Content and scope

The application provides the main services of a system and is therefore the most valuable part of a system from a user point of view. Application models are very central in TIMe:

In this Chapter we shall describe:

Application reference model

It is abstract

The application is an abstract system which provides the services that users and other systems in the environment need. It determines the quality of the system services.

As an open systems it exists in a context where it attain purpose and meaning from an environment. This context may again be part of an even wider context, such as an enterprise, where the system and its environment together serve some higher purposes.

The domain is a generalisation of this wider (enterprise) context. In contrast to the domain, the system context is a part of the world being served by a system. The domain is a more general and often wider area of concern.

In the reference model for application systems we consider the system and its environment, see Figure 21. Both the system and the environment are decomposed into Domain given, System given and Interface given parts:

Figure 21: Application system reference model


These parts may have quite different characteristics and contribute to the overall functionality in different ways. Note that the services are related to the domain given and the system given parts, while the interface given parts only serve as communication media. Interfaces have been separated from services in order to achieve protocol transparency and modularity. It is generally desirable that services can work over a range of communication facilities and that interfaces and services can evolve as independently as possible.

The Environment is further decomposed into:

Since the system shall serve the environment, we will find corresponding entities within the system. In fact, TIMe recommends to "mirror" the environment by objects inside the system. Some of these will be active object and some will be passive objects, see Object Models. The active objects provide services, while the passive represent entities and relationships the system needs to know.

The application system reference model has been inspired by the OOA&D method (Mathiassen et al. 1993), but adopted and detailed to suit reactive real-time systems. Methods like object modelling with UML do not have this kind of system reference model.

We believe the reference model will help to structure system models and to give more precise method guideance.

System context


A system context is a part of the world containing the system itself and its Environment. Thus, Figure 21 illustrates a system context.


Note that:

Domain given


Parts that are modelled in the domain and therefore common to most systems in a domain are classified as domain given parts. The domain given parts of the environment contain domain entities that are served by the system, typically actors and processes, and subject entities known by the system. The domain given parts of the system itself contain domain entities that are realised by the system, typically some domain Helpers. They also contain passive objects representing domain given entities of the environment.


The users and the Access Zones of the Access Control system are examples.


Domain services will be quite general and common to most systems in a given domain. Every PBX, for instance, is able to provide normal two-party telephone calls. Any access control system will know about users and access rights. Such parts are likely to be stable and may potentially be reused in many systems and system families. This is one reason to separate these parts from the more system specific parts.

In methods like object modelling in UML or OOA&D the emphasis is on passive objects representing knowledge about phenomena in the problem domain. In our method, we also include active objects that perform services.

System given


The system given parts are specific to a particular system or system family. They will act together with domain given parts to provide the services.


In the Access Control system the operators and the objects serving the operators is an example. Another example is the error handling and initialisation functionality needed in most systems.


These parts provide the services that makes this particular system, or system family, different from other systems in the problem domain. The System given parts can collaborate with the Domain given parts of the system to accomplish the services. They are separated from the Domain given parts because they are less stable, general and reusable. The purpose of these parts may be to:

Interface given


The interface given parts take care of the communication between the service needing parts in the environment and the service providing parts in the system.


Communication require interfaces. In some cases the interface is simple: just hit a button. In other cases it involves complex behaviour, such as protocols and graphic user interfaces. In most cases there is independence between the interfaces and the service provided through the interfaces. It is therefore recommended to isolate what is specific to an interface from the services provided over it. This is particularly true where there is a complex behaviour associated with the interface.

Such separation allows interfaces and services to evolve independently and help to protect investment in either area from changes in the other.


The interface specific parts are subdivided into:


Common to all these parts is the Layering Principle. All interfaces will be layer structured, starting with the physical medium moving upwards to the services in the System given and Interface given parts of the system.


In the AC system we have a user interface with a physical layer: the Panel, and a protocol layer: PanelControl.


The environment consists of the parts of the surrounding world which are either known to the system or communicate with it.

Subject entities


Most systems will contain data representing entities, relationships and measures external to themselves. The actual entities, relationships and measures represented by such data are denoted collectively as known entities. The known entities can be seen as the meaning (semantics) of the data. Subject entities are known entities that a system does not interact with directly.


