1

MODELISATION
DU SYSTÈME D'INFORMATION
 MODELISATION SI
2

 Compétences visées / Objectifs généraux d'apprentissage

 Approfondir la modélisation métier en utilisant un standard du marché
 Savoir modéliser les aspects structurels statiques et dynamiques d’un
Système d’Information (SI): données, traitements, architecture.
 Savoir faire le lien entre les modèles et les codes
 Connaitre ce qu'est une méthode de développement de SI


 Thèmes / mots-clés
 objets métiers, modélisation, UML, processus de développement


 MODELISATION SI
3

 Contenu et formes d'enseignement

 Langages de modélisation unifiée UML
 Modèle des cas d’utilisation
 Structure statique : Diagramme des classes
 Structure dynamique : Diagramme de séquences et de
communication
 Structure dynamique : Diagramme d’états
 Processus de développement des SI, processus unifié
 Cas pratiques
 MODELISATION SI
4

 Bibliographie
 UML 2 par la pratique, Eyrolles, ISBN : 2-212-11480-X
 Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and Iterative Development, Prentice Hall PTR, ISBN : 978-
0131489066
5
 Méthodes – Processus - Langages
6

 Méthodes – Processus - Langages

 Une Méthode de Développement est un Moyen pour réaliser un

artéfact Logiciel;
 Une Méthode de Développement comporte:
Langage de Modélisation
 1 Langage de Modélisation, (Notation )
 1 Processus,
 des Outils supports

Processus Outils
S. KOUSSOUBE
 Méthode – Processus - Langage
7

 Processus de Développement :
 Un processus de développement définit un ensemble
d’étapes à exécuter selon un ordonnancement
permettant d’analyser, et/ou de concevoir, et/ou
d’implémenter des systèmes logiciels
 Un ordonnancement d’étapes peut être en tout ou partie
 séquentiel,
 et/ou parallèle
 et/ou itératif.

S. KOUSSOUBE
 Méthode – Processus - Langage
8
 Modélisation, Langage de Modélisation
 Le développement d’un système logiciel industriel nécessite
la création de plusieurs modèles;
 Modèle : Un modèle est une Vue abstraite (Simplifiée) d’un
système, d’un problème. Un modèle décrit le système par
rapport à un point de vue spécifique et à un certain niveau
d’abstraction. Les modèles permettent :
 de gérer la complexité;
 d'assurer une cohérence architecturale
 de faciliter la communication entre les membres du Projet.
 Un système complexe s’appréhende mieux à travers un petit
ensemble de vues indépendantes.
 Chaque modèle peut être représenté à différents niveaux de
fidélité doit être conforme à la réalité;
 Les modèles sont définis en utilisant un langage de
S. KOUSSOUBE
modélisation
 Méthode – Processus - Langage
9

 Modélisation, Langage de Modélisation

 Un langage de modélisation rigoureux comporte:
 des éléments de modélisation : les concepts de modélisation
fondamentaux et leur sémantique ;
 Une Notation : le rendu visuel des éléments de modélisation ;
 Des directives : des idiomes pour le bon usage du langage.

 Exemple:
 Méthodes: Merise, (2TUP couplé à UML), …
 Processus: Processus de Merise; Processus 2TUP; …
 Outils: AmcDesignor; Rational Rose; …

S. KOUSSOUBE
10
 UML en Bref
11

 UML (Unified Modelling Language)

 UML est un langage de modélisation visuel
 UML sert à :
 spécifier,
 visualiser,
 construire,
 et documenter les éléments d’un système logiciel.
 UML est le langage de modélisation le plus utilisé pour
construire les systèmes Orientés Objets
 Il a fusionné les Concepts de trois méthodes Phares : OMT,
BOOCH et OOSE
 Il est Standardisé par l’OMG (adoption en 1997;
http://www.omg.org/) S. KOUSSOUBE
 UML en Bref
12

Booch Rumbaug Jacobson

h Meyer
(pré-post
conditions)
Odell
(classificatio
n)
Harel
Shlaer-Mellor UML (State
(Cycle de vie des charts)
objets)

Wirfs-Brock
Gamma et al (responsabilité
(Framework, patterns, s)
Fusion
notes)
(descriptionS.
desKOUSSOUBE
opérations)
13

S. KOUSSOUBE
 UML en Bref
14

 Contenu de UML :

 La Sémantique UML

 Le Guide Notation UML

 Des Profils :
 Processus de Développement,
 Modélisation Métier,…

 Object Constraint Language (OCL)

S. KOUSSOUBE
 UML en Bref
15
 Éléments Basiques de UML :
 Éléments de Modélisation:
 classes, interfaces, cas d’utilisation, etc.

 Relations :
 association, généralisation, dépendances, etc.

 Diagrammes
 diagramme des cas d’utilisation, des classes, d’interaction,
etc.)

