[PDF] Cours langage UML : les diagrammes d’états-transitions | Cours informatique

1

Faculté des Sciences Dhar El Mehraz de Fès

Département de Mathématique et Informatique

Master Qualité du Logiciel

Rapport de Formation

:

MODELISATION UML

Document réalisé par HANGAMA Cédric

Etudiant en Master 1, Qualité du Logiciel

2

Sommaire

I. INTRODUCTION GENERALE ... 3

II. LES DIAGRAMMES UML ... 5

Chap. I Les diagrammes des cas d’utilisation ... 5

1.

Définition et Objectifs ... 5

2.

Notations et Variantes... 6

3.

Une étude de cas ... 10

Chap. II. Le diagramme de séquence ... 12

1.

Définition et Objectifs ... 12

2.

Type de message ... 13

3.

Activation et envoi des messages ... 14

4.

Fragments d’interaction combinés. ... 14

Chap. III. Le diagramme des classes ... 18

1.

Définition et Objectifs ... 18

2. Notations et Variantes... 19

3. Une étude de cas ... 21

Chap. IV. Le diagramme d’état - transition ... 21

1.

Définition et Objectifs ... 21

2.

Notation et variantes... 22

3.

Etapes d’élaboration d’un diagramme d’états – transitions ... 23

3

I. INTRODUCTION GENERALE

Pour développer un logiciel, il ne suffit pas de se lancer directement dans les lignes de code. Le développement d’une application exige une préparation rigoureuse : Il faut documenter ses idées, définir et organiser les différents modules de l’application et préciser les étapes de réalisation. Cette étape ultime, dans la technologie objet, se nomme modélisation. C’est une démarche antérieure au codage, c'est-à-dire la réalisation des modules de l’application. Elle comprend l’analyse des besoins utilisateurs et la conception des objets du système ; le but étant de produire le plus rapidement

possible une application qui satisfasse au mieux ses utilisateurs et d’assurer la compréhension de systèmes souvent complexes.

Dans le présent document, il s’agit de détailler un des langages de modélisation les plus en vogue, UML, car intégrant le concept objet dans son formalisme et permettant d’obtenir une modélisation de très haut niveau indépendante des langages et des environnements.

UML (Unified Modeling Language) est donc un langage unifié de modélisation permettant de modéliser un problème de façon standard et de fournir une notation standard utilisable dans le développement de systèmes informatiques basés sur l’objet. Il est né de la fusion de plusieurs méthodes existant auparavant et a été conçu pour permettre la modélisation de tous les phénomènes de l’activité d’une entreprise et ce indépendamment des techniques d’implémentation mises en œuvre par la suite. UML est devenu actuellement la référence en termes de modélisation objet.

Il est à signaler qu’UML ne suffit pas à lui seul à produire un développement logiciel de qualité. Ce n’est qu’un ensemble de formalismes, un outil permettant d’appréhender un problème. Le succès du développement du logiciel dépendra surtout de la façon dont on utilisera UML à l’intérieur du cycle de développement du logiciel ce qui permettra par exemple d’étendre la réutilisabilité de ce dernier.

a. Les objectifs du langage UML

UML est un langage formel et normalisé qui nous offre un gain de précision avec un gage de stabilité car étant un support de communication performant, facile et compréhensible du fait de sa souplesse. L’utilisation de l’approche objet avec UML réduit l’écart entre le langage utilisateur et le langage conceptuel. Il est aussi adapté à toutes les phases de développement logiciel et compatible avec toutes les techniques de réalisation.

Les objectifs de ce langage de modélisation sont multiples :

 Proposer un langage visuel de modélisation ce qui réduit l’ambigüité d’un système complexe.  Etre indépendant des langages particuliers de programmation.

 Coordonner les équipes d’analyse et de conception et séparer l’analyse de la réalisation.  Exprimer dans un seul modèle tous les aspects statiques, dynamiques ou même de

spécification.

 Prendre en compte l’évolution de l’analyse et du développement.

 Migrer facilement vers une architecture objet d’un point de vue statique et dynamique.  Encourager également l’application des outils orientés objets.

4

Etc.

b. L’approche Orienté Objet

La programmation orientée objet consiste à modéliser un ensemble d’éléments d’une partie du monde réel en un ensemble d’entités informatiques appelés objets. Elle repose sur un certains nombre de concepts qui sont des abstractions permettant de modéliser plus facilement le comportement d’un programme. Ces différents concepts de base sont entre autres :

