Cours UML diagramme de Classe

Aller au Téléchargement

niveau S.I.A. (Système d'Information Automatisé)

Les outils U.M.L.

1- les paquetages

2- les cas d'utilisation

3- les diagrammes de collaboration

4- les diagrammes de classes et d'objets

5- les diagrammes de séquence

6- les diagrammes d'états-transitions

7- les diagrammes d'activités

8- les diagrammes de composants

9- les diagrammes de déploiement

La démarche UML

1- découpage de l'application enpaquetage

2- découpage de l'application encas d'utilisation(use-case), et regroupement de ces derniers à l'intérieur des paquetages précédents.

3- conceptualisation de 1diagramme de collaborationpar instance de cas d'utilisation (scénario).

4- conceptualisation de 1diagramme de classespar diagramme de collaboration.

5- création d'undiagramme de classes globalpar regroupement des sous-diagrammes de classes précédemment conçus.

Dans une méthode objet, on va du particulier au général

Quelques remarques ..

   Développement du génie logiciel

Développement des applications

     en modules réutilisables

 Généralisation de la "réflexion" à propos

       d'une application en termes de "scénarios"

(ex: saisir des inscriptions à l'université ou des inscriptions encentre de vacances engendre le même scénario)

   USE-CASE        PAQUETAGE

NB: un use-case peut parfois présenter plusieurs scénarios différents (instances), qui sont autant de schémas acteurs-flux différents.

Les paquetages

• Représentation graphique:

• Définition:

Mécanisme de partition des modèles et de regroupement des éléments de modélisation

Un paquetage recouvre une application telle que la perçoit l'utilisateur (ex: comptabilité, gestion des commandes……)

Le système entier peut être pensé comme un paquetage

Ils peuvent contenir tous les éléments de modélisation: classes, cas d'utilisation, d'autres paquetages mais aussi des diagrammes.

Les cas d'utilisation

• Definition:

Un cas d'utilisation est une manière spécifique d'utiliser un système dont la finalité est de produire un résultat pour un acteur.

Scénario:

Un scénario décrit un exemple précis d'un cas d'utilisation.

Un cas d'utilisation  regroupe tout ce qui concerne un aspect particulier de l'utilisation du système.

• Mode de recherche:

Pour trouver les cas d'utilisation le "développeur" doit ébaucher des exemples de documents:

   - d'entrées

   - de sorties

Il pourra ainsi faire réagir l'utilisateur

• Représentation graphique:

             Acteur A                                                          Acteur B

La participation d'un acteur à un cas d'utilisation peut se décomposer en:

  - Signaux émis(par le cas d'utilisation)

-Signaux reçus(par le cas d'utilisation)

Les acteurs sont ici les acteurs externes au système étudié

Les Diagrammes de collaboration

• Définition:

Un diagramme de collaboration montre quelques objets dans une situation donnée.

• Représentation graphique:

Les objets sont représentés sous forme de rectangles, des liens les objets qui se connaissent ( c. à d. qui peuvent interagir).

Les messages échangés par ces objets sont représentés le long de ces liens.

L'ordre d'envoi des différents messages est matérialisé par un numéro placé en tête du message.

                                     1:X                                 3:Z

                              2:Y

Un diagramme de collaboration décrit un scénario (une instance d'un cas d'utilisation)

• Un message peut être conditionnel:

                                   [cond .]:X

• Les attributs colportés par un message peuvent êtres précisés:

                                    Envoyer ( x, y, z,..)

• Les classes (objets) interfaces représentant les sorties (journal des ventes, factures ), et les entrées (saisie du nom d'un client .) ainsi que, si nécessaire, l'acteur envoyant un message  apparaissent dans un diagramme de collaboration

                                Saisir [x,y,z ]

NB: un Diagramme de collaboration est proche d'un MLD avec liaisons d'usage

Le Diagramme de Collaboration entre Objets

En quoi les méthodes d'analyse orientées objets diffèrent fondamentalement d'une méthode type "Merise"?

Un objet est une entité autonome qui dispose de sa propre structure de données individuelle et qui est maître de son propre comportement. Une tâche (ou fonction) se réalise par la coopération de plusieurs objets.

Supposons que le problème à résoudre consiste à échanger les valeurs (un swap) des deux mémoires individuelles M1 et M2 appartenant respectivement à 2 objets O1 et O2. Si le contenu de O1 est directement transféré dans 02, on perd l'ancien contenu de ce dernier et l'échange n'est plus possible. Il faut donc créer un objet 03 :

Le "comportement" de chacun de nos objets est défini par 2 opérations : LIRE qui lit le contenu de sa mémoire et ECRIRE qui met une valeur dans cette mémoire.

La réalisation de l'échange des valeurs des mémoires M1 et

M2 peut être décrit par:

Les segments entre objets représentent un lien entre eux. Les flèches orientées sur ces segments indiquent l'orientation des messages.

Contrairement au Graphe des flux, les messages sont ordonnés.

Contrairement au DFD, la fonction (ici l'échange M1 M2) n'est pas réalisée par un processus du type "boîte noire" mais par la collaboration d'objetsautonomesqui communiquent entre eux, et dont l'intérieur est visible.

Contrairement aux 2 modèles précédents, tout est dit. La communication est vue comme uneinteractionqui se déroule dans uncontextequi est lui-même décrit : données (Mi), opérations (Lire, Ecrire).

Pour voir si vous avez bien compris :

1) Sachant que les valeurs initiales de M1 et M2 sont respectivement 8 et 5, dessiner les contenus des mémoires M1, M2 et M3 après chacun des messages échangés.

2) Représenter le même problème avec un Graphe des Flux,

Le Diagramme de Séquence entre Objets

On peut proposer une autre représentation qui permet:

-de mieux visualiser l'ordonnancement temporel
-ennégligeant le contextede la communication.

Une ligne en pointillé indique laligne de vied'un objet. L'ordre d'envoi des messages est donné par une position sur l'axe vertical.

Il s'agit donc d'un diagramme équivalent à un Graphe des Flux dans lequel on aurait précisé l'ordre des messages.

Des notations complémentaires permettent d'exprimer :
- les contraintestemporellesprécises en graduant l'axe vertical (pour dire par exemple :"10 secondes plus tard")
- lemode de réalisationdu diagramme : message synchrone ou asynchrone, délai de transmission d'un message, message de création ou de destruction d'objet, durée d'une activité d'objet, etc.

Les objets sont des acteurs externes au système étudié ou des acteurs internes à ce système

Modélisation UML – diagramme de Classe

Une classe est une description d’une famille d’objets qui ont:

1-la même sémantique

2-les mêmes attributs

3-les mêmes opérations, donc le même comportement

4-les mêmes protocoles de communication (interface)

Tout objet est uneinstanced’une et une seule classe

                              (occurrence d’entité en EA)

Rappel:tout objet a:

1-    un état: à l’instant ‘T’ cet état regroupe les valeurs instantanées de tous les attributs de l’objet.

2-    un comportement: décrit les actions et réactions de l’objet. Chaque atome de comportement est appelé "opération". Chaque opération attachée à un objet est déclanchée suite à une stimulation externe, appelée message, envoyée par un autre objet.

3-    une identité: permet de distinguer deux objets de façon non ambiguë. Chaque objet a une identité de manière implicite. L' identifiant, appelé aussi "clé naturelle" est un artifice rajouté dans l'état des objets afin de les distinguer.

Un objet (ou une classe d'objets) est entièrement défini par ses attributsETses opérations.

( une méthode est une opération implémentée )

Modélisation UML – diagramme de Classe

ASSOCIATION

association

L’assocation est porteuse d’attributs

Elle estattribuéesi elle ne participe pas à des relations avec d’autres classes

Assocation non attribuée

Modélisation UML – diagramme de Classe

ASSOCIATION(suite)

Travaille pour

Active (c’est le cas ici)

Nom de l’association

Passive (“est employée par”)

ROLE: 2 roles par association. Chacun peut porter un nom

Subord.1..*1

1..*

employé              employeur

0..1

supérieurs

Multiplicité

Spécifie le nombre d’instances qui participent à l’association

écriture inverse de celle du modèle EA

1un et un seul

0…1zéro ou 1

0…*zéro à plusieurs

*zéro à plusieurs

1…*un à plusieurs

m…nde m à n

Modélisation UML - diagramme deClasse

NAVIGABILITE d’une association

Précise le sens dans lequel une association entre deux classes peut être parcourue. Par défaut une association estnavigabledans les deux sens.

de

0..*1..*

Les objets instances de commande voient les objets instances de produits, mais non l’inverse.

ASSOCIATION TERNAIRE

Association non porteuse de données

Modélisation UML - diagramme deClasse

Association porteuse de données

Modélisation UML – diagramme de Classe

AGREGATION

0..**

COMPOSITION

Agrégation forte: la durée de vie du composant=celle du composé

0..1                                  1..1

NB: Jamais la multiplicité * du coté du composé

Modélisation UML – diagramme de Classe

GENERALISATION

Sur-classe (classe  super-type)

Sous-classe (classe  sous-type)

La généralisation traduit une relation par laquelle une instance d'un sous-type peut être substituée à une instance d'un super-type

GENERALISATION ET HERITAGE

Modélisation UML - diagramme deClasse

LES CONTRAINTES:

1-Qualification (d’une association)

1

                              Repertoire + le nom d’un fichier (comme cle par exemple) permet d’accéder à un fichier précis et un seul.

(un ou plusieurs attributs peuvent former la clé, et la multiplicité de l’association est alors réduite à 1)

2-Ordre (d’une association)

Cette contrainte porte sur le rôle d’une association

Elle spécifie une relation d’ordre pour les objets placés dans la collection

10..*

(ordonné)

la collection des comptes d’une personne est ordonné

Modélisation UML - diagramme de Classe

LES STEREOTYPES de CLASSE

1-<< signal >> classe qui déclenche une transaction

2-<< interface >> classe qui décrit des opérations visibles

(saisie, édition…)

3-<< utilitaire >> une classe réduite au concept de module et

qui ne peut être instanciée

4-<< association >> classe liée à une association porteuse de

données

5-<< contrôle >> caractérise des classes effectuant des

                                                       traitements internes au système

6-<< entité >> classe “standard”

VISIBILITEDES ATTRIBUTS ou DES OPERATIONSD’UNECLASSE

1-public: rend l’élément visible à tous les clients de la classe

( visibilité par défaut )        symbole: +

2-protégé: rend l’élément visible aux sous-classes de la classe

                                                                                       symbole: #

3-privé: rend l’élément visible à la classe seule

symbole: -

Modélisation UML - diagramme deClasse

différents TYPES de CLASSE (ou d'objets)

1-    abstraite: L'élement ne peut être instancié (la classe ne donne pas naissance à des objets)

2-persistante: représente des objets de gestion

3-feuille: la classe (ou l'objet) ne peut avoir de sous-type

4-racine: l'élément ne peut avoir de super-type