UML4

Génie logiciel et méthodes de
conception orientées objet
A. ABDELLATIF
abdelaziz.abdellatif@fst.rnu.tn
2007-2008
UML
et le processus de
développement logiciel

GL & MCOO A. Abdellatif
2UML et le processus
de développement logiciel
Sommaire
Introduction au processus de
Le processus unifié (PU)
L’extreme programming (XP)
Un processus simplifié
Quelques outils (AGL)

Introduction au processus de

Développement logiciel
Logiciels à développer de plus en plus
complexes.
Capacité de production logicielle
inférieure à la demande (crise du
logiciel).
Nécessité de mettre en place une
organisation adéquate dans les
projets de développement logiciel

Organisation d’un projet de
Projet
Processus
Personnes
Outils

Processus de développement
logiciel
Un processus de développement logiciel est un
ensemble d’activités permettant de
transformer les besoins des utilisateurs en
un système logiciel.
Processus de
développement
logiciel
Besoins utilisateurs
Système logiciel

logiciel
Un processus de développement logiciel
doit être générique, c’est dire qu’il doit
pouvoir s’adapter à :
Tout type de logiciel,
Tout type d’entreprise,
Toute taille d’entreprise,
Toute taille de projet et
Tout niveau de compétence.

logiciel et MCSI
Une méthode de conception de systèmes
d’information comporte :
Un formalisme permettant de décrire les
composantes du SI à l’aide d’un ensemble de
modèles (ou diagrammes).
Une démarche (ou processus) permettant de
réaliser les composantes du SI en suivant un
ensemble d’étapes.
Un plan d’assurance qualité permettant de
garantir la qualité des composantes du SI en
respectant un ensemble de règles.

UML et le processus de
UML est une notation.
UML n’est pas une méthode.
UML est utilisable avec toute méthode
de conception dont le processus est :
Piloté par les cas d’utilisation
Centré sur l’architecture logicielle
Itératif et incrémental

Quelques processus de développement
logiciel utilisables avec UML
UML peut être utilisée en suivant :
Le processus unifié (PU) : c’est un
cadre complet (et lourd) de processus
de développement logiciel.
L’extrême programming (XP) :
c’est une démarche favorisant le
développement rapide.
Un processus simplifié : démarche
à mi-chemin entre le PU et l’XP.

Présentation
« Le processus unifié est 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

Présentation
Le PU est un ensemble de principes et
de bonnes pratiques permettant de
répondre aux questions suivantes :
QUI ? Qui participe au projet,
QUOI ? Que produit le projet,
COMMENT ? Comment le travail doit
être réalisé
QUAND ? Quand est réalisé chaque
livrable

Historique du PU
ApprocheApproche
EricsonEricson
ObjectoryObjectory
ProcessProcess
1967 19871967 1987 -- 1995 19961995 1996 -- 1997 19981997 1998 ……
RationalRational
ObjectoryObjectory
ProcessProcess
UMLUML
RationalRational
UnifiedUnified
ProcessProcess
AutresAutres
sourcessources
Un système est
composé d’un
ensemble de blocs
imbriqués
•Object Factory
•Cas d’utilisation
•Suite de modèles
•Importance de
l’architecture
•Démarche itérative
et incrémentale
•Standard de fait
•Domaine public
•Supporté par les
produits

Caractéristiques du PU
Le PU est :
Piloté par les cas d’utilisation d’UML
Centré sur l’architecture
Itératif et incrémental

Concepts de base du PU
Le PU se base sur un ensemble de
concepts répartis en trois groupes :
Les artefacts : ce sont les éléments
produits au cours du projet (le QUOI).
Les rôles : ce sont les rôles joués par
les acteurs intervenant dans un projet
(le QUI).
Les disciplines : une discipline est un
ensemble d’activités qui produisent un
ensemble d’artefacts.

Artefacts
Deux types d’artefacts :
Artefacts relatifs à la gestion du projet :
Comptes rendus,
Plannings, …
Artefacts relatifs à la production
logicielle :
Modèles,
Spécification,
Code source,
Exécutables, …

Rôles
Cinq groupes de rôles :
Analystes : ceux qui analysent les
risques.
Développeurs : ceux qui conçoient et
implémentent le logiciel.
Testeurs : ceux qui testent les
programmes
Managers : ceux qui gèrent
l’organisation du projet.
Les autres

