Processus de Développement Objet

METHODES et
PROCESSUS DE DÉVELOPPEMENT
OBJET
METHODES
-Une méthode de développement de systèmes

logiciels est définie avec :
- un ou plusieurs modèles,
-un ou plusieurs processus de développement,
-et généralement, un ou plusieurs ateliers.
-La mise en œuvre des étapes d’un processus de

développement s’appuie sur un ensemble de
techniques
METHODE TECHNIQUES OUTILS
Méthodes Objets
• Langage de Modélisation
– UML = Standard (OMG)
• Processus
– Plusieurs processus (généralement « Unifiés »)
• Outils
– Modeleur, AGL, plate-forme de développement
• Rational Rose, Power AMC, Enterprise Architect etc.
PROCESSUS DE DÉVELOPPEMENT
• Définition
– Un processus de développement de systèmes

logiciels est un ensemble d’étapes à exécuter selon
un ordonnancement permettant d’analyser, et/ou de
concevoir, et/ou d’implémenter des systèmes
logiciels.
– Un ordonnancement d’étapes peut être en tout ou

partie séquentiel, et/ou parallèle, et/ou itératif.
Processus Unifié
• Processus unifié :
– processus de développement logiciel
ayant les caractéristiques suivantes :
• construit sur UML,
• itératif et incrémental,
• conduit par les cas d’utilisation,
• orienté par les risques.
• centré sur l’architecture du système
– géré à travers 4 phases : pré étude, élaboration, construction et transition.
– contient 6 disciplines fondamentales: Modélisation métier, Besoins, Analyse

et Conception, Implémentation, Test, Déploiement
Processus Unifié
Plusieurs variantes
Cas d’Utilisation Architecture Risques

Orienté par
Centré sur
Conduit par
Construit sur Itératif et

UML Processus Unifié
Incrémental
RUP UPEDU 2TUP 

Processus Unifié
Piloté Par les Cas d’Utilisation (orienté utilisateur)
La spécification, la conception et l’implémentation sont construites à partir

des modes d’utilisation attendus par les acteurs du système.
Processus Unifié
• itératif et incrémental
– Itération
• Une séquence distincte d’activités avec un plan de base et des
critères d’évaluation, qui produit une release (interne ou externe).
• Un itération améliore ou fait évoluer un système et elle peut être

évaluée par les utilisateurs.
– Incrément
• la différence (Delta) entre deux releases produites à la fin de deux
itérations successives
Processus Unifié
Source http://www.entreprise-agile.com/HistoAgile.pdf
Processus Unifié
Source http://www.entreprise-agile.com/HistoAgile.pdf
Processus Unifié
– La définition et l’ordonnancement des itérations sont basés sur
les priorités attachées aux cas d'utilisation et sur l'étude du
risque.
– Une itération comprend en général toutes les disciplines:

• Une planification de l’itération
• Analyse des besoins (raffinement)
• Analyse et conception
• Implémentation et tests
• Évaluation
• Livraison
Processus Unifié
• itératif et incrémental Itération
Processus Unifié
• Orienté par les risques
– Un risque est un événement dont on redoute la survenue dont

l’occurrence est plus ou moins prévisible et peut provoquer des
dommages sur le déroulement du projet.
– Exemples : incapacité de l’architecture technique à répondre aux

contraintes opérationnelles, inadéquation du développement aux
besoins des utilisateurs
– Les causes d’échec les plus importantes d’un projet doivent être
identifiées et écartées en priorité.
– Les risques doivent être pris en compte dans le cahier des charges
Processus Unifié
– Quelques Facteurs de Risques
• Technique/Architectural: technologies incertaines, visibilité partielle, …
• Ressources: ressources humaines (quantité et qualité), compétence,

financement, ressources matérielles, …
• Business: Concurrence, Interfaces avec les fournisseurs, sous-traitants
• Planning: dépendances, …
• Changements d’Exigences
Processus Unifié
– Identifier les Facteurs de Risques
• Un facteur de risque peut entrainer l’apparition de plusieurs

risques
– Développer sans spécification approuvées  Insatisfaction du client +

Surcoût
• Plusieurs facteurs de risques peuvent contribuer à

l’apparition d’un risque:
– Connaissance insuffisante du métier du client + Plan de validation
incomplet + conduite au Changement non prévue  rejet par le client
Processus Unifié
– Analyser les risques
• Evaluer la probabilité d’apparition d’un risque
• Evaluer la gravité des conséquences liées à la survenue d’un risque
Gravité
Probabilité
Processus Unifié

• Actions à Mener: prévoir ou anticiper les situations risquées et définir et
mettre en œuvre un plan d’actions qui se décline en:
– Actions de réduction: réduire l’influence des facteurs de risques (donc

la probabilité)
• Les Technologie utilisées sont bien maitrisées  réduction du risque de non
aboutissement
– Actions préventives: Ne pas se mettre dans une situation (actions sur

le déclenchement des facteurs de risques):
• Faire intervenir pour réduire les risques de rejet
– Actions de couverture: limiter les conséquences des risques:

• Un développement itératif et incrémental pour limiter la prise de risque au niveau
technologique
– Le projet peut être abandonné si les risques sont jugés trop

élevés (NO GO)
Processus Unifié
• Centré sur l’architecture du système.

– A chaque étape de construction du modèle, les décisions
d’architecture doivent être respectées. L’architecture préside à
l’intégrité du projet, elle structure et assure la cohérence des
points de vue (permet la maitrise d’un système complexe),
permet la réutilisabilité.
– Architecture : Ensemble des décisions d’organisation du

système logiciel qui prend en compte les exigences
fonctionnelles, techniques et économiques.
Processus Unifié
– Architecture : Ensemble des décisions d’organisation du

système logiciel qui prend en compte les exigences
fonctionnelles, techniques et économiques.
• Software architecture is not only concerned with structure and behavior, but also with
usage, functionality, performance, resilience, reuse, comprehensibility, economic and
technological constraints and tradeoffs, and esthetics.
• A Technical Architecture is the minimal set of rules governing the arrangement,

interaction, and interdependence of the parts or elements that together may be used
to form an information system.
Processus Unifié
– architectures client/serveur en tiers (2-tiers, 3-tiers ou n-tiers) :

concernent la capacité de montée en charge du système.
• Le style 2-tiers met généralement en jeu des clients et un serveur de base

de données (applications départementales avec un nombre limité
d’utilisateurs).
• Le style 3-tiers ou n-tiers permettent l’évolution du nombre d’utilisateurs en
introduisant un middleware qui distribue les services entre les clients et les
serveurs.
– Architecture en couches : s’intéressent à la distribution des

responsabilités techniques sur les parties développés du système
logiciel. Les architectures en couches améliorent les qualités d’évolution
et de maintenance des aspects techniques du système.
• Une répartition classique est celle suivant cinq couches : présentation,

application, métier, accès aux données et stockage des données.
Processus Unifié

– Les architectures en niveaux : traitent du déploiement des fonctions sur
les postes de travail des utilisateurs. Ces niveaux permettent de mieux
contrôler l’imbrication des fonctions du système, avec comme
conséquence, l’amélioration de ses qualités d’évolution et de
maintenance fonctionnelles.
• Les trois niveaux suivants peuvent être distingués au sein d’une entreprise :
niveaux central, départemental et local.
– Architectures à Base de Composant (ABC): permettent de développer

les opportunités de réutilisation au sein du système informatique. L’ABC
améliore aussi bien les qualités d’évolution et de maintenance que les
coûts de développement du système.
• Ces composants peuvent être développés de façon spécifique ou achetés.
L’ABC impose une forte rigueur dans la décomposition modulaire.
Processus Unifié

– L’architecture joue le rôle de lien pour l’ensemble des membres du
projet en insistant sur la réalisation concrète de prototypes
incrémentaux qui «valident» les décisions prises
– plus le projet avance, plus l’architecture est difficile à modifier : les

risques liés à l’architecture sont très élevés, car très coûteux.
– Objectif pour le projet:

• établir dès la phase d’élaboration des fondations solides et évolutives pour
le système à développer, en favorisant la réutilisation
• l’architecture s’impose à tous, contrôle les développements ultérieurs,

