lawesn@SouthBank.UUCP (05/19/87)
Request for information from designers/developers
of object oriented systems:
A Systematic Method for Object-Oriented Development
Yes folks, thats the title of my MSc project. I am working on some
sort of design methodology for OO systems. I am particularly interested
in developing a requirements elicitation method targetted to the conceptual
categories of OO languages. The conceptual categories identified are
+ messages
+ classes
+ methods
+ inheritance
The idea is to structure information about the target system at the earliest
possible stage. I would particularly like to open a dialogue with people
who have experience of Object-Oriented design. The questions I would like to
ask you are:
+ what kind of approach did you take to the design of your system.
+ how did you select your classes.
+ how did you manage inheritance in your system.
+ did you make use of the model-view-controller paradigm.
+ based on your experience, how would you approach the same problem
if you had to start all over again.
And any other points that you feel are appropriate to OO system design. I
would also be interested in references (I think I have access to the more
common ones, such as the smalltalk books). Please reply to this if you have
experience in OO system design, I will summarise findings to the net.
Also I would like to reach people at Apple computer who as we know, have
made significant progress in providing OO tools 'for the rest of us'. But
I am genuinely interested in discussing this area of design with anybody who
has input on the subject. By the way, the two systems that I am using are
Smalltalk-80 on a Tek 4406 and MacApp/Object Pascal.
Please reply direct to the address below ( ..mcvax!ukc!idec!kbsc!lawesn )
Thanks in advance...........
Nick
Nick Thompson. ..mcvax!ukc!idec!kbsc!lawesn
South Bank Poly & Imperial College, London. Phone +44 1 858 4371
c/o 53 Maze Hill, Greenwich, London, SE10 8XQ, UK.
"A turkey with a PhD is still a turkey"
This message has been mailed by Nick Lawes on behalf of the forementioned.
--
/------------------------------------------=-------------------------------\
| Nick Lawes (South Bank Polytechnic, UK) | | ..mcvax!ukc!idec!kbsc!lawesn |
| "Where are my peril sensitive glasses?" | | Phone +44 1 928 8989 ex 2328 |
\------------------------------------------=-------------------------------/hallett@macbeth.steinmetz (Hallett) (05/21/87)
I apologize to everyone who doesn't care about this. I found myself unable to respond directly to the address below. For some reason it came back. Oh, well. If Nick will send me mail directly, perhaps I can reply with more info. In article <623@SouthBank.UUCP> lawesn@SouthBank.UUCP (Nick Lawes) writes: > >Request for information from designers/developers >of object oriented systems: > >The idea is to structure information about the target system at the earliest >possible stage. > First, I salute him on his approach. An excellent idea and very sound software engineering. > > + what kind of approach did you take to the design of your system. > + how did you select your classes. > + how did you manage inheritance in your system. > + did you make use of the model-view-controller paradigm. > + based on your experience, how would you approach the same problem > if you had to start all over again. > There are several sources of O.O. design principles now on the market. If Nick writes me, I will be glad to relate those (if ANYONE writes ...). One in particular advanced here goes something as follows: 1. Identify the data abstractions for each subsystem. Most OO systems are obviously OO systems, ie. the majority of the objects come straight from the requirements document and the rest are often discovered when working in a top-down manner (refining). These objects are usually physical components of the system, but sometimes, pseudo-objects or "control objects" must be introduced. 2. Identify the attributes of each abstraction. Again, there are obvious ones, but only after refining the design will more become apparent. 3. Identify the operations (methods) for each abstraction. 4. Identify the communication between the abstractions. This involves identifying the messages required to activate the methods of #3. 5. TEST the design with scenarios. This is the refining step mentioned above. Draw pictures do what ever is necessary to act out situations. This is where the designer tests if the system is matching the requirements. Often, these scenarios will point out objects, attributes and messages that are missing. 6. Apply inheritance. Collapse classes that share attributes. Don't attempt to do this immediately unless it is terribly obvious. Wait until all the objects are established and then compare them to find similarities. 7. REITERATE. (Obviously... 8=)) I'm not an expert and don't claim to be. I've just done some of this and this method works well for me. A rule of thumb I live by is that solutions suggest implementations. Don't try to force O.O. just because it is a good buzz-word. If you design suggests O.O. then do it; if it looks like O.O will only give you problems, throw it out. This goes for language choice, data structures and other things as well. One last note -- when doing scenarios, it is important to enact them as stupidly as possible. I mean that you shouldn't read in information from your point of view. You know more than the objects in the system, so don't assume they know things. Act it out entirely from their point of view, working with only what they know. This is the most difficult thing to do and takes the most care and practice. It is also where many O.O. systems go wrong in designing. Sorry about the long-windedness. Again, if you have flames, send them to me. Let's not be stupid like me and tie up the net debating ;-). I have further references for interested people. Jeffrey A. Hallett (hallett@ge-crd.arpa hallett@desdemona.uucp) Software Technology Program General Electric Corporate Research and Development ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The needs of the few outweigh the needs of the many" -- Kirk (STIII) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: My opinions do not represent my employer's, but it is his fault for giving me this thing. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~