Cours UML FI2

1
Unified Modeling LanguageLangage unifié pour la
modélisation objet
J. Rumbaugh, G. Booch, I. Jacobson
2
Sommaire

• Généralités Modélisation et approche O.O.
• UML Langage de modélisation
• RUP Processus de modélisation

3
INTRODUCTION
Lingénierie des systèmes dinformation
INGENIERIE DES BESOINS
Élucidation des besoins
INGENIERIE DU LOGICIEL
modélisation
Système réel
conception
validation
production
Schéma conceptuel
vérification
Domaine du problème
Système logiciel
Domaine de la solution
4
INTRODUCTION
POINT DE VUE HISTORIQUE

• "Crise du logiciel" L'ingénierie du logiciel
  comme une discipline

(milieu des années 60)

• Facteurs d'évolution

Coût du logiciel / coût du matériel
Le logiciel considéré comme un produit ayant son
cycle de vie
Nécessité davoir des Méthodes
5
INTRODUCTION
Composants dune méthode de construction de SI
des MODÈLES Pour décrire les données et
les traitements

• Une DÉMARCHE
• des étapes

Une MÉTHODE de CONSTRUCTION De systèmes
dinformation

• des OUTILS
• manuels
• automatisés (AGL)

6
Processus de développement
7
INTRODUCTION Des méthodes fonctionnelles aux
méthodes Objet

• Lorientation fonctionnelle (années 1970)
• Programmation structurée, méthodes danalyse
  structurées.
• Lorientation conceptuelle (années 1980)
• méthodes de conception systémique (Données et
  traitement)
• Lorientation Objet (les années 1990)
• Programmation Objet, SGBD Objet, méthodes
  danalyse et de conception orientée Objet

8
La prolifération des méthodes objets
INTRODUCTION

• 1990 Naissance d'une cinquantaine de méthodes
  orienté objet.
• Confusion autour de lanalyse et de la
  conception.
• Idée Examen des méthodes dominantes pour
  permettre de dégager un consensus autour didées
  communes.
• Rapprochement de 2 méthodes OOAD de Grady
  Booch et OMT de Rumbaugh Al

9
Livres Guide de lutilisateur Manuel de
référence Guide du processus
UML 1.3
Standardisation par lOMG
1997, Soumission à lOMG
UML 1.0
Spécification disponible sur Internet
OOPSLA96
UML 0.9
Spécification disponible sur Internet
Méthode unifiée 0.8
OOPSLA95
Booch93
OMT-2
Autres méthodes
Booch91
OMT-1 Rumbaugh91
OOSE Jacobson92
Partenaires Rational
10
Lorientation Objet

• Les principes de base de lorientation objet
• Les objets, les classes, envoi de messages,
  lencapsulation
• lhéritage, le polymorphisme
• Organisation dun système en une collection
  dobjets disssociés mais collaborant entre eux

CLASSE
OBJET
Classe 2
Classe 3
objet2
Classe 1
objet1
objet3
Classe 4
Classe 31
Classe 32
objet4
Une architecture logicielle
11
Pourquoi lapproche objet ?

• But
• modélisation des propriétés statiques et
  dynamiques de lenvironnement dans lequel sont
  définis les besoins (domaine du problème),
• formalisation de la perception du monde et des
  phénomènes qui sy déroulent,
• Avantages
• capacité à regrouper ce qui a été séparé,
• à construire le complexe à partir de
  lélémentaire,
• à intégrer statiquement et dynamiquement les
  constituants d un système.

12
(No Transcript)
13
(No Transcript)
14
Ma Voiture
Bleu 979 kg 12 CV 30 litres
Couleur Masse Puissance fiscale Quantité de
carburant
15
Ma Voiture
Ma Voiture
Bleu 979 kg 12 CV 30 litres
Bleu 979 kg 12 CV 20 litres
Après un parcours de 100 km.
16
Un autre objet
Opération 1
Un message
Opération 2
Un objet
17
Avion En vol
Atterrir
Avion Au sol
Tour de contrôle
Décoller
18
(No Transcript)
19

• Définitions
• Une classe est la description dun ensemble
  d objets qui ont les
• mêmes attributs, les mêmes opérations, les
  mêmes relations et
• des sémantiques communes
• ex Personne, Etudiant, Compagnie
• Un attribut est une propriété nommée dune
  classe qui décrit un
• ensemble de valeurs, il représente une
  propriété de lélément
• modélisé
• Une opération est l implantation dun
  service qui peut être
• demandé aux objets d une même classe
  dans le but de
• déclencher un comportement

20
Nom de Classe
Attributs Opérations ()
Moyen de transport
Type Poids Couleur Démarrer () Accélérer
() Freiner ()
21
Interface / Implémentation
LIRE_NOM
MAJ_NOM
AGE
Interface
PARTIE VISIBLE
Implantation
structures de données
corps des méthodes
PARTIE CACHEE
age peut être implémenté par un
attribut stocké ou par un calcul
utilisant la date de naissance)
Abstraction les objets clients ne peuvent
accéder à un
objet que via son interface
Ils ne connaissant pas tout le détail de l'objet
Masquage d'information
Indépendance des clients vis à vis des
structures de données et des algorithmes
22
Le lien dhéritage entre classes est une
relation entre un élément général et un élément
dérivé
Polygone
Super classe
Sommets
Translater (a,bréel) périmètre()réel
La classe Rectangle hérite de la classe Polygone
Sous-classe
Rectangle
Tous les attributs et toutes les opérations de
la classe Polygone sont applicables de la même
façon à la classe Rectangle
Coté1 coté2 diagonale
On n indique dans la sous classe que les
Propriétés spécifiques
23
Principe de la redéfinition et Polymorphisme
La règle de calcul du périmètre d'un rectangle
peut être optimisée selon la formule p
2(coté1coté2))
La méthode périmètre peut être redéfinie dans la
classe
Rectangle afin d'avoir un corps différent (ici la
redéfinition
est utilisée pour une meilleure efficacité)
Le même nom "périmètre" désigne deux corps
différents, une opération peut avoir plusieurs
formes (Polymorphisme)
La redéfinition est un mécanisme sémantique qui
assure que le même nom fait référence à des
codes différents selon le type de l'objet auquel
il s'applique
24
(No Transcript)
25
(No Transcript)
26
Chapitre 2 UML Unified Modelling Language
27
(No Transcript)
28
Les Briques de Base
29
Les modèles UML

