taso@munnari.oz (Taso Hatzi) (03/21/88)
I am seeking comment on the following questions from people who have had success with any object oriented design methodology. o What design documentation did you need and what form did it take? o What characterizes a properly designed system? o Do there exist any well known object oriented design methodologies?
des@jplpro.JPL.NASA.GOV (David Smyth) (03/31/88)
In article <2045@munnari.oz> taso@munnari.oz (Taso Hatzi) writes: > >I am seeking comment on the following questions from people who have >had success with any object oriented design methodology. we are currently using ood for a system which in the past has been very large and complex. At this stage in the design everything looks rather straight- forward, I am hoping for success! > > o What design documentation did you need and what form did it take? The requirements were collected from lots of people with experience at doing what the new system is supposed to support (programming unmanned spacecraft, in this case). The requirements were documented in whatever manner seemed effective to the req author, and were not in any way "object oriented" - confused along the line of "structured design" if anything. The design documents have an outline like this: abstract 1.0 intro 1.1 references 1.2 bs to meet documentation standards 2.0 informal discussion of the problem, sort of an object-oriented requirements. 3.0 formal specification of the objects identified and discussed casually in section 2. For each object: 3.x.1 Methods (functions, operators) 3.x.2 Attributes (public data) We are still developing the documentation. For example, people are still not clear on what is class data, and instance data from the list of Attributes. It makes a big difference when people start implementing the objects. Also, the section numbers start getting too long when we try and represent the inheritance of classes within the document structure. I have started just using .NH 3 only, because a fully hierarchical numbering system precludes multiple inheritance, and we need multiple inheritance. We have 2 layers of these design documents. One for a "system" and one fort each of the objects in section 3: 3.x would go into one object design doc, 3.y goes into another. > > o What characterizes a properly designed system? Does it work? Is it easy for people to understand? Does it do what the requirements people REALLY need (not just what they wrote, which is usually an improper subset of the ACTUAL requirements). > > o Do there exist any well known object oriented design methodologies? 1. understand the problem however you need to. 2. figure out the general objects required, and what look like (attrs), what they act like (methods). 3. formally list and describe the attrs and methods for each object. 4. implement the objects, most general first, most specific last.
djones@megatest.UUCP (Dave Jones) (03/31/88)
in article <1711@devvax.JPL.NASA.GOV>, des@jplpro.JPL.NASA.GOV (David Smyth) says: > > In article <2045@munnari.oz> taso@munnari.oz (Taso Hatzi) writes: >> >>I am seeking comment on the following questions from people who have >>had success with any object oriented design methodology. > [...] >> >> o Do there exist any well known object oriented design methodologies? >> > > 1. understand the problem however you need to. > 2. figure out the general objects required, and what look like (attrs), > what they act like (methods). > 3. formally list and describe the attrs and methods for each object. > 4. implement the objects, most general first, most specific last. ^^^^ ^^^^^^^ ^^^^^ ^^^^ ^^^^^^^^ ^^^^ > [...] I quite agree. But this statement can be misinterpreted. So let me rephrase it, "Implement the classes, in a bottom-up (not top-down!) order." Or stated another way, "Implement base-classes and so-called 'library classes' first. Then do the derived classes and high-level classes." That is what you meant, right? -- HERASY ON -- The "top-down design" philosophy goes hand in hand with "structured design" as a means for enforcing software rigidity and closed systems. "Piecewise refinement" is the best way I know to insure that a software design is so tightly targeted at a specific set of high-level requirements, that any change will propogate changes throughout the entire system. Change something near the top of a "piecewise refined" program, and you will find that you are obliged to piecewise refine it all the way to the bottom all over again. Brad Cox said it about as well as I have heard anybody say it, in his Objective C book. I don't have the book handy, but essentially he said that the _requirements document_ is a Marginot Line behind which one may hide from the enemy: The enemy is Change. (Too bad Brad thinks he invented software libraries. Calls the library classes "software IC's", you know. I just don't have the heart to tell him otherwise.) Here's a toast to to "piecewise concretion". BOTTOMS UP! -- HERASY OFF -- Now may the incredulous rejoinders commence. I think I'll take a few days off in, oh.. say, the Peepee islands maybe. -- Dave J.
kasper@csli.STANFORD.EDU (Kasper Osterbye) (04/01/88)
Hi,
There was a guy that asked for design methodologies for software engeneering.
I know that a number of persons might not agree on my suggestion, but here it
goes:
Michael Jacson, System Development. Prentice-Hall International Inc. 1983
You will not find the word object-oriented anywhere in it, but it stresses
the importance of in finding the objects and operations on these objects
in the very first part of system development. He has a number of "rules of
thump" on what kind of objects to include, what to exclude, what kind of
actions to look out for and pitfalls in general.
He do NOT give any hint on how to organize your objects into a class hierarchy.
His methodology has a number of stages, with the implementation being the
last. With the arrival of o-o architectures, this last part of the book might
not be that relavant anymore.
check it out, said the wise student who have never done programming in the
large :-)
--Kasper.
Kasper Osterbye ||| /// ///|
Internet: kasper@csli.stanford.edu ||| /// ///||
UUCP: {backbones..}!csli.stanford.edu!kasper |||<<< ///|||
AT&T: (415) 323 9604 ||| \\\ ///=|||
USMAIL: 2420 Tasso st. #3, Palo Alto CA 94301 ||| \\X// |||MIGA