UML 2.x

standard défini par l'Object Management Group (OMG). On en est à la version 2.5

Introduction générale à UML

UML 2.3 propose 14 types de diagrammes (9 en UML 1.3).

Selon wikipédia, UML se décompose en plusieurs sous-ensembles :

  • Les vues : Les vues sont les observables du système. Elles décrivent le système d'un point de vue donné, qui peut être organisationnel, dynamique, temporel, architectural, géographique, logique, etc. En combinant toutes ces vues, il est possible de définir (ou retrouver) le système complet.
  • Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci décrivent le contenu des vues, qui sont des notions abstraites. Les diagrammes peuvent faire partie de plusieurs vues.
  • Les modèles d'élément : Les modèles d'élément sont les briques des diagrammes UML, ces modèles sont utilisés dans plusieurs types de diagrammes.
    Exemple d'élément : cas d'utilisation (CU ou cadut'), classe, association, etc.

Les vuesUne façon de mettre en œuvre UML est de considérer différentes vues qui peuvent se superposer pour collaborer à la définition du système :

  • Vue des cas d'utilisation : c'est la description du modèle vu par les acteurs du système. Elle correspond aux besoins attendus par chaque acteur (c'est le QUOI et le QUI).
  • Vue logique : c'est la définition du système vu de l'intérieur. Elle explique comment peuvent être satisfaits les besoins des acteurs (c'est le COMMENT).
  • Vue d'implémentation : cette vue définit les dépendances entre les modules.
  • Vue des processus : c'est la vue temporelle et technique, qui met en œuvre les notions de tâches concurrentes, stimuli, contrôle, synchronisation, etc.
  • Vue de déploiement : cette vue décrit la position géographique et l'architecture physique de chaque élément du système (c'est le OÙ).

Diagrammes

Les 14 diagrammes UML sont dépendants hiérarchiquement et se complètentLes 14 diagrammes UML sont dépendants hiérarchiquement et se complètent, de façon à permettre la modélisation d'un projet tout au long de son cycle de vie.

Diagrammes structurels ou statiques

Object diagram : sert à représenter les instances de classes (objets) utilisées dans le système.

Component diagram : permet de montrer les composants du système d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de données…)

Deployment diagram : sert à représenter les éléments matériels (ordis, périphériques, réseaux, systèmes de stockage…) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent entre eux.

Package diagram : un paquetage étant un conteneur logique permettant de regrouper et d'organiser les éléments dans le modèle UML, le diagramme de paquetage sert à représenter les dépendances entre paquetages, c’est-à-dire les dépendances entre ensembles de définitions.

Composite Structure Diagram : depuis UML 2.x, permet de décrire sous forme de boîte blanche les relations entre composants d'une classe.

Profile diagram : depuis UML 2.2, permet de spécialiser, de personnaliser pour un domaine particulier un meta-modèle de référence d'UML.

Diagrammes comportementaux (Behavior Diagram)

Diagramme des cas d'utilisation (use-cases ou Use Case Diagram) : permet d'identifier les possibilités d'interaction entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire toutes les fonctionnalités que doit fournir le système.
Diagramme états-transitions (State Machine Diagram) : permet de décrire sous forme de machine à états finis le comportement du système ou de ses composants.
Diagramme d'activité (Activity Diagram) : permet de décrire sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants.

Diagrammes d'interaction ou dynamiques (Interaction Diagram)

Diagramme de séquence (Sequence Diagram) : représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs.
Diagramme de communication (Communication Diagram) : depuis UML 2.x, représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets.
Diagramme global d'interaction (Interaction Overview Diagram) : depuis UML 2.x, permet de décrire les enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes de séquences (variante du diagramme d'activité).
Diagramme de temps (Timing Diagram) : depuis UML 2.3, permet de décrire les variations d'une donnée au cours du temps.

Les éléments de modélisation

  • Le Stéréotype est une marque de généralisation notée par des guillemets, cela montre que l'objet est une variété d'un modèle.
  • Le classeur est une annotation qui permet de regrouper des unités ayant le même comportement ou structure. Un classeur se représente par un rectangle conteneur, en traits pleins.
  • Un paquetage regroupe des diagrammes ou des unités.
  • Chaque classe ou objet se définit précisément avec le signe « :: », ainsi l'identification d'une Classe X en dehors de son package ou de son classeur sera définie par « Package A::Classeur B::Classe X ».
Les éléments de modélisation de type commun     

État initial (Initial state)
État terminal (Final state)
Interface
        O←-- sens du flux de l'interface
        O)----- est un raccourci pour la superposition de →O et O←

Les éléments de modélisation de type relation

Dépendance       ; agrégation et  Composition ; réalisation ; utilisation

Un lien de composition symbolise l'existence d'une agrégation particulière, dite 'forte', entre deux entités (classes).
Une composition est définie par les points suivants :

Durée de vie : toute classe agrégée est détruite quand la classe composite est détruite.
Exclusivité : une classe agrégée ne peut l'être que par une seule classe composite.
Notion de « fait partie de ».

À noter que la distinction entre composition et agrégation n'est pas absolue : c'est le contexte qui détermine ce choix. Ainsi une voiture peut être vue comme l'agrégation d'un habitacle et 4 roues du point de vue d'un logiciel de casse automobile (la destruction de la voiture n'entrainera pas celle des roues si elles sont récupérées auparavant), ou bien comme une composition du point de vue d'un logiciel de simulation de comportement routier (où les roues nécessitent d'être traitées comme des entités distinctes, mais où le véhicule reste considéré comme un tout).

MOF (Meta-Object Facility)

est une architecture à 4 couches, dév par OMG.

 

Plus sur UML

http://www.uml.org/ et http://www.omg.org/
http://en.wikipedia.org/wiki/UML_tools

des tuto:

http://www.omg.org/gettingstarted/training.htm
http://www.jeckle.de/umllinks.htm#tutorials
http://www.conradbock.org/#UML2.0

 

doc: 
AttachmentSize
PDF icon UML 2 pages guide pdf10.32 MB