Arrow Table de matières
1255365

CHAP III MODELISATION

Le processus de modélisation vise à obtenir une solution acceptable du système informatique. La solution finalement retenue n’est pas obtenue en une seule itération. Plusieurs étapes sont nécessaires ; ces étapes successives permettent de raffiner le niveau de détails du système à réaliser. Les premières étapes donnent une vision à très gros grains et permettent d’avancer dans la compréhension du problème.

Il existe plusieurs méthodes de modélisation de système d’information parmi lesquelles nous retrouvons : la méthode MERISE, le Processus Unifié, le Processus Unifié version 7, le Rational Unified Process (RUP) etc.

Dans ce travail nous utiliserons la démarche du Processus Unifié.

3.1. Présentation d’UP

La méthode du Processus Unifié (UP pour Unified Process) est un processus de développement itératif et incrémental, ce qui signifie que le projet est découpé en phases très courtes à l’issue de chacune desquelles une nouvelle version incrémentée est livrée (SOUTOU, 2002).

 Il s’agit d’une démarche s’appuyant sur la modélisation UML pour la description de l’architecture du logiciel (fonctionnelle, logicielle et physique) et la mise au point de cas d’utilisation permettant de décrire les besoins et exigences des utilisateurs.

3.2. Les principes d’UP (JOSEPH & DAVID, 2008)

Le processus de développement UP, associé à UML, met en œuvre les principes suivants :

  1. Processus guidé par les cas d’utilisation

L’orientation forte donnée ici par UP est de montrer que le système à construire se définit d’abord avec les utilisateurs. Les cas d’utilisation permettent d’exprimer les interactions du système avec les utilisateurs, donc de capturer les besoins.

Une seconde orientation est de montrer comment les cas d’utilisation constituent un vecteur structurant pour le développement et les tests du système. Ainsi le développement peut se décomposer par cas d’utilisation et la réception du logiciel sera elle aussi articulée par cas d’utilisation.

  1. Processus itératif et incrémental

Ce type de démarche étant relativement connu dans l’approche objet, il paraît naturel qu’UP préconise l’utilisation du principe de développement par itérations successives. Concrètement, la réalisation de maquette et prototype constitue la réponse pratique à ce principe. Le développement progressif, par incrément, est aussi recommandé en s’appuyant sur la décomposition du système en cas d’utilisation.

  1. Processus centré sur l’architecture

Les auteurs d’UP mettent en avant la préoccupation de l’architecture du système dès le début des travaux d’analyse et de conception. Il est important de définir le plus tôt possible, même à grandes mailles, l’architecture type qui sera retenue pour le développement, l’implémentation et ensuite le déploiement du système. Le vecteur des cas d’utilisation peut aussi être utilisé pour la description de l’architecture.

  1. Processus orienté par la réduction des risques

L’analyse des risques doit être présente à tous les stades de développement d’un système. Il est important de bien évaluer les risques des développements afin d’aider à la bonne prise de décision. Du fait de l’application du processus itératif, UP contribue à la diminution des risques au fur et à mesure du déroulement des itérations  successives.

3.3. Phases et itérations du processus (aspect dynamique)

Le processus unifié étant organisé en fonction du temps, il est fractionné en quatre phases successives :

  1. Inception (lancement ou analyse des besoins)

L’inception donne une vue du projet sous forme de produit fini.

Cette phase porte essentiellement sur les besoins principaux du point de vue de l’utilisateur, l’architecture générale du système, les risques majeurs, les délais et les coûts.

C’est la mise en place du projet.

Elle répond aux questions suivantes :

  • que fera le système ?
  • pour ce qui est des utilisateurs principaux, quels services rendra-t-il?
  • quelle sera l’architecture générale de ce système ?
  • quels seront les délais, les coûts, les ressources, les moyens à déployer?
  1. Élaboration

L’élaboration reprend les éléments de la phase d’analyse des besoins et les précise pour arriver à une spécification détaillée de la solution à mettre en œuvre.

Elle permet de préciser la plupart des cas d’utilisation, de concevoir l’architecture du système et surtout de spécifier l’architecture de référence. A la fin de cette phase, les chefs de projet doivent être capables de prévoir les activités et d’estimer les ressources nécessaires à l’achèvement du projet.

