Vous êtes sur la page 1sur 36

MERISE : une méthode systèmique de conception de SI - Présentation générale -

Bernard ESPINASSE Professeur à l'Université d'Aix-Marseille

Plan

• Origine et évolution

• Principes généraux

• Cadre de modélisation et démarche préconisée

• Principales dernières évolutions

Introduction : les méthodes Systémiques

• méthodes s'appuyant sur une approche systémique

• définissent différents niveaux de préoccupation ou d'abstraction

• proposent de nombreux modèles complémentaires

• sont souvent spécialisées pour la conception d'un certain type de systèmes

• méthodes systémiques les plus connues :

MERISE (méthode la plus utilisée en informatique de gestion en France et grande partie de l'Europe)

AXIAL (IBM - systèmes d'information), MEGA (Mega - systèmes d'information),

OSSAD (systèmes bureautiques)

SAGACE (CEA - systèmes complexes (centrales atomiques))

GRAI (Productique)

Origine de Merise : Merise 1° génération

• 1978 - Ministère de l'industrie : Merise 1° génération

• concevoir et définir une méthode d'intérêt national

• principales SSII et le CETE d'Aix-en-Provence (H.Tardieu - A.Rochfeld)

1974-1978

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

Ministère de l'Industrie

recherche en systèmique appliquée aux organisations

recherche en systèmique appliquée aux organisations MERISE 1976 1977 SSCI 1979 -> synthèse : •

MERISE

1976

1977

SSCI

1979

-> synthèse :

• réactualise acquis sur la spécification des traitements des méthodes antérieures

• intègre l'approche par les données

• propose une démarche garantissant la rigueur de la méthode et sa facilité d'application sur le terrain

Merise

• 1979 : Merise 1° génération

• 1992 : Merise 2° génération

• bibliographie complémentaire :

• Nanci D., Espinasse B. et al., Ingénierie des Systèmes d'Information:

Merise Deuxième Génération - 3° Édition entièrement revue et augmentée, Éditions Sybex, 1996.

• Tardieu H., Rochfeld A., Coletti R., La méthode Merise, tome 1 : Principes et outils, éditions d’Organisation, 1983.

• Tardieu H., Rochfeld A., Coletti R., Panet G., Vahee G., la Méthode Merise, tome 2 : Démarche et pratiques, éditions d’Organisation, 1985.

• Rochfeld A., Morejon, J., la Méthode Merise, tome III : Gamme opératoire, éditions d’Organisation, 1989.

Objectifs de Merise

Pour être efficace une méthode doit pouvoir :

• associer étroitement les aspects organisationnels et informatiques

• accroître la qualité des relations entre les utilisateurs et les informaticiens dans la mesure ou l'informatisation peut modifier les modes de gestion et les conditions de travail

• être acceptée par les uns et les autres comme moyen:

• d'étude

• de conception

• de dialogue

• de formalisation de décision de choix

• de contrôle d'avancement,

• être précise pour être efficace,

• sans être abusivement rigide pour être tolérée

évaluer au préalable : les dépenses et les conséquences liées aux solutions de conception

Principes fondamentaux de la méthode MERISE

apport de la systémique (Bertalanffy, LeMoigne,

):

tente depuis 30 ans d'apporter

un nouveau cadre de réflexion, de modélisation des structures complexes vivantes

(biologie, sciences sociale, gestion,

)

=> l'organisation en tant que système

• découpage de l'organisation en domaines

analyse indépendante Données / Traitements

• une démarche à 3 dimensions :

• la démarche: cycle de vie

• le raisonnement : niveaux d'abstraction

• la maîtrise: niveaux de décision

La démarche ou cycle de vie

• modèle de la cascade :

La démarche ou cycle de vie • modèle de la cascade : "plan d'action" SHEMA DIRECTEUR
"plan d'action" SHEMA DIRECTEUR "dossier de choix" ETUDE PREALABLE "cahier des charges
"plan d'action"
SHEMA DIRECTEUR
"dossier de choix"
ETUDE PREALABLE
"cahier des charges
utilisateur"
ETUDE DETAILLEE
"cahier des charges
technique"
ETUDE TECHNIQUE
"dossier de
réalisation"
REALISATION
MISE EN SERVICE

"manuel

utilisateur"

La démarche ou cycle de vie

schéma directeur

schéma directeur
schéma directeur
schéma directeur
schéma directeur Définition des orientations générales du développement à moyen terme des systèmes d'information
schéma directeur Définition des orientations générales du développement à moyen terme des systèmes d'information
schéma directeur Définition des orientations générales du développement à moyen terme des systèmes d'information

Définition des orientations générales du développement à moyen terme des systèmes d'information

à moyen terme des systèmes d'information PROJET étude préalable Proposition et évaluation de
PROJET étude préalable Proposition et évaluation de solutions d'organisation et techniques pour le SI d'un
PROJET
étude préalable
Proposition et évaluation de solutions d'organisation et
techniques pour le SI d'un domaine
étude détaillée
Spécifications complètes du futur SIO. Point de vue
de l'utilisateur (externe).
étude technique
Spécifications complètes du futur SII. Point de vue du
réalisateur (interne).
production logiciel
Ecriture des programmes, génération des fichiers ou bases
de données, tests
mise en service
Installation de l'application informatique, mise en
place de la nouvelle organisation
maintenance
Rectification des anomalies, améliorations, évolutions

Rectification des anomalies, améliorations, évolutions

Les raisonnements ou niveaux d'abstraction

Exemples de choix :

choix de gestion:

faire de la pré-facturation ou de la post-facturation

• procéder à des contrôles systématiques des dossiers avant de les traiter ou les traiter sans contrôles et procéder à des contrôles par échantillonnage

• affecter certains produits à tels dépôts

• admettre qu'une commande client pourra être livrée en plusieurs fois, chaque livraison donnant lieu à une facture choix d'organisation:

les quantités réceptionnées seront saisies en fin de journée sur un terminal dans le magasin

• l'interrogation des commandes se fera en temps réel sur ce même terminal choix techniques:

mettre à tel endroit un terminal de telle marque

• exécuter tel traitement dans tel programme

• implanter telle donnée sur tel disque

Les 4 niveaux d'abstraction de MERISE

Système d'Information Organisationnel (SIO) :

• niveau conceptuel exprime les choix fondamentaux de gestion: recherche des éléments stables indépendamment des moyens à mettre en oeuvre, de leurs contraintes et de leur organisation.

• niveau organisationnel exprime les choix d'organisation de ressources humaines et matérielles, au travers de la définition de sites, de postes de travail,

Système d'Information Informatisé (SII) :

• niveau logique exprime les choix de moyens et de ressources informatiques, en faisant abstraction de leurs caractéristiques techniques précises.

• niveau physique traduit les choix techniques et la prise en compte de leurs spécificités.

SYSTEME D'INFORMATION ORGANISATIONNEL SIO SYSTEME D'INFORMATION INFORMATISE SII
SYSTEME D'INFORMATION ORGANISATIONNEL
SIO
SYSTEME D'INFORMATION
INFORMATISE
SII

Les 4 niveaux d'abstraction de MERISE

Système d'Information "naturel" choix de gestion Système définition des informations et des
Système
d'Information
"naturel"
choix de gestion
Système
définition des informations
et des activités
niveau conceptuel
d'Information
Organisationnel
choix d'organisation
S.I.O.
niveau
types de ressources et
affectation
organisationnel
choix logiciels
moyens et ressources
informatiques
niveau logique
Système
d'Information
choix techniques
Informatisé
S.I.I.
ressources effectives
niveau physique

Applications informatiques supports du système d'information

Les Modèles de Merise

Données

Traitements

 

Modèle Conceptuel des Données

Modèle Conceptuel desTraitements

MCD

MCT

SIO

Signification des informations sans contrainte technique ou économique

 

CONCEPTUEL

Activite du domaine sans préciser les ressources ou leur organisation

et

   

ORGANISATIONNEL

Modèle Organisationnel des Données

Modèles Organisationnels des Traitements

MOD

MOT

 

SYSTEME

Signification des informations avec contrainte organisationnelles et économique

D'INFORMATION

Fonctionnement du domaine avec les ressources utilisées et leur organisation

 

Modèle Logique des Données

Modèles Logique des Traitements

SII

LOGIQUE

MLD

MLT

SYSTEME

Description des données tenant compte de leurs conditions d'utilisation par les traitements

Fonctionnement du domaine avec les ressources et leur organisation informatiques

D'INFORMATION

INFORMATISE

   

Modèle Physique des Données

Modèle Physique des Traitements

MPD

MPT

 

PHYSIQUE

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

Architecture technique des programmes

ORGANISATIONNEL

Architecture technique des programmes ORGANISATIONNEL préoccupations du préoccupations de gestionnaire-

préoccupations du

préoccupations du préoccupations de

préoccupations de

gestionnaire-

l'informaticien

utilisateur

Modèles et niveaux d'abstraction

se pose le problème de :

comment élaborer et exprimer les différents modèles? formalismes adaptés à chaque modèle conseils de mise en oeuvres

comment passer d'un niveau d'abstraction au suivant et transformer les différents modèles? procédures de transformation prise en compte de nouveaux choix

comment confronter données et traitements pour assurer une cohérence interne? vérification de cohérence

Cycle de décision dans MERISE

étapes de la démarche résultats plan de schéma directeur développement des SI étude préalable dossier
étapes de la démarche
résultats
plan de
schéma directeur
développement
des SI
étude préalable
dossier de choix
n solutions
stop
spécifications
étude détaillée
fonctionnelles
spécifications
étude technique
techniques
pour réalisation
réalisation logiciel
système réalisé
en ordre de marche
mise en service
système installé
dans l'organisation
système
maintenance
maintenu

décisions

approbation et mise en application

choix d'une solution ou arrêt

 
 
  stop

stop

accord utilisateur /specifs fonctionnelles

 

accord réalisateurs

 

/specifs techniques

recette provisoire conformité système

 

recette définitive système en service

 

recette simplifiée fin de maintenance

 
 
   
 

Cheminement du processus de conception "courbe du soleil"

8 3 niveau 2 conceptuel SIO niveau 7 organisationnel 9 4 niveau 1 10 5
8
3
niveau
2
conceptuel
SIO
niveau
7
organisationnel
9
4
niveau
1
10
5
logique
SII
niveau
11
6
physique
système d'information
état actuel
système d'information
état futur
état actuel système d'information état futur champ de l'étude préalable champ de l'étude

champ de l'étude préalable

état futur champ de l'étude préalable champ de l'étude détaillée prise en compte

champ de l'étude détaillée

prise en compte d'objectifs, de contraintes, d'orientations nouvelles

Niveaux d'abstraction et du degré de détail

degré global détaillé niveau conceptuel organisationnel zone d'utilisation classique logique physique
degré
global
détaillé
niveau
conceptuel
organisationnel
zone d'utilisation classique
logique
physique

Démarche et couverture des niveaux d'abstraction

0%

étude préalable

 

100%

conceptuel

     

organisationnel

   

logique

   
 

physique

0%

étude détaillée

 

100%

conceptuel

   

organisationnel

 

logique

   

physique

 

0%

étude technique/réalisation

100%

conceptuel

organisationnel

logique

physique

Évolution de la méthode MERISE

• depuis 1992 : Merise 2° génération

• évolution du cadre de modélisation

• l'extension de 3 à 4 niveaux d'abstraction (conceptuel, organisationnel, logique et physique)

• émergence de nouveaux modèles :

• modèle logique de traitements (MLT)

• modèle organisationnel de données (MOD),

• distinction de 2 missions distinctes de l'ingénierie des SI :

• conception du Système d'Information Organisationnel (SIO)

• conception du Système d'Information Informatisé (SII)

• évolution des outils et formalismes associés

extension du formalisme Entité-Relation, avec par exemple l'explicitation de types et sous-types, de contraintes d'intégrité,

clarification de la modélisation des traitements à l'aide du formalisme issu des réseaux de Pétri, à différents niveaux de préoccupation,

Évolution de la méthode MERISE (suite)

• Merise 2° génération :

MCT : introduction du concept d'état et ses conséquences sur les aspects de modélisation,

MCD : amendements concernent les récentes extensions du formalisme

Entité-Relation, le traitement de l'historisation,

,

MOT : avec l'introduction des cycles de vie des objets (CVO),

MOD : répartition organisationnelle des données (MOD locaux) et toute sa pertinence dans contexte d'architectures client-serveur,

MLT : approche et modélisation opérationnelles, adaptées aux nouveaux

environnements (Client-Serveur, interfaces graphiques,

),

MLD : passage du modèle Entité-Relation au modèle relationnel enrichi :

• prise en compte des contraintes d'intégrité

• écriture des triggers associés, l'historisation,

Mise en oeuvre de la méthode MERISE (suite)

• couplage avec des méthodes de conduite de projet ,

• développement d'ateliers

de

génie

logiciel

(A.G.L.) de conception : AMC

Designer, MEGA, WinDesign,

• ouverture vers les autres méthodes :

de génie logiciel (Merise et Yourdon [PHAN 85],

),

de génie cognitif (Merise et KADS [BRUNET 90],

),

• adaptation à d'autres types d'activités :

domaine de la productique (Merise et GRAI [Cecima 90]),

l'EDI (Merise et l'EDI [BCEL 91])

