UML dans le projet de

développement logiciel

UML UML

UML
© D. Ribouchon

§1 1

Objectifs du cours:
UML au service du projet

• Savoir mener les différentes activités d'un processus de

développement logiciel avec l'aide d'UML
• Acquérir de bonnes pratiques de conception logicielle

• Savoir utiliser l'abstraction

• Savoir atterrir; l'abstraction au service du concret:
– lier la conception UML et langage de programmation
– décliner sur un type de projet particulier: "Système
d'information" ou "Système embarqué"

• Avoir un premier contact avec un outil de modélisation UML

© D. Ribouchon

§1 2

1
 Les spécificités d'un
"Système d'information"

• Un SI peut être défini comme "un ensemble organisé de

ressources logicielles et matérielles qui permet de collecter,
regrouper, classifier, traiter et diffuser de l'information dans un
environnement donné"

• Le logiciel est la partie prépondérante du système

• Le matériel est du matériel standard

• Il s'intègre dans un environnement métier: une organisation

humaine (e.g. une entreprise)
© D. Ribouchon

§1 3

Plan du cours
Déclinaison SI

• Introduction
• Prise en main: COO UML/POO et processus de développement
• Spécifier les exigences du système
– Comprendre le métier
– Spécifier les exigences
• Concevoir le système
– Définir la plateforme technique Exercices et
– Concevoir le code source étude de cas
– Concevoir les composants déployables
• Pour aller plus loin
© D. Ribouchon

§1 4

2
 Les spécificités d'un
"Système embarqué"

• Un système embarqué est un système composite HW/SW,

embarqué dans un environnement physique

• Exemples: un système embarqué PABX, l'ensemble des

éléments HW et SW d'un système téléphonique

• Les éléments physiques sont généralement passifs,

contrairement aux éléments HW et SW qui ont un
comportement, une "intelligence"

• Le HW est spécifique et ne consiste pas en de simples unités

d'exécution du logiciel
© D. Ribouchon

§1 5

Les spécificités d'un

"Système embarqué" - vision OMG

Les systèmes embarqués sont souvent définis comme des éléments

interconnectés, contenant des parties software et hardware
(principalement de nature électronique), mais qui ne sont pas des
ordinateurs dans le sens classique du terme.
Les systèmes embarqués sont des systèmes informatiques qui sont
déployés dans un environnement (une partie du monde physique)
avec lequel ils interagissent.
Le développement de systèmes embarqués implique de concevoir un
système dans lequel les ressources sont limitées, et qui peut s'exécuter
sans intervention manuelle. C'est pourquoi, toutes les erreurs doivent être
prises en compte par le système lui-même. Comme les ressources sont
limitées (quantité mémoire, puissance consommée, etc.) la conception
des systèmes embarqués demande souvent des optimisations.
Les systèmes embarqués se distinguent en particulier par les
caractéristiques suivantes: hétérogénéité (hardware/software), distribution
( potentiellement sur plusieurs ressources hardware hétérogènes),
© D. Ribouchon

capacité à réagir (supervision, modes d'interfaces utilisateurs), criticité,

§1 temps réel, contraintes de consommation. 6

3
 Plan du cours
Déclinaison système embarqué

• Introduction
• Prise en main: COO UML/POO, processus de développement

• Exigences du système embarqué

• Conception du système embarqué Exercices et

étude de cas

• Conception du logiciel

• Pour aller plus loin

© D. Ribouchon

§1 7

1- Introduction
© D. Ribouchon

4
 Objectifs d'un projet de
développement de système

• Fournir un système de qualité, au moindre coût et dans les

délais les plus courts: allier qualité et productivité
• Deux niveaux de qualité du système:
– La réponse aux besoins utilisateur:
• qualité externe
• => vision de l'utilisateur
– La maintenabilité, l'évolutivité, i.e. "l'agilité du système":
• qualité interne,
• => vision du développeur
• L'agilité du système rejoint, à moyen et long terme, l'objectif de
productivité
• Chercher le bon dosage …
© D. Ribouchon

§1 9

Mise en situation – cas concret (de type SI)

• Objectif du projet: élaborer un logiciel de consultation de

commandes, en alliant qualité et productivité

• Comment atteindre cet objectif?

© D. Ribouchon

§1 10

5
 Une des clés: travailler avec méthode

• Suivre un processus de développement

• Le processus de développement définit:
– les activités à effectuer
– la séquence de leur réalisation
– les rôles et responsabilités

• Deux types d'activités:

– activités d'ingénierie logicielle (spécification, conception,
codage …)
– activités de support (gestion de projet, gestion de
configuration et des changements …)
D. Ribouchon

§1 11
11/28
©

Activités d'ingénierie logicielle "classiques"

Vision utilisateur, Exigences Tests

externe (et def. tests de de qualification
Qualification)

Conception Tests
Vision développeur, (et def. tests int.) d'intégration
interne

Codage
(et TU)
D. Ribouchon

§1 12
12/28
©

6
 La gestion de projet

• L'activité de gestion de projet adresse en particulier:

