background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 1/23
Meta model SAM
1.2
Authors
Guillaume Jolly
Summary
This document exposes the SAM functionnal partitionning used by Airbus,
currently with the Sildex tool, to modelize a system.
Each concept is first presented with its model and then the metamodel
corresponding.
Disclaimer : Contractors participating to this report shall incur no liability whatsoever for
any damage or loss which may result from the use or exploitation of information and/or
Rights contained in this report.
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 2/23
Table of Contents
1 Preface.............................................................................................................................. 4
1.1 Table of versions........................................................................................................ 4
1.2 Table of references and applicable documents............................................................. 4
1.3 Table of abbreviations................................................................................................ 4
1.4 Glossary..................................................................................................................... 4
2 Goal of this document......................................................................................................... 5
3 Modelisation and metamodel.............................................................................................. 6
3.1 Model to be metamodelised....................................................................................... 6
3.2 Representation of a function or a subsystem................................................................ 6
3.2.1 Model................................................................................................................ 6
3.2.2 Metamodel......................................................................................................... 6
3.2.2.1 Schema...................................................................................................... 6
3.2.2.2 Class definitions and OCL rules.................................................................. 6
3.3 Representation of the control and data flows................................................................ 6
3.3.1 model.................................................................................................................. 6
3.3.2 Metamodel.......................................................................................................... 8
3.3.2.1 Schema....................................................................................................... 8
3.3.2.2 Class definitions and OCL rules.................................................................. 8
3.4 Representation of the data range............................................................................... 10
3.5 Representation of the data storage............................................................................. 10
3.5.1 Model................................................................................................................ 10
3.5.2 Metamodel........................................................................................................ 11
3.5.2.1 Schema..................................................................................................... 11
3.5.2.2 Class definitions and OCL rules................................................................ 11
3.6 Representation of flow composition/decomposition.................................................... 12
3.6.1 Model................................................................................................................ 12
3.6.2 Metamodel........................................................................................................ 12
3.6.2.1 Schema..................................................................................................... 12
3.6.2.2 Class definitions and OCL rules................................................................ 13
3.7 Representation of an automaton subset..................................................................... 14
3.7.1 Model................................................................................................................ 14
3.7.2 Metamodel........................................................................................................ 16
3.7.2.1 Schema..................................................................................................... 16
3.7.2.2 Class definitions and OCL rules................................................................ 16
4 Metamodel overview....................................................................................................... 18
Index of Illustrations
Illustration 1 Function, subsystem model
6
Illustration 2 Function, subsystem metamodel 6
Illustration 3 Flows and ports model
7
Illustration 4 Special ports model 7
Illustration 5 Flows and port metamodel
8
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 3/23
Illustration 6 Datastore model
10
Illustration 7 Datastore metamodel
11
Illustration 8 Flow composition model
12
Illustration 9 Flow decomposition model
12
Illustration 10 Flow composition/decomposition metamodel 13
Illustration 11 Automaton model 14
Illustration 12 Automaton set model
15
Illustration 13 Automaton set metamodel
16
Illustration 14 Model root meta model
18
Illustration 15 Metamodel overview
18
Illustration 16 Attributes generalization meta model 19
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 4/23
1 Preface
1.1 Table of versions
Version
Date
Description & rationale of
modifications
Sections modified
version 1.0
25/11/04 Creation on the document
Whole document
version 1.1
24/02/05 Update of the meta model
Metamodel sections
version 1.2
14/12/05 Update of the meta model (MultiPort
and Automaton)
§3.3.2, §3.5.2,
§3.7.2, §4
1.2 Table of references and applicable documents
Reference
Title & edition
Author or editor
Year
1.3 Table of abbreviations
Abbreviation
Description
1.4 Glossary
Term
Description
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 5/23
2 Goal of this document
The goal of this document is to expose the metamodel of the SAM functional partitionning
through the different phases of the modelisation definition.
The metamodel presented here id a little different from the metamodel used by the Sildex
tool to produce SAM models.
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 6/23
3 Modelisation and metamodel
3.1 Model to be metamodelised
The metamodelisatoin is about the SAM models as defined by Airbus functionnal
partitionning. It does not use the Sildex representation.
3.2 Representation of a function or a subsystem
3.2.1 Model
A function is a simple subsystem composed of no element.
The system is the same as a subsystem but contained by no other subsytem.
3.2.2 Metamodel
3.2.2.1 Schema
3.2.2.2 Class definitions and OCL rules
·
System:
This class represent either the system to modelize or the subsystems it is composed of.
A simple function will be represented as a system composed of no component.
A function or a subsystem consume inputs and produce outputs which are of the type data
flow or control flow.
3.3 Representation of the control and data flows
3.3.1 model
12/14/2005
Illustration 1 Function,
subsystem model
Illustration 2 Function,
subsystem metamodel
System
(f rom SAM)
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 7/23
Special consideration :
The name of a data flow starts with FD_ .
The name of a control flow starts with FC_ .
Special consideration :
Sildex offer the possibility to group some flows to simplify the visual aspect, via the Sildex
port notion. A port can group bi-directionnal flows. In the previous schema, the m port is
an exemple, it is represented by the black square symbol.
12/14/2005
Illustration 3 Flows and ports model
Illustration 4 Special ports model
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 8/23
3.3.2 Metamodel
3.3.2.1 Schema
3.3.2.2 Class definitions and OCL rules
·
Model
This class represent the root of the global model.
There is only one instance of this element for each model.
12/14/2005
Illustration 5 Flows and port metamodel
OutDataPort
(from SAM)
OutControlPort
(from SAM)
InDataPort
(from SAM)
InControlPort
(from SAM)
OutputPort
(from SAM)
InputPort
(from SAM)
DataPort
(from SAM)
DataFlow
type : DataType
(from SAM)
1..n
+dest
1..n
1
+source
1
ControlPort
(from SAM)
ControlFlow
(from SAM)
1..n
+dest
1..n
1+source
1
Flow
(from SAM)
Model
System
(from SAM)
1
0..n
+parentSystem
1
+listFlows
0..n
If the system has sub elements, its inports must have
outlinks and its outports must have inlinks.
==>
inv :
if System.listElements->size>0 then
System.listPorts->forAll(p : InPort | p.outlink->size = 1)
and
System.listPorts->forAll(p : OutPort | p.inlink->size = 1)
endif
Port
(from SAM)
0..1
+outlink
0..1
0..1
+inlink
0..1
0..1
0..n
+parentSystem
0..1
+listPorts
0..n
MultiPort
(from SAM)
0..1
1..n
+parentMultiPort
+listPort
1..n
ModelContent
0..1
1
+parentModel
0..1
+modelContent
1
0..1
0..n
+parentSystem 0..1
+listElements
0..n
+listMultiPort
+parent 1
0..n
1
0..n
0..1
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 9/23
·
ModelContent
This class is abstract and represents teh different kinds of elements that can be the first
element of the model.
·
System
If the system has sub elements, its inports must have outlinks and its outports must
have inlinks.
==>
inv :
if System.listElements->size>0 then
System.listPorts->forAll(p : InPort | p.outlink->size = 1) and
System.listPorts->forAll(p : OutPort | p.inlink->size = 1)
endif
·
Port
This represents a port allowing to the component containing it to received information.
·
InputPort
This class represents a kind of port.
It allows a data flow to bring some data into the component containing this port.
·
InDataPort
This class represents a kind of port.
It allows a data flow to bring some data into the component containing this port.
·
InControlPort
This class represents a kind of port.
It allows a control flow to bring control information into the component containing this
port.
·
OutputPort
This represents a port allowing to the component containing it to output information.
·
OutDataPort
This class represents a kind of port.
It allows the component containing it to output some data in a data flow.
·
OutControlPort
This class represents a kind of port.
It allows the component containing it to output control information in a control flow.
·
DataPort
This represents a port allowing to the component containing it to receive or emit a data
flow.
·
ControlPort
This represents a port allowing to the component containing it to receive or emit a
control flow.
·
MultiPort
This is a special kind of port. It is an artifact used to group ports together. It is
composed of any kind and any number of ports that are semantically linked in the
model.
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 10/23
·
Flow
A flow is a link between 2 components used to communicate.
·
DataFlow
A data flow is a flow carrying data between systems or to an automaton.
It cannot come from an autumaton.
the Data can be stored, or retrieve, into, or from, a data store, and composed into one
or decomposed from one data flow.
This class represent the link used to give data between 2 components.
·
ControlFlow
A control flow is a flow carrying control messages to between systems or automatons.
This class represent the link used for control purpose between 2 components.
3.4 Representation of the data range
A data incoming from the upper/surrounding level appear at the border of the function
representation. (see figure of the 3.5 §)
3.5 Representation of the data storage
3.5.1 Model
The data storage is graphically represented by the data_store symbol.
For graphical constraints, this symbol is divided inty 2: data_store_g(entry to the left) or
data_store_d-entry to the right.
The storage allows asynchroneous access the the data.
12/14/2005
Illustration 6 Datastore model
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 11/23
3.5.2 Metamodel
3.5.2.1 Schema
3.5.2.2 Class definitions and OCL rules
·
DataStore
A data store is a component used to store data that can be retrieved later.
This class represent a general data store, not specifying where the entry point is.
·
Automaton
This class represents an automaton component, consisting of a set of states linked by
12/14/2005
Illustration 7 Datastore metamodel
InputPort
(from SAM)
OutputPort
(from SAM)
DataPort
(from SAM)
DataFlow
type : DataType
(from SAM)
1..n
+dest
1..n
1
+source
1
ControlPort
(from SAM)
ControlFlow
(from SAM)
1..n
+dest
1..n
1
+source
1
InControlPort
(from SAM)
OutControlPort
(from SAM)
Model
Flow
(from SAM)
ModelContent
0..1
1
+parentModel
0..1
+modelContent
1
System
(from SAM)
1
0..n
+parentSystem
1
+listFlows
0..n
0..1
0..n
+parentSystem
0..1
+listElements
0..n
InDataPort
(from SAM)
DataStore
(from SAM)
1
0..n
+parentSystem
1
+listStores
0..n
0..1
1
+parentDataStore
0..1
+in 1
OutDataPort
(from SAM)
0..1
1
+parentDataStore
0..1
+out
1
Port
(from SAM)
0..1
+outlink
0..1
0..1
+inlink
0..1
0..1
0..n
+parentSystem
0..1
+listPorts
0..n
Automaton
(from SAM)
+listPorts
+parentAutomaton
0..1
0..n
0..1
0..n
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 12/23
transitions.
An automaton cannot produce data, but it can output its current state, so only one
OutDataPort is possible.
3.6 Representation of flow composition/decomposition
3.6.1 Model
A composed flow cannot be a component of a greater composed flow.
There is no limit to the number of component in a flow.
Some component from a decomposed flow may be omitted.
3.6.2 Metamodel
3.6.2.1 Schema
12/14/2005
Illustration 8 Flow composition model
Illustration 9 Flow decomposition model
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 13/23
3.6.2.2 Class definitions and OCL rules
·
System
OCL:
If the system has subsystems or automatons, its inports must have outlinks and its
outports must have inlinks.
If the system doesn't have any subsystem or automaton, then there can't be any
synchronisation or data store either.
==>
inv :
if System.listElements->size>0 then
System.listPorts->forAll(p : InPort | p.outlink->size = 1) and
System.listPorts->forAll(p : OutPort | p.inlink->size = 1)
else
System.listSynchronisation->size=0 and System.listStores->size=0 and
System.listPorts->forAll(p : InPort | p.outlink->size = 0) and
System.listPorts->forAll(p : OutPort | p.inlink->size = 0)
endif
·
FlowSynchronisation
12/14/2005
Illustration 10 Flow composition/decomposition metamodel
InputPort
(from SAM)
Composition
(from SAM)
Decomposition
(from SAM)
A decomposition is made of one
inPort and multiple outPorts
OCL
inv :
in->size=1 and out->size>1
A composition is made of one
outPort and multiple inPorts
OCL
inv :
in->size>1 and out->size=1
OutputPort
(from SAM)
DataPort
(from SAM)
DataFlow
type : DataType
(from SAM)
1..n
+dest
1..n
1
+source
1
If a system doesn't have any sub elements, it can't have any
synchronisation gate or data store.
OCL
inv:
if System.listElements->size=0 then
System.listSynchronisation->size=0 and System.listStores->size = 0
endif
InDataPort
(from SAM)
OutDataPort
(from SAM)
SynchronisationGate
(from SAM)
0..1
1..n
+parentSync
+in
1..n
0..1
1..n
+parentSync
+out
1..n
Port
(from SAM)
System
(from SAM)
1
0..n
+parentSystem
+listSynchronisation
0..n
0..1
0..n
+parentSystem 0..1
+listPorts 0..n
Flow
(from SAM)
0..1
+outlink
0..1
0..1
+inlink
0..1
1
0..n
+parentSystem
1
+listFlows
0..n
1
0..1
0..1
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 14/23
A flow synchronisation, represented with a bar, is a way to group or split data with
several data flow.
One flow contain all the data, and the other flows a part of this data only.
·
Composition
A composition is a flow synchronisation used to group several flow into one.
OCL:
A composition is made of one outPort and multiple inPorts
==>
inv :
Composition.in->size>1 and
Composition.out->size=1
·
Decomposition
A decomposition is a flow synchronisation used to make several flow from a single flow.
Each flow "produced" by the decomposition is a part of the original flow.
This is not used to have several destination for one flow, by to split the data contained
by the original flow.
OCL:
A decomposition is made of one inPort and multiple outPorts
==>
inv :
Decomposition.in->size=1 and
Decomposition.out->size>1
3.7 Representation of an automaton subset
3.7.1 Model
An automaton subsystem consume mainly control flow entries and produce only control
flow exits/outputs.
An automaton include one intial state (the state 1 in the exemple). The transition from one
state to another is described by a couple (? event/condition on the entries -! emission of
an exit/output). If several transitions leave the same state, they have to be ordered by a
number.
12/14/2005
Illustration 11
Automaton model
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 15/23
12/14/2005
Illustration 12 Automaton set model
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 16/23
3.7.2 Metamodel
3.7.2.1 Schema
3.7.2.2 Class definitions and OCL rules
·
Automaton
OCL:
The automaton inports don't have any outlink and the outports don't have inlinks.
==>
inv :
listPorts->select(port Port | port.oclIsKindOf(InPort))->forAll(port : InPort | port.outlink-
>size=0)
and listPorts->select(port Port | port.oclIsKindOf(OutPort))->forAll(port : OutPort |
12/14/2005
Illustration 13 Automaton set metamodel
The automaton inports don't have any outlink and the outports don't have inlinks.
OCL :
inv :
listPorts->select(port Port | port.oclIsKindOf(InPort))->forAll(port InPort |
port.outlink->size=0) and listPorts->select(port Port |
port.oclIsKindOf(OutPort))->forAll(port OutPort | port.inlink->size=0)
Each priority is unique if there are multiple
outlink
OCL :
inv :
let : priorityBag : Bag=outlink.priority
let : prioritySet : Set=outlink.priority->asSet
in
priorityBag->size = prioritySet->size
Only one state can be initial
OCL
inv :
listStates->select(AbstractState s | s.oclIsTypeOf(InitialState) )->size=1
InitialState
(from SAM)
MacroState
(from SAM)
State
(from SAM)
AbstractState
(from SAM)
0..n
0..1
+composition
0..n
+parentState
0..1
Transition
condition : String
emission : String
priority : Integer
(from SAM)
1
0..n
+dest 1
+inlink 0..n
1
0..n
+source 1
+outlink
0..n
Automaton
(from SAM)
0..1
1..n
+parentAutomaton 0..1
+listStates
1..n
1
0..n
+parentAutomaton
1
+listTransitions
0..n
Port
(from SAM)
0..1
0..n
+parentAutomaton
0..1
+listPorts
0..n
The allowed outDataPorts are one with integer type, and boolean for any other
port.
OCL :
inv :
listPorts->select(x : Port | x.oclIsTypeOf(OutDataPorts))
->select(x : OutDataPort | x.type = DataType.Integer)->size() <2
end listPorts->select(x : Port | x.oclIsTypeOf(OutDataPorts))
->forAll(x : OutDataPort | x.type = DataType.Integer or x.type =
DataType.Boolean)
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 17/23
port.inlink->size=0)
OCL:
Only one state per automaton can be initial
==>
inv :
Automaton.listStates->select(AbstractState s | s.oclIsTypeOf(InitialState) )->size=1
OCL:
The allowed outDataPorts are one with integer type, and boolean for any other port.
==>
inv :
listPorts->select(x : Port | x.oclIsTypeOf(OutDataPorts))
->select(x : OutDataPort | x.type = DataType.Integer)->size() <2
and listPorts->select(x : Port | x.oclIsTypeOf(OutDataPorts))
->forAll(x : OutDataPort | x.type = DataType.Integer or x.type = DataType.Boolean)
·
AbstractState
Abstraction of the states that can be contained by an Automaton.
OCL:
Each priority is unique if there are multiple outlink
==>
inv :
let : priorityBag : Bag=State.outlink.priority
let : prioritySet : Set=State.outlink.priority->asSet
in
priorityBag->size = prioritySet->size
·
MacroState
Due to the fact a MacroState cannot have inlinks, it cannot be a directly State.
Furthermore, a macrostate can be composed of states.
·
State
A state represents the way of functionning of an automaton.
One of the states of the automaton is the initial state.
The states are linked by transition with a condition and possibly a priority if several
transition goes from the same state.
·
Transition
A transition represents the link between 2 states of an automaton.
The condition attribute represents the event/condition string.
The priority is used only is there are multiple link outgoing from one state.
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 18/23
4 Metamodel overview
12/14/2005
Illustration 15 Metamodel overview
Illustration 14 Model root meta model
Automat
on
Model
System
MultiPort
ModelContent
1
0..1
+modelContent
1
+parentModel
0..1
0..n
0..1
+listElements
0..n
+parentSystem
0..1
0..n
1
+listMultiPort
0..n
+parent
1
MacroState
Decompo
sition
InputPort
OutputPort
InitialState
Composi
tion
ControlPort
ControlFlow
1
+source
1
1..n
+dest
1..n
DataPort
DataFlow
type : DataType
1
+source
1
1..n
+dest
1..n
DataType
Integer
Real
Float
Double
Boolean
<<enumeration>>
InControlPort
OutControlPort
InDataPort
OutDataPort
SynchronisationGate
0..1
1..n
+parentSync
0..1
+in
1..n
0..1
1..n
+parentSync
0..1
+out
1..n
DataStore
0..1
1
+parentDataStore
0..1
+in
1
0..1
1
+parentDataStore
0..1
+out
1
State
AbstractState
0..1
0..n
+parentState
0..1
+composition
0..n
Transition
condition : String
emission : String
priority : Integer
0..n
1
+outlink
0..n
+source
1
1
0..n
+dest 1
+inlink
0..n
Flow
System
0..n
1
+listFlows
0..n
+parentSystem 1
0..n
1
+listSynchronisation
0..n
+parentSystem
1
1
0..n
+parentSystem
1
+listStores
0..n
MultiPort
Automaton
0..1
1..n
+parentAutomaton
0..1
+listStates
1..n
0..n
1
+listTransitions
0..n
+parentAutomaton
1
Port
0..1
+outlink
0..1
0..1
+inlink
0..1
0..1
0..n
+parentSystem
0..1
+listPorts
0..n
0..1
1..n
+parentMultiPort
+listPort
1..n
0..1
0..n
+parentAutomaton
0..1
+listPorts
0..n
0..1
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 19/23
Classes definitions and OCL rules :
·
AbstractState:
Abstraction of the states that can be contained by an Automaton.
OCL:
Each priority is unique if there are multiple outlink
==>
inv :
let : priorityBag : Bag=State.outlink.priority
let : prioritySet : Set=State.outlink.priority->asSet
in
priorityBag->size = prioritySet->size
·
Automaton:
This class represents an automaton component, consisting of a set of states linked by
transitions.
An automaton cannot produce data, so there is no output data port.
OCL:
The automaton inports don't have any outlink and the outports don't have inlinks.
==>
inv :
listPorts->select(port Port | port.oclIsKindOf(InPort))->forAll(port : InPort | port.outlink-
>size=0)
and listPorts->select(port Port | port.oclIsKindOf(OutPort))->forAll(port : OutPort |
port.inlink->size=0)
12/14/2005
Illustration 16 Attributes generalization meta model
IdentifiedItem
comment : String
requirements : String
NamedItem
name : String
Flow
Abstract
State
Transition
SynchronisationGate
DataStore
Port
ModelCo
ntent
MultiPort
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 20/23
OCL:
Only one state per automaton can be initial
==>
inv :
Automaton.listStates->select(AbstractState s | s.oclIsTypeOf(InitialState) )->size=1
OCL:
The allowed outDataPorts are one with integer type, and boolean for any other port.
==>
inv :
listPorts->select(x : Port | x.oclIsTypeOf(OutDataPorts))
->select(x : OutDataPort | x.type = DataType.Integer)->size() <2
and listPorts->select(x : Port | x.oclIsTypeOf(OutDataPorts))
->forAll(x : OutDataPort | x.type = DataType.Integer or x.type = DataType.Boolean)
·
Composition:
A composition is a flow synchronisation used to group several flow into one.
OCL:
A composition is made of one outPort and multiple inPorts
==>
inv :
Composition.in->size>1 and
Composition.out->size=1
·
ControlFlow:
A control flow is a flow carrying control messages to between systems or automatons.
This class represent the link used for control purpose between 2 components.
·
ControlPort
This represents a port allowing to the component containing it to receive or emit a
control flow.
·
DataFlow:
A data flow is a flow carrying data between systems or to an automaton.
It cannot come from an autumaton.
the Data can be stored, or retrieve, into, or from, a data store, and composed into one
or decomposed from one data flow.
This class represent the link used to give data between 2 components.
·
DataPort:
This represents a port allowing to the component containing it to receive or emit a data
flow.
·
DataStore:
A data store is a component used to store data that can be retrieved later.
This class represent a general data store, not precising where the entry point is.
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 21/23
·
Decomposition:
A decomposition is a flow synchronisation used to make several flow from a single flow.
Each flow "produced" by the decomposition is a part of the original flow.
This is not used to have several destination for one flow, by to split the data contained
by the original flow.
OCL:
A decomposition is made of one inPort and multiple outPorts
==>
inv :
Decomposition.in->size=1 and
Decomposition.out->size>1
·
Flow:
A flow is a link between 2 components used to communicate.
·
FlowSynchronisatrion:
A flow synchronisation, represented with a bar, is a way to group or split data with
several data flow.
One flow contain all the data, and the other flows a part of this data only.
·
IdentifiedItem:
This abstract class represent any item that is unique, so possesses a unique identifier.
Each of these items can be commented ou have requirements.
·
InControlPort:
This class represents a kind of port.
It allows a control flow to bring control information into the component containing this
port.
·
InDataPort:
This class represents a kind of port.
It allows a data flow to bring some data into the component containing this port.
·
InputPort:
This represents a port allowing to the component containing it to received information.
·
MacroState:
Due to the fact a MacroState cannot have inlinks, it cannot be a directly State.
Furthermore, a macrostate can be composed of states.
·
Model:
This class represent the root of the global model.
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 22/23
There is only one instance of this element for each model.
·
ModelContent:
This class is abstract and represents the different kinds of elements that can be the first
element of the model.
·
MultiPort:
This is a special kind of port. It is an artifact used to group ports together. It is
composed of any kind and any number of ports that are semantically linked in the
model.
·
NamedItem:
This abstract class represent any item that can be named.
·
OutControlPort:
This class represents a kind of port.
It allows the component containing it to output control information in a control flow.
·
OutDataPort:
This class represents a kind of port.
It allows the component containing it to output some data in a data flow.
·
OutPort:
This represents a port allowing to the component containing it to output information.
·
Port:
This class represents the generalization of the different kind of ports.
A port allows the input or output of information in or from components.
·
State:
A state represents the way of functionning of an automaton.
One of the states of the automaton is the initial state.
The states are linked by transition with a condition and possibly a priority if several
transition goes from the same state.
·
System:
This class represent either the system to modelize and the subsystems it is composed
of.
A simple function will represented as a system composed of no component.
OCL:
If the system has sub elements, its inports must have outlinks and its outports must
have inlinks.
If the system doesn't have any sub element, then there can't be any composition or
12/14/2005
background image
TOPCASED
TPC_TUT_MM_SAM V1.2
Page 23/23
data store either.
==>
inv :
if System.listElements->size>0 then
System.listPorts->forAll(p : InPort | p.outlink->size = 1) and
System.listPorts->forAll(p : OutPort | p.inlink->size = 1)
else
System.listSynchronisation->size=0 and System.listStores->size=0 and
System.listPorts->forAll(p : InPort | p.outlink->size = 0) and
System.listPorts->forAll(p : OutPort | p.inlink->size = 0)
endif
This OCL rule may be more restrictive than what is needed, but more effective.
This has to be accepted by Airbus.
·
Transition:
A transition represents the link between 2 states of an automaton.
The condition attribute represents the event/condition string.
The priority is used only is there are multiple link outgoing from one state.
12/14/2005