largement

diffusée en France et dans l'Europe du Sud (parfois avec des

adaptations mineures)

• constitue un standard en conception de système d'information

MCT : introduction du concept d'état

• établi lien entre modélisation des données et modélisation des traitements

• peut s'exprimer :

• par une valeur prise par une information (dossier en cours),

• par le fait qu'une activité à été réalisée (calcul des pénalités effectué),

• par une règle de traitement (délai de règlement dépassé de 15 j.)

mémorisation des états assurée par les données informations spécifiques (ex: état de la commande).

• s'applique à des objets et associations modélisés dans les données

• description d'un état d'un objet :

• le nom de l'objet,

• le nom de l'information décrivant le type d'état,

• la valeur de l'état,

• éventuellement la règle permettant de déterminer l'état.

• représentation graphique :

DOSSIER CREDIT situation contentieux commandement
DOSSIER CREDIT
situation contentieux
commandement

Exemple d'utilisation du concept d'état

ARTICLE CLIENT disponibilité demande OK et VENTE DIRECTE AU COMPTANT Enregistrer la commande Facturer
ARTICLE
CLIENT
disponibilité
demande
OK
et
VENTE DIRECTE
AU COMPTANT
Enregistrer la commande
Facturer
Enregistrer le règlement
Remettre les articles
articles
en stockdernier article vendu
CLIENT
facture comptant
ARTICLE
disponibilité
COMMANDE
rupture
livrée
FACTURE
réglée

