Memoire Online - Plateformes de services intégrés pour mobiles

Un projet informatique, quelle que soit sa taille et la portée de ses objectifs, nécessite la mise en place d'un planning organisationnel tout au long de son cycle de vie. C'est ainsi qu'est apparue la notion de méthode.

Une méthode, dans le contexte informatique, peut être définie comme une démarche fournissant une méthodologie et des notations standards qui aident à concevoir des logiciels de qualité.

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence. Un modèle est un langage commun, précis, qui est connu par tous les membres de l'équipe et il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle pour aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la maîtrise d'ouvrage et la maîtrise d'oeuvre informatique) et précise d'un problème donné.

Dans le domaine de l'ingénierie du logiciel, le modèle permet de mieux répartir les tâches et d'automatiser certaines d'entre elles. C'est également un facteur de réduction des coûts et des délais. Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour faire de la génération de code (au moins au niveau du squelette) voire des allers-retours entre le code et le modèle sans perte d'information. Le modèle est enfin indispensable pour assurer un bon niveau de qualité et une maintenance efficace car, une fois mise en production, l'application va devoir être maintenue, probablement par une autre équipe et, qui plus est, pas nécessairement de la même société que celle ayant créée l'application. Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes non triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles employés, la démarche de modélisation n'est pas la même.

Dans ce chapitre, nous ferons une étude approfondie de l'ensemble des méthodes d'analyse et de conception existantes. Enfin nous effectuerons un choix parmi ces dites méthodes.

Une méthode fait intervenir essentiellement les concepts d'analyse et de conception.

Correspondant à la phase qui répond à la question « que fait le système », l'analyse est l'une des étapes les plus importantes et les plus difficiles de la modélisation. Elle permet de modéliser le domaine d'application, d'analyser l'existant et les contraintes de réalisation. Elle s'effectue par une abstraction et une séparation des problèmes. Elle peut être découpée en trois phases que sont :

Il s'agit d'identifier les acteurs et les cas d'utilisation, de structurer le modèle, et d'identifier les autres exigences.

Elle consiste à collecter des informations (interviews, lecture de documentation) et à la compréhension du domaine et du problème posé.

A ce niveau il s'agit de restituer les besoins dans un langage compréhensible par le client et de procéder à l'identification, à la structuration et à la définition d'un dictionnaire.

Dans cette phase il sera question d'aller à un niveau de spécification plus détaillé voire même plus formel des besoins. Elle sera d'une grande utilité pour le client mais aussi pour le développeur.

A la fin de cette phase d'analyse un modèle conceptuel sera disponible, lequel modèle sera un outil fondamental lors de la phase de conception.

Phase menée à la suite de l'analyse des besoins, la conception met en oeuvre tout un ensemble d'activités qui à partir d'une demande d'informatisation d'un processus permettent la conception, l'écriture et la mise au point d'un produit informatique (et donc de programmes informatiques) jusqu'à sa livraison au demandeur. Elle a comme objectifs de répondre à la question « comment faire le système ?» et de décomposer de façon modulaire le système à mettre en place. La conception définit l'architecture du logiciel. Elle définit par la même occasion chaque constituant du logiciel (Informations traitées, traitements effectués, résultats fournis, contraintes à respecter. A la suite un modèle logique utilisable à la phase d'implémentation est produit.

Cette phase consiste à la mise en oeuvre des programmes dans un langage de programmation conformément aux spécifications définies dans les phases précédentes. Elle renferme en son sein les phases de test et de mise au point (débogage). A la sortie il sera produit un modèle physique (collection de modules implémentés mais non testés, documentation de programmation expliquant le code).

Malgré la diversité des méthodes d'analyse et de conception, il est possible de les classer en trois catégories :

Avec cette méthode, le système étudié est abordé par les fonctions qu'il doit assurer plutôt que par les données qu'il doit gérer. Le processus de conception est vu comme un développement linéaire. Il y a décomposition systématique du domaine étudié en sous domaines, eux-mêmes décomposés en sous-domaines jusqu'à un niveau considéré élémentaire. SADT (Structured-Analysis-Design-Technique) en est un exemple.

Les méthodes systémiques sont des méthodes s'appuyant sur une approche systémique. Elles définissent différents niveaux de préoccupation ou d'abstraction et proposent de nombreux modèles complémentaires. Les méthodes systémiques sont souvent spécialisées pour la conception d'un certain type de systèmes. Comme exemple de méthode systémique nous pouvons citer MERISE, AXIAL ...

Ce sont des méthodes consistant à créer une représentation informatique des éléments du monde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs données et les fonctions qui les utilisent. Pour cela des méthodes ont été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches orientées objets, si bien qu'en 1994 il existait plus de 50 méthodes objet. Toutefois seules 3 méthodes ont véritablement émergé :

Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling) visent à réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des tests tout au long du cycle de développement.

L'origine des méthodes agiles est liée à l'instabilité de l'environnement technologique et au fait que le client est souvent dans l'incapacité de définir ses besoins de manière exhaustive dès le début du projet. Le terme « agile » fait ainsi référence à la capacité d'adaptation aux changements de contexte et aux modifications de spécifications intervenant pendant le processus de développement. En 2001, 17 personnes mirent ainsi au point le manifeste agile dont la traduction est la suivante :

