Conception Sysinfo

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.
 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
2 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
 Cycle de vie d’un logiciel
 Historique d’UML
 Diagrammes UML
 Diagrammes de classes et d’objets
 Diagrammes des cas d’utilisation
 Autres Diagrammes
Plan
 Méthodes agiles
 Introduction
 Concept
 Quelques méthodes agiles
 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
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
 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)

 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)

 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.
Vue d’ensemble de la démarche
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

 La démarche
 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
 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).

 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.

Niveau Données Traitements Choix pris en compte
Modèle Conceptuel des
Modèle Conceptuel des Données
Traitements
(MCD)
(MCD) Choix de gestion
Conceptuel Signification des informations
Activite du domaine sans Quoi ?
sans contrainte technique ou
préciser les ressources ou leur
économique
organisation
Modèle Organisationnel des

Modèle Organisationnel des
Données
Traitements
(MOD) Choix d'organisation
Organisationnel (MOT)
Signification des informations avec Qui ?, Ou ?, Quand ?
Fonctionnement du domaine
contrainte organisationnelles et
avec les ressources utilisées
économique
Modèle Physique des Données Modèle Physique des

(MPD) Traitements
Choix technique
Physique Description de la ou des bases de (MPT)
Comment ?
données dans la syntaxe du Architecture technique des
logiciel SGF ou SGBD programmes

 Objectifs de cette décomposition
 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
 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.

 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.
 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.

 Cycle de décision
 Fixation de jalon de validation
 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.
 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
 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
 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 :
 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.

 Les étapes du MCD
 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é
 Représentation d'un objet réel, ayant une existence et
une raison d'être dans le système d'information.

 Entité
 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
 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é
 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)
 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)
 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
 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.
a Société
Employé
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é.
compose Produit
Commande
1,n 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 0,n
parle
1,n
0,n
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 A UT E UR
é cri t 0 ,n
0 ,n
0 ,n
0 ,n
1 ,n
ve n d é d i te sto cke
q u a n ti té E n ti e r q u a n ti té E n ti e r q u a n ti té E n ti e r
0 ,n
0 ,n
0 ,n L IB RA IRIE
E DIT E UR

 Cas des associations de dimension 1 (réflexives)
 Cas des associations de dimension 3

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 :
 Soit au niveau des évènements déclenchant
 Soit au niveau des résultats

 Les étapes du MCT
 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 :
 É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 DEVIS
Elaboration du devis Elaboration du devis
Elaboration de la Demande de prêt DEVIS

proposition
ET
PROPOSITION
Elaboration de la
proposition
DEVIS


 Les relations entre « acteurs » peuvent être traduites soit par
un « graphe des flux » soit par une « matrice des flux ».
CLIENT BANQUE BDF DGI
Demande du
CLIENT
client
Déclaration
Demande de
BANQUE Accord ou Refus ouverture de
renseignements
compte
BDF Réponse BDF
DGI
MATRICE DES FLUX

 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".

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?
 Analyse des postes de travail.
 Partage des traitements entre l’homme et la machine.
 Type d’individu qui réalisera les traitements.
 Quand?
 Influence du temps et comment structurer les traitements en
conséquence.
 Où?
 Comment les traitements sont-ils organisés dans l’espace ?

Traitements)
 Le M.O.T se concentre sur le COMMENT
 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
 Il s’agit ici de
 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
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 :
 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

Traitements)
 Construction du M.O.T
 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

Traitements)
Il est possible de représenter le temps sous forme d’une colonne

comme un acteur
Temps Poste 1 Poste 2 Poste 3 Partenaire
T0
TO + 10 jours

Traitements)

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).
 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).









UML
Cycle de vie d’un logiciel
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.

69
Étapes nécessaires à la réalisation d’un logiciel:

 Analyse
 Conception
 Codage (Implémentation)
 Tests
 Livraison
 Maintenance

Modèle en Cascade (WaterFall)
70
Analyse
Conception
Implémentation
Tests
Maintenance

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)

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.

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
 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

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

76
Spécification technique :(Étude de l’existant)

 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 :
 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 :
 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 :
 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 :
 É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)

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:
 Langages classiques (C, Pascal, Fortran, …)
 Langages orientés objets (C++, Java, C#, …)

Codage et Tests
83
On distingue plusieurs types de tests :

 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 :
 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 :
 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) :
 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

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.

