2 Software engineering
Object-oriented methods cover, at least, methods for design and methods for analysis. Sometimes there is an overlap, and it is really only an idealization to say that they are completely separate activities. Ralph Hodgson (1990) argued that the systems development process is one of comprehension, invention and realization whereby a problem domain is first grasped or apprehended as phenomena, concepts, entities, activities, rôles and assertions. This is comprehension and corresponds entirely to analysis. However, understanding the problem domain also entails simultaneously apprehending frameworks, components, computational models and other mental constructs which take account of feasible solution domains. This inventive activity corresponds to the design process. Of course, most conventional thinkers on software engineering will be horrified that we suggest that understanding the answer precedes, to some extent, understanding the problem, but that is precisely what we are saying. All other cognitive processes proceed in this way, and we see no reason why software engineering should be different. These considerations also enter into the realization process where these frameworks and architectural components are mapped onto compilers and hardware. Advocates of evolutionary development have long argued that it is beneficial not to make a rigid separation between analysis, design and implementation. On the other hand, managerial and performance considerations lead to serious questions about the advisability of prototyping in commercial environments. Graham (1991d) suggested a number of ways in which prototyping could be exploited but controlled. At the root of this debate are ontological and epistemological positions concerning what objects are and how we can apprehend them or know about them.
Biggerstaff and Richter (1989) suggested that less than half of a typical system can be built of reusable software components, and that the only way to obtain more significant gains in productivity and quality is to raise the level of abstraction of the components. Analysis products or specifications are more abstract than designs. Designs are more abstract than code. Abstract artefacts have less detail and less reliance on hardware and other implementation constraints. Thus the benefits of reuse can be obtained earlier in a project, when they are likely to have the greatest impact. However, the less detailed an object is the less meaningful it becomes. Where extensibility or semantic richness is important greater detail may be required, and this may compromise reuse to some extent. This leads us to ask if object-oriented analysis and design techniques exist which can deliver the benefits of reuse and extensibility. In the face of still evolving object-oriented programming and component technology, this question attains even more significance: can we gain these benefits now, pending the appearance of more mature, more stable languages and frameworks? We think we can. However, the subsidiary question of which methods of design and analysis we should use is harder. The popular notation is UML, which was first standardized by the OMG in 1997, but UML is only a notation. We need to add techniques and guidelines to it to arrive at a method.
Software houses and consultancies ought to be particularly interested in reusable and extensible specifications. The reason for this is pecuniary. What the people employed by software houses and consultancies do, to earn their livings, is work with clients to understand their businesses and their requirements and help them produce software solutions to their problems. Having gained all this valuable experience, consultants then go on to the next client and sell what they have learnt, perhaps for a higher fee justified by the extra knowledge. Some firms go further. They try to encapsulate their experience in customizable functional specifications. For example, a firm We worked for, BIS Information Systems, had a product in the 1980s called the 'mortgage model', which was a functional specification of a mortgage application, based on a number of such projects and capable of being tailored to the needs of a particular client. The trouble was, for BIS at least, that the mortgage model could not be sold to greengrocers or washing machine manufacturers, even though some of the entities, such as account, may apply to all these businesses. What is required, then, is a set of reusable specification components that can be assembled into a functional specification suitable for any business. Object-oriented analysis, and to a lesser extent design, promises to deliver such a capability, even if the only extant reusable frameworks, such as IBM's San Francisco, are still delivered as code.
To fix terminology, let us begin with a vastly oversimplified picture of the software development process or life cycle. According to this simplified model, development begins with the elicitation of requirements and domain knowledge and ends with testing and subsequent maintenance. Between these extremes occur three major activities: specification and logical modelling (analysis), architectural modelling (design) and implementation (coding and testing). Of course this model permits iteration, prototyping and other deviations, but we need not consider them at this stage. In real life, despite what the textbooks tell us, specification and design overlap considerably. This seems to be especially true for object-oriented design and analysis because the abstractions of both are modelled on the abstractions of the application, rather than the abstractions appropriate to the world of processors and disks. Design may be divided into logical and physical design, as is well known. In object-oriented design the logical stage is often indistinguishable from parts of object-oriented analysis. One of the major problems encountered with structured analysis and structured design methods is the lack of overlap or smooth transition between the two. This often leads to difficulties in tracing the products of design back to original user requirements or analysis products. The approach adopted in object-oriented analysis and design tends to merge the systems analysis with the process of logical design, although there is still a distinction between requirements elicitation and analysis and between logical and physical design. Nevertheless, object-oriented analysis, design and even programming, through working consistently with a uniform conceptual model of objects throughout the life cycle, at least promises to overcome some of the traceability problems associated with systems development. One of the chief reasons for this is the continuum of representation as the object-oriented software engineer moves from analysis through design to programming. In these transitions the unit of currency, as it were, remains the same; it is the object. Analysts, designers and programmers can all use the same representation, notation and metaphor rather than having to use DFDs at one stage, structure charts at the next and so on.
The benefits of object-oriented analysis and design specifically include:
Object-oriented analysis and design methods share the following basic steps although the details and the ordering of the steps vary quite a lot:
Analysis is the decomposition of problems into their component parts. In computing it is understood as the process of specification of system structure and function independently of the means of implementation or physical decomposition into modules or components. Analysis was traditionally done top-down using structured analysis, or an equivalent method based on functional decomposition, combined with separate data analysis. Often the high level, strategic, business goal-driven analysis is separated from the systems analysis. Here we are concerned with both. This is possible because object-oriented analysis permits the system to be described in the same terms as the real world; the system abstractions correspond more or less exactly to the business abstractions.
Object-oriented analysis is analysis, but also contains an element of synthesis. Abstracting user requirements and identifying key domain objects are followed by the assembly of those objects into structures of a form that will support physical design at some later stage. The synthetic aspect intrudes precisely because we are analysing a system, in other words imposing a structure on the domain. This is not to say that refinement will not alter the design; a well-decoupled design can be considerably different from a succinct specification model.
There is a rich theory of semantic data modelling going far beyond the normal use of ER diagrams. This theory encompasses many of the concerns of object-orientation such as inheritance and abstract types. It also illuminates our understanding of relationships or associations between entities. Much of this work has been ignored by workers in object technology and in AI as thoroughly as these two areas have ignored each other.
Early OO analysis methods
There are often said to be three primary aspects of a system apart from its identity. These are respectively concerned with: a) data, objects or concepts and their structure; b) architecture or atemporal process; and c) dynamics or system behaviour. We shall refer to these three dimensions as data, process and control. Object-orientation combines two of these aspects - data and process - by encapsulating local behaviour with data. We shall see later that it is also possible to encapsulate control. Thus, an object-oriented analysis can be regarded as a form of syllogism moving from the Particular (classes) through the Individual (instances) to the Universal (control).
Figure 2 Three dimensions of software engineering.
The conventional wisdom in software engineering holds it as self-evident that a system must be described in these three dimensions; those of process, data and dynamics or control. The data dimension corresponds to entity-relationship diagrams (ERDs) or logical data models. The process models are represented by data flow or activity diagrams of one sort or another. Finally, the dynamics i