dt@cui.UUCP (TSICHRITZIS Dennis) (02/19/88)
We have been struggling for a year now to understand what kinds of tools are needed for object design. Here are some comments which may at least encourage some discussion. General comment --------------- If you insist on reusability you cannot always rely on structured design by refinement. At some point you should synthesize from existing objects. Traditional software methodologies are the equivalent of a cookbook recipe. Given the desired meal, you come down to the needed ingredients and the procedure to follow to cook it. With object reusability the problem is inverted. Given some notion of a meal and some available stuff in your fridge, fix a reasonable meal. Here are some tools that we have been working on that we believe will help to solve the problem: 1. The first tool you need is one that helps you to organize a software base of available objects. Conceptual modeling and knowledge base ideas are helpful here, but we are dealing with *real* objects, not concepts. Together with this we need a powerful filter-browser to select the pertinent objects for your application. 2. Another tool you need is a structure editor like the ones used for VLSI design, which puts objects together from existing objects as parts. You can go so far with structural synthesis. Eventually you arrive at some objects which are relatively autonomous. 3. You need a configuration tool which defines how objects are put together. The important notion here is "glue". Glue is a kind of interfacing tool which you use when objects do not fit nicely together. After all, if you insist on reusing objects you will be very lucky if they can talk to each other. A common standard interface as a uniform glue is too restrictive. The problem we are struggling with is, what are the most useful kinds of glue? A more advanced problem is, what is a good tool for creating your own glue? 4. When objects are active and autonomous, you need a notion of "scripting". Scripts can be thought of as scenarios in a theatrical play, or as the instructions given by the coach to the football players for a game. They can be considered as a driving mechanism, or as a constraint mechanism on a set of objects. We have worked on scripts and we are now developing some tools. It is a fascinating area. What we are aiming for is that the scripts which coordinate objects will be the same as the ones which can coordinate an animation of characters representing objects. In this way the user can follow what the objects are doing by watching the animated characters. The work we are doing relates to Hybrid, a local, yet another, object-oriented language and system. However most of the work is in C++, and the design tools should apply to other environments. By the way, if you want to understand how application developers may be using existing objects to create applications, go and watch a mason building a *stone* wall (if you can find anywhere such an endangered species). You will see there the notions of a software base, available objects, selection of objects, fitting of objects, mortar as glue, etc. The striking impression is that for such an effort you need imagination, not discipline. That sort of goes against traditional thought about what programming ought to be. But I better stop here. To illustrate that no problem is new, here is a correspondence between hacking, and object design and configuration. Object design Hacking ------------- ------- select objects from software base get packages from network modify them hack them configure via scripts link with shell commands monitor behaviour prototype & test evolve software base distribute on the network You get the feeling that what we are trying to do is to provide some academic respectability for hacking. Greetings from Geneva. D. Tsichritzis (UUCP: mcvax!cernvax!cui!dt)
winnie@pyr1.cs.ucl.ac.uk (03/01/88)
Tsichritzis has given some comments regarding proper design tools for object-oriented programming. However, I believe that before we can decide what design tools are necessary, we do need a proper design methodology which provides the infrastructure for the design tools. At least that is what happened to structured programming style. At first, we had structured programming languages such as Pascal. Then there's the structured design method such as Yourdon's method. The design method brought with it the design tools such as structured editor, data dictionary etc.
des@jplpro.JPL.NASA.GOV (David Smyth) (03/02/88)
In article <36300003@pyr1.cs.ucl.ac.uk> winnie@pyr1.cs.ucl.ac.uk writes: > >Tsichritzis has given some comments regarding proper design tools >for object-oriented programming. However, I believe that before >we can decide what design tools are necessary, we do need a proper design >methodology which provides the infrastructure for the design tools. OOD Methodology (derived from Booch, Cox, and MANY others): 1) Understand the problem any way you want to. Maybe throw together a prototype. I don't care - understanding the problem is beyond the scope of "design." 2) Write an informal description of the problem. This is just prose. 3) Identify the "objects" in the informal description (nouns, and identifying prose). 4) Identify the attributes of the objects (descriptive prose) and the methods applied to the objects (active prose). Well, that does it for the OOD methodology. Pretty easy isn't it? Try it, you'll like it - everybody else has! What is OOP? Implement those attributes and methods in a programming language. I don't care which one, use FORTRASH if you want. However, a true "OOPL" is alot easier, just like symbolic programming is easier in LISP than FORTRASH.
hogg@db.toronto.edu (John Hogg) (03/03/88)
In article <1442@devvax.JPL.NASA.GOV> des@jplpro.JPL.NASA.GOV (David Smyth) writes: >OOD Methodology (derived from Booch, Cox, and MANY others): > >1) Understand the problem any way you want to. Maybe throw together a > prototype. I don't care - understanding the problem is beyond the > scope of "design." > >2) Write an informal description of the problem. This is just prose. > >3) Identify the "objects" in the informal description (nouns, and > identifying prose). > >4) Identify the attributes of the objects (descriptive prose) and the > methods applied to the objects (active prose). > >Well, that does it for the OOD methodology. Pretty easy isn't it? Try it, >you'll like it - everybody else has! While the one true OOD methodology is something we should strive for, it regrettably remains a tough problem. As a matter of fact, ``Booch, Cox, and many others'' participated in the OOPSLA Workshop on Specification and Design for Object Oriented Programming last October, and the consensus was that we still don't know what we're doing. I claim no omniscience myself, but I can at least repeat some of the observations made at the workshop. Let's look at the methodology presented above. In step 1), getting the *right* understanding of the problem is both highly important and non-trivial. Grady Booch distinguished between the *logical* design of the system and the *physical* design, and it appears that step 1) is, ``Construct a logical design.'' Dave Bulman remarked that selecting the right objects, as in step 3), can be difficult outside of the academic environment, where the problems are selected to demonstrate the solution. Nobody had any surefire rules for object selection, although Ivar Jacobsen put forth a heuristic for good design: any reasonable change proposed by a user should influence one class only, or at most two. The fact that this is a retrospective measure illustrates the problem of getting it right in the first place. Alternatively, Kent Beck had a different perspective on the same problem: objects are not too hard to choose, but distributing behaviours among objects is difficult. This is step 4). It was well illustrated by the examples that Booch used: an automobile cruise control, and a naval fire control system. Several methodologies were in fact presented at the workshop, but they were invariably prefaced with, ``The way that *I* do it is...'' Since Dennis Tsichritzis started this thread, perhaps I should finish with an observation from him (not made at OOPSLA) on medicines: if there's only one cure offered for your ailment (e.g., ASA for headaches) it works. If there are rows of nostrums, none of them really work. While I don't think that anybody is selling object-oriented snake oil, a lot of intuition and black art is still needed with these tools. -- John Hogg | hogg@csri.toronto.{edu,cdn} Computer Systems Research Institute| uunet!csri.toronto.edu!hogg University of Toronto | hogg%csri.toronto.edu@relay.cs.net (arpa) | hogg@csri.utoronto (bitnet)
des@jplpro.JPL.NASA.GOV (David Smyth) (03/08/88)
hogg@db.toronto.edu (John Hogg) writes: >des@jplpro.JPL.NASA.GOV (David Smyth) writes: >>OOD Methodology ... >>1) Understand the problem any way you want to. ... >>2) Write an informal description of the problem. This is just prose. >>3) Identify the "objects" ... >>4) Identify the attributes of the objects ... > >While the one true OOD methodology is something we should strive for, >it regrettably remains a tough problem. As a matter of fact, ``Booch, >Cox, and many others'' participated in the OOPSLA Workshop on >Specification and Design for Object Oriented Programming last October, >and the consensus was that we still don't know what we're doing. Yes, it is true that everybody has various little details that they interject, but I think that this is a good summary of the common ground. If you go thru all those proceedings, articles, and books, and do a one page summary (I've never seen a book that needed more than a one page summary!), you will end up with a close approximation of the above list. >... In step 1), getting the *right* understanding of the >problem is both highly important and non-trivial. > > ... selecting the right objects, as in step 3), >can be difficult outside of the academic environment ... > >Alternatively, ... objects are not too hard to choose, but distributing >behaviours among objects is difficult. This is step 4)... I suppose this caveat should always be applied to any design effort, regardless of methodology and medium: ALWAYS GET THE VERY BEST DESIGNERS YOU CAN. THEY CAN NEVER COST TOO MUCH. Yourdon tried to emphasise that alot of effort is needed, and lots of consistency in the documentation. This is simply not so. All that is needed is a CORRECT design. A correct design is probably impossible for most people to generate, regardless of methodology. So, I should have added a "Zeroth" step: 0) Get the best people available.
cox@stpstn.UUCP (Brad Cox) (03/11/88)
> In article <36300003@pyr1.cs.ucl.ac.uk> winnie@pyr1.cs.ucl.ac.uk writes: > > OOD Methodology (derived from Booch, Cox, and MANY others): > > 1) Understand the problem any way you want to. Maybe throw together a > prototype. I don't care - understanding the problem is beyond the > scope of "design." > > 2) Write an informal description of the problem. This is just prose. > > 3) Identify the "objects" in the informal description (nouns, and > identifying prose). > > 4) Identify the attributes of the objects (descriptive prose) and the > methods applied to the objects (active prose). > > Well, that does it for the OOD methodology. Pretty easy isn't it? Try it, > you'll like it - everybody else has! I must admit to the same kind of discomfort I've felt many times before with Structured Programming/Design and now OO Programming/ Design. Which is that such adjectives encourage the gullible to view them as indistinguishable with GoodProgramming and GoodDesign. I really like your caricature of OOD. It neatly captures in very few words the shallowness of OOD as a topic unto itself and how far we've yet to go to arrive a complete GoodDesign cookbook. I've done a lot of system-building, have made a lot of mistakes, done a lot of things right, and have tried to learn from all this to begin building such a cookbook. My primary recipe is a simple one USE THE RIGHT TOOL FOR THE JOB That is nearly any tool, C, assembly language, Smalltalk, Unix, awk, shell, Cobol, Structured Programming, Object-oriented programming, has a right place and a wrong place *inside nearly every programming project*. I particularly like this rule because it totally subsumes fads by presuming that any skilled craftsman will stay abreast of the state of the art in his area and will be aware of important tools as they come available, be they structured programming, object-oriented programming, and the like. The skill is then a matter of deciding which tool is right for the job at hand. The second rule is more radical and more specific. And like the first one, you won't find it mentioned in any of the OOD cookbooks I've seen to date. In fact, it is so seldom discussed that I've given it a fancy name to attract the attention that it deserves, *The Golden Rule of Design*. SEPARATE THE ABSTRACT AND THE CONCRETE I learned this one from the Smalltalk-80 Model-View-Controller paradigm, by reading Alan Shaw's discussion of text-formatting programming, and by paraphrasing one of the dictums of data-flow diagramming as *Keep the bubbles distinct from the arrows*; i.e. separate the data from the processes that are transforming it. Paraphrased for object-oriented programming, it means to separate those classes that represent the abstract behavior of the application (the models) from those classes that are involved in transforming the model (the views and controllers), because abstractions can usually be codified to withstand radical evolutionary change far better than transformation classes, particularly when the transformations have to do with user interfaces. A correlary of this rule is to avoid what I now refer to (after having *recommended* it several times in writing! That is, before I knew better) as a sucker trap that object-oriented programming lays for the unwary, OBJECTS SHOULD NEVER KNOW HOW TO `PRINT' THEMSELVES (or `display' themselves, nor any analogous verb). Printing is guaranteed to change because it depends on display device technology, formatting requirements, and even the needs/expertise of the viewer, while abstract (model) objects can live on and on without change. -- Brad J. Cox, Ph.D. Productivity Products International 75 Glen Road; Sandy Hook, CT 06482 (203) 426 1875; ...yale!bunker!ppi!cox
des@jplpro.JPL.NASA.GOV (David Smyth) (03/12/88)
cox@stpstn.UUCP (Brad Cox) writes: >>des@jplpro.JPL.NASA.GOV (David Smyth) writes: >> OOD Methodology (derived from Booch, Cox, and MANY others): >> 1) Understand the problem any way you want to... >> 2) Write an informal description of the problem... >> 3) Identify the "objects" (nouns, ... >> 4) Identify the attributes of the objects (descriptive prose) and the >> methods applied to the objects (active prose). > > ... avoid what I now refer to (after having >*recommended* it several times in writing! That is, before I knew better) >as a sucker trap that object-oriented programming lays for the unwary, > > OBJECTS SHOULD NEVER KNOW HOW TO `PRINT' THEMSELVES > (or `display' themselves, nor any analogous verb). > >Printing is guaranteed to change because it depends on display device >technology, formatting requirements, and even the needs/expertise of the >viewer, while abstract (model) objects can live on and on without change. I think this is really a good place to use multiple inheritance, or an underlying layer (resource class) used by objects. The "print" method requires context. This can be presumed by inherited attributes and methods which know about the context: Print_self! for a memo being mailed (showing up in a mailbox contents display) would be different than the Print_self! method required by a browser, perhaps. The mailbox and browser developers can define the required methods and attributes, and a memo class, say, which is to interact with the mailbox or browser can inherit from those classes, and modify them to fit the memo class. In a sense, the "browser object" class as inherited by "memo class" simply specifies the interface - both process and data - that browser requires. Browser would ask a memo to "Print_self!" and the memo would do so. True, the code and data would likely come from the Browser developer. The memo developer can tailor as required. --------------- OOD is NOT a panacea, or a cookbook for good design. I do not think there IS a cookbook for good design. Good designers approach problems in different ways. I know I design differently than, say, my brother, and both of us have been sucessful in our designs. As you (B.Cox) said, "USE THE BEST TOOL FOR THE JOB" but I think this should be added: "GET THE BEST DESIGNERS AVAILABLE" as the tools won't solve the problem, rather a good designer using good tools will solve the problem.
lee@ssc-vax.UUCP (Lee Carver) (03/16/88)
In article <1681@stpstn.UUCP>, cox@stpstn.UUCP (Brad Cox) writes: > > OBJECTS SHOULD NEVER KNOW HOW TO `PRINT' THEMSELVES > (or `display' themselves, nor any analogous verb). > > Printing is guaranteed to change because it depends on display device > technology, formatting requirements, and even the needs/expertise of the > viewer, while abstract (model) objects can live on and on without change. Perhaps an obvious corralary, but an analogous verb not covered is 'input', for exactly the same reason. Both input and output are concrete processes. OBJECTS SHOULD NEVER KNOW HOW TO `INPUT` THEMSELVES