Plan

• Cours 1
Méthodologie objet Introduction
Présentation d’UML
Modèle fonctionnel (utilisation)
Modèle structurel (1)
• Cours 2
UML et RUP : un survol Modèle structurel (2)
Modèle dynamique (1)
• Cours 3
Modèle dynamique (2)
T. Libourel Modèle d’implémentation
Projection vers les Bases de Données
libourel@lirmm.fr
• Cours 4
M Huchard Projection vers la programmation
huchard@lirmm.fr Méthodologie (RUP)

Plan Introduction

• Cours 1 Modélisation
Introduction
Présentation d’UML
Modèle fonctionnel (utilisation) Produire une représentation simplifiée du monde
Modèle structurel (1) réel pour :
• accumuler et organiser des connaissances,
• décrire un problème,
• trouver et exprimer une solution,
• raisonner, calculer.

1
Introduction Introduction
Difficultés de la modélisation

En informatique, Problèmes des spécifications

Résoudre le hiatus entre : „ parfois imprécises, incomplètes, ou incohérentes

Taille et complexité des systèmes importantes et croissantes

„ les besoins et les fonctionnalités augmentent
le réel le monde informatique „ la technologie évolue rapidement

„ les architectures se diversifient

• Évolutif • Langages codifiés „ assurer l’interface avec le métier (domaine d’application)

• Ambiguïté • Sémantique unique

Introduction
Introduction
Difficultés de la modélisation
Les méthodes = des guides structurants
Évolution des applications
„ évolution des besoins des utilisateurs • Décomposition du travail
„ réorientation de l'application
• Organisation des phases
„ évolution de l'environnement technique (matériel et

logiciel) • Concepts fondateurs

Problèmes liés à la gestion des équipes
„ taille croissante des équipes
• Représentations semi-formelles
„ spécialisation technique

„ spécialisation métier
Assurent une démarche reproductible
pour obtenir des résultats fiables

2
Introduction Introduction

Décomposition du travail Organisation du travail

• Phases
• Processus de développement
analyse, conception, codage, validation, etc.
Phases séquentielles
• Niveaux d’abstraction
Itération sur les phases
conceptuel (besoins)
logique (solution informatique abstraite)
physique (solution informatique concrète)

Introduction Introduction

Concepts fondateurs Représentations semi-formelles

• Représentations partiellement codifiées basées

• Fondent l’approche du problème et sur les concepts fondateurs
l’expression de la solution diagrammes, formulaires, etc.
Classe, signal, état, fonction, etc.
• Support de différentes activités

réflexion, spécification, communication,

documentation, mémorisation (trace)

3
Introduction Plan

Pour résumer … • Cours 1

Une méthode d’analyse et de conception Introduction
„ propose une démarche qui distingue les étapes du
Présentation d’UML
Modèle fonctionnel (utilisation)
développement dans le cycle de vie du logiciel
Modèle structurel (1)
(modularité, réduction de la complexité, réutilisabilité
éventuelle, abstraction)
„ s’appuie sur un formalisme de représentation qui facilite

la communication, l’organisation et la vérification

Le langage de modélisation
„ produit des documents (modèles) qui facilitent les retours
sur conception et l’évolution des applications

UML - Unified Modeling Language UML = Bénéficier des qualités

• Langage de modélisation véhiculant en particulier
les concepts des approches par objets
classe, instance, classification, etc.
mais intégrant d’autres aspects
associations, fonctionnalités, événements,
états, séquences, etc.
des approches par objets
• Simplicité
• Facilité pour coder et réutiliser
• Modèle plus proche de la réalité
– description plus précise des combinaisons
(données, opérations)
– décomposition basée sur “classification naturelle”
– facile à comprendre et à maintenir
• Stabilité
– de petites évolutions peuvent être prises en compte
sans changements massifs

4
La portée d’UML s’explique par
l’importance de l’approche par objets
Omniprésence technique de l’Objet
dans les langages de programmation, les bases de
données, les interfaces graphiques, ... et les méthodes
d’analyse et de conception.
Universalité de l’Objet
la notion d’objet, plus proche du monde réel,
est compréhensible par tous et facilite la communication
entre tous les intervenants d’un projet.
Genèse d’UML
Au début des années 90, une cinquantaine de méthodes objet,
liées uniquement par un consensus autour d’idées communes
(objets, classes, sous-systèmes, ...)
Recherche d’un langage commun unique utilisable par toute
méthode objet
„ dans toutes les phases du cycle de vie,
„ compatible avec les techniques de réalisation actuelles.

UML (Unified Modeling Language) Définition en cours UML 2.0

Version béta - fin 99 UML 1.3

UML
Version intermédiaire non publiée

Commentaires du public
OMG UML 1.2
Standardisation à l’OMG - Novembre 97 UML 1.1

Soumission à l’OMG - Janvier 97 UML 1.0

OOPSLA
Juin 96 puis OOPSLA’96 UML 0.9 & 0.91
Autres
OOPSLA’95 Unified Method 0.8

OOD (Booch) OMT (Rumbaugh) Booch’93 OMT-2

OOSE (Jacobson)

Autres méthodesBooch’91 OMT-1 OOSE Partenaires

5
 Concepts généraux Concepts généraux
Quatre modèles pour concrétiser ces points de vue
Points de vue sur le système Modèle structurel
Types d'objets
et leurs relations
Vue
structurelle Vue
implémentation
Modèle Implémentation
Vue Modèle d’utilisation
Composants
Cas d’utilisation Fonctionnalités Fichiers BD
Vue Vue Projection sur le
dynamique architecture matériel
(déploiement) Modèle Dynamique
Stimuli des objets
<------- Logique Physique ------> et leurs réponses

Concepts généraux
Concepts généraux

Chaque modèle est une représentation abstraite Diagrammes (représentations graphiques de modèles)
d ’une réalité, il fournit une image simplifiée du Diagrammes
Diagrammes
monde réel selon un point de vue. de collaboration
de classes de séquences
Il permet : d’instances d'états, d’activités

- de comprendre et visualiser (en réduisant la complexité)

Diagrammes Diagrammes
- de communiquer (à partir d’un « langage » commun
à travers un nombre restreint de concepts) de cas d’utilisation de déploiement
de composants
- de valider (contrôle de la cohérence, simuler, tester …)

6
Concepts généraux Aspects du langage
Les diagrammes sont majoritairement des graphes
Démarche uniforme sur le cycle de vie
Même notation Noeuds
Arcs

noms, étiquettes,
Chaînes de caractères
Analyse Conception Implémentation mots clefs << interface >>

Contraintes Texte libre, lge prog. OCL, etc.

Notes

Plan
Modèle d’utilisation

• Cours 1 Les cas d’utilisation, ou « USE CASE »

