cours uml 1

1

OFPPT OFPPT

ROYAUME DU MAROC

RESUME THEORIQUE &

GUIDE DES TRAVAUX PRATIQUES

MODULE N° : 8

TITRE DU MODULE : Spécification fonctionnelle d’une application informatique

SECTEUR : NTIC SPECIALITE : TSDI Niveau : TECHNICIEN Spécialisé

Décembre 2006

Office de la Formation Professionnelle et de la Promotion du Travail

Centre NTIC Settat

2

REMERCIEMENT

La DRIF remercie les personnes qui ont contribué à l’élaboration du présent document.

Pour la supervision : MME.BENNANI WAFAE DIRECTRICE CDC TERTIAIRE & TIC M. ESSABKI NOURDDINE CHEF DE DIVISION CCFF Pour la conception :

- MR MOHAMMED EL OUMAMI

Pour la validation :

- JELLAL ABDELILAH

Les utilisateurs de ce document sont invités àcommuniquer à la DRIF toutes les remarqueset suggestions afin de les prendre enconsidération pour l’enrichissement etl’amélioration de ce programme.

Said Slaoui DRIF

3

MODULE 8 : Spécification fonctionnelle d’une application informatique

Durée : 95 h

OBJECTIF OPERATIONNELS DE PREMIER NIVEAU DE COMPORTEMENT

COMPORTEMENT ATTENDU

Pour démontrer sa compétence, le stagiaire doit spécifier fonctionnellement une application selon les conditions, les critères et les précisions qui suivent.

CONDITIONS D’EVALUATION

• Epreuve écrite de type étude de cas

CRITERES GENERAUX DE PERFORMANCE • Utilisation des commandes appropriées. • Respect du temps alloué. • Respect des règles d’utilisation du matériel et logiciel Informatique.

4

OBJECTIF OPERATIONNELS DE PREMIER NIVEAU

DE COMPORTEMENT PRECISIONS SUR LE COMPORTEMENT ATTENDU A. Analyser le cahier des charges B. Créer et gérer le dictionnaire des données et des règles de gestion C. Modéliser D. Installer et Utiliser un outil de modélisation E. Créer le dossier de spécification

CRITERES PARTICULIERS DE PERFORMANCE • Description précise des limites du projet • Précision exacte de la liste des éléments

fonctionnels à réaliser • Organisation optimisée des travaux à

effectuer • Enumération exacte des éléments

techniques constitutifs du projet • Formalisation exacte du dictionnaire des

données et des règles de gestion à partir des éléments techniques extraits du cahier des charges

• Application judicieuse de la démarche et

du formalisme de la méthode UML pour l’analyse des traitements.

• Mise en oeuvre pertinente du modèle entité/association pour l’analyse des données et des règles de passage au modèle logique des données (Merise).

• Installation et paramétrage correct de

l’outil de modélisation • Utilisation adéquate des contrôles

sémantiques pour présenter les fonctionnalités de l’application à développer à l’aide de l’outil de modélisation.

• Documentation judicieuse des fiches de chaque modèle conçu.

5

OBJECTIFS OPERATIONNELS DE SECOND NIVEAU

LE STAGIARE DOIT MAITRISER LES SAVOIR, SAVOIR-FAIRE, SAVOIR -PERCEVOIR OU SAVOIR-ETRE JUGES PREALABLES AUX APPRENTISSAGES DIRECTEMENT REQUIS POUR L’ATTEINTE DE L’OBJECTIF DE PREMIER NIVEAU, TELS QUE :

Avant d’apprendre à analyser le cahier des charges (A) :

1. Expliquer l’intérêt d’un cahier de charge 2. Analyser les données de la situation présentée

Avant d’apprendre à Créer et gérer le dictionnaire des données et des règles de gestion (B)

3. Expliquer l’intérêt du dictionnaire des données et des règles de gestion

Avant d’apprendre à Modéliser (C ) :

4. Expliquer le formalisme de chaque méthode (Merise et UML) 5. Expliquer l’intérêt du model Entités/Association

Avant d’apprendre à Utiliser un outil de modélisation (D) : 6. Expliquer l’intérêt d’utilisation d’un outil de modélisation 7. Utiliser un outil de présentation graphique.

6

– Introduction :

• Constatations et état du marché

• Approche objet

• Inconvénients et remèdes

• Historique d’UML

– Les diagrammes UML

• Diagramme des cas d'utilisation

• Diagramme de classes, objets

• Diagramme de séquence

• Diagramme de collaboration

• Diagramme d'états – transition

• Diagramme de composants

• Diagramme de déploiement

7

L’état du Marché

• Quelle est la réalité du développement aujourd’hui ? • Est-ce que je peux partager mes systèmes existants ? • Puis-je intégrer de nouvelles applications ? • Quelle est l’adaptabilité de mon application (souplesse) ?

Le rythme effréné des changements technologiques: • Internet/Intranet, ERP • CORBA , COM/DCOM, ActiveX, Java, ... • Système Distribués à N-niveau

• Etat actuel : des dépendances ingérables entre des applications peu ou pas documentées

L’approche objet : une solution ?

• Maîtrise de la complexité Une décomposition objet décrit et décompose le problème étudié comme un ensemble d’objets autonomes qui collaborent pour réaliser certaines opérations. Chaque objet décrit un certain objet du monde réel et incorpore son propre comportement. Les objets inter-agissent en s’envoyant des messages demandant l’exécution de telle ou telle opération

• Réutilisation Les inconvénients de l’approche objet

• Moins intuitive que l’approche fonctionnelle ou chaque fonction du système est identifiée puis décomposée en sous-fonctions

• Dérive inévitable car rien dans les concepts de base de l’approche objet ne dicte

comment modéliser la structure objet d’un système de manière pertinente • Nécessité d’une grande rigueur dans l’application des concepts

UML : le remède Pour penser et concevoir objet, il faut savoir prendre de la hauteur, jongler avec des concepts abstraits, indépendants des langages d’implémentation et des contraintes purement techniques. Il nous faut donc :

• Un langage qui permette de représenter des concepts abstraits (graphiquement par exemple)

De limiter les ambiguïtés en permettant un discours commun avec un

vocabulaire précis indépendant des langages orientés objet.

De faciliter l’analyse

8

De définir des vues décrivant tous les aspects du système avec des concepts objets

Historique d’UML

10

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de la leçon : Les cycles de vie

Objectifs de la leçon : Le stagiaire doit être capable de Tracer un chemin au court de son analyse a fin de bien facilité son travail cela en passant d’une étape de cycle de vie a l’autre

Maintenance et évolution Validation Tests de vérification Implémentation Conception Analyse Spécifications Expression des besoins

Matériels et matière d’œuvre : Exercices

11

INTRODUCTION

Activités d’apprentissage Rappel

Une démarche de développement repose sur :

• Un formalisme, • Une méthode, • Un processus et un cycle de vie, • Des buts.

Les étapes du cycle de vie d'une application :

• Expression des besoins : Il traduit l'apport du futur système. • Spécifications : Précision avec schémas, modèles et enchaînements

d'écrans. • Analyse : Détermination des éléments du système. • Conception : Comprend tous les choix techniques. • Implémentation : Génération des squelettes d'une application. • Tests de vérification : Tests unitaires et finals. • Validation : Utilisation d'un cahier de recettes. • Maintenance et évolution : Suivi du logiciel en production.

Transition

Il est important de déterminer chaque cycle de vie étape par étape Pour bien réaliser une application

DEROULEMENT DU COURS

Les différents cycles de vie Il existe 2 cycles de vie utilisées dans les approches traditionnelles : le modèle linéaire et le modèle en “ V ”. Le modèle linéaire

12

Expression des besoins : ...

Spécification : Ce que le système doit être et comment il peut être utilisé.

Analyse :

L’objectif est de déterminer les éléments intervenant dans le système à construire, ainsi que leur structure et leurs relations. Elle doit décrire chaque objet selon 3 axes :

• Axe fonctionnel : savoir-faire de l’objet. • Axe statique : structure de l’objet. • Axe dynamique : cycle de vie de l’objet au cours de l’application (Etats

et messages de l’objet).

Ces descriptions ne tiennent pas compte de contraintes techniques (informatique).

La conception :

• Elle consiste à apporter des solutions techniques aux descriptions définies lors de l’analyse : architecture technique ; performances et optimisation ; stratégie de programmation.

• On y définit les structures et les algorithmes.

• Cette phase sera validée lors des tests.

L’implémentation : C’est la réalisation de la programmation.

Les tests de vérification :

13

Ils permettent de réaliser des contrôles pour la qualité technique du système. Il s’agit de relever les éventuels défauts de conception et de programmation (revue de code, tests des composants,...). Il faut instaurer ces tests tout au long du cycle de développement et non à la fin pour éviter des reprises conséquentes du travail (programmes de tests robustes ; Logiciels de tests).

Validation :

Le développement d’une application doit être lié à un contrat ayant une forme de

cahier de charges, où doivent se trouver tous les besoins de l’utilisateur. Ce cahier de charge doit être rédigé avec la collaboration de l’utilisateur et peut être par ailleurs complété par la suite. Tout au long des ces étapes, il doit y avoir des validations en collaboration également

avec l’utilisateur. Une autre validation doit aussi être envisagée lors de l’achèvement du travail de

développement, une fois que la qualité technique du système est démontrée. Elle permettra de garantir la logique et la complétude du système.

Maintenance et évolution

Deux sortes de maintenances sont à considérer :

Une maintenance corrective, qui consiste à traiter les “bugs ”. Une maintenance évolutive, qui permet au système d’intégrer de nouveaux besoins ou des changements technologiques.

Le principe de cette démarche est que chaque phase est traitée complètement avant que la suivante ne soit entamée. Ce qui renvoie les tests de vérification et la validation en fin du processus de développement. Le modèle en v

14

Autre représentation de cycle en V

Le modèle en “V” permet une organisation modulaire.

• A chaque étape de l’analyse et de la conception correspond une étape de tests ou de validation.

• A chaque étape fonctionnelle correspond ainsi une étape technique. Le processus s’accomplit en deux phases :

Expression des besoins

Conception du système

Conception des composants

Implémentation

Tests descomposants

Tests du système

Validation fonctionnelle

Spécifications fonctionnelles

Validation des besoins

Etude préalable

Réalisation logicielle

Etude technique

Etude détaillée


Tests d’intégration

Validation fonctionnelle

15

• Une phase descendante : de spécifications et de conception. • Une phase ascendante : de tests et de validation.

Comme pour le modèle linéaire, l’inconvénient est que la validation et les tests interviennent tardivement. Il y a aussi Modèle en spiral

Le cycle en cascade

Prototype 2

Spécifs

Evaluation

Prototype 1

Evaluation 2

Spécifs 2

16

Le cycle de vie Objet Dans un projet Objet, le cycle de vie répond à 3 caractéristiques essentielles :

• La traçabilité entre les étapes • Un cycle itératif • Un cycle incrémental

La traçabilité entre les étapes :

• Les concepts utilisés au cours des différentes étapes sont quasiment identiques

(Classes, Objets, Attributs, Méthodes, Héritage, Polymorphisme, ...). • Ce qui n’est pas le cas dans les approches traditionnelles, où l’on utilise une

méthode d’analyse et de conception avec des concepts et un langage de programmation avec d’autres concepts.

• Ceci permet de conserver le même discours lors de toutes les étapes : « Analyse - Conception - Implémentation ».

Un cycle itératif :

Spécifications techniques complètes du futur S.I. (vue info.) pour la réalisation

Spécifications fonctionnelles complètes futur S.I. (vue utilisateur)

Application informatique installéedans la nouvelle organisation

Etude préalable

Réalisation logicielle

Etude technique

Etude détaillée

Maintenance

Mise en service

Plan de développement à moyen terme des systèmes d’informations

Dossier de choix avec proposition et évaluation de n solutions

Schéma directeur

17

Un cycle incrémental :

• Lors du développement, une maquette doit être réalisée pour valider l’ergonomie

de l’application et l’enchaînement des écrans.

• Plusieurs versions peuvent être développées. Lors de chacune d’elle, chaque fonctionnalité est améliorée jusqu’à optimisation rendant ainsi le système progressivement robuste.

Expression des besoins

Spécifications fonctionnelles

Conception Analyse

Implémentation

Tests de vérification


18

CONCLUSION

Récapitulation et synthèse

Donner les différents cycles de vie?

Exercice d’évaluation 1) Définir les cycles de vie en ordre et en expliquant leur étapes ?

2) Donner les types des modèles de cycle de vie ? 3) Définir la déférence entre les modèles de cycle de vie ? 4) Le cycle de vie répond à 3 caractéristiques essentielles dans un projet, les quelles ? 5) Le processus de cycle en V s’accomplit en deux phases les quelles ?

20

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de la leçon : cas d’utilisation (use case)

Objectifs de la leçon : Le stagiaire doit être capable de : * Bien comprendre le cahier de charge * Définir les acteurs avec leurs intentions * comment rechercher les acteurs et leurs cas d’utilisation


21

Activités d’apprentissage

Rappel Diagramme de cas d’utilisation (DCU) Il est destiné à représenter les besoins des utilisateurs par rapport au système • Il s’agit de la solution UML pour représenter le modèle conceptuel • Les uses cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d’un système. • Ils identifient les utilisateurs du système (acteurs) et leur interaction avec le système Eléments de base : Acteur : entité externe qui agit sur le système (utilisateur, autre système) • Il possède un rôle par rapport au système • Il peut consulter ou modifier l’état d’un système

Un acteur est défini à travers son rôle Typologie des acteurs : primaire ou secondaire

Cas d’utilisation : ensemble des actions réalisées par le système en réponse à une action d’un acteur; • Moyen de recueillir et de décrire les besoins des acteurs du système; • Les uses cases peuvent être organisée en paquetages (packages). Transition Le chemin à suivre pour réaliser un diagramme de cas d’utilisation

1) Faire un tableau d’exigences 2) Diagramme des acteurs 3) Diagramme contexte dynamique 4) Diagramme contexte statique 5) Intentions d’acteurs 6) Et en fin Diagramme de uses case

22

Schèma des étapes à suivre

nom : effectuer un achat acteur principal : client acteur secondaire : caissier événement déclencheur : … rôle du use case : … terminaison du use case : …

Diagramme de uses cases

Use case haut niveau

Diagramme contexte statique

Processus de définition des besoins

Exigences Diagramme des acteurs

Diagramme contexte

Intentions d’acteurs

re

R

fonction

payer achat

… …

magasi

payer retourn

magasiest dans

0..*

ref fonctio intenti acteur

23


Les use cases (cas d’utilisation) sont un concept de la méthode OOSE de Ivar Jacobon.

Ils permettent d’effectuer une délimitation du système et de décrire son

comportement.

Ils constituent une représentation orientée “ fonctionnalités ” du

système.

Dans la modélisation par les use cases :

2 concepts fondamentaux interviennent :

Les acteurs : utilisateurs du système.

Les uses cases : utilisation du système

Ceux sont les utilisateurs du système

Tout système peut être décrit par un certain nombre de cas d’utilisation représentant les

besoins exprimés par l’ensemble d’utilisateur.

Exemple de représentation d’un système en cas d’utilisation La représentation d’un cas d’utilisation met en jour trois concepts.

