COURS UML

Unified Modeling Language

PLAN Introduction Concepts objet La Notation UML OCL

Introduction

Historique des méthodes orientées objet Durant les années 80-90, on assiste à l’apparition de méthodes d’analyse et de conception orientée « objet »: OOD (Object Oriented Design) de G. Booch (1985), aussi connue sous le nom de Booch OOA/OOD (Object Oriented Analysis / Object Oriented Design) de P. Coad et E. Yourdon (1991) OMT (Object Modeling Technique) de J. Rumbaugh (1991) OOSE (Object Oriented Software Engineering) de I. Jacobson (1992) Les méthodes Booch, OMT et OOSE sont à l’origine de la notation UML

Historique (suite) L’OMG (Object Management Group) est un groupement d’industriels dont l’objectif est la standardisation des technologies objets afin de garantir l’interopérabilité des applications. L’OMG comprend plus de 800 membres, dont les principaux acteurs de l’industrie informatique (IBM, Microsoft, Oracle, Sun …).  http://www.omg.org Un des principaux standards de l’OMG est UML (Unified Modeling Language) dont la 1ère version a été approuvée en 1997. La dernière version d’UML est 2.0. La version présentée ici est la 1.5.

Historique (suite) UML est une notation et non une méthode car elle ne définit par de démarche à respecter. UML a effectué la synthèse des meilleurs concepts et formalismes des précédentes notations.  http://www.uml.org Il est donc possible (et nécessaire !) d’utiliser la notation UML avec une démarche de développement.

Concepts objet

L’approche orientée objet Le monde réel est constitué d’objets (une personne, une voiture, une loi…) Un objet informatique offre une représentation abstraite d’un objet du monde réel dans le but de le simuler. Le logiciel orienté objet va utiliser des objets informatiques communiquant entre eux: objets métiers, objets d’IHM, objets techniques, objets d’accès aux données… Exemple d’objets métiers: un compte bancaire, une facture, un client… Exemple d’autres types d’objets: un écran de consultation de compte, une connexion à une base de données, un composant graphique…

L’approche orientée objet (suite) L’approche objet utilise des principes tout au long du développement : Abstraction : les objets sont issus des classes, qui sont de bonnes abstractions du monde réel Encapsulation : masquage des informations et de l’implémentation des objets, publication d’une interface publique Héritage : permet de récupérer des propriétés et comportements d’autres classes d’objets Relation : certains objets vont être liés entre eux à travers des relations Message : les objets communiquent entre eux par messages

L’approche orientée objet (suite) Les avantages de l’approche objet : La stabilité de la modélisation par rapport aux entités du monde réel La construction itérative du logiciel facilitée par le couplage faible entre composants   La réutilisation des composants développés (par héritage ou composition) Une bonne cohérence de la conception en modélisant ensemble les données et les traitements Une représentation cohérente tout au long du cycle de développement: (Analyse objet  Conception objet  Programmation objet)

L’approche orientée objet (suite) Les inconvénients de l’approche objet: Tout n'est pas objet ! (SGBD, langages …) Penser objet oblige à changer de mentalité L'approche objet est moins intuitive que l'approche fonctionnelle

Les Concepts L’approche objet utilise les concepts suivants: Objet Message Classe et instance Attributs Opérations Relation Héritage et polymorphisme

L’Objet Objet = identité + état + comportement Un objet possède une identité qui caractérise son existence propre. Elle est invariante au cours de la vie de l'objet et indépendante de ses valeurs d’attributs. Elle permet de désigner l'objet et de créer des références vers l'objet. Une référence vers un objet est utilisée pour envoyer un message à cet objet.

L’Objet Un objet est caractérisé par un ensemble d’attributs (ex : nom, prénom, age, adresse pour un objet « Personne »). Un attribut d'un objet peut avoir pour valeur l'identité d'un objet, c'est-à-dire détenir une référence vers un objet. Un ensemble d'opérations définissent le comportement de l’objet (ex : setAge (param) ). L’état d’un objet est constitué des valeurs instantanées de ses attributs. Ex : l’objet « Martin » est dans l’état « Adulte » si son attribut Age est >= 18 ans. L’état d’un objet est la conséquence des opérations effectuées sur cet objet ( Encapsulation) Ex: l’objet « Martin » est dans l’état « Adulte » car on a invoqué l’opération setAge(18)

