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:
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:
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.
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.
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:
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.
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 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.
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.
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.
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.
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:
structure design which define the structure of objects and component aggregates;
behaviour design that define the behaviour of objects.
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.
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:
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.
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).
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).
It is recommended to distinguish between the service behaviour and the interface behaviour by using layering as illustrated in Figure 24.
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.
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.
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.
Normally UML will be used for the specification object models:
Context: model the application system as a Class. Represent the environment as object sets with specified variability. Describe associations and communication links in the environment and with the system.
Content: model the content (if any) as object sets inside the class.
Component types: define a class for each component in the system environment and content. For each component class, model the context using separate diagrams.
For property models, text, role structures expressed in UML and MSC will be used.
a role structure expressed in UML;
a MSCs for every initiative and its most important responses.
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:
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.
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.
Of course this division may cause interworking problems between the SDL and UML parts.
An application specification serves to answer fundamental questions like:
It specify the external interfaces and behaviour properties (services) of an application.
The application specification models are illustrated in Figure 26
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.
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:
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.
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.
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.
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 roles using UML;
a textual explanation;
the role behaviour expressed using MSC. There should be one MSC for each independent initiative and each main course of behaviour that may follow.
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 models consists of:
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)
Each type is defined with a context and a content with associated properties. An object type definition consists of:
How the application is related to the domain and the Framework is illustrated in Figure 27.
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.
or an annotation telling that it is inspired-by.
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.)
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 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.
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.
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.
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.
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.
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 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.
when the process graph structure is not dependent on the data values (non-decisive data);
to keep information about the situation and structure of the environment (context knowledge);
to control loops that are not terminated by specific signals (loop control data).
In order to describe behaviour state oriented and clearly, it is necessary to find objects that behave as independently as possible.
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.
gradual approach to detail;
separation of concerns;
definition of a type (class) suitable for use in many places (e.g. AccessPoint);
similarity with the concrete system. NB this consideration should not be taken before the framework is defined.
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.
one active object for each active object in the aggregate environment it communicates with;
one active object for each pool of shared resources to be dynamically allocated;
one active object for each block of shared data accessed and controlled independently;
one active object for each independent routing function needed.
either each aggregate (SDL Blocks) shall be classified as domain, system or interface given;
or each aggregate is subdivided into parts that can be classified as domain, system or interface given.
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.
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.
The general guidelines for Object Modelling apply with the following additions:
Define attributes by attribute types that are either predefined or locally defined.
Associate signal lists with communication links.
Turn communication links into signal routes or channels when designing in SDL.
Stick to constructive relations.
Always use real aggregation for active objects.
Use aggregation relations only for passive objects.
The main sources of input information are:
The system family statement will express overall goals for the application system.
The system studies will provide some sketches of the application system and also express initial requirements.
The domain descriptions will describe objects and properties that will go into the domain given parts of the application (more or less directly).
The framework (when it has been developed), will provide structure and interfaces that the application must abide.
Other families will provide components and possibly ideas for structuring.
Project documents and other documents within the company will provide additional information such as business plans and product strategies.
Users and other domain stake holders can help to clarify what is unclear in existing descriptions and can help to make decisions (in particular regarding specifications and behaviour details). They will also come up with new requirements as their understanding and experience develops.
Project and product management may give additional requirements and guide-lines from the project and company point of view.
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:
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.
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.
The following general approach to making application models is recommended:
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.
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.
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:
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).
As a result we have identified the domain given parts of the environment and the system, and we have started to define object types.
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?
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.
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.
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.
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.
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.
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.
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.
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).
The following strategy assumes that we know the active environment and the roles that it requires from the system.
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.
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.
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.
The central issue is to synthesize the behaviour. This can be done in three ways:
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:
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.
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:
Model the application system as a Class. Represent the environment as object sets with specified variability. Describe associations and communication links in the environment and with the system.
Model the content (if any) as object sets.
Model the Class context for objects in the system environment and content using separate diagrams.
Model the application system as a Block Type in SDL if SDL is used for the complete application system. Represent the environment as gate constraints.
Model the content (if any) as Block sets.
Model the types context for Block types in the environment ant the content.
a role structure expressed in UML;
a MSCs for every initiative and its most important responses.
Domain given parts
System given parts
Interface given parts
interface roles using UML;
a textual explanation;
the role behaviour expressed using MSC. There should be one MSC for each independent initiative and each main course of behaviour that may follow.
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
Represent all the domain Actors and Helpers needing to be served by the system as active objects in the environment.
Represent domain Helpers to be implemented by the system as active objects inside the system.
Represent stake holders, subject entities and helpers the system need to know as passive objects in the environment.
make property models that abstract from the interface given parts and focus on the domain and system given parts;
make additional property models where the interface given parts are included.
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.