permet de comprendre le système et d’en gérer la complexité
Processus Unifié

– L’architecture doit prévoir la réalisation de tous les cas
d’utilisation.
– Démarche classique :
• Créer une ébauche  grossière de l’architecture.

• Traiter les cas d’utilisation essentiels
• Adapter au besoin l’architecture pour intégrer ces cas d’utilisation
• Sélectionner d’autres cas d’utilisation et reprendre.
Processus Unifié
• 4 Phases: préétude(inception), élaboration, construction et
transition.
– préétude(inception):
• Etablir la porté du projet

• Déterminer les Cas d’utilisation et les scénarios principaux
• Proposer une 1ère architecture risques
• Estimer les coûts et un calendrier prévisionnel
• Identifier les risques et leurs sources
Vision du projet: Glossaire, Détermination des parties prenantes et

des utilisateurs, détermination de leurs besoins (fonctionnels/non
fonctionnels), Contraintes de conception
Processus Unifié

transition.
– préétude(inception)
• évaluation:
– Acceptation des parties prenantes sur la délimitation du champ

d'application
– Accord sur les exigences
– Accord sur les estimations de coût, le planning, les priorités, les risques
et le processus de développement
– Les risques ont été identifiés et une stratégie de gestion du risque a été
définie
Processus Unifié
transition.
– Elaboration:
• Définir et valider l'architecture de base

• Produire les cas d’utilisation principaux (pour couvrir environ 80%
des besoins fonctionnels)
• Définir les niveaux de qualité à atteindre,
• Etablir un plan détaillé pour la phase de construction
• Démontrer que l'architecture de base prend en charge «la vision» à
un coût et dans un délai raisonnables
• Architecture : Document d’architecture Logicielle, Différentes vues
selon la partie prenante, Comportement et conception des
composants du système.
Processus Unifié
transition.
– Elaboration:
• Architecture
– Vues d’architecture
– Buts et contrainte
– Caractéristiques (taille, performances, …)
– Qualité (extensibilité, portabilité, …)
Processus Unifié
transition.
– Elaboration:
• Architecture
– Vues d’architecture
Processus Unifié
transition.
– Elaboration
• Evaluation:
• Vision du système et exigences stables

• Architecture stable
• Risques majeurs étudiés et « résolus »
• Plans d’itération pour la phase de construction assez détaillé
• Entente de tous les intervenants sur le fait que la vision est
réalisable dans le contexte de l’architecture proposée
Processus Unifié
transition.
– Construction:
• Produire un logiciel conforme aux besoins

• Tester le logiciel vs critères d’acceptation établis pendant la pré
étude
• Extension de l’identification/description/réalisation des cas
d’utilisation
• Finalisation Analyse/conception/Implémentation/tests
• Principal livrable: version suffisamment stable pour être déployée
• Evaluation: La version actuelle est-elle assez stable?, les

utilisateurs sont-ils avertis formés etc …
Processus Unifié
transition.
– Transition:
• Recommandations aux clients sur la maj de l’environnement logiciel

• Elaboration des manuels/documentation sur la version courante
• Adaptation de la version actuelle
• Correction des anomalies exhibées lors des béta test
• Livraison du Produits aux utilisateurs
• Evaluation: les utilisateurs sont-ils satisfaits ?

Processus Description Points Forts Points Faibles
 Promu par Rational(IBM). • Itératif • Coûteux à
RUP  Le RUP est à la fois
une méthodologie
• Spécifie le dialogue
entre les différents
personnaliser :
batterie de
et un outil prêt à intervenants du consultants
l’emploi (documents projet : les livrables, • Très axé processus,
Rational types partagés dans les plannings, les au détriment du
un référentiel Web) prototypes… développement : peu
Unified  Cible des projets de • Propose des modèles de de place pour le code
Process plus de 10 personnes documents, et des
canevas pour des
et la technologie
projets types
•Ensemble de • Itératif • Ne couvre pas les
XP « Best Practices »
de développement
• Simple à mettre en
oeuvre
phases en amont et
en aval au
(travail en équipes, • Fait une large place aux développement :
transfert de aspects techniques : capture des besoins,
compétences…) prototypes, règles de support, maintenance,
• Cible des projets de développement, tests… tests d’intégration…
moins de 10 • Innovant: • Elude la phase
eXtreme personnes programmation en duo,
kick-off matinal
d’analyse, si bien
qu’on peut dépenser
Programming debout … son énergie à faire et
défaire
• Assez flou dans sa
mise en oeuvre:
quels intervenants,
quels livrables ?
• S’articule autour de • Itératif • Plutôt superficiel
2TUP l’architecture
• Propose un cycle de
• Fait une large place à
la technologie et à la
sur les phases
situées en amont et
développement en Y gestion du risque en aval du
• Détaillé dans « UML • Définit les profils des développement :
en action » (voir intervenants, les capture des besoins,
Two Track références) livrables, les plannings, support, maintenance,
Unified • Cible des projets de les prototypes gestion du
toutes tailles changement…
Process • Ne propose pas de
documents types
Le processus 2TUP
(Two Track Unified Process)
Le Processus 2TUP
(Two Track Unified Process)
• Processus Unifié
• Couvre :
– L’étude des besoins fonctionnels ;
– L’étude des besoins techniques ;
– La réalisation.
Le processus 2TUP(Two Track Unified Process)
Branche
fonctionnelle: Branche technique:
détermine ce que va prend en compte
réaliser le système en les contraintes du système
terme de métier ( Intégration,
performances, …)
Phase de réalisation:
fusion du modèle d’analyse
dans l’architecture
technique; codage, tests,
déploiement.
 Branche fonctionnelle:
– couvre la capture et l’analyse des besoins fonctionnels du système
à mettre en place.
– définit les fonctionnalités du système d’une manière exhaustive et
précise, en se focalisant sur le métier des utilisateurs
 Branche technique
– couvre la prise en charge des besoins non fonctionnels
(Contraintes)
• d’intégration avec l’existant,
• de développement,
• de performance.
• Etc.
 Branche Réalisation:
 la conception préliminaire
• permet d’intégrer le modèle d’analyse de la branche fonctionnelle dans
l’architecture technique de la branche technique,
 la conception détaillée
• qui développe le modèle d’analyse en vue du codage,
 le codage
 et le test.
CAPTURE DES BESOINS
 Etude Préliminaire
Capture des Besoins Fonctionnels Capture des Besoins Techniques
ANALYSE

Découpage en Catégories ARCHITECTURE
TECHNIQUE
Développement du modèle Statique Conception Générique
Développement du modèle Dynamique
CONCEPTION
 Conception Préliminaire
Conception Détaillée

ETUDE PREALABLE
• Situation et Objectif :
– Toute première étape du processus en Y.
– Elle a pour objet d’effectuer une (première) étude succincte des

besoins fonctionnels et opérationnels.
ETUDE PREALABLE
• Éléments utilisés :
– Acteur ,
– Message,
• communication unidirectionnelle entre objets qui transporte de l’information en vue de
déclencher une activité chez le récepteur,
– Évènement,
– Contexte dynamique,
• Diagramme synthétique qui représente tous les messages système- acteurs. Il se
représente sous la forme d’un diagramme de communication UML avec les
caractéristiques suivantes :
– Le système étudié = boîte noire = participant central ;
– Celui-ci est relié aux acteurs qui sont placés tout autour.
– Sur chaque lien sont montrés des messages en entrée et en sortie du système sans
numérotation. Les messages devront être décrits de façon détaillée sous forme textuelle dans
un document séparé (donnée du message, périodique, synchrone/asynchrone, etc.).
– Contexte statique.
ETUDE PREALABLE
• Éléments produits :
– Un cahier des charges préliminaires (recueil initial des besoins

fonctionnels et opérationnels) :
• Description (essentiellement textuelle) des différents besoins fonctionnels
exprimés ;
• Recueil des besoins opérationnels : sécurité, authentification, volume des
données etc.
– Une modélisation du contexte :

• Identifie les acteurs,
• Répertorie les interactions (émission / réception de messages) entre les
acteurs et le système,
• Représente le tout sous la forme d’un diagramme de contexte dynamique,
• Définit éventuellement un diagramme de contexte statique.
Préétude (interviews,
etc.)
Cahiers des Charges préliminaires