L’Objet Un objet est une instance de classe (un « exemplaire » d’une classe). Une classe est un type de données abstrait, caractérisé par des propriétés (attributs et opérations) communes à des objets et permettant de créer des objets possédant ces propriétés. L’encapsulation consiste à masquer les détails d'implémentation d'un objet, en définissant une interface. L'interface est la vue externe d'un objet (= ensemble des opérations publiques de l’objet). Elle définit les opérations accessibles aux utilisateurs de l'objet par le biais de messages.

L’Objet L'encapsulation facilite l'évolution d'une application car elle stabilise l'utilisation des objets. On peut modifier l'implémentation des attributs d'un objet sans modifier son interface. L'encapsulation garantit l'intégrité des données, car elle permet d'interdire l'accès direct aux attributs des objets (utilisation d’accesseurs). Un objet n’est manipulable qu’à travers son interface. Un objet respecte les principes qui permettent d’obtenir une bonne modularité du logiciel: Cohésion interne très forte Couplage faible avec les autres objets Interface explicite

setAlarmeReservoir() Exemple d’objet Opérations publiques = son interface Attributs Son nom La voiture de Jean getKilometrage() kilometrage : ... vitesse : ... immatriculation : ... setVitesse(param) L'objet remplirReservoir() setAlarmeReservoir() Opération privée

L’Objet Il existe trois niveaux de visibilité des attributs et des opérations : - privé ( l’élément n’est visible que par la classe) + public (l’élément est visible par toutes les autres classes ) # protégé (l’élément est visible par la classe, ses sous classes et les classes du même paquetage)

Message Un message est un ordre d’action qui est envoyé à un objet. Les objets sont émetteurs et récepteurs de messages. Dans un développement objet, les fonctions attendues du système sont réalisées par des échanges de messages entre objets du système.

Message Un message peut être envoyé en mode synchrone ou asynchrone: Mode Synchrone: l’objet émetteur suspend son activité en attente de la réponse (ex: coup de téléphone)  Un seul objet actif Mode Asynchrone: l’objet émetteur poursuit son activité après l’envoi du message (ex: envoi d’un email)  Plusieurs objets actifs

Message : un exemple Méthode Atterrir ( ) de l’objet Avion 1 Etat de l’objet Avion 1 = En Vol Méthode Décoller ( ) de l’objet Avion 1 Message n°1 = Invocation de la méthode Avion 1.Atterrir ( ) Objet Tour de contrôle Méthode Atterrir ( ) de l’objet Avion 2 Etat de l’objet Avion 2 = au Sol Méthode Décoller ( ) de l’objet Avion 2 Message n°2 = Invocation de la méthode Avion 2.Décoller ( )

Classe La Classe est une abstraction des propriétés communes (attributs et opérations) d’un ensemble d’objets. La classe va se comporter comme un moule capable des créer des objets conformes à sa définition: les instances 1234 XY 31 Renault Mégane 10 700 km 6789 AB 33 Ford Fiesta 120 450 km

Attibuts d’instance et de classe Un objet possède ses propres valeurs d’attributs appelées attributs d’instance. Une classe peut aussi posséder des attributs, dits attributs de classe ou attributs statiques. Ces attributs de classe ont une valeur unique pour toutes les instances de la classe. Ils peuvent servir de constantes.

Opération Une opération est un ensemble d’instructions formant l’unité de code executable pour un objet. Une opération est caractérisée par sa signature: Nom de l’opération Nombre et type des arguments en entrée Type de la valeur éventuelle de retour Rappel: chaque opération a un argument implicite qui est l’objet auquel elle appartient. getAge(dateNaissance Date, dateJour Date) : integer Exemple: varAge = martin.getAge(17/06/72, 21/09/2003)