Historique
Deux approches
 Approche fonctionnelle
 1960 – fin 1970
 l'important c'est les traitements
 Séparation nette des données et traitements
 Approche objet
 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 :
 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

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

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 :
 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
 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 :
 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.

Diagrammes d'UML
UML comprend 9 diagrammes :
Diagramme
Est sorte de
CasCasd d’utilisation
’utilisation Classes
Classes États
EtatsTransitions
Transitions Séquence
Séquence
Collaboration Composants Déploiement 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

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

Diagramme d’UML
Cas d’utilisation
Objets Composants
Classes Vue logique statique Vue Implémentation

(Structure des objets) (composants logiciels)
Vue externe
(fonctions système)
Séquence Vue déploiement
Vue logique dynamique
(Environnement
(Comportement)
d’implantation)
Collaboration
Activités
États transitions 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 :
 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
 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
 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

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)

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 :
 - 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 = 10
- Longueur : float
- /Surface : float

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
 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 : Rectangle = (100,100)
- visibilité : boolean = true Attributs d'instances
- taille_defaut : Rectangle
- taille_max : Rectangle Attributs de classes
+ <<Constructor>> Window ()
+ afficher () : void
+ cacher () : void Opérations d'instances
+ getTaille_max () : Rectangle
+ getTaille_defaut () : Rectangle 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é ».

Une méthode est

 l’implémentation d’un service offert par la classe
(opération).
 de différents types :
 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
 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
- Solde : float
- Client : Personne
+ <<Constructor>> Compte ()
+ Deposer (float somme) : void
+ Retirer (float somme) : float
+ AvoirSolde () : String

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.

Classe représentée par un rectangle à trois parties :
 Partie 1 : Nom de la classe
 Partie 2 : Attributs (propriétés, champs)
 Partie 3 : Méthodes (fonctions, opérations)

Compte
- Solde : float = 100
# Client : Personne
+ Deposer (float somme) : void
+ Retirer (float somme) : float

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 Nom de la classe
Attributs Attributs Opérations
Opérations

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.

Encapsulation, visibilité et interface
Données
} •Partie statique, passive
•Partie cachée, privée
Traitement
} •Partie dynamique, comportementale
•Partie visible, publique
•Interface avec l’extérieur
User

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
+ {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

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

Package
 Un package est représenté par un rectangle possédant un
onglet dans lequel est inscrit le nom du package

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.

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’

Associations
 Relation existant entre une, deux ou plusieurs classes.
 Une association porte un nom (signification)
 Représentée par une ligne rectiligne

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

Associations
Nom et sens de lecture
 Décrit la nature (signification) de l’association
 Montre la direction de lecture de l’association

Associations
Rôle d’une association
Décrit le rôle d’une classe dans une association

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
Pilote Personne Personne

Avion 0..4
femme
Passager
0..1
mari

Associations
Classe association
Une association peut avoir des attributs = classe-association

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

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

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

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,
…
…

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

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

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

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)

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.

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 1

Exercice
 Un avion est composé de plusieurs sièges, mais dans une
rangée il y a seulement quatre sièges.

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 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

Agrégation
Titre
0..1 Un agrégat (composé) peut être multiple.
1..1
Destinataire E-Mail Fichier

1..* 0..*
* 0..*
Ici, on exprime qu'un fichier peut être attaché à un email (ou a

1..1 plusieurs, ou même à aucun) et qu'un email peut (ou non)
attacher (contenir une copie) une ou plusieurs fichiers.
0..1
Texte

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).

Composition
 la suppression d’un objet agrégat entraîne la suppression des

objets agrégés

Composition
 Un document est composé de plusieurs paragraphes, qui,
à son tour, est composé de plusieurs phrases
 Remarquer la propagation des opérations (copie,
suppression,…)

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 super-
classe 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

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)

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.

héritage
Compte
- Solde : float
+ Déposer (float Somme) : void
+ Retirer (float Somme) : float
CompteEpargne
- Taux : float

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.

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
Employes
Sous classes - Filiere : String
Classes filles + <<Constructor>> Employes (int Code, String Nom, String Filiere)
Classes dérivées + getInf () : String
155 + Conception des systèmes d’information
getFiliere () : String
Généralisation / Spécialisation
 une classe peut hériter de plusieurs super-classes
= héritage multiple

Généralisation / Spécialisation
 polymorphisme = opérations de même nom, polymorphisme
