Embed Size (px)
Citation preview
Pourquoi l’AOO ? (Coad&Yourdon 1993) meilleur abord des questions du domaine meilleure interaction expert domaine /
analyste meilleure cohérence des résultats de l’analyse représentation explicite des éléments
communs production de spécifications résistantes au
changement meilleure réutilisation représentation de base cohérente et continue
pour l’analyse et la conception
2
L’analyse objet dans la démarche A/COO
Analyse objet+ diagrammes état-transition (classes complexes)+ organisation classes en packages UML
3
Qu’est-ce qu’un modèle du domaine ?
La quintessence de l’étape AOO réside dans la décomposition d’un domaine en concepts fondamentaux ou objets
Un modèle du domaine est une représentation visuelle des classes conceptuelles ou des objets du monde réel dans un domaine donné, avec un diagramme de classes UML
Synonymes : modèle du domaine modèle conceptuel modèle objet du domaine modèle objet d’analyse
UML - Diagramme de classes
4
Le modèle du domaine est un dictionnaire visuel Le modèle du domaine permet de visualiser
et mettre en relation les termes ou concepts du domaine
Les classes UML sont une abstraction des classes conceptuelles (ne contiennent que les attributs pertinents au domaine) Ex. on s’en fiche de la couleur du livre
Les informations du modèle du domaine pourraient être présentées sous forme de texte, dans un glossaire par exemple, mais la représentation graphique facilite la compréhension et la communication des termes et de leurs relations
5
Gestion de la complexité abstraction : ignorer certains aspects non pertinents encapsulation : cacher le détail, montrer l’essentiel exprimer et utiliser les similitudes relier les objets 3 méthodes d’organisation constamment utilisées
par les hommes : distinguer entre des objets et leurs attributs (arbre, sa
taille, son âge, etc...) distinguer entre les objets et leurs parties (arbre et
racines, branches, ...) généralisation, identification de classes d’objets (tous les
arbres)
Le modèle de domaine ne représente pas d’objets logiciels
Une classe du domaine représente une entité du monde réel et non des classes logicielles Java ou C++
Les éléments suivants ne doivent pas y figurer : Les artefact logiciels, comme les
fenêtres IHM ou les bases de données, à moins que le domaine ne soit lui-même composé d’objets logiciels, par exemple un modèle d’interfaces utilisateur graphiques
Classes avec les attributs typés ou des méthodes (du ressort de la conception)
7
Pourquoi créer un modèle du domaine ?
Pour comprendre le domaine et communiquer
Pour réduire le décalage des représentations (ou décalage sémantique) entre nos modèles logiciels et mentaux Modèle logiciel d’un programme de paie de
1953 : 1000101010001111010101010100010101010…
Modèle logiciel moderne (orienté objet) :titreauteur
Livre
titreChapitre
*1
Point de vue conceptuel(modèle du domaine)
Livre
getTitre() : StringgetAuteur : StringgetChapitres : List<Chapitres>
titre : Stringauteur : string
getTitre() : Stringtitre : String
Chapitre
Point de vue des spécifications
ou de l'implémentation(diagramme de classes
de conception)
Diagramme de classes servant à visualiser les concepts du monde réel
*
Diagramme de classesservant à visualiser les
éléments logiciels
public class Livre { private String titre; private String auteur; private List<Chapitre> chapitres;
getTitre() { return titre; } ....}
public class Chapitre {private String titre;
....}
Code Java élaboréà partir de la spécification
logicielle(classes conception)
Monde réel
8
Comment procéder pour créer un modèle du domaine ?1. Identifier les objets du domaine (classes
conceptuelles)
1. Identifier les relations entre les objets (associations)
2. Identifier les caractéristiques significatives des objets (attributs)
9
Comment identifier les classes conceptuelles ? Méthode 1 : observer, discuter, lire Méthode 2 : réutiliser ou modifier des modèles
existants Il existe des modèles du domaine publiés et de bonne
facture pour de nombreux domaines : gestion stocks, finances, ATM, etc. Ex. Analysis Patterns (Martin Fowler), Data Model Patterns
(David Hay), Data Model Ressources Book (Len Silverston)
Méthode 3 : Utiliser une liste de catégories Méthode 4 : Identifier des groupes nominaux
10
Ex. Terminal Point de Vente (TPV)Cas d’utilisation « Traiter une vente »
Scénario nominal :1. Le Client arrive à la caisse avec des marchandises et/ou services à acheter.2. Le Caissier commence une vente.3. Le Caissier entre le code de l’article.4. Le Système enregistre l’article et présente sa description, son prix et le
total en cours.1. Le Caissier répète 3 et 4 pour tous les articles.
5. Le Système présente le total incluant les taxes calculées.6. Le Caissier communique le montant total au Client et en demande le paiement.7. Le Client paie et le Système traite son règlement.8. Le Système enregistre la vente et transmet les informations la concernant et
celles concernant le règlement au système de Comptabilité externe et au système de Gestion de stock.
9. Le Système génère un reçu.10. Le Client quitte le point de vente avec ses achats et son reçu.
Extensions :7a. Paiement en espèces :1. Le Caissier saisit le montant reçu en espèces.2. Le Système affiche le solde dû et ouvre le tiroir-caisse.3. Le Caissier encaisse le montant et rend la monnaie en espèces au Client.4. Le Système enregistre le paiement en espèces.11
Méthode 2 : Utiliser une checklist (catégories de classes prévisibles)1. Transactions métier (ex. Vente, Paiement)2. Lignes d’une transaction (ex. LigneArticles, LignePanier) 3. Produit ou service lié à une transaction ou à une ligne d’une
transaction (ex. Article, Livre)4. Où la transaction est-elle enregistrée ? (ex. Caisse
enregistreuse, Panier)5. Rôle des personnes ou des organisation liées à la transaction;
acteurs dans les cas d’utilisation (ex. Internaute, Client)6. Lieu de la transaction; lieu de service (ex. Site, Magasin)7. Evénements notables, souvent à un moment ou dans un lieu
que vous devrez mémoriser (ex. Vente, Paiement)8. Objets physiques (ex. Article, Livre)9. Description d’entités (ex. DescriptionProduit, DescriptionLivre)10. Catalogues (ex. CatalogueProduits, CatalogueLivres)11. Conteneurs d’objets physiques ou d’informations (ex.
Magasin, Panier)12. Contenu d’un conteneur (ex. Article, Livre)13. Systèmes externes (ex. SysPaiementCarteBleue)14. Docs financiers, contrats, docs légaux (ex. Reçu, Facture)15. Instruments financiers (ex. Espèces, Chèque, LigneCrédit)16. Plannings, manuels, documents régulièrement consultés pour
effectuer un travail (ex. MiseAjourTarifs) 12
Méthode 3 : Identifier des groupes nominaux
Cette technique consiste à repérer les noms et les groupes nominaux dans la description textuelle d’un domaine, et à les considérer comme des classes conceptuelles ou des attributs possibles
Les cas d’utilisation sont une excellente description qui peut servir de base à cette analyse (ex. « Traiter une vente »)
Les documents (ex. exigences CdC), la mémoire des experts métier, etc. représentent d’autres sources possibles
Certains groupes nominaux peuvent devenir des classes conceptuelles, d’autres désigner des classes à ignorer lors de cette itération et d’autres sont des attributs de classe
Point faible de la technique : l’imprécision du langage naturel• Différents groupes nominaux peuvent représenter la même classe
conceptuelle ou le même attribut 13
Identifier les classes conceptuelles du domaine TPV
Liste de classes générée à partir de la liste de catégories et l’analyse des groupes nominaux Vente, PaiementEnEspèces, LigneArticles, Article, Registre (caisse TPV),
GrandLivre, Caissier, Client, Magasin, DescriptionProduit, CatalogueProduits
Diagramme de classes initial (attributs et association à ajouter)
14
Identifier les classes conceptuelles du domaine TPV
Exclure les objets non pertinents pour le(s) UC pris en compte dans l’itération courante ex : ticket de caisse :
informations déjà dans les autres classes retour d’articles pas dans les cas d’utilisation pris en compte
pour l’instant
Nom des classes : éviter les codes vocabulaire du domaine noms clairs et représentatifs
15
Comment modéliser avec des classes de « description » ?
Appliquer le pattern « Item-Descriptor » consistant à créer une classe de description (métaclasse) avec les informations supplémentaires
Quand faut-il l’appliquer ? Lorsque : Des Produits ou Services nécessitent une description La suppression d’instances d’une entité qu’elle décrit (ex.
Article) entraîne la perte d’une information qui doit être mémorisée
Elle réduit la redondance ou la duplication des informations
Ex. :
16
Ajout des associations Une association représente une relation plus ou moins durable entre deux
classes Ex1. une personne peut posséder des voitures. La relation « Possède » est une
association entre les classes Personne et Voiture Ex2. une Vente contient des lignes d’article. « Contient » est une association
pour mémoriser les instances de LigneArticles associées à une instance de Vente. Sinon nous ne pourrions pas reconstituer les ventes, ni imprimer le reçu
Il faut éviter d’ajouter trop d’associations parce qu’elles peuvent rendre le diagramme illisible
Il s’agit d’une relation significative du point de vue conceptuel : pas de flot de donnée, de clé étrangère, etc... (cela dit bcp de ces relations seront implémentées dans le logiciel)
Comment les représenter ? Par une ligne entre deux classes avec un nom Les extrémités d’une association, appelées rôles, peuvent contenir un nom et
une indication de multiplicité indiquant une relation numérique entre les instances des classes
Signification de la notation pour la multiplicité : « pour un objet de la classe A, combien d’objets de la classe B ? »
17
A B
Ajout des associations
*
1..*
1..40
5
zéro ou plus ; plusieurs
un ou plus
De un à 40
Exactement 5
18
Checklist d’associations courantes
1. A est une transaction liée à une transaction B (PaiementEnEspèces–Vente)
2. A est un élément d’une transaction B (LigneArticles-Vente) 3. A est un produit pour une transaction B (Article-LigneArticle)4. A est un rôle lié à une transaction B (Client-Paiement)5. A est une partie logique ou physique de B (Tiroir-Caisse
enregistreuse)6. A est physiquement ou logiquement contenu dans B (Caisse-
Magasin)7. A est une description de B (DescriptionProduit-Article)8. A est connu/consigné/enregistré/saisi dans B (Vente-Caisse)9. A est un membre de B (Caissier-Magasin)10. A est une sous-unité organisationnelle de B (Rayon-Magasin)11. A utilise, gère ou possède B (Caissier-Caisse)12. A est voisin de B (Article-Article)
19
Modèle du domaine TPV avec des associations
20
Ajout des attributs
Faites figurer les attributs quand les exigences ou les cas d’utilisation suggèrent la nécessité de mémoriser des informations Ex. Vente (dateHeure), Magasin (nom, addresse)
Dans un modèle du domaine, les attributs doivent être des types de données « primitifs » Booléen, Date, Nombre, Chaîne de caractères, Heure Autres types courants : Adresse, Couleur, Géométrie (Point,
Rectangle), Numéro de téléphone, Numéro de Sécurité sociale, Codes postaux, types énumérés, etc.
Un attribut ne doit pas être un concept complexe du domaine, comme Vente
Déconseillé
Conseillé
21
Attribut ou classe ?
L’erreur la plus courante lors de la création d’un modèle du domaine consiste à représenter quelque chose comme un attribut alors qu’il devrait s’agir d’une classe conceptuelle
Ex.
Le terme suggère une entité doté d’existence juridique, une organisation occupant un espace : Magasin doit donc être une classe conceptuelle.
22
Attributs dérivés
L’attribut « total » d’une Vente est calculé à partir des informations contenues dans chaque LigneArticles. Quand nous voulons exprimer le fait que 1) un attribut est important; et 2) il est dérivable, nous appliquons une convention UML : le symbole « / » devant le nom de l’attribut
L’attribut « quantité » est également dérivé Ce concept n’existant pas dans les langages objet, le
concepteur devra le transformer soit en un attribut « normal », soit en une opération (méthode)
23
Modèle du domaine TPV avec des attributs
24
Affinement d’un modèle du domaine
Généralisation-spécialisation Modélisation des changements d’état Classes association Agrégation/composition Structuration en packages
25
Généralisation-spécialisation
Les concepts PaiementEnEspèces, PaiementACrédit et PaiementParChèque présentent de nombreuses similitudes
Dans cette situation, il est utile de les organiser en une hiérarchie de classes, dans laquelle la super-classe Paiement représente un concept général, et les sous-classes des concepts spécialisés
La généralisation est l’activité qui consiste à identifier les éléments communs aux différents concepts, et à définir des relations de super-classe et sous-classe
Cela permet une expression plus économique, une meilleure compréhension du modèle et une réduction des redondances
Déconseillé
Conseillé26
Modélisation des changements d’état
Ne modélisez pas les différents états possibles d’un concept X comme des sous-classes de X
Deux solutions possibles : Définir une hiérarchie d’états
et les associer à X Ignorer la représentation des
états dans les modèle du domaine, et les représenter dans les diagrammes d’états
Déconseillé
Conseillé
27
Classes association
On peut ajouter des attributs à une association via la notion de classe association
Ex. attribut « codeVendeur » Les services d’autorisation
attribuent un code vendeur à chaque magasin pour pouvoir l’identifier lors des transaction
Toute demande d’autorisation de paiement émise par le magasin doit porter le code
Chaque magasin peut avoir autant de codes différents qu’il utilise de services d’autorisation
28
Agrégation/composition
Une agrégation est un cas particulier d’association non symétrique exprimant une relation de contenance
Les agrégations n’on pas besoin d’être nommées : implicitement signifient « contient », « est composé de »
Une composition est une agrégation plus forte impliquant que : Un élément ne peut appartenir qu’à un
seul agrégat composite (agrégation non partagée)
La destruction de l’agrégat composite entraîne la destruction de tous ses éléments (le composite est responsable du cycle de vie des parties)
Conseils : Abstenez-vous d’utiliser l’agrégation :
une association normale suffit en général
La composition est plus utile, mais dans le doute, abstenez-vous aussi 29
Conclusion et conseils méthodologiques Il n’existe pas de modèle du domaine correct : tous les modèles
sont des approximations du domaine qu’on essaye de comprendre Le modèle du domaine est un outil d’analyse et de communication
qui capture les abstractions et les informations essentielles pour comprendre le domaine : ses concepts, sa terminologie et ses relations
Evitez l’état d’esprit « en cascade » qui implique un gros effort de modélisation pour produire un modèle du domaine exhaustif et « correct »
Une telle « surmodélisation » engendre une paralyse analytique (paranalysis) : soyez donc agile !
Limitez la modélisation du domaine à quelques heures par itération
Le modèle du domaine peut être affiné dans des itérations successives : démarche itérative et incrémentale !
Utilisez autant que possible des patterns d’analyse existants Ex. ouvrages : Analysis Patterns (Martin Fowler), Data Model
Patterns (David Hay), Data Model Ressources Book (Len Silverston)
30
