Vous êtes sur la page 1sur 230

Chapitre 1 - Introduction

au langage UML
La justification historique de la modélisation objet

La complexité du logiciel
Ses origines

Selon Grady Booch, la complexité est une caractéristique


inhérente au logiciel et elle provient de quatre éléments :
la complexité des problèmes ;
la difficulté à contrôler le processus de développement ;
la flexibilité dans la programmation ;
le passage du monde continu au monde discret .
La justification historique de la modélisation objet

La complexité du logiciel
La complexité des problèmes
Les logiciels doivent parfois traiter des éléments
complexes (par exemple, le pilote automatique d'un avion
de ligne) auxquels viennent s'ajouter des exigences comme
la facilité d'emploi, les performances ...
La justification historique de la modélisation objet

La complexité du logiciel
La complexité des problèmes

Ces contraintes forment un


ensemble de besoins que
l'utilisateur a du mal à exprimer
à un concepteur de logiciels qui
ne connaît pas nécessairement
le domaine d'activité de
l'utilisateur.
Ce dialogue s'effectue aux
travers de documents parfois
volumineux et sujets à
interprétations.
La justification historique de la modélisation objet

La complexité du logiciel
La complexité des problèmes
Cette complexité est encore accrue par l'évolution du
dialogue entre le concepteur qui appréhende de mieux
en mieux le domaine et l'utilisateur qui saisit mieux les
possibilités de l'informatique et exprime mieux ses
besoins.
La justification historique de la modélisation objet

La complexité du logiciel
La difficulté à contrôler les processus de développement

Les logiciels doivent parfois traiter (en interne) des


éléments complexes tout en conservant (en externe)
une relative simplicité d'utilisation. Cet objectif peut être
atteint en utilisant, par exemple, des interface
utilisateurs graphiques et intuitives.
La justification historique de la modélisation objet

La complexité du logiciel
La difficulté à contrôler les processus de développement

Ce traitement interne, toujours plus complexe, auquel vient


s'ajouter un souci de simplification dans sa présentation,
entraîne une augmentation du volume de codage des outils
logiciels.
La justification historique de la modélisation objet

La complexité du logiciel
La difficulté à contrôler les processus de développement
Le processus de développement de tels outils logiciels ne peut
plus être appréhendé (en un temps raisonnable) par une seule
personne et doit faire l'objet d'un travail d'équipe.
La complexité organisationnelle vient s'ajouter à la
complexité du logiciel à développer.
La justification historique de la modélisation objet

La complexité du logiciel
La flexibilité dans la programmation

Des industries comme le bâtiment peuvent utiliser les


services d'autres industries comme la métallurgie pour
construire des édifices car toutes sont tenues de respecter
des normes.
La justification historique de la modélisation objet

La complexité du logiciel
La flexibilité dans la programmation

Un industriel comme Eiffage peut construire un pont mixte


en utilisant des poutres d'acier produites par un autre
industriel comme sa filiale Effel simplement en spécifiant
le type normalisé de poutre dont il a besoin (une poutre
d'un type donnée est construite d'une certaine manière et
possède des caractéristiques mécaniques particulières).
La justification historique de la modélisation objet

La complexité du logiciel
La flexibilité dans la programmation

L'industrie du logiciel possède moins de normes, les


concepteurs sont alors tentés de créer leurs propres
briques de base pour s'assurer qu'elles répondent
parfaitement à leur besoins : le développement logiciel en
devient donc d'autant plus laborieux.
La justification historique de la modélisation objet

La complexité du logiciel
Le passage du monde continu au monde discret

La modélisation du réel, qui est


régie par des lois physiques
continues, s'appuie sur des
éléments discrets possédant un
nombre fini d'états.

En météorologie, l’atmosphère
est modélisée par un ensemble
de cubes où la température et la
pression sont considérées
comme homogènes.
La justification historique de la modélisation objet

La complexité du logiciel
Le passage du monde continu au monde discret

Cette discrétisation introduit une erreur artificielle qui doit


être gérée par le logiciel (par exemple un dépassement de
capacité ne doit pas introduire un comportement anormal du
modèle).
La justification historique de la modélisation objet

La complexité du logiciel
Le passage du monde continu au monde discret

L'état du modèle discret est la combinaison des états des


éléments qui composent ce modèle, le programmeur doit donc
gérer une combinatoire importante qui amène un modèle avec
un grand nombre d'états.
La justification historique de la modélisation objet

La gestion progressive de la complexité


Premiers programmes en langage machine

Les premiers programmes, écrits en langage machine,


dépendaient fortement de l'architecture des ordinateurs
utilisés.
La justification historique de la modélisation objet

La gestion progressive de la complexité


Programmation en langages évolués

Lorsque le nombre d'architectures différentes a augmenté, un


premier effort a été produit pour séparer les concepts
manipulés dans les langages de leur représentation dans
la machine et a aboutit à la création de langages comme
FORTRAN.
La justification historique de la modélisation objet

La gestion progressive de la complexité


Méthode d’analyse par décomposition

La complexité croissante des


programmes a de nouveau suscité
un effort pour mieux structurer les
programmes (en abandonner le
goto et la programmation spaghetti).
Les méthodes d'analyse consistait
alors à « diviser pour mieux
régner », autrement dit à découper
les tâches en modules
indépendants considérés comme
des boites noires [Edsger Dijkstra].
La justification historique de la modélisation objet

La gestion progressive de la complexité


Structuration des programmes

Niklaus Wirth alla plus loin en considérant les programmes


comme la « somme » d'une structure de données et d'un
ensemble distinct d'algorithmes chargés de les manipuler.
La programmation structurée étaient alors synonyme de
programmation dirigée par les traitements.
La justification historique de la modélisation objet

Limites de la programmation structurée


L’explosion des besoins

Le coût du matériel informatique a fortement décrût et ce


matériel est devenu un bien de consommation courant (tant
dans des entreprises et des universités que chez les
particuliers).
La clientèle s'est diversifiée, les besoins ont explosé.
La justification historique de la modélisation objet

Limites de la programmation structurée


Des besoins très variés

Certains besoins concernent la création de logiciels mais


d'autres besoins concernent la « maintenance » de logiciels (70
% du coût du logiciel).
40 % de cette maintenance sont des extensions ou des
modifications demandées par les utilisateurs.
La justification historique de la modélisation objet

Limites de la programmation structurée


La diffusion de la structure des données dans le code

La programmation structurée nécessite de faire des hypothèses


sur les données à traiter .
La structure physique des données à traiter est diffusée dans
une part importante du code.

Une simple modification des exigences des utilisateurs ou une


modification des données peut entraîner d'importantes
modifications au niveau des codes chargés de les traiter.
La justification historique de la modélisation objet

Limites de la programmation structurée


L’exemple de des postes Américaines

Par exemple, en 1982, les postes américaines sont passés du


code postal à 5 chiffres à celui à 9 chiffres. Beaucoup de
programmes gérant des fichiers d'adresses ont dû être récrits
à grands frais.
La justification historique de la modélisation objet

Limites de la programmation structurée


Synthèse de la situation avant la POO

D'un côté des utilisateurs formulaient des exigences qui leur


