Problems with the structured approach to software development
This section looks at the way in which systems were developed before object-orientation, and at some of the problems that resulted from using the traditional approach.
Functional decomposition. For many years, software systems were developed using a structured approach based on functional decomposition. This meant that developers decomposed and then constructed the system according to the main areas of a c t i v i t y - in other words, the subsystems that were identified corresponded directly to tasks that the system had to carry out. For example, in a bike hire system, such as the one used in this book, the system would probably be based on subsystems or processes dealing with issuing a bike, returning a bike, maintaining records for bikes and for customers etc. Each of these processes would perform a separate function, and the data about bikes, transactions and customers would be passed freely between them. In functional decomposition, there was a clear separation between data and process, and data items could frequently be accessed by any part of the program. Figure 4.1 shows data about bikes being transferred between a data store that holds records about bikes and the processes that deal with issuing and returning bikes to customers.
This is a potential source of problems, because the bike details are accessible to other parts of the system with no protection from processes that may access and modify them in error.
Maintenance. Structured software designed using functional decomposition brought with it big maintenance problems. Changes to the code frequently introduced new bugs; a change in one place
OBJECTS AND CLASSES: THE BASIC CONCEPTS WHY A NEW DEVELOPMENT METHOD WAS NEEDED
77
Figure 4.1
I
bike details _ Issue bike
I -I
Bike
l bike details I Return bike
In functional decomposition data (here details about bikes)flows unprotected round the system
caused unexpected side-effects elsewhere: the infamous 'ripple effect'. Software developers became aware that if the data in the system was accessible to all parts of the code, it could be accidentally corrupted and this was what was causing the ripple effect. Software developers realized that to prevent this, data needed to be encapsulated (protected from unauthorized access).
Poor modularity.
However a system is decomposed, it is very important that each separate component or module is self- contained, with a well-defined purpose, and as independent as possible from other modules. Unfortunately, decomposing a system using functional decomposition did not lead to modules with these characteristics. A module in a system based on functional decomposition often was not internally cohesive and was heavily dependent on other modules in the program.With functional decomposition, making changes to code, either to correct software bugs or implement changes in the user requirements, was a very slow process. In order to understand enough of the code to make the change, preferably without causing side effects, the maintaining programmer had to read a great deal of the code. This was because of poor modularity, the code modules were not independent enough, they were not autonomous. The maintaining programmer could not understand them in isolation, he had to read many peripheral modules to make sense of the one he was changing. This implied that there were hidden dependencies between the modules. What was needed were cohesive (internally coherent) modules that could function either independently or via well-defined interfaces to other modules.
Testing.
Software systems based on functional decomposition were still being delivered with errors in the code; they were perceived as unreliable and not sufficiently well tested. It was thought that this might be partly because it was difficult to test units in isolation and manage rigorous integrated testing. This was again partly because units of code were too interdependent. Software developers wanted78 A STUDENT (~UIDE TO OBJECT-ORIENTED DEVELOPMENT
software units that could be both easily tested in isolation and logically incorporated into an integration testing schedule.
Software reuse. Reuse of software had never taken off as it was expected to do. One of the principal reasons for this was that a suitable software construct didn't exist. A module that is heavily d e p e n d e n t on other software modules cannot easily be put in a software l i b r a r y - all the bits it depends on have to be in the library also. To be reused, modules need to be independent. Useful library modules must also have a clear single purpose that is general enough to be useful in more than one system.
Data versus function. The structured approach built systems based on their f u n c t i o n a l i t y - what the system had to do, the tasks that it had to carry out. The problem with this was that typically the functionality of a system is much more volatile and subject to change than its data. Extensive studies have shown that the most common changes in user requirements are to the functionality of the system. Let us consider, for example, a system for allocating patients and staff to wards in a hospital. We can imagine that over time the ways in which patients are assigned to beds in a ward and the way that the nurses' rota is worked out may change. In addition, it is likely that the system will be required to produce more and different reports for its users. W h a t e v e r these changes may be, however, the system will still be dealing with patients, beds, nurses and wards - in other words, the data remains the same. The data is much more stable than the functionality, and is a much sounder basis on which to build a system. In functional decomposition the software architecture (the way the system was divided up) was based on its functionality, and over time the whole structure of the system eventually became unstable. The data in the system, however, remained relatively unchanged over the life-time of a system; it eventually became obvious to the software development community that a system based on data would be more robust.
Advantages of object-oriented development
In order to address the problems associated with functional decomposition, developers needed a software construct that was:
9 Autonomous, i.e. did not depend heavily on other modules either explicitly or in obscure ways
9 Cohesive with a single, well-defined purpose 9 Easy to u n d e r s t a n d
OBJECTS AND CLASSES: THE BASIC CONCEPTS WHY A NEW DEVELOPMENT METHOD WAS NEEDED
9 Easily adapted to accommodate new or changed requirements 9 Based on data.
In addition to these characteristics, the software construct should also have:
9 encapsulated data
9 a well-defined public interface.
This type of unit would be easier to test thoroughly both in isolation and as part of an integrated test plan. It would more likely be reusable and could be included in a software library.
The object-oriented community proposed the
object
as asoftware construct which had the characteristics listed above.
Objects, although they provide functionality, are based on the data in the system. This provides a structure that is less subject to change. As we shall see later in this chapter, an object protects (or encapsulates) its data by making the data accessible only by using the object~ publicly declared operations. Well-designed objects are independent and autonomous, making them easy to test in isolation before being integrated into the system. A good object is cohesive, i.e. concerned with a single idea, which makes it suitable for inclusion in a software library for possible reuse.
79
Use case decomposition and object-oriented decomposition
Although objects are based on the data in the system, this does not mean that object-oriented software ignores the required functionality. We have seen in Chapter 3 that the use case model specifies, from the user~ point of view, what the system must do.
The objects we define must be capable of delivering that functionality. The use case model provides one decomposition of the system, based on the required functionality. However, the software structure of an object-oriented system is based on the object. In other words when we come to build the software and divide it up into separate parts we don't split it up according to use cases but by objects and groups of objects.
Another advantage of the object-oriented approach is that it provides a seamless development process. The objects we identify as part of the analysis stage persist through the development stages to the code. This thread of continuity means the software objects have a certain p r e d i c t a b i l i t y - we have expectations, for example, of what an object representing a customer will look like and what it will do. In well-designed object-oriented code our expectations will not be disappointed. This makes the code easier to understand and therefore easier to maintain.
80 A STUDENT GUIDE TO OBJECT-ORIENTED DEVELOPMENT
The seamless development also provides traceability of user requirements from initial identification through to the code. In the traditional structured approach to development some of the models that were used to capture user requirements (such as the data flow diagram) were abandoned at the design stage where a new modelling technique was used to specify the structure of the code (for example, structure charts). This made it hard to ensure that all of the user requirements were incorporated in the final implementation: it was easy to lose features in the changeover of models. In the object-oriented approach we identify objects which represent things in the problem domain and about which we need to store information. Later in the development process we add objects to provide the software structure we want to implement (for example, control and b o u n d a r y objects) and objects that are to do with how the software will work (buttons, windows, mouse- listeners etc.). However, the original objects, although they may gather some extra features in the development process, will still be identifiable in the code.