Analyse et conception d applications Introduction : but du cours et notions UML de base

Analyse et conception d applications Introduction : but du cours et notions UML de base Notes de cours 2008-2009 par Jacques THOORENS 1 Buts et orientations du cours Ce cours a pour but de proposer une réflexion sur l utilisation des objets en programmation. Dans le cursus de formation de nos étudiants, les objets sont abordés par deux biais : l étude d un langage, dans le cours de langage orienté objet, et la réalisation de projets, dans les trois cours consacrés à un projet, à un projet GUI et un projet Intranet. Je sais pertinemment qu au-delà de leur compétence dans chaque domaine particulier, que ce soit le C++, C#, PHP, ASP ou l interface avec les bases de données, mes collègues ont à cœur de provoquer chez les étudiants une prise de conscience de l intérêt d utiliser des objets en programmation. L apprentissage de C++ passe forcément par un exposé théorique portant notamment sur l encapsulation, l héritage et le polymorphisme. L originalité de l approche qui sera la mienne réside dans l indépendance vis-à-vis du langage, puisque je ne suis pas obligé de «boucler» une matière, avec son nécessaire cortège d exercices de programmation, et dans l indépendance vis-à-vis d un projet, puisque les cas concrets que nous allons étudier ne doivent pas nécessairement déboucher sur un programme qui «tourne». Cette liberté va me permettre de mieux mettre l accent sur la philosophie de la programmation objet. Le terme philosophie n est pas choisi au hasard, ni par pédanterie. De même que les philosophes grecs ont les premiers utilisé leur intelligence, non pour tenter de donner une explication au monde, mais pour essayer de comprendre leur propre processus de connaissance, l analyse est une sorte de méta-programmation, dans laquelle la réalisation du programme n est plus un but mais un objet de réflexion. Le but ultime est sans doute aussi illusoire que la sagesse parfaite des philosophes : la création d une méthode qui permette de réaliser un logiciel parfaitement adapté à son objet. Pour le dire plus simplement, nous allons moins nous soucier de ce que nous faisons que de la manière dont nous le faisons. Ce cours d analyse de deuxième niveau porte le titre complet «Analyse et conception d applications» qui ne fait pas référence explicite à la programmation objet. Je pense qu après une étude de Merise, qui a le mérite de planter un décor solide, il est bon de regarder autour de soi et de voir que les entreprises demandent des programmeurs aguerris aux méthodes objet. Pour parler de Merise, il suffisait de choisir un bon bouquin et de paraphraser son exposé. Pour ce qui concerne l approche objet, les bons livres ne manquent pas, mais aucun d eux ne réussit à imposer sa méthodologie comme une référence incontournable. Cela peut aller du livre de recettes pour programme objet, à une simple présentation d un outil, en passant par une présentation un peu abstraite d une méthode trop américaine pour satisfaire des esprits européens. Les notes fournies cette année sont donc une ébauche et ma seule ambition est de proposer à mes étudiants un point de départ pour établir leur propre méthode ou une base pour accueillir la méthode utilisée par l entreprise où ils travailleront bientôt. Chemin faisant, nous allons, outre un rappel de notions importantes de la programmation objet, aborder plusieurs exemples concrets tout au long du cours et nous intéresser à trois

