UML 2

La problématique que pose la mise en œuvre d'UML est simple : comment passer de l'expression des besoins au code de l'application ? Cette problématique est parfaitement illustrée par la figure 9.1.

Comme nous l'avons déjà dit, à maintes reprises, UML n'est qu'un langage de modélisation, ce n'est pas une méthode. En effet, UML ne propose pas une démarche de modélisation explicitant et encadrant toutes les étapes d'un projet, de la compréhension des besoins à la production du code de l'application. Une méthode se doit de définir une séquence d'étapes, partiellement ordonnées, dont l'objectif est de produire un logiciel de qualité qui répond aux besoins des utilisateurs dans des temps et des coûts prévisibles.

Bien qu'UML ne soit pas une méthode, ses auteurs précisent néanmoins qu'une méthode basée sur l'utilisation UML doit être :

• la principale qualité d'un logiciel étant son utilité, c'est-à-dire son adéquation avec les besoins des utilisateurs, toutes les étapes, de la spécification des besoins à la maintenance, doivent être guidées par les cas d'utilisation qui modélisent justement les besoins des utilisateurs ;

• l'architecture est conçue pour satisfaire les besoins exprimés dans les cas d'utilisation, mais aussi pour prendre en compte les évolutions futures et les contraintes de réalisation. La mise en place d'une architecture adaptée conditionne le succès d'un développement. Il est important de la stabiliser le plus tôt possible ;

• l'ensemble du problème est décomposé en petites itérations, définies à partir des cas d'utilisation et de l'étude des risques. Les risques majeurs et les cas d'utilisation les plus importants sont traités en priorité. Le développement procède par des itérations qui conduisent à des livraisons incrémentales du système. Nous avons déjà présenté le modèle de cycle de vie par incrément dans la section 1.2.3Modèles de cycles de vie d'un logiciel.