Disciplines
Deux familles de disciplines :
Disciplines d’ingénierie :
Modélisation du métier (Business Modeling)
Besoins (Requirements)
Analyse et conception (Analysis & Design)
Implémentation (Implementation)
Test
Déploiement (Deployment)
Disciplines de support :
Gestion de projet (Project Management)
Gestion de Configuration et du changement
(Configuration and Change Management)
Environnement

Architecture bidirectionnelle du PU
Le PU gère le processus de
développement selon deux axes :
Axe vertical : les disciplines
Axe horizontal : les phases (inception,
élaboration, construction, transition)
Pour chaque discipline, les phases
sont réalisées en plusieurs itérations.

Architecture bidirectionnelle du PU
Disciplines
Phases
Itérations

Modélisation du métier
(Business Modeling)
Objectif :
Produire un modèle de l’organisation
à laquelle est destiné le logiciel.
Artefacts :
Glossaire
Modèle des cas d’utilisation métier
Rôles :
Analystes processus métier

Besoins
(Requirements)
Objectif :
Capturer les besoins des utilisateurs.
Artefacts :
Modèle des cas d’utilisation
Spécifications non fonctionnelles
Liste des risques
Maquette d’IHM
Rôles :
Analystes système

Analyse et conception
(Analysis & Design)
Objectif :
Traduire les cas d’utilisation des besoins en
artefacts de conceptions du système.
Artefacts :
Modèle de conception
Modèle de déploiement
Modèle de données
Rôles :
Concepteurs
Architectes

Implémentation
Objectif :
Raffiner le modèle de conception et
produire des composants logiciels.
Artefacts :
Modèle de composants
Prototype ou version du logiciel
Rôles :
Développeurs
Intégrateurs

Test
Objectif :
Test des composants logiciels
développés.
Artefacts :
Plan de test
Scripts de test
Rôles :
Testeurs

Déploiement
(Deployment)
Objectif :
Conditionnement du logiciel et sa
mise à la disposition des utilisateurs.
Artefacts :
Plan de déploiement
logiciel
Rôles :
Gestionnaire de déploiement

Phase Inception
Consiste à :
cadrer le projet
Identifier les risques
Réaliser un premier planning
Artefacts :
Version initiale de Risk list
Version initiale du plan de développement du
logiciel
Première version du modèle de cas d’utilisation

Phase Elaboration
Consiste à :
Stabiliser l’architecture de référence
Éliminer les risques majeurs
Artefacts :
Nouvelle version de Risk list
Nouvelle version du plan de développement du
logiciel
Document décrivant l’architecture du logiciel :
modèle de CU,
modèle de conception relatif aux CU les plus
importants,
modèle de composants,
modèle de déploiement

Phase Construction
Consiste à :
Proposer des versions exécutables du
logiciel
Éliminer les risques majeurs
Artefacts :
Version beta du logiciel
Plan de déploiement
Première version de la documentation

Phase Transition
Consiste à :
Livrer le logiciel et en assurer
l’exploitation et la maintenance.
Artefacts :
Version finale du logiciel

Variantes du PU
Le processus unifié a donné lieu à plusieurs implémentations :
RUP : Rational Unified Process, Rational Software (IBM)
EUP : Enterprise Unified Process, intégre les phases de post-
implantation et décrivant le cycle de vie du logiciel.
XUP : Extreme Unified Process, intégrant UP avec XP
AUP :Agile Unified Process, instanciation partielle de PU
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, 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, par Ivar Jacobson, intégre
certains concepts de la méthodes Agile et des idées des
partisans de ProcessImprovement.

Présentation
Méthode de développement itérative.
Proposée par Kent BECK et Ron
JEFFRIES.
Ensemble cohérent de bonnes
pratiques.
Privilégie la production du code à
celle des documents et des modèles.

Les principes d’XP
Le développement se fait selon une suite
d’itérations imbriquées :
Itérations de développement
consistant à réaliser des
fonctionnalités demandées par le
client (1 à 4 semaines).
Itérations de livraison composées de
2 à 3 itérations de développement.

Les principes d’XP
L’analyse et la conception ne peuvent
être séparées de l’implémentation car :
Le client peut changer d’avis en cours du
projet.
Risque de non compréhension des
spécifications par les développeurs
Risque de départ de membre de l’équipe