S. KOUSSOUBE
 UML en Bref
16

Statique Comportemental
e
Classes Activités
Objets Séquence
Packages Communication
Analyse &
Structure Global d’Interaction
Conception composite Temps
États/Transitions

Implémentatio Composants
n Déploiement
 UML en Bref
17

 Les Diagrammes UML

 Le diagramme de classe.
 Montre les classes du système avec leurs attributs et
méthodes ainsi que les relations et dépendances

 Le diagramme d’objets.
 Montre des graphes d’instances (objets) qui peuvent exister
pendant l’exécution du système. Sert à Illustrer des
structures de classes compliquées.

 Les diagrammes de Package.

 Organisent les éléments de modélisation en groupes avec
pour objectif de rendre les diagrammes plus simples et plus
faciles à comprendre.

S. KOUSSOUBE
 UML en Bref
18

 Les diagrammes UML

 Les diagrammes de Structure Composite
 Explorent les instances des classes collaborant à travers des
liens de communications.
 Les diagrammes de cas d’utilisation
 Montrent les utilisateurs et leurs interactions avec le
système. Structurent les fonctionnalités offertes par le
système.
 Les diagrammes de séquence.
 Montrent des exemples d’historique de communication entre
les objets ou les utilisateurs.
 Les diagrammes de Communication (collaboration)
 sont une forme spéciale de diagramme d’objets enrichis avec
des informations sur le flot S.
des messages entre objets et sur
KOUSSOUBE
la création/destruction des objets.
 UML en Bref
19

 Les diagrammes UML

 Diagramme Global d’Interaction (Overview
Interaction)
 Une variante du diagramme d’activité qui donne une vue
globale d’un flot de contrôle.

 Diagramme de Temps (Timing Diagram)

 Explore le comportement d’un ou plusieurs objets pendant
une période de temps donnée.

 Les diagrammes d’états des classes

 Utilisés pour modéliser l’état des données et leurs
changements durant le cycle de vie des objets instances des
classes du diagramme de classe.
S. KOUSSOUBE
 UML en Bref
20

 Les diagrammes UML

 Les diagrammes d’activité
 Une forme spéciale de diagramme de transition d’états utilisé
pour modéliser l’état du contrôle

 Les diagrammes des composants.

 Montrent la structure du code et son partitionnement en
composants.

 Les diagrammes de déploiement

 Montrent la structure de l’implémentation en Exécution et la
distribution des objets et composants sur les nœuds
physiques .

S. KOUSSOUBE
21

Mécanismes Généraux
d’Extension.

S. KOUSSOUBE
 Mécanismes d’Extension de UML
22

 Les Mécanismes d’extension de UML sont :

 les Contraintes,
 les Stéréotypes,
 les Étiquettes/propriétés.

 Les Mécanismes d’extension s’appliquent à n’importe quel

élément de modélisation

 Ils permettent de spécialiser et d’étendre un élément de

modélisation avec une nouvelle sémantique

S. KOUSSOUBE
 Mécanismes d’Extension de UML
23


Contrainte:
 Une contrainte est une relation sémantique qui doit être
maintenue entre des éléments de modèle
 Certains types de contraintes sont prédéfinis: {frozen},
{subset}, etc.
 L’utilisateur peut définir de nouvelles contraintes dans
un langage libre ou avec le langage OCL.
 Notation : { contrainte }

S. KOUSSOUBE
 Mécanismes d’Extension de UML
24

 Exemple de Contrainte

Personne est membre

Comité
de

dirig
e

Personne est membre

Comité
de
{subset
}

dirig
e
 Mécanismes d’Extension de UML
25

 Exemple de Contrainte

Il s’agit d’une personnalité morale

employé employeu
Personne Compagnie
r
agen
chef
t

{Peronne.employeur =
Personne.chef.employeur }
 Mécanismes d’Extension de UML
