Uml masterGI

1.
Etude de Cas
Conception de Systèmes d’Information – S1
SI d ’un bureau d ’étude

Hydraulique
Michel TOLLENAERE professeur laboratoire GILCO

Dominique RIEU Professeur laboratoire LSR/équipe SIGMA
Eric BLANCO Maître de Conférence laboratoire GILCO
Khadidja GREBICI doctorante laboratoires GILCO / LSR.
 JP mP
1.
2
Conception de Systèmes
d ’Information
Cours : Systèmes d ’Information

Michel TOLLENEAR
Dominique RIEU.
 JP mP
1.
3
Notion de modèle
 Qu’est ce qu’un modèle ? (Minsky 1968)

A* est un modèle de A pour un observateur O
ssi A* aide O à répondre aux questions qu’il se pose sur A.
Observateur Modèle
Système observé
Où sont construites les ailes ?
 JP mP
1.
4
notions de base: objet, acteur, collaboration,

activité, Evénements, scénarios, états…
 Objet: entité d ’un monde réel ou virtuel, capable de sauvegarder un

état (une information) et qui offre des opérations (un comportement)
pour observer ou modifier cet état.
 Acteur: classe d ’utilisateur du système, personne physique ou morale,
entité fonctionnelle ou organisationnelle.
 Activité: opération interruptible exécutée durant un état zone
d ’activités
 Collaboration: interaction entre objets collaborants.
 Relation: dépendance entre entités.
 Paquetage: partition du modèle.
 Cas d ’utilisation: manière dont les acteurs utilisent le système.
 JP mP
1.
notions de base: objet, acteur, collaboration, activité, Evénements, scénarios, états… 5
 Un événement est un stimuli externe visible, avec ses réponses. On commence la modélisation
dynamique par l'extraction d'un résumé des séquences d'événements ; pour chaque objet il faut établir
un diagramme d'états avec les événements entrants et sortants et qui montre les interactions entre
objets. On n'établit pas d'algorithme, ce qui relève de l'implantation, si l'événement n'est pas externe.
Ces diagrammes sont essentiels pour les systèmes interactifs, contrairement aux systèmes statiques
comme les Bases de Données. Il faut aussi noter qu'ils ne sont pas suffisants pour les systèmes temps
réel.
 Un scénario est une séquence type d'événements, il permet de décrire les interactions courantes pour
l'extraction des événements et l'identification des objets cibles. Le suivi des séquences et des états
permet d'établir les diagrammes d'états et de les comparer afin d'obtenir la correspondance événement-
objet. L'ensemble des diagrammes d'état définit le modèle dynamique.
EXEMPLE
 Un état est une abstraction des valeurs des attributs et des liens d'un objet. Ces60valeurs
Plus de ans sont groupées
selon les propriétés qui affectent le comportement de l'objet. Il faut établir, pour chaque objet non
trivial un diagramme d'états qui décrit ses événementsACTIVITE
d'entrées et de sortie. Un scénario correspond à
un chemin dans un tel diagramme. Pour ce faire il faut considérer un objet unique et ses interactions
type, ce qui définit un chemin constitué d'und ’emploi
Perte ensemble d'arcs étiquetés par les RETRAITE
recrutement événements d'une
colonne du suivi. L'intervalle entre deux événements correspond à une activité continue ou qui prend
du temps ; c'est un état, représenté par un noeud et auquel on peut donner un nom si nécessaire. La
modification d'un état par un événement donne lieuCHOMAGE
à une transition.
Plus de 60 ans
 JP mP
1.
6
Axes de modélisation d ’un système

Statique (ce que le système EST)
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Dynamique
(comment le système
Fonctionnel
EVOLUE)
(ce que le système FAIT)
• diagramme de séquence
• diagramme de collaboration • diagramme de cas d’utilisation
• diagramme d’états-transitions • diagramme de collaboration
• diagramme d’activités • diagramme FAST
 JP mP
1.
7
Révision UML
 UML: Définition
 UML: Bibliographie et sites.

 UML: Genèse
 pourquoi UML?
 UML, modèles et diagrammes, parcours général
 Les Données : diagramme de classes - structure statique
 Organiser les documents : les packages
 Analyser par les Cas d’Utilisation
 Compléments sur les langages et concepts
 JP mP
1.
8
•langage semi formel

•analyse et conception
orientée objet
•une notation
• une méthode: « the
Unified Software
Development Process
•outils : rational Rose,
objecteering...
 JP mP
1.
9
Bibliographie
 « MODELISATION OBJET AVEC UML » P.Muller N.Gaertner, Editions Eyrolles
- mars 2000
 « UML EN Action : de l’analyse des besoins à la conception en Java »

P.Roques F.Vallée, Editions Eyrolles - février 2000
 «Advanced Object-Oriented Analysis & Design Using UML», Odell J., SIGS
Publications, 1997.
 « UML DISTILLED : A Brief Guide to the Standard Object Modeling Language »
M.Fowler K.Scott, Addison & Wesley - août 1999
 « LE GUIDE DE L’UTILISATEUR UML » G.Booch I.Jacobson J.Rumbaugh,
Editions Eyrolles - février 2000
 « LE PROCESSUS UNIFIE DE DEVELOPPEMENT LOGICIEL » I.Jacobson
G.Booch J.Rumbaugh, Editions Eyrolles - juin 2000.
 « UML POUR L’ANALYSE D’UN S.I. : Le cahier des charges du maître
d'ouvrage » C.Morley J.Hugues B.Leblanc, Dunod - février 2000
 « Business Modeling with UML : Business Patterns at work »
H.Eriksson M.Penker Wiley & Sons - janvier 2000
 « Concevoir des application Web avec UML » , J.Conallen, Eyrolles, sept 2000
 JP mP
1.
10
Bibliographie
 « Unified Modeling Langage Reference Manual », J.Rumbaugh I.Jacobson
G.Booch, Addison-Wesley, 1998.
 « UML en Action », Pascal Rocques, Vallée F , Eyrolles, 2000.
 JP mP
1.
11
Des sites...
 Des sites en français
– //www.uml.crespim.uha.fr/ (site de mulhouse)

– //free.uml.fr/
 Des sites industriels