Introduction
Présentation d’UML
Modèle fonctionnel (utilisation) • Fonctionnalités externes
Modèle structurel (1) • Modèles descriptifs du point de vue des utilisateurs
• Interactions avec les acteurs extérieurs

la manière d’utiliser le système

7
 Modèle d’utilisation
Modèle d’utilisation
On part de l’analyse des besoins ….
Deux concepts Acteur (rôle 2)

Deux concepts « communicate »

Acteur Acteur (rôle 1)
Acteur
toute entité extérieure au système et interagissant avec celui-ci.
acteurs humains, acteurs « machine » (système extérieur « communicate »
communiquant avec le système étudié) << actor >>
Cas d’utilisation role
toute manière d’utiliser le système
suite d’événements notable du point de vue de l ’utilisateur Cas d’utilisation

Modèle d’utilisation
Modèle d’utilisation
Acteur (rôle 2)

Acteur (rôle 1) Diagramme du « contexte statique »

0..1 0..*
« include » Acteur (rôle 2)
« extend » Acteur (rôle 1)
association
système
Les cas d ’utilisation peuvent être liés par des relations :
0..1
- d’utilisation « include » (le cas origine contient obligatoirement l’autre)
<< actor >>
- de raffinement « extend » (le cas origine peut être ajouté optionnellement )
- de généralisation/spécialisation « generalizes » role

8
Modèle d’utilisation Modèle d’utilisation

Commander
extension Commander
« include » « include » « include » « include »
« extend »
Décrire Procéder au Décrire Procéder au
Client produits paiement Client produits paiement
Demande
catalogue « specializes »

Paiement CB Paiement cash

Livraison
Gestionnaire
Du stock

Modèle d’utilisation
Modèle d’utilisation
Descriptions complémentaires
Délimiter le système
Textes, diagramme de séquences ou d’activités
- ce qui est extérieur et qui communique avec le
système Une proposition courante
- ce qui est interne au système 9 Sommaire d’identification
9 Titre, résumé, acteurs, dates création maj, version, auteurs
Définir les fonctionnalités du système du point de vue des 9 Description des enchaînements
utilisateurs 9 Pré-conditions, scénario nominal, alternatives, exceptions,
post-conditions
9 Besoins IHM
Donner une description cohérente de toutes les vues que
l’on peut avoir du système 9 Contraintes non fonctionnelles
9 Temps de réponse, concurrence, ressources machine, etc.

9
Plan
Modèle structurel

En UML, le modèle structurel ou statique est décrit à l'aide de