L’acteur. Le cas d’utilisation. l’interaction entre l’acteur et le cas d’utilisation

1 système=n cas d’utilisation Acteur 1

Acteur2

Acteur 3

24

Stick-manClient

<<actor>> Client

- Recherche des Acteurs : Qu’est ce qu’un acteur

• Quelqu’un ou quelque chose • EXTERNE au système • qui interagit avec le

système Un acteur est une personne ou une chose qui va interagir avec le système

Il peut être : » soit un humain; » soit un logiciel ; » soit un automate.

On distingue :

• les acteurs primaires : ceux sont les utilisateurs du système ; • les acteurs secondaires : ceux qui administrent le système.

• Un acteur est défini à travers son rôle • Typologie des acteurs : primaire ou secondaire

Exemple 1 :

<< Acteur >> Client

Client

Application bancaireGuichetier

Responsable des

Directeur

Acteur secondaire

Acteurs primaires

25

- Recherche des Use Case :

Un cas d’utilisation est

• Séquence de transactions entre un acteur et le système • PAS un module du système * plutôt une fonctionnalité du système

• Un use case est une intention d'acteur. Quand un acteur démarre un use case, il a une

intention précise. Quelle est cette intention? Effectuer un achat est une intention qui recouvre un certain nombre d'exigences. C'est une unité d'intention complète d'un acteur: c'est donc un use case. Payer ses achats n'est pas une intention complète d'acteur. Nous n'allons pas dans un magasin pour payer, mais bien pour faire des achats. C'est donc une partie (et pas la plus agréable) de effectuer un achat. Ce n'est donc pas un use case.

Représentation générale de DCU

Exemple 1:

Exemple 2 :

Consulter compte

Client

Le système permet à l’acteurClient de consulter son compte

26

Exemple 3

L’intégration dans l’Use Case “ Application bancaire ” des use cases de chaque opération permet d’avoir une vision globale du système. Elle permet également de comprendre le rôle de chaque acteur.

Application bancaire (système)

Guichetier Responsable des devises

Directeur

Retrait euros Saisie cours

devise

Bilan

Emprunt

Retrait devises

27

Exemple 4

Relations entre cas d’utilisation Les cas d’utilisation peuvent être liés par des relations : - d’utilisation « include » (le cas origine contient obligatoirement l’autre) - de raffinement « extend » (le cas origine peut être ajouté optionnellement)

• Des fonctionnalités bien précises qui se retrouvent parmi plusieurs uses cases. Nous parlerons alors de use case included ou subalterne.

Relation d’utilisation : indique que le cas d’utilisation Source contient aussi le comportement décrit dans le cas d’utilisation destination. En d’autres termes, pour réaliser l’objectif « Imprimer solde compte », on utilise les objectifs « Consulter compte » et « imprimer un ticket » du système

Effectuer un achat

Salarié

Se connecter

Client

Retourner un article

Caissier

Gérer le catalogue

Initialiser la caisseManager

Editer un rapport

administrateurDéfinir les profils

les flêches unidirectionnelles indiquent un lien principal, c'est à dire l'acteur principal du use case.

28

Un tel use case ne peut être lié qu'à un use case, pas à un acteur. (Nous mettrons alors le stéréotype include sur le lien use case vers use case subalterne).

Exemple

Relation d’extension Un use case peut nécessiter le service d'un autre use case. Le use case dont nous avons besoin du service étend le use case demandeur. Nous utiliserons le stéréotype extend. Ici les uses cases peuvent être sollicités par des acteurs.

exemple de use case subalterne pour un guichet automatique de banque

avoir solde retrait

authentification

<<include>><<include>>

29

Donc la relation extend dit que : Un ou plusieurs use cases peuvent hériter des caractéristiques d’un autre use case.

Les Uses Cases fils ont les mêmes liens avec les acteurs et les autres use cases que le use case dont ils héritent. Ceux sont de cas particuliers du Uses Case père. Exemple :

Exemple (distributeur des boissons)

exemple de use case étendu pour un système de gestion de commande. Quand nous rentrons une commande, il faut pouvoir créer le client s 'il n'existe pas.

gestion clientgestion commande

<<extend>>

Retrait devises

Retrait francs

Retrait

“Extends”

“Extends”

SystèmGuichetie

30

Relation d’extension : indique que le cas d’utilisation source étend (Précise) les objectifs (le comportement) du cas d’utilisation destination. La relation “uses” Soit l’use case “Saisie n° compte”

• Le guichetier saisit le code de la banque du compte. • Il saisit le numéro du compte. • Il saisit la clé du compte. • Le système calcule la clé du compte et vérifie qu’elle est bonne. • Le système interroge le compte sur le système central. • Le système affiche le compte ainsi que son détenteur.

Lorsque une ou plusieurs tâches sont utilisées régulièrement, on peut les factoriser dans un même use case et faire de telle sorte que d’autres use cases l’utilisent en le pointant par une flèche. Cet use case est en fait une sous partie de chaque use case qui l’utilise. Ce qui permet de décomposer un use case complexe en plusieurs uses cases.

Application bancaire (système)

Retrait Retrait devises

“uses”

Saisie n° compte

“uses”

Emprunt

“uses”

Usager

Boisson

monnaie

CocaServir Boisson

extendsextends

uses

uses

31

Use case description bat niveau : C’est ou en défini :

• nom : • acteur principal : • acteur secondaire : • événement déclencheur : • rôle du use case : • terminaison du use case :

Use case description haut niveau : C’est ou en défini :

• nom : • acteur principal : • acteur secondaire : • événement déclencheur : • rôle du use case : • terminaison du use case : • références croisées : • pré conditions : • scénarios et alternatives :

32

CONCLUSION


1) Donner la définition d’un acteur et de use case ? 2) Quel est le type du diagramme suivant :

♀ Guichetier Interroger compte

Exercice d’évaluation EXERCICE 1

On considère un système simplifié de Guichet Automatique de Banque (G.A.B.). Le GAB offre les services suivants:

1. Distribution d'argent à tout porteur de carte de crédit (carte Visa, ou de la banque), via un lecteur de carte et un distributeur de billets.

2. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients de la banque porteurs d'une carte de crédit de la banque.

Par ailleurs:

• Toutes les transactions sont sécurisées, via:

Le Système d'Autorisation Visa, pour les retraits effectués avec une carte Visa;

QUESTIONS Elaborez un Diagramme de Cas d'Utilisation détaillé du GAB EXERCICE 2

Cet exercice traite d'un système simplifié de caisse enregistreuse de supermarché. Le déroulement normal d'utilisation de la caisse est le suivant:

• Un client arrive à la caisse avec des articles à payer. • Le caissier enregistre le n° d'identification de chaque article, ainsi que la quantité si

elle est supérieure à 1. • La caisse affiche le prix de chaque article et son libellé. • Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente.

33

• La caisse affiche le total des achats. • Le client choisit son mode de paiement.

1. Liquide: le caissier encaisse l'argent reçu, la caisse indique la monnaie à rendre au client.

2. Chèque: le caissier vérifie la solvabilité du client en transmettant une requête à un centre d'autorisation via la caisse.

3. Carte de crédit: un terminal bancaire fait partie de la caisse. Il transmet une demande d'autorisation en fonction du type de la carte.

• La caisse enregistre la vente et imprime un ticket. • Le caissier donne le ticket de caisse au client.

Lorsque le paiement est terminé, la caisse transmet les informations sur le nombre d'articles vendus au système de gestion des stocks.

Tous les matins, le responsable du magasin initialise les caisses pour la journée.

QUESTIONS

1. Elaborez un Diagramme de Cas d'Utilisation détaillé de la Caisse enregistreuse. N'hésitez pas à utiliser les relations entre cas d'utilisation pour rendre le diagramme plus précis.

Exercice 2

Voila des cas d’utilisations d’un système de messagerie faire les liens entre les acteur et ces cas d’utilisation

Les acteurs

Personne A (un utilisateur du public) Administrateur

Les cas d’utilisations

Connexion Lecteur de boite Envoi d’un message Changement de boite

35

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de la leçon : Objet, classe et association

Objectifs de la leçon : Le stagiaire doit être capable de

• Différencier entre un objet et une classe • Reconnaître les différents types de relations • Reconnaître les multicipités • Rappeler l’héritage…etc.


36

INTRODUCTION Rappel - Rappel sur les modèles de merise - Rappel sur la façon pour trouvez les entités - Rappel sur les différentes relations ainsi que les cardinalités


Diagramme de classe d’analyse Le diagramme de classes est un des documents les plus importants, voire le plus important de l'analyse d'un logiciel par une méthode objet. C'est le premier document qui est dans le monde des objets (les acteurs n'étant pas forcément représentés dans le système informatique). C'est donc l'entrée dans le monde des objets. Ce diagramme est un diagramme de classe d'analyse. Il ne représente pas les classes Java ou C++ que nous développerons par la suite. Ici nous nous intéressons aux classes du domaine métier, c'est à dire des objets dont on parle dans le cahier des charges et dans les uses cases principalement. Nous ne nous intéressons pas aux objets informatiques dans ce diagramme (sauf bien entendu si le métier est l'informatique !!). Cela viendra en son temps, dans le diagramme de classe de conception. Quand nous passerons à la conception des classes disparaîtront, d'autres apparaîtront, dont les classes informatiques (collections, …). C'est normal. En phase d'analyse, nous voulons simplement faire un diagramme de classe d'objets manipulés dans le domaine métier considéré. Dans ce diagramme de classe les opérations ne sont pas représentées (ce sera lors de la conception). Ce diagramme montrera les concepts du domaine métier, les liens (associations) entre ces concepts (avec leur cardinalité ou multiplicité), et les attributs de ces concepts ( souvent sous forme de données simples ). Le but de ce diagramme est de clarifier le domaine métier du client, et de se familiariser avec ce domaine. Dans une analyse structurée nous décomposons l'analyse suivant les tâches ou les fonctions. Dans une application à dominante gestion, nous décomposerons notre application suivant les données, et les traitements. Ici nous analyserons la complexité du domaine en regardant les objets métier et leurs interactions entre eux.

Partie -I- -Notion d’objet : Un objet est défini à la fois par des informations : données ou attributs ou variables

d’instances.

37

Comportements : traitements ou méthodes ou opérations.

Exemple :

Partie -II-

-Notion de classe :

Lorsque des objets ont les mêmes attributs et comportements : ils sont regroupés dans une famille appelée : Classe. Les objets appartenant à celle-ci sont les instances de cette classe. L’instanciation est la création d’un objet d’une classe.

Deux instances d’une même classe peuvent avoir des attributs avec des valeurs différentes et mais partagent les mêmes méthodes.

Partie -III-

Les relations :

L’association représente une relation entre plusieurs classes. Elle correspond à l’abstraction des liens qui existent les objets dans le monde réel.

Client Produit Achète

38

Agrégation est une forme particulière d’association entre plusieurs classes. Elle

exprime le fait qu’une classe est composée d’une ou plusieurs autres classes.

La composition est une relation d’agrégation dans laquelle il existe une contrainte de durée de vie entre la classe ‘composant’ et la ou les ‘composé’. Autrement dit la suppression de la classe ‘composé’ implique la suppression de la des classes ‘composant’.

Exemple :

Généralisation de classe consiste à factoriser dans une classe, appelée superclasse, les

attributs et/ou opérations des classes considérées. Exemple 1:

La spécialisation représente la démarche inverse de la généralisation puisqu’elle consiste à créer à partir d’une classe, plusieurs classes spécialisées.

Exemple 2:

Classe A

Sous-Classe A1

Sous-Classe A2

Généralisation

Classe A

Sous-Classe A1

Sous-Classe A2

Spécialisation

Bouteille Vin

Commande

LigneDeCommande

39

L’encapsulation : les données ne sont accessibles qu’à partir des opérations définies

dans la classe. Le principe d’encapsulation renforce l’autonomie et l’indépendance de chaque classe et donne une forte potentialité de définition de classe réutilisable.

Exemple 3: Accès aux données via l’interface (Partie visible de La classe)

Le polymorphisme : est la capacité donnée à une opération de s’exécuter différemment suivant le contexte de la classe où elle se trouve.

La persistance est la propriété donnée à un objet de continuer à exister après la fin de

l’exécution du programme qui l’a créé. Par défaut dans l’approche objet, aucun objet n’est persistant. Les modèles décrivent le système en exécution en mémoire centrale et ne tiennent pas compte a priori de l’état du système qui doit être stocké sur disque. L’héritage est un mécanisme qui permet d’assurer une grande variabilité dans la

réutilisation des objets. Il existe deux techniques liées à l’héritage : les classes abstraites et l’héritage multiple.

Exemple 4:

Passager poids:reel donnerPoids():reel

Conducteur bouge(dir,vit):void

Voiture

Super-classe

Sous-classe

Classe x Traitements Liste des attributs

I N T E R F A C E

Données : Liste des attributs

40

Exemple d’héritage multiple : La classe C50 hérite des classes C1, C2 et C3. Partie -IV- Comment identifier les bons objets métier pour construire notre diagramme de classe

d'analyse?

Il va falloir recenser dans les documents de définition des besoins et dans les documents d'analyse l'ensemble des objets métier. Les noms ou groupes nominaux vont être de bons candidats pour être élus au titre de classe, objet ou attribut. Cependant, il faut être prudent car il y aura aussi un certain nombre de faux amis et de doublons.

41

Voici une démarche de sélection des classes candidates: Par use case, nous réaliserons un diagramme de classe, le diagramme final étant la superposition de tous ces diagrammes. Pour un use case nous recenserons les groupes nominaux rencontrés. Nous identifierons alors: • Les classes (noms communs). • Les objets (noms propres ou nom référencés). • Les attributs (données simples qui qualifient une classe ou un objet). • Les éléments qui sont étrangers à notre problème ou qui n'y ont pas de rôle réel. • Les " classes fonctionnelles " qui ne sont porteuses d'aucune information, mais seulement

de traitement, qui ne sont souvent pas des classes de notre diagramme. Par exemple gestionnaire du planning, décodeur de message, …

• Il est parfois difficile de savoir si une information est un attribut d'une classe ou une classe (avec une association avec la classe). Dans le doute il vaut mieux faire une classe, quitte à revenir en arrière dans une itération ultérieure. Par exemple pour la classe personne l'âge est un attribut (donnée simple) l'adresse étant à priori une donnée complexe sera plutôt une autre classe associée à la personne. • Les entités suivantes peuvent prétendre à devenir des classes :

- les objets physiques (produit…), - les transactions (réservation, commande,….), - les lignes de transaction (ligne de commande…), - les conteneurs (catalogues, lots,…), - les organisations (services, départements,….), - les acteurs ou les rôles (client, fournisseur….), - les regroupements en abstraction (modèle, genre, type, catégorie….), - les évènements (vol,…)

Pour le use case " effectuer un achat " voici la liste des classes sélectionnées:

caissier

vente

caissecatalogue

article

ligne de vente

Paiement

ticket

42

Nous ne gèrerons pas les exemplaires des articles. Nous appèlerons article un ensemble d’exemplaires identifiés par le même code barre, et comportant des informations identiques (prix …).

Nous allons maintenant rajouter les associations entre les classes, en donnant un intitulé et des cardinalités à ces associations.

Notre but n'est pas de mettre à jour toutes les associations entre les différentes classes, mais de noter les associations pertinentes pour comprendre le problème. Il faut privilégier les associations qui durent dans le temps, et dont la connaissance est nécessaire à la compréhension du problème. Il faut éviter les associations redondantes ou dérivables d'autres associations. L'établissement de ces associations nous amène à poser des questions au client. C'est un des buts recherchés. Voici une possibilité de diagramme de classe avec ses associations.

Sur ce diagramme de classe d'analyse il faut maintenant mettre les attributs des classes qui ont été repérés dans le cahier des charges, le diagramme de use case, ou dans le diagramme de séquence boîte noire du use case.

caissier

0..1

0..1

caisse0..1

0..1

utilise

0..1

1..*

Paiement 1

1

ticket1

1

0..*

ligne de vente

1

0..*1

1

1

vente

1

0..1effectue

1..*

1

comprend

1

1payée par

1

1génère

catalogue

11

1

se fait à partir

1

1

article

1

0..*

est décrite par

0..*

contient

43

caissier

0..1

0..1

caisse0..1

0..1

utilise

0..1

1..*

Paiement somme : réel 1

1

ticket1

1

0..*

ligne de ventequantité : entier

1

0..*1

1

1

Ventedate : Dateheure : Heure

1

0..1effectue

1...*

1

comprend

1

1payée par

1

1génère

catalogue

1 1

1

se fait à partir

1

1

description article description : text prix : réel code : codebarre

1

0..*est décrite par

0..*

contient

le prix ou la somme devraient se donner par rapport à une monnaie...

A priori, les attributs présents dans notre diagramme de classe d'analyse sont des attributs simples. On pourra faire exception des données pures qui sont des regroupements de données simples ( ici code, adresse, prix ) . Les attributs qui ont un comportement sont des classes associées à notre classe. Ceci ne présage en rien du diagramme de classe de conception. Nous verrons ultérieurement ce que deviennent les associations dans ce schéma… Dans les attributs, il ne doit pas y avoir de clef sur un autre objet. Cela se représente par une association. Voici notre diagramme de classe enrichi des attributs d'analyse.

44

CONCLUSION

Récapitulation et synthèse Donner les différents types de relation avec des exemples ? En UML une composition est : * une opération entre trois classes * une association d’héritage entre deux classes * une association qui indique qu’une classe en contient une autre * un attribut composé de plusieurs attributs 3) En UML, quelle est l’expression vraie exprimée par le diagramme suivant :

