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

Ingénierie Système Analyse orientée objet (AOO) 3/12/2010 Catherine Letondal

Présentations similaires


Présentation au sujet: "Ingénierie Système Analyse orientée objet (AOO) 3/12/2010 Catherine Letondal"— Transcription de la présentation:

1 Ingénierie Système Analyse orientée objet (AOO) 3/12/2010 Catherine Letondal

2 Pourquoi lAOO ? (Coad&Yourdon 1993) meilleur abord des questions du domaine meilleure interaction expert domaine / analyste meilleure cohérence des résultats de lanalyse 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 lanalyse et la conception 2

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

4 Quest-ce quun modèle du domaine ? La quintessence de létape AOO réside dans la décomposition dun 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 danalyse UML - Diagramme de classes 4

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

6 Gestion de la complexité abstraction : ignorer certains aspects non pertinents encapsulation : cacher le détail, montrer lessentiel exprimer et utiliser les similitudes relier les objets 3 méthodes dorganisation 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 dobjets (tous les arbres)

7 Le modèle de domaine ne représente pas dobjets 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é dobjets logiciels, par exemple un modèle dinterfaces utilisateur graphiques Classes avec les attributs typés ou des méthodes (du ressort de la conception) 7

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 dun programme de paie de 1953 : … Modèle logiciel moderne (orienté objet) : 8

9 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

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 10

11 Ex. Terminal Point de Vente (TPV) Cas dutilisation « 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 larticle. 4. Le Système enregistre larticle et présente sa description, son prix et le total en cours. 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

12 Méthode 2 : Utiliser une checklist (catégories de classes prévisibles) 1. Transactions métier (ex. Vente, Paiement) 2. Lignes dune transaction (ex. LigneArticles, LignePanier) 3. Produit ou service lié à une transaction ou à une ligne dune 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 dutilisation (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 dentités (ex. DescriptionProduit, DescriptionLivre) 10. Catalogues (ex. CatalogueProduits, CatalogueLivres) 11. Conteneurs dobjets physiques ou dinformations (ex. Magasin, Panier) 12. Contenu dun 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

13 Méthode 3 : Identifier des groupes nominaux Cette technique consiste à repérer les noms et les groupes nominaux dans la description textuelle dun domaine, et à les considérer comme des classes conceptuelles ou des attributs possibles Les cas dutilisation 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 dautres sources possibles Certains groupes nominaux peuvent devenir des classes conceptuelles, dautres désigner des classes à ignorer lors de cette itération et dautres sont des attributs de classe Point faible de la technique : limprécision du langage naturel Différents groupes nominaux peuvent représenter la même classe conceptuelle ou le même attribut 13

14 Identifier les classes conceptuelles du domaine TPV Liste de classes générée à partir de la liste de catégories et lanalyse 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

15 Identifier les classes conceptuelles du domaine TPV Exclure les objets non pertinents pour le(s) UC pris en compte dans litération courante ex : ticket de caisse : informations déjà dans les autres classes retour darticles pas dans les cas dutilisation pris en compte pour linstant Nom des classes : éviter les codes vocabulaire du domaine noms clairs et représentatifs 15

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 lappliquer ? Lorsque : Des Produits ou Services nécessitent une description La suppression dinstances dune entité quelle décrit (ex. Article) entraîne la perte dune information qui doit être mémorisée Elle réduit la redondance ou la duplication des informations Ex. : 16

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 darticle. « 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 dajouter trop dassociations parce quelles peuvent rendre le diagramme illisible Il sagit dune 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 dune 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 dobjets de la classe B ? » 17 AB

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

19 Checklist dassociations courantes 1. A est une transaction liée à une transaction B (PaiementEnEspèces–Vente) 2. A est un élément dune 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

20 Modèle du domaine TPV avec des associations 20

21 Ajout des attributs Faites figurer les attributs quand les exigences ou les cas dutilisation 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

22 Attribut ou classe ? Lerreur la plus courante lors de la création dun modèle du domaine consiste à représenter quelque chose comme un attribut alors quil devrait sagir dune classe conceptuelle Ex. Le terme suggère une entité doté dexistence juridique, une organisation occupant un espace : Magasin doit donc être une classe conceptuelle. 22

23 Attributs dérivés Lattribut « total » dune 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 lattribut Lattribut « quantité » est également dérivé Ce concept nexistant pas dans les langages objet, le concepteur devra le transformer soit en un attribut « normal », soit en une opération (méthode) 23

24 Modèle du domaine TPV avec des attributs 24

25 Affinement dun modèle du domaine Généralisation-spécialisation Modélisation des changements détat Classes association Agrégation/composition Structuration en packages 25

26 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 lactivité 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

27 Modélisation des changements détat Ne modélisez pas les différents états possibles dun 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

28 Classes association On peut ajouter des attributs à une association via la notion de classe association Ex. attribut « codeVendeur » Les services dautorisation attribuent un code vendeur à chaque magasin pour pouvoir lidentifier lors des transaction Toute demande dautorisation de paiement émise par le magasin doit porter le code Chaque magasin peut avoir autant de codes différents quil utilise de services dautorisation 28

29 Agrégation/composition Une agrégation est un cas particulier dassociation non symétrique exprimant une relation de contenance Les agrégations non 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 lagrégat composite entraîne la destruction de tous ses éléments (le composite est responsable du cycle de vie des parties) Conseils : Abstenez-vous dutiliser lagrégation : une association normale suffit en général La composition est plus utile, mais dans le doute, abstenez-vous aussi 29

30 Conclusion et conseils méthodologiques Il nexiste pas de modèle du domaine correct : tous les modèles sont des approximations du domaine quon essaye de comprendre Le modèle du domaine est un outil danalyse 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 desprit « 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 danalyse existants Ex. ouvrages : Analysis Patterns (Martin Fowler), Data Model Patterns (David Hay), Data Model Ressources Book (Len Silverston) 30


Télécharger ppt "Ingénierie Système Analyse orientée objet (AOO) 3/12/2010 Catherine Letondal"

Présentations similaires


Annonces Google