Cours UML Partie2

ENSA de Fès 2017/2018
ENSAF
M M
O O
D D
E
L Langage de Modélisation E
L
I I
S
A UML S
A Diagramme de Cas
T T
I
O (Partie 2) I
O d’Utilisation
N N
U U
M M
L Mohammed Berrada L
mohammed.berrada@gmail.com
ENSAF 48 M.BERRADA ENSAF 49 M.BERRADA
Plan 3 Cas d’utilisation : Introduction

M M
O • Introduction O • Le concept de cas d’utilisation introduit par Ivar Jacobson
D • Cas d’utilisation : Notation D dans la méthode Object-Oriented Software Engineering
E E (OOSE).
L • Relation entre acteurs et cas d’utilisations L
I I
S • Elaboration d’un cas d’utilisation S
A A
• Les fonctionnalités du système sont décrites comme un
T • Exemple d’application T ensemble de cas d’utilisation.
I • Conclusion I
O O
N N • Chaque cas représente un flot spécifique d’événements
vers le système.
U U
M M
L L
• La description du cas d'utilisation définit ce qui arrive dans
le système lors de sa réalisation.
M.BERRADA 1
Cas d’utilisation (Notation) Représentation d’un Cas d’utilisation

M M
O • Entité qui agit sur le système; représente un O
D ensemble cohérent de rôles qu’un utilisateur D
E E
L peut effectuer. L
I Acteur I
S S
A A
T • Ensemble cohérent de fonctionnalités fournies T
I I
O Cas d’utilisation par le système ou un sous-système en réponse O
N à une action de l’utilisateur. N
U U
M • Représentent des relations (liens) entre : M
L L
Relation – Des CU, des acteurs, les CU et les acteurs
Relations entre acteurs et CU Relations entre cas d’utilisation (1)

M M
O • Association O
D – Représente un chemin de communication entre un acteur et un CU D
E E
L • Multiplicité L
I – En cas de plusieurs interactions entre un acteur et un cas d’utilisation, I
S – Elle est représenté par un symbole du coté cas d’utilisation S
A • Exemple : * (plusieurs) , n (exactement n), et n..m ( entre n et m) A
T T
I • Cas d’utilisation interne I
O – Quand un cas n’est pas relié directement à un acteur O
N N
U U
M M
L L
M.BERRADA 2
Relations entre cas d’utilisation(2) Relation d’inclusion

M M • Un cas A inclut un cas B si le comportement décrit par le cas
O • On peut distinguer entre 2 types de relations: O
D D A inclut le comportement du cas B : le cas A dépend de B.
E
– Les dépendances stéréotypées E
L • Une dépendance se représente par une flèche avec un trait pointillé L • Les inclusions permettent :
I I – factoriser une partie de la description d’un cas d’utilisation qui serait
<<stéréotype>>
S S
commune à d’autres cas d’utilisation
A • les plus utilisées : A
T T – décomposer un cas complexe en sous-cas plus simples
– l’inclusion <<include>> : Représente l'insertion d'un « use case » dans
I I
un autre use case
O O
N – l’extension <<extend>>: Capture comment une ou plusieurs N
descriptions d’un « use case » intègrent la description d'un autre use
U case U
M M
L – La généralisation/spécialisation L
• Le symbole utilisé pour la généralisation est un flèche avec un trait pleins
dont la pointe est un triangle fermé désignant le cas le plus général.
Relation d’extension Relation de généralisation/Spécialisation

M M
O • Un cas A étend un cas B lorsque le cas A peut être appelé au cours de O • Cette relation de généralisation/spécialisation est présente
D l’exécution du cas B. D dans la plupart des diagrammes UML
E E
L • Exécuter B peut éventuellement entraîner l’exécution de A : L • Elle se traduit par le concept d’héritage dans les langages
I contrairement à l’inclusion, l’extension est optionnelle. I orientés objet.
S S
• Une extension est souvent soumise à une condition. Graphiquement, elle • Un cas A est une généralisation d’un cas B si B est un cas
A A
T est exprimée sous la forme d’une note T particulier de A
I I
O O
N N
U U
M M
L Condition : Si le client L Consulter depuis Internet Consulter comptes
n’est pas enregistré
M.BERRADA 3
Relations entre acteurs Elaboration de CU