A salary system, for instance, needs to know about employees, but will normally not interact with them, hence the employees are subject entities.

Subject entities will often be domain given.

Other systems


Other systems are external technical systems with which the system in question is communicating to accomplish its purpose.


A PBX for instance, will communicate with nodes in the public telephone network. An ATM machine will communicate with the central bank computers.


Many systems will communicate with external systems. In some cases the relationship will be asymmetric, as in a client server architecture. In other cases it will be symmetric as between the switching nodes in a communication network. Anyhow, the relationship with other systems may be central to the purpose of the system in question. Sometimes the system even receives its prime purpose from external systems.

Other systems are sometimes domain given and sometimes System given.

Controlled processes


The controlled processes are equipment in a surrounding technical system being directly controlled by the system in question.


In the Access Control system, the Doors are controlled processes. In an ATM machine, the money-bin is a controlled process. In a lift control system, the physical hoist unit and the lift chair are controlled processes.


Controlled processes will only be present in embedded systems, where the application system is controlling a larger technical system, e.g. a paper mill, a telephone exchange or a robot. Normally this larger technical system will rely on the application system to behave as required. This is typically the case in so-called mechatronic systems, where software, hardware and mechanical solutions are integrated. A mechatronic system will comprise active parts which exercise control and passive parts being controlled.

System boundary

It is a matter of definition where to put the system boundary, and hence what to consider as part of the system in question and what to consider as controlled by the system. If we consider a complete lift system, the physical hoist unit containing motors, brakes, wires, etc. will be considered as part of the system. If we consider only the lift control system, then these parts are considered as controlled by the system.

The controlled processes will often be domain given.



Users is the term collectively used for human beings interacting with the system in question. They may play a variety of roles such as operators, service personnel or clients. domain actors supported by the system will be domain given, while others will be system given.

Application models

Application model overview


First of all, application models serve three basic purposes:

The purpose of the application models in general is to answer what systems in the family shall do.

They should support unambiguous communication among project members and in-depth understanding by the individual. An application model is made primarily for human communication and analysis, not for machines. But it should also be processed by machines.

It should be readable for the human being without being vague or ambiguous and it should express the behaviour without unwanted bias towards the physical implementation in order to allow freedom in selecting the implementation.

At the same time it should be implementable so it can be trusted as documentation. In fact, we will generate code automatically from application models.

Once application models serve these purposes and we are able to actually engineer systems on the application level, some secondary purposes emerge. We want to further reduce lead times and to introduce new services more quickly than before. Therefore we want application models to be:

To achieve all these objectives, application models should be structured with the following criteria in mind:


As illustrated in Figure 22, the complete application system may be defined as a type. This will be a natural thing to do during the first time development. However, once a framework has been defined, the complete application system may become less important, because it is the component types and not the complete application system, that will be used in frameworks. Therefore the component types used to construct the application system may be more important than the system itself.

This observation is strengthened by the fact that it may be difficult to express all the variability needed formally in one type model. It may prove more practical to develop several component types that are easy to compose into alternative system types. Thus, the most important part of application models is a library of (component) types that can be used to define application systems using either composition or inheritance.

Application model content

Application specification and design parts

As all other family models, application models have two main parts: the specification part (see Application specification) and the design part (see Application design). Each part consists of object models and property models as illustrated in Figure 22:

Figure 22: Application specification and design


  1. The specification focuses on the environment and how it relates to the entity being defined. In the object model, the entity itself is represented as a black box while the environment is detailed. Associated property models will focus on interactions between the entity and the environment. Every service it provides shall be described by means of roles, text and MSC.
  2. The design focuses on the content. In the design object models we will see how the application system is composed from parts and also how these parts behave. In the property models we will see how design objects interact. It is of course, essential that the properties actually provided by the design objects correspond to those required in the specification. (A combination of property conserving synthesis and verification techniques is used to ensure that.) The object model design consists of two parts:

    structure design which define the structure of objects and component aggregates;

    behaviour design that define the behaviour of objects.

Application system boundary

