and Data Flow Models -- A Case Study

Comparing

Object-Oriented

and Data Flow Models -- A Case Study John C. Kelly Jet Propulsion Labomtory California Institute of Technology Pasadena, CA 91109

Ken Abanethy Depamnent of Computer Science Furman University Greenville, SC 29613 Abstract

the concepts of functwnal decomposition and structured programming popularized by Dijksb’a [8], [9], Wirth [16],

Object-oriented analysis is the newest component of a proposed object-oriented software life cycle methodology. In this paper, we make comparisons between the standard data flow diagram (DFD) models and the newly introduced object models within the context of an existing moderately complex (approx. 65,000 lines) software project. In particular, we compare the complexities of competing models for the project domain using some simple metrics.

[17], and othera in the 1970s.

1.

Introduction

Recently, object-oriented programming has emerged as an important alternative to structured programming. The ready availability of several object-oriented languages and their potential for enabling the creation of reusable code have enhanced the popularity of this paradigm. However, many organizations have been reluctant to make a strong commitment to the paradigm, because it is difficult to combine the use of the established structured anaJysis and design methods with object-oriented programming. Responding to the need for more compatibility between design models and the programming paradigm for objectoriented programming, several authors (see [4], [51and [15])

and Background

One of the essential features of modem methods of analysis and design is the use of abstraction, accomplished through the construction of models of the problem domain and the proposed system design, to manage the multitude of details inherent in a complex system. In this paper, we will make an empirical comparison between two modelling methods used for software system requirements definition.

have developed object-oriented design (GOD) techniques. These techniques have been successful in that an objeztoriented design can be more or less directly translatedinto code written in an object-oriented language. However, in order for the object-oriented approach to be considered a complete life cycle methodology, mdmds for performing an object-oriented requirements analysis must be defined. During the last several years, we have seen the beginning of t.tis attempt (see [3], [6], and [14]).

CurrentJy, the most widely used technique for modelling software requirements employs data jknv diagrams (DFDs, for short), which model the flow of data through the essential processes (functions) of the system. Data flow diagrams are organizd into levels, and where appropriate, the functions shown at a higher level are decomposed into their own DFDs at the next lower level. Hence, we may expose more and more detail as we move to lower levels in The decomposition process the diagram hierarchy. continues until the functions being described are simple enough (they are calledfwtctiond primitives, at this point) to be described in brief mini-specifications. The data flows employed in the various DFDs are cataloged and defined in a supporting data dictionary.

Being the newest component of the object-oriented methodology, object-oriented analysis (OOA) is consequently the least formalized and the least undmtood component. Coad and Yourdon [6] have laid out some of the principles, but details about how to apply these Principlm are still evolving. In 00A, the basic model that is adopted is an object model, as opposed to the functional decomposition model used in the smtctured methodology. Once defined in the analysis phase, the object model is refined, expanded, and more completely specified in the design phase.

Data flow modelling is a part of the widely used and design methodology. This methodology was introduced by Yourdon and Constantine [18], and has since been developed and modified by a number of authors (cf. [7], [10], 11], [12], and [13]). Its development was encouraged by, and is tightly coupled to,

structured analysis

In an object model, the objects themselves are structured entities containing both data (attributes) and functions (services). Collections of objects with the same structure are called classes. Classes of objects are organized and related in several different ways. Two imprtant kinds of structures within the class definitions are modelled -wholelpart structures and generalizationlspecialization (classhbchss) structures. Relationships among classes are identified and the cardinality (oneoone, many-to-one, one to-many, many-to-many) of the relationships given where possible. Additionally, the basic message connection paths between classes are included in the model. Finally, root classes (classes at the top of the hierarchies) are sometimes

Permission to copy without fee all or part of this matariel ia grented provided that tha copies are not meda or diatnbuted for diract commercial edvantaga, the ACM copyright notica and the titfe of tha publication and ita date appaar, and notice ia givan that copying ia by parmiaeion of the Association for Computing Machinery. To copy otharwise, or to republish, raquirea a fee and/or specific parmiaaion.

01992

ACM

089791

-472-4/92/0002/0541

$1.50

541

Structure

of an Object

Symbol Ke~

Model

