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