- les Objets

- Les Classes d’objets correspondant à une entité abstraite d’un niveau supérieur - L’association des données et des traitements dans une même entité

- L’encapsulation masquant les données et traitements internes de l’objet - Des niveaux d’accès aux données et traitements (publique, privé, protégé) - La séparation des interfaces de manipulation de l’implémentation des traitements - L’héritage (généralisation et spécialisation).

- Le polymorphisme, un mécanisme permettant l’invocation d’opérations sur des objets avec abstraction du type de l’objet destinataire du message.

Le principe de l’approche objet est donc de modéliser des propriétés statiques et dynamiques de l’environnement dans lequel sont définis les besoins ce qui permettra de réduire l’écart sémantique entre la réalité et les différents modèles.

c. La démarche UML

Dans le cadre de la modélisation d'une application informatique, UML préconise une démarche :  Guidée par les besoins des utilisateurs du système

Le périmètre du système à modéliser est défini par les besoins des utilisateurs étant donné que le système doit répondre aux exigences de ces derniers.

 Centrée sur l’architecture logicielle

Une architecture adaptée est la clé d’un succès d'un développement. Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité...). Cette démarche peut être simplifiée en un ensemble de techniques permettant de passer des modèles de l’application au codage de l’application :

1. Identification des cas d’utilisation 2. Réalisation du diagramme de séquences 3. Description le modèle conceptuel 4. Elaboration de diagramme d’interaction

5. Réalisation du diagramme des classes de conception 6. Production du code

5

II

LES DIAGRAMMES UML

Les diagrammes UML fournissent les informations sur un problème et sa solution. Ils forment les modèles du système (spécifier, visualiser) et peuvent montrer tout ou partie des caractéristiques des éléments de modélisation, selon le niveau de détail utile dans le contexte d’un diagramme donné. UML distingue principalement 9 sortes de diagrammes (13 avec la nouvelle version UML2.0) reparties sur trois axes de modélisation pour représenter les différents points de vue de modélisation :

 Vue fonctionnelle :

 Le diagramme des cas d’utilisation  Vue statique :

 Le diagramme des classes  Le diagramme d’objet  Le diagramme d’implémentation  Le diagramme de déploiement  Vue dynamique :  Le diagramme de séquence  Le diagramme de collaboration  Le digramme d’état  Le diagramme d’activité

Dans le présent rapport, on invoquera les modèles qui ont été principalement évoqués durant notre formation UML.

Chap. I Les diagrammes des cas d’utilisation

1. Définition et Objectifs

Un cas d’utilisation est tout simplement la description des interactions entre l’utilisateur et le système. Il s’agit ici d’élaborer un diagramme qui permet aux utilisateurs de structurer et d’articuler leurs désirs ; un diagramme qui les oblige à définir la manière dont ils voudraient interagir avec le système, à préciser quelles informations ils entendent échanger et à décrire ce qui doit être fait pour obtenir le résultat escompté.

6

 De concrétiser le futur système dans une formalisation proche de l’utilisateur.

 De favoriser la définition d’un cahier des charges reflétant réellement de l’utilisateur final du système.

 De donner une vision globale du comportement fonctionnel du système logiciel.

 De servir d’un support de communication exprimant ce que le client (l’utilisateur final) attend du système.

Ils forment dans leur ensemble des séquences d’actions observables, représentant les différentes manières de se servir fonctionnellement du système.

En produisant une collection des uses cases, on arrive à décrire l’ensemble des fonctionnalités à développer d’une façon claire et compréhensible pour tous les intervenants du projet. Il s’agit donc l à d’une conception du système centrée sur l’utilisateur et sur les taches qu’il peut accomplir.

2. Notations et Variantes

La modélisation UML intègre dans son formalisme certaines notions pour représenter le diagramme des cas d’utilisations. On distingue :

 Le cas d’utilisation  Les acteurs du système

 Les différentes relations entre acteurs, entre cas d’utilisation et entre acteur et cas d’utilisation  Description textuelle des cas d’utilisation

 Les scenarios

a. Le cas d’utilisation

Le cas d’utilisation représente la fonctionnalité du système. Dans la notation UML, il est décrit par un verbe à l’infinitif et un complément. Il est représenté en UML par une ellipse contenant un nom décrivant la fonctionnalité du cas et éventuellement un stéréotype :