Grâce aux méthodes agiles, le client est pilote à part entière de son projet et obtient très vite une première mise en production de son logiciel. Ainsi, il est possible d'associer les utilisateurs dès le début du projet. Comme méthode agile nous pouvons citer eXtreme Programming (XP).

Pour l'analyse et la conception de notre application nous opterons pour une méthode orientée objet. Une méthode étant un assemblage d'une démarche et d'un langage de modélisation, nous allons choisir le tandem le plus adéquat.

RAD (Rapid Application Development) est une méthode de conduite de projet permettant de développer rapidement des applications de qualité. Aujourd'hui qualité et réactivité font partie des objectifs généraux de beaucoup d'entreprises. Cela entraine un certain nombre de projets, qui tout en apportant satisfaction aux utilisateurs, doivent être menés dans un délai court. C'est à cela que répond la méthode RAD.

La méthode RAD propose de remplacer le cycle de vie classique par un autre découpage temporaire. Le déroulement est d'abord linéaire, puis il suit le modèle de la spirale. Les étapes sont au nombre de cinq :

L'étape Initialisation : l'objectif est de sélectionner les acteurs pertinents, de structurer le travail en thèmes et d'amorcer une dynamique. Elle ne dépasse pas 15 jours.

L'étape Expression des besoins : l'objectif est de mettre à jour ce qui sera utile aux utilisateurs. On utilise la technique du JRP^1(*) qui organise le travail en session. La durée de cette étape est fonction du nombre d'utilisateurs concernés. Elle ne dépasse pas 30 jours.

L'étape Conception : l'objectif est de concevoir une solution. Les techniques utilisées sont le JAD^2(*) et le prototypage. L'étape ne dépasse pas 60 jours.

L'étape Construction : il s'agit, fonction par fonction, de construire un système viable. Les techniques utilisées sont la time-box^3(*) et le prototypage. Cette étape ne dépasse pas 120 jours.

L'étape Mise en oeuvre : des recettes partielles ont été faites à l'étape construction. Il s'agit ici d'officialiser une livraison globale, de l'optimiser éventuellement, d'installer le nouveau système et de faire le bilan du projet.

La méthode DSDM (Dynamic Software Development Method) a été mise au point en s'appuyant sur la méthode RAD afin de combler certaines de ses lacunes, notamment en offrant un canevas prenant en compte l'ensemble du cycle de développement.

· L'acceptation des produits livrés dépend directement de la satisfaction des besoins

La méthode du Processus Unifié (UP pour Unified Process) est un processus de développement itératif et incrémental, ce qui signifie que le projet est découpé en phases très courtes à l'issue de chacune desquelles une nouvelle version incrémentée est livrée.

Il s'agit d'une démarche s'appuyant sur la modélisation UML pour la description de l'architecture du logiciel (fonctionnelle, logicielle et physique) et la mise au point de cas d'utilisation permettant de décrire les besoins et exigences des utilisateurs.

RUP (Rational Unified Process) est une méthode de développement par itérations promue par la société Rational Software, rachetée par IBM. RUP propose une méthode spécifiant notamment la composition des équipes et le calendrier ainsi qu'un certain nombre de modèles de documents. RUP est l'une des plus célèbres implémentations de la démarche UP, livrée clé en main, permettant de donner un cadre de développement logiciel, répondant aux exigences fondamentales préconisées par les créateurs d'UML. RUP est une version commerciale d'UP.

La méthode XP (pour eXtreme Programming) définit un certain nombre de bonnes pratiques permettant de développer un logiciel dans des conditions optimales en plaçant le client au coeur du processus de développement, en relation étroite avec le client.

· Les équipes de développement travaillent directement avec le client sur des cycles très courts d'une à deux semaines maximum.

· Les livraisons de versions du logiciel interviennent très tôt et à une fréquence élevée pour maximiser l'impact des retours utilisateurs.

· L'équipe de développement travaille en collaboration totale sur la base de binômes.

· Des indicateurs permettent de mesurer l'avancement du projet afin de permettre la mise à jour du plan de développement.

Le choix de la démarche se fera en prenant en compte des critères essentiels de la plateforme à concevoir. Pour des raisons d'efficacité, de rapidité et d'analyse complète, nous opterons en effet pour un processus situé à mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et XP (eXtreme Programming), une approche minimaliste à la mode centrée sur le code.

UP (Unified Process) est une méthode générique de développement de logiciels.

Générique signifie qu'il est nécessaire d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de l'organisation (exemple: R.UP ou X.UP). C'est plus ou moins vrai pour toute méthode, qu'elle se définisse elle-même comme générique ou pas.

Le processus unifié est une démarche de développement logiciel : il regroupe les activités à mener pour transformer les besoins d'un utilisateur en système logiciel.

