Cours de CSI Bac 2 Informatique

i
REPUBLIQUE DEMOCRATIQUE DU CONGO

ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
INSTITUT SUPERIEUR PEDAGOGIQUE ET TECHNIQUE DE LIKASI
Ass. Ir. Landry

MBAY KANYIMBU
Contact : +243 997631729
Email : landrymbaykanyimbu@gmail.com
2023
ii
Département D’Electronique-Informatique Industrielle
UE : Conception des Systèmes Informatiques
Code UE : INF201
Semestre : Premier Semestre
Nombre de Crédits : 3
Horaire : du Mardi 25/04 au Mercredi 03/05/2023 dans les installations de l’ISPT/Likasi.
Préalables
- Labo 1
- Informatique Général
Ressources
- Support du cours ;
- Ordinateur ;
- Projecteur ;
- AGL (Modelio).
iii
Objectifs du cours
a. Objectif Général
Cette Unité d’Enseignement intitulée Conception de Systèmes
Informatiques vise à fournir à l’étudiant(e) des connaissances sur des méthodes
et concepts fondamentaux de l’analyse, de la conception et de la réalisation de
systèmes informatiques.
b. Objectifs Spécifiques
A l’issu de ce cours, tout étudiant qui aura suivi avec succès ces enseignements
sera capable:
- De comprendre et d’utiliser les concepts de l’approche orientée objet ;
- D’analyser le domaine d'étude pour comprendre les besoins et les
formaliser en utilisant les diagrammes correspondants ;
- De concevoir le système pour déterminer les mécanismes de traitement de
l’information par les opérations informatisables de la solution à
développer;
- De définir l’architecture de la future solution pour son implémentation;
- De comprendre et représenter (modéliser) un concept du système
d’information ;
- D’analyser et de concevoir un système d’information par le processus
unifié (UP) associé au langage de modélisation UML et SysML.
Approches Pédagogiques
Les approches suivantes seront utilisées pour l’enseignement de

cours :
- Cours Magistral Interactif ;
- Utilisation Pédagogique des TIC ;
- Exposés Individuels et/ou de groupe ;
iv
- La pédagogie inversée.
Aspect d’Evaluation et Réglementaire
- Il est prévu un TD à chaque chapitre pour 20 % de Toute l’Evaluation;

- A la fin du cours, nous prévoyons un travail pratique en groupe pour 30 %
de toute l’Evaluation;
- Et un examen écrit à la fin du semestre pour 50 % de toute l’Evaluation.
Règles de Bonne Conduite :

- Il est obligatoire de respecter l’heure d’arriver ;
- Tous les téléphones doivent être sous mode vibreur ou silencier
- Tout le monde doit s’habiller d’une manière descente et être propre c’est-
à-dire présentable ;
- Lorsqu’on a une question, veuillez lever votre main pour garder l’attitude
sereine de l’auditoire.
5
PLAN DU COURS
CHAPITRE I CONSIDERATIONS THEORIQUES
I. INTRODUTION
II. DEFINITION DES CONCEPTS
SYSTEME
SYSTEME D’INFORAMTION
CONCEPTION
MODELE
LANGAGE DE MODELISATION
III. CONCEPTS DE L’APPROCHE OBJET
OBJET
CLASSE
ENCAPSULATION
ASSOCIATION ET AGGREGATION
GENERALISATION ET SPECIALISATION
IV. PRESENTATION D’UML
BREVE HISTORIQUE
PRESENTATION GENERAL DES DIAGRAMMES
CHAPITRE II CONCEPTION STATIQUE ET DYNAMIQUE D’UN SI(UML)
I. LES DIAGRAMMES STATIQUES (CONCEPTION STATIQUE)
LE DIAGRAMME DE CLASSES
LE DIAGRAMME DE COMPOSANTS
LE DIAGRAMME DE DEPLOIEMENT
II. LES DIAGRAMMES COMPORTEMENTAUX (CONCEPTION

DYNAMIQUE)
Ass. Ir. Landry MBAY KANYIMBU

6
LE DIAGRAMME DE CAS D’UTILISATION
LE DIAGRAMME D’ACTIVITES
LE DIAGRAMME DE SEQUENCE
CHAPITRE III INTRODUCTION AU LANGAGE SYSML
CONSIDERATIONS THEORIQUES
DESCRIPTION FONCTIONNELLE
DESCRIPTION STRUCTURELLE
CHAPITRE IV APPROCHE UP (PROCESSUS UNIFIE)
PRESENTATION D’UP
LES PRINCIPES D’UP
PHASES ET ITERATION DU PROCESSUS
ACTIVITES DU PROCESSUS

7
CHAPITRE I CONSIDERATIONS THEORIQUES

I. INTRODUCTION
Un logiciel est un produit (manufacturé c’est-à-dire fabriqué) :
 Comme une voiture ou une machine à outils qui nécessité
qu’on détermine :
 un processus de développement ;
 Déterminer les besoins ;
 Plan ou architecture du système ;
 Conception du système ;
 Réalisation du système
Ainsi, pour développer un logiciel ou une application
professionnelle, une démarche de conception doit être mise en œuvre,
comme nous l’oblige les méthodologies de développement logiciel. La
conception de logiciel met en œuvre un ensemble d'activités qui, à partir
d'une demande d'informatisation d'un processus (demande qui peut aller de
la simple question orale jusqu'au cahier des charges complet) permettent
l’analyse, la conception, l'écriture et la mise au point d'un logiciel (et donc de
programmes informatiques) jusqu'à sa livraison au demandeur.
En règle générale, la fabrication d'un logiciel va suivre trois
grandes phases :
 Phase d'analyse (fonctionnelle) ou de conception
Durant cette phase, on effectue simultanément l'étude des données et
l'étude des traitements à effectuer. C'est en général dans cette phase
que s'appliquent les techniques de modélisation. Il en découle la
description des bases de données éventuelles à créer et les
programmes à écrire et la manière dont tout cela va être intégré.
o Spécification
o Conception
o Définition de l'architecture
 Phase de réalisation ou de programmation (écriture et tests des
programmes)
o Algorithmique

8
o Programmation
o Gestion des versions
o Factorisation
o Tests unitaires
o Optimisation du code
 Phase de livraison
