0% ont trouvé ce document utile (0 vote)
28 vues361 pages

Université de Kalemie: Étude Des Systèmes D'information

Le document présente un cours sur l'étude des systèmes d'information, mettant l'accent sur la conception et l'implémentation à travers des méthodes comme UML et MERISE. Il aborde les objectifs d'apprentissage, les défis actuels du génie logiciel, ainsi que l'importance de la documentation et des outils CASE. Enfin, il souligne la nécessité d'une analyse approfondie pour résoudre les problèmes et améliorer la communication entre les utilisateurs et les développeurs.

Transféré par

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

Université de Kalemie: Étude Des Systèmes D'information

Le document présente un cours sur l'étude des systèmes d'information, mettant l'accent sur la conception et l'implémentation à travers des méthodes comme UML et MERISE. Il aborde les objectifs d'apprentissage, les défis actuels du génie logiciel, ainsi que l'importance de la documentation et des outils CASE. Enfin, il souligne la nécessité d'une analyse approfondie pour résoudre les problèmes et améliorer la communication entre les utilisateurs et les développeurs.

Transféré par

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

Introduction

Point de vue fonctionnel

Université de Kalemie

Domaine des sciences économiques et de gestion


Département de l’informatique de gestion
(BAC+2)

Étude des systèmes d’information


(Langage UML)

Youen Mushegerha (CT)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Bibliographie (non exhaustive)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Présentation
Fonction,
grade et
Profil statu Licence Master Autres
EVAPRO,
Réseaux,
Réseaux
SI et sociaux,
Réseaux, ILAQ,
Info de ENSP Odélisation
gestion, Yaoundé et Program-
Enseignant UCB (Came- mation
(CT) ; (Bukavu), roun), Objet, Télé-
Marié 2013 2017 matique ;

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Conception VS Implémentation

Conception
La conception est la phase créative d’un projet d’ingénierie. Le but
premier de la conception est de permettre de créer un système ou un
processus répondant à un besoin en tenant compte des contraintes.

Le système doit être suffisamment défini pour pouvoir être installé,


fabriqué, construit et être fonctionnel, et pour répondre aux besoins
du client.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Conception VS Implémentation

Implémentation
L’implémentation est la réalisation, l’exécution ou la mise en pra-
tique d’un plan, d’une méthode ou bien d’un concept, d’une idée, d’un
modèle, d’une spécification, d’une norme ou d’une règle dans un but
précis.

L’implémentation est donc l’action qui doit suivre une réflexion pour
la concrétiser.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Quels sont les Objectifs du cours ?

Apprendre à utiliser des méthodes systématiques pour l’analyse


des besoins
Créer des modèles UML d’analyse couvrant 3 aspects :
Fonctionnel,
Statique,
Dynamique
Avoir la maîtrise totale sur la méthode MERISE à travers les
améliorations d’UML ;
Connaître de nouveaux formalismes de modélisation
Découvrir les principaux concepts des approches orientées objet

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Plan du cours

Chap 1. Introduction aux notions des systèmes d’information


Chap 2. Point de vue fonctionnel
Chap 3. Point de vue statique
Chap 4. Point de vue dynamique
Étude de cas (à chaque fin d’une notion)

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Système d’Information d’une entreprise


Dans une entreprise, les organes (acteurs) échangent des informations
(flux) entre eux et créent ainsi un environnement de travail et de pro-
duction.

et chacun des échanges est nommé et bien orienté.


Youen Mushegerha (CT) Étude des systèmes d’information
Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Système d’Information d’une entreprise

Chaque entreprise est constituée de plusieurs domaines d’activités di-


verses.

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Degrés d’invariance dans l’entreprise

Ce qui est stable :


Processus liant l’entreprise à ses acteurs externes
Les données
Ce qui est moins stable :
Les traitements
Ce qui est peu stable :
Les techniques
La nature de la demande
Les besoins en statistiques
L’organisation de l’entreprise

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Degrés d’invariance d’un SI

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

A quoi sert l’information ?

Support pour l’action


Conserve une trace des activités
Apporte une aide à la décision
Mémorisation
traitement automatique
Diffusion et partage

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Système d’information

Systémique

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Taille et complexité du logiciel

Problème
Complexité fonctionnelle et algorithmique
Mutations technologiques perpétuelles
Complexité des architectures

Solution
Distinguer analyse et réalisation
Décomposer le système
Utiliser une approche de haut niveau

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Taille croissante des équipes

Problème
Compétences de + en + variées et pointues
Applications stratégiques orientées métier
Délais de + en + courts

Solution
Technologie unifiant le vocabulaire
Méthode, démarche de travail

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Évolution rapide des applications

Problème
Besoins du client
Activités du client
Environnement technique

Solution
Cycle de vie itératif et incrémental

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Spécifications peu précises

Problème
Imprécision, incomplétude
Interface difficile entre domaine métier et informatique

Solution
Utilisation de modèles, notamment graphiques

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Défauts du langage humain

Problème
Bruit
Silence
Sur-spécification
Contradiction, redondance (polysème et synonymes)
Ambiguïté
Référence en avant
Etc.

Solution
Sérénité dans l’utilisation de la démarche

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Impact d’une erreur de spécification

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Nécessité de l’analyse et de la conception

Poser les bonnes questions :


QUEL est le problème ?
POURQUOI le problème existe-t-il ?
QUI est impliqué ?
OU se situe le problème ?
QUAND faut-il mettre en œuvre la solution ?
QUELLE technologie est implicitement pressentie ?
COMMENT on y arrive ?

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Analyse vs conception

La conception est TRÈS souvent un compromis ! ! !

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Analyse vs conception

L’analyse prend en compte l’environnement du monde réel


QUOI
Conceptuel
Peut couvrir des besoins de l’utilisateur hors logiciel
La conception consiste à trouver une solution techniquement pos-
sible
COMMENT
Organisation, implémentation physique
le choix des méthodes et langages techniques

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Analyse

Comprendre le problème
Un cahier des charges textuel est rédigé par l’utilisateur
Poser des questions pour identifier les vrais besoins
Supprimer les ambiguïtés et incohérences
Parler le langage de l’utilisateur (le client)
Réaliser des modèles (abstractions)
L’ensemble des modèles constitue le modèle d’analyse
C’est une représentation + ou - formelle de l’information
Le modèle d’analyse est contractuel
En amont, il faut cerner les besoins par une étude préalable du
domaine

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Conception

Résoudre le problème
Connaître les technologies, les architectures appropriées et les
bonnes pratiques
Comparer les approches possibles (trade-off)
Appliquer des solutions standards quand c’est possible (frame-
works)
Parler le langage de l’utilisateur et de l’analyste
Réaliser le modèle de conception
Adapter le modèle d’analyse
Allouer les composants du modèle d’analyse à des composants du
modèle de conception

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Importance de la documentation

La réalisation de la documentation est perçue comme une contrainte

Elle sera faite plus tard (= jamais)


Elle n’est pas mise à jour
Les spécifications et la conception doivent être documentées
Approbation des clients
Compréhension des développeurs
Une bonne stratégie de tests peut être développée à partir des spé-
cifications
La documentation est indispensable pour la maintenance

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Outils CASE

Computer Aided Software Environment


Éditeur de diagrammes
Dictionnaire de données (repository)
Contrôle d’accès
Vérifications automatiques de la cohérence, complexité. . .
S’appuie sur une méthode
Génération automatique de documentation
Génération automatique de code
Exemples :
Magic Draw UML 11.5 (No Magic, Inc.), edraw Max
Objecteering (Softeam), Rose (Rational), Mega (IBM)
Class Builder (freeware )
Outils gratuits de démonstration : UML Jude, visual paradigm,
Star UML (Win), Umbrello, Bouml (UNIX)

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

UML : Ce que c’est

Le langage UML (Unified Modeling Language, ou langage de modéli-


sation unifié) a été pensé pour être un langage de modélisation visuelle
commun, et riche sémantiquement et syntaxiquement. Il est destiné
à l’architecture, la conception et la mise en œuvre de systèmes logi-
ciels complexes par leur structure aussi bien que leur comportement.

Il ressemble aux plans utilisés dans d’autres domaines et se compose


de différents types de diagrammes.

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

UML : Ce que c’est

UML n’est pas un langage de programmation, mais il existe des ou-


tils qui peuvent être utilisés pour générer du code en plusieurs langages
à partir de diagrammes UML.
Son objectif :
Créer un langage visuel commun dans le monde complexe du déve-
loppement de logiciels, un langage qui serait également compris par
les utilisateurs professionnels et tous ceux qui veulent comprendre un
système.

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

UML : Ce que c’est

Dans un LOO, les algorithmes définissent des objets et les font inter-
agir les uns avec les autres. Il peut s’agir d’immeubles, de widgets sur
un ordinateur ou encore d’êtres humains.

UML combine plusieurs notations orientées objet : Object-Oriented


Design (conception orientée objet), Object Modeling Technique (tech-
nique de modélisation objet) et Object-Oriented Software Enginee-
ring (génie logiciel orienté objet).

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Pourquoi l’approche objet ?

Stabilité de la modélisation par rapport aux entités du monde réel


Construction itérative facilitée par le faible couplage entre com-
posants
Réutilisation des éléments
Simplicité du modèle : 5 concepts : objets, messages, classes,
généralisation, polymorphisme

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Notion d’objet

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Notion d’objet

Différence Langage - Méthode


Langage de modélisation = notations, grammaire, sémantique
Méthode = comment utiliser le langage de modélisation (recueil
des besoins, analyse, conception, mise en œuvre, validation, ...)

Pourquoi modéliser ?
La description de la POO nécessite un travail conceptuel
Il faut organiser ses idées, les documenter, organiser la réalisation,
définir des modules, ...
Modélisation = démarche antérieure à l’implémentation

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Historique UML

Développé en réponse à l’appel lancé par l’OMG (Object Management


Group [[Link]] fondé en 1989 pour standardiser et promouvoir
l’objet) dans le but de définir la notation standard pour la modéli-
sation des applications construites à l’aide d’objets. Elle est héritée
de plusieurs autres méthodes telles que OMT (Object ModelingTech-
nique), OOSE (Object Oriented Software Engineering) et Booch. Les
principaux auteurs de la notation UML sont Grady Booch, Ivar Ja-
cobson et James Rumbaugh.

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Les auteurs

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Historique UML

UML est une notation, pas une méthode


UML est un langage universel de modélisation objet
UML convient à toutes les méthodes objet
UML n’est pas un langage de programmation et en est donc indé-
pendant
UML est extensible
UML est unenormemaintenue par l’OMG
Description exacte : http ://[Link]/uml
Youen Mushegerha (CT) Étude des systèmes d’information
Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Historique UML

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Historique UML : besoin d’unification

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Historique UML : unification

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Hiérarchie des diagrammes d’UML (2 catégories)


Diagrammes de structure (éléments statiques d’un système)
Diagrammes de comportement (interactions dynamiques entre
les objets d’un système)

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Hiérarchie des diagrammes d’UML (2 catégories)


Diagrammes de structure (éléments statiques d’un système)
Diagrammes de comportement (interactions dynamiques entre
les objets d’un système)

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Diagrammes de structure

Diagramme de classes (Cours + TD) : représente la structure sta-


tique en termes de classes et de relations
Diagramme d’objets (Cours) : les objets et leurs relations
Diagramme de modules (Cours) : regroupement des classes
Diagramme de composants (Cours) : composants logiciels d’une
application
Diagramme de déploiement (Cours + TD) : déploiement des
composants sur les dispositifs physiques
Diagramme de structures composites (Cours) : liens entre dia-
gramme de classes et diagramme de composants

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Diagrammes de comportement

Diagramme d’activité (Cours + TD) : décrit le comportement en


termes d’actions, de flux
Diagramme de cas d’utilisation (Cours + TD) : les fonctions du
système du point de vue de l’utilisateur
Diagramme d’états-transitions (Cours + TD) : comportement
des éléments en termes d’états et de changement d’états
Diagrammes d’interactions (Cours + TD)

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

Diagrammes d’interactions

Diagramme de séquence (Cours + TD) : représentation tempo-


