MASI

MODELISATION DES SYSTEMES D’INFORMATION

Ousmane SENGHOR
E-MAIL: [email protected]
TEL: 77 459 41 71

2023 - 2024
Plan du cours

I- Présentations et définitions
́ ..
II- Rappels des concepts clés : Génie logiciel, Qualité…
1
III- UML2 : historique et principes généraux
IV- Modélisation fonctionnelle:
• diagramme de cas d’utilisation (Use case diagram) ,
• diagramme d’activités (Activity diagram),
• diagramme de séquence (Sequence diagram).
Modélisation statique=Diagrammes structurels:
• diagramme de classes (Class diagram),
• diagramme d’objets (Object diagram),
• diagramme de composants (Component diagram),
• diagramme de déploiement (Deployment diagram),
• diagramme de paquetages (Package diagram),
• diagramme de structures composites (Composite
structure diagram)
2/140 .
I- Présentations et définitions

 UML est un langage qui permet de

représenter des modèles, mais il ne définit
1
pas le processus d'élaboration des modèles !
 UML est une notation, pas une méthode
 UML est un langage de modélisation objet
 UML convient pour toutes les méthodes
objet

3/140 .
I- Présentations et définitions

UML est un langage formel et normalisé

– gain de précision
1
– gage de stabilité
– encourage l'utilisation d'outils
UML est un support de communication performant
– Il cadre l'analyse.
– Il facilite la compréhension de
représentations abstraites complexes.
– Son caractère polyvalent et sa souplesse en
font un langage universel.

4/140 .
I- Présentations et définitions
Qu’est-ce qu’un modèle?

Modèle = Objet conçu et construit (artefact) :

1

• Pour représenter un sujet d’études Exemple de sujet : les

circuits électriques (Représentativité)
• S’appliquant à plusieurs cas de ce sujet d’étude (Généricité)
• Incarnant un point de vue sur ces cas (Abstraction)

Un même sujet d’études peut avoir plusieurs modèles

• Chaque modèle donne un point de vue différent sur le sujet

5/140 .
I- Présentations et définitions
Langages de modélisation ?
• Langages utilisés pour exprimer un modèle
Langues naturelles : qui évoluent hors du contrôle d’une théorie
1 Ex : Français, Anglais, ...
Langages artificiels : conçus pour des usages particuliers
Langages formels : syntaxe définie par une grammaire Ex
: Logique, langages informatique (C, Java, SQL, ...), ...
• Pouvoir d’expression d’un langage
Ensemble des modèles que l’on peut exprimer
Le choix du langage influence la conception du modèle...
...et donc la perception du sujet d’études

• Interprétation d’un langage

Procédure pour comprendre un modèle (Sémantique)
Modèle ambigu : Plusieurs interprétations différentes possibles
Modèle exécutable : Interprétation exécutable par une machine

6/140 .
II- Rappels des concepts clés

1. Génie logiciel
Est appelé génie logiciel l'application des principes de l'ingénierie (traitant
habituellement des systèmes physiques) à la conception, au développement, au
1
test, au déploiement et à la gestion de logiciels.

Cette discipline applique au développement logiciel l'approche structurée et

hiérarchisée de la programmation utilisée par l'ingénierie, dans le but d'améliorer la
qualité, les délais et le budget, tout en assurant des tests ordonnés et la
certification des ingénieurs.

Le génie logiciel est généralement réservé aux logiciels complexes de grande

envergure et non aux applications ou programmes simples. Le développement n'est
toutefois qu'une phase du processus. Les ingénieurs logiciels sont responsables de
la conception des systèmes, alors que les programmeurs sont chargés du codage
permettant leur implémentation.

7/140 .
II- Rappels des concepts clés

1. Génie logiciel

1 ……. Les différents champs du génie logiciel couvrent les processus liés à l'ingénierie
et à la certification logicielles, à savoir : l'analyse des besoins, la conception, la
construction et la maintenance des logiciels, la gestion de la configuration et de
l'ingénierie logicielles, la gestion et la création du processus de développement
logiciel, les modèles et les méthodes d'ingénierie logicielle, la qualité logicielle, les
pratiques professionnelles d'ingénierie logicielle de même que les mathématiques
et l'informatique fondamentales et les études d'ingénierie.

