leendert@cs.vu.nl (Leendert van Doorn) (11/14/90)
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 --------------------------------------------------------------------------- -- Leendert van Doorn <leendert@cs.vu.nl> Vrije Universiteit / Dept. of Maths. & Comp. Sc. Amoeba project / De Boelelaan 1081 1081 HV Amsterdam / The Netherlands
eberard@bse.com (Edward V. Berard) (11/23/90)
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 | ----------------------------------------------------------------------------