• Modèle dapproche décrit le comportement du
  système à un haut niveau
• les cas dutilisation, les scénarios
• Modèle de structure décrit laspect statique du
  système
• les objets, les classes et leurs
  relations
• Modèle de la dynamique décrit les échanges
  entre objets
• interaction,
  communication, message

30
Modèles dapproche les cas dutilisation

• Le modèle des UC une vue du système qui met
  laccent sur le comportement du système tel quil
  apparaît aux utilisateurs externes. Il permet la
  représentation des fonctionnalités du système.
• Les diagrammes de cas dutilisation sont élaborés
  pour visualiser les relations entre les acteurs
  et les cas dutilisation
• Les diagrammes de cas dutilisation présentent
  une vue extérieure du système

31
(No Transcript)
32
Acteurs et cas dutilisation

• Acteurs et cas dutilisation permettent de
  décrire le système
• Les acteurs interagissent directement avec le
  système
• Les cas dutilisation représentent lutilisation
  du système par les acteurs

ltltacteurgtgt
Un autre acteur
Un acteur
Un cas dutilisation
33
Les Acteurs
Un Acteur représente un rôle joué par une
personne ou une chose qui interagit avec le
système
Conseiller financier
guichetier
Un acteur a besoin déchanger des informations
avec le système. Même si on les utilise dans les
modèles, les acteurs ne font pas partie du
système puisquils résident en dehors de celui ci.
34
Les Acteurs
Trois types d acteurs

• les personnes, ce sont des utilisateurs du
  système
• (acteurs principaux, acteurs secondaires)
• le matériel externe, dispositif utilisé par le
  système
• ex limprimante dun distributeur de billet
• les autres systèmes, qui communiquent avec le
  système
• ex Le groupement bancaire dans un système
  
• de distributeur de billets

35
Les Cas dutilisation
Un cas d utilisation modélise une fonctionnalité
du système
Ex
Traiter Prêt
Valider Mot de passe
Traiter un versement
Un cas d utilisation décrit ce que fait un
système mais ne précise pas comment il le
fait La réalisation dun cas dutilisation se
traduit par un échange de messages entre le
système et ses acteurs
36
Diagramme de cas dutilisation
Application bancaire
Traiter un versement
Conseiller financier
guichetier
Traiter Prêt
Un cas dutilisation définit un comportement du
système sans révéler sa structure interne il
spécifie les services que le système fournit à
ses utilisateurs et les interactions
acteurs/système
37
cas dutilisation et scénarios

• Un cas dutilisation se détermine en observant
  acteur par acteur les séquences dinteractions
  scénarios du point de vue de lutilisateur
• Scénario  instance  dun cas dutilisation
  ou sa  réalisation 
• Un scénario est un accomplissement dun cas
  dutilisation
• - Il est initié par un message venant
  dune instance dacteur
• - il accomplit une séquence dactions
  telle que spécifiée par le cas
• dutilisation
• La réalisation dun cas dutilisation est
  accomplie comme une transaction
• atomique
• - elle ne peut être interrompue par une
  autre instance de cas
• dutilisation

38
cas dutilisation et scénarios

• Décrire le cas dutilisation décrire lensemble
  de scénarios potentiels
• Un scénario est composé de plusieurs chemins
• un chemin de base ou nominal
• l'ensemble le plus commun ou plus général
  d'interactions
• un ou plusieurs chemins alternatifs
• Variantes itérations et alternatives
• Anomalies l'ensemble des interactions traitant
  les cas d'erreur

39
Description dun cas dutilisation

• Spécifier une séquence initiée par lutilisateur
• interactions entre
• les utilisateurs et le système
• les réponses effectuées par le système du point
  de vue extérieur (au système)
• Intégrer les variantes à cette séquence
• alternatives
• comportements exceptionnels
• interception derreur

40
Description patron textuel

• Nom
• Résumé
• Acteurs
• initiateur autres
• Préconditions
• Description
• textuelle en langage naturel informel
• rédaction utiliser une forme active du point de
  vue du système
• Cas d'erreur
• Variantes et autres cas d'erreurs dans le
  déroulement du cas d'utilisation
• Postconditions

41
Relations entre cas dutilisation

• Relation  include 
• inclusion dun cas dutilisation dans un autre
• à utiliser quand on répète plusieurs fois la même
  séquence dans différents cas dutilisation
• Relation  extends 
• ajout optionnel de comportement dans un cas
  dutilisation
• à définir
• condition dextension
• point dextension dans le cas dutilisation
  étendu
• à utiliser quand on décrit une variation sur un
  comportement normal

