Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!bse.com!eberard From: eberard@bse.com (Edward V. Berard) Newsgroups: comp.object Subject: Re: OOA/OOD - identifying objects (easy?) Summary: JSD, ER Diagrams and an OO approach are not a good mix Keywords: JSD, ER Diagrams, OOD/OOA Message-ID: <0B010001.5knuhj@bse.com> Date: 22 Nov 90 16:36:20 GMT Reply-To: eberard@bse.com Organization: Berard Software Engineering, Inc. Lines: 210 X-Mailer: uAccess - Mac Release: 1.0.1c In article <8235@star.cs.vu.nl>, leendert@cs.vu.nl (Leendert van Doorn) writes: > > I'm posting the following message for my girlfriend. > Please reply using e-mail, I'll summarize if appropriate. > > --------------------------------------------------------------------------- > Dear Netlanders, > > I'm working on a project to integrate OOA/OOD into existing development > methods and tools. One of the (main) problems is the identification of > objects. Luckily some methods are available that enable me to identify > these objects (I've narrowed my research down to ER [Entity Relation > modeling], and JSD [Jackson Structured Development]). The general idea > is that these methods provide me with a list of objects, even though > they use different approaches at obtaining this list. > > However, examining both methods I came across the following problem: > Using JSD I'm able to uncover objects and the actions belonging to > these objects. On the other hand, using ER I'm able to uncover the > structure of the objects and the relationship among them (ER uncovers > inheritance and aggregations). For my project I would like to combine > the advantages of these two methods (thus creating a method that > enables me to find the objects, their relations, and actions all > together at once). The problem that becomes apparent is the following: > do both methods uncover the same objects. For example, if JSD uncovers > n objects, does ER uncover the same n objects ? I've tried some > examples and it seems to me that they do, but before I pursue this > matter any further I would like a second opinion. > > Thanks, > Judith van Rijt > --------------------------------------------------------------------------- I think you will have problems with both JSD and ER when attempting to use them with an object-oriented approach. Let me focus on JSD. (If I have time, I will get to the problems with ER and an object-oriented approach in another message.) What follows is the text of an earlier message regarding JSD and object-oriented approaches: |Paul S. R. Chisholm (psrc@pegasus.ATT.COM) writes: | | I've been reading a book called SYSTEM DEVELOPMENT | (Prentice-Hall International, 1983, ISBN 0-13-880328-5) by | Michael Jackson. No, not the pop singer; the author of | PRINCIPLES OF PROGRAM DESIGN and the "Jackson method" (what | Jackson calls JSP). His latest development, JSD, has a *lot* | of bits that sound like object-oriented design. His first | step is to model this system, and to identify "entities" (what | lots of us would call objects) and "actions". | |[...] ... | | But there *is* some value to be gained from this book, and | with that caveat, I recommend it. Anyone else have opinions on | this, or some other method, that could help us develop an | object-oriented method of developing software? | |Before, I say anything else, I would like to inform everyone that |there are literally hundreds of articles on "object-oriented design," |and an ever increasing number of articles on other object-oriented |methodologies. I will discuss some of these in another article. | |Now, let me shift the focus back to Jackson's methodologies. I first |encountered Jackson Structured Programming (JSP) in 1979. Jackson's |book ([Jackson, 1975]) was very interesting, but lacked an index, |making it difficult to use. More than one of my contemporaries noticed |a good deal of superficial similarities between Jackson's work and |that of Jean-Dominique Warnier (Logical Construction of Programs). | |Later, in about 1984, when many of us were looking for a suitable |"front end" to Grady Booch's object-oriented design (OOD) approach, |Jackson System Development (JSD) at first appeared attractive. After |all, he did talk about "entities" which sounded like "objects." |However, we found that the method is not as suitable for |object-oriented development as we had once hoped. (Although, see [Reed |and Bynum, 1989] and [Birchenough and Cameron, 1988] for an opposing |view.) | |What problems did I have? Let me list a few: | | - JSD is much more of a "modeling approach" than it is an | "object-oriented approach." Users of the methodology create | time-based models of "real world" entities and then create | models of their "real world" interactions. Notice that in | object-oriented approaches, objects (and classes) are not | designed based on their histories (life-cycles) in a | particular application, but rather on the characteristics of | the object (class) in isolation. [The life-cycle of an | object (class) in an application is often used to suggest | the characteristics of an item.] | | - The "quasi-object-oriented" systems produced using JSD | tended to have highly coupled and weakly cohesive objects | (classes). This had a very negative impact on both the | reusability, and the reliability of the objects (classes) in | the system. To be fair, if reuse was not a priority, and you | chose not to view entities as objects, JSD did present a | very attractive alternative to the usual structured | approaches. | | - There is very little to support conventional | "object-oriented thinking" in JSD, e.g., no mention of | inheritance (or delegation, for that matter), data | abstraction, information hiding, or encapsulation. | |In the end, after several attempts to merge object-oriented approaches |and JSD, we gave up. | |However, "a good engineer is a 'thief' [of technology]." I found much |to like in JSD, and I have incorporated many of its concepts into my |object-oriented methods, e.g.: | | - JSD is _very_ real time oriented. Jackson brings up many | points which are missed by designers of real time | methodologies. For example, andy real time system must be | connected to the outside world in some manner. JSD provides | at least two mechanisms for doing this: "data streams" and | "state vectors." | | - The separation of "process texts" and "state vectors" forces | one to consider abstraction, and could result in a | significant savings in both source code, and memory | requirements. | | - Concurrency is the norm in JSD. If you have a lot of | distributed and/or parallel processing going on, you should | take a look at the issues raised in JSD, e.g., assigning | processes to processors, synchronization, and scheduling. | | - Unnecessary parallelism in JSD can be removed by a process | called "inversion." (There are actually several different | types of inversion.) In deciding whether to use inversion, | and which form to use, you bring up many issues which are | very similar to those raised when deciding which objects | should send messages to which other objects, i.e., "where do | you put the 'intelligence.'" | |Overall, I would say that JSD is worth studying. However, there are |better ways to deal with object-oriented development. If you do look, |make sure that you first consider references dated 1983, or newer. | | POINTS OF CONTACT | |Jackson Systems Corp., 860 Prospect Hill Road, Windsor, Connecticut |06095, Phone: (203) 683-1976, FAX: (203) 688-3025. | |European Offices: Michael Jackson Systems, Ltd., London, U.K. : Sorry, |I do not have an address, and the phone number I have is very old. | | BIBLIOGRAPHY | |[Birchenough and Cameron, 1988]. A. Birchenough and J. R. Cameron, |"JSD and Object-Oriented Design," Michael Jackson Systems Limited, |London, 1988, in [Cameron, 1989]. | |[Cameron, 1983]. J.R. Cameron, Editor, JSP and JSD: The Jackson |Approach to Software Development, IEEE Computer Society Press, |Washington, D.C., 1983. | |[Cameron, 1986]. J.R. Cameron, "An Overview of JSD," IEEE Transactions |on Software Engineering, Vol. SE-12, No. 2, February 1986, pp. 222 - |240. | |[Cameron, 1989]. J.R. Cameron, Editor, JSP and JSD: The Jackson |Approach to Software Development, Second Edition, IEEE Computer |Society Press, Washington, D.C., 1989. | |[Hughes, 1979]. J. W. Hughes, "A Formalization and Explication of the |Michael Jackson Method of Program Design," Software Practice and |Experience, Vol. 9, 1979, p. 191 - 202. | |[Jackson, 1975]. M. A. Jackson, Principles of Program Design, |Academic Press, New York, New York, 1975. | |[Jackson, 1976]. M.A. Jackson, "Constructive Methods of Program |Design," Proceedings of the First Conference of European Cooperation |in Informatics, Vol. 44, 1976, pp. 236 - 262. | |[Jackson, 1983]. M. A. Jackson, System Development, Prentice-Hall, |Englewood Cliffs, New Jersey, 1983. | |[King, 1988]. D. King, Creating Effective Software: Computer Program |Design Using the Jackson Methodology, Yourdon Press, A Prentice-Hall |Company, Englewood Cliffs, New Jersey, 1988. | |[Martins and Veloso, 1985]. R.C.B. Martins and P.A.S. Veloso, |"Jackson's Method for Programme Construction: Year 9," Proceedings of |the Third International Workshop on Software Specification and Design, |August 1985, IEEE Catalog No. 85 CH2138-6, IEEE Computer Society |Press, Washington, D.C., pp. 155 - 158. | |[Masiero and Germano, 1988]. P. C. Maserio and S.R. Germano, "JSD as |an Object-Oriented Design Method," ACM SIGSoft Software Engineering |Notes, Vol. 13, No. 3, July 1988, pp. 22 - 23. | |[Reed and Bynum, 1989]. G.P. Reed and Donald E. Bynum, "Analyzing |Systems for Object-Oriented Design," Proceedings of the Sixth |Washington Ada Symposium, June 26-29, 1989, pp. 195 - 200. | |*** There are many more references on both JSD and JSP. I could only |*** list a few. ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------