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.
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
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
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
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
Inoperational models are models which
cannot be executed. Many models, used for the analysis of
software systems are inoperational 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
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
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
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
Steps in Domain Modeling
In domain modeling the following steps
* Step 1: Identify Key Concepts
* Step 2: Specify Domain
* Step 3: Specify Domain Operations
* Step 4: Implement Domain
* Step 5: System Modeling
These steps have the following meaning:
Step 1: Identify Key Concepts