Client

Compte

1..1 0..*

4) En UML quelle est la signification d’une généralisation : * relation d’inclusion entre 2 classes * génération d’une opération conceptuelle * relation de dépendance hiérarchique entre deux classes * n’existe pas en UML. Exercice «classification »

Classer les relations suivantes en généralisation, instanciation, agrégation, lien ou association. Argumenter les réponses. (a) Un pays possède une capitale. (b) Un philosophe qui dîne utilise une fourchette. (c) Un joueur de rugby est un avant, un demi ou un arrière. (d) Une équipe de rugby est composée de 8 avants, 2 demis et 5 arrières. (e) Dédé programme son simulateur de vol en Java sur son PC. (f) Java, C++ et Eiffel sont des langages orientés objet. (g) La Tour Eiffel a 3 étages et 3 millions de boulons. (h) L'agrégation est un examen. Exercice Dessiner les diagrammes (d’objets, de classes) correspondant aux situations suivantes : (a) La France est frontalière de l’Espagne. Le Canada est frontalier des Etats-Unis. (b) Un polygone est constitué de points. Un point possède une abscisse et une ordonnée. (c) Une médiathèque possède des médias, empruntables par les abonnés de la médiathèque. (d) Un client demande une réparation. Une réparation est effectuée par un mécanicien. Elle nécessite des compétences. Un mécanicien possède des compétences. (e) Une galerie expose des oeuvres, faites par des créateurs, et représentant des thèmes. Des clients, accueillis par la galerie, achètent des oeuvres. Dessiner les diagrammes (d’objets, de classes, de généralisation) correspondant à la situation

45

suivante : (f) Un bateau contient des cabines, occupées par des personnes qui effectuent des activités. Les personnes sont ou bien des guides, ou bien des animateurs, ou bien des passagers. Les guides expliquent des visites aux passagers et les animateurs animent des animations pour les passagers. Exercice « JARDINIER » Un jardinier effectue deux types de travaux : l’arrosage et le piochage. L’arrosage consiste à arroser des plantes (tulipes, eucalyptus ou géraniums) avec un outil (arrosoir ou tuyau) contenant de l’eau et le piochage consiste à retourner la terre avec un outil (pioche ou pelle) pour y mettre de l’engrais. Autrement dit, le jardinier utilise un outil (arrosoir, tuyau, pelle ou pioche) pour mettre une ressource (eau ou engrais) sur un objet naturel (terre ou plante) ; celuici est produit par un travail (arrosage ou piochage). 1) Dessiner le diagramme de généralisation des classes. On généralisera les classes du domaine avec une classe « Objet ». 2) Dessiner un diagramme d’objets correspondant au texte suivant : Jacques est un jardinier qui arrose 3 géraniums avec un arrosoir rempli d’eau. Jules est un jardinier qui pioche la terre avec une pelle pour y mettre de l’engrais. 3) Dessiner un premier diagramme de classes avec les classes Jardinier, Arrosage, Arrosoir, Eau, Geranium. Puis dessiner un autre diagramme de classes similaire au premier mais avec des classes plus générales : Jardinier, Travail, Outil, Ressource, ObjetNaturel. 4) Quelle difficulté posent les classe Eau, Terre, Engrais ? 5) Placer les ordres de multiplicité sur les 2 diagrammes de classes précédents. Quelle Remarque peut-on faire ? Exercice : Dessiner les diagrammes (d’objets, de classes) correspondant aux situations suivantes : (a) La France est frontalière de l’Espagne. Le Canada est frontalier des Etats-Unis. (b) Un polygone est constitué de points. Un point possède une abscisse et une ordonnée. (c) Une médiathèque possède des médias, empruntables par les abonnés de la médiathèque. (d) Un client demande une réparation. Une réparation est effectuée par un mécanicien. Elle nécessite des compétences. Un mécanicien possède des compétences. (e) Une galerie expose des oeuvres, faites par des créateurs, et représentant des thèmes. Des clients, accueillis par la galerie, achètent des oeuvres. Dessiner les diagrammes (d’objets, de classes, de généralisation) correspondant à la situation suivante : (f) Un bateau contient des cabines, occupées par des personnes qui effectuent des activités. Les personnes sont ou bien des guides, ou bien des animateurs, ou bien des passagers. Les guides expliquent des visites aux passagers et les animateurs animent des animations pour les passagers.

47

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de la leçon : notion des classes Objectifs de la leçon : Le stagiaire doit être capable de

• Fournir un premier contact avec la modélisation desdonnées en montrant la difficulté et l'importance decette activité.

• Montrer la différence entre modèle du domaine etmodèle du problème.

• Montrer comment faire la liaison entre le dictionnaireet les modèle du domaine / du problème.

• Montrer la relation entre les cas d'utilisation et lamodélisation des données pour souligner une certainecontinuité et éviter que les diagrammes de casd'utilisation soit élaborés mais aussitôt abandonnés.

• Simplicité • Facilité pour coder et réutiliser • Modèle plus proche de la réalité

– description plus précise des combinaisons (Données, opérations)

– décomposition basée sur “classification naturelle” f il à d t à i t i


48

INTRODUCTION

Activités d’apprentissage Rappel Une classe Ensemble d’objets ayant : - des propriétés (attributs) similaires - un comportement (opérations) commun - des relations communes avec d’autres objets - des sémantiques communes (domaines de Définitions) Donc : une classe décrit un groupe d’objet ayant les mêmes propriétés, un même

comportement et une sémantique commune.

Une classe se représente à l’aide d’un rectangle comportant les trois compartiments.

La désignation de la classe

La description des attributs

La description des opérations

Un modèle de domaine : fait référence à des connotatives métier Ce dernier ce trouve dans le dictionnaire de données (il à une forme d’un tableau qui peut contient les colonnes suivants : nom d’attribut ; signification ; type –N, A, AN- ; longueur ; nature –E, CO, CA /M, SIG, SITU- ; règle de calcule ou d’intégrité) Modèle de problème : il est variable selon l’application demandée il étude les problèmes à résoudre Un objet est une instance d’une classe, est caractérisé par des attributs, des méthodes, et l’identité Transition

Pour que le stagiaire soit capable de réaliser des classe il faut qu’il défini premièrement le modèle de domaine et le modèle de problème pour pouvoir étudier les problèmes à

résoudre et en fin extraire les classes et leurs attributs et méthodes

Nom de la calasse Attributs

Opération

49


Activités d’apprentissage Partie1 Identification des classes et des attributs : (1) Explication : sur la différence entre modèle du domaine et modèle du problème • Modèle du domaine. Stable. Indépendant d'une l'application particulière. Peut être partagé entre entreprises, fait référence à des connaissances métiers et se retrouve dans le dictionnaire. • Modèle du problème : instable. Dépend de l'application à réaliser. Fortement lié au diagramme de cas d'utilisation et du problème à résoudre. En réalité, la séparation n'est pas si simple à obtenir. Du moment que l'on modélise de manière un peu détaillée, on se concentre déjà sur le modèle du problème en choisissant par exemple de représenter une information sous la forme d'un attribut plutôt que d'une classe par exemple, car l'on sait que peu d'information sont nécessaires dans le problème auquel on s'intéresse. Pour le déroulement de la séance, on peut commencer en partant du dictionnaire et/ou du texte et essayer de voir pour chaque élément quels sont leur modélisation en UML en s'attachant aux classes et aux attributs A ce stade les différents concepts UML vus sont les suivants • acteur • cas d'utilisation • classe • attribut • association • opération Il s'agit donc pour chaque terme dans le dictionnaire de déterminer la catégorie correspondante. Différentes alternatives de modélisation sont possibles. Par exemple on peut représenter la Ville comme un attribut ou comme une classe en fonction du niveau de détail que l'on souhaite modéliser. On peut représenter Inscription comme une classe ou une association. On choisira la modélisation exacte par la suite en faisant un diagramme de classe.

50

Représentation graphique d'une classe :

Le premier compartiment contient le nom de la classe, le second les attributs et le dernier les opérations. Les compartiments peuvent être supprimés pour alléger les diagrammes. Par défaut, les attributs sont cachés et les opérations sont visibles.

Exemple 2 Exemple 3 Attributs de la classe

• est une propriété élémentaire d’une classe; • prend une valeur pour chaque objet d’une classe

Les noms d’attributs d’une classe sont uniques Le type de l’attribut (entier, texte…) dépendant des types

disponibles dans le langage d’implémentation Un attribut dont la valeur peut être calculée à partir d’autres

attributs de la classe est un attribut dérivé qui se note « / Nom de l’attribut dérivé » Attributs

Compte

Le nom de la classe

CompteNuméro : String Solde : Float

Les attributs

Nom de la classe Attributs Opérations

51

Un attribut est une valeur de donnée détenue par les objets d'une classe. Chaque nom d'attribut est unique à l'intérieur d'une classe (par opposition au fait d'être unique parmi toutes les classes). Ainsi la classe Personne et la classe Société peuvent avoir chacune un attribut adresse. Syntaxe complète : visibilité nom : type = valeur -initiale Seul le nom est obligatoire en analyse. Visibilité : marqueur optionnel utilisé en conception

+ Public # protégé

- privé Type : type d'un langage de programmation en conception détaillée. Valeur -initiale : servira à donner la valeur initiale d'un attribut à la création d'un nouvel objet. Exemple 4 : Opérations de la classe - Est une fonction applicable aux objets d’une classe; - Permet de décrire le comportement d’un objet * Une méthode est l’implémentation d’une opération

Opérations Une opération est un service que l'on peut demander à un objet pour réaliser un comportement. Tous les objets d'une classe partagent les mêmes opérations. En analyse, on parle plutôt d’opération. En conception, on parle plutôt de méthode. Une méthode est l'algorithme ou la procédure qui produit le résultat de l'opération. Syntaxe complète : visibilité nom (liste -paramètres) : type -retour Seul le nom est obligatoire en analyse. Visibilité : marqueur optionnel utilisé en conception + Public # protégé

- privé Liste -paramètres : liste de paramètres formels, chacun étant spécifié comme suit : Nom : type = valeur -défaut

Compte

public class Compte { String numero; Float solde; void debiter() {} void crediter() {} Float getSolde() {} }

numero : String solde : Float

debiter () : void crediter () : void getSolde () : Float

Les méthodes

52

Type -retour : optionnel si l'opération ne retourne pas de résultat (void du C++).

Fenêtre Objet géométrique

+ afficher ( ) : Position + déplacer (delta: Vecteur) + cacher ( ) + sélectionner (p: Point) : Booléen + tourner (angle) Exemple 2

Exemple 3

numero : String solde : Float

debiter () : void crediter () : void getSolde () : Float

Voitur

type : string marque : stringcouleur : string repeindre(c: Couleur) déplacer(d : Méthode

Nom de la classe

Attributs

opérations

Des attributs complémentaires peuvent être nécessaires

Compte

53

Exemple 4

Propriétés des attributs et des opérations - Accessibilité aux attributs et opérations d’une classe Trois niveaux de protection : • Public (+) : accès à partir de toute entité interne ou externe à la classe • Protégé (#) : accès à partir de la classe ou des sous-classes • Privé (-) : accès à partir des opérations de la classe

Compte

- numero : String - solde : Float

+ debiter (montant : Float) : void + crediter (montant : Float) : void + getSolde () : Float - modifierSolde (montant : Float) : void# calculerNouveauNumero () : String

public class Compte { private String numero; private Float solde; public void debiter() {} public void crediter() {} public Float getSolde() {} static protected calculerNouveauNumero() {} }

54

Synthèse

Association entre classes

• représente les liens qui existent entre les instances de ces classes.

• Chaque association peut être identifié par son nom

Multiplicité des associations - est une information portée par le rôle, qui quantifie le nombre de fois où un objet participe à une instance de relation.

- adresse : String = 'adresse inconnue' - numeroINSEE[6] : Integer

# changeAdresse(nouvelleAdresse : String)+ cotisationAJour() : Boolean

Adhérent

note (peut contenir un complément de description, un

commentaire, …)

type d'attribut

valeur initiale

type de paramètre

privé

public

adhérent de la bibliothèque

55

Agrégation entre classes

• est une association qui permet de représenter un lien de type « ensemble » comprenant des « éléments »

• est une association non symétrique : L’une des extrémités joue un rôle prédominant par rapport à l’autre

Agrégation particulière : Composition

• est une relation d’agrégation dans laquelle il existe une contrainte de durée de vie entre la classe « composant » et la ou les classes « Composé »

• La suppression de la classe composé implique la suppression de la ou des classes composant.

• La valeur maximale de multiplicité du côté du conteneur ne doit pas excéder 1 puisque les objets, instances de la classe des composants, doivent tous appartenir au même objet conteneur.

56

Généralisation, Spécialisation et héritage simple

• La généralisation consiste à créer une « superclasse » à partir de classes

• La spécialisation consiste à créer des « sous-classes » à partir d’une classe

• Les attributs et opérations d’une superclasse sont transmis aux sous-classes par héritage

• Sous-classes = instances d’une seule classe (héritage simple)

• La généralisation facilite la modélisation en regroupant ce qui commun aux classes de ce qui ne l’est pas.

57

Exemple 2

Héritage multiple - consiste à hériter une même classe de deux classes « Parentes » distinctes

Véhicule Véhicule

Auto Véhicule Batea

Véhicule

58

CONCLUSION Récapitulation et synthèse

1) Donner les étapes nécessaires pour définir les classes avec les attributs? 2) En conception technique, comment implémente t-on les associations entre des classes du

diagramme de classe : Par exemple :

• On créé une nouvelle classe pour traduire l’association posséder • On crée une méthode dans l’une des deux classes concernées Client ou Compte • Ce n’est pas nécessaire, le diagramme de classes suffit • on crée un attribut dans une des classes qui référencera un objet de ’autre classe

Exercice d’évaluation Un ordinateur et composé de plusieurs périphériques ; donner un diagramme de classe que montre un archetière d’un ordinateur en spécifiant le type d’association entre les classes Exercices Exercice « TRIATHLON » Un triathlète utilise trois types de moyens de déplacement : la nage, le cyclisme et la course à pied. La nage consiste à nager une distance courte avec un maillot de bain dans un liquide (lac ou mer). Le cyclisme consiste à pédaler sur une distance longue avec un vélo sur une route. La course a pied consiste à courir une distance moyenne avec des chaussures sur une route. Autrement dit, le triathlète possède des équipements (vélo, maillot ou chaussure) pour effectuer une distance (courte distance, moyenne distance ou longue distance) sur un site (liquide ou Route) en utilisant un moyen de déplacement (nage, cyclisme ou course à pied). 1) Dessiner le diagramme de généralisation des classes. On généralisera les classes du domaine avec une classe « Objet » . 2) Dessiner un diagramme d’objets correspondant au texte suivant : Thierry est un triathlète qui court à pied une moyenne distance sur la route Départementale 3 avec ses chaussures. Timothée est un triathlète qui nage une courte distance dans la mer méditerranée avec un maillot de bain. 3) Dessiner un premier diagramme de classes avec les classes Triathlète, Nage, Maillot, Mer, CourteDistance. Puis dessiner un autre diagramme de classes similaire au premier mais avec des classes plus générales : Triathlète, MoyenDeplacement, Equipement, Site, Distance. 4) Placer les ordres de multiplicité sur les 2 diagrammes de classes précédents. Quelle remarque peut-on faire ? UML Exercices de base

