31/01/2005

Syllabus Rappels UML

Introduction : notion de modèle + historique UML

Module Analyse et Conception z

z Description des digrammes d’UML

avec UML z Le processus de développement en Y
z Présentation de l’étude de cas
Rappels UML z Capture des Besoins
z Développement de la partie Analyse :
z Modélisation de la partie statique
z Modélisation de la dynamique
z Partie Conception

UML VDe 2

Introduction : Evolution systèmes 14 Facteurs Qualité (B.Meyer)

z Complexité croissante z Correction z Adaptabilité

z Ex.: Mise sur le marché de systèmes capables de z Robustesse z Extensibilité
s’administrer et de réparer certains des problèmes z Efficacité z Compatibilité
matériels seuls
z Facilité d’utilisation z Portabilité
z Croissance continue de la complexité des
z Richesse fonctionnelle z Réutilisation
systèmes informatiques
z Délais z Compréhensibilité
z Soutenue par l’évolution en parallèle :
z coûts z Facilité de test
z Puissance des machines
z Abstraction des langages de programmation
z Pertinence des méthodes de développement

UML VDe 3 UML VDe 4

1

Poids des facteurs
z Tous n’auront pas le même poids
z Fonction du point de vue :
z Utilisateur
z Analyste chargé des spécifications
z Programmeur
z Celui qui effectue les tests
z Celui qui a en charge la maintenance
z Celui chargé de la vente
UML VDe
Logiciel sans défaut…
z Les défauts doivent être :
z Éviter d’être introduits
z Identifier et éliminer
z Pour ne pas introduire trop de défauts :
z Méthodes d’ACSI (ex. UML)
z Formalismes de description
z Conventions de documentations
z Identification de « bonnes pratiques »
UML VDe
31/01/2005
Qualité et défaut
z Le pendant de la qualité, c’est le défaut
z Défaut du code mais aussi :
z Défaut des spécifications
z De la documentation
z Du découpage en applications
z De la répartition en composants
z De la stratégie de déploiement
z Etc.
z DEF Défaut :
z Un aspect du logiciel qui peut et doit être amélioré
5 UML VDe 6
Détecter et éliminer les défauts
z « Revue logicielle »
z Étape par étape
z Outils et techniques spécifiques d’analyse du
code source :
z Analyse statique (compilateur, métrique)
z Tests (unitaires, intégration, validation)
z Outils CASE (Computer-Aided System
Engineering, ou AGL, Atelier de Génie Logiciel)
z Langages de preuve formelle
z Etc.
7 UML VDe 8
2

Quand dans le cycle de vie ?
z Défauts : introduits tout au long du
développement
z En analyse, lors des spécifications, de la
réalisation, documentation, validation, correction
d’erreurs
z Lors de la réutilisation (design pattern ou approche
par composants)
z Qualité : souci de tous les instants !
UML VDe 9 UML VDe
L’abstraction Qu’est-ce qu’un modèle ?
z Il s'agit d'un processus qui consiste à
identifier les caractéristiques intéressantes
d'une entité, en vue d'une utilisation précise.
z 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.
UML VDe 11
31/01/2005
UML, Unified Modeling Language
Le langage de modélisation objet unifié…
en référence aux nombreux modèles antérieurs qui
coexistaient péniblement !
Qu'est-ce qu'un modèle ?
z Un modèle est une abstraction de la réalité
L'abstraction est un des piliers de l'approche
objet.
10
z Un modèle est une vue subjective mais
pertinente de la réalité
z 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é
z Ex.: personnages chez peintres cubistes (Picasso,
Braque)
z 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.
UML VDe 12
3

Quelques exemples de modèles
z Modèle météorologique :
à partir de données d'observation (satellite ...), permet de
prévoir les conditions climatiques pour les jours à venir.
z 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...).
z 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...
UML VDe
Modélisation objet
z Encapsulation
z Regroupement de code et d’informations
z Masquage d’information au monde extérieur
z Meilleure modularité (interface, privée)
z Meilleure sécurité, lisibilité
z Héritage
z Construire une classe à partir d’une autre (réutilisabilité)
z « Factoriser » dans une classe générique (abstraction)
z Polymorphisme
z Unicité de nom de fonction pour des codes
d’implémentation différents
z Liaison dynamique
UML VDe
31/01/2005
Caractéristiques fondamentales
z Le caractère abstrait d'un modèle doit
notamment permettre de :
z faciliter la compréhension du système étudié;
z réduire la complexité du système étudié;
z simuler le système étudié.
z Un modèle représente le système étudié et
reproduit ses comportements.
z 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
13 UML VDe 14
Comment modéliser avec UML ?
z UML est un langage qui permet de
représenter des modèles, il ne définit pas le
processus d'élaboration des modèles !
z Volonté des auteurs : le processus de
développement est trop fonction de la culture
d'entreprise, et du type de projet
z Dans le cadre de la modélisation d'une
application informatique, les auteurs d'UML
préconisent d'utiliser une démarche :
z itérative et incrémentale,
z guidée par les besoins des utilisateurs du système,
z centrée sur l'architecture logicielle.
15 UML VDe 16
4