1. Recueil Initial des Besoins
Fonctionnels et Techniques
2. Modélisation du Contexte
Opérateur Administrateur
Chargé d’Etude
: SYST : SYST
valider
DG
DG
Acteurs Diagramme de
Messages
Contexte Statique
Diagramme de
Contexte Dynamique
ETAPE GI : Capture des Besoins
Fonctionnels.
• Situation et Objectif
– C’est la première étape de la branche gauche du

processus.
– Elle a pour objet de formaliser et de détailler la partie

« fonctionnelle » de ce qui a été produit au cours de
l’étude préliminaire.
ETAPE GI : Capture des Besoins Fonctionnels.
• Les éléments utilisés

•
– Messages, Acteurs (principal, secondaires), modèle de contexte
dynamique
– Cas d’Utilisation (CU),
– Description d’un CU (description préliminaire d’un CU, fiche de
description textuelle d’un CU),
– diagramme de CU,
– Scénario,
– diagramme d’activité, diagramme de séquence
– relations du diagramme des CU (extension, inclusion, généralisation
des CU)
– classes candidates, responsabilité,
– diagramme de classes participantes
– traçabilité des CU avec les besoins fonctionnels
• Activités et Eléments produits :
– 1. Identifier les Cas d’utilisation :

• liste préliminaire des cas d’utilisation ainsi q’une description succincte de
ces cas d’utilisation et un diagramme de CU simple.
• technique : partant du diagramme de contexte dynamique, on considère

l’intention fonctionnelle de l’acteur par rapport à chaque message. En
regroupant les intentions fonctionnelles en unité cohérente, on obtient les
C.U
• L’analyse du cahier des charges permet également de déterminer

directement les services fonctionnels attendus
•1. Identifier les Cas d’utilisation (suite) :
Cas d’Utilisation Acteur Principal, Messages émis/reçus par les

Acteurs Secondaires acteurs
émet : m1, m2, …

CU1 Acteur1 (P)
Acteur2 reçoit : m5, m7, m8
….. ……
CU2
… … …
CUn
• 1. Identifier les Cas d’utilisation (fin):

– La description succincte pourra avoir le format suivant :
• Nom du CU (<acteur principal>) :

– Exemple : ouvrir un compte client (Agent Conseil)
– Remarque : Il est conseillé de nommer le CU avec un verbe à l’infinitif suivi d’un
complément et en se plaçant du point de vue de l’acteur et non du point de vue du
système.
• Intention
– exemple : créer un nouveau compte client (ordinaire ou d’épargne)
• Actions
– Saisir les informations identitaires du client, les informations
socioprofessionnelles, générer un nouveau compte, procéder au versement initial
etc
2. Décrire les Cas d’Utilisation.

• Sommaire d’identification (obligatoire) :
– titre, but, résumé, dates, versions, acteurs, responsables
• Description des enchaînements (obligatoire)
• scénarii nominal, alternatifs, d’exception, pré-conditions, post-
conditions)
• Besoins en IHM (optionnel)
– contraintes d’interface H/M : ce qu’il est nécessaire de montrer, en
rapport avec les opérations que l’utilisateur peut déclencher, …
• Exigences non fonctionnelles (optionnel)
• Fréquence, volumétrie, disponibilité, fiabilité, intégrité,
confidentialité, performances, concurrence, etc. Ces contraintes
peuvent servir pour évaluer les contraintes techniques et pour
améliorer/consolider la capture des besoins technique opérée en
parallèle par l’architecte technique.
• 3. Organiser les Cas d’utilisation
– rajouter les relations d’inclusion, d’extension et de

généralisation entre cas d’utilisation ;
– regrouper les CU en paquetages afin de définir des

blocs fonctionnels homogènes de haut niveau.
ETAPE GI : Capture des Besoins Fonctionnels
Cas d’Utilisation Acteurs Paquetage

CU11 Acteur11 P1
… …
Acteur1n
CU1n
CU21 … P2
… …
CUp … Pp
• Chaque paquetage identifié donne lieu à un diagramme

de CU séparé.
• critères de regroupement des CU suivants :
– par domaine d’expertise métier : critère le plus intuitif et

souvent efficace.
– par acteur : intéressant si chaque CU est relié à un seul

acteur ; sinon rejoint le critère précédent ;
– par lot de livraison : en rapport avec le développement itératif

et incrémental, on regroupe dans un même paquetage, les CUs
qui seront délivrés en même temps.
• 4. Identifier les classes candidates.
– définir les concepts clés du domaine d’application (concepts

métiers) ;
– ajouter les concepts « applicatifs » liés à l’informatisation.
– Résultats : Un diagramme « préliminaire » non exhaustif de
classes participantes pour chaque cas d’utilisation.
• Démarche : rechercher les noms communs importants dans les
descriptions textuelles des CU. Vérifier que ces noms peuvent être réifiés
en objets (identité, propriétés, comportement) puis définir les
responsabilités des objets retenus.
• Définition : Une responsabilité est le « contrat » que la classe doit remplir.

Les attributs, les opérations et les associations permettent à la classe de
remplir son contrat qui est d’un niveau d’abstraction plus élévé. Une
classe doit avoir au moins une responsabilité et en nombre réduit (<= 5)
sinon la scinder en plusieurs classes.
• 5. Valider et Consolider.
– Procéder à une révision des CU :
• les frontières du système sont-elles bien définies ?

• les acteurs sont-ils tous pris en compte ?
• chaque cas d’utilisation a-t-il un processus de
déclenchement ?
• le niveau d’homogéneité des CU est t-il homogène ?
• Toutes les fonctionnalités du système sont-elles
traitées ?
• 5. Valider et Consolider (matrice de traçablité).
Exigence1 Exigence2 Exigencen
CU1 Scénario1 × × ×
Scénarion2 × ×
Scénario 3
CU2 Scénario1 × × ×
Scénario1 ×
…
… …
Cas d’Utilisation
Cahiers des
Diagrammes de
Éditer la demande
Charges
Opérateur
analyser la demande
1. Identifier les Cas d’Utilisation

Chargé d’Étude Valider la demande
2. Décrire les Cas d’Utilisation

Fiches de
Description 3. Organiser les Cas d’Utilisation
Éditer la S’authentifier
demande
dynamiques
Diagrammes
4. Identifier les classes candidates

Opérateur
5. Valider et Consolider analyser la

demande
Chargé d’Étude Valider la

demande
Valider la
demande
C2
C1
P1
Diagrammes de
Cas d’Utilisation affinés et consolidés
C3
P2
Diagrammes de classes
participantes
P3 Traçabilité
Packages de Spécification fonctionnelle

ETAPE DI : Capture des Besoins Techniques
• Première étape de la branche gauche (complément de G1).
• Elle a pour objet de formaliser et de détailler la partie « non

fonctionnelle » de ce qui a été produit au cours de l’étude
préliminaire.
• Elle intervient lorsque des informations suffisantes sur les aspects

techniques sont disponibles:
– matériel (machines et réseaux), progiciels à intégrer, outils de

développement retenus.
– A ces éléments s’ajouteront les contraintes non fonctionnelles décrites
par les CU techniques.
• Les éléments utilisés
– diagramme de déploiement, nœud et connexions du réseau,

architecture à 3 niveaux ;
– diagramme de composants, composants d’exploitation,

architecture 3-tiers,
– diagramme de CU, CU technique, organisation en couches

logicielles, architecture en 5 couches,
– spécification logicielle détaillée.

• Activités et Livrables
– 1. Capture des spécifications techniques relatives à la

configuration matérielle
• Identifier les contraintes techniques liées aux machines, aux

connexions et aux déploiements existants ;
• Produire le diagramme de configuration matérielle ;
• Identifier les contraintes d’organisation (modèle de déploiement)
imposées par les choix d’architecture.
Serveur GESCOM Serveur Web
{SE= Linux} {SE= Unix}
« LAN » « LAN »
Client Central (PC)

Serveur Application
« LAN » {SE= WindowXP, nombre < 25}
Central
{SE= Linux, CPU >2}
Firewall Client Agence (PC)