• Cours 1
Introduction deux sortes de diagrammes
Présentation d’UML „ Diagrammes de classes
Modèle fonctionnel (utilisation) (description de tout ou d'une partie du système d'une
Modèle structurel (1) manière abstraite, en termes de classes, de structure et
d'associations).
„ Diagrammes d'objets

(description d'exemples de configuration de tout ou

partie du système, en termes d'objets, de valeurs et de
liens).

Modèle structurel
Modèle structurel

Les objets Objet

Objets du monde réel Objets informatiques Etat ---> évolue au cours du temps

Comportement ---> actions et réactions

Comportement Identité ----> essence
visible
État Interne
caché
Comportement influe sur l'état
Etat reflète les comportements passés

10
Modèle structurel Modèle structurel

BD Deux objets Première abstraction

ou instances

Luc Une classe peut être vue comme

Système - la description en intension d'un groupe d'objets ayant

Alain • même structure (même ensemble d'attributs),

• même comportement (mêmes opérations),
: Discipline
Sophie • une sémantique commune.
- la « génitrice » des objets ou instances
: Professeur
- le « conteneur » (extension) de toutes ses instances

Modèle structurel Modèle structurel

Classe et Attributs (propriétés)
Classe Instance [Visibilité] nom [[multiplicité]][:type][=valeur initiale][{propriétés}]
Attributs (propriétés) Valeurs d'attributs (État)
[0..1]
+ - ~ # Nom de constant
[n] classe,
Voiture titine :Voiture addOnly
[2..*] expression

type : string « Est-instance-de » type =205 Couleur

Peugeot Voiture
marque : string
couleur : string rouge
type : String {changeable}
marque : String blanc:Couleur
couleur[1..*]: Couleur = blanc

11
Modèle structurel Modèle structurel

Classe Classe Instance

Instance
Attributs de classe Valeurs d'attributs (État) Attributs dérivés Valeurs d'attributs (État)
Sauf des attributs de classe

Voiture titine :Voiture Personne julie:Personne

type : string « Est-instance-de » type =205 « Est-instance-de » 08/05/88

marque : string Peugeot dateNaissance : String 15
couleur : string rouge /age : int
nbrRoues : int =4 {cst}

Attribut de classe ~ caractéristique partagée {age = date du jour – date de naissance}

Révèle souvent une modélisation à approfondir Peut-être une opération déguisée ? (stockage optionnel)

Modèle structurel Modèle structurel

Classe, opérations, méthodes

Opérations et méthodes [Visibilité] nom [(paramètres)][:type retour][{propriétés}]

nom de la
classe
+ - ~ # query
[mode] param : type [=valeur défaut]
Voiture attributs abstract
mode = in (par défaut), out, in/out

type : string Couleur

marque : string Voiture
couleur : string opérations
Implémentations
repeindre(c: Couleur)
déplacer(d : longueur) Méthodes repeindre(in c: Couleur=blanc) blanc:Couleur
déplacer(in d : longueur)
Des attributs complémentaires peuvent être nécessaires getCouleur():Couleur{query}

12
Modèle structurel Modèle structurel
Opérations et méthodes de classe Opérations et méthodes de classe

Date Produit
jour:int Référence : String
mois:int PrixHT : float
annee:int TauxTVA : float
nomDesMois[12]:String={« janvier », « fevrier » ..}

getJour():int setPrixHT(f:float)
……… affichePrix()
getFormatEtendu():String ……..
…….. fixeTauxTVA(f:float)
getNomMois(in i:int)

Opération/méthode de classe Opération/méthode de classe

Elle ne s’applique pas à une instance Elle ne s’applique pas à une instance

Modèle structurel Modèle structurel

Association / Lien
(analogie Classe / Instance)
Un objet est instance (propre) d'une classe :
„ il se conforme à la description que celle-ci fournit,

„ il admet une valeur pour chaque attribut déclaré à son

attention dans la classe, Pays a-pour-capitale Ville
„ il est possible de lui appliquer toute opération définie à
son attention dans la classe. nom nom
Association
Tout objet admet une identité qui le distingue pleinement des
autres objets :
„ il peut être nommé et être référencé par un nom (mais
a-pour-capitale
son identité ne se limite pas à ça). : Pays :Ville
nom=France nom = Paris
Lien

13
Modèle structurel Modèle structurel
Association en général binaire (degré = 2) mais ..

Association / Lien
(analogie Classe / Instance) nom d'association

emprunte
Adhérent Exemplaire
Une association est l’abstraction d’un groupe de liens
dont les caractéristiques sont communes
lire
• même type d’origine
• même type de destination association ternaire
association
• même attributs
binaire
DispositifDeLecture

Modèle structurel Modèle structurel

Multiplicités et rôles dans une association Multiplicité et rôles d'une association

employeur employé
A assoc n Société emploie 1..* Personne
B *

rb nom nom
travaille-pour date de nais. chef
adresse
n°SS 0..1
adresse

encadre
travailleur 1..*
- n instances de B peuvent être en relation avec une instance
fixée de A
- une instance de B joue le rôle rb pour une instance de A dans le
contexte de assoc

14
Modèle structurel Modèle structurel
Multiplicité
exactement 1 Conseils pour la modélisation d'association
1
Classe
0..1 au plus 1
Classe
- verbes candidats possibles
0..* aucun, 1 ou plusieurs (défaut)
Classe
1..* - ne pas "dériver vers la conception"
au moins 1 (pointeurs ou attributs référentiels)
Classe

2..4 de 2 à 4
Classe

Classe 2,4
2 ou 4

Modèle structurel Modèle structurel

Classe association

1..*
Voiture Couleur
Possède-des-
Entreprise actions Personne
* 1..*
type : String {changeable}
marque : String nom capital actionnaire nom
adresse date de nais.
adresse

Ligne de
Un attribut à valeur multiple est souvent référentiel portefeuille
quantité

15
Modèle structurel Modèle structurel
Classe association Classe d’association

Autorisé sur Une classe d'association permet de modéliser une

Utilisateur 1..* 1..* Station de travail association par une classe, donc de disposer d’attributs et
d’opérations spécifiques.
nom nom Les liens d'une telle association sont alors des objets
instances de cette classe.
Autorisation À ce titre, ils admettent une valeur pour tout attribut déclaré
priorité dans la classe d'association ; et on peut leur appliquer toute
droits opération définie dans celle-ci.
En tant que classe, une classe d'association peut à son tour
1..* répertoire de rattachement
être associée à d'autres classes (voire à elle-même par une
association réflexive).
Répertoire

Modèle structurel
Plan
Association qualifiée
est_client
Banque 1..* 1..* Personne
• Cours 2
Modèle structurel (2)
Dossier_C Modèle dynamique (1)

num_client

est_client
Banque Personne
num_client
1..* 0..1

16
 Modèle structurel
Modèle structurel
Composition
D ’autres « abstractions » Association particulière Tout /partie
Palmier
associations particulières
(composition / agrégation)
0..2

Couronne Stipe Racine

spécialisation / généralisation

0..* 0..1
Régime
Feuille
Inflorescence
0..1

Modèle structurel Modèle structurel

Agrégation Composition / Agrégation

Sémantique Collection/Élément
Pays
Contraintes
1

Forêt - Exclusivité / Partage

1 1..n

Région - Dépendance / Indépendance

1..n 1
Propagation / Diffusion
Arbre
1..n

Site

17
Modèle structurel Modèle structurel
Généralisation / Spécialisation Généralisation / Spécialisation
Personne
Mécanismes d’inférences intellectuelles de
caractéristiques nom
adresse
„ Soit on affine (spécialisation)

„ Soit on abstrait (généralisation)

{disjoint}

Sémantique Gestionnaire Chercheur

„ Point de vue ensembliste grade
num
adresse
„ Point de vue logique adresse
Exposer()

Modèle structurel Modèle structurel

Généralisation / Spécialisation Généralisation / Spécialisation multiple

Équipement Véhicule
Type d'équipement

Pompe Échangeur ... Réservoir

Véhicule aquatique
Véhicule terrestre
Type de pompe
Type de réservoir

Pompe Cent. Pompe Imm. ... Réservoir Press. ...

Auto Véhicule amphibie Bateau

18
 Modèle structurel
Modèle structurel
Composition/Agrégation ou généralisation ? Généralisation / Spécialisation
Une sous-classe “hérite” des descriptions de
Agrégation
sa super-classe :
„ lien entre instances
„ les déclarations d'attributs,
„ un arbre d'agrégation est composé
„ les définitions d'opérations,
d'objets qui sont parties d'un objet
„ les associations définies sur la super-classe,
composite
„ les contraintes (on en parle plus tard).
Généralisation
Une sous-classe peut redéfinir de façon plus
„ lien entre classes
spécialisée une partie ou la totalité de la
description « héritée ».

Modèle structurel Modèle structurel

Les contraintes Les contraintes

Les contraintes sont des prédicats, pouvant porter sur Exemples de contraintes sur associations
plusieurs éléments du modèle statique, qui doivent être
vérifiés à tout instant.
membreDe
Les contraintes permettent de rendre compte de détails à SOL
* *
un niveau de granularité très fin dans un diagramme de Personne {subset} Comité
classe. Elles peuvent exprimer des conditions ou des 1 préside *
restrictions.
En UML, les contraintes sont exprimées sous forme 1..* {ordered} contrainte entre
contrainte sur
textuelle, entre accolades et de préférence en OCL (Object Strates extrémité
2 associations
Constraint Language). d'association
Les contraintes sont héritées.

19
Modèle structurel Modèle structurel
Les contraintes Quelques compléments de notation
Exemple de contraintes à différents niveaux
contrainte stéréotype
{ actif = passif } «instance of»
sur classe

subordonné employeur
relation de dépendance
Personne Société
* 1..* 0..1
0..1
<dirige chef actif : Real {value ≥ 0}
passif : Real Un stéréotype est un label qui permet d'apporter
une précision supplémentaire à un élément de
{ Personne.employeur =
Personne.chef.employeur }
contrainte notation (classe, relation, …)
sur attribut
contrainte
sur 2
associations

Modèle structurel
Modèle structurel
Classes abstraites
Opérations abstraites
Une classe abstraite est une classe non
instanciable, c'est à dire qu'elle n'admet pas Une opération abstraite est une opération
d'instances directes. n'admettant pas d'implémentation : au niveau de la
Une classe abstraite est une description d'objets classe dans laquelle est déclarée, on ne peut pas
destinée à être « héritée » par des classes plus dire comment la réaliser.
spécialisées. Les opérations abstraites sont particulièrement
Pour être utile, une classe abstraite doit admettre utiles pour mettre en œuvre le polymorphisme.
des classes descendantes concrètes. Toute classe concrète sous-classe d'une classe
abstraite doit “concrétiser” toutes les opérations
La factorisation optimale des propriétés abstraites de cette dernière.
communes à plusieurs classes par généralisation
nécessite le plus souvent l'utilisation de classes
abstraites.

20
 Modèle structurel Modèle structurel
Classes abstraites Interfaces

classe FormeGéométrique
abstraite
Une interface est une collection d'opérations
centre : Point opération utilisée pour spécifier un service offert par une
abstraite
classe dessiner() classe.
abstraite déplacer(delta : Vecteur) Une interface être vue comme une classe sans
(dessiner() est classe attributs et dont toutes les opérations sont abstraites.
héritée et non concrète
concrétisée) Une interface est destinée à être “réalisée” par une
classe (celle-ci en hérite toutes les descriptions et
Polygone Ellipse concrétise les opérations abstraites).
régulier : Boolean grandDiam : Vecteur Une interface peut en spécialiser une autre, et
petitDiam : Vecteur intervenir dans des associations avec d'autres
Polygone opération
utile que si dessiner()
concrétisée
interfaces et d'autres classes.
spécialisée

Modèle structurel Modèle structurel

Interfaces
Interfaces
Deux notations pour l'utilisation d'une interface
«interface» interface
opérations «interface»
abstraites BlocDeChoix réalise
1..* BlocDeChoix
setDefault(o : Option)
getChoice() : Option
Option «uses» setDefault(o : Option) MenuPopUp
choix
String getChoice() : Option
réalisation
1..* choix opérations ApplicationFenêtrée
concrétisées
utilisation
MenuPopUp MenuBouton classe utilisatrice interface
setDefault(o : String) setDefault(o : Bouton) 1..*
getChoice() : String getChoice() : Bouton
Bouton
choix «uses»
ApplicationFenêtrée MenuPopUp
BlocDeChoix

21
Modèle structurel Plan

Heuristiques d’élaboration du modèle structurel

• Bien comprendre le problème

• Faire simple
• Cours 2
• Bien choisir les noms Modèle structurel (2)
• Bien expliciter les associations Modèle dynamique (1)
• Ne pas trop “généraliser”
• Relire
• Documenter

De nombreuses révisions sont nécessaires !

Modèle dynamique Modèle dynamique

Décrit les interactions entre objets diagrammes de collaboration

et les changements au cours du temps

diagrammes de séquences
- Aspects temporels, comportementaux : Contrôle

- Stimuli des objets et leurs réponses

diagrammes états-transitions

diagrammes d'activités (non traités)

22
Modèle dynamique Modèle dynamique
La communication Les messages
Systèmes informatiques : Société d'objets travaillant en
synergie pour réaliser les fonctions de l'application Types Synchronisation
simple
constructeurs
destructeurs
Communication synchrone
sélecteurs
Client dérobant
modificateurs
itérateurs
Acteur minuté
Serveur asynchrone
message

Modèle dynamique Modèle dynamique

Diagramme de collaboration Diagramme de séquence

A B C
M1
2: M2
1: M1 B M2
5: M5
A 4: M4 M3

C 6: M6 M4
message 3: M3 M5
M6

23
Modèle dynamique Modèle dynamique
La ligne de vie
« create »
:C1 :Palmier :Feuille :Inflorescence :Régime
op
Création par le message «create»

temps
Activation de l’objet qui
exécute une opération op

« destroy »

Destruction par un autre objet

Modèle dynamique
Modèle dynamique

Événement et État Diagrammes d'États

Représentation graphique état et événement

État d'un objet

• Graphe
„ valeurs de ses attributs et de ses liens
„ au cours du temps un objet peut changer d'état Nœud État
Arc Transition nommées par événement
Événement
„ stimuli d'un objet vers un autre objet • Une séquence d'événements = chemin dans le graphe

24
Modèle dynamique Modèle dynamique
Événement
État
• pas de durée

• concurrence d'événements • abstraction des valeurs d'attributs et de liens d'un objet

• classes d'événements • un état a une durée (intervalle de temps entre deux événements)
- sans attributs • spécifie la réponse à un événement
- avec attributs • état et événement sont duaux
départ vol (compagnie, num_vol, ville)
a pour instances un événement sépare deux états
AirFrance vol 124 de Paris un état sépare deux événements
Alitalia vol 352 de Rome

Modèle dynamique
Modèle dynamique
Diagrammes d'États
Transitions gardées
création
e2 demande création fermeture fermeture accomplie
Créé Avec inflorescence
Avec feuille en création Ouvert Fermé
e1
[C] retrait (s) dépôt(s)

[Solde >0] [Solde >0]

Créditeur
En retrait En dépôt
Avec régime

[Solde ≤0] [Solde ≤0]

Débiteur

25
 Modèle dynamique
Modèle dynamique
Opération
elle peut être attachée à une transition ou à un état.
Opération elle est exécutée en réponse à l'événement ou à l'état.
Activité / Action
Action
opération instantanée, non interruptible,
souvent utilisée pour faire des mises à jour de valeurs,
Événement 1 [Cond1] / Action1 attachée à une transition.
État 1 (attrib) État 2
faire : Activité 1 ... Envoyer un événement est une action

Activité
opération qui prend du temps, interruptible par un événement,
perpétuelle ou finie,
nécessairement attachée à un état.

Modèle dynamique Modèle dynamique

Généralisation Agrégation

- permet une meilleure structuration des diagrammes d'états une classe "agrégat" aura un état défini par l'agrégation des états
de ses composants.
Un objet dans un état du diagramme général doit
être dans un des états du diagramme imbriqué Agrégation concurrente (relation et)
(relation ou entre les états)
E1 Ecomp1 Ecomp2

E3 E4
E2

E5 E6

26
 Modèle dynamique
Modèle d’implémentation
Les packages
Heuristiques d’élaboration du modèle dynamique

• Utiliser les scénarios pour commencer à construire
les diagrammes d'état
• Ne construire un diagramme d'état que pour les classes
au comportement temporel significatif
• Contrôler la cohérence
• Utiliser des diagrammes structurés
Un package ou sous-système est un regroupement
logique de classes, associations, contraintes ..
Un sous-système est généralement défini par les
services qu’il rend
Les liens entre sous-systèmes sont des liens de
dépendance
Les « packages » servent à structurer une application
Ils sont utilisés dans certains LPO (Java) ce qui assure
une bonne « traçabilité » de l ’analyse à
l ’implémentation

Modèle d’implémentation Plan

Les packages

n ce
nda
épe
ns de d • Cours 3
Lie
Modèle dynamique (2)
Modèle d’implémentation
Projection vers les Bases de Données

Classes avec fort couplage

« sémantique »

27
Du modèle objet ... aux BD Du modèle objet ... aux BD

Adéquation aux BD « objet » Adéquation aux BD « objet »

Persistance LDD, LMD, L Hôte

• Classes vs Types
persistants vs éphémères • LDD, LMD, L Hôte équivalents LPO
• Points d’entrée (racine de persistance) • Langage de requête « like » SQL

• Regroupements • Transactions

Du modèle objet ... aux BD Du modèle objet ... aux BD

Adéquation aux BD « classiques » Classes ADRESSE

N°
Traduction Schéma relationnel Rue
CP
Ville
Attributs
comme précédemment Ajout de l’identifiant
d. structurels --> schémas
d. dynamiques --> requêtes et Schéma Adresse
Attribut Domaine Non Null
traitements applicatifs divers Clé primaire
Id_adresse
Id_adresse Identifiant Oui
N° Entier Non
Mais règles de « passage » Rue String(30) Non
…..

28
 Du modèle objet ... aux BD Du modèle objet ... aux BD

Classes PERSONNE
Associations
NSS {unique}
Schéma relationnel Nom PERSONNE ADRESSE
Prénom
Date-naissance NSS 1 a 1 N°
Rue
Attributs ....
CP
Ajout de l’identifiant Ville

Schéma Personne
Attribut Domaine Non Null Schéma Personne Attribut Domaine Non Null
Clé primaire
Clés primaires
candidates
Id_Pers Identifiant Oui NSS NSS String(13) ID Oui
Id_adresse NSS String(13) Oui Nom String(35) Oui
Clé étrangère
NSS Prénom String(30) Non Id_adresse Id_adresse Identifiant Oui
Date-nais Date Non
On préfère NSS

Du modèle objet ... aux BD Du modèle objet ... aux BD

Associations
Associations
PERSONNE BIBLIOTHEQUE

PERSONNE COMPTE NSS 0..* adhère-> 0..* nom

....
NSS 1 possède 0..* N°
.... Type
date adhésion
type adhésion (mensuelle, annuelle)

Schéma Compte Attribut Domaine Non Null Schéma Adhère Attribut Domaine Non Null
Clé primaire Clé primaire
Id-compte NSS NSS Id String(13) Oui
N° Id_compte Identifiant Oui Id_bibliothèque Id_bibliothèque Identifiant Oui
On choisit N° N° String(35) Id Oui
Rque : Date_adhésion Date Oui
NSS Identifiant Oui Type_adhésion String(10) Oui
Clé étrangère Date
NSS Type

29
 Du modèle objet ... aux BD Plan

Spécialisation Plusieurs choix

PERSONNE - « aplatir vers le haut »

NSS
....
Schéma Personne • Cours 4
Clé primaire Projection vers la programmation
NSS
Méthodologie (RUP)
- « aplatir vers le bas » Patrons de conception
Schémas Etudiant, Enseignant
ETUDIANT ENSEIGNANT Clé primaire
num
NSS
grade
....
....
- conserver les niveaux

Du modèle objet ... à la programmation Du modèle objet ... à la programmation

Classes
Classes
note (peut contenir un
complément de Proposer un service et réagir aux messages
description, un
commentaire, …)
adhérent de la
valeurs
bibliothèque Attributs, Opérations ------> Champs, Méthodes
multiples
Adhérent Et des méthodes particulières spécifiques à certains
privé valeur initiale langages …
- adresse : String = 'adresse inconnue'
- numeroINSEE[6] : Integer
protégé
type d'attribut Accesseurs L/E (convention get/set en Java)
# changeAdresse(nouvelleAdresse : String)
+ cotisationAJour() : Boolean Constructeurs (Java, C++), Destructeurs (C++)
type de
public type du résultat paramètre
de l'opération

30
 Classe Adhérent en Java (extrait) Classe Adhérent en C++ (extrait)
public class Adherent //………. Adherent.h ……………………………………………………
{ Champs class Adherent
private String adr = ``adresse inconnue``; {
private int[] numeroInsee; private:
Constructeurs string adr; Champs
public Adherent(){numeroInsee=new int[6];} int* numeroInsee;
public Adherent(String na, int[] ni){adr=na; numeroInsee=ni;} public:
Adherent(); Constructeurs
public String getAdr(){return adr;}
Accesseurs Adherent(string na, int* ni);
protected void setAdr(String nouvelleAdresse) virtual ~Adherent(); Destructeurs
{adr=nouvelleAdresse;} virtual string getAdr() const;
public int[] getNumeroInsee(){return numeroInsee;} virtual void setAdr(string nouvelleAdresse); Accesseurs
protected void setNumeroInsee(int[] ni){numeroInsee=ni;} virtual int* getNumeroInsee()const;
Méthodes virtual void setNumeroInsee(int* ni);
public boolean cotisationAjour(){…….} virtual boolean cotisationAjour()const; Méthodes
} };

Classe Adhérent en C++ (extrait) Du modèle objet ... à la programmation

//……………. Adherent.cc …………………………………………………
Retour sur la notion d’encapsulation
Adherent::Adherent()
{adr = ``adresse inconnue``; numeroInsee=new int[6];}
Adherent::Adherent(string na, int* ni)
{adr=na; numeroInsee=ni;} Objet

Adherent::~Adherent(){delete[] numeroInsee;} Données

string Adherent:: getAdr()const{return adr;} Encapsulation
Messages
void Adherent::setAdr(string nouvelleAdresse)
{adr=nouvelleAdresse;} Opérations
int* Adherent::getNumeroInsee()const{return numeroInsee;}
void Adherent::setNumeroInsee(int* ni){numeroInsee=ni;}
boolean Adherent:: cotisationAjour()const{…….}

31
 Du modèle objet ... à la programmation
Utilité de l’encapsulation
Liste
Du modèle objet ... à la programmation
Encapsulation
Consensuel
GestionPersonnel
privé ... implémentation
public ... spécification

ajoute En pratique

à chaque langage ses particularismes

retire
Smalltalk. attributs privés, méthodes publiques, ...
applique(fct) Java. package, protected, ...
C++. friends, protected,
¾ Confiner les modifs de Liste dans la classe Liste … protection sur le lien d’héritage, ...

Quelle philosophie adopter ?

Du modèle objet ... à la programmation Du modèle objet ... à la programmation

Protection en Java
Variables et méthodes de classe (en Java)
public class Adherent Accessible seulement dans les
{ autres méthodes de la classe Produit
private String adr = ``adresse inconnue``; référence : String
private int[] numeroInsee; prixHT : float
Accessible aussi dans toute tauxTVA : float
méthode du package et
public Adherent(){numeroInsee=new int[6];} dans toute méthode d’une
setPrixHT(f:float)
public Adherent(String na, int[] ni) sous-classe C sur une affichePrix()
{adr=a; numeroInsee=ni;} variable dont le type ……..
public String getAdr(){return adr;} statique est C ou une sous- fixeTauxTVA(f:float)
protected void setAdr(String nouvelleAdresse) classe de C
{adr=nouvelleAdresse;} public class Produit
public int[] getNumeroInsee(){return numeroInsee;} {
protected void setNumeroInsee(int[] ni){numeroInsee=ni;} private static float tauxTVA;
Accessible partout
………..
public boolean cotisationAjour(){…….} public static void fixeTauxTVA(float f){…..}
} }

32
 Du modèle objet ... à la programmation Du modèle objet ... à la programmation
Classes abstraites, méthodes abstraites Traduction des interfaces en Java

abstract public class Figure Spécification de services (sans implémentation)

{ Java
abstract public void dessine();
……..
}
class Figure Héritage par réalisation
{
public: C++
virtual void dessine()const=0;
……..
}

Du modèle objet ... à la programmation Du modèle objet ... à la programmation

Interfaces en Java Interfaces en Java
Ipolygon
interface Ipolygon méthodes abstraites et
interface Ipolygon {float perimeter(); …} publiques (par défaut)
{float perimeter(); …}
Iquadrilateral
interface Iquadrilateral ….
interface Iquadrilateral …. Isquare {static const int sideNb = 4; ….} variables de classe
{static const int sideNb = 4; ….}
publiques et constantes
interface Isquare …. (par défaut)
interface Isquare …. {float getCote(); …..}
{float getCote(); …..}
Square type à implémenter
public class Square implements Isquare
public class Square implements Isquare {public float getCote(){….} ….}
{public float getCote(){….} ….} type de Java
(écriture de code
public class x
public class x {…. public void meth(Isquare i) {…} …..}
générique)
{…. public void meth(Isquare i) {…} …..}

33
 Du modèle objet ... à la programmation Du modèle objet ... à la programmation
Associations Navigabilité dans un seul sens Associations Navigabilité dans les deux sens

PERSONNE ADRESSE PERSONNE COMPTE

nom 1 a 1 N° nom 1 possède 0..n N°

.... Rue .... Type
CP
adr Ville possesseur comptes

class PERSONNE class PERSONNE

Attribut complexe { Utilisation Conteneur {private :
private : string nom;
string nom; du nom de rôle list <COMPTE> comptes;....}
ADRESSE adr;
.... Référence class COMPTE
} {private :
PERSONNE possesseur;....}
rien de spécial dans ADRESSE

Du modèle objet ... à la programmation Du modèle objet ... à la programmation

Associations Classe d’association L’héritage traduit la généralisation/spécialisation
PERSONNE BIBLIOTHEQUE Personne C++
0..n 0..n
nom adhère nom nom class Personne{};
....
adresse class Gestionnaire
: virtual public Personne
date adhésion
type adhésion (mensuelle, annuelle)

Gestionnaire Java
class PERSONNE {private : string nom;....}
class BIBLIOTHEQUE {private : ....} public class Personne{}
num public class Gestionnaire
class ADHESION
{private : adresse extends Personne {}
Réification
PERSONNE adhérent;
BIBLIOTHEQUE biblio;
DATE dateadhésion;
String typeAdhesion; ....}

34
Du modèle objet ... à la programmation Du modèle objet ... à la programmation
Héritage Héritage : adéquation des deux relations
Implémentation de la relation de spécialisation par Flot
l’héritage, quelques problèmes ....
good()
eof()
...
• adéquation des deux relations
FlotLecture FlotEcriture
• représentation et traitement des conflits lire(nbOctets) écrire(blocOctets)
... ...
• spécialisation des attributs

• représentation de la surcharge et du masquage FlotLectureEcriture

• utilisation de l’héritage à des fins d’implémentation ?

Spécialisation multiple (possible en C++, impossible entre classes Java)

Du modèle objet ... à la programmation Du modèle objet ... à la programmation

Adéquation des deux relations (cas de Java) Héritage : adéquation des deux relations (Java)
interface Flot
interface Ipolygon
{float perimeter(); …} héritage multiple
entre interfaces interface FlotLecture interface FlotEcriture
interface Iquadrilateral extends Ipolygon
{static const int sideNb = 4; ….}
classe Flot
interface FlotLectureEcriture
interface Isquare extends Irectangle,Irhombus
{float getCote(); …..}
spécialisation classe FlotLecture classe FlotEcriture

extends
public class Square implements Isquare classe FlotLectureEcriture
implements
{public float getCote(){….} ….}
implémentation Cas de Java : héritage simple pour l’implémentation, multiple pour les interfaces
... côté classes, ...
public class x
les méthodes de FlotLecture et FlotEcriture doivent être réécrites dans FlotLectureEcriture
{…. public void meth(Isquare i) {…} …..}

35
Du modèle objet ... à la programmation Du modèle objet ... à la programmation
Spécialisation/Généralisation .... Spécialisation/Généralisation ....
multiples
Conflit portant sur le nom des propriétés Conflit portant sur les valeurs ou le domaine
d’une propriété
Objet
ObjetNautique
couleur (rouge, vert ...)
zoneNav

Elément de jeu

{zoneNav Bateau EnginPlage {zoneNav

Carte à jouer sup. à 100}
Pion Dé inf. à 10}
couleur (coeur, trèfle, ...) Pedalo
{zoneNav ?}

Il y a clairement deux propriétés Le pédalo n’a qu’une propriété zoneNav, mais quel sera son domaine ?

Du modèle objet ... à la programmation Du modèle objet ... à la programmation

Héritage : spécialisation des attributs
Héritage : représentation et traitement d’un conflit de
nom
Animal Relation

C++ Smalltalk nourriture (végétale, animale, minérale) ensemblesImpliqués > 1

Java

Désignation explicite Donner deux noms pas d’accès possible

Objet::Couleur à couleur d’objet Herbivore
différents RelationBinaire
CarteAJouer::Couleur autre qu’avec “super”
(dans les méthodes) nourriture (végétale)
ensemblesImpliqués = 2

mieux vaut donner

deux noms différents
Aucune représentation, ni en C++, ni en Smalltalk, ni en Java

Seule issue : vérification des contraintes dans les méthodes (surtout accesseurs) ...

36
Du modèle objet ... à la programmation Du modèle objet ... à la programmation
Héritage : redéfinition Java
redéfinition seulement si les signatures
Héritage : surcharge statique et redéfinition sont strictement identiques,
C++
Magnitude redéfinition si les types des paramètres
Surcharge statique <(Magnitude)
sont identiques, le type de retour peut
être spécialisé
coexistence de méthodes de même nom
dans des classes différentes Date Time Magnitude
appel déterminé par le type de la variable (statique) jour heure <(Magnitude)
mois minute
année secondes
Redéfinition Date Time
<(Date) <(Time)
coexistence de méthodes de même nom jour
mois
heure
minute
dans des classes comparables année secondes
appel déterminé par le type de l’objet (dynamique) Java, C++ : on ne peut pas
représenter directement une <(Magnitude) <(Magnitude)
spécialisation des paramètres

cas de surcharge statique cas de redéfinition

Du modèle objet ... à la programmation Du modèle objet ... à la programmation

Héritage : à chacun sa surcharge Héritage : l’utiliser pour des raisons d’implémentation ?
Personne

habiller(Vêtement) Liste
QuiSePorte
habiller(Vêtement, Chaussure) ajoutFin

Bijou Chaussure Vêtement A éviter dans tous les cas ...

Pile même si les livres en sont pleins ...
Princesse
push
habiller(Vêtement, Bijou) pop
top

En Java : correctement interprété comme de la surcharge statique

En C++ : habiller(Vêtement, Bijou) cache les deux autres

37
 Du modèle objet ... à la programmation Du modèle objet ... à la programmation
A partir du modèle dynamique - diagrammes de séquence
Généricité paramétrique jim:Etudiant
En C++ : template
afficheResultats()
template<typename T>
class Pile afficheMoyenneEtMention()
{… push(T element) …}
T
Pile [moyenne<10]
Pile<int> p; afficheModulesObtenus()

T En Java : simulé
public class Etudiant
push(t:T) class Pile {
pop():T {…. push(Object element) ….} public void afficheResultats()
top():T {
Pile p = new Pile(); afficheMoyenneEtMention();
if (getMoyenne()<10)
problèmes : afficheModulesObtenus();
- contrôle des éléments insérés }
- cast des éléments retirés
}

Plan
Du modèle objet ... à la programmation
A partir du modèle dynamique - diagrammes de collaboration

*[i:=0..nbEtudiants-1]:moyenne()
cnam03:Promotion
:Etudiant
• Cours 4
public class Promotion Projection vers la programmation
{ Méthodologie (RUP)
private Vector listeEtudiants; Patrons de conception
……….
public float moyenneGenerale()
{
double mg=0;
for (int i=0; i<listeEtudiants.size(); i++
mg+=((Etudiant)(listeEtudiants.get(i))).moyenne();
return mg/listeEtudiants.size();
}
}

38
 Historique
Méthodologie
Méthode ou Processus de développement • Méthodes cartésiennes

Jackson, SADT, Yourdon

9acteurs nécessaires (qui) • Méthodes systémiques

9grands types d’activités (comment)
9artefacts (quoi)
9organisation du travail (quand)
Merise, Axial, Information Engineering
• Méthodes objet
OOD, HOOD, OMT, OOSE, OOA/OOD,
unifiées dans le RUP (Rational Unified Process)

Concepts généraux Concepts généraux

• Conceptualiser Étapes Résultats
obtenir un énoncé du problème (utilisateurs) Planification Schéma directeur

Analyse des besoins Modèle des besoins

• Analyser
Spécification formelle ou analyse Modèle conceptuel
spécifier le problème
Spécification technique ou conception Modèle logique

• Concevoir Implémentation Modèle physique

une solution informatique Intégration et Tests Rapport de cohérence logique

• Implémenter Validation du système Rapport de conformité

Maintenance et évolution Documentation et trace

réaliser la solution informatique

39
Concepts généraux Modèle de cycle en cascade

Analyse
• Cycles de développement
Conception

- en cascade
Implémentation
- en V
Tests
- en spirale

- tridimensionnel Maintenance

Modèle de cycle en cascade Modèle de cycle en cascade

9Organisation séquentielle des phases du cycle de 9Contre :

vie
9 Retours sur les phases précédentes
difficiles (rupture entre les phases)
9Une phase est structurée en un ensemble d'activités
pouvant s'exécuter en parallèle par plusieurs 9 Visualisation et validation tardive
personnes

9Le passage d'une phase à la suivante ne se fait que Pour :

lorsque les sorties de la première ont été fournies
9 Organisation simple et directe

40
Modèle de cycle en V Modèle de cycle en V
Expression Validation
des besoins des besoins
9Approche descendante dans les phases précédant
Spécification Validation l’implémentation : on décompose le système au fur
fonctionnelle fonctionnelle et à mesure qu’on le construit
Conception Tests du
du système système 9Approche ascendante dans les phases suivantes : on
recompose le système en testant les parties
Conception Tests des
des composants composants
9Hiérarchie de tests : les différents tests provoquent
Implémentation un retour d’information directement sur la phase
permettant de corriger les erreurs.

Modèle de cycle en V Modèle de cycle en spirale

Analyse
9Pour :
Conception Spécifications
9 Décomposition du système en sous-systèmes Besoins
9 Hiérarchie de tests et retours facilités
9 Vérification ascendante

Implémentation Validation
9Contre :
9 Validation en fin de cycle (erreurs d’analyse Tests
coûteuses)

41
Modèle de cycle en spirale
9 Modèle itératif
9 On passe par toutes les phases du cycle de vie
plusieurs fois
9 Modèle incrémental
9 On améliore à chaque passage
9 Un passage peut aussi bien permettre d’évaluer un
nombre réduit de fonctionnalités ou l’organisation
générale du système de façon non détaillée
Modèle de cycle en spirale
9Pour :
9 Réalisation de plusieurs prototypes (versions) avant
la réalisation du système réel (définitif)
9 Validation progressive et précoce
9 Souplesse dans le choix des prototypes
9Contre :
9 Mise en œuvre parfois coûteuse
9 Possibilité de divergence, nombre de prototypes
difficile à déterminer
¾Le RUP est une réponse à ces critiques

RUP (Rational Unified Process) RUP (Rational Unified Process)

Mots-clefs :
RUP
)développement itératif
)développement incrémental
)pilotage par les cas d’utilisation
Objectory OMT BOOCH )centré sur l’architecture
)configurable

