--CCoo uurrss PPrriivvééss Conception

Page (1 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO

--- CCC ooo uuu rrr sss PPP rrr iii vvv ééé sss

CCoonncceeppttiioonnddee

SSyyssttèèmmeess dd’’IInnffoorrmmaattiioonn

GGGnnnééénnneeessssssiiiooo RRRooobbbeeerrrtttAAAssssssiiissstttaaannnttt eeennn IIInnnfffooorrrmmmaaatttiiiqqquuueeeAAA lll'''IIInnnppp HHHbbbBBBppp 111000999333 YYYaaammmooouuussssssooouuukkkrrrooo



SOMMAIRE

AVANT PROPOS-----------------------------------------------------------------------------------------------

I. NTRODUCTION-------------------------------------------------------------------------------------

1.1. Besoins de méthodes -------------------------------------------------------------------------------------------------------------------------------

1.2. Définition d'une méthode ---------------------------------------------------------------------------------------------------------------------------

1.3. Méthode MERISE ------------------------------------------------------------------------------------------------------------------------------------

II. LES DIVERSES MUTATIONS DU SYSTEME D’INFORMATION -----------------

2.1. Origine --------------------------------------------------------------------------------------------------------------------------------------------------

2.2. Evolution de MERISE -------------------------------------------------------------------------------------------------------------------------------

III. PRINCIPES FONDAMENTAUX DE MERISE--------------------------------------------

3.1. Notion de système -----------------------------------------------------------------------------------------------------------------------------------

3.2. Modélisation systémique de l'entreprise--------------------------------------------------------------------------------------------------------

3. 4. Informatisation d'un système d'information ----------------------------------------------------------------------------------------------------

3.5. Statique et dynamique du SI ----------------------------------------------------------------------------------------------------------------------

IV. LES TROIS COMPOSANTES DE LA METHODE MERISE. -------------------------

4.1. La démarche ou cycle de vie. ---------------------------------------------------------------------------------------------------------------------

4.2. Les raisonnements ou cycle d'abstraction -----------------------------------------------------------------------------------------------------

4.2.1. Présentation du cycle----------------------------------------------------------------------------------------------------------------------

4.2.2. Les modèles du cycle d'abstraction----------------------------------------------------------------------------------------------------

4.3. La maîtrise ou cycle de décision -----------------------------------------------------------------------------------------------------------------

4.4. Cheminement du processus de conception ---------------------------------------------------------------------------------------------------

4.5. Typologie des systèmes d'informations---------------------------------------------------------------------------------------------------------

4.6. Les systèmes d'information globaux (EDI) -----------------------------------------------------------------------------------------------------

CONCEPTION DU SYSTEME D'INFORMATION ORGANISATIONNEL -------------------

V. DECOUPAGE EN DOMAINES, ANALYSE DES FLUX.--------------------------------

5.1. Découpage en domaines---------------------------------------------------------------------------------------------------------------------------

5.2. Analyse des flux --------------------------------------------------------------------------------------------------------------------------------------

5.2.1. Acteurs ---------------------------------------------------------------------------------------------------------------------------------------

5.2.2. Flux --------------------------------------------------------------------------------------------------------------------------------------------

5.2.3. Diagramme des flux -----------------------------------------------------------------------------------------------------------------------

5.2.4. Matrice des flux -----------------------------------------------------------------------------------------------------------------------------

5.3. Utilisation de l'analyse des flux pour le découpage en domaine.-------------------------------------------------------------------------

VI. MODELISATION CONCEPTUELLE DES TRAITEMANTS -------------------------

6.1. Introduction. -------------------------------------------------------------------------------------------------------------------------------------------


6.1.1. Définition--------------------------------------------------------------------------------------------------------------------------------------

6.1.2. Objectifs --------------------------------------------------------------------------------------------------------------------------------------

6.2. Formalisme de modélisation des traitements -------------------------------------------------------------------------------------------------

6.2.1. L'acteur ---------------------------------------------------------------------------------------------------------------------------------------

6.2.2. L'événement / Résultat – Message ----------------------------------------------------------------------------------------------------

6.2.3. L'état (Nouvelle notion) ------------------------------------------------------------------------------------------------------------------

6.2.5. Le processus --------------------------------------------------------------------------------------------------------------------------------

6.3. Règles de vérification -------------------------------------------------------------------------------------------------------------------------------

6.3.1. Règles de syntaxe -------------------------------------------------------------------------------------------------------------------------

6.3.2. Règles de fonctionnement ---------------------------------------------------------------------------------------------------------------

6.4.1. Règles de traitement ----------------------------------------------------------------------------------------------------------------------

6.4.2. Etapes de construction d'un MCT ------------------------------------------------------------------------------------------------------

VII. MODELISATION CONCEPTUELLE DES DONNEES

7.1. Introduction --------------------------------------------------------------------------------------------------------------------------------------------

7.2. Construction d'une liste d'information -----------------------------------------------------------------------------------------------------------

7.3. Formalisme et description des données au niveau conceptuel --------------------------------------------------------------------------

7.3.2. L'entité type ----------------------------------------------------------------------------------------------------------------------------------

7.3.3. La relation type------------------------------------------------------------------------------------------------------------------------------

7.3.4. Variété de relations types ----------------------------------------------------------------------------------------------------------------

7.3.5. Les cardinalités d'une entité type dans une relation type. ------------------------------------------------------------------------

7.3.6. Types et sous-types d'entités------------------------------------------------------------------------------------------------------------

7.3.7. Dépendances fonctionnelles entre entités d'une relation -------------------------------------------------------------------------

7.3.8. Dépendances fonctionnelles interrelations ------------------------------------------------------------------------------------------

7.4. Complément sur le formalisme entité relation -----------------------------------------------------------------------------------------------------------

7.5. Construction du modèle conceptuel de données. --------------------------------------------------------------------------------------------

7.5.1. Règles de gestion --------------------------------------------------------------------------------------------------------------------------

7.5.2. Approche inductive-------------------------------------------------------------------------------------------------------------------------

7.5.3. Approche déductive------------------------------------------------------------------------------------------------------------------------

VIII. MODELISATION ORGANISATIONNELLE DES TRAITEMENTS

8.1. Introduction --------------------------------------------------------------------------------------------------------------------------------------------

8.2. Formalisme de modélisation des traitements au niveau organisationnel. --------------------------------------------------------------

8.2.1. Poste de travail -----------------------------------------------------------------------------------------------------------------------------

8.2.2. L événement / Résultat – Message ----------------------------------------------------------------------------------------------------

8.2.3. L'état-------------------------------------------------------------------------------------------------------------------------------------------

8.2.4. La tâche---------------------------------------------------------------------------------------------------------------------------------------

8.2.5. La règle de traitement ---------------------------------------------------------------------------------------------------------------------

8.2.6. La phase--------------------------------------------------------------------------------------------------------------------------------------

8.2.7. La procédure organisationnelle ---------------------------------------------------------------------------------------------------------

8.2.8. Représentation graphique d'un MOT. -------------------------------------------------------------------------------------------------

8.3. Construction d'un modèle organisationnel de traitements.---------------------------------------------------------------------------------


IX. MODELISATION ORGANISATIONNELLE DES DONNEES

9.1. Introduction --------------------------------------------------------------------------------------------------------------------------------------------

9.2. Choix des données à mémoriser ----------------------------------------------------------------------------------------------------------------

9.3. Quantification du modèle organisationnel de données.-------------------------------------------------------------------------------------

9.3.1. Taille des propriétés -----------------------------------------------------------------------------------------------------------------------

9.3.2. Nombre d'occurrences des entités et des relations --------------------------------------------------------------------------------

9.3.2.1. Mémoires. ------------------------------------------------------------------------------------------------------------------------------------

9.3.2.1. La durée de vie -----------------------------------------------------------------------------------------------------------------------------

9.3.3. Quantification des cardinalités ----------------------------------------------------------------------------------------------------------

9.3.4. Volume global du MOD ------------------------------------------------------------------------------------------------------------------

9.4. Sécurité des données -------------------------------------------------------------------------------------------------------------------------------

9.5. Répartition organisationnelle des données ----------------------------------------------------------------------------------------------------

X. CONFRONTATION DONNEES / TRAITEMENT

10.1. Introduction --------------------------------------------------------------------------------------------------------------------------------------------

10.2. Rôle et nécessité -------------------------------------------------------------------------------------------------------------------------------------

10.3. Confrontation algorithmique détaillée -----------------------------------------------------------------------------------------------------------

10.3.1. Modélisation d'un message --------------------------------------------------------------------------------------------------------------------

10.3.2. Expression des actions sur les données mémorisées. ----------------------------------------------------------------------------------

10.3.3. Algorithme de confrontation détaillée. -------------------------------------------------------------------------------------------------

III CONCEPTION DU SYSTEME INFORMATISE D’INFORMATION

XI. MODELISATION LOGIQUE DES TRAITEMENTS

11.1. Introduction --------------------------------------------------------------------------------------------------------------------------------------------

11.2. Formalisme de modélisation des traitements au niveau logique. ------------------------------------------------------------------------

11.2.1. La machine logique ------------------------------------------------------------------------------------------------------------------------

11.2.2. L'événement / Résultat – Message ----------------------------------------------------------------------------------------------------

11.2.3. L'état-------------------------------------------------------------------------------------------------------------------------------------------

11.2.5. La procédure logique ----------------------------------------------------------------------------------------------------------------------

11.3. Conception des modèles logiques de traitements (MLT)-----------------------------------------------------------------------------------

11.3.1. Trois approches de conception des MLT --------------------------------------------------------------------------------------------

11.3.1.1. La décomposition des tâches organisationnelles-----------------------------------------------------------------------------------

11.3.1.2. Réutilisation des ULT----------------------------------------------------------------------------------------------------------------------

11.3.1.3. Conception des ULT autour des données. ------------------------------------------------------------------------------------------

11.3.2. Modularité des MLT------------------------------------------------------------------------------------------------------------------------

11.4. MLT repartis -------------------------------------------------------------------------------------------------------------------------------------------

11.4.1. Démarche de répartition ------------------------------------------------------------------------------------------------------------------

11.4.2. Modalités de répartition -------------------------------------------------------------------------------------------------------------------

11.5. Exemple pratique d'un MLT futur ----------------------------------------------------------------------------------------------------------------


XII. MODELISATION LOGQIUE DES DONNEES (MLD)

12.1. Introduction --------------------------------------------------------------------------------------------------------------------------------------------

11.2. Modèle logique de données relationnelles-----------------------------------------------------------------------------------------------------

11.2.1. Concepts de base d'un modèle relationnel ------------------------------------------------------------------------------------------

11.2.2. Eléments d'algèbre relationnelle--------------------------------------------------------------------------------------------------------

11.2.3. Processus de normalisation -------------------------------------------------------------------------------------------------------------

11.2.4. Notion de vues relationnelles

11.2.5. Formalisme graphique du modèle relationnel. --------------------------------------------------------------------------------------

11.2.6. Règles de transformation du formalisme Entité Relation en formalisme relationnel ---------------------------------------

11.2.7. Prise en compte des sous-types du MCD/MOD ------------------------------------------------------------------------------------

11.2.8. Prise en compte de l'historisation ------------------------------------------------------------------------------------------------------

11.3. Intégrité dans les bases de données relationnelles------------------------------------------------------------------------------------------

11.4. Prise en compte les contraintes d'intégrité-----------------------------------------------------------------------------------------------------

11.4.1. Contraintes intra entité --------------------------------------------------------------------------------------------------------------------------

11.4.2. Contraintes intra relation -----------------------------------------------------------------------------------------------------------------

11.4.3. Quelques exemples d'utilisation du langage SQL

11.5. Quantification des modèles logiques de données -------------------------------------------------------------------------------------------

11.6. Construction d'un modèle logique----------------------------------------------------------------------------------------------------------------

XII. MODELE PHYSIQUE DE DONNEES

12.1. Modèles physiques de données---------------------------------------------------------------------------------------------------------------------------

12.1.1. Objectifs des SGBD -----------------------------------------------------------------------------------------------------------------------

12.2. Modèle physique de traitements------------------------------------------------------------------------------------------------------------------

XIII. OPTIMISATION DES MODELES DE DONNEES

13.1. Introduction --------------------------------------------------------------------------------------------------------------------------------------------

13.2. Optimisation du modèle relationnel --------------------------------------------------------------------------------------------------------------

13.2.1. Optimisation par valorisation de l’activité des traitements sur la base de données ----------------------------------------

13.2.2. Optimisation par choix d’une organisation des tables -----------------------------------------------------------------------------

IV LA DEMARCHE MERISE

XIV. LE SCHEMA DIRECTEUR

14.1. Objectifs ------------------------------------------------------------------------------------------------------------------------------------------------

14.2. Différentes démarches------------------------------------------------------------------------------------------------------------------------------

14.2.1. Approches mono domaine ---------------------------------------------------------------------------------------------------------------

14.2.2. Approche simultanée des domaines avec intégration de l’étude préalable --------------------------------------------------

14.2.3. Approche simultanée des domaines avec esquisse conceptuelle--------------------------------------------------------------

14.3. Découpage du SI en domaines -------------------------------------------------------------------------------------------------------------------


XV. ETUDE PREALBLE

15.1. Objectifs ------------------------------------------------------------------------------------------------------------------------------------------------

15.2. Phases--------------------------------------------------------------------------------------------------------------------------------------------------

15.2.2. Analyse de l’existant -----------------------------------------------------------------------------------------------------------------------

15.2.3. Conception -----------------------------------------------------------------------------------------------------------------------------------

15.2.4. Evaluation et appréciation----------------------------------------------------------------------------------------------------------------

15.3. Conclusions--------------------------------------------------------------------------------------------------------------------------------------------

XVI. L'ETUDE DETAILLEE

16.1. Objectifs ------------------------------------------------------------------------------------------------------------------------------------------------

16.2. Phases-----------------------------------------------------------------------------------------------------------------------------------------------------------

16.2.1. Conception générale ----------------------------------------------------------------------------------------------------------------------

16.2.2. Conception détaillée -----------------------------------------------------------------------------------------------------------------------

16.2.3. Spécification des procédures transitoires --------------------------------------------------------------------------------------------

16.2.4. Spécification des procédures de secours---------------------------------------------------------------------------------------------------

16.3. Conclusion ---------------------------------------------------------------------------------------------------------------------------------------------

XVII. L'ETUDE TECHNIQUE

17.1. Objectifs ------------------------------------------------------------------------------------------------------------------------------------------------

17.2. Phases--------------------------------------------------------------------------------------------------------------------------------------------------

17.3. Architectures ------------------------------------------------------------------------------------------------------------------------------------------

17.3.1 Architectures de données ----------------------------------------------------------------------------------------------------------------

17.3.2. Architectures des programmes transactionnels-------------------------------------------------------------------------------------

17.3.3. Architecture des programmes en réponse différé ----------------------------------------------------------------------------------

17.4. Conclusion ---------------------------------------------------------------------------------------------------------------------------------------------

XVIII. LA PRODUCTION DU LOGICIEL

18.1. Objectifs ------------------------------------------------------------------------------------------------------------------------------------------------

18.2. Phases--------------------------------------------------------------------------------------------------------------------------------------------------

XIX. LA MISE EN ŒUVRE

19.1. Objectifs ------------------------------------------------------------------------------------------------------------------------------------------------

19.2. Phases -------------------------------------------------------------------------------------------------------------------------------------------------

19.2.1. La planification de la mise en service -------------------------------------------------------------------------------------------------

19.2.2. Mise en place des ressources-----------------------------------------------------------------------------------------------------------

19.2.3. Mise en exploitation------------------------------------------------------------------------------------------------------------------------

XX. LA MAINTENANCE

20.1. Objectifs ------------------------------------------------------------------------------------------------------------------------------------------------

20.2. Phases--------------------------------------------------------------------------------------------------------------------------------------------------

20.2.1 Prise en compte de la demande de maintenance. --------------------------------------------------------------------------------


20.2.2. Réalisation des modifications -----------------------------------------------------------------------------------------------------------

XXI. MOYENS DE MISE EN ŒUVRE DE LA MEMOIRE MERISE

21.1. Structures et intervenants dans un projet MERISE ------------------------------------------------------------------------------------------

21.1.1. Les structures permanentes. ------------------------------------------------------------------------------------------------------------

21.1.2. Les structures du projet -------------------------------------------------------------------------------------------------------------------

21.1.3. Les structures de conseil -----------------------------------------------------------------------------------------------------------------

21.2. Rôles des structures dans la démarche --------------------------------------------------------------------------------------------------------

21.2.1. Tableau récapitulatif des activités des structures du projet. ---------------------------------------------------------------------

21.2.2. La validation, facteur de qualité---------------------------------------------------------------------------------------------------------

21.3. Outils pour la mise en œuvre ---------------------------------------------------------------------------------------------------------------------

22.3.1. Les ateliers de génie logiciels. ----------------------------------------------------------------------------------------------------------

22.3.2. La notion de dictionnaire------------------------------------------------------------------------------------------------------------------

XXII. MERISE ET LES AUTRES

22.1. Le développement rapide --------------------------------------------------------------------------------------------------------------------------

22.1.1. Contexte des projets micro-informatiques--------------------------------------------------------------------------------------------

23.1.2. Les éléments de la démarche du développement rapide.------------------------------------------------------------------------

23.2. Le client – serveur -----------------------------------------------------------------------------------------------------------------------------------

23.2.1. Présentation de l'architecture client. ---------------------------------------------------------------------------------------------------

23.2.1.1. Le découpage d'une application --------------------------------------------------------------------------------------------------------

23.2.1.2. Dialogue entre un client et un serveur-------------------------------------------------------------------------------------------------

23.2.1.3. Les grands types de client serveur-----------------------------------------------------------------------------------------------------

23.2.1.4. Les différents types de client serveur--------------------------------------------------------------------------------------------------

23.2.2. MERISE et la conception de SI en environnement client - serveur. -----------------------------------------------------------

XIII. MERISE ET L'APPROCHE ORIENTE OBJET

23.1. Introduction --------------------------------------------------------------------------------------------------------------------------------------------

24.2. Transition vers l'objet--------------------------------------------------------------------------------------------------------------------------------

24.2.1. Présentation générale de L'OMT -------------------------------------------------------------------------------------------------------


AVANT PROPOSToute organisation ou entreprise a des obligations légales de productivité ou d’étique qui l'amène à avoir

constamment besoins de s'informer :

- Obligations légales : fournir les éléments comptables à temps et produire des rapports d'activités

(moral et financier).

- Obligations de gestion ou de productivité possibilité d'anticipation et de décision juste pour parer au

plus pressé

- Obligations sociales : possibilité d'assurer et de contrôler les services rendus aux hommes qui leurs

sont liés. Pour leur bien être.

Pour pouvoir assurer ses obligations, l'entreprise doit pouvoir informer à temps ses associés ou être informée de

son environnement. Tout ceci conduit à la nécessité de traiter les informations car :

- Les informations apparaissent souvent à des endroits différents de l'endroit où elles sont stockées

(où elles se trouvent);

- Les informations apparaissent souvent à des moments autres que ceux de leur utilisation ;

- Les informations apparaissent sous des formes autres que celles où elles sont utilisées;

- Les informations doivent être diffusées.

Pour arriver à une diffusion efficiente de l'information, il faudrait que ces informations soient envoyées ou reçues

sous des formes acceptables, compréhensibles, bien structurées, bien organisées.

L'organisation, la structuration et les mécanismes de traitement de l'information en vue de produire un

système d'information capable de faciliter la communication entre les différents acteurs de l'organisation

est l'œuvre du concepteur de systèmes d'information.

Cette conception du SI consiste à :

- Analyser le fonctionnement d'une situation de gestion donnée et juger si des améliorations sont

nécessaires;

- Proposer une application de gestion qui mémorise, traite et diffuse les données, en vue de

remplacer ou de compléter l'ancienne application.

Le SI ainsi conçu aura pour mission de traiter les échanges tout en fournissant des éléments nécessaires à la

prise de décision.

Dans ce cours, il sera question de présenter les démarches ou méthodes qui vont conduire à l'élaboration d'un

bon système d'information. Parmi toutes les méthodes existantes il y a MERISE (Méthode d'Etude et de

Réalisation Informatique par sous Ensemble) qui sera notre point de concentration.

Owner

Highlight

Owner

Typewriter

methode d'analyse et de conception pour l'élaboration d'un bon systeme d'information



I. NTRODUCTION

1.1. Besoins de méthodes

L'élaboration et l'usage de méthodes pour la réalisation d'objets artificiels (conçus et réalisés par l'homme) se

retrouve dans de nombreux domaines tels que le génie civil, le génie chimiques, le génie mécanique, la gestion et

l'informatique. En effet, pour des démarches intuitives conduisant souvent aux échecs, les concepteurs ont

synthétisé leurs expériences en des logiques de raisonnements appelés méthodes.

1.2. Définition d'une méthode

On pourrait associer la définition du mot méthode à une combinaison de deux mots :

- Méthis Le raisonnement rusé ou les ruses de l'intelligence

- Hodas : Le chemin, la voie à suivre.

D'où, méthode pourrait se définir comme étant le chemin de la ruse. On peut aussi dire, système d'opérations

extériorisables qui fasse mieux que l'esprit, le travail de l'esprit. Une troisième définition pourrait être, un

ensemble de démarches que suit l'esprit et l'arrangement qui en résulte.

1.3. Méthode MERISE

La méthode merise est une méthode de conception et de développement de système d'information informatisé.

La nature spécifique du système d'information, à la fois objet naturel et objet artificiel a conduit à définir une

méthode pour sa conception. Cette méthode est un schéma de réflexion fournissant au concepteur un guide

continu indiquant la manière d'aborder les problèmes. Ce sont là les principes généraux de la méthode Merise.

Pour assurer et faciliter la communication entre les intervenants de la conception, la méthode Merise utilise des

modèles. Ces modèles sont exprimés et validés en utilisant un formalisme (formalisme individuel), c'est à dire, un

langage permettant d'identifier et de décrire tous les concepts nécessaires à la spécification des systèmes

étudiés.

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight


II. LES DIVERSES MUTATIONS DU SYSTEME

D’INFORMATION

2.1. Origine

Jusqu'aux années 70, l'informatisation se limitait aux processus administratifs. L'informatisation privilégiait les

traitements au partage de l'information. A partir des résultats à obtenir, on définissait les traitements appropriés,

puis on voyait les données nécessaires. Par conséquent, chaque traitement a son fichier de données.

EXEMPLE : COORIG ET MINOS

Au début des années 70, avec l'apparition des systèmes transactionnels, on a créé des applications intégrées

avec des statistiques, des interrogations aléatoires, des tableaux de bord. Des difficultés apparaissent cependant

:

- Difficile de prendre en compte toutes les activités d'une entreprise

- Les incohérences globales entre les informations des différentes applications

- Une lourdeur dans la mise en œuvre

La fin des années 70 voit avec une technologie de plus en plus puissante la prolifération :

- Des réseaux locaux et étendus

- De la micro informatique avec les traitements conversationnels.

- Des concepts généraux des systèmes de gestion de base de données

- Des outils de développement (AGL).

Tout ceci, ajouté aux expériences antérieures a amené les concepteurs à revoir l'architecture générale de

l'informatique au sein des entreprises. Ces améliorations apportées ont suscité l'émergence de :

- La notion de système d'information

- La nécessité d'une méthode de conception pour la conception et la spécification de système

d'information.

Les anciennes approches par les besoins seront abandonnées au profit de :

- L'approche systémique

- La modélisation des données avec un formalisme et des outils de description.

Les deux réflexions ont été menées essentiellement par une équipe de concepteurs réunis au sein de la CETE

(Centre d'Etudes Techniques et de l'Equipement) en France en Aix_En_Province animé par Hubert Tardieu et


du GRASCE (Ax – Marseille), animé par JL. Le Moigne. Ce sont ces deux groupes qui fondent de 1974 à 1978

les bases théoriques et pratiques dune nouvelle méthode de conception de système d'information.

En 1977, sous l'égide du ministère de l'industrie qui voulait une méthode d'intérêt national, un groupe de travail

s'est mis en place et a fait la synthèse des différents travaux :

- Réactualisation de la spécification des traitements;

- Intégration des nouvelles méthodes orientées système d'information et approche par les données;

- Proposition d'une démarche qui garantisse la rigueur et la facilité d'application.

La méthode Merise naît officiellement en 1979 pour répondre effectivement aux problèmes de conception de

système d'information adaptés aux fonctionnements des entreprises et aux technologies informatiques. Les

premier ouvrages sur la méthodes Merise paraissent en 1983 et 1985 (Tardieu, Roschield, Colleti).

2.2. Evolution de MERISE

Face aux réalités du terrain, Merise va connaître des améliorations et des innovations avec l'extension du

formalisme et l'introduction de nouveaux modèles. Ainsi on aura :

- Extension du formalisme entité - relation avec l'explicitation de types et sous-types, de contraintes

d'intégrité, du formalisme issu du réseau PETRI;

- Développement d'ateliers de génie logiciel (AGL) intégrant la méthode Merise;

- Extension des modèles avec l’introduction des MLT et MOD.

- Ouverture de Merise vers d'autres méthodes (Client – serveur, UML, BPR, orienté objets).

Expériencedes démarches

MERISE

Recherche en informatique de gestion (bases de données, SGBD)

Méthoded’analyse

Recherche en systémiqueAppliqué aux organisation

Owner

Highlight

Owner

Highlight


III. PRINCIPES FONDAMENTAUX DE MERISE

3.1. Notion de système

Un système est un ensemble d'éléments matériels ou immatériels (homme, machines, méthodes, règles,

données, etc.) en interaction, transformant par un processus, des éléments (les entrées) en d'autres éléments

(les sorties). Par exemple, une chaudière transforme par combustion du charbon en chaleur.

3.2. Modélisation systémique de l'entreprise

L'entreprise est composée de trois sous systèmes qui sont :

- Le système opérant (SO), siège de l'activité productive de l'entreprise, c'est à dire chargée de la

transformation des flux (ou ressources) primaires tels que les flux de matières, les flux financiers,

les flux de personnes, les flux d'actifs ou les flux d'information

- Le système de pilotage, siège de l'activité décisionnelle assurée par tous les acteurs de l'entreprise

à des niveaux divers.

- Le système d'information, objet de l'étude

ENVIRONNEMENT

Sous-système de pilotage- Réfléchit (SP)- Décidé- Contrôle

Sous-système d’information- Mémorise- Traite- Diffuse

Sous-système opérant (SO)- Transforme- Produit

Information

Information

Entreprise / Organisation

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight


3.3. Les grandes fonctions du système d'information

Placé comme l'interface entre le système de pilotage et le système opérant, le SI est destiné au SP pour pouvoir

connaître et maîtriser le fonctionnement du SO et au SO lorsque les flux transformés sont des informations. Il

permet :

- La génération des informations, fonction dévolue au système de pilotage. Les informations doivent

être générées avant toute mémorisation

- La mémorisation des informations (transfert des informations dans le temps)

- La communication et la diffusion des informations (Transfert dans l'espace)

- L'exécution de traitements (transfert dans la forme).

Comme on le voit, le système d'information existe indépendamment des techniques, mais ces dernières

amplifient les fonctions de mémorisation, communication et de traitement.

3.4. Informatisation d'un système d'information

L'utilisation des techniques informatiques qui a contribué à amplifier les fonctions du SI a conduit à considérer

deux niveaux d'étude dans l'informatisation du SI:

- Le niveau du système d'information organisationnel (SIO) qui exprime l'activité organisée (Tâches

humaines, tâches informatisées) tourné vers les utilisateurs.

- Le niveau du système d'information informatisé (SII) (Logiciels, Fichiers, bases de données).

La méthode Merise traitera la spécification et la validation du SIO et du SII.

3.5. Statique et dynamique du SI

Avec l'introduction des bases de données, l'idée de séparation de données et traitements (par opposition à

l'ancienne approche) a été diffusée et adoptée mais elle reste artificielle car les données n'ont d'usage qu'à

travers les traitements, les traitements ne peuvent fonctionner sans données.

Cette distinction est présente dans la méthode MERISE.

- Les données représentent l’aspect statique du système d'information. (Ce qui est). Elle présente

une certaine stabilité dans le temps

- Les traitements représentent l'aspect cinématique du SI (ce sui se fait)

L'analyse des données et celle des traitements ne s'effectuent pas dans une ignorance mutuelle. Lorsque la

conception analyse et spécifie les données, il a à l'esprit que ces données vont être utilisées par les traitements,

et inversement.

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight


IV. LES TROIS COMPOSANTES DE LA METHODE

MERISE.

Une méthode s'inscrit dans trois dimensions à savoir :

- La démarche ou cycle de vie

- Le raisonnement ou cycle d'abstraction

- La maîtrise ou cycle de décision.

4.1. La démarche ou cycle de vie.

Le cycle (caractère vivant) se compose d'une conception, une gestation, naissance, une croissance, évolution et

une mort puis d'une renaissance. Dans le cas su système d'information, on a la conception, la réalisation et la

maintenance.

stop

Spécification complète du futurS10. Point de vue de l’utilisateur (externe)

Schéma DirecteurDéfinition des orientationsGénérales du développement à moyen terme du SI

Etude de préalableProposition et évaluation de solution d’organisation et de solution technique

pour SI d’un domaine.

Etude détaillée

Etude techniqueTraduction informatique des spécifications techniques

Production logicielEcriture des programmes Génération des fichiers ou bases de données - Tests

Installation de l’application informatique. Mise en place de la nouvelle organisation.

MaintenancePrise en compte des évolutions et changements qui interviennent dans le système

Mise en œuvre

Spécification complète du futur SII. Point de vue de l’utilisateur (interne)

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight


4.2. Les raisonnements ou cycle d'abstraction

4.2.1. Présentation du cycle

Les problèmes à prendre en compte dans la conception d'un système d'information peuvent être:

- La description du fonctionnement de l'activité (domaine);

- La définition des règles de gestion;

- La définition des informations;

- La répartition des traitements entre l'homme et la machine;

- L'organisation physique des fichiers;

- Le découpage en transactions;

- Le choix du matériel;

- La répartition des responsabilités au sein de la structure.

Ces problèmes conduisent à faire des choix, à effectuer une hiérarchisation des préoccupations en niveaux

d'intérêts homogènes. Cette hiérarchisation de niveaux se présente de la façon suivante :

- Pour la conception du système d'information organisationnel (SIO), il y a deux niveaux :

- Le niveau conceptuel qui exprime les choix fondamentaux de gestion (Recherche des

éléments stables indépendamment des moyens à mettre en œuvre, de leur contrainte et de

leur organisation).

- Le niveau organisationnel qui exprime les choix d'organisation des ressources humaines au

travers de la définition des sites, de postes de travail.

- Pour la conception du SII. Les solutions retenues relèvent essentiellement du choix de l'utilisateur.

Il comprend deux niveaux :

- Le niveau logique qui exprime les choix et moyens informatiques en faisant abstraction de

leurs caractéristiques techniques.

- Le niveau physique qui traduit les choix techniques et la prise en compte de leurs

spécifications.

La conception relève uniquement du savoir faire de l'informaticien

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight

Owner

Highlight


4.2.2. Les modèles du cycle d'abstraction

A chaque niveau d'abstraction correspond un modèle pour le volet statique (les données) et pour le volet

dynamique (les traitements) qui sont :

- Au niveau conceptuel :

- Le MCD (modèle conceptuel de données) qui formalise la signification des informations sur

lesquelles repose le SI, sans contraintes techniques, ni économique.

- Le MCT (Modèle Conceptuel des traitements) qui formalise l'activité du domaine, abordé

sans préciser les ressources ni leur organisation.

- Au niveau organisationnel :

- Le MOT (Modèle organisationnel des traitements qui décrit le fonctionnement du domaine en

précisant les ressources humaines et matérielles mobilisées ainsi que l'organisation de ces

ressources dans le temps et dans l'espace.

- Le MOD (Modèle organisationnel des données) qui précise parmi les données définis dans le

MCD, celles qui sont prises en compte par le SII futur, où ces données sont localisées

(répartition par site organisationnel), leur confidentialité pour chaque intervenant dans

l'entreprise.

SystèmeD’information

naturel

Niveau conceptuel

SystèmeD’informationOrganisation(SIO)

NiveauOrganisationnel

Choix de gestion

Définition des informations et des

activités

Type de ressources et affectation

Choix d’organisation

Niveau logique

SystèmeD’informationInformatisé

(SII)Niveau physique

Choix logique

Moyens et ressourcesinformatiques

Ressources effectives

Choix techniques

APPLICATION INFORMATIQUESUPPORT DU SYSTEME D’INFORMATION

Owner

Highlight

Owner

Highlight


- Au niveau logique :

- Le MLD (Modèle logique de données) qui fournit une description des données en tenant

compte des moyens informatiques de mémorisation et de leurs conditions d'utilisation par les

traitements.

- Le MLT (Modèle logique des traitements) qui d'écrit comment les tâches informatisées sont

définies en terme de logiciel.

- Au niveau physiques :

- Le MPD (Modèle physique des données) qui est une description de la base de données ou

de l'ensemble des fichiers exprimés dans la syntaxe des SGBG ou des SGF adoptés.

- Le MPT (Modèle physique des traitements) qui précise, pour la réalisation, les spécifications

techniques des différents modèles définis.

DONNEES TRAITEMENTS

MCD

Signification des informations sans contraintes techniques ou

économiques

MCT

Activité du domaine sans préciser. Les

ressources ou leur organisation

(Que fait-on et pourquoi ? que signifient les informations)

MOD

Signification des informations avec contraintes organisationnelles et

économiques

MOT

Fonctionnement du domaine avec les

ressources utilisées et leur organisation

(Comment et avec quels moyens logiciels humaines et informatique

MLD

Description des données tenant compte de leurs conditions et des

techniques de mémorisation

MLD

Fonctionnement du domaine avec les

ressources et leurs organisations

informatiques

(comment et avec quels moyens logiciels?) informaticien

MPD

Description de la ou des bases de données dans la syntaxe du logiciel

SGF ou

MPT

Architecture technique des programmes

SGBD (Comment concrétiser compte tenu d'un environnement technique)

SIO : Préoccupation du gestionnaire – utilisateur

SII : Préoccupation de l'informatique

Owner

Highlight

Owner

Highlight


4.3. La maîtrise ou cycle de décision

La maîtrise du déroulement simultané de la démarche et du raisonnement nécessite la prise de décision des

choix à retenir. Le contrôle doit s'effectuer sur les durées, les coûts et la conformité avec l'attente.

L'organisation générale d'un projet informatique se compose de trois groupes:

- Le groupe de pilotage

- Le groupe de projet

- Le groupe de validation

Ainsi, à chaque niveau de développement et à chaque étape, des décisions doivent être prises.

ETAPE DE LA DEMARCHE RESULTAT DECISION

Schéma Directeur Plan de développement des SII Approbation et mise en application

Etude préalable Dossier de choix n solutions Choix d'une solution ou arrêt

Etude détaillée Spécification fonctionnelleAccord utilisateurs/ spécifications

fonctionnelles

Etude technique Spécification technique pour réalisationAccords réalisateurs / spécifications

techniques

Réalisation du logiciel Système réalisé en ordre de marcheRecette provisoire conformité

système

Mise en service Système installé dans l'organisation Recette définitive système un service

Maintenance Système maintenanceRecette simplifiée fin de

maintenance

Remarques

- Les trois dimensions de la méthode Merise sont fondamentales et ne sont pas indépendantes.

- Une méthode sans cycle d'abstraction présenterait une succession de décision sans modèle. Mi

techniques lui permettant de formaliser ses raisonnements.

- Une méthode sans cycle de vie omet les décisions et n'indique au concepteur aucune démarche de

mise en œuvre.

- Une démarche sans cycle de décision ne doit même pas être envisagée.

Owner

Highlight

Owner

Highlight


4.4. Cheminement du processus de conception

La méthode Merise préconise, lorsque cela est possible, de partir de l'existant, c'est à dire, de la compréhension

du système d'information actuel (niveau logique et physique). Cela passe par:

- L'étude du fonctionnement du domaine (ses activités, son organisation) ;

- L'organisation des différents formats de fichiers et l'architecture de la base de données;

- L'étude des différents documents manuels et informatisés;

- Les entretiens avec les différents acteurs de l'organisation.

A partir de cette compréhension de l'existant, on conservera les grandes finalités afin de mieux appréhender les

nouveaux choix conceptuels que l'entreprise souhaite faire pour son développement futur. Avec ces choix futur,

on construira les modèles appropriés du futur système d'information.

4.5. Typologie des systèmes d'informations

Plusieurs typologies peuvent être considérées à savoir :

- Système d'information de production. L'information est exclusivement destinée au système

opérant (secteur tertiaire telle que assurance, banque, administration. 07866262

- Système d'information opérationnels ou SI primaire qui est directement tourné vers une

représentation. Coordination opérationnelle de l'activité du système opérant (Gestion du

personnelle, du matériel (stocks), commerciale (suivis des commandes). Comptabilité (comptes,

journaux, grands livres). Gestion de production

- Système d'information de pilotage, fournit les informations nécessaires à la prise de décision.

(Système d'information secondaire)

4.6. Les systèmes d'information globaux (EDI)

Les systèmes d'information globaux sont une nouvelle famille de système d'information qui permet aux

entreprises de communiquer entre elles, d'échanger des informations d'où le nom EDI (Echange de Données

Informatisées). Pour une question de compétitivité et de performance concurrentielle, (entreprise système a laissé

la place au système d'entreprise comme stratégie de développement.

Owner

Highlight

Owner

Highlight

Owner

Highlight


CONCEPTION DU SYSTEME

D'INFORMATION

ORGANISATIONNEL


V. DECOUPAGE EN DOMAINES, ANALYSE DES FLUX.

5.1. Découpage en domaines

L'analyse systémique nous a fourni une modélisation de l'entreprise échangeant et transformant des données.

Cependant, l'entreprise dans sa globalité est un système trop complexe pour aborder sa modélisation. Pour réduire

cette complexité et obtenir des tailles de projets facilement maîtrisables, on cherche à découper l'entreprise en

domaine d'activité. Ces domaines sont généralement les grandes fonctions de l'entreprise (Vendre, stocker, acheter,

gérer du personnel, etc.).

Il faudra cependant noter que les domaines d'une entreprise ne sont pas disjoints.

5.2. Analyse des flux

L'analyse des flux permet d'appréhender simplement le fonctionnement global de l'entreprise (unités actives

s'échangeant des flux entre elles) ne se focalisant un ensemble d'activités concernées par l'étude.

5.2.1. Acteurs

Un acteur représente une unité active intervenant dans le fonctionnement du système opérant. Un acteur fait

quelque chose.

5.2.2. Flux

Le flux représente un échange entre deux acteurs. Merise s'intéresse aux flux d'information. Les autres flux

doivent être explicités en termes d'informations. Les flux entre acteurs et données mémoires doivent être traitées

avec délicatesses.

5.2.3. Diagramme des flux

C'est une représentation graphique des acteurs et des flux échangés. Il peut même se substituer au modèle

organisationnel des traitements.


Exemple : Contrôle de la distribution des hydrocarbures en Côte D'Ivoire.

Acteurs : Grands Dépôts. Dépôts consommateurs. Stations Pays limitrophes, BIS. (Système présenter).

5.2.4. Matrice des flux

C'est une représentation matérielle des flux échangés, avec les acteurs qui forment les lignes et les colonnes du

tableau et les flux qui sont dans les cellules. 'L'acteur sur la ligne est émetteur et celui sur la colonne est destinataire

de flux.

Exemple Elle permet de vérifier pour s'assurer qu'aucun flux n'a été omis.

BIS Grands Dépôts Stations & Dépôts Pays

limitrophes

Contrôleurs

BIS

Grands

Dépôts

Stations & dépôts

Consommateurs

Pays limitrophes

Contrôleurs

Ivoiriens

5.3. Utilisation de l'analyse des flux pour le découpage en

domaine.

A partir de tous les acteurs existants dans ce système, on construit un diagramme brut de flux. A partir de ces flux ,

on met en évidence les frontières entre ces domaines.

A partir de la délimitation du domaine étudié, on parlera alors de :

- Acteurs internes, c'est à dire ceux faisant partie des unités actives du domaine étudié?

- Acteurs externes, ce sont ceux se trouvant à l'extérieur des frontières du domaine. La présence de ces

données est obligatoire car le domaine ne vivra que par les échanges (entrant ou sortant) avec les

acteurs externes.


VI. MODELISATION CONCEPTUELLE DES TRAITEMANTS

6.1. Introduction.

6.1.1. Définition

Bien que souvent le terme ²traitement² soit vu comme la transformation de données, donc la description

algorithmique (organigramme), pour Merise, décrire les traitements, c'est décrire les processus déclenchés dans le

domaine en réponse aux stimulations de son environnement.

Un MCT exprime ce que fait le domaine, et non par qui, quand, où et comment ces activités sont réalisées

6.1.2. Objectifs

La modélisation conceptuelle des traitements (MCT) a pour objectifs de représenter formellement les activités

exercées par le domaine en faisant abstraction de l'organisation, c'est à dire des moyens et ressources nécessaires

à l'exécution de ces activités. Il a essentiellement pour buts de :

- Recenser tous les traitements opérés dans le domaine d'application;

- Hiérarchiser ces traitements dans l'ordre conceptuel d'exécution;

- Représenter les différentes règles de traitements et de gestion.

6.2. Formalisme de modélisation des traitements

Pour décrire le niveau conceptuel, le formalisme des traitements utilise les concepts suivants :

- L'acteur

- L'événement / Résultat message

- L'état

- L'opération

6.2.1. L'acteur

Client

Formalisme


6.2.2. L'événement / Résultat – Message

Un événement est un flux d'informations émis par un acteur à destination d'un autre acteur du domaine Un résultat

est la formalisation d'une réaction du domaine et de son système d'information. Un résultat est donc émis par une

activité du domaine à destination d'un acteur. On distingue plusieurs catégories d'événements:

- Externes, modélisant des flux avec un acteur;

- Décisionnels, représentant les échanges avec le système de pilotages;

- Temporel représentant les échéances.

Les résultats et événements sont regroupés par type, c'est à dire toutes les occurrences d'événement et résultats

ayant les mêmes propriétés et les mêmes types d'actions.

Exemple

Un message est un ensemble structuré d'informations décrivant un événement.

6.2.3. L'état (Nouvelle notion)

Un état est une condition préalable à l'exécution d'une opération. Il peut être aussi la conséquence conditionnelle

d'une opération. L'état peut s'exprimer par :

- Une valeur prise par une information (dossier ouvert, dossier en cours, date d'anniversaire)

- Le fait qu'une activité a été réalisée (calcul des pénalités effectué)

- Une règle de traitement (délai de règlement dépassé de 15 jours).

Un état doit être décrit par :

- son nom

Demande

22/12/2002KONAN HenriCarte de CNI

21/11/1999GNENESSIO

RobertMessage

Formalisme de l'événement

Compagnie d’assurance

Client

Déclaration d’accident

Envoi de chèque

Evénement type


- Le nom de l'information décrivant le type délai

- La valeur de l'état

- Eventuellement la règle permettant de déterminer l'état

6.2.4. L'opération

L'opération est la description du comportement du domaine et de son système d'information par rapport aux

événements types. Elle est déclenchée par la survenance d'un événement d'un état ou de la combinaison de

plusieurs états et événements.

Le morcellement d'une opération ne se justifie que par l'attente d'informations complémentaires nécessaires à la

poursuite des activités.

Une opération peut être décrite par:

- Des décisions

- Des règles de gestion

- Des actions sur les données

- Traitements conçus

6.2.4.1. Synchronisation

Elle représente une condition préalable au démarrage de l'opération. Elle permettra aussi le découpage d'un

domaine en plusieurs opérations. Elle se traduit par l'utilisation des expressions logiques telles que ET, OU, NON ou

leur combinaison.

6.2.4.2. Condition d'émission

L'opération produit des résultats et / ou des états. L'émission de ces derniers peut être soumise à des conditions

traduites par des expressions logiques

Conditions d’émission

Liste des fonctions ou actions

NOM DE L’OPERATION

Expression de synchronisation

Nom étatNom Information

ValeurInformation

ArticleDisponibilité

OK


Exemple

Exemple d’une opération

6.2.5. Le processus

Un processus est un ensemble d'événements opérations et résultats consécutifs qui concourent à un même but.

On peut distinguer trois manières de représenter un MCT :

- Le MCT Général représentant les enchaînements des événements, opérations et résultats

- Le MCT orienté processus où sont présentés les événements, les processus et les résultats. (Les

événements et opérations intermédiaires ne sont pas présentés. Ce MCT est aussi appelé Modèle

Général des Processus.

- Le MCT détaillé dans lequel les opérations sont décomposées en opérations élémentaires, avec

représentation des états intermédiaires. Ce MCT est dénommé MCT analytique.

Client Demande


OK


RuptureCommande

Statut

LivréeFactureStatut

Réglée

Et

VENTE DIRECTE AU COMPTANT

- Enregistrer la commande- Facturer- Enregistrer le règlement- Remettre les articles

Article en stock Dernier article vendu

Client

Facture Comptant


6.3. Règles de vérification

Un modèle conceptuel de traitement doit respecter les règles de syntaxe et les règles de fonctionnement.

6.3.1. Règles de syntaxe

Les règles de syntaxes à respecter sont les suivantes :

- Un acteur reçoit au moins un résultat ou émet au moins un événement;

- Un résultat provient d'une opération;

- Tout résultat a au moins une destination (acteur ou opération);

- Une opération est déclenchée soit directement par un événement ou un état, soit par une

synchronisation unique;

- Une synchronisation lie au moins deux événements ou états par une expression logique;

- L'expression logique associée à une synchronisation où à l'émission d'un résultat doit pouvoir prendre

au moins la valeur vrai. Sinon l'opération ne sera jamais déclenchée ou le résultat ne sera jamais émis.

6.3.2. Règles de fonctionnement

6.3.2.1. Cycle

Lorsqu'un état contribue à une synchronisation de l'opération qui produit directement ou indirectement le même état

on dit qu'il y a un fonctionnement cyclique et il doit être contrôlé.

6.3.2.2. Atteignabilité

Un résultat ou état est dit atteignable si l'on peut trouver dans le système une séquence d'activation de

synchronisation et de conditions d'émission qui permettent de produire cet état ou ce résultat.

6.3.2.3. Les conflits

On dit qu'il y a conflit sur un événement / résultat s'il contribue à plusieurs synchronisations ou s'il est destiné à

plusieurs acteurs.


6.4.1. Règles de traitement

Les règles de traitement souvent appelées règles de gestion décrivent les enchaînements des opérations ou

fonctions. Elle rend possible le regroupement des actions au sein d'une seule opération ininterruptible.

Exemple

Règle N°1 : Toute demande d'article est satisfaite selon la disponibilité.

Règle N°2 : On actionne le réapprovisionnement dès que le seuil unité est attesté

6.4.2. Etapes de construction d'un MCT

- Recenser les acteurs et les flux échangés

- Construction du diagramme du flux ou graphe de circulation des données.

- Identifier clairement les événements et les résultats

- Ordonnancer les flux

- Identifier les principaux processus, actions concourant à la même finalité de gestion

- Découper chaque processus en opérations, c'est à dire en un enchaînement d'événements et de

résultats. Pour cela il faut respecter les principes suivants :

- Toutes les activités successives qui n'attendent pas de synchronisation (externes) sont

regroupées en une seule opération.

- Ne pas tenir compte des moyens et des ressources.

- Toutes les fonctions d'une opération ne sont pas toujours exécutées.

- Plusieurs résultats peuvent être émis par la même condition de sortie

Exemple

Soit un système d'information ayant les règles de traitements suivantes :

Règle N 1 : Toute commande de client non solvable est rejetée

Règle N 2: Les commandes de produits indisponibles sont mises en attente et devront déclencher un

réapprovisionnement

Règle N 3 : Les commandes en attente seront déclarées disponibles lorsque le réapprovisionnement sera

suffisant

Règle N 4 : Les commandes de produits disponibles donnent lieu à livraison au client

Règle N 5 : Les livraisons refusées par le client donnent lieu à retour de marchandises

Règle N 6 : Les livraisons acceptées donnent lieu à des factures qui sont conservées jusqu'à règlement

complet


Règle N 7 : Toute facture non réglée à l'échéance donne lieu à relance.

Règle N 8 : Toute facture soldée est archivée

Première étape : Recensement des acteurs et des flux

* Diagramme des flux

Légendes

1. Commande produits

2. Modification de la commande refusée

.3 Demande de la livraison (commande acceptée)

4. Livraison + bon de livraison

5. Retour marchandise

6. Acceptation livraison

7. Facture client

8. Relance client

9. Règlement facture

10. Archivage facture

11. Demande de réapprovisionnement

12. Livraison fournisseur

13. Commande fournisseur

14. Retour commande

Pour ce domaine d'étude, l'événement déclencheur est bien entendu la commande du client.

ArchivesService

commercialService achat

MagasinClient

Comptabilité

Fournisseurs1 2

3 1114

13

12

5

8

7

10 6

9

4


* Ordonnancement des flux

Deuxième étape : identification des principaux processus

* MCT Orienté processus

Ce MCT fait ressortir trois grands processus à savoir la commande, le réapprovisionnement et la comptabilité.

Client Commande

Liste des manquants

Commande refusée

Besoins réapprovisionnement

Livraison client Commande

fournisseur

Livraison fournisseur

Retour marchandise

Facture et attente règlement

RelanceRèglement

Facture soldée

Facture archivée Livraison fournie

Client Commande

COMMANDE

- Examen compte client- Examen des stocks- Mise à jour stock

Livraison

COMPTABILITE

- Calculer la facture- Enregistrer règlement- Faire lettre de relance- Archiver facture

REAPPROVISIONNEMENT

- Commande fournisseur- Contrôle livraison- Mise à jour stock

Facture archivée

Facture archivée


VIII. MODELISATION ORGANISATIONNELLE DES

TRAITEMENTS

8.1. Introduction

Si au niveau conceptuel des traitements on s'est contenté des activités majeures en s'appuyant sur le quoi et le

pourquoi, au niveau organisationnel, on va préciser le comment et va consister à :

- Définir les ressources (techniques, humaines, espaces, temps et données)

- Décomposer les opérations en éléments homogènes plus fins appelés tâches.

- Construire les enchaînements chronologiques des activités.

- Organiser l'ensemble des ressources.

Cette modélisation doit aboutir au modèle organisationnel des traitements MOT. Ce modèle précisera donc la

répartition organisationnelle (répartition entre les unités fonctionnelles) et la répartition de l'architecture logique

(système réparti ou non).

8.2. Formalisme de modélisation des traitements au niveau

organisationnel.

Le MOT reprend en détail les concepts du MCT avec un ajout de nouveaux concepts.

8.2.1. Poste de travail

Un poste de travail type ou poste type est un centre d'activité élémentaire du domaine comprenant tout ce qui est

nécessaire à l'exécution d'un traitement.

Un poste type traduit un niveau de responsabilité des personnes qui exécutant les tâches qui leur sont confiées.

Un poste type, selon les cas peut comprendre :

- Une personne associée à un matériel (secrétaire + clavier et écran : réception d'une clinique)

- Plusieurs personnes partageant un matériel (réception comptoir d'un magasin, 3 vendeurs, 1 clavier, 1

écran, 1 lecteur cartes magnétiques, 1 imprimante)

- Une ou plusieurs personnes sans matériel (aire de stockage d'un magasin avec plusieurs

manutentionnaires)

- Du matériel sans personne spécialisée (lecteur de badges horaires).

Owner

Highlight


Formalisme

Temps Extérieur au domaine Secrétariat Rédacteur

8.2.2. L événement / Résultat – Message

Ce sont les mêmes notions qu'au niveau conceptuel. Cependant, la matérialisation d'un résultat déclenchant une

tâche (spécialement deux tâches s'enchaînant dans le même poste) n'est pas nécessaire. Mais à chaque

chargement de poste ou de phase il est nécessaire de matérialiser l'événement.

Exemples de transformation de MCT en MOT, en termes d'événements.

* Demande client

- Demande initiale

- Demande modifiée

* Remise de chèque

- Chèque sur place de notre banque

- Chèque hors place de notre banque

- Chèque hors place d'une autre banque

* Evénements temporels

- Début / Fin de mois

- Début / Fin de journée

- Chaque jour à 18h

- Le 15 de chaque mois (TVA)

AssuréJ 0Déclaration

accident

Enregistrement

J + 1

Dossier

Instruction


* Evénements décisionnels

- Décision de relance

- Sur demande

8.2.3. L'état

Le concept reste le même qu'au niveau conceptuel. Il précise les conditions de fonctionnement des procédures

organisationnelles.

8.2.4. La tâche

La tâche type est un ensemble nommé d'activités élémentaires et homogènes concourant à un même but. Elle est

généralement issue la décomposition d'une opération.

Exemple

Avis de rejet

Trop grave

Vérifier constatIdentifier les partiesContrôler la situation de l'assuréAnalyser circonstancesOuvrir dossier

AssuréDéclaration

accident

OUVERTURE DOSSIER

Incomplet AcceptéNonCouvert

Demande complément information

Assuré

Accord NotificationExpert

Dossiertransmis

Siège

Expert


Décomposition en tâches

Les caractéristiques organisationnelles d'une tâche sont :

- Le poste type. Une tâche s'exécute dans un seul poste type.

- Le degré d'automatisation. Une tâche peut-être :

- Manuelle (M). Seule la ressource humaine est mobilisé

- Conversationnelle ou interactive (I) ou (SM) pour semi-automatique.

- Automatique (A). Seule la ressources informatique est mobilisée (Lecteur de badges)

- Le délai de réponse

- Réponse immédiate si les ressources sont disponibles, la tâche traite l'événement

- Réponse différée. La tâche attend d'autres événements ou conditions (délai, intervalle de

temps)

- Le mode de fonctionnement

- Unitaire. Elle traite les occurrences d'événements un par un, à la survenance des événements.

Avis de rejet

Correct

Vérifier le remplissageIdentifier les partiesSi besoins demander info complément

Assuré Déclaration accident

VERIFICATION

Incomplet

Demande complément information

Assuré

Dossiertransmis

Siège

Correct

Garanties souscritesEchéances régléesConditions d'utilisation respectées

CONTROLE SITUATION ASSURE

Incomplet

Standard

CirconstancesDommages

ANALYSE SINISTRE

Trop grave

Enregistrer sinistreEditer les courriers

OUVERTURE DOSSIER

Notification Expert Expert

Accord

Assuré

Tâches ou phase


- Par lot. La tâche attend un lot d'événement avant son déclenchement.

Une tâche peut être décrite par :

- Des règles de traitements, c'est à dire une forme structurée, un algorithme appliqué à un

ensemble de données

- Des actions effectuées sur un sous schéma de données

- Des choix et des décisions.

Remarques :

*. Il est possible aussi pour une tâche, de préciser le sous schéma organisationnel (ou conceptuel) des

données qui lui est associé. Plusieurs tâches peuvent partager les mêmes sous schéma

organisationnel ou conceptuel (MCD ou MOD).

*. Il est souvent possible de préciser aussi sur le formalisme, les ressources.

8.2.5. La règle de traitement

Une règle de traitement est un ensemble structuré de règles sous une forme algorithmique :

- D'expressions logiques

- D'expressions arithmétiques

- D'actions

8.2.6. La phase

La phase est une succession de tâches qui s'exécutent consécutivement au sein d'un même poste. Pendant

l'exécution d'une phase, toutes ses ressources restent mobilisées. Elle est ininterruptible.

Le découpage en tâche d'une phase a pour avantage:

- De permettre une meilleure analyse de l'utilisation optimale des ressources.

- D'offrir un découpage du rythme de travail au sein du poste

- De mettre en évidence, les points d'attente entre les phases.


Exemple de phase

SECRETARIAT

8.2.7. La procédure organisationnelle

Une procédure est enchaînement de tâches ou de phases, d'intérêt pour l'organisation. En d'autres termes, la

procédure est, à partir d'un (ou plusieurs) événements type, les enchaînements de tâches qui concourent à produire

un événement résultat homogène.

Complet

Déclarationaccident

VERIFICATION

Incomplet

Assuré

Déclarationaccident

Couvert


Non couvert

Avis de rejetOUVERTURE DOSSIER

Dossier

Assuré


8.2.8. Représentation graphique d'un MOT.

R

e

m

a

r

q

u

e

D

a

n

s

l

a

m

o

d

é

l

i

s

a

t

i

o

n

d

'

u

n

M

Extérieur au domaine Secrétariat Rédacteur

Assuré

Enregistrer sinistre

OUVERTURE DOSSIER

Dossier

Ouvert

Dossier à instruire

Couvert

CirconstancesDommages

ANALYSE SINISTRE

Trop grave

AssuréDéclaration accident

Complet

Vérifier le remplissage constatIdentifier les parties en présenceSi besoins, demander info compl.

VERIFICATION

IncompletDemande

information complémentaire

Couvert

Garanties souscritesEchéances régléesConditions d'utilisation respectées


Non couvert

Assuré

Avis de rejet

Siège

Part de responsabilitéConditions d'indemnisationProcédure à suivre

SAISIE CONCLUSIONS

Editer les courriersA l'assuréA l'expert

INFORMER

Dossier instruit

Fin de journée

et

Expert

Accord

Notification


MOT, il est souvent nécessaire de préciser les concepts suivants :

- La fréquence d'un événement (100 commands / jour)

- La capacité d'un événement (infinie par défaut)

- La participation d'un événement à une synchronisation (Nombre d'occurrence d'événements, 1par

défaut).

- La durée de contribution d'un événement (0 par défaut)

- Les conditions locales d'une synchronisation (expressions logiques)

- La durée limite de synchronisation (temps maximum d'attente entre le premier événement contributif et

le déclenchement de la tâche)

- Le délai de synchronisation (temps écoulé avant de démarrer une tâche après que la synchronisation

soit vrai).

- La durée de la tâche

- La périodicité de la tâche (quotidienne, hebdomadaire, mensuelle, annuelle)

- La duplication d'un résultat (nombres d'occurrences identiques d'un résultat émis par une tâche 1 par

défaut).

On peut représenter un MOT sous trois formes :

- Le MOT de procédures avec la présentation des procédures avec les événements déclencheurs et les

événements résultats

- Le MOT de phase qui permet de voir les enchaînements des travaux entre postes.

- Le MOT des tâches, plus détaillé.

8.3. Construction d'un modèle organisationnel de traitements.

Dans la construction d'un MOT, il faudra tenir compte des principes suivants :

- Faire le choix des postes de travail en spécifiant les ressources humaines et informatiques

- Décomposer chaque opération en tâches, les ordonner et les affecter aux postes, en s'assurant de leur

faisabilité par rapport aux ressources.

- Préciser les phases

- Envisager des solutions alternatives

- Evaluer l'ergonomie de chaque poste.

- L'ergonomie est l'ensemble des connaissances scientifiques relatives à l'homme et nécessaire pour

concevoir des outils, des techniques et des dispositifs qui puissent être utilisés avec le maximum de

confort, de sécurité et d'efficacité

Remarque : L'ergonomie peut prendre en compte les considérations suivantes :

- Une bonne analyse des postes

- La conception de bonnes interfaces homme – machine


X. CONFRONTATION DONNEES / TRAITEMENT

10.1. Introduction

Il convient de montrer ici la différence entre la validation et la confrontation des données et des traitements, bien que

visant toutes les deux, la cohérence et la qualité du futur système.

La confirmation cherche à vérifier la cohérence entre la modélisation des données et les traitements, quand la

validation cherche à vérifier que les solutions proposées sont conformes aux besoins.

10.2. Rôle et nécessité

Ayant modélisé les données et les traitements de manière séparée sans approfondir leur utilisation par l'une ou

l'autre des modèles, il est donc nécessaire de s'assurer que la signification des données modélisées est compatible

avec leur utilisation par les traitements. Cela consiste a :

- Vérifier si les traitements (tâches) disposent bien des données

- Contrôler si les données sont utilisées dans les traitements.

Il existe plusieurs modes de confrontations :

- La relecture croisée MCD / MCT. En relisant le MCT, on doit s'assurer que les objets et

associations évoqués se retrouvent bien dans le MCD et inversement, en relisant le MCD, on

vérifie si les associations évoquées par les relations sont bien présentes dans le MCD.

- Grille de cohérence globale MCD – MOD / MOT

Il s'agit de contrôler si les tâches du MOT disposent des données nécessaires à leur fonctionnement et que les

MCD – MOD sont utilisées dans les tâches.


Exemple :

MCD CAS Assurance

Tâches Entités Relations

Assuré Contrat Garantie Sinistre Compte Echéance Rattache Maj

Vérification

Contrôle LEC LEC LEC LEC LEC

Ouverture CRE CRE

Analyse

Saisie MOD CRE

Informe LEC LEC LEC LEC LEC LEC

Pour chaque tâche, on indique son action sur chaque entité ou sur chaque relation en CREATION, LECTURE,

Suppression ou Modification. Cela permettra de déceler dans les modèles :

- Les entités ou relation sans aucune action (Utilisation ou données pour tâches manuelles)

- Des entités ou relations jamais créées (soit la tâche est en dehors des sous–ensembles ou on a

oublié)

- Entités ou relations créées par plusieurs tâches

- Entités ou relations avec propriétés non modifiées

- Entité ou relations jamais supprimées.

1,n

0,n

1,1

EchéanceMontant

Date

DATE

CodeNomAdresse

ASSURE

N° ImmatriculationTypeMarquePuissance fiscale

VEHICULE

N° PoliceDate souscriptionBonus

CONTRAT

Code CAANom

COMPAGNIE

CodeLibelléMontant franchiseMontant plafond

TYPE GARANTIE

N° sinistreDate ouvertureDate survenanceNatureMontant estimé

SINISTRE

Nom

EXPERT

RangNomPrenomAdresse

TIERS

ConcernerCouvrir

AdversaireConcerner

Mise en jeu

Montant remboursé

Rattachée à

Victime

Suivi par

0,n

0,1

1,1

0,n

1,1

0,n

0,n

0,n

0,n

1,n

1,n

1,1

1,n

0,n

0,n

0,n

1,n


10.3. Confrontation algorithmique détaillée

La confrontation algorithmique détaillée exprime la vision des informations contingente aux traitements effectués par

la tâche. Cette perception modélisée est appelée "vue externe ". Elle consiste à :

- La description des messages en entrée en précisant les informations contenues et leur structure;

- Les règles de traitements de ces informations

- Les actions de consultations et de mise à jour des données mémorisées

- La description des messages en sortie en spécifiant les informations contenues et leur structure, aussi

que leur condition d'émission.

En d'autres termes, il s'agit de confronter le MOD avec les modèles externes associés à chaque tâche du MOD

Une tâche du modèle externe comprend :

- Un message dont le contenu est modélisé.

- Des règles de traitements

- Des actions sur un sous schéma de données

MOTTâches décrites en- Message- Actions sur les données- Règles de calcul

MOD

Confrontation détallée

Diagnostique des incohérences

Décision

Modification du

MODModification des tâches du

MOT

Travail technique

Discussions avec utilisateurs

NégociationArbitrage


10.3.1. Modélisation d'un message

Un message est constitué d'un ensemble structuré d'informations. Sa formalisation se fait en utilisant le formalisme

de MERISE. Pour des synchronisation avec ou, il faut modéliser deux messages, dans les autres cas il s'agit d'un

message résultant. A un message, le concepteur peut associer l'écran (ou l'état associé) de présentation.

Exemple : Après analyse d'un dossier de sinistre (manuelle), le message initiant la tâche " saisie conclusions" aura

le message et vue externe suivant

Message conclusion sur le sinistre

Modélisation du message

CONCLUSION

Références dossier

- N° dossier- Coordonnées assuré- Contrat véhicule

Adversaire

- compagnie- Véhicule- Responsabilité

Indemnisation

- Garanties concernées*- Montant indemnisation garantie

Numéro dossierDate ouvertureDate survenanceNom assuréAdresse assuréNuméro policeDate souscriptionN° Véhicule assuré

DOSSIER SINISTRE

Code garantieMontant indemnisé

GARANTIES INDEMNISEES

Réf CompagnieNuméro véhicule adversePourcent responsabilité

ADVERSAIRE

ImpliquerFait jouer

1,1

0,n 1,n

1,1


10.3.2. Expression des actions sur les données mémorisées.

Les données mémorisées du MOD ne sont accessibles qu'à travers une tâche. On distingue, quatre actions :

La création d'une nouvelle occurrence d'une entité ou d'une relation

- La modification

- La suppression

- La consultation

10.3.3. Algorithme de confrontation détaillée.

Pour valider les modèles externes par rapport au modèle de données, on effectue les opérations suivantes :

10.3.3.1. Equivalence propriété externe propriété conceptuelle

Il s'agit de confronter les propriétés présents dans le modèle externe et de trouver leur correspondances dans le

modèle organisationnel (conceptuel), soit directement, soit à travers une relation ou une règle si la propriété du

message ne se retrouve pas dans le MCD ou dans les règles, cette propriété vient modifier le MCD.

Exemple :

- Emission d'articles de rôles d'impôts

- Montant des émissions (calculés).

- Toute modification des règles perd les montants. D'où, une raison de conserver cette propriété.

10.3.3.2. Prise en compte des actions

A chaque entité ou relation conceptuelle, préciser les actions (créer, modifier, supprimer, consulter)

correspondantes.


III CONCEPTION DU

SYSTEME INFORMATISE

D’INFORMATION


XI. MODELISATION LOGIQUE DES TRAITEMENTS

11.1. Introduction

Après plusieurs années de pratique, on a été amené à considérer le comment du point de vue du gestionnaire (SIOet MOT) et du point de vue de l'informaticien (SII et le MLT). L'objectif tournera donc autour des moyens informatiques à réunir pour informatiser les activités présentes dans la modélisation organisationnelle des traitements (tâches, phases) compte tenu :

- Des ressources et contraintes logicielles et matérielles - Des principes généraux d'ergonomie.

Il s'agit de la mise en place d'un SGBD, de bases de données reparties, d'architectures client – serveur, avec la présentation des interfaces – homme – machine pour chaque poste de travail ainsi que pour chaque message ou état.

11.2. Formalisme de modélisation des traitements au niveau

logique.

Bien que pas différent du formalisme des traitements organisationnels, le formalisme au niveau logique utilise les

concepts suivants :

- La machine logique

- L'événement / Résultat Message

- L'état

- L'unité logique de traitement ULT

- La procédure logique

11.2.1. La machine logique

Une machine logique type est un ensemble de ressources informatique (matériel et logiciel) capable d'exécuter des

traitements informatiques de façon autonome. Elle permet d'exprimer la répartition des traitements informatisés : Elle

peut être :

- Une machine physique

- Micro-ordinateur autonome ou en réseau

- Serveur

- Mainframe ou mini avec terminaux fictifs

- Une partie de machine physique

- Machine virtuelle sur un mainframe.

Comme pour les postes du MOT, il faudra représenter chaque machine logique dans un tableau.


11.2.2. L'événement / Résultat – Message

A l'opposé du SIO où les événements / résultats – messages représentent les échanges du système avec son

environnement ou entre les postes de travail, dans le MLT, ils désignent les échanges entre le SIO (les

utilisateurs) et le SII.

Ils peuvent représenter :

- Des échanges entre machines logiques ou unités de traitements logiques ULT

- Le début et la fin d'une procédure logique

11.2.3. L'état

L'état (même modélisation que le SIO) expriment des conditions préalables ou des résultats conditionnels d'une

ULT.

11.2.4. Unité logique de traitement ULT

L'unité logique de traitement type est un ensemble de traitements informatiques perçus comme homogène en terme

de finalités et elle se définit aussi par rapport à la cohérence des données du SII. Une ULT peut

- Une transaction dans un système relationnel

- Une boîte de dialogue

- Une édition

- Un module dans une chaîne batch.

Début

Mise à jour

Réactivation dossier

Prorogation dossier

Et

Et

Fin

Dossier

Suspendu

Dossier

Echu


Une ULT comprend selon leur nature :

- Une interface

- Un traitement

- Un sous schéma de données

Ces éléments peuvent se décomposer en plusieurs fonctions représentées graphiquement de la façon suivante :

11.2.5. La procédure logique

C'est un enchaînement d'ULT réalisant l'informatisation d'une tâche ou d'une phase du MOT. Elle commence par

un appel utilisateur du menu (ou du début spécifié) et se termine par le retour au menu d'appel. Au sein d'une

procédure logique, les ULT et leur enchaînement correspondent à la résolution de l'activité organisationnelle

associée.

Présentation externe des données utilisées

Logique de dialogue (Règle de gestion et de contrôle) associé à la présentation sur les données, sur les valeurs

Logique fonctionnelle (Algorithme générale)

Les enchaînements (Liaison entre les différents

ULT)- Origines des appels

- Liaisons conditionnelles avec d’autres ULT

C’est la partie externe visible de l’interface (Ecran avec objets, fenêtre, état ou formulaire)

Point de contact utilisateur - SII

Accès aux données mémorisées. Respect de la cohérence et de l’intégrité des données

Règles de calculs

Algorithme suffisant ne nécessitant pas d’interaction avec la présentation, échangeant des données avec le sous -schéma


Exemple : Procédure logique contrôle situation assuré

Autre Nom

ASélection

- Saisir nom complet ou partiel- Recherche sur nom- Sélection sur liste

Début Procédure Contrôle situation assuré

RECHERCHE ASSURE

Ou

I

- I : Inconnu- A : Abandon

ASélection

Autre Assuré

- Afficher la liste des contrats-- Sélection sur liste

RECHERCHE CONTRAT

Ou

NR

- NR : Non Référencé- O : Ouverture

dossier

ADétail GarantiesAutre contrat

- Afficher garanties souscrites et situation échéanceSITUATION CONTRAT

Ou

NR O

Non couvertRetour contrat

- Afficher des seuils d4indemnisation et des conditions d’utilisation

DETAIL D’UNE GARANTIE

- Edition d’un courrier circonstancié en fonction du motif du rejet

EDITION AVIS DE REJET

Ou

Vers ProcédureOUVRIRDOSSIER

Fin de procédure

Avis de rejet

Incomplet


11.3. Conception des modèles logiques de traitements (MLT)

La construction d'un modèle logique de traitement exige une réflexion, une création, une invention et ne peut donc

découler directement et automatiquement des modèles du SIO. Pour son élaboration plusieurs approches sont

possibles.

11.3.1. Trois approches de conception des MLT

11.3.1.1. La décomposition des tâches organisationnelles

Les procédures logiques sont élaborées à partir du MOT. Les enchaînements et contenus des ULT sont construits

pour chaque tâche du MOT.

La procédure logique apparaît comme une décomposition de la tâche. Comme avantages, on peut dire que les ULT

sont très proches des activités formulées dans le MOT. L'inconvénient est que pour des ULT identiques, on peut

avoir à faire de longs développements.

11.3.1.2. Réutilisation des ULT

Il s'agit de rechercher dans le MOT, les tâches dont la description soit similaire ou proche et concevoir des ULT

utilisable, en commun par différentes tâches. (Préconiser par le Génie logiciel). Dans leur utilisation les ULT

communes seront amendées pour s'adapter éventuellement à chaque tâche.

L'avantage c'est qu'on écrira moins de code, moins de ULT. Comme inconvénients on peut avoir des ULT moins

adaptées aux tâches, les appels ou enchaînements peuvent poser problèmes.

11.3.1.3. Conception des ULT autour des données.

Il s'agit ici de repérer dans le MOD, des ensembles de données perçus comme stables par les utilisateurs et se

referant à des objets couramment utilisés dans les activités (Entités externes des vues externes). Si la vue externe

comporte plusieurs entités reliées par une relation, s'appuyer sur la principale (pivot).

A ce sous schéma, on associe une ULT qui permettra d'effectuer les opérations de base (création, modification,

suppression, consultation)


Comme avantages, les ULT servent de base pour une approche par réutilisation et peuvent être directement

implémentés dans des environnements graphiques en dehors d'approches procédurales. Comme inconvénient, on

voit que la construction des procédures logiques à l’initiative des utilisateurs qui doivent maîtriser les enchaînements

adéquats.

Exemple :

Le contrat et ses garanties

CodeLibelléMontant franchiseMontant plafond

CodeNomAdresse

ASSURE

N° ImmatriculationTypeMarquePuissance

VEHICULE

Concerner

CouvrirN° PoliceDateBonus

CONTRAT 1,1

0,n

1,n

1,1

Comporter

Clause particulière

TYPE GARANTIES

1,n

0,n

ASSUREVEHICULE

CouvrirConcerner CONTRAT

Comporter

Clause particulière

Numéro sinistreDate ouvertureDate survenanceNature sinistreMontant estimé

SINISTRE

1,1

SINISTRE


11.3.2. Modularité des MLT

11.3.2.1 ULT et architecture logique d'application

Il s'agit de concevoir des applications respectant la séparation entre interfaces utilisatrices et le noyau de

l'application afin de garantir une indépendance du dialogue interactif. On distingue En généra trois modules à savoir

- Les interface graphique homme / machine

- Le noyau applicatif

- Le guidage fonctionnel

11.3.2.2. Décomposition des ULT par nature

Dans cette décomposition, les ULT sont décomposés en ULT élémentaires respectant les règles suivantes :

- De nature (Présentation, dialogue, logique fonctionnelle, accès aux données, règles, enchaînement)

- De machine logique en cas de répartition.

Exemple : Décomposition de L'ULT Recherche assuré en ULT élémentaires.

Afficher l’écran

Néant

- Relancer les recherches successives sur nom en augmentant le champ de calcul jusqu’à obtenir une liste ou la limite de recherche

Nom saisi

Champ Nom saisi ou fonction activée

SAISIE ECRAN

Calcul de nom approchant alphabétiquement ou phonétiquement

Autre action

Rechercher les assurés correspondant au nom calculé

RECHERCHE SUR NOM

Abandon

Vers les ULT correspondant selon les situations de la procédure

ECRAN SELECTION ASSURE

Autre Nom Inconnu Abandon

REINITIALISATION

GESTION RECHERCHE NOM

Chercher OK

AFFICHER RESULTATANALYSE NOM

ENCHAINEMENT

Sélectionné Inconnu

SELECTIONNER SUR LISTE

Sélectionner


11.4. MLT repartis

La répartition logique des traitements porte sur les unités logiques de traitement associées aux tâches du MOT.

Grâce aux nouvelles technologies de l'information, il est aujourd'hui de plus en plus questions de traitements

repartis.

11.4.1. Démarche de répartition

Pour construire un MLT reparti, il faut adopter la démarche suivante :

- Elaborer un MLT non reparti sans tenir compte de la future répartition

- Définir une architecture matérielle, c'est à dire définir :

- La machine logique et ses caractéristiques techniques

- Les sites logiques

- Les ressources d'environnement (Système d’exploitation, logiciel de développement, communication

- Repartir les traitements en affectant les différents ULT aux machines logiques.

11.4.2. Modalités de répartition

Repartir des données et les traitements, c'est les installer sur des machines logiques. On dispose de trois modalités

de répartition essentielles :

- Traitements coopératifs : Une ULT primaire est exécutée sur plusieurs machines logiques. (ULT non

décomposé en ULT élémentaires)

- Données identiques sur des machines logiques différentes (Accès concurrent)

- Client - Serveur


11.5. Exemple pratique d'un MLT futur

Annuler

Maquette VT 04Recherche client selon critères- Nom (Partiel)- Ville- TéléphoneAfficher N° Compte et adresseChoix sur liste

Annuler

Maquette VT 03Afficher article et quantité demandéeIndiquer ou rechercher client donneur d’ordreIndiquer ou rechercher client à facturerCalculer prix de vente net et totauxIndiquer le mode de facturationEncaisser si paiement comptant

Annuler

Début de procédure

Annuler

Maquette VT 01Saisir référenceConsulter quantité en stockSaisir quantité commandée

DEMANDE ET DISPONIBILITE

Suivant Remplaçant FactureStock

Maquette VT 02Liste articles et stockChoix remplaçant

REMPLACANTS

RemplaçantsOK

FACTURATION

? Client Enregistrer

Remise

RECHERCHE CLIENT

OKClient

Comptant

Maquette VT 05Enregistrer la factureMettre à jour les stocksImprimer la facture ou l’avis de débit

ENREGISTREMENT

En compte

Avis de débit

Facture réglée

Fin Procédure

Enreg_Fact

Procédure logique vente comptoir


Représentation graphique des ULT

❶. ULT demande et disponibilité

Présentation de la maquette

Logique du dialogue

- Saisir la référence. Afficher le libellé si référence existe et quantité en stock ou erreur si inconnue.

- Saisir quantité demandée

Logique fonctionnelle

Règle

- Si quantité demandée > quantité disponible

Alors

Sous schéma

Référence articleCode_MagasinQantité_Stock

Référence articleDésignation

Référence :

Libellé :

Quantités

Commandée :

Disponible :

Annuler Suivant Facture

STOCK MAGASIN

ARTICLE DEMANDE

Remplaçant

Erreur ouRemplaçant

ARTICLE


Enchaînement

❷ ULT facture (appel par bouton)

Présentation

Logique de dialogue

- Saisir N° ou bouton ? Pour le client livré afficher nom et adresse

- Saisir N° ou bouton ? Pour le client facturé afficher Nom et adresse

Si inconnu, afficher message client inconnu

Condition Action Résultats

Suivant BoutonConserver la quantité demandée

Effacer les lignes pour ressaisie

Remplaçant BoutonSi l’article possède des remplaçants, appeler l’ULT avec passage de référence article

Sinon afficher message Pas de remplaçant

Facturer BoutonAppeler l’ULT facturation avec passage des références et quantités des articles

demandés

Annuler Bouton Fin de procédure

N° :

Nom :

Adresse :

FACTURATIONClient Livré Client Facturé

N° :

Nom :

Adresse :

Désignation article P.U % Total

Enregistrer

Annuler

Total Hors taxe :Tva :

Total TTC

Qté

En compte

Comptant

Mode de paiement


- Saisir mode de paiement


Afficher les articles et les quantités provenant de l'ULT demande et disponibilité chiffrer la facture selon les règles.

Règles

- Détermination de la remise. Le % de remise est le maximum des % remise client et remise article.

- % remise appliqué = Max (% remise client, % remise article)

- Calcul montant total ligne = PU* quantité* (1 -% Remise)

- Calcul montant total facture = Somme(Total lignes)

Sous schéma

* Enchaînement

Condition Action Résultat

? client Bouton Appeler l'ULT recherche client

Enregistrement Bouton Appeler l'ULT Enregistrement et édition avec passage de

l'ensemble des informations présente

Annule Bouton Fin procédure

N° ClientTx_Remise

Référence articleCode magasinPrix_Magasin

CLIENTSTOCK_MAGASIN


❸ ULT Enregistrement et édition

Présentation

Logique de dialogue

Sans objet


- Créer la facture

- Mettre à jour la quantité en stock

- Imprimer selon le formulaire correspondant

- Retour à l'ULT facturation

Règle

- Détermination N° commande – Génération par le système d'un numéro chronologique.

- Détermination du code du dépôt, de la date de commande, mise à jour stock

Nom :

Adresse :

Client Livré Client Facturé

Nom :

Adresse :

Désignation article P.U % Total

Total Hors taxe :

Tva :

Total TTC

Qté

Société XPièces détachées

FACTURE

N° :Date :

Magasin de :

Paiement :


Sous schéma

Enchaînement

Condition Action Résultat

OK Bouton Appeler ULT facturation, avec transmission du client sélectionné

Annuler Bouton Appeler l'ULT facturation

#NocliNomRueVilleCp

Code_MagasinCLIENT

MAGASIN

#Code articleN° CommandeNocli –PasserNocli – Tiers FactureDate CmdeDate livraisonMode paiementEtat cmd

Code_magasinN° CmdeRéférence_ArticleQuantité livréeMontant net

Cmd_FACTURE LIGNE_CMDE_FACTURE

Référence articleDésignation

Référence articleCode_MagasinQuantité en stock

STOCK_MAGASIN

ARTICLE

Concerner :

Facturertiers :Passer :



XII. MODELE PHYSIQUE DE DONNEES

12.1. Modèles physiques de données

Le modèle physique de données est la traduction du MLD dans un langage de description de données spécifique au

système de gestion de base de données, de fichiers (SGF). Chaque système à ces spécificités qu'on devra voir

avec ces systèmes. Exemple D’ORACLE, de SQL serveur, de Access, etc.

12.1.1. Objectifs des SGBD

12.1.1.1. Objectifs orientés données

- Non redondance des données. MAJ et saisies réduites. Moins d'incohérence

- Partageabilité des données. Pb d'accès concurrents résolus.

- Sécurité des données. Protection contre les utilisateurs non autorisés ou mal intentionnés. Résolu par

les SGBD.

- Cohérence des données

12.1.1.2. Objectifs orientés traitements

- Indépendance physique des données choix d'une organisation physique de données

- Indépendance logique des données.

- Définition d'un modèle externe pour chaque utilisateur

- Manipulation facile des données

- Utilisation de langages non procéduraux simples

- Utilisation de langages procéduraux très évolués.

- Cohérence physique / fiabilité – dispose de mécanismes sophistiqués de reprise après les pannes.

12.1.1.3. Objectifs organisationnels

Avec les politiques de centralisation – décentralisation, concentration – déconcentration des données de certaines

entreprises, l'organisation et l'administration des données doivent :

- Assurer un contrôle efficace des données

- Résoudre les conflits entre divers points de vue d'utilisateurs

- Optimisation des accès aux données

- Optimiser les moyens informatiques.

Ici, il y a un besoin d'un AD (administrateur des donnes et d'un ABD AD: de base de données).

12.2. Modèle physique de traitements

C'est l'ensemble des programmes informatiques assurant l'exécution des traitements informatisés du SI.



XIII.OPTIMISATION DES MODELES DE

DONNEES

13.1. Introduction

Jusqu’au modèle physique de données, la conception ne s’est pas encore préoccupée des problèmes d’accès, de

performances, de volumes et de coûts. L’optimisation aura pour rôle de tenir compte de ces aspects en faisant un

compromis entre une organisation et une implémentation conduisant à des performances meilleures. On devra pour

cela s’occuper :

- Du volume global occupé par les données mémorisées

- Du temps d’accès aux données

- Des contraintes de transfert entre données et UC

- Etc.

13.2. Optimisation du modèle relationnel

Plusieurs moyens d’optimisation existent et permettent des performances diverses.

13.2.1. Optimisation par valorisation de l’activité des traitements sur la base

de données

- Transformation de sous – schémas conceptuels en sous – schémas logiques.

- Transformation des actions en primitives

- Accès par clé primaire CP_Prim + Table (LIRE)

- Accès par autre attribut ?Prim + Table

- Ajout d’un tuple Prim_Add + Table (CREER)

- Suppression d’un tuple Prim_Supp + Table (SUPPRIMER)

- Modification d’un attribut d’un tuple Prim_Modif + Table

- Jointure entre deux tables Prim_TXT


13.2.2. Optimisation par choix d’une organisation des tables

- Chemins d’accès primaires : Les SGBD proposent des choix de gestion qui dépendent

généralement des systèmes d’exploitation. L’accès par index primaire ou clé primaire améliore l’accès

à une donnée. Il existe plusieurs types d’index selon les SGBD. Pour les plus importantes (INGRES,

ORACLE, SQL SERVEUR) on a les organisations suivantes :

- HEAP : Table organisée en fichier séquentiel

- HASH : Clé calculée ou accès sur une valeur de clé.

- ISAM : Les données de la table sont triées selon une clé et permet un accès rapide sur une

valeur exacte d’une clé, mais nécessite une réorganisation quand la table augmente

- BTREE : Les données de la table sont triées selon une clé et permet un accès rapide sur une

valeur exacte ou partie d’une clé. La table est réorganisée automatiquement à

chaque modification.

- Chemins d’accès secondaires : Selon certaines situations de gestion, des attributs non clés

mais pouvant être souvent utilisés pour des recherches (En dehors de la clé) peuvent être pris comme

clés secondaires pour accélérer les recherches.

- L’encodage ou la compression de données qui ont pour objet, la réduction de l’espace de stockage.

- Le partitionnement des tables ou segmentation pour avoir des données fréquemment utilisées ou de

même traitement ensembles. Deux partitions sont possibles :

- La partition verticale : Les champs souvent utilisés sont mis dans une table quand les autres sont

dans une mémoire moins utilisée. Les coûts de mise à jour peuvent être coûteux.

- La partition horizontale qui consiste à subdiviser les tuples d’une table en sous tables de même nature.

- Le regroupement (ou clustérisation). Dans le cas de ORACLE, on peut regrouper physiquement, sur

une même page (Entrée / Sortie) des données provenant de plusieurs relations et vérifiant des

prédicats de sélection précis (En général deux tables). Si plusieurs tables sont placées dans un

cluster, elles doivent avoir un attribut commun :

- Chaque valeur de cet attribut est stockée une fois dans la base

- Les tuples ayant la même valeur de l’attribut sont placés dans une même zone (Page)

- Un index au cluster est créé


- La dé normalisation par regroupement des tables.

Il faut cependant évaluer les risques qu’il y a à avoir des commandes sans factures

- La création de redondances d’attributs non clés.

Adresse souvent consultée

- La création de tables de jointures

N° CommandeDate Cmde

COMMANDESComposer

N° FactureDate Facture

FACTURE

Entité / Relation

N° CommandeDate Cmde

COMMANDES

N° CommandeN° FactureDate Facture

FACTURE

MLD non optimisé

0,1 1,1

N° CommandeN° FactureDate FactureDate Commande

COMMANDE

MLD optimisé

NomAdresse

PERSONNECoordonnéesNomDate constructionSurfaceDate acquisition

MAGASIN

MLD non optimisé

NomAdresse

PERSONNECoordonnéesNomDate constructionSurfaceDate acquisitionAdresse Personne

MAGASIN

Pour une consultation massive à partir du magasin, on duplique l’adresse


IV LA DEMARCHE MERISE


XIV. LE SCHEMA DIRECTEUR

14.1. Objectifs

Le schéma directeur fixe les lignes directrices du développement des systèmes d’information. Il spécifie les

contraintes ou souhaits majeurs sans proposer de solutions. En d’autres termes, le SD relève de l’orientation

politique qui se traduit par un plan de développement de 3 à 7 ans selon les secteurs d’activité et portant sur :

- Le découpage en domaine

- La planification globale et les priorités

- La politique matérielle et logicielle

- Les options principales d’organisation (Site, Centralisé / Décentralisé, Repartis)

- Les stratégies des moyens en personnel (Engager ou commander des services)

- Les cadres budgétaires

- Les contraintes dues à l’environnement (Internet ou pas, Pb d’électricité, etc.)

14.2. Différentes démarches

14.2.1. Approches mono domaine

Un domaine de l’entreprise est identifié et l’orientation politique (Après étude préalable) est portée sur ce

domaine.

14.2.2. Approche simultanée des domaines avec intégration de l’étude

préalable

Le SD qui en résulte est complet. Il propose un meilleur découpage en domaines et une meilleure vision des

fonctionnalités de chaque domaine et des relations avec les autres domaines.

14.2.3. Approche simultanée des domaines avec esquisse conceptuelle

Pour de grandes entreprises aux activités diverses, les deux premières approches ne sont pas faisables. Celle –

ci propose un découpage en domaines avec les MCD et MCT globaux (Sans se préoccuper des règles) afin de

déterminer les vrais domaines et la politique d’orientation.


14.3. Découpage du SI en domaines

Pour une question de maîtrise, tout projet informatique doit être subdivisé en modules bien ordonnancés. D’où la

nécessité de découper le SI en domaines. Un domaine pouvant être défini comme un ensemble d’activités de

gestion s’appuyant sur un ensemble d’informations communes et n’ayant que peu d’échanges avec d’autres

activités. Trois approches de découpage sont proposées :

- Approche activité du système opérant. Les domaines opérationnels sont obtenus en regardant plus

le niveau des traitements.

- Approche fonctions du système de pilotage. Regroupement des fonctions de décision et de

contrôles d’activités du système de pilotage.

- Approches selon les finalités distinctes.


XV. ETUDE PREALBLE

15.1. Objectifs

L’Etude Préalable réalisée au niveau d’un domaine a pour objectifs :

- L’analyse et l’évaluation critique du fonctionnement du système d’information actuel.

- L’élaboration de solutions en précisant :

- Les processus de fonctionnement du système

- La perception des informations

- Les modes d’organisation

- Le degré et type d’automatisation

- L’évaluation des solutions proposées en termes de :

- Equipements informatiques

- Coûts et délais de mise en oeuvre

- Conséquences sur l’organisation générale de l’entreprise

- Scénario de mise en oeuvre

15.2. Phases

L’EP se décompose en quatre phases : Le lancement, l’analyse de l’existant, la conception et l’évaluation qui se

termine par un dossier de choix.

15.2.1. Le lancement

Elle initialise l’EP et rappelle les orientations issues du Schéma Directeur. Elle se décompose en quatre tâches :

- Le rappel de l’objet et la limite du projet (Tracer les cadres pour savoir ce qui en fait partie et ce qui

est exclu)

- Le rappel des orientations générales

- L’organisation et la planification de l’étude ou définition des modalités pratiques de déroulement

(Calendriers, structures du projet (Groupe de pilotage et de validation), points et modes de

contrôles, budgets, contraintes politiques, etc.

- Des informations


15.2.2. Analyse de l’existant

Remarque : Il ne s’agit pas de rechercher l’exhaustivité du recensement des données et des traitements,

mais se préoccuper des données et traitements majeurs. L’analyse de l’existant n’est pas un

audit.

Avant de concevoir un nouveau SI, il faut connaître :

- La situation de l’entreprise, ses produits et son marché

- L’organisation actuelle (Direction, services, personnels, moyens techniques)

- La circulation des biens, des services et des informations

- Les points forts et les points faibles

Toutes ces informations peuvent être obtenues en observant les gestionnaires et les ouvriers travailler et en les

interrogeant. Après cela, on passe à :

- L’analyse des flux pour voir les principales informations qui circulent dans le SI (Supports) et les

principales unités actives qui participent à ces échanges. Le document produit (Graphe des flux)

doit être validé

- L’analyse des modèles organisationnels (MOD, MOT pas très approfondis) pour déterminer les

postes de travail, les procédures organisationnelles majeures et la fréquence exprimée dans les

principaux événements.

Remarques : Le MOT ici aura pour but de servir de base au MCT actuel et futur,

d’évaluer l’écart avec le futur système et d’élaborer un scénario pour la transition.

- Analyse du modèle logique et physique des données, avec l’étude des fichiers ou bases de

données existantes, ou l’organisation actuelle des données.

L’analyse de l’existant doit pouvoir porter un regard critique sur l’existant en termes de points forts et points

faibles et récapituler les souhaits et attentes des utilisateurs.

15.2.3. Conception

En se basant sur les critiques des modèles précédents et en tenant compte des souhaits et attentes des

utilisateurs, il faut maintenant proposer le futur système d’information avec les MCD – MCT et MOD – MOT.


La phase de conception comprend :

- La clarification des orientations du futur SI pour éviter les divergences entre la base et le sommet de

l’entreprise (Priorités, perceptions)

- La construction d’un MCD et d’un MCT futurs en termes de processus majeurs et sans rechercher

l’exhaustivité des données

- La construction du MOT et du MOD avec solutions informatiques succinctes

- La confrontation MOT / MOD

- La synthèse et la validation des solutions proposées

15.2.4. Evaluation et appréciation

Elle comprend :

- Une estimation du volume des données à mémoriser

- L’estimation de l’activité (Evaluation de la charge ordinateur directement liée aux accès aux

données)

- La recherche de solutions informatiques en termes de ressources matériels et organisation des

données et traitements (Données ou traitements repartis).

- Les principes du passage du système actuel au système futur (Basculement instantané, opération

pilote, installation progressive, fonctionnement en double)

- L’estimation des coûts et délais

- Appréciation des différentes solutions proposées

- Rédaction d’un dossier de choix

15.3. Conclusions

Une fois l’EP qui ne doit pas être très longue est terminée, le dossier de choix est remis au groupe de pilotage qui

donnera une suite au projet. La suite peut être soit :

- Le comité de pilotage choisit une solution et donne son accord pour la suite des travaux

- Le CP abandonne pour insuffisances des gains futurs

- Le CP invite l’équipe à reprendre l’EP dans certains domaines.


XVI. L'ETUDE DETAILLEE

16.1. Objectifs

L'étude détaillée a pour objectifs :

- La description de tous les processus composant le fonctionnement du futur système

- La définition exhaustive des informations utilisées et mémorisées.

- La spécification complète des tâches, surtout pour celles à informatiser

- La description des procédures exceptionnelles, les phases transitoires et le fonctionnement

dégradé.

L'étude détaillée (ED) permet de spécifier l'intégralité du fonctionnement du futur système. Elle sera surtout liée

aux modèles du SI0 (MCD – MOD et MCT – MOT). Elle constitue ainsi un cahier des charges

utilisateur.

16.2. Phases

Elle comprend aussi quatre phases à savoir la conception générale, la conception détaillées, les procédures

transitoires, les procédures de recours.

16.2.1. Conception générale

Elle permet d'étendre et de généraliser les spécifications de l'étude préalable à l'ensemble de l'activité. Elle

comprend quatre tâches :

- L'extension du MCT qui consiste à la reprise du MCT issu de l'EP et de le compléter avec :

- La liste des acteurs avec les événements émis et les résultats reçus

- Le diagramme d'enchaînements des procédures

- La liste des processus et des événements déclencheurs

- La description de chaque opération

- L'extension du MCD qui permet d'enrichir le MCD avec:

- L'apport de données complètes d'une entité

- L'éclatement de certaines entités en sous entités. Exemple. Contribuable (société, Individu)


- L'extension du MOT qui consiste à étendre le MOT de l'étude préalable en fournissant une

description complète de l'ensemble des procédures et des postes de travail. Son élaboration doit

être faite en étroite collaboration avec les utilisateurs. Une clarification est doit être faite sur :

- L'enchaînement des différentes tâches

- Le partage des tâches entre l'homme et la machine

- La circulation des informations

- Les caractéristiques techniques et ergonomiques des postes

- La liste des postes de travail en précisant

- La localisation géographique

- Les compétences requises

- Le matériel informatique associé

- Le nombre de postes identiques

- La disposition pratique

- Le graphe d'enchaînement des tâches en précisant

- Le degré d'automatisation (Manuel, conversationnel, automatisé)

- Le délai de réponse (Immédiat/ différé avec précision sur le déclenchement : Fin de journée, 10

jours, fin de mois, etc.)

- Le mode de travail (unitaire/Lot)

- Les phases de traitements

- Un tableau récapitulatif des différentes procédures

- Une liste récapitulative des tâches en précisant :

- Le poste, le degré d'automatisation, le délai de réponse

- Les procédures dans lesquelles elle intervient

- Une estimation de la charge de développement

- L'extension du MOD en faisant après confrontation avec le MOT, des ajouts ou suppressions de

propriétés.

16.2.2. Conception détaillée

Elle comprend plusieurs tâches :

- L'analyse détaillée des tâches conversationnelles : spécification intégrale pour les traitements à

effectuer pour informatiser les tâches conversationnelles à savoir :

- La saisie et le contrôle des informations apportées par le message

- La restitution immédiate de un ou plusieurs résultats.


- Lorsqu'une tâche est complexe, la décomposer en tâches élémentaires pour se retrouver en unités

logiques de traitements (ULT). Pour chaque ULT, préciser :

- Le dessin détaillé des supports utilisés avec la description des informations (ergonomie)

- Les règles de traitement de vraisemblance, de compatibilité, d’existence préalables utilisées

(Contrôles à la saisie, calcul arithmétiques et logiques, règles de présentation pour la

restitution des informations)

- Les actions effectuées sur les données mémorisées à partir des informations utilisées dans

L'ULT, propriétés mises à jour ou consultées, type d’action (Création, modification,

consultation, suppression).

- Les messages et diagnostiques d’erreurs propre à L'ULT.

- L'utilisation de maquettes rend la spécification une plus facile (Ecran, formulaire etc.)

- L'analyse détaillée des tâches automatiques. Ces tâches qui ne demandent que les ressources sont

souvent appelées batch. L'absence d'interactivité permet de ne pas apporter suffisamment de

détails à ce niveau, et d’attendre l'étude technique.

- La confrontation détaillée qui consiste à constituer pour chaque ULT, le modèle externe comprenant :

- La structure des informations contenues dans les messages d'entrée (Ecran)

- Les règles de calcul

- Les actions sur les données

- La structure des informations contenues dans les résultats (Etats)

En cas d'incohérence après confrontation, on peut :

- Amender les MCD

- Modifier la tâche ou L'ULT

- L'enrichissement du MCD pour apporter tous les compléments nécessaires après confrontation. On

spécifiera définitivement :

- Schéma Entité / Relation

- Une description détaillée pour chaque entité précisant :

- L'appellation, la définition

- L’identifiant et la liste des propriétés

- Une description détaillée pour chaque relation précisant

- L'appellation, la définition

- L’identifiant et la liste des propriétés

- La collection et les cardinalités


- Les dépendances fonctionnelles

- La liste des propriétés

- Une fiche pour chaque propriété précisant :

- L'appellation la description

- le type format de présentation

- Valeurs types

- L'enrichissement du MOT qui permet de définir précisément chaque tâche, en ce qui concerne :

- Sa place dans la procédure organisationnelle

- Le contenu et la structure des informations dans le message (Entrée / Sortie)

- L'expression des règles de traitement

- L'expression des actions effectuées par la tâche sur les données mémorisées.

- La finalisation du MOD qui prend en compte l'enrichissement du MCD précédent, pour en faire un

MOD le compléter au niveau du MOD pour en constituer la version définitive. Les aspects suivants

sont pris en compte :

- Spécification des propriétés exprimant des "états" : Exemple. Etat d'une demande (Ferme, à

facturer, facturée, Livrée, etc.). Une propriété pourra s'ajouter au MOD pour cela

- Spécification des durées de vie, en procédant à l'archivage des données anciennes (durée à

définir) et à mettre en place des procédures de récupération.

- Spécification du MOD d'archives puisque les données archivées peuvent être résumées ou

avoir la même structure que le MOD.

16.2.3. Spécification des procédures transitoires

Pendant la période de mise en service du nouveau SI, il est important de proposer des procédures transitoires

permettant de passer de l'ancien système au nouveau système. Pour cela il faut se pencher sur :

- La récupération et le transfert de données. Il s'agit pour cela de définir les données à transférer et

les tâches prenant un compte ce transfert ainsi que celles qui permettent un chargement initial

(Même degré de détail que le système futur).

- Les principes du basculement entre le système actuel et le système futur. On décidera selon la

complexité et la sensibilité du projet, de faire un passage:

- Immédiat: Dès la mise en œuvre on passe directement au nouveau système.

- Progressive: Le nouveau système est utilisé modules par modules jusqu'à l'utilisation complète, en

allant du plus simple au plus compliqué.


- Concomitant: les deux systèmes sont utilisés simultanément. MOT durant la période transitoire. En

cas de mise en œuvre progressive surtout, on doit définir les différents stades de l'organisation

provisoire sous forme d'un ou de plusieurs MOT transitoires qui pourraient comporter:

- Des degrés d'automatisation provisoires (une tâche automatisée à terme, reste provisoirement

manuelle)

- Des tâches provisoires (ou conserve ou on ajoute une tâche pour la situation provisoire)

- Des répartitions différentes des postes (tâche en attente de poste non encore opérationnels)

- Des délais de réponses provisoires (tâche avec réponse immédiate peut-être provisoirement en

réponse différées)

Toutes ces descriptions / spécifications respectent le même principe qu'un MOT normal.

16.2.4. Spécification des procédures de secours

L'entreprise peut-être privée de ces ressources pour une période plus ou moins longue suite à un incident. Il est

indispensable en ce moment de prévoir des procédures de fonctionnement à appliquer pendant l'incident et pour

le rattrapage de l'activité. On abordera alors ces deux aspects en ce qui concerne:

- Le MOT de secours doit proposer et décrire l'organisation à mettre en place lors d'une

indisponibilité de ressources informatiques car elle remet essentiellement en cause l'équilibre

manuel / automatisé.

Pour cela, le concepteur doit proposer un MOT spécifique (selon le cas) pour éviter les

improvisations souvent néfastes. Parmi ces procédures, on peut proposer:

- D'attendre que les ressources redeviennent disponibles si :

- La plupart des tâches sont en réponse différée

- La durée de la panne est courte

- De revenir au manuel pour tout ou partie des tâches automatisées. Les tâches manuelles de

remplacements doivent permettre des enregistrements temporaires devant être récupérés

ultérieurement. Il faudra pour cela :

- Proposer des bordereaux et supports provisoires

- Réaffecter éventuellement des tâches aux postes

- Proposer les tâches vitales devant être assurées

- Les procédures de rattrapages de l'activité. Elles consistent à spécifier dans quelles conditions

s'effectuera la reprise (Naturellement ou selon une organisation). En mode attente, il y aura un

cumul d'information à traiter (Doubler les postes actifs par exemple pendant la reprise). En mode

manuel, avec des informations, il faut savoir si on récupère tout ou une partie des données et

comment?


16.3. Conclusion

L'étude détaillée ayant pour objectif la production d'une description complète du fonctionnement du futur système,

elle doit être couronnée par la production d'un dossier de l'ED qui comporte :

- Un rappel des objectifs, des orientations et des modalités de l'étude détaillée.

- La description des données (Modèles organisationnels validés)

- La description détaillée des traitements (Diagramme des procédures organisationnelles, description

détaillée de chaque tâche, phase de chaque poste).

- Le calendrier prévu pour l'étude technique.


XVII. L'ETUDE TECHNIQUE

17.1. Objectifs

L'étude détaillée a permis d'obtenir l'ensemble des spécifications du futur système du point de vue de l'utilisateur.

L'étude technique représente les spécifications informatiques. Elle est généralement liée à la production du

logiciel. Elle permet de définir complètement :

- La structure physique des données (Fichiers ou base de données)

- Les programmes à réaliser

- Les procédures techniques de sécurité

- La planification de réalisation

Les modèles concernés sont les MLD, MPD et les MLT MPT.

17.2. Phases

L'étude technique est menée en deux phases, la définition des architectures des données et des programmes et

la préparation de la réalisation.

17.3. Architectures

17.3.1 Architectures de données

Il s'agit de définir une description informatique opérationnelle de l'organisation des données mémorisées, l'accès

aux données à partir des programmes. Cette architecture dépend aussi du logiciel de gestion de données utilisé.

C'est ici qu'on transforme le MOD en MLD. Certaines améliorations peuvent être apportées selon les possibilités

techniques du SGBD.

17.3.2. Architectures des programmes transactionnels

Il s'agit de définir une description complète des transactions à programmer en fonction des outils de production

(SQL, VB, ORACLE, FOXPRO, etc.). Il faudra alors spécifier.

- La liste des transactions à réaliser

- L’enchaînement entre les différentes transactions


- La description technique de chaque transaction (Expression informatique des algorithmes, accès

aux données, les sécurités techniques)

17.3.3. Architecture des programmes en réponse différé

Il s'agit de la description complète des programmes batch. Selon les outils de production, on spécifiera :

- La liste des programmes à réaliser

- Les diagrammes d'enchaînement des unités de traitement

- L'accès aux données

- L'expression informatique de l'algorithmique

- Les critères de classement et de sélection

- La définition des fichiers de travail

17.4. Conclusion

L'étude détaillée ayant pour objectif la production d'une description complète du fonctionnement du futur système,

elle doit être couronnée par la production d'un dossier de l'ED qui comporte :

- Un rappel des objectifs, des orientations et des modalités de l'étude détaillée.

- La description des données (Modèles organisationnels validés)

- La description détaillé des traitements (diagramme des procédures organisationnelles, description

détaillée de chaque tâche, phase de chaque poste).

- Le calendrier prévu pour l'étude technique.


XVIII. LA PRODUCTION DU LOGICIEL

18.1. Objectifs

L'ensemble des spécifications précédentes étude détaillée et étude technique proposait un SI "papier". La

production va réaliser concrètement l'ensemble de ces spécifications.

18.2.Phases

La production étant la partie la plus lourde des étapes, les phases aussi sont assez lourdes. Il faut se référer aux

documents sur la production de logiciels. Elle comprend les phases suivantes:

- La mise en place des équipements de développement et les moyens matériels nécessaires de

développement.

- L'écriture, la documentation et la qualification des codes unitaires.

- 'intégration du logiciel

- La qualification du logiciel et de sa documentation, au sein du service de développement.


XIX LA MISE EN ŒUVRE

19.1 Objectifs

Une application informatique est l’ensemble des programmes développés et testés associé à une structure

d'accueil de données mémorisées. Un système informatique est l'ensemble application informatique et

organisation mise en place dans une entreprise. L'objectif de la mise en œuvre est le transfert de l'application

depuis le maître d'œuvre (concepteurs et développeurs) au maître d'ouvrage(utilisateurs).

19-2 Phases

La mise en place se déroule en quatre phases:

- La planification de la mise en service

- La mise en place des ressources

- La préparation du lancement

- La mise en service définitive

19-2 1 La planification de la mise en service

Après toutes les opérations faites dans les étapes de conception (EP, ED), il s'agit de produire un planning de

toutes les tâches de mise en service: On notera spécialement les valeurs de:

- Mise en place des moyens techniques

- Mise en place de l' organisation

- Mise en place des ressources humaines

- Mise en place des informations externes.

19-2 2 Mise en place des ressources

Il s'agit des ressources techniques et humaines. Cette phase comprend aussi les phase suivante:

- Mise en place des moyens informatiques comme le matériel (Ordinateurs terminaux, Serveurs,

Imprimantes), le logiciel système ou spécialisé, le matériel annexe, les aménagements nécessaires.

Ces moyens sont installés selon un ordonnancement.

- Préparation des jeux d'essai qui consiste à produire un ensemble, de données d'essai documentées

en précisant la procédure ou la tâche à tester avec les données d' entrées et les résultats attendus.


- Rédaction de la documentation utilisateur qui comprendra la présentation générale du futur système

et le détail des fonctionnalités (ou ULT), proposées par l'étude détaillée et les modèles qui ont été

réalisés.

- Mise en place de la nouvelle organisation telle que définie par l'étude détaillée qui a précisée:

- La description des nouvelles structures (postes)

- La présentation des nouvelles procédures organisationnelles

- -Les procédures organisationnelles transitoires

- La direction élaborera les nouveaux organigrammes, la définition de nouveaux services et le

calendrier d'application

- Mise en place de ressources humaines. Il s'agit de définir et communiquer les nouvelles fonctions

des utilisateurs.

- Préparation du lancement qui comprend:

- La formation du personnel

- Informer le personnel du nouvel outil et de son impact

- Informer les partenaires du nouveau système et de son impact sur les relations.

- Proposer un plan de lancement.

19-2 3 Mise en exploitation

Cette phase qui manque la naissance réelle du nouveau système se décompose elle aussi en tâches qui sont :

- La recette avant lancement. Pour éviter de rater le lancement, ce qui pourrait être désastreux pour

toute les parties, il faut s'assurer que tout ce qui a été spécifié est opérationnel et s'intègre, bien au

domaine. Proposer des tests pour vérifier la conformité avec les attentes et les performances avant

démarrage.

- Lancement effectif. Le nouveau système est utilisé à partir de cet instant par les utilisateurs eux

mêmes, et non par le maître d’œuvre. On analysera tout de même le nouveau système pour

apporter des retouches. Si le lancement effectif a réussit, on peut arrêter l'ancien système.

- Période probatoire. Quelle que soit la rigueur dans la conception et les tests, des "pannes de

jeunesse" peuvent se présenter auxquelles des solutions doivent être apportées.

- Recettes définitives. A la fin de la période probatoire, il faut mettre fin définitivement à la période de

mise en service avec les conclusions sur la conformité et les performances du nouveau système

(satisfaction ou pas).


XX LA MAINTENANCE

20.1. Objectifs

La maintenance a pour objectifs de;

- Maintenir l'application informatique en bon état de fonctionnement

- Apporter les corrections nécessaires suite à un dysfonctionnement constaté.

- Prendre en compte les évolutions demandées par les utilisateurs ou le service d'exploitation.

20.2. Phases

20.2.1 Prise en compte de la demande de maintenance.

Elle comprend :

- Le recueil de la demande qui consiste à enregistrer formellement toute remarque d'anomalie ou

d'amélioration avec toutes les descriptions (dates, types, poste, application en cause, etc..)

- Analyse de la demande qui consiste à rechercher l'anomalie ou instruction de la demande au niveau

conceptuel et au niveau organisationnel et à proposer des solutions correctives (Equipe de

maintenance)

20.2.2. Réalisation des modifications

Elle comprend les étapes suivantes:

- Etude détaillée pour la conception d'amélioration demandée

- Etude technique

- Production du logiciel tant pour la réalisation de nouvelles transactions que pour la correction

d'anomalie

- Mise en service si l'ampleur de la modification l'implique.


XXI MOYENS DE MISE EN ŒUVRE DE LA

METHODE MERISE

21.1. Structures et intervenants dans un projet MERISE

- Les structures permanentes

- Les structures du projet

- Les structures de conseil

21.1.1. Les structures permanentes.

Ce sont toutes les structures exerçant dans le domaine. On peut citer :

- Les professionnels de la gestion, souvent désignée comme les utilisateurs, cette structure est la

destination de l'application.

- Les professionnels de la réalisation du SI, en général, elle est constituée des informaticiens de la

maison et est souvent appelée les maîtres d'ouvrage.

21.1.2. Les structures du projet

Elles sont constituées de trois groupes formés à l'occasion d'un projet informatique :

- Groupe de pilotage qui a la maîtrise du projet en termes de décisions, coûts et délais.

- Groupe de projet qui est responsable de la production du projet selon les différentes phases dont la

composition souhaité est la suivante :

- Un responsable système d'information, leader des utilisateurs maîtrisant parfaitement le

projet.

- Des utilisateurs concepteurs maîtrisant certains points particuliers du domaine

- Un chef de projet, professionnel de l'information des informaticiens

- Groupe de validation qui est la représentation consultative des futurs utilisateurs.


21.1.3. Les structures de conseil

Sans être partie prenante dans le groupe du projet, certaines spécialités peuvent être consultées de façon

ponctuelle. Ces personnes peuvent être :

- Spécialiste du domaine d'étude

- Spécialiste de la méthode MERISE

- Spécialiste de l'organisation

- Spécialiste des systèmes informatiques

21.2. Rôles des structures dans la démarche

Dans un projet informatique, on distingue les activités suivantes :

- Produire ou participer à la construction du SI dans une de ses composantes (Modèles, écrire un

programme, faire un test)

- Documenter ou rédiger un rapport d'étude, décrire un modèle, documenter un programme, écrire un

manuel utilisateur

- Décider ou choisir des coûts, délais ou qualité

- Valider ou se prononcer sur la conformité de la production par rapport aux souhaits et spécifications

initiales

- Conseiller ou apporter un avis une contribution ponctuelle

- Piloter ou donner une orientation et les choix, diriger l'équipe.

- Approuver les décisions prises

21.2.1. Tableau récapitulatif des activités des structures du projet.

GROUPE DE

PILOTAGE

GROUPE DE PROJET UTILISATEURS

Responsable SI Utilisateurs Chef Projet Informaticien

Etude

Préalable

Décide Pilote

Produit

Produit Produit,

Documente

Produit

Document

Valide

Etude

détaillée

Approuve Valide

Décide

Produit Pilote, Produit,

Documente

Produit

Documente

Valide

Etude

technique

Approuve Pilote, Produit

Décide

Produit

Documente

Réalisation Approuve Pilote, Produit

Décide

Produit

Documente

Mise en

service

Décide Pilote

Produit

Décide

Produit Produit

Valide

Produit Valide


21.2.2. La validation, facteur de qualité

La recherche de la qualité, c'est à dire la conformité du produit fourni aux exigences du client, passe entre autres

par la validation des spécifications du produit. La présence donc des groupes de validation à toutes les étapes de

l'étude préalables et de l'étude détaillée ainsi que de la mise en service est primordiale pour une bonne qualité.

22.3. Outils pour la mise en œuvre

22.3.1. Les ateliers de génie logiciels.

Ces ateliers ont pour but de couvrir tout ou une partie de la conception, du développement et de la maintenance

des applications. En anglais, on parle de Computer Aided Software Engineering ou CASE. Cette approche

initiée par l'informatique à vocation technique de type temps réel tourne autour de deux axes :

- La conception du système d'information.

- Spécification du logiciel et la production

Les différents courants de génie logiciel ont permis la création

- Du développement client serveur

- Le développement rapide

- Le développement en langage objet

22.3.2. La notion de dictionnaire

Le dictionnaire est destiné à mémoriser, contrôler et gérer les différents objets de conception, de réalisation du SI.

Il contiendra les éléments suivants :

- Entité, propriétés, relation

- Opération, événement, acteurs

- Tâche, règle, procédure, phase poste

- Table, enregistrement, champ, attribut

- Unités logiques de traitement, blocs,

- Programme, module, écran


XXIII. MERISE ET LES AUTRES

23.1. Le développement rapide

23.1.1. Contexte des projets micro-informatiques

Le développement rapide de la microinformatique supporte presque les mêmes applications que les gros

systèmes et l'expansion des architectures client - serveur ou le micro joue un rôle primordial ont entraîné la

microinformatique à être confrontée aux mêmes projets que l'informatique classique. Mais, de par leur nature

(convivialité, facilité d'utilisation, puissance), la vision ancienne de la conception a changé. Pour la micro, un

développement rapide s'impose pour les raisons suivantes :

- Limitation des délais car le développement est souvent assimilé en micro développement (Délai

souvent moitié des délais classiques pour les mêmes projets). Cette limitation de délai entraîne la

réduction de l'analyse, et la limitation de la documentation, etc.

- Réduction du champ de l'étude

- Réduction de la taille des équipes de projets.

- Le problème de sécurité. Avec la micro-informatique, la sécurité peut être assurée par les

utilisateurs, ou grâce aux apports de certains SGBD.

- La puissance des outils de développement

- La reprise d'application locale

- Etc.

23.1.2. Les éléments de la démarche du développement rapide.

Dans le développement de système d'information, plusieurs démarches sont utilisées :

- La démarche en cascade (MERISE) est une démarche utilisée dans les cas classiques.

- Le prototypage qui concerne essentiellement la validation des besoins utilisateurs ou des

spécifications de systèmes complexes.

- Le développement rapide (RAD) qui suppose qu'au début du développement, l'utilisateur a une idée

sommaire de ces besoins. C'est donc au cours de la conception / réalisation que la spécification de

ses besoins va se faire.

Le développement rapide va se décomposer de la manière suivante :

- Découpage en projet et selon la complexité des champs de l'étude. Ici on prendra comme

champs de l'étude, un processus en raison de son autonomie fonctionnel, organisationnel et


technique. (Exemple : gestion des impôts foncier, gestion impôts divers, gestion de

l'enseignement). Du coup, il n'y a plus un besoin de l'étape schéma Directeur (sauf pour des

cas complexes).

- Etude préalable. En développement rapide, on préservera le principe de l'étude préalable,

l'étude des différentes fonctions à réaliser, l'estimation des coûts et délais, l'aspect global de

l'étude. Il faut adapter le champ de l'étude, le contenu des spécifications. Il faut minimiser

l'étude de l'existant sauf si elle est déterminante pour la suite du projet, l'étude des différentes

solutions, la rédaction d'un dossier de choix.

- Etude détaillée. On préservera l'essentiel de l'étude détaillé et on minimisera la définition

des procédures transitoires et de secours, les spécifications formelles au travers des MCD,

MOT et MLT.

- Etude technique. On préservera la description opérationnelle de la base et de la définition

des procédures de sécurité, des protections d'accès. On adaptera l'optimisation de la BD, de

la définition des règles de réalisation. On minimisera les spécifications formelles de la

structure logique puis physique des programmes.

- Mise en œuvre. On préservera la rédaction d'un manuel utilisateur et la formation des

utilisateurs.

23.2. Le client - serveur

L'architecture client serveur, apparu dans les années 90, permet de répartir les données et les traitements sur

des systèmes différents et de généraliser les interfaces graphiques des applications de gestion. Elle ne remet pas

en cause les méthodes de conception existantes (y compris MERISE). En outre, la quasi totalité des architectures

client – serveur travailleur sur des SGBD-R

23.2.1. Présentation de l'architecture client.

L'architecture client serveur peut se présenter sous divers aspects à savoir :

- Le découpage d'une application en trois niveaux

- Le dialogue entre un client et un serveur

- Les grands types de Middleware

- Les différents types de client serveurs.


23.2.1.1. Le découpage d'une application

Toutes application est découpée en trois niveaux :

- L'interface avec l'utilisateur. Il est fortement lié à l'environnement graphique et définit la logique de la

présentation.

- Le niveau des traitements qui contient la logique fonctionnelle des traitements et exécute les

procédures de traitement

- Le niveau des données, qui contient la logique (l'intégrité) des données et assure la gestion et les

accès aux données.

23.2.1.2. Dialogue entre un client et un serveur

L'échange entre un client et un serveur s'effectue au moyen d'un réseau qui relie deux machines au moyen d'un

dialogue interprocessus. L'ensemble des couches logicielles qui s'interposent entre application et le réseau est

appelé IPC (Inter Process Communication) ou Middleware. Il permet d'unifier l'accès au réseau de toutes

les applications.

Le dialogue entre client et serveur est supporté des deux côtés par :

- Une API, interface de programmation au niveau de l'application est une couche qui permet à

l'application de faire appel aux services du serveur. Point d'entrée de l'application.

- Des FAP, protocoles de communication et format de données définis (Format And Protocoles), est

une couche qui gère les échanges à travers le réseau et leur synchronisation selon un protocole de

communication. Elle assure la mise en forme des données selon un format et l'ordonnancement des

étapes de l'échange (Connexion – requête – Résultat – Message –Transport).

- Des protocoles de transport. Cette couche insère les messages dans une trame qui circule dans un

réseau (TCP – IP, NetBios par exemple)

- Une méthode d'accès aux médias – couche qui assure l'accès au média de transport (Internet,

Token – Ring.)

APPLICATION SERVEUR

Middleware

Réseau


23.2.1.3. Les grands types de client serveur

Selon la nature du dialogue, on distingue plusieurs types de Middleware :

- Le dialogue synchrone qui fait obligation pour le client d'attendre la réponse du serveur après

chaque envoi.

- Le dialogue asynchrone. Pas d'attente de la réponse du serveur.

- Le dialogue sans connexion qui ne nécessite pas une connexion entre le client et le serveur et qui

fonctionne par appel de procédure. Ce sont des dialogues synchrone. Le message contient tous

les éléments nécessaire au serveur (nom de procédure, paramètres associés, données

d'identification de l'appelant). Le message en retour est un seul flot et contient toute la réponse

attendue par le client (RPC Remote Procedure Call). Il n'est cependant pas assez fiable;

Quant au dialogue avec message, queuing ou dialogue avec queue de message (asynchrone), le client envoie un

message à un destinataire à un service désigné par un nom sans se soucier de sa disponibilité. (L'API repose sur

les deux verbes envoyer. Recevoir puis sur stocker Propager très simple, et garanti qu'un message sera envoyé

une et une seule fois.

- Le dialogue avec connexion et gestion d'une session. Cas de l'APPC (Application Program To

Program Communication (SNA d'IBM)) ou du RDA (Remote Data Access). Après l'acceptation d'une

demande de connexion par le serveur, celui-ci crée un contexte propre au programme du client sur

le serveur. Trois types de messages vont être échangés entre le client et le serveur :

- Emission de requête

- Renvoie de réponse

- Synchronisation du client vers le serveur à commit ou Rollback ou un début ou une fin de

transaction qui permet de garder un état stable du contexte

23.2.1.4. Les différents types de client serveur

Une application s'articule autour de trois points à savoir la présentation (les interfaces de l'application), les

traitements et les données. Selon que le service fournit par le serveur relève de l'un ou d'une combinaison de ces

points, nous aurons différents types d'architecture client serveur

- Le client serveur de présentation. Ici, seule la présentation est déportée sur le poste client. Les

données et la logique qui sous-tend la gestion de la fenêtre et des traitements sont au niveau du

serveur.


- Le client serveur de données. Les données sont essentiellement sur le serveur tant disque la

présentation et les traitements sont sur le client. Dans le cas d'une BD reparties, certaines données

peuvent se trouver sur le poste client.

- Le client serveur de traitements. Au niveau du serveur, nous avons les données et les traitements.

Au niveau du client nous avons les traitements et la présentation. Dans le cas d'une BD distribuée,

nous avons des données au niveau des postes client (Client Serveur deuxième génération).

DONNEES

TRAITEMENTS

PRESENTATION

Serveur

Client

DONNEES

TRAITEMENTS

PRESENTATION

Serveur

Client

Gestion distante des données

DONNEES

DONNEES

TRAITEMENTS

PRESENTATION

Bases de données distribuées


23.2.2. MERISE et la conception de SI en environnement

client - serveur.

L'expérience des premières architectures client serveur nous permet d'avancer que :

- Les modélisations des données et des traitements sont adaptées aux nouvelles possibilités offertes

par le client serveur.

- La répartition organisationnelle s'avère un élément décision dans la répartition informatique client

serveur.

23.2.2.1. La modélisation des données et des traitements pour le

client serveur.

Deux niveaux de modélisation sont à considérer :

- La modélisation conceptuelle et organisationnelle des données. Comme le client serveur qui

consacre la place centrale des données dans les SI, le formalisme relationnel entité/relation est en

adéquation avec le client serveur. Ainsi on a :

DONNEES

TRAITEMENTS

PRESENTATION

Serveur

Traitements distribués

DONNEES

DONNEES

TRAITEMENTS

PRESENTATION

Traitements et bases de données distribuées

TRAITEMENTS TRAITEMENTS


- La répartition des données et des traitements sur des systèmes distincts en client serveur nécessite

une indépendance entre la structuration des données et des traitements (MERISE).

- La conception d'un serveur de données avant mêmes de connaître les données et les traitements à

implanter (Système ouvert est favorisé par MERISE.

- La formalisation des contraintes interrelations, le concept de stabilité et le concept de règles qui sont

traduits au niveau logique par des "triggers"" a été rendu nécessaire pour la prise en compte du

client - serveur, 2ème génération. Dans architecture, certaines règles, procédures et autres sont

stockées au niveau du serveur.

- La modélisation logique des données et traitements repartis. Dans la deuxième génération de client

serveur (client serveur de traitements distribués et (ou sans) bases de données distribuées), les

données et les traitements d'une même application peuvent être reparti entre les postes clients et

plusieurs serveurs. Avec MERISE, on peut exprimer cette répartition au moyen :

- Des machines logiques

- Des ULT globales décomposées en ULT par nature.

23.2.2.2. De la modélisation organisationnelle à la répartition

informatique.

Les formalisations de la répartition organisationnelle

- Des traitements s'effectuent au travers des MOT repartis avec des degrés de détail.

- Des données s'effectuent aussi au travers des MOD


XIV MERISE ET L'APPROCHE ORIENTE OBJET

24.1. Introduction

L'approche orienté objet est bien adapté à conception et à la réalisation des systèmes d'informations distribués

car elle offre une manière claire de concevoir une architecture modulaire encapsulant la complexité et facilitant

l'implémentation multi plate forme.

Les dernières années, l'approche objet s'est particulièrement distingué dans le domaine des interfaces homme /

machine. Ici, l'utilisateur choisit l'objet et le service qu'il veut en attendre.

Pour arriver à concevoir et à développement des applications avec l'approche orienté objet, des méthodes

orientées objet et des langages orientés objets existent. On peut citer les OOD, OOA, OOSE et le plus récent

mais le plus utilisé, l'OMT (Objet Modeling Technique. Il faut cependant reconnaître que toutes ces méthodes

relèvent plus du génie logiciel que de la conception de système d'information.

En ce qui concerne MERISE, il faut évoluer vers :

- Transition MERISE objet surtout MERISE pour le SI0 et l'objet pour le SII

- MERISE 3ème génération avec le tout objet

24.2. Transition vers l'objet

Cette solution consiste à coupler MERISE avec une méthode de génie logiciel orienté objet. L'exemple du

couplage de MERISE et de L'OMT.

24.2.1. Présentation générale de L'OMT

Concernant cette méthode (Objet Modeling Technique), seuls les grands principes vont être présentés. OMT

présente trois modèles :

- Le modèle objet

- Le modèle dynamique

- Le modèle fonctionnel


24.2.1.1. Le modèle objet (MO) le plus important des modèles

Il se présente comme une extension du modèle Entité – Association. L'OMT introduit cependant l'agrégation, la

généralisation et surtout la spécification d'opérations et de contraintes au niveau des entités nommées classes.

- Classes et instances. Une classe d'objet modélise un ensemble d'objets ayant des propriétés

similaires (attributs) et des comportements similaires (opérations).

- Association binaire et n - aire

- Généralisation, spécialisation et héritage. Identique au concept de sous-classe. A chaque sous-

classe mérite de la surclasse associée (attributs, opérations).

- Agrégation : relations ternaires ou plus .

- Contraintes sur :

- Les objets

- Des attributs ch > 0

- Des liaisons X ou XT

- Clé candidate : l'ensemble des attributs pouvant identifier de manière unique, une classe

24.2.1.2. Le modèle dynamique MD

Présente les aspects de l'application affectés par le temps et spécifie l'ordonnancement de l'exécution des

opérations déjà définies dans le modèle. Ce modèle se présente comme un diagramme d'états transition

spécifiant l'ordonnancement des états des événements autorisés pour une classe d'objets. Sur ces diagrammes

sont mentionnés les opérations de transformations associées. Les concepts associés à ce modèle sont :

- L'événement d'un objet vers un autre. On peut regrouper les événements de même structure de

message et de comportements communs en classe d'événements.

- Etats et transition. L'état est la valeur d'un objet durant un intervalle de temps ou durant l'occurrence

de deux événements. Une transition est d'écrite par l'événement qui la déclenche.

24.2.1.3. Le Modèle fonctionnel (MF)

Il modélise les processus de transformation de l'application. Il se présente comme un diagramme de flux

classique modélisant des processus transformant des données, des flux de données transportant des données,

des objets acteurs et enfin des dépôts de données. Les principaux concepts utilisés sont :

- Processus. Il transforme des données. Il est représenté par une ellipse et un flot de contrôle par une

flèche en pointillée orienté du processus contrôlant vers le processus contrôlé. Pour chaque

processus, on a les quatre opérations suivantes :

- Opération d'accès – Ecrivent ou lisent des attributs

- Opération requête – Présente les états


- Opérations action – Modifient d'autres objets – Durée nulle

- Opération activité – Modifie d'autres objets –Durée limitée

- Flux de données – connexion entre la sortie d'un processus et l'entrée d'un autre.

- Dépôt de données – Objet passif qui assure le stockage de valeurs pouvant être simples ou

agrégées.

Documents

--CCoo uurrss PPrriivvééss Conception