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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public From: Anthony Menio Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Date: 1996/11/11 Message-ID: #1/1 X-Deja-AN: 196639328 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55u84o$k0i@plath.bain.oz.au> <3283027E.25FA@concentric.net> <56632p$g2e@plath.bain.oz.au> <5672ok$vea@grimsel.zurich.ibm.com> content-type: TEXT/PLAIN; charset=US-ASCII organization: Montclair State University mime-version: 1.0 reply-to: Anthony Menio newsgroups: comp.object,comp.lang.ada,comp.ai,comp.lang.c++,comp.lang.smalltalk Date: 1996-11-11T00:00:00+00:00 List-Id: On 11 Nov Paul Gover > I can see that an application's design might be expressed as > a network of interacting objects, and without such objects there's no > application. I can also see that it's possible to design class hierarchies > to solve application development problems (for example a matrix class to > help develop a linear programming application) which clearly contain > executable program code despite having neither objects nor their interactions > defined as part of the program. > > To clarify, we write such a class definition in terms of the indefinite article - > "A matrix inverse" - whereas in the application definition we'd write in terms of > the definite article - "THE costs matrix. (My apologies to readers whose native > language is Russian, which I think has neither definite nor indefinite articles!) > > If we restrict a development method to applications, I think it's perfectly > possible to consider a design which specifies no implementation details. > But if we consider a development method for programs, I suggest it should > address implementation details such as capacity, performance, reliability, > generality. > > If that's so, can we separate development methods into two groups along this line, > (and if so, are the groups non-empty :-)? Does the term "OO" mean the same thing when > applied to the different groups? I suggest not: application designs seem to be > independant of implementation, so if we use the term to mean inheritance, > encapsulation and polymorphism, it's irrelevant; in the application context it's > more a synonym for "entity -relationship" (which I'd justify by pointing to Alan's > interacting object instances). Conversely in "component" design, the traditional > OO attributes are very relevant to the implementation. Perhaps the > entity-relationship details now come more as constraints on the design, ie, an input, > than a design product. > > Paul Gover > IBM Warwick Development Group > Mumbling for myself, not IBM. > > I think the distinction you are speaking od is the one between the analysis model and the design model. The analysis model is one of the objects which will exist in the system and the interactions between them. These are objects not classes, thus they are definite articals. This model is assumed to take place in an ideal environment. Thus the specifics of the development environment are ignored, ie operating system, language,database system in use etc. The design model describes the classes and class relations which the objects in the previous model will be created from. This model is developed from the previous now in the specific implementation model for the system. The the processes that create these models should be seemless thus the implementation model should be created from and be as consistant as possible with the analysis model. Thus both described the system and both do so in terms of same architecture(an OO) just at different levels of detail. So in essence your talking about the deliverables of two different stages in an OO systems development process rather than two different sets of methods, and the answer is that these both reflect the OO architecture of the system equally. Regardless of the size or complexity of any system thier exists both an analysis model and a design model which will be equally valid descriptions of it. Thus any component you wish to create must have the abilites of an instance of it modeled and then a blue print to create these instances of. Consider the development of a set of components from a physical system lets say a transmission you would be interested in describing the behavoir and attributes of a example of this transmission and its sinteraction with everal instances of types of cars. From this model you would create your blueprint thus your design the type description. Anthony Menio I.S. student menio@pegasus.montclair.edu