L'objectif principal d'un système logiciel est de rendre service à ses utilisateurs ; il faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de développement sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne pas seulement les utilisateurs humains mais également les autres systèmes. L'utilisateur représente donc une personne ou une chose dialoguant avec le système en cours de développement. Ce type d'interaction est appelé cas d'utilisation illustré par le schéma suivant :

Les cas d'utilisation font apparaître les besoins fonctionnels et leur ensemble constitue le modèle des cas d'utilisation qui décrit les fonctionnalités complètes du système.

Les cas d'utilisation ne sont pas un simple outil de spécification des besoins du système. Ils vont complètement guider le processus de développement à travers l'utilisation de modèles basés sur l'utilisation du langage UML.

Ø A partir du modèle des cas d'utilisation, les développeurs créent une série de modèles de conception et d'implémentation réalisant les cas d'utilisation.

Ø Chacun des modèles successifs est ensuite révisé pour en contrôler la conformité par rapport au modèle des cas d'utilisation.

Ø Enfin, les testeurs testent l'implémentation pour s'assurer que les composants du modèle d'implémentation mettent correctement en oeuvre les cas d'utilisation.

Les cas d'utilisation garantissent la cohérence du processus de développement du système. S'il est vrais que les cas d'utilisation guident le processus de développement, ils ne sont pas sélectionnés de façon isolée, mais doivent absolument être développés "en tandem" avec l'architecture du système.

Dès le démarrage du processus, on aura une vue sur l'architecture à mettre en place. L'architecture d'un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. L'architecture logicielle équivaut aux aspects statiques et dynamiques les plus significatifs du système. L'architecture émerge des besoins de l'entreprise, tels qu'ils sont exprimés par les utilisateurs et autres intervenants et tels qu'ils sont reflétés par les cas d'utilisation.

Tout produit est à la fois forme et fonction. Les cas d'utilisation doivent une fois réalisés, trouver leur place dans l'architecture. L'architecture doit prévoir la réalisation de tous les cas d'utilisation. L'architecture et les cas d'utilisation doivent évoluer de façon concomitante.

ü L'architecte crée une ébauche grossière de l'architecture, en partant de l'aspect qui n'est pas propre aux cas d'utilisation (plateforme..). Bien que cette partie de l'architecture soit indépendante des cas d'utilisation, l'architecte doit avoir une compréhension globale de ceux-ci avant d'en esquisser l'architecture.

ü Il travaille ensuite, sur un sous ensemble des cas d'utilisations identifiés, ceux qui représentent les fonctions essentielles du système en cours de développement.

ü L'architecture se dévoile peu à peu, au rythme de la spécification et de la maturation des cas d'utilisation, qui favorisent, à leur tour, le développement d'un nombre croissant de cas d'utilisation.

Le développement d'un produit logiciel destiné à la commercialisation est une vaste entreprise qui peut s'étendre sur plusieurs mois. On ne va pas tout développer d'un coup. On peut découper le travail en plusieurs parties qui sont autant de mini projets, chacun d'entre eux représentant une itération qui donne lieu à un incrément.

Une itération désigne la succession des étapes de l'enchaînement d'activités, tandis qu'un incrément correspond à une avancée dans les différents stades de développement.

Le choix de ce qui doit être implémenté au cours d'une itération repose sur deux facteurs :

· Une itération prend en compte un certain nombre de cas d'utilisations qui, ensemble, améliorent l'utilisabilité du produit à un certain stade de développement.

Un incrément constitue souvent un additif. A chaque itération, les développeurs identifient et spécifient les cas d'utilisations pertinents, créent une conception en se laissant guider par l'architecture choisie, implémentent cette conception sous forme de composants et vérifient que ceux-ci sont conformes aux cas d'utilisation. Dés qu'une itération répond aux objectifs fixés le développement passe à l'itération suivante. Pour rentabiliser le développement il faut sélectionner les itérations nécessaires pour atteindre les objectifs du projet. Ces itérations devront se succéder dans un ordre logique. Un projet réussi suivra un déroulement direct établi dès le début par les développeurs et dont ils ne s'éloigneront que de façon très marginale. L'élimination des problèmes imprévus fait partie des objectifs de réduction des risques. Les avantages d'un processus unifié contrôlé sont :

Ø la limitation des coûts, en termes de risques, aux strictes dépenses liées à une itération,

