08/03/2016
DÉMARCHE DE
MODÉLISATION AVEC UML
2
Méthodologie
Ensemble des méthodes et des techniques d'un
domaine particulier
Manière de faire, procédé, méthode
Ensemble structuré et cohérent de méthodes,
guides et outils permettant de déduire la manière
de résoudre un problème
1
08/03/2016
UML et le processus unifié
3
Le langage UML
Processus de développement
2
08/03/2016
Vues architecturales et modèles UML
5
Le langage UML
Démarche proposée(1)
UML n’est pas une méthode
Comment passer de l’expression des besoins
au code de l’application ?
3
08/03/2016
Démarche proposée(2)
UML ne propose pas une démarche de modélisation
explicitant et encadrant toutes les étapes d’un projet
ses auteurs précisent qu’une méthode basée sur 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
Centrée sur l’architecture : L’architecture conçue pour
satisfaire les besoins exprimés dans les cas d’utilisation,
prend en compte les évolutions futures et les contraintes de
réalisation.
Itérative et incrémentale : le problème est décomposé en
petites itérations qui conduisent à des livraisons
incrémentales du système.
Démarche proposée (3)
Proposition d'une méthode archi-minimale
• Vraiment nettement moins complexe que RUP
• Adaptée pour des projets modestes
• Minimum vital pour qui prétend utiliser UML
Inspirée de
UML 2 - Modéliser une application web
Pascal Roques
Editions Eyrolles (2006)
4
08/03/2016
Identification des besoins et
spécification des fonctionnalités
Identification et représentation des besoins :
diagramme de cas d’utilisation
Recueil des besoins:
-déterminer les limites du
système,
-identifier les acteurs
-recenser les cas d’utilisation
Si l’application est complexe,
organiser les cas d’utilisation
en paquetages.
Identification des besoins et spécification
des fonctionnalités (suite)
Approche itérative et incrémentale: affecter un degré
d’importance et un coefficient de risque à chacun des
cas d’utilisation.
Les interactions entre les acteurs et le système (au sein
des cas d’utilisation) seront explicitées sous forme
textuelle et sous forme graphique au moyen de
diagrammes de séquence système
Les utilisateurs ont souvent beaucoup de difficultés à
exprimer clairement et précisément ce qu’ils attendent
du système => les aider à formuler et formaliser ces
besoins.
5
08/03/2016
Exemple de classement
Identification des besoins et spécification
des fonctionnalités (suite)
Spécification détaillée des besoins :diagrammes de
séquence système
Les diagrammes de
séquence système illustrent
la description textuelle des
cas d’utilisation.
Cette étape amène
souvent à mettre à jour le
diagramme de cas
d’utilisation
Lorsque les scénarii alternatifs d’un cas d’utilisation sont nombreux
et importants, l’utilisation d’un diagramme d’activités peut s’avérer
préférable
6
08/03/2016
Exemple de DSS
Identification des besoins et spécification des
fonctionnalités (suite)
Maquette de l’IHM de l’application (non couvert par UML)
7
08/03/2016
Phases d’analyse
Analyse du domaine : modèle du domaine
L’élaboration du modèle des classes du domaine permet
d’opérer une transition vers une véritable modélisation
objet.
Ce modèle doit définir les classes qui modélisent les entités
ou concepts présents dans le domaine (le métier) de
l’application.
La phase d’analyse du domaine permet d’élaborer la
première version du diagramme de classes.
Phases d’analyse
Les classes du modèle du domaine ne doivent pas
contenir d’opérations, mais seulement des attributs.
Les étapes à suivre pour établir ce diagramme sont
identifierles entités ou concepts du domaine ;
identifier et ajouter les associations et les attributs ;
organiser et simplifier le modèle en éliminant les classes
redondantes et en utilisant l’héritage ;
le cas échéant, structurer les classes en paquetage
selon les principes de cohérence et d’indépendance
8
08/03/2016
Exemple du modèle du domaine
Structuration en packages
9
08/03/2016
Définition synthétique des packages
Phases d’analyse (suite)
Diagramme de classes participantes
Le diagramme de classes participantes effectue la
jonction entre les cas d’utilisation, le modèle du
domaine et les diagrammes de conception logicielle
le diagramme de classes participantes modélise
trois types de classes d’analyse:
Les classes de dialogues : permettent les interactions
entre l’IHM et les utilisateurs sont directement issues de
l’analyse de la maquette IHM
10
08/03/2016
Phases d’analyse (suite)
Les classes de contrôles : modélisent la cinématique de
l’application contiennent les règles applicatives et les
isolent à la fois des dialogues et des entités.
Les classes entités: sont généralement persistantes
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 lasses peuvent ne pas se
concrétiser par des classes mais par des relations, au
sens des bases de données relationnelles
Diagramme de classes participantes
11
08/03/2016
Exemple de diagrammes de classes
participantes
12
08/03/2016
Diagrammes d’activités de navigation
Exemple de diagramme d'activités de
navigation
13
08/03/2016
Phase de conception
Diagrammes d’interaction:
14
08/03/2016
15
08/03/2016
Des séquences système aux interactions
internes
Des séquences système aux interactions
internes
16
08/03/2016
Phase de conception(suite)
Diagramme de classes de conception
L’objectif de cette étape est de produire le diagramme de
classes qui servira pour l’implémentation
L’utilisation des design patterns est fortement conseillée lors de
l’élaboration du diagramme de classes de conception
Diagramme des classes de conception
17
08/03/2016
18
