IFT2251 : Génie logiciel

Transcription

1 Conception détaillée Julie Vachon, Automne 2006 IFT2251 : Génie logiciel Chapitre 5 - Conception Section 1. Conception détaillée orientée objets 1. Qu est-ce que la conception? 2. Objectifs de la conception détaillée 3. Réalisation des cas d utilisation Analyse de robustesse 6. Élaboration des collaborations Règles d attribution des responsabilités 7. Chap.5, Sect.1, p.2 Copyrights Julie Vachon, L activité de conception Étape cruciale du développement logiciel : pont entre l analyse des besoins et l implémentation Activité exigeant de la créativité et de la rigueur. Pas de recette toute faite Il existe des méthodologies (principes et bonnes pratiques) et de bons conseils. Résultat de la phase de conception : une conception (ou un «design») Un bonne conception contribue à la qualité du logiciel : fiabilité, correction, évolubilité, etc. L activité de conception Pont entre la définition des besoins et l implémentation Activité itérative/incrémentale qui transforme les besoins vers le produit final Analyse Conception Décomposition en modules (classes, packages, composants, etc.) Rôle et responsabilités de chaque module Relations entre modules Implémentation Chap.5, Sect.1, p.3 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.4 Copyrights Julie Vachon, 2006

2 L activité de conception Décomposition et raffinement progressif du logiciel en modules de plus en plus détaillés Processus en n étapes : chaque étape (itération) raffine et décompose, en sous-modules, les modules définis à l étape précédente Implémentation étape n Conception bas niveau La décomposition étape 2 se poursuit jusqu à ce qu on obtienne Conception haut niveau étape 1 des modules suffisamment Conception globale «concrets» pour être directement Besoins implémentés Chap.5, Sect.1, p.5 Copyrights Julie Vachon, 2006 Package, composants (use case) Types de conception Conception architecturale (conception de haut niveau, conception globale, «the big picture») Structure et organisation générale du logiciel à concevoir. Description des principaux modules composant le système, des relations entre eux, des contraintes à respecter, des motifs et de la logique de cette décomposition. classe Conception détaillée Description du fonctionnement interne de chacun des modules Étape qui consiste à détailler les résultats de l analyse fonctionnelle, jusqu'à un niveau suffisant pour en permettre finalement le codage dans un langage de programmation Définition de la conception du logiciel respectant le plan de la conception architecturale Chap.5, Sect.1, p.6 Copyrights Julie Vachon, 2006 Architecture logicielle Types de conception «An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behaviror as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subystems, and the architectural style that guides this organization these elements and their interfaces, their collaborations, and their composition.» [Booch, Jaobson and Rumbaugh. The UML specification documents, Rational Software Corp., 1997] Caractéristiques d une bonne conception Une bonne conception = Une bonne décomposition en modules qui favorise Une forte cohésion : les éléments ne sont pas réunis dans un même module par hasard, ils forment un tout pour réaliser une tâche Un faible couplage : les modules sont relativement indépendants, ils ne dépendent pas trop des éléments d autres modules L abstraction et le masquage d information Chap.5, Sect.1, p.7 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.8 Copyrights Julie Vachon, 2006

3 Caractéristiques d une bonne conception Qualités logicielles en jeu Évolubilité : si le logiciel est difficile à changer, les autres qualités sont directement compromises (fiabilité, performance, etc.) Réutilisation : on veut minimiser les coûts et rentabiliser les efforts de développement Principes mis en œuvre Rigueur et formalité Séparation des préoccupations Modularisation Abstraction Anticipation des changements Concevoir pour changer Incrémentalité Famille de produits Chap.5, Sect.1, p.9 Copyrights Julie Vachon, 2006 Tâches de la phase de conception Concevoir et intégrer le réseau Mise en œuvre de la communication entre les processus distribués qui collaborent Concevoir l architecture des applications «Qui» fera «quoi» et «où»? Concevoir les interfaces utilisateurs du logiciel Concevoir et intégrer les bases de données Décrire les détails de la conception Conception détaillée Spécifier ces détails puis les prototyper Concevoir et intégrer les contrôles du logiciel Mise en œuvre de tous les aspects liés au contrôle, à la correction, à la sécurité, à la tolérance aux fautes, à la protection des données, etc. Chap.5, Sect.1, p.10 Copyrights Julie Vachon, Objectifs de la conception détaillée Transformer le modèle d analyse (spécification, haut niveau d abstraction) en un modèle de conception détaillé (implémentation, bas niveau d abstraction, concret, détails techniques) à partir du duquel le programmeur pourra directement implémenter le logiciel + Degré d abstraction - Modèles d analyse Modèles de conception Implémentation (java, etc.) raffinement raffinement Chap.5, Sect.1, p.11 Copyrights Julie Vachon, 2006 Objectifs de la conception détaillée Services (événements) Réalisation des cas d utilisation Modèle d analyse Quoi? Données (éléments) Approche BCE Modèle de conception Comment? : identification des objets servant d interface (boundary), de contrôle (control) ou représentant les données du domaine (entity) Chap.5, Sect.1, p.12 Copyrights Julie Vachon, 2006