42
Relation dinclusion définition
La relation d inclusion signifie que le cas
d'utilisation source comprend le comportement
décrit par le cas d'utilisation destination en un
point dinsertion bien déterminé
ltltincludegtgt
exemple
ltltincludegtgt
La relation d inclusion est un exemple de
délégation. Un cas dutilisation est partagée par
plusieurs cas d utilisation
43
Relation d'extension définition
ltltextendgtgt
Condition d extension
exemple
ltltextendgtgt
Fixer priorité
Fixer priorité
44
Relation de généralisation définition
45
Virement
Vérification supplém. Après identification
Virement par minitel
ltltextendgtgt
ltltIncludegtgt
Client local
Client distant
Identification
46
(No Transcript)
47

48
Les modèles de structure
49
Le Modèles de structure

• Représentation de la structure statique du
  système
• Les composants du système
• Les liens sémantiques entre ces composants
• Contenu
• Objets et classes
• Liens et associations
• Généralisation
• Modules ou paquetages

50
Objet et Classe définitions

• Objet
• Une abstraction
• Une entité qui a un sens propre dans le domaine
  ou dans l'application
• Un objet est une instance d'une classe
• Classe
• Représente un groupe d'objets qui ont une même
  sémantique et des caractéristiques communes
• attributs, opérations, relations avec d'autres
  objets

Personne
Personne
Pierre
JeanPersonne
Objet de classe
Classe
51
Les Classes dobjet

• Exemples

Nom de classe
attributs
opérations
nom prénom dateNaissance age()
52
Objet et Classe les Attributs

• Définissent les propriétés des objets dune
  classe
• Chaque nom d'attribut est unique dans une classe.
• L' identification est fournie par le système,
  elle nest pas à
• considérer dans le modèle objet.

Nom de classe
Nom dattribut type valeur initiale
Personne
Film
Personne
nom string prénom string dateNaiss date
titre string réalisateur string dateProduction
date dateSortie date
Id_pers ID nom string prénom
string dateNaiss date
53
Objet et Classe les Attributs

• Attribut
• Une donnée dont la valeur caractérise un objet
• Un attribut est une propriété de la classe
• Un attribut peut être structuré
• adresse (numéro, rue, ville, code postal)
• Attribut identifiant de l'objet
• Un objet n'a pas d'identifiant, sauf si un
  attribut l'identifie dans le monde réel

54
Objet et Classe les opérations

• Une opération définit une fonction applicable aux
  objets de la classe

Nom de classe
Nom dopération( liste_arguments) type_retour
Rectangle
Personne
Côté1 Côté2 Ajouter( ) Déplacer( ) Périmètre( )
nom string prénom string dateNaiss
date Adresse string CalculerAge (
) changerAdresse ( )
Une méthode est la mise en oeuvre d'une opération
pour une Classe (plusieurs méthodes pour le même
service)
55
Objet et Classe Attribut dérivé

• Les attributs dérivés offrent une solution pour
  allouer des propriétés à des classes, tout en
  indiquant clairement que ces propriétés sont
  dérivées dautres propriétés déjà allouées.
• Exemple

Rectangle
Rectangle
longueur largeur /surface
longueur largeur
En conception
surface( )
56
Objet et classes Visibilité des attributs et
des opérations

• 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 à la classe
  seul

Classe
Personne
Attribut public Attribut protégé - Attribut
privé Attribut de classe
- nom chaîne - date_naissance date
calculer_age () rechercher()
Opération publique( ) Opération protégée( ) -
Opération privée( ) Opération de classe( )
57
Lien et Association

• Association
• Une relation sémantique entre classes
• Représente l'ensemble des liens entre les objets
  des classes qui participent à l'association
• Degré d'une association
• Le nombre de classes qui participent à
  l'association
• Une association peut être réflexive
• Lien
• Une connexion physique entre objets
• Une instance d'une association
• Similarité classe-objet et association-lien

58
Les relations entre classes
Lien et Association

• Une association est une relation structurelle qui
  précise que les objets d une classe sont reliés
  aux objets dune autre classe

Travaille pour
association
Personne
société
Travaille pour
Snecma
Durand
liens
Travaille pour
Dupond
Darty
59
Lien et Association modélisation et mise en
oeuvre

• Une association ne doit pas être modélisée par un
  attribut
• Une association est mise en oeuvre (programmée)
  par
• un attribut identifiant un pointeur d'objet,
• une classe
• une structure d'accueil (container) telle que
  liste, tableau, etc.

60
Lien et Association multiplicité

• La multiplicité est une information qui définit
  combien dobjets de la classe considérée peuvent
  être liés à un objet de lautre classe

1
Personne
Société
1..
Chaque personne travaille pour une société,
chaque société emploie de une à plusieurs
personnes. Multiplicité cardinalité
61
Lien et Association multiplicité
1
1 (un et un seul)
0..

plusieurs (zéro ou plus)
0..1
facultatif (au plus un)
1..
obligatoire (au moins 1)
2..4
deux, trois ou quatre

• Les valeurs de multiplicité expriment des
  contraintes liées au domaine de lapplication,
  valables durant lexistence des objets.

62
Lien et Association rôle

• "Rôle" des participants dans une association
• Un "rôle" peut être spécifié pour une extrémité
  de l'association.
• Il exprime le rôle d'une classe dans
  l'association.
• il facilite la lecture et la compréhension du
  modèle objet.

63
Lien et Association contraintes

• Contrainte sur les participants dans une
  association
• Ordre implicite sur les objets de la classe qui
  participe à l'association, avec une cardinalité
  supérieure à 1
• Contrainte de sous-ensemble de liens entre
  associations

64
Lien et Association attribut de lien

• Une valeur portée par un lien
• Une propriété de l'association
• Ce n'est pas une propriété d'un des objets qui
  identifie le lien
• Ce n'est pas une propriété d'une des classes qui
  identifie l'association

accède à
Utilisateur
Fichier
0..
0..
Accès
permission
65
Lien et Association association modélisée en
classe

• Chaque lien est une instance de la classe qui
  modélise l'association
• A utiliser quand les liens ont des opérations

66
Les Associations, Contraintes sur les associations

• Association réflexive
• Le nommage des rôles est essentiel à la clarté du
  diagramme.

Personne
Parents
2

Enfants
67
Lien et Association sens, direction, contrainte
travaille pour
Personne
Entreprise
0..
emploie
sens de lecture de l'association
association unidirectionnelle
or
contrainte ou entre associations
Compte
68
Les relations entre classes Les agrégations

• Représente une association non symétrique dans
  laquelle une classe joue un rôle prédominant par
  rapport à lautre classe.
• Les critères suivants impliquent une agrégation
• une classe fait partie dune autre classe
• les objets dune classe sont subordonnés aux
  objets dune autre classe

Tout
Partie
Une agrégation
A
B
La relation dagrégation représente la relation
Possède
69
Agrégat caractéristiques

• Transitivité
• Antisymétrie
• Propagation d'opérations
• Certaines opérations du "tout" se propagent (avec
  modification) aux "parties"
• Exemples corriger document, corriger
  paragraphe, corriger mot
• Quand utiliser lagrégat
• Une "partie" ne peut pas exister indépendamment
  du "tout"

Document
Paragraphe
Phrase
0..
0..
70
Les relations entre classes Les agrégations

• Lagrégation peut être multiple, comme
  lassociation

1
Entreprise
Service

Cette forme d association a pour but de
distinguer le tout de la partie. Elle est
uniquement conceptuelle
71
Les relations entre classes La composition

• La composition est un cas particulier de
  lagréation
• Agrégation réalisée par valeur sur des attributs
  composition.
• Ils sont physiquement contenus dans lagrégat.

Composite
0..1
Composite
Composant
Composant

Fenêtre
1
1
1
scrollbar
1
2
titre
corps
1
Ascenseur
EnTete
Panneau
72
Les relations entre classes La composition

• Forme dagrégat avec appartenance forte et vies
  coïncidentes des parties au tout
• La destruction du composite implique la
  destruction de tous ses composants,
• La création, la modification et la destruction
  des composants sont de la responsabilité du
  composite
• La multiplicité du côté du tout ne peut dépasser
   1 
• Un composant est non partagée

73
Les relations entre classes La composition
Un autre exemple
Voiture
Voiture
Moteur
?
Moteur
Carburateur
Cylindre
...
74
Généralisation
Spécialisation
Super-classe
Sous-classe 2
Sous-classe 1
75
Exemple 1
Super classe
Livre
Titre Nombre de pages
Livre pour les enfants
Livre pour lenseignement
Fourchette des âges Thème
Discipline Niveau
Sous classe
76
Exemple 2

Ecran
symbole de généralisation
O D
Ligne
Point
Polygone
nbre côtés sommets
afficher
77
Les classes sont ordonnées selon une hiérarchie
une superclasse est une abstraction de ses
sous-classes
Véhicule
Terrestre
Aérien

• La généralisation est une relation non
  réflexive.
• La généralisation est une relation non
  symétrique.
• La généralisation est une relation transitive.

78
Généralisation héritage multiple

• Possibilité d'hériter de plusieurs classes

Problème Conflit de nom
79
La généralisation

• Une classe peut être spécialisée selon plusieurs
  critères simultanément.

Véhicule
Milieu
Motorisation
A voile
A moteur
Terrestre
Marin
80
La généralisation, Contraintes

• La contrainte Disjoint ou Exclusif indique
  que les instances d une sous-classe ne peuvent
  pas être incluses dans une autre sous classe de
  la même classe

Personne
Exclusif
Steward
Pilote
81
La généralisation, Contraintes

• La contrainte Chevauchement ou Inclusif
  indique que deux sous classes peuvent avoir des
  instances communes

Véhicule
Inclusif
Motorisation
Milieu
A voile
A moteur
Terrestre
Marin
82
La généralisation, Contraintes

• La contrainte Complète indique que la
  généralisation est terminée et qu'il n'est pas
  possible de rajouter des sous-classes.
  Inversement, la contrainte Incomplète désigne
  une généralisation extensible.

Cours
Incomplète
Maths
Français
Géographie
83

• Un diagramme sert à montrer un contexte. Ils
  facilitent la compréhension des structures de
  données complexes.

Nom de l'objet
Nom de l'objet Classe
Classe
exemple
Voiture
Moteur
4
Voiture
Roue
1
1
Roue
1
Roue
Roue
Roue
Moteur
Diagramme dobjets
Diagramme de classes
84

• Les objets composés de sous-objets peuvent être
  représentés au moyen d'un objet composite.

Un composite

• Les objets composites sont instances de classes
  composites

Ascenseur
Fenêtre
1
2
Fenêtre
1
1
Zone de dessin
85

• Les systèmes impliquent la manipulation dun
  nombre élevé de classes et autres éléments du
  modèle.
