Analyse et conception orientée objet

Transcription

1 11 Analyse et conception orientée objet Au sommaire de ce chapitre Comment utiliser l analyse orientée objet pour comprendre le problème à résoudre Comment obtenir, grâce à la conception orientée objet, une solution robuste, extensible et fiable Comment documenter l analyse et la conception de vos applications à l aide de UML (Unified Modeling Language) À force de se concentrer sur la syntaxe du langage C++, on risque de perdre de vue l importance de ces techniques de construction des programmes.

2 322 Le langage C++ Les modèles L objectif d un modèle est de créer une abstraction significative du monde réel. Cette abstraction doit être plus simple que la réalité, mais aussi la refléter fidèlement afin que le modèle puisse servir à prévoir le comportement des choses dans la réalité. Un globe terrestre posé sur un bureau en est un exemple classique. Le modèle n est pas la Terre elle-même et il ne risque pas d être confondu avec la chose réelle. Cependant l un est une représentation suffisamment fidèle de l autre pour nous permettre l apprentissage de la Terre en étudiant le globe. Il y a, bien sûr, des simplifications importantes : il ne pleut jamais sur le globe de mon fils et il n est pas sujet aux marées, aux tremblements de terre, etc. Cependant, je peux l utiliser pour prévoir le temps qu il me faudra pour me rendre de chez moi à New York. Un modèle qui ne serait pas plus simple que ce qu il représente ne serait pas d une grande utilité. La conception orientée objet impose la construction de modèles efficaces, elle met en jeu deux éléments importants : un langage et un processus de modélisation. Conception : le langage de modélisation Le langage de modélisation est l aspect le moins important de l analyse et la conception orientée objet, mais c est malheureusement à lui que s intéressent principalement la plupart des gens. Un langage de modélisation n est rien de plus qu une convention permettant de définir un modèle sur un autre support papier ou système informatique et dans un autre format comme les graphiques, le texte ou les symboles. Rien ne nous empêche, par exemple, de représenter nos classes sous la forme de triangles et la relation d héritage comme une ligne pointillée. Vous pourriez alors modéliser un géranium comme sur la Figure Cette figure montre qu un géranium est une sorte particulière de fleur. Tant que nous sommes d accord sur cette représentation du concept d héritage (généralisation/spécialisation), nous nous comprendrons parfaitement. Au cours du temps, nous voudrons sûrement modéliser de nombreuses relations complexes et nous développerons donc nos propres conventions et règles pour nos diagrammes. Il reste bien entendu à faire connaître ces conventions à toutes les personnes qui travaillent avec nous et à les apprendre aux nouveaux venus. Si nous collaborons avec d autres sociétés qui utilisent leurs propres conventions, nous devrons alors mettre en place une convention commune de manière à éviter les malentendus inévitables.

3 Chapitre 11 Analyse et conception orientée objet 323 Figure 11.1 Généralisation/ spécialisation. Fleur Géranium Il serait encore plus pratique d avoir recours à un langage commun défini une fois pour toutes. Le langage universel en matière d analyse et de conception logicielle s appelle UML (Unified Modeling Language). Son rôle est de répondre à des questions comme "Comment représenter une relation d héritage?". En UML, le géranium de notre exemple aurait ainsi été représenté par la Figure Figure 11.2 Représentation UML de la spécialisation. Fleur Géranium En UML, les classes sont représentées par des rectangles et l héritage sous la forme d une flèche partant de la classe la plus spécialisée vers la plus générale. Le sens de cette flèche peut sembler peu intuitif, mais il n a pas vraiment d importance ; l essentiel, après avoir appris la représentation, consiste à utiliser une convention commune pour communiquer. Les détails de UML sont assez simples. Les représentations schématiques sont généralement assez faciles à comprendre et à appliquer et vous les apprendrez à mesure que nous les présenterons. Bien qu il soit possible d écrire un livre entièrement consacré à UML, la vérité est que l on n en utilise la plupart du temps qu un petit sous-ensemble, qui s apprend rapidement.