b. Les acteurs

Un acteur est un élément externe qui interagit avec le système. Cet élément peut être un utilisateur ou un système tiers. UML distingue 4 grandes catégories d’acteurs :

- Les acteurs principaux qui utilisent les fonctions principales du système

- Les acteurs secondaires, ceux qui effectuent des tâches administratives ou de maintenance - Le matériel externe, un dispositif matériel faisant partie du domaine de l’application et devant

être utilisé.

<<stereotype>> Nom du cas d'

7

- Les autres systemes externes, qui doivent interagir avec le système à modéliser.

Un acteur peut être représenté en UML sous forme d’un bonhomme (par exemple pour les acteurs principaux et secondaires) :

Exemple :

On peut également le représenter sous forme d’un classeur lorsqu’il s’agit par exemple de représenter un acteur système externe ou matériel externe :

Exemple :

c. Les relations dans un diagramme des use cases

UML fournie de nombreuses relations entre acteurs du système ou entre cas d’utilisation pour mieux structurer un diagramme des cas d’utilisation et le rendre plus compréhensible :

 Les relations entre acteur et cas d’utilisation

UML définit une relation entre acteurs et cas d’utilisation, la relation d’association. Cette relation correspond précisément a un potentiel de communication entre acteurs et système.

 Les relations entre cas d’utilisation, qui permettent d’organiser les interactions. UML distingue trois types de relation standard entre cas d’utilisation :

- <<include >> : un cas d’utilisation qui incorpore explicitement et de manière obligatoire un autre cas d’utilisation à l’ endroit spécifié.

- <<extend>> : un cas d’utilisation qui incorpore implicitement de manière facultative un autre cas d’utilisation à l’ endroit spécifié. Dans une relation d’extension entre cas d’utilisation, le cas d’utilisation source ajoute son comportement au cas d’utilisation destination.

- Généralisation, une relation qui permet à un sous cas d’utilisation de spécialiser le comportement d’un cas d’utilisation de base.

Exemple :

8

 Les relations entre acteurs

La seule relation possible entre acteurs est la relation d’héritage qui permet d’éviter de surcharger le diagramme car un acteur qui hérite d’un autre acteur hérite aussi de toutes ses associations.

Exemple :

d. Description textuelle des cas d’utilisation

Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue des acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation.il est

<<include>>

<<extend>> <<extend>>

CEDST

Administrer les candidatures Authentification

Consulter les candidats valider inscription

Préposé aux commandes

Directeur des ventes

Passer une commande

Suivre une commande

9

donc recommandé de rédiger une description textuelle car c’est une forme souple qui convient dans bien des situations. L’idée est de fournir un format de présentation textuelle à la fois souple et riche. Une description textuelle d’un cas d’utilisation se compose essentiellement de 3 parties :

 La première permettant d’identifier le cas d’utilisation et doit contenir les informations suivantes :

- Le nom du cas

- L’objectif, une description résumée permettant de comprendre l’intention principale du cas d’utilisation

- Les différents acteurs (principaux et secondaires)

- Les dates de création et de mise à jour de la description courante - Le nom des responsables et le numéro de version

 La deuxième partie contient la description du fonctionnement du cas sous la forme d’une séquence de messages échangés entre les acteurs et le système. Elle contient toujours une séquence (scenario) nominale qui décrit le déroulement normal du cas. À la séquence nominale peuvent s’ajouter des séquences alternatives et des séquences d’exceptions (qui

interviennent quand une erreur se produit).

Dans cette partie, on spécifiera donc les éléments suivants :

- Les pré- conditions, décrivant dans quel état doit être le système avant que ce cas d’utilisation puisse être déclenché

- Les différents scénarios décrits sous la forme d’échange d’événements entre l’acteur et le système

- Les post conditions décrivant l’état du système a l’issu des différents systèmes

 La troisième partie, qui est une rubrique optionnelle, contient généralement des spécifications non fonctionnelles. Elle peut éventuellement contenir une description des besoins en termes d’interface graphique.

e. Les scénarios

