UE : Environnements de Développement

ECUE : METHODOLOGIE DE CONCEPTION

VH : 1,5h - Coefficient : 2 - Crédit : 2

Classe : L3-DSI

Enseignante : Mme S. Gannar

AU : 2024-2025
 Chapitre 3 :
Processus Unifié d’UML

❑ Présentation
❑ Caractéristiques
❑ Activités
❑ Phases
❑ Cas pratique

Mme S. Gannar 2
 Présentation

❑ UML est un langage qui permet de représenter des modèles, mais il ne

définit pas leur processus d'élaboration
➔ UML n’est donc pas une méthode de modélisation
❑ Ses auteurs préconisent d’utiliser une démarche dite USDP
➔ processus général pour gérer un projet de bout en bout
❑ Profitant du fruit de l’expérience de Rational, de ses pratiques et de sa
stratégie de fusion-acquisition des sociétés éditrices de logiciel
❑ UML et l’approche Rational forment en juin 1998 le RUP : processus Unifié
d’UML

Mme S. Gannar 3
 Caractéristiques
❑ Le processus unifié d’UML propose une démarche qui est :
❑ Pilotée par les cas d’utilisation
❑ Centrée sur l’architecture
❑ Itérative et incrémentale

Activités

Mme S. Gannar 4
 Pilotée par les cas d’utilisation

❑ Cas d’utilisation = service rendu par le système

