Méthodologie de

conception objet
Brahmi oumaima
Année scolaire 2023/2024

1
plan
Processus Unifié – Principes

Cycle de vie de Processus Unifié

Les phases

Les activities

Les caractéristiques du processus unifié

Les 4 <<p>> du développement logiciel

Les rôles

2
 Qu’est-ce que le Processus Unifié ? (1/2)
 Un processus de développement logiciel définit qui fait quoi, quand et comment pour atteindre un objectif

donné

Le Processus Unifié ou UP (Unified Process) est une méthode générique de développement de logiciel

développée par les concepteurs d’UML

Générique signifie qu'il est nécessaire d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de

l'organisation.

Il existe donc un certain nombre de méthodes issues de UP comme par exemple RUP (Rational Unified

Process), 2TUP (Two Track Unified Process)

3
 Qu’est-ce que le Processus Unifié ? (2/2)

 Un processus de développement logiciel, c’est-à-dire qu’il regroupe les activités à mener pour transformer
les besoins d’un utilisateur en système logiciel (Jacobson, Booch, Rumbaugh 1999). UP est itératif, centré
sur l'architecture, Piloté par des cas d'utilisation et orienté vers la diminution des risques.

 Une méthode de développement pour les logiciels orientés objets vient pour compléter la systémique des
modèles UML.

 C'est un patron de processus pouvant être adaptée à une large classe de systèmes logiciels, à différents
domaines d'application, à différents types d'entreprises, à différents niveaux de compétences et à différentes
tailles de l'entreprise.

4
 Objectifs de UP

• produire un logiciel de qualité en respectant des contraintes de délai, de coûts et de performance

• fournir des lignes directrices pour un développement efficace d’un logiciel de qualité, en réduisant
les risques et en améliorant les prévisions

• Décrire les meilleures méthodes de travail pour apprendre des expériences précédente et
l’amélioration du support de formation

5
 Les dérivés de U.P
 RUP : Rational Unified Process : Instanciation par Rational Software (IBM) des préceptes UP

 EUP : Enterprise Unified Process : Instanciation intégrant les phases de postimplantation et décrivant le

cycle de vie du logiciel.

 XUP : Extreme Unified Process : Instanciation hybride intégrant UP avec Extreme Programming.

 AUP : Agile Unified Process: partie des préceptes UP permettant l’agilité du développement, instanciation

partielle de la méthode mettant l’accent sur l’optimisation et l’efficience sur le terrain plus que sur le modèle

théorique.

 2TUP : Two Tracks Unified Process : Instanciation de UP proposé par Valtech prenant en compte les aléas

et contraintes liées aux changements perpétuels et rapides des SI des entreprises.

 EssUP : Essential unified process : (Ivar Jacobson) propose une mouture de UP integrant certains
6
concepts de la méthodes Agile et de ProcessImprovement (intégration prévue aux outils de travail

collaboratifs “Visual Studio Team System” de Microsoft)

Cycle de vie de Processus Unifié

7
 Cycle de vie de Processus Unifié 1/3

 L'objectif d'un processus unifié est de maîtriser la complexité des projets informatiques en diminuant les
risques. UP est un ensemble de principes génériques adapté en fonctions des spécificités des projets.

 L’architecture bidirectionnelle: UP gère le processus de développement par deux axes .

 L'axe vertical : représente les principaux enchaînements d'activités, qui regroupent les activités selon leur
nature. Cette dimension rend compte l'aspect statique du processus qui s'exprime en termes de composants,
de processus, d'activités, d'enchaînements, d'artefacts et de travailleurs.

 L'axe horizontal : représente le temps et montre le déroulement du cycle de vie du processus; cette
dimension rend compte de l'aspect dynamique du processus qui s'exprime en termes de cycles, de phases,
d'itérations et de jalons.

8
Cycle de vie de Processus Unifié 2/3

L’architecture bidirectionnelle

9
Les phases , les itérations et les jalons

 Une phase se découpe en itérations successives

 Une phase et une itération se termine par un jalon
 Les Jalons correspondent à des étapes d’évaluation de la phase
