Memoire Online - Essai de conception et d'implémentation d'une plateforme web d'aide à l'orientation des étudiants dans leurs recherches de travaux de fin de cycle

Le « Two Track - Unified Process » est l'une de nombreuses implémentations du processus UP mais paraît de loin la plus intéressante.

Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées aux systèmes d'information de l'entreprise. En ce sens, il renforce le contrôle sur les capacités d'évolution et de correction de tels systèmes. « 2 Track » signifie littéralement que le processus suit deux chemins. Il s'agit des chemins « fonctionnels » et « d'architecture technique », qui correspondent aux deux axes de changement imposés au système informatique (VALLEE, op.cit.).

Pour faire simple, le 2TUP formalise sa modélisation sur deux « branches » d'analyse qui se rejoignent à la fin de la modélisation et juste avant la conception préliminaire : la branche fonctionnelle à gauche et la branche technique à droite. Les deux forment un « Y », d'où l'appellation « processus de développement en Y ».

La branche gauche ou fonctionnelle, se rapporte aux attentes des utilisateurs par rapport au système. Elle va inclure l'ensemble de ce qu'on va appeler « métiers utilisateurs » afin de ne pas dévier des desiderata de ces derniers. Elle est indépendante des technologies à employer.

La branche droite ou technique quant à elle s'intéresse uniquement aux considérations techniques du système à modéliser : les outils ou matériaux de conception, les technologies à employer,... ainsi que la cohabitation de toutes ces composantes. Cette branche doit pouvoir garder une certaine indépendance vis-à-vis de la branche d'en face.

En se rejoignant, les deux branches ne forment plus qu'une seule branche qui part d'une conception préliminaire, étape délicate où doivent être conciliées les exigences de deux branches précédentes. Après, on passe à une conception détaillée pour réaliser chaque composante.

Ensuite, viennent le codage avec ses tests unitaires et enfin ; l'étape de recette qui consistera en la validation des fonctions du système développé.

Le livre « UML2 EN ACTION : De l'analyse des besoins à la conception » de P. Roques et F. Vallée est un excellent bouquin pour entrer dans les détails. Voici, à la page 14 du livre, un schéma reprenant toutes ces étapes :

II.3.2. MODELISATION AVEC LE LANGAGE UML

UML est l'abréviation de « Unified Modeling Language », qu'on peut traduire par « Langage de modélisation unifié ».

UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire de besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.(VALLEE, op.cit.)

UML est un langage standard pour la modélisation des systèmes en informatique. Pour cela, il facilite l'analyse et la conception comme tout langage mais avec l'avantage d'être par essence dans une approche orientée objet.

- La syntaxe : règles selon lesquelles les éléments du langage (Ex. : les mots) sont assemblés en des expressions (Ex. : phrases, clauses).

- La sémantique : règles permettant d'attribuer une signification aux expressions syntaxiques.

C'est l'OMG (Object Management Group) qui définit les spécifications (norme) UML. Il s'agit d'un groupe comprenant les grands noms de l'industrie de l'informatique comme IBM, Microsoft, etc.

Parmi les objectifs d'UML, il y entre autre le besoin de faciliter la modélisation et ainsi arriver à faire de la programmation sans programmer c'est-à-dire, créer un langage de modélisation utilisable à la fois par les humains et les machines.

Pour concevoir un nouveau produit logiciel en informatique, on part d'un cahier des charges. Celui-ci est fait en reprenant les desiderata du client ou des potentiels demandeurs. Après celui-ci, nous pouvons passer à la modélisation en connaissance de cause.

Dans cette section, nous allons pouvoir capturer les besoins des utilisateurs en suivant le schéma de développement logiciel avec la méthode 2TUP. Cette capture se fait en deux temps ; d'abord on va « capturer » les besoins fonctionnels ensuite, les besoins techniques.

A. CAPTURE DES BESOINS FONCTIONNELS

Les besoins fonctionnels sont des besoins liés aux fonctionnalités de l'application à mettre en place. Elles ressortent du récit narratif du futur utilisateur ou ses propres besoins, quelle que soit la façon dont il les exprime.

A ce niveau déjà, nous allons nous servir de nos premiers diagrammes UML pour formaliser les besoins fonctionnels. On va utiliser : le diagramme de cas d'utilisation et le diagramme de séquence.

C'est sans aucun doute le diagramme UML le plus important car, il constitue le point de départ de toute la modélisation. Le diagramme de cas d'utilisation est composé du système, des acteurs, des cas d'utilisation et des relations.

Il représente dans notre cas, la plate-forme en ligne que nous voulons créer. Pour rappel, un système, c'est tout simplement un ensemble d'éléments interconnectés et concourant à un but précis.

Il sera donc constitué des cas d'utilisations et éventuellement des relations entre eux. Il est représenté par un grand rectangle.

Il s'agit de répondre à la question « qui ? ». On fait intervenir Les individus ou éléments qui vont déclencher la réalisation d'un cas d'utilisation. Les acteurs peuvent être humains ou d'autres systèmes.

On distinguera l'acteur dit « primaire ou principal » de celui dit « secondaire ». Le premier doit obligatoirement paraître dans un diagramme de cas d'utilisation. Il est donc celui qui initie la réalisation directe d'un cas d'utilisation. On le place généralement du côté gauche du système.

L'acteur secondaire est tout autre participant au système, sa présence n'est pas obligatoire (comme dans notre cas). On le place du côté droit du système.

· Le membre : L'étudiant ou la personne qui visitera la plateforme en ligne pour y chercher des informations.