Les taches à effectuer dans cette phase sont les suivantes : créer une architecture de référence ; identifier les risques, ceux qui sont de nature à bouleverser le plan, le coût et le calendrier ; définir les niveaux de qualité à atteindre ; formuler les cas d’utilisation pour couvrir les besoins fonctionnels et planifier la phase de construction ; élaborer une offre abordant les questions de calendrier, de personnel et de budget (SOUTOU, 2002).

  1. Construction

C’est la phase où l’on construit le produit. Elle est centrée sur les activités de conception, d’implémentation et de test. L’architecture de référence se métamorphose en produit complet.

Le produit contient tous les cas d’utilisation que les chefs de projet, en convenance avec les utilisateurs ont décidé de mettre au point pour cette version.

  1. Transition

Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit et détecte les anomalies et défauts (exploitation réelle). Ici sont traitées toutes les actions liées au déploiement.

Cette phase exige des activités comme la formation des utilisateurs clients, la mise en œuvre d’un service d’assistance et la correction des anomalies constatées afin de valider le nouveau système.

Dans le processus unifié, chacune de phases peut-être divisée en itérations. Une itération est un circuit complet de développement aboutissant à une livraison (interne ou externe) d’un produit exécutable.

Ce produit est un sous-ensemble du produit final en cours de développement, qui croît de  manière incrémentale d’itération en itération pour devenir le système final.

Chaque itération au sein d’une phase aboutit à une livraison exécutable du système. (JOSEPH & DAVID, 2008)

3.4. Activités du processus (aspect statique)

  1. Expression des besoins

L’expression des besoins comme son nom l’indique, permet de définir les différents besoins : inventorier les besoins principaux et fournir une liste de leurs fonctions, recenser les besoins fonctionnels (du point de vue de l’utilisateur) qui conduisent à l’élaboration des modèles de cas d’utilisation, appréhender les besoins non fonctionnels (technique) et livrer une liste des exigences.

Le modèle de cas d’utilisation présente le système du point de vue de l’utilisateur et représente sous forme de cas d’utilisation et d’acteur, les besoins du client.

A ce niveau, deux diagrammes sont présentés : le diagramme de contexte et le diagramme de cas d’utilisation système.

  1. Analyse

L’objectif de l’analyse est d’accéder à une compréhension des besoins et des exigences du client. Il s’agit de livrer des spécifications pour permettre de choisir la conception de la solution.

Un modèle d’analyse livre une spécification complète des besoins issus des cas d’utilisation et les structure sous une forme qui facilite la compréhension (scénarios), la préparation (définition de l’architecture), la modification et la maintenance du futur système.

Il s’écrit dans le langage des développeurs et peut être considéré comme une première ébauche du modèle de conception.

A ce niveau, trois diagrammes sont présentés: le diagramme de cas d’utilisation, le diagramme de séquence et le diagramme d’activité.

  1. Conception

La conception permet d’acquérir une compréhension approfondie des contraintes liées au langage de programmation, à l’utilisation des composants et au système d’exploitation.

Elle détermine les principales interfaces et les transcrit à l’aide d’une notation commune.

Elle constitue un point de départ à l’implémentation : elle décompose le travail d’implémentation en sous-système elle créée une abstraction transparente de l’implémentation.

A ce niveau, quatre diagrammes sont présentés: le diagramme d’objet, diagramme de collaboration, diagramme de classe et le diagramme d’état-transition.

  1. Implémentation

Cette phase est la production du logiciel sous forme de composants ou de fichiers. Comme dans toutes les autres méthodes, l’implémentation reste la plus lourde en charge par rapport à l’ensemble des autres phases.

A ce niveau, deux diagrammes sont présentés: le diagramme de déploiement et le diagramme des composants.

  1. Test

Les tests permettent la vérification de:

  • résultats de l’implémentation de toutes les exigences,
  • fonctionnement correct des interactions entre les objets,
  • la bonne intégration de tous les composants dans le logiciel.

C’est ainsi que différents niveaux de tests sont réalisés dans cette activité : test unitaire, test d’intégration, test de réception, test de performance et test de non régression.

Cette activité vise à tester le diagramme de cas d’utilisation, le diagramme de séquence système et le diagramme d’activité.

La figure suivante résume les activités et phases de la démarche UP (JOSEPH & DAVID, 2008, p. 130)

Figure 3. 1 - Activités et phases de la démarche UP

3.5. Démarche de développement du processus unifié

Le processus unifié UP utilise le langage UML (Unified Modeling Language) pour la présentation des différents modèles et diagrammes.

Chaque activité du processus unifié se termine par la réalisation d’un certain nombre des diagrammes.

Les lignes suivantes seront consacrées à l’application de la démarche dans le cadre de notre travail. Nous présenterons pour chaque activité les diagrammes qui sont nécessaire dans le contexte de ce travail.

3.5.1. Expression des besoins

  1. Élaboration du schéma de contexte du domaine d’étude

Le schéma de contexte permet de situer le domaine d’étude par rapport aux autres processus de l’entreprise.

Ainsi, nous observons que dans notre étude,  le domaine d’étude est en étroite relation avec les employés de ce service.

Figure 3. 2 - Schéma de contexte du domaine d’activité

  1. Diagramme de cas d’utilisation système

- Élaboration du diagramme de cas d’utilisation système

Figure 3. 3 - Diagramme de cas d’utilisation système

- Description générale des cas d’utilisation

  • Cas d’utilisation « encoder et enregistrer les fiches » - une fois que les fiches sont arrivées chez le réceptionniste, il les encode puis les enregistre dans la base de données. L’encodage des fiches est réalisé par semaine. Le réceptionniste peut ainsi retrouver pour une semaine donnée, les fiches qu’il a reçues. Apres enregistrement les données peuvent être modifiées.
  • Cas d’utilisation «vérifier la qualité des données enregistrées» -une fois que l’administrateur a reçu les fiches de surveillance, il examine la qualité des données se trouvant sur chaque fiche, vérifie si le formulaire est bien rempli. Si oui, il passe à l’étape suivante, si non il contacte la zone de santé concernée pour plus d’information, cette fiche est directement déclassée jusqu’à ce que cette zone de santé envoie un nouveau bien remplie. Vérifie si la fiche est arrivée à temps.
  • Cas d’utilisation «archiver les données dans le registre» - après vérification des données, l’administrateur peut maintenant les stocker dans le registre de notification et données échangées.
  • Cas d’utilisation «mettre à jour le registre» - après stockage, l’administrateur Mets à jour les totaux récapitulatifs de chaque semaine. Pour aider l’analyste à bien faire ses analyses.
  • Cas d’utilisation «traiter des données» - après que l’administrateur a archivé les données dans le registre de notification et données échangées, l’analyste procède à l’analyse des données enregistrées. Il fait l’analyse en fonction du temps, du lieu, des personnes et en fonction de seuils. C’est avec c’est analyse qu’il pourra faire des graphiques pour voir l’évolution des épidémies.
  • Cas d’utilisation «valider les informations des registres» - Cette étape est faite par le directeur général. Les données analysées doivent être vérifiées par le DG pour la validation des résultats et prendre des décisions concernant ces épidémies.

3.5.2. Analyse

Il sera question de présenter le diagramme de cas d’utilisation, le diagramme de séquence et les diagrammes d’activité.

  1. Élaboration du diagramme des cas d’utilisation

Les cas d’utilisation constituent un moyen de recueillir et de décrire les besoins des acteurs du système. Ils peuvent être aussi utilisés ensuite comme moyen d’organisation du développement du logiciel, notamment pour la structuration et le déroulement des tests du logiciel. Un cas d’utilisation permet de décrire l’interaction entre les acteurs (utilisateurs du cas) et le système. La description de l’interaction est réalisée suivant le point de vue de l’utilisateur (MBIKAY, 2014).

Un acteur est un utilisateur type qui a toujours le même comportement vis-à-vis d’un cas d’utilisation. Ainsi les utilisateurs d’un système appartiennent à une ou plusieurs classes d’acteurs selon les rôles qu’ils tiennent par rapport au système.

Une même personne physique peut se comporter en autant d’acteurs différents que le nombre de rôles qu’elle joue vis-à-vis du système.

Un cas d’utilisation correspond à un certain nombre d’actions que le système devra exécuter en réponse à un besoin d’un acteur. Il doit produire un résultat observable pour un ou plusieurs acteurs du système.

Figure 3. 4 - Diagramme de cas d’utilisation

  1. b) Élaboration des diagrammes de séquence

L’objectif du diagramme de séquence est de représenter les interactions entre objets en indiquant la chronologie des échanges.

Ainsi, nous établissons :

  • Le diagramme de séquence d’authentification. (Figure 3.5)
  • Le diagramme de séquence de déconnexion.
  • Le diagramme de séquence du cas d’utilisation «encoder et enregistrer les données». (Figure 3.6)
  • Le diagramme de séquence du cas d’utilisation «vérifier la qualité des données enregistrées ».
  • Le diagramme de séquence du cas d’utilisation «archiver les données dans le registre». (Figure 3.7)
  • Le diagramme de séquence du cas d’utilisation «mettre à jour le registre».
  • Le diagramme de séquence du cas d’utilisation «traiter les données». (Figure 3.8)
  • Le diagramme de séquence du cas d’utilisation «valider les informations des registres ». (Figure 3.9)

Parmi ces diagrammes nous pouvons illustrer quelques uns :

Figure 3. 5 - Demande d’authentification

Figure 3. 6 - Diagramme de séquence du cas d’utilisation «encoder et enregistrer les données»

Figure 3. 7 - Diagramme de séquence de cas d’utilisation «archiver les données dans le registre»

Figure 3. 8 - Diagramme de séquence du cas d’utilisation «traiter les données»

Figure 3. 9 - Diagramme de séquence du cas d’utilisation «valider les informations dans le registre»

  1. Élaboration des diagrammes d’activité

Les concepts action et activité sont au cœur du diagramme d’activité :

Une action correspond à un traitement qui modifie l’état du système. Cette action peut être appréhendée soit à un niveau élémentaire proche d’une instruction en termes de programmation soit à un niveau plus global correspondant à une ou plusieurs opérations. L’enchaînement des actions constitue le flot de contrôle.

Une activité représente le comportement d’une partie du système en termes d’actions et de transitions.

  1. a) encoder et enregistrer les données

Le réceptionniste se connecte au système à partir de son terminal moyennant une authentification. S’il saisie un mauvais mot de passe, il a la possibilité de faire trois essais, au 4eme essai le système se déconnecte automatiquement. S’il saisie un bon mot de passe il a accès au système et la il peut encoder, chercher, modifier les fiches de surveillance.

Figure 3. 10 - Diagramme d’activité «encoder et enregistrer les données»

  1. b) vérifier la qualité des données enregistrées

L’administrateur se connecte au système à partir de son terminal moyennant une authentification. S’il saisie un mauvais mot de passe, il a la possibilité de faire trois essai, au quatrième essai le système se déconnecte automatiquement. S’il saisie un bon mot de passe il a accès au système et la il peut rechercher les fiches de surveillance encodées par le réceptionniste, vérifier si le formulaire est bien rempli, vérifier si les fiches sont arrivées à temps et enregistrer les fiches.

Figure 3. 11 - Diagramme d’activité «vérifier la qualité des données enregistrées»

  1. c) archiver les données dans le registre

L’administrateur se connecte au système à partir de son terminal moyennant une authentification. S’il saisie un mauvais mot de passe, il a la possibilité de faire trois essais, au quatrième essai le système se déconnecte automatiquement. S’il saisie le bon mot de passe, il a accès au système et la il peut rechercher la fiche de surveillance, la sélectionner, l’archiver dans le registre de notification puis enregistrer le registre de notification.

  1. d) mettre à jour le registre

L’administrateur se connecte au système à partir de son terminal moyennant une authentification. S’il saisie un mauvais mot de passe, il a la possibilité de faire trois essai, au quatrième essai le système se déconnecte automatiquement. S’il saisie le bon mot de passe, il a accès au système et la il peut rechercher la semaine, mettre à jour le registre et enregistrer les mises à jour.

  1. e) traiter les données

L’analyste se connecte au système à partir de son terminal moyennant une authentification. S’il saisie un mauvais mot de passe, il a la possibilité de faire trois essai, au quatrième essai le système se déconnecte automatiquement. S’il saisie le bon mot de passe, il a accès au système et la il peut traiter les données de plusieurs façons comme en fonction du temps, du lieu, des personnes. Après analyse, il enregistre les données qu’il a obtenu, et les imprime.

Figure 3. 12 - Diagramme d’activité «traiter les données»

  1. f) valider les informations des registres

La direction générale se connecte au système à partir de son terminal moyennant une authentification. Si elle saisit un mauvais mot de passe, elle à la possibilité de faire trois essais, au quatrième essai le système se déconnecte automatiquement. Si elle saisit le bon mot de passe, elle a accès au système et la elle recherche les registre, vérifier le registre, prépare le commentaire, valide le registre et enregistre le registre.

3.5.3. Conception

  1. Dictionnaire des données (Tableau 3.1)

Un dictionnaire de données est le support du travail, le résultat de la recherche et l’analyse des données. Il se présente sous la forme d’un tableau dans lequel on représente chaque classe avec ses attributs ainsi que les propriétés de ceux-ci: la désignation, le type, la taille en nombre de caractères et éventuellement une règle de calcul (KASORO, 2014). Chaque propriété suivie par le signe # montre que c’est l’identifiant.

  1. tableau des descriptions des données (Tableau 3.2)

L’association est une relation statique n-aire (souvent binaire), c’est-à-dire qu’elle relie plusieurs classes entre elles pour montrer une structure. Le tableau ci-dessous représente toutes les associations qui interviennent dans notre travail.

Tableau 3.  1 - Dictionnaire de données

N °

Classe

Propriété

Type

longueur

1

FicheSurveillance

IdFiche #

Cas

Deces

DateEnvoi

DateReception

IdMaladie

IdAge

IdZone

IdSemaine

IdUtilisateur

Integer

Integer

Integer

Date

Date

Integer

Integer

Integer

Integer

Integer

X(5)

X(10)

X(10)

X(10)

X(10)

X(5)

X(5)

X(5)

X(5)

X(5)

2

ZoneSante

IdSante #

Designation

Pays

Province

Commune

Ville

AireSante

Structure

MedecinDir

Qualification

NumTel

Email

DateEncodage

IdUtilisateur

Integer

Varchar

Varchar

Varchar

Varchar

Varchar

Varchar

Varchar

Varchar

Varchar

Integer

Varchar

Date

Integer

X(5)

X(30)

X(20)

X(30)

X(20)

X(20)

X(20)

X(20)

X(20)

X(20)

X(10)

X(30)

X(10)

X(5)

3.

Age

IdAge #

Intervalle

Integer

Varchar

X(5)

X(30)

4.

RegistreNotification

IdRegistre #

DescriptionNotifRecue

Periode

BienRemplie

DelaiRetard

RetroinfoSite

Commentaires

IdFiche

IdUtilisateur

Integer

Varchar

Varchar

Varchar

Varchar

Varchar

Varchar

Integer

Integer

X(5)

X(50)

X(20)

X(3)

X(6)

X(3)

X(50)

X(5)

X(5)

5.

Utilisateur

IdUtilisateur #

Pseudo

TypeUtilisateur

MotPasse

Fonction

Integer

Varchar

Varchar

Varchar

Varchar

X(5)

X(15)

X(15)

X(15)

X(20)

6.

Maladie

IdMaladie #

Designation

Integer

Varchar

X(5)

X(30)

7.

Calendrier

IdSemaine #

Semaine

Debut

Fin

IdAnnee

IdMois

Integer

Integer

Integer

Integer

Integer

Integer

X(5)

X(2)

X(10)

X(10)

X(5)

X(5)

8.

Annee

IdAnnee #

Integer

X(5)

9.

Mois

IdMois #

Integer

X(5)

 

