This theme is about the basic concepts, principles and ideas on which TIMe is founded. They are presented here to give an overview, and also an introduction to the underlying theories. Here we present the foundation for the "I" in TIMe (The Integrated Method).
The idea is that this theme will present the key features underpinning the methodology. It will start in textbook style, but will contain parts that are more of a reference nature. It will serve as the domain description for TIMe.
It expands somewhat on the central relationship between properties and objects. It is believed that the notion of roles will be central here. Relationships between objects and properties along with rules and operations on roles will be introduced.
To alleviate these problems it is necessary to have a longer planning horizon and to shift focus from individual users and systems towards the more generic aspects of market segments and system families. For this purpose we distinguish between three areas of concern:
In each area of concern the method recommends to make the descriptions indicated in Figure 1 , which will be elaborated in the next chapter.
Responsibility for the different areas of concern will often rests with different departments within a company. Problem domain knowledge is essential for marketing and high level product planning. System families are the main products of the system- and development departments, while system instances are the main concern of the sales, engineering and production departments. In many companies these departments have difficulties communicating effectively with each other and this may lead to misunderstandings that are very expensive. They often have problems introducing new staff too because they lack a high level description of the problem domain and the systems they make. TIMe seeks to overcome these problems by providing high level domain and system models that can be shared across departments and thus provide a common ground of communication.
The various descriptions and the activities that produce them are elaborated in Activities and descriptions .
The essence of systems engineering is to understand needs and to design systems having properties that satisfies the needs in a cost effective way. Without descriptions this is impossible. Descriptions are indispensable in systems engineering and all other engineering disciplines.
To a very large extent systems engineering is a matter of creating, understanding, analysing and transforming descriptions. Consequently, the selection of descriptions, their organisation and languages, are central to any systems engineering methodology.
Within each area of concern the methodology recommends to make the models and descriptions indicated in Figure 2 .
The descriptions have been carefully selected. They are neither too few, nor too many. There is little redundancy, as they describe different aspects and complement each other in a complete, concise and readable documentation. TIMe keeps the amount of temporary (throw away) descriptions to a minimum, and emphasizes descriptions that end up as final documentation. This does not prevent us from identifying partial descriptions that are useful in their own right, such as specifications, and to issue them in separate documents when needed.
We distinguish between formal models, implementations and other descriptions. The formal core of the methodology is the models which are expressed using the well defined languages UML, OMT+- , MSC and SDL .
Domain descriptions are organised in:
Family descriptions are organised in:
Applications that describe what the user environment want the system to do (user services).
Frameworks that describe how applications are distributed and supported by an infrastructure. Frameworks and applications together define the complete system behaviour.
Architectures that describe how frameworks and applications are realised in terms of hardware and software nodes.
Instance Descriptions are organised in:
The concrete system that actually exists in the real world is composed from physical parts and software that executes to provide services to its users. In order to implement such systems we need detailed descriptions of their physical composition and their software. This is what we consider implementations .
However, in order to understand how the system is constructed and in particular to understand what it does for the users, implementations are not adequate. They are far too technical and detailed. Thus there is a conflict between the needs of the machine and the needs of the human. To satisfy the human, we need abstractions that remove the technical detail of implementations and allow us to concentrate fully on the aspects that are important for the human designer and user.
In order to bridge the conflicting needs of human interpretation on one hand and physical construction on the other, TIMe models the world using two main abstractions as illustrated in Figure 3 :
Abstract world models which emphasizes concepts and behaviour related to the user needs. They serve to define the behaviour in an abstract form that can be understood, communicated and analysed as much as possible without binding the implementation. They will often be organised in a Framework with two main parts:
In principle all model abstractions may be used in all areas of concern. The focus in the domain is, however, mainly on the abstract world with emphasis on applications. This does not rule out the possibility of including infrastructures and even concrete world models in the domain where this is relevant.
To some extent the abstraction depends on the language used in descriptions too. But we have tried to follow some general underlying principles in TIMe that make the methodology less dependent on particular language than one could expect. To some extent it it possible to change language and still be able to use the principles of TIMe. For instance, it has been possible to move from the SOON notation, through OMT to the forthcoming UML notation.
Most people find that the most difficult part of systems engineering is to decide on architectural solutions for the systems. A well engineered architecture is clearly instrumental to the profitability of a product. Therefore it is essential that a methodology provide guidance and support to architectural solutions. Central competitive issues today are flexibility, time to market and cost. We seek modular designs:
To achieve this the methodology provide system reference models at the abstract and the concrete level. Another rationale is to identify parts that may have different requirements on development methods and often are developed by different teams.
The application part provide the user services and is the most interesting part from a user point of view. Changing or adding services to the system means to modify the application part. It consists of the following main sub-parts:
Interface given objects that encapsulate the interface specific behaviour, e.g. the behaviour of graphic user interfaces and protocol stacks. By isolating this part from the rest it is possible to change the interfaces without affecting the other parts.
System given objects that encapsulate the system specific services and information. These are particular for this system family and not common to all systems in a problem domain.
Domain given objects that encapsulate services and information that are common to the entire problem domain. These objects are reused across system families.
The infrastructure part contains additional behaviour needed to fully understand and analyse what the system does (the complete system behaviour). Here we find object that support distribution, system administration and other facilities not directly related to user services.
Whenever practical the application and the infrastructure will be put together in an application framework that serves to simplify the definition of new abstract systems.
A Concrete system consist of:
Note that the various parts of the system models are quite independent and may be modified with little impact on each other. It is, for instance, possible to change the implementation platform without needing to modify the application. Thus an application may survive several platform generations and thereby provide better return of investment. Similarly a platform may support several applications. Adding or changing services is mainly performed in the application, leaving other parts unchanged.
We will distinguish between a system and its descriptions. A system is part of the real world and is able to perform behaviour, thus serving its users. Descriptions, on the other hand, represent the system and enable us to understand, analyse and communicate about it. Descriptions are also part of the real world, but they are distinct from the system and cannot perform behaviour and serve users like the system does. What they can do is to define the rules of behaviour.
Designers tend not to distinguish clearly between descriptions and systems. For them the word "system" often means "system description". For the users, however, the difference is profound. From the designers point of view, evolution is mainly a matter of change and adaptation of descriptions. From the market, or user, point of view, it is a matter of change and adaptation of systems. Maintaining the relationship between systems and descriptions is therefore essential for successful evolution.
It should be noted that any particular concrete system may be composed from more than one application. TIMe supports the development of heterogeneous distributed systems using a mixture of languages and methods.
Descriptions may be structured in many ways. Some will be easy to comprehend and relate to the real system, while others may be hard. A compact description is no better than a larger one, if it is harder to relate to reality.
As can be seen from Figure 5 , we use two related model types:
A central idea in TIMe is that every object (and system) is characterised by properties that can be used:
Property models are not necessarily bound to object models, but object models shall normally be bound to property models.This holds for all object models: domain models, application models, architecture models.
The purposes of separating Property Models from object models are:
There are many kinds of properties: behaviour properties, performance properties, maintenance properties, etc. In TIMe, the property models will contain properties that are relevant for the corresponding object models:
Object models consists of two main parts, illustrated in Figure 6 :
The object-property dimension and the context-content dimension give every type model four facets as indicated in Figure 6 .
A specification covers those aspects of a model that are relevant for its external representation and use. The context part is often sufficient as a specification, but if parts of the content is important it may be included in the specification. Specifications are associated with the abstractions they belong to:
A design cycle start by making a specification where the context object model and the context property models are defined. It then makes a design where the content object model and the content property models are defined. In the specification, the emphasis is on properties, while in design it is on objects. But the properties of the specification shall be satisfied by the design.
Specifications serve three main purposes:
The specification serve as a datasheet for a designer looking for existing components to (re)use in a design. They also serve to describe interfaces in a way that simplify validation of interconnections.
1. Make activities . Activities that make or synthesise descriptions ( models) for the first time, possibly based on other descriptions, e.g. to make SDL process graphs from requirements expressed using MSC. A variety of techniques are used: transformation, translation, composition, decomposition and reuse.
2. Evolve activities . Activities which perform (incremental) development of existing descriptions. They may either add new properties, e.g. add a new service to existing Application models, or change existing properties, e.g. correct errors.
3. Harmonise activities . Activities which ensure that models/descriptions are consistent with each other, e.g. to make the domain dictionary consistent with the domain object models. The activity will ensure that certain relationships that should hold between models/descriptions are satisfied. For instance that an object model satisfies the properties specified in a property model, or that a content satisfies a context.
4. Analyse activities . Activities that analyse a model/description, e.g to verify that a design satisfies given properties.
The make activities can be subdivided according to the the main facets of a model (see Objects and properties ) into:
Make structure design: synthesises the design object structure with associated properties for the first time. As part of this it identifies the component types used in the structure. For those that must be developed from scratch the same basic make activities are applied again. This activity follow guidelines that seeks to ensure consistency with the specification.
Make behaviour design: synthesises the behaviour of object types (e.g. the process graph of an SDL process). This activity too, follows guidelines that seek to ensure consistency with the specification.
After a description is made the first time, it may be evolved by adding, modifying or removing features. This is performed by evolve activities. They are different from make activities because the target description already exists when they are invoked. They must consider the impact on the existing target and carry out modifications according to the new requirements. They must also consider whether the result should be treated as a revision to replace the previous target, or as a variant that shall co-exist with it.
Harmonisation is the general term we will use for maintaining desired relationships between descriptions. Harmonisation applies both to the descriptions within an area of concern such as between the the domain descriptions, and between different areas of concern such as the between domain object model and the application object model. Within the domain, for instance, we harmonise the terminology in the dictionary, the statement and the models. It also applies to the different abstractions: we want the application models and the implementations to be consistent.
Ideally, harmonisation should take place after each step in order to keep the descriptions consistent at all times. In practice, however, we must accept some deviation from this ideal. A central point in TIMe is that object descriptions and property descriptions represent two different perspectives on some entity (usually a type). This implies that, that even if domain-, design- and implementation descriptions are not maintained so that they are consistent, then the object and property descriptions within the same models (e.g. the domain models) are consistent. It also implies that the activities producing these will have a tighter interaction than the activities from different areas.
Constructive design methods that will ensure consistency between the required and provided properties will be emphasised. Still it will not be feasible to ensure that they are consistent at all times.
These are activities that derive properties from descriptions and compare descriptions. They are typically used to verify and to validate descriptions on the different abstraction levels. For instance to see if an object type is able to provide some required properties, or to check that an application system is deadlock-free.
The main modelling languages are summarised in Figure 7 .
Both abstract and concrete world models are relevant for families. Frameworks (applications and infrastructures) are primarily expressed in SDL, but OMT+- is used as a supplement both for high level specifications and for parts where SDL is less suited, e.g. database applications. For reactive systems, SDL-92 will be used as the main language. However, SDL is best suited for the control part of reactive behaviour, and less well suited for pure transformations (algorithms), data-oriented applications and user interfaces. As modern systems often need to integrate these other aspects, TIMe provides support for these parts as well based on OMT+- or the forthcoming Unified Modelling Language, UML.
In the instance area of concern, the main thing is to configurate and to build a system instance. This can be done both on the abstract level, using SDL, in the Implementation Architecture, and in the implementation. The common practice in most companies is to do this on the implementation level using configuration files and tools like Make . An alternative is to use special configuration languages in this area.
TIMe will allow systems to be described by a mixture of notations and languages in order to cover all system aspects. It will for instance be possible to model control behaviour using SDL and data manipulation using OMT+- or UML.
This means that a concrete system well may be composed from parts that are modelled and developed using different techniques. Each of these parts may then be considered a system in its own right from a modelling point of view. Consequently, what we choose to consider a system will depend on the circumstances, and need not always be the complete system that will be delivered to customers.
What we choose to model as an SDL system may be just the parts where SDL is well suited. Other parts may be modelled in OMT+- or eventually in UML. The practical implications are that the SDL system concept will be less important. In stead the focus should be on generic component types that may be put together and configurated as easily as possible into complete systems. In SDL terms this means to focus more on block types and process types than on systems.
It is not obvious that these two purposes can be served by the same set of descriptions. Indeed, there are methodologies that emphasizes the first purpose and produces many descriptions that only serve the process and not the final product. The models we use in TIMe have been selected to serve both these purposes. TIMe seeks to keep the amount of temporary (throw away) descriptions to a minimum, and emphasizes descriptions that end up as final documentation. This does not prevent us from identifying partial descriptions that are useful in their own right, such as specifications, and to issue them in separate documents when needed.
In systems engineering projects, the various models and descriptions are developed gradually in an order that help to illuminate critical issues and make decisions at the right points during a systems engineering process. They end up to complement each other in a complete and readable documentation.
The descriptions within different areas of concern and on different abstraction levels are developed in steps that help to reduce risk, and to improve quality and control. This help to give better control and also to use the skills of different people better and to run activities in parallel.
Each object type model is developed in two main steps: first the specification step where the specification part (interfaces and the required properties) is made, and then the synthesis step where the design part is developed.The main development cycles are illustrated in Figure 8 .
This is of course a simplified illustration of the main steps. Considered over time we will se that the descriptions evolve gradually, that there are many iterations and that changes take place due to better insight, new requirements and new technology. We will also see that there are other, smaller cycles. For instance: to add a new service or feature to an existing product we need not modify the domain. To produce a customized instance we only need to add a new instance configuration.
One should not jump to the conclusion that TIMe only supports the classical "waterfall" model! It is up to the actual projects to determine whether they will adopt a waterfall strategy, a prototyping strategy, use incremental development or whatever.
It is then up to each project to plan and carry out a process where they are performed in a suitable order. Some typical process cases are presented in Process models. Processes will invoke the activities and evolve the descriptions through a sequence om milestones and intermediate steps as illustrated in Figure 10 .
Activities and processes are about HOW TO DO IT. Or more precisely: how to carry out property oriented development projects. They provides the practical guide-lines needed to achieve a controlled process starting with the initial needs and ideas and ending with quality products ready to be installed at customer sites.
Relationships between all the models and other descriptions shown in Figure "The main descriptions used in TIMe" must be defined. There are:
In the systems engineering literature and practice, the terms "documents", "descriptions" and "models" appear frequently. Do they mean the same, or is there a difference in meaning? We will use the terms to mean two different, but related, things:
Why this distinction? Because it enable us to distinguish between the information which is essentially needed to develop and understand quality systems (the models and other descriptions) and the accidental form used to present it on various occasions (the documents). The n:m relationship, between models and document indicates that documents and models should be maintained separately.
Normally, many documents are produced during a project. As a minimum, formal communications and decision points in a project will be based on documents. The structure and contents chosen for each particular document will depend on the occasion and the audience that particular document is intended for. Most models, on the other hand, are not intended for any particular occasion or audience. They express up to date information about some area of concern. A domain model, for instance, has meaning in terms of a domain and is stable as long as the domain remains the same.
Some companies are very document oriented. The work proceed through a sequence of documents and much of the effort is centered on document production. To a large extent models and descriptions exist only as part of documents. Consequently, where to find complete and up to date models and descriptions are not always obvious. This problem may be amplified if different departments prefer to express essentially the same information in different ways. As a result, much effort is spent on translating and repeating information.
The cost associated with this repetition is probably the least problem. More serious is the likelihood that the models seen by different people are inconsistent. Even more serious is the tendency to be preoccupied with document form rather than model content. Another common problem is that textual specifications are structured according to document standards and not according to the model of the system.
The other extreme is a purely model and description oriented organisation, where everything is centered around models and descriptions. In practice there will be a mixture. The question is how much emphasis there is on such models compared to documents. Are models the main results on which communication, quality control and progress measurements are based, or is it documents? Is one consistent and complete set of interrelated models sought, or is the collection of more or less complete models found around in various documents considered good enough?
TIMe recommends to be mainly model and description oriented, but recognizes that documents are needed addition for external communication, formal reviews and contracts, see Figure 13 . The basis for communication and common understanding, is the models. It is therefore essential that all team members see the same models. Since models are gradually developed and updated in the course of a project it is also essential that the team members see the same versions.
1. Passive objects . The purpose of passive objects is to represent something we need to know about. Descriptions of passive objects will abstract from physical details of the entities they represent and model only what we need to know about them. The behaviour of passive objects will normally be very different from the actual behaviour of the objects they represent. A passive object representing a person has a simple behaviour concerned with updating of attributes and relationships (data), while the real person itself has an extremely complex behaviour.
2. Active objects. The purpose of active objects is to take care of transformations and control we need to perform. They are justified more by what they do than by what they represent. Their behaviour is often detailed and related to physical processes. A call handling process in a telephone system, is one example. It interacts with physical users and controls physical connections.
Note that this classification is according to how we want to describe objects, and not necessarily depending on real object properties. The same physical object may well be described both as a passive and an active object. An access point in the Access Control system, for instance, is a passive object in the validation database, and at the same time an active object controlling user access to the system. In a way the passive objects are like property descriptions of the active.
Passive and active objects are related as illustrated in Figure 14 . We will normally describe active and passive objects in separate but related descriptions.
The relationship between passive objects and the objects they describe, i.e. the meaning, is quite important and central to the correctness of a system. TIMe will seek to take care of this relationship and use it constructively during synthesis and correctively in V&V.
Object models are made where we need a constructive description at a given level of abstraction.
Object models can be organised in many ways. TIMe assumes that object models are organised as illustrated in Figure 15 to have two main parts:
1. By explicit and local definition of the content. This is what is illustrated in Figure 15 .
For each component, two similar options apply: it may either be defined, as illustrated in Figure 15 ,by explicit local definition, or by instantiating an object type defined elsewhere.
If we represent and entire object model, like the one in Figure 15 , by a triangle, we may illustrate these various ways that type models may be used as in Figure 16 . It illustrates that a type may be used in three "dimensions": in sub-types, in components and in system instances.
For each type model, property models will be associated with the context and the content, see Property models .
Depending on the abstraction and the problem, we will use either OMT/UML or SDL for object modelling. These languages are based on object oriented principles supporting types, inheritance and instantiation and can be used to make object models according to the principles explained above.
The principles for object modelling are further explained in Object modelling .
Functional properties characterise the behaviour of abstract systems . In TIMe, abstract systems are modelled in Application models and Framework models . Figure 17 illustrate how functional properties are related to Application systems .
Figure 17 illustrates how the properties relate to the different parts of an application system. Note that interface and service properties involve at least two objects where some are in the environment and some in the content. Also note that properties may be related by layering.
It is well known that users tend to think in terms of services and interfaces. Therefore it is customary to characterise systems using a service oriented perspective. This is best explained in contrast to the object oriented perspective as illustrated in Figure 18 . Many services will naturally involve several objects. A normal call in a telephone system involves at least two objects: the initiating subscriber and the terminating subscriber. There is no point in one without the other. The service perspective allows us to see the two in combination, but only to see fragments of each object. In the object perspective we are able to see the complete object, but only fragments of each service.
Services are controlled via interfaces, and interfaces may have properties of their own. These properties (protocols) must be followed by both sides of the interface, as illustrated in Figure 18 . Objects may have several interfaces, and the same interface may apply to several objects. Indeed, standard interfaces is a key to achieve architectural flexibility. There may well be mutual dependencies between interfaces. The behaviour a user experiences on a given panel depends on the access rights the user has been granted through the operator terminal. Such dependencies will be visible as non-deterministic choices at the observed interface, but the exact nature of the influence will be hidden.
The data stored in a system or object is central to its purpose. In a specification the interesting thing is what the system (or object) knows about the environment. In other words: what are the associations between (passive objects in) the system and the environment.
1. Service and interface properties will span several objects. They are composed from (sub)properties of different objects. An important advantage of the property perspective is the possibility to combine and describe properties of different objects that belong together in one place. This will be utilized to describe service and interface properties in one place such that they may be used to characterise all object types using the interface.
2. Object properties are composed from sub-properties belonging to different services and interfaces. However, composition of properties into objects is not as simple and well defined as composition of objects into systems. The reason is that objects encapsulate behaviour and have interfaces, whereas object properties are likely to be fragments of behaviour without interfaces.
The notion of roles will help to satisfy both these requirements. We will use roles to represent objects (anonymously) in property models, and we may compose the properties of an object from roles described in different property models. The ovals in Figure 17 and Figure 18 represent roles.
In a play, like Peer Gynt by Ibsen, we find roles such as Peer and Mor Aase. In the theatre, during a performance we find actors playing Peer and Mor Aase. The roles, as described by Ibsen, specify required properties of the actors without specifying what other properties they may have. If the actors are good, they provide the properties in a way that make us believe that Peer and Mor Aase are real. After the play is over, the actors will do something else and provide other properties. This notion of a role can be formalized as the properties of an object appearing in the context of a service (or function), the play.
Another notion of role comes from the relationship between objects. A person has the role of father in relation to his daughter, husband in relation to his wife and owner in relation to his car. This notion of role can be formalized as properties of an object appearing in relation to another object. It is typical for this kind of roles that they are related in pairs. The role of daughter is complemented by the role of father. It is also typical that the role correspond to required properties the actor should provide in that relationship. An object may well play many roles, but they should not be mixed. (Some reactions are bound to surface if a person mixes the role of husband with the role of father, for instance).
Service roles are the parts that objects play in a given service (or function) In a basic telephone call for instance, there is an initiating subscriber role, and a terminating subscriber role. These roles must be played by different objects in the same call (service invocation), but an object may well play both roles in different calls. Service roles are often dynamically assigned so that objects take on one service role at the time (but not always).
Interface roles allows us to describe and study (required and provided) properties at a particular interface, such as a user interface, and to discard the other interfaces. Using interface roles, we may describe and analyse the properties of each interface separately. In that way we obtain an external view structured according to the interfaces, e.g. the users view and the operators view. Interface roles are statically associated with the interfaces of an object (or system).
An object will often be able to perform several service roles and some of these may be accessible from the same interface as indicated in Figure 19 .
In TIMe we recommend to define the environment of each object type in the context part of the object model, and here we shall describe all the objects that are in the environment and somehow are related to instances of the type being defined.
For each instance of the type, every environment role shall be assigned to an actor, i.e. an object in the instance environment playing the role. For a system to be consistent, the play of all these roles must be valid. (Exactly what this means will be elaborated later.)
Thus, attached to an object type there are environment roles describing properties required from other objects. Due to symmetry, these implicitly describe properties provided by the object type as well see Figure 20 .
Interfaces and service roles are related to object designs by projection. These projections are similar to the well known geometrical projections in that they show everything that is visible from a given angle, and hides the rest. As in geometry we use projections in two ways:
Instead of projections as geometrical views, we look at the observable behaviour of objects. When making such projections we can perform some consistency checks which are explained in Risk index .
For more about roles, see The relationship between objects and properties .
To read more about property modelling in general, see Property Modelling .
We shall use MSC as the main language to describe role behaviours.
It is not obvious that a property description is consistent with an object design. Therefore, our first issue is to understand the relationship between object design descriptions and property descriptions. We are seeking principles that helps to:
When we use instances of the type in composition, see Figure 16 , actual objects in their (instance) environment will be assigned the environment roles, and will have to play these roles as expected. Otherwise the composition will not be valid. Conversely, each of these actor objects assign roles the other way. In that way each object in a composition will assign environment roles to other objects and be assigned roles from them.
This role-play principle is symmetric. The validation of an interface is to check that both sides play the roles they mutually require from each other. It follows from these considerations that the notions of roles and plays are closely connected to the notion of validation and thus to system quality. If we are able to formalize these notions, we might find better ways to achieve quality control. This is one of the ideas we will pursue in TIMe.
The notion of Risk index can also be used constructively. Whenever we design a new process type we should ensure that it has a low risk index in all its roles.
2. Composition. The content is decomposed into parts (top down) and/or composed from parts (bottom up) using a mixture of manual and automated techniques. The method seeks to reuse existing types as much as possible, and to make new types that might be needed reusable. Thus, design with reuse and design for reuse is part of the method. Design with reuse involves:
The content design is either a behaviour, or a (component) structure. In the case of a structure, each component type is synthesised using the same principle as for the enclosing type: first specify the context with properties and then synthesise the content. In this way, the make activities are invoked recursively, see Objects and Properties and Object models .
2. Mirror the environment knowledge. The system structure should contain a data object for each entity or relation the system needs to know about. Allocate these data objects to the concurrent actor objects needing the knowledge, or to separate objects when the knowledge needs to be shared.
A precondition for the first rule is that we know the concurrent roles required by the environment. In other words: we are looking for environment roles that are to be composed in parallel. What kind of roles are that?
Therefore we need to identify the objects in the environment and the corresponding environment roles in order to see the concurrency required. Since our goal is to design a structure of objects and interfaces that will satisfy the requirements of the environment, it is hardly surprising that we have to start by identifying objects in the environment. By defining a type for each of them, we find the environment roles that the system shall play.
Without any knowledge of the object structure, we cannot tell whether these roles should be composed in sequence or in parallel. When we know the objects, however, we may analyse the concurrency and determine how the roles shall be composed. For environment roles, such as the SubServer, we have this knowledge.
We therefore start with the environment and the environment roles it imposes on the system, see Figure 21
Each subscriber, being an instance of the TYPE Sub, demands that the system is able to play the role SubServer to serve their needs. We assume that corresponding roles, OpServer and TrunkServer, have been defined for the Op and the Trunk types. Since the subscribers are concurrent objects, their initiatives will be independent. The corresponding roles must therefore be composed in parallel. Since the sequence following each initiative is largely independent of other initiatives, the parallel composition is best achieved by concurrent objects as illustrated in Figure 21 . At this point we may note the following:
The task of the designer is to find objects in the system that will satisfy these needs. When the needs are represented in the form of environment roles, this task is simplified a great deal. By using the environment mirroring principle, we easily get the first ideas about the object structure in the system. As a first step we identify an object for each of the statically assigned, concurrent roles in Figure 21 , see Figure 22 .
Our next step is to find actors for the remaining interface roles: Calling, FirstCalled and SecondCalled. Our first choice is always to look for actors among the existing objects. If they are not suitable actors, we introduce new objects. In this case it is specified that the actors shall represent instances of Sub, Op or Trunk observing the same role behaviour. We already have such objects both in the environment and in the system. In the environment we have direct instances of the specified actor types, and in the system we have the SS, OS and TS objects which may represent the same types. Using the internal representatives allows us to maintain a single, non-switched, channel towards each object in the environment. This will be our first choice, as indicated in Figure 23 .
In order to design the types for the internal objects in the system, we apply the mirror principle again. Let us consider one of the SS objects. From the Subscriber, the SS object gets the SubServer role statically assigned. This role implies that the roles Calling, FirstCalled and SecondCalled are played by other objects in the system. These objects will in turn require corresponding roles to be played by the SS object, as illustrated in Figure 24 .
Both ways we must be aware of the how the roles should be composed (in sequence or in parallel). Analysing the initiatives, we see that the Calling role behaviours are triggered by a call initiative from the "own" subscriber, whereas the termination initiatives may come from either the "own" subscriber or some other object. The FirstCalled and SecondCalled role behaviours are triggered by initiatives taken by other system objects, whereas the termination may come from either those objects or the "own" subscriber. Consequently a combination of sequential and parallel composition is needed. It is not obvious which solution will be best in this case: