Chapitre 4 : Modélisation Logiciel

Contents
1. Objectif ................................................................................................................................... 2
2. Introduction ............................................................................................................................. 2
3. Les Modèles contextuelles ...................................................................................................... 3
4. Les modèles comportementaux ............................................................................................... 5
4.1. Les modèles de flux de données ...................................................................................... 5
4.2. Les modèle de machine à états ........................................................................................ 6
5. Les modèles de données .......................................................................................................... 8

 1. Objectif

L'objectif de ce chapitre est d'introduire un certain nombre de modèles de système

qui peuvent être développés au cours du processus d'ingénierie des exigences. Ainsi à la
fin de cette leçon l’apprenant devra être capable :

• Comprendre pourquoi il est important d'établir les limites d'un système et

modéliser son contexte ;

• Comprendre les concepts de modélisation comportementale, de modélisation

de données et de modélisation d’objets ;

• Appréhender certaines des notations définies dans le langage de modélisation

unifié (UML) et comment ces notations peuvent être utilisées pour développer
des modèles de système.

2. Introduction

Les exigences des utilisateurs doivent être rédigées en langage naturel car elles
doivent être comprises par des personnes qui ne sont pas des experts techniques.
Cependant, des exigences système plus détaillées peuvent être exprimées d'une manière
plus technique. Une technique largement utilisée consiste à documenter la spécification du
système comme un ensemble de modèles de système. Ces modèles sont des représentations
graphiques qui décrivent les processus métier, le problème à résoudre et le système à
développer. En raison des représentations graphiques utilisées, les modèles sont souvent
plus compréhensibles que les descriptions détaillées en langage naturel des exigences du
système. Ils constituent également un pont important entre les processus d'analyse et de
conception.
 Les modèles peuvent être utilisé dans le processus d'analyse pour développer une
compréhension du système existant qui doit être remplacé ou amélioré ou pour spécifier le
nouveau système requis. Ils peuvent être utiliser pour représenter les systèmes sous
plusieurs perspectives :

• Une perspective externe, où le contexte ou l'environnement du système est

modélisé
• Une perspective comportementale, où le comportement du système est
modélisé
• Une perspective structurelle, où l'architecture du système ou la structure des
données traitées par le système est modélisée.

3. Les Modèles contextuelles

Dès le début de la phase recueil et d'analyse des exigences, il est important de

déterminer les frontières du système. Cela implique de travailler avec les parties prenantes
du système pour distinguer ce qu'est le système et quel est l'environnement du système.
Dans certains cas, la frontière entre un système et son environnement est relativement
claire. Par exemple, lorsqu'un système automatisé remplace un système manuel ou
informatisé existant, l'environnement du nouveau système est généralement le même que
celui du système existant. Dans d'autres cas, il y a plus de flexibilité et vous décidez de ce
qui constitue la frontière entre le système et son environnement pendant le processus
d'ingénierie des exigences.

Une fois que certaines décisions sur le frontière du système ont été prises, une partie
de l'activité d'analyse est la définition de ce contexte (environnement) et des dépendances
qu'un système a sur son environnement. Normalement, la production d'un modèle
architectural simple est la première étape de cette activité. La figure 1 est un modèle
architectural qui illustre la structure du système d'information qui comprend un réseau de
guichets automatiques bancaires. Les modèles architecturaux de haut niveau sont
généralement exprimés sous forme de schémas fonctionnels (encore appelé schéma-bloc,
schéma de principe ou en anglais block Diagram) simples où chaque sous-système est
représenté par un rectangle nommé et les lignes indiquent les associations entre les sous-
systèmes.

Figure 1 : Exemple de modèle architectural d’un système informatique de

guichet automatique

À partir de la figure 1, nous voyons que chaque guichet automatique est connecté à une
base de données de comptes, un système de comptabilité de succursale locale, un système
de sécurité et un système de prise en charge de la maintenance des machines. Le système
est également connecté à une base de données d'utilisation qui surveille la façon dont le
réseau des guichets automatiques est utilisé et à un système de guichet local. Ce système
de comptage fournit des services tels que la sauvegarde et l'impression. Celles-ci n'ont donc
pas besoin d'être incluses dans le système ATM lui-même.

