uml for realtime - unice.frmap/cours/master_tsm/cours1_uml-intro.pdf · uml for realtime...

Master 2 TSM Janvier 2009

Marie-agnes Peraldi-Frati 1

UML for Realtime

Marie-Agnès Peraldi-Frati

UNSA/I3S/INRIA

[email protected]

Charles André - University of Nice-Sophia Antipolis2

Purpose

• Not a study of UML per se.

• UML for modeling real-time and

embedded systems.

• Analyzing performance of such systems

• Implementing such systems

• Not restricted to software application

• Systems engineering



Part I: Introduction to UML

Excerpts from Jean-Paul Rigault’s lecture.

(See the full course document//www-local.essi.fr/~jpr)


Contents

• Introduction: modeling and OO modeling

• Application modeling with Use Case

• Class and object modeling

• State modeling

Focus on

modeling and

analysis




Modeling and OO modeling

• What is modeling?

• What is object-oriented modeling?

• What is UML?

• Technical activities in OO modeling


Overview of UML: A Brief History

Many

OOAD

methods

(> 50)

CoadCoadCoadCoad----YourdonYourdonYourdonYourdon

ShlaerShlaerShlaerShlaer----MellorMellorMellorMellor

FusionFusionFusionFusion

etc.etc.etc.etc.

1991199119911991 1992199219921992 1993199319931993 1994199419941994 1995199519951995 1996199619961996 1997199719971997 1998199819981998 ………… 2004200420042004

Booch (Rose)Booch (Rose)Booch (Rose)Booch (Rose)

Good for designGood for designGood for designGood for design

and constructionand constructionand constructionand construction

Rumbaugh (OMT)Rumbaugh (OMT)Rumbaugh (OMT)Rumbaugh (OMT)

Good for analysis andGood for analysis andGood for analysis andGood for analysis and

datadatadatadata----intensive systemsintensive systemsintensive systemsintensive systems

Jacobson (OOSE)Jacobson (OOSE)Jacobson (OOSE)Jacobson (OOSE)

Good for the captureGood for the captureGood for the captureGood for the capture

of requirementsof requirementsof requirementsof requirements

U

M

L

0.8

U

M

L

0.9

RationalRationalRationalRational

U

M

L

1.0

U

M

L

1.1

OMG request

UMLUMLUMLUMLconsortiumconsortiumconsortiumconsortium

U

M

L

1.2

U

M

L

1.3

U

M

L

2.0

OMGOMGOMGOMG

OMG vote




What is UML and what is it for?

UML is a language for

– Visualizing

– Specifying

– Constructing

– Documenting

Syntax, Semantics (verification)

Graphics

Architecture and behavior

Allow code generation

Textual and graphical

descriptions

the artifacts of a software-intensive system


Overview of UML: What is a UML Model?

• A Use Case view

– Functional requirements

• Several object

views

– Different concerns(architecture, behaviour…)

– Different levels of description(analysis, design, implementation…)

StateStateStateState

DiagramsDiagramsDiagramsDiagramsUse CaseUse CaseUse CaseUse Case



DiagramsDiagramsDiagramsDiagrams

ScenarioScenarioScenarioScenario

DiagramsDiagramsDiagramsDiagramsScenarioScenarioScenarioScenario

DiagramsDiagramsDiagramsDiagramsCollaborationCollaborationCollaborationCollaboration



DiagramsDiagramsDiagramsDiagramsStateStateStateState

DiagramsDiagramsDiagramsDiagramsComponentComponentComponentComponent


ComponentComponentComponentComponent

DiagramsDiagramsDiagramsDiagramsComponentComponentComponentComponent

DiagramsDiagramsDiagramsDiagramsDeploymentDeploymentDeploymentDeployment



DiagramsDiagramsDiagramsDiagramsStateStateStateState

DiagramsDiagramsDiagramsDiagramsObjectObjectObjectObject


ScenarioScenarioScenarioScenario

DiagramsDiagramsDiagramsDiagramsScenarioScenarioScenarioScenario

DiagramsDiagramsDiagramsDiagramsStatechartStatechartStatechartStatechart


Use CaseUse CaseUse CaseUse Case


DiagramsDiagramsDiagramsDiagramsSequenceSequenceSequenceSequence



DiagramsDiagramsDiagramsDiagramsClassClassClassClass


ActivityActivityActivityActivity


ModelModelModelModel

ElementsElementsElementsElements




UML and Software Methodologies

• The UML is methodology independent

• However it is better suited to a

development process that is

– Use case driven

– Architecture centric

– Iterative and incremental


Technical activities in OO modeling




Application modeling

• Modeling requirements in UML

– Functional requirements

• Modeled as Use Cases

– Non-functional requirements

• Some are specific to one use case

• Some relate to technical issues addressed by

implementation diagrams and models

• Other in some supplementary documents, out of

the UML scope

Timing constraints,

Reliability,

…


System Requirements CaptureIdentify capabilities as Use

Cases

Use Case scenario analysis Use Case specification

Identify interactions of

interest

Add QoS Constraints

Informal specification

Specify protocols of

interaction with Statecharts or

activity diagrams

Derive scenarios from

specifications

Add QoS Constraints

Requirements

“By example”Requirements

“By specification”




What is a Use Case?

• Set of sequences of actions that a system

performs and that yields an observable

result

• A set of related services provided by the

system, together with scenarios of use.

• Actor

– Anything which interface with the system

– Not part of the system

Sensors, actuators, …


Use Case: Difficulty and Drawbacks

• Use case modeling is difficult

– Homogeneity, completeness, consistency…

• UML “formalism” is simple, even simplistic

– No real semantics

– No formal description of textual senarios

– Need for predefined interpretations, corporate policies

• Textual scenarios awkwardly express complex control

– Loops, conditionals…




Use Case: Advantages

• Simple to elaborate, understand, and

communicate

– Even for non-computer scientists

• Focus on user needs, not on solution or

architecture

– Avoid architectural drift in object-orientation

– Ease traceability from functional needs to implementation

• Facilitate setting up integration tests

– From use cases, one can derive test cases


Use Cases• A use case usually provides a textual description

outlining its intent and purpose.

• Use Case Description Format:– Name

– Purpose• May be written informally (“The purpose of the capability is to…”)

– Description• May be written semi-formally (“The system shall…”)

• May be informal

• May be a hyperlink off to a separate document

– Preconditions• What is true prior to the execution of the capability?

– Postconditions• What does the system guarantee to be true after the execution of

the use case?

– Constraints• Additional QoS requirements or other rules for the use case




Use Case Diagram

User

Priority User

Edit Phone List

Data

Initialize phone

Display text

Connected

services

Make call

Send text

message

Receive call

Receive text

message

Phone

Company

Make priority call

<< predecessor >>

<< include >>

<< extends >>

{ worst case performance < 2s }

YakityYak Deluxe ™

Cell Phone use cases.

Identifies the

primary

capabilities

of the system.Dependency

relation

Association

relation

Generalization

relation


Object-Orientation OverviewThe (application) world is composed of objects

These objects are linked together

Static relationships (links)

These objects react to stimuli (messages)

Either internal or external

Originating from other objects or from outside the

system

These objects have an internal state

Internal data (attributes) and status of the links with

other

The state may change when the objects are stimulated




What is an object?

Object = Identity + State + Behavior

Objects should bedistinguishable

The identity is independent

of the state

Internal data valuesStatus of links with otherobjects

Operations,events, messages…

Public interface

Objects have “crisp” conceptual boundaries (Booch, 1994)


What is an object?

Static information: architectural aspects

– List of operations (interface)

• The messages the object can accept and react to

– State values

• Possible values of internal data (attributes)

• Possible links with other objects, that are

message transport media

Dynamic behavior: control aspect

– State evolution and messages sent to other objects

• Triggered by message flows




What is a Class?

A group of objects sharing common properties

– common structure:

• same attributes

• same possible relations with other objects

– common behavior: same operations

An abstract data type

A model to instantiate objects

– A class defines the possible behaviors and the information structure of all its instances


Model Elements

ModelElement

Diagram

“Thing”

Relation

Abstractions, first-class citizen in the model

Tie "things" together

Group interesting collections of things and

express (some of) their relationships




Model Elements: Summary

ModelElement

Diagram

“Thing”

Use Case

Class

Interface

Collaboration

Active Class

Component

Node

Relation

Realization

DependencyAssociationGeneralization

Class

Use Case

Collaboration

Deployment

Object

Sequence

State-Transition

ComponentActivity

Structural

Behavioral

OrganizationalAnnotational

InteractionState Machine

PackageNote


Dynamic

diagrams

Model Elements: DiagramsClass diagram

Object diagram

Use case diagram

Sequence diagram

Collaboration diagram

Statechart diagram

Activity diagram

Component diagram

Deployment diagram

Static diagrams

Static (implementation) diagrams

Interaction diagrams

State-transition diagrams




UML Diagrams

Requirement modeling, Design…

Design, Test, Configuration Management

Requirement modeling, Design

Design, Test, Simulation

Requirement modeling, Design, Test

Requirement modeling, Design, Test

Requirement modeling

Analysis, Design, Test…

Analysis and Design

Run-time organization, distribution…

Deployment

Software resource organizationComponent

Business proceduresActivity

Dynamic behaviorStatechart

Cooperation between objects, Design Patterns

Collaboration

Scenario of use, exchange of messages between objects

Sequence

Application needsUse Case

Architecture of a particular instance of the model

Object

Architecture, structureClass

Part II: UML 2.0

Model-Driven Development and MDA

Excerpts from “Bubbles of Steel: A Preview of UML 2.0 and MDA”

Bran SelicIBM Software Group – Rational Software




Model-Driven Style of Development

• An approach to software development in which

the focus and primary artifacts of development

are models (as opposed to programs)

– Implies automatic generation of programs from

models

– Using modeling languages directly as implementation

tools

– “The model is the implementation”


Modeling vs. Programming Languages

Level of

Abstraction

high

low

Programming

Languages(C/C++, Java, …)

Modeling

Languages

(UML,…)

∆∆∆∆LO::::data layout, arithmeticaland logicaloperators,etc.

∆∆∆∆HI::::statecharts,interactiondiagrams,architecturalstructure, etc.

Cover different ranges of abstraction




Covering the full range of detail

(Any) Action

Language

“Action” languages (e.g., Java, C++) for fine-grain detail“Action” languages (e.g., Java, C++) for fine-grain detail

Level of

Abstraction

high

low

Programming

Languages(C/C++, Java, …)

Modeling

Languages

(UML,…)

implementation

level detail

(application

specific)

Fine-grain

logic,

arithmetic

formulae,

etc.

Fine-grain

logic,

arithmetic

formulae,

etc.


How We Learn From ModelsΞ = Ξ = Ξ = Ξ = cos (η + π/2)(η + π/2)(η + π/2)(η + π/2)

+ ξ∗5+ ξ∗5+ ξ∗5+ ξ∗5

Ξ = Ξ = Ξ = Ξ = cos (η + π/2)(η + π/2)(η + π/2)(η + π/2)+ ξ∗5+ ξ∗5+ ξ∗5+ ξ∗5

??• By inspection

– mental execution

– unreliable



??• By formal analysis

•Mathematical methods

•Reliable (theoretically)

•Software is very

difficult to model

mathematically!??



•By experimentation(execution)

•More reliable than inspection

•Direct experience/insight




MDD Implications• Ultimately, it should be possible to:

– Execute models

– Translate them automatically into implementations

– …possibly for different implementation platforms

� Platform independent models (PIMs)

• Modeling language requirements

– The semantic underpinnings of modeling languages must be

precise and unambiguous

– It should be possible to easily specialize a modeling

language for a particular domain

– It should be possible to easily define new specialized

languages


The OMG’s Model Driven Architecture

• The OMG has formulated an initiative called “Model-Driven

Architecture” (MDA)

– A framework for a set of standards in support of MDD

– Inspired by the widespread public acceptance of UML and

the availability of mature MDD technologies

• Rational is a pioneer of model-driven development and is one

of the principal drivers of MDA

– Conceived and refined UML (Booch, Rumbaugh, Jacobson)

– Model-driven development process (RUP)

– Tools for executable models and automatic code generation

(XDE, Rose RealTime, Rose)




The Languages of MDA• Set of modeling languages for specific purposes

GeneralStandard UML

Common Warehouse

Metamodel (CWM)

etc.

Real-Timeprofile

EAI profile

Softwareprocess profile

etc.

MetaObjectFacility (MOF)

A modeling language

for defining modeling

languages

For exchanging

information about

business data

For general OO

modeling

UML

“bootstrap”

MOFMOF“core”


1967

Jacobson

UML: The Foundation of MDA

BoochRumbaugh

UML 1.1 (OMG Standard)UML 1.1 (OMG Standard)

UML 1.3 (extensibility)UML 1.3 (extensibility)

UML 1.4 (action semantics)UML 1.4 (action semantics)

UML 1.4.1UML 1.4.1

1996

1997

1998

2001

2002

2003

UML 2.0 (MDA)UML 2.0 (MDA)

Foundations of OO (Nygaard, Meyer, Stroustrup,

Harel, Wirfs-Brock, Reenskaug,…)




Formal RFP Requirements

1) Infrastructure – UML internals