terminée, et de lancement de la phase suivante 10
 Cycle de vie de Processus Unifié 3/3

Pour mener efficacement un tel cycle, les développeurs ont besoins de toutes les représentations du
produit logiciel.

 un modèle de cas d'utilisation.

 un modèle d'analyse : détailler les cas d'utilisation.

 un modèle de conception : finissant la structure statique du système sous forme de sous-

systèmes, de classes et interfaces.

 un modèle d'implémentation : intégrant les composants

 un modèle de déploiement : définissant les nœuds physiques des ordinateurs

 un modèle de test : décrivant les cas de test vérifiant les cas d'utilisation

11
 une représentation de l'architecture.
Les phases

12
Les phases de PU

13
 Les phases du PU
 Le PU répète une série de cycles constituant la vie du système.
 Un cycle conduit à la livraison d’une version du produit.
 Un cycle s’articule autour de 4 phases :
 étude préliminaire
 Élaboration
 Construction
 Transition

 Chaque cycle de développement du PU est géré comme un projet ayant 4

phases.
14
 Chaque phase s'achève par un jalon défini par un ensemble d’artefacts.
Les phases du PU - artefact

 Un élément d'information sur le produit ou la modification dans le cadre

du processus de développement(document, diagramme, compte rendu

de la réunion , code source, modèle de base de données, etc.)

 Artefacts qui dépendent de l'activité de gestion de projet.

 Artefacts qui sont directement issus du travail de fabrication du logiciel .

15
 Phase de lancement (Inception) ; étude préliminaire
(1/2)

 Cette phase traduite en une vision du produit fini.

 Elle répond aux questions suivantes :
 Quel est le domaine d’application?
 Que doit faire le système ?
 Quels sont les risques ?
 Quel sont les coûts, les délais, les ressources et les moyens pour le projet ?
 Comment le planifier ?
 Jalon : « objectifs du projet »
 Prise de décision: Est-ce qu’on accepte le projet ? 16
Phase de lancement (Inception) ; étude préliminaire
(2/2)
 Comprendre les objectifs et la portée du projet
Objectifs :
1. Comprendre le système à construire
2. Identifier la fonctionnalité principale du système
3. Déterminer au moins une solution possible
4. Décider du processus à appliquer et des outils à utiliser

 Nb : en général une seule itération, sauf pour projets importants, innovants, ou très risqués

17
Phase d’élaboration 1/3

18
Phase d’élaboration 2/3

 Elaboration : mise en place d’un prototype

 Formuler les cas d’utilisation pour couvrir environ 80% des besoins fonctionnels.
 Exigences supplémentaires (non fonctionnelles et celles qui ne sont pas associées à des c.u.).
 Conception de l’architecture de référence (squelette du système).
 Mise en œuvre de cette architecture.
 Planification complète (temps, personnel, budget).
 Un manuel utilisateur préliminaire.

– Les besoins sont-ils considérés? L’architecture stable? Les risques sont contrôlés ?
– Jalon : « architecture»
19
– Prise de décision: Est-ce qu’on peut passer à la réalisation?
Phase d’élaboration 3/3
 Construction d’un squelette d’architecture en intégrant les risques majeurs et affiner les
plans de projet

Objectifs :
1. Comprendre en détail les exigences
2. Concevoir, implémenter, valider l’architecture
3. Réduire les risques essentiels et estimer plus exactement le budget
4. Affiner le plan de développement

 NB: en général une à trois itérations (artefact : plan d’itération)

20
Phase de construction 1/3

21
Phase de construction 2/3

 Mettre en œuvre tous les cas d'utilisation en accord avec les clients
 La phase la plus coûteuse qui englobe le codage, la conception , test et intégration, etc.
 Construction : développement
– Développement par itérations / incréments
• Pour aboutir à une architecture stable
– Le produit contient tout ce qui avait été planifié
• Il peut rester quelques erreurs non détectées …
– Jalon : «opérationnel»
Le jalon est une version du produit.
22
– Prise de décision: le produit est-il suffisamment correct pour être installé chez un client ?
Phase de construction 3/3

 Phase concentrée sur la conception, l’implémentation et les tests

 Objectifs :
