Introduction aux notations UML et OCL

Introduction aux notations
UML et OCL
use case diagram
diagramme de cas d’utilisation
le système
Nom du cas d’utilisation
NomActeur
<<actor>>
SIExterne
« include »
Nom du cas d’utilisation
Etudiant
Description du cas d’utilisation Enseigner un cours
Professeur
date : 10/09/03
auteur : E. Renaux
version : v.0.6
acteur principal : Professeur
acteurs secondaires : Etudiant
Préparer un cours
« include »
« extend »
Enseigner un cours
Points d’extension :
exposé énoncé exercice
rendu de devoir
Enseigner un cours
par correspondance
Diagramme de cas d ’utilisation
du système machin
Réalisation du cas d’utilisation
"préparer un cours"
Précondition
il y a plus de trois étudiants présents
Scénario nominal
1. Le professeur s ’identifie au système
2. Le système authentifie le professeur
3. ...
Scénarios alternatifs
A1. Titre du scénario alternatif
commence à l ’étape 2 du scénario nominal ...
A1.1. Le …
...
Exceptions
...
Postcondition
il y a autant d ’étudiants qu ’au début du cours :-)
exigences non fonctionnelles
le cours doit durer 1h30
activity diagram
diagramme d’activités
client
agent de caisse
Entrer
dans
magasin
[encore un achat dans la liste]
Sélectionner un
produit
[courses terminées]
Scanner article
Choisir une caisse
Y a t ’il encore des articles ?
[oui]
Poser articles sur
tapis
[non]
Editer ticket
Sortie du
magasin
Ouvrir tiroir
Payer
Diagramme d’activité des courses
class diagram
diagramme de classes
ClasseParti
e
1..3
<<stereotype>>
NomClasseAbstraite
from nomPaquetage
- attributPrivate : Type= valeur
# attributProtected : Type
+ attributPublic
- operationPrivate(argument1:
Type, …) : TypeRetour
# operationProtected
+ operationPublique
<<interface>>
NomInterface
operation1
()
operation2
()
ClasseTou
t
ClassePartie2
<<realize>>
ClasseB
ClasseA
NomClasseAssociatio
n
operation
()
NomClasse
operation1()
operation2()
NomSousClasse
ClasseCliente
operation()
note
UneClasse
1
attributDeClasse
ClasseA
nomAssociation
role1
0..*
role2
operationDeClasse()
Classe1
qualif
ier
Classe2
ClientData
unPaquetage
IhmClient
Diagramme de classe du système
Manager
ClasseB
sequence diagram
diagramme de séquence
environnement du système
jeanClaude
:Commerci
al
système
formulaire:
IhmVendeu
r
saisir identifiant
:ManagerV
ente
temps
saisieId(id)
<<entity>>
:BaseVente
algo récursif
verifierId(id)
demande info client
lireListeClients(id)
demande fiche client
lireFicheClient(nom)
creerClient(nom)
infoPaul:Cl
ientData
saisir vente
saisirVente(produit,quantite,prix)
detruire()
Diagramme de séquence du scénario nominal du cas d’utilisation "réaliser une vente"
statechart diagram
diagramme d’états
Clé insérée
insérer clé
scanner un
article(codebarre)[invalide]
/bip erreur
/liste vide
Attente scan
retirer clé
scanner un
article(codebarre)[valide]
/ajouter liste articles
demander total
Attente paiement
Courses payée
/ vider liste articles
Diagramme d’états d’une caisse
component diagram
diagramme de composants
Appli cliente
Base de donnée
centrale
Diagramme de composant du système
boiteOutil.dll
deployment diagram
diagramme de déploiement
Windows NT
Linux
Firewall
serveur central
PC
Client
internet
ethernet banque
ServeurApplication
serveur Web
données
Limites d'UML
OCL
Object Constraint Language
d’après
CSCI3007 Component Based Development
Plan
Qu’est-ce qu’une contrainte?
OCL Concepts
OCL Concepts avancés
Definition
“Une contrainte est la restriction
de une ou plusieurs valeurs d’un
modèle UML.”
Différents types de contraintes
Invariant de Classe
Precondition d’une operation
une contrainte qui doit être satisfaite par toutes
les instances de la classe
une contrainte qui doit toujours être true avant
l’execution de l’ operation
Postcondition d’une operation
une contrainte qui doit toujours être true après
l’execution de l’ operation
Pourquoi
?
Utiliser
OCL
préciser un diagramme
VOL
PassagerVOL
vols
0..*
1
CargoVOL
AVION
0..*
0..*
1
1
PassagerAvion
CargoAvion
15
exemple: Ajouter des invariants
VOL
type :
enum of cargo, passager
0..*
vols
1
AVION
type :
enum of cargo, passager
{context VOL
inv: type = #cargo implies avion.type = #cargo
inv: type = #passager implies avion.type = #passager}
16
OCL?
OCL est
un langage textuel pour décrire les
contraintes dans UML
Formel mais simple à utiliser
Non ambigüe
Sans effets de bord
Modèle Exemple
Flight
Airport
origin
name: String
destination
departing
Flights
departTime: Time
*
/arrivalTime: Time
duration : Interval
maxNrPassengers: Integer
*
flights
airline
*
arriving
Flights
Airline
passengers
* {ordered}
name: String
Passenger
$minAge: Integer
age: Integer
needsAssistance: Boolean
0..1
book(f : Flight)
CEO
airline
0..1
context et self
toute expression OCL est associée à un
contexte spécifique
Ce contexte est souvent l'élément UML auquel
cette contrainte est attachée
Ce contexte peut être désigné dans
l'expression par le mot clé ‘self’.
‘self’ est implicite dans toute expression OCL
Équivalent à`this’ en Java
Notation
Les Contraintes peuvent figurer dans le
modèle UML ou dans un document séparé.
L'expression:
context Flight inv: self.duration < 4
Est identique à:
context Flight inv: duration < 4
Et à:
<<invariant>>
duration < 4
Flight
duration: Integer
Elements d'une expression OCL
On peut utiliser:
Types de base: String, Boolean, Integer, Real.
Éléments du modèle UML
attributs, et classes
Operations booléennes des classes query operations
(sans effets de bord)
Les associations du modèle UML
Y compris les noms de rôles
conseil: utiliser des rôles dans UML pour simplifier OCL
Exemple: OCL types de base
context Compagnie inv:
name.toLower = ‘klm’
context Passager inv:
age >= ((9.6 - 3.5)* 3.1).floor implies
mature = true
Classes, Modèle et attributs
attributs
context VOL inv:
self.maxNrPassagers <= 1000
Attributs de Classe
context Passager inv:
age >= Passager.minAge
Exemple: operations
context Flight inv:
self.departTime.difference(self.arrivalTime)
.equals(self.duration)
Time
midnight: Time
month : String
day : Integer
year : Integer
hour : Integer
minute : Integer
difference(t:Time):Interval
before(t: Time): Boolean
plus(d : Interval) : Time
Interval
nrOfDays : Integer
nrOfHours : Integer
nrOfMinutes : Integer
equals(i:Interval):Boolean
Interval(d, h, m : Integer) :
Interval
Exemple: navigations
Flight
Airport
origin
name: String
destination
departing
Flights
departTime: Time
*
/arrivalTime: Time
duration : Interval
maxNrPassengers: Integer
*
arriving
Flights
context Flight
inv: origin <> destination
inv: origin.name = ‘Amsterdam’
context Flight
inv: airline.name = ‘KLM’
Classes Association
context Person inv:
if employer.name = ‘Klasse Objecten’ then
job.type = #trainer
else
job.type = #programmer
endif
Job
type : {trainer, programmer}
Person
*
employee
1
employer
Company
name : String
Collections dans OCL
La plupart des navigations retournent
des collections d' elements
Flight
type :
enum of cargo, passenger
0..*
flights
1
Airplane
type :
enum of cargo, passenger
Trois Sous types de Collection
Set:
Bag:
arrivingFlights(dans le contexte Airport)
Non-ordonné, unique
arrivingFlights.duration (dans le contexte Airport)
Non-ordonné, non-unique
Sequence:
passagers (dans le contexte Flight)
ordonné, non-unique
Collection : operations
OCL a un grand nombre d'opérations
prédéfinies sur les collections.
Syntax:
collection->operation
collect
Syntaxe:
collection->collect(elem : T | expr)
collection->collect(elem | expr)
collection->collect(expr)
résumé:
collection.expr
L'opération collect retourne la collection des
valeurs obtenues par application de expr aux
éléments de collection
select
Syntaxe:
collection->select(elem : T | expression)
collection->select(elem | expression)
collection->select(expression)
select retourne le sous ensemble des
éléments pour lesquels expression est
true
Exemple: collect
context Airport inv:
self.arrivingFlights -> collect(airLine) ->notEmpty
airp1
f1
airline1
f2
f3
airp2
airline2
f4
airline3
arriving flights
departing flights
f5
forAll
Syntaxe:
collection->forAll(elem : T | expr)
collection->forAll(elem | expr)
collection->forAll(expr)
True si expr est true pour tous les
éléments de collection
Exemple: forAll
context Airport inv:
self.departingFlights->forAll(departTime.hour>6)
f1
depart = 7
airp1
f2
depart = 5
f3
depart = 8
airp2
f4
depart = 9
f5
depart = 8
departing flights
arriving flights
airline1
airline2
airline3
exists
Syntaxe:
collection->exists(elem : T | expr)
collection->exists(elem | expr)
collection->exists(expr)
true si il existe au moins un
élément de collection pour
lequel expr est true.
Exemple: exists
context Airport inv:
self.departingFlights->exists(departTime.hour<6)
f1
depart = 7
airp1
f2
depart = 5
f3
depart = 8
f4
depart = 9
airp2
departing flights
arriving flights
f5
depart = 8
airline1
airline2
airline3
Exemple: select
context Airport inv:
self.departingFlights->select(duration<4)->notEmpty
f1
duration = 2
airp1
f2
duration = 5
f3
duration = 3
f4
duration = 5
airp2
arriving flights
f5
duration = 2
airline1
airline2
airline3
departing flights
Exemple : Iterate
Exemple iterate:
context Airline inv:
flights->select(maxNrPassengers > 150)->notEmpty
Est identique à:
context Airline inv:
flights->iterate (f : Flight;
answer : Set(Flight) = Set{ } |
if f.maxNrPassengers > 150 then
answer->including(f)
else
answer endif )->notEmpty
autres operations sur collection
isEmpty
notEmpty
size
count(elem):occurences d'elem dans collection
includes(elem): true si elem dans collection
excludes(elem)
includesAll(coll)
Result et postcondition
Exemple pre et postcondition
context Airline::servedAirports() : Set(Airport)
pre : -- none
post: result = flights.destination->asSet
Statechart
L' operation oclInState retourne true si
l'objet est dans l'état spécifié
Bottle
filled : enum {empty, half, full}
open
context Bottle inv:
self.oclInState(closed) implies filled = #full
closed
Variables Locales
let definit des variables locales à une
contrainte:
Let var : Type = <expression1> in
<expression2>
Exemple:
context Airport inv:
Let supportedAirlines : Set (Airline) =
self.arrivingFlights -> collect(airLine) in
(supportedAirlines ->notEmpty) and
(supportedAirlines ->size < 500)
heritage de contraintes
Liskov’s Substitution Principle (LSP):
“Partout où une instance d'une classe est
attendue, une instance d'une sous classe
peut lui être substituée”
heritage de contraintes
Consequences de LSP pour les invariants:
un invariant est toujours hérité par ses sous classes.
Les sousclasses peuvent renforcer l'invariant.
Consequences de LSP sur les preconditions et
postconditions:
une precondition peut être weakened (contravariance)
une postcondition peut être strengthened (covariance)
OCL Tools
FREE parser from IBM
Cybernetics
www.boldsoft.com
ICON computing
www-st.inf.tu-dresden.de/ocl/
Boldsoft
www.cybernetic.org
University of Dresden
http://www.software.ibm.com/ad/ocl
www.iconcomp.com
Royal Dutch Navy
Others … …
Conclusions
OCL invariants allow you to
OCL pre- and postconditions allow you to
model more precisely
remain implementation independent
specify contracts (design by contract)
specify interfaces of components more precisely
OCL usage tips
keep constraints simple
always combine natural language with OCL
use a tool to check your OCL
References
[UML 1.3] OMG UML Specification v. 1.3,
OMG doc# ad/06-08-99
[UML 1.4] OMG UML Specification v. 1.4, UML
Revision Task Force recommended final draft,
OMG doc# ad/01-02-13.
Infos
Web:
UML 1.4 RTF: www.celigent.com/omg/umlrtf
OMG UML Tutorials:
www.celigent.com/omg/umlrtf/tutorials.htm
UML 2.0 Working Group:
www.celigent.com/omg/adptf/wgs/uml2wg.htm
OMG UML Resources: www.omg.org/uml/