Embed Size (px)
Citation preview
Université de Batna II - Pôle Fesdis
Département Informatique
Support de cours :
Génie logiciel
Enseignant : Dr Sofiane AOUAG
Cours destiné aux étudiants en L3 SI
Table des matières
0. Introduction 0.1 Description du cours ................................................................................................... 1 0.2 Objectifs du cours ...................................................................................................... 4
1. Chapitre I : Analyse des besoins et définition du problème 1.1 Introduction ............................................................................................................... 5 1.2 Définition du problème................................................................................................ 6 1.3 Grilles de Levesques ................................................................................................... 7 1.3.1 Application des Grilles de Levesque ..................................................................... 8 1.4 Délimitation du périmètre du système ........................................................................ 9
2. Chapitre II : Digramme de cas d’utilisation 2.1 Introduction ............................................................................................................. 10 2.2 Éléments graphiques d’un diagramme de cas d’utilisation ........................................ 10 2.3 Formalisme de diagramme de cas d’utilisation .......................................................... 11 2.3.1 Identifier les acteurs .......................................................................................... 11 2.3.2 formaliser les cas d’utilisation .......................................................................... 12 2.4 Relations et stéréotypes dans le diagramme de cas d’utilisation ............................... 13 2.4.1 Relation d’include ............................................................................................ 13 2.4.2 Relation Extends .............................................................................................. 14 2.4.3 Relation d’héritage (généralisation et spécialisation) ........................................ 15 2.5 Rédaction de cas d’utilisation selon le Formlulaire de Cockburn ............................... 16 2.5.1 Rubriques de Cockburn...................................................................................... 16 2.5.2 Exemple Domaine ............................................................................................ 17 2.6 Conclusion ................................................................................................................. 18
3. Diagramme d’activité 3.1 Introduction ............................................................................................................. 19 3.2 Eléments graphiques de diagramme d’activité .......................................................... 19 3.3 Formalisme d’un diagramme d’activité ..................................................................... 21 3.4 Flot de contrôle et synchronisation dans le diagramme d’activité ............................. 23 3.4.1 Synchronisation disjonctive (embranchement) ................................................ 23 3.4.2 Synchronisation conjonctive (conjonction) ....................................................... 24 3.4.3 Les couloirs dans le diagramme d’activité ........................................................ 25 3.4.4 Flux d’objet ............................................................................................................ 26 3.5 Conclusion ................................................................................................................. 28
4. Chapitre IV : Diagramme de classes 4.1 Introduction ............................................................................................................. 29 4.2 Éléments graphiques d’un diagramme de classes ...................................................... 29 4.3 Formalisme d’un diagramme de classes ................................................................... 31 4.3.1 La multiplicité ................................................................................................. 31 4.3.2 Notion d’association ........................................................................................ 32 4.3.3 Association binaire et n-aire ............................................................................ 32 4.3.4 Association avec navigabilité et contraintes ..................................................... 33 4.3.5 Association dérivée .......................................................................................... 34 4.3.6 Classe-Association ........................................................................................... 35 4.4. Relations dans le diagramme de classes ................................................................... 36 4.4.1 Relation d’agrégation et de composition ......................................................... 36 4.4.2 Relation de dépendance ................................................................................. 37 4.4.3 Relation d’Héritage, généralisation et spécialisation ...................................... 37 4.5 Conclusion ................................................................................................................ 38
5. Chapitre V : Diagramme d’objets 5.1 Introduction ............................................................................................................. 39 5.2 Éléments graphiques d’un diagramme d’objets ....................................................... 39 5.3 Formalisme d’un diagramme d’objets ...................................................................... 40 5.3.1 Constructeur et destructeur d’objets .............................................................. 40 5.3.2 Durée de vie d’un Objet .................................................................................. 40 5.3.3 Objet Composite ............................................................................................. 41 5.3.4 Les contraintes dans le diagramme d’objets .................................................... 41 5.3.5 Le langage de contrainte OCL ......................................................................... 43 5.4 Implémentation en java ............................................................................................ 44 5.4.1 Implémentation de la relation bidirectionnelle 1-1.......................................... 45 5.4.2 Implémentation de la relation bidirectionnelle 1-N .......................................... 46 5.4.3 Implémentation de la relation unidirectionnelle 1-N ........................................ 46 5.4.4 Implémentation de la relation unidirectionnelle 1-1 ........................................ 47 5.5 Conclusion ................................................................................................................. 47
Introduction
Introduction
0.1 Description du cours
Il est certain qu’un processus de conception vise en premier lieu l’obtention d’une solution dîtes acceptable du système informatique. Par analogie avec un architecte qui dessine plusieurs plans pour arriver au plan final d’architecture de la maison, la conception d’un système informatique est organisée dans un processus de modélisation qui prévoit aussi plusieurs visions du même problème pour aider à trouver une solution acceptable. Par conséquent, la solution finalement retenue n’est guerre obtenue en une seule itération. Plusieurs étapes sont nécessaires pour raffiner le niveau de détails du système à réaliser. Les premières étapes donnent une vision macro à très gros grains et permettent d’avancer dans la compréhension du problème.
Le processus de modélisation requiert souvent des représentations fidèles de la réalité en se basant sur les méthodes de conception qui utilisent généralement la modélisation à base de graphiques (Coan et al 2015). L’importance de la représentation graphique du modèle reste une évidence, vue la précision donnée de cette représentation par rapport à une description informelle en langage naturelle.
Figure 0.1 Processus de l’analyse
Ce cours aborde la modélisation des systèmes informatiques en se basant sur le langage (graphique) Uml qui est considéré comme un langage de modélisation très efficace. Avant de montrer les différents diagrammes Umls, ce cours présente en premier lieu le processus du développement afin de mettre en évidence l’importance de la phase d’analyse dans les projets informatiques. Il s’agit d’identifier l’objectif en premier lieu pour structurer les besoins et rédiger le cas d’utilisation
Un modèle est une abstraction de la réalité qui permet de présenter une ou plusieurs vues sur le système ; la vue a pour objet d’aider le concepteur à mieux comprendre et donc mieux maîtriser le système. La cohérence entre les différentes vues du système est importante, chaque vue cible des catégories différentes d’intervenants ayant des besoins différents (voir figure ci-dessous). Il est important de rappeler ici que chaque vue représente une étape dans le cycle de vie de développement de logiciel. Nous avons abordé le processus de développement logiciel et les différents modèles de cycle de vie d’un logiciel (Modèle en V, Modèle en cascade et Modèle en spirale) dans la première partie du module (gestion de projet de développement de logiciel). Ce cours se contente de présenter les étapes d’analyse et de conception en se basant sur le langage de modélisation UML.
Figure 0.2 Processus de développement logiciel (Jacobson et al 2000)
Un langage de modélisation doit définir la manière de présenter le modèle en offrant une sémantique des concepts ; une notation pour la représentation de concepts ; des règles de construction et d'utilisation des concepts. L'industrie du logiciel dispose de nombreux langages de modélisation adaptés aux différents contextes d’utilisation : on peut distinguer les langages adaptés aux systèmes procéduraux (MERISE...) ; adaptés aux systèmes temps réel (ROOM, SADT...) ; adaptés aux systèmes à objets (OMT, Booch, UML...).
UML est donc un langage de modélisation destiné en particulier à la modélisation objet. Il est devenu une norme OMG en 1997 (OMG est un organisme à but non lucratif créé en 1989 à l'initiative de sociétés comme HP, Sun, Philips, etc. (Roques 2006, Roques 2002)). Il propose un formalisme indépendant d'un langage de programmation donné. Pour ce faire, UML normalise les concepts de l'objet (énumération et définition exhaustive des concepts) ainsi que leur notation graphique. Il permet de diviser la visualisation d’un modèle en diagrammes qui correspondent à des vues différentes.
Les modèles obtenus peuvent être implémentés dans un langage de programmation objet. On se contente de présenter dans ce cours les 10 principaux diagrammes (figure 0.3), leurs rôles complémentaires, et montrer comment les diagrammes d’un modèle sont construits de manière cohérente.
Figure 0.3 Principaux diagrammes UML étudiés
Notons que ces diagrammes peuvent être classés selon leurs aspects et fonctionnement suivant le point de vue classique de modélisation (statique, fonctionnel et dynamique) (Roques & Vallée 2003). L’aspect fonctionnel comporte : -les diagrammes de cas d’utilisation, -de séquence et -d’activité ; l’aspect statique comporte : -les diagrammes de classes,-paquetage, -objets, -composants et -déploiement ; l’aspect dynamique concerne : -les diagrammes de séquence,- de communication, -d’activité et -d’états-transitions.
Voici une brève description du contenu de chaque type de diagramme présenté dans la figure ci-dessus : Cas d’utilisation: c’est un diagramme visualisant les interactions entre le système et les utilisateurs (et autres systèmes externes). Il aide dans la visualisation des exigences / besoins ; Activité : il permet la modélisation des processus métier avec les échanges de données ; Classes : Ce diagramme permet de présenter les classes (d’analyse et de conception), les types, les interfaces et relations entre eux ;
Objets : on présente dans ce diagramme les instances de classes définissant une configuration importante du système ; Machine à états ou états-transitions: il s’agit de définir les états des classes à travers leur cycle de vie (de la création / instanciation des objets à leur destruction) et les événements qui provoquent les transitions / changements d’états ; Interaction : on distingue deux types de diagrammes d’interaction :
- séquence : ce type de diagramme permet de visualiser en plus des interactions leur ordre d’exécution qui est considéré comme important;
- communication : on visualise dans ce diagramme les interactions entre objets pour lesquels les connexions entre objets sont importantes ;
Composants : il s’agit de rassembler des classes ou des composants tels que conçus par l’équipe de développement pour décomposer le système en parties de logiciel gérables; Déploiement : il concerne les unités de configuration, d’installation et de déploiement du produit fini sur un parc de machines. Paquetages : on rassemble dans ce type de diagramme les éléments de modélisation par exemple pour les distribuer entre membres de l’équipe de développement ; Le langage UML possède quelques autres diagrammes qui ne seront pas détaillés dans ce cours : diagrammes de temps (en anglais, timing), diagrammes de vues globales d’interactions (en anglais, interaction overview) et diagrammes de structures composites. L’utilisation des 10 principaux diagrammes, qui seront présentés dans ce cours, sera largement suffisant aux étudiants de se familiariser avec les concepts liés à la modélisation informatique et atteindre les objectifs de ce cours. 0.2 Objectifs du cours L’objectif de ce cours est double: il s’agit d’une part de permettre aux étudiants d’avoir une vision globale sur l’analyse et la conception des systèmes informatiques afin d’apprendre la manière d’abstraire la réalité pour mieux comprendre le système à réaliser. D’autre part ce cours permet l’étude du langage de modélisation Uml en présentant les éléments méthodologiques d’utilisation des différents types de diagrammes dans un processus de modélisation. A la fin de ce cours l’étudiant sera capable de
- Se familiariser avec les concepts liés aux démarches de l’analyse, de conception et de développement des systèmes informatiques;
- Savoir traduire un besoin fonctionnel en s'appuyant sur les diagrammes UML ; - Comprendre la représentation et l'intérêt d'utilisation des différents diagrammes
UML pour le développement d’un logiciel ; - Intégrer les concepts objets nécessaires à une analyse/conception ; - Maîtriser les 10 principaux diagrammes UML.
Chapitre I :
Analyse des besoins et définition du problème
1.1 Introduction
Le processus d’analyse de besoin est considéré comme la première étape d’analyse du système à réaliser (ou même le système à améliorer). Ce système doit répondre à un ou plusieurs besoins qui doivent être analysés et exprimés dans la première étape d’analyse et de conception. Par exemple, une banque a besoin d’un guichet automatique pour assurer un service continu à ses clients. Le besoin concerne le fait que la banque possède un guichet automatique qui permet aux clients de retirer de l’argent même en dehors des heurs de travail. Notons que celui qui commande le logiciel s’appel le maître d’ouvrage et celui qui réalise le logiciel on le nome le maître d’œuvre.
Le maître d’ouvrage intervient constamment au cours de projet pour
- Définir et exprimer les besoins ; - Valider les solutions proposées par le maître d’œuvre ; - Valider le produit livré.
Le maître d’œuvre est par exemple la société de services en ingénierie informatique (SSII ou SS2I), qui est une société de services spécialisée en génie informatique. Elle se caractérise par ses compétences techniques de maîtrise d'œuvre. Le maître d’œuvre est souvent choisi pour ses compétences techniques, mais aussi pour son savoir faire. Au début du projet, un maître d’œuvre est capable de recueillir les besoins auprès des maîtres d’ouvrage. Le recueil des besoins implique une bonne compréhension du métier : par exemple la réalisation d’un logiciel pour une banque nécessite des connaissances approfondies dans les systèmes bancaires pour intégrer toutes les contraintes et les exigences du métier. Cette condition est primordiale pour bien cerner les cas d’utilisation exprimés par le client afin d’apporter des solutions adéquates (Charroux et al 2005).
Le problème souvent posé pendant la première étape concerne la distinction entre les besoins, les objectifs et les opportunités. La question qui se pose est : ai-je toutes les connaissances et les informations pour définir ce que doit faire le système ?
Pour guider le concepteur dans sa démarche, ce cours présente la manière de définition de problème, la technique d’analyse qui se base sur les grilles de Levesque et présente en fin des exemples de cas d’utilisation.
1.2 Définition du problème
Le recueil de besoin nécessite de compléter le cahier des charges par des discussions approfondies avec le maître d’ouvrage et les futurs utilisateurs du système. Le premier problème posé au niveau de la phase d’analyse est celui de communication. Une expression de besoin n’est pas facile car elle nécessite des compétences pluridisciplinaires pour assurer une maitrise des concepts liés aux domaines différents.
Un utilisateur a dit à un informaticien :
« Je sais que tu crois avoir compris ce que tu penses que j’ai dit, mais je ne suis pas sûr que tu réalises que ce que tu as entendu n’était pas ce que je voulais dire. »
Malheureusement, il y a souvent une différence : « Entre, Ce que je pense ; Ce que je veux dire ; Ce que je crois dire ; Ce que je dis ; Ce que vous avez envie d’entendre ; Ce que vous croyez entendre ; Ce que vous entendez ; Ce que vous avez envie de comprendre ; Ce que vous croyez comprendre ; Ce que vous comprenez… il y a dix possibilités qu’on ait des difficultés à communiquer. Mais essayons quand même… » – Bernard Werber (Bauchet 2015)
Le problème d’expression de besoin présente toujours des difficultés autant pour les informaticiens que non informaticiens. L’image d’humour très connue par les chefs de projets présente le problème réel et comment peut-on exprimer les besoins et livrer ce que le client a mal décrit.
Figure 1.1 Problème d’expression de besoins
1.3 Grilles de Levesques
Cette section présente une grille d’analyse appelée Grille de Levesque qui peut être utilisée comme un outil pouvant guider le concepteur à définir le problème. L’idée consiste à trouver un seul objectif au projet. Il s’agit de classer chaque affirmation pertinente issue des réunions de travail (brain-storming) ou d’une entrevue avec le client. En analysant les informations collectées, il faut d’abord procéder par la distinction de 6 classes de faits : Besoins, Objectif, Symptôme, Problème, Solution et Opportunité. Il faut donc distinguer un symptôme de problème, un besoin d’un objectif et une solution d’une opportunité. Nous donnons dans ce qui suit la définition de chaque concept :
Besoin: Exigence liée à la vie d’une personne, d’une organisation….
Exemples :
- Une personne doit manger pour assouvir sa faim.
- La voiture doit assurer sa tenue de route dans les virages.
2- Objectif: But à atteindre, résultat précis (servant de phare au développement)
Exemples :
- Demeurer en bonne santé - Assurer le transport de l’automobiliste et de ses passagers d’un lieu à un autre
3- Problème: Difficulté à surmonter pour atteindre l’objectif.
Exemples :
- Une personne a de l’urticaire - Mauvaise tenue de route de la voiture
4- Symptôme : Une manifestation du problème.
- Les boutons sur le visage est un symptôme de l’urticaire. - La voiture quitte la route lorsqu’elle aborde un virage au-delà de 60 km/h est un -
symptôme de mauvaise tenue de route.
5- Solution: ensemble des décisions et mise en œuvre permettant d’atteindre l’objectif en palliant les problèmes.
Exemple
- Supprimer la confiture de fraise peut être une solution à l’urticaire - La révision de la carrosserie peut être une solution à la tenue de route
6- Opportunité: bénéfice apporté au système mais ne répondant pas directement au besoin.
Exemples
- Supprimer la confiture de fraise peut être une solution à l’urticaire et peut contribuer à diminuer l’obésité (opportunité).
- La révision de la carrosserie peut être une solution à la tenue de route et une opportunité d’avoir un nouveau design.
1.3.1 Application des Grilles de Levesque sur l’analyse du problème de gestion de bibliothèque de MIRABELLE (cas fictif). Une idée extraite de (Lesvesques 1999)
On analyse les faits en fonction de l’objectif défini : si on prend comme objectif l’amélioration du service à la clientèle ; l’analyse sera résumée dans le tableau ci-dessous.
Tableau 3.1 Grilles de Levesques
Fait Donnée Observation symptôme problème besoin Objectif opportunité solution
A Lenteur du service * B Retard dans les rappels
de prêts *
C Files d’attente * D Pas de compilation de
stats récentes *
E Classifier de nouveaux doc. en retard
*
F Eliminer les retards de classement
*
G Faire le suivi des prêts * H Compiler régulièrement
les statistiques *
I Utiliser une base de données
*
J Ajouter du personnel * K Réduire et contrôler les
dépenses *
L Augmenter les revenus * M Réduire les délais de
classement *
N Améliorer le service à la clientèle
* X
O Limiter le temps de dépannage du matériel de la bibliothèque
Exercice : proposer une autre solution en mettant « (L) : augmenter les revenus » comme un objectif.
1.4 Délimitation du périmètre du système
La délimitation du système nécessite une analyse de sa structure ainsi que son intégration dans un système supérieur. La délimitation concerne tout simplement le fait de mettre des limites au système par le fait de spécifier les exigences en matière de développement, d’achat, d’exploitation ou même de maintenance. Il s’agit d’analyser et documenter les frontières de systèmes et de sous-systèmes en insistant surtout sur la distinction entre les décisions de conception et les contraintes d’exploitation. Il faut également identifier et documenter les interfaces entre systèmes et en décrire les interactions.
Exemple : Nous avons la possibilité de définir deux approches pour la délimitation du périmètre du système d’étude de caisse de supermarché :
1- Classique : La caissière est hors du système étudié - Toutes les interactions entre la caissière et le système seront listées dans le
modèle d’usage 2- Originale: La caissière est dans le système étudié
- Les interactions entre la caissière et le client seront alors listées dans le modèle d’usage.
- Le système pourra alors s’appliquer une borne interactive sans caissière
Figure 1.2 Délimitation du périmètre du système
Les contraintes d’exploitation peuvent concerner :
- Volumes (nombre de données à traiter) - Performance (temps de réponses) - Organisation : équipe support interne, ... - Spécifications techniques
o Existant : parc matériel et environnement logiciel
Remarque : Si on commence dès le début de conception du système de mettre des contraintes sur le matériel utilisé : par exemple la solution devra utiliser des Pentium IV, 1,5 Ghz. Ceci peut être considéré comme une décision de conception prématurée.
Chapitre II :
Digramme de cas d’utilisation
2.1 Introduction
UML propose de représenter les cas d'utilisation d'un système sous une forme graphique nommée diagramme de cas d'utilisation appartenant au modèle des besoins. En effet, UML n’est qu’un langage et il ne sert en première phase de projet qu’à formaliser les besoins, c'est-à-dire à les représenter sous forme graphique suffisamment simple pour être compréhensible par les acteurs du projet (Toutes les personnes impliquées dans le projet). Notons que ces acteurs ne sont pas forcément tous des informaticiens, il leur faut donc un moyen simple d’exprimer leurs besoins (Gollot 2015). Ceci est le rôle précis du diagramme de cas d’utilisation : faciliter l’expression des besoins sous forme graphique compréhensible par toutes les personnes impliquées dans le projet même pour les non informaticiens.
Courtes définitions issues des spécifications UML (Charroux et al 2009) :
● Un cas d'utilisation est une manière spécifique d’utiliser un système. Le cas d’utilisation réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l’acteur qui l’initie.
● Un acteur est une entité externe au système, en interaction avec ce dernier. L'entité est un rôle joué par un utilisateur, par exemple un comptable, ou par un autre système, un capteur par exemple.
● Un scénario est un chemin particulier au travers de la description abstraite et générale fournie par le cas d'utilisation (Muller & Gaertner 2003).
Un diagramme de cas d'utilisation montre acteurs et cas d'utilisation ensemble avec leur relations. La relation entre un acteur et un cas d'utilisation est appelée association et correspond au fait que l'acteur participe à un cas d'utilisation. Les cas d'utilisation représentent les fonctionnalités d'un système, ou d'une entité d'un système, telles qu'elles sont sollicitées en interaction avec des événements extérieurs. Ils donnent une vision "haute" et dynamique du système.
2.2 Éléments graphiques d’un diagramme de cas d’utilisation
Acteur : un bonhomme ou une classe stéréotypée <<actor>>. Son rôle est décrit sous ses pieds.
Cas d'utilisation : une ellipse. Le nom du cas d'utilisation est placé généralement en dessous de l'ellipse.
Association : il s’agit de montrer la participation d'un acteur à un cas d'utilisation par un trait plein pouvant être orienté ou NON.
Figure 2.1 Modèle de Cas d’utilisation.
Exemple :
Figure 2.2 Cas d’utilisation : Gestion de Bibliothèque (Bauchet 2015).
2.3 Formalisme de diagramme de cas d’utilisation
2.3.1 Identifier les acteurs
Un acteur peut être humain ou purement informatique, hardware ou software. Un acteur est un élément pouvant communiquer avec le système étudié, extérieur au système étudié, qui joue un rôle dans le système. Il peut avoir de multiples "personnalités", jouer plusieurs rôles dans un ou plusieurs cas d'utilisation.
Acteur non humain
Acteur non humain
Remarque : Il ne faut pas confondre acteur et individu-utilisateur. Notons qu’un individu utilisateur peut avoir plusieurs rôles donc être représentatif de plusieurs acteurs.
Exemple
Domaine : site Internet d’achat de billets de transport.
Cas d’utilisation : réserver un billet.
Acteurs Internaute, serveur de la société de transport
Figure 2.3 Cas d’utilisation : réservation de billet.
2.3.2 formaliser les cas d’utilisation
Regroupe dans une vue synthétique les acteurs et les liens s’ils interagissent avec des cas d’utilisation. Les cas d’utilisation sont des abstractions du dialogue entre les acteurs et le système. Ils n’entrent pas dans le détail de chaque scénario.
L’ensemble de cas d’utilisation contenus dans le cadre constitue « «un sujet »
Figure 2.4.A Modèle de gestion de la bibliothèque.
Gestion de Bibliothèque
Etudiant
Figure 2.4.B Modèle de gestion de la bibliothèque étendu.
2.4 Relations et stéréotypes dans le diagramme de cas d’utilisation
UML propose trois types de relations standards entre cas d'utilisation, <<include>> , <<extend>> et la relation d’héritage qui peut être considéré comme une relation de généralisation ou de spécialisation. Les deux premières sont représentées par un stéréotype de dépendance, l'autre étant la relation de généralisation représentée en UML par une flèche creuse à pointe fermée.
2.4.1 Relation d’include
La relation d’inclusion de deux cas d’utilisation est notée par une dépendance stéréotypée « «include» ». L’inclusion exprime le fait qu’un cas d’utilisation comprend une séquence d’actions consécutives qu’il est possible de factoriser avec d’autres cas d’utilisation. Lorsque le système modélisé atteint une certaine taille, il est important de montrer les relations d’inclusion qui définissent alors des parties du système réutilisables par d’autres parties.
Figure 2.5 Relation d’include.
Gestion de Bibliothèque
A --------<<include>>-------> B signifie que A réalise forcément B au cours de son exécution. On utilise ce stéréotype lorsque que l'on souhaite factoriser un cas d'utilisation partagé par plusieurs autres cas d'utilisation.
Par exemple, une opération de retrait et une opération de transfert nécessitent toutes les deux une opération de vérification de l'identité du client.
Figure 2.6 Stéréotype <<include>>
2.4.2 Relation Extends
A <-------<<extends>>-------- B signifie que A réalise potentiellement B au cours de son exécution. Un cas d'utilisation peut déclarer des points d'extension (extension point). Un point d'extension localise un endroit (un point) unique dans le cas d'utilisation.
Figure 2.7 Stéréotype <<extends>>
C'est dans les limites de ce point que d'autres cas d'utilisation pourront étendre ( extend ) le comportement initial du cas d'utilisation. C'est un moyen pratique de mettre en avant une fonctionnalité optionnelle.
Figure 2.8 Exemple d’utilisation du Stéréotype <<extends>> (Bauchet 2015)
2.4.3 Relation d’héritage (généralisation et spécialisation)
Une relation de généralisation d'un cas d'utilisation B vers un cas d'utilisation A signifie que B est une spécialisation de A. Contrairement aux deux autres relations, la relation de généralisation n'est pas un stéréotype. Elle indique qu'un cas d'utilisation est une variation d'un autre.
Figure 2.9 Relation d’héritage
Par exemple dans le cas d’utilisation "Retirer de l'argent", si il s’agit de retirer de l’argent sur un compte sur livret le comportement des deux cas d’utilisation peut être tout à fait différent.
Figure 2.10 Relation de généralisation
2.5 Rédaction de cas d’utilisation selon le Formlulaire de Cockburn
Pour rédiger un cas d’utilisation, nous avons besoins de préciser en premier lieu le titre du cas d’utilisation. Un cas d'utilisation (use case) commence toujours par un verbe décrivant une action. (Retirer de l’argent, emprunter un livre ….).
Il est ici inutile de préciser tous les processus techniques menant aux actions, il suffit de les modéliser en langage simple et compréhensible. Les cas d'utilisation seront modélisés par des développeurs sous forme technique dans une seconde étape. Nous nous référons dans cette partie du cours aux travaux d’Alistair Cockburn (Cockburn, 2001). L'idée est de fournir un format de présentation textuelle à la fois simple et riche du cas d’utilisation. Ce formulaire sert comme un guide méthodique de rédaction de cas d’utilisation. Nous nous basons dans ce qui suit sur l’exemple de système de gestion de bibliothèque pour montrer comment suivre les rubriques de cockburn afin de les utiliser prochainement dans les futurs projets.
2.5.1 Rubriques de Cockburn
• Titre, Résumé, Acteurs • Préconditions • Action départ • Liste des actions • Action d’arrêt • Postconditions • Exceptions • Remarques ergonomiques, Contraintes NF
2.5.2 Exemple Domaine :
Système de gestion d’une bibliothèque (Bauchet 2015)
Titre: Emprunter ouvrage.
Résumé: Liste des actions réalisées par un étudiant se présentant pour emprunter un ouvrage dans la bibliothèque.
Acteurs : Etudiant (E), Hôtesse (H)
Pré-condition(s):
- L’étudiant est inscrit à la bibliothèque - L’étudiant a trouvé son ouvrage dans les rayons de la bibliothèque
Déclencheur: 0. L’étudiant souhaite emprunter le livre qu’il a en main
Action de fin:
10. E quitte l’accueil avec son ouvrage.
Post-condition(s):
- L’ouvrage n’est plus disponible pour un autre prêt.
Exceptions:
Exception A : L’ouvrage a été réservé
- signale la non-disponibilité de l’ouvrage, - invite l’étudiant à revenir à la date d’expiration de l’emprunt.
Exception B :
- La carte n’est pas valide ou l’étudiant est banni pour quelques jours car il a rendu son précédent emprunt trop tard.
- précise les causes du refus de prêt
Remarques ergonomiques : on pourra utiliser un lecteur de code barre pour récupérer les coordonnées de l’ouvrage.
Contraintes non fonctionnelles
2.6 Conclusion
Nous avons présenté dans ce chapitre le diagramme de cas d’utilisation et son importance dans le recueil, d’analyse et d’organisation des besoins. Nous avons également vu que la description d’un cas d’utilisation se fait par des scénarios qui définissent la suite logique des actions qui constituent ce cas. Cette séquence doit être représentée en se basant sur le formulaire de Cockburn. Notons qu’il est possible de définir des scénarios simples ou des scénarios plus détaillés faisant intervenir les variantes, les cas d’erreurs, etc.
Il est important de noter ici que la description détaillée des scénarios nécessite une représentation faisant apparaitre des détailles (conditions, boucle, l’enchainement d’actions de haut niveau…) que le cas d’utilisation ne les représente pas ; et il faut donc utiliser le diagramme d’activité pour les représenter. Nous présentons dans le chapitre suivant le diagramme d’activité.
Chapitre III : Diagramme d’activité
3.1 Introduction
A la différence du cas d’utilisation qui montre ce que fait ou doit faire le système ; Un diagramme d’activité permet de montrer l’enchaînement des activités d’un système ou même d’une opération. Le diagramme d’activité représente le flot de contrôle qui retrace le fil d’exécution et qui transite d’une activité à l’autre dans le système. Dans la pratique, les diagrammes d’activité sont bien adaptés à cette phase de l’analyse qui consiste en l’expression des processus métier comme un ensemble d’actions coordonnées pour atteindre un but. Dans ce sens il est comme un organigramme.
L’avantage d’un diagramme d’activité par rapport à un simple organigramme réside dans le fait de son pouvoir d’expliciter des activités parallèles et leur synchronisation. Le diagramme d’activité est utilisé surtout pour modéliser un workflow dans un ou plusieurs cas d’utilisation. Le diagramme d’activité est le plus approprié pour modéliser la dynamique d’une tâche ou d’un groupe de tâches.
3.2 Eléments graphiques de diagramme d’activité
Figure 3.1.A Diagramme d’activité (Audibert 2009).
Figure 3.1.B Représentation graphique des nœuds d'activité
Le premier type de losange est appelée une décision et simule le début d’une instruction « si-alors ». Les conditions sont appelées des gardes. Le second type de losange signifie la fusion des branches à la fin du « si-alors » (voir l’exemple d’utilisation des losanges dans la figure 3.2). Il faut penser aux situations de blocage, pour ce fait les conditions doivent être complètes pour éviter que l’activité ne soit bloquée ou gelée indéfiniment parce qu’aucune des conditions n’est valide.
Exemple :
Une activité débute par un nœud initial représenté par un disque noir. Cette action marque le début de l’activité et est suivi d’arêtes représentant le passage à l’action suivante. Le nœud terminal ou final signifiant la fin de l’activité est représentée par un disque noir entouré d’un second disque. Entre les deux extrémités, les actions importantes du scénario sont reliées entre elles de façon à montrer le flot de l’activité : les enchaînements ou séquences et la concurrence (parallélisme).
L’exemple ci-dessous montre l’enchainement d’activités liées à la réception de commande.
Figure 3.2 Premier exemple d’un diagramme d’activité (Audibert 2009).
Il existe, en plus du nœud initial et nœud final, plusieurs types de nœuds de contrôle :
nœud de fin de flot (flow final node en anglais) ;
nœud de décision (decision node en anglais) ;
nœud de fusion (merge node en anglais) ;
nœud de bifurcation (fork node en anglais) ;
nœud d'union (join node en anglais). 3.3 Formalisme d’un diagramme d’activité
Les modèles de diagrammes d’activité servent d’abord à expliquer le fonctionnement d’un système, en fournissant une vision abstraite de son fonctionnement. L’objectif est de donner une description informelle permettant d’aller jusqu’à décrire le système à un niveau de détail qui permet de montrer son exécution. Uml est doté d’un mécanisme offrant la possibilité de décrire les actions sans entrer dans les détails du langage de programmation.
Les actions sont des étapes discrètes à partir desquelles se construisent les comportements. La notion d'action est à rapprocher de la notion d'instruction élémentaire d'un langage de programmation (comme C++ ou Java). Selon (Audibert 2009). Une action peut être, par exemple :
une affectation de valeur à des attributs ;
un accès à la valeur d'une propriété structurelle (attribut ou terminaison d'association) ;
la création d'un nouvel objet ou lien ;
un calcul arithmétique simple ;
l'émission d'un signal ;
la réception d'un signal ;
…
Nous décrivons ci-dessous les types d'actions les plus courants prédéfinis dans la notation UML.
Action appeler ( call operation )
L'action call operation correspond à l'invocation d'une opération sur un objet de manière synchrone ou asynchrone. Lorsque l'action est exécutée, les paramètres sont transmis à l'objet cible. Si l'appel est asynchrone, l'action est terminée et les éventuelles valeurs de retour seront ignorées. Si l'appel est synchrone, l'appelant est bloqué pendant l'exécution de l'opération et, le cas échéant, les valeurs de retour pourront être réceptionnées.
Action comportement ( call behavior )
L'action call behavior est une variante de l'action call operation car elle invoque directement une activité plutôt qu'une opération.
Action envoyer ( send )
Cette action crée un message et le transmet à un objet cible, où elle peut déclencher un comportement. Il s'agit d'un appel asynchrone (i.e. qui ne bloque pas l'objet appelant) bien adapté à l'envoi de signaux (send signal).
Action accepter événement ( accept event )
L'exécution de cette action bloque l'exécution en cours jusqu'à la réception du type d'événement spécifié, qui généralement est un signal. Cette action est utilisée pour la réception de signaux asynchrones.
Action accepter appel ( accept call )
Il s'agit d'une variante de l'action accept event pour les appels synchrones.
Action répondre ( reply )
Cette action permet de transmettre un message en réponse à la réception d'une action de type accept call.
Action créer ( create )
Cette action permet d'instancier un objet.
Action détruire ( destroy )
Cette action permet de détruire un objet.
Action lever exception ( raise exception )
Cette action permet de lever explicitement une exception.
Figure 3.3 Représentation des actions dans le diagramme d’activité (Audibert 2009).
3.4 Flot de contrôle et synchronisation dans le diagramme d’activité
Les actions qui se déroulent en même temps sont dites concurrentes. Elles sont modélisées entre deux traits épais comme des chemins parallèles. Les séquences d’actions en parallèle débutent en même temps, sont toutes exécutées, mais par définition ne finissent pas au même instant. La fin de l’action join intervient lorsque toutes les actions en parallèle se terminent ; join est donc un point de synchronisation.
Il est possible de synchroniser les transitions à l'aide des "barres de synchronisation". Une barre de synchronisation permet d'ouvrir et de fermer des branches parallèles au sein d'un flot d'exécution :
- Les transitions qui partent d'une barre de synchronisation ont lieu en même temps. - On ne franchit une barre de synchronisation qu'après réalisation de toutes les
transitions qui s'y rattachent.
Figure 3.4 la synchronisation dans le diagramme d’activité.
3.4.1 Synchronisation disjonctive (embranchement)
Un embranchement est la décomposition du flux de contrôle en deux ou plusieurs flux de contrôle. Il permet de spécifier des activités concurrentes.
Figure 3.5 Synchronisation disjonctive (embranchement) dans le diagramme d’activité.
3.4.2 Synchronisation conjonctive (conjonction) :
Une jonction est la recomposition du flux de contrôle de deux ou plusieurs flux de contrôle en un seul.
- Un embranchement permet de spécifier la synchronisation d'activités concurrentes. - Les flux qui sortent d'un embranchement doivent balancer les flux qui entrent dans
la jonction correspondante.
Figure 3.6 Synchronisation conjonctive (conjonction) dans le diagramme d’activité
3.4.3 Les couloirs dans le diagramme d’activité
Les partitions appelées des couloire (Swimlanes en anglais) dans le diagramme d’activité sont généralement utilisés pour organiser un diagramme d'activités. Il s’agit de définir des "couloirs d'activités" selon les différents responsables des actions représentées. Les couloirs sont un genre de paquet pour la responsabilité d'organisation des activités dans une classe. Un diagramme d'activité peut être divisé visuellement en des lignes solides verticales des deux côtés. Chaque couloire représente la responsabilité d'une partie de l'activité globale, et peut par la suite être mis en application par un ou plusieurs objets.
Figure 3.7 Les couloires dans le diagramme d’activité.
3.4.4 Flux d’objet
Un flux d'objet représente la participation d'un objet dans un flux de contrôle.
- Les flux d'objets sont représentés par des relations de dépendance entre objets et états d'action ou d'activités.
- Les flux d'objets sont représentés par des flèches :
Figure 3.8.A. Flux d’objet dans le diagramme d’activité
Représentation des Pins d’entrée et de sortie sur une activité
Figure 3.8.B. Flux d’objet dans le diagramme d’activité
Exercice : Construire un diagramme d’activité représentant l’utilisation d’une cafetière électrique: 1. premier état : chercher du café ; 2. dernier état: servir du café.
Figure 3.9. Exemple du diagramme d’activité correspondant à l’utilisation de la cafetière
3.5 Conclusion Nous avons montré que le diagramme d’activité est utilisé dans la phase de conception afin d’offrir une description détaillée du diagramme de cas d’utilisation. Le diagramme d’activité offre une vue centrée sur les traitements. Cette vue permet de modéliser efficacement le cheminement de flots de contrôle et flots de données. L’objectif n’est pas certes de fixer complètement le choix d’implémentation, mais de fournir une vision abstraite de traitement. Par exemple, l’expression de mécanismes concurrents n’implique pas forcément le fait d’imposer une architecture parallèle spécifique.
Après avoir montré comment concevoir une vue permettant de visualiser les traitements, nous allons aborder dans le chapitre suivant le diagramme de classes qui montre la structure interne du système.
Chapitre IV : Diagramme de classes 4.1 Introduction ............................................................................................................. 29 4.2 Éléments graphiques d’un diagramme de classes ...................................................... 29 4.3 Formalisme d’un diagramme de classes ................................................................... 31 4.3.1 La multiplicité ................................................................................................. 31 4.3.2 Notion d’association ........................................................................................ 32 4.3.3 Association binaire et n-aire ............................................................................ 32 4.3.4 Association avec navigabilité et contraintes ..................................................... 33 4.3.5 Association dérivée .......................................................................................... 34 4.3.6 Classe-Association ........................................................................................... 35 4.4. Relations dans le diagramme de classes ................................................................... 36 4.4.1 Relation d’agrégation et de composition ......................................................... 36 4.4.2 Relation de dépendance ................................................................................. 37 4.4.3 Relation d’Héritage, généralisation et spécialisation ...................................... 37 4.5 Conclusion ................................................................................................................ 38
Chapitre IV :
Diagramme de classes
4.1 Introduction
Compte tenu de l’importance du diagramme de classes dans la modélisation orientée-objet, il est le seul diagramme obligatoire lors du processus de modélisation. Il permet de fournir une représentation abstraite des objets du système qui vont interagir pour réaliser les cas d'utilisation.
Notons qu'un même objet peut intervenir dans la réalisation de plusieurs cas d'utilisation. A la différence du diagramme d’activité qui offre une vue dynamique centrée sur les traitements, Il s'agit dans le diagramme de classes de représenter une vue statique du système, car on ne tient pas compte du facteur temporel dans le comportement du système.
Une classe peut être extraite des cas d’utilisation, par un analyste programmeur, et après analyse et factorisation opérées par un ingénieur de développement, peut être considérée comme valide et ajoutée dans le package correspondant. Pour distinguer ces étapes de modélisation, on doit ajouter au nom de la classe toutes les informations nécessaires.
Une classe est considérée comme un ensemble d’objets possédant même structure et même comportement. Une classe permet la description de la structure et du comportement des objets, c'est-à-dire les intentions de la classe. Elle est considérée comme un modèle à partir duquel les objets sont créés (instanciation).
Le diagramme de classes permet de modéliser les classes du système et leurs relations. Les principaux éléments de cette vue statique sont les classes, qui possèdent des attributs et des opérations, et leurs relations. Les relations entre classes peuvent être de différents types : l’association (binaire), la généralisation spécialisation ou héritage, l’agrégation, etc. Une association possède un sens de lecture du verbe la nommant, une navigabilité indiquant dans quel sens l’association peut être parcourue. Chaque extrémité de l’association possède un rôle spécifiant le rôle de la classe dans l’association par rapport à l’autre extrémité, ainsi qu’une multiplicité.
4.2 Éléments graphiques d’un diagramme de classes
Une classe est un concept abstrait représentant des éléments variés comme ( Audibert 2009):
des éléments concrets (ex. : des avions), des éléments abstraits (ex. : des commandes de marchandises ou services), des composants d'une application (ex. : les boutons des boîtes de dialogue), des structures informatiques (ex. : des tables de hachage), des éléments comportementaux (ex. : des tâches), etc.
Une classe est un classeur. Elle est représentée par un rectangle divisé en trois à cinq compartiments. Le premier indique le nom de la classe, le deuxième ses attributs et le troisième ses opérations. Un compartiment des responsabilités peut être ajouté pour énumérer l'ensemble de tâches devant être assurées par la classe, mais pour lesquelles on ne dispose pas encore assez d'informations. Un
compartiment des exceptions peut également être ajouté pour énumérer les situations exceptionnelles devant être gérées par la classe.
Figure 4.1. Diagramme de classes.
Le nom de la classe doit évoquer le concept décrit par la classe. Il commence par une majuscule. On peut ajouter des informations subsidiaires comme le nom de l'auteur de la modélisation, la date, etc. Pour indiquer qu'une classe est abstraite, il faut ajouter le mot-clef abstract.
On peut ajouter aux méthodes définies sur les classes un ensemble de contraintes (types ou propriété). Le type du paramètre peut être un nom de classe, un nom d'interface ou un type de donnée prédéfini. Les propriétés correspondent à des contraintes ou à des informations complémentaires comme les exceptions, les préconditions, les postconditions ou encore l'indication qu'une méthode est abstraite (mot-clef abstract), etc.
Notons qu’un principe de conception important dans la modélisation objet consiste à protéger le cœur d’un système des accès intempestifs venant de l’extérieur. C’est le principe de coffre-fort appelé principe d’encapsulation en modélisation objet : seuls les détenteurs d’une clé peuvent l’ouvrir. UML définit quatre niveaux d’encapsulation d’une propriété d’une classe :
- Le mot clé Public ou le caractère + : propriété ou classe visible partout - Aucun caractère, ni mot clé : propriété ou classe visible uniquement dans le paquetage où la
classe est définie. - Le mot clé Protected ou le caractère # : propriété ou classe visible dans la classe et par tous
ses descendants. - Le mot clé Private ou le caractère - : propriété ou classe visible uniquement dans la classe.
Les attributs dérivés peuvent être calculés à partir d'autres attributs et de formules de calcul. Lors de la conception, un attribut dérivé peut être utilisé comme marqueur jusqu'à ce que vous puissiez déterminer les règles à lui appliquer.
Les attributs dérivés sont symbolisés par l'ajout d'un « / » devant leur nom.
Figure 4.2. Attribut dérivé d’une classe (Coan et al 2015).
4.3 Formalisme d’un diagramme de classes
Les classes sont les éléments de base d’un diagramme de classes. Une application nécessite sans doute la modélisation de plusieurs classes. Après avoir identifié les classes dont on a besoin, il convient de les relier entre elles. Les relations entre classes expriment le lien sémantique ou structurel. Les relations les plus utilisées sont l’association, l’agrégation, la composition, la dépendance et l’héritage.
4.3.1 La multiplicité
La multiplicité est définie par un ensemble non vide d’entiers positifs à l’exclusion d’un ensemble ne contenant que zéro {0}. Elle apparaît à chaque extrémité d’une relation et indique le nombre d’objets de la classe apparaissant à cette extrémité pouvant s’associer à un seul et unique objet de la classe apparaissant dans l’autre extrémité.
Exemple : Un objet de la classe Voiture est composé d’au moins trois roues et d’au plus dix roues. Et chaque roue se compose d’un seul pneu et d’une seule jante.
Figure 4.3. Multiplicité.
3..10
4.3.2 Notion d’association
Figure 4.4. Notion d’association.
Dans la première version (figure 4.4), l'association apparaît clairement et constitue une entité distincte. Dans la seconde, l'association se manifeste par la présence de deux attributs dans chacune des classes en relation. C'est en fait la manière dont une association est généralement implémentée dans un langage objet quelconque, mais pas dans tout langage de représentation.
La question de savoir s'il faut modéliser les associations en tant que telles a longtemps fait débat. UML a tranché pour la première version, car elle se situe plus à un niveau conceptuel (par opposition au niveau d'implémentation) et simplifie grandement la modélisation d'associations complexes (comme les associations plusieurs à plusieurs par exemple).
4.3.3 Association binaire et n-aire
Figure 4.5. Association binaire.
Une association binaire est matérialisée par un trait plein entre les classes associées. Elle peut être ornée d'un nom, avec éventuellement une précision du sens de lecture. Quand les deux extrémités de l'association pointent vers la même classe, l'association est dite réflexive (Solnon 2015 ).
Une personne travail pour une et une seule entreprise. L’entreprise emploie au moins une personne. L’entreprise est l’employeur des personnes qui travaillent pour elle et une personne a un statut d’employé dans l’entreprise.
Figure 4.6. Association n-aire.
Une association n-aire lie plus de deux classes. Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque classe s'applique sur une instance de chacune des classes, à l'exclusion de la classe-association et de la classe considérée. En effet, une multiplicité minimale de 1 (ou plus) sur une extrémité implique qu'il doit exister un lien (ou plus) pour TOUTES les combinaisons possibles des instances des classes situées aux autres extrémités de l'association n-aire. On représente une association n-aire par un grand losange avec un chemin partant vers chaque classe participante. Le nom de l'association, le cas échéant, apparaît à proximité du losange.
4.3.4 Association avec navigabilité et contraintes
Une association entre deux classes indique que les propriétés sont échangées ou partagées par les classes reliées. L’ajout de contraintes à une association ou bien entre associations apporte plus d’information car cela permet de mieux préciser la portée et le sens de l’association. La navigabilité indique s'il est possible de traverser une association. On représente graphiquement la navigabilité par une flèche du côté de l’extrémité navigable et on empêche la navigabilité par une croix du côté de l’extrémité non navigable. Par défaut, une association est navigable dans les deux sens.
Par exemple, sur la figure ci-dessous, l’extrémité du côté de la classe Commande n'est pas navigable : cela signifie que les instances de la classe Produit ne stockent pas de liste d'objets du type Commande. Inversement, l’extrémité du côté de la classe Produit est navigable : chaque objet commande contient une liste de produits.
Figure 4.7.A Navigabilité
Figure 4.7.B Notations ayant la même sémantique.
Lorsque l'on représente la navigabilité uniquement sur l'une des extrémités d'une association, il faut remarquer que, implicitement, les trois associations représentées sur la figure ont la même signification : l'association ne peut être traversée que dans un sens.
Figure 4.8. Navigabilité et contraintes.
Dans la figure ci-dessus, un polygone est défini par un ensemble de points jouant le rôle de sommets. Les sommets du polygone ne sont accessibles que par la classe et par ses descendants. La navigabilité est possible uniquement du polygone vers les points.
L’ajout de l’attribut sommets dans la classe Polygone permet de modéliser l’association entre les classes Polygone et Point et mettre en évidence la navigabilité de la relation.
4.3.5 Association dérivée
Une association dérivée est une association qui peut se déduire d’une asscociation existante ; elle est donc conditionnée ou peut être déduite à partir d’une autre association. Graphiquement, une association dérivée est symbolisée par l’ajout d’un slash avant le nom de l’association. Dans la figure ci-dessous, l’asssociation dérivée /emploie indique que la personne qui travail dans une entreprise est la même que celle associée à l’une des ses services.
Figure 4.9. Association dérivée.
4.3.6 Classe-Association
Parfois, une association doit posséder des propriétés qui ne sont disponible dans aucune des classes qu’elle lie. Comme, dans le modèle objet, seules les classes peuvent avoir des propriétés, cette association devient alors une classe appelée « Classe-Association ».
Par exemple, l'association Emploie entre une société et une personne possède comme propriétés le salaire et la date d'embauche. En effet, ces deux propriétés n'appartiennent ni à la société, qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il s'agit donc bien de propriétés de l'association Emploie. Les associations ne pouvant posséder de propriété, il faut introduire un nouveau concept pour modéliser cette situation : celui de classe-association.
Une classe-association possède les caractéristiques des associations et des classes : elle se connecte à deux ou plusieurs classes et possède également des attributs et des opérations.
Une classe-association est caractérisée par un trait discontinu entre la classe et l'association qu'elle représente.
Figure 4.10. Classe-association.
Notons qu’il n'est pas possible de rattacher une classe-association à plus d'une association puisque la classe-association constitue elle-même l'association. Dans le cas où plusieurs classe-associations doivent disposer des mêmes caractéristiques, elles doivent hériter d'une même classe possédant ces caractéristiques, ou l'utiliser en tant qu'attribut.
Qualification d’une association pour limiter son impacte sur les classes associées
Généralement, une classe peut être décomposée en sous-classes ou posséder plusieurs propriétés. Une telle classe rassemble un ensemble d'éléments (d'objets). Quand une classe est liée à une autre classe par une association, il est parfois préférable de restreindre la portée de l'association à quelques éléments ciblés (comme un ou plusieurs attributs) de la classe. Ces éléments ciblés sont appelés un qualificatif. Un qualificatif permet donc de sélectionner un ou des objets dans le jeu des objets d'un objet (appelé objet qualifié) relié par une association à un autre objet. L'objet sélectionné par la valeur du qualificatif est appelé objet cible. L'association est appelée association qualifiée. Un qualificatif agit toujours sur une association dont la multiplicité est plusieurs (avant que l'association ne soit qualifiée) du côté cible.
Un objet qualifié et une valeur de qualificatif génèrent un objet cible lié unique. En considérant un objet qualifié, chaque valeur de qualificatif désigne un objet cible unique.
L’objectif dans la figure ci-dessous est de modéliser l’association entre une personne et une banque. L’unique lien entre les deux est le fait de posséder au plus 2 comptes. La banque assure bien d’autres activités qui ne concernent pas le client. Pour mettre en évidence le fait que le lien entre la banque et une personne se limite à la possession de plusieurs compte, on ajoute une classe Compte qui représente la classe Banque dans l’association avec la classe Personne.
Figure 4.11. Une classe qualifiante est collée à la classe principale (Charroux et al 2005).
4..4 Relations dans le diagramme de classes
Après avoir présenté la structure du diagramme de classes et son formalisme en détaillant ses relations structurelles (Associations), nous allons présenter dans cette section les autres types de relation qui sont très utiles dans la modélisation objet.
4.4.1 Relation d’agrégation et de composition
Une agrégation est une forme particulière d’association. Elle représente la relation d’inclusion structurelle ou comportementale d’un élément dans un ensemble. Contrairement à l’association, l’agrégation est une relation transitive. Graphiquement, l’agrégation se distingue d’une association par l’ajout d’un losange vide du côté de l’agrégat.
La composition est une agrégation particulière. Cela signifie que toute composition peut être remplacée par une agrégation mais avec perte d’information. La relation de composition décrit une contenance structurelle entre instances. Ceci implique que l’élément composite est responsable de la création de la copie et de la destruction de ses composants. Dans la figure ci-dessous la tête est le tronc sont des composites d’un homme. Un homme peut très bien perdre une jambe ou un bras et donc la relation entre bras et jambe est une agrégation.
Figure 4.12. Agrégation et composition.
Banque #Comptee
Posséder 0..2 *
Client
Personne
4.4.2 Relation de dépendance
Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre des éléments du modèle. Elle est représentée par un trait discontinu orienté. Elle indique que la modification de la cible peut impliquer une modification de la source. La dépendance est souvent stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle.
On utilise souvent une dépendance quand une classe en utilise une autre comme argument dans la signature d'une opération. Par exemple, le diagramme de la figure ci-dessous montre que la classe Confrontation utilise la classe Stratégie, car la classe Confrontation possède une méthode confronter dont deux paramètres sont du type Stratégie. Si la classe Stratégie, notamment son interface, change, alors des modifications devront également être apportées à la classe Confrontation.
Figure 4.13. Relation de dépendance (Audibert 2009).
4.4.3 Relation d’Héritage, généralisation et spécialisation
La généralisation décrit une relation entre une classe générale (classe de base ou classe parent) et une classe spécialisée (sous-classe). La classe spécialisée est intégralement cohérente avec la classe de base, mais comporte des informations supplémentaires (attributs, opérations, associations). Un objet de la classe spécialisée peut être utilisé partout où un objet de la classe de base est autorisé.
Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de généralisation se traduit par le concept d'héritage. On parle également de relation d'héritage. Ainsi, l'héritage permet la classification des objets.
Le symbole utilisé pour la relation d'héritage ou de généralisation est une flèche avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus général.
Les propriétés principales de l'héritage sont :
la classe enfant possède toutes les caractéristiques de ses classes parents, mais elle ne peut accéder aux caractéristiques privées de cette dernière ;
une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la classe parent. Sauf indication contraire, un objet utilise les opérations les plus spécialisées dans la hiérarchie des classes ;
toutes les associations de la classe parent s'appliquent aux classes dérivées ; l’héritage multiple concerne le fait qu’une classe fille peut avoir plus d’une classe mère.
Figure 4.13. Relation d’héritage.
4.5 Conclusion
Nous avons commencé, dans ce chapitre par la définition de la notion de classe qui adopte un niveau élevé d’abstraction afin de modéliser d’une façon concise un ensemble d’objets. Nous avons présenté dans le formalisme de diagramme de classes la notion d’association afin de faciliter la compréhension de la modélisation d’un diagramme de classes en utilisant uniquement des associations. Nous avons ensuite présenté les autres types de relations et leurs différences qui permettent de modéliser la diversité des cas rencontrés lors de la modélisation objet.
La concrétisation du modèle de classes nécessite de définir le diagramme d’objets qui permet de présenter les liens concrets entre les entités généralisées dans le diagramme de classes. Nous allons border dans le chapitre suivant le diagramme d’objet et présenter la manière de concrétiser le diagramme de classes afin d’arriver à la phase d’implémentation.
Chapitre V : Diagramme d’objets
5.1 Introduction ............................................................................................................. 39 5.2 Éléments graphiques d’un diagramme d’objets ....................................................... 39 5.3 Formalisme d’un diagramme d’objets ...................................................................... 40 5.3.1 Constructeur et destructeur d’objets .............................................................. 40 5.3.2 Durée de vie d’un Objet .................................................................................. 40 5.3.3 Objet Composite ............................................................................................. 41 5.3.4 Les contraintes dans le diagramme d’objets .................................................... 41 5.3.5 Le langage de contrainte OCL ......................................................................... 43 5.4 Implémentation en java ............................................................................................ 44 5.4.1 Implémentation de la relation bidirectionnelle 1-1.......................................... 45 5.4.2 Implémentation de la relation bidirectionnelle 1-N .......................................... 46 5.4.3 Implémentation de la relation unidirectionnelle 1-N ........................................ 46 5.4.4 Implémentation de la relation unidirectionnelle 1-1 ........................................ 47 5.5 Conclusion ................................................................................................................. 47
Chapitre V :
Diagramme d’objets
5.1 Introduction
Le diagramme d’objets permet la représentation d’une instanciation du diagramme de classes en représentant les objets (i.e. instances de classes) et leurs liens (i.e. instances de relations). Un diagramme d’objets peut être utilisé pour illustrer le modèle de classes en montrant un exemple qui explique le modèle en précisant certains aspects du système. Il s’agit de mettre en évidence des détails imperceptibles, qui ne sont pas modélisés, dans le diagramme de classes, par exemple l’expression d’une exception ou la prise d’une image (snapshot) d'un système à un moment donné.
Le diagramme de classes modélise les règles et le diagramme d’objets modélise des faits. Il permet de donner une vue figée de l'état d'un système à un instant donné. 5.2 Éléments graphiques d’un diagramme d’objets
La notation UML de l’objet est très simple. Un objet est un rectangle avec le nom de l’objet et le nom de la classe séparés par le signe « : » et soulignés. Le nom de l’objet est facultatif : sans nom d’objets, l’objet est dit « anonyme ». Lorsque deux classes sont reliées par deux associations, le nom de l’instance d’association dessinée doit être précisée pour lever l’ambiguïté. Les attributs reçoivent des valeurs. Quand certaines valeurs d'attribut d'un objet ne sont pas renseignées, on dit que l'objet est partiellement défini.
Figure 5.1. Instanciation d’un diagramme de classes (Audibert 2009).
L’objet entrep, modélise lui une entreprise particulière (PERTNE) qui emploie trois personnes. La relation de dépendance d'instanciation (stéréotypée << instanceof >>) décrit la relation entre un classeur et ses instances. Elle relie, en particulier, les liens aux associations et les objets aux classes. Dans un diagramme d’objets, les relations du diagramme de classes deviennent des liens. La relation de généralisation ne possède pas d'instance, elle n'est donc jamais représentée dans un
diagramme d’objets. Graphiquement, un lien se représente comme une relation, mais, s'il y a un nom, il est souligné. Naturellement, on ne représente pas les multiplicités.
Par exemple, le diagramme de classes de la figure 5.1 montre qu'une entreprise emploie au moins deux personnes et qu'une personne travaille dans au plus deux entreprises. Le diagramme d’objets
Figure 5.2. Dépendance d'instanciation entre les classeurs et leurs instances (Charroux et al 2005).
5.3 Formalisme d’un diagramme d’objets
Un diagramme d’objets est particulièrement utile pour décrire comment les objets dans le système fonctionnent ensemble dans un scénario donné. Un diagramme d’objets représente une configuration donnée. Clairement, un diagramme d’objets doit respecter les contraintes d’un diagramme de classes : par exemple, ne pas tracer de liens entre deux objets dont les classes ne sont pas reliées dans le diagramme de classes.
5.3.1 Constructeur et destructeur d’objets
Un constructeur est une méthode d'instanciation et d'initialisation d’objets dans la mémoire. Le destructeur est une méthode de finalisation et de destruction de l’objet dans la mémoire. Toute classe a un constructeur et un destructeur par défaut, fournis par le compilateur. Les constructeurs et destructeurs appellent les constructeurs par défaut et les destructeurs des classes de base et des données membres de la classe. Leur redéfinition permet de gérer certaines actions qui doivent avoir lieu lors de la création d'un objet et de leur destruction. Par exemple, si l'objet doit contenir des variables allouées dynamiquement, il faut leur réserver de la mémoire à la création de l'objet ou au moins mettre les pointeurs correspondants à NULL. À la destruction de l'objet, il convient de restituer la mémoire allouée, s'il en a été alloué (Roques & Vallée 2003).
5.3.2 Durée de vie d’un Objet
Les objets ne sont pas des éléments statiques et leur durée de vie ne correspond pas forcément à la durée d'exécution du programme.
La durée de vie d'un objet passe par trois étapes :
la déclaration de l'objet et l'instanciation ;
l'utilisation de l'objet en appelant ses méthodes ;
la suppression de l'objet : elle se fait en utilisant le destructeur d’objets. Il est à noter qu’en java, cette étape est automatique grâce à la machine virtuelle. La restitution de la mémoire inutilisée est prise en charge par le récupérateur de mémoire (garbage collector).
5.3.3 Objet Composite
Un objet composite est constitué d'un ou de plusieurs objets similaires (ayant des fonctionnalités similaires). L'idée est de manipuler un groupe d’objets de la même façon que s'il s'agissait d'un seul objet. Les objets ainsi regroupés doivent posséder des opérations communes, c'est-à-dire un "dénominateur commun". Dans l’exemple ci-dessous un livre est constitué d’un N chapitres il est donc composite, la relation entre classes est une composition. Un objet livre est un objet composite.
Figure 5.3.A Objet Composite.
Figure 5.3.B Instanciation d’un objet Composite.
5.3.4 Les contraintes dans le diagramme d’objets
Une contrainte constitue une condition ou une restriction sémantique exprimée sous forme d'instruction dans un langage textuel qui peut être naturel ou formel. En général, une contrainte peut être attachée à n'importe quel élément de modèle ou liste d'éléments de modèle. Une contrainte désigne une restriction qui doit être appliquée par une implémentation correcte du système.
On représente une contrainte sous la forme d'une chaîne de texte placée entre accolades ({}). La chaîne constitue le corps écrit dans un langage de contrainte qui peut être :
naturel ; dédié, comme OCL ; ou encore directement issu d'un langage de programmation.
Si une contrainte possède un nom, on présente celui-ci sous forme d'une chaîne suivie d'un double point (:), le tout précédant le texte de la contrainte.
Figure 5.4. Représentation des contraintes.
La figure 5.4 présente quelques contraintes prédéfinies ({frozen}, {ordered} et {addonly}). Frozen précise que le nombre de payés dans lequel la personne est née ne peut pas varier ici nombre=1. Une personne ne peut naitre que dans un seul payé. Le addonly signifie que le payé est une instance que l’on peut ajouter mais on ne peut le retirer. Ordered signifie que les valeurs sont ordonnées. UML permet d'associer une contrainte à un, ou plusieurs, élément(s) (Audibert 2009) de modèle de différentes façons :
en plaçant directement la contrainte à côté d'une propriété ou d'une opération dans un classeur ;
en ajoutant une note associée à l'élément à contraindre ; en plaçant la contrainte à proximité de l'élément à contraindre, comme une extrémité
d'association par exemple ; en plaçant la contrainte sur une flèche en pointillés joignant les deux éléments de modèle à
contraindre ensemble, la direction de la flèche constituant une information pertinente au sein de la contrainte ;
en plaçant la contrainte sur un trait en pointillés joignant les deux éléments de modèle à contraindre ensemble dans le cas où la contrainte est bijective ;
en utilisant une note reliée, par des traits en pointillés, à chacun des éléments de modèle, subissant la contrainte commune, quand cette contrainte s'applique sur plus de deux éléments de modèle.
Le diagramme de la figure 5.4 introduit des nouvelles contraintes et montre comment les utiliser. La liste est encore longue, mais le pouvoir expressif de ces contraintes reste insuffisant et l’utilisation d’un langage de contraintes devient une véritable nécessité. Le langage de contraintes objet OCL apporte une solution élégante à cette insuffisance.
5.3.5 Le langage de contrainte OCL
C'est avec OCL (Object Constraint Language) qu'UML formalise l'expression des contraintes. Il s'agit donc d'un langage formel d'expression de contraintes bien adapté aux diagrammes d'UML, et en particulier au diagramme de classes.
OCL existe depuis la version 1.1 d'UML et est une contribution d'IBM. OCL fait partie intégrante de la norme UML depuis la version 1.3 d'UML. Dans le cadre d'UML 2.0, les spécifications du langage OCL figurent dans un document indépendant de la norme d'UML, décrivant en détail la syntaxe formelle et la façon d'utiliser ce langage.
Figure 5.5. Diagramme d’objets valide mais ne respectant parfaitement les spécifications.
La figure ci-dessus présente un diagramme d’objets valide vis-à-vis du diagramme de classes mais ne respecte pas la spécification attendue :
- Une personne a un compte dans une banque où elle n'est pas cliente - Une personne est cliente d'une banque mais sans y avoir de compte
OCL peut s'appliquer sur la plupart des diagrammes d'UML (Barbier et al 2005) et permet de spécifier des contraintes sur l'état d'un objet ou d'un ensemble d’objets comme :
les invariants doivent être respectés en permanence; les préconditions doivent être vérifiées avant l'exécution, les postconditions doivent être vérifiées après l'exécution ; des ensembles d’objets destinataires pour un envoi de message ; une expression OCL décrit une contrainte à respecter et pas le « code » d'une méthode.
Dans une contrainte OCL associée à un objet, on peut :
- Accéder à l'état interne de cet objet (ses attributs) - Naviguer dans le diagramme : accéder de manière transitive à tous les objets (et leur état)
avec qui il est en relation
L’usage d’OCL dans l’application bancaire peut être résumé comme suit (Cariou 2015) :
context Compte inv: propriétaire.age >= 18// Le propriétaire d'un compte doit avoir plus de 18 ans inv: solde > 0 // Pour toutes les instances de la classe Compte, l'attribut solde doit toujours être positif context Compte : débiter(somme : int) pre: somme > 0 //précondition solde >0 post: solde = solde@pre – somme // Postcondition : la somme à débiter doit être positive pour que l'appel de l'opération soit valide. Après l'exécution de l'opération, l'attribut solde doit avoir pour valeur la différence de sa valeur avant l'appel et de la somme passée en paramètre context Compte inv: banque.clients -> includes (propriétaire) // une personne ne peut avoir un compte dans une banque où elle n'est pas cliente et une personne est cliente d'une banque mais sans y avoir de compte
OCL propose un ensemble de primitives utilisables sur les ensembles : - size() : retourne le nombre d'éléments de l'ensemble - isEmpty() : retourne vrai si l'ensemble est vide - notEmpty() : retourne vrai si l'ensemble n'est pas vide - includes(obj) : vrai si l'ensemble inclut l'objet obj - excludes(obj) : vrai si l'ensemble n'inclut pas l'objet obj - …
5.4 Implémentation en java
Nous allons montrer comment implémenter une classe simple ainsi que l’instanciation de ces objets dans la classe main. Notons qu’on s’est basé sur les exemples d’implémentations présentés dans le livre de UML2 de l’apprentissage à la pratique de Laurent Audibert (Audibert 2009) .
Figure 5.6 exemple d’une classe A.
Code de la classe en java
public class A { public String a1; package String a2; protected String a3; private String a4; public void op1() { ... } public void op2() { ... } }
Instanciation de l’objet dans la fonction main
5.4.1 Implémentation de la relation bidirectionnelle 1-1
Figure 5.7 Relation bidirectionnelle 1-1.
… public static void main(String[] args){ A a = new A(); // instanciation de la classe A et l’objet instanciée exécutera automatiquement le constructeur. } …
public class A { private B rb; public void addB( B b ) { if( b != null ){ if ( b.getA() != null ) { // si b est déjà connecté à un autre A b.getA().setB(null); // cet autre A doit se déconnecter } this.setB( b ); b.setA( this ); } } public B getB() { return( rb ); } public void setB( B b ) { this.rb=b; } } public class B { private A ra; public void addA( A a ) { if( a != null ) { if (a.getB() != null) { // si a est déjà connecté à un autre B a.getB().setA( null ); // cet autre B doit se déconnecter } this.setA( a ); a.setB( this ); } } public void setA(A a){ this.ra=a; } public A getA(){ return(ra); } }
5.4.2 Implémentation de la relation bidirectionnelle 1-N
Figure 5.8 Relation bidirectionnelle 1-N.
5.4.3 Implémentation de la relation unidirectionnelle 1-N
Figure 5.9 Relation unidirectionnelle 1-N.
public class A { private ArrayList <B> rb; public A() { rb = new ArrayList<B>(); } public ArrayList <B> getArray() {return(rb);} public void remove(B b){rb.remove(b);} public void addB(B b){ if( !rb.contains(b) ){ if (b.getA()!=null) b.getA().remove(b); b.setA(this); rb.add(b); } } } public class B { private A ra; public B() {} public A getA() { return (ra); } public void setA(A a){ this.ra=a; } public void addA(A a){ if( a != null ) { if( !a.getArray().contains(this)) { if (ra != null) ra.remove(this); this.setA(a); ra.getArray().add(this); } } }
}
public class A { private ArrayList <B> rb; public A() { rb = new ArrayList<B>(); } public void addB(B b){ if( !rb.contains( b ) ) { rb.add(b); } } } public class B { ... // B ne connaît pas l'existence de A
}
5.4.4 Implémentation de la relation unidirectionnelle 1-1
Figure 5.10 Relation unidirectionnelle 1-1.
5.5 Conclusion
Nous avons présenté dans ce chapitre le diagramme d’objets qui représente une ou plusieurs instanciations du diagramme de classes pour faciliter la validation de celui-ci. Nous avons vu qu’un diagramme d’objets représente un état du système en utilisant l’ensemble des contraintes prédéfinies. Ces contraintes doivent être formulées en utilisant le langage OCL. Nous avons montré que l’utilisation d’OCL permet d’organiser le travail.
Ce chapitre a montré comment implémenter le diagramme de classes afin de s’orienter sur le point de vue implémentation. L’objectif était de présenter des exemples de contenu d’implémentation facilitant la compréhension du diagramme d’objets et son utilisation dans le système. Un diagramme
d’objets donc ne montre pas l'évolution du système dans le temps. Pour représenter ce fait, en se basant sur les interactions au fil du temps, il faut utiliser le diagramme d’interaction. Le chapitre suivant présentera le diagramme d’interaction.
public class A { private B rb; public void addB( B b ) { if( b != null ) { this.rb=b; } } } public class B { ... // La classe B ne connaît pas l'existence de la classe A }
