Back Home Up Next



1.1 Classification of Models
1.2 Domain Models
1.3 Steps in Domain Modeling
1.4 Results of Domain Modeling
1.5 Moving to Systems Design
1.6 Summary


Models have become widely accepted as a means for studying complex phenomena. A model is an abstracted representation of a system. The value of a model arises from its improving our understanding of unclear behavior characteristics more effectively than could be done by observing the real system. A model, compared to the real system it represents, can yield important information about the behavior of the system under different conditions. Models can be a basis for investigations at lower cost and in less time than analyzing actual systems. Knowledge can be obtained more quickly and for conditions not observable in real life.

The main reason for modeling is to deal with systems that are too complex to understand directly. Models reduce complexity by separating out a small number of important aspects to deal with at a time. Models can also be used for experiments under different conditions.

In this part of the book we will examine how modeling can be applied to complex software systems. We start with this chapter about a specific form of modeling, called domain model which is focused on the underlying concepts of a software system.



1.1 Classification of Models

Models might be classified in many ways. We will describe four kinds of subdivisions:

Physical or Abstract. First, models can be distinguished as being either physical models or abstract models.

Physical models are the most easily understood. They are usually physical replicas, often on a reduced scale, of objects under study. Static physical models, such as architectural models, help us to visualize floor plans and space relationships. Dynamic physical models are used as in wind tunnels to show the aero-dynamic characteristics of proposed aircraft design.

Abstract models are based on symbols, rather than physical devices. The abstract model is much more common than the physical model but is less often recognized for what it is. A mental image, a verbal description, a drawing, or a mathematical formula can represent an abstract model of a system. Models used for designing software systems are abstract models.

Descriptive or Prescriptive. Models can also be classified as being either descriptive models or prescriptive models.

Descriptive models are describing existing systems. They are used for studying specific characteristics of the real system. Examples are models for weather prediction, economic systems, biological systems. The goal of a descriptive model is to understand the behavior of the real system. In many cases it is also used as a basis for predicting future behavior. Because a model is an abstraction of a real system, data can be collected from the existing system and used as input for the model.

Prescriptive models are used to examine the behavior of man-made systems before they are built. Sketches, drawings, blueprints, formulas, and computer programs are all used for prescriptive modeling. The goal of prescriptive modeling is to examine the behavior of systems under different conditions, to understand the operational characteristics and to support the decision making process in selecting the right set of system parameters. Prescriptive modeling has to deal with two kinds of uncertainties: one is related to the question what the characteristics of the future system should be, the other uncertainty has to do with the question which aspects of a future system should be included in the model. Models used to analyze the requirements for future software systems are prescriptive models.

Static or Dynamic. Models may or may not represent situations that change with time. A static model describes a relationship that does not vary with time. A dynamic model deals with time-varying interactions.

Both static and dynamic models are used for the analysis of new software systems. Information models and object models are often static models, representing the structural data aspects of the system. Data flow models, functional models, and state-transition models are dynamic models, representing the temporal and behavioral aspects of the system.

Operational or Inoperational. Models may be divided in operational and inoperational models.

Operational models are dynamic models which can be put into effect. Operational physical models are usually working small-scale versions of objects, such as trains, automobiles, aircraft. Operational abstract models are describing time-varying phenomena. They contain descriptions how to generate the actions that are taken progressively through time. To be useful, the model must be executed by a mechanical or electronic device. An important class of executable, abstract models are simulation models which are used to simulate the current or expected behavior of a system. They are frequently used to study complex, history-dependent state-transitions, which are difficult to predict. Those models are also used to study the effects of different alternative solutions as a basis for experimental investigations.

Inoperational models are models which cannot be executed. Many models, used for the analysis of software systems are inoperational models.


1.2 Domain Models

Domain models are abstract, prescriptive, dynamic, and operational models of concepts in a problem area. They are used to study the structure and the behavior of a future software system under varying conditions and the implications of different concepts in the problem space.

Domain modeling may be used in addition to existing system analysis methodologies. In that case it may augment and improve the results of the system analysis process.

Domain modeling may also be used as a single and independent tool for system analysis.

Why do we need domain modeling? There are a number of important reasons to build domain models:

