Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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
Page (2 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
Page (3 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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. -------------------------------------------------------------------------------------------------------------------------------------------
Page (4 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.---------------------------------------------------------------------------------
Page (5 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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 ----------------------------------------------------------------------------------------------------------------
Page (6 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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 -------------------------------------------------------------------------------------------------------------------
Page (7 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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. --------------------------------------------------------------------------------
Page (8 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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 -------------------------------------------------------------------------------------------------------
Page (9 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (10 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
Page (11 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (12 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (13 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (14 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (15 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (16 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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)
Page (17 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (18 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (19 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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
Page (20 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (21 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (22 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
CONCEPTION DU SYSTEME
D'INFORMATION
ORGANISATIONNEL
Page (23 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (24 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (25 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (26 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (27 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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
Page (28 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
ArticleDisponibilité
OK
ArticleDisponibilité
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
Page (29 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (30 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (31 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (32 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
* 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
Page (33 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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).
Page (34 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (35 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
* 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
Page (36 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (37 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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.
Page (38 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
CONTROLE SITUATION ASSURE
Non couvert
Avis de rejetOUVERTURE DOSSIER
Dossier
Assuré
Page (39 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
CONTROLE SITUATION ASSURE
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
Page (40 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (41 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (42 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (43 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (44 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (45 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (46 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
III CONCEPTION DU
SYSTEME INFORMATISE
D’INFORMATION
Page (47 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (48 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (49 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (50 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (51 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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)
Page (52 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (53 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (54 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (55 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (56 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (57 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (58 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- Saisir mode de paiement
Logique fonctionnelle
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
Page (59 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
❸ ULT Enregistrement et édition
Présentation
Logique de dialogue
Sans objet
Logique fonctionnelle
- 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 :
Page (60 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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 :
Page (61 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
Page (62 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (63 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
Page (64 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (65 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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éé
Page (66 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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
Page (67 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
IV LA DEMARCHE MERISE
Page (68 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (69 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (70 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (71 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (72 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (73 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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)
Page (74 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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.
Page (75 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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
Page (76 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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é.
Page (77 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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?
Page (78 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (79 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (80 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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.
Page (81 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (82 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (83 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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).
Page (84 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (85 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (86 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (87 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (88 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (89 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (90 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (91 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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.
Page (92 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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
Page (93 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (94 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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
Page (95 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (96 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
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
Page (97 / 97) Créé le 19/10/2016 08:38:00 par **Robert GNENESSIO
- 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.