Developpement et integration d'un systeme de gestion integrée pour la gestion des établissements scolaires cas du complexe scolaire l'age d'or

B. Capture de besoins

1. Besoins fonctionnels

La capture des besoins fonctionnels est la première étape de la branche gauche du cycle en Y. Elle formalise et détaille ce qui a été ébauché au cours de l'étude préliminaire. Elle est complétée au niveau de la branche droite du Y par la capture des besoins techniques et prépare l'étape suivante de la branche gauche : l'analyse.

a. Diagramme de cas d'utilisation fonctionnel du système

Le diagramme de cas d'utilisation, est un diagramme UML qui permet de modéliser les besoins des utilisateurs du système informatique en conception. Ce diagramme est un diagramme pivot du processus unifié avec la méthode 2TUP, car l'un des principes de 2TUP est que cette dernière est orientée utilisateur.^22(*) L'identification des cas d'utilisation une première fois, nous donne un aperçu des fonctionnalités futures que doit implémenter le système. Cependant, il nous faut plusieurs itérations pour ainsi arriver à constituer des cas d'utilisation complets. D'autres cas d'utilisation vont apparaître au fur à mesure de la description de ceux-là, et l'avancement dans le « recueil des besoins fonctionnels ».

Pour constituer les cas d'utilisation, il faut considérer l'intention fonctionnelle de l'acteur par rapport au système dans le cadre de l'émission ou de la réception de chaque message. En regroupant les intentions fonctionnelles en unités cohérentes, on obtient les cas d'utilisations.

Voici la représentation du diagramme de cas d'utilisation :

Figure 12 Diagramme de cas d'utilisation informatique

a. Description des cas d'utilisation (Diagramme de séquences systèmes)

Un cas d'utilisation représente un ensemble de séquences d'interactions entre le système et ses acteurs. Pour décrire la dynamique du cas d'utilisation, le plus naturel consiste à recenser toutes les interactions de façon textuelle. Le cas d'utilisation doit par ailleurs avoir un début et une fin clairement identifiés. Il doit préciser quand ont lieu les interactions entre acteurs et système, et quels sont les messages échangés. Il faut également préciser les variantes possibles, telles que les différents cas nominaux, les cas alternatifs, les cas d'erreurs, tout en essayant d'ordonner séquentiellement les descriptions, afin d'améliorer leur lisibilité. Chaque unité de description de séquences d'actions est appelée enchaînement. Un scénario représenteune succession particulière d'enchaînements, qui s'exécute du début à la fin du cas d'utilisation.^23(*)

i. Cas d'utilisation PROGRAMMER COURS

PROGRAMMER COURS
But	Le but de ce cas d'utilisation est de programmer le cours dans une classe et une période donnée, à partir des enseignants disponibles.
Acteurs	Directeur des études (principal)
Préconditions	- Le Directeur des études est authentifié - Il existe au moins une commande confirmée à programmer - Avoir une liste des enseignants, des classes, ainsi que le programme de cours ;
Scenario nominal	Ce cas d'utilisation commence lorsque le Directeur des études demande au système de programmer un cours - Le système affiche la liste de classes disponibles - Le Directeur des études, commence par sélectionner la classe dont le cours devra être programmé - Il spécifie ensuite le cours sur la liste de cours ; - Il valide ensuite le choix du cours qu'il a programmé, et lance la publication aux utilisateurs concernés - Le système valide ces actions et renvoie un message de confirmation
Scenario alternatif	Enchainement(b) : -
Post condition

Les scenarios que nous avons ci-haut explicités, sont alors présentés par le diagramme de séquence ci-dessous :

Figure 13 Diagramme de séquence du cas d'utilisation PROGRAMMER COURS

* ²² Xavier BLANC et Isabelle MOUNIER, UML 2 pour les développeurs cours et exercices corrigés, EYROLLES, Paris, 2009, p. 97-106 ;

* ²³ Pascal ROQUES et Franck VALLEE, UML 2 en action de l'analyse des besoins à la conception,

EYROLLES, Paris, p. 69 ;