4 Réalisation des cas d utilisation Pour chaque cas d utilisation, expliquer en détails comment il sera réalisé La conception détaillé a pour but d associer une collaboration (implémentation) à chaque cas d utilisation Collaboration Ensemble d objets qui coopèrent pour réaliser une tâche Description de la réalisation (l implémentation) d un cas d utilisation (ou d une opération) Plusieurs collaborations (implémentations) peuvent réaliser, de façon différente, un même cas d utilisation (spécification) Effectuer un transfert de fonds Solution X du transfert de fonds Solution Y du transfert de fonds Chap.5, Sect.1, p.13 Copyrights Julie Vachon, 2006 Réalisation des cas d utilisation Collaboration = Description d un arrangement de liens et d objets qui interagissent pour implémenter un comportement spécifié par un cas Partie statique : instanciation des objets, des liens Partie dynamique : envoie de messages, calculs Collaboration peut être décrite Par un diagramme de collaboration (partie statique et dynamique) Par un diagramme de classes (partie statique) et diagramme de séquences (partie dynamique) Etc. Chap.5, Sect.1, p.14 Copyrights Julie Vachon, 2006 Réalisation des collaborations Élément de Spécification (Ex. cas d utilisation) Lien de réalisation Solution d implémentation (Ex. une collaboration) Réalisation = Lien entre un élément décrivant une solution d implémentation et un élément de spécification Élément de spécification = Description du comportement et ou de la structure du logiciel Ex. Interface, classe abstraite, cas d utilisation Élément d implémentation = Explique en détail comment le comportement du logiciel est effectivement implémenté Ex. Classe, composant, collaboration Chap.5, Sect.1, p.15 Copyrights Julie Vachon, 2006 Réalisation des collaborations Quelle est l erreur? Inscrire les étudiants aux cours de B.Sc. informatique L implémentation doit supporter tous les comportements inclus dans la spécification. Consulter la liste des étudiants Ajouter l étudiant aux cours choisis Chap.5, Sect.1, p.16 Copyrights Julie Vachon, 2006

5 pour construire le modèle de conception détaillé Pré-requis provenant du modèle d analyse Diagramme de classes décrivant les données Diagramme de cas d utilisation et leur documentation. Facultatifs mais très utiles Autres diagrammes complétant l analyse : diagramme de séquence ou d activités, diagramme d états. Chap.5, Sect.1, p.17 Copyrights Julie Vachon, 2006 Conception préliminaire Client cliquer login Home page Illustrer les scénarios principal (et secondaires) sur un diagramme de robustesse. entrer les données et cliquer login Boîte de dialoguerappel du mot de passe afficher Page de Login Ouvrir un compte bancaire consulter l'indice de mdp Compte Cas d utilisation: Se logguer Scénario principal: 1. Le client clique sur le bouton «login» de la home page. 2. Le système affiche la page de login Scénarios secondaires: 3.a. Le client clique sur le bouton «nouveau compte» sur page de login: Point d extension «ouvrir_compte» Chap.5, Sect.1, p.18 valider Copyrights Julie Vachon, 2006 Pour faire le design détaillé, pour chaque cas d utilisation, faire les étapes suivantes: Phase 1 Réviser la description détaillée du cas d utilisation, ajouter les détails manquants, s assurer d une documentation complète des scénarios principal et alternatifs. Chap.5, Sect.1, p.19 Copyrights Julie Vachon, 2006 Phase 2 : analyse de robustesse (conception préliminaire) Construire le schéma de robustesse associé au cas d utilisation (se concentrer sur le scénario principal d abord), suivre chacune des étapes du scénario Introduire un objet boundary pour chaque interface (avec l utilisateur, avec un périphérique, avec un système externe, etc.) Introduire un objet control pour chaque tâche à effectuer Introduire un objet entity pour chaque élément de données (c.f. diagramme de classes construit pendant l analyse) Tracer les liens d interactions entre ces objets Réviser le schéma Mettre à jour le diagramme de classes, ajouter les classes d interface identifiées pendant l analyse de robustesse, les attributs des classes si nécessaire Chap.5, Sect.1, p.20 Copyrights Julie Vachon, 2006

