3.53.5 étoiles sur 5 a partir de 1 votes. Votez ce document: ☆☆☆☆☆★★★★★
Introduction au Cours Le processus unifié
I-A-2-e - L'approche objet, hier et aujourd'hui
Les concepts objet sont stables et éprouvés (issus du terrain)
Simula, 1er 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) à l'aide de :
classes
associations entre classes
hiérarchies de classes
messages entre objets
Le 1er compilateur C++ date de 1980, et C++ est normalisé par l'ANSI.
De nombreux langages orientés objets académiques ont étayés les concepts objets : Eiffel, Objective C, Loops...
Les concepts objet sont anciens, mais ils n'ont jamais été autant d'actualité
L'approche fonctionnelle n'est pas adaptée au développement d'applications qui évoluent sans cesse et dont la complexité croit continuellement.
L'approche objet a été inventée pour faciliter l'évolution d'applications complexes.
De nos jours, les outils orientés objet sont fiables et performants
Les compilateurs C++ produisent un code robuste et optimisé.
De très nombreux outils facilitent le développement d'applications C++ :
générateurs d'IHM (Ilog Views, TeleUse...)
bibliothèques (STL, USL, Rogue Wave, MFC...)
environnements de développement intégrés (Developper Studio, Sniff+...)
outils de qualimétrie et de tests (Cantata++, Insure++, Logiscope...)
bases de données orientées objet (O2, ObjectStore, Versant...)
I-A-2-f - L'approche objet : une solution parfaite ?
En résumé, l'approche objet c'est :
Un ensemble de concepts stables, éprouvés et normalisés.
Une solution destinée à faciliter l'évolution d'applications complexes.
Une panoplie d'outils et de langages performants pour le développement
Oui, MAIS..
Malgré les apparences, il est plus naturel pour nos esprits cartésiens, de décomposer un problème informatique sous forme d'une hiérarchie de fonctions atomiques et de données, qu'en terme d'objets et d'interaction entre ces objets. De plus, le vocabulaire précis est un facteur d'échec important dans la mise en oeuvre d'une approche objet.
L'approche objet est moins intuitive que l'approche fonctionnelle !
Quels moyens utiliser pour faciliter l'analyse objet ?
Quels critères identifient une conception objet pertinente ?
Comment comparer deux solutions de découpe objet d'un système ?
L'application des concepts objets nécessite une grande rigueur !
Le vocabulaire est précis (risques d'ambiguïtés, d'incompréhensions).
Comment décrire la structure objet d'un système de manière pertinente ?
I-A-2-g - Quels sont les remèdes aux inconvénients de l'approche objet ?
Un langage pour exprimer les concepts objet qu'on utilise, afin de pouvoir :
Représenter des concepts abstraits (graphiquement par exemple).
Limiter les ambiguïtés (parler un langage commun).
Faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions).
Une démarche d'analyse et de conception objet, pour :
Ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet dès le départ.
Définir les vues qui permettent de couvrir tous les aspects d'un système, avec des concepts objets.
Bref : il nous faut un outil qui apporte une dimension méthodologique à l'approche objet, afin de mieux maîtriser sa richesse et sa complexité.
I-B - Les méthodes objet et la genèse d'UML
I-B-1 - 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
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 (Unified Modeling Langage), la fusion et synthèse des méthodes dominantes :
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).
>>> UML n'est pas une mode, c'est un investissement fiable !
I-B-2 - 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.
I-C - Avantages et inconvénients d'UML
I-C-1 - 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.
I-C-2 - 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.
II - MODELISER AVEC UML
II-A - 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
Le caractère abstrait d'un modèle doit notamment permettre :
de faciliter la compréhension du système étudié
> Un modèle réduit la complexité du système étudié.
de simuler le système étudié
> Un modèle représente le système étudié et 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
II-B - Comment modéliser avec UML ?
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 !
Cependant, dans le cadre de la modélisation d'une application informatique, les auteurs d'UML préconisent d'utiliser une démarche :
itérative et incrémentale,
guidée par les besoins des utilisateurs du système,
centrée sur l'architecture logicielle.
D'après les auteurs d'UML, un processus de développement qui possède ces qualités devrait favoriser la réussite d'un projet.
II-B-1 - Une démarche itérative et incrémentale ?
L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes.
Cette démarche devrait aussi s'appliquer au cycle de développement dans son ensemble, en favorisant le prototypage.
Le but est de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes complexes.
II-B-2 - Une démarche pilotée par les besoins des utilisateurs ?
Avec UML, ce sont les utilisateurs qui guident la définition des modèles :
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).
Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système).
Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de développement (itératif et incrémental) :
A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs.
A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs.
A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.
II-B-3 - Une démarche centrée sur l'architecture ?
Une architecture adaptée est la clé de voûte du succès d'un développement.
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 :
II-B-4 - Définir une architecture avec UML (détail de la "vue 4+1")
La vue logique
Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle modélise les éléments et mécanismes principaux du système.
Elle identifie les éléments du domaine, ainsi que les relations et interactions entre ces éléments :
les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
ils sont indispensables à la mission du système,
ils gagnent à être réutilisés (ils représentent un savoir-faire).
Cette vue organise aussi (selon des critères purement logiques), les éléments du domaine en "catégories" :
pour répartir les tâches dans les équipes,
regrouper ce qui peut être générique,
isoler ce qui est propre à une version donnée, etc...
La vue des composants
Cette vue de bas niveau (aussi appelée "vue de réalisation"), montre :
L'allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de données, exécutables, etc...).
En d'autres termes, cette vue identifie les modules qui réalisent (physiquement) les classes de la vue logique.
L'organisation des composants, c'est-à-dire la distribution du code en gestion de configuration, les dépendances entre les composants...
Les contraintes de développement (bibliothèques externes...).
La vue des composants montre aussi l'organisation des modules en "sous-systèmes", les interfaces des sous-systèmes et leurs dépendances (avec d'autres sous-systèmes ou modules).
La vue des processus
Cette vue est très importante dans les environnements multitâches ; elle montre :
La décomposition du système en terme de processus (tâches).
Les interactions entre les processus (leur communication).
La synchronisation et la communication des activités parallèles (threads).
La vue de déploiement
Cette vue très importante dans les environnements distribués, décrit les ressources matérielles et la répartition du logiciel dans ces ressources :=
La disposition et nature physique des matériels, ainsi que leurs performances.
L'implantation des modules principaux sur les noeuds du réseau.
Les exigences en terme de performances (temps de réponse, tolérance aux fautes et pannes...).
La vue des besoins des utilisateurs
Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres.
Dessiner le plan (l'architecture) d'un système informatique n'est pas suffisant, il faut le justifier !
Cette vue définit les besoins des clients du système et centre la définition de l'architecture du système sur la satisfaction (la réalisation) de ces besoins.
A l'aide de scénarios et de cas d'utilisation, cette vue conduit à la définition d'un modèle d'architecture pertinent et cohérent.
Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture.
Elle motive les choix, permet d'identifier les interfaces critiques et force à se concentrer sur les problèmes importants.
II-B-5 - Résumons la démarche...
Modéliser une application ?
Mais comme UML n'est pas un processus... Quelle démarche utiliser ?
Trouver un bon modèle est une tâche difficile mais capitale !
1 Optez pour une approche itérative et incrémentale.
2 Centrez votre démarche sur l'analyse des besoins des utilisateurs.
3 Prenez grand soin à la définition de l'architecture de votre application (l'approche "4+1" permet de mieux la cerner).
OK OK , mais en pratique ?
Bien qu'UML n'est pas un processus, il facilite une démarche d'analyse itérative et incrémentale, basée sur les niveaux d'abstraction.
Les niveaux d'abstraction permettent de structurer les modèles.
Un micro-processus régit les itérations à niveau d'abstraction constant.
Un macro-processus régit le passage de niveau à niveau.
Une démarche incrémentale consiste à construire les modèles de spécification et de conception en plusieurs étapes (cible = catégories).
Le schéma ci-dessous montre les niveaux d'abstraction principaux, qu'on peut identifier dans un processus de développement logiciel :
II-B-6 - Elaboration plutôt que transformation
UML opte pour l'élaboration des modèles, plutôt que pour une approche qui impose une barrière stricte entre analyse et conception :
Les modèles d'analyse et de conception ne diffèrent que par leur niveau de détail, il n'y a pas de différence dans les concepts utilisés.
UML n'introduit pas d'éléments de modélisation propres à une activité (analyse, conception...) ; le langage reste le même à tous les niveaux d'abstraction.
Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction.
L'élaboration encourage une approche non linéaire (les "retours en arrière" entre niveaux d'abstraction différents sont facilités).
La traçabilité entre modèles de niveaux différents est assurée par l'unicité du langage.
II-B-7 - Détail des différents niveaux d'abstraction (phases du macro-processus)
Conceptualisation
L'entrée de l'analyse à ce niveau, est le dossier d'expression des besoins client.
A ce niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs.
Il ne faut pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins !
Le but de la conceptualisation est :
de définir le contour du système à modéliser (de spécifier le "quoi"),
de capturer les fonctionnalités principales du système, afin d'en fournir une meilleure compréhension (le modèle produit sert d'interface entre les acteurs du projet),
de fournir une base à la planification du projet.
Analyse du domaine
L'entrée de l'analyse à ce niveau, est le modèle des besoins clients (les "cas d'utilisation" UML).
Il s'agit de modéliser les éléments et mécanismes principaux du système.
On identifie les éléments du domaine, ainsi que les relations et interactions entre ces éléments :
les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
ils sont indispensables à la mission du système,
ils gagnent à être réutilisés (ils représentent un savoir-faire).
A ce stade, on organise aussi (selon des critères purement logiques), les éléments du domaine en "catégories" :
pour répartir les tâches dans les équipes,
regrouper ce qui peut être générique, etc...
Analyse applicative
A ce niveau, on modélise les aspects informatiques du système, sans pour autant rentrer dans les détails d'implémentation.
Les interfaces des éléments de modélisation sont définis (cf. encapsulation).
Les relations entre les éléments des modèles sont définies.
Les éléments de modélisation utilisés peuvent être propres à une version du système.
Conception
On y modélise tous les rouages d'implémentation et on détaille tous les éléments de modélisation issus des niveaux supérieurs.
Les modèles sont optimisés, car destinés à être implémentés.
II-B-8 - Activités des micro-processus d'analyse (niveau d'abstraction constant)
A chaque niveau d'abstraction, un micro-processus régit la construction des modèles.
UML ne régit pas les activités des micro-processus, c'est le principe d'abstraction qui permet l'élaboration itérative et incrémentale des modèles.
Exemple de micro-processus de construction d'un modèle :
identifiez les classes (d'objets) :
recherchez les classes candidates (différentes suivant le niveau d'abstraction) à l'aide de diagrammes d'objets (ébauches),
filtrez les classes redondantes, trop spécifiques ou vagues, qui ne représentent qu'une opération ou un attribut,
documentez les caractéristiques des classes retenues (persistances, nombre maximum d'instances, etc.).
identifiez les associations entre classes / interactions entre objets (instances) :
recherchez les connexions sémantiques et les relations d'utilisation,
documentez les relations (nom, cardinalités, contraintes, rôles des classes...),
en spécification, filtrez les relations instables ou d'implémentation,
définissez la dynamique des relations entre objets (les interactions entre instances de classes et les activités associées).
identifiez les attributs et les opérations des classes :
recherchez les attributs dans les modèles dynamiques (recherchez les données qui caractérisent les états des objets),
filtrez les attributs complexes (faites-en des objets) et au niveau spécification, ne représentez pas les valeurs internes propres aux mécanismes d'implémentation,
recherchez les opérations parmi les activités et actions des objets (ne pas rentrer dans le détail au niveau spécification). optimisez les modèles :
choisissez vos critères d'optimisation (généricité, évolutivité, précision, lisibilité, simplicité...),
utilisez la généralisation et la spécialisation (classification),
documentez et détaillez vos modèles, encapsulez. validez les modèles :
vérifiez la cohérence, la complétude et l'homogénéité des modèles,
confrontez les modèles à la critique (comité de relecture...).
II-B-9 - Synthèse de la démarche
Modéliser une application n'est pas une activité linéaire.
Il s'agit d'une tâche très complexe, qui nécessite une approche :
itérative et incrémentale (grâce aux niveaux d'abstraction), car il est plus efficace de construire et valider par étapes, ce qui est difficile à cerner et maîtriser,
centrée sur l'architecture (définie par la vue "4+1"), car il s'agit de la clé de voûte qui conditionne la plupart des qualités d'une application informatique,
guidée par la prise en compte des besoins des utilisateurs (à l'aide des cas d'utilisation), car ce qui motive l'existence même du système à concevoir, c'est la satisfaction des besoins de ses utilisateurs.
II-B-10 - Les diagrammes UML
OK pour la démarche d'élaboration d'un modèle, mais...
II-B-10-a - Comment "rédiger" un modèle avec UML ?
UML permet de définir et de visualiser un modèle, à l'aide de diagrammes.
Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle ; c'est une perspective du modèle, pas "le modèle".
Chaque type de diagramme UML possède une structure (les types des éléments de modélisation qui le composent sont prédéfinis).
UML, le langage de modélisation objet unifié par Laurent Piechocki
Un type de diagramme UML véhicule une sémantique précise (un type de diagramme offre toujours la même vue d'un système).
Combinés, les différents types de diagrammes UML offrent une vue complète des aspects statiques et dynamiques d'un système.
Par extension et abus de langage, un diagramme UML est aussi un modèle (un diagramme modélise un aspect du modèle global).
II-B-10-b - Quelques caractéristiques des diagrammes UML
Les diagrammes UML supportent l'abstraction. Leur niveau de détail caractérise le niveau d'abstraction du modèle.
La structure des diagrammes UML et la notation graphique des éléments de modélisation est normalisée (document "UML notation guide").
Rappel : la sémantique des éléments de modélisation et de leur utilisation est définie par le métamodèle UML (document "UML semantics").
Le recours à des outils appropriés est un gage de productivité pour la rédaction des diagrammes UML, car :
ils facilitent la navigation entre les différentes vues,
ils permettent de centraliser, organiser, partager, synchroniser et versionner les diagrammes (indispensable avec un processus itératif),
facilitent l'abstraction, par des filtres visuels,
simplifient la production de documents et autorisent (dans certaines limites) la génération de code.
II-B-10-c - Les différents types de diagrammes UML
Vues statiques du système :
diagrammes de cas d'utilisation
diagrammes d'objets
diagrammes de classes
diagrammes de composants
diagrammes de déploiement
Introduction au Cours Le processus unifié
I-A-2-e - L'approche objet, hier et aujourd'hui
Les concepts objet sont stables et éprouvés (issus du terrain)
Simula, 1er 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) à l'aide de :
classes
associations entre classes
hiérarchies de classes
messages entre objets
Le 1er compilateur C++ date de 1980, et C++ est normalisé par l'ANSI.
De nombreux langages orientés objets académiques ont étayés les concepts objets : Eiffel, Objective C, Loops...
Les concepts objet sont anciens, mais ils n'ont jamais été autant d'actualité
L'approche fonctionnelle n'est pas adaptée au développement d'applications qui évoluent sans cesse et dont la complexité croit continuellement.
L'approche objet a été inventée pour faciliter l'évolution d'applications complexes.
De nos jours, les outils orientés objet sont fiables et performants
Les compilateurs C++ produisent un code robuste et optimisé.
De très nombreux outils facilitent le développement d'applications C++ :
générateurs d'IHM (Ilog Views, TeleUse...)
bibliothèques (STL, USL, Rogue Wave, MFC...)
environnements de développement intégrés (Developper Studio, Sniff+...)
outils de qualimétrie et de tests (Cantata++, Insure++, Logiscope...)
bases de données orientées objet (O2, ObjectStore, Versant...)
I-A-2-f - L'approche objet : une solution parfaite ?
En résumé, l'approche objet c'est :
Un ensemble de concepts stables, éprouvés et normalisés.
Une solution destinée à faciliter l'évolution d'applications complexes.
Une panoplie d'outils et de langages performants pour le développement
Oui, MAIS..
Malgré les apparences, il est plus naturel pour nos esprits cartésiens, de décomposer un problème informatique sous forme d'une hiérarchie de fonctions atomiques et de données, qu'en terme d'objets et d'interaction entre ces objets. De plus, le vocabulaire précis est un facteur d'échec important dans la mise en oeuvre d'une approche objet.
L'approche objet est moins intuitive que l'approche fonctionnelle !
Quels moyens utiliser pour faciliter l'analyse objet ?
Quels critères identifient une conception objet pertinente ?
Comment comparer deux solutions de découpe objet d'un système ?
L'application des concepts objets nécessite une grande rigueur !
Le vocabulaire est précis (risques d'ambiguïtés, d'incompréhensions).
Comment décrire la structure objet d'un système de manière pertinente ?
I-A-2-g - Quels sont les remèdes aux inconvénients de l'approche objet ?
Un langage pour exprimer les concepts objet qu'on utilise, afin de pouvoir :
Représenter des concepts abstraits (graphiquement par exemple).
Limiter les ambiguïtés (parler un langage commun).
Faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions).
Une démarche d'analyse et de conception objet, pour :
Ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet dès le départ.
Définir les vues qui permettent de couvrir tous les aspects d'un système, avec des concepts objets.
Bref : il nous faut un outil qui apporte une dimension méthodologique à l'approche objet, afin de mieux maîtriser sa richesse et sa complexité.
I-B - Les méthodes objet et la genèse d'UML
I-B-1 - 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
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 (Unified Modeling Langage), la fusion et synthèse des méthodes dominantes :
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).
>>> UML n'est pas une mode, c'est un investissement fiable !
I-B-2 - 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
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.
I-C - Avantages et inconvénients d'UML
I-C-1 - 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.
I-C-2 - 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.
II - MODELISER AVEC UML
II-A - Qu'est-ce qu'un modèle ?
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
Le caractère abstrait d'un modèle doit notamment permettre :
de faciliter la compréhension du système étudié
> Un modèle réduit la complexité du système étudié.
de simuler le système étudié
> Un modèle représente le système étudié et 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
II-B - Comment modéliser avec UML ?
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 !
Cependant, dans le cadre de la modélisation d'une application informatique, les auteurs d'UML préconisent d'utiliser une démarche :
itérative et incrémentale,
guidée par les besoins des utilisateurs du système,
centrée sur l'architecture logicielle.
D'après les auteurs d'UML, un processus de développement qui possède ces qualités devrait favoriser la réussite d'un projet.
II-B-1 - Une démarche itérative et incrémentale ?
L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes.
Cette démarche devrait aussi s'appliquer au cycle de développement dans son ensemble, en favorisant le prototypage.
Le but est de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes complexes.
Avec UML, ce sont les utilisateurs qui guident la définition des modèles :
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).
Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système).
Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de développement (itératif et incrémental) :
A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs.
A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs.
A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.
II-B-3 - Une démarche centrée sur l'architecture ?
Une architecture adaptée est la clé de voûte du succès d'un développement.
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 :
II-B-4 - Définir une architecture avec UML (détail de la "vue 4+1")
La vue logique
Cette vue de bas niveau (aussi appelée "vue de réalisation"), montre :
L'allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de données, exécutables, etc...).
En d'autres termes, cette vue identifie les modules qui réalisent (physiquement) les classes de la vue logique.
L'organisation des composants, c'est-à-dire la distribution du code en gestion de configuration, les dépendances entre les composants...
Les contraintes de développement (bibliothèques externes...).
La vue des composants montre aussi l'organisation des modules en "sous-systèmes", les interfaces des sous-systèmes et leurs dépendances (avec d'autres sous-systèmes ou modules).
La vue des processus
Cette vue est très importante dans les environnements multitâches ; elle montre :
La décomposition du système en terme de processus (tâches).
Les interactions entre les processus (leur communication).
La synchronisation et la communication des activités parallèles (threads).
La vue de déploiement
Cette vue très importante dans les environnements distribués, décrit les ressources matérielles et la répartition du logiciel dans ces ressources :=
La disposition et nature physique des matériels, ainsi que leurs performances.
L'implantation des modules principaux sur les noeuds du réseau.
Les exigences en terme de performances (temps de réponse, tolérance aux fautes et pannes...).
La vue des besoins des utilisateurs
Modéliser une application ?
Mais comme UML n'est pas un processus... Quelle démarche utiliser ?
Trouver un bon modèle est une tâche difficile mais capitale !
1 Optez pour une approche itérative et incrémentale.
2 Centrez votre démarche sur l'analyse des besoins des utilisateurs.
3 Prenez grand soin à la définition de l'architecture de votre application (l'approche "4+1" permet de mieux la cerner).
OK OK , mais en pratique ?
Bien qu'UML n'est pas un processus, il facilite une démarche d'analyse itérative et incrémentale, basée sur les niveaux d'abstraction.
Les niveaux d'abstraction permettent de structurer les modèles.
Un micro-processus régit les itérations à niveau d'abstraction constant.
Un macro-processus régit le passage de niveau à niveau.
Une démarche incrémentale consiste à construire les modèles de spécification et de conception en plusieurs étapes (cible = catégories).
Le schéma ci-dessous montre les niveaux d'abstraction principaux, qu'on peut identifier dans un processus de développement logiciel :
II-B-6 - Elaboration plutôt que transformation
UML opte pour l'élaboration des modèles, plutôt que pour une approche qui impose une barrière stricte entre analyse et conception :
Les modèles d'analyse et de conception ne diffèrent que par leur niveau de détail, il n'y a pas de différence dans les concepts utilisés.
UML n'introduit pas d'éléments de modélisation propres à une activité (analyse, conception...) ; le langage reste le même à tous les niveaux d'abstraction.
Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction.
L'élaboration encourage une approche non linéaire (les "retours en arrière" entre niveaux d'abstraction différents sont facilités).
La traçabilité entre modèles de niveaux différents est assurée par l'unicité du langage.
II-B-7 - Détail des différents niveaux d'abstraction (phases du macro-processus)
L'entrée de l'analyse à ce niveau, est le dossier d'expression des besoins client.
A ce niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs.
Il ne faut pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins !
Le but de la conceptualisation est :
de définir le contour du système à modéliser (de spécifier le "quoi"),
de capturer les fonctionnalités principales du système, afin d'en fournir une meilleure compréhension (le modèle produit sert d'interface entre les acteurs du projet),
de fournir une base à la planification du projet.
Analyse du domaine
L'entrée de l'analyse à ce niveau, est le modèle des besoins clients (les "cas d'utilisation" UML).
Il s'agit de modéliser les éléments et mécanismes principaux du système.
On identifie les éléments du domaine, ainsi que les relations et interactions entre ces éléments :
les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
ils sont indispensables à la mission du système,
ils gagnent à être réutilisés (ils représentent un savoir-faire).
A ce stade, on organise aussi (selon des critères purement logiques), les éléments du domaine en "catégories" :
pour répartir les tâches dans les équipes,
regrouper ce qui peut être générique, etc...
Analyse applicative
A ce niveau, on modélise les aspects informatiques du système, sans pour autant rentrer dans les détails d'implémentation.
Les interfaces des éléments de modélisation sont définis (cf. encapsulation).
Les relations entre les éléments des modèles sont définies.
Les éléments de modélisation utilisés peuvent être propres à une version du système.
Conception
A chaque niveau d'abstraction, un micro-processus régit la construction des modèles.
UML ne régit pas les activités des micro-processus, c'est le principe d'abstraction qui permet l'élaboration itérative et incrémentale des modèles.
Exemple de micro-processus de construction d'un modèle :
identifiez les classes (d'objets) :
recherchez les classes candidates (différentes suivant le niveau d'abstraction) à l'aide de diagrammes d'objets (ébauches),
filtrez les classes redondantes, trop spécifiques ou vagues, qui ne représentent qu'une opération ou un attribut,
documentez les caractéristiques des classes retenues (persistances, nombre maximum d'instances, etc.).
identifiez les associations entre classes / interactions entre objets (instances) :
recherchez les connexions sémantiques et les relations d'utilisation,
documentez les relations (nom, cardinalités, contraintes, rôles des classes...),
en spécification, filtrez les relations instables ou d'implémentation,
définissez la dynamique des relations entre objets (les interactions entre instances de classes et les activités associées).
identifiez les attributs et les opérations des classes :
Modéliser une application n'est pas une activité linéaire.
Il s'agit d'une tâche très complexe, qui nécessite une approche :
itérative et incrémentale (grâce aux niveaux d'abstraction), car il est plus efficace de construire et valider par étapes, ce qui est difficile à cerner et maîtriser,
centrée sur l'architecture (définie par la vue "4+1"), car il s'agit de la clé de voûte qui conditionne la plupart des qualités d'une application informatique,
guidée par la prise en compte des besoins des utilisateurs (à l'aide des cas d'utilisation), car ce qui motive l'existence même du système à concevoir, c'est la satisfaction des besoins de ses utilisateurs.
II-B-10 - Les diagrammes UML
OK pour la démarche d'élaboration d'un modèle, mais...
II-B-10-a - Comment "rédiger" un modèle avec UML ?
UML permet de définir et de visualiser un modèle, à l'aide de diagrammes.
Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle ; c'est une perspective du modèle, pas "le modèle".
Chaque type de diagramme UML possède une structure (les types des éléments de modélisation qui le composent sont prédéfinis).
UML, le langage de modélisation objet unifié par Laurent Piechocki
Un type de diagramme UML véhicule une sémantique précise (un type de diagramme offre toujours la même vue d'un système).
Combinés, les différents types de diagrammes UML offrent une vue complète des aspects statiques et dynamiques d'un système.
Par extension et abus de langage, un diagramme UML est aussi un modèle (un diagramme modélise un aspect du modèle global).
II-B-10-b - Quelques caractéristiques des diagrammes UML
