I.4.Modélisation du processus métier
cible
La modélisation du métier vise à mieux
connaître le fonctionnement et les règles qui régissent le
système organisationnel dans lequel on envisage implanter un nouveau
système informatisé. Si l'on souhaite que le système
informatique à concevoir corresponde aux exigences réelles du
métier ciblé, il est vital de bien identifier les objectifs, les
priorités, les règles de gestion et les processus clés de
l'organisation avant toute tentative d'informatisation. C'est ainsi que nous
allons commencer par présenté le langage de modélisation
qui n'est autre qu'UML et en suite la démarche UP :
Présentation du langage de modélisation
UML
UML (Unified Modeling Language) se définit comme un
langage de modélisation graphique et textuel destiné à
comprendre et décrire des besoins, spécifier et documenter des
systèmes, esquisser des architectures logicielles, concevoir des
solutions et communiquer des points de vue.24
UML n'est pas une méthode (une description normative
des étapes de la modélisation) : ses auteurs ont en effet
estimé qu'il n'était pas opportun de définir une
méthode en raison de la diversité des cas particuliers. Ils ont
préféré se borner à définir un langage
graphique qui permet de représenter, de communiquer les divers aspects
d'un système d'information. UML est donc un métalangage car il
fournit les éléments permettant de construire le modèle
qui, lui, sera le langage du projet.
UML en sa version 2 s'articule autour de treize types de
diagrammes, chacun d'eux étant dédié à la
représentation des concepts particuliers d'un système logiciel.
Ces diagrammes sont regroupés dans deux grands ensembles: les diagrammes
structurels et les diagrammes comportementaux. Ces types de diagrammes sont
répartis en deux grands groupes :
Les six diagrammes structurels :
Diagramme de classes : il montre les
briques de base statiques : classes, associations, interfaces, attributs,
opérations, généralisations, etc. Diagramme
d'objets : il montre les instances des éléments
structurels et leurs liens à l'exécution.
Diagramme de packages : il montre
l'organisation logique du modèle et les relations entre packages.
Diagramme de structure composite :
il montre l'organisation interne d'un élément statique
complexe.
24 Pascal ROQUES, UML2 Modéliser
une application Web, Ed. EYROLLES, p22.
16
Diagramme de composants : il montre
des structures complexes, avec leurs interfaces fournies et requises.
Diagramme de déploiement : Il
montre le déploiement physique des « artefacts » sur les
ressources matérielles.
Les sept diagrammes comportementaux
:
Diagramme de cas d'utilisation : il
montre les interactions fonctionnelles entre les acteurs et le système
à l'étude.
Diagramme de vue d'ensemble des interactions
: il fusionne les diagrammes d'activité et de
séquence pour combiner des fragments d'interaction avec des
décisions et des flots.
Diagramme de séquence : il
montre la séquence verticale des messages passés entre objets au
sein d'une interaction.
Diagramme de communication : il
montre la communication entre objets dans le plan au sein d'une interaction.
Diagramme de temps : il fusionne les
diagrammes d'états et de séquence pour montrer l'évolution
de l'état d'un objet au cours du temps.
Diagramme d'activité : il
montre l'enchaînement des actions et décisions au sein d'une
activité.
Diagramme d'états : il montre
les différents états et transitions possibles des objets d'une
classe.
La demarche UP (Unified Process)
Processus unifié (PU ou UP en anglais pour Unified
Process) est une méthode de prise en charge du cycle de vie d'un
logiciel et donc du développement, pour les logiciels orientés
objets. Le Processus Unifié (UP, pour Unified Process) 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.25
Le processus unifié se déroule en quatre phases,
incubation, élaboration, construction et transition. Chaque phase
répète un nombre de fois une série d'itérations. Et
chaque itération est composée de cinq activités : capture
des besoins, analyse, conception, implémentation et test.
25 RAMAZANI Trésor, Cours de
conception orienté objet II, G3 Info, UCSV 2014-2015
17
Figure 3: Cycle de vie du processus
unifié
Source : Cours de COO II, G3 Info, UCSV
2014-2015
Les quatre phases du processus unifié sont :
1. Création
C'est la première phase du processus unifié. Il
s'agit de délimiter la portée du système,
c'est-à-dire tracer ce qui doit figurer à l'intérieur du
système et ce qui doit rester à l'extérieur, identifier
les acteurs, lever les ambiguïtés sur les besoins et les exigences
nécessaires dans cette phase. Il s'agit aussi d'établir une
architecture candidate, c'est-à-dire que pour une première phase,
on doit essayer de construire une architecture capable de fonctionner. Dans
cette phase, il faut identifier les risques critiques susceptibles de faire
obstacles au bon déroulement du projet.
2. Elaboration
C'est la deuxième phase du processus. Après
avoir compris le système, dégagé les
fonctionnalités initiales, précisé les risques critiques,
le travail à accomplir maintenant consiste à stabiliser
l'architecture du système. Il s'agit alors de raffiner le modèle
initial de cas d'utilisation, voire capturer de nouveaux besoins, analyser et
concevoir la majorité des cas d'utilisation formulés, et si
possible implémenter et tester les cas d'utilisation initiaux.
18
3. Construction
Dans cette phase, il faut essayer de capturer tous les
besoins restants car il n'est pratiquement plus possible de le faire dans la
prochaine phase. Ensuite, continuer l'analyse, la conception et surtout
l'implémentation de tous les cas d'utilisation. A la fin de cette phase,
les développeurs doivent fournir une version exécutable du
système.
4. Transition
C'est la phase qui finalise le produit. Il s'agit au cours de
cette phase de vérifier si le système offre véritablement
les services exigés par les utilisateurs, détecter les
défaillances, combler les manques dans la documentation du logiciel et
adapter le produit à l'environnement (mise en place et installation).
Dans notre étude le processus cible est le vote
présidentielle ainsi que dépouillement des résultats
après le vote. Pour ainsi arriver à modéliser notre
processus cible qui est le vote et le dépouillent (comptage des voix)
après le processus de vote, nous utiliserons les diagrammes suivants
:
Diagramme de Cas d'utilisation
métier
C'est un diagramme qui représente la structure des
grandes fonctionnalités nécessaires aux utilisateurs du
système. C'est le premier diagramme du modèle UML, est celui
où s'assure la relation entre l'utilisateur et les objets que le
système met en oeuvre.26
Cette phase va nous permettre d'identifier les
différents cas d'utilisations de notre métier. Par le biais des
cas d'utilisation, nous serons en contact permanent avec les acteurs du
système en vue de définir les limites de celui-ci, et ainsi
éviter de trop s'éloigner des besoins réels de
l'utilisateur final.
Le diagramme de CU présenté ci-dessous ne
présente pas la totalité des cas d'utilisation du processus
métier cible, ce pendant nous avons présentés quelques cas
d'utilisation afin de mieux analysé notre système en vue d'y
apporter notre future solution.
26 Laurent AUDIBERT, cours UML
2.0, Paris 2006, p 26
19
Figure 4: Diagramme de Cas d'Utilisation
métier
System
Présenter Carte
Verification Carte
Sec Bureau de Vote
Reçevoir Bulletin de Vote
Voter
Votant
Placer Bulletin dans l'urne
Retirer Carte d'Elect
Chef_antenne
Envoyer resultat
Source : l'auteur
| 