relle des objets et de leurs interactions
Diagramme de communication (Cours + TD) : représentation
spatiale des objets, des liens et des interactions
Diagramme de timing (Cours) : spécifications temporelles (pour
systèmes temps réel)
Diagramme global d’interaction (Cours) : version simplifiée du
diagramme d’activité qui se focalise sur les éléments qui inter-
viennent dans la réalisation d’une activité plutôt que sur ses étapes

Youen Mushegerha (CT) Étude des systèmes d’information


Système d’Information d’une entreprise
Introduction Problème actuels du génie logiciel
Point de vue fonctionnel Analyse vs conception, documentation et CASE
Approches orientées objets : intro UML

UML et ses conséquences

Standard générique : conçu pour « tout » modéliser mais se voit


reprocher sa complexité
Parfois concurrencé par les DSL : Domain Specific Language
Ces approches se rejoignent autour du développement guidé par
les modèles : Génération de code
NB. : Il est rare, voir même jamais d’observer (étudier) tous les
diagramme dans un cas pratique de conception d’un système d’in-
formation.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les axes de modélisation


Il existe trois axes de modélisation sous le principe d’UML et chacun
d’entre eux suppose un ensemble des diagrammes :

Nous commencerons par étudier l’axe fonctionnel avec le diagramme


des cas d’utilisation mais voyons les autres représentations.
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

4+1 vues ( Philippe Kruchten en 1995)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme des cas d’utilisation

Le Diagramme des cas d’utilisation ou Use Cases a pour rôles :


Permet l’analyse des besoins de l’utilisateur
Sert à élaborer les jeux d’essais (tests)
Décrit le comportement du système vue de l’utilisateur : actions
et réactions (fonctions)
Un cas d’utilisation regroupe une famille de scénarii selon un
critère fonctionnel
Regroupement par catégories d’utilisateurs

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme des cas d’utilisation

Un use case comprend :


Les acteurs
Le système
Les cas d’utilisations eux-mêmes

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Qui peut être un acteur ? (D.C.U)


Un acteur peut être :
Une même personne physique peut jouer le rôle de plusieurs ac-
teurs

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Qui peut être un acteur ? (D.C.U)


Un acteur peut être :
Acteurs primaires : utilisent "directement" le système
Acteurs secondaires : administrent le système
Matériel externe
Autres systèmes

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)


Cas d’utilisation (ellipse ou notation en classificateur)

Acteur (silhouette ou notation en classificateur)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)


Relation de communication entre acteur et use case

Relation de généralisation entre cas d’utilisation :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)

Relation de généralisation entre acteurs :


La seule relation possible entre deux acteurs est la généralisation :
un acteur A est une généralisation d’un acteur B si l’acteur A peut
être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation
accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.
Le symbole utilisé pour la généralisation entre acteurs est une flèche
avec un trait plein dont la pointe est un triangle fermé désignant
l’acteur le plus général.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)


Relation de généralisation entre acteurs :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)


Relation entre cas : relation d’inclusion
On peut regrouper des fonctionnalités communes à plusieurs
cas d’utilisation en créant un cas d’utilisation inclus, partagé
Le cas inclus n’est ni autonome ni complet : il constitue une
partie nécessaire à la définition de cas d’utilisation plus larges

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)

Comme le montre la figure suivante (même la précédente), une re-


lation d’inclusion est affichée dans l’éditeur de diagramme comme
une ligne tiretée avec une flèche ouverte dirigée du cas d’utili-
sation de base vers le cas d’utilisation inclus. Le mot clé «include»
est rattaché au connecteur.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)

Exemple : Le cas d’utilisation LogIn est un cas d’utilisation inclus


distinct, car il contient des comportements qu’utilisent plusieurs autres
cas d’utilisation dans le système. Une relation d’inclusion est dirigée
du cas d’utilisation CheckOrderStatus vers le cas d’utilisation LogIn
pour indiquer que le cas d’utilisation CheckOrderStatus inclut tou-
jours les comportements figurant dans le cas d’utilisation LogIn.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)

Relation entre cas : relation d’extension


Le cas d’utilisation d’extension peut accéder aux attributs du cas
d’utilisation de base et modifier ces attributs, mais ce dernier n’a
pas connaissance du cas d’utilisation d’extension et ne peut donc
pas accéder aux attributs et opérations du cas d’utilisation d’exten-
sion, ni les modifier. Une instance du cas d’utilisation d’extension
peut être étendu (sous certaines conditions) par le comportement
spécifié par le cas source (de base)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)


Vous pouvez ajouter des relations d’extension à un modèle pour pré-
senter les situations suivantes :
Un composant d’un cas d’utilisation qui est un comportement fa-
cultatif du système
Un flux secondaire est exécuté uniquement sous certaines condi-
tions
Un ensemble de segments de comportement qui peut être inséré
dans un cas d’utilisation de base

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)

Exemple d’extension : Le cas « ajouter un titulaire sur le compte


joint » étend le cas « ouvrir un compte » car il propose des fonction-
nalités supplémentaires ; cependant, le cas de base est utilisable de
façon autonome.
Les 3 notations ci-dessous sont possibles, Notation 1 :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les formalismes possibles (D.C.U)


Les 3 notations ci-dessous sont possibles :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Notion de scénario (D.C.U)

Une fois les cas d’utilisation identifiés, il faut les décrire


Un scénario représente une succession particulière de séquences
d’actions qui s’exécutent du début à la fin du cas d’utilisation
Description textuelle d’un scénario :
Titre
Résumé
Acteurs
Date de création / Date de MAJ / Auteur
Pré-conditions
Scénario nominal
Enchaînements alternatifs
Enchaînements d’exception
Post-conditions

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 1 : Station Service

Soit un système informatique qui gère une station-service :


Le client peut utiliser des pompes manuelles et payer à la caisse
du gérant ou utiliser des pompes automatiques.
Le gérant de la station utilise le système informatique pour ses
opérations de gestion (particulièrement le bilan des opérations de
vente d’essence).
Le gérant peut se servir de l’essence pour sa voiture.
La station-service a un petit atelier d’entretien de véhicules. Le
gérant est aussi mécanicien.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 1 : Station Service

1 Que pensez-vous du diagramme présenté ci-dessous ?


2 Faites le diagramme des cas d’utilisation concernant le gérant

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 1 : Station Service

Réponse 1 :

Ce schéma n’est pas un diagramme de cas d’utilisation.

Il correspond à peu près à un diagramme d’activités (il faudrait orien-


ter les liaisons) : il décrit la séquence des actions effectuées par le
client. De plus, il fusionne deux usages : prendre de l’essence (ce qui
se fait à la pompe) et payer (ce qui se fait à la caisse).

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 1 : Station Service


Réponse 2 :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 2 : Cas d’utilisation

Dans un établissement scolaire on désire gérer la réservation des salles


de cours ainsi que du matériel pédagogique (ordinateur portable et/ou
vidéo projecteur). Seuls les enseignants sont habilités à effectuer des
réservations (sous réserve de disponibilité de la salle ou du matériel).

Le planning des salles peut quant à lui être consulté par tout le monde
(enseignants et étudiants). Par contre, le récapitulatif horaire par en-
seignant (calculé à partir du planning des salles) ne peut être consulté
que par les enseignants.

En fin, il existe pour chaque formation un enseignant responsable qui


peut éditer le récapitulatif horaire pour l’ensemble de la formation.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 2 : Cas d’utilisation

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 3 : DAB

On considère le système suivant de gestion d’un DAB :


Le distributeur délivre de l’argent à tout porteur de carte bancaire
Pour les clients de la banque, il permet :
la consultation du solde du compte
le dépôt d’argent (chèque ou numéraire)
Toute transaction est sécurisée et nécessite par conséquent une
authentification
Dans le cas où une carte est "avalée" par le distributeur, un opéra-
teur de maintenance se charge de la récupérer. C’est la même per-
sonne qui collecte également les dépôts d’argent et qui recharge
le distributeur.
Modéliser cette situation par un diagramme de cas d’utilisation

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 3 : DAB
Réponse : Client et carte

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 3 : DAB
Réponse : Opérateur de maintenance

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 4 : Magasin 1

Dans un magasin, un commerçant dispose d’un système de gestion de