26


Propriétés:
 Une propriété (ou Valeur étiquetée) : est une valeur attachée à
une propriété d’un élément de modélisation.
 C’est une extension des propriétés d’un élément UML qui permet
d’apporter de nouvelles informations de spécification. Une
propriété peut ne pas avoir de notation visuelle.
 l’Utilisateurs peut ainsi définir de nouvelles propriétés en
utilisant le mécanisme d’étiquetage : Paire (Étiquette, Valeur).
Ce mécanisme permet d’alléger les diagrammes des détails
d’implémentation.

S. KOUSSOUBE
 Mécanismes d’Extension de UML
27


Propriétés:
 Exemple
 {estAbstrait = vrai}, {abstrait}
 { auteur = “Jean Bosco”, deadline = 31/10/04, phase =
analyse}

« interface »

Serializable
Document
{serialized}

Document

S. KOUSSOUBE
 Mécanismes d’Extension de UML
28


Stéréotypes:
 Un Stereotype est une nouvelle classe du métamodèle
introduit au moment de la modélisation.
 C’est une sous-classe d’une classe existant dans le méta
modèle avec la même forme mais avec une intention
différente.
 Un élément stéréotypé peut avoir :
 des contraintes additionnelles,
 des étiquettes supplémentaires,
 et éventuellement une notation graphique différente.
 Notation usuelle: mot clé entre guillemets placé au dessus
du nom de l’élément .

S. KOUSSOUBE
 Mécanismes d’Extension de UML
29


Stéréotypes:

« persistent » « control »

Compte CompteManager

S. KOUSSOUBE
30

Modèle des Cas

d’Utilisation

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
31

 Modèle des Cas d’Utilisation :

 Le Modèle des Cas d’Utilisation est une Vue du Système

qui montre le comportement du système tel qu’il est
perçu par les utilisateurs externes.
 Le modèle Partitionne les fonctionnalités du système en
transactions (cas d’utilisation) significatives pour les
utilisateurs.
 Ce modèle sert de Vecteur de communication entre
clients, utilisateurs finals et développeurs sur les
fonctionnalités et comportement du système.

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
32
 Les Concepts:
 Acteur
 Un acteur est un ensemble cohérent de rôles qu’un utilisateur
ou une entité externe peut jouer en interagissant avec le
système
 Un acteur peut consulter et/ou modifier directement l’état du
système

 Un acteur peut être :

 les utilisateurs humains directs; il faut Identifier tous les profils
(administrateur, opérateur, …)
 les autres systèmes connexes qui interagissent directement avec
le système étudié, souvent par le biais de protocoles
bidirectionnels.

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
33
 Les Concepts:

 Acteur (Notation)

« actor »
Opérateur
client

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
34
 Les Concepts:
 Acteur (découverte des Acteurs):
 Qui s’intéresse à tel besoin ?
 Dans quelle partie de l’organisation le système sera utilisé?
 Qui doit profiter de l’utilisation du système?
 Qui va fournir telle information au système?
 Qui utilise, ou supprime telle information?
 Qui va maintenir le système?
 Le système utilise-il une ressource externe?
 Une personne joue t-elle plusieurs rôles?
 Plusieurs personnes jouent-elle le même rôle?
 Le système doit-il interagir avec une ancienne application?
 etc.
S. KOUSSOUBE
 Modèle des Cas d’Utilisation
35

 Les Concepts:
 Cas d’Utilisation:
 Un Cas d’Utilisation est une unité cohérente de fonctionnalité
offerte par le système; Il modélise un service rendu par le
système.

 La description d’un cas d’utilisation comprend :

 La séquence de messages échangés entre le système et des
agents externes aux systèmes (acteurs);
 l'ensemble des actions réalisées par le système

 Notation
<nom> Ouvrir un
Compte

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
36

 Les Concepts:
 Cas d’Utilisation:
 Quel niveau de détail dans un Cas d’Utilisation?
 Un Cas d’utilisation: une séquence de transactions
réalisées par le système et qui a un résultat significatif et
mesurable pour un acteur particulier.
 Un Cas d’Utilisation représente une unité majeure de
fonctionnalité qui est complète.
 Un cas d’utilisation est constitué de plusieurs scénarii
