9.1 Analysis 9.1.1 Structured Analysis 9.1.2 Object-oriented Analysis 9.1.3 Domain-oriented Analysis 9.2 Domain Definitions 9.2.1 Domain Transformations 9.2.2 Applications of Domain Definitions 9.3 Domain Modeling 9.3.1 Interactions between Requirements and Structures 9.3.2 Use of Domain Modeling 9.4 Language Features 9.4.1 Alternatives to Inheritance, Polymorphism, and Dynamic Binding 9.5 Summary 9.6 References
In this chapter we will examine some of the differences between object orientation and domain orientation. It starts with a description of the most important methods used in structured analysis and object-oriented analysis, and it compares the representations used in these methods with the use of domain definitions in domain-oriented analysis.
The use of domain transformations is illustrated by an example and a summary is given of the applications of domain definitions. Domain modeling is described as a bridge between requirements and implementation.
Furthermore, some language features and alternatives of inheritance are examined.
The analysis of the requirements for a new system are in many situations the most difficult parts of software development because of their far-reaching consequences. Errors made in the early phases of the software life-cycle have a tendency to perpetuate until they are discovered by the users after the system has been built. And we all know that the later an error is identified the more expensive it is to correct.
The analysis activities try to answer the question what the problems are that should be solved. Initial problem statements are often vague and incomplete. In those cases analysis activities are required to really understand the problems and to bring hidden requirements to the surface. For example, before an hospital information system can be specified quite a number of discussions will be needed to discover the requirements of doctors, nurses, managers, bookkeepers, and others, before it will be clear what the system is suppose to do.
These activities are often taken a great deal of the time and effort. There are a number of reasons for that. One reason is that users often do not know what they want. Another reason is that the implications of user wishes are difficult to judge. A further reason is that proposed solutions are frequently partial solutions solving only fragments of the problem. Most of these reasons are caused by the inherent complexity of the systems to be designed.
After the problem domain is sufficiently understood, a systems requirements specification may be written which describes the problem domain and specifies what the system is expected to do. It comprises an answer to the question what kind of services the system should provide.
Many analysis methods have been proposed to support these activities. In this chapter we will examine three approaches:
Structured analysis methods were mostly developed in the 1970s. Important and representative schools are:
Functional Decomposition consists of selecting the processing steps and sub-steps for a new system. It decomposes a system into functional parts. A functional-decomposition diagram aims to show pictorially the breakdown of activities into more and more details. The focus is on what activities must be taken to fulfill the requirements of the new system.
The Data Flow Approach follows the flow of data whenever looking at the problem space, and maps that flow into subsequent diagrams. A data-flow diagram aims to show pictorially the activities of the problem space, the static data that is used by the activities and the dynamic data that is passed between activities. The focus is on the flow of data as required for a new system.
Information Modeling aims to model the data of a problem space. The data and their relationships are represented in entity-relationship diagrams or other kinds of diagrams. The focus is on the static data as required by an application area.
While structured analysis methods concentrated on one aspect of a problem space, being activities, flow of data, or static data, object orientation combined those aspects into one concept, the object. An object represents data and the associated activities on that data.
A number of interesting approaches are:
Object-Oriented Analysis and Design (OOA/D) was introduced by Coad and Yourdon in 1990 and revised in 1991. They suggest that analysis proceeds in five stages:
Object-Oriented Design (OOD) introduced by Booch in 1991 and revised in 1994 consists of six types of diagrams and four major tasks. The diagrams dealing with the static aspects of a system include class diagrams, object diagrams, module diagrams, and process diagrams. The dynamic aspects are dealt with using the existing techniques of state transition diagrams and timing diagrams.
The four major tasks to produce the diagrams are:
Object Modeling Technique (OMT) was introduced by Rumbaugh and others, in 1991. The method distinguishes three complementary models for describing a system. The object model is used to describe the static structure of classes and their relationships. The dynamic model describes for each object class the state changes resulting from performing operations. The functional model describes the interactions between objects in terms of data-flow diagrams.
The Unified Modeling Language(UML) is an undertaking of Booch, Rumbaugh, and Jacobson to unify their methods into one coherent software development process.
Let us now compare the domain-oriented techniques as described in this book with other approaches. To a large extent, domain orientation is a generalization of object orientation. Many techniques developed for object-oriented analysis and design are also applicable to domain-oriented analysis and design. However, there are also a number of differences.
One of the most important differences is that structured analysis methods as well as object-oriented methods are based on graphical representations. Diagrams and charts are essential elements of the way the results of analysis and design are presented. Those graphical representations serve two kinds of purposes. First of all, they are used as a means of communication to potential users to show what they may expect from the new system. Secondly, they are also used as a specification for the developers who will design the system. To serve both purposes, analysts have a tendency to develop graphical representations in great detail because they do not know when to stop. As a result, the graphical representations are too detailed for the users, and too restrictive for the developers. Users have difficulties to understand the behavior of a system from a large pile of diagrams. Developers are often not able discover the structure of the system from the same pile. They are also not encouraged to investigate different solutions because the diagrams are heading for one solution. An associated problem is that diagrams cannot easily be manipulated to investigate other approaches.
With domain orientation the two functions are separated. Graphical representations may be used for communication with the users. Domain definitions are used for specifying a system.
Domain definitions are formal descriptions of
problem-space concepts. As such they can be transformed into
other domain definitions to represent different solutions.
As discussed in Chapter 3 about "Domain Definitions", the transformation of domain expressions and domain definitions must be in accordance with algebraic rules. Domain transformations can be used for several purposes. One goal can be to simplify a set of domain definitions. Another aim may be to investigate different solutions.
In the following example we will illustrate how simple transformations may completely change the domain definitions and how they may result into different implementations. Let us assume that we have the following domain definition:
(1) a = b + ( c | d )
From this we may derive the following domain definitions:
(2) a = b + e
(3) e = c | d
As a result, a is a composite domain which will be implemented as a descriptor type, and e is a selection domain which will be implemented as a category type.
On the other hand, we may derive from the same definition (1) also:
(4) a = b + c | b + d
which must be transformed into the following basic domain definitions:
(5) a = p | q(6) p = b + c(7) q = b + d
In contrast to the previous result, this approach makes a a selection domain, and p and q composite domains.
It will be clear that both solutions will lead to two different implementations although the meaning of a is in both solutions the same.
To make our example more concrete, we assume that (1) represents the following domain:
Shop = ShopName + ( MaleShopkeeper | FemaleShopkeeper )
The first solution of (2) and (3) is:
Shop = ShopName + ShopkeeperShopkeeper = MaleShopkeeper | FemaleShopkeeper
The second solution of (5), (6), and (7) is:
Shop = ShopKeptByMale | ShopKeptByFemaleShopKeptByMale = ShopName + MaleShopkeeperShopKeptByFemale = ShopName + FemaleShopkeeper
The first solution will result in two components. One component for Shop-descriptors, and another component for the Shopkeeper-category.
The second solution will result in three components. One component for the Shop-category, one component for ShopKeptByMale-descriptors, and another for ShopKeptByFemale-descriptors.
Both solutions are representing the initial
domain definition. It depends on the context of the problem and
different kinds of trade-off which solution will be chosen. As
with any other engineering discipline, the investigation of
various approaches is essential to find an optimal solution.
Domain definitions provide the tools for that. It is much more
difficult to derive the same alternatives by manipulating
As we have discussed earlier, domain definitions have many applications and can be used for a variety of purposes. We will name some of them.
A complete set of domain definitions for a given application area provides an Information Model for that area. In classical terms, an information model describes the entities, their attributes, and the relationships between the entities. Information models are often used for developing information systems and applications involving databases. An information model may be used by several application programs.
Based on the set of domain definitions for a given application area also a List of Components may be derived. Those components are descriptor components, category components, collection components, coupler components. The list of components is based on the information model, and because an information model is the foundation for multiple applications, the same components can also be used by different applications. That means that domain definitions provide the basis for reuse of components.
Because domain definitions are high-level, abstract descriptions, they do not assume physical locations. Therefore, they can also be used to describe distributed architectures, such as client-server systems.
Furthermore, domain definitions may also be used to model databases. Hierarchical databases, relational databases, and object-oriented databases may all be described by domain definitions.
Because components are derived from domain definitions, and domain definitions may be interrelated, also the corresponding components are interrelated. As a consequence, related domain definitions represent system structures and sub-system structures.
Domain definitions are also the basis for the specifications of domain operations, as described in Chapter 4, "Domain Operations". Furthermore, domain definitions and domain names are used in domain implementations (see Chapter 5, "Domain Implementations") for:
All methods using structured analysis or object-oriented analysis are based on modeling. Each method has its own approach and uses its own conventions to model future systems. As we saw earlier, each method relies on graphical representations. Often, a variety of diagrams are required to describe a new system.
Domain modeling is different from the other methods in a number of ways:
These three points represent a continuum in development from domain definitions to an executable model and from there on to an implementation. Domain definitions provide a high-level, abstract view of a system-in-the-large, while implementations provide realizations-in-the-small. Domain definitions are not dealing with programming but with the organization of programs. Modeling provides the link between domain definitions and implementations.
In many engineering disciplines modeling is used to clarify the discrepancies between requirements and implementations. As an example, let us see what happens if you want to build a new house. You may first try to get an idea of the type of house you want by looking around and having discussions with your friends, and probably you are estimating the money you want to spend. Then you are calling in an architect to tell him your requirements and constraints. The architect will start with some detailed questions about your family situation and about some aspects of the house and he will leave with the promise to come back with a first draft. As a good architect he will return soon with a number of alternative plans, each with its own merits. You as a potential user are delighted because this approach gives you the possibility to discuss with the architect the various alternatives and to combine the aspects of different plans. This type of dialogue may be repeated over time, further and further refining the concept of the house. In the meantime the architect has made a start to make more detailed drawings of the house. The design of the house goes hand in hand with the evolution of the requirements. While in the first phase your requirements are driving the design, later on the design is driving the requirements. After the global design has been agreed upon, the architect will ask your detailed requirements regarding the location of the doors, the color of the walls, the type of sanitary, all fitting within the total concept of the house.
Why is the exchange of roles happening? Because the global requirements are determining the structure of the house and all the detailed requirements should fit within that structure. This does not only apply to buildings but is in fact a very general principle applicable to all kinds of constructions. The structure determines if a new requirement can be fulfilled and the structure also invites for detailed requirements to complete the structure. That means that once a structure has been defined it will act as a coherent and stable framework which separates the consistent requirements from the ones that are inconsistent with the structure. This principle works for physical structures as well as for abstract structures.
For software systems the same principles can be applied. Domain modeling is based on the translation of requirements into executable implementation models. In domain modeling, the distinction between analysis, design, and implementation is primarily one of emphasis. There is a continues interaction between different aspects of the model as we have illustrated in our case studies (see Chapter 7, "Case Study: An Order Processing System", and Chapter 8, "Case Study: An Airport Support System").
Domain modeling is an iterative process. A domain model is developed along the lines (Berard, 1990):
"analyze a little,
An important question is: Can we use domain modeling in combination with existing methods for analysis and design, or must we throw those methods out of the window and start all over again?
Fortunately, domain modeling can not only being used as a single and independent tool, but it can also be applied in combination with existing system analysis approaches. In that case it may augment and improve the structured analysis or object-oriented analysis methods you are using. The connection between existing analysis methods and domain modeling are the domain definitions. Based on the analysis results, domain definitions can be derived as input for domain modeling.
Domain modeling may come after the analysis activities or it may start during system analysis. In order to gain the most benefits it is often wise to start domain modeling parallel to system analysis. In that case a maximum of interactions between analysis and modeling is obtained which may increase the quality of both.
Domain modeling may continue until a final implementation has been obtained. However, it is also possible to stop earlier, for example, after a model of the final design has been achieved. The implementation may then be coded in a traditional language such as Cobol, or Fortran, or in an object-oriented language as C++.
To compare domain-oriented language features with object-oriented language features is only possible on a global scale.
The features of a domain-oriented language are to a large extent dictated by the requirement that domain definitions and domain operations should easily be mapped on language constructs used in domain implementations. Categories, lists, and definitions returning multiple or optional values, are obvious examples of such features.
Object-oriented programming is based upon objects, classes, methods, messages, encapsulation, inheritance, polymorphism, and dynamic binding. They are representing important concepts which should also be incorporated, in one way or another, in a domain-oriented language.
For a number of concepts it has been fairly obvious to include them in Elisa. Objects are represented by descriptors, classes by descriptor types, methods by definitions, messages by definition calls, and encapsulation is provided by components.
However, not so obvious are inheritance,
polymorphism, and dynamic binding as we discussed earlier. We
will discuss them in more detail.
Because of the complexities of inheritance many researchers have tried to simplify or to avoid inheritance. From the many alternatives which have been investigated two approaches have appeared to be the most effective. These alternatives, delegation and decomposition, are both based on object composition.
Object composition means that an object is composed of other objects which implies that such an object is able to make use of the other objects. Thus, a child object may use a parent object. One may say that the has-a relationship and the is-a relationship, as discussed earlier, are both be implemented by means of a using relationship.
Object composition requires that the objects being composed have well-defined interfaces. No internal details of the referred objects are visible. The differences between inheritance and object composition have been investigated by a number of authors (Budd (1997), Gamma (1995)).
Delegation is one of the alternatives to inheritance. In delegation, two objects are involved in handling a request; a receiving object delegates operations to another object, its delegate. This is comparable with child classes deferring requests to parent classes.
Let us compare inheritance and delegation in more detail. For example, let us assume that we have a parent class:
and a child class:
By using inheritance in an object-oriented language the Employee class inherits the behavior of the Person class because of the relationship: Employee is-a Person. For example, if a client requests for the Name of an Employee, the system automatically provides the Name of the Person object if there is no Name method defined for Employee.
In case of delegation an explicit Name operation must be defined for Employee. This Name operation will delegate this request to the associated Person object as in:
The difference with inheritance is that all the operations related to an Employee as a Person must explicitly be declared. For example, also operations for Address, ChangeAddress, and Birthdate must be defined for Employee.
Another approach is to use decomposition. With decomposition, elements of an object are made accessible to the user. That means that a reference to a parent object in a child object can be made available to the user of the child object by means of an accessor operation. In our example it requires that an accessor operation for Person is defined within the context of Employee:
The user may now ask for the Name of an Employee in the following way:
The difference with delegation is that no explicit operations related to an Employee as a Person are required except for the accessor operation Person. That means, for example, that operations for Name, Address, ChangeAddress, and Birthdate are not needed anymore for Employee. The only requirement is that the Person operations are accessible for the users of the Employee class.
In Elisa delegation as well as decomposition can both be used as alternatives to inheritance. The choice between delegation and decomposition depends on the question of information hiding. If, in our example, Person should not be visible to the users of Employee, then delegation is the preferred method, otherwise decomposition can be chosen. Decomposition often leads to simpler child classes. However, part of the burden is shifted to the user because he has to know the interface of the child class as well as the interface of the parent class(es).
By using delegation and decomposition instead of inheritance a large number of the problems associated with inheritance are disappearing. Furthermore, polymorphism and dynamic binding can be supported by orthogonal language facilities.
In the language, polymorphism is supported by type-variables, categories, and generic components. Dynamic binding is performed by some type-conversion expressions, and by type-matching in parameter-expressions. As a consequence, the programmer has more direct control over the implementations of is-a relationships, and can decide how and when to use polymorphism, and dynamic binding. With these facilities it is also possible to create application frameworks as defined by a set of domain definitions, and to use design patterns, as illustrated by the skeletons defined in Chapter 5, "Domain Implementations".
In this chapter we discussed a number of the differences between object orientation and domain orientation:
Coad and Yourdon (1991a) are discussing a number of methods that are commonly used in analysis. They compare functional decomposition, the data flow approach, and information modeling with object-oriented analysis methods.
Object-oriented analysis and design is described by Booch (1991, revised in 1994). Object-oriented modeling and design (OMT) is discussed by Rumbaugh (1991) and others. The Unified Modeling Language is defined by Booch, Rumbaugh, and Jacobson (1999).
Budd(1997) describes and compares various features of different object-oriented languages.
Of the many papers about the problems of inheritance, the papers of Snyder(1986,1987) are worthwhile to study. The differences between inheritance and object composition have been described by Gamma (1995) and Budd (1997). Budd (1997) distinguishes 8 forms of inheritance. Meyer (1996) found 12 kinds of inheritance grouped into 3 broad categories.
Taenzer (1989), Ganti, and Podar are describing the yo-yo problem.
Delegation was first described by Lieberman (1986). Later on, the term delegation was redefined by Wegner (1987).
Wilde(1993), Matthews, and Huitt are discussing maintenance problems of object-oriented software.
Many contributions about object orientation can also be found in the yearly OOPSLA proceedings (since 1986), and in the Journal of Object-Oriented Programming (since 1988).
Design patterns and application frameworks are discussed by Budd (1997) and by Gamma, et al. (1995).
This page was last modified on 27-09-2012 16:53:46