Cours démarche générale de modélisation avec UML, tutoriel & guide de travaux pratiques en pdf.

Démarche générale de modélisation avec UML

Qu’est-ce qu’un modèle ?
Définition d’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.
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.

Comment modéliser avec UML ?

 Proposition de démarche
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 : UML n’est donc pas une méthode de modélisation.
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.
Une démarche itérative et incrémentale 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 doit 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.
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) :
– à 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.
– à chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.

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). Ph. Kruchten défend l’idée que l’architecture logicielle doit être une discipline à part entière. Il propose que plusieurs perspectives concourent à l’expression de l’architecture d’un système et il explique qu’il est nécessaire de garantir la séparation et l’indépendance de ces différentes perspectives. L’évolution de l’une des perspectives ne doit pas avoir d’impact (sinon limité) sur les autres.
La relation entre les différentes perspectives a été représentée par ph. Kruchten dans le schéma suivant, dit « schéma 4+1 vues ».

La vue « 4+1 » de ph. Kruchten

La vue logique
Cette vue concerne « l’intégrité de conception ».
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 « notions de classes et de relations » :
– 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 concerne « l’intégrité de gestion ».
Elle exprime la perspective physique de l’organisation du code en termes de modules, de composants et surtout des concepts du langage ou de l’environnement d’implémentation.
Dans cette perspective, l’architecte est surtout concerné par les aspects de gestion du code, d’ordre de compilation, de réutilisation, d’intégration et d’autres contraintes de développement pur. Pour représenter cette perspective, UML fournit des concepts adaptés tels que les modules, les composants, les relations de dépendance, l’interface …
Cette vue de bas niveau (aussi appelée « vue de réalisation »), montre ainsi :
– l’allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de données, exécutables, etc…). 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…).
– 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 concerne « l’intégrité d’exécution ».
Cette vue est très importante dans les environnements multitâches ; elle exprime la perspective sur les activités concurrentes et parallèles. Elle montre ainsi :
– 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 concerne « l’intégrité de performance ». Elle exprime la répartition du système à travers un réseau de calculateurs et de noeuds logiques de traitements . Cette vue est particulièrement utile pour décrire la distribution d’un système réparti.
Elle montre :
– 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 cas d’utilisation
Cette vue est particulière en ce sens qu’elle guide toutes les autres.
Cette vue permet :
– de trouver le « bon » modèle Les cas d’utilisation permettent de guider la modélisation. L’utilisation des scénarios et des cas d’utilisation s’avère plus rigoureuse et plus systématique que les entretiens et l’analyse des documents pour découvrir les abstractions du domaine.
– d’expliquer et de justifier ses choix Il est en effet nécessaire d’expliquer le système, de justifier les choix qui ont guidé sa conception et son fonctionnement pour pouvoir le construire, le maintenir et le tester. Pour cela UML offre des concepts adaptés tels que les scénarios et les cas d’utilisation.

Les niveaux d’abstraction

Une non-démarcation entre conception et analyse 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.
Les niveaux d’abstraction
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.

TABLE DES MATIERES
INTRODUCTION
UML est une norme
UML est un langage de modélisation objet.
UML est un support de communication
UML est un cadre méthodologique pour une analyse objet
I). Le contexte d’apparition d’UML
I.1) Approche fonctionnelle versus approche objet
I.1.2) L’approche objet
I.2) La genèse d’UML
I.2.1) Historique des méthodes d’analyse
I.2.2) Cadre d’utilisation d’UML
I.2.3) Points forts d’UML
I.2.4) Points faibles d’UML
II) Démarche générale de modélisation avec UML
II.1) Qu’est-ce qu’un modèle ?
II.1.1) Définition d’un modèle
II.1.2) Caractéristiques fondamentales des modèles
II.2 ) Comment modéliser avec UML ?
II.2.1) Proposition de démarche
II.2.2) La vue « 4+1 » de ph. Kruchten
II.2.3) Les niveaux d’abstraction
II.4 ) L’utilisation de diagrammes
II.4.1) Définition d’un diagramme
II.4.2) caractéristiques des diagrammes UML
II.4.3) Les différents types de diagrammes UML
III) Les Différents types de diagrammes
III.1) Vues statiques du système
III.1.1) diagrammes de cas d’utilisation
III.1.2) diagrammes de classes
III.1.3) diagrammes d’objets
III.1.4) diagrammes de composants
III.1.5) diagrammes de déploiement
III.2) Vues dynamiques du système
III.2.1) diagrammes de collaboration
III.2.2) diagrammes de séquence
III.2.3) diagrammes d’états-transitions
III.2.4) diagrammes d’activités
IV) Le processus unifié
IV.1) Le processus unifié est piloté par les cas d’utilisation
IV.1.1) Présentation générale
IV.1.2) Stratégie des cas d’utilisation
IV.2) Le processus unifié est centré sur l’architecture
IV.2.1) Liens entre cas d’utilisation et architecture
IV.2.2) Marche à suivre
IV.3) Le processus unifié est itératif et incrémental
IV.4) Le cycle de vie du processus unifié
V) Eléments de comparaisons entre MERISE et UML
V.1) Les principes
V.1.1) L’approche systémique
V.1.2) Les cycles de construction du système d’information
V.1.3) L’approche fonctionnelle
V.1.4) La séparation données-traitements
V.1.5) L’ approche qui part du général vers le particulier
V.2) La modélisation métier
V.2.1) Le domaine
V.2.2) L’acteur
V.2.3) Les flux
V.2.4) Les modèles conceptuels et organisationnels
V.3) La démarche
V.3.1) Les modèles utilisés
V.3.2) les étapes du processus d’élaboration du système d’information
V.4) Conclusion
CONCLUSION GENERALE