Plateforme web B2B

On me demande souvent comment je travaille sur de nouveaux projets de développements ? Quelles sont les méthodes que j'utilise et finalement comment je passe du cahier des charges à une solution fonctionnelle et innovante ?
Au travers de cet article, je vais apporter quelques éléments de réponses.
Pour ce faire je partirai d'un cahier des charges dont le but est de réaliser une plateforme web B2B.
C'est un projet intéressant puisque la méthodologie s'apparente à celle d'un projet de génie logiciel.
Cependant on utilisera des technologies orientées web pour sa réalisation (interface pour navigateur internet, langage PHP, base de données Mysql...).
Le but de cette solution B2B est de permettre à des professionnels d’interagir via un site web, d'échanger des informations, de conclure des affaires, de suivre leurs activités, de gérer des stocks, de participer à des enchères, d'appartenir à des groupes, etc...
Les phases 1 et 2 du projet sont les plus délicates, car le succès de cette entreprise en dépend. En phase 1 on va ainsi réaliser un cahier des charges dont le rôle sera de décrire tous les process des actions qui seront menées par les professionnels, avec des règles métiers (qui serviront plus tard à la modélisation conceptuelle, organisationnelle et collaborative). En général le cahier des charges est réalisé directement en entretien avec les intervenants et mandataires du projet. En fonction de sa complexité cela peut prendre quelques heures ou quelques semaines.
Une fois que la phase 1 est bouclée, on peut passer à la phase 2, au cours de laquelle on va réaliser l'analyse du projet, puis différents modèles et diagrammes, ainsi que le prototypage de fonctions, qui serviront plus tard à la phase 3 (lors de la programmation).

Pour la modélisation j'utilise la méthode MERISE, qui permet d'établir les modèles de communication, les modèles conceptuels, les modèles organisationnels et les modèles logiques. Dans le document que vous pourrez télécharger plus bas, je ne parlerai que du modèle logique qui permet de concevoir la base de données du projet. C'est une phase très importante car elle permettra de bien connaître les contraintes d'intégrité entre les tables ainsi que leurs règles de liaison.

Lorsque le projet est un peu complexe, l'informaticien recours systématiquement à la programmation orientée objet, qui est extrêmement pratique pour y voir clair dans le code source que l'on écrira plus tard. En effet en mettant beaucoup de clarté dans le programme, vous pourrez plus facilement faire évoluer votre projet.
Pour cette raison dans l'analyse du projet, j'ai recours à la méthode UML (pour Unified Modeling Language), sa particularité c'est qu'au travers de 14 types de diagrammes elle unifie d'anciennes méthodes (telles que Boost, OMT ou encore OOSE, SAT...) tout en intégrant des nouveautés.

Vous pouvez maintenant télécharger le document dans lequel je conçois le projet (analyse, modélisation, prototypage de fonctions et choix technologiques) :

http://www.strangemenstudio.com/telechargement/Plat_Web_B2B.pdf

Je vous détail ci-dessous les fonctions de chacun des diagrammes UML.

Les diagrammes structurels ou statiques :
- Diagramme de classes : Permet la représentation des informations du domaine métier regroupées en entités logiques nommées classes, et la représentation des associations entre ces classes.
- Diagramme d'objets : Représente une instance possible de diagramme de classes, il met en évidence des objets instances de ces classes et des relations instance de leurs associations.
- Diagramme de composants : Représente les morceaux d'applications packagées sous la forme de composants disposant d'interfaces.
- Diagramme de déploiement : Complémentaire du diagramme de composants, décrit la répartition physique des instances de composants, de processus et d'objets d'une application distribuée.
- Diagramme de paquetage : Représente les dépendances entre paquetages et donc les dépendances entre les ensembles de définition.
- Diagramme de structure composite : Décrit les relations entre les composants d'une classe sous la forme d'une boite blanche.
- Diagramme de profil : Spécifie et personnalise un méta-modèle de référence d'UML pour un domaine.


Les diagrammes comportementaux :
- Diagramme de cas d'utilisation : Modélise les interactions entre les différents acteurs externes et les fonctionnalités du système.
- Diagramme d'état-transition : Décrit l'ensemble des états des objets du système et les transitions qui déclenchent le passage d'un état donné vers un nouvel état.
- Diagramme d'activité : Décrit l'ensemble des activités effectuées par les acteurs du système en les décomposant en sous-activités et en spécifiant les contraintes relatives à l'enchainement de ces sous-activités.


Les diagrammes d'interaction ou dynamiques :
- Diagramme de collaboration : Représente sur un diagramme d'objets les échanges de messages entre objets ou entre acteurs et objets.
- Diagramme de séquence : Variante du diagramme de collaboration qui permet la représentation temporelle des échanges entre les différents objets du système.
Diagramme de temps : Décrit les variations au cours du temps d'un objet ou d'une donnée.
- Diagramme d'interaction : A travers le choix de scénario décrit par le diagramme de séquence, décrit les différents enchainements possibles.


Pour ce projet, vous ne trouverez dans le document à télécharger plus haut, qu'une partie de ces diagrammes, en effet on ne s'intéressera qu'aux interactions fixes et temporelles, ainsi qu'à la cinématique des actions sur la plateforme web B2B.
Dans les choix technologiques, vous verrez que j'ai opté pour du PHP/Mysql avec HTML/CSS et quelques WEBSERVICES. Ceci pour des raisons économiques pour le client. Mais des solutions plus robustes existent, telles que JAVA/XML avec des JavaServerPage (JSP) et des composants Enterprise JavaBeans (EJB), l'utilisation d'une base de données ORACLE aurait donnée aussi une fiabilité et une sécurité très importante pour l'accès et la sauvegarde des données.

Un dernier mot sur les architectures MVC (Modèle-Vue-Contrôleur) qui permettent de bien visualiser les différentes interactions entre les couches de la plateforme web B2B. Le but est de séparer la partie data, du modèle de présentation du site, et des applications (codes côté serveur et codes côté navigateur).
Cette étape est donc nécessaire pour modéliser vos couches 3-tiers ou n-tiers.

Je vous souhaite une bonne lecture du document et si vous avez des questions concernant la phase 3 qui n'y figure pas, vous pouvez m'envoyer un E-mail.

Olivier EDWIGE


Commentaires

Articles les plus consultés