Méthodologie objetCycle de développement objet
C. Soulé-DupuyProfesseur d ’informatique Université Toulouse 1 &
Institut de Recherche en Informatique de Toulouse
1. Pourquoi une méthode ?
2. Les constituants d ’une méthode
3. Le concept de système
4. Cycles de vie et cycles de développement
5. Panorama des méthodologies objet
6. Mise en œuvre des méthodologies objet : le RUP
7. Approches « RAD » et « Concurrent Engineering »
8. Méthodes OO et « Business Process Reengineering »
© C. Soulé-Dupuy 2
1. POURQUOI UNE MÉTHODE ?
Volonté d ’HOMOGÉNÉISATION de la prise en compte et de la résolution de problèmes
Nécessité d ’une CONCERTATION entre : utilisateurs décideurs informaticiens
Fixer des règles opératoires
Capitaliser des expériences
Nécessité de spécifier et de concevoir en abordant conjointement cadre décisionnel et informatique
Nécessité d ’une approche globale cohérence priorités
Utilisateurs
Maîtred ’ouvrage
Maîtred ’oeuvre
Développeurs
Cheminement de la communicationdans un processusde développement
© C. Soulé-Dupuy 3
1. POURQUOI UNE MÉTHODE ?
Elle guide et indique comment aborder les problèmes au travers de
formalismes
démarche de modélisation
Elle propose des normes ou standards de présentation des résultats de la spécification et de la conception
langage standardisé
démarche vérifiable
validation aisée
Une méthode a un double rôle :
© C. Soulé-Dupuy 4
2. LES CONSTITUANTS D ’UNE MÉTHODE
Philosophie générale support continu métier guide sur la façon d ’aborder les problèmes dans leur
environnement
Démarche mode d ’emploi de la méthode découpage du processus de développement en étapes
cohérentes
Vocabulaire identifier les concepts décrire les concepts
Formalisme et normes spécifier la représentation des composantes du système
Outils aides à l ’analyse et à la conception aides à la réalisation
© C. Soulé-Dupuy 5
3. LE CONCEPT DE SYSTÈME
Définition
Autrement dit :
ensemble d ’éléments matériels ou immatériels en interaction
transforment, grâce à un processus, des éléments (entrées) en d ’autres éléments (sorties)
« UN SYSTÈME EST UN ENSEMBLE D ’ÉLÉMENTS
EN INTERACTION DYNAMIQUE
ORGANISÉS EN FONCTION D ’UN BUT DONNÉ »
© C. Soulé-Dupuy 6
3. LE CONCEPT DE SYSTÈME
Schéma général d ’un système :
SYSTEME DE PILOTAGE
SYSTEME OPERANT
fixation des objectifsvariables essentielles
Entrées Sorties
Ecarts
décisions
informations
© C. Soulé-Dupuy 7
Approche systémique
SYSTEME DE PILOTAGE
Coordination, objectifs (membres de la direction, ...)
SYSTEME D'INFORMATION
- collecte - mémorisation - traitement - transmission
des données (informations)
SYSTEME OPERANT
Production, action (ensemble du personnel exécutant)
informations
externes
informations
l'exterieur
vers
Décisionsinformations
traitées
informations collectées
Flux entrant
Flux sortant
E N V I R O N N E M E N
E X T E R I E U R
3. LE CONCEPT DE SYSTÈME
© C. Soulé-Dupuy 8
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT Cycles de vie linéaires
applications traditionnelles
processus séquentiels
Expressiondes besoins
Spécificationsfonctionnelles
Analyse
Conception
Implémentation
Tests devérification
Validation
© C. Soulé-Dupuy 9
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT Cycles de vie en « V »
enchaînement de phases autonomes
facilite vérification et validation
Expressiondes besoins
Spécificationsfonctionnelles
Conceptiondu système
Conceptiondes composants
Implémentation
Validationdes besoins
Validationfonctionnelle
Testdu système
Test descomposants
© C. Soulé-Dupuy 10
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT Le cycle de vie objet
traçabilité entre les étapes caractère itératif caractère incrémental
Spécifications
Analyse
Conception
Implémentation
Tests
Validation
V 1.0 V 1.1 V 1.2
© C. Soulé-Dupuy 11
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT
Cycle de développement Orienté Objet
Modélisation métier
Planification initiale
Planification
ExigencesAnalyse et conception
Réalisation
Tests
Évaluation Déploiement
Gestion des changements et
de la configuration
Environnement
© C. Soulé-Dupuy 12
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT Quel cycle de vie ? Quel Cycle de développement ?
Cascade
Itératif
Bien documenté
Traçabilité
Comité de contrôle des changements
Faible formalisme Formalisme élevé
Peu de documentation
Processus légers
Peu de risquesSéquentielIntégration et tests tardifs
Piloté par les risques,Intégration et tests continus
© C. Soulé-Dupuy 13
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT
Les paradigmes de modélisation axe structurel et statique axe temporel et dynamique axe fonctionnel
MÉTHODE DE CONCEPTION
STRUCTUREL
DYNAMIQUE FONCTIONNEL
© C. Soulé-Dupuy 14
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT Niveaux d ’abstraction : 3+1 niveaux de
préocccupation couche de modélisation conceptuelle couche de modélisation logique et organisationnelle couche de modélisation physique et opérationnelle
Niveau Préoccupations Données Traitements Flux
Conceptuel QUOI ? Conceptuel Conceptuel ConceptuelQUE VEUT-ON FAIRE ?
OrganisationnelQUI ? OU ? QUAND ? Organisationnel OrganisationnelOrganisationnel
Logique COMMENT ? Logique Logique
Physique AVEC QUELS MOYENS Physique Opérationnel
© C. Soulé-Dupuy 15
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT Niveaux d ’abstraction (suite) :
Données Traitements Flux
Niveauconceptuel
MCD : signification desinformations sanscontraintes techniques ouéconomiques
MCT : activité du domainesans préciser les ressourcesou leur organisation
MCF : flux et activitésdu domaine
Systèmed'information
Niveauorganisationnel
MOD : signification desinformations aveccontraintes techniques ouéconomiques
MOT : fonctionnement dudomaine avec les ressourcesutilisées et leur organisation
MOF : flux et acteursd’information dudomaine
Niveau logique
MLD : description desdonnées en tenant compte deleurs conditions et destechniques de mémorisation
MLT : fonctionnement dudomaine avec les ressourcesutilisées et leur organisationinformatiques
Systèmed'informationinformatisé
Niveau PhysiqueMPD : description de la oudes BD dans la syntaxe duSGF ou du SGBD
MPT : Architecturetechnique des programmes
© C. Soulé-Dupuy 16
Processus de Conception
Les résultats types
Globalement Expression des besoins
Par système
Par sous-système
Par moduleou paquetage
Etude préalable
Etude détaillée
Réalisationet mise en oeuvre
Articulationdes domaines
PLAN DEDÉVELOPPEMENT
Descriptionchoix scénario
de développement
DOSSIER DE CHOIX
Description1er
sous-système
Description2ème
sous-système
CAHIER CHARGES CAHIER CHARGES
UTIL. UTIL.REAL. REAL.
Réalisation et mise en œuvre
1er module
Réalisation et mise en œuvre2ème module
DOC. 1er MODULE DOC. 2ème MOD.
4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT
© C. Soulé-Dupuy 17
5. PANORAMA DES MÉTHODES OBJET
Précurseurs de RUP-UML
OOD (Object Oriented Design) - G. Booch– Ada, C++, Smalltalk, Eiffel
HOOD (Hierarchical Object Oriented Design)– Ada
OOA (Object Oriented Analysis) - Shlaer & Mellors
OOA / OOD - Coad & Yourdon
OMT (Object Modeling Technique) - Rumbaugh
OOSE (Object Oriented Software Ingineering) - Jacobson
OOM (Orientation Objet dans Merise)
1985
1993
© C. Soulé-Dupuy 18
5. PANORAMA DES MÉTHODES OBJET
Aujourd ’hui, les AGL (Atelier de Génie Logiciel ) permettant une modélisation objet :
intègrent UML– Rational ROSE (Rational Inc.) OMT, Booch, UML
– ISOA (MEGA International) UML, Chen ER
– ObjectPartner (Verilog) OMT, UML
– Paradigm Plus (Platinum Technology) OMT, Booch, UML, Jacobson, Chen ER, OOA (Slaer & Al.), ...
– StP ou Software through Pictures (Aonix) OMT, Booch, UML
– ...
Intègrent un processus UP
permettent la génération de code C++ et Java et éventuellement VisualBasic
© C. Soulé-Dupuy 19
5. PANORAMA DES MÉTHODES OBJET
Evolution des méthodes Objet
Autresméthodes
Booch ’91 OMT-1J. Rumbaugh, 91
OOSE (Objectory)I. Jacobson, 92
PartenairesIBM
ObjecTime/ROOM
Booch ’93 OMT-2
Unified Method 0.8OOPSLA ’95
WWW, Juin 96 UML 0.9
UML 1.0
UML 1.1
Jeu dedocumentation
Spécifications sur le site Web de l ’OMG :http://www.omg.com
Rational SW, Microsoft, HP, ICON,ORACLE, Unisys, MCI Systemhouse,TI SW :soumission commune à l ’OMG,17 Janvier 1997
UML 1.3Juin 1999
Spécifications sur le site Web Rational :
http://www.rational.com
UML 2.0Septembre 2003
© C. Soulé-Dupuy 20
6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP
L ’ingénierie de systèmes avec le RUP : Rational Unified Process)
Approche disciplinée sur la manière d ’attribuer les tâches et les responsabilités
maîtrise des moyens maîtrise des coûts maîtrise des délais
S ’adapte à tous types de projets et d ’organisations processus itératif décomposé en phases et itérations modulables et
configurales
« Production de logiciel d ’un haut niveau de qualité correspondant aux besoins de l ’utilisateur final dans le
cadre de programmes et de budgets prévibles »
© C. Soulé-Dupuy 21
6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP
Cf. plan détaillé fourni séparément.
4 phases dans le RUP
1. Inception Cadre du système et portée du projet2. Elaboration Analyser le système et développer le plan
du projet3. Construction Développement du système4. Transition Livraison du système aux utilisateurs
Itération Cycle de développement logiciel (ou système) complet depuis le
recueil des besoins jusqu ’à l ’implantation et aux tests.
Se termine par la sortie d ’une version exécutable du projet
1 .. * itérations par phase
© C. Soulé-Dupuy 22
6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP
PHASES
ITÉRATIONS
Workflows du processus
Workflows de soutien
Inception Elaboration Construction Transition
Itération(s)préliminaire(s)
Itér.#1
Itér.#2
Itér.#n
Itér.#n+
1
Itér.#n+
2
Itér.#k
Itér.#k+
1
Modélisation métier
Exigences
Analyse et conception
Implantation
Tests
Déploiement
Gestion de configuration
et des changements
Gestion de projet
Environnement
© C. Soulé-Dupuy 23
6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP
Modélisation métier
Urbanisation du système
Développement dusous-système logiciel
Développement etacquisition du matériel
Gestionde
projet
Déploiementet
maintenance
Construction,Intégration
etTest
© C. Soulé-Dupuy 24
6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP
VueLogique
Vue desProcessus
Vue desComposants
Vue deDéploiement
Vue desCas d’ Utilisation
UtilisateursFonctionnalités
Intégrateurs de systèmesPerformanceRobustesse, AdaptabilitéDébit
Maîtrise d ’ouvrage / AnalystesComportements
ProgrammeursGestion du logiciel
Ingénierie du systèmeTopologie du systèmeDistribution, InstallationCommunication
© C. Soulé-Dupuy 25
7. APPROCHES « RAD » et « CONCURRENT ENGINEERING »
Rapid Application Development approche par prototypage itératif meilleure appréhension des objectifs d ’un projet et des
besoins
Concurrent Engineering Ingénierie simultanée
« prendre les bonnes personnes au bon moment pour identifier et résoudre les problèmes de conception »
Réduction du cycle de vie
© C. Soulé-Dupuy 26
8. MÉTHODES OO ET « BPR »
Objets métiers et objets logiciels
Objet métier
– générique / contexte idéal
– terme utilisé tant en génie logiciel qu’en management
– objets perçus au pour l ’implantation des modèles conceptuel et logique
Objet logiciel
– objets perçus au niveau de l ’architecture logicielle
© C. Soulé-Dupuy 27
Objets métiers et objets logiciels Architecture en couches
Interfaces H-M Ecrans / dialogues / maquettes
Contrôle Liens écrans / modèles
Processus métier
Organisation métier
Applications
Objets métiers
Objets techniques
Objets d ’infrastructures
Services Services techniques / objets de classes prédéfinies
Communication Echanges entre applications distantes, accès BD, ...
Stockage Données persistantes / matériel / base de données /système d ’exploitation
Modèles Conceptuel & logique
8. MÉTHODES OO ET « BPR »
© C. Soulé-Dupuy 28
Objets métiers et objets logiciels Structuration des objets métiers
– Diagramme de classes global
– partitionnement du modèle de classes en paquetages==> identifier le domaine métier
• classes liées par agrégation
• même attente utilisateur
• même responsabilité géographique et fonctionnelle
Entitésexternes
Entités depilotage
Entitésopérantes
8. MÉTHODES OO ET « BPR »
© C. Soulé-Dupuy 29
Objets métiers et objets logiciels
Fractionner la migration par phase
==> limiter les risques
Axe applicatif(paquetage logique)
Axe géographique(structure entreprise)
Axe technique(infrastructure)
8. MÉTHODES OO ET « BPR »
© C. Soulé-Dupuy 30
Business Process Reengineering
Nouveaux modes de restructuration dynamique et continuelle
– réaction rapide face aux changements de l ’environnement
– forte aptitude au changement
La complexité des systèmes et de leur management nécessite des méthodes et outils nouveaux permettant aux acteurs de mieux comprendre l ’organisme et le système
8. MÉTHODES OO ET « BPR »
© C. Soulé-Dupuy 31
Business Process Reengineering Objectifs du « BPR »
– correction
– prévention
– anticipation
– satisfaction client / utilisateur
– privilégier processus et non fonction
==> Reconfiguration de processus
Succès
Hommes
Organisationdu projet BPR
Compréhensiondu fond
Développementincrémental
8. MÉTHODES OO ET « BPR »
© C. Soulé-Dupuy 32
Business Process Reengineering
Le processus est :
– transversal
– dynamique
– rarement indépendant du produit fini
Le processus correspond à une action
8. MÉTHODES OO ET « BPR »
© C. Soulé-Dupuy 33
Déroulement du « BPR »
Lancement del ’action BPR
Existant et bilan
Conception
Mise en œuvre
PHASESÉTAPES
- Volonté de l ’action- Étude d ’opportunité- Préparation de la logistique
- Compréhension de l ’existant- Élaboration des stratégies
- Conception des processus métier- Planification des actions
- Implantation- Suivi des processus
Processusincrémental
8. MÉTHODES OO ET « BPR »