Cours de Genie Logicielle
(Chap.4)
Prof. Dr Jean-Pepe
BUANGA
Plan du Cours
References
MODELISATION DE
PROCESSUS DE
DEVELOPPEMENT LOGICIEL
Introduction
La modélisation de développement logiciel
aide les développeurs à sélectionner la
stratégie pour développer le produit logiciel.
Chaque modélisation de développement
possède ses propres outils, ses méthodes et
ses procédures qui permettent d’exprimer
clairement et définissent le cycle de vie de
développement du logiciel.
Les modèles du cycle de vie du logiciel sont
des « plans de travail » qui permettent de
planifier le développement.
Introduction
Les modèles sont utilisés:
pendant le processus d'ingénierie des
exigences pour aider à dériver les
exigences d'un système;
pendant le processus de conception pour
décrire le système aux ingénieurs mettant
en œuvre le système;
après la mise en œuvre (Implementation)
pour documenter la structure et le
fonctionnement du système.
Introduction
Vous pouvez développer des modèles à la
fois du système existant et du système à
développer :
1. Les modèles du système existant sont
utilisés lors de l'ingénierie des exigences. Ils
aident à clarifier ce que fait le système
existant et peuvent être utilisés comme
base pour discuter de ses forces et de ses
faiblesses. Celles-ci conduisent ensuite à
des exigences pour le nouveau système.
Introduction
2. Les modèles du nouveau système sont
utilisés pendant l'ingénierie des exigences
pour aider à expliquer les exigences
proposées aux autres parties prenantes du
système.
Les ingénieurs utilisent ces modèles pour
discuter des propositions de conception et
documenter le système pour la mise en
œuvre.
Modèles de processus
logiciels
Un modèle de processus logiciel est une
représentation simplifiée d'un processus
logiciel.
Chaque modèle de processus représente un
processus d'un point de vue particulier et ne
fournit donc que des informations partielles
sur ce processus.
Par exemple, un modèle d'activité de
processus montre les activités et leur
séquence mais peut ne pas montrer les rôles
des personnes impliquées dans ces activités.
Modèles de processus
logiciels
Ce sont plutôt des abstractions du
processus qui peuvent être utilisées pour
expliquer différentes approches du
développement de logiciels.
Les modèles de processus sont :
Modèles de processus logiciels-
Modèle en cascade
Il prend les activités fondamentales de
processus de spécification, de
développement, de validation et d'évolution
et les représente sous forme de phases de
processus distinctes telles que la
spécification des exigences, la conception
de logiciels, la mise en œuvre, les tests, etc.
En raison de la cascade d'une phase à
l'autre, ce modèle est appelé modèle en
cascade ou cycle de vie du logiciel.
Modèles de processus logiciels-
Modèle en cascade
Modèles de processus logiciels-
Modèle en cascade
1. Analyse et définition des exigences Les
services, les contraintes et les objectifs du
système sont établis en consultation avec les
utilisateurs du système.
2. Conception du système et du logiciel Le
processus de conception des systèmes alloue
les exigences aux systèmes matériels ou
logiciels en établissant une architecture globale
système. La conception de logiciels implique
l'identification et la description des abstractions
fondamentales du système logiciel et de leurs
relations.
Modèles de processus logiciels-
Modèle en cascade
3. Implémentation et tests unitaires La
conception du logiciel est réalisée comme un
ensemble de programmes ou d'unités de
programme. Les tests unitaires consistent à
vérifier que chaque unité répond à ses
spécifications.
4. Intégration et test du système Les unités de
programme ou les programmes individuels sont
intégrés et testés en tant que système complet
pour s'assurer que les exigences du logiciel ont
été satisfaites. Après les tests, le système
logiciel est livré au client.
Modèles de processus logiciels-
Modèle en cascade
5. Exploitation et maintenance Il s'agit de la
plus longue phase de cycle de vie. Le
système est installé et mis en pratique.
La maintenance consiste à corriger les
erreurs qui n'ont pas été découvertes au
cours des premières étapes du cycle de vie,
à améliorer la mise en œuvre des unités du
système et à améliorer les services du
système à mesure que de nouvelles
exigences sont découvertes.
Modèles de processus logiciels-
Modèle en cascade
En principe, le résultat de chaque phase est
un ou plusieurs documents qui sont
approuvés. La phase suivante ne doit pas
commencer tant que la phase précédente
n'est pas terminée.
Lors de la conception, les problèmes liés
aux exigences sont identifiés. Lors du
codage, des problèmes de conception sont
détectés et ainsi de suite.
Modèles de processus logiciels-
Modèle en cascade
Les documents produits à chaque phase peuvent
alors devoir être modifiés pour refléter les
changements apportés.
En raison des coûts de production et
d'approbation des documents, les itérations
peuvent être coûteuses et impliquer
d'importants remaniements.
Par conséquent, après un petit nombre
d'itérations, il est normal de geler des parties du
développement, telles que la spécification, et de
continuer avec les étapes de développement
ultérieures.
Modèles de processus logiciels-
Modèle en cascade
Le modèle en cascade est cohérent avec
d'autres modèles de processus d'ingénierie et
une documentation est produite à chaque
phase. Cela rend le processus visible afin que
les gestionnaires puissent suivre les progrès
par rapport au plan de développement.
Son problème majeur est le cloisonnement
inflexible du projet en étapes distinctes. Les
engagements doivent être pris à un stade
précoce du processus, ce qui rend difficile de
répondre à l'évolution des besoins des clients.
Modèles de processus logiciels-
Modèle en cascade
En principe, le modèle en cascade ne doit
être utilisé que lorsque les exigences sont
bien comprises et qu'il est peu probable
qu'elles changent radicalement au cours du
développement du système.
Modèles de processus logiciels-
Développement incrémental
Le développement incrémentiel est basé sur
l'idée de développer une implémentation
initiale, de l'exposer aux commentaires des
utilisateurs et de la faire évoluer à travers
plusieurs versions jusqu'à ce qu'un système
adéquat ait été développé (Figure 2.2).
Cette approche entrelace les activités de
spécification, de développement et de
validation. Le système est développé sous la
forme d'une série de versions (incréments),
chaque version ajoutant des fonctionnalités à la
version précédente.
Modèles de processus logiciels-
Développement incrémental
Modèles de processus logiciels-
Développement incrémental
Le développement logiciel incrémental est
préférable à une approche en cascade pour
la plupart des systèmes d'entreprise, de
commerce électronique et personnels.
Le développement incrémental reflète la
façon dont nous résolvons les problèmes.
En développant le logiciel de manière
incrémentielle, il est moins coûteux et plus
facile d'apporter des modifications au logiciel
au fur et à mesure de son développement.
Modèles de processus logiciels-
Développement incrémental
Chaque incrément ou version du système
intègre certaines des fonctionnalités dont le
client a besoin. Généralement, les premiers
incréments du système incluent la
fonctionnalité la plus importante ou la plus
urgente.
Cela signifie que le client peut évaluer le
système à un stade relativement précoce
du développement pour voir s'il répond à
ses besoins.
Modèles de processus logiciels-
Développement incrémental
Le développement incrémentiel présente
trois avantages importants, par rapport au
modèle en cascade :
1. Le coût de l'adaptation aux besoins
changeants des clients est réduit. La
quantité d'analyse et de documentation à
refaire est bien inférieure à celle requise
avec le modèle en cascade.
Modèles de processus logiciels-
Développement incrémental
2. Il est plus facile d'obtenir des
commentaires des clients sur le travail de
développement qui a été effectué. Les clients
peuvent commenter les démonstrations du
logiciel et voir ce qui a été mis en œuvre.
3. Une livraison et un déploiement plus
rapide de logiciels utiles au client sont
possibles, même si toutes les fonctionnalités
n'ont pas été incluses. Les clients sont en
mesure d'utiliser et de valoriser le logiciel
plus tôt qu'avec un processus en cascade.
Modèles de processus logiciels-
Développement incrémental
Les problèmes de développement incrémentiel
deviennent particulièrement aigus pour les
grands systèmes complexes à longue durée de
vie, où différentes équipes développent
différentes parties du système.
Les grands systèmes ont besoin d'une
architecture stable et les responsabilités des
différentes équipes travaillant sur des parties du
système doivent être clairement définies par
rapport à cette architecture. Cela doit être
planifié à l'avance plutôt que développé
progressivement.
Modèles de processus logiciels-
Modele du code-and-fix
C’est un modèle qui repose sur la possibilité
d’une détermination facile des besoins : une
première phase de Compréhension du
problème est suivie d’une phase de
Programmation ; puis une phase de Mise au
point, parfois en collaboration avec
l'utilisateur du futur système, est répétée
jusqu’à l’atteinte du résultat visé.
Modèles de processus logiciels-
Modele du code-and-fix
Modèles de processus logiciels-
Transformation automatique
C’est un modèle basé sur la possibilité de
transformer automatiquement des
spécifications en programmes.
Modèles de processus logiciels-
Modele en V
Le modèle en V du cycle de vie du logiciel
précise la conception des tests : (les tests
système sont préparés à partir de la
spécification; les tests d’intégration sont
préparés à partir de la conception
architecturale ; les tests unitaires sont
préparés à partir de la conception détaillée
des composants).
Modèles de processus logiciels-
Modele en V
Modèles de processus logiciels-
Modele en V
La première branche correspond à un
modèle en cascade classique. Toute
description d’un composant est
accompagnée de définitions de tests.
La seconde branche correspond à des tests
effectifs effectués sur des composants
réalisés. L’intégration est ensuite réalisée
jusqu’à l’obtention du système logiciel final.
Modèles de processus logiciels-
Modele en V
L’avantage d’un tel modèle est d’éviter
d’énoncer une propriété qu’il est impossible
de vérifier objectivement une fois le logiciel
réalisé.
Il est largement utilisé, notamment en
informatique industrielle et en
télécommunication.
Modèles de processus logiciels-
Cycle de vie en spirale
Ce modèle repose sur le même principe que le
modèle évolutif, mais il s’inscrit dans une
relation contractuelle entre le client et le
fournisseur.
De ce fait les engagements et validations
présentent un caractère formalisé.
Chaque cycle donne lieu à une
contractualisation préalable, s’appuyant sur
les besoins exprimés lors du cycle précédent.
Le dernier cycle permet de développer la
version finale et d'implémenter le logiciel.
Modèles de processus logiciels-
Cycle de vie en spirale
Un cycle comporte six phases :
1)Analyse du risque ;
2)Développement d'un prototype (modèle,
archétype…) ;
3)Simulation et essais du prototype ;
4)Détermination des besoins à partir des
résultats des essais ;
5)Validation des besoins par un comité de
pilotage ;
6)Planification du cycle suivant.
Modèles de processus logiciels-
Cycle de vie en spirale
Modèles de processus logiciels-
Cycle de vie en spirale
Chaque cycle de la spirale se déroule en
quatre phases :
1. Un cycle de la spirale commence par
l’élaboration d’objectifs tels que la
performance, la fonctionnalité, etc. On
énumère ensuite les différentes manières
de parvenir à ces objectifs, ainsi que les
contraintes. On évalue ensuite chaque
alternative en fonction de l’objectif.
Modèles de processus logiciels-
Cycle de vie en spirale
2. L’étape suivante consiste à évaluer les
risques pour chaque activité, comme
l’analyse détaillée, le prototypage, la
simulation, etc.
3. Après l’évaluation des risques, choisir un
modèle de développement pour le système.
Par exemple, si les principaux risques
concernent l’interface utilisateur, le
prototypage évolutif pourrait s’avérer un
modèle de développement approprié.
Modèles de processus logiciels-
Cycle de vie en spirale
Le modèle de la cascade peut être le plus
approprié si le principal risque identifié
concerne l’intégration des sous-systèmes. Il
n’est pas nécessaire d’adopter un seul
modèle à chaque cycle de la spirale ou même
pour l’ensemble d’un système. Le modèle de
la spirale englobe tous les autres modèles.
4. La situation est ensuite réévaluée pour
déterminer si un développement
supplémentaire est nécessaire, auquel cas il
faudrait planifier la prochaine étape.
Modèles de processus logiciels-
Cycle de vie en spirale
De façon générale, les risques liés au
développement de logiciels peuvent être
répartis en quatre catégories :
1)les risques commerciaux (placement du
produit sur le marché, concurrence);
2)les risques financiers (capacités financières
suffisantes pour réaliser le produit);
3)les risques techniques (la technologie
employée est-elle ´éprouvée ?) ;
4)les risques de développement (l’équipe est-
elle suffisamment expérimentée ?).
Modèles de processus logiciels-
Prototypage
Le prototypage permet de contourner la
difficulté de la validation liée à l’imprécision
des besoins et caractéristiques du système
à développer.
Cela veut dire que lorsqu’il est difficile
d’établir une spécification détaillée, on a
recours au prototypage qui est considéré,
dans ce cas, comme un modèle de
développement de logiciels.
Modèles de processus logiciels-
Prototypage
Nous distinguons deux types de
prototypage :
1)Le prototypage Jetable : ici, le squelette
du logiciel n’est créé que dans un but et
dans une phase particulière du
développement.
2)Le prototypage Evolutif : ici, on conserve
tout, au long du cycle de développement. Il
est amélioré et complété pour obtenir le
logiciel final.
Modèles de processus logiciels-
Prototypage
Modèles de processus logiciels-
Ingénierie orientée réutilisation
Dans la majorité des projets logiciels, il y a
une certaine réutilisation des logiciels.
Cela se produit souvent de manière
informelle lorsque les personnes travaillant
sur le projet connaissent des conceptions ou
du code similaires à ce qui est requis.
Ils les recherchent, les modifient au besoin
et les intègrent dans leur système.
Cette réutilisation informelle a lieu quel que
soit le processus de développement utilisé.
Modèles de processus logiciels-
Ingénierie orientée réutilisation
Les approches orientées réutilisation
reposent sur une large base de composants
logiciels réutilisables et un cadre
d'intégration pour la composition de ces
composants.
Parfois, ces composants sont des systèmes
à part entière qui peuvent fournir des
fonctionnalités spécifiques telles que le
traitement de texte ou un tableur.
Modèles de processus logiciels-
Ingénierie orientée réutilisation
les étapes intermédiaires d'un processus
orienté réutilisation sont :
1. Analyse des composants Compte tenu de la
spécification des exigences, une recherche
est effectuée pour les composants pour
mettre en œuvre cette spécification.
2. Modification des exigences Au cours de
cette étape, les exigences sont analysées à
l'aide d'informations sur les composants qui
ont été découverts. Ils sont ensuite modifiés
pour refléter les composants disponibles.
Modèles de processus logiciels-
Ingénierie orientée réutilisation
3. Conception du système avec réutilisation
Au cours de cette phase, le cadre du
système est conçu ou un cadre existant est
réutilisé.
4. Développement et intégration Le logiciel
qui ne peut pas être acheté à l'extérieur est
développé, et les composants et les
systèmes commerciaux sont intégrés pour
créer le nouveau système. L'intégration du
système, dans ce modèle, peut faire partie
du processus de développement.
Modèles de processus logiciels-
Ingénierie orientée réutilisation
Modèles de processus logiciels-
Ingénierie orientée réutilisation
Il existe trois types de composants logiciels
pouvant être utilisés dans ce processus :
1. Services Web développés conformément
aux normes de service et disponibles pour
un appel à distance.
2. Collections d'objets développés sous
forme de package à intégrer à un
framework de composants tel que .NET ou
J2EE.
3. Systèmes logiciels autonomes configurés
pour être utilisés dans un environnement
particulier.
Modèles de processus logiciels-
Ingénierie orientée réutilisation
L'ingénierie logicielle orientée vers la
réutilisation présente l'avantage évident de
réduire la quantité de logiciels à développer
et donc de réduire les coûts et les risques.
Cela conduit généralement aussi à une
livraison plus rapide du logiciel.
Modélisation du système
La modélisation du système est le
processus de développement de modèles
abstraits d'un système, chaque modèle
présentant une vue ou une perspective
différente de ce système.
Elle peut signifier la représentation du
système à l'aide d'une sorte de notation
graphique, presque toujours basée sur les
notations du langage de modélisation unifié
(UML).
Modélisation du système
Un modèle est une abstraction du système
étudié plutôt qu'une représentation
alternative de ce système.
Idéalement, une représentation d'un
système devrait conserver toutes les
informations sur l'entité représentée.
Une abstraction simplifie délibérément et
sélectionne les caractéristiques les plus
saillantes.
Modélisation du système
Développer différents modèles pour représenter le
système sous différents angles. Par exemple:
1. Une perspective externe, où vous modélisez le
contexte ou l'environnement du système.
2. Une perspective d'interaction dans laquelle vous
modélisez les interactions entre un système et son
environnement ou entre les composants d'un système.
3. Une perspective structurelle, où vous modélisez
l'organisation d'un système ou la structure des données
qui sont traitées par le système.
4. Une perspective comportementale, où vous
modélisez le comportement dynamique du système et
comment il réagit aux événements.
Modélisation du système-
Modèles de contexte
Les modèles de contexte montrent
normalement que l'environnement
comprend plusieurs autres systèmes
automatisés.
Cependant, ils ne montrent pas les types de
relations entre les 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.
Modélisation du système-
Modèles de contexte
Ils peuvent partager des données avec le
système, ou ils peuvent être connectés
directement, via un réseau ou ne pas être
connectés du tout. Ils peuvent être
physiquement co-localisés ou situés dans
des bâtiments séparés.
Toutes ces relations peuvent affecter les
exigences et la conception du système en
cours de définition et doivent être prises en
compte.
Modélisation du système-
Modèles de contexte
À un stade précoce de la spécification d'un
système, vous devez décider des limites du
système. Cela implique de travailler avec les
parties prenantes du système pour décider:
Quelles fonctionnalités doivent être incluses
dans le système et ce qui est fourni par
l'environnement du système.
La prise en charge automatisée de certains
processus métier doit être mise en œuvre, mais
que d'autres doivent être des processus manuels
ou pris en charge par différents systèmes.
Modélisation du système-
Modèles de contexte
Avec les systèmes existants, décider où les
nouvelles fonctionnalités doivent être mises
en œuvre.
Ces décisions doivent être prises au début
du processus pour limiter les coûts du
système et le temps nécessaire pour
comprendre les exigences et la conception
du système.
Modélisation du système-
Modèles de contexte
La figure suivante est un modèle de
contexte simple qui montre le système
d'information du patient et les autres
systèmes dans son environnement.
Modélisation du système-
Modèles de contexte
La figure suivante est un modèle d'un
processus système important qui montre les
processus dans lesquels le MHC-PMS est
utilisé.
Parfois, les patients qui souffrent de
problèmes de santé mentale peuvent être
un danger pour les autres ou pour eux-
mêmes. Ils peuvent donc devoir être
détenus contre leur gré dans un hôpital afin
qu'un traitement puisse leur être
administré.
Modélisation du système-
Modèles de contexte
Modélisation du système-
Modèles de contexte
La figure 4.4 est un diagramme d'activité
UML.
Les diagrammes d'activités sont destinés à
montrer les activités qui composent un
processus système et le flux de contrôle
d'une activité à une autre.
Le début d'un processus est indiqué par un
cercle plein ; la fin par un cercle plein à
l'intérieur d'un autre cercle. Les rectangles
aux coins arrondis représentent les activités,
c'est-à-dire les sous-processus spécifiques qui
doivent être exécutés. Vous pouvez inclure
des objets dans les tableaux d'activités.
Modélisation du système-
Modèles de contexte
Les flèches représentent le flux de travail
d'une activité à une autre. Une barre pleine
est utilisée pour indiquer la coordination de
l'activité. Lorsque le flux de plus d'une
activité mène à une barre pleine, toutes ces
activités doivent être terminées avant que
la progression ne soit possible. Lorsque le
flux d'une barre pleine conduit à un certain
nombre d'activités, celles-ci peuvent être
exécutées en parallèle.
Modélisation du système-
Modèles de contexte
Les flèches peuvent être annotées avec des
gardes qui indiquent la condition lorsque ce
flux est pris.
Modélisation du système-
Modèles d'interaction
Tous les systèmes impliquent une
interaction quelconque. Cela peut être une
interaction utilisateur, qui implique des
entrées et des sorties utilisateur, une
interaction entre le système en cours de
développement et d'autres systèmes ou une
interaction entre les composants du
système.
La modélisation de l'interaction utilisateur
est importante car elle permet d'identifier
les besoins des utilisateurs.
Modélisation du système-
Modèles d'interaction
La modélisation de l'interaction système à
système met en évidence les problèmes de
communication qui peuvent survenir.
La modélisation de l'interaction des
composants nous aide à comprendre si une
structure de système proposée est
susceptible de fournir les performances et
la fiabilité requises du système.
Modélisation du système-
Modèles d'interaction
Dans cette section, deux approches liées à la
modélisation des interactions :
1. La modélisation des cas d'utilisation, qui
est principalement utilisée pour modéliser les
interactions entre un système et des acteurs
externes (utilisateurs ou autres systèmes).
2. Les diagrammes de séquence, qui sont
utilisés pour modéliser les interactions entre
les composants du système, bien que des
agents externes puissent également être
inclus.
Modélisation du système-
Modèles d'interaction
(1) Modélisation des cas d'utilisation
Chaque cas d'utilisation représente une
tâche discrète qui implique une interaction
externe avec un système.
Dans sa forme la plus simple, un cas
d'utilisation est représenté sous la forme
d'une ellipse avec les acteurs impliqués
dans le cas d'utilisation représentés sous
forme de bonhommes allumettes.
Modélisation du système-
Modèles d'interaction
La figure montre un cas d'utilisation du
MHC-PMS qui représente la tâche de
téléchargement des données du MHC-PMS
vers un système de dossier patient. Ce
système conserve des données sur un
patient.
Modélisation du système-
Modèles d'interaction
Notez qu'il y a deux acteurs dans ce cas
d'utilisation : l'opérateur qui transfère les
données et le système de dossier patient.
Formellement, les diagrammes de cas
d'utilisation doivent utiliser des lignes sans
flèches, car les flèches dans l'UML indiquent
la direction du flux des messages.
Évidemment, dans un cas d'utilisation, les
messages passent dans les deux sens.
Modélisation du système-
Modèles d'interaction
Les diagrammes de cas d'utilisation
donnent un aperçu assez simple d'une
interaction, vous devez donc fournir plus de
détails pour comprendre ce qui est
impliqué.
Ce détail peut être une simple description
textuelle, une description structurée dans
un tableau ou un diagramme de séquence
comme indiqué ci-dessous.
Modélisation du système-
Modèles d'interaction
Modélisation du système-
Modèles d'interaction
(2) Diagrammes de séquence
Les diagrammes de séquence dans l'UML
sont principalement utilisés pour modéliser
les interactions entre les acteurs et les
objets dans un système et les interactions
entre les objets eux-mêmes.
Modélisation du système-
Modèles d'interaction
Les objets et les acteurs impliqués sont
répertoriés en haut du diagramme, avec
une ligne pointillée tracée verticalement à
partir de ceux-ci.
Les interactions entre les objets sont
indiquées par des flèches annotées. Le
rectangle sur les lignes pointillées indique la
ligne de vie de l'objet concerné (c'est-à-dire
le temps pendant lequel cette instance
d'objet est impliquée dans le calcul).
Modélisation du système-
Modèles d'interaction
Vous lisez la séquence des interactions de
haut en bas. Les annotations sur les flèches
indiquent les appels aux objets, leurs
paramètres et les valeurs de retour.
Dans cet exemple, je montre également la
notation utilisée pour désigner les
alternatives. Une case nommée alt est
utilisée avec les conditions indiquées entre
crochets.
Modélisation du système-
Modèles d'interaction
Modélisation du système-
Modèles d'interaction
Vous pouvez lire la figure 5.6 comme suit :
1. Le réceptionniste médical déclenche la
méthode ViewInfo dans une instance P de la
classe d'objets PatientInfo, fournissant
l'identifiant du patient, PID. P est un objet
d'interface utilisateur, qui s'affiche sous la
forme d'un formulaire affichant des
informations sur le patient.
Modélisation du système-
Modèles d'interaction
2. L'instance P appelle la base de données
pour retourner les informations requises, en
fournissant l'identifiant du réceptionniste
pour permettre le contrôle de sécurité (à ce
stade, on ne se soucie pas d'où vient cet
UID).
3. La base de données vérifie avec un
système d'autorisation que l'utilisateur est
autorisé pour cette action.
Modélisation du système-
Modèles d'interaction
4. En cas d'autorisation, les informations du
patient sont renvoyées et un formulaire sur
l'écran de l'utilisateur est rempli. Si
l'autorisation échoue, un message d'erreur
est renvoyé.
Modélisation du système-
Modèles structurels
Les modèles structurels de logiciels
affichent l'organisation d'un système en
termes de composants qui le composent et
de leurs relations.
Les modèles structurels peuvent être des
modèles statiques, qui montrent la structure
de la conception du système, ou des
modèles dynamiques, qui montrent
l'organisation du système lors de son
exécution.
Modélisation du système-
Modèles structurels
(1) Diagrammes de classes
Les diagrammes de classes sont utilisés lors
du développement d'un modèle de système
orienté objet pour montrer les classes d'un
système et les associations entre ces
classes.
Une classe d'objets peut être considérée
comme une définition générale d'un type
d'objet système.
Une association est un lien entre des
classes qui indique qu'il existe une relation
entre ces classes.
Modélisation du système-
Modèles structurels
Lorsque vous développez des modèles
pendant les premières étapes du processus
de génie logiciel, les objets représentent
quelque chose dans le monde réel, comme
un patient, une ordonnance, un médecin,
etc.
Les diagrammes de classes dans l'UML
peuvent être exprimés en detail à différents
niveaux.
Modélisation du système-
Modèles structurels
La première étape consiste à regarder le
monde, à identifier les objets essentiels et à
les représenter sous forme de classes.
Notez aussi l'existence d'une association en
traçant une ligne entre les classes.
Par exemple, la figure 5.8 est un diagramme
de classes simple montrant deux classes :
Patient et Dossier patient avec une
association entre elles.
Modélisation du système-
Modèles structurels
Dans cet exemple, chaque extrémité de
l'association est annotée d'un 1, ce qui
signifie qu'il existe une relation 1:1 entre les
objets de ces classes.
Modélisation du système-
Modèles structurels
Vous pouvez définir qu'un nombre exact
d'objets sont impliqués ou, en utilisant un *,
comme le montre la figure suivante, qu'il y
a un nombre indéfini d'objets impliqués
dans l'association.
La figure développe ce type de diagramme
de classes pour montrer que les objets de la
classe Patient sont également impliqués
dans des relations avec un certain nombre
d'autres classes.
Modélisation du système-
Modèles structurels
Modélisation du système-
Modèles structurels
Lorsque l'on montre les associations entre
les classes, il est pratique de représenter
ces classes de la manière la plus simple
possible.
Pour les définir plus en détail, ajoutez des
informations sur leurs attributs (les
caractéristiques d'un objet) et leurs
opérations (les choses que vous pouvez
demander à un objet).
Modélisation du système-
Modèles structurels
Par exemple, un objet Patient aura l'attribut
Adresse et vous pouvez inclure une
opération appelée ChangeAddress, qui est
appelée lorsqu'un patient indique qu'il est
passé d'une adresse à une autre.
Dans l'UML, vous affichez les attributs et les
opérations en étendant le simple rectangle
qui représente une classe.
Modélisation du système-
Modèles structurels
Ceci est illustré à la Figure 5.10 où :
1. Le nom de la classe d'objets se trouve
dans la section supérieure.
2. Les attributs de classe se trouvent dans
la section du milieu. Cela doit inclure les
noms d'attributs et, éventuellement, leurs
types.
3. Les opérations (appelées méthodes en
Java et autres langages de programmation
OO) associées à la classe d'objets se
trouvent dans la partie inférieure du
rectangle.
Modélisation du système-
Modèles structurels
(2) Généralisation
La généralisation est une technique
quotidienne que nous utilisons pour gérer la
complexité.
Plutôt que d'apprendre les caractéristiques
détaillées de chaque entité que nous
expérimentons, plaçons ces entités dans
des classes plus générales (animaux,
voitures, maisons, etc.) et apprenons les
caractéristiques de ces classes.
Modélisation du système-
Modèles structurels
Cela nous permet de déduire que différents
membres de ces classes ont des
caractéristiques communes (par exemple,
les écureuils et les rats sont des rongeurs).
Dans les systèmes de modélisation, il est
souvent utile d'examiner les classes d'un
système pour voir s'il existe des possibilités
de généralisation. Cela signifie que les
informations communes seront conservées
à un seul endroit.
Modélisation du système-
Modèles structurels
Dans les langages orientés objet, tels que
Java, la généralisation est implémentée à
l'aide des mécanismes d'héritage de classe
intégrés au langage.
L'UML a un type spécifique d'association
pour désigner la généralisation, comme
illustré à la figure suivante. La
généralisation est représentée par une
pointe de flèche pointant vers la classe la
plus générale.
Modélisation du système-
Modèles structurels
Modélisation du système-
Modèles structurels
Dans une généralisation, les attributs et
opérations associés aux classes de niveau
supérieur sont également associés aux
classes de niveau inférieur.
Les classes de niveau inférieur sont des
sous-classes qui héritent des attributs et
des opérations de leurs superclasses.
Ces classes de niveau inférieur ajoutent
ensuite des attributs et des opérations plus
spécifiques.
Modélisation du système-
Modèles structurels
Modélisation du système-
Modèles structurels
Par exemple, tous les médecins ont un nom
et un numéro de téléphone ; tous les
médecins hospitaliers ont un matricule et
un service mais les médecins généralistes
n'ont pas ces qualités car ils travaillent de
manière autonome. Ils ont cependant un
nom et une adresse de pratique.
Modélisation du système-
Modèles structurels
(3) Agrégation
Les objets du monde réel sont souvent
composés de différentes parties. Par
exemple, un dossier d'étude pour un cours
peut être composé d'un livre, de
diapositives PowerPoint, de quiz et de
recommandations pour une lecture plus
approfondie.
Modélisation du système-
Modèles structurels
L'UML fournit un type spécial d'association
entre les classes appelé agrégation qui
signifie qu'un objet (le tout) est composé
d'autres objets (les parties). Pour montrer
cela, nous utilisons une forme de losange à
côté de la classe qui représente le tout.
Modélisation du système-
Modèles comportementaux
Les modèles comportementaux sont des
modèles du comportement dynamique du
système lors de son exécution.
Ils montrent ce qui se passe ou ce qui est
censé se passer lorsqu'un système répond à
un stimulus de son environnement.
Modélisation du système-
Modèles comportementaux
Considérer ces stimuli comme étant de
deux types :
1. Données Certaines données arrivent et
doivent être traitées par le système.
2. Événements Un événement se produit, et
ensuite déclenche le traitement du
système. Les événements peuvent avoir
des données associées mais ce n'est pas
toujours le cas.
Modélisation du système-
Modèles comportementaux
De nombreux systèmes d'entreprise sont
des systèmes de traitement de données qui
sont principalement pilotés par les données.
Ils sont contrôlés par les données entrées
dans le système avec relativement peu de
traitement d'événements externes.
Par exemple, un système de facturation
téléphonique acceptera des informations
sur les appels passés par un client,
calculera les coûts de ces appels et
générera une facture à envoyer à ce client.
Modélisation du système-
Modèles comportementaux
Par exemple, un système de commutation
téléphonique fixe répond à des événements
tels que « récepteur décroché » en
générant une tonalité, ou l'appui sur les
touches d'un combiné en capturant le
numéro de téléphone, etc.
Modélisation du système-
Modèles comportementaux
(1) Modélisation basée sur les données
Les modèles basés sur les données
montrent la séquence des actions
impliquées dans le traitement des données
d'entrée et la génération d'une sortie
associée.
Ils sont particulièrement utiles lors de
l'analyse des besoins car ils peuvent être
utilisés pour montrer le traitement de bout
en bout dans un système.
Modélisation du système-
Modèles comportementaux
Par exemple, la figure suivante montre la
chaîne de traitement impliquée dans le
logiciel de la pompe à insuline. Dans ce
diagramme, vous pouvez voir les étapes de
traitement (représentées comme des
activités) et les données circulant entre ces
étapes (représentées comme des objets).
Modélisation du système-
Modèles comportementaux
Modélisation du système-
Modèles comportementaux
Une autre façon de montrer la séquence de
traitement dans un système consiste à
utiliser des diagrammes de séquence UML.
Vous avez vu comment ils peuvent être
utilisés pour modéliser l'interaction, mais si
vous les dessinez de manière à ce que les
messages ne soient envoyés que de gauche
à droite, ils montrent le traitement
séquentiel des données dans le système.
Modélisation du système-
Modèles comportementaux
La figure suivante illustre ce modele, en
utilisant un modèle de séquence du
traitement d'une commande et de son envoi
à un fournisseur.
Modélisation du système-
Modèles comportementaux
Les modèles de séquence mettent en
évidence les objets d'un système, tandis
que les diagrammes de flux de données
mettent en évidence les fonctions.
Modélisation du système-
Modèles comportementaux
(2) Modélisation événementielle
La modélisation événementielle montre
comment un système réagit aux événements
externes et internes. Il est basé sur
l'hypothèse qu'un système a un nombre fini
d'états et que des événements (stimuli)
peuvent provoquer une transition d'un état à
un autre.
Par exemple, un système contrôlant une
vanne peut passer d'un état « Vanne
ouverte » à un état « Vanne fermée »
lorsqu'une commande de l'opérateur (le
stimulus) est reçue.
Modélisation du système-
Modèles comportementaux
L'UML prend en charge la modélisation
événementielle à l'aide de diagrammes
d'états.
Les diagrammes d'état montrent les états du
système et les événements qui provoquent
des transitions d'un état à un autre.
Ils ne montrent pas le flux de données au
sein du système mais peuvent inclure des
informations supplémentaires sur les calculs
effectués dans chaque état.
Modélisation du système-
Modèles comportementaux
Prenons l’exemple de logiciel de contrôle pour
un four à micro-ondes pour illustrer la
modélisation événementielle. Ce four a un
interrupteur pour sélectionner la pleine ou la
moitié de la puissance, un clavier numérique
pour entrer le temps de cuisson, un bouton
marche/arrêt et un affichage alphanumérique.
Modélisation du système-
Modèles comportementaux
La séquence d'actions lors de l'utilisation du
micro-ondes est :
1. Sélectionnez le niveau de puissance (soit à
mi-puissance, soit à pleine puissance).
2. Saisissez le temps de cuisson à l'aide d'un
clavier numérique.
3. Appuyez sur Start et la nourriture est cuite
pendant le temps donné.
Modélisation du système-
Modèles comportementaux
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 dispose d'un affichage
alphanumérique qui permet d'afficher
diverses alertes et messages
d'avertissement.
Dans les diagrammes d'état UML, les
rectangles arrondis représentent les états
du système. Ils peuvent inclure une brève
description des mesures prises dans cet
état.
Modélisation du système-
Modèles comportementaux
Les flèches étiquetées représentent des
stimuli qui forcent une transition d'un état à
un autre. Vous pouvez indiquer les états de
début et de fin à l'aide de cercles pleins,
comme dans les diagrammes d'activités.
Modélisation du système-
Modèles comportementaux
Modélisation du système-
Ingénierie dirigée par les modèles
L'ingénierie dirigée par les modèles (MDE,
Model-driven engineering) est une approche
du développement de logiciels où les
modèles plutôt que les programmes sont les
principaux résultats du processus de
développement.
MDE s'intéresse à tous les aspects du
processus d'ingénierie logicielle.
Modélisation du système-
Ingénierie dirigée par les modèles
(1) Architecture pilotée par modèle
L'architecture dirigée par les modèles est
une approche centrée sur les modèles pour
la conception et la mise en œuvre de
logiciels qui utilise un sous-ensemble de
modèles UML pour décrire un système.
Modélisation du système-
Ingénierie dirigée par les modèles
La méthode MDA ( Model-driven
architecture) recommande de produire trois
types de modèle de système abstrait :
1. Un modèle indépendant du calcul (CIM,
computation independent model) qui
modélise les abstractions de domaine
importantes utilisées dans le système. Les
CIM sont parfois appelés modèles de
domaine. Par exemple, il peut y avoir un
CIM de sécurité dans lequel vous identifiez
des abstractions de sécurité importantes.
Modélisation du système-
Ingénierie dirigée par les modèles
2. Un modèle indépendant de la plate-forme
(PIM, Platform independent model) qui
modélise le fonctionnement du système
sans référence à son implementation. Le
PIM est généralement décrit à l'aide de
modèles UML qui montrent la structure
statique du système et comment il réagit
aux événements externes et internes.
Modélisation du système-
Ingénierie dirigée par les modèles
3. Modèles spécifiques à la plate-forme
(PSM, Platform specific models) qui sont des
transformations du modèle indépendant de
la plate-forme avec un PSM distinct pour
chaque plate-forme d'application. Ainsi, le
PSM de premier niveau pourrait être
spécifique au middleware mais indépendant
de la base de données. Lorsqu'une base de
données spécifique a été choisie, un PSM
spécifique à la base de données peut alors
être généré.
Modélisation du système-
Ingénierie dirigée par les modèles
Ceci est illustré à la figure suivante, qui
montre également un niveau final de
transformation automatique. Une
transformation est appliquée au PSM pour
générer du code exécutable qui s'exécute
sur la plate-forme logicielle désignée.
Modélisation du système-
Ingénierie dirigée par les modèles
Modélisation du système-
Ingénierie dirigée par les modèles
La traduction des PIM vers les PSM est plus
mature et plusieurs outils commerciaux
sont disponibles qui fournissent des
traducteurs des PIM vers des plates-formes
communes telles que Java et J2EE. Ceux-ci
s'appuient sur une bibliothèque complète
de règles et de modèles spécifiques à la
plate-forme pour convertir le PIM en PSM.
Modélisation du système-
Ingénierie dirigée par les modèles
Si un système logiciel est destiné à
fonctionner sur différentes plates-formes
(par exemple, J2EE et .NET), il est alors
seulement nécessaire de maintenir le PIM.
Les PSM pour chaque plate-forme sont
générés automatiquement. Ceci est illustré
à la figure suivante.
Modélisation du système-
Ingénierie dirigée par les modèles