1. Minimiser les coûts de développement et obtenir un certain degré de parallélisme
2. Développer de façon itérative un logiciel prêt à la transition vers les utilisateurs

 NB : même pour de petits projets, il faut plusieurs itérations (entre 2 et 4)

23
Phase de transition 1/2

24
Phase de transition 2/2

 Cette phase couvre le test du produit en version bêta .

 Les anomalies et les défauts constatés par l'équipe de test sont prises en
considération.

 La formation des utilisateurs, la préparation des manuels d’utilisation , la mise en

place d'une équipe de maintenance.

 Le produit est déployé chez le client.

25
Les activités

26
Les activités

les phases se décomposent en activités :

 1) Expression des besoins
*recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à l'élaboration des
modèles de cas d'utilisation
*Appréhender les besoins non fonctionnels (technique) :
-performance, sûreté, confidentialité, portabilité , etc.
-chercher des critères mesurables

27
Rôle le des besoins dans le cycle de vie du logiciel

 L'expression des besoins s'étale sur plusieurs incréments de développement .

 Chaque itération apporte de nouveaux cas d'utilisation ou des détails des cas d'utilisation existants.

 La capture des besoins s'effectue principalement au cours des phases d'étude préliminaire et
d’élaboration.

 Identification de la plupart des cas d'utilisations durant la phase d'étude préliminaire.

 La mise à jour des cas d’utilisation durant la phase de l’élaboration.

 Le reste des besoins est formulé et mis en œuvre durant la phase de construction.

28
Expression des besoins

 vue d’ensemble
 Capture des besoins

– collecte des informations : interviews, lecture de documentation,,,

– chercher à comprendre : (1) le domaine (2) le problème

 Définition des besoins

– restitution dans un langage compréhensible par le client

– identification, structuration, définition d’un dictionnaire

 Spécification des besoins

– spécification détaillée des besoins, plus formel

– utile pour le client, mais aussi pour les développeurs

29
Expression des besoins

 Capture des besoins (1)

 Objectifs : comprendre le domaine, comprendre le problème

 Collecter le maximum d'informations

– Lecture des documents fournis, Consulter les documents pertinents au système

– Interviews du client, des utilisateurs, …discuter avec le client ou l’utilisateur afin de bâtir une compréhension
commune des exigences du système.

– Réunions de travail

– Collecter des exemples pour valider

– Étudier les systèmes existants le cas échéant,

– observer l’exécution des tâches des utilisateurs que le

 système doit soutenir. 30

Expression des besoins

 Capture des besoins (2)

 → Réagir et être actif !

– Établir la liste des documents consultés, les classer
– Élaborer une liste de questions précises
• les numéroter, les dater, …
• faire référence aux documents concernés
– Écrire un ou plusieurs documents et les diffuser
– Provoquer les réunions et les mener
• établir l’ordre du jour
• prendre des notes
• faire systématiquement des comptes rendus écrits
31
Expression des besoins

 Définition des besoins (1)

 Restituer les informations sous forme synthétique
– Scénarios et cas d’utilisation :
• Identifier une séquence d'actions effectuées par le système qui résultent en un résultat observable,
• Utiliser et simuler l'utilisation du système afin d’expliciter et de clarifier Exigences
 Ce qui n’est pas écrit n’existe pas !
 Préciser les besoins, pas la solution
 Préciser ce que doit faire le système
– et aussi ce qu’il n’est pas sensé faire.
– mais surtout pas comment il doit le faire.
 Etablir des priorités
 Arriver à un consensus avec le client
32
Expression des besoins

 Définition des besoins (2)

 Les besoins doivent être compris par tous
– utiliser la langue naturelle
• Faire des phrases courtes,
• Eviter le conditionnel, le futur, les termes ambigus ou subjectifs, ...
• Parler en termes de rôles plutôt que de personnes
• Numéroter les paragraphes si nécessaire, Utilisation de références précises
• Elaborer un dictionnaire
– utiliser des schémas si nécessaire
 tout schéma doit être commenté et comporter une légende
 Structurer le document de définition