Increasing Complexities. The systems we are planning nowadays are increasing in complexity. The continuing growth of hardware capabilities, the introduction of new technological possibilities, and the everlasting demands of user communities are creating continuous pressures for more advanced applications. Current methods of system developments are not adequate for these new, more complex generations of applications. Domain models can help to reduce complexities.

Missing Requirements. In an ideal situation, systems analysis starts with as input a complete, formal, and unambiguous system requirements specification. In practice, the initial system requirements are often informal, ambiguous, and incomplete. The main cause is that it is difficult to foresee all the implications and interactions in the system to build. Domain modeling may help to discover missing requirements early in the development process. Model building as a means of discovering missing requirements is frequently used in other disciplines.

Global requirements are determining the structure of a system. The detailed requirements should fit within that structure. 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.

A domain model may act as such a framework which invites for more detailed requirements from the users and which may help to discover missing requirements early in the development process. It can also be used to detect requirements which are not consistent with the implied structure, leaving the analyst with three options: either change the structure of the domain model, or discuss with the users the implications of the requirements, or do both.

Dynamic Behavior. As we saw, before a house is built a number of modeling steps are taken to ensure that the house is constructed according to the wishes of the user. The same applies to building software systems. However, there are even stronger reasons to make models before building software systems, because there are two characteristics of software systems which are not present in our building example.

A primary distinction is that while in the building industry the products are real, physical constructions, in information processing systems the software products are abstract entities. And we all know that people have more trouble to comprehend abstract concepts then concrete things.

Another difference is that in the building industry the static behavior of its products is dominant, while in computer-based systems the dynamic behavior of the systems is most important. That means that static models are not sufficient to describe a system because we know that it is often very difficult to derive from a static description the dynamic behavior and to foresee all the implications and interactions between the different parts of a running system. The essence of software, however, is its dynamic behavior! Designing complex systems using only static means is like designing an aircraft without using a wind tunnel.

In particular the combination of both characteristics makes the construction of reliable and maintainable software an inherent difficult job. The systems we want to create are both dynamic and abstract in nature. To make those systems more 'visible', we need executable domain models as simplified representations of the systems we want to build. These models should reflect the dynamic behavior of a system and may be used for experiments and study. They can also be used for interrogation to answer questions about system behavior in particular cases.

Incompatible and Partial Models. The analysis of user requirements and the translation of these requirements into proper system specifications are often determining factors for developing usable systems. As a result, many methods, techniques and tools have been developed to support the analysis activities. Many methods are based on graphical representations to specify the activities and the data of the intended system. All kinds of diagrams are used to describe certain aspects of the system, sometimes in great detail. There are many types of diagrams for data modeling, for data flow, for several kinds of activities, and so on.

However, there are a number of problems associated with these kinds of graphical representations. First of all, to support the analysis activities, more than one model is required. Models for data, supplemented by separate models for activities are often needed to model several views of a system. For example, structural, functional, and control views can be modeled. However, each model represents a partial view of the system. The total behavior of a system can only be derived by consulting a number of different models using separate notations. The translation from one model to another is often cumbersome and sometimes impossible because of lack of information. Because of these problems, the gaps in representation and meaning between different partial models are major sources of misunderstandings and errors. And we all know that errors made in the early phases of development are very costly to repair.

Domain modeling helps to solve these kinds of problems because in a domain model the static and dynamic aspects of a system are integrated into one model. Domain modeling also helps to derive from real-world concepts the corresponding information concepts.


1.3 Steps in Domain Modeling

In domain modeling the following steps are recognized:

* Step 1: Identify Key Concepts

* Step 2: Specify Domain Definitions

* Step 3: Specify Domain Operations

* Step 4: Implement Domain Specifications

* Step 5: System Modeling

These steps have the following meaning:

Step 1: Identify Key Concepts

The first step of the domain modeling process is to identify the key concepts of the problem domain. How that should be done is described in Chapter 2, "Concepts".

Step 2: Specify Domain Definitions

The second step is to specify domain definitions of the concepts identified in step 1. A domain is the representation of a concept in a domain model. Concepts in the problem domain are represented by corresponding domain definitions. Domain definitions are defining the relationships between different domains. How domains are defined is described in Chapter 3, "Domain Definitions".

Step 3: Specify Domain Operations

