tom@ghp.UUCP (Tom Huras) (09/28/88)
This is a request for techniques or methodologies for analysing
complex engineering systems. There is much said about object-oriented
programming, a tiny bit on object-oriented design (a few rules of
thumb), but there is a paucity of material on object-oriented
analysis. In this posting I explain why the traditional techniques
are insufficient, and what I'm trying now. If there are no
methodologies available, it would be nice if someone confirmed what
I'm trying.
In software engineering, there seems to be a shortage of analysis
techniques. The traditional "data processing" techniques:
- structured analysis (Gane & Sarson dataflow diagrams and process
diagrams)
- data modeling (Chen's entity-relationship diagrams)
tear out the procedural aspects from the data. In complex
engineering systems, the principles of information hiding,and data
abstraction say that the traditional approaches are inadequate.
The concept I'm using right now is to model the "enterprise" by its
fundamental objects. I've started with an entity-relationship model
to get a model of the passive, data objects. I've enhanced the model
by associating methods with the objects, and I have allowed for
inheritance to capture the generalization aspects. Going at the model
from the other end, I've modeled the high-level, active objects as
resources accessing and using the passive, data objects.
The overall goal is to use the model to partition the system into real
computer systems and human tasks. Then, further expand the objects
into greater detail for eventual implementation (maybe even using an
object-oriented language).
Just so that you know where I've been, my prime sources of motivation
at this time are:
- Bertrand Meyer's Object-oriented Software Construction (1988):
provides compelling reasons for using object-oriented techniques
- Brodie/Mylopoulos/Schmidt's On Conceptual Modelling (1982): deals
with the need for conceptual modeling borrowing techniques of
knowledge representation from AI, semantic data models from databases,
and abstractions from programming languages.
- Rumbaugh, "Relations as Semantic Constructs in an Object-Oriented
Language", OOPSLA '87: this tells how relations in an
entity-relationship model should be implemented in an object-oriented
language.
Comments? I'll summarize if appropriate.
--
"Wisdom is supreme; | Tom Huras, Gellman.Hayward & Partners Ltd.
therefore get wisdom. | 33 Yonge St., Toronto, Ontario, Canada, M5E 1G4
Though it costs all you have,| UUCP:{decvax|allegral|ihnp4|linus|utcsri}
get understanding." | !utzoo!mnetor!ghp!tom
Proverbs 4:7 | Disclaimer: These are only my opinions.johnson@p.cs.uiuc.edu (10/04/88)
>This is a request for techniques or methodologies for analysing >complex engineering systems. There is much said about object-oriented >programming, a tiny bit on object-oriented design (a few rules of >thumb), but there is a paucity of material on object-oriented >analysis. >Tom Huras, Gellman.Hayward & Partners Ltd. Tom's signature file was amazing. It gave the answer to his question! I am definitely going to put it in a paper or two. The relevant fragment of the signature was: "Wisdom is supreme; therefore get wisdom. Though it costs all you have, get understanding." Proverbs 4:7 One of the things about o-o programming that is not well understood is that there is little difference between o-o programming, o-o design, and o-o analysis. Smalltalk programmers use rapid-prototyping to figure out the problem and to develop a clean design. The reason for this is that the only people who really know how to design something are those who have done it before. Rapid prototyping is the solution to the question, "If hind-sight is so valuable, how do I get it?" If you understand what I am saying then you will immediately object that the whole point of emphasising analysis and design is to reduce the bugs that always crop up after slash-and-burn programming. I'll get to that later. One of the things that I like about object-oriented programming is that it lets the design of a program shine through the code. Object-oriented programming provides new ways to structure a program, such as class and instance hierarchies. Protocol specifications (i.e. interface descriptions) become much more important than in other languages, primarily because there are many classes that implement the same protocol. The result is that I can quickly figure out the design of a well structured object-oriented program. ("Quickly" being relative, of course.) Systems written in C tend to have little structure. The original design is virtually impossible to figure out unless there is good documentation. However, documentation is rarely modified when the code is modified, documentation often gets lost, and it is frequently never written. It is much better to ensure that the design of the system is included along with the code for the system so that later generations of programmers can figure out what is going on. This is not to say that o-o systems can't be improved. There are many kinds of design information that are not included with the program. Performance choices are an important catagory. Also, descriptions of the overall "framework" (the word has a technical meaning) are also hard to get out of the code unless you know what you are looking for. This is a great area for research. The fact that the code for an o-o system contains a great deal of the design information means that programmers are doing design. Alternatively, once the design is done, coding is virtually complete. Thus, it is rare to see the distinction between system analysts and programmers in places that do o-o programming. Instead, there is a distinction between tool-kit builders and tool-kit users, or between framework developers and application programmers (same thing in different words). However, both are programmers/designers. Quit a few people at OOPSLA last week made this point. I think the reason why we make this point so emphatically is that we are finding the people don't believe us. Lots of people think that this way of building a system is unreliable, inefficient, immoral, and fattening. On the other hand, object-oriented systems have a reputation for being reliable and very productive of programmer time. One would think that people would believe those who build object-oriented systems when they explain how the systems were built, and recognize that there is a relationship between how a system is built and what it looks like at the end. The object-oriented life-cycle is, without any doubt, cyclic. In fact, it makes one wonder how the waterfall model can be called a life-cycle. A particular application group starts with a set of classes, extends them, modifies them, and comes up with a prototype of the application. They then find out from the customers what was really needed and revise the system. This happens several times. In the middle, the application classes may be reorganized as an antidote to entropy. Some of the classes may be considered general-purpose enough to be added to the standard class libraries, but most are not. In between applications, framework designers spot similarities between applications and try to develop classes that will help solve similar problems in the future. Often the third or fourth application of a particular type will cause the designers to try to develop some general purpose components instead of building special purpose ones again. They may look back at the older components and generalize from them or they may come up with a solution that is a more radical departure but that solves the same problems. In any case, general solutions always come out of several concrete solutions. The main reason that o-o programming is so popular is code reuse. Reusable code is harder to write than other code because, in addition to being correct, it must be reusable. The only way to see whether or not code is reusable is to reuse it. If some classes will work in three previous projects then they are more likely to be reusable than classes that have only been used in one project, which is one of the reasons why reusable code is usually a result of generalizing from earlier projects. I believe it is code reuse that makes the iterative life-cycle model so important to object-oriented programming. Design by rapid-prototyping is different from the slash-and-burn style of programming because the purpose is different. Slash-and-burn programmers just want to get a working system. Rapid-prototypers want to understand what they are supposed to do. The hardest part of building a system is understanding its requirements. "Understanding" is the goal of the object-oriented programmer, and the price of obtaining it is no greater than the priced of successfully building the system. Thus, "though it costs all you have, get understanding". Once you understand the problem and how to solve it, implementing the solution is easy. It is the understanding that is the bottleneck. One of the differences between object-oriented programmers and others who prototype is that we rarely throw a complete system away. Instead, we "grow" the system by modifying or throwing away parts of it but keeping most of the system at each stage. Of course, after a while there is little trace of the original system, but each step along the way consists of a working program. One of the reasons why this works is that object-oriented system are extremely modular, so replacing one module with another is relatively painless. Late-binding of procedures makes this especially easy. Last week I talked to the Analyst people at Xerox and someone building oscilliscopes for Tektronix. I heard people talk from Apple and Mentor Graphics. They all gave the same story. Their experiences are the same as my own building compilers and operating systems. Object-oriented analysis and design is little different from object-oriented programming. Certainly we need better ways of describing our systems, but those ways will help programmers just as much as they help analysts and designers. Ralph Johnson -- University of Illinois at Urbana-Champaign
eddy@battenkill.uucp (frederick s eddy) (10/04/88)
In article <125@ghp.UUCP> tom@ghp.UUCP (Tom Huras) writes: > >This is a request for techniques or methodologies for analysing >complex engineering systems. ... >Just so that you know where I've been, my prime sources of motivation >at this time are: > >- Bertrand Meyer's Object-oriented Software Construction (1988): >provides compelling reasons for using object-oriented techniques > >- Brodie/Mylopoulos/Schmidt's On Conceptual Modelling (1982): deals >with the need for conceptual modeling borrowing techniques of >knowledge representation from AI, semantic data models from databases, >and abstractions from programming languages. > >- Rumbaugh, "Relations as Semantic Constructs in an Object-Oriented >Language", OOPSLA '87: this tells how relations in an >entity-relationship model should be implemented in an object-oriented >language. We are using an extended variant of the Entity-Relationship diagram here at GE Corporate R&D Center. We have found it to be very effective, both during analysis and design of object-oriented systems. Our technique, called "Object Modeling Technique" (OMT) was developed jointly by GE-CRD and Calma. (Jim Rumbaugh, cited above, works here at GE-CRD.) Here are some additional references: Loomis, Shah, and Rumbaugh, "An Object Modeling Technique for Conceptual Design", ECOOP '87 Proceedings, 1987. Published as Lecture Notes in Computer Science 176, Springer-Verlag, 1987. Blaha, Premerlani, and Rumbaugh, "Relational Database Design Using an Object-Oriented Methodology", Communications of the ACM, April, 1988. Sally Shlaer and Stephen Mellor, "Object-Oriented Systems Analysis: Modeling the World in Data", Yourdon Press, 1988. The Shlaer/Mellor book presents an analysis method similar to our OMT technique. Chapter 9 of the book gives a very brief introduction to the use of State Models to capture dynamic behavior, but there is much more to it than is covered in the book. Shlaer and Mellor offer two courses covering their method in detail. Call Project Technology Inc. (PTI) at (415) 845-1484 for more information. (I should add that I have no relationship to PTI other than as a customer.) Fred Eddy | UUCP: uunet!steinmetz!battenkill!eddy GE Corp. R&D | ARPA: eddy@ge-crd.arpa Schenectady, NY | Fred Eddy | UUCP: uunet!steinmetz!battenkill!eddy GE Corp. R&D | ARPA: eddy@ge-crd.arpa Schenectady, NY | GE DECnet: csbvax::mrgate!eddy@moose@smtp@tcpgateway
tockey@hrsw2.UUCP (Steve Tockey) (10/07/88)
Some work on this very topic has been going on at Boeing for the
last 18 months or so. Our work has lead us to much the same
conclusions as Shlaer/Mellor, and that is that a combination of
Data/Information modeling, Behavior/state modeling, and Process/
function modeling (with a few structural rules thrown in) can be
used very sucessfuly to not only model system requirements specs
in an object oriented fashion, but also helps tremendously to
identify the objects and classes in a given problem domain. Both
Shlaer/Mellor (AKA Project Technology) and we published papers
in the proceedings of the last Structured Development Forum. (You
may be able to get copies of the proceedings through Ted Michaels,
Lawrence Livermore National Labs, PO Box 808, L-308, Livermore, Ca
94550.
We also published our paper in the proceedings of the upcoming
Ada-Expo (9 thru 11-Oct, Anaheim, Ca), and my co-worker on this
project will present the paper in session 12 (2:00 to 3:30pm,
Tuesday, October 11).
We have a few pilot projects here at Boeing that are using the
method (on some significant applications) with great success. We
hope to publish the results of these pilot projects at upcoming
conferences. Project Technology (Shlaer/Mellor) have consulted on
several _major_ projects using the method and have been quite
successful.
Several other people are also working on object oriented analysis,
but have come to substantially different conclusions. (Dave Bulman,
Pragmatics, Inc. PO Box 3020, Waikoloa, Hi, 96743, Tel (808)883-9011;
Seidewitz and Stark at Nasa-Goddard, no address available, Ed Berard
at EVB Software Engineering, 5320 Spectrum Drive, Frederick, Md 21701,
Tel (301) 695-6960.)
The field of object oriented analysis is quite new, that accounts for
the lack of published material. But expect a lot of press in the future
(Who? _ME_? Biased? Nahhhhhhh :-).
Shlaer/Mellor would probably send you a copy of their paper (it covers
much more of the method than their book). If you have trouble getting
SDF or Ada-Expo proceedings, I can send copies of our paper to
interested people. My UUCP address is:
uunet!{pilchuck|uw-beaver}!apicsea!hrsw2!tockey and my ARPANET address
is in the .sig
-- steve tockey.
--
-- Steve Tockey Boeing Computer Services
Software Engineering Support (G-2544) P.O. Box 3707 MS77-87
tockey%ada3.boeing.com Seattle, Wa 98124