The possibilities and the problems of object oriented programming methodologies… Object-orientation is the software buzz-word of the 1980s – but who really knows what it is? This was one of the problems raised at the Methods for Object-Oriented Software Engineering event held by the British Computer Society’s Object-Oriented Programming and Systems, OOPS, Specialist Group, held, appropriately enough at London Zoo in Regent’s park earlier this month. According to the independent consultant John Daniels, object-orientation is the last in a long line of panaceas stretching from assemblers, through fourth generation languages, to Computer-Aided Software Engineering tools. Companies like Oracle Corp will be pleased to know that among programmers represented at the event, software engineering tools are widely felt to be suffering a backlash. The problem being that they are often promoted as a panacea, yet, in Daniels’ words, if used by the unqualifed they have an effect similar to a machine gun in the hands of an idiot. Anyway, back to the concept in hand, what is object-orientation? Well, probably the most convincing definition given at the conference was Daniels’ argument that it is a religion. Converts to object-oriented methods intuitively believe in their benefits but have no empirical evidence to prove that they are beneficial. The methods themselves are currently prominent in four main areas. The most familiar of these areas is the object-oriented user interface such as GEM and MacDraw. These interfaces are object-oriented in dhe sense that the user deals directly with the objects to be manipulated rather than with the program which does the manipulation. Because this is the most popularised aspect of object-orientation it is held in some contempt by the OOPS fraternity, members of which do not take kindly to comments like ah yes object orientation – that’s playing with pictures on an Apple Mac isn’t it? The next main area where object-orientation is to be found is that of design, where Grady Booch pioneered work with real-time systems in the late 1970s, developing Ada as a package construct. Ada and other object-oriented design methods are founded on the idea that problems can be solved by creating a model of the real world in software. At present there is no uniform object-oriented design method, but there is a consensual attitude among the converted that four general design steps have to be taken. First of all, object-oriented programmers must specify the system using an entity model and a data flow diagram based on the real world. They must then produce an object model from the entity model and map the functions from the data flow diagrams to the objects. Finally, the object interfaces must be defined. Despite the fact that Ada follows these general design premises, Daniels feels that it is more of a teaching aid than a workable design concept for programmers. One of the main problems that he elucidated was its failure to consider the life histories or the inheritance of real life entities. After all if a programmer knows why, how and for what a component was designed he is more capable of re-using that component in future designs. Problem with Ada A further problem with Ada is that it does not incorporate the formal specification techniques already embedded in industry. Interestingly, both inheritance and formal specification are domains within object-orientation where there was consensus that work needed to be done. Nevertheless, within the Ada community some major systems are now being designed with Hierarchic Object Oriented Design, HOOD, developed by the European Space Agency with Ada as its target programming language. It is probably from this design method that the longer term benefits of object oriented design will flow. Another key domain where it was agreed that clarification is required is in the data abstraction field. Daniels suggested that research on semantic data modelling as found in the development of relational databases would prove useful in this sphere. For example, notations are c
urrently in existence that can identify whole-part and inheritance hierarchies, and which are thus invaluable to entity relationship modellers. Building on such notations is the third area where object-oriented models are in use, and an object oriented database should soon be developed that is able to connect behaviour directly to database entities. The final area in which object-oriented methods are found is, of course, that of object-oriented languages based round the Smalltalk model. At present such languages have been badly promoted and lack industry acceptance, though C++ and Interactive Software Engineering Inc’s Eiffel look set to redress these setbacks. As far as Daniels is concerned, however, the main bridge to be crossed is not that of respectability, but of establishing a uniform object-oriented view of software development. After all, many a real-world panacea has suffered from having too many interpretive possibilities. – Katy Ring …but what’s it all about, Alvey? Conventional methods – from SSADM through to Jackson Structured Programming – operate like oil refineries, turning crude data into refined and useful information. To do this, a problem is functionally decomposed into procedures and data. Procedures describe how the manipulation of data is to take place. Object orientated design separates a problem into objects and events, or messages. Objects are packets of information and a description of its manipulation. Messages merely specify the manipulations that a sender wants done and the receiver determines exactly what will happen. The qualities and characteristics pertaining to objects and events are described only once, and are inherited by others, eliminating duplication. Object orientated design is based on the principle of abstraction from the real world – the same as the way people learn – and is rooted in the philosophy of Heidegger, who examined what it is to be in the world. The advantage is that objects conveniently bolt together, are easily modified, are eminently transportable and re-usable. Further, the method is not prescriptive, so that if two people are given the same problem they are unlikely to come up with the same answer. The real problem facing object orientated design, as explained by conference chairman Ralph Hodgson, of Interactive Development Environments Ltd, is to establish a unified abstraction model, a methodology to which people can work, and a common vocabulary. Object orientated design is not just restricted to programming style or system implementation, and Professor S Schuman of Surrey University argued that it can be used during all stages of the project lifecycle, including specification. It uses traditional tools such as data flow diagrams, entity relationship diagrams and structure charts to examine a system, which is then broken down into a study of operations and events. Computer-aided software engineering tools are the domain of object oriented design at present, particularly in conjunction with languages such as C++, Ada and Modula-2. Ironically Xerox’s Smalltalk, which was developed specifically for object oriented design and defined much of its nomenclature is seen as too slow for many applications using a design strategy. – William Fellows