42
RUP (Rational Unified Process) RUP (Rational Unified Process)
1- Les grandes activités
1- Les grandes activités
2- La notion d’architecture logicielle
3- L’organisation itérative des activités

Bibliographie Le RUP distingue 9 activités,

• « The RUP, an Introduction » à chacune correspond :
P. Kruchten, Addison-Wesley 2000
des artefacts
• « The unified Software Developement Process »
I. Jacobson, G. Booch, J. Rumbaugh, Addison-Wesley 1999
des métiers
• « Modélisation Objet avec UML »
P.-A. Muller, N. Gaertner, Eyrolles, 2002 9 des outils (cf. site de Rational)

RUP (Rational Unified Process) RUP (Rational Unified Process)

1- Les grandes activités 1- Les grandes activités

activité 1. GESTION DE PROJET activité 2. MODELISATION DE L’ORGANISATION

Plannification modélisation
Allocation des tâches et des responsabilités - de la structure
Allocation des ressources - du fonctionnement
Etude de faisabilité et des risques de l’organisation où le système sera déployé

calendrier des tâches cas d’utilisation de l’organisation

chef de projet (avec scenarii)
concepteur d’organisation

43
RUP (Rational Unified Process)
1- Les grandes activités
activité 3. ANALYSE DES BESOINS
détermination des besoins :
- fonctionnels (ce que l’on attend du système)
- non fonctionnels (fiabilité, temps de réponse,
environnement distribué, etc.)
cas d’utilisation du système à construire
(avec scenarii)
documents descriptifs
conception de l’interface utilisateur
analyste
RUP (Rational Unified Process)
1- Les grandes activités
activité 5. IMPLEMENTATION
Transcription dans un langage de programmation
ou de base de données
Utilisation de composants existants
code
implémenteur, développeur
RUP (Rational Unified Process)
1- Les grandes activités
activité 4. ANALYSE ET CONCEPTION
évoluer depuis la spécification des besoins
jusqu’à une solution informatique
analyse~besoins fonctionnels
conception~intègre aussi les besoins non fonctionnels
diagrammes de classes, paquetages,
sous-systèmes
diagrammes de collaboration, d’états
diagrammes de composants
architecte, concepteur
RUP (Rational Unified Process)
1- Les grandes activités
activité 6. TEST
Estimer
si les besoins sont satisfaits
s’il y a des erreurs/défauts à corriger
Renforcer et stabiliser l’architecture
modèles de test, scripts
concepteur de test, testeur
44
RUP (Rational Unified Process) RUP (Rational Unified Process)
1- Les grandes activités 1- Les grandes activités

