0% ont trouvé ce document utile (0 vote)
22 vues124 pages

Lecture Software Eng Chap 4

Le cours de Génie Logiciel aborde la modélisation des processus de développement logiciel, en présentant divers modèles tels que le modèle en cascade, le développement incrémental, et le cycle de vie en spirale. Chaque modèle a ses propres caractéristiques, avantages et inconvénients, et est utilisé pour planifier et exécuter le développement logiciel en fonction des exigences et des retours des utilisateurs. L'importance de la documentation et de la gestion des risques tout au long du cycle de vie du développement est également soulignée.

Transféré par

pemberoger7
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PPTX, PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
22 vues124 pages

Lecture Software Eng Chap 4

Le cours de Génie Logiciel aborde la modélisation des processus de développement logiciel, en présentant divers modèles tels que le modèle en cascade, le développement incrémental, et le cycle de vie en spirale. Chaque modèle a ses propres caractéristiques, avantages et inconvénients, et est utilisé pour planifier et exécuter le développement logiciel en fonction des exigences et des retours des utilisateurs. L'importance de la documentation et de la gestion des risques tout au long du cycle de vie du développement est également soulignée.

Transféré par

pemberoger7
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PPTX, PDF, TXT ou lisez en ligne sur Scribd

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

Vous aimerez peut-être aussi