– //www.rational.com/uml
– //www.objexion.com/
– //www.softeam.fr/
 Des livres sur UML répertoriés par
– //www.eyrolles.fr/php.informatique/Ouvrages/liste_ouvrages
 JP mP
1.
12
Genèse d’UML
Révision UML 2.0 2002
Révision
UML 1.4 2000
Mineur
UML 1.3 1999

UML 1.2 1998
Novembre : Acceptation
UML 1.1
1997
Septembre : soumission final 1997

UML 1.0
Janvier : soumission OMG
UML 0.9 1996
Spécification Méthode
1995
sur internet unifiée 0.8
Autres OOAD OMT OOSE

Partenaires
Méthodes Booch Rumbaugh... Jacobson...
 JP mP
1.
13
Pourquoi UML ?
 Besoin d’un Langage de Modélisation  Pour Documenter
– notation claire des diagrammes – les besoins
– de modèles variés/points de vue – l’architecture

– flexibilité – la conception
– unificateur – le codage, les tests....
 Besoin d’un Processus de  Dans X Environnements de

Modélisation (dirigé par les cas systèmes à support logiciels :
d’utilisation) – SI de l’entreprise
– modèles et vues intégrant – Systèmes bancaires, financiers
l’architecture – Télécoms, transports
– itératif et incrémental – Aérospatiale, scientifique
– non standard mais à ADAPTER... – Électronique, médical
– Services Web
 JP mP
1.
14
UML, Modèles et Diagrammes

Parcours Général
 JP mP
1.
15
Un Modèle = Un point de vue sur le système

 Modèle de Classes qui capture la structure statique
 Modèle des Cas d’Utilisation – Use Case, UC – qui décrit les

besoins, les fonctions
 Modèle d’Interaction qui représente les scénarios et les flots de
messages
 Modèle des États qui exprime le comportement dynamique des
objets, classes...
 Modèle de Réalisation qui montre des unités de travail
 Modèle de Déploiement qui précise la répartition des processus
 Descriptions abstraites pour capturer la sémantique d’un système
 JP mP
1.
16
Diagrammes
Diagrammes
Classes Objets Séquence Collaboration Activités
Cas d'Utilisation États-Transitions Composants Déploiement
 JP mP
1.
Diagrammes
17
lien d’héritage : «est un diagramme»,

chacun est une spécialisation de la classe diagramme
Diagrammes
Un diagramme est un « langage graphique » de phrases traduisant

entre les concepts « éléments du vocabulaire du diagramme », icônifiés aux nœuds
des relations matérialisées par des arcs du graphe, écrits avec un forme particulière.
L’ensemble donne la syntaxe, graphique du langage associé
 JP mP
1.
Diagrammes
18
Diagrammes
Ce que le système
 Aspects structurels statiques EST
 diagramme de classes : classes et relations statiques
 diagramme des objets : objets et liens
 Aspects fonctionnels et dynamiques Ce que le système
FAIT
 diagramme de cas d’utilisation : acteurs et utilisation du
 système
 JP mP
1.
Diagrammes
19
Diagrammes
 Aspects dynamiques
 diagramme de séquence : vision temporelle des interactions comment le système
 diagramme de collaboration : vision spatiale des interactions EVOLUE
 diagramme d’états-transitions : comportement des objets
 diagramme d’activités : flot de contrôle interne aux opérations
 JP mP
1.
Diagrammes
20
Diagrammes
 Aspects implantation
 diagramme de composants : codage
 diagramme de déploiement : implantation, distribution
 Les diagrammes des classes physiques participant aussi à cette description
 JP mP
1.
21
Organiser les documents,

Les Packages
 JP mP
1.
22
Structurer : Package
 Unité de stockage d’un ensemble d’informations variées ayant trait à
une même unité d’information pour l’application modélisée.
 Appliqué selon
plusieurs points de vue : Pkg-projet
package exigences Pkg-exigences

package analyse Pkg-analyse
package conception
package réalisation Pkg-conception «trace»
Pkg-conception
package maintenance
Pkg-réalisation
«realise»
Pkg-réalisation
Pkg-réalisation Pkg-maintenance
Vue cycle de développement Pkg-maintenance
Pkg-maintenance
 JP mP
1.
Structurer : Package
23
Graphisme
 Chaque package peut avoir divers modèles (UC, Classes, textes, ….)
lesquels constituent une unité de documentation pour le niveau
auquel on se trouve….
– Analyse
– Conception Gérer une compagnie
d'aviation
– Réalisation
Gérer le parc
Gérer les
réservations
Gérer le Gérer la politique

réseaux commerciale
 JP mP
1.
24
Analyser par les Cas d’Utilisation,
Cas d’Utilisation,
Scénarios : Collaborations et Séquences
 JP mP
1.
25
 Un CU est :

Diagrammes de Cas d’Utilisation
une réponse à la question « dans quel cas tel acteur utilise-t-il le système?. C ’est un ensemble d ’interactions entre acteur et système.
 une technique d ’expression des besoins mise en œuvre par Ivar Jacobson (objectory).
 une manière spécifique d’utiliser un système
 représenté dans un diagramme de CU faisant référence aux acteurs, i.e: « choses » externes au système qui communiquent avec ce dernier (principaux, secondaires, matériels ou non) et aux relations (communication, utilisation, extension)
 de propriétés :
 - exclusivité les uns des autres, le système est dans une situation donnée pour un acteur donné et à un instant donné.
 - couverture d ’une utilisation complète depuis la connexion jusqu ’à la déconnexion.
 L’analyse d’un cas d’utilisation par des scénarios :
 Diagrammes de Collaboration (modèles organisationnels)
 Diagrammes de Séquence (modèles chronologiques)
pour des regroupements et la mise en évidence des objets et des cas d’utilisation
 JP mP
1.
26
 Modéliser le comportement d’un :

– élément,
– système,
– sous-système,
– classe. <<include>>
Virement
Client
« généralise »
Identification
Virement minitel
Client distant
 Un acteur fait avec le système qui lui offre ce service :

– « un client fait un virement »
 Ce que fait l’élément et NON Comment il le fait
 JP mP