En plus du diagramme des cas d’utilisation, les cas d’utilisation serviront à élaborer des scénarios de cas d'utilisation. Les scenarios consistent en une description textuelle de chaque cas d'utilisation. On y détaillera de façon textuelle toutes les interactions entre les acteurs et l'application ; en précisant aussi les variantes possibles d’un même scenario. Un cas d’utilisation propose en effet différents comportements :

 Un scénario nominal, idéal, décrivant les interactions entre l’acteur et le cas d’utilisation dans un cas typique de succès.

 Un scénario alternatif proposant un flot d‘événements alternatifs qui peuvent soit revenir au scénario nominal ou déboucher a un échec

10

En rédigeant un scénario de cas d'utilisation, on doit considérer le système comme une « boîte noire » qui ne peut qu'accepter des requêtes provenant des acteurs, et retourner des résultats à ces mêmes acteurs. On se préoccupe pas à savoir comment cette boîte noire accomplit les requêtes.

Les cas d'utilisation font aujourd'hui partie intégrante d’UML et constituent d'ailleurs le premier critère à prendre en compte dans le choix de la méthode associée à UML. Ils font référence aux acteurs, c.-à-d aux "choses" externes au système et qui communiquent avec le système. La démarche consistera donc à identifier les différents acteurs du système et à pouvoir recenser les différents cas d’utilisation du système.

3. Une étude de cas

Pour mieux illustrer toutes les étapes de modélisation UML dans la specification des cas d’utilisation, faisons une étude de cas spécifique. Dans notre exemple, il s’agit de modéliser un système e-commerce

Enoncé :

Le commerce électronique dans cette étude de cas, concerne le processus d’achat/vente de livres sur Internet. La société BookStore est spécialisée dans la vente de livres de tout type (science, littérature, Art, etc…) et sur tout support (livre papier, numérique, DVD, etc..). BookStore reçoit ses commandes par fax et les chèques par courrier puis envoie le bon de commande au client. Une fois le chèque encaissé par la banque partenaire BookBank, elle utilise la société de transport BookEx pour acheminer les livres vers leurs clients. La société BookStore possède un système « Gestion des stocks » qui met à jour les données concernant le prix et l’état du stock des livres du catalogue. Ce système est

automatiquement chargé dans la base de données de façon périodique.

Actuellement, La société BookStore souhaite réaliser un site e-commerce pour gérer seulement la vente de ses livres en ligne, gérer son catalogue de livre et sa base de données de clients. L’objectif

fondamental du futur site BookStore est de permettre aux internautes de rechercher des ouvrages par thème, auteur, mot-clé, etc., de se constituer un panier virtuel, puis de pouvoir les commander et les payer directement sur le Web.

1. Diagramme de cas d’utilisation.

a. Identifier les acteurs du système. b. Identifier les cas d’utilisation.

11

1. La première étape consiste à identifier les différents acteurs du système. Pour y parvenir, on se posera des questions comme :

Qui utilise le système ? Qui maintient le système?

Quels sont les autres systèmes qui utilisent le système ? Qui récupère de l’information à partir du système ?

Ainsi, on pourra facilement identifier les acteurs du système e-commerce présent. on a comme acteurs externes du système :

-Un internaute naviguant sur le site e-commerce - Un visiteur voulant s’inscrire pour devenir membre -Un client de la société BookStore

-Le système de gestion de stock -L’administrateur du site

-La banque BookBank pour encaisser les chèques

2. Deuxième étape, identification des cas d’utilisation. Pour identifier les cas

d’utilisation, il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert du système. On notera par exemple que :

- Un visiteur du site e-commerce pourra s’inscrire et devenir membre du site - Un internaute devra pouvoir rechercher des ouvrages et gérer son panier - Un client membre du site pourra commander un livre par exemple et le payer - Un client membre devra s’authentifier pour accéder au système

- Le système de gestion de stock est utilise pour maintenir le catalogue

- L’administrateur du site pourra par exemple gérer les clients et maintenir le site

3. Avec la troisième étape, il s’agit de dessiner le diagramme des cas d’utilisation. L’outil de modélisation utilisé dans notre étude est le powerAMC.

12

Signalons que dans la réalisation d’un diagramme de cas d’utilisation, il n’est pas conseillé de spécifier tous les cas possible. Un certain niveau d’abstraction est recommandé, en représentant juste les cas d’utilisation généraux du système.

Chap. II. Le diagramme de séquence

1. Définition et Objectifs