2 ACA - Introduction : 2 Notation U.M.L. aspects fondamentaux de l analyse objet : un processus, qui nous permettra de progresser d une définition du problème vers une conception de plus en plus détaillée de la solution, c est sans doute la partie la plus discutable du cheminement, mais aussi la plus passionnante ; une notation, qui nous permettra de mémoriser nos idées et surtout de les partager avec les utilisateurs et les gens qui travailleront avec nous, nous adopterons évidemment UML. des outils, qui nous permettront de traiter efficacement les notations pour les mémoriser, les modifier, voire même générer du code à partir d elles. Les outils ne manquent pas, mais nous seront limités par le prix des licences. Ces outils sont habituellement désignés par le terme générique outils CASE (Computer-Aided Software Engineering ou Génie Logiciel Assisté par Ordinateur). 2 Notation U.M.L. 2.1 Historique et principes U.M.L., acronyme de Unified Modeling Language (Langage unifié de modélisation) est un langage graphique de description défini pour la première fois en 1997. Il a fait l objet de plusieurs révisions, la dernière en date étant la version 2.1. Répétons que UML est un langage (ou un formalisme si on préfère) et non une méthode. Certains de ses concepteurs ont exposé une méthodologie 1 dans des ouvrages distincts et il est parfaitement possible d utiliser UML sans partager ces idées théoriques. UML est né principalement de la rencontre des travaux de trois analystes américains, qui ont reçu le surnom de Tres Amigos. Bien qu une même société fort active dans le développement d outils en relation avec UML, Rational Software, maintenant une division d IBM, en emploient les trois fondateurs, la norme UML n est pas propriété de cette société, mais d un consortium où interviennent la plupart des ténors de l industrie logicielle américaine (parmi eux, HP, Microsoft, IBM, Oracle...). Jim RUMBAUGH apporte principalement la formalisation des notions de classe et d association ; Grady BOOCH a spécialement apporté une contribution sur la partition en sous-système ; Ivar JAKOBSON, inventeur des use cases, rejoint l équipe en 1995. Les trois amigos se sont fixé quatre objectifs 2 : représenter des systèmes entiers (au-delà du seul logiciel) par des concepts objets ; établir un couplage explicite entre les concepts et les artefacts exécutables ; prendre en compte les facteurs d échelle inhérents aux systèmes complexes et critiques ; créer un langage de modélisation utilisable à la fois par les humains et les machines. UML présente essentiellement des diagrammes de différents types qui servent à représenter les aspects statiques et dynamiques d une application. Tous ne sont pas également utiles. Certains d entre eux ont une interprétation unique, tandis que d autres peuvent servir à représenter différents aspects de l application à différents stades de l analyse. La version 1.x d UML comportait 9 types de diagrammes, la version actuelle en a modifié certain et ajouté quelques diagrammes. Ils sont maintenant au nombre de 13. Déjà parmi les neuf types initiaux, certains jouaient un rôle plus important. 1 Cette méthode est définie dans P. KRUCHTEN, The Rational Unified Process, Addison-Wesley, 1998, traduit en français aux éditions Eyrolles (Initiation au Rational Unified Process) et généralement mentionnée sous l abréviation RUP. 2 Je cite ici l excellent résumé de Pierre-Alain MULLER dans son excellent ouvrage cité dans la bibliographie.

2.2 Diagrammes structurels 3 2.2 Diagrammes structurels 2.2.1 Diagrammes de classes (UML 1) Sans doute le diagramme le plus connu et le plus riche. Comme son nom l indique, il sert à représenter les classes, leurs composants (attributs et opérations) et les relations diverses entre ses classes. On trouve parfois aussi des interfaces parmi ces classes. Il est possible de représenter l ordonnancement des classes au sein des paquetages dans ce type de diagrammes, mais UML 2 a introduit un type spécifique de diagrammes pour cela. On peut trouver des diagrammes de classes extrêmement sommaires, en phase initiale de conception, ou au contraire des diagrammes remplis de détails exhaustifs. Notons que beaucoup de logiciels offrent la possibilité de générer du code au départ de ces diagrammes. La précision des détails permet alors d éviter une bonne partie de la frappe du code. Il est également possible de générer une diagramme de classe au départ d une application existante (retro engineering). La possibilité de travailler simultanément sur le diagramme de classes et le code est réservée aux logiciels professionnels coûteux. 2.2.2 Diagrammes de composants (UML1) Ils représentent l organisation et les dépendances au sein d un ensemble de composants. Ils représentent la vue d implémentation statique d un système.

4 ACA - Introduction : 2 Notation U.M.L. 2.2.3 Diagrammes de déploiement (UML 1) Ils représentent la configuration des nœuds de processus en phase d exécution ainsi que les composants qui y résident. C est une partie du modèle qui n est pas très développée et sur laquelle les auteurs restent relativement discrets.