activité 6. TEST activité 6. TEST

Différents niveaux de tests Différents types de tests

• unitaires (test d’une classe, d’un module isolément) • Benchmark (sur un ensemble de données type)
• intégration (plusieurs modules ensembles) • Configuration/installation
• validation (les fonctionnalités du système sont • Charge
assurées) • Fiabilité, stress
• recette (souvent contractualisés, avec le client) • Performance

RUP (Rational Unified Process) RUP (Rational Unified Process)

1- Les grandes activités 1- Les grandes activités

activité 7. DEPLOIEMENT activité 8. MAINTENANCE ET EVOLUTION

Distribuer le logiciel dans son environnement Gérer pendant l’avancement du projet l’évolution :
opérationnel des besoins des utilisateurs,
Installation, test du niveau des développeurs,
Formation des utilisateurs de la technologie, etc.
Migration des données
plan de modification
diagrammes de déploiement tous les métiers !
formateur, graphiste, rédacteur de
documentation, testeur, implémenteur
(scripts d’installation)

45
RUP (Rational Unified Process) RUP (Rational Unified Process)
1- Les grandes activités 2- L’architecture logicielle

activité 9. ENVIRONNEMENT
• Analogie avec l’architecture dans le domaine du
Activité de support du développement bâtiment
sélection des outils de travail,
administration système et réseau, • Désigne un ensemble de descriptions de haut
administration BD, niveau (les « plans de construction »)
formation de l’équipe de travail, etc.