6 Phase 3 : élaboration des collaborations, i.e., attribution des responsabilités Construire le diagramme de collaboration ou de séquence Placer les objets interfaces et entités sur le diagrammes (se référer au schéma de robustesse) Pour chaque tâche représentée par un objet control, identifier le(s) message(s) qui doi(ven)t être échangé(s) entre les objets pour réaliser les tâches représentées par les objets control dans le schémas de robustesse Faire correspondre la signature d une opération à chaque message Ajouter les flèches d envois de messages correspondantes dans le diagramme de collaboration ou de séquence Mettre à jour le diagramme de classes : ajouter les opérations identifiées :ObjA toto(m) :ObjB ObjB +toto(integer) Chap.5, Sect.1, p.21 Copyrights Julie Vachon, 2006 Phase 4 : amélioration et révision Utiliser des patrons de conception pour améliorer la conception des collaborations Si nécessaire, compléter la modélisation par des diagrammes d états pour décrire le comportement des instances d une classe donnée en fonction des événements Vérifier la cohérence des informations entre les différents diagrammes : diagramme de classes, schéma de robustesse, diagrammes de collaboration et ou de séquence, description des cas d utilisation, etc. Chap.5, Sect.1, p.22 Copyrights Julie Vachon, 2006 Quelques précisions sur les phases 2 et 3 L analyse de robustesse (conception préliminaire) Phase 2 La réalisation des collaborations Phase 3 Chap.5, Sect.1, p.23 Copyrights Julie Vachon, 2006 Analyse de robustesse Phase 2 Objectifs et avantages Raffinement et validation de la documentation des cas d utilisation : description opérationnelle, réaliste et réalisable? Validation des cas d utilisation: Complets? Corrects? Découverte dynamique des objets participant à la réalisation du cas d utilisation Constitue une étape de conception préliminaire permettant de faire le pont entre l analyse et la conception détaillée (diagrammes d interactions) Chap.5, Sect.1, p.24 Copyrights Julie Vachon, 2006

7 Analyse de robustesse Analyse de robustesse Les objets d interface (boundary) Objets que les acteurs utilisent pour communiquer avec le logiciel Ex. Fenêtre, page web, menus, etc. Les objets entités (entity) Objets qui correspondent aux données du logiciel, ces objets correspondent à des classes identifiées dans le diagramme de classes pendant l analyse, ils seront éventuellement stockés en base de données Les objets contrôleur (control) Éléments liant les objets d interface et les entités Représentent les fonctionnalités du logiciel Ces fonctionnalités seront plus tard attribuées à une interface ou à une entité ou bien on créera réellement un objet contrôleur pour réaliser la fonctionnalité Servent de «boîte» pour être certain de n oublier aucune fonctionnalité requise par le cas d utilisation Chap.5, Sect.1, p.25 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.26 Copyrights Julie Vachon, 2006 Révision du schéma Analyse de robustesse Les interactions entre objets BCE doivent généralement respecter les règles suivantes Les acteurs ne peuvent envoyer de messages qu à des objets boundary Les objets boundary ne peuvent envoyer des messages qu à des objets control et aux acteurs Les objets entity ne peuvent envoyer des messages qu aux objets control Les objets control peuvent envoyer des messages aux objets boundary, control et entity, mais non aux acteurs Chap.5, Sect.1, p.27 Copyrights Julie Vachon, 2006 Analyse de robustesse Associations autorisées Associations interdites Chap.5, Sect.1, p.28 Copyrights Julie Vachon, 2006