—----7aM................. :~I~–– I(:I

SWv’c.s

...........

:X’+

q

Aii?iii ~.

.

. . . .%-~ .....

‘...,...7

-

““’”.’”.,,., ,,,jjj

...

..,, t,.

... ..

w!

...

&

1:1

‘VJ

@

,.-\................ ...

*

,..J

@

Figure 1: Overall structure of an object mo&L 2.

This grouped into related collections called subjects. partitioning into subjects provides a higher level view of the entire object model. A diagram illustrating the modelling process employed is given in Figure 1 (the diagraming conventions used them are adapted from [6]).

The Case Study Problem and Models

ln orderto comparethe two modellingtechniques,we decided to examine models produced by each of the techniques for a single problem domain. For the problem domain, we choose an existing software system developed The system’s overall at the Jet Propulsion Laboratory. purpose was to provide an automated arehive, catalog, and order system for a variety of data products generated from end related to satellite images. This system represents a moderately complex (approximately 65,000 lines of largely fourth generation code) project. It was implemented on a VAX 8530 with VMS operating system, employing the INGRES database management system. The INGRES tool Application-B y-Form (ABF), which includes the fourth generation language Operations Specification Language (OSL), was the primary development environment. The majority of the code was written in OSL, with more detailed components written in the C language.

There is a fundamental difference in perspective between data flow and object models. In a data flow model, we concentrate on organizing system knowledge around a hierarchy of functions, with data organization playing a secondary role. In en object model, the primary organizing concept is that of an object and its embodied data (attributes) and functions (services). Because of this basic difference, it is natural to ask which is the superior paradigm for system modelling. We are not attempting the resolution of this question in this paper. In feet, it is our view that it is premature to even discuss this issue until we gain a great deal more experience in using the objectoriented approach, especially on large complex systems.

The original requirements analysis and system design was conducted using standard structured analysis methodology, and hence we had in hand from the beginning a software requirements data flow model. ‘l%ismodel had three levels and included 8 high-level processes and 36 functional primitives. Its structure is illustrated in Figure 2, where the functional primitives are shaded for emptils.

Instead, we will compare the two modelling methods on an empirical basis in tie hope of better understanding some of their similarities and differences. In particular, we address three questions in our comparison. Can object models be efficiently managed with iterative development? Are object models more, or less, complex than DFD models? How does the number of components (objects, messages, services, ete.) in an object model compare with the number of components (high-level processes, functional primitives, data flows, functional requirements) of a DFD model?

To complete the modelling, we performed a simulated object-oriented requirements analysis for the

542

Context

Diagram~

1.0 = Manage Inventery 1.1 1.2

Oate = Ptanege Pteta4eta = Ilanege tliaaien Plan

2.0 3.0

Date

1.3 = PtarmgeOrder Deta

=Ptanaga Archive =Transferrnlnmge8

Date

4.0 =PrOd~o&Digtrib~oPreduct$ 5.0 = Manage Bibliegrapbg

Figure 2: Hierarchical structure of the data jlow mo&l for the case study problem. project, producing an object model of the system requirements. We began this process by making a survey of the general problem domain as it was described by the data flow diagrams,data dictionary,and mini-specifications. Using information gleaned from this survey, we created a rough first draft object model. In order to refine our initial rough model, we concentrated on the software requirements as expressed in the mini-specifications for the functional primitives in the data flow model. We collected these requuements into a database system, which allowed us to use the search and retrieval capabilities of a database management system to view the requirements flexibly. We employed two primary

strategies at this point -- the first used the requirements database to refine, evaluate, screen, and add detail to the candidate objects we had so far discovered; the second used the requirements database to discover additional object definitions. To employ the first strategy, we considered the suggested object definitions that we gathered during our initial problem domain analysis. With these candidate object definitions in hand, we then searched our database for requirements that could logical] y be embodied in these objects. For example, if we had a candidate object class called Sensor, we would search for all requirements that contained the word sensor. Or, we might search for sensor and other related words -- say temperature and pressure, depending upon what kind of parameters the sensor was thought to be measuring. In this way, we evaluated our initial choices of potential objects. Those objects that had several related requirements became stronger candidates than those that had few or none. Using this approach, we also

added to objects services which satisfied the functionality expressed within the associated requirements. On the other hand, there were a number of requirements that were not associated with objects we had thus far identified. Our second strategy involved using such requirements to generate new potential object definitions. The method we employed was adapted from work by Abbott [1] and is described in detail in [2]. Briefly, we started by identifying key nouns or noun phrases in these requirements, then searching for additional occurrences of the same words or phrases, and for synonyms or aliases, within our requirements database. For example, by grouping all the requirements that contain the word temperature, we could discover the need for a Sensor object class, assuming we had not already identifkd it, Once we were satisfied that we had captured a fairly complete version of the problem domain in our object and class definitions, we proceeded to structure the identified entities in ways that represented the inherent relationships of the classes and objects being modelled. In particular, we looked for generalization/specification structures and whole/part structures, and relationships between separate classes. We also grouped classes into four higher-level subjects. The resulting object classes and their hierarchies are shown in Figure 3, where we have shaded the various hierarchies for emphasis. The four subjects are grouped and numbered according to the following: 1 = Data subjec~ 2 = Or&r subject; 3 = Operations subject; 4 = Account subject. Finally, using the requirements database as a guide, we incorporated all the necessary message connections among objectsand classes into the model.

