- Email: [email protected]
OO oversold
Information and Software Technology 1994 36 (1) 35-42
O 0 oversold Those objects of obscure desire Tony Bryant and Andy Evans BT Reader in Software Engineering at Leeds Metropolitan University, The Grange, Beekett Park, Leeds LS6 3QS, UK Research Assistant at Leeds Metropolitan University, The Grange, Beckett Park, Leeds LS6 3QS, UK
The principles of object-orientation have been widely used in the area of programming for some time. Their application to the design and specification of software has proved beneficial in a number of ways. In recent years there have been numerous attempts to exploit the same principles in high level design and the analysis of systems requirements. In many cases this has been achieved by extending the principles of object-oriented programming to the earlier phases of analysis and design without recognition that activities and objectives in the different domains may be dissimilar. This paper demonstrates that the endeavour to extend the principles of object-orientation into an all-encompassing method is ill-considered, and that an expansive view of methods integration is more likely to prove conducive in harnessing the strengths of objectorientation to alternative approaches to systems development. Keywords: object-orientation, methods integration, systems development
Object-orientation (OO) emerged almost simultaneously in various fields in computer science during the 1970s~; this included areas as diverse as computer architecture, databases and artificial intelligence, although perhaps the most important contribution derives from object-based and objectoriented programming languages. These include, Simula, CLLI and ADA, and what is often called the first true OO programming language, Smalltalk. As a consequence of this origin in relatively esoteric and constrained programming and development environments, OO was often associated with small-scale programming and rapid prototyping. For example, both of these features are facilitated by Smalltalk's development environment. Over the past 10 years or so OO has found many proponents, particularly amongst software designers and programmers who have come to appreciate its facilities for reuse, data abstraction and rapid prototyping affording a powerful and more intuitive approach to software development. This practitioner-led impulse has coincided with the promise of increased productivity from OO developments, as argued by Cox, amongst others 2, who detect the possibility of genuine component manufacture with consequent economies of scale, once authentic OO software production has evolved. An earlier version of this paper was presented at the OT93 Conference, April 1993. 0950--5849/94/010035-08~ 1994 Butterworth-Heinemann Ltd
Given this promise, and some limited tangible success in the realm of code production, more recent work has been carried out to extend OO principles to the earlier development activities of design and requirements analysis. This extension has led to the construction of a number of OO 'methods', purporting to encompass a larger proportion of the development process, or even the full scope of system development from requirements capture to implementation3-5. We would argue that such expansion has been envisaged in too simplistic a manner, and that the harnessing of OO must be seen as one aspect in the strategy of methods integration, rather than as an all-encompassing development perspective.
The extending of the OO domain The demand or desire for application of OO beyond the programming phase emanates from a number of sources. One key motivation has been the desire to mimic the expansion that the predominant precursors of OO approaches, collectively termed Structured Methods, effected. Thus structured programming appeared in the late 1960s, and achieved a large measure of acceptance during the 1970s, aided by the appearance of programming languages more akin to structured concepts and abstractions. This later led, by the 1980s, to the growth of more encompassing 35
O0 oversold: A Bryant and A Evans 'methods' incorporating design and analysis. The initial impetus behind this structured revolution may well have been that designers and implementors were keen to fashion much of the output of initial phases of development in as immediately utilizable a form as possible for later implementation purposes. This offered a direct enhancement to the process of verification. Enabling (i.e. compelling or constraining) users and developers to capture and express requirements in a series of structured abstractions made the task of transposition to code easier, less risky and more dependable: with luck it was also a surer way of producing usable, useful and reliable systems. In time, structured methods evolved far beyond this original abstraction-based view. They now (1990s) at least attempt to account for a whole host of other critical factors apart from the eventual design and implementation vehicle. This does not mean that structured approaches have, or indeed can, solve all problems of systems development*. As new developmental strategies appear in a specific domain they will either complement or supplant existing ones. Initially the adherents of such innovations will tend to perceive a wide application for their particular approach, possibly extending beyond the bounds of its actual use. This explains the aspirations of OO adherents to establish ways in which the OO approach can be augmented to resolve an increasing range of developmental problems and paradoxes. In the narrow cast, this has been motivated by those wanting to produce high-level designs that can be fashioned in OO terms so that there can be a rapid and easy translation into the target OO programming language. In wider terms, some analysts have seen OO as providing a 'natural way of modelling' the problem domain itself. Thus Coad and Yourdon introduce their book on OO analysis (OOA) with the statement that ' O O A . . . is based upon concepts that we first learned in kindergarten '3. In general OO partisans often preface their work with statements to the effect that the object view of the world is akin to the natural, everyday one. There seems to be little justification for this claim (as will be argued later, there are the same problems in identifying objects in the OO approach as there are in identifying entities in data-driven and structured ones), but it is partially explained by the origins of OO amongst programmers to whom objects--particularly when viewed as implementations of abstract data types (ADTs)--are probably as natural as any abstraction can be. The failure to make clear distinctions between the two positions--OO as augmentation and OO as self-contained and sufficient alternative--has inevitably led to some confusion. Does the OO approach supplement existing approaches; or is it an irreconcilable alternative? Many of the current OO protagonists seem to suggest that structured analysis techniques (such as those found in Yourdon Structured Analysis, SSADM, Information Engineering) cannot be used effectively when subsequent design and implementation is to be carried out in an object-oriented *Recent work on methods integration stems from the recognition that no single approach is sufficient--this applies just as much to OO approaches as to all others 6. 36
mannerS'V: others claim the contrary 9. The perceptive reader will already have noticed some degree of scepticism in these remarks. In what follows, we wish to examine some key features of the emerging OO 'methods'; aiming to demonstrate that although in some specific aspects they provide advances on their functionoriented, structured predecessors, in general they have failed to address many of the problems associated with the problem domain of systems development as a whole. This leads us to our conclusion that the sole feasible and appropriate trajectory for these advances is provided by the admittedly chaotic but experientially and practically sound bases offered by existing, non-OO approaches. You cannot simply jettison the 'structured baby' with the 'functional bathwater'. This is not to say that OO and any other innovative approaches must align with or rest upon bases offered by structured and other precursors; but neither should it be assumed that these earlier methods can be simply effaced, and the lessons gained from their use forgotten. The problem domain which is the target of all approaches to information systems development is the inherently chaotic and non-systemic one of human social--and, slightly more constrained--organizational activity. This domain is no more 'object-oriented' than it is 'functionoriented' or 'event-oriented'*. On the contrary it is usually readily acknowledged by systems developers that they have to introduce and refine abstractions which capture and concentrate upon certain key features of the development context. None of these abstractions can be considered natural; they are by implication artificial constructs which are at best useful or elucidatory. Thus one cannot judge whether an abstraction such as 'citizen' is useful or not without recourse to the specific system context. On the other hand the entity 'citizen' is no more or less natural than the object 'citizen', and the function of 'citizenship' is similarly devoid of meaning without clarification of use and context. Different orientations can be best judged, at first impression, with reference to their usefulness in providing abstractions which are of value at one or more points of reference within the domain itself: i.e. whether or not they provide a more accessible perspective for consideration of usability, reliability, criticality, and so on. At a more advanced stage of knowledge and theoretical maturity, and assuming that the method has offered at least some semblance of purposeful deployment, consideration should be turned to issues of theoretical soundness, compatibility with other perspectives, semantic meaning and methodological guidance. These aspects have already been identified as weaknesses in most structured (algorithmic or function-oriented) methods. Unless the developers of OO methods address these issues, not only will the advantages of the object-oriented approach be lost, but it will not be long before the term object-oriented is dissociated from good software engineering practice, simply taking its place among the other, now discarded panaceas. *Since first developing this point and presenting this paper, the authors have become aware of a similar argument from a group in Norway s.
Information and Software Technology 1994 Volume 36 Number 1
O0 oversold: A Bryant and A Evans We shall suggest that a more general approach is demanded; one which seeks to encourage more flexibility, coupled with greater emphasis on the theoretical foundations of the models and techniques (including OO ones) used in all kinds of development. We shall also raise the more fundamental issue of whether the OO approach is a suitable one for requirements analysis at all, and what might the consequences be should the approach be found inappropriate.
No O 0 silver bullets In his influential paper No Silver Bullet ~°, Brooks argued that the inherent issues of software development emanate from four essences or ineluctable features of software engineering: these applying as much to the objective of software engineering (better software) as to the process (better practice). These essences were labelled as complexity, conformity, changeability and invisibility. The detail of his paper can be summarized along the following lines: Complexity. Software is inherently complex, it cannot be simplified: this complexity is not merely a technical issue, it also has ramifications for the planning, management and control of software projects. Conformity. Software does not perform in isolation, but has to interface and co-operate with a multitude of other human arte[acts, each of which is idiosyncratically designed, and each of which is less malleable than the software; hence the software has to adapt, not be adapted to. Changeability. Since software is an embodiment of functionality it is subject to constant and continued pressures to change, adapt, and modify. In addition, the use of software itself engenders innovations and imaginative extensions of the software or software/hardware configuration. Invisibility. This chameleon-like complexity and transmutability is further complicated by the total lack of any extensive conceptual representations capable of incorporating all or even most of this intricacy. Does OO confront these essential challenges? Writing in 1985 Brooks argued that OO programming does hold out some promise; but that, at best, it will serve to remove 'accidental' difficulties rather than ameliorating the essential ones themselves. Thus 'abstract data types' and 'hierarchical types' (the two features singled out by Brooks as characterizing OO) remove yet another accidental difficulty from the process, allowing lhe designer to express the essence of the design without having to express large amounts of syntactic material that add no information content (p 14) In other words, ADTs and HTs are useful and potent as detaded design abstractions, permitting developers to concentrate on central features of the object domain. This can be done without having to be concerned with the Information and Software Technology 1994 Volume 36 Number 1
programming language semantics, but in such a way that the transition from specification to code is relatively straightforward. (Or at least less complex than it would otherwise be if abstraction mechanisms other than ADTs and HTs were employed.) We find ourselves in complete agreement with this view. Particularly since it coincides with our point that OO is natural only in these critical but restricted confines between detailed design and coding. To what extent has the expansion of OO into higher levels of design, and latterly analysis, developed further positive aspects which might counteract Brooks' essences? Prior to offering an initial assessment, it is worthwhile summarizing the key features of the OO perspective, or O 0 paradigm itself. The O0 paradigm It is interesting that many of the texts on OO use the term paradigm in their discussions. The term has derived its current meaning from the work of T S Kuhn t~ in which he distinguished between knowledge domains with wellfounded assumptions and those where the basic principles were themselves contested or questionable and consequently always in need of justification. Thus a subject or discipline could be termed paradigmatic when basic principles were generally accepted by the broad spectrum of experts and aficionados: if no such set of fundamentals existed, the domain was termed pre-paradigmatic, implying that eventually a paradigm would emerge. The champions of OO are therefore stressing that the principles of the perspective have--or very soon will--become generally accepted amongst all systems practitioners. The non-OO mavericks will gradually fade into the background or convert to the new order of things. If this is the case, we should find broad and clear consensual agreement on the basic tenets of OO; with many of the fundamental characteristics taken for granted by practitioners and publicists alike. The current literature on OO is growing exponentially, but there are a number of central sources to which a significant proportion of OO publications refer. The classic reference for many is Grady Booch on OO ~. Although slightly dated, it is still the text to which most OO authors refer in support of their opening arguments defining the key characteristics of the approach. Some have criticized the Booch notation, but none of the protagonists has questioned his basic assumptions: and it is these which are central to our present argument. Booch defines the 'object model' as encompassing the 'principles of abstraction, encapsulation, modularity, hierarchy, typing, concurrency, and persistence'. Given Booch's position as one of the authorities on OO, this is a strange starting point. After all, many of these principles can be found in non-OO contexts. It is worth examining each of these concepts in turn to see if they justify the claim for OO to be a new paradigm; a revolution in system specification. Abstraction. This is defined by Booch as 'the process of focusing upon the essential characteristics of an object' 3"/
O0 oversold: A Bryant and A Evans (glossary, p 513); in more general terms, however, it is an inescapable aspect of any modelling activity. • Encapsulation. 'The process of hiding all of the details of an object that do not contribute to its essential characteristics' (glossary, p 513). This is another term for what Parnas described as 'information hiding'. The ambiguity concerning 'essential characteristics' is noted below.
• •
Modularity. 'The property of a system that has been decomposed into a set of cohesive and loosely coupled modules' (p 515). The recognizable basis of structured methods. • Hierarchy. 'A ranking or ordering of abstractions' (p 514). This is somewhat nebulous, but if it is meant to invoke the concept of inheritance, then this can also apply to entity models with sub-types and super-types. Typing. 'The enforcement of a class of an object' (p 519). This can be found implicitly in many programming contexts, but explicitly in all those espousing the employment of ADTs. Concurrency. 'The property that distinguishes an active object from one that is not' (p 513). The term, possibly understood differently, is a feature of all communicating systems. Persistence. 'The property of an object by which its existence transcends time' (p 517). This is applicable to all forms of data-oriented approaches, not just OO ones. The OO paradigm does not then seem to be based on intrinsically different concepts from non-OO approaches. Moreover this does not appear to square with the claim that OO is such a natural approach. For all non-OO practitioners, the use of OO's central terms is anything but naturally object-centred: on the contrary the terms resonate with meanings far removed from those applied by the OO adherents. The only concept which is perhaps uniquely marked as object-oriented is the object itself. Not only is the case for a new paradigm unproven with respect to OO: many of its key concepts are simply those of existing approaches still retaining their meaning. The only concept unique to OO is that of the object itself, and that appears to be far from paradigmatic in the sense of evoking a single agreed meaning. Objects Central to the object-oriented approach is the notion of the object. But what exactly is an object. Although it is easy to state what the properties of an object are (it has state, attributes and functions), and to give examples of objects, (book, car, manager, etc.), the term itself is often a difficult one to define. Perhaps this reflects the fact that objects mean different things to different people, depending upon their view of reality. The following represent definitions of 'object' from a number of well-regarded sources. • 'a tangible entity that exhibits some well defined behaviour' 38
•
--Booch ~ who then goes on to generalize this definition to 'anything which has a well defined boundary'; 'an abstraction of the problem domain, reflecting the capabilities of the system to keep information about it, interact with it, or both'--Coad and Yourdon3; 'a thing that retains certain information and knows how to perform certain operations'--Wirfs-Brock et al. ~2; 'concept, abstraction or thing in the world with crisp boundaries meaningful for the problem at hand to promote understanding of the real world and provide a basis for computer implementation'--RMT, Rumbaugh et al.4; 'anything to which an Object Type applies'--Martin and Odelll3; 'a "thing" that can be distinctly identified'--Coleman et al.~4 (stress in original).
This is hardly a definitive and harmonious basis for a paradigm. The definitions range from those regarding OO as akin to a cognitive orientation allowing observers to view the real world in a specific way, to the operational variety where the OO programming implementation is the main touchstone. If some of these individual definitions are later elaborated by associated features, this results in reiteration of some of the 'fundamental elements of the object world' identified by Booch which we have seen have far wider domains of application. Encapsulation, abstraction, and inheritance hierarchy have already been discussed. Other concepts include the following. • Reuse. This is an aim of all software developers, it is not essentially a component of OO, although the abstract and modular nature of objects should facilitate and encourage reuse. • Communication. Objects communicate via message passing: this allows an added dimension for conceptualizing systems behaviour and interactions. This perspective is not, however, aided by statements such as Booch's that 'message, method, and operation are usually inter-changeable' (p 515) • Polymorphism. This relates to the aim of designing code that can manipulate objects of different types. Again this is an aspiration rather than an intrinsic feature, although at the levels of detailed design and implementation it has succeeded in achieving the status of design principle. In general these features seem wholly admirable, but again not unique or specifically restricted to the OO approach. (Although it can be argued that polymorphism and communication through type hierarchy are unique to OO.) Taken together they are almost certainly enormously useful as programmer-based abstractions, and that is perhaps the whole point. Overall the concept of the object does seem to offer significant improvements on its more restricted and nebulous predecessor concept the entity, particularly in the former's incorporation of the dynamic with the static aspects of a system. Furthermore the applicability and utility of OO to the practice of programming is not in question, but is it giving us any more than that? To listen to the OO enthusiasts it would seem so. For those such as Shlaer and Melior 5, Coad and Yourdon 3, Rumbaugh e t a l . 4 Information and Software Technology 1994 Volume 36 Number 1
O0 oversold: A Bryant and A Evans
Coleman et al. 14 and many others, OO is able to provide a seamless, universal domain within which all issues relevant to systems development, extending from requirements capture to implementation, can be expressed. Verification and reconciliation of abstraction notations are no longer the critical areas of uncertainty they once were. Unfortunately the central tenets of OO are not quite as obvious and indisputable as they would have us believe. These principles may in due course become obvious and indisputable, although we would challenge that presumption; but at present the term paradigm, defined by Kuhn ~ as 'the entire constellation of beliefs, values and techniques and so on shared by members of a given community' (p 175), is not applicable to OO with regard to the community of systems developers: we shall use the phrase OO approach or perspective instead.
Objects of obscure desire? The rationale underlying the rapid adoption of OO is the belief that it provides a powerful and usable abstraction of the key features of the problem domain--'OO brings extra emphasis to the understanding of problem domains '3. This derives from the assumption noted earlier, that the OO perspective is somehow natural, and moreover capable of near-seamless transformation from requirements to implementation. From the previous section we have stated our vie~ that much of what passes for OO is in fact a mixture of generally accepted best practice and solid aspiration. If OO is to prove anything more than this its power will have to emanate from the object itself. The object will need to serve as the basis which will support systems developers as they cope with Brooks' ineluctable essences. But do these obscure objects of desire transcend the essential paradoxes of systems development? When the OO approach is viewed in light of Brooks' essences, a number of general observations can be made about its benefits, particularly as they apply to requirements analysis. Complexity
Although objects provide abstractions which can potentially hide complexity, there are a number of drawbacks when using the approach in requirements analysis: Naturalness. The OO approach claims to reduce com-
plexity by providing a 'natural and intuitive' abstraction of the problem domain. The great appeal of OOA is that it is claimed all the analyst has to do is identify the real world objects in the problem domain and specify them. This sounds ideal, but it ignores the fact that the problem domain is no more object-oriented than it is function-oriented or event-oriented. Although the requirements domain may contain certain (usually real-life/physical) entities that are eas) to identify and abstract as objects (lift buttons, etc.), other aspects of the system may be more appropriately identified and modelled in functional, or event terms. Furthermore, the fact that the object model attempts to represent reality so closely (using terms and representations borrowed unaltered and uncritically from the problem Information and Software Technology 1994 Volume 36 Number 1
domain), may make it far easier to misuse and misinterpret than other modelling techniques--which do not purport to model the world so directly, and hence demand a more discriminating mode of representation. For instance, the initial identification of objects is difficult because it is often hard to decide on what is a real world object and what is an appropriate system object. Is a purchase an object, an operation or an event? In reality it may be all of these, and during requirements capture it will be crucial that the full nature of the domain is defined. Meyer may have been correct when he said that 'the objects are there for the picking'7; but selecting the correct one is a problematic task. (In our experience of teaching OO principles, students using the ATM example from OMT find it very ditticult to extract the correct objects from the specification. In particular they find the distinctions between customer, cash card, account and transaction far from obvious.) In this way OOA may actually undermine effective requirements capture and specification, allowing the presumption that whatever the problem domain, it is best specified in OO terms. To someone with a hammer, every problem resembles a nail: to a wholehearted OO adherent, every requirement resembles a series of interacting objects. A suspicious reader might note that the examples used by OO authors to illustrate their perspective are more than a little slanted to permit application of OO concepts. As a didactic device this is perfectly acceptable, but as evidence of the universal applicability of OO it is at best questionable. Refinement. One of the major advantages claimed for OO
development by many authors is that, unlike structured methods, the translation from the analysis model to the design model is much simplified. Coad and Yourdon make this claim, and stress that the singular abstraction medium is the key: 'It's a matter of using the same underlying representation in analysis and design. This is the bedrock concept of the [OOA] approach '3. Unfortunately, although this may be the case for simple text book examples, it does not prove the case for more complicated systems. Objects identified during the analysis phase may serve as a skeleton for the eventual design, but the need to optimize the design often means that the designer must introduce 'additional classes, attributes, associations, and operations '4. In this case, a direct mapping from the analysis model to the design model would not be guaranteed, since it is possible that any addition or alteration might compromise the integrity of the system. (Again our experience with the OMT ATM example has demonstrated the complexity of accomplishing the transition from the initial object model of the analysis phase to that of design and implementation.) Conformity
That software has to conform to a vast range of human artefacts is not in dispute. At the level of code itself, conformity certainly seems facilitated by the OO approach. Indeed the concept of polymorphism appears to go some way towards a basis upon which this relentless pressure to conform can be controlled. But the literature is not entirely convincing, partly exacerbated by the tendency to provide illustrations for polymorphism which amount to a 39
O0 oversold: A Bryant and A Evans predesigned interface, or external aspect, into which all external objects must fit. This in fact undermines conformity, forcing other artefacts to conform to the software. Again, we can go some of the way to support this, since it effectively constrains the range of behaviours permissible by external factors, and this is probably a good thing. But it still does not overcome the problem of pressures to conform with less malleable features of the environment. Changeability Given the infinite demand for changed functionality, and the way this is increasingly sought from the software components of manufactured articles, the OO approach at the level of components appears to be an advance. But it can only offer this advance if there is a clear view of requirements which is independent of the components available: otherwise analysis simply becomes a case of selecting from among available object components rather than identification of genuine requirements. Reuse. The argument for reuse at the code level is well rehearsed and readily accepted. The reuse of existing analysis objects is widely cited as a possible means of reducing the effort and complexity required in systems analysis. The idea of a software factory producing systems to customer order has been a key theme in the writings of some OO adherents, particularly Brad Cox. Systems are, however, not standardized and are subject to enormous variations. Real world domains that initially appear 'small' and comprehensible, often reveal themselves to be very complex when analysed. The difficulty of identifying, capturing and organizing objects, let alone 'appropriate' reusable objects, is often underestimated by OO literature. Toy domains such as the library system or the automated teller machine system, which have become popular in the academic community to highlight the benefits of OO, illustrate only some of the issues faced by OO analysts. They are inadequate and seriously misleading because they fail to convey an understanding of the practical and intellectual difficulties of the analysis of real life domains. Thus colleagues of ours who have endeavoured to model systems which involve specified user roles and responsibilities have found that the OO approach appears to offer a solution, but only at the expense of effacing or simplifying the complex interactions required for the system to function effectively. Indeed, it is difficult to find any literature on OOA that tries to address these issues*. Invisibility The OO adherents clearly feel that objects are more tangible and manipulable than any alternative conceptual devices. If this is the case then OO will mark a significant advance for developers, but it will still not necessarily mean that all other approaches are redundant or secondary. Reiterating
*Booch recommends the use of Domain Analysis as an approach to object identification, However, Domain Analysis is still in its infancy and thus far lacks method, formality and tool support.
40
the point made above about the dangers of spurious naturalism, making software visible in a misleading way is worse than accepting its intrinsic intangibility. The overall conclusion must be that OO does offer some advances at the levels of design and implementation; but is no more natural for requirements capture and analysis than is any other approach--perhaps even less so. We would see the claims for OOA, in particular that they offer a simpler route to capture of requirements and afford the potential of reuse and refinement, as dubious at best, and probably spurious. Those with long memories might recall the claim, made in the 1960s, that Cobol was so simple and like natural language that eventually 'every business man [ sic ] will be able to produce his own software'! The wilder claims made for OO may prove as unjustified, but that is not to deny that OO may prove as enduring in a more specialized way; just as Cobol has. O O methods The desire to extend OO into the realm of analysis and requirements capture has led some to outline O 0 'methods', detailing approaches which encompass OOA, O 0 design (OOD) and O 0 implementation. It is not the purpose of this paper to describe these methods in any detail. However, a cursory review of some of these O 0 approaches yields some interesting conclusions. Apart from the general concept of an object, there is little which is common to all of them, which would not also be common to non-O0 approaches. For example, many of the same modelling techniques used in structured approaches (entity relationship diagrams, state transition diagrams, dataflow diagrams, etc.) are used in OO methods. A further criticism which can be directed at most O 0 methods is that they view O 0 as pervasively applicable and totally effective, and thereby ignore some of the fundamental problems associated with traditional structured methods which O 0 methods also fail to solve. Attempts to indicate and remedy these areas of weakness have been progressing since the latter part of the 1980s 15. They cover many significant areas, but at this juncture we wish to consider just two: formal specification and methodology. Formal specification A serious deficiency of structured methods is their reliance on informal and imprecise techniques and products. Many of their component techniques, such as the construction of Data Flow Diagrams (DFDs), and Entity Life Histories (ELHs), have little formal basis; i.e. there is often no rigorous way to ensure that a set of well-formed diagrams has been produced; nor that different types of model form a consistent whole. More importantly, because there is no formal meaning, such models are of limited use for verifying that the transition from one stage to another, particularly from analysis to design, is correct. Experience of auditing a number of large software developments, in which these techniques have been applied, has shown that it is precisely these ambiguities in the analysis phase together with the inability to verify formally the design and implementation against the requirements, that are a Information and Software Technology 1994 Volume 36 Number 1
O 0 oversold: A Bryant and A Evans
key source of problems. The issue of formal specification seems to have gone unrecognized by many of the developers of new OOA/OOD methods, who have incorporated many of the techniques previously used in structured methods in their own OO methods, with little regard for formality. Often, additional features are added to make the notations more objectoriented with little consideration given to their precise meaning. For example, Hayes and Coleman ~6 have highlighted consistency problems with the techniques used in RMT, which have arisen as a result of the informal way in which the techniques have been integrated. This criticism is taken further in their later work on the FUSION approach ~4. Another example is the lack of any formal basis for the interstate machine primitives (message passing) used by many of the methods. This means that the behaviour of an interacting community of objects cannot be discerned--a serious deficiency if the behaviour of all but the most trivial OO systems is to be properly understood. Lack of formal expression is also highlighted by the confusion over exactly what OO means. This is reflected in the way that some authors define their understanding of the terms they use. For example Rumbaugh et al. ~ define inheritance as a mechanism of sharing attributes and operations based on generalization, which allows for the overriding of class attributes as a means of removing attribute and operation redundancies. Coad and Yourdon 3, contrarily, explicitly forbid overriding, but instead use the notion of a class hierarchy lattice. Such differences are not too surprising given the novelty of the OO approach. The danger, however, is that they are open to misunderstanding and misinterpretation of the system model by both the client and other analysts. One could legislate for uniform standards in this developing area, but we would contend that a more precise description of these terms is a much needed step. A rigorous definition of the syntax and semantics of OO approaches, highlighting their commonalities and divergences, would do much to provide a sound basis for pragmatic future development.
better use of techniques, rather than on their constant re-invention. As we argued earlier, problem domains are no more object-oriented than event- or process-oriented. However, in the majority of OOA methods, object identification is the key starting point of the analysis process. This means that the analyst is forced to recast non-object-oriented aspects of the problem domain into OO terms before they can be represented properly. For example, the principle of encapsulation ensures that every class must contain the operations which apply to it. It is, however, not difficult to think of functions in which several objects participate but no one object owns. In such cases, pseudo classes must be constructed in order that the rules of OO are not broken. Another example is that of continuous processes. In an OO view, these must be represented by state machines associated with timers, a distinctly artificial approach. Analysis paradigms which are not design-independent force the analyst to alter the world to fit the paradigm. The need for this mental conversion process reduces the value of the analysis model as a representation of reality. Thus, in order to understand the analysis model, the analyst and customer have to be aware of the preconceptions embodied in it. Such a pedantic approach to analysis, in which objects must be identified first, is undesirable for this reason. Instead, a more flexible and implementation-independent approach is required. This can only by achieved if there is a developing realization of the full scope and nature of reliable and effective methods or approaches for systems development. We are not arguing for a rejection of OO, rather for an acceptance of the approach as an additional factor in the developers" unavoidable encounters with the essences of software development. A greater reflection of the ways in which structured methods have developed over the last decade or so would temper some of the wilder claims made for OO, as well as indicating a practical vehicle for its wider endorsement and application.
Methodology
Thus far we have argued that although OO does offer some significant advantages, many of the claims made for OO are highly problematic and possibly fanciful. Furthermore, emerging OO methods have generally failed to address many of the critical deficiencies of traditional structured methods, merely assuming that the object will cure all. We believe OO should be viewed as an additional and potentially useful approach available to the software developer: particularly at the level of detailed design and implementation. If the full power of OO is to be harnessed, a framework must be provided which situates OO against the key features of the software development process. This process must be seen to encompass a range of issues which can be resolved with intelligent application of a wide variety of fundamental techniques and principles, including OO, structured and formal techniques amongst others. These must be instituted in such a way that their domain of use, strength, limitations, and relationships to other approaches are clarified and understood: similarly for any tools which offer support for these techniques. For
If a formally grounded expression of central OO concepts is one solution for consolidating and realistically evaluating the potential of OO, the other quest is for a firm methodological grounding for the approach. Although there are a large number of emerging new OO methods, many of the modelling techniques they use are clearly very similar. For example, entity relationship diagrams, state transition diagrams and data flow diagrams have proven themselves many times over as powerful tools for modelling the data, behaviour and functionality of both structured and objectoriented systems. The problems arise if there is no agreement about, or clear vision of, the available techniques and their applicatic, n and relationships. There is a demand for a set of fundamental principles guiding systems methods as a whole, as well as outline modelling techniques for OO approaches themselves. This is preferable to the chaotic proliferation of methods occurring at present. If such bases could be defined, more emphasis could be placed on the h~r,,uai(m and Software Technology 1994 Volume 36 Number 1
The way forward
41
O 0 oversold: A Bryant and A Evans
instance, a safety critical system would require greater emphasis on the incorporation of formal methods, while a generic system application incorporating a wide range of manipulations of essentially similar items would probably be effectively developed using a predominantly OO approach. In this way, the software developer is not locked into one particular way of viewing a system. Rather, there is greater emphasis on a more theoretical and generic understanding of techniques, which seeks to surpass the 'madness of methods and notations '9. The level of communication required must also be considered within this framework: not simply the communication between the analyst and the customer (a prime feature of OO methods), but also the unambiguous communication required between members of the development team. Finally coherent project planning and overall management need to be stressed in terms of the framework that they can provide for decision making, quality assurance, product reviews, and the like. This project of Methods Integration has become a key concern in recent years. In 1991 the methods integration group at Leeds Metropolitan University was set up to investigate approaches relating to the general area of methods integration. This work is currently developing along two complementary routes. The first is concentrating upon efforts to link specific systems models with formal, mathematically based models: in effect integrating systems models. The second route focuses on the concept of a method itself; seeking to develop a fully articulated framework for systems development, potentially encompassing a range of methods together with decision points and selection criteria for method selection.
Conclusions In this paper we have argued that some recent developments in OO technology are highly problematic and possibly fanciful. To some extent their current popularity may be due to their potential role as a panacea for the key problems associated with software development. We have shown that such hopes are unreasonable, particularly with regard to the extension of the principles of object-
42
orientation from the sphere of programming and detailed design into analysis and top level design. We have proposed a more general approach which places greater emphasis on theoretical understanding while retaining the usability of existing OO methods. OO is no more natural a way of building abstractions--all of which are inherently artificial--than any other. OO must be judged in terms of its usefulness and effectiveness without recourse to ontological rectitude (naturalistic claims). People no more think in terms of objects than they do in terms of any other specific abstraction. OO may be perfectly natural, wholesome and sufficient in a buildingblock world, but who wants to live in Legoland anyway?
References 1 Booch, G Object-orienteddesign with applications BenjaminlCummings (1991) 2 Cox, B J 'Planning the software industrial revolution' IEEE (November 1990) 3 Coad, P and Yourdon, E Object-oriented analysis 2nd Edn Yourdon Press (1992) 4 Rumbaugh, J, Blaha, M, Premerlani, W, Eddy, F and Lorensen, W Object-oriented modelling and design Prentice-Hall (1991) 5 Shlaer, S and Mellor, S Object-oriented systems analysis Prentice-Hall
(1988) 6 Bryant, A, Semmens, L and Allen, P 'Workshop on methods integration', draft proceeding, available from the authors at Leeds Metropolitan University (September 1991) 7 Meyer, B Object-oriented software construction Prentice-Hall (1988) 8 Hoydalsvik, G M and Sindre, G 'On the purpose of object-oriented analysis' OOPSLA (1993) 9 Constantine, L L 'Object-oriented and structured methods: towards integration' American Programmer Vol 2 No 7/8 (August 1989) 10 Brooks, F P 'No silver bullet' Computer (April 1987) pp 10-19 11 Kuhn, T S The structure of scientific revolutions 2nd edn Chicago University Press (1970) 12 Wirfs-Brock, R J, Wilkerson, B and Weiner, L Designing objectoriented software Prentice-Hall (1990) 13 Martin, J and Odell, J Object oriented analysis and design PrenticeHall (1991) 14 Coleman, D, Arnold, P, Bodoff, S, Dollin, C, Gilchrist, H, Hayes, F and Jeremes, P Object-oriented development: the fusion method Prentice-Hall (1994) 15 Bryant, A 'Structured and formal methods', in Nichols, J (ed) Proceedings of the Z user group 1990 Springer-Verlag (1990) 16 Hayes, F and Coleman, D 'Coherent models for object-oriented analysis' OOPSLA (1991)
Information and Software Technology 1994 Volume 36 Number I
O 0 oversold Those objects of obscure desire Tony Bryant and Andy Evans BT Reader in Software Engineering at Leeds Metropolitan University, The Grange, Beekett Park, Leeds LS6 3QS, UK Research Assistant at Leeds Metropolitan University, The Grange, Beckett Park, Leeds LS6 3QS, UK
The principles of object-orientation have been widely used in the area of programming for some time. Their application to the design and specification of software has proved beneficial in a number of ways. In recent years there have been numerous attempts to exploit the same principles in high level design and the analysis of systems requirements. In many cases this has been achieved by extending the principles of object-oriented programming to the earlier phases of analysis and design without recognition that activities and objectives in the different domains may be dissimilar. This paper demonstrates that the endeavour to extend the principles of object-orientation into an all-encompassing method is ill-considered, and that an expansive view of methods integration is more likely to prove conducive in harnessing the strengths of objectorientation to alternative approaches to systems development. Keywords: object-orientation, methods integration, systems development
Object-orientation (OO) emerged almost simultaneously in various fields in computer science during the 1970s~; this included areas as diverse as computer architecture, databases and artificial intelligence, although perhaps the most important contribution derives from object-based and objectoriented programming languages. These include, Simula, CLLI and ADA, and what is often called the first true OO programming language, Smalltalk. As a consequence of this origin in relatively esoteric and constrained programming and development environments, OO was often associated with small-scale programming and rapid prototyping. For example, both of these features are facilitated by Smalltalk's development environment. Over the past 10 years or so OO has found many proponents, particularly amongst software designers and programmers who have come to appreciate its facilities for reuse, data abstraction and rapid prototyping affording a powerful and more intuitive approach to software development. This practitioner-led impulse has coincided with the promise of increased productivity from OO developments, as argued by Cox, amongst others 2, who detect the possibility of genuine component manufacture with consequent economies of scale, once authentic OO software production has evolved. An earlier version of this paper was presented at the OT93 Conference, April 1993. 0950--5849/94/010035-08~ 1994 Butterworth-Heinemann Ltd
Given this promise, and some limited tangible success in the realm of code production, more recent work has been carried out to extend OO principles to the earlier development activities of design and requirements analysis. This extension has led to the construction of a number of OO 'methods', purporting to encompass a larger proportion of the development process, or even the full scope of system development from requirements capture to implementation3-5. We would argue that such expansion has been envisaged in too simplistic a manner, and that the harnessing of OO must be seen as one aspect in the strategy of methods integration, rather than as an all-encompassing development perspective.
The extending of the OO domain The demand or desire for application of OO beyond the programming phase emanates from a number of sources. One key motivation has been the desire to mimic the expansion that the predominant precursors of OO approaches, collectively termed Structured Methods, effected. Thus structured programming appeared in the late 1960s, and achieved a large measure of acceptance during the 1970s, aided by the appearance of programming languages more akin to structured concepts and abstractions. This later led, by the 1980s, to the growth of more encompassing 35
O0 oversold: A Bryant and A Evans 'methods' incorporating design and analysis. The initial impetus behind this structured revolution may well have been that designers and implementors were keen to fashion much of the output of initial phases of development in as immediately utilizable a form as possible for later implementation purposes. This offered a direct enhancement to the process of verification. Enabling (i.e. compelling or constraining) users and developers to capture and express requirements in a series of structured abstractions made the task of transposition to code easier, less risky and more dependable: with luck it was also a surer way of producing usable, useful and reliable systems. In time, structured methods evolved far beyond this original abstraction-based view. They now (1990s) at least attempt to account for a whole host of other critical factors apart from the eventual design and implementation vehicle. This does not mean that structured approaches have, or indeed can, solve all problems of systems development*. As new developmental strategies appear in a specific domain they will either complement or supplant existing ones. Initially the adherents of such innovations will tend to perceive a wide application for their particular approach, possibly extending beyond the bounds of its actual use. This explains the aspirations of OO adherents to establish ways in which the OO approach can be augmented to resolve an increasing range of developmental problems and paradoxes. In the narrow cast, this has been motivated by those wanting to produce high-level designs that can be fashioned in OO terms so that there can be a rapid and easy translation into the target OO programming language. In wider terms, some analysts have seen OO as providing a 'natural way of modelling' the problem domain itself. Thus Coad and Yourdon introduce their book on OO analysis (OOA) with the statement that ' O O A . . . is based upon concepts that we first learned in kindergarten '3. In general OO partisans often preface their work with statements to the effect that the object view of the world is akin to the natural, everyday one. There seems to be little justification for this claim (as will be argued later, there are the same problems in identifying objects in the OO approach as there are in identifying entities in data-driven and structured ones), but it is partially explained by the origins of OO amongst programmers to whom objects--particularly when viewed as implementations of abstract data types (ADTs)--are probably as natural as any abstraction can be. The failure to make clear distinctions between the two positions--OO as augmentation and OO as self-contained and sufficient alternative--has inevitably led to some confusion. Does the OO approach supplement existing approaches; or is it an irreconcilable alternative? Many of the current OO protagonists seem to suggest that structured analysis techniques (such as those found in Yourdon Structured Analysis, SSADM, Information Engineering) cannot be used effectively when subsequent design and implementation is to be carried out in an object-oriented *Recent work on methods integration stems from the recognition that no single approach is sufficient--this applies just as much to OO approaches as to all others 6. 36
mannerS'V: others claim the contrary 9. The perceptive reader will already have noticed some degree of scepticism in these remarks. In what follows, we wish to examine some key features of the emerging OO 'methods'; aiming to demonstrate that although in some specific aspects they provide advances on their functionoriented, structured predecessors, in general they have failed to address many of the problems associated with the problem domain of systems development as a whole. This leads us to our conclusion that the sole feasible and appropriate trajectory for these advances is provided by the admittedly chaotic but experientially and practically sound bases offered by existing, non-OO approaches. You cannot simply jettison the 'structured baby' with the 'functional bathwater'. This is not to say that OO and any other innovative approaches must align with or rest upon bases offered by structured and other precursors; but neither should it be assumed that these earlier methods can be simply effaced, and the lessons gained from their use forgotten. The problem domain which is the target of all approaches to information systems development is the inherently chaotic and non-systemic one of human social--and, slightly more constrained--organizational activity. This domain is no more 'object-oriented' than it is 'functionoriented' or 'event-oriented'*. On the contrary it is usually readily acknowledged by systems developers that they have to introduce and refine abstractions which capture and concentrate upon certain key features of the development context. None of these abstractions can be considered natural; they are by implication artificial constructs which are at best useful or elucidatory. Thus one cannot judge whether an abstraction such as 'citizen' is useful or not without recourse to the specific system context. On the other hand the entity 'citizen' is no more or less natural than the object 'citizen', and the function of 'citizenship' is similarly devoid of meaning without clarification of use and context. Different orientations can be best judged, at first impression, with reference to their usefulness in providing abstractions which are of value at one or more points of reference within the domain itself: i.e. whether or not they provide a more accessible perspective for consideration of usability, reliability, criticality, and so on. At a more advanced stage of knowledge and theoretical maturity, and assuming that the method has offered at least some semblance of purposeful deployment, consideration should be turned to issues of theoretical soundness, compatibility with other perspectives, semantic meaning and methodological guidance. These aspects have already been identified as weaknesses in most structured (algorithmic or function-oriented) methods. Unless the developers of OO methods address these issues, not only will the advantages of the object-oriented approach be lost, but it will not be long before the term object-oriented is dissociated from good software engineering practice, simply taking its place among the other, now discarded panaceas. *Since first developing this point and presenting this paper, the authors have become aware of a similar argument from a group in Norway s.
Information and Software Technology 1994 Volume 36 Number 1
O0 oversold: A Bryant and A Evans We shall suggest that a more general approach is demanded; one which seeks to encourage more flexibility, coupled with greater emphasis on the theoretical foundations of the models and techniques (including OO ones) used in all kinds of development. We shall also raise the more fundamental issue of whether the OO approach is a suitable one for requirements analysis at all, and what might the consequences be should the approach be found inappropriate.
No O 0 silver bullets In his influential paper No Silver Bullet ~°, Brooks argued that the inherent issues of software development emanate from four essences or ineluctable features of software engineering: these applying as much to the objective of software engineering (better software) as to the process (better practice). These essences were labelled as complexity, conformity, changeability and invisibility. The detail of his paper can be summarized along the following lines: Complexity. Software is inherently complex, it cannot be simplified: this complexity is not merely a technical issue, it also has ramifications for the planning, management and control of software projects. Conformity. Software does not perform in isolation, but has to interface and co-operate with a multitude of other human arte[acts, each of which is idiosyncratically designed, and each of which is less malleable than the software; hence the software has to adapt, not be adapted to. Changeability. Since software is an embodiment of functionality it is subject to constant and continued pressures to change, adapt, and modify. In addition, the use of software itself engenders innovations and imaginative extensions of the software or software/hardware configuration. Invisibility. This chameleon-like complexity and transmutability is further complicated by the total lack of any extensive conceptual representations capable of incorporating all or even most of this intricacy. Does OO confront these essential challenges? Writing in 1985 Brooks argued that OO programming does hold out some promise; but that, at best, it will serve to remove 'accidental' difficulties rather than ameliorating the essential ones themselves. Thus 'abstract data types' and 'hierarchical types' (the two features singled out by Brooks as characterizing OO) remove yet another accidental difficulty from the process, allowing lhe designer to express the essence of the design without having to express large amounts of syntactic material that add no information content (p 14) In other words, ADTs and HTs are useful and potent as detaded design abstractions, permitting developers to concentrate on central features of the object domain. This can be done without having to be concerned with the Information and Software Technology 1994 Volume 36 Number 1
programming language semantics, but in such a way that the transition from specification to code is relatively straightforward. (Or at least less complex than it would otherwise be if abstraction mechanisms other than ADTs and HTs were employed.) We find ourselves in complete agreement with this view. Particularly since it coincides with our point that OO is natural only in these critical but restricted confines between detailed design and coding. To what extent has the expansion of OO into higher levels of design, and latterly analysis, developed further positive aspects which might counteract Brooks' essences? Prior to offering an initial assessment, it is worthwhile summarizing the key features of the OO perspective, or O 0 paradigm itself. The O0 paradigm It is interesting that many of the texts on OO use the term paradigm in their discussions. The term has derived its current meaning from the work of T S Kuhn t~ in which he distinguished between knowledge domains with wellfounded assumptions and those where the basic principles were themselves contested or questionable and consequently always in need of justification. Thus a subject or discipline could be termed paradigmatic when basic principles were generally accepted by the broad spectrum of experts and aficionados: if no such set of fundamentals existed, the domain was termed pre-paradigmatic, implying that eventually a paradigm would emerge. The champions of OO are therefore stressing that the principles of the perspective have--or very soon will--become generally accepted amongst all systems practitioners. The non-OO mavericks will gradually fade into the background or convert to the new order of things. If this is the case, we should find broad and clear consensual agreement on the basic tenets of OO; with many of the fundamental characteristics taken for granted by practitioners and publicists alike. The current literature on OO is growing exponentially, but there are a number of central sources to which a significant proportion of OO publications refer. The classic reference for many is Grady Booch on OO ~. Although slightly dated, it is still the text to which most OO authors refer in support of their opening arguments defining the key characteristics of the approach. Some have criticized the Booch notation, but none of the protagonists has questioned his basic assumptions: and it is these which are central to our present argument. Booch defines the 'object model' as encompassing the 'principles of abstraction, encapsulation, modularity, hierarchy, typing, concurrency, and persistence'. Given Booch's position as one of the authorities on OO, this is a strange starting point. After all, many of these principles can be found in non-OO contexts. It is worth examining each of these concepts in turn to see if they justify the claim for OO to be a new paradigm; a revolution in system specification. Abstraction. This is defined by Booch as 'the process of focusing upon the essential characteristics of an object' 3"/
O0 oversold: A Bryant and A Evans (glossary, p 513); in more general terms, however, it is an inescapable aspect of any modelling activity. • Encapsulation. 'The process of hiding all of the details of an object that do not contribute to its essential characteristics' (glossary, p 513). This is another term for what Parnas described as 'information hiding'. The ambiguity concerning 'essential characteristics' is noted below.
• •
Modularity. 'The property of a system that has been decomposed into a set of cohesive and loosely coupled modules' (p 515). The recognizable basis of structured methods. • Hierarchy. 'A ranking or ordering of abstractions' (p 514). This is somewhat nebulous, but if it is meant to invoke the concept of inheritance, then this can also apply to entity models with sub-types and super-types. Typing. 'The enforcement of a class of an object' (p 519). This can be found implicitly in many programming contexts, but explicitly in all those espousing the employment of ADTs. Concurrency. 'The property that distinguishes an active object from one that is not' (p 513). The term, possibly understood differently, is a feature of all communicating systems. Persistence. 'The property of an object by which its existence transcends time' (p 517). This is applicable to all forms of data-oriented approaches, not just OO ones. The OO paradigm does not then seem to be based on intrinsically different concepts from non-OO approaches. Moreover this does not appear to square with the claim that OO is such a natural approach. For all non-OO practitioners, the use of OO's central terms is anything but naturally object-centred: on the contrary the terms resonate with meanings far removed from those applied by the OO adherents. The only concept which is perhaps uniquely marked as object-oriented is the object itself. Not only is the case for a new paradigm unproven with respect to OO: many of its key concepts are simply those of existing approaches still retaining their meaning. The only concept unique to OO is that of the object itself, and that appears to be far from paradigmatic in the sense of evoking a single agreed meaning. Objects Central to the object-oriented approach is the notion of the object. But what exactly is an object. Although it is easy to state what the properties of an object are (it has state, attributes and functions), and to give examples of objects, (book, car, manager, etc.), the term itself is often a difficult one to define. Perhaps this reflects the fact that objects mean different things to different people, depending upon their view of reality. The following represent definitions of 'object' from a number of well-regarded sources. • 'a tangible entity that exhibits some well defined behaviour' 38
•
--Booch ~ who then goes on to generalize this definition to 'anything which has a well defined boundary'; 'an abstraction of the problem domain, reflecting the capabilities of the system to keep information about it, interact with it, or both'--Coad and Yourdon3; 'a thing that retains certain information and knows how to perform certain operations'--Wirfs-Brock et al. ~2; 'concept, abstraction or thing in the world with crisp boundaries meaningful for the problem at hand to promote understanding of the real world and provide a basis for computer implementation'--RMT, Rumbaugh et al.4; 'anything to which an Object Type applies'--Martin and Odelll3; 'a "thing" that can be distinctly identified'--Coleman et al.~4 (stress in original).
This is hardly a definitive and harmonious basis for a paradigm. The definitions range from those regarding OO as akin to a cognitive orientation allowing observers to view the real world in a specific way, to the operational variety where the OO programming implementation is the main touchstone. If some of these individual definitions are later elaborated by associated features, this results in reiteration of some of the 'fundamental elements of the object world' identified by Booch which we have seen have far wider domains of application. Encapsulation, abstraction, and inheritance hierarchy have already been discussed. Other concepts include the following. • Reuse. This is an aim of all software developers, it is not essentially a component of OO, although the abstract and modular nature of objects should facilitate and encourage reuse. • Communication. Objects communicate via message passing: this allows an added dimension for conceptualizing systems behaviour and interactions. This perspective is not, however, aided by statements such as Booch's that 'message, method, and operation are usually inter-changeable' (p 515) • Polymorphism. This relates to the aim of designing code that can manipulate objects of different types. Again this is an aspiration rather than an intrinsic feature, although at the levels of detailed design and implementation it has succeeded in achieving the status of design principle. In general these features seem wholly admirable, but again not unique or specifically restricted to the OO approach. (Although it can be argued that polymorphism and communication through type hierarchy are unique to OO.) Taken together they are almost certainly enormously useful as programmer-based abstractions, and that is perhaps the whole point. Overall the concept of the object does seem to offer significant improvements on its more restricted and nebulous predecessor concept the entity, particularly in the former's incorporation of the dynamic with the static aspects of a system. Furthermore the applicability and utility of OO to the practice of programming is not in question, but is it giving us any more than that? To listen to the OO enthusiasts it would seem so. For those such as Shlaer and Melior 5, Coad and Yourdon 3, Rumbaugh e t a l . 4 Information and Software Technology 1994 Volume 36 Number 1
O0 oversold: A Bryant and A Evans
Coleman et al. 14 and many others, OO is able to provide a seamless, universal domain within which all issues relevant to systems development, extending from requirements capture to implementation, can be expressed. Verification and reconciliation of abstraction notations are no longer the critical areas of uncertainty they once were. Unfortunately the central tenets of OO are not quite as obvious and indisputable as they would have us believe. These principles may in due course become obvious and indisputable, although we would challenge that presumption; but at present the term paradigm, defined by Kuhn ~ as 'the entire constellation of beliefs, values and techniques and so on shared by members of a given community' (p 175), is not applicable to OO with regard to the community of systems developers: we shall use the phrase OO approach or perspective instead.
Objects of obscure desire? The rationale underlying the rapid adoption of OO is the belief that it provides a powerful and usable abstraction of the key features of the problem domain--'OO brings extra emphasis to the understanding of problem domains '3. This derives from the assumption noted earlier, that the OO perspective is somehow natural, and moreover capable of near-seamless transformation from requirements to implementation. From the previous section we have stated our vie~ that much of what passes for OO is in fact a mixture of generally accepted best practice and solid aspiration. If OO is to prove anything more than this its power will have to emanate from the object itself. The object will need to serve as the basis which will support systems developers as they cope with Brooks' ineluctable essences. But do these obscure objects of desire transcend the essential paradoxes of systems development? When the OO approach is viewed in light of Brooks' essences, a number of general observations can be made about its benefits, particularly as they apply to requirements analysis. Complexity
Although objects provide abstractions which can potentially hide complexity, there are a number of drawbacks when using the approach in requirements analysis: Naturalness. The OO approach claims to reduce com-
plexity by providing a 'natural and intuitive' abstraction of the problem domain. The great appeal of OOA is that it is claimed all the analyst has to do is identify the real world objects in the problem domain and specify them. This sounds ideal, but it ignores the fact that the problem domain is no more object-oriented than it is function-oriented or event-oriented. Although the requirements domain may contain certain (usually real-life/physical) entities that are eas) to identify and abstract as objects (lift buttons, etc.), other aspects of the system may be more appropriately identified and modelled in functional, or event terms. Furthermore, the fact that the object model attempts to represent reality so closely (using terms and representations borrowed unaltered and uncritically from the problem Information and Software Technology 1994 Volume 36 Number 1
domain), may make it far easier to misuse and misinterpret than other modelling techniques--which do not purport to model the world so directly, and hence demand a more discriminating mode of representation. For instance, the initial identification of objects is difficult because it is often hard to decide on what is a real world object and what is an appropriate system object. Is a purchase an object, an operation or an event? In reality it may be all of these, and during requirements capture it will be crucial that the full nature of the domain is defined. Meyer may have been correct when he said that 'the objects are there for the picking'7; but selecting the correct one is a problematic task. (In our experience of teaching OO principles, students using the ATM example from OMT find it very ditticult to extract the correct objects from the specification. In particular they find the distinctions between customer, cash card, account and transaction far from obvious.) In this way OOA may actually undermine effective requirements capture and specification, allowing the presumption that whatever the problem domain, it is best specified in OO terms. To someone with a hammer, every problem resembles a nail: to a wholehearted OO adherent, every requirement resembles a series of interacting objects. A suspicious reader might note that the examples used by OO authors to illustrate their perspective are more than a little slanted to permit application of OO concepts. As a didactic device this is perfectly acceptable, but as evidence of the universal applicability of OO it is at best questionable. Refinement. One of the major advantages claimed for OO
development by many authors is that, unlike structured methods, the translation from the analysis model to the design model is much simplified. Coad and Yourdon make this claim, and stress that the singular abstraction medium is the key: 'It's a matter of using the same underlying representation in analysis and design. This is the bedrock concept of the [OOA] approach '3. Unfortunately, although this may be the case for simple text book examples, it does not prove the case for more complicated systems. Objects identified during the analysis phase may serve as a skeleton for the eventual design, but the need to optimize the design often means that the designer must introduce 'additional classes, attributes, associations, and operations '4. In this case, a direct mapping from the analysis model to the design model would not be guaranteed, since it is possible that any addition or alteration might compromise the integrity of the system. (Again our experience with the OMT ATM example has demonstrated the complexity of accomplishing the transition from the initial object model of the analysis phase to that of design and implementation.) Conformity
That software has to conform to a vast range of human artefacts is not in dispute. At the level of code itself, conformity certainly seems facilitated by the OO approach. Indeed the concept of polymorphism appears to go some way towards a basis upon which this relentless pressure to conform can be controlled. But the literature is not entirely convincing, partly exacerbated by the tendency to provide illustrations for polymorphism which amount to a 39
O0 oversold: A Bryant and A Evans predesigned interface, or external aspect, into which all external objects must fit. This in fact undermines conformity, forcing other artefacts to conform to the software. Again, we can go some of the way to support this, since it effectively constrains the range of behaviours permissible by external factors, and this is probably a good thing. But it still does not overcome the problem of pressures to conform with less malleable features of the environment. Changeability Given the infinite demand for changed functionality, and the way this is increasingly sought from the software components of manufactured articles, the OO approach at the level of components appears to be an advance. But it can only offer this advance if there is a clear view of requirements which is independent of the components available: otherwise analysis simply becomes a case of selecting from among available object components rather than identification of genuine requirements. Reuse. The argument for reuse at the code level is well rehearsed and readily accepted. The reuse of existing analysis objects is widely cited as a possible means of reducing the effort and complexity required in systems analysis. The idea of a software factory producing systems to customer order has been a key theme in the writings of some OO adherents, particularly Brad Cox. Systems are, however, not standardized and are subject to enormous variations. Real world domains that initially appear 'small' and comprehensible, often reveal themselves to be very complex when analysed. The difficulty of identifying, capturing and organizing objects, let alone 'appropriate' reusable objects, is often underestimated by OO literature. Toy domains such as the library system or the automated teller machine system, which have become popular in the academic community to highlight the benefits of OO, illustrate only some of the issues faced by OO analysts. They are inadequate and seriously misleading because they fail to convey an understanding of the practical and intellectual difficulties of the analysis of real life domains. Thus colleagues of ours who have endeavoured to model systems which involve specified user roles and responsibilities have found that the OO approach appears to offer a solution, but only at the expense of effacing or simplifying the complex interactions required for the system to function effectively. Indeed, it is difficult to find any literature on OOA that tries to address these issues*. Invisibility The OO adherents clearly feel that objects are more tangible and manipulable than any alternative conceptual devices. If this is the case then OO will mark a significant advance for developers, but it will still not necessarily mean that all other approaches are redundant or secondary. Reiterating
*Booch recommends the use of Domain Analysis as an approach to object identification, However, Domain Analysis is still in its infancy and thus far lacks method, formality and tool support.
40
the point made above about the dangers of spurious naturalism, making software visible in a misleading way is worse than accepting its intrinsic intangibility. The overall conclusion must be that OO does offer some advances at the levels of design and implementation; but is no more natural for requirements capture and analysis than is any other approach--perhaps even less so. We would see the claims for OOA, in particular that they offer a simpler route to capture of requirements and afford the potential of reuse and refinement, as dubious at best, and probably spurious. Those with long memories might recall the claim, made in the 1960s, that Cobol was so simple and like natural language that eventually 'every business man [ sic ] will be able to produce his own software'! The wilder claims made for OO may prove as unjustified, but that is not to deny that OO may prove as enduring in a more specialized way; just as Cobol has. O O methods The desire to extend OO into the realm of analysis and requirements capture has led some to outline O 0 'methods', detailing approaches which encompass OOA, O 0 design (OOD) and O 0 implementation. It is not the purpose of this paper to describe these methods in any detail. However, a cursory review of some of these O 0 approaches yields some interesting conclusions. Apart from the general concept of an object, there is little which is common to all of them, which would not also be common to non-O0 approaches. For example, many of the same modelling techniques used in structured approaches (entity relationship diagrams, state transition diagrams, dataflow diagrams, etc.) are used in OO methods. A further criticism which can be directed at most O 0 methods is that they view O 0 as pervasively applicable and totally effective, and thereby ignore some of the fundamental problems associated with traditional structured methods which O 0 methods also fail to solve. Attempts to indicate and remedy these areas of weakness have been progressing since the latter part of the 1980s 15. They cover many significant areas, but at this juncture we wish to consider just two: formal specification and methodology. Formal specification A serious deficiency of structured methods is their reliance on informal and imprecise techniques and products. Many of their component techniques, such as the construction of Data Flow Diagrams (DFDs), and Entity Life Histories (ELHs), have little formal basis; i.e. there is often no rigorous way to ensure that a set of well-formed diagrams has been produced; nor that different types of model form a consistent whole. More importantly, because there is no formal meaning, such models are of limited use for verifying that the transition from one stage to another, particularly from analysis to design, is correct. Experience of auditing a number of large software developments, in which these techniques have been applied, has shown that it is precisely these ambiguities in the analysis phase together with the inability to verify formally the design and implementation against the requirements, that are a Information and Software Technology 1994 Volume 36 Number 1
O 0 oversold: A Bryant and A Evans
key source of problems. The issue of formal specification seems to have gone unrecognized by many of the developers of new OOA/OOD methods, who have incorporated many of the techniques previously used in structured methods in their own OO methods, with little regard for formality. Often, additional features are added to make the notations more objectoriented with little consideration given to their precise meaning. For example, Hayes and Coleman ~6 have highlighted consistency problems with the techniques used in RMT, which have arisen as a result of the informal way in which the techniques have been integrated. This criticism is taken further in their later work on the FUSION approach ~4. Another example is the lack of any formal basis for the interstate machine primitives (message passing) used by many of the methods. This means that the behaviour of an interacting community of objects cannot be discerned--a serious deficiency if the behaviour of all but the most trivial OO systems is to be properly understood. Lack of formal expression is also highlighted by the confusion over exactly what OO means. This is reflected in the way that some authors define their understanding of the terms they use. For example Rumbaugh et al. ~ define inheritance as a mechanism of sharing attributes and operations based on generalization, which allows for the overriding of class attributes as a means of removing attribute and operation redundancies. Coad and Yourdon 3, contrarily, explicitly forbid overriding, but instead use the notion of a class hierarchy lattice. Such differences are not too surprising given the novelty of the OO approach. The danger, however, is that they are open to misunderstanding and misinterpretation of the system model by both the client and other analysts. One could legislate for uniform standards in this developing area, but we would contend that a more precise description of these terms is a much needed step. A rigorous definition of the syntax and semantics of OO approaches, highlighting their commonalities and divergences, would do much to provide a sound basis for pragmatic future development.
better use of techniques, rather than on their constant re-invention. As we argued earlier, problem domains are no more object-oriented than event- or process-oriented. However, in the majority of OOA methods, object identification is the key starting point of the analysis process. This means that the analyst is forced to recast non-object-oriented aspects of the problem domain into OO terms before they can be represented properly. For example, the principle of encapsulation ensures that every class must contain the operations which apply to it. It is, however, not difficult to think of functions in which several objects participate but no one object owns. In such cases, pseudo classes must be constructed in order that the rules of OO are not broken. Another example is that of continuous processes. In an OO view, these must be represented by state machines associated with timers, a distinctly artificial approach. Analysis paradigms which are not design-independent force the analyst to alter the world to fit the paradigm. The need for this mental conversion process reduces the value of the analysis model as a representation of reality. Thus, in order to understand the analysis model, the analyst and customer have to be aware of the preconceptions embodied in it. Such a pedantic approach to analysis, in which objects must be identified first, is undesirable for this reason. Instead, a more flexible and implementation-independent approach is required. This can only by achieved if there is a developing realization of the full scope and nature of reliable and effective methods or approaches for systems development. We are not arguing for a rejection of OO, rather for an acceptance of the approach as an additional factor in the developers" unavoidable encounters with the essences of software development. A greater reflection of the ways in which structured methods have developed over the last decade or so would temper some of the wilder claims made for OO, as well as indicating a practical vehicle for its wider endorsement and application.
Methodology
Thus far we have argued that although OO does offer some significant advantages, many of the claims made for OO are highly problematic and possibly fanciful. Furthermore, emerging OO methods have generally failed to address many of the critical deficiencies of traditional structured methods, merely assuming that the object will cure all. We believe OO should be viewed as an additional and potentially useful approach available to the software developer: particularly at the level of detailed design and implementation. If the full power of OO is to be harnessed, a framework must be provided which situates OO against the key features of the software development process. This process must be seen to encompass a range of issues which can be resolved with intelligent application of a wide variety of fundamental techniques and principles, including OO, structured and formal techniques amongst others. These must be instituted in such a way that their domain of use, strength, limitations, and relationships to other approaches are clarified and understood: similarly for any tools which offer support for these techniques. For
If a formally grounded expression of central OO concepts is one solution for consolidating and realistically evaluating the potential of OO, the other quest is for a firm methodological grounding for the approach. Although there are a large number of emerging new OO methods, many of the modelling techniques they use are clearly very similar. For example, entity relationship diagrams, state transition diagrams and data flow diagrams have proven themselves many times over as powerful tools for modelling the data, behaviour and functionality of both structured and objectoriented systems. The problems arise if there is no agreement about, or clear vision of, the available techniques and their applicatic, n and relationships. There is a demand for a set of fundamental principles guiding systems methods as a whole, as well as outline modelling techniques for OO approaches themselves. This is preferable to the chaotic proliferation of methods occurring at present. If such bases could be defined, more emphasis could be placed on the h~r,,uai(m and Software Technology 1994 Volume 36 Number 1
The way forward
41
O 0 oversold: A Bryant and A Evans
instance, a safety critical system would require greater emphasis on the incorporation of formal methods, while a generic system application incorporating a wide range of manipulations of essentially similar items would probably be effectively developed using a predominantly OO approach. In this way, the software developer is not locked into one particular way of viewing a system. Rather, there is greater emphasis on a more theoretical and generic understanding of techniques, which seeks to surpass the 'madness of methods and notations '9. The level of communication required must also be considered within this framework: not simply the communication between the analyst and the customer (a prime feature of OO methods), but also the unambiguous communication required between members of the development team. Finally coherent project planning and overall management need to be stressed in terms of the framework that they can provide for decision making, quality assurance, product reviews, and the like. This project of Methods Integration has become a key concern in recent years. In 1991 the methods integration group at Leeds Metropolitan University was set up to investigate approaches relating to the general area of methods integration. This work is currently developing along two complementary routes. The first is concentrating upon efforts to link specific systems models with formal, mathematically based models: in effect integrating systems models. The second route focuses on the concept of a method itself; seeking to develop a fully articulated framework for systems development, potentially encompassing a range of methods together with decision points and selection criteria for method selection.
Conclusions In this paper we have argued that some recent developments in OO technology are highly problematic and possibly fanciful. To some extent their current popularity may be due to their potential role as a panacea for the key problems associated with software development. We have shown that such hopes are unreasonable, particularly with regard to the extension of the principles of object-
42
orientation from the sphere of programming and detailed design into analysis and top level design. We have proposed a more general approach which places greater emphasis on theoretical understanding while retaining the usability of existing OO methods. OO is no more natural a way of building abstractions--all of which are inherently artificial--than any other. OO must be judged in terms of its usefulness and effectiveness without recourse to ontological rectitude (naturalistic claims). People no more think in terms of objects than they do in terms of any other specific abstraction. OO may be perfectly natural, wholesome and sufficient in a buildingblock world, but who wants to live in Legoland anyway?
References 1 Booch, G Object-orienteddesign with applications BenjaminlCummings (1991) 2 Cox, B J 'Planning the software industrial revolution' IEEE (November 1990) 3 Coad, P and Yourdon, E Object-oriented analysis 2nd Edn Yourdon Press (1992) 4 Rumbaugh, J, Blaha, M, Premerlani, W, Eddy, F and Lorensen, W Object-oriented modelling and design Prentice-Hall (1991) 5 Shlaer, S and Mellor, S Object-oriented systems analysis Prentice-Hall
(1988) 6 Bryant, A, Semmens, L and Allen, P 'Workshop on methods integration', draft proceeding, available from the authors at Leeds Metropolitan University (September 1991) 7 Meyer, B Object-oriented software construction Prentice-Hall (1988) 8 Hoydalsvik, G M and Sindre, G 'On the purpose of object-oriented analysis' OOPSLA (1993) 9 Constantine, L L 'Object-oriented and structured methods: towards integration' American Programmer Vol 2 No 7/8 (August 1989) 10 Brooks, F P 'No silver bullet' Computer (April 1987) pp 10-19 11 Kuhn, T S The structure of scientific revolutions 2nd edn Chicago University Press (1970) 12 Wirfs-Brock, R J, Wilkerson, B and Weiner, L Designing objectoriented software Prentice-Hall (1990) 13 Martin, J and Odell, J Object oriented analysis and design PrenticeHall (1991) 14 Coleman, D, Arnold, P, Bodoff, S, Dollin, C, Gilchrist, H, Hayes, F and Jeremes, P Object-oriented development: the fusion method Prentice-Hall (1994) 15 Bryant, A 'Structured and formal methods', in Nichols, J (ed) Proceedings of the Z user group 1990 Springer-Verlag (1990) 16 Hayes, F and Coleman, D 'Coherent models for object-oriented analysis' OOPSLA (1991)
Information and Software Technology 1994 Volume 36 Number I