« internet » {SE= WindowXP, nombre <
« LAN »
45}
Serveur Agence
{SE= Linux}
Modèle de configuration matérielle

<<SGBDR>> <<SGBDR>>
BD Agence BD Central
{nombre =4}
<<EJB>> Processus Applicatifs

Composant Metiers {nombre =7}
{nombre =4}
<<connecteur>>
Connecteur EAI
{nombre =4}
<application> Navigateur
AppliCentral {nombre >1}
{nombre >1}
<<progiciel>>
PCOMPTA
Organisation du modèle de déploiement

• Activités et Délivrables (suite)
– 2. Capture initiales des spécifications logicielles :

• Identifier les besoins logiciels du point de vue des exploitants ;
• Donner la description sommaire des cas d’utilisations techniques
• Définition 1 : un exploitant est un acteur (au sens de UML) qui

bénéficie (seulement) des fonctionnalités techniques du système.
• Définition 2 : un cas d’utilisation technique est une séquence

d’actions produisant une valeur ajoutée opérationnelle ou
purement technique (et non pas fonctionnelle).
• Activités et Délivrables (suite)
– 2. Capture initiales des spécifications logicielles :

• Identifier les besoins logiciels du point de vue des
exploitants ;
• Donner la description sommaire des cas d’utilisations
techniques
• Nota : la diffusion des standards techniques (JEE, .NET,

Apache/Struts, PHP etc.) tend à uniformiser les styles de
conception et donc à amoindrir l’intérêt d’une capture des besoins
techniques en terme de spécification logicielles.
Synchroniser les
objets entre applis Utiliser l’aide
Manipuler les
objets
Gérer la distribution
utilisateur
Gérer la
sécurité Gérer l’intégrité
Exemple de Modèle de spécification Logicielle

• exemple de description sommaire des CU Technique:
• CU : Manipuler les Objets
• Intention : l’utilisateur désire gérer un ou plusieurs objets.
• Actions : créer, modifier, supprimer un objet
A3
Découpage en Catégorie
– Branche Gauche
– 1ère activité de l’analyse;
– Organise le modèle en se fondant sur une structuration objet à

travers les classes et les catégorie. Ceci permet de:
• Organiser les équipes d’analystes qui vont pouvoir travailler sur des
sous-ensembles cohérents et faiblement couplés
• Maîtriser la complexité en isolant les mécanismes de détails dans

les catégories
• Assurer l’évolutivité et la maintenance, favoriser la réutilisation en

séparant par exemple, les parties applicatives variables des parties
métiers stables et donc réutilisables.
Diapositive 67
A3 Le découpage en catégorie est très différent du découpage fonctionnel vu précédemment. En effet, on rencontre souvent les cas suivants dans
les classes candidates:
- la même classe candidate participe à plusieurs cas d'utilisation;
des classes candidates de noms différents ont lesmêmes responsabilités et les mêmes collaboration surtout si les CU ont été étudiés par des
personnes différentes;
Administrateur; 15/10/2007
Decoupage en Catégorie
• Éléments Utilisés :
– Catégorie: regroupement logique de classes à
forte cohésion interne et à faible couplage
externe. Concept non UML qui sera
représenté par un package stéréotypé.
– (diagramme de) Package, dépendance,

importation, visibilité, Généralisation,
association, navigabilité, diagramme de
classes par catégorie.
• Activités et Délivrables :
1. Répartir les classes candidates en

catégories
2. Élaborer les diagrammes de classes

préliminaires par catégorie
3. Etablir les dépendances entre les catégories

• Activités et Livrables :
1. Répartir les classes candidates en catégories
- Part des classes identifiés durant la phase précédente
- Se base sur deux principes: Cohérence et Indépendance
- (a) Cohérence : regrouper des classes sémantiquement proches.

Les critères de cohérence sont:
- Finalité: les classes doivent rendre des services de même nature aux
utilisateurs;
- Évolution: isoler les classes stables de celles qui vont (probablement)
évoluer au cours du projet. Ex: Classes métier vs classes
applicatives
- Cycle de vie des objets: distinguer et gérer différemment les classes
dont les instances ont des durées de vie très ≠tes.
- (b) indépendance : minimiser les dépendances entre catégorie
1. Répartir les classes candidates en catégories

- Une catégorie ne doit être :
- Ni trop grosse: trop de responsabilité, difficile à
maîtriser (moins de 10 classes);
- Ni trop maigre: peu de responsabilité, risque de
couplages multiples
• 2. Développer le diagramme de classe pour chaque
catégorie
– On définit les associations entre les classes :
• 3. Etablir les dépendances entre catégories
– Dépendances déduites des relations entre classes;

– Éviter les dépendances mutuelles
– À l’inverse, les dépendances entre catégories peuvent guider le
choix de navigabilité des associations
– Les dépendances entre catégories ne sont pas transitives
P1
C2 Diagrammes des classes
P2 C1 participantes
P3
C3
Package des C.U.
1. Répartir les classes candidates

en Catégories P1
P2 Catégories
2. Élaborer les diagrammes de
P3
classes préliminaires/catégorie
3. Décider des Dépendances entre

catégorie
C2
P1 C1
C3
P2
P3
Diagrammes de
Classes d’analyse par catégorie
Diagrammes de
Packages d’Analyse
Développement du Modèle
Statique
• Situation et Objectif
– Branche Gauche, Phase d’Analyse, succède
au découpage en Catégories;
– Objectif: Détailler, compléter et optimiser les
diagrammes de classes de l’étapes
précédente
Statique
• Éléments mis en jeu:
Classe, responsabilité, association, multiplicité, agrégation, composition, attributs,
,attributs dérivés, de classe, classe d’association, qualificatif, opération,
opération de clase, classification, généralisation, spécialisation, classe
abstraite, principe de substitution généralisation multiple, contrainte.
1. Affiner les classes;
2. Affiner les associations;
3. Ajouter les attributs;
4. Ajouter les opérations (optionnels);
5. Optimiser avec la généralisation.
Statique
1. Affiner les classes:
Examen minutieux des classes candidates: ajout, suppression, validation itérative des
classes.
Principes généraux pour l’élimination de classes:
– Classes redondantes : représentent le même concept;
– classe vagues : ne correspond pas à un concept que l’on peut exprimer par une
classe (ex. l’organisation des politiques, …);
– Classe à la place d’un attribut: exprime un concept quantifiable (ex.: Taille);
– Classe à la place d’un rôle: exprime un rôle dans une association particulière
(aéroport de départ, aéroport destination);
– Classe représentant un acteur: utile uniquement lorsque le système doit gérer des
informations sur l’acteur;
– Classe de conception: introduit trop tôt des choix de réalisation.
– Classes représentant des groupes d’objet: classes inutiles car implicites dans les
multiplicités
Statique
1. Affiner les classes:
Examen minutieux des classes candidates: ajout, suppresion, validation itérative des
classes.
Autres principes ( ajout de classes, subdivision de classes):
– Limiter le nombre de responsabilités des classes: pour éviter un nombre trop élévés
d’attributs, d’opérations et d’association. Il faut scinder les classes avec trop de
responsabilités.
– Ne pas confondre entité physique et objet logique ie une entité et sa description
* Plats
DescriptionPlatBuffet
1..*
0..1
1
CommandeBuffet
Statique
2. Affiner les Associations
Examen minutieux des associations: ajout, suppression, validation itérative des
associations.
– principes pour éliminer les associations
– Associations non structurelles: expriment des liens instantanés (dynamique). Un lien

structurel implique une certaine durée et stabilité.
– Associations redondantes: peuvent être retrouvées par navigations à partir des
autres associations
– Utiliser de façon appropriée l’agrégation et la composition
– Identifier les règles de gestion et utiliser les propriétés standard de UML pour
les exprimer: {ordered}, {frozen}, {addOnly}
Statique
3. Ajouter les Attributs
– Ne pas confondre attribut et classe

• attribut = propriété d’une classe, caractérisée par une quantité mesurable
• Un attribut peut être valorisé par une structure de donnée ou être multiple.
– Erreurs classiques:
• Confusion attribut/classe.
• Attribut redondant avec une association/implicite d’après l’association
– Distinguer les attributs dérivés: attribut redondant signalé par « / »