• En UML, un paquetage est un mécanisme générique
  pour organiser des éléments de modélisation en
  groupes
• Les paquetages permettent de présenter
  différentes vues de l architecture du système

Représentation graphique
86
CLIENT
Client
1..
87
Paquetage dépendances structurelles

• Association
• Spécialisation

P2
P1
D
C
0..
P2
P1
F
E
88
Paquetage dépendances dutilisation
P2
P1
 uses 
H
G

• H nécessite G pour sa mise en oeuvre ou son
  fonctionnement.
• La nature de lutilisation peut être
• linvocation dune opération
• la création dun objet

89

• Un modèle objet est constitué de un ou plusieurs
  paquetages
• Un nom de classe est unique dans un paquetage
• Une classe peut appartenir à plusieurs
  paquetages elle réalise le lien
• vue comme une classe importée
• Il est préférable qu'une association (ou une
  généralisation) n'existe que dans un seul
  paquetage
• Les liens entre paquetages doivent être limités
  couplage minimum

90
(No Transcript)
91
Le Modèle Dynamique

• Décrit l'évolution au cours du temps du système
• Description de la vie de chaque objet dans le
  temps
• Changement d'états des objets
• Modification des valeurs des attributs qui
  caractérise l'objet
• Modification des liens entre objets
• Montre le flux de contrôle dans le temps
• Séquences d'opérations à exécuter en réponse à
  des événements extérieurs
• Interactions dans le temps entre objets
• Envois de messages et réponses aux événements
• Appels d'opérations

92
Le Modèle Dynamique Les diagrammes

• Le modèle dynamique repose sur un ensemble de
  diagrammes
• Diagrammes de séquence et/ou Diagramme de
  collaboration pour chaque scénario
• Modéliser la collaboration de plusieurs objets
  dans un cas dutilisation
• Un diagramme d'états pour certaines classes
• Modéliser le comportement dun objet
• Les diagrammes d'états sont reliés par des
  événements "partagés"
• Diagrammes d activités pour la description des
  traitements ou les synoptiques de tâches
  (workflow)

93
Scénario Définition

• Une séquence de messages qui correspond à une
  utilisation du système
• Les scénarios sont créés pour des cas
  dutilisation du système
• Les scénarios montrent comment est utilisé le
  système
• ce qu'il va faire en réaction à ces messages
• Eviter les alternatives (séquences
  conditionnelles) dans un scénario
• si besoin d'une alternative faire plutôt deux
  scénarios

94
Exemples de scénarios

• Appel téléphonique
• Scénario le numéro appelé est occupé
• L'appelant décroche le téléphone
• L'appelant commence à composer le numéro
• L'appelant termine de composer le numéro
• La tonalité "occupée" commence à sonner
• L'appelant raccroche le téléphone
• Scénario le numéro appelé n'est pas occupé
• L'appelant décroche le téléphone
• L'appelant commence à taper le numéro
• L'appelant termine de taper le numéro
• Le téléphone commence à sonner
• L'appelé décroche
• La conversation se déroule
• L'appelé raccroche le téléphone

95
Le modèle dynamique

• La brique de base de la modélisation de la
  dynamique est léchange (interaction) entre
  objets, les concepts principaux lévénement et
  le message
• Une interaction est un ensemble de messages
  échangés au sein dun groupe d objets pour
  atteindre un objectif
• Un message est la spécification d une
  communication entre objets qui transporte des
  informations et qui seffectue pour déclencher
  une activité

96
Le modèle dynamique
Exemple
Personne

1..
Entreprise
employeur
employé
setRémunération(sSalaire) affecter(ddepartement
)
message
Affecter(Marketing)
PPersonne
Entreprise
97
Diagramme de séquence

• Représentation graphique du scénario montrant
• le séquencement des messages (opération, signal)
  entre objets dans le scénario
• Modéliser la collaboration de plusieurs objets
  dans un cas d utilisation
• Met en évidence les messages concurrents du
  scénario
• L envoi d un message est atomique
• insécable
• la durée de lenvoi est considérée nulle comparée
  à la granularité de l interaction
• Un objet est représenté par sa ligne de vie
• une ligne de vie peut être la vue abstraite d un
  ensemble d objets

98
Diagramme de séquence représentation

• Un système téléphonique

appelantPersonne
Ligne
appeléPersonne
décrocher
débuter tonalité
composer chiffre(n)
ligne de vie
arrêter tonalité
composer chiffre(n)
...
composer chiffre(n)
sonner
débuter tonalité sonnerie
décrocher
temps
arrêter sonnerie
arrêter tonalité sonnerie
connecter
connecter
L envoi d un message est toujours horizontal
raccrocher
déconnecter
déconnecter
raccrocher
99
message synchrone
message asynchrone
100

• La création des objets se représente en faisant
  pointer le message de création sur le rectangle
  qui symbolise l'objet créé.
• La destruction est indiquée par la fin de la
  ligne de vie et par une lettre X.

Créer
Détruire
X
101
Activation
Retour implicite
Récursion
Retour explicite
102

• Un objet peut s'envoyer un message.

Message réflexif

• Un objet composite envoie un message à son objet
  composant.

Point d'entrée
103
obj3C3
obj1C1
obj5C5
obj2C2
créer
création
xgt0 mes1(x)
obj4C4
branchement
xlt0 mes2
mesA(z)
Période d activité. Permet de définir quel objet
"à la main"
mes3(w)
Met en évidence les processus parallèles
mes4
récursion
destruction
104
Diagramme de collaboration