543

Giiki3””&” ~

&

ii’fiiia

Giiia

@

A

Figure 3: Abbreviated form of the completed case study object mo&l. experience was that the object model is easily modified as new problem domain knowledge is discovered. Basic object definitions were stable throughout the process. Changes to them generally had only a local effect. When new object classes were discovered and added, existing classes were seldom effected. The coupling among the basic building blocks (object classes) is much looser than in a DFD model. We need not fix the communication lines between classes (messages) early in the modelling process, hence the coupling that does exist can be imposed after the modeI assumes a more stable arrangement.

While applying both object definitionirefinement strategies, we kept track of the object-requirement As we associated relationships in our database. requirements with object candidates and services, we

recorded the object names, along with the number of the object’s services that were associated with the particular requirement, as part of the &tabase record for that requirement. In addition, we also created a database for objects, in which the associations of services and requirements were tracked as well. 3.

Comparing

the Two Models Our second question concerned the relative complexity of the two models. The original DFD model for the case study system consisted of three levels of diagrams, with a total of 8 higher level processes and 36 functional primitives (c.f. Figure 2). These functional primitives contained a total of 209 requirements, or an average of 5.8 requirements per primitive. The object model which we derived contained a total of 52 classes of objects (14 root classes), grouped into 4 subjects (cf. Figure 3). The total number of services associated with objects was 2(M (160 of these were derived from the 209 requirements and 46 were

As we noted earlier, it was our intent to address three questions in our comparison of the hvo models. ‘Ile fmt question concerned the ease with which iterative development could be managed within the object model. As described earlier, our development of the object model was an iterative process, done in thres stages. First we collected object definitions as we made our initial survey of the problem domain. Then we refined these definitions and added others as we analyzed the requirements database. Finally we modelled the structures inherent in the classes and objects, as well as relationships among them. Our

544

Data Flow I’lodel Top Lovol Com~ments:

Mld Lovol Objecte:

Pri mlttvee:

Object

Model

6 processes --5 of thsse are high-level (with their own dde flow dfegrems), end ! is e functional primitive.

4 subjects. centst ntnq 3,5, 4, ml 2 root clesew reepectwel y.

8 total high-level processes wit h ttdr own DFDs.

14 root cle.we, 6 efwhich hove eseeciated hie rorc hies.

36 functional primitives.

38 leef clessee (chs$es with no ports or subclasses).

209 requirements

Leveliw:

206

6 processeset level 1 20 procewes8t level 2 i 8 proceweset level 3

i 4 cl0ss0sat level 1 20 classeset level 2 9 clews et level 3 4 clesseset level 4 5 cleaseset level 5

Figure 4: Comparing

model complem”ties.

expressed in DFD mini-specs) related to services, and we found that most requirements are associated with a single serviee in a single objeet. Some requirements (24 of the original 209)werenotassociated withanyobjeetorserviee (upon closer examination these did not speeify a true software requirement, but rather constraints on other requirements). Excluding these 24 requirements, only al.mut 16% of the requirements were associated with multiple serviees, suggesting that the mapping from requirements to services is relatively dint. The proffle of associations of requirements to numbers of serviees is given in Figure 5.

added standard Create and Delete services), or an average of

Figure 4

approximately 4.0 services per object. summarizessome of this data.

totel servl ces

in mini-specifications.

The data in Figure 4 suggest that the complexity inherent in the two models is comparable. The numbers of major components at each level is similar. The objeet model has two extra layers in its class hierarehy as opposed to the functional hierarehy of the data flow model, but this is compensated for by reduced coupling between components. At the least, we can conclude that the objeet model does not involve a proliferation of objects.

We can also consider the requirements/services association from the reverse perspective. In other words, we can ask from how many requirements a given service was derived. When we do, we fmd that most of the services were associated with a single requirement. Again, some