What should be inside and what should be outside the system is a question that often causes high tempered and endless discussions. We contend that the decision is not very crucial, as the method we propose will allow the boundary to be adjusted later on with little effort.

The important thing is to include either in the environment or in the system itself everything the system ultimately will serve or know. In particular it is important to represent all the various stake-holders needing to be served or represented by the system. These should be placed in the environment. Other objects we are sure never will be produced or delivered as part of a system instance, e.g. people, should be put in the environment. This does not exclude the possibility of including some of these in the system at a later stage, for instance as part of a simulator.

Application services and objects

The services of a system are defined in application property models. As in the domain, the application service models contain a textual explanation, a role structure and an MSC document.

In general, an object is assigned properties in the following three ways, see Figure 23:

Figure 23: Ways that services are related to objects


  1. By explicit assignment of service roles using the Plays service role relation. This is because the object is part of an object type to which we explicitly assign property models.
  2. By implicit assignment of service roles from the object type it is an instance of. This is because objects are instances of types that may have explicitly assigned roles.
  3. By implicit assignment of interface roles required by objects in its environment. This is because the object appears in an environment where surrounding objects will expect the object to behave according to some interface.

Of course, all the roles that an object receives must somehow be consistent with each other and with the properties that the object actually provides.

Therefore, care must be taken to maintain consistency between the properties specified explicitly for the system as a whole and those received implicitly from its components and the environment.

Role sets

The application reference model parts

Domain given

Application models are closely related to the domain and the needs of domain stake holders. We are likely to find some of the domain actors in the system environment (those that the system will support), and some domain helpers inside the system (in the domain given part).

System given

A system family may have many features that were not covered in the domain models, e.g.:

We recommend to model the System given parts in the same general way as the domain given, except that the System given parts originate outside the domain and have no relations to domain models (except in cases where they lead to new understanding of the domain).

Interface given

It is recommended to distinguish between the service behaviour and the interface behaviour by using layering as illustrated in Figure 24.

Figure 24: A service layer and an interface layer

Further we recommend to first define the service behaviour separately without any reference to interface given parts. This means to consider only the two service roles xr1 and xr2 and their dashed interconnection in Figure 24. When interfaces are introduced, the services shall ideally behave in the same way even though the interconnections go via the interfaces and the dashed interconnection in Figure 24 disappears.

(It may happen that interfaces interact with the services in ways that were not anticipated in the service models, for instance that messages may be lost. In such cases the service behaviour must be modified to take the interaction into account.)

Figure 25 illustrates how services and service objects may relate to the interface given parts. Where to place interfaces in relation to the system boundary, and how to model them is often a difficult choice.

Figure 25: Two cases of interface given parts


In the User terminal case, we have placed the Terminal in the environment and a Terminal server inside the system. Note that the User will play both a service role and an interface role in this case. Since these roles are internal to the User object, the service interactions S1, S2,. are not visible outside the User. Inside the system however, the roles are played by two different objects, and therefore the service interactions are visible there. In the Ext system case, the interface given parts are Protocols belonging to the two systems.

Application languages and notations

As illustrated in Figure 22, the main languages to use are MSC for property models and UML combined with SDL for object models.

SDL is the main language for control behaviour, while UML will be used for other aspects (such as user interfaces and data-bases). Typically UML will be used in the specification part, and possibly for top level design structuring. SDL will take over where the main thing is to model reactive behaviour.

In some cases it will be possible to express the application object models completely in SDL.

For description of interaction properties, we stick to MSC even if UML is used for the Object Model.

Application specification languages and notations

Normally UML will be used for the specification object models:

Application specification notation

For property models, text, role structures expressed in UML and MSC will be used.

Using SDL in application specifications

If SDL is used, we recommend to model the application system as an SDL Block type rather than as a System type. There are two main reasons for this:

  1. It is possible to formally describe the environment of Block types but not of System types.
  2. Block types can be used as components while System types cannot.
  3. Where reactive behaviour is important and general relations (associations in UML) are unimportant, SDL should be used in the specification:

    Context: model the application system as a Block Type in SDL. Represent the environment as gate constraints.

    Content: model the content (if any) as Block sets.

    Components: define a Block or process type for each component in the system or the environment. For each type, define the type context.

  4. Associate the roles of property models with the objects and types/classes of object models.

