La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Analyse orientée objet (AOO)

Présentations similaires


Présentation au sujet: "Analyse orientée objet (AOO)"— Transcription de la présentation:

1 Analyse orientée objet (AOO)
Ingénierie Système Q : principale difficulté dans un projet informatique ? Analyse orientée objet (AOO) Catherine Letondal 3/12/2010

2 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 résultats attendus : comprehension du domaine et des besoins évolutivité de la modélisation pour s’adapter aux modifications (des modèles, de l’analyse et des besoins)

3 L’analyse objet dans la démarche A/COO
+ diagrammes état-transition (classes complexes) + organisation classes en packages UML

4 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

5 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

6 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)

7 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)

8 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 : Modèle logiciel moderne (orienté objet) :

9 Comment procéder pour créer un modèle du domaine ?
Identifier les objets du domaine (classes conceptuelles) Identifier les relations entre les objets (associations) Identifier les caractéristiques significatives des objets (attributs)

10 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

11 Ex. Terminal Point de Vente (TPV) Cas d’utilisation « Traiter une vente »
Scénario nominal : Le Client arrive à la caisse avec des marchandises et/ou services à acheter. Le Caissier commence une vente. Le Caissier entre le code de l’article. Le Système enregistre l’article et présente sa description, son prix et le total en cours. Le Caissier répète 3 et 4 pour tous les articles. Le Système présente le total incluant les taxes calculées. Le Caissier communique le montant total au Client et en demande le paiement. Le Client paie et le Système traite son règlement. 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. Le Système génère un reçu. Le Client quitte le point de vente avec ses achats et son reçu. Extensions : 7a. Paiement en espèces : Le Caissier saisit le montant reçu en espèces. Le Système affiche le solde dû et ouvre le tiroir-caisse. Le Caissier encaisse le montant et rend la monnaie en espèces au Client. Le Système enregistre le paiement en espèces.

12 Méthode 2 : Utiliser une checklist (catégories de classes prévisibles)
Transactions métier (ex. Vente, Paiement) Lignes d’une transaction (ex. LigneArticles, LignePanier) Produit ou service lié à une transaction ou à une ligne d’une transaction (ex. Article, Livre) Où la transaction est-elle enregistrée ? (ex. Caisse enregistreuse, Panier) Rôle des personnes ou des organisation liées à la transaction; acteurs dans les cas d’utilisation (ex. Internaute, Client) Lieu de la transaction; lieu de service (ex. Site, Magasin) Evénements notables, souvent à un moment ou dans un lieu que vous devrez mémoriser (ex. Vente, Paiement) Objets physiques (ex. Article, Livre) Description d’entités (ex. DescriptionProduit, DescriptionLivre) Catalogues (ex. CatalogueProduits, CatalogueLivres) Conteneurs d’objets physiques ou d’informations (ex. Magasin, Panier) Contenu d’un conteneur (ex. Article, Livre) Systèmes externes (ex. SysPaiementCarteBleue) Docs financiers, contrats, docs légaux (ex. Reçu, Facture) Instruments financiers (ex. Espèces, Chèque, LigneCrédit) Plannings, manuels, documents régulièrement consultés pour effectuer un travail (ex. MiseAjourTarifs) ex Monopoly (version simplifiée : une simulation logicielle : l’utilisateur lance le logiciel, indique le nombre de joueurs, puis le jeu est lancé, et le logiciel affiche une trace du jeu juqu’às ce qu’il y ait un gagnant ou que l’utilisateur arrête le logiciel) : 5. joueur 7. Jouer 8. terrain, dés, pion 11. plateau vision Coad&Yourdon: il faut chercher les autres systèmes, les périphériques, les choses et évènements à mémoriser, les rôles joués, les procédures opérationnelles, les sites et unités organisationnelles. checklist C&Y: mémorisation souhaitée, comportement souhaité, multiples attributs, multiples objets, attributs tjs applicables, services tjs applicables, besoins spécifiques, résultats non dérivés simplement (cf PDC->EDT diffusé et si modif)

13 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

14 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)

15 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 nom des classes : éviter les codes, nom clair et représentatif (nommer = modéliser) vocabulaire du domaine

16 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. : - perte d’information : ex vol (si tous les vols annulés, les informations sur les vols sont où ?)

17 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 ? » relation entre 2 classes ou entre 2 instances de ces classes ? nb de relations possibles entre n classes ? n (n-1) / 2 exemples multiplicité : magasin(1) (*) article A B

18 Ajout des associations
* 1..* 1..40 5 zéro ou plus ; plusieurs un ou plus De un à 40 Exactement 5

19 Checklist d’associations courantes
A est une transaction liée à une transaction B (PaiementEnEspèces–Vente) A est un élément d’une transaction B (LigneArticles-Vente) A est un produit pour une transaction B (Article-LigneArticle) A est un rôle lié à une transaction B (Client-Paiement) A est une partie logique ou physique de B (Tiroir-Caisse enregistreuse) A est physiquement ou logiquement contenu dans B (Caisse-Magasin) A est une description de B (DescriptionProduit-Article) A est connu/consigné/enregistré/saisi dans B (Vente-Caisse) A est un membre de B (Caissier-Magasin) A est une sous-unité organisationnelle de B (Rayon-Magasin) A utilise, gère ou possède B (Caissier-Caisse) A est voisin de B (Article-Article) C&Y: assemblage-parties (5), contenant-contenu (6), collection-membres (9) monopoly : 5. 6. case/plateau 8. pion/case 9. joueur/jeu 11. joueur.pion 12. case/case

20 Modèle du domaine TPV avec des associations

21 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 Conseillé Déconseillé

22 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.

23 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) (?) Les attributs dérivés permettent à l’analyste de ne pas faire de choix de conception prématuré

24 Modèle du domaine TPV avec des attributs

25 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

26 Généralisation-spécialisation
Déconseillé 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 Conseillé

27 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é

28 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

29 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

30 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)


Télécharger ppt "Analyse orientée objet (AOO)"

Présentations similaires


Annonces Google