Modélisation et implémentation d'un système d'aide à la décision pour le diagnostic de la fievre thyphoà¯de

CHAPITRE IV : ELABORATION DU SYSTEME

Tout au long de ce chapitre, il sera question de pouvoir entamer la conception du système en présentant d'abord la vue statique à travers le diagramme de classe comme objet de la première section, puis la vue dynamique au moyen du diagramme d'activités comme objet de la seconde section.

4.1. Développement du modèle statique

Le développement du modèle statique constitue la deuxième activité de l'étape d'analyse. Comme le montre la figure ci-dessous, elle se situe sur la branche gauche du cycle en Y¹⁶. Il permet de décrire les entités concernées par l'automatisation. Ce système comprend plusieurs diagrammes; pour notre cas, nous allons nous attarder sur le diagramme de classe.

Figure 14 : Branche gauche du cycle en Y.

¹⁶ROQUES,P., VALLEE, F., UML 2 en action, 4^ème Ed. Eyrolles, Paris 2007.

[56]

4.1.1. Diagramme de classe

Le diagramme de classes est le point central dans un développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs.

En conception, le diagramme de classes représente la structure d'un code orienté objet ou, à un niveau de détail plus important, les modules du langage de développement.

Il exprime d'une manière générale la structure statique du système en termes de classe et de relations entre ces classes. Le diagramme de classes met en oeuvre des classes, contenant des attributs et des opérations, et reliées par des associations ou des généralisations.

a. Formalisme

Classe A

Attribut Attribut : Attribut

Méthodes

classe B

Attribut Attribut : Attribut

Méthodes

Association

b. Concepts

Etant le socle même d'UML, ci-dessous les différents concepts liés à cette notion de classe :

? Classe : elle représente la description abstraite d'un ensemble d'objets possédant les mêmes caractéristiques. On peut parler également de type.

? Attributs : il s'agit de données, dont les valeurs représentent l'état de l'objet.

? Méthode : ces sont des opérations applicables aux objets.

? Association : une association représente une relation sémantique durable entre deux classes.

[57]

4.1.1.1. Règle de gestion

Une règle de gestion décrit une condition d'exécutions d'une action. Les règles de gestion ci-dessous ont été recensées pour le développement de notre système:

- Administrateur gère un ou plusieurs utilisateurs.

- Un utilisateur est géré par un et un seul administrateur

- Le médecin assure un ou plusieurs diagnostics.

- Un diagnostic est assuré par un et un seul médecin

- Diagnostic concerne un ou plusieurs patients.

- Un patient est concerné à un et un seul diagnostic.

4.1.1.2. Identification de classes

Les classes ci-dessous ont été recensées pour la présentation de notre diagramme de classe :

? Administrateur

? Médecin

? Utilisateur

? Diagnostic

? Patient

4.1.1.3. Dictionnaire de données

Nous présentons dans le tableau ci-dessous, les différentes classes recensées sur base de la règle de gestion ci-dessus, ses attributs et les structurer en taille et en type.

[58]

Tableau 10 : Dictionnaire de données.

N°	Attribut	Libellé	Type	Taille
1	id_util	Identifiant de l'utilisateur	Chaine de caractère	8
	Nom_utilis	Nom de l'utilisateur	Chaine de caractère	30
	Pseudo_ut	Pseudo de l'utilisateur	Chaine de caractère	10
	Mot_pass	Le mot de passe de l'utilisateur	Chaine de caractère	9
2	Matricule_med	Matricule du médecin	Chaine de caractère	5
	Nom_med	Nom du médecin	Chaine de caractère	30
	Spécialité_med	Spécialité du médecin	Chaine de caractère	25
	Nationalite_me d	nationalité du médecin	Chaine de caractère	15
	Téléphone_me d	Téléphone du médecin	Chaine de caractère
3	Id_admin	Identification de l'administrateur	Chaine de caractère	5
	Nom adm	Nom de l'administrateur	Chaine de caractère	30
	Pseudo_Admin	Pseudo de l'administrateur	Chaine de caractère	30
	MotPasse_adm in	Mot de passe de l'administrateur	Chaine de caractère	10
4	Numéro_diagn	Numéro du diagnostic	Chaine de caractère	10
	Signes_vitaux	Signes vitaux	Chaine de caractère	300
	Date_diagn	Date du diagnostic	Date
	Observation	Observation	Chaine de caractère	40
5	CodeMal	Code malade	Chaine de caractère	8
	NomMal	Nom du malade	Chaine de caractère	30
	Sexe	Sexe du malade	Chaine de caractère	1
	AgeMal	Age du malade	Chaine de caractère	10
	Pouls	Pouls	Chaine de caractère	10
	TensionArt	Tension artérielle	Chaine de caractère	10
	Temperature	Température	Chaine de caractère	10

[59]

4.1.1.4. Présentation des classes