third question also concerned complexity reflected by the numbers of details to be managed within the models. Some insight into this issue is supplied by Figure 4. At a more detailed level, we considered how requirements (as The

R ●

q u

i r ●

m ●

n t s

o

2 3 Nutiw nf SWviccs

1

❑ Numbtr of requirtmwhs

4

s

6

having giwn nwnbw of essc.ciatcdscrviccs.

Figure 5: Comparing requirementlservice associations.

545

Ssrvtees

160

&

Rqutrem*nts

144

s

128

?

r v i e

112

112- 96 00 64

●

s 16

0

3 4 5 2 Nwnbu of R@quir@mmts ❑ Numbw of scrvixs havhg givsn numbw of associated requtrwnmts. 1

Figure 6: Co~”dering servicelrequirement associations. to be modelled, but upon many decisions made by the model developers. Hence, a comptison of data such & we have presented must be interpreted with that in mind. However, we believe that there are two general conclusions which this case study strongly supports.

were not derived from any requirement (47), but of those that were associated with one or more requirements, only about 29% were associated with more than one requirement. These results are summarized in Figure 6. Finally, the average number of services per object (approx. 4.0) compares favorably with the average number of requirements per functional primitive in the data flow model (approx. 5.8), and hence the mapping from requirements to objects is quantitatively similar to the mapping of requirements to functional primitives. This fact shows up when we compare associations of functional primitives and objects. Four of the functional primitives did not contain software ~uirements modelled in the object model. Of the 32 other primitives, more than half had all their requirements modelled in a single object each. The results of this comparison are displayed in Flgum 7. 4.

First, we found the object model to be compatible with and supportive of iterative development. Second, the overall complexity of data flow models and object models appears comparable. This is supported by examination and comparison of the structural entities within each model as well as a detailed comparison of more primitive entities. In particular, we found that the numbers of model components compare quite favorably between the two modeIs (Fig. 4). In addition, we observed the mapping between requirements and services and the mapping between functional primitives and objects, while not entire]y one-to-one, to be reasonably direct (13gs. 5, 6, and 7). While certainly not definitive, this case study suggests that creation and maintenance of an object model will require efforts quite similar to those required for a corresponding data flow model.

Conclusions

Granted,the form of any particular model (of either type) will depend not only on the problem domain and the system

F u n c t i o n a 1

P r i m i t i v ●

s

o

1

2 3 Nu’nb@r of Objwts

❑ Nunbw of prfmftivcs whosor~wntnts

4 art assc-tdatod with th+

qivtn nurnbwof objwts.

Figure 7: Considering objectlfunctionai primitive associations.

546

Acknowledgements

References 1.

2.

3.

1983. Abemethy, K. and Kelly, J., “A method for creating object models for object-oriented analysis,” to

appear. Bailin, S., “An object-oriented specification ACIU, hby,

4.

5.

6.

7. 8.

9.

The research described in this paper was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.

Abbott, R., “Program design by informal English descriptions,” Communications of the ACM, Nov.,

method,”

The first author’s work on this project was supported by an ASEE/NASA Summer Faculty Fellowship.

requirements

Communications

of the

Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacnuer, or otherwise, doe-s not constitute or imply its endorsement by the United States Government or the Jet Propulsion Laboratory, California Institute of Technology.

1989.

Booth, G., “Object-oriented development,” IEEE Transactions on Software Engineering, Vol. SE-12, No, 2, Feb., 1986. Booth, G., Object-Oriented Design with Applications, Benjamin Cummings, Redwood City, CA, 1991. Coad, P. and Yourdon, E. Object-Oriented Analysis, 2nd Ed., Yourdon Press, Englewood Cliffs, NJ, 1991. DeMarco, T., Structured Analysis and System Spec@cation, Yourdon Press, New York, 1978. Dijkstra, E., “The goto statement considered of the ACM, Mar., harmful,” Communications 1968. Dijkstra,

E.,

A

Discipline

of

The case study was developed from Jet Propulsion Laboratory document D-5298, Revision A, Alaska SAR Facility Archive and Catalog Subsystem, Software Requirements Document.

Programming,

Prentice-Hal!, Englewood Cliffs, NJ, 1976. 10. Gane, C. and S-wson, T., Structured Systems Analysis: Tools and Techniques, Prentice-Hall, Englewood Cliffs, NJ, 1979. 11. Jackson, M., System Development, Prentice-Hall, Englewood Cliffs, NJ, 1983. 12. McMenamin, S. and Palmer, J., Essential Systems Analysis, Yourdon Press, New York, NY, 1984. 13. Page-Jones, M., The Practical Guide to Structured Systems Design, Yourdon Press, New York, NY, 1980. Systems 14. Shlaer, S. and Mellor, S., Object-Oriented Analysis, Prentice-Hall, Englewood Cliffs, NJ, 1988. 15. Ward, P., “How to integrate object orientation with structured analysis and design,” IEEE Software, March, 1989. 16. Wirth, N., “Program development by stepwise refinement,” Communications of the ACM, Apr., 1971. 17. Wirth, N., Systematic Programming : An Introduction, Prentice-Hall, Englewood Cliffs, NJ, 1973. 18. Yourdon, E. and Constantine, L,, Structured Design, Yourdon Press, New York, 1975.

547

548