Institut Universitaire de Technologie de Villetaneuse – Département Informatique
Avenue Jean-Baptiste Clément
93430 Villetaneuse
Adresse électronique : laurent[dot]audibert[at]iutv[dot]univ-paris13[dot]fr
Adresse du document : http://www-lipn.univ-paris13.fr/ audibert/pages/enseignement/cours.htm
Les techniques de programmation n’ont cessé de progresser depuis l’époque de la programmation en langage binaire (cartes perforées, switch) à nos jours. Cette évolution a toujours été dictée par le besoin de concevoir et de maintenir des applications toujours plus complexes.
La programmation par cartes perforées, switch ou câblage (de 1800 à 1940) a ainsi fait place à des techniques plus évoluées, comme l’assembleur (1947), avec l’arrivée de l’ordinateur électronique né des besoins de la guerre. Des langages plus évolués ont ensuite vu le jour comme Fortran en 1956 ou Cobol en 1959. Jusque là, les techniques de programmation étaient basées sur le branchement conditionnel et inconditionnel (goto) rendant les programmes importants extrêmement difficiles à développer, à maîtriser et à maintenir.
La programmation structurée (Pascal en 1970, C en 1972, Modula et Ada en 1979, …) a alors vu le jour et permis de développer et de maintenir des applications toujours plus ambitieuses. L’algorithmique ne se suffisant plus à elle seule à la fin des années 1970, le génie logiciel est venu placer la méthodologie au cœur du développement logiciel. Des méthodes comme Merise (1978) se sont alors imposées.
La taille des applications ne cessant de croître, la programmation structurée a également rencontré ses limites, faisant alors place à la programmation orientée objet (Simula 67 en 1967, Smalltalk en 1976, C++ en 1982, Java en 1995, …). La technologie objet est donc la conséquence ultime de la modularisation dictée par la maîtrise de la conception et de la maintenance d’applications toujours plus complexes. Cette nouvelle technique de programmation a nécessité la conception de nouvelles méthodes de modélisation.
UML (Unified Modeling Language en anglais, soit langage de modélisation objet unifié) est né de la fusion des trois méthodes qui s’imposaient dans le domaine de la modélisation objet au milieu des années 1990 : OMT, Booch et OOSE. D’importants acteurs industriels (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) s’associent alors à l’effort et proposent UML 1.0 à l’OMG (Object Management Group) qui l’accepte en novembre 1997 dans sa version 1.1. La version d’UML en cours en 2008 est UML 2.1.1 qui s’impose plus que jamais en tant que langage de modélisation standardisé pour la modélisation des logiciels.
Ce document constitue le support du cours d’UML 2 dispensé aux étudiants du département d’informatique de l’institut universitaire de technologie (IUT) de Villetaneuse en semestre décalé.
Ce support a été réalisé en utilisant les ouvrages cités en bibliographie. Il est en partie basé sur le livre de [7] qui constitue une bonne introduction au langage UML. Aomar Osmani est à l’origine du cours d’UML dans notre IUT.
[27], [5], [3] [26] et [16] ont également été largement utilisés. [27] est un ouvrage de référence assez complet et contient un dictionnaire détaillé de la terminologie UML 2.0. [5], également écrit par les créateurs du langage UML, est un guide d’apprentissage complétant bien le premier ouvrage. [16] est un cours d’UML 2.0 bien expliqué et plus complet et détaillé que [7] mais, en contrepartie, moins accessible. [3] constitue une approche pratique et critique d’UML très intéressante. [25] constitue une excellente approche concrète d’UML comportant des exercices corrigés de très bonne facture que nous reprenons parfois dans les travaux dirigés de ce cours. Pascal Roques est probablement l’un des auteurs les plus prolifique [23, 26, 24, 25] et compétant concernant la mise en œuvre d’UML.
Agréable à lire, [28] s’intéresse à la place de l’informatique dans notre société et plus particulièrement dans l’entreprise.
Enfin, diverses sources trouvées sur Internet, inépuisable source d’information en perpétuel renouvellement, m’ont également été d’un grand secours. Parmi ces dernières, certaines sont incontournables, comme le cours de [21] ou encore le site [9].
L’informatisation est le phénomène le plus important de notre époque. Elle s’immisce maintenant dans la pluspart des objets de la vie courante et ce, que ce soit dans l’objet proprement dit 1, ou bien dans le processus de conception ou de fabrication de cet objet.
Actuellement, l’informatique est au cœur de toutes les grandes entreprises. Le système d’information d’une entreprise est composé de matériels et de logiciels. Plus précisément, les investissements dans ce système d’information se réparatissent généralement de la manière suivante : 20% pour le matériel et 80% pour le logiciel. En effet, depuis quelques années, la fabrication du matériel est assurée par quelques fabricants seulement. Ce matériel est relativement fiable et le marché est standardisé. Les problèmes liés à l’informatique sont essentiellement des problèmes de logiciel.
Un logiciel ou une application est un ensemble de programmes, qui permet à un ordinateur ou à un système informatique d’assurer une tâche ou une fonction en particulier (exemple : logiciel de comptabilité, logiciel de gestion des prêts).
Les logiciels, suivant leur taille, peuvent être développés par une personne seule, une petite équipe, ou un ensemble d’équipes coordonnées. Le développement de grands logiciels par de grandes équipes pose d’importants problèmes de conception et de coordination. Or, le développement d’un logiciel est une phase absolument cruciale qui monopolise l’essentiel du coût d’un produit2 et conditionne sa réussite et sa pérennité.
En 1995, une étude du Standish Group dressait un tableau accablant de la conduite des projets informatiques. Reposant sur un échantillon représentatif de 365 entreprises, totalisant 8 380 applications, cette étude établissait que :
Pour les grandes entreprises (qui lancent proportionnellement davantage de gros projets), le taux de succès est de 9% seulement, 37% des projets sont arrêtés en cours de réalisation, 50% aboutissent hors délai et hors budget.
L’examen des causes de succès et d’échec est instructif : la plupart des échecs proviennent non de l’informatique, mais de la maîtrise d’ouvrage3 (i.e. le client). Pour ces raisons, le développement de logiciels dans un contexte professionnel suit souvent des règles strictes encadrant la conception et permettant le travail en groupe et la maintenance4 du code. Ainsi, une nouvelle discipline est née : le génie logiciel.
Le génie logiciel est un domaine de recherche qui a été défini (fait rare) du 7 au 11 octobre 1968, à Garmisch-Partenkirchen, sous le parrainage de l’OTAN. Il a pour objectif de répondre à un problème qui s’énonçait en deux constatations : d’une part le logiciel n’était pas fiable, d’autre part, il était incroyablement difficile de réaliser dans des délais prévus des logiciels satisfaisant leur cahier des charges.
L’objectif du génie logiciel est d’optimiser le coût de développement du logiciel. L’importance d’une approche méthodologique s’est imposée à la suite de la crise de l’industrie du logiciel à la fin des années 1970. Cette crise de l’industrie du logiciel était principalement due à :
La maintenance est devenue une facette très importante du cycle de vie d’un logiciel. En effet, une enquête effectuée aux USA en 1986 auprès de 55 entreprises révèle que 53% du budget total d’un logiciel est affecté à la maintenance. Ce coût est réparti comme suit :
Pour apporter une réponse à tous ces problèmes, le génie logiciel s’intéresse particulièrement à la manière dont le code source d’un logiciel est spécifié puis produit. Ainsi, le génie logiciel touche au cycle de vie des logiciels :
Les projets relatifs à l’ingénierie logicielle sont généralement de grande envergure et dépassent souvent les 10000 lignes de code. C’est pourquoi ces projets nécessitent une équipe de développement bien structurée. La gestion de projet se retrouve naturellement intimement liée au génie logiciel.
En génie logiciel, divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui dépendent, entre autres, du domaine de l’application et des outils utilisés. Parmi ces derniers nous pouvons citer :
Ces facteurs sont parfois contradictoires, le choix des compromis doit s’effectuer en fonction du contexte.
Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d’une entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, de l’expliquer ou de le prévoir. Modèle est synonyme de théorie, mais avec une connotation pratique : un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.
Concrètement, un modèle permet de réduire la complexité d’un phénomène en éliminant les détails qui n’influencent pas son comportement de manière significative. Il reflète ce que le concepteur croit important pour la compréhension et la prédiction du phénomène modélisé. Les limites du phénomène modélisé dépendant des objectifs du modèle.
Voici quelques exemples de modèles :
Les trois premiers exemples sont des modèles que l’on qualifie de prédictifs. Le dernier, plus conceptuel, possède différents niveaux de vues comme la pluspart des modèles en génie logiciel.
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence. Un modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle pour aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la maîtrise d’ouvrage et la maîtrise d’œuvre informatique) et précise d’un problème donné.
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches et d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des délais. Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour faire de la génération de code (au moins au niveau du squelette) voire des aller-retours entre le code et le modèle sans perte d’information. Le modèle est enfin indispensable pour assurer un bon niveau de qualité et une maintenance efficace. En effet, une fois mise en production, l’application va devoir être maintenue, probablement par une autre équipe et, qui plus est, pas nécessairement de la même société que celle ayant créée l’application.
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes non-triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles employés, la démarche de modélisation n’est pas la même.
La modélisation est souvent faite par la maîtrise d’œuvre informatique (MOE). C’est malencontreux, car les priorités de la MOE résident dans le fonctionnement de la plate-forme informatique et non dans les processus de l’entreprise.
Il est préférable que la modélisation soit réalisée par la maîtrise d’ouvrage (MOA) de sorte que le métier soit maître de ses propres concepts. La MOE doit intervenir dans le modèle lorsque, après avoir défini les concepts du métier, on doit introduire les contraintes propres à la plate-forme informatique.
Il est vrai que certains métiers, dont les priorités sont opérationnelles, ne disposent pas toujours de la capacité d’abstraction et de la rigueur conceptuelle nécessaires à la formalisation. La professionnalisation de la MOA a pour but de les doter de ces compétences. Cette professionnalisation réside essentiellement dans l’aptitude à modéliser le système d’information du métier : le maître mot est modélisation. Lorsque le modèle du système d’information est de bonne qualité, sobre, clair, stable, la maîtrise d’œuvre peut travailler dans de bonnes conditions. Lorsque cette professionnalisation a lieu, elle modifie les rapports avec l’informatique et déplace la frontière des responsabilités, ce qui contrarie parfois les informaticiens dans un premier temps, avant qu’ils n’en voient apparaître les bénéfices.
Le MOA est client du MOE à qui il passe commande d’un produit nécessaire à son activité.
Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou plusieurs fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.
La relation MOA et MOE est définie par un contrat qui précise leurs engagements mutuels.
Lorsque le produit est compliqué, il peut être nécessaire de faire appel à plusieurs fournisseurs. Le MOE assure leur coordination ; il veille à la cohérence des fournitures et à leur compatibilité. Il coordonne l’action des fournisseurs en contrôlant la qualité technique, en assurant le respect des délais fixés par le MOA et en minimisant les risques.
Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison au MOA, procéder aux vérifications nécessaires (« recette usine »).
Le cycle de vie d’un logiciel (en anglais software lifecycle), désigne toutes les étapes du développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, c’est-à-dire l’adéquation des méthodes mises en œuvre.
L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant plus élevé qu’elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.
Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes :
La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix d’un modèle de cycle de vie entre le client et l’équipe de développement. Le cycle de vie permet de prendre en compte, en plus des aspects techniques, l’organisation et les aspects humains.
Le modèle de cycle de vie en cascade (cf. figure 1.1) a été mis au point dès 1966, puis formalisé aux alentours de 1970.
Dans ce modèle le principe est très simple : chaque phase se termine à une date précise par la production de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à la phase suivante que s’ils sont jugés satisfaisants.
Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été rajoutée ultérieurement sur la base qu’une étape ne remet en cause que l’étape précédente, ce qui, dans la pratique, s’avère insuffisant.
L’inconvénient majeur du modèle de cycle de vie en cascade est que la vérification du bon fonctionnement du système est réalisée trop tardivement: lors de la phase d’intégration, ou pire, lors de la mise en production.
Le modèle en V (cf. figure 1.2) demeure actuellement le cycle de vie le plus connu et certainement le plus utilisé. Il s’agit d’un modèle en cascade dans lequel le développement des tests et du logiciels sont effectués de manière synchrone.
Le principe de ce modèle est qu’avec toute décomposition doit être décrite la recomposition et que toute description d’un composant est accompagnée de tests qui permettront de s’assurer qu’il correspond à sa description.
Ceci rend explicite la préparation des dernières phases (validation-vérification) par les premières (construction du logiciel), et permet ainsi d’éviter un écueil bien connu de la spécification du logiciel : énoncer une propriété qu’il est impossible de vérifier objectivement après la réalisation.
Cependant, ce modèle souffre toujours du problème de la vérification trop tardive du bon fonctionnement du système.
Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il met l’accent sur l’activité d’analyse des risques : chaque cycle de la spirale se déroule en quatre phases :
L’analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de développement classique.
Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus.
Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s’intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l’un des modèles précédents.
Les avantages de ce type de modèle sont les suivants :
Les risques de ce type de modèle sont les suivants :
Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.
Les méthodes d’analyse et de conception fournissent une méthodologie et des notations standards qui aident à concevoir des logiciels de qualité. Il existe différentes manières pour classer ces méthodes, dont :
Les méthodes fonctionnelles (également qualifiées de méthodes structurées) trouvent leur origine dans les langages procéduraux. Elles mettent en évidence les fonctions à assurer et proposent une approche hiérarchique descendante et modulaire.
Ces méthodes utilisent intensivement les raffinements successifs pour produire des spécifications dont l’essentielle est sous forme de notation graphique en diagrammes de flots de données. Le plus haut niveau représente l’ensemble du problème (sous forme d’activité, de données ou de processus, selon la méthode). Chaque niveau est ensuite décomposé en respectant les entrées/sorties du niveau supérieur. La décomposition se poursuit jusqu’à arriver à des composants maîtrisables (cf. figure 1.3).
L’approche fonctionnelle dissocie le problème de la représentation des données, du problème du traitement de ces données. Sur la figure 1.3, les données du problème sont représentées sur la gauche. Des flèches transversalles matérialisent la manipulation de ces données par des sous-fonctions. Cet accès peut-être direct (c’est parfois le cas quand les données sont regroupées dans une base de données), ou peut être réalisé par le passage de paramètre depuis le programme principal.
La SADT (Structured Analysis Design Technique) est probablement la méthode d’analyse fonctionnelle et de gestion de projets la plus connue. Elle permet non seulement de décrire les tâches du projet et leurs interactions, mais aussi de décrire le système que le projet vise à étudier, créer ou modifier, en mettant notamment en évidence les parties qui constituent le système, la finalité et le fonctionnement de chacune, ainsi que les interfaces entre ces diverses parties. Le système ainsi modélisé n’est pas une simple collection d’éléments indépendants, mais une organisation structurée de ceux-ci dans une finalité précise.
En résumé, l’architecture du système est dictée par la réponse au problème (i.e. la fonction du système).
L’approche orientée objet considère le logiciel comme une collection d’objets dissociés, identifiés et possédant des caractéristiques. Une caractéristique est soit un attribut (i.e. une donnée caractérisant l’état de l’objet), soit une entité comportementale de l’objet (i.e. une fonction). La fonctionnalité du logiciel émerge alors de l’interaction entre les différents objets qui le constituent. L’une des particularités de cette approche est qu’elle rapproche les données et leurs traitements associés au sein d’un unique objet.
Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d’objets, d’entités ayant une existence matérielle (chien, voiture, ampoule, personne, …) ou bien virtuelle (client, temps, …).
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures logicielles fondées sur les objets du système, plutôt que sur la fonction qu’il est censé réaliser.
En résumé, l’architecture du système est dictée par la structure du problème.
Selon la thèse de Church-Turing, tout langage de programmation non trivial équivaut à une machine de Turing. Il en résulte que tout programme qu’il est possible d’écrire dans un langage pourrait également être écrit dans n’importe quel autre langage. Ainsi, tout ce que l’on fait avec un langage de programmation par objets pourrait être fait en programmation impérative. La différence entre une approche fonctionnelle et une approche objet n’est donc pas d’ordre logique, mais pratique.
L’approche structurée privilégie la fonction comme moyen d’organisation du logiciel. Ce n’est pas pour cette raison que l’approche objet est une approche non fonctionnelle. En effet, les méthodes d’un objet sont des fonctions. Ce qui différencie sur le fond l’approche objet de l’approche fonctionnelle, c’est que les fonctions obtenues à l’issue de la mise en œuvre de l’une ou l’autre méthode sont distinctes. L’approche objet est une approche orientée donnée. Dans cette approche, les fonctions se déduisent d’un regroupement de champs de données formant une entité cohérente, logique, tangible et surtout stable quant au problème traité. L’approche structurée classique privilégie une organisation des données postérieure à la découverte des grandes, puis petites fonctions qui les décomposent, l’ensemble constituant les services qui répondent aux besoins.
En approche objet, l’évolution des besoins aura le plus souvent tendance à se présenter comme un changement de l’interaction des objets. S’il faut apporter une modification aux données, seul l’objet incriminé (encapsulant cette donnée) sera modifié. Toutes les fonctions à modifier sont bien identifiées : elles se trouvent dans ce même objet : ce sont ses méthodes. Dans une approche structurée, l’évolution des besoins entraîne souvent une dégénérescence, ou une profonde remise en question, de la topologie typique de la figure 1.3 car la décomposition des unités de traitement (du programme principal aux sous-fonctions) est directement dictée par ces besoins. D’autre part, une modification des données entraîne généralement une modification d’un nombre important de fonctions éparpillées et difficiles à identifier dans la hiérarchie de cette décomposition.
En fait, la modularité n’est pas antinomique de l’approche structurée. Les modules résultant de la décomposition objet sont tout simplement différents de ceux émanant de l’approche structurée. Les unités de traitement, et surtout leur dépendance dans la topologie de la figure 1.3 sont initialement bons. C’est leur résistance au temps, contrairement aux modules objet, qui est source de problème. La structure d’un logiciel issue d’une approche structurée est beaucoup moins malléable, adaptable, que celle issue d’une approche objet.
Ainsi la technologie objet est la conséquence ultime de la modularisation du logiciel, démarche qui vise à maîtriser sa production et son évolution. Mais malgré cette continuité logique les langages objet ont apporté en pratique un profond changement dans l’art de la programmation : ils impliquent en effet un changement de l’attitude mentale du programmeur.
Dans la section 1.3.2, nous avons dit que l’approche objet rapproche les données et leurs traitements. Mais cette approche ne fait pas que ça, d’autres concepts importants sont spécifiques à cette approche et participent à la qualité du logiciel.
Tout d’abord, introduisons la notion de classe. Une classe est un type de données abstrait qui précise des caractéristiques (attributs et méthodes) communes à toute une famille d’objets et qui permet de créer (instancier) des objets possédant ces caractéristiques. Les autres concepts importants qu’il nous faut maintenant introduire sont l’encapsulation, l’héritage et l’agrégation.
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant une interface. L’interface est la vue externe d’un objet, elle définit les services accessibles (offerts) aux utilisateurs de l’objet.
L’encapsulation facilite l’évolution d’une application car elle stabilise l’utilisation des objets : on peut modifier l’implémentation des attributs d’un objet sans modifier son interface, et donc la façon dont l’objet est utilisé.
L’encapsulation garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre, l’accès direct aux attributs des objets.
L’héritage est un mécanisme de transmission des caractéristiques d’une classe (ses attributs et méthodes) vers une sous-classe. Une classe peut être spécialisée en d’autres classes, afin d’y ajouter des caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent être généralisées en une classe qui les factorise, afin de regrouper les caractéristiques communes d’un ensemble de classes.
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de classes. L’héritage peut être simple ou multiple. L’héritage évite la duplication et encourage la réutilisation.
Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des objets de classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du code.
Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont des composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets composés d’autres objets. L’agrégation permet donc d’assembler des objets de base, afin de construire des objets plus complexes.
Les premiers langages de programmation qui ont utilisé des objets sont Simula I (1961-64) et Simula 67 (1967), conçus par les informaticiens norvégiens Ole-Johan Dahl et Kristan Nygaard. Simula 67 contenait déjà les objets, les classes, l’héritage, l’encapsulation, etc.
Alan Kay, du PARC de Xerox, avait utilisé Simula dans les années 1960. Il réalisa en 1976 Smalltalk qui reste, aux yeux de certains programmeurs, le meilleur langage de programmation par objets.
Bjarne Stroustrup a mis au point C++, une extension du langage C permettant la programmation orientée objets, aux Bell Labs d’AT&T en 1982. C++ deviendra le langage le plus utilisé par les programmeurs professionnels. Il arrivera à maturation en 1986, sa standardisation ANSI / ISO date de 1997.
Java est lancé par Sun en 1995. Comme il présente plus de sécurité que C++, il deviendra le langage favori de certains programmeurs professionnels.
La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des interfaces etc.
Pour programmer une application, il ne convient pas de se lancer tête baissée dans l’écriture du code : il faut d’abord organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes de la réalisation. C’est cette démarche antérieure à l’écriture que l’on appelle modélisation ; son produit est un modèle.
Les spécifications fournies par la maîtrise d’ouvrage en programmation impérative étaient souvent floues : les articulations conceptuelles (structures de données, algorithmes de traitement) s’exprimant dans le vocabulaire de l’informatique, le modèle devait souvent être élaboré par celle-ci. L’approche objet permet en principe à la maîtrise d’ouvrage de s’exprimer de façon précise selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être immédiatement compris par les informaticiens. En principe seulement, car la modélisation demande aux maîtrises d’ouvrage une compétence et un professionnalisme qui ne sont pas aujourd’hui répandus.
Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative (notamment Merise) étaient fondées sur la modélisation séparée des données et des traitements. Lorsque la programmation par objets prend de l’importance au début des années 1990, la nécessité d’une méthode qui lui soit adaptée devient évidente. Plus de cinquante méthodes apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, etc.) mais aucune ne parvient à s’imposer. En 1994, le consensus se fait autour de trois méthodes :
Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en compétition s’était réduit, mais le risque d’un éclatement subsistait : la profession pouvait se diviser entre ces trois méthodes, créant autant de continents intellectuels qui auraient du mal à communiquer.
Événement considérable et presque miraculeux, les trois gourous qui régnaient chacun sur l’une des trois méthodes se mirent d’accord pour définir une méthode commune qui fédérerait leurs apports respectifs (on les surnomme depuis « the Amigos »). UML (Unified Modeling Language) est né de cet effort de convergence. L’adjectif unified est là pour marquer qu’UML unifie, et donc remplace.
En fait, et comme son nom l’indique, UML n’a pas l’ambition d’être exactement une méthode : c’est un langage.
L’unification a progressé par étapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis d’accord pour construire une méthode unifiée, Unified Method 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement du mot méthode par le mot langage, plus modeste). Les acteurs les plus importants dans le monde du logiciel s’associent alors à l’effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et UML 1.0 est soumis à l’OMG5. L’OMG adopte en novembre 1997 UML 1.1 comme langage de modélisation des systèmes d’information à objets. La version d’UML en cours en 2008 est UML 2.1.1 et les travaux d’amélioration se poursuivent.
UML est donc non seulement un outil intéressant mais une norme qui s’impose en technologie à objets et à laquelle se sont rangés tous les grands acteurs du domaine, acteurs qui ont d’ailleurs contribué à son élaboration.
UML n’est pas une méthode (i.e. une description normative des étapes de la modélisation) : ses auteurs ont en effet estimé qu’il n’était pas opportun de définir une méthode en raison de la diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet de représenter et de communiquer les divers aspects d’un système d’information. Aux graphiques sont bien sûr associés des textes qui expliquent leur contenu. UML est donc un métalangage car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet.
Il est impossible de donner une représentation graphique complète d’un logiciel, ou de tout autre système complexe, de même qu’il est impossible de représenter entièrement une statue (à trois dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel système des vues partielles, analogues chacune à une photographie d’une statue, et dont la conjonction donnera une idée utilisable en pratique sans risque d’erreur grave.
UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands groupes :
Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous produits à l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes d’activités, de cas d’utilisation, de classes, d’objets, de séquence et d’états-transitions. Les diagrammes de composants, de déploiement et de communication sont surtout utiles pour la maîtrise d’œuvre à qui ils permettent de formaliser les contraintes de la réalisation et la solution technique.
Le diagramme de cas d’utilisation (cf. section 2) représente la structure des grandes fonctionnalités nécessaires aux utilisateurs du système. C’est le premier diagramme du modèle UML, celui où s’assure la relation entre l’utilisateur et les objets que le système met en œuvre.
Le diagramme de classes (cf. section 3) est généralement considéré comme le plus important dans un développement orienté objet. Il représente l’architecture conceptuelle du système : il décrit les classes que le système utilise, ainsi que leurs liens, que ceux-ci représentent un emboîtage conceptuel (héritage) ou une relation organique (agrégation).
Le diagramme d’objets (cf. section 3.5) permet d’éclairer un diagramme de classes en l’illustrant par des exemples. Il est, par exemple, utilisé pour vérifier l’adéquation d’un diagramme de classes à différents cas possibles.
Le diagramme d’états-transitions (cf. section 5) représente la façon dont évoluent (i.e. cycle de vie) les objets appartenant à une même classe. La modélisation du cycle de vie est essentielle pour représenter et mettre en forme la dynamique du système.
Le diagramme d’activités (cf. section 6) n’est autre que la transcription dans UML de la représentation du processus telle qu’elle a été élaborée lors du travail qui a préparé la modélisation : il montre l’enchaînement des activités qui concourent au processus.
Le diagramme de séquence (cf. section 7.3) représente la succession chronologique des opérations réalisées par un acteur. Il indique les objets que l’acteur va manipuler et les opérations qui font passer d’un objet à l’autre. On peut représenter les mêmes opérations par un diagramme de communication (cf. section 7.2), graphe dont les nœuds sont des objets et les arcs (numérotés selon la chronologie) les échanges entre objets. En fait, diagramme de séquence et diagramme de communication sont deux vues différentes mais logiquement équivalentes (on peut construire l’une à partir de l’autre) d’une même chronologie. Ce sont des diagrammes d’interaction (section 7).
La présentation d’un modèle UML se compose de plusieurs documents écrits en langage courant et d’un document formalisé : elle ne doit pas se limiter au seul document formalisé car celui-ci est pratiquement incompréhensible si on le présente seul. Un expert en UML sera capable dans certains cas de reconstituer les intentions initiales en lisant le modèle, mais pas toujours ; et les experts en UML sont rares. Voici la liste des documents qui paraissent nécessaires :
On doit présenter en premier le diagramme de cas d’utilisation qui montre l’enchaînement des cas d’utilisation au sein du processus, enchaînement immédiatement compréhensible ; puis le diagramme d’activités, qui montre le contenu de chaque cas d’utilisation ; puis le diagramme de séquence, qui montre l’enchaînement chronologique des opérations à l’intérieur de chaque cas d’utilisation. Enfin, le diagramme de classes, qui est le plus précis conceptuellement mais aussi le plus difficile à lire car il présente chacune des classes et leurs relations (agrégation, héritage, association, etc.).
Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des diagrammes de cas d’utilisation qui permettent de recueillir, d’analyser et d’organiser les besoins, et de recenser les grandes fonctionnalités d’un système. Il s’agit donc de la première étape UML d’analyse d’un système.
Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous-système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant un sens pour les acteurs. Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d’une vision informatique.
Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux attentes des utilisateurs. Pour élaborer les cas d’utilisation, il faut se fonder sur des entretiens avec les utilisateurs.
Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système.
Il se représente par un petit bonhomme (figure 2.1) avec son nom (i.e. son rôle) inscrit dessous.
Il est également possible de représenter un acteur sous la forme d’un classeur (cf. section 2.4.3) stéréotypé (cf. section 2.4.4) << actor >> (figure 2.2).
Un cas d’utilisation est une unité cohérente représentant une fonctionnalité visible de l’extérieur. Il 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 cas d’utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.
Un cas d’utilisation se représente par une ellipse (figure 2.3) contenant le nom du cas (un verbe à l’infinitif), et optionnellement, au-dessus du nom, un stéréotype (cf. section 2.4.4).
Dans le cas où l’on désire présenter les attributs ou les opérations du cas d’utilisation, il est préférable de le représenter sous la forme d’un classeur stéréotypé << use case >> (figure 2.4). Nous reviendrons sur les notions d’attributs ou d’opération lorsque nous aborderons les diagrammes de classes et d’objets (section 3).
Comme le montre la figure 2.5, la frontière du système est représentée par un cadre. Le nom du système figure à l’intérieur du cadre, en haut. Les acteurs sont à l’extérieur et les cas d’utilisation à l’intérieur.
Une relation d’association est chemin de communication entre un acteur et un cas d’utilisation et est représenté un trait continu (cf. figure 2.5 ou 2.6).
Lorsqu’un acteur peut interagir plusieur fois avec un cas d’utilisation, il est possible d’ajouter une multiplicité sur l’association du côté du cas d’utilisation. Le symbole * signifie plusieurs (figure 2.6), exactement n s’écrit tout simplement n, n..m signifie entre n et m, etc. Préciser une multiplicité sur une relation n’implique pas nécessairement que les cas sont utilisés en même temps.
La notion de multiplicité n’est pas propre au diagramme de cas d’utilisation. Nous en reparlerons dans le chapitre consacré au diagramme de classes section 3.3.4.
Un acteur est qualifié de principal pour un cas d’utilisation lorsque ce cas rend service à cet acteur. Les autres acteurs sont alors qualifiés de secondaires. Un cas d’utilisation a au plus un acteur principal. Un acteur principal obtient un résultat observable du système tandis qu’un acteur secondaire est sollicité pour des informations complémentaires. En général, l’acteur principal initie le cas d’utilisation par ses sollicitations. Le stéréotype << primary >> vient orner l’association reliant un cas d’utilisation à son acteur principal, le stéréotype << secondary >> est utilisé pour les acteurs secondaires (figure 2.6).
Quand un cas n’est pas directement relié à un acteur, il est qualifié de cas d’utilisation interne.
Il existe principalement deux types de relations :
Une dépendance se représente par une flèche avec un trait pointillé (figure 2.7). Si le cas A inclut ou étend le cas B, la flèche est dirigée de A vers B.
Le symbole utilisé pour la généralisation est un flèche avec un trait pleins dont la pointe est un triangle fermé désignant le cas le plus général (figure 2.7).
Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le cas A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette dépendance est symbolisée par le stéréotype << include >> (figure 2.7). Par exemple, l’accès aux informations d’un compte bancaire inclut nécessairement une phase d’authentification avec un identifiant et un mot de passe (figure 2.7).
Les inclusions permettent essentiellement de factoriser une partie de la description d’un cas d’utilisation qui serait commune à d’autres cas d’utilisation (cf. le cas S’authentifier de la figure 2.7).
Les inclusions permettent également de décomposer un cas complexe en sous-cas plus simples (figure 2.8). Cependant, il ne faut surtout pas abuser de ce type de décomposition : il faut éviter de réaliser du découpage fonctionnel d’un cas d’utilisation en plusieurs sous-cas d’utilisation pour ne pas retomber dans le travers de la décomposition fonctionnelle.
Attention également au fait que, les cas d’utilisation ne s’enchaînent pas, puisqu’il n’y a aucune représentation temporelle dans un diagramme de cas d’utilisation.
La relation d’extension est probablement la plus utile car elle a une sémantique qui a un sens du point de vue métier au contraire des deux autres qui sont plus des artifices d’informaticiens.
On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> (figure 2.7).
L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point d’extension. Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique point d’extension, et est éventuellement associé à une contrainte indiquant le moment où l’extension intervient. Une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d’une note. La figure 2.7 présente l’exemple d’une banque où la vérification du solde du compte n’intervient que si la demande de retrait dépasse 20 euros.
Un cas A est une généralisation d’un cas B si B est un cas particulier de A. Dans la figure 2.7, la consultation d’un compte via Internet est un cas particulier de la consultation. Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet.
La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.
Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont la pointe est un triangle fermé désignant l’acteur le plus général (comme nous l’avons déjà vu pour la relation de généralisation entre cas d’utilisation).
Par exemple, la figure 2.9 montre que le directeur des ventes est un préposé aux commandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une commande, il peut gérer le stock. Par contre, le préposé aux commandes ne peut pas gérer le stock.
Les éléments du langage UML que nous abordons ici ne sont pas spécifiques au diagramme de cas d’utilisation mais sont généraux. Nous avons déjà utilisé certains de ces éléments dans ce chapitre et nous utiliserons les autres dans les chapitres qui suivent, notamment dans le chapitre sur les diagrammes de classes (section 3).
Un paquetage est un regroupement d’éléments de modèle et de diagrammes. Il permet ainsi d’organiser des éléments de modélisation en groupes. Il peut contenir tout type d’élément de modèle : des classes, des cas d’utilisation, des interfaces, des diagrammes, … et même des paquetages imbriqués (décomposition hiérarchique).
Un paquetage se représente comme un dossier avec son nom inscrit dedans (figure 2.10, diagramme de gauche). Il est possible de représenter explicitement le contenu d’un paquetage. Dans ce cas, le nom du paquetage est placé dans l’onglet (figure 2.10, diagramme de droite).
Les éléments contenus dans un paquetage doivent représenter un ensemble fortement cohérent et sont généralement de même nature et de même niveau sémantique. Tout élément n’appartient qu’à un seul paquetage. Les paquetage constituent un mécanisme de gestion important des problèmes de grande taille. Ils permettent d’éviter les grands modèles plats et de cloisonner des éléments constitutifs d’un système évoluant à des rythmes différents ou développés par des équipes différentes.
Il existe un paquetage racine unique, éventuellement anonyme, qui contient la totalité des modèles d’un système.
Les espaces de noms sont des paquetages, des classeurs, etc. On peut déterminer un élément nommé de façon unique par son nom qualifié, qui est constitué de la série des noms des paquetages ou des autres espaces de noms depuis la racine jusqu’à l’élément en question. Dans un nom qualifié, chaque espace de nom est séparé par deux doubles points (::).
Par exemple, si un paquetage B est inclus dans un paquetage A et contient une classe X, il faut écrire A::B::X pour pouvoir utiliser la classe X en dehors du contexte du paquetage B.
Les paquetages et les relations de généralisation ne peuvent avoir d’instance. D’une manière générale, les éléments de modélisation pouvant en avoir sont représentés dans des classeurs1. Plus important encore, un classeur est un élément de modèle qui décrit une unité structurelle ou comportementale.
Un classeur modélise un concept discret qui décrit un élément (i.e. objet) doté d’une identité (i.e. un nom), d’une structure ou d’un état (i.e. des attributs), d’un comportement (i.e. des opérations), de relations et d’une structure interne facultative. Il peut participer à des relations d’association, de généralisation, de dépendance et de contrainte. On le déclare dans un espace de noms, comme un paquetage ou une autre classe. Un classeur se représente par un rectangle, en traits pleins, contenant éventuellement des compartiments.
Les acteurs et les cas d’utilisation sont des classeurs. Tout au long de ce cours, nous retrouverons le terme de classeur car cette notion englobe aussi les classes, les interfaces, les signaux, les nœuds, les composants, les sous-systèmes, etc. Le type de classeur le plus important étant, bien évidemment, la classe (cf. section 3).
Un stéréotype est une annotation s’appliquant sur un élément de modèle. Il n’a pas de définition formelle, mais permet de mieux caractériser des variétés d’un même concept. Il permet donc d’adapter le langage à des situations particulières. Il est représenté par une chaînes de caractères entre guillemets (<< >>) dans, ou à proximité du symbole de l’élément de modèle de base.
Par exemple, la figure 2.4 représente un cas d’utilisation par un rectangle. UML utilise aussi les rectangles pour représenter les classes (cf. section 3). La notation n’est cependant pas ambiguë grâce à la présence du stéréotype << use case >>.
Une note contient une information textuelle comme un commentaire, un corps de méthode ou une contrainte. Graphiquement, elle est représentée par un rectangle dont l’angle supérieur droit est plié. Le texte contenu dans le rectangle n’est pas contraint par UML. Une note n’indique pas explicitement le type d’élément qu’elle contient, toute l’intelligibilité d’une note doit être contenu dans le texte même. On peut relier une note à l’élément qu’elle décrit grâce à une ligne en pointillés. Si elle décrit plusieurs éléments, on dessine une ligne vers chacun d’entre eux.
L’exemple de la figure 2.11 montre une note exprimant une contrainte (cf. section 4.1) sur un attribut.
UML n’emploie pas le terme d’utilisateur mais d’acteur. Les acteurs d’un système sont les entités externes à ce système qui interagissent (saisie de données, réception d’information, …) avec lui. Les acteurs sont donc à l’extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l’interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur l’interface et donc la définition du système à produire.
Il faut faire attention à ne pas confondre acteurs et utilisateurs (utilisateur avec le sens de la personne physique qui va appuyer sur un bouton) d’un système. D’une part parce que les acteurs inclus les utilisateurs humains mais aussi les autres systèmes informatiques ou hardware qui vont communiquer avec le système. D’autre part parce que un acteur englobe tout une classe d’utilisateur. Ainsi, plusieurs utilisateurs peuvent avoir le même rôle, et donc correspondre à un même acteur, et une même personne physique peut jouer des rôles différents vis-à-vis du système, et donc correspondre à plusieurs acteurs.
Chaque acteur doit être nommé. Ce nom doit refléter sont rôle car un acteur représente un ensemble cohérent de rôles joués vis-à-vis du système.
Pour trouver les acteurs d’un système, il faut identifier quels sont les différents rôles que vont devoir jouer ses utilisateurs (ex : responsable clientèle, responsable d’agence, administrateur, approbateur, …). Il faut également s’intéresser aux autres systèmes avec lesquels le système va devoir communiquer comme :
Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système. Tout ce qui est à l’extérieur et qui interagit avec le système est un acteur, tout ce qui est à l’intérieur est une fonctionnalité à réaliser.
Vérifiez que les acteurs communiquent bien directement avec le système par émission ou réception de messages. Une erreur fréquente consiste à répertorier en tant qu’acteur des entités externes qui n’interagissent pas directement avec le système, mais uniquement par le biais d’un des véritables acteurs. Par exemple, l’hôtesse de caisse d’un magasin de grande distribution est un acteur pour la caisse enregistreuse, par contre, les clients du magasins ne correspondent pas à un acteur car ils n’interagissent pas directement avec la caisse.
L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences fonctionnelles du système. Chaque cas d’utilisation correspond donc à une fonction métier du système, selon le point de vue d’un de ses acteurs. Aussi, pour identifier les cas d’utilisation, il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert du système. Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon niveau d’abstraction. Trouver le bon niveau de détail pour les cas d’utilisation est un problème difficile qui nécessite de l’expérience.
Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en vous plaçant du point de vue de l’acteur et non pas de celui du système. Par exemple, un distributeur de billets aura probablement un cas d’utilisation Retirer de l’argent et non pas Distribuer de l’argent.
De par la nature fonctionnelle, et non objet, des cas d’utilisation, et en raison de la difficulté de trouver le bon niveau de détail, il faut être très vigilant pour ne pas retomber dans une décomposition fonctionnelle descendante hiérarchique. Un nombre trop important de cas d’utilisation est en général le symptôme de ce type d’erreur.
Dans tous les cas, il faut bien garder à l’esprit qu’il n’y a pas de notion temporelle dans un diagramme de cas d’utilisation.
Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue des acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation. Bien que de nombreux diagrammes d’UML permettent de décrire un cas, il est recommandé de rédiger une description textuelle car c’est une forme souple qui convient dans bien des situations.
Une description textuelle couramment utilisée se compose de trois parties.
Il est important de noter que l’utilisation des relations n’est pas primordiale dans la rédaction des cas d’utilisation et donc dans l’expression du besoin. Ces relations peuvent être utiles dans certains cas mais une trop forte focalisation sur leur usage conduit souvent à une perte de temps ou à un usage faussé, pour une valeur ajoutée, au final, relativement faible.
Unanimement reconnus comme cantonnés à l’ingénierie des besoins, les diagrammes de cas d’utilisation ne peuvent être qualifiés de modélisation à proprement parler. D’ailleur, de nombreux éléments descriptifs sont en langage naturel. De plus, ils ne correspondent pas stricto sensu à une approche objet. En effet, capturer les besoins, les découvrir, les réfuter, les consolider, etc., correspond plus à une analyse fonctionnelle classique.
UML ne mentionne que le fait que la réalisation d’un cas d’utilisation est décrit par une suite de collaborations entre éléments de modélisation mais ne parle par de l’élément de modélisation use case realization. Les use case realization ne sont pas un formalisme d’UML mais du RUP (Rational Unified Process).
Après avoir rédigé les cas d’utilisation, il faut identifier des objets, des classes, des données et des traitements qui vont permettre au système de supporter ces cas d’utilisation. Pour documenter la manière dont sont mis en œuvre les cas d’utilisation du système, on peut utiliser le mécanisme des use case realization. Ils permettent de regrouper un diagramme de classes et des diagrammes d’interaction. On retrouvera dans le diagramme de classes les classes qui mettent en œuvre le cas d’utilisation associé au use case realization. On retrouvera dans les différents diagrammes d’interaction une documentation des différents évènements échangés entre les objets afin de réaliser les différents scénarii décrit dans le cas d’utilisation.
Au final on aura un use case realization par cas d’utilisation et dans chaque use case realization on aura autant de diagrammes d’interaction que nécessaire pour illustrer les scénarii décrits dans le cas d’utilisation (scénario nominal, scénarii alternatifs et scénarii d’exception).
Les use case realization permettent donc, dans la pratique, d’apporter un élément de réponse à la question : Comment structurer mon modèle UML ?
Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation.
Alors que le diagramme de cas d’utilisation montre un système du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d’utilisation. Il est important de noter qu’un même objet peut très bien intervenir dans la réalisation de plusieurs cas d’utilisation. Les cas d’utilisation ne réalisent donc pas une partition1 des classes du diagramme de classes. Un diagramme de classes n’est donc pas adapté (sauf cas particulier) pour détailler, décomposer, ou illustrer la réalisation d’un cas d’utilisation particulier.
Il s’agit d’une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise les conceps du domaine d’application ainsi que les concepts internes créés de toutes pièces dans le cadre de l’implémentation d’une application. Chaque langage de Programmation Orienté Objets donne un moyen spécifique d’implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d’un langage de programmation particulier.
Les principaux éléments de cette vue statique sont les classes et leurs relations : association, généralisation et plusieurs types de dépendances, telles que la réalisation et l’utilisation.
Une instance est une concrétisation d’un concept abstrait. Par exemple :
Une classe est un concept abstrait représentant des éléments variés comme :
Tout système orienté objet est organisé autour des classes.
Une classe est la description formelle d’un ensemble d’objets ayant une sémantique et des caractéristiques communes.
Un objet est une instance d’une classe. C’est une entité discrète dotée d’une identité, d’un état et d’un comportement que l’on