Une démarche itérative et incrémentale ?
z 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.
z Cette démarche devrait aussi s'appliquer au cycle
de développement dans son ensemble, en
favorisant le prototypage.
z Le but est de mieux maîtriser la part
d'inconnu et d'incertitudes qui caractérisent
les systèmes complexes.
UML VDe
Une démarche centrée sur l'architecture ?
z Une architecture adaptée est la clé de voûte
du succès d'un développement.
z Elle décrit des choix stratégiques qui
déterminent en grande partie les qualités du
logiciel (adaptabilité, performances, fiabilité...).
UML VDe
31/01/2005
Une démarche pilotée par les utilisateurs ?
z Avec UML, les utilisateurs définissent ce que
doit être le système
z le périmètre du système à modéliser est défini par
les besoins des utilisateurs
z Les utilisateurs sont les clients du système
z Le but du système à modéliser est de répondre aux
besoins de ses utilisateurs.
z Les besoins des utilisateurs servent aussi de
fil rouge, tout au long du cycle :
z A chaque itération de la phase d'analyse, de la
phase de conception et de réalisation, de la phase
17 UML VDe
de test 18
OK, mais en pratique ?
z UML n'est pas un processus… mais
z il facilite une démarche d'analyse itérative et
incrémentale, basée sur les niveaux d'abstraction.
z Les niveaux d'abstraction permettent de
structurer les modèles.
z Un micro-processus régit les itérations à niveau
d'abstraction constant.
z Un macro-processus régit le passage de niveau à
niveau.
z La démarche incrémentale consiste à
construire les modèles de spécification et de
conception en plusieurs étapes.
19 UML VDe 20
5
 31/01/2005

Analyse vs. Conception Le piège de l’analyse

z Analyse : dissection du problème z Trop d’attention accordée aux détails !

z Étude du domaine du problème
z Définition d’un comportement observable de l’extérieur
z On a envie de se plonger très vite dans les
z Interlocuteur privilégié : l’utilisateur final détails… car :
z Ex. jeu de dés : concepts Joueur, Dé, JeuDeDés z c’est plus facile
z on sait fournir des résultats (on a des solutions)
z Conception : fabrication d’une solution informatique
z Malheureusement, une mauvaise analyse
z Détails d’implémentation réelles (IHM, stockage, accès,
sécurité, fréquence/débits, performances) conduit à une conception figée ou
z Interlocuteur privilégié : l’analyste inadéquate…
z Classe Dé : méthode Lancer() et getValeur() z On considère qu’une erreur d’analyse de 1 €
z Classe JeuDeDés : méthode Jouer() qui va appeler Lancer() conduit à des modifications en conception de 1000
de Dé fois plus…
UML VDe 21 UML VDe 22

Utilisation d’UML ? Les diagrammes d’UML

z L’AGL le plus vendu qui permet de développer une z9 diagrammes différents

spécification UML est ROSE de Rational
z À l’IUT, nous utilisons PowerAMC qui est équivalent z (12 dans UML v2.0)
z Cet AGL reste cher pour les petits projets… z Deux modes de représentation
complémentaires :
z Dans les SSII, les spécifications suivent souvent une
méthode « maison » qui est de l’UML simplifiée statique et dynamique
z Représentation statique : 5 diagrammes
z UML est une boîte à outils extraordinaire dont il faut z Représentation dynamique : 4
savoir extraire les bons éléments !
diagrammes
UML VDe 23 UML VDe 24

6
 31/01/2005

Modélisation statique (1/4) Modélisation statique (2/4)

z Diagramme des Cas d’utilisation (USE CASE) z Diagramme de Classes :

z montre les différentes fonctionnalités, les z utilisé à la fois
différents types d’utilisateurs (rôles, acteurs) z en analyse (description de la structure des entités qui
composent le système)
z utilisé pour la capture des besoins fonctionnels et
z et en conception (modules ou entités liés au langage)
techniques
z Diagramme d’objets
z pour détailler des structures de classes complexes
z Diagramme de classes
z pour vérifier, en analyse, que tous les cas possibles
z le plus important car c’est celui utilisé pour la ont bien été envisagés dans le diagr. de classes.
génération automatique de code