❑ Ce service = besoin d’utilisateur
➔ Cas d’utilisation = besoin exprimé par l’usager
❑ Les cas d'utilisation recentrent l'expression des besoins sur les utilisateurs :
❑ Outil d'aide à leur identification et leur structuration.
❑ Outil d'aide à l'analyse et à la conception objet ➔ On s'intéresse à un
ensemble de classes qui collaborent dans un certain contexte (celui du
cas d'utilisation)
❑ Outil de communication

Mme S. Gannar 5
 Pilotée par les cas d’utilisation

❑ à chaque itération :
❑ l’activité d'analyse ➔ clarifie, affine et valide les besoins des
utilisateurs.
❑ l’activité de conception et de réalisation ➔ veille à la prise en compte
des besoins des utilisateurs.
❑ l’activité de test ➔ valide la satisfaction des besoins des utilisateurs

Mme S. Gannar 6
 Pilotée par les cas d’utilisation

❑ Les cas d'utilisation sont le fil conducteur de

toutes les activités
❑ A partir des cas d’utilisation, les développeurs
créent une série de modèles UML
Mme S. Gannar 7
 Pilotée par les cas d’utilisation

❑ Classes candidates à partir des descriptions des UC :

❑ Classes '‘entité’’ : classes données du système
❑ Classes '‘frontière’’ interfaces entre acteur et système
❑ Classes '‘contrôle’’ encapsulent le comportement d'un Use Case
Mme S. Gannar 8
 Centrée sur l’architecture
❑ Art d’assembler des composants en respectant des contraintes,
ensemble des décisions significatives sur :
✓ l’organisation du système
✓ les éléments qui structurent le système
✓ la composition des sous-systèmes en systèmes, …
✓ Le style architectural guidant l’organisation (couches…)
➔Ensemble des éléments de modélisation les plus signifiants qui
constituent les fondations du système

❑ L’architecture regroupe les différentes vues du système qui doit être

construit.

Mme S. Gannar 9
 Centrée sur l’architecture
Vue Description
De haut niveau, se concentre sur l'abstraction et l'encapsulation.
Logique
Elle modélise les éléments et leurs interactions. Elle organise les
(l’intégrité de
éléments du domaine en "catégories" (regrouper ce qui peut
conception)
être générique, isoler ce qui est propre à une version donnée, ...)
De composants - De bas niveau, montre l'allocation des éléments de modélisation
de réalisation dans des modules (fichiers sources, bib, BDs, exe, …). Elle
(l’intégrité de identifie les modules qui réalisent (physiquement) les classes de
gestion) la vue logique.
Importante dans les environnements multitâches. Elle montre la
De processus
décomposition du système en terme de processus (tâches), les
(l’intégrité
interactions entre les processus (leur communication), la
d’exécution)
synchronisation et la communication des activités // (threads)
Utile pour décrire la distribution d’un système réparti. Elle
De déploiement
montre la disposition physique des matériels, ainsi que leurs
(l’intégrité de
performances, l'implantation des modules principaux sur les
performance)
nœuds du réseau, les exigences en terme de performances
De cas d’utilisation Guide la modélisation et colle tous les autres vues.

Mme S. Gannar 10
 Centrée sur l’architecture

Mme S. Gannar 11
 Centrée sur l’architecture

❑ Marche à suivre :
❑ Créer une ébauche grossière de l’architecture.
❑ Travailler sur les cas d’utilisation représentant les fonctions
essentielles
❑ Adapter l’architecture pour qu’elle prenne en compte ces cas
d’utilisation
❑ Sélectionner d’autres cas d’utilisation et refaire de même.
➔ L’architecture et les cas d’utilisation évoluent de façon
concomitante.

Mme S. Gannar 12
 Itérative et incrémentale
❑ Découpe du projet en “mini-projet”
➔ des ITÉRATIONS qui donnent lieu à un INCRÉMENT.
❑ Une itération est une séquence d’activités (mini-cascade) selon un plan
pré-établi et des critères d’évaluation, résultant en un produit
exécutable et dure entre qques semaines et 9 mois.
❑ Chaque itération comprend un certain nombre de cas d’utilisation et
doit traiter en priorité les risques majeurs
❑ Les itérations sont regroupées dans une phase. Chaque phase est
ponctuée par un jalon qui marquera la décision que les objectifs (fixés
préalablement) ont été remplis.

Mme S. Gannar 13
 Itérative et incrémentale

❑ Découpe du projet en “mini-projet”

➔ des ITÉRATIONS qui donnent lieu à un INCRÉMENT.
❑ Un incrément par itération :
❑ Le logiciel et le modèle évoluent suivant des incréments
❑ série de prototypes qui vont en s’améliorant avec les retours
utilisateurs
❑ processus incrémental
❑ les versions livrées correspondent à des étapes de la chaîne de
prototypes

Mme S. Gannar 14
 Itérative et incrémentale

Activités

Mme S. Gannar 15
 Itérative et incrémentale : Avantages

❑ Gestion de la complexité :
pas tout en même temps,
étalement des décisions importantes
❑ Maîtrise des risques élevés précoce :
❑ diminution de l’échec
❑ architecture mise à l’épreuve rapidement (prototype réel)
❑ Intégration continue :
❑ progrès immédiatement visibles
❑ maintien de l’intérêt des équipes (court terme, prototypes vs
documents)

Mme S. Gannar 16
 Itérative et incrémentale : Avantages

❑ Prise en compte des modifications de besoins :

❑ feedback, implication des utilisateurs et adaptation précoce
❑ Apprentissage rapide de la méthode :
❑ amélioration de la productivité et de la qualité du logiciel
❑ Adaptation de la méthode :
❑ possibilité d'explorer méthodiquement les leçons tirées d'une
itération (élément à conserver, problèmes, éléments à essayer…)
❑ Mais gestion de projet plus complexe : planification adaptative

Mme S. Gannar 17
 Phases et Activités

❑ Chaque phase exécute l’ensemble des activités et se termine par un

point de contrôle (jalon / livrable) permettant de prendre des décisions

Mme S. Gannar 18
 Activités

✓ Les analystes identifient la plupart des UC pour délimiter le système, et

détaillent les plus importants
✓ Les analystes trouvent les UC restant (objectif : 80%) et les décrivent pour
estimer l'effort de développement en fin de phase
✓ Le reste des UC est exprimé et implémenté
✓ Sauf changement, aucun UC ne doit rester à découvrir
Mme S. Gannar 19
 Activités : Capture des Besoins

❑ Définir les besoins fonctionnels

❑ Cas d’utilisation / / Acteurs / Scénarios (donc construction du modèle
de cas d’utilisation)
❑ Classer les cas d’utilisation par priorité
❑ Détailler les cas d’utilisation (Préconditions, Scénario nominal, …)
❑ Appréhender les besoins non fonctionnels (contraintes)
❑ Travailleurs :
❑ Analyste du domaine
❑ Spécificateur de cas d’utilisation
❑ Concepteur d’interface utilisateur (Maquette IHM )
❑ Architecte logiciel (Vue architecturale du modèle des UC)

Mme S. Gannar 20
 Capture des Besoins : Artéfacts

Mme S. Gannar 21
 Activités : Analyse des Besoins
❑ Construire le modèle d’analyse et préparer la conception
(Forme/Architecture générale du système)
❑ Mener l’analyse architecturale
❑ Identifier les packages d’analyse par regroupement logique
❑ Identifier les classes constituant le cœur de métier (3 stéréotypes)
❑ Identifier les besoins non fonctionnels communs pour les rattacher aux UC
❑ Analyser les cas d’utilisation
❑ Réaliser les scénarios
❑ Identifier les classes, attributs et associations nécessaires
❑ Décrire les interactions (par des diagrammes de séquence)
❑ Faire ces opérations pour chaque UC
❑ Travailleurs
❑ Architecte
❑ Responsable de l’intégrité du modèle d’analyse et de la description de
l’architecture
❑ Ingénieur des UC
❑ Responsable de l’analyse de chaque UC
❑ Ingénieur des composants
❑ Responsable des classes et paquetages d’analyse
Mme S. Gannar 22
 Analyse des Besoins : Artéfacts

Mme S. Gannar 23
 Activités : Conception
❑ Proposer une réalisation de l'analyse et des cas d’utilisation en prenant en
compte toutes les exigences
❑ Effectuer la conception architecturale : identifier les nœuds du déploiement
❑ Concevoir les cas d'utilisation : identifier les classes nécessaires à la
réalisation des cas
❑ Concevoir les classes et les interfaces : décrire les méthodes, les états,
prendre en compte les besoins spéciaux
❑ Concevoir les sous-systèmes :mettre à jour les dépendances, les interfaces,
les composantes réseau et/ou middleware
❑ Travailleurs
❑ Architecte
❑ Ingénieur des UC
❑ Ingénieur des composants
Mme S. Gannar 24
 Conception : Artéfacts

Mme S. Gannar 25
 Activités : Implémentation
❑ Faire la mise en œuvre architecturale
❑ identifier les artefacts logiciels et les associer à des nœuds
❑ Intégrer le système
❑ planifier l'intégration, intégrer les incréments réalisés
❑ Réaliser les composants et les sous-systèmes
❑ Réaliser les classes
❑ Mener les tests unitaires (tests de spécification en boîte noire)
❑ Travailleurs
❑ Architecte
❑ Ingénieur des composants
❑ Intégrateur système

Mme S. Gannar 26
 Implémentation : Artéfacts

Mme S. Gannar 27
 Activités : Tests
❑ Rédiger le plan de test
❑ Décrire les stratégies de test, estimer les besoins pour l'effort de test,
planifier l'effort dans le temps
❑ Tenir compte des risques (tester dès que possible)
❑ Concevoir les tests
❑ Automatiser les tests
❑ Réaliser les tests d'intégration
❑ Réaliser les tests du système dans son intégralité
❑ Évaluer les tests (sont-ils efficaces ? Pertinents ? …)
❑ Travailleurs
❑ Concepteur de tests
❑ Ingénieur de composants (test unitaires)
❑ Testeur d’intégration (tests d’intégration)
❑ Testeur système (vérification du système dans son ensemble)
Mme S. Gannar 28
 Tests : Artéfacts

Mme S. Gannar 29
 Priorités !!!
❑ Avant que les besoins les besoins ne puissent être utilisés dans les phases
suivantes du processus, on doit leur affecter des priorités.
❑ Il est important d’associer objectivement une priorité à chaque besoin
❑ Il s’agit d’estimer la contribution relative de chaque besoin à la vision du
projet
❑ Pour la majorité des systèmes, une échelle de quelques niveaux : haut,
moyen, bas (1,2,3) suffit à définir les priorités :
❑ Un besoin à haute priorité est un besoin indispensable sans lequel le
système ne peut pas être fonctionnel
❑ Un besoin de priorité moyenne peut être fortement souhaité
❑ Un besoin de priorité basse est souhaité mais optionnel dans le sens
où son absence rend le système inférieur mais tout de même

Mme S. Gannar
fonctionnel. 30
 Priorités : Exemple

Cas d’utilisation Priorité

Rechercher ouvrage Haute
Gérer son panier Haute
Effectuer une commande Moyenne
Consulter ses commandes en cours Basse
Consulter l’aide en ligne Basse
Maintenir le catalogue Haute

Mme S. Gannar 31
 Risques ???

❑ Risque que le projet de construction du système soit un échec

❑ Différentes natures de risques pour un projet : besoins / technique /
autres
❑ Exemples :
❑ le système construit n’est pas le bon
❑ architecture inadaptée, utilisation de technologies mal maîtrisées,
performances insuffisantes
❑ personnel insuffisant, problèmes commerciaux ou financiers
(risques non techniques, mais bien réels)

Mme S. Gannar 32
 Risques ???

❑ Identifier et classer les risques par importance

❑ Agir pour diminuer les risques
ex. changer les besoins, confiner la portée à une petite partie du projet,
faire des tests pour vérifier leur présence et les éliminer
❑ S’ils sont inévitables, les évaluer rapidement
tout risque fatal pour le projet est à découvrir au plus tôt

Mme S. Gannar 33
 Risques
Planification
de l’itération
Risques initiaux,
portée du projet Développement de
l’itération

Itération N
Évaluation

Révision du
plan du projet

Risques éliminés
Révision des risques

34
 Phase d’Inception : Objectifs

❑ Etude d’opportunité
❑ Délimiter le système
❑ Déterminer ce qu’il fait
❑ Prévoir les risques
❑ Estimer les coûts
NB: Attention à ne pas définir tous les besoins, à vouloir des estimations
fiables (coûts, durée), sinon on fait de la cascade

Mme S. Gannar 35
 Phase d’Inception : Activités
❑ Capture des besoins
❑ comprendre le contexte du système (50 à 70% du contexte)
❑ établir les besoins fonctionnels et non fonctionnels (80%)
❑ traduire les besoins fonctionnels en cas d'utilisation (50%)
❑ détailler les premiers cas par ordre de priorité (10% max)
❑ Analyse
❑ analyse des cas d'utilisation (10% considérés, 5% raffinés) pour mieux
comprendre le système à réaliser et guider le choix de l'architecture
❑ Conception
❑ première ébauche de la conception architecturale : sous-systèmes, nœuds, réseau,
couches logicielles
❑ Implémentation et Tests
❑ Grandes lignes

Mme S. Gannar 36
 Phase d’Inception : Livrables
❑ Première version du modèle du domaine ou de contexte de l’entreprise
(parties prenantes, utilisateurs, …)
❑ Liste des besoins fonctionnels et non fonctionnels
❑ Ébauche des modèles de cas, d’analyse et de conception
❑ Esquisse d’une architecture
❑ Liste ordonnée de risques et liste ordonnée de cas
❑ Grandes lignes d’un planning pour un projet complet
❑ Première évaluation du projet, estimation grossière des coûts
➔ Accepter le projet ?

Mme S. Gannar 37
 Phase d’Inception : récap

❑ Vision = Quoi + Pour qui + Combien

❑ les grandes lignes du produit

❑ la population cible

❑ combien l’acheteur serait prêt à payer

❑ Estimation des coûts

❑ Prototype

❑ Petit projet : cahier de charges

❑ Durée pour un projet moyen (un an) : un mois

38
 Phase d’Elaboration : Objectifs

❑ Spécifier la plupart des cas d’utilisation

❑ Concevoir l’architecture de base (squelette du système)
❑ Mettre en œuvre cette architecture
❑ Faire une planification complète

Mme S. Gannar 39
 Phase d’Elaboration : Activités
❑ Capture des besoins
❑ terminer la capture des besoins et en détailler de 40 à 80%
❑ faire un prototype de l'interface utilisateur (éventuellement)
❑ Analyse
❑ analyse architecturale complète (packages...)
❑ raffinement des cas d'utilisation (pour l'architecture, < 10%)
❑ Conception
❑ terminer la conception architecturale
❑ effectuer la conception correspondant aux cas sélectionnés
❑ Implémentation
❑ limitée au squelette de l'architecture
❑ faire en sorte de pouvoir valider les choix
❑ Tests
❑ du squelette réalisé (attention, peut être coûteux)
Mme S. Gannar 40
 Phase d’Elaboration : Livrables