– suivre un plan standard si disponible
– numéroter les sections, références, index, …
33
Expression des besoins
 Définition des besoins (3)
 Définir un dictionnaire
– Indispensable d'avoir un langage commun
• définition d'un vocabulaire précis
• client, équipe de développement, utilisateurs
– Utilisation dans les documents et aussi le logiciel !
• analyse des besoins (clients)
• base pour le développement du logiciel (développeurs)
• base pour l'interface du logiciel (utilisateurs)
– Technique simple mais efficace !
– Intérêt :
• Outil de dialogue, Informel, facile à réaliser, facile à faire évoluer
– Permet de décrire la terminologie du domaine
– réutilisable dans un autre projet
– Permet de détecter les ambiguïtés
34
• Montre l'essentiel du domaine d'application
• Permet d'assurer la traçabilité
Expression des besoins

 Définition des besoins (4)

 Conseils pour la construction du dictionnaire :

– Partir de la description du problème
– Repérer les groupes nominaux notion
– Repérer les groupes verbaux action ou notion
– Eliminer les synonymes
– Eliminer les termes inutiles
– Donner des définitions simples
– Permet de se concentrer sur l'essentiel
– Doit être complété et mis à jour !

35
Expression des besoins

 Spécification des besoins

 Interface entre le client et les développeurs

– doit être compris par les deux
– définit dans le détail ce qui doit être réalisé
– doit être précis car contractuel
 Utilisation de techniques semi-formelles
– ex. diagrammes de cas d'utilisation UML
– ex. diagrammes de classes UML

36
Les activités
 2) Analyse :
L'objectif de l'analyse est d'accéder à une compréhension des besoins et des
exigences du client.

37
Analyse

 Modèle d’Analyse vs Modèle des cas d’utilisation

38
Les activités
 3) Conception :
La conception permet d'acquérir une compréhension approfondie des contraintes
liées au langage de programmation à l'utilisation des composants et framework
et au système d’exploitation ,

39
Conception :
 Modèle d’analyse vs Modèle de conception

40
Conception :

 Etapes à suivre
 1. Estimer les performances du système
 2. Mettre au point un plan de réutilisation
 3. Organiser le système en sous-systèmes
 4. Identifier les questions de concurrence inhérentes au
 problème
 5. Allouer les sous-systèmes aux équipements matériels
 6. Gérer le stockage des données
 7. Gérer les ressources globales
 8. Choisir une stratégie de contrôle du logiciel
 9. Traiter les cas limites
 10. Arbitrer les priorités
 11. Sélectionner un style architectural

41
Conception

 Conception des classes

 Finalisation de la définition des classes et des associations

 Choix des algorithmes des opérations
 Ajout de détails et prise de décisions fines
 Choix des différentes façons d’implémenter les classes d’analyse
 Nécessité d’avoir plusieurs itérations à des niveaux successifs d’abstraction
 Critères de facilité d’implémentation, de maintenabilité et d’extensibilité

42
Les activités

 4) Implémentation:
la programmation. Le résultat de la conception pour implémenter le système sous
formes de composants

43
Les activités
 5) Test
Pour mener à bien ces tests, il faut les planifier pour chaque itération, les
implémenter en créant des cas de tests, effectuer ces tests et prendre en compte
le résultat de chacun.

 6) Déploiement

44
Les caractéristiques du processus unifié

45
Les caractéristiques du processus
unifié

46
 Processus piloté par les cas d’utilisation

 Le but principal d’un système informatique est de satisfaire les besoins de client. Le processus de développement
sera donc accès sur l’utilisateur. Le cas d’utilisation permet d’illustrer ces besoins. Ils détectent puis décrivent les
besoins fonctionnels et leur ensemble constitue le modèle de cas d’utilisation qui dicte les fonctionnalités
complètes du système.

