From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,HEADER_SPAM, INVALID_DATE,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.object:1378 comp.software-eng:3845 comp.databases:6362 comp.realtime:724 comp.edu:3309 comp.lang.ada:4039 Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!bse.com From: eberard@bse.com (Edward V. Berard) Newsgroups: comp.object,comp.software-eng,comp.databases,comp.realtime,comp.edu,comp.lang.ada Subject: CFP - ECOOP/OOPSLA Workshop on Graphics for Object-Oriented Software Engineering Summary: workshop on graphics (to be) used in object-oriented software engineering Keywords: object-oriented, software engineering, graphics Message-ID: Date: 1 Jul 90 22:33:35 GMT Reply-To: eberard@bse.com Organization: Berard Software Engineering, Inc. List-Id: CALL FOR PARTICIPATION ECOOP/OOPSLA-90 Workshop on Graphics for Object-Oriented Software Engineering (GOOSE) Sunday, October 21, 1990 Ottawa, Canada Moderated by Edward V. Berard Berard Software Engineering, Inc. Graphical representations are an integral part of most software engineering processes. During analysis and design they help us to model both the problem and our potential solutions. During testing they can provide a quick visual means of generating test cases. During maintenance, well-executed graphics can guide software engineers in the repair and extension of existing systems. In fact, there are very few, if any, software engineering activities which do not benefit from some forms of graphics. Good software engineering graphics are simple, straightforward, and accurately reflect the software engineering approach (e.g., functional decomposition or object-oriented) used in their associated activity. Not surprisingly, the most familiar forms of software engineering graphics (e.g., data flow diagrams, structure charts, and flow charts) reflect the most common software engineering approach, i.e., functional decomposition. Object-oriented approaches are significantly different from the more conventional approaches. Probably the most significant difference is in how information is localized, i.e., object-oriented approaches localize information around objects, not functions or data. Other differences include: - how objects interact, which is not restricted to a simple function invocation hierarchy, - the interfaces of objects, which are not simple subroutine interfaces, and - the clear separation of information into a specification (or interface) part and a body (or internal) part. Some attempts at defining graphics for object-oriented software engineering resulted in either the direct use of, or simple extensions to, the more conventional graphics e.g., [Alabiso, 1988], [Gray, 1987], [Gray, 1988], [Reed and Bynum, 1989], and [Wasserman, 1990]. Others have resulted in newer types of graphics, e.g., [Booch, 1986], [Booch, 1990], [Coad and Yourdon, 1989], [Cunningham and Beck, 1986], [Heitz and Labreuille, 1988], [Loomis et al, 1987], [Pun and Winder, 1989], and [Vielcanet, 1989]. (It is interesting that Ray Buhr, who does not consider his approach to be object-oriented, is often cited as a supplier of "object-oriented graphics," e.g., [Buhr, 1984].) Still others have mixed both conventional graphics with new forms, e.g., [Shlaer and Mellor, 1988] and [Stark and Seidewitz, 1987]. There are those who advocate the use of known, but less popular, graphics, e.g.: - semantic networks (e.g., page 180 of [Barr and Feigenbaum, 1981]) and other graphical representation techniques from artificial intelligence (e.g., [Janlert, 1988] and [Sowa, 1984]), - state transition diagrams (e.g., [Barrett and Couch, 1979] and [Ward and Mellor, 1985]), - Petri net graphs (e.g., [Bruno and Balsamo, 1986], [Ghezzi et al, 1989], and [Peterson, 1981]), and - entity-relationship diagrams (e.g., [Chen, 1976]). There are those, including this author, who believe that any graphics chosen for object-oriented software engineering should directly support object-oriented thinking. Examples of object-oriented thinking can be found in, e.g., [Peterson, 1987], [Stefik and Bobrow, 1985], and [Wegner, 1989]. As object-oriented software engineering becomes more popular, there is a definite need for some guidance in the selection and use of graphical techniques. At present, we have much confusion. Those most interested in graphics for software engineering are: - the software engineers themselves (and their management), - those people who are developing object-oriented software engineering methodologies, - anyone developing and defining software engineering standards, and - those developing computer aided software engineering (CASE) tools. It is the intention that this workshop attempt to accomplish several tasks, i.e.: - begin to identify the criteria for selecting graphics for object-oriented software engineering (it will be assumed that the concept of graphics is generally understood), - identify and justify likely candidate graphical techniques, - identify the strengths and weaknesses of each candidate graphical technique, - show any relationships among the candidate graphics, e.g., methods of correlation or transformation, - identify useful combinations of graphical techniques, and - provide a few examples of how each technique can (or should) be used in object-oriented software engineering. Workshop attendance will be by invitation only and is limited to 30 participants. Invitations will be issued on the basis of extended abstracts or position papers. Appropriate papers should not be less than 3 single spaced pages and should state clearly their authors' position and supporting arguments for issues related to one or more of the above mentioned topics. The papers will be reviewed by the moderator and acceptance will be based on both the relevance of the work to the workshop theme and the quality and clarity of the papers. Accepted papers will be distributed to the participants before the workshop, and based on the workshop outcome, some form of formal publication will be generated, that will include longer versions of the accepted submissions. Those interested in attending this workshop should send position papers to Edward V. Berard, Berard Software Engineering, Inc., 18620 Mateney Road, Germantown, Maryland 20874, U.S.A.. Phone contact is available via (301) 353-9652. FAX contact is (301) 353-9272, and e-mail is eberard@bse.com. Important Dates: ---------------- August 10, 1990 Deadline for receiving extended abstracts. September 17, 1990 Notification of invitation or rejection. (Note: I am actively seeking one, or more, co-moderators.) BIBLIOGRAPHY [Alabiso, 1988]. B. Alabiso, "Transformation of Data Flow Analysis Models to Object -Oriented Design," OOPSLA '88 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 23, No. 11, November 1988, pp. 335 - 353. [Barr and Feigenbaum, 1981]. A. Barr and E.A. Feigenbaum, Editors, The Handbook of Artificial Intelligence, Volume 1, HeurisTech Press, Stanford, California, 1981. [Barrett and Couch, 1979]. W.A. Barrett and J.D. Couch, Compiler Construction: Theory and Practice, Science Research Associates, Chicago, Illinois, 1979. [Booch, 1986]. G. Booch, "Object Oriented Development," IEEE Transactions on Software Engineering, Vol. SE-12, No. 2, February 1986, pp. 211 - 221. [Booch, 1990]. G. Booch, Object-Oriented Design, Benjamin/Cummings, Menlo Park, California, 1990. [Bruno and Balsamo, 1986]. G. Bruno and A. Balsamo, "Petri Net-Based Object-Oriented Modeling of Distributed Applications," OOPSLA '86 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No. 11, November 1986, pp. 284 - 293. [Buhr, 1984]. R.J.A. Buhr, System Design With Ada, Prentice-Hall, Englewood Cliffs, New Jersey, 1984. [Chen, 1976]. P.P-S Chen, "The Entity-Relationship Model -- Toward a Unified View of Data," Transactions on Database Systems, Vol. 1, No. 1, March 1976, pp. 9 - 36. [Coad and Yourdon, 1989]. P. Coad and E. Yourdon, OOA -- Object-Oriented Analysis, Prentice-Hall, Englewood Cliffs, New Jersey, 1989. [Cunningham and Beck, 1986]. W. Cunningham and K. Beck, "A Diagram for Object-Oriented Programs," OOPSLA '86 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No. 11, pp. 361 - 367. [Ghezzi et al, 1989]. C. Ghezzi, D. Mandrioli, S. Morasca, and M. Pezze, "A General Way to Put Time in Petri Nets," Proceedings of the Fifth International Workshop On Software Specification and Design, May 19-20, 1989, Pittsburgh, Pennsylvania, IEEE Computer Society Press, Washington, D.C., May 1989, pp. 60 - 67. [Gray, 1987]. L. Gray, "Procedures for Transitioning from Structured Methods to Object-Oriented Design," Proceedings of the Conference on Methodologies and Tools for Real-Time Systems IV, National Institute for Software Quality and Productivity, Washington, D.C., September 14-15 1987, pp. R-1 to R-21. [Gray, 1988]. L. Gray, "Transitioning from Structured Analysis to Object-Oriented Design," Proceedings of the Fifth Washington Ada Symposium, June 27 - 30, 1988, Association for Computing Machinery, New York, New York, 1988, pp. 151 - 162. [Heitz and Labreuille, 1988]. M. Heitz and B. Labreuille, "Design and Development of Distributed Software Using Hierarchical Object Oriented Design and Ada," in Ada In Industry: Proceedings of the Ada-Europe International Conference Munich 7-9 June, 1988, Cambridge University Press, Cambridge, United Kingdom, 1988, pp. 143 - 156. [Janlert, 1988]. L.E. Janlert, "Pictorial Knowledge Representation," Proceedings of the European Conference on Artificial Intelligence 1988, Munich, August 1988, pp. 149 - 151. [Loomis et al, 1987]. M.E.S. Loomis, A.V. Shaw, and J.E. Raumbaugh, "An Object Modeling Technique for Conceptual Design," Proceedings of ECOOP '87: European Conference on Object-Oriented Programming, Springer Verlag, New York, New York, 1987, pp. 192 - 202. [Peterson, 1981]. J.L. Peterson, Petri Net Theory and the Modeling of Systems, Prentice-Hall, Englewood Cliffs, New Jersey, 1981. [Peterson, 1987]. G.E. Peterson, Tutorial: Object-Oriented Computing, Volume 1: Concepts, IEEE Catalog Number EH0257-6, IEEE Computer Society Press, Washington, D.C., 1987. [Pun and Winder, 1989]. W.W.Y. Pun and R.L. Winder, "A Design Method for Object-Oriented Programming," ECOOP '89: Proceedings of the European Conference on Object-Oriented Programming, British Computer Society Workshop Series, Cambridge University Press, Cambridge, United Kingdom, 1989, pp. 225 - 240. [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. [Shlaer and Mellor, 1988]. S. Shlaer and S.J. Mellor, Object-Oriented Systems Analysis: Modeling the World In Data, Yourdon Press: Prentice-Hall, Englewood Cliffs, New Jersey, 1988. [Sowa, 1984]. J.F. Sowa, Conceptual Structures: Information Processing in Mind and Machine, Addison-Wesley, Reading, Massachusetts, 1984. [Stark and Seidewitz, 1987]. M. Stark and E.V. Seidewitz, "Towards a General Object-Oriented Ada Life-Cycle," Proceedings of the Joint Ada Conference, Fifth National Conference on Ada Technology and Washington Ada Symposium, U.S. Army Communications-Electronics Command, Fort Monmouth, New Jersey, pp. 213 - 222. [Stefik and Bobrow, 1985]. M. Stefik and D.G. Bobrow, "Object-Oriented Programming: Themes and Variations," The AI Magazine, 1985, pp. 40 - 62. [Vielcanet, 1989]. P. Vielcanet, "HOOD Design Method and Control/Command Techniques for the Development of Realtime Software," Proceedings of the Sixth Washington Ada Symposium, June 26-29, 1989, pp. 213 - 219. [Ward and Mellor, 1985]. P.T. Ward and S.J. Mellor, Structured Development for Real-Time Systems, Volumes 1-3, Yourdon Press, New York, New York, 1985. [Wasserman et al, 1990]. A.I. Wasserman, P. Pircher, and R.J. Muller, "An Object-Oriented Design Notation for Software Design Representation," IEEE Computer, Vol. 23, No. 3, March 1990, pp. 50 - 63. [Wegner, 1989]. P. Wegner, "Learning the Language," Byte, Vol. 14, No. 3, March 1989, pp. 245 - 253. ------------------------------------------------------------------------------- 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 | -------------------------------------------------------------------------------