Compte

Client

59

Exercice « EXPRESSION » Soit l’expression suivante : (X+Y/2)/(X/3+Y) 1) Identifier des classes pertinentes correspondant à cette expression. 2) Faire un diagramme de généralisation. 3) Faire un diagramme de classes. 4) Préparer le diagramme d’objets correspondant à l’expression. Exercice « classification » Classer les relations suivantes en généralisation, instanciation, agrégation, lien ou association. Argumenter les réponses. (a) Un pays possède une capitale. (b) Un philosophe qui dîne utilise une fourchette. (c) Un joueur de rugby est un avant, un demi ou un arrière. (d) Une équipe de rugby est composée de 8 avants, 2 demis et 5 arrières. (e) Dédé programme son simulateur de vol en Java sur son PC. (f) Java, C++, Eiffel sont des langages orientés objet. (g) La Tour Eiffel a 3 étages et 3 millions de boulons. (h) L'agrégation est un examen. Exercice « brain-storming » Préparer un diagramme d’objets montrant au moins 10 relations parmi les classes d’objets suivantes. Inclure les associations les agrégations et les généralisations. Placer les ordre de multiplicité. (a) école, terrain de jeu, proviseur, conseil de classe, salle de classe, livre, élève, professeur, cafétéria, ordinateur, bureau, chaise, porte. (b) château, douve, pont-levis, tour, fantôme, escalier, donjon, plancher, couloir, salle, fenêtre, Pierre, seigneur, dame, cuisinier. (c) Automobile, roue, frein, moteur, porte, batterie, silencieux, pot d’échappement. Exercice « attributs méthodes de classe ou d’instance » Pour chaque propriété des classes UML suivantes, nous avons volontairement omis de la souligner quand cela était nécessaire. En vous aidant du nom de la propriété et de sa signification, indiquer si la propriété est "d'instance" ou bien "de classe". Château muraille : Muraille ; listeTours : Liste ; listeChateaux : Liste ; void imprimerMuraille() ; Objet nombreObjets : int ; mesObjets : Liste ; numéro : int ;

61

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de la leçon : Objet, classe et association


• Différencier entre un objet et une classe • Reconnaître les différents types de relations • Reconnaître les multicipités • Rappeler l’héritage…etc.


62

INTRODUCTION Rappel - Rappel sur les modèles de merise - Rappel sur la façon pour trouvez les entités - Rappel sur les différentes relations ainsi que les cardinalités


Diagramme de classe d’analyse Le diagramme de classes est un des documents les plus importants, voire le plus important de l'analyse d'un logiciel par une méthode objet. C'est le premier document qui est dans le monde des objets (les acteurs n'étant pas forcément représentés dans le système informatique). C'est donc l'entrée dans le monde des objets. Ce diagramme est un diagramme de classe d'analyse. Il ne représente pas les classes Java ou C++ que nous développerons par la suite. Ici nous nous intéressons aux classes du domaine métier, c'est à dire des objets dont on parle dans le cahier des charges et dans les uses cases principalement. Nous ne nous intéressons pas aux objets informatiques dans ce diagramme (sauf bien entendu si le métier est l'informatique !!). Cela viendra en son temps, dans le diagramme de classe de conception. Quand nous passerons à la conception des classes disparaîtront, d'autres apparaîtront, dont les classes informatiques (collections, …). C'est normal. En phase d'analyse, nous voulons simplement faire un diagramme de classe d'objets manipulés dans le domaine métier considéré. Dans ce diagramme de classe les opérations ne sont pas représentées (ce sera lors de la conception). Ce diagramme montrera les concepts du domaine métier, les liens (associations) entre ces concepts (avec leur cardinalité ou multiplicité), et les attributs de ces concepts ( souvent sous forme de données simples ). Le but de ce diagramme est de clarifier le domaine métier du client, et de se familiariser avec ce domaine. Dans une analyse structurée nous décomposons l'analyse suivant les tâches ou les fonctions. Dans une application à dominante gestion, nous décomposerons notre application suivant les données, et les traitements. Ici nous analyserons la complexité du domaine en regardant les objets métier et leurs interactions entre eux.

Partie -I- -Notion d’objet : Un objet est défini à la fois par des informations : données ou attributs ou variables

d’instances.

63

Comportements : traitements ou méthodes ou opérations.

Exemple :

Partie -II-

-Notion de classe :

Lorsque des objets ont les mêmes attributs et comportements : ils sont regroupés dans une famille appelée : Classe. Les objets appartenant à celle-ci sont les instances de cette classe. L’instanciation est la création d’un objet d’une classe.

Deux instances d’une même classe peuvent avoir des attributs avec des valeurs différentes et mais partagent les mêmes méthodes.

Partie -III-

Les relations :

L’association représente une relation entre plusieurs classes. Elle correspond à l’abstraction des liens qui existent les objets dans le monde réel.

Client Produit Achète

64

Agrégation est une forme particulière d’association entre plusieurs classes. Elle

exprime le fait qu’une classe est composée d’une ou plusieurs autres classes.

La composition est une relation d’agrégation dans laquelle il existe une contrainte de durée de vie entre la classe ‘composant’ et la ou les ‘composé’. Autrement dit la suppression de la classe ‘composé’ implique la suppression de la des classes ‘composant’.

Exemple :

Généralisation de classe consiste à factoriser dans une classe, appelée superclasse, les

attributs et/ou opérations des classes considérées. Exemple 1:

La spécialisation représente la démarche inverse de la généralisation puisqu’elle consiste à créer à partir d’une classe, plusieurs classes spécialisées.

Exemple 2:

Classe A

Sous-Classe A1

Sous-Classe A2

Généralisation

Classe A

Sous-Classe A1

Sous-Classe A2

Spécialisation

Bouteille Vin

Commande

LigneDeCommande

65

L’encapsulation : les données ne sont accessibles qu’à partir des opérations définies

dans la classe. Le principe d’encapsulation renforce l’autonomie et l’indépendance de chaque classe et donne une forte potentialité de définition de classe réutilisable.

Exemple 3: Accès aux données via l’interface (Partie visible de La classe)

Le polymorphisme : est la capacité donnée à une opération de s’exécuter différemment suivant le contexte de la classe où elle se trouve.

La persistance est la propriété donnée à un objet de continuer à exister après la fin de

l’exécution du programme qui l’a créé. Par défaut dans l’approche objet, aucun objet n’est persistant. Les modèles décrivent le système en exécution en mémoire centrale et ne tiennent pas compte a priori de l’état du système qui doit être stocké sur disque. L’héritage est un mécanisme qui permet d’assurer une grande variabilité dans la

réutilisation des objets. Il existe deux techniques liées à l’héritage : les classes abstraites et l’héritage multiple.

Exemple 4:

Passager poids:reel donnerPoids():reel

Conducteur bouge(dir,vit):void

Voiture

Super-classe

Sous-classe

Classe x Traitements Liste des attributs

I N T E R F A C E

Données : Liste des attributs

66

Exemple d’héritage multiple : La classe C50 hérite des classes C1, C2 et C3. Partie -IV- Comment identifier les bons objets métier pour construire notre diagramme de classe

d'analyse?

Il va falloir recenser dans les documents de définition des besoins et dans les documents d'analyse l'ensemble des objets métier. Les noms ou groupes nominaux vont être de bons candidats pour être élus au titre de classe, objet ou attribut. Cependant, il faut être prudent car il y aura aussi un certain nombre de faux amis et de doublons.

67

Voici une démarche de sélection des classes candidates: Par use case, nous réaliserons un diagramme de classe, le diagramme final étant la superposition de tous ces diagrammes. Pour un use case nous recenserons les groupes nominaux rencontrés. Nous identifierons alors: • Les classes (noms communs). • Les objets (noms propres ou nom référencés). • Les attributs (données simples qui qualifient une classe ou un objet). • Les éléments qui sont étrangers à notre problème ou qui n'y ont pas de rôle réel. • Les " classes fonctionnelles " qui ne sont porteuses d'aucune information, mais seulement

de traitement, qui ne sont souvent pas des classes de notre diagramme. Par exemple gestionnaire du planning, décodeur de message, …

• Il est parfois difficile de savoir si une information est un attribut d'une classe ou une classe (avec une association avec la classe). Dans le doute il vaut mieux faire une classe, quitte à revenir en arrière dans une itération ultérieure. Par exemple pour la classe personne l'âge est un attribut (donnée simple) l'adresse étant à priori une donnée complexe sera plutôt une autre classe associée à la personne. • Les entités suivantes peuvent prétendre à devenir des classes :

- les objets physiques (produit…), - les transactions (réservation, commande,….), - les lignes de transaction (ligne de commande…), - les conteneurs (catalogues, lots,…), - les organisations (services, départements,….), - les acteurs ou les rôles (client, fournisseur….), - les regroupements en abstraction (modèle, genre, type, catégorie….), - les évènements (vol,…)

Pour le use case " effectuer un achat " voici la liste des classes sélectionnées:

caissier

vente

caissecatalogue

article

ligne de vente

Paiement

ticket

68

Nous ne gèrerons pas les exemplaires des articles. Nous appèlerons article un ensemble d’exemplaires identifiés par le même code barre, et comportant des informations identiques (prix …).

Nous allons maintenant rajouter les associations entre les classes, en donnant un intitulé et des cardinalités à ces associations.

Notre but n'est pas de mettre à jour toutes les associations entre les différentes classes, mais de noter les associations pertinentes pour comprendre le problème. Il faut privilégier les associations qui durent dans le temps, et dont la connaissance est nécessaire à la compréhension du problème. Il faut éviter les associations redondantes ou dérivables d'autres associations. L'établissement de ces associations nous amène à poser des questions au client. C'est un des buts recherchés. Voici une possibilité de diagramme de classe avec ses associations.

Sur ce diagramme de classe d'analyse il faut maintenant mettre les attributs des classes qui ont été repérés dans le cahier des charges, le diagramme de use case, ou dans le diagramme de séquence boîte noire du use case. A priori, les attributs présents dans notre diagramme de classe d'analyse sont des attributs simples. On pourra faire exception des données pures qui sont des regroupements de données simples ( ici code, adresse, prix ) .

caissier

0..1

0..1

caisse0..1

0..1

utilise

0..1

1..*

Paiement 1

1

ticket1

1

0..*

ligne de vente

1

0..*1

1

1

vente

1

0..1effectue

1..*

1

comprend

1

1payée par

1

1génère

catalogue

11

1

se fait à partir

1

1

article

1

0..*

est décrite par

0..*

contient

69

caissier

0..1

0..1

caisse0..1

0..1

utilise

0..1

1..*

Paiement somme : réel 1

1

ticket1

1

0..*

ligne de ventequantité : entier

1

0..*1

1

1

Ventedate : Dateheure : Heure

1

0..1effectue

1...*

1

comprend

1

1payée par

1

1génère

catalogue

1 1

1

se fait à partir

1

1

description article description : text prix : réel code : codebarre

1

0..*est décrite par

0..*

contient

le prix ou la somme devraient se donner par rapport à une monnaie...

Les attributs qui ont un comportement sont des classes associées à notre classe. Ceci ne présage en rien du diagramme de classe de conception. Nous verrons ultérieurement ce que deviennent les associations dans ce schéma… Dans les attributs, il ne doit pas y avoir de clef sur un autre objet. Cela se représente par une association. Voici notre diagramme de classe enrichi des attributs d'analyse.

70

CONCLUSION

Récapitulation et synthèse Donner les différents types de relation avec des exemples ? En UML une composition est : * une opération entre trois classes * une association d’héritage entre deux classes * une association qui indique qu’une classe en contient une autre * un attribut composé de plusieurs attributs 3) En UML, quelle est l’expression vraie exprimée par le diagramme suivant :

Client

Compte

1..1 0..*

4) En UML quelle est la signification d’une généralisation : * relation d’inclusion entre 2 classes * génération d’une opération conceptuelle * relation de dépendance hiérarchique entre deux classes * n’existe pas en UML. Exercice «classification »