1.
27
Exemple1 : Réserver sur un vol à une date donnée

 Le client interroge le système, soit en passant dans une agence, soit par un système
télé-informatique (minitel ou internet) pour s’assurer de pouvoir faire la réservation
souhaitée.
 La réservation peut concerner un déplacement de passagers (un ou plusieurs) ou une
demande de transport de fret.
 Une solution réalisable étant trouvée, il enregistre la réservation (nom des passagers
ou volumes et caractéristiques du fret) et paye par le moyen adapté à l’environnement
(liquide, chèque, carte de crédit).
 Le ou les billets correspondants lui sont délivrés (directement, à l’agence, par la
poste, par mise à disposition à l’aéroport pour télépayement ou aussi par impression
de bons de transports sur connexion internet.
une note est attachée

à tout UC, pour définir
son rôle et son contenu
Réserver
Client
 JP mP
1.
28
Exemple 1 – Requirements
(Système) RESERVER
Interroger au guichet
Interroger possibilité-vol
Interroger par le net
Généralisation/spécialisation selon les « modes d ’accès »
Client
Vue analyse des besoins :

un acteur, le client
Le diagramme d’UC du package RESERVER, décompose l ’UC RESERVER
 JP mP
1.
Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements
29
(Système) RESERVER
enregistrer réservation
Client
Vue analyse des besoins
 JP mP
1.
30
(Système) RESERVER
enregistrer réservation Spécialisation par

enregistrer fret l’objet du transport
Client
enregistrer passagers
 JP mP
1.
31
(Système) RESERVER
enregistrer fret
Client
payer enregistrer passagers
 JP mP
1.
32
(Système) RESERVER
enregistrer fret
Client
payer enregistrer passagers
obtenir billets
 JP mP les liens d’activation du système

1.
33
Exemple 1 – Analyse
(Système) RESERVER
Généralisation/spéciali Gestionnaire des vols
sation selon les Interroger par le net
« modes d ’accès »
Gestion interface
Sous-systèmes externes
Client Vue Analyse

(raffinement)
spécification
 JP mP
1.
Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse
34
(Système) RESERVER
Gestionnaire des vols
enregistrer fret Spécialisation par

l’objet du transport
Gestion interface
Client Vue Analyse
 JP mP
1.
35
(Système) RESERVER
Gestionnaire des vols
enregistrer fret
Gestion interface
payer
Gestionnaire financier
Client Vue Analyse
 JP mP
1.
36
(Système) RESERVER
des acteurs Gestionnaire des vols
secondaire
enregistrer fret des acteurs

enregistrer réservation secondaires
Gestion interface
principal payer
obtenir billets Gestionnaire financier

Client Vue Analyse
 JP mP
1.
37
Extension : Systèmes Évolutifs

relation d’extension : une évolution

demandée avec indication de l’endroit
où elle vient s’insérer
extension points : commande <<extend>>

complémentaire - les bonnes
occases- après rechercher un vol.
Consulter les promotions
 JP mP
1.
38
Exemple 1 – Conception
Système de Réservation
ss-système
Gérer-réservation
Télé-système Agence <<realize>>
<<include>>
Valider
<<include>> la commande
Réserver
Agent-réservation
Enregistrer
<<include>> demande
<<include>>
Client
Éditer billet Gérer Enregistrer Enregistrer

paiements passager fret
 JP mP
1.
39
Relations dans les Diagrammes d’UC

 Pas de Composition-Décomposition: (pour le raffinement) mais un UC se décrit en détail à travers un
package associé à l ’UC à détailler et décrit par des diagrammes d’UC définissant le contenu du package.
 Inclusion « include »: (pour la réutilisation) A inclut B

Lorsque la description textuelle <<include>>
& l’utilise  relation defait
dépendance
apparaîtreentre
desUC d’un même
interactions
communes
diagramme; l’UC, inclus, peut à plusieurs
être réutilisé cas.
dans d’autres Cas d'utilisation A Cas d'utilisation B
diagrammes ; (exemple typePour éviter la
: Réserver, ré-écriture.
Éditer billet)
 Extension « extend »: (pour l’extensibilité) B étend A,

en ...  relation de dépendance entre d ’étendre
UC d’un même <<extend>>
Permettre les
interactions
diagramme; l’UC, qui « étend », et donc
doit avoir les
un point
d’insertion dans l’UC fonctionnalités décrites
« étendu » ; (exemple : par les Cas d'utilisation A Cas d'utilisation B
interactions
« Consulter les promotions »)
typique d ’une situation optionnelle.
 Généralisation : (pour les mécanismes d’héritages et de versions) relation hiérarchique (une spécialisation
assure la fonction de l’UC parent) qui permet d’avoir plusieurs environnements pour le même objectif.
(exemple : Interroger possibilité-vol et Interroger par le net…)
Sans oublier entre les niveaux les dépendances de « trace » ou « réalisation »...
 JP mP
1.
40
Diagrammes d’Interaction
 Ensemble des objets, acteurs, systèmes qui collaborent pour contribuer

à la réalisation d’un U.C.
 A l’expression d’une collaboration est associé un diagramme de
collaboration qui met en évidence les parties de système, acteurs et
objets collaborants
Deux Types : Collaboration ou Séquences
 JP mP
1.
41
Diagrammes de Collaboration
Modéliser les Flux de Contrôle
 Utilisé pour décrire des scénarios du modèle : formes de séquences des vies
relationnelles des objets
 Utilisé pour décrire les interactions entre objets
– ensembles de messages échangés entre les objets,
– liens créés par ces échanges et leurs successions et/ou alternatives
– messages (orientés), flux de données
 Syntaxe d’un OBJET
joël:ETUDIANT
objet, nommé 1-objet pas de classe associée
1-objet:
:ETUDIANT l ’objet, nommé Joël de la classe ETUDIANT
un objet anonyme de la classe étudiant
 JP mP
1.
42
Exemple : r:
Réserve
f : Gestionnaire financier 5: afficher prix à payer

2: réserve
 3: réservation possible
Ce scénario traduit ce qui se
6: payer
passe quand tout est OK  4: évaluer réservation
à étudier, les autres cas :
pas de “vol” et pas de “place” 1: demander réservation
7: éditer réservation : Gestion interface
c : Client
9: m à dispo-billet
8: demander billet
b : Billets
 Dans ce modèle, on ne se préoccupe pas de l’aspect “gestion d’interface-client”, serveur d’agence ou de

télécommunication, gestionnaire du dialogue, qui serait seul à communiquer avec les sous-systèmes du
système de réservation. C’est ici une vue purement “fonctionnelle”
 Séquencement chronologique sans notion d’écoulement de temps
Message action : Verbe

Chaque message crée un lien entre les objets, une relation entre leurs classes
Un Use Case est un « classifier », unité de regroupement, de Scénarios
 JP mP
1.
43
Exprimer une alternative :
1 : demander réservation
2.0 [choix = OK]: confirme-réservation

r : Réserve
2.0 [non(choix = OK)]: propose-alternatives
2.1 [non(choix = OK)]: choisir-alternative
c : Client
2.2 [non(choix= OK)] : confirme-alternative
Même numéro de séquence de l’action suivie d’une condition.

Pour la cohérence du modèle, il faut que les conditions soient exclusives et totalement
définies, mais rien dans les outils ne valide cela, pour l’instant
Pour la lisibilité, il est souvent opportun de multiplier les modèles descriptifs chacun d’une
situation, càd d’un scénario pour le cas « normal » et les exceptions
 JP mP
1.
44
Diagramme de Séquence
Modéliser les Flux de Contrôle selon le Temps
 Utilisé pour modéliser des scénarios du modèle entre des objets

 Utilisé pour décrire les interaction entre objets selon un point de vue temporel :
– ensembles d’opérations échangées entre les objets, liens, messages (orientés)
– séquencement chronologique avec la notion de “vie de l’objet”
– écoulement du temps vertical/échange de message horizontal avec du parallélisme
d’existence, des alternatives ...
 Deux utilisations :
– documentation des cas d’utilisation (événements, ...)
– représentation précise des interactions entre objets (messages, ...)
 Messages synchrones, asynchrones, délai de transmission, contraintes temporelles...
 Création, destruction d’objets / durée d’activation d’un objet / boucles, conditionnelles
 Utilisé aussi pour documenter la dynamique des processus au niveau de la conception
physique du système
 JP mP
1.
Diagrammes de Séquence
45
:Unobjet :autreobjet
:Unobjet
Message asynchrone
création
:autreobjet
Retour explicite
destruction
X
:Unobjet :autreobjet
Message synchrone
Retour implicite
 JP mP
1.
46
Exemple :
c : Client : Gestion interface r : Réserve f : Gestionnaire b : Billets

financier
demander réservation
réserve
réservation possible
évaluer réservation
afficher prix à payer
payer
éditer réservation
demander billet
m à dispo-billet
Un dual du diagramme de collaboration avec insistance sur le temps

 JP mP
1.
47
Syntaxe
 Entête des colonnes :
– Objets A B
– Acteur, si il est acteur de l’UC dont le DS est
un scénario (rattachement)
 Message : deux types
– message synchrone : A attend la réponse de B
– message asynchrone : A envoie un signal et ne
s’en occupe plus
 Alternatives entre les mêmes objets
 JP mP
1.
48
Diagrammes de Classes – Données

Classes, Attributs, Opérations, Associations,
Agrégation, Composition, Héritage
 JP mP
1.
49
Classes - Propriétés
 Les classes : ensemble d’objets ayant les mêmes attributs, les mêmes opérations,
les mêmes relations et la même sémantique
Représentation graphiques
Vol nom de classe (unique)

numVol
hdep
attributs, typés ou non, simples ou multiples, avec
har valeur initiale éventuelle
définit la desserte définir-périodes() opérations() avec ou sans leurs paramètres

d’une ligne (ville de
départ, ville d’arrivée)
selon un horaire donné
Avion
Responsabilités : représentées comme

une note ou dans la doc de la classe Une classe peut être présentée sans ses
attributs e/ou sans ses opérations.
 JP mP
1.
50
Classes - Instances
Grenoble-Paris1 :VOL
GREPA01
5h37
6h41
Vol
« instancie » Paris-Grenoble1 :VOL
numVol
hdep PAGRE01
har « instancie » 7H15
8H20
définir-périodes()
Une classe = un type + un conteneur d’objets de ce type

 Donc, il faut « classer », càd,
 reconnaître les familles d’éléments, « ensembles » cohérents
 leur rôle, « responsabilité »
 les données associées « attributs »
 les actions que font les éléments « actifs »
 les actions que l’on fait sur les éléments « passifs » les « opérations »
 les « signaux » qu’ils envoient
 JP mP
1.
Diagrammes de Classes
51
Responsabilités
 Utiliser en phase d’analyse de besoins
– pour décrire le rôle des objets de la classe par rapport à l’environnement

– pour se concentrer sur le « pourquoi » avant d’aborder les structures : attributs
– mettre en évidence les relations fonctionnelles pour l’utilisateur
 Concerne particulièrement les «objets clients»
– un badge, identifie une des personnes autorisées
– un lecteur,
 veille & détecte la présentation d’un badge et en lit le code Exemple Contrôle
d’Access
 informe le système de contrôle et affiche le résultat du contrôle
 …
 JP mP
1.
52
Propriétés Statiques - Attributs
 Concernent la structure des données

 Une syntaxe
– [visibilité] nom [multiplicité] [ : type ][= valeur-initiale]
– [ {chaîne-propriété} ]
 Trois valeurs de visibilité :

– +, public (visible de toute classe),
– #, protégé (visible dans la classe et ses sous-classes),
– -, privé (visible dans la classe uniquement),
 JP mP
1.
53
Propriétés Dynamiques - Opérations

 Une syntaxe et quelques propriétés
– [visibilité] nom [ (liste-paramètre) ] [ : type-retour ]

– [ {chaîne-propriété} ]
 Des propriétés de contrôle de flots dynamiques :
– sequential : coordination extérieure pour que les appels soient séquentiels (1à1)
– guarded : contrôle d’intégrité sémantique, pas d’appels concurrents sur les gardes
– concurrent
 JP mP
1.
54
Exemples
Étudiant
Sport
nom : String nom
Inscription
numéro : Integer = 0
age : Integer date : Date
ajouter()
grade
invalider()
ajouter(Nom : String) : void
s-inscrire() : Boolean
Formation : cycle d’étude auquel Lors de la création
les étudiants peuvent s’inscrire d’une classe, donner sa
dans le cadre de l’institution que
definition comme une
l’on gère.
Note ou avec la
Formation Créée ou invalidée par
Documentation de la
nom : String l’administration après habilitation
Classe
Archivée pour l’historique de la vie
ajouter(nom : String) : void de l’établissement
valider(nom : String) : void
Note
Les opérations de création d’un objet sont implicites car « standard ».
 JP mP
1.
55
Variétés Spécifiques
 «stéréotype» : type de méta-classe qui sert de «définition de type» pour une famille
de classe
– <<boundary>>, <<control>>, <<entity>>...
– «interface» : associée à une classe, elle décrit un comportement visible  Ne contient que
des opérations (un type de stéréotype)
POSterminal
Store Une classe « interface » est une
<<uses>>
storeId : Integer
POSlist : list
Classe abstraire.
create()
login()
find() POSterminal
I-Store Store
getPOStotals()
storeId : Integer
updateStoreTotals() <<uses>> POSlist : list
get()
create()
login()
find()
Autre représentation I-Store getPOStotals()
getPOStotals() updateStoreTotals()
updateStoreTotals() get()
 JP mP get()
1.
56
Les Relations
 Lien entre les objets ou les classes qui crée des dépendances fortes entre les classes
du diagramme
 Trois types de liens de base, statiques, structurants :

– association
– agrégation, composition
– héritage
 Aussi, des liens de dépendance, plus faibles concernant la conception/réalisation du
modèle de base  ce sont les dépendances :
– « réalise » entre classe et une interface
– « réalise » entre des composants logiciels et une classe
– « trace » entre classe « utilisateur » issue de l’analyse et
– classe « composant » qui est le résultat de la conception du logiciel
 JP mP
1.
Diagrammes de Classes – Les Relations
57
Associations
Rôle (pas nécessairement des deux côtes)

Nom de la association (en italique)
Étudiant > Comment lire l’association
nom : String Formation
+inscrits Inscription > nom : String
age : Integer
grade 1..n 1..4 ajouter()
valider()
Cardinalités (inversées)
La formation à laquelle l’étudiant est inscrit ne figure pas en « doublon »

! dans les attributs de Étudiant  C’est la relation qui traduit la propriété.
 JP mP
1.
Diagrammes de Classes – Les Relations – Association
58
Classe Associative
Étudiant
nom : String Formation
+inscrits Inscription > nom : String
age : Integer
grade 1..n 1..4 ajouter()
valider()
Inscription
date : Date Action pour un étudiant de
s’inscrire à une formation de
l’établissement, créé et daté
par la scolarité lors de cette
inscription.
Archivé pour l’historique de la
vie de l’étudiant
Classe associative : un objet de la classe est identifié

par le « couple » d’objets liés par l’association
 JP mP
1.
59
Généralisation-Spécialisation
 Généralisation : plus général…
– super-classe
Instance-Vol
associerAvion()
Héritage
– sous-classe (hérite de)
 Spécialisation : plus spécial
Instance-Pass Instance-Fret
res1 fret
res2  Généraliser :
reserver-fret()
réserver1() associerAvion() – factoriser attributs, opérations,
réserver2()
associerAvion() contraintes
 Spécialiser :
Polymorphisme
– extension COHERENTE…au
sens ensembliste...
 JP mP
1.
Diagrammes de Classes – Les Relations – Généralisation-Spécialisation
60
Héritage Multiple
Animal
Mammifere Poisson Carnivore Herbivore
Felin
 JP mP
1.
61
« Classe Abstraite »
 Classe, regroupant des propriétés communes à ses sous-classes
 Pas d’instances propres, sert juste à la « factorisation », « abstraction »
Personne
nom : String
prénom : String Nom en italique
n-insee : Integer
adresse : String
identifier()
Etudiant Employe
n-inscription : Integer salaire : Double
indice : Double
identifier()
identifier()
 JP mP
1.
62
Quelques Considérations
 Sens : « est un » , « est une sorte de » , « est de la famille des »
 Propriétés :
– non réflexive : A n’hérite pas de lui-même ; il EST lui-même
– non-symétrique : B sous-classe de A, interdit A sous-classe de B (pas de cycle)
– transitive : C sous classe de B, B sous-classe de A => C sous-classe de A
A
A
A
B
B
 JP mP
1.
63
Agrégation
 Type de relation orientée, du tout vers les parties
Forte : Composition
Un module appartient à une seule filière (et disparaît avec elle)
Filière Module
1 1..n composition = agrégation forte
pas de partage
Tout Partie
mort simultanée
Faible : Agrégation
Les modules sont partagés par plusieurs filières
Filière Module
1..n 1..n
 JP mP
1.
64
Dépendances
 Réalisation
Java-Réserve Réservation
 La dépendance
 « type de dépendance »
– bind , entre des classes paramétrées et les paramètres effectifs
– derive, attribut dérivé : âge dérivé de date-de naissance
– friend, visibilité du but par la source
– instanceOf, instantiate pour des relations classe/objet
– powertype dans une relation enfants d’un même parent
– refine par raffinement d’abstraction de classe (analyse...implémente)
 JP mP
1.
65
Dynamique des Classes

Diagramme d’ État-Transition, Diagramme
d’Activités.
 JP mP
1.
66
Diagrammes d’États-Transitions
 Automates d’états finis de type State Charts de Harel (visual Formalism
for complexe systems, Sciences of Computer Programming vol 8).
 Exprime contraintes dynamiques

 Abstraction des comportements possibles
– des objets d’une classe (le plus souvent...)
– d’un U.C.
– d’un système
 Un état est caractérisé Plus pardeune
60 ansnotion de durée et de stabilité
ACTIVITE Etat
 Automates déterministes avec un état initial et des états finaux intermédiaire
Perte d ’emploi recrutement RETRAITE
 Transitions déclenchées par des événements Etat initial Etat final
CHOMAGE
– avec conditions, actionsPlus
et activités
de 60 ans
 Décomposition disjonctive et composition conjonctive d’états

 Historique
 JP mP
1.
Diagrammes d’États-Transition
67
Exemple 1
Diagramme d’États-Transition pour la Classe Station-Lavage
Classe
Station-Lavage
<<idle>>
Attente
Fin( programme )
Fin( programme )
Démarrer( programme )
[ présence(véhicule) ]
Fin( programme )
Lavage Rinçage Séchage

Suite( Programme ) Suite( programme )
 JP mP
1.
Diagrammes d’États-Transition – Exemple 1
68
événement
<<idle>>
Attente
Fin( programme )
Fin( programme )
[ présence(véhicule) ] états
Fin( programme )

Suite( programme ) Suite( programme )
garde
transitions
Classes
démarrer(programme) est un « signal » du Système de commande
Station-Lavage
[présence(véhicule)] est une « garde », condition qui est évaluée pour
accepter ou refuser la transition.
Syst-Commande « signal »
Le développement des diagrammes d’états entraîne la mise à jour en démarrer(programme)
cohérence des diagrammes de classes (statique) fin(programme)
 JP mP
1.
69
événement
<<idle>>
Attente
Fin( programme )
Démarrer( programme )[ présence(véhicule) ]
Actif
Classes
En regroupant toutes les transitions « fin programme » Station-Lavage

on met en évidence un sur-état Actif
Syst-Commande « signal »
démarrer(programme)
fin(programme)
 JP mP
1.
70
Diagramme « plat »
<<idle>>
Attente
Fin( programme )
Fin( programme )
[ présence(véhicule) ] Fin( programme )
Lavage Suite( programme ) Rinçage Suite( programme ) Séchage
Diagramme « hiérarchisé »
Démarrer( programme )[ présence(véhicule) ]
Actif
<<idle>>
Attente
...
Fin( programme )
Actif

les sous-états
héritent des
 JP mP transitions de sortie
1.
71
Histoire des sous-états dans un état

Actif
État “historique” –
indique un retour
avec mémorisation Lavage Rinçage Séchage
H
Fin( programme )
<<idle>>
Attente
Démarrage( programme )[ présence(véhicule) ] Problème
 JP mP
1.
72
Concepts 1
 État : (d’un objet ou d’une classe) : ensemble des valeurs, des attributs,
des relations et des opérations exécutables (pour l’objet et ceux qui sont
visibles par lui)

– nom: nomme l’état, mais il peut être anonyme ; pas obligatoire
– actions : d’entrée/sortie, opérations instantanées, non interruptive exécutées à
l’entrée ou la sortie de l’état, (au passage de la transition)
– transitions internes : transitions qui ne changent pas l’état, et s’exécutent sous le
contrôle des sous états
– sous états : états contenus dans l’état impliquant des sous-états, disjoints
(séquentiels) ou concurrents
– pseudo états : il existent trois :
 état initial : correspond à l’état implicite “le diagramme d’états est crée”
 état final : correspond à l’état implicite “le diagramme d’états est détruit”
 état “indicateur d’historique” : une transition vers cet état déclenche une transition au
dernier sous-état atteint lors du dernier passage à cet état
 JP mP
1.
73
Concepts 2
 État “idle”, inactif, attente : état neutre de l’objet après une transition, il attend
d’autres événements pour effectuer une transition.
 État actif : état actif càd une activité se déroule pendant que l’objet est dans cet état,
en attendant un événement déclencheur d’une transition (avec durée)
 Activité - do/activity (faire/activité)
– Ensemble d’opérations qui peuvent se produire pendant que l’objet est dans un état. Ex.:
do/op1(a); op2(b); op3(c)
– Séquence d’actions (chaque action est non interruptive)
– Une activité met un certain temps à s’exécuter.
– Elle est interruptive (entre deux actions) par un événement déclencheur.
– Elle peut faire référence à un autre diagramme d’état qui la décrit ;
États Transition d’État
Nom de l’État
entry: action d’entrée
Nom entry: ^class.événement
exit: action de sortir Événement[Garde]/Action
Initial Final exit: ^ class.événement
do: activité
do: ^class.événement
 JP mP
1.
74
Concepts 3
 Les événements provoquant les transitions sont classables suivant 4 natures :
– change event :changements de valeur, atteintes de limites
– time event : date, jour-heure, fin ou début de période

– signal : signaux venant d ’une autre classe (classe-active) avec ou sans paramètre
– call event : appel de procédure qui déclenche une action qui fait transiter…
 Comment les reconnaître ? Et trouver les états :

– en examinant dans les scénarios, les appels de procédure inter-objets ou les signaux
envoyés
– en regardant les qualificatifs associés aux objets dans ces mêmes scénarios
– en examinant les attributs des objets et leurs valeurs critiques
– en établissant une trace des divers points importants du «calendrier » qui rythme la vie du
système et des objets
État : une situation assez stable pour « durer » !
 JP mP
1.
75
Exemple 2
Diagramme d’États-Transition pour une Classe Fax
super-état
sous-état
<<idle>> Réception
Attendre sonnerie
entry/ décrocher
exit/ déconnecter
Connecté Entête-Ok
raccrocher
En-traitement
Envoie-fax actions
do/ recevoir
Transmission Effacer
Erreur / imprimer-rapport [ parité-Faux ]
transitions sans déclencheur

état final (fin du scénario)
état initial (début du scénario)
 JP mP
1.
76
Diagrammes d’Activités
 Autre diagramme pour exprimer de la dynamique  un organigramme qui
présente le flux de contrôle entre des activités

 Utilisé principalement pour la modélisation d’étapes séquentiels (ou
concurrents...) d’un processus de calcul
 Modélise le comportement interne d’une méthode (d’un seul objet) ou d’un cas
d’utilisation (d’une société d’objets)
 Une variante du diagramme d’états transition
– Diagramme d’États Transition : mis en valeur des états et des transitions
– Diagramme d’Activités : mis en valeur des activités et des transitions
 Zones d’activités
– pour exprimer en analyse de besoin, les grandes étapes du système
– pour montrer globalement des interactions avec le temps et les contraintes logiques
 JP mP
1.
77
 A cause de la nature procédurale des opérations (la plupart des événements

correspondent simplement à la fin de l’activité précédente) la distinction
systématique entre état, activité et événement est parfois inutile  Les
diagrammes d’activités offrent une manière simplifiée pour la visualisation

des activités.
 Par rapport aux Diagrammes d’Interaction, que mettent en valeur le flux de

contrôle entre les objets, les Diagrammes d’Activités mettent en valeur le
contrôle d’une activité vers une autre.
 Les Diagrammes d’Activités peuvent exister pour qu’on puisse d’une manière
indépendante , visualiser, spécifier, construire et documenter la dynamique
d’un ensemble d’objets  peuvent aussi servir à modéliser le flux de contrôle
d’une opération.
 JP mP
1.
78
Concepts 1
 État d’Action et État d’Activité :
– États d’Action : représentent un calcul exécutable atomique (ne
Étudier devis
peut pas être divisé)  des états du système que représentent

chacun l’exécution d’une action.
 Un État d’Action ne peut pas être décomposé Action simple
 Un État d’Action est atomique : des événements peuvent se Expression
produire sans que l’action réalisée par l’état soit interrompue.
 La durée d’exécution de l’action dans un état d’action est index:= index + 1
considéré non significative.
– États d’Activités : sont des états dont l’activité peut
éventuellement être représentée par d’autres diagrammes
d’activités  un État d’Action peut être considéré comme un Début Construction()
cas spécial d’État d’Activité qui ne peut plus être divisé. entry / bloquer()
 Un État d’Activité peut être décomposé
Action d’entre
 Les États d’Activités ne sont pas atomiques : ils peuvent être Sous-diagramme
interrompus par des événements
 La durée d’exécution de l’activité dans un État d’Activité Contrôle Finance(f)
peut être mesuré, elle est significative
 JP mP
1.
79
Concepts 2
 États Initial et Final : utilisés au même sens que dans les État initial
Diagrammes d’États Transition.
État d’Action
 Transition : quand l’action ou activité d’un état se termine, le État 1
flux de contrôle passe immédiatement à l’activité suivante 
Transition
ce flux est indiqué avec les Transitions que permettent de
montrer le chemin entre les états d’action ou d’activité. État 2
 Division Conditionnelle du Flux : est utilisée pour spécifier les

différents chemins qui peut prendre le flux à partir de État final
l’évaluation d’une expression booléenne.
Ordre début
– Un division doit avoir une transition entrante et une ou des travails
plusieurs transitions sortantes
– Chaque transition sortante doit avoir une expression booléenne division
qui est évalue lorsque la division est atteinte  les conditions [matériel pas prêt]
de garde de chacune de ces transitions doivent être Replanifier
mutuellement exclusives et doivent couvrir toutes les
Condition de garde
possibilités pour maintenir le déterminisme [matériel prêt]
– On peut utiliser le mot clef else pour indiquer la transition
que doit être suivie dans le cas où aucune autre n’est vrai Attribuer taches
 JP mP
1.
80
Concepts 3
 Synchronisation de Flux
Concurrents:
– Utilisées pour représenter la division et
le regroupement de flux de contrôle Action de
Resfrier
parallèles. Fourche
Concurrente
– Une fourche concurrente représente la
division du flux de contrôle  au
Arreter
dessous de la division, les activités Chaufage Aerer
associées aux flux se développent en
Jonction
parallèle. Concurrente
– Une jonction concurrente peut avoir
Mesurer
deux ou plus transitions entrantes et Temperature
généralement une unique sortante 
après que toutes les transitions aient
atteint la jonction, la transition de
sortie est réalisée.
 JP mP
1.
81
Concepts 4
 Travées :
– Est une division que peut être appliquée à un Diagramme d’Activités pour représenter les
différents responsabilités d’un mécanisme ou d’une organisation.

– Chaque responsabilité est assuré par un ou plusieurs objets et chaque action d’état ou
activité est attachée à un une travée en particulier.
– Chaque travée est divisée avec des lignes verticales.
– Les transitions peuvent traverser les travées.
 Flot d’Objet :
– Est un ensemble composé d’une relation de dépendance entre un objet et l’action ou
l’activité à l’origine de sa création, destruction ou modification.
– Présente les objets qui participent au flux de contrôle d’un Diagramme d’Activités.
– Peut présenter pour les objets qui participent du diagramme ses états et les valeurs de ses
attributs.
– Des objets peuvent être connectés à différentes actions d’états ou d’activités  son état
est représenté pour faire la différence
– Des flots d’objets peuvent être utilisés avec de diagrammes d’activités simples ou en
travée.
 JP mP
1.
Diagrammes d’Activités – Concepts 4 : Travées et Flot d’Objets
82
Client Ventes Entrepot
Commander
produit travées
Traiter
commande
Sortir
articles
c : Commande
[en cours]
Expedier
commande
flot d’objet
objet
c : Commande
[traitée]
Recevoir Facturer
commande client
état
Payer f : Facture
facture
[due]
Cloturer
f : Facture commande
[payée]
flot d’objet
 JP mP
1.
83
DEMARCHE ORIENTEE OBJET

 Le domaine d ’étude n ’est pas le système d ’information dans sa globalité
(l ’organisation n ’est pas prise en compte). Il est réduit au système
informatique. La démarche proposée (à travers UML) vise donc à spécifier et à

implanter les fonctions informatisées du système d ’information.
A.Expression des besoins B.Analyse C.conception D.Implantation
B.1 diagramme de séquence

A.1 Cas d ’utilisation (Use Case) intermédiaire C.1diagramme de Séquences Détaillé
à partir des fonctions attendues «pour chaque diagramme de séquences à chaque diagramme se séquences interm.
du système informatique, établir de haut niveau construire le diagramme Construire le D S D: exprimer les demandes
un diagramme de cas d ’utilisation. de séquences intermédiaire qui exprime de services détaillées entre objets et spécifier
A.2 Diagramme de séquence de haut les demandes de services fondamentales leurs paramètres.
niveau entre objets. C.2 Diagramme de Classe Détaillé
pour chaque cas d ’utilisation, décrire B.2 diagramme de classe intermédiaire compléter le diagramme de classe
le scénario principal et éventuellement construire progressivement le diagramme conformément aux Diagrammes de Séquences
les scénarios secondaires en langue de classes: classes, attributs et associations. Détaillés.
naturelle Ajouter les classes application et ses C.3 Diagramme de Classes Généralisé
opérations (cas d ’utilisation définis du principes d ’abstraction et de polymorphisme.
système. C.4 Langage de conception
 JP mP
1.
Démarche Orienté Objet
84
Conclusion
Les étapes expression des besoins, analyse et conception sont menées de

manière cyclique
où les diagrammes d ’état-transition, d ’activité, de séquences… permettent
d ’affiner le système informatique(selon des points de vue différents)
en introduisant plus de détailles concernant les rôles, les objets, les liens…
et par conséquent élargir le périmètre du SI.
 JP mP

JP mP
Etude de Cas
1.
85
1.
86
Décrire la Réalisation et son

Implantation
Diagrammes de Composant, Diagrammes
de Déploiement
 JP mP
1.
87
Diagrammes de Composants
 Fournit une vue statique (l’architecture logicielle) représentant la mise en oeuvre d'un
système, dessiné sous la forme d'un graphique de composants logiciels connectés par
des relations : dépendance, généralisation, association et réalisation.

 Éléments : composants (avec plusieurs stéréotypes) et interfaces.
 Utilisés pour définir les dépendances et relations entre objets à un niveau
“supérieure” à celui du diagramme de classes  les AGLs permettent de créer un lien
entre les classes du modèle logique et les composants.
 Modélisent la structure du logiciel et montrent les dépendances entre le code source,
le code binaire et les composants exécutables, de sorte que l'impact d'une
modification puisse être évalué  Les dépendances entre composants
permettent notamment d'identifier les contraintes de compilation et de mettre
en évidence la réutilisation de composants.
 Le composants peuvent être organisés en packages, qui définissent des
sous-systèmes.
Sybase® - PowerAMC™ - Modèle Orienté Objet
Guide de l'utilisateur Version 9.0 - Janvier 2002
 JP mP
1.
Diagrammes de Composants
88
Exemple
Cours UML : UML, le langage de modélisation objet unifié

http://uml.free.fr/index.html
 JP mP
1.
89
Diagrammes de Déploiement
 Architecture matérielle et répartition logicielle
 Éléments : des nœuds (ressources matérielles) et des relations de dépendance et
d’association  aussi des composants qui doivent résider sur un nœud et de packages.
 Des Diagrammes de Classes centrées sur les nœuds d’un système
 Stéréotypes utilisés pour les nœuds : <<processeur>>, <<mémoire>>, <<dispositif>>
 Connections bi-directionnelles avec cardinalités des nœuds et des connections
Comportement du Logiciel
Structure du Logiciel Diagrammes de Séquences
Diagrammes de Classes Diagrammes de Collaboration
Diagrammes de Composants Diagrammes de États-Transition

A la frontière matériel/logiciel du système pour planifier la topologie des
processeurs et des périphériques sur lesquels le système tourne
 JP mP
1.
90
Exemple
Cours UML : UML, le langage de modélisation objet unifié

 JP mP http://uml.free.fr/index.html

Uml masterGI

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml masterGI

Transféré par

Droits d'auteur :

Formats disponibles

1.

SI d ’un bureau d ’étude

Michel TOLLENAERE professeur laboratoire GILCO

Cours : Systèmes d ’Information

 Qu’est ce qu’un modèle ? (Minsky 1968)

notions de base: objet, acteur, collaboration,

 Objet: entité d ’un monde réel ou virtuel, capable de sauvegarder un

Axes de modélisation d ’un système

 UML: Bibliographie et sites.

•langage semi formel

 « UML EN Action : de l’analyse des besoins à la conception en Java »

 « UML en Action », Pascal Rocques, Vallée F , Eyrolles, 2000.

– //www.uml.crespim.uha.fr/ (site de mulhouse)

UML 1.3 1999

Septembre : soumission final 1997

UML 0.9 1996

Autres OOAD OMT OOSE

– de modèles variés/points de vue – l’architecture

 Besoin d’un Processus de  Dans X Environnements de

UML, Modèles et Diagrammes

Un Modèle = Un point de vue sur le système

 Modèle des Cas d’Utilisation – Use Case, UC – qui décrit les

Classes Objets Séquence Collaboration Activités

Cas d'Utilisation États-Transitions Composants Déploiement

lien d’héritage : «est un diagramme»,

Classes Objets Séquence Collaboration Activités

Cas d'Utilisation États-Transitions Composants Déploiement

Un diagramme est un « langage graphique » de phrases traduisant

Classes Objets Séquence Collaboration Activités

Cas d'Utilisation États-Transitions Composants Déploiement

Classes Objets Séquence Collaboration Activités

Cas d'Utilisation États-Transitions Composants Déploiement

Classes Objets Séquence Collaboration Activités

Cas d'Utilisation États-Transitions Composants Déploiement

Organiser les documents,

package exigences Pkg-exigences

Gérer le Gérer la politique

Analyser par les Cas d’Utilisation,

 Modéliser le comportement d’un :

 Un acteur fait avec le système qui lui offre ce service :

Exemple1 : Réserver sur un vol à une date donnée

une note est attachée

Généralisation/spécialisation selon les « modes d ’accès »

Vue analyse des besoins :

Vue analyse des besoins

enregistrer réservation Spécialisation par

Vue analyse des besoins

payer enregistrer passagers

Vue analyse des besoins

payer enregistrer passagers

 JP mP les liens d’activation du système

Client Vue Analyse

enregistrer fret Spécialisation par

Client Vue Analyse

enregistrer fret des acteurs

obtenir billets Gestionnaire financier

Extension : Systèmes Évolutifs

relation d’extension : une évolution

extension points : commande <<extend>>

Consulter les promotions

Éditer billet Gérer Enregistrer Enregistrer

Relations dans les Diagrammes d’UC

 Inclusion « include »: (pour la réutilisation) A inclut B