Démarche d’application d’UML

Comment bien utiliser UML ?

Bonnes pratiques

Avertissement

z Il n’y a pas UNE démarche officielle

z Sinon le PU avec ses branches fonctionnelles et
techniques disjointes
z Valable pour les grands projets
z Mais plusieurs démarches appliquées par les
professionnels
z fonction de leur culture, de leur passé
z des besoins, du type d’applications

Démarche synthétique

z Cas d’utilisation
z Modèle du domaine
z Diagramme de séquence du système
z Identification des principales IHM
z Diagramme d’activités de navigation
z Diagramme de séquence d’interaction
z Diagramme de classes

1
Démarche proposée (1)

1. Cas d’utilisation
Identifier :
z les acteurs
z les cas d’utilisation
z Structurer les cas d’utilisation en packages

Décrire textuellement chaque cas d’utilisation à

l’aide d’une fiche descriptive

Démarche proposée (2)

2. Modèle du domaine

z Identifier les concepts métier manipulés par

les acteurs

z Etablir un glossaire des classes : liste des

classes avec leurs attributs

Démarche proposée (3)

3. Diagramme de séquence système

z Détailler chaque cas d’utilisation en voyant le
système comme une boîte noire.
z Pour chaque cas d’utilisation, on pourra
distinguer :
z le scénario nominal : le chemin le plus direct pour
atteindre l’objectif du cas d’utilisation.
z les extensions : qui comprennent les chemins
moins directs ainsi que les « exceptions ». Elles
doivent se brancher sur le scénario nominal.

2
Démarche proposée (4)

4. IHM

z Identifier les principales IHM

z Définir les principales méthodes à réaliser par

chaque IHM

Démarche proposée (5)

5. Diagramme d’activités de navigation

z Représenter les différents chemins possibles

entre les principaux écrans proposés à
l’utilisateur

Démarche proposée (6)

6. Diagramme de séquence d’interaction

z Détailler chaque diagramme de séquence

pour les cas intéressants en faisant apparaître
les différents objets (internes au système) qui
interagissent

3
Démarche proposée (7)

7. Diagramme de classes

Réaliser le diagramme de classes de conception

attributs / méthodes / liens entre les classes

Exemple : système bancaire

Gérer les clients

Ouvrir un compte

guichetier responsable
Créditer compte
clientèle

Débiter compte

Consulter Comptes

client
Gestion de commande

Packages

Ouvrir un compte

Créditer compte
Gestion
comptes Débiter compte

Consulter Comptes

Gestion
commandes Gestion
clients

4
Diag. séquences pour le cas "Ouvrir un cpte"

unCompte: Compte

guichetier
client
<< create >> fournir(infoClient)

Créditer (50)

Éditer_Compte()

Diag. d'activités pour "Débiter cpte"

Ici on montre la logique du cas d'utilisation Débiter

Compte :

Débiter(montant)
[solde insuffisant]

[solde suffisant]

Déduire montant du solde

Diagr. de classes … trivial !

Compte
1..* Client
numéroCpte
Solde <possède Nom
Prénom
Créditer(montant) adresse
Débiter(montant)
getSolde() Éditer()
Éditer()

Le constructeur n’est pas mentionné

ici en analyse, mais il est obligatoire
pour les classes concrètes

5
Démarche détaillée des Cas d’Utilisation

(1) Présentation du contexte et du sujet

(2) Acteurs autour du système
Æ diagramme de contexte statique
z identifier les acteurs (rôles abstraits)
z environnement humain et informatique du
système
z lister et nommer les acteurs, les définir par une
phrase

Démarche Cas d’utilisation (2)

(3) Ajouter les échanges d'informations

acteurs ⇔ système
z les nommer, les définir par une
phrase (diagramme de contexte dynamique)

(4) Services rendus aux acteurs par le