S'il est impossible de savoir précisément à quand remonte la première mention de

ce terme, on sait toutefois que c'est en 1968 que l'OTAN a organisé la première
conférence sur le sujet. L'objectif était alors de remédier à l'incohérence et à
l'absence de fiabilité du développement logiciel, et d'en améliorer impérativement
la qualité et la fiabilité. Les experts internationaux réunis à cette occasion ont
approuvé l'application des processus systématiques de l'ingénierie du monde
physique au développement logiciel, déjà développés à ces fins.

8/140 .
II- Rappels des concepts clés

2. La qualité
En informatique et en particulier en génie logiciel, la qualité logicielle est une
1
appréciation globale d'un logiciel, basée sur de nombreux indicateurs.

La complétude des fonctionnalités, la correction et précision des résultats, la

fiabilité, la tolérance de pannes, la facilité et la flexibilité de son utilisation, la
simplicité, l'extensibilité, la compatibilité et la portabilité, la facilité de correction et
de transformation, la performance, la cohérence et l'intégrité des informations qu'il
contient sont tous des facteurs de qualité.

La qualité d'un logiciel dépend entièrement de sa construction et des processus

utilisés pour son développement, c'est par conséquent un sujet central en génie
logiciel. Une appréciation globale de la qualité tient autant compte des
facteurs extérieurs, directement observables par l'utilisateur, que des
facteurs intérieurs, observables par les ingénieurs lors des revues de code ou des
travaux de maintenance.

9/140 .
II- Rappels des concepts clés
2. La qualité: LE MODÈLE D’ÉVALUATION
Ce modèle définit la qualité́ du logiciel à travers la qualité́ du produit, du processus et du
service rendu. On peut représenter ce modèle sous la forme d’une arborescence.
1
II- Rappels des concepts clés
2. La qualité
Un facteur est une caractéristique du logiciel, du processus ou du service
contribuant à sa qualité telle qu'elle est ressentie par l'utilisateur.
1

Un critère est un attribut du logiciel par l'intermédiaire duquel un facteur

peut être obtenu. C'est également une caractéristique du logiciel sur laquelle
le développeur peut agir. (par exemple, sa simplicité)

Une métrique est la mesure d'une propriété d'un critère. (par exemple, la
taille d’un module pour le critère "Simplicité").

• Les principaux facteurs de qualité d’un logiciel:

Disponibilité, ergonomie, fiabilité, cohérence, complétude,

compréhensibilité, contrôle d’accès, modularité, protection des accès,
simplicité.
11/140 .
III- UML2 : historique et principes généraux
- Historique la programmation par objets
Les premiers langages de programmation qui ont utilisé des objets sont Simula I
(1961-64) et Simula 67 (1967), conçus par les informaticiens norvégiens Ole-Johan
Dahl et Kristan Nygaard. Simula 67 contenait déjà les objets, les classes, l'héritage,
1
l'encapsulation, etc.

Alan Kay, du PARC de Xerox, avait utilisé Simula dans les années 1960. Il réalisa en
1976 Smalltalk qui reste, aux yeux de certains programmeurs, le meilleur langage de
programmation par objets.

Bjarne Stroustrup a mis au point C++, une extension du langage C permettant la

programmation orientée objet, aux Bell Labs d'AT&T en 1982. C++ deviendra le
langage le plus utilisé par les programmeurs professionnels. Il arrivera à maturité en
1986, sa standardisation ANSI / ISO date de 1997.

Java est lancé par Sun en 1995. Comme il présente plus de sécurité que C++, il
deviendra le langage favori de certains programmeurs professionnels.