Classer les relations suivantes en généralisation, instanciation, agrégation, lien ou association. Argumenter les réponses. (a) Un pays possède une capitale. (b) Un philosophe qui dîne utilise une fourchette. (c) Un joueur de rugby est un avant, un demi ou un arrière. (d) Une équipe de rugby est composée de 8 avants, 2 demis et 5 arrières. (e) Dédé programme son simulateur de vol en Java sur son PC. (f) Java, C++ et Eiffel sont des langages orientés objet. (g) La Tour Eiffel a 3 étages et 3 millions de boulons. (h) L'agrégation est un examen. Exercice Dessiner les diagrammes (d’objets, de classes) correspondant aux situations suivantes : (a) La France est frontalière de l’Espagne. Le Canada est frontalier des Etats-Unis. (b) Un polygone est constitué de points. Un point possède une abscisse et une ordonnée. (c) Une médiathèque possède des médias, empruntables par les abonnés de la médiathèque. (d) Un client demande une réparation. Une réparation est effectuée par un mécanicien. Elle nécessite des compétences. Un mécanicien possède des compétences. (e) Une galerie expose des oeuvres, faites par des créateurs, et représentant des thèmes. Des clients, accueillis par la galerie, achètent des oeuvres. Dessiner les diagrammes (d’objets, de classes, de généralisation) correspondant à la situation

71

suivante : (f) Un bateau contient des cabines, occupées par des personnes qui effectuent des activités. Les personnes sont ou bien des guides, ou bien des animateurs, ou bien des passagers. Les guides expliquent des visites aux passagers et les animateurs animent des animations pour les passagers. Exercice « JARDINIER » Un jardinier effectue deux types de travaux : l’arrosage et le piochage. L’arrosage consiste à arroser des plantes (tulipes, eucalyptus ou géraniums) avec un outil (arrosoir ou tuyau) contenant de l’eau et le piochage consiste à retourner la terre avec un outil (pioche ou pelle) pour y mettre de l’engrais. Autrement dit, le jardinier utilise un outil (arrosoir, tuyau, pelle ou pioche) pour mettre une ressource (eau ou engrais) sur un objet naturel (terre ou plante) ; celuici est produit par un travail (arrosage ou piochage). 1) Dessiner le diagramme de généralisation des classes. On généralisera les classes du domaine avec une classe « Objet ». 2) Dessiner un diagramme d’objets correspondant au texte suivant : Jacques est un jardinier qui arrose 3 géraniums avec un arrosoir rempli d’eau. Jules est un jardinier qui pioche la terre avec une pelle pour y mettre de l’engrais. 3) Dessiner un premier diagramme de classes avec les classes Jardinier, Arrosage, Arrosoir, Eau, Geranium. Puis dessiner un autre diagramme de classes similaire au premier mais avec des classes plus générales : Jardinier, Travail, Outil, Ressource, ObjetNaturel. 4) Quelle difficulté posent les classe Eau, Terre, Engrais ? 5) Placer les ordres de multiplicité sur les 2 diagrammes de classes précédents. Quelle Remarque peut-on faire ? Exercice : Dessiner les diagrammes (d’objets, de classes) correspondant aux situations suivantes : (a) La France est frontalière de l’Espagne. Le Canada est frontalier des Etats-Unis. (b) Un polygone est constitué de points. Un point possède une abscisse et une ordonnée. (c) Une médiathèque possède des médias, empruntables par les abonnés de la médiathèque. (d) Un client demande une réparation. Une réparation est effectuée par un mécanicien. Elle nécessite des compétences. Un mécanicien possède des compétences. (e) Une galerie expose des oeuvres, faites par des créateurs, et représentant des thèmes. Des clients, accueillis par la galerie, achètent des oeuvres. Dessiner les diagrammes (d’objets, de classes, de généralisation) correspondant à la situation suivante : (f) Un bateau contient des cabines, occupées par des personnes qui effectuent des activités. Les personnes sont ou bien des guides, ou bien des animateurs, ou bien des passagers. Les guides expliquent des visites aux passagers et les animateurs animent des animations pour les passagers.

73

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de leçon : Diagramme de contexte

Objectifs de la leçon :

Le stagiaire doit être capable de :

• Déterminer la frontière du système

• Définir les cardinalités des acteurs par rapport au système

• Préciser les rôles de chaque acteur

• Définir les événements des acteurs vers le système


74

INTRODUCTION

Rappel

Le diagramme de contexte

Le diagramme de contexte définit les intentions entre les acteurs et le système, et les différents rôles de chaque acteur vers le système ainsi que les cardinalités

DEROULEMENT DU COURS Diagramme de contexte Les objets déterminés serviront lors des phases analyse, conception et plus tard à l’implémentation. Les objets du modèle statique sont une représentation (modélisation) des objets (monde réel), qui seront en général ceux qu’on retrouve lors de l’implémentation sous la même forme ou sous une forme différente. Ils sont munis de données encapsulées dans les objets, représentant leurs attributs et leurs opérations (méthodes).

La notation du diagramme de contexte

La notation du diagramme de contexte est une forme modifiée de la notation des DFDs, ne différant que par le niveau des détails qu'elle fournit et par l'ajout d'un symbole spécial - le terminateur (terminator). Les symboles contextuels sont illustrés à la figure 6

Les symboles du diagramme de contexte

75

Les définitions de ces symboles sont les suivantes:

• Une transformation de contexte représente la totalité du comportement exigé du système. Elle reçoit le numéro 0 (zéro), bien que ce numéro ne soit normalement pas représenté. Son nom suit le format d'une phrase comportant un verbe et un objet, définissant la fonction complète du système.

• Les terminateurs représentent les composants de l'environnement d'un système, organisés en groupes aux comportements prédéfinis. Ils peuvent avoir des noms physiques, puisqu'ils représentent habituellement le comportement d'équipements existants.

• Les magasins ou dépôts externes représentent les interfaces dans lesquelles l'information a été entreposée. Ce sont des composants qui font partie de l'environnement et non du système!

Règles du diagramme de contexte

Les règles pour l'interconnexion des composants des diagrammes contextuels sont illustrées à cette figure.

Définition de ses règles Les règles qui s'appliquent au diagramme de contexte sont:

Connexions autorisées dans les diagrammes de contexte

76

* Une seule transformation de contexte peut apparaître sur le diagramme contextuel d'un système donné.

* Les terminateurs peuvent figurer à plusieurs exemplaires pour plus de commodité, cela étant indiqué par un astérisque accolé à leur nom

(Utilisé lorsqu'ils ont des interfaces complexes). * Les terminateurs ne peuvent pas être connectés les uns aux autres sur ce diagramme.

Toute interconnexion sera définie dans un modèle stratégique approprié. * Un diagramme contextuel donné peut être dessiné sur plusieurs pages, chacune comportant

la même transformation de contexte, mais un ensemble différent de terminateurs (n'est utilisé que lorsque des interfaces très complexes sont rencontrées).

Exemple 1 :

Les événement externes ( ) sont envoyés des acteurs vers le système. Alors ce qu’il

nous permet d’identifier les déférents use cases. Exemple d’un diagramme de contexte correct

Système

Acteur 1 Acteur 2

Acteur 3

77

CONCLUSION

Récapitulation et synthèse Généralement le diagramme de contexte n'existe pas dans UML, mais est néanmoins très intéressant Il emprunte le même formalisme qu'un diagramme de collaboration. Exercice d’évaluation Compléter le diagramme de contexte du SI Approvisionnement

Corrigé

Fournisseur

Fournisseur

Si Achats

Bon de Commande

Fournisseur Catalogue de produits

Fournisseur

Bon de livraison Responsable

Rapport de -conformité

Si Achats

Bon de Commande

80

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de la leçon : Diagramme de séquence

Objectifs de la leçon :

Le stagiaire doit être capable de :

- Déterminer la classifications des événements ou bien les uses cases

- Préciser les acteurs qui ont participés dans ce diagramme


81

INTRODUCTION Rappel Les diagrammes de séquences

• Les diagrammes de séquences permettent de représenter des collaborations entre objets selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages.

• Contrairement au diagramme de collaboration, on n'y décrit pas le contexte ou l'état des objets, la représentation se concentre sur l'expression des interactions.

• Les diagrammes de séquences peuvent servir à illustrer un cas d'utilisation.

• L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme ; le temps s'écoule "de haut en bas" de cet axe.

• La disposition des objets sur l'axe horizontal n'a pas de conséquence pour la sémantique du diagramme.

Les diagrammes de séquences et les diagrammes d'état transitions sont les vues dynamiques les plus importantes d'UML.

82


Diagramme de séquence Objet :

• objet dédié: une instance particulière d'une classe • objet anonyme : n'importe quelle instance d'une classe

Stimulus : • une instance de message i.e. représentation de l'échange d'information entre objets

Supporte des flots de données et divers types de synchronisation Déroulement temporel :

• vertical: représente la ligne de vie des objets et les périodes d'activité des objets • horizontal: représente l'enchaînement des stimuli entre 1 objet émetteur et 1 objet

récepteur i.e. les flots de contrôle (séquence, répétition, alternative) Syntaxe générale d’un diagramme de séquence En résume deux types de diagramme de séquence : Diagramme de séquence boite noir : c’est le diagramme simple c'est-à-dire on ne détaille

pas les événements.

Diagramme de séquence boite blanche : son principe est de détailler le diagramme de

séquence boite noir c'est-à-dire il détaille chaque opération qui a un sens vers le système (

)

Par exemple on a ci dessous un diagramme de séquence boite noir qui décrit tous les

événements entre le system et les acteurs (client, caissier)

83

Pour faire un diagramme de séquence boite blanche il suffit de détailler chaque opération (

)

Dans un diagramme

Comme exemple on détaille l’opération (FINIR VENTE)

Caissier Caisse System

Finir vente Set terminer (true)

Total

Set (total)

Temps

Client Cassier Système

Présenter article

Affiche (prix et désignation) Saisir quantité

Affichage (sous total)

Finir vente

Paiement Payer (somme)

Lire article (code)

Affichage (total)Calcule total

Calcule monaieAffichage (monaie)

Impression (ticket)Rendre (ticket, monaie)

Plusieurs

Temps

Calcule sous total

PlusieursSi qte>0

84

La différence entre un diagramme de séquence d’analyse et un diagramme de séquences de conception

– Un diagramme de séquences (ici, il s’agit d’un diagramme de séquence

d’analyse)

de vie d’un objet. Par exemple, sur la figure 17, on a fait apparaître le délai de 250

millisecondes entre le moment où l’utilisateur appuie sur un bouton et le moment où le

voyant correspondant s’allume.

Deux notions, liées au contrôle des interactions s’avèrent utiles :

– la première est la condition qui indique quand un message doit être envoyé. Le

message ne sera transmis que si la condition est vérifiée. On indique les conditions

entre crochets au-dessus de l’arc du message ;

Calculer (total)

Temps

85

– la seconde est la façon de marquer la répétitivité d’un envoi de message. Par

exemple, si l’on doit répéter un appel pour toute une collection d’objets (pour

tous les éléments de la liste des demandes), on fera précéder le dénominateur du

message par un « * ».

Un diagramme des séquences permet de vérifier que tous les acteurs, les classes, les

associations et les opérations ont bien été identifiés dans les diagrammes de cas et de

classes. Il constitue par ailleurs une spécification utile pour le codage d’un algorithme

ou la conception d’un automate.

Le diagramme de séquence de conception ci-dessous permet de voir un exemple

dans lequel la signature des méthodes est à peu près formalisée.

Un diagramme de séquences de conception Autre exemple du diagramme de séquence

Exemple 1

Temps

86

Exemple2

Système central

Saisie compte

Guichetier Système guichet

Validation compte Demande type

Retrait liquide (220F) Vérification solde compte

Débit compteAutorisation délivrance

temps

Appelant Ligne Appelé

{b-a < 1 sec} {c-b < 10 sec}

{d’-d < 5 sec}

décrocher tonalité

Taper chiffre

routage

sonner sonner

Arrêt sonnerie Arrêt sonnerie

décrocher

a b c d

d’

87

Exemple 3

Exemple 4

Durant : Personne

Objet SA : Société ANPE

Notification d’embauche

Demande développeur C++ Proposition

Convocation

Demande d’entrevue

Entrevue

BilanAttribution du poste

88

Exemple 5

Dupont : Personne

OOsoft : Société

ConseilRecrut

Proposition CV Dupont pour ce poste Convocation Entrevue

Bilan

Notification d’embaucheEmbauche

Propose poste consultant objet

Interface Objet 1 : Classe1 Frontière

du système Acteur

Temps

Objet 3 : Classe3

Destruction De l’objet

commenceSession (nom, pass) vérifieMotPasse

(pass)

^MotPasseOkObjet 2 : Classe2

créé ajouteSession

ouvreSession

fermeSession

Message sur l’objet

Retour de

Bloc d’opération

89

• Chaque réception de message donne lieu à une durée d'activation : le temps de

traitement du message

• La durée d'activation de l'émetteur recouvre celle du récepteur

• Type de messages :

• flot de contrôle à plat :

• message synchrone

• message asynchrone

• flot de contrôle emboîté ou appel de procédure (avec attente implicite du

retour)

• retour d'un appel de procédure, avec ou sans paramètre de retour

Exemple 6

91

CONCLUSION


Un diagramme de séquence détaillé UML en conception technique est utilisé pour : • comporter un diagramme de classes en trouvant de nouveaux attributs • ce diagramme n’est utilisé en conception technique • structure la logique d’une application informatique • ordonner la séquence des composants graphiques dans une fenêtre Windows

Exercice d’évaluation N°1

Dessiner le diagramme de séquences du simulateur de voitures de la création du simulateur jusqu’au déroulement de la simulation. Pour vérifier votre bonne compréhension, on vous demande de nommer les objets de votre diagramme avec les noms utilisés dans le corrigé en C++. Remarque : Dans ce diagramme, on suppose ne pas connaître ni la classe du fournisseur, ni la classe de la voiture.

Corrigé

92

Exercice d’évaluation N°2

Ouvrir et sauvegarder A) Enoncé Dans un programme interactif développé avec le pattern MVC, on donne la possibilité à l’utilisateur :

- de sauvegarder un document sur un support permanent, - de charger en mémoire un document existant sur un support permanent.

1) Des trois classes Modèle, Vue et Contrôleur qui intercepte les demandes de sauvegarde ou de chargement de l’utilisateur. 2) On pourrait en poussant la philosophie un peu loin confier l’exécution des demandes à une vue dédiée à la communication vers le support permanent.

Pourquoi, cependant, il est plus naturel de donner la mission au modèle ?

3) Donner le diagramme de séquence relative à une demande de chargement d’un document en mémoire.

B) Corrigé

1) Une demande de sauvegarde ou de chargement est faite par l'utilisateur. C'est donc le contrôleur qui doit intercepter cette demande. 2) Etudions séparément les deux cas : Sauvegarde et Chargement : Charger un document consiste à redéfinir complètement le contenu du document en mémoire. Il paraît donc naturel que cette action soit une méthode du modèle. La sauvegarde du document met à jour le document sur le support permanent. L'état d'un document est donc toujours une certaine conjonction entre son état en mémoire et son état sur le support permanent. Le document sur le support permanent est donc un prolongement du document en mémoire.

94

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de la leçon : Diagramme d’activité

Objectif de la leçon : Le stagiaire doit être capable de :

Connaître la déférence entre les états et les activités Ainsi que les événements qui déclanche des résultats

entre toutes les activités possibles Prévoir les itérations Associer la synchronisation (disjonction et conjonction d’activités)


95

INTRODUCTION Rappel UML permet de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une variante des diagrammes d'états transitions). Une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles. Le passage d'une activité vers une autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre (elles sont automatiques). Transition Pour passer au diagramme d’activité il faut tenu compte au condition et les événements ainsi que les différents type de transition.


