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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!JPL-VLSI.ARPA!larry From: larry@JPL-VLSI.ARPA.UUCP Newsgroups: comp.lang.ada Subject: OO and Requirements Message-ID: <870226165936.08e@Jpl-VLSI.ARPA> Date: Thu, 26-Feb-87 19:59:35 EST Article-I.D.: Jpl-VLSI.870226165936.08e Posted: Thu Feb 26 19:59:35 1987 Date-Received: Mon, 2-Mar-87 07:09:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet List-Id: I've been talking recently with several people about the relationship of object orientation to requirements analysis. The following is my answer, which borrows from Russell Abbott's _An Integrated Approach to Software Development_ (John Wiley & Sons, 1986). Abbott is the person to whom Grady Booch gives credit for his particular approach to object-oriented design and programming. My interpretation may differ from Abbott's, but the bottom line is the same: object orientation is essential to requirements study, but is not enough by itself. THE CHINESE BLACK-BOX PROBLEM Abbott splits requirements analysis into two phases (or roles, if as I do you see development as a parallel rather than a serial process.) The needs analysis phase is concerned with the environment of a problem, with WHY a new system of some kind is to be developed. Since no system can solve all problems or garner all profits, the client and analyst(s) prioritizes the pains and gains to be dealt with and drops some of them. Boundary conditions are then set for those that remain. The end product of this phase is a Requirements Specification. The second part of the requirements study is the system synthesis phase, which focuses on WHAT the new system will be. This phase produces a description of a system that will meet the constraints defined earlier. There may be several that would satisfy the client. The one picked becomes the Target Specification. Abbott emphasizes that the Req spec must be kept as loose as possible and distinguished from the Target Spec to keep from painting oneself into a corner. Design is concerned with the insides of the system, with HOW resources are to be partitioned and allocated to make the system real. There may be more than one good way to partition/allocate resources; one must be picked. To manage the complexity inherent in any non-trivial system, design is often broken into a preliminary and one or more detailed phases. This brings to light a confusion that I call the Chinese Black-box Problem. Each target that satisfies a higher-level requirement establishes requirements for the next level down, so how do you know the difference between requirements and design? The resolution is that requirements and design are duals of each other, and are distinguished by whether you are looking up or down abstraction levels. Or put another way: every coin has three sides, the inside, the outside, and the coin-purse. NOUNS/VERBS/ADWORDS Defining important objects is often the first action done at each level of abstraction, whether it be the two requirements phases, two or more design, or the various implementation phases. Most writing makes object orientation sound very esoteric, but in fact the situation is just the opposite. An object is simply an entity with fairly definite boundaries. This is the sole criterion, but in the real world most objects have three other attributes. One is a skin at the boundary that hides/protects some of its interior and shows/exposes other parts. Also, they have relationships with other objects, one of the more important ones being membership in one or more classes. Lastly, they tend to be long-lived or combine to make up larger objects that are long-lived. Each of these characteristics (bounds, skins, relations, longevity) are important because they simplify the thinking of everyone concerned. It is for this reason that objects are often the starting point in each phase. Longevity is also important at the end of the development process: the "maintenance" phase. Enhancement or error correction is much easier when major parts of a system are stable. But a system without time (or with eternal time) is useless. Change is also needed--attributes of objects (color, location, etc.), relationships with other objects (before/after, brighter- or dimmer-than), the creation and deletion and transformation into other objects, etc. This is a procedural orientation. Ed Berard (and I believe Booch) distinguish two types. A mapping from a domain of objects to a range of them (before and after: binary time) is a functional abstraction. More complex temporal changes need an explicit or implicit controller and is labeled a process abstraction. In many cases it makes more sense to start a phase defining the nouns (objects) of a (sub)system being developed, but there are also systems where time is more important and it may be best to start with the system's verbs (functional relationships, attributes, and decomposition). In either case, however, developers will have to deal with both nouns and verbs and rarely will one be more more important than the other in the long run. But there's another linguistic element that needs attention, especially in regards to requirements: adwords (adjectives and adverbs). Ada (or Ada-like) "sentences" can adequately specify the noun and verb elements of a target specification, with expressions on the order of OBJ2 := Func(OBJ1). But how can requirements be specified? What's the Ada equivalent of the following? Size(OBJECT) < MAX and Time(Func) > WAIT Larry @ jpl-vlsi.arpa