Les modèles architecturaux décrivent l'environnement d'un système. Cependant, ils

n'indiquent pas les relations entre les autres systèmes de l'environnement et le système
spécifié. Les systèmes externes peuvent produire ou consommer des données du système.
Ils peuvent partager des données avec le système, ou être connectés directement, via un
réseau ou pas du tout. Ils peuvent être physiquement colocalisés ou situé dans des bâtiments
séparés. Toutes ces relations peuvent affecter les exigences du système en cours de
définition et doivent être prises en compte. Par conséquent, les modèles architecturaux
simples sont normalement complétés par d'autres modèles, tels que les modèles de
processus, qui montrent les activités de processus prises en charge par le système. Les
modèles de flux de données peuvent également être utilisés pour afficher les données
transférées entre le système et d'autres systèmes dans son environnement.

4. Les modèles comportementaux

Les modèles comportementaux sont utilisés pour décrire le comportement global du

système. Nous discuterons ici de deux types de modèles comportementaux : les modèles
de flux de données, qui modélisent le traitement des données dans le système, et les
modèles de machine à états, qui modélisent la réaction du système aux événements. Ces
modèles peuvent être utilisés séparément ou ensemble, selon le type système en cours de
développement.

4.1. Les modèles de flux de données

Les modèles de flux de données sont un moyen intuitif de montrer comment les
données sont traitées par un système. Au niveau de l'analyse, ils doivent être utilisés pour
modéliser la manière dont les données sont traitées dans le système existant. Dans La
notation utilisée dans ces modèles, le traitement fonctionnel est représenté par des
rectangles arrondis, les enregistrements de données par des rectangles et les mouvements
de données entre les fonctions par des flèches étiquetées.

Les modèles de flux de données sont utilisés pour montrer comment les données
circulent à travers une séquence d'étapes de traitement. Les données sont transformées à
chaque étape avant de passer à l'étape suivante. Ces étapes de traitement ou transformations
représentent des processus ou des fonctions logiciels lorsque des diagrammes de flux de
données sont utilisés pour documenter une conception logicielle. Un modèle de flux de
données, qui montre les étapes impliquées dans le traitement d'une commande de biens
(comme du matériel informatique) dans une organisation, est illustré à la figure 2. Ce
modèle particulier décrit le traitement des données dans l'activité « Passer une commande
d'équipement » dans le modèle de processus global illustré à la Figure 2. Le modèle montre
comment la commande des marchandises passe d'un processus à l'autre. Il montre
également les enregistrements de données (Fichier commandes et fichier Budget)
impliqués dans ce processus.

Figure 2 : Exemple de modèle de flux de donnée d’un processus de commande de

matériel

4.2. Les modèle de machine à états

Un modèle de machine d'état décrit la manière dont un système répond aux événements
internes ou externes. Le modèle de machine à états montre les états du système et les
événements qui provoquent des transitions d'un état à un autre. Il ne montre pas le flux de
données au sein du système. Ce type de modèle est souvent utilisé pour modéliser des
systèmes en temps réel car ces systèmes sont souvent pilotés par des stimuli provenant de
l'environnement du système.

Un modèle de machine d'état d'un système suppose qu'à tout moment, le système se
trouve dans l'un des nombreux états possibles. Lorsqu'un stimulus est reçu, cela peut
déclencher une transition vers un état différent. Par exemple, un système contrôlant une
valve peut passer d'un état « Valve ouverte » à un état « Valve fermée » lorsqu'une
commande d'opérateur (le stimulus) est reçue.

Cette approche de la modélisation de système est illustrée à la figure 3. Ce diagramme