Pour accompagner la description textuelle des cas d'utilisation, UML fournit un autre modèle de diagramme, le diagramme de séquences. Le diagramme de séquences permet de représenter des collaborations entre objets selon un point de vue temporel c.-à-d en mettant l'accent sur la

<<include>> <<include>> <<include>> <<include>> <<include>> Rechercher ouvrage S'inscrire Se constituer un panier Internaute Visiteur Client S'authentifier Commander Payer Maintenir le site Verifier le catalogue

Gerer les clients

Administrateur du site

BookBank Systeme Gestion de Stock Maintenir le

13

chronologie des envois de messages. Il modélise donc les interactions acteurs/système dans les scenarios spécifiques et est le plus répandu des diagrammes d’interaction.

Il est utile pour mieux comprendre la séquence des opérations dans un cas d'utilisation. Voici comment il fonctionne :

1. On place les acteurs à gauche et, à droite, le système entier représenté par une boîte. 2. On ajoute ensuite des lignes verticales qui représente le passage du temps, du haut vers le

bas.

3. Les interactions entre l'utilisateur et le système sont marquées par une ligne, avec une flèche indiquant la direction du message. Une description de l'interaction est écrite au-dessus de la flèche.

Exemple du cas d’utilisation « retrait argent » dans un distributeur automatique

Il est possible de représenter dans un diagramme de séquence des structures de contrôle, de création et de destruction d’objet, des branchements conditionnels et même des contraintes temporelles.

2. Type de message

Les principales informations contenues dans un diagramme de séquence sont les messages échangés entre les lignes de vie, présentés dans un ordre chronologique. Un message définit donc une

communication particulière entre des lignes de vie (objets ou acteurs).

Les diagrammes de séquence distinguent deux grandes catégories d’envoi de message:

 Les envois synchrones pour lesquels l’émetteur est bloqué et attend que l’appelé ait fini de traiter le message.

 Les envois asynchrones pour lesquels l’émetteur n’est pas bloqué et peut continuer son exécution

14

Exemple :

- Les messages simples et synchrones sont tous deux synchrones. Ce qui les différentie, c’est le mode de contrôle.

- Un message simple convient pour les systèmes à un seul flot de contrôle, donc automatiquement l’émetteur est bloqué jusqu’à la réponse du destinataire.

- Un message synchrone convient aux systèmes à plusieurs flots de contrôle, l’émetteur a son propre flot de contrôle mais il reste néanmoins bloqué jusqu’à la réponse du destinataire. - Pour pouvoir éditer les propriétés d’un message, l’objet destinataire doit être instance d’une

classe.

3. Activation et envoi des messages

Les diagrammes de séquence permettent de représenter les périodes d’activité des objets. Une période d’activité correspond au temps pendant lequel un objet effectue une action, soit directement, soit par l’intermédiaire d’un autre objet qui lui sert de sous-traitant. Les périodes d’activité se représentent par des bandes rectangulaires placées sur les lignes de vie. Le début et la fin d’une bande correspondent respectivement au début et à la fin d’une période d’activité.

4. Fragments d’interaction combinés.

Un 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é. Les fragments combinés permettent de décrire des diagrammes de séquence de manière compacte et peuvent faire intervenir l’ensemble des entités participant au scénario ou juste un sous-ensemble.

Un fragment combiné se représente de la même façon qu’une interaction. Il est représenté dans un rectangle dont le coin supérieur gauche contient un pentagone. Dans le pentagone figure le type de la combinaison, appelé opérateur d’interaction. Les opérandes d’un opérateur d’interaction sont séparés par une ligne pointillée. Les conditions de choix des opérandes sont données par des expressions booléennes entre crochets ([ ]).

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

 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 ;

15

Dans notre formation UML, nous n’avions abordé que quelques-unes de ces interactions, celles plus fréquemment utilisées à savoir les opérateurs de choix et de boucle (alt, loop et option) ainsi que l’operateur de réutilisation d’une interaction, ref.

 l’operateur alt

L'opérateur alt désigne un choix, une alternative. Il représente deux comportements possibles : c'est en quelque sorte l'équivalent du SI...ALORS...SINON : donc, une seule des deux branches sera réalisée dans un scénario donné. La condition d'exécution d'une des deux branches (l'équivalent du SI) peut être explicite ou implicite.

L'utilisation de l'opérateur else permet d'indiquer que la branche est exécutée si la condition du alt est fausse.