12/140 .
III- UML2 : historique et principes généraux
- Introduction
La description de la programmation par objets a fait ressortir l'étendue du travail conceptuel
nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des
interfaces, etc.
1
Pour programmer une application, il ne convient pas de se lancer tête baissée dans l'écriture
du code : il faut d'abord organiser ses idées, les documenter, puis organiser la réalisation en
définissant les modules et étapes de la réalisation. C'est cette démarche antérieure à
l'écriture que l'on appelle modélisation ; son produit est un modèle.

Les spécifications fournies par la maîtrise d'ouvrage en programmation impérative étaient

souvent floues : les articulations conceptuelles (structures de données, algorithmes de
traitement) s'exprimant dans le vocabulaire de l'informatique, le modèle devait souvent être
élaboré par celle-ci.

L'approche objet permet en principe à la maîtrise d'ouvrage de s'exprimer de façon précise

selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être
immédiatement compris par les informaticiens.
En principe seulement, car la modélisation demande aux maîtrises d'ouvrage une
compétence et un professionnalisme qui ne sont pas aujourd'hui répandus.

13/140 .
III- UML2 : historique et principes généraux
- Histoire des modélisations par objets
Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative
(notamment Merise) étaient fondées sur la modélisation séparée des données et des
traitements.
1Lorsque la programmation par objets prend de l'importance au début des années 1990, la
nécessité d'une méthode qui lui soit adaptée devient évidente.
Plus de cinquante méthodes apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion,
HOOD, OMT, OOA, OOD, OOM, OOSE, etc.), mais aucune ne parvient à s'imposer. En 1994, le
consensus se fait autour de trois méthodes :

• OMT de James Rumbaugh (General Electric) fournit une représentation graphique des
aspects statique, dynamique et fonctionnel d'un système ;
• OOD de Grady Booch, définie pour le Department of Defense, introduit le concept de
paquetage (package) ;
• OOSE d'Ivar Jacobson (Ericsson) fonde l'analyse sur la description des besoins des
utilisateurs (cas d'utilisation, ou use cases).

Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en

compétition s'était réduit, mais le risque d'un éclatement subsistait : la profession pouvait se
diviser entre ces trois méthodes, créant autant de continents intellectuels qui auraient du
mal à communiquer.
14/140 .
III- UML2 : historique et principes généraux
- Histoire des modélisations par objets
Événement considérable et presque miraculeux, les trois gourous qui régnaient chacun sur
l'une des trois méthodes se mirent d'accord pour définir une méthode commune qui
fédérerait leurs apports respectifs (on les surnomme depuis « the Amigos »).
1UML (Unified Modeling Language) est né de cet effort de convergence. L'adjectif unified est
là pour marquer qu'UML unifie, et donc remplace.

En fait, et comme son nom l'indique, UML n'a pas l'ambition d'être exactement une
méthode : c'est un langage.

L'unification a progressé par étapes. En 1995, Booch et Rumbaugh (et quelques autres) se
sont mis d'accord pour construire une méthode unifiée, Unified Method 0.8 ; en 1996,
Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement du mot méthode par
le mot langage, plus modeste).
Les acteurs les plus importants dans le monde du logiciel s'associent alors à l'effort (IBM,
Microsoft, Oracle, DEC, HP, Rational, Unisys, etc.) et UML 1.0 est soumis à l'OMG(5). L'OMG
adopte en novembre 1997 UML 1.1 comme langage de modélisation des systèmes
d'information à objets. La version d'UML en cours en 2008 est UML 2.1.1 et les travaux
d'amélioration se poursuivent.
UML est donc non seulement un outil intéressant, mais une norme qui s'impose en technologie à objets
et à laquelle se sont rangés tous les grands acteurs du domaine, acteurs qui ont d'ailleurs contribué à son
élaboration. 15/140 .
IV- Modélisation fonctionnelle:
A - Diagramme de cas d’utilisation (Use case diagram):

Le diagramme de cas d'utilisation représente la structure des grandes fonctionnalités

nécessaires aux utilisateurs du système.
1
C'est le premier diagramme du modèle UML, celui où s'assure la relation entre l'utilisateur et
les objets que le système met en œuvre.