Diagramme d’activité Le diagramme d’activité est très proche du diagramme état transition puisqu’il représente le comportement interne d’une opération ou d’un d’utilisation en termes d’actions. Les concepts de base d’activités et de transition déjà définis sont repris dans le diagramme d’activités. Cependant, le diagramme d’activité utilise le concept d’état action qui correspond à un état dans lequel se déroule une action et au minimum une transition automatique vers un autre état. Représentation d’un diagramme d'activité : Transition Comment construire un diagramme d’activité ?

1. Identifiez la portée (« scope ») du diagramme d'activité Commencez en identifiant ce que vous allez modéliser. Un seul use case? Une partie d'un use case ? Un « workflow » qui inclut plusieurs use cases ? Une méthode de classe ?

2. Ajouter l’état de départ et de terminaison

Activité1

Activité1

96

3. Ajouter les activités Si vous modélisez un use case, introduisez une activité pour chaque use case principal. Si vous modélisez un « workflow », introduisez une activité pour chaque processus principal, souvent un use case. Enfin, si vous modélisez une méthode, il est souvent nécessaire d’avoir une activité pour chaque grande étape de la méthode.

4. Ajouter des transitions (séquentielles), des transitions alternatives (conditionnelles), des synchronisations entre des activités, des itérations.

5. Identifier des swimlanes et répartir des activités identifiées dans ces swimlanes Notion d’activité

• Etat de départ • Etat de terminaison • Transition • Transition Alternative

Notion de diagramme d’activité Synchronisation disjonctive et conjonctive

97

Exemple 1 : Représentons le cycle de vue d'une entreprise : Etat initial

Faillite Exemple 2:

Diagramme d'activité avec synchronisation

Création -Innovation

Chute

Matricule

Croissance

98

Exemple 3:

L'exemple suivant illustre l'utilisation des barres de synchronisation :

Chercher un café

Mettre un filtre

Mettre du café

Remplir Le réservoir

D’eau Prendre une tasse

Prendre un jus d’orange

Allumer la cafetière

Le café passe

Déguster

Servir

[il reste du jus d’orange]

[plus de jus d’orange]

Synchronisation

99

Couloirs d'activités : Afin d'organiser un diagramme d'activités selon les différents responsables des actions représentées, il est possible de définir des "couloirs d'activités". Il est même possible d'identifier les objets principaux, qui sont manipulés d'activités en activités et de visualiser leur changement d'état .

100

CONCLUSION

Récapitulation et synthèse En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités, mais seuls les mécanismes complexes ou intéressants méritent d'être représentés. Exercice 1

Elaborer un diagramme d’activité représentant la saisie d’un texte sous Word, et l’impression

Exercice 2

Construire un diagramme d’activité représentant l’utilisation d’une cafetière électrique: – premier état: chercher du café – dernier état: Servir du café

Solution

101

Exercice 3 Construire un diagramme d’activité pour modéliser le processus de commander d’un produit. Le processus concerne les acteurs suivants: – Client: qui commande un produit et qui paie la facture – Caisse: qui encaisse l’argent du client – Vente: qui s’occupe de traiter et de facturer la commande du client – Entrepôt: qui est responsable de sortir les articles et d’expédier la commande.

Solution

Commander produit

Encaisser

Payer facture

Expédier commande Facturer

client

Sortir articles

Traiter commande

103

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de leçon : diagramme de collaboration


• Décrire le comportement collectif d’un ensemble d’objet • En vue de réaliser une opération En décrivant leurs interactions modélisées par des envois (Éventuellement numérotés) de messages


104

INTRODUCTION

Activités d’apprentissage Rappel Diagramme de collaboration :

• Les diagrammes de collaboration montrent des interactions entre objets (instances de classes et acteurs).

• Ils permettent de représenter le contexte d'une interaction, car on peut y préciser les états des objets qui interagissent.

Transition A partir d’un diagramme d’état en passe à réaliser un diagramme de collaboration

Diagramme d’état

Attente

Actif

Diagramme collaboration

:o1

:o2

1 : m()

1.1 : msg()

105


Activités d’apprentissage Utilité de diagramme de collaboration Le diagramme de collaboration va nous montrer comment les objets interagissent entre eux pour rendre le service demandé par le contrat d'opération. Nous allons d'abord observer la syntaxe, et la forme que prend ce diagramme d'opération. Les objets doivent demander des services à d'autres objets. Il leur faut donc connaître ces objets pour pouvoir leur adresser des messages. Nous allons donc regarder la visibilité des objets (c’est à dire comment un objet peut connaître d'autres objets). Enfin quand une ligne du contrat d'opération est réalisée il faut se poser la question de savoir quel objet agit pour réaliser cette ligne (qui crée tel objet, qui reçoit l'événement initial). En un mot il est nécessaire de définir les responsabilités des objets. L'expérience et le savoir faire des professionnels nous ont permis de définir des règles, des modèles de pensée, qui nous permettrons de nous guider pour définir les responsabilités des objets. Ce sont les GRASP patterns que nous verrons enfin, avant de traiter notre caisse. La notion collaboration Deux notions fondamentales :

• Le contexte : vue statique partielle des objets • Les interactions : séquences de messages échangés par les objets

Représentation générale de diagramme de collaboration :

Syntaxe du diagramme de collaboration Nous allons prendre un exemple de diagramme de collaboration pour introduire toutes les notions véhiculées dans ce diagramme. Rappelons nous que ce diagramme, dans le contexte de la conception, nous montre comment les objets coopèrent entre eux pour réaliser les opérations définies par les contrats d'opération.

:caisseModifierprix(code,prix) :catalog1 :Modifierprix(code,prix)

: article art : article

1.2 : setprix(prix)

106

Les objets

Ici nous représentons la coopération des objets pour rendre le service demandé. Il s’agit donc bien d’objets. Ces objets apparaissent sous trois formes : Les objets anonymes ( : caisse, :catalogue). A comprendre la caisse courante, où le catalogue courant… Les objets nommés (art : article). A comprendre que c’est bien le type d’article qui correspond au code cherché. Les multi objets ( : article). A comprendre comme la collection des types d’article

associée au catalogue

Conditions sur l’envoi des messages

L’envoi d’un message peut être assorti d’une condition

• UML permet de spécifier de manière très précise l'ordre et les conditions d'envoi des messages sur un diagramme dynamique.

• Pour chaque message, il est possible d'indiquer : o les clauses qui conditionnent son envoi, o son rang (son numéro d'ordre par rapport aux autres messages), o sa récurrence, o ses arguments.

:caisseModifierprix(code,prix)

:catalog1 :Modifierprix(code,prix)

: article

1.1 :art :=

art : article

1.2 : setprix(prix) Objet

nommé

Multi objet

Objet

107

• Retour d’une liste de valeurs à l’issue d’un envoi de • Message

Une liste de valeurs peut être retournée suite à l’envoi d’un message

-NB : Pour rendre les messages plus spécifiques il est de préférable de les affecter des conditions et des attributs comme ci-dessus :

• Pour chaque message, il est possible d'indiquer : o les clauses qui conditionnent son envoi, o son rang (son numéro d'ordre par rapport aux autres messages), o sa récurrence, o ses arguments.

• La syntaxe d'un message est la suivante :

[pré "/"] [["["cond"]"] [séq] ["*"["||"]["["iter"]"]] ":"] [r ":="] msg"("[par]")"

o pré : prédécesseurs (liste de numéros de séquence de messages séparés par une virgule ; voir aussi "séq"). Indique que le message courant ne sera envoyé que lorsque tous ses prédécesseurs le seront aussi (permet de synchroniser l'envoi de messages).

108

o cond : garde, expression booléenne. Permet de conditionner l'envoi du message, à l'aide d'une clause exprimée en langage naturel.

o séq : numéro de séquence du message. Indique le rang du message, c'est-à-dire son numéro d'ordre par rapport aux autres messages. Les messages sont numérotés à la façon de chapitres dans un document, à l'aide de chiffres séparés par des points. Ainsi, il est possible de représenter le niveau d'emboîtement des messages et leur précédence. Exemple : l'envoi du message 1.3.5 suit immédiatement celui du message 1.3.4 et ces deux messages font partie du flot (de la famille de messages) 1.3. Pour représenter l'envoi simultané de deux messages, il suffit de les indexer par une lettre. Exemple : l'envoi des messages 1.3.a et 1.3.b est simultané.

o iter : récurrence du message. Permet de spécifier en langage naturel l'envoi séquentiel (ou en parallèle, avec "||") de messages. Notez qu'il est aussi possible de spécifier qu'un message est récurrent en omettant la clause d'itération (en n'utilisant que "*" ou "*||").

o r : valeur de retour du message. Permet d'affecter la valeur de retour d'un message, pour par exemple la retransmettre dans un autre message, en tant que paramètre.

o msg : nom du message.

o par : paramètres (optionnels) du message.

3 : bonjour ()

Ce message a pour numéro de séquence "3".

[heure = midi] 1 : manger()

Ce message n'est envoyé que s'il est midi.

1.3.6 * : ouvrir()

Ce message est envoyé de manière séquentielle un certain nombre de fois.

3 / *||[i := 1..5] : fermer()

Représente l'envoi en parallèle de 5 messages. Ces messages ne seront envoyés qu'après l'envoi du message 3.

1.3,2.1 / [t < 10s] 2.5 : age := demanderAge(nom,prenom)

109

Ce message (numéro 2.5) ne sera envoyé qu'après les messages 1.3 et 2.1, et que si "t < 10s".

1.3 / [disk full] 1.7.a * : deleteTempFiles() 1.3 / [disk full] 1.7.b : reduceSwapFile(20%)

Ces messages ne seront envoyés qu'après l'envoi du message 1.3 et si la condition "disk full" est réalisée. Si cela est le cas, les messages 1.7.a et 1.7.b seront envoyés simultanément. Plusieurs messages 1.7.a peuvent être envoyés

Conclusion sur les messages : La syntaxe des messages

1.1 :art := chercher(code) : article

Message initial issu du

D’abord le catalogue cherche

:caisse :catalogu1 :modifierprix(code,prix)

: article art : article

1.2 :

Caisse envoie un

Puis il modifie le prix de l’article trouvé

Modifierprix(code,prix)

110

Le message initial est non numéroté par convention. Ce message est un des événements issu du diagramme de séquence boîte noire, dont nous avons fait un contrat d’opération. Les opérations effectuées en réponse à ce message seront numérotées de 1 à n (notons qu’en général n n’est pas très élevé, si la conception est bien faite). Les opérations effectuées en réaction à un message numéro x seront numérotées de x.1 à x.n. Et ainsi de suite pour les opérations effectuées en réaction à un message numéro x.y (x.y.1 à x.y.n). Un message a la forme suivante

Un lien entre deux objets est directionnel. La flèche indique le receveur du message. Ce lien implique que l’objet qui envoie le message connaisse celui qui le reçoit. Un objet ne peut en effet envoyer un message qu’à un objet qu’il connaît (rappelez-vous que l’on envoie un message à un objet en lui parlant : moncatalogue, modifie le prix de l’article de code moncode à monprix.). Chaque flèche implique une visibilité orientée entre les objets. Exemple 1 :

Exemple 2

:ihmClient

:consultationController

:Compte

sinon:Client

3:4: entrer n° compte

5: consulter compte

6: obtenir solde

111

Exemple 3 :

Exemple 4 :

112

Exemple 5 :

CONCLUSION Récapitulation et synthèse

Un diagramme de collaboration est utilisé pour : * schématiser la collaboration entre un composant et une base de données * montrer comment les objets participent avec une interface graphique * montrer comment les objets inter -agissement entre eux ce diagramme n’est pas utilisé en conception technique.

Exercice d’évaluation Exercice 1

OOsoft:Sociéte

Conseil Recrut: CabinetRecrutement

Dupont: Personne

estCandidat

Convoquer(unPoste)

PasserEntrevue()

ProposerPoste (unPoste)

signer

estClient

ProposerCandidats (desCandidats,unPoste)

New Ct1:ContratTravail

signer

Embaucher(unPoste) EffectuerBilan()

NotifierEmbauche(unPoste)

Système guichetier

Guichetier Système Central

(1) Saisie compte (2) Validation compte

(3) Demande type d’opération

(4) Retrait espèces

(5) vérification solde compte

(6) Débit compte

(7) Autorisation délivrance

113

Définir un diagramme d’état du déroulement d’une voiture (marche avant, marche arrière, point mort …) A partir de ce diagramme réaliser un diagramme de collaboration

Exercice 2

A partir de ce diagramme d’état distributeur de boisson réalisé un diagramme collaboration

115

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de la leçon : Diagramme d ’Etat

Objectifs de la leçon : Le stagiaire doit être capable de - Faire tous les états possibles d’un objet - Etudier les conditions de transition - Définir la durée d’un état


116

INTRODUCTION Activités d’apprentissage Rappel Diagramme d’un état : il montre les différents états des objets en réaction aux événements. L’état d’un objet et défini, à un instant donné, par l’ensemble des valeurs de ses propriétés. Transition : c’est le passage d’un état à un autre. Un événement : est un fait survenu qui déclanche une transition. Une action : est une opération instantané qui ne peut être interrompue ; elle est associée à une transition. Une activité : est une opération d’une certaine durée qui peut être interrompue, Elle est associée à un état d’un objet. Transition A fin d’extraire les classes et les objets il faut réfléchir de tous les cas possibles de ce dernier

117


Activités d’apprentissage

C’est un graphe composé de nœuds représentant des états d’un objet d’une classe et les arcs sont les transitions portant des événements. Un diagramme d’états est propre à une classe d’objets. Un état d’un objet peut correspondre à des sous états. Cela dépend du niveau de

granularité qu’on désire. Exemple : L’état Sportif peut être représenté par trois sous états : Athlète Haut Niveau ; Sélection en E.N. et Compétition.

Les sous états sont représentés comme des états. Dans un diagramme d’états on peut développer un état d’un objet par un sous

diagramme d’états avec des points d’entrée et des points de sortie. De telle sorte on peut passer d’un état à un sous état et inversement.

La notion d’état Un état d’un objet est défini à la fois par la valeur de ses attributs et de ses liens avec les autres objets. Il représente ainsi un intervalle de temps. L’objet est dans un état initial et peut alors changer d’état. Etat • Abstraction des valeurs d'attributs et de liens d'un objet • Un état a une durée (intervalle de temps entre deux événements) • spécifie la réponse à un événement • État et événement sont duaux Un événement sépare deux états

Changer carrière

Suivre parallèlement Disputer

Convocation Athlète Haut Niveau

Sélection en Equipe Nationalle

Compétition

118

Un état sépare deux événements Schéma général : Etat 1 transition [condition]/action Etat 2 Faire: activité 1 faire : activité 2 Exemple : cette figure montre un des actions et activités d’états ainsi que la description complète d’une transition

Etat 1 maladie [arrêt]/réception arrêt Etat 2 Faire : travaille faire : mise en arrêt

Ici l’objet Etudiant peut passer d’un état Etudiant à un état de diplômé à un état de sportif, C’est l’attribut Statut qui va changer de valeur. Représentation d’un état :

Un événement est produit par un fait et véhicule une information qui va solliciter un ou plusieurs objets. Soit ils répondront en activant une méthode ; soit ils ne réagiront pas du tout. Cela dépend de l’état dans lequel se trouve (nt) l’ (les) objet(s). Un événement peut être interne ou externe au système.

Etudiant

Diplômé Sportif

*Etudiant

0..*

*

*

PratiquerInscritEn

Diplôme Sport

Nom Prénom Âge Statut

119

Lorsqu’un objet provoque un événement en direction d’un autre objet, ce dernier peut répondre en déclenchant une de ses méthodes C’est une interaction entre ces deux objets. L’événement est qualifié alors de message entre ces deux objets. Exemple 1 :

Exemple 2 : Exemple 3 :

Demande créationfermeture accomplie

En dépôt

Débiteur

fermeture

retrait (s) dépôt(s)

Créditeur[Solde >0] [Solde >0]

[Solde ≤0] [Solde ≤0]

Anniversaire (âge) [âge=18]Mineur Majeur

Naissance Décès

Etat Etat final

Evénement condition

Etat transitio

120

Exemple 4 :

Exemple de distributeur de boisson

Remarque : Plusieurs sous diagrammes d’états peuvent intervenir en même temps. Ils se déroulent en concurrence ou en synchronisation.

Décroché

Raccroché

Attente Pièce

En communication

Attente nontant

Taper numéro urgenceInsérer pièce/

credit=0

Taper un numéro

État initial

État final

121

Lorsqu’ils sont en concurrence, le premier sous diagramme d’état bloque les autres et fait quitter l’état englobant vers un autre état.

Lorsqu’ils sont en synchronisation, la transition de l’état englobant vers un autre état ne s’effectue que lorsque tous les sous diagrammes le permettent. Aucun sous diagramme ne peut être interrompu.

Sous diagramme d’état en concurrence.

- Sous diagramme d’état en synchronisation

Synthèse Etat Un état spécifie la réponse de l'objet aux événements d'entrée. Il est stable. Il peut être caractérisé par un ensemble de valeurs d'attributs et de liens d'un objet. Il correspond à l'intervalle de temps entre deux événements reçu par l'objet. Transition : Relation entre deux états indiquant qu’un objet dans le premier état va passer dans le deuxième quand un événement particulier apparaîtra, et que certaines conditions seront satisfaites. Evénement:

Proposition Entrevue Proposition ANPE OU

Petites annonces

Allocation chômage

Inscrit ANPE

En PhaseEmbauche

AcceptationInsciption

Demander Congé Assurer Fonctions

En congé

ET

122

Un événement est un stimulus pouvant transporter des informations (sous forme de paramètres). Il est considéré comme n'ayant pas de durée. Un événement peut être émis par un objet du système ou par un objet externe au système. Il peut également provenir de l’interface du système, par exemple un clic de souris. Quelle que soit son origine, un événement peut être soit dirigé vers un ou plusieurs objets, soit émis sans destination précise dans le système, certains objets du système pouvant alors le capter. La réponse d’un objet à un événement dépend de l'état dans lequel il se trouve autant que de l'événement. Remarque : la plupart des ouvrages et des outils de modélisation objet emploie les termes événement et message indifféremment. En UML, un message est un événement particulier, issu de l’interaction entre deux objets (un objet appelle une méthode d’un autre objet). Tout événement n’est donc pas forcément un message. Etats initial et final : Chaque automate de classe doit préciser un état initial (état d’une instance juste après sa création). On peut également préciser les conditions de destruction en ajoutant un état final. Condition Une condition est une expression booléenne, attachée à un événement, qui doit être vraie pour le déclenchement de la transition. Elle est indiquée entre crochets à la suite du nom de l'événement Action : Une action est une opération instantanée. Elle est associée à un événement. Elle représente une opération dont la durée est insignifiante comparée à la résolution (niveau de définition) du diagramme d'état. La notation d'une action sur une transition est précédée d’une barre oblique ("/"). Activité :

Etat initial(création) (néant)

Etat X Evénement

(état

Chauffage à l'arrêt

Chauffage en marche

Refroidissement [temp < temp référence]

Réchauffement [temp > temp référence]

En attente

En attente

Menu visible

Bouton droit activé / afficher menu

Bouton droit non activé / effacer menu

Curseur bougé / item de menu en

123

Une activité est une opération qui dure un certain temps. Elle est associée à un état. Elle peut être continue ou finie (se termine d’elle même). Notation : "Do : activité". Les diagrammes d’état peuvent s’exécuter une seule fois ou en boucle continue Les diagrammes "une seule fois" (one–step-diagrams) représentent les objets qui ont une vie finie. Un diagramme "une seule fois" possède un état initial et un état final.. L'état initial est entré à la création de l'objet; l'entrée dans l'état final (qui peut éventuellement prendre plusieurs conditions) implique, elle, la destruction de l'objet Diagramme en boucle continue Ce diagramme qui décrit le comportement d'une ligne téléphonique, est une boucle continue. On ne se soucie pas de savoir comment la boucle a démarré.

Compte

Créditeur

Compte débiteur Do: CalculAgio

Retrait [solde - retrait < 0]

Dépôt [solde + dépôt > 0]

Début

Blanc

Echec et mat

noir bouge

Tour des noirs

blanc bouge

Tour des blancs

Echec et mat

Noir gagne

Partie nulle

pat

pat

124

L'événement "Combiné raccroché" provoque une transition de n'importe quel état vers l'état "En attente". Noter que les états ne définissent pas toutes les valeurs d'un objet; par exemple, l'état "En numérotation" inclut toutes les séquences de numéros incomplets. Ce n'est pas la peine de les différencier puisqu'ils ont tous le même comportement

Conclusion

En attente

En tonalité Faire: jouer

En numérotation

En connexion Faire: trouver

Sonnant Faire: sonner

Connecté

Déconnecté

En délai dépasséFaire: jouer bip

Message enregistré

Tonalité: "occupé"

Combiné Combiné

Fin de

Fin de

Faux

Bon

Chiffre

Acheminé

Appelé répond / connecter

Appelé raccroche / déconnecter

Message

Numéro

Fin de

125


1) Un diagramme d’états UML en conception technique est utilisé pour : • Indiquer l’état d’une transaction dans une application avec base de données • Définir la structure d’un état imprimé • Découvrir certaines méthodes dans une classe données • Ce diagramme n’est jamais utilisé en conception technique

Exercice

La montre Bouton mode Bouton avance

En fonctionnement normal, la montre affiche les heures, les minutes et les secondes qui défilent. Une pression sur le bouton mode sélectionne le chiffre des heures qui se met à clignoter. A ce moment une pression sur le bouton avance incrémente le compteur d’une heure. Une nouvelle pression sur le bouton mode sélectionne le chiffre des minutes qui se met à clignoter. A ce moment une pression sur le bouton avance incrémente le compteur d’une minute. Une nouvelle pression sur le bouton mode revient à l’affichage normal. 1) Dessiner le diagramme état -transition de cette montre. 2) On veut modifier le comportement de la montre pour que si on maintient la pression sur le bouton avance au moins deux secondes, l’avancement des heures ou des minutes se fasse en continu

