Professional Documents
Culture Documents
INF 423
Développement d’applications
Valéry MONTHE
cours.monthe@gmail.com
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 1 sur 12
Sommaire
1.3. Maquette rapide de l’IHM de l’application (non couverte par UML) ....................................... 4
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 2 sur 12
A. UML et méthodologie
Cette partie du support présente une méthodologie minimale permettant de passer de l’expression des
besoins au code de l’application avec UML. Cette problématique est parfaitement illustrée par la figure
ci-dessous.
Comme nous l’avons déjà dit, UML n’est qu’un langage de modélisation. En effet, UML ne propose pas
une démarche de modélisation explicitant et encadrant toutes les étapes d’un projet, de la
compréhension des besoins à la production du code de l’application. Néanmoins, ses auteurs précisent
qu’une méthode basée sur l’utilisation d’UML doit être :
Pilotée par les cas d’utilisation : La principale qualité d’un logiciel étant son utilité, c’est-à-dire son
adéquation avec les besoins des utilisateurs, toutes les étapes, de la spécification des besoins à la
maintenance, doivent être guidées par les cas d’utilisation qui modélisent justement les besoins des
utilisateurs.
Centrée sur l’architecture : L’architecture est conçue pour satisfaire les besoins exprimés dans les cas
d’utilisation, mais aussi pour prendre en compte les évolutions futures et les contraintes de réalisation.
La mise en place d’une architecture adaptée conditionne le succès d’un développement.
Itérative et incrémentale : L’ensemble du problème est décomposé en petites itérations, définies à
partir des cas d’utilisation et de l’étude des risques. Les risques majeurs et les cas d’utilisation les plus
importants sont traités en priorité.
La méthode que nous présentons ici est issue de celle présentée par Roques(2000) dans son livre « UML
– Modéliser un site e-commerce »
Bouti que_On_Li ne
Chercher
ouv rage
Gérer panier
Internaute
Dans le cadre d’une approche itérative et incrémentale, il faut affecter un degré d’importance et un
coefficient de risque à chacun des cas d’utilisation pour définir l’ordre des incréments à réaliser.
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 3 sur 12
Cas d’utilisation Priorité Risque
Chercher ouvrage Haute Moyen
Gérer Panier Moyen Moyen
Rechercher par mots-clés Bas Moyen
Etc. Etc. Etc.
Un tel classement permet de déterminer les cas d’utilisation centraux en fonction de leur priorité
fonctionnelle et du risque qu’ils font courir au projet dans son ensemble. Les fonctionnalités des cas les
plus centraux seront développées prioritairement.
L’objectif de cette étape est d’aider aussi les utilisateurs à formuler et formaliser ce qu’ils attendent du
système.
Dans cette étape on va détailler les besoins à l’aide de la description textuelle des cas d’utilisation et
produire des diagrammes de séquences système illustrant cette description textuelle. Cette étape peut
amener à mettre à jour le diagramme de cas d’utilisation puisque nous sommes toujours dans la
spécification des besoins. Il faut au minimum, représenter le scénario nominal de chacun des cas
d’utilisation par un diagramme de séquence qui présente l’interaction entre les acteurs et le système.
Lorsque les scénarii alternatifs d’un cas d’utilisation sont nombreux et importants, l’utilisation d’un
diagramme d’états-transitions ou d’activités peut s’avérer préférables à une multitude de diagramme de
séquence.
2. Phase d’analyse
2.1 Analyse du domaine : le modèle du domaine
La modélisation des besoins par les cas d’utilisation s’apparente à une analyse fonctionnelle classique.
L’élaboration du modèle des classes du domaine permet d’opérer une transition vers une véritable
modélisation objet. La phase d’analyse du domaine permet d’élaborer la première version du
diagramme de classes appelée modèle du domaine. Ce modèle doit définir les classes qui modélisent les
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 4 sur 12
entités ou concepts présents dans le domaine (métier) de l’application. Ces entités ou concepts peuvent
être identifié directement à partir de la connaissance du domaine ou par des entretiens avec des experts
du domaine. Il faut absolument utiliser le vocabulaire du métier pour nommer les classes et leurs
attributs. Ces classes ne comportent pas d’opération.
Editeur
- nom : char
- pays: char
1
edi ter
1..*
Liv re
Les classes de dialogues – Les classes qui permettent les interactions entre l’IHM et les utilisateurs sont
qualifiées de dialogues. Ces classes sont directement issues de l’analyse de la maquette. Il y a au moins
un dialogue pour chaque association entre un acteur et un cas d’utilisation du diagramme de cas
d’utilisation. En général, les dialogues vivent seulement le temps du déroulement du cas d’utilisation
concerné.
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 5 sur 12
Les classes de contrôles – Les classes qui modélisent la cinématique de l’application sont appelées
contrôles. Elles font la jonction entre les dialogues et les classes métier en permettant aux différentes
vues de l’application de manipuler des informations détenues par un ou plusieurs objets métier. Elles
contiennent les règles applicatives et les isolent à la fois des dialogues et des entités.
Les classes entités – Les classes métier, qui proviennent directement du modèle du domaine, sont
qualifiées d’entités. Ces classes sont généralement persistantes, c’est-à-dire qu’elles survivent à
l’exécution d’un cas d’utilisation particulier et qu’elles permettent à des données et des relations d’être
stockées dans des fichiers ou des bases de données. Lors de l’implémentation, ces classes peuvent ne
pas se concrétiser par des classes mais par des relations, au sens des bases de données relationnelles.
Lors de l’élaboration du diagramme de classes participantes, il faut veiller au respect des règles
suivantes :
– Les entités, qui sont issues du modèle du domaine, ne comportent que des attributs ;
– Les entités ne peuvent être en association qu’avec d’autres entités ou avec des contrôles ;
– Les contrôles ne comportent que des opérations. Ils implémentent la logique applicative (i.e. les
fonctionnalités de l’application). Chaque contrôle est généralement associé à un cas d’utilisation, et vice
versa. Mais rien n’empêche de décomposer un cas d’utilisation complexe en plusieurs contrôles.
– Les contrôles peuvent être associés à tous les types de classes, y compris d’autres contrôles.
– Les dialogues comportent des attributs et des opérations. Les attributs représentent des informations
ou des paramètres saisis par l’utilisateur ou des résultats d’actions. Les opérations réalisent
(généralement par délégation aux contrôles) les actions que l’utilisateur demande par le biais de l’IHM.
– Les dialogues peuvent être en association avec des contrôles ou d’autres dialogues, mais pas
directement avec des entités.
– Il est également possible d’ajouter les acteurs sur le diagramme de classes participantes en respectant
la règle suivante : un acteur ne peut être lié qu’à un dialogue.
Le schéma ci-dessous donne un diagramme de classes participantes pour le cas d’utilisation « chercher
ouvrage »
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 6 sur 12
3. La phase de conception
3.1 Diagrammes d’interaction : diagramme de séquences détaillé et diagramme de
collaboration
Maintenant, il faut attribuer précisément les responsabilités de comportement, dégagée par les
diagrammes de séquence système, aux classes d’analyse du diagramme de classes participantes. Les
résultats de cette réflexion sont présentés sous la forme de diagrammes d’interaction UML.
Parallèlement, une première ébauche de la vue statique de conception, c’est-à-dire du diagramme de
classes de conception, est construite et complétée. Durant cette phase, l’ébauche du diagramme de
classes de conception reste indépendante des choix technologiques qui seront faits ultérieurement.
Pour chaque service ou fonction, il faut décider quelle est la classe qui va le contenir. Les diagrammes
d’interactions (i.e de séquence ou de communication) sont particulièrement utiles au concepteur pour
représenter graphiquement ces décisions d’allocations des responsabilités. Chaque diagramme va
représenter un ensemble d’objets de classes différentes collaborant dans le cadre d’un scénario
d’exécution du système.
Avec un outil de modélisation UML (comme Rational Rose ou PowerAMC), la spécification de l’envoi
d’un message entre deux objets crée effectivement une opération publique sur la classe de l’objet cible.
Ce type d’outil permet réellement de mettre en œuvre l’allocation des responsabilités à partir des
diagrammes d’interaction.
Par rapport aux diagrammes de séquences système, nous remplaçons ici le système, vu comme une
boîte noire, par un ensemble d’objets en collaboration. Ces objets sont des instances des trois types de
classes d’analyse du diagramme de classes participantes, à savoir des dialogues, des contrôles et des
entités. Pour que deux objets puis interagir directement, il faut que :
– les classes dont ils sont issus soient en association dans le diagramme de classes participantes;
– l’interaction respecte la navigabilité de l’association en question.
L’objectif de cette étape est de produire le diagramme de classes qui servira pour l’implémentation. Une
première ébauche du diagramme de classes de conception a déjà été élaborée en parallèle des
diagrammes d’interaction Il faut maintenant le compléter en précisant les opérations privées des
différentes classes. Il faut prendre en comptes les choix techniques, comme le choix du langage de
programmation, le choix des différentes librairies utilisées (notamment pour l’implémentation de
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 7 sur 12
l’interface graphique), etc. Pour une classe, le couplage est la mesure de la quantité d’autres classes
auxquelles elle est connectée par des associations, des relations de dépendances, etc. Durant toute
l’élaboration du diagramme de classes de conception, il faut veiller à conserver un couplage faible pour
obtenir une application plus évolutive et plus facile à maintenir. L’utilisation des design patterns est
fortement conseillée lors de l’élaboration du diagramme de classes de conception.
Production itérative d'incréments : Les itérations sont produites successivement, chacune ajoutant au
système de nouvelles fonctionnalités, jusqu'à former un système complet.
A chaque itération, on refait : la spécification (analyse), la conception, l’implémentation et les tests
1. Présentation de RUP
RUP est une démarche de développement qui est souvent utilisé conjointement au langage UML.
RUP est :
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 8 sur 12
- Piloté par les cas d’utilisation
- Centré sur l’architecture
- Itératif et incrémental
o Chaque itération prend en compte un certain nombre de cas d’utilisation
o Les risques majeurs sont traités en priorité.
o Chaque itération donne lieu à un incrément et produit une nouvelle version exécutable.
Livrables
Un document de vision présentant les besoins de base, les contraintes et fonctionnalités
principales ;
Une première version du modèle de cas d'utilisation ;
Un glossaire de projet ;
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 9 sur 12
Un document de justification économique incluant le contexte général de réalisation, les
facteurs de succès et la prévision financière ;
Une évaluation des risques ;
Un plan de projet présentant phases et itérations ;
Un ou plusieurs prototypes.
Critère d’évaluation
Un consensus sur : La planification, l'estimation des coûts, la définition de l'ensemble des projets
des parties concernées.
La compréhension commune des besoins.
Objectifs
Définir, valider et arrêter l'architecture ;
Démontrer l'efficacité de cette architecture à répondre à notre besoin ;
Planifier la phase de construction.
Activités
Elaboration de la vision générale du système, les cas d'utilisation principaux sont compris et
validés ;
Le processus de projet, l'infrastructure, les outils et l'environnement de développement sont
établis et mis en place ;
Elaboration de l'architecture et sélection des composants.
Livrables
Le modèle de cas d'utilisation est produit au moins à 80 %;
La liste des exigences et contraintes non fonctionnelles identifiées ;
Une description de l'architecture ;
Un exécutable permettant de valider l'architecture du logiciel à travers certaines fonctionnalités
complexes ;
La liste des risques revue et la mise à jour de la justification économique du projet ;
Le plan de réalisation, y compris un plan de développement présentant les phases, les itérations
et les critères d'évaluation ;
Critères d'évaluation
La stabilité de la vision du produit final ;
La stabilité de l'architecture ;
La prise en charge des risques principaux est adressée par le(s) prototype(s) ;
La définition et le détail du plan de projet pour la phase de construction ;
Un consensus, par toutes les parties prenantes, sur la réactualisation de la planification, des
coûts et de la définition de projet.
Objectifs
La minimisation des coûts de développement par : l'optimisation des ressources et la
minimisation des travaux non nécessaires.
Le maintien de la qualité ;
Réalisation des versions exécutables.
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 10 sur 12
Activités
Gestion et le contrôle des ressources et l'optimisation du processus de projet ;
Evaluation des versions produites en regard des critères d'acceptation définis.
Livrables
Les versions exécutables du logiciel correspondant à l'enrichissement itération par itération des
fonctionnalités ;
Les manuels d'utilisation réalisés en parallèle à la livraison incrémentale des exécutables ;
Une description des versions produites.
Critères d'évaluation
La stabilité et la qualité des exécutables ;
La préparation des parties prenantes ;
La situation financière du projet en regard du budget initial.
Activités
Activités de « packaging » du logiciel pour le mettre à disposition des utilisateurs et de l'équipe
d'exploitation ;
Correction des erreurs résiduelles et amélioration de la performance et du champ d'utilisation ;
Evaluation du produit final en regard des critères d'acceptation définis.
Livrables
La version finale du logiciel ;
Les manuels d'utilisation.
Critères d'évaluation
La satisfaction des utilisateurs ;
La situation financière du projet en regard du budget initial.
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 11 sur 12
Le schéma ci-dessous illustre l’importance des activités dans chaque phase
INF423 Chapitre 2 : UML et RUP – Master 1 Informatique – Année 2014/2015 Valery Monthe Page 12 sur 12