Méthodologie objet Cycle de développement objet C. Soulé-Dupuy Professeur d informatique...

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


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 :


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


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É »



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


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



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


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


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


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


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



Les paradigmes de modélisation axe structurel et statique axe temporel et dynamique axe fonctionnel

MÉTHODE DE CONCEPTION

STRUCTUREL

DYNAMIQUE FONCTIONNEL


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


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


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.



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



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



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


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 »



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



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


Exigences

Analyse et conception

Implantation

Tests

Déploiement

Gestion de configuration

et des changements

Gestion de projet

Environnement




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



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


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


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


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



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



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)



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



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



Business Process Reengineering

Le processus est :

– transversal

– dynamique

– rarement indépendant du produit fini

Le processus correspond à une action



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


Méthodologie objet Cycle de développement objet C. Soulé-Dupuy Professeur d informatique...

Documents

Transcript of Méthodologie objet Cycle de développement objet C. Soulé-Dupuy Professeur d informatique...