semblaient simples
De l'autre des concepteurs de logiciels ne maîtrisaient pas la
complexité logicielle notamment à cause de la
programmation structurée.

Nous avons alors abouti à une explosion des délais et des


budgets informatiques ce qui s'est traduit à grande échelle
par une crise du logiciel.
Introduction au langage UML

Les apports de la
modélisation objet
Les apports de la modélisation objet

Plan de la partie
Voici les chapitres que nous allons aborder :
Méthode et modèle
Le principe d’encapsulation.
Le principe d’abstraction.
Le principe de modularité.
Synthèse.
Méthode, modèle
processus

Une méthode comprend deux parties :


une première, technique, qui correspond à l’ensemble des activités
induites (ce que l’on doit faire et dans quel ordre) ;
une seconde, organisationnelle, relative à la gestion du processus
(qui fait quoi, avec quelles ressources).
Il faut ajouter à cela un aspect outillage qui complète
avantageusement cet « arsenal ».
techniques
Méthode = { notations, processus, outil, management}

UML
UP StarUML
Méthode, modèle
Un modèle est une représentation (le plus souvent abstraite) de
quelque chose que l’on perçoit :

Modèle 1 Modèle 2


réalité déformée
filtre réalité
filtre réalité déformée
perception perception
Modèle

ÉPISTÉMOL., SC. Système physique, mathématique ou


logique représentant les structures essentielles d'une réalité
et capable à son niveau d'en expliquer ou d'en reproduire
dynamiquement le fonctionnement`` (Birou 1966). Modèle
explicatif; modèle logico-mathématique:
On parle de modèle, en science, chaque fois qu'il y a renvoi
d'une réalité concrète à une réalité idéale avec exploitation de
leurs analogies descriptives. Analogie ne signifie nullement
identité; il existe même une différence de nature entre le
modèle et le réel qu'il représente, le modèle ayant une valeur
symbolique. Sill. Psychol. 1980, p.753.
Réf: http://www.cnrtl.fr/lexicographie/modele
Objets de la vie courante

Rêve

123CDE91 titi

garfield mange
0605040302
0102030405 grosminet

parle

odie
001-DF-YTR
poursuit
007BEJ06
Dupond Dupont

poursuit
java 2

0203040506 felix
45BEJ91
Les objets coopèrent
Objet boîte noire

Services rendus par l’objet


:
Démarrer ;
Arrêter ;
Accélérer ;
Freiner ;
Climatiser …
Fonctionnement
interne ???
Objet logiciel

Abstraction
Représentation abstraite des entités du monde réel ou virtuel
dans le but de les piloter ou de les simuler
Programme, logiciel

Objet = Message =
demande de
Service
État + service
État
Comportement +
Identité
unObjet
Téléphone portable

voir R ép er toir e
() appeler (Bob)

ch er ch er
appeler

N um er o
(personne)
État
(p er sonne)

monTéléphone recevoir
msg appeler (Bob et Paulette)
(msg)
Les apports de la modélisation objet

Le principe d’encapsulation
Le principe
Le principe de l'encapsulation est « d'enfermer »
(de cacher) les données dans des entités logicielles
appelées objets qui fournissent des méthodes pour accéder
« proprement » en lecture et en écriture à ces données que nous
appelons attributs (ou champs).
INTERFACE

METHODES ATTRIBUTS
Les apports de la modélisation objet

Le principe d’encapsulation
Selon Grady BOOCH
Les apports de la modélisation objet

Le principe d’encapsulation
L’objectif et les conséquences

Cette encapsulation avait pour principal objectif de confiner la


structure physique des données à l'intérieur de l'objet afin
de limiter l'impact d'une éventuelle modification dans la
structure des données.

L’adaptabilité du code est améliorée donc l’écriture du code et


sa maintenance sont facilitées
Les apports de la modélisation objet

Le principe de modularité
L’héritage et le polymorphisme

D'autres concepts comme l'héritage et le polymorphisme ont


été mis en place plus tard dans les langages de POO afin de
faciliter la ré-utilisabilité du code :
productivité accrue des équipes de programmeurs ;
extensibilité du code améliorée.
Les apports de la modélisation objet

Le principe de modularité
L’héritage

Ces objets graphiques ont des points Point


Couleur
communs comme la couleur ou le
Point d’ancrage
point d'ancrage : ces attributs peuvent
être déclarés une seule fois au
niveau de l'objet Point, ils seront
connus de la descendance. Segment

De même les méthodes permettant de


lire ou de modifier ces attributs seront Rectangle
codées une seule fois au niveau de
Point pour être connues de la
descendance.
Les apports de la modélisation objet

Le principe de modularité
Le polymorphisme

Soit des objets graphiques (le point, le cercle, le carré ...)


munis d’une même méthode « dessiner » qui se comporte
différemment selon le type d'objet.

Nous créons un objet « abstrait » appelé objetGraphique


muni d'une méthode virtuelle « dessiner ».

On créé un tableau d’objetGraphique et lorsqu’on implante


une boucle où est appelée la méthode dessiner de chaque
élément, le système détermine automatiquement la bonne
méthode dessiner à utiliser.
Les apports de la modélisation objet

Le principe de modularité
Le polymorphisme

« abstract »
ObjetGraphique

virtual dessiner

Point Cercle Carré

dessiner dessiner dessiner


Les apports de la modélisation objet

Le principe d’abstraction
Le principe

Chaque acteur de la conception possède son propre point


de vue sur l'objet qui est conditionné par son domaine
d'activité professionnelle, par sa culture et sa sensibilité.

Les niveaux d'abstraction perçus par chacun sont alors


différents

L'objet à concevoir doit pouvoir être décrit en respectant


différents niveaux d'abstraction (du général au précis).
Les apports de la modélisation objet

Le principe d’abstraction
Les différents points de vue (selon G. BOOCH)
Les apports de la modélisation objet

Le principe d’abstraction
Les différents niveaux d’abstraction (selon G. BOOCH)
Les apports de la modélisation objet

Le principe d’abstraction
La pratique

D’un point de vue pratique, ce principe d’abstraction est atteint


en utilisant une hiérarchie d’objets :
des objets (par exemple des souris) qui englobent
d’autres objets (différents types de rouages) qui englobent
d’autres objets plus petits (les composants) qui contiennent
des objets atomiques.

Les concepteurs peuvent donc manipuler un objet dans sa


globalité ou dans un niveau de détail plus fin.
Les apports de la modélisation objet

Synthèse
Les 3 principes de la modélisation objet
Introduction au langage UML

L’aspect historique de la
modélisation objet
L’aspect historique de la modélisation objet

Plan de la partie
Voici les chapitres que nous allons aborder :
Introduction.
Grady Booch et OOD.
Ivar Jacobson et OOSE.
John Rumbaugh et OMT.
L'arrivée d'UML.
L’aspect historique de la modélisation objet

Introduction
Une petite chronologie

Les premières méthodes d'analyse apparaissent au cours


des années 70.

Les méthodes d’analyse sont améliorées dans les années


80. On adopte une approche systémique (modélisation des
données et modélisation des traitements) et on utilise des
méthodes comme Merise, Axial, IE...

