Conception 2 users.info.unicaen.fr/~ionona/gl2009

Présentation au sujet: "Conception 2 users.info.unicaen.fr/~ionona/gl2009"— Transcription de la présentation:

1 Conception 2 users.info.unicaen.fr/~ionona/gl2009

2 Visibilité d’un objet B par un objet A
Pour que A puisse envoyer un message à B, il faut que B soit visible par A CatalogueProduit Registre dP=getDescriptionProduit(codeArticle) Registre CatalogueProduit 1 *

3 Types de visibilités (durée de vie)
Visibilité d’attribut. B est un attribut de A. dv : tant que A et B existent Visibilité de paramètre. B est un paramètre d’un méthode de A. dv: celle de la méthode Visibilité locale. B est une variable locale d’une méthode de A. Dv: celle de la méthode Visibilité globale. B est visible par tous les objets. Dv: tant que A et B existent

4 Services externes dotés d’interfaces différentes
Le système doit se connecter à des services tiers externes: Calculateur de taxes, service de comptabilité, Autorisation de crédit Mais pour chaque type de service peut exister différents fournisseurs tiers avec son API propre chacun (différent mais stable) Ex. Il existe calculateurTaxe1, calculateurTaxe2, calculateurTaxe3

5 Recours à des services tiers externes

6 Polymorphisme

7 Fabrique concrète (Factory)
Quel objet crée les adaptateurs de services ? Un objet du domaine ? Registre ? Non car diminue la cohésion Séparer les attributions, chaque classe a un objectif cohérent Construire un objet Fabrication pure nommée FabriqueConcrete pour gérer la création

8 Qui crée l’objet FabriqueDeServices ?
De combien d’instances de FabriqueDeServices a-t-on besoin ? Comment s’assurer que getInstance() soit visible partout ?

9 Singleton classe qui ne produit qu’une instance unique

10 Ex. de calcul de taxes

11 Comment choisir l’adaptateur à créer ?
Chargement dynamique de la classe Le nom de la classe étant enregistré dans un fichier de configuration système IAdaptateurCalculTaxes getAdaptateurCalculTaxes{ if ( adaptateurCalculTaxes1 == null ) { String className = System.getProperty( "calculateurTaxes.class.name" ); adaptateurCalculTaxes= (IAdaptateurCalculTaxes) Class.forName( className ).newInstance(); } return adaptateurCalculTaxes1 ;

12 Algorithmes variables mais apparentés
Stratégie Pb: les politiques de tarification sont variables mais apparentés, pouvant évoluer Sol: définir chaque algorithme, politique, stratégie dans une classe distincte mais avec une interface commune

13 Ex de tarification composite
Réduction 15% le mercredi Réduction 5% pour cartes privilèges sur toute vente supérieur à 200 euros Réduction fixe de 20 euros le lundi pour toute vente supérieure à 500 euros Tarification nombreuse et conflictuelle pouvant coexister

14 Solution partielle: définir une stratégie de résolution de conflit: ex
Solution partielle: définir une stratégie de résolution de conflit: ex. politique la « plus avantageuse pour le client » si … alors Tarification peut dépendre Du type de client Du type du produit

15 Pattern Composite

16 Facade (d’un sous-système)

17 Façade IHM (push-from-below)

18 Modèle de délégation d’événements
Diffusion-souscription Observateur (souscripteur, auditeur) - observable (diffuseur) Pb: différents types d’objets souscripteurs (observateurs) sont concernés par les changements d’états et les événements diffuseurs (observable) et veulent réagir chacun à leur manière lorsque le diffuseur génère un événement De plus, le diffuseur veut maintenir une faible couplage avec les souscripteurs Solution: définir une interface « souscripteur » ou « listener ». Les souscripteurs implémentent cette interface. Le diffuseur peut enregistrer dynamiquement les souscripteurs intéressés par un événement et le leur signaler Le diffuseur délègue le traitement de l’information au souscripteur

19 Autre affichage total Affichage total code articles etc.

20 Couche présentation- couche domaine
souscripteurs :vente1 :vente1 :vente1 diffuseurs :vente1 Serveur

21 L’observateur FrameVente souscrit auprès du diffuseur vente

22 La vente diffuse un événement à l’intention des souscripteurs

23 Autres diagrammes UML

24 Diagrammes d’états Objet état-indépendant: répond toujours de la même manière à un événement Objet état-dépendant: réagit différemment aux événements selon leur état

25 Machines à états Utiliser pour objets réactifs à comportement complexe
Équipements physiques controlés par logiciels Transaction et objets métiers (vente, commande, paiement) Objets qui changent de rôle. Ex Personne civile devient militaire Protocoles et séquences légales Flots page/fenêtre IHM Contrôleur flots ou session d’une interface utilisateur Opérations systèmes des cas d’utilisations (ex. creerPaiement ne peut survenir avant fin vente)

26 déf Événement: occurrence d’un fait significatif ou remarquable
État: condition d’un objet à un moment donné, y demeurre jusqu’à arrivée nouvel événement Transition: relation entre deux états indiquant que l’objet change d’état lorsqu’un événement se produit

27 exercice Dessiner un diagramme d’états de la séquence légale des opérations du CU « traiter une vente »

28 Diagramme de package Dépendances entre packages:
Package : unité de de base de développement et de livraison Emboitables Dépendances entre packages: Ventes et Payements font appel à des éléments de « concepts communs »

29 Partitionner Modèle du domaine en package
Regrouper les: Les éléments situés dans le même domaine (étroitement liés par leur concept ou leur vocation) Éléments situés dans la même hiérarchie de classes Éléments participant aux mêmes cas d’utilisation Éléments fortement associés

30 Communs divers

31 Ventes utilise core:register et core:store

32 Conception packages Organiser en partitions verticales et horizontales fonctionnellement cohésives Packager une famille d’interfaces dans un package distinct de ceux des implémentations Créer un package par tâche et par groupe de classes instables Ex si P1 contient 40 classes dont 10 instables Alors scinder P1 en 2: P1-a et P1-b

33 Conception package Les packages les plus responsables (qui engendrent les plus de dépendances) doivent être les plus stables Factoriser les types (classes, interfaces) indépendants pour être réutilisés ( peut être division par fonctionnalité n’offre pas granularité suffisante)

34 Conception package Utiliser des Fabrications pour limiter la dépendance aux packages concrets Ex objet Registre et PayementMapping créent PayementCredit Crée dépendance entre un objet et son créateur

35 Réduire couplage avec Fabrique

36 Pas de cycles dans les packages
Factoriser les types qui participent aux cycles dans un nouveau package plus petit Rompre le cycle à l’aide d’une interface Exercice

37 Diagramme de déploiement
une vue statique représentant utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Utilise des nœuds (physiques, environnement d’exécution) les composants, les associations entre eux

38 Déploiement d’une architecture 3-tier