MCD : récentes extensions du formalisme Entité- Relation

• Types et sous-types d’entités : spécialisation/généralisation Spécialisation simple Spécialisations
• Types et sous-types d’entités : spécialisation/généralisation
Spécialisation simple
Spécialisations multiples
Spécialisations à surtypes
multiples
ADHERENT
TIERS
TIERS
n° tiers
n° adhérent
n° tiers
raison sociale
date adhésio
adresse administrative
raison
sociale
adresse
adresse
type
statut
type
statut
XT
T
CLIENT
FOURNISSEUR
PERSONNE MORALE
PERSONNE PHYSIQU
COTISANT
BENEFICIAIRE
n° client
adresse de livraison
conditions de vente
n° fournisseur
délai de livraison
n° SIREN
n° INSEE
taux
date ouverture droi
FOURNISSEUR
CLIENT
raison sociale
nom
date création
prénom
condition de règlement
taux de remise
forme juridique
date naissance

• Restrictions et sous-types de relations

EMPLOYE 1,n PROJET 0,n 0,1 SECRETAIRE 0,n gérer
EMPLOYE
1,n
PROJET
0,n
0,1
SECRETAIRE
0,n
gérer

MCD : récentes extensions du formalisme Entité- Relation

• Contraintes intrarelation

• Contraintes interrelations

