Cours UML les diagrammes de composants et de déploiement

Cours UML les diagrammes de composants et de déploiement, tutoriel & guide de travaux pratiques en pdf.

Les méthodes objet et la genèse d’UML

Méthodes ?
• Les premières méthodes d’analyse (années 70)
• Découpe cartésienne (fonctionnelle et hiérarchique) d’un système.
• L’approche systémique (années 80)
• Modélisation des données + modélisation des traitements (Merise, Axial, IE…).
• L’émergence des méthodes objet (1990-1995)
• 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) ?
• Plus de 50 méthodes objet sont apparues durant cette période (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE…) !
• Aucun méthode ne s’est réellement imposée.
• Les premiers consensus (1995)
• OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d’un système UML, le langage de modélisation objet unifié par Laurent Piechocki
• Issue du centre de R&D de General Electric.
• Notation graphique riche et lisible.
• OOD (Grady Booch) : vues logiques et physiques du système
• Définie pour le DOD, afin de rationaliser de développement d’applications ADA, puis C++.
• Ne couvre pas la phase d’analyse dans ses 1ères versions (préconise SADT).
• Introduit le concept de package (élément d’organisation des modèles)
• OOSE (Ivar Jacobson) : couvre tout le cycle de développement
• Issue d’un centre de développement d’Ericsson, en Suède.
• La méthodologie repose sur l’analyse des besoins des utilisateurs.
• L’unification et la normalisation des méthodes (1995-1997)
• UML aujourd’hui : un standard incontournable
• UML est le résultat d’un large consensus (industriels, méthodologistes…).
• UML est le fruit d’un travail d’experts reconnus.
• UML est issu du terrain.
• UML est riche (il couvre toutes les phases d’un cycle de développement).
• UML est ouvert (il est indépendant du domaine d’application et des langages d’implémentation).
• 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…).
• XMI (format d’échange standard de modèles UML).
• UML évolue mais reste stable !
• L’OMG RTF (nombreux acteurs industriels) centralise et normalise les évolutions d’UML au niveau international.
• Les groupes d’utilisateurs UML favorisent le partage des expériences.
• De version en version, UML gagne en maturité et précision, tout en restant stable.
• UML inclut des mécanismes standards d’auto-extension.
• La description du métamodèle d’UML est standardisée (OMG-MOF).

A quoi sert UML ?
UML n’est pas une méthode ou un processus !
• Si l’on parle de méthode objet pour UML, c’est par abus de langage !
• Ce constat vaut aussi pour OMT ou d’autres techniques / langages de modélisation.
• Une méthode propose aussi un processus, qui régit notamment l’enchaînement des activités de production d’une entreprise.
• UML a été pensé pour permettre de modéliser les activités de l’entreprise, pas pour les régir (ce n’est pas CMM ou SPICE).
• Un processus de développement logiciel universel est une utopie :
• Impossible de 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 si un processus constitue un cadre général, il faut l’adapter de manière précise au contexte de l’entreprise.
UML est un langage pseudo-formel
• UML est fondé sur un métamodèle, qui définit :
• les éléments de modélisation (les concepts manipulés par le langage),
• la sémantique de ces éléments (leur définition et le sens de leur utilisation).
• Un métamodèle est une description très formelle de tous les concepts d’un langage. Il limite les ambiguïtés et encourage la construction d’outils.
• 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.
• Le métamodèle UML est lui-même décrit par un méta-métamodèle (OMG-MOF).
• UML propose aussi une notation, qui permet de représenter graphiquement les éléments de modélisation du métamodèle.
• Cette notation graphique est le support du langage UML.
UML cadre l’analyse objet, en offrant :
• différentes vues (perspectives) complémentaires d’un système, qui guident l’utilisation des concept objets,
• plusieurs niveaux d’abstraction, qui permettent de mieux contrôler la complexité dans l’expression des solutions objets.
UML est un support de communication
• Sa notation graphique permet d’exprimer visuellement une solution objet.
• L’aspect formel de sa notation limite les ambiguïtés et les incompréhensions.
• Son aspect visuel facilite la comparaison et l’évaluation de solutions.
• Son indépendance (par rapport aux langages d’implémentation, domaine d’application, processus…) en font un langage universel.

Avantages et inconvénients d’UML

Les points forts d’UML
UML est un langage formel et normalisé
• gain de précision
• gage de stabilité
• encourage l’utilisation d’outils
UML est un support de communication performant
• Il cadre l’analyse.
• Il facilite la compréhension de représentations abstraites complexes.
• Son caractère polyvalent et sa souplesse en font un langage universel.
Les points faibles d’UML
• La mise en pratique d’UML nécessite un apprentissage et passe par une période d’adaptation.
Même si l’Espéranto est une utopie, la nécessité de s’accorder sur des modes d’expression communs est vitale en informatique. UML n ‘est pas à l’origine des concepts objets, mais en constitue une étape majeure, car il unifie les différentes approches et en donne une définition plus formelle.
• Le processus (non couvert par UML) est une autre clé de la réussite d’un projet.
Or, 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.

Qu’est-ce qu’un modèle ?

• Un modèle est une abstraction de la réalité L’abstraction est un des piliers de l’approche objet.
• Il s’agit d’un processus qui consiste à identifier les caractéristiques intéressantes d’une entité, en vue d’une utilisation précise.
• 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.
• Un modèle est une vue subjective mais pertinente de la réalité
• 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é.
• 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.
• Quelques exemples de modèles
• Modèle météorologique :
à partir de données d’observation (satellite …), permet de prévoir les conditions climatiques pour les jours à venir.
• 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…).
• 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, etc…
• Caractéristiques fondamentales des modèles.

I – PRESENTATION D’UML
I-A – Un peu d’Histoire
I-A-1 – Approche fonctionnelle vs. approche objet
I-A-2 – Quels sont les autres concepts importants de l’approche objet ?
I-B – Les méthodes objet et la genèse d’UML
I-B-1 – Méthodes ?
I-B-2 – A quoi sert UML ?
I-C – Avantages et inconvénients d’UML
I-C-1 – Les points forts d’UML
I-C-2 – Les points faibles d’UML
II – MODELISER AVEC UML
II-A – Qu’est-ce qu’un modèle ?
II-B – Comment modéliser avec UML ?
II-C – Les vues statiques d’UML
II-C-1 – LES PAQUETAGES
II-C-2 – LA COLLABORATION
II-C-3 – INSTANCES ET DIAGRAMME D’OBJETS
II-C-4 – LES CLASSES
II-C-5 – DIAGRAMME DE CLASSES
II-C-6 – DIAGRAMMES DE COMPOSANTS ET DE DEPLOIEMENT
II-D – Les vues dynamiques d’UML
II-D-1 – LES CAS D’UTILISATION
II-D-2 – COLLABORATION ET MESSAGES
II-D-3 – DIAGRAMME DE SEQUENCE
II-D-4 – DIAGRAMME D’ETATS-TRANSITIONS
II-D-5 – DIAGRAMME D’ACTIVITES
II-E – Conclusion
II-E-1 – Programmer objet ?
II-E-2 – Utiliser UML ?