This is the first article in the series. The completed set is as
Part 1: Motivation and Fundamental Issues
Part 2: Creating Requirements Documents
Part 3: Mapping Requirements to OOA/OOD
Part 4: Test Case (Home Heating System)
This article is one in a series whose aim is to develop a number of techniques for the
elicitation, expression and validation of requirements for problems which are solved using
object-oriented technology. In particular, we are concerned with the creation of
requirements documents which can be used as a front-end to the OMT and Unified methods.
This article is concerned with a number of important issues and an initial motivation for giving more attention to requirements determination before embarking on an object-oriented analysis of a given problem.
First generation object oriented methodologies appeared in the early 1990's. Some have
disappeared in the meantime, while others have undergone change and improvements. For
example, OMT has been replaced by the Unified Method, in which the efforts of James
Rumbaugh and Grady Booch have been merged. Despite the many improvements in this field the
author claims that more work needs to be done in the area of capturing requirements before
we start on an object-oriented analysis of a given problem. The fact that little attention
has been paid to requirements has lead to a number of difficulties when developing systems
using OMT. We suspect that the same problems have been encountered with other methods (for
example, Fusion and to a lesser extent Objectory); however, this article focuses on OMT
since this is what we are familiar with.
In this section we discuss some of the main bottlenecks associated with the current technology. In later sections we show how such problems can be partially or completely resolved by using requirements determination techniques.
The main problems are now listed. A number of these problems have already been discussed in [reference 1].
One of the most important and difficult decisions which must be made during project development is how to partition a problem into smaller manageable chunks or subsystems so that each subsystem can be separately analysed and designed. The lack of this feature leads to a number of serious problems:
In short, the fact that a given system is not partitioned at a very early stage leads to maintainability and scalability problems. OMT partitions the system into a number of subsystems during the design phase but this approach leads to a new set of complications (see [reference 2]).
OMT gives few guidelines for problems whose requirements are not complete. In other words, the method assumes that the objects and classes are known before commencing on the construction of the object model. For this reason, some authors (see [reference 1]) have concluded (for right or wrong) that it is best applied to information systems or to re-engineering situations where data objects are already identified. In this case the construction of the object model is relatively simple.
Our claim is that OMT can be applied to many different kinds of problems (for example, real-time systems) if the correct requirements have been found and that the method is not doomed to solving only administrative systems.
OMT examines a problem from three different viewpoints (see [reference 3]), namely the object, dynamic and functional (or process) models. The object model is concerned with the main abstractions or classes in the problem domain as well as the long-term structural relationships between them. These are usually generalisation, association and aggregation relationships. Furthermore, the object model is concerned with finding object and link attributes. The dynamic model is concerned with the major external events and control in the system. It is also important to find object states during this phase. Finally, the functional model is concerned with determining what happens in the system; in this case, data flow diagrams play a fundamental role.
A major problem which results from lack of a clear requirements standard is that the distinction between generalisation, association and aggregation relationships is often misunderstood. Worse still, inheritance is misapplied in many situations. This ultimately leads to major maintenance problems. The main cause of these problems is that incorrect relationships are deduced from the requirements.
Based on the above reasoning that a problem can be analysed by looking at it from three almost orthogonal viewpoints, the question is why are requirements documents not written in such a way as to help the analyst to easily find the needed information? It would be highly convenient if a requirements document could be created which reflects the three different analysis views!
The lack of standardisation of requirements documentation is not just limited to OMT. The main consequence of this state of affairs is that the requirements document in its entirety must be read and understood when we wish to construct each of the above three models. This places a heavy burden on those who have to read the document because they have to wade through information which is not immediately relevant to the current activities. For example, the pump delivery system in [reference 4] which was solved by the HP Fusion method has an initial requirements document which must be read several times before we can ascertain what the most important classes are in the problem domain. It would have been much easier to understand if the requirements were set up in such a way that they could easily be mapped to the three analysis views.
One of the major problems with object-oriented analysis methods in general, and OMT in
particular is knowing when we are in the problem domain and when we are in the solution
domain. This is a common problem with many methods in our opinion (the HP Fusion method
being a good example). This is the so-called 'wicked problem' (reference ) by which we
mean that OMT does not prevent a solution-oriented model being constructed. This leads to
a situation in which the specifications become intertwined with the design. There is a
need to separate design issues from those which belong to the requirements stage of the
What is needed is a broader approach to the initial stages of the software development process.
Object oriented technology is difficult to learn and to apply correctly. It is true to say that many experienced DP personnel have the greatest difficulty in moving to this technology. All the more reason why we should not burden users with the delights of object diagrams, Harel charts and object flow diagrams! On the other hand, we must have some other means in order to communicate our ideas to the customer; a more general conclusion is that we need to adopt 'ethnomethodology' (see [reference 5]) in which the analyst gathers information in naturally occurring situations where the participants are engaged in ordinary, everyday activities.
Most developers and programmers know about the benefits of using encapsulation and
information hiding at the class level. For example, in C++ it is possible to hide the
implementation (member data) of a class interface in a so-called private area, thus making
it inaccessible to client code. The same principle holds in more general situations. David
Parnas (see [reference 7]) has used the term Information Hiding and it is one of the most
powerful techniques available in order to create flexible and robust software. However, it
has been neglected in the OOA literature and this absence leads to a number of problems
when the software needs to be modified. What we would like to see is Information Hiding
being used in all phases of the object lifecycle.
This finishes some of the problems that we have encountered with classical OMT. The next section deals with solving a number of these problems.
After having said all this and having accepted that these are major obstacles to successful system development using object-oriented technology, the challenge is now to set up an infrastructure in which these problems can be resolved. We present and elaborate some of the techniques which help us in solving and avoiding the problems of the previous section. These are the basic ingredients from which we create a standard requirements document. Many of the following topics will be discussed in greater detail in the next articles in this series.
A number of system development methodologies (such as Shlaer-Mellor (see [reference 8]) require that an analyst partitions a system into separate subject matters, known as domains. Each domain is analysed separately and the domains are connected together through interfaces during design and implementation. OMT, on the other hand does not partition the systems as such but uses the concept of module. This concept is rather artificial in our opinion and it does not really help when developing large systems.
Although there are no hard and fast rules for partitioning a system into domains or subsystems we have found that the application of the ANSI/SPARC model (see [reference 9]) to object-oriented development has proved to be useful. Based on this model we can partition all systems, programs and processes into three separate and more or less independent domains. These domains are based on functionality and are sometimes given the synonyms expertise area, logical subsystem or subject area.
In order to be able to use and apply the ANSI/SPARC model we need to know how the model is partitioned and what its components are. In general, the model consists of three layers, each one having its own set of responsibilities. More precisely, the model is partitioned into the internal, conceptual and external layers. First of all, the external layer is concerned with that part of the application which is directly visible to clients (for example, GUI software); for this reason it is sometimes called the presentation layer. The internal layer is concerned with the 'raw' or unprocessed data which will be transformed in one or more ways in order to be delivered to the external layer. Finally, the conceptual layer is the intermediary between the internal and external layers and it represents the business rules and core activities of an application. In a more general business setting, we see the ANSI/SPARC model being used in the literature (see for example, [reference 10], page 52). In business environments for example, we are concerned with converting raw materials into sellable products by using the knowledge and intelligence of the people in an organisation. In such cases we can think of a workflow scheme consisting of three domains for input (internal layer), processing (conceptual layer) and output (external layer). Specifically, each layer is concerned with the following issues:
The different layers may communicate with each other in different ways. For example, a system may be implemented as a batch program in which the output from the internal layer functions as input to the conceptual layer while the output from the conceptual layer is used as input to the external layer. In such cases there is a one-way flow of information but it is also possible for pairs of layers to communicate in a peer-to-peer fashion. For example, it is possible for the internal and conceptual layer to be active and have the ability to send information to each other. In this case we speak of collaborating layers.
The process of partitioning a problem into smaller domains using the ANSI/SPARC model is a recursive one. The process ends when all domains cannot be decomposed further. For these 'terminal' domains there is a set of abstractions which realises the functionality of the domain. Once we arrive at this stage we can apply concept mapping techniques as discussed and elaborated in [references 11 and 12]. These techniques allow the analyst to find the major concepts (later classes) and the links or relationships (such as generalisation, association and aggregation) between them. The advantages of this approach are:
One of the advantages of using these maps at an early stage in the software development is that first of all, it promotes communication between analyst and domain expert and secondly it ensures that no design or implementation details are used because, by definition concept maps deal exclusively with abstractions from the problem domain and not the abstractions from the solution domain.
Concept maps deal with the static structure of the system. It is necessary to deal with the external events which trigger reactions in the system. In this case we use the Use-case approach developed by Ivar Jacobson (see [reference 13]). The use cases in our approach are distributed over the different domains which are produced from the ANSI/SPARC model. The advantages of this approach are:
In short, we have combined ANSI/SPARC, concept maps and use cases to partition a given system into a number of almost independent subsystems in which both the structure and behaviour can be properly described.
It is interesting to note that the steps advocated in [reference 15] for analysing large problems are very similar to our own techniques. The major addition or simplification in our case is that we have a reproducible technique for partitioning a system and that we use concept maps to produce stable and accurate object diagrams.
The steps are:
1. Identify the high-level subsystems (by ANSI/SPARC, for example)
2. Distribute the use cases over the subsystems
3. Determine the interfaces between the subsystems
4. Design each subsystem internally
The approach in this article is taken because of our basic objective of creating requirements documents which can be used as input to OMT or the Unified Method. The results are not shocking as such but they create an environment in which all problems are described in a standard fashion. In this way, we hope to improve the software process by producing standard documents. The ultimate objective is to reduce cycle times and introduce a factory-based approach to creating software (see [reference 14]).
It has taken us a number of years to realise that we must start with a requirements analysis and determination for a given problem and that it is not enough to start with object diagrams and inheritance hierarchies. Many of our customers agree on this point. We have found that they are able to understand and create a requirement document within days but most find it difficult to partition a problem into domains. The method has been applied to problems in mechanical engineering, holography, accountancy, EDI and in the construction of reusable components. Feedback has been positive, many due to the improved communication between those involved in the software development process.
In the next article we shall discuss the steps that need to be executed in order to create a requirements document which can be used as input to the object, dynamic and functional views in OMT.
This article contains excerpts from course materials and tutorials on OORD by Datasim BV, reproduced with permission.
Daniel J. Duffy is a director and founder of Datasim BV, Amsterdam, a training and software development organisation which has been involved with OOT since 1988. He is chief designer of CADObject, a class library consisting of 600 C++ classes which is used to build applications for CAD, computer graphics, engineering and simulated worlds. He has been involved in many types of OO projects in finance, CAD, logistics and engineering . He is convinced that software development should be based on a building block or factory foundation and that new applications and prototypes should be built using ideas, architectures and designs which have been applied from previous projects. Duffy has a Ph.d. in numerical mathematics from Trinity College, Dublin and can be reached on the e-mail address email@example.com.
[ Homepage | Articles ]