Rel_1 0,n Ent_1 X Rel_2 0,n
Rel_1
0,n
Ent_1
X
Rel_2
0,n

EXCLUSION

 
Rel_1 0,n Ent_1 XT Rel_2 0,n
Rel_1
0,n
Ent_1
XT
Rel_2
0,n

EXCLUSION et TOTALITÉ Toute occurrence de l’entité Ent_1 participe au moins soit à la relation Rel_1, soit à la relation Rel_2, mais pas aux deux à la fois.

Si

une

occurrence

de

l’entité

Ent_1 participe à

la

relation

Rel_1, elle ne peut pas participer

à

la

relation

Rel_2

et

réciproquement (possibilité d’orientation de cette exclusion)

Rel_1 0,n Ent_1 S Rel_2 0,n
Rel_1
0,n
Ent_1
S
Rel_2
0,n

SIMULTANÉITÉ Toute occurrence de l’entité Ent_1

Rel_1 0,n Ent_1 I Rel_2 0,n
Rel_1
0,n
Ent_1
I
Rel_2
0,n

INCLUSION

Si une occurrence de l’entité

participant à la relation Rel_1 participe simultanément à la relation Rel_2.

Ent_1 participe à la relation

Rel_1, elle

participe

à

la

relation Rel_2 (mais réciproquement).