Exercice 2 2-donner tous les états possibles d’un compte bancaire 2-donner les conditions pour passer d’un état à l’autre débuteur, créditeur… (Exp.:mineur majeur il faut que age=18) Exercice 3 Faire les transitions convenables aux états suivants pour faire un diagramme d’état de l’objet client d’une gestion commerciale

22 :15 :35

126

Voici les états de client

client perspectif client actif client douteux client inactif client en contentieux client supprimer

Exercice 4

D’écrire un diagramme d’état d’une bouteille avec toutes les conditions de passer d’un état a l’autre

128

Nom/Prénom : Etablissement : Spécialité : Niveau d’étude : Bloc modulaire : Thème de leçon : Diagramme de composants et déploiement


129

INTRODUCTION Rappel Le diagramme de déploiement « Où ranger les composant ? » Le diagramme de déploiement montre la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels. Les ressources matérielles sont représentées sous forme de noeuds. Les noeuds sont connectés entre eux, à l'aide d'un support de communication. La nature des lignes de communication et leurs caractéristiques peuvent être précisées. ⇒ Les diagrammes de déploiement peuvent montrer des instances de noeuds (un matériel

précis), ou des classes de noeuds. Le diagramme de composant « Le physique du système »

• Les diagrammes de composants permettent de décrire l'architecture physique et statique d'une application en terme de modules : fichiers sources, librairies, exécutables, etc. Ils montrent la mise en oeuvre physique des modèles de la vue logique avec l'environnement de développement.

• Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants

• Les composants peuvent être organisés en paquetages, qui définissent des sous-systèmes. Les sous-systèmes organisent la vue des composants (de réalisation) d'un système. Ils permettent de gérer la complexité, par encapsulation des détails d'implémentation.

130


Diagramme de composants Un système informatique comprend des composants physiques propres à l’environnement de réalisation choisi. Le diagramme de composants permet de décrire ces composants qui sont : le sous-système, le module, le programme et le sous-programme, le processus et la tâche. Sous-systèmes : cette notion a déjà été présentée au paragraphe consacré aux paquetages. Les trois icônes utilisées

Exemple 1 :

Main Spécification

131

Exemple 2 :

Diagramme de déploiement Le diagramme de déploiement représente l’architecture physique des composants matériels qui supportent l’exécution du système. Chaque composant matériel, appelé aussi nœud est symbolisé par un cube. Les liens entre ces composants permettent de décrire les supports physiques de communication. Le diagramme de déploiement permet de représenter les classes de composants matériels ainsi que des instances particulières de ces classes (objet). Un objet, instance d’une classe de composant physique, est distingué dans le diagramme en soulignant le nom attribué à l’objet.

132

Exemple 1 : Détermine le schéma général d’un diagramme de déploiement

Exemple 2 :

ServeurApplication

SGBD Client

133

Exemple 3 :

Uranus Serveur BDD ORACLE V7

Saturne Stockage

de fichiers

Station d’administration

Venus Serveur exchange Passerelle Internet

Routeur IP

IBM grand système

MVS

<< RNIS Internet >>

<< ethernet 100Mb >>

Mercure Passerelle

SNA

<< ligne spécialisée 64 Kbps >>

<< Token Ring >> IBM AS/400

Jupiter Serveur logiciels

Neptune Serveur BDD SQL Server

Pluton Serveur impressionet communication Elara

Imprimante

<< Réseau téléphonique commuté >>

134

Un diagramme de déploiement peut spécifier la répartition des traitements dans une architecture client-serveur.

Procédures stockées d’insertion

Pages WEB

HTML

ActiveX

ODBC

Objet métier

BDD

Poste Client Serveur de BDD

Serveur WEB Serveur de traitement

135

Bibliographie et Ressources

Penser Objet avec UML et Java de Michel Lai de chez Dunod http://fr.wikipedia.org/wiki/Unified_Modeling_Language UML Quick Reference Card (http://tnerual.eriogerg.free.fr/uml.html) UML Quick Reference (http://www.holub.com/goodies/uml/index.html)

Grady Booch, James Rumbaugh, Ivar Jacobson (2000). Le guide de l'utilisateur UML, ISBN 2212091036

UML 2 et les Design Patterns - Craig Larman (3ème édition), ISBN 2744070904

Martin Fowler et al. (2004). UML 2.0, ISBN 2744017132 : initiation aux aspects essentiels de la notation

"http://developpeur.journaldunet.com/dossiers/alg_uml.shtml", UML en 5 étapes, MORLON J, avril, 2004. "http://developpeur.journaldunet.com/tutoriel/cpt/031013cpt_uml5conseils.shtml", Cinq petits conseils pour un schéma UML efficace, BORDERIE X, avril, 2004. "http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-ex_rel.pdf", Exercices - Modèle Relationnel, DARMONT J, janvier, 2004. "http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-ex_uml.pdf", Exercices - Modèle UML, DARMONT J, janvier, 2004.

Récupérée de « http://fr.wikipedia.org/wiki/Unified_Modeling_Language »

136

Logiciels de modélisation UML Logiciels libres

• ATL solution open source pour faire des transformations de modèles vers ou depuis UML (entre autres); ATL est un langage de type QVT.

• Dia

• Umbrello un modeleur UML sous GPL. Ne fonctionne pas correctement sous Windows ;

• ArgoUml un modeleur UML sous Licence BSD ;

• Gaphor un modeleur UML sous GPL la version actuelle est 0.7.1 ;;

• BOUML, un modeleur UML sous GPL pour Windows, Linux, MacOS X et Solaris;

• Eclipse GMT-XUML, en version betâ.

• Eclipse UML2, Méta modèle UML2, sans interface graphique.

• Netbeans 5.5, en version preview.

• Staruml, en version libre.

• Acceleo, générateur de code source à partir de modèles UML.

Logiciels propriétaires

• Together, de Borland ; • Poseidon, basé sur ArgoUml (version commerciale) ;

• Rational Software Architect / Rational Software Modeler (et toujours Rose/XDE), de IBM Software Rational ;