The third step is to specify domain operations for the domains defined in step 2. How domains operations are specified is described in Chapter 4, "Domain Operations".

Step 4: Implement Domain Specifications

The fourth step is to implement the domain specifications. Domain specifications consists of domain definitions, identified in step 2, and domain operations, specified in step 3. How domains are implemented is described in Chapter 5, "Implementation of Domain Specifications".

Step 5: System Modeling

The final step is to model the system based on implemented domains of step 4 and external events as specified for the system. How that is done is described in Chapter 6, "Systems".

The domain modeling process is in essence an iterative process. It may start with often very vague notions of the system, but after successive iterations the ultimate structure of the system should emerge. And although we have presented the modeling process as a sequence of steps, you should never forget its iterative nature.


1.4 Results of Domain Modeling

There are two main reasons for domain modeling. The first one is to get a better understanding of the problem domain in order to complete the system requirements. The second reason is to lay the foundation for the design of the system.

Domain modeling is used during the system analysis activities as a tool to support the analysis process of a system. It is particularly suited to study the dynamic behavior of the system and to discover unknown user requirements. As an operational model it can be subject to experiments to discover the optimal structure and behavior. Because the domain model deals with concepts of the problem space it should help to answer the question what the system should do.

Domain modeling can start as soon as the global requirements of the system are known. The global requirements are used to determine the structure of the model. All the detailed requirements should fit within that structure. 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.

The domain model is an executable model which can be used by users to get a much better understanding of what the ultimate system will look like. Based on that model the users may agree to build that system as represented by the model. The model is also important for the developers because it gives them more insight in the kind of system they are suppose to build.

Based on the results obtained via the domain model, the system requirements may be completed. In addition, the development plan and all its documentation can make use of the results of the analysis activities.


1.5 Moving to Systems Design

Moving from systems analysis to systems design is a progressive expansion of the model. The domain model already defines the problem-space concepts and the associated actions. The design will use the same concepts but will transform the problem-space concepts into corresponding domain-oriented solutions.

The domain model will be expanded into an design model: it should reflect the design of the system taking into consideration the implementation aspects, such as the possible hardware and software configurations, the database management system it will use, etc. The design model deals with the solution space and it should give an answer to the question how the system should work.

In addition, the design model also used as a basis for implementation.


1.6 Summary

A model is an abstracted representation of a system. Models can be a basis for investigations at much lower cost and in less time than building the system.
Domain models are abstract, prescriptive, dynamic, and executable models of concepts in a problem domain.
The reasons to build domain models are:

* Increasing complexities of future systems

* Detection of missing requirements

* Investigations of dynamic system behavior

* One unified model for a system

There are 5 steps involved in the domain modeling process.
Domain modeling may result in a better understanding of the problem space and may be used as the foundation for the design of the system.
Moving from systems analysis to systems design and from systems design to implementation are progressive expansions of the model.


Top of Page   Part 4: Domain Modeling   Chapter 1: Introduction


Home | Highlights of Elisa | Integrating Different Paradigms | Getting Started with Elisa | Demo's  | What is Domain Orientation | Bibliography | Copyright | News | Contact | Contents

Language Description:

Lexical Elements | Basic Data Types and Expressions | Definitions | Streams | Backtracking | Statements and Special Expressions | Arrays | Lists | Descriptors | Components | Collections | Generic Components | Terms | Categories | Types | Built-in Definitions | Higher-order Definitions | External Interfaces | Index 

Data Structures: Sequences | Examples involving Lists | Trees | Graphs | Searching State Spaces | Language Processing | Knowledge Representations
Domain Modeling:

Domain Modeling | Concepts | Domain Definitions | Domain Operations | Domain Implementations | Systems | Case study: an Order processing system | Case study: an Airport Support system | Domain Orientation versus Object Orientation

Design Patterns:

Introduction | Abstract Factory | Builder | Factory Method | Prototype | Singleton | Adapter | Bridge | Composite | Decorator | Facade | Flyweight | Proxy | Chain of Responsibility | Command | Interpreter | Iterator | Mediator | Memento | Observer | State | Strategy | Template Method | Visitor 


click tracking


Send me your comments


This page was last modified on 02-10-2012 17:26:28   

free hit counter