Systems in the scope of TIMe are characterised by consisting of concurrently executing objects that communicate by sending signals and whose behaviour is best described by states and transitions (reactive systems).
These systems tend to become large and complex - therefore it is not sufficient to describe the objects - the system also has to be structured in some way. Important properties are often described by use cases and by interactions between objects of the system.
UML , OMT  and many other methods use object diagrams and informal sketches in the specification and design of structure and a Statecharts-like notation for the specification of behaviour. TIMe uses one language for both: SDL.
SDL is a language recommended by ITU  for specifying structure and behaviour of systems that are reactive, concurrent, real-time, distributed and heterogeneous (not just telecommunication systems).
MSC is a notation recommended by ITU  for describing interaction scenarios.
TIMe recognizes that UML and SDL have slightly different approaches to object modeling, that these differences in some cases are beneficial (UML provides e.g. concepts for associations, while SDL does not) and that they in other cases may cause problems. Instead of a clear cut between object modeling in UML and SDL, TIMe defines its underlying approach to object orientation and provides guidelines on how to use both UML and SDL to support this.
The approach followed in this method is that an object model is regarded as a physical model, simulating the behaviour of either a real or imaginary part of the world. The main property of physical modeling is that it is based upon a conception and understanding of the application domain in terms of phenomena and concepts, and that physical models will have elements which directly reflect these phenomena and concepts. The physical model will consist of
Objects are characterised by variable attributes (data attributes), procedures (potential behaviour patterns) and behaviour. Objects in this approach may execute their behaviour concurrently with other objects. This kind of object is sometimes called " active objects" in contrast to " passive (data) objects".
TIMe uses UML for describing object models in case the formality of SDL is not required (or desired). The full TIMe book contains a tutorial on UML; the following is just an overview, covering the most important elements.
In Figure 46 three classes are defined with attributes, and no operations.
Classes may be related, as e.g. in the domain object model in Figure "The access control domain". AccessPoint and User are connected in order to specify that objects of these classes communicate.
Classes may inherit properties from a superclass, as in Figure 48, and thereby define more specialized classes.
Although UML supports multiple inheritance, TIMe advocates the use of single inheritance. One reason is that this is by far the best understood concept - another reason is that SDL only supports single inheritance.
In order to really specify that the objects are part of the containing object and that relations to these part objects are only meaningful when contained in this object, TIMe uses the notation in Figure 49. It is specified that each AccessPoint consists of three objects (of classes Panel, Door and Controller) and that the environment communicates with some of these part objects. In UML the User in the environment would have associations to the class Panel in general, while what we want to express is that they only have associations with Panels as part of AccessPoints.
The corresponding can be expressed in UML using Composites, see Figure 50.
A block may either be further structured into blocks, or it may contain a number of processes. A block type defines a category of blocks with the same properties. The block type diagram in Figure 52 defines the AccessPoint referenced in the system diagram.
Each AccessPoint block will consist of three processes: Panel, Door and apc (access point controller) of process type Controller. The fact that the process type controller is defined to be virtual implies that it may be redefined in subtypes of AccessPoint.
The processes of each AccessPoint block are connected by signal routes, and the signals on these indicate the possible communication between the processes. The signals used between the processes of a block can be defined locally to the block.
Processes execute concurrently, communicate by means of signal exchange (or remote procedure calls), and have the behaviour represented by an Extended Finite State Machine. The extensions are that processes may have variables and actions as part of transitions.
The subtype hierarchy which is specified in UML in Figure 48 will in the corresponding SDL design be represented by two block types inheriting the block type AccessPoint. In Figure 54 this is illustrated for BlockingAccessPoint.
When the redefined Controller gets a Disable signal (in all states) it will enter the state Blocked, where it will only accept Enable, while all other signals will be saved (for consideration in other states).
SDL has more specialised concepts, so in a mapping from UML to SDL a number of decisions must be taken. Most UML classes of objects will map to process types, but in UML we may define attribute types as classes, while attributes in SDL are mapped to variables of data types. Aggregated objects in UML may either map to blocks (containing other blocks or processes) or to processes (containing services).
Classes in UML maps in general to types in SDL. Classes of objects with their own behaviour and with communication with other objects map to processes types, classes of container objects map to block types, and data object class map to SDL data types.
Attributes of objects map to variables of data types. A difference between UML and SDL is that attributes of UML objects are just of predefined types, while variables of SDL can be of user-defined types.
Relations are not easily mapped to SDL. TIMe makes a distinction between constructive and illustrative relations. Being aware of this distinction when defining relations help in the mapping. Constructive relations will readily be implemented by a corresponding data base part of the system, while illustrative relation must be "implemented" in SDL.
The relations in Figure 58 are for illustrative purposes in the mapping of the AccessPoint class to the AccessPoint block type, while the connection between AccessPoint and User maps to a gate e. The User class of objects is "mapped" in the first round to processes in the environment of the AccessPoint and in the second round to processes in the environment of the system.
In a further mapping of the classes in Figure 58, the classes be in addition be mapped to classes of objects in a database of which users may enter which access zones through which access point. In that mapping the relations are not just illustrative but may map to corresponding relations in the database.
It is recommended to use only single inheritance. This is readily mapped to the corresponding mechanism in SDL. The difference is that inheritance will have more implications in SDL than in UML, especially for inheritance between process types. While UML only specifies the inheritance of attributes and operations, inheritance for process types implies also the inheritance of behaviour also.
Inheritance between classes are not restricted to UML classes that map to process types or block types. Architecture of systems can be represented by a special system class in UML and if using the real aggregation of UML the content of the system objects can be readily expressed. Subclasses of such system object classes are mapped in the same way as in Figure 59, just substituting BLOCK with SYSTEM un the headings.
Multiple inheritance of the special kind where just one of the superclasses is a real superclass and the other are just "interface classes" (that is classes with only operations with no specification of behaviour, and no attributes) can in SDL be represented by inheritance combined with a gate for each interface superclass.
Multiple inheritance in general can be mapped into a type where the properties of the superclasses are copied into the type corresponding to the subclass (resolving the inheritance) or in some cases by aggregation. The first is not recommended, but must be done in some cases. The second alternative take different forms:
Normally a problem with representing multiple inheritance by means of aggregation, in languages with object references, is that the objects of the resulting subclass cannot be referenced by object references typed with the superclasses. SDL does not have a general object reference concept and process instances can only be referenced by untyped PIds, so this is not a problem in SDL.
In order to really specify that the objects are part of the containing object and that relations to these part objects are only meaningful in their property of being contained in this object, TIMe uses the notation in Figure 61. It is specified that a AC-System object consists of two objects (of class AccessPoints and CentralUnit), and that the environment communicates with some of these part objects. In UML the User in the environment would have associations to the class AccessPoint in general, while what we want to express is that they only have associations with AccessPoints as part of AC-System. The mapping to SDL is straight forward - here it is indicated that CentralUnit is not an object of a class but specified directly. The definition of the block type AccessPoint is left out in the mapping - it can be defined in a package or as part of the system.
The properties characterize the objects identified in the Object Modelling. It is, however, not always the case that the object model has been created before the property model. During the identification of the objects, properties become clear, and during the description of properties, the objects and their relations must be established.
The basic notation for property modelling is MSC-96. MSC highlights interaction between instances based on messages. MSC is most effective when the sequencing of messages between the acting objects is of major importance.
MSC concentrates on describing the message-sending between instances. The important invariant for messages is that a message must be sent before it is received.
Figure 63 describes a very simple interaction between a user and an access control system. The user presents the personal code to the system which then returns that the user is eligible to enter the door. The user then pushes the door open.
The instance head and instance end represent the start and end of events on the instance timeline within the MSC. The timeline of an instance contains a sequence of events.The most basic events are output and input of a message. Each message has exactly one output event and one input event. Messages are communicated between instances or between an instance and the environment. The environment is represented by the frame around the MSC diagram.
The events are ordered along each timeline, but events on different timelines are not ordered.
MSC describe communication between instances. An instance need not be a process in SDL terms. In Figure 65 we see that AC System is an SDL system.
The set of mscs that are used to describe a specific piece of reality is called an MSC document. Relations between different mscs within a MSC document are called conditions. Combining two mscs where the end condition of the first is equal to the start condition of the second is legal. Combining mscs with unequal conditions is not legal. In Figure 66 there are two conditions, Idle and Door unlocked.
The two mscs Unlocked_reset and Unlocked_timeout in Figure 67 represent alternative courses of action from the state Door Unlocked.
Coregion is a concept which is motivated by the fact that sometimes one does not care in which order a set of events occur.
In Figure 68 the User does not care whether he receives/consumes Card out or OK first.
Submsc is motivated by the need to look into an instance for more communication details. Our AC System instance obviously contains a number of "smaller" instances. The requirement analysis may want to express details about the internal behavior of the system.
When we want to define a submsc of an instance we depict that in the instance header, see Figure 69. The decomposed instance must have the same interface as given by the instance in the MSC of higher granularity.
AC System of Figure 69 states that input of Code is followed in sequence by the outputs of Card out, Ok and Unlock. To ensure this in the submsc, we sometimes have to introduce additional (pseudo) messages, see Figure 70. This is an unfortunate aspect of this mechanism.
1. Take every service of the corresponding domain model and make sure that all roles are played by objects in the design structure. Remake all domain property descriptions such that they refer to the design software structure which is preferably in SDL.
5. Use the design MSC property model as base for producing SDL process skeletons. The automatic production of skeletons can be used for discovering inconsistencies in the MSC property model. The produced skeletons should then be compared with the design object model and a complete design SDL model should be produced.
MSC is a formal language which is well suited to express cases of interaction between instances. SDL is a formal language which is well suited to express the total imperative behavior of processes one by one. The two notations have different perspectives on a system which supplement each other well.
We shall not always expect the MSC descriptions to cover all possible situations, but those situations which are covered are important. We should make sure that at least these situations are properly handled in the corresponding SDL descriptions.
TIMe provides a simple technique to produce SDL process skeletons for instances of MSCs. In order to have the produced SDL be a part of the final design it is necessary to make the MSCs so detailed that the instances of the MSCs correspond directly to processes of the SDL design. By careful use of local and global conditions in the MSCs, the SDL skeleton can be automatically derived.
From the SDL skeleton, the design process will add more behavior in order to cover all aspects of the process behavior. These supplements should not violate the behavior which was already generated in the skeleton. Since MSC does not have a formal data concept, the addition of tasks and decisions is one major activity when supplementing an SDL skeleton.