pas

Rel_1 0,n Ent_1 S Rel_2 0,n
Rel_1
0,n
Ent_1
S
Rel_2
0,n

TOTALITÉ Toute occurrence de l’entité Ent_1

   

participe au moins à l’une des deux relations Rel_1 ou Rel_2.

Historisation

• Historisation des valeurs d’une propriété

PERSONNE nom antérieurement DATE prénom 0,n 1,n adresse jj_mm_aa date naissance adresse
PERSONNE
nom
antérieurement
DATE
prénom
0,n
1,n
adresse
jj_mm_aa
date naissance
adresse

• Propriété historisée

PERSONNE ident nom adresse (H)
PERSONNE
ident
nom
adresse (H)

• Entité historisée

PERSONNE (H) ident nom adresse nombre d'enfan
PERSONNE (H)
ident
nom
adresse
nombre d'enfan

• Relation historisée

PERSONNE 1,n louer (H) 1,n LOGEMENT montant loyer
PERSONNE
1,n
louer (H)
1,n
LOGEMENT
montant loyer

• Patte de relation historisée

ASSURE présent dans DOSSIER 0,n 1,n (H)
ASSURE
présent dans
DOSSIER
0,n
1,n (H)

MOT : introduction des cycles de vie des objets (CVO)

• Concepts généraux de la modélisation de la dynamique

• Etat : abstraction des valeurs des attributs et des associations d'un objet,

• Evénement : stimulus accompagné éventuellement d'information,

• Transition : modification d'état provoquée par un événement,

• Diagramme d'états : graphe dont les noeuds sont des états et les arcs orientés des transitions désignées par des noms d'événements.

déclaration

désignées par des noms d'événements. déclaration ouvert c o n t r o l é a

ouvert

par des noms d'événements. déclaration ouvert c o n t r o l é a c
par des noms d'événements. déclaration ouvert c o n t r o l é a c

controlé

accepté

ouvert c o n t r o l é a c c e p t é
en instruction trop grave non couvert
en instruction
trop
grave
non
couvert
c c e p t é en instruction trop grave non couvert transmis en attente renvoi

transmis

en attente

instruction trop grave non couvert transmis en attente renvoi hors délai clos facture reçue réglé pièces
instruction trop grave non couvert transmis en attente renvoi hors délai clos facture reçue réglé pièces

renvoi

hors

délai

clos

facture

reçue

réglé

pièces

manquantes

incomplet

Diagramme d'états du dossier de sinistre

• les méthodes objet ajoutent d'autres concepts :

• Condition : associée à une transition,

• Opération : associée à l'état, décrit ce que fait l'objet en réponse à l'événement

MOT : introduction des cycles de vie des objets (CVO)

• Concepts retenus pour le cycle de vie des objets dans Merise

• Etat,

• Evénement,

• Activité : (opération, tâche) appelée Transition avec si nécessaire synchronisation et conditions

• Particularités du CVO Merise :

le passage d'un état à un autre nécessite obligatoirement une transition indiquant à minima les activités permettant ce changement d'état,

une transition pas obligatoirement déclenchée par un événement explicite : déclenchement implicitement liée à un événement décisionnel

Dossier Sinistre facture en attente Règlement contrôler facture calculer montant indem Dossier Sinistre réglé
Dossier Sinistre
facture
en attente
Règlement
contrôler facture
calculer montant indem
Dossier
Sinistre
réglé

• passage de l'état "attente" de l'objet "Dossier sinistre" à l'état "réglé" de celui-ci,

• passage déclenché par l'événement "facture" et nécessitant la réalisation de l'activité "Réglement"

MOD : répartition organisationnelle des données (MOD locaux) pour les architectures client-serveur

• Répartition organisationnelle des données = répartition d'utilisation de ces données suivant les différentes unités organisationnelles.

en

• permet

d'orienter

ultérieurement