système (diagramme des cas d'utilisation)
z étude plus fine des interactions acteurs ⇔
système, en dissociant en grandes fonctions
z nommer les services rendus, les définir par
une phrase

Démarche Cas d’utilisation (3)

(5) Pour chaque cas d'utilisation :

z Définir les objets partagés entre acteurs et
système :
z Objets traités, mémorisés, produits,
transformés
z objets du monde modélisé
z objets importants pour les acteurs
z objets persistants ou pas

6
Pour chaque cas d’utilisation (suite)

z lister et nommer les objets (avec le

vocabulaire des acteurs), les définir par une
phrase
z identifier les classes candidates
Æ un diagramme de classe par cas d'utilisation

z relier les objets, nommer les liens, les définir

par une phrase

Démarche Cas d’utilisation (4)

(6) Réunir les objets des différents cas

Æ un unique diagramme des classes

(les mêmes objets interviennent dans les

différents cas)

Attention !

z Rappel : UML est une méthode incrémentale

et itérative
z Itérative
z on modifie et enrichit au fur et à mesure les
diagrammes ;
z Incrémentale
z on peut livrer des lots utilisables

z Quelle différence ?

7
Analogie la fabrication d'un immeuble

Si on construit un immeuble par itérations :

z On fait les murs.
z On habille tout l'extérieur.
z On fait toute l'électricité.
z On habille tous les intérieurs.
Si on construit un immeuble par incréments :
z On réalise un étage complet puis on passe au
suivant.
z Chaque étage fini est comparable à une version
livrable (un prototype -et non une maquette).

Meilleures pratiques

z Pour une analyse conception d’une application

relativement isolée, démarche top-down :
z partir des uses case et arriver aux modules…
z Pour un pb « d’urbanisme de SI », ie de conception de
différents SI qui possèdent des inter-relations entre
eux,
z avec un objectif plus lointain de concevoir des
systèmes qui vont être capables d’évoluer en fonction
des modifications de technologies ou des besoins,
z préférer une démarche bottom-up.
l'urbanisme est moins une affaire de statique des
domaines fonctionnels que de dynamique des échanges
et de "gestion des flux".

Critiques des méthodes de

spécification

Une autre vision du développement : les

méthodes de programmation rapide

8
 Approches classiques de développement

z Développement en cascades (waterfall)

z Merise
z Développement itératif et incrémental
z UML
z Basées sur la séquence : spécification / conception /
réalisation / validation
z Fondées sur l'idée que le coût de modification du
logiciel augmente de manière exponentielle dans le
temps
z Obj.: chercher à définir complètement le produit avant de
procéder à sa réalisation

Problèmes chroniques

z Les spécifications sont définies au début du projet,

alors qu'on en sait encore peu sur le sujet,
z Les spécifications différencient rarement ce qui est
important de ce qui ne l'est pas,
z L'application se rigidifie progressivement en un produit
"final" souvent difficile à faire évoluer et à maintenir,
z Les activités sont compartimentées en fonction des
spécialités des développeurs
z ce qui pose des problèmes de répartition des tâches et limite
la circulation des connaissances dans l'équipe

Une nouvelle hypothèse

z Certaines pratiques de développement

permettent de réduire de manière significative
le coût de changement du logiciel
z il devient ainsi plus rentable de prendre les
décisions le plus tard possible
z en s'appuyant sur l'expérience acquise au cours du
développement lui-même

9
eXtreme Programming: XP

z Approche radicalement différente du développement

z fondée sur une ouverture permanente au changement
z Caractéristiques
z Spécifications définies au début du projet, puis revues, affinées et
complétées tout au long du développement,
z Le client arbitre en permanence les priorités pour que l'équipe se
focalise d'abord sur les tâches les plus importantes,
z L'application est maintenue simple et évolutive à travers un
ensemble de pratiques de programmation strictes,
z Les développeurs travaillent toujours ensemble, ce qui favorise le
transfert de connaissances, améliore la qualité du produit et rend le
travail nettement plus motivant
z Par ex.: programmation en binômes
z Réf ?

10