= comportement spécifique

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

Les contraintes (prédéfinies) souvent utilisées :
 {ordonné}
 {sous ensemble}
 {xor}
 {addOnly}
 {frozen}

contrainte {ordonné}
Indique que les objets seront ordonnés à chaque opération
de création, modification, suppression, …
Personne Compte
1 0..*
{Ordonné}
Les comptes d’une personne sont ordonnés

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 Personnes

1..*
{sous-ensemble}
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

contrainte {xor}
Indique que parmi un groupe d’associations, une seule est
valide à la fois
Batterie
PC Portable 1
{xor}
Un PC Portable est alimenté soit à partir
1 d’une batterie, soit à partir d’un secteur
1 Secteur

contrainte {addOnly}
La contrainte prédéfinie {addOnly} autorise l’ajout de
nouveaux objets, mais pas leur suppression ni leur mise
à jour.
Personne Liste
1..*
1
0..*
{addOnly}
Enfants

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} 0..*
enfant
2
parent

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

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.

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.

Exemple de diagramme de classes
(Distributeur Automatique de Banque : DAB)

Diagramme d’objets
 Représente les objets (instances de classes) et les liens
(instances de relations) à un instant donné
 Peut être utilisé pour :
 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é
 Nom : Classe
 Nom
 :Classe

Exemple :
 Une entreprise emploie au moins deux personnes
 Une personne travaille dans au plus deux entreprises

Exemple
Entreprise
:Entreprise e1:Entreprise
0..2
2..*
Personne
:Personne 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 …

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.

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

Diagrammes des cas d'utilisation
Comportent plusieurs éléments :
 Acteurs
 Cas d'utilisation
 Relations de dépendances, de généralisations et
d'associations

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)

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).

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

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, …)

Acteurs
<<acteur>>
Secrétaire Site Web de l'établissement
Etudiant
Système de Gestion
Scolaire
<<acteur>>
Imprimante

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.

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é

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 :
 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.

Cas d'utilisation
Un cas d'utilisation est représenté par une ellipse en trait
plein, contenant son nom.
Nom Cas Utilisation

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 :
 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

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.

 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).
<<include>>

Les cas d'utilisation "Déposer de
l'argent", "Retirer de l'argent",
"Effectuer des virements" et "Consulter
Retirer de l'argent
solde" incorporent de façon explicite le
cas d'utilisation "S'authentifier", à un
endroit spécifié dans leurs
<<include>> enchaînements.
Déposer de l'argent
<<include>>
S'authentifier
<<include>>
Effectuer des virements
<<include>>
Consulter solde

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.

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.

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

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.

 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 Point d'insertion
<<extend>>
 Le comportement ajouté s’insère au niveau d’un point

d’extension définit dans le CU destination

 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.

Exemple :
Au moment de l'authentification, il se peut que le guichet
retient la carte.
S'authentifier
Retenir la carte
<<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.

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.

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.

 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.

Reserver voyage
Réserver voyage par téléphone 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.

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.

Relations entre cas d’utilisation
<<extend>> Vérification solde compte

Virement
Montant > 500 DH
<<include>>
Virement par Internet
Virement sur place
Identification
Client distant
Client local
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

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)

(description textuelle)
 Identification
 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
 Scénario nominal
1. Le Guichetier saisit le numéro de compte client
2. L’application valide le compte auprès du SC
3. L’application demande le type d’opération au Guichetier
4. Le Guichetier sélectionne un retrait de 200 DT
5. Le système interroge le SC pour s’assurer que le compte est
suffisamment approvisionné.
6. Le SC effectue le débit du compte
7. Le système notifie au guichetier qu’il peut délivrer le montant
demandé

 Scénarios
 Scénario alternatif (exception)
1. 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 ys tè m e C e n tra l
S a is ie d u n u m é r o d e c o m p te c lie n t
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 é
D é b ite r le c o m p te
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

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é

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.

Diagramme des cas d'utilisation
Déposer de l 'argent Reteni r l a carte
Cl i ent
<<i ncl ude>> <<extend>>

Reti rer de l 'argent
<<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
Agent Fourni r un l ogi n et un mot

de passe
Ravi tai l l er
T echni ci en
Réparer

É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)

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 :
 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

 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

 Un message reçu par un objet déclenche l’exécution d’un
opération
 Un message envoyé par objet correspond :
 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
+ consulter () : float
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)