8 Schéma de robustesse Retrait bancaire Cas d utilisation : Retrait Acteur principal : Client Déclencheur : le client sélectionne l option «retrait» dans la page principale Pré-conditions : le client a déjà inséré sa carte et son NIP, il a été authentifié par le logiciel et sa fiche client peut être consultée Post-conditions : si le compte sélectionné par le client est actif et si le solde est suffisant, le compte se trouve débité de la somme demandée Chap.5, Sect.1, p.29 Copyrights Julie Vachon, 2006 client Log In Retrait Scénario principal Schéma de robustesse Retrait bancaire Le client sélectionne l option «retrait» dans la page principale Le logiciel affiche la liste des comptes bancaires dont le client est propriétaire et l invite à en sélectionner un Le client sélectionne un des comptes bancaires proposés Le logiciel vérifie que le compte est actif puis affiche une page où il invite le client à saisir le montant de son retrait Le client saisit la somme qu il souhaite retirer Le logiciel vérifie que le solde du compte est suffisant, i.e., qu il est supérieur ou égal au montant du retrait, le cas échéant, le compte est débité de la somme correspondante et l argent est versé dans le bac du distributeur, le logiciel affiche un message confirmant le retrait et invitant le client à récupéré l argent versé dans le bac Scénarios alternatifs Chap.5, Sect.1, p.30 Copyrights Julie Vachon, 2006 Schéma de robustesse Retrait bancaire Page de saisie du montant Page principale Page des comptes bancaires afficher page de saisie montant Vérifier solde suffisant Trouver liste des comptes bancaires afficher liste des comptes vérifier l'état actif du compte fiche client compte bancaire Page avis de retrait Afficher avis de retrait Chap.5, Sect.1, p.31 Copyrights Julie Vachon, 2006 débiter Interface du distributeur de billets verser les billets Analyse de robustesse Révision du schéma En révisant le schéma de robustesse, le concepteur devrait être capable de lire le scénario du cas d utilisation pas à pas et simultanément suivre du doigt les associations sur le schéma Si ça ne correspond pas, faire les corrections nécessaires Chap.5, Sect.1, p.32 Copyrights Julie Vachon, 2006

9 Élaboration des collaborations Phase 3 Objectifs et avantages Attribuer les responsabilités (i.e., les opérations) aux interfaces, contrôleurs et entités Illustrer le détail des interactions sur un diagramme de collaborations ou de séquences Compléter le diagramme de classe en ajoutant les classes, les opérations (et attributs) découverts Étapes Élaboration des collaborations Revoir la documentation des scénarios du cas d utilisation Construire le squelette du diagramme de séquences ou de collaborations à partir du schéma de robustesse Inclure les objets entités et les objets interfaces dans le diagramme d interaction <<boundary>> :ClasseInterfaceX <<entity>> :ClasseEntitéY Chap.5, Sect.1, p.33 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.34 Copyrights Julie Vachon, 2006 Étapes Élaboration des collaborations Chaque objet contrôleur du schéma de robustesse représente une ou plusieurs responsabilités à assigner aux objets du diagramme d interaction, assigner ces responsabilités (i.e., les appels de méthodes) aux objets du diagrammes d interactions Comment décider de l attribution des responsabilités? Voir les règles qui suivent Doit-on ajouter des objets contrôleurs pour la coordination? Oui, pour gérer les événements du logiciel (par exemple ceux générés par les interfaces utilisateurs) Mettre à jour le diagramme de classes en ajoutant les classes et les opérations nouvellement identifiées en construisant le diagramme d interactions Chap.5, Sect.1, p.35 Copyrights Julie Vachon, 2006 Élaboration des collaborations :PagePaiement fairepaiement(m) v : Vente create(m) p : Paiement L objet p de type PagePaiement a pour responsabilité de demander à l objet v de type Vente d enregistrer un paiement de montant m La classe Vente doit donc avoir une opération de signature correspondante : +fairepaiement(integer) Chap.5, Sect.1, p.36 Copyrights Julie Vachon, 2006