• PowerDesigner, de Sybase (un outil de modélisation complet intégrant l'UML en plus des classiques MCD, MPD ...) ;

• Objecteering de Softeam ;

• Visual Paradigm for UML, de Visual Paradigm Internation Ltd. ;

• SDE for Eclipse, un plugin UML pour Eclipse ;

• Omondo EclipseUML, un plugin UML pour Eclipse ;

• Jude [1], en Java ;

• MagicDraw, un éditeur de diagrammes UML ;

• Enterprise Architect, un outil de modélisation UML ;

137

Modélisation objet avec UML Etude de cas : Application de contrôle d'accès à un bâtiment Le but est de protéger un bâtiment en restreignant l'accès à certaines salles. L'ouverture de chacune des portes de ces salles est commandée par un lecteur de Badges placé à proximité. Les badges qui permettent l'ouverture des portes ne sont Délivrés qu'aux personnes qui doivent accéder aux locaux protégés dans l'exercice de leurs fonctions. Les droits d'accès sont alloués entre les groupes de personnes et les Groupes de portes, de sorte qu'une personne ou une porte doit toujours être au moins dans un groupe (le sien). Un groupe de portes peut contenir des portes dispersées dans tout le bâtiment. Une porte donnée ne peut appartenir qu'à un seul groupe de portes. La même personne peut appartenir à plusieurs groupes, de sorte que ses droits d'accès Correspondent à l'union des droits d'accès de chacun des groupes qui la contiennent. La définition des droits d'accès est effectuée en décrivant pour chaque groupe de personnes les différents groupes de portes qui sont accessibles et sous quelle contrainte horaire. Les droits d'accès sont décrits dans un calendrier annuel qui décrit la situation semaine par semaine. Vu la faible variation des droits dans le temps, un Calendrier peut être initialisé au moyen de semaines types qui décrivent une configuration de droits donnée. Le superviseur peut créer autant de semaines type qu'il le désire. Les changements apportés à une semaine sont automatiquement propagés dans tous les calendriers qui utilisent cette semaine type. Le système de contrôle d'accès doit fonctionner de la manière la plus autonome possible. Un superviseur est responsable de la configuration initiale et de la mise à jour des différentes informations de définition des groupes de personnes et de portes. Un gardien dispose d'un écran de contrôle et est informé des tentatives de passage infructueuses. Les alarmes sont transmises en temps légèrement différé: la mise à jour de l'information sur l'écran de contrôle est effectuée toutes les minutes. 1. Décrire la vue des besoins (use case view) de ce système de contrôle d'accès. Cette analyse des besoins consiste à définir : les acteurs de ce système. le diagramme des cas d'utilisation du système. les principaux scénarios de chaque cas d'utilisation qui seront décrits par des

diagrammes de séquence (point de vue temporel). 2. Décrire la vue logique (logical view) de ce système. Cette analyse du domaine consiste à définir : le diagramme des classes. décrire les principaux scénarios par des diagrammes de collaboration

(interactions entre objets d’un point de vue spatial). Il est bien évidemment possible de représenter les interactions entre objets par des diagrammes de séquence.

Corrigé

142

Etude de cas : Application gestion de caisse Un commerçant de produits touristique (souvenirs, livres régionaux,…) désire informatiser sa caisse. Chaque type de produit possède un code unique (étiquette à code à barres), et un même prix pour tous les produits de ce type. L'objectif est de faciliter la maintenance des prix des articles.

143

Chaque type de produit est référencé dans un catalogue, puis sur l'étagère ou il est rangé. Le cassier s'identifie pour démarrer la caisse (avec mot de passe). La caisse fera les fonctions habituelles d'une caisse : calcul du sous total, calcul du total, possibilité de rentrer plusieurs articles ayant un même code, retour d'une marchandise avec le ticket de caisse. Le paiement se fera en monnaie seulement. La caisse permet d'éditer des rapports:

• Le reçu qui sera donné uniquement pour une vente effective. Il contient le Nom du magasin, un message de bienvenue, la date et l'heure. Puis pour chaque vente il donne le code du produit, la description du produit, le prix unitaire, la qualité et le sous total. Enfin nous y trouvons le total TTC. • Le rapport quotidien de l'ensemble des ventes (date, heure, total). • Le rapport quotidien détaillé : liste de l'ensemble détaillé des ventes de la journée. La caisse s'exécute sur un PC. Une douchette permettra de lire les codes à barres. Les informations peuvent être rentrées au clavier, ou à la souris. Première étape : les exigences et les acteurs Les exigences que nous allons découvrir sont les exigences fonctionnelles. A partir du problème posé, c'est-à-dire de tout ce qui est écrit, plus tout ce qui ne l'est pas, nous allons lister l'ensemble des fonctions qui pourront être réalisées par le logiciel. Ces exigences seront numérotées pour pouvoir les tracer dans les intentions d'acteur puis dans les uses cases.

144

référence fonction

R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 R 10 R 11 R 12 R 13 R 14 R 15 R 16

Modifier le prix d'un produit Calculer le total d'une vente Rentrer une quantité par article Calculer le sous total d'un produit Retourner une marchandise Payer l'achat Editer un ticket de vente Editer un rapport succinct Editer un rapport détaillé Se connecter à la caisse Se connecter en gérant Définir les droits des usagers Entrer un produit au catalogue Supprimer un produit du catalogue Enregistrer un produit à la caisse Initialiser la caisse

Regardons maintenant les acteurs qui gravitent autour de notre application. Un acteur humain a bien une intention quand il fait quelque chose.

♀ ♀ ♀ Caissier Client Manager

♀ ♀

Salarié Administrateur Les acteurs de l'application Ce diagramme est un diagramme de classe qui permet de lister les différents acteurs. Il se peut que notre liste ne soit pas complète, une itération suivante du processus nous permettra de compléter ce schéma.

145

Nous avons défini 5 acteurs. N'oublions pas qu'un acteur représente un rôle, et non pas une personne. Le manager peut être aussi l'Administrateur (notion de rôle). Un salarié est soit un caissier, soit le Manager. Il se peut que dans la première itération l'analyse ne remarque pas ceci. C'est souvent dans une itération ultérieure que nous verrons les généralisations d'acteurs. Nous connaissons les acteurs, et les exigences de l'application. Nous pouvons donc faire un diagramme de contexte dynamique. Gérer un retour d'article Editer un ticket Enregistrer un produit Enregistrer un produit Gérer un paiement

♀ ♀

Client caissier Retourner un article gérer la catalogue Payer un achat initialiser les caisses Editer des rapports Magasin Se connecter

♀ ♀

Salarié définir les droits des usagers manager

♀

Administrateur Diagramme de contexte de magasin

♀ ♀ Client Caissier Est à la caisse Est dans

146

magasin

Gère Travaille dans

♀ administre ♀ Salarié Manager

♀ Administrateur Diagramme de contexte statique (capture initiale des besoins) Deuxième étape : les intentions d'acteurs Nous allons maintenant regrouper les exigences en intentions d'acteurs. Une intention d'acteur est un enchaînement de fonctions qui rend un service complet à un acteur (et pas une fraction de service).

Référence Fonction Intention d'acteur acteurs

147

R 1 R 13 R 14 R 16 R 5 R 10 R 11 R 8 R 9 R 12 R 7 R 6 R 2 R 3 R 15 R 4

Modifier le prix d'un produit Entrer un produit au catalogue Supprimer un produit du catalogue Initialiser la caisse Retourner une marchandise Se connecter à la caisse Se connecter en gérant Editer un rapport succinct Editer un rapport détaillé Définir les droits des usagers Editer un ticket de vente Payer l'achat Calculer le total d'une vente Rentrer une quantité par article Enregistrer un produit à la caisse Calculer le sous total d'un produit

Gérer le catalogue Gérer le catalogue Gérer le catalogue Initialiser la caisse Retourner un article Se connecter Se connecter Editer un rapport Editer un rapport Définir les profils Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat

Manager Manager Client, Caissier Salarié

Manager Administrateur Client, Caissier

Ici dans le tableau la notion d'acteur repose sur l'intention d'acteur, pas sur la fonction. Ainsi toutes les lignes d'une même intention d'acteur ne sont-elles pas renseignées pour les acteurs. Ici nous distinguerons l'acteur principal des acteurs secondaires en soulignant l'acteur qui est à l'origine de l'intention. Nous allons bien sûr vérifier que les exigences définies précédemment sont toutes incluses dans les intentions d'acteur. La traçabilité est un facteur essentiel des phases de définition des besoins et de celle d'analyse. Nous avons les intentions d'acteurs, nous pouvons donc faire un diagramme de Use Case. Toute cette démarche peut être faite d'une autre manière: *nous déterminons les acteurs et les exigences. *A partir des exigences nous faisons un diagramme d'activité (UML) en colonnes (swimlane). Chaque colonne correspond à un acteur. Cela nous permet de définir les responsabilités des acteurs, donc de définir les Uses Cases correspondants. Gestion d’une bibliothèque municipale Objectifs : établir le diagramme de cas d’utilisation, le diagramme de classe Il s’agit de réaliser un logiciel de gestion des prêts de documents aux lecteurs d’une bibliothèque municipale. L’usager demande sur poste informatique qu’un document lui soit communiqué. Le lecteur se voit attribué un numéro lors de son inscription. Un système de fiches existe pour la recherche documentaire qui n’est pas informatisée actuellement.

148

Si le lecteur est déjà inscrit, il s’identifie puis remplit. Sur le terminal informatique la demande de document souhaité. il sélectionne le document désire et le lieu ou il souhaite consulter le document (sur place ou à domicile). Il existe en fait plusieurs type de documents : journaux, livres et microfilm. Chaque usager dispose de droits différents en fonction de sa profession et de son employeur. Ces droits sont valides pour une année et correspondent à des niveaux de confidentialité. Certains documents sont consultables uniquement sur place, d’autres peuvent être emportés à domicile. Pour consulter sur place, un emplacement doit être affecté au lecteur dans une salle adaptée au document. Si le document n’est pas disponible pour le moment, le système fournit au lecteur une fiche de réservation comprenant une date de disponibilité et une place réservé (en cas de consultation sur place).le lecteur peut ensuit venir à la date prévue utiliser sa réservation. Si le document est disponible, le système imprime une fiche qui permet au lecteur de retirer son document au guichet. L’employé valide alors le prêt sur son poste informatique et enregistre le retour lorsque le lecteur rend le document. En cas d’emprunter à domicile. L’usager à une semaine pour rendre le document. L’usager peut à tout moment consulter l’état de ses demandes (prêts et/ou réservation en cours). Il ne pourra effectuer un emprunt que s’il a rendu les document déjà empruntes. Chaque document possède une cote. Un journal possède un titre, une date et un numéro. Un livre possède un titre et un ou plusieurs auteurs. Les microfilms ont été tirés à partir de certains journaux. Le système fournit à l’employé, chaque soir après le départ du dernier client, la liste des documents consultés sur place qui n’ont pas rendu. Le responsable du service des prêts peut à tout moment demander au système la liste des prêts à domicile non rendu à la date prévue. Ceux-ci seront classés par nombre de jours de retard, afin de pouvoir éditer les lettres de relance. Il peut aussi obtenir différentes statistiques.

Corrigé Définition des besoins Liste des exigences référence Fonction R1 Inscrire un nouveau lecteur R2 Enregistrer la cotisation d’un lecteur R3 Enregistrer un nouveau document R4 Sortir un document R5 Vérifier la disponibilité d’un document R6 Restituer un document R7 Consulter la liste des documentation rendus R8 Editer une lettre de relance

149

R9 Emprunter un document Liste des acteurs Les acteurs principaux de ce système sont : L’usager L’employé Les intentions d’acteur On classera les références ci–dessus dans ce tableau d’exigences : Référence Fonction Intension Acteur R1 R2

-Inscrire un nouveau lecteur -Enregistrer la cotisation d’un lecteur

Gestion des lecteurs L’employé

R3 - Enregistrer un nouveau document

Gestion des documents

L’employé

R4 R6

- Sortir un document - Restituer un document

Gestion des emprunts/restitutions

L’employé

R7 R8

- Consulter la liste des documentation rendus - Editer une lettre de relance

Gestion des relances L’employé

R5 -Vérifier la disponibilité d’un document

Vérification de la disponibilité d’un document

L’employé L’usager

R9 -Emprunter un document

Emprunter un document

L’usager

Diagramme de cas d’utilisation ( use case )

L’employé L’usager

150

*Use case description haut niveau : 1-Gérer les lecteurs

• Nom de use case : gérer les lecteurs • Acteur principale : l’employé • Acteur secondaire : l’usager • Evénement déclencheur de use case : le nouveau lecteur arrive chez l’employé et

demande d’emprunter un document • Rôle de use case : l’employé saisit les informations du lecteur ,enregistrer sa cotisation

et lui demande de remplir la demande de document souhaité • Références croisées exigences :R1,R2 • Terminaison de use case : l électeur prend son document et s’en va pour le consulter

soit sur place soit à domicile. 2-Gérer les documents

• Nom de use case : gérer les documents • Acteur principale : l’employé

Gérer les lecteurs

Gérer les documents Verrifier la disponibilité D’un document Gérer les emprunts /restitutions

Gérer les relances

Emprunter un document

151

• Acteur secondaire : ---------- • Evénement déclencheur de use case : un nouveau document arrive à la bibliothèque • Rôle de use case : l’employé enregistre le nouveau document et lui donne un numéro • Références croisées exigences :R3 • Terminaison de use case : le document est enregistré et placé avec les autres de même

type 3-vérification la disponibilité d’un document

• Nom de use case : vérifier la disponibilité d’un document • Acteur principale : l’employé • Acteur secondaire : l’usager • Evénement déclencheur de use case : un lecteur arrive et demande un document pour

l’emprunter • Rôle de use case : l’employé entrer le numéro de document pour le rechercher • Références croisées exigences :R5 • Terminaison de use case : le système renvoi a l’employé le résultat de recherche

4-gérer les emprunte /restitution

• Nom de use case : gérer les emprunte /restitution • Acteur principale : l’employé • Acteur secondaire : l’usager • Evénement déclencheur de use case : un usager représente chez l’employé pour

emprunter un document ou restituer • Rôle de use case : en cas d’emprunt l’employé enregistre le document dans la liste des

documents prêts , en cas de restitution il place le document dans sa propre place • Références croisées exigences :R4,R6 • Terminaison de use case : le document est soit prêt soit restitué à la bibliothèque

5-Gérer les relances

• Nom du use case : gérer les relances. • Acteur principal : l’employé. • Acteurs secondaires : ------- • Evénement déclencheur du use case : l’employé demande au système la liste des

usagers n’ayant pas rendu les documents dans leur propriété. • Terminaison du use case : l’employé imprime des lettres de relance pour

les envoyer. • Références croisées des exigences : R7, R8

*Analyse

+Diagramme de séquence boite noire :

152

Enregistre le document dans la liste

des prêts avec le nom de l’usager

Entrer le n° du document pour vérifier

Sa disponibilité

Se présente pour emprunter un document

Lui demande de fournir ses informations

Enregistre les informations du lecteurLui demande le document qu’il souhaite

Fournit le nom du document

Enregistre les cotisations de l’usager

Prête le document au lecteur

-pour le use case détaillé « Emprunter un document » :

- pour les use case détaillé « Gérer les lectures »

Recherchedocument

Si le document est disponible

L’usager l’employé le système

Lui donne une fiche pour la remplir

Remplit la fiche et la rend à l’employé

Répond l’employé

lui donne le document

Se présente pour emprunter un document

Si nouveau lecteur

Si le document est disponible

L’usager L’employé le système

153

+Diagramme de classe d’analyse : Employé lecteur -code int -Matricule int 1..1 inscrire 1..* -Nom String -Nom String -Prénom String -Prénom String -Adresse String +Employé() +void lecteur() +void gérer lecteur() +void emprunter()

1..* 1..* Bibliothèque emprunter Travaille pour 1..1 -Nom String -Adresse String +void bibliothèque 1..* 1..1 Document 1..* -code int -type String Se trouve dans

+void document +Contrat d’opération : -l’opération :inscrire un lecteur

• Nom : inscrire un lecteur

• Responsabilité : inscrire un nouveau lecteur dans la bibliothèque

• Exigences : R1, R2

• Notes : une fois le lecteur inscrit, il peut emprunter des livres quand il

veut

• Pré conditions : le lecteur doit payer une cotisation

• Post conditions : le lecteur peut emprunter le livre ou le document qu’il veut

-l’opération :emprunter un document

• Nom : emprunter un document

• Responsabilité : emprunter un document pour le consulter sur place ou à domicile

154

• Notes : --------

• Pré conditions : le document doit être disponible, et le lecteur ne doit avoir aucun

document non restitué

• Post conditions : le document et enregistré emprunté par le lecteur

*Conception +Diagramme de classe de conception : Employé lecteur -code int -Matricule int 1..1 inscrire 1..* -Nom String -Nom String -Prénom String -Prénom String -Adresse String +Employé () +void lecteur() +void gérerlecteur () +void emprunter ()

1..* 1..* Bibliothèque emprunter Travaille pour 1..1 -Nom String -Adresse String +void bibliothèque () 1..* 1..1 Document 1..* -code int -type String Se trouve dans +void document ()

Microfilm -journal String +microfilm ()

Livre -titre String -auteur String +livre ()

Journal -Titre String -date Date -numéro int +journal ()

cours uml 1

Documents

Transcript of cours uml 1