The core of The Integrated
Method (TIMe) will be presented in the following. TIMe is centered around
a number of descriptions
which are developed by activities
. These descriptions express domain
in terms of external properties, system
designs in terms of structure and behaviour, implementation
mappings and system instantiation. They are organised in three main
areas of concern
and the system
It is assumed that the
Languages and Notations
to make descriptions and the Foundation
of TIMe are known to the reader.
The content is organised
overview which introduces the main descriptions and how they are
overview which introduces the main activities and how they are
- Description modules. Here
we present the various descriptions as modules with associated operations.
They are organised according to the three areas of concern:
Figure 1: The main descriptions used in TIMe
Areas of concern
As can be seen from Figure
, the descriptions are organised within three areas
, system family
In each area there are formal models and there are other
descriptions (dictionaries, statements and auxiliary). The formal core
of the methodology is the models which are expressed using the well defined
These descriptions are
necessary and sufficient to achieve central goals of TIMe:
- to improve common understanding and communication
among the people involved in all areas of concern;
- to achieve a controlled process towards quality results;
- to achieve flexibility in services and system designs;
- to minimise cost and lead times and to increase reuse.
The descriptions have been
carefully selected. They are neither too few, nor too many. There is little
redundancy, as they describe different aspects and complement each other
in a complete, concise and readable documentation. TIMe keeps the amount
of temporary (throw away) descriptions to a minimum, and emphasizes descriptions
that end up as final documentation. This does not prevent us from identifying
partial descriptions that are useful in their own right, such as specifications,
and to issue them in separate documents when needed.
Textual explanations may
be attached to models as well as to other descriptions.
models which are collections of classes with attributes, relations
and associated properties. They may be organised in several abstractions.
Since the domain is about general concepts and processes that are common
to many systems, it is likely that some parts of the domain models will
be used within the family models. These parts will often be quite stable,
reusable and resilient to change.
statements which are concise statements about the domain normally
expressed in prose.
dictionaries over common domain terminology. It is important that
the terminology used in other domain descriptions is harmonized with and
defined in the dictionary.
auxiliary descriptions which are any other description used, and
will often be informal text and illustrations used to help reading the
Family models which are object models and property
models describing the family on several levels of abstraction:
that describe what the user environment want the system to do (user services).
that describe how applications are distributed and supported by an infrastructure.
Frameworks and applications together define the complete system behaviour.
that describe how frameworks and applications are realised in terms of
hardware and software nodes.
Family implementations which are implementations
of family concepts. Here we find the general parts of implementations that
are stable over all instances.
Family statements which are concise statements
about the family: its main purposes, its market and qualities.
Family dictionaries which define the family
Auxiliary descriptions which are any other description
used, for instance test plans.
Instance models which define the particular
system instance on all abstraction levels. These may be self contained
system models, but it is recommended to define instances as configurations
Implementations which are the instance specific
implementations such as configuration files.
Auxiliary descriptions which are any other description
of the instance, for instance a test suite.
As explained in Objects
and properties, models have the facets illustrated in Figure
2. In general there are object models and property models. Seen
together they define a context
and a content.
The context represents the entity being defined (e.g. a system type)
as a "black" box and details its environment, while the content details
its internal composition in terms of object structures and behaviour.
Figure 2: The facets
of a type model
covers those aspects of a model that are relevant for its external representation
and use, while the design cover the internal composition and the internal
The distinction between specifications
and designs is not so important in domain models, while in system family
models it is important. This has been illustrated for application, framework
and architecture models in Figure
A specification covers those
aspects of a model that are relevant for its external representation and
use. The context
part is often sufficient as a specification, but if parts of the content
are important it may be included in the specification. Specifications are
associated with the abstractions they belong to.
Specifications are partial models
TIMe emphasises that specifications
are not special models, but integral parts of type models. The reason is
that we want to minimise the amount of descriptions that are thrown away.
In stead we want to make use of specifications throughout the lifetime
of a model:
- first to express the
required properties so they can be verified and validated;
- then to synthesise the
design in a way that satisfies the specification;
- finally to describe its provided properties for later assessment, (re)use, validation and evolution purposes.
Specifications vs design
System Family specifications
contain the specification parts of application, framework and Architecture
models. These are related to the design parts, as indicated below.
Figure 3: Specification and design related
Specifications and designs
are often developed in different phases. Specifications are produced early
and play a central role in quality and process control. Designs are produced
later. Therefore, in a development project they are developed by separate
steps as illustrated in Figure
In TIMe we consider a requirements
specification as a document
It is normally produced early in a development project and used as a
contract for the design work. It will contain specifications and other
items of relevance at that stage.
Specifications should be
kept consistent with the properties provided by a design. We foresee that
specification are used:
for validation of applications;
Qualities of specifications
Important qualities of
precision and detail;
traceability and verifiability;
modularity that will support evolution and change.
Make a context diagram where the entity being
specified is identified and the system environment is detailed. Describe
communication interfaces and other relations the entity will handle.
<click for context diagram>
Do not show everything in the environment,
only the parts that are related to the entity being specified.
Avoid to state content requirements in specifications
unless absolutely necessary and well justified.
the parts that are subject to requirements. Avoid describing more than
Use open aggregation to illustrate how entities
in the environment are related and connected to components.
<Click for example>
The descriptions within
different areas of concern and on different abstraction levels are developed
in steps that help to reduce risk, and to improve quality and control.
This help to give better control and also to use the skills of different
people better and to run activities in parallel.
Each model is developed in
two main steps: first the specification step where the specification part
(interfaces and the required properties) is made, and then the synthesis
step where the design part is developed.The main development cycles are
illustrated in Figure
Figure 4: The main
This is of course a simplified
illustration of the main steps. Considered over time we will see that the
descriptions evolve gradually, that there are many iterations and that
changes take place due to better insight, new requirements and new technology.
We will also see that there are other, smaller cycles. For instance: to
add a new service or feature to an existing product we need not modify
the domain. To produce a customized instance we only need to add a new
Not only waterfall
Please do not jump to the
conclusion that TIMe only supports the classical "waterfall" model! It
is up to the actual projects to determine whether they will adopt a waterfall
strategy, a prototyping strategy, use incremental development or whatever.
What TIMe provides is a set
of descriptions and some general development activities including strategies
and rules, see Figure
7. The activities are described in Activity
is a domain?
is a part of the world where a system
instance may be a (partial) solution to some need (the problem).
As a part of the real world
the domain may be very large and not well delimited from other parts of
the world. Obviously, the domain
descriptions cannot describe it all. It is necessary to focus on
those parts that are important for the family of systems in consideration.
A natural consequence is to consider only a subset of the world that may
somehow be served by a family member
The domain consists of physical
entities such as persons, cards and doors as well as conceptual entities
such as transactions and rules. The entities may be linked by physical
connections that enable entities to communicate or by associations.
Important entity classes
holder. These are persons, institutions or systems with direct
or indirect interest in the domain, such as users, owners, and producers.
Needs originate from the stake holders, so it is extremely important to
have a clear understanding of who they are, what they want to achieve and
what their priorities are. These stake holders may have quite different
needs that are not easily conveyed in a single model. Consequently, it
will be important to identify the various classes of stake holders and
possibly develop a set of models to properly describe their different views
on the problem domain. In the Access Control system for instance, the operator´s
view is different from the user´s view. A very important category
are the Actors
of the domain, the stake holders that take part in the services or processes
of the domain. These are later going to be supported and/or represented
by the system.
These are general tools that are used by the actors to provide services.
Examples are communication systems, radar equipment and keys.
entities. These are entities that are subject to manipulation,
representation or control in the domain. They may be materials in the case
of a material transformation domain, e.g. moulding, or they may be entities
represented in an information system, e.g. flights and seats, or they may
be controlled machinery, e.g. a paper mill.
These are entities representing transactions or events in the dynamic
behaviour of the domain, e.g. the purchase of a car, or a user passing
In general the entities
seeks to accomplish some services or transformation processes. Their basic
need is to provide these in the best possible way.
Figure 5: Elements of
The domain descriptions
help to describe and clarify the needs of all the stake holders. Needs
may be classified as needs to:
know about entities and relationships,
e.g. the identity of users and which doors they are allowed to pass;
communicate among objects,
e.g. for two persons to communicate;
transform objects from one
form to another, e.g. to peel shrimps, to send a fax or to compile a program;
control something, i.e. to
control or manipulate knowledge, transformations and communications, e.g.
to control a fax machine.
Difference from systems
The problem domain has
a wider scope than any system in the domain, as its focus is on what the
systems are (to be) used for, i.e.WHY the systems are needed. Compared
to a system context, it should be wider and more general. By studying the
whole it is easier to see the purpose of the parts.
Thus, by studying a wider
context, it is possible to get a better understanding of WHY the system
is needed and what properties it should have. For instance, if the system
is a communication system, we may consider why the communication is needed.
In what kind of processes is the communication to be used? What are the
success criteria for those?
By asking such questions
we get a better understanding of the underlying needs and may be able to
suggest new solutions. Perhaps the real need is not for a communication
system after all? Or, perhaps the need is for a completely new kind of
integration between communication and transaction systems?
A problem domain may well
be modelled as any other system. Compared to systems in the solution domain
there are some differences, however:
The domain will normally include people, so
it is a socio-technical system.
The domain need not have well defined interfaces
as it is not going to be used as a component.
The domain need not be completely composed or
operational to the same degree as systems. It may well be described by
The domain avoids system specific solutions.
The enterprise view in
ODP serves the same purpose as the domain here. However, in the domain
we do not wish to identify a particular system or system context. We want
the domain to be general and independent of particular systems for several
Open system analysis. We want the domain as
a foundation for system analysis. It should not bind the solution but allow
us to investigate many alternatives.
Common concepts. We want the domain to describe
common concepts and terminology that can help different communities to
communicate: users, marketing, development, engineering.
Reuse. We want to identify concepts and properties
that will be needed in many different system families, and thereby promote
reuse. The domain given parts of systems (see System
reference models) contain such reusable parts.
In principle, the problem
domain can be modelled as a (socio-technical) system, more ore less, like
any other system. In practice a more fragmented view, with focus on the
needs of various stake holders is more useful. It enables us to describe
and to analyse different viewpoints without enforcing the completeness
and consistency required in a system model at this stage.
The domain may be described
on all three abstraction levels (see Abstractions
in models). Normally only the abstract application level is considered
and this is what most methods consider as the "domain". It is also what
we shall consider the domain unless otherwise stated.
However, it is also possible
to describe e.g. the infrastructure domain and the platform domain. Here
we may describe common features of infrastructures, say user interfaces,
and platforms, say middelware like CORBA . These other domains will end up in other parts of the system such
as the interface given parts or the platform.
It is not always obvious
what to include in the problem domain. One should avoid system specific
solutions, but concentrate on more general concepts and properties that
will be common to many systems. For information systems this will typically
be types of passive objects (see Active
and passive objects) and associations that will be represented
in every system in the domain. For instance it is reasonable to believe
that every seat reservation system will handle flights, seats and passengers.
System specific solutions
should be avoided, but general objects/types and functions performed by
(parts of) systems shall be covered.
make domain descriptions?
descriptions are used to define a domain
and its terminology. domain descriptions serve three main purposes:
To provide a firm basis for communication and
common understanding amongst different Stake
holders such as: end users, owners, developers, marketing and production.
To provide a firm basis for product planning,
i.e. to analyse needs, to seek possible solutions and to specify the goals
for a new product development. In this it is extremely important to consider
variability and to plan a system
family from the beginning that will cater for the variability.
During product planning it is also important to consider existing systems
To boost productivity and quality by systematically
capturing and maintaining common knowledge in one place (possibly at a
strategic company level) rather than arbitrarily in various system specific
documents. Domain descriptions will hold for many different systems and
identify stable, reusable concepts and properties. Components that are
derived from them are likely to be quite stable and therefore reusable
across systems and system families. The domain given part of the application
reference model has been introduced to highlight this aspect, see Domain
To establish a common understanding of terminology,
phenomena, concepts, and tasks by making domain descriptions (a set of
models and a set of rigorous prose specifications).
To describe general objects/types and properties
that is common to many systems in the domain and thereby achieve a high
degree of reuse.
Domain descriptions contain
the following description modules:
models and auxiliary domain descriptions.
The domain will normally
include entities that will be part of (the domain given part of) systems,
see Figure 6
Figure 6: Parts of
the (application) domain will be realised in the domain given part of systems
We seek to keep the domain
given parts of systems formally related to the domain. These parts may
not only contain "data objects" (passive objects), but also active objects.
In the end, the domain models should cover all the domain given parts of
The various domain descriptions
should be harmonised as much as possible with each other: phenomena
and concepts in the dictionary should have their counterparts in the domain
object model. If properties are properties of entities in the dictionary,
then the terminology introduced there should be used in the property models.
Align the domain object model, the property
model, the statement and the dictionary with each other. At least define
every main term in the statement in the dictionary.
As an example
of this guideline, look at the example descriptions and see how Access
Zone , Access Point and User are treated in them.
Details will be given for
the component descriptions: Domain
object models and Domain
When system families are
introduced, domain descriptions will be harmonised and extended to cover
what is common for many systems or system types. Domain descriptions are
extended and detailed so that they take domain specific system elements
into consideration. The purposes are:
- to promote reuse;
- to improve traceability;
- to simplify maintenance;
- to simplify design.
There are two sub-activities:
Reuse analysis: to analyse the design looking
for object types and properties that will be common to most systems in
the domain. They will then be re-used in system designs (families and system
add new object types and
properties to the domain descriptions;
adjust the domain descriptions
to correspond as closely as possible with design without introducing system
Establish links: define the relationships between
design and domain descriptions.
is a family?
contains the generic result of systems development. It represent
a product base on which a company may capitalise by producing and selling
system instances. As explained in Abstractions
, systems are modelled on several levels of abstraction:
Each level is developed
in two main steps: the specification step which emphasises external properties
and the design step which emphasises the internal content. The general
approach is to work from the application level towards the implementation
level and from the specification towards the design within each level.
Note that applications, frameworks,
and architectures are somewhat independent and interchangeable. An application
may, for instance, fit into several frameworks, and a framework may accommodate
several applications. Each may use components that are shared between families.
In most cases a system family
is designed to serve one market segment within a domain. As the application
level is closest to the market needs, it seems natural that the system
family should be defined on the application level. However, to fully generate
system instances, we need information provided in the framework, architecture
and implementation levels. Therefore these levels must be included when
we want to produce concrete system instances. To produce an abstract system
instance for simulation purposes, on the other hand, the application level
Types and Families
Object models in the family
area will contain types defined with a context and a content, see Anatomy
of object models
To some extent it is possible to define a system
family formally as a type, e.g a System Type in SDL. But to define the
family as just one type would probably be too restrictive:
it would make the family specific to the level
(application, framework, architecture) where the type belongs;
it would not capture the component libraries
it would be restricted to what is formally expressible
in the languages.
In stead we consider the
system family as a more loose organisation (library) of types and other
generic entities, which are used to generate system instances within a
domain. A system family need not be self contained. It may well import
parts from and export to other system families.
When to use
There are cases (one-of-a-kind
systems) where a family may seem to be overkill. But even in such cases
it appears that most results are generic in the sense that they can be
used to produce many similar system instances. They may also contain parts
that can be used in different systems. Therefore there is an implicit system
family, which is made up by the generic system descriptions that are produced
anyhow, even in these cases.
In more interesting cases
many instances with a range of different properties shall be produced.
In such cases it is desirable to analyse the needs for variability, and
to design the family so that instances can be configurated and build as
cost effectively as possible. This may require some additional design effort
that has to be balanced by savings later on when system instances are configurated
Variability can be represented
in two principally different ways:
By different versions of descriptions. This
kind of variability (outside the descriptions) is traditionally handled
by configuration management systems, see
Software configuration management.
By variable parts in the descriptions, typically
by parameters, configuration variables, virtuality. This kind of variability
is expressed in the notations and languages we use.
Our main focus here will
be on the latter kind of internal variability. It involve all the descriptions
in a system family.
make family descriptions?
The central idea behind the
concept is that companies will benefit from being more "product oriented".
Rather than being driven by the short term goals of individual system deliveries,
which is tempting since each system sold give immediate payback, development
effort should be invested in lasting results that can generate a better
business in the long run. Companies that focus too much on individual systems
tend not to have a clear picture of what their products are and how they
relate to the market. They often have difficulties in keeping the cost
down and to keep schedules. After some time they get trapped in vicious
circles where they never have time nor money to improve.
development effort should be invested where
the results can be resold many times;
the cost of each adaptation and sale should
be as low as possible
The family concept is introduced
to achieve these goals and to given an overall cost reduction.
of family descriptions
A system family contains
the following main description modules:
family statement - a concise prose statement that characterises
systems in the family.
- a dictionary over family specific terminology.
studies - which are temporary descriptions of alternative system
principles made in order to assess alternatives and choose the best
models - which define the system behaviour related to user needs.
models - which define additional behaviour needed to support the
models - which define the physical platform and how the framework
functionality is implemented.
implementations - which contain the implementation details in programming
languages and hardware description languages.
auxiliary - which contain other descriptions such as methods for
evolution and instantiation.
The needs for variability
is considered on each abstraction level and for the system family as whole.
An important result is a method for binding the variability and configuring
Another important result
is a method for flexible introduction of new services. One main goal is
that the method shall lead to a flexible framework and Architecture that
will allow us to add new services mainly by working on the application
System studies are made
in order to create deeper understanding of the technical problems and solution
possibilities at an early stage. By exploring the "solution space" for
a given problem they seek to find innovative solutions that will lead to
better systems. "Better" in the sense that the quality is good, that the
cost is competitive the solution is flexible for change.
System studies are not
a special kind of descriptions, but rather incomplete family descriptions
that are sufficiently detailed that alternative solutions may be compared
and assessed. This means that it must be possible to compare development
costs, production costs, risks and potential user satisfaction. It may
be necessary to perform prototype developments and laboratory experiments.
Note that system studies
involves all the abstraction levels, and builds on the activities described
for those. It can be seen as the start of system specification.
The results are system sketches
consisting of rough specifications and content outlines. They need not
be very detailed, but sufficiently detailed to identify all critical parts
and the principle for implementing all services. They should be more detailed
where there is uncertainty concerning technology, performance or cost.
Note that the resulting descriptions
(for the selected system concept) are not to be thrown away. They are to
be gradually elaborated into complete descriptions. However, if well formed,
they may later serve as an executive introduction to the system.
- Feasibility studies which
are performed when a new system family is to be made.
- Impact studies which are performed when an existing system family is to be evolved.
System study notations
Do not feel obliged to use only UML
in all sketches needed during this activity. It is more important that
all possible elements of the system and its environment come forward. Make
competing sketches. Have possibly one person responsible for "formalising"
these sketches into or UML sketches.
A system instance is a (real
which can perform behaviour and provide services.
The system instance area
of concern contains system
instances produced from system families. An instance
description describes a system instance.
When a system family is defined,
a system instance can be defined by reference to a system family using
relatively simple configuration statements to binds the variability in
the family. If there is no family however, it is necessary to define each
system instance completely in self a contained instance description.This
can only be recommended for one-of-a-kind developments.
In TIMe, system instance
descriptions are organised in:
Instance models that formally define the system
instance, usually by configuration of some family;
instance auxiliary descriptions that provide
instance implementations which are the instance
specific implementations such as configuration files.
Relations and traceability
It is clearly necessary
to establish and maintain clear and traceable relationships between the
various descriptions and models. There are several reasons:
Since each model or description is concerned
with a limited area of concern and abstraction, a complete documentation
is made up of a set of interrelated models/descriptions. In order to read
and understand this complete documentation it must be possible for a reader
to navigate in the descriptions and to understand the relationships as
easily as possible.
We need to trace the relationships from required
properties to the design objects where they are provided. There are at
least, two reasons for this:
quality assurance need to
check that every requirement is satisfied;
when a requirement is changed
we need to analyse what impact it will have on the design.
We need to ensure consistency both between models
and within models. This can be achieved either correctively by comparing
models or constructively by ensuring that models are derived according
to rules, e.g. by automatically translating from abstract models to implementations.
Domain to family relations:
object to object;
property to property.
Family to instance relations:
object to object;
property to property.
Family internal relations:
application to framework
property to object relations,
specification to design relations,
validity of interfaces,
dictionary, statement and
Domain internal relations:
dictionary, statement and
Instance internal relations
The precise definition
of relationships depend on the languages that are used. They will be elaborated
under the various description modules.
Figure 7: The main
activities in TIMe
As illustrated in Figure
, TIMe consists of five main activities:
Analysing. The purpose of this activity is to analyse a domain and to specify
the requirements to a new system family. It makes the following descriptions
for the first time:
domain and family statement;
domain and family dictionary;
application, framework and
Designing. The purpose of this activity is to develop the design part of application,
framework and architecture models, including the detailed behaviour of
Implementing. In this activity all the detailed implementation descriptions are
produced including source code for the software and detailed hardware descriptions.
Instantiating. The purpose of this activity is to produce (executable) system instances
that satisfy specific suer needs.
For each activity we
seek to give practical strategies and rules that will help to produce high
quality descriptions and target systems. As far as possible the approach
will be illustrated by practical Examples
These main activities
consists of sub-activities. At the lowest level, sub-activities are seen
as tasks (operations) that "belong to" description modules, for instance
domain object models. Such tasks will be described under the description
modules they belong to.
Specifications and designs
have been identified as separate entities in Figure
7 in order to distinguish the specification and design activities.
The reader should we aware that this does not imply a separation of the
System development is rarely
a straight forward process where the optimal solution is found at first
attempt. It is more of a trial and error process. By working with a particular
solution we often learn how it can be improved or get ideas for radically
better solutions. Therefore it is recommended to spend some time investigating
the solution space before selecting the system concept to develop. For
this purpose we develop System
studies which are compared and analysed with respect to cost, technical
feasibility and market potential. The most favorable alternative is then
selected for further development, if indeed it has sufficient business
There is no specific ordering
imposed on the activities themselves, but in practical projects they will
be ordered, and indeed the ordering is significant. It is essential that
specifications, designs and implementations follow each other in that order
for each part of the system. But it is not necessary that every part is
developed at the same time. Therefore it is possible to start design before
all parts are specified, and to start implementation before all parts are
designed. This is further elaborated in the
It is important to note that
the activities are not independent, but influence each other in various
ways. As an example, a design activity may lead to insight that triggers
a change in the domain models. These mutual interactions are not indicated
in Figure 7,
but will be explained in the text. We have sought to describe the activities
in a generic way that can be used in most processes. However, the best
way to carry out an activity depends on the actual state of its input descriptions
and output descriptions at the time when it is invoked. In order to take
this into account, we provide some alternative strategies and activity
Make activities which make or synthesise
descriptions for the first time, possibly based on other descriptions,
e.g. to make SDL process graphs from requirements expressed using MSC.
Evolve activities which perform (incremental)
development of existing descriptions. They may either add new properties,
e.g. add a new service to existing application models, or change
existing properties, e.g. correct errors.
Harmonise activities which ensure that
models/descriptions are consistent with each other, e.g. to make the domain
dictionary consistent with the domain object models.
We may distinguish two cases:
- Developing from scratch,
where a new domain and a new system family is developed without any product
base to start from. The starting point is just some needs or a product
- Developing from existing
families where a new system family is developed using existing families
as basis. In principle we go through the same steps as when developing
from scratch, but now we seek to utilise as much as possible from the existing
Families. Design by reuse is a central concern. This case is considered
the normal for development of new system families in a company that have
used TIMe for some time. Such companies have established extensive domain
descriptions and component libraries which are taken into account in all
Both cases will follow
the same overall strategy, but the detailed activities will be different.
Normal development will put more emphasis on reuse and adaptation of existing
solutions. If, for instance the framework and the architecture is reused
from an existing family and only the family is modified, then the effort
will be far less than when developing from scratch.
Evolution is caused by new
requirements. It may be requirements for new services or service features,
it may be requirements for a new platform, or requirements for a new interface.
The abstractions and the system reference model we use in TIMe has been
chosen with evolution in mind. Areas that are likely to change independently
of each other are separated:
Changes in services or user interfaces are defined
on the application level. Here the distinction between domain given, system
given and interface given parts, help to further isolate changes.
Changes in implementation platform are defined
on the architecture and the implementation levels.
Changes in infrastructure are defined on the
The situation today is
characterised by increasing demands for service flexibility. In order to
stay ahead of competition, the lead time for specifying and implementing
new services must be as short as possible. At the same time, many products
must be supported on a range of different platforms. This means that system
Families should be designed with flexibility and diversity in mind and
supported by tools.
The various evolution activities
are dealt with for each description module separately.
The harmonising activities
take care of the iterations and feed-back between the various descriptions.
The objectives of analysing
To understand the domain and what users and other
stake holders want to achieve, i.e. their needs.
To find improvements they will consider valuable.
To plan new product families that will give valuable
improvement and thus create business in the future
Analysing is part of product
planning which is a more or less, continuous task in any prosperous company.
It is constrained by the company's strategic plans and seeks to come up
with ideas for new products or enhancements to existing products.
Figure 8: Analysing
Central to the task is
a deep knowledge about a problem domain and existing system solutions.
It seeks to identify a problem, i.e. some deficiency or opportunity for
improvement, that a new system family may solve. This should not be just
any problem, but something that would mean considerable improvement and
thus have sufficient value for some stake holders to justify an investment
in the new system. Thus the core of the task is to understand needs and
The concrete results are
domain descriptions, system studies and specifications
families that may create future businesses. A business is created
when a product and a production meets a market. Thus, commercial success
depends on more than the product qualities. It also depend on the marketing
and the production. Consequently it is recommended to develop the product,
the market and the production in parallel.The domain relates clearly to
the market, and the instances to production. In this way TIMe supports
integrated development of all three areas.
Analysis consists of two
Analysis require multidisciplinary
teams. Key personnel are domain experts such as marketing people and real
users, but system developers should also participate both to improve their
own problem understanding and to help finding improvements. It is a task
where experts in the problem domain meets experts in the solution domain
and new opportunities arise out of their combined effort.
There may also be existing
literature, existing systems and possibly existing domain descriptions
to use. Existing systems is an important source. Consider what parts of
the domain they cover. Can competitive advantage be gained if we cover
more? or less?
What to do
"How can you possibly
find the solution if you haven't grasped the problem?" (adapted form a
wise saying at Ericsson).
This wisdom tells us that
understanding the problem should come first: start by describing and analysing
the domain, and go from there towards possible solutions. However, when
the domain is well defined and the challenge is to gain competitive edge
through innovative solutions, the solution comes first.
Therefore, the strategy will
depend on the quality of existing domain descriptions, and whether the
challenge lies in the problem or in the solution.
Note that domains are not
entirely independent of design concepts or technology. New technology enable
improvements that were not feasible and perhaps even not imaginable before.
For instance: the access control domain was different before cards were
introduced than after. Before there were keys, but no need for person identification.
After, person identification is a central issue.
Figure 9: Domain - system
The old solution was traditional
keys that were hard coded according to access zones. With new technology
it became feasible to use personal cards and PIN codes instead and thereby
achieve more flexibility and security. This change led to a changed domain
model where person identification and authentication is a central issue.
In order to get a good start
with the first domain descriptions it may be a good idea simply to model
the current reality first. If the challenge is to reengineer existing systems,
then first establish a domain description corresponding to the usage of
the existing systems.
When initial understanding
of the problem domain is established, the next step is to start looking
for improvements in terms of new technologies, innovative system solutions
or just better ways to organise work. What are the problems today, and
what may be improved? Answering these questions and setting goals for improvement
is the soul of product planning and should not be taken lightly.
If the improvements have
effect on the domain, then make an new or updated domain description.
When the goals for improvement
has been set it is time to start looking for technical principles and solutions.
We start by Analysing
solutions seeking to come up with alternative system ideas that
may be evaluated and compared. How this is to be done depends on the problem,
but it will involve making a mixture of object models and property models
for the new family (or system instance if it is a one-shot development).
These models are called System
In the beginning, these models
may be independent of any particular system boundary. In fact it may be
a good idea not to identify the system initially, but use the models to
analyse what shall be done, and how it may be done. When this is well understood,
the next step is to decide what shall be done by the system, and what shall
be done by the environment.
The result will be a number
of alternative product outlines that may be analysed with respect to technical
feasibility, risks, cost and schedules.
Finally, the most promising
system concept is selected among the alternatives, and a go/no-go decision
is made based on business criteria, available resources and schedules.
If it is go, then a specification is developed.
A major goal for analysing
is to decide what parts of a problem domain to include or support by a
new product. Obviously the domain analysis should be more detailed for
those parts. Therefore there is a mutual influence between domain analysis
and solution analysis.
We define two main strategies:
analysing from scratch and analysing from existing domain.
Analysing from scratch
If the problem domain is
new or the quality of existing domain descriptions low the following strategy
can be used.
It is quite normal that
domain models and system family models influence each other. Therefore
it may be a good strategy to start analysing solutions before the domain
models are completed.
If the problem domain is well
described, and the main challenge is to find new technical solutions, then
the following strategy is recommended.
We perform domain analysis
in order to:
understand the domain and make domain descriptions;
analyse the domain seeking improvements of value
for the stake holders;
evolve and harmonise the domain descriptions.
Domain analysis is primarily
concerned with the problem domain. In addition to general knowledge of
the problem domain, knowledge about existing systems is important. It is
important to identify the strong and the weak sides of existing solutions.
It may be useful to first model the existing domain including existing
systems, and then look for ways the domain may be improved. As a result
a future domain may be described. If systems are used in different markets
for different purposes, several domains may be described.
Figure 10: Analysing domain
We perform domain analysis
by means of the following sub-activities:
The people to involve are
stake holders in the domain such as users and other actors, market people
and other domain experts.
What to do
Which sub-activity to start
with will be a matter of choice. For a new domain it is recommended to
start with the domain statement and the dictionary, and continue with the
object models and the property models. For an existing domain, it may be
better to start with object and property models. In both cases there will
be iterations between domain descriptions and design descriptions.
Making domain descriptions
In this activity we seek
to define a domain for the first time. The main purpose is to understand
the domain in terms of concepts, objects and relationships and to understand
the needs that various stake holders have (the problem). We have no existing
system family to consider (but there may be other existing systems in the
Work on the object and
property models will normally lead to clarification and more complete understanding
which should be used to improve the dictionary and domain statement.
Evolving domain descriptions
Here the purpose is to analyse
and improve existing domain descriptions. A typical reason may be that
we have revealed imperfections or are looking for improvements that will
lead to a new and better domain description or that we need to add details.
This will typically be the case when we plan new products in an existing
domain. The strategy will depend on the circumstances, but since we already
have a domain statement and a dictionary, it may be a good idea to start
with the formal models in this case.
of dynamic domain rules
Domain modelling approach
Establish contact with domain experts and
other sources of information about the domain.
Present your results and have frequent discussions
with domain experts.
Do not use too much time on problem domain
analysis if experiences with making systems in the domain are poor. Iterate
with system analysis and possibly system design.
Study existing systems, and make use of existing
descriptions and literature about the problem domain.
Iterate with requirements analysis to explore
new solutions and to find ways to improve the problem domain. (Remember
that some problems may go away, and new opportunities be opened, when new
ways are found. E.g. with personal cards, lost keys are not a problem any
Finding domain objects
A problem domain may be very comprehensive.
Do not try to model everything that might be considered part of the domain
in some wide sense. Concentrate on parts that may be supported by new products.
As a start, consider how things are done
today and describe the existing domain. Then consider how it may be improved
and develop a new domain description.
Focus on abstract objects that are essentially
needed and avoid system specific solutions. This does not exclude elements
that eventually will be part of systems. The essential thing is that the
problem domain generalises over system specific solutions. Classes of objects
coming from an analysis of the problem domain are candidates for reuse
across systems, but reuse requires at least one use.
When systems are defined, use the Application
reference model to classify the entities into interface, system, and domain
specific parts. Generalisations of the domain specific entities should
be included in the problem domain.
Model the actors
Be sure to represent each type of stake holder
in the domain statement, dictionary and object model.
For each stake holder, describe their needs
for services and interfaces.
Represent every actor as a type with context
in the object model and describe its services in property models.
is performed in order to analyse needs and to develop specifications. Not
just any specifications, but specifications for system Families with a
business potential. domain descriptions where needs for improvement are
identified is a good starting point for this activity.
Figure 11: Analysing requirements
The activity is crucial
for the success of a system family as it seeks to answer questions like:
what parts of the problem domain should be supported
by the system family;
what should be the environment and the interfaces
of the system family;
what should be the positioning properties and
the duty properties of the system family;
what should be the main technological principles;
what are the requirements to future instantiation
A central issue is to balance
the needs against technical feasibility and cost. To this end, system studies
are made where alternative system concept can be evaluated and compared.
(These may be seen as mini developments.) If any of the alternatives seems
feasible and attractive from a business viewpoint, the best is chosen for
For the selected concept
a specification is produced.
It is of course possible
to make specifications without (explicitly) analysing the domain and analysing
solutions first, but it will be more difficult. Parts of these activities
will then have to be done implicitly in the specification activity. With
explicit domain descriptions and system studies, the goals for the system
development are known, and the task of specification is to express them
precisely and detailed.
Developers, market persons,
and stake holders in the domain should all participate. Go/no-go decisions
will of course involve management.
What to do
The first thing to do is
to make system studies seeking for a viable overall system concept. If
such a concept is found the next step is to develop a system family statement
and start on a dictionary, and then to develop specifications.
When making requirements
for the first time, we assume there are domain descriptions to use as input,
but there is no existing family (apart from those that other companies
might have on the market).
In this case we have existing
system family descriptions to start from. We assume the reason for evolution
is that some external requirements have been added or changed. (Changes
caused by internal iterations are handled by harmonising) In this case
too, we start with the formal specifications
of dynamic requirements rules
Requirements analysis approach
This is a creative activity, so creative
techniques such as brain storming may prove useful.
At an early stage do not be afraid of unconventional
solutions. On the contrary, look for them.
Remember that the purpose is to find a new
and better way to satisfy the needs of stake holders. Therefore, close
interaction with stake holders and domain modelling is strongly recommended.
The main purpose is not to find design solutions,
but to determine the external properties and interfaces, in particular
which services the system are going to provide. Therefore the focus should
be on context, and not content.
Elaborate content only where this is necessary
to assess the feasibility or to estimate cost an risk. Be prepared to reconsider
content that is sketched at this stage.
Use prototyping when this is cost effective,
i.e. when the additional cost of a prototype is justified by improved communication,
decision making and/or reduced risk.
State explicitly the
project and product requirements. These requirements are often requirements
to the tools and languages of the project.
The purpose of analysing
solutions is too consider the needs and how they may be satisfied. It is
an interplay between the what and the how.
Inputs to the activity are
needs and domain descriptions. Central decisions to be made are what needs
to satisfy, in particular which services to provide, and what technology
The activity is the first
step in turning needs into solutions. It can consist of many mini-development
projects with the purpose of exploring alternative solutions. The activity
may therefore produce a number of alternative system Sketches. The detailing
of these sketches depends upon the knowledge about the desired system and
the risks involved.
For each system concept:
- Selecting services to
- Sketching the environment.
- Sketching the application.
- Sketching the architecture.
- Identification of and assessment
of risk and critical issues.
- Assessing cost and schedules.
- Evolution and maintenance.
When some promising alternatives
have been sketched they shall be compared and the best selected. This forms
the input to make family statement and Make Specifications.
The main inputs to this
activity are informal statements about needs, the domain descriptions and
Outputs are precise specifications
expressed on the relevant abstraction levels. The focus is on properties
and context. The challenge is to structure the input information, find
missing detail and organise the specification. Clarifications and iterations
will be needed.
Specifications are developed
by development persons in close cooperation with users and other stake
holders. System and market departments should also take part, if not in
the detailed work, at least in major decisions.
What to do
Turning needs into specifications
is not always straight forward. On one hand it is necessary to clarify
the needs in order to make the specifications sufficiently precise and
detailed. On the other hand it is necessary to consider technical feasibility,
economy and schedules. Finally it is necessary to consider how each particular
requirement will interact with other requirements. An iterative process
is required where users and other stake holders take actively part.
It is assumed here that specification
is proceeded by system studies where an overall system concept has been
selected. It is clear roughly what parts of the domain that shall be covered
by the system family, and what properties it shall have. The goal is to
state this more precisely and with more detail.
For a general approach to
making specifications more precise and detailed, see The
dialectics of refinement.
When specifications are developed
for the first time, the following strategy may be used.
When new requirements lead
to changes in specifications, follow this strategy:
of dynamic specification rules
In order to achieve flexibility in the development
process and the product, try to make the specifications modular so it is
as easy as possible to add or change specifications.
If flexibility is important, express this
as clearly as possible in the specification (in the Auxiliary descriptions,
in the statement or in textual annotations to the models).
State clearly the requirements to methods for
(incremental) evolution, code generation and instantiation.
The main outputs are the
corresponding design models:
Application design, Framework
design and Designing
architecture. In addition one should consider how implementations
shall be generated, how instances shall be produced and how evolution is
to be done, in particular how services shall be added. This is described
as part of the Family
Figure 12: Designing
Designing is not a monolithic
activity. It is composed from activities that each require considerable
effort, especially when developing from scratch:
applications which synthesises the application design from the
application specifications, and verifies that the specifications are satisfied
by the design. Both when making and evolving a design it is recommended
to take existing components into account (designing with reuse) and to
keep a close relationship between service roles, interface roles and design
objects (service orientation). When a new object behaviour must be designed,
try to synthesise object behaviour from service and interface roles.
architecture which synthesises the architecture design from the
architecture specification and the application design. The goal of this
activity is to define an implementation architecture which will implement
the application and satisfy the non-functional requirements. This activity
will often require a cut and try approach, where an architecture is suggested,
and then evaluated with respect to performance, error handling, and other
non-functional properties. As platforms become more standardised, this
activity can focus more on the application specific architecture.
framework structure and Designing
framework behaviour which takes the infrastructure required by
the implementation architecture into account and define a framework. It
also verifies that the specification part is satisfied. Once the framework
has been defined it is likely that the application must be harmonised so
that it uses the infrastructure part of the framework. It should be noted
that a framework is useful only when there is an infrastructure to consider
and may be omitted in other cases. It may also be the case that the framework
is omitted in the first system development, but introduced later in order
to better support evolution and production.
Designing methods which define methods for the
future handling of the system family: methods for automatic code generation,
methods for system instantiation and methods for system evolution, see
Such methods are not needed for one-of-a-kind systems, but essential for
cost-effective product handling. An important goal of TIMe is to free resources
that traditionally has been tied up in maintenance, evolution and production
are detailed and precise descriptions of the hardware and the software
that a concrete system is made of. They define the physical construction
of systems in a family. The software part will be expressed in programming
languages such as C++ or Pascal, while the hardware part will be expressed
in a mixture of hardware description languages such as circuit diagrams,
cabinet layout diagrams and VHDL. Software plays a dual role. Firstly,
as a description to be read and understood outside the system, and secondly
as an exact prescription of behaviour to be interpreted inside the system.
Concrete systems consist
The application and the framework software.
State-of-the-art tools allow this software to be automatically derived.
Special application and framework hardware.
This will be special hardware designed to perform part of the application
or the framework.
The platform, which consists of:
the support software which
normally is a layered structure containing operating systems, middleware
for distribution support, SDL runtime systems, DBMS and interface support;
the general hardware which
normally is an network of computers.
What to do
For every new system development,
the platform is an important design issue, as it determines important properties
such as cost, reliability and flexibility. It also influences the way that
applications and frameworks are implemented.
13 illustrate some aspects of implementations. Note that the code
generated from application frameworks will interface with code coming from
different sources. To produce a concrete system these various parts of
code must be linked together and loaded on the the hardware.
Figure 13: Software implementation
Once the platform and the
code generation strategy is defined, it is possible to rely on automatic
code generation for application and framework evolution for those parts
where SDL is used. The code which is generated for the application and
the framework must be adapted somehow to the platform. Here the Vendors
of code generators use two different strategies. One is to adapt the code
generator so the generated code fits the platform. Another is to adapt
the generated code to fit different platforms by means of interface modules
It should be noted that even
if automatic code generation is used, there is likely to be some hand generated
code (e.g. for input/output drivers) and possibly legacy code from existing
solutions. It may also happen that different parts are generated using
different tools, e.g. SDL tools for the control parts and UML tools for
Consequently there are many
issues to consider, and many tool problems to solve before the implementation
activity is well defined for a new system family. However, once defined
it may be used over and over again to produce new implementations.
In the instance area of
concern, the main thing is to configurate and to build a system instance.
This can be done both on the abstract level, using SDL, in the implementation
architecture, and in the implementation. The common practice in most companies
is to do this on the implementation level using configuration files and
tools like Make. An alternative is to use special configuration languages
in this area.
System instances are what
companies sell and customers buy. The purpose of instantiation is to produce
system instances from family descriptions and instance configuration descriptions.
In the instance area of
concern, the main thing is to configurate and to build system instances.
Ideally we should perform configuration at the level where it belongs:
functionality at the application and/or framework levels, and implementation
at the architecture and/or implementation levels.
It is possible to perform
some configuration at the application and framework levels using SDL, but
due to limitations in the language, this is restricted.
The common practice in most
companies today is therefore to do configuration on the implementation
level using configuration files and tools like Make. (An alternative is
to use special configuration languages.)
We recommend that a method
for configuration and building of system instances is defined as part of
the architecture design work.
leads to the very first understanding of what this problem domain is all
about. It helps to clarify needs and to understand the real purpose of
systems in the domain. It also serves as an introduction to the other domain
A (problem) domain
statement is a concise description of the problem domain with focus on
stake holders and their needs, the essential concepts, functions and work
processes, rules and principles. It should also clearly state the nature
of the problem, i.e. what one tries to achieve.
It will normally be sufficient
to express the domain statement informally using natural language and drawings,
but one should try to be as clear and precise as possible.
The domain statement can often
be based on existing prose descriptions. There may be descriptions of earlier
systems, there may be textbooks on the subject and there may be informal
statements about the system.
The domain statement may
also contain required properties if these exist at this point of time,
but for an initial development of a new system these may be vague or non-existing.
This should be a very brief
summary with focus on the key issues. It may well be written in a style
directly suitable for market purposes. Stake holders in the domain should
immediately recognise and accept the description.
Area of concern/context
High level description of
the area of concern or the context of the domain. E.g. the interbank financial
market, the security in buildings area.
Stake holders are persons
or institutions with direct or indirect interest in the domain: companies,
users, operators, owners, etc. The various stake holders have responsibilities
and tasks to perform that give rise to needs. Therefore the domain statement
should mention every class of stake holders, their overall objectives,
needs and responsibilities. The Actors are of course important, but do
not forget other stake holders that have a more indirect interest (often
economic), e.g. managers or owners.
These are all the entities
that are manipulated, represented or controlled in the domain:
- Passive entities that need
to be represented as data, and their associations.
- Manipulated entities that
are transformed or handled in the domain; such as, materials, commodities,
- Controlled entities, such
as some machinery, that are under control by other entities in the domain.
Be sure to mention every
category of subject entities and explain their role in the domain.
These are the entities that
are used by the actors to perform services and transformation processes.
Be careful not to make the helpers too system specific. Try to capture
the general features needed irrespective of particular systems.
List all the main functions,
their purpose, which objects that collaborate and describe how they are
performed in terms of textual use cases.
Work processes and materials
If the domain contains non-trivial
transformations, describe each transformation stating its inputs, outputs
and constraints. This is particularly useful for material transformation
processes, e.g. to pick potatoes or peel scrimps.
Rules and principles
State general rules and principles
that apply to the domain as a whole or to specific parts of the domain.
If there are trends in how
the domain will develop: describe them.
Brief summary of systems
that are common to use in the domain, their strengths and weaknesses.
Problems - improvements needed
Identification of problems
or shortcomings that need to be solved.
Every domain term used
in the domain statement shall be defined in the dictionary.
Every type of actor and entity
shall be represented in the object models under the same name as in the
Every service and transformation
shall be represented in the property models under the same name as in the
No particular constraints.
Make sure the relationships
with other domain descriptions are satisfied. Make an entry in the dictionary
for every domain specific term . Important objects, classes, relationships
and properties in the domain models shall be mentioned in the statement.
To collect domain knowledge
and make a Domain statement
, and to keep the domain statement updated and in harmony with other
The source information will
normally be fragmented, informal and imprecise by e.g. not using the same
terminology or by stating the same required property twice, but with a
slight difference. It may also be unbalanced in its coverage of essential
versus not so essential information. This activity, together with the one
making the dictionary, shall transform these informal specifications to
a more precise, yet informal, specification, where the essential parts
As for the domain at large.
Making domain statement
This activity may well be
subdivided according to the topics of a domain statement, for instance
This part is best written
after the other parts of the domain statement. Consider what is the essential
message of the problem domain descriptions. Express it in a way everybody
can understand. Make it short (half a page).
area of concern/context
Try to state concisely what
the area of concern is about and what its environment is.
Ask yourself who has an interest
in this domain? Try to identify every type of stake holder/person-role
in the domain and describe their overall responsibilities and tasks. Note
down what kind of problems they have and what kind of improvements they
would consider valuable.
Try to identify all passive
entities (including the stake holders), manipulated entities and controlled
entities. Explain their roles in the domain and how they are connected
and related to each other. Do they communicate? How? Consider only entities
and associations that are relevant to some services or work processes in
Are any helpers needed to
perform the services? Try to abstract from particular system solutions
and identify the general features needed. Note that the helpers are likely
candidates for improvement. If it is very difficult to generalise, then
describe the existing helpers, and consider improvements afterwards.
List all services (functions)
needed and give a concise description of what each does. Again it it important
to abstract as much as possible from how services are implemented in existing
systems. Try to focus on what essentially needs to be done.
work processes and materials
For each material transformation,
give a concise description of what it does. What are the inputs and the
outputs? What are the sub-transformations? What are the constraints? Note
that the purpose is not to describe technical solutions, but to clarify
rules and principles
Rules that regulate the problem
domain should be referenced, as should general principles. You will have
to consult domain experts to find out about these issues. Be aware that
law may severely constrain the technical solutions that are available,
as well as it may create new business opportunities.
Important trends regarding
functionality, work processes, regulations and technology should be stated.
The purpose here is to briefly
explain the main features of existing systems with emphasis on their strong
and weak points. Consider also the competition here. This will help to
identify duty bound and success properties for new products.
problems and improvements needed
Analyse the domain described
so far and try to identify the problems with existing solutions and how
they may be improved. Interviews with domain Actors and other stake holders
will be important here.
When new insight or new requirements
leads to a modification of the domain descriptions, then the domain statement
shall be updated accordingly. This activity follows from other activities
in domain analysis or solution analysis.
Note that the domain shall
be relatively stable compared to the system solutions. It shall not be
updated so often. However, a new domain is likely to be updated more frequently
than a well established one.
of dynamic domain statement rules
Consistent domain statement
Check that the terminology is internally
consistent, using the same terms for the same entities throughout the statement.
Check that the statement is unambiguous,
that each term has only one meaning.
Maintainable domain statement
Check that the statement is maintainable.
i.e. modular and without redundancy that makes it difficult to maintain.
The objectives of a domain
are to define terminology and thereby enable precision
and efficiency through:
common use of terminology;
improved communication and coordination;
A dictionary is a reference
book listing words or terms and giving information about a particular subject
or activity (Collins 86).
A dictionary in TIMe need
not be a book, but it shall contain a list of terms with an explanation
of their meaning.
An informal Domain
statement is normally not sufficient. We will need a more precise
definition of the most important phenomena and concepts and the corresponding
terminology. We therefore improve our understanding by listing the concepts
in a dictionary. For some domains, dictionaries are readily available,
but for other areas, an important task is to define one.
A dictionary is based upon
the three aspects of concepts: designation, intention and extension. The
designation is the entry in the dictionary and the explaining text is a
description of the properties that phenomena shall have in order to belong
to this concept. The extension are all the phenomena covered by the concept.
Producing a dictionary adds
to the understanding of the subject being analysed. Furthermore, it will
help people to communicate more precisely. A dictionary helps to bridge
the gap between people with specific knowledge of the application area
and people new to the area. Later in the development the concepts in the
dictionary will often find their way into the system description as types
(of objects). We suggest that the dictionary should be maintained along
with the other permanent documents.
Be aware of the difference
between concepts and sets. A set has cardinality, and a given entity may
or may not be member of the set. A concept is not a set of phenomena, but
just a definition of the properties of the corresponding phenomena. This
should be reflected in the wording of the dictionary - the reason is that
the domain may have real sets.
Domain dictionary content
The dictionary may simply
be an alphabetic list of terms with informal explanation. All terms used
in the problem domain should be included, such as :
- terms for phenomena and concepts;
- terms for entities;
- terms for properties;
- terms for services;
- terms for relationships;
- terms for connections and interfaces;
- terms for processes;
- terms for roles in particular
human roles like users, operators etc.;
- terms for materials.
There is a more or less
direct road from a dictionary to an object model. Concepts are represented
by classes: the name of the class corresponds to the designation and the
class definition to the intention of the concept. objects according to
the class represent the extension. Therefore the names used for object
types shall be the same as the name used for the corresponding concept
in the dictionary.
The domain given terminology
used in Families shall be the same as in the domain dictionary. It is possible
to define additional terminology in separate Family dictionaries.
Ensure that the relationships
with the other domain Descriptions are maintained. See Relationships
Ensure that the general
domain terminology is applied in the Families. If family specific Dictionaries
are developed, they should refer to the domain dictionary for all domain
given terminology and avoid redundant definitions (which may develop into
of static domain dictionary rules
Domain dictionary entries
Represent each essential problem domain phenomena
and concept by an entry in the dictionary.
For entries in the dictionary that correspond
to concepts that will be represented directly by types (classes), it may
be a good idea (if this is known) to use the same name on the type as the
designation of the concepts.
Update d domain dictionary
Keep the dictionary updated throughout the
development. If desired classify the entries as coming from analysis or
design, domain, environment or system. This may help in updating the dictionary
and also to answer questions like "Is this phenomenon covered by the domain
of the system?" or "Is this type of entity handled by the system?"
Domain specialisation hierarchies
For each concept in the dictionary (and the
corresponding Developing domain object models), ask whether all the objects
that fall within the extension of the concept/class have the same properties.
If they have not, find specialisations, which may or may not extend the
dictionary. During the specialisation, extend the description in the dictionary
with properties which add to the understanding of the concept.
Developing domain dictionary
The activity makes an entry
in the dictionary for each term in problem domain.
In general, the dictionary
comes from the other domain Descriptions, as its purpose is to define the
terminology used there. Thus, the dictionary is developed more as a spin-off
from making the other descriptions, than as an independent activity.
When object models and property
models are developed, the dictionary should cover all the objects/types,
associations and properties represented in those models.
Same as for domain Analysis
The dictionary is made for
the first time as part of the first domain analysis, see: Making
The first dictionary comes
from a (prose) Domain
statement. By studying the nouns in the Domain
statement we can make the initial dictionary. But the dictionary
shall contain more than the nouns, it shall also include services or functions
and associations which may be visible in the domain statement as verbs.
A practical approach is to
analyse the text of the domain statement and mark every term that refer
to a domain specific concept or phenomena.
For each term thus marked,
make an entry in the dictionary which define the term.
- should the dictionary
be organised in some way? e.g. according to the domain statement categories,
according to the kind of entity (concept, property, entity, relationship,
- should the dictionary
contain references to object models and property models?
The dictionary is evolved
as part of the evolution of domain Descriptions, see Evolving
domain descriptions. Changes may be due to evolution of the domain
statement as well as the domain models. Whenever existing terms are modified
or new terms are introduced in any of the other domain Descriptions, the
dictionary should follow up.
of dynamic domain dictionary rules
Finding domain dictionary entries
Develop the dictionary as a consequence of
other domain descriptions.
Use the dictionary actively as a source of
terminology when making the other domain descriptions.
Do not add new terms to any model without
checking that there is no appropriate term in the dictionary already.
Analyse each entry checking that it is precisely
and unambiguously defined. Look for similarities among entries. Avoid to
use the same term for different things, and to use different terms for
the same thing. If necessary define synonyms explicitly. Clarify relationships
between related entries, e.g. subtype relationships.
The purposes of domain models
To describe formally how objects and properties
in the domain
To define generic types that may be used in many
system families and system instances serving the domain.
Figure 14: Domain Models
Domain models will mostly
be application abstractions. But the possibility to model more concrete
aspects (e.g. infrastructure and platform) will not be excluded. It may
for instance be useful to model various technical solutions which are common
for the problem domain. It is perfectly relevant to make more concrete
object models whenever there are concrete matters in the domain needing
to be described, e.g. physical materials, concrete interfaces. Implementations
are not part of domain models.
Figure 15: Domain model
Domain object models serve:
To improve understanding and communication by
rigorously describing how concepts and objects in the domain are related.
To give a more precise meaning to terms in the
To clarify the basic needs existing in the domain.
To promote reuse by describing objects and classes
that are common to most systems in the domain.
Figure 16: Domain Object
It defines types which
represent concepts in the problem domain, and objects which represent phenomena
in the problem domain. It defines the attributes, the operations and the
behaviour of objects as well as associations and communication links between
objects. It shall be complemented by Domain
Domain object models will
objects as well as passive
Active and passive objects
Objects of the real world
are by nature active. They interact with other objects and have a dynamic
behaviour. When we consider the domain as a part of the real world, all
objects are potentially active. However, we do not need to model them all
as active objects in the domain models. Some may be active, some may be
passive and some may be both. This is a decision we make in the models.
At some stage we must decide
the level of detail and the kind of behaviour we will specify for each
object type. For active objects, we specify a "real" behaviour, whereas
for passive objects we specify a "data" behaviour which is very different
from the "real" behaviour. Considered as an active object an AccessPoint
in the Access Control domain have a reactive behaviour that interact with
real users. As a passive object, represented in the validation database,
is has a simpler behaviour that responds to validation queries.
Normally there will be only
one active object representation of a domain entity, but there may be several
passive object representations. The behaviour, the attributes and the context
may be very different in each case. Therefore we may need to develop one
active and several passive component models representing the same domain
The advantage of the object
models over prose descriptions are that they show the relationships between
objects in a rigorous way, and that they use a graphical notation.
The domain object model is
not only made in order to get a better understanding of the domain. It
is also made to identify types that are common to all systems in the domain.
It is a goal to describe at least every object type that will be part of
the domain given parts of systems and system environments. It may be difficult
to find all of those without considering any system. It will normally help
to study existing systems, and also to work on the new system design. Consequently,
when complete, the domain object models will be influenced by existing
systems as well as the design of new ones.
However domain object models
may well include more objects than those that will eventually be in systems
or system environments. They should also describe related objects that
are important for the purpose of systems in the domain.
Components for reuse are
supposed to be identified in this activity, and correspondingly components
identified in earlier domain object models are used here. Classes of objects
that are identified as belonging to the problem domain will have more chances
for being reused in other systems than classes being made in the design
of a specific system. Types (classes) identified in the domain object model
are therefore supposed to be made as general as possible, and there may
even be sub-activities that have this as their main purposes: to prepare
for reuse. Apart from this, TIMe believes in the fact that reuse comes
after a successful first use.
Since the domain
as we consider it, is a generalisation it may be modelled as a type (in
SDL) or a class (in UML). It will normally contain components that
are defined with reference to other types (SDL) or classes (UML), see
of object models.
In most cases these component types are more
useful than the domain model itself.
There are several reasons
In many cases the domain is not well defined
enough or contains too much variability to capture in a single model. A
collection of component types is less restrictive and more flexible. They
provide more information than can be said in a single model.
Within the domain there will be many different
views that we need to understand and reconcile, e.g. the views of different
actors. Component types offer a formal way to describe the relative views
of each component type through its context expressions.
Reuse will be in terms of component types and
not complete domain models.
For this reason we recommend
the following rule
Make component type models
Make a type model showing the context and
content of each actor, helper and subject entity.
In order to get a better
overview, one should try to put the components together in complete or
partial domain models where possible. A useful compromise may be to develop
several viewpoint models.
Consequently, domain object
models will normally contain two main parts:
Domain structures which give a structural
overview of the domain representing all objects, connections and associations.
It may be a single model, or it may be composed from several viewpoint
models. In the case of a single model, the entire domain is viewed from
the same angle (somewhere "above" the domain), see Figure
17. In the case of viewpoint models the domain is seen from different
angles (from some "side"). Viewpoint models may be simpler to make since
they may discard aspects that are not relevant from that angle. At the
same they allow us to make the differences between different viewpoints
more clear. UML supports veiwpoints by using Packages, while UML supports
viewpoints through the Module concept.
Component type models which define
each component type (class) separately with context and associated properties.
These models serve to give the relative views that each component type
has on the domain, see Figure
Figure 17: The access
Figure 18: The class
definition of Access Zone
Domain object modelling belongs
to a subset of more general
models can be described using either
or SDL, depending on whether they are domain or design object models and depending
on the formality needed.
object model languages and notations
Object models are expressed
It should be noted that UML is made primarily for passive objects,
while SDL are for active objects. For purely passive objects, pure UML
Domain object notations
Make separate object
models for active and passive objects?
domain object models
Domain object models are
abstract models unless otherwise stated. They are abstract in two senses:
they model the world without considering the
physical details of entities;
they model parts that will be realised in systems
without going into system specific detail.
The abstract models will
normally concentrate on the application abstraction, and only consider
infrastructure in special cases where the infrastructure is general for
the domain. Frameworks are normally not considered as they belong to the
At this level we find the
bulk of domain object models. Every actor, helper and subject entity should
be represented in a component model.
In addition the domain structure
may be represented in a number of viewpoint models or in a single model.
This level will consist
of component models for infrastructure components that are common to the
entire domain. System and family specific components should not be included.
Make component type models
Make a type model showing the context and
content of each actor, helper and subject entity.
Concrete domain object models
At this level we find models
for platform components that are general for the entire domain.
models at this level are
only made if the domain is about platforms, or if the platform is standard
for the domain.
Every object type shall be mentioned in the
dictionary under the same name.
Every object type shall have associated property
Object models refer to properties through service
names and role names.
The association between objects and properties
are maintained through service names and role names.
The functional properties specified for an object
shall be satisfied by the object behaviour, i.e. be a proper and valid
The behaviour of every object type shall be
strongly input consistent in every role.
Every object instance shall be valid in all
Domain given design objects shall be related
to domain object through inheritance or implementation relations.
Harmonising domain object models
In this case the domain object
model is harmonised within the domain and with design.
Ensure that the rules for
domain internal relationships are correctly maintained:
Every type name shall be defined in the dictionary.
Every object type shall have associated property
Ensure that the rules for
Design relationships are correctly maintained:
Every domain given object in design shall be
related to an object type in the domain object models. The relationship
shall either be pure inheritance or an implementation relation.
Summary of static domain object model rules
Use the general rules for
object modelling and the following special rules:
Make component type models
Make a type model showing the context and
content of each actor, helper and subject entity.
Domain object notations
Domain property models
To improve understanding
and communication about the domain by rigorously describing the properties
applying to domain objects, services and interfaces.
Domain property models
are used to describe the problem domain from the property
perspective. It includes functional and non-functional properties.
Functional properties are
considered as projections of object behaviour, and described using text,
role structures and MSC, see Figure
Text is used to give a textual
explanation of a service or interface. Role structures are UML instance
diagrams that represents the roles of the service or the interface. The
objects in role structure diagrams can be considered as anonymous objects.
They will be related to object model objects by role association links,
and to the instances in the service MSCs through the same name.
When the system is designed,
the domain property models will also be valid property models of the corresponding
(domain specific) system objects. Properties belonging to the domain will
be candidates for properties of several system in the domain.
It is an implicit assumption
that models of the domain will not cover design dependent properties. Such
properties will be added in design models. However, the domain may well
cover concrete properties as long as they are general for the domain and
not specific to particular systems or families. Domain properties shall
be related to domain objects if they can, but it is allowed to describe
properties without reference to objects. One example is roles where the
actor objects are unknown or irrelevant in the domain. Another example
is general properties applying to the domain at large. property descriptions
will typically be quite fragmented.
Services: Text, role structure
diagram and UseCases in MSC.
Interfaces: Text, Role structure
diagram and Use Cases in MSC.
General properties: safety,
liveness, user friendliness etc.
Services: as above.
Interfaces: as above.
General properties: as above.
Make property models that are as self contained
and independent of
other properties as possible.
Motivation: to enable property (service) flexibility through modular
General constraints and
requirements that are common to the domain:
reliability, safety, modularity,
performance, size, technology.
About general properties
of the environment, materials, processes, etc.
Every service shall be mentioned in the dictionary.
The MSC instances shall represent either service
roles or interface roles.
Object models shall refer to properties through
service names and role names.
Interfaces of domain given design objects shall
be an implementation of the corresponding domain interfaces.
Services of domain given design objects shall
be implementations of the corresponding domain services.
domain property models
Ensure that every service
mentioned in the dictionary and statement has an entry in the service lists
and corresponding MSCs.
of static domain property model rules
Make property models that are as self contained
and independent of other properties
Motivation: to enable property (service) flexibility through modular
The goal is to make domain
object models and domain property models and to keep them aligned and in
harmony with other descriptions.
Figure 19: Developing domain
The main inputs are domain
knowledge that come from people, and general domain knowledge that can
be found in the literature. The domain statement and the domain dictionary
give important input too. When a system family has been defined, it may
influence the domain models. The outputs are the domain object models and
the domain property models.
This activity is composed
from two sub-activities:
of static domain model rules
Switch between object modelling and property
modelling, as each of these activities may contribute to the other. Object
modelling and property modelling go hand in hand.
Developing domain object models
to make and evolve Domain
to analyse the models looking for improvements;
to keep the models updated and in harmony with
This activity produces
a (set of) Developing
domain object models
, some of which may be adaptations
of existing object models (which will be the normal case during evolution
The main inputs to this activity
are existing domain object models (if any) the Domain
statement and the Domain
dictionary supplemented by domain knowledge and the Domain
property models. It is also influenced by existing systems and
the design of new ones.
As explained in Domain
object models, it is possible to model the domain as a single
structure, but we recommend to develop viewpoint models and component type
models as well. In a single domain structure it is not so easy to distinguish
between active and passive objects. Therefore we may start to develop the
domain structure without considering whether objects are active or passive.
In viewpoint models we are more likely to see differences, and in the component
models we must be clear about it. The following guidelines help to identify
active and passive objects:
Active and passive domain objects
Use connections primarily to link active
objects. Therefore objects with connections attached will be active.
Use relations/associations primarily for
constructive relations. Therefore objects participating in relations/associations
are likely to be represented by passive objects.
It follows that objects with both connections
and relations will have both an active and a passive representations in
As an example consider
the user of the Access control system, see Figure
"The access control domain". The model indicates that there will
be two user concepts: active users seeking services, and passive users
representing those that are valid users in the domain.
What to do?
In this case we have no existing
object model or property model, only a first domain statement and a domain
dictionary. The task is to develop the first domain object model.
In all steps above, variability,
generalisation and specialisation should be considered.
Using this strategy it is
natural to develop two models, an active object model and a passive (information)
object model. Here the active model will map to active (domain given) objects
in the systems while the passive will map to known entities represented
by passive (domain given) objects in the systems.
An alternative is to combine
active and passive objects in the same models.
In this case an existing
domain object model is evolved to take new domain knowledge or requirements
into account. Inputs are the existing models and knowledge about the changes
to be made. The reasons for change are either:
an extension of the domain;
some new services to be added;
a restructuring due to better insight;
some major changes in the system technology
(such as replacing mechanical keys by magnetic cards).
Note that updates due to
system design normally is handled in the harmonising activities.
of dynamic domain object model rules
Domain object modelling approach
Take the entities that a system must know
about and possibly control as starting points for classes of objects.
If working with the domain alone is too abstract,
consider in stead systems in the domain and try to generalises from them.
Classes of objects may very well be identified
in a process where the required properties of a system are analysed. These
preferably involving people representing the users and people being responsible
for the required properties.
Switch between identifying attributes and
relations between classes of objects, as it may be a matter of choice if
a property is a relation or just an attribute.
Make component models
Take each of the classes and make a model
that includes the most important classes of objects in the environment
of this class. Identify the constraints on the classes stemming from this
Using domain object notation
For parts where the system Design object
model is to be specified in SDL, the properties of SDL should be taken
Examples: As it is known that SDL has single inheritance, it would
be a bad idea to make a domain object model in UMLwith extensive use
of multiple inheritance. SDL has a strong notion of real aggregation that
depends upon which kind of objects to aggregate (services as part of processes,
blocks/processes as part of blocks) - if aggregation is part of the domain
object model it should take this into consideration.
Domain object modelling
is a special kind of object modelling. In addition to the general guidelines
; the following special guidelines
Object classes with
relations and connections
If attributes are not known, just introduce the class. Include any
relation or communication link that may be important - in the design activity
these will be refined and detailed (or thrown away). Do not use too much
time on signals on communication links, unless they are given from the
Communication connections between classes indicates that there will
be Interaction models between instances of these. For each of the communication
connections check if this is important enough to call for Interaction models.
Do not be afraid to use illustrative relations, but be aware that
they may have to be "implemented" during design.
If the type of an attribute is not known, simply introduce the attribute
without any type, or introduce the attribute type as a class - this will
then be defined during design.
Use only real aggregation when it is obvious that this is the case.
If in doubt, use relation aggregation, as this the most flexible.
Classes with constraints on the environment
the object model
This will mostly be in terms of Interaction models by use of MSC.
If state information is important for the behaviour of an object, sketch
an SDL process graph fragment for this part of the behaviour.
Do not consider this unless it is quite obvious. In case SDL is
used for domain object modelling it will produce a set of packages of type
definitions. These will mostly be independent of actual context. If domain
modelling go so far as defining system and block types, then apply the
general rules of localisation.
Developing domain property models
To make domain property models.
To analyse the property models seeking to identify
problems and find possible improvements in the domain (and thus in systems).
To keep the property models updated and in harmony
with other descriptions.
This activity produces
the Domain property models
, including only properties of entities visible in the Domain
Functional Properties that can be expressed as
Use Cases by means of function lists and MSC are considered the most important,
but Non-Functional Properties are also considered when they are part of
the domain. A speciality of TIMe is that objects in the domain object model
are not just passive "data objects" - they may also be active objects.
If such active objects are identified in the analysis of the domain, then
an analysis of their properties also belong here.
Who to involve
The people to involve are
the same as for domain analysis in general. However, in order to get the
service properties right, it is important to consult actors in the domain,
and in particular those that may become users of the systems.
What to do
Consider each of the active
object types in all their different roles and describe, by means of role
structures, text and MSC, what they need to do or need others to do for
them. For each service, identify the roles or actors involved in role structures,
and describe the collaborations using MSC.
Be sure to cover all general
tasks where systems in the domain are involved. Consider also work situations
and tasks to be achieved by means of the systems, i.e. consider a wider
context of purposes than the systems in question.
As part of the Developing
domain models activity this activity runs in parallel with Making
domain object models.
The main inputs are the domain
statement and the domain dictionary together with the object model developed
so far and general domain and system knowledge.
In this case the starting
point is existing domain models and some requirements for new or modified
properties. TIMe seeks to support property flexibility by promoting modular
property models. However, undesirable interactions may occur between properties
and they should be detected and resolved.
of dynamic domain property model rules
Domain property modelling approach
Use the domain statement as starting point
and consider the needs of all stakeholders.
Use the domain object model as starting point,
and consider especially objects that are connected by communication links.
Make a Service List stating all the services
(or functions) that needs to be performed and possibly may be supported
by systems in the domain. Explain what each service does.
For each service, identify the object roles
involved and as far as possible, which objects are the actors of the roles.
For each service, describe the most important
Use Cases using MSC. Apply the guidelines of the MSC methodology.
the MSC guidelines for the MSC part: see How to use MSC-92 effectively.
Follow the rule for MSC
Rule for MSC usage
Identify all initiatives. For every initiative;
describe the sequences that may follow until the next initiative. Use one
MSC for each alternative .
Domain behaviour properties
Describe abstract (behaviour) properties
in a way that eases composition into object behaviours and comparison with
Motivation: ease of synthesis, quality by construction, ease of
validation and verification.
Domain non-functional properties
Identify concrete (non-functional) properties
that are relevant for the domain models, i.e. properties that any concrete
system must abide.
If the system design is considered, look especially
for properties that are inherent in the domain and describe them in a general
If the system is considered, then it is preferably
considered as one object, and it is only decomposed if this helps in identifying
properties of the domain objects.