doc outils, doc installation

admin. S&R, formateur, admin. BD

RUP (Rational Unified Process) RUP (Rational Unified Process)

2- L’architecture logicielle 2- L’architecture logicielle

Plans de construction
La vue de l’architecte est générale et sert à :
Logique Réalisation
classes/dynamique composants
• contrôler l’intégrité du système
Cas d’utilisation
• identifier les éléments réutilisables use case + scenarii
Processus
Déploiement
• baser le partage du travail scenarii sur composants
composants
concurrence
projetés sur le matériel
distribution
tolérance aux pannes

Orientation des modèles par les cas d’utilisation

46
 RUP (Rational Unified Process) RUP (Rational Unified Process)
2- L’architecture logicielle 3- L’organisation itérative des activités
Une définition de la notion d’architecture

« vue limitée du système permettant de Pour répondre aux problèmes connus du

comprendre : développement en cascade :
• ce qu’il fait
• comment il fonctionne • découverte tardive des défauts
• comment travailler sur une seule partie • intégration difficile des modifications
• comment l’étendre • contrôle temps et coûts délicat
• comment réutiliser certaines parties »

Seules les grandes lignes de chaque diagramme

font partie de l’architecture

RUP (Rational Unified Process) RUP (Rational Unified Process)

3- L’organisation itérative des activités 3- L’organisation itérative des activités

