Conception 2users.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

Registre CatalogueProduit

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

AdaptateurCalculTaxes1AdaptateurCalculTaxes2

IAdaptateurCalculTaxes

getTaxes(v : vente)

<<Interface>>Registre

0..n1 0..n1

AdaptateurCalculTaxesFutur

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

FabriqueServicesadaptateurCalculTaxes : IAdaptateurCalculTaxesadaptateurCompta : IAdaptateurCompta

getAdaptateurCalculTaxes()getAdaptateurCompta()

Qui crée l’objet FabriqueDeServices ?

• De combien d’instances de

FabriqueDeServices a-t-on besoin ?

• Comment s’assurer que getInstance() soit

visible partout ?

Singletonclasse qui ne produit qu’une instance unique

FabriqueServices<<static>> instance : FabriqueServicesadaptateurCalculTaxes : IAdaptateurCalculTaxesadaptateurCompta : IAdaptateurCompta

<<static>> getInstance()getAdaptateurCalculTaxes()getAdaptateurCompta()

<<singleton>>

// static methodpublic static synchronized FabriqueDeServices getInstance(){if ( instance == null )instance := new FabriqueDeServices()return instance}}

Ex. de calcul de taxes

: Magasin : Magasin : Registre : Registre : FabriqueServices : FabriqueServices

: AdaptateurCalculTaxes2 : AdaptateurCalculTaxes2

initialiser

getAdaptateurCalculTaxes()

create

getTaxes(vente)

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. politique la « plus avantageuse pour le client »si … alors

• Tarification peut dépendre• Du type de client• Du type du produit

Pattern Composite

Strategie PourcentageRemise

getTotal(v : vente)

strategie RemiseParDate

getTotal(v : vente)

strategieComposite orienteeClient

getTotal(v : vente)

strategieComposite orienteeMagasin

getTotal(v : vente)

ventedate

getTotal()

strategie tarificationComposite

getTotal(v : vente)ajouter(s : IStrategieTarification)

IStrategieTarification

getTotal(v : vente)11 1..n

+strategies

1..n

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

Affichage totalcode articlesetc.

Autre affichage total

Couche présentation- couche domaine

Serveur

:vente1:vente1 :vente1

:vente1

souscripteurs

diffuseurs

L’observateur FrameVente souscrit auprès du diffuseur vente

: Registre : Registre

fmv : FrameVente

fmv : FrameVente

v : ventev : vente auditeursDePropriétés[i] : auditeurDePropriétés

auditeursDePropriétés[i] : auditeurDePropriétés

initialiser(v: vente)

ajouterAuditeurDeProprietes(fmv)

ajouter(fmv)

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

: vente : venteAuditeursDePropriétés[i] :

auditeurDePropriétésAuditeursDePropriétés[i] :

auditeurDePropriétés

setTotal(ntotal)

diffuserEvenementProprietes("vente.total", ntotal)

*[i=1...n] evenementSurPropriete(v, "vente.total", ntotal)

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

Package : unité de de base de développement et de livraisonEmboitablesDé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 instablesAlors 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éploiementune 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