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

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 *

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

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

Recours à des services tiers externes

Polymorphisme

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

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

Singleton classe qui ne produit qu’une instance unique

Ex. de calcul de taxes

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 ;

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

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

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

Pattern Composite

Facade (d’un sous-système)

Façade IHM (push-from-below)

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

Autre affichage total Affichage total code articles etc.

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

L’observateur FrameVente souscrit auprès du diffuseur vente

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

Autres diagrammes UML

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

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)

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

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

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 »

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

Communs divers

Ventes utilise core:register et core:store

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

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)

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

Réduire couplage avec Fabrique

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

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

Déploiement d’une architecture 3-tier