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: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public From: Snowball Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/12 Message-ID: <3288C52E.455E@rase.com>#1/1 X-Deja-AN: 196344913 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> content-type: text/plain; charset=us-ascii organization: RASE Inc. mime-version: 1.0 reply-to: snowballinfo@rase.com newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai x-mailer: Mozilla 3.0b5aGold (Win95; I) Date: 1996-11-12T00:00:00+00:00 List-Id: Robert C. Martin wrote: > > Objects execute inside computers. They take up memory space and CPU cycles. > Classes are source code. They specify the objects and create a structure > from which the objects are created. > This is true for C++ and some other languages, however for Smalltalk Classes are objects which take up memory space (and sometimes CPU cycles). > Any method that concentrates on one more than the other is doing a disservice > to its inventors and its users. Rather we must focus on both. We generally > use dynamic models (i.e object diagrams, interaction diagrams, etc) to specify > objects and the way that they interact. We use static models (i.e. class > diagrams, package diagrams, etc) to specify classes and the static > relationships between them. When we are talking about static and dynamic models, something bothers me. There are two types of complexities in any system. One is the static or structural (or sometimes I call it detail) complexity, the other one is dynamic complexity. To me some canonical forms of systems such as class hierarchy can be reasonably understood by static diagrams, however, it is not very intuitive to attempt to model dynamic behavior in static diagrams such as object or interaction diagrams. I can differentiate between structural complexity and dynamic complexity with an example: a car engine totally taken apart and lying on the floor with all parts visible, and even sorted out to parts, may create an atmosphere for us to develop a detailed understanding of each part but will not give us a clear idea of how it runs. An engine timing diagram can help us but the best way to understand how an engine works is to observe it "running" preferably with a power to control the motion of the time domain. This means that we can take the engine, replace one of the side walls of it with say a glass panel, and let it slowly run, even single step, so that we can follow the entire motion. Same analogy for a software system running would be to add a layered visual debugger and a reverse engineering tool to obtain and animate certain diagrams to observe how the behavior of the system changes in time. (It just happens that I am working on such a visual debugger for Smalltalk to be added to a tool I developed) > There is a mapping between the two kinds of models that must be maintained. > Every relationship on a dynamic model; that is, ever pathway accross which > a message is sent; must be supported by a static relationship in a static > model. I totally agree here. To me, they are essentially two different views of the same system. We are mostly defining the structure (time independent portion) of the system with the static models, and we shape the behavior of the system (or how a system behaves in time). Of course in many current languages there is a sharp distinction between these two views although in the real world this distinction is thinner than we think. For every system adaptation is a key to survival. Adaptation requires structural change. That means adding and/or deleting classes, or changing class structure or behavior in time. If this is the case the ?staticness? (is there such a word?) of the static diagrams will not hold any more. A correct class diagram for a system initially will not be the correct diagram after some classes are added or modified dynamically. Tansel Ersavas RASE Inc. mailTo:tansel@deep.net http://www.rase.com/