Opération Opération de classe (ou opération statique): c’est une opération qui concerne la classe plus que les objets. Voiture.getTauxTVA(); ou v1. getTauxTVA(); Surcharge d’opération: on parle de surcharge d’opération quand il existe plusieurs opérations possédant le même nom (mais pas la même signature) dans une même classe.

Relation Dans la modélisation objet, on définit 2 types de relation : Association simple :   Elle caractérise une relation directe, structurelle entre classes. Ce sont souvent des formes verbales qui apparaissent dans le problème à modéliser. (Ex: un adhérent Emprunte un ouvrage).  Agrégation: L'agrégation est une relation qui permet de décrire un objet composite en terme d'objets qui le constituent (ex. un objet voiture est composé des objets moteur, carrosserie, pneus, ...).

Héritage La généralisation consiste à factoriser les éléments communs à un ensemble de classes dans une classe plus générale. La généralisation permet de hiérarchiser les classes entre elles. L'héritage est un mécanisme de transmission des propriétés d'une classe (ses attributs et opérations) vers une sous-classe. La spécialisation d’une classe permet d’ajouter des caractéristiques spécifiques. L'héritage peut être simple ou multiple. L'héritage permet la réutilisation.

Héritage et Polymorphisme Le polymorphisme représente la faculté d'une opération à pouvoir s'appliquer à des objets de classes différentes (redéfinition du code en gardant le même nom d’opération). Le polymorphisme augmente la généricité du code.

La Notation UML

Les Concepts de base Il existe un petit nombre de concepts généraux applicables à tous les diagrammes: Les Notes Les Stéréotypes Les Contraintes Les Paquetages

Les Notes Une note est un commentaire placé sur un diagramme. Une note peut posséder le stéréotype <<contrainte>>. Une note peut servir à préciser une valeur (ex: version = 3.2).

Les Stéréotypes Les stéréotypes permettent de définir des nouveaux types dans un diagramme. C’est le principal facteur d’extensibilité au sein d’UML. Symbole: << nom du stéréotype>>

Les Contraintes Les contraintes spécifient des conditions qui doivent être respectées. Une contrainte est représentée par un texte entre accolades { }. UML propose OCL (Object Constraint Language) pour exprimer les contraintes.

Les Paquetages Les paquetages permettent de regrouper les éléments de modélisation. Un paquetage peut contenir d’autres sous-paquetages sans limites de niveaux. Le paquetage est un espace de nommage. Un paquetage peut importer une classe issue d’un autre paquetage. Une dépendance entre deux paquetages signifie qu’au moins une classe du paquetage client utilise les services offerts par une classe du paquetage fournisseur. UML définit l’opérateur  : :  pour l’appartenance d’une classe à un paquetage.

Exemple Véhicule : : Voiture signifie que la classe Voiture appartient au paquetage Véhicule.

Les diagrammes d’UML UML repose sur 9 modèles (appelés diagrammes). Un modèle est une description simplifiée d'un système qui permet de le comprendre et de le simuler. En informatique, la modélisation consiste tout d'abord à décrire un problème puis à décrire la solution à ce problème. Ces activités s'appellent respectivement l'analyse et la conception.

Les diagrammes d’UML Les 9 diagrammes d’UML se répartissent en 2 familles: Les diagrammes structurels (statiques) : diagramme de classes diagramme d'objets diagramme de déploiement diagramme de composants Les diagrammes comportementaux (dynamiques) : diagramme d'activités diagramme de séquence diagramme d'états-transitions diagramme de collaboration diagramme de cas d'utilisation

Le diagramme de classes C’est le diagramme le plus important d’UML. Exprime l'aspect structurel d'un système en termes de classes et de relations. A l'intérieur des classes et des relations doivent apparaître les attributs et les opérations. Il faut préciser de plus les rôles des classes dans la relation et leur multiplicité (nombres d’instances d’une classe qui peuvent être en association avec une instance de l'autre classe). Diagramme de classes = Modèle Entité-Association de Merise