Nous présentons dans le tableau ci-dessus les différentes classes identifiées ainsi que leurs attributs et méthodes.

Tableau 11 : Liste des classes

N°	Nom de la classe	Attribut	Méthodes
1	Utilisateur	id_util	Avoir_accès Afficher() Supprimer ()
		Nom_utilis
		Pseudo_ut
		Mot_pass
2	Médecin	Matricule_med	Consulter() Prescrire()
		Nom_med
		Spécialité_med
		Nationalite_med
		Téléphone_med
3	Administrateur	Id_admin	Avoir_accès() Modifier ()
		Nom adm
		Pseudo_Admin
		MotPasse_admin
4	Diagnostic	Numéro_diagn	Afficher () Ajouter () Rechercher ()
		Signes_vitaux
		Date_diagn
		Observation
5	Patient	CodeMal	Payer_consultation() Faire_examen
		NomMal
		Sexe
		AgeMal
		Pouls
		TensionArt
		Temperature

[60]

4.1.1.5. Association et Multiplicité

a. Association

Une association représente une relation sémantique durable entre deux classes. Le modèle de données d'UML comprend trois associations génériques principales :

Généralisation, association, dépendance à partir de ces trois associations de base, nous représentons ainsi les différents types d'association qui décrivent les dépendances entre les classe déjà citées.

Association simple : les associations simples sont des liaisons logiques entre entités.

a. Les cardinalités/Multiplicité

Le nombre d'association qui surviennent entre des éléments spécifiques. Par exemple, un client peut passer plusieurs commandes et un employé travaille dans un service.

Il sied toutefois de rappeler qu'à l'approche orienté objet, on parle de multiplicité.

Le tableau ci-dessous illustre d'ailleurs les différentes multiplicités : Tableau 12 : Multiplicités

Multiplicités	Désignation
1	Un et un seul
0...1	Zéro ou un
N	Entier naturel
m...n	De m à n (deux entiers naturels)
0...*	De 0 à plusieurs
1...*	De 1 à plusieurs

Tableau 14 : Diagramme de classe.

[61]

Nous représentons les différentes multiplicités de notre système dans le tableau suivant :

Tableau 13 : Représentation des associations simples

N°	Désignation	Classes participantes	Cardinalités
1	Gérer	Administrateur-Utilisateurs	1..*-1
2	Ajouter	Administrateur-Médecin	1..* -1
3	Assurer	Diagnostic-Médecin	1..*-1
4	Créer	Administrateur-Médecin	1-1..*
5	Concerner	Diagnostic-Patient	1..*-1

Diagramme de classe

[62]

4.1.2. Règle de passage d'un diagramme de classe vers un modèle relationnel.

Le passage d'un diagramme de classe vers un modèle relationnel est rendu possible suivant un certain nombre des règles. Parmi ces règles nous avons :

y' Toute classe du diagramme devient une table dans laquelle les attributs deviennent les colonnes et choisir un attribut pour la clé

y' Association 1.. : on ajoute un attribut de type clé étrangère dans la relation fils de l'association. l'attribut porte le nom de la clé primaire de la relation père de l'association.

y' Association plusieurs vers plusieurs (*..*) : la classe association devient une relation. La clé primaire de cette relation est la concaténation des identifiants des classes connectées à l'association.

y' Association 1..1 : il faut ajouter un attribut de type clé étrangère dans la relation dérivée de la classe ayant la multiplicité minimale égale à un. L'attribut porte le nom de la clé primaire de la relation dérivée de la classe connecté à l'association. Si les deux multiplicités minimales sont à un, il est préférable de fusionner les deux classes en une seules.

4.2. Développement du modèle dynamique

Le développement du modèle dynamique constitue la troisième activité de l'étape d'analyse. Elle se situe sur la branche gauche du cycle en Y. Il s'agit d'une activité itérative, fortement couplée avec l'activité de modélisation statique, décrite au chapitre précédent.

Le modèle dynamique montre les comportements du système et l'évolution des objets dans le temps. Dans la même perspective, son but c'est de trouver les relations temporelles et évènementielles entre les objets.¹⁷

¹⁷MVIBUDULU, J.A Opcit P30.

[63]

4.2.1. Diagramme d'activités

Diagramme de flux de travaux qui décrit les activités des utilisateurs et leur séquence de déroulement.

Le diagramme d'activité permet de représenter le déclenchement d'évènements en fonction des états du système et de modéliser des comportements parallélisables. Il donne une vision des activités propres à une opération ou à un cas d'utilisation.

Il sied toutefois de rappeler qu'une activité est une opération d'une certaine durée qui peut être interrompue.

[64]

4.2.1.1. Diagramme d'activité « s'authentifier »

Figure n° 16 : Diagramme d'activité s'authentifier

[65]

4.2.1.4. Diagramme d'activités « Consultation »

Figure n°17 : Diagramme d'activité « consulter malade »

[66]