10 Règle de l expert Attribution des responsabilités Assigner la responsabilité à la classe qui possède l information nécessaire pour effectuer la tâche Ex. Quel instance possède l information nécessaire (i.e., la longueur des côtés) pour calculer le périmètre d un polygone? Polygone +périmètre():integer 3..n côté longeur : integer Chap.5, Sect.1, p.37 Copyrights Julie Vachon, 2006 Attribution des responsabilités Règle du créateur Assigner à une classe B la responsabilité de créer une instance de la classe A si (entre autres) B est un agrégat d objets de A (agrégation) B contient des instances de type A (composition) B enregistre (ex. v : dans V ente une liste) des instances de type A create(m ) p : P aiem ent La vente B utilise de près les instances de la classe enregistre A les paiements. B possède les données nécessaires pour créer et initialiser les instances de A Chap.5, Sect.1, p.38 Copyrights Julie Vachon, 2006 Attribution des responsabilités Règle du couplage faible Assigner les responsabilités de façon à minimiser le couplage Meilleure solution pour le couplage 1. fairepaiement(m) : PagePaiement v : Vente Attribution des responsabilités Règle de la cohésion forte Assigner les responsabilités de façon à maximiser la cohésion Que penser de la classe ContrôleurCentral? z : Z z a:a : PagePaiement 2. ajouterpaiement(p) v : Vente 1.1. create(m) y : Y x y :contrôleurcentral b:b p : Paiement 1. p:=create(m) p : Paiement Chap.5, Sect.1, p.39 Copyrights Julie Vachon, 2006 x : X Chap.5, Sect.1, p.40 Copyrights Julie Vachon, 2006 c:c À éviter : les classes surchargées d opérations diverses

11 Attribution des responsabilités Règle du contrôleur Assigner la responsabilité de recevoir ou de traiter un événement du logiciel (par exemple les événements produits par les I.U.) À un contrôleur dédié au cas d utilisation (stratégie use case controller) À des gestionnaires définis dans l interface utilisateur (stratégie control in the screen) Recommandé : contrôle indépendant de l interface Chap.5, Sect.1, p.41 Copyrights Julie Vachon, 2006 C. Larman Chap.5, Sect.1, p.42 Copyrights Julie Vachon, 2006 Non recommandé : contrôle dans l interface : Client 1. selectionretrait() Diagramme de séquence Retrait bancaire : PagePrincipale L'acteur interagit ici avec le système via des appels synchrones, puisqu'il doit attendre la réponse du système pour poursuivre. On aurait pu choisir de représenter ces messages de l'acteur par des messages asynchrones (la numérotation aurait alors été différentes.) :PageComptes Bancaires 1.1. debutretrait() On suppose ici que les interfaces fonctionnent en mode procédural et qu'elles se bloquent pendant le traitement par le contrôleur create() affichercomptes(listecmptes) :Contrôl eur du Retrait l:=getlistecomptes() f :Fiche Client c :Compte bancaire :InterfaceDistributeur De Billets On suppose ici que le(s) compte(s) bancaire(s) et la fiche client sont déjà en mémoire vive: ils ont déjà été récupérés de la base de données. 2. selectioncompte() 2.1. comptesélectionné(i) actif?() :PageSaisieDu Montant create() affiche() 3. entrermontant(m) 3.1. montantsaisi(m) fondssuffisants?(m) distribuerbillets(m) :PageAvis Retrait create() afficher() Chap.5, Sect.1, p.43 C. Larman Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.44 Copyrights Julie Vachon, 2006

