An abstract system is a system which exists in a conceptual, abstract world.
In TIMe an action is seen as an occurrence of an activity during some development process. It takes a specific state of input (a milestone) and produces a specific state of output (another milestone). The general rules and guidelines that should be followed during an action are described for the activity it is an occurrance of.
The purpose of active objects is to take care of transformations and control the 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.
The message gates are used when references to the MSC are put in a wider context in another MSC. The actual gates on the MSC reference are then connected to other message gates or instances. Similar to gate definitions, actual gates may have explicit or implicit names.
A message gate always has a name. The name can be defined explicitly by a name associated with the gate on the frame. Otherwise the name is given implicitly by the direction of the message through the gate and the message name, e.g. "in_X" for a gate receiving a message X from its environment.
All non-trivial systems are composed from components. The process of putting components together to form a whole is called aggregation. Aggregation enables us to associate a single concept and a name with a composite ../object/object. This helps to simplify matters considerably when we are dealing with the object as a whole. But to build the object and use it correctly we need to understand what it consists of.
The alt operator defines alternative executions of MSC sections. This means that if several MSC sections are meant to be alternatives only one of them will be executed. In the case where alternative MSC sections have common preamble the choice of which MSC section will be executed is performed after the execution of the common preamble.
An architecture is an abstraction of a concrete system representing:
is an aspect of a Configuration Item that gives additional information, e.g. about its functionality.
The attribute is not part of the Identification of the item.
Attributes are specified by means of a name and a type:
Click here for an example .
Attributes of objects are "value" properties that are not covered by part objects (aggregation). Attributes are defined by a name and a type. In Domain Object Models this is informally specified, but it is still worthwhile to use a type that will be defined as an attribute type or class in the Design Object Model.
For the specification of attributes in UML, see attribute specification in UML.
For the specification of attributes in SDL, see variable definition in ../SDL/SDL.
An automaton is an abstract machine which can be in a set of states . It takes a stream of input symbols . The consumed input symbol and the state together determines which actions the automaton takes. After the actions have been performed the automaton enters another state. The passage from one state through the consumption of an input symbol to another state is called a transition.
A baseline may also have a more specific definition, implying that all the configuration items included in the baseline have a certain Status.
If a class of objects has been identified as part of the object modelling, then it is possible to associate behaviour with objects of this class. If some behaviour has been identified without being associated with any object or class (but a role), then it is possible to associate it with classes later or combine it with other behaviour specifications to new roles or classes.
Depending upon the nature of the behaviour that is desirable to express, it is either expressed in terms of MSC or in fragments of SDL process graphs. The latter may be applicable if the analysis is based upon existing specifications in SDL or in case it is desirable to specify behaviour properties like "instance of type AccessPoint" shall always (that is in any state) accept a Log signal and respond to the Logger with the current status of the point".
or as a block set according to a block type.
The block set is not a reference
It designates a set of block instances.
The example here specifies a set of 100
blocks of type AccessPoint:
The block CentralUnit is defined in a separate block diagram , while the properties of the blocks in the ls block set is defined by the block type LocalStation. A block type is defined by a block type diagram. If you want to see a block type defined in terms of a substructure of blocks, look at block type diagram of AccessPoint with block substructure .
A block type diagram defines the properties of a block type .
The set of LocalStations is called ls and the number (100) designates the cardinality of the set. All the block instances within a block set typically have the same relationship with its surroundings (given by the channels).
A block set is not an array, so the thirteenth block cannot be identified by e.g. ls(13). The number of elements in a block set is determined when the system is created, all blocks in the set are created as part of the creation of the system, blocks will be permanent part (instances) of the system instance, and sets of blocks cannot be created dynamically.
Block types may contain a connectivity graph of block instances connected by channels. This makes up a structure of nested blocks. At the leaves of this structure there are blocks which contain processes. In SDL, block types may not contain both blocks and processes at the same time.
In addition to containing structures of blocks or structures of processes, block types may contain other type definitions. This makes up the scoping hierarchy of ../SDL/SDL. Names in enclosing type definitions are the only names visible.
Block types may contain data type definitions, but no variable declarations. This follows from the fact that processes in SDL do not share data other than signal queues. They share a signal queue in the way that one process appends (output) signals to the queue (the input port), while the other process consumes (input) signals from the same queue. Appending and consuming signals are atomic, non-interruptible operations. The input port is the basic synchronisation mechanism of ../SDL/SDL.
Block type s are defined in block type diagrams, and they are referenced by means of block type references. The block type reference indicates in which block or system scope unit the block type is defined.
The origin of the word is in theatres where roles are played by actors and they comprise the cast of a performance.
A channel is a one-way or two-way directed connection. It is characterised by the signals that it may carry; these constitute the signal list(s) of the channel. A channel has a signal list for each direction.
Channels connect blocks or block sets with other blocks or block sets, or with the environment of the system. It provides a (one or two way) communication path for signals. If there is no channel between two blocks, then processes in these two blocks cannot communicate by signal exchange. Processes may, however, communicate by means of remote procedure calls without channels connecting the enclosing blocks. A channel cannot connect a block or block set with itself.
Associated with each direction of a channel are the types of signals that may be conveyed by the channel. The list enclosed by the signal list symbol can be signals (as e.g. Code) or signal lists (as e.g. validity) enclosed in ().
Classes are often defined with a specific purpose in mind, and especially for the behaviour of a class (typically becoming a process type in SDL) it is necessary to know what other processes will be in the environment. This is typical for the scenario with several equally "important" objects that have to co-operate in order to do a task. It will, however, reduce the reusability of the class in other contexts where these other objects will not be. A quite different scenario is the specification of a typical "server" object class that should work in any context and where the behaviour is independent on the behaviour of the client objects.
A class definition may include a prescription of what we consider a valid instance environment. The entities and relations in the environment of a class represent roles that shall be played by actors in the environment of an instance of the class.
It covers the Application and the infrastructure functionality supporting the Application. Its behaviour is a valid model of the real behaviour and its structure is similar to the structure of physical nodes in the concrete system.
A concrete system is a real system which is part of the physical world.
A condition describes either a global system state (global condition ) referring to all instances contained in the MSC or a state referring to a subset of instances (non-global condition). In the second case the condition may be local, i.e. attached to just one instance.
A condition describes either a global system state (global condition) referring to all instances contained in the MSC or a state referring to a subset of instances (nonglobal condition). In the second case the condition may be local, i.e. attached to just one instance.
is an entity which is subjected to Configuration Management and is treated as atomic (indivisible) in this respect.
A configuration item may consist of parts, but these parts are then not managed as parts according to configuration management (e.g. a printed circuit board may be a configuration item, while the components on it are not subjected to configuration management).
A document which describes how Configuration Management shall be carried out in a project or for a product. It describes:
Objects are connected if they are involved in communication with each other. This is different from objects being related, as this will only imply that the objects may be reached by navigating along the relations.
Connections may cross object and class boundaries (see aggregation) in order to get an understanding of which part of the environment interacts with which part of the object/class.
The number of connections will follow from the number of connected objects. When the cardinalities are identical, one-to-one connections will be the normal case, giving just as many connections as there are objects on each side. When the cardinalities differ, each instance may potentially connect to all objects on the other side, giving many-to-many connections.
Examples are parts of object models with relations that may be transformed to database schemes; a subtype relation between two types in the domain object model that is transformed to the corresponding relation between the corresponding SDL process types.
The content of an object model consists of a structure of internal entities or a behaviour. The structure may be decomposed over several aggregation levels. The structural component may be instances of types defined in other object models.
The context of an object model consists of the entity being modelled, considered as a black box, and its environment, where the environment consists of other entities that are known to or that interact with the entity being modelled. This serves to describe the environment and the interfaces as well as other external relationships.
By associating property models with the context it is possible to specify the external properties that the object provides as well as the properties it requires from its environment.
Therefore a coregion is introduced for the specification of unordered events on an instance. Such a coregion in particular covers the practically important case of two or more incoming messages where the ordering of consumption may be interchanged.
A document is a piece of paper, a booklet, etc.; providing information esp. of an official nature. In TIMe Documents are physical carriers of information. This information may be local to that document, or it may be fetched from descriptions and models (whole or partial models). Documents are often made for specific occasions and audiences, e.g. a contract, a review document, a user manual.
The (problem/application) domain models a part of the real world having similar needs and terminology, and where a system instance may be a (partial) solution to some need (the problem). It is not specific to a particular system or system family, but rather to a market segment. It covers common phenomena, concepts and processes that need to be supported to solve the problem, irrespective of particular system solutions.
Note that the domain is like a type; it is a generalised concept covering the common features of many domain instances. Hence the Domain is not a set of occurrences, but a general pattern for one occurrence.
Domain Auxiliary descriptions will often be informal text and illustrations used to help reading the other Domain Descriptions .
A domain description describes a (problem/application) domain .
A Domain Dictionary is dictionary over common domain terminology.
A Domain Model is a formal definition of a Domain expressed in terms of Object Models and Property Models (collections of classes with attributes and relations and associated properties). To fully define a Domain it is possible to use Domain Models on several abstraction levels.
A Domain Statement is a concise statement about a Domain , and is normally expressed in prose.
A (problem) domain statement is a concise description of the problem domain with focus on stakeholders and their needs, the essential concepts, functions and work processes, rules and principles. It should also clearly state the nature of the problem, i.e. what one wants to achieve.
An MSC describes the communication between a number of system components, and between these components and the rest of the world, called environment . It is assumed that the environment of an MSC is capable of receiving and sending messages from and to the Message Sequence Chart; no ordering of message events within the environment is assumed. Although the behaviour of the environment is non-deterministic, it is assumed to obey the constraints given by the Message Sequence Chart.
Environment is the surroundings of an MSC. When the MSC is placed in a wider context my using MSC references, the communication with the environment from inside the MSC diagram should match the communication with the MSC reference which references it.
The instance definition provides an event description for message inputs and message outputs, actions, shared and local conditions, timer, process creation, process stop. Outside of coregions a total ordering of events is assumed along each instance-axis. Within coregions no time ordering of events is assumed.
A system family description describes a system family .
A finalised input is a redefinition of a virtual input transition that cannot be redefined in further subtypes. A virtual input is a special case of a virtual transition .
is a finalised redefinition of the corresponding virtual process type in the super block type, and it is not virtual, so that it can not be redefined in further subtypes of this block type.
For classification of concepts we have the notions of generalisation and specialisation. Generalisation is a means to focus on similarities between a number of concepts and to ignore their differences. To generalize is to form a concept that covers a number of more special concepts based on similarities of the special concepts.
The intension of the general concept is a collection of properties that are all part of the extension of the more special concepts. The extension of the general concept contains the union of the extensions of the more special concepts. The inverse mechanism is to specialise: to form a more special concept from a general one.
Note that the exact meaning of specialisation will only be given when it is applied in a formal language. When using specialisation in the domain object modelling it is recommended to use it in a way that will not be very different from the meaning in the design.
The graph describing the composition of MSCs within an HMSC is interpreted in an operational way as follows. Execution starts at the <hmsc start symbol>. Next, it continues with a node that follows one of the outgoing edges of this symbol.
is an unambiguous designation of a Configuration Item that is part of a system or product.
Implementations are detailed and precise descriptions of the hardware and the software that a concrete system is made of. They define the physical construction of systems in a system family . The software part will be expressed in programming languages such as C++ or Pascal, while the hardware part will be expressed in a mixture of hardware description languages such as circuit diagrams, cabinet layout diagrams or VHDL.
See also declarative .
NOTE: The <lost message symbol> describes the event of the output side, i.e. the solid line starts on the <message start area> where the event occurs. The optional intended target of the message can be given by an identifier associated with the symbol. The target identification should be written close to the black circle, while the message identification should be written close to the arrow.
NOTE: The <found message symbol> describes the event of the input side (the arrowhead) which should be on a <message end area>. The instance or gate which supposedly was the origin of the message is indicated by the optional identification given by the text associated with the circle of the symbol. The message identification should be written close to the arrow part.
An input allows the consumption of the specified input signal instance. The consumption of the input signal makes the information conveyed by the signal available to the process. The variables associated with the input are assigned the values conveyed by the consumed signal.
The values will be assigned to the variables from left to right. If there is no variable associated with the input for a sort specified in the signal, the value of this sort is discarded. If there is no value associated with a sort specified in the signal, the corresponding variable becomes "undefined".
The <void symbol> is a geometric point without patial extension. The <message in symbol> is actually only a point which is on the instance axis. The end of the message symbol which is the arrow head is also pointing on this point on the instance axis.
A Message Sequence Chart is composed of interacting instances of entities. An instance of an entity is an object which has the properties of this entity. Related to SDL, an entity may be an SDL-process, block or service. Within the instance heading the entity name, e.g. process name, may be specified in addition to the instance name.
An instance is an interacting entity of an MSC. Events are on instances and they are ordered according to their position on the instance from top to bottom. An instance has an instance head and an instance end or a stop. Between these there is the instance axis which may be either a single vertical line or a column defined by two vertical lines.
An instance description describes a system instance .
By a systems engineering language we mean a formal description technique (FDT). This means that not only the alphabet (notation) must be defined, but that both syntax (grammer) and semantics (meaning) of the language must be defined.
Contrast to Notation .
Some phenomena and concepts are only meaningful within the context of a specific phenomenon or concept. Localisation of definitions supports this and gives rise to nesting of definitions. Scope rules and binding rules determine how nested definitions may use entities defined in enclosing definitions.
A message exchanged between two instances can be split into two events: the message input and the message output. Messages coming from the environment are represented by a message input, messages sent to the environment by a message output. To a message, parameters may be assigned between parentheses. The declaration of the parameter list is optional for the message input.
Contrast to Methodology .
Given a model which is (typically described by automata), decide whether a given logical statement (typically describe in some temporal logic) is valid.
A methodology is a collection of methods and guidelines for when and how to use them to produce a result.
In systems engineering most results take the form of descriptions expressed using some notation or language. A systems engineering methodology therefore prescribes a set of descriptions and associated methods.
An MSC describes the communication between a number of system components, and between these components and the rest of the world, called environment. For each system component covered by an MSC there is an instance axis. The communication between system components is performed by means of messages. The sending and consumption of messages are two asynchronous events. It is assumed that the environment of an MSC is capable of receiving and sending messages from and to the Message Sequence Chart; no ordering of message events within the environment is assumed.
MSC references may not only refer to a single MSC, but also to MSC reference expressions. MSC reference expressions are textual MSC expressions constructed from the operators alt, par, seq, loop, opt, exc and subst, and MSC references.
The actual gates of the MSC reference may connect to corresponding constructs in the enclosing MSC. By corresponding constructs we mean that an actual message gate may connect to another actual message gate or to an instance or to a message gate definition of the enclosing MSC. Furthermore an actual order gate may connect to another actual order gate, or an orderable event or an order gate definition.
Total execution time is the execution time accumulated over all installations that run the same product. Thus, if one site has run the product for two months on two computers and another site has run the product for one month on one computer, the total execution time is 2 x 2 + 1 x 1 = 5 months of execution time.
Non-functional properties can be related to the handling of abstract systems, for instance that they are flexible. More often they are related to the concrete system, and express physical properties such as size, weight and temperature.
A notation is less formal than a Language , in that the syntax and/or the semantics are not formally defined.
This aspect of object modelling has to do with identification of classes without considering how many instances there will be in a given system and also without considering how they are used in the design of specific systems or other instances.
While traditional notations only represent set of objects through cardinalities of relations, an object/class in OMT+- may be defined to consist of sets of objects independent of relations, see also aggregation.
An object symbol may represent a single object or it may represent a set of objects. The text inside an object symbol consists of two parts separated by a colon. The first part, which is optional, contains a local object name followed by the number of objects. The second part contains the class name.
The number of objects in a set is specified by a low and a high limit placed inside parentheses (range). For example, (1,100) which means at least one and a maximum of 100 or (3,3) which means exactly 3. The special symbols * and + represent zero or more and one or more, respectively. If no range is specified, then a single object is specified.
The term object model is a bit misleading, as object models normally describe general types (sometimes called classes) and object sets rather than individual objects. A type is a concept. According to the classical notion of a concept, it is characterised by:
Representing concepts by types and phenomena by instances of these types follows this pattern: the instances belong to the extension, the type definition gives the intention and the type name represents the designation. The term object model as we use it in TIMe covers objects as well as types.
In TIMe, every object model should have associated property models .
The alt operator defines alternative executions of MSC sections. This means that if several MSC sections are meant to be alternatives only one of them will be executed. In the case where alternative MSC sections have common preamble the choice of which MSC section will be executed is performed after the execution of the common preamble.
The par operator defines the parallel execution of MSC sections. This means that all events within the parallel MSC sections will be executed, but the only restriction is that the event order within each section will be preserved.
The loop construct can have several forms. The most basic form is " loop <n,m> " where n and m are natural numbers. This means that the operand may be executed at least n times and at most m times. The naturals may be replaced by the keyword inf, like " loop <n,inf> ". This means that the loop will be executed at least n times. If the second operand is omitted like in " loop <n> " it is interpreted as " loop <n,n> ". Thus " loop <inf> " means an infinite loop. If the loop bounds are omitted like in "loop", it will interpreted as " loop <1,inf> ". If the first operand is greater than the second one, the loop will be executed 0 times.
The exc operator is a compact way to describe exceptional cases in an MSC. The meaning of the operator is that either the events inside the <exc inline expression symbol> are executed and then the MSC is finished or the events following the <exc inline expression symbol> are executed. The exc operator can thus be viewed as an alternative where the second operand is the entire rest of the MSC.
Stating a <process identifier> in <destination> indicates the destination as any existing instance of the set of process instances indicated by <process identifier>. If there exist no instances, the signal is discarded.
The <void symbol> is a geometric point without patial extension. The <message out symbol> is actually only a point which is on the instance axis. The end of the message symbol which has no arrow head is also on this point on the instance axis.
A package is a collection of types. A package is defined by a package diagram. Packages can be provided (that is defined) together with a system diagram (or together with another package diagram) or they can be used by means package identifiers.
A package may contain definitions of types, data generators, signal lists, remote specifications and synonyms. Definitions within a package are made visible to a system definition or other package definitions by a package-reference-clause (use clause). All (or selected) definitions of packages provided in this way will be visible in the system definition (or in the new package).
A package reference clause specifies that a system diagram or package diagram use the definitions of other packages. The names following the "/" after the package name denotes the subset of the definitions that are used. Z.100
A diagram may be split into a number of pages. In that case each page is numbered in the rightmost upper corner of the frame symbol. The page numbering consists of the page number followed by (an optional) total number of pages enclosed by (), e.g. 1 (4), 2 (4), 3 (4), 4 (4).
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.
Procedures define patterns of behaviour that processes/services may execute at several places or several times during their life-time. The behaviour of a procedure is defined in the same way as for processes (that is by means of states and transitions), a procedure may have (local) variables, and in addition it may have IN, OUT, IN/OUT parameters.
where <data-type-identifier> gives the data type of the value returned by the procedure. The optional <variable-name> can be used to name the result. The result can either be stated as an expression next to the return symbol, or as an assignment in a task to the variable introduced in result.
A procedure reference specifies that there is a procedure in the enclosing entity and that the properties of this procedure are defined in a separate (referenced) procedure diagram outside this diagram.
a process is:
6. a series of actions which produce a change or development;
In TIMe a process is an ordered series of actions that produce change or development of descriptions and systems. The particular states of descriptions and systems that are produces are called milestones, and the periods of time when they are developed are called phases. Hence a process is an ordered series of actions and milestones related to phases.
Each process consists of the input port and an extended finite state machine (EFSM) with a sequential behaviour defined by a process graph, which is a sort of state transition diagram. The finite state machine fetches signals from the input port in strict FIFO order except when the order is modified by the save operator (see below). For each signal it performs one transition which will take a short but undefined time.
Signals are messages that the finite state machine consumes. Each signal has a signal type identification which the FSM uses to select the next transition action. In addition, the signal carries the sender identity and possibly some additional data.
The behaviour of processes may be defined either by means of a procedure graph (states and transitions) or by means of a substructure of services connected by signal routes. The behaviour of each of the services is defined by means of states and transitions.
A process set defines a set of processes according to a process type .
Just like we have the distinction between block reference, block type and block set according to type, we have the distinction between process reference, process type and process set according to a type. Our recommendation is that process sets should be described with reference to a process type.
This is both a specification of a process set as part of the enclosing block and a reference to the corresponding process diagram , which defines the properties of the processes in the set.
The numbers in parentheses after the process set name specify the number of instances in the process set. As defined in above, there are initially no processes, and there is no limit on the number of instances that may be created.
A process type diagram defines the properties of a process type .
The heading of process diagrams (defining a process set directly without any process type) is a <process heading>, defining the name of the process set and the initial/maximum number of instances in the set.
The heading of process type diagrams is a <process type heading>, defining the name of the process type, its virtuality (and constraint), its formal context parameters and if it inherits from another process type.
A proof is a systematic sequence of statements aimed at establishing the truth of some given sentence. A proof is often supported by mathematical notation, and based upon formal inference rules. Proofs may also be performed automatically by a computer program, or semi-automatically by the use of proof assistants.
Properties are not components that can be used to build systems . They are measures we use to characterise and evaluate systems by. Let us compare to a brick: the brick itself is an object we can use to build something with (e.g. a fireplace), its physical measures are properties we may use to select the particular type of brick and to plan the fireplace, but not to build with. Thus, properties are not components to be used in constructions, but means to understand, select and plan constructions.
A property model is a model that states properties of a system , a component or a single object without prescribing a particular construction. Property models are not constructive, but used to characterise an entity from the outside. There are many kinds of properties: behaviour properties, performance properties, maintenance properties, etc. This is the perspective preferred by users and sales persons. It is also the main perspective in specifications.
Property oriented development is at a higher process maturity level than Design oriented development .
is a redefinition of the corresponding virtual process type in the super block type, and it is virtual, so that it can be redefined in further subtypes of this block type.
MSC references may not only refer to a single MSC, but also to MSC reference expressions. MSC reference expressions are textual MSC expressions constructed from the operators alt , par , seq , loop , opt , exc and subst , and MSC references.
The alt , par , loop , opt and exc operators are described in definition of operator . The seq operator denotes the weak sequencing operation where only events on the same instance are ordered.
This is the form of aggregation where the part objects are just related to the composite object with a special relation, but still just a relation. This is the only form of aggregation supported by pure OMT.
A relation represents application specific relationships between objects of the involved classes. Instances of a relation are called links and consist of tuples of object references. Structural "relations" such as subclass-of and part-of are not regarded as relations, but as separate constructs.
Relations can be used either as the basis for automatic generation of the corresponding part of functional design (e.g. a database part of the design) - that is as constructive parts of the conceptual model, or as illustrations of properties that will be "implemented" in some way in the design.
When defining an object/class by means of aggregation, we may in some case need to express that there are relations to the objects/object sets comprising the aggregation. The same symbols as for relations with classes as endpoints are used, but the semantics is different: the set denoted by the relation is a subset of the related object (set). See also relation aggregation and real aggregation.
The probability that the software will not cause the failure of a system for a specified time under specified conditions. The probability is a function of the inputs to and the use of the system as well as a function of the existence of faults in the software.
1. The exporting of a procedure . A procedure which is made visible by other processes is marked with the keyword exported preceding the procedure heading, e.g. "exported procedure Validate ..." from a process within the CentralUnit. The exporting process can control in which states it will accept the remote request. It may also specify to save the request to other states. The controlling of the acceptance is done by using input and save symbols with the remote procedure name preceded by the keyword procedure.
2. The importing of a procedure . When a process, service or procedure wants to import a remote procedure, it must specify the signature of this procedure in an "imported procedure specification" in a text area. The specification in our case would read: "imported procedure Validate; returns integer;" where the integer returned would give the result of the validation.
3. The specification of remote procedure . In SDL all names must be defined in a specific scope. Thus, the names of remote procedures must be defined in the context in which the actual definition of the procedure and the calls will be contained. In our case the definition of the procedure Validate is within the CentralUnit and the call is in Controller of the AccessPoint. The scope unit enclosing all these is the system itself. There we will find a text area with the following text: "remote procedure Validate; returns integer;".
4. The calling of a remote procedure . The calling of the remote procedure is indistinguishable from local procedure calls unless the caller explicitly states which process it will request the procedure executed by. This can be done by a to-clause with a PId following the procedure name of the call.
Remote procedures may be value returning (as in our example above) and they may be virtual. Z.100
· If an <msc reference> is immediately preceded by a <condition symbol>, with an associated set of <condition name>s, then this set must be a subset of the set of initial conditions of the <msc ref expression> associated with the <msc reference>.
· If an <msc reference> is immediately followed by a <condition symbol>, with an associated set of <condition name>s, then this set must be a subset of the set of final conditions of the <msc ref expression> associated with the <msc reference>.
· If an <par expr area> is immediately preceded by a <condition symbol>, with an associated set of <condition name>s, then this set must be a subset of the set of initial conditions of the <par expr area>.
· If an <par expr area> is immediately followed by a <condition symbol>, with an associated set of <condition name>s, then this set must be a subset of the set of final conditions of the <par expr area>.
A return represents the the completion of a call of a procedure .
is a Version of a component that is derived from an earlier version, and that is designed to replace the earlier version. The difference between two succeeding revision is usually a "small" improvement (error correction or enhancement in functionality). The latest revision is the version one intends should be used ("latest and greatest").
Roles are used to describe properties, and are related to object designs by projection. Roles are used to link properties and objects. Projections are used for synthesis of new objects and for documenting existing objects.
A service is a state machine being part of a process instance, and cannot be addressed as a separate objects. It shares the input port and the expressions self, parent, offspring and sender of the process instance.
Only one service at a time is executing a transition. Services alternate based on signals in the input port of the process .
A signal definition defines a set of types of signals. Signal definitions are part of text symbols .
Signals may be defined in system and block diagrams, and these may then be used for communication between the blocks of the system or the processes of the block. Signals may also be defined in process (type) diagrams, but then they can only be used for communication between processes of the same set. Often signal definitions are collected in packages.
virtual is used when a type is introduced as a virtual type. A virtual type must be a type defined locally to another type; the implication is that it can be redefined in types that inherit from the enclosing type.redefined is used when the redefinition of a virtual type is still virtual. finalized is used when the redefinition is not virtual.
A box with a single name specifies a class. The class will most probably be defined in more details in other diagrams, but its involvement in relations may e.g. be described by just using a box with the class name.
The fact that the classes SimpleAP, LoggingAP and BlockingAP are specialisations of AccessPoint may either be specified as below, or as part of the heading of the single classes.
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 it may be included in the specification. Specifications are associated with the abstractions they belong to.
There is only one start symbol for a process. The transition from the start takes place when the process is generated. A process may be generated either at system start-up or as a result of a create request from another process.
A state represents a particular condition in which a process may consume a signal resulting in a transition. If the state has neither spontaneous transitions nor continuous signals, and there are no signal instances in the input port, otherwise than those mentioned in a save, then the process waits in the state until a signal instance is received.
A system state is normally used for the state of a whole system. A process state or basic state refers to a state in the finite set of defined, named states in an SDL process (or equivalent). A complete state of an SDL process will include values of all local variables and the value of the input port and save queue.
As apposed to the Identification of the item, the status will change.
These are entities that are subject to manipulation, representation or control in the Domain . They may be materials in the case of a material transformation domain, e.g. moulding, or they may be entities represented in an information system, e.g. flights and seats, or they may be controlled machinery, e.g. a paper mill.
A sub MSC essentially has a structure analogous to an MSC. It is distinguished from the MSC by the keyword submsc . Characteristic for a sub MSC is its relation to a decomposed instance containing the keyword decomposed and having the same name as the sub MSC. The relation is provided by the messages connected to the exterior of the sub MSC and the corresponding messages sent and consumed by the decomposed instance.
In TIMe, synthesis is an activity that produces a design from a specification .
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. TIMe 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 TIMe. Design with reuse involves:
A system is a part of the world that a person or group of persons during some time interval and for some purpose choose to regard as a whole. A system consists of interrelated components, each component being characterised by properties that are selected as being relevant to the purpose.
The System family contains generalised system and component concepts that can be adapted (configurated) and instantiated to fit into a suitable range of user environments. They represent the product base from which a company can make a business out of producing and selling system instances .
In TIMe, system families are formally defined as (collections of) types or classes. Where practical, system types/classes will be defined from which complete system instances may be generated. In addition the system family contains the component types/classes that are used to compose the system types/classes.
The system family statement is a concise description of the system family with emphasis on specifications , i.e. the external properties.
A system instance is a (real) system which can perfom behaviour and provide services.
The system instance area of concern contains system instances produced from system families .
The heading of system diagrams, that is a system-heading is as follows:
A task is part of a transition .
The text symbol is also used for the graphical representation of a use clause, see package .
No global time axis is assumed for one Message Sequence Chart. Along each instance axis the time is running from top to bottom, however, we do not assume a proper time scale. If no coregion is introduced a total time ordering of events is assumed along each instance axis.
The notion of timers provides a mechanism for specifying time-related matters. Timers are just like alarm clocks. The process waiting for a timer is passively waiting since the process needs not sample them. Timers will issue time-out signals when their time is reached. There may well be several different timers active at the same time. Active timers do not affect the behaviour of the process until the timer signal is consumed by the process.
Timers are set and reset in tasks . When a timer has not been set, it is inactive. When it is set, it becomes active.
A timer is set with a time value. time is a special data type and is mainly used in connection with timers. The expression "now+10" is a time value and it adds the time expression now and the duration 10 (here: seconds). now is an operator of the time data type and it returns the current real time. Duration is another special data type and it is also mainly used in connection with timers. You may add or subtract duration to time and get time. You may divide or multiply duration by a real and get duration. You may subtract a time value from another time value and get duration.
The semantics of timers is this: a time value is set in a timer and it becomes active. When the time is reached, a signal with the same name as the timer itself will be sent to the process itself. Then the timer becomes inactive.
A timer may be reset and it then becomes inactive and no signal will be issued. (If an inactive timer is reset, then it remains inactive.) A reset will also remove a timer signal instance already in the input port. This happens when the timer has expired, but the time-out signal has not been consumed.
If an active Timer is set, the time value associated with the timer receives a new value. The timer is still active. If a timer is set to a time which is already passed, the timer will immediately issue the time-out signal.
Timer signals may contain data as other signals may contain data. Different parameter values in set means generation of several timer instances. reset must match these parameter values to eliminate the correct timer instance.
The Jante Law (Janteloven) is from the novel "En flygtning krysser sitt spor" (`A refugee crosses his tracks') by the Norwegian/Danish author Aksel Sandemose. The book takes place in an imaginary Danish small town called Jante, based on Sandemose's hometown Nykøbing Mors. The book is about the ugly sides of Scandinavian smalltown mentality, and the term has come to mean the unspoken rules and jealousy of such communities in general.
These are entities representing transactions or events in the dynamic behaviour of the Domain , e.g. the purchase of a car, or a user passing a door.
is a Version of a component that is designed to co-exist in parallel with other versions of a component, as an alternative. One variant of a component is seldom "better" than another, but offers different alternative functionality (e.g. for different computer platforms).
A virtual process type is a process type that can be redefined in a subtype of the enclosing block type.
The virtuality is specified in the process type heading or by < virtuality > in the corresponding process type reference symbol.
The virtuality of a type defines whether the type is virtual (so that it can be redefined in a subtype of the enclosing type), redefined (a redefined type, but still virtual), or finalised, that a redefinition that cannot be further redefined.
The implication of a constraint is that a redefined or finalized definition of the virtual type must be a type definition that inherits from the constraint type. In case of no constraint specified, the definition of the virtual type itself is the constraint.