2.2 Diagrammes structurels 5 2.2.4 Diagrammes de paquetages Sous-catégorie des diagrammes de classes, ils insistent sur les regroupement des classes et des interfaces au sein des paquetages. 2.2.5 Diagrammes d objets (UML 1) Ils représentent un ensemble d objets et leurs relations. Ces sont des vues statiques des instances des éléments qui apparaissent dans les diagrammes de classes. Ils ont un rôle essentiellement didactique en permettant de représenter sous une forme concrète des interactions d objets illustratives ou des cas particuliers dont les modèles de classe doivent pouvoir rendre compte. Leur formalisme est tout-à-fait équivalent à celui des diagrammes de classes. Ils s en distinguent par la présence d objets concrets. 2.2.6 Diagrammes de structures composites Addition récente au modèle UML, le diagramme de structure composite figure dans des modèles particulièrement complexes. Il associe des diagrammes de classes avec des diagrammes de composants.

6 ACA - Introduction : 2 Notation U.M.L. 2.3 Diagrammes comportementaux 2.3.1 Diagrammes de cas d utilisation (UML 1) Ils représentent un des apports marquants de Jacobson à la méthode. Ils regroupent un ensemble de cas d utilisation et d acteurs et leurs relations. Particulièrement éclairants pour la modélisation des comportements du système, ils en fournissent une description de base qui sera utile pour dialoguer avec les utilisateurs. Ceux-ci se reconnaîtront dans les acteurs et ils pourront vérifier que leur interaction avec le système correspond bien à leurs attentes. 2.3.2 Diagrammes d activité (UML 1) Ils représentent la vue dynamique du système et décrivent la succession des activités en son sein. On peut les utiliser pour modéliser n importe quoi. Ils sont proches des diagrammes d états-transitions par leur souci de représenter la dynamique du système, mais ils mettent en évidence la succession des activités. A la différence des diagrammes séquentiels, ils sont moins soucieux de chronologie que de logique. Ils rappellent les organigrammes de la programmation traditionnelle, mais offrent la possibilité de représenter les traitements en parallèle.

2.3 Diagrammes comportementaux 7 2.3.3 Diagrammes de communication (en UML 1 de collaboration) Ce sont des diagrammes d interaction qui mettent l accent sur l organisation structurelle des objets qui envoient et reçoivent des messages. Ils sont sémantiquement identiques aux diagrammes de séquence : seule la manière de représenter l information diffère : les objets sont ici mis en évidence et on voit clairement les messages qui partent de chacun d eux et y aboutissent. 2.3.4 Diagrammes de machines d état (UML 1) Ce sont des automates à états finis, composés d états, de transitions, d événements et d activités. Ils présentent la vue dynamique d un système. Ils offrent la possibilité de montrer des parties dynamiques d un système en mettant en évidence la notion d état. Les visions purement statiques ou chronologiques ne permettent pas de représenter clairement cette notion.

8 ACA - Introduction : 2 Notation U.M.L. On pourra par exemple représenter par leur truchement les différentes valeurs d un attribut au cours du temps, en montrant quelles opérations en provoquent les changements. 2.3.5 Diagrammes d interaction d ensemble Version moins détaillée des diagrammes d activités. 2.3.6 Diagrammes de séquences (UML 1) Ce sont des diagrammes d interaction qui mettent l accent sur le classement chronologique des messages. Ils se disposent en colonnes correspondant à différents objets. L axe vertical représente le déroulement du temps. Des flèches horizontales représentent les messages transmis d un acteur à l autre. Depuis la version 2.0, ces diagrammes s enrichissent d un formalisme permettant de représenter les boucles, les traitements optionnels ou alternatifs, voire même la notion de sous-traitement. Ils sont très riches, mais assez lourds à mettre en œuvre.

