Upload
saf-bes
View
104
Download
2
Embed Size (px)
Citation preview
Wajdi BOUAJILA
Institut Supérieur des Etudes Technologiques de DjerbaDépartement technologies de l’Informatique
Plan Qu’est que UML?
Diagramme de cas d’utilisation
Diagramme de classes
Diagramme de séquences
Diagramme de communication
Diagramme d’état-transition
Diagramme d’activité
Diagramme de paquetage
Diagramme de déploiement
Diagramme de composant
Correction du projet Sivex
Proposition d’une correction de concours (2009)
La modélisation : Pourquoi
Pourquoi réaliser des modèles?
A quoi cela peut-il vraiment servir à part me faire perdre du temps alors qu’il serait plus rapide de passer directement au codage?
Vous avez peut être aussi travaillé à partir de modèles réalisés par les autres et vous n’avez pas vraiment saisie l’intérêt?
Voire vous vous êtes dit « mes ces modèles sont faux, je ne fais pas comme cela dans mon code »?
Un modèle est avant tout une représentation abstraite du monde réel.
=> Un modèle va donc nous servir à communiquer et échanger des points de vue afin d’avoir une compréhension commune et précise d’un même problème.
Un modèle ?
Pour un problème complexe, il est conceptuellement impossible de l’appréhender d’un seul bloc=> dégrossir le problème
Ce mode de résonnement est à la base même des niveaux d’abstraction que l’on retrouve dans les méthodes :
Merise (niveau conceptuel, niveau logique, niveau physique)
RUP1 (niveau fonctionnel, niveau analyse, niveau conception).
=>enrichir un modèle de niveau N par l’analyse de niveau N+1.
C’est un outil pour documenter
Les niveaux d’abstraction
Historique d'UML
Booch-93 Rumbaugh( OMT2)
Oct-950.8
Jacobson (use case - sdl)
Juillet-960.9
Janv-971.0
Nov-971.0
Sept-971.1 (OMG)
20001.4
20052.0
20062.1
UML 1.x
UML 2.0
UML 2.3
C’est quoi UML?
Objectifs : spécifier, construire, visualiser et documenter les systèmes à base de logiciel
Pour communiquer, travailler à plusieurs
Pour Comprendre la «big picture»
Par approche orientée objets
Avec différents modèles pour différentes vues
UML : Langage et non simple notation graphique (ni méthode)
UML est Indépendant des méthodologies
UML Support des systèmes concurrents et répartis, à base de composants
UML: un méta-langage de modélisation pour unifier les modèles utilisés dans les méthodes
Diagramme de Use case
La notation UML
D. Cas d’utilisation : les acteurs
Un acteur est un rôle d’un ou plusieurs objetssitués à l’extérieur du système et qui interagissentavec lui pour remplir une fonctionnalité donnée de ce système.Un acteur caractérise le rôle joué par un objet àl’extérieur du système.
Uti lisateur
• Un acteur parle au système (Acteur principal)• Le système parle à un acteur (Acteur secondaire)• Un acteur est :
• Un humain (via une IHM)• Du soft• Du hard
<<actor>>
Autre Système
Use Case :Use Case
Un Cas d’utilisation ( use case ) est une fonctionnalité remplie par le système et qui semanifeste par un ensemble de messages échangésentre le système et un ou plusieurs acteurs.
UtilisateurVerifierBonneMarche
CapteurTemperat
ure
Exemple
Consulter solde
compte
Client
Technicien
Distributeur de billets
Retirer de l ’agent
Mettre en marche / arrêter
Ravitailler le coffre
visualise
débite
Cas d ’utilisation objectif du système motivé par un
besoin
Acteurpersonne ou système externe à l ’origine d ’une interaction avec le systèmes
Paquetage
regroupe des éléments de modélisation
Nature de l ’interaction
Le technicien éteint le distributeur avant de ravitailler le coffre
On ne peut retirer de l ’argent que dans la limite du stock
<<actor>>
SI Banque
Acteur secondaire
Liens entre cas d ’utilisation
Trois types de liens entre cas d’utilisation : Extension (<<extends>>) : comportement optionnel du
système (variation d’un comportement « normal ») Inclusion (<<includes>>) : un cas intègre le
comportement d’un autre (raffinement ou factorisation) Utilisation (<< uses>>) : spécialisation avec héritage
(ajout ou remplacement de comportement)
Extends ou uses utilisent l’idée de factorisation, mais : Dans l’extension, un acteur réalise le cas de base et ses
extensions Dans l’utilisation, il n’y a pas en général d’acteur associé
au cas commun
Stéréotypes
Cas d ’utilisation et scénarios
Un scénario est une série d ’événements ordonnés
dans le temps, simulant une exécution particulière du
système
Pour chaque cas d ’utilisation, il existe un ou plusieurs scénarios
dont la description permet d ’expliciter le comportement du
système pour une situation donnée.
Appelant Appelé
téléphoner
communication directe
ligne occupée
sans réponse
communication par répondeur
ligne en dérangement
etc...
Transition vers les objets
La réalisation d ’un cas d ’utilisation nécessite la
collaboration de plusieurs objets
•Chaque objet de la collaboration participe à la réalisation des scénarios.
• Chaque scénario peut être décrit par rapport aux interactions entre les objets de la collaboration à travers
• un diagramme de collaboration
• ou
• un diagramme de séquence
exempleUne société de vente par correspondance vous demande de développer sonsystème informatique. Ce système doit pouvoir prendre en compte descommandes passées par la poste et des commandes passées par internet. Ildoit suivre les expéditions qui ne sont effectuées que si le paiement est OK.Les paiements se font par carte bancaire dans le cas d'internet et par chèquedans le cas de la poste. Les paiements sont validés par un système bancaireappartenant à la société et existant. Il faut récupérer ce système. Lenouveau système est chargé aussi de la gestion de stocks, lorsqu'un articleatteint un seuil minimal, alors il faut passer une nouvelle commande aufournisseur adéquat. A la réception de la commande, la mise à jour de labase est faite par un employé. Dans le cas d'un paiement accepté et de stockdisponible, l'expédition est faite par un robot existant au quel il suffit depasser les coordonnées du client, et la liste des produits achetés. En casd'indisponibilité, une lettre doit être envoyé au client.
Ce qui nous demande généralement
Un tableau dont les noms des colonnes sont:
Scénarios pour chaque cas d’utilisation
Nom d’ acteur Description Rôle
correction
Robot
ClientPoste
ClientInternet
Verifier StockFournisseur
Passer Commande Internet
include
Passer Commande Posteinclude
SystemBancaireVerifier Paiement
Include
Include
Expedier Commande
Extend
Diagramme de séquences
La notation UML
Diagramme de séquences
Un diagramme de classe permet de décrire les intéractions entre différentes entités et/ou acteurs : par exemple des objets dans un modèle d'un logiciel, des sous-systèmes dans un modèle d'un système complet.- Le temps est représenté comme s'écoulant du haut vers le bas le long des "lignes de vie" (lifeline) des entités.- Des flèches représentent les messages qui transitent d'une entité vers l'autre. Le nom des message apparaît sur chaque flèche. Si l'extrémité de la flèche est pleine, le message est synchrone. Si l'extrémité de la flèche est creuse, le message est asynchone.
Événements et messages
Message Asynchrone :
Message Synchrone :
Les fragments combinés
Un fragment combiné représente des articulations d'intéractions.
Il existe 10 opérateurs définis dans la notation UML2.0
permettent de décrire des diagrammes de séquence de manière compacte
Opérateur "Alternative“ -- AltL'opérateur "alt" désigne un choix, une alternative. Il représente deux comportements possibles : c'est en quelque sorte l'équivalent du SI...ALORS...SINON
Opérateur"Option“ -- Opt
L'opérateur "opt"désigne un fragment combiné optionnel comme son nom l'indique : c'est à dire qu'il représente un comportement qui peut se produire... ou pas. Un fragment optionnel est équivalent à un fragment "alt" qui ne posséderait pas d'opérande else (qui n'aurait qu'une seule branche)
Opérateur "Break"
L'équivalent de ce diagramme de séquence sans l'opérateur break correspond aux deux diagrammes de séquence dans le diapositive suivant:
Opérateur "Parallel“ -- par
L'opérateur "par" est utilisé pour représenter des intéractionsayant lieu en parallèle
Opérateur "Loop"
L'opérateur "Loop" (boucle) est noté "loop". Cet opérateur est utilisé pour décrire un ensemble d'intéraction qui s'exécutent en boucle. En général, une contrainte appelée garde indique le nombre de répétitions (minimum et maximum) ou bien une condition booléenne à respecter.
Fragment combiné -- mixte
Diagramme de communication
La notation UML
Définition
Un diagramme de communication est un diagramme d'interaction qui présente les messages échangés en fonction de la structure.
un diagramme de communication rend compte de l'organisation spatiale des participants à l'interaction
Il est souvent utilisé pour illustrer un cas d'utilisation ou pour décrire une opération.
Le diagramme de communication aide à valider les associations du diagramme de classe en les utilisant comme support de transmission des messages.
Éléments composant une collaboration:1. Objets: Instance d’une classe.
Rectangle avec étiquette de la forme nomObjet:nomClasse ou :nomClasseOn représente uniquement les objets pertinents i.e. interagissant dans le cas d’utilisation ou le scénario qu’on veut décrire.
2. Liens: Instances de certaines associations dans le diagramme de classes. On ne représente que les instances d’associations pertinentes pour la collaboration décrite.
3. Acteurs: On peut représenter les acteurs participant au cas d’utilisation ou scénario décrit. L’acteur initiant un cas d’utilisation est appelé initiateur.
Exemple sans lien
mb:MembreBiblio
unExemplaire:Exemplaire
leLivre :Livre
unMembre: Emprunteur
Ajout des messages sur les liens...
On indique les messages à côté des liens appropriés sur le diagramme de collaboration.
La flèche est issue de l’émetteur et pointe vers le destinataire.
L’association correspondante dans le diagramme de classe doit être navigable dans la même direction que la flèche.
Le destinataire doit pouvoir comprendre le message (opération appropriée?)
n°, cond, …: message
Représentation des interactions Numéro du message: Lorsqu’un objet O reçoit un
message (synchrone), le numéro de ce message est utilisé comme préfixe pour tous les messages envoyés par O… jusqu’à ce que O réponde à ce message.
En général, les messages de retour n’apparaissent pas explicitement dans les diagrammes de collaboration.
Types de messages: simple, synchrone, asynchrone…
Aussi: garde, itération, etc.
Attention (cohérence des divers diagrammes) :
methodeR doit être une méthode de la Classe A dans le diagramme de Classes, MéthodeS doit être une méthode de la Classe B dans le diagramme de Classes MéthodeT doit être une méthode de la Classe D dans le diagramme de Classes
Représentation des messages Un message est spécifié sous la forme suivante :
cond est une condition sous forme d’expression booléenne entre crochets. séq est le numéro de séquence du message. On numérote les messages par
envoi et sous-envoi désignés par des chiffres séparés par des points : ainsi l’envoi du message 1.4.3 est antérieur à celui du message 1.4.4 mais postérieur à celui du message 1.3.5. La simultanéité d’un envoi est désignée
par une lettre : les messages 1.6.a et 1.6.b sont envoyés en même temps. iter spécifie (en langage naturel, entre crochets) l’envoi séquentiel (ou en
parallèle, avec ||). On peut omettre cette spécification et ne garder que le caractère "*" (ou "*||") pour désigner un message récurrent envoyé un certain nombre de fois.
r est la valeur de retour du message, qui sera par exemple transmise en paramètre à un autre message.
msg est le nom du message. par désigne les paramètres (optionnels) du message.
Représentation des messages
A
B
1: message()
Message
A
B
1: [cond] message()
A
B
1: res:= message()
A
B
1: *[i:=1..n] message()
BB
A
B C
1: m1()
1.1: m2()
1.2: m3()
2: m4() 1.a: m1()
A
B C
1.b: m2()
Message conditionnel Message avec retour
Itération Invocations synchrones Concurrence
Exemple avec interactions
leMembre:MembreBiblio
cetExemplaire:Exemplaire
leLivre :Livre
unMembre: Emprunteur
emprunter(cetExemplaire)
1: okPourEmprunter()
2: emprunter
2.1: est_emprunté
Création et destruction dynamiques d’objets
Ajout d’une contrainte ({new} ou {destroyed}) après l’étiquette dans le rectangle représentant l’objet créé ou détruit.
Si au cours des interactions représentées par le diagramme, un objet est créé puis détruit, on utilise la contrainte {transient}.
Les messages de création et de destruction d’objets: new, destroy…
exemple
:ProfAgrégé {new}
:ProfAdjoint {destroyed}
: Doyen
1: k : = obtenirNom()
2: new ProfAgrégé(n)
3 : destroy()
Message avec garde
concurrence
Le message 1 est un message simple itératif.
Les messages 2.a et 2.b sont des messages synchrones concurrents.
Les messages 3.a et 3.b sont des messages asynchrones concurrents
t:TourDeContrôle
b:Boeing747
a1:Avionétat = à_terre
position = piste
a2:Avionétat = à_terre
position = piste
:Pompiers1: * alerte()
3.b: atterrir(piste)
3.a: envoyer(piste)
2.b: déplacer(piste,parking)
2.a: déplacer(piste,parking)
Diagramme d’état-transition
La notation UML
Introduction
Permet de décrire le cycle de vie d’un Objet :
Les différents états qu’il peut atteindre
Les règles régissant le passage d’un état à un autre
Au niveau métier permet de décrire les règles de
gestion assurant comment sont utilisés les objets du
monde (ex. facture).
Au niveau logique :
Transposition au niveau des objets concrets (ie futur code)
Spécification de règles de comportement des objets « concrets » (ex. objet graphique).
État :
Objet: caractérisé en principe par l’ensemble des valeurs prises par les attributs de l’objet à un instant t. Mais selon cas peut se réduire à l’étude de certains attributs.
Métier: caractérise l’état d’une entité au sens large : état stable, en cours d’exécution, attente d’un évènement…
Transition :
traduit le passage possible d’un état à un autre avec éventuellement des conditions sur l’événement à l’origine de l’activation de la transition (condition de garde).
Type d’état
Type d’État :
État initial : traduit l’initialisation du diagramme d’état (1 seul par diagramme).
État final : caractérise la fin du diagramme (0..n).
État simple : caractérise l’état d’un objet
État composite: permet de gérer l’abstraction en définissant un « super » état dans lequel une séquence d’état et de transition peuvent décrire plus finement ce qui se passe dans cet état (ex. l’état Inscription peut être décomposé en état saisi, état frais inscription calculés, frais payés, inscrit).
Type d’évènement
Type d’évènement pouvant déclencher une transition :
Réception d’un signal : envoi d’un message asynchrone par un autre objet ou par un acteur (point de vue métier)
Appel de méthode (call event) sur l’objet modélisé (synchrone ou asynchrone). (point de vue objet)
Écoulement d’une durée (time event) relative (10 sec) ou absolue (date précise). Utilisation du mot clé after
Changement de condition (change event) : décrite par une expression booléenne sur des variables (état d’une variable, d’un objet, d’une valeur globale) mot clé when
Exemple
Etat et transition interne
Diagramme actif: possibilité de spécifier des actions…
Action : opération associée à un état non interruptible
Activité : idem mais interruptible.
Ces opérations peuvent être exécutées :
Dés l’entrée dans l’état
A la sortie de l’état
Pendant l’activation de l’état interruptible)
Les transitions peuvent également réaliser des actions
Point de décision
Il est possible de représenter des alternatives pour franchir une transition, on utilise soit:
Point de jonction ( représenter par )
Elle permet de partager des segments de transition.
Tous les chemin sont potentiellement valides.
Point de choix ( représenter par )
Saisie formulaire
Afficher problèmes
Demander confirmation
Go/valideEntrée() Entrée valide
[else]
Etat composite
Un état composite est graphiquement composé en deux ou plusieurs sous-état.
Exemple cabinet téléphonique
Début
Entry/tonalité « prêt »Exit/cesse tonalité
Numéroter
Entry/numéro.apprend(n)
Chiffrer (n)
Chiffrer (n) [Num.valid]
Composer numéro
Composer numéro
Gestion de la concurrence
Les diagramme d’état permettent de décrire efficacement les mécanismes concurrents.
fork join
état historique
Exemple de diagramme possédant un état historique profond permettant de reprendre le programme de lavage ou de séchage d'une voiture à l'endroit où il était arrivé avant d'être interrompu.
Diagramme de paquetage
La notation UML
Définition
Un diagramme de paquetage est un diagramme de structure qui montre les paquetages et, éventuellement, les relations entre eux.
Un paquetage étant un conteneur logique permettant de regrouper et d'organiser les éléments dans le
modèle UML (classes, use cases, etc.)
le Diagramme de paquetage sert à représenter les dépendances entre paquetages, c’est-à-dire les dépendances entre ensembles de définitions.
Utilité
Très utilisé, indispensable pour les grands modèle
Indispensable pour définir l’architecture d’un modèle, pour gérer un modèle et son développement par une équipe
Utile dès l’analyse et fondamentale en conception
Dépendance
un paquetage est dépendant d’un autre s’il l’utilise…
SimpleChat
ClientCommon
OCSF
ClientServer
<<import>>
Diagramme de composant
La notation UML
Définition
Un composant doit fournir un service bien précis
Les fonctionnalités qu’il encapsule doivent être cohérentes entre elles et génériques
Un composant est une unité autonome représentée par un classeur structuré, stéréotypé «component», comportant une ou plusieurs interfaces requises ou offertes.
Son comportement interne, généralement réalisé par un ensemble de classes, est totalement masqué : seules ses interfaces sont visibles.
Pour montrer les instances des composants, un diagramme de déploiement doit être utilisé
Composant
Composants et interfaces
Composant
Commande
EntréeCmdes
PaiementComptes
Personne
composantinterface requise interfaces offertes
Commande
<<provided interfaces>>
EntréeCmdes
PaiementComptes
<<required interface>>
Person
Composants et relations
Une flèche de dépendance permet de mettre en relation des composant via les interfaces requises et fournies
Système de
commande
AccèsProduit
RechercheClient
Système
d’inventaire
Repositoire
ClientsRechercheClient
AccèsProduit
(3) dépendance
(1) composant
(2) interface
Composants et relations
Planificateur
réservations
GUI
Gestionnaire
d’horairesréservations
mise à jour
mise à jour
Réunions_BD
accèsBD
accèsBD
Composants – Vue de la structure interne
Pour montrer la structure interne d’un composant
:CommandePersonne
:Produit
:Client
ItemCommandable
Magasin
EntréeCmdes
<<delegate>>
Compte
Compte
EntréeCmdes
<<delegate>>
port
Assembly
connector
Entête
LigneCmde*
Diagramme de composants MVC
Diagramme de déploiement
La notation UML
Définition
Un diagramme de déploiement décrit la disposition physique des ressources matérielles qui composent le système
Il montre la répartition des composants sur chaque matériels
Chaque ressource étant matérialisée par un nœud
Chaque ressource est matérialisée par un nœud représenté par un cube comportant un nom
Un nœud est un classeur et peut posséder des attributs (quantité de mémoire, vitesse du processeur, …).
Exemple
GPS satellite
M1:MachineX
M2:MachineX
C1:Client
C2:Client
S:Serveur
Communication
sans fil
TCP/IP
noeuds
lien
Exemple 2
Machine de Joe:PC
:Planificateur
GUI
mise à jour
Admin:MachineHote
:Gestionnaire
Horaires
:Réunions_BD
réservations
Accès_bd
internet
Exemple 3