– la planification (i.e. "le séquencement des activités
d'ingénierie")
– les ressources affectées aux activités d'ingénierie à un
moment donné

• Deux grands types de séquencement:

– processus dits "en cascade"
– processus dits "itératifs", "agiles"
D. Ribouchon

§1 13
13/28
©

Processus en V en cascade:
Une étape = finaliser une activité
d'ingénierie

Exigences Tests
(et def. tests de
de qual.) qualification

Conception
Tests
(et def. tests
d'intégration
d'int.)

Codage
(et TU)

Etape 1 Etape 2 Etape 3 Etape 4 Etape 5

© D. Ribouchon

§1 14

7
 Processus en cascade: l’effet « Tunnel »

• Absence de visibilité sur le processus

Démarrage ? ?
Enoncé des
besoins

Dé
vel
o ppe
me
nt

Déploiement

Maintenance
© D. Ribouchon

§1 15

Processus en V itératif/agile:
Une étape = effectuer le V sur un périmètre
réduit

Etape/Itération 1 Etape/Itération 2 Etape/Itération 3 Etape/Itération 4

• On aimerait qu'un processus itératif soit incrémental …

© D. Ribouchon

§1 16

8
 L'itératif réduit l'effet "tunnel" - Limitation
des risques

Démarrage

Étude
préliminaire

Incrément 1
Analyse
fonctionnelle
Conception
technique Déploiement
Incrément 2
Développement

Tests

Analyse
fonctionnelle
Conception
Déploiement
Incrément 3
technique
Développement

Tests
Analyse
fonctionnelle
Conception Incrément 4
technique Déploiement
Développement

Tests
Analyse
fonctionnelle
Conception
technique Déploiement
Développement

Tests
Maintenance
© D. Ribouchon

§1 17

Pour notre petit projet

• Processus en cascade ou itératif?

© D. Ribouchon

§1 18

9
 Définir les exigences du logiciel

• A minima, décrire l'IHM sous la forme de descriptions d'écran

• Définition des exigences du logiciel "Consultation commandes":

– écran accueil: saisie du numéro de commande parmi les
commandes existantes
– écran commande: visualisation de la commande: numéro,
montant HT, montant TTC, taux taxes (commun à toutes les
commandes)
© D. Ribouchon

§1 19

Concevoir le logiciel

• A minima:
– Définir la plateforme technique: architecture matérielle et
framework logiciel
– Décrire la structuration du code en unités de code source –
i.e. fichiers de code source

• Conception du logiciel "Consultation commandes":

– Plateforme technique: Techno Web/PHP – 1 serveur Web
(pas de BDD)
– Structuration du code: 1 programme PHP, matérialisé par
un seul fichier "consultationCdes.php", produisant les 2
pages
© D. Ribouchon

§1 20

10
 Coder

• Fichier consultationCdes.php:
<html>
<head><title>Consultation Commandes></title></head>
<body>
<?php
if ($_SERVER['REQUEST_METHOD']== 'GET') {
?>
<form action="<?php echo $_SERVER['PHP_SELF'] ?>" method="POST">
Numéro de la commande:
<input type="texte" name="numeroCde" /> <br />
<input type="submit" name="Consulter commande" /> <br />
</form>
<?php
} elseif ($_SERVER['REQUEST_METHOD']== 'POST') {
$numero = $_POST['numeroCde'];
$montantHT = $lesCommandes[$numero]['montantHT'];
$montantTTC = $lesCommandes[$numero]['montantHT']+
$lesCommandes[$numero]['montantHT']* $tauxTaxes;
© D. Ribouchon

§1 printf (…………);} … 21
</html>

Tester (au niveau qualification)

• A minima:
– Exécuter un scénario significatif (qui aura été défini au
moment de la spécification des exigences)

• Dans notre cas:

– Consulter une commande existante (numéro 3)
© D. Ribouchon

§1 22

11
 Réflexions sur le cas – Le projet a-t-il
atteint ses objectifs?

• Qualité:
– Réponse aux besoins
– Maintenabilité et évolutivité

• Productivité:
– Court terme = développement de la première version du
logiciel, "from scratch"
– Moyen/long terme = maintenance et évolutions
© D. Ribouchon

§1 23

Améliorer la compréhension du
contexte métier

• Afin de bien relier la spécification des exigences au besoin

métier, il est souhaitable de connaître le contexte métier

=> connaître les processus métier

© D. Ribouchon

§1 24

12
 Améliorer la conception du logiciel –
Structuration du code

• Un code logiciel est un ensemble de lignes de code source

définissant des données et des traitements sur ces données

• Une problématique essentielle de conception: comment

structurer ces milliers de lignes de code en unités de code
source (i.e. en fichiers)?
© D. Ribouchon

§1 25

Améliorer la conception du logiciel –

Bonnes pratiques de conception –
Les fondamentaux

• Pratique 1- Séparation des préoccupations en unités de code:

– Chaque unité de code possède une responsabilité claire,
reflétée par son nom, et non partagée
– Les données et les traitements associés sont définis dans la
même unité, qui est responsable de l'intégrité de ses
données
– …
• Pratique 2- Limitation des dépendances:
– …
© D. Ribouchon

§1 26

13
 Améliorer la conception du logiciel –
Réflexions sur le cas

• Comment améliorer la maintenabilité du code précédent en

suivant ces principes de conception?
© D. Ribouchon

§1 27

Deux nouvelles bonnes pratiques

• Pratique 1- Séparation des préoccupations en unités de code:

– Chaque unité de code possède une responsabilité claire,
reflétée par son nom, et non partagée
– Les données et les traitements associés sont définis dans la
même unité, qui est responsable de l'intégrité de ses
données
– Séparer les préoccupations d'affichage des
préoccupations de gestion des données
– Quand l'unité gère des "choses" du monde réel, le nom
de l'unité reflète le nom utilisé dans le monde réel:
structurer en s'appuyant sur le monde réel
© D. Ribouchon

§1 28

14
 Améliorer le processus de
développement?

• Affiner le processus?
• Utiliser le Unified Process?
• Quel processus dans le cas d'un système embarqué?
© D. Ribouchon

§1 29

Améliorer la forme des descriptions

• Dans notre cas, améliorer la forme des descriptions:

– Spécifications des exigences
=> Connaître le contexte métier
=> Utiliser des prototypages d'écran?
– Spécifications et conception du logiciel
=> Utiliser un formalisme lisible et rigoureux: UML (Unified
Modeling Language)? Facture

0..1

Client Voiture Reparation

possède
© D. Ribouchon

- immatriculation
1 1..* 1 0..*
- couleur
§1 30

15
 Introduction – Synthèse (1/2)

• L'objectif de la formation est de donner quelques clés pour

répondre à la problématique du projet logiciel

• Ces clés s'articulent autour de 3 axes intimement liés:

– Le processus de développement
– Les bonnes pratiques de conception logiciel
– La notation UML, utilisée dans les activités de description

• Ces aspects sont généralement applicables à toute

technologie, même si le cours a une orientation objet
© D. Ribouchon

§1 31

Introduction – Synthèse (2/2)

Vision utilisateur, Exigences Tests

externe (et def. tests de de qualification
Qualification)
Utilisation
d'UML

Conception Tests
Vision développeur, (et def. tests int.) d'intégration
interne

Codage
(et TU)
© D. Ribouchon

§1 32

16
 Plan du cours
(Déclinaison SI)

• Introduction
• Prise en main: COO UML/POO et processus de développement
• Spécifier les exigences du système
– Comprendre le métier
– Spécifier les exigences
• Concevoir le système
– Définir la plateforme technique
– Concevoir le code source
– Concevoir les composants déployables
• Pour aller plus loin
© D. Ribouchon

§1 33

Plan du cours
(Déclinaison système embarqué)

• Introduction
• Prise en main: COO UML/POO et processus de développement
• Exigences du système embarqué
– Sensibilisation à la modélisation du domaine
– Spécification des exigences du système
• Conception du système embarqué
• Conception du logiciel
• Pour aller plus loin
© D. Ribouchon

§1 34

17
 Prise en main:
COO UML/POO et processus de
développement
© D. Ribouchon

§1 35

Plan du chapitre

• COO UML/POO

• Vue d'ensemble du processus de développement

• Vue d'ensemble de la notation UML

© D. Ribouchon

§1 36

18
 Programmation structurée/OO
et conception UML

• Un objectif principal des bonnes pratiques de conception

consiste à produire une programmation structurée,
probablement orientée objet (POO), maintenable et évolutive
• La conception doit être exprimée de façon claire et rigoureuse.
• UML est un formalisme bien adapté car il définit des concepts
de programmation fondamentaux

Tests de
Spécification
"niveau 2"
exigences

Commande
Tests
numero :int Conception
montantHT :float "niveau 1"
montantTTC :float
tauxTaxes :float

facturerTTC()
class Commande {
© D. Ribouchon

Codage int numero;

§1 float montantHT;
float montantTTC;
37
}

Programmation structurée et POO

• Les fondamentaux de la programmation structurée dont la

POO:
– unité de code: regroupe des données et traitements
– les valeurs des données constitue le contexte d'exécution
des traitements
• Conception OO:
– classe ("unité de code")
– attribut
– opération
– objet et instanciation ("occurrence des données et contexte
d'exécution")
– communication entre objets
– encapsulation
© D. Ribouchon

§1 38

19
 Unité de code

• Un fichier de code source dans lequel sont définis un ensemble

de données et de traitements

• Rappel pratique 1- La séparation des préoccupations en unités

de code:
– Chaque unité de code possède une responsabilité claire
– Les données et les traitements associés sont définis dans la
même unité, qui est responsable de l'intégrité de ses
données
– Séparer les préoccupations d'affichage des préoccupations
de gestion des données
– Structurer en s'appuyant sur le monde réel
© D. Ribouchon

§1 39

En C: Module C = fichier .c

• Fichier GestionCommandes.c:
typedef struct Commande {
float montantHT;
float montantTTC;
}
struct Commande lesCommandes [100];
float tauxTaxes;
void facturerCdeTTC(int numero){
lesCommandes[numero].montantTTC=
lesCommandes[numero].montantHT+
lesCommandes[numero].montantHT* tauxTaxes;
}
© D. Ribouchon

§1 40

20
 En PHP: fichier .php

• GestionCommandes.php

$lesCommandes
$tauxTaxes

function facturerCdeTTC ($numero){

global $lesCommandes;
global $tauxTaxes;
$lesCommandes[$numero]['montantTTC']= $lesCommandes[$numero]['montantHT']+
$lesCommandes[$numero]['montantHT']* $tauxTaxes;}
}
© D. Ribouchon

§1 41

En UML: une classe logicielle

• Une classe logicielle représente une unité de code dans

laquelle sont définis un ensemble de données et des
traitements sur ces données

Nom de l'unité de code: GestionCommandes

compartiment nom
numero :int
Définition des données: montantHT :float
compartiment attributs montantTTC :float
tauxTaxes :float

Définition des traitements: facturerCdeTTC()

compartiment opérations
© D. Ribouchon

§1 42

21
 Occurrences des données et contexte
d'exécution des traitements
typedef struct Commande {

float montantHT;
GestionCommandes
float montantTTC;
numero :int
montantHT :float
}
montantTTC :float struct Commande lesCommandes [200];
tauxTaxes :float
float tauxTaxes;
facturerCdeTTC()
void facturerCdeTTC(int numero){
lesCommandes[numero].montantTTC=
lesCommandes[numero].montantHT+
lesCommandes[numero].montantHT* tauxTaxes;

• Généralement} les données existent en plusieurs

occurrences: une occurrence pour chaque commande –
i.e. pour chaque objet commande
• Généralement les traitements s'exécutent dans le contexte
d'un objet particulier
© D. Ribouchon

§1 43

Une problématique classique: comment indiquer le

contexte d'exécution d'un traitement – i.e. "l'objet"
du traitement?

• En programmation procédurale:
void facturerCdeTTC(int numero){
lesCommandes[numero].montantTTC=
lesCommandes[numero].montantHT+
lesCommandes[numero].montantHT* tauxTaxes;
}

• La notion d'objet est implicite, mais existe: c'est une entrée

dans le tableau des commandes.
Quelle donnée est particulière?

• La POO met en avant la notion de contexte d'exécution avec la

© D. Ribouchon

notion explicite d'objet

§1 44

22
 Objet en POO

• Objet en POO = quelque chose, à l'intérieur

du logiciel à l'exécution, qui a une identité, un état,
et un comportement

cde131

numero = 131
montantHT = 10
montantTTC = 12

facturerTTC()
© D. Ribouchon

§1 45

En POO, un objet est

une instance de classe

cde131 :Commande

numero = 131
montantHT = 10
montantTTC = 12

facturerTTC()

• Le nom de classe reflète la nature de chaque instance et non

plus la nature des traitements: GestionCommandes devient
Commande
Commande

numero :int
montantHT :float
montantTTC :float
tauxTaxes :float
© D. Ribouchon

§1 facturerTTC() 46

23
 Classe et objet

Commande
• Dans la classe sont définis les types de données numero :int
et les traitements – au moment du codage montantHT :float
montantTTC :float
tauxTaxes :float

facturerTTC()

• Chaque objet contient les valeurs des données – au

moment de l'exécution

cde131 :Commande cde132 :Commande

numero = 131 numero = 132

montantHT = 10 montantHT = 20
montantTTC = 12 montantTTC = 24

• Ces différentes notions POO sont clairement définies dans

le formalisme UML
© D. Ribouchon

§1 47

Classe – Class
Définition UML

• Classe = "Descripteur d'un jeu d'objets qui partagent les

mêmes caractéristiques (attributs, opérations, relations …)."

Commande

numero :int
montantHT :float
Classe représentées dans un montantTTC :float
diagramme de classes – Class Diagram tauxTaxes :float

facturerTTC()
© D. Ribouchon

§1 48

24
 La notion de classe en conception logicielle
orientée objet

• La classe est une unité de code (i.e. un fichier de code source)

dont la responsabilité, la préoccupation, est de gérer « un type
de trucs »

• Bonne pratique: Le nom de la classe reflète la nature des

objets, instances de la classe, gérés par la classe

Commande
© D. Ribouchon

§1 49

Classe – Class
Illustration Java

• Une classe Java:

Fichier Commande.java:
Commande
class Commande {
….
}
© D. Ribouchon

§1 50

25
 Classe – Class
Illustration PHP

• Une classe PHP:

Fichier Commande.php:
Commande
class Commande {
….}
© D. Ribouchon

§1 51

Attribut – Attribute
Définition UML

• Attribut = "Description d'un élément nommé prenant un type

spécifié dans une classe. Chaque objet de la classe détient
séparément une valeur du type."

Commande

numero :int
Attributs définis montantHT :float
montantTTC :float
dans la classe tauxTaxes :float

facturerTTC()

cde131 :Commande cde132 :Commande

Valeurs des attributs numero = 131 numero = 132

montantHT = 10 montantHT = 20
dans chaque objet montantTTC = 12 montantTTC = 24

• Les valeurs des attributs définissent l'état de l'objet

© D. Ribouchon

§1 52

26
 Attribut – Attribute
Illustration Java

• Un attribut dans la classe Java:

class Commande {
Commande
…
numero :int int numero;
montantHT :float float montantHT;
montantTTC :float float montantTTC;
tauxTaxes :float ….
}
facturerTTC()
© D. Ribouchon

§1 53

Attribut – Attribute
Illustration PHP

• Une propriété dans la classe PHP:

class Commande {
Commande
…
numero :int var $numero;
montantHT :float var $montantHT;
montantTTC :float var $montantTTC;
tauxTaxes :float ….
}
facturerTTC()
© D. Ribouchon

§1 54

27
 Opération – Operation
Définition UML (1/2)

• Opération = "Spécification d'une requête ou d'une

transformation de son état, qu'un objet peut être appelé à
exécuter."
Commande

numero :int
montantHT :float
montantTTC :float
tauxTaxes :float

Opération facturerTTC()

• Le contexte d'exécution d'une opération est généralement un

objet: une opération est donc plutôt "une requête qu'une classe
peut être amenée à exécuter et dont le contexte d'exécution est
généralement un objet
© D. Ribouchon

§1 55

Opération – Operation
Définition UML (2/2)

• Une opération peut posséder une liste de paramètres, dont des

paramètres de retour

Commande

numero :int
montantHT :float
montantTTC :float
tauxTaxes :float

facturerTTC(mode :int) :boolean

© D. Ribouchon

§1 56

28
 Opération – Operation
Illustration Java

• Une méthode dans la classe Java:

class Commande {
Commande …
numero :int float montantHT;
montantHT :float float montantTTC;
montantTTC :float static float tauxTaxes;
tauxTaxes :float ….
facturerTTC()
void facturerTTC() {
this.montantTTC = this.montantHT +
this.montantHT * tauxTaxes;
}
…
}
© D. Ribouchon

§1 57

Opération – Operation
Illustration PHP

• Une méthode dans la classe PHP:

class Commande {
Commande …
numero :int var $montantHT;
montantHT :float var $montantTTC;
montantTTC :float static $tauxTaxes;
tauxTaxes :float ….
facturerTTC()
function facturerTTC() {
$this->montantTTC = $this->montantHT
$this->montantHT * $tauxTaxes;
}
…
}
© D. Ribouchon

§1 58

29
 Objet – Object
Définition UML

• Objet = "Entité discrète avec une frontière bien définie et une

identité qui encapsule son état
et son comportement ; instance d'une classe."

cde131 :Commande

numero = 131
montantHT = 10
montantTTC = 12

facturerTTC()

• … ou plutôt "quelque chose, à l'intérieur

du logiciel à l'exécution, qui a une identité, un état,
et un comportement. C'est une instance d'une classe qui aura
été codée précédemment."
© D. Ribouchon

§1 59

Objet – Object
Illustration Java

• Une zone mémoire contenant la valeur des attributs

cde131 :Commande 131

numero = 131 10
montantHT = 10
montantTTC = 12
12

• Quelle est l'identité de l'objet?

© D. Ribouchon

§1 60

30
 Instanciation - Instantiation
Définition UML

• Instancier = "Créer une instance d'un descripteur"

• Instancier un objet = Créer une instance de classe
:Titi

cde131
creerCommande()
:Commande

2 instanciations cde312
creerCommande()
:Commande

cde131 :Commande cde132 :Commande

=> 2 instances de la classe Commande numero = 131 numero = 132

© D. Ribouchon

montantHT = 10 montantHT = 20
montantTTC = 12 montantTTC = 24
§1 61

Instanciation- Instantiation
Illustration Java

• Quelque part dans le code de la classe Titi, appel à la méthode

constructeur de la classe Commande:
class Titi{
…
Commande laCommande;
…
methodeX(){
…
laCommande = new Commande();
…..
}
}

• L’objet a automatiquement une identité logicielle technique:

son emplacement mémoire
© D. Ribouchon

§1 62

31
 Instanciation- Instantiation
Illustration PHP

• Quelque part dans le code de la classe Titi, appel à la méthode

constructeur de la classe Commande:
class Titi{
…
var $laCommande;
…
function methodeX(){
…
$laCommande = new Commande();
…
}
}

• L’objet a automatiquement une identité logicielle technique:

son emplacement mémoire
© D. Ribouchon

§1 63

Constructeur – Constructor
Définition UML

• Constructeur = "Opération qui crée et initialise une instance de

classe."

Commande

numero :int
montantHT :float
montantTTC :float
tauxTaxes :float

facturerTTC()
Constructeur Commande()
© D. Ribouchon

§1 64

32
 Constructeur– Constructor
Illustration Java

• Une méthode du nom de la classe:

class Commande {
…
int numero;
….
Commande() {
…
this.numero = …
…
}
…
}
© D. Ribouchon

§1 65

Définition du constructeur – Constructor

Illustration PHP

• Une méthode __construct:

class Commande {
…
var $numero;
….
function __construct() {
…
$this->numero == …
…
}
…
}
© D. Ribouchon

§1 66

33
 Communication entre objets – Message
Définition UML

• Message entre objets = "Communication d'un objet à un

autre."
leTiti :Titi cde131 :Commande

Diagramme de séquence
– Sequence Diagram facturerTTC()

• Le contexte de traitement/exécution du message est l'état de

l'objet récepteur
• L'objet émetteur doit connaître l'identité de l'objet récepteur
© D. Ribouchon

§1 67

Communication entre objets – Message

Illustration Java

• Envoi d'un message = appel d'une méthode

class Titi {
…
Commande laCommande;
…
methodeX(){
…
laCommande.facturerTTC();
…..}
}

• Comment indiquerait-on le contexte d'exécution – i.e. "l'objet

commande" - dans une approche procédurale classique?
© D. Ribouchon

§1 68

34
 Communication entre objets – Message
Illustration PHP

• Envoi d'un message = appel d'une méthode

class Titi {
…
var $laCommande;
…
function methodeX(){
…
$laCommande->facturer();
…..}
}

• Comment indiquerait-on le contexte d'exécution – i.e. "l'objet

commande" - dans une approche procédurale classique?
© D. Ribouchon

§1 69

Méthode = message synchrone

• L'appel d'une méthode/opération correspond à l'envoi d'un

message synchrone

leTiti :Titi cde131 :Commande

Message synchrone = facturerTTC()

appel de la méthode
() Message retour =
retour de la méthode
© D. Ribouchon

§1 70

35
 Exercice

:? :Titi :Toto

reqX()

reqY(1)

(false)

()

• A partir du diagramme de séquence, compléter la conception

des classes Titi et Toto dans un diagramme de classes
• Coder en java ce qui peut être déduit de la conception
(uniquement):
© D. Ribouchon

§1 71

Destruction – Destruction
Définition UML

• Destruction = "Elimination d'un objet et récupération de ses

ressources."
leTiti :Titi

creerCommande() cde131
:Commande

(cde131)

facturerTTC()
()

detruire()
© D. Ribouchon

§1 72

36
 Destruction – Destruction
Illustration Java

• Définition du destructeur dans la classe

• Appel du destructeur: par le "ramasse-miettes", quand "l'objet

ne sert plus à rien"
© D. Ribouchon

§1 73

Destruction – Destruction
Illustration PHP

• Définition d'une méthode destructeur dans la classe:

class Commande {
…
function __destruct() {
…
}
…
}

• Appel du destructeur: automatiquement, quand "l'objet ne sert

plus à rien"
© D. Ribouchon

§1 74

37
 Notions échappant au
"paradigme objet pur"

• Donnée existant en une seule occurrence

• Traitement dont le contexte d'exécution n'est pas un objet
particulier
• Dans cet exemple de code C, quelle partie n'est pas dans
l'esprit objet?

typedef struct Commande {

float montantHT;
...
}
struct Commande lesCommandes [100];
float tauxTaxes;
void facturerCdeTTC(int numero){
lesCommandes[numero].montantTTC= ….
}
void modifierTauxTaxes(nouveauTaux){
© D. Ribouchon

§1 tauxTaxes=nouveauTaux;} 75

Attribut de classe – Class attribute

Définition UML

• Attribut de classe = "Attribut dont la valeur est partagée par

toutes les instances de la classe. Egalement appelé attribut
statique."

Commande

numero :int
montantHT :float
montantTTC :float
Attribut de classe tauxTaxes :float

facturerTTC()
© D. Ribouchon

§1 76

38
 Attribut de classe – Class attribute
Illustration PHP

• Propriété statique:

Commande class Commande {

…
numero :int var $numero;
montantHT :float var $montantHT;
montantTTC :float var $montantTTC;
tauxTaxes :float
static $tauxTaxes;
….
facturerTTC()
}
© D. Ribouchon

§1 77

Opération de classe – Class operation

Définition UML

• Opération de classe = "Opération dont l'accès est lié à une

classe et non à une instance de la classe."

Commande

numero :int
montantHT :float
montantTTC :float
tauxTaxes :float

facturerTTC()
Opération de classe modifierTaux(nouveauTaux :float)
© D. Ribouchon

§1 78

39
 Opération de classe – Class operation
Illustration PHP

• Définition d'une méthode statique dans la classe:

class Commande {
var $numero;
var $montantHT;
var $montantTTC;
static $tauxTaxes;

static function modifierTaux($nouveauTaux){

$tauxTaxes = $nouveauTaux;
}
}

class Titi {
• Appel de la méthode: …
Commande::modifier_taux(21);
…..
© D. Ribouchon

§1 } 79

Avons-nous respecté nos bonnes pratiques

de conception? (1/2)

Commande
Titi
numero :int
montantHT :float methodeX()
montantTTC :float
tauxTaxes :float

facturerTTC()

class Commande {
var $numero; class Titi {
var $montantHT; …
var $montantTTC; function methodeX(){
static $tauxTaxes; $laCommande = new Commande();
…. …
function facturerTTC() { $laCommande->montantHT =20;
$this->montantTTC = $this->montantHT + $laCommande->montantTTC =22;
$this->montantHT * $tauxTaxes; ….
} }
© D. Ribouchon

… §1 } 80
}

40
 Avons-nous respecté nos bonnes pratiques
de conception? (2/2)

• Rappel pratique 1- Séparation des préoccupations en unités de code:

– Chaque unité de code possède une responsabilité claire
– Les données et les traitements associés sont définis dans la même
unité, qui est responsable de l'intégrité de ses données
– Séparer affichage et gestion des données
– Structurer en s'appuyant sur le monde réel
– En OO, le nom de la classe reflète la nature des objets

• Rappel Pratique 2- Limitation des dépendances:

Commande
Titi
numero :int
montantHT :float
montantTTC :float methodeX()
tauxTaxes :float
© D. Ribouchon

facturerTTC()
§1 81

Appliquer le principe d'encapsulation objet

• La classe n'expose pas les données dont elle est responsable:

ses attributs sont privés

• Elle communique avec l'extérieur (les objets des autres

classes) via des messages qu'elle reçoit: invocation
d'opérations publiques
© D. Ribouchon

§1 82

41
 Visibilité – Visibility
Définition UML

• Visibilité = "La visibilité d'un élément indique si on peut voir

l'élément en dehors de son espace de noms enveloppant."

• Deux visibilités de base pour les attributs et les opérations:

privé-private et publique-public

Commande

- numero :int
- montantHT :float
Visibilité privé - montantTTC :float
- tauxTaxes :float

Visibilité publique + facturerTTC()

+ modifierTaux(nouveauTaux :float)
© D. Ribouchon

§1 83

Visibilité – Visibility
Illustration Java

class Commande {
…
private int numero;
Commande
private float montantHT;
- numero :int
- montantHT :float ….
- montantTTC :float
- tauxTaxes :float
public void facturerTTC() {
…
+ facturerTTC()
+ modifierTaux(nouveauTaux :float) }
…
}
© D. Ribouchon

§1 84

42
 Visibilité – Visibility
Illustration PHP

class Commande {
…
private $numero;
Commande
private $montantHT;
- numero :int
- montantHT :float ….
- montantTTC :float
- tauxTaxes :float
public function facturerTTC() {
…
+ facturerTTC()
+ modifierTaux(nouveauTaux :float) }
…
}
© D. Ribouchon

§1 85

Encapsulation – Accesseurs

• Des méthodes d'accès aux informations:

Commande

- numero :int
- montantHT :float
- tauxTaxes :float

+ getNumero() :int
+ getMontantHT() :float
+ getTauxTaxes() :float
+ setNumero(numero :int)
+ setMontantHT(montant :float)
+ setTauxtaxe(taux :float)
© D. Ribouchon

§1 86

43
 Exercice – le rectangle

• Concevoir et programmer une classe gérant des rectangles. Chaque

rectangle gère sa largeur, sa longueur, sa surface
(en lecture et modification):
– Concevoir la classe en UML:
• Attributs
• Opérations (dont le constructeur)
– Coder la classe en Java ou PHP
• Concevoir et programmer une classe "RectangleControleur"
qui offre une seule opération "manipulerRectangles" qui:
• instancie 2 rectangles de dimensions suivantes: 2,4 et 2,5
• récupère la surface du premier rectangle, puis du deuxième
• modifie la largeur du premier
• récupère la nouvelle surface
• NB: les 2 rectangles sont des objets locaux à l'opération
– Concevoir la classe en UML
© D. Ribouchon

§1 – Coder la classe en Java ou PHP 87

Le principe d'encapsulation est un principe

fondamental de conception

• Le principe d'encapsulation aide à mettre en œuvre nos 2

bonnes pratiques de conception:
– Pratique 1- Séparation des préoccupations en unités de
code:
• …
• Les données et les traitements associés sont définis dans la
même unité, qui est responsable de l'intégrité de ses données:
les données sont privées
– Pratique 2- Limitation des dépendances:
• Eviter la redondance de données:
– par des attributs calculés
• Pas de dépendance directe sur les données
© D. Ribouchon

§1 • Comment traduire le principe d'encapsulation en programmation 88

procédurale classique?

44
 Objets persistants/transitoires
(Persistent/Transient)

• Un objet persistant sauvegarde son état dans un système

de stockage permanent (une base de données en général)
• On peut arrêter le processus qui l'a créé sans perdre les
informations contenues dans l'objet (passivation
de l'objet)
• On peut ensuite reconstruire l'objet (activation
de l'objet)
• Les objets non persistants sont dits transitoires
• Le principe d'encapsulation s'applique jusqu'à la
persistance
© D. Ribouchon

§1 89

Patterns de conception logicielle

• Les bonnes pratiques de conception sont souvent appelées

"patterns", au sens " solutions communes à des problèmes de
conception récurrents"

• Ces patterns se situent à 2 niveaux:

– au niveau de l'architecture d'ensemble: on parle de
"architectural pattern"
– au niveau de quelques classes: on parle de "design
pattern"

• En POO, il existe un catalogue de design patterns, le catalogue

"GOF: "Design patterns Element of Reusable Object-Oriented
Software" (de E. Gamma, R. Helm, R. Johnson et J. Vlissides)
© D. Ribouchon

§1 90

45
 Plan du chapitre

• COO UML/POO

• Vue d'ensemble du processus de développement

• Vue d'ensemble de la notation UML

© D. Ribouchon

§1 91

Rappel de notre objectif

• Qualité: Réponse aux besoins, Maintenabilité et évolutivité

• Productivité: Court terme = développement de la première
version du logiciel, "from scratch", Moyen/long terme =
maintenance et évolutions

• Suffit-il de suivre quelques bonnes pratiques de conception, à

l'échelle de quelques classes?

Commande

numero :int Conception

montantHT :float
montantTTC :float
tauxTaxes :float

facturerTTC()
class Commande {
Codage int numero;
float montantHT;
float montantTTC;
© D. Ribouchon

§1 92

46
 Suivre un processus de développement
plus complet

"Besoins utilisateur"

Prendre en compte Tester le système

Spécification Tests de
le besoin utilisateur exigences qualification logiciel

Commande

numero :int Conception

Concevoir un montantHT :float
montantTTC :float

système logiciel tauxTaxes :float

facturerTTC()
class Commande {
Codage int numero;
float montantHT;
float montantTTC;
}

• Le processus est adapté à la complexité du logiciel à réaliser

© D. Ribouchon

§1 93

Importance de la branche amont

• Centrer le développement sur sa finalité: une réponse aux

besoins utilisateur

• Maîtriser la complexité du système logiciel lors de sa

conception

• Partager la même vision du système entre les différents

acteurs du projet (managers, utilisateurs, architectes,
développeurs …)
© D. Ribouchon

§1 94

47
 Quel processus de développement?

• Le processus de développement doit être adapté à la

complexité du projet et le type projet
• Dans ce cours, nous allons nous appuyer:
– sur le Processus Unifié – Unified Process, pour un projet
de type SI
– sur un processus d'ingénierie système classique, pour un
projet de type système embarqué temps réel
© D. Ribouchon

§1 95

Le Unified Process: un processus

adapté aux systèmes de type SI

• Le Unified Process est un processus de développement,

élaboré par les concepteurs d'UML, souvent associé à UML
• Ses principales caractéristiques:
– il définit un ensemble de disciplines, en particulier des
disciplines de modélisation - i.e. activités d'ingénierie de
la branche amont
– il est itératif et incrémental
– il est générique et adaptable (une adaptation: le RUP)
© D. Ribouchon

§1 96

48
 Les activités d'ingénierie
dans le Processus Unifié

"Besoins utilisateur"

Modélisation du
Déploiement
métier

Vision utilisateur, Tests système

Exigences
("de qualification")
externe

Analyse
(= Préconception
optionnelle)
Vision développeur,
Tests
interne Conception
d'intégration

Implémentation
© D. Ribouchon

§1 97

Modélisation du Spécification
métier – des exigences –
Business modeling Requirements
Réalité décrite: Réalité décrite:
le système métier le système logiciel
(Processus métier Niveau d'abstraction:
Informations métier) vue externe

facture 130 clic

total: 304€

Notations UML Notations UML

Calculer montant
Completer reparation

[montant > 500] [montant <= 500]

Facture
Mecanicien

Obtenir autorisation
0..1 :SI garage

1 :Secretaire :Sys Nomenclature

Client Voiture Reparation

possède demande preparation facture()
- immatriculation
1 1..* 1 0..*
- couleur
Payer

ecran liste reparations()

© D. Ribouchon

selection reparation()

...

§1 98

49
 Conception

Réalité décrite:
système d'information
Niveau d'abstraction:
vue interne

Notations UML
PCClient Serv eurBDD

* 1

:GUI :Reparation :Facture

:Secretaire

demande de facturation()

traiterFacturation()

creerFacture()
© D. Ribouchon

© D. Ribouchon

ecran facture()

§1 99

L'analyse: un préconception simplifiée,

optionnelle

"Besoins utilisateur"

Modélisation du
Déploiement
métier

Vision utilisateur, Tests système

Exigences
("de qualification")
externe

Analyse
(= Préconception
optionnelle)
Vision développeur,
Tests
interne Conception
d'intégration

Implémentation
© D. Ribouchon

§1 100

50
 Les rôles classiques au sein d'un projet :
Maîtrise d'ouvrage/Maîtrise d'œuvre

• Le maître d'ouvrage: il finance, définit ce qu'il veut (cahier des

charges), il recette
modélisation du métier/spécification des exigences/tests de
qualification

• Le maître d'œuvre: il réalise à la demande du maître d'ouvrage

conception/implémentation/tests d'intégration

• Un rôle intermédiaire: assistance à maîtrise d'ouvrage

© D. Ribouchon

§1 101

Projet French chic –

Prise en main du projet

• Prendre en main le projet "French chic": Expression générale

des besoins fournie par la MOA

"Besoins utilisateur"
Modélisation du
Déploiement
métier

Tests système
Vision utilisateur, Exigences
("de qualification")
externe
Analyse
(= Préconception
optionnelle)
Vision développeur, Tests
Conception
interne d'intégration
© D. Ribouchon

§1 Implémentation 102

51
 Système de type
"système embarqué"

• Rappels:
– Dans ce contexte, on emploie le terme "système" pour
désigner un système composé d'éléments logiciels et
d'éléments matériels

– Les éléments matériels sont des éléments spécifiques (e.g.

matrice de commutation électronique), et non de simples
unités de déploiement (calculateur).
© D. Ribouchon

§1 103

Les activités d'ingénierie classiques pour le

développement d'un système embarqué

Besoins utilisateur

Ingénierie du
système
"englobant"

Exigences Qualification
du système du système
embarqué embarqué

Conception Intégration
du système du système
embarqué embarqué

Conception Intégration
du logiciel du logiciel

Implémentation
du logiciel
© D. Ribouchon

§1 104
• En parallèle de l'ingénierie du logiciel: l'ingénierie du HW

52
 Les activités de la branche amont

• Spécifications des exigences du système embarqué: le

système embarqué est une "boîte noire"
• Conception du système: le système est une boîte blanche, le
logiciel et chaque HW est une boîte noire

• Conception du logiciel: le logiciel est une boîte blanche

Logiciel/SW

HW HW
Raccord. Raccord.
Poste poste ligne Ligne réseau
HW
Matrice de
com.
© D. Ribouchon

§1 Système embarqué: le PABX 105

Le système PABX embarqué

dans un système téléphonique

Logiciel/SW

HW HW
Raccord. Raccord.
Abonné Poste poste ligne Ligne réseau
HW
Matrice de
com.

Système embarqué: le PABX (HW/SW)

© D. Ribouchon

Système téléphonique
§1 106

53
 Les rôles classiques au sein d'un projet
"système embarqué"

Besoins utilisateur

Architecte système Ingénierie du

Système
du système englobant "englobant"

Exigences Qualification
du système du système
embarqué embarqué

Architecte système
du système embarqué Conception
du système
Intégration
du système
embarqué embarqué

Conception Intégration
du logiciel du logiciel
Concepteur-développeur
du logiciel
© D. Ribouchon

Implémentation
du logiciel
§1 107

Projet Ascenseur –
Prise en main du projet

• Prendre en main la description du système ascenseur fournie par les

architectes du système ascenseur

Besoins utilisateur
Ingénierie du
Système
"englobant"

Exigences Qualification
du système du système
embarqué embarqué

Conception Intégration
du système du système
embarqué embarqué

Conception Intégration
du logiciel du logiciel
© D. Ribouchon

§1 Implémentation
108
du logiciel

54
 Plan du chapitre

• COO/POO et UML

• Vue d'ensemble du processus de développement

• Vue d'ensemble de la notation UML

© D. Ribouchon

§1 109

UML: formalisme de modélisation (1/2)

• UML (Unified Modeling Language) est un langage de

modélisation graphique adapté à la description de logiciels
• Standard OMG depuis 1997, il est le plus utilisé dans
l'ingénierie logicielle aujourd'hui
• Issus des méthodes Booch (Grady Booch), OMT
(James Rumbaugh) et OOSE (Ivar Jacobson)

• Intègre les concepts objets

• Dernières versions:
– 2.4.1 (08/2011): www.omg.org/spec/UML/2.4.1
© D. Ribouchon

– 2.4.5 béta1 (10/2012): www.omg.org/spec/UML/2.5/Beta1

§1 110

55
 UML: formalisme de modélisation (2/2)

• Il définit:
– un ensemble de concepts, possédant une sémantique claire
– une "boîte à outils" de formalismes de modélisation
graphique: les diagrammes UML

• Formalisme très générique :

– Pour tout type de système logiciel
– Les mêmes diagrammes sont utilisés dans plusieurs
disciplines de modélisation

=> formalisme très (trop?) abstrait

© D. Ribouchon

§1 111

Les 13 diagrammes

• d'activité (activity diagram)

• de classe (class diagram)
• d'objets (object diagram)
• de machine d'états (state machine diagram)
• de cas d'utilisation (use case diagram)
• de séquence (sequence diagram)
• de package (package diagram)
• de déploiement (deployment diagram)
• de composants (component diagram)
• de structure composite (composite structure diagram)
• de communication (communication diagram)
• de timing (timing diagram)
© D. Ribouchon

• de vue d'ensemble des interactions (interaction overview diagram)

§1 112

56
 Diagramme d'activité

Calculer montant

[montant > 500] [montant <= 500]

Obtenir autorisation

Payer
© D. Ribouchon

§1 113 113

Diagramme de classe

Facture

0..1

Client Voiture Reparation

possède
- immatriculation
1 1..* 1 0..*
- couleur
© D. Ribouchon

§1 114

57
 Diagramme d'objets

:Facture

:Reparation

:Client :Voiture

:Reparation
© D. Ribouchon

§1 115

Diagramme de machine d'états

Prete
Env oyee
envoi

apres(10 jours) paiement

EnRelance Payee
paiement
© D. Ribouchon

§1 116

58
 Diagramme de cas d'utilisation

Creer un dossier

Secretaire

Facturer

Systeme nomenclature

Saisir reparation

Mecanicien
© D. Ribouchon

§1 117

Diagramme de séquence

:GUI :Reparation :Facture

:Secretaire

demande de facturation()

traiterFacturation()

creerFacture()

ecran facture()
© D. Ribouchon

§1 118

59
 Diagramme de package
© D. Ribouchon

§1 119

Diagramme de déploiement

PCClient Serv eurBDD

* 1
© D. Ribouchon

§1 120

60
 Diagramme de composants

GUI_JSP GestionReparation
ReparationServices
© D. Ribouchon

§1 121

Diagramme de structure composite

(déclinaison système embarqué)

Cabine

«HW» «HW»
«HW»
selecteur :BoutonVoyant entrainementCab :
porteCabine :Porte [1] [nbEtages] Entrainement [1]

«SW»
pilote :Pilote
© D. Ribouchon

§1 122

61
 Diagramme de communication

:Secretaire

1.3: ecran facture()

1: demande de facturation()

:GUI 1.2: traiterFacturation() :Reparation

1.1: creerFacture()

:Facture
© D. Ribouchon

§1 123

Diagramme de timing
Lecteur optique

Verrouillee

EnAttente
verifier
Ouv erte

deverrouiller verouiller
Processeur

Inactif
EnVerification
actif
Actif
Porte

Verrouillee Dev errouillee Verrouillee

0 10 20 30 40 50 60 70 80 90 100
© D. Ribouchon

§1 124

62
 Diagramme de vue d'ensemble des
interactions

ref ref
accepter admission refuser admission

sd Sequence Diagram

:GUI :Reparation :Facture

:Secretaire

demande de facturation()

traiterFacturation()

creerFacture()

ecran facture()
© D. Ribouchon

§1 125

Bonne pratique applicable

à tout diagramme

• Pour être lisible, un diagramme doit être simple:

– il contient peu d'éléments
– chaque élément n'est représenté qu'une fois Facture

– il tient sur une page

0..1

Client Voiture Reparation

possède
- immatriculation
1 1..* 1 0..*
- couleur
© D. Ribouchon

§1 126

63
 Une notion structurante: le package
Définition UML

• Package = "Mécanisme généraliste permettant d'organiser

des éléments dans un groupe, d'établir des appartenances
et de déclarer des noms uniques pour référencer les
éléments"

• Un package contient des éléments de modélisation et des

diagrammes les représentant
© D. Ribouchon

§1 127

Packages et outil de modélisation

• La notion de package se matérialise principalement au

travers d'un outil de modélisation
• Les packages structurent le navigateur des modèles
(model explorer, project browser …)

•
© D. Ribouchon

La structuration du projet dans l'outil est essentielle pour la

§1 lisibilité des modèles 128

64
 Spécialiser le formalisme UML
Stéréotype – Stereotype
Définition UML

• Stéréotype = "Nouveau type d'élément de modèle défini

au sein d'un profil, fondé sur un type d'élément de modèle
existant."
«business entity»
Commande
• Permet de préciser le type d'un
numero
élément de modèle montantHT
montantTTC

Commande
«entity»
numero Commande
montantHT
montantTTC numero
montantHT
montantTTC

«java»
Commande

numero
© D. Ribouchon

montantHT
§1 montantTTC 129

Les profils – Profiles

Définition UML

• Profil = "Définition d'un jeu d'ajouts limités à un méta modèle

de base pour l'adapter à une plate-forme ou à un domaine
spécifique"
• Généralement, un profil se matérialise par un ensemble
cohérent de stéréotypes étendant la notation UML à un
domaine spécifique
• Exemples du profil "business modeling"

«business entity»
Commande
<<business use case>>
numero
Acheter
montantHT
montantTTC <<business
actor>> Client
© D. Ribouchon

§1 130

65
 Les différents types de profils

• Deux profils définis dans la norme UML elle-même

(StandardProfileL2/L3)
• Des profils sont définis par l'OMG, en dehors d'UML:
– UML Profile for Modeling and Analysis of Real-Time
Embedded Systems (MARTE)
– UML Profile for CORBA®
– OMG Systems Modeling Language (SysML)
–…
• Des profils sont définis par des organisations autres que l'OMG:
– Rational UML Profile for business modeling (IBM Rational
Software – RUP)
–…
•
© D. Ribouchon

Il est possible d'élaborer un profil "maison"

§1 131

Prise en main – Synthèse (1/2)

• Objectifs du projet: qualité (réponse aux besoins et

maintenabilité) et productivité

• Importance du processus de développement, en particulier

de la branche amont

• Importance des bonnes pratiques de conception, qu'elles

soient objet ou non

• UML, formalisme de description logiciel, n'est qu'un soutien

aux 2 axes principaux: processus de développement et
bonnes pratiques de conception
© D. Ribouchon

§1 132

66
 Prise en main – Synthèse (2/2)
Bonnes pratiques de conception logicielle

• Pratique 1- Séparation des préoccupations en unités de code:

– Chaque unité de code possède une responsabilité claire, reflétée
par son nom, et non partagée
– Les données et les traitements associés sont définis dans la même
unité, qui est responsable de l'intégrité de ses données: les
données sont privées
– Séparer affichage et gestion des données
– Structurer en s'appuyant sur le monde réel
– En OO, le nom de la classe reflète la nature des objets
– …
• Pratique 2- Limitation des dépendances:
– Eviter la redondance de données:
• par l'utilisation des attributs calculés
– Pas de dépendance directe sur les données
© D. Ribouchon

§1 – … 133

Fin
Prise en main
© D. Ribouchon

§1 134

67
 Plan du cours
Déclinaison SI

• Introduction
• Prise en main: COO UML/POO et processus de développement
• Spécifier les exigences du système
– Comprendre le métier
– Spécifier les exigences
• Concevoir le système
– Définir la plateforme technique
– Concevoir le code source
– Concevoir les composants déployables
• Pour aller plus loin
© D. Ribouchon

§1 135

Spécifier les exigences

dans le Processus Unifié

"Besoins utilisateur"

Modélisation du
Déploiement
métier

Vision utilisateur, Tests système

Exigences
("de qualification")
externe

Vision développeur,
Tests
interne Conception
d'intégration

Implémentation
© D. Ribouchon

§1 136

68
 Plan du cours
Déclinaison système embarqué

• Introduction
• Prise en main: COO UML/POO, processus de développement

• Exigences du système embarqué

• Conception du système embarqué

• Conception du logiciel

• Pour aller plus loin

© D. Ribouchon

§1 137

Spécifier les exigences du système embarqué

Besoins utilisateur
Ingénierie du
Système
"englobant"

Exigences Qualification
du système du système
embarqué embarqué

Conception Intégration
du système du système
embarqué embarqué

Conception Intégration
du logiciel du logiciel

Implémentation
© D. Ribouchon

du logiciel

§1 138

69