Dans les sections qui suivent (sections 9.2Identification des besoins, 9.3Phases d'analyse et 9.4Phase de conception) nous allons présenter une méthode simple et générique qui se situe à mi-chemin entre UP (Unified Process), qui constitue un cadre général très complet de processus de développement, et XP (eXtreme Programming) qui est une approche minimaliste à la mode centrée sur le code. Cette méthode est issue de celle présentée par [23] dans son livre « UML - Modéliser un site e-commerce » qui résulte de plusieurs années d'expérience sur de nombreux projets dans des domaines variés. Elle a donc montré son efficacité dans la pratique et est :

• conduite par les cas d'utilisation, comme UP, mais bien plus simple ;
• relativement légère et restreinte, comme XP, mais sans négliger les activités de modélisation en analyse et conception ;
• fondée sur l'utilisation d'un sous-ensemble nécessaire et suffisant du langage UML (modéliser 80 % des problèmes en utilisant 20 % d'UML).

Dans tous les cas, il faut garder à l'esprit qu'une méthode n'est pas une formule magique. Le fait de produire des diagrammes UML selon un ordre établi n'est en aucun cas une garantie de réussite. Une méthode ne sert qu'à canaliser et ordonner les étapes de la modélisation. La valeur n'est pas dans la méthode, mais dans les personnes qui la mettent en œuvre.

Les cas d'utilisation sont utilisés tout au long du projet. Dans un premier temps, on les crée pour identifier et modéliser les besoins des utilisateurs (figure 9.2). Ces besoins sont déterminés à partir des informations recueillies lors des rencontres entre informaticiens et utilisateurs. Il faut impérativement proscrire toute considération de réalisation lors de cette étape.

Durant cette étape, vous devrez déterminer les limites du système, identifier les acteurs et recenser les cas d'utilisation (cf. section 2.5Modélisation des besoins avec UML). Si l'application est complexe, vous pourrez organiser les cas d'utilisation en paquetages.

Dans le cadre d'une approche itérative et incrémentale, il faut affecter un degré d'importance et un coefficient de risque à chacun des cas d'utilisation pour définir l'ordre des incréments à réaliser.

Les interactions entre les acteurs et le système (au sein des cas d'utilisation) seront explicitées sous forme textuelle et sous forme graphique au moyen de diagrammes de séquence (cf. section 9.2.2Diagrammes de séquence système). Les utilisateurs ont souvent beaucoup de difficultés à exprimer clairement et précisément ce qu'ils attendent du système. L'objectif de cette étape et des deux suivantes (section et 9.2.3Maquette de l'IHM) est justement de les aider à formuler et formaliser ces besoins.

Dans cette étape, on cherche à détailler la description des besoins par la description textuelle des cas d'utilisation (cf. section 2.5.3Description textuelle des cas d'utilisation) et la production de diagrammes de séquence système illustrant cette description textuelle (figure 9.3). Cette étape amène souvent à mettre à jour le diagramme de cas d'utilisation puisque nous sommes toujours dans la spécification des besoins.

Les scénarii de la description textuelle des cas d'utilisation peuvent être vus comme des instances de cas d'utilisation et sont illustrés par des diagrammes de séquence système. Il faut, au minimum, représenter le scénario nominal de chacun des cas d'utilisation par un diagramme de séquence qui rend compte de l'interaction entre l'acteur, ou les acteurs, et le système. Le système est ici considéré comme un tout et est représenté par une ligne de vie. Chaque acteur est également associé à une ligne de vie.

Lorsque les scénarii alternatifs d'un cas d'utilisation sont nombreux et importants, l'utilisation d'un diagramme d'états-transitions ou d'activités peut s'avérer préférable à une multitude de diagrammes de séquence.

Une maquette d'IHM (Interface Homme-Machine) est un produit jetable permettant aux utilisateurs d'avoir une vue concrète, mais non définitive de la future interface de l'application (figure 9.4). La maquette peut très bien consister en un ensemble de dessins produits par un logiciel de présentation ou de dessin. Par la suite, la maquette pourra intégrer des fonctionnalités de navigation permettant à l'utilisateur de tester l'enchaînement des écrans ou des menus, même si les fonctionnalités restent fictives. La maquette doit être développée rapidement afin de provoquer des retours de la part des utilisateurs.

La modélisation des besoins par des cas d'utilisation s'apparente à une analyse fonctionnelle classique. L'élaboration du modèle des classes du domaine permet d'opérer une transition vers une véritable modélisation objet. L'analyse du domaine est une étape totalement dissociée de l'analyse des besoins (sections 9.2.1Diagramme de cas d'utilisation, 9.2.2Diagrammes de séquence système et 9.2.3Maquette de l'IHM). Elle peut être menée avant, en parallèle ou après cette dernière.

La phase d'analyse du domaine permet d'élaborer la première version du diagramme de classes (figure 9.5) appelée modèle du domaine. Ce modèle doit définir les classes qui modélisent les entités ou concepts présents dans le domaine (on utilise aussi le terme de métier) de l'application. Il s'agit donc de produire un modèle des objets du monde réel dans un domaine donné. Ces entités ou concepts peuvent être identifiés directement à partir de la connaissance du domaine ou par des entretiens avec des experts du domaine. Il faut absolument utiliser le vocabulaire du métier pour nommer les classes et leurs attributs. Les classes du modèle du domaine ne doivent pas contenir d'opération, mais seulement des attributs. Les étapes à suivre pour établir ce diagramme sont (cf. section 3.6.1Élaboration d'un diagramme de classes) :

• identifier les entités ou concepts du domaine ;
• identifier et ajouter les associations et les attributs ;
• organiser et simplifier le modèle en éliminant les classes redondantes et en utilisant l'héritage ;
• le cas échéant, structurer les classes en paquetage selon les principes de cohérence et d'indépendance.

L'erreur la plus courante lors de la création d'un modèle du domaine consiste à modéliser un concept par un attribut alors que ce dernier devait être modélisé par une classe. Si la seule chose que recouvre un concept est sa valeur, il s'agit simplement d'un attribut. Par contre, si un concept recouvre un ensemble d'informations, alors il s'agit plutôt d'une classe qui possède elle-même plusieurs attributs.

Le diagramme de classes participantes est particulièrement important puisqu'il effectue la jonction entre, d'une part, les cas d'utilisation (section 9.2.1Diagramme de cas d'utilisation), le modèle du domaine (section 9.3.1Analyse du domaine : modèle du domaine) et la maquette (section 9.2.3Maquette de l'IHM), et d'autre part, les diagrammes de conception logicielle que sont les diagrammes d'interaction (section 9.4.1Diagrammes d'interaction) et le diagramme de classes de conception (section 9.4.2Diagramme de classes de conception). Les diagrammes de conception logicielle n'apparaissent pas encore sur la figure 9.6.

Il n'est pas souhaitable que les utilisateurs interagissent directement avec les instances des classes du domaine par le biais de l'interface graphique. En effet, le modèle du domaine doit être indépendant des utilisateurs et de l'interface graphique. De même, l'interface graphique du logiciel doit pouvoir évoluer sans répercussion sur le cœur de l'application. C'est le principe fondamental du découpage en couches d'une application. Ainsi, le diagramme de classes participantes modélise trois types de classes d'analyse, les dialogues, les contrôles et les entités ainsi que leurs relations.

