Cours complet sur le langage de modelisation objet unifie uml
...
L'approche objet est pourtant loin d'être une idée récente. Simula, premier langage de programmation à implémenter le concept de type abstrait à l'aide de classes, date de 1967 ! En 1976 déjà, Smalltalk implémente les concepts fondateurs de l'approche objet : encapsulation, agrégation, héritage. Les premiers compilateurs C+ datent du début des années 80 et de nombreux langages orientés objets "académiques" ont étayés les concepts objets (Eiffel, Objective C, Loops...).
Il y donc déjà longtemps que l'approche objet est devenue une réalité. Les concepts de base de l'approche objet sont stables et largement éprouvés. De nos jours, programmer "objet", c'est bénéficier d'une panoplie d'outils et de langages performants. L'approche objet est une solution technologique incontournable. Ce n'est plus une mode, mais un réflexe quasi-automatique dès lors qu'on cherche à concevoir des logiciels complexes qui doivent "résister" à des évolutions incessantes.
Penser objet avec UML' pour concevoir objet :
Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des concepts abstraits, indépendants des langages d'implémentation et des contraintes purement techniques. Les langages de programmation ne sont pas un support d'analyse adéquat pour "concevoir objet". Ils ne permettent pas de décrire des solutions en terme de concepts abstraits et constituent un cadre trop rigide pour mener une analyse itérative.
Pour conduire une analyse objet cohérente, il ne faut pas directement penser en terme de pointeurs, d'attributs et de tableaux, mais en terme d'association, de propriétés et de cardinalités... Utiliser le langage de programmation comme support de conception ne revient bien souvent qu'à juxtaposer de manière fonctionnelle un ensemble de mécanismes d'implémentation, pour résoudre un problème qui nécessite en réalité une modélisation objet.
Au risque d'en décourager certains et d'en décevoir d'autres, l'approche objet nécessite une analyse réfléchie, qui passe par différentes phases exploratoires ! Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle reste la plus intuitive pour nos esprits cartésiens... Voilà pourquoi il ne faut pas se contenter d'une implémentation objet, mais se discipliner à "penser objet" au cours d'une phase d'analyse préalable.
Toutes les dérives fonctionnelles de code objet ont pour origine le non respect des concepts de base de l'approche objet (encapsulation...) ou une utilisation détournée de ces concepts (héritage sans classification...). Ces dérives ne sont pas dues à de mauvaises techniques de programmation ; la racine du mal est bien plus profonde ! Bref, programmer en C++ ou en Java n'implique pas forcément concevoir objet...
Les difficultés de mise en oeuvre d'une approche "réellement objet" ont engendré bien souvent des déceptions, ce qui a longtemps constitué un obstacle important à l'essor des technologies objet. Beaucoup ont cédé au leurre des langages de programmation orientés objet et oublié que le code n'est qu'un "moyen". Le respect des concepts fondamentaux de l'approche objet prime sur la manière dont on les implémente. Ne penser qu'à travers un langage de programmation objet est un mirage qui vous détourne de l'essentiel. Pour sortir les technologies objet, l'OMG propose UML.
->Définition :
UML (Unified Modeling Language), qui se traduit par : "langage de modélisation objet unifié", est né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des années 90 : OMT, Booch et OOSE.
Issu "du terrain" et fruit d'un travail d'experts reconnus, UML est le résultat d'un large consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à son développement.
Né de la fusion des méthodes objet dominantes (OMT, Booch et OOSE), puis normalisé par l'OMG en 1997, UML est rapidement devenu un standard incontournable. UML n'est pas à l'origine des concepts objet, mais il en en donne une définition plus formelle et apporte la dimension méthodologique qui faisait défaut à l'approche objet.
En l'espace d'une poignée d'années seulement, UML est devenu un standard incontournable. La presse spécialisée foisonne d'articles exaltés et à en croire certains, utiliser les technologies objet sans UML relève de l'hérésie. Lorsqu'on possède un esprit un tant soit peu critique, on est en droit de s'interroger sur les raisons qui expliquent un engouement si soudain et massif.
Le but de cette présentation n'est pas de faire l'apologie d'UML, ni de restreindre UML à sa notation graphique, car le véritable intérêt d'UML est ailleurs. En effet, maîtriser la notation graphique d'UML n'est pas une fin en soi. Ce qui est primordial, c'est d'utiliser les concepts objet à bon escient et d'appliquer la démarche d'analyse correspondante. Cette présentation a donc pour objectif, d'une part, de montrer en quoi l'approche objet et UML constituent un "plus" et d'autre part, d'exposer comment utiliser UML dans la pratique, c'est-à-dire comment intégrer UML dans un processus de développement et comment modéliser avec UML.
- >Les méthodes objet et la genèse d'UM L:
o Découpe cartésienne (fonctionnelle et hiérarchique) d'un système.
o Modélisation des données + modélisation des traitements (Merise, Axial, IE...).
o Prise de conscience de l'importance d'une méthode spécifiquement objet : comment structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur les traitements (mais sur les deux) ?
o Plus de 50 méthodes objet sont apparues durant cette période (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !
o Aucune méthode ne s'est réellement imposée.
o OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un système
n Issue du centre de R&D de General Electric.
n Notation graphique riche et lisible.
o OOD (Grady Booch) : vues logiques et physiques du système
n Définie pour le DOD, afin de rationaliser de développement d'applications ADA, puis C++.
n Ne couvre pas la phase d'analyse dans ses lères versions (préconise SADT).
n Introduit le concept de package (élément d'organisation des modèles).
o OOSE (Ivar Jacobson) : couvre tout le cycle de développement
n Issue d'un centre de développement d'Ericsson, en Suède.
n La méthodologie repose sur l'analyse des besoins des utilisateurs.
o UML (Unified Modeling Langage), la fusion et synthèse des méthodes dominantes :
o UML est le résultat d'un large consensus (industriels, méthodologistes...).
o UML est le fruit d'un travail d'experts reconnus.
o UML est issu du terrain.
o UML est riche (il couvre toutes les phases d'un cycle de développement).
o UML est ouvert (il est indépendant du domaine d'application et des langages d'implémentation).
o Après l'unification et la standardisation, bientôt l'industrialisation d'UML : les outils qui supportent UML se multiplient (GDPro, ObjectTeam, Objecteering, OpenTool, Rational Rose, Rhapsody, STP, Visio, Visual Modeler, WithClass...).
o XML (format d'échange standard de modèles UM L).
o L'OMG RTF centralise et normalise les évolutions d'UML au niveau international.
o Les groupes d'utilisateurs UML favorisent le partage des expériences.
o De version en version, UML gagne en maturité et précision, tout en restant stable.
o UML inclut des mécanismes standards d'auto-extension.
o La description du métamodèle d'UM L est standardisée (OMG-MOF). Note : UML n'est pas une mode' c'est un investissement fiable !
- >Le rôle d'UML :
o Si l'on parle de méthode objet pour UML, c'est par abus de langage!
o Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modélisation.
o Propose aussi un processus, qui régit l'enchaînement des activités de production d'une entreprise.
o UML a été pensé pour permettre de modéliser les activités de l'entreprise, pas pour les régir.
o Un processus de développement logiciel universel est une utopie :
n Impossible de prendre en compte toutes les organisations et cultures d'entreprises.
n Un processus est adapté (donc très lié) au domaine d'activité de l'entreprise.
n Même si un processus constitue un cadre général, il faut l'adapter de manière précise au contexte de l'entreprise.
o UML est fondé sur un métamodèle, qui définit :
n les éléments de modélisation (les concepts manipulés par le langage),
n la sémantique de ces éléments (leur définition et le sens de leur utilisation).
o Un métamodèle est une description très formelle de tous les concepts d'un langage. Il limite les
ambiguiités et encourage la construction d'outils.
o Le métamodèle d'UML permet de classer les concepts du langage (selon leur niveau d'abstraction ou domaine d'application) et expose sa structure.
o Le métamodèle UML est lui-même décrit par un méta-métamodèle (OMG-MOF).
o UML propose aussi une notation, qui permet de représenter graphiquement les éléments de modélisation du métamodèle.
o Cette notation graphique est le support du langage UML.
o différentes vues complémentaires d'un système, qui guident l'utilisation des concepts objets,
o plusieurs niveaux d'abstraction, qui permettent de mieux contrôler la complexité dans l'expression des solutions objets.
o Sa notation graphique permet d'exprimer visuellement une solution objet.
o L'aspect formel de sa notation limite les ambiguités et les incompréhensions.
o Son aspect visuel facilite la comparaison et l'évaluation de solutions.
o Grâce au principe d'élaboration des modèles, UML permet de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes complexes.
o Mais cet aspect méthodologique d'UM L ne doit pas vous induire en erreur.
o UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus d'élaboration des modèles! Qualifier UML de "méthode objet" n'est donc pas tout à fait approprié.
o Les auteurs d'UM L sont tout à fait conscients de l'importance du processus, mais ce sujet a été intentionnellement exclu des travaux de l'OMG.
Comment prendre en compte toutes les organisations et cultures d'entreprises ?
Un processus est adapté (donc très lié) au domaine d'activité de l'entreprise ; même s'il constitue un cadre général, il faut l'adapter au contexte de l'entreprise. Bref, améliorer un processus est une discipline à part entière, c'est un objectif qui dépasse très largement le cadre de l'OMA.
Cependant, même si pour l'OMG, l'acceptabilité industrielle de la modélisation objet passe d'abord par la disponibilité d'un langage d'analyse objet performant et standard, les auteurs d'UML préconisent d'utiliser une démarche :
D'après les auteurs d'UML, un processus de développement qui possède ces qualités fondamentales "devrait" favoriser la réussite d'un projet. Une source fréquente de malentendus sur UML a pour origine la faculté d'UML de modéliser un processus, pour le documenter et l'optimiser par exemple. En fin de compte, qu'est-ce qu'un processus ? Un ensemble d'activités coordonnées et régulées, en partie ordonnées, dont le but est de créer un produit (matériel ou intellectuel). UML permet tout à fait de modéliser les activités (c'est-à-dire la dynamique) d'un processus, de décrire le rôle des acteurs du processus, la structure des éléments manipulés et produits, etc...
Une extension d'UML ("UM L extension for business modeling") propose d'ailleurs un certain nombre de stéréotypes standards (extensions du métamodèle) pour mieux décrire les processus.
L'intégration d'UML dans un processus n'est pas triviale et améliorer un processus est un tâche complexe et longue. Les auteurs d'UML sont tout à fait conscients de l'importance du processus, mais l'acceptabilité industrielle de la modélisation objet passe d'abord par la disponibilité d'un langage d'analyse objet performant et standard.
Son indépendance par rapport aux langages d'implémentation, domaine d'application, processus... en font un langage universel. Avant tout est un support de communication performant, qui facilite la représentation et la compréhension de solutions objet :
La notation graphique d'UM L n'est que le support du langage. La véritable force d'UM L, c'est qu'il repose sur un métamodèle. En d'autres termes : la puissance et l'intérêt d'UML' c'est qu'il normalise la sémantique des concepts qu'il véhicule.
Qu'une association d'héritage entre deux classes soit représentée par une flèche terminée par un triangle ou un cercle, n'a que peu d'importance par rapport au sens que cela donne à votre modèle. La notation graphique est essentiellement guidée par des considérations esthétiques, même si elle a été pensée dans ses moindres détails.
Par contre, utiliser une relation d'héritage, reflète l'intention de donner à votre modèle un sens particulier. Un "bon" langage de modélisation doit permettre à n'importe qui de déchiffrer cette intention de manière non équivoque ! Il est donc primordial de s'accorder sur la sémantique des éléments de modélisation, bien avant de s'intéresser à la manière de les représenter. Le métamodèle UML apporte une solution à ce problème fondamental.
UML est donc bien plus qu'un simple outil qui permet de "dessiner" des représentations mentales... Il permet de parler un langage commun, normalisé mais accessible, car visuel. Il représente un juste milieu entre langage mathématique et naturel, pas trop complexe mais suffisamment rigoureux, car basé sur un métamodèle.
Décrit de manière très précise tous les éléments de modélisation (les concepts véhiculés et manipulés par le langage) et la sémantique de ces éléments (leur définition et le sens de leur utilisation). En d'autres termes : UML normalise les concepts objet.
Un métamodèle permet de limiter les ambiguiités et encourage la construction d'outils. Il permet aussi de classer les différents concepts du langage (selon leur niveau d'abstraction ou leur domaine d'application) et expose ainsi clairement sa structure. Enfin, on peut noter que le métamodèle d'UML est lui-même décrit par un méta-métamodèle de manière standardisée, à l'aide de MOF (Meta Object Facility : norme OMG de description des métamodèles). Cela vous semble peut-être anecdotique, mais prouve si nécessaire le soin apporté par l'OMG pour définir UML.
Véritable clé de voûte de l'OMA, UML est donc un outil indispensable pour tous ceux qui ont compris que programmer objet, c'est d'abord concevoir objet. UML n'est pas à l'origine des concepts objets, mais il en constitue une étape majeure, car il unifie les différentes approches et en donne une définition plus formelle.
- >Les points forts d'UML :
o gain de précision
o gage de stabilité
o encourage l'utilisation d'outils
o Il cadre l'analyse.
o Il facilite la compréhension de représentations abstraites complexes.
o Son caractère polyvalent et sa souplesse en font un langage universel.
- >Les points faibles d'UM L:
3.1. Qu'est-ce qu'un modèle ?
L'abstraction est un des piliers de l'approche objet.
o Il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une entité, en vue d'une utilisation précise.
o L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d'une entité, retenues par un observateur.
o Un modèle définit une frontière entre la réalité et la perspective de l'observateur. Ce n'est pas "la réalité", mais une vue très subjective de la réalité.
o Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des aspects importants de la réalité, il en donne donc une vue juste et pertinente.
o Modèle météorologique : à partir de données d'observation (satellite ...), permet de prévoir les conditions climatiques pour les jours à venir.
o Modèle économique : peut par exemple permettre de simuler l'évolution de cours boursiers en fonction d'hypothèses macro-économiques (évolution du chômage, taux de croissance...).
o Modèle démographique : définit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des études statistiques, d'augmenter l'impact de démarches commerciales,...
Le caractère abstrait d'un modèle doit notamment permettre :
o de faciliter la compréhension du système étudié --> Un modèle réduit la complexité du système étudié.
o de simuler le système étudié représenté par un modèle qui reproduit ses comportements.
Un modèle réduit (décompose) la réalité, dans le but de disposer d'éléments de travail exploitables par des moyens mathématiques ou informatiques : modèle / réalité — digital / analogique
3.2. Comment modéliser avec UML ?
o Itérative et incrémentale,
o Guidée par les besoins des utilisateurs du système,
o Centrée sur l'architecture logicielle.
D'après les auteurs d'UML, un processus de développement possède ces qualités doit favoriser la réussite d'un projet.
3.3. Une démarche itérative et incrémentale:
3.4. Une démarche pilotée par les besoins des utilisateurs :
o Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce que doit être le système).
o Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système).
o A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs.
o A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs.
o A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.
4.1. Une démarche centrée sur l'architecture :
Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité...).
Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui permettent de définir un modèle d'architecture (publication IEEE, 1995).
Cette vue ("4+1") a fortement inspiré UML :
Les 4+1 vues permettent de mettre en évidence les différents aspects du logiciel à réaliser.
-La vue des cas d'utilisation:Traite les spécifications fonctionnels du logiciel : (guide et justifie les autres vues).
-La vue logique : Modélise les éléments structurés du système (les classes).
-La vue des composants : Décrit l'organisation des composants physique du logiciel (Fichiers sources, BD, DLL, ...etc). -La vue des processus:Traite les aspects multitâches et concurrents du logiciel. -La vue de déploiement : Répartition des composants physiques sur le matériel.
4.2. Vues Statiques:
o Conceptualisation et les cas d'utilisation
o Structuration des modèles (paquetages, collaboration)
o les objets, le diagramme d'objets et les classes
o le diagramme de classes
o les stéréotypes
o le diagramme de composants
o le diagramme de déploiement
4.3. Vues Dynamiques :
o le diagramme de collaboration
o synchronisation des messages
o les objets actifs
o le diagramme de séquence
o le diagramme d'états-transitions
o le diagramme d'activités
5.1. Aspect statique:
Décrit l'aspect structurel du logiciel, c-à-d les classes, les objets constituant le système et les relations entre eux.
5.2. Aspect dynamique :
Décrit le comportement des objets à l'intérieur du système c'est-à-dire changement d'état des objets en réponse à certains événements.
5.3. Aspect fonctionnel :
Décrit les fonctionnalités réalisées par les objets du système par l'intermédiaire de leurs opérations.
o définissent le contour du système à modéliser (ils précisent le but à atteindre),
o permettent d'identifier les fonctionnalités principales (critiques) du système.
-Cas d'utilisation (use cases) :
-Le modèle conceptuel :
Le modèle conceptuel est le type de diagramme UML qui possède la notation la plus simple; mais paradoxalement c'est aussi celui qui est le plus mal compris!
Au début des années 90, Ivar Jacobson (inventeur de OOSE, une des méthodes fondatrices d'UML) a été nommé les ingénieurs d'Ericsson avaient accouché d'un monstre. Personne ne savait vraiment quelles étaient les fonctionnalités du produit, ni comment elles étaient assurées, ni comment les faire évoluer...Classique lorsque les commerciaux promettent monts et merveilles à tous les clients qu'ils démarchent, sans se soucier des contraintes techniques, que les clients ne savent pas exprimer leurs besoins et que les ingénieurs n'ont pas les ressources pour développer le mouton à cinq pattes qui résulte de ce chaos.
Pour éviter de foncer droit dans un mur et mener à bien ce projet critique pour Ericsson, Jacobson a eu une idée. Plutôt que de continuer à construire une tour de Babel, pourquoi ne pas remettre à plat les objectifs réels du projet ? En d'autres termes : quels sont les besoins réels des clients, ceux qui conditionneront la réussite du projet ? Ces besoins critiques, une fois identifiés et structurés, permettront enfin de cerner "ce qui est important pour la réussite du projet". Le bénéfice de cette démarche simplificatrice est double. D'une part, tous les acteurs du projet ont une meilleure compréhension du système à développer, d'autre part, les besoins des utilisateurs, une fois clarifiés, serviront de fil rouge, tout au long du cycle de développement.
A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs ; à chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs et à chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits. Simple mais génial. Pour la petite histoire, sacheZ que grâce à cette démarche initiée par Jacobson, Ericsson a réussi à mener à bien son projet et a gagné une notoriété internationale dans le marché de la commutation.
La détermination et la compréhension des besoins sont souvent difficiles car les intervenants sont noyés sous de trop grandes quantités d'informations. Or, comment mener à bien un projet si l'on ne sait pas où l'on va ?
Jacobson identifie les caractéristiques suivantes pour les modèles :
Notes :
Une fois identifiés et structurés, ces besoins :
Mais un modèle conceptuel qui identifie les besoins avec un plus grand niveau d'abstraction reste indispensable. Avec des systèmes complexes, filtrer l'information, la simplifier et mieux l'organiser, c'est rendre l'information exploitable. ProduiseZ de l'information éphémère, complexe et confuse, vous obtiendreZ un joyeux "désordre".
Remarque:
UtiliseZ les use cases tels qu'ils ont été pensé par leurs créateurs! UML est issu du terrain. Si vous utiliseZ les use cases sans avoir en tête la démarche sous-jacente, vous n'en tirereZ aucun bénéfice.
r*Eléments de base des cas d'utilisation :
o L'acteur peut consulter ou modifier l'état du système.
o En réponse à l'action d'un acteur, le système fournit un service qui correspond à son besoin.
o Les acteurs peuvent être classés (hiérarchisés).
o Les uses cases peuvent être structurés.
o Les uses cases peuvent être organisés en paquetages (packages).
o L'ensemble des use cases décrit les objectifs (le but) du système.
Cours complet sur le langage de modelisation objet unifie uml
...
L'approche objet est pourtant loin d'être une idée récente. Simula, premier langage de programmation à implémenter le concept de type abstrait à l'aide de classes, date de 1967 ! En 1976 déjà, Smalltalk implémente les concepts fondateurs de l'approche objet : encapsulation, agrégation, héritage. Les premiers compilateurs C+ datent du début des années 80 et de nombreux langages orientés objets "académiques" ont étayés les concepts objets (Eiffel, Objective C, Loops...).
Il y donc déjà longtemps que l'approche objet est devenue une réalité. Les concepts de base de l'approche objet sont stables et largement éprouvés. De nos jours, programmer "objet", c'est bénéficier d'une panoplie d'outils et de langages performants. L'approche objet est une solution technologique incontournable. Ce n'est plus une mode, mais un réflexe quasi-automatique dès lors qu'on cherche à concevoir des logiciels complexes qui doivent "résister" à des évolutions incessantes.
Penser objet avec UML' pour concevoir objet :
Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des concepts abstraits, indépendants des langages d'implémentation et des contraintes purement techniques. Les langages de programmation ne sont pas un support d'analyse adéquat pour "concevoir objet". Ils ne permettent pas de décrire des solutions en terme de concepts abstraits et constituent un cadre trop rigide pour mener une analyse itérative.
Pour conduire une analyse objet cohérente, il ne faut pas directement penser en terme de pointeurs, d'attributs et de tableaux, mais en terme d'association, de propriétés et de cardinalités... Utiliser le langage de programmation comme support de conception ne revient bien souvent qu'à juxtaposer de manière fonctionnelle un ensemble de mécanismes d'implémentation, pour résoudre un problème qui nécessite en réalité une modélisation objet.
Au risque d'en décourager certains et d'en décevoir d'autres, l'approche objet nécessite une analyse réfléchie, qui passe par différentes phases exploratoires ! Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle reste la plus intuitive pour nos esprits cartésiens... Voilà pourquoi il ne faut pas se contenter d'une implémentation objet, mais se discipliner à "penser objet" au cours d'une phase d'analyse préalable.
Toutes les dérives fonctionnelles de code objet ont pour origine le non respect des concepts de base de l'approche objet (encapsulation...) ou une utilisation détournée de ces concepts (héritage sans classification...). Ces dérives ne sont pas dues à de mauvaises techniques de programmation ; la racine du mal est bien plus profonde ! Bref, programmer en C++ ou en Java n'implique pas forcément concevoir objet...
Les difficultés de mise en oeuvre d'une approche "réellement objet" ont engendré bien souvent des déceptions, ce qui a longtemps constitué un obstacle important à l'essor des technologies objet. Beaucoup ont cédé au leurre des langages de programmation orientés objet et oublié que le code n'est qu'un "moyen". Le respect des concepts fondamentaux de l'approche objet prime sur la manière dont on les implémente. Ne penser qu'à travers un langage de programmation objet est un mirage qui vous détourne de l'essentiel. Pour sortir les technologies objet, l'OMG propose UML.
->Définition :
UML (Unified Modeling Language), qui se traduit par : "langage de modélisation objet unifié", est né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des années 90 : OMT, Booch et OOSE.
Issu "du terrain" et fruit d'un travail d'experts reconnus, UML est le résultat d'un large consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à son développement.
Né de la fusion des méthodes objet dominantes (OMT, Booch et OOSE), puis normalisé par l'OMG en 1997, UML est rapidement devenu un standard incontournable. UML n'est pas à l'origine des concepts objet, mais il en en donne une définition plus formelle et apporte la dimension méthodologique qui faisait défaut à l'approche objet.
En l'espace d'une poignée d'années seulement, UML est devenu un standard incontournable. La presse spécialisée foisonne d'articles exaltés et à en croire certains, utiliser les technologies objet sans UML relève de l'hérésie. Lorsqu'on possède un esprit un tant soit peu critique, on est en droit de s'interroger sur les raisons qui expliquent un engouement si soudain et massif.
Le but de cette présentation n'est pas de faire l'apologie d'UML, ni de restreindre UML à sa notation graphique, car le véritable intérêt d'UML est ailleurs. En effet, maîtriser la notation graphique d'UML n'est pas une fin en soi. Ce qui est primordial, c'est d'utiliser les concepts objet à bon escient et d'appliquer la démarche d'analyse correspondante. Cette présentation a donc pour objectif, d'une part, de montrer en quoi l'approche objet et UML constituent un "plus" et d'autre part, d'exposer comment utiliser UML dans la pratique, c'est-à-dire comment intégrer UML dans un processus de développement et comment modéliser avec UML.
- >Les méthodes objet et la genèse d'UM L:
o Découpe cartésienne (fonctionnelle et hiérarchique) d'un système.
o Modélisation des données + modélisation des traitements (Merise, Axial, IE...).
o Prise de conscience de l'importance d'une méthode spécifiquement objet : comment structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur les traitements (mais sur les deux) ?
o Plus de 50 méthodes objet sont apparues durant cette période (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !
o Aucune méthode ne s'est réellement imposée.
o OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un système
n Issue du centre de R&D de General Electric.
o OOD (Grady Booch) : vues logiques et physiques du système
n Définie pour le DOD, afin de rationaliser de développement d'applications ADA, puis C++.
n Ne couvre pas la phase d'analyse dans ses lères versions (préconise SADT).
n Introduit le concept de package (élément d'organisation des modèles).
o OOSE (Ivar Jacobson) : couvre tout le cycle de développement
n Issue d'un centre de développement d'Ericsson, en Suède.
n La méthodologie repose sur l'analyse des besoins des utilisateurs.
o UML (Unified Modeling Langage), la fusion et synthèse des méthodes dominantes :
o UML est le résultat d'un large consensus (industriels, méthodologistes...).
o UML est le fruit d'un travail d'experts reconnus.
o UML est issu du terrain.
o UML est riche (il couvre toutes les phases d'un cycle de développement).
o UML est ouvert (il est indépendant du domaine d'application et des langages d'implémentation).
o Après l'unification et la standardisation, bientôt l'industrialisation d'UML : les outils qui supportent UML se multiplient (GDPro, ObjectTeam, Objecteering, OpenTool, Rational Rose, Rhapsody, STP, Visio, Visual Modeler, WithClass...).
o XML (format d'échange standard de modèles UM L).
o L'OMG RTF centralise et normalise les évolutions d'UML au niveau international.
o Les groupes d'utilisateurs UML favorisent le partage des expériences.
o De version en version, UML gagne en maturité et précision, tout en restant stable.
o UML inclut des mécanismes standards d'auto-extension.
o La description du métamodèle d'UM L est standardisée (OMG-MOF). Note : UML n'est pas une mode' c'est un investissement fiable !
- >Le rôle d'UML :
o Si l'on parle de méthode objet pour UML, c'est par abus de langage!
o Propose aussi un processus, qui régit l'enchaînement des activités de production d'une entreprise.
o UML a été pensé pour permettre de modéliser les activités de l'entreprise, pas pour les régir.
o Un processus de développement logiciel universel est une utopie :
n Impossible de prendre en compte toutes les organisations et cultures d'entreprises.
n Un processus est adapté (donc très lié) au domaine d'activité de l'entreprise.
n Même si un processus constitue un cadre général, il faut l'adapter de manière précise au contexte de l'entreprise.
o UML est fondé sur un métamodèle, qui définit :
n les éléments de modélisation (les concepts manipulés par le langage),
n la sémantique de ces éléments (leur définition et le sens de leur utilisation).
o Un métamodèle est une description très formelle de tous les concepts d'un langage. Il limite les
ambiguiités et encourage la construction d'outils.
o Le métamodèle d'UML permet de classer les concepts du langage (selon leur niveau d'abstraction ou domaine d'application) et expose sa structure.
o Le métamodèle UML est lui-même décrit par un méta-métamodèle (OMG-MOF).
o UML propose aussi une notation, qui permet de représenter graphiquement les éléments de modélisation du métamodèle.
o Cette notation graphique est le support du langage UML.
o différentes vues complémentaires d'un système, qui guident l'utilisation des concepts objets,
o plusieurs niveaux d'abstraction, qui permettent de mieux contrôler la complexité dans l'expression des solutions objets.
o Sa notation graphique permet d'exprimer visuellement une solution objet.
o L'aspect formel de sa notation limite les ambiguités et les incompréhensions.
o Son aspect visuel facilite la comparaison et l'évaluation de solutions.
o Mais cet aspect méthodologique d'UM L ne doit pas vous induire en erreur.
o UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus d'élaboration des modèles! Qualifier UML de "méthode objet" n'est donc pas tout à fait approprié.
o Les auteurs d'UM L sont tout à fait conscients de l'importance du processus, mais ce sujet a été intentionnellement exclu des travaux de l'OMG.
Comment prendre en compte toutes les organisations et cultures d'entreprises ?
Un processus est adapté (donc très lié) au domaine d'activité de l'entreprise ; même s'il constitue un cadre général, il faut l'adapter au contexte de l'entreprise. Bref, améliorer un processus est une discipline à part entière, c'est un objectif qui dépasse très largement le cadre de l'OMA.
Cependant, même si pour l'OMG, l'acceptabilité industrielle de la modélisation objet passe d'abord par la disponibilité d'un langage d'analyse objet performant et standard, les auteurs d'UML préconisent d'utiliser une démarche :
D'après les auteurs d'UML, un processus de développement qui possède ces qualités fondamentales "devrait" favoriser la réussite d'un projet. Une source fréquente de malentendus sur UML a pour origine la faculté d'UML de modéliser un processus, pour le documenter et l'optimiser par exemple. En fin de compte, qu'est-ce qu'un processus ? Un ensemble d'activités coordonnées et régulées, en partie ordonnées, dont le but est de créer un produit (matériel ou intellectuel). UML permet tout à fait de modéliser les activités (c'est-à-dire la dynamique) d'un processus, de décrire le rôle des acteurs du processus, la structure des éléments manipulés et produits, etc...
L'intégration d'UML dans un processus n'est pas triviale et améliorer un processus est un tâche complexe et longue. Les auteurs d'UML sont tout à fait conscients de l'importance du processus, mais l'acceptabilité industrielle de la modélisation objet passe d'abord par la disponibilité d'un langage d'analyse objet performant et standard.
Son indépendance par rapport aux langages d'implémentation, domaine d'application, processus... en font un langage universel. Avant tout est un support de communication performant, qui facilite la représentation et la compréhension de solutions objet :
La notation graphique d'UM L n'est que le support du langage. La véritable force d'UM L, c'est qu'il repose sur un métamodèle. En d'autres termes : la puissance et l'intérêt d'UML' c'est qu'il normalise la sémantique des concepts qu'il véhicule.
Qu'une association d'héritage entre deux classes soit représentée par une flèche terminée par un triangle ou un cercle, n'a que peu d'importance par rapport au sens que cela donne à votre modèle. La notation graphique est essentiellement guidée par des considérations esthétiques, même si elle a été pensée dans ses moindres détails.
UML est donc bien plus qu'un simple outil qui permet de "dessiner" des représentations mentales... Il permet de parler un langage commun, normalisé mais accessible, car visuel. Il représente un juste milieu entre langage mathématique et naturel, pas trop complexe mais suffisamment rigoureux, car basé sur un métamodèle.
Décrit de manière très précise tous les éléments de modélisation (les concepts véhiculés et manipulés par le langage) et la sémantique de ces éléments (leur définition et le sens de leur utilisation). En d'autres termes : UML normalise les concepts objet.
Un métamodèle permet de limiter les ambiguiités et encourage la construction d'outils. Il permet aussi de classer les différents concepts du langage (selon leur niveau d'abstraction ou leur domaine d'application) et expose ainsi clairement sa structure. Enfin, on peut noter que le métamodèle d'UML est lui-même décrit par un méta-métamodèle de manière standardisée, à l'aide de MOF (Meta Object Facility : norme OMG de description des métamodèles). Cela vous semble peut-être anecdotique, mais prouve si nécessaire le soin apporté par l'OMG pour définir UML.
Véritable clé de voûte de l'OMA, UML est donc un outil indispensable pour tous ceux qui ont compris que programmer objet, c'est d'abord concevoir objet. UML n'est pas à l'origine des concepts objets, mais il en constitue une étape majeure, car il unifie les différentes approches et en donne une définition plus formelle.
- >Les points forts d'UML :
o gain de précision
o gage de stabilité
o encourage l'utilisation d'outils
o Il cadre l'analyse.
o Il facilite la compréhension de représentations abstraites complexes.
o Son caractère polyvalent et sa souplesse en font un langage universel.
- >Les points faibles d'UM L:
L'abstraction est un des piliers de l'approche objet.
o Il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une entité, en vue d'une utilisation précise.
o L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d'une entité, retenues par un observateur.
o Un modèle définit une frontière entre la réalité et la perspective de l'observateur. Ce n'est pas "la réalité", mais une vue très subjective de la réalité.
o Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des aspects importants de la réalité, il en donne donc une vue juste et pertinente.
o Modèle météorologique : à partir de données d'observation (satellite ...), permet de prévoir les conditions climatiques pour les jours à venir.
o Modèle économique : peut par exemple permettre de simuler l'évolution de cours boursiers en fonction d'hypothèses macro-économiques (évolution du chômage, taux de croissance...).
o Modèle démographique : définit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des études statistiques, d'augmenter l'impact de démarches commerciales,...
Le caractère abstrait d'un modèle doit notamment permettre :
o de faciliter la compréhension du système étudié --> Un modèle réduit la complexité du système étudié.
o de simuler le système étudié représenté par un modèle qui reproduit ses comportements.
Un modèle réduit (décompose) la réalité, dans le but de disposer d'éléments de travail exploitables par des moyens mathématiques ou informatiques : modèle / réalité — digital / analogique
3.2. Comment modéliser avec UML ?
o Guidée par les besoins des utilisateurs du système,
o Centrée sur l'architecture logicielle.
D'après les auteurs d'UML, un processus de développement possède ces qualités doit favoriser la réussite d'un projet.
3.3. Une démarche itérative et incrémentale:
3.4. Une démarche pilotée par les besoins des utilisateurs :
o Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce que doit être le système).
o Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système).
o A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs.
o A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs.
o A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.
4.1. Une démarche centrée sur l'architecture :
Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité...).
Cette vue ("4+1") a fortement inspiré UML :
Les 4+1 vues permettent de mettre en évidence les différents aspects du logiciel à réaliser.
-La vue des cas d'utilisation:Traite les spécifications fonctionnels du logiciel : (guide et justifie les autres vues).
-La vue logique : Modélise les éléments structurés du système (les classes).
-La vue des composants : Décrit l'organisation des composants physique du logiciel (Fichiers sources, BD, DLL, ...etc). -La vue des processus:Traite les aspects multitâches et concurrents du logiciel. -La vue de déploiement : Répartition des composants physiques sur le matériel.
4.2. Vues Statiques:
o Conceptualisation et les cas d'utilisation
o Structuration des modèles (paquetages, collaboration)
o les objets, le diagramme d'objets et les classes
o le diagramme de classes
o les stéréotypes
o le diagramme de composants
o le diagramme de déploiement
4.3. Vues Dynamiques :
o le diagramme de collaboration
o synchronisation des messages
o les objets actifs
o le diagramme de séquence
o le diagramme d'états-transitions
o le diagramme d'activités
5.1. Aspect statique:
Décrit l'aspect structurel du logiciel, c-à-d les classes, les objets constituant le système et les relations entre eux.
5.2. Aspect dynamique :
Décrit le comportement des objets à l'intérieur du système c'est-à-dire changement d'état des objets en réponse à certains événements.
5.3. Aspect fonctionnel :
Décrit les fonctionnalités réalisées par les objets du système par l'intermédiaire de leurs opérations.
o permettent d'identifier les fonctionnalités principales (critiques) du système.
-Cas d'utilisation (use cases) :
-Le modèle conceptuel :
Le modèle conceptuel est le type de diagramme UML qui possède la notation la plus simple; mais paradoxalement c'est aussi celui qui est le plus mal compris!
Pour éviter de foncer droit dans un mur et mener à bien ce projet critique pour Ericsson, Jacobson a eu une idée. Plutôt que de continuer à construire une tour de Babel, pourquoi ne pas remettre à plat les objectifs réels du projet ? En d'autres termes : quels sont les besoins réels des clients, ceux qui conditionneront la réussite du projet ? Ces besoins critiques, une fois identifiés et structurés, permettront enfin de cerner "ce qui est important pour la réussite du projet". Le bénéfice de cette démarche simplificatrice est double. D'une part, tous les acteurs du projet ont une meilleure compréhension du système à développer, d'autre part, les besoins des utilisateurs, une fois clarifiés, serviront de fil rouge, tout au long du cycle de développement.
A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs ; à chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs et à chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits. Simple mais génial. Pour la petite histoire, sacheZ que grâce à cette démarche initiée par Jacobson, Ericsson a réussi à mener à bien son projet et a gagné une notoriété internationale dans le marché de la commutation.
La détermination et la compréhension des besoins sont souvent difficiles car les intervenants sont noyés sous de trop grandes quantités d'informations. Or, comment mener à bien un projet si l'on ne sait pas où l'on va ?
Jacobson identifie les caractéristiques suivantes pour les modèles :
Notes :
Mais un modèle conceptuel qui identifie les besoins avec un plus grand niveau d'abstraction reste indispensable. Avec des systèmes complexes, filtrer l'information, la simplifier et mieux l'organiser, c'est rendre l'information exploitable. ProduiseZ de l'information éphémère, complexe et confuse, vous obtiendreZ un joyeux "désordre".
Remarque:
UtiliseZ les use cases tels qu'ils ont été pensé par leurs créateurs! UML est issu du terrain. Si vous utiliseZ les use cases sans avoir en tête la démarche sous-jacente, vous n'en tirereZ aucun bénéfice.
r*Eléments de base des cas d'utilisation :
o L'acteur peut consulter ou modifier l'état du système.
o En réponse à l'action d'un acteur, le système fournit un service qui correspond à son besoin.
o Les acteurs peuvent être classés (hiérarchisés).
o Les uses cases peuvent être structurés.
o Les uses cases peuvent être organisés en paquetages (packages).
o L'ensemble des use cases décrit les objectifs (le but) du système.