Application design languages and notations

For reactive, state transition behaviour it is recommended to use SDL. This means that active objects in general should be described with SDL. One exception is graphical user interfaces. For passive objects, and especially objects going into a database, UML may be preferred.

This means that the application design may use a combination of SDL and UML.

Application design notation

Of course this division may cause interworking problems between the SDL and UML parts.

Application specification


An application specification serves to answer fundamental questions like:

  1. What services are provided?
  2. What is the environment i terms of active and passive objects?
  3. 3. What is variable in the environment and the services?

It specify the external interfaces and behaviour properties (services) of an application.


The application specification models are illustrated in Figure 26

Figure 26: Application system specifications

Specifications are developed first for the application system as a whole and later for each (component) type. We distinguish between domain given, System given and Interface given parts. It is natural to use this division as a guideline in the specification:

Domain given types will be quite stable, and may be reused between many systems and system families. System given types are less stable as they provide the functionality that is particular for a system or system family. Among the interface given types, user interfaces can be the least stable. Protocols, on the other hand, may be quite stable.

Application specification content

Domain given specification

One key issue in any system development is to decide on what parts of a domain to support. (This is true even if there are no explicit domain models.) Basically this means to decide on which domain actors and which domain services to support. These shall be represented in the specification as follows:

Domain given specification

As a result we have a subset of the specification object model representing the domain given parts. Inside the system (in the content) we only find domain objects (Helpers) that are going to be realized by the system. In the environment we find the domain objects that are going to be supported (if they are active) or represented (if they are passive) by the system.

In this way there will be a separate service description (using role structures, text and MSC diagrams) for each domain given service. Interaction with System given service roles should be shown but interface given roles should be avoided.

System given specification

We do not include System given objects inside the system in the specifications unless there are good reasons for it. We recommend to focus on the environment, and avoid specifying content.

Again we recommend to separate services from interfaces.

In an enterprise view, consider stake holders and other entities that need to interact with or be represented by the system.

System given specifications

As a result, we have a detailed description of the environment and the communication links with the system. Each service has a separate description, and we know which service roles that are going to be played by the system itself and by the objects in its environment.

Interface given specification

Specifications will often be quite detailed about interface given parts. Interface given parts will be localised somewhere on the communication links between the system and the environment where their role is to convey the service interactions.

Interfaces will often have a layered structure with one or more protocol layers on top of a physical layer.

Interface given specifications

Application design


To describe the design part of an application that:


The context part of an application is fully covered in the specification. The design part adds the content which is not covered in the specification. It defines the content structure in terms of objects, and the behaviour of each object type.

The first purpose of an application design model is to describe the system behaviour at an abstraction level, where it can be understood and analyzed independently of a particular implementation. This is done in terms of both an object and a property model.

The second purpose is to be a firm foundation for designing an optimum implementation satisfying both the functional and non-functional requirements.

Object behaviours are central to the application, and the design should primarily be structured to give clear and concise behaviour models. We contend that behaviour should be described state oriented, see General application guidelines. To achieve that, the structure should contain one object for each independent (concurrent) thread of behaviour in the system. These objects may be then aggregated in various ways to suit additional purposes.

It is recommended to make a library of component types that can be used in a range of application systems to cover the full variability needed. Some of these will be real aggregates containing a structure of components, and others will be object types with behaviour. The component types designed with SDL will be organised in Packages. (Packages are used only for types that are general enough to qualify for being part of a package. It is, however, possible to start with collecting the types being used in a specific system in a set of packages.)

Application design content

Application design models consists of:

  1. The application modeled as a structure type. It is a type definition with context and content that define the overall structure of the application system and may use several levels of real aggregation. It will be constructed using a collection of component types and refer to the definition of these component types for further detail. The content structuring is primarily concerned with active objects and interconnections. However, the active objects will contain passive objects and conceptual relations.
  2. The component types which are either:

    structure types that consist of object aggregates, defining the content as a structure of components, or

    behaviour types, i.e. object types having a behaviour of their own, e.g. SDL processes. There will be both active object s and passive objects as well as association between active objects and passive objects, i.e. which active objects that access and may change the passive objects representing known entities in the context. (For SDL, the passive objects will be variables contained in processes)

  3. 3. Property models for the overall content. The application content shall satisfy the specified context properties.