Statique
3. Ajouter les Attributs
– Ne pas confondre attribut et classe
• attribut = propriété d’une classe, caractérisée par une quantité mesurable
• Un attribut peut être valorisé par une structure de donnée ou être multiple.
– Erreurs classiques:
• Confusion attribut/classe.
• Attribut redondant avec une association/implicite d’après l’association
CLASSE ETUDIANT
étudiants 1..* nom
Nb_étudiants Date_nais
… …
• Ajouter les attributs (suite)
– Distinguer les attributs dérivés (« / » + {contrainte pour le calcul} );

– Distinguer les attributs de classe (souligner);
– Remarques:
• Détail qu’on peut négliger en analyse: le type, la valeur initiale, la visibilité;
• Détail intéressants en analyse: multiplicité, val initiale seulement pour les
attributs de classes, propriété {frozen}
– Lorsqu’une association comporte des attributs, elle sera promue en

classe-association.
• [Ajouter les opérations]
– Opération = service, traitement des instances de la classe.
– Certaines opération peuvent être identifier par analyse textuelle du

cahier des charges, et des fiches de description des C.U.
• verbes d’action : envoyer, ajouter etc.
– Ignorer les opérations implicites: constructeur, destructeur,

accesseurs(lecture, modification), création/destruction des liens,
parcours et recherches sur les associations.
– En analyse un nom significatif suffit.

• Optimiser avec la généralisation
– Rechercher les classes possédant des caractéristiques (attributs, opérations,
associations) communes. Rassembler les propriétés communes dans une
superclasse éventuellement abstraite.
– L’optimisation peut aussi se faire par introduction de métaclasses (une

métaclasse est une classe qui décrit une autre classe);
« metaclass »
C
* 1 CatégC
att1
att2 att3
att4
• Les contraintes importantes peuvent être ajoutées à ce niveau.
– Concernent : attributs (notamment attributs dérivés), associations
– Utiliser au besoin OCL.

Développement du modèle dynamique
• Position et Objectif.
– Troisième activité de l’analyse, fortement couplée avec et exécutée
(quasiment ) en parallèle avec la modélisation statique;
– Décrire les scénarii mettant en interaction des objets (diagrammes de
séquence/communication);
– Décrire le cycle de vie des objets de certaines classes (diagrammes
d’états).
• Éléments Utilisés:
– Scénario, diagramme de séquence, de communication;
– Message, événement, signal, appel d’opération;
– Classe d’analyse;
– État (composite), sous-état (séquentiel, parallèle) activité, transition (
propre, interne), conditions, activité (d’entrée, de sortie)
• Les étapes
1. Identifier les scénarios

– Un scénario = exécution particulière d’un cas d’utilisation du
début à la fin
– Plusieurs types de scénarii:
– Nominaux: réalisent les post-conditions d’une façon naturelle et
fréquente
– Alternatifs: réalise les post-conditions par des vois détournées ou
rares.
– Aux limites: remplissent les post-conditions du C.U. mais modifie le

système de telle sorte que la prochaine exécution du C.U. provoquer
aune erreur.
– D’erreur: ne réalisent pas les post-conditions.
• Les étapes
1. Identifier les scénarios
– Le nombre de scénarii est potentiellement élevé. L’exhaustivité

n’est pas un objectif réaliste;
– Essayer de définir un ensemble minimal de scénarii permettant
de couvrir toutes les actions/réactions du système.
– Ex.: couvrir toutes les exécutions importants et réaliste du C.U. et
faire intervenir chaque enchainement au moins une fois dans un
scénario.
• Les étapes
2. Formaliser les scénarios
– Décrire les scénarii à l’aide de diagramme d’interaction
– Scénario= ensemble ordonné de messages échangés par des objets

– Objet (en analyse) : instance de classe d’analyse ou instance d’acteur
– Message: specif. D’une communication unidirectionnelle entre deux
objets. Peut comprendre des paramètres qui transportent des valeurs
vers le recepteur.
– 2 grandes catégories de messages:
• Signal: communication asynchrone explicite et nommée entre 2 objets;
• Appel: invocation sysnchrone d’une opération avec restitution du contrôle
à l’émetteur
• Les étapes
2. Formaliser les scénarios
– Séquence ou Communication ?
• Point de vue assez répandue: en analyse le diag. de séquence et
en conception le diag. de communication qui est plus adapté à la
représentation des itération, des branchements complexes et des
flots de contrôles //.
• Autre critère:
– Peu de participants mais beaucoup d’échanges  Séquence;
– Beaucoup de participants  Communication
– Utilisation possible des Classes d’analyse de Jacobson
• boundary, control, entity
• Les étapes
3. Construire les diagrammes d’états
– Pour les classes ayant un comportement dynamique marqué;
• État = situation au cours de la vie d’un objet pendant laquelle il satisfait

une certaine condition et/ou il exécute une certaine activité et/ou il attend
un certain événement.
• Evénément : occurrence d’un stimulus qui peut déclencher une
transition d’état. Plusieurs types d’événements:
– Réception d’un signal envoyé par un objet ou par un acteur;
– Appel d’une opération sur l’objet récepteur;
– Passage du temps qui se modélise en utilisant le mot clé « after »
suivi d’une expression qui représente une durée décomptée à partir
de l’entrée dans l’état courant;
– Changement dans la satisfaction d’une condition. Mot clé « when »
suivi d’une expression booléenne. L’événement de changement se
produit lorsque la condition passe à vrai.
• Les étapes
– Classe ayant un comportement dynamique marqué ?
• Les objets de la classe réagissent différemment à l’occurrence

d’un même événement (chaque type de réaction  un état);
• La classe organise certaines opérations dans un ordre précis. Des
états séquentiels permettent de préciser la chronologie des
événements d’activation.
•  Un diagramme d’états doit comporter plus de 2 états.

• Les étapes
– Recherche des états d’une classe
• Pas de recette miracle
• 3 approches non exclusives:
– Recherche intuitive s’appuyant sur l’expertise métier (permet de trouver à priori
les états fondamentaux intégrés au vocabulaire métier)
– Étude des attributs et des associations de la classe:
» Valeurs seuils d’attributs qui modifient la dynamique (personne mineure,
majeure)
» Comportements induits l’existence ou la présence de certain liens (marié,
célibataire)
– Démarche systématique: pour chaque classe rechercher le diagramme
d’interaction le plus représentatifs des instances; associer un état à chaque
intervalle entre événement émis ou reçus par une instance; placer les
transitions; Itérer sur tous les scénarii faisant intervenir des instances de la
classes. Cela ajoute de nouveaux états et/ou de nouvelles transitions. Trouver
les boucles dans le diagramme pour éviter la démultiplication des états.
• Les étapes
– Approche incrémentale d’élaboration du diagramme
• Représenter la séquence d’états et les transitions correspondant
au scénario nominal;
• Ajouter progressivement les transitions relatives aux scénarii
alternatifs;
d’exception
• Indiquer les activités sur les transitions et dans les états;
• Structurer (selon la complexité du diagramme ) en sous-état.
• Les étapes
4. Valider Les Diags d’état avec les Diags
d’Interaction
– Complémentarité diagrammes d’interaction/diagrammes d’état
– Les diags d’états de par leur précision et exhaustivité, permettent

de valider et de compléter les diags d’interaction. Au besoin, on
rajoute de nouveaux diagrammes d’interaction
– Il faut vérifier que les diags d’états des classes impliquées dans
les interactions prennent bien en compte tous les scénarii décrits.
• Les étapes
– Approche incrémentale d’élaboration du diagramme

• Représenter la séquence d’états et les transitions correspondant
au scénario nominal;
alternatifs;
d’exception
• Indiquer les activités sur les transitions et dans les états;
• Structurer (selon la complexité du diagramme ) en sous-état.
• Les étapes
5. Confronter les modèles statiques et dynamiques
– Quelques correspondances entre les concepts des deux types de
modèles:
– Un message p un appel d’opération sur un objet (le récepteur) par un
autre objet (l’émetteur)
– Un évènement/ action sur une transition p appel d’une opération.
– Une activité dans un état p exécution d’une opération complexe, ou
d’une succession d’opérations
– Un diagramme d’interaction met en jeu des objets ou des rôles
– Une opération peut être décrite par un diagramme d’interaction ou
d’’activités
– Une conditionde garde ou un « change event » peuvent consulter des
attributs ou des liens statiques
– Une action sur une transition peut peut manipuler des attributs ou des
liens statiques
– Le paramètre d’un message peut être un attribut ou un objet entier
• Figure
Conception Générique
• Position et Objectif
– 2ème étape de la branche technique
– Objectif: développer le squelette technique de la