Dans les années 90-98, le langage C++ connaît de plus en


plus d’adeptes. On assiste à ce moment à une l’émergence
d’une multitude de méthodes objet (Booch, Classe-
Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE) :
3 méthodes se démarquent (OMT, OOD et OOSE).
L’aspect historique de la modélisation objet

Grady Booch et OOD


Description

OOD signifie « Object Oriented Design ».


Cette méthode a été créée en 1993 par Grady Booch, alors
qu’il travaillait chez General Electric pour faciliter la phase de
conception orientée objet des gros projet.
Cette méthode propose des vues logiques et physiques du
système.
L’aspect historique de la modélisation objet

Ivar Jacobson et OOSE


Description

OOSE signifie « Object Oriented Software Engineering ».


Cette méthode, créée en 1995 par Ivar Jacobson dans le
cadre de ses activités chez Ericsson, introduit la notion de
use-cases (cas d’utilisation).
L’aspect historique de la modélisation objet

John Rumbaugh et OMT


Description

OMT est l’acronyme de « Object Modeling Technique ».


John Rumbaugh a créé cette méthode en 1996 et a
commercialisé un logiciel appelé Rational Rose (de la
société Rational Rose Software) qui est une référence
dans le domaine de la modélisation.
Cette méthode propose des vues statiques, dynamiques et
fonctionnelles d’un système.
L’aspect historique de la modélisation objet

L’arrivée d’UML
L’unification

Entre 1995 et 1997, nous assistons à une fusion progressive


de ces 3 méthodes (OOD, OOSE et OMT) :

représentation graphique commune des notions qui apparaissaient


comme semblables ;
apport des éléments spécifiques à chacune des méthodes.

Ces 3 méthodes ont donc été unifiée sous la bannière UML


qui signifie Unified Modeling Language.
L’aspect historique de la modélisation objet

L’arrivée d’UML
La normalisation

UML devient une norme de l’OMG en 1997.

L’OMG (Object Management Group) est un organisme à but


non lucratif créé en 1989 afin de promouvoir des standards
(comme CORBA par exemple) qui garantissent
l’interopérabilité entre des applications orientées objet
développées sur des réseaux hétérogènes.

Cet organisme a été créé et est soutenu par des industriels


comme HP, Sun, Unisys, American Airlines, Philips …
L’aspect historique de la modélisation objet
L’arrivée d’UML
L’évolution
La norme a évolué afin d’intégrer
de nouveaux diagrammes ;
une manière de formaliser les contraintes grâce à OCL
(Object Constraint Language) proposé par IBM.

On a donc eu :
la version 1.1 en 1997 ;
la version 2.0 en 2004 ;
la dernière est la 2.1.1 du 3 février 2007.
L’aspect historique de la modélisation objet

L’arrivée d’UML
L’évolution
L’aspect historique de la modélisation objet

L’arrivée d’UML
Au final, qu’est-ce qu’UML ?

UML est un langage visuel, basé sur l’utilisation de


diagrammes normalisés.

Il permet d'exprimer visuellement une solution objet, ce qui


facilite la comparaison et l'évaluation de solutions.

UML n’est pas une méthodologie de développement,


contrairement à RUP (Rational Unified Process).
L’aspect historique de la modélisation objet

L’arrivée d’UML
Les différentes vues

UML propose 5 vues qui se superposent en partie afin de


présenter les systèmes sous différents aspects.

Vue d’implémentation Vue logique

Vue des cas d’utilisation

Vue du déploiement Vue des processus


L’aspect historique de la modélisation objet

L’arrivée d’UML
Les différentes vues

La vue des cas d'utilisation décrit le système tel que le


perçoivent les acteurs (leurs besoins).
La vue logique décrit l’intérieur du système pour expliquer
comment peuvent être satisfaits les besoins.
La vue d'implémentation définit les dépendances entre les
modules.
La vue des processus est la vue temporelle et technique,
qui met en œuvre les notions de tâches concurrentes, stimuli,
contrôle, synchronisation, etc.
La vue de déploiement décrit la position géographique et
l'architecture physique de chaque élément du système.
L’aspect historique de la modélisation objet

L’arrivée d’UML
Les différents diagrammes

UML (qui est avant tout un langage graphique) propose 13


types de diagrammes.

Ces diagrammes sont présentés dans la norme sous forme


d’un diagramme de classes afin de mettre en évidence les
deux types de diagrammes :
les diagrammes de structure pour modéliser l’aspect statique
d’un système ;
les diagrammes de comportement pour modéliser l’aspect
plutôt dynamique d’un système.
L’aspect historique de la modélisation objet

L’arrivée d’UML
Les différents diagrammes
Diagramme

Diagramme de structure Diagramme de comportement

Diagramme de classes Diagramme d’activité

Diagramme d’objets Diagramme de cas d’utilisation

Diagramme de paquets Diagramme d’états-transitions

Diagramme de déploiement Diagramme d’interaction

Diagramme de composants Diagramme de séquence

Diagramme de structure composite Diagramme de communication

Diagramme global d’interaction

Diagramme de temps
L’aspect historique de la modélisation objet
L’arrivée d’UML
Les points forts
UML est un langage formel et normalisé :
un gain de précision (pas d’ambigüité) ;
un gage de stabilité qui encourage à la création et
l’utilisation d’outils.

UML est un support de communication performant :


il cadre l’analyse ;
il facilite la compréhension de représentations abstraites
complexes ;
son caractère polyvalent et sa souplesse en font un
langage universel.
L’aspect historique de la modélisation objet

L’arrivée d’UML
Les points faibles

L’utilisation pratique d’UML passe par un apprentissage.


UML ne propose pas de méthodologie, c’est seulement
un langage graphique.
Représentation du contexte du système
Définir les Limites du système à développer
Relations entre le système et son environnement.
Diagrammes:
Cas d’utilisation

Gestion commerciale représente le périmètre de l’étude


Les acteurs sont des personnes ou des systèmes en
relation avec le domaine de l’étude.
Les acteurs sont extérieurs au domaine de l’étude.
Diagrammes:Cas d’utilisation

Pour:
Structurer fonctionnellement le domaine pour décrire les
exigences
Répartir le travail et les responsabilités pour la spécification
et la validation des besoins.
Les cas d’utilisation
Opportunité

Analyse
du besoin

Analyse
du problème
de la solution

Conception
de la solution

Implémentation
Mise en oeuvre
Cas d’utilisation

Chaque cas d’utilisation est accompagné d’un


texte et éventuellement de diagrammes
Ceux-ci expriment les exigences du client
Les exigences constituent une partie du contrat
entre le client (maîtrise d’ouvrage) et les
développeurs (maîtrise d’œuvre)
Cas d’utilisation
Exemple de rédaction
Titre: Préparation de la commande fournisseur
But: Déterminer la date de passation de commande
Version, date de rédaction
Auteur de la rédaction
Acteurs du cas d’utilisation: acheteur
Préconditions:
Les demandes d’achat sont valides, elles ont été affectées à
l’acheteur qui initialise le processus.
Postcondition:
La date de passation de commande de la DA est prévue
Événement initial:
Affectation des DA nouvellement arrivées à un acheteur
Description du scénario de base
Description des flots alternatifs
Diagrammes:
Cas d’utilisation. Acteurs