o Intégration
o Validation
o Documentation du logiciel
o Packaging
o formation
NB :
Dans ce cours c’est la première phase (Analyse/Conception que
nous allons approfondir pour voir dans quelle mesure, nous allons atteindre
nos objectifs.
II. DEFINITION DES CONCEPTS
a. SYSTEME
Un système peut à la fois être qualifié de solaire, technique ou
d’équations en fonction de son domaine d’application. Dans tous les cas, le
terme fait référence à un objet complexe, logique et ordonné. A l’image de
son étymologie (du grec systêma signifiant un assemblage ou une
combinaison), la norme ISO/IEC 15288 : 2002 propose la définition
suivante.
« Unsystème est un arrangement d’éléments en interaction, organisés en vue

de répondre à un besoin des Hommes ».
Plusieurs interprétations découlent de cette définition :
- Un système est un ensemble ;
- Cet ensemble peut être décrit à partir d’éléments ;
- Les éléments de cet ensemble sont en relation et en interaction ;
- Ce système est une finalité exprimée.

9
Afin de faciliter l’étude d’un système complexe, ce dernier pourra

être décomposé en sous-systèmes plus simple. Ces derniers pourront, à leur
tour, être considérés comme un système composé d’autres sous-systèmes.
Cette décomposition pourra être faite jusqu’aux composants élémentaires.
b. SYSTEME D’INFORMATION
Plusieurs définitions existent pour un système d’information.
Nous pouvons noter celles qui suivent :
- Le système information, appelé aussi d’une manière large
système informatique, (noté SI) représente l'ensemble des logiciels
et matériels participant à la récolte, au stockage, au traitement,
au transport et à la diffusion de l'information au sein de
l'organisation.
- Un système d’information peut être défini techniquement comme

un ensemble de composants interdépendants qui collectent,
traitent, stockent et distribuent des informations pour soutenir la
prise de décision et le contrôle dans une organisation.
Comme vous pouvez le constater, ces définitions privilégient deux
approches différentes pour décrire les systèmes d’information : les
composants qui constituent un système d’information et le rôle que ces
composants jouent dans une organisation.
1. LES COMPOSANTS DES SYSTEMES D’INFORMATION

Les systèmes d’information peuvent être considérés comme ayant cinq
composants principaux : le matériel, les logiciels, les données, les
personnes et les processus. Les trois premiers sont technologiques.
Les deux derniers composants les personnes et les processus, séparent
l’idée de systèmes d’information des domaines plus techniques, tels
que l’informatique. Une question nécessitent d’être posée « de quelle

10
manière ces composants fonctionnent pour apporter de la valeur à une

organisation.
a. Les Composants Technologiques

La technologie peut être considérée comme l’application des
connaissances scientifiques à des fins pratiques. De l’invention de la
roue à l’exploitation de l’électricité pour l’éclairage artificiel, la
technologie est devenue omniprésente dans la vie quotidienne, au
point que l’on suppose qu’elle est toujours disponible, quel que soit le
lieu. Dans la définition précédente nous avons dit que les trois
premiers composants étaient technologiques.
- Matériel
Le matériel est la partie tangible et physique d’un système
d’information. C’est une partie que vous pouvez toucher. Il regroupe :
les ordinateurs, les claviers et lecteurs de disques, les câbles de
connections et autres équipements réseaux.
- Logiciel
Le logiciel comprend l’ensemble d’instructions qui indiquent au
matériel ce qu’il doit faire. Le logiciel n’est pas tangible. Il ne peut pas
être touché. Les programmeurs créent des logiciels en tapant une sérié
d’instructions indiquant au matériel ce qu’il doit faire. Deux catégories
principales de logiciel sont à signaler ici, le logiciel des systèmes
d’exploitation pour un ordinateur (windows, ubuntu, Google Android,
IOS) ; ainsi que le logiciels d’applications permettant à un utilisateur
de réaliser des tâches ou des opérations professionnelles telles que
l’enregistrement de données dans une feuille de calcul ou la capture
d’une image.
- Donnée
Comme les logiciels, les données sont intangibles c’est-à-dire qu’elles
sont incapables d’être vues à leur état natif. Des morceaux de données

11
sans rapport entre elles ne pas très utile. Mais agrégées, indexées et
organisées ensemble dans un fichier, elles deviennent un outil
puissant pour les entreprises. C’est ainsi que les organisations
collectent toutes sortes de données et les utilisent pour prendre des
décisions (orientations) qui peuvent ensuite être analysées quant à
leur efficacité.
b. Communication en Réseau
Outre les composants technologiques (matériel, logiciel et donnée) qui
ont été longtemps considérés comme la technologie de base des
systèmes d’information, il a été suggéré d’ajouter un autre composant :
la communication. Un système d’information peut exister sans pouvoir
communiquer (le cas des premiers ordinateurs personnels qui étaient
des machines autonomes qui n’accédaient pas à Internet).
Cependant, dans le monde hyper-connecté d’aujourd’hui, c’est
extrêmement rare de trouver un ordinateur qui ne se connecte pas à
un autre appareil ou à un réseau. Techniquement, l’élément
communication en réseau est composé de matériels et de logiciels,
mais c’est une caractéristique tellement essentielle des systèmes
d’informations actuels qu’il est devenu une catégorie à part entière.
c. Personne
Les personnes constituent un panel des personnes qui interviennent
dans la construction, l’usage et la maintenance du système
d’information. Nous trouvons notamment, les personnels d’assistance
pour les utilisateurs (Help Desk), les utilisateurs de première ligne, les
analystes d’affaires, les développeurs jusqu’au directeur des systèmes
d’information (DSI), les personnes impliquées dans les systèmes
d’information constituent un élément essentiel de ces derniers.

12
d. Processus
Un processus est une série d’étapes entreprises pour atteindre un
résultat ou un objectif souhaité. Les systèmes d’information sont de
plus en plus intégrés aux processus organisationnels, apportant une
plus grande productivité et un meilleur contrôle de ces processus.
2. LE SYSTME INFORMATIQUE
Un système informatique est constitué de ressources matérielles et
logicielles organisées pour collecter, stocker, traiter et communiquer
les informations. Les ressources humaines nécessaires à son
fonctionnement (par exemple les administrateurs) sont parfois incluses
dans ce périmètre.
Le système informatique ne doit pas être conçu comme une fin en soi :
il est l’un des outils qui permet à l’organisation d’atteindre ses
objectifs. Il ne se justifie que tant qu’il soutient des processus « métier
», sans lesquels il n’a aucun sens. Il doit donc être aligné avec les
objectifs stratégiques de l’organisation. Cet alignement stratégique est
fondamental : désormais, un système informatique est un facteur
déterminant de la performance (efficacité, efficience, maîtrise des
risques) d’une organisation. Inversement, un système informatique
inadapté ou mal maîtrisé peut être une source inépuisable de
difficultés.
c. LA CONCEPTION
Est un processus créatif qui consiste à représenter les diverses
fonctions du système d’information afin d’obtenir rapidement un ou
plusieurs programmes réalisant ses fonctions. Cette technique est aussi
connue sous le contexte de la « Modélisation ».
La modélisation est la conception d'un modèle. D’une manière
simple, on définit aussi la modélisation comme un mécanisme consistant à
comprendre une idée et de la représenter par des modèles du langage de

13
modélisation. Selon son objectif et les moyens utilisés, la modélisation est

dite mathématique, géométrique, 3D, empirique, mécanique (ex :
modélisation de réseau trophique dans un écosystème), cinématique... Elle
nécessite généralement d'être calée par des observations ou mesures faites
lesquelles servent aussi à paramétrer, calibrer ou ajuster le « modèle », par
exemple en intégrant des facteurs d'influences qui s'avèreraient nécessaires.
La Conception Orientée Objet (COO) quant à elle, est la démarche
qui conduit à la conception des architectures logicielles fondées sur les
objets.
Ces différentes représentations sont considérées comme étant des
modèles ou des diagrammes. Et chaque modèle ou diagramme représente un
aspect bien particulier d’un système à développer.
d. LE MODELE
Un modèle est une représentation simplifiée d’une réalité sur
laquelle on veut être renseigné (Ex : Un plan, une carte, un schéma,
électronique,…). Un modèle s’exprime avec un ensemble de concepts, dotés
de règles d’utilisation et de représentation (souvent graphiques).
Les modèles servent à :
- Communiquer : Vérifier que l’analyste a bien compris les
utilisateurs (phase d’analyse) ;
- Préparer la réalisation : Grâce à un modèle de la solution (Phase de
conception).
Un modèle est une représentation abstraite de la réalité qui exclut
certains détails du monde réel. Il permet de réduire la complexité d'un
phénomène en éliminant les détails qui n'influencent pas son comportement
de manière significative. Il reflète ce que le concepteur croit important pour
la compréhension et la prédiction du phénomène modélisé, les limites du
phénomène modélisé dépendent des objectifs du modèle.

14
e. LANGAGE DE MODELISATION
Un langage de modélisation est un langage artificiel qui peut être
utilisé pour exprimer de l'information ou de la connaissance ou des systèmes
dans une structure qui est définie par un ensemble cohérent de règles. Les
règles sont utilisées pour l'interprétation de la signification des composants
dans la structure.
Un langage de modélisation peut être graphique ou textuel.
- Les langages de modélisation graphiques utilisent des techniques de
diagrammes avec des symboles associés à des noms qui représentent
les concepts et des lignes qui connectent les symboles et qui
représentent les relations et les diverses autres annotations
graphiques pour représenter les contraintes.
- Les langages de modélisation textuels utilisent typiquement des mots-
clés standardisés accompagnés de paramètres pour rendre les
expressions interprétables par les ordinateurs.
REMARQUE
Un langage de modélisation doit définir :

- La sémantique des concepts ;
- Une notation pour la représentation de concepts ;
- Des règles de construction et d'utilisation des concepts.
L'industrie du logiciel dispose de nombreux langages de

modélisation :
- Adaptés aux systèmes procéduraux (MERISE...) ;
- Adaptés aux systèmes temps réel (ROOM, SADT...) ;
- Adaptés aux systèmes à objets (OMT, Booch, UML...).
Dans la pratique de la modélisation, il existe deux grands types de
modélisation qui oriente les concepteurs dans leur travail de modélisation
des systèmes entre autre :
- Modélisation Ascendante et
- Modélisation Objet

15
1. Modélisation par Décomposition Fonctionnelle

Ici nous trouvons l’Approche descendante qui permet de
décomposer la fonction globale jusqu'à obtenir des fonctions simples à
appréhender et donc à programmer.

16
III. CONCEPTS DE L’APPROCHE OBJET

Aujourd’hui l’approche objet occupe une place prépondérante dans
le génie logiciel. En effet, ces dernières années nous avons assisté tout
d’abord à une utilisation plus large des langages de programmation objet de
référence comme C++, C# et Java et ensuite à l’introduction des concepts
objet dans d’autres langages comme par exemple VB.NET, Perl et même
Cobol. Le développement très important d’applications liées à Internet
constitue une des principales explications de ce phénomène sans précédent
alors que l’on aurait pu s’attendre à un démarrage plus précoce de ce
changement compte tenu de l’existence dès le début des années 80 des
premiers langages objet tel que C++.
À notre avis les deux événements majeurs qui ont marqué cette
évolution se sont produits à la fin des années 90 avec l’arrivée de Java en
1995 et d’UML en 1997.
Notre objectif dans cette section est donc de présenter l’essentiel
des concepts objet qui nous paraissent nécessaires à une bonne
compréhension d’UML. Les concepts qui nous semblent importants à bien
maîtriser sont les suivants :
- objet et classe,
- encapsulation et interface,
- association et agrégation de classes,
- généralisation et spécialisation de classe,
- polymorphisme,
- persistance.
A. OBJET ET CLASSE
1. Objet
Un objet représente un exemplaire utilisable d’une entité du
monde réel (ou du monde virtuel pour les objets immatériels), qui se
caractérise par un ensemble de propriétés (attributs), des états significatifs

17
et un comportement. D’autres auteurs définissent l’objet comme étant une

instance de la classe.
L’état d’un objet correspond aux valeurs de tous ses attributs à un
instant donné. Les propriétés sont définies dans la classe d’appartenance de
l’objet. Le comportement d’un objet est caractérisé par l’ensemble des
opérations qu’il peut exécuter en réaction aux messages provenant des
autres objets. Les opérations sont définies dans la classe d’appartenance de
l’objet.
Exemple.
Considérons l’étudiante BENEDICT, Code BKM0001, Genre
Féminin, Promotion L1, évoluant dans le département d’Eq-Info.
Cet objet est caractérisé par la liste de ses attributs et son état est
représenté par les valeurs de ses attributs :
- Code : BKM0001
- Nom : Benedict
- Genre : Féminin
- Promotion : L2
- Departement : Eq-Info
Son comportement est caractérisé par les opérations qu’il peut

exécuter. Dans notre cas, nous pouvons avoir les opérations suivantes :
- S’Inscrire
- Passer Un Examen
- Suivre Un Cours
- Changer de Département
2. Classe
Une classe est l’abstraction d’un ensemble d’objets qui possèdent
une structure identique (liste des attributs) et un même comportement (liste
des opérations). C’est ainsi qu’on définit aussi un objet comme étant une
instance d’une et une classe. En d’autres termes, nous pouvons définir la

18
classe comme étant un ensemble d’objets ayant les mêmes propriétés (aspect
structurel) et les mêmes méthodes (aspect comportemental).
Exemple :
Considérons la classe Etudiant qui représente tous les étudiants
d’une Université. La description de la classe Etudiant comportera les
éléments suivants :
 Nom Classe : Etudiant ;
 Attributs :
o Code
o Nom
o Genre
o Promotion
o Departement
 Opérations :
o Inscrire Etudiant
o Enseigner Etudiant
o Délibérer Etudiant
o Modifier Etudiant
Exemple des Etudiants…
B. ENCAPSULATION ET INTERFACE
Par rapport à l’approche classique, l’approche objet se caractérise
par le regroupement dans une même classe de la description de la structure
des attributs et de la description des opérations. Ce regroupement des deux
descriptions porte le nom d’encapsulation données-traitements.
Plus précisément, les données ne sont accessibles qu’à partir
d’opérations définies dans la classe. Le principe d’encapsulation renforce
l’autonomie et l’indépendance de chaque classe et donne une potentialité
accrue de définition de classe réutilisable. L’ensemble des opérations d’une
classe rendue visible aux autres classes porte le nom d’interface.

19
CLASSE N
TREAITEMENTS
INTERFACE
1. Opérations Accessibles DONNEES :
Accès aux
données
- Opération 1
via l’interface - Opération 2 Liste des
(partie visible - Opération 3 Attributs
de la classe)
- Opération n
2. Opérations Non Accessibles

- Opération A
- Opération B
- Opération n
C. ASSOCIATION ET AGREGATION ENTRE CLASSE
1. Association
L’association représente une relation entre plusieurs classes. Elle
correspond à l’abstraction des liens qui existent entre les objets dans le
monde réel. Les multiplicités (ou cardinalités en MERISE) et les rôles des
objets participant aux relations complètent la description d’une association.
Les exemples d’associations sont donnés directement dans les diagrammes
de classe d’UML.
2. Agrégation
L’agrégation est une forme particulière d’association entre
plusieurs classes. Elle exprime le fait qu’une classe est composée d’une ou
plusieurs autres classes. La relation composant-composé ou la relation
structurelle représentant l’organigramme d’une entreprise sont des exemples
types de la relation d’agrégation.

20
D. GENERALISATION ET SPECIALISATION
1. Généralisation
La généralisation de classes consiste à factoriser dans une classe,
appelée super classe, les attributs et/ou opérations des classes considérées.
Appliquée à l’ensemble des classes, elle permet de réaliser une hiérarchie des
classes. Il s’agit de l’opération qui consiste à construire une classe mère
appelée (super classe) à partir d’autres classes filles dites sous-classe.
A titre d’exemple, la relation qui existe entre la classe telle que
« Personne » et la classe telle que « Etudiant ». On peut se permettre de dire
que tous les étudiants sont des personnes, mais toute personne n’est pas
étudiant ; dans ce sens Etudiant n’est qu’un cas particulier d’une personne.
2. La Spécialisation
La spécialisation représente la démarche inverse de la
généralisation puisqu’elle consiste à créer à partir d’une classe, plusieurs
classes spécialisées. Chaque nouvelle classe créée est dite spécialisée puis
qu’elle comporte en plus des attributs ou opérations de la super-classe
(disponibles par héritage) des attributs ou opérations qui lui sont propres.
Une classe spécialisée porte aussi le nom de sous-classe. La
spécialisation de classe se construit en deux temps : d’abord par héritage
des opérations et des attributs d’une super-classe et ensuite par ajout
d’opérations et/ou d’attributs spécifiques à la sous-classe.
La généralisation-spécialisation est un des mécanismes les plus
importants de l’approche objet qui facilite la réutilisation des classes.
E. LE POLYMORPHISME
Le polymorphisme est la capacité donnée à une même opération
de s’exécuter différemment suivant le contexte de la classe où elle se trouve.
Ainsi, une opération définie dans une super-classe peut s’exécuter de
manière différente selon la sous-classe où elle est héritée.

21
En fait lors de l’exécution, l’appel de l’opération va

automatiquement déclencher l’exécution de l’opération de la sous-classe
concernée. Dans le déroulement de l’exécution de l’opération de la sous-
classe, il est possible de faire appel à l’opération de la super-classe qui
contient en général la partie commune applicable aux deux sous-classes.
Exemple.
Considérons une classe Employé ayant la structure suivante :
 Nom Classe : Employé
 Attributs :
o Code
o Nom
o Genre
o Salaire de base
 Opération
o calculSalaire ()
Soit les sous classes suivantes :

 Nom de la Sous Classe : Cadre
o Attribut : Niveau d’encadrement
o Opération : calculSalaire ()
 Nom de la Sous Classe : Non Cadre

o Attribut : Niveau de Spécialisation
o Opération : calculSalaire ()
Le principe de calcul du salaire étant de calculer pour chaque type

d’employé une prime spécifique en fonction soit du niveau d’encadrement,
soit du niveau de spécialisation selon le type d’employé.
Voyons maintenant comment se réalise l’application du
polymorphisme lors de l’exécution des opérations. Dans cet exemple, lorsque
l’on appelle l’opération calculSalaire( ), c’est l’opération de sous-classe Cadre

22
ou celle de la sous-classe NonCadre qui est en fait activée selon l’objet

concerné.
L’opération de la sous-classe fait en général appel explicitement à
l’opération calculSalaire() de la super-classe pour bénéficier des traitements
communs aux cadres et non cadres et ensuite il y aura poursuite du
traitement spécifique à la sous-classe.
F. LA PERSISTANCE
La persistance est la propriété donnée à un objet de continuer à
exister après la fin de l’exécution du programme qui l’a créé. Par défaut dans
l’approche objet, aucun objet n’est persistant. Les modèles décrivent le
système en exécution en mémoire centrale et ne tiennent pas compte apriori
de l’état du système qui doit être stocké sur disque.
La gestion de la mémoire incombe au programmeur avec
notamment le problème de la libération des espaces.
I. PRESENTATION GENERAL D’UML
A. BREVE HISTORIQUE
Regardons tout d’abord ce qui s’est passé au début des années 90.
Par rapport à la cinquantaine de méthodes d’analyse et de conception objet
qui existaient au début des années 90, seulement trois d’entre elles se sont
détachées nettement au bout de quelques années.
En effet, la volonté de converger vers une méthode unifiée était déjà
bien réelle et c’est pour cette raison que les méthodes OMT, BOOCH et
OOSE se sont démarquées des autres. OMT (Object Modeling Technique) de
James Rumbaugh et BOOCH de Grady Booch ont été les deux méthodes les
plus diffusées en France durant les années 90. Par ailleurs, OOSE de Ivar
Jacobson s’est aussi imposée dans le monde objet pour la partie
formalisation des besoins.
Pour aller plus loin dans le rapprochement, James Rumbaugh et
Grady Booch se sont retrouvés au sein de la société Rational Software et ont

23
été ensuite rejoints par Ivar Jacobson en se donnant comme objectif de

fusionner leur méthode et créer UML (Unified Modeling Language).Il est
important de noter que contrairement à ce qui avait été envisagé au départ,
le processus de développement a été sorti du champ couvert par le projet de
norme.
UML est donc une norme du langage de modélisation objet qui a
été publiée, dans sa première version, en novembre 1997 par l’OMG (Object
Management Group), instance de normalisation internationale du domaine de
l’objet.
En quelques années, UML s’est imposée comme standard à utiliser
en tant que langage de modélisation objet. Aujourd’hui, en cette fin de la
première décennie des années 2000, nous avons déjà une dizaine d’années
de recul sur l’enseignement et la pratique d’UML en entreprise.
B. PRESENTATION GENERALE DES DIAGRAMMES

UML dans sa version 2 propose treize diagrammes qui peuvent être
utilisés dans la description d’un système. Ces diagrammes sont regroupés
dans deux grands ensembles.
1. Les diagrammes structurels

Ces diagrammes sont au nombre de six, ont vocation à représenter
l’aspect statique d’un système (classes, objets, composants…). C’est
pourquoi on les appels aussi les diagrammes statiques.
a. Diagramme de classe
Ce diagramme représente la description statique du système en
intégrant dans chaque classe la partie dédiée aux données et celle consacrée
aux traitements. C’est le diagramme pivot de l’ensemble de la modélisation
d’un système.

24
b. Diagramme d’objet
Le diagramme d’objet permet la représentation d’instances des
classes et des liens entre instances.
c. Diagramme de composant
Ce diagramme représente les différents constituants du logiciel au
niveau de l’implémentation d’un système.
d. Diagramme de déploiement
Ce diagramme décrit l’architecture technique d’un système avec
une vue centrée sur la répartition des composants dans la configuration
d’exploitation.
e. Diagramme de paquetage
Ce diagramme donne une vue d’ensemble du système structuré en
paquetage. Chaque paquetage représente un ensemble homogène d’éléments
du système (classes, composants…).
f. Diagramme de structure composite

Ce diagramme permet de décrire la structure interne d’un
ensemble complexe composé par exemple de classes ou d’objets et de
composants techniques. Ce diagramme met aussi l’accent sur les liens entre
les sous-ensembles qui collaborent.
2. Les diagrammes de comportement

Ces diagrammes représentent la partie dynamique d’un système
réagissant aux événements et permettant de produire les résultats attendus
par les utilisateurs. Sept diagrammes sont proposés par UML :
a. Diagramme des cas d’utilisation

Ce diagramme est destiné à représenter les besoins des utilisateurs
par rapport au système. Il constitue un des diagrammes les plus
structurants dans l’analyse d’un système.

25
b. Diagramme d’état-transition
Ce diagramme montre les différents états des objets en réaction
aux événements.
c. Diagramme d’activités
Ce diagramme donne une vision des enchaînements des activités
propres à une opération ou à un cas d’utilisation. Il permet aussi de
représenter les flots de contrôle et les flots de données.
d. Diagramme de séquence
Ce diagramme permet de décrire les scénarios de chaque cas
d’utilisation en mettant l’accent sur la chronologie des opérations en
interaction avec les objets.
e. Diagramme de communication (anciennement appelé collaboration)

Ce diagramme est une autre représentation des scénarios des cas
d’utilisation qui met plus l’accent sur les objets et les messages échangés.
f. Diagramme global d’interaction

Ce diagramme fournit une vue générale des interactions décrites
dans le diagramme de séquence et des flots de contrôle décrits dans le
diagramme d’activités.
g. Diagramme de temps (nouveau dans UML 2)

Ce diagramme permet de représenter les états et les interactions
d’objets dans un contexte où le temps une forte influence sur le
comportement du système à gérer.
Dans le développement d’un système d’information par l’approche

objet, tous les diagrammes ne sont obligatoirement utilisés dans la
démarche. Sur ce, n’ayant pas assez de temps, nous allons entrer dans le vif
pour les diagrammes les plus importants.

26
CHAPITRE II LES DIAGRAMMES STRUCTURELS (STATIQUES)
I. DIAGRAMME DE CLASSE (DCL)
a. INTRODUCTION
Le diagramme de classe constitue l’un des pivots essentiels de la
modélisation avec UML. En effet, ce diagramme permet de donner la
représentation statique du système à développer. Cette représentation est
centrée sur les concepts de classe et d’association. Chaque classe se décrit
par les données et les traitements dont elle est responsable pour elle-même
et vis-à-vis des autres classes. Les traitements sont matérialisés par des
opérations. Le détail des traitements n’est pas représenté directement dans
le diagramme de classe ; seul l’algorithme général et le pseudo-code
correspondant peuvent être associés à la modélisation.
La description du diagramme de classe est fondée sur :
• le concept d’objet,
• le concept de classe comprenant les attributs et les opérations,
• les différents types d’association entre classes.
b. OBJET
Nous allons donner une première définition du concept d’objet
avant de traiter le concept de classe. La description d’un objet sera
complétée simultanément à la présentation du concept de classe.
Un objet est un concept, une abstraction ou une chose qui a un
sens dans le contexte du système à modéliser. Chaque objet a une identité et
peut être distingué des autres sans considérer a priori les valeurs de ses
propriétés.
Il existe deux types d’objets ; les objets physiques et les objets de
gestion.

27
Exemple :
La figure ci-dessous montre des exemples d’objets physiques (une
chaise, une voiture, une personne, un vélo) et d’objets de gestion (la
Commande n° 12, le Client Durand).
c. CLASSE, ATTRIBUT ET OPERATION
1. Classe
Une classe décrit un groupe d’objets ayant les mêmes propriétés
(attributs), un même comportement (opérations), et une sémantique
commune (domaine de définition).
Un objet est une instance d’une classe. La classe représente
l’abstraction de ses objets. Au niveau de l’implémentation, c’est-à-dire au
cours de l’exécution d’un programme, l’identificateur d’un objet correspond
une adresse mémoire.
Formalisme général et exemple

Une classe se représente à l’aide d’un rectangle comportant
plusieurs compartiments. Les trois compartiments de base sont :
 La désignation de la classe,
 La description des attributs,

28
 La description des opérations.
Deux autres compartiments peuvent être aussi indiqués :

 La description des responsabilités de la classe,
 La description des exceptions traitées par la classe.
Il est possible de manipuler les classes en limitant le niveau de

description à un nombre réduit de compartiments selon les objectifs
poursuivis par le modélisateur.
Ainsi les situations suivantes sont possibles pour la manipulation
d’une description restreinte de classe :
 Description uniquement du nom et des caractéristiques générales de
la classe,
 Description du nom de la classe et de la liste d’attributs.
D’une manière générale, on utilise une représentation de trois

compartiments de base.
Nom de Classe
Attributs
Ou bien
Opérations
Nom Classe
Attributs
Opérations

29
2. Attribut
Un attribut est une propriété élémentaire d’une classe. Il s’agit
d’un type d’information à stocker dans une classe. Pour chaque objet d’une
classe, l’attribut prend une valeur.
Formalisme et Exemple
Nom de la classe Employé
Nom et Caractéristique Attribut1
Matricule : texte
Nom et Caractéristique Attribut2
N.B :
Un attribut dont la valeur peut être calculée à partir d’autres

attributs de la classe est un attribut dérivé qui se note « /nom de l’attribut
dérivé ».
3. Opération
Une opération est une fonction applicable aux objets d’une classe.
Une opération permet de décrire le comportement d’un objet. Une méthode
est l’implémentation d’une opération.
Formalisme et exemple
Chaque opération est désignée soit seulement par son nom soit par
son nom, sa liste de paramètres et son type de résultat.
Nom Classe
Attribut
Nom et Caractéristique Opération 1
Nom et Caractéristique Opération 2
Exemple1
Voiture
Marque : texte
Rouler(vitesse)

30
Exemple 2
Voiture
Marque : texte
Puissance : entier
Année : entier
/Ancienneté : entier
Rouler ()
Freiner ()
Arrêter ()
Démarrer ()
d. VISIBILITE DES ATTRIBUTS ET OPERATIONS

Chaque attribut ou opération d’une classe peut être de type public,
protégé, privé ou paquetage. Les symboles + (public), # (protégé), - (privé) et ~
(paquetage) sont indiqués devant chaque attribut ou opération pour signifier
le type de visibilité autorisé pour les autres classes.
Les droits associés à chaque niveau de confidentialité sont :
• Public (+) – Attribut ou opération visible par toutes les autres classes
• Protégé (#) – Attribut ou opération visible seulement à l’intérieur de la
package
et pour toutes les sous-classes de la classe.
• Privé (-) – Attribut ou opération seulement visible à l’intérieur de la classe.
• statique (~) – Attribut ou opération ou classe seulement visible à l’intérieur
De la classe et ne peut pas être hérité.
e. ASSOCIATION ET MULTIPLICITES
1. Lien et Association
Un lien est une connexion physique ou conceptuelle entre
instances de classes donc entre objets. Une association décrit un groupe de
liens ayant une même structure et une même sémantique. Un lien est une
instance d’une association. Chaque association peut être identifiée par son
nom.

31
Une association entre classes représente les liens qui existent

entre les instances de ces classes.
La figure suivante donne le formalisme de l’association. Le symbole
(facultatif) indique le sens de lecture de l’association. Dans cette figure est
donné aussi un exemple de représentation d’une association.
Classe A Nom Association Classe B
Personne Posséder Voiture
2. Multiplicités
La multiplicité indique un domaine de valeurs pour préciser le
nombre d’instance d’une classe vis-à-vis d’une autre classe pour une
association donnée. Le domaine de valeurs est décrit selon plusieurs formes
:
 Intervalle fermé – Exemple : 2, 3..15.
 Valeurs exactes – Exemple : 3, 5, 8.
 Valeur indéterminée notée * – Exemple : 1..*.

32
Exemple
Personne Travail Service
Nom Nom Entreprise

1..* 1
Postnom Adresse
3. CLASSE ASSOCIATION
Une classe-association permet de décrire soit des attributs soit
des opérations propres à l’association. Cette classe-association est elle-même
reliée par un trait en pointillé au losange de connexion. Une classe-
association peut être reliée à d’autres classes d’un diagramme de classes.
Personne Travailler Service
Nom NomService
* *
Postnom Adresse
Affectation
DateDebut
DateFin

33
4. AGREGATION ET COMPOSITION
a. Agrégation
L’agrégation est une association qui permet de représenter un lien
de type« ensemble » comprenant des « éléments ». Il s’agit d’une relation entre
une classe représentant le niveau « ensemble » et 1 à n classes de niveau «
éléments ». L’agrégation représente un lien structurel entre une classe et une
ou plusieurs autres classes.
Classe A
Classe B
Exemple :

34
Montre un exemple de relation d’agrégation. Dans cet exemple, nous

avons modélisé le fait qu’un ordinateur comprend une UC, un clavier et un
écran.
b. Composition
La composition est une relation d’agrégation dans laquelle il existe
une contrainte de durée de vie entre la classe « composant » et la ou les
classes « composé ». Autrement dit la suppression de la classe « composé »
implique la suppression de la ou des classes « composant ».
Classe A
Classe B
Exemple.

35
c. Interface
Une classe d’interface permet de décrire la vue externe d’une
classe. La classe d’interface, identifiée par un nom, comporte la liste des
opérations accessibles par les autres classes. Le compartiment des attributs
ne fait pas partie de la description d’une interface. L’interface peut être aussi
matérialisée plus globalement par un petit cercle associé à la classe source.
La classe utilisatrice de l’interface est reliée au symbole de
l’interface par une flèche en pointillé. La classe d’interface est une
spécification et non une classe réelle.
La figure ci-après donne le formalisme, sur un exemple, des deux types de
représentation d’une interface.
Ou bien

36
5. SPECIALISATION ET LA GENERALISATION
La généralisation est la relation entre une classe et deux autres
classes ou plus partageant un sous-ensemble commun d’attributs et/ou
d’opérations. La classe qui est affinée s’appelle super-classe, les classes
affinées s’appellent sous-classes. L’opération qui consiste à créer une super-
classe à partir de classes s’appelle la généralisation. Inversement la
spécialisation consiste à créer des sous classes à partir d’une classe. D’une
manière simple c’est aussi un principe d’héritage que nous trouvons là-
dessus.
Classe A
Sous Classe A1 Sous Classe A2

37
Exemple.
Une classe abstraite est une classe qui n’a pas d’instance directe
mais dont les classes descendantes ont des instances. Dans une relation
d’héritage, la super-classe est par définition une classe abstraite.
Exercice.
Question
Une entreprise nationale de vente d’appareil électroménager
souhaite réaliser une première expérience d’analyse objet avec le langage
UML sur un petit sous ensemble de son SI. Ce sous-ensemble concerne le
suivi des personnels des agences locales implantées dans les régions.
Chaque région est pilotée par une direction régionale qui a en charge un
certain nombre d’agences locales. Une direction régionale est caractérisée
par un code et un libellé.
Chaque agence est caractérisée par un code, un intitulé, une date
de création et une date de fermeture. À une agence sont rattachées une à
plusieurs personnes. Chaque personne est caractérisée par les données :

38
numéro, qualité (M., Mme, Mlle), nom, prénom, date de naissance, date
prévisionnelle d’arrivée, date d’arrivée et date de départ. Il est demandé
d’élaborer le diagramme de classe de ce premier sous-ensemble du SI de
cette entreprise.
Corrigé :
Les trois classes constituant ce système sont évidentes puisque déjà bien
identifiées dans l’énoncé : Direction régionale, Agence et Personnel.
L’association entre Direction régionale et Agence est une agrégation qui
matérialise une relation structurante entre ces classes. La relation entre
Agence et Personnel est une association de un à plusieurs. Les opérations
mentionnées dans chaque classe correspondent aux opérations élémentaires
nécessaires à la gestion du personnel des agences.
Direction Régionale
-Code : texte
-Libelle : texte
+consulter ()
+demande_créer_agence()
+demande_supprimer_agence()
Personnel
1,*
- Code : entier
Agence - nom :texte
- postnom :texte
-code : entier - datenaissance : date
Appartenir
-intitulé : texte -date_arrivee_agence : date
-datecreation : date -date_depart_agence : date
-datefermeture :date 1 1,*
+créer() +créer()
+supprimer() +modifier()
+modifier() +supprimer()
+visualiser() +rechercher()
+rattacher_agence()
+dettacher_agence()

39
Exercice 2
Une école souhaite bien concevoir en partie son système

d’information particulièrement la modélisation des classes pour les
paiements des frais scolaires. Un élève évolue dans une classe appartenant
elle-même à une option et une option est directement liée à une section.
Lorsque celui-ci paie on prend sur lui le montant payé, le nom, prenom,
postnom, motif de paiement, la date de paiement en vue d’éditer le reçu de
paiement.
II. DIAGRAMME DE COMPOSANT

Le diagramme de composant permet de représenter les composants
logiciels d’un système, ainsi que les liens existant entre ces composants. Les
composants logiciels peuvent être de deux origines : soit des composants
métiers propres à une entreprise soit des composants disponibles sur le
marché comme par exemple les composants EJB, CORBA, .NET, WSDL.
A. COMPOSANT
On appel composant, une ressource logicielle permettant de
réaliser une tâche bien spécifique au sein d’un logiciel.
Chaque composant est assimilé à un élément exécutable du
système. Il est caractérisé par :
 un nom ;
 une spécification externe sous forme soit d’une ou plusieurs interfaces
requises, soit d’une ou plusieurs interfaces fournies ;
 un port de connexion.
Le port d’un composant représente le point de connexion entre le
composant et une interface. L’identification d’un port permet d’assurer une
certaine indépendance entre le composant et son environnement extérieur.

40
Formalisme général
Un composant est représenté par un classeur avec le mot-clé «

composant »ou bien par un classeur comportant une icône représentant un
module.
<<composant>>
NomComposant
N.B : Il existe deux façons de représenter un composant.
Deux types de représentation sont disponibles pour modéliser les

composants : une représentation « boîte noire » et une représentation « boîte
blanche ». Pour chaque représentation, plusieurs modélisations des
composants sont proposées.
a. Représentation boite noire

C’est une vue externe du composant qui présente ses interfaces
fournies et requises sans entrer dans le détail de l’implémentation du
composant.
Tout en sachant qu’une interface fournie est une partie logicielle
du composant permettant de réaliser une tâche bien précise. Et l’interface
requise est toute ressource (matérielle, logicielle, humaine) à avoir en pré-
condition avant de réaliser le composant.
Une interface fournie se représente à l’aide d’un trait et d’un petit
cercle et une interface requise à l’aide d’un trait et d’un demi-cercle. Ce sont
les connecteurs d’assemblage.

41
Exemple :
Ce petit exemple montre un composant commande, qui a comme

interfaces fournies GestionCommande et SuiviCommande ; les interfaces
requises sont alors la personne qui passe la commande et le produit qui est
la ressource commandée.
b. Représentation boite blanche.

C’est une vue interne du composant qui décrit son implémentation
à l’aide de classificateurs (classes, autres composants) qui le composent.
Une manière de modéliser un composant avec une représentation
boîte blanche est de décrire sous forme textuelle les interfaces fournies et
requises à l’intérieur d’un compartiment, les classificateurs (classes, autres
composants) dans un autre compartiment, les artefacts (élément logiciel :
jar, war, ear, dll) qui représentent physiquement le composant sur la
mémoire dans un dernier compartiment.
Exemple :

42
La représentation ci-dessus nous montre un composant commande

avec ses interfaces fournies et interfaces requises vues précédemment, les
réalisateurs qui sont les classes detailCommande et LigneCommand enfin
l’artefact commande.jar représentant physiquement notre composant
physiquement le composant sur le disque dur.
c. Port
Le port d’un composant représente le point de connexion entre le
composant et une interface. Il est représenté par un petit carré sur le
composant.
Exemple :
III. DIAGRAMME DE DEPLOIEMENT

Le diagramme de déploiement permet de représenter
l’architecture physique supportant l’exploitation du système. Cette
architecture comprend des nœuds correspondant aux supports physiques
(serveurs, routeurs…) ainsi que la répartition des artefacts logiciels
(bibliothèques, exécutables…) sur ces nœuds. C’est un véritable réseau
constitué de nœuds et de connexions entre ces nœuds qui modélise cette
architecture.
A. NŒUD
Un nœud correspond à une ressource matérielle de traitement sur
laquelle des artefacts seront mis en œuvre pour l’exploitation du système.
Les nœuds peuvent être interconnectés pour former un réseau d’éléments
physiques.
Formalisme
Un nœud ou une instance de nœud se représente par un cube ou
parallélépipède.
<<Devise>>
NomDuNoeud

43
B. ARTEFACT
Un artefact est la spécification d’un élément physique qui est
utilisé ou produit parle processus de développement du logiciel ou par le
déploiement du système. C’est donc un élément concret comme par exemple
: un fichier, un exécutable ou une table d’une base de données.
Un artefact peut être relié à d’autres artefacts par notamment des
liens de dépendance.
Un artefact se représente par un rectangle caractérisé par le mot-
clé« artifact » et/ou une icône particulière dans le coin droit du rectangle.
<<artifact>>
commande.jar
C. REPRESENTATION
Le diagramme de déploiement représente les nœuds de
l’architecture physique ainsi que l’affectation des artefacts sur les nœuds
conformément aux règles de déploiement définies. L’exemple est la suivante :
<<Devise>>
ServeurFacturation
<<artifact>>
Facturation.jar
<<artifact>> <<artifact>>
Facture.mdb Client.mdb

44
Exemple 2.
<<device>>
client
<<artifact>>
Explorateur
<<Devise>>
ClientWeb
<<artifact>>
Facturation.jar
<<Device>>
ServeurBDD
<<artifact>>
Script Sql
Ce deuxième diagramme nous crée un diagramme de déploiement

avec trois nœuds ; le premier nœud est déployé le l’explorateur (navigateur) ,
sur le deuxième nœud est implémenté l’application conçu sous java et le
dernier nœud on y déployé la base de données (les scripts SQL).

45
IV. LES DIAGRAMMES COMPORTEMENTAUX
A. LE DIAGRAMME DE CAS D’UTILISATION
1. PRESENTATION GENERALE ET CONCEPT DE BASE

Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas
des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs
besoins. C'est précisément le rôle des diagrammes de cas d'utilisation qui
permettent de recueillir, d'organiser les besoins, et de recenser les grandes
fonctionnalités d'un système. Il s'agit donc de la première étape UML
d'analyse d'un système.
Un cas d’utilisation est un moyen qui permet de décrire
l’interaction entre les acteurs (utilisateurs du cas) et le système. La
description de l’interaction est réalisée suivant le point de vue de
l’utilisateur. La représentation d’un cas d’utilisation met en jeu trois
concepts : l’acteur, le cas d’utilisation et l’interaction entre l’acteur et le cas
d’utilisation.
2. ACTEUR
Un acteur est un utilisateur type qui a toujours le même
comportement vis-à-vis d’un cas d’utilisation. Ainsi les utilisateurs d’un
système appartiennent à une ou plusieurs classes d’acteurs selon les rôles
qu’ils tiennent par rapport au système.
Une même personne physique peut se comporter en autant
d’acteurs différents que le nombre de rôles qu’elle joue vis-à-vis du système.
C’est ainsi un administrateur du système logiciel peut aussi devenir
utilisateur de cette même messagerie. Il sera considéré, en tant qu’acteur du
système, dans le rôle d’administrateur d’une part et dans celui d’utilisateur
d’autre part.

46
Formalisme :
Un acteur peut se représenter symboliquement par un «
bonhomme » ou stick man et être identifié par son nom.
Nom Acteur
3. CAS D’UTILISATION ET INTERACTION

Un cas d’utilisation correspond à un certain nombre d’actions
que le système devra exécuter en réponse à un besoin d’un acteur. Un cas
d’utilisation doit produire un résultat observable pour un ou plusieurs
acteurs ou parties prenantes du système.
Une interaction permet de décrire les échanges entre un acteur et
un cas d’utilisation.
Formalisme
Un cas d’utilisation se représente par un ovale dans lequel figure
son intitulé. L’interaction entre un acteur et un cas d’utilisation se
représente comme une association.
Interaction
Nom Cas d'Utilisation
Nom Acteur
Chaque cas d’utilisation doit être décrit sous forme textuelle afin
de bien identifier les traitements à réaliser par le système en vue de la
satisfaction du besoin exprimé par l’acteur.
4. REPRESENTATION DU DIAGRAMME DE CAS D’UTILISATION

Tout système peut être décrit par un certain nombre de cas
d’utilisation correspondant aux besoins exprimés par l’ensemble des
utilisateurs. À chaque utilisateur, vu comme acteur, correspondra un certain
nombre de cas d’utilisation du système. L’ensemble de ces cas d’utilisation
se représente sous forme d’un diagramme.

47
N.B : Un cas d’utilisation peut avoir l’acteur principal et l’acteur secondaire,

l’acteur principal est celui qui initie le cas d’utilisation et l’acteur secondaire
est celui qui l’exécute.
Exemple :
Soit le diagramme des cas d’utilisation pour le système de gestion
des commandes.
System
passer commande
client receptionniste
Enregistrer Commande
Valider Commande
gestionnaire
5. RELATION ENTRE CAS D’UTILISATION

Afin d’optimiser la formalisation des besoins en ayant recours
notamment à la réutilisation de cas d’utilisation, trois relations peuvent être
décrites entre cas d’utilisation : une relation d’inclusion (« include »), une
relation d’extension (« extend ») et une relation de généralisation.
a. Relation d’inclusion
Un cas A inclut un cas B si le comportement décrit par le cas A
inclut le comportement du cas B : le cas A dépend de B. Lorsque A est
sollicité, B l'est obligatoirement, comme une partie de A. Cette dépendance
est symbolisée par le stéréotype <<include>>

48
cas d'utilisation A
<<include>>
cas d'utilisation B
System
s'inscrire
etudiant appariteur
<<include>>
paiement des frais
Cet exemple montre que l’étudiant lorsqu’il veut s’inscrire, cela

inclut l’exécution du cas d’utilisation paiement frais.
b. Relation d’Extension
Une relation d’extension d’un cas d’utilisation A par un cas
d’utilisation B signifie qu’une instance de A peut être étendue par le
comportement décrit dans B. Deux caractéristiques sont à noter :
 Le caractère optionnel de l’extension dans le déroulement du cas

d’utilisation standard (A) ;
 La mention explicite du point d’extension dans le cas d’utilisation
standard.
cas d'utilisation B
cas d'utilisation A
<<extend>>

49
Exemple :
accorder rabais
passer commande
si > 200
<<extend>>
Il s’agit dans cet exemple d’étendre le cas d’utilisation passer

commande par l’exécution du cas accorder rabais s’il le client commandait la
marchandise de plus de 200 USD.
c. Relation de Généralisation
Une relation de généralisation de cas d’utilisation peut être définie
conformément au principe de la spécialisation-généralisation déjà présentée
pour les classes.
Cas d'Utilisation A
Cas d'Utilisation C Cas d'utilisation B
Exemple :
Retirer Argent
Retirer En Dollard Retirer en Franc
6. DESCRIPTION TEXTUELLE D’UN CAS D’UTILISATION

À chaque cas d’utilisation doit être associée une description
textuelle des interactions entre l’acteur et le système et les actions que le

50
système doit réaliser en vue de produire les résultats attendus par les
acteurs.
La description textuelle d’un cas d’utilisation est articulée en six points :
 Objectif – Décrire succinctement le contexte et les résultats attendus
du cas d’utilisation.
 Acteurs concernés – Le ou les acteurs concernés par le cas doivent être
identifiés en précisant globalement leur rôle.
 Pré conditions – Si certaines conditions particulières sont requises
avant l’exécution du cas, elles sont à exprimer à ce niveau.
 Post conditions – Par symétrie, si certaines conditions particulières
doivent être réunies après l’exécution du cas, elles sont à exprimer à
ce niveau. Pour notre part, par souci de simplification nous n’avons
pas traité ce point dans les exercices et études de cas présentés.
 Scénario nominal – Il s’agit là du scénario principal qui doit se dérouler
sans incident et qui permet d’aboutir au résultat souhaité.
 Scénarios alternatifs – Les autres scénarios, secondaires ou
correspondants à la résolution d’anomalies, sont à décrire à ce niveau.
Le lien avec le scénario principal se fait à l’aide d’une numérotation
hiérarchisée (1.1a, 1.1b…) rappelant le numéro de l’action concernée.
Exercice 1.
Énoncé
Une bibliothèque universitaire souhaite automatiser sa gestion.
Cette bibliothèque est gérée par un gestionnaire chargé des inscriptions et
des relances des lecteurs quand ceux-ci n’ont pas rendu leurs ouvrages au-
delà du délai autorisé. Les bibliothécaires sont chargés de gérer les
emprunts et la restitution des ouvrages ainsi que l’acquisition de nouveaux
ouvrages.
Il existe trois catégories d’abonné. Tout d’abord les étudiants qui
doivent seulement s’acquitter d’une somme forfaitaire pour une année afin
d’avoir droit à tous les services de la bibliothèque. L’accès à la bibliothèque
est libre pour tous les enseignants.

51
Enfin, il est possible d’autoriser des étudiants d’une autre

université à s’inscrire exceptionnellement comme abonné moyennant le
versement d’une cotisation. Le nombre d’abonné externe est limité chaque
année à environ 10 % des inscrits. Un nouveau service de consultation du
catalogue général des ouvrages doit être mis en place.
Les ouvrages, souvent acquis en plusieurs exemplaires, sont
rangés dans des rayons de la bibliothèque. Chaque exemplaire est repéré par
une référence gérée dans le catalogue et le code du rayon où il est rangé.
Chaque abonné ne peut emprunter plus de trois ouvrages. Le délai
d’emprunt d’un ouvrage est de trois semaines, il peut cependant être
prolongé exceptionnellement à cinq semaines.
Il est demandé d’élaborer le diagramme des cas d’utilisation (DCU).
Dans cet exercice nous avons recensé les cas d’utilisations et les
acteurs suivants :
C.U :
* Inscription à la bibliothèque,
* Consultation du catalogue,
* Emprunt d’ouvrages,
* Restitution d’ouvrages,
* Approvisionnement d’ouvrages,
* Relance emprunteur.
Acteurs :
 étudiant,
 externe,
 enseignant,
 emprunteur,
 gestionnaire,
 bibliothécaire.

52
System
<<include>> paiement frais
S'inscrire
Etudiant
Consultater catalogue
Particulier
gestionnair
Emprunter Livre
emprunteur
Restituer livre
bibliothècaire
Approvisionner livre
Enseignant
Relancer emprunteur
B. LE DIAGRAMME D’ACTIVITES
1. PRESENTATION
Le diagramme d’activité présente un certain nombre de points
communs avec le diagramme d’état-transition puisqu’il concerne le
comportement interne des opérations ou des cas d’utilisation. Cependant le
comportement visé ici s’applique aux flots de contrôle et aux flots de données
propres à un ensemble d’activités et non plus relativement à une seule
classe.
Les concepts permettant de manipuler ou de modéliser un
diagramme d’activités sont les suivants :
Nœud initial (état initial),
Nœud final (état final),
Nœud de fin flot (état de sortie),
Nœud de décision (choix).
Les concepts spécifiques au diagramme d’activité sont :

53
- nœud de bifurcation,
- nœud de jonction,
- nœud de fusion,
- pin d’entrée et de sortie,
- flot d’objet,
- partition.
Voici la description de chaque concept pour le diagramme
d’activités.
a. Action
Une action correspond à un traitement qui modifie l’état du
système. Cette action peut être appréhendée soit à un niveau élémentaire
proche d’une instruction en termes de programmation soit à un niveau plus
global correspondant à une ou plusieurs opérations.
Formalisme et Exemple.
NomAction Saisir Commande
b. Transition
Dès qu’une action est achevée, une transition automatique est
déclenchée vers l’action suivante. Il n’y a donc pas d’événement associé à la
transition.
Formalisme
Transition
Action 1 Action 2
c. Activité
Une activité représente le comportement d’une partie du système
en termes d’actions et de transitions.

54
DemanderInscription EnregistrerCoordonnées
d. Nœud de Bifurcation
Un nœud de bifurcation (fourche) permet à partir d’un flot unique
entrant de créer plusieurs flots concurrents en sortie de la barre de
synchronisation.
reception paiement
Comptabiliser ValiderFacture
L’exemple précède concerne le paiement de frais. Lorsque l’on

perçoit les frais, cela déclenche deux opérations simultanément,
premièrement comptabiliser et deuxièmement valider facture.
e. Nœud de Jonction (synchronisation)

Un nœud de jonction (synchronisation) permet, à partir de
plusieurs flots concurrents en entrée de la synchronisation, de produire un
flot unique sortant. Le nœud de jonction est le symétrique du nœud de
bifurcation.
PrésenterFacture Transmettre Facture

Encaisser

55
Cet exemple permet de faire l’encaissement lorsqu’on va présenter

la facture par le client et lorsqu’on va transmettre la facture par la
facturation.
f. Nœud de Test-décision
Un nœud de test-décision permet de faire un choix entre plusieurs
flots sortants en fonction des conditions de garde de chaque flot. Un nœud
de test-décision n’a qu’un seul flot en entrée. On peut aussi utiliser
seulement deux flots de sortie : le premier correspondant à la condition
vérifiée et l’autre traitant le cas sinon.
Passer Commander
Mettre Commande en Attente stock suffisant

Editer Facture
stock insuffisant
Cet exemple permet de mettre une commande si le stock est

insuffisant et d’éditer la facture lorsque le stock est suffisant.
g. Nœud d’Objet
Un nœud d’objet permet de représenter le flot de données véhiculé
entre les actions.
[Facture] [NomObjet]
h. Partition
UML permet aussi d’organiser la présentation du diagramme
d’activité en couloir d’activités. Chaque couloir correspond à un domaine de
responsabilité d’un certain nombre d’actions. Les flots d’objets sont aussi

56
représentés dans le diagramme. L’ordre relatif des couloirs de responsabilité

n’est pas significatif.
Client Service Commercial Service Production
Demander produit Enregistrer Demande Verifier Stock
[si stock insuffisant]
Commander
[si stock suffisant]
Enregistrer Commande
[commande]
Editer Facture
Regler Facture
[Facture]
Encaisser paiement Livrer Produit
Receptionner Produit
Cet exemple montre la vente des produits dans une entreprise. Le

client demande un produit ou plusieurs, le service commercial enregistre la
demande et transmet la situation au service de production pour vérifier si le
produit existe en stock. Si oui on enregistre la commande et l’on crée une
facture, sinon on rejette la demande. Le client doit payer les frais pour la
facture éditée avant d’avoir accès à ses produits, après avoir payé le service

57
de production disponibilise les produits les lui transmet en et ça sera la fin

du processus.
C. DIAGRAMME DE SEQUENCE
1. PRESENTATION
L’objectif du diagramme de séquence est de représenter les
interactions entre objets en indiquant la chronologie des échanges. Cette
représentation peut se réaliser par cas d’utilisation en considérant les
différents scénarios associés.
Un diagramme de séquence se représente globalement dans un
grand rectangle avec indication du nom du diagramme.
sd NomDiagramme
2. LIGNE DE VIE
Une ligne de vie représente l’ensemble des opérations exécutées
par un objet. Un message reçu par un objet déclenche l’exécution d’une
opération. Le retour d’information peut être implicite (cas général) ou
explicite à l’aide d’un message de retour.
3. MESSAGE SYCHRONE ET ASYNCHRONE

Dans un diagramme de séquence, deux types de messages peuvent
être distingués :
- Message synchrone : dans ce cas l’émetteur reste en attente de la
réponse à son message avant de poursuivre ses actions. La flèche avec
extrémité pleine symbolise ce type de message. Le message retour peut
ne pas être représenté car il est inclus dans la fin d’exécution de
l’opération de l’objet destinataire du message.

58
- Message asynchrone : dans ce cas, l’émetteur n’attend pas la réponse

à son message, il poursuit l’exécution de ses opérations. C’est une
flèche avec une extrémité non pleine qui symbolise ce type de message.
4. FRAGMENT D’INTERACTION
a. Types de Fragments d’interaction

Dans un diagramme de séquence, il est possible de distinguer des
sous-ensembles d’interactions qui constituent des fragments.
Un fragment d’interaction se représente globalement comme un
diagramme de séquence dans un rectangle avec indication dans le coin à
gauche du nom du fragment. Un port d’entrée et un port de sortie peuvent
être indiqués pour connaître la manière dont ce fragment peut être relié au
reste du diagramme.
b. Opérateur alt
L’opérateur alt correspond à une instruction de test avec une ou
plusieurs alternatives possibles. Il est aussi permis d’utiliser les clauses de
type sinon.
Formalisme
L’opérateur alt se représente dans un fragment possédant au
moins deux parties séparées par des pointillés.

59
sd Diagramme de sequence
client receptionniste systeme
1 : passer commande() 2 : vérifier stock()
3 : resultat
alt alt
[stock suffisant]
4 : commande validée
................................................................................................................................
[stock insuffisant]
5 : commande rejetee
c. Opérateur opt
L’opérateur opt (optional) correspond à une instruction de test sans
alternative (sinon).
L’opérateur opt se représente dans un fragment possédant une seule partie.
Utilisateur Systeme
1 : Saisir Coordonnees()
2 : Verifier Authentification()
seq opt
[ si utilisateur enregistre]
3 : donner acces
d. Opérateur loop
L’opérateur loop correspond à une instruction de boucle qui
permet d’exécuter une séquence d’interaction tant qu’une condition est
satisfaite.

60
Il est possible aussi d’utiliser une condition portant sur un nombre

minimum et maximum d’exécution de la boucle en écrivant : loop min, max.
Dans ce cas, la boucle s’exécutera au minimum min fois et au maximum
max fois. Il est aussi possible de combiner l’option min/max avec la
condition associée à la boucle.
Formalisme et exemple.
L’opérateur loop se représente dans un fragment possédant une
seule partie et englobant toutes les interactions faisant partie de la boucle.
Association Adhérent
seq Loop Rendu=Non et Delai=dépassé

1 : relancer()

61
CHAPITRE IV. DEMARCHE DE CONCEPTION DES UP
I. UP.
UML n’est qu’un langage de modélisation. Nous n’avons pas
aujourd’hui dans la norme, de démarche unifiée pour construire les modèles
et conduire un projet mettant en œuvre UML ; c’est ainsi que le processus
unifié doit être associé à UML
II. LES PRINCIPES D’UP

Le processus de développement UP, associé à UML, met en œuvre
les principes suivants :
 Processus guidé par les cas d’utilisation,
 Processus itératif et incrémental,
 Processus centré sur l’architecture,
 Processus orienté par la réduction des risques.
Ces principes sont à la base du processus unifié décrit par les
auteurs d’UML.
a. Processus guidé par les cas d’utilisation

L’orientation forte donnée ici par UP est de montrer que le système
à construire se définit d’abord avec les utilisateurs. Les cas d’utilisation
permettent d’exprimer les interactions du système avec les utilisateurs, donc
de capturer les besoins.
Une seconde orientation est de montrer comment les cas
d’utilisation constituent un vecteur structurant pour le développement et les
tests du système. Ainsi le développement peut se décomposer par cas
d’utilisation et la réception du logiciel sera elle aussi articulée par cas
d’utilisation.
b. Processus itératif et incrémental

Ce type de démarche étant relativement connu dans l’approche
objet, il paraît naturel qu’UP préconise l’utilisation du principe de

62
développement par itérations successives. Concrètement, la réalisation de

maquette et prototype constitue la réponse pratique à ce principe. Le
développement progressif, par incrément, est aussi recommandé en
s’appuyant sur la décomposition du système en cas d’utilisation.
Les avantages du développement itératif se caractérisent comme

suit :
 Les risques sont évalués et traités au fur et à mesure des itérations,
 es premières itérations permettent d’avoir un feed-back des
utilisateurs,
 Les tests et l’intégration se font de manière continue,
 Les avancées sont évaluées au fur et à mesure de l’implémentation.
c. Processus centré sur l’architecture

Les auteurs d’UP mettent en avant la préoccupation de
l’architecture du système dès le début des travaux d’analyse et de
conception. Il est important de définir le plus tôt possible, même à grandes
mailles, l’architecture type qui sera retenue pour le développement,
l’implémentation et ensuite le déploiement du système. Le vecteur des cas
d’utilisation peut aussi être utilisé pour la description de l’architecture.
d. Processus orienté par la réduction des risques

L’analyse des risques doit être présente à tous les stades de
développement d’un système. Il est important de bien évaluer les risques des
développements afin d’aider à la bonne prise de décision. Du fait de
l’application du processus itératif, UP contribue à la diminution des risques
au fur et à mesure du déroulement des itérations successives.
III. PHASE ET ITERATION DU PROCESSUS

Le processus unifié, organisé en fonction du temps, est divisé en
quatre phases successives.
• Inception (Lancement).
• Élaboration.

63
• Construction.
• Transition.
a. INCEPTION
Cette phase correspond à l’initialisation du projet où l’on mène une
étude d’opportunité et de faisabilité du système à construire. Une évaluation
des risques est aussi réalisée dès cette phase.
En outre, une identification des principaux cas d’utilisation
accompagnée d’une description générale est modélisée dans un diagramme
de cas d’utilisation afin de définir le périmètre du projet. Il est possible, à ce
stade, de faire réaliser des maquettes sur un sous-ensemble des cas
d’utilisation identifiés. Ce n’est qu’à l’issue de cette première phase que l’on
peut considérer le projet véritablement lancé.
b. ELABORATION
Cette phase reprend les résultats de la phase d’inception et élargit
l’appréciation de la faisabilité sur la quasi-totalité des cas d’utilisation. Ces
cas d’utilisation se retrouvent dans le diagramme des cas d’utilisation qui est
ainsi complété.
Cette phase a aussi pour but d’analyser le domaine technique du
système à développer afin d’aboutir à une architecture stable. Ainsi, toutes
les exigences non recensées dans les cas d’utilisation, comme par exemple
les exigences de performances du système, seront prises en compte dans la
conception et l’élaboration de l’architecture.
L’évaluation des risques et l’étude de la rentabilité du projet sont
aussi précisées. Un planning est réalisé pour les phases suivantes du projet
en indiquant le nombre d’itérations à réaliser pour les phases de
construction.
c. CONSTRUCTION
Cette phase correspond à la production d’une première version du
produit. Elle est donc fortement centrée sur les activités de conception,

64
d’implémentation et de test. En effet, les composants et fonctionnalités non

implémentés dans la phase précédente le sont ici.
Au cours de cette phase, la gestion et le contrôle des ressources
ainsi que l’optimisation des coûts représentent les activités essentielles pour
aboutir à la réalisation du produit. En parallèle est rédigé le manuel
utilisateur de l’application.
d. TRANSITION
L Après les opérations de test menées dans la phase précédente, il
s’agit dans cette phase de livrer le produit pour une exploitation réelle. C’est
ainsi que toutes les actions liées au déploiement sont traitées dans cette
phase. De plus, des « bêta tests » sont effectués pour valider le nouveau
système auprès des utilisateurs.
IV. LES ACTIVITES DU PROCESSUS

Les activités menées à l’intérieur des quatre phases sont plus
classiques, car déjà bien documentées dans les méthodes existantes par
ailleurs. Nous nous limiterons donc à ne donner qu’une brève explication de
chaque activité.
a. EXPRESSION DES BESOINS

UP propose d’appréhender l’expression des besoins en se fondant
sur une bonne compréhension du domaine concerné pour le système à
développer et une modélisation des procédures du système existant. Ainsi,
UP distingue deux types de besoins :
• les besoins fonctionnels qui conduisent à l’élaboration des cas d’utilisation,
• les besoins non fonctionnels (techniques) qui aboutissent à la rédaction
d’une matrice des exigences.
Sur base de ce qui vient d’être dit, nous avons ici le diagramme de contexte
statique ou le diagramme de cas d’utilisation métier qui se présente de la
manière ci-suivante :

65
class Deployment Model
GESTION DE RESERVATION DES VOLS
CLIENT Plan de vol
Agent comptoir Chargé

opérations
aériennes
Billet
Caissier
Dans cet exemple, nous avons l’utilisateur ou acteur « Client » qui utilise
directement le système c’est pourquoi, il touche le système. Le système est
représenté par l’oval dans lequel c’est écrit « GESTION DE RESERVATION
DES VOLS ». Ce système se trouve dans un domaine (le rectangle), nous y
trouvons deux types d’acteurs :
- L’acteur Agent Comptoir : c’est un acteur interne au domaine et
externe au système comme caissier et chargé des opérations
aériennes. Mais il est un acteur d’interface dans le sens qu’il est en
contact physique avec les acteurs externes au domaine.
- Caissier et Chargé des Opérations : sont les acteurs internes du
domaine qui sont des contrôleurs, c’est-à-dire qu’ils ont niveau de
décision dans le processus.
b. ANALYSE
L’analyse permet une formalisation du système à développer en
réponse à l’expression des besoins formulée par les utilisateurs. L’analyse se
concrétise par l’élaboration de tous les diagrammes donnant une
représentation du système tant statique (diagramme de classe

66
principalement), que dynamique (diagramme des cas d’utilisation, de

séquence, d’activité, d’état-transition…).
c. CONCEPTION
La conception prend en compte les choix d’architecture technique
retenus pour le développement et l’exploitation du système. La conception
permet d’étendre la représentation des diagrammes effectuée au niveau de
l’analyse en y intégrant les aspects techniques plus proches des
préoccupations physiques.
d. IMPLEMENTATION
Cette phase correspond à la production du logiciel sous forme de
composants, de bibliothèques ou de fichiers. Cette phase reste, comme dans
toutes les autres méthodes, la plus lourde en charge par rapport à
l’ensemble des autres phases (au moins 40 %).
e. TEST
Les tests permettent de vérifier :
• la bonne implémentation de toutes les exigences (fonctionnelles et
techniques),
• le fonctionnement correct des interactions entre les objets,
• la bonne intégration de tous les composants dans le logiciel.

67
CHAPITRE IV INTRODUCTION AU LANGAGE SYSML
I. CONSIDERATION THEORIQUE
A. INTRODUCTION
Le métier de base de l’ingénieur consiste à résoudre des problèmes

de nature technologique, concrets et souvent complexes, liés à la
conception, à la réalisation et à la mise en œuvre de produits, de systèmes
ou de services. Cette aptitude résulte d’un ensemble de connaissances
techniques d’une part, économique, sociales et humaines d’autre part,
reposant sur une solide culture scientifique.
Les activités de l’ingénieur sont donc centrées autour de l’étude des
systèmes, de leur conception à leur recyclage. Ce chapitre cherchera à
présenter l’ensemble des systèmes, à l’aide d’un vocabulaire spécifique,
d’outils et de moyens de communication.
B. PRESENTATION DE SYSML
Systems Modeling Language, SysML en abrégé est un langage de

modélisation spécifique au domaine de l’ingénierie système. Il permet la
spécification, l’analyse, la conception, la vérification et la validation de
nombreux systèmes et systèmes de systèmes. SysML se définit comme une
extension d’une sous ensemble d’UML via l’utilisation du mécanisme de
profil UML.
SysML est spécialisé dans la modélisation de systèmes. Il offre aux
ingénieurs systèmes plusieurs améliorations notables par rapport à UML,
qui est plus centré sur le logiciel. Il est un langage plus réduit qu’UML, ce
qui facilite son apprentissage et son utilisation. SysML supprime beaucoup
de concepts d’UML trop liés à sa vision centrée sur le logiciel. L’ensemble du
langage SysML est plus petit, tant en nombre de types de diagrammes qu’en
nombre de concept totaux. Ce langage va bien au-delà des problématiques
de l’informatique. Comme UML, SysML n’est pas une méthode.

68
SysML dans toute sa globalité disponibilise neuf diagrammes

regroupés en trois catégories en l’occurrence :
- Les diagrammes définissant le cahier de charge ou les diagrammes
fonctionnels ;
- Les diagrammes comportementaux et
- Les diagrammes structurels.
II. DESCRIPTION FONCTIONNELLE

L’analyse ou la description fonctionnelle permet de décrire le besoin auquel
répond un système et de définir les contraintes, imposées par le milieu extérieur,
auquel il doit s’adapter. Dans l’ingénierie système, c’est une étape indispensable pour
s’assurer que le système à concevoir répondra au mieux aux besoins de ses utilisateurs.
A. LE DIAGRAMME DE CAS D’UTILISATION

Le diagramme de cas d’utilisation permet de représenter les
besoins attendus par un système. On se place du point de vue utilisateur.
Ce diagramme (DCU) est un schéma qui montre les cas d’utilisations (ovales)
reliés par des associations (lignes) à leurs acteurs (stick man). Chaque
association signifie « Participe à ».
Son objectif est de recenser les besoins clients et de délimiter
précisément le système, en recherchant les acteurs, ceux qui ont des
interactions avec lui, et les cas d’utilisation, ce à quoi il sert.
Exemple :
Soit à concevoir un lecteur MP3 pour la lecture de la musique.

69
Le diagramme de cas d’utilisation d’un lecteur MP3(partiel)

- CU « Ecouter de la musique » : représente un service, une
fonctionnalité attendue de l’utilisateur. Il symbolise son déroulement.
- CU « Allumer » : la relation ‘include’ indique que allumer fait partie du
déroulement de ‘Ecouter de la musique’.
- CU « Régler le volume » : la relation ‘extend’ indique que régler le
volume peut éventuellement se dérouler durant Ecouter de la
musique.
B. LE DIAGRAMME DES EXIGENCES

Que ce soit pour l'ingénierie système ou pour des réalisations
logicielles, les exigences sont couramment utilisées pour formaliser les pré-
requis du système, se traduisant par des fonctionnalités ou conditions qui
doivent ou devraient être satisfaites par le système (selon les éventuelles
priorités associées aux exigences).
Pour la maîtrise d'ouvrage (MOA), les exigences ont pour objectif
d'assurer l'adéquation de la solution (le système réalisé) avec les besoins. Les
exigences peuvent être formalisées et catégorisées par centre d'intérêts ou

70
aspects, par exemple différenciant les exigences fonctionnelles des exigences

techniques (performance, fiabilité, ergonomie, etc.).
La formalisation des exigences peut être effectuée avec une feuille
Excel, ou avec un outil spécialisé tel que DOORS ou CaliberRM. L'intérêt
qu'offrent ces outils est la gestion des exigences dans une organisation
structurée. Les exigences sont également utilisées pour la modélisation, par
la création d'associations entre exigences et cas d'utilisations, blocs ou tout
type d'élément du modèle, établissant une traçabilité.
Il est possible avec l'outil Enterprise Architect de définir les
exigences ou de les importer depuis un outil tel que DOORS, et de les
associer avec les éléments du modèle. SysML formalise les exigences et leur
représentation, s'inspirant des fonctionnalités des outils actuellement
disponibles sur le marché, par exemple EA, DOORS, CaliberRM. Ainsi SysML
définit une représentation graphique et visuelle des exigences textuelles,
permet une organisation hiérarchique et l'association avec les éléments du
modèle.
SysML définit de nouveaux types d'associations (liens de
dépendance stéréotypés) :
- Derive : une ou plusieurs exigences sont dérivées d'une exigence ;
- Satisfy: un ou plusieurs éléments du modèle (par exemple un bloc)
permettent de satisfaire une exigence ;
- Verify: un ou plusieurs éléments du modèle (par exemple un « test
case ») permettent de vérifier et valider une exigence ;
- Refine: un ou plusieurs éléments du modèle, par exemple un cas
d'utilisation, redéfinit une exigence.
SysML définit de nouveaux commentaires stéréotypés permettant

d'associer une explication à des associations ou éléments du modèle :
 Problem: commentaire dont la description pose le problème ou le
besoin qui a donné lieu à la création de l'association ou de l'élément
associé ;
 Rationale: commentaire dont la description indique la raison ou la
justification par rapport à l'élément ou l'association associé.

71
C. LE DIAGRAMME DE CONTEXTE
Ce diagramme complète éventuellement la description fonctionnelle
en présentant tous les éléments externes qui influencent le système étudié et
le système lui-même.

72
III. DESCRIPTION STRUCTURELLE

Le langage SysML propose 2 diagrammes destinés à décrire la
composition du système.
A. LE DIAGRAMME DE DEFINITION DES BLOCS (BDD)
Le diagramme de définition de block (BDD, ou Block Définition

Diagramme en anglais) représente la vue boite noire d’un bloc. Ainsi le bloc
principal et la hiérarchie des blocks qui le composent, qu’ils soient logiciels
ou matériels, sont spécifiés dans ce diagramme.
Par rapport à UML, le BDD de SysML redéfinit le diagramme de
classe en remplaçant les classes par des blocs. Le BDD est similaire à la
première page d’une notice de montage d’un meuble, indiquant la liste des
éléments et des pièces à assembler avec leurs quantités respectives.
Il répertorie les constituants du système ou d’un block en précisant
éventuellement leur rôle et leur quantité. Chaque block peut faire l’objet
d’une description plus précise en indiquant ses constituants, ses propriétés,
les opérations qu’il peut effectuer ainsi que les contraintes ou limites
auxquelles il est soumis. Exemple :

73
Diagramme de définition des blocks d’un lecteur mp3

Remarque : Dans le cas présent, le lecteur MP3 dispose d’une interface
utilisateur constituée d’un écran LCD tactile et de 3 boutons.
B. LE DIAGRAMME DE BLOCK INTERNE (IBD)
Le diagramme de bloc interne (IBD, ou Internal Block Diagram)

décrit la vue interne d’un bloc ou vue boite blanche, et se base sur le BDD
pour assembler les blocs qui composent le bloc principal. Il représente les
liens, les flux et les informations échangées entre les parts d’un block ou du
système.
Le bloc principal peut être représenté comme conteneur sur l’IBD
ou être absent de ce diagramme. Les blocs qui le composent, définis dans le
BDD, sont instanciés en parties (tout comme les parties dans un diagramme
de structure composite avec UML2). Ces parties sont assemblées par des
connecteurs qui relient leurs ports (ports standards avec interfaces exposées
et/ou ports de flux). Il est également possible de relier des parties
directement entre elles, l’utilisation des ports étant optionnelle.
C. LE DIAGRAMME PARAMETRIQUE
Le diagramme paramétrique est une nouveauté SysML qui redéfinit

le diagramme interne de bloc SysML (lui-même basé sur le diagramme de
structure composite UML2), et permet d’intégrer des analyses systèmes
(performance, fiabilité, etc.) avec des blocs de contrainte.

74
Un bloc de contrainte représente une expression mathématique

dont les paramètres peuvent faire référence à des éléments du système, par
exemple des propriétés de blocs.
IV. DESCRIPTION COMPORTEMENTALE

Pour modéliser l'aspect dynamique d'un système et/ou de ses
constituants, le langage SysML propose des diagrammes de comportement
parmi lesquels on trouve :
A. LE DIAGRAMME DE SEQUENCE
Le diagramme de séquence représente les éléments intervenant
dans le scénario, ainsi que les échanges de messages entre le système et des
acteurs, ou entre des parties du système, de manière chronologique en
précisant d'éventuelles contraintes de temps. La lecture d'un tel diagramme
se fait de haut en bas.
Dans un premier temps, on peut choisir de représenter les
interactions entre l'acteur et le système (vue boite noire). Par la suite il est
possible de rentrer en détails avec un diagramme de séquence qui représente
les blocs internes du système intervenant dans un scénario (pour un
message émis par l'acteur, le diagramme décrit l’enchaînement des messages
échangés entre les blocs internes du système) ; on parle ainsi de la vue boite
blanche (comportement du système).

75
B. LE DIAGRAMME D’ACTIVITES
Le diagramme d'activité est utilisé pour représenter les étapes d'un
traitement. Avec SysML, les « input et output pins » sont particulièrement
utilisés pour représenter le type d'élément qui est requis en entrée d'une
activité ou action, et ce qui est généré en sortie.
Si une action ou activité représente l'opération d'un bloc, on peut
garantir la cohérence du modèle en s'assurant que ce qui est défini en entrée
d'une activité corresponde à la signature de l'opération du bloc ou de son
interface.

76
ANNEXE ATELIER DE GENIE LOGICIEL
I. OBJECTIF D’UN AGL

Un atelier de génie logiciel (AGL) est un ensemble d’outils intégrés
de développement des logiciels consistant à atteindre la qualité et la
productivité des développements informatiques. Il fournit des services et des
outils pour développer des composants du produit de l’informatique
institutionnelle en contrôlant les normes de développement en s’appuyant
sur un Framework.
Il met au point des dispositions afin de :
 Optimiser la production de code des composants
 Gérer l’ensemble de paramètres utilisés
 Analyser l’impact sur l’ensemble des composants
 Tester les différents composants du produit logiciel
 Diffuser les versions du développement à l’implantation
L’atelier est structuré autour d’un référentiel unique qui décrit les
composants du produit logiciel en veillant à la :
o Génération automatique des composants
o Gestion des paramètres : vérification des valeurs
o Atelier d’édition des programmes: outil de gestion du code source à la
fabrication de l’exécutable
o Outils de génération des jeux de tests d’exécution de test unitaire, de test
de module et de test de manipulation de la base de données
o Outil de diffusion du produit : gestion des différents environnements, de la
diffusion et de l’implantation des versions du produit
o Outil de gestion des demandes : gestion des demandes d’évolutions et
d’anomalies constatées.
Les AGL ont un enjeu important pour le monde industriel et pour les
utilisateurs car la rationalisation visée par l’industrie doit aboutir à des
produits logiciels moins chers et mieux adaptés aux utilisateurs.

77
II. CARACTERISTIQUE D’UN ATELIER DE GENIE LOGICIEL

Trois étapes successives peuvent être distinguées :
- La prise en compte des phénomènes de l’organisation visés dans la
mise en oeuvre s’un système informatique au moyen des concepts
adaptés liés aux variables, aux fonctions, aux flux, aux dépendances
fonctionnelles,…
- La formalisation des phénomènes doit pouvoir s’effectuer selon toute
une panoplie d’outils, car une toute petite catégorie de phénomènes
est prise en compte par une méthode donnée.
- L’évaluation des phénomènes formalisés dans un atelier est une
fonction de contrôle de qualité qui doit être fait en temps réel et de
façon interactive entre le développeur et l’AGL.
III. OUTILS AGL

Il existe plusieurs outils d’AGL permettant de faciliter l’élaboration
des modèles ou diagrammes représentant la connaissance du développeur. Il
s’avère capital au développeur de motiver le choix d’un outil d’AGL par
rapport au besoin (approche de modélisation) et aux faisabilités
fonctionnelles.
Ainsi, nous allons illustrer l’usage des certains d’entre eux :
· Pacestar UML Diagrammer
· Microsoft Office Visio Professionnel
· Argo UML
· Entreprise Architect

78
IV. ILLUSTRATION
Pour une étude plus concrète, nous proposons dans le ligne qui suive l’Atélier de
Génie Logiciel MODELIO.
MODELIO est le successeur de l’atélier Objecteering. Il est un outil de modélisation

UML disponible sur les formes windows, Linux et Mac. Il intègre plusieurs aspects de
modélisation d’un système d’information telle que les exigences (besoins), la
conception et autres.
Voici comment se présente l’environnement de modélisation avec Modelio

79

80
BIBLIOGRAPHIE
- Alissali, M. (1998). Support de cours introduction au génie logiciel.
- Bell, D. (2004). Uml’ssequencediagram.)
- Debrauwer, L. & Van der Heyd, F. (2005). Uml 2 initiation, exemples
etexercices corrigés. eni.
- Developpez.com. (n.d.). Club d’entraide des développeurs
francophones.Internet.(http ://www.developpez.com/)
- Morand, B. (n.d.). Analyse et conception des systèmes d’information :
Lesdiagrammes de unifiedmodelinglanguage (uml).
- Muller, P.-A. &Gaertner, N. (2000). Modélisation objet avec uml.Eyrolles.
- Hughes BERSINI, L’orienté Objet, Eyrolles, 2004.
- Michael BLAHA, James RAMBAUGH − Modélisation et conceptionorientées
objet avec UML 2, Pearson Education, 2005.
- Alistair COCKBURN, Rédiger des cas d’utilisation efficaces, Eyrolles,2001.
- ACSIOME, Modélisation dans la conception des systèmes
d'information,Masson, 1989
- C. TESSIER, La pratique des méthodes en informatique de gestion,LesEditions
d'Organisation, 1995
- Daniel Durand, La systémique, PUF "Que sais-je?" n°1795, 1979
- Gérard Donnadieu & Michel Karsky, La systémique: penser et agir dansla
complexité, Liaisons,2002

Cours de CSI Bac 2 Informatique

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours de CSI Bac 2 Informatique

Transféré par

Droits d'auteur :

Formats disponibles

i

REPUBLIQUE DEMOCRATIQUE DU CONGO

Ass. Ir. Landry

Département D’Electronique-Informatique Industrielle

UE : Conception des Systèmes Informatiques

Semestre : Premier Semestre

Horaire : du Mardi 25/04 au Mercredi 03/05/2023 dans les installations de l’ISPT/Likasi.

Les approches suivantes seront utilisées pour l’enseignement de

Aspect d’Evaluation et Réglementaire

- Il est prévu un TD à chaque chapitre pour 20 % de Toute l’Evaluation;

Règles de Bonne Conduite :

CHAPITRE I CONSIDERATIONS THEORIQUES

III. CONCEPTS DE L’APPROCHE OBJET

IV. PRESENTATION D’UML

PRESENTATION GENERAL DES DIAGRAMMES

CHAPITRE II CONCEPTION STATIQUE ET DYNAMIQUE D’UN SI(UML)

I. LES DIAGRAMMES STATIQUES (CONCEPTION STATIQUE)

II. LES DIAGRAMMES COMPORTEMENTAUX (CONCEPTION

Ass. Ir. Landry MBAY KANYIMBU

LE DIAGRAMME DE CAS D’UTILISATION

CHAPITRE III INTRODUCTION AU LANGAGE SYSML

CHAPITRE IV APPROCHE UP (PROCESSUS UNIFIE)

LES PRINCIPES D’UP

PHASES ET ITERATION DU PROCESSUS

Ass. Ir. Landry MBAY KANYIMBU

CHAPITRE I CONSIDERATIONS THEORIQUES

Ass. Ir. Landry MBAY KANYIMBU

II. DEFINITION DES CONCEPTS

« Unsystème est un arrangement d’éléments en interaction, organisés en vue

Ass. Ir. Landry MBAY KANYIMBU

Afin de faciliter l’étude d’un système complexe, ce dernier pourra

- Un système d’information peut être défini techniquement comme

1. LES COMPOSANTS DES SYSTEMES D’INFORMATION

Ass. Ir. Landry MBAY KANYIMBU

manière ces composants fonctionnent pour apporter de la valeur à une

a. Les Composants Technologiques

Ass. Ir. Landry MBAY KANYIMBU

Ass. Ir. Landry MBAY KANYIMBU

Ass. Ir. Landry MBAY KANYIMBU

modélisation. Selon son objectif et les moyens utilisés, la modélisation est

Ass. Ir. Landry MBAY KANYIMBU

Un langage de modélisation doit définir :

L'industrie du logiciel dispose de nombreux langages de

Ass. Ir. Landry MBAY KANYIMBU

1. Modélisation par Décomposition Fonctionnelle

Ass. Ir. Landry MBAY KANYIMBU

III. CONCEPTS DE L’APPROCHE OBJET

Ass. Ir. Landry MBAY KANYIMBU

et un comportement. D’autres auteurs définissent l’objet comme étant une

Son comportement est caractérisé par les opérations qu’il peut

Ass. Ir. Landry MBAY KANYIMBU

Ass. Ir. Landry MBAY KANYIMBU

2. Opérations Non Accessibles

C. ASSOCIATION ET AGREGATION ENTRE CLASSE

Ass. Ir. Landry MBAY KANYIMBU

Ass. Ir. Landry MBAY KANYIMBU

En fait lors de l’exécution, l’appel de l’opération va

Soit les sous classes suivantes :

 Nom de la Sous Classe : Non Cadre

Le principe de calcul du salaire étant de calculer pour chaque type

Ass. Ir. Landry MBAY KANYIMBU

ou celle de la sous-classe NonCadre qui est en fait activée selon l’objet

I. PRESENTATION GENERAL D’UML

Ass. Ir. Landry MBAY KANYIMBU