solution. Fournir une solution qui répond aux
spécifications techniques de l’étape précédente et qui
est indépendante des aspects fonctionnels. Trois
modèles :
• Modèle logique de conception technique
• Modèle d’exploitation
• Modèle de configuration logicielle
• Éléments utilisés
– Diagrammes de classe, frameworks techniques
abstraits et concrets,
– Design patterns, réutilisation des composants
techniques,
– Diagrammes des composants, composants
d’exploitation, composants de configuration logicielle
– frameworks techniques
• Un réseau de classes qui collaborent à la réalisation d’une
responsabilité technique qui dépasse celle de chacune des classes
participantes.
• Représente généralement les mécanismes nécessaire à

l’implémentation d’une couche logicielle
– Struts, Swing, MFC  structure technique de la couche présentation
• Exemples de framework:
– Struts (www.apache.org)
– JDO
– Swing (Java)
– MFC (Microsoft)
• Framework abstrait: constitué seulement d’interfaces
– Interface = ensemble d’opérations qui spécifie le service offert
par une classe ou un composant.
– Réutiliser le framework abstrait  implémenter les interfaces
– structure seulement le modèle de configuration logicielle
• Framework concret:
– structure le modèle de configuration logicielle et le modèle
d’exploitation
– En pratique un framework est constitué à la fois d’interfaces à

implémenter et de classes à réutiliser
– Au niveau du modèle d’exploitation, un framework est livré
sous la forme d’un fichier JAR, WAR, EAR ou d’une
bibliothèque
– Représente généralement les mécanismes nécessaire à
l’implémentation d’une couche logicielle
– Valeur Étiquetée
• Extension des propriétés d’un élément de UML qui permet d’ajouter
de nouvelles informations de spécifications.
• Permet d’alléger et de simplifier les diagrammes de conception.
• Donne de la cohérence à la conception car chaque valeur étiquetée
standardise, factorise et partage un même mécanisme de conception.
– Tout mécanisme introduit doit être clairement défini comme sur la figure avant d’être
utilisé.
« interface »
Serializable
Facture
{serialized}
Facture
– Design patterns
• Solution de conception commune à un problème de conception
récurrent dans un contexte donné
• Traitent les problématiques communément rencontrées en COO:
– Diminution du couplage en vue de faciliter la maintenance évolutive
– Séparation des rôles
– Indépendances vis-à-vis des plate-forme matérielles et logicielles
– Réutilisation du code existant
– Facilité d’extension
– Etc.
• Présente un catalogue des meilleures pratiques:
– « singleton », « fabrication », etc.
• Les Étapes
– 1. Modèle Logique de Conception
• (a) Élaboration :
– Modèle Structurel: Construire les classes, les mécanismes, et les design
patterns au sein des frameworks techniques.
– Modèle dynamique: décrire la dynamique càd la façon dont les
composantes du framework se synchronisent:
» Diagramme d’interaction si le mécanisme mis en jeu implique la
synchronisation d’appels sur plusieurs classes
» Diagrammes d’états si le mécanisme étudiés est sous la
responsabilité d’une classe au comportement dynamique marqué
» Diagramme d’activité ou diagramme global d’interaction lorsque le
mécanisme étudié est entièrement englobé par une seule méthode
qui déroule les étapes fonctionnelles.
• Les Étapes
– 1. Modèle Logique de Conception technique
• (b) organisation :
– Organiser le modèle de conception technique par package de classes (un
package = un framework) en faisant ressortir les dépendances entre les
frameworks techniques.
• Les Étapes
• (c) quelques remarques :
– R1: Modèle Logique / couches logicielles

» L’organisation des frameworks techniques est influencée par les
couches logicielles apparaissant dans l’expression des besoins
techniques
» En effet pour des raisons de cohérence et d’homogénéité, une
responsabilité technique (donc un framework) doit concerner une
seule couche logicielle.
» Toutefois, le modèle de conception logique peut ajouter des services
qui sont transversales par rapport aux couches (çàd accédant ou
accessibles par plusieurs couches).
• Les Étapes
• (c) quelques remarques :
– R2: conception techniques/ contraintes de réiutilisation

» La conception technique doit tenir compte des contraintes de
réutilisation qui s’expriment selon les critères suivants:
1. Avantage économique: temps de développement qu’il aurait fallu
consacrer au composant
2. Gain en fiabilité:
3. Contraintes d’intégration: documentation, exemples, découplage
techniques
• Les Étapes
– 2. Élaboration du Modèle d’Exploitation de Conception
technique
• Rappels :
– Composant (UML): partie physique et remplaçable du système qui
réalise un ensemble d’interface.
– Composant d’exploitation: partie du système logiciel qui doit être
connue, installée, déclarée et manipulée par les exploitants du système.
» Les stéréotypes UML prédéfinis « executable » et « library » (mais
seulement les librairies dynamiques) peuvent être assimilés à des
composants d’exploitation.
• Le modèle d’exploitation montre l’organisation des composants

correspondant aux différents frameworks techniques. Il permet
d’identifier les premiers éléments du système logiciel et de définir
les règles d’intégration des différents composants.
• Les Étapes
– 2. Élaboration du Modèle d’exploitation de Conception technique
• Le modèle d’exploitation montre l’organisation des composants

correspondant aux différents frameworks techniques. On pourra
utilise, à titre d’exemple, les stéréotypes suivants:
– « application »: exécutable directement accessible à un utilisateur. Se
déploie généralement sur un poste client ou sur un serveur d’application
– « EJB Server »: Serveur EJB. Composant distribué sous forme d’un
fichier EAR et se déployant sur une machine serveur d’application
– « DB engine »: moteur BD
– « DB instance »: une instance de la BD (ensemble de tables et
d’utilisateurs)
– « EAI broker »: serveur de messages d’échanges entre les applications
du SI
– « EAI adapter »: terminaux récepteur/émetteurs des messages qui
exécutent les màj au sein des applications.
– 2. Élaboration du Modèle d’exploitation de Conception technique
Figure
• Les Étapes
– 3. Élaboration du Modèle de Configuration de Conception
technique
– More to Come
• Les Étapes
– Génération de Code.
– More to Come
• Élaboration du modèle de configuration logicielle de la conception
technique
– Permet d’identifier les sous-ensemble (sous-systèmes) pouvant se
fabriquer et s’utiliser indépendamment les un des autres. N’a d’intérêt
que pour les grands systèmes
• Un Sous-système est représenté par un package UML avec le stéréotype
« subsystem ». Il est caractérisé par un procédé de fabrication indépendant
et un numéro de version qui fixe son état d’évolution (par exemple un fichier
make file ou le fichier projet d’une plate forme de développement)
• Le découpage en sous-système permet d’identifier les dépendances de
compilation, d’implantation des sources, de regroupements en fichiers JAR,
EAR, WAR, etc.
• Ce découpage établit généralement une correspondance avec les
composants d’exploitation.
• 4. Génération de code
– La conception générique développe le squelette technique du
projet sous la forme de frameworks techniques plus ou moins
abstraits. L’implémentation des frameworks abstraits est basée
sur des informations déjà disponible dans le modèle d’analyse.
Cette implémentation à partir des définitions fonctionnelles
implique l’écriture répétitive et fastidieuse de code.
– L’usage d’un générateur de code (accompagnant l’outil CASE)
peut être utile pour compléter la conception générique.
– Trois familles de générateurs de code:
• Ceux qui permettent de développer ses propres générateurs;
• Ceux qui livrent des générateurs paramétrables;
• Les outils de dernière génération conforma à l’architecture MDA
– Trois niveau de complexité de génération:
• Générer les squelettes: production des fichiers sources des classes
incluant des méthodes vides à compléter à partir des classes,
attributs, méthodes+signatures
• Générer des mécanismes systématiques: générer les classes avec
les méthodes spécifiques aux mécanismes du framework
techniques traité.
– Principale difficulté: paramétrage à réaliser pour contrôler les différents
cas de figures
• Générer le corps des méthodes fonctionnelles: produire à partir des
informations du modèle dynamique, les opérations liées à un
diagramme d’interactions ou à des classes liées à un diagramme
d’états.
– Trois Qualités d’un générateur de code:
• Permettre de s’adapter à la conception générique;
• Être capable d’implémenter tout un framework technique à
partir des informations disponibles dans le modèle d’analyse
• Être incrémental: toute nouvelle génération de code doit
préserver le code qui a été ajouté manuellement.
– La Génération de code demande des ressources.
• Elle est un projet à part entière (analyse, concevoir, coder)
• L’intérêt de la GC peut être estimé à partir du critère:
– n = nombre de classes d’analyse * nombre de frameworks
» Utiliser un GC si n > 200
• 5. Développement d’un prototype
– Le développement (optionnel) d’un ou plusieurs prototype(s) permettre au
point la conception générique avant que les changements ne deviennent trop
coûteux.
– Champs des prototypes: répondre aux fonctionnalités techniques du système:
• Mécanisme CRUD des objets (create, retrieve, update, delete) depuis la présentation
jusqu’à la BD.
• Transformation d’objets entre couches:
– objet de présentation  objet de distribution  objet métier
• Mécanismes d’authentification et d’habilitations
• Intégrité des données sur les postes serveurs et clients
• Synchronisation EAI entre aaplications
• Mécanismes de présentation.
• 5. Développement d’un prototype
– Le prototype doit préparer les trois niveaux de tests relatifs
à la recette technique du système:
• Test unitaire des composants techniques;
• Test d’intégration
• Réponses aux spécifications techniques : respect des temps de
réponses, exigence de montée en charge, etc.
• Résumé de la conception générique
– 1. Élaboration du modèle logique de conception
générique
• Schématiser, au moyen des diagrammes de classes et
d’interaction, les design patterns qui seront utilisés;
• Représenter de la même façon les mécanismes de la

