Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.software-eng Subject: Re: Attempts to connect SA/D and OOPS Summary: Answers to Questions Message-ID: <553@ajpo.sei.cmu.edu> Date: 13 Aug 89 14:54:26 GMT References: <8908120353.AA14861@mitre.arpa> Lines: 275 In article <8908120353.AA14861@mitre.arpa>, Dick Botting wrote: > > Gossain Sanjiv > 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 > wrote > >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) > See, for example, some of the recent discussions I and Ralph Johnson have had on comp.lang.smalltalk. > (2) There is a a hefty investment in Analysis and Design Methods that > don't fit Object Oriented Programming. I recognize this as a real problem. Say, for a minute, you believe two things. First, that an object-oriented approach provides many worthwhile benefits _when_ _correctly_ _and_ _properly_ _applied_. Second, that an object-oriented approach is a significant departure from the more traditional (e.g., functional decomposition) approaches. So much so, that very little can be migrated from the traditional to the object-oriented. You now have a very typical "real world" problem on your hands. Do you continue to use inappropriate techniques, methods, and tools with the new technology, thereby both minimizing the promised benefits, and lengthening the time (and thus the costs) for the transition, or do you make a clean (and what may be costly) break? This is something that software people usually don't do, or don't do very well, i.e., make a meaningful assessment of costs of each alternative. Consider the following simple (incomplete and not very detailed) cost comparison: 1. Cost to acquire current technology: - training costs - hardware (e.g., workstations) costs - CASE software costs - hiring costs - costs to develop in-house policies, procedures, standards, guidelines, bidding and estimating strategies, and in-house training - consulting costs - cost for conferences 2. Cost to acquire the new technology: - all of the above costs - cost of creating and executing a transition plan 3. Quantification of cost benefits of new technology, i.e., cost savings per period of time. 4. Payback period estimation, i.e., the length of time before the new technology will actually pay for itself. 5. The impact, both positive and negative, of not moving to the new technology immediately. Note that, in this analysis, costs are not only financial costs. There are human costs, corporate image costs, and corporate capability costs. There are hidden psychological costs. For example, being in the technology transition business, I frequently hear things like: - I don't trust this new stuff. Therefore I'm going to act like I'm using it, but I'm really going to keep doing things the way I always have done them. - I really like this new technology, but management insists that we use inappropriate tools, techniques, and procedures, simply because they have made such a large investment in these items. I'm looking for a new job, i.e., one that will let me use the new technology in the right way. - I don't know. All these technologies are the same. You just get comfortable with one when a new one comes along. We don't get any work done here. We just change technologies. > (3) Programming technology and methodology have not (alone) > consistently produced valuable pieces of software Human beings, as a rule, have a great deal of difficulty differentiating between a bad idea, and a bad implementation of a good idea. Further, few people willing accept blame. So when something goes wrong, inanimate objects (e.g., programming languages, methodologies, and standards) are easy targets for blame. In essence, one of the hardest things for someone involved in a technical activity to do is to recognize the human part of the technology. Ask any one who has ever attempted to educate or train two, or more, people. Not everyone is equally capable. Of all the items which have an impact on the success or failure of a project, people have, by far, the largest impact. However, good people with poor tools are not as productive as good people with good tools. Yet, this is not enough. To get maximum benefits we must consider the whole picture, i.e., good people, good tools, good methodologies, good standards, good management, good training, etc. > (4) Something has to be done prior to writing code. But what? Here we begin to differentiate between computer science and software engineering. One of the things an engineer must do is to take the knowledge provided by the scientist, and apply it in a practical manner to everyday, "real world" problems, to produce cost-effective, pragmatic solutions. There are many different life-cycle models, e.g.: - flowchart model - sequential waterfall - iterative waterfall - b-model - spiral - recursive/parallel Each of these models is further divided into steps (stages). Some of these life-cycle models provide more than one place where coding can occur. However, to keep things simple, let's use traditional terms: 0. Going on in parallel with the life-cycles of many different software products, is object-oriented domain analysis (OODA). 1. Ignoring the (real) possibility of a feasibility study, one might begin with object-oriented requirements analysis (OORA). 2. There is, of course, object-oriented design (OOD). 3. Object-oriented implementation or coding is often referred to as object-oriented programming (OOP). Please note that OORA is _not_ merely structured analysis (SA) with a few object-oriented terms, nor is object-oriented design a variation on structure design (SD). To oversimplify, object-oriented software engineering involves: - Identifying relevant objects and classes - Documenting these objects and classes - Applying configuration management to the objects and classes of interest. - Producing both static and dynamic object-oriented models of the system. [I would very much like to avoid a detailed discussion of the processes involved with OORA, OOD, and OODA, although I have detailed, e.g., 600 slides worth of OORA, presentations on each.] > 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. This is true. There are also things like classes, systems of objects, and subsystems. > (2) separate object have some means of communication with each other. > (is this always one-one by the way?) There are many mechanisms by which objects can communicate. Smalltalk, for example, allows objects to "pass messages" in all directions. If you wish you can generalize the "message passing" concept. However, remember that messages are themselves composite objects. > (3) designing and documenting which communications should occur might > save money - in the long run. > (How much? - to the programmer, the designer, the maintainer,...) Documenting the interactions of objects, including how they exchange information, is important. However, things like "data flows" don't don't make sense in an object-oriented approach. One technique that is roughly equivalent is an "object-message diagram." This documents flows of messages among objects. > > Given these - what language independent ways exist for > (1) Recording existing communication patterns > (Ideally in 4 forms: text, mathematical, automated, and graphic) Before I begin to answer these questions, I must point out the following: - In addition to communication among objects, we must also provide a mechanism to describe the composition of a given object. - We must also have a mechanism for describing the dynamic behavior of the object - Any and all mechanisms must be object-oriented. One technique for representing the behavior of an object-oriented system is a Perti net graph. The "places" on the Petri net graph, e.g., represent objects in specific states. What is interesting about Petri net graphs is that they are often used to model systems, however, the arcs (edges) do not indicate flow of data or control. Specifically, you can represent a system of interacting (i.e., communicating) objects without showing communication in the conventional sense, i.e., "flowing" along the arcs. > (2) Deriving patterns of communication from existing software This depends on how the software was created. If the software was implemented using a functional decomposition technique, then data and control flows would most accurately reflect the intentions of the initial designers. Attempting to represent this software in terms of interacting objects is both difficult and confusing. > (3) Evaluating a pattern of communication. One of the key criteria for evaluating a "pattern of communication" is how consistent it is with the overall approach. For example, if the approach talks about objects, the pattern should also talk about objects. If the approach talks about functions, then the pattern should talk about functions. > (4) Designing a pattern suitable for given situation. I have a question. Must this "pattern of communication" be explicit or implicit? For example, in data flow diagrams the communication is explicit, i.e., via labeled edges. In Petri net graphs, the communication is implicit, i.e., derived from context. > > 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 -- Ed Berard (301) 353-9652