Each type is defined with a context and a content with associated properties. An object type definition consists of:


Application model relationships

How the application is related to the domain and the Framework is illustrated in Figure 27.

Figure 27: External Application relationships


Relationships application - domain

We recommend that each domain given object has a type, with a context description. (Each of these types will correspond to one of the component types that we recommended to make in the Domain object models) In this way the relations to the domain go via the types.

The nature of these relationship may vary from plain equality (when domain objects can be used as-is) through inheritance (when the application objects are extensions of the domain objects) to informal similarity (when the domain objects are just used as inspirations for the application objects).

Domain relationships can thus be either Identity, Inheritance or Inspires where Identity and Inheritance can be expressed in the object modelling languages, while Inspires must be added as annotations. In Figure 27 we have only indicated the weakest relationship "inspires".

Ideally the domain given types should be identical to the domain types. Any difference shall be due to system given or interface given aspects. As far as possible we seek to isolate these aspects, but it cannot be avoided that the domain given objects are influenced:

Consequently, the domain given behaviour properties will be a refinement of the corresponding domain properties.

Application domain relationship

Domain communication

Harmonising application - domain

Only the domain given parts need to be considered. When these parts differ from the corresponding domain models, the difference should be caused by System or Interface given aspects. If they are not, it is likely that the difference is accidental and should be removed, either by changing the domain model or the application model. (It is not uncommon that working with the application helps to improve the understanding of the domain.)

Application domain harmonisation

Relationships application - framework

Frameworks are composed from an infrastructure part, that come from the implementation architecture, and a redefinable application part, that come from the application. Objects in the application part (of the framework) are formally related to Objects in the application by using the same types. However, the application part of the framework may be structured somewhat differently from the application. This means that the application types need to be designed so they can be distributed in the framework and communicate transparently with each other and the environment. It also means that they must be adapted to the operation and maintenance services provided in the framework, e.g. the methods for dynamic system configuration.

Application framework relationship

Harmonising application - framework

Application types are developed and maintained as part of the application, and used in frameworks to produce executable systems. It is not necessary to develop a complete application system each time a new executable system is to be produced. It is sufficient that the necessary (component) types are available for use in the framework. However, to fit into the framework, application types must comply with the framework infrastructure and interfaces.

Application framework harmonisation

Relationships application specification - design

We recommend that the properties of a design always shall satisfy the properties of a specification.

This can be verified to some extent using state-of-the-art tools, e.g. verifying that a MSC specification may be executed by a SDL design.

If possible, the rules for mapping service specifications to design objects shall be described, both for the purpose of traceability and for incremental service creation. Ideally, if the rules are well defined, we may perform service evolution mainly by evolving the service specifications. Although this cannot fully be achieved presently, being clear about the rules is a step in that direction.

The internal relationship of application models are illustrated in Figure 28.

Figure 28: Internal application model relationships

In general, the content properties shall be a refinement of the context properties such that the application content model satisfies the context properties.

The application content receives properties from the component types that are used. These component properties shall be consistent with other properties that are specified for the content as a whole and with each other.

Harmonisation application specification - design

Top-down we seek to synthesize the content such that the context properties remain satisfied. Bottom-up we compose the content using existing types such that each interface is consistent, and that the context properties are satisfied. As far as possible we use constructive rules.

Application internal harmonisation

General application guidelines


While we structure domain models mainly to show the concepts and the relationships of the domain, we strive to achieve clarity in the behaviour description when we make application models.

Golden rule

The main goal is to find an object structure that will enable us to describe behaviour as clearly and concisely as possible in state oriented fashion.

State orientation

State orientation is a general principle for behaviour description that helps to make behaviour descriptions easier to understand and analyse. The basic idea is to unfold the state transition behaviour as explicitly as possible in the description. In that way the description is similar to the real behaviour and therefore easier to follow than an action oriented behaviour.


