Ingénierie Système Introduction à l analyse et et à la conception orientée objet 1 Catherine Letondal catherine.letondal@enac.fr 05/12/2013
Objectifs pédagogiques Une 1 ère compréhension de l analyse orientée objet ses raisons, ses objectifs Modélisation du domaine d une application trouver les classes et leurs relations application en TP (2h) : jeu de monopoly dossier IS : système de gestion de la scolarité pour l ENAC UML : aperçu de la notation 2
Objectifs pédagogiques définir de façon exhaustive les caractéristiques techniques formaliser les besoins 35 30 25 20 15 10 5 0 définir l'usage Analyse fonctionnelle Conception participative Analyse orientée objet susciter la coévolution besoinssolution 3
Bibliographie Craig Larman Coad & Yourdon Martin Fowler 4
Qu est-ce que l analyse et la conception? L analyse met l accent sur l investigation du problème et des besoins : Analyse objet : compréhension des concepts du domaine métier Analyse des besoins : fonctions, cas d utilisation La conception élabore une solution répondant aux besoins à partir de l analyse L analyse pour construire le bon système et la conception pour construire bien le système (make the right thing vs make the thing right) 5
Qu est-ce que l analyse et la conception orienté objet (A/COO)? Analyse OO : recherche et description des classes conceptuelles (concepts) du domaine et de leurs relations Ex. bibliothèque : ouvrage, prêt, catalogue un prêt concerne un ouvrage un catalogue liste des ouvrages Conception OO : spécification des classes logicielles à partir de ces concepts, et de la façon dont leurs instances collaborent pour satisfaire les besoins utilisateurs Ex. l objet logiciel «Livre» a un attribut «titre : String» et une méthode «getchapitre() : Chapitre» 6
Produits de l A/COO La conception doit produire la spécification d une solution implémentable Spécification faite de plus en plus en utilisant des modèles graphiques (diagrammes UML) Un modèle de l A/COO = ensemble diagrammes UML + éléments du diagramme (classes, cas d utilisation, objets, etc.) + documents textuels 7
Notation UML Standard OMG très répandu dans l industrie Né de la fusion de notations de plusieurs méthodes Langage visuel qui permet l élaboration de modèles Notation très vaste UML 2 : 13 diagrammes différents UML n est pas une méthode Méthode = notation (ex. UML) + processus de développement + outils L utilisation concrète d UML dépend du processus de développement choisi par le chef du projet 8
Perspectives d utilisation UML UML peut être utilisé pour modéliser depuis plusieurs perspectives Point de vue conceptuel Les diagrammes sont interprétés comme décrivant des entités du monde réel ou du domaine d intérêt Point de vue des spécifications (logicielles) Les diagrammes décrivent des composants logiciels sans préciser une implémentation Point de vue de l implémentation Les diagrammes décrivent les implémentations logicielles dans une technologie particulière (Java, C++, ) 9
Une «classe» dans les différentes perspectives Monde réel Analyse Livre titre auteur 1 * Chapitre titre Point de vue conceptuel (modèle du domaine) Diagramme de classes servant à visualiser les concepts du monde réel Conception Livre titre : String auteur : string gettitre() : String getauteur : String getchapitres : List<Chapitres> * Chapitre titre : String gettitre() : String Point de vue des spécifications ou de l'implémentation (diagramme de classes de conception) Diagramme de classes servant à visualiser les éléments logiciels Codage public class Livre { private String titre; private String auteur; private List<Chapitre> chapitres; public class Chapitre { private String titre;... } Code Java élaboré à partir de la spécification logicielle (classes conception) 10 } gettitre() { return titre; }...
Façons d appliquer UML (I) UML en mode esquisse (sketching) Diagrammes informels et incomplets (souvent tracés à la main) créés pour expliciter un problème ou pour explorer une solution UML en mode plan (blueprint) Diagrammes de conception détaillés pour la pro-ingénierie (génération de code à partir des diagrammes) ou rétroingénierie (génération des diagrammes à partir du code) La génération de code n est que partielle Le développeur doit compléter (et parfois corriger) le code généré 11
Façons d appliquer UML (II) UML comme langage de programmation Spécification complète et exécutable d un système logiciel en UML Code exécutable généré automatiquement à partir des modèles UML qui n a pas besoin d être revu ni modifié par les développeurs Requiert des outils UML puissants et des diagrammes très détaillés Toujours en cours de développement en termes de théorie, de robustesse d outils et de facilité d utilisation 12
UML en mode esquisse ne pas hésiter à dessiner, discuter autour d un tableau blanc (+ photos) les diagrammes servent à réfléchir et visualiser : ils peuvent être partiels 13
UML mode blueprint ou programmation bouml.free.fr 14
Processus de développement Vu le nombre d activités possible entre l analyse des besoins et l implémentation, comment une équipe de développeurs doivent-ils procéder? Les activités A/COO doivent s inscrire dans le contexte d un processus de développement Beaucoup de processus existants : Processus classiques : cascade, cycle en V Processus Unifié (UP) : RUP, 2TUP, Processus agiles : extreme programming, Scrum, 15
Etude de cas A/COO avec UML Gestion du panier d une librairie web http://www.dotnetguru.org/articles/uml/agile2/modelisation-agile.html http://www.dotnetguru.org/articles/uml/agiledotnet2.htm 16
Besoins Le site doit permettre aux internautes de : rechercher des ouvrages par thème, auteur, mot-clef, etc., se constituer un panier virtuel, puis de pouvoir les commander et les payer directement sur le Web. Nous nous restreindrons à la fonctionnalité de gestion du panier virtuel. 17
A/COO avec UML (UP agile) Analyse objet Analyse de besoins Conception objet 18
Modèle de cas d utilisation Description du UC «Gérer son panier» Préconditions : néant. Scénario nominal : 1. L Internaute enregistre les ouvrages qui l intéressent dans un panier virtuel (voir le cas d utilisation Rechercher des ouvrages). 2. L Internaute demande l accès à son panier. 3. Le Système lui affiche l état de son panier. Chaque ouvrage qui a été préalablement sélectionné est présenté sur une ligne, avec son titre, son auteur et son numéro ISBN. Son prix unitaire est affiché, la quantité est positionnée à «1» par défaut, et le prix total de la ligne est calculé. Le total de la commande est calculé par le Système et affiché en bas du panier avec l indication des frais de port. 4. L Internaute valide son panier en demandant à effectuer une commande. Extensions 3-4a. Le panier est vide 1. Le système affiche un message d erreur à l Internaute («Votre panier est vide!») et lui propose de revenir à une recherche d ouvrage. 4a. L Internaute modifie les quantités des lignes du panier, ou en supprime. 1. L Internaute revalide le panier en demandant le recalcul du total 2. Le Système met à jour le total calculé du panier et le cas d utilisation reprend à l étape 4 du scénario nominal. 4b. L Internaute effectue une nouvelle recherche d ouvrage (voir le cas d utilisation correspondant). 1. Le cas d utilisation reprend à l étape 1 du scénario nominal. Exigences non-fonctionnelles 19 Le panier de l internaute est sauvegardé pendant toute la durée de sa visite sur le site Web.
Modèle de cas d utilisation Diagramme de séquence système (DSS) Modélise la séquence d interactions acteur-système correspondant à un scénario d un UC («Gérer son panier») Identifie les événements auxquels le système doit réagir Le système «jebouquine.com» est représenté comme une boîte noire : Les classes implémentant la fonctionnalité sont identifiées plus tard (modèle conception) 20 UML - Diagramme de séquence
Modèle du domaine Diagramme de classes conceptuel En analysant la description du UC «Gérer son panier», on identifie les concepts métier, comme «Panier», «Livre»,... On modélise ces concepts sous forme de diagrammes de classes contenant uniquement des attributs et des associations On n identifie pas d opérations (à attendre à la conception) UML - Diagramme de classes 21
Modèle de conception Conception préliminaire - Architecture Architecture modulaire Présentation, interactions : classes IHM Logique applicative, dialogue : isole l IHM de la complexité de la couche métier Logique Métier : classes métier Stockage : responsable de la persistance des objets en BD ou fichiers Cours A/COO Architecture en couches UML Diagramme de packages 22
Modèle de conception Diagrammes séquence conception (DSC) Le système est composé de plusieurs classes Les opérations des classes sont identifiées Les objets collaborent avec l envoi de messages afin d implémenter les opérations système (ex. supprimerligne() ) 23 DSS DSC
Modèle de conception Diagrammes séquence conception (DSC) A faire en parallèle avec les diagrammes de classe conception (DCC) DSC surtout utile pour les opérations complexes 24 DSS DSC
Modèle de conception Diagrammes classe conception (DCC) A réaliser en parallèle avec les DSC Créer les classes de conception métier et applicatives (présentation, dialogue) dans les packages UML de l architecture Classes métier créées à partir des classes du modèle du domaine Ajouter les opérations aux classes correspondantes aux messages des DSC Affiner les associations (indication de navigabilité, ajout de dépendances, ) Ajouter des types aux attributs En fonction du nombre de classes, un ou plusieurs DCC pour chaque package de l architecture 25 3 DCC
Soyez agile et itératifs! Les description des cas d utilisation et des diagrammes UML ne sont jamais parfaits Ne pas adopter l attitude du processus en cascade en déployant toujours plus d effort pour obtenir des spécifications exactes et exhaustives Entre la démarche en cascade et la «programmation sauvage» existe le développement itératif et incrémental Dans cet approche, les différents modèles sont progressivement affinés, vérifiés et clarifiés grâce à la programmation et aux tests 26
Ingénierie Système Analyse orientée objet (AOO) Catherine Letondal catherine.letondal@enac.fr 05/12/2013
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- transi/on (classes complexes) + organisa/on classes en packages UML 3
Qu est-ce qu un modèle du domaine? La quintessence de l étape AOO réside dans la description des concepts fondamentaux du domaine, et de leurs relations. Une classe représente un concept, c-a-d la description abstraite d un ensemble d objets ex : la classe Livre représente les livres Les classes contiennent les attributs pertinents au domaine Ex : le prix d un livre Ex : on s en fiche de la couleur du livre Synonymes : modèle du domaine modèle conceptuel modèle objet du domaine 4 modèle objet d analyse
Le modèle du domaine est un dictionnaire visuel Un modèle du domaine est une représentation visuelle des concepts dans un domaine donné, avec un diagramme de classes UML qui met en relation les termes ou concepts du domaine 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 UML - Diagramme de classes 5
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) : Monde réel Point de vue conceptuel (modèle du domaine) Livre titre auteur 1 * Chapitre titre Diagramme de classes servant à visualiser les concepts du monde réel Livre titre : String auteur : string gettitre() : String getauteur : String getchapitres : List<Chapitres> * Chapitre titre : String gettitre() : String Point de vue des spécifications ou de l'implémentation (diagramme de classes de conception) Diagramme de classes servant à visualiser les éléments logiciels 6 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)
Gestion de la complexité abstraction : ignorer certains aspects non pertinents encapsulation : cacher le détail, le volatile exprimer et utiliser les similitudes relier les objets la modélisation utilise 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)
Comment procéder pour créer un modèle du domaine? 1. Identifier les concepts (ou objets) du domaine (classes conceptuelles) 2. Identifier les relations entre les objets (associations) 3. Identifier les caractéristiques significatives des objets (attributs) 8
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 Les attributs typés ou les méthodes (du ressort de la conception) 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. 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. Actions ou transactions métier (ex. Vente, Paiement) 2. Lignes d une transaction (ex. LigneArticles, LignePanier) 3. Produit ou service lié à une action/transaction ou à une ligne d une transaction (ex. Article, Livre) 4. Où l action est-elle enregistrée? (ex. Caisse enregistreuse, Panier) 5. Rôle des personnes ou des organisations liées à l action; acteurs dans les cas d utilisation (ex. Internaute, Client) 6. Lieu de l action; 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. Descriptions d entités (ex. DescriptionProduit, DescriptionLivre) 10. Catalogues, listes (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. Documents financiers, contrats, documents 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), 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 Points faibles 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 Certains concepts apparaissent comme des verbes et certains groupes 13 nominaux sont des substantivations
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), 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 : nommer est une activité de modélisation é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 avec les informations supplémentaires (parfois appelée métaclasse) Quand faut-il l appliquer? Lorsque : Ex. : 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 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 s agit d une relation significative du point de vue conceptuel : pas de flot de données, de fonction, d interaction ponctuelle 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?» A B 17
Ajout des associations * zéro ou plus ; plusieurs 1..* 1..40 5 un ou plus De un à 40 Exactement 5 18
Checklist d associations courantes 1. A est une action liée à une action B (PaiementEnEspèces Vente) 2. A est un élément d une action B (LigneArticles-Vente) 3. A est un produit pour une action B (Article-LigneArticle) 4. A est un rôle lié à une action 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 Conseillé 21 Déconseillé
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ée 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 26 Déconseillé Conseillé
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. association «autoriser paiement» Les services d autorisation attribuent un code vendeur à chaque magasin pour pouvoir l identifier lors des transactions 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 28 services d autorisation
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 : 29 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
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
Ingénierie Système Vers la conception objet Catherine Letondal catherine.letondal@enac.fr 05/12/2013
La conception objet dans la démarche A/COO on a un modèle du domaine, on a des fonctions : et ensuite...? allouer des responsabilités aux classes trouver les classes logicielles décrire leurs interactions Conception objet + organisation classes en packages UML (composants) = Architecture logique
Modèles statiques et modèles dynamiques Il existe deux sortes de modèles objet : dynamiques et statiques Les modèles dynamiques comme les diagrammes séquence : Aident à concevoir la logique comportementale, le corps des méthodes dans le code Tendent à être les plus difficiles et les plus intéressants à créer Les modèles statiques tels que les diagrammes de classe ou de packages : Permettent de définir les packages, les noms de classes, les attributs et les signatures des méthodes, mais pas le corps de celles-ci Modèle dynamique Modèle statique
Diagrammes de séquence de conception (DSC) UML fournit des diagrammes d interaction qui permettent de représenter la façon dont les objets interagissent via des messages On les utilise dans le cadre de la modélisation dynamique On va présenter succinctement la notation des diagrammes de séquence qui sont les diagrammes dynamiques les plus utilisés public class A { private B monb = new B(); public void messageun() { monb.messagedeux(); monb.messagetrois(); } }
Lien entre diagramme de séquence et modèle de classes
Conception pilotée par les responsabilités (CPR) Nous pouvons penser la conception des objets logiciels (et des composants à plus grand échelle) en termes de responsabilités, de rôles et de collaborations Ces notions font partie d une approche plus vaste nommée conception piloté par les responsabilités (CPR) Dans le CPR, les objets ont deux types de responsabilités : savoir et faire Les responsabilités de faire d un objet peuvent être : Faire quelque chose lui-même, par exemple créer un autre objet ou effectuer un calcul Déclencher une action d un autre objet Contrôler et coordonner les activités d autres objets Les responsabilités de savoir d un objet peuvent être : Connaître les données privées encapsulées Connaître les objets connexes Connaître des éléments qu il peut dériver ou calculer
CPR (suite) Les responsabilités sont affectées aux classes d objets lors de la conception objet Ex. Vente a la responsabilité de créer les objets de la classe LigneArticles (faire) et connaître son total (savoir) Les objets du domaine inspirent souvent les responsabilités liées au «savoir» (à partir des attributs) La traduction des responsabilités en classes et méthodes est influencée par la granularité de celles-ci Ex. la responsabilité «fournir un accès à une BD relationnelle» peut nécessiter deux cents classes et des milliers de méthodes En revanche, la responsabilité de «créer une Vente» ne demandera peut-être qu une seule méthode dans une seule classe
Cartes CRC
Cartes CRC