– More precise conceptual base for better MDA support

2) Superstructure – User-level features

– New capabilities for large-scale software systems

– Consolidation of existing features

3) OCL – Constraint language

– Full conceptual alignment with UML

4) Diagram interchange standard

– For exchanging graphic information (model diagrams)


Language Structure• A core language + optional “sub-languages”

– Enables flexible subsetting for specific needs

– Users can “grow into” more advanced capabilities

OCL

Basic UML(Classes, Basic behavior, Internal structure, Use cases…)

MOF Profiles

StateMachines

StructuredClasses andComponents

Activities Interactions DetailedActions

Flows

Basic LevelBasic Level

Intermediate LevelIntermediate Level

Complete LevelComplete Level

UML Infrastructure




Infrastructure: Consolidation of Concepts

• Breakdown into fundamental conceptual primitives

Namespace PackagableElement RedefinableElement

Classifier Feature

• Eliminate semantic overlap

• Better foundation for precise definition of concepts and semantics


Infrastructure: Behavior Harmonization

• Common semantic base for all behaviors

– Choice of behavioral formalism driven by application

needs

Classifier

. . .Class UseCase Component Action Activity StatemachineInteraction

Behavior0..1 0..*




Package diagrams

Charles André - University of Nice-Sophia Antipolis40Charles André - UNSA40