montre un modèle de machine d'état d'un four à micro-ondes simple équipé de boutons
pour régler la puissance et la minuterie pour démarrer le système. Les vrais fours à micro-
ondes sont en fait beaucoup plus complexes que le système décrit ici. Cependant, ce modèle
comprend les caractéristiques essentielles du système. Pour simplifier le modèle, j'ai
supposé que le la séquence d'actions dans l'utilisation du micro-ondes est :

1) Sélectionnez le niveau de puissance (mi-puissance ou pleine puissance).

2) Saisissez le temps de cuisson.
3) Appuyez sur Start et les aliments sont cuits pendant la durée indiquée.

Pour des raisons de sécurité, le four ne doit pas fonctionner lorsque la porte est ouverte
et, à la fin de la cuisson, un signal sonore retentit. Le four a un affichage alphanumérique
très simple qui est utilisé pour afficher diverses alertes et messages d'avertissement.

La notation UML utilisé pour décrire les modèles de machines à états est conçue pour
modéliser le comportement des objets. Cependant, il s'agit d'une notation à usage général
qui peut être utilisée pour tout type de modélisation de machine d'état. Les rectangles
arrondis d'un modèle représentent les états du système. Ils comprennent une brève
description (suivant « do : ») des actions entreprises dans cet état. Les flèches étiquetées
représentent des stimuli qui forcent une transition d'un état à un autre.

Par conséquent, à partir de la figure 3, nous pouvons voir que le système répond
initialement au bouton pleine puissance ou demi-puissance. Les utilisateurs peuvent
changer d'avis après avoir sélectionné l'un d'entre eux et appuyer sur l'autre bouton. L'heure
est réglée et, si la porte est fermée, le bouton Démarrer est activé. Appuyez sur ce bouton
pour démarrer le four et la cuisson a lieu pendant la durée spécifiée.
 Figure 1 : Modèle de machine à état d’un four de micro-onde

5. Les modèles de données

La plupart des grands systèmes logiciels utilisent une grande base de données
d'informations. Dans certains cas, cette base de données est indépendante du système
logiciel. Dans d'autres, il est créé pour le système en cours de développement. Une partie
importante de la modélisation des systèmes consiste à définir la forme logique des données
traitées par le système. On les appelle parfois des modèles de données sémantiques.

La technique de modélisation de données la plus largement utilisée est la modélisation

Entité-Relation-Attribut (modélisation ERA), qui montre les entités de données, leurs
attributs associés et les relations entre ces entités. Les modèles de relation d'entité ont été
largement utilisés dans la conception de bases de données.

L'UML n'inclut pas de notation spécifique pour cette modélisation de base de données,
car il suppose un processus de développement orienté objet et modélise les données à l'aide
d'objets et de leurs relations. Cependant, vous pouvez utiliser l'UML pour représenter un
modèle de données sémantique. Vous pouvez considérer les entités d'un modèle ERA
comme des classes d'objets simplifiées (elles n'ont aucune opération), les attributs comme
des attributs de classe et les associations nommées entre les classes comme des relations.

La figure 4 est un exemple de modèle de données faisant partie du système de

bibliothèque LIBSYS présenté dans les chapitres précédents. Rappelons que LIBSYS est
conçu pour fournir des copies d'articles protégés par le droit d'auteur qui ont été publiés
dans des magazines et des revues et pour percevoir les paiements pour ces articles. Par
conséquent, le modèle de données doit inclure des informations sur l'article, le titulaire du
droit d'auteur et l'acheteur de l'article. J'ai supposé que les paiements pour les articles ne se
faisaient pas directement mais par l'intermédiaire des agences nationales de droits d'auteur.
 Figure 4 : Modèle de données du système de bibliothèque LIBSYS

La figure 4 montre qu'un article a des attributs représentant le titre, les auteurs, le nom
du fichier PDF de l'article et la taxe à payer. Ceci est lié à la source, où l'article a été publié,
et à l'Agence du droit d'auteur du pays de publication. L'agence du droit d'auteur et Source
sont tous deux liés au pays. Le pays de publication est important car les lois sur les droits
d'auteur varient selon les pays. Le diagramme montre également que les acheteurs passent
des commandes d'articles.