Arrow Table de matières
7815476

II.3.1. Le langage de modélisation UML

II.3.1.1. Définition

Unified Modeling Language est un langage unifié de modélisation objets. Ce n’est pas une méthode, il ne donne pas de solution pour la mise en œuvre d’un projet. C’est avant tout un formalisme graphique issu de notations employées dans différentes méthodes objets.

II.3.1.2 Rôle d’UML

s

UML utilise l’approche objet en présentant un langage de description universel. Il permet, grâce à un ensemble de diagrammes très explicites, de représenter l’architecture et le fonctionnement des systèmes informatiques complexes en tenant compte des relations entre les concepts utilisés et l’implémentation qui en découle.

UML est avant tout un support de communication performant, qui facilite la représentation et la compréhension de solutions objet :

  • sa notation graphique permet d’exprimer visuellement une solution objet ; ce qui facilite la comparaison et l’évaluation de solutions ;
  • l’aspect formel de sa notation limite les ambigüités et les incompréhensions ;
  • son indépendance par rapport aux langages de programmation, aux domaines d’application et aux processus en fait un langage universel.

II.3.1.3. Définition d’un diagramme

Un diagramme UML est une représentation graphique, qui s’intéresse à  un aspect précis du modèle ; c’est une perspective du modèle.

Chaque type de diagramme UML possède une structure (les types des éléments de modélisation qui le composent sont prédéfinis) et véhicule une sémantique précise (il offre toujours la même vue d’un système). Les diagrammes permettent donc d’inspecter un modèle selon différentes perspectives et guident l’utilisation des éléments de modélisation (les concepts objets), car ils possèdent une structure.

II. 3.2. Conception des diagrammes pour la modélisation du système concerné

Dans cette partie, différents diagrammes seront présentés pour mieux analyser le système actuel tout en dégageant les acteurs, leurs rôles est de déterminer les relations entre les classes etc. Ici trois digrammes nous permettent d’expliquer le cahier de charge et deux autres diagrammes pour la conception architecturale.

1.         Diagramme de cas d’utilisation[1]

Sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d’un système logiciel. Ils sont utiles pour des présentations auprès de la direction ou des acteurs d’un projet, mais pour le développement, les cas d’utilisation sont plus appropriés. Un cas d’utilisation représente une unité discrète d’interaction entre un utilisateur (humain ou machine) et un système. Il est une unité significative de travail. Dans un diagramme de cas d’utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d’utilisation (use cases).

UML définit une notation graphique pour représenter les cas d’utilisation, cette notation est appelée diagramme de cas d’utilisation. UML ne définit pas de standard pour la forme écrite de ces cas d’utilisation, et en conséquence il est aisé de croire que cette notation graphique suffit à elle seule pour décrire la nature d’un cas d’utilisation. Dans les faits, une notation graphique peut seulement donner une vue générale simplifiée d’un cas ou d’un ensemble de cas d’utilisation. Les diagrammes de cas d’utilisation sont souvent confondus avec les cas d’utilisation. Bien que ces deux concepts soient reliés, les cas d’utilisation sont bien plus détaillés que les diagrammes de cas d’utilisation.

Ils permettent de décrire l’interaction entre l’acteur et le système. L’idée forte est de dire que l’utilisateur d’un système logiciel a un objectif quand il utilise le système, Le cas d’utilisation est une description des interactions qui vont permettre à l’acteur d’atteindre son objectif en utilisant le système. Les use case (cas d’utilisation) sont représentés par une ellipse sous-titrée par le nom du cas d’utilisation (éventuellement le nom est placé dans l’ellipse). Un acteur et un cas d’utilisation sont mis en relation par une association représentée par une ligne.

NOTE : le plus souvent, le diagramme des cas est établi par la maîtrise d’ouvrage (MOA) d’un projet lors de la rédaction du cahier des charges afin de transmettre les besoins des utilisateurs et les fonctionnalités attendues associées à la maîtrise d’œuvre (MOE).

Pour notre ca, le cas d’utilisation se présente comme suit :

Figure 14 : Diagramme des cas d’utilisation

2. Diagramme de séquence[2]

Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation UnifiedModeling Langage.

Dans cette partie on va devoir parler de :

  1. L’utilité du diagramme de séquence,
  2. Dialogue entre les objets,
  3. Cadres d’interaction.
  • L’utilité du diagramme de séquence

Le diagramme de séquences permet de montrer les interactions d’objets dans le cadre d’un scénario de Diagramme des cas d’utilisation. Dans un souci de simplification, on représente l’acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets.

La dimension verticale du diagramme représente le temps, permettant de visualiser l’enchaînement des actions dans le temps, et de spécifier la naissance et la mort d’objets. Les périodes d’activité des objets sont symbolisées par des rectangles, et ces objets dialoguent par le biais de messages.