Exemple : cas d’utilisation « Paiement » du système e-commerce

 l’operateur opt

L’operateur opt désigne un fragment combiné optionnel, c'est à dire qu'il représente un comportement qui peut se produire ou pas. Un fragment optionnel est équivalent à un fragment "alt" qui ne

Paiement

effectuer_Transaction() cumulerMontant()

choisir mode de paiement client :System Bookbank ref passerCommande() montant<somme montant>=somme alt effectuer_Transaction() cumulerMontant()

16

posséderait pas d'opérande else (qui n'aurait qu'une seule branche). Un fragment optionnel est donc une sorte de SI...ALORS

Exemple : le cas d’utilisation « rechercher ouvrage » du system e-commerce

 l’operateur loop

L’opérateur loop est utilisé généralement pour décrire un ensemble d'interaction qui s’exécute en boucle. En général, une contrainte indique le nombre de répétitions (minimum et maximum) ou bien une condition booléenne à respecter.

Exemple : supposons un cas d’utilisation communication d’un système téléphonique

Rechercher_ouvrage AjouterPanier() AfficherLivre() ChoisirLivre(theme,auteur,editeur) internaute :System [choix du livre] opt AjouterPanier() AfficherLivre() ChoisirLivre(theme,auteur,editeur)

17

 l’operateur ref

Une interaction peut faire référence a une autre explicitement grâce a un cadre avec le mot clé « ref » Exemple : le cas d’utilisation « passer commande » du système e-commerce

Communication sonner() raccrocher() findecommunication() raccrocher() transferer() emettre() transferer() emettre() sonner() composer_Numero(numAbon) tonalite decrocher() Appelant Appelé CT loop sonner() raccrocher() findecommunication() raccrocher() transferer() emettre() transferer() emettre() sonner() composer_Numero(numAbon) tonalite decrocher()

18

En conclusion, ces diagrammes nous permettent de mieux cerner l’aspect dynamique du système. Il s’agit d’une représentation intuitive lorsque l’on souhaite concrétiser des interactions entre deux entités (deux sous-systèmes ou deux classes d’un futur logiciel) .Ils présentent des messages échangés entre des objets selon un point de vue temporel (chronologie d’envoi des messages et ligne de vie des objets) et diffèrent pour chaque d’utilisation.

Chap. III. Le diagramme des classes

1.

Définition et Objectifs

Le diagramme des classes est le diagramme le plus largement répandu dans les spécifications d'UML. Il s’agit d’un élément important dans une démarche de conception orientée objet, représentant les différentes entités (classes d’objet) intervenant dans le système à modéliser ainsi que les différentes relations entre celles-ci. Il offre une vue statique du système car il fait abstraction des aspects temporels et dynamiques.

L’élément classe dans la modélisation d’un diagramme de classes décrit les responsabilités, le

comportement et le type d’un ensemble d’objets. Il s’agit d’un ensemble de fonctions et d’attributs qui sont liés ensemble par un champ sémantique.

Les diagrammes des classes permettent donc de décrire d’une manière générique le comportement du système. Les autres éléments associés à la modélisation d’un diagramme de classes sont :

 Les spécifications générales de la classe (type, parent)  Les spécifications détaillées de la classe (cardinalité,…)  Les attributs et opérations de la classe

 Les associations entre classes  Les dépendances

19

2.

Notations et Variantes

Les éléments d'un diagramme des Classes sont principalement les classes et les relations qui les lient. a. Classe

La notion de classe est essentielle en programmation orientée objets ; elle définit une abstraction, un type abstrait qui permettra plus tard d’instancier des objets. On distingue

généralement des classes abstraites (qui ne peuvent pas être instanciées directement) et des classes "normales" qui servent à définir des objets. UML étant un langage de modélisation objet, il a la possibilité de représenter une classe.

Dans la notation UML, une classe est décrite par un rectangle compose de trois compartiments : - Le premier au niveau supérieur contenant le nom de la classe

- Le second pour la liste des attributs de la classe - Le dernier pour énumérer les méthodes de la classe

Exemple : classe Animal

Les deux derniers compartiments ne sont pas forcément représentés. b. Les relations entre les classes

