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.
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 :
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.
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.
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
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 :
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.
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é.
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.
Figure 15 : Diagramme de séquence de gestion de paie
Figure 16 : Diagramme de séquence de gestion des congés
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é
Figure 17 : Diagramme d’activité pour la gestion de paie
Figure 18 : Diagramme d’activité pour la gestion des congés
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).
Notre application comprend les classes suivantes :
Tableau 2: Liste des associations et cardinalités
N° |
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) |
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 |
|
|
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 |
|
|
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 |
Figure 19: Diagramme des classes
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