Contrôle de la convergence : instauration de 4 PHASES

Cycle de base
• Chaque phase développe tout ou partie d’un ou plusieurs
cycles
besoins analyse • Des points de contrôle entre les phases permettent de
conception vérifier l’avancement
plannification implémentation
Etude Construction
Elaboration Transition
d’opportunité
évaluation
test déploiement

Def. Projet Plannification version version

objectifs architecture béta courante
risques, bénéfices

47
RUP (Rational Unified Process)
3- L’organisation itérative des activités
A chaque itération
• la plannification est remise à jour et étendue
• les modèles sont approfondis
• un prototype est développé ou augmenté
• on teste (on re-teste parfois …) l’existant
Plan
• Cours 4
Projection vers la programmation
Méthodologie (RUP)
Patrons de conception
RUP (Rational Unified Process)
3- L’organisation itérative des activités
Bénéfices
• résultats concrets précoces et réguliers
• problèmes et évolutions sont intégrés au fur et
à mesure
• meilleure compréhension par les utilisateurs de ce
qu’ils peuvent comprendre -> ils précisent mieux leur
besoin
• la faisabilité est objectivement mesurée, on a des points
de mesure
• tous les métiers sont en permanence sollicités, les
problèmes remontent plus vite
Patrons de conception
Recueillir l’expertise en conception
Définition
Un patron de conception est une solution de conception
générique pour résoudre un problème de conception
récurrent
Micro-architecture d’une application
Analogie avec les plans de construction détaillés d’un
élément de bâtiment
48
Patrons de conception
Un exemple :
Résumé du patron « objets composite »
Problème
Nous désirons représenter des objets qui se décrivent par
une hiérarchie d’objets, avec les deux particularités :
• la hiérarchie est une hiérarchie d’agrégation
• tous les objets jusqu’au plus haut niveau présentent un
même comportement (on peut leur appliquer un même
ensemble de méthodes)
Patrons de conception
Résumé du patron « objets composite »
Exemple 1
Dans un éditeur de dessin, une figure géométrique est
simple ou se compose d’autres figures.
Toutes les figures peuvent être dessinées, déplacées,
effacées, agrandies, etc.
Exemple 2
Dans un système d’exploitation, les fichiers peuvent être
ordinaires, ou bien des liens, ou encore des répertoires qui
contiennent eux-mêmes d’autres fichiers.
Tout fichier peut être déplacé, détruit, renommé, etc.

Patrons de conception Patrons de conception

Résumé du patron « objets composite »
Solution générique [E. Gamma et al. « design patterns », 94] Résumé du patron « objets composite »
version dite « sécurité » Spécialisation du patron
abstraite fils Figure element
si pas de partie Composant
commune + dessine
+ operation + deplace

FigureSimple FigureGroupee
Feuille Composite
+ dessine + dessine
+ operation + operation + deplace + deplace
+ ajout(c:Composant) + ajoute(f:Figure)

appliquer operation
à tous les fils Cercle Carré Trait

49