Le domaine du projet est découpé en cas d’utilisation

Chaque cas d’utilisation représente une fonction du


système informatique dont un acteur métier a besoin

Un acteur métier est un rôle.

Dans la démarche: on recherche d’abord les acteurs


métier puis les fonctions dont ils ont besoin.
Diagrammes:
Cas d’utilisation.

Le cas d’utilisation spécifie la façon dont le


système est utilisé pour aider un client ou un
utilisateur à atteindre ses objectifs. Il décrit un
processus.
Cas d’utilisation
Spécifications de besoins,
exigences

Le texte doit être bien structuré


Il est sous la responsabilité de l’utilisateur
Il peut être accompagné de diagrammes UML
Il décrit ce que doit faire le système et non
comment
Cas d’utilisation
Spécifications de besoins,
exigences
Le cas d’utilisation décrit un processus métier
Le processus est déclenché par un événement métier
Il se termine par un résultat intéressant pour l’utilisateur ou par
un échec
Il comporte souvent plusieurs scénarios
Diagrammes:Cas d’utilisation

Chaque cas d’utilisation est accompagné d’un


texte et éventuellement de diagrammes
Ceux-ci expriment les exigences du client
Les exigences constituent une partie du contrat
entre le client (maîtrise d’ouvrage) et les
développeurs (maîtrise d’œuvre)
Cas d’utilisation
Exemple de rédaction

Titre: Passation de la commande au fournisseur


But: Transmettre une commande valide au fournisseur
Version, date de rédaction
Auteur de la rédaction
Acteurs du cas d’utilisation: acheteur
Préconditions:
Les demandes d’achat sont valides, elles ont été affectées à
l’acheteur qui initialise le processus.
Postcondition:
La commande est transmise, sa transmission est enregistrée
Événement initial:
Affectation des DA nouvellement arrivées à un acheteur
Description du scénario de base
Description des flots alternatifs
Diagramme de cas d’utilisation
Relations

Les cas d’utilisation peuvent être fractionnés.


Puis reliés.
relation « include »
relation « extend »
relation « generalise »
Cas d’utilisation
Relation « include »

Permet d ’identifier des sous-ensembles


communs à plusieurs cas d ’utilisation

comptable
« include » « include » Accueil
Contrôle adhérent
Règlement cotisations
Inscription activité
Contrôle adhérent est extrait de « Règlement cotisation »
et de « Inscription activité » afin de ne le décrire qu’une fois
Cas d’utilisation
Relation « include »

« include »
Cas d’utilisation
Relation « extend »

Accueil
« include »
contrôle adhérent

Inscription activité
Permet de décrire séparément
certaines partis alternatives, « extend » extension
optionnelles ou exceptionnelles

Inscription activité inexistante


Cas d’utilisation
Relation « extend »

L‘extension ne peut être


Accueil
activée directement « include »
contrôle adhérent
Inscription activité
Texte: La relation est indiquée dans le
« extend »
cas extension, ici inscription activité inexistante

L‘extension peut être planifiée dans un autre Inscription


activité inexistante
incrément que le cas d’utilisation de base
Cas d’utilisation
Relation généralisation

Plusieurs cas d’utilisation ont le même but

Ils ont des fonctionnements différents, Ce sont les variantes


d’une même fonction.
Cas d’utilisation
Relation Généralisation
« inc
lude
» »

contrôle comptable

Règlement cotisations
« Généralisation »

Règlement par courrier Règlement par Internet

adhérent
Exercice
Faire le modèle de cas d’utilisation
correspondant aux fonctions suivantes:
Contrôle des commandes client (la saisie des
commandes est faite chez le client par le commercial ou
au siège à partir d’un formulaire)
Réception des règlements
Dans ces 2 cas l’identité du client est contrôlée
Traitement des anomalies commandes

Le contrôle des commandes est sous la responsabilité


du commercial ou de l’administration des ventes. Le
comptable est responsable de la réception des
règlements
Exercice
Modèle de cas d’utilisation

Prise de commande Contrôle identité client


Commercial chez client
<<include>>
<<généralisation>> <<include>>

Contrôle commande Réception règlement Comptable

<<extend>>
Administration ventes Saisie commande
au siège

Traitement anomalies
commandes
Traiter le passage en
caisse

Titre : Traiter le passage en caisse


Résumé : un client arrive à une caisse avec des articles qu’il souhaite
acheter. Le caissier enregistre les achats et récupère le paiement.
A la fin de l’opération, le client part avec les articles.
Acteurs : principal caissier, secondaire client.
Pré conditions : la caisse est ouverte (donc en service) ;
un caissier y est connecté
Post conditions: Le client a payé, la vente est enregistrée,
le ticket de caisse a été donné au client.
Description du flot de base :
Ce cas d’utilisation commence quand un client arrive à la caisse avec des
articles qu’il souhaite acheter.
Le caissier enregistre chaque article. S’il y a plus d’un exemplaire par
article, le caissier indique également la quantité.
La caisse détermine le prix de l’article et ajoute les informations sur
l’article, à la vente en cours. La caisse affiche la description et le prix de
l’article en question.
Après avoir enregistré tous les articles, le caissier indique que la vente est
terminée. La caisse calcule et affiche le montant total de la vente.
Le caissier annonce le montant total au client.
Le client choisit le type de paiement :
E ncas depai
em ent cash, calculerla m onnai
eà rendre
La caisse enregistre la vente effectuée et imprime un ticket.
Le caissier donne le ticket de caisse au client.
Le client s’en va avec les articles qu’il a achetés.
Pour éviter les Si dans le flot de base
Les flots alternatifs sont décrits à part

Flot alternatif 1: numéro d’identification inconnu


Cette alternative démarre au point 4 du flot de base.
La caisse indique au caissier que le numéro d’identification de
l’article est inconnu. L’article ne peut alors être pris en compte dans
la vente en cours.
Le flot de base reprend au point 4.

Flot alternatif 2 : client ne pouvant pas payer


Cette alternative démarre au point 6 du flot de base.
Le client ne peut payer le total avec aucun moyen de paiement
autorisé.
Le caissier annule l’ensemble de la vente et le cas d’utilisation se
termine en échec (post condition non réalisée)
Flot alternatif 3: client payant par chèque

Cette alternative remplace le point 6 de la version de base.


Le chèque est mis par le caissier dans le lecteur de chèque
qui imprime le montant et la date
Le caissier fait signer le chèque.
Le flot de base reprend au point 7
Exercice
Cas d’utilisation paiement par carte
Ce cas d’utilisation remplace le point 6 du cas d’utilisation:
« Traiter le passage en caisse ». En cas de succès, le flot reprend
au point 7; en cas d’échec il reprend au point 6 de « Traiter le
passage en caisse »
Flot de base
1. Le client insère la carte dans le lecteur de carte et saisit son
code
Flot alternatif échec: Le code saisit est faux 3 fois de suite
à la suite du point 1

« extend » Payer par carte