4 324 Le langage C++ Conception : le processus Le processus de l analyse et de la conception orientée objet est bien plus complexe et plus important que le langage de modélisation. Il est donc assez amusant que l on en entende beaucoup moins parler. En effet, le débat sur les langages de modélisation est plus ou moins terminé l industrie a choisi UML comme standard, alors que le débat sur le processus fait toujours rage. Une méthode est un langage et un processus de modélisation. On la désigne souvent par le terme de "méthodologie", bien que ce soit une erreur puisque ce mot désigne l étude des méthodes. Il existe plusieurs méthodes, parmi lesquelles la méthode de Grady Booch, celle de Ivar Jacobson et la méthode OMT de James Rumbaugh (Object Modeling Technologt). Ces trois hommes ont concocté Objectory, désormais appelé Rational Unified Process, qui est à la fois une méthode et un produit commercial distribué par Rational Software, Inc. Lorsqu ils travaillaient pour cette division d IBM, ils étaient affectueusement appelés les Three Amigos. Ce chapitre respecte en gros leur processus, sans le suivre aveuglément. D autres méthodes sont intéressantes à différents points de vue, l association des unes et des autres permettant d obtenir une schématique assez efficace. Tout le monde n adopte pas cette approche ; il est donc conseillé de vous documenter sur la pratique de l ingénierie logicielle pour vous faire votre propre idée. Le processus de la conception peut être itératif, ce qui signifie qu au cours du développement du logiciel, la totalité du processus peut être répétée à mesure que vous ajoutez des améliorations découlant d une meilleure compréhension des besoins. La conception guide l implémentation, mais les détails absents de l implémentation réalimentent la conception. Il est important de ne pas tenter, dès le départ, de développer un projet important de façon rectiligne et séquentielle, mais plutôt de boucler dans différentes parties du projet en améliorant constamment sa conception et en affinant son implémentation. Développement itératif ou développement en cascade? Le développement itératif se distingue du développement en cascade, dans lequel la sortie d une étape devient l entrée de la suivante et où il est impossible de revenir en arrière (voir Figure 11.3). Dans un processus en cascade, les besoins sont détaillés et confirmés par le client, ils sont alors transmis au concepteur et gravés sans le marbre. Le concepteur fait son travail puis passe sa conception au programmeur qui l implémente. Le programmeur écrit le code qui est testé par le Service Qualité, puis livré au client. Belle théorie qui peut se révéler catastrophique en pratique.

5 Chapitre 11 Analyse et conception orientée objet 325 Figure 11.3 La méthode en cascade. Analyse Conception Implémentation Tests Processus du développement itératif Dans un développement itératif, on part d un concept (une idée de ce que l on veut construire). Cette vision s étend et évolue à mesure que l on examine les détails. Dès que nous avons une idée des besoins, la conception démarre tout en sachant que les questions qui vont se poser entraineront des modifications qui auront probablement un effet sur les besoins. Tout en travaillant sur la conception, on commence également le prototypage puis l implémentation du produit. Les problèmes survenant pendant le développement ont une répercussion sur la conception et peuvent même influencer notre compréhension des besoins. Nous ne concevons et implémentons que des parties du produit complet, en rebouclant continuellement dans les phases de conception et d implémentation. Bien que les étapes du processus se répètent, il est pratiquement impossible de les décrire de manière cyclique ; c est la raison pour laquelle la liste qui suit les décrit de manière séquentielle. Étapes du processus de développement itératif : 1. Conceptualisation. La conceptualisation est la "vision". C est une simple phrase qui décrit la grande idée. 2. Analyse. L analyse est le processus de compréhension des besoins. 3. Conception. La conception est la phase de création du modèle de vos classes, à partir duquel vous produirez votre code. 4. Implémentation. L implémentation est la transcription dans le langage choisi (C++, par exemple). 5. Tests. Les tests consistent à vérifier que le travail a été bien fait.

6 326 Le langage C++ 6. Livraison. La livraison est la remise au client. Info Ce ne sont pas les mêmes étapes que les phases de Rational Unified Process, qui sont les suivantes : Mise en route ; Élaboration ; Construction ; Transition. Ni de son workflow, qui est constitué des étapes suivantes : Modélisation d activité ; Besoins ; Analyse et conception ; Implémentation ; Tests ; Déploiement ; Configuration et gestion des modifications ; Gestion de projet ; Environnement. Il doit être bien clair que chacune de ces étapes sera répétée de nombreuses fois pendant le développement d un produit donné. Pour bien comprendre le processus de conception itératif, il est toutefois plus simple de les présenter l une après l autre. Ce processus est simple. Le reste du chapitre ne fait qu en présenter les détails. Controverses Ce qui se passe au cours de chacune des étapes d un processus de conception itératif, même le nom attribué à ces étapes, fait l objet de controverses sans fin. En fait, cela n a aucune importance. Les étapes essentielles sont les mêmes dans tous les processus : savoir ce que vous voulez construire, concevoir une solution et l implémenter. Le but est de produire un code qui respecte les besoins énoncés, qui soit fiable, extensible et facilement mis à jour, tout en respectant les délais et le budget impartis.