La Classe

Attributs UML permet de définir les attributs dérivés (attributs qui sont calculés à partir d’autres éléments) par le symbole  / . Les attributs de classe peuvent être utilisés comme des constantes (ex: Pi) ou non (ex: nb d’instances d’une classe). Les opérations de classe permettent de manipuler les attributs de classe (ex : getPi( ) ).

Visibilité Il existe trois niveaux de visibilité des attributs et des opérations : - privé ( l’élément n’est visible que par la classe) + public (l’élément est visible par toutes les autres classes ) # protégé (l’élément est visible par la classe, ses sous classes et les classes du même paquetage) Par défaut, les opérations sont publiques et les attributs privés

Les Interfaces L'interface d'une classe représente son comportement visible (c'est à dire l'ensemble de ses opérations publiques) se représente au moyen d’un cercle ou par une classe avec le stéréotype <<interface>>.

La Classe paramétrable Les classes paramétrables sont des modèles de classe. Elles doivent être instanciées avec des paramètres pour obtenir une classe concrète.

La Classe abstraite UML représente une classe abstraite avec le stéréotype « abstraite ». Le nom de la classe est noté en italique. Les classes abstraites ne sont pas instanciables. Elles servent de spécification (moule). Dés qu'une classe contient une opération abstraite (dont le code n'est pas défini), elle devient abstraite.

Autres types de classes Des types de classes particulières sont définissables par des stéréotypes: << utilitaire >> : Ce genre de classe permet de regrouper des éléments sans vouloir construire une classe complète (ex : des fonctions mathématiques). << association>> : Transformation d'une association *,* en classe pour pouvoir y placer des attributs ou des opérations.

Exemples

Les Relations Les relations sont représentées par des traits continus entre les classes. On peut nommer les relations avec un verbe au milieu de la ligne. On peut indiquer à chaque extrémité d'une relation le rôle qui décrit comment une classe voit l'autre classe. Le nommage des rôles est sous forme nominale. On doit préciser la multiplicité des associations. Ceci indique à combien d’objets de la classe "en face" correspond un objet de la classe de "départ". On peut restreindre le sens de navigation d’une relation avec une flêche.

Les Multiplicités 1..1 ou 1 un et un seul 0..1 zéro ou un M .. N de M à N * Plusieurs 0..* de zéro à plusieurs 1..* de un à plusieurs

La Restriction (ou qualification) d’association La restriction consiste à sélectionner un sous-ensemble d’objets qui participent à l’association. La sélection des objets est caractérisée par un attribut que l’on appelle clé. Tous les objets de la classe qui vérifient la clé feront partie de l’association.

L’Agrégation et la Composition Une agrégation représente une association non symétrique dans laquelle une extrémité de l’association joue un rôle prédominant par rapport à l’autre extrémité.   La composition (ou agrégation forte) est une association correspondant à la contenance. Si on détruit l'objet composé, les objets composants sont détruits aussi. Dans une composition, un composant ne peut pas appartenir à plusieurs composé.

L’Agrégation et la Composition : exemple

La Généralisation La généralisation consiste à factoriser les éléments communs (attributs, opérations, relations) d'un ensemble de classes dans une super classe. Les attributs et opérations publiques et protégées de la super classe sont accessibles dans la sous-classe. La généralisation ne porte pas de nom, elle signifie "est un". L'héritage permet la réutilisation de classes existantes pour créer de nouvelles classes. L'héritage peut être simple ou multiple.  La classe spécialisée peut avoir ses propres attributs, opérations ou relations.

La Généralisation: exemple

Le Polymorphisme Le polymorphisme d’opérations permet de déclencher  des opérations différentes en réponse à un même message. Chaque sous-classe hérite de la spécification des opérations de sa super-classe mais a la possibilité de modifier localement le code de ces opérations tout en conservant leur nom initial.   A ne pas confondre avec la surcharge des opérations qui permet de donner le même nom à une famille d’opérations mais avec des paramètres différents pour chacune d'entre elles.

Le Polymorphisme : exemple