UML VDe 25 UML VDe 26

Modélisation statique (3/4) Modélisation statique (4/4)

z Diagramme de composants : z Diagramme de déploiement

z pour l’aspect technique, représente les z montre à la fois le réseau informatique qui
composants technologiques nécessaires à
va supporter le système logiciel
l’exploitation de l’application
z (librairies dynamiques, instances de BD, applications, z et la façon dont les composants y sont
progiciels, objets distribués, exécutables…) installés
z pour la configuration logicielle, montre la structure
des composants comme les fichiers sources, les
scripts ou les librairies.

UML VDe 27 UML VDe 28

7
 31/01/2005

Comportement du système (1/3) Modélisation dynamique (2/3)

Comment il réagit aux événements extérieurs :

z Diagramme d’activités
modèle dynamique du système
z enchaînement des activités du système
z Utilisé :
z Diagramme d’états
z soit pour consolider la spécification d’un cas
z utilisé en analyse pour montrer comment les objets
d’utilisation
d’une classe se comportent et évoluent au cours du
z soit pour concevoir une méthode en conception
temps
z en conception, montre la dynamique des classes
de conception (ex.: fonctionnement d’une fenêtre)

UML VDe 29 UML VDe 30

Modélisation dynamique (3/3) Trop de diagrammes ?

z Diagramme de collaboration z Arhhh… lequel choisir pour mon système ?

z montrer les interactions entre les objets du système
z Chaque diagramme de la représentation S ou
(échange de messages) pour des fonctionnements
particuliers D est une vue du système
z utilisé en début d’analyse pour modéliser le z On en choisit un ou deux !
contexte du système : définition de scénarios types z Les plus courants sont :
d’utilisation
z pour concevoir une méthode en phase de z Le diagramme de classe
conception z Le diagramme de séquence (ou de
z Diagramme de séquences collaboration)
z développer en phase d’analyse les scénarios
d’utilisation préalablement identifiés
UML VDe 31 UML VDe 32

8
 31/01/2005

Processus de développement : en Y Processus de développement : en Y

z Processus unifié (PU) construit sur UML

z Un système d’information est généralement
z Deux branches : fonctionnelle et technique
conditionné par la définition :
z itératif, orienté composants, fondés sur de
« bonnes pratiques » et non pas sur une tentative z Un volet fonctionnel
de normalisation universelle z Un volet technique
z Processus itératif z Ces deux axes sont indépendants pour ce
z à chaque étape, on augmente le niveau de détail, qui concerne les premières étapes du
le niveau d’abstraction diminue
développement
z étapes consolidées au fur et à mesure
Le changement FAIT PARTIE du dévelop- z Ensuite, on les fusionne pour définir le
pement logiciel ! système souhaité.

UML VDe 33 UML VDe 34

Un processus bien accepté Besoins fonctionnels

z C’est la définition des fonctions attendues et

z Ce processus a fait ses preuves
z notamment pour se prémunir du risque fréquent de
sous-estimer certains problèmes de
développement.
z La politique de l’autruche est une pratique
courante en développement logiciel, on a
tendance à repousser les problèmes
z Histoire d’avancer...
z mais en final, ça coûte cher en modifications
tardives
UML VDe
souhaitées pour le système
z Si nouveau système : spécifications du cahier
des charges
z Ex. : gestion de l’emploi du temps en IUT
z Cas d’un système existant à modifier :
spécifications des modifications ou nouvelles
contraintes
z Ex. : modification du calcul ; prise en compte de
nouveaux paramètres dans une BD ;
enrichissement des fonctionnalités, …
35 UML VDe 36

9