• Représente du point de vue structurel et
  dynamique les objets impliqués dans la mise en
  oeuvre dun but
• Modèle expliquant la coopération entre les objets
  utilisés pour la réalisation dune opération ou
  dun cas dutilisation
• Contient
• Collaboration
• Contexte structurel des participants
• objets, classes, liens, associations, attributs
• Interaction
• Séquence de messages échangés entre les objets
• Numérotés
• Informations de contrôle du diagramme de séquence
  sont applicables

105
exemple
Ouvrir
106
Le temps n'est pas représenté de manière
implicite les messages sont numérotés pour
indiquer l'ordre des envois.
1Monter
3Fermer
2Allumer
Les interactions séquence de messages entre
objets
107
1Venir me chercher au RDC
Personne
2Ajouter destination RDC
108
Synthèse des messages

• Consolide l'ensemble des messages entre objets
• Ne montre pas le séquencement
• Intègre tous les scénarios
• Synthèse des dépendances dynamiques entre objets.

décrocher composer chiffre(n) raccrocher
appelantPersonne
Ligne
débuter tonalité arrêter tonalité débuter
tonalité sonnerie arrêter tonalité
sonnerie connecter débuter sonnerie occupée
sonner arrêter sonnerie connecter déconnecter
décrocher raccrocher
appeléPersonne
109
Diagramme de collaboration
Collaboration en réponse à lappui sur le bouton
dappel d un ascenseur
Personne
1 appuyer()
2 mémoriser requête()
réquisition
pilote
Bouton étage
Contrôleur ascenseur
3 allumer()
pilote
pilote
7 éteindre()
4 déplacer()
9 fermer()
8 ouvrir()
5 étage atteint()
6 immobiliser()
Porte
Ascenseur
110
(No Transcript)
111
(No Transcript)
112
Diagramme de collaboration vsDiagramme de
séquence

• Séquence
• accent sur le séquencement  ordre évident des
  messages
• Simplicité
• Mais si ajout de conditions/alternatives/boucles
  perd sa lisibilité
• Collaboration
• accent sur la structure  indique comment les
  objets sont liés
• A propos des comportements conditionnels
• Intégrer les conditions dans le même diagramme ?
  Ou
• Un diagramme séparé pour chaque condition (chaque
  scénarios) ?
• Les diagrammes de séquence sont optimums quand le
  comportement est simple

113
(No Transcript)
114
Diagramme d'Etats

• Un diagramme d'états est associé à une classe
• Il est valable pour tous les objets de cette
  classe
• toutes les instances se comporteront de la même
  façon
• Il contient tous les scénarios possibles dans
  lesquels la classe est considérée
• Un scénario correspond à un chemin dans un
  diagramme d'état

115
Société
Personne
1..
0..1
Age
116
État initial
État final
117
Exemple Transitions entre états de la classe
Personne
118
Événement
Perte demploi
Un événement déclenche la transition qui lui est
associée.
119
Evénement

• Représente un moyen pour transmettre de
  l'information
• Se produit à un instant donné
• N'a pas de durée (par rapport à la durée de
  l'état)
• Peut être
• Événement signal causé par la réception dun
  signal
• Événement appel causé par la réception dun appel
  dopération
• Événement temporel causé par lexpiration dune
  temporisation
• Événement modification exprimée par une
  expression booléenne

120
Evénement Exemples

• Événement signal
•  clic de souris ,  entrée clavier 
• Événement appel
•  crée ,  détruit ,
• Événement temporel 
• Quand (date 1/1/2005) , Après (3 secondes) ...
• Événement modification
• Quand suivi dune condition booléenne

121
Etat d'un objet vs Evènement

• Contexte pendant lequel l'objet est susceptible
  de traiter des événements reçus
• Un état est caractérisé par des valeurs
  d'attributs et/ou de liens
• Un objet répond ou non à un événement en fonction
  de son état

Diagramme d'états d'une porte automatique
Etat
s'ouvrant
porte ouverte
bouton ouverture
Etat initial
ouverte
fermée
bouton ouverture
bouton fermeture
porte fermée
se fermant
122

• Une garde est une condition booléenne qui valide
  ou non le déclenchement d'une transition lors de
  l'occurrence d'un événement.

Événement Condition
Appuyer bouton d ouverture/ascenseur arrêté
Porte fermée
Porte ouverte
123
E1 / Action
A
Etat A
B
on E1 Action entry Action d'entrée exit Action
de sortie
entry on UnÉvénement exit
entry Action d'entrée exit Action de sortie
124
Action

• Traitement instantané et non interruptible
• sa durée n'est pas significative
• Associée à un événement et exécutée lors de la
  transition
• Associée à un état et exécutée en entrant ou en
  sortant

Événement / Action
afficherMenu est l'action qui s'exécute pendant
cette transition
positionnerDebut est l'action qui s'exécute en
entrant dans cet état
bouton droit enfoncé / afficherMenu
menu inactif
menu visible entry/ positionnerDébut
bouton droit levé / effacerMenu
déplacement curseur / positionnerItem
125
Diagramme d'états d'un Menu Fantôme (popup)
Bouton droit activé/afficher menu déroulant
Menu visible do montrer menu
En attente
Bouton désactivé/effacer menu
126
Activité

• Traitement de durée finie ou non
• Interruptible par un événement
• Exécutée durant un état

Diagramme d'états d'une ligne téléphonique
(partiel)
composition du numéro
numéro valide
connexion faite
faireSonner est l'activité qui s'exécute pendant
cet état
connecté
l'appelé décroche
127
/ Op1
Un état
entry Op2 do Op3 exit Op4 on UnEvénement Op5
/ Op6
128
Diagramme d'états structuré

