Why should we ever want to create higher level models of an object- oriented program? The binary executable code is the only
representation that gives a precise definition of what the program will actually do under all possible circumstances. The source code
contains the equivalent information -- assuming that the compilers, and loaders do what we expect them to do. But we have also added embellishments that have no effect on program execution: Comments are added and program entities are given names that convey meaning to a human reader, but that have no effect on program execution. Most of us still prefer to study the program in its source code form, even if we are occasionally mislead by improper comments and entity names. A program is defined by its executable code 4.1 Introduction to implementation 29 March 1995 23:05 ©Taskon 1992. Page 159 Bridge to implementation
Office procedures are very similar: the office procedures are defined by the procedure texts and there are no high level descriptions. We will later show that higher level, object-oriented descriptions of office procedures give important benefits, but we will now restrict our arguments to computer programs.
The binary executable code mixes all system functions
While we try to create a program structure which clearly separates different concerns into distinct classes and methods, we still end up with having to satisfy several requirements in the same unit. Consider a method that changes the state of a persistent object. The primary function of this method is to change the state. In addition, it must raise an exception if the specified change is inappropriate. It must update all dependent objects such as visual presentations on the screen. It must ensure that the new state of the object is reflected in its persistent form (e.g., on disk). If the state change is part of a transaction that is canceled, it may have to undo it.
Why should we ever want to create high level models of an object- oriented program? If the code is simple and readable, we need nothing else. In practice, the program code is not as simple and readable as we could wish, and we have four excellent reasons for wanting to create higher level models:
Why high level models?
Simplification. We want a simplified description which can be
grasped by the limited capacity of our skull. We use such abstract descriptions to reason about the system before diving into the details, and to provide a clear documentation of its overall features.
1.
Evolution. The more details we put into our descriptions, the
harder it will be to change them. The original rationale for introducing a design stage in the program life cycle was that it is so much cheaper to change a design description than it is to change a complete program. But this is only true to the extent that the design description really is smaller and simpler than the program code.
A viable alternative is to describe the essential aspects as a
simplified program. This incremental programming approach is
often more productive than a prolonged period of high level (and abstract) analysis and design.
2.
4.1 Introduction to implementation 29 March 1995 23:05
Emphasis. The program code is an explicit representation of the
program logic, the source code may also exhibit the data
structures. Important static and dynamic program properties are specified implicitly, and not always easy to fathom. Many OOram views explicitly express aspects of the program which are not immediately apparent from the program code.
3.
4. Documentation. (Human-to-human communication.) A successful
program will have a long life. Many people will try to understand it in order to fix bugs and modify its functionality, usually under high time pressure. Good documentation help them understand the underlying architecture and constraints, and thus maintain system integrity.
Simple models are easy to change
All four considerations have proven to be important in our practical work. Making changes to an isolated role model is trivial, as is making changes to the details of an isolated method. But due to the ripple effect, changing a role model which depends on other role models is harder. In general we can say that the work involved in making a change depends on the number and nature of its dependent parts, be they state diagrams, method definitions or dependent models. Large systems need another abstraction layer to keep things simple. We advocate a clear, modular architecture for this purpose, and keep low level modules stable while the high level modules are being developed. (FOOTNOTE: We will describe OOram modules in chapter 6.5)
Our experience has also provided counter-examples to these observations. Simple role models are excellent for providing the answers to critical questions, but we may fail to find the most critical questions. Our understanding of the issues may be incomplete, problems we deem to be important evaporate under close scrutiny, and problems we believed to be trivial turn out to be real mind boggles. We therefore need to go the whole way and describe the solution as a program before we can be sure that our original questions were the right ones. In the normal life cycle with a design stage separated from an implementation stage, deficiencies in the design which are discovered during implementation cause costly rework.
Simple models may hide ugly details
Some description methodologies, notably in the field of database systems, follow the '100% rule': The high level description shall include sufficient detail for the automatic generation of the
application program. We then regard this description as a program
29 March 1995 23:05 4.1 Introduction to implementation
©Taskon 1992. Page 161 Bridge to implementation
and the description language (which may be graphical) as a very high level programming language. The whole argument repeats itself: Can we manage with this program as the sole description of the
application, or do we need simplified and more abstract models?
Executable specifications are simplified programs which combine the best from both worlds
We often find it convenient to introduce an intermediate stage between design and implementation which we call executable
specifications. These specifications are implementations in the sense
that they can be executed as programs, but they neither have the efficiency nor the robustness required of a finished program product. Their aim is to highlight deficiencies and details in the system logic, they are abstractions in the sense that they suppress many aspects of the target program and hide trivial details.
Some computer professionals may tend to associate system
description paradigms with the internal workings of the computer. But the computer hardware does not "know" about Fortran and C, entities, relations, objects, or messages. A computer is just a piece of
electronic hardware, performing its operations according to the programs represented as bit patterns in its memory. So the audience of a high-level description is a human being, not a computer.
The ultimate consumer of a manifest model is human
Many years ago, we attended a seminar given by M. A. Jackson which profoundly changed our attitude to programming techniques. The following is a description of the result of this experience. (Apologies to Jackson if he should be misrepresented.)
In figure 4.6, the top line symbolizes all programs that a given computer may perform. These programs are generated by
systematically loading the computer's memory with each possible bit pattern, and then, in turn, ask the computer to start executing from each possible starting point. The number of different programs that can be executed by our own personal computer is on the order of 10 raised to the power of many million, a truly staggering figure. Most of these programs will come to an abrupt halt; some of them will never terminate. To the computer, they are all legal programs. What most of them have in common is that they do nothing that we, as humans, regard as useful or even meaningful.
We only permit systems we understand
The middle line in the figure illustrates the almost infinitesimal subset of these programs that do something that we find meaningful.
Jackson's insight was that even these programs are not acceptable, because the functioning of most of them will be outside the grasp of the human mind. Jackson's thesis was that of all the meaningful
29 March 1995 23:05 4.1 Introduction to implementation
programs, we should limit ourselves to the small portion of them that we can understand. This is illustrated as the bottom line of the figure. Jackson: "For any given problem, there is one and only one correct
solution. The tragedy of computing is that there are so many other solutions which also work."
Figure 4.6 Our methodologies are designed for people - - computers will accept anything
The set of all possible programs is extremely large
The set of all meaningful programs
The set of all understandable programs
Simplicity is a goal Our first line of defense is to create programs that are within the grasp
of the human mind; programs that are "so simple that there are obviously no deficiencies". We believe that such programs should be our ideal. No other representation can beat the simple program text for precision, clarity and completeness.
The need for high level representations arise when the problem is too complex to yield simple code in its solution -- when the structure of objects gets too large to be readily grasped by the human mind. OOram role modeling was created to answer this need and to provide a model of the program that is simple and easy to understand.
4.1 Introduction to implementation 29 March 1995 23:05