La modélisation¶

La meilleure façon pour un analyste de décrire les spécifications d’un système d’information consiste à utiliser un ensemble de modèles. Un système est très complexe, c’est pourquoi l’analyste créer divers modèles englobants toute l’information qu’il y a recueilli pendant la phase d’analyse.

Les modèles montrent différentes parties du problème et de sa solution. Un modèle peut par exemple, montrer les entrées et un autre, les données stocker.

Certains modèles représentent le même problème et sa solution, mais sous différents angles. Ainsi, un modèle peut montrer comment les objets interagissent du point de vue des acteurs extérieurs et un autre, comment les mêmes objets interagissent en termes de séquence.

Certains développeurs pensent que les modèles sont une forme de documentation que l’on produit une fois le travail d’analyse terminé alors, qu’en réalité ils aident l’analyste à clarifier et à raffiné la conception. L’analyste en apprend de plus en plus sur le système à mesure qu’il complète et étudie les différents modèles.

Pendant qu’il crée un modèle l’analyste se pose également des questions et les résout et fur et à mesure de l’avancement de la modélisation en collaboration avec son équipe.

Simplification¶

La difficulté à décrire les systèmes d’informations est un autre facteur clé justifiant l’importance de la modélisation. Les systèmes d’informations sont très complexes et certains de leur composant sont intangibles.

Des modèles de leurs différentes parties aident à simplifier le travail d’analyse, car il ne s’attarde que sur quelques aspects du système à la fois.

Pourquoi un analyste utilise-t-il de nombreux modèles différents? Tout simplement parce que chacun porte sur des aspects différents du système (logiciel).

De fait certains modèles créer ne servent qu’à intégrer certains de ces aspects. C'est-à-dire à montrer comment les autres modèles s’assortissent (interagisse entre eux)

La quantité d’information imposante que les analystes recueillent et doivent assimiler en proportion du temps que chacun passe sur un projet les obligent à revoir les modèles souvent afin de se rappeler du travail déjà réalisé. Les gens ne peuvent retenir qu'une quantité limite d’information; nous avons donc tous besoin d’un aide-mémoire. Les modèles sont une façon de stocker de l’information pour plus tard, mais sous une forme facilement assimilable.

Communication¶

L’une des raisons les plus souvent citées pour justifier la création d’un modèle à trait aux communications. Comme l’analyste apprend tout au long du processus de modélisation et que l’ensemble des modèles rend le système d’information moins complexe, les modèles jouent un rôle crucial pour supporter les communications entre les membres de l’équipe ainsi que les utilisateurs. Si un membre de l’équipe travaille sur le modèle des entrées et des sorties et qu’un autre travaille sur les modèles de processus de conversion de données, les deux (2) doivent donc se parle et coordonner leur travail pour s’assurer que leurs modèles respectifs seront compatibles. Le deuxième membre de l’équipe a besoin de voir les sorties souhaitées avant de les modéliser. En même temps, les deux (2) personnes doivent savoir quelles données seront stocker de façon à connaitre les entrées désirée et les processus requis pour accéder aux données nécessaires.

Les modèles appuient donc la communication et le travail d’équipe.¶

Documentation¶

Pour terminer, les modèles de spécification produits par l’analyste servent de documentation aux futures équipes de développement qui maintiendront ou amélioreront le système. Si l’on considère la quantité de ressources investies dans la production d’un nouveau système, il est primordial que l’équipe de développement laisse derrière elle des traces précise du travail accompli. Une activité importante de la phase de réalisation consiste à assembler la documentation (composé entre autres de modèles) dans une forme utilisable pour les futurs développeurs.

En résumer la modélisation peut paraitre enfantine mais est très importante pour : - Réduction de la complexité par abstraction - Rétention de tous les détails sous forme efficace - Communication avec les autres membres de l’équipe de développement - Communication avec les divers utilisateurs et intervenant - Documenter ce qui a été fait en vue de la maintenance.

Les outils de modélisation¶

Le Langage de Modélisation Unifié, de l'anglais Unified Modeling Language (UML), est un langage de modélisation graphique à base de pictogrammes conçu pour fournir une méthode normalisée pour visualiser la conception d'un système.

Il est couramment utilisé en développement logiciel et en conception orientée objet.

UML¶

L'UML est le résultat de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard adopté par l'Object Management Group (OMG).

UML 1.0 a été normalisé en janvier 1997; UML 2.0 a été adopté par l'OMG en juillet 2005. La dernière version de la spécification validée par l'OMG est UML 2.5.1 (2017).

UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon développement d'un logiciel orienté objet. UML offre un standard de modélisation, pour représenter l'architecture logicielle.

Les différents éléments représentables sont : - Activité d'un objet/logiciel - Acteurs - Processus - Schéma de base de données - Composants logiciels - Réutilisation de composants

Grâce aux outils de modélisation UML, il est également possible de générer automatiquement tout ou partie du code d'une application logicielle, par exemple en langage Java, à partir des divers documents réalisés.

Types de diagrames UML¶

Diagrammes de structure ou diagrammes statiques¶

Les diagrammes de structure (structure diagrams) ou diagrammes statiques (static diagrams) rassemblent : - Diagramme de classes (class diagram) : représentation des classes intervenant dans le système.
Pour modéliser les classes, incluant les attributs et les opérations ainsi que les relations et les associations avec les autres classes, on utilise un diagramme de classe.
Un diagramme de classe est une vue statique du système et ne montre pas la nature dynamique des communications entre les objets du diagramme de classe.

Diagramme d'objets (object diagram) : représentation des instances de classes (objets) utilisées dans le système.
Diagramme de composants (component diagram) : représentation des composants du système d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de données…)
Diagramme de déploiement (deployment diagram) : représentation des éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage…) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent entre eux.
Diagramme des paquets (package diagram) : représentation des dépendances entre les paquets (un paquet étant un conteneur logique permettant de regrouper et d'organiser les éléments dans le modèle UML), c'est-à-dire entre les ensembles de définitions.

Diagrammes de comportement¶

Les diagrammes de comportement (behavior diagrams) rassemblent : - Diagramme des cas d'utilisation (use-case diagram) : représentation des possibilités d'interaction entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire de toutes les fonctionnalités que doit fournir le système. - Diagramme états-transitions (state machine diagram) : représentation sous forme de machine à états finis le comportement du système ou de ses composants. - Diagramme d'activité (activity diagram) : représentation sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants.

Diagrammes d'interaction ou diagrammes dynamiques¶

Les diagrammes d'interaction (interaction diagrams) ou diagrammes dynamiques (dynamic diagrams) rassemblent : - Diagramme de séquence (sequence diagram) : représentation de façon séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs. - Diagramme de communication (communication diagram) : représentation de façon simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets (depuis UML 2.x). - Diagramme global d'interaction (interaction overview diagram) : représentation des enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes de séquences (variante du diagramme d'activité) (depuis UML 2.x). - Diagramme de temps (timing diagram) : représentation des variations d'une donnée au cours du temps (depuis UML 2.3).