2.2. Dialogue entre les objets

Plusieurs types de messages (actions) peuvent transiter entre les acteurs et objets.

Message simple : le message n’a pas de spécificité particulière d’envoi et de réception.

Message avec durée de vie : l’expéditeur attend une réponse du récepteur pendant un certain temps et reprend ses activités si aucune réponse n’a lieu dans un délai prévu.

Message synchrone : l’expéditeur est bloqué jusqu’au signal de prise en compte par le destinataire. Les messages synchrones sont symbolisés par des flèches barrées.

Message asynchrone : le message est envoyé, l’expéditeur continue son activité que le message soit parvenu ou pris en compte ou non. Les messages asynchrones sont symbolisés par des demi-flèches.

Message dérobant : le message est mis en attente dans une liste d’attente de traitement chez le récepteur.

Le langage permet de décaler l’envoi et la réception des messages, pour montrer les délais de communication non négligeables. La plupart des ateliers UML ne prennent cependant pas en compte cette spécificité.

II.3. Cadres d’interaction

Pour les cas plus complexe, on peut intégrer des algorithmes dans les diagrammes de séquences. Par le biais de cadres d’interaction, on peut préciser les spécificités d’un ensemble de messages :

alt. : fragments multiple alternatifs (si alors sinon)

opt : fragment optionnel

par : fragment parallèle (traitements concurrents)

loop : le fragment s’exécute plusieurs fois

région : région critique (un seul thread à la fois)

neg : une interaction non valable

réf : référence à une interaction dans un autre diagramme

sd : fragment du diagramme de séquence en entier.

II.3.2.Présentation des diagrammes de séquence

  1. Diagramme de séquence pour la gestion de paie

Figure 15 : Diagramme de séquence de gestion de paie

  1. Diagramme de séquence de gestion des congés

Figure 16 : Diagramme de séquence de gestion des congés

III. Diagramme d’activité[3]

Le diagramme d’activité est un diagramme comportemental d’UML, permettant de représenter le déclenchement d’événements en fonction des états du système et de modéliser des comportements sparallélisables (multithreads ou multiprocessus). Le diagramme d’activité est également utilisé pour décrire un flux de travail (workflow).

Un diagramme d’activité permet de modéliser un processus interactif, global ou partiel pour un système donné (logiciel, système d’information). Il est recommandable pour exprimer une dimension temporelle sur une partie du modèle, à partir de diagrammes de classes ou de cas d’utilisation, par exemple.

Le diagramme d’activité est une représentation proche de l’organigramme; la description d’un cas d’utilisation par un diagramme d’activité correspond à sa traduction algorithmique. Une activité est l’exécution d’une partie du cas d’utilisation, elle est représentée par un rectangle aux bords arrondis.

Le diagramme d’activité est sémantiquement proche des diagrammes de communication (appelés diagramme de collaboration en UML 1), ou d’état-transitions, ces derniers offrant une vision microscopique des objets du système.

Présentation des diagrammes d’activité

  1. Diagramme d’activité pour la gestion de paie

Figure 17 : Diagramme d’activité pour la gestion de paie

  1. Diagramme d’activité pour la gestion des congés

Figure 18 : Diagramme d’activité pour la gestion des congés

  1. Diagramme de classe

Le diagramme des classes est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme fait partie de la partie statique d’UML car il fait abstraction des aspects temporels et dynamiques.

Une classe décrit les responsabilités, le comportement et le type d’un ensemble d’objets. Les éléments de cet ensemble sont les instances de la classe.

Une classe est un ensemble de fonctions et de données (attributs) qui sont liées ensemble par un champ sémantique. Les classes sont utilisées dans la programmation orientée objet. Elles permettent de modéliser un programme et ainsi de découper une tâche complexe en plusieurs petits travaux simples.

Les classes peuvent être liées entre elles grâce au mécanisme d’héritage qui permet de mettre en évidence des relations de parenté. D’autres relations sont possibles entre des classes, chacune de ces relations est représentée par un arc spécifique dans le diagramme de classes.

Elles sont finalement instanciées pour créer des objets (une classe est un moule à objet : elle décrit les caractéristiques des objets, les objets contiennent leurs valeurs propres pour chacune de ces caractéristiques lorsqu’ils sont instanciés).

  1. Identification des classes