Il consiste à:
o Modélisant les besoins des utilisateurs.
o Identifiant les grandes fonctionnalités et les limites du système.
o Représentant les interactions entre le système et ses utilisateurs

16/140 .
IV- Modélisation fonctionnelle:
• Les éléments d’un diagramme des cas d’utilisation

17/140 .
IV- Modélisation fonctionnelle:
• Les éléments d’un diagramme des cas d’utilisation

18/140 .
IV- Modélisation fonctionnelle:
• Les éléments d’un diagramme des cas d’utilisation

19/140 .
IV- Modélisation fonctionnelle:
3) Relation entre acteurs et cas d’utilisation :

La relation d’association

A1 chaque acteur est associé un ou plusieurs cas d’utilisations, la relation d’association peut
aussi être appelée relation de communication.

Elle est représentée par un trait reliant l’acteur et le cas d’utilisation. Nous pouvons rajouter
sur ce trait un stéréotype qui va préciser la relation de communication (« communicate »).

20/140 .
IV- Modélisation fonctionnelle:

21/140 .
IV- Modélisation fonctionnelle:
4. Les relations entre cas d’utilisation

22/140 .
IV- Modélisation fonctionnelle:
4. Les relations entre cas d’utilisation

23/140 .
IV- Modélisation fonctionnelle:
4. Les relations entre cas d’utilisation

Relation de généralisation ou de spécialisation :

Comme nous l’avons découvert lorsque nous avons traité la notion d’objet, il est également
1
possible de spécialiser un cas d’utilisation en un autre cas d’utilisation. Nous obtenons alors
un sous-cas d’utilisation.
Comme pour les classes, le sous-cas d’utilisation hérite du comportement du sur-cas
d’utilisation. Le sous-cas d’utilisation hérite aussi de toutes les associations du sur-cas
(relations d’association avec les acteurs, relations d’inclusions, et relations d’extensions).

Quelquefois, le sur-cas d’utilisation est abstrait (c’est-à-dire qu’il ne peut pas être instancié). Il
correspond à un comportement partiel et sert uniquement de base pour les sous-cas
d’utilisation qui en hériteront.

La relation de généralisation est représentée par une flèche avec une extrémité triangulaire.

Le nom d’un cas d’utilisation abstrait est écrit en italique (ou accompagné du stéréotype

« abstract »).

24/140 .
IV- Modélisation fonctionnelle:
4. Les relations entre cas d’utilisation

Relation de généralisation ou de spécialisation :

25/140 .
IV- Modélisation fonctionnelle:
5. Type d’acteurs et relation entre acteurs :

Acteurs principaux et secondaires :

A chaque cas d’utilisation est associé un ou plusieurs acteurs.

1

Un acteur est principal pour le cas d’utilisation auquel il est lié si ce cas d’utilisation lui rend un
service.

Les autres acteurs liés à ce cas d’utilisation sont dit secondaires.

Normalement, Il ne peut y avoir qu’un seul acteur principal par cas d’utilisation.

En général, l’acteur principal sollicite le cas d’utilisation alors que l’acteur secondaire est
sollicité par le cas d’utilisation.
Un acteur peut être principal pour un cas d’utilisation et secondaire pour un autre cas
d’utilisation.

Si nous désirons indiquer si l’acteur est principal ou secondaire pour un cas d’utilisation, nous
pouvons ajouter les stéréotypes « primary » ou « secondary » sur la relation d’association
entre l’acteur et le cas d’utilisation.
26/140 .
IV- Modélisation fonctionnelle:
6. La relation de généralisation :

La seule relation possible entre 2 acteurs est la généralisation (même comportement et même
représentation graphique que la relation de généralisation entre 2 cas d’utilisation).
Exemple : Dans le cas du DAB, l’acteur Client banque est une spécialisation de l’acteur Porteur
1
de carte.

27/140 .
IV- Modélisation fonctionnelle:
6. La relation de généralisation :

28/140 .
IV- Modélisation fonctionnelle:
6. La relation de généralisation :

29/140 .