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

1. Conception 2users.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. Singletonclasse 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 • IAdaptateurCalculTaxesgetAdaptateurCalculTaxes{ • 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. 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 totalcode articlesetc.

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