Les diverses classes possèdent des relations de dépendance entre elles. Cette communication interclasse est effectivement primordiale car la manière dont les messages sont échangés entre les objets est un aspect important de la POO. Elles définissent le fonctionnement du programme. UML définit cinq types de relation interclasse qui sont couramment utilisés (il en existe d'autres) a savoir : - L’héritage - La dépendance - L’agrégation - La composition - L’association

Chacune d’elle répond à un contexte d'utilisation, et offre des avantages parfois subtils mais réels.  L’héritage

Elle présente une classe spécifique comme descendante d'une classe plus générique. Cette classe spécifique propose des méthodes dont la classe générique ne dispose pas, tout en conservant la

20

plupart des méthodes de cette classe "parente".

En UML, une dépendance est représentée par une ligne en tirets, terminée par une flèche évidée.

 La dépendance

La relation de dépendance présente l'utilisation que fait une classe d'une autre. Une classe dépend d'une autre si ses méthodes manipulent l'objet de cette classe. Par exemple, une classe Réservation ne pourrait exister que si la classe Compte indique les coordonnées de la personne... La dépendance est souvent stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle.

En UML, une dépendance est représentée par une ligne en tirets, terminée par une simple flèche.

 L’agrégation

Une relation d'agrégation indique un principe de subordination entre l'agrégat (classe qui regroupe les classes agrégées) et les agrégées. Concrètement, elle indique une "possession", une relation de contenant – contenu. En UML, une agrégation est représentée par une ligne entre deux classes, terminée par un losange vide ("diamant") du côté de l'agrégat.

 La composition

Il s'agit en fait d'une agrégation à laquelle on impose des contraintes internes : un seul objet peut faire partie d'un composite (l'agrégat de la composition), et celui-ci doit gérer toutes ses parties. En clair, les composants sont totalement dépendants du composite.

En UML, la composition est représentée de la même manière que l'agrégation, mais le diamant est plein.

 L’association

La relation d’association existe à partir du moment où l'une des deux classes sert de type à un attribut de l'autre, et que cet autre envoi des messages à la première (condition nécessaire pour une

association). Simplement, une association indique que deux classes communiquent entre elles (dans un sens ou dans les deux sens).

En UML, Elle est modélisée par une ligne reliant les deux classes. Cette ligne peut être qualifiée avec le type de relation, et peut également comporter des règles de multiplicité (par exemple un à un, un à plusieurs, plusieurs à plusieurs) pour la relation.

21

3.

Une étude de cas

Notre étude de cas concerne le système e-commerce déjà étudié ci-haut. Il s’agit maintenant d’élaborer le diagramme des classes correspondant.

Solution proposée.

Chap. IV. Le diagramme d’état - transition

1. Définition et Objectifs

Les diagrammes d’états-transitions d’UML décrivent le comportement interne d’un objet à l’aide d’un automate à états finis. Ils présentent les séquences possibles d’états et d’actions qu’une instance de classe peut traiter au cours de son cycle de vie en réaction à des événements discrets. Ils spécifient habituellement le comportement interne d’autres éléments tels que les cas d’utilisation, les sous-systèmes, les méthodes.

Le diagramme d’états-transitions est le seul diagramme, de la norme UML, à offrir une vision complète et non ambiguë de l’ensemble des comportements de l’élément auquel il est attaché. En effet, un diagramme d’interaction n’offre qu’une vue partielle correspondant à un scénario sans spécifier comment les différents scénarios interagissent entre eux. La vision globale du système n’apparaît pas

1..* adresse facturation 1..1 0..* adresse livraison 1..1 0..1 0..* 1 1..* 1..* 1..* 1..* 0..* 0..1 0..* 0..1 0..* 0..1 0..* 0..1 0..* 0..1 0..* Client -nom prenom login password email Adresse - adr Commande -numCommande date montant delai Editeur -nom pays Ligne -qtite montant Theme - libelle Auteur -nom prenom Ouvrage -ISBN titre date de parution prix Panier - total BookBank

22

sur ce type de diagramme puisqu’ils ne s’intéressent qu’à un seul élément du système indépendamment de son environnement.

Concrètement, un diagramme d’états-transitions est un graphe qui représente un automate à états finis, c’est-à-dire une machine dont le comportement des sorties ne dépend pas seulement de l’état de ses entrées, mais aussi d’un historique des sollicitations passées.

Ces diagrammes nous permettent donc :

 de décrire les changements d'états d'un objet ou d'un composant, en réponse aux interactions avec d'autres objets/composants ou avec des acteurs.

 De représenter l’évolution du système au cours du temps en réaction aux événements externes.

 De représenter une conjonction instantanée des valeurs des attributs d’un objet.