Notre application comprend les classes suivantes :

  1. Agents: cette  classe traite des informations sur les agents de l’Hôpital Général de Référence de Lemera
  2. Admin : la classe admin enregistre les informations de l’administrateur du système.
  3. Paies: Cette classe enregistre les opérations de paie effectuées par le système.
  4. Avance sur salaire: dans cette classe on trouve les informations sur les avances perçus sur salaire;
  5. Retenus sur salaire : cette classe enregistre les informations des retenus sur le salaire;
  6. Congés : Cette classe comprend les informations essentielles sur les congés des agents.
  7. Indices : enregistre les informations essentielles sur l’outil indice de paie des agents.
  1. Les associations et cardinalités

Tableau 2: Liste des associations et cardinalités

Classes

Associations

Cardinalités

1

Agents-Paies

Effectuer

(1..*), (1)

2

Agents–Paies

Concerner

(1..*), (1)

3

Agents- Congés

Accorder

(1..*), (1)

4

Agents- Congés

Obtenir

(1..*), (1)

5

Paies–Indices

Concerner

(1), (1..*)

6

Paies- Avance/Salaire

Concerner

(1..*), (1)

7

Paies-Retenus/Salaire

Concerner

(1..*), (1)

                   

  1. Le dictionnaire de données

Tableau 3 : Dictionnaire des données

Classes

Nom

Type de données

Taille

Indices

id_indice

int

categorieProf

Varchar

100

Indice

double

5

Effectif

int

indiceTotal

double

Agents

id_agent

Int

Nom

Varchar

20

Postnom

Varchar

20

Prenom

Varchar

20

Sexe

Varchar

1

Date_naiss

date

Phone

Varchar

10

Email

Varchar

100

Fonction

varchar

100

Adresse

Varchar

255

Login

varchar

20

Passe

varchar

20

Admin

id_admin

Int

Nom

Varchar

20

Postnom

Varchar

20

Prenom

Varchar

20

Sexe

Varchar

1

Date_naiss

date

Tel

Varchar

10

Email

Varchar

100

Image

Varchar

255

Login

Varchar

20

Passe

Varchar

20

Paies

id_paie

int

id_agent

Int

id_indice

Int

100

Mois

Varchar

10

Date_paie

date

Montant

double

Obs

Varchar

255

Congés

id_conge

Int

id_agent

Date

type_conge

Varchar

20

Circonstance

Varchar

100

Date_debut

date

Date_fin

date

Obs

Varchar

255

Retenus sur Salaire

id_retenu

int

id_agent

int

Mois

Varchar

10

Motif

Varchar

100

Montant

double

Obs

Varchar

255

Avances sur Salaire

id_avance

int

id_agent

int

Mois

Varchar

10

Motif

Varchar

100

Montant

double

Obs

Varchar

255

  1. Présentation du diagramme des classes

Figure 19: Diagramme des classes

  1. Diagramme de déploiement

En UML, un diagramme de déploiement est une vue statique qui sert à représenter l’utilisation de l’infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de déploiement sont principalement les nœuds, les composants, les associations et les artefacts. Les caractéristiques des ressources matérielles physiques et des supports de communication peuvent être précisées par stéréotype[4].

Nœuds

Les nœuds (nodes), représentés par des cubes en trois dimensions, sont des composants mécaniques de l’infrastructure tel un routeur, un ordinateur, un assistant personnel, ... . Ceux-ci peuvent comprendre d’autre nœuds ou artefacts. Les nœuds internes indiquent l’environnement d’exécution plutôt que l’infrastructure physique.

Composants

Les composants, représentés par des boites rectangulaires avec deux rectangles sortant du côté gauche, sont les différentes parties du système étudié.

Connexions

Les connexions sont principalement de deux types : associations ou dépendances.

Associations

Les associations, représentées par de simples lignes sont des liens de communication, s’établissent entre les différents composants du système.

Dépendances

Les dépendances, représentées par des flèches vides, sont régies par les règles standards d’UML 2.0.

Artefacts

Dans ce contexte, un artefact est une manière de définir un fichier, un programme, une bibliothèque ou une base de données construite ou modifiée dans un projet. Ces artefacts mettent en œuvre des collections de composants qui sont consommées ou créées durant l’une des étapes du processus de déploiement.

Pour notre système, le diagramme de déploiement est le suivant

Figure 20 : Diagramme de déploiement

[1]https://fr.wikipedia.org/w/index.php?title=Diagramme_d%27activité&oldid=118070848 , Consulté le 30/06/2017

[2]  https://fr.wikipedia.org/w/index.php?title=Diagramme_de_séquence&oldid=117795050, Consulté le 09/07/2017

[3]https://fr.wikipedia.org/w/index.php?title=Diagramme_de_séquence&oldid=117795050 , Consulté le 06/07/2017

[4]  https://fr.wikipedia.org/w/index.php?title=Diagramme_de_déploiement&oldid=111161679, consulté le 02/07/2017

Partager ce travail sur :