Traiter le passage en
caisse
Diagramme cas d’utilisation
Le diagramme de cas d’utilisation montre le comportement d’un
système, les services visibles de l’extérieur, fournis par le système
dans le contexte de son environnement
Exemple: Téléphone mobile
Modélisation logique structurelle
Diagramme de classe
Architecture
du système d’information
du système informatique

Objets
Classes
Paquetages
Modélisation structurelle
Les objets

Un objet est « une chose »


qui peut être parfaitement
identifiée; une personne
précise, une organisation,
une machine ou un
événement peuvent être
considérés comme des
objets.
Modélisation structurelle
Les objets

Un objet peut sauvegarder des valeurs, ces valeurs ont un


nom (nom d’attribut)

.Ces valeurs constituent l’état de l’objet. l’état de l’objet peut


changer
Modélisation structurelle
Les objets

Un objet offre des


opérations (son
comportement) qui
permettent
d’examiner ou de
modifier son état.

L’état d’un objet garde le souvenir


de l’exécution des opérations
Modélisation structurelle
Les objets

Un objet est une instance de classe


3 représentations possibles d’un objet:

Valérie Valérie: Personne


: Personne
Date embauche =12-07-76

nom de l’objet nom de l’objet , Objet anonyme


nom de la classe
Modélisation structurelle
Les Classes
Les objets sont groupés en ensembles appelés classes.
Les objets sont des instances de classe.

Salarié Lili:Salarié
nom Instance de nom:Lili
Poste poste:DRH
salaire
3000 euros
payer()
Modélisation structurelle
Les classes
Une classe est une abstraction qui représente l’idée
ou la notion générale que l’on peut avoir d’un ensemble
d’objets similaire
Par exemple tous les salariés d’une entreprise
appartiennent à la classe « Salarié »

Tous les objets d’une classe partagent les mêmes attributs,


le même comportement et les mêmes associations.
Tous les salariés ont un salaire, chaque mois ils touchent
leur salaire, ils travaillent pour une entreprise.
Modélisation structurelle
Les Classes

Pendant la phase d’analyse une classe est un concept du


monde réel (ex : salarié, adhérent, prime)

Pendant la phase de conception elle peut être un concept


technique (ex : pilote d’imprimante, fenêtre…) elle est
affinée par des notions techniques (ex: visibilité)

Pendant la phase d’implémentation une classe est un


élément du logiciel
Modélisation structurelle
Les Classes
Chaque classe est représentée sous la forme d’un
rectangle divisé en 3 compartiments. Le 1er
compartiment contient le nom de la classe, le second
les attributs et le 3ème les opérations

Personne

adressePrincipale
nom

facturer ()
Modélisation structurelle
Les Attributs

Chaque nom d’attribut peut être accompagné de détails


facultatifs tels que le type ou la valeur par défaut.
Le type et la valeur par défaut seront généralement
mentionnés à partir de la phase de conception.

Personne

N om :chai ne
A ge:enti er
S olv ab i
li
té:Booléen=1
Modélisation structurelle
Les attributs dérivés

Un attribut dérivé peut être calculé à partir d’autres


attributs
On le trouve:
soit dans le compartiment attribut précédé d’une barre
oblique
soit dans le compartiment opération
C’est un choix de conception

Rectangle

Longueur
Largeur
/S urface
Modélisation structurelle
Les opérations

Une opération spécifie une action qu’un objet doit exécuter


Une méthode est une procédure qui implémente une opération

Généralement
En phase d’analyse, on écrit seulement le nom de l’opération
En phase de conception on écrit
La visibilité
Les paramètres
Le type de retour
La portée
Modélisation structurelle
Les opérations

« entité »
Portée de classe
Personne {auteur=Rémi}
adresse
nom
solde

Portée d’instance créer


Facturer ( remise : Int = 0, montant : Int ) : montantDu
Modélisation structurelle
La visibilité

UML définit 3 niveaux de visibilité pour les attributs et les


opérations

+ Public qui rend l’élément visible à tous les clients de la


classe ·
# Protégé qui rend l’élément visible aux sous-classes de
la classe
— Privé qui rend l’élément visible aux opérations de la
classe seule
Modélisation structurelle
La visibilité

Client


nom
— adressePrincipale

— enregistrer()

# facturer()

+ consulter nom()
Modélisation structurelle
Les relations

L’association
La généralisation
La dépendance
La réalisation
Modélisation structurelle
L’association
Il existe des liens entre les objets

Exemple:
Les commandes sont liées aux clients

Client Passe > Commande


raisonSociale 1 *
dateCommande
Modélisation structurelle
Multiplicité
Un objet peut être relié à plusieurs objets:
Un client peut être relié à plusieurs commandes.
Mais une commande ne peut être reliée qu’a un seul
client
et elle est nécessairement reliée à un client.
Modélisation structurelle
La multiplicité s’écrit :

1 toujours 1
0..1 0 ou 1
* ou 0..* 0 à plusieurs
1..* 1 à plusieurs
m..n de m à n (entiers naturels)
Modélisation structurelle
Classes d’association

Chaque lien de l’association est relié à un objet de la classe association.


Chaque objet de la classe association est identifié par les références aux
classes reliées ; Il ne peut y avoir plusieurs liens entre les mêmes objets
On indique cette classe si le lien est porteur d’attributs ou d’opérations .
Une classe d’association peut être associée à d’autres classes

Personne * ** Diplôme
nom niveau

DiplômeObtenu
date obtention
Modélisation structurelle
Rôle

Un rôle décrit la part prise par une classe dans une


association, il est écrit sur l’association du coté de la
classe correspondante
Le rôle permet de distinguer plusieurs associations
entre les 2 même classes

résident 1
Personne *
travailleur Ville
nom * *
Modélisation structurelle
Associations qualifiées
Le qualificatif permet de retrouver 1 ou n objets à l’autre
bout de l’association il sélectionne certains objets)
Nom de fichier est un identifiant relatif pour Fichier

1
Répertoire 1 Fichier
Nom de fichier

* 1
Banque compte Personne
Modélisation structurelle
Associations qualifiées
Exercice

Comment modéliser les chambres d’une chaîne


d’hôtels en indiquant que les hôtels ont la liberté de
leur numérotation
Modélisation structurelle
Contraintes d’intégrité sur
association

Statue

{ ou exclusif } Commune Personne


Musée Site

Sous-ensemble
Modélisation structurelle
Association réflexives
Un objet d’une classe peut être associé à un autre
objet de la même classe

Personnel chef
1

collaborateur 1..*
Modélisation structurelle
Associations n-aires

Des associations peuvent relier plus de 2 classes


Joueur

Équipe Année

Record
Gain
Exercice
Représentation principal
Spectacle
Date représentation Acteur
metteur en scène
Heure représentation * 1 0..* 1..*
Tarif
Prix place
* *
*
réserver

Billet Réservation
num billet vendre Agence
Date réservation
1..* * 0..* 1
*
Catégorie Place
1 *
Modélisation structurelle
L’agrégation

L’agrégation est une forme particulière d’association qui


exprime un couplage plus fort entre classes.

L’agrégation permet de représenter les relations de type


maître esclave, tout et partie, ou composé et
composant.

