Analyse et Conception Objets - Espace Numerique de Travailtouchardinforeseau.servehttp.com/siteweb20142015/20142015/IRIS2... · MODELISATION UML Le modèle objet La modélisation

S.T.S . Informat ique e t Réseauxpour l ' Industr ie et l es Services techniques

Analyse et ConceptionObjets

U.M.L Unified Modeling Languagelangage de modélisation objet unifiée

Version 2 2– septembre 2010 Jean GUILLETVersion 2 0– septembre 2006 Jean GUILLETVersion 1.5 – janvier 2003 Philippe Cruchet

1 ÉLÉMENTS BIBLIOGRAPHIQUES.................................................................................................3

2 DÉFINITION DE LA NOTION «ORIENTÉ OBJET».....................................................................4

2.1 LES OBJETS.............................................................................................................................................42.1.1 Caractéristiques des objets...........................................................................................................42.1.2 État d'un objet...............................................................................................................................42.1.3 Comportement d'un objet.............................................................................................................52.1.4 Identité d'un objet.........................................................................................................................62.1.5 Communication entre les objets...................................................................................................6

2.1.5.1 Comportement d'un objet....................................................................................................................62.1.5.2 Les messages.......................................................................................................................................6

2.1.6 Représentation en UML des objets...............................................................................................62.2 LES CLASSES...........................................................................................................................................7

2.2.1 Représentation UML de la relation classe et objet......................................................................72.2.2 Les attributs..................................................................................................................................72.2.3 Les opérations..............................................................................................................................72.2.4 Représentation UML des classes..................................................................................................82.2.5 Codage en C++............................................................................................................................82.2.6 Les interfaces................................................................................................................................92.2.7 Les classes utilitaires....................................................................................................................9

2.3 L’ENCAPSULATION..................................................................................................................................92.4 LA GÉNÉRALISATION ET SPÉCIALISATION..................................................................................................102.5 LE POLYMORPHISME...............................................................................................................................11

3 LA MÉTHODOLOGIE UML..............................................................................................................12

3.1 HISTORIQUE DE LA MÉTHODOLOGIE UML...............................................................................................123.2 UML EST UN LANGAGE PSEUDO FORMEL.................................................................................................123.3 LES BESOINS DES UTILISATEURS...............................................................................................................123.4 ARCHITECTURE.......................................................................................................................................13

3.4.1 La vue des cas d'utilisation...........................................................................................................133.4.2 La vue logique..............................................................................................................................133.4.3 La vue des composants.................................................................................................................143.4.4 La vue des processus....................................................................................................................143.4.5 La vue de déploiement..................................................................................................................14

4 MODELISATION DES CAS D’UTILISATION................................................................................15

4.1 INTRODUCTION.......................................................................................................................................154.2 LES ACTEURS..........................................................................................................................................15

MODELISATION UML

4.3 LES CAS D’UTILISATION...........................................................................................................................164.3.1 Les relations entre les cas d'utilisation........................................................................................16

4.4 RÉSUMÉ DE LA NOTATION ET DES SYMBOLES...........................................................................................174.5 LES POINTS CLÉS DES CAS D’UTILISATION.................................................................................................17

4.5.1 Nombre de cas d'utilisation..........................................................................................................174.5.2 Interaction de l'acteur .................................................................................................................174.5.3 Éléments de description................................................................................................................184.5.4 Autres éléments.............................................................................................................................18

5 DIAGRAMME DE SÉQUENCE.........................................................................................................19

5.1 INTRODUCTION.......................................................................................................................................195.2 NOTATIONS DU DIAGRAMME DE SÉQUENCE..............................................................................................19

5.2.1 Symbolisation...............................................................................................................................195.2.2 Niveau d’utilisation......................................................................................................................205.2.3 Les structures de contrôle et les activités des objets....................................................................215.2.4 Les messages.................................................................................................................................22

5.2.4.1 Message synchrone.............................................................................................................................225.2.4.2 Message asynchrone............................................................................................................................23

5.2.5 les fragments ou cadre d’interaction............................................................................................235.2.5.1 Cadre d'interaction avec les opérateurs alt et opt et else.....................................................................245.2.5.2 Cadre d'interaction avec l'opérateur loop.............................................................................................245.2.5.3 Cadre d'interaction avec l'opérateur par...............................................................................................255.2.5.4 Cadre d'interaction avec l'opérateur critical.........................................................................................255.2.5.5 Cadre d'interaction avec l'opérateur ref...............................................................................................26

5.2.6 Autres messages............................................................................................................................27

6 DIAGRAMME DE COMMUNICATION..........................................................................................27

6.1 INTRODUCTION.......................................................................................................................................276.2 NOTATION DU DIAGRAMME DE COMMUNICATION......................................................................................276.3 PRISE EN COMPTE DES THREADS..............................................................................................................28

7 DIAGRAMME D'IMPLÉMENTATION...........................................................................................29

7.1 DIAGRAMME DE COMPOSANTS..................................................................................................................297.2 DIAGRAMME DE DÉPLOIEMENT.................................................................................................................31

8 LES DIAGRAMMES DE CLASSES...................................................................................................32

8.1 L’HÉRITAGE ET LA GÉNÉRALISATION........................................................................................................328.1.1 Définition......................................................................................................................................328.1.2 Intérêt de l'héritage......................................................................................................................33

8.2 LES ASSOCIATIONS..................................................................................................................................338.2.1 Nom d’une association.................................................................................................................338.2.2 Rôle des extrémités des associations............................................................................................338.2.3 Multiplicité des associations........................................................................................................348.2.4 Les classes associations................................................................................................................358.2.5 Les noms de rôle des associations................................................................................................36

8.3 LES AGRÉGATIONS..................................................................................................................................368.4 LA COMPOSITION....................................................................................................................................37

9 LES DIAGRAMMES ÉTAT TRANSITIONS....................................................................................38

9.1 INTRODUCTION.......................................................................................................................................389.2 ÉTATS ET ÉVÉNEMENTS...........................................................................................................................38

9.2.1 Notion d’événement......................................................................................................................389.2.2 Notion d’état.................................................................................................................................38

9.3 DIAGRAMME D’ÉTATS TRANSITIONS.........................................................................................................389.3.1 Les gardes ou condition de garde................................................................................................399.3.2 Les opérations, activités et actions...............................................................................................39

9.4 LES DIAGRAMMES D’ACTIVITÉS................................................................................................................409.4.1 Les états actions............................................................................................................................419.4.2 La synchronisation.......................................................................................................................419.4.3 éléments graphiques.....................................................................................................................42

IRIS - LPR Touchard - LE MANS page 2

MODELISATION UML

Le modèle objet

La modélisation objet tend à s’appuyer sur le monde réel pour faire apparaître les différentescomposantes d’un projet informatique. Chaque objet ainsi défini possède une identité propre, uncomportement et peut communiquer par l’intermédiaire de messages avec les autres objets quil’entourent. Un objet est constitué de données et d’opérations nécessaires à la manipulation de cesdonnées.

Le terme objet reste un terme général. Pour désigner une famille d’objets possédant les mêmespropriétés, un comportement commun et des relations communes avec d’autres objets, le terme declasse est retenu. Pour l’utilisation d’un objet en tant qu’individu, c’est le mot instance qui estemployé. Chaque classe doit faire l’objet d’une instanciation pour pouvoir être utilisée.

1 ÉLÉMENTS BIBLIOGRAPHIQUES● Livre :

○ Modélisation objet avec UML de Pierre Alain MULLER et Nathalie GAERTNER

○ Introduction à UML de Sinan Si Ahir, Alexandre Gachet aux éditions O'REILLY. Livretraduit de l'américain. 38 €

● site internet :

○ Très didactique sur UML http://uml.free.fr/ correspond à la version 1

○ Constitué principalement de nombreux liens en rapport direct avec UMLhttp://uml.developpez.com/ A consulter et utiliser

● Logiciel

Produit Lien vers distributeur

BoUML outil UML à base de QT et fonctionnant sousWindows/Linux/Solaris. Simple à utiliser génère le code pourdifférents langages. Il n’est maintenant plus libre.

http://bouml.free.fr/index_fr.html )

Modelio il dispose d'une version open source pour lesdéveloppements non commerciaux. Il est complet, fournit du code C++, java,etc.

