Literature: Describing, comparing and improving the Demeter Method for adaptive systems design: @TECHREPORT{spit:demeter-95, AUTHOR = "Martin Spit", TITLE = "Method Modeling of Demeter", INSTITUTION = "University of Twente", YEAR = 1995, MONTH = "September", NUMBER = "", NOTE = "Master's Thesis" } ========================================= Compares 15 methods: @BOOK{hutt:method-comparison, AUTHOR = "Andrew T.F. Hutt", TITLE = "Object Analysis and Design: Comparison of Methods", PUBLISHER = "John Wiley and Sons", YEAR = "1994", SERIES = "Object Management Group" } ================================================================ Oct. 28, 1995 Patrick Logan wrote: The closest thing I can identify S-M (Shlaer-Mellor) with in the OO world is the Demeter stuff. But I have only a surface level understanding of either one. (I am not talking about just the popular Law of Demeter. I mean the entire Demeter system.) It would be helpful for me to see a comparison of the two. Patrick_D_Logan@ccm.jf.intel.com -- Martin Spit (spit@cs.utwente.nl) from the University of Twente has compared the Demeter Method with ten other methods, including the Shlaer-Mellor Method. His Master's thesis will soon be available on the net and will be announced on the Demeter Home page (see below). The key difference between the Shlaer-Mellor Method and the Demeter Method is that the latter is based on patterns of object collaborations, known as propagation patterns. There is a new book which describes those patterns in detail and how they are used in the Demeter Method. Title: Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns Author: Karl Lieberherr Publisher: PWS Publishing Company ISBN: 0-534-94602-X Year: 1996 email info: info@pws.com For more information, on the Demeter System (consisting of both method and free professional tools and free Internet course materials, including many pattern examples), see URL: Demeter's home page: http://www.ccs.neu.edu/research/demeter/ Karl Lieberherr, (Lieberherr@CCS.neu.EDU) Oct. 31, 1995 Subject: Re: Demeter & Object Lifecycles > There > has been some discussion of the Schlaer-Mellor O-O method and how it > is a "translational" approach instead of the "elabaration" approach > employed by Booch and others. The question came up as to which of > these categories Demeter falls into and how does it stack up against > the Schlaer-Mellor method. > It would be helpful for me to see a comparison of the two. The difference between 'translational' and 'elaborational' is not completely clear to me. I expect elaborational methods to be strictly OO, i.e. always maintain an object-view throughout the design process. While translational methods introduce different views, different modeling approaches which results are mapped onto the object model. On of the major benefits of object-orientation is that it allows designers of information systems to use the same model in different stages of the design process. The object model can be gradually refined ('elaborated') to support analysis, design as well as implementation phases. Whereas in conventional systems design a translation between -for instance Entity-Relationship modeling and Relational database models- is necessary, this transition is 'seamless' (Henderson-Sellers) in object-orientation. Unfortunately, this not completely true. With respect to the static parts of the object there seems to be no problem. Even in large and complex systems it is possible to identify the relevant objects/classes and their characteristics. (There is a lot of experience in this, since Chen's ER-modeling) However, the modeling of the system's behavior is not so simple. The currently known ways of OO modeling do not firmly support the step from high-level functionality specifications to individual object behavior. I see three strategies taken towards this problem: 1. puritan OO. Trying to define high-level structures that have identity, state and behavior. Jacobson's use-cases I place in this category. 2. make do. Find ways to incorporate the results of a non-OO view in the object model. This usually implies incorporating some way of reasoning about processes into the method. 3. denial. Right now denial seems the most popular approach, while some research efforts are made in finding pure OO solutions. I have to admit that searching for ways to increase the expressive power of OO seems the best way to tackle the problem way consistent with the developments in field of computer science. On the other hand I think the design methodology community should not close its eyes for the fact that in business administration reasoning in processes is -and will be for many years to come- normative. (In this light the claim that object-orientation is a 'natural' view to the world might be questionable. What is natural may depend on the viewer's position.) So I can still agree upon taking a translational approach as long as the translation can be done in an unambiguous and preferably non-creative way. Demeter is translational in this way. Modeling of the class structure and the system's functionality is done in a minimally dependent way. This strong separation between structure and functionality is not very OO but is at the core of Demeter's strength: specifying functionality that is robust against changes in the class structure (adaptiveness). Shlaer & Mellor's Object Lifecycles (Modeling the World in States) introduces 'actions', functionality specifications that aggregate the behavior of several individual objects ('processes'). This is a similarity with Demeter. The difference, however, is that in Demeter the specification of certain behavior of groups of objects is done in such a way that the translation to individual object behavior (the decomposition from actions to processes) is automated, and therefore no longer a concern to the designer. Many introductory papers on Demeter have already been writter by the Demeter team. My modest contribution "Method Modeling of Demeter -describing, comparing & improving the Demeter method for adaptive systems design-" will be available in the Demeter ftp-directory by the end of this week. --Martin Spit. (spit@cs.utwente.nl)