2. Notation et variantes

Un diagramme d’états est un graphe orienté d’états et de transitions. Exemple :

Les diagrammes d’état-transition sont basés sur les notions suivantes :  L’état d’un objet

Dans l’élaboration d’un diagramme d’état-transition, l’état représente une situation dans laquelle peuvent se trouver les objets d’une classe durant leur vie. Il a une durée finie, variable selon la vie de l’objet, en particulier en fonction des événements qui lui arrivent.

Un objet passe donc par une succession d’états durant son existence

En plus de la succession d’états « normaux » correspondant au cycle de vie d’un objet, le diagramme d’états comprend également deux pseudo-états a savoir:

- L’état initial du diagramme d’états correspondant à la création de l’instance. - L’état final du diagramme d’états correspondant à la destruction de l’instance. Exemple :

 Un événement qui est un stimulus interne ou externe envoyé à l’objet. Il se produit

Instantanément à l’échelle d’évolution du système et est noté entre guillemets. Un événement peut être

reçu ou envoyé par un objet.  Transition

Une transition indique le passage d’un état d’un objet a un autre état lorsqu’un événement se produit. Elle est représentée par une flèche pointée de l’état de départ vers l’état d’arrivée et qui porte les paramètres des événements qui lui sont associés.

23

 Un message qui est l’événement émis entre deux objets, l’objet émetteur et l’objet récepteur. Le mode de communication peut être synchrone ou asynchrone.

 Condition qui est une expression booléenne qui doit être vraie lorsque l’événement arrive pour que la transition soit déclenchée.

 Effet, action ou activité

Une transition peut spécifier un comportement optionnel réalisé par l’objet lorsque la transition est déclenchée. Ce comportement est appelé «effet». Cela peut être une simple action ou une séquence d’actions (une activité).

Soulignons que les activités associées aux transitions sont considérées comme atomiques, c’est-à-dire qu’elles ne peuvent être interrompues.

3. Etapes d’élaboration d’un diagramme d’états – transitions

 Identifier les états d’une classe. S’il y a des valeurs seuil d’attributs ou de

comportements conditionnels qui modifient le comportement dynamique, il faut définir les états en déterminant les événements reçus et émis par les objets.

 Représenter le scénario principal qui décrit la séquence essentielle d’événements.  Ajouter progressivement les transitions correspondant aux scénarios secondaires, qui décrivent les comportements alternatifs et d’erreur.

 Repérer les boucles. Si le scénario peut se répéter indéfiniment, boucler le chemin dans le diagramme.

 Compléter les actions sur les transitions et les activités dans les états.  Structurer en sous-états, si le diagramme est devenu trop complexe.

Il est souhaitable de construire un diagramme d’états-transitions pour chaque classe possédant un comportement dynamique important.

24

III

CONCLUSION

Dans le but d’assurer la qualité logicielle et de réduire les risques quelconques lies au développement logiciel, il s’impose d’établir des plans permettant d’organiser les différents modules de l’application et de préciser les étapes de réalisation ; donc de mettre en place une phase de modélisation.

Les langages de modélisation sont nombreux mais UML s’est impose car, intégrant dans ses formalismes l’approche objet, il permet de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes complexes et de faciliter la maintenance du logiciel.

UML est donc un langage de modélisation qui permet, outre le fait de se concentrer sur l’utilisateur, de documenter très clairement les besoins exprimes par ces derniers dans le cadre d’une gestion de projet de développement qui va de la conception jusqu’au déploiement de l’application.

UML nous fourni un ensemble de diagrammes regroupes en modèles fonctionnel, statique et dynamique qui permettent de modéliser un système d’informations. Durant notre formation, on a élaboré quatre de ces diagrammes qui, dans l’ensemble, présentent au mieux les besoins

fonctionnels :

 Le diagramme des cas d’utilisation décrivant les fonctions du système du point de vue de ses utilisateurs

 Le diagramme de séquence représentant la succession chronologique des opérations réalisées par un acteur.

 Le diagramme des classes pour représenter l’architecture conceptuelle du système a modéliser.

 Le diagramme d’état –transitions décrivant le comportement d’une classe en terme d’états lié au cycle de vie des objets.