Besoins techniques
z Nouveau système : choix des orientations
techniques à privilégier (fonctionnement sur un
intranet, application Client/Serveur en local…)
z QUELQUE SOIT les applications
z Système existant : MàJ avec prise en compte
des évolutions techniques
z Ex. : accepter des commandes par le Web
z Rien ne change fonctionnellement, mais l’architecture
technique va évoluer
z Ex.: ajout d’une fonctionnalité qui nécessite une
synchronisation entre un fournisseur et son client
z ex. partage de catalogue
UML VDe 37
Capital Métier
z Dans beaucoup de développements
informatiques, la connaissance fonctionnelle
est noyée dans les lignes de code
z Avec le PU, Analyse indpte de toute considération
technique.
z Si l’E. maintient à jour ses modèles
fonctionnels, elle est capable un jour de le
développer sous d’autres architectures
techniques
z Réutilisation du même modèle fonctionnel avec une
archi Client / serveur, ou avec une architecture
JAVA
UML VDe 39
31/01/2005
Etapes de l’Axe Fonctionnel
1. Capture des besoins fonctionnels, focalisés
sur le métier des utilisateurs
2. Analyse (étude précise des besoins
fonctionnels)
z comprend généralement une analyse du
domaine et une analyse de l’application
⇒ Capitalisation de la connaissance métier
de l’Entreprise : investissement à M.T. et L.T.
UML VDe 38
Étapes de l’Axe Technique
1. Capture des besoins techniques : choix,
contraintes matérielles, contraintes
d’intégration
2. Conception générique (indépendante des
besoins fonctionnels) :
z définition des composants nécessaires à
l’architecture technique; va jusqu’à définir les
classes techniques réutilisables, ainsi que les
règles de conception pour l’ensemble du système.
z Parfois validation par un prototype
UML VDe 40
10
 31/01/2005

Axe Technique Remarque sur l’aspect technique

z A l’issue de cette branche : on a un squelette z Le souci de maîtrise de l’architecture

technique du projet. technique est de moins en moins la
z Si le squelette est robuste et bien conçu : préoccupation des entreprises
z il pourra soutenir la grande majorité des évolutions
fonctionnelles
z Elles se recentrent sur leur métier et sous-traitent
aux SSII la définition d’architectures clefs en main
z Au contraire s’il est mal conçu et qu ’il engendre de
(type services CORBA, services web) « prêtes à
nombreuses retouches ou reprises :
intégrer ».
z cela aura des répercussions très coûteuses pour la suite du
projet. z « Downsizing » et externalisation
⇒ Capitalisation du savoir-faire technique de l’E.
⇒ Investissement à CT et MT

UML VDe 41 UML VDe 42

Différents niveaux d’abstraction :

Étapes de l’Axe Final Commun
processus itératif

3. Conception préliminaire : intégration du

modèle d’analyse dans l’architecture Au niveau n
technique (1) Planification des tâches de construction
z identification des composants du systèmes à (2) Avancement sur le modèle
développer
(3) Validation
4. Conception détaillée : comment réaliser Si imprécisions, corrections : retour en (1) sinon :
chaque composant
(4) Passage au niveau n+1
5. Codage et tests
6. Recette : valider les fonctions du système
développé
UML VDe 43 UML VDe 44

11
 31/01/2005

Ex.: Niveaux d’abstraction de la Branche

Fonctionnelle Ex.: Niveaux des Besoins Techniques
z Niveau contexte
z frontière entre système et son environnement
z Niveau Cas d’utilisation z Niveau analyse technique : choix des
z activités attendues par les différents utilisateurs
couches logicielles
z Niveau Analyse du domaine
z déf. de structure et comportement des objets
métiers z Niveau Activités : activités techniques
attendues
z Niveau Analyse de l’application
z idem pour les objets mis en œuvre dans
l’application, objets connus des utilisateurs
Les niveaux accroissent progressivement le niveau de
UML VDe
profondeur de l’analyse
45 UML VDe 46

Le processus unifié Activités support

xte
Branche fonctionnelle Branche technique
nte Capture des besoins
Co io n Capture An
des besoins Tâches de
sat a
techniques lyse t Tâches
’ u tili fonct.
e ech
pilotage du
s d a in Co ni q projet d’industrialisation
Ca d om Analyse Conception générique nce ue du logiciel
du n pti
y s e tio Conception préliminaire o n
a l ca t e
An li chn
app iq u
d e l’ Conception détaillée
C e contrôler et
y s e o n anticiper
n a l Codage et tests cep
A Co tio (Tâches
Activitésded’administration +
nc ns l’avancement du
Recette ept yst développement
appropriation des outils de dvpt +
ion èm projet
e logiciel)des configurations
gestion
des
com
po
san
ts
UML VDe 47 UML VDe 48

12
 31/01/2005

Gestion des risques Etude préliminaire : contexte

z Toute première étape, après l’idée du projet

z Processus tourné vers la gestion des risques z Repérage des besoins fonctionnels et
Æ différents risques sont évalués à chaque étape techniques
d’avancement textes et des diagrammes très simples
Æ risque d’imprécision fonctionnelle, z Système = boîte noire
Æ risque de ne pas répondre aux besoins utilisateurs, z Préparation à la capture des besoins, avec
Æ risque d’inadéquation ou de sous-performances des étapes plus formelles
techniques, etc.