Plusieurs concepts additionnels :
 Période d’activité
 Types de messages
 Création et destruction d’objets
 Structures de contrôles

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

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 :
 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

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)

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

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)
M e ssa g e _ 1

Message synchrone (appel de
procédure) : Exemple
Communication client serveur : Sockets
Client Serveur
Sollitation
Acceptation
Requête
Réponse

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
M e ssa g e _ 1

Message récursif
 Appelé aussi message réflexif
 Message envoyé d’un objet vers lui-même.
Objet_1
Message_1

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

Création et destruction d’objets
Un message peut créer ou détruire un objet
Objet_1 Objet_3
Message_1
Objet_2
Création d’objet
Message_2
Objet créé au cours de l’exécution du scénario Destruction d’objet
Objet détruit dans un scénario

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

Traduction des messages
class Voiture{
Public void demarrer(){}
}
class Conducteur{
private Voiture voiture;
public void conduire(){
voiture.demarrer();
}
}
… main(String[] arg){
conducteur.conduire();
}

Structures de contrôle
Le diagramme de séquences peut inclure un certain nombre
de structures
 Branchements (tests)
 Répétitions (itérations, boucles)

Les test (branchements)
La condition précédée le message et elle est délimitée par
des crochets
Objet_1 Objet_2 Objet_3
[condition]: Message

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

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 Objet_3
* [condition]: Message

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
 loop : boucle
 alt : alternative
 ref : référence
 …

Fragments
Tant que x>0 faire
Si x>0 alors
Si x<0 alors

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

 Représentation graphique de l’évolution d’un ensemble
d’objets pour effectuer une action
 Différences avec diagrammes de séquence
 pas d’axe temporel
 temps modélisé par numérotation

Éléments d’une interaction
 Instances
 qui collaborent avec d'autres objets en échangeant des
informations
:Classe Objet:Classe
 Représentés par
 liens
 qui sont des supports de messages
 Représentés comme des associations
 messages
 déclenchant les opérations
 Indiqués par des flèches

 Exemple : Appel téléphonique
1. Décrocher 4.1b. Sonnerie

:Appelant 2. Tonalité :Ligne 5. Décrocher :Appelé
3. Numérotation 6.1b. Arrêt sonnerie
4.1a. Tonalité sonnerie
6.1a. Arrêt tonalité

 Aspect temporel
 modélisé par numérotation des messages
 Type et Sémantique des numérotations
 1, 2, 3, 4 : Numérotation simple
 séquencement des messages
 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
 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) 2. vérifier(n, item)

:Client :Vendeur :Stock
4. livrer(n, item) 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}
<<{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
 Plus d’instances peuvent être représentées sur un même diagramme
que pour les diagrammes de séquence

Exemple : Ascenseur (Séquence)

Exemple : Ascenseur (Collaboration)

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 :
 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
 …

É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
Affichée
- ID : int
- Visible : boolean = 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

É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 :
 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’

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 Etat2
Evénement [Condition]

Formalisme et exemple
Etat1 Etat2
Evénement [Condition]
Employé recruté Employé en activité

Prise fonction [Date embauche échue]

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 :
 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/"

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/")

Formalisme et exemple
Etat 2
Etat_1
entry / Act1
entry / Action_1
do / Act2
do / Action_2
Evénement [Cond]/ Action Evénement() / Act3
Evénement() / Action_3
exit / Act4
exit / Action_4
Embauché
entry / Signer contrat
do / Assurer fonction
Arrivée proposition() / Réponde à la proposition
Mutation() / Changer d'affectation
exit / Rompre contrat de travail

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)

É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

Exemple (Feu de signalisation)
Feu
- ID : int
- Couleur : {Vert, Orange, Rouge}
Orange
Vert
Rouge

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 :
 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

Points de choix

É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.

Exemple

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

Concurrences
 Pour représenter la concurrences dans un diagramme
d’états/transitions, on utilise :
 É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

États concurrents

Transitions concurrentes
 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

Transitions concurrentes

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

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

Comportement conditionnel
 Appelé aussi le branchement
 Symbolise une transition entrante gardée par une
condition et plusieurs transitions sortantes mutuellement
exclusives

Comportement conditionnel :
Exemple
Demander l'addition
[Prix<=Somme disponible] [Else]
Régler la note
Faire la vaisselle

Synchronisation
 Fusion (conjonction) : plusieurs transitions entrantes et