Resource allocation


In order to describe behaviour state oriented and clearly, it is necessary to find objects that behave as independently as possible.

Service concurrency

For the domain and System given parts that perform the service behaviour, this rule leads to:

This helps to find the objects that behave independently in the environment and therefore need to be served independently by the system.


Aggregation purposes


Aggregates are like systems, they have a context and a content. Their environment consists of the entities they know and communicate with, and their content consists of the aggregated parts.

Similarity and types

In many cases it is best to define aggregates as types. We call such types structure types , as opposed to object types that define single objects with behaviour. Look for similarities, which will make type concepts. Re-examine components that are partially similar, but partially dissimilar.

Using library

Designing with SDL


The variability is an important part to consider.

It may sometimes be difficult to capture all variability required in one formal model of the application, because the languages we use have limitations. The way out of this problem is to model several application systems with different ranges of variability. This may sound like a very expensive approach, but it need not be. Provided that we have defined the various component types we need, to define another application system is a simple matter of defining a new top level structure. For the specification this means to define a new context model using existing component types.



The focus on components will be even more important when a framework has been defined.

Object modelling in general

The general guidelines for Object Modelling apply with the following additions:

Developing applications


Figure 29: Developing Application



The main sources of input information are:

The quality of the various sources may vary a lot from project to project. It is of course recommended to put as much as possible on paper, but descriptions cannot entirely replace interaction with other people. Two things are certain:

What to do

Application types are developed in two main steps: 1. the specification step and 2. the design step. As indicated in Figure 29, this holds both for making the first model and for later evolution.

The specification step develops the application context and the required properties, while the design step synthesizes an application content that provides the properties. The content will be a structure of objects with behaviour. Therefore the design step will have two interrelated activities: structural design and behaviour design.

Both the specification step and the synthesis step are split into sub-activities that develop the three main parts of an application system: the domain given, the System given and the Interface given parts. Here the general approach is to work from the domain given towards the Interface given parts as illustrated in Figure 30.

Figure 30: Developing the various parts of an application


There are good reasons for this general approach:

In terms of services, a good approach is to start with the high level services (required by the domain and the system) and work towards the low level interface protocols. This approach is consistent with the idea of layering and separation of concerns. It will promote a structure where changes in one part may be hidden from other parts.

Of course, it may so happen that some parts are more or less given by the initial requirements. For instance that an existing protocol stack or user interface shall be used. This does not alter the general approach to be taken, but reduces the amount of work required for that part.

Making application models

The following general approach to making application models is recommended:

The approach is further detailed in Specifying applications and Designing applications.

Evolving application models

The reason for evolution is that some new requirements shall be satisfied.

The same overall approach is recommended for making (the first) and evolving (the existing) application. The difference is that evolution is incremental and based on existing models. Our ideal goal is to be able to specify services independently and to add new services to the system with minimal impact on existing services and objects. We will strive to achieve solutions that are as flexible as possible, but realise that the ideal goal is not fully achievable today. Some redesign of existing parts will often be required. Normally new services, or service features, will interact with existing services. Feature interaction analysis will be needed to ensure that the new properties combine with the existing properties without any undesirable effects.

This activity is both simpler and more difficult than making (the initial) application model. It is simpler because so much is already in place and we only need to do an incremental addition or change. It is more difficult because even small changes or additions may have profound impact on the existing parts, if not prepared for.

Specifying applications


Inputs to this activity are the same as for Developing application models as a whole, see Figure 29. Be aware that system studies normally are performed before we start specifying the application. During System Studies, the main decision about system boundary, services and environment is made. As a result we have partial answers to questions like:

If these questions have not been answered before, perform that part of System Studies first.

What to do

The objectives of application specifications are:

Therefore, a central issue is to identify objects in the environment that demand services independently of each other, and to describe these services.

The overall approach is as follows:

Making application specifications

As a first step consider what language to use, see Language choice.

Then start to make a type model for the entire application system by representing the system type as one entity type (Class in UML).