❑ « architecture du cycle de vie » ➔ premier prototype qui démontre la

validité des choix architecturaux
❑ Peut-on passer à la construction ? (besoins, architecture, planning
stables ? Risques contrôlés ? )

Mme S. Gannar 41
 Phase d’Elaboration : récap

❑ Analyse des besoins ➔ architecture du produit

❑ Descriptions des cas d’utilisations, des scénarios principaux, un modèle

des classes

❑ Plan détaillé des itérations

❑ Durée : 2-4 mois pour un projet d’un an

42
 Phase de Construction : Objectifs
❑ Réaliser une version béta
➔ Développer par incréments ( y aura plusieurs itérations) :
✓l'architecture reste stable malgré des changements mineurs
✓le produit contient au final tout ce qui avait été planifié, il reste
quelques erreurs
❑ Phase la plus coûteuse :
❑ > 50% du cycle
❑ englobe conception, codage, tests, intégration, etc

Mme S. Gannar 43
 Phase de Construction : Activités
❑ Capture des besoins
❑ spécifier l'interface utilisateur

❑ Analyse
❑ terminer l'analyse de tous les cas d'utilisation, la construction du modèle structurel d'analyse

❑ Conception
❑ l'architecture est fixée et il faut concevoir les sous-systèmes dans l'ordre de priorité
(itérations de 1 à 3 mois, max. 9 mois)
❑ concevoir les cas d’utilisation puis les classes