une seule sortante
 Comportement parallèle :
 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

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 ]

Swimlanes
 Extension des diagrammes d'activités permettant de
représenter l'organisation.
 Représente le lieu, le responsable des activités.

Résumé notation

Exemple récapitulatif

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 ]
D é b i t e r c a rt e c ré d i t
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 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

Exercice 1 : solution
Vérifier commande
Valide
[oui] [non]
Enregistrement commande Rejet commande
Informer erreur au client

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


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


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.


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

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, …

 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, …

 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).

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

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

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éfinie entre l’interface et le composant qui fournit les services
pour les autres composants
 Cette interface est appelée « interface exportée »
 Dépendance :
 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 Component2
Opérations

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 Component2

Relations entre les composants
 Contenance :
 Un composant peut être contenu dans un autre composant
 Notation UML
Component 1
Component 2

Système Vente
(diagramme de classes)
enregistre SpécificationProduit
Ligne de vente
* 1 -Description : string
-quantité : integer -Prix : real
+setQuantité(In quantité:integer) +getDescritption(In Item:undefined):string
+getPrix(In Item:undefined):real
1..*
contenu dans *
1 Contient
Vente 1..*
Magasin
-Date : undefined utilise
-Heure : undefined Catalogue
+nom : string
1 1
+initierPaiement(In montant:real) +adresse : string
+ObtenirSpec(In Item:undefined):SpécificationProduit
1
est payée par
1
Paiement
-montant : real
-mode : string

(Exemple)
 Système Vente
<<executable>>
IHM_Caisier
<<interface>>
InterfacePaiement
InterfaceProduit
<<library>>
JavaSwing
<<executable>>
<<executable>> GestionPaiement
Enregistrement-Produits
InterfaceAutorisation InterfaceImpôts
InterfaceCatalogue
<<utility>> <<executable>>
Gestion d'Impôts
CatalogueProduits Gestion d'autorisation

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
 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.

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)
 « 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 Composant 2

Relations entre deux nœuds
 Association
 Indiquent une voie physique entre deux nœuds
 Exemple:
 Une connexion Ethernet TCP / IP
 Un bus de communication 1 1..*
 Notation UML
Nœud 1 Nœud 2

(Exemple)
 Système Vente
Serveur de Calcul
InterfaceAutorisation InterfaceImpôts
<<executable>> <<executable>> <<executable>> Gestion d'Impôts

Enregistrement-Produits Gestion d'autorisation GestionPaiement
InterfacePaiement
1 1
LAN
LAN
1
Serveur de Données Ventes
<<executable>> <<library>>
InterfaceCatalogue 1..* JavaSwing
IHM_Caisier
<<utility>>
CatalogueProduits

Serveur
Base <<utility>>
de Données
Ordonnanceur Base de
Données
interface
1
TCP / IP
1..*
Client
IHM


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.

class Personne{
…
…
….
Personne }

 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.

abstract class Personne{

….
….
Personne ….
{abstract} }

 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’

interface Forme {
…
…
…
Forme
}

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).

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.

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(){
}
}

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.

