Conception des systèmes d`information

Transcription

Conception des systèmes
d’information
Objectifs
Initiation à la modélisation des Systèmes d’Information en
utilisant Merise, UML et les méthodes agiles.






2
Structuration de la démarche informatique,
Méthodes d’analyse et de conception,
Méthodes de modélisation,
Assimiler les caractéristiques et les concepts de l’approche
objet,
Apprentissage des concepts de l’approche objet, de la méthode
UML et les fondements des méthodes agiles
Conception des systèmes d’information
Plan
Merise






Vue d’ensemble de la démarche
Le M.C.D (Modèle conceptuel de données)
Le M.C.T (Modèle conceptuel de traitements)
Le M.O.T (Modèle organisationnel de traitements)
Le M.L.D (Modèle logique de données)
UML


Introduction



Diagrammes UML



3
Cycle de vie d’un logiciel
Historique d’UML
Diagrammes de classes et d’objets
Diagrammes des cas d’utilisation
Autres Diagrammes
Plan
Méthodes agiles




Introduction
Concept
Quelques méthodes agiles


4
Scrum
Extreme Programming
Introduction
Introduction
A quoi sert une méthode ?
Une méthode définit une démarche reproductible qui
produit des résultats fiables.



Une méthode d’élaboration de logiciels décrit comment
modéliser et construire des systèmes logiciels de manière
fiable et reproductible.

De manière générale, une méthode définit :
Des éléments de modélisation,
Une représentation graphique,
Du savoir-faire et des règles



6
Introduction
Les objectifs d’une méthode sont les suivants :





Se donner toutes les chances de mener à bien un projet
informatique,
Établir un plan projet réaliste en définissant, estimant et
planifiant les moyens à mettre en œuvre,
Maîtriser le projet en mesurant son avancement et les écarts
éventuels avec les engagements pris,
S'assurer que la qualité définie est respectée.
Parce que



7
Le système d'information des entreprises actuelles est devenu
l'un des principaux piliers sur lesquels repose l'ensemble de
l'activité.
Impossible donc de traiter ce domaine de manière
approximative.
Introduction
Des méthodes fonctionnelles aux méthodes objet
Une évolution des méthodes qui s’est toujours faite de la
programmation vers l’analyse :


Programmation
Conception
Analyse
Les premières méthodes d'analyse (années 70)


Découpe fonctionnelle (fonctionnelle et hiérarchique) d'un système.
L'approche systémique (années 80)


Modélisation des données + modélisation des traitements (Merise, Axial,
..).
L'émergence des méthodes objet (1990-1995)




8
Prise de conscience de l'importance d'une méthode spécifiquement
objet :
comment structurer un système sans centrer l'analyse uniquement sur
les données ou uniquement sur les traitements (mais sur les deux) ?
Plus de 50 méthodes objet sont apparues durant cette période (Booch,
Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !
Aucune méthode ne s'est réellement imposée.
Introduction
Des méthodes fonctionnelles aux méthodes objet (suite) :
Les premiers consensus (1995)





OMT (Object Modeling Technique - James Rumbaugh) - Méthode
d'analyse et de conception orientée objet.Vues statiques, dynamiques et
fonctionnelles d'un système.
OOD (Object Oriented Design - Grady Booch).Vues logiques et
physiques du système.
OOSE (Object Oriented Software Engineering - Ivar Jacobson). Couvre
tout le cycle de développement. Une des plus anciennes méthodes objet
focalisée sur le modèle statistique.
L'unification et la normalisation des méthodes (1995-1997)




9
UML (Unified Modeling Language) est né de la fusion de ces 3
méthodes qui ont le plus influencé la modélisation objet au milieu des
années 90
Fin 1997, UML devient une norme OMG (Object Management Group).
L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative de
grandes sociétés (HP, Sun, Unisys, American Airlines, Philips...). Son rôle
est de promouvoir des standards qui garantissent l'interopérabilité entre
applications orientées objet, développées sur des réseaux hétérogènes.
Merise
Méthode d’Étude et Réalisation Informatique pour les Systèmes de
l’Entreprise
Vue d’ensemble de la démarche Merise

Qu’est ce que Merise ?

Création : 1978-1979

Plus qu’une méthode d’analyse informatique, une démarche de
construction des Systèmes d’information.

A quoi sert Merise ?


En ce qui concerne les données : A identifier le nombre et la nature des
tables, les articulations et la ventilation des informations entre ces tables,
afin que l'ensemble soit le plus efficace et évolutif possible,

Pour les traitements : A identifier les fonctionnalités selon une approche
"top / down" ("du général au particulier"), leur découpages et leurs
enchaînements.

Merise est un travail d'anticipation : Elle sert à préparer les
développements informatiques et à chiffrer (en coût, en temps et en
énergie) ces chantiers, quelle que soit leur échelle.
L'approche Merise n'est pas adaptée aux projets très complexes
11

La démarche

12
Merise définit la réalité dont elle prend en compte
comme la résultante d'une progression, menée de
front, selon trois axes, qualifiés de "cycles".

Les niveaux d’abstraction

Il y a trois niveaux d’abstraction



13
Le niveau conceptuel
Le niveau organisationnel
Le niveau physique

Le niveau conceptuel

Il consiste à répondre à la question QUOI ?
Quoi faire, avec quelles données ?
A ce niveau, on ne se préoccupe pas de l’organisation du travail
ni du matériel utilisé.

Les deux modèles sont le Modèle conceptuel des données
(MCD) et le Modèle conceptuel des traitements (MCT).
14

Le niveau organisationnel

Il consiste à répondre à la question QUI ?, OU ?, QUAND ?
C’est à ce niveau que sont intégrés les critères d’organisation
de travail.

On tient compte (ou on propose) des choix d’organisation de
travail comme la répartition des traitements entre l’homme et
la machine, le mode de fonctionnement (temps réel, temps
différé).

Le modèle de représentation est le modèle organisationnel des
traitements.
15
Niveau
Conceptuel
Données
Modèle Conceptuel des Données
(MCD)
Signification des informations
sans contrainte technique ou
économique
Modèle Organisationnel des
Données
(MOD)
Organisationnel
Signification des informations avec
contrainte organisationnelles et
économique
Physique
16
Modèle Physique des Données
(MPD)
Description de la ou des bases de
données dans la syntaxe du
logiciel SGF ou SGBD
Traitements
Choix pris en compte
Modèle Conceptuel des
Traitements
(MCD)
Choix de gestion
Activite du domaine sans
Quoi ?
préciser les ressources ou leur
organisation
Modèle Organisationnel des
Traitements
(MOT)
Fonctionnement du domaine
avec les ressources utilisées
Choix d'organisation
Qui ?, Ou ?, Quand ?
Modèle Physique des
Traitements
(MPT)
Architecture technique des
programmes
Choix technique
Comment ?

Objectifs de cette décomposition



17
procéder de manière progressive,
distinguer le quoi (plutôt stable) du comment
organisationnel et technique (plutôt instable),
ne prendre en compte qu'une classe de problèmes à chaque
niveau.

Cycle de vie

Maîtrise de la chronologie des opérations


Succession de phases contrôlables par l’organisation (planning,
échéances, moyens humains, etc.)
4 étapes

Schéma directeur



Il s’agit de la traduction de la stratégie de l’entreprise.
La réalisation d’un schéma directeur répond à un objectif principal :
adapter l’organisation et les moyens de traitement de l’information aux
axes stratégiques de l’entreprise.
Objectifs



18
clarifier les centres d'intérêt,
les pôles de décision,
donner une première idée de la chronologie des évènements

Etude préalable
 Ce
document doit permettre une première mesure de
l'impact financier et administratif des grandes
orientations définies dans le schéma directeur.
 Il comporte
 L'étude de l'existant
 La définition du "Quoi ?" futur ("MCD" et "MCT")
 Le scénario (coût, impact sur l'organisation etc.)
 Le graphe de circulation de l'information pour les
procédures les plus représentatives.
 Une première approximation quant aux choix de
matériels et de logiciels, ainsi qu'une estimation du
volume de l'information qui sera traitée.
19

Etude détaillée
 La
définition du "Qui ?", du "Où ?" et du "Quand ? ».
C'est-à-dire la "vision utilisateurs"(soit les MOT et
MLD).
 But
 décrire de façon exhaustive l’application qui devra
être développée, c’est-à-dire les interfaces graphiques,
les traitements et les états imprimés.
 Elle se présente sous la forme d'un descriptif précis
portant sur les données en amont et en aval de
chaque opération, et sur le mode de traitement de
chacune de ces opérations.
 Elle débouche sur un dossier de spécifications
détaillées.
20

Etude technique
 Les
données sont réajustées et stabilisées, l'essentiel des
traitements (les algorithmes fondamentaux) est décrit.
 C’est seulement à ce stade qu’est censée commencer la
réalisation.
 La réalisation concerne la production du code
informatique correspondant aux spécifications définies
dans l’étude détaillée.
 Elle débouche sur un dossier de réalisation.
21

Cycle de décision

Fixation de jalon de validation


Importance de la Méthode mise sur un échéancier de
rencontres entre




Les responsables des différents pôles de l’entreprise
Les utilisateurs
On désigne par le terme d'échéancier (éventuellement
jalonnement) l'enchaînement des dates des jalons.
Objectifs des jalons


22
Le terme de jalon est utilisé pour désigner les événements sensibles
de la réalisation du projet nécessitant un contrôle. Chaque jalon
permet de vérifier que les conditions nécessaires à la poursuite du
projet sont réunies.
Faire prendre conscience de la charge de travail
Des difficultés relationnelles que supposent une collaboration, une
compréhension et une implication dans un processus de décision

Cycle d’abstraction

23
Dissociation des données et des traitements et l’étude de leurs
interactions

Cycle d’abstraction

Il s’agit d’un déroulement de données / traitements,
selon 3 niveaux correspondant à trois groupes de
questions :



24
Le "niveau conceptuel" (le "Quoi ?"), aboutissant aux M.C.D.
("Modèle conceptuel des données") et M.C.T. ("Modèle
conceptuel des traitements"). A ce stade, données et
traitements sont étudiés de manière parallèle, dissociée.
Le "niveau logique" (pour les données) et le "niveau
organisationnel" (pour les traitements) (le "Qui?", le
"Quand ?", le "Où ?") correspondants aux M.O.T ("modèle
organisationnel des traitements") et M.L.D. ("Modèle
logique des données").
Le "niveau physique" (pour les données) aboutissant à la
création des tables, et le "niveau opérationnel" (pour les
traitements) enclenchant analyse détaillée de chaque
traitement, et développements
Merise
Le M.C.D
Le M.C.D (Modèle Conceptuel de Données)



Représentation statique, sous forme schématique, de la
situation respective des données d'un domaine de gestion.
Ce schéma est conçu pour être très stable dans le temps.
Objectif


Définir (identifier) toutes les données utilisées, les
regrouper en ensembles appelés entités, et de lier ces
entités par des relations, dans un modèle définit et
compréhensible par toute personne connaissant la
"syntaxe" du MCD.
Le MCD regroupe les informations à traiter, le
"quoi" du système.
26

Les étapes du MCD






27
Catalogue des données
Épuration (polysèmes et synonymes)
Détermination des entités
Détermination et affectation des propriétés
Recensement des associations (avec, éventuellement, les
propriétés non encore affectées
Détermination des cardinalités

Entité

28
Représentation d'un objet réel, ayant une existence et
une raison d'être dans le système d'information.

Entité



29
Une entité est pourvue d’une existence propre et est
conforme aux choix de gestion de l’entreprise.
Une entité peut être un acteur : client, usine, produit
Une entité peut être un flux : commande, livraison

Les propriétés

30
Une propriété est une donnée élémentaire qui qualifie
l’entité à laquelle elle se rapporte :
 Chaque propriété prend des valeurs qui sont
appelées occurrences de la propriété,
 Chaque propriété a un domaine de définition
(ensemble de valeurs possibles),
 Chaque propriété se rattache toujours à une entité.
 Identification d’une Entité :

Identification d’une entité

31
C’est une propriété (ou ensemble de propriétés)
particulière qui permet d’identifier de façon unique une
occurrence de l’entité.
 Pour être identifiant, la propriété ou le groupe de
propriétés ne doit pas prendre plusieurs fois la même
valeur sur l’ensemble des occurrences de l’entité.
 L’identifiant figure en premier dans la liste des
propriétés
 Il est souligné

Association (ou Relation)


32
Objet permettant d'associer deux ou plusieurs entités. Ce lien est nommé
et est, par convention, très souvent un verbe à l'infinitif.
Exemple :
 entre deux entités, Personne et Ordinateur, une relation nommée
Posséder peut être mise, et on lit "une personne possède un
ordinateur" et, dans l'autre sens, 'un ordinateur est possédé par une
personne".

Association (ou Relation)


33
Objet permettant d'associer deux ou plusieurs entités. Ce lien est nommé
et est, par convention, très souvent un verbe à l'infinitif.
Exemple :
 entre deux entités, Ouvrage et Auteur, une relation nommée Écrire
peut être mise, et on lit "un Auteur a écrit un Ouvrage" et, dans l'autre
sens, 'un Ouvrage est écrit par un Auteur".

Cardinalité d’une Association

34
C'est le nombre d'occurrences, minimal et maximal, d'une association par
rapport à chaque occurrence d'une entité donnée. D'une entité donnée
vers une association donnée.

Exemple 1

Un employé a une et une seule société. Une société a 1 ou n employés.
1,1

1,n
Exemple 2

Une commande est composée de 1 ou n produits distincts en certaine
quantité. Un produit est présent dans 0 ou n commandes en certaine
quantité.
Produit
compose
Commande
1,n

Société
a
Employé
quantité Entier
0,n
Exemple 3

Un étudiant parle une ou plusieurs langues avec un niveau. Chaque
langue est donc parlée par 0 ou n étudiants avec un niveau. Pour chaque
niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.
Langue
Etudiant
1,n
parle
0,n
0,n
35
Niveau

Une centrale d’achat : les cardinalités
T YPE
0 ,n
a p p a rti e n t
1 ,1
O UV RA G E
é d i te
q u a n ti té
E n ti e r
E n ti e r
sto cke
q u a n ti té
E n ti e r
0 ,n
0 ,n
36
A UT E UR
0 ,n
1 ,n
q u a n ti té
0 ,n
0 ,n
0 ,n
ve n d
é cri t
E DIT E UR
0 ,n
L IB RA IRIE

Cas des associations de dimension 1 (réflexives)

Cas des associations de dimension 3
37
Merise
Le M.C.T
Le M.C.T (Modèle Conceptuel de Traitements)

Représentation, sous forme schématique, de phénomènes
de réactions du type et ceci indépendamment de toute
préoccupation d'organisation interne :


Évènement déclenchant -> Transformation du système
d'information -> Résultat
Implication du monde extérieur au niveau de chaque
opération :


39
Soit au niveau des évènements déclenchant
Soit au niveau des résultats

Les étapes du MCT




40
Identification des acteurs (Rappel : il s'agit des acteurs
extérieurs à l'entreprise).
Identification et classement chronologique des flux.
Construction du M.C.T.
Description détaillée des règles de gestion.

Processus


Définition

Ensemble structuré d’événements, opérations et résultats consécutifs
qui concourent à un même but.

Il représente généralement un sous ensemble d ’activités de
l ’organisation dont les événements initiaux et les résultats finaux
délimitent un état stable du domaine.

Il est en général caractéristique du secteur d ’activité de
l ’organisation et constitue de ce fait un invariant pour le concepteur.
Exemple (Processus Prêt)

Ensemble des opérations consécutives à la demande de prêt :



41
Élaboration devis,
Instruction d ’un dossier de prêt,
Mise en place du prêt.

Exemple : Processus Prêt
Demande Client
Demande Client
Demande de prêt
PROPOSITION
Elaboration du devis
Elaboration de la
proposition
DEVIS
Elaboration du devis
Demande de prêt
ET
PROPOSITION
Elaboration de la
proposition
DEVIS
42
DEVIS

43


Les relations entre « acteurs » peuvent être traduites soit par
un « graphe des flux » soit par une « matrice des flux ».
CLIENT
BANQUE
BDF
DGI
Demande de
renseignements
Déclaration
ouverture de
compte
Demande du
client
CLIENT
BANQUE
BDF
Accord ou Refus
Réponse BDF
DGI
MATRICE DES FLUX
44


Evènement
 Collection de faits, susceptibles de déclencher une
Opération dans les conditions précisées par la
Synchronisation.

Synchronisation
 Condition booléenne traduisant les règles d'activation
d'une opération.

Opération
 Ensemble d'actions dont l'enchaînement ininterruptible
n'est conditionné par l'attente d'aucun évènement
autre que le déclencheur initial.

Règles d'émission
 Condition traduisant les règles de gestion, à laquelle
est soumise l'émission des résultats d'une opération.

Résultats
 Collection de faits, produits par l‘Opération, dans les
conditions prévues par la (ou les) "règles d'émission".
45

46
Merise
Le M.O.T
Le M.O.T (Modèle Organisationnel de
Traitements)



Le M.O.T a pour objectif de représenter les traitements en prenant en
compte les choix et les contraintes liées à l’organisation.
La modélisation s’effectue en faisant abstraction du COMMENT faire
technologique.
Qui est qui? Qui fait quoi?




Quand?


Analyse des postes de travail.
Partage des traitements entre l’homme et la machine.
Type d’individu qui réalisera les traitements.
Influence du temps et comment structurer les traitements en
conséquence.
Où?

48
Comment les traitements sont-ils organisés dans l’espace ?
Traitements)

Le M.O.T se concentre sur le COMMENT




Il s’agit ici de



Définition des différentes ressources à mettre en œuvre
(moyens techniques ou humains, espace, temps, données)
Décomposition des opérations spécifiées au niveau conceptuel
en des éléments plus fins et homogènes, les tâches
Organisation de l’ensemble des ressources permettant
d’assurer l’exécution des tâches envisagées
spécifier le contenu de chaque opération conceptuelle,
construire une ou plusieurs solutions organisationnelles
La difficulté réside dans la diversité des solutions
d’organisation envisageables
49
Traitements)

Formalisme du M.O.T

Le MOT reprend les concepts du MCT, parfois réadaptés,
auxquels sont ajoutés de nouveaux concepts tels que :




50
le poste de travail : entité physique comprenant des ressources sur un
lieu donné et un responsable.
la tâche/opération : affectation des traitements d’une opération
conceptuelle à une unité organisationnelle de type site ou service.
la procédure organisationnelle : enchaînement de traitements (tâches
et/ou phases) affectés à un ou plusieurs sites ou services au sein d’un
même processus.
Le MOT cerne l'activité de chaque poste de travail
(informatique ou non), et de chaque service, en tenant compte
du "planning", du type de ressources (manuel, automatisé), du
type de support (document écrit, magnétique etc.)
Traitements)
MOT = MCT + Lieu + Moment + Nature



Lieu : qui exécute ? Acteurs.
Moment : Quand exécute t-on l’opération ? Agencement
temporel.
Nature : Manuelle,Automatique, Interactive
51
Traitements)

Construction du M.O.T






52
Faire le choix des postes, en spécifiant les ressources humaines
et informatiques
Décomposer chaque opération conceptuelle en opérations
organisées, les ordonner, les affecter aux postes, préciser les
différentes caractéristiques (degré d’automatisation, délai de
réponse, mode de travail)
S’assurer de la faisabilité des opérations organisées par rapport
aux ressources composant le poste
Préciser les différentes phases
Évaluer l’ergonomie générale de chaque poste de travail par
rapport à l’ensemble des phases à assurer
Envisager des solutions alternatives: variantes de procédures
Traitements)
Procédure décomposée en opérations et par poste de travail
Partenaire
Poste 1
Poste 2
Poste 3
Partenaire
Message externe
enclanchant
Un MOT analyse les réactions des postes de travail à un message externe
53
Traitements)
Il est possible de représenter le temps sous forme d’une colonne
comme un acteur
Temps
Poste 1
Poste 2
Poste 3
T0
TO + 10 jours
54
Partenaire
Traitements)
55
Merise
Le M.L.D
Le M.L.D (Modèle Logique de Données)

C'est grâce à toutes les opérations précédentes que
l'ensemble des tables de la base de donnée vont pouvoir
être structurées de manière simple et très rapide :



le M.C.D, ayant été corrigé à la fin de l'étape du M.O.T, ce sont
les cardinalités maximales qui vont jouer le rôle essentiel.
les entités deviennent des tables (sauf des cas particuliers
comme les "dates")
Si l'une des cardinalités maximales est à "1" et l'autre à
"n", l'association disparaît et l'identifiant de l'entité
marquée "n" vient s'ajouter à la liste des propriétés de
l'entité marquée "1" (Cas 1).
57

Si toutes les cardinalités maximales sont à "n",
l'association se transforme en une table qui permettra la
correspondance entre les enregistrements des tables
reliées (tout en pouvant comporter ses propres
propriétés) (Cas 2).

Ces règles s'appliquent aussi bien pour les associations
"réflexives" (Cas 3).

Pour les associations de dimension "3" ou plus, elles sont
toujours transformées en table (Cas 4).
58
59
60
61
62
63
64
65
66
UML
68



Processus (ensemble d’activités) nécessaire au
développement et à la maintenance d’un logiciel
Composé de plusieurs phases autonomes mais
dépendantes (interdépendantes).
Chaque étape se termine par la remise de un ou
plusieurs documents validé conjointement par
l’utilisateur et le développeur.
68
69
Étapes nécessaires à la réalisation d’un logiciel:






69
Analyse
Conception
Codage (Implémentation)
Tests
Livraison
Maintenance
Modèle en Cascade (WaterFall)
70
Analyse
Conception
Implémentation
Tests
Maintenance
70
Analyse
71




Elle a pour but de dégager le problème à étudier.
Le résultat de l'analyse est le cahier de charges
(exprimé dans une langue naturelle) contenant les
besoins du futur système.
Cette spécification est informelle.
3 phases:(Faisabilité, Spécifications des besoins,
Organisation du projet)
71
Faisabilité
72


Première étape du cycle de vie d’un logiciel
Répondre à deux questions :
 Est-ce que le logiciel est réalisable ?
 Est-ce que le développement proposé vaut la
peine d’être mis en œuvre ?
►► Étudier le marché pour déterminer s’il existe
un marché potentiel pour le produit.
72
Spécification des besoins
73


Permet de définir ce que doit faire le logiciel et non
comment il le fait
Quatre types de spécifications




73
Spécifications générales
Spécifications fonctionnelles
Spécifications d’interface
Spécifications techniques
74
La spécification générale consiste à identifier :
 Objectifs à atteindre
 Contraintes (utilisation du matériel et outils
existants)
 Règles de gestion à respecter
74
75
Spécification fonctionnelles est la description des
fonctionnalités du futur logiciel de manière aussi
détaillée que possible
Spécification d’interface décrit les interfaces du
logiciel avec le monde extérieur : homme (IHM),
autres logiciel (Middleware), machines
75
76
Spécification technique :(Étude de l’existant)




76
Moyens d’accès (local, distant, Internet, …)
Temps de réponse acceptable (gestion des GAB, gestion des
emplois de temps, …)
Plateforme (Windows, Unix, …)
Quantité d’informations à stocker (choix du SGBDR, …)
Organisation du projet
77



Appelée aussi Planification et gestion de projet
Permet de déterminer la manière de développer le logiciel
La phase de planification permet de :



77
découper le projet en tâches
décrire leur enchaînement dans le temps,
affecter à chacune une durée et un effort
Organisation du projet
78
Plusieurs étapes :



78
Analyse des coûts: estimation du prix du projet
Planification: calendrier pour le développement (jours
ouvrables, jours fériés, nombre d’heures de travail par jours,
…)
Répartition des tâches: distribuer les tâches et les sous tâches
(affectation des ressources aux tâches)
Conception
79



Permet de fournir une description fonctionnelle
(formelle) du système en utilisant une méthode.
Les méthodes proposent des formalismes (dans la
plupart des temps graphiques) pour concevoir le
système.
Deux types de conception :


79
Conception générale
Conception détaillée
Conception générale
80
Appelée aussi : ‘Conception architecturale’
 Se focaliser sur l’architecture générale du système :
décomposition du système en sous système
Exemple, pour la gestion scolaire :




80
Étudiants (étudiants, notes, prof, filières, …)
Administration (personnel administratif, …)
…
Conception détaillée
81


Produire une description externe de chacune des
procédures, fonctions et des structures de données
(conception classique)
Produire de manière précise les contenus des
objets en terme de propriétés et de méthodes
(conception Orientée Objet)
81
implémentation (Réalisation)
82


Des programmes seront élaborés afin de mettre en
œuvre des solutions techniques précédemment
retenues
Plusieurs types langages sont utilisés:


82
Langages classiques (C, Pascal, Fortran, …)
Langages orientés objets (C++, Java, C#, …)
Codage et Tests
83
On distingue plusieurs types de tests :






83
Test unitaire: tester les parties du logiciel par les développeurs
Test d’intégration: tester pendant l’intégration des modules
Test système: tester dans un environnement proche à celui de
production
Test alpha: tests faits par le client sur le site de développement
Test bêta: tests faits par le client sur le site de production
Test de régression: enregistrer les résultats des tests et les comparer
avec ceux des anciennes versions pour déterminer si la nouvelle n’a pas
apporté de dégradation de performance.
Livraison
84


Fournir au client une solution logicielle qui
fonctionne correctement.
Plusieurs tâches :



84
Installation: rendre le logiciel opérationnel sur le site du client
Formation: enseigner aux utilisateurs à se servir de ce logiciel
Assistance: répondre aux questions de l’utilisateur
Maintenance
85


Mettre à jour et améliorer le logiciel
La maintenance comprend :



85
Corrective : correction des erreurs et anomalies
Adaptative : adaptation à de nouveaux environnements
Évolutive ou Perfective : ajout de nouvelles fonctionnalités
Documents
86


Cahier des charges : description des fonctionnalités
désirées (décrites par l’utilisateur)
Spécifications : décrit ce que doit remplir le logiciel
(décrites par le développeurs) :



86
Modèle Objet : Classes et objets
Scénarios des cas d’utilisation : différents enchaînements possibles du
point de vue de l’utilisateur
…
Documents
87



Calendrier du projet: indique les tâches, les délais et
les ressources
Plan de test: indiquent les procédures de tests à
appliquer
Manuel d’utilisateur: mode d’emploi du logiciel dans
sa version finale
87
Documents
88



Code source: code complet du produit fini
Rapport des tests: décrit les tests effectués et les
réactions du système
Rapport des défauts: décrit les comportements du
système qui n’ont pas satisfait le client.
88
Historique
Deux approches

Approche fonctionnelle



1960 – fin 1970
l'important c'est les traitements
Séparation nette des données et traitements
Approche objet




89
1980 – début 1990 : premières génération
L'important c'est l'objet
Objet = données + traitements
Historique
Début des années 1990


les premiers processus de développement OO apparaissent
prolifération des méthodes et notations étaient la cause de
grande confusion :






90
méthode OOD de Grady Booch (1991)
méthode OMT de James Rumbaugh (1991)
méthode OOSE de Ivar Jacobson (1991)
méthode OOA/OOD de Coad and Yourdon (1992)
méthode de Schlaer and Mellor (1992)
Etc.
Historique
Fin 1994
 J. Rumbaugh rejoint G. Booch chez Rational Software
 OMT + OOD  Unified Method (oct 1995)
Fin 1995
 I. Jacobson les rejoint chez Rational Software
 Unified Method + OOSE  UML 0.9 (juin 1996)
Début 1997
 Partenaires divers : Microsoft, Oracle, IBM, HP et autres leaders
collaborent

 UML 1.0 (jan 1997)
Fin 1997
 l’OMG (Object Management Group) retient UML 1.1 comme norme
de modélisation
M.A1
91
Diapositive 91
M.A1
OMG (fondée en 1989) Organisation Internationale regroupant plus de 800 membres : vendeurs de systèmes, développeurs de logiciels,
utilisateurs, ...
Madani; 01/06/2006
Historique
Les versions se succèdent :





Début 1998
 UML 1.2
En 1998
 UML 1.3
En 2001
 UML1.4
En 2003
 UML 1.5
En 2005
 UML 2.0
M.A2
92
Diapositive 92
M.A2
OMG (fondée en 1989) Organisation Internationale regroupant plus de 800 membres : vendeurs de systèmes, développeurs de logiciels,
utilisateurs, ...
Madani; 01/06/2006
Qu’est ce que UML ?
UML(Unified Modeling Language) un langage de
modélisation unifié
 Langage = syntaxe + sémantique :


93
syntaxe : notations graphiques consistant essentiellement en
des représentations conceptuelles d'un système
sémantique : sens précis pour chaque notation

UML est caractérisé par :





un travail d'expert
utilise l’approche orientée objet
normalisé, riche
Formel : sa notation limite les ambiguïté et les incompréhensions
langage ouvert



94
INDÉPENDANT du langage de programmation
Domaine d'application : permet de modéliser n'importe quel système
Supporté par plusieurs outils (AGL) : Objecteering, Open tools,
Rational Rose, PowerAMC, WinDesign, …
Apports de UML
favorise la communication entre :



95
développeurs et futurs utilisateurs
 analyse des besoins, spécification
équipes de conception et de développement
 conception
Attention
UML est un langage (et non pas une méthode) qui :
 permet de représenter les modèles
 ne définit pas le processus d'élaboration des modèles.
96
Diagrammes d'UML
UML comprend 9 diagrammes :
Diagramme
Est sorte de
’utilisation
CasCasd d’utilisation
Collaboration
97
Classes
Classes
Composants
EtatsTransitions
Transitions
États
Déploiement
Séquence
Séquence
Activité
Objets
Diagrammes d'UML
UML définit deux types de diagrammes, structurels (statiques)
et comportementaux (dynamiques)


Modélisation de la structure
 diagramme de classes
 diagramme d’objets
 diagramme de composants
 diagramme de déploiement
Modélisation du comportement
 diagramme de cas d'utilisation
 diagramme d’états
 diagramme d’activités
 diagramme de collaboration
 diagramme de séquence
98
Diagramme d’UML
Les diagramme d’UML peuvent être utilisés pour
représenter différents points de vues :
 Vue externe : vue du système par ses utilisateurs finaux
 Vue logique statique : structure des objets et leurs
relations
 Vue logique dynamique : comportement du système
 Vue d’implémentation : composants logiciels
 Vue de déploiement : répartition des composants
99
Diagramme d’UML
Cas d’utilisation
Composants
Objets
Classes
Vue logique statique
(Structure des objets)
Vue Implémentation
(composants logiciels)
Vue externe
(fonctions système)
Séquence
Vue logique dynamique
(Comportement)
Collaboration
États transitions
100
Vue déploiement
(Environnement
d’implantation)
Activités
Déploiement
UML
Diagrammes de classes et d’objets
Diagramme de classes

Permet de donner une vue statique du système en terme
de :


Classes d'objets
Relations entre classes




Associations
agrégation/composition
héritage
La description du diagramme de classes est centrée sur
trois concepts :



102
Le concept d’objets
Le concept de classes d’objets comprenant des attributs et des
opérations
Les différents types de relations entre classes.
Concept d'objet
Objet = un concept, abstraction ou une chose autonome
qui a un sens dans le contexte du système à modéliser




103
une personne : le client « Louizi M. »
un objet concret : le livre intitulé « Initiation à… »
un objet abstrait : le compte bancaire n° 1915233C
…
Concept d'objet
Remarque
 Un objet doit :





Être autonome
Avoir une signification dans le système
En relation avec d'autres objets
Ne pas confondre "autonomie" avec "indépendance"!!
Exemples


104
Gestion de stock : Clients, Commandes, Articles, …
Gestion scolaire : Étudiants, Modules, Filières, …
Concept d'attribut

Un attribut est une propriété, caractéristique d’un objet.
Par exemple :



un client a un nom, un prénom, une adresse, un code
client, …
un compte bancaire a un numéro, un solde, …
Un attribut doit (généralement) avoir une valeur
atomique
105
Concept d'attribut
La description d’un attribut comporte :
Visibilité attribut:type[= valeur initiale]
Où :
 Visibilité :






+ (publique, public) : visible par tous
- (privée, private) : visible seulement dans la classe
# (protégée, protected) : visible seulement dans la classe et dans
les sous-classes de la classe.
Nom d’attribut
Type de l’attribut
Valeur initiale (facultative)
106
Concept d'attribut
Le type d’un attribut peut être :



Un type de base : entier, réel, …
Une expression complexe : tableaux, enregistrements, …
Une classe
Exemples d’attributs :



107
- couleur : enum{Rouge,Vert, Bleu}
# b : boolean = vrai
- Client : Personne
Concept d'attribut
Lorsqu’un attribut peut être dérivé ou calculé à partir
d'autres attributs, il est précédé d’un /. Par exemple, une
classe « Rectangle » peut contenir les attributs suivants :



longueur : réel,
largeur : réel,
/surface : réel.
Rectangles
- Largeur
: float
- Longueur : float
- /Surface : float
108
= 10
Concept d'attribut
On distingue deux types d'attributs :
 Attribut d'instance :



Chaque instance de la classe possède une valeur particulière pour
cet attribut
Notation : Visibilité attribut:type[= valeur initiale]
Attribut de classe



109
Toutes les instances de la classe possède la même valeur pour cet
attribut
Notation : Visibilité attribut:type[= valeur initiale]
Équivalent en C++, Java : static
Concept d'attribut
Window
-
taille
visibilité
taille_defaut
taille_max
:
:
:
:
Rectangle
boolean
Rectangle
Rectangle
= (100,100)
= true
+ <<Constructor>> Window ()
+
afficher ()
+
cacher ()
+
getTaille_max ()
+
getTaille_defaut ()
110
Attributs d'instances
Attributs de classes
:
:
:
:
void
void
Rectangle
Rectangle
Opérations d'instances
Opérations de classes
Concept d'opération et méthode
Une opération est :
 un service offert par la classe
 une fonction ou une transformation qui peut être
appliquée aux objets d’une classe.
 permet de décrire le comportement d’un objet. Par
exemple, « Embaucher », « Licencier » et « Payer » sont
des opérations de la classe « Société ».
111
Une méthode est
 l’implémentation d’un service offert par la classe
(opération).
 de différents types :



112
accesseurs (get...): renvoie une information sur l'état
d'un objet (fonction)
modifieurs (set...): modifie l'état de l'objet (procédure)
constructeurs: initialise une nouvelle instance
La description d’une opération comporte :
Visibilité opération([arguments:type[=valeur
initiale]]):type de résultat




113
Visibilité de l’opération (-, +, #)
Nom de l’opération
Liste des arguments avec leurs types et éventuellement leurs
valeurs par défaut
Le type du résultat retourné
Exemples d'opérations :
Compte
- N°Compte : String
: float
- Solde
: Personne
- Client
+ <<Constructor>> Compte ()
Deposer (float somme) : void
+
Retirer (float somme) : float
+
+
: String
AvoirSolde ()
114
Concept de classes d’objets

Classe = ensemble d’objets ayant les mêmes propriétés
(attributs) et le même comportement (opérations)




tous les clients sont décrits par un nom, un prénom, … et
peuvent marcher, parler,courir, …
tous les comptes bancaires ont un numéro, un solde, … et sur
lesquels on peut déposer ou retirer l'argent, ou les consulter
…
Un objet est instance d’une classe, et le fait de créer un
objet d'une classe est dite instanciation.
115
Classe représentée par un rectangle à trois parties :



116
Partie 1 : Nom de la classe
Partie 2 : Attributs (propriétés, champs)
Partie 3 : Méthodes (fonctions, opérations)
Compte
- Solde
: float
# Client
: Personne
= 100
+
Deposer (float somme) : void
+
Retirer (float somme) : float
AvoirSolde ()
: String
+
117
Concept de classe d'objets
On peut ne pas visualiser les attributs et/ou les opérations,
afin de ne pas alourdir inutilement le schéma.
Nom de la classe
Nom de la classe
Nom de la classe
Attributs
Attributs
Opérations
Opérations
118
Nom de la classe
Encapsulation, visibilité et interface



Encapsulation est le mécanisme de regrouper les attributs
et les opérations au sein d’une même entité (classe)
Ce regroupant permet d’empêcher d’accéder
directement aux données par un autre moyen que les
services proposés (opérations)
Ces services offerts aux utilisateurs définissent ce que
l’on appelle l’interface de la classe.
119
Encapsulation, visibilité et interface
Données
Traitement
}
}
•Partie statique, passive
•Partie cachée, privée
•Partie dynamique, comportementale
•Partie visible, publique
•Interface avec l’extérieur
User
120
Méthodes et classes abstraites


Une méthode est dite abstraite si on connaît son entête,
mais pas la manière dont elle peut être réalisée
Une classe est dite abstraite lorsqu’elle définit au moins
une méthode abstraite
FormeGéométrique
{abstract}
- abs : int
- ord : int
+
+
+
+
121
{abstract}surface () : double
getAbs ()
: int
getOrd ()
: int
... ()
Classe « Interface »


Une interface est une classe spéciale dont toutes les
méthodes sont abstraites
Une interface se note en UML avec le stéréotype
<<interface>> ou symbole
Forme
122
Package


Un package permet de regrouper des classes, des
interfaces et des packages.
Les classes, les interfaces et les packages ne peuvent
qu’un seul package dans lequel ils sont regroupés
123
Package

Un package est représenté par un rectangle possédant un
onglet dans lequel est inscrit le nom du package
124
Import des packages


La relation d’import permet à une classe d’un package
d’utiliser les classes d’un autre package.
La relation est monodirectionnelle : elle comporte un
package source et un package cible.
125
Import de packages


La relation d’import s’exprime avec une flèche en
pointillé
Dans l’exemple, la classe ‘Afficheur’ a besoin des classes
du package ‘Dessin’
126
Associations



Relation existant entre une, deux ou plusieurs classes.
Une association porte un nom (signification)
Représentée par une ligne rectiligne
127
Associations
Remarques
 une association fonctionne (généralement) dans les 2 sens
(bidirectionnelle)
 termes associés : Nom, Sens de lecture, degré (arité),
Multiplicité, Rôle, navigabilité et le qualificateur
128
Associations
Nom et sens de lecture


Décrit la nature (signification) de l’association
Montre la direction de lecture de l’association
129
Associations
Rôle d’une association
Décrit le rôle d’une classe dans une association
130
Associations
Rôle d’une association
Utile surtout dans deux cas :


Lorsqu’on a plusieurs associations entre deux classes avec des
rôles différents
une relation réflexive : relation entre deux instances d’une
même classe
Avion
Pilote
Personne
Personne
0..4
femme
Passager
0..1
mari
131
Associations
Classe association
Une association peut avoir des attributs = classe-association
132
Associations
Classe association

Les classes association sont utiles quand il y a des
attributs qui sont pertinents à l’association, mais à aucune
des classes impliquées.
Personne
Entreprise
1..*
0..1
Emploi
- Période : int
- Salaire : float
133
Associations
 degré d’une association = nombre de classes participantes
Association unaire : relie 2 instances d'une classe
association binaire : relie 2 classes
 association ternaire : relie 3 classes
 association n-aire : relie n classes
134
Associations
Multiplicité = nombre de participations d’une classe dans une
association
 indiquée à chaque extrémité d’une association
 sous la forme min..max
 min, max = 0, 1, *
 Exemple général
 Exemple concret
135
Associations
 Exemple ternaire
 Pour un couple d’instances de la classe A et de la classe B,
il y a au min. r1 instances de la classe C et au max. r2 instances,
…
…
136
Associations
Notation abrégée des multiplicités :
1

1..1 (exactement 1)
*

0..* (0 ou plusieurs)
n

n .. n (exactement n)
1..*  1 ou plusieurs (1 ou plus)
0..1  0 ou 1 (au plus un)
1..100  entre 1 et 100
2,4,5  2, 4 ou 5
137
Association
Navigabilité

Une association est par défaut bidirectionnelle.
Commandes
Clients
1..*
1

Cependant, il peut être utile de se limiter à une seule
direction  association navigable
138
Association
Navigabilité (Exemple)


Spécification : on doit être en mesure de savoir le client
qui a fait la commande et non toutes les commandes d’un
client
Conception :
Commandes
Clients
1..*
1

Implémentation : la classe commande doit avoir un champ
faisant référence à la classe client
139
Association
Navigabilité (Exercice)
Un étudiant peut avoir jusqu’à 5 copies d’examens. À un
étudiant sont associées ses copies d’examens, mais on ne
doit pas autoriser l’accès à l’auteur de la copie
(notamment avant la correction des copies)
140
Qualification d'une association


La qualification d’une association permet de restreindre la
multiplicité d’une association.
La qualification se représente par un rectangle placé au
niveau de la classe source du qualificatif.
141
Exemple : une banque contient plusieurs comptes, d'où le
diagramme :
Banque
Compte
1..*
1
Par contre, si on connaît le N°Compte, il y a un
et un seul compte, on obtient alors :
Compte
Banque
NCompte
1
142
1
Exercice
 Un avion est composé de plusieurs sièges, mais dans une
rangée il y a seulement quatre sièges.
143
Agrégation
Type particulier d’association dans laquelle :


Classe agrégat (composé), classes agrégée (composant)
Entre les deux, il existe une relation de type « est composé de »
Agrégat
144
Agrégée
Agrégation


Les parties (les composants) sont séparables de L’agrégat
(le tout)
La suppression d’une équipe n’implique pas la suppression
des personnes qui la composent
145
Agrégation
Titre
0..1
Un agrégat (composé) peut être multiple.
1..1
Destinataire
1..*
E-Mail
0..*
0..*
*
Ici, on exprime qu'un fichier peut être attaché à un email (ou a
plusieurs, ou même à aucun) et qu'un email peut (ou non)
attacher (contenir une copie) une ou plusieurs fichiers.
1..1
0..1
Texte
146
Fichier
Composition



La composition est un cas particulier d’une agrégation
dans laquelle la vie des composants (élément) est liée à
celle de l’agrégat (composé) : si l’agrégat est détruit (ou
déplacé), ses composants le sont aussi.
D’un autre côté, et contrairement à l’agrégation, une
instance de composant ne peut être liée qu’a un seul
agrégat.
La composition se représente par un losange noir (plein).
147
Composition
 la suppression d’un objet agrégat entraîne la suppression des
objets agrégés
148
Composition


Un document est composé de plusieurs paragraphes, qui,
à son tour, est composé de plusieurs phrases
Remarquer la propagation des opérations (copie,
suppression,…)
149
Généralisation / Spécialisation et
héritage




La généralisation est la relation entre une classe et une
ou plusieurs de ses versions raffinées.
On appelle la classe dont on tire les précisions la superclasse et les autres classes les sous-classes.
C’est une relation de type « est un (is a) » ou « est une
sorte de ».
La notation utilisée pour la généralisation est le triangle
150
héritage
 généraliser = mettre en facteur des classes  « super-classe »
 spécialiser = décrire de nouveaux détails
 « sous-classes »
 comparable à une association de type « est un, is a, kind of »
 une sous-classe hérite des attributs et opérations de sa super-classe
(classe mère)
151
héritage
La classe spécialisée (sous-classe)
 hérite les méthodes et les attributs de la classe générale
(super-classe)
 peut ajouter ses propres attributs et méthodes.
 peut redéfinir le comportement d’une méthode.
152
héritage
Compte
- Solde
: float
+
Déposer (float Somme) : void
+
Retirer (float Somme) : float
+
AvoirSolde ()
: String
CompteEpargne
- Taux : float
+ AvoirSolde () : String
153
héritage
Remarques
 La généralisation et la spécialisation sont deux façons
pour voir la même relation, top-down (spécialisation) ou
bottom-up (généralisation).
 L'héritage est l’implémentation de la relation de la
généralisation/spécialisation.
 Une classe peut hériter de plusieurs classes, on parle
alors d’un héritage multiple.
154
héritage
Personnes
- Code : int
- Nom : String
+ <<Constructor>> Personnes (int Code, String Nom)
+
getNom ()
: String
+
getInf ()
: String
Spécialisation
Super classe, classe mère
Généralisation
Etudiants
- Salaire : float
+ <<Constructor>> Etudiants (int Code, String Nom, float Salaire)
+
getInf ()
: String
+
getSalaire ()
: float
Sous classes
Classes filles
Classes dérivées
155
Employes
- Filiere : String
+ <<Constructor>> Employes (int Code, String Nom, String Filiere)
+
getInf ()
: String
+ Conception des systèmes
getFiliere ()
: String
d’information
Généralisation / Spécialisation
 une classe peut hériter de plusieurs super-classes
= héritage multiple
156
Généralisation / Spécialisation
 polymorphisme = opérations de même nom, polymorphisme
= comportement spécifique
157
Contraintes sur les associations




Concepts avancés des associations
Permettent d’imposer des règles à respecter lors du
passage à l’implémentation
Il est possible d’attribuer toutes sortes de contraintes à
une association
Les contraintes sont représentées entre accolades et
peuvent être exprimées dans n’importe quel langage
158
Les contraintes (prédéfinies) souvent utilisées :





159
{ordonné}
{sous ensemble}
{xor}
{addOnly}
{frozen}
contrainte {ordonné}
Indique que les objets seront ordonnés à chaque opération
de création, modification, suppression, …
Personne
1
0..*
{Ordonné}
Les comptes d’une personne sont ordonnés
160
Compte
contrainte {sous-ensemble}


Indique qu’une collection est incluse dans une autre
Nécessite la présence d’au moins deux relations
Ecole
Parent d’élève
1..*
{sous-ensemble}
Personnes
Délégué
1..*
Les personnes qui jouent le rôle de délégué font partie des personnes
qui jouent le rôle de parents d’élèves
161
contrainte {xor}
Indique que parmi un groupe d’associations, une seule est
valide à la fois
Batterie
1
PC Portable
1
{xor}
1
Un PC Portable est alimenté soit à partir
d’une batterie, soit à partir d’un secteur
1
162
Secteur
contrainte {addOnly}
La contrainte prédéfinie {addOnly} autorise l’ajout de
nouveaux objets, mais pas leur suppression ni leur mise
à jour.
Personne
1..*
Liste
1
1
0..*
{addOnly}
Enfants
163
contrainte {frozen}
La contrainte prédéfinie {frozen} interdit l’ajout, la
suppression ou la mise à jour des liens d’un objet vers
les objets de la classe associée, après l’initialisation du
premier.
Personne
{frozen}
2
parent
164
0..*
enfant
Exercices
Modéliser sous forme de diagrammes de classes :
1.
Le président d’un comité doit être membre du comité
2.
Une personne qui soumet un article à un journal ne
peut pas évaluer son propre article
165
Exercices
Modéliser sous forme de diagrammes de classes :
1.
Un véhicule est composé d’au moins 2 roues. Le
nombre de roues d’un véhicule ne peut pas varier
2.
Les employés de l’hôtel n’ont pas le droit de prendre
une chambre dans le même hôtel.
166
Exercices
Une personne
 Est née dans un pays (ce pays ne peut être modifié)
 A visité un certain nombre de pays, dans un ordre donné,
et que le nombre de pays visités ne peut que croître
 Aimerait encore visiter toute une liste de pays, et que
cette liste est ordonnée.
167
Exemple de diagramme de classes
(Distributeur Automatique de Banque : DAB)
168
Diagramme d’objets


Représente les objets (instances de classes) et les liens
(instances de relations) à un instant donné
Peut être utilisé pour :




169
Illustrer le modèle de classes en montrant un exemple qui
explique le modèle
Préciser certains aspects du système
Exprimer une exception en modélisant des cas particuliers
Etc.

Le nom d’un objet est souligné



170
Nom : Classe
Nom
:Classe
Exemple :
 Une entreprise emploie au moins deux personnes
 Une personne travaille dans au plus deux entreprises
171
Exemple
Entreprise
:Entreprise
e1:Entreprise
0..2
2..*
Personne
:Personne
172
p1:Personne
p2:Personne
p3:Personne
p4:Personne
Etapes pour établir un diagramme de
classes
A partir d’une description du système :
1. Identifier un premier ensemble de classes candidates
2. Identifier les associations et les attributs
3. Identifier les généralisations
4. Lister les traitements, choisir les opérations
5. Vérifier le modèle obtenu
a.
Supprimer les transitivités
b.
S’assurer que le schéma répond à la demande
6. Itérer jusqu’à satisfaction …
173
UML
Diagrammes de cas d'utilisation
Diagramme des cas d’utilisation


Décrit, sous forme d’actions et de réactions, le
comportement d’un système du point de vue d’un
utilisateur.
Permet de définir les limites du système et ses relations
avec l’environnement.
175
Diagramme de cas d'utilisation



Sert à modéliser les aspects dynamiques d'un système
(Contrairement aux diagrammes de classes).
Fait ressortir les acteurs et les fonctions offertes par le
système.
Utilisé pour modéliser les exigences (besoins) du client
176
Diagrammes des cas d'utilisation
Comportent plusieurs éléments :
 Acteurs
 Cas d'utilisation
 Relations de dépendances, de généralisations et
d'associations
177
Acteurs



UML n’emploi pas le terme d’utilisateur mais d’acteur.
Le terme acteur ne désigne pas seulement des utilisateurs
humains mais également les autres systèmes (machines,
programmes, …)
Un acteur est un rôle joué par une entité externe qui agit
sur le système (Comptabilité, service commercial, …), en
échangeant de l’information (en entrée et en sortie)
178
Acteurs
Remarques
 La même personne physique peut jouer le rôle de
plusieurs acteurs (Chef d’agence est un client de la
banque).
 D’autres part, plusieurs personnes peuvent jouer le
même rôle, et donc agir comme un même acteur
(plusieurs personnes peuvent jouer le rôle
d’administrateur).
179
Acteurs
Peut être représenté de deux manières différentes :

Petit personnage (stick man)

Classe stéréotypée
Nom Acteur
<<Acteur>>
Nom Acteur
180
Acteurs
Les acteurs peuvent être de trois types :
 Humains : utilisateurs du logiciel à travers son interface
graphique, par exemple.
 Logiciels : disponibles qui communiquent avec le système
grâce à une interface logicielle (API, ODBC, …)
 Matériels : exploitant les données du système ou qui sont
pilotés par le système (Imprimante, robots, automates, …)
181
Acteurs
<<acteur>>
Site Web de l'établissement
Secrétaire
Système de Gestion
Scolaire
Etudiant
<<acteur>>
Imprimante
182
Acteurs
Mais du point de vue système on distingue deux types :
 Acteurs principaux : utilisent les fonctions principales du
système. Par exemple, le client pour un distributeur de
billets.
 Acteurs secondaires : effectuent des tâches
administratives ou de maintenance. Par exemple, la
personne qui recharge la caisse contenue dans le
distributeur.
183
Acteurs
Un acteur peut être une spécialisation
d'un autre acteur déjà défini.
Acteur général
Dans ce cas, on utilise la relation de
généralisation/spécialisation.
Acteur spécialisé
184
Cas d'utilisation



Introduit par Ivar Jacobson en 1992 dans sa méthode
Object-Oriented Software Engineering (OOSE).
Technique de description du système étudié privilégiant le
point de vue de l'utilisateur.
Repris par UML dans la but de :


185
Effectuer une bonne délimitation du système
Améliorer la compréhension de son fonctionnement interne
Cas d'utilisation
Les cas d’utilisations
 Permettent de modéliser les attentes (besoins) des
utilisateurs
 Représentent les fonctionnalités du système
 Suite d’événements, initiée par des acteurs, qui
correspond à une utilisation particulière du système
 L’image d’une fonctionnalité du système, déclenchée en
réponse à la stimulation d’un acteur externe.
186
Cas d'utilisation
Un cas d'utilisation est représenté par une ellipse en trait
plein, contenant son nom.
Nom Cas Utilisation
187
Structuration des cas d'utilisation
Après avoir identifié les acteurs et les cas d'utilisation, il est
utile de restructurer l'ensemble des cas d'utilisation que
l'on a fait apparaître afin de rechercher les :



188
Comportements partagés
Cas particuliers, exceptions, variantes
Généralisations/spécialisations.
Structuration des cas d'utilisation
UML définit trois types de relations standardisées entre cas
d'utilisation :
 Une relation d'inclusion, formalisée par la dépendance
«include»
 Une relation d'extension, formalisée par la dépendance
«extend»
 Une relation de généralisation/spécialisation
189
Relation d'inclusion
Lors de la description des cas d'utilisation, il apparaît qu'il
existe des sous-ensembles communs à plusieurs cas
d'utilisation, il convient donc de factoriser ces
fonctionnalités en créant de nouveaux cas d'utilisation qui
sont utilisés par les cas d'utilisation qui les avaient en
commun.
190


A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de factoriser
des fonctionnalités partagées
Le cas d'utilisation pointé par la flèche (dans notre cas B)
est une sous partie de l'autre cas d'utilisation (A, dans
notre exemple).
B
<<include>>
A
191
Retirer de l'argent
<<include>>
Les cas d'utilisation "Déposer de
l'argent", "Retirer de l'argent",
"Effectuer des virements" et "Consulter
solde" incorporent de façon explicite le
cas d'utilisation "S'authentifier", à un
endroit spécifié dans leurs
enchaînements.
Déposer de l'argent
<<include>>
S'authentifier
<<include>>
Effectuer des virements
<<include>>
Consulter solde
192
On utilise cette relation pour éviter de décrire plusieurs
fois un même enchaînement d'actions. Ainsi, on est amené
à factoriser un comportement commun à plusieurs cas
d'utilisation dans un cas d'utilisation à part.
193
Remarques
 La relation include n’a pour seul objectif que de factoriser
une partie de la description d’un cas d’utilisation qui
serait commune à d’autres cas d’utilisation.
 Le cas d’utilisation inclus dans les autres cas d’utilisation
n’est pas à proprement parlé un vrai cas d’utilisation car il
n’a pas d’acteur déclencheur ou receveur d’évènement. Il
est juste un artifice pour faire de la réutilisation d’une
portion de texte.
194
Résumé
 Une instance du cas source inclut obligatoirement le
comportement décrit par le cas d’utilisation destination
 Permet de décomposer des comportements et de définir
les comportements partagées entre plusieurs cas
d’utilisation
▬► Factoriser
195
Relation d'extension
La relation stéréotypée «extend» permet d'étendre les
interactions et donc les fonctions décrites dans les cas
d'utilisation, mais sous certaines contraintes.
196


Le CU source (B) ajoute, sous certaines conditions, son
comportement au CU destination (A)
En d’autres termes, le CU B peut être appelé au cours de
l’exécution du CU A
A
B

<<extend>>
Point d'insertion
Le comportement ajouté s’insère au niveau d’un point
d’extension définit dans le CU destination
197


Le cas d'utilisation de destination peut fonctionner tout
seul, mais il peut également être complété par un autre
cas d'utilisation, sous certaines conditions.
On utilise principalement cette relation pour séparer le
comportement optionnel (les variantes) du
comportement obligatoire.
198
Exemple :
Au moment de l'authentification, il se peut que le guichet
retient la carte.
S'authentifier
Retenir la carte
199
<<extend>>
Relations d’inclusion VS d'extension


La relation « extend" montre une possibilité d'exécution
d'interactions qui augmenteront les fonctionnalités du cas
étendu, mais de façon optionnelle, non obligatoire,
La relation "include" suppose une obligation d'exécution
des interactions dans le cas de base.
200
Relation d'héritage


Il peut également exister une relation d'héritage entre cas
d'utilisation.
Cette relation exprime une relation de
spécialisation/généralisation au sens classique.
201
Relation d'héritage : Exemple
Dans un système d'agence de voyage, un acteur
"Touriste" peut participer à un cas d'utilisation de
base qui est "Réserver voyage", qui suppose par
exemple, des interactions basiques au comptoir de
l'agence. Une réservation peut être réalisée par
téléphone ou par Internet.
202



On voit qu'il ne s'agit pas d'une relation "extend", car la
réservation par Internet n'étend pas les interactions ni les
fonctionnalités du cas d'utilisation "Réserver voyage".
Les deux cas d'utilisation "Réservation voyage" et "Réserver
voyage par Internet" sont liés : la réservation par Internet
est un cas particulier de réservation.
De façon générale en objet, une situation de cas particulier
se traduit par une relation de généralisation/spécialisation.
203
Reserver voyage
Réserver voyage par téléphone
204
Réserver voyage par Internet
Structuration entre cas d’utilisation
Résumé
Les cas peuvent être structurées par des relations :
 A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de factoriser
des fonctionnalités partagées
 A étend B : le cas A est une extension optionnelle du cas
B à un certain point de son exécution.
 A généralise B : le cas B est un cas particulier du cas A.
205
Relations entre cas d’utilisation :
Exemple
Un client peut effectuer un virement bancaire. Le retrait
peut être effectué sur place ou par Internet. Le client
doit être identifié (en fournissant son code d’accès)
pour effectuer un virement, mais si le montant dépasse
500DT, la vérification du solde de son compte est
réalisée.
206
Relations entre cas d’utilisation
Virement
<<extend>>
Vérification solde compte
Montant > 500 DH
<<include>>
Virement par Internet
Virement sur place
Identification
Client distant
207
Client local
Conception
des systèmes d’information
Description des cas d’utilisation



Le diagramme de cas d’utilisation décrit les grandes
fonctions d’un système du point de vue des acteurs.
Mais il n’expose pas de façon détaillée le dialogue entre
les acteurs et les cas d’utilisation.
 nécessité de décrire ce dialogue
208
Deux façons sont couramment utilisées pour décrire les cas
d’utilisation :
 Description textuelle
 Description à l’aide d’un diagramme de séquence (voir
chapitre suivant)
209
(description textuelle)

Identification



210
Nom du cas : retrait d’argent
Objectif : détaille les étapes permettant à un guichetier
d’effectuer des opérations de retrait par un client
Acteurs : Guichetier (Principal), Système central (Secondaire)
Scénarios


1.
2.
3.
4.
5.
6.
7.
211
Scénario nominal
Le Guichetier saisit le numéro de compte client
L’application valide le compte auprès du SC
L’application demande le type d’opération au Guichetier
Le Guichetier sélectionne un retrait de 200 DT
Le système interroge le SC pour s’assurer que le compte est
suffisamment approvisionné.
Le SC effectue le débit du compte
Le système notifie au guichetier qu’il peut délivrer le montant
demandé
Scénarios


1.
212
Scénario alternatif (exception)
En (5) : si le compte n’est pas suffisamment approvisionné
….
(description par diagramme de séquence)
S ys tè m e
G u i c h e ti e r
S a is ie d u n u m é r o d e c o m p te c lie n t
S ys tè m e C e n tra l
D e m a n d e d e v a lid ité d e c o m p te
OK
V é r fific a tio n
D e m a n d e ty p e o p é r a tio n
R e tr a it(s o m m e )
C o m p te s u ffis a m m e n t a p p r o v io s io n n é
C o m p te d é b ité
A u to r is a tio n d e d é liv r e r s o m m e
213
D é b ite r le c o m p te
Intérêts des cas d’utilisation
Les CU obligent les utilisateurs à :
 Définir la manière dont ils voudraient interagir avec le
système
 Préciser quelles informations ils entendent échanger avec
le système
 Décrire ce qui doit être fait pour obtenir le résultat
escompté
214
Diagramme des cas d'utilisation


Le diagramme des cas d'utilisation regroupe dans un
même schéma les acteurs et les cas d'utilisation en les
reliant par des relations. Le système étant délimité par un
cadre rectangulaire.
La représentation de base d'un cas d'utilisation est une
ellipse contenant le nom du cas. L'interaction entre un
acteur et un cas d'utilisation se représente comme une
association. Elle peut comporter des multiplicités comme
toute association entre classes.
215
Diagramme des cas d'utilisation
Déposer de l 'argent
Reteni r l a carte
Cl i ent
<<i ncl ude>>
Reti rer de l 'argent
<<extend>>
<<i ncl ude>>
Consul ter l e sol de
<<i ncl ude>>
S'authenti fi er
<<i ncl ude>>
Effectuer des vi rements entre comptes
Fourni r un l ogi n et un mot
de passe
Agent
Ravi tai l l er
T echni ci en
Réparer
216
Étapes de construction du diagramme des
cas d'utilisation
Pour modéliser le diagramme des cas d'utilisation, il faut :
 Identifier les acteurs qui entourent le système. Certains acteurs
utilisent le système pour accomplir des tâches (acteurs principaux),
d'autres effectuent des tâches de maintenance ou d'administration
(acteurs secondaires).
 Organiser les acteurs selon une hiérarchisation de
généralisation/spécialisation
 Intégrer les acteurs au diagramme en spécifiant les cas d'utilisation
auxquels ils se rapportent
 Structurer les cas d'utilisation pour faire apparaître les comportement
partagés (relation d'inclusion), les cas particuliers
(généralisation/spécialisation) ou options (relation d'extension)
217
UML
Diagrammes de séquences
Diagramme de séquences




Représenter les interactions entre objets en précisant la
chronologie des échanges de messages
Représente une instance d’un cas d’utilisation (les
scénarios possible d’un cas d’utilisation donné)
Montre sous forme de scénarios, la chronologie des
envoies de messages issus d’un cas d’utilisation
Le diagramme de séquence fait ressortir :



219
Les acteurs
Les objets
Les messages
O b j e t_ 1
O b j e t_ 2
O b j e t_ 3
M e ssa g e _ 1
M e ssa g e _ 2
L ig n e d e vie d e
l 'o b j e t
220



Un objet est représenté par un rectangle et une ligne
verticale (ligne de vie de l’objet)
Les objets communiquent en échangeant des messages
représentés par des flèches orientées de l’émetteur au
récepteur
L’ordonnancement vertical des messages indique la
chronologie
221


Un message reçu par un objet déclenche l’exécution d’un
opération
Un message envoyé par objet correspond :


222
Demander un service d’un autre objet
Renvoyer le résultat d’un opération
Diagramme de séquences : Exemple
Compte
- Solde
: float
+ <<Constructor>> Compte (int n, float s)
déposer (float somme) : void
+
retirer (float somme) : float
+
: float
consulter ()
+
Le client demande un service (déposer de l’argent) à l’objet Compte
Le compte reçoit le message et déclenche l’opération de même nom
Le compte retourne le résultat (le solde actuel)
223
Plusieurs concepts additionnels :
 Période d’activité
 Types de messages
 Création et destruction d’objets
 Structures de contrôles
224
Période d’activité


Correspond au temps pendant lequel un objet fait une
action
Représentée par une bande rectangulaire superposée à la
ligne de vie de l’objet
Objet_2
Objet_1
Message_1
225
Messages



Traduisent les interactions (échange d’informations) entre
objets
Représentés par des flèches orientées de l’émetteur au
récepteur
Plusieurs types :





226
Message simple
Message minuté (Timeout)
Message synchrone
Message asynchrone
Message récursif
Message simple
Message pour lequel on ne spécifie aucune information
d’envoi ou de réception
Objet_1
Objet_2
Message_1
227
Message minuté (Timeout)


Bloque l’expéditeur pendant un temps donné, en
attendant la prise en compte du message par le récepteur
Après le délai, l’expéditeur est libéré et peut envoyer
O b j e t_ 2
O b j e t_ 1
M e ssa g e _ 1 (2 0 se c o n d e s)
228
Message minuté (Timeout) : Exemple
La porte d’un ascenseur s’ouvre pendant un certain délai
avant d’être refermée.
Ascenseur
Porte
ouvrir (2 secondes)
fermer
229
Message synchrone (appel de
procédure)


Bloque l’expéditeur jusqu’à la prise en compte du
message par le récepteur
Le contrôle est passé de l’émetteur au récepteur qui
devient à son tour émetteur (actif)
O b j e t_ 2
O b j e t_ 1
M e ssa g e _ 1
230
Message synchrone (appel de
procédure) : Exemple
Communication client serveur : Sockets
Client
Serveur
Sollitation
Acceptation
Requête
Réponse
231
Message asynchrone


N’interrompt pas l’exécution de l’expéditeur
L’expéditeur peut émettre sans attendre la réponse du
récepteur
O b j e t_ 2
O b j e t_ 1
M e ssa g e _ 1
232
Message récursif


Appelé aussi message réflexif
Message envoyé d’un objet vers lui-même.
Objet_1
Message_1
233
Message récursif : Exemple
Lorsque le client introduit sa carte de guichet, ce dernier
vérifie la validité de la carte avant de demander le code
d’accès
Client
GAB
Introduire carte
Vérification validité
Demande code accès
234
Création et destruction d’objets
Un message peut créer ou détruire un objet
Objet_1
Objet_3
Message_1
Création d’objet
Objet_2
Message_2
Objet créé au cours de l’exécution du scénario
Destruction d’objet
Objet détruit dans un scénario
235
Traduction des messages


Envoyer un message c’est demander un service d’un autre
objet (sauf le cas d’un message de retour).
Les messages sont traduits par des opérations dans la
classe de l’objet ayant reçu le message
236
Traduction des messages
class Voiture{
Public void demarrer(){}
}
class Conducteur{
private Voiture voiture;
public void conduire(){
voiture.demarrer();
}
}
… main(String[] arg){
conducteur.conduire();
}
237
Structures de contrôle
Le diagramme de séquences peut inclure un certain nombre
de structures
 Branchements (tests)
 Répétitions (itérations, boucles)
238
Les test (branchements)
La condition précédée le message et elle est délimitée par
des crochets
Objet_1
Objet_2
[condition]: Message
239
Objet_3
Les test (branchements) : Exemple
Pour accéder au centre de recherche, l’utilisateur doit
présenter son badge. S’il a droit d’accès, un voyant
vert est allumé et la porte s’ouvre
Utilisteur
Système
Présente son badge
Vérifier droit d'accès
[OK]voyant vert
ouvrir porte
240
Les boucles (répétitions)
La boucle se note comme le test, mais la condition est
précédée d’un astérisque
Objet_1
Objet_2
* [condition]: Message
241
Objet_3
Fragments



Permet de décomposer une interaction complexe en
fragments simples
Représenté par un rectangle dont le coin supérieur
gauche contient un pentagone
Dans le pentagone figure le type du fragment




242
loop : boucle
alt : alternative
ref : référence
…
Fragments
Tant que x>0 faire
Si x>0 alors
Si x<0 alors
243
UML
Diagrammes de collaboration
Diagramme de collaboration


Représente les interactions entre objets et relations
structurelles permettant celles-ci.
Permettent la description:




Du comportement collectif d’un ensemble d’objets
Des connexions entre ces objets
Des messages échangés par les objets
Interaction réalisée par un groupe d’objets qui
collaborent en échangeant des messages
245


Représentation graphique de l’évolution d’un ensemble
d’objets pour effectuer une action
Différences avec diagrammes de séquence


246
pas d’axe temporel
temps modélisé par numérotation
Éléments d’une interaction
 Instances



liens



qui collaborent avec d'autres objets en échangeant des
informations
:Classe
Objet:Classe
Représentés par
qui sont des supports de messages
Représentés comme des associations
messages


247
déclenchant les opérations
Indiqués par des flèches

Exemple : Appel téléphonique
:Appelant
248
1. Décrocher
:Ligne
2. Tonalité
3. Numérotation
4.1a. Tonalité sonnerie
6.1a. Arrêt tonalité
4.1b. Sonnerie
5. Décrocher
6.1b. Arrêt sonnerie
:Appelé

Aspect temporel


modélisé par numérotation des messages
Type et Sémantique des numérotations

1, 2, 3, 4 : Numérotation simple


1, 1.1, 1.2, 1.2.1, 1.2.2, 1.2.3 : Dot notation


séquencement + un point : ne peut être terminé que si ses sous
points le sont aussi
1, 1.1a, 1.1b, 1.2, 1.3 : Dot notation + concurrence

249
séquencement des messages
idem dot notation, mais les points 1.1a et 1.1b peuvent être effectués
en parallèle

Mêmes types de contraintes que pour les diagrammes de
séquence



Itération : *[condition]
Conditions : [condition]
Exemple : réservation d’articles
1. commander(n, item)
:Client
:Vendeur
4. livrer(n, item)
250
2. vérifier(n, item)
:Stock
3. [disponible]réserver(n, item)



Les objets crées ou détruits au cours d’une interaction
peuvent respectivement porter les contraintes :
{Nouveau}
{Détruit}
251
<<{Détruit}>>
<<{Nouveau}>>
Objet_1
Objet_2
Conclusion
 Représentation spatiale



Aspect temporel plus difficile à suivre que pour les Diagrammes
de séquence
Durée d’exécution d’une contrainte difficile à évaluer
Diagramme niveau instance

Limite : taille des diagrammes

252
Plus d’instances peuvent être représentées sur un même diagramme
que pour les diagrammes de séquence
Exemple : Ascenseur (Séquence)
253
Exemple : Ascenseur (Collaboration)
254
UML
Diagramme état-transition
Le diagramme état-transition :
 Fait partie des modèles dynamiques
 Décrit l'enchaînement de tous les états d'un objet
 Propre à une classe donnée. Il décrit :



256
Les états des objets de cette classe
Les événements auxquels ils réagissent
Les transitions qu'ils effectuent
Le diagramme état-transition manipule plusieurs concepts :
 État
 Transition
 Événement
 Garde
 …
257
État



L'état d'un objet est défini par l'ensemble des valeurs de
ses attributs (fenêtre affichée, fenêtre cachée, …)
Un état dépend de l'état précédent et de l'événement
survenu
Un état est représenté par un rectangle aux coins
arrondis
Fenêtre
- ID
: int
- Visible : boolean
258
Affichée
= True
Transition



C'est le passage d'un état à un autre
Peut être nommé par un événement
Représenté par une flèche orientée de l'état source vers
l'état cible
Restaurée
Réduire
Réduite
259
Événement




Fait (externe) survenu qui déclenche une transition
(changement d'états)
Peut être réflexif et conduire au même état
Conduit à l'appel d'une méthode de la classe de l'objet
Peut posséder des attributs :


260
paramètres portés par des événements
Représentés entre parenthèses
Exemple
Soit le diagramme d’états/transitions de l’objet ‘Fenêtre’
261
Gardiens



Conditions ou fonctions booléennes associées à une
transition
Une transition gardée ne peut être effectuée que si le
gardien est vérifié
Un gardien est représenté entre crochets
Etat1
262
Evénement [Condition]
Etat2
Formalisme et exemple
Etat1
Employé recruté
263
Evénement [Condition]
Prise fonction [Date embauche échue]
Etat2
Employé en activité
Actions et activités


Un objet qui reçoit un événement déclenche une ou
plusieurs opérations
On distingue deux types d'opérations :


264
Action : associée à un état ou à une transition
Activité : associée à un état
Activité



Opération d'une certaine durée, qui est exécutée tant
que l’objet se trouve dans l’état
Associée à un état d'un objet
Représentée dans l'état précédée par la notation "do/"
265
Action



Opération instantanée non interrompue
Peut être associée aussi bien à l'état d'un objet qu'a une
transition
Elle peut intervenir soit

En entrée de l'état (préfixe : "entry/")
En sortie de l'état (préfixe : "exit/")
En réponse à un événement (préfixe :"evt/")
Au cours d'une transition (préfixe : "evt/")
266



Formalisme et exemple
Etat 2
Etat_1
entry / Action_1
do / Action_2
Evénement() / Action_3
exit / Action_4
Evénement [Cond]/ Action
entry / Act1
do / Act2
Evénement() / Act3
exit / Act4
Embauché
entry / Signer contrat
do / Assurer fonction
Arrivée proposition() / Réponde à la proposition
Mutation() / Changer d'affectation
exit / Rompre contrat de travail
267
Exercice
Modéliser l’état de saisie d’un mot de passe :
 Au début, la zone de saisie est masquée
 À chaque saisie d’un caractère, il est stocké
 La touche F1 permet d’afficher l’aide
 Le bouton Annuler permet de fermer la fenêtre
 À la fin de la saisie (validation) le mot de passe est testé
(valide ou invalide)
268
État initial et états finaux
Un diagramme état-transition


Débute toujours par un état initial
Se termine par un ou plusieurs états finaux (sauf où le
diagramme représente une boucle)
Etat_1
Etat_2
269
Exemple (Feu de signalisation)
Feu
- ID
: int
- Couleur : {Vert, Orange, Rouge}
Orange
Vert
Rouge
270
Point de décision


Permettent de représenter des partages de transitions ou
des alternatives pour le franchissement d’une transition
On utilise deux mécanismes :


271
Points de jonction (petit cercle plein) : pour partager des
segments de transition
Points de choix (losange) : pour choisir une ou une autre
transition
Point de jonction
272
Points de choix
273
État composite



Un état composite (#état simple) est décomposé en deux
ou plusieurs sous états
Cette décomposition est récursive
Un état composite est représenté comme un état simple,
sauf que les sous états sont contenus dans le
compartiment inférieur.
274
Exemple
275
Historique



On représente le pseudo état historique par un H cerclé
Une transition ayant pour cible l’état historique est
équivalente à une transition ayant pour cible le dernier
état visité dans la région contenant le H
H* (historique profond) est un état valable pour tous les
niveaux
276
Concurrences

Pour représenter la concurrences dans un diagramme
d’états/transitions, on utilise :


277
États concurrents
Transitions concurrentes
États concurrents



État composite pour représenter l’exécution de plusieurs
automates s’exécutant indépendamment
On utilise un séparateur en pointillés
L’objet peut être simultanément dans plusieurs états
concurrents
278
États concurrents
279




Deux transitions particulières : fork et join
La transition fork correspond à la création de deux états
concurrents
La transition join permet de supprimer la concurrences
(barre de synchronisation)
Pour pouvoir franchir la barre de synchronisation, toutes
les tâches concurrentes doivent être achevées
280
281
UML
Diagramme d'activités
Introduction


Variante des diagrammes d'état-transition
Permet de décrire le flot de contrôle entre les opérations
:






Choix
Séquences
Itérations
Parallélisme
Au niveau macroscopique : décrit les enchaînements des
opérations
Au niveau microscopique : décrit l'algorithme d'une action
du diagramme d'états
283
Concepts de base
Plusieurs concepts sont manipulés :
 État
 Activité
 Transition (séquentielle, alternatives ou conditionnelle)
 Synchronisation (disjonction et conjonctions d’activités)
 Itération
 Swimlanes
284
Comportement conditionnel


Appelé aussi le branchement
Symbolise une transition entrante gardée par une
condition et plusieurs transitions sortantes mutuellement
exclusives
285
Comportement conditionnel :
Exemple
Demander l'addition
[Prix<=Somme disponible]
Régler la note
286
[Else]
Faire la vaisselle
Synchronisation


Fusion (conjonction) : plusieurs transitions entrantes et
une seule sortante
Comportement parallèle :



287
La barre de synchronisation permet d'ouvrir et de fermer les
branches parallèles au sein d'un flot d'exécution
Les transitions partantes d'une barre ont lieu en même temps
La barre n'est franchie qu'après réalisation de toutes les
transitions qui s'y rattachent
Synchronisation : Exemple
Déserrer le frein à main
Barre de synchronisation
Fusion (conjonction)
Appuyer sur l'embrayage
Enclencher la 1ère vitesse
Comportement parallèle
Disjonction
Relâcher l'embrayage
288
Itération : Exemple
Re ce vo ir co m m a n d e
V é ri f i e r a rt i c l e
C o m m a n d e r a rt i c l e
[ s'i l re st e d e s a rt i c l e s]
[ p l u s d 'a rt i c l e ]
289
Swimlanes


Extension des diagrammes d'activités permettant de
représenter l'organisation.
Représente le lieu, le responsable des activités.
290
Résumé notation
291
Exemple récapitulatif
292
Exemple récapitulatif
R é c e p ti o n c o m m a n d e
A n n u le r co m m a n d e
V é ri f i e r c a rt e c ré d i t
V é r i f i e r d i sp o n i b i l i t é p r o d u i t
[ E l se ]
[ E l se ]
[ D i sp o n i b l e ]
[V a l i d e ]
P ré p a re r c o m m a n d e
E xp é d ie r co m m a n d e
293
D é b i t e r c a rt e c ré d i t
P o st e r f a c t u r e
Exercice 1
Représenter les états suivants sous forme de diagramme
d'activité :
 Vérification commande
 Enregistrement commande
 Rejet commande
 Informer erreur au client
294
Exercice 1 : solution
Vérifier commande
Valide
[oui]
Enregistrement commande
[non]
Rejet commande
Informer erreur au client
295
Exercice 2
Dans le domaine de gestion de stock, on considère les états
suivants indiquant le flot de contrôle de réception d'une
livraison :
Réception livraison, contrôle qualité, contrôle quantité et
enregistrement livraison.
Proposez un diagramme d'activité représentant ce flot
d'information
296
297
Exercice 3
Construire un diagramme d’activité pour modéliser le
processus de commande d’un produit. Le processus
concerne les acteurs suivants:
 Comptable : enregistrement commande, envoi de la
facture et enregistrement paiement du client
 Client : paiement de la facture
298
299
Exercice 4
Construire un diagramme d’activité pour modéliser le
processus de commande d’un produit. Le processus
concerne les acteurs suivants:
 Client: qui commande un produit et qui paie la facture
 Caisse: qui encaisse l’argent du client
 Vente: qui s’occupe de traiter et de facturer la
commande du client
 Entrepôt: qui est responsable de sortir les articles et
d’expédier la commande.
300
301
UML
Diagrammes de Composants et de Déploiement
Diagrammes de Composants/
Déploiement
Permettent de modéliser les aspects physiques d’un
système orienté-objet
 Diagramme de Composants : se focalise sur
l’organisation et les dépendances entre un
ensemble de composants
 Diagrammes de Déploiement : se focalise sur la
configuration en temps d'exécution des nœuds de
traitement et de composants qui sont actifs
303
Diagramme de composants


Dans le monde de bâtiment, tout ce qui est proposé par
l’architecte (plan) constitue une vue logique : visualiser,
spécifier, documenter
Lors de la construction, on utilise des composants
physiques du monde réel : murs, fenêtres, portes, …
304


De même, tout ce que nous avons vu jusqu’à présent
constitue le modèle logique : visualiser, spécifier et
documenter la structure et le comportement des objets
La construction va s’appuyer sur les composants du
monde réel de l’ordinateur : fichiers, tables, librairies, …
305



Permet de décrire l'architecture physique et statique d'une application
en terme de composants :
 code source,
 bibliothèques,
 exécutables,
Il montre la mise en oeuvre physique des modèles de la vue logique
dans l'environnement de développement
Permet de spécifier :
 Composants
 Interfaces
 Relations (dépendance, généralisation, association, réalisation).
306
Composant


Un composant est une partie physique et remplaçable
d’un système qui sait faire et fournit la réalisation d’un
ensemble d’interface
Les composants peuvent être organisés en paquetages
307
Composant
Nom du composant
Component1

Nom du composant :
 Permet de distinguer un composant des autres composants
 Il peut être un nom simple ou un nom composé qui indique le paquetage auquel
appartient le composant

Stéréotypes : spécifient un composant qui désigne:
 « executable »: un programme pouvant s’exécuter sur un nœud
 « library » : une bibliothèque statique ou dynamique
 « table »: une table de base de données
 « file » : un fichier contenant du code source ou des données
 « document » : un document
308
Concepts

Interface :


Est une collection d’opérations utilisées pour spécifier les
services d’une classe ou d’un composant
Relations avec les interfaces

Réalisation :



Dépendance :


309
Définie entre l’interface et le composant qui fournit les services
pour les autres composants
Cette interface est appelée « interface exportée »
Définie entre l’interface et le composant qui utilise les services
fournis par un autre composant
Cette interface est appelée « interface importée ».
Interface
Component1
Component2
Interface1
dépendance
réalisation
« Interface »
Interface1
Component1
Attributs
Opérations
310
Component2
Relations entre les composants

Dépendance :


Cela signifie qu’un des éléments d’un composant a besoin des
services que les élément de l’autre composant réalisent
Notation UML
Component1
311
Component2
Relations entre les composants

Contenance :


Un composant peut être contenu dans un autre composant
Notation UML
Component 1
Component 2
312
Système Vente
(diagramme de classes)
enregistre
Ligne de vente
SpécificationProduit
*
1
-Description : string
-Prix : real
+getDescritption(In Item:undefined):string
+getPrix(In Item:undefined):real
-quantité : integer
+setQuantité(In quantité:integer)
1..*
*
contenu dans
Contient
1
Vente
-Date : undefined
-Heure : undefined
+initierPaiement(In montant:real)
1
1..*
Magasin
+nom : string
+adresse : string
utilise
1
Catalogue
1
+ObtenirSpec(In Item:undefined):SpécificationProduit
est payée par
1
Paiement
-montant : real
-mode : string
313
(Exemple)

Système Vente
<<executable>>
IHM_Caisier
<<interface>>
InterfaceProduit
InterfacePaiement
<<library>>
JavaSwing
<<executable>>
Enregistrement-Produits
<<executable>>
GestionPaiement
InterfaceAutorisation
InterfaceImpôts
<<executable>>
Gestion d'autorisation
Gestion d'Impôts
InterfaceCatalogue
<<utility>>
CatalogueProduits
314
Diagramme de déploiement



Montre la configuration des nœuds de exécution et des
composants qu’y résident
Montre les relations physiques entre les composants
logiciels et matériels d’un système
Permet de spécifier


315
Nœuds
Relations : (dépendance, associations)
Nœud




Est un élément physique qui existe pendant l’exécution
et représente une ressource informatique dans la
plupart de cas il s’agit d’un élément matériel
En général un nœud possède sa propre mémoire et une
capacité de traitement
L’ensemble de composants qui est associé aux nœuds
est appelé « unité de répartition »
Les nœuds prennent en charge l’exécution des
composants.
316
Nœud
Nom du nœud

Nœud 1
Nom du nœud :
Permet de distinguer un nœud des autres nœuds
 Le nom peut être composé du nom de paquetage qui contient le
nœud
Stéréotypes : un nœud peut posséder un stéréotype qui permet de le
distinguer des autres types de ressources (permettant de spécifier le types
de ressources)





317
« CPU » : une unité de calcul
« memory » : une unité de stockage
« device »: un dispositif tel qu’un capteur
Relations entre nœuds et composants
Dépendance :
 Montre la capacité d’un nœud de supporter un composant
 Peut être également exprimée entre les composants résidant dans
un même nœud
 Notation UML

Nœud 1
Client
IHM
Composant1
318
Composant 2
Relations entre deux nœuds

Association


Indiquent une voie physique entre deux nœuds
Exemple:



Une connexion Ethernet
Un bus de communication
Notation UML
TCP / IP
1
Nœud 1
319
1..*
Nœud 2
(Exemple)

Système Vente
Serveur de Calcul
InterfaceAutorisation
<<executable>>
<<executable>>
Enregistrement-Produits
InterfaceImpôts
<<executable>>
Gestion d'Impôts
GestionPaiement
Gestion d'autorisation
InterfacePaiement
1
1
LAN
1
LAN
Serveur de Données
Ventes
<<executable>>
InterfaceCatalogue
1..*
IHM_Caisier
<<utility>>
CatalogueProduits
320
<<library>>
JavaSwing
Serveur
Base <<utility>>
de Données
Base de
Données
Ordonnanceur
interface
TCP / IP
1
1..*
Client
IHM
321
322
Correspondance UML et Java
Traduction d’une classe



La classe est le concept fondamental de toute technologie
objet.
Le mot-clé correspondant existe bien sûr également en
Java.
De plus, chaque classe UML devient par défaut un fichier
.java.
324
class Personne{
Personne
325
…
…
….
}


Une classe abstraite est simplement une classe qui ne
s’instancie pas directement mais qui représente une pure
abstraction afin de factoriser des propriétés.
Elle se note avec {abstract} en UML et se traduit par le
mot-clé abstract en Java.
326
abstract class Personne{
Personne
{abstract}
327
….
….
….
}



Une interface est une classe spéciale dont toutes les
méthodes sont abstraites
Une interface se note en UML avec le symbole
En java, elle traduite par le mot clé ‘interface’
328
interface Forme {
Forme
329
…
…
…
}
Traduction des attributs




Les attributs UML deviennent simplement des attributs
en Java
Leur type est soit un type primitif (int, etc.), soit une
classe.
La visibilité des attributs est montrée graphiquement en
UML en les faisant précéder par + pour public, # pour
protégé (protected), - pour privé (private).
Les attributs de classe en UML deviennent des membres
statiques en Java (static).
330
Traduction des opérations




Les opérations UML deviennent très directement des
méthodes en Java.
Leur visibilité est définie graphiquement avec les mêmes
conventions que les attributs.
Les opérations de classe deviennent des méthodes
statiques (static).
Les opérations abstraites (en italiques) se traduisent par le
mot-clé abstract en Java.
331
Traduction des opérations
class Personne {
private int code;
private String nom;
private static int nombre;
public Personne() {
}
public static int getNombre(){
}
public String getInf(){
}
}
332
Traduction des relations
Les relations UML entre concepts statiques sont très riches.
On peut distinguer les relations de :
 Généralisation (héritage)
 Réalisation
 Association, avec ses variantes : agrégation et
composition.
333
(La généralisation)


Le concept UML de généralisation se traduit directement
par le mécanisme de l’héritage dans les langages objets.
Java, contrairement à C++ interdit l’héritage multiple
entre classes.
334
(La généralisation)
Class Personne{
…
…
…
Personne
Employe
}
Class Employe extends
Personne{
…
…
…
}
335
(La réalisation )


Une classe UML peut implémenter plusieurs interfaces.
Contrairement à C++, le langage Java propose
directement ce mécanisme.
336
(Réalisation)
interface A{
…
…
A
B
}
interface B{
…
…
}
class C implements A, B {
C
…
…
}
337
(Les associations)

Les associations navigables UML se traduisent par du
code Java qui dépend de :



la multiplicité de l’extrémité concernée (pointée par la flèche)
mais aussi de l’existence ou pas d’une contrainte {ordered} ou
d’un qualificatif.
Nous allons voir tout cela du plus simple au plus
complexe :


338
Une association navigable avec une multiplicité 1
Une association navigable avec une multiplicité *
(Les associations)


Une association navigable avec une multiplicité 1 se
traduit par une variable d’instance de type référence vers
une instance de classe.
Une multiplicité « * » va se traduire par un attribut de
type collection de références d’objets au lieu d’une simple
référence sur un objet.
339
(Les associations)
La difficulté consiste à choisir la bonne collection parmi les
très nombreuses classes de base que propose Java.
 Bien qu’il soit possible de créer des tableaux d’objets, ce
n’est pas forcément la bonne solution.
 En pratique, on préfère plutôt recourir à des collections,
parmi lesquelles les plus utilisées sont : ArrayList, SortedList
et HashTable.


340
Utilisez ArrayList si vous devez respecter un ordre et récupérer
les objets à partir d’un indice entier
Utilisez HashTable si vous souhaitez récupérer les objets à partir
d’une clé arbitraire.
(Les associations)
341
(Les associations)


Une association bidirectionnelle se traduit simplement
par une paire de références, une dans chaque classe
impliquée dans l’association.
Les noms des rôles aux extrémités d’une association
servent à nommer les variables de type référence.
342
(Les associations)
343
(Les associations)
344
(La classe association)


Elle possède tout à la fois les caractéristiques d’une
association et d’une classe et peut donc porter des
attributs qui se valorisent pour chaque lien.
Ce concept UML avancé n’existe pas dans les langages de
programmation objet, il faut donc le traduire en le
transformant en classe normale, et en ajoutant des
variables de type référence.
345
(La classe association)
346
UML
De UML vers le modèle relationnel
De UML vers le modèle relationnel


Cette partie traite le passage de la conception faite par
UML vers le modèle relationnel
La traduction concerne


Classes, instances, attributs
Relations entres classes :




348
Associations,
Agrégation,
Composition,
Généralisation spécialisation
348
Classe en Relationnel



Dans le cas général une classe est traduite par une table
Chaque objet est conservé dans une ligne de la table
Un champ jouant le rôle de clé primaire est ajouté même
s'il n'existait pas dans la classe
349
349
Traduction d'une classe

En Relationnel
Compte(NCompte, Solde)

En SQL
Create table Compte(
Compte
- N°Compte : int
- Solde
: float
NCompte smallint,
+ <<Constructor>>
+
Solde decimal,
+
+
Primary key PK_Compte (NCompte)
Compte (int N°Compte, float Solde)
deposer (float Solde)
: void
retirer (float Solde)
: float
avoirSolde ()
: String
)
350
350
Généralisation/spécialisation en
Relationnel
Plusieurs méthodes de traduction en Relationnel :
 Représenter toutes les classes d’une arborescence
d’héritage par une seule table relationnelle
 Représenter chaque classe par une table
351
351
Relationnel



La solution la plus simple est de modéliser toute une
hiérarchie de classes dans une même table
Chaque classe ajoutant ses propres attributs comme de
nouveaux champs.
Il nous suffit alors d’ajouter un champ contenant le type
de l’instance pour pouvoir charger les champs
correspondants.
352
352
Relationnel
353
353
Associations en Relationnel
(Association un-à-un)
Deux solutions sont possibles :
 une clé étrangère dans chacune des tables associées
 la fusion des deux tables dans une seule
354
354

1ère Solution



Pays(IdPays, NomP,#IdCapitale)
Capitales(IdCapitale, NomC, #IdPays)
2ième Solution

355
Pays(IdPays, NomP, NomC)
355
1ère Solution

create table Pays(IdPays integer primary key,
…
IdCapitale integer foreign key references capitales (IdCapitale))
et
create table Capitales(IdCapitale integer primary key,
…,
IdPays integer foreign key refernces pays(IdPays))

2ième Solution
Pays(IdPays integer primary key,
NomP varchar(20),
NomC varchar(20))
356
356
(Association un-à-plusieurs)
Une seule solution est possible :
 migration de la clé du côté de 1 vers la table du côté de
plusieurs
 La clé migrée jouera le rôle de clé étrangère
357
357
(Association un-à-plusieurs)

En Relationnel



Dept(IdDept, Nomdept)
Emp(IdEmp, NomEmp, #IdDept)
En SQL


Create table dept(…)
Create table emp(IdEmp integer primary key,
NomEmp varchar(20),
IdDept integer foreign key references Dept(IdDept)
)
358
358
(Association plusieurs-à-plusieurs)


L’association est traduite par une table dont la clé
primaire est la concaténation des clés primaires des
tables associées
La table résultante aura :


359
Une seule clé primaire
Deux clés étrangères
359
Traduction des associations en Relationnel
En Relationnel
 Articles(Ref, Des, PU)
 Commandes(NBC, DateC, Client)
 Détails(#NBC, #Ref, Qté)
360
360
Traduction des associations en Relationnel
En SQL
1. create table Article(Ref integer primary key, …)
2. create table Cde(NBC integer primary key, …)
3. create table Detail(NBC integer, Ref integer,…,
constraint PK primary key(NBC, Ref),
constraint FK1 foreign key(NBC) references cdes(NBC),
Constraint FK1 foreign key(NBC) references cdes(NBC))
361
361
OCL
Contraintes



Une contrainte est une condition ou une restriction
sémantique exprimée sous forme d’instructions dans un
langage textuel qui peut être naturel ou formel
Elle doit être appliquée lors de l’implémentation
Représentée sous forme d’une chaîne placée entre
accolades({})
363
Contraintes

Nous avons vu comment exprimer certaines contraintes
avec UML





364
{ordered}
{subset}
{frozen}
{xor}
…
Contraintes – Exemple 
Dans cet exemple, on exprime le fait qu’un ‘solde’ doit
rester toujours positif (utilisation d’un langage formel).
365
Contraintes – Exemple 
Dans cet exemple, on exprime un contrainte avec un
langage textuel non formel
366
Introduction


OCL est un langage de contraintes associé à UML
Il peut être utilisé pour contraindre n’importe quel
diagramme
367
Contexte



Une contrainte est toujours associée à un élément du
modèle
Cet élément constitue le contexte de la contrainte
Deux manières pour exprimer le contexte d’une
contrainte :


368
En écrivant la contrainte entre {} dans une note (voir exemple
précédent)
En utilisant le mot clé ‘context’ dans un document accompagnant
le modèle
Contexte

Syntaxe
context <élément>
Où : <élément> : peut être une classe, un attribut, une opération,
etc.

Pour faire référence à un élément d’une classe, il faut
utiliser les ‘::’
369
Contexte



Le contexte de la classe ‘Compte’
context Compte
Le contexte de l’opération getSolde() de la classe
Compte
context Compte::getSolde():Real
Le contexte de l’opération deposer() de la classe Compte
context Compte::deposer(somme:Real)
370
Invariants



Un invariant exprime une contraintes sur un objet ou un
groupe d’objets qui doit être respectée en permanence
Syntaxe :
inv : <expression_logique>
L’expression logique doit être toujours vraie
371
Invariants
Exemple :
Le solde d’un compte doit être toujours positif

context Compte
inv : solde>0
372
Préconditions et postconditions


Une précondition permet de spécifier une condition qui
doit être vérifiée avant l’appel d’une opération.
Une postcondition permet de spécifier une condition
qui doit être vérifiée après l’appel d’une opération.
373

Dans l’expression de la contrainte de la postcondition,
deux éléments particuliers sont utilisés :


374
result : la valeur retournée par l’opération
<attribut>@pre : la valeur de l’attribut avant l’appel de
l’opération

Syntaxe de la précondition
pre : <expression logique>

Syntaxe de la postcondition
post : <expression logique>
375
Exemples :
context Compte::debiter(somme : Real)
pre : somme>0
post : solde=solde@pre-somme

post : result=solde
376
Résultat d’une opération
L’expression de contrainte ‘body’ permet définir
directement le résultat d’une opération

Syntaxe :
body : <requête>
<requête> : expression qui retourne le résultat dont le type
est compatible avec le type de retour de l’opération

377
Résultat d’une opération
Exemple
La méthode getSolde() de la classe ‘Compte’ retourne le
solde actuel

body : solde
378
Définition des attributs et de
méthodes

Motivation :


une sous expression peut être utilisée plusieurs fois dans une
expression
Deux expressions de contraintes :


379
let : permet de déclarer et d’initialiser un attribut qui peut être
utilisé dans l’expression qui suit le mot clé in
def : fait la même chose que let.
méthodes

Syntaxes :
let <déclaration>=<requête> in <expression>
L’attribut déclaré recevra le résultat de la <requête>
dans toute l’<expression>
def : <déclaration>=<requête>
380
méthodes

1.
2.
3.
381
Exemples
context Personne
inv : let argent=compte.solde->sum() in
age>=18 implies argent>0
context Personne
def : argent : Real = compte.solde->sum()
context Personne
inv : age>=18 implies argent>0
Initialisation et évolution des
attributs



Le type de contrainte init permet de préciser la valeur
initiale d’un attribut ou d’une terminaison d’association
La valeur d’un attribut dérivé est définie par la contrainte
derive.
Syntaxes :
init : <requête>
derive : <requête>
382
Initialisation et évolution des
attributs
Exemple
Quand on crée une personne, la valeur initiale de l’attribut
marié est faux, et la personne ne possède pas
d’employeur.
context Personne::marié:Boolean
init : false
context Personne::employeur:Set(Société)
init : set{}

383
Initialisation et évolution des attributs
Exemple
 L’âge d’une personne est la différence entre la date
courante et la date de naissance de la personne.
context Personne::age:Integer
derive : Date::current() – date_de_naissance

384
Types et opération OCL
Le langage OCL possède un certain nombre de types
prédéfinis et d’opérations prédéfinies sur ces types :




385
Boolean
Integer
Real
String
Type
opérateurs
Boolean And, or, xor, not, implies, if…then…else…endif
Integer
+,-, *, /, abs(), …
Real
+,-, *, /, abs(), floor(), …
String
Concat(), size(), substring(), …
386
a
b
a and b
a or b
a xor b
a implies b
V
V
V
V
F
V
V
F
F
V
V
F
F
V
F
V
V
V
F
F
F
F
F
V
387
not
If <exp_log0>
Then <exp_log1>
V
F
Else <exp_log2>
F
388
V
Endif
Collections

Le langage OCL manipule plusieurs collections :




389
Set : collection non ordonnée d’éléments uniques
orderedSet : collection ordonnée d’éléments uniques
Bag : collection non ordonnée d’éléments
Sequence : collection ordonnée d’éléments
Collections
Collection
Éléments ordonnées Éléments uniques
Set
Non
Oui
OrderedSet Oui
Oui
Bag
Non
Non
Sequence
Oui
Non
390
Quelques opérations sur les collections
- Opération de base 









La syntaxe : collection->operation()
size() : nombre d’éléments
count() : nombre d’occurrences
sum() : somme des éléments
isEmpty() : est vide
notEmpty() : non vide
includes(el) : appartenance
excludes(el) : non appartenance
includesAll(col) : inclusion
excludesAll(col) : exclusion
391
Quelques opérations sur les collections
- Filtrage 





select(cond) : retient les éléments qui vérifient la condition
reject(cond) : élimine les éléments qui vérifient la condition
any(cond) : retourne l’un des éléments qui vérifie la condition
forAll(cond) : true si tous les éléments vérifient la condition
exists(cond) : true si au moins un élément vérifie la condition
isUnique(exp) : true si une et une seule valeur de la collection
qui vérifie la condition
392
Opération ensembliste
- Set ou OrederedSet 



union(ens) : union
- : différence (ens1 – ens2)
including(el) : ajoute un élément
excluding(el) : retire un élément
393
Accès aux données de l’objet courant
Pour faire référence à une donnée (attribut ou
opération) d’un objet désigné par le contexte :

1.
2.
394
Utiliser le nom de l’élément
Faire précéder le nom de l’élément du mot clé ‘self’
Accès aux données de l’objet courant
Exemple
 Dans le contexte de la classe ‘Compte’ :
Context Compte
Inv : solde > 0

Context Compte::debiter(somme : Real)
Pre : somme > 0
Post : self.solde = self.solde@pre - somme
395
Navigation à travers une association

Pour faire référence à un objet (ou un groupe d’objets)
associé via une association, On utilise :


396
Le nom de la classe associée en minuscule
Le nom du rôle côté de la classe associée

Dans le contexte de la classe ‘Personne’, on fait référence
à la classe société avec l’une des deux méthodes :



employeur
société
De même pour accéder à l’adresse de la société :


397
employeur.adresse
société.adresse
L’utilisation du rôle est indispensable si :
1.
2.
398
Il existe plusieurs associations entre l’objet désigné par le
contexte et l’objet auquel on désire accéder
L’association est réflexive

Le type du résultat dépend de :



la multiplicité de l’objet référencé
type de l’objet référence proprement dit.
Si l’objet référencé est T, alors le résultat est de type :



399
T, si la multiplicité est 0..1 ou 1..1
Set(T), si la multiplicité est *
OrderedSet(T), si la multiplicité est * avec {ordered}

Exemple : Type du résultat
400
qualifiée
Dans une association qualifiée, on utilise les valeurs (les
instances) des qualificatifs entre crochets ([])
context Banque
inv : self.compte[8900].solde>0

401
Navigation vers une classe association


Dans le contexte de Société, self.poste.salaire:
salaire de tous les employés
Dans le contexte de Personne,
self.mariage[epouse].date : dates de mariages des
femmes
402
Navigation depuis une classe
association
context Poste
inv : self.employe.age>21
(ou aussi, self.personne.age>21)
403
Accès à une méthode redéfinie


Une sous classe peut redéfinir une méthode de sa classe
mère
L’accès à la méthode de la classe parente est toujours
possible et se fait par : oclAsType()
404
Accès à une méthode redéfinie
Dans le contexte de B :
 Self.f() : accès à f() de B
 Self.oclAsType(f()) : accès à la
méthode de A
405
Les méthodes agiles
Agile



Approche réactive et itérative d’organisation de travail
Focalisée sur la fonctionnalité et satisfaction client
Construit en adéquation avec les capacités et limites
humaines
407
Pourquoi Agile ?

En réaction des problèmes avec des approches
‘traditionnelles’ :
Besoins
Spécifications
Conception
Code
Test
408
Les constats

Les meilleures idées ne viennent pas forcément au début
du projet




Il est plus facile de construire par étape que tout imaginer dès
le début
Les besoins peuvent évoluer pendent le projet
Le formalisme n’est pas naturel
Chiffrages et Reste à Faire sont difficiles à évaluer
409
Un projet informatique … la réalité

On ne sait pas estimer la charge restante
100%
% Complété
T
410
Problèmes avec cascade

Les méthodes prédictives fonctionnent bien, à condition
d’avoir:



Stabilité et prévisibilité
Communication et compréhension parfaite
Choix parfaits dès le départ

411
Aucun humain!
Agile : un juste milieu
Très réactive
Peu focalisé, aucune maitrise
Réactivité
Peu réactive
Focalisation
Objectifs clairs
Méthodes
prédictives
Absence de
méthode
412
Agile : une catégorie de méthodes

‘Agile’ regroupe plusieurs méthodologies :






Scrum
Extreme Programming (XP)
DSDM
Crystal
…
Notion officialisée en 2001 avec le Manifeste Agile
413
Le manifeste Agile
Personnes et interactions
Plutôt que
Processus et outils
Un produit opérationnel
Documentation
exhaustive
Collaboration
avec le client
Négociation d'un contrat
Adaptation au
changement
Suivi d'un plan
414
Agile : Libérer le génie Humain
Pour l’auto-organisation dans un contexte qu’il peut maîtriser :


La taille de l’équipe est limitée
le domaine du problème est limité
Petites équipes autogérées
 Portée fonctionnelle restreinte à un moment donné
 Garder un rythme de travail soutenable
 Avancement par itération

415
Méthodes Agiles
Expression des besoins
Conception
Développement
Tests, recette & debugage
416
Les solutions Agiles
i1
417
i2
i3
in

Toujours focalisées sur le produit final



Découper le projet autrement


Une vision commune pour l’équipe
La satisfaction du client
par fonctionnalité
Organiser en cycles de développement réduits

418
itérations

Collaboration avec le client

Pourquoi on veut des contrats ?

Instaurer la confiance autrement

Eviter les effets pervers d’un contrat
419



Adaptables
Réactives aux nouveaux besoins
Réceptives aux nouvelles solutions

Prendre les décisions définitives le plus tard possible

De courtes itérations permettent de changer de direction sans
laisser des éléments à moitié fait
420
Agile : Planification

L’estimation de charge est difficile, mais les courtes
itérations nous aident



421
On est plus précis sur les petites tâches
Feedback très rapide
Plus facile à s’adapter face aux dérives, surprises
Exemple de méthode agile
SCRUM
Introduction à Scrum





Source : http://commons.wikimedia.org
Scrum = mêlée en rugby
Objectifs :
 Satisfaire au mieux les besoins du
client
 Maximiser les chances de réussite du
projet
Méthode itérative et incrémentielle
Equipes de 8 personnes. Mécanismes
d’extension
Méthode agile la plus utilisée avec
eXtreme Programming
1986 : « The new new product development game »
 2001 : K. Schwaber et M. Beedle publient « Agile software development with Scrum ».

423
Rappel sur les méthodes agiles (% Scrum)
Manifeste de l’agilité publié en 2001
4 valeurs :


1.
2.
3.
4.
424
Les personnes et les interactions plutôt que
les outils et les processus
Le logiciel fonctionnel plutôt que
de la documentation exhaustive
La collaboration avec le client plutôt que
la négociation de contrat
L’adaptation au changement plutôt que
le respect d’un plan pré-établi
Scrum – Principes clés


Conforme au manifeste de l’agilité
Met l’accent sur :







425
Auto-organisation de l’équipe
Pouvoir de décision donné à l’équipe
Délais fixes
Sprint en isolement
Réunions quotidiennes
Livrer un logiciel fonctionnel - démonstration du résultat du
sprint
Planning adaptatif
Scrum – Les rôles


Les poules et les cochons
Les cochons :




Les poules :


Le product owner
Le scrummaster
L’équipe
Tous ceux qui ont un intérêt dans le projet
Certifications
426
Scrum – Planifier un projet
Source : http://fr.wikipedia.org


Constitution du backlog produit par le product owner.
Répartition en sprints et en releases.
427
Scrum – Organisation 1/5
Source : www.scrumalliance.org
1. Backlog produit (ou catalogue des besoins)

Besoins priorisés par le product owner

Besoins évalués par l’équipe
428
2. Backlog de sprint
 Extrait du backlog produit
 Besoins éclatés en tâches
429
3. Sprint
 Développement des fonctionnalités du backlog de sprint
 Aucune modification du backlog de sprint possible
430
4. Mêlée quotidienne
 Point de contrôle quotidien de l’équipe
 Interventions régulées – 2 min. par personne
431
5. Incrément logiciel : livré au product owner à la
fin du sprint.
432
Scrum – Indicateurs de projet 1/2

Le tableau des tâches
Source : « Scrum and XP from the trenches » de H. Kniberg, 2007
433
Scrum – Indicateurs de projet 2/2

Le burndown chart
Source : « Summary of Scrum », Signifikant Svenska A.B., 2007
434
Scrum – Ingénierie logicielle



Scrum est une méthode de gestion de projet
Doit être complétée par des techniques d’ingénierie
logicielle
Complémentaire avec eXtreme Programming :


435
Test Driven Development
Intégration continue
Scrum – Equipes plus grandes
Principes :

1.
2.
Commencer par une équipe Scrum standard
Création de plusieurs équipes – essaimage
Adaptation de la méthode :



Scrum des scrums
Rôle de team lead
Problèmes à traiter :



436
Dispersion géographique
Développement off-shore
Les outils



Outils traditionnels
 Tableau blanc et post-its
 Excel – Backlog produit et backlog de sprint
Outils dédiés
 Outils commerciaux / Open source
 Gèrent une charge de travail
 Absence de PERT / Gantt
 Intégration avec : IDE, contrôle de sources, gestion des tests, bug
tracking, intégration continue.
Autres outils
 Connexion large bande
 Wiki, webcams, messagerie instantanée…
437
Perspectives


Pas d’évolution, peu de critiques
Défauts à palier
Absence de dépendance entre les tâches
 Polyvalence des programmeurs
 Productivité équivalente supposée
 Grande maturité nécessaire



Contrats à adapter
Stratégie d’introduction de Scrum en entreprise
438
Conclusion






Méthode de gestion de projet – développement
logiciel
A compléter avec des techniques d’ingénierie
logicielle
Rien de totalement nouveau
Méthode à la mode. Conditions propices nécessaires
Expérimentations prometteuses
Principal bénéfice : des équipes motivées
439
Exemple de méthode agile
Extreme Programming
Extreme Programming : Caractéristiques


Méthodologie de développement basée sur des valeurs,
principes et pratiques
Propose des pratiques d’ingénierie comme le binomage et
TDD.
441
Extreme Programming : Caractéristiques


Méthodologie de développement basée sur des valeurs,
principes et pratiques
Propose des pratiques d’ingénierie comme le binomage et
TDD.
442
Extreme Programming : Valeurs

Communication




Entre les membres de l’équipe
Verbale
Facilité par colocalisation de l’équipe
Simplicité

Cherche la solution la plus simple qui convient au problème du
jour.

443
Le refactoring n’est pas un échec, mais une étape normale !

Feedback


Des tests unitaires, fonctionnels
Du client


De l’équipe

444
Revue avec le client toutes les deux à trois semaines
Grace à la communication continuelle

Courage




De s’attaquer aux problèmes tout de suite
D’appliquer les valeurs XP
De jeter du code lorsque nécessaire
Respect

445
Tous les membres de l’équipe apportent quelque chose, peu
importe leurs années d’expérience
Extreme Programming : Pratiques

Pair programming




Partage des idées, bonnes pratiques
Partage des expériences
Partage des compétences
Le code appartient à tout le monde


446
Règles de codage
Utilisation de patterns, métaphores
Extreme Programming : Pratiques

Tests




Unitaires
Intégration continue
Test-driven development
Conception incrémentale
447
Bibliographie

Ce cours a été inspiré de :





448
François Potentier, « Scrum, Etat de l’art », Présentation, 2008
Arnaud Pasquiers & Chris Ozanne, « Découvrir l’agilité » Agile Tour, Rennes, 2011
Omar El Beqqali, « Unified Modeling Language – Modélisation
Objet », support de cours, EMSI, 2009-2010
« Merise – UML », Support de cours de l’Université de Pise,
2008
Abdellah Madani, « UML : Unified Modeling Language », Support
de cours, Université Nancy 2, 2007

Conception des systèmes d`information

Transcription

Documents pareils

Exemples de diagrammes SysML sur un portail automatique

Formation UML complète Plan de cours

UML-2-par-la-pratique-etude-de-cas-et-exercices

uml 2 analyse et conception

1. Diagramme de cas d`utilisation

conception d`une base de données relationnelle appliquée à la

Analyse et conception avec UML 2.0 - EGILIA

P50 Maquettage d`un outil pédagogique pour une méthode de

2. UML - membres