Virtualité Réelle thierry.leydier@gmail · Tour d ’horizon rapide des diagrammes UML ......
Transcript of Virtualité Réelle thierry.leydier@gmail · Tour d ’horizon rapide des diagrammes UML ......
UML
Virtualité Ré[email protected]
Historique des approches : les ancêtres
Pour parer aux difficultés du logiciel, les méthodes en Génie Logiciel sont nombreuses depuis les années 80
Des méthodes précises mais trop limitées, très orientées production de logiciel ou programmation
Parmi les méthodes les plus connues :
1985 : Booch Object Oriented Design (OOD)
1986 : Seidewitz - Stark (NASA) General Object-Oriented design (GOOD)
1987 : CISI - CRI - MATRA (ESA) Hierarchical Object-Oriented Design (HOOD)
1988 : Kerth Multiple-View Object-Oriented Design Methodology (MOOD)
1988 : Jacobsen ObjectOry
1989 : Wasserman Object-Oriented Structured Design (OOSD)
Des méthodes ou des formalismes de plus en plus complets
Durant les années 90, on voit apparaître des méthodes plus complètes, et plus orientées analyse des problèmes
3 méthodes émergent: OMT : J Rumbaugh
OMT 1 (91), OMT 2 (93) formalisme graphique vue fonctionnelle
BOOCH approche méthodologique approfondie 91, 93
OOSE : Jacobson Vue des cas de fonctionnement
En 1996, les 3 méthodes précédentes sont unifiées dans une seule : UML UML devient ainsi un outil de modélisation complet et universel 1997 : Normalisation d’UML (1.0) et Création d’un groupe de prescripteurs (
OMG) Aujourd’hui UML Version 2
Les traits d ’UML
Les traits d ’UML
UML est un langage pas une simple notation
un vrai langage de modélisation
la définition d ’UML est formelle et normalisée
UML n ’est pas une méthode en soi Méthode implicite adossée issue des technologies objets
Conception ascendante
UML ne définit pas un processus Processus implicites issus des technologies objets
cycle en spirale, cycles itératifs
Complément à UML : Unified process défini par l ’OMG
UML est extensible
UML = ensemble
Plus un agglomérat qu’un ensemble homogène
La création d ’UML a pour objectif de rassembler un ensemble de modèle sans vrai volonté de trier ou filtrer
Homogénéité de notation, de documentation
Hétérogénéité
plusieurs notations possibles pour décrire les mêmes concepts
plusieurs diagrammes possibles pour la même idée
Par exemple, la modélisation d ’une séquence d ’actions peut être effectuée de différentes façons
Difficulté :
Comment utiliser cet agglomérat ?
UML = Offre industrielle
UML est difficilement contournable en matière de modélisation
UML est utilisé ou prescrit par les grands industriels
De nombreux outils existent
plus ou moins complets
plus ou moins intégrés à des environnement de développement de logiciels
cibles standard C++ et JAVA
différents objectifs
outils à destination de programmeurs
outils à destination d ’analystes
ouverture à d ’autres métiers
Les éléments généraux d ’UML
Les constituants
UML est composé :
d ’éléments de base du modèle
les atomes de la modélisation
un objet, un lien, etc.
de diagrammes qui permettent de combiner ces éléments
les diagrammes portent une cohésion
par exemple, un diagramme exprime un scénario (cohésion temporelle)
de vues qui permettent de rassembler les diagrammes
les vues correspondent à des étapes de la démarche de modélisation
deux types de vue
macroscopique : vue globale
microscopique : point de vue spécifique
Les constituants d ’UML
Vue fonctionelle
Injecteur
Objet
Cylindre
Objet
Température
Objet
Démarrage Moteur
Diagramme de séquence
Vue du motoriste
Cycle Antipollution
Diagramme de séquence
Vue du constructeur auto
Vue conceptuelle Vue technique
ModèleNiveau Vue
Macroscopique
Niveau Vue Microscopique
Diagramme
Élément de base du modèle
Les éléments de base du modèle
Servent à la modélisation de concepts dans les diagrammes.
Les éléments les plus classiques :
les items une classe : quelque chose de générique. Par exemple un cylindre
un objet : un élément physique. Par exemple le premier cylindre
un acteur : un objet externe au système. Par exemple, la pédale d ’accélérateur est un objet externe au système d ’injection
les liens entre items liens de composition
un cylindre fait partie d ’une ligne d ’échappement
Les associations
Associés à un stéréotype : la façon de représenter chaque élément graphiquement dans le modèle
Associés à des informations textuelles
Extensibles : on peut rajouter de nouveaux éléments, ou personnaliser les éléments standard
Les diagrammes
Définis à priori
Neuf diagrammes résultant de l’unification des méthodes
Certains diagrammes sont « redondants » ou corrélés
Liste exhaustive :
diagrammes des cas d ’utilisation
diagrammes de séquence
diagrammes de collaboration
diagramme d ’objets
diagrammes de classe
diagrammes d ’activité
diagrammes état transitions
diagrammes de composants
diagrammes de déploiement
Tour d ’horizon rapide des diagrammes UML
Contexte d’utilisation d’UML
On peut utiliser UML pour trois grandes catégories de travaux
Analyser un problème
Modéliser un problème
Synthèse du problème sous forme d’objets
Modéliser une solution
Description « logicielle » de la solution
Analyser un problème
Modéliser un problème
Modéliser une solution
Tour d ’horizon rapide des diagrammes UML
Diagrammes permettant d ’analyser un problème
diagramme des cas
diagramme de séquence et de collaboration
Diagrammes permettant de modéliser le problème diagramme d ’objets
Diagrammes permettant de modéliser une solution
au niveau conceptuel
diagramme de classes diagramme d activité et états-transition
au niveau informatique
diagramme des composants
diagramme de déploiement
Diagrammes des cas d ’utilisation
Diagramme de base de l ’analyse d’un problème
Décrit un ensemble de cas d ’utilisations
acteurs
cas
scénarios
Point de vue utilisateur
système = boite noire
Diagrammes des cas d ’utilisation
<<communique>>
<<Include>><< Extend>>
Freine
(Cas utilisé)Verglas détecté
(Cas complémentaire)
Conduit Automobile
(Cas)Conducteur
(Acteur)
ABS
(Acteur interne)
Diagrammes de séquence
Décrit une séquence d ’action ou un enchaînement d événements
Complément en général de la description d ’un cas d ’utilisation
Orientation temporelle
organisation dans le temps des actions, des messages
Parallèle au diagramme de collaboration
Diagrammes de séquence
Conducteur
ABSGestionnaire
de trajectoire
Appuie Pédale Frein
[t°>0] Consigne
[t° <=0] Alarme
Information
Les objets
Le temps
Calcul
Disques
t0
t1
t1-t0<100 ms
Diagrammes de collaboration
Décrit la collaboration entre objets
Complément en général de la description d ’un cas d ’utilisation
Orientation communicationnelle
messages entre objets ou classes
Parallèle au diagramme de séquence
Diagrammes de collaboration
Conducteur ABS
1 : Appuie pédale
2 : Consigne
5 : Information
4 : CalculObjet C
: Objet ADisque 1
2 : Alarme
Diagrammes de classe
Diagramme de base des vues logiques
Décrit :
des classes
des attributs,
des opérations
des associations entre classes
d ’autres relations
héritage
composition
Diagramme d ’objets
Proche du diagramme de classe (s ’applique aux objets)
Diagramme complémentaire aux diagrammes de classes
Décrit :
des objets
des attributs,
des opérations
des associations entre classes
d ’autres relations
héritage
composition
Diagramme de classes et d ’objets
Conduire ()
nom
age : entier
Conducteur
rouler()Véhicule
Camion Voiture
Roue Système de
Frein
possède►
*0..1
4 à 8 41 à 2
Diagrammes état transitions
Base de la description de la dynamique
Décrit un ensemble d ’états
Décrit les transitions entre états
Très riche en formalisation
Complément au diagramme de classe ou d ’objet
Parallèle au diagramme d ’activité
Diagrammes d ’activité
Base de la description de la dynamique
Décrit un enchaînement d ’opérations
Pour une classe ou un objet donné
Scénario précis
Complément au diagramme de classe ou d ’objet
Parallèle au diagramme états transitions
Diagrammes état transitions
Appuie Pédale Frein
État 1
Entry : Diagnostic Freins
État 2
Do : Commande Disques
État 3
Diag Terminé [Pas de panne]
Pédale relâchée
Sous machine
Diagrammes de composants
Base de la description de la réalisation
Décrit :
les composants
les relations de dépendance
les relation de réalisation
classes
objets
associations
Diagrammes de déploiement
Base de la description du déploiement
Décrit :
les cibles
les tâches
Syntaxe UML standard limitée
nécessite généralement des compléments
Les vues
Les vues
Concept général en UML
La façon de voir le système
Un moyen, plus qu’un standard du modèle
Deux niveaux
macroscopique correspondent à des étapes du cycle de production
les vues macroscopiques servent généralement de base à l ’organisation des modes opératoires des outils UML
microscopique correspondent à des points de vue différents
vues orthogonales d ’une même analyse, d ’une même solution
Vue fonctionelle
Vue du motoriste Vue du constructeur auto
Vue conceptuelle Vue technique
Modèle
Macroscopique : l’organisation 4+1
A un niveau macroscopique, on peut représenter un système sous 5 points de vue :
vue des cas d'utilisation,
vue statique ou logique,
vue dynamique (processus),
vue des composants,
vue de déploiement (matériel).
Cette vue s’appelle 4 + 1 dans le jargon UML
Variante 3+1 (sans la vue dynamique)
Les vues 4+1 organisent l ’interface utilisateur des outils
Dans UML Rose par exemple, 4 niveaux de modélisation (4 vues)
A ne pas confondre avec les phases de modélisation
Macroscopique 4+1: les cas au centre de la modélisation
Vue
statiqueVue
dynamique
Vue descomposants Vue du
déploiement
Vue
des
Cas
d ’Util.
Vue macroscopique : autre exemple basé sur les étapes du développement
On utilise les phases de définition du produit
analyse système
analyse sous-système
une vue par sous-système
conception système
une vue par sous-système
intégration système
vue centrée sur la conception des interfaces entre les sous-systèmes
A chaque vue vont correspondre des niveaux de détail différents
Liens entre les vues macroscopiques et les diagrammes
Pas d ’association standard entre vues et diagrammes Pas de préconisation donc quant aux diagrammes à utiliser pour analyser ou
modéliser un problème ou une solution Dans le cours, on recommandera cependant certains usages
Quand utiliser quoi, et pourquoi
Les outils qui proposent des organisations standard peuvent éventuellement imposer des associations
Exemples d’associations possibles pour le 4+1: vue des cas d'utilisation:
diagrammes des cas d ’utilisation, de séquence, de collaboration, d ’objets
vue statique ou logique: diagrammes de classes, d ’objets, de séquence, de collaboration, d ’activités, d ’états
transitions
vue dynamique (processus): diagrammes de séquence, de collaboration, d ’activités, d ’états transitions, de déploiement
(tâches)
vue des composants : diagrammes de composants
vue de déploiement (matériel): diagrammes de composants, de déploiement
Microscopique = Les points de vues
A un niveau microscopique, il est souvent possible d'utiliser plusieurs points de vues :
plusieurs éléments de modélisation,
plusieurs syntaxes pour représenter les mêmes concepts ou des concepts complémentaires.
On utilise généralement un point de vue principal pour conduire une analyse ou une conception :
c'est le point de vue des utilisateurs en analyse ou le point des concepteurs en conception.
On peut compléter une modélisation en utilisant d'autres points de vue :
par exemple, utiliser le point de vue de l'exploitant d’un logiciel lors de l'analyse ou utiliser le point de vue des mainteneurs en phase de conception.
Les vues et la documentation UML
Le concept de vue peut conduire la documentation UML à une organisation complexe ni synoptique
ni hiérarchique
Conséquences information répartie
avec duplication possible
Cette souplesse peut conduire à des difficultés dans un contexte industriel
dans un contexte critique
Pour éviter tout problème, l’utilisation d’UML débute généralement par la mise en place d’une convention d’utilisation, dans laquelle on définit : Les vues macroscopiques ;
Les points de vue possibles
Les diagrammes associés a priori aux vues et aux étapes du développement
Autres éléments d ’UML
Les paquetages
Unité d ’organisation des constituants d ’UML Récursif Peut contenir
des éléments de modélisation de base des diagrammes des paquetages
Exemples : un paquetage de classes : catégorie un paquetage de composants : librairie un paquetage de cibles : cluster un paquetage de diagrammes de cas d ’utilisation : une
fonction un paquetage d ’acteurs : un ensemble d ’utilisateurs
Les stéréotypes
Unité de représentation associée à des concepts
critères de classification
Des stéréotypes standard
classe
classe paramétrée
acteur
travailleur d ’interface
etc.
Des extensions possibles
Principales extensions conseillées
acteurs
cibles (vue de déploiement)
Champ d ’application UML
UML Outil de Génie Logiciel
Par nature et par origine, UML est naturellementorientée vers le logiciel
De nombreux outils logiciels existent
De nombreux liens vers les langages de programmation
JAVA, C++
Homéomorphisme technologique
les langages de programmation actuels contiennent les éléments conceptuels contenus dans UML
Transition immédiate entre conception et réalisation
UML Outil d ’analyse Généraliste
UML est utilisé pour l ’analyse des problèmes
techniques
ou d ’autre nature
En dehors du Génie Logiciel
UML est utilisé comme « chapeau de l ’analyse »
On complète par des analyses plus ciblées effectuées par des méthodes complémentaires
analyse fonctionnelle : complément fonctionnel
AMDEC : complément sûreté et sécurité
analyse de la valeur : complément marketing
UML Outil de conception de système complexe
UML est utilisé pour la conception des systèmes complexes. Par exemple, des systèmes
à plusieurs composantes technologiques
Ou réalisés sur plusieurs sites
Ou réalisés dans le cadre de montage industriels complexes
Un exemple : conception système d ’un satellite
UML est utilisé pour l ’analyse système et la définition des sous-systèmes sous-systèmes fonctionnels et structurels
plate-forme, charge utile
définition et modélisation de l ’interface entre sous-système
prototypage, préparation de l ’intégration
On complète par la conception de chaque sous-système Avec des moyens et techniques propres aux technologies utilisées par les sous
systèmes Mécanique, thermique, électronique, etc.
Concepts Objets de Base
Approche objet :
L ’approche objet est le résultat de l ’unification entre les différentes approches de modélisation des logiciels (plus généralement de modélisation des problèmes)
Approches fonctionnelles et données
Approches non procédurales
L ’unification est présente dans l ’essence de l ’objet
L’approche objet a évolué au fil du temps pour suivre les courants technologiques
L’approche objet a permis une révolution dans le domaine de la production des logiciels
Aujourd’hui la production d’un logiciel est une activité de type analyse, intégration et personnalisation, plus qu’une activité de création et de développement
L’objet
L ’objet peut être expliqué de façon théorique ou pratique
Théorique
Le principe est dérivé de la notion de Type Abstrait Algébrique(TAA)
L’objet prend donc racine dans une théorie mathématique précise et complète
Pratique
Le terme « objet » est un terme volontairement simple emprunté au monde réel pour « vulgariser » la notion de type abstrait
L ’objet est la formalisation basique d ’un problème ou d’une solution
L ’objet est un moyen unifié de décrire simplement les données et les traitements en utilisant le même formalisme
Type Abstrait : Définitions
Un type abstrait décrit un type de données en masquant la manière dont il est réalisé
pour décrire un type concret on dit de quoi il est fait ; exemples : entier codé sur 32 bits
tableau = ensemble contigu d'éléments de même taille
pour décrire un type abstrait on dit quelles opérations il sait faire
Spécification algébrique d'un type abstrait
opérations supportées par le type + ensemble d'axiomes portant sur ces opérations
ces axiomes doivent former un tout complet et cohérent
de cette manière on axiomatise le domaine du problème
Un type abstrait algébrique permet donc de dire à la fois quels services rend un type et comment ces services s'articulent entre eux : le type est entièrement décrit par ses opérations
Description précise d'un TAA
Un Type abstrait est décrit par des signatures et des axiomes.
Signature = sortes + opérations sortes = symbolise formellement le domaine de définition
opérations = moyen d ’interagir avec l ’objet deux types d ’opération
les générateurs
les observateurs
Axiomes = système d'équations en logique du premier ordre, mettant en jeu variables et symboles fonctionnels les axiomes expriment des invariants
Exemple : le TAA Booléen
sortesBool
opérationsvrai : Bool (générateur)faux : Bool (générateur)_ : Bool Bool__ : Bool Bool Bool__ : Bool Bool Bool
axiomesa, b, c : Bool(b1) vrai = faux(b2) a = a(b3) a vrai = a(b4) a faux = faux(b5) a (b c) = (a b) c(b6) a b = b a(b7) a b = ( a b)
En Pratique : Qu’est ce qu’un bon objet ?
Un objet qui va de soi
Habituel, Naturel
L’objet appartient au vocabulaire du métier Un capteur, Une bielle, etc.
L’objet est le plus souvent homogène à une chose Concrète : Un constituant d’un moteur
Abstraite : Un cycle de combustion
L’objet peut être également homogène à des actions Un processus de fabrication
Un objet que l ’on peut appréhender sans le décrire en détail
effort d ’abstraction
Un objet que l ’on peut décrire sans parler a priori de son contenu
de ses opérations
de ses données
Exemple d ’objet - haut niveau
En phase d’analyse d’un problème, on effectue la description des objets à haut niveau
Nom de l’objet
Responsabilités de l’objet ce que l’objet sait faire, les services qu’il rend
Exemple
Objet Nombre Complexe
Description des responsabilités de l ’objet additionner deux complexes
calculer la norme d ’un complexe
donner la partie réelle, la partie imaginaire d ’un complexe
donner l’angle et le rayon d ’un complexe (coordonnées polaires)
Exemple d ’objet - bas niveau
En phase de modélisation d’une solution, on effectue la description des objets à bas niveau Nom de l’objet
Description des données contenues dans l’objet
Descriptions des opérations fournies
Exemple : Objet Nombre Complexe
les données x : la partie réelle
y : la partie imaginaire
les fonctions de l ’objet complexe norme : la norme du complexe (renvoie un réel positif)
addition : l ’addition de deux complexes (renvoie un complexe)
Une représentation possible pour un objet
Complexe
Addition ()
Norme ()
x
y
Le nom de l’objet
Les services proposés par l’objet
La partie cachée de
l’objet
Les notions objets élémentaires
Les notions Objets élémentaires
La notion d’abstraction
La notion d’encapsulation
Les notions de classe et d’instance
Attributs et Opérations
Héritage
Les relations
La notion d ’abstraction
Un objet est issu de l ’analyse du monde réel (le monde du problème)
On obtient les objets du problème par un effort d ’abstractionsur le dit problème
La qualité des objets décrits ne se limite pas ainsi à la fidélité de reproduction des objets du monde réel, mais également à la capacité à s ’extraire de ce monde réel par esprit d ’abstraction
Objets
du monde réel
Objets
du modèle
Domaine, métier
Domaine
« le domaine applicatif »
Un ensemble de connaissances ou d'activités caractérisé par des concepts et une terminologie propres aux praticiens de ce domaine. Une application (un projet) restreint un domaine aux besoins d'un projet.
associé à un domaine de compétence
Métier
le savoir faire d ’un domaine
décrit par les experts
Application et Projet
Application
l ’objectif du projet
une partie du domaine
décrit par les utilisateurs
Projet
le processus de fabrication de l ’application
Peut nécessiter une analyse du domaine (=> extension du cadre applicatif)
Objets
du domaine
Objets
du projet
Abstraction : illustration
Complexe peut être un objet du domaine du problème (e.g. problème = création d’un bibliothèque de calcul) on utilise le complexe tel quel
on devra alors décrire l ’ensemble des responsabilités du complexe (au sens mathématique du terme) On décrit par exemple tous les opérateurs du complexe
Complexe peut être un objet du monde de la solution on utilise un complexe pour des calculs électriques
on limite la portée de la description des responsabilité
on oriente le complexe Le complexe est un élément de solution : on ne décrit que
opérateurs utiles à la solution
Abstraction : illustration
Autre exemple :
Pour un mathématicien, un complexe est un élément du corps des complexes : il doit ainsi proposer des opérations comme trouver le complexe inverse
Pour un électronicien, un complexe est un outil d’expression algébrique des lois électriques : une restriction des opérations est suffisante
Les notions Objets élémentaires
La notion d’abstraction
La notion d’encapsulation
Les notions de classe et d’instance
Attributs et Opérations
Héritage
Encapsulation
La notion d’encapsulation permet de faire la distinction lors de la modélisation entre :
ce qui est visible à l ’extérieur de l ’objet (public),
ce qui est caché à l ’intérieur de l ’objet (privé).
L’interface de l ’objet est composé de la partie visible
L ’interface peut contenir des données ou des fonctions
La notion d ’encapsulation est un moyen de séparer entre implémentation et interface (pour fournir par exemple plusieurs implémentations)
La séparation est forte et stricte
Encapsulation : exemple
Sur l ’objet Complexe, on décide de cacher x et y
principe de masquage de l ’information
On rajoute deux fonctions d ’accès à x et y
Get_x
Get_y
On rajoute également deux fonctions d ’accès au rayon et à l ’angle
Cela permet de modifier ultérieurement l ’implémentation du nombre complexe
utiliser des cordonnées polaires
Illustration de l ’encapsulation
Complexe
Addition ()
Norme ()
Get_x ()
Get_y ()
Get_ro ()
Get_theta ()x
yX et Y sont masqués
L’interface publique d’un
complexe
Les notions Objets élémentaires
La notion d’abstraction
La notion d’encapsulation
Les notions de classe et d’instance
Attributs et Opérations
Héritage
Classe et Instance
Une classe décrit un ensemble potentiellement infini d'objets individuels : tous les objets qui ont les mêmes attributs, les mêmes opérations, relations, contraintes et le même comportement.
Un objet est une instance d'une classe : les données de l'objet correspondent aux attributs de la classe auxquels on a affecté des valeurs. Le comportement et les opérations s'appliquant sur un objet sont ceux décrits pour la classe que l'objet instancie.
Une classe instanciée en un seul objet est un singleton
Classe et Instance
Complexe
Addition ()
Norme ()
Get_x ()
Get_y ()
Get_ro ()
Get_theta ()X
y
1
X = 1
Y = 0
i
X = 0
Y = 1
Affectation des données
membres
Objets et Instances
On utilise souvent le terme « objet » dans un sens générique (instance ou classe)
Les propriétés d’un objet
Approche objet
Lorsque l’on veut lever l’ambiguïté on utilisera explicitement les termes instances et classes
Création et destruction d ’instances
Les instances naissent, vivent et meurent
La création d ’instance peut être statique ou dynamique
On associe généralement des opérations déclenchées lors de la création et la destruction
Une instance persistance est une instance dont la durée de vie dépasse celle de l'application et donc qui doit être stocké sur un support permanent (dans un fichier, une base de données...).
Exemples de création le complexe 1 (x=1,y=0)
le complexe j ( x=0,y=1)
Les notions Objets élémentaires
La notion d’abstraction
La notion d’encapsulation
Les notions de classe et d’instance
Attributs et Opérations
Héritage
Attributs, Opérations et Méthodes
Un attribut d'une classe est une des données de la classe.
Une opération est un service offert par une classe. Une opération peut comporter des paramètres.
Une méthode est la réalisation d’une opération (L’algorithme ou la procédure qui donne le résultat d’une opération)
Opérations particulières
Les constructeurs
création d ’instance
Les copies
copie une instance dans une autre instance
clone une instance
Les conversions (d ’une classe c1 vers une classe c2)
créer une instance temporaire de c2 initialisée avec les données d ’une instance de la classe c1
Les destructeurs
destruction d ’instances
généralement unique par simplicité
Opérations particulières (suite)
Les sélecteurs
Accès aux données (généralement cachées)
Support au masquage d’information (encapsulation)
Exemple : Get_x ()
Les modifieurs
Modification des données (généralement publiques)
Centralisation de la modification
Support au masquage d’information (encapsulation)
Exemple : Set_x ()
Les notions Objets élémentaires
La notion d’abstraction
La notion d’encapsulation
Les notions de classe et d’instance
Attributs et Opérations
Héritage
Les relations
Héritage
L’héritage est une technique de classification pour les classes : une classe A hérite d ’une classe B si A « est une sorte » de B.
A est la classe fille ; B la classe mère ( la classe ancêtre ou la super-classe)
La classe ancêtre factorise des propriétés communes aux classes héritières
La relation d’héritage exprime ainsi une idée de spécialisation / généralisation entre des classes
la classe fille spécialise la classe mère
la classe mère généralise la classe fille
Héritage : exemple
Figure
Polygone
Dessin ()
Couleur
ListeSommets
Héritage : exemple discutable
Polygone
Dessin ()
Polygone régulier
?
ListeSommets
Il est difficile d ’exprimer ce qui
caractérise un polygone régulier
par rapport à un polynome en
termes de :
fonctions
données
L ’héritage dépend donc du contexte
et des techniques utilisées
?
Héritage : meilleure approche
Polygone
Dessin ()
Polygone régulier
Dessin ()
ListeSommets Nb de sommetsCentreSommet Origine
Figure
Divers types d ’héritage
Héritage multiple : une classe fille hérite de plusieurs classes ancêtres
Héritage répété : Une classe dérivée hérite « plusieurs fois » d’une même classe de base, via plusieurs chemins dans un arbre d’héritage (D hérite de B1 et B2 qui héritent de A).
Héritage multiple
Polygone
Dessin ()
ListeSommets
Figure Surface
Surcharge et redéfinition
On parle de surcharge d ’opération, ou de redéfinition de méthode lorsque qu’une sous-classe donne une nouvelle implémentation à une méthode définie dans sa super classe, en respectant scrupuleusement sa signature (nom de la méthode, type de retour, liste de paramètres et d’exceptions).
On distingue la surcharge au niveau opération, de la redéfinition (ou ré implémentation) au niveau méthode.
Il est conseillé de garder la même sémantique pour chaque opération surchargée
Exemple de surcharge
Figure Encadrée
Dessin ()
Figure Titrée
Dessin ()
Donne une
implémentation
de base à
la fonction de dessin
(dessin d ’un cadre)
x,ycx,cy
Exemple de redéfinition
Figure Encadrée
Dessin ()
Cercle
Dessin ()
x,ycx,cy
Renonce à
l ’ implémentation
de base
(dessin d ’un cadre)
Classe racine
Une classe qui n’a pas de mère dans la hiérarchie d’héritage et qui a des filles est appelée racine (racine de l’arbre d’héritage).
On définit généralement plusieurs racines dans un projet
base de la décomposition du projet en classes
Certaines racines sont fournies par l ’environnement de programmation :
classe Object dans JAVA = racine de tout objet
Object
ThrowableString
Exception
RuntimeException
Error
Integer
Les notions Objets élémentaires
La notion d’abstraction
La notion d’encapsulation
Les notions de classe et d’instance
Attributs et Opérations
Héritage
Les relations
Association
Une relation sémantique entre deux ou plusieurs classes, ou catégories, qui implique des connexions au niveau instance.
Une association est généralement binaire Dans une association, les extrémités ont un poids
équivalent.
Moteur Boite1:n 1:n
boite moteur
Agrégation
Une forme spéciale d’association qui spécifie une relation « tout - partie » entre l’agrégat (tout) et une partie.
Exemple :
Voiture Personne1 n
passagers
Composition
Une forme d’agrégation qui exprime une forte propriété entre le tout et les parties, ainsi qu’une subordination entre l’existence des parties et du tout.
Exemple :
Moteur Cylindre1 n
cylindres moteur
UML
Analyse d ’un problème avec UML
Analyse avec UML
L ’analyse d ’un problème en UML repose sur une démarche de description sur la base de scénarios
scénarios d’utilisation définis sous forme de cas
élaborés en prenant le point de vue des utilisateurs
L’analyse conduit généralement à la fabrication d ’une vue macroscopique :
la vue des cas d ’utilisation
Analyse sans UML
L ’approche fonctionnelle est celle utilisée le plus couramment dans l ’analyse des problèmes, hors UML
Rappels :
L ’analyse fonctionnelle consiste à décomposer le problème en sous-problèmes, jusqu’à aboutir à des problèmes élémentaires que l ’on sait résoudre
L ’analyse fonctionnelle est une approche
itérative
hiérarchique
descendante
on part d ’un gros problème et on le divise
Comparaison de l ’approche « objet » avec l ’approche fonctionnelle
Approche fonctionnelle point de vue « fonctions »
possibilité de confusions entre le quoi et le comment le quoi : le problème
le comment : une solution
difficultés pour arrêter la décomposition fonctionnelle
Approche par cas d ’utilisation (UML) on revient toujours au point de vue « utilisateur »
tout cas est relié à un acteur (qui est externe au système)
évite la description du « comment »
parfois insuffisant pour une spécification industrielle besoin de décrire également des mécanismes
Démarche d’analyse d’un problème avec UML
On suit avec UML la démarche suivante :
Identification de la périphérie du problème
les acteurs
Identification des événements
Les événements dont déclenchés par les acteurs (stimuli)
Table des évènements
Détail des cas d’utilisation
Les cas sont les actions conséquences des stimulis
On décrit dans le détail chaque scénario
Synthèse des cas
On donne une vue d’ensemble sur les scénarios
Vue des cas d ’utilisation
Identification des acteurs
La description des acteurs permet d'identifier précisément la " frontière " du système à analyser en définissant les personnes, matériels ou autres systèmes qui interagissent avec le système courant.
L ’acteur est un utilisateur dans un rôle particulier (ex. opérateur, client, administrateur,…) ou, plus généralement, toute entité externe à l'application et qui interagit avec elle (sous-système ou matériel de l'environnement…).
Les acteurs sont en dehors du système à modéliser.
Les acteurs sont représentés pas des stéréotypes
On peut avoir recours dans certains cas à l ’utilisation d ’acteurs « internes »
complémentaires
utiles pour simplifier la description
Exemple
Modélisation du fonctionnement d’un ascenseur
Acteurs :
Utilisateur de l’ascenseur (passager)
Technicien (chargé de la maintenance de l’ascenseur)
Agent de sécurité (prévenu en cas d’appel d’urgence)
Identification des Evenements
L'identification des événements est un travail complémentaire à la description des acteurs.
Ce travail va permettre une bonne préparation de la description des cas d'utilisation.
Un événement est attaché au monde réel : il représente sous forme abstraite un incident ou un signal qui marque un changement d'état. Un événement est ainsi toujours associé à un récepteur: ce récepteur est généralement un acteur ou un objet du monde réel.
Table des événements
On remplit une table d’événement avec : La signification de l'événement : c'est la description de ce qui
se passe dans le monde réel lorsque l'événement se produit
L’acteur principal (déclencheur du cas)
Les acteurs auxiliaires
Le cas déclenché (homogène à un scénario)
des paramètres éventuels
ParamètresCasAutres acteurs
Acteur principal
Évènement
Exemple
Ascenseur :
On / OffArrêterUtilisateurStop
AlerterAgent de sécurité
UtilisateurAlerte
Haut / BasAppelerUtilisateurAppel
nChoisir Étage
UtilisateurChoix Étage
Numéro de testTesterTechnicienAction clé
ParamètresCasAutres acteurs
Acteur principal
Évènement
Détail des cas d’utilisation
La description textuelle des cas d'utilisation est effectuée à l'aide d'un modèle de cas d'utilisation. Vue de détail
L’essentiel du travail
La description graphique des cas d'utilisationconsiste à regrouper sur un diagramme les objets qui participent à un scénario et à montrer leurs interactions sans entrer dans le détail des messages échangés. Elle est formalisée à l'aide de diagrammes de collaboration
et de séquences
Elle n’est pas systématique : on ne l’effectue que pour quelques scénarios complexes
Synthèse des cas d’utilisation
La description graphique des cas d'utilisation est effectuée avec les diagrammes de cas d'utilisation d'UML.
Vue de synthèse
Synthèse : vue des cas
Appeler<<Appel (Haut, Bas)>>
Utilisateur
Choisir<<Choix (n)>>
Arrêter
<<Stop (On/Off)>>
Alerter
<<Alerte>>
Agent de
sécurité
Technicien
Tester
<<Action Clé (n)>>
Etude de cas
Recherche des acteurs, des événements et des cas d'utilisation
« Fonctionnement d’un calculateur de contrôle moteur»
On joue le rôle de l ’équipementier (= fabriquant du calculateur)
Informations complémentaires
Le calculateur est un équipement électronique connecté à d ’autres
équipements du véhicule comme le Système de Freinage, la
commande de boite à vitesses, la commande d ’accélération, etc.
Il réagit indirectement aux actions du conducteur, et directement aux
stimulis de capteurs d ’état (température, pression, etc.) et de position
moteur (angle vilebrequin et arbre à cames )
Il commande des organes électriques comme les injecteurs, des
vannes, ect.
Le calculateur peut être diagnostiqué et calibré
Modélisation UML de la vue des cas d’utilisation
Analyse d’un problème
La vue des cas d ’utilisation : contenu
Cette vue est composée principalement de trois types de diagrammes UML :
les diagrammes de cas d’utilisation
les diagrammes de séquence
les diagrammes de collaboration.
Cette vue peut également contenir d’autres diagrammes UML comme des diagrammes de classes qui illustrent la participation des objets aux cas d’utilisation
Diagrammes des Cas d ’utilisation
Diagrammes de cas d’utilisation
Les diagrammes de cas d'utilisation mettent en jeu des cas d'utilisation et des acteurs.
Un cas d'utilisation représente une séquence d'actions que le système va exécuter lorsqu'il interagit avec un acteur.
Les cas sont représentées dans des « ovales ».
Le diagramme est une vue graphique assez pauvre(vue synthétique des interactions)
Le diagramme doit être complété par un texte plus précis
Exemple de diagramme des cas
<<communique>>
<<Include>>
<<Extend>>
Cas utilisé
Cas complémentaire
Cas décrit
Acteur
Acteur internePoint d ’extension
autre
Scénario
Séquences spécifiques d'actions qui illustrent des comportements
Ils sont déclenchés par des acteurs
Ils manipulent des objets
Un cas est souvent composé de plusieurs scénarios
Le scénario principal
Des scénarios alternatifs
Les messages
Les acteurs interagissent avec ce système par des messages :
les message de type <<communique>>.
On peut décider d'orienter ou de ne pas orienter la relation <<communique>>.
Lorsque la relation est orientée, on fait la distinction entre acteur actif qui déclenche un scénario, et acteur passif qui reçoit simplement un message.
On peut préciser la nature de cette communication en donnant un nom au message
Les relations d ’ extension
La relation <<Etend>> exprime l'idée que l'on peut compléter l'exécution du cas d'utilisation courant par des actions complémentaires (afin de prendre en compte une alternative).
<<communique>>
<<Etend>>
Cas complémentaire
Acteur
Point d ’extension
autre
Les relations d ’inclusion
La relation <<Utilise>> exprime l'idée qu'un cas d'utilisation va utiliser un autre cas d'utilisation pour s'exécuter.
<<communique>>
<<Utilise>>
Cas utilisé
Acteur
Point d ’extension
autre
Le point de vue
Le diagramme de cas d'utilisation est orienté par la vue que l'utilisateur a du système à analyser et des services qu'il en attend
On peut décrire des parties propres au fonctionnement interne du système s'il s'agit de préciser l'interaction entre l'acteur et le système.
Dans ce cas, cette précision n'est pas vue comme une description du " COMMENT " mais comme un complément au " QUOI " qui sera éventuellement remis en cause lors de la recherche d’une solution au problème.
Besoin de préciser le point de vue
Les mécanismes
Il est possible d'utiliser un mécanisme pour structurer le modèle UML
Les mécanismes sont :
soit des acteurs identifiés à la périphérie du système, mais qui en font partie (on parle d'acteurs d'interface)
soit des agents (comme des processus) qui sont responsables du déclenchement de cas d'utilisation
soit un autre sous-système pour le sous-système courant.
les mécanismes servent à la modélisation des cas d'utilisation
on utilise un stéréotype particulier pour le repérer.
Les points d ’extension
Le compartiment optionnel " Point d'extension " permet de préciser des extension complémentaires propre à un cas.
Utilisé pour la description d ’alternatives
Vocabulaire complémentaire
Alternative
Partie d'un cas d'utilisation qui sort du déroulement normal. Une alternative peut être une exception.
Déroulements/ Enchaînement
Normal
L'enchaînement des activités standard d'un cas ou d'un scénario.
Alternatif
Tout enchaînement autre que le déroulement normal.
La représentation Textuelle des cas d ’utilisation
Représentation Textuelle des cas
La vue graphique UML est pauvre concernant les cas d ’utilisation et doit être complétée par un texte
Le texte n ’est pas standard en UML
La rédaction d ’un texte de cas de fonctionnement doit respecter l ’orientation « utilisation » du système
On utilisera pour chaque projet un format standard
fiche de cas
template documentaire (.dot par exemple)
Cette description permettra par la suite l ’analyse du vocabulaire (identification des objets)
Exemple de canevas pour une description textuelle
Cas d’utilisation
Acteurs
Point de vue
Préconditions
Description
détaillée
Déroulement
normal
Postconditions
Exceptions Déroulement
alternatif
Variantes
Cas d’utilisation
Acteurs
Point de vue
Préconditions
Description
détaillée
Déroulement
normal
Postconditions
Exceptions Déroulement
alternatif
Variantes
Les rubriques d ’un UC textuel (1)
L'identification : numéro d'ordre, nom. Cette identification est utilisée en traçabilité.
Les acteurs et mécanismes impliqués. Pour les cas d'utilisation reliés par des relations de type " Include " ou " Extend ", cette rubrique peut être vide.
Le point de vue adopté : est ce le point de vue externe ? le point de vue d'un développeur ?
Les rubriques d ’un UC textuel (2)
Le déclenchement : quel est l'événement (ou les événements) qui déclenche(nt) le cas d'utilisation
Les préconditions : on décrit l'état du système avant le déroulement du cas. Cet état se limite généralement à la description des données qui sont utilisées par le cas d'utilisation.
La description détaillée du cas : Interactions et messages échangées,
actions effectuées
Sous forme de liste d’actions élémentaires
Le plus souvent Ping-Pong (acteur – système)
La description peut faire apparaître des alternatives (variantes ou exceptions)
Les rubriques d ’un UC textuel (3)
Les postconditions : on décrit l'état du système après le déroulement du cas.
On se limite généralement à la description des données qui sont modifiées par le déroulement du cas d'utilisation.
Les exceptions : on décrit le traitement éventuel des exceptions levées.
Une exception est assimilée à un cas d'erreur ou à un fonctionnement dégradé.
Les variantes : on décrit le traitement associé aux variantes détectées.
Une variante correspond à un comportement alternatif au comportement standard, sans être une exception.
Exemple de détail : cas de l’ascenseur
Cas = Appel
Acteur = Utilisateur
Point de vue = Utilisateur
Déclenchement = L’utilisateur appuie sur le bouton d’appel de l’ascenseur
Pré-condition = Ascenseur en état de marche
Détail 1 . Si l’ascenseur est déjà présent à l’étage d’appel => variante A, sinon l’ascenseur
enregistre la demande d’appel si elle n’est pas déjà enregistrée
2. L’ascenseur consulte la file des demandes, et se rend à l’étage correspondant à la demande la plus prioritaire
3. La porte de l’ascenseur s’ouvre
4. Si l’étage d’arrêt de l’ascenseur correspond à la demande de l’utilisateur, le scénario prend fin.
5. L’ascenseur supprime de la file des appels la demande courante et reprend en 2.
Variante A A1 . La porte de l’ascenseur s’ouvre
Post-condition : L’ascenseur est présent à l’étage d’appel, porte ouverte
Règles complémentaires d ’écriture d ’un UC
On n'utilisera pas de forme impersonnelle, ni de forme passivesans préciser qui fait l'action.
Une formulation impersonnelle ou passive cache les acteurs, ce qui nuit à l'identification des responsabilités et des objets.
Les formes impersonnelles sont moins précises
On utilisera un texte court (1 ou 2 pages au format A4 pour le cas d'utilisation complet). Des méthodes de réduction de texte standard peuvent être appliquées : supprimer les adverbes inutiles, supprimer les constructions littéraires, supprimer les paraphrases.
une description courte limite les incohérences
une description courte permet d'éviter les paraphrases
une description courte permet d'éviter le style littéraire
Les scénarios
Notion de scénario
Un scénario est une instance de cas d'utilisation ou un sous ensemble de cas :
dans un scénario, l'alternative est exclue ou très limitée.
La modélisation des scénarios devra être effectuée soit de façon textuelle , soit de façon graphique.
La modélisation textuelle d'un scénario s'effectue en complétant la rubrique " Description textuelle des cas d'utilisation ".
Modélisation graphique des scénarios
Les diagrammes utilisés pour modéliser les scénarios sont les diagrammes de séquence et les diagrammes de collaboration
On peut décomposer un scénario soit :
en interactions entre objets : on suit alors la voie qui conduit à un diagramme de collaboration
en séquences d'activités : on préfère alors le diagramme de séquence
Généralement on choisit un seul diagramme
Dans certains cas, les deux diagrammes pourront être décrits car il seront complémentaires.
Point de vue
La modélisation d'un scénario doit s'effectuer selon un point de vue identifié
Le point de vue choisi doit être décrit : dans le cas d'une modélisation graphique, on devra faire figurer ce point de vue sous forme de note attachée au diagramme.
Ce point de vue oriente le diagramme et illustre ce sur quoi on veut mettre l'accent.
Un diagramme de séquence ou un diagramme de collaboration n'exprime pas tout le scénario mais seulement un point de vue
Cohérence entre diagrammes
Lorsque la cohérence entre un diagramme de collaboration et un diagramme de séquence n'est pas assurée par l'outil, on devra choisir entre les deux:
Les diagrammes de séquence et de collaboration expriment les mêmes idées avec des nuances.
Assurer la cohérence signifie par exemple, que le changement de l'ordonnancement des actions sur un diagramme de séquence doit entraîner une re-numérotation des séquences sur le diagramme de collaboration.
Dans le cas ou l'outil support assure la cohérence, on pourra en revanche multiplier les diagrammes ce qui permet de multiplier les points de vue.
Les diagrammes de séquence
Diagrammes de séquence
Un diagramme de séquence montre les interactions entre les objets en fonction du temps.
Les objets communiquent par messages :
un message va d'un objet vers un autre.
un message peut être éventuellement réflexif.
Une ligne de message horizontale montre une transmission immédiate du message ; une ligne inclinée montre une transmission avec un délai.
Exemple de diagramme
Les objets
Le temps
Acteur
: Objet A : Objet C
Message 1
[x>0] Message
2
[x <=0] Message 3
Message 4
Réflexif
: Objet B
t0
t1
t1-t0<100 ms
Autres possibilités du diagramme (1)
Le déclenchement d'un message peut être conditionné : message 2 n'est effectivement déclenché que si x>0
Acteur
: Objet A : Objet C
Message 1
[x>0] Message
2
[x <=0] Message 3
Message 4
Réflexif
: Objet B
Autres possibilités du diagramme (2)
Chaque objet a une ligne de vie symbolisée par un trait pointillé. L'objet B est créé par le déclenchement du message 2 et détruit lors de l'exécution du scénario : la croix symbolise sa fin de vie.
Acteur
: Objet A : Objet C
Message 1
[x>0] Message
2
[x <=0] Message 3
Message 4
Réflexif
: Objet B
Autres possibilités du diagramme (3)
Les boites blanches représentent les périodes de temps au cours desquelles l'objet est actif : activation des objets
Acteur
: Objet A : Objet C
Message 1
[x>0] Message
2
[x <=0] Message 3
Message 4
Réflexif
: Objet B
Autres possibilités du diagramme (4)
Il est possible d'associer des datescomme t0 et t1 et des contraintes sur les dates comme (t1-t0<100ms)
Le temps
Acteur
: Objet A
Message 1
Message 4
t0
t1
t1-t0<100 ms
Intérêt de ce type de diagramme
On choisira un diagramme de séquence plutôt qu'un diagramme de collaboration lorsque l'on veut mettre en évidence l'organisation des événements dans le temps et l'enchaînement des événements du scénario :
La visualisation du temps et des séquences est immédiate sur un diagramme de séquence
La visualisation des créations et destruction d'instances est immédiate
Structuration : approche par contrôleur
Dans cette approche, le premier objet contrôle tous les suivants
Structuration : approche par délégation
Dans cette approche, chaque objet contrôle l'objet suivant auquel il délègue une partie des traitement
Les diagrammes de collaboration
Diagrammes de collaboration
Le diagramme de collaboration met l'accent sur l'interaction entre les objets
On relie les objets et acteurs
La communication est décrite par des flèches,
On peut indiquer le message échanger
On peut indiquer éventuellement le numéro d'ordre du message dans la séquence des messages
Exemple de diagramme
Acteur
Objet B : Classe B
1 : Message 1
2 : Message 2
3 : Message 3
5 : Message 4
4 : RéflexifObjet C
: Objet AObjet A
Objet BC
Autres possibilités du diagramme (1)
On représente les agrégations par une boîte englobante : sur le schéma, les objets B et C sont rassemblés dans l'agrégation objet BC
Objet B : Classe B
3 : Message 3
4 : RéflexifObjet CObjet BC
Autres possibilités du diagramme (2)
On peut représenter les classes auxquelles appartiennent les objets dans le cas où ces classes ont été définies : l'objet B appartient à la classe B
Objet B : Classe B
3 : Message 3
4 : RéflexifObjet CObjet BC
Autres possibilités du diagramme (3)
On peut présenter la notion d'instance multiple pour un objet : c'est le cas pour l'objet A.
Objet B : Classe B
2 : Message 2
3 : Message 3
4 : RéflexifObjet C
: Objet AObjet A
Objet BC
Autres possibilités du diagramme (4)
On peut préciser la nature des liens entre objets : s'agit- t 'il d'un lien par donnée membre, par paramètre, par donnée globale ?
Objet B : Classe B
2 : Message 2
3 : Message 3
4 : RéflexifObjet C
: Objet AObjet A
Objet BC
Autres possibilités du diagramme (5)
On peut associer d'autres propriétés aux objets comme leur persistance ou leur activité (les objets actifs sont autonomes en terme de comportement et sont représentés avec un contour épais)
3 : Message 3
4 : RéflexifObjet CObjet BC
Autres possibilités du diagramme (6)
On peut définir le mode de transmission de chaque message : simple (le cas général), synchrone, asynchrone, avec time out , etc. La différence entre modes de transmission est marquée par le type de flèche.
Objet B : Classe B
3 : Message 3
4 : RéflexifObjet CObjet BC
Autres possibilités du diagramme (7)
La séquence peut être exprimée de façon assez complète : on peut préciser des conditions de synchronisation, des séquences parallèles, etc.
Acteur
Objet B : Classe B
1 : Message 1
2 : Message 2
3 : Message 3
5 : Message 4
4 : RéflexifObjet C
: Objet AObjet A
Intérêt de ce type de diagramme
On choisira un diagramme de collaboration plutôt qu'un diagramme de séquence lorsque l'on veut mettre en évidence la communication entre les objets plutôt que l'organisation des événements dans le temps
Il y a deux façon d'exprimer la communication dans un diagramme de collaboration :
de façon simple et immédiate : en exprimant les liens entre les acteurs et les objets. Ces liens sont la base de la communication ; ils se traduisent par des messages échangés entre les objets
de façon plus élaborée
Organisation générale d ’une vue des cas d ’utilisation
Structuration
La vue des cas d'utilisation sera structurée à l'aide de paquetages afin d'améliorer sa lisibilité.
On décrira un paquetage minimum par sous-système
On utilisera la décomposition en paquetages pour distribuer le travail de modélisation
On pourra utiliser les paquetages pour multiplier les points de vues
Chaque paquetage ainsi décrit contiendra un ensemble de cas d'utilisation. On appellera ce paquetage un " paquetage de cas ".
Contenu d ’un paquetage de cas
Un paquetage de cas peut contenir :
des acteurs (propres ou attachés au cas)
des cas
description textuelle des cas
des scénarios
complément descriptif aux cas
des diagrammes
de cas d ’utilisation
de séquence
de collaboration
d ’autres paquetages
UML
Modélisation d ’un problème avec UML
Modélisation d ’un problème avec UML
La modélisation d ’un problème avec UML est le résultat définitif de l ’analyse
Cette modélisation consiste à :
identifier les objets du problèmes
représenter ces objets en utilisant des diagrammes appropriés
En particulier le diagramme d ’objets
Cette modélisation s’effectue à partie des résultats de l’analyse du problème
Les diagrammes de cas
Les diagrammes de séquence et de collaboration
Le détail des cas (partie textuelle)
Étapes de la modélisation du problème
La modélisation du problème s’effectue en trois étapes
La recherche des objets initiaux du monde du problème à partir de ceux du monde réel
La consolidation de l’analyse
On arbitre le résultat de l’étape précédente
La formalisation du problème
On crée des diagrammes UML qui permettront de représenter de détailler les objets du problème
Étape 1 : Identification des objets initiaux du problème
L’identification des objets du problème consiste à chercher dans le résultat de l’analyse le objets possibles
Certains objets apparaissent déjà dans des scénarios Diagrammes de séquence ou de collaboration
On va compléter ces objets déjà identifiés par une analyse exhaustive de tous les objets possibles pour notre problème Démarche aveugle
Démarche « par le bas » On identifie des candidats : les objets initiaux
On consolidera ces objets dans une seconde étape
Technique utilisée : l’analyse du vocabulaire
Analyse du vocabulaire
Technique classique pour la recherche des objets initiaux
Principe : faire une analyse grammaticale du résultat de l’analyse (le détail des cas en particulier)
Détermination des objets et des classes potentiels du système
Cette technique est très simple, ne demande pas de formation particulière
Cette technique est très rapide
Cette technique oblige à une mise à plat de l ’ensemble du vocabulaire
L’analyse du vocabulaire est un travail brut et mécanique :
on n’élimine a priori aucun terme de l’analyse
La synthèse d’effectuera dans un premier temps
Analyse du vocabulaire : la démarche
Obtenir ou décrire de façon informelle le vocabulaire du domaine ou de l'application A partir de description textuelles
Identifier les objets et les classes en utilisant les noms, pronoms, etc. Les noms précis (noms propres, singuliers) sont utilisés pour trouver les objets (les instances). Les noms généraux sont utilisés pour trouver les classes.
Repérer les constructions de type "est composé de ", " fait partie de ", etc. pour identifier les agrégations
Repérer les compléments de temps pour déterminer les évènements
Identifier les groupes verbaux peut isoler des services et des responsabilités
Généraliser les instances pour créer de nouvelles classes par repérage des adverbes et des adjectifs
Associer les services à des classes
Grouper tous les résultats dans une table
Analyse du vocabulaire : exemple(extrait d’un cas d’utilisation)
Sur événement Clé-On vers Clé-Off, le calculateurprincipal envoie un message de «Coupure-Alimentation» aux autres calculateurs auxiliaires.
Chaque calculateur auxiliaire envoie un message d’acquittement et effectue la sauvegarde des données.
Les groupes nominaux
Les groupes verbaux
Les évènements
Résultat de l’analyse du vocabulaire
Envoyer message « Coupure alimentation »
calculateurCalculateur principal
Envoyer message « Acquittement »
Sauver les données
calculateurCalculateur auxiliaire
Responsabilités et services
ClasseObjet
Étape 2 : Consolidation de l’analyse
La consolidation s’effectue en deux temps Complément éventuel de la table des objets et
des classes On complète indépendamment des cas en rajoutant des
compléments naturels qui ne sont pas décrits dans les cas mais qui sont logiques par rapport à la cohérence des objets
Synthèse On regroupe des objets
En classes plus génériques
On regroupe des service En service plus standard, moins détaillés, plus génériques
Exemples de compléments
Pour chaque service rendu, on se pose la question de l’intérêt du service réciproque
Sauver les données => Restaurer les données
On rajoute donc restaurer les données à l’objet calculateur auxiliaire
Pour chaque service rendu, on rajoute les services liés au fonctionnement dégradé s’ils ne sont pas décrits dans les cas d’utilisation
Sauver les données => Sauver les données critiques (mode dégradé)
Pour chaque objet passif, on se pose la question du déclencheur des service : on crée si besoin le déclencheur comme nouvel objet
Qui est le déclencheur de l’ « événement Clé-On vers Clé-Off » Création de l’objet « Centrale de condamnation des portes »
Étape 3 : formalisation
La formalisation s’effectue principalement au travers de deux diagrammes Les diagrammes d’objets
Le point central
Les diagramme de classe plus rares dans le cas de la modélisation du problème
On peut éventuellement compléter ces diagrammes par des compléments Diagramme de séquence ou de collaboration
complémentaires à ceux de la vue des cas
L’ensemble de ces diagrammes constitue la vue logique
Structuration de la vue logique
On structure la vue logique en paquetages en respectant les décompositions en sous-systèmes et catégories :
La notion de sous système en UML permet de structurer la vue logique à haut niveau
La notion de paquetage en UML permet de structurer chaque sous-système
Attention : dans UML les paquetages ne sont qu’un simple regroupement logique
Pour améliorer la lisibilité d’un modèle, on doit faire coïncider la structuration de la vue logique (niveau modèle) et la structuration de la décomposition statique (niveau conceptuel).
Exemple de structuration correcte
Capteurs de portières Capteurs de capot
Condamnation des portes
Injecteurs
Commande d'injection
Système
La structuration du modèle logique correspond à la structuration en organes
« Système »
Exemple de structuration confuse
Capteurs de portières
Condamnation des portes
Capteurs de capot Injecteurs
Commande d'injection
Système
La structuration du modèle logique ne correspond pas à la structuration en
organes « Système »
Diagrammes de classes et d’objets
Vue logique
Diagramme de classes et d ’objets
Les diagrammes de classes représentent les classes, leurs propriétés et leurs relations.
Les diagrammes permettre de représenter les relations d'héritage (entre mère et fille), les relations d'agrégation, les associations, les compositions et les liens de dépendance.
Les diagrammes d'objets sont comparables aux diagrammes de classes mais contiennent des instances. Ils sont généralement moins techniques et plus applicatifs
Description d ’une classe
Chaque classe ou objet est représenté par une boite qui contient des « compartiments » :
Le compartiment " nom " est le premier : il décrit le nom de la classe ou de l'objet, auquel on peut joindre des propriétés comme " la classe est elle abstraite ou pas ". On peut également utiliser un stéréotype pour identifier le type de la classe (exemple de la classe Mère).
Les compartiments suivants sont des listes : on peut les utiliser pour décrire des listes d'opérations, d'attributs, de responsabilités, d'exceptions, etc. Les outils apportent des limitations à l'utilisation des listes et proposent généralement des listes standard.
En phase d’analyse du problème, on n’utilise généralement que le compartiment opérations pour décrire les responsabilités des objets
Classe
Attributs
Responsabilités
Classe
Responsabilités
Description textuelle des classes
Les caractéristiques de chaque classe sont décrites sous forme de rubriques informatives.
Certaines informations sont déduites de la modélisation graphique (les relations par exemple). Les autres sont à renseigner par le biais de texte ou de boites de dialogue.
Informations textuelles possibles
le type de la classe : classe simple, métaclasse, classe abstraite
son stéréotype UML,
la cardinalité de son ensemble d'instance (instance unique ou non)
son autonomie de traitement : classe active, passive
Description des responsabilités
En analyse d’un problème, on décrit uniquement les responsabilités des objets :
souvent exprimées comme des verbes , avec ou sans complément
On ne décrit donc généralement pas de paramètres, pas de valeurs de retours, pas d'attributs
On se limite à une liste de services : ces services pourront être traduit en phase de modélisation du problème par des opérations dans le cas ou l'on conserve la même décomposition.
Cette limite permet de ne pas empiéter sur les solutions : on reste à un niveau de modélisation du problème
Types de classes
UML propose des types de classe qui permettent de distinguer Classe de contrôle : homogène à un traitement, ce type de
classe sert à représenter un gestionnaire
Classe entité : homogène à une donnée, ce type de classe est utilisé pour représenter une donnée (généralement structurée et persistante)
Classe interface : La description d'une classe peut se limiter à son interface
Classe utilitaire : elles sont utilisées pour rassembler des opérations de bas niveau afin d'exprimer une notion de bibliothèque de fonction ou pour exprimer une cohésion de coïncidence.
Les objets
Les objets sont les instances associées aux classes
La description des classes n’est pas obligatoire, mais recommandée pour simplifier les diagrammes, sauf pour les singletons
Les instances sont reliées aux classes par des liens d’instanciation
Lors de la description d'un objet sur un diagramme de classe, on peut donner le nom de la classe associée : " objet : classe ".
Objet :Classe
Responsabilités
Héritage
Les relations d'héritage sont représentées par le lien de généralisation.
Entre classes
Elles illustrent la relation « est un » ou « est une sorte de »
Classe Fille 2
Attributs
Opérations
Classe Fille 1
Attributs
Opérations
Mère
Agrégations et Composition
Les agrégationsexpriment en UML un lien « faible » entre container et contenus
Les compositionsexpriment en UML un lien « forte » entre container et contenus
Le tout n’existe pas sans les parties
Salle de cours
Responsabilités
Élèves n
Responsabilités
Promotion
Responsabilités
Élèves n
Responsabilités
Associations
Les associations supportent un nom, un rôle pour chaque extrémité et une cardinalité.
On peut décrire des " qualifier " (les rôles) associés aux associations qui sont des attributs spécifiques qui vont permettre de compléter la description des relations, ou qui vont préparer l'implémentation.
Classe
Attributs
Opérations
Classe reliée
Attributs
Opérations
0..1
1
+ rôle 1
+ rôle 2
Associations : rôles
Les noms de rôles doivent être uniques et distincts des noms des attributs de la classe opposée (i.e. de la classe située à l'autre extrémité de l'association).
Toutes les associations issues d'une même classe doivent avoir, à leur extrémité, des noms de rôle différents et distincts des noms des attributs de la classe opposée.
Pour éviter des conflits de nom (en particulier à la génération de code) :
un rôle correspond implicitement à un attribut de la classe associée.
Associations complexes
Lorsque la relation est complexe ou que de l'information complémentaire doit lui être affectée, on peut attacher une classe à la relation
Classe
Attributs
Opérations
Classe reliée
Attributs
Opérations
0..1
1
+ rôle 1
+ rôle 2
Classe association
Attributs
Opérations
Classe Association
Si un attribut est une caractéristique d'une association entre deux classes, il est plus lisible de le définir comme un attribut de la classe association et non de l'une des classes.
Définir un attribut d'association dans une des classes est une implémentation possible qu'il est prématuré de considérer dans un diagramme d'analyse du problème.
Le diagramme est plus évolutif : en effet, si la cardinalité de l'association est transformée en "plusieurs-plusieurs", il n'est plus possible de conserver l'attribut de l'association dans l'une des classes.
Catégorie
Une catégorie est un ensemble de classes
Une catégorie est une unité de découpage conceptuelle
Elle devrait correspondra à une unité de découpage du modèle
On ne confondra pas :
Catégorie
Agrégation et composition
Modélisation d’une catégorie Catégorie
Exemple à commenter
SeReposer()
Travailler()
Conduire ()
nom
age : entier
Personne
rouler()Véhicule
Vélo Voiture
Roue Moteur
possède►
roues
roue_secours
moteur
roues
*0..1
24
11
Multiplication des points de vue
Multiplication des points de vues
Le multiplication des points de vue contribuent à l'amélioration de la qualité de l'analyse du problème
Chaque point de vue (ou chaque angle de vue) donne lieu à un nouveau diagramme
Les outils de modélisation peuvent assurer la cohérence entre les diagrammes
Jusqu’à une certaine limite
Attention à ne pas tendre vers l’excès de modélisation
Exemple de point de vue : le Diagramme Interface
Il montrera l'ensemble des relations entre les classes de la catégorie courante et les classes externes (n'appartenant pas à cette catégorie).
Il est réservé à l'expression de l'interface d'un paquetage afin de préparer l'intégration de ce paquetage avec les autres parties du système analysé.
On décrira par exemple systématiquement un paquetage d'interface pour chaque sous système, ou par chaque unité d'intégration (développement séparé réalisé en parallèle par une autre équipe par exemple).
Il permet de détailler les relations entre les paquetages
Autre exemple de point de vue : Diagramme de Synthèse
Il concerne les paquetages qui regroupent d'autres paquetages (comme les sous-système)
Il décrit les relations entre les paquetages contenus.
Il est utilisé au sein d'une même unité d'intégration.
On utilisera un seul paquetage de plus haut niveau pour exprimer l'interface entre l'ensemble des paquetages de l'unité d'intégration.
Autres diagramme spécifiques
D’autres diagrammes de classes spécifiques pourront être ajoutés à tout paquetage afin d'exprimer une idée ou d'insister sur un élément de modélisation
un diagramme associé à un scénario précis : on montre les classes qui participent au scénario et leurs liens
un diagramme qui montre une hiérarchie d'héritage
un diagramme qui exprimer une agrégation
un diagramme qui exprimera une relation
Concepts Objets Avancés
Les notions Objets élaborées
Catégories et Paquetages
Attributs et fonctions statiques
État
Liaison dynamique et Polymorphismes
La généricité
La dynamique et le flot de contrôle
Catégorie et Paquetage
La paquetage est un mécanisme général désignant un regroupement d’éléments dans un ensemble
Une catégorie est un paquetage de classes (et de catégories) et moyen de structuration hiérarchique d'un modèle Objet.
L’ensemble des catégories réalisent un recouvrement des classes et des relations entre classes (pas forcément une partition)
Une catégorie peut comprendre à la fois des catégories filles et des classes
On utilise les catégories pour regrouper sémantiquement des classes
Catégorie et Paquetage
Transporter ()
Véhicule
Trottinette Voiture
Roue Moteur
roues
Roue de secours
moteur
roues
2
4
1
1
Paquetage Moyen de Transport
Sous-système
Partie d’un système telle que l’ensemble des sous-systèmes constitue une partition du système.
La nature des sous-systèmes peut être très variée et n’est pas généralement un résultat de l’analyse ou de la conception.
Les notions Objets élaborées
Catégories et Paquetages
Attributs et fonctions statiques
État
Liaison dynamique et Polymorphismes
La généricité
La dynamique et le flot de contrôle
Attribut statique
Une donnée partagée entre tous les objets de la classe
On parle d'attribut statique ou attribut de classe (par opposition à un attribut d’instance)
Tous les objets (les instances) peuvent accéder à un attribut statique
La modification d ’un attribut statique doit être contrôlée
Exemple :
Le nombre d ’instances courantes pour la classe complexe est une donnée statique
Cette donnée est modifiée par les constructeurs et destructeurs
Attribut statique
Complexe
Addition ()
Norme ()
Get_x ()
Get_y ()
Get_ro ()
Get_theta ()X, y
NbInstance
1
X = 1
Y = 0
i
X = 0
Y = 1
La donnée NbInstance n’est pas définie dans
les instances
Opération statique
Une opération de la classe que l’on peut utiliser sans instance
Une opération statique s’applique aux données statiques de la classe
Exemple :
La fonction d’accès au nombre d’instances
Opération statique
Complexe
Addition ()
Norme ()
Get_x ()
Get_y ()
GetNbInstance ()
X, y
NbInstance
1
X = 1
Y = 0
i
X = 0
Y = 1
Les notions Objets élaborées
Catégories et Paquetages
Attributs et fonctions statiques
État
Liaison dynamique et Polymorphismes
La généricité
La dynamique et le flot de contrôle
État interne
L ’état interne d ’une instance caractérise le comportement complet de l ’objet
L ’état est caractérisé lui même par un ensemble d ’attributs non statiques (les attributs d ’état)
La modification des attributs d ’état entraîne la modification de l ’état de l ’objet
Exemples
le complexe est caractérisé par x et y
un attribut NbUse qui compte le nombre d ’accès en lecture à une instance (incrémenté par les opérations d ’accès) n ’est pas un attribut d ’état
État interne : exploitation
La partition des attributs entre attributs d ’états et autres attributs améliore la fiabilité
On différenciera les opérations :
qui modifient l ’état d ’un objet
opérations non constantes
qui ne modifient pas l ’état d ’un objet
opérations constantes
Les notions Objets élaborées
Catégories et Paquetages
Attributs et fonctions statiques
État
Liaison dynamique et Polymorphismes
La généricité
La dynamique et le flot de contrôle
Liaisons statique et dynamique
Liaison statique :
liaison qui s ’effectue lors de l ’édition de classique standard
Liaison dynamique :
Liaison qui ne s’effectue pas lors de l’édition de lien statique, mais lors de l’exécution. L’héritage dynamique demande une liaison dynamique.
Mécanisme nécessitant l ’utilisation de pointeurs, ou d ’autres mécanismes spécifiques
Méthode Virtuelle
Méthode d'une classe, sur laquelle s'applique la liaison dynamique.
Le mécanisme d ’appel à une méthode virtuelle repose sur le principe des pointeurs de fonction
Méthode Virtuelle Pure : méthode virtuelle que l ’on doit forcément redéfinir dans une classe fille.
Une méthode virtuelle pure peut ne pas avoir de définition (uniquement une déclaration)
On ne peut utiliser directement une méthode virtuelle pure.
Exemple de méthode virtuelle
Volume Droit
Surface ()
Volume ()
Prisme Droit Régulier
Surface ()
Hauteur
Dans le cas général, on ne sait pas calculer une surface. La fonction surface est virtuelle, on doit la définir dans toutes les classes filles.
Cylindre
Surface ()
RayonCoté, Nombre
Le volume en revanche peut être calculé de façon
générique pour tout volume droit
Volume=surface()*hauteur
Classe abstraite
Une classe qui possède au moins une méthode virtuelle, soit directement, soit dans la liste des méthodes héritées.
La liaison dynamique s ’applique ainsi à toute classe abstraite
Une technique pour rendre une classe abstraite est souvent de décrire l ’opération de destruction virtuelle
Objets Polymorphes
Possibilité d’utiliser une même référence pour des objets de structures différentes.
Cette possibilité est offerte par les langages de programmation objet et permet une programmation générique
Le polymorphisme s ’appuie sur les classes abstraites et utilise la liaison dynamique
Dans l ’exemple précédent, une référence vers un volume droit est polymorphe
soit un prisme droit
soit un cylindre
Les autres notions d’objet
Catégories et Paquetages
Attributs et fonctions statiques
État
Liaison dynamique et Polymorphismes
La généricité
La dynamique et le flot de contrôle
Concept de Template
Classe paramétrable
Opération ou méthode paramétrable (hors arguments)
Les paramètres
des types, des classes
des opérations
Exemples
une classe de gestion de Pile
paramètre : le type de l ’élément empilé
une classe de gestion de dictionnaire
paramètre : une méthode d ’indexation
Plus généralement, une technique de méta modélisation
Les autres notions d’objet
Catégories et Paquetages
Attributs et fonctions statiques
État
Liaison dynamique et Polymorphismes
La généricité
La dynamique et le flot de contrôle
Objet Persistant
Objet qui continue à exister après un traitement ou un fil qui l’a créé. Un objet persistant s’oppose à un objet transitoire.
La persistance est souvent synonyme de sauvegarde dans une mémoire de masse.
La sauvegarde suppose généralement une transformation de l’objet de sa forme dynamique vers une forme homogène à un flot de caractères facilement stockable.
Cette transformation s’appelle la mise en série de l’objet (ou sérialisation).
Objet transitoire
Un objet fugitif qui n’existe que pendant l’exécution d’une méthode, d’un fil ou d’un processus.
Contraire d ’un objet persistant
Les instances transitoires doivent être créées et détruites avec précision
mécanismes de gestion des instances
« fabrique »
Objet actif ou passif
Objet Actif
Un objet autonome ou capable de modifier son état sans intervention externe.
Un objet actif contient généralement un automate qui modélise son comportement
Objet passif
Un objet incapable de modifier son état sans intervention externe.
Un objet passif est vue comme un ensemble de services sans contrôle dynamique associé
Supports logiciels de la dynamique
Processus : Flot de contrôle (exécutable) qui peut s’exécuter en parallèle avec d’autres processus. On parle parfois de tâche
Thread : Flot de contrôle léger qui peut s’exécuter en parallèle avec d’autres threads dans un même processus.
Processus et Thread peuvent posséder des propriétés comme la priorité, la récurrence, le mode d’activation, en accord avec les possibilités de l’operating system support.
Un processus ou un thread est associé aux objets actifs
Synchronismes
La communication entre objets (messages) peut empiéter sur le déroulement du flot courant de l ’objet
Action synchrone
Action sous forme de requête qui interrompt le cours du flot courant pour attendre la fin de son exécution. On parle également d’action exécutée de façon synchrone.
Action asynchrone
Action sous forme de requête qui n’interrompt pas le cours du flot courant pour attendre la fin de son exécution. On parle également d’action exécutée de façon asynchrone.
UML
Modélisation d ’une solution avec UML
Modélisation d ’une solution avec UML
Contrairement aux activités tournant autour du problème, les activités d’UML tournant autour de la solution sont orientées principalement vers la production de logiciel
Certaines parties de la modélisation peuvent éventuellement être appliquées à d’autres domaines
La modélisation d ’une solution comprend trois grandes parties
L’approfondissement de l’analyse
Éventuellement la remise en cause
Le détail de la vue logique
La modélisation dynamique
Modélisation d ’une solution avec UML
Première Étape : Approfondissement de l’analyse
Principe de l’approfondissement de l’analyse
Principe général
On va critiquer la vue logique obtenu en phase d’analyse du problème afin de dégager une solution
La solution Doit répondre au problème
Mais peut répondre à d’autres problèmes du même type
Peut également réutiliser des éléments de réponses mis au point sur d’autres projets (et qui n’ont rien à voir a priori avec le problème courant)
Principes techniques
Des itérations sur les catégories et les classes permettent : de créer de nouvelles classes, de remettre en cause les classes existantes
Recherche de réutilisation de composants existant
Utilisation des schémas standard design patterns
Il existe des règles que l’on peut suivre et qui guident la démarche d’approfondissement
Modélisation d ’une solution avec UML
Exemples de règles applicables
Classes façades
Introduire des classes façade pour simplifier ou améliorer l'interface des catégories.
La classe façade d'une catégorie donne une interface simplifiée pour ses clients.
services de création et de destruction d'objets,
accès régulé aux autres classes publiques de la catégorie.
Exceptions :
Les classes thématiques
Les classes composites
Schéma(s) : Façade
Classes façades : intérêt
Fournir un point d'entrée privilégié pour les classes d'une catégorie, ce qui la rend plus facile d'utilisation
Minimiser les relations de dépendance entre un client et les classes de la catégorie
Limiter le couplage
Améliorer la primitivité
Classes de services
Introduire des catégories et des classes techniquesdédiées à la fourniture de services transversaux et essayer de les concevoir avec une cohésion forte
Dans la plupart des applications, des services ou mécanismes communs aux différentes catégories doivent être mis en œuvre. Ces services peuvent être regroupés dans une ou plusieurs classes dédiées.
On essayera d'améliorer la cohésion de ces catégories en groupant fonctionnellement les services fournis.
Classes de services : intérêt
Elle assure l'homogénéité de l'application : elle permet de réutiliser une même solution dans les différentes parties de l'applicatif où le même problème technique se pose.
La conception est plus lisible et plus évolutive.
La traçabilité de la conception vis à vis de l'analyse est facilitée
Les composants de ces catégories transversales ont la particularité d'être réutilisables. Le fait de les concevoir dans des catégories dédiées favorise leur réutilisation dans le contexte d'autres projets.
Classes de services : exemples
Composants dédiés à la gestion de processus (communication, partage de ressources, service de nommage, ...).
Composants encapsulant les "appels système" (mécanisme de verrouillage, gestion des droits d'accès au fichier, ...),
Mécanismes facilitant la mise en place de machines à état, la gestion des événements ou des exceptions.
Séparation Domaine
Les classes de responsabilité thématique (issue du domaine) doivent être séparées des classes de catégorie informatique (implémentation de la solution) afin d'améliorer la réutilisabilité et la maintenabilité
Il est recommandé de ne pas mélanger dans un même paquetage des classes issues du domaine avec les autres types de classes (techniques, informatiques)
Les classes du domaine doivent être identifiées
Attribut du modèle ou une règle de nommage
Séparation Domaine/Informatique : Intérêt
Meilleure maintenabilité
Meilleure traçabilité entre les classes d'analyse et les classes de conception.
Le développement des deux types de classes (informatiques et du domaine) ne demande pas les mêmes compétences. Séparation des équipes
Les composants informatiques sont souvent réutilisables quel que soit le domaine d'application(réutilisation horizontale) alors que le spectre de réutilisation des objets du domaine est restreint au domaine d'application (réutilisation verticale).
Créations
Repérer les classes à structure complexe, évolutive ou générique et créer une classe spécifique qui prend en charge la création et éventuellement la gestion de leurs instances
classe complémentaire qui prend en charge complètement la gestion de toutes les instances de la classe.
classe qui fournit les services basiques de créations et de destructions, en s'appuyant éventuellement sur un schéma de classe.
Des services complémentaires peuvent prendre en charge la gestion des instances comme le comptage des instances, l'itération sur les instances, etc.
Schémas : " Fabrique Abstraite ", " Fabrication ", " Monteur ", " Prototype "
Créations : Intérêt
La centralisation des instances permet d'avoir une seule interface quel que soit l'objet construit, sa structure, sa complexité ce qui facilite l'utilisation de la création d'instance
La centralisation facilite également la maintenancecar on a une très bonne séparation entre l'interface de création et l'implémentation de la création
Enfin, cette centralisation supporte la création dynamique d'objet : la centralisation permet de contrôler l'ensemble des instances créées afin d'éviter ainsi des problèmes de mémoire, de pointeurs en l'air, etc.
Modélisation d ’une solution avec UML
Deuxième Étape : Détails de la vue logique
Principe du détail de la vue logique
Lors de la modélisation de la solution, la vue logique sera plus précise, plus complète que lors de la modélisation du problème
Les classes seront plus nombreuses
On utilisera des possibilités de modélisations plus avancées
Idée
Préparation de l’activité de programmation
En pratique, cette activité est très liée aux possibilités des outils UML et leur capacité à générer du code à partir des modèles UML
Attributs
On détaille les classes en donnant les attributs
La description des attributs comprend un nom, un type, une valeur par défaut, une cardinalité: On va préciseer la visibilité des attributs
si l'attribut est public (+), privé (-) ou protégé (#).
Un attribut peut être dérivé d'un autre attribut.
Pour améliorer la maintenabilité, les attributs sont généralement privés ou protégés Principe de masquage de l’information
Les outils utilisés peuvent proposer des représentations graphiques plus adaptéesà la représentation de ces propriétés.
+Visible:int = 10
# Protégé : float = 0.7
+Get (in x: int = 0)
# Display () {abtrait}
Classe
Description des attributs
En phase de modélisation du problème, la vue logique devra décrire les caractéristiques de chaque attribut afin d'améliorer la complétude et préparer la phase de codage
On décrit précisément les attributs de chaque classe.
Cette description est effectuée en fonction des possibilités de l'outil support à la modélisation, de ses capacités en génération de code et du langage cible (C++, ADA, JAVA, autre).
Description des attributs
Informations associées aux attributs :
sa visibilité et son mode (" statique " par exemple)
son type
sa valeur par défaut (associé au constructeur par défaut = initialisation sur démarrage à froid)
ses autres valeurs d'initialisation possibles (initialisation sur démarrage à chaud, réinitialisation, etc.)
un lien éventuel avec des opérations d'accès
la description des attributs est utilisée pour compléter la génération du code
Opérations
On détaille les classes en donnant les opérations Plus précis que les simples responsabilités
La description des opérations comprend un nom, un type de retour, une liste de paramètres. On peut préciser si l'opération est publique (+), privée (-)
ou protégée (#).
Pour chaque paramètre, on peut décrire un nom, un type, un mode (in , out ou in-out) et une valeur de défaut.
On peut préciser si l'opération est abstraite ou pas.
Les outils utilisés peuvent là aussi proposer des représentations graphiques plus adaptéesà la représentation de ces propriétés. +Visible:int = 10
# Protégé : float = 0.7
+Get (in x: int = 0)
# Display () {abtrait}
Classe
Description des opérations
En phase d’explicitation d’une solution, la vue logique devra décrire les caractéristiques de chaque opération afin d'améliorer la complétude et préparer la phase de codage
Cette description est effectuée en fonction des possibilités de l'outil support à la modélisation, de ses capacités en génération de code et du langage cible (C++, ADA, JAVA, autre). On peut aller jusqu’à définir toutes les opérations de niveau
langage de programmation, si l’on dispose d’un outil efficace en terme de génération de code
Sinon, on ne décrira que les opérations principales, avec une syntaxe simplifiée
Description des opérations
Informations associées à une opération :
sa visibilité
sa signature (type de retour, paramètres, mode de passage)
le protocole d'appel
les exceptions éventuelles levées et traitées par l'opération
les pré conditions et post conditions
la description des opérations est utilisée pour générer les squelettes de code pour chaque fonction
Description du comportement
La description d'une opération doit être réalisée à l'aide d ’assertions (pré conditions et post conditions), et non pas à l'aide d'algorithme ou de flot de donnée
L'utilisation des pré conditions et post conditions est conseillée pour chaque opération.
Des principes éventuels de conception peuvent être également ajoutés à la description de l'opération, sans entrer dans une description algorithmique précise.
Description des exceptions
On établira pour chaque opération et pour chaque classe, la liste des exceptions afin de compléter la description du comportement statique
Pour spécifier le contrôle, on doit faire la liste des exceptions locales (privées) et non locales (publiques).
Les exceptions privées sont traitées localement.
Les exceptions publiques seront référencées globalement.
Modélisation d ’une solution avec UML
Dernière Étape : Modélisation de la dynamique des classes
Modélisation de la dynamique
La modélisation de la dynamique s’effectue par une vue complémentaire
La vue de la dynamique
La vue dynamique consiste à compléter la vue logique et la vue des cas d'utilisation par des informations plus précises qui visent à décrire la dynamique du logiciel et de certaines classes.
Diagrammes UML possibles
diagramme états – transitions et diagramme d'activités
Éventuellement diagramme de séquence et diagramme de collaboration
Compléments UML possibles
diagrammes des cas d ’utilisation
Niveaux de modélisation
La rajout d 'éléments de modélisation pour exprimer la dynamique peut être effectué à trois niveaux
Niveau Classe et Objet :
on décrit le fonctionnement interne d'une classe
Niveau Paquetage :
on décrit le fonctionnement interne d'un paquetage
Niveau Logiciel ou Sous Système :
on décrit le fonctionnement interne d'un sous système
le fonctionnement du logiciel complet et l ’interface dynamique entre les sous systèmes
Diagramme États Transitions
Diagrammes états - transitions
Les diagrammes états - transition permettent de modéliser des machines à états.
Ils permettent de modéliser la dynamique des systèmes réactifs ou événementiels de façon semi-formelle.
Inspirés par : les Statechart de Harel,
les Réseaux de Pétri,
le Grafcet.
Si leur description est rigoureuse, les diagrammes états transitions sont déterministes et se prêtent bien à la génération de code.
Diagrammes états - transitions (1)
Les diagrammes états - transitions permettent de décrire des états stables dont 2 particuliers : l'état initial et l'état final.
Événement initial
Événement Final
Diagrammes états - transitions (2)
Les états peuvent être reliés par des transitions qui expriment le changement d'état. Ce changement peut être déclenché par un événement, une condition ou la conjonction des deux.
État 1
État 2
Événement [condition]
Diagrammes états - transitions (3)
Une transition peut être également directement déclenchée par la fin d'une activité : on parle alors de transition automatique.
État 1
État 2
Diagrammes états - transitions (4)
On peut associer à chaque transition des actions ; de la même façon , on peut associer des traitements aux états.
État 1
Entry : Activité
État 2
Do : activité
Événement / Action
Exemple de diagramme
Événement initial
État 1
Entry : Activité
État 2
Do : activité
État 3
Evénement [condition]
[condition]
Événement / Action
Sous machine
Diagrammes états - transitions : possibilités
La modélisation que UML propose pour les diagrammes états transitions est très riche :
pour chaque état, on peut définir des actions associées à l'état, mais aussi des actions en entrée et en sortie de l'état ; on peut également définir des actions sur transition interne : on ne change pas d 'état mais on effectue une action lorsque un événement survient. Cette transition interne peut même être associée à une condition de garde
pour chaque transition simple, on peut définir un événement déclenchant, mais aussi une condition de garde, une action sur transition et une liste de messages
Diagrammes états - transitions : possibilités
il est possible d'utiliser des disjonctions et conjonctions afin d'exprimer un parallélisme :
le franchissement d'une transition de type disjonction entraîne l'activité de deux états concurrents supportés par deux fils (threads) distincts
il est possible d'associer des propriétés aux événements :
le stéréotype signal permet de décrire des événements en utilisant les diagrammes de classes.
On peut utiliser les relations d'héritage pour hiérarchiser les événements.
Possibilités d ’incohérences
La puissance d'expression d'UML est très riche en ce qui concerne les diagrammes états transitions
La richesse peut conduire à des incohérences lors de la description des éléments du modèle :
incohérences entre la description des actions sur état et la description des actions sur transition
incohérences entre la description des actions en sortie d'une état, et la description des actions en entrée d'un autre état
incohérences entre la description des événements et la description des actions
UML est un langage semi formel
Non comparable à des formalismes comme le Grafcet ou les réseaux de Pétri
Non interprété
Utilisation en cas de rigueur exigée forte
Si le niveau de rigueur exigé pour le diagramme est fort, on utilisera une restriction des diagrammes états - transitions pour représenter la dynamique complète de la classe
Si le niveau de rigueur exigé est fort, il faudra que la représentation du comportement soit non ambiguë. Dans certains cas, on préférera même une modélisation parallèle avec un outil adapté à base de Réseaux de Pétri ou de LDS qui prendra en charge une génération du code, ou une preuve de bon comportement.
Restriction de la modélisation
utiliser uniquement des transitions simples : on remplace les transitions multiples par des transitions simples en rajoutant des états de synchronisation utiles pour supprimer le parallélisme induit par les transitions multiples
utiliser des conditions simples ou des événements simples pour chaque transition : on supprime les disjonctions / conjonctions d'événement ou les disjonctions / conjonctions de conditions en rajoutant des états intermédiaires.
Restriction de la modélisation (suite)
utiliser des attributs de la classe pour décrire les conditions : on supprime les effets de bord quitte à avoir une image des
données externes à la classe utiles à la description du comportement. La création d'une donnée image permet de décrire précisément la disponibilité de la donnée (quand est elle mise à jour ? )
ne pas utiliser pour exprimer les transitions les attributs de la classe qui décrivent son état : les conditions doivent être totalement indépendantes des
variables d'états de la classe qui elles sont associées aux états. Il faudra rajouter des états complémentaires pour prendre en compte ces conditions particulières.
Restriction de la modélisation (fin)
éviter le mélange d'événements et de conditions sur une même transition : on crée autant d'états intermédiaires que de combinaisons
événements - conditions
utiliser : soit des traitements sur états uniquement (les activités) , (pas de
traitement en entrée, ni en sortie, ni sur événement interne, ni sur transition)
soit des traitements en entrée uniquement (les activités) , (pas de traitement sur état, ni en sortie, ni sur événement interne, ni sur transition)
dans les traitements, ne pas utiliser des attributs d'état de la classe : si c'est la cas, on doit éclater les actions pour ne retenir que les actions élémentaires associées aux états courants
Restriction de la modélisation : intérêt
La restriction de la modélisation évite les incohérences de description précitées
Elle impose une duplication des états permettant une meilleure sémantique pour chaque état
Cette restriction simplifie l'expression des actions et des conditions, améliorant ainsi la robustesse
Exemple : Description non rigoureuse
Off->On
Démarrage
Do : Diagnostic
Nominal
Do : Diagnostic
IT0 [!Panne périphérique]
On->Off
Description non rigoureuse (commentaire)
Sur l'événement " Off->On ", on passe dans l'état démarrage. Cet état se termine lorsque l'IT0 est déclenchée s'il n'y a pas de pannes.
On passe alors dans l'état Nominal d'où l'on sort sur l'événement On->Off.
Dans chacun des états, on exécute la même activité qui consiste à diagnostiquer les événements.
Off->On Démarrage
Do : Diagnostic
Nominal
Do : Diagnostic
IT0 [!Panne périphérique]
On->Off
Description non rigoureuse (commentaire suite)
Incohérences ou ambiguïtés : " Panne périphérique " est un attribut d'état : il ne doit pas être utilisé dans une
condition mais donner lieu à la création d'états complémentaires. Cela permet notamment de décrire le fonctionnement du logiciel en mode dégradé lorsque les pannes apparaissent.
L'activité de diagnostic exécutée dans chacun des états dépend de l'état. Il faut la découper : diagnostic en démarrage, diagnostic en nominal.
Que se passe t il si l'interruption IT0 survient et si la donnée Panne périphérique n'est pas disponible ou si sa valeur n'est pas cohérente avec l'état des périphériques ?
Que se passe t il si la panne périphérique survient 1 seconde après le déclenchement de l'IT0 ?
Off->On Démarrage
Do : Diagnostic
Nominal
Do : Diagnostic
IT0 [!Panne périphérique]
On->Off
Description plus rigoureuse
Off->On
Démarrage
Entry : Diagnostic
en démarrage
Nominal
Do : Diagnostic
en Nominal
IT0
On->Off
Panne Détectée :
Entry : Diagnostic
de confirmation
Panne Confirmée :
Entry : Diagnostic
de confirmation
[Diagnostic positif]
[!Confirmation]
[Confirmation]
Diagramme d'activités
Diagramme d ’activités
Un diagramme d'activités est une machine à étatsdans laquelle les états sont des activitésreprésentant les opérations, et les transitions sont déclenchées par la terminaison des opérations.
Les états d'un diagramme d'activité sont appelés des états actions :
la fin de l'exécution d'un traitement entraîne le déclenchement d'un événement implicite qui conduit au changement d'état.
Diagramme d ’activités (1)
On peut utiliser des conjonctions et des disjonctionsafin de modéliser des cheminements d'actions. Il est possible d'aiguiller l'enchaînement en rajoutant des conditions.
État Action 3
État Action 5État Action 4
[Condition B][Condition A]
Diagramme d ’activités (2)
On peut modéliser des objets dont la mise à jour est associée au changement d'état : ces objets peuvent être décrits à l'aide de leur état interne.
État Action 1
État Action 2 État Action 3
Objet [État 1]
Diagramme d ’activités (3)
Les objets peuvent être également en entrée d'un état action : on veut signifier dans ce cas là que l'enchaînement vers une nouvelle activité est déclenché par le changement d'état de l'objet.
État Action 3
État Action 5État Action 4
[Condition B][Condition A]
Objet [État 2]
État Action 8
Diagramme d ’activités (4)
On peut découper un diagramme en couloirs pour exprimer un parallélisme d ’actions
Couloir 2Couloir 1
État Action 1
État Action 2 État Action 3
Objet [État 1]
Diagramme d ’ activités complet
État Action 1
État Action 2 État Action 3
État Action 5État Action 4
[Condition B][Condition A]
État Action 6 État Action 7
Objet [État 1]
Objet [État 2]
État Action 8
Utilisation des diagrammes d ’activités
Le diagramme d'activité pourra être utilisé afin de mettre en lumière un enchaînement de traitementsinternes à une classe.
On le réservera pour des modélisations peu rigoureuses, purement informatives, dans lesquelles on veut mettre en lumière des contraintes de synchronisation entre opérations
éviter la multiplicité des formalismes
on référera le diagramme états transitions
Le sémantique du concept de couloir est trop faible et ne permet pas par exemple de définir des fils (threads)
Diagramme États Transitions
Règles et Recommandations
États homogènes
Dans un diagramme états - transitions, les états doivent être homogènes afin de faciliter la description des transitions et la compréhension du comportement
Dans un diagramme ou les états sont hétérogènes, on mélange généralement les comportements
Simplification d ’un diagramme / États homogènes
Des états homogènes d'un diagramme correspondent aux différents valeurs ou classes de valeurs (au sens d'une relation d'équivalence) de l'état interne de la classe.
L'état interne peut être associé à une notion de mode, de temps, etc..
La recherche d'une meilleure homogénéité consiste par exemple à séparer les états " internes " des états liés à des déclenchements d'événements externes.
On utilisera une sous machine pour décrire des états de niveaux différents
États homogènes : contre exemple
Off->On
Démarrage
Mode Superviseur
IT0 [!Panne Périphérique && SuperviseurPassword
On->Off
Mode Utilisateur
Standard
IT0 [!Panne Périphérique && !SuperviseurPassWord]
IT0 [Panne Périphérique]
États homogènes : contre exemple
Il mélange deux notions :
celle de gestion du mode de fonctionnement du système (démarrage- normal),
celle de gestion des modes d'utilisation du logiciel (utilisateur standard, superviseur)
Pour améliorer le diagramme, on devra créer deuxmachines.
Une machine de Gestion des Modes
Une machine de Traitement du diagnostic
Refonte : Gestion des modes
Off->On
Démarrage
Mode Superviseur
[SuperviseurPassword]
On->Off
Mode Utilisateur
Standard
IT0
Connexion
Entry : GetPassword
[!SuperviseurPassword]
On->Off
Refonte : Traitement du diagnostic
Off->On
Démarrage
Entry : Diagnostic
en démarrage
Nominal
Do : Diagnostic
en Nominal
IT0
On->Off
Panne Détectée :
Entry : Diagnostic
de confirmation
Panne Confirmée :
Entry : Diagnostic
de confirmation
[Diagnostic positif]
[!Confirmation]
[Confirmation]
Simplification des diagrammes
Le nombre de chemins indépendant dans un diagramme états transitions sera limité à 15 si l'on veut maîtriser le comportement qu'il décrit.
La complexité d'une machine se mesure par le nombre de chemins linéairement indépendants qui conduisent de l'état initial à l'état final.
Théorie des graphes
nombre cyclomatique : v(G)
Si le nombre de chemins est trop important, la machine devient difficilement testable.
Limitation du nombre de chemins
Pour limiter le nombre de chemins , on structure les diagrammes état transitions en faisant apparaître des sous - machines et en reportant la règle sur les sous machines
L'enchaînement entre les sous - machines est une machine de plus haut niveau que l'on peut appeler machine maître.
Lors d'une telle organisation, la machine maître doit être très simple.
Réversibilité
On doit toujours pouvoir revenir dans n'importe quel état, autre que l'état initial si on veut améliorer la fiabilité
La réversibilité exprime la possibilité pour une machine à état de pouvoir toujours revenir directement ou indirectement dans un état que l'on a quitté.
Ce principe peut exprimer par exemple la possibilité d'annuler une action (" undo "), de pouvoir effectuer une action inverse afin d'annuler l'effet d'une action passée, de se recaler sur un état plus stable ou de se récupérer après une erreur.
Réversibilité (suite)
Ce principe est essentiel en conception sûre.
La réversibilité améliore la sûreté de fonctionnement
Attention, cette propriété est formelle et nécessite une formalisation très stricte de la machine, en termes d'actions et de conditions.
Restriction d ’UML
Synchronisation
Quel que soit l'état courant, il doit exister un moyen de rejoindre l'état final afin d'améliorer la sûreté de fonctionnement
" séquence de synchronisation ".
L'existence de séquence de synchronisations exprime les capacités de non blocage d'une machine à états.
Une machine capable de ne pas se bloquer améliore la sûreté de fonctionnement
Attention, propriété formelle
Évaluation de la qualité d ’un modélisation
Évaluation de la qualité des objets et des classes
Cohésion
La cohésion de chaque classe doit être forte afin d'améliorer la maintenabilité
La cohésion mesure la pertinence des liens entre les informations (méthodes et attributs) internes à un objet. Une forte cohésion est le signe d'une très bonne abstraction et minimise l'impact des modifications.
Une classe ou catégorie doit représenter une et une seule abstraction : c'est le cas de la cohésion fonctionnelle ou Type abstrait
Mesure de la cohésion
On peut définir une échelle de la cohésion, de la plus faible à la plus forte de 0 à 6.
0Arbitraire (Coïncidence)
1Logique
2Temporel
3Procédural
4Communication
5Séquentiel
6Type abstrait
Niveau 0 : Arbitraire (Coïncidence)
Les traitements (méthodes) n'ont aucun lien logique entre eux
Les attributs sont accolés sans lien structurel ou fonctionnel.
Exemple : On rassemble dans une classe tout ce qui est développé
par une même personne, ou tout ce qui est développé sur un site, ou tout ce qui est développé en utilisant un langage particulier.
Commentaires et actions d'amélioration : Ce type de cohésion doit être évité à tout prix : il faut
redistribuer les attributs et les opérations dans d'autres classes
Niveau 1 : Logique
Les traitements sont de même nature mais il n'existe pas d ’autre lien entre eux.
Exemple :
On regroupe dans une classe l’ensemble des fonctions mathématiques
Commentaires et actions d'amélioration :
Ce genre d'approche n'est pas souhaitable en approche orientée objet : il faudra réorganiser les opérations en les associations à des types de données précis. Par exemple, on pourrait découper la classe en regroupant les opérations sur les nombres réels ce qui permettrait de cacher l'implémentation. On pourrait isoler les opérations trigonométriques, ce qui permettrait une liberté supplémentaire sur la représentation des données (implémentation polaire par exemple).
Niveau 2 : Temporel
Les traitements s'exécutent dans la même période. Il peut exister des liens faiblement synchrones.
Exemple : On a regroupé les actions de type initialisation dans une
même classe ; on a regroupé les actions déclenchées par un même événement dans une même classe
Commentaires et actions d'amélioration : Ce genre de cohésion est à éviter : il va poser des
problèmes de maintenance énormes. On découpe les traitements de la classe en sous - traitements centrés sur les données utilisées par ces traitements. On distribue les traitements dans des classes séparées associées aux données.
Niveau 3 : Procédural
Les traitements forment une procédure et sont appelés dans un ordre défini sans qu'il y ait un lien de cause à effet entre ces traitements.
Exemple :
On a regroupé dans une classe les opérations élémentaires qui entrent dans la composition de plusieurs calculs afin d'avoir un point d'appel unique.
Commentaires et actions d'amélioration :
On peut généralement toujours améliorer une classe de cohésion procédurale, en l'éclatant en une classe de cohésion communication et une classe de cohésion séquentielle.
Niveau 4 : Communication
Les traitements ont les mêmes paramètres d'entrée-sortie
Exemple :
On regroupe l’ensemble des fonctions trigonométriques dans une classe sans définir formellement les types de données associés aux domaine de définition
Commentaires et actions d'amélioration :
Pour améliorer une cohésion de communication, il faut compléter par une définition des données : par exemple définir le type angle, et lui associer les opérations trigonométriques.
Niveau 5 : Séquentiel
Les traitements se suivent : la sortie de l'un est l'entrée de l'autre
Exemple :
On crée une classe de contrôle pour synchroniser plusieurs autres classes indépendantes : acquérir une donnée brute, formater la donnée brute, calculer un terme correctif
Commentaires et actions d'amélioration :
si le déplacement de la synchronisation vers d'autres classes introduit un déséquilibre dans la responsabilité des classes, alors cette cohésion est correcte
s'il existe une ou plusieurs classes qui peuvent prendre en charge la synchronisation (cas de classes maîtres), alors on déplacera la synchronisation vers ces classes en supprimant la classe courante.
Niveau 6 : Type abstrait
La classe correspond à un type de donnée abstrait : c'est l'objet parfait
Exemple :
La classe String de Java qui cache l'implémentation des chaînes de caractères et fournit tous les services possibles pour la manipuler.
La classe Stack qui fournit les opérations de manipulation de pile
Commentaires et actions d'amélioration :
Une classe de cohésion type abstrait est l'objectif qu'il faut atteindre lors de la modélisation d'une abstraction homogène à une donnée.
Primitivité
La vue publique de chaque classe doit être primitive afin d 'améliorer maintenabilité, fiabilité et réutilisabilité
Avec une classe primitive, on ne peut pas simplifier l'interface fournie par la classe sans perdre une fonctionnalité proposée par l'objet (c'est à dire qu'il n'y a pas de redondance dans l'interface de l'objet).
On parle aussi de « primitivité de l'interface »
Primitivité : Intérêt
Une interface primitive simplifie l'utilisation des classes et donc joue favorablement sur la réutilisabilité
Une interface primitive simplifie les implémentationset donc la maintenabilité et la fiabilité (meilleure cohérence des services rendus)
La réutilisation d'une classe non primitive entraîne des incohérences qui nuisent à la compréhension : on peut avoir dans un même projet des réutilisations du même service sous des formes différentes (voir exemple)
Primitivité : Mesure
Pour mesurer la primitivité d'un objet, on essaie de simplifier l'interface de l'objet par itérations successives. On peut ainsi essayer de masquer des attributs, de supprimer des paramètres associés aux méthodes, de supprimer des méthodes elles-mêmes. Si l'on n'arrive pas à une primitivité de 100%, c'est que les méthodes associées ne sont pas les bonnes ; il faut alors essayer de la changer.
Pour la recherche de la primitivité, un point de vue externe est souvent nécessaire.
Lors de la recherche de la primitivité, on envisage l'interface d'un objet comme un tout.
Primitivité arbitrage : une classe primitive
Creer
InsererElementTete (element)
SupprimerElementTete
TeteListe
ElementSuivant
Liste
Dans ce premier exemple, une structure de liste est gérée entièrement au travers de la classe Liste.
La liste est supposée simplement chaînée.
L’interface de Liste est primitive :
On a uniquement les services de base pour créer, mettre à jour, supprimer des éléments et parcourir la liste.
Primitivité arbitrage : une façade non primitive
Creer
InsererElementTete (element)
SupprimerElementTete
TeteListe
ElementSuivant
Liste
Dans ce second exemple, une façade a été créée afin de proposer des services complémentaires.
L ’interface de MaListe n ’est pas primitive, mais les nouvelles opérations fournies respectent les principes de fonctionnement d ’une liste
EstVide
SupprimerElements
RechercherElement (element)
Creer
EstVide
InsererElementTete (element)
SupprimerElementTete
SupprimerElements
TeteListe
ElementSuivant
RechercherElement (element)
MaListe
Primitivité arbitrage : une façade non appropriée
Creer
InsererElementTete (element)
SupprimerElementTete
TeteListe
ElementSuivant
Liste
Dans ce troisième exemple, une façade inappropriée a été créée.
En effet, les deux nouvelles opérations fournies ne respectent pas les principes de fonctionnement d ’une liste
DonneElement (index)
AffecteElement (index)
Ces deux opérations ne sont pas efficaces, et peuvent induire une utilisation d ’une structure de liste, à la place d’une structure de table.
TaListe
Creer
EstVide
InsererElementTete (element)
SupprimerElementTete
SupprimerElements
TeteListe
ElementSuivant
RechercherElement (element)
DonneElement (index)
AffecteElement (index)
Couplage
Le couplage mesure le degré d'interconnexion entre les classes et les catégories. Un couplage exprime généralement une complexité des relations entre classes ou entre catégories : les liens sont nombreux, la nature des liens est complexe.
Le couplage entre deux catégories doit être minimal; Le couplage entre deux classes doit être minimisé
Un couplage réduit facilite les modifications locales à un composant : il améliore la maintenabilité.
Un couplage faible améliore la réutilisabilité.
Mesure du couplage
Pour évaluer le couplage, on peut définir une échelle du couplage, du plus fort au plus faible.
Niveau A : Contenu
Niveau B: Global
Niveau C : Contrôle
Niveau D : Structure
Niveau E : Données
Niveau A : Couplage de contenu
Le couplage de contenu est le couplage le plus fort.
Il met en lumière l'intrusion d'une classe dans le comportement d'une autre.
Il montre généralement de gros défauts de conception ou de réalisation qui peuvent être liés à un besoin d'optimisation et de configuration excessif.
Ce couplage peut être également dynamique : il se révèle à l'exécution du logiciel.
C ’est également souvent un problème de codage
Couplage de contenu : Exemples
référence à des données internes d'un autre composant (utilisation de friend par exemple, non-respect de l'encapsulation)
branchement direct d'un composant dans un autre (non respect de l'encapsulation du code, utilisation en C/C++ de SetJmp / LongJmp, etc.)
modification des instructions d'un composant par un autre(exportation de macros, abus de fonctions inline, etc..)
utilisation des mêmes constantes dans le code (partage de constantes de configuration, de switch de compilation)
non maîtrise des chaînes de responsabilités : traitement des exceptions non locales mal maîtrisé, messages entre fenêtres mal acheminés,
Amélioration du couplage de contenu
On améliore un couplage de contenu :
en respectant l'encapsulation existante concernant les données, les traitements, les exceptions
en hiérarchisant les événements et les exceptions
en clarifiant et simplifiant les chaînes de responsabilitémises en œuvre dans le logiciel (exception, messages, délégation)
en redécoupant les classes afin d'encapsuler les données de configurations et les macros
en interdisant certaines tournures de programmation (saut entre modules, classes amies, etc.)
Niveau B : Couplage global
le couplage global exprime un manque de structuration de la décomposition : on a décrit une structure à plat sans utiliser les hiérarchies ou l'encapsulation. Contrairement au couplage de contenu qui exprime une non-utilisation de l'encapsulation ou un détournement de l'encapsulation par des mécanismes intrusifs, le couplage global exprime le respect d'une mauvaise encapsulation.
Exemples
groupe de n modules partageant la même donnée commune
utilisation excessive de catégories de bas niveau
Amélioration du couplage global
On améliore un couplage global :
en isolant des classes à cohésion plus forte qui regroupent différemment les données et les traitements
en évitant les classes et catégories de type coïncidence
On pourra accepter le couplage global lorsque les données et les méthodes de bas niveau utilisées sont réutilisées ou vraiment globales au logiciel.
Niveau C : Couplage de contrôle
Le couplage de contrôle exprime la possibilité qu'a une classe de modifier le comportement d'une autre.
Contrairement au couplage de contenu qui exprime la possibilité de modifier le comportement d'une autre classe par un mécanisme intrusif, le couplage de contrôle exprime l'utilisation correcte des méthodes d'une classe pour modifier son comportement.
Exemples :
exportation d'informations destinées à contrôler la logique interne d'un composant
utilisation de données externes pour contrôler l'état d'une classe
Amélioration du couplage de contrôle
On améliore un couplage de contrôle :
en séparant dans les données de la classe celles qui sont associées à l'état de la classe, des autres données membres
en cachant les données associées à l'état de la classe
en décrivant des machines à états rigoureuses
en créant une classe de contrôle
Niveau D : Couplage de Structure
Le couplage de structure exprime la communication vers d'autres classes de la structure de la classe.
Exemples :
exportation de données membres à structure
exportation de types
exportation d'énumérations
Amélioration du couplage de structure
On améliore un couplage de structure :
en encapsulant les structures de donnée, les types, les énumérations
en décrivant des méthodes d'accès primitives aux champs éléments des données membres à structure complexe
On pourra dans certains cas accepter le couplage par énumérations : l'énumération devra dans ce cas être un concept commun aux classes ou catégories couplées.
Niveau E : Couplage de Données
Le couplage de donnée est le couplage minimal. C'est le résultat qu'il faut atteindre.
Exemple :
les données membres de la classe sont masquées
les méthodes de la classe utilisent des paramètres qui ont des types standard
Complétude
Une classe réutilisable doit être complète
L'interface fournie par l'objet est complète en ce sens qu'elle peut être réutilisée telle quelle dans un autre projet de type projet fils, projet filière commune, ou tout autre projet.
Pour mesurer la complétude d'un objet, on analyse l'interface proposée par l'objet du point de vue de sa réutilisation potentielle dans un autre projet.
Cette analyse peut être conduite par une personne hors du projet, adoptant le point de vue d'un réutilisateur.
Héritage : Est un
L'héritage doit exprimer une relation conceptuelle "est un". ou "est une sorte de".
En particulier ne pas confondre héritage et agrégation ("se compose de").
L'utilisation à tort de l'héritage pour spécifier d'autres types de relation, conduit à une mauvaise compréhension de la modélisation et limite les possibilités de réutilisation.
Héritage : Restriction
Dans une classe descendante, ne pas restreindre les propriétés des classes ancêtres. Une classe descendante peut redéfinir des méthodes
publiques de la classe ancêtre (dans le but d'optimiser l'implantation ou spécialiser le comportement) et étendre l'interface publique par de nouvelles méthodes.
Par contre, il est interdit de concevoir des classes héritières qui suppriment des méthodes publiques des classes ancêtres ou masque des attributs
Il doit être possible d'utiliser n'importe quelle classe à la place de sa super-classe.
Les clients d'une hiérarchie d'héritage doivent pouvoir développer du code qui s'applique à toutes les classes filles sans provoquer d'erreur dynamique.
Restriction : Exemples
Soit une classe "Oiseau" avec la méthode "Vole()".
Il est déconseillé de faire hériter la classe "Manchot" de cette classe "Oiseau" (chacun sait que les manchots ne volent pas).
Il est préférable de créer une classe "OiseauNonVolant" dont on dérivera "Manchot".
Il est déconseillé de créer une classe Carré qui hérite d'une classe rectangle en imposant la contrainte longueur = largeur.
Restriction : Exemples
a
b
c
Racines (r1,r2)
Optimum ()
Polynome 2nd Degré
Racine (r)
Polynome 1er Degré
La définition d ’un polynome du premier degré comme un polynome du deuxième degré (avec a = 0) est une solution qui restreint les propriétés du polynome du 2nd degré.
La recherche des racines peut conduire à une erreur si l ’implémentation de polynôme 2nd degré n ’est pas robuste (a=0).
De plus, Optimum n ’existe pas pour un polynome de 1er degré (un polynome du 1er degré est strictement monotone, sauf si b est nul)
UML
Modélisation Physique
Principe de la modélisation physique
Il s’agit de décrire la solution Sous forme physique
Fichiers de développement
Machines de développement
Fichiers d’exploitation
Machines d’exploitation (machines cibles)
Réseaux et autres périphérique
Cette partie d’UML est propre donc au logiciel
Elle donne lieu à deux types de vue La vue des composants
Vue du logiciel en développement
La vue de déploiement Vue du logiciel en exploitation
Vue des composants
La Vue des composants
La vue des composants présente la distribution du logiciel en composants (fichiers de code), librairies statiques et dynamiques et exécutables
Un composant à un nom, et un type : le type est par exemple source, librairie, etc.
Chaque composant à une interface : un diagramme de composants peut montrer les liens de dépendances entres composants.
Un composant réalise des objets et / ou des services décrits dans l'activité de conception : cette relation de traçabilité particulière s 'appelle la relation de réalisation.
Un composant peut décrire graphiquement les objets et classes qu'il implémente.
La Vue des composants
Composant 1
Composant 2
Composant utilisé Service 1
Service 2Objet 1
Objet 2 : Classe
Vue de déploiement
La vue de déploiement
La vue de déploiement montre le déploiement du logiciel sur le matériel
les machines,
les processeurs,
les calculateurs,
les disques,
les mécanismes de transport,
les tâches,
les fils.
Capacités des outils UML
Les vues déploiement sont généralement très limitées par les outils UML
Selon le contexte et le besoin, on pourra compléterle formalisme ; par exemple :
créer des stéréotypes
décider de représenter manuellement la vue du déploiement en décidant d'éléments de modélisation propre
Exemples de stéréotypes
Disques Listing
Bande
Machine
Cpu
Cpu
Thread
Processus
Mémoire (RAM)
Mémoire (Flash)
Exemple de diagramme de déploiement
C:
LPT1
X-Tape
ATBxx
CpuAction
FABRIQUER
XRAM
8000:837Fh
Eflash
0000:7FFFh
Sauver