• Structurer les diagrammes d'états
• Eviter l'explosion combinatoire des transitions
• Décomposer le diagramme en sous-diagrammes
• regrouper des états au comportement commun, dans
  un super-état

129
Un sous-état est un état emboîté dans un autre
état, on dit que c est un état composé Un état
composé peut contenir soit des sous-états
séquentiels (disjoints), soit des sous-états
concurrents La représentation graphique est
identique à celle de létat
130
exemple 1 modélisation du comportement dun DAB
CarteInsérée
Actif
Annuler
Fin entretien
entretien
Actif
Emission
131
exemple modélisation du comportement dun DAB
Maintenance
Test
Commande
132
Un diagramme d états-transitions permet de
modéliser les aspects dynamiques dun système à
laide dun automate à états finis On utilise
les diagrammes détats-transition pour la
modélisation du comportement des objets
réactifs Un objet réactif est un objet dont le
comportement se caractérise surtout par sa
réponse aux événements envoyés de l extérieur
de son contexte
133
Diagramme d'activités

• Un diagramme d activités est un organigramme qui
  montre le flot de contrôle d une activité à une
  autre, il modélise les étapes séquentielles et/ou
  concurrentes dans un processus de calcul, il
  contient
• des états dactivité et des états daction,
• des transitions
• des objets

134
Diagramme d'activités

• Chaque activité représente une étape particulière
  dans l'exécution de la méthode englobante.
• Les activités sont reliées par des transitions
  automatiques. Lorsqu'une activité se termine, la
  transition est déclenchée et l'activité suivante
  démarre.

Activité
Autre activité
135
Diagramme d'activités

• Les transitions entre activités peuvent être
  gardées par des conditions booléennes,
  mutuellement exclusives. Les gardes sont à
  proximité des transitions dont elles valident le
  déclenchement.

Mesurer la température
trop chaud
trop froid
Chauffer
Refroidir
136
Diagramme d'activités

• Les diagrammes d'activités peuvent être découpés
  en couloirs d'activités (travées) pour montrer
  les différentes responsabilités au sein d'un
  mécanisme ou d'une organisation. Chaque
  responsabilité est assurée par un ou plusieurs
  objets et chaque activité est allouée à un
  couloir donné.

Enseignant
Jury
Étudiant
Enseigner
Apprendre
Contrôler les connaissances
Composer
Évaluer
137
Diagramme d'activités

• Il est possible de faire apparaître clairement
  les objets dans un diagramme d'activités, soit au
  sein des couloirs d'activités, soit
  indépendamment de ces couloirs.

Vendeur
Expédition
Client
Se renseigner
Établir un devis
Commande passée
Commander
Bon de livraison
Facturer
Commande payée
Payer
Livrer
138
Les modèles de structure
139
Composant définition

• Un composant est une partie physique du système
  qui réalise un ensemble dinterfaces
• Un composant représente tout élément tangible
  entrant dans la fabrication dune application
• code source, binaire relogeable, exécutable
• tout document produit
• un module est un type de composant
• La définition des composants est issue de la
  décomposition en paquetages

- Un composant avec son interface
140
3 types de composants

• Les composants de déploiement comme les
  bibliothèques
• dynamiques (DLL) et les exécutables (EXE)
• les composants produits par le développement
  ils sont
• le résultat du processus de développement
  ce sont les
• fichiers code source et les fichiers de
  données à partir
• desquels les composants de déploiement sont
  créés
• les composants d exécution ils sont crées en
  tant que
• produit d une exécution comme par exemple un
  objet
• COM instancié à partir dune DLL

141
Diagramme de composantsCas Sivex
Base de données agence
Base de données central
Serveur métier
Application agence
Application central
142
Les diagrammes de déploiement

• Montrer
• la disposition physique des différents matériels
  entrant dans la composition dun système
  informatique
• un matériel est représenté par un noeud
• la répartition des programmes exécutables sur ces
  matériels
• décrit comment les composants et objets sont
  disposés dans un système distribué
• Tout système est décrit par un petit nombre de
  diagrammes de déploiement souvent un seul
  diagramme suffit

un poste clientPC
Serveur Base de données
RPC
1..10
noeud
connexion entre noeuds
143
Les diagrammes de déploiement

• La nature de l'équipement peut être précisée au
  moyen d'un stéréotype.
• Les nœuds sont connectés entre eux par des lignes
  qui symbolisent un support de communication

Connection
144
Les diagrammes de déploiement

• Les diagrammes de déploiement peuvent montrer des
  classes de nœuds ou des instances de nœuds.
• Les diagrammes de déploiement peuvent également
  montrer des instances de nœuds.

Maître
1
1..10
Pilote

145
Organisation des noeuds
Des relations de type dépendance, généralisation
ou association sont utilisés pour organiser les
nœuds. La relation la plus utilisée est
l association
10-T ethernet
RS-232
146
Nœuds et Composants

• Les composants sont des éléments qui
  participent à
• lexécution d un système alors que les
  nœuds sont
• des éléments qui exécutent les composants
• Les composants représentent lemballage
  physique
• d éléments logiques alors que les nœuds
  représentent
• le déploiement physique des composants

Un composant est la matérialisation dun ensemble
déléments logiques tels que les classes et les
collaborations et un nœud est lemplacement sur
lequel les composants sont déployés
147

