RASDS : A DRAFT MODEL LIBRARY APPROACH
Issue 0.1
(IN COMPLEMENT TO P. SHAMES & T. YAMADA SLIDES FOR SPACEOPS 2004)
CNES - F. Jocteur Monrozier
May 2004
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
2
MODEL LIBRARY CONCEPT IN UML2
CREATING A TOP LEVEL MODEL
UML CONCEPT USE
- systemModel
The term systemModel is a stereotype attached to a package to signify that the package contains a
collection of models that taken together represent the entire system being modeled.
Note : used for a top level package that aims to contains all RASDS models and viewpoints. The
RASDS model livrary and all RASDS compliant models is defined in a package with this stereotype.
CONCEPT/STANDARD APPLIED TO RASDS
See the 2 following sections.
CREATION OF RASDS VIEWPOINTS
UML CONCEPT USE
- A view projection is a projection of a set of model elements onto a set of view elements. A view
projection provides a location and a style for each model element in the projection.
- A projection is a mapping from a set of elements to a subset of itself.
CONCEPT/STANDARD APPLIED TO RASDS
A RASDS viewpoint might be defined using the view
projection concept.
Note : I can not test this functionality in my UML2 editor.
The different model libray viewpoints have been creating using a “package” with a “topLevel” stereotype
for each RASDS viewpoints.
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
3
USING A MODEL LIBRARY APPROACH
UML CONCEPT
A specific stereotype is defined in order to define a model library that can be import in other models.
- modelLibrary
The term modelLibrary is a stereotype attached to a dependency to signify that the client package
is using the source package as a library of shared model elements.
Note : used in each system models that wants to use RASDS Models. See figure
CONCEPT/STANDARD APPLIED TO RASDS
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
4
ASSOCIATING CLASS DIAGRAM COMPANION
Some of diagrams allows to defined some quick and interesting view of some concerns (use case,
composite structure …). I think that some elements defined in these diagrams have to be linked with
additional class diagrams in order to define more precisely some expected information.
For example : a link in a Use case diagram such as “Agreement”, need to be definied precisely in a class
diagram.
For this reason, I think that main of the elements, whatever their uml constructs need a relative class
diagram description that details one aspect of the architecture definition (role, agreement, …).
DRAFT OF A MODEL LIBRARY APPROACH USING UML2*
(*) As I do not have a SysML editor and a partial UML2 compliant editor, it’s just a fisrt attempt in order
to see how a RASDS model library could be done (with the time I had to do it).
DEFINING MODEL LIBRARY ELEMENTS (VERY DRAFT PROPOSAL)
The proposed modelling organisation is not complete. The intention is to be sure that this is the direction
we would like to go. It’s just a first attempt see how we can provide a pragmatic model library approach
for defining RASDS viewpoints.
COMMON
Objective : define all modelling elements that can be used in the different viewpoints. By defining a root:common
model library, we will ensure a better unified modelisation.
o Elements – class diagram
Objective : define all modelling elements relative to the structure and relationships between elements. can be
used in the different viewpoints.
Example of elements:
o Events – class diagram
Objective : define all modelling elements relative to events/signal concepts. This class diagram could be useful to
defined all needed major events in a space system such as AOS, LOS, … and that could be reused between
RASDS models.
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
5
o Performance – class diagram
Objective : define all modelling elements relative to performance aspects. This class diagram could be useful to
defined all needed performance information, linked to RASDS model elements.
o Requirements – class diagram
Objective : define all modelling elements relative to requirements aspects. This class diagram could be useful to
defined all needed high-level requirement information, linked to RASDS model elements.
o Security – class diagram
Objective : define all modelling elements relative to security aspects. This class diagram could be useful to
defined all needed security information, linked to RASDS model elements.
Note : in OSI management model, a FCAPS (Fautl management, Configuration management, Accounting
management, Performance management, Security management) decomposition is proposed, we should
perhaps have on look on it to see if it could be usefull for our purpose.
ENTERPRISE VIEWPOINT
o Enterprise role view (level 1)- deployment diagram
Objective : identify organisational elements and their role. This class diagram could be useful to defined all
needed high-level requirement information, linked to RASDS model elements.
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
6
Enterprise View (Enterprise
Objects)
Enterprise P
Enterprise Q
Agreement,
Contract, etc.
o Common

Elements – class diagram (extension from root:common:Elements)
- Example of Enterprise organisation elements definition
Example of Enterprise mission elements definition
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
7
Example of Enterprise Role elements definition
Example of Enterprise node elements definition
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
8

