Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!bloom-beacon!MWSUN.MITRE.ORG!nigam From: nigam@MWSUN.MITRE.ORG (Alok Nigam) Newsgroups: comp.software-eng Subject: Re: Attempts to connect SA/D and OOPS Message-ID: <8908151432.AA18184@mwsun.mitre.org> Date: 15 Aug 89 14:32:16 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 78 Date: Fri, 11 Aug 89 11:03:08 PDT From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU Subject: Re: Attempts to connect SA/D and OOPS Gossain Sanjiv Organization: University of Essex, Colchester, UK States >It seems to me that too many people try to evolve OO design methods from >existing design approaches, when what is really required, IMHO, is to >wipe the slate clean and start proposing design approaches that reflect >the paradigm shift required when moving to OOP. Earlier in Vol 6, Issue 37, Edward Berard w rote >Subject: Re: Integrating SA/SD & DA/DD >Although object-oriented programming has been around (formally) for >almost twenty years, its practitioners unfortunately spent most of >their time focusing on coding and programming language issues. Until >the early 1980s very little work was done in the area of life-cycle >methodologies. Hence, we see the structured methodologists now >migrating to an object-oriented approach and bringing their largely >inappropriate methods, tools, and graphics with them. There is a problem here (1) Object Oriented Programming exists and has advantages(IMHO) (2) There is a a hefty investment in Analysis and Design Methods that don't fit Object Oriented Programming. (3) Programming technology and methodology have not (alone) consistently produced valuable pieces of software (4) Something has to be done prior to writing code. But what? In Vol 6, Issue 40, Edward Berard wrote: >Subject: Re: Attempts to connect SA/D and OOPS(2) >Please, object-oriented systems do _not_ organize by data. Objects >encapsulate: > - knowledge of state information (which may deal with "data," > but is more likely to be concerned with objects) > - operations (and their associated methods) > - [optionally] other objects, i.e., you may have: > - homogeneous composite objects > - heterogeneous composite objects > - [optionally] exceptions > - [optionally] constants > - concepts [...] >Object-oriented systems don't have "data" flows. If the concept of >something flowing is important to you, you can talk about "object >flows," although this would seem strange to some object-oriented folks. Forgive my ignorance but is it ok to assume that in an object oriented piece of software (1) there are things that we can call 'objects' which are separated from each other. (2) separate object have some means of communication with each other. (is this always one-one by the way?) (3) designing and documenting which communications should occur might save money - in the long run. (How much? - to the programmer, the designer, the maintainer,...) Given these - what language independant ways exist for (1) Recording existing communication patterns (Ideally in 4 forms: text, mathematical, automated, and graphic) (2) Deriving patterns of communication from existing software (3) Evaluating a pattern of communication. (4) Designing a pattern suitable for given situation. Dick Botting, Department computer science, California State University, San Bernardino, CA 92407 PAAAAAR@CCS.CSUSCC.CALSTATE paaaaar@calstate.bitnet PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU