Table de matières
Table de matières
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é.
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 :
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.
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.
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.
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.
Le processus unifié étant organisé en fonction du temps, il est fractionné en quatre phases successives :
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 :
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).
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.
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)
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.
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é.
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.
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.
Les tests permettent la vérification de:
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
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
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é
- É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
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é.
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
L’objectif du diagramme de séquence est de représenter les interactions entre objets en indiquant la chronologie des échanges.
Ainsi, nous établissons :
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»
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.
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»
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»
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.
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.
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»
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
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.
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 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 |
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 :
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
Figure 3. 15 - Navigation générale
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.
Afric mémoire est une plateforme web pour le partage des mémoires et TFC entre étudiants du monde entier.
Enregistrer en PDF
Imprimer cette page