Specifying the domain given objects

  1. Represent all the domain Actors and Helpers needing to be served by the system as (active) objects in the environment.
  2. Represent domain Helpers to be implemented by the system as active objects inside the system.
  3. Represent stake holders, subject entities and helpers the system need to know as (passive) objects in the environment.
  4. Start to define object types for all the objects identified so far. For each type, make a context diagram showing the type environment.
  5. Relate domain given types to the corresponding domain types.

As a result we have identified the domain given parts of the environment and the system, and we have started to define object types.

Specifying the system given objects

Consider the system from an enterprise viewpoint. Think of the system in the wider context of an enterprise where it operates and provide services together with users and other systems. What are the combined services and what additional requirements to the system family can be identified in this perspective?

  1. Add (active) objects representing system given actors and helpers needing to be served by the system; place them in the environment and connect them to the system by communication links.
  2. Add (passive) objects representing system given objects and relationships the system need to know; place them in the environment.
  3. Add the context part of type models for the system given types.

As a result we have made a context object model for the system as a whole where the complete system environment is represented, and context models of the component types used in the system context.

We always consult the library of existing component types and pick existing types whenever possible.

Specifying the services

From the domain models we already have domain services. But the domain services will now interact with the System given services. Our first step is to consider each domain service in the light of System given objects and services.

  1. Refine each domain service so it takes into account interaction with System given objects (or roles) and services.
  2. Define each System given service.
  3. Make new component type models more complete by specifying relations to service roles they play.

This activity shall take existing service models into account. For instance, if an existing component type is used, the services it provides may be taken for granted, and the new services may build on it. It may also happen that a new version of existing services are needed. It is only in rare cases one is free to specify all services from the bottom.

Once the services are specified, we have a (complete) context model for the system given and domain given parts of the application system. We also have context models for each of the object types used in the environment, and we have service models. We may now analyse the model for completeness and consistency, and we should involve users and other stake holders in a validation.

Specifying the interface given objects

The Interface given parts should be kept separately from the rest by layering. Consider the physical interfaces and add interface specific parts to the environment, or to the system as appropriate.

  1. Make a type definition for each kind of interface object.
  2. Specify the interface behaviour for each layer of interface protocols:

    define the interface roles using UML;

    make a textual explanation;

    define the role behaviour using MSC. Make one MSC for each independent initiative and describe the main course of behaviour that may follow.

It is recommended to describe the behaviour of each interface using an interface role diagram and at least a number of MSCs. Wherever practical, develop a more complete interface behaviour using SDL.

Evolving application specifications

Evolution may take place in all parts: domain given, system given and interface given. The big difference from making a specification is that we now shall add something new or change something existing. We must therefore consider the impact on the existing.

Note that application specifications are made for the first time before any framework is defined (normally). However, when they are subject to evolution, it is more likely that a framework is in place. In that case we may have abandoned the complete view on application systems in favour of a more component oriented view. This means that our task is to find what component types are affected, and to modify each of them separately.

Designing applications

This activity takes the application specification and synthesizes a design that will provide the required properties. It consists of two parts: Designing application structure and Designing application behaviour.

Designing application structure


In SDL terms this activity is concerned with the identification of blocks and block types in order to divide the system into convenient "components". Blocks may be used to make a layered system. One may chose the extreme that the interface-, system- and domain given parts are represented by one block each, but this may be too inflexible. Blocks are aggregates and should be selected to fulfil the aggregation purposes, see General application guidelines.

Some of the object types and properties developed in this activity may turn out to be quite general and common to many system families in the domain. In such cases the domain object models and domain property models should be harmonised, i.e. updated, to include these object types and properties.

Property descriptions will in this activity be associated with the identified objects of the system, while property descriptions in the domain analysis and requirement specification activities more often are property descriptions of the whole system.

"Finding" the content objects may in some cases appear as "magic" and may require some experience from good design for similar systems. However, once the context is specified with service roles and the interface roles, the task is simpler: just "find" actors for all the roles. With a slight adaptation of an old saying we may say: Tell us who is in your environment and we will tell you who you are (what your content is).

What to do

Making application structure