conception et les identifier avec des valeurs étiquetées;
• Identifier et schématiser en UML, les frameworks techniques
• Organiser le modèle logique

– 2. Élaboration du modèle d’Exploitation de

conception technique
• Identifier les composants d’exploitation correspondant aux

frameworks techniques ;
• Organiser le modèle d’Exploitation ;

– 3. [Élaboration du modèle de configuration logicielle
de conception technique]
• Identifier les sous-systèmes de fabrication des composants
d’exploitation en fonction des classes et des frameworks
techniques disponibles;
• Organiser la configuration logicielle en précisant les
dépendances entre sous-système
• Développer si nécessaire les composant de chaque sous-

système ;
– 4. [Développer un générateur de code = un sous

projet]
• Faire l’analyse en s’appuyant sur les résultats de la

conception technique;
• Concevoir,
• et Implémenter le générateur de code
• Tester le générateur de code ;

– 5. [Développer un prototype]
• Identifier les objectifs du prototype;
• Implémenter la conception générique,
• [Intégrer le générateur de code]
• Tester
• Et si nécessaire, Mettre à jour la conception générique et le
générateur de code ;
• Schéma Conception Générique
Conception Préliminaire
– Position: étape (délicate) qui fusionne les
études fonctionnelles et techniques.
– Objectifs:
• Passer de l’analyse objet à la conception;
• Intégrer les fonctions métier et applicatives dans
l’architecture technique;
• Adapter la conception génériques aux spécificités
fournies par l’analyse
• Éléments Utilisés
– Modèle de déploiement, poste de travail, style d’architecture à

niveaux
– Modèle d’exploitation, applications, composants métier,

instances de BD;
– Interfaces de composants, interfaces utilisateur, interface EAI,

façade;
– Modèle logique, diagrammes de classes, classes, catégories de

conception, distribution du modèle logique sur les couches
– Modèle de configuration logicielle

• 1. Développement du Modèle de Déploiement
– Notion de Poste de travail
• Représente un ou plusieurs acteurs localisé(s) sur une machine
d’un type particulier et remplissant une fonction identifiée dans
l’entreprise
• Peut consister en plusieurs machine donnant lieu au même type de
déploiement
• À un acteur de l’analyse correspond généralement (mais pas
toujours) un poste de travail.
– Le modèle de déploiement s’exprime, tout comme le modèle de

configuration matérielle, à l’aide d’un diagramme de
déploiement
modèle de configuration modèle de déploiement
matérielle
• Exprime les contraintes de mise en œuvre au • Exprime la répartition physique des

niveau physique fonctions métier du système en
• montre les nœuds et les connexions considérant chaque nœud comme un
physiques (différents types de machines poste de travail
connectés par divers moyens).
• justifie la localisation des BD et des
•Spécifie, documente et justifie les choix
d’organisation physique en fonction des environnements de travail.
machines dédiés aux diverses fonctions
techniques
– 1.a. Identifier les postes de travail;
– 1.b. Déployer les postes sur le réseau physique
– 1.c. commenter et justifier les caractéristiques opérationnelles du

déploiement: dimensionnement des réseaux, dispositif physique de
sécurité, localisation des bases de données, etc.
Exemple de Modèle de Déploiement
DMZ
Poste Comptable LAN

LAN filtré
{number < 4} Serveur central
{number = 2} Serveur Web
{number = 2}
Poste DRH
{number < 3} WAN
Poste Chef Agence Serveur Agence

{number = 20}
{number = 2}
LAN AGCE
Liaison
radio RTC
Terminal Conducteur
Syst. Localisation
Véhicule
• 2. Développement du Modèle d’Exploitation
– Compléter l’architecture d’exploitation commencé en
conception générique, en fonction des machines et des postes
de travail et en tenant compte des besoins exprimés en
analyse
• Définir les applications installées sur les postes de travail, les
composants métiers et les instances de BD déployés sur les
serveurs
– 2.a. Identifier les applications à partir des cas d’utilisation
– 2.b. Identifier les composants distribués à partir des catégories
d’analyse
– 2.c. Faire l’ébauche des interfaces des composants distribués
– 2.d. [Identifier et spécifier les interface EAI]
– 2.e. Identifier les instances des BD afin d’optimiser la distribution
– 2.f. Lister les interfaces utilisateurs des applications
– 2.g. Compléter la vue d’exploitation
– 2.a. Identifier les applications à partir des cas d’utilisation
• Les applications se déterminent par regroupement des fonctions

de l’utilisateur (modèle de spécification fonctionnelle), tout en
respectant la définition des postes de travail.
– Dans le cas idéal: une application  réalisation d’un nombre entier de
CU
– Mais un CU peut concerner plusieurs acteurs sur des postes de
travail différents. Ainsi un même CU peut donner lieu à plusieurs
applis. Plusieurs CU peuvent correspondent à la même appli.
– 2.a. Identifier les applications à partir des cas
d’utilisation
Poste Comptable
Serveur WEB
« application »
APCOMPTA.exe XXX.War
Client SAP
YYY.War
Poste AGENT
« application »
ApAgent.exe
• 2. Développement du Modèle
d’Exploitation
d’analyse
• Transformer chaque catégorie d’analyse représentant des
concepts du domaine, en en composant d’exploitation
• Arranger au besoin ce découpage en prenant en compte des
critère de conception (regroupement de plusieurs catégorie dans
un composant etc.)
• Assimiler tout progiciel à un composant supplémentaire et utiliser
les technique d’analyse et de conception propre à l’EAI

d’analyse
« EJB »
Facturation « EJB »
« EJB » Produit
Commande
« EJB »
Client

– 2.c. Énumérer les interfaces des composants
• Décrire sommairement ce que réalise chaque composant (sa
fonctionnalité)
Composant Distribué Interface Responsabilité
Commande Icommande Gestion distribuée des entités

Création, modification,
validation, annulation,
suppression d’une
commande
IEnCoursdeCmde
Distribution des infos d’en-
cours de commande
… … …

