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