http://www.modeliosoft.com/fr.html

Umbrello est un outil UML porté uniquement sur LINUX et intégré àkde.. Il génère du code pour différents langage. A utiliser depréférence pour les débutants.

http://uml.sourceforge.net/index.php )

Rational Rose par les concepteurs d’UML. Une version éducationcomplète existe mais c’est un produit dont l’interface est pluscomplexe pour les néophytes.

http://www-01.ibm.com/software/rational/

Obecteering UML de Objecteering génère du code C++ et java.Une version community existe sans génération de code.

http://www.objecteering.com/

Quelques développements libres mais exclusivement pour java

Poséidon bien et agréable à utiliser http://www.gentleware.com/index.php

Argo UML : outil pour java; je ne l’ai pas testé, http://argouml.tigris.org/

Open Modelsphere est un logiciel de modélisation gratuit qui permetde modéliser systèmes d'information en général et/ou bases dedonnées en particulier à l'aide du langage UML ou les modèles de laméthode Merise

http://www.modelsphere.org/fr/index.html


http://uml.free.fr/



http://argouml.tigris.org/

http://www.objecteering.com/

http://uml.sourceforge.net/index.php

http://www.modeliosoft.com/fr.html

http://bouml.free.fr/index_fr.html

http://uml.developpez.com/

MODELISATION UML

2 DÉFINITION DE LA NOTION «ORIENTÉ OBJET»Un objet regroupe sous une même entité à la fois un état (fourni par les valeurs des attributs d'une

classe) et un comportement (méthodes d'une classe).

Il fournit

· Une relation d'encapsulation pour une forte cohérence interne. Ses données membres(attributs) ne sont pas ou très peu directement accessibles de l'extérieur.

· Un faible couplage externe. Il communique avec l'extérieur par l'envoi de messagesprincipalement à l'aide de ses méthodes.

Le modèle objet fait appel à seulement cinq concepts fondateurs :

· les objets

· les messages

· les classes

· l'encapsulation

· la généralisation

La modélisation objet présente les principaux attraits suivants :

· Proche du monde réel.

· Construction itérative facilité par le couplage faible entre les éléments.

La construction d'un logiciel est donc une suite d'itération en commençant par décomposer(diviser) puis composer (réunion).

Cette technique permet une approche du développement logiciel fondée sur la modélisation desobjets du monde réel. C’est une manière abstraite de réfléchir à un problème en employant les conceptsdu monde réel, plutôt que d’utiliser ceux purement informatique. L’objectif de cette approche est uneréponse à plusieurs tendances de l’informatique contemporaine:

· Besoin de maîtriser la complexité d’application de plus en plus volumineuses,

· Évolution de l’industrie du logiciel dans le sens de la réutilisation,

· Nécessité de réduire le poids de la maintenance dans les coûts du logiciel,

· Structuration des logiciels en couches,

· Prise de conscience de l’importance de l’approche par les données et par les servicesdans le processus de fabrication du logiciel.

2.1 Les objets

2.1.1 Caractéristiques des objetsComme il a été dit plus tôt, un objet présente les trois caractéristiques suivantes :

· une identité

· un état

· un comportement.

Dans de très rares cas, un objet peut être sans état (par exemple un objet math) ou sanscomportement (une structure au sens C) mais il possède toujours une identité.

2.1.2 État d'un objetL'état regroupe les valeurs instantanées de tous les attributs d'un objet. Un attribut (ou donnée

membre) peut prendre une valeur dans le domaine de définition de son type. Par exemple un attribut de


MODELISATION UML

type entier 16 bits non signé pourra prendre une valeur parmi [0..65535], un attribut etatMoteur de typeénuméré {Marche avant, Marche arrière, Arrêté, Démarrage} prendra l'une de ses valeurs et seulementcelle la.

L'état évolue au cours du temps. L'objet <un moteur> passe de l'état démarrage, marche avant,arrêté, Marche arrière,...

2.1.3 Comportement d'un objetLe comportement décrit les actions et les réactions d'un objet. Chaque entité élémentaire de

comportement est appelée opération.

Les opérations sont déclenchées suite à un stimulus externe représenté sous la forme d'un messageenvoyé par un autre objet.

L'état et le comportement sont liés. En effet, un avion ne peut atterrir que s'il est en vol. Ici, lesobjets sont des objets anonymes car il désigne un objet quelconque. Dans ce cas seul le nom des classesapparaît souligné et (précédé du caractère < : >


un Moteur

EtatMoteur = arreté

un Moteur

EtatMoteur = Démarrage

un Moteur

EtatMoteur = Marche avant

Après appui sur le starter

Après enclenchement de la vitesse

:Avion[en vol]

:Avion[au sol]

:Tour de controle

Atterir

Décoller

MODELISATION UML

2.1.4 Identité d'un objetL'identité de l'objet permet de distinguer deux objets indépendamment de leur état.

2.1.5 Communication entre les objets.Les objets cachent leur état interne et échange avec les autres objets à l'aide de message. Les

messages correspondent la plupart du temps à des méthodes

2.1.5.1 Comportement d'un objet

Les objets interagissent pour répondre à l'application. Un objet peut ainsi avoir plusieurscomportements selon qu'il reçoit ou envoie un message. Trois comportements apparaissent :

· Acteur : il est toujours à l'origine d'une interaction. C'est un objet actif.· Serveur : il est toujours le destinataire d'un message. C'est souvent un objet passif qui

attend d'être sollicité.par un autre objet.· Agent : c'est un objet qui cumule les caractéristiques de l'acteur et du serveur à la

manière d'un être humain. Il interagit avec les autres objets de sa propre initiative ousuite à une sollicitation d'un objet.

2.1.5.2 Les messages

Un message regroupe sous une même entité un flot de contrôle et un flot de données. Il peut être :

· Un appel de fonction (en général)· Un événement· Une interruption· Un datagramme UDP· Une recherche dynamique dans une base de données

2.1.6 Représentation en UML des objetsL'objet se représente sous la forme d'un rectangle, le nom est souligné.

Ici, deux objets sont représentés <une voiture> et <le conducteur>. Un lien existe entre la voitureet le conducteur, il est représenté en trait continu. Un descriptif est ajouté. Cette notre de commentaireest représenté par un rectangle avec un coin retourné, il est relié aux objets par une ligne pointillée.


MODELISATION UML

2.2 Les classesBeaucoup d'objets ont des caractéristiques communes, des éléments qui se ressemblent. L'idée est

de regrouper tous ces éléments semblables dans une structure d'un niveau d'abstraction supérieur.

La classe décrit le domaine de définition d'un ensemble d'objets. Chaque objet appartient à uneclasse Les objets informatiques sont construits à partir d'une classe par le processus de l'instanciation.On dit qu'un objet est instance d'une classe.

2.2.1 Représentation UML de la relation classe et objet

2.2.2 Les attributsLes attributs d'une classe sont leurs propriétés. Ils sont définis par un nom, un type et souvent une

valeur initiale. Un objet donne une valeur particulière à tous les attributs définis dans la classe ce quidétermine son état.

Par défaut, les attributs sont encapsulés pour ne pas être manipulés par les autres classes. Lesexceptions à cette règle sont par exemple pour diminuer le temps d'accès en supprimant les opérationsde type sélecteurs, modificateurs définis ci après.

2.2.3 Les opérationsLa réalisation du comportement d'un objet est exprimée par les méthodes de la classe. En UML,

une opération est un service offert par les instances d'une classe alors que les méthodes sont lesimplémentations des opérations. Cinq catégories d'opérations sont définies :

· Les constructeurs pour la création des objets· Les destructeurs pour leur destruction· Les sélecteurs. Ils renvoient une partie ou la totalité d'un objet (c’est une méthode qui

renvoie la valeur d'un attribut) · Les modificateurs. Ils modifient tout ou partie de l'état d'un objet (une méthode qui

modifie directement la valeur d'un attribut est en général à réserver à un usage restreintcar cela revient à passer outre le principe de l'encapsulation)

· Les itérateurs. Ils parcourent l'état d’un objet ou d'une structure de données quicontient plusieurs objets par exemple une liste, une file, un vecteur.


Couleur = rougeNbKilometre = 50000

MODELISATION UML

2.2.4 Représentation UML des classes