12 Attribution des responsabilités Les patrons de conception Assigner les responsabilités en suivant les recommandations d un patron de conception Solution générique (donc réutilisable!), proposant une «bonne façon» de résoudre un problème de conception (ex. Attribuer les responsabilités ) dans un contexte donné Qu est-ce qu un patron de conception? «Une solution à un problème dans un contexte» Contexte = Ensemble de situations récurrentes dans lesquelles le patron s applique Problème = Ensemble de buts et de contraintes qui se présentent dans le contexte. Solution = Motif de conception canonique ou règle de conception qui peut être utilisé pour résoudre le problème Micro-architecture réutilisable qui décrit les structures statiques et dynamiques des collaborations entre les éléments du patron Chap.5, Sect.1, p.45 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.46 Copyrights Julie Vachon, 2006 Utilité Partager et de réutiliser l expertise en conception et le savoirfaire Outil de documentation Moyen de communication conceptuelle Outil pédagogique, diffusion des connaissances en conception Les patrons de Gamma et al. (GoF), trois catégories Création : solutions pour de créer des instances de façon flexible Structure : solutions permettant d organiser l agencement structurel d un ensemble de classes, d instance de façon à en faciliter la maintenance Comportement : solutions permettant d organiser les interactions d un ensemble d instances de façon efficace et maintenable Exemple Serveur de fichiers distant Serveur de fichiers root Java LaTeX Documents bin source new Chap.5, Sect.1, p.47 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.48 Copyrights Julie Vachon, 2006

13 Exemple Serveur de fichiers distant Patron Observateur Structure statique Les contraintes L identité et le nombre de receveurs ne sont pas connus à l avance De nouvelles classes de receveurs pourraient s ajouter au logiciel Le sondage (polling) inapproprié, i.e., impossible ou trop coûteux avec un grand nombre de receveurs Solution? Patron de conception Observer «abstract» Subject notify() attach(observer) detach(observer) ConcreteSubject subjectstate getstate() setstate() 1 * observer For all o in observers { o. } subject return subjectstate «abstract» Observer Update() ConcreteObserver observerstate observerstate = subject.getstate() Chap.5, Sect.1, p.49 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.50 Copyrights Julie Vachon, 2006 Patron Observateur Structure dynamique Patron = Collaboration Des objets qui interagissent pour accomplir une tâche! ConcreteSubject ConcreteObserver1 ConcreteObserver2 set_state() ServeurFichier observer Ordinateur 1: notify() getfiletree() 1.1: 1.1.1: get_state() subject 1.2: 1.2.1: get_state() Observer PC Mac Chap.5, Sect.1, p.51 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.52 Copyrights Julie Vachon, 2006

14 Patron = Collaboration Valeurs des données getvalues() subject Observer Tableur observer Affichage Histogramme Graphique circulaire Documentation Si Vous vous trouvez dans ce [contexte] Par exemple [exemples] Aux prises avec ce [problème] Impliquant ces [buts et contraintes] Alors Pour ces [raisons] Appliquer ce [patron de conception] et ou [règle] suivants Pour construire cette [solution] Conduisant à ce [nouveau contexte] et [autres patrons] Chap.5, Sect.1, p.53 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.54 Copyrights Julie Vachon, 2006 Documentation d un patron: Nom du patron Objectif Autres noms Motivation Applicabilité Structure Participants Collaborations Conséquences Implémentation Exemple de code Utilisations connues Patrons connexes Patrons comportementaux (behavioral patterns) Patrons structuraux (structural patterns) Patrons créateurs (creational patterns) Chap.5, Sect.1, p.55 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.56 Copyrights Julie Vachon, 2006

15 Patrons comportementaux Utilité générale Algorithmes et à attribution des responsabilités aux classes et à leurs instances Patrons du GoF Chaîne de responsabilité Commande Interpréteur Itérateur Médiator Mémento Observateur State Stratégie Méthode modèle Visiteur Utilité générale Patrons structuraux Spécifier comment les classes et leurs instances sont associées pour former de plus grandes structures Patrons du GoF Adaptateur Pont Composite Décorateur Façade Poids léger Mandataire Chap.5, Sect.1, p.57 Copyrights Julie Vachon, 2006 Chap.5, Sect.1, p.58 Copyrights Julie Vachon, 2006 Patrons créateurs Utilité générale Découpler la connaissance du type d une instance (quoi) du processus de création de cette instance (quand et comment) Patron du GoF Usine abstraite Constructeur Méthode usine Prototype Singleton Chap.5, Sect.1, p.59 Copyrights Julie Vachon, 2006