UML VDe 49 UML VDe 50

Résultats de l’étude préliminaire Étude de cas : SIVEX

z Société de messagerie : enlèvement, transport

z un Cahier des Charges préliminaire
z la liste des acteurs
z une description des messages entre les
acteurs et le système
z une modélisation du contexte dynamique, qui
montre quels messages sont échangés entre
les acteurs et le système
z Éventuellement : contexte statique, pour les
cardinalités
UML VDe
et livraison de colis
z 70 agences, 3000 employés et 40 000 colis
traités par jour
z Souhaite un syst. qui permette de :
z localiser et connaître l’état des colis en TR
z suivre les commandes + gestion comptable
z autoriser les clients à suivre l’acheminement de
leur commande via Internet
z Besoins techniques : UML / archi. 3-tiers /
Internet / JAVA /SGBDR (cf CdesCh)
51 UML VDe 52

13
 31/01/2005

Déterminer les acteurs Choix des acteurs

z les acteurs définissent les différents rôles que
les utilisateurs du système peuvent jouer
z un acteur peut être un humain ou un
constituant informatique, un dispositif
matériel ou un autre système : néanmoins c’est
une entité externe
z pas de relation 1-1 entre un acteur et un
utilisateur du système
z Identification des acteurs : processus itératif
UML VDe 53
UML VDe
z Utilisateurs humains : identifier tous les profils
possibles
z opérateur de maintenance, administrateur…
z Autres systèmes connexes qui intéragissent
avec le système
z vérifier qu’ils agissent bien directement avec le
système, et pas par le biais d’un acteur déjà
répertorié !
z Vérifier que les acteurs sont bien extérieurs au
système, que ce ne sont pas des composants.
z Vérifier aussi qu’il a une autonomie de
décision, ça ne doit pas être un matériel passif 54

SIVEX Acteurs de SIVEX

z quels sont les acteurs ? z Réceptionniste

z Saisie et annule les cdes client
z Client
z Consulte ses encours via internet, reçoit confirmation cde par
courriel ou fax
z Progiciel de comptabilité
z Comptable
z Fait le point sur les cdes, établit factures/avoirs;
recouvrements
z Répartiteur
z Crée les différentes missions en fonction cdes et ressources;
pare aux incidents

UML VDe 55 UML VDe 56

14
 31/01/2005

Acteurs de SIVEX (suite) Identifier les messages

z Chauffeur z message = communication entre acteur et

z Assure les missions; réceptionne/livre les colis; informe de système
ses arrêts le système
z Opérateur de quai z le message transporte de l’information
z Identifie et pèse les colis provenant d’un enlèvement; pointe le z le message est envoyé avec l’intention de
passage des colis en départ et arrivée d’agence; inventaires
de quai.
déclencher une activité chez le récepteur
z Responsable logistique z la réception d’un message est considérée
z Définit le réseau des agences; stratégie de transport comme un événement
z Administrateur système
z Gère les profils utilisateurs du système, et mots de passe;
archivages

UML VDe 57 UML VDe 58

Identifier les messages Diag. de Contexte statique : SIVEX

→ se demander quels sont les messages

envoyés par les acteurs qui déclenchent un Responsabl e
Logi sti que

comportement attendu, dans le cadre de leur Récepti onni ste 0..n

0. .1
0..70 Répartiteur

activité
0..n 0..70
→ pour le système, se demander quels sont les SIVEx

messages envoyés vers chaque acteur Cli e nt Adm inistrateur

Systèm e

→ (cf SIVEX) 0..1 0..n

0..1 0..n

Com ptabl e Opérateur de

Progi ci el de Quai
Chauffeur
Com pta bil i té

UML VDe 59 UML VDe 60

15
 31/01/2005

Messages Diagr. de Contexte dynamique : SIVEX

z pas de messages entre acteurs : c’est HS !

z Construire le diagramme de contexte
dynamique, qui ordonne et classe les
messages.
Système au centre, comme une boîte noire
Acteurs autour
Mentionner les messages et le sens de la
communication : de l ’acteur vers le système ou
l ’inverse
(cf SIVEX)

UML VDe 61 UML VDe 62

Messages

z On notera qu’il n’y a :

z ni les actions de connexion/déconnexion du syst.,
z ni les consultations sans effet de bord

z Décrire les messages textuellement

UML VDe 63

16