Les 12 pratiques d’XP
Assurer un feedback constant :
1. Développement piloté par les test
2. Le jeu de la planification
3. Le client sur site
4. Programmation en binôme
Mettre en place un processus fluide et
continu :
5. Intégration continue
6. Amélioration du code par la réécriture
7. Itérations de livraison courtes

Les 12 pratiques d’XP
Favoriser une compréhension
partagée :
8. Conception simple
9. User de la métaphore
10. Propriété collective du code
11. Conventions de codage
Assurer le bien-être de l’équipe :
12. Un rythme de travail continu sans
surcharge

Présentation
C’est un processus de développement
logiciel qui se trouve à mi-chemin
entre le PU et l’XP.
Il regroupe les avantage de chacun
des ces processus et évite leurs
inconvénients :
Généricité du PU
Rapidité d’obtention du code de l’XP
Éviter la lourdeur du PU

Caractéristiques
Le processus simplifié a les
caractéristiques suivantes :
Basé sur les cas d’utilisation comme le
PU,
Plus simple que le PU,
Léger comme l’XP,
Ne néglige pas l’analyse et la conception,
Utilise 20% d’UML pour modéliser 80%
du système

Les phases du processus
Le processus de développement logiciel
est composé des phases suivantes :
Étude des besoins
Analyse
Conception
Implémentation

Étude des besoins
Cette phase consiste à :
Identifier les besoins des utilisateurs à travers des
entretiens avec eux.
Modéliser ces besoins à l’aide de diagrammes de cas
d’utilisation :
Identifier les acteurs,
Délimiter le système,
Identifier les cas d’utilisation.
Pour chaque cas d’utilisation faire:
Une description textuelle,
Des diagrammes de séquence système qui
représentent les interactions entre les acteurs et le
système.
Des diagrammes d’activité ou des diagrammes d’états-
transitions en cas de besoins.
Réaliser une maquette.

Analyse
Élaborer un premier diagramme de
classes (dit diagramme du domaine) :
Identifier les entités du domaine (
classes)
Identifier les attributs
Identifier les associations
Simplifier le modèle en utilisant l’héritage
Regrouper les classes en paquetages

Analyse (suite)
Élaborer un diagramme des classes
participantes. C’est un digramme qui comporte
trois types de classes :
Classes de dialogue : classes qui permettent
l’interaction entre les utilisateurs et l’IHM. Elles
sont déduites à partir de la maquette.
Classes de contrôle : classes permettant de
faire le lien entre les classes de dialogue et les
classes entités. Elles contiennent les règles de
gestion.
Classes entités : elles proviennent du
diagramme du domaine. Elles sont persistantes.

Analyse (suite)
Élaborer des diagrammes de navigation.
Ce sont des digrammes qui permettent
de représenter la dynamique de la
navigation à travers l’IHM. Pour ce faire,
on peut utiliser :
Les diagrammes d’activités
Les diagrammes d’états-transitions
Ces diagrammes sont rattachées aux classes
de dialogue.

Conception
Détailler les digrammes de séquence système
élaborés dans la phase d’analyse en remplaçant
l’objet « système » par un ensemble d’objets
(dialogue, contrôle, entité).
Élaborer un diagramme de classes de conception
qui est obtenu par l’enrichissement du
diagramme de classes participantes en rajoutant
les opérations (à partir des diagrammes de
séquences).

Implémentation
Générer la base de données à partir du
diagramme de classes.
Générer les classes (Java, C++, …) à
partir du diagramme de classes.
Générer du code à partir des autres
diagrammes (activité, séquence, …) si
l’AGL le permet.
Compléter le développement.
Tester les modules.

Processus simplifié : synthèse
1 2
3
4
5
6
7
8
9
Étude des besoins
Analyse
Conception
Implémentation

Quelques AGL supportant UML
Power AMC
Version 11
Sybase
www.sysbase.com
Visual Paradigm for UML
Version 6.1
Visual Paradigm International
www.visual-paradigm.com

Quelques AGL supportant UML
MagicDraw UML
Version 14.0
No Magic
www.magicdraw.com
Rational Rose
Version 2003
IBM
www-306.ibm.com/software/awdtools/developer/rose

UML4

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie UML4

Ähnlich wie UML4 (20)

Mehr von 'Farouk' 'BEN GHARSSALLAH'

Mehr von 'Farouk' 'BEN GHARSSALLAH' (15)

UML4