2.2.5 Codage en C++L'exemple de la classe précédente donne le code suivant :

/* Generated by Together */

#ifndef VOITURE_H#define VOITURE_H

class Voiture {public: // Constructeurs Voiture();

Voiture(const Voiture &voitureModele); // Destructeur ~Voiture();

// quelques opérations void rouler() ; void entretenir() ; // Sélecteurs string getNom() const;

// Modificateurs void setNbKilo(int kilom);private: string couleur; int nbKilometre; string nom;};#endif //VOITURE_H


MODELISATION UML

2.2.6 Les interfacesUne interface décrit le comportement visible d’une classe, d’un paquetage… Ce comportement est

défini par une liste d’opération de portée "public". Par contre, aucun attribut ni association n’est définidans une interface.

Une interface peut se représenter

Ø par un petit cercle relié à la classe correspondante

Ø par une classe avec le stéréotype <<interface>> auquel cas les services de l’interfacesont placés dans le compartiment des opérations

Les classes qui réalisent l’interface sont reliées à celle-ci à l’aide d’une flèche en pointillé avecextrémité triangulaire du côté de l’interface.

2.2.7 Les classes utilitairesLes fonctions mathématiques habituelles sont regroupées au sein d’un même module sans que cela

correspondent à une classe complète (il n’y a pas à proprement parlé d’attribut pour ce type de classe).Dans ce type de situation, une classe utilitaire permet de représenter de tels modules.

Les attributs et les opérations des classes utilitaires ont une portée globale. Le stéréotype<<utilitaire>> est ajouté à ce type de classe.

En C++ ou en java par exemple, une classe utilitaire ne contient que des membres statiques(attributs et méthodes).

2.3 L’encapsulationChaque objet est isolé des autres et ne peut directement accéder à un autre objet. De plus certaines

données et méthodes peuvent être privées, dans ce cas un objet client ne pourra les utiliser directement.Par contre, il pourra lui demander de communiquer la valeur des données sans connaître leuragencement, ni la façon dont elles sont mémorisées.

L'encapsulation fait référence à deux caractéristiques :

Ø La première est le regroupement des parties codes et données à l'intérieur de l'objet.La structure du programme s'en trouve simplifiée.

Ø La seconde correspond à la possibilité, dans la définition de la classe, de cachercertains des attributs, méthodes à la vue du reste du programme.

Un objet peut donc contenir des données invisibles aux autres objets et un ensemble de fonctionspermettant de contrôler l'accès à ces données. On retrouve ici la notion de boîtes noires où seules desmessages peuvent modifier les données ou obtenir des renseignements.

Par défaut, les valeurs des attributs ne peuvent être manipulées directement par les autres objets.


MODELISATION UML

2.4 La généralisation et spécialisationLa généralisation factorise les éléments communs (attributs, opérations) à un ensemble de classes

dans une classe plus générale appelée superclasse. Le schéma représentant un ensemble de classeshiérarchisées est une arborescence.

Dans l’exemple ci-dessous, apparaît un ensemble de moyen de locomotions hiérarchisées :

Il faut noter que la généralisation est une démarche abstraite. Elle part des objets du monde réel(ici voiture, avion…) pour déterminer les éléments communs. La flèche montre la généralisation. Ellepointe donc vers la classe la plus générale.

La spécialisation montre les particularités à partir d’une superclasse. Elle est intéressante pourétendre de manière cohérente un ensemble de classe. Dans l’exemple précédent, il est possibled’ajouter :

Ø La classe camion spécialisée de la classe "Vehicule" terrestreØ La classe "SideCar" spécialisée de la classe MotoØ …


MODELISATION UML

2.5 Le polymorphismeLe polymorphisme en informatique désigne la possibilité pour un nom d’objet de pouvoir désigner

des instances de classes différentes issues d’une même arborescence de classes.

Par exemple le diagramme suivant présente la collection polymorphe des barres

Le magasinier lorsqu’il veut afficher les caractéristiques d’une barre n’a pas besoin de connaître lesparticularités de l’affichage pour chaque barre. Il demande à chaque barre de s’afficher


:barre:barre

: Barre

+affiche()

MODELISATION UML

3 LA MÉTHODOLOGIE UML

3.1 Historique de la méthodologie UMLLes premières méthodes de développement orienté objet ont fait leurs apparitions en 1982 avec

OOD for Ada de Graddy BOOCH. La méthode Object Oriented Design for Ada ne fait pas cespreuves car elle est trop liée au langage Ada. Son auteur améliore le concept avec OOD pour ObjectOriented Developement en 1984, sa méthode apporte des solutions pour trouver les objets avec desstratégies informelles.

Les années 1986-1987, voient naître HOOD pour Hierachical Object Oriented Developementdans les laboratoires de Matra et Cisi Ingénierie pour les projets Hermes et Colombus de l’AgenceSpatial Européenne.

James RUMBAUGH en 1992 édite son livre sur la méthode OMT Object Modeling Technics.C’est une des composantes essentielles des méthodes utilisées aujourd’hui. Cette technique esttransposable vers d’autres langages que Ada, et ainsi, s’ouvre à de nombreux domaines del’informatique. La difficulté toujours présente, reste le fait de trouver les «bons objets» pour modéliserle monde réel.

Ivan JACOBSON propose dans le même temps une méthode ou l’on pense d’abord à l’utilisateuravec OOSE. C’est une méthode qui conduit à une approche ni structuré ni objet.

Puis, James RUMBAUGH et Graddy BOOCH commence à travailler ensemble sur une méthodeunifiée. Ils sont rejoints en 1996 par Ivan JACOBSON et associent leurs techniques pour fonder UMLUnified Modeling Langage.

3.2 UML est un langage pseudo formel. Il est fondé sur un méta-modèle, qui définit :

· Les éléments de modélisation (les concepts manipulés par le langage), · La sémantique de ces éléments (leur définition et le sens de leur utilisation). · Un méta-modèle est une description très formelle de tous les concepts d'un langage. Il

limite les ambiguïtés et encourage la construction d'outils.UML propose aussi une notation, qui permet de représenter graphiquement les éléments de

modélisation du méta-modèle. Cette notation graphique est le support du langage UML.

3.3 Les besoins des utilisateursLe périmètre du système à modéliser est défini par les besoins des utilisateurs (les utilisateurs

définissent ce que doit être le système).

· Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (lesutilisateurs sont les clients du système).

· Le développement se fait de manière itérative· À chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des

utilisateurs. · A chaque itération de la phase de conception et de réalisation, on veille à la prise en

compte des besoins des utilisateurs. · A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont

satisfaits.


MODELISATION UML

3.4 ArchitecturePh. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui permettent

de définir un modèle d'architecture (publication IEEE, 1995).

3.4.1 La vue des cas d'utilisationCette vue guide toutes les autres.

· Les cas d'utilisation représentent les fonctions du système du point de vue desutilisateurs.

· Cette vue définit les besoins des clients du système et centre la définition del'architecture du système sur la satisfaction (la réalisation) de ces besoins.

· A l'aide de scénarios et de cas d'utilisation, cette vue conduit à la définition d'unmodèle d'architecture pertinent et cohérent.

· Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture.

· Elle motive les choix, permet d'identifier les interfaces critiques et force à seconcentrer sur les problèmes importants

Cette vue rend compte des éléments de modélisation suivants :· Les acteurs· Les cas d'utilisation· Les classes· Les collaborations

3.4.2 La vue logiqueCette vue modélise les éléments et mécanismes principaux du système. Elle décrit les aspectsstatiques et dynamiques en termes de classes et d'objets en pensant abstraction, encapsulation,uniformité. Elle utilise les éléments suivants :

· Les objets· Les classes· Les collaborations· Les interactions

Cette vue permet d'identifier, de généraliser les éléments du système :

· les éléments du domaine sont liés au(x) métier(s) de l'entreprise, · ils sont indispensables à la mission du système, · ils gagnent à être réutilisés (ils représentent un savoir-faire).


Vue de déploiementVue de déploiementVue des processusVue des processus

Vue de réalisationVue de réalisationVue logiqueVue logique

Vue des cas d'utilisation

http://p3.html/#interf

MODELISATION UML

Cette vue organise aussi (selon des critères purement logiques), les éléments du domaine en"catégories" :

· pour répartir les tâches dans les équipes, · regrouper ce qui peut être générique, · isoler ce qui est propre à une version donnée, etc.

3.4.3 La vue des composantsCette vue de bas niveau (aussi appelée "vue de réalisation"), montre :

· L'allocation des éléments de modélisation dans des modules (fichiers sources,bibliothèques dynamiques, bases de données, exécutables, etc.).

· En d'autres termes, cette vue identifie les modules qui réalisent (physiquement) lesclasses de la vue logique.

· L'organisation des composants, c'est-à-dire la distribution du code en gestion deconfiguration, les dépendances entre les composants...

· Les contraintes de développement (bibliothèques externes...). · La vue des composants montre aussi l'organisation des modules en "sous-systèmes",

les interfaces des sous-systèmes et leurs dépendances (avec d'autres sous-systèmes oumodules).

Cette vue utilise les éléments suivants :

· Les composants stéréotypés tels que les fichiers, tables, bibliothèques, sousprogramme...

· Les sous systèmes (paquetages spécialisés)voir chapitre 71 pour le détail d'implémentation

3.4.4 La vue des processus

Cette vue est très importante dans les environnements multitâches ; elle montre :

· La décomposition du système en terme de tâches, thread. · Les interactions entre les processus (leur communication). · La synchronisation et la communication des activités parallèles (threads).· L'allocation des objets

Cette vue s'occupe également de

· La disponibilité du système· La fiabilité des applications· Les performances


· Les objets actifs (thread et processus)· Les interactions

3.4.5 La vue de déploiementCette vue est très importante dans les environnements distribués, elle décrit les ressources

matérielles et la répartition du logiciel dans ces ressources :

· La disposition et nature physique des matériels, ainsi que leurs performances. · L'implantation des modules principaux sur les nœuds du réseau. · Les exigences en termes de performances (temps de réponse, tolérance aux fautes et

pannes...).· La bande passante des moyens de communication et leur capacité· La disposition physique des processeurs· Les besoins en puissance de calculs distribués· Les surcharges et l'équilibrage de charge dans un système distribué· La tolérance aux fautes


http://p3.html/#interf

http://p7.html/#vl

MODELISATION UML


· Les nœuds de communication· Les instances de composants

voir chapitre 72 pour le détail d'implémentation

4 MODELISATION DES CAS D’UTILISATION

4.1 IntroductionLes diagrammes de cas d'utilisation représentent les cas d'utilisation, les acteurs et leurs relations.

· Ils permettent de définir les limites du système et de l'environnement.

· Un cas d'utilisation représente une fonctionnalité du système déclenchée en réponse àun stimuli d'un acteur externe.

· L'ensemble des fonctionnalités du système est déterminé en examinant les besoinsfonctionnels de chaque acteur.

· Les cas d'utilisation obligent les utilisateurs à définir la manière dont ils voudraientinteragir avec le système, à préciser les informations à échanger, décrire ce qui doitêtre fait.

· les cas d'utilisation concrétisent le système en une formulation proche des utilisateurs

A c te u r

C a sd 'u t i l is a t io n

figure 1 : Exemple de cas d’utilisation

4.2 Les acteursUn acteur se représente soit sous forme d'un petit bonhomme soit un via le symbole de classe avec

le mot clé <<acteur>>

Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chosequi interagit avec un système

Le concept d’acteur aide à définir ce qui existe en dehors du système, c’est à dire ce qui interagitavec lui ou échange des informations avec lui. En fait, l’acteur envoie des événements comme, entrerune date de naissance, cliquer sur un bouton OK ou encore envoyer un fichier de données ou une trameXML. Il peut également recevoir des informations de la part du système comme, recevoir une facture,mettre à jour un référentiel de données ou encore mettre à jour une application back-office. Un acteurreprésente un rôle. Ce rôle peut être joué aussi bien par une personne que par toute autre entité commeune machine, un autre système, un groupe d’utilisateur…

Exemple : L’ouvrier d’une usine peut conduire sa ligne de fabrication il joue le rôle deCONDUCTEUR. Quelquefois il peut être amené à faire des manipulationsspécifiques de configuration, il joue alors le rôle de REGLEUR. Chacun de cesdeux rôles invoquera un comportement différent du système sur lequel travaill’ouvrier. Le CONDUCTEUR et le REGLEUR sont deux acteurs du système.

Pour déterminer un acteur, il faut observer les utilisateurs du système.


MODELISATION UML

On peut définir 4 grandes catégories d'acteurs :

· Acteurs principaux: ceux qui utilisent les fonctions principales du système(CONDUCTEUR)

· Acteurs secondaires: ceux qui effectuent des tâches administratives ou demaintenance sur le système (REGLEUR)

· Matériel externe: dispositifs périphériques (non modélisés par le système) maisindispensable à l'application (automate programmable mais pas l'ordinateur où vas'exécuter l'application)