❑ Implémentation
❑ réaliser, passer des tests unitaires, intégrer les incréments

❑ Tests
❑ toutes les activités de test :
plan, conception, évaluation...

Mme S. Gannar 44
 Phase de Construction : Livrables

❑ Un plan du projet pour la phase de transition

❑ L'exécutable et son packaging minimal
❑ Tous les documents et les modèles du système
❑ Une description à jour de l'architecture
❑ Un manuel utilisateur suffisamment détaillé pour les tests

Mme S. Gannar 45
 Phase de Construction : récap

❑ Identification des scénarios à compléter au cours de l’itération, en

fonction des risques

❑ Affectation de tâches précise à l’équipe

❑ Définition des critères d’évaluation de l’itération, des points de

contrôle et des délais

❑ Rédaction des documents pour l’utilisateur

❑ durée : 6-9 mois

46
 Phase de Transition : Objectifs

❑ Mise en service chez l’utilisateur :

❑ livrer / déployer le produit
❑ corriger le reliquat d’erreurs
❑ améliorer le produit
❑ préparation de la formation, la commercialisation
❑ former les utilisateurs
❑ Déplacement et/ou assistance en ligne

Mme S. Gannar 47
 Phase de Transition : Activités
❑ Préparer la version beta à tester (installer la version sur le site, convertir et faire
migrer les données)
❑ Gérer le retour des sites (retour de déploiement)
❑ Le système fait-il ce qui était attendu ? Erreurs découvertes ?
❑ Adapter le produit corrigé aux contextes utilisateurs (installation...)
❑ Terminer les livrables du projet (modèles, documents...)
❑ Déterminer la fin du projet
❑ Reporter la correction des erreurs trop importantes (nouvelle version)
❑ Organiser une revue de fin de projet (pour apprendre)
❑ Planifier le prochain cycle de développement

