soft-eng@MITRE.MITRE.ORG (Alok C. Nigam) (08/08/89)
------- Forwarded Message
Received: from CALSTATE.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 2303; Thu, 03 Aug 89 16:15:37 EDT
Received: by CCS.CSUSCC.CALSTATE.EDU from Mail by CSUMailer (1.3);
Thu, 3 Aug 89 13:16:15 PDT
Date: Thu, 03 Aug 89 13:15:42 PDT
From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
Subject: Re: Attempts to connect SA/D and OOPS(2)
To: soft-eng
Cc: <PAAAAAR> (Dick Botting), <SBAILIN@NSSDCA.GSFC.NASA.GOV>
There has been some recent discussion on the soft-eng mailing list
The Communications of the ACM have published a paper
that has specific proposals for a modification to DFDs etc
that makes them more suitable for object-oriented programming.
(CACM May 1989, Volume 32, Number 5, pp608-623)
"An Object-Oriented Requirements Specification Method"
by Sidney C. Bailin <SBAILIN@NSSDCA.GSFC.NASA.GOV>
(CACM May 1989, Volume 32, Number 5, pp608-623)
Abstract
"Analyzing requirements for Object Oriented Software is examined in an
alternative methodology from the more standard structred analysis approach.
Through parallel processes of decomposing objects and allocating functions,
the method is explained in detail".
Review
This excelent paper makes a clear distinction between Structured Analysis(SA)
(organised by function) and an object oriented(OO) design (organised by data)
and argues for the replacement of SA by OO at the requirements stage.
As an example he shows that SA separates the reading, sorting,
and writing of some data into separate processes and a data store,
whereas an OO structure gathers these inside an object with
three actions and some data.
The 2 approaches have been recognised since Parnas's original papers on
decomposing programs into modules was published in the 60s and/or 70s.
The author presents and illustrates a step by step methodology for designing
systems.
He replaces Entity-Relationship-Attribute
(ERA) diagrams by simpler Entity-Relation-Diagram(ERD).
He also proposes changing DFDs to an EDFDs (Entity-Data-Flow-Diagrams) which
show the types of entity and how dat flows between them.
He makes clear the existance of strong rules of correspondence that will
hold in a correct OO design:
External entities --- Internal Objects
ERA Entity --- EDFD Entity
ERA Rel ation --- EDFD Flow
He has a program to check these rules.
He notes (p619) that a common problem in Structured Analysis(SA) is naming
some processes since fuzzy names like "control", "manage", "handle", "monitor"
are discouraged or even verbotten. He claims that such "processes" are
actually entities in disguise.
He argues that they should be shown as
objects that automatically and invisibly keep their state up to date.
In my opinion this paper marks the conscious acceptance of ideas that
have been repressed by the hierachical and sequential paradigm that
has been the prevailing doctrine since the late 60s. Possibly we should
go further - subsume relations as entities (as in SSADM) and removing
ALL processes from DFDs.
This paper is required reading for anyone wanting to keep up
with Software Engineering.
Dick Botting
CSUSB
------- End of Forwarded Messageeberard@ajpo.sei.cmu.edu (Edward Berard) (08/08/89)
In article <8908071747.AA03249@mitre.arpa>,SBAILIN@NSSDCA.GSFC.NASA.GOV (Dick Botting) writes: > > There has been some recent discussion on the soft-eng mailing list > > The Communications of the ACM have published a paper > that has specific proposals for a modification to DFDs etc > that makes them more suitable for object-oriented programming. > > "An Object-Oriented Requirements Specification Method" > by Sidney C. Bailin <SBAILIN@NSSDCA.GSFC.NASA.GOV> > (CACM May 1989, Volume 32, Number 5, pp608-623) > > Abstract > "Analyzing requirements for Object Oriented Software is examined in an > alternative methodology from the more standard structred analysis approach. > Through parallel processes of decomposing objects and allocating functions, > the method is explained in detail". > > Review > This excelent paper makes a clear distinction between Structured Analysis(SA) > (organised by function) and an object oriented(OO) design (organised by data) ^^^^ Please, object-oriented systems do _not_ organize by data. Objects encapsulate: - knowledge of state information (which may deal with "data," but is more likely to be concerned with objects) - operations (and their associated methods) - [optionally] other objects, i.e., you may have: - homogeneous composite objects - heterogeneous composite objects - [optionally] exceptions - [optionally] constants - concepts To say that "objects are data" is like saying "people are houses." Houses may contain people, but people and houses are decidedly different. Some people begin to migrate away from a functional viewpoint, an towards an object-oriented viewpoint, by saying something equivalent to: "Systems are made up of objects and functions. Since functions do not appear to be objects, I guess data must be objects." The next stage is often the improved, but still not correct: "Objects are functions and data together." Sometimes you hear all kinds of strange things such as: "data objects," "function objects," and "controller objects." These are usually the result of people trying to reconcile their functional outlook with objects, e.g., since data is passive (inert) and objects are data (or highly data-like), objects must be passive -- but then, how does work get done? > and argues for the replacement of SA by OO at the requirements stage. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I very much agree. > As an example he shows that SA separates the reading, sorting, > and writing of some data into separate processes and a data store, > whereas an OO structure gathers these inside an object with > three actions and some data. This seems strange from an object-oriented point of view, because: - Reading is a composite operation involving several objects (the input object, the actual object being read, and at least one other object), see, e.g., the discussions on "objectification" on comp.lang.ada, comp.lang.c++, and others. - Sorting is also a composite operation, involving the object being sorted and the composite object which contains these objects, and operations from both classes. - The same is true for the writing operation. At best, you will have a massive amount of undesirable "object coupling." Reusability and software reliability will be diminished. > The 2 approaches have been recognised since Parnas's original papers on > decomposing programs into modules was published in the 60s and/or 70s. D.L. Parnas's paper ("On the Criteria To Be Used In Decomposing Systems Into Modules," Communications of the ACM, Vol. 5, No. 12, December 1972, pp. 1053-1058) Was a landmark paper which emphasized "information hiding." Information hiding is probably one of the most fundamental tenets of object-oriented thinking, e.g., "objects are black boxes." > The author presents and illustrates a step by step methodology for designing > systems. > He replaces Entity-Relationship-Attribute > (ERA) diagrams by simpler Entity-Relation-Diagram(ERD). > He also proposes changing DFDs to an EDFDs (Entity-Data-Flow-Diagrams) which > show the types of entity and how data flows between them. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Object-oriented systems don't have "data" flows. If the concept of something flowing is important to you, you can talk about "object flows," although this would seem strange to some object-oriented folks. > He makes clear the existance of strong rules of correspondence that will > hold in a correct OO design: > External entities --- Internal Objects > ERA Entity --- EDFD Entity > ERA Relation --- EDFD Flow > He has a program to check these rules. I appreciate the effort that has been expended, but I have to ask, "What does any of this have to do with an object-oriented approach?" > He notes (p619) that a common problem in Structured Analysis(SA) is naming > some processes since fuzzy names like "control", "manage", "handle", "monitor" > are discouraged or even verbotten. He claims that such "processes" are > actually entities in disguise. I strongly agree that names like "control", "manage", "handle", and "monitor" are fuzzy and should be discouraged. I would have a hard time agreeing with calling such "processes," "entities in disguise." They may be "large composite operations accomplished by a system of cooperating objects." > He argues that they should be shown as > objects that automatically and invisibly keep their state up to date. There is some truth to this. Somewhere within the "system of cooperating obejcts" there is very likely at least one "object with life," i.e., an object which is capable of spontaneously changing its own state. Objects with life (also known as "active objects," and "actor objects") do "automatically and invisibly" alter their state. ("Keeping the state up to date" is anohter discussion entirely.) > In my opinion this paper marks the conscious acceptance of ideas that > have been repressed by the hierachical and sequential paradigm that > has been the prevailing doctrine since the late 60s. Possibly we should > go further - subsume relations as entities (as in SSADM) and removing > ALL processes from DFDs. I find this a strange, but interesting analysis. I would dismiss the recommendation, and suggest that people consider adopting an object-oriented approach. > > This paper is required reading for anyone wanting to keep up > with Software Engineering. It is my opinion (and, yes, I know I'm biased) that this article will do more to confuse people attempting to understand what object-oriented thinking is all about, more than it will help them. I can offer a piece of advice to those attempting to understand what an object-oriented approach is. You will usually find two kinds of people: those who have developed a number of systems in a funtional decomposition manner, and those who have written code using a so-called object-oriented programming language. Some of these people actually understand what an object-oriented approach is all about. However, watch out for the following people: - The people with the functional decomposition background who often describe what their "fantasy" of an object-oriented system or approach might be. These people have usually not done much reading on the topic, and often provide their own interpretations of what object-oriented buzzwords mean. They tend to freely mix concepts from a number of different paradigms, e.g., data flow diagrams and objects. - People who have written code in an object-oriented programming language are often unable to separate concepts from implementations, e.g., they seem unable to discuss anything without talking about how it is done in programming language X. Some of these people claim that methodolgies are harmful, and that an object-oriented approach obviates the need for methodologies. > Dick Botting > CSUSB -- Ed Berard (301) 353-9652
goss@ese.essex.ac.uk (Gossain Sanjiv) (08/08/89)
In a recent posting, <538@ajpo.sei.cmu.edu> Edward Berard comments: Topic: (CACM May 1989, Volume 32, Number 5, pp608-623) "An Object-Oriented Requirements Specification Method" by Sidney C. Bailin <SBAILIN@NSSDCA.GSFC.NASA.GOV> >> As an example he shows that SA separates the reading, sorting, >> and writing of some data into separate processes and a data store, >> whereas an OO structure gathers these inside an object with >> three actions and some data. > This seems strange from an object-oriented point of view, because: > - Reading is a composite operation involving several objects > (the input object, the actual object being read, and at > least one other object), see, e.g., the discussions on > "objectification" on comp.lang.ada, comp.lang.c++, and > others. > > - Sorting is also a composite operation, involving the object > being sorted and the composite object which contains these > objects, and operations from both classes. > > - The same is true for the writing operation. > > At best, you will have a massive amount of undesirable "object > coupling." Reusability and software reliability will be diminished. Yes, it seems to defeat the object (pardon the pun) to have an object oriented approach and yet still adhere to the same, inappropriate principles of a functional approach! I would agree here with Mr. Berard whole-heartedly. It seems to me that too many people try to evolve OO design methods from existing design approaches, when what is really required, IMHO, is to wipe the slate clean and start proposing design approaches that reflect the paradigm shift required when moving to OOP. Methods that arise from peoples experiences in OOD are far better than those that are derived from existing approaches. Sanjiv Gossain goss%ese.essex.ac.uk@nsfnet-relay.ac.uk ---------------------------------------------------------- Sanjiv Gossain Dept. of ESE Universtiy of Essex Colchester CO4 3SQ ENGLAND +44 206 873333 xt:2820
soft-eng@MITRE.MITRE.ORG (Alok C. Nigam) (08/12/89)
------- Forwarded Message Gossain Sanjiv <mcvax!ukc!servax0!ese!goss@uunet.uu.net> Organization: University of Essex, Colchester, UK States >It seems to me that too many people try to evolve OO design methods from >existing design approaches, when what is really required, IMHO, is to >wipe the slate clean and start proposing design approaches that reflect >the paradigm shift required when moving to OOP. Earlier in Vol 6, Issue 37, Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu> w rote >Subject: Re: Integrating SA/SD & DA/DD >Although object-oriented programming has been around (formally) for >almost twenty years, its practitioners unfortunately spent most of >their time focusing on coding and programming language issues. Until >the early 1980s very little work was done in the area of life-cycle >methodologies. Hence, we see the structured methodologists now >migrating to an object-oriented approach and bringing their largely >inappropriate methods, tools, and graphics with them. There is a problem here (1) Object Oriented Programming exists and has advantages(IMHO) (2) There is a a hefty investment in Analysis and Design Methods that don't fit Object Oriented Programming. (3) Programming technology and methodology have not (alone) consistently produced valuable pieces of software (4) Something has to be done prior to writing code. But what? In Vol 6, Issue 40, Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu> wrote: >Subject: Re: Attempts to connect SA/D and OOPS(2) >Please, object-oriented systems do _not_ organize by data. Objects >encapsulate: > - knowledge of state information (which may deal with "data," > but is more likely to be concerned with objects) > - operations (and their associated methods) > - [optionally] other objects, i.e., you may have: > - homogeneous composite objects > - heterogeneous composite objects > - [optionally] exceptions > - [optionally] constants > - concepts [...] >Object-oriented systems don't have "data" flows. If the concept of >something flowing is important to you, you can talk about "object >flows," although this would seem strange to some object-oriented folks. Forgive my ignorance but is it ok to assume that in an object oriented piece of software (1) there are things that we can call 'objects' which are separated from each other. (2) separate object have some means of communication with each other. (is this always one-one by the way?) (3) designing and documenting which communications should occur might save money - in the long run. (How much? - to the programmer, the designer, the maintainer,...) Given these - what language independant ways exist for (1) Recording existing communication patterns (Ideally in 4 forms: text, mathematical, automated, and graphic) (2) Deriving patterns of communication from existing software (3) Evaluating a pattern of communication. (4) Designing a pattern suitable for given situation. Dick Botting, Department computer science, California State University, San Bernardino, CA 92407 PAAAAAR@CCS.CSUSCC.CALSTATE paaaaar@calstate.bitnet PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU ------- End of Forwarded Message
eberard@ajpo.sei.cmu.edu (Edward Berard) (08/13/89)
In article <8908120353.AA14861@mitre.arpa>, Dick Botting wrote: > > Gossain Sanjiv <mcvax!ukc!servax0!ese!goss@uunet.uu.net> > States > >It seems to me that too many people try to evolve OO design methods from > >existing design approaches, when what is really required, IMHO, is to > >wipe the slate clean and start proposing design approaches that reflect > >the paradigm shift required when moving to OOP. > > Earlier in Vol 6, Issue 37, Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu> > wrote > >Subject: Re: Integrating SA/SD & DA/DD > >Although object-oriented programming has been around (formally) for > >almost twenty years, its practitioners unfortunately spent most of > >their time focusing on coding and programming language issues. Until > >the early 1980s very little work was done in the area of life-cycle > >methodologies. Hence, we see the structured methodologists now > >migrating to an object-oriented approach and bringing their largely > >inappropriate methods, tools, and graphics with them. > > There is a problem here > (1) Object Oriented Programming exists and has advantages(IMHO) > See, for example, some of the recent discussions I and Ralph Johnson have had on comp.lang.smalltalk. > (2) There is a a hefty investment in Analysis and Design Methods that > don't fit Object Oriented Programming. I recognize this as a real problem. Say, for a minute, you believe two things. First, that an object-oriented approach provides many worthwhile benefits _when_ _correctly_ _and_ _properly_ _applied_. Second, that an object-oriented approach is a significant departure from the more traditional (e.g., functional decomposition) approaches. So much so, that very little can be migrated from the traditional to the object-oriented. You now have a very typical "real world" problem on your hands. Do you continue to use inappropriate techniques, methods, and tools with the new technology, thereby both minimizing the promised benefits, and lengthening the time (and thus the costs) for the transition, or do you make a clean (and what may be costly) break? This is something that software people usually don't do, or don't do very well, i.e., make a meaningful assessment of costs of each alternative. Consider the following simple (incomplete and not very detailed) cost comparison: 1. Cost to acquire current technology: - training costs - hardware (e.g., workstations) costs - CASE software costs - hiring costs - costs to develop in-house policies, procedures, standards, guidelines, bidding and estimating strategies, and in-house training - consulting costs - cost for conferences 2. Cost to acquire the new technology: - all of the above costs - cost of creating and executing a transition plan 3. Quantification of cost benefits of new technology, i.e., cost savings per period of time. 4. Payback period estimation, i.e., the length of time before the new technology will actually pay for itself. 5. The impact, both positive and negative, of not moving to the new technology immediately. Note that, in this analysis, costs are not only financial costs. There are human costs, corporate image costs, and corporate capability costs. There are hidden psychological costs. For example, being in the technology transition business, I frequently hear things like: - I don't trust this new stuff. Therefore I'm going to act like I'm using it, but I'm really going to keep doing things the way I always have done them. - I really like this new technology, but management insists that we use inappropriate tools, techniques, and procedures, simply because they have made such a large investment in these items. I'm looking for a new job, i.e., one that will let me use the new technology in the right way. - I don't know. All these technologies are the same. You just get comfortable with one when a new one comes along. We don't get any work done here. We just change technologies. > (3) Programming technology and methodology have not (alone) > consistently produced valuable pieces of software Human beings, as a rule, have a great deal of difficulty differentiating between a bad idea, and a bad implementation of a good idea. Further, few people willing accept blame. So when something goes wrong, inanimate objects (e.g., programming languages, methodologies, and standards) are easy targets for blame. In essence, one of the hardest things for someone involved in a technical activity to do is to recognize the human part of the technology. Ask any one who has ever attempted to educate or train two, or more, people. Not everyone is equally capable. Of all the items which have an impact on the success or failure of a project, people have, by far, the largest impact. However, good people with poor tools are not as productive as good people with good tools. Yet, this is not enough. To get maximum benefits we must consider the whole picture, i.e., good people, good tools, good methodologies, good standards, good management, good training, etc. > (4) Something has to be done prior to writing code. But what? Here we begin to differentiate between computer science and software engineering. One of the things an engineer must do is to take the knowledge provided by the scientist, and apply it in a practical manner to everyday, "real world" problems, to produce cost-effective, pragmatic solutions. There are many different life-cycle models, e.g.: - flowchart model - sequential waterfall - iterative waterfall - b-model - spiral - recursive/parallel Each of these models is further divided into steps (stages). Some of these life-cycle models provide more than one place where coding can occur. However, to keep things simple, let's use traditional terms: 0. Going on in parallel with the life-cycles of many different software products, is object-oriented domain analysis (OODA). 1. Ignoring the (real) possibility of a feasibility study, one might begin with object-oriented requirements analysis (OORA). 2. There is, of course, object-oriented design (OOD). 3. Object-oriented implementation or coding is often referred to as object-oriented programming (OOP). Please note that OORA is _not_ merely structured analysis (SA) with a few object-oriented terms, nor is object-oriented design a variation on structure design (SD). To oversimplify, object-oriented software engineering involves: - Identifying relevant objects and classes - Documenting these objects and classes - Applying configuration management to the objects and classes of interest. - Producing both static and dynamic object-oriented models of the system. [I would very much like to avoid a detailed discussion of the processes involved with OORA, OOD, and OODA, although I have detailed, e.g., 600 slides worth of OORA, presentations on each.] > In Vol 6, Issue 40, Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu> wrote: > >Subject: Re: Attempts to connect SA/D and OOPS(2) > >Please, object-oriented systems do _not_ organize by data. Objects > >encapsulate: > > - knowledge of state information (which may deal with "data," > > but is more likely to be concerned with objects) > > - operations (and their associated methods) > > - [optionally] other objects, i.e., you may have: > > - homogeneous composite objects > > - heterogeneous composite objects > > - [optionally] exceptions > > - [optionally] constants > > - concepts > [...] > >Object-oriented systems don't have "data" flows. If the concept of > >something flowing is important to you, you can talk about "object > >flows," although this would seem strange to some object-oriented folks. > > Forgive my ignorance but > is it ok to assume that in an object oriented piece of software > (1) there are things that we can call 'objects' > which are separated from each other. This is true. There are also things like classes, systems of objects, and subsystems. > (2) separate object have some means of communication with each other. > (is this always one-one by the way?) There are many mechanisms by which objects can communicate. Smalltalk, for example, allows objects to "pass messages" in all directions. If you wish you can generalize the "message passing" concept. However, remember that messages are themselves composite objects. > (3) designing and documenting which communications should occur might > save money - in the long run. > (How much? - to the programmer, the designer, the maintainer,...) Documenting the interactions of objects, including how they exchange information, is important. However, things like "data flows" don't don't make sense in an object-oriented approach. One technique that is roughly equivalent is an "object-message diagram." This documents flows of messages among objects. > > Given these - what language independent ways exist for > (1) Recording existing communication patterns > (Ideally in 4 forms: text, mathematical, automated, and graphic) Before I begin to answer these questions, I must point out the following: - In addition to communication among objects, we must also provide a mechanism to describe the composition of a given object. - We must also have a mechanism for describing the dynamic behavior of the object - Any and all mechanisms must be object-oriented. One technique for representing the behavior of an object-oriented system is a Perti net graph. The "places" on the Petri net graph, e.g., represent objects in specific states. What is interesting about Petri net graphs is that they are often used to model systems, however, the arcs (edges) do not indicate flow of data or control. Specifically, you can represent a system of interacting (i.e., communicating) objects without showing communication in the conventional sense, i.e., "flowing" along the arcs. > (2) Deriving patterns of communication from existing software This depends on how the software was created. If the software was implemented using a functional decomposition technique, then data and control flows would most accurately reflect the intentions of the initial designers. Attempting to represent this software in terms of interacting objects is both difficult and confusing. > (3) Evaluating a pattern of communication. One of the key criteria for evaluating a "pattern of communication" is how consistent it is with the overall approach. For example, if the approach talks about objects, the pattern should also talk about objects. If the approach talks about functions, then the pattern should talk about functions. > (4) Designing a pattern suitable for given situation. I have a question. Must this "pattern of communication" be explicit or implicit? For example, in data flow diagrams the communication is explicit, i.e., via labeled edges. In Petri net graphs, the communication is implicit, i.e., derived from context. > > Dick Botting, > Department computer science, > California State University, San Bernardino, CA 92407 > > PAAAAAR@CCS.CSUSCC.CALSTATE > paaaaar@calstate.bitnet > PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU -- Ed Berard (301) 353-9652
nigam@MWSUN.MITRE.ORG (Alok Nigam) (08/15/89)
Date: Fri, 11 Aug 89 11:03:08 PDT From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU Subject: Re: Attempts to connect SA/D and OOPS Gossain Sanjiv <mcvax!ukc!servax0!ese!goss@uunet.uu.net> Organization: University of Essex, Colchester, UK States >It seems to me that too many people try to evolve OO design methods from >existing design approaches, when what is really required, IMHO, is to >wipe the slate clean and start proposing design approaches that reflect >the paradigm shift required when moving to OOP. Earlier in Vol 6, Issue 37, Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu> w rote >Subject: Re: Integrating SA/SD & DA/DD >Although object-oriented programming has been around (formally) for >almost twenty years, its practitioners unfortunately spent most of >their time focusing on coding and programming language issues. Until >the early 1980s very little work was done in the area of life-cycle >methodologies. Hence, we see the structured methodologists now >migrating to an object-oriented approach and bringing their largely >inappropriate methods, tools, and graphics with them. There is a problem here (1) Object Oriented Programming exists and has advantages(IMHO) (2) There is a a hefty investment in Analysis and Design Methods that don't fit Object Oriented Programming. (3) Programming technology and methodology have not (alone) consistently produced valuable pieces of software (4) Something has to be done prior to writing code. But what? In Vol 6, Issue 40, Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu> wrote: >Subject: Re: Attempts to connect SA/D and OOPS(2) >Please, object-oriented systems do _not_ organize by data. Objects >encapsulate: > - knowledge of state information (which may deal with "data," > but is more likely to be concerned with objects) > - operations (and their associated methods) > - [optionally] other objects, i.e., you may have: > - homogeneous composite objects > - heterogeneous composite objects > - [optionally] exceptions > - [optionally] constants > - concepts [...] >Object-oriented systems don't have "data" flows. If the concept of >something flowing is important to you, you can talk about "object >flows," although this would seem strange to some object-oriented folks. Forgive my ignorance but is it ok to assume that in an object oriented piece of software (1) there are things that we can call 'objects' which are separated from each other. (2) separate object have some means of communication with each other. (is this always one-one by the way?) (3) designing and documenting which communications should occur might save money - in the long run. (How much? - to the programmer, the designer, the maintainer,...) Given these - what language independant ways exist for (1) Recording existing communication patterns (Ideally in 4 forms: text, mathematical, automated, and graphic) (2) Deriving patterns of communication from existing software (3) Evaluating a pattern of communication. (4) Designing a pattern suitable for given situation. Dick Botting, Department computer science, California State University, San Bernardino, CA 92407 PAAAAAR@CCS.CSUSCC.CALSTATE paaaaar@calstate.bitnet PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
nigam@MWSUN.MITRE.ORG (08/25/89)
------- Forwarded Message
Received: from CALSTATE.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 1641; Thu, 17 Aug 89 20:49:13 EDT
Received: by CCS.CSUSCC.CALSTATE.EDU from Mail by CSUMailer (1.3);
Thu, 17 Aug 89 17:40:38 PDT
Date: Thu, 17 Aug 89 17:40:24 PDT
From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
Subject: Re: Attempts to connect SA/D and OOPS
To: soft-eng
Cc: <PAAAAAR> (Dick Botting), <PWROSS@MILLERSV>
(Resend - Previous version probably garbled or lost...)
In Vol 6 Number 42, Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu> 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 existance 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.
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 Petrie 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` occrences 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?
How many real projects have used Petri Nets?
How do you communicate a Petri Net over the network?
He asks
>Must this "pattern of communication" be explicit or
>implicit.
I was trying to define important Entities and Relationships in
OO Software Engineering - in particular searching for the Relationships betwee
n
Objects that it would be helpful to have on record.
I would claim that technical drawing is a standard way to show the
boundaries of mechanical objects and to make explicit how they touch.
Babbage invented a diagram to help him simplify his
Analytical Engine - one part made explicit how parts were
connected. Electrical Engineers have explicit lines connecting objects
in a circuit diagram.
I was thinking along these lines:
If I've got the task of changing an object-oriented system
what I need to do is to find out what objects
could cause the observed problems and which could not. Afterall
doctors have anatomy diagrams and X-rays that make explicit the connections
implicit in the body. If there was accessible and explicit documentation of
what classes of objects can influence other classes - my maintenance task
should be easier...
Or suppose if you are working on an Object-oriented system for my bank,
I will want to be certain
that the object representing the customer's money is isolated
from other "customers" and from the programmer/designer except under
specific and explicit circumstances. I want evidence that the system
will not do the Salami Trick!
However I think DFDs are a comparatively uneconomic representation. I'd
like to test the N-squared chart developed in TRW some years ago.
These naturally map any set (nodes) and pairwise `relations` into
a matrix with clearly visible connections and or boundaries.
(They also take up a lot of space)
Dr. Richard J. Botting,
Department of computer science,
California State University, San Bernardino,
CA 92407
PAAAAAR@CCS.CSUSCC.CALSTATE
paaaaar@calstate.bitnet
PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
------- End of Forwarded Messageeberard@ajpo.sei.cmu.edu (Edward Berard) (09/06/89)
In article <PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU>, Dick Botting writes: > In Vol 6 Number 42, Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu> 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