· Autres systèmes: systèmes interagissant avec l'application (équilibreuse de roue,système distant)

4.3 Les cas d’utilisationLe cas d'utilisation se représente par une ellipse avec à l'intérieur le nom du cas d'utilisation. Un

ensemble de cas d'utilisation peut être contenu dans un rectangle qui symbolise les limites du systèmemais les acteurs sont à l'extérieur car ils ne sont pas dans le système.

Un cas d’utilisation correspond à une manière spécifique d’utiliser le système. Chaque casd’utilisation doit faire l’objet d’une description détaillée formulée dans le langage de l’utilisateur Celapeut être

· un texte

· un diagramme d'activité ou un diagramme à état

· ...

. Cette description doit être la plus complète possible mais doit cependant rester significative pourl’utilisateur et ne pas invoquer des éléments de conception, c’est une vue purement externe d’une partiede l’application.

Ils se déterminent par observation du système en précisant acteur par acteur les scénarios mais dupoint de vue de l'utilisateur. Un cas d'utilisation regroupe un ensemble de scénario d'utilisation du pointde vue fonctionnel.

Dans le cas où l’on désire présenter les attributs ou les opérations du cas d’utilisation, il estpréférable de le représenter sous la forme d’un classeur stéréotypé « use case ». Voici un exemple dereprésentation d’un cas d’utilisation sous la forme d’un classeur

4.3.1 Les relations entre les cas d'utilisationTrois types de relation permettent de décrire les relations (UML 1) :

· La relation de généralisation. Un cas d'utilisation est enfant d'un autre cas lorsqu'ilreprésente une spécialisation du cas parent.

· La relation d'inclusion. Ici, le cas d'utilisation source (départ de la flèche) comprendégalement le cas d'utilisation destination. Cette relation permet de décomposer des caset de définir un cas d'utilisation partageable. Par exemple dans le cas d'un échange dedonnées sur Internet, il est nécessaire de se faire reconnaître. Le cas d'utilisation<<reconnaissance de l'utilisateur>> est un cas d'utilisation inclus dans tous les casd'utilisation d'échange de données.

· La relation d’extension. Le cas d'utilisation source (départ de la flèche) ajoute uncomportement supplémentaire au cas d'utilisation destination. Cette extension peut êtresoumise à condition. Souvent il s'agit d'un cas particulier du cas d'utilisationdestination. Par exemple dans le cas d'échange de données sur Internet, le casd'utilisation <<transfert crypté>> peut être un cas particulier.


MODELISATION UML

·

4.4 Résumé de la notation et des symboles

Nom Symbole Description

Acteur Joue un rôle pour le système

Cas d’utilisation Une façon dont l’acteur utilise le système

Frontière de la vue du système

Limites du système pour un ensemble de cas d’utilisation

Interaction Interaction Acteur/Cas d’utilisation

Relation “Etend…”Relation entre deux cas d’utilisation dont l’un est un cas particulier (origine de la flèche) du premier (extrémité de la flèche)

Relation “Utilise…” Relation entre deux cas d’utilisation où l’un utilise les services de l’autre.

4.5 Les points clés des cas d’utilisation

4.5.1 Nombre de cas d'utilisationUn diagramme de cas d’utilisation, ne doit comporter que 5 à 20 cas d’utilisation maximum, sinon

le décomposer par acteur ou par fonctionnalité.

4.5.2 Interaction de l'acteur Un cas d'utilisation doit être simple, décrit de manière claire et concise. Le nombre d'acteurs en