7 Chapitre 11 Analyse et conception orientée objet 327 Étape 1 La conceptualisation : commencer par la vision Tout bon logiciel commence par une vision, un produit ou un service que quelqu un pense intéressant de développer. La vision d un projet est rarement le fait d un comité. La toute première phase d une analyse et d une conception orientées objet consiste à capturer cette vision sous la forme d une simple phrase (ou, au plus, d un court paragraphe), qui deviendra le principe directeur du développement. L équipe qui sera chargée d implémenter cette vision pourra s y référer et la modifier si nécessaire à mesure de l avancement du projet. Même si l énoncé de la vision a été produit par un comité du département financier, une seule personne devrait être considérée comme le "visionnaire". Son travail consiste à être le gardien de la lumière sacrée. À mesure que le projet avance, les besoins évoluent ; les contraintes de planification et de livraison peuvent (et devraient) modifier ce que vous tentez d accomplir à la première itération du programme, mais le visionnaire doit garder un œil sur l idée essentielle pour s assurer que ce qui est produit reflète très fidèlement la vision initiale. C est ce dévouement sans faille, passionné, qui permettra d amener le projet à ses fins. Si cette vision est perdue, le produit l est aussi. La phase de conceptualisation, dans laquelle s articule la vision, est très courte. Elle ne doit pas dépasser le temps du flash révélateur et de sa retranscription. Dans d autres projets, la vision exige une phase de détermination de l envergure plus complexe, où il faut parvenir à un accord sur les composants, entre les personnes impliquées. Dans ce cas, le succès du projet sera fonction des éléments retenus ou refusés. Étape 2 L analyse : collecter les besoins Certaines sociétés confondent la vision et les besoins. Une bonne vision est nécessaire, mais pas suffisante. Pour passer à la conception, il faut comprendre l utilisation qui sera faite du produit et le comportement qu il devra avoir. L objectif de l analyse est d articuler et de collecter ces besoins. Son résultat est un document des besoins, dont la première partie est l analyse des case d utilisation (use cases). Les cas d utilisation Les use cases, ou cas d utilisation, sont tout simplement une description de haut niveau de la façon dont le produit sera utilisé. Ils orientent non seulement l analyse, mais également la conception en vous aidant à déterminer les classes et sont particulièrement importants pour les tests du produit.

8 328 Le langage C++ L élaboration d un jeu complet de cas d utilisation peut représenter le travail le plus important de l analyse. Les experts du domaine sont les plus qualifiés pour vous aider dans cette tâche car ce sont eux qui ont le plus d informations sur les besoins que vous tentez de cerner. Les cas d utilisation ne tiennent pas compte des détails de l interface utilisateur, pas plus que des rouages internes du système que vous êtes en train de construire. Ils devraient plutôt se consacrer aux interactions qui doivent survenir et aux personnes et aux systèmes (les acteurs) qui devront collaborer pour produire le résultat attendu.. Voici quelques définitions pour résumer cette partie : Cas d utilisation. Une description de la façon dont le logiciel sera utilisé. Experts du domaine. Comme le nom l indique, ce sont les experts du domaine auquel le produit est destiné. Acteur. Tout utilisateur ou système interagissant avec le système que vous développez. Un cas d utilisation est une description de l interaction entre un acteur et le système luimême. Pour les besoins de l analyse des cas d utilisation, le système est considéré comme une "boîte noire". Un acteur "envoie un message au système", et une réaction se produit : des informations sont renvoyées, l engin spatial change de trajectoire, etc. Les cas d utilisation ne suffisent pas à connaître tous les besoins, mais ils sont essentiels et reçoivent souvent la plus grande attention. On peut également inclure les règles d entreprise, les données et les besoins techniques en matière de performances, de sécurité, etc. Identifier les acteurs Les acteurs ne sont pas nécessairement des personnes, les systèmes qui interagissent avec le système que vous construisez le sont aussi. Si, par exemple, vous construisez un guichet automatique de banque, le client et l employé de banque sont tous les deux acteurs de même que tout système impliqué, comme un système de prêt ou de suivi des découverts. Les caractéristiques essentielles d un acteur sont : d être externes au système ; d interagir avec le système. Astuce Le démarrage est souvent la partie la plus difficile de l analyse des cas d utilisation. Le meilleur point de départ peut être une séance de brainstorming. Notez la liste des personnes et des systèmes qui interagiront avec votre nouveau système. N oubliez pas que Personnes signifie en réalité rôles le guichetier, le directeur, le client, etc. Une même personne peut avoir plusieurs rôles.