Mission *
Développeur

Agrégation simple
Modélisation structurelle
Agrégation de composition
L’agrégat « possède » ses parties,
Les partie sont « à l’intérieur » de l’agrégat ; Un objet ne
peut être l’élément de plusieurs agrégats.
La destruction de l’agrégat entraîne la destruction des
parties

Commande 1
LigneDeCommande Article
1..*
quantitéCommandée * 1 référenceArticle
préparer
Exercice

Un médecin veut modéliser des informations concernant


ses patients, leurs consultations, leurs maladies.
Exercice

Patient Consultation
1 0..*
Date

Maladie
Modélisation structurelle
Généralisation et spécialisation

La généralisation consiste à factoriser les éléments


communs (attributs, opérations, relations) d’un
ensemble de classes dans une classe plus générale
appelée super-classe.
Les sous-classes héritent des caractéristiques de
leur super-classe
Modélisation structurelle
Généralisation et spécialisation

Tiers Banque
raisonSociale Code

Client Fournisseur

facturer() régler()
Modélisation structurelle
Généralisation et spécialisation
Tiers Banque
raisonSociale Code

Client Fournisseur

facturer() régler()

ClientNat ClientExport Devise


Modélisation structurelle
Généralisation et spécialisation
Site Objet Nation
Code

Bâtiment ObjetMobile Musée

Statue Bijou Particulier


Modélisation structurelle
Contrainte d’intégrité sur
généralisation
Objet Objet

Statue Bijou Statue Bijou


Modélisation structurelle
Classe abstraite
Une classe abstraite ne peut être instanciée, ses sous-classes sont
concrètes

Classe abstraite
Activité
nom activité
montant

planifier()

Classe concrète

Tennis Foot

planifier() planifier()
Modélisation structurelle
Représentation de l’architecture

Une bonne architecture doit permettre:


La réutilisation
La répartition du travail entre équipes
L’étude d’impact lors des changements fonctionnels,
techniques et d’explitation
Modélisation structurelle
Représentation de l’architecture

UML offre des notations destinées


à découper
Le système d’information
Le logiciel
À isoler les éléments du logiciel
Représentation de l’architecture
Les Paquetages
Représentation de l’architecture
Les Paquetages
Modélisation structurelle
Représentation de
l’architecture
Architecture technique
1 paquetage= n éléments
1 composant=1 ou n classes
Modélisation structurelle
Représentation de l’architecture
Les Paquetages
livraison article
Classe livraison (from vente) (from stock)
appartient à vente

Le paquetage vente Commercial::Vente


appartient à commercial + commande stock
+ client +stockFaçade
— livraison _article
Classe non visible
_ entrepôt
à l’extérieur du
paquetage

dépendance
commercial java.io

Paquetages leur contenu et leurs dépendances


Modélisation de la dynamique du
système
Diagrammes d’interaction
Diagramme de séquence
Diagramme de communication

Diagramme d’activité

Diagramme État-Transition
Modélisation de la dynamique du
système
Les diagrammes d’interaction et d’activité
précisent le texte du cas d’utilisation

Cas d’utilisation
flot de base
Flots alternatifs

n diagrammes de séquence Diagramme de classe


n diagrammes d’activité
Modélisation de la dynamique
Diagramme de séquence
Un diagramme de séquence représente un ou plusieurs
scénarios d’un cas d’utilisation (cas d’utilisation parent)

Pour un cas d’utilisation, il peut y avoir autant de


diagrammes de séquence qu’il y a de scénarios
Modélisation de la dynamique
Diagramme de séquence
Le diagramme de séquence transforme la structure
fonctionnelle, décrite par le cas d’utilisation en une
structure objet

Il représente les messages que les objets doivent


s’échanger pour réaliser la fonction.

Ces messages sont des appels d’opérations ou de


groupes d’opérations. Ils sont effectués par des objets
vers des objets.

Les objets sont des acteurs ou des objets logiciels.


Modélisation de la dynamique
Diagramme de séquence
Un objet de la classe
Acteur activité

: adhérent : activité
: Accueil

Message
Demande inscription activité La flèche est dans le
sens du flux de contrôle
inscription

Demande supplément cotisation


Période d’activité
de l’objet

Paiement
Ligne de vie de l’objet
Modélisation de la dynamique
Diagramme de séquence

Un objet ou un participant peut être anonyme,


identifié, qualifié

: adhérent Martin : adhérent adhérent actif

: adhérent

Adhérent est ici


un objet du logiciel
Modélisation de la dynamique
Diagramme de séquence, concepts
Modélisation de la dynamique
Diagramme de séquence, concepts

Événements (ou messages)


Un diagramme de séquence montre les
messages que les objets s’échangent.
Ces messages sont des événements :
Ils déclenchent des opérations sur les objets
destinataires
Ligne de vie
Modélisation de la dynamique
Diagramme de séquence
Exercice
Faire le diagramme de séquence correspondant à cet extrait du
cas d’utilisation Règlement cotisations
Suite à un appel de cotisation (qui a été fait longtemps avant et qui, par
conséquent est décrit dans un autre cas d’utlisation) les adhérents paient leur
cotisation, le paiement est enregistré, les appels de cotisation correspondants
sont mis à jour, un accusé de réception est retourné à l’adhérent

Paiement

Adhérent Règlement cotisations

AppelCotisation
Modélisation de la dynamique
Diagramme de séquence

unPaiement unAppel
: Adhérent
Cotisation

paiement
cotisation
accuséRéception
Client théatre : : Spectacle : : Place Paiement
: Client
Activité Représentation

Contrôle client

[client pas OK]


Contrôle activité

[activité pas OK]

[Réservation OK]
Diagramme de séquence
Représentation des paramètres

: Client Client

Demande réservation(code client,code activité)


Diagramme de séquence,
Représentation de plusieurs
scénarios

adhérent Un paiement Un appel cotisation

paiement

cotisation

Qualité du montant

Accusé réception [Si montant OK]

Avis solde [Else]


Diagramme de séquence,
Représentation de plusieurs scénarios
Exercice

le service commercial doit la contrôler


Si elle n’est pas correcte, l’annuler Recevoir la commande

Si elle est correcte,


Faire le bon de livraison
Faire la facture
Dans tous les cas mémoriser son état
Recevoir la commande

[Commande pas OK]

[else]
D iagram m e de séquence: R eprésentation d’une 
itération Par un cadre d’interaction

15 octobre
Diagramme de séquence,
Représentation d’une itération

A la réception de la commande:

le service commercial doit la contrôler


Il saisit la commande
Il contrôle que chaque article est en stock
Sinon, il annule l’article
Si la commande est OK
Il fait la facture
Recevoir la commande
Modélisation de la dynamique
Diagramme de communication
1. paiement :Paiement

2:cotisation
3.

: Adhérent
Ac
cu

de
3.
Av


ce olde
is

pt
de

io
s

n
[m art]
on

ta
c

nt
O
K]

: Appel cotisation
Modélisation de la dynamique
Diagramme de communication
1. paiement :Paiement

2:cotisation
3.

: Adhérent
Ac
cu

de
3.
Av