2.4 Les vues 9 2.3.7 Diagrammes de chronométrages Cas particulier de diagramme d interactions réservé au traitement des problèmes en «temps réel». Il permet de synchroniser les envois de messages dans des situations complexes (exemple : les satellites pour lesquels la distance et la durée de la transmission deviennent critiques). Nous ne parlerons pas de ce type très particulier de diagrammes, réservés à des contextes industriels complexes. 2.4 Les vues 3 Bien que ne faisant pas partie d UML, la présentation sous forme de vues permet de classer les différents diagrammes en mettant l accent sur des aspects communs. Beaucoup de logiciels utilisent cette notion, qui constitue alors un point d entrée obligé. C est le cas de Bouml, décrit plus loin. 2.4.1 Vue du concepteur Elle est centrée sur le concept de classe. On y retrouvera donc les diagrammes de classes et d objets (comprenant classes, interfaces et objets), des diagrammes d activités, des diagrammes de séquences. Bouml y ajoute les machines à états et les diagrammes d états. L implémentation et le déploiement n en font pas partie (voir vue suivante). 2.4.2 Vue de déploiement On est proche ici du matériel, de la topologie du réseau. On voit comment le système s exécute et se configure, par le moyen de diagrammes de composants, de déploiement et de d interaction. Bouml n y inclut que des diagrammes de déploiement, mais permet d y intégrer des composants. 3 Pour cette sous-section, j ai suivi d assez prêt la description de DAN PILONE et NEIL PITMAN, UML en concentré, traduit par DENIS PRIOU. Paris, Editions O Reilly, 2006.

10 ACA - Introduction : 2 Notation U.M.L. 2.4.3 Vue d implémentation Centrée sur les composants, cette vue n utilise pratiquement que des diagrammes de composants. Composants, fichiers, ressources y figurent. On peut aussi parfois trouver, mais pas dans Bouml, des diagrammes d interaction, d état et de structures composite. Cette vue porte le nom de «component view» dans Bouml. 2.4.4 Vue du processus Absente dans Bouml, cette vue décrit la performance, l évolutivité et la cohérence du système. Beaucoup de diagrammes d interaction et d activités. 2.4.5 Vue de cas d utilisation Cette vue définit ce que les utilisateurs seront à même de réaliser à l aide du logiciel (et ce qu ils peuvent effectivement réaliser à la fin du développement). Outre les diagrammes de cas d utilisation, on y trouve des diagrammes de séquences et des diagrammes d interaction (dans Bouml : cas d utilisation, séquences, communication et objets). 2.5 Les relations La notion de relation en UML a un contenu neutre. Elle constitue une classe abstraite dont les sous-classes se rencontrent effectivement dans les diagrammes. Il existe en quatre sousclasses fondamentales, l une d elle ayant des cas particuliers. Un certain nombre de relations peuvent recevoir un stéréotype.

2.5 Les relations 11 2.5.1 la dépendance Représente une relation faible impliquant que l objet qui dépend de l autre risque de devoir se modifier si l autre subit une altération. On essaie de supprimer toutes les dépendances mutuelles, qui rendent difficiles les réutilisations. On parlera de dépendance d une classe A vis-à-vis de B si une de ses variables d instance est de type B ou si le paramètre d une de ses méthodes est également de type B. En pratique, on peut minimiser la dépendance entre classes en utilisant des interfaces. 2.5.2 la généralisation Au coeur de la modélisation, la généralisation relie une classe à sa classe-mère. Conçue à l origine pour modéliser les hiérarchies de classes, la généralisation s applique aussi aux acteurs et aux use cases. On parle parfois de la généralisation comme d une relation «EST UN». 2.5.3 l association L association manifeste une relation privilégiée en deux classes dont les instances entretiennent des liens. Elle joue un rôle primordial dans la dynamique du système : l association

12 ACA - Introduction : 2 Notation U.M.L. autorise les instances d une classe à envoyer des messages à d autres objets. La modélisation des associations est à ce point importante qu on a défini trois cas particuliers d association : 1. la classe-association est une association qui disposent d attributs et d opérations. 2. l aggrégation définit la relation entre la partie et le tout : on parle aussi de relation «A UN». 3. la composition est un type particulier d aggrégation. On parle de composition quand l élément composant n est pas accessible en dehors de son composé. 2.5.4 la réalisation La réalisation unit une classe à l interface qu elle implémente. On trouve aussi une réalisation entre un cas d utilisation et la collaboration qui la matérialise.