9 Chapitre 11 Analyse et conception orientée objet 329 Dans notre exemple de guichet automatique, nous pourrions avoir les rôles suivants : le client ; le personnel de la banque ; un système back-office ; la personne qui alimente le guichet automatique. Cette liste suffit pour commencer la génération de nos cas d utilisation. Déterminer les premiers cas d utilisation Dans l exemple du guichet automatique, commençons par le client. Il peut : vérifier son solde ; déposer de l argent sur son compte ; retirer de l argent ; faire des virements entre ses comptes ; ouvrir un compte ; fermer un compte. Doit-on faire la distinction entre "déposer de l argent sur son compte courant" et "déposer de l argent sur son compte épargne", ou ces actions doivent-elles être combinées en une seule (comme nous l avons fait) : "déposer de l argent sur son compte"? Cela dépend si la différence est significative dans le domaine en question. Pour le savoir, vous devez demander si les mécanismes (actions entreprises par le client) et les sorties (réponse du système) sont différents. La réponse aux deux questions est "non" : le client dépose de l argent de la même façon sur ces deux comptes et la sortie est quasiment la même ; le guichet répond en incrémentant le solde du compte concerné. L acteur et le système se comportant et répondant de façon quasiment identique dans le cas d un versement sur l un ou l autre compte, ces deux cas d utilisation n en forment réellement qu un seul. Vous pourrez plus tard tenter deux variantes pour voir s il existe une quelconque différence. En examinant chaque acteur, vous pouvez découvrir des cas d utilisation supplémentaires en répondant aux questions suivantes : Pourquoi l acteur utilise-t-il ce système? Le client l utilise pour obtenir du liquide, faire un dépôt ou vérifier son solde.

10 330 Le langage C++ Quelle est la sortie que l acteur veut ou attend? Ajout d argent sur un compte ou obtention de liquide pour faire un achat. Qu est-ce qui incite l acteur à utiliser maintenant le système? Il peut avoir reçu de l argent sur son compte ou avoir l intention de faire un achat. Que doit faire l acteur pour utiliser le système? S identifier en insérant une carte dans la machine. Ah! Nous avons donc besoin d un cas d utilisation supplémentaire pour la connexion du client au système. Quelles informations l acteur doit-il fournir au système? Entrer un code personnel. Ah! Nous avons donc encore besoin d une cas d utilisation supplémentaire pour obtenir et modifier son code personnel. Quelles sont les informations que l acteur attend du système? Solde du compte, etc. Vous pouvez aussi vous concentrer sur les attributs des objets du domaine. Le client a un nom, un code et un numéro de compte. Avez-vous des cas d utilisation pour gérer ces objets? Un compte a un numéro, un solde et un historique des opérations. Ces éléments figurent-ils dans les cas d utilisation? Après avoir exploré en détail les cas d utilisation du client, l étape suivante consiste à développer ceux des autres acteurs. Dans notre exemple : Le client vérifie son ou ses soldes. Le client dépose de l argent sur son ou ses comptes. Le client retire de l argent de son ou ses comptes. Le client fait des virements. Le client ouvre un compte. Le client ferme un compte. Le client se connecte à son ou ses comptes. Le client vérifie ses dernières transactions. L employé de banque se connecte à un compte spécial de gestion. L employé de banque modifie un compte client. Un système back-office met un compte client à jour en fonction d une activité externe.

