Analyse, Conception et Programmation par Objets

Analyse, Conception et Programmation par Objets
Plan
Plan
Analyse, Conception
et Programmation par Objets
Norbert Kajler et Fabien Moutarde
{Norbert.Kajler, Fabien.Moutarde}@mines-paristech.fr
Année 2011-2012
• Les concepts objets . . . . . . . . . . . . . . .
1
• Analyse et conception . . . . . . . . . . . . . .
17
• UML : introduction . . . . . . . . . . . . . . .
26
• UML : modèle des classes . . . . . . . . . . .
34
• UML : compléments au modèle des classes . .
74
• UML : modèle dynamique . . . . . . . . . . .
83
(Dernière mise à jour le 15 septembre 2011)
• UML : modèle fonctionnel . . . . . . . . . . . 115
• Méthodologie pour l’analyse et la validation . . 126
• UML : modèle d’implantation . . . . . . . . . 150
• Méthodologie de la conception à l’intégration . 158
• Tests . . . . . . . . . . . . . . . . . . . . . . . 190
Mines ParisTech
• Bibliographie . . . . . . . . . . . . . . . . . . 198
60 Bd Saint Michel
75272 Paris Cedex 06
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, i
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Les concepts objets
ii
Les concepts objets
Crise du logiciel
Coût
Les concepts objets
200
100
50
20
10
5
1. Pourquoi la programmation par objets.
2
1
phases
Modifications de formats de données
12,4%
Corrections d’erreurs en urgence
9%
Corrections d’erreurs de routine
7. Héritage.
6,2%
Modifications du matériel
8. Polymorphisme.
5,5%
4%
3,4%
n
5. Objet, message, méthode.
17,4%
tio
41,8%
ta
oi
n
n
io
n
so
ai
at
gr
tio
n
io
4. Abstraction et encapsulation.
6. Classe et instance.
pl
Ex
vr
Li
té
a
lis
pt
ce
e
s
ly
3. Modularité.
In
éa
R
on
C
na
A
2. Qualité du logiciel.
Modifications dans les exigences des utilisateurs
Documentation
Amélioration d’efficacité
Autres
Répartition des coûts de maintenance
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 1
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 2
Les concepts objets
Les concepts objets
Défis des langages et méthodes objets
Qualité du logiciel
Facteurs externes (concernent utilisateurs et développeurs) :
Quatre défis principaux :
Validité : aptitude à satisfaire exactement les tâches définies
Réduire les coûts de développement des logiciels.
par sa spécification.
Réduire les coûts de maintenance.
Robustesse : capacité à fonctionner même dans des
conditions anormales.
Faciliter la réutilisation de composants logiciels déjà
réalisés.
Extensibilité : facilité d’adaptation d’un logiciel aux
changements de spécification.
Accroı̂tre la qualité du logiciel.
Compatibilité : aptitude à pouvoir être combiné à d’autres
... et une révolution en cours pour les Informaticiens :
logiciels.
Développement de bibliothèques de composants logiciels
réutilisables.
Efficacité, portabilité, facilité d’utilisation, etc.
Construction d’applications par assemblage de
composants selon des méthodes rigoureuses et
éprouvées.
Facteurs internes (concernent uniquement les développeurs) :
Ré-utilisabilité : possibilité de réutiliser des éléments d’un
Travail à un plus haut niveau d’abstraction que le code.
Vérifiabilité : facilité de préparation/réalisation des
logiciel pour réaliser de nouvelles applications.
procédures de certification.
Modularité, lisibilité, etc.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 3
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Les concepts objets
4
Les concepts objets
Processus d’abstraction
Modularité
Décomposabilité modulaire : décomposition d’un
logiciel complexe en sous-systèmes moins complexes.
Processus de structuration/simplification de la réalité :
Définition des frontières conceptuelles.
Suppression des détails non significatifs pour
l’application.
Concentration sur la vue externe de l’objet.
Composabilité modulaire : utilisation d’éléments
existants pour construire de nouveaux logiciels.
Exemple : abstraction du concept d’usager dans une
bibliothèque :
Attributs : numéro, nom, prénom, adresse.
Comportement : emprunter(), rendre(), démissionner().
Compréhensibilité modulaire : compréhension de
chaque module pris isolément.
Protection modulaire : chaque module est responsable
de ses dysfonctionnements et les traite localement.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 5
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 6
Les concepts objets
Les concepts objets
Encapsulation
Interface et implantation
Technique consistant à regrouper en une même entité (un
objet) des données et les procédures pour manipuler ces
objets.
Séparation stricte entre :
l’implantation de l’objet (ou partie privée) ;
Les données (ou attributs) sont appelées la partie
statique de l’objet ;
et son interface (ou partie publique).
Classe Rectangle
les procédures (ou méthodes) sont appelées la partie
dynamique.
Public
int calculerSurface()
void dessiner()
int h, l , x, y;
Exemple :
Privée
int calculerSurface() { return h * l; }
void dessiner() { ... }
Classe Polygone
Attributs
arêtes
couleur des bords
; L’interface doit être aussi simple et sûre que possible.
couleur du fond
; La partie privée est réservée au concepteur/développeur
de l’objet (invisible aux utilisateurs de la classe).
Méthodes
dessiner()
effacer()
Abstraction de données ≡ partie publique constituée
exclusivement de méthodes (pas de données).
déplacer()
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 7
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Les concepts objets
8
Les concepts objets
Abstraction de données : exercice
Objet, Message, Méthode
Les objets sont des entités autonomes communicantes qui
s’échangent des messages :
Pourquoi l’abstraction de données est une « bonne
pratique » ?
Messages
reçus
Objet
(attributs - méthodes)
Messages
envoyés
Valeurs retournées
Message : requête d’une action que doit réaliser l’objet
récepteur.
Les messages sont mis en oeuvre par les méthodes de
l’objet récepteur.
La dénomination message/objet met en évidence l’idée
que l’objet est responsable de l’exécution de la requête
portée par le message.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 9
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 10
Les concepts objets
Classe et instance
Les concepts objets
Héritage
Relation entre deux classes A et B permettant de définir
la classe B à partir de la classe A.
Classe : modèle d’objets ayant les mêmes types de
propriétés et de comportements.
Chaque instance d’une classe possède ses propres
valeurs pour chaque attribut.
La classe mère transmet ses attributs et ses méthodes à
ses classes filles.
Exemple :
La classe fille ou sous-classe est un cas particulier de la
ou des classe(s) mère(s) ou super-classe(s).
Classe Tour
Attributs
Selon les langages objets :
- héritage simple ou multiple ;
- une ou plusieurs classe(s) racine(s) ;
- plus ou moins grand nombre de classes pré-définies.
position
couleur
Méthodes
déplacer()
; Analogie avec le concept type / variable.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 11
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Les concepts objets
Héritage simple : exemple
12
Les concepts objets
Relation client vs Relation d’héritage
3 Vision hiérarchique :
Relation client : « a un »
Classe Véhicule
; relation de composition, de collaboration entre les
objets.
Attributs
nb_passager
Méthodes
avancer()
Exemples :
- une voiture a 4 roues ;
- une voiture a 1 moteur.
2roues
Voiture
Attributs
puissance
Relation d’héritage : « est un »
Motocyclette
Bicyclette
; relation de spécialisation, relation hiérarchique entre
les objets.
relation d’héritage
Exemples :
- une voiture est un véhicule ;
- une Twingo est une voiture .
3 Vision ensembliste :
Véhicule
2roues
Motocyclette
Voiture
Bicyclette
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 13
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 14
Les concepts objets
Polymorphisme
Avantage du polymorphisme
Propriété d’une méthode de pouvoir se comporter de
manière différente sur des objets de classes différentes.
En programmation structurée (Pascal, C, etc.) :
pour chaque pièce faire
selon type de la pièce
cas Tour : deplacer Tour()
cas Roi : deplacer Roi()
cas Fou : deplacer Fou()
fin selon
fin pour
Polymorphisme statique :
double mult(double, double) ;
double mult(int, double) ;
int mult(int, int) ;
Polymorphisme dynamique :
@Piece p ;
...
p=new Tour() ; // ou new Roi() ou ...
...
p.deplacer() ;
Déplacer
Déplacer
Les concepts objets
En programmation par objets (C++, Java, etc.) :
◦ Définition d’une classe abstraite Piece.
◦ Définition des sous-classes Tour, Roi, Fou, ... avec
pour chacune une méthode deplacer spécifique.
pour chaque pièce p faire
p . deplacer()
fin pour
Déplacer
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 15
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Analyse et conception
16
Analyse et conception
Cycle de vie d’un logiciel
D’un problème à sa solution Informatique :
Expression des besoins, spécifications fonctionnelles :
description détaillée des fonctionnalités souhaitées du
point de vue des futurs utilisateurs.
Analyse et conception
Analyse : spécification du « quoi », c-à-d. description
détaillée du système à réaliser.
1. Cycle de vie d’un logiciel.
Conception : définit « comment » le système sera
réalisé, et comment il se décompose en modules.
2. Méthode d’analyse et de conception.
3. Atelier de Génie Logiciel.
Réalisation : codage de chacun des modules.
4. Analyse et conception objets.
Intégration : test unitaire de chaque module et
intégration des différentes modules dans le système.
Validation : vérification de la conformité globale du
logiciel produit par rapport à sa spécification.
Maintenance, évolution, ...
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 17
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 18
Analyse et conception
Analyse et conception
Analyse et conception par objets
Cycle en cascade
Enchaı̂nement linéaire des phases :
Description du monde réel
Analyse
Analyse
Conception
Modèles d’objet et interactions
Réalisation
Conception
Intégration
Architecture détaillée du système
et des modules
Validation
Réalisation
; Cycle très rigide ;
; retour en arrière extrêmement coûteux.
Système réalisé avec un
langage à objets
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 19
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Analyse et conception
Analyse et conception
Le cycle en V
Cycle en spirale (ou « itératif »)
Chaque phase du cycle est ponctuée par une analyse des
risques encourus sur la phase suivante.
Mise en parallèle des phases de construction et de
vérification :
Analyse
préparation
Conception
20
Si les risques sont importants l’équipe aura recourt à du
prototypage.
Validation
Chaque itération fournit une nouvelle version du système
(pas forcément complète).
Intégration
Analyse détaillée
Réalisation
; Relative rigidité ;
; cycle « classique » car relativement facile à maı̂triser et
à mettre en oeuvre.
Analyse préliminaire
Conception
.
.
version 1 version 2
Validation
Réalisation
Intégration
; Cycle puissant mais délicat à maı̂triser.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 21
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 22
Analyse et conception
Méthodes d’analyse et de conception
Analyse et conception
Méthodes d’analyse et de conception : historique
; « Méthodologie » ou « software development process »
UML + RUP (ou équivalent)
Objectifs :
Classe-relation
OMT OOA
OOD/HOOD/OOSD
◦ permettre la spécification du logiciel à l’aide d’un
langage de modélisation (e.g. UML) ;
◦ guider les différents intervenants lors des différentes
phases du développement logiciel ;
SA-RT
◦ conduire à un meilleur contrôle des facteurs
économiques pertinents : qualité, coût, délais, risques.
Nécessite en pratique :
Diagrammes Etat-Transition
Réseaux de Pétri
Entité-Relation (MERISE)
IA-NIAM
◦ un outil (logiciel) pour saisir/manipuler/vérifier les
spécifications exprimées dans le langage de
modélisation, ainsi que pour superviser le déroulement
du projet.
Data-flow/SADT/SA-SD
Structure-Chart
◦ une formation préalable des intervenants au projet.
Méthodes objets
Méthodes comportements
Méthodes données
Méthodes fonctionnelles
hiérarchiques
Exemple de méthodologies : OMT, Booch, UP/RUP, ...
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 23
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Analyse et conception
24
UML : introduction
Atelier de Génie Logiciel (ou «AGL»)
Un AGL rassemble typiquement :
◦ des éditeurs graphiques et syntaxiques permettant de
saisir/vérifier l’ensemble d’une modélisation ;
UML : introduction
◦ un ou plusieurs générateurs de code ;
◦ un générateur de documentation ;
1. Fondements.
◦ une suite d’outils de Génie Logiciel tels que :
– gestionnaire de versions ;
2. Historique et perspectives.
– gestionnaire de tests ;
3. Disponibilité.
– analyseur de performances ;
4. Exemple.
– ...
5. Contenu d’UML.
Exemples d’AGL : Rational Software Modeler (Rose),
Together, Modelio, Visual Paradigm, Entreprise
Architect, ...
Alternatives gratuites : Bouml, StarUML, ...
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 25
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 26
UML : introduction
UML : introduction
Fondements
Historique
Unified Modeling Language (UML) :
Principales qualités du modèle objet :
◦ association données-traitements (encapsulation) ;
Langage de modélisation «universel»
◦ séparation entre interface et implantation
(public/privé) ;
Résultat de la convergence en 1995 des méthodes :
– OMT (James Rumbaugh),
– OOA-OOD (Grady Booch),
– Objectory/OOSE (Ivar Jacobson)
◦ organisation hiérarchique des classes (héritage).
◦ modélisation des relations non-hiérarchiques ;
Standard industriel sous la direction de l’Object
Management Group (OMG) depuis UML 1.1 (1997) :
◦ vision dynamique de l’application ;
Versions utilisées : UML 1.5 ; UML 2.0 (2005)
Principales limites du modèle (et des langages) objet :
◦ méthodologie (découverte des classes, génération et
documentation du code, reverse engineering, etc.)
Extensions ( « Profiles » ) :
– UML Profile for Enterprise Distributed Object
Computing (EDOC) ;
– UML P. for Schedulability, Performance and Time ;
– UML Testing Profile ;
– ...
; méthodes d’analyse et de conception objets telles
que : OMT, OOAD, Classe-Relation, UML + RUP, UML +
Catalysis, etc.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 27
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : introduction
28
UML : introduction
Formalisme utilisé dans UML
Disponibilité
Essentiellement graphique.
Standard disponible librement sur le site Web de l’OMG
; http://www.omg.org/uml/
(documentation de référence très technique, plutôt
destinée à des utilisateurs avertis : auteurs d’ouvrages,
concepteurs d’outils UML notamment).
Notations spécifiques pour chacun des concepts UML :
packages, classes, relations, instances, états, etc.
Exemple :
+m1()
+m2()
Supporté par de nombreux AGL (Rational Software
Modeler, Modelio, Rhapsody, Together, ...) permettant la
modélisation, génération de code (C++, Java, C#, etc.),
génération des documentations, retro-conception, ...
C2
Documentation :
– ces transparents ;
– livres et sites web sur UML (cf. Bibliographie) ;
– http://www.ensmp.fr/CC/Docs
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, C1
+m1()
+m3()
C3
0..1
*
+a1 : string
Besoin d’un outil adapté : édition des diagrammes,
gestion des cohérences entre diagrammes, génération de
la doc et du code, etc.
; AGL comme « Rational Software Modeler (Rose) »,
« Modelio », ...
29
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 30
UML : introduction
Contenu d’UML : survol rapide
UML : introduction
Contenu d’UML : hiérarchie des concepts
Une notation unifiée
Les « diagrammes » (voir p.33)
; facilite la compréhension / communication d’une
modélisation.
Les « choses » (ou things)
◦ structurelles :
; classes, interfaces, collaborations, cas
d’utilisation, classes actives, composants, noeuds
Un méta-modèle complètement spécifié
; spécifie formellement la sémantique d’UML ;
; facilite la réalisation d’outils et l’échange d’une
modélisation entre outils.
◦ dynamiques (ou behavioral) :
; interactions, automates
◦ groupantes :
; packages
Attention : UML n’impose pas de « processus de
développement » (ou « méthodologie ») spécifique
◦ annotantes :
; notes
; possibilité d’adapter UML aux spécificités de chaque
organisation et/ou projet en terme de processus de
développement.
Les « relations » :
; dépendances, associations, généralisations
L’« extensibilité » :
; stéréotypes, propriétés, contraintes, commentaires
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 31
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : introduction
32
UML : modèle des classes
Contenu d’UML : neuf types de diagramme
Aspects « fonctionnels » :
UML : modèle des classes
◦ Diagramme de cas d’utilisation (ou use case diagram)
; [Expression des besoins / An.]
Aspects « structurels » :
1. Packages.
◦ Diagramme de classes ; [An. / Co.]
2. Classes.
◦ Diagramme d’instances (ou d’objets) ; [An.]
3. Attributs, opérations, invariants et
pré-/post-conditions.
◦ Diagramme de composants ; [Co.]
◦ Diagramme de déploiement ; [Co.]
4. Associations et agrégations.
Aspects « dynamiques » :
5. Généralisation.
◦ Diagramme d’états-transitions (ou statechart
diagram) ; [An. / Co.]
6. Instances et diagrammes d’instances
◦ Diagramme de séquence (ou scénario) ; [An.]
7. Règles d’emploi du modèle des classes.
◦ Diagramme de collaboration ; [An.]
◦ Diagramme d’activités ; [An.]
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 33
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 34
UML : modèle des classes
UML : modèle des classes
Packages : exemple
Packages
3 Un package peut comporter d’autres packages :
Encapsulation des classes en distinguant :
Banque
◦ les classes privées
(classes strictement internes au package) ;
◦ les classes protégées
(classes pouvant être utilisées par des classes
appartenant à des packages « fils ») ;
Transactions
◦ les classes publiques
(classes pouvant être utilisées par des classes de
n’importe quel package).
Comptes
3 Dans chaque diagramme on contrôle librement le
niveau de détail :
Banque
Liens de généralisation, de référencement et de
composition entre packages (un package peut encapsuler
d’autres packages).
Comptes
Transactions
Compte
Compte_particulier
Compte_societe
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 35
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
Classes
36
UML : modèle des classes
Packages et classes : exemple
Une classe appartient à un (et un seul) package.
3 Le package Comptes comporte trois classes :
Rappel : une classe peut être publique, privée ou
protégée au sein de son package.
Compte
Une classe peut comporter des attributs, des opérations
et un invariant.
Une classe peut être en relation avec :
– des classes du même package ;
– des classes publiques appartenant à des packages «
visibles » depuis le package courant.
Compte_particulier
; la classe Compte est abstraite (italique) ;
Une classe peut être abstraite (au sens Java/C++)
; notation : nom de la classe en italique...
...ou alors écriture de la propriété {abstract} sous le
nom.
; la classe Compte est la classe mère des deux autres
classes du package.
Remarque : à l’extérieur de leur package de définition les
noms de classes sont préfixés par le nom du package...
; Exemple : Comptes::Compte_societe
Remarque : deux classes peuvent porter le même nom à
condition de ne pas appartenir au même package.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Compte_societe
37
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 38
UML : modèle des classes
UML : modèle des classes
Attribut
Invariant de classe
Un attribut possède :
Ensemble de contraintes d’intégrité que doit satisfaire
l’ensemble des instances de la classe.
◦ un nom ;
◦ un type ;
Ces contraintes expriment tout ce qui ne peut pas être
exprimé par les attributs et les opérations.
◦ éventuellement une valeur par défaut.
Expression syntaxique uniquement : sous forme
textuelle et/ou sous forme d’expressions booléennes dans
le langage d’implantation final (e.g. C++ ou Java) ou en
langage « OCL » (Object Constraint Language).
Un attribut peut être « de classe » (≡ static en
C++/Java)...
; notation : nom et type de l’attribut souligné.
Exemple :
Exemples :
Salaire
– L’invariant de la classe NombrePair est que le modulo
2 de la valeur de l’attribut value doit être nul (ou en
Java : value%2 == 0).
date_paye : date
indice : integer=0
facteur : real
– Soit une classe Carré héritière d’une classe
Rectangle, son invariant peut s’écrire en Java :
largeur == hauteur
Types élémentaires pré-définis en UML : boolean, char,
integer, real, string.
Possibilité de définir de nouveaux types élémentaires au
niveau d’une classe ou d’un package.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 39
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
UML : modèle des classes
Invariant de classe : exemple
Opération
Une opération est définie par :
3 La contrainte associée à l’attribut valeur a été
déclarée comme un invariant :
◦ son nom ;
◦ ses paramètres : nom, type, valeur par défaut, mode de
passage :
– passage par valeur : In ;
– passage par référence pour un résultat : Out ;
– passage par référence d’une valeur qui pourra être
modifiée : Inout ;
Nombre_pair
+valeur : integer
40
{valeur modulo 2
doit être nul.}
◦ son type de retour éventuel ;
Une simple annotation à
but documentaire
◦ son action sur l’instance courante :
– modification possible (mode par défaut) ;
– opération « constante » : propriété query.
Remarque : outre l’invariant, on a associé une note à
l’attribut valeur. En fait on peut associer une note à toute
entité UML et ce dans n’importe quel diagramme.
Une opération peut être « de classe »
; notation : souligné
Une opération peut être abstraite
; notation : en italique ou étiquette {abstract}
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 41
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 42
UML : modèle des classes
UML : modèle des classes
Classe, attribut, opération : exemple
Pré-/Post-conditions
Pré-conditions d’une opération : ensemble des
conditions préalables à l’exécution de l’opération.
Salaire
Post-conditions d’une opération : ensemble des
conditions devant être vérifiées à l’issue de l’exécution
de l’opération.
date_paye : date
indice : integer=0
facteur : real
augmenter(In montant:euro)
calculer_salaire():euro
donner_avance(In montant:euro)
payer()
calculer_moyenne_salaires():euro
Elles sont toujours sous forme syntaxique :
◦ texte à usage documentaire ;
◦ expression en langage OCL ;
◦ expression booléenne exprimée dans le langage
d’implantation (e.g. Java ou C++).
Question : il y a plusieurs anomalies dans cette
spécification, lesquelles ?
Elles comprennent toujours implicitement l’invariant de
la classe. Cas particuliers :
◦ pour le constructeur, l’invariant n’est pas ajouté à la
pré-condition mais il l’est à la post-condition ;
◦ pour le destructeur, l’invariant est ajouté à la
pré-condition, mais ne l’est pas à la post-condition.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 43
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
Pré-/Post-conditions : exemple
44
UML : modèle des classes
Visibilité des attributs, opérations et associations
Public ... notation : nom préfixé par +
; élément accessible à tous.
Soit l’opération :
Package ... notation : nom préfixé par ∼
; élt. accessible aux seules instances des classes
appartenant au même package.
débiterCompte(montant : in Euros) :
Pré-condition : Le solde du compte est supérieur à
« montant ».
Protégé ... notation : nom préfixé par #
; élt. accessible aux seules instances de la classe, ainsi
qu’aux instances des classes dérivées.
Post-condition : Le solde du compte a bien été diminué de
« montant ».
Privé ... notation : nom préfixé par –
; élt. accessible seulement aux instances de la classe.
Exemple :
Salaire
#date_paye : date
#indice : integer=0
#facteur : real
+augmenter(In montant:euro)
+calculer_salaire():euro
+donner_avance(In montant:euro)
+payer()
+calculer_moyenne_salaires():euro
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 45
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 46
UML : modèle des classes
UML : modèle des classes
Association
Avion
Classe d’association
+propulseur
véhicule_propulsé
propulsion
1-1
Permet d’attacher des propriétés (attributs et/ou
opérations) directement à l’association liant deux classes.
Réacteur
2-*
Attention : une classe d’association ne peut être reliée
qu’à une seule association (par contre elle peut être en
relation avec d’autres classes).
Une association peut avoir :
◦ un nom ;
◦ deux rôles ;
Exemple :
◦ une orientation (voir p.49) ;
Entreprise
◦ deux cardinalités — la cardinalité indique les nombres
d’instances minimum et maximum pouvant être liées à
une instance de la classe.
Exemples : 2
*
0..2
1..*
1..10, 50, 100
employeur
employé
*
Consultant
*
Mission
+description : string
+salaire : integer
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 47
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
Association orientée
48
UML : modèle des classes
Exercice : associations à orienter
L’orientation spécifie un sens d’utilisation, c-à-d. : la
classe qui utilise vs la classe qui est utilisée.
Assureur
Homme
Une association peut ainsi :
◦ être orientée dans un sens ;
◦ être orientée dans les 2 sens ;
Fichier
Répertoire
◦ ne pas être orientée.
A l’issu de l’analyse, toutes les associations devraient
être orientées, et, sauf cas très particulier, dans un seul
sens.
Professeur
Elève
Bibliothèque
Ouvrage
Exemple :
propulsion
Avion
1-1
+propulseur
Réacteur
2-*
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 49
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 50
UML : modèle des classes
Visibilité d’une association orientée
UML : modèle des classes
Cas particulier d’associations : les agrégations
Une agrégation dénote l’idée de « faire partie de ».
Une association orientée peut être :
◦ privée ;
On distingue :
◦ protégée ;
◦ l’agrégation partagée (ou agrégation)
Exemple :
◦ public.
Groupe de travail
Personne
*
Exemple :
+direction
2-*
Volant
1
Conducteur
◦ l’agrégation de composition (ou composition)
Exemple :
Voiture
Voiture
1
-propulseur
Roue
0..1
Moteur
4
; Le conducteur doit pouvoir manipuler le volant, mais
pas le moteur.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 51
UML : modèle des classes
Généralisation / spécialisation
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 52
UML : modèle des classes
Contraintes sur la généralisation
Expression du lien « est-sous-classe-de » entre classes.
UML permet d’ajouter des précisions sur les liens de
généralisation. Plusieurs contraintes sont pré-définies :
Généralisation simple (1 super-classe au maximum) ou
multiple.
{overlapping} ; une classe dérivée peut hériter de
plus d’une mère.
Toutes les propriétés d’une super-classe sont vraies pour
chaque classe fille.
{disjoint} ; une classe dérivée NE PEUT hériter
que d’une mère.
L’invariant d’une sous-classe comprend celui de sa
super-classe.
{complete} ; toutes les classes filles sont spécifiées.
{incomplete} ; la liste des classes filles est
incomplète.
Exemple de généralisation simple :
Véhicule
Avion
Bateau
Train
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 53
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 54
UML : modèle des classes
UML : modèle des classes
Contraintes sur la généralisation : exemples
Liens entre classes : résumé
Trois niveaux pour les liens d’utilisation entre classes :
Mammifère
1. conceptuel : liens forts et permanents entre objets
; en UML : association et généralisation ;
{disjoint}
Chat
Chien
{incomplete}
2. contextuel : paramètre d’une opération
; en UML : dépendance ;
3. opérationnel : utilisation dans le corps de la méthode
; en UML : dépendance.
Animal
Exemple :
Mammifère
{overlapping}
{disjoint}
Mammifère
Personne
Oiseau
Nourriture
propriétaire
Carnivore
1
Patte
Aigle
*
membre
4
Chien
Couteau
1
Fourchette
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 55
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
UML : modèle des classes
Diagrammes d’instances (ou diagrammes d’objets)
Utilisation contextuelle et opérationnelle : exemple
Soit la méthode manger de la classe Chien :
Possibilité d’y mélanger classes et instances.
manger(Nourriture repas) {
// Utilise les classes :
//
couteau, fourchette.
.
.
.
Couteau.prendre() ;
Fourchette.prendre() ;
Fourchette.immobiliser(repas) ;
Couteau.couper(repas) ;
.
.
.
}
Désignation des instances :
nom de l′ instance : Nom de la Classe
ou bien nom de l′ instance
ou bien : Nom de la Classe
Utilisation :
◦ permet de visualiser les valeurs des attributs ;
◦ permet de visualiser la totalité des instances lorsqu’on
en connaı̂t à l’avance le nombre ;
◦ permet d’illustrer sur des exemples la pertinence des
différents liens ;
◦ permet de visualiser l’état du système à un instant
donné ;
; Utilisation contextuelle de «nourriture» ;
; Utilisation opérationnelle de «couteau» et «fourchette».
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 56
◦ facilite la compréhension de structures de données
complexes (récursives).
57
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 58
UML : modèle des classes
Diagrammes d’instances : exemple
UML : modèle des classes
Règles d’emploi du modèle des classes
Un modèle peut être correct, c’est-à-dire cohérent par
rapport aux notations et à la syntaxe, sans qu’il soit pour
autant valide (c-à-d. sans correspondre au problème que
l’on veut modéliser).
payeDeMrMachinMars2001:Virement
Id : integer=1263636737
Il ne sera pas surprenant que le modèle objet construit ait
besoin de nombreuses révisions.
; Itérer pour clarifier les noms, ajouter des détails,
prendre en compte correctement les contraintes
structurelles.
compteMrMachin:Compte_particulier
Num : integer=03003.03080.13462345.06
compteCieLambda:Compte_societe
Choisir les noms avec soin. Ils sont importants. Ils
doivent être précis, descriptifs, non-ambigus.
Num : integer=03052.01367.00031487.02
Documenter systématiquement le modèle des classes. Un
diagramme spécifie la structure d’un modèle, mais ne
peut pas décrire, notamment, les raisons qui ont poussé à
certains choix.
Question : il y a plusieurs anomalies dans ce diagramme,
lesquelles ?
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 59
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
Règles relatives aux packages
UML : modèle des classes
Règles relatives à la définition de classes
Pas de dépendances mutuelles entre 2 packages (ni de
cycles dans les liens entre packages)
Une classe doit correspondre à une certaine « réalité » de
la chose à modéliser :
◦ ne pas faire apparaı̂tre de classes inutiles ;
; Voir les packages comme moyen de structuration
strict (en vue d’un découpage du travail de conception /
programmation en équipes séparées).
◦ ne pas dupliquer de classes ;
◦ chaque classe doit pouvoir se justifier par les
opérations qu’elle fournit de manière exclusive et/ou
représenter un concept clairement identifié du système.
Dans un même package, ne pas ouvrir la visibilité sur les
classes privées d’un package (ni par héritage, ni par une
association publique).
Les classes (et les associations) doivent correspondre à
des éléments stables (par opposition à des états, des
dépendances, etc.)
; (mauvais) Exemples :
-C2
60
-C4
+R
1
1
C1
C3
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 61
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 62
UML : modèle des classes
Règles relatives à la définition de classes : exercice
UML : modèle des classes
Règles relatives à l’arité des associations
Que penser de cette modélisation ?
On évitera l’écriture d’associations d’arité > 2.
; Ceci n’est nullement restrictif : toute association
n-aire peut se transformer en n associations binaires.
Livre
1
Exemple :
1
chose_enseignée
emballage
1
1
contenu
Professeur
Couverture
Suite_De_Pages
Matière
1..*
1..*
enseignant
1..*
destinataire
Groupe
1
⇓
1..*
élément
Professeur
1..*
enseignant
Page
Matière
*
1..*
Enseignement
chose_enseignée
*
1
1..*
destinataire
Groupe
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 63
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
Règles relatives aux attributs
64
UML : modèle des classes
Règles relatives aux attributs (2)
Identifiant d’une classe : valeur caractérisant un objet.
≡ le sous-ensemble minimal des attributs nécessaires pour
distinguer de façon certaine 2 instances quelconque de la
classe. (e.g. : num. de sécurité sociale vs nom + prénom).
Tout attribut d’une classe devrait être du type d’une
classe élémentaire (sinon ⇒ association).
Un attribut doit avoir une signification pour toutes les
instances de la classe dans laquelle il est défini.
La valeur d’un attribut n’appartenant pas à l’identifiant I
de la classe ne doit pas dépendre (fonctionnellement) :
◦ d’un attribut n’appartenant pas non plus à I ;
◦ d’un sous-ensemble strict de I.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 65
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 66
UML : modèle des classes
UML : modèle des classes
Règles relatives à la généralisation : exercice
Règles relatives à la généralisation
Que penser de ces généralisations ?
Ne pas factoriser artificiellement des concepts différents.
Rappel : une instance ne peut jamais changer de classe
(penser aux états dans ce cas).
Objet_Avec_Nom_Et_Age
+nom : string
+age : integer
Se souvenir que toute classe dérivée hérite de l’ensemble
des propriétés de la classe de base.
Personne
Planète
Elément_Gérable
+gérer()
Projet
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 67
Compte_Bancaire
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
Règles relatives à la généralisation : exercice (2)
UML : modèle des classes
Règles relatives aux pré-/post-conditions
Une classe fille doit permettre l’exploitation de chaque
opération dans tous les cas autorisés au niveau de la
classe mère...
=⇒ maintient ou réduction des pré-conditions.
Critiquer/améliorer cette modélisation :
Périphérique
Aussi, une opération spécialisée doit pouvoir accomplir
au moins ce qu’accomplit son équivalent dans la classe
de base...
=⇒ maintient ou augmentation des post-conditions.
+controler()
+attendre()
+lire()
+ecrire()
Disque_Dur
Exemple :
Ecran
Véhicule_Transposrt_Aérien
Pré-condition
{piste > 3 km}
+décoller()
Imprimante
68
Post-condition
{altitude > 600 pieds}
Clavier
Avion_Tourisme
+décoller()
Bande_Magnetique
Pré-condition
{piste > 300 m}
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Hélicoptère
69
+décoller()
Post-condition
{altitude > 1600
pieds}
Post-condition
{altitude >
1000 pieds}
Pré-condition
{piste > 5 m}
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 70
UML : modèle des classes
UML : modèle des classes
Orientations mutuelles : exercice
Règles relatives aux orientations des liens entre classes
Les orientations mutuelles sont à éviter :
; gène pédagogique ;
Critiquer/améliorer cette modélisation :
; difficultés pour développement, tests et intégration.
Humain
Degré de gravité :
◦ niveau conceptuel : grave ;
◦ niveau contextuel : gênant ;
◦ niveau opérationnel : acceptable.
(mauvais) Exemples :
Homme
C1
C3
1
2
C4
épouse
Femme
0-1
1
1-*
C2
mari
0-1
C5
3
C6
C7
*
Rappel : dépendances mutuelles entre packages
strictement interdites.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 71
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle des classes
72
UML : compléments au modèle des classes
Exercice : le plombier et l’épicier
Comme pour les associations : éviter dans la mesure du
possible les utilisations contextuelles mutuelles.
UML : compléments au modèle
des classes
Exercice : critiquer/améliorer cette modélisation
Epicier
Plombier
1. Interfaces.
+vendre_victuailles()
+faire_réparer_plomberie()
2. Classes paramétrables.
+réparer_plomberie()
+acheter_victuailles()
3. Attributs/associations dérivés et identifiants.
4. Responsabilités, etc..
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 73
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 74
UML : compléments au modèle des classes
UML : compléments au modèle des classes
Interfaces : notations
Interfaces
Deux notations pour interfaces et liens de réalisation...
Concept similaire aux interfaces Java. Une interface :
; porte un nom ;
; liste des opérations (publiques) ;
; peut lister des signaux (notamment des exceptions) ;
; ne comporte ni attributs, ni associations ;
; ne peut pas être instanciée ;
; sert à spécifier un type abstrait pouvant être implanté
par une ou plusieurs classes.
1. Notation « compacte » :
I1
ClasseUtilisatrice
ClasseRéalisatrice
I3
I2
2. Notation « détaillée » :
Possibilité de généralisation entre interfaces.
I1
Lien de dépendance entre une classe C et une interface I
=⇒ classe C utilise le type abstrait défini par I.
I3
<<interface>>
I2
ClasseRéalisatrice
+m4()
+m3()
+m1()
+m2()
+m3()
+m4()
+autreOpération()
NOTA-BENE : en termes de méta-modèle UML, une
interface est une classe avec le stéréotype « interface ».
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, +m1()
+m2()
ClasseUtilisatrice
Lien d’implantation (ou de « réalisation ») entre une
classe C et une interface I
=⇒ la classe C implante les opérations listées dans I.
75
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : compléments au modèle des classes
Interfaces : exemple
76
UML : compléments au modèle des classes
Interfaces : exemple (vue détaillée)
Simulateur
Matrice
+get(In l:integer ,In c:integer):real
+afficher()
+ajouter(In m:Matrice)
+mult(In m:Matrice)
Calculateur
Matrice
MatriceCarrée
+puissance(In n:integer)
<<throw>>
<<throw>>
<<throw>>
MatriceCarrée
MatriceCreuse
MatriceCreuse
+convertirEnDense():MatriceDense
+get(In l:integer ,In c:integer):real
+afficher()
+ajouter(In m:Matrice)
+mult(In m:Matrice)
MatriceDense
<<throw>>
<<exception>>
MatrixException
<<throw>>
<<throw>>
MatriceCarréeCreuse
MatriceCarréeDense
MatriceCarréeCreuse
+puissance(In n:integer)
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 77
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 78
UML : compléments au modèle des classes
Résumé : interfaces, classes, classes abstraites
Résumé : généralisations et liens d’implantation
En UML et en Java :
Généralisation entre deux interfaces :
; relation de nature sous-type / type entre deux types
abstraits.
une interface équivaut à un type abstrait (n’inclut aucune
implantation) ;
une classe (non-abstraite) équivaut à un type abstrait
accompagné d’une implantation complète ;
Généralisation entre deux classes :
; la sous-classe hérite à la fois le type abstrait et
l’implantation correspondant à la classe mère.
une classe abstraite est un concept intermédiaire qui
équivaut à type abstrait accompagné d’une implantation
incomplète (ou vide).
Lien d’implantation entre une classe (non abstraite) et
une interface :
; relation de nature type concret / type abstrait ;
; la classe (éventuellement via les classes dont elle
hérite) inclut (au minimum) le code correspondant à
l’ensemble des méthodes définies dans l’interface.
Remarques :
Une classe (abstraite ou pas) peut implanter zéro, une ou
plusieurs interfaces.
Inversement, une même interface peut être implantée par
zéro, une ou plusieurs classes.
Lien d’implantation entre une classe abstraite et une
interface :
; sémantique moins claire que dans les autres cas
(permet de combiner un sous-typage abstrait et/ou un
début de concrétisation).
Seules les classes non abstraites peuvent être instanciées.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : compléments au modèle des classes
79
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : compléments au modèle des classes
80
UML : compléments au modèle des classes
Classes paramétrables (ou classes templates)
Responsabilités, ...
En vrac :
Responsabilités (d’une classe) : mention (pour les classes
d’interface) sous le nom de la classe du, ou des, cas
d’utilisation qu’elle prend en charge (cf. transparent 137
sur la recherche des classes d’interface).
Contraintes « Xor » (ou exclusif) au niveau d’un
ensemble d’associations partant d’une classe.
Classes/objets actifs : pour modéliser les applications
multi-threadées (notation : rectangle à bord gras).
Multi-objets : collection d’instances similaires dans un
diagramme d’instance...
Sémantique identique aux templates C++ et Java.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 81
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 82
UML : modèle dynamique
UML : modèle dynamique
Événements
Occurrence (instantanée) d’une situation donnée
significative pour le système.
UML : modèle dynamique
Les événements peuvent être :
◦ internes au système (émis par un objet) ;
1. Évènements.
◦ externes (capteur physique, bouton d’une IHM, etc.).
2. Diagrammes d’états.
Un événement peut apparaı̂tre dans les diagrammes :
3. Diagrammes de séquence.
◦ d’états ;
4. Diagrammes de collaboration.
◦ de séquence, de collaboration, d’activité ;
5. Diagrammes d’activité.
◦ de classes (événements « signaux » seulement, voir
plus loin).
6. Importance des commentaires.
7. Résumé et mode d’emploi du modèle dynamique.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 83
UML : modèle dynamique
Quatre types d’événements
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 84
UML : modèle dynamique
Événements de type « signal »
Un signal est un objet émis de manière asynchrone par
un objet « émetteur » à destination d’un autre objet «
récepteur ».
Événements asynchrones :
◦ Événement signal : stimulus asynchrone
; déclenche réaction chez le destinataire ;
; pas de « valeur de retour » possible mais possibilité
d’émettre un autre signal en réponse au premier.
Un signal peut être d’origine interne ou externe au
système.
◦ Événement temporel : expiration d’une
temporisation.
Exemple de signal interne : une exception (Java).
Exemple de signal externe : une action de l’utilisateur
(via l’IHM) ou l’action d’un capteur physique.
◦ Événement modification : passage à vrai d’une
expression booléenne.
En tant qu’objet, un signal doit être instance d’une classe
portant le stéréotype « signal » (classe à définir dans le
modèle des classes).
Événements synchrones :
◦ Événement appel : appel d’une opération
; déclenche l’opération chez le destinataire ;
; « valeur de retour » possible vers l’appelant.
Aussi, il peut comporter des attributs et des opérations
spécifiques.
Possibilité de visualiser les émissions possibles de
signaux dans un diagramme de classe à l’aide d’une
dépendance portant le stéréotype « send ».
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 85
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 86
UML : modèle dynamique
Exemple de signaux dans un diagramme de classes
UML : modèle dynamique
Cas particulier de signal : les « exceptions »
<<signal>>
ContextePhysique
Instance d’une classe portant le stéréotype « exception ».
Exemple :
<<exception>>
PilePleine
<<signal>>
PbTempérature
<<signal>>
PbHumidité
<<throw>>
+température : integer
Pile
<<signal>>
TropFroid
<<exception>>
PileException
<<signal>>
TropChaud
+ajouter()
+enlever()
<<throw>>
<<signal>>
BeaucoupTropFroid
<<signal>>
BeaucoupTropChaud
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, <<exception>>
PileVide
87
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle dynamique
Événements « temporels » (ou time events)
88
UML : modèle dynamique
Événements « modification » (ou change events)
Permet de spécifier le passage d’une certaine quantité de
temps.
Permet de représenter un changement d’état ou la
satisfaction d’une condition.
Instant de référence par défaut : l’entrée dans l’état
courant (voir plus loin).
La condition qui définit un événement « modification »
peut faire référence aux attributs et aux opérations de la
classe recevant l’événement (plus ceux des classes
visibles depuis cette dernière).
Exemples :
◦ after 30 seconds
Exemples :
◦ after 2 ms since exiting EnVeille
(fait référence à la sortie de l’état de nom EnVeille)
◦ when temperature > 30
◦ when nbInstances = 1000
◦ when client.cpt.solde > calculerSeuil()
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 89
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 90
UML : modèle dynamique
Diagrammes d’états (ou statechart diagram)
UML : modèle dynamique
Diagrammes d’états : principes
Exprime les règles d’utilisation des opérations de la
classe ainsi que les aspects réactifs du système :
Un diagramme d’états est généralement associé à une
classe (peut aussi être relatif à un use case ou au système
global).
◦ permet de contrôler l’ordre d’exécution des opérations
au sein d’une classe ;
Une classe peut avoir plusieurs diagrammes d’états.
◦ permet de spécifier que certaines opérations ne
peuvent s’appliquer que lorsque l’objet est dans un
certain état et/ou certaines contraintes sont satisfaites ;
Un diagramme d’états doit être déterministe : pour
chaque état les transitions sortantes doivent
correspondre :
◦ permet de tenir comptes des occurrences
d’événements.
◦ à des événements différents ;
◦ ou alors être gardées par des conditions incompatibles.
Il est défini par un automate d’états fini, c-à-d. un graphe
orienté dont les noeuds sont des états et les arêtes des
transitions.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 91
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle dynamique
Diagrammes d’états : états et transitions
92
UML : modèle dynamique
Diagrammes d’états : exemple
Les diagrammes d’états sont définis par :
des états : situations caractéristiques et stables du
fonctionnement des instances de la classe.
emprunter()
En rayonnage
◦ Cas particuliers : les états initial et final.
En prêt
retourner()
des transitions : manières dont un objet passe d’un état à
un autre... Une transition peut :
Diagramme d’états de la classe Livre
◦ correspondre à l’arrivée d’un événement ;
◦ avoir une condition de garde ;
Remarquer :
– l’état initial ;
– les 2 autres états ;
– les 2 transitions, chacune étant déclenchée par un
événement de type appel.
◦ donner lieu à l’exécution d’une opération de la classe
et/ou l’émission d’un événement.
Notation :
État1
Evt1[cond1]/m()^Evt2
État2
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 93
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 94
UML : modèle dynamique
UML : modèle dynamique
Diagrammes d’états : troisième exemple
Diagrammes d’états : deuxième exemple
Vide
EnVeille
débutEmbarquement/embarquerPassagers()
/débarquerPassagers()
tropChaud(températureSouhaitée)
tropFroid(températureSouhaitée)
Chargé
autorisationRejoindreLaPiste/rejoindrePiste()^demandeAutorisationDécollage
PrêtADécoller
températureOK
températureOK
/rejoindreAérogare()
autorisationDeDécollage/décoller()
tropChaud(températureSouhaitée)
Chauffage
Refroidissement
FinAttérrissage
tropFroid(températureSouhaitée)
EnVol
autorisationDAttérissage/atterir()
changerCap()
Diagramme d’états de la classe Thermostat
Diagramme d’états de la classe Avion
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 95
UML : modèle dynamique
Diagrammes d’états : précisions sur les états
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 96
UML : modèle dynamique
Diagrammes d’états : états composites
Pour chaque état, possibilité de spécifier :
Permet de simplifier les automates d’états en considérant
des états composés de sous-états.
◦ une action exécutée à l’entrée dans l’état ;
◦ une action exécutée à la sortie de l’état ;
Le diagramme d’état correspondant à un état
« composite » doit comporter au maximum un état initial
et un état final.
◦ une activité à effectuer tant qu’on reste dans l’état ;
◦ des transitions internes (qui ne déclenchent donc pas
les actions ci-dessus) ;
◦ des événements dont le traitement est « retardé ».
Exemple :
Appel en attente
entry/incrémenterCompteurClientsEnAttente()
exit/decrémenterCompteurClientsEnAttente()
do/jouerMusiqueDouce()
after(90 seconds)/jouerMessageExcusePourAttente()
toucheClavier(n)/defer
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 97
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 98
UML : modèle dynamique
Diagrammes d’états : quatrième exemple
UML : modèle dynamique
Scénarios (ou diagrammes d’interactions)
Actif
Exemples de traitement au sein du système.
Invalide
compose(n)[n invalide]
décroche
Associés à un package, une classe, ou un cas
d’utilisation.
Tonalité
En composition
compose(n)[n valide]
Repos
S’expriment sous la forme d’une séquence d’envois de
messages et/ou signaux entre des objets (objets concrets
ou prototypes).
after(15 seconds)
occupé
Diagrammes utiles pour :
Tonalité occupée
◦ vérifier la complétude de l’analyse, mettre en évidence
des incohérences, etc. ;
appelant raccroche
connecté
appelé raccroche
Dialogue
◦ documenter l’analyse, illustrer le fonctionnement
d’une partie du système ;
Sonnerie
◦ préparer des jeux de test.
appelé décroche
Diagramme d’états de la classe Téléphone avec
visualisation du contenu de l’état composite Actif
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 99
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle dynamique
100
UML : modèle dynamique
Diagramme de séquence vs de collaboration
Diagramme de séquence : notations
:Classe1
Deux types de diagrammes sémantiquement équivalents
disponibles en UML pour exprimer des scénarios :
objetMachin:Classe2
m1()
create()
objetTruc:Classe3
les diagrammes de séquence pour mettre en évidence la
dimension temporelle dans l’enchaı̂nement des
interactions entre objets ;
m2(x,y)
s1(x,y)
les diagrammes de collaboration pour mettre en
évidence comment les objets coopèrent pour mener à
bien le scénario.
z
m2(x2,y2)
s2(x2,y2)
z2
m3()
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 101
m4()
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 102
UML : modèle dynamique
UML : modèle dynamique
Diagramme de séquence : exemple et exercice
Diagramme de séquence : autre exemple
Critiquer/améliorer le scénario suivant :
Jean:Employé
:Téléphone
:Patron
:Standard
:Usager
salaireDeJean:
décrocher()
demanderAvance(4000)
sonnerTonalité()
donnerAvance(2000)
composer(9294)
2000
demander(9294)
demanderAugmentation()
sonnerAttenteDeConnexion()
0
occupé()
donnerDémission()
sonnerOccupé()
rembourser(2000)
rembourserAvance(2000)
raccrocher()
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 103
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle dynamique
Diagramme de séquence : exercice
104
UML : modèle dynamique
Diagramme de séquence : notations pour switch & while
i1:
i2:
i3:
Critiquer/améliorer le diagramme suivant :
[CONDITION] m1()
:Société
:Cabinet recutement
Mr.X:Personne
[non CONDITION] m2()
demande("Dir. achats")
Mr.X
proposerEntrevue("15 mars 14h")
[CONDITION1] m3()
entrevue()
[CONDITION2] m4()
décideEmbauche(Mr.X)
[CONDITION3] m5()
false
notifierRefus(Mr.X)
notifierRefus()
* [CONDITION] m6()
Mr.Y
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 105
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 106
UML : modèle dynamique
Diagramme de collaboration : notations
UML : modèle dynamique
Diagrammes d’activités
Graphe orienté associé à une activité.
/:Classe1
Permet de spécifier le fonctionnement interne d’une
activité en la décomposant en :
1:m1()
2:m2(x,y)
◦ actions (e.g. envoi de signal, appel d’opération,
création/destruction d’objet, évaluation d’une
expression) ;
3:m2(x2,y2)
4:m3()
◦ sous-activités (chacune pouvant être spécifié à son tour
par un diagramme d’activités).
/objetMachin:Classe2
Rappel : les activités sont décomposables et
interruptibles alors que les actions ne le sont pas.
1.1:create()
2.1:s1(x,y)
3.1:s2(x2,y2)
4.1:s3()
4.1.1:destroy()
/objetTruc:Classe3
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 107
UML : modèle dynamique
Diagrammes d’activités : utilisation
108
UML : modèle dynamique
Diagrammes d’activités : principes et notations
Deux contextes d’utilisations distincts :
Actions et sous-activités se représentent de la même
manière en tant que sommet du graphe tandis que les
arcs indiquent l’enchaı̂nement depuis l’état initial
jusqu’à l’état final.
1. Macroscopique
Modélisation d’un flux de traitements (workflow) :
◦ permet de décomposer les activités du point de vue
des acteurs du système
; détailler/expliciter les activités métiers ;
Les sous-activités peuvent comporter des champs
entry et exit.
Contrairement aux diagrammes d’états, les transitions
s’effectuent dès que l’action ou sous-activité précédente
est terminée.
◦ diagramme associé typiquement à un cas
d’utilisation (éventuellement à un package, une
classe ou une collaboration.)
Possibilité d’inclure les instances créés, modifiées ou
détruites au sein de l’activité en dessinant un lien de
dépendance vers l’instance depuis l’élément du
diagramme d’activité qui l’a créé, modifiée ou détruite.
2. Microscopique
Modélisation d’une opération (flowchart) :
◦ visualise la séquence d’instructions correspondant
au corps de la méthode
; « programmation visuelle » ;
Notations spécifiques pour :
– branchement conditionnel ;
– concurrence (fork & join) ;
– partionnement en lignes d’eau (ou « swimlane »).
◦ diagramme associé typiquement à une opération.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 109
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 110
UML : modèle dynamique
Diagramme d’activités : exemple
UML : modèle dynamique
Diagramme d’activités : autre exemple
Consommateur
Serveur
Cuisinier
n=1
Choisir table
Apporter carte
[arrivée nouveau client]
val=f(val)
Attente
[val < seuil]
[client prêt à commander]
Refléchir
return n
[else]
Demander choix
Passer commande
n++
Noter commande
Préparer commande
Modélisation d’une méthode
Modélisation d’un workflow
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 111
UML : modèle dynamique
Importance des commentaires
112
UML : modèle dynamique
Résumé et mode d’emploi du modèle dynamique
Outre les diagrammes vus jusqu’ici (et afin de préciser le
mieux possible la dynamique du système) :
1. Si besoin, à titre documentaire, expliciter le contexte
général (métier) à travers un (ou plusieurs)
diagramme(s) d’activités.
Penser à décrire les traitements en attachant des
descriptifs textuels aux opérations complexes. Ces
descriptifs peuvent être de différentes sortes :
2. Expliciter les interactions utilisateur–système à travers
un (ou plusieurs) scénario(s) macroscopique(s).
1. Summary : bref résumé (e.g. 1 ligne) ;
3. Identifier les classes ayant des comportements
systématiques, réagissant à des conditions particulières.
Pour ces classes définir un (ou plusieurs) diag. d’états.
2. Description : spécification/explication détaillée du
traitement ;
3. Comment : commentaire technique (destiné au
concepteur/programmeur) .
4. Préparer un jeu de scénarios détaillés pour tester /
illustrer la faisabilité des principales fonctionnalités en
termes d’enchaı̂nements de méthodes (diag. de
séquence et/ou diag. de collaboration).
Prendre soin d’utiliser exactement les termes employés
pour la description du modèle (nom des classes, rôle des
associations, etc).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 5. Si besoin, et à titre documentaire, spécifier le
fonctionnement des principales ops. de chaque classe :
– à travers un diag. d’activité ;
– et/ou un descriptif textuel.
113
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 114
UML : modèle fonctionnel
UML : modèle fonctionnel
Acteurs
Un acteur est une entité extérieure au système et amenée
à interagir avec lui.
Un acteur est une classe (avec stéréotype « actor »).
UML : modèle fonctionnel
Un acteur peut représenter un utilisateur direct du
système (humain) ou un autre système.
1. Acteurs.
On distingue :
2. Cas d’utilisation.
◦ les acteurs primaires (ceux pour qui le système est
directement prévu) ;
3. Diagrammes de cas d’utilisation.
◦ les acteurs secondaires (ceux dont l’existence est la
conséquence des besoins des utilisateurs primaires).
4. Relations entre cas d’utilisation.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 115
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle fonctionnel
Acteurs : exemple
116
UML : modèle fonctionnel
Cas d’utilisation (ou use cases)
Un cas d’utilisation est une manière particulière
d’utiliser le système.
Un cas d’utilisation correspond à une séquence
d’interactions entre le système et un ou plusieurs acteurs.
Propriétaire
Constructeur
Un jeu de cas d’utilisation permet de décrire de manière
informelle le service rendu par le système dans sa
globalité, autrement dit, ils fournissent une expression
fonctionnelle du système.
Voiture
Conducteur
Un cas d’utilisation porte un nom.
Notation : un ellipse autour du nom du cas d’utilisation.
<<actor>>
Garagiste
Les diagrammes de cas d’utilisation permettent de
visualiser les liens entre acteurs et cas d’utilisations,
ainsi que les liens entre cas d’utilisation.
Passager
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 117
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 118
UML : modèle fonctionnel
Diagramme de cas d’utilisation : exemple
UML : modèle fonctionnel
Relations entre cas d’utilisation
Inclusion :
; permet une approche « top-down » de la spécification
des besoins utilisateurs (indique qu’un cas d’utilisation
se décompose en plusieurs autres).
Voiture
Se déplacer
Généralisation :
; permet de définir un cas d’utilisation comme un cas
particulier d’un autre plus général et/ou plus abstrait.
Ecouter de la musique
Conducteur
Téléphoner
Extension :
; permet la gestion des « variantes »
– pouvant être ajoutées (ou pas) à une fonctionnalité
initiale mais qui ne sont pas strictement nécessaires à la
complétion du cas d’utilisation de départ,
– dont la présence ou l’absence dépend, par exemple, du
matériel utilisé pour le déploiement du système.
Garagiste
Changer les bougies
Faire la vidange
NOTA-BENE : penser au critère de « sous-partie
strictement nécessaire » pour discriminer entre relations
d’inclusion et d’extension.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 119
UML : modèle fonctionnel
Relations entre cas d’utilisation : exemple
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 120
UML : modèle fonctionnel
Double intérêt de la relations « include »
Parmi les trois sortes de relations entre cas d’utilisation,
la relation « include » est la plus utile car elle permet
tout à la fois de hiérarchiser et de factoriser les cas
d’utilisation.
Voiture
Faire la vidange
Faire une ristourne
<<include>>
<<extend>>
Vérifier l’allumage
<<include>>
Réparer automobile
Garagiste
<<include>>
Changer plaquettes de frein
<<include>>
Réparer une Formule 1
Changer l’aileron
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 121
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 122
UML : modèle fonctionnel
UML : modèle fonctionnel
Exemple de factorisation par la relation « include »
Exemple de hiérarchisation par la relation « include »
Voiture
Distributeur de billets
<<include>>
Établir le contact
Consulter compte
<<include>>
Démarrer
<<include>>
<<include>>
Se déplacer
Débrayer
<<include>>
Retirer argent
<<include>>
Composer code
Client
Embrayer
<<include>>
<<include>>
Accélérer
<<include>>
Effectuer virement
<<include>>
Passer une vitesse
<<include>>
Freiner
Tourner le volant
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 123
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle fonctionnel
124
Méthodologie pour l’analyse et la validation
Diagramme de séquence / cas d’utilisation : exemple
dabCL1:Distibuteur de billets
Méthodologie pour l’analyse et
la validation
:Client
introduireCarte()
afficher("Saisissez votre code")
saisirCode(7435)
vérifierCode(7435)
1. Rappel : le cycle en V.
"code OK"
afficherMenuPrincipal()
2. Méthodologie : introduction.
3. Les étapes de l’analyse.
choisirRetrait()
afficherMenuRetraits()
4. Préparation de la validation.
5. Résumé : pertinence des différents éléments d’UML.
choisirMontant(200)
vérifierRéserve(200)
6. Document d’analyse.
"réserve OK"
afficher("Pour récupérer vos billets, reprenez votre carte")
ejecterCarte()
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 125
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 126
Méthodologie pour l’analyse et la validation
Méthodologie pour l’analyse et la validation
Rappel : le cycle en V
Méthodologie : introduction
Mise en parallèle des phases de construction et de
vérification :
Expression
des besoins
et
Analyse
préparation
Méthodologie (ou software development process) :
◦ démarche menant de la spécification d’un besoin à la
réalisation d’un logiciel (ou à la modification d’un
logiciel existant) ;
◦ comporte de nombreux aspects : techniques mais aussi
gestionnaires (planification du développement,
optimisation des coûts et des délais, maı̂trise des
risques).
Validation
Conception
préliminaire
Intégration
Conception
détaillée
tests unitaires
Guide les différents intervenants
; équilibre à trouver entre :
◦ des contraintes destinées à assurer la maı̂trise des
coûts, des délais et le respect des spécifications ;
Réalisation
◦ la créativité indispensable, notamment, lors des phases
d’analyse et de conception.
Cycle bien adapté aux « petits » projets
(au-delà : penser au cycle en spirale).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 127
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie pour l’analyse et la validation
128
Méthodologie pour l’analyse et la validation
Méthodologie : contenu
Méthodologie et UML
Répond aux questions suivantes :
UML n’inclut pas de méthodologie.
Quelles sont les différentes phases du cycle de vie et
comment s’enchaı̂nent-elles ?
Toutefois,
◦ UML suggère l’utilisation d’une méthodologie basée
sur les cas d’utilisation ;
Comment s’y prendre pour identifier les besoins,
structurer le système en classes et packages, planifier les
moyens à mettre en oeuvre pour chaque phase, ... ?
◦ les auteurs d’UML proposent la méthodologie
« RUP » (Rational Unified Process).
Quand utiliser quel diagramme (plus quels stéréotypes
et/ou annotations) et pour quoi faire ?
Il faut en fait distinguer :
◦ le langage de modélisation UML ;
Quelles sont les productions dues à l’issue de chaque
phase : quels documents, logiciels et/ou données ?
◦ les règles d’utilisation des différents modèles ;
Qui réalise quoi dans chaque phase ?
◦ les méthodologies génériques comme l’UP et ses
déclinaisons : RUP, EUP, ... ;
◦ une méthodologie « ad hoc » (adaptée aux besoins
spécifiques d’une équipe pour un projet donné.)
...
Principales méthodologies compatibles UML :
◦ « générales / génériques » : UP/RUP/..., Catalysis, ... ;
◦ « agiles » : XP, Scrum, Crystal, ... (cf. bibliographie).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 129
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 130
Méthodologie pour l’analyse et la validation
Méthodologie pour l’analyse et la validation
A1 : Expression des besoins (Requirements Elicitation)
L’analyse (en 8 étapes)
A1. Expression des besoins.
Identifier les utilisateurs du système (au sens d’acteurs
UML : entité externe au système et amenée à interagir
avec lui).
A2. Établir le dictionnaire.
Pour chaque type d’utilisateur :
Huit étapes (pas forcément séquentielles) :
1. Identifier les besoins fondamentaux : ceux dont la
satisfaction motivent la réalisation du système.
A3. Identifier et définir les classes d’interface.
A4. Structurer le modèle.
2. Identifier les besoins opérationnels : ensemble des
actions que l’utilisateur devra effectuer pour satisfaire
chacun de ses besoins fondamentaux.
A5. Construire les premiers scénarios.
A6. Vérifier la cohérence de l’analyse préliminaire.
Modéliser les utilisateurs en termes d’acteurs.
A7. Détailler le modèle.
Modéliser les besoins par des cas d’utilisation.
A8. Vérifier la qualité de l’analyse détaillée.
Décrire (brièvement) sous forme textuelle chaque cas
d’utilisation.
Identifier aussi les besoins non-fonctionnels
; vitesse des traitements, capacité d’accès simultané,
etc.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 131
Méthodologie pour l’analyse et la validation
Exercice : l’ascenceur
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 132
Méthodologie pour l’analyse et la validation
Précisions sur l’analyse fonctionnelle
Utiliser le vocabulaire du client exclusivement :
Soit un ascenceur dans un petit immeuble d’habitation de 5
étages plus 2 niveaux en sous-sol. Quels sont :
– les utilisateurs ?
– les besoins fondamentaux ?
– les besoins opérationnels ?
◦ pas de termes typiquement informatiques (classe,
instance, attribut, association, généralisation, etc.) ;
◦ l’ensemble de l’analyse fonctionnelle doit être
facilement compréhensible par le client.
Fournir une vue strictement externe du système à réaliser
(on ne s’intéresse donc pas encore à son architecture).
Clarifier, à la manière d’un contrat, ce que le système
doit faire et ce qu’il ne doit pas faire.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 133
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 134
Méthodologie pour l’analyse et la validation
Précision sur le dictionnaire
A2 : Établir le dictionnaire (ou « glossaire »)
Nom
Définition
Traduction
Nom
UML
informatique
Méthodologie pour l’analyse et la validation
Moyen pour établir et figer la terminologie du domaine
de l’application.
Point d’entrée et référentiel initial de l’application.
Outil de communication avec les clients.
Outil pour assurer la cohérence entre analyse, conception
et réalisation.
Préciser les noms et les définitions propres à
l’application (remplir les 2 premières colonnes).
Rangement par ordre alphabétique.
Justifier toute absence de terme.
Éventuellement, constitué de deux parties :
Retirer les synonymes et qualifier les homonymes.
1. dictionnaire des notions,
Valider le dictionnaire avec le « client ».
2. dictionnaire des actions.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 135
Méthodologie pour l’analyse et la validation
A3 : Identifier et définir les classes d’interface
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 136
Méthodologie pour l’analyse et la validation
A4 : Structurer le modèle
Point de départ : cas d’utilisation et dictionnaire.
Définir les associations entre classes.
Identifier les classes (et les opérations associées) qui
satisfont les besoins opérationnels des utilisateurs...
; ces classes sont les classes d’interface (ou boundary
classes).
Définir les généralisations entre classes.
Indiquer les classes « abstraites ».
Définir l’organisation en packages.
Poursuivre dans cette voie en considérant
individuellement chaque classe C identifiée :
◦ C peut-elle réaliser ses services de manière autonome ?
Sinon de quoi a-t-elle besoin ? Quelle autre classe
pourrait satisfaire ce besoin ?
◦ quelles opérations supplémentaires la classe C
peut-elle fournir pour constituer une entité cohérente ?
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 137
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 138
Méthodologie pour l’analyse et la validation
Méthodologie pour l’analyse et la validation
A5 : exemple
A5 : Construire les premiers scénarios
:C1
Point de départ :
:C2Control
:Usager
besoinOp1a()
1. les cas d’utilisation ;
service1a()
2. les classes d’interface identifiées en A3.
creerBidule()
create()
:C3
Définir les scénarios sous forme de diagrammes de
séquences (et/ou de collaboration).
Remarque : lors de l’analyse, les scénarios sont
pertinents à la fois pour :
besoinOp1b()
service1b()
saisirDonnées()
◦ préciser le cahier des charges et les use cases
; scénarios utilisables aussi pour la validation ;
data
remplirBidule(data)
◦ détailler les appels de méthodes entre les classes
; scénarios utilisables aussi pour les phases suivantes
(conception, réalisation et tests unitaires).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, remplir(data)
139
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie pour l’analyse et la validation
140
Méthodologie pour l’analyse et la validation
A6 : Vérifier la cohérence de l’analyse préliminaire
A7 : Spécifier en détail le modèle
Vérifier la cohérence entre :
Compléter la spécification de chaque classe :
1. le contenu du dictionnaire ;
◦ attributs et opérations ;
2. les cas d’utilisation ;
◦ pour chaque opération : liste des paramètres et type de
retour ;
3. les scénarios ;
◦ pour chaque attribut et paramètre : son type ;
4. les éléments modélisés jusqu’ici dans les différents
diagrammes de classe.
◦ pour chaque association : orientation, cardinalité(s) et
rôle(s) ;
Il s’agit notamment de vérifier la cohérence entre la vision
externe (les cas d’utilisation) et interne (diagrammes de
classe) du système.
◦ dépendances vers d’autres classes ;
◦ caractère « de classe » des attributs, ops., assocs. ;
◦ ...
Attention : il est fréquent de devoir « boucler » plusieurs
fois sur les étapes A1 à A6 avant de parvenir à une analyse
préliminaire satisfaisante.
Spécifier, lorsque c’est nécessaire :
◦ les invariants des classes et des packages ;
◦ les automates d’états des classes ;
◦ les pré-/post-conditions des opérations ;
◦ les diagrammes d’activités des opérations.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 141
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 142
Méthodologie pour l’analyse et la validation
A7 : Spécifier en détail le modèle (suite)
Méthodologie pour l’analyse et la validation
A8 : Vérifier la qualité de l’analyse détaillée
Appliquer les règles d’emploi du modèle des classes
(suppression des cycles, etc.).
Vérifier :
◦ la correction,
◦ la completude,
Ajouter les précisions documentaires utiles à la clarté de
la modélisation.
◦ et la consistance de la modélisation
(sinon retour en A1 ou A7).
... Par contre, il est inutile en phase d’analyse de spécifier :
; penser à utiliser l’outil si il permet la recherche
automatique de défauts dans la modélisation.
les visibilités ;
les accesseurs (pour les attributs et les associations) ;
Compléter le dictionnaire en précisant les formes de
modélisation UML des termes et les noms informatiques
utilisés (colonnes no 3 et no 4) :
les constructeurs (sauf si ils sont non-triviaux).
Nom
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 143
Méthodologie pour l’analyse et la validation
Qualité de l’analyse détaillée : reviewing
Traduction
Nom
UML
informatique
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 144
Méthodologie pour l’analyse et la validation
Précisions sur l’analyse détaillée
Liste (non-exhaustive) de questions à se poser :
Les objectifs sont assez opposés à ceux de l’analyse
fonctionnelle :
tous les termes du dictionnaire sont-ils bien définis et
compréhensibles par l’ensemble des intervenants ?
◦ utilisation d’un langage davantage informatique
(cas d’utilisation et scénarios mais aussi diagrammes
de classe, diagrammes d’états, etc.) ;
Pour chaque classe : est-elle nécessitée directement ou
indirectement par un cas d’utilisation ? Si oui, dans quel
cas d’utilisation des instances de cette classe sont-elles
crées, modifiées, détruites ?
◦ obtention d’une vue à la fois externe et interne du
système à réaliser ;
Pour chaque attribut : quel est son type ? quand est-il
initialisé ? modifié ?
◦ niveau de détail dans la compréhension des besoins qui
va bien au delà de ce qui intéresse généralement
l’utilisateur (c-à-d. l’aspect contractuel de l’analyse
fonctionnelle).
Pour chaque association : quand est-elle traversée ? sa
multiplicité et son orientation sont-ils justifiés ?
Y a t-il des entités portant le même nom, et si oui
pourquoi (dénotent-elles bien des notions identiques) ?
Ne doit pas comporter de redondances, d’incohérences
ou d’imprécisions
; en effet, il s’agit de bien mesurer la complexité
interne de la chose à réaliser et de délimiter l’espace des
décisions à prendre lors de la phase suivante
(conception).
Toutes les entités sont-elles bien décrites avec un même
niveau de détail ?
les cas d’erreurs sont-ils tous décrits et traités ?
(idem pour phases d’initialisation et d’arrêt du système)
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Définition
145
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 146
Méthodologie pour l’analyse et la validation
Préparation de la validation
Méthodologie pour l’analyse et la validation
Résumé : pertinence des différents éléments d’UML
Définir une stratégie en vue de la validation :
Phase
◦ par type d’acteurs ;
An.
Co.
Ré.
In.
Va.
•••
•
•
•
••
Package
••
•••
•••
•••
••
Classe
•••
•••
•••
•••
•••
Modèle fonctionnel :
Acteur et use case
◦ par cas d’utilisation ;
Modèle des classes :
◦ ou par packages.
Compléter et finaliser les scénarios de validation
(et, le cas échéant, les jeux de tests correspondant).
Planifier la phase de validation en termes de temps et de
moyens nécessaires.
Attribut
•••
•••
•••
•
•
Opération
•••
•••
•••
•••
•••
Association
•••
•••
•••
••
•
•••
•••
••
Visibilité
Invariant
••
•
•
••
••
Pré-/Post-condition
••
••
•
••
••
Diagramme d’états
••
••
•
••
••
Scénario
•••
••
••
•••
Diagramme d’activités
•
•
Modèle dynamique :
• parfois utile
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 147
•• très utile
•
•
••• indispensable
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie pour l’analyse et la validation
148
UML : modèle d’implantation
Document d’analyse : plan type
1. Présentation générale
Situation et objectifs, documents de référence, etc.
UML : modèle d’implantation
2. Spécification préliminaire
Dictionnaire.
Représentation globale de l’application.
1. Composant.
Description résumée.
2. Diagramme de composants.
3. Définition des utilisateurs
3. Noeud et liaison.
Cas d’utilisation (et acteurs), exemples (scénarios).
4. Diagramme de déploiement.
4. Spécification détaillée
5. Directives.
Définition du modèle des classes (par package) :
- package p1 :
classes C1 , C2 , ... Cn
chacune accompagnée le cas échéant de ses :
invariants, diagramme d’état, ...
6. Hypergénéricité.
- package p2 :
...
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 149
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 150
UML : modèle d’implantation
Composant
UML : modèle d’implantation
Diagramme de composants
Élément physique du système
(codes source ou exécutable, fichier de données, ...)
Définition des composants logiciels en terme de
composition et de dépendances.
Stéréotypes prédéfinis :
<<executable>>
ServeurJeuEnRéseau
◦ « exécutable » ;
◦ « library » ;
◦ « file » ;
◦ « document » ;
◦ « table » ;
<<executable>>
ClientJoueur
◦ « EntityBean » et « SessionBean »
(support pour les EJB en cours de standardisation).
IHM
Liens possibles entre composants : dépendance et
composition.
Comme une classe, un composant peut « réaliser » une
(ou plusieurs) interface(s).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, NoyauClient
151
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle d’implantation
Noeud
152
UML : modèle d’implantation
Diagramme de déploiement (1)
Définition des noeuds en tant@qu’unités physiques
d’exécution ;
Ressource matérielle utilisée lors de l’exécution
; exemples : PC, serveur Web, Imprimante, ...
(pas de stéréotypes prédéfinis).
Définition des liaisons en tant que liens de
communication.
Distinction classe vs instance
; exemple : PC vs monPC : PC
ServeurUnix
Les noeuds peuvent accueillir des composants
(ou plus précisément des instances de composants).
serveur
1
Données encodés selon
protocole Lambda
Les noeuds sont reliés par des liaisons
; exemples : Ethernet, Internet, ...
; possibilité de spécifier le débit.
client
*
Client
Mac
PC
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 153
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 154
UML : modèle d’implantation
Directives (ou « tagged values »)
Diagramme de déploiement (2)
Mécanisme général permettant d’annoter le modèle en vue
(principalement) de son implantation.
Définition de la répartition des composants sur les
différents noeuds.
Tout élément du modèle peut être annoté : package,
classe, opération, paramètre, association, etc.
serveurDuJeu:ServeurUnix
Sous Modelio : directives interprétées par des règles
d’hypergénericité.
:Jeu:ServeurJeuEnRéseau
serveur
UML : modèle d’implantation
serveur
serveur
Exemples de directives pré-définies pour les opérations :
client
◦ virtual et inline (C++ seulement), JavaNative, ...
client
unAutrePC:PC
Exemples de directives pré-définies pour les attributs :
unMac:Mac
◦ JavaShort, JavaLong, JavaGenerateAccessor, ...
:Jeu:ClientJoueur
:Jeu:ClientJoueur
◦ *, & : génération d’un pointeur vs référence (C++)
◦ short, long, const, create, fullaccess, array, ... (C++)
client
Exemples de directives pré-définies pour associations :
unPC:PC
◦ JavaGenerateAccessor, ordered, ... (Java)
:Jeu:ClientJoueur
◦ access fullaccess, ordered, ... (C++)
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 155
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, UML : modèle d’implantation
156
Méthodologie de la conception à l’intégration
Hypergénéricité
L’hypergénéricité est un mécanisme de Modelio à base de
règles (langage J) permettant :
de rendre paramétrable la génération de code (et de
documentation) ;
Méthodologie de la conception à
l’intégration
d’automatiser au maximum la phase de conception
technique et de codage.
Principe :
1. Conception préliminaire et intégration.
on utilise les directives prédéfinies sous Modelio pour
annoter les éléments de modélisation lors de la phase de
conception ;
2. Conception détaillée et tests unitaires.
3. Réalisation : d’UML à C++ / Java.
si besoin, on peut définir de nouvelles directives et
modifier le jeu de règles pilotant la génération de code ;
4. Document de conception.
l’idée est de spécifier des principes à un niveau global,
quitte à les invalider localement ;
le code généré tient alors compte des directives choisies.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 157
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 158
Méthodologie de la conception à l’intégration
Méthodologie de la conception à l’intégration
C1 : identifier les objectifs de conception
Conception préliminaire (ou « system design »)
Expliciter et ordonner les objectifs de conception parmi :
Huit étapes (pas forcément séquentielles) :
◦ réduction des coûts de développement et/ou
d’installation et/ou de fonctionnement ;
C1. Identifier les objectifs de conception.
C2. Décomposer le système en sous-systèmes.
◦ réduction des délais de livraison du prototype et/ou du
système complet ;
C3. Ré-utiliser (frameworks et bibliothèques de classes).
◦ maximiser les performances : temps de réponse,
nombre de transactions, besoin en mémoire, etc. ;
C4. Définir le déploiement des composants sur les noeuds.
◦ maximiser la fiabilité : robustesse, disponibilité,
sécurité, etc.
C5. Décider le mode de stockage des données.
C6. Décider une politique de contrôle d’accès.
◦ maximiser l’extensibilité, la portabilité, l’ergonomie,
etc.
C7. Décider la nature du flux de contrôle global.
C8. Identifier les conditions aux limites.
Attention : ces objectifs sont souvent incompatibles :
; temps de réponse vs besoin en mémoire.
; rapidité vs taille de l’exécutable.
; rapidité de réalisation vs autres critères.
... avant passage à la conception détaillée (ou « object
design »).
On pourra s’appuyer sur les besoins non-fonctionnels
identifiés au début de l’analyse.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 159
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
C2 : décomposer le système en sous-systèmes
160
Méthodologie de la conception à l’intégration
C3 : ré-utiliser (frameworks et bibliothèques de classes)
Il s’agit :
S’appuyer sur la décomposition en packages issue de
l’analyse.
1. d’identifier les classes qu’on pourrait éviter de
réaliser « from scratch » ;
Principes :
2. pour ces classes, d’évaluer la pertinence d’une
réalisation « from scratch » selon des critères à définir
parmi :
◦ regrouper par fonctionnalité ;
◦ minimiser le nombre de dépendances entre
sous-systèmes ;
◦ fiabilité, performance, portabilité, ...
◦ tenir compte de l’architecture du système
(monolithique, distribuée, ... voir C4) ;
◦ minimisation des risques, des coûts et/ou délais.
◦ tenir compte des objectifs de conception, notamment
en termes de performances.
Remarque : utiliser un framework peut conduire à des
choix imposés (en termes de flux de contrôle notamment,
voir C7).
Utiliser les diagrammes de composants pour présenter la
décomposition en sous-systèmes.
Bien comprendre les différences entre :
◦ bibliothèques de classes ;
◦ frameworks ;
◦ patterns.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 161
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 162
Méthodologie de la conception à l’intégration
A propos de « design patterns »
Méthodologie de la conception à l’intégration
C4 : définir le déploiement des composants
Synonymes : « patron » ou « schéma de conception ».
Valider un choix d’architecture :
◦ nombre, nature et caractéristiques des noeuds ;
Origine : ouvrages de l’architecte Christopher Alexander
(The Timeless Way of Building, A Pattern Language)
◦ nature et caractéristiques des liaisons ;
◦ le cas échéant, OS, SGBD, etc.
Objectifs :
Définir le déploiement des composants sur les noeuds :
◦ identifier/nommer/diffuser les meilleures pratiques ;
◦ traiter les problèmes induits par le déploiement :
transferts des données, synchronisation, sécurité, etc. ;
◦ accélérer la communication et les prises de décisions
durant les phases d’analyse et (surtout) de conception.
◦ se souvenir que le logiciel survit généralement au
matériel =⇒ minimiser l’impact d’un portage sur une
autre architecture.
Comporte systématiquement :
– titre, diagramme, propos, description, exemple(s),
– et si besoin : contre-indications, patterns connexes, etc.
Utiliser les diagrammes de déploiement pour présenter
l’architecture (noeuds et liaisons) et le déploiement des
composants sur les noeuds.
Exemples de patterns : composite, abstract factory,
adapter, MVC, etc.
Cf. exemples plus loin dans le cours... et Bibliographie.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 163
Méthodologie de la conception à l’intégration
C5 : décider le mode de stockage des données
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
C6 : décider une politique de contrôle d’accès
Il s’agit de maı̂triser la gestion des données stockées en
mémoire permanente (sur disque) :
Il s’agit de gérer les différences d’accès (éventuelles)
entre les différents acteurs :
◦ données à stocker entre 2 exécutions du programme ;
◦ données trop volumineuses pour la mémoire vive ;
◦ accès plus ou moins étendu aux fonctionnalités du
système ;
◦ données à partager avec d’autres programmes ;
◦ accès aux données créées par l’utilisateur lui-même ;
◦ données « sensibles » qu’il faut être sûr de préserver
même en cas de crash.
◦ accès aux données créées par les autres utilisateurs ;
◦ accès aux données internes au système ;
◦ accès aux données « confidentielles » ou «
stratégiques ».
Identifier les données à stocker (objets « persistants »).
Décider mode de stockage parmi : simple fichier, BDD
relationnelle, BDD objet.
Identifier les données et fonctionnalités accessibles à
chaque acteur.
Critères :
Mettre en place les mécanismes pour gérer les différents
niveaux d’accès au système (fonctionnalités et données).
◦ taille et nature des données à stocker ;
◦ complexité des requêtes ;
Mettre en place les mécanismes pour authentifier les
utilisateurs.
◦ performance souhaitée (temps d’accès et mémoire).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 164
165
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 166
Méthodologie de la conception à l’intégration
C8 : identifier les conditions aux limites
C7 : décider la nature du flux de contrôle global
Il s’agit de préciser :
Il s’agit, pour chaque composant qui s’exécute sur un
processus propre, de choisir parmi :
◦ les phases de démarrage et d’arrêt du système ;
◦ le cas échéant, l’interruption du système ;
◦ le mode procédural : le programme enchaı̂ne les
actions selon un ordre strictement déterminé en
s’interrompant seulement lorsqu’il attend des données
de l’utilisateur ou d’un autre programme...
; adapté aux systèmes à l’IHM en mode texte ;
; typique des langages procéduraux.
◦ le cas échéant, les modes de fonctionnement «
dégradés » (panne de disque dur, de courant, de
réseau, ... ou simple maintenance).
Les aspects à prendre en compte incluent :
◦ vitesse de démarrage ;
◦ le mode réactif : une boucle globale traite les
événements selon leur arrivée et les transmet aux
objet(s) concerné(s)...
; adapté aux systèmes à l’IHM relativement simple.
◦ intégrité des données en toutes circonstances ;
◦ bloquages d’accès sélectifs (maintenance) ;
◦ gêne occasionnée aux autres systèmes lorsque le
logiciel est arrêté, interrompu, en cours de démarrage,
... ;
◦ les threads : le programme se compose de processus «
légers » qui s’exécutent en // et réagissent à des
événements différents...
; adapté au systèmes complexes ;
; élégant, intuitif, mais délicat à mettre au point.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
◦ information des différents acteurs lorsque le système
n’est pas dans un état de fonctionnement normal.
167
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
Conception préliminaire : résumé
168
Méthodologie de la conception à l’intégration
Conception préliminaire : bilan
La conception préliminaire consiste en :
A la fin de cette étape :
1. un certains nombre de choix stratégiques globaux :
toutes les décisions globales (stratégiques) ont été prises
et documentées ;
stockage des données et contrôle des droits d’accès ;
tous les packages sont identifiés et chaque classe
appartient à un package et un seul ;
frameworks et classes pré-existantes sélectionnées ;
nature du flux de contrôle ;
il sera donc possible de paralléliser la suite du
développement en confiant chaque package à une
équipe ;
organisation du système en sous-systèmes ;
choix de l’architecture en terme de noeuds et liaisons.
2. un certains nombre d’ajouts et de modifications dans les
modèles issus de l’analyse :
il est possible, et souhaitable, de préparer sans attendre
l’intégration...
ajouts des diagrammes de composants et de
déploiement ;
modifications des autres diagrammes pour prendre en
compte les choix ci-dessus ainsi que les conditions
aux limites ;
précisions documentaires relatant les choix de
conception et les raisons de ces choix (traçabilité).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 169
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 170
Méthodologie de la conception à l’intégration
Intégration : ordonnancement des travaux
Méthodologie de la conception à l’intégration
Conception détaillée
(ou « object design » ou « class design »)
Se baser sur les dépendances entre packages :
Quatre étapes (pas forcément séquentielles) :
P2
P1
C9. Compléter la spécification.
C10. Frameworks et bibliothèques de classes.
P4
P3
P5
C11. Restructurer.
C12. Optimiser.
P6
Test P6
... avant passage à la réalisation.
Test P5
Assemblage P4-P6
Objectif : rapprocher, par étapes successives, la
modélisation issue de l’analyse préliminaire de sa
concrétisation informatique à venir.
Test P4-P6
Assemblage P3-P6
Test P3-P6
Assemblage P4-P5-P2
Test P2-P4-P5
Assemblage P1-P3-P4
Test P1-P3-P4
t
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 171
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
C9 : compléter la spécification
172
Méthodologie de la conception à l’intégration
C10 : Frameworks et classes ré-utilisés
Il s’agit de terminer la description de tous les éléments à
implanter :
Il s’agit de :
◦ paramétrer les frameworks et les classes ré-utilisées ;
ré-examen des classes, notamment les classes techniques
ajoutées lors de la conception ;
◦ modifier la modélisation pour tenir compte des
frameworks et bibliothèques de classes utilisées.
finaliser les APIs (interfaces de programmation)
; travailler au niveau des signatures en vérifiant la
cohérence (ordre des paramètres, nommage, ...) ;
Aussi, il est prudent :
◦ d’anticiper l’évolution des frameworks et classes
ré-utilisées ;
expliciter les pré-/post-conditions de chaque méthode ;
◦ de prévoir leur remplacement éventuel par d’autres
plus performants (ou moins coûteux).
préciser les exceptions ;
préciser les visibilités ;
; On tachera donc de découpler au maximum ces
classes des autres classes du système.
ajouter les directives d’implantation ;
éventuellement, décrire le corps de chaque méthode en
utilisant les méthodes d’accès et de manipulation des
relations et des attributs (voir plus loin).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 173
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 174
Méthodologie de la conception à l’intégration
Méthodologie de la conception à l’intégration
Pattern « Adapter »
Exercice : le pattern « Singleton »
<<description>>
Target
Comment faire en sorte qu’une classe ne puisse être
instanciée qu’une fois au maximum ?
Client
InterfaceFournisseur
+m1()
+m2()
+m3()
ClasseExistante
ImplantationFournisseur
+me1()
+me2()
+me3()
+me4()
+me5()
+m1()
+m2()
+m3()
<<description>>
Adapter (ou
Wrapper)
<<description>>
Adaptee
<<comment>>
Dans cet exemple, Client n’a besoin que des méthodes me1(),
me2() et me3() de ClasseExistante.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 175
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
176
Méthodologie de la conception à l’intégration
C11 : Restructurer
Pattern « AbstractFactory »
Il s’agit, pour chaque diagramme de classes, de traiter les
cas suivants :
Client
AbstractFactory
suppression des généralisations multiples si le langage
cible ne les permet pas ;
createlabel()
createButton()
transformation des associations n-aires en associations
binaires ;
PcFactory
remplacement des classes d’association par des classes
ordinaires ;
createLabel()
createButton()
... le tout en maintenant dans la mesure du possible la
lisibilité des diagrammes.
AbstractLabel
En fonction des objectifs, il peut s’agir aussi de :
MacFactory
createLabel()
createButton()
AbstractButton
préparer la réutilisation de certaines classes ;
augmenter la portabilité du système
(vis-à-vis des classes techniques d’IHM par exemple).
PcLabel
PcButton
MacLabel
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 177
MacButton
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 178
Méthodologie de la conception à l’intégration
Pattern « AbstractFactory » (utilisation)
Méthodologie de la conception à l’intégration
C12 : Optimiser
AbstractFactory fac = newPcFactory();
Les techniques suivantes devront être utilisées à bon
escient :
// La suite du code est portable (ne
// dépend pas de la plate-forme utilisée)
ajout de raccourcis dans les chemins entre classes
(pour l’accès aux opérations les plus fréquemment
invoquées) ;
AbstractButton button=fac.createButton();
AbstractButton button2=fac.createButton();
AbstractLabel lab=fac.createLabel();
accélération des accès au niveau des associations de
cardinalité élevée ou variable (via ordonnancement des
instances ou liaison directe vers certaines instances) ;
...
déplacement d’attributs vers la classe qui les utilise
directement ;
suppression des classes « inutiles » (via rapatriement des
données/méthodes dans la classe utilisatrice) ;
ajout de dispositifs pour mémoriser les résultats des
opérations coûteuses en temps (« cache »), pour «
bufferiser » certains accès coûteux, etc.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 179
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
Conception détaillée : résumé
180
Méthodologie de la conception à l’intégration
Conception détaillée : bilan
La conception détaillée consiste en :
A la fin de cette étape :
un certains nombre de choix techniques délicats :
toutes les décisions de détail ont été prises et
documentées ;
◦ paramétrage et encapsulation des
composants/classes/frameworks ré-utilisés ;
chaque entité est complètement spécifiée ;
◦ nature des optimisations à effectuer.
il est donc temps de passer à la réalisation de chaque
package ;
un certains nombre d’ajouts et modifications dans les
modèles issus de la conception préliminaire :
il est possible, et souhaitable, de préparer les tests
unitaires...
◦ restructurations des différents diagrammes de classes
pour, notamment, prendre en compte les choix
techniques ci-dessus ;
◦ spécification finale des APIs, contraintes,
pré-/post-conditions, exceptions, ...
◦ visibilités ;
◦ ajouts de précisions documentaires, notamment :
descriptions techniques des méthodes, ...
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 181
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 182
Méthodologie de la conception à l’intégration
Réalisation : d’UML à C++
UML
;
C++
classe
;
class
attribut publique
;
attribut protégé avec méthodes
publiques d’accès
attribut protégé
;
attribut privé
;
attribut protégé avec méthodes
d’accès protégés
idem mais tout « privé »
opération
;
fonction membre
généralisation
;
héritage (public par défaut)
association
;
collection (liste, tableau, ...)
avec méthodes d’accès
package
;
namespace
;
assert(condition)
Méthodologie de la conception à l’intégration
Réalisation : accès aux associations depuis C++
Pour chaque association, 4 méthodes sont automatiquement
ajoutées à la classe utilisatrice (cela dépend toutefois de la
configuration du projet). Soit, par exemple, une classe C1
utilisant une classe C2 avec comme rôle r, on a les 4
méthodes suivantes définies dans C1 :
•
•
•
•
int card_r()
C2* get_r(int i=0)
void append_r(const C2*)
void erase_r(const C2*)
Autres possibilités :
– gérer les associations à la main en annotant l’association
par la directive (ou «tagged value») own ;
– cas particuliers : composition, classe d’association,
association « de classe ».
; Cf. la doc Modelio pour plus de détails sur la traduction
en C++ des concepts UML.
invariants, pré- et
post-conditions
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 183
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
Réalisation : génération de code C++
UML
;
Java
C5
classe
;
classe publique
C4
attribut publique
;
attribut protégé avec méthodes
publiques d’accès
attribut protégé
;
attribut privé
;
attribut protégé avec méthodes
d’accès protégés
idem mais tout « privé »
opération
;
fonction membre
généralisation
;
héritage
association
;
attribut de type ArrayList +
méthodes d’accès
package
;
paquetage
;
if (!condition)
C2
C1.hxx
C3
#include "P1.hxx"
#include "C2.hxx"
#include "C3.hxx"
...
C1.cxx
}
utilisation conceptuelle
#include "C1.hxx"
#include "C4.hxx"
#include "C5.hxx"
Méthodologie de la conception à l’intégration
Réalisation : d’UML à Java
package P1
C1
}
utilisation contextuelle
ou opérationnelle
invariants
pré- et post-
...
conditions
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 184
185
throw new RuntimeException
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 186
Méthodologie de la conception à l’intégration
Méthodologie de la conception à l’intégration
Réalisation : accès aux associations depuis Java
Réalisation : génération de code Java
Pour chaque association, 6 méthodes sont automatiquement
ajoutées à la classe utilisatrice (cela dépend toutefois de la
configuration du projet). Soit, par exemple, une classe C1
utilisant une classe C2 avec comme rôle R, on a les 6
méthodes suivantes définies dans C1 :
•
•
•
•
•
•
package P1
P2::C5
C2
P2::C4
int cardR()
C2 getR(int)
void setR(int,C2)
void appendR(C2)
void eraseR(int)
void eraseR(C2)
*
+R
C1
C3
C1.java
package P1;
Cas particuliers : composition, classe d’association,
association « de classe ».
import P2.*;
public class C1 extends C2 {
protected ArrayList<C3> R = new ArrayList<C3>();
; Cf. la doc Modelio pour plus de détails sur la traduction
en Java des concepts UML.
...
};
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 187
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Méthodologie de la conception à l’intégration
188
Tests
Document de conception : plan type
1. Présentation générale
Situation et objectifs, documents de référence, etc.
Tests
2. Architecture
Contraintes d’implantation, architecture technique,
principes d’implantation.
1. Définitions.
3. Conception générale
2. Tests de fiabilité.
Définition complète du modèle, package par
package :
- package P1 :
classes C1 , C2 , ... Cn
chacune accompagnée le cas échéant de ses :
invariants, pré-/post-conditions,
diagrammes d’états, ...
3. Tests fonctionnels.
4. Tests non-fonctionnels.
5. Profiling et optimisation.
6. Tests de portabilité.
7. Quand s’arrêter de tester ?.
- package P2 :
...
4. Traçabilité
5. Plan d’intégration
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 189
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 190
Tests
Tests
Définitions
Tests de fiabilité
Analyse dynamique du code lors de l’exécution :
Il faut comprendre « les tests » comme la recherche
active et systématique de différences entre le
fonctionnement supposé du programme et son
fonctionnement effectif (en termes de fonctionnalités, de
fiabilité et de performances).
détection d’incohérences dans les classes entités, de
non-respect du mode d’emploi des méthodes, ...
; Test systématique des pré-/post-conditions et invariants.
Nota-Bene : il vaut mieux prévenir que guérir.
On appelle cas de test (ou test case), un ensemble
composé des éléments ci-dessous
détection de problèmes mémoire (surtout utile pour
langages sans garbage collector comme C ou C++) ;
1. nom du cas de test ;
détection des parties de code jamais parcourues à
l’exécution lors des tests
⇒ code suspect : inutile et/ou jamais testé !
2. input (données et/ou commandes) ;
3. oracle (résultat attendu) ;
; Utilisation d’outils tels que Rational PurifyPlus (IBM).
... et destiné à mettre en évidence une faute dans une
partie du programme.
Relecture systématique du code (cf. méthodologie XP).
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 191
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Tests
Tests
Tests fonctionnels
Tests non-fonctionnels
Impossible de tout tester (surtout dans le cas d’une IHM
graphique), par contre on peut :
Vérifier les performances du logiciel :
◦ temps de calcul ;
Tester un maximum de points
⇒ prévoir du temps pour les tests ;
◦ besoin mémoire à l’exécution ;
◦ en cas d’IHM graphique : réactivité de l’IHM, fluidité
des animations, ...
Faire tester par un maximum de personnes différentes
(informaticiens et non-informaticiens) ;
◦ etc.
Accumuler les cas de tests
; batterie de centaines (voire milliers) de cas de tests ;
Cas particulier des « tests de charge » :
◦ de plus en plus nécessaires (Web, e-commerce, ...) ;
Automatiser l’application et l’analyse des cas de tests
⇒ utiliser des outils adaptés (y compris des « robots »
pour tester les IHMs).
◦ nécessite un outil ad hoc pour simuler des milliers
(voire des millions) de requêtes pendant un temps
défini ;
Batterie de tests à ré-appliquer systématiquement sur
chaque nouvelle version du code
; tests de non-régression.
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 192
◦ résultats souvent imprévisibles avant le test
⇒ tester sur un prototype le plus tôt possible.
193
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 194
Tests
Tests
Profiling et optimisation
Tests de portabilité
Si besoin (en cas de performances insuffisantes) . . .
Compilation et tests (fonctionnels et performance) de
chaque exécutable sur les différentes architectures visées
(matériels × OSs × autres logiciels).
Etude dynamique du code à l’exécution : mise en
évidence des parties du code à optimiser en priorité (où
passe-t-on du temps à l’exécution ?)
Si nécessaire, tester avec des périphériques d’E/S
différents :
; utilisation d’outils tels que prof (Unix) ou Rational
PurifyPlus (IBM).
◦ écran basse vs haute résolution ;
◦ écran couleur vs monochrome ;
◦ claviers de type différents ;
◦ ...
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 195
196
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Tests
Bibliographie
Exercice : quand s’arrêter de tester ?
Les tests permettent de déceler des erreurs, jamais de
garantir qu’il ne reste plus d’erreurs dans le code...
; Comment évaluer le nombre N d’erreurs non encore
décelées dans le programme ?
Bibliographie
; Est-il possible d’avoir une idée a priori de la fiabilité du
logiciel produit ?
1. Ouvrages de référence
2. Quelques autres ouvrages sur l’Objet, UML, les
patterns, etc
3. Quelques URLs
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 197
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 198
Bibliographie
Quelques ouvrages sur l’Objet, UML, les patterns, etc.
Ouvrages de référence
... sur le langage de modélisation UML :
Bibliographie
[VF : Eyrolles]
... pour approfondir UML (et les patterns) :
– Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified
Modeling Language User Guide. Addison-Wesley, 2005, 500p.
– Bernd Bruegge, Allen H. Dutoit. Object-Oriented Software
Engineering : Using Uml, Patterns and Java (2nd edition).
Prentice-Hall, 2003, 800p.
– James Rumbaugh, Ivar Jacobson, Grady Booch. UML 2.0 Guide de
référence. Campus Press, 2004, 774p.
– Jos Warmer, Anneke Kleppe. The Object Constraint Language :
– Michael R Blaha, James Rumbaugh. Modélisation et conception
Precise Modeling with UML (2nd ed.). Addison-Wesley, 2003, 232p.
orientées objet avec UML 2 Pearson Education, 2005, 585p.
... sur les méthodologies « Unified process » :
...pour approfondir les « patterns » :
– Ivar Jacobson, Grady Booch, James Rumbaugh. The Unified
Software Development Process. Addison-Wesley, 1999,
463p.
[VF : Eyrolles]
– Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
Design Patterns. Addison-Wesley, 1995, 395p.
[VF : Eyrolles]
– Jim Arlow, Ila Neustadt. UML 2 and the Unified Process (2nd ed.).
patterns tête la première O’Reilly, 2005, 639p.
– Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates. Design
Addison-Wesley, 2005, 592p.
... pour approfondir gestion de projets & génie logiciel :
...pour découvrir les méthodologies « légères » :
– Kent Beck. eXtreme Programming. Campus Press, 2002, 230p.
– Shari L, Pfleeger. Software Engineering, Theory and Practice (2nd
Edition). Prentice-Hall, 2001, 659p.
– Alistair Cockburn. Crystal Clear - A Human-Powered Methodology
for Small Teams. Addison-Wesley, 2004, 312p.
– Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli. Fundamentals of
Software Engineering. Prentice-Hall, 2003, 604p.
– Henrik Kniberg. Scrum et XP depuis les Tranchées. C4Media Inc,
2007, 150p. Disponible gratuitement en-ligne
(www.infoq.com/minibooks/scrum-xp-from-the-trenches)
199
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, Bibliographie
Quelques URLs
http://www.omg.org
; Site de l’OMG
; Documentation sur UML (normalisé par l’OMG)
http://www.modeliosoft.com
; Site sur l’outil Modelio (voir aussi www.softeam.fr)
http://www.rational.com
; Site de la division d’IBM qui commercialise les outils Rational, le
RUP, ...
; UML Resource Center
http://www.extremeprogramming.org/
http://www.xprogramming.com/
; Sites dédiés à l’Extreme Programming (XP)
http://www.agilemodeling.com/
; Site de référence pour l’Agile Modeling (AM)
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 201
c CCSI, Mines ParisTech (imprimé le 15 septembre 2011)
Analyse, conception et programmation par objets, 200
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising