projet[methode d_'analyse comparée][barro drissa et traoré ibrahim]

5/16/2018 Projet[Methode d_'Analyse Comparée][Barro Drissa et Traoré Ibrahim] - slidepdf.com

http://slidepdf.com/reader/full/projetmethode-danalyse-compareebarro-drissa-et-traore-ibrahim 1/14

Ecole Supérieure d’Informatique

Analyse et Programmation

3eme Année

Burkina Faso

Université Polytechnique de Bobo

THEME : ANALYSE DES DIFFERENTES METHODES DE MODELISATION ET

COMPARAISON

Etudiants

BARRO Drissa

TRAORE Ibrahim

Enseignant

Dr Loe SANOU



A- Les diff érentes Techniques de

modelisation des systemesd'information existantes.

Les méthodes d'analyse et de conception peuvent être divisées en quatre grandes

familles :

I-Les méthodes cartésiennes

Avec ces méthodes (SADT, SA-SD), le système étudié est abordé par les fonctions

qu'il doit assurer plutôt que par les données qu'il doit gérer. Le processus de conception est vu

comme un développement linéaire. Il y'a décomposition systématique du domaine étudié en

sous domaines, eux-mêmes décomposés en sous domaines jusqu'à un niveau considéré

élémentaire.

Exemple: La méthode d'analyse structurée SADT

La méthode SADT (Structured Analysis and Design Technique) est une méthode

d'analyse particulièrement bien adaptée à la phase de spécification fonctionnelle d'un système.

Elle permet non seulement de décrire les tâches du projet et leurs interactions, mais aussi de

décrire le système que le projet vise à étudier, créer ou modifier, en mettant notamment en

évidence les parties qui constituent le système, la finalité, le fonctionnement de chacune, et les

interfaces entre les diverses parties qui font qu'un système n'est pas une simple collection

d'éléments indépendants, mais une organisation structurée de ceux-ci dans une finalité

précise. SADT cherche à répondre aux niveaux conceptuel et organisationnel d'abstraction et

donc à séparer la phase d'analyse de la phase de conception (le quoi du comment). SADT

utilise une approche de décomposition descendante (top down), modulaire et hiérarchique. La

première description est la description la plus générale possible.

Modéliser un système consiste à en donner une représentation qui énumère les quatre

ensembles d'éléments ci-dessus en les distinguant les uns des autres, et en montrant les

relations :

La fonction, qui apporte la valeur ajoutée à la matière d'oeuvre.

Les éléments constitutifs (sous-systèmes, composants,) qui, inclus dans la frontière,supportent la fonction.



La matière d’oeuvre sur laquelle s'exerce son action.

Les données d'entrée, ou de contrôle, qui provoquent ou modifient la mise en oeuvre

de la fonction .

Dans une analyse SADT, on peut modéliser deux types d'analyse. L'analyse par des

actigrammes (bo î tes d'action) et l'analyse par des datagrammes (bo î tes de donnée).

Sur des actigrammes, les actions sont reliées entre elles par des flux de données alorsque les datagrammes se sont les données qui sont reliées entre-elles par des flux d'activité.

1-Les Datagrammes et les actigrammes

Un diagramme d'activité est identifié par un verbe d'action. Il sollicite une donnée

d'entrée qui est transformée, modifiée ou changée d'état pour générer une donnée de sortie. Ce

processus s'effectue suivant certains mécanismes et sous des directives de contrôle. Les

données de contrôle ne sont pas modifiées par l'activité, par opposition aux données d'entrée.Elles peuvent déclencher, inhiber ou jouer le rôle de paramètre sur l'activité. Les mécanismes

représentent les moyens de réaliser l'activité, le comment. Les flèches d'entrée, de sortie et de

contrôle sont identifiées dans les datagrammes par des noms.

......Le diagramme de données crée, à partir d'activités d'entrées (les activités génératrices),

une donnée utilisée par l'activité de sortie. Le processus s'effectue sous l'influence d'activités

de contrôle et en utilisant des mécanismes de support de la donnée. Les activités génératrices,

utilisatrices et de contrôle sont identifiées par des verbes et la donnée par un nom. Les

mécanismes sont ceux servant à mémoriser la donnée.

Figure représentant le Diagramme d'activité et le diagramme de donnée

2- Organisation hiérarchique des diagrammes

Les diagrammes sont organisés de façon hiérarchique (figure 3.3). L'actigramme

correspondant au système global est l'actigramme A-0 (lire A moins zéro). La premièredécomposition correspond à l'actigramme A0. Les actigrammes du niveau suivant sont



numérotés A1, A2, A3, An et les actigrammes de niveau inf érieur A11, A12,.., A1n. Le

datagramme correspondant au système global est le datagramme D-0, et les datagrammes

suivants D0, puis D1, D2, D3, ... Dn.

......Les conditions d'activation permettent de spécifier l'ordre dans lequel les

contraintes sur les données sont satisfaites dans les actigrammes.

Figure repré sentant l’Organisation hié rarchique des diagrammes

II- Les méthodes systémiques

Dans les méthodes systémiques (Merise, REMORA, etc.), le système est abordé à

travers l'organisation des systèmes constituants l'entreprise. Elles aident donc à construire un

système en donnant une représentation de tous les faits pertinents qui surviennent dans

l'organisation en s'appuyant sur plusieurs modèles à des niveaux d'abstraction diff érents

(conceptuel, organisationnel, logique, physique, etc.)

Exemple: Une méthode d'analyse informatique: Merise

La méthode Merise est une méthode d'analyse, de conception et de réalisation de

systèmes d'informations informatisés. Elle propose une méthode de conception et de

développement de Systèmes d'Information complète, détaillée, en grande partie formalisée,

qui garantit (en principe) une informatisation réussie.

Elle est essentiellement française. Elle a des équivalents à l'étranger en ce qui concerne

les modèles de données (avec des diff érences, par exemple les cardinalités ne sont pas aussi

détaillées dans les modèles anglo-saxons). En revanche la modélisation des traitements est

beaucoup plus complexe que dans les méthodes anglo-saxonnes.

La méthode Merise est bien adaptée à l'automatisation de tâches séquentielles degestion pure. En revanche, elle est mal adaptée aux environnements distribués, où de



multiples applications externes à un domaine viennent interagir avec l'application à modéliser.

De plus, elle n'est pas en mesure de modéliser les informations à caractère sémantique

(documents,...).

La méthode Merise d'analyse et de conception propose une démarche articulée

simultanément selon 3 axes pour hié rarchiser les préoccupations et les questions auxquelles

répondre lors de la conduite d'un projet:Cycle de vie : phases de conception, de réalisation, de maintenance puis nouveau

cycle de projet.

Cycle de décision : des grands choix (Étude préalable), la définition du projet (étude

détaillée) jusqu'aux petites décisions des détails de la réalisation et de la mise en œuvre du

système d'information. Chaque étape est documentée et marquée par une prise de décision.

Cycle d'abstraction :niveaux conceptuels,logique/organisationnel et

physique/opérationnel (du plus abstrait au plus concret). L'objectif du cycle d'abstraction est

de prendre d'abord les grandes décisions métier, pour les principales activités (Conceptuel)

sans rentrer dans le détail de questions d'ordre organisationnel ou technique.

Les principales caractéristiques de la méthode sont: Approche globale menée parallèlement sur les données et les traitements.

Description du système d’information en trois niveaux ;

Découpage du processus de développement en quatre étapes :

1-Étude préalable:

recueil des infos ;

diagramme des flux ;

élaboration des MOT (mod èle organisationnel des traitements) et MCD

(mod èle conceptuel des donné es) actuels ;

synthèse et bilan (services rendus, analyse des insuffisances, synthèse des

besoins d'amélioration).

choix MCD et MCT (mod èle conceptuel des traitements) nouvelle solution

évaluation nouvelle solution

2-Étude détaillée:

MCD, MCT, MLD (mod èle logique des donné es) et MOT nouvelle solution

Conception générale: Description des MCD, MCT, MLD, MOT. Définir

l'environnement de développement (matériel et logiciel). Mise en oeuvre du

dictionnaire des données. Etude préliminaire de la mise en oeuvre (ébauche:

plan de formation, documentation, plan de réception, démarrage, initialisationdes données). Etude des solutions dégradées.

conception détaillée: Spécification détaillée des phases «temps réel» et «temps

diff éré». Validation données traitements (optimisation du MLD, ébauche du

MPD (mod èle physique des donné es)). Evaluation de la charge de réalisation

(durée), évaluation de la mise en oeuvre, plane d’équipements matériels

logiciels.

3-Réalisation:

Etude technique: Description de l'environnement technique, description de

l'architecture du logiciel, description du modèle physique des données.



Production du logiciel: Ecriture du logiciel (en appliquant les méthodes du

génie logiciel), tests unitaires (par unité de traitement) et d'intégration.

4-Mise en oeuvre:

Mise en place des moyens: Moyens techniques (locaux, matériel informatique,

fournitures...). Moyens humains (formation des utilisateurs, mise en place desfichiers et de la documentation.

Réception et lancement: Exécution des jeux d'essais utilisateurs. Conformité

avec le dossier d'étude détaillée. Lancement du nouveau système en vraie

grandeur (en parallèle avec le système existant) pendant une période

d'observation. Arrêt de l'ancien système.

Description de la structure de travail:

Comité directeur: fixe les orientations, prend les décisions importantes...

Groupe projet: seule structure permanente, il comprend le chef de projet

informatique, les concepteurs et les réalisateurs des logiciels, les représentants

du groupe utilisateur. C'est lui qui réalise les dossiers d'étude et les logiciels.

Comité utilisateur: participe à l'élaboration des solutions, à la validation des

dossiers d'étude produits par le groupe projet.

III- Langage de modélisation objet (UML)

Quelques méthodes de conception objet

UML (Unified Modeling Langage) est un langage de modélisation graphique et textuel

destiné a comprendre et à décrire les besoins, spécifier et documenter des systèmes, définir

des architectures logicielles, concevoir des solutions et communiquer des points de vue.

Le langage UML suit une démarche itérative et incrémentale et celle-ci est

piloté par les Use Cases (les cas d’utilisations). La plupart des méthodes objets sont basées les

principes du langage UML.

Exemples de méthodes de conception objet



L'approche objet permet d'appréhender un système en centrant l'analyse sur les

données et les traitements à la fois. Les stratégies orientées objet considèrent que le système

étudié est un ensemble d'objet coopérant pour réaliser les objectifs des utilisateurs. Les

avantages qu'offre une méthode de modélisation objet par rapport aux autres méthodes sont la

réduction de la « distance » entre le langage de l'utilisateur et le langage conceptuel, le

regroupement de l'analyse des données et des traitements, la réutilisation des composants mis

en place.

1-UP (Unified Process)

1.1. Définition et caractéristiques

Le Processus Unifié (UP) est un processus de développement logiciel :

Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1

mois) qui permettent de mieux suivre l’avancement global. A la fin de chaque itération, une

partie exécutable du système final est produite, de façon incrémentale.

Figure Illustrant le caractè re ité ratif de UP

Centré sur l’architecture : tout système complexe doit être décomposé en parties

modulaires afin de garantir une maintenance et une évolution facilitées. Cette architecture



(fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas seulement

documentée en texte.

Mod èle repré sentant les 4+1 vues de Kruchten

Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt

mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre

déterminent l’ordre des itérations.Conduit par les cas d’utilisation : le projet est mené en tenant compte des besoins et

des exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés, décrits

avec précision et priorisés.

1-2.Les phases du Processus Unifié

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.UP répond aux préoccupations suivantes : QUI participe au projet ?, QUOI, qu'est-ce

qui est produit durant le projet ?, COMMENT doit-il être réalisé ?, QUAND est réalisé

chaque livrable ? De ce fait on a quatre phases principales :

La phase d’initialisation : Elle consiste à définir la " vision " du projet, sa portée, sa

faisabilité, son " business case ", afin de pouvoir décider au mieux de sa poursuite ou de son

arrêt.

La phase d’élaboration : Elle poursuit trois objectifs principaux en parallèle :

Identifier et décrire la majeure partie des besoins utilisateurs,

Construire l’architecture de base du système,

Lever les risques majeurs du projet.



La phase de construction consiste surtout à concevoir et à implémenter l’ensemble

des éléments opérationnels (autres que ceux de l’architecture de base). C’est la phase la plus

consommatrice en ressources et en effort.

La phase de transition permet de faire passer l’application des développeurs aux

utilisateurs finaux.

L’approche itérative est fondée sur la croissance et l'affinement successifs d’un

système par le biais d’itérations multiples, feed-back et adaptation cycliques permettant de

converger vers un système satisfaisant. Le système cro î t avec le temps de façon incrémentale,

itération par itération, et c’est pourquoi cette méthode porte également le nom de

développement itératif et incrémental. Il s’agit là du principe le plus important du Processus

Unifié.

Figure repré sentant les phases du processus unifié

2-Le 2TUP (2 Track Unified Process)

2.1. Definitions et caracteristiques

2TUP est un processus unifié récent. Il est construit sur UML et a aussi les mêmes

caractéristiques que UP c’est-à-dire itératif, centré sur l’architecture et conduit par les cas

d’utilisation. Il apporte une réponse aux contraintes de changement continuel imposées aux

systèmes d’informations. 2TUP peut se décomposer et se traiter parallèlement, suivant un axe

fonctionnel et un axe technique. A l’issue des évolutions du modèle fonctionnel et de

l’architecture technique, la réalisation du système consiste à fusionner les résultats de ces

deux branches du processus.

2.2. L’architecture 2TUP

Cette architecture est composée d’une branche fonctionnelle qui regroupe trois phases

(captures des besoins fonctionnels, spécifications fonctionnelles et l’analyse) ; d’une branche



technique (capture des besoins techniques, architecture logicielle et applicative, frameworks

techniques) et d’une phase de réalisation (conception, codage, tests, recettes, déploiement) qui

est le résultat des deux branches (technique et fonctionnelle). Le schéma suivant est une

illustration de l’architecture 2TUP :

3- Méthodes agiles (AM = Agile Modeling)

Méthodes agiles sont des méthodes itératives à planification souple qui leur permettent

de s'adapter à la fois aux changements de contexte et de spécifications du projet.

Les caractéristiques des méthodes agiles :

Le manifeste

Les méthodes agiles s’appuient sur quatre valeurs principales qui permettent le

développement rapide et l’adaptation au changement :

priorité aux personnes et aux interactions sur les procédures et les outils,

priorité aux applications fonctionnelles sur une documentation pléthorique,

priorité de la collaboration avec le client sur la négociation de contrat,

priorité de l'acceptation du changement sur la planification.

Ces quatre valeurs sont déclinées sur douze principes plus généraux qui caractérisent

en détail les méthodes agiles.



Les principes

Délivrer rapidement et très fréquemment des versions

opérationnelles, pour favoriser un feed-back client permanent. Accueillir favorablement le changement

Assurer une coopération forte entre client et développeurs

Garder un haut niveau de motivation

Le fonctionnement de l’application est le premier indicateur du

projet

4- XP (Extreme Programming)

Ensemble de bonnes pratiques de développement qui vise à remettre le développeur aucentre du processus de développement. Ses prises de positions originales (et extrêmes) lui ont

valu un succès d'estime depuis 4 ou 5 ans, surtout aux Etats-Unis.

Voici les principaux éléments du fonctionnement de XP :

Gestion des livraisons : L'équipe fournit des livraisons fréquentes au client. Le

contenu de ces livraisons est décidé par le client lui-même, à partir des estimations fournies

par les développeurs.

Gestion des itérations : Les livraisons sont réalisées en une suite d'itérations

de 2 semaines environ, au sein desquelles le projet est géré à un niveau de détail plus fin.

Suivi du projet : L'avancement du projet est mesuré de manière concrète par

une batterie de tests de recette automatiques. Le rythme de progression est réévalué à chaque



itération, et le plan de développement lui-même est revu fréquemment pour tirer parti de

l'expérience acquise au cours du projet.

Qualité du design et du code : Des pratiques strictes permettent de garder une

vitesse de développement élevée tout au long du projet, tout en gardant une ouverture

maximale au changement. La conception reste toujours le plus simple possible, le code est

nettoyé en permanence et des tests unitaires de non régression sont écrits pour chaque classe.

Travail en équipe : L'équipe travaille réellement... en équipe. Le code est

partagé par tous, les développeurs travaillent systématiquement en binômes, et l'intégration

est quasiment continue."

5- La méthode RAD

Aujourd'hui, qualité et réactivité font partie des objectifs généraux de beaucoup

d'entreprises. Cela entra î ne un certain nombre de projets, qui tout en apportant satisfaction

aux utilisateurs, doivent être menés dans un délai court. C'est à cela que répond la méthodeRAD. RAD est une méthode basée sur le partenariat. L'utilisateur s'affirme le vrai ma î tre de

son application et, par sa participation active, il s'en approprie la réalisation. Le RAD et le

prototypage permettent de réaliser en concevant, tout en testant ce que l'on réalise. La

méthode RAD propose de remplacer le cycle de vie classique par un autre découpage

temporel. Le déroulement est d'abord linéaire, puis il suit le modèle de la spirale. Les étapes

sont au nombre de cinq :

La phase d'Initialisation : Cette phase permet de définir le périmètre général du

projet, de structurer le travail par thèmes, de sélectionner les acteurs pertinents et

d'amorcer une dynamique de projet. Elle représente environ 6% du projet en charge.

La phase Expression des besoins : Cette phase permet de spécifier les exigences du

système lors des entretiens avec les utilisateurs et de définir la solution globale sur les plans

stratégique, fonctionnel, technologique et organisationnel. Cette phase représente environ 9%

du projet.

La phase de Conception : Cette phase permet de concevoir et de modéliser le futur

système avec le concours des utilisateurs pour l'affinage et la validation des modèles. C'est

aussi dans cette phase que nous validons le premier niveau de prototype présentant

l'ergonomie et la cinématique générale de l'application. Cette phase représente environ 23%

du projet.

La phase de Construction (développement itératif) : Durant cette phase, notre équipe

développe l'application module par module. L'utilisateur participe toujours activement aux

spécifications détaillées et à la validation des prototypes. Plusieurs sessions itératives sont

nécessaires. Cette phase représente environ 50% du projet.

La phase de mise en œuvre : Des recettes partielles ayant été obtenues à l'étape

précédente, il s'agit dans cette phase d'officialiser une livraison globale et de transf érer le

système en exploitation et maintenance. Cette phase représente environ 12% du projet.

IV- Approche orientée aspect



Bien qu'en étant encore à ses débuts, la Programmation Orientée Aspect commence

à se faire conna î tre et séduit. C'est un principe novateur qui permet de résoudre les problèmes

de séparation des préoccupations d'une application. Le code résultant devient plus lisible,

réutilisable et le remplacement de composants se fait rapidement et à moindre coût du fait de

la séparation des préoccupations. Cette séparation se fait par la création d'aspects contenant le

code à greffer à l'application. Un programme appelé « tisseur » greffe ensuite les aspects de

façon statique après la compilation, ou de façon dynamique au moment de l'exécution.

Il existe dé jà des tisseurs matures, comme AspectJ pour Java, qui est parfaitement

intégré à Eclipse grâce au plug-in AJDT. La plateforme .NET possède aussi des tisseurs très

prometteurs, tels que AspectDNG qui permet dé jà une utilisation professionnelle.

B- Analyses comparatives des

diff érentes techniques de modélisation

Méthodes Forces Faiblesses

Mé

thodescartésiennes

(SADT,SA/SD,

JSD /JSP…)

1. La décomposition

fonctionnelle garantit la conformité de

la conception aux besoins des

utilisateurs puisque calquée sur leurs

fonctions.

2. La simplicité et bon sens,car basée sur le bon sens et une

démarche naturelle pour aborder le

problème.

3. Adéquation à capturer les

besoins des utilisateurs

4. Capacité à produire des

solutions à plusieurs niveaux

d'abstraction

1.

À son plus haut niveau, un

système ne remplit qu’une seule fonction

générale, ne permet pas la modélisation de

systèmes complexes.

2. Les règles de décomposition non

explicites produisent des niveaux dedécomposition diff érents suivant les

analystes.

3. La volatilité des fonctions fait

qu’un SI est en continuelle évolution, d’où

la difficulté de réutilisation de la conception.

4. effort sur les fonctions au

détriment des données

Méthodes

Systémiques

(MERISE,IDA,

REMORA,

NIAM….)

1. La perception globale

permet une vue moins redondante et

plus cohérente des informations (à

travers la notion de base de données).

2. La capacité de décrire des

systèmes complexes.

3. Grande cohérence des

données niveaux d'abstraction bien

définis (Ansi/Sparc/X3):niveau

externe, niveau conceptuel, niveau

interne

1. La dichotomie donnée traitements

conduisent à une impossibilité de validation

mutuelle des deux modèles.

2. Manque de cohérence entre

données et traitements

3. Faiblesse de la modélisation des

traitements, mélange des contraintes et des

contrôles



Méthodes Objets

(UP, 2TUP, XP,

RAD ….)

1. Capacité à modéliser des

objets complexes.

2. Exprimer de façon intégrée

la dynamique des objets.

3. Réduire distorsions entresystème informatique et monde réel

4. Intégration des traitements

aux données

5. Encapsulation

1. Perception et représentation

monolithiques des applications à cause du

concept unique d’objet.

2. Absence de la notion de fonction qui est

une réalité des organisations.3. "tout objet" difficile à appréhender

4. Aspect fonctionnel mal représenté

5 .Aspect procédural des opérations

Approche orientée

aspect

1. Maintenance aisée : les modules

techniques, sous forme d'aspect,

peuvent être maintenus plus

facilement du fait de son détachement

de son utilisation,2. Meilleure réutilisation : tout module

peut être réutilisé sans se préoccuper

de son environnement et

indépendamment du métier ou du

domaine d'application. Chaque

module implémentant une

fonctionnalité technique précise, on

n'a pas besoin de se préoccuper des

3. Evolutions futures : de nouvelles

fonctionnalités pourront êtreimplémentées dans de nouveaux

modules qui interagiront avec le

système au travers des aspects.

4. Gain de productivité : le

programmeur ne se préoccupe que de

l'aspect de l'application qui le

concerne, ce qui simplifie son travail.

5. Amélioration de la qualité du code :

la simplification du code qu'entra î ne la

programmation par aspect permet de

le rendre plus lisible et donc de

meilleure qualité.

Par contre le tissage d'aspect qui n'est

finalement que de la génération automatique

de code inséré à certains points d'exécution

du système développé, produit un code qui

peut être difficile à analyser (parce quegénéré automatiquement) lors des phases de

mise au point des logiciels (débogages, test).

Mais en fait cette difficulté est du même

ordre que celle apportée par toute

décomposition non linéaire (fonctionnelle

ou objet par exemple).

projet[methode d_'analyse comparée][barro drissa et traoré ibrahim]

Documents