Package

• Package = Organizational model elements.– Provides a way to group related UML elements

– and scope their names (defines a namespace)

– Contains PackageableElements (Class, Object, Event, Packages… are PackageableElements).

• Packages cannot be instantiated and can only be used to organize

models.• Representation

– A package is denoted by a rectangle with a tab attached to the top left.

– Example: the Utilities package below

– Utilities is the name of the package

– Each element in the package has a fully qualified name (e.g., Utilities::Timer).




Representations

Charles André - UNSA41


Visibility

• May specify visibility information for owned and imported elements (public or private)





Importing & Accessing Packages• When accessing elements in one package from a different package,

you must qualify the name of the element you are accessing.

• To simplify accessing elements in a different package, UML allows a

package to import another package. Imported elements are

available without qualification in the importing package.

• By default, imported elements are public, but they can be given

private visibility.

• «import» vs. «access»

• «merge» mainly for metamodeling.Charles André - UNSA43


UML: Diagrammes de Classes

Transparents inspirés de [4]




Diagrammes de classes

• Les diagrammes de classes représentent un ensemble de classes, d'interfaces et de collaborations, ainsi que leurs relations. Ce sont les diagrammes les plus fréquents dans la modélisation des systèmes à objets. Ils présentent la vue de conception statique d'un système. Les diagrammes de classes, (qui comprennent aussi les classes actives), présentent la vue de processus statique d'un système.