Mme S. Gannar 48
 Phase de Transition : Livrables

❑ « livraison du produit » ➔ produit déployé chez le client

❑ tests suffisants ? Produit satisfaisant ? Manuels prêts ?
❑ L'exécutable et son programme d'installation
❑ Les documents légaux : contrat, licences, garanties, etc.

Mme S. Gannar 49
 Phase de Transition : récap
❑ Pour l’utilisateur

❑ programmes (version bêta, puis définitive)

❑ documents (utilisation, installation)

❑ Pour le responsable du projet

❑ modèles révisés

❑ critères d ’évaluation des itérations

❑ description des livraisons

❑ résultats de l’assurance qualité

❑ durée : un mois

50
 Répartition Modèles/Phases

❑ U : Modèle de UC
❑ A : Modèle d’analyse
❑ C : Modèle de conception
❑ D : Modèle de déploiement
❑ I : Modèle d’implémentation
❑ T : Modèle de Tests

Mme S. Gannar 51
 Le processus unifié : Récapitulons

❑ UML est un langage de modélisation et n ’impose pas de démarche

de développement

❑ Le processus unifié : méthodologie de développement

❑ basée sur un cycle de vie itératif et incrémental

❑ axe temporel : phases et itérations

❑ axe vertical : activités

52
 Le processus unifié : Récapitulons
Itération Phase Objectif Décision
Itération Etude d’opportunité Comprendre le
préliminaire problème
Ressources pour
l’élaboration
Itération Elaboration Comprendre la
d’architecture solution

…xN … …
Ressources pour la
construction
Itération de Construction Réaliser la solution
développement

…xN … …
Livrer le produit
(version bêta)
Itération de Transition Transmettre la
transition solution
…xN … …
Recette client
53
 Conclusion

RUP est Gros mais très

structurant
il faut s’adapter aux
besoins du projet

Mme S. Gannar 54