la

répartition

informatique

des

données,

particulier dans des environnements clients / serveurs

• MOD local à une unité organisationnelle

• exprime, du point de vue de l’utilisateur, les données accessibles par un ensemble de postes de l'unité organisationnelle

• pour chaque unité organisationnelle MOD local :

sous-ensemble du MOD global : sous ensemble d'entités-types, de relations-types et de propriétés

tableau précisant les éventuelles restrictions sur les occurrences disponibles d'entités ou de relations : une agence (unité organisationnelle) ne gère que les contrats de son secteur.

• permet de mettre en évidence :

• les données communes à l'ensemble du domaine,

• les données partagées entre certaines unités,

• les données privées à une unité.

MOD : répartition organisationnelle des données (MOD locaux) pour les architectures client-serveur

0,n (R) 1,n 0,n Unités organisationnelles et MOD locaux
0,n
(R)
1,n
0,n
Unités organisationnelles et MOD locaux

accessibilité des données d'un MOD local : actions élémentaires possible pour tous les traitements réalisés dans le site organisationnel => préciser différents types d’accès, lecture (L), modification (M), création (C) et suppression (S)

si partage entre plusieurs UOs et si répartition informatique : préciser quelle UO fait référence en cas de divergence dans le contenu des informations partagées.

MOD : répartition organisationnelle des données (MOD locaux) pour les architectures client-serveur

• Sécurité des données :

• s'exprime, selon les cas, au niveau du MOD global ou des MOD locaux

• passe par la définition de catégories ou profils d'utilisateurs

• definir les restrictions d'accès aux données mémorisées pour certaines profils d'utilisateurs concernant un type d'action limité (L, M, C, S) :

• soit aux entités, relations ou propriétés du MOD global ou local, • soit à une sous-population des occurrences d’entités/relations

Profil utilisateur : Employé

Entité - Relation Propriété

restriction ou autorisation

CLIENT niveau découvert

Lecture seule autorisée

Profil utilisateur : Chef de service

Entité - Relation Propriété

restriction ou autorisation

CLIENT niveau découvert

Modification autorisée montant <= 10 000 F.

Profil utilisateur : Directeur

Entité - Relation Propriété

restriction ou autorisation

CLIENT niveau découvert

Modification autorisée tout montant

MLT : modélisation adaptée aux environnements Client- Serveur, interfaces graphiques,

Machine logique

machine physique = ensemble de matériels permettant d'assurer les fonctions de base de l'informatique (exécution de logiciel, mémorisation, entrées/sorties).

• machine logique = ensemble de ressources informatiques (matériel et logiciel) capables d'exécuter des traitements informatiques de façon autonome

• une machine logique peut être :

équivalente à une machine physique : micro autonome ou en réseau, serveur, mainframe ou mini avec terminaux passifs.

composée de plusieurs machines physiques : mini et micro en émulation terminal passif, mainframe et machine base de données.

une partie de machine physique : machine virtuelle sur un mainframe.

MLT : modélisation adaptée aux environnements Client- Serveur, interfaces graphiques,

Répartition des traitements entre des machines logiques :

SYSTEME DEPARTEMENTAL AGENCE SYSTEME INTER-COMPAGNIES infos adversaire début et CONTROLE PARTIE ADVERSE Saisie des
SYSTEME DEPARTEMENTAL AGENCE
SYSTEME INTER-COMPAGNIES
infos adversaire
début
et
CONTROLE PARTIE ADVERSE
Saisie des informations de la partie adverse :
compagnie, n° contrat, n° véhicule
léments d'identificatio
ompagnie hors conventio
ompagnie conventionné
CONTROLE EXISTENCE NATIONALE
Vérifier au fichier central des assurances
la validité des informations saisies
connu
inconnu
nfos administrative
ENREG INFOS PARTIE ADVERSE
mise à jour dossier sinistre
ou
SAISIE COMPLEMENT DOSSIER
Saisir les informations connues
pour traitement hors procédure
standard d'indemisation directe
fin

MLT : modélisation adaptée aux environnements Client- Serveur, interfaces graphiques,

• l'Unité Logique de Traitement = ensemble des traitements informatiques homogènes à réaliser qui peuvent être décomposés selon leur nature :

• Interface,

• Traitements,

• Données.

Composants fonctionnels d'une ULT :