M • La généralisation est la seule relation possible entre deux M
O O • quelles sont les tâches de l’acteur ?
acteurs
D D • quelles informations l’acteur doit-il créer, sauvegarder, modifier,
E • un acteur A est une généralisation d’un acteur B E
L L détruire, ou simplement lire ?
– si l’acteur A peut être substitué par l’acteur B.
I I • l’acteur doit-il informer le système de changements externes ?
– Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais
S S
l’inverse n’est pas vrai. • On s’intéresse au domaine du ‘quoi faire’, pas du ‘comment’ (sinon on
A A
T T rentre dans la phase de conception)
I I
O O
• on doit rester au niveau de l’interaction acteur/système
N N
U U
M M
L L
Cas d'utilisation : Démarche Acteur

M M
O • Recherche des acteurs externes O • UML n’emploie pas le terme Utilisateur
D D
E
• Pour chaque acteur les cas d'utilisation E
• Rôle joué par une personne ou une chose qui interagit avec
L • Pour chaque cas d'utilisation : L un système d’une manière directe
I I – La même personne physique peut jouer différents rôles
– rechercher les interactions
S S
– rechercher les objets manipulés • Correspondre à plusieurs acteurs
A A
T T – Plusieurs personnes peuvent jouer le même rôle
• Faire la maquette de chaque cas d'utilisation
I I • Correspondre à un seul acteur
O O
N N
Remarque :Les diagrammes des cas d'utilisation se retrouveront • Nom de l’acteur = Rôle joué par l’acteur
U à tous les stades du projet. U
M M • Détermination des acteurs par l’identification des différents
L L rôles
– ==> précision des limites du système de manière progressive
M.BERRADA 4
Catégories et types d’acteurs C.U : Caractéristiques (1)

M M
O Catégories O • Le cas d'utilisation utilise une description textuelle
D • Acteurs principaux: personnes utilisant le système (à qui va servir le système) D • Le cas d'utilisation est un cadre pour l'élaboration des différentes fins
E E
L • Acteurs secondaires: qui administrent le système (paramètrent le système en lui L possibles pour le cas d'utilisation
I fournissant les informations nécessaires ou effectuent des m.a.j). I • L'analyse est complète lorsque tous les cas d'utilisation sont étudiés
S Exemple : bibliothèque => l’administrateur est un A.S, le membre est un A.P. S
A A • Un cas d'utilisation décrit l'échange standard entre un acteur externe et un
T Types T système; décrit une famille de scénarios incluant les cas d ’erreur.
I • Matériel externe: dispositifs matériels faisant partie du domaine de I
O O
• L'acteur est l'initiateur de l'échange, il peut être:
l’application.
N N – Personne
• Humains : utilisateurs du système.
– équipement
U • Logiciels, robots : qui exploitent les données du système. U – système externe
M M
L L
CU : Caractéristiques (2) Description textuelle d’un CU

M M
O • Identification d'une finalité de l'utilisateur O • Une description se compose de trois parties
D • Un stimulus de départ D 1. Première partie: permet d’identifier le cas, elle doit contenir
E E
• Une pré-condition du système au déclenchement • Nom: utiliser une tournure à l’infinitif (ex: Retirer de l’argent)
L L
I I • Objectif: Une description résumée
• Un enchaînement d'interactions
S S • Acteurs principaux/secondaires
A • Une post-condition du système à la fin du cas d’utilisation A • Dates, Responsable et version
T T
I • Enchaînement d’actions à effectuer I
2. Deuxième partie : contient la description du fonctionnement du cas
O O • Les préconditions : décrit l’état du système avant le déclenchement de ces cas
• Une fin normale (conditions d’exécution éventuelles)
N N d’utilisation
• Des scénarii : ils sont décrits sous la forme d’échanges d’évènements entre
U U l’acteur et le système (nominal, alternatif et d’exception)
M M • Des postconditions: décrivent l’état du système à l’issue des différents scénarii
L L
3. Troisième partie: contient des spécifications non fonctionnelles (techniques )
• une description des besoins en d’interfaces graphiques
M.BERRADA 5
Exemple d’application (1) Exemple d’application (2)

