Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.software-eng Subject: Re: Attempts to connect SA/D and OOPS Summary: Some answers -- short answers, but answers Message-ID: <573@ajpo.sei.cmu.edu> Date: 5 Sep 89 19:20:51 GMT References: <8908251356.AA04062@mwsun.mitre.org> Lines: 296 In article , Dick Botting writes: > In Vol 6 Number 42, Edward Berard described > the costs and problems of discarding older methods and tools to gain the > benefits of Object Oriented Programming. He mentions 4 new methods: > > OODA - Object-oriented domain analysis > OORA - Object-oriented requirements analysis > OOD - Object-oriented Design > OOP - Object-oriented implementation > (often called Object-oriented programming) > > He stated that these were different to previous methodologies and hinted > at the existence of much detailed information on these techniques. He > also said that > >I would very much like to avoid a detailed discussion of the processes > >involved in OORA, OOD and OODA > > I would certainly value a detailed discussion of such topics - > a seminar on Ada and OOP costs $500 for example and 2 days. At present, I cannot go into a detailed discussion of the methodologies, but I can give you a sketch of the motivations, concepts, and backgrounds. Historically, much of the work in object-oriented technology focused on programming language issues, e.g., how to implement a particular concept in programming language X. Little thought was given to "formal approaches." In fact, a common description of object-oriented programming was: 1. create classes 2. create instances of the classes (i.e., objects) 3. cause the objects to interact via message passing. This approach works very well with small, easily-understood systems. However, as the size of a system grows, additional techniques are needed to manage the complexity. Make no mistake about it, object-oriented programming has made several important contributions to software engineering, _over_ _and_ _above_ _the_ _usually_ _cited_ _advantages_ _of_ _object-oriented_ _technology_, e.g.: - The concepts and techniques of "composition" as opposed to "decomposition." Traditional approaches, emphasized breaking a system down until all that remained were easily understood units (modules). While this did help to manage one type of complexity, it did little to offset the increased complexities of duplications, and "re-invention of the wheel." Many people confuse composition techniques with "code first, think later." This is not the case. Composition dictates that the developers have a library of reusable components, and that at some point during development, the software engineers will be able to make an informed decision as to which, if any, of these components can be used in the new system. - The concept of treating vastly dissimilar items in a similar manner, thus keeping things simple. For example, a graphics object can be stored and retrieved in much the same manner as a text object. (It is no accident that polymorphism is very often associated with object-oriented approaches.) You might say that object-oriented software engineering involves: - the identification of relevant objects and classes - documentation of these items - the application of sound configuration management to the objects and classes - documenting the interaction of these items with each other and their surroundings in a manner which is consistent with an object-oriented philosophy. - application of testing, maintenance, quality assurance, debugging, and other techniques in a manner consistent with an object-oriented philosophy. Note that I carefully avoided saying how the "relevant objects and classes" were identified, e.g., they could have been identified by inspection, or uncovered via decomposition of a large system. Of course, we should point out that object-oriented approaches are fundamentally different from the more traditional approaches. Further, we should also observe that the general life-cycle approach is very different, i.e., object-oriented life-cycles are recursive/parallel ("analyze a little, design a little, implement a little, test a little"), as opposed to the more traditional waterfall life-cycle (all the analysis, followed by all the design, followed by all the coding, etc.). If you will grant me that this is a "short net message" and not a series of week-long tutorials, I will attempt to present some material here regarding object-oriented life-cycle methodologies. Please remember that this is material taken out of context, and is presented with virtually no explanations. Object-Oriented Domain Analysis (OODA) may be accomplished by: 1. Defining the domain 2. Defining (conceptually) the object-oriented items which are to be considered for reuse within the domain 3. Collection of a representative sample of applications found within the application domain 4. Analysis of these representative applications it identify reusable components 5. Defining reusability guidelines regarding the reusable components 6. Demonstrating reuse using the reusable components and the guidelines 7. Making recommendations [OODA can be, and is, much more formal than these few points suggest.] Object-oriented requirements analysis (OORA) can be accomplished by: 1. Identifying the sources of requirements information 2. Characterizing the sources of requirements information [Note that these first two steps are required for any requirements analysis -- object-oriented, or not.] 3. Identifying candidate objects, classes, systems of objects, and subsystems (see my earlier postings on comp.lang.smalltalk for definitions of "subsystems" and "systems of objects") 4. Building object-oriented models of both the problem and potential solutions, as necessary 5. Re-localization of the information around the appropriate candidate objects, classes, systems of objects, and subsystems 6. The selection, creation, and verification of object and class specifications (OCSs), subsystem specifications, and system of objects specifications. 7. Assigning the above items to their appropriate place in the object-oriented requirements specification (OORS), i.e., the object-general section, or the application-specific section 8. The development and refinement of the qualifications section of the OORS 9. The development and refinement of the precise and concise system description. Object-oriented design (OOD) may be accomplished by: 0. Object-oriented domain analysis (OODA) 1. Object-oriented requirements analysis (OORA) 2. Identifying design objects and classes of interest 2.1 Developing a design strategy [at an appropriate level of abstraction] 2.2 Identifying objects, classes, subsystems, and systems of objects, of interest 2.3 Associating attributes with these items 3. Identifying operations suffered by and required of each object and class of interest 3.1 Identifying operations of interest 3.2 Associating attributes with the operations of interest 3.3 Handling composite operations 3.3.1 Decomposition into primitive operations 3.3.2 Decoupling of objects and classes 4. Selecting, creating, and verifying object and class specifications (OCSs), subsystem specifications, and systems of objects specifications, for design 4.1 Binding objects, classes, and operations 4.2 Examining objects and classes for completeness 5. Deciding on language implementations for objects, classes, systems of objects, and subsystems 5.1 Items identified during analysis 5.2 Items identified during design 6. Graphically representing both object-oriented items and their interactions 6.1 Static representations 6.1.1 Booch diagrams (can be used with many different languages) 6.1.2 Semantic networks 6.1.3 Subsystem graphics 6.1.4 Systems of objects graphics 6.2 Dynamic representations 6.2.1 State transition diagrams 6.2.2 Petri net graphs 6.2.3 Object-Message diagrams 7. Establishing the interface for each object-oriented item 7.1 Objects and classes 7.2 Systems of objects 7.3 Subsystems 8. Implementing each object-oriented item 8.1 Implementation of the interface objects and classes 8.2 Implementation of the other objects and classes 8.3 Recursive application of the object-oriented development process > He refers to the use of Petri Nets to describe the behaviors of > object-oriented systems - I studied these in some faculty seminars back in > the early 1970's - as I recall, when we drew a Petri Nets some of the cycles > in the equivalent directed graph were associated with `objects`. For example > Making coffee had cycles running thru all places involving `perculator`, > and another cycle covered all the `cup` occrrences and so on... When two or > more of these cycles overlapped then the objects tended to be interacting. > > Does something like this also happen in OO systems? Somewhat, however, it is more common to ask questions such as "what objects have to be in what states for a transition to occur?" Remember, in object-oriented Petri nets, places represent specific objects in specific states. > How many real projects have used Petri Nets? The Europeans in general, and the Italians especially, seem to be very interested in Petri nets and Petri net graphs. I know of a few communications systems applications which have made use of Petri net graphs. Although they are conceptually very simple, one of the biggest obstacles to their effective use is the apparent lack of understanding of how to use both levels of abstraction and equivalence classes to simplify models created using them. > How do you communicate a Petri Net over the network? One of the things I find particularly attractive about Petri net graphs is that they can be reduced to mathematical expressions. These mathematical representations have two very important additional benefits: they aid in the verification and automation of Petri net graphs, and once in their mathematical form, they can be converted to other representation forms, e.g., state transition diagrams. There is, of course, much more that I could say. Unfortunately, my time is limited. Thanks for listening. -- Ed Berard Berard Software Engineering, Inc. 18620 Mateney Road Germantown, Maryland 20874 Phone: (301) 353-9652 E-Mail: eberard@ajpo.sei.cmu.edu