Les classes

• La classe est une description abstraite d’un ensemble d’objets

• La classe peut être vue comme la factorisation des éléments communs à un ensemble d’objets

• La classe décrit le domaine de définition d’un ensemble d’objets

• Description conceptuellement sépa-rée en deux parties

– La spécification d’une classe qui décrit le domaine de définition et les propriétés des instances de cette classe (type de donnée)

– La réalisation qui décrit comment la spécification est réalisée

• Caractéristiques des

classes

– Attributs

– Opérations

– Réceptions

– Relations

– Multiplicité

– Persistance

– Composant




Eléments graphiques

parametre

classe parametrable

une classe une autre classe

nom de l’association

nom de la

classe association

attributs

operations

une classe une autre classe

nom de l’association

/ association dérivée

rôle 1 rôle 2

nom de la classe

attributsnom_attr : type = valeur initiale

opérationsnom_op (arg_list):type

nom de la classe

- variable privée+ variable publique# variable protégée

- opération privée+ opération publique# opération protégée

Remarque: Commencer le nom d’une classe par une majuscule


Visibilité des attributs et opérations

• Public +

Visible à l’extérieur de

la classe

• Protected #

Visible seulement par

les descendants

(classes dérivées)

• Private -

Visible à l’intérieur des

méthodes

• Package ~

• Souligné

attribut/opération de

classe (statique)




Relations : association

• L’association

• L’agrégation

• La composition

• La généralisation

• La dépendance

• L’association exprime une connexion sémantique bidirectionnelle entre classes

• Une association est une abstraction des liens qui existent entre les objets instances des classes associéesRelation

Realization