Le Polymorphisme : généricité du code public class Zoo { private String adresse; private Vector mesAnimaux = new Vector(); public Zoo(String adr) { adresse = adr; } public Boolean coucherAnimaux() for ( int i = 0; i < mesAnimaux.size() ; i++ ) Animal a = (Animal) mesAnimaux.elementAt(i) ; a.Dormir(); return (true);

Le diagramme des cas d’utilisation (ou Use Case) L'intérêt des cas d'utilisation est de cerner les besoins réels des utilisateurs. Les UC sont nécessaires pour définir et délimiter les fonctions attendues du système.   UML utilise le concept d'acteur pour définir un utilisateur. Il existe 3 catégories d'acteurs:  les acteurs externes (envoient des évènements et reçoivent des résultats) les acteurs principaux (interagissent directement avec le système) = postes de travail du MOT de Merise les acteurs secondaires (administrent et gèrent le système)

Le diagramme des cas d’utilisation (ou Use Case) On peut avoir un héritage entre acteurs. L’acteur représente un rôle joué par une personne ou un autre système qui interagit avec le système. Un cas d’utilisation regroupe plusieurs scénarios d’utilisation du système. Un scénario représente un cas particulier d'un cas d'utilisation.  Les cas d’utilisation peuvent être en relations (inclusion, extension ou généralisation).

Une fiche de description d’Use Case Titre : Résumé : Acteurs : Date de création / mise à jour : Auteur : Version : Description des scénarios: Préconditions : Postconditions : Scénario nominal : Action de l’acteur Action du système …. …. Enchaînements alternatifs / d ’erreurs: Autres besoins: Commentaires :

Relations entre Use Case La relation d'inclusion indique que l'UC destination est obligatoirement utilisée par l'UC source. Cette relation permet de créer des UC élémentaires réutilisables par d'autres UC. L'extension indique que l'UC source est éventuellement exécutée en complément de l'UC destination. Cette relation permet notamment de représenter les cas d'erreur. La généralisation indique une factorisation d'UC. Par la suite, chaque UC pourra être représentée par un diagramme d’activités Le scénario nominal de chaque UC donnera lieu à un diagramme de séquence. 

Le diagramme des cas d’utilisation : exemple générique

Le diagramme des cas d’utilisation : exemple pratique

Construction du diagramme des UC 1 - Recenser les acteurs et les hiérarchiser. 2 - Pour chaque acteur, identifier les UC principaux qu'il déclenche. 3 - Organiser les UC grâce aux relations de généralisation, d'inclusion et d'extension. 4 - Construire le diagramme des UC.

Le diagramme d’objets Les diagrammes d'objets permettent la représentation spatiale des objets et de leurs liens. Chaque objet est une instance de classe et les liens entre ces objets sont les instances des relations entre les classes.

Le diagramme d’objets L’instanciation des classes composites donne des objets composites. Ils peuvent être représentés par "un super objet" de la façon suivante. Objet composite N°1 Objet composite N°2 Objet composé

Le diagramme d’objets Le nom de la classe peut contenir le chemin complet d'accès, composé à partir des différents paquetages englobants séparés par des doubles deux points. On peut aussi représenter des multi-objets (objets de la même classe en x exemplaires)

Le diagramme d’objets Parallèle entre le diagramme d'objets et le diagramme de classes :

Les diagrammes d'interaction 2 notations : les diagrammes de séquence les diagrammes de collaboration Diagrammes de séquence : mise en évidence des objets et des messages échangés correspondent à la structure temporelle Diagrammes de collaboration : correspondent à la structure spatiale Nota : les 2 notations sont duales, et souvent on se contente de l'une ou de l'autre !

Les diagrammes de Collaboration Les diagrammes de collaboration sont des diagrammes d'objets où figurent les interactions entre objets. Les interactions sont réalisées par échanges de messages. Le diagramme représente ces messages à l’aide de flèches le long des liens. L’ordre des messages est indiqué par un numéro. Les arguments des messages sont entre parenthèses. Les messages invoqués correspondent à des opérations de l'objet destinataire.

Le diagramme de Collaboration : exemple

Le diagramme de Collaboration Les messages se regroupent en 5 catégories : -        les constructeurs qui créent des objets  -        les destructeurs qui détruisent des objets -        les sélecteurs qui renvoient tout ou partie de l’état d’un objet -        les modificateurs qui changent tout ou partie de l’état d’un objet -      les itérateurs qui visitent le contenu d’une structure de données qui contient plusieurs objets

Le diagramme de Séquence Pour chaque objet étudié, on associe une barre verticale en pointillée appelée " ligne de vie ". Le diagramme possède un axe des temps dirigé du haut vers le bas. Les messages sont représentés par des flèches horizontales orientées de l’émetteur vers le destinataire. Lorsque le message possède un temps de propagation non négligeable, les flèches sont alors obliques.

Le diagramme de Séquence La représentation des périodes d’activité des objets est possible à l’aide de bande rectangulaire le long des lignes de vie des objets et dont les extrémités représentent le début et la fin de l’activité. Dans le diagramme, on peut indiquer les branchements conditionnels par du pseudo-code placé le long de la ligne de vie ou entre crochets sur le message à conditionner. On peut placer en pseudo-code les boucles d’itération (while, for).

Le diagramme de Séquence : exemple 1

Le diagramme de Séquence : exemple 2 Objet anonyme Message Le temps s'écoule verticalement Durée de vie

Le diagramme d’états-transitions Les diagrammes d’états-transitions sont la représentation du comportement d’une classe en terme d’états. On associe à chaque classe un automate fini qui décrit le comportement de la classe.

Les concepts Etat : Transition : Evénement : à tout instant un état représente l’ensemble des valeurs instantanées des attributs et des liens avec les autres objets un état est caractérisé par une certaine durée / stabilité Transition : connexion unidirectionnelle reliant 2 états assure le passage d’un état à l’autre est supposée instantanée une transition peut être réflexive Evénement : l’événement est le déclencheur d’une transition peut être chargé d’information

Les états Un état est toujours nommé Il peut comporter : des actions d’entrée des actions de sortie des activités des inclusions de sous états Etats particuliers : Etat initial Etat final

Les transitions Syntaxe : event [garde] / action,^objet cible.opération(arg) garde = condition à respecter pour franchir la transition action exécutée lors du franchissement de la transition. L’action correspond à une opération de la classe. Etat E1 Etat E2 evenement e[ condition i ] / action1 evenement j

Les transitions On peut indiquer la communication entre objets sur un diagramme d’états-transitions. Pour indiquer l’appel d'opération vers un autre objet, UML définit la syntaxe suivante : Evénement (Arguments) [condition] /Action ^Cible.Opération (arguments)   Exemple d’évènements déclenchant des transitions: l'invocation d'une opération la création ou la destruction d'un objet le temps qui s'écoule (mot-clé tempo(x) ) le changement de certaines conditions

Appel d’opération d’un autre objet: exemple  

Les transitions temporisées UML permet d’indiquer les transitions temporisées en utilisant une transition annotée avec le mot-clé tempo (temps passé).

Le diagramme d’etats-transitions : exemple

Le diagramme d’etats-transitions : exemple

La généralisation d’état UML permet la généralisation d’état. Les états les plus généraux sont appelés les super états et les états les plus spécifiques sont appelés les sous états.   Notion d’héritage appliquée aux états.

La généralisation d’état : exemple

L’agrégation d’états L’agrégation d’état représente un état composé de plusieurs automates qui évoluent simultanément, indépendamment ou non. Notion d’agrégation appliquée aux états. Les sous-états agrégés permettent de représenter la notion de concurrence.

L’agrégation d’états : exemple Voiture

L’agrégation d’états : exemple

L’historique L’historique permet de mémoriser le dernier sous-état qui a été actif dans une généralisation d’états. Le symbole H dans un super état indique que l’on voudrait mémoriser le dernier sous état qui a été actif. Le symbole H* indique que l’on veut mémoriser le dernier sous état qui a été actif quelle que soit la profondeur d’imbrications des sous états.

L’historique : exemple générique

L’historique : exemple pratique

Le diagramme d’activités Un diagramme d’activités représente l’exécution d’un processus sous la forme d’un déroulement d’étapes (ou activités). Une activité est un automate à deux états où le franchissement de la transition est conditionné par une fin d’activité.    

Le diagramme d’activités Dans le diagramme d’activité, il existe deux types de transitions :  -  Les transitions automatiques (une flèche simple) qui sont franchies quand l’activité précédente est finie.  Les transitions gardées (une flèche avec une condition entre crochets) qui sont franchies si une condition est vérifiée.

Le diagramme d’activités Les diagrammes d’activités permettent aussi de visualiser les activités qui s’exécutent en parallèle au moyen de barres de synchronisation. Les transitions au départ d'une barre de synchronisation sont déclenchées simultanément Une barre de synchronisation est franchie lorsque toutes les transitions en entrée sur la barre ont été déclenchées

Le diagramme d’activités Les diagrammes d’activités peuvent être découpés en couloirs d’activité pour visualiser la responsabilité des objets au sein du système à modéliser.

Le diagramme d’activités On peut visualiser les objets dans un diagramme d’activité. La manipulation des objets permet aussi de visualiser la modification de leur état.

Remarques sur les diagrammes d’activités Niveau détaillé : permet, pour une opération donnée d’un objet, d’exprimer graphiquement son algorithme Niveau global : donne une vue macroscopique de l’enchaînement des activités correspond au MOT de Merise

Le diagramme de composants Traduit l’aspect implémentation en proposant une structure en composants et paquetages Les composants représentent les éléments logiciels Propriétés importantes : au sein d’un composant : couplage fort entre composants, couplage faible Paquetage = ensemble de composants

Le diagramme de composants Les diagrammes de composants décrivent les éléments logiciels, appelés modules, et leurs relations dans le système.   Il existe trois types de modules : la spécification (l'interface de la classe), le corps (la réalisation de la classe), la spécification générique (classe paramétrable).  

Le diagramme de composants Un composant peut faire référence au service d’un autre composant. Il y a alors une relation de dépendance entre ces 2 composants.

Le diagramme de composants : exemple

Le diagramme de composants On appelle tâche un composant qui possède son propre flot de contrôle.

Le diagramme de composants La notation UML permet de représenter les programmes principaux et les sous programmes :

Le diagramme de composants : exemple 1

Le diagramme de composants : exemple 2 Ecran consultation cours Interfaces Université Gestion des Erreurs Base de Données etudiant cours matiere prof

Le diagramme de déploiement Les diagrammes de déploiement indiquent la disposition physique des différents matériels qui entrent dans la composition d’un système, ainsi que la disposition des composants logiciels sur ces matériels. Les éléments matériels sont représentés par des cubes (appelés nœuds). La nature du matériel peut être précisée par un stéréotype. Les nœuds sont connectés à l’aide d'un trait qui symbolise un support de communication dont la nature peut être précisée par un stéréotype. On peut indiquer la multiplicité des liaisons entre les nœuds. 

Le diagramme de déploiement : exemple générique

Le diagramme de déploiement : exemple pratique 1 *

Avantages et Limites d ’UML Ambiguïté possible de certains modèles (utilisation à différents niveaux d’abstraction)   Personnalisation possible de la modélisation (stéréotype) Trop de concepts proposés (complexité du langage)    Large palette de modèles Absence de modèles pour représenter l’IHM Norme internationale de modélisation (communication facilitée) Absence de démarche Prise en compte des besoins directs des utilisateurs (diag. UC) Limites d'UML Avantages d'UML

O C L

OCL UML formalise l'expression des contraintes avec OCL (Object Constraint Language). Ce langage formel possède une grammaire élémentaire et peut être interprété par des outils. Il représente un juste milieu, entre langage naturel et langage mathématique. OCL permet ainsi de limiter les ambiguïtés, tout en restant accessible. OCL permet de décrire des invariants dans un modèle, sous forme de pseudo-code : - pré et post-conditions pour une opération, - expressions de navigation, - expressions booléennes, etc...

OCL : exemple (tiré du site http://uml.free.fr/cours/p16.html#ocl) Un hôtel Formulain est constitué d'un certain nombre de chambres. Un responsable de l'hôtel gère la location des chambres. Chaque chambre se loue à un prix donné (suivant ses prestations). L'accès aux salles de bain est compris dans le prix de la location d'une chambre. Certaines chambres comportent une salle de bain, mais pas toutes. Les hôtes de chambres sans salle de bain peuvent utiliser une salle de bain sur le palier. Ces dernières peuvent être utilisées par plusieurs hôtes. Les pièces de l'hôtel qui ne sont ni des chambres, ni des salles de bain (salle de conférences…) ne font pas partie de l'étude. Des personnes peuvent louer une ou plusieurs chambres de l'hôtel, afin d'y résider. L'hôtel héberge donc un certain nombre d’hôtes.

OCL : diagramme de classes de l’exemple

OCL : exemple OCL permet d'enrichir ce diagramme, en décrivant toutes les contraintes et tous les invariants du modèle présenté, de manière normalisée et explicite (à l'intérieur d'une note rattachée à un élément de modélisation du diagramme). Voici quelques exemples de contraintes qu'on pourrait définir sur ce diagramme, avec la syntaxe OCL correspondante. Un hôtel Formulain ne contient jamais d'étage numéro 13 (superstition oblige). context Chambre inv: self.etage <> 13 context SalleDeBain inv: self.etage <> 13

OCL : exemple Le nombre de personnes par chambre doit être inférieur ou égal au nombre de lits dans la chambre louée. Les enfants (accompagnés) de moins de 4 ans ne "comptent pas" dans cette règle de calcul (à hauteur d'un enfant de moins de 4 ans maximum par chambre). context Chambre inv: client->size <= nbDeLits or (client->size = nbDeLits + 1 and client->exists(p : Personne | p.age < 4)) L'étage de chaque chambre est compris entre le premier et le dernier étage de l'hôtel. context Hôtel inv: self.chambre->forAll(c : Chambre | c.etage <= self.etageMax and c.etage >= self.etageMin)

OCL : exemple Chaque étage possède au moins une chambre (sauf l'étage 13, qui n'existe pas...). context Hôtel inv: Sequence{étageMin..étageMax}->forAll (i : Integer | if i <> 13 then self.chambre->select(c : Chambre | c.etage = i)->notEmpty) endif)   On ne peut repeindre une chambre que si elle n'est pas louée. Une fois repeinte, une chambre coûte 10% de plus. context Chambre::repeindre(c : Couleur) pre: client->isEmpty post: prix = prix@pre * 1.1

OCL : exemple Une salle de bain privative ne peut être utilisée que par les personnes qui louent la chambre contenant la salle de bain et une salle de bain sur le palier ne peut être utilisée que par les clients qui logent sur le même palier. context SalleDeBain::utiliser(p : Personne) pre: if chambre->notEmpty then chambre.client->includes(p) else p.chambre.etage = self.etage endif post: nbUtilisateurs = nbUtilisateurs@pre + 1 Le loyer de l'hôtel est égal à la somme du prix de toutes les chambres louées. context Hôtel::calculerLoyer() : réel pre: post: result = self.chambre->select(client->notEmpty).prix->sum

Bibliographie Site Web : http://uml.free.fr, de Laurent Piechocki « UML par la pratique », Pascal Roques, Edition Eyrolles « UML : modéliser un site e-commerce », Pascal Roques, Edition Eyrolles, collection « les cahiers du programmeur » « UML 2 et les design patterns », Craig Larman, Edition Pearson Education « UML : le tout en poche », Martin Fowler et Kendall Scott, Edition CampusPress Référence « UML 2.0 », Martin Fowler, Edition CampusPress

FIN Cliquez ici pour revenir à la page index