The following strategy assumes that we know the active environment and the roles that it requires from the system.

  1. Mirror the environment behaviour:

    Identify the objects in the environment, and describe the corresponding types with roles.

    For each role directly interacting with an environment object through a static one-to-one connection, assign an actor object in the system.

  2. Define the corresponding object types and their roles.
  3. If possible, assign the roles remaining to be bound to objects already defined, otherwise introduce new objects.
  4. Introduce switched communication where n-to-m communication is needed.
  5. Continue until all roles have been bound to actors. This may be an iterative process by which new actor objects are found. In principle the search for objects in the system is a search for actors that continue until every association role of every object has an actor. It starts with objects in the environment and the roles they impose on the system. The actors of these roles will be server objects for the corresponding environment objects. These server objects will also have association roles that shall be played. If they require new actor objects, the process continues one more round.
  6. Validate that every role is properly played in the system using the role analysis principles of the SISU method. Where new objects are defined, apply the rules constructively during behaviour composition.
  7. Mirror the context knowledge. The passive objects in the context represent context knowledge the system need to have. This knowledge must be mirrored by data or active objects inside the system. Therefore, allocate the passive objects in the context to active objects in the body. This may result in some new objects being defined. The same principle applies recursively for every object inside the system too. If necessary introduce new active objects to hold the data.
  8. Shared resources. Identify shared resources and introduce corresponding resource allocation objects.
  9. Make MSCs detailing the internal interactions and check that the structure will give effective behaviour definitions.
  10. Continue to adjust the structure until the general rules and guidelines for application models are satisfied (see General application guidelines).

For each aggregate (SDL block); the same rules apply as if it was a system. The decomposition process continues recursively until objects with behaviour (SDL processes) are reached. The structuring of blocks results in a tree of blocks. The leaves of this tree will contain the real actors of our system, the processes.

The principles behind this process are elaborated in synthesis.

Evolving application structure


Designing application behaviour


The task at hand is to define object types where the content is a behaviour definition and possibly some attributes. The goal is to describe the behaviour clearly and concisely in state oriented form.

Object design tries to synthesize object behaviours that will satisfy the desired behaviour properties (services). It will, however, often be so that several objects must be involved in satisfying a single property (service) of the system.

What to do

Making application behaviour

The central issue is to synthesize the behaviour. This can be done in three ways:

Synthesizing behaviour from properties

The behaviour properties express fragments of behaviour that somehow shall be part of the final object behaviour. Behaviour design will compose these behaviour fragments into complete behaviours. This may be done in two steps, see MSC to object behaviour:

  1. composition of behaviour fragments from MSCs to more complete role behaviours;
  2. composition (with a certain amount of adaptation) of object type behaviour from role behaviours.

Synthesizing behaviour from environment behaviours

In some cases the behaviours of objects in the environment are defined, and the task is to design a behaviour that will serve these. The resulting behaviour shall be a kind of "mirror" image of the environment behaviours.

Synthesizing behaviour from informal requirements

Sometimes no behaviour properties are formally expressed, only some informal description of functionality exists. In this case, the preferred approach is to first formalise the requirements in MSCs and then synthesize the behaviour as described above. Alternatively, produce state transition diagrams (SDL process graphs) directly:

  1. Identify the main control states that can be distinguished form outside. At least identify an initial state.
  2. Link the main states together by transitions.
  3. Consider each service that shall be performed and define its external state transition behaviour. Add states if necessary.
  4. When all the services are defined, go through the diagram state by state and check that all possible inputs are properly treated. Apply the rules for input consistent behaviour, see ++
  5. Add the necessary data declarations and parameter handling.

Evolving application behaviour


Summary of static application rules

Language choice

Domain given parts

System given parts

Interface given parts

General considerations

System Content

Summary of dynamic application rules

Domain mapping

Domain relationships can be either Inheritance or Inspired-by. Inheritance can be expressed in the object modelling languages, while Inspired-by must be added outside the languages as annotations.

Domain stake holders

Interface layering


SDL system and environment

For the elements at the periphery of your concern, place them inside the system if you wish to describe their behaviour in detail. If you are merely interested in their signal interface, place them in the environment which means they will not be identified explicitly in SDL.