la notation uml - lifl · 2013. 9. 9. · mais le même nom peut être utilisé dans 2 paquetages...
Post on 22-Jul-2021
0 Views
Preview:
TRANSCRIPT
Cedric Dumoulin
Plan Le diagramme d’objets Le diagramme de composants Le diagramme de déploiement Exemple
Objets
- 3 -
Diagrammes d’objets Pour représenter un instantané du système
les objets et leurs liens objets = spécification d’instances de classes Liens = instance d’associations
Quand les utiliser ? Pour montrer des instances de classes pour montrer un contexte
collaborations sans messages quand une structure complexe est trop difficile à comprendre avec un diagramme de classe
ex. : récursivité, associations multiples, etc.
- 5 -
Représentation graphique des objets Le nom d’un objet est souligné
Nom : Classe Objet sans type Nom objet anonyme :Classe
- 6 -
Exemple
Un lien est instance d’une association
Artur:Personne Francetele:Société
Sophie:Personne
Jean Pierre:Personne
Mélanie:Personne
subordonné
subordonné
directeurdirecteurdirecteur
subordonné
employés
employés
employés
employés
Personne Sociétéemployés
1..* 0..1directeur
subordonné
0..1
*
- 7 -
Trois types de diagrammes avec des objets
Diagrammes d’objets (point de vue statique)
Diagrammes d’interaction (point de vue dynamique) Diagramme de séquence Diagramme de collaboration
- 9 -
Les Paquetages Elément de structuration par excellence,
un paquetage peut contenir des paquetages, des classes, des diagrammes, ….
C’est un conteneur qui définit un espace de nommage et qui permet de voir (de cacher) son contenu
Les noms sont uniques à l’intérieur d’un paquetage Mais le même nom peut être utilisé dans 2 paquetages différents
Le nom complet d’un élément contient le nom des paquetages <nomP1> ::<nomP2> : ::<nomElement>
- 10 -
PkgClientPkgService
FactureProduit
Prix Prix
Quelques exemples de paquetages (tirés du métamodèle UML)
BehavioralElements
ModelManagement
Foundation
Core ExtensionMechanisms
DataType
CollaborationsUsesCases
ActivityGraphs
StateMachines
Common
Dépendances entre packages Découlent des dépendances
entre éléments des packages notamment les classes
Les dépendances ne sont pas transitives modifier Fournisseur n’oblige pas à
modifier Clientèle
Utilisation des diagrammes de packages
Organisation globale du modèle hiérarchies de packages contenant diagrammes et éléments
Organisation des classes en packages pour contrôler la structure du système
comprendre et partager obtenir une application plus évolutive et facile à maintenir
ne pas se faire déborder par les modifications viser la généricité et la réutilisabilité des packages
avoir une vue claire des flux de dépendances entre packages les minimiser
Packages et nommage Noms pleinement qualifiés
équivalent à chemin absolu ex. package java::util, classe java::util::Date
Principes du découpage en packages Cohérence interne du package : relations étroites entre
classes fermeture commune
les classes changent pour des raisons similaires
réutilisation commune les classes doivent être réutilisées ensemble
Indépendance par rapport aux autres packages Un package d’analyse contient généralement moins de
10 classes
Bien gérer les dépendances Les minimiser pour maintenir un couplage faible
dépendances unidirectionnelles cf. associations navigables
pas de cycles de dépendances ou au moins pas de cycles inter-couches
stabilité des dépendances plus il y a de dépendances entrantes, plus les interfaces de
package doivent être stables
Packages : divers Packages considérés comme
simples regroupements sous-systèmes opérationnels comportement + interfaces
Package vu de l’extérieur classe publique gérant le comportement externe (cf. pattern
Façade) Interfaces
Utilité pratique d’un package Commun regrouper les concepts largement partagés, ou épars
Lien entre packages et couches (niveaux) une couche est composée de packages
Diagrammes de composants
Composant Unité logiciel offrant des services à travers une ou
plusieurs interfaces interfaces fournies
Boite noir La structure interne n’est pas accessible de l’exterieur Communique au travers de ses interfaces
Peut dépendre d’autres composants dont il est client interface requises (implémentées par le composant
dont il dépend)
Composants Partie remplaçable d’un système qui se conforme à des
interfaces et fournit la réalisation de ces interfaces Doit être compris comme un élément qu’on peut
acheter, associer à d’autre composants
Représentation
Diagramme de composants Objectifs
représenter l’organisation et les dépendances entre les composants logiciels décrire les composants et leurs relations dans le système en
construction
Diagramme de composants inclusion des composants relations de fourniture et d’utilisation d’interfaces
Diagramme de composants
Diagramme de déploiement Décrit l’architecture physique du système Est composé de nœud Un nœud représente une entité matérielle capable de
recevoir et exécuter du logiciel
Artefact Forme physique d’un logiciel:
Fichier exécutable, bibliothèque, script, … Un artefact se déploie dans un nœud Un nœud peut recevoir plusieurs artefacts
Lien entre noeuds Ils représentent les liens de communications
ex: le réseau
- 30 -
Diagrammes de classes Ils servent à modéliser l’aspect statique d’un système On peut les utiliser pour:
expliquer le vocabulaire du système (audit) modéliser une collaboration ….
- 31 -
Diagrammes de classes Utilisation des diagrammes de classes pour un audit
(ingénierie du métier, du besoin) Prendre un mot important du vocabulaire, il correspond à un
objet l’abstraire en classe Construire un nouveau diagramme de classes Construire la classe (si elle n’existe pas déjà), la placer au
centre du diagramme Placer autour les mots du vocabulaire (en tant que classes) et
relier les classes entre elles avec les relations appropriées. Recommencer avec un autre mot important du vocabulaire
Lors de la modélisation métier, il ne doit pas y avoir de référence à la future application / à son implémentation
- 32 -
Diagrammes de classes Conseils Sur le fond
Utiliser plusieurs diagrammes !!! Un seul thème par diagramme.
Il ne doit contenir que des éléments nécessaires Les détails doivent être en relation avec le niveau d’abstraction
(attribut et opérations des classes, décoration des associations,..) Pas plus dépouillé que nécessaire, il ne doit pas induire en erreur le
lecteur Ne pas être trop précis trop vite!
Sur la forme Le nom doit exprimer clairement le thème du diagramme Éviter les croisements, rapprocher les éléments liés Utiliser les notes et la couleur pour ajouter du sens
- 33 -
- 34 -
Utilisation de diagrammes de classes pour décrire une structure(modélisation métier)
Un établissement de santé est composé de différents services (médicaux, administratifs, gestions des ressources, hôtelier,…). A la tête de chaque service, on trouve un chef de service qui coordonneune équipe.Différents types d’établissement de santé, les maisons médicalisées, les cliniques, les hôpitaux qui doivent obligatoirement mettre en place un service des urgences. Parmi les hôpitaux, les CHRU sont en relation avec une université.
Règle métier:Un chef de service est un médecin hospitalier.
Utilisation de diagrammes de classes pour décrire une structure(modélisation métier)
les agrégatsIl s’agit d’une association par référence, c'est-à-dire que la classe référencée peut avoir une existence en dehors de la classe référençante
Structuration en paquetages
L’exemple ci-dessus montre que très rapidement, il est nécessaire de regrouper pour s’y retrouver.On décide de créer un paquetage organisation, un paquetage LesPersonnes et un paquetage Général où on mettra ce qu’on n’arrive pas à mettre dans les autres paquetages et qui ont un sens en dehors de ces paquetages.Des dépendances existent entre ces paquetagesOn construit un diagramme de classes santeStructure pour introduire les dépendances:
Utilisation de diagrammes de classes pour décrire une structure (modélisation métier)
Chaque paquetage peut être traité indépendamment (re divisé, nouveaux diagrammes,…)
Le paquetage LesPersonnes
les agrégats forts ou composition. La classe référencée ne peut pas avoir d’existence en dehors de la classe référençanteSi une instance de Personne est créée, une instance (au moins) de Coordonnée est créée également ; si l’instance de Personne disparaît, l’instance de coordonnée disparaît également. Les durées de vie sont liées
PersonneCoordonnee
Adressenom : stringprenom : stringsexe : stringdateNaissance : DatenomMarital : string
telephone : undefinedeMail : undefinedfax : undefined
1 *
1 *
Zoom sur Personne (changement de granularité)
Attributs
Opérations
Personne
MedecinReferent
Dossier
Resultat
MedecinHospitalier
Medical
MembrePersonnel
DossierMedical DossierAdministratif
Patient
VisiteReference : undefined
1
*
1
*
date : Dateduree : integercoût : integer
CPS : undefined1
La classe association: Visite
Ce que vous avez appris Diagramme d’objets Diagramme de Déploiement Diagramme de Composant Exemple
Pour la prochaine séance Lecture obligatoire :
UML 2: Initiation, exemples et exercices corrigés Chap. 5 « La modélisation de la dynamique»
A, B, C, D Chap. 8 Diagramme d ’état
A, B, C, D Chap. 9 La modélisation des activités
top related