hogg@db.toronto.edu (John Hogg) (03/02/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 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 work. While I don't think that anybody is selling object-oriented snake oil, there's a lot of black art and intuition needed to effect a cure 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)
hogg@db.toronto.edu (John Hogg) (03/02/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 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 work. While I don't think that anybody is selling object-oriented snake oil, there's a lot of black art and intuition needed to effect a cure 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)
hogg@csri.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 from 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 black art and intuition 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)
hogg@csri.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)