47
 Processus piloté par les cas d’utilisation

 Le processus de développement est centré sur l’utilisateur.

48
 Processus itératif et incrémentale1/2
 Une itération est une succession d'enchainements d'activités.

 Un incrément est une avancée dans les stades de développement.

 À chaque itération on retrouve les activités de spécification des besoins, de conception, jusqu'au prototypage
exécutable.

 Le projet est découpé en itérations ou étapes de

courte durée qui permettent de mieux suivre
l’avancement globale. A la fin de chaque itération
une partie exécutable du système finale est
produite, de façon incrémentale (par ajout).

49
 Processus itératif et incrémentale 2/2
 Une itération est une séquence d’activités selon un plan
pré-établi et des critères d’évaluation, résultant en un
produit exécutable

50
 Processus centré sur l’architecture 1/2

 Tout système complexe doit être décomposé en partie modulaire afin d’en faciliter la maintenance et l’évolution.
Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modéliser en UML, et pas seulement
documentée en texte.

 L’architecture d’un système logiciel :

• peut être décrite comme les différentes vues du système à construire

• équivaut aux aspects statiques et dynamiques significatifs du système

• émerge des besoins exprimés par les utilisateurs et spécifiés par les cas d’utilisation
 Centré sur l’architecture
• Structurer tous les modèles (UC, déploiement et composants, classes)
51
 Processus centré sur l’architecture 2/2

 L’architecture constitue dans UP 2 artefacts primaires pour conceptualiser,

construire, gérer, et élaborer le système en développement :

1. la description de l’architecture logicielle qui décrit l’architecture

du projet

2. le prototype de l’architecture qui implémente cette architecture.

52
 Processus piloté par le risque
 Les risques majeurs du projet doivent être identifiés au plus tôt mais surtout levés le
plus rapidement. Les mesures à prendre dans ce cadre déterminent l’ordre des itérations

 Diminution des risques

• Identifier au plus tôt
• Commencer par le plus difficile

53
 Différentes natures de risques
 Besoins

• Mauvaise interprétation des besoins, du domaine

 Technique

• Architecture technique inadaptée (performances insuffisantes)

 Autres

• Outil inutilisable (formation, administration)

• Risques non techniques (personnel de développement insuffisant, problèmes commerciaux ou financiers)

54
Les 4 <<p>> du développement logiciel

55
Les 4 <<p>> du développement logiciel

 Personnes : les architectes, développeurs, testeurs , la direction, les utilisateurs, les

clients.

 Projet : élément d’organisation à travers lequel est gérez le développement du

logiciel.

 Produit : ensemble des artefacts créés au cours du cycle de vie du projet .

 Processus : offrir un cadre générique à la création de projet.

56
Les rôles

57
Les rôles

 Le chef de projet
Responsable de la gestion de projet
Individu ou équipe ?
Plan de développement (plan de projet, plan d’itération, risques)
Plan de gestion de la configuration
Choisir les artefacts UTILES
Adapter les artefacts au projet
Collaborer avec tous les autres acteurs
Constamment focalisé sur les risques

58
Les rôles

 L’analyste
Activités : Modélisation métier, Exigences, Analyse et conception
Développer une Vision
Liste des fonctionnalités
Modèle de C.U., Glossaire, Prototype interface utilisateur, Spécifications Supplémentaires
Vérifier que les exigences sont respectées et testées

59
Les rôles
 L’architecte
Coordonne les artefacts techniques
Communication entre les équipes de développement
Choix d’une architecture en fonction : performance, robustesse, réutilisation, compréhensibilité,
modularité, contraintes techniques, sûreté de fonctionnement
Document d’architecture
Validation par le prototype architectural

60
Les rôles
 Le développeur
Activités :
Analyse et conception
Implémentation
Conception des réalisations des C.U.
Conception des tests

61
Les rôles
 Le testeur
Activités en fonction des phases :
Lancement : test des idées des technologies possibles
Élaboration : test architecture (notamment performance, évolutivité, etc.)
Construction : test fonctionnel
Transition : robustesse, ergonomie, etc.

62