PRESENTATION LOGIQUE DE DIALOGUE ACCES AUX DONNEES LOGIQUE FONCTIONNELLE REGLES DE CALCUL ENCHAINEMENTS
PRESENTATION
LOGIQUE DE
DIALOGUE
ACCES AUX
DONNEES
LOGIQUE
FONCTIONNELLE
REGLES
DE CALCUL
ENCHAINEMENTS

Sous schéma de données logique associé à l'ULT :

Enregistrer sinistre

Enregistrer sinistre Nouveau dossier sinistre ASSURE VEHICULE CODE N° IMMATRICULATION NOM TYPE ADRESSE MARQUE

Nouveau dossier sinistre

Enregistrer sinistre Nouveau dossier sinistre ASSURE VEHICULE CODE N° IMMATRICULATION NOM TYPE ADRESSE MARQUE
ASSURE VEHICULE CODE N° IMMATRICULATION NOM TYPE ADRESSE MARQUE PUISSANCE FISCALE concerner couvrir SINISTRE
ASSURE
VEHICULE
CODE
N° IMMATRICULATION
NOM
TYPE
ADRESSE
MARQUE
PUISSANCE FISCALE
concerner
couvrir
SINISTRE
N° SINISTRE
CONTRAT
N° POLICE
N° POLICE
NOM
N° IMMATRICULATION
rattaché à
DATE OUVERTURE
CODE
DATE SURVENANCE
NATURE

MLD : passage du modèle Entité-Relation au modèle relationnel enrichi

• prise en compte des types et sous-types :

-> écriture des assertions SQL ou des triggers associés

• prise en compte des contraintes d'intégrité :

-> écriture des assertions SQL ou des triggers associés

• prise en compte de l'historisation :

-> écriture des assertions SQL ou des triggers associés

MLD : passage du modèle Entité-Relation au modèle relationnel enrichi

exemple de contrainte inter relations d'inclusion : toute personne qui effectue un prêt doit avoir
exemple de contrainte inter relations d'inclusion : toute personne qui effectue un
prêt doit avoir souscrit un abonnement :
Entité-Relation
Relationnel dérivé
ABONNEMENT
souscrire
ABONNEMENT
SOUSCRIRE
n°abonnement
PERSONNE
n°abonnement
1,n
0,1
SOUSCRIRE
n°personne
n°abonnement
occurrences de
PERSONNE
PRET
I
PERSONNE
EFFECTUER
n°personne
n°pret
n°personne
0,n
EFFECTUER
PRET
1,1
n°pret
effectuer

Assertion SQL 2 :

Trigger oracle :

CREATE ASSERTION I CHECK (NOT EXISTS (SELECT DISTINCT n°personne FROM Personne A WHERE NOT EXISTS (SELECT DISTINCT n°personne FROM Prêt B WHERE (A.n°personne= B.n°personne)) AND n°abonnement IS NOT NULL));

CREATE TRIGGER Inclusion_Effectuer_Souscrire BEFORE INSERT ON Pret ON EACH ROW WHEN new.n°personne IS NOT NULL DECLARE nb_abonnement number; BEGIN SELECT COUNT(*) INTO nb_abonnement FROM Personne WHERE n°personne = :new.n°personne; IF nb_abonnement = 0 THEN raise_application_error (-20006, 'Un abonnement n'a pas été souscrit' )); END IF; END;

MLD : passage du modèle Entité-Relation au modèle relationnel enrichi

• prise en compte de l'historisation : règles de transformation logique

exemple : historisation de relation PERSONNE LOGEMENT n°personne adresse LOUER (H) nom surface adresse 0,n
exemple : historisation de relation
PERSONNE
LOGEMENT
n°personne
adresse
LOUER (H)
nom
surface
adresse
0,n
loyer_mensuel
0,n
nb_pièces

Pour toute modification de valeur de l'une des propriétés d'une relation, on historise l'ensemble des valeurs des propriétés de la relation ainsi que son identification :

PERSONNE

 

LOUER

 

LOGEMENT

n°personne

n°personne adresse adresse

adresse

n°personne adresse adresse

adresse

nom

 

n°personne

   

surface

adresse

loyer_mensuel

nb_pièces

 
   
 
 

H_LOUER

 

adresse

 

n°personne

DATE_HISTO

loyer_mensuel