• Les classes qui permettent les interactions entre l'IHM et les utilisateurs sont qualifiées de dialogues. Ces classes sont directement issues de l'analyse de la maquette présentée section 9.2.3Maquette de l'IHM. Il y a au moins un dialogue pour chaque association entre un acteur et un cas d'utilisation du diagramme de cas d'utilisation de la section 9.2.1Diagramme de cas d'utilisation. En général, les dialogues vivent seulement le temps du déroulement du cas d'utilisation concerné.

• Les classes qui modélisent la cinématique de l'application sont appelées contrôles. Elles font la jonction entre les dialogues et les classes métier en permettant aux différentes vues de l'application de manipuler des informations détenues par un ou plusieurs objets métier. Elles contiennent les règles applicatives et les isolent à la fois des dialogues et des entités.

• Les classes métier, qui proviennent directement du modèle du domaine (cf. section 9.3.1Analyse du domaine : modèle du domaine), sont qualifiées d'entités. Ces classes sont généralement persistantes, c'est-à-dire qu'elles survivent à l'exécution d'un cas d'utilisation particulier et qu'elles permettent à des données et des relations d'être stockées dans des fichiers ou des bases de données. Lors de l'implémentation, ces classes peuvent ne pas se concrétiser par des classes, mais par des relations, au sens des bases de données relationnelles (cf. section 3.6.3Implémentation en SQL ).

Lors de l'élaboration du diagramme de classes participantes, il faut veiller au respect des règles suivantes :