Events – class diagram (extension from root:common:Events)

Security – class diagram (extension from root:common:Security)
o Requirements
o Performance
o Security
o Subsystems description
Note : Apply the same descriptive approach done in Enterprise package for each
subsystem identified in Enterprise nodes (see upper level)

Subsystem 1

Subsystem nodes
o …

Requirements

Performance

Security

Subsystems description
Note : Apply the same descriptive approach done in Enterprise package for each
subsystem identified in Subsystem 1 nodes (see upper level)

Subsystem 2

Subsystem 3

…
CONNECTIVITY VIEWPOINT
o Common

Events (extension from root:common:Events)

Security (extension from root:common:Security)

…
o Global connections overview - …
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
9
-
Detailed node element view – composite structure diagram
Connectivity View (Nodes & Links)
Using SysML Components
(Spacecraft)
Spacecraft
y
r
a
n
sciInstr : scienceInstrument
CDH : CmdDataHandlingSystem
dm :
DataManager
CmndIn
Port
i
m
SensorData
DataDonePort
i
l
e
ecu : Execution
Control Unit
InstrCmnd
Port
ObsFin
Port
r
P
oc :
ObsControl
TeleCmndPort
ap : Aperture
ic :
InstrControl
TakeObs
TelemPort
ap: Mechanical
s:
Sensor
dl : DownLink
ul : UpLink
RFAntenna
FUNCTIONNAL VIEWPOINT
o Function overview – use case or components diagram

Objective : diagram showing the functional interactions between main function objects and the type
of data used in their interactions
Example :
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
10
o Scenario overview – a sequence diagram

Objective : diagram showing the scheduling view of the implied functions and their interactions
and the major events of the system that hase impact on this scenario.
Note : An activity diagram as proposed by Peter and Takahiro is also possible.
o Common

Events (extension from root:common:Events)

Security (extension from root:common:Security)

…
o
o Requirements
o Scenarios

Objective : Use case and sequence diagrams showing main data flows and functional interactions
scenarios
o Functions description – package
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
11


Function 1 – package

Function overview – use case

Function Requirements
Function 2 – package
o Function deployment overview – component/deployment
Note : Classification of objects in three categories for Function viewpoint:

Boundary objects are used by actors when communicating with the system; they can be windows,
screens, dialog boxes or menus

Entity objects represent stored data like a database, database tables, or any kind of transient
object such as a search result

Control objects are used to control boundary and entity objects, and represent transfer of
information
INFORMATION VIEWPOINT
o ….
COMMUNICATIONS VIEWPOINT
o ….
:
TO INVESTIGATE
- buildComponent
The term buildComponent refers to a stereotype on a set of components that signifies that the
components have been grouped for organizational or system-level development purposes.
- bind
The term bind is a stereotype attached to a dependency to signify a binding.
When bind is present, there must also be a list of actual parameters that match up with the given
template's formal parameters.
- binding
A binding is a dependency within which the source instantiates the target template to produce a new
model element that uses the specified actual parameters.
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
12
GENERAL COMMENTS
-
separate physical concepts from logical ones (separate design models from physical ones)
-
keep a formal link between logical elements and physical entities by using associations.
-
It could be interesting to provide a sort of design process matrix in order to tell the designers
which kinds of diagrams/models might/should be defined depending the project phase.
Phase
Analysis /
Specification
System Design
Detailed
systems
/subsystems
design
…
Use case +
- Activity
diagrams
- Agreements
Internal
subsystem
architecture
design (nodes)
…
Viewpoint
Enterprise
viewpoint
Enterprise objects
(EO)
Connectivity
viewpoint
Requirements
- Performance
diagram
Links between EO
…
…
…
Use case +
Refinement of
main functions
Function
interface + state
diagrams
…
Function
mapping to
nodes
Requirements
Functionnal
viewpoint
Localisation of main
Functions
Requirements
+ sequence
diagram
Information
viewpoint
Identification of data
flows
Identification and
localisation of main
repositories/database
and needed models
information
Global Model
Information
definition
Detailed model
Information
…
…
…
…
Requirements
Communication
viewpoint
…
…
REFERENCES
- UML Dictionnary URL : http://softdocwiz.com/UML.htm
Modéle de document par défaut CNES version 1.5 mars 1999 81920692
Validation
13
- Presentation of P. Shames & T. Yamada for SpaceOps2004
- RASDS 0.9 document.
- Meta-model slides from T. Yamada.
Modéle de document par défaut CNES version 1.5 mars 1999 81920692