relation avec un cas d'utilisation doit être restreint souvent un. Pour l'acteur en relation avec un casd'utilisation, il faut se poser les questions :

· Quelles sont les tâches de l'acteur ?

· Quelles informations doit-il créer, détruire, sauvegarder, modifier ou lire?

· Devra-t-il informer le système de modification externe ?

· Doit-il être informé de conditions internes ?


Extends

Uses

MODELISATION UML

4.5.3 Éléments de descriptionLes descriptions des acteurs et des cas d’utilisation sont très importantes. Ils contiennent :

· un scénario principal. Il représente 80% du cas d'utilisation

· des scénarios alternatifs qui sont des cas d'exécution moins fréquents mais assurent unfonctionnement correct (par exemple lors de l'échange de données une rupture brève etmomentanée de l'accès Internet

· des scénarios d'exceptions correspondant à des cas de pannes qui ne permettent pasune terminaison correcte du cas d'utilisation par exemple lors d'un accès Internet, unerupture permanente de la connexion

La lecture de chaque cas d’utilisation conduira à passer à l’étape suivante, la réalisation dudiagramme d’interaction d’objets faisant apparaître des objets et des interactions entre ces objets

En outre la description d'un cas d'utilisation doit comprendre :

· le début du cas d'utilisation sous la forme « le cas d'utilisation débute quandl'événement evt se produit ».

· la fin du cas d'utilisation de manière similaire « quand l'événement evtprime seproduit, le cas d'utilisation est terminé ».

· L'interaction entre l'acteur et le cas décrit clairement ce que l'acteur fait et ce que lesystème fait

· les échanges d'informations entre acteur et ou cas d'utilisation sont formalisés en termenon informaticien par exemple dans le cas d'une connexion l'utilisateur se connecte àl'aide de son nom et de son mot de passe.

· La chronologie et l'origine des informations pour connaître l'instant où les systèmesdoivent en disposer.

· Les répétitions de comportement peuvent être décrite à l'aide de pseudo code.

4.5.4 Autres élémentsIl faut relire les demandes (formulées ou seulement informelles) pour

· vérifier que tous les besoins identifiés sont pris en compte

· qu'un même besoin ne soit pas été alloué à plusieurs cas d'utilisation

· vérifier qu'un cas d'utilisation n’est pas référencé par les besoins de l'utilisateur.


MODELISATIONUML MODELISATION DES INTERACTIONS

Modélisation des Interactions d’objets

La vue des cas d’utilisation est une description fonctionnelle des besoins décrits en rapport avec lesutilisateurs. Chaque cas d’utilisation conduit à la réalisation de diagrammes d’interaction d’objets. Les«bons » objets sont trouvés dans la description du cas d’utilisation. Deux diagrammes d’interactionsd’objets sont proposés dans UML : le diagramme de séquences et le diagramme de collaborations.

5 DIAGRAMME DE SÉQUENCE

5.1 IntroductionCette étape détaille les fonctionnalités de chaque cas d’utilisation et permet de comprendre

comment les objets pourront les implémenter. Les diagrammes de séquences permettent de représenterdes collaborations entre objets selon un point de vue temporel. L'accent est mis sur la chronologie desenvois de messages. Ils sont prévus pour montrer l’aspect dynamique des systèmes temps réel et desscénarios complexes.

5.2 Notations du diagramme de séquence

5.2.1 SymbolisationLes diagrammes de séquence indiquent la chronologie des messages envoyés entre les différents

objets de l’application. On doit voir l’enchaînement des appels avec l’activité des objets (rectangle surl’objet). L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme ; letemps s'écoule « de haut en bas » de cet axe. La disposition des objets sur l'axe horizontal n'a pasd’importance mais doit permettre une lecture aisée.

Un objet est matérialisé par un rectangle et une barre verticale nommée ligne de vie de l’objet. Lesobjets communiquent par l’envoi de messages représentés par des flèches horizontales, orientées del’émetteur vers le destinataire du message. La dimension verticale représente l’écoulement du temps etpeut être graduée. Le temps s'écoule de haut en bas.

La syntaxe de l'objet est :nom du rôle : nom du type.

Au moins l’un des 2 éléments doit être présent et le symbole : est toujours présent. Par exempledans la représentation ci-dessous, main est un objet de type administrateur, CSocketServeur etTcpListener sont deux classes dont les noms d'instance ne sont pas indiquées sur ce diagramme.

STS IRIS - LPR Touchard - LE MANS PAGE 19

http://p18.html/#coll


5.2.2 Niveau d’utilisationLe diagramme de séquence s’utilise en premier lieu pour documenter un cas d’utilisation.

L’indication portée sur les flèches est une précision proche des préoccupations de l’utilisateur et non duconcepteur. Dans cet exemple, les objets Appelant et Appelé sont des acteurs, ils ont été représentéscomme tel sur le diagramme. En général, c’est un acteur qui débute le diagramme de séquence. Unévénement débute une séquence.

La deuxième utilisation correspond à un usage informatique. Elle permet la représentation précisedes interactions entre les objets et fait apparaître des appels de méthode, des événements discrets, desinterruptions matérielles…

Il ne faut pas confondre un objet qui est un exemplaire d’une classe (encore appelé instance) avecune classe qui est un type abstrait de données. L’objet se note au-dessus de la classe et c’est lui qui estindiqué en premier lors de la construction d’un diagramme de séquence. Ensuite, on indique à partir dequelle classe il est fabriqué.


Durée d’activation


5.2.3 Les structures de contrôle et les activités des objetsLes structures de contrôle sont gérées par ces diagrammes. Elles se notent avec un rectangle en

surimpression sur l’activité principale. Toutes les structures de contrôle que l’on rencontre eninformatique sont acceptées.

La création d’un objet se note par l’arrivée du message sur l’objet et la destruction de l’objet senote par une croix en fin de la ligne de vie de l’objet.



5.2.4 Les messagesUn message représente la communication entre objets. Plusieurs types de messages existent, les

plus communs sont :

=>l’envoi d’un signal ;

=>l’invocation d’une opération ;

=>la création ou la destruction d’une instance.

Le message correspond à une méthode de la classe où arrive la flèche.

Une interruption ou un événement sont de bons exemples de signaux. Ils n’attendent pas deréponse et ne bloquent pas l’émetteur qui ne sait pas si le message arrivera à destination. Lorsque lemessage arrivera à destination, il sera traité par le destinataire. Un signal est, par définition, un messageasynchrone.

L’invocation d’une opération est le type de message le plus utilisé en programmation objet.L’invocation peut être asynchrone ou synchrone. Dans la pratique, la plupart des invocations sontsynchrones, l'émetteur reste alors bloqué le temps que dure l’invocation de l’opération

5.2.4.1 Message synchrone

Graphiquement, un message synchrone se représente par une flèche en traits pleins et àl’extrémité pleine partant de la ligne de vie d’un objet expéditeur et allant vers celle de l’objetcible (voir ci-dessous). Ce message peut être suivi d’une réponse qui se représente par une flèche enpointillé


unRouleau

ajoutMRAjoutVue

if(condition vrai)

Magasinier

if(condition vrai)

2.1.1: Realiser()

5.1: detruire()

1.1: créer()

6: message temporisé

5: mesagesansattente

4: messageDerobant

3: messageSynchrone

2: MessageSimple

1: messageAsynchrone

Un acteurun objet :ajiout est une instancede la classe MRAjoutVue

un objet nonencore instancié

destruction de l'objet


La création d’un objet est matérialisée par une flèche qui pointe sur le sommet d’une ligne devie.

La destruction d’un objet est matérialisée par une croix qui marque la fin de la ligne de vie del’objet.

5.2.4.2 Message asynchrone

Graphiquement, un message asynchrone se représente par une flèche en traits pleins et àl’extrémité ouverte partant de la ligne de vie d’un objet expéditeur et allant vers celle de l’objet cible

5.2.5 les fragments ou cadre d’interactionUn fragment combiné représente des articulations d’interactions. Il est défini par un opérateur et

des opérandes. L’opérateur conditionne la signification du fragment combiné. Il existe 12 d’opérateursdéfinis dans la notation UML 2.0. Les fragments combinés permettent de décrire des diagrammes deséquence de manière compacte. Les fragments combinés peuvent faire intervenir l’ensemble des entitésparticipant au scénario ou juste un sous-ensemble.