Tableau 3.  2 - Description des associations

Association/classe

Désignation

Classes

Multiplicité

Contenir

Une fiche de surveillance contient une t une seule zone de santé

ZoneSante

1..*

FicheSurveillance

1..1

Posséder

Une fiche de surveillance possède un ou plusieurs âges

Age

1..*

FicheSurveillance

1..1

Ecrire

Un utilisateur écrit un ou plusieurs registres de notification

RegistreNotification

1..*

Utilisateur

1..1

Exister

Dans un calendrier, il existe une ou  plusieurs années

Annee

1..1

Calendrier

1..*

Provenir

Plusieurs mois proviennent d’un seul calendrier

Mois

1..*

Calendrier

1..1

Comprendre

Une fiche de surveillance a un et un seul calendrier

Calendrier

1..1

FicheSurveillance

1..1

Retrouver

Dans une fiche de surveillance on retrouve plusieurs maladies

Maladie

1..*

FicheSurveillance

1..1

Saisir

Un utilisateur saisit une ou plusieurs zones de sante

ZoneSante

1..*

Utilisateur

1..1

Renfermer

Un registre de notification renferme une ou plusieurs fiches de surveillance

FicheSurveillance

1..*

RegistreNotification

1..1

Completer

Un utilisateur peut completer une ou plusieurs fiches de surveillance

Fiche-surveillance

1..*

Utilisateur

1..1

  1. Elaboration du diagramme de classe

Le diagramme de classe constitue l’un des pivots essentiels de la modélisation avec UML. En effet, ce diagramme permet de donner la représentation statique du système à développer. Cette représentation est centrée sur les concepts de classe et d’association. Chaque classe se décrit par les données et les traitements dont elle est responsable pour elle-même et vis-à-vis des autres classes. Les traitements sont matérialisés par des opérations. Le détail des traitements n’est pas représenté directement dans le diagramme de classe ; seul l’algorithme général et le pseudo-code correspondant peuvent être associés à la modélisation.

Pour mettre en place un diagramme de classe, il faut :

  • éliminer les classes redondantes en utilisant le principe d’héritage ;
  • trouver les classes du domaine étudié ;
  • trouver les associations entre classes ;
  • trouver les attributs des classes ;
  • organiser et simplifier le modèle ;
  • itérer et raffiner le modèle.

Après toutes ces étapes, nous avons retenu dans notre travail les classes suivantes :

ZoneSante, Utilisateur, FicheSurveillance, RegistreNotification, Maladie, Age, Calendrier, Mois, Année.

Figure 3. 13 - Diagramme de classe

3.5.4. Implémentation

Elaboration du diagramme de déploiement

Le diagramme de déploiement permet de représenter l’architecture physique supportant l’exploitation du système. Cette architecture comprend des nœuds correspondant aux supports physiques (serveurs, routeurs…) ainsi que la répartition des artefacts logiciels sur ces nœuds. C’est un véritable réseau constitué de nœuds et de connexions entre ces nœuds qui modélise cette architecture.

Un nœud correspond à une ressource matérielle de traitement sur laquelle des artefacts seront mis en œuvre pour l’exploitation du système. Les nœuds peuvent être interconnectés pour former un réseau d’éléments physiques.

Un artefact est la spécification d’un élément physique qui est utilisé ou produit par le processus de développement du logiciel ou par le déploiement du système. C’est donc un élément concret comme par exemple : un fichier, un exécutable ou une table d’une base de données.

Une spécification de déploiement peut être associée à chaque artefact. Elle permet de préciser les conditions de déploiement de l’artefact sur le nœud sur lequel il va être implanté.

Figure 3. 14 - Diagramme de déploiement

3.6. Elaboration du schéma de navigation générale

Figure 3. 15 - Navigation générale

3.7. Conclusion partielle

Dans ce chapitre, Il a été question de décrire le type de modélisation qu’on va utiliser dans notre logiciel qui aidera à la surveillance épidémiologique.

C’est ainsi que nous sommes partie de l’expression des besoins, de l’analyse, de la conception et de l’implémentation pour arriver au test de l’analyse.

Partager ce travail sur :