M • Diagramme de CU pour un système téléphonique M
O O • Description textuelle d’un CU
D D – Nom : appeler téléphone
E Téléphone E
L L – Description:
I I
S Appeler Téléphone
S
– Acteur principal : client
A Client A – Acteur secondaire : opérateur
T Recevoir Appel T
I I – Pré condition :avoir un crédit suffisant pour l’appel
Opérateur
O O – Scénarii :
N Interrompre appel N
• composer le numéro de l’appelant, parler, et finir l’appel
U U • Composer le numéro, fin du crédit et arrêt de l’appel par l’opérateur
M M • Composer le numéro, l’appelant ne répond plus
• Cas d’utilisation : description générique d’une transaction complète entre
L L
l’acteur et le système (claire et précise). – Post condition : communication finie entre l’appellant et
Remarque : pas d ’interactions entre acteurs l’appellé
Plan 4
M M
O O • Classes et objets
D D • Associations
E E
L L – Caractéristiques: multiplicité, rôle, …
I I – Classes d’association
S S
A A – Associations n-aires, récursives
T T
• Composition et agrégation
I
O Diagramme de Classes I
O • Généralisation et spécialisation
N N
• Package
U U
M M • Exemples
L L
M.BERRADA 6
Notation de base Classe Attribut

• Classe • Attribut = propriété nommée d ’une classe
M M
O – Une description d’un ensemble d’objets O • Syntaxe
D qui partage les mêmes attributs, opérations, D – visibilité nom : type = valeur initiale
E méthodes, relations et contraintes E • Visibilité
L L
– + public
I I
S S – # protégé
A A – - privé
T • Objet T – package
Objet de type Classe
I – Une entité avec une limite et une identité I • Attribut de classe
O bien définies qui encapsule de l'état et du O
N N – la portée standard d’un attribut est limité à un objet
comportement. L’état est représenté par
des attributs et des relations, le – quand cette portée s’applique à la classe elle même, on parle d’attribut de
U comportement est représenté par des U classe (représenté par le symbole $ ou souligné)
M opérations et des méthodes. Un objet est M • Attribut dérivé
L une instance d’une classe. L – attribut qui peut être déduit d’un ou plusieurs autres attributs (représenté
par le symbole /)
Méthode Notation Complète

Nom de la Classe
• Méthode = service que l ’on peut demander à un objet pour réaliser un
M M Initialisation
comportement
O O
D • Syntaxe D Fenetre
E – visibilité nom (paramètres) : type retour E Visibilité + taille : Rectangle = 100,100
}
L • Mêmes notions que l’attribut L - visible : Boolean = true
I I couleur : C olor = blue
– visibilité Attributs
S S #$ tailleMax : Rectangle
A – méthode de classe A Static #$ tailleMin : Rectangle
T T /#$ tailleMoyenne : Rectangle
I I
O
N
U
M
O
N
U
M
Dérivé + afficher() : Position
+ cacher()
# setTaille(taille : Rectangle)
} Méthodes
L L Retour
Paramètre
M.BERRADA 7
Définitions Exemple
• Association
M M Rôle
O – Exprime une connexion sémantique bi-directionnelle entre classes O
D – Abstraction des liens qui existent entre objets D
E – Le sens d ’une association peut-être précisé par une flêche E
L • Association binaire = Association entre 2 classes. Cas particulier L Personne Nom Entr epris e
I I -em ployé em ploie -em ployeur
d ’association n-aire Nom Raison Sociale
S S Prénom Ac tivité
A • Rôle = rôle joué par une classe dans une association A 1..* 0..1
T • Multiplicité = indique le nombre d’instances d ’une classe qui peut être T
I mise en relation avec une seul instance de la classe associée I Sens
O O
– 1 : obligatoire
N N
– 0..1 : optionnel
U – 0..* ou * : quelconque U Classe
M – 1..* : au moins 1 M Multiplicité
L – 1..5, 10 : entre 1 et 5, ou 10 L
Sémantique Note
• Note = Commentaire placé sur un diagramme
M M
O O
D Mari 1 marié avec 1 Epouse D
E E C ommentaire sur
L L une asso ciatio n
I I
S S
A Homme 1 marié avec 1 Femme A
T mari épouse T Personne Entreprise
I I
O O
N N
Homme 0..* a été marié avec 0..* Femme
U U
C o mm enta ire
M M
sur une classe
L L
M.BERRADA 8
Multiplicité des attributs Noms d’extrémité