Un fragment combiné est représenté un rectangle dont le coin supérieur gauche contient unpentagone. Dans le pentagone figure le type de la combinaison, appelé opérateur d’interaction. Lesopérandes d’un opérateur d’interaction sont séparés par une ligne pointillée. Les conditions de choix desopérandes sont données par des expressions booléennes entre crochets ([ ]).

La liste suivante regroupe les opérateurs d’interaction par fonctions :


Message synchrone

Réponse éventuelle

Message asynchrone


les opérateurs de choix et de boucle : alternative, option, break et loop ;

les opérateurs contrôlant l’envoi en parallèle de messages : parallel et critical region ;

les opérateurs contrôlant l’envoi de messages : ignore, consider, assertion et negative ;

les opérateurs fixant l’ordre d’envoi des messages : weak sequencing , strict sequencing.

5.2.5.1 Cadre d'interaction avec les opérateurs alt et opt et else

L’opérateur alternative, ou alt, est un opérateur conditionnel possédant plusieurs opérandes. C’estun peu l’équivalent d’une exécution à choix multiple (condition switch en C++). Chaque opérandedétient une condition de garde. L’absence de condition de garde implique une condition vraie (true). Lacondition else est vraie si aucune autre condition n’est vraie. Si plusieurs opérandes prennent la valeurvraie, le choix est non déterministe. Dans le cas d'un choix multiple (switch), on ajoute autant deséparateur que de cas. L’exemple ci-dessous représente la structure alternative si (cond) alors ... sinon

L’opérateur option, ou opt, comporte un opérande et une condition de garde associée. Le sousfragment s’exécute si la condition de garde est vraie et ne s’exécute pas dans le cas contraire. C’estl'équivalent du si (cond) alors

A noter dans cet exemple, le fragment assert. Celui-ci est principalement utilisé lors des tests. Ilindique que les seuls messages possibles à cet instant sont ceux décrits dans le fragment ; tout autremessage n'est pas pris en compte.

5.2.5.2 Cadre d'interaction avec l'opérateur loop

Un fragment combiné de type loop possède un sous-fragment et spécifie un compte minimum etmaximum (boucle) ainsi qu’une condition de garde. La syntaxe de la boucle est la suivante :

loop[ ’(’<minInt> [ ’,’ <maxInt> ] ’)’ ]

La condition de garde est placée entre crochets sur la ligne de vie.

La boucle est répétée au moins minInt fois avant qu’une éventuelle condition de garde booléennene soit testée. Tant que la condition est vraie, la boucle continue, au plus maxInt fois

Dans l'exemple ci-dessous, la boucle est au moins exécuté une fois et s'interrompt s'il y a arrêt duserveur.



5.2.5.3 Cadre d'interaction avec l'opérateur par

Un fragment combiné de type parallèle, ou par, possède au moins deux sous-fragments exécutéssimultanément. La concurrence est logique et n’est pas nécessairement physique : les exécutionsconcurrentes peuvent s’entrelacer sur un même chemin d’exécution dans la pratique.

Dans l'exemple ci-dessus, les deux méthodes nukeFood et rotateFood vont s' 'exécutersimultanément.

5.2.5.4 Cadre d'interaction avec l'opérateur critical

L'opérateur "critical" désigne une section critique. Une section critique permet d'indiquer que lesinteractions décrites dans cet opérateur ne peuvent pas être interrompues par d'autres interactionsdécrites dans le diagramme. On dit que l'opérateur impose un traitement atomique des interactions qu'ilcontient.

L'exemple ci-dessous montre un opérateur "critical" : On ne souhaite pas que l'utilisateur puisseobtenir des billets avec un code erroné et une somme demandée incorrecte



5.2.5.5 Cadre d'interaction avec l'opérateur ref

Une référence (interaction occurrence) peut être vue comme un pointeur ou un raccourci vers unautre diagramme de séquence existant. Cela équivaut à copier le contenu du diagramme de séquencepointé en lieu et place de la référence. Attention cependant à être cohérent au niveau des paramètresutilisés.

Cela permet de factoriser des parties de comportement utilisées dans plusieurs scénarios.

L'exemple ci-dessus montre une référence : Le diagramme de séquence "identifierUtilisateur" faitréférence à un diagramme de séquence noté "vérifierSomme"



5.2.6 Autres messagesType symbole Description

messagesimple

Message dont on ne spécifie aucune caractéristique d'envoi ou de réceptionparticulière.

messageminuté(timeout)

Bloque l'expéditeur pendant un temps donné (qui peut être spécifié dans unecontrainte), en attendant la prise en compte du message par le récepteur.L'expéditeur est libéré si la prise en compte n'a pas eu lieu pendant le délai spécifié.

messagesynchrone

Bloque l'expéditeur jusqu'à prise en compte du message par le destinataire. Le flotde contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et le récepteuractif) à la prise en compte du message.

messageasynchrone

N'interrompt pas l'exécution de l'expéditeur. Le message envoyé peut être pris encompte par le récepteur à tout moment ou ignoré (jamais traité).

messagedérobant

N'interrompt pas l'exécution de l'expéditeur et ne déclenche une opération chez lerécepteur que s'il s'est préalablement mis en attente de ce message

Messagedécalé

La flèche indique que le délai de transmission du message n’est pas négligeable parrapport à l’application

Selfmessage

Message transmis à l’objet lui même. En général, indique l’appel d’une méthode dela classe.

6 DIAGRAMME DE COMMUNICATION

6.1 IntroductionLes diagrammes de communication (ou collaboration) montrent des interactions entre objets