Ø la limitation des risques de retard de mise sur le marché du produit développé (identification des problèmes dès les premiers stades de développement et non en phase de test comme avec l'approche « classique »),

Ø l'accélération du rythme de développement grâce à des objectifs clairs et à court terme,

Ø la prise en compte du fait que les besoins des utilisateurs et les exigences correspondantes ne peuvent être intégralement définis à l'avance et se dégagent peu à peu des itérations successives.

L'architecture fournit la structure qui servira de cadre au travail effectué au cours des itérations, tandis que les cas d'utilisation définissent les objectifs et orientent le travail de chaque itération. Il ne faut donc pas mésestimer l'un des trois concepts.

Le processus unifié répète un certain nombre de fois une série de cycles. Tout cycle se conclut par la livraison d'une version du produit aux clients et s'articule en 4 phases : création, élaboration, construction et transition, chacune d'entre elles se subdivisant à son tour en itérations.

Chaque cycle se traduit par une nouvelle version du système. Ce produit se compose d'un corps de code source réparti sur plusieurs composants pouvant être compilés et exécutés et s'accompagne de manuels et de produits associés. Pour mener efficacement le cycle, les développeurs ont besoin de construire toutes les représentations du produit logiciel :

Modèle des cas d'utilisation	Expose les cas d'utilisation et leurs relations avec les utilisateurs
Modèle d'analyse	Détaille les cas d'utilisation et procède à une première répartition du comportement du système entre divers objets
Modèle de conception	Définit la structure statique du système sous forme de sous système, classes et interfaces ; Définit les cas d'utilisation réalisés sous forme de collaborations entre les sous systèmes les classes et les interfaces
Modèle d'implémentation	Intègre les composants (code source) et la correspondance entre les classes et les composants
Modèle de déploiement	Définit les noeuds physiques des ordinateurs et l'affectation de ces composants sur ces noeuds.
Modèle de test	Décrit les cas de test vérifiant les cas d'utilisation
Représentation de l'architecture	Description de l'architecture

Tous ces modèles sont liés. Ensemble, ils représentent le système comme un tout. Les éléments de chacun des modèles présentent des dépendances de traçabilité ; ce qui facilite la compréhension et les modifications ultérieures.

Première phase du cycle de vie du processus unifié, la création traduit une idée en vision de produit fini et présente l'étude de rentabilité pour ce produit. Elle essaie de répondre à un certain nombre de questions : Que va faire le système pour les utilisateurs ? A quoi peut ressembler l'architecture d'un tel système ? Quels sont l'organisation et les coûts du développement de ce produit ? C'est à ce niveau où les principaux cas d'utilisation seront spécifiés. L'identification des risques majeurs, la mise sur place d'une architecture provisoire du système à concevoir et la préparation de la phase d'élaboration seront les principales tâches à effectuer durant cette étape de la création.

Elle permet de préciser la plupart des cas d'utilisation et de concevoir l'architecture du système. L'architecture doit être exprimée sous forme de vue de chacun des modèles. Lors de cette phase une architecture de référence sera conçue. Au terme de cette étape, le chef de projet doit être en mesure de prévoir les activités et d'estimer les ressources nécessaires à l'achèvement du projet.

C'est le moment où l'on construit le produit. L'architecture de référence se métamorphose en produit complet, elle est maintenant stable. Le produit contient tous les cas d'utilisation que les chefs de projet, en accord avec les utilisateurs ont décidé de mettre au point pour cette version. Celle ci doit encore avoir des anomalies qui peuvent être en partie résolue lors de la phase de transition.

Le produit est en version bêta. Un groupe d'utilisateurs essaye le produit et détecte les anomalies et défauts. Cette phase suppose des activités comme la fabrication, la formation des utilisateurs clients, la mise en oeuvre d'un service d'assistance et la correction des anomalies constatées (ou le report de leur correction à la version suivante).

L'eXtreme Programming ou XP, est une méthode de développement de projet mise au point à la fin des années 90 par Kent Beck, Ward Cunningham et Ron Jeffries.
XP doit son nom au fait qu'elle place l'activité de programmation au centre du projet, et qu'elle obtient ses résultats en combinant et en poussant à l'extrême certaines pratiques de développement. XP est un ensemble de pratiques qui couvre une grande partie des activités de la réalisation d'un logiciel, de la programmation proprement dite à la planification du projet, en passant par l'organisation de l'équipe de développement et les échanges avec le client. Ces pratiques n'ont en soi rien de révolutionnaire : il s'agit simplement de pratiques de bon sens, mises en oeuvre par des développeurs ou des chefs de projet expérimentés, telles que :

· Un utilisateur à plein-temps dans la salle projet. Ceci permet une communication intensive et permanente entre les clients et les développeurs, aussi bien pour l'expression des besoins que pour la validation des livraisons.

· Écrire le test unitaire avant le code qu'il doit tester, afin d'être certain que le test sera systématiquement écrit et non pas négligé.

· Programmer en binôme, afin d'homogénéiser la connaissance du système au sein des développeurs, ainsi que de permettre aux débutants d'apprendre des experts. Le code devient ainsi une propriété collective et non individuelle que tous les développeurs ont le droit de modifier.

· Intégrer de façon continue, pour ne pas retarder à la fin du projet le risque majeur de l'intégration des modules logiciels écrits par des équipes ou des personnes différentes.

Communication : La communication est la composante fondamentale de tout travail en équipe. XP installe la communication dans le projet à tous les niveaux.

Simplicité : Communication et retour d'information : ces dispositions sont menacées, à mesure que le produit évolue et s'accroît, par la lourdeur et l'inertie du processus. Pour cette raison, XP érige la simplicité en véritable discipline, tant au niveau de la conception que du processus lui-même (scénarios utilisateur, séances de planifications, propriété collective du code, pas de spécialisations techniques).

Feedback : Le retour d'information permet de tracer et d'ajuster le processus en vue d'améliorer la qualité, la maintenance et la productivité. A chacune des tâches de production, XP câble un mécanisme ou une pratique permettant de valider cette production de manière quasiment continue.

Courage : La force d'une équipe même dotée d'une approche efficace ne se mesure pas tant à ce qu'elle fait lorsque tout va bien, qu'à la manière dont elle affronte les difficultés. Pour cette raison XP valorise également le Courage.

Elle est bien adaptée pour des projets de taille moyenne où le contexte (besoins utilisateurs, technologies informatiques) évolue en permanence.

L'eXtreme Programming repose sur des cycles rapides de développement (des itérations de quelques semaines) dont les étapes sont les suivantes :

· une phase d'exploration qui détermine les scénarios clients qui seront fournis pendant cette itération ;

· une phase de planning où l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;

· une phase de mise en production où chaque développeur s'attribue des tâches et les réalise avec un binôme ;

· une phase de maintenance lorsque tous les tests fonctionnels passent, le produit est livré.

Le cycle se répète tant que le client peut fournir des scénarios à livrer. La première livraison est généralement plus importante et n'est réalisée qu'après quelques itérations. Après la première mise en production, les itérations peuvent devenir plus courtes (une semaine par exemple).

La problématique que pose la mise en oeuvre d'UML est simple : comment passer de l'expression des besoins au code de l'application ? Comment obtenir le plus efficacement possible un code informatique opérationnel, complet, testé, et qui réponde parfaitement aux besoins exprimés par les utilisateurs ?

Dans un premier temps, les besoins vont être modélisés au moyen des cas d'utilisation UML. Ils seront également représentés de façon plus concrète par une maquette d'IHM (Interface Homme Machine) destinée à faire réagir les futurs utilisateurs.

Dans le cadre des systèmes orientés-objets, la structure du code est définie par les classes logicielles et leurs regroupements en ensembles appelés packages. Nous avons donc besoin de diagrammes représentant les classes logicielles et montrant les données qu'elles contiennent (attributs), les services qu'elles rendent (opérations) ainsi que leurs relations. UML propose les diagrammes de classes pour véhiculer toutes ces informations.

Les diagrammes de classes de conception représentent bien la structure statique du code, par le biais des attributs et des relations entre classes, mais ils contiennent également les opérations (méthodes) qui décrivent les responsabilités dynamiques des classes logicielles. L'attribution des bonnes responsabilités aux bonnes classes est l'un des problèmes les plus délicats de la conception orientée-objet. Pour chaque service ou fonction, il faut décider quelle est la classe qui va le contenir. Nous devons ainsi répartir tout le comportement du système entre les classes de conception et décrire les collaborations induites.

Les diagrammes d'interactions UML (séquence ou collaboration) sont particulièrement utiles au concepteur pour représenter graphiquement ses décisions d'allocation de responsabilités. Chaque diagramme d'interaction va ainsi 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 ce genre de diagramme, les objets communiquent en s'envoyant des messages qui invoquent des opérations sur les objets récepteurs.

On peut donc suivre visuellement les interactions dynamiques entre objets, et les traitements réalisés par chacun. Les diagrammes d'interaction aident également à écrire le code à l'intérieur des opérations, en particulier les appels d'opérations imbriqués. La figure suivante ajoute une étape du côté du code, mais ne nous dit pas encore comment relier tout cela aux cas d'utilisation.

Comment passer des cas d'utilisation aux diagrammes d'interaction ? Ce n'est pas simple ni direct car les cas d'utilisation sont au niveau d'abstraction des besoins utilisateurs alors que les diagrammes d'interaction se placent au niveau de la conception objet. Il faut donc au moins une étape intermédiaire.

Chaque cas d'utilisation est décrit textuellement de façon détaillée, mais donne également lieu à un diagramme de séquence représentant graphiquement la séquence des interactions entre les acteurs et le système vu comme une boîte noire, dans le cadre du scénario nominal. Nous appellerons ce diagramme : diagramme de séquence système.

Par la suite, en remplaçant le système vu comme une boîte noire par un ensemble choisi d'objets de conception, nous décrirons l'attribution des responsabilités dynamiques, tout en conservant une traçabilité forte avec les cas d'utilisation. La figure ci-après montre ainsi les diagrammes de séquence système en tant que lien important entre les cas d'utilisation et les diagrammes d'interaction.

Mais comment trouver ces fameuses classes de conception qui interviennent dans les diagrammes d'interactions ?

Les classes logicielles représentant l'informatisation des concepts métier manipulés par les experts du domaine et les utilisateurs sont assez directement trouvées par une analyse du domaine. Pour matérialiser cette analyse, nous allons construire un modèle du domaine, sorte de glossaire détaillé et formalisé en UML des concepts fondamentaux de l'espace du problème. Ces concepts, leurs attributs et leurs relations vont être décrits en UML par un diagramme de classes simplifié utilisant des conventions particulières. Comme indiqué sur la figure suivante, le modèle du domaine fournit une partie des classes de conception, celles correspondant directement aux concepts métier. Il découle des cas d'utilisation et de l'analyse des besoins

Mais le modèle du domaine à lui seul ne permet pas d'identifier les principales classes d'IHM ni celles qui décrivent la cinématique de l'application. Le chaînon manquant de notre démarche s'appelle les diagrammes de classes participantes. Il s'agit là encore de diagrammes de classes UML qui décrivent, cas d'utilisation par cas d'utilisation, les trois principales classes d'analyse et leurs relations.

· Les classes qui permettent les interactions entre l'application et ses utilisateurs sont qualifiées de « dialogues ». Ce sont typiquement les écrans proposés à l'utilisateur : les formulaires de saisie, les résultats de recherche, etc. Elles proviennent directement de l'analyse de la maquette.

· Celles qui contiennent la cinématique de l'application seront appelées « contrôles ». Elles font la transition entre les dialogues et les classes métier, en permettant aux écrans de manipuler des informations détenues par un ou plusieurs objets métier.

· Celles qui représentent les règles métier sont qualifiées d'« entités ». Elles proviennent directement du modèle du domaine, mais sont confirmées et complétées cas d'utilisation par cas d'utilisation.

Un avantage important de cette technique pour le chef de projet consiste en la possibilité de découper le travail de son équipe d'analyste suivant les différents cas d'utilisation, plutôt que de vouloir tout traiter d'un bloc. En outre, le modèle du domaine joue le rôle de référence commune et d'arbitre en ce qui concerne les entités découvertes par les différentes équipes. Comme l'illustre la figure ci-après, les diagrammes de classes participantes sont particulièrement importants car ils font la jonction entre le les cas d'utilisation, le modèle du domaine, la maquette et les diagrammes de conception logicielle (diagrammes d'interaction et diagrammes de classes).

Pour que le tableau soit complet, il nous reste à détailler une exploitation supplémentaire de la maquette. Elle va nous permettre de réaliser des diagrammes dynamiques représentant de manière formelle l'ensemble des chemins possibles entre les principaux écrans proposés à l'utilisateur. Ces diagrammes s'appellent des diagrammes d'activités de navigation.
La trame globale de la démarche est ainsi finalisée, comme indiqué sur la figure suivante.

UML (en anglais Unified Modeling Language, « langage de modélisation unifié ») est un langage graphique de modélisation des données et des traitements. C'est une formalisation très aboutie et non-propriétaire de la modélisation objet utilisée en génie logiciel. UML est l'accomplissement de la fusion des meilleures approches de la modélisation objet (Booch, OMT, OOSE) effectuée en 1995. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par l'OMG (Object Management Group).

UML a démarré avec la version 0.8 intégrant les méthodes BOOCH 93 et OMT. Par la suite il y a eu l'avènement de la version 0.9 ayant intégré la méthode OOSE. La version 1.0, proposé à l'OMG en 1996, fut finalement standardisée en 1997 sous la version 1.1. Depuis cette année il ya eu quatre révisions du standard (de UML 1.1 à UML 1.5 en 2003). Les dernières améliorations étant conséquentes, UML est passé à une nouvelle version : UML 2.0 (ou UML 2), abrégé souvent en U2. Cette figure ci-dessous montre l'évolution des versions d'UML depuis sa genèse.

On appelle objet un élément matériel ou immatériel, dans la réalité étudiée, qui satisfait aux principes de distinction, de permanence et d'activité. Cela entraine qu'un objet possède une identité, un état et un comportement. Un objet communique avec ses utilisateurs (ou clients) par le biais de son interface. L'interface d'un objet est la liste des services qu'il peut rendre et des ressources qu'il souhaite mettre à la disposition de ses clients.

Une classe est un ensemble d'objet sur lesquels on peut reconnaître des similitudes dans le champ d'étude. Ces similitudes portent sur la façon de les identifier, sur les types d'états qu'ils peuvent prendre et sur le rôle qu'ils jouent.

Lors de la modélisation d'un système d'information certains objets sont porteurs d'informations concrètes, manipulées, transmises ou mémorisées. On les qualifie d'objets informationnels. Une entité est donc un ensemble d'objets sur lesquels on peut reconnaître la même structure et qui sont gérés de la même façon

UML n'emploie pas le terme d'utilisateur mais d'acteur. Les acteurs d'un système sont les entités externes à ce système qui interagissent (saisie de données, réception d'information, ...) avec lui. Les acteurs sont donc à l'extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l'interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur l'interface et donc la définition du système à produire.

Le terme processus vient du latin « progrès » et signifie littéralement « aller de l'avant » ; cela évoque l'idée d'une marche progressive ou d'un plan déterminé à l'avance. On appelle processus l'organisation d'un ensemble finalisé d'activités effectuées par des acteurs et mettant en jeu des entités, pour répondre à un type d'événement.

Diverses perspectives ou vues peuvent être prises en compte dans la modélisation d'un système d'informations. Le langage UML en a défini cinq (05) qui sont complémentaires et qui guident l'utilisation des concepts objets : il s'agit de l'architecture 4+1 centrée sur la vue utilisateur représentée par la figure ci-dessous.

Cette vue appelée vue de haut niveau se concentre sur l'abstraction et l'encapsulation. C'est à ce niveau que s'effectue la modélisation des éléments et mécanismes principaux du système. La vue logique permet d'identifier les éléments du domaine, ainsi que les relations et interactions entre ces éléments : les éléments du domaine étant le(s) métier(s) de l'entreprise. Ils sont d'une importance capitale dans la mission future du système, ils gagnent à être réutilisés (ils représentent un savoir-faire). Cette vue permet aussi d'organiser, (selon des critères purement logiques), les éléments du domaine en "catégories" : pour répartir les tâches dans les équipes, regrouper ce qui peut être générique, isoler ce qui est propre à une version donnée, etc.

Cette vue de bas niveau (aussi appelée "vue de réalisation"), montre : L'allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de données, exécutables, etc.). En d'autres termes, cette vue identifie les modules qui réalisent (physiquement) les classes de la vue logique. Elle définit aussi l'organisation des composants, c'est-à dire la distribution du code en gestion de configuration, les dépendances entre les composants... Les contraintes de développement (bibliothèques externes...). La vue des composants montre aussi l'organisation des modules en "sous-systèmes", les interfaces des sous-systèmes et leurs dépendances (avec d'autres sous-systèmes ou modules).

Cette vue est d'une très grande importante dans les environnements multitâches ; elle montre :

Cette vue très importante dans les environnements distribués, décrit les ressources matérielles et la répartition du logiciel dans ces ressources :

o la disposition et nature physique des matériels, ainsi que leurs performances,

o les exigences en termes de performances (temps de réponse, tolérance aux fautes et pannes...).

Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres. Dessiner le plan (l'architecture) d'un système informatique n'est pas suffisant, il faut le justifier ! Cette vue définit les besoins des clients du système et centre la définition de l'architecture du système sur la satisfaction (la réalisation) de ces besoins. A l'aide de scénarios et de cas d'utilisation, cette vue conduit à la définition d'un modèle d'architecture pertinent et cohérent. Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture. Elle motive les choix, permet d'identifier les interfaces critiques et force à se concentrer sur les problèmes importants.

UML n'est pas une méthode (i.e. une description normative des étapes de la modélisation) : ses auteurs ont en effet estimé qu'il n'était pas opportun de définir une méthode en raison de la diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet de représenter, de communiquer les divers aspects d'un système d'information (aux graphiques sont, bien sûr, associés des textes qui expliquent leur contenu). UML est donc un métalangage car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet.

Il est impossible de donner une représentation graphique complète d'un logiciel, ou de tout autre système complexe, de même qu'il est impossible de représenter entièrement une statue (à trois dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel système des vues partielles, analogues chacune à une photographie d'une statue, et dont la juxtaposition donnera une idée utilisable en pratique sans risque d'erreur grave.

UML 2.0 en a rajouté quatre. Ces treize types de diagrammes représentent autant de vues distinctes pour représenter des concepts particuliers du système d'information. Ils se répartissent en deux grands groupes :

· diagramme de structures composites (Composite structure diagram) rajouté par UML 2.0

o diagramme global d'interaction (Interaction overview diagram) rajouté par UML 2.0

Ces diagrammes, d'une utilité variable selon les cas, ne sont pas nécessairement tous produits à l'occasion d'une modélisation. Les plus utiles pour la maîtrise d'ouvrage sont les diagrammes d'activités, de cas d'utilisation, de classes, d'objets, de séquence et d'états transitions. Les diagrammes de composants, de déploiement et de communication sont surtout utiles pour la maîtrise d'oeuvre à qui ils permettent de formaliser les contraintes de la réalisation et la solution technique. Dans la suite nous allons présenter les diagrammes utilisés dans notre modélisation.

Le diagramme de classes est considéré comme le plus important de la modélisation orienté objet et le seul obligatoire lors d'une telle modélisation. Il montre la structure interne d'un système à mettre en place. Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d'utilisation. Il est important de noter qu'un même objet peut très bien intervenir dans la réalisation de plusieurs cas d'utilisation. Les cas d'utilisation ne réalisent donc pas une partition des classes du diagramme de classes. Un diagramme de classes n'est donc pas adapté (sauf cas particulier) pour détailler, décomposer, ou illustrer la réalisation d'un cas d'utilisation particulier. Il s'agit d'une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise les concepts du domaine d'application ainsi que les concepts internes créés de toutes pièces dans le cadre de l'implémentation d'une application. Chaque langage de Programmation Orientée Objets donne un moyen spécifique d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de programmation particulier. Les principaux éléments de cette vue statique sont les classes et leurs relations : association, généralisation et plusieurs types de dépendances, telles que la réalisation et l'utilisation.

Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs besoins. C'est précisément le rôle des diagrammes de cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les besoins, et de recenser les grandes fonctionnalités d'un système. Il s'agit donc de la première étape UML d'analyse d'un système.

Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-système, d'une classe ou d'un composant tel qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d'utilisation, ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d'une vision informatique.

Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux attentes des utilisateurs. Pour élaborer les cas d'utilisation, il faut se fonder sur des entretiens avec les utilisateurs.

· Acteur : un acteur est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système.

· Cas d'utilisation : un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.

· Association : Une association est le chemin de communication entre un acteur et un cas d'utilisation.

Le diagramme de séquence est une représentation intuitive lorsque l'on souhaite concrétiser des interactions entre deux entités (deux sous-systèmes ou deux classes d'un futur logiciel). Ils permettent à l'architecte/designer de créer au fur et à mesure sa solution. Cette représentation intuitive est également un excellent vecteur de communication dans une équipe d'ingénierie pour discuter cette solution.

Les diagrammes de séquence peuvent également servir à la problématique de test. Les traces d'exécution d'un test peuvent en effet être représentées sous cette forme et servir de comparaison avec les diagrammes de séquence réalisés lors des phases d'ingénierie. Le diagramme de séquence permet aussi de représenté un scénario^4(*) d'un cas d'utilisation.

Les diagrammes d'activités permettent de mettre l'accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils permettent ainsi de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation.

Les diagrammes d'activités sont relativement proches des diagrammes d'états-transitions^5(*) dans leur présentation, mais leur interprétation est sensiblement différente. Les diagrammes d'états-transitions sont orientés vers des systèmes réactifs, mais ils ne donnent pas une vision satisfaisante d'un traitement faisant intervenir plusieurs classeurs et doivent être complétés, par exemple, par des diagrammes de séquence. Au contraire, les diagrammes d'activités ne sont pas spécifiquement rattachés à un classeur particulier. Ils permettent de spécifier des traitements a priori séquentiels et offrent une vision très proche de celle des langages de programmation impératifs comme C++ ou Java.

Dans la phase de conception, les diagrammes d'activités sont particulièrement adaptés à la description des cas d'utilisation. Plus précisément, ils viennent illustrer et consolider la description textuelle des cas d'utilisation. De plus, leur représentation sous forme d'organigrammes les rend facilement intelligibles et beaucoup plus accessibles que les diagrammes d'états-transitions.

Les diagrammes d'activités sont également utiles dans la phase de réalisation car ils permettent une description si précise des traitements, qu'elle autorise la génération automatique du code.

Adopté en Juin 2004, UML2.0 ou UML2 qui est une révision majeure d'UML1.x, est déjà supporté par un nombre important d'ateliers UML.

Le tableau ci-dessous synthétise l'ampleur des changements intervenus entre UML1.4 et UML2.0. Les éléments nouveaux ou très impactés sont notés "+++", cependant que les moins impactés sont notés "-".

Modèle	Degré d'évolution	Commentaire
Flux d'information	+++	Nouveauté
Diagramme d'activité	+++	Extensions et enrichissement pour la modélisation des processus et "workflow"
Diagramme d'interaction	+++	Structuration et Structures de contrôle sur les diagrammes de séquence.
Diagramme de collaboration	++	Unification avec "parts" et "ports"
Diagramme de classes	++	Nouveautés: parts, ports, structure interne
Diagramme de déploiement	+	Refonte et généralisation
Diagramme d'état	+	Structuration
Diagramme d'état de protocole	+	Formalisation, State invariant, pré et post conditions
Diagramme des cas d'utilisation	-	Quasi inchangé pour l'utilisateur final.

Les diagrammes de séquence (interaction diagram) ont été totalement refondus, afin de leur donner plus de précision et de capacité de modélisation. Il est maintenant possible de décomposer des diagrammes de séquence en "sous diagrammes de séquence" et d'employer des structures de contrôle au sein des diagrammes de séquence. Leur extension a surtout été inspirée par les besoins des domaines des télécoms, qui doivent exprimer finement des protocoles. Les diagrammes de collaboration sont peu utilisés par les praticiens d'UML1.4. Peu s'intéressent donc à leur évolution, qui du point de vue de la représentation reste stable. Les diagrammes de classe ont bénéficié de quelques extensions. Dans une grande majorité de cas, ceux-ci restent inchangés par rapport à UML1.4. Lorsque des besoins de modélisation architecturale apparaissent, alors de nouvelles notions sont utilisées, comme par exemple les composants, les parts et les ports. Les diagrammes de déploiement corrigent des insuffisances d'UML1.x. Les notions d'artefact permettent de modéliser la chaîne de production d'une application, en décidant des éléments gérés et produits, comme par exemple des librairies ou des exécutables. Les diagrammes d'état peuvent être structurés et factorisés pour être réutilisés. On distingue maintenant les diagrammes d'état de protocole, qui permet de décrire le cycle de vie des objets. Les diagrammes de cas d'utilisation enfin, ne présentent pas d'évolutions notables.

* ¹ Joint Requiement Planning : Technique d'aide à l'expression des besoins par les utilisateurs

* ² Joint Application Development : Cette technique organise le processus de conception de façon à y faire participer les utilisateurs

* ³ Time-box : cette technique limite la durée de la réalisation à une enveloppe-temps maximale

Plateformes de services intégrés pour mobiles

Chapitre 2 : Choix d'une méthode d'analyse et de conception