– 2.d Définition des interfaces EAI
• Définir des interfaces particulières pour l’encapsulation des
progiciels en composants correspondant:
– soit à des fonctions distribuées synchrones ( op. EJB)

– soit des messages de données transmises de façon
asynchrones

– 2.e Définition des instances BD
• Identifier les instances de BD pour optimiser la distribution
en particulier dans une architecture 3-tiers (application-
composants distribués-Stockage des données)
– Critères : temps d’accès, intégration d’autres systèmes,
isolation d’une partie du système en vue de sa réutilisation.
«DB Instance »
BDCentrale
« DB Instance »
BDAgence «DB Instance »
RefClients
– 2.e Énumérer les interfaces Utilisateurs
• Lister les vues d’IHM de chaque application ainsi leurs
principales fonctions.
Vue d’IHM Description

Sélection Article Sélection d’un article dans une liste filtrée d’article
selon les critères: catégorie, sous-catégorie, …
Édition de Feuille d’édition d’une facture: création,
Facture modification, suppression, annulation d’une
facture
… …
• 3. Développement du Modèle Logique
– Modèle logique = modèle représentant les classes organisées

en catégories
– 3.a Identifier les catégories de conception à partir des

catégories d’analyse et des frameworks techniques
– 3.b. Isoler les mécanismes communs dans des catégories

séparées en vue de leur réutilisation
– 3.c. Structurer le modèle logique suivant les couches logicielles

et disposer –y les catégories identifiées
• Catégories de conception = regroupements de classes à fort

couplage
– Organisent les classes techniques et permet une réutilisation
optimale
• L’identification des catégories se fait sur la base:

– Des composants d’exploitation qui définissent des ensembles
cohérents de classes à assembler
– Des frameworks techniques qui conservent la structure des couches
logicielles en regroupant les classes ayant les mêmes domaines de
responsabilité techniques et mettant en œuvres les même types de
technologies
– Des catégories d’analyse qui structurent le métier en plusieurs
domaines spécialisés en regroupant les classes étroitement liées
• Catégories de conception % composants d’exploitation
– Un composant d’exploitation est réalisé par un nombre entier de
catégories de conception: Une même catégorie de conception ne
peut être découpée entre la réalisation de plusieurs composants.
– Par contre, une même catégorie peut participer à l’élaboration de
plusieurs composants
• Catégories de conception % Frameworks techniques

– Framework concret  Catégorie du Modèle Logique technique 
catégorie du ML de conception
– Framework abstrait
» Correspond en général à une couche logicielle
» Le ML peut être organisé en 5 couches : présentation,
Application, Métier, Accès aux données, Stockage des données
» Couche = package qui englobe les catégories de conception.
– 3.a Identifier les catégories de conception à partir des catégories d’analyse et
des frameworks techniques
Stockage Données
Accès Données
« category »
Métier
Facturation
« category »
Facturation « category »
Facturation
Application
Présentation
« category »
« category »
Facturation
Facturation
– 3.b. Isoler les mécanismes communs dans des catégories

séparées en vue de leur réutilisation
• Pour obtenir le découpage en catégorie de conception, prendre

tour à tour chaque composant d’exploitation et considérer ce que
devient chaque chaque catégorie d’analyse par rapport aux
frameworks abstraits. Cela fait apparaître des redondances entre
les catégories. Il faut alors identifier les parties rétulisables et les
isoler dans des catégories spécifique réutilisable.
– 3.c. Structurer le modèle logique suivant les couches
logicielles et disposer –y les catégories identifiées
« layer »
Présentation
« category » « category »
Facturation Commande
« category »
Client
« layer »
Métier
« category » « category »
Facturation Commande
« category »
Client
• 4. Définir les interfaces des catégories
– 4.a Répartir les opérations d’analyses suivant les

couches
– 4.b. Identifier les opérations accessibles depuis

l’extérieur de la catégorie
– 4.c. Concevoir l’interface des catégories

conformément aux frameworks techniques réalisés
• 5. Mettre au point la présentation des applications
– 5.a Élaborer une maquette d’IHM pour les interfaces des
applications
– 5.b. Reporter la structure des classes d’IHM dans les

catégories des couches présentation et d’application
• 6. Structurer la configuration logicielle

– 6.a Identifier les sous-systèmes à partir des catégories de
conception
– 6.b. Compléter la configuration logicielle ébauchée en

conception générique
– Position: étape qui poursuit la conception.
– Objectifs:
• S’appuyer sur les catégories de conception pour
construire les classes, les vues d’IHM, les
interfaces, les tables et les méthodes constituant
des items prêts à coder du système.
• 1. Concevoir le Modèle Logique
– Concevoir les classes
– Concevoir les associations
– Concevoir les attributs
– Concevoir les opérations
• Concernent toutes les couches logicielles
• 2. Développer la configuration logicielle

Processus de Développement Objet

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Processus de Développement Objet

Transféré par

Droits d'auteur :

Formats disponibles

METHODES et

-Une méthode de développement de systèmes

-un ou plusieurs processus de développement,

-et généralement, un ou plusieurs ateliers.

-La mise en œuvre des étapes d’un processus de

– Un processus de développement de systèmes

– Un ordonnancement d’étapes peut être en tout ou

– géré à travers 4 phases : pré étude, élaboration, construction et transition.

– contient 6 disciplines fondamentales: Modélisation métier, Besoins, Analyse

Cas d’Utilisation Architecture Risques

Construit sur Itératif et

RUP UPEDU 2TUP 

La spécification, la conception et l’implémentation sont construites à partir

• Un itération améliore ou fait évoluer un système et elle peut être

– Une itération comprend en général toutes les disciplines:

• Orienté par les risques

– Un risque est un événement dont on redoute la survenue dont

– Exemples : incapacité de l’architecture technique à répondre aux

• Orienté par les risques

– Quelques Facteurs de Risques

• Technique/Architectural: technologies incertaines, visibilité partielle, …

• Ressources: ressources humaines (quantité et qualité), compétence,

• Business: Concurrence, Interfaces avec les fournisseurs, sous-traitants

• Orienté par les risques

– Identifier les Facteurs de Risques

• Un facteur de risque peut entrainer l’apparition de plusieurs

– Développer sans spécification approuvées  Insatisfaction du client +

• Plusieurs facteurs de risques peuvent contribuer à

• Orienté par les risques

– Analyser les risques

• Evaluer la probabilité d’apparition d’un risque

• Evaluer la gravité des conséquences liées à la survenue d’un risque

• Orienté par les risques

– Actions de réduction: réduire l’influence des facteurs de risques (donc

– Actions préventives: Ne pas se mettre dans une situation (actions sur

– Actions de couverture: limiter les conséquences des risques:

– Le projet peut être abandonné si les risques sont jugés trop

• Centré sur l’architecture du système.

– Architecture : Ensemble des décisions d’organisation du

• Centré sur l’architecture du système.

– Architecture : Ensemble des décisions d’organisation du

• A Technical Architecture is the minimal set of rules governing the arrangement,

– architectures client/serveur en tiers (2-tiers, 3-tiers ou n-tiers) :

• Le style 2-tiers met généralement en jeu des clients et un serveur de base

– Architecture en couches : s’intéressent à la distribution des

• Une répartition classique est celle suivant cinq couches : présentation,

• Centré sur l’architecture du système.

– Architectures à Base de Composant (ABC): permettent de développer

• Centré sur l’architecture du système.

– plus le projet avance, plus l’architecture est difficile à modifier : les

– Objectif pour le projet:

• l’architecture s’impose à tous, contrôle les développements ultérieurs,

• Centré sur l’architecture du système.

• Créer une ébauche  grossière de l’architecture.

• Etablir la porté du projet

Vision du projet: Glossaire, Détermination des parties prenantes et

• 4 Phases: préétude(inception), élaboration, construction et

– Acceptation des parties prenantes sur la délimitation du champ

• Définir et valider l'architecture de base

• Vision du système et exigences stables

• Produire un logiciel conforme aux besoins

• Evaluation: La version actuelle est-elle assez stable?, les

• Recommandations aux clients sur la maj de l’environnement logiciel

• Evaluation: les utilisateurs sont-ils satisfaits ?