DependencyAssociationGeneralization


Exemple d’association




Nommage des associations

• Indication du sens de lecture


Nommage des rôles

•Le rôle décrit une extrémité d’une association




Multiplicité des rôles

1 Un et un seul0..1 Zéro ou unM .. N De M à N (entiers naturels)* Plusieurs0 .. * De zéro à plusieurs1 .. * D'un à plusieurs

class Personne {

Compagnie employeur; ... }


Navigabilité

• étant donnée une association non décorée entre deux classes, on peut naviguer d'un type d'objet vers un autre type d'objet.

• par défaut une association est navigable dans les deux sens.

• une indication de navigabilitésuggère en général qu'à partir d'un objet à une extrémité on peut directement et facilement atteindre l'un des objets à l'autre extrémité.

• lors d'une mise en œuvre programmée, ceci peut suggérer par exemple qu'un objet source mémorise une référence directe aux objets cible.

• étant donné un utilisateur, on

désire pouvoir accéder à ses

mots de passe

• étant donné un mot de passe,

on ne souhaite pas pouvoir

accéder à l'utilisateur

correspondant




Exemple


L’agrégation

• Forme d’association qui exprime un

couplage plus fort entre classes

• Connexions sémantiques

bidirectionnelles non-symétriques

• Représentation des relations

– maître et esclaves

– tout et parties

– composé et composant.




L’agrégation• Forte = Composition

Modélisation de la composition physique

– Multiplicité au max de 1 du coté de l’agrégat

– Propagation automatique

de la destruction

– Agrégation simple

Compagnie

Département

*

1

Le tout

La partie


Relation : spécialisation/généralisation

• Gérer la complexité

• Héritage

• Arborescences de classes d’abstraction croissante

class Sous-Classe extends Super-classe { ... }




Relation de Dépendance• Relation très générale (peut être utilisée entre

n’importe quel NamedElement).

• Entre classes: la classe B dépend de la classe A. Si A change, B peut changer; mais pas l’inverse.

• Notation UML : Un trait discontinu partant de la classe dépendante et pointant vers la classe proposant les services sollicités, se terminant par une pointe de flèche ouverte

Exemple : Un contrat dispose d'un service d'impression (méthode impression),

qui utilise une méthode (print), dont la spécification est déclarée par l'interface Printer.


Relation de réalisation• Notation UML : Un trait discontinu partant de la classe

d'implémentation et allant vers l'interface, se terminant

par une pointe de flèche fermée, la même utilisée par

la spécialisation/généralisation

• La fenêtre SaisirClient réalise le contrat définit par

l'interface ActionListener.

class SaisirClient

extends JFrame

implements ActionListener

{ ...

public void actionPerformed (ActionEvent e) {

// faire quelque chose }

}




Exercice faire le diag de classes public interface Observer {

public void update(Observable o);} public class Observable {

Collection observateurs; public void notify() {

Iterator it = this.iterator(); while (it.hasNext())

{ ((Observer) it.next()).update(this); } }

public void addObserver(Observer o) { observateurs.add(o); } ... }

public class Bilan extends Observable { void setChange() { notify(); } ...

}public class UIGraphe implements Observer {

public void update(Observable o) { Bilan unbilan = (Bilan) o; double compteResultat = unbilan.getCompteResultat();

... } ...}


Retour sur les attributs (1)

• Les attributs peuvent

– Inlined attributes

– Attributes by relationship

• Il n’y a pas de différence sémantique entre les deux

• Remarque: Avec les relations on peut introduire plus d’information (e.g., composition)

62




Retour sur les attributs (2)• Notation générale des inlined attributesvisibility / name : type multiplicity = default

{ property strings and constraints }

visibility ::= + | - | # | ~

multiplicity ::= [ lower .. upper ]

/ indique que l’attribut est dérivé. Sa valeur peut être calculée à

partir des autres attributs de la classe.



Retour sur les attributs (3)

• Attribute multiplicity:

quand plus qu’un, on

peut préciser en plus

{ ordered, unique }

Défaut: unique, non ordonné

• Attribute properties:

– readOnly

– union

– subsets attribute-name

– redefines attribute-name





Contraintes• Les contraintes représentent

des restrictions imposées sur

un élément.

• Exprimées en langage

naturel ou en langage formel

(e.g., OCL)

• Notation: la contrainte est

placée entre { } après

l’éléments contraint ou dans

une note.



Retour sur les opérations

66

• Notationvisibility name ( parameters ) : return-type

{ properties and constraints }

visibility ::= + | - | # | ~

parameter ::= direction param-name type

multiplicity = default-value { properties }

direction ::= in | out | inout | return

multiplicity ::= [ lower .. upper ]

• Operation constraints

– preconditions state before invocation

– postconditions state after execution

– body conditions constraints on the returned value

– query does not modify the state of the class




Objet• Un objet est une instance de classe.

• Chaque instance peut avoir un nom ou bien être anonyme. Le nom (s’il est donné) est suivi de : et son type (souvent une classe).

Une classe

Une instance de la

classe Car

Remarque: commencer le nom d’une instance par une minuscule


Classe abstraite

• Une classe abstrait est utile pour identifier des fonctionnalités communes à plusieurs types d’objets.

• Notation: Le nom d’une classes abstraite est écrit en italique.

• Une classe abstraite ne peut pas être instanciée. Elle doit être sous-classée (spécialisée). Les sous-classes concrètes peuvent être instanciées.




Les classes-associations (1)

•Ajout d’attributs ou d’opérations dans la relation

Personne Sociétéemployé

* 0..2

Emploi

salaire

augmenter()

société

Le nom de la classe correspond au nom de l’associationAttention: Pour une association donnée, un couple d'objets ne peut être connectés que par un seul lien correspondant à cette association.(sauf si l'association est décorée par {nonunique} en UML2.0)


