Unified Modeling Language UML

Transcription

Unified Modeling Language UML
Unified Modeling Language
UML
Introduction
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
From now on, slides from B. Selic [3]
2
Charles André - UNSA
UML: Evolution
3
Charles André - UNSA
UML 2 Language Architecture
A core language + a set of optional “language units”
Some language units have multiple increments
4
Multiple levels
of compliance
Charles André - UNSA
UML 2: Run-Time Semantics
Much more than a notation
5
Charles André - UNSA
How things happen in UML
In UML, all behavior results from the actions of (active) objects
Object behavior
(e.g., statechart)
Inter-object
behavior
(interaction)
6
Charles André - UNSA
UML approach: Single Model
Views are projections of a complete model
Continuous integration of views with dynamic detection of inconsistencies
7
Charles André - UNSA
UML 2 Diagram Types
The different diagram types of UML represent different views of a given system
typically based on different viewpoints or representations
UML Diagram
Structure
Diagram
8
Behavior
Diagram
Instance
Diagram
Class
Diagram
Activity
Diagram
Statechart
Diagram
Deployment
Diagram
Package
Diagram
Interaction
Diagram
UseCase
Diagram
Collaboration
Diagram
Composite
Structure
Timing
Diagram
Interaction
Overview
Sequence
Diagram
Communication
Diagram
Charles André - UNSA
Object-Orientation Overview
The (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
9
Charles André - UNSA
What is an object?
Object = Identity + State + Behavior
Objects should be
distinguishable
The identity is independent
of the state
Operations,
events, messages…
Public interface
Internal data values
Status of links with other
objects
Objects have “crisp” conceptual boundaries (Booch, 1994)
10
Charles André - UNSA
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
11
Charles André - UNSA
What is in 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
12
Charles André - UNSA
Model Elements
“Thing”
Abstractions, first-class citizen in the model
Relation
Tie "things" together
Diagram
Group interesting collections of things and
express (some of) their relationships
ModelElement
13
Charles André - UNSA
Model Elements: Summary
Class
“Thing”
ModelElement
Relation
Diagram
14
Structural
Active Class
Interface
Collaboration
Use Case
Interaction
Component
Node
Behavioral
State Machine
Package
Organizational
Note
Annotational
Dependency
Association
Generalization
Realization
Class
Object
Use Case
Sequence
Collaboration
State-Transition
Activity
Component
Deployment
Charles André - UNSA
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.
16
Charles André - UNSA
Les classes
• Caractéristiques des
• La classe est une description
abstraite d’un ensemble d’objets
classes
• La classe peut être vue comme la
– Attributs
factorisation des éléments communs
– Opérations
à un ensemble d’objets
– Réceptions
• La classe décrit le domaine de
– Relations
définition d’un ensemble d’objets
– Multiplicité
• Description conceptuellement séparée en deux parties
– Persistance
– La spécification d’une classe qui décrit
– Composant
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
17
Charles André - UNSA
Eléments graphiques
nom de la classe
nom de la classe
- variable privée
+ variable publique
# variable protégée
attributs
nom_attr : type = valeur initiale
opérations
nom_op (arg_list):type
- opération privée
+ opération publique
# opération protégée
parametre
classe parametrable
nom de l’association
une classe
une autre classe
nom de la
classe association
attributs
operations
/ association dérivée
rôle 1
nom de l’association
une classe
rôle 2
une autre classe
Remarque: Commencer le nom d’une classe par une majuscule
18
Charles André - UNSA
Visibilité des attributs et opérations
• Public +
Visible à l’extérieur de
la classe
• Protected #
Visible seulement par
les descendants
• Private Visible à l’intérieur des
méthodes
• Package ~
• Souligné
attribut/opération de
classe (statique)
19
Charles André - UNSA
Relations
•
•
•
•
•
20
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ées
Charles André - UNSA
Exemple
21
Charles André - UNSA
Nommage des associations
• Indication du sens de lecture
22
Charles André - UNSA
Nommage des rôles
•Le rôle décrit une extrémité d’une association
23
Charles André - UNSA
Multiplicité des rôles
1
0..1
M .. N
*
0 .. *
1 .. *
24
Un et un seul
Zéro ou un
De M à N (entiers naturels)
Plusieurs
De zéro à plusieurs
D'un à plusieurs
Charles André - UNSA
Visibilité des rôles
• Public
• Protégé
• Private
25
Charles André - UNSA
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.
26
• é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
Charles André - UNSA
Exemple
27
Charles André - UNSA
L’agrégation
• Connexions sémantiques
bidirectionnelles antisymétriques
• Forme d’association qui exprime un
couplage plus fort entre classes
• Représentation des relations
– maître et esclaves
– tout et parties
– composé et composant.
28
Charles André - UNSA
La composition
• Modélisation de la
composition physique
– Multiplicité au max de
1 du coté de l’agrégat
– Propagation
automatique de la
destruction
Compagnie
Le tout
1
*
Département
29
La partie
Charles André - UNSA
Hiérarchie de classes
• Gérer la
complexité
– Arborescences
de classes
d’abstraction
croissante
Super-classe
Classe plus
générale
Sous-classe
Classe plus
spécialisée
30
Charles André - UNSA
Autres concepts présents dans
les diagrammes de classes
Dépendances
• 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.
Remarque: Les dépendances sont souvent stéréotypées
32
Charles André - UNSA
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)
33
Charles André - UNSA
Retour sur les attributs (2)
• Notation générale des inlined attributes
visibility / 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.
34
Charles André - UNSA
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
35
Charles André - UNSA
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.
36
Charles André - UNSA
Retour sur les opérations
• Notation
visibility 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
–
–
–
–
37
preconditions state before invocation
postconditions state after execution
body conditions constraints on the returned value
query does not modify the state of the class
Charles André - UNSA
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
38
Charles André - UNSA
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.
39
Charles André - UNSA
Les classes-associations (1)
•Ajout d’attributs ou d’opérations dans la relation
employé
Personne
société
0..2
*
Société
Emploi
salaire
augmenter()
Le nom de la classe correspond au nom de l’association
(problème: il faut choisir entre forme nominale et forme verbale)
Attention: 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)
40
Charles André - UNSA
Classes-associations (2)
employé
Personne
sociétés
Société
0..2
*
Emploi
e1
p1
salaire
s1
Ci-dessus, une personne peut avoir deux emplois, mais pas dans la même société
e1
p1
s1
e2
employé
Personne
1
0..2
Emploi
salaire
*
société
1
Société
Ci-dessus, une personne peut avoir deux emplois dans la même société
41
Charles André - UNSA
Associations qualifiées
• Une association qualifiée met en relation deux classes sur
la base d'une clef.
• La technique associée de mise en œuvre est souvent un
tableau associatif ou un dictionnaire.
Repertoire
nom
0..1
Fichier
"Pour un répertoire, à un nom donné on associe qu'un fichier
(ou 0 s'il existe aucun fichier de ce nom dans ce répertoire)."
Correspond à la notion intuitive d'index absente ci-dessous
Repertoire
*
42
Fichier
Charles André - UNSA
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.
43
Charles André - UNSA
Interfaces (2)
Class that uses the interface
Other notation: ball
(provided interface)
And socket (required
interface)
Class that implements
the interface
44
Charles André - UNSA
Templates
• UML permet d’utiliser des abstractions pour les types
de classes avec lesquels une classes peut interagir.
Templated class
Implicit template binding
Explicit template binding
45
Charles André - UNSA
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
46
Charles André - UNSA
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
47
Charles André - UNSA
Enumeration
• A data type whose instances form a list of
named literal values.
• An enumeration is a user-definable data type.
48
Charles André - UNSA
Bibliographie
• [1] UML superstructure v 2.1.1, Feb. 2007
(http://www.omg.org/cgi-bin/doc?formal/07-02-05)
• [2] UML infrastructure v 2.1.1, Feb. 2007
(http://www.omg.org/cgi-bin/doc?formal/07-02-06)
• [3] Bran Selic. UML2 and SysML: Modeling Language
Stndards for System Design. IBM, 2007
• [4] Jean Bézivin. Ingénierie des modèles logiciels. Cours
#1. Nantes 2003.
• [5] Jean-Marie Favre. UML Diagrammes de Classes –
Concepts avancés. Cours.
49
http://www-adele.imag.fr/~jmfavre
Charles André - UNSA
Books
• [B1] The Unified Modeling Language User Guide
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison Wesley, 1999.
• [B2] The Unified Modeling Language Reference Guide
James Rumbaugh, Grady Booch, Ivar Jacobson
Addison Wesley, 1999
• [B3] Real-Time UML
Douglass B.P., Addison-Wesley, 1998.
• [B4] Doing Hard Time
Douglass B.P., Addison-Wesley, 1999.
• [B5] Real-Time Design Patterns
Douglass B.P., “Addison-Wesley, 2003.
50
Charles André - UNSA
Books (continued)
51
Charles André - UNSA