• les entités, qui sont issues du modèle du domaine, ne comportent que des attributs (cf. section 9.3.1Analyse du domaine : modèle du domaine) ;
• les entités ne peuvent être en association qu'avec d'autres entités ou avec des contrôles, mais, dans ce dernier cas, avec une contrainte de navigabilité interdisant de traverser une association d'une entité vers un contrôle ;
• les contrôles ne comportent que des opérations. Ils implémentent la logique applicative (i.e. les fonctionnalités de l'application), et peuvent correspondre à des règles transverses à plusieurs entités. Chaque contrôle est généralement associé à un cas d'utilisation, et vice versa. Mais rien n'empêche de décomposer un cas d'utilisation complexe en plusieurs contrôles ;
• les contrôles peuvent être associés à tous les types de classes, y compris d'autres contrôles. Dans le cas d'une association entre un dialogue et un contrôle, une contrainte de navigabilité doit interdire de traverser l'association du contrôle vers le dialogue ;
• les dialogues comportent des attributs et des opérations. Les attributs représentent des informations ou des paramètres saisis par l'utilisateur ou des résultats d'actions. Les opérations réalisent (généralement par délégation aux contrôles) les actions que l'utilisateur demande par le biais de l'IHM ;
• les dialogues peuvent être en association avec des contrôles ou d'autres dialogues, mais pas directement avec des entités ;
• il est également possible d'ajouter les acteurs sur le diagramme de classes participantes en respectant la règle suivante : un acteur ne peut être lié qu'à un dialogue.

Certaines classes possèdent un comportement dynamique complexe. Ces classes auront intérêt à être détaillées par des diagrammes d'états-transitions.

L'attribution des bonnes responsabilités, dégagée dans la section 9.2.2Diagrammes de séquence système, aux bonnes classes est l'un des problèmes les plus délicats de la conception orientée objet. Ce problème sera affronté en phase de conception lors de l'élaboration des diagrammes d'interaction (section 9.4.1Diagrammes d'interaction) et du diagramme de classes de conception (section 9.4.2Diagramme de classes de conception).

Lors de la phase d'élaboration du diagramme de classes participantes, le chef de projet a la possibilité de découper le travail de son équipe d'analystes par cas d'utilisation. L'analyse et l'implémentation des fonctionnalités dégagées par les cas d'utilisation définissent alors les itérations à réaliser. L'ordonnancement des itérations étant défini par le degré d'importance et le coefficient de risque affecté à chacun des cas d'utilisation dans la section 9.2.1Diagramme de cas d'utilisation.

Les IHM modernes facilitent la communication entre l'application et l'utilisateur en offrant toute une gamme de moyens d'action et de visualisation comme des menus déroulants ou contextuels, des palettes d'outils, des boîtes de dialogues, des fenêtres de visualisation, etc. Cette combinaison possible d'options d'affichage, d'interaction et de navigation aboutit aujourd'hui à des interfaces de plus en plus riches et puissantes.

UML offre la possibilité de représenter graphiquement cette activité de navigation dans l'interface en produisant des diagrammes dynamiques. On appelle ces diagrammes des diagrammes de navigation. Le concepteur a le choix d'opter pour cette modélisation entre des diagrammes d'états-transitions et des diagrammes d'activités. Les diagrammes d'activités constituent peut-être un choix plus souple et plus judicieux.

Les diagrammes d'activités de navigation sont à relier aux classes de dialogue du diagramme de classes participantes. Les différentes activités du diagramme de navigation peuvent être stéréotypées en fonction de leur nature : « fenêtre », « menu », « menu contextuel », « dialogue », etc.

La modélisation de la navigation a intérêt à être structurée par acteur.

Maintenant, il faut attribuer précisément les responsabilités de comportement, dégagées par le diagramme de séquence système dans la section 9.2.2Diagrammes de séquence système, aux classes d'analyse du diagramme de classes participantes élaboré dans la section 9.3.2Diagramme de classes participantes. Les résultats de cette réflexion sont présentés sous la forme de diagrammes d'interaction UML (figure 9.8). Inversement, l'élaboration de ces diagrammes facilite grandement la réflexion.

Parallèlement, une première ébauche de la vue statique de conception, c'est-à-dire du diagramme de classes de conception, est construite et complétée. Durant cette phase, l'ébauche du diagramme de classes de conception reste indépendante des choix technologiques qui seront faits ultérieurement (dans la section 9.4.2Diagramme de classes de conception).

Pour chaque service ou fonction, il faut décider quelle est la classe qui va le contenir. Les diagrammes d'interactions (i.e de séquence ou de communication) sont particulièrement utiles au concepteur pour représenter graphiquement ces décisions d'allocations des responsabilités. Chaque diagramme va représenter un ensemble d'objets de classes différentes collaborant dans le cadre d'un scénario d'exécution du système.

Dans les diagrammes d'interaction, les objets communiquent en s'envoyant des messages qui invoquent des opérations sur les objets récepteurs. Il est ainsi possible de suivre visuellement les interactions dynamiques entre objets, et les traitements réalisés par chacun d'eux. Avec un outil de modélisation UML (comme Rational Rose ou PowerAMC), la spécification de l'envoi d'un message entre deux objets crée effectivement une opération publique sur la classe de l'objet cible. Ce type d'outil permet réellement de mettre en œuvre l'allocation des responsabilités à partir des diagrammes d'interaction.

Par rapport aux diagrammes de séquences système de la section 9.2.2Diagrammes de séquence système, nous remplaçons ici le système, vu comme une boîte noire, par un ensemble d'objets en collaboration (cf. figure 9.9). Ces objets sont des instances des trois types de classes d'analyse du diagramme de classes participantes, à savoir des dialogues, des contrôles et des entités. Les diagrammes de séquences élaborés dans cette section doivent donc toujours respecter les règles édictées dans la section 9.3.2Diagramme de classes participantes. Ces règles doivent cependant être transposées, car, pour que deux objets puissent interagir directement, il faut que :

• les classes dont ils sont issus soient en association dans le diagramme de classes participantes(15) ;
• l'interaction respecte la navigabilité de l'association en question.

L'objectif de cette étape est de produire le diagramme de classes qui servira pour l'implémentation (figure 9.10). Une première ébauche du diagramme de classes de conception a déjà été élaborée en parallèle du diagramme d'interaction (section 9.4.1Diagrammes d'interaction). Il faut maintenant le compléter en précisant les opérations privées des différentes classes. Il faut prendre en comptes les choix techniques, comme le choix du langage de programmation, le choix des différentes bibliothèques utilisées (notamment pour l'implémentation de l'interface graphique), etc.

Pour une classe, le couplage est la mesure de la quantité d'autres classes auxquelles elle est connectée par des associations, des relations de dépendances, etc. Durant toute l'élaboration du diagramme de classes de conception, il faut veiller à conserver un couplage faible pour obtenir une application plus évolutive et plus facile à maintenir. L'utilisation des design patterns est fortement conseillée lors de l'élaboration du diagramme de classes de conception.

Pour le passage à l'implémentation, referez-vous à la section 3.6Élaboration et implémentation d'un diagramme de classes. Parfois, les classes du type entités ont intérêt à être implémentées dans une base de données relationnelle (cf. section 3.6.3Implémentation en SQL ).