· Le spécialiste : C'est lui qui publiera les thématiques, postera des fichiers à consulter et/ou à télécharger.

· L'administrateur : C'est le gestionnaire de la plateforme. A lui, incombe la tâche de la maintenance de la plateforme.

Il s'agit ici de savoir ce que le système devra faire, sans tenir compte de comment il le fera. Donc, à ce niveau ; il s'agit de répondre à la question « quoi ? ».

Les cas d'utilisations, sont les différentes interactions métier entre l'utilisateur du système et le système lui-même. En d'autres termes, le concepteur prévoit quel sera le comportement de son système, les interactions entre celui-ci et les acteurs en présence et même les potentiels Scenarii alternatives.

Pour faciliter la lecture préalable de nos cas d'utilisation, plaçons ces derniers dans le tableau synthétique ci-après :

Cas d'utilisation	Acteur
S'authentifier	Membre
Consulter une thématique
Consulter le modèle
Télécharger les fichiers
S'authentifier	Spécialiste
Poster un modèle
Disponibiliser les fichiers
Proposer une thématique
S'authentifier	Admin
Gérer les membres
Gérer le spécialiste

Ce sont les liens entre utilisateurs et cas d'utilisation, entre utilisateurs eux-mêmes ou entre cas d'utilisations. Tout cela dans le but de rendre le fonctionnement du système clair.

Au vu de tout ce qui précède, nous proposons le diagramme de cas d'utilisation suivant :

CU1	Authentification
Résumé Narratif	Pour accéder à la plateforme
Acteur (s)	Membre, spécialiste et admin
Pré-conditions	Soumettre le login et le mot de passe
Post-conditions	Le cas démarre après le point 03 du scenario nominal
Scenario nominal << DEBUT>> 01. Le système affiche la page d'authentification 02. Entrer login et mot de passe 03. Vérification des paramètres entrés 04. Ouverture de la plate-forme << FIN>>
Scenario alternatif
Login et mot de passe incorrects : Commence au point 03 05. Message d'échec d'authentification 06. Retour en 01

CU2	Consulter les thématiques
Résumé Narratif	Permet l'accès et l'exploration des thématiques
Acteur (s)	Membre
Pré-conditions	Soumettre le login et le mot de passe
Post-conditions	Le cas démarre après le point 02 du scenario nominal
Scenario nominal << DEBUT>> 01. Entrer login et mot de passe 02. Vérification des paramètres entrés 03. Ouverture espace membre 04. Accéder aux thématiques 05. Commenter une thématique << FIN>>
Scenario alternatif
Login et mot de passe incorrects : Commence au point 02 06. Message d'échec d'authentification 07. Retour en 01

CU3	Consulter le modèle
Résumé Narratif	Permettre au membre de consulter le modèle
Acteur (s)	Membre
Pré-conditions	Soumettre le login et le mot de passe
Post-conditions	Le cas démarre après le point 02 du scenario nominal
Scenario nominal << DEBUT>> 01. Entrer login et mot de passe 02. Vérification des paramètres entrés 03. Ouverture espace membre 04. Accès au modèle 05. Télécharger le modèle << FIN>>
Scenario alternatif
Login et mot de passe incorrects : Commence au point 02 06. Message d'échec d'authentification 07. Retour en 01

CU4	Télécharger
Résumé Narratif	Permettre le téléchargement des fichiers/du modèle
Acteur (s)	Membre
Pré-conditions	Soumettre le login et le mot de passe
Post-conditions	Le cas démarre après le point 02 du scenario nominal
Scenario nominal << DEBUT>> 01. Entrer login et mot de passe 02. Vérification des paramètres entrés 03. Ouverture espace membre 04. Ouverture page des téléchargements 05. Télécharger les fichiers/le modèle << FIN>>
Scenario alternatif
Login et mot de passe incorrects : Commence au point 02 06. Message d'échec d'authentification 07. Retour en 01

CU5	Gérer les membres/le spécialiste
Résumé Narratif	Permettre la gestion du fonctionnement de la plate-forme
Acteur (s)	Admin
Pré-conditions	Soumettre le login et le mot de passe admin
Post-conditions	Le cas démarre après le point 03 du scenario nominal
Scenario nominal << DEBUT>> 01. Le système affiche la page d'authentification 02. Fournir login et mot de passe 03. Vérification des paramètres entrés 04. Ouverture l'espace administrateur 05. Gestion de la plate-forme << FIN>>
Scenario alternatif
Login et mot de passe incorrects : Commence au point 03 06. Message d'échec d'authentification 07. Retour en 01

CU6	Poster modèle/Disponibiliser fichiers/Proposer thématiques
Résumé Narratif	Permettre au spécialiste de poster un modèle, de disponibiliser les fichiers ou proposer une thématique
Acteur (s)	Spécialiste
Pré-conditions	Soumettre le login et le mot de passe spécialiste
Post-conditions	Le cas démarre après le point 03 du scenario nominal
Scenario nominal << DEBUT>> 01. Le système affiche la page d'authentification 02. Entrer login et mot de passe spécialiste 03. Vérification des paramètres entrés 04. Ouverture espace spécialiste 05. Choisir l'opération à réaliser << FIN>>
Scenario alternatif
Login et mot de passe incorrects : Commence au point 03 06. Message d'échec d'authentification 07. Retour en 01

Essai de conception et d'implémentation d'une plateforme web d'aide à l'orientation des étudiants dans leurs recherches de travaux de fin de cycle

II.3.1. Le 2TUP

II.3.2. MODELISATION AVEC LE LANGAGE UML

A. CAPTURE DES BESOINS FONCTIONNELS