stock d’articles, dont les fonctionnalités sont les suivantes :
Édition de la fiche d’un fournisseur
Possibilité d’ajouter un nouvel article (dans ce cas, la fiche four-
nisseur est automatiquement éditée. Si le fournisseur n’existe pas,
on peut alors le créer)
Affichage de l’inventaire. Depuis cet écran, on a le choix d’im-
primer l’inventaire, d’effacer un article ou d’éditer la fiche d’un
article)
Modéliser cette situation par un diagramme de cas d’utilisation

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 4 : Magasin 1 (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 5 : Magasin 2

Dans un magasin, le processus de vente est le suivant : le client entre,


passe les rayons, demande éventuellement des renseignements ou pro-
cède à des essais, prend (décide d’acheter) des articles (si le stock est
suffisant), passe à la caisse où il règle ses achats (en liquide ou chèque
ou carte). Il peut éventuellement bénéficier d’une réduction.

Modéliser cette situation par un diagramme de cas d’utilisation

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 5 : Magasin 2 (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercices pratiques

A l’aide d’un logiciel de modélisation, représenter le diagramme de


cas d’utilisation de :
Installation logiciels Visual Paradigme et StarUml (30 min)
Exercice 2 DCU : Réservation des salles de classe (Ensemble)
Exercice 4 DCU : Magasin 1 (30 min)
Exercice 5 DCU : Magasin 2 (25 min)
Merci de nommer les projets exactement comme ci-haut et les enre-
gistrer dans un même dossier

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme d’activité

Les diagrammes d’activités permettent de déterminer des traitements


a priori séquentiels. Ils offrent un pouvoir d’expression très proche
des langages de programmation objet : spécification des actions de
base (déclaration de variables, affectation etc.), structures de contrôle
(conditionnelles, boucles), ainsi que les instructions particulières à la
programmation orientée objet (appels d’opérations, exceptions etc.).

Ils sont donc bien adaptés à la spécification détaillée des traitements


en phase de réalisation.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Une action : D.A

Une action est le plus petit traitement qui puisse être exprimé en UML.
Elle a une incidence sur l’état du système ou en extrait une information.

Ce sont des étapes discrètes à partir desquelles se construisent les com-


portements. La notion d’action est à rapprocher de celle d’instruction
élémentaire d’un langage de programmation comme C++ ou Java.

Par exemple, une action peut être : - la création d’un nouvel objet ou
lien - l’émission d’un signal - une affectation de valeur à des attributs
- la réception d’un signal - un calcul arithmétique simple etc.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Types d’actions : D.A

Action appeler (Call Operation) : elle correspond à l’invocation


d’une opération sur un objet de manière synchrone (qui a lieu
en même temps) ou asynchrone. Lorsque l’action est exécutée,
les paramètres sont transmis à l’objet cible. Si l’appel est asyn-
chrone, l’action est terminée et les éventuelles valeurs de retour
seront ignorées. Lorsque l’appel est synchrone, l’appelant est blo-
qué pendant l’exécution de l’opération et les valeurs de retour, s’il
y en a, pourront être réceptionnées.
Action comportement (Call Behaviour) : C’est une variante de
l’action Call Operation car elle invoque directement une ac-
tivité plutôt qu’une opération. Elle correspond à l’invocation
d’un comportement spécifié à l’aide d’un diagramme UML, par
exemple un diagramme d’activités ou d’interactions.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Types d’actions : D.A

Action envoyer (Send) : Cette action crée un message et le trans-


met à un objet cible, où elle peut déclencher un comportement.
Elle correspond à des appels asynchrones correspondant à des en-
vois de messages asynchrones : l’appelant poursuit son exécution
sans attendre que l’entité cible ait bien reçu le message.
Action accepter événement (Accept Event) : L’exécution de cette
action interrompt l’exécution en cours jusqu’à la réception du
type d’événement spécifié, qui est généralement un signal. Cette
action est utilisée pour la réception de signaux asynchrones.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Types d’actions : D.A

Action accepter appel (Accept Call) et action répondre (Re-


ply) : L’action accept call est une variante de Accept Event pour
les appels synchrones. L’action Répondre permet de transmettre
un message en réponse à la réception d’une action de type Accept
Call. Les actions accept call et reply peuvent être utilisées du côté
récepteur pour décomposer la réception de l’appel. Reply corres-
pond précisément au return des langages de programmation.
Action créer (Create) : Cette action permet d’instancier (dupli-
quer) un objet.
Action détruire (destroy) : Cette action permet de détruire un
objet.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemples d’actions : D.A

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Une activité : D.A

Une activité définit un comportement décrit par une série organisée


d’unités dont les éléments simples sont les actions. Le flot d’exécu-
tion est modélisé par des nœuds reliés par des arcs. Une activité est un
comportement et peut comporter des paramètres en entrée ou en
sortie, ainsi que des variables locales au même titre qu’une opération.

Une activité peut regrouper des nœuds et des arcs, c’est ce qu’on peut
appeler "groupe d’activités". Un diagramme d’activité est lui-même un
groupe d’activités.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les Nœuds : D.A

Il existe plusieurs types de nœuds dans un Diagramme d’Activités :


Nœud d’activité : c’est un type d’élément abstrait qui permet de
représenter les étapes le long du flot d’activité. On observe trois
types de nœuds d’activité :
les nœuds d’exécution (executable node)
les nœuds d’objet (object node)
les nœuds de contrôle (control nodes)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Nœuds d’exécution

Un nœud exécutable est un nœud d’activité qui donne lieu à une exé-
cution d’actions. On trouve également le nœud d’action qui est un
nœud d’activité exécutable qui constitue l’unité fondamentale de fonc-
tionnalité exécutable dans une activité.

Lorsqu’une action est exécutée, une transformation ou un calcul quel-


conque sont mis en place dans le système modélisé. En général, les
actions sont liées à des opérations qui sont directement appelées. De
plus, un nœud d’action doit avoir au moins un arc entrant.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Nœuds de contrôle
Un nœud de contrôle est un nœud d’activité abstrait utilisé pour
coordonner les flots entre les nœuds d’une activité.
nœud initial (initial node) : à partir duquel le flot débute lorsque
l’activité enveloppante est invoquée
nœud de fin d’activité(final node) : possédant un ou plusieurs arcs
entrants et aucun arc sortant
nœud de fin de flot (flow final)
nœud de décision (decision node) : permet de faire un choix entre
plusieurs flots sortants
nœud de fusion (merge node) : rassemblant plusieurs flots alter-
natifs entrants en un seul flot sortant.
nœud de bifurcation (fork node) : sépare un flot ou plusieurs flots
concurrents
nœud d’union (join node) : synchronise des flots multiples
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Exemple de D.A (Borne bancaire)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemple de D.A (Borne bancaire)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemple de D.A (prise de commande)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Nœuds d’objet

Un nœud d’objet permet de définir un flot de données dans un dia-


gramme d’activités. Plusieurs éléments sont à étudier sur un nœud
d’objet :
Pins d’entrée et de sortie
Pin de valeur
Flot de données (ou flot d’objet)
Nœud tampon central
Nœud d’activité structurée
Structure de contrôle
Partitions

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Pins d’entrée et de sortie

Pour exprimer les valeurs passées en argument à une activité ainsi


que les valeurs de retour, il faut utiliser des nœuds d’objet appelés
pins d’entrée ou de sortie. L’activité ne peut commencer uniquement
lorsqu’une valeur est affectée à chacun de ses pins de sortie. Un pin
est représenté par un petit carré attaché à la bordure d’une activité.

Il peut contenir des flèches indiquant sa direction (entrée ou sortie) si


l’activité ne permet pas de le déterminer de manière univoque.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Pins d’entrée et de sortie

Un pin de valeur est un pin d’entrée qui fournit une valeur à une
action sans que cette valeur ne provienne d’un arc de flot d’objet.

Il est toujours associé à une valeur spécifique. Graphiquement, il


est représenté de la même manière qu’un pin d’entrée avec la valeur
associée écrite à proximité.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Flot de données (ou flot d’objet)

Il permet de passer des données d’une activité à une autre. Un arc


reliant un pin de sortie à un pin d’entrée est un flot d’objet. Dans
cette situation, le type de pin récepteur doit être identique ou parent du
type du pin émetteur.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Nœud tampon central


C’est un nœud d’objet qui accepte les entrées de plusieurs nœuds
d’objet ou produit des sorties vers plusieurs nœuds d’objet. Les
flots en provenance d’un nœud tampon central ne sont donc pas di-
rectement connectés à des actions. Ce nœud modélise un tampon
traditionnel qui peut contenir des valeurs venant de diverses sources
et livrer des valeurs vers différentes destinations.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Nœud tampon central

Il existe également un autre type de nœud tampon central appelé "Nœud


de stockage données (data store node). Quand un flux sortant sélec-
tionne une information, l’information est reproduite et elle ne se sup-
prime pas du nœud de stockage des données comme ce qui se passe
dans un nœud tampon central. Lorsque un flux entrant sélectionne une
donnée déjà stockée , cette donnée est supprimée par une nouvelle.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Nœud tampon central

Après avoir recruté le personnel, il est stocké dans le nœud de stockage


des données de façon permanente, appelé dans ce cas "Base de données
du Personnel". Ceux qui n’ont pas été affectés sont disponibles pour
être affectés par l’activité "Affecter personnel". L’étiquette "selection :
[Link]=null" permet de sélectionner ceux qui n’ont pas
été affectés.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Nœud d’activité structurée

Un nœud d’activité structurée est un espace de nom et une spéciali-


sation d’un groupe d’activités et d’un nœud d’activité exécutable.
C’est une partie structurée d’une activité qui ne présente aucun autre
nœud structuré.

Dans le même nœud d’activité structurée, les transitions doivent avoir


leurs nœuds source et cible. Les arcs et les nœuds doivent être pré-
sents dans un seul et unique nœud d’activité structuré. De plus,
c’est uniquement lorsque toutes les données d’entrée sont disponibles
que l’activité structurée peut s’activer. Enfin, le flux a la possibilité de
quitter l’activité quand toutes les actions de l’activité structurée se ter-
minent.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Nœud d’activité structurée


Voici un schéma représentant un nœud d’activité structurée :

Un nœud structuré est identifié par la dénomination "strutured" et par


un nom qui décrit le comportement modélisé dans l’activité structurée.
Comme sur le schéma ci-dessus, le contour du nœud est en pointillé
et une ligne continu sépare le nœud structuré de l’activité structu-
rée.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Structure de contrôle

Différents types de nœud d’activité structurée :


Nœud de séquence : garantit l’exécution d’un certain nombre
d’activités réalisées en séquence dans un ordre établi en amont
Nœud conditionnel : représente le choix exclusif d’une activité
parmi un certain nombre d’activités alternatives
Nœud de boucle "loop" : représente une structure de contrôle en
boucle présentant une partie d’initialisation, une partie de test et
une partie correspondant au corps de la boucle

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Structure de contrôle

Différents types de nœud d’activité structurée :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Partitions

Les partitions sont aussi des éléments essentiels dans un D.A. En ef-
fet, elles sont appelées couloirs ou lignes d’eau. Elles ont pour but
d’organiser les noeuds d’activités disposés dans un D.A par le biais de
regroupements.

Ce sont des unités d’organisation du modèle. Ces partitions sont utiles


lorsqu’on doit désigner la classe responsable qui rassemble un en-
semble de tâches par exemple. La classe en question est donc respon-
sable du comportement des nœuds à l’intérieur de la partition précé-
demment évoquée.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Partitions

Graphiquement, les partitions sont représentées par des lignes conti-


nues. Elles peuvent prendre la forme d’un tableau. De plus, les nœuds
d’activités doivent appartenir à une seule et unique partition et les
transitions peuvent passer à travers les frontières des partitions.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Partitions

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Partitions : ou alors :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Partitions multidimensionnelles

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 6 : La mousse au chocolat

Commencer par casser le chocolat en morceaux, puis le faire fondre.


En parallèle, casser les œufs en séparant les blancs des jaunes.
Quand le chocolat est fondu, ajouter les jaunes d’œufs
Battre les blancs en neige jusqu’à ce qu’ils soient bien fermes.
Les incorporer délicatement à la préparation chocolat sans les bri-
ser.
Verser dans des ramequins individuels.
Mettre au frais au moins 3 heures au réfrigérateur avant de servir.
Question : Représentez par un diagramme d’activité la recette de
la mousse au chocolat !

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 6 : Solution

Le diagramme d’activité est donné par la figure suivante. Nous suppo-


sons avoir des ressources illimitées, nous parallélisons donc au maxi-
mum. Les barre d’embranchement (fork) et de jointure (join) per-
mettant de représenter précisément le parallélisme dans les flots de
contrôle de l’activité. Enfin, l’action "Attendre 3h" est de type Accept
time event.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 6 : Solution

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 7 : DAB 2

Décrire le fonctionnement d’un DAB. Le client introduit sa carte dont


la validité est immédiatement vérifiée. Il est ensuite invité à saisir le
code de la carte. Après trois tentatives infructueuses, la carte est avalée.
Sinon le client peut indiquer le montant qu’il désire retirer, le solde de
son compte bancaire est alors consulté pour s’assurer que le retrait est
possible. En cas de solde insuffisant, le client en est informé et peut
alors saisir un montant inférieur. Si le solde du compte est suffisant,
le distributeur restitue la carte et délivre alors les billets accompagnés
d’un reçu.

Travail à faire : Établir le diagramme d’activités (Vous avez 30


minutes !)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 7 : DAB 2 (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 7 : OU (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 8 : Agence de voyage

Une agence de voyage organise des voyages, gère le transport, l’hé-


bergement et offre la possibilité à ses clients de disposer d’un taxi à
l’arrivée du voyage pour se rendre à l’hôtel.

Travail à faire : Établir le diagramme d’activités décrivant tous


les scénarios pour le cas d’utilisation "Transport" (Vous avez 20
minutes !)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 8 : Agence de voyage (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 9 : Connexion Telnet

Décrire la connexion d’un client à un serveur telnet. On considère le


client, le démon telnet (serveur logiciel) et la machine serveur. Une
fois la connexion établie entre le client et le serveur, le démon demande
un mot de passe au client, ce dernier dispose de trois tentatives avant
que la connexion ne soit rompue. Les tentatives infructueuses sont en-
registrées dans un fichier sur le serveur. Une fois l’identification faite,
un terminal est ouvert et l’utilisateur peut alors saisir des commandes
qui sont interprétées par le démon et exécutées sur le serveur. La com-
mande exit déconnecte le client du serveur.

Travail à faire : Établir le diagramme d’activités (Vous avez 20


minutes !)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 9 : Connexion Telnet (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 9 : Connexion Telnet (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 10 : financement et lancement d’un projet


Quand un distributeur a un projet d’aménagement ou d’extension de
ses équipements, il doit obtenir l’aval du siège, qui se traduit par sa
participation au financement de l’opération. Une fois établi, le dossier
de projet est donc soumis simultanément à la banque et au siège, qui
répond très rapidement.
Si le siège est défavorable, le projet est abandonné et la banque
est prévenue.
Si le siège accepte de co-financer le projet, on attend la réponse
de la banque pour décider de poursuivre ou de réétudier le
dossier.
Quand les deux réponses sont positives, un dossier de financement dé-
finitif est établi puis le projet est lancé.

Travail à faire : Établir de diagramme d’activités correspondant


au processus de financement et de lancement d’un projet. (TP)
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Exercices pratiques

A l’aide d’un logiciel de modélisation, représenter le diagramme d’ac-


tivité de :
Exercice 7 DA : DAB 2 (Ensemble)
Exercice 9 DA : Connexion Telnet (45 min)
Exercice 10 DA : TP à remettre lundi (1ère question).
Merci de nommer les projets exactement comme ci-haut et les enre-
gistrer dans un même dossier

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Collaboration (interactions)

Un objet interagit pour implémenter un comportement. On peut dé-


crire cette interaction de deux manières complémentaires :
l’une est centrée sur des objets individuels (diagramme d’états-
transitions) et
l’autre sur une collection d’objets qui coopèrent (diagrammes
d’interaction) qui contient à son tour le Diagramme de Com-
munication ou de Collaboration et le Diagramme de Séquences.
La spécification d’un diagramme d’états-transitions est précise et conduit
immédiatement au code. Elle ne permet pas pour autant d’expliquer le
fonctionnement global d’un système, car elle se concentre sur un seul
objet à la fois. Un diagramme d’interaction permet d’offrir une vue
plus claire et totale du comportement d’un jeu d’objets.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme Diagramme de Collaboration (interactions)

Le diagramme de communication est un diagramme d’interaction


mettant l’accent sur l’organisation structurelle des objets qui envoient
et reçoivent des messages. Le diagramme de séquence est un dia-
gramme d’interaction mettant l’accent sur la chronologie de l’envoi
des messages.

Pour produire un diagramme d’interaction, il faut focaliser son atten-


tion sur un sous-ensemble d’éléments du système et étudier leur façon
d’interagir pour décrire un comportement particulier. UML permet de
décrire un comportement limité à un contexte précis de deux façons :
dans le cadre d’un classeur structuré ou
dans celui d’une collaboration

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

D. Col. : Classeur structuré


Exemple de classeur structuré montrant qu’un classeur Moteur est en
fait constitué d’un Allumage et de quatre Bougies.

Un D. Col. : classeur structuré est la description de la structure d’im-


plémentation interne d’une classe. Graphiquement, il se représente par
un rectangle en trait plein comprenant deux compartiments. Le
haut contient le nom du classeur et le bas montre les parties internes
reliées par des connecteurs
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Diagramme de Collaboration (Interactions)


Diagramme de collaboration d’une transaction immobilière.

Une collaboration permet de décrire la mise en œuvre d’une fonc-


tionnalité par un jeu de participants. Un rôle est la description d’un
participant. Contrairement aux paquetages et aux classeurs structu-
rés, une collaboration ne détient pas les instances liées à ses rôles. Une
collaboration peut donc traverser plusieurs niveaux d’un système et un
même élément peut apparaître dans plusieurs collaborations.
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Diagramme de Collaboration (Interactions)

Par exemple, pour implémenter un cas d’utilisation, il faut utiliser un


ensemble de classes, et d’autres éléments, fonctionnant ensemble pour
réaliser le comportement de ce cas d’utilisation. Cet ensemble d’élé-
ments, comportant à la fois une structure statique et dynamique, est
modélisé en UML par une collaboration.

Graphiquement, une collaboration se représente par une ellipse en trait


pointillé comprenant deux compartiments. Le compartiment supé-
rieur contient le nom de la collaboration et le compartiment inférieur
montre les participants à la collaboration

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Interactions et lignes de vie


Partant d’un Diagramme de classe d’un système de pilotage

Voici le Diagramme de communication correspondant :

Voici le Diagramme de séquence correspondant :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Collaboration (Interactions)

UML propose principalement deux diagrammes pour illustrer une in-


teraction : le diagramme de communication (collaboration) et celui
de séquence. Une même interaction peut être présentée aussi bien par
l’un que par l’autre.

À ces deux diagrammes, UML 2.0 en ajoute un troisième : le dia-


gramme de timing. Son usage est limité à la modélisation des sys-
tèmes qui s’exécutent sous de fortes contraintes de temps, comme les
systèmes temps réel.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Collaboration (Interactions)

Un diagramme d’interaction se représente par un rectangle contenant,


dans le coin supérieur gauche, un pentagone accompagné du mot-
clef sd lorsqu’il s’agit d’un diagramme de séquence et com lorsqu’il
s’agit d’un diagramme de communication.

Le mot-clef est suivi du nom de l’interaction. Dans le pentagone, on


peut aussi faire suivre le nom par la liste des lignes de vie impliquées,
précédée par le mot-clef lifelines. Enfin, des attributs peuvent être in-
diqués dans la partie supérieure du rectangle contenant le diagramme.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Communication (Interactions)

Diagramme de communication illustrant la recherche puis l’ajout, dans


son panier virtuel, d’un livre lors d’une commande sur Internet.

Contrairement à un DS, un DC rend compte de l’organisation spatiale


des participants à l’interaction, il est souvent utilisé pour illustrer un ca
d’utilisation ou pour décrire une opération.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de communication (Interactions)

Les lignes de vie sont représentées par des rectangles contenant une
étiquette dont la syntaxe est :

[<nom_du_rôle>] : [<Nom_du_type>]

Au moins un des deux noms doit être spécifié dans l’étiquette, les deux
points ( :) sont, quant à eux, obligatoires.

Les relations entre les lignes de vie sont appelées connecteurs et se


représentent par un trait plein reliant deux lignes de vie et dont les
extrémités peuvent être ornées de multiplicités.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de communication (Interactions)

Dans un diagramme de communication, les messages sont générale-


ment ordonnés selon un numéro de séquence croissant. Un message
est, habituellement, spécifié sous la forme suivante :

[’[’<cond>’]’[<séq>][*[||][’[’<iter>’]’]] :][<var> :=]<msg>([<par>])

<cond> : condition sous forme d’expression booléenne.


<séq> : numéro de séquence du message.
<iter> : envoi séquentiel de plusieurs messages.
<var> : valeur de retour du message.
<msg> : le nom du message.
<par> : les paramètres (optionnels) du message.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de communication (Interactions)

Cette syntaxe un peu complexe permet de préciser l’ordonnancement


et la synchronisation des messages entre les objets du diagramme
de communication. La direction d’un message est spécifiée par une
flèche pointant vers l’un ou l’autre des objets de l’interaction, reliés
par ailleurs avec un trait continu (connecteur).

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de séquences (Interaction diagram)


Décrit le comportement d’un scénario
Contient des objets et les messages transmis entre ces objets (re-
présenté par une barre verticale)
Indique explicitement le temps (de haut en bas)
Adapté aux systèmes temps réel et aux scénarios complexes

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemple Diagramme de séquences

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dialogue entre les objets (D.S)


Plusieurs types de messages (actions) entre les acteurs et objets.
message simple : le message n’a pas de spécificité particulière
d’envoi et de réception.
message à durée de vie : l’expéditeur attend une réponse du ré-
cepteur pendant un certain temps et reprend ses activités si aucune
réponse n’a lieu dans un délai prévu.
message synchrone : l’expéditeur est bloqué jusqu’au signal de
prise en compte par le destinataire. Les messages synchrones sont
symbolisés par des flèches barrées.
message asynchrone : le message est envoyé, l’expéditeur conti-
nue son activité que le message soit pris en compte ou non. Les
messages asynchrones sont symbolisés par des demi-flèches.
message dérobant : le message est mis en attente dans une liste
d’attente de traitement chez le récepteur.
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Dialogue entre les objets (D.S)

Messages synchrones et asynchrones

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dialogue entre les objets (D.S)

Graphiquement, un message synchrone se représente par une flèche


en traits pleins et à l’extrémité pleine partant de la ligne de vie d’un
objet expéditeur et allant vers celle de l’objet cible. Ce message peut
être suivi d’une réponse qui se représente par une flèche en pointillé.

Un message asynchrone se représente par une flèche en traits pleins et


à l’extrémité ouverte partant de la ligne de vie d’un objet expéditeur et
allant vers celle de l’objet cible

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dialogue entre les objets (D.S)

Messages synchrones et asynchrones

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Messages de création et destruction d’instance

La création d’un objet est matérialisée par une flèche qui pointe sur
le sommet d’une ligne de vie.
La destruction d’un objet est matérialisée par une croix qui marque
la fin de la ligne de vie de l’objet.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Événements et messages

A travers ces différents évènements correspondant à un message asyn-


chrone, UML permet de séparer clairement l’envoi du message, sa ré-
ception, ainsi que le début de l’exécution de la réaction et sa fin
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Syntaxe des messages et des réponses

Dans la plupart des cas, la réception d’un message est suivie de l’exé-
cution d’une méthode d’une classe. Cette méthode peut recevoir des
arguments et la syntaxe des messages permet de transmettre ces argu-
ments.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Syntaxe des messages et des réponses


La syntaxe de ces messages est la même que pour un diagramme de
communication excepté deux points :
la direction du message est directement spécifiée par la direc-
tion de la flèche qui matérialise le message, et non par une flèche
supplémentaire au-dessus du connecteur reliant les objets comme
c’est le cas dans un diagramme de communication ;
les numéros de séquence sont généralement omis puisque l’ordre
relatif des messages est déjà matérialisé par l’axe vertical qui re-
présente l’écoulement du temps.
La syntaxe de réponse à un message est la suivante :

[<attribut> = ] message [ : <valeur_de_retour>]

où message représente le message d’envoi.


Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Message perdu et trouvé

Un message complet est représenté par une simple flèche dirigée


de l’émetteur vers le récepteur.
Un message perdu est tel que l’événement d’envoi est connu,
mais pas l’événement de réception, représenté par une flèche qui
pointe sur une petite boule noire.
Un message trouvé est tel que l’événement de réception est connu,
mais pas l’événement d’émission. Une flèche partant d’une petite
boule noire le représente.
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Messages retours implicites et explicites

Le retour d’un message synchrone peut ne pas être représenté, le


retour est alors implicite. Par contre, dans le cas d’un message asyn-
chrone, il est impératif de faire apparaître le message de retour.

Le retour est explicite. Bien entendu, si l’exécution de la méthode lan-


cée par le message asynchrone ne doit rien retourner, il est évident que
nous ne devons pas représenter le message de retour (c’est générale-
ment le cas le plus classique, notamment avec la gestion événemen-
tielle).

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Messages retours implicites et explicites

Les 3 diagrammes suivants sont équivalents

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Recouvrement des bandes d’activations et message récursif

Lorsqu’un objet est déjà activé il peut quand même recevoir d’autres
messages (appel d’une autre de ses méthodes), cela se représente par
un dédoublement de la bande d’activation.

Un objet peut s’envoyer un message à lui-même (utilisation d’une


autre méthode du même objet). Cela se représente là aussi par un
dédoublement de la bande d’activation.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Messages retours implicites et explicites

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exécution de méthode et objet actif


Représentation d’un objet actif (à gauche) et d’une exécution sur un
objet passif (à droite).

Un objet actif initie et contrôle le flux d’activités. Graphique-


ment, la ligne pointillée verticale d’un objet actif est remplacée
par un double trait vertical .
Un objet passif, au contraire, a besoin qu’on lui donne le flux
d’activité pour pouvoir exécuter une méthode. La spécification de
l’exécution d’une réaction sur un objet passif se représente par un
rectangle blanc ou gris placé sur la ligne de vie en pointillé
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Exécution de méthode et objet actif

Représentation d’une exécution simultanée (à gauche).

Les deux sur une même ligne de vie sont représentées par un rectangle
chevauchant comme le montre la figure ci-haut

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Fragments d’interaction combinés

Un fragment d’interactions combiné est une partie du diagramme de


séquence (délimitée par un rectangle) associée à une étiquette (dans
le coin supérieur gauche). L’étiquette contient un opérateur d’interac-
tion qui permet de décrire des modalités d’exécution des messages à
l’intérieur du cadre.

Il y en a en tout une douzaine. Les opérandes d’un opérateur d’in-


teraction sont séparés par une ligne pointillée. Les conditions de choix
des opérandes (éventuels) sont données par des expressions booléennes
entre crochets ([ ]).

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Fragments d’interaction combinés

La liste suivante regroupe les opérateurs d’interaction par fonctions :


les opérateurs de choix et de boucle : alternative, option, break et
loop ;
les opérateurs contrôlant l’envoi en parallèle de messages : paral-
lel et critical region ;
les opérateurs contrôlant l’envoi de messages : ignore, consider,
assertion et negative ;
les opérateurs fixant l’ordre d’envoi des messages : weak sequen-
cing , strict sequencing.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur ALT

L’opérateur alternative, ou alt, est un opérateur conditionnel possé-


dant plusieurs opérandes (figure suivante). C’est un peu l’équivalent
d’une exécution à choix multiple (condition switch en C++).

Chaque opérande détient une condition de garde. L’absence de condi-


tion de garde implique une condition vraie (true). La condition else est
vraie si aucune autre condition n’est vraie. Exactement un opérande
dont la condition est vraie est exécuté. Si plusieurs opérandes prennent
la valeur vraie, le choix est non déterministe.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur ALT
Représentation d’un choix dans un diagramme de séquence illustrant
le découvrement d’une case au jeu du démineur.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur ALT

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur par

Un fragment combiné de type parallel, ou par, possède au moins deux


sous-fragments exécutés simultanément (figure suivante). La concur-
rence est logique et n’est pas nécessairement physique : les exécutions
concurrentes peuvent s’entrelacer sur un même chemin d’exécution
dans la pratique.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur par

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur par

Microwave est un exemple d’objet effectuant deux tâches en parallèle.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur strict

Un fragment combiné de type strict sequencing, ou strict, possède


au moins deux sous-fragments. Ceux-ci s’exécutent selon leur ordre
d’apparition au sein du fragment combiné. Ce fragment combiné est
utile surtout lorsque deux parties d’un diagramme n’ont pas de ligne
de vie en commun (figure suivante).

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur strict

Procédures de décollage d’un avion dans l’ordre.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur loop

Le fragment loop (opérateur d’itération) permet de répéter ce qui se


trouve en son sein. On peut spécifier entre crochets à quelle condition
Les fragments peuvent s’imbriquer les uns dans les autres
On peut émettre des messages réflexifs et dans ce cas, on définit
une activité “dans” l’activité
Lorsqu’on décrit une opération dans le détail, il est permis de pla-
cer des commandes sur les flèches au lieu de messages correspon-
dant à des opérations ou des signaux.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur loop

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur loop
Découvrement d’une case au jeu du démineur.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Opérateur opt

L’opérateur option (opt) comporte un opérande et une condition de


garde associée. Le sous-fragment s’exécute si la condition de garde est
vraie et ne s’exécute pas dans le cas contraire.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de séquences DAB

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

D. de collaboration / D. de séquence
A quel Diagramme de séquence correspond ce diagramme de collabo-
ration ?

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

D. de collaboration / D. de séquence

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de séquences DAB

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de séquences DAB

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 11 : Ascenseur
Contrôler N ascenseurs dans un gratte-ciel de M étages :
1 Chaque ascenseur possède au moins un bouton pour chaque étage,
s’allume lorsqu’il est appuyé et provoque le déplacement de l’as-
censeur vers l’étage correspondant.
2 Chaque étage, sauf le premier et le dernier, possède deux bou-
tons (montée et descente). Ils s’allument lorsqu’ils sont appuyés
et s’éteignent quand l’ascenseur arrive à l’étage.
3 Quand un ascenseur n’est pas requis, il reste à l’étage où il se
trouve et ferme ses portes.
Décrire à l’aide d’un diagramme de séquence :
requête d’ascenseur depuis l’étage
requête d’étage depuis l’ascenseur

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 11 : Ascenseur (Solution)


Réponse : Scenario requête d’ascenseur depuis l’étage

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 11 : Ascenseur (Solution)


Réponse : Scenario requête d’étage depuis l’ascenseur

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 12 : Caisse

Le déroulement normal d’utilisation d’une caisse de supermarché est


le suivant :
un client arrive à la caisse avec ses articles à payer
le caissier enregistre chaque article, ainsi que la quantité (si elle
est supérieure à 1)
la caisse affiche le prix de chaque article et son libellé
lorsque tous les achats sont enregistrés, le caissier signale la fin
de la vente
la caisse affiche le total des achats
le caissier annonce au client le montant total à payer
le client choisit son mode de paiement

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 12 : Caisse

liquide : le caissier encaisse l’argent, la caisse indique le montant


à rendre au client
chèque : le caissier note le numéro de pièce d’identité du client
carte de crédit : la demande d’autorisation est envoyée avant la
saisie
la caisse enregistre la vente et l’imprime
le caissier donne le ticket de caisse au client

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 12 : Caisse (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 13 : Magasin fleurs


Le client demande au vendeur des renseignements sur les compo-
sitions florales
Le vendeur lui fournit toutes les informations nécessaires
Le client commande alors la composition de son choix et le ven-
deur émet le bon de fabrication qu’il transmet à son ouvrier fleu-
riste.
Le vendeur édite ensuite la facture correspondante.
L’ouvrier fleuriste crée la composition puis archive le bon de fa-
brication
Il remet alors la composition au vendeur
La facture est remise au client pour règlement une fois le bouquet
réalisé
le client récupère sa composition et quitte le magasin.
Modéliser cette situation à l’aide d’un diagramme de séquence et
d’un diagramme de collaboration :
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Exercice 13 : Magasin fleurs (Solution D. Séquences)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 13 : Magasin fleurs (Solution D. Collaboration)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 14 : Entrepôt de Stockage


Le logiciel à produire doit allouer automatique un emplacement pour le
chargement des camions qui convoient le stock à entreposer. Le fonc-
tionnent du système informatique doit être le suivant :
déchargement d’un camion : lors de l’arrivée d’un camion, un
employé doit saisir dans le système les caractéristiques de chaque
article ; le système produit alors une liste où figure un emplace-
ment pour chaque article ;
chargement d’un camion : les caractéristiques des articles à char-
ger dans un camion sont saisies par un employé afin d’indiquer au
système de libérer des emplacements.
Le chargement et le déchargement sont réalisés manuellement.
Travail à Faire : Donner le Diagramme de séquence et celui de colla-
boration pour le cas déchargement d’un camion

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 14 : Diagramme de Collaboration (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 14 : Diagramme de séquences (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 15 : Réception des arrivées


Lorsqu’un chargement arrive, l’employé crée un nouveau bordereau
de réception. Il vérifie et confirme chaque lot constitué d’une certaine
quantité d’un produit donné en entrant sur le bordereau le code du
produit et la quantité livrée.

Le système attribut alors au lot un identifiant et délivre un code barre


et une fiche de destination qui seront collés sur l’emballage.

Lorsque tous les lots seront rentrés, le système compare le bordereau


avec la commande correspondante. S’il trouve des différences, il pro-
duit un rapport d’erreur de livraison, sinon, la commande est vali-
dée et un accusé de réception est délivré au chauffeur.
Proposer un DS pour les deux scénarios (Chargement correct et erreur
de livraison)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 15 : Réception des arrivées (Solution)


Scénario 1 : Erreur de livraison

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 15 : Réception des arrivées (Solution)


Scénario 2 : Chargement correct

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 16 : système de livraison express à domicile


On s’intéresse à une société de livraison express à domicile. Le service
Clientèle reçoit chaque jour les clients qui désirent une livraison en
France ou à l’étranger. Ce service gère deux catégories de paquets :
les paquets légers ou lettres dont le poids est < à 2 kg,
les paquets lourds ou colis dont le poids est > à 2 kg.
Le tarif est calculé en fonction du poids du colis et de sa destination
avec un forfait de 10 Euros si le client opte pour un envoi avec accusé
de réception. Le service Clientèle enregistre alors les références des
paquets client (coordonnées expéditeur + destinataire, poids, etc.) en
ordinateur et impriment un récépissé pour le client. La facturation des
paquets légers ou à destination de la France sont gérés aussi par ce
service. Le paiement effectué, le service transmet le paquet au service
Logistique pour l’acheminement.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 16 : système de livraison express à domicile

Les paquets lourds, à destination de l’international, doivent respecter


la réglementation douanière et doivent donc faire l’objet de démarches
plus lourdes qui rallongent leur délai d’acheminement de 48h au moins
et sont sur-facturés de 10%. En particulier, le client doit remplir et si-
gner une liasse de transport qui précise la nature et la valeur du contenu
du (ou des) paquets à acheminer. Le paquet, accompagné de ce docu-
ment, est transmis au service Export de l’entreprise.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 16 : système de livraison express à domicile

Les paquets dont le poids dépasse les 20kg ou, dont le contenu est
répertorié dans une liste de marchandises bien définie par la réglemen-
tation douanière, doivent subir des formalités avec les douanes Fran-
çaises, en liaison avec le service Export. Le paquet ne peut être ache-
miné avant accord des douanes qui se matérialise par un bordereau
avec les références du paquet à acheminer et le montant de la taxe à la
charge du client.

Le service Export de l’entreprise transmet alors l’information au ser-


vice de facturation. Celui-ci émet ensuite la facture finale à destination
du client. Après règlement, le service Export en est informé et transmet
le paquet avec le bordereau des douanes au service Logistique qui se
charge de la livraison.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 16 : système de livraison express à domicile

Travail demandé :
1 Donner le diagramme des cas d’utilisation qui décrit le
fonctionnement de cette société.
2 Décrire le scénario principal déclenché par le service Clientèle
par un diagramme de séquence (Ne faire que le Diagramme de
séquence du scénario "Gestion d’une lettre ou d’un colis
national")
Premier travail à domicile : à faire dans la journée de dimanche
(comptabilisé)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 16 : Système de livraison (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 16 : Système de livraison (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 16 : Système de livraison (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercices pratiques

A l’aide d’un logiciel de modélisation, représenter le diagramme de


séquences de :
Exercice 11 DS : Ascenseur (45 min)
Exercice 12 DS : Caisse (30 min)
Exercice 13 DC : Magasin fleurs DC(30 min)
Exercice 13 DS : Magasin fleurs DS(45 min)
Merci de nommer les projets exactement comme ci-haut et les enre-
gistrer dans un même projet car ils seront tous remis

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les axes de modélisation


Il existe trois axes de modélisation sous le principe d’UML et chacun
d’entre eux suppose un ensemble des diagrammes :

Maintenant l’axe statique !

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de classes

Le Diagramme de classes a pour rôles :


Identifier et commencer à organiser les données
Construit à partir des spécifications et du diagramme des cas d’uti-
lisation
Prépare la conception en vue d’une implémentation informatique

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de classes

Objectifs
Décrire les classes d’une application et leurs relations statique

Représentation UML d’une classe


Les instances d’une classe ont les mêmes attributs et opérations
Abstraction : factorisation des caractéristiques communes à une
catégorie d’objets
Une classe décrit une infinité d’instances

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de classes
Rectangle composé de compartiments
classe = décrit un ensemble d’objets
association = un ensemble de liens

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de classes
Rectangle composé des compartiments
Compartiment 1 : Nom de la classe
Compartiment 2 : Attributs
Compartiment 3 : Opérations
Possibilité d’ajouter des compartiments (exceptions, ..)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Classes : stéréotypes et propriétés

Une classe peut contenir un des stéréotypes suivants :


«signal» : occurrence déclenchant une transaction dans un auto-
mate,
«interface» : description des opérations visibles,
«métaclasse» : classe d’une classe,
«utilitaire» : classe réduite au concept de module et ne peut être
instanciée.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Classes : stéréotypes et propriétés

Tout compartiment peut avoir des propriétés représentées par des éti-
quettes

étiquette = paire (attribut, valeur) définie par l’utilisateur :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Classes : Attributs et Opérations

Les attributs et opérations d’une classe peuvent être explicités :


Syntaxe d’un attribut :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Classes : Attributs et Opérations

Les attributs et opérations d’une classe peuvent être explicités :


Syntaxe d’un attribut dérivé :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Classes : Attributs et Opérations


3 niveaux de visibilité des attributs et des opérations :
public : élément visible à tous les clients de la classe (+),
protégé : élément visible aux sous-classes de la classe (#),
privé : élément visible à la classe seule (-).

Les attributs et opération soulignés : visibles


Youen Mushegerha (CT)
globalement dans toute la
Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Classe : les Interfaces


Une interface : fournit une vue totale ou partielle d’un ensemble de
services offerts par un ou plusieurs éléments :

Elles peuvent être représentées au moyen de classes stéréotypés :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Classes abstraites

pas directement instanciables


ne donne pas naissance à des objets
sont utilisées pour une spécifications de typage plus générale
pour manipuler les objets instances d’une (ou plusieurs) de leurs
sous-classes :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemple de classe

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Message

Message : stimulation externe d’un objet par un autre


Les opérations (actions et réactions) sont déclenchées suite à
l’envoi d’un message par un autre objet

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Associations binaires

Les associations peuvent relier des classes non nécessairement


distinctes
représentées par un lien qui peut être nommé (forme active/forme
passive/infinitif)

L’association "porter" est attribuée (attribut "Quantité commandée")

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Associations binaires

lorsque l’association est caractérisée par un attribut, une nouvelle


classe, classe-association sans nom est crée (ici pour l’attribut
Quantité_commandée)
l’extrémité d’un lien associatif est appelé "rôle"
le nommage des roles est possible (lourd si cummulé à celui des
assciations)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Multiplicités

caractérisent les liens associatifs


spécification des multiplicités à l’autre bout de la ligne (inverse
cardinalités Merise)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Comparaison des formalismes UML et Merise


Cardinalités (Merise), multiplicités (UML)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Multiplicités

caractérisent les liens associatifs


spécification des multiplicités à l’autre bout de la ligne (inverse
cardinalités Merise)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Multiplicités

caractérisent les liens associatifs


spécification des multiplicités à l’autre bout de la ligne (inverse
cardinalités Merise)

La notion de multiplicité ne fonctionne plus avec les associations n-


aires.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Associations n-aires : Deux façons !


1. par une classe-association ordinaire (avec losange) :

ici classe-association REALISER reliée par un losange, elle possède


un attribut propre "montant annuel"
A ces classes-associations peuvent être rattachés des attributs et/ou
des opérations propres
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Associations n-aires : Deux façons !

2. par une classe-association stéréotypée :

../pictures/[Link]

ici classe-association Réaliser reliée par un losange, elle possède un


attribut propre "montant annuel"
A ces classes-associations peuvent être rattachés des attributs et/ou
des opérations propres

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemple : commande

Une personne peut passer plusieurs commandes


Une commande est toujours passée par une et une seule personne

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

L’Agrégation

C’est une association non symétrique dans laquelle une extrémité joue
un rôle prédominant sur l’autre et ne peut concerner qu’un seule rôle
de l’association :
une classe fait partie d’une autre classe,
les valeurs d’attributs d’une classe se propagent dans les va-
leurs d’attributs d’une autre classe
une action sur une classe implique une action sur une autre classe,
les objets d’une classe sont subordonnés aux objets d’une autre
classe.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

L’Agrégation

C’est une association non symétrique dans laquelle une extrémité joue
un rôle prédominant sur l’autre et ne peut concerner qu’un seule rôle
de l’association :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Agrégation

Relation "made of" "part of"


Transitive et Antisymétrique
Propagation des propriétés avec modifications locales éventuelles

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Composition

C’est un cas particulier d’agrégation : contenance physique et rela-


tion transitive du type Composé-Composant entre une classe "agrégat"
et une classe "composant" :

Implique une contrainte sur la valeur de la multiplicité du coté de


l’agrégat. Composition et attributs sont sémantiquement équivalents
(notation par attribut ou par composition) :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Composition

Une classe Véhicule est composée par exemple de 2 autres classes, la


Carrosserie et le Moteur qui à son tour est composé des classes Bielle
et Piston

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Composition
Agrégation avec relation d’appartenance forte et coïncidence des
durées de vie
Les composants peuvent être créés après le composite, mais après
création ils ont la même durée de vie
Les composants peuvent être enlevés avant la mort du composite
Chaque composant appartient à, au plus, un composite
Propagation composite vers composant

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemples
Un répertoire contient des fichiers
Une pièce est faite (composée) des murs

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Contraintes sur les associations

Contrainte ordonnée : une relation d’ordre décrit les objets placés


dans la collection : l’ordre doit être maintenu :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Contraintes sur les associations

Contrainte sous-ensemble : une collection est incluse dans une autre


collection :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Contraintes sur les associations

Contrainte ou-exclusif : pour un objet donné, une seule association est


valide :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Restriction des associations (qualification)

Soit une association entre 2 classes A et B, une qualification consiste à


sélectionner un sous-ensemble d’objets parmi l’ensemble des objets
qui participent à une association :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Restriction des associations (qualification)

Est réalisée par un attribut spécifique appelé "clé", représentée sur le


rôle de départ et appartient pleinement à l’association et non aux
classes associées.

combinaison d’une ligne et d’une colonne pour identifier une case de


l’échiquier

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation

Les associations décrivent un réseau de relations structurelles entre


les classes, donnant naissance aux liens entre les objets, instances de
ces classes. Les liens constituent des "canaux de navigation" entre les
objets :
par défaut les associations sont "navigables" dans les 2 sens
dans certains cas un seul sens est possible : celui de la flèche :

L’association entre les classes A et B est seulement navigable de A vers


B

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

Il faut un pseudo-langage pour spécifier les chemins au sein des dia-


grammes de classes. Ce langage définit des expressions servant à pré-
ciser notamment des contraintes.

Règle syntaxique R1 : cible : := ensemble ’.’ sélecteur

Avec :
cible = ensemble d’objet (une classe désigne objets instances de
la classe)
sélecteur = nom d’attribut /d’association /de rôle (opposé sur un
lien) des objets de l’ensemble

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

Exemple :

[Link] désigne tous les enfants d’une personne donnée

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

Règle syntaxique R2 : cible : := ensemble ’.’ ’ ’sélecteur

Avec :
sélecteur = nom de rôle placé du coté de l’ensemble
cible = d’objet obtenu par navigation dans le sens opposé au nom
de rôle

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

Exemple :

UnePersonne. Enfants désigne les parents d’une personne donnée

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

Règle syntaxique R3 : cible : := ensemble ’[’ expression_booléenne’]’

Avec :
expression booléenne : construite à partir des objets de l’en-
semble et des liens et valeurs accessibles par ces objets
cible = d’objets vérifiant cette expression booléenne = sous-ensemble
de l’ensemble de départ

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

Exemple :

L’expression booléenne [Link][âge>=20] désigne tous


les enfants de plus de 20 ans d’une personne donnée

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

Règle syntaxique R4 : cible : := ensemble ’.’ sélecteur ’[’ valeur_de_clé’]’

Avec :
sélecteur = association qui partitionne l’ensemble à partir de la
valeur de la clé
cible = sous-ensemble de l’ensemble défini par l’association
expression booléenne : construite à partir des objets de l’en-
semble et des liens et valeurs accessibles par ces objets
cible = d’objets vérifiant l’expression booléenne = sous-ensemble
de l’ensemble de départ

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins


Exemple : restriction par l’ajout de clés sur l’association, ce qui réduit
la multiplicité :

L’expression [Link][UnPrénom] identifie un enfant


de façon non ambiguë (chaque enfant d’une même famille a un pré-
nom différent)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

Il y a aussi les expressions de pré ou post conditions attachées aux


spécifications des opérations :
1 - association correcte des parents et des enfants :

{UnePersonne = [Link][UnPrénom].(Parent[Mère]
ouParent[Père])}

2 - ou en navigant en sens inverse :

{UnePersonne = [Link][UnPrénom].( Enfant[Mère]


ou Enfant[Père])}

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

La Navigation : spécification des chemins

3 - ou enfin, en posant :

{papa = [Link][Père]}

ET

{papi = UnePersonne.(Parent[Père] ou
(Parent[Mère].Parent[Père]}

Alors

{[Link][Père] = [Link][Père].Parent[Père]}

Comme on dit, le papa de papi est le papi de papa !

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Généralisation

C’est une relation de classification transitive entre une classe plus


générale - super-classe - et une ou plusieurs autres classes plus spé-
cifiques - sous-classes -

Chat, Chien, Lapin sont dites sous-classes de la super-classe Animal

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Généralisation

Les attributs, opérations, relations et contraintes définies dans les


super-classes sont hérités intégralement dans les sous-classes
une classe peut avoir plusieurs super-classes : généralisation
multiple
une généralisation peut être faite selon des critères indépendants :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Généralisation

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Généralisation - Spécification

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Polymorphisme
Un nom d’objet peut désigner des instances de classes différentes
issues d’une même arborescence
L’objet peut réagir différemment à des opérations communes

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Généralisation
chaque sous-classe hérite des caractéristiques (attributs et opéra-
tions) de la surclasse
toute sous-classe peut modifier et/ou ajouter de nouveaux attri-
buts / opérations par rapport à ceux hérités
possibilité de contraintes sur hiérarchies de classes (contraintes
d’intersection/disjonction) :
contrainte Disjoint ou Exclusif : une sous-classe ne peut être sous-
classe que d’une super-classe,
contrainte Chevauchement ou Inclusif : une sous-classe peut être
sous-classe de plusieurs super-classes (généralisation multiple
possible),
contrainte Complete : la généralisation est terminée, plus possible
de rajouter de nouvelles sous-classes,
contrainte Incomplete : il est possible de rajouter de nouvelles
sous-classes :
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Généralisation

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Généralisation

Au niveau des concepts


Relation "is a" ou "a kind of" (Classification)
Généralisation/Spécialisation
Relation entre une classe (super-classe) et une ou plusieurs spé-
cialisations (sous-classes)
Une instance d’une sous-classe est également une instance de la
super-classe
Classe concrète et classe abstraite

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Héritage

Au niveau de la mise en œuvre (programmation orientée objet)


N’est pas la seule technique d’implantation d’une généralisation
Héritage : Relation transitive sur un nombre arbitraire de niveaux
Relation statique à couplage fort

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Hiérarchie de classes et héritage

Les objets de SC héritent des attributs et méthodes de C


On peut redéfinir dans SC une méthode de C (surcharge)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemples

Les modems et les claviers sont des périphériques d’entrée-sortie


Une transaction boursière est un achat ou une vente

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Généralisation et Héritage

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Héritage et réutilisation

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 17 : gestion d’un magasin

Spécification :
Notre magasin stocke des lignes de produits
Chaque ligne de produits contient des articles
Chaque article correspond à une ligne de produits
Diagramme de classes correspondant :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 18 : système de fichiers

Spécification :
Un utilisateur possède au moins un répertoire
Un répertoire appartient à un et un seul utilisateur
Un répertoire peut contenir d ’autres répertoires
Un utilisateur peut accéder à au moins un répertoire
Un répertoire peut être accédé par au moins un utilisateur
Travail à faire : Élaborez un Diagramme de classes (Vous avez 15
minutes !)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 18 : système de fichiers (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 19 : des personnes, des communes. . .


Spécification :
Une personne peut travailler pour plusieurs sociétés
Une société a un et un seul PDG
Une personne peut être PDG de plusieurs sociétés et peut possé-
der plusieurs voitures
Une voiture a un seul propriétaire
Une personne peut avoir des enfants
Une personne peut être le maire d ’une commune et peut être le
député d ’une circonscription
Une commune appartient à une circonscription
Travail à faire : Élaborez un Diagramme de classes (Vous avez 25
minutes !)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 19 : des personnes, des communes (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 20 : Diagramme de classes

1 Donnez toutes les DFE&D à déduire de ce diagramme de classes


2 Donnez les tables de la BDR correspondant en précisant quels
sont les attributs qui forment les clés primaires et étrangères

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 20 : Diagramme de classes

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 21 : Diagramme de classes

Pour chaque exemple ci-dessous, indiquez si la relation présentée est


une généralisation, une agrégation ou une association :
Un pays a une capitale
Une transaction boursière est un achat ou une vente
Les fichiers contiennent des enregistrements
Une personne utilise un langage de programmation dans un
projet
Les modems et les claviers sont des périphériques
d’entrées/sorties

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 21 : Diagramme de classes (Solution)

Un pays a une capitale Agrégation


Une transaction boursière est un achat ou une vente Généralisa-
tion
Les fichiers contiennent des enregistrements Agrégation
Une personne utilise un langage de programmation dans un projet
Association
Les modems et les claviers sont des périphériques d’entrées/sor-
ties Généralisation

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 22 : Diagramme de classes

Pour chaque situation ci-dessous, proposez une modélisation de la réa-


lité.
1 Une librairie vend des livres, caractérisés par leur auteur et leur
nombre de pages ; certains livres possèdent également d’autres ca-
ractéristiques : une fourchette des âges pour les livres pour en-
fants, et la discipline et le niveau pour les livres scolaires.
2 On considère une entreprise, et on suppose qu’un chef dirige plu-
sieurs salariés (les subordonnés) et que le chef est lui-même un
salarié.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 22 : Diagramme de classes (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 23 : Diagramme de classes

Une classe Véhicule a été caractérisée par les propriétés suivantes : Nu-
méro du véhicule, date de fabrication du véhicule, pavillon du bateau,
nombre de réacteurs, superficie des ailes, puissance fiscale, hauteur du
mat, nombre de torpilles.

Quel est le défaut de cette classe ? Proposez une autre représentation à


l’aide d’un diagramme de classes.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 23 : Diagramme de classes (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 24 : Conduite d’un bus

Dans une société de transport, on voudrait gérer les bus de ramassage


scolaire et les conducteurs. Un lycéen est un enfant, il est caractérisé
par son nom, âge et sexe. Les informations qui caractérisent le conduc-
teur sont les mêmes que pour le lycéen, avec en plus le numéro de son
permis. Quant au bus, on a besoin de connaître son numéro d’immatri-
culation, sa date de mise en service, nombre d’années de service, et le
poids total.

Un bus est constitué d’une carrosserie (poids, couleur), des roues


(pression, diamètre), de plusieurs sièges (couleur) pour passagers, plu-
sieurs vitres (épaisseur, poids).

Présentez le diagramme de classes adéquat.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 24 : Conduite d’un bus (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 25 : Constitution ordinateur

Un ordinateur est composé d’un ou plusieurs moniteurs, d’un boîtier,


d’une souris optionnelle et d’un clavier. Un boîtier a un châssis mé-
tallique, une carte mère, plusieurs barrettes de mémoire, un ventilateur
optionnel, des supports de stockage et des cartes périphériques.

Proposez un diagramme de classes qui représente l’architecture d’un


ordinateur.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 25 : Constitution ordinateur (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 26 : Phrases

Soient les phrases suivantes :


Les modems et claviers sont des périphériques d’entrée / sortie
Une transaction boursière est un achat ou une vente
Un compte bancaire peut appartenir à une personne physique ou
morale
Elaborez les diagrammes de classe correspondants en choisissant le
type de relation approprié :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 26 : (Solution Périphériques et Transaction)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 26 : (Solution Compte bancaire)

NB : Pour le compte bancaire, on aurait également pu modéliser 2


associations entre « compte bancaire » et « personne physique » et «
personne morale » en y incluant une contrainte d’exclusion.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 27 : Dispense des cours


Une académie souhaite gérer les cours dispensés dans plusieurs col-
lèges. Pour cela, on dispose des renseignements suivants :
Chaque collège est structuré en départements, qui regroupent cha-
cun des enseignants spécifiques. Parmi ces enseignants, l’un d’eux
est responsable du département.
Un enseignant se définit par son nom, prénom, tél, mail, date de
prise de fonction et son indice.
Les étudiants suivent quant à eux plusieurs matières et reçoivent
une note pour chacune d’elle.
Pour chaque étudiant, on veut gérer son nom, prénom, tél, mail,
ainsi que son année d’entrée au collège.
Une matière peut être enseignée par plusieurs enseignants mais
a toujours lieu dans la même salle de cours (chacune ayant un
nombre de places déterminé).
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Exercice 27 : Dispense des cours

On désire pouvoir calculer la moyenne par matière ainsi que par


département
On veut également calculer la moyenne générale d’un élève et
pouvoir afficher les matières dans lesquelles il n’a pas été noté
Enfin, on doit pouvoir imprimer la fiche signalétique (, prénom,
tél, mail) d’un enseignant ou d’un élève.
Elaborez le diagramme de classes correspondant. Pour simplifier l’exer-
cice, on limitera le diagramme à une seule année d’étude

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 27 : Dispense des cours (Solution)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Comment construire un diagramme de classes


Lister les noms
Un substantif (mot du domaine) est un candidat potentiel pour
(Une entité, Un attribut)
Supprimer les Synonymes, Polysèmes et Noms superflus (in-
utiles ou hors domaine)
Procéder par itérations
Identifier les classes
Regroupent des attributs
Identifier les associations : Verbes
Identifier les classes interdépendantes
Répartir les attributs dans les classes
Indiquer les multiplicités
Trouver les opérations

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercices pratiques

A l’aide d’un logiciel de modélisation, représenter le diagramme de


classes de :
Exercice 25 DCl : Constitution ordinateur (45 min)
Exercice 27 DCl : Dispense des cours (45 min)
Merci de nommer les projets exactement comme ci-haut et les enre-
gistrer dans le même projet car ils seront tous remis

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagrammes d’objets ou d’instances

Le diagramme d’objets, dans UML, permet de représenter les ins-


tances des classes, c’est-à-dire des objets. Comme le diagramme de
classes, il exprime les relations qui existent entre les objets, mais aussi
l’état des objets, ce qui permet d’exprimer des contextes d’exécution.
En ce sens, ce diagramme est moins général que le diagramme de
classes.

Les diagrammes d’objets s’utilisent pour montrer l’état des instances


d’objet avant et après une interaction, autrement dit c’est une photo-
graphie à un instant précis des attributs et objet existant pour faciliter
la compréhension des structures complexes. Il est utilisé en phase
exploratoire.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagrammes d’objets ou d’instances

Chaque objet est représenté dans un rectangle dans lequel figure le


nom de l’objet (souligné) et éventuellement la valeur de un ou plu-
sieurs de ses attributs. Comme pour la représentation d’une classe, la
représentation d’un objet pourra être plus ou moins détaillée.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagrammes d’objets ou d’instances

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Relations réflexives

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagrammes d’objets ou d’instances

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagrammes d’objets ou d’instances

Soit le diagramme de classe suivant :

Avec le diagramme objet ci-dessous on définit une instance particu-


lière du diagramme de classe (qui est le combat entre Mohamed Ali et
George Foreman qui a eu lieu le 24 septembre 1974 à Kinshasa).

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagrammes d’objets ou d’instances

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagrammes d’objets ou d’instances

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme des modules (paquets)

Lorsque nous sommes en présence d’un système de grande taille,


il peut être intéressant de le décomposer en plusieurs parties (appe-
lées paquetage ou modules). Un paquetage est donc un regroupe-
ment de différents éléments d’un système (regroupement de classes,
diagrammes, fonctions, interfaces...). Cela permet de clarifier le mo-
dèle en l’organisant. Il est représenté par un dossier avec son nom à
l’intérieur :

Exemple : Utilitaires : :Horloge Le diagramme de paquetages est un


diagramme structurel (statique) d’UML qui représente les paque-
tages composant un système, ainsi que les relations qui lient ces diffé-
rents paquetages.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme des modules (paquets)

Il est possible de représenter les éléments du système appartenant au


paquetage : à l’intérieur de celui-ci ou à l’extérieur :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme des modules (paquets)

Pour faire appel à un élément d’un paquetage, nous indiquons le nom


du paquetage (espace de nommage) suivi de deux fois deux points
( : :) puis du nom de l’élément.

Les paquetages peuvent s’imbriquer (décomposition hiérarchique) mais


pas se chevaucher. Un élément du système ne peut appartenir qu’à un
et un seul paquetage. Chaque paquetage doit posséder un nom diffé-
rent.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Principes de structuration en paquetages

Regrouper les classes sémantiquement proches


Finalité : les classes rendent des services de même nature aux uti-
lisateurs
Évolution : isoler les classes stables de celles susceptibles d’évo-
luer (classes métier et classes applicatives. . .)
Cycle de vie des objets : distinguer les classes dont les objets ont
des durées de vie très différentes
Minimiser les dépendances entre paquetages

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Découpage en 2 paquetages (solution 1)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Découpage en 2 paquetages (solution 1 corrigée)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Découpage en 2 paquetages (solution 2)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dépendances entre paquetages : Visibilité

Chaque éléments d’un paquetage est soit :


privé : encapsulé dans le paquetage et invisible à l’extérieur de
celui-ci. Un élément privé est désigné par un signe – devant lui.
public : visible et accessible de l’extérieur du paquetage. Un
élément public est désigné par un signe + devant lui.

Par défaut, les éléments d’un paquetage sont publics.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dépendances entre paquetages : "import"

Elle correspond à l’importation par un paquetage B de tous les élé-


ments publics d’un paquetage A. Ces éléments :
auront la visibilité «public» dans le paquetage B (et seraient
donc aussi transmis à un paquetage qui ferait une importation du
paquetage B).
seront accessibles au paquetage B sans avoir à utiliser
explicitement le nom du paquetage A.
La dépendance de type «import» est représentée par une flèche poin-
tillée muni du stéréotype «import»

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dépendances entre paquetages : "import"

Le paquetage B importe Classe1 et Classe2 (pas Classe3 qui a une


visibilité de type privée). Classe1 et Classe2 ont une visibilité de type
public dans paquetage B. Le paquetage C importe Classe1, Classe2 et
Classe4

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dépendances entre paquetages : "access"

Elle correspond à l’accès par un paquetage B de tous les éléments pu-


blics d’un paquetage A. Ces éléments auront la visibilité privé dans
le paquetage B, ils ne peuvent donc pas être transmis à un paque-
tage C qui ferait une importation ou un accès au paquetage B (pas de
transitivité).

La dépendance de type «access» est représentée par une flèche poin-


tillée muni du stéréotype «access»

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dépendances entre paquetages : "access"

Le paquetage B a accès à Classe1 et Classe2 (pas à Classe3 qui a une


visibilité de type privée). Classe1 et Classe2 ont une visibilité de type
privé dans paquetage B. Le paquetage C a accès à Classe4 (pas à
Classe1 et Classe2 qui ont une visibilité de type privée dans paque-
tage B

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Dépendances entre paquetages : "merge"

Elle correspond à la fusion de 2 paquetages en un seul. La dépendance


de type «merge» est représentée par une flèche pointillée muni du sté-
réotype «merge».

Le paquetage A est fusionné dans le paquetage B (le paquetage A


n’est pas modifié alors que le paquetage B est écrasé pour accueillir
la fusion des 2 paquetages)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Un dernier exemple

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Un diagramme de déploiement est une vue statique qui sert à re-


présenter l’utilisation de l’infrastructure physique par le système et la
manière dont les composants du système sont répartis ainsi que leurs
relations entre eux.

Les éléments utilisés par un diagramme de déploiement sont principa-


lement les nœuds, les composants, les associations et les artefacts.
Les caractéristiques des ressources matérielles physiques et des sup-
ports de communication peuvent être précisées par stéréotype.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Les nœuds (nodes), représentés par des cubes, sont des composants
mécaniques de l’infrastructure tel un routeur, un ordinateur, un assis-
tant personnel, ... . Ceux-ci peuvent comprendre d’autres nœuds ou
artefacts. Les nœuds internes indiquent l’environnement d’exécution
plutôt que l’infrastructure physique.

Les composants, représentés par des boites rectangulaires avec deux


rectangles sortant du côté gauche, sont les différentes parties du sys-
tème étudié.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Un nœud est représenté par un parallélépipède rectangle dans lequel


figure son nom.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Un nœud possède des attributs (quantité de mémoire, vitesse de pro-


cesseur, marque, type...) que nous pouvons spécifier à l’intérieur du
parallélépipède.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Pour montrer qu’un composant est affecté sur un nœud, il faut :


Soit en plaçant le composant dans le nœud
Soit en le reliant à l’aide d’une relation de dépendance (flèche
en pointillées) stéréotypée «support» orientée du composant
vers le nœud.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Les connexions sont principalement de deux types : associations ou


dépendances.

Les associations, représentées par de simples lignes sont des liens de


communication, s’établissent entre les différents composants du sys-
tème.

Les dépendances, représentées par des flèches vides, sont régies par
les règles standard de l’UML 2.0.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Un artefact est une manière de définir un fichier, un programme, une


bibliothèque ou une base de données construite ou modifiée dans un
projet. Ces artefacts mettent en œuvre des collections de composants
qui sont consommées ou créées durant l’une des étapes du processus
de déploiement.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement
Projet de mesure et d’analyse de consommation énergétique :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Déploiement

Projet de transfert de photos par Internet :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les axes de modélisation


Il existe trois axes de modélisation sous le principe d’UML et chacun
d’entre eux suppose un ensemble des diagrammes :

Maintenant l’axe dynamique !


Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Rôle des modèles dynamiques

Constituent un plus par rapport aux méthodes systémiques (Merise)


Relations temporelles et événementielles entre objets
Les États des objets au cours de déroulement de l’application
Actions effectuées par les objets dans un contexte donné
Actions et réactions des objets vis à vis des sollicitations exté-
rieures

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme d’états

Le diagramme d’état décrit les transitions entre les états (states) et


les actions que le système ou ses parties réalisent en réponse à un
événement. Il s’agit d’une représentation séquentielle des états d’un
système.

Le diagramme d’état se compose


d’états
de transitions
d’évènements
de conditions
d’effets
d’activités

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme d’états (transitions)

État : une situation d’un bloc fonctionnel pendant laquelle


il satisfait une certaine condition
il exécute une certaine activité
Événement : stimulus pouvant transporter des informations (exemple :
clic souris)
Message : événement particulier impliqué dans l’interaction entre
2 objets
Transition : Changement d’état d’un objet causé par un événe-
ment
Les différents états sont reliés entre eux par des transitions.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme d’états (transitions)

Une transition est liée à un événement. Lorsque l’événement se pro-


duit, il peut provoquer le changement d’état de la fonction qui lui
est liée. Une transition peut être complétée par une condition (guard)
notée entre croche, des paramètres notés entre parenthèses et d’une ac-
tivité.
evenement[condition](paramètres)/activité
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Les super-états, pseudo-états et mémoire


Le diagramme d’état peut comporter des super-états (submachine state)
qui encapsulent d’autres diagrammes d’états. Ils permettent de "factoriser"
des transitions déclenchées par le même événement et amenant vers le
même état cible (brancher, débrancher) tout en spécifiant des transi-
tions particulières entre les sous-états.

La mémorisation est modélisée par un pseudo état History symbolisé


par la lettre H. L’activation de ce pseudo-état permet au super état
de se souvenir du dernier sous-état qui était actif avant une transition
sortante.

Dans l’exemple ci-dessous, grâce au pseudo état History, le fait de dé-


brancher la RADIO provoque la mémorisation des paramètres pro-
grammés. Lorsque l’appareil sera à nouveau rebranché les paramètres
mémorisés seront repris.
Youen Mushegerha (CT) Étude des systèmes d’information
Introduction
Point de vue fonctionnel

Les super-états, pseudo-états et mémoire

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les super-états, pseudo-états et mémoire

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemples : distributeur de boissons

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemples : distributeur de boissons

Un état composite possédant 2 régions

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemple de diagramme d’états-transitions

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exemple de diagramme d’états-transitions

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 29 : Montre digital

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 29 : Montre digital


Une montre digitale simple possède un cadran et deux boutons, que
l’on nommera A et B. La montre a deux modes d’opérations, affichage
de l’heure et mise à l’heure. En mode d’affichage, les heures et les mi-
nutes sont affichées, séparées par un signe « deux points » intermittent.

Le mode de mise à l’heure à deux sous-modes, heures et minutes.


A chaque fois que l’on appuie sur le bouton A, le mode change sui-
vant la séquence : affichage, configurer heures, configurer minutes, af-
fichage, etc. Dans une sous-mode, le bouton B s’emploie pour avancer
les heures ou les minutes à chaque fois que l’on appuie dessus. Les
boutons doivent être relâchés avant de pouvoir produire un autre évé-
nement.
Travail à faire : Préparez un diagramme d’états de la montre.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 29 : Montre digital (Solution)

Réponse :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Exercice 30 : Montre digital (S’exercer)

Et si on complexifie l’exercice ? ! ! !

Compléter le diagramme d’états en prenant en compte la gestion de


l’éclairage, l’affichage de l’alarme, la mise sous alarme (Travail à
faire ! ! !)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme des profils

En UML, un diagramme de profils est un diagramme de structure


permettant l’utilisation de profils pour un méta-modèle donné.

Apparu avec UML 2.2, ce diagramme fournit une représentation des


concepts utilisés dans la définition des profils (packages, stéréotypes,
application de profils, etc.)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme des profils

Le diagramme de profils permet l’utilisation des éléments suivants :


Stéréotype (représenté comme une classe avec le stéréotype «ste-
reotype») ;
Métaclasse (représentée comme une classe avec le stéréotype «me-
taclass») ;
Profil (représenté comme un package avec le stéréotype «pro-
file»).

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme des profils

Les relations entre les éléments : Les éléments d’un diagramme de


profils peuvent être mis en relation à l’aide des éléments suivants :
Extension (d’un stéréotype à une métaclasse, représentée comme
une flèche pleine) ;
Application de profil (d’un profil à un package de métamodèle,
représentée comme une flèche pointillée avec le stéréotype «ap-
ply») ;
Référence (d’un profil à un package ou une métaclasse référen-
cés par le profil, représenté comme une flèche pointillée avec le
stéréotype «reference»).

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de Profil

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)

Un diagramme de temps est un diagramme d’interaction où l’atten-


tion est portée sur les contraintes temporelles dans le langage UML2.

Ils sont utilisés pour explorer le comportement des objets d’un sys-
tème à travers une période déterminée.

Un diagramme de temps est une forme spéciale de diagramme de sé-


quence où les axes ont été inversés pour que le temps s’écoule de la
gauche vers la droite et les lignes de vies sont affichées dans des com-
partiments séparés disposés horizontalement.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)

Sur un diagramme de temps, la ligne de vie permet aussi de présenter


les états d’un objet au cours de la période de temps représentée par le
diagramme, un plat signifiant que l’état de l’objet n’a pas évolué sur
cette période.

Les lignes de vies peuvent être annotées avec des intervalles de durées
(« entre 1 et 6 minutes ») ou bien des intervalles de temps (« entre
5h40 et 6h00 ») que l’application doit respecter.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)


Mots-clefs du diagramme
Ligne de vie, Etat, Ligne te temps, Message, Événement,
Contrainte de durée

Ligne de vie
Sémantiquement similaire à une ligne de vie dans un diagramme
de séquence
Schématiquement le nom de type (objet, acteur...) écrit vertica-
lement du bas vers le haut

État
Abstraction de valeurs d’un objet exactement comme dans un dia-
gramme États-transitions

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)


Exemple :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)

Ligne de temps
Représenté par une ligne continue
Définit l’intervalle de temps relatif à chaque état de la ligne de vie
Pouvant être ornés de contrainte de temps

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)


Voici comment modéliser les lignes de temps :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)


Les changements d’état de l’objet : Piste

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)

Message
Associé à une ligne de vie
Accompagné d’un événement
Exactement comme dans un diagramme de séquence, représenté
par une flèche
en traits pleins et‘a l’extrémité ouverte pour les messages asyn-
chrones
en traits pleins et‘a l’extrémité pleine pour les messages syn-
chrones
Permettant‘a une ligne de vie d’informer une autre de son chan-
gement d’état

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)


message synchrone + événement :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)


On peut avoir un message de retour (asynchrone)

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)

Contrainte de durée
Intervalle mathématique exprimée sous forme d’une contrainte
UML
Précisant la durée min et max d’un ou plusieurs état(s)
Placée entre accoladescontrainte
Accompagnée d’une flèche à double sens pour indiquer le début
et la fin

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)


Une contrainte peut concerner une partie d’une ligne de temps d’un
état ou plusieurs :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)


On peut aussi définir un contexte :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de temps (Timing)

Une deuxième représentation possible pour les lignes de temps :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de structure composite

Dans le langage UML, le diagramme de structure composite expose


la structure interne d’une classe ainsi que les collaborations que cette
dernière rend possible. Ses éléments sont les parties, les ports par
le biais desquels les parties interagissent entre elles, avec différentes
instances de la classe ou encore avec le monde extérieur, et enfin les
connecteurs reliant les parties et les ports.

Une structure composite est un ensemble d’éléments interconnectés


collaborant dans un but commun lors de l’exécution d’une tâche. Chaque
élément se voit attribuer un rôle dans la collaboration.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de structure composite

Le diagramme des structures composites est apparu dans la spécifica-


tion d’UML 2.0. Les éléments clés du diagramme de structure compo-
site sont les classifieurs structurés, les parties, les ports, les connecteurs
et les collaborations.
Un classifieur structuré représente une classe, dans la plupart des
cas une classe abstraite, dont le comportement peut être décrit
complètement ou partiellement par le biais d’interactions entre
parties. Un classifieur encapsulé est une forme de classifieur struc-
turé contenant des ports.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de structure composite

Une partie représente un rôle joué par une instance d’une classe
ou un ensemble d’instances à l’exécution. La partie peut donner
le nom d’un rôle, d’une super-classe abstraite ou d’une classe
concrète spécifique. La partie peut inclure une cardinalité.
Le port est un point d’interaction qui peut être utilisé pour connec-
ter un classifieur structuré avec ses parties ou son environnement.
Les ports peuvent accessoirement spécifier les services qu’ils four-
nissent ainsi que les services qu’ils peuvent requérir d’autres par-
ties du système. Les ports sont symbolisés par un carré sur le dia-
gramme.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de structure composite

Les connecteurs relient plusieurs entités, leur permettant d’inter-


agir entre elles lors de l’exécution. Un connecteur est représenté
par une ligne reliant une combinaison de parties, des ports ou des
classifieurs structurés.
Une collaboration est en général d’un niveau d’abstraction plus
élevé qu’un classifieur. Elle est représentée par un ovale en poin-
tillé contenant les rôles joué par chaque instance dans la collabo-
ration lors de l’exécution.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de structure composite

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants

Dans UML, les diagrammes de composants représentent la structure


du système logiciel, qui décrit les composants du logiciel, leurs inter-
faces et leurs dépendances. Vous pouvez utiliser des diagrammes de
composants pour modéliser des systèmes logiciels à un haut niveau ou
pour afficher des composants à un niveau inférieur, au niveau du pa-
ckage.

Ce type de diagramme prend en charge le développement à base de


composants, dans lequel un système logiciel est divisé en composants
et interfaces qui sont réutilisables et remplaçables.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants

Les diagrammes de composants sont utiles pour les raisons suivantes :

Définition des aspects exécutables et réutilisables d’un système


logiciel
Mise en évidence des problèmes de configuration logicielle à tra-
vers les relations de dépendance
Représentation précise d’une application logicielle avant que vous
n’y apportiez des changements ou des extensions

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants

Vous pouvez aussi utiliser des diagrammes de composants pour repré-


senter les composants physiques suivants d’un système logiciel :
Les fichiers de code source que vous développez dans un IDE
Les fichiers exécutables qui sont nécessaires pour réaliser un sys-
tème en cours de fonctionnement
Les bases de données physiques qui stockent des informations
dans les tables d’une BDR ou dans les pages d’une BDOO
Les systèmes adaptables dotés de composants qui migrent pour
l’équilibrage de charge et la reprise sur incident

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants : représentation graphique

Il existe plusieurs possibilités pour représenter un composant :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants : représentation graphique

Il existe aussi plusieurs possibilités pour représenter les interfaces :


Intégrées dans la représentation du composant :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants : représentation graphique

Il existe aussi plusieurs possibilités pour représenter les interfaces :


Dans un classeur séparé du composant dans lequel sont listés les
différents services :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants : représentation graphique

Il existe aussi plusieurs possibilités pour représenter les interfaces :


Avec des connecteurs d’assemblage :

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Diagramme de composants VS Diagramme de déploiement

Les diagrammes de composants sont distincts des diagrammes de


déploiement. Un le premier définit la composition des composants
et artefacts dans le système. Le deuxième affiche les composants et
artefacts en relation avec l’emplacement où ils sont utilisés dans le
système déployé.

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les 13 Diagrammes d’UML

Diagrammes de structure ou diagrammes statiques (7)


1 Diagramme des classes
2 Diagramme d’objets
3 Diagramme de structure composite
4 Diagramme de composants
5 Diagramme de déploiement
6 Diagramme des paquets (Modules)
7 Diagramme de profils

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les 13 Diagrammes d’UML

Diagrammes de comportement (3)


1 Diagramme des cas d’utilisation
2 Diagramme d’états-transitions
3 Diagramme d’activités
Diagrammes d’interaction ou diagrammes dynamiques (3)
1 Diagramme de séquence
2 Diagramme de communication (Collaboration)
3 Diagramme de temps

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les 13 Diagrammes d’UML

Youen Mushegerha (CT) Étude des systèmes d’information


Introduction
Point de vue fonctionnel

Les 13 Diagrammes d’UML

Youen Mushegerha (CT) Étude des systèmes d’information

Vous aimerez peut-être aussi