UML langage qui permet de représenter des modèles

Méthodologie des systèmes d’information – UML

Comment modéliser avec UML ?
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus d’élaboration des modèles! Cependant, dans le cadre de la modélisation d’une application informatique, les auteurs d’UML préconisent d’utiliser une démarche : – itérative et incrémentale, – guidée par les besoins des utilisateurs du système, – centrée sur l’architecture logicielle. D’après les auteurs d’UML, un processus de développement qui possède ces qualités devrait favoriser la réussite d’un projet.
Une démarche itérative et incrémentale ? L’idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s’y prendre en plusieurs fois, en affinant son analyse par étapes. Cette démarche devrait aussi s’appliquer au cycle de développement dans son ensemble, en favorisant le prototypage. Le but est de mieux maîtriser la part d’inconnu et d’incertitudes qui caractérisent les systèmes complexes. Une démarche pilotée par les besoins des utilisateurs ? Avec UML, ce sont les utilisateurs qui guident la définition des modèles : Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce que doit être le système). Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système). Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de développement (itératif et incrémental) : à chaque itération de la phase d’analyse, on clarifie, affine et valide les besoins des utilisateurs. A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs. A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.
Une démarche centrée sur l’architecture ? Une architecture adaptée est la clé de voûte du succès d’un développement. Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité…). Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui permettent de définir un modèle d’architecture (publication IEEE, 1995). Cette vue (« 4+1 ») a fortement inspiré UML :
Définir une architecture avec UML (détail de la « vue 4+1 ») ¾La vue logique Cette vue de haut niveau se concentre sur l’abstraction et l’encapsulation, elle modélise les éléments et mécanismes principaux du système. Elle identifie les éléments du domaine, ainsi que les relations et interactions entre ces éléments : les éléments du domaine sont liés au(x) métier(s) de l’entreprise, ils sont indispensables à la mission du système, ils gagnent à être réutilisés (ils représentent un savoir-faire). Cette vue organise aussi (selon des critères purement logiques), les éléments du domaine en « catégories » : pour répartir les tâches dans les équipes, regrouper ce qui peut être générique, isoler ce qui est propre à une version donnée, etc…
La vue des composants Cette vue de bas niveau (aussi appelée « vue de réalisation »), montre : L’allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de données, exécutables, etc…). En d’autres termes, cette vue identifie les modules qui réalisent (physiquement) les classes de la vue logique. L’organisation des composants, c’est-àdire la distribution du code en gestion de configuration, les dépendances entre les composants… Les contraintes de développement (bibliothèques externes…). La vue des composants montre aussi l’organisation des modules en « sous-systèmes », les interfaces des sous-systèmes et leurs dépendances (avec d’autres sous-systèmes ou modules).
La vue des processus Cette vue est très importante dans les environnements multitâches ; elle montre : La décomposition du système en terme de processus (tâches); les interactions entre les processus (leur communication); la synchronisation et la communication des activités parallèles (threads).
La vue de déploiement Cette vue très importante dans les environnements distribués, décrit les ressources matérielles et la répartition du logiciel dans ces ressources : la disposition et nature physique des matériels, ainsi que leurs performances, l’implantation des modules principaux sur les nœuds du réseau, les exigences en terme de performances (temps de réponse, tolérance aux fautes et pannes…).
La vue des besoins des utilisateurs Cette vue (dont le nom exact est « vue des cas d’utilisation »), guide toutes les autres. Dessiner le plan (l’architecture) d’un système informatique n’est pas suffisant, il faut le justifier ! Cette vue définit les besoins des clients du système et centre la définition de l’architecture du système sur la satisfaction (la réalisation) de ces besoins. A l’aide de scénarios et de cas d’utilisation, cette vue conduit à la définition d’un modèle d’architecture pertinent et cohérent. Cette vue est la « colle » qui unifie les quatre autres vues de l’architecture. Elle motive les choix, permet d’identifier les interfaces critiques et force à se concentrer sur les problèmes importants.