11 Chapitre 11 Analyse et conception orientée objet 331 Les modifications d un compte client sont reflétées dans un système back office. Le guichet automatique signale qu il est à court d argent. Le technicien alimente le guichet automatique en argent et en imprimés. Création du modèle du domaine Après avoir établi un premier découpage de vos cas d utilisation, le document des besoins peut être étoffé avec un modèle du domaine détaillé. Ce document capture tout ce que vous savez du domaine. Les objets du domaine que vous créez, décrivant tous les objets mentionnés dans vos cas d utilisation, en font partie. Notre exemple comprend pour l instant les objets suivants : client, personnel de la banque, systèmes back-office, compte courant, compte épargne, etc. Pour chacun de ces objets du domaine, nous devons capturer des données essentielles comme le nom de l objet (client, compte, etc.), si l objet est un acteur, ses attributs et ses comportements principaux, etc. De nombreux outils de modélisation permettent de capturer ce type d informations dans des descriptions de "classe". La Figure 11.4 montre comment ces informations sont représentées avec l outil de modélisation Rational Rose. Figure 11.4 Rational Rose. Il est important de réaliser que les objets décrits ne sont pas la classe qui sera utilisée dans la conception (même s il y aura sûrement des classes similaires), mais des classes d objets du domaine. Il s agit d une documentation des besoins de fonctionnement du système, pas d une documentation de la façon dont celui-ci va répondre à ces besoins. Les relations entre les objets du domaine de notre exemple peuvent être représentées en UML avec les mêmes conventions que celles que nous utiliserons plus tard pour décrire

12 332 Le langage C++ les relations entre les classes de la conception. C est l un des principaux avantages de UML : vous pouvez utiliser la même représentation à chaque étape du projet. Par exemple, la Figure 11.5 précise que les vérifications des comptes courant ou épargne sont des spécialisations du concept plus général de compte bancaire. Figure 11.5 Spécialisation. Généralisation Compte bancaire Objet du domaine Compte courant Compte épargne Dans la Figure 11.5, les rectangles représentent les différents objets du domaine et les flèches indiquent une généralisation. Le sens des flèches va de la classe spécialisée vers la classe de base plus générale. Les comptes courant et épargne sont donc tous deux une forme spécialisée de compte bancaire. Info Nous montrons ici la relation entre les classes du domaine des besoins. Vous pourrez ultérieurement, au moment de la conception, décider d avoir un objet CompteCourant et un objet CompteBancaire, et implémenter cette relation à l aide de l héritage, mais ce seront des décisions de conception. Lors de l analyse, nous nous contentons de documenter notre compréhension de ces objets dans le domaine. UML est un langage de modélisation riche permettant de représenter toutes les relations. Les principales, capturées lors de l analyse, sont les suivantes : la généralisation (ou spécialisation) ; la composition ; l association.

13 Chapitre 11 Analyse et conception orientée objet 333 Généralisation Elle est souvent assimilée à l héritage, mais il existe une distinction significative entre les deux. La généralisation décrit la relation ; l héritage est l implémentation de la généralisation dans le code. Le corollaire à la généralisation est la spécialisation. Un chat est une forme spécialisée d animal ; l animal est un concept généralisé qui réunit un chien ou d un chat. La spécialisation implique que l objet dérivé est-un sous-type de l objet de base. Un compte courant est-un compte bancaire. Cette relation est symétrique : un compte bancaire généralise le comportement et les attributs communs d un compte courant et d un compte épargne. Dans la phase d analyse du domaine, vous devez chercher à capturer ces relations telles qu elles existent dans la réalité. Composition Un objet est souvent composé de plusieurs sous-objets. Un compte courant comprend un solde, un historique des transactions, une identification du client, etc. On dit que le compte courant a ces éléments ; la composition modélise la relation a-un. En UML, elle est représentée par une flèche avec un losange partant de l objet contenant vers l objet contenu, comme le montre la Figure Figure 11.6 Composition. Compte courant Agrégation Solde Le compte courant a-un solde. Vous pouvez combiner ces diagrammes pour représenter un ensemble de relations assez complexe. La Figure 11.7 montre qu un compte courant et un compte épargne sont tous les deux des comptes bancaires et que tous les comptes bancaires ont à la fois un solde et un historique des transactions.

14 334 Le langage C++ Figure 11.7 Relations entre objets. Compte courant Compte épargne Compte bancaire Solde Historique des transactions Association La troisième relation fréquemment représentée lors de l analyse du domaine est une simple association. Une association suggère l interaction quelconque de deux objets, sans préciser vraiment son objectif. Cette définition sera affinée lors de la phase de conception. Pour l analyse, elle indique simplement qu un objet A et un objet B sont liés, mais qu aucun d eux ne contient, ni est une spécialisation de l autre. La notation UML la représente comme une simple ligne entre les objets (voir Figure 11.8). Figure 11.8 Association. Objet A Objet B Association Établir des scénarios Avec nos cas d utilisation préliminaires et les outils permettant de représenter les relations entre les objets du domaine, nous pouvons formaliser les cas et les approfondir.