(déroulement particuliers):
 Un scenario nominal (déroulement normal);

 Des scenarii alternatifs (déroulements alternatifs )

 Des scenarii d’exception (se terminant en « queue

de poisson » )

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
37

 Les Concepts:
 Cas d’Utilisation:
 Questions à poser:
 Quelles sont les tâches de chaque acteur ?
 Tel acteur va-t-il créer, stocker, modifier ou supprimer des
informations dans le système?
 Quel cas d’utilisation va créer, stocker, modifier ou supprimer des
informations dans le système?
 Un certain acteur doit-il informer le système des changements
externes?
 Le système doit-il informer un certain acteur des changements
internes?
 Quels cas d’utilisations doivent maintenir le système?
 Tous les besoins fonctionnels sont-ils pris en compte par les cas
d’utilisation?
S. KOUSSOUBE
 Modèle des Cas d’Utilisation
38

 Les Relations:

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
39

Agent

Chef
Service

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
40

« acteur »

A SYSCOMPTA
Agent

Chef
Service

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
41

« acteur »

A SYSCOMPTA
Agent

Chef D E
Service

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
42

« acteur »

A SYSCOMPTA
Agent «include
»
B F

Chef D E
Service

S. KOUSSOUBE
 Modèle des Cas d’Utilisation

43

« acteur »

A SYSCOMPTA
Agent «include
»
B F

«extend G
s»
Chef D E
Service

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
44
 Relations des Acteurs
 Généralisation. Une généralisation de A vers B : l’acteur A est une
spécialisation de l’acteur B.
 une instance de A peut communiquer avec les mêmes C.U. que les instance
de B.
 Association(Communication) : Participation d’un acteur à un CU

 Relations des Cas d’Utilisation

 Association(Communication) : Participation d’un acteur à un C.U.
La navigation (si elle existe) indique qui de l’acteur ou du C.U. initie la
communication
 Extend. A étend B : une instance de B peut être augmentée (sous
certaines conditions spécifiques) par le comportement de A.
 Include. A inclut B : une instance de A contient le comportement
spécifié par B.
S. KOUSSOUBE
 Généralisation. Une généralisation de A vers B: A est une
spécialisation de B.
 Modèle des Cas d’Utilisation
45

 Diagramme des Cas d’Utilisation

 Un diagramme des cas d’utilisation est une vue
graphique de tout ou partie des acteurs, des cas
d’utilisations et de leurs interactions.
 On produit, en pratique, plusieurs diagrammes de cas
d’utilisation plus ou moins détaillés:
 DCU principal: montre les acteurs et les principales
fonctionnalités du système.
 Des DCU particuliers (par acteur, un CU et ses relations etc.)

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
46

 Documentation des Cas d’Utilisation

 Description Textuelle
 Sommaire d’Identification (obligatoire) :
 titre du CU, acteurs, date de création etc.
 Description des Enchaînements (obligatoire) :
 scénarii nominaux, alternatifs, d’exception

 Besoins en IHM (Optionnel)

 Contraintes non fonctionnelles (optionnel) :
 fréquence, volumétrie, disponibilité, fiabilité, intégrité,
confidentialité, performance
 Pré/Post Conditions

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
47

 Documentation des Cas d’Utilisation

 diagramme d’activité du C.U.
 Le diagramme d’activité décrit l’ensemble de l’activité
réalisée par le CU
 C’est un graphe constitué d’activités, d’actions et de
transitions. Ce graphe contient les branchements
conditionnels et toutes les boucles possibles.

 Diagramme de Séquence Système.

 Une forme particulière de diagramme de séquence
comprenant le système (vue comme une boite noire) et les
différents acteurs participants.

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
48 Documentation des Cas d’Utilisation

Cas
d’Utilisation

S. KOUSSOUBE
49

Cas
d’Utilisation
Texte

S. KOUSSOUBE
50

Cas activité activité

d’Utilisation
Texte
activité

S. KOUSSOUBE
51

Cas activité activité

d’Utilisation
Texte
activité

Syst
Scénario

S. KOUSSOUBE
 Modèle des Cas d’Utilisation
52

 Etapes du processus unifié où l'on

construit le modèle des cas d'utilisation:

 Dans uns processus unifié, le développement du
modèle des cas d’utilisation
 commence à l’étape de Pré étude (« Inception »)
 et affiné et complété lors de l’étape d’Élaboration.

S. KOUSSOUBE
53