Classes-associations (2)

Emploi

salairePersonne Société

employé

1 1

0..2 société*Ci-dessus, une personne peut avoir deux emplois dans la même sociétée2

p1 s1e1

Personne Sociétéemployé

* 0..2

Emploi

salaire

sociétés

Ci-dessus, une personne peut avoir un emploi, dans deux sociétés différentesp1 s1

e1




Interfaces (1)• Une interface est un classeur (classifier) qui à

des déclarations de propriétés et d’opérations mais pas d’implémentations.

• On peut utiliser des interfaces pour grouper des éléments communs à plusieurs classeurs et fournir un contrat qu’un classeur qui implémente l’interface doit respecter.

• Assez proche du concept d’interface en Java.


Interfaces (2)

Class that implements

the interface

Class that uses the interface Other notation: ball

(provided interface)

And socket (required

interface)




Templates

• UML permet d’utiliser des abstractions pour les types

de classes avec lesquels une classes peut interagir.

Templated class

Explicit template binding

Implicit template binding


Classifier• A classifier is a classification of instances, it

describes a set of instances that have features (structural and/or behavioral) in common.

• Kinds of Classifiers: Class, Actor, Component, DataType, Interface, Node, Signal, Subsystem, UseCase,…

• Classes are the most general kind of classifiers. Other can be intuitively understood as similar to classes, with certain restrictions on content or usage. (Excerpts from [B2])

• Note that Classifier is an abstract metaclass





Data types• A data type is a type whose instances are identified only

by their value. A DataType may contain attributes to

support the modeling of structured data types.


Danger:

A metamodel,

not a user’s

model

• All copies of an instance of a data type and any instances of that

data type with the same value are considered to be the same

instance. Value ≠ Object


Enumeration

• A data type whose instances form a list of named literal values.

• An enumeration is a user-definable data type.




References


Official references

• [UML-Infra] OMG “UML 2.0 Infrastructure Specification”, September 2003, OMG Adopted Specification, ptc/03-09-15.

• [UML-Super] OMG “UML 2.0 SuperstructureSpecification”, August 2003, OMG Adopted Specification, ptc/03-08-02.

• [MOF] OMG “Meta Object Facility (MOF) 2.0 Core Specification”, October 2003, OMG Adopted Specification ptc/03-010-04.

• [OCL] OMG “Unified Modeling Language: OCL”, August 2003, OMG 2.0 Draft Adopted Specification ptc/03-08-08.




Books• The Unified Modeling Language User Guide

Grady Booch, James Rumbaugh, Ivar Jacobson

Addison Wesley, 1999.

• The Unified Modeling Language Reference Guide

James Rumbaugh, Grady Booch, Ivar Jacobson

Addison Wesley, 1999

• Real-Time UML

Douglass B.P., Addison-Wesley, 1998.

• Doing Hard Time

Douglass B.P., Addison-Wesley, 1999.

• Real-Time Design Patterns

Douglass B.P., “Addison-Wesley, 2003.


Books (continued)

uml for realtime - unice.frmap/cours/master_tsm/cours1_uml-intro.pdf · uml for realtime...

Documents