13 3 Logiciels de modélisation UML Quelques remarques sur les logiciels disponibles (voir aussi la page de Wikipedia qui en recense un bon nombre et fournit les liens vers des descriptions plus complètes). 3.1 IBM - Rational Rose L un des premiers logiciels de modélisation UML. Les trois amigos ont été engagés par Rational bien avant le rachat de la société par IBM. C était un logiciel énorme, offrant des tas d ajouts vers les langages et les technologies de persistance. Grande richesse fonctionnelle, interaction bi-directionnelle avec le code. Le programme mettait pas mal de désordre sur la machine hôte : engorgement de la base de registre, morceaux de technologie UNIX dans le système. Les produits actuels sont devenus plus complexes encore : plusieurs modules aux fonctionnalités parfois cryptiques. Ce sont sans nul doute de bons produits, mais réservés à des entreprises ayant les moyens de s offrir les licences et surtout les nombreuses formations payantes proposées par IBM. 3.2 ArgoUML Logiciel libre prometteur, mais dont le développement semble ralenti. La version 0.24 va être suivie d une béta de 0.26 après deux ans de vie. La version actuelle ne tient quasiment pas compte de UML 2.0. 3.3 Poseidon Initialement basé sur ArgoUML, il se décline en plusieurs versions dont une version professionnelle impressionnante (travail collaboratif). La version «communauté» a brutalement cessé d être gratuite en décembre 2006, sans laisser la possibilité de relire les anciennes productions. Elle offrait une bonne ergonomie, la génération de code en Java et l indépendance vis-à-vis du système d exploitation. Elle existe également comme plug-in pour Eclipse. Lent au démarrage, il exige une machine assez puissante. 3.4 Bouml Développé en C++, ce logiciel tourne sous différents système d exploitation grâce à l emploi des bibliothèques Qt. L emploi de C++ le rend étonnamment rapide, au démarrage comme

14 ACA - Introduction : 3 Logiciels de modélisation UML à l importation de classes existantes. Il dame le pion à tous ses concurrents sur ce plan. Assez complet et en constante évolution (une à deux mises à jour par mois), il offre des fonctionnalités originales dans la description des cas d utilisation, la génération d une abondante documentation sous format HTML pour la consultation du dossier, la génération et l importation depuis différents langages (C++, Java, Python et PHP), l importation des modèles de Rational Rose, la possibilité de travailler à plusieurs sur un même modèle et quelques autres surprises agréables. L interface est moins intuitive que celle de Poseidon, mais plus réactive. Quelques défauts : une documentation de 300 pages assez peu utilisable (heureusement compensée par des tutoriels de l auteur sur Developpez.com), le changement de format à chaque mise à jour, qui rend impossible la lecture d un fichier 4.5.1 sur une version 4.5.0. Pour un travail en équipe, il convient de synchroniser les mises à jour. 3.5 Produits divers J ai entendu parler en bien de StarUML (sous Windows uniquement). Je déconseille Umbrello (uniquement sous Linux) qui reste peu ergonomique et fort incomplet. Jude est intéressant (multiplateforme), mais limité dans sa version gratuite. Il dispose des mêmes menus que la version payante et on se trouve constamment bridé dans sa créativité par un écran qui annonce qu il faut ouvrir sa bourse pour la fonctionnalité choisie. Il en est de même pour les produits de Visual Paradigme et Sybase (PowerAMC) qui ne sont vraiment utilisables qu en version payante. 3.6 Modules divers NetBeans offre un module UML dans sa version complète (gratuit). Il est intégré aux projets développés en Java ou dans d autres langages. Il offre quelques fonctionnalités intéressantes, mais son ergonomie et son look non standard ne lui permettent pas d être envisagé comme outil de modélisation intensif. Il existe également quelques fonctions du même genre dans JDevelopper d Oracle. 3.7 Logiciels de dessin vectoriel Visio, Dia, SmartDraw offrent généralement des extensions UML. Il s agit de logiciels de dessin qui ne sont donc pas à même de gérer les dépendances, de mettre en évidence les incohérences, ni d importer ou d exporter. Il faut donc les employer pour une utilisation ponctuelle (schéma pour illustrer un dossier).