• Diagrammes de cas dutilisation
• Diagramme séquence système

Vue utilisation modèle dusage
Vue statique modèle objet
Vue dynamique modèle dynamique
Diagrammes de classes Diagrammes
dobjets Diagrammes de paquetages Diagrammes de
composants Diagrammes de déploiement
Diagrammes dinteraction séquences ou
collaborations Diagrammes détats Diagrammes
dactivités
148
(No Transcript)
149
(No Transcript)
150
R.U.P. Processus de modélisation
F. Semmak SIL 2004 2005
151
Ingénierie de systèmes dinformation
Besoins des utilisateurs
?
Système Logiciel
CODE
Un processus définit une séquence
détapes,Ordonnées, concourant à obtenir un
système logiciel
152
Les modèles de processus

• Cycle en cascade de Royce 1970
• Cycle en spirale de Boehm 1986
• Cycle itératif
• Cycle incrémental
• Cycle de vie dans les méthodes à objet
• RUP Rational Unified Process

153
Two Track Unified Process (2TUP)
Capture initiale des Besoins fonctionnels
Capture des besoins fonctionnels
Capture des besoins techniques
Analyse
Conception générique
Conception préliminaire
Conception détaillée
Codage test
Recette
154
Capture initiale des besoins
Interviews Pré-étude
Cahier des charges préliminaires
1 Recueil initial des besoins Fonctionnels et
techniques
2 Modélisation du contexte
Contexte
Acteurs
155
Capture des besoins fonctionnels
Cahier des charges
Diagramme U.C.
1 Identifier les cas dutilisation
Fiches de description
2 Décrire les cas dutilisation
Diagramme dynamique
3 Organiser les cas dutilisation
Packages de spécification fonctionnelle
4 Identifier les classes candidates
Diagramme de classes participantes
5 Valider et consolider
Diagramme U.C. affiné
156
Analyse
Architecture logique
Statique
Dynamique
1 Répartir les classes candidates
2 Elaborer le diagramme de classes par package
3 Définir les dépendances entre packages
157
Analyse découpage en catégorie
Une catégorie consiste en un regroupement de
classes à forte cohérence interne et faible
couplage externe. Cohérence consiste à
regrouper les classes sémantiquement
proches Faible couplage consiste à organiser
les paquetages de telle façon quils ne dépendent
pas fortement les uns des autres
158
Analyse Statique
Diagrammes de classes participantes
Cahier des charges
1 Affiner les classes
2 Affiner les associations
Diagramme de Classes optimisé
3 Ajouter les attributs
4 Ajouter les opérations (optionnel)
5 Optimiser avec la généralisation
Diagramme de Classes complété
159
Analyse Dynamique
Diagramme U.C.
1 Identifier les scénarios
2 Formaliser les scénarios
3 Construire les diagrammes détats
Diagramme dinteraction
4 Valider le modèle dynamique
Diagramme détats
5 Confronter modèles dynamiques et statiques
Diagramme de classes complétés
160
Capture des besoins techniques
Cahier des charges
Diagramme de déploiement
Diagrammes U.C. fonctionnels
1 Capture des spécifications techniques
Style darchitec- ture en tiers
2 Spécification logicielle initiale
3 Spécification logicielle détaillée
U.C. techniques
Couches logicielles
U.C. techniques détaillés
161
Capture des besoins techniques
Point de vue matériel Définir le nombre de
niveaux géographiques et organisationnels où
vont se situer les environnements dexécution du
système

• Architecture à 2 Niveaux

Processeur
Processeur
Départemental
Local

• Cas Vidéo Club
• Local la boutique
• Départemental le club

162
Capture des besoins techniques

• Architecture à 3 Niveaux

Processeur

Processeur
Processeur
Central
Départemental
Local
Cas Sivex

• Cas Sivex
• Central les informations partagées entre les
  agences et consolidées au siège
• Départemental pour chaque agence
• Local les applications à déployer au niveau
  des postes de travail

163
Capture des besoins techniques
Point de vue logiciel Le choix dun style
darchitecture conditionne la façon dont
seront organisés les composants dexploitation du
système Le style darchitecture en  Tiers 
spécifie lorganisation des composants mis en
oeuvre pour réaliser le système 2 styles
darchitecture

• Style darchitecture 2-tiers
• Style darchitecture 3-tiers

164
Capture des besoins techniques

• Style darchitecture 2-tiers
• configuration dun système Client-Serveur

Serveur
Client
Traitement lié au stockage des données
Gestion de linterface utilisateur Et des
processus de gestion
165
Capture des besoins techniques

• Style darchitecture 3-tiers
• configuration dun système Client-Serveurs

Serveur de données
Serveur dapplications
Traitement lié au stockage des données
Client
Gestion des processus De gestion
Gestion de linterface utilisateur
166
Conception générique
U.C. techniques
Frameworks design pattern
Couches logicielles
1 Modèle logique
Modèle logique
2 Modèle dexploitation
Modèle dexploitation

• Modèle de configuration
• logicielle (optionnel)

Modèle Config. logicielle
4 Générateur de code
Générateur de code
5 Prototypage
Prototype
167
Conception préliminaire
Modèles danalyse
Acteurs
Diagramme de déploiement
1 concevoir le déploiement
Modèle dexploitation
Modèles de conception générique
2 Concevoir le modèle dexploitation
Modèle logique De conception
3 Organiser le modèle logique
Les interfaces
4 Concevoir les interfaces
5 Concevoir la structure De la présentation
Maquettes Classes dIHM
6 concevoir