Modélisation et implémentation d’une base de données répartie pour la gestion de l’enrôlement dans un processus électoral

SECTION II. MODELISATION DE LA BASE DE DONNEE

Une idée centrale des BDD est de séparer la description des données (effectuée par l'Administrateur) de la manipulation (effectuée par les programmes d'application).^54(*)

La description permet de spécifier les structures et les types de données ou d'application, alors que la manipulation consiste à effectuer des interrogations, des insertions et des mises à jour.

Bien que la notation UML ait été proposée tout d'abord pour la spécification d'applications, il n'en reste pas moins que les concepts relatifs au diagramme de classes peuvent s'adapter à la modélisation d'une base de données relationnelle ou objet-relationnelle.

UML 2 reprend les concepts du modèle entité-association et propose en plus des artifices pour améliorer la sémantique d'un schéma conceptuel (contraintes, classe-association, stéréotype...). De ce fait, cette notation est très complète et puissante et peut s'adapter parfaitement à la description statique d'une base de données.

Une notation étant une convention de représentation graphique des concepts liés à un formalisme,proposée par un ou plusieurs auteurs ; un formalisme alors est l'ensemble de règles de représentation permettant de formuler un modèle graphiquement. Il comporte un certain nombre de concepts de base permettant d'exprimer un modèle.^55(*)

II.1. DIAGRAMME CAS D'UTILISATION

Le rôle des diagrammes de cas d'utilisation est, comme nous l'avions souligné, de permettre à recueillir, analyser et 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.

Pour élaborer les cas d'utilisation, il faut se fonder sur des entretiens avec les utilisateurs.

II.1.1. ELEMENTS DU DIAGRAMME DES CAS D'UTILISATION

a) Acteurs

Dans notre cas, l'acteur principal est le candidat qui vient se faire enrôler dans le Centre d'Identification (CI) de la CENI. Il est l'élément déclencheur du processus.

C'est pourquoi nous définissons un acteur comme étant l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système.

Il se représente par un petit bonhomme avec son nom inscrit dessous. Il est également possible de représenter un acteur sous la forme d'un classeur stéréotypé << actor >>.

Pour être plus réaliste, nous avons recensé pour notre problème les acteurs suivants :

- Candidat ;

- OPS (Opérateur De Saisie) ;

- DBA (DataBase Administrator : Administrateur de la BD) ;

- BD Distante (Autres sites ou centre d'identification).

b) 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.

Un cas d'utilisation se représente par une ellipse contenant le nom du cas (un verbe à l'infinitif), et optionnellement, au-dessus du nom, un stéréotype.

* ⁵⁴ GARDARIN G., Bases de données, Ed. EYROLLES, Paris, 2001, p.15.

* ⁵⁵ ROY G., Conception de bases de données avec UML, Edition Presse de l'Université Québec, Québec, 2009, p.26