(instances de classes et acteurs). Ils permettent de représenter le contexte d'une interaction, car on peut ypréciser les états des objets qui interagissent. C'est une vue dynamique en relation avec le diagramme deséquence (un diagramme de séquence est associé à un diagramme de communication.

Voici en exemple le diagramme de communication associé avec le diagramme de séquence del’appel téléphonique :

6.2 Notation du diagramme de communicationLe diagramme ci-dessous nous montre les communications entre les objets et les messages

d’échanges.


http://p20.html/#state

http://p10.html/#acteur

http://p12.html/#inst


UML permet de spécifier de manière très précise l'ordre et les conditions d'envoi des messages surun diagramme dynamique. Pour chaque message, il est possible d’indiquer :

Ø les clauses qui conditionnent son envoi,Ø son rang (son numéro d'ordre par rapport aux autres messages),Ø sa récurrence,Ø ses arguments.

6.3 Prise en compte des threadsUML permet de représenter des communications entre objets actifs de manière concurrente. Le

fragment avec l'opérateur par et également le fragment avec l'opérateur critical permettent lareprésentation des threads.


http://p12.html/#inst


Cette extension des diagrammes de communication permet notamment de représenter descommunications entre processus ou l'exécution de threads :

7 DIAGRAMME D'IMPLÉMENTATION

7.1 diagramme de composantsUn diagramme de composants montre les dépendances entre les composants logiciels pour

l'implémentation. Il comprend les programmes sources, binaires ou exécutables et leurs relations. Maisun diagramme de composants ne montre que les types des composants logiciels. Afin de représenterleurs instanciations, il faut utiliser un diagramme de déploiement.

On utilise les diagrammes de composants pour modéliser la vue d’implémentation statique d’unsystème. Il existe quatre façons de modéliser cette vue à l’aide des diagrammes de composants :

Ø Modélisation du code source

Ø Modélisation des versions exécutables

Ø Modélisation des bases de données physiques

Ø Modélisation des systèmes adaptables


http://p18.html/#coll


La figure 10 représente l'interaction entre les composants logiciels, par exemple les classesd'implémentation des objets « BancDeMesures », « Bobine » et « Multimètre », ainsi que leurs liensavec les tâches actives de l’application embarquée.



7.2 diagramme de déploiementLe diagramme de déploiement permet de représenter l'architecture physique, c'est-à-dire la

répartition de l'architecture logique sur l'architecture matérielle. Un diagramme de déploiement est undiagramme qui montre la configuration de nœuds de traitement en phase d’exécution ainsi que lescomposants qui se trouvent sur ces nœuds. Un diagramme de déploiement est un ensemble de sommetset d’arcs. Lorsqu’on modélise la vue de déploiement statique d’un système, on utilise habituellementdes diagrammes de déploiement pour une des trois situations suivantes :

➢ Systèmes embarqués

➢ Systèmes client/serveur

➢ Systèmes répartis

Ce schéma montre la disposition physique des différents matériels (ou nœuds) qui entrent dans lacomposition du système. On retrouve

• la répartition des composants (cf. diagrammes de composants) au sein des nœuds.

• La composition du diagramme :

◦ les dispositifs physiques (les nœuds),

◦ les objets d’implantation attachés aux nœuds (les composants)

◦ les liens représentants les moyens de communication entre les nœuds (les supports decommunication).

7.2.1 Les nœudsChaque ressource matérielle est représentée par un nœud. En général, cette ressource possède ses

propres attributs (capacité mémoire, capacité calculatoire,...).

• Exemple : calculateur, ressource humaine, imprimante

7.2.2 les supports de communicationLes supports de communication sont symbolisés par des relations entre les nœuds.


poste administrateur

aplicationclient

serveur sureau

applicationserveur

autre serveur

serveur chene

ethernet + TCP/IP

ethernet + TCP/IPethernet + TCP/IP

Tous les postesserveurs disposedu mêmeprogrammeserveur

Le poste administrateurinterroge un posteserveur pour connaîtreson identification


• La nature du support peut être précisée par un stéréotype :

<<rs232>>

• Le support de communication est a priori bidirectionnel.

7.2.3 Exemple introductifUn système de gestion de parking dispose d'un poste de supervision capable d'assurer le suivi

journalier du parking. L'entrée et la sortie du parking sont gérées par une borne d'accès. Celle-cicommunique à intervalle régulier avec le poste de supervision grâce à une communication TCP/IP

Un automobiliste se fait communique à l'aide des éléments suivants présents sur la borne :

• un clavier pour les usagés réguliers

• un lecteur de cartes pour les résidents

• un bouton d'appel gardien pour les livreurs

• un afficheur pour transmette à l'usager des messages

• ces éléments sont reliés à la borne avec un bus I2C

La borne pilote la barrière, les boucles de détection des voitures avec un bus CAN


MODELISATIONUML MODELISATION OBJET

Modélisation de l’aspect statique des objets

8 LES DIAGRAMMES DE CLASSESLes diagrammes de classes montrent les composants du système en terme de classes, et de relation

entre les classes. Ces diagrammes présentent l’aspect interne du système. Ils mettent l’accent sur lesrelations entre les différentes classes de l’application. Les classes ont déjà été décrites au premierchapitre. Nous allons montrer ici les différents types de relation entre les classes.

8.1 L’héritage et la généralisation

8.1.1 DéfinitionDe nombreux objets ne diffèrent que par quelques éléments, aussi les classes d'objets sont-elles

organisées hiérarchiquement. Une classe de base nommée superclasse regroupe les éléments communs àplusieurs sous-classes. Par héritage, elles se transmettent leurs propriétés et leurs opérations degénération en génération. L’objectif étant de réutiliser le maximum de code déjà écrit.

Exemple :

Une sous-classe hérite de tous les attributs et méthodes de la superclasse, mais peut posséder desattributs et des méthodes qui lui sont propres.

Un autre point de vue est celui de la généralisation d’une ou plusieurs sous-classes, cetteabstraction permet de partager les points communs entre les classes tout en préservant leurs différences.


«business»::Fenêtre

«business»::Boîte de dialogue

«business»::Zone de saisie

«business»::Bouton

«business»::Capteur

«business»::Capteur de vitesse

«business»::Capteur de température

«business»::Capteur de pression


Cette relation entre deux classes peut se traduire par «est une sorte de ». Chaque sous-classereprésente une spécialisation de la superclasse.

8.1.2 Intérêt de l'héritageL'héritage permet :

Ø De réutiliser du code déjà écrit (dans les superclasses), sans avoir recours à lacompilation.

Ø D'ajouter de nouvelles fonctionnalités à une classe sans modifier les programmesn'utilisant que les anciennes fonctionnalités. Il permet ainsi la mise en facteur.

Ø Au niveau des méthodes, la classe dérivée peut partager une fonction membre avec saclasse mère par héritage ou la redéfinir pour qu'elle ait un comportement différent. Leterme polymorphisme est alors retenu.

Ø Une classe dérivée est donc plus spécialisée que la classe de base. On peut aussiconstruire une classe de base à partir de plusieurs classes en recherchant les pointscommuns (généralisation). Les classes dérivées partageront par héritage les pointscommuns.

8.2 Les associationsUne association représente une relation entre au moins deux classes mais la plupart du temps, elle

est binaire. Elle se représente avec un trait continu sur lequel plusieurs indications s peuvent figurer :

8.2.1 Nom d’une associationLe nom de l’association qui est une forme verbale passive ou active et situé au milieu du trait. Le

sens de lecture peut être indiqué à l’aide d’un petit triangle. Ce nommage est en général à éviter.

8.2.2 Rôle des extrémités des associationsLes noms de rôle sont nécessaires pour distinguer deux associations d’un même couple de classe

ou pour l’association de deux objets d’une même classe. Dans les autres cas ils peuvent ne pasapparaître et dans ce cas, c’est le nom de la classe qui est utilisé comme nom de rôle.

L’extrémité d’une association possède un nom qui indique comment la classe source voit la classedestination à l’aide de cette association. Ce rôle correspond à un attribut de la classe et doit être unique.Chaque association binaire possède un nom de rôle à chaque extrémité. Il se présente sous formenominale et est placé à l’extrémité concernée.


Capteur Contrôle Moteur* 1Informe


8.2.3 Multiplicité des associationsLa multiplicité des associations indique le nombre d’objets de la classe considérée lié à un objet

de l’autre classe. Voici une liste des valeurs possibles :

1 Un et un seul objet

0..1 Zéro ou un objet

n N objets (n est un entier)

m..n De M à N objets

* De zéro à plusieurs objets

0..* De zéro à plusieurs objets

1..* De un à plusieurs objets

Voici quelques exemples d’associations avec leur nom de rôle


Classe

Classe

Classe

Classex..y

*

Exactement 1

Quelconque

1 ou plus

A partir de x jusqu'à y

1

1..*


8.2.4 Les classes associationsUne classe association se représente par une classe pour ajouter des attributs et des opérations

dans l’association. Dans l'exemple ci-dessous, un fichier a un propriétaire. Un utilisateur dispose dedifférents documents. La relation entre Fichier et Utilisateur est défini par les permissions d'accès enlecture, écriture et en exécution.

Voici des exemples d’attributs pour la classe : « permission d’accès »

Fichier Permission Utilisateur

/etc/termcap (Lecture) Pierre

/etc/termcap (Lecture/Ecriture) Jean

/etc/doc/.login (Lecture/Ecriture) Pierre

Exemple : Les utilisateurs ont des autorisations sur plusieurs stations de travail, chaqueautorisation porte des privilèges de priorité et d’accès. Un utilisateur possède unrépertoire de rattachement sur chaque station autorisé. Cependant le même répertoirede rattachement peut être partagé entre plusieurs stations ou par plusieursutilisateurs.


Utilisateur Station de travail

Répertoire

* *est autorisésur

Autorisation

prioritéprivilègeLancer Session

* 1

Utilisateur Répertoire

1 *

Estpropriétaire de

Propriétaire Propriété

* *

Visualise

Utilisateurautorisé

*

1

Contient

Conteneur

Contenu


La modélisation d’une association comme classe, se justifie lorsque une association dispose deplusieurs propriétés..

Lors de la conception, cette classe association devient une classe avec les cardinalités placées surla nouvelle classe :

8.2.5 Les noms de rôle des associationsUn rôle est une extrémité d’une association, il précise le rôle de la classe dans l’association.

Exemple :

Les noms de rôle sont nécessaires pour distinguer deux associations d’un même couple de classeet pour l’association de deux objets d’une même classe. Dans les autres cas ils peuvent ne pasapparaître et c’est le nom de la classe qui est utilisé comme nom de rôle.

8.3 Les agrégationsL’agrégation représente une association non symétrique dans laquelle une des extrémités remplit

un rôle plus important. L’agrégation ne concerne qu’un rôle d’une association. Elle se représente par unlosange vide situé du côté de l’agrégat.

Une agrégation peut indiquer :

Ø qu'une classe (un « élément ») fait partie d'une autre ("l'agrégat"),

Ø qu’un changement d'état d'une classe, entraîne un changement d'état d'une autre,

Ø qu'une action sur une classe, entraîne une action sur une autre.

A un même moment, une instance d'élément agrégé peut être liée à plusieurs instances d'autresclasses (l'élément agrégé peut être partagé).

Une instance d'élément agrégé peut exister sans agrégat (et inversement) : les cycles de vies del'agrégat et de ses éléments agrégés peuvent être indépendants.



8.4 La compositionLa composition est un cas particulier d’une agrégation. La classe prédominante est appelée classe

composite. Elle se représente par un losange plein du côté de la classe conteneur (encore appeléecomposite)

La composition est une agrégation forte (agrégation par valeur). Un attribut de classes peutêtre considéré comme une composition. Une composition outre les caractéristiques de l’agrégationimplique que :

Ø Les cycles de vie des éléments (les « composants ») et du conteneur sont liés : si leconteneur est détruit (ou copié), ses composants le sont aussi.

Ø A un même moment, une instance de composant ne peut être liée qu'à un seulconteneur.

Ø Les « objets composites » sont des instances de classes composées.

Dans l’exemple ci-dessous un poste de travail est composé de 7 vérins et de 5 capteurs.

Le choix d’une composition plutôt qu’une agrégation peut se justifier par le fait que l’existenced’un objet composite dépend de l’existence de l’objet conteneur. Les vérins et les capteurs n’ont deraison d’être que s’ils sont une partie du poste de travail.

En fait, les représentations graphiques des attributs et de la composition sont équivalentes. Onpeut représenter la composition précédente de la manière suivante :

Modélisez un email à partir de la description suivante :

celui-ci dispose d'un objet, (le titre) d'au moins un destinataire

il peut comporter un texte

il est possible de lui attacher des pièces jointes


Poste de travail

Capteur5

Vérin7

Poste de travail

Verin Capteur

1

7 5

1

MODÉLISATIONUML MODÉLISATION ASPECT DYNAMIQUE

MODÉLISATION DE L’ASPECT DYNAMIQUE DESOBJETS

9 LES DIAGRAMMES ÉTAT TRANSITIONS

9.1 IntroductionDans un système, l’aspect contrôle concerne le séquencement des opérations en réponse à des

stimuli externes. Les principales notions sont, l’événement qui représente un stimulus externe et l’étatqui modélise une configuration de valeurs pour un objet à un instant donné. Le modèle utilisé est lediagramme états transitions de David Harel. Avec les diagrammes de séquences, les diagrammes d'étattransitions sont les vues dynamiques les plus importantes d'UML

Ce type de diagramme représente le comportement de classes mais il peut également être utilisépour présenter l’aspect dynamique des cas d’utilisation, d’acteur, de sous système, d’opération ou deméthode.

9.2 États et événements

9.2.1 Notion d’événementA tout moment, dans un modèle objet, les objets interagissent entre eux en s’envoyant des

événements. Un événement se produit à un instant précis et n’a pas de durée ou elle est négligeable dansle contexte du problème. Un événement est une information instantanée qui doit être traitée sans délai.Deux événements qui n’ont aucun lien de cause à effet sont dits concurrents. Ils peuvent se produiredans n’importe quel ordre. Un événement peut déclencher le passage d’un état à un autre.

9.2.2 Notion d’étatUn état représente un intervalle de temps entre l’arrivée de deux événements sur un objet. Il est

souvent associé à une activité qui est réalisée pendant la durée de cet état. Un état dépend des étatsprécédents et des événements survenus. Le passage d’un état au suivant est généralement instantané, carle système est toujours dans un état connu.

9.3 Diagramme d’états transitionsUn diagramme d’états relie des événements et des états. Quand un événement est reçu, l’état

suivant dépend autant de l’état courant que de l’événement lui-même. Une modification d’état estnommée transition.

Un état est représenté par une boîte arrondie portant un nom représentatif. Une transition estsymbolisée par une flèche orientée suivant l’enchaînement possible des états. Le nom sur la flèchedésigne l’événement provoquant la transition.

Exemple de diagramme

En attente Alarme

Début

Arrêt surveillance

Temps écoulé

Prise en compteFin



Le point noir désigne le point d’entrée du diagramme, celui avec un cercle autour représente l’étatfinal. Un diagramme état transition peut avoir plusieurs points de sorties, mais n’a qu’un seul étatinitial. Il n’est pas nécessaire de fournir un nom à l’état initial et aux états finaux.

9.3.1 Les gardes ou condition de gardeUne condition de garde est une condition booléenne qui permet de contrôler le changement d’état

lorsqu’un événement arrive sur une transition. Elle est représentée entre crochets à la suite del’événement.

Exemple de diagramme

Chauffage

Ventilation forcée

Ventilation normale

Top Horloge [température > 90°]

Top Horloge [température < 90°]

9.3.2 Les opérations, activités et actionsLes transitions entraînent des changements d’état mais elles peuvent déclencher également des

opérations. Les opérations représentent soit une action, soit une activité.

Une action a une durée négligeable, exemple générer un autre événement. Elle peut envoyer dessignaux, invoquer une opération déclarée dans la classe de l’objet concerné, créer ou détruire des objets.Une action est considérée non interruptive, elle doit se terminer pour qu’une autre action puisse avoirlieu.

Une activité dure un temps non négligeable, elle est associée à un état. L’activité se déroule soitpendant toute la durée de vie de l’état (cas des opérations continues) soit, elle s’arrête d’elle-même à lafin du traitement (cas des opérations séquentielles), elle peut être interrompue à tout moment, dès que latransition de sortie de l’état est déclenchée.

L’action ou l’activité est représentée par un «/» suivi du nom de l’opération à la suite del’événement

. Un état peut engendrer plusieurs activités en séquence. Un ordre d’exécution est établi pardifférents mots clés :

Un événement peut provoquer une action sans provoquer un changement d’état. Dans la boîte ontrouve alors :

Entry/action action exécutée à l'entrée de l'état

Exit / action action exécutée à la sortie de l

On evenement / action action exécutée à chaque fois que l'événement cité survient

Do / action action récurrente ou significative, exécutée dans l'état

De plus, lors des transitions d’entrée et de sortie d’un état, il est possible de réaliser également desactions :

Transition d’entrée action exécutée lorsque la transition d’entrée arrive

Transition de sortie action exécutée lorsque la transition de sortie arrive



Il faut noter que la transition interne (evt interne) n’entraîne pas l’exécution des autres actions àl’intérieur de l’état.

9.4 Les diagrammes d’activitésC’est une variante du diagramme état transition. Dans ce diagramme, ce sont les activités et les

transitions qui sont prépondérantes.

Ce diagramme est utilisé pour décrire le comportement dynamique du système en réponse audemande d'un acteur. Il permet de décrire un scénario de cas d'utilisation sans se préoccuper decontrainte d'implémentation.



9.4.1 Les états actionsUn état action modélise une étape d’un algorithme dans laquelle une action se déroule et se termine

automatiquement mettant fin à l’état. Il n’y a donc pas lieu de noter la transition entre deux états actionspuisque c’est la fin automatique de l’action qui la déclenche.

9.4.2 La synchronisation Les transitions concurrentes représentant les synchronisations dans les diagrammes d’activités se

représentent à l’aide de barres qui permettent l’ouverture ou la fermeture de branches parallèled’activités. :



9.4.3 éléments graphiques

Symbole Signification

Représente un état associé à une action c'est à dire qu'en quittant l'état, l'action est également terminée

Une décision est à prendre

Début d'activité de ce diagramme

Fin d'activité de ce diagramme

Nouvelle jointure (fin de plusieurs traitements) ou nouvelle activité à réaliser en parallèle (au moins deux trait repartent de la barre

Une transition entre deux état, un état et une jointure...

Un nouvel objet

Flot entre objet

Réception d'un signal

Émission d'un signal

Partition du diagramme . Les partitions permettent de séparés les différentes activités


Documents

Analyse et Conception Objets - Espace Numerique de Travailtouchardinforeseau.servehttp.com/siteweb20142015/20142015/IRIS2... · MODELISATION UML Le modèle objet La modélisation