ans cet article, nous allons décrire de façon
progressive le processus simplifié que nous préconisons pour la modélisation
des sites Web marchands.
Le
processus que nous vous proposons de suivre
pour le développement d’un site d’e-commerce se situe à 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.
Nota : la description détaillée de ce
processus ainsi que sa mise en œuvre sur une étude de cas de librairie en
ligne paraîtra prochainement chez Eyrolles, dans une nouvelle collection
intitulée « Les cahiers du Programmeur », sous le titre :
« Modéliser un site e-commerce ».
Dans un prochain article, nous reviendrons faire un zoom sur l’activité de conception détaillée prenant pour cible la plate-forme .NET, en nous inspirant du dernier chapitre du même ouvrage.
Le Processus Unifié (UP) est un processus de développement logiciel « itératif et incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les risques » :
§ Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1 mois) qui permettent de mieux suivre l’avancement global. A la fin de chaque itération, une partie exécutable du système final est produite, de façon incrémentale.
§ Centré sur l’architecture : tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution facilitées. Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas seulement documentée en texte.
§
Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt
mais surtout levés le plus rapidement possible. Les mesures à prendre dans
ce cadre déterminent l’ordre des itérations.
§ Conduit par les cas d’utilisation : le projet est mené en tenant compte des besoins et des exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés, décrits avec précision et priorisés.
La gestion d’un tel processus est organisée suivant les quatre phases suivantes : initialisation, élaboration, construction et transition.
La phase d’initialisation conduit à définir la « vision » du projet, sa portée, sa faisabilité, son « business case », afin de pouvoir décider au mieux de sa poursuite ou de son arrêt.
La phase d’élaboration poursuit trois objectifs principaux en parallèle :
La phase de construction consiste surtout à concevoir et implémenter l’ensemble des éléments opérationnels (autres que ceux de l’architecture de base). C’est la phase la plus consommatrice en ressources et en effort.
Enfin, la phase de transition permet de faire passer l’application des développeurs aux utilisateurs finaux. Les mots-clés sont : conversion des données, formation utilisateurs, déploiement, béta-tests.
Chaque phase est elle-même décomposée séquentiellement en itérations limitées dans le temps (entre 2 et 4 semaines). Le résultat de chacune d’elles est un système testé, intégré et exécutable. L’approche itérative est fondée sur la croissance et l'affinement successifs d’un système par le biais d’itérations multiples, feed-back et adaptation cycliques étant les moteurs principaux permettant de converger vers un système satisfaisant. Le système croît avec le temps de façon incrémentale, itération par itération, et c’est pourquoi cette méthode porte également le nom de développement itératif et incrémental. Il s’agit là du principe le plus important du Processus Unifié.
Les activités de développement sont définies par cinq disciplines fondamentales qui décrivent la capture des exigences, l’analyse et la conception, l’implémentation, le test et le déploiement. La modélisation métier est une discipline amont optionnelle et transverse aux projets. Enfin, trois disciplines appelées de support complètent le tableau : gestion de projet, gestion du changement et de la configuration, ainsi que la mise à disposition d’un environnement complet de développement incluant aussi bien des outils informatiques que des documents et des guides méthodologiques.
Contrairement au processus en cascade (souvent appelé cycle en V en France), le Processus Unifié ne considère pas que les disciplines sont purement séquentielles. En fait, une itération comporte une certaine quantité de travail dans la plupart des disciplines. Mais la répartition de l’effort relatif entre celles-ci change avec le temps. Les premières itérations ont tendance à mettre plus l’accent sur les exigences et la conception, les autres moins, à mesure que les besoins et l’architecture se stabilisent grâce au processus de feed-back et d’adaptation.
UP doit donc être compris comme une trame commune des meilleures pratiques de développement, et non comme l’ultime tentative d’élaborer un processus universel.
L'eXtreme Programming (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 œuvre par des développeurs ou des chefs de projet expérimentés,
telles que :
Pour résumer, on peut dire que XP est une méthodologie légère qui met l’accent sur l’activité de programmation et qui s’appuie sur les valeurs suivantes : communication, simplicité et feedback. Elle est bien adaptée pour des projets de taille moyenne où le contexte (besoins utilisateurs, technologies informatiques) évolue en permanence.
http://www.extremeprogramming.org/
Le processus pragmatique que nous allons présenter est :
Nous allons donc essayer de trouver le meilleur rapport « qualité / prix » possible afin de ne pas multiplier les concepts et les activités de modélisation qui ne sont pas indispensables au développement de sites e-commerce efficaces. La célèbre règle des 80/20 peut aussi s’appliquer dans notre cas : vous pouvez modéliser 80% de vos problèmes en utilisant 20% d’UML ! Encore faut-il savoir quels sont ces 20% indispensables …
Le problème fondamental auquel cet article va s’efforcer de répondre est finalement assez simple : comment passer des besoins des utilisateurs au code de l’application ? Autrement dit : « j’ai une bonne idée de ce que mon site marchand doit faire, des fonctionnalités attendues par les futurs utilisateurs. Comment obtenir le plus efficacement possible un code informatique opérationnel, complet, testé, et qui réponde parfaitement au besoin ? ».
Il ne s’agit pas de se jeter sur l’écriture de code en omettant de formaliser les besoins des utilisateurs et d’élaborer une architecture robuste et évolutive. D’un autre côté, le but n’est pas de faire de la modélisation pour le plaisir, mais bien de produire le plus rapidement possible une application qui satisfasse au mieux ses utilisateurs !
Nous allons donc vous proposer une démarche de modélisation nécessaire et suffisante afin de construire efficacement un site Web marchand. Pour cela nous utiliserons un sous-ensemble du langage de modélisation UML qui sera également nécessaire et suffisant pour la plupart des projets de même nature. Cette approche est le résultat 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.
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. La figure suivante montre bien de quoi nous partons et là où nous voulons arriver.
Repartons maintenant du but, c’est à dire du code que nous voulons obtenir, et remontons en arrière, pour mieux expliquer le chemin minimal qui va nous permettre de joindre les deux « bouts ». Dans le cadre de 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 (appelées attributs), les services qu’elles rendent (appelés opérations ou méthodes) ainsi que leurs relations. UML propose les diagrammes de classes pour véhiculer toutes ces informations.
Nous reviendrons dans la seconde partie de cette série sur les
diagrammes de classes de conception dans un environnement technique .NET
et C#.
La figure ci-après montre ainsi cette étape préliminaire au codage, mais il reste encore beaucoup de chemin à parcourir …
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 (aussi appelées 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 la 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’interaction 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.
Nous reviendrons dans un prochain article sur les diagrammes
d’interaction de conception dans un environnement technique .NET et
C#.
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’interaction ?
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. Par exemple, si le domaine qui nous intéresse est la vente en ligne sur Internet, nous aurons des concepts du domaine comme « article », « catalogue », « client », « commande », etc.
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.
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.
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 la 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.
Nous avons ainsi obtenu un schéma complet montrant comment, en partant des besoins utilisateurs formalisés par des cas d’utilisation et une maquette, et avec l’apport du modèle du domaine, on peut aboutir à des diagrammes de conception qui permettent de dériver du code assez directement.
Notez que nous n’utilisons pas les neuf types de diagrammes proposé par UML, mais seulement une moitié, en insistant particulièrement sur les diagrammes de classes et les diagrammes d’interaction. Cette limitation volontaire permet une réduction significative du temps d’apprentissage de la modélisation avec UML, tout en restant largement suffisante pour la plupart des projets.
Dans la seconde partie de cet article nous mettrons l'accent sur le code
résultant des différents diagrammes précédents dans un environnement
.NET et C#.
Auteur : Pascal Roques
Copyright : Juin 2002 - Eyrolles ©
Ressources
Modéliser un site e-commerce : Pascal Roques
http://www.dotnetguru.org (Article sur UML et C#)
Site officiel du RUP : http://www.rational.com/rup
Site officiel d'eXtreme Programming : http://www.extremeprogramming.org/
Jean-Louis Bénard (Business Interactif) : Excellents Articles parus dans le magazine électronique Développeur Référence