ce olde
is

pt
de

io
s

n
[m art]
on

ta
c

Flux de contrôle
nt
O
K]

Message
: Appel cotisation activité
adhérent
Classes correspondantes
nom activité
nom adhérent
montant
* *
Modélisation de la dynamique
Diagramme de communication
1. paiement :Paiement

2:cotisation
3.

: Adhérent
Ac
cu

de
3.
Av


ce olde
is

pt
de

io
s

n
[m art]
on

ta
c

Flux de contrôle
nt
O
K]

Message
: Appel cotisation
2: Contrôle client

1: Demande réservation 4: Contrôle activité 6:


Client théatre : : Spectacle
Activité
3: [client pas OK] 5: [activité pas OK] 11:
: Client 15: [Réservation OK] 12:
14: 13: 10: 7:

: Représentation
Paiement

9: 8:

: Place
Diagrammes d’interaction
et démarche
Diagramme de séquence
Interactions entre les acteurs et le système (Analyse des besoins)
Interactions entre les objets logiciels (Analyse du problème et
conception)

Diagramme de communication
Interaction entre les acteurs (Analyse des besoins)
Diagramme de flux (Analyse des besoins)
Interaction entre les objets logiciels
(Analyse du problème et conception)
(surtout s’il n’y a pas de chronologie ou si on veut montrer les liens entre
les objets)
Modélisation de la dynamique
Diagramme d’activité

Permet de représenter une logique procédurale, un processus


métier, un workflow
On peut représenter le déroulement des actions dans des
chemins alternatifs ou parallèles
Modélisation de la dynamique
Diagramme d’activité
Nœud initial
Enregistrer
la commande

Contrôler Commande
Action

Sortir article

Expédier Commande
Nœud final
Diagramme d’activité
Partitions
Client Ventes Entrepôt

Enregistrer Ressource
la commande

Contrôler Commande

Sortir article

Expédier Commande
Diagramme d’activité
Décisions
Client Ventes Entrepôt

Contrôler Commande

Sortir article
OU [OK] Sortir article

[Pas OK]
Annuler Expédier Commande
Commander
la commande

OU

Enregistrer état Commande


Modélisation de la dynamique
Diagramme d’activité
Exercice
Lorsque le réveil sonne, prendre le petit déjeuner puis
préparer le cartable (sauf le mercredi) puis, dans tous les
cas, se laver
Sonnerie réveil

Déjeuner

mercredi? non

oui Préparer
cartable

Se laver
Les diagrammes d’activité
Barre de synchronisation
administration Ventes Entrepôt

Contrôler Commande
Contrôler Commande
Barre de synchronisation
(fork)
[Pas OK]

[OK]

Préparer
Préparer bonbon
livraison ET Préparer Commande
livraison

Barre de synchronisation
(joint)
Commande expédiée
Les diagrammes d’activité
Barre de synchronisation

Explication du schéma précédent


Si le contrôle de la commande est satisfaisant (OK) on peut faire le bon de livraison
et préparer la commande, dans n’importe quel ordre successivement ou
parallèlement
Pour expédier la commande il faut que sa préparation soit terminée et que le bon de
livraison soit fait
Exercice lorsque le réveil sonne
Lorsque le réveil sonne, l’homme commence par prendre sa
douche.
Au sortir de la douche, il réveille sa femme et effectue sa
gymnastique
Ensuite, il prépare le petit déjeuner pour sa famille, et enfin prépare
la voiture pour le départ

La femme, à son réveil, fait sa toilette matinale, puis prépare les


cartables des enfants – sauf le mercredi – et enfin prend son petit
déjeuner avec les enfants.
Tout le monde se retrouve ensuite en voiture l’homme fait
l’inspection finale et la mise en route.
Homme Femme
Sonnerie réveil

Douche

Gym Toilette

Mercredi?

[ Non ] [ Oui ]
Préparation
petit déjeuner Préparation
cartable

Préparation
voiture
Petit
déjeuner

Famille en route Inspection et


mise en route
Les diagrammes d’activité
Décomposition d’une action
Les actions peuvent être décomposées en sous-activités.
On peut ainsi décrire un processus globalement puis
l’affiner progressivement
Réception
commande

Exécution
commande Envoi facture

Livrer
Traitement
paiement

Clore
l'ordre
Livrer

Livraison
normale
Exécution
Clore
commande l'ordre
Livraison
urgente
Exercice
Détailler l’exercice: « lorsque le réveil sonne »
Pour préparer le petit déjeuner l’homme sort les
ingrédients
Si le café manque, il prend du thé.
Il prépare soit le thé soit le café
Il dresse la table
Gym

Homme en forme

Préparation petit déjeuner


Sortir
ingrédients

Préparer Préparer thé


café

Dresser la
table

Préparation
voiture Petit
déjeuner
Les diagrammes d’activité
Invocation d’une méthode
Dans une action, on peut invoquer une méthode

Livrer

Livraison
normale Clore
Exécution l'ordre
commande Ordre::SuppressOrder
Livraison
urgente Nom de la classe Nom de la méthode
Les diagrammes d’activité
Signaux
Signal temporel
Une activité écoute ces signaux en permanence, ils
constituent un événement d’un processus extérieur, le
diagramme définit comment l’activité réagit à ces
événements
2 heures Faire les
bagages
avant le vol
Partir pour
l'aéroport

Taxi
arrive
Exercice
Une commande Fournisseur est rédigée puis envoyée
A la réception de l’accusé de réception, la commande est
validée.
Si 2 semaines après l’envoi de la commande, l’accusé de
réception du fournisseur n’est toujours pas parvenu, la
commande est annulée
Région d’expansion

Une région d’expansion délimite dans un diagramme


d’activité une zone ou les actions s’exécutent une fois
pour chaque élément d’une collection
Choisir un thème

Ecrire Relire Publier


l’article l’article la revue

« concurrent »
Contrôle client

Existence de Contrôle stock Etablir


l’article de l’article la facture
Modélisation de la dynamique Les
diagrammes d’activité
Activités et flot d’objets
Dans un diagramme d’activité, il est possible de faire
apparaître clairement les objets créés, détruits ou
modifiés, par une activité. .
Les objets modifiés sont indiqués par des flèches en
pointillé.

Etablir Devis Commande


r
Modélisation de la dynamique Les
diagrammes d’activité
Client et flots d’objetsVentes
Activités Entrepôt

Enregistrer
la commande

Contrôler Commande

Décision [OK] Préparer


commande

[Pas OK]

Expédier Commande
Commande annulée

Commande expédiée
Modélisation de la dynamique
Diagramme État-Transition
Concepts
État
Un objet passe par différents états au cours de son
existence

Un état est une situation au cours de la vie d’un objet


pendant la quelle il satisfait certaines conditions,
exécute certaines activités ou répond à certains
événements

L’état d’un objet est matérialisé par la valeur de certains


de ses attributs et par ses liens
Modélisation de la dynamique
Diagramme État-Transition
Concepts
Modélisation de la dynamique
Diagramme état-transition

Le diagramme d’états-transitions représente:


