Conception et développement d'une application web sur la gestion du cursus scolaire des élèves à l'EPSP/ sud Kivu

3.3 A quoi sert UML

UML donne une définition sur une approche objet plus formelle et apporte la dimension logique à l'approche objet [NKU2013].

Pour concevoir en UML, il faut commencer par prendre de la hauteur par rapport au problème qui est posé et utiliser des concepts abstraits complètement indépendants des langages de programmation. L'utilisation d'un langage de programmation comme support de conception revient à faire une analyse peu précise et réductrice par rapport à une modélisation objet. A l'inverse de la plupart des technologies objet, UML permet de s'affranchir totalement de tout langage de programmation (permettant ainsi l'écueil de la limitation de vue du langage de programmation) pour élaborer et exprimer des modèles objet. Il a été pensé comme support d'analyse objet [NKU2013].

De plus, UML est un méta-modèle : il décrit très précisément tous les éléments de modélisation (permettant ainsi de limiter les ambiguïtés) et normalise les concepts objet. Étant un méta modèle, UML est valable pour tous les langages de programmation.

Il présente comme qualités d'être un langage sans ambigüité, un langage universel, un langage offrant le moyen de définir les structures de programmation, un langage ayant une représentation universelle (une communication performante et une notation graphique simple [ROQ2008].

UML propose aussi une notation pour représenter graphiquement les éléments de modélisation du méta modèle ; cette notation graphique est le support du langage UML. Ceci lui permet donc d'être visuellement plus compréhensible (pour comparer ou évaluer) et limite ainsi les ambiguïtés. Il offre un cadre avec différentes vues complémentaires du système sur plusieurs niveaux d'abstraction, les diagrammes, et contrôle ainsi que la complexité dans l'expression des solutions objets [ROQ2008].

3.4 Les diagrammes UML

UML 2 s'articule autour de treize types de diagrammes, chacun d'eux étant dédié à la représentation des concepts particuliers d'un système logiciel. Ces types de diagramme sont répartis en deux grands groupes à savoir six diagrammes structurels et sept diagrammes comportementaux.

Les diagrammes structurels sont :

- le diagramme de classes : montrant les briques de base statiques : les classes, les associations, les interfaces, les attributs, les opérations et les généralisations ;

- le diagramme d'objets : montrant les instances des éléments structurels et leurs liens à l'exécution ;

- le diagramme de packages : montrant l'organisation logique du modèle et les relations entre packages ;

- le diagramme de structure composite : montrant l'organisation interne d'un élément statique complexe ;

- le diagramme de composants : montrant des structures complexes, avec leurs interfaces fournies et requises ;

- Diagramme de déploiement : Il montre le déploiement physique sur les ressources matérielles.

Les diagrammes comportementaux sont :

- le diagramme de cas d'utilisation : montrant les interactions fonctionnelles entre les acteurs et le système à l'étude ;

- le diagramme de vue d'ensemble des interactions : fusionnant les diagrammes d'activité et de séquence pour combiner des fragments d'interaction avec des décisions et des flots ;

- le diagramme de séquence : montrant la séquence verticale des messages passés entre objets au sein d'une interaction ;

- le diagramme de communication : montrant la communication entre objets dans le plan au sein d'une interaction ;

- le diagramme de temps : fusionnant les diagrammes d'états et de séquence pour montrer l'évolution de l'état d'un objet au cours du temps ;

- le diagramme d'activité : montrant l'enchaînement des actions et décisions au sein d'une activité ;

- le diagramme d'états : montrant les différents états et transitions possibles des objets d'une classe.

Le présent travail va tout simplement se servir de quatre diagrammes parmi les treize. Il s'agit du diagramme de classes, le diagramme des cas d'utilisation, le diagramme de séquence et celui d'activités car UML n'étant pas une méthode, leur utilisation est laissé à l'appréciation de chacun. Même si le diagramme de classes est généralement considéré comme l'élément central d'UML ; des méthodologies, telles que le Processus Unifié, axent l'analyse en tout premier lieu sur les diagrammes de cas d'utilisation (Use Case). De même, on peut se contenter de modéliser seulement partiellement un système, par exemple certaines parties critiques.