(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.

(La généralisation)
Class Personne{
Personne …
…
…
}
Class Employe extends
Employe Personne{
…
…
…
}

(La réalisation )
 Une classe UML peut implémenter plusieurs interfaces.
 Contrairement à C++, le langage Java propose
directement ce mécanisme.

(Réalisation)
interface A{
…
…
A B }
interface B{
…
…
}
class C implements A, B {
C
…
…
}

(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 :
 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.

(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.
 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)

(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.

(Les associations)

(Les associations)

(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.

(La classe association)

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 :
 Associations,
 Agrégation,
 Composition,
 Généralisation spécialisation
348 Conception des systèmes d’information 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

Traduction d'une classe
 En Relationnel
Compte(NCompte, Solde)
 En SQL
Compte
Create table Compte( - N°Compte : int
- Solde : float
NCompte smallint,
+ <<Constructor>> Compte (int N°Compte, float Solde)
Solde decimal, + deposer (float Solde) : void
+ retirer (float Solde) : float
Primary key PK_Compte (NCompte)
+ avoirSolde () : String

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

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.

Relationnel

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

 1ère Solution
 Pays(IdPays, NomP,#IdCapitale)
 Capitales(IdCapitale, NomC, #IdPays)
 2ième Solution
 Pays(IdPays, NomP, NomC)

 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))

(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

(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)
)

(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 :
 Une seule clé primaire
 Deux clés étrangères

Traduction des associations en Relationnel
En Relationnel
 Articles(Ref, Des, PU)
 Commandes(NBC, DateC, Client)
 Détails(#NBC, #Ref, Qté)

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))

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({})

Contraintes
 Nous avons vu comment exprimer certaines contraintes
avec UML
 {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).

Contraintes – Exemple -
 Dans cet exemple, on exprime un contrainte avec un
langage textuel non formel

Introduction
 OCL est un langage de contraintes associé à UML
 Il peut être utilisé pour contraindre n’importe quel
diagramme

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 :
 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 ‘::’

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)

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

Invariants
 Exemple :
Le solde d’un compte doit être toujours positif
context Compte
inv : solde>0

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.

 Dans l’expression de la contrainte de la postcondition,
deux éléments particuliers sont utilisés :
 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>

 Exemples :
context Compte::debiter(somme : Real)
pre : somme>0
post : solde=solde@pre-somme
post : result=solde

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

Résultat d’une opération
 Exemple
La méthode getSolde() de la classe ‘Compte’ retourne le
solde actuel
body : solde

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 :
 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>

méthodes
 Exemples
1. context Personne
inv : let argent=compte.solde->sum() in
age>=18 implies argent>0
2. context Personne
def : argent : Real = compte.solde->sum()
3. 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>

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{}

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

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 :
 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(), …

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

not If <exp_log0>
Then <exp_log1>
V F
Else <exp_log2>
Endif
F V

Collections
 Le langage OCL manipule plusieurs collections :
 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

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

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

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

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. Utiliser le nom de l’élément
2. 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

Navigation à travers une association
 Pour faire référence à un objet (ou un groupe d’objets)
associé via une association, On utilise :
 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é :
 employeur.adresse
 société.adresse

L’utilisation du rôle est indispensable si :
1. Il existe plusieurs associations entre l’objet désigné par le
contexte et l’objet auquel on désire accéder
2. 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 :
 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

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

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

Navigation depuis une classe
association
context Poste
inv : self.employe.age>21
(ou aussi, self.personne.age>21)

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()

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

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

Pourquoi Agile ?
 En réaction des problèmes avec des approches
‘traditionnelles’ :
Besoins
Spécifications
Conception
Code
Test

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

Un projet informatique … la réalité
 On ne sait pas estimer la charge restante
100%
% Complété

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
 Aucun humain!

Agile : un juste milieu
Très réactive Réactivité Peu réactive
Peu focalisé, Focalisation Objectifs clairs

aucune maitrise
Absence de Méthodes
méthode prédictives

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

Le manifeste Agile
Personnes et interactions Plutôt que Processus et outils
Documentation
Un produit opérationnel
exhaustive
Collaboration
Négociation d'un contrat
avec le client
Adaptation au
Suivi d'un plan
changement

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

Méthodes Agiles
Expression des besoins
Conception
Développement
Tests, recette & debugage

Les solutions Agiles
i1 i2 i3 in

 Toujours focalisées sur le produit final
 Une vision commune pour l’équipe
 La satisfaction du client
 Découper le projet autrement
 par fonctionnalité
 Organiser en cycles de développement réduits
 itérations

 Collaboration avec le client
 Pourquoi on veut des contrats ?
 Instaurer la confiance autrement
 Eviter les effets pervers d’un contrat

 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

Agile : Planification
 L’estimation de charge est difficile, mais les courtes
itérations nous aident
 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
 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
Source : http://commons.wikimedia.org eXtreme Programming
 1986 : « The new new product development game »

 2001 : K. Schwaber et M. Beedle publient « Agile software development with Scrum ».

Rappel sur les méthodes agiles (% Scrum)
 Manifeste de l’agilité publié en 2001

 4 valeurs :
1. Les personnes et les interactions plutôt que
les outils et les processus
2. Le logiciel fonctionnel plutôt que
de la documentation exhaustive
3. La collaboration avec le client plutôt que
la négociation de contrat
4. 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 :
 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 :
 Le product owner
 Le scrummaster
 L’équipe
 Les poules :
 Tous ceux qui ont un intérêt dans le projet
 Certifications

Scrum – Planifier un projet
Source : http://fr.wikipedia.org
 Constitution du backlog produit par le product owner.

 Répartition en sprints et en releases.

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
2. Backlog de sprint
 Extrait du backlog produit
 Besoins éclatés en tâches

3. Sprint
 Développement des fonctionnalités du backlog de sprint
 Aucune modification du backlog de sprint possible

4. Mêlée quotidienne
 Point de contrôle quotidien de l’équipe
 Interventions régulées – 2 min. par personne

5. Incrément logiciel : livré au product owner à la

fin du sprint.
Scrum – Indicateurs de projet 1/2
 Le tableau des tâches
Source : « Scrum and XP from the trenches » de H. Kniberg, 2007

Scrum – Indicateurs de projet 2/2
 Le burndown chart
Source : « Summary of Scrum », Signifikant Svenska A.B., 2007

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 :
 Test Driven Development
 Intégration continue

Scrum – Equipes plus grandes
 Principes :
1. Commencer par une équipe Scrum standard
2. Création de plusieurs équipes – essaimage
 Adaptation de la méthode :
 Scrum des scrums
 Rôle de team lead
 Problèmes à traiter :
 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…

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

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

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.

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.

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.
 Le refactoring n’est pas un échec, mais une étape normale !

 Feedback
 Des tests unitaires, fonctionnels
 Du client
 Revue avec le client toutes les deux à trois semaines
 De l’équipe
 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
 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
 Règles de codage
 Utilisation de patterns, métaphores

Extreme Programming : Pratiques
 Tests
 Unitaires
 Intégration continue
 Test-driven development
 Conception incrémentale

Bibliographie
 Ce cours a été inspiré de :
 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 Sysinfo

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Conception Sysinfo

Titre original :

Transféré par

Droits d'auteur :

Conception des systèmes

2 Conception des systèmes d’information

4 Conception des systèmes d’information

 Une méthode d’élaboration de logiciels décrit comment

 De manière générale, une méthode définit :

 L'approche systémique (années 80)

 L'émergence des méthodes objet (1990-1995)

 L'unification et la normalisation des méthodes (1995-1997)

 A quoi sert Merise ?

 Pour les traitements : A identifier les fonctionnalités selon une approche

 Merise est un travail d'anticipation : Elle sert à préparer les

 L'approche Merise n'est pas adaptée aux projets très complexes

12 Conception des systèmes d’information

13 Conception des systèmes d’information

 Les deux modèles sont le Modèle conceptuel des données

14 Conception des systèmes d’information

 On tient compte (ou on propose) des choix d’organisation de

 Le modèle de représentation est le modèle organisationnel des

15 Conception des systèmes d’information

Modèle Organisationnel des

Modèle Physique des Données Modèle Physique des

16 Conception des systèmes d’information

17 Conception des systèmes d’information

 Il s’agit de la traduction de la stratégie de l’entreprise.

18 Conception des systèmes d’information

 Ce document doit permettre une première mesure de

19 Conception des systèmes d’information

 La définition du "Qui ?", du "Où ?" et du "Quand ? ».

 Les données sont réajustées et stabilisées, l'essentiel des

21 Conception des systèmes d’information

23 Conception des systèmes d’information

26 Conception des systèmes d’information

 Catalogue des données

27 Conception des systèmes d’information

28 Conception des systèmes d’information

29 Conception des systèmes d’information

30 Conception des systèmes d’information

31 Conception des systèmes d’information

32 Conception des systèmes d’information

33 Conception des systèmes d’information

34 Conception des systèmes d’information

35 Conception des systèmes d’information

36 Conception des systèmes d’information

 Cas des associations de dimension 3

37 Conception des systèmes d’information

 Évènement déclenchant -> Transformation du système

 Implication du monde extérieur au niveau de chaque

39 Conception des systèmes d’information

40 Conception des systèmes d’information

 Il représente généralement un sous ensemble d ’activités de

 Il est en général caractéristique du secteur d ’activité de

Demande Client Demande Client

Elaboration de la Demande de prêt DEVIS

42 Conception des systèmes d’information

43 Conception des systèmes d’information

CLIENT BANQUE BDF DGI

BDF Réponse BDF

MATRICE DES FLUX

44 Conception des systèmes d’information

46 Conception des systèmes d’information

48 Conception des systèmes d’information

 La difficulté réside dans la diversité des solutions

 Le MOT cerne l'activité de chaque poste de travail

 Lieu : qui exécute ? Acteurs.

51 Conception des systèmes d’information