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.
The criteria for being included here is that the topic is central to TIMe and to integration, and that it is used pervasively in the methodology.
This initial version contains only a brief overview as a starting point for discussions and agreement.
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.
The basic concepts and ideas are organised along the following dimensions:
They will be described in the following chapters.
A major concern of most companies is to sell and deliver as many systems as possible. However, if their focus is entirely on the short term profits of each particular system delivery, they risk:
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 5-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.
TIMe offers the following advantages to the different departments:
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 5-2.
These descriptions are necessary and sufficient to achieve central goals of TIMe:
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.
Domain descriptions are organised in:
Family descriptions are organised in:
Instance Descriptions are organised in:
Textual explanations may be attached to models as well as to other descriptions.
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 5-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.
The implementations are composed from a variety of notations and languages for hardware design and programming.
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.
Note that the main model abstractions is a rather coarse classification. There may more abstractions in a practical project.
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, during the development of TIMe there was a move from the SOON notation, through OMT to the UML notation.
All this is detail however. The main point is that we use abstractions primarily to improve human understanding and communication, and concrete systems to build the physical systems.
As explained in Objects and properties, models have facets illustrated in Figure 5-4. In general there are object models and property models. Seen together they define a context and a content. The context represents the entity being defined (e.g. a system type) as a "black" box and details of its environment, while the content details its internal composition in terms of object structures and behaviour.
A specification covers those aspects of a model that are relevant for its external representation and use, while the design covers the internal composition and the internal properties.
The distinction between specifications and designs is not so important in domain models, while in system family models it is important. This has been illustrated for application, framework and architecture models in Figure 5-2.
A specification covers those aspects of a model that are relevant for its external representation and use. The context part is often sufficient as a specification, but if parts of the content are important they may be included in the specification. Specifications are associated with the abstractions they being to.
TIME emphasises the specifications are not special models, but integral parts of type models. The reason is that we want to minimise the amount of descriptions that are thrown away. Instead we want to make use of specifications throughout the lifetime of the model:
Specification and designs are often developed in different phases. Specification are produced early endplay a central role in quality and process control. Designs are produced later. Therefore in a development project they are developed by separate steps as illustrated in Figure 5-10.
In TIMe we consider a requirements specification as a document. it is normally produced early in a development project and used as a contract for the design work. We force that specifications are used:
Important qualities of specifications are:
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.
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 consists of:
The role of the implementation architecture model is to define the overall architecture of the concrete system and define how the abstract systems are mapped to (abstract system) implementations.
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.
Our quest for structural similarity have caused us to adopt object- and state orientation as the primary perspectives for system description.
As can be seen from Figure 5-7, 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 5-8:
The object-property dimension and the context-content dimension give every type model four facets as indicated in Figure 5-8.
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.
Viewed from the development processes, activities can be classified in these categories:
The make activities can be subdivided according to the the main facets of a model (see Objects and properties) into:
It is here assumed that the content of a model is either a structure or a behaviour.
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.
TIMe emphasises flexibility in the design solutions in order to support an evolutionary approach and service flexibility.
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.
An important aspect to harmonisation is traceability. As a minimum it shall be possible to trace how each requirement is mapped to design.
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.
In general, analysis seeks to check that desired relationships hold between models/descriptions.
Analysis and harmonisation is closely related to the various relationships that may be defined between descriptions.
The main modelling languages are summarised in Figure 5-9.
However there may be cases where concrete world models are appropriate, e.g. to describe physical conditions, implementation principles or non-functional properties that apply throughout the domain.
Both abstract and concrete world models are relevant for families. Frameworks (applications and infrastructures) are primarily expressed in SDL, but UML 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 the Unified Modelling Language, UML.
In the instance area of concern, the main thing is to configure 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 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 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 configured as easily as possible into complete systems. In SDL terms this means to focus more on block types and process types than on systems.
Another implication is that some way to define complete systems composed from inhomogeneous parts is needed. For this purpose UML will be used for high level architectures.
Assuming that the models are the key to systems engineering, how are we going to use them during the systems engineering processes?
Bear in mind that we make descriptions for two main purposes:
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 5-10.
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 5-12.
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.
It is clearly necessary to establish and maintain clear and traceable relationships between the various descriptions and models. There are several reasons:
Relationships between all the models and other descriptions shown in Figure 5-2 must be defined. There are:
The precise definition of relationships depend on the languages that are used. They will be elaborated under the various description modules.
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 5-15. 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.
Objects have the following characteristics:
Good objects have the following additional qualities:
We generally classify objects appearing in object models in two categories depending on their purpose in the model:
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 5-16. 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 Modelling has traditionally been used only for passive objects to be handled by information systems. TIMe will also cover active objects performing general functions.
Traditional data models are object models describing passive objects.
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 5-17 to have two main parts:
In the family area the emphasis will be on object type models. A type may be defined in two ways:
For each component, two similar options apply: it may either be defined, as illustrated in Figure 5-17, by explicit local definition, or by instantiating an object type defined elsewhere.
If we represent and entire object model, like the one in Figure 5-17, by a triangle, we may illustrate these various ways that type models may be used as in Figure 5-18. 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 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 5-19 illustrates how functional properties are related to Application systems.
Functional properties are classified in the following categories:
Figure 5-19 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.
An important class of general properties is safety properties, which state what should never happen, typically:
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 5-20. 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 5-20. 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.
We can now make two important observations:
We have two requirements to functional property models:
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 5-19 and Figure 5-20 represent roles.
Several strands of thought pointed towards roles as a useful idea:
The word "role" is used quite frequently in everyday life. The meaning is mostly informal, but will often be synonymous with a function or a relationship.
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).
In general, every object provide some roles at its interfaces, and require complementary roles from the objects at the other side of the interface.
We will use two main categories of roles:
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 5-21.
A service may also span several interfaces. Service roles may in special cases, be identical to interface roles, but more often several service roles will be visible in the same interface.
In relation to a given object structure, service roles observe the structure from "above", while interface roles observe it from "the side" through interfaces.
Each object type defines roles for entities in its environment, either explicitly or implicitly.
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.
Entities in the type environment are not real objects but rather anonymous objects that will become real objects when the type is instantiated. We consider these as environment roles.
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 5-22.
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:
Both ways will be part of TIMe.
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.
Interface properties and service properties are described using:
As interfaces and services often will be layered, the property descriptions will be layered too.
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:
The notion of roles is a key to all this.
Through the environment roles of a type (defined in the context part of the type model) we formalise the requirements that instances of the type have on their environment.
When we use instances of the type in composition, see Figure 5-18, 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.
Environment roles may be used in several ways:
We summaries with the following rule:
Two basic techniques are used to synthesise a design:
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.
How should we proceed to synthesize the system structure from the requirements? We recommend the following core rules:
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?
"Parallel composition will be the main rule for fragments on interfaces between different object pairs".
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.
The following approach may be used when making a design structure.
If we have expressed the functional requirements entirely in terms of service role models, the first step will be to compose the service roles into environment roles.
We will use a PBX to illustrate the approach. In a PBX we usually identified a number of service roles called A-party, B-party, C-party, NormalCall, ConferenceCall, TransferCall, and so on.
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 5-23
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 5-23. At this point we may note the following:
The environment roles defined for the environment types are explicit representations of the needs of the environment!
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 5-23, with the result shown in Figure 5-24.
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 5-25.
These objects will not be totally independent and need to be coordinated. How can we know that? It follows clearly from the interface roles. The implications are the following:
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 5-26.
Our next step is to define a type that will play these roles.We may do this in two ways:
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:
If the second alternative is chosen, the dependencies must be taken care of by means of signals and/or shared data.