M M
O • [1] : une valeur obligatoire O • Possibilité de nommer les extrémités d’association
D • [0..1] : une seule valeur optionnelle D
E E
L • [*] : zéro ou plusieurs valeurs L
I I
S
• Par défaut : attribut mono-valué ([1]) S
A A
T T
I I • Indispensable pour les associations entre objets de même
O O classe
N N
U U
M M
L L
Classe d’Association Classe d’Association (2)

• Classe d’association = Elément ayant à la fois les propriétés d’une
M M
classe et d’une association • Note : Ne pas confondre classe-association et association
O O
D D promue au rang de classe
E E
Société
L Personne L
nom
I nom travaille capital I
age
S S
0..* 0..* embaucher( )
A prendre retraite( déposer bilan( A
T T
I Contrat de Travail I
O date Convention Collective O
salaire respecte - référence
N N
1..* 1..1
augmenter( ) + renégocier( )
résilier( )
U U
M M
L L
Classe
M.BERRADA 9
Classe d’Association (3) Association n-aire

• Association n-aire = Une association parmi 3 classes ou plus. Chaque
M M
O • Elément dérivé : donnée définie en terme d’autres O instance de l’association est un n-tuple de valeurs des classes respectives.
D termes D
E E
L L Salle
I I
lieu 1
S S
A A
T T Cours
I I Professeur 1 Elève
1..*
O O
N N
U U
M M
L L Heure de début
Heure de fin
Association n-aire (2) Agrégation et Composition

• Note : A éviter ce type d’association. Elle Peut être • Agrégation = association particulière spécifiant une relation ‘tout -
M M
partie’ entre l’agrégat et un composant
O décomposée en associations binaires O
D D – Inclusion ( Un livre ‘ inclus ’ des chapitres. Un chapitre ‘ inclus ’ des mots.)
E E – Propagation (Si on pose la question ‘nombre de caractère ?’ à la classe
L L Livre, celle-ci propage la même question à la classe Chapitre qui la propage à
I I la classe Mot.)
S S
A A
T T Livre Chapitre Mot
I I 1..* 1..*
O O
N N
• Composition = forme forte d’agrégation avec un cycle de vie des
U U parties lié à celui du composite
M M
L L
M.BERRADA 10
Exemples Généralisation et héritage

Voiture Multiplicité • Spécialisation = relation ente un élément plus général et un élément plus
M M
O
Agrégation O
spécifique qui est entièrement conforme avec le premier élément, et qui
D D ajoute de l ’information supplémentaire
E 1..1 1..1 4 2,3,4,5 E • Généralisation = mécanisme par lequel des éléments plus spécifiques
L Moteur Chassis Roue Porte L incorporent la structure et le comportement d’éléments plus généraux
I I (notion d’héritage).
S S
A A
T T Avion Discriminant
I I Généralisation
O Composition O
N N motorisation motorisation rayon d'action rayon d'action
Planeur AvionAMoteur MoyenCourrier LongCourrier

U U
M M
L L
A320
Spécialisation
Héritage multiple
Généralisation et héritage (2) Interface

• Notations
M M Stéréotype
O • Exemple : O <<Interface>>
D D
E E
L L
I I
S S • Hériter d’une interface
A A
T T <<Interface>> <<Interface>>
Wind Liste ner A vion Missile_ Liste ner
I I
O O
N N
U U
M M
Implements
L L P lanneur
AvionD e C hasse
Extends
M.BERRADA 11
Interface : Dépendance Interface : Exemple

• Une dépendance est une relation unidirectionnelle exprimant une • Une interface doit être réalisée par au moins une classe et peut l’être par
M M
dépendance sémantique entre des éléments du modèle. plusieurs. Graphiquement, cela est représenté par un trait discontinu
O O
D D terminé par une flèche triangulaire et le stéréotype « realize ».
E • La dépendance est souvent stéréotypée pour mieux expliciter le lien E • Une classe peut très bien réaliser plusieurs interfaces
L sémantique entre les éléments du modèle L
I I
S S
A • On utilise souvent une dépendance quand une classe en utilise une autre A
T comme argument dans la signature d’une opération T
I I
O O
N N
U U
M M
L L
Classe Abstraite Enumération

• Classe Abstraite = classe que l ’on ne peut pas instancier
M M
O O • Énumération : type de données ayant un ensemble fini de
D • Notation : D valeurs
E E
L L
I I
S Avion Ou Avion S
{abstract}
A A
T T
I I
O O
N Italic Contrainte N
U U
M M
L L
M.BERRADA 12
Exemple : Éditeur graphique Exemple : Éditeur graphique

M M
O • Un éditeur de documents graphiques supporte le O
D groupement d'objets graphiques. D
E E
L
• Un document se compose de plusieurs feuilles, chacune L
I contenant des objets graphiques (texte, forme géométrique I
S et groupe d'objets). S
A A
T • Un groupe est un ensemble d'objets pouvant contenir T
I d'autres groupes. Un groupe doit contenir au moins deux I
O O
N
éléments. N
• Les formes géométriques comprennent les cercles, les
U U
M
ellipses, les rectangles, les carrés, les lignes... M
L L
Contraintes Contraintes (2)

• Les seules contraintes pré-définies en UML pour la généralisation sont :
M M
O • Contrainte : condition booléenne s’appliquant aux O – disjoint (un moyen courrier ne peut être long courrier) / overlapping
D éléments d’un modèle UML D – complete (liste éxhaustive de classe) / incomplete
E E Avion
L L
I I
S S
A A
T T
{incomplete} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - {disjoint}
I I
O O
Planeur AvionAMoteur MoyenCourrier LongCourrier
N N
U U
M M
L L
M.BERRADA 13
Ordonnancement, bags et séquences Association qualifiée

M M • Qualificateur :
O • Ordonnancement des objets situés à l’extrémité d’une O
association « plusieurs » – Attribut permettant de distinguer les objets situés à l’extrémité
D D
E E de multiplicité « plusieurs » d’une association
L L – Attribut réduisant la multiplicité « plusieurs » à « un »
I I
S S • Association qualifiée : association contenant un ou plusieurs
A A attributs qualificateurs
T T
I I
O • Bag (sac) : collection non ordonnée avec autorisation de O
N doublons N
U • Séquence : collection ordonnée avec autorisation de U

M doublons M
L L Un numéro de Salle permet d’identifier une salle unique dans un
Bâtiment donné
Un numéro de Salle est relatif à un Bâtiment
Association qualifiée (2) Exemple (1)

M M
O • Le diagramme à gauche représente l’association entre une O • Pour couvrir le cas des comptes joints, il faut utiliser le
D banque et ses clients, et le diagramme à droite représente D modèle de droite.
E l’association entre un échiquier et les cases qui le composent. E
L L
I En bas, les diagrammes équivalents utilisant des associations I
S qualifiées. S
A A
T T
I I
O O
N N
U U
M M
L L
M.BERRADA 14
Exemple (2) Exemple (3)

M M
O • Si un cours doit pouvoir exister indépendamment d’un lien O • Si un même cours doit concerner plusieurs couples
D entre un enseignant et un groupe, il faut utiliser le modèle D Enseignant/Etudiant, il ne faut pas utiliser une classe-
E de droite. E association, mais une association ternaire comme sur le
L L
I I modèle de droite.
S S
A A
T T
I I
O O
N N
U U
M M
L L
Package : Pour Structurer Exemple

M • Package = Regroupement d’éléments de modèle M
• Package : groupe d’éléments partageant un thème
O • Les Packages divisent et organisent les modèles de la même manière que O
D les répertoires organisent les systèmes de fichiers D
E • Les Packages eux-mêmes peuvent être imbriqués à l ’intérieur d ’autres E
L L
Packages
I I
S S
A A
Package Parent
T T
I I
O O
N Package Enfant 1 Package Enfant 2 N
U U
M M
L L
M.BERRADA 15
Notation
M M
O O
D D
E E
L L
I I
S S
A A
T T
I
O
I
O Diagramme d’objets
N N
U U
M M
L L
Plan 5 Définition
M M
O • Définition O • Représentation d’un ensemble d’objets et de liens, exprimant
D • Objet D la structure statique.
E E
L • Lien L
I
• Exemples I • Un diagramme d’objets est une instance d’un diagramme de
S S
A A
classes et illustre l’état d’un système à un moment donnée.
T T
I I
O O • Les diagrammes d’objets s’utilisent principalement :
N N – pour montrer un contexte e.g., avant ou après une
U U interaction,
M M – pour faciliter la compréhension des structures de données
L L
complexes e.g., structures récursives.
M.BERRADA 16
Définition (2) Objet

M M
O • Un diagramme d’objets est composé : O • Un objet est une instance d’une classe : il représente
D – d’objets (instances de classes), D “l’état” d’une classe à un instant précis.
E E
L – de liens (instances d’associations). L
I I • Des groupes d’objets instances d’une même classe peuvent
S S
A • La notation des diagrammes d’objets est dérivée de celle A
se représenter.
T des diagrammes de classes. T
I I
O O • Un message envoyé vers un groupe est reçu par tous les
N
• La notation des diagrammes de collaboration est dérivée de
N objets du groupe.
U la notation des diagrammes d’objets. U
M M • Représentation UML
L L
Objet (2) Objet (3)

M M
O • L’état d’un objet est déterminé par les valeurs de ses O • Possibilité de modéliser les changements d’états des objets :
D attributs : D
E E
L
il est possible de nommer un état afin d’indiquer L
I clairement dans quel état se trouve un objet. I
S S
A A
T • Les représentations des objets peuvent contenir des T
• Possibilité d’utiliser des liens stéréotypés (exemple : la copie
I I
attributs significatifs. d’objets)
O O
N N
U U
M M
L L
M.BERRADA 17
Objet Composite (Représentation UML) Lien

M M
O O • Les objets sont reliés par des instances d’associations : les liens.
D D • Un lien représente une relation entre objets à un instant donné.
E E
L L • ATTENTION : la multiplicité des extrémités des liens est
I I toujours de 1.
S S
A A
T T • Exemple : représentation de la structure générale d’une voiture
I I
O O
N N
U U
M M
L L
Lien (Stéréotype) Lien : Rôle

M M
O Des stéréotypes peuvent être utilisés pour qualifier les O • Les rôles des associations peuvent être représentés
D extrémités des liens : D explicitement
E E
L
• <<local>>: l’instance associée à cette extrémité est une L
I variable locale d’une méthode. I
S S
A
• <<global>>: l’instance associée à cette extrémité est A
T visible pour tous les éléments (portée globale). T
I I
• <<paramètre>>: paramètre d’une méthode.
O O
N • <<self>>: lien vers l’objet lui- même (une instance peut N
s’envoyer un message).
U U
M M
L L
M.BERRADA 18
Exemple d’un système de sécurité Exemple : Diagramme de classes

M M
O • L’exemple partiel qui suit est extrait du livre “Instant O
D UML” (chapitre 5) et il est possible d’obtenir l’exemple D
E complet sur le site http://www.wrox.com. E
L L
I I
S S
A
• Il s’agit d’un système de sécurité limitant les accès à des A
T parties d’un édifice à l’aide de cartes magnétiques. T
I I
O O
N N
U U
M M
L L
Exemple : Diagramme d’objets Exemple : Diagramme d’objets

M M
O • Le système gère un seul bâtiment contenant trois portes. O
D D
E E
L • Le système peut être géré par une personne nommée L
I Tolkien. I
S S
A A
T • Deux utilisateurs peuvent accéder au bâtiment : T
I I
O – Gandalf a accès à la première (8h-18h) et seconde porte O
N (12h-24h) N
U – Bilbon a accès à la troisième porte toute la journée. U

M M
L L
M.BERRADA 19

Cours UML Partie2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cours UML Partie2

Загружено:

Авторское право:

Доступные форматы

ENSA de Fès 2017/2018

ENSAF 48 M.BERRADA ENSAF 49 M.BERRADA

Plan 3 Cas d’utilisation : Introduction

ENSAF 50 M.BERRADA ENSAF 51 M.BERRADA

Cas d’utilisation (Notation) Représentation d’un Cas d’utilisation

ENSAF 52 M.BERRADA ENSAF 53 M.BERRADA

Relations entre acteurs et CU Relations entre cas d’utilisation (1)

ENSAF 54 M.BERRADA ENSAF 55 M.BERRADA

Relations entre cas d’utilisation(2) Relation d’inclusion

Relation d’extension Relation de généralisation/Spécialisation

ENSAF 58 M.BERRADA ENSAF 59 M.BERRADA

Relations entre acteurs Elaboration de CU

ENSAF 60 M.BERRADA ENSAF 61 M.BERRADA

Cas d'utilisation : Démarche Acteur

ENSAF 62 M.BERRADA ENSAF 63 M.BERRADA

Catégories et types d’acteurs C.U : Caractéristiques (1)

ENSAF 64 M.BERRADA ENSAF 65 M.BERRADA

CU : Caractéristiques (2) Description textuelle d’un CU

ENSAF 66 M.BERRADA ENSAF 67 M.BERRADA

Exemple d’application (1) Exemple d’application (2)

ENSAF 70 M.BERRADA ENSAF 71 M.BERRADA

Notation de base Classe Attribut

ENSAF 72 M.BERRADA ENSAF 73 M.BERRADA

Méthode Notation Complète

ENSAF 74 M.BERRADA ENSAF 75 M.BERRADA

ENSAF 76 M.BERRADA ENSAF 77 M.BERRADA

ENSAF 78 M.BERRADA ENSAF 79 M.BERRADA

Multiplicité des attributs Noms d’extrémité

ENSAF 80 M.BERRADA ENSAF 81 M.BERRADA

Classe d’Association Classe d’Association (2)

ENSAF 82 M.BERRADA ENSAF 83 M.BERRADA

Classe d’Association (3) Association n-aire

ENSAF 84 M.BERRADA ENSAF 85 M.BERRADA

Association n-aire (2) Agrégation et Composition

ENSAF 86 M.BERRADA ENSAF 87 M.BERRADA

Exemples Généralisation et héritage

Planeur AvionAMoteur MoyenCourrier LongCourrier

ENSAF 88 M.BERRADA ENSAF 89 M.BERRADA

Généralisation et héritage (2) Interface

ENSAF 90 M.BERRADA ENSAF 91 M.BERRADA

Interface : Dépendance Interface : Exemple

ENSAF 92 M.BERRADA ENSAF 93 M.BERRADA

Classe Abstraite Enumération

ENSAF 94 M.BERRADA ENSAF 95 M.BERRADA

Exemple : Éditeur graphique Exemple : Éditeur graphique

ENSAF 96 M.BERRADA ENSAF 97 M.BERRADA

Contraintes Contraintes (2)

ENSAF 98 M.BERRADA ENSAF 99 M.BERRADA

Ordonnancement, bags et séquences Association qualifiée

U • Séquence : collection ordonnée avec autorisation de U

Association qualifiée (2) Exemple (1)

ENSAF 102 M.BERRADA ENSAF 103 M.BERRADA

Exemple (2) Exemple (3)

ENSAF 104 M.BERRADA ENSAF 105 M.BERRADA

Package : Pour Structurer Exemple

ENSAF 106 M.BERRADA ENSAF 107 M.BERRADA

ENSAF 108 M.BERRADA ENSAF 109 M.BERRADA

ENSAF 110 M.BERRADA ENSAF 111 M.BERRADA

Définition (2) Objet

ENSAF 112 M.BERRADA ENSAF 113 M.BERRADA

Objet (2) Objet (3)

ENSAF 114 M.BERRADA ENSAF 115 M.BERRADA

Objet Composite (Représentation UML) Lien

ENSAF 116 M.BERRADA ENSAF 117 M.BERRADA