Les différents états possibles d’un objet
Les opérations qui peuvent être exécutées dans cet état
Les événements qui provoquent des transitions d’un
état à un autre.
Diagramme état-transition
commande Evénement déclencheur
Etat initial
prise en compte commande

Opération longue
Durée de l’état
commande en enregistrement Opération courte
entry: contrôle client pendant l’état
do: contrôle article
Urgence / priorité
Événement qui ne change pas l’état exit: décision

condition
[ non ] [oui ]

Activité
commande invalide
commande valide Envoi d’événement
entry: mise en attente
exit/^: bon de préparation

[ stock OK ] / ordre de servir Opération courte pendant


la transition
Commande refusée
commande servie
Etat final
Modélisation de la dynamique
Diagramme état-transition
Plusieurs types d’opérations:
Une opération longue ou activité
se prolonge autant que dure l’état
est précédée de la mention do:
Opérations courtes ou actions
pratiquement sans durée:
Modélisation de la dynamique
Diagramme état-transition
Opérations courtes ou actions, pratiquement sans
durée:
Précédées de entry lorsqu’elles s’exécutent au moment ou
l’objet entre dans le nouvel état
Précédées de exit lorsqu’elles s’exécutent au moment ou
l’objet sort d’un état
Précédées de:
/ lorsqu’elles sont déclenchées par un événement
Modélisation de la dynamique
Diagramme état-transition
Conditions

Les conditions sont encadrées par des crochets


Une condition peut avoir une certaine durée
alors qu’un événement est instantané
Modélisation de la dynamique
Diagramme état-transition

Monter le diagramme d’états-transitions représentant les


différents états que peut prendre, au sens de l’état civil, la
classe INDIVIDU
Jugement de divorce
MARIÉ DIVORCÉ
Contrat de
mariage signé Contrat de mariage signé

Décès
individu

Décès conjoint
VEUF

Contrat de mariage signé


Naissance

CÉLIBATAIRE DÉCÉDÉ
iDécès individu

Contrat PACSE signé

Contrat PACS
signé Contrat PACSE signé
PACSÉ
Rupture contrat
Modélisation de la dynamique
Diagramme état-transition Sous-
état
Un sous- état est un état emboîté dans un autre état.
Un état composé peut contenir soit des sous-états
concurrents, soit des sous-états séquentiels
Modélisation de la dynamique
Diagramme état-transition Sous-
état
Sous-état séquentiel
Plante en croissance

do: Arroser
Plante non mure

Plante à maturité
on
Disponibilité[
Disponibilité[
temps
temps
favorable
favorable
] / Récolter
]: Récolter

Plante récoltée
Modélisation de la dynamique
Diagramme état-transition Sous-
état
Plante semée

Plante en hibernation

Plante en croissance

Plante récoltée
Modélisation de la dynamique
Diagramme d’états concurrents et
Emission

synchronisation
do: Distribuer billets
exit: billets pris Prêt à initialiser
Préparation

do: éjecter carte


exit: carte prise
La modélisation de l’implémentation
Les Composants
Les composants sont des éléments physiques comme
les exécutables, les composants Com, les EJB, les
bibliothèques, les tables, les fichiers et les documents

Un composant peut réaliser une interface définie dans


le modèle logique

Généralement, les services d’un composant sont


disponibles uniquement à travers leur interface
a modélisation de l’implémentation
Les Composants, organisation
On peut regrouper les composants en
paquetages
Les composants sont des éléments de la
gestion de configuration.
On détermine les composants à partir des cas
d’utilisation et des postes de travail. Les
composants sont distribués sur les postes de
travail
La modélisation de l’implémentation
Les Composants
La distribution des composants permet un
découplage entre les applications et le métier
et facilite
La réutilisation
La maintenance
La flexibilité
modélisation de l’implémentation
Développement par composants

On créé un système à partir de composants,


On le fait évoluer
En ajoutant de nouveaux composants
En remplaçant les anciens
Sans avoir à reconstruire le système
grâce aux interfaces
La modélisation de l’implémentation
Diagramme de composants
Livraison Servir Le composant Servir
contient les classes
Article et Entrepôt
disponibilité

<<Interface>>
disponibilité Article

+contrôle stock() +contrôle stock()


+préparation()

livraison

Entrepôt

+préparation()
Modélisation du déploiement

Nœud
Un nœud représente une ressource de calcul
Un composant peut être déployé par un ou
plusieurs nœud
Diagramme de déploiement
Servir
Serveur

Client 1 Client 2

Livraison
Description des processus
De l’analyse des besoins à la conception

:


t
a
l :
so
l :
pl
an
te:
co
mm
a
nd
e:c
l
i
ent
: client système
systè
:
cl
i
ent
:
c
ot
i
se
r c
l
i
en
t
A
c
he
t
er
effectuez votre choix

type de végétal

pourquoi?(de l'ombre?des fruits?des fleurs?)


des arbres

nature du sol
idem

ensoleillement
idem

réponse
idem
Planche de fruits
des fruits

choix de fruit
idem

planche de fleurs
des fleurs
choix de fleurs

idem

planche de silhouettes
de l'ombre

choix de silhouette
idem

liste de choix possibles


Cas d’utilisation 1
1 1..*
Scénario
1..*
Opération système 0..* 0..1
DiagrammeSéquence

système
systè

Diagramme séquenceDiagr.
système
séquence objets logic
: client

effectuez votre choix

type de végétal

pourquoi?(de l'ombre?des fruits?des fleurs?)


des arbres

nature du sol
idem

ensoleillement
idem

Représentation du dialogue entre l’acteur et le sys


réponse
idem
Planche de fruits
des fruits

On représente les flux de données


choix de fruit
idem

Quelles données sont saisies


planche de fleurs
des fleurs
choix de fleurs

idem

Quelles données sont affichées.


Eventuellement les traitements importants effectués par
planche de silhouettes
de l'ombre

choix de silhouette
idem

liste de choix possibles


Les opérations système

Exemple : RespFormation

gestion Catalogue

:système
: RespFormation

creerFormation( )

initialiserFormation (titre, durée, prix)


Opérations système
creerContenu( )

creerContenu( audience, prerequis, objectifs, outils, plan )


Conseil
creerSession() Un diagramme de séquence par
fonction
creerSession(date debut, lieu) (Créer, Modifier, Supprimer,
Editer, ../)
Identifier les opérations système

:système
: Utilisateur :Système

creerFormation( )
creerFormation()
initialiserFormation (titre, durée, prix) creerContenu()
creerContenu( )
creerSession()
creerFiliere()
creerContenu( audience, prerequis, objectifs, outils, plan ) modifierFormation()
modifierContenu()
creerSession
modifierSession()
creerSession(date debut, lieu) modifierFiliere()
…..
Description des
données

Référence matière,
Adresse de l'élève,
Nombre d'heures,
Nom de la classe,
Nom de l'élève,
Nom du professeur,
Valeur de la note,
Numéro de salle,
Prénom de l'élève
Elève
Classe
nomElève appartient
nomClasse
prénom élève
numéroSalle
adresseElève * 1

0..*
*

Elève/Matière 1..* * Classe/Matière


ValeurNote NombreDheures
Matière
référenceMatière
nomProfesseur