Vous êtes sur la page 1sur 199

Analyse  et  Conception  des  

Systèmes  d’Information

Soror  SAHRI
soror.sahri@parisdescarets.fr

1
Informations  pratiques
l  Cours  
l  Soror  Sahri
l  TDs
l  Soror  Sahri
l  Nicoleta  Rogovschi
l  Volume  horaire
l  1h30  cours  x  12  +  2h  TDs  x  12
l  Sources  du  cours
l  Ingénierie  des  SI  :  Merise,  D.  Nanci  &  B.  Espinasse
2
Objectifs
Analyse  et  Conception  des  Systèmes  d’Information  (ACSI)
     Analyse  
Processus  d’examen  de  l’existant
       Conception  
Processus  de  définition  de  l’application  future
Systèmes  d’Information
Ensemble  de  moyens  et  de  méthodes  se  rapportant  au  traitement    
de  l’information  d’une  organisation
Objectifs
l  Comprendre  les  enjeux  des  systèmes  d’information
l  Connaître  les  techniques  de  modélisation  des  SI
l  Apprendre  des  méthodes  de  conception  des    SI 3

§  Approfondir    la  méthode  MERISE


Objectifs
l  on  s'ʹintéresse  en  général  à  un  domaine  d'ʹactivité  de  
l'ʹentreprise  :
§  ventes,  
§  production,  
§  logistique,  
§  finances,  
§  RH  …
l  on  prend  en  compte  les  besoins  des  utilisateurs,
l  on  définit  le  problème  à  résoudre  :  fonctionnalités  à  offrir  
et  qualités  a[endues.
Objectifs
     on  définit  une  solution  informatique  :
-­‐‑  structuration  des  données,
-­‐‑  organisation  des  traitements,
-­‐‑  définition  des  postes  de  travail,
-­‐‑  choix  techniques  :  matériels,  langages  de  
programmation,  logiciels  de  gestion  de  
données  (SGBD)…

Démarche  «  très  théorique  »

analyse  du  problème                conception  de  la  solution


                                                                     réalisation  du  système
Difficulté  de  l’ACSI
Mythes
l  L’utilisateur  connaît  son  métier  et  exprime  ses  besoins.
l  L’informaticien  professionnel  analyse  les  besoins  puis  développe  une  
application.
Utilisateur  pro  +  informaticien  pro  =
 application  qui  répond  aux  besoins…
Réalités
l  Besoins  définis  par  plusieurs  personnes  (écarts)
l  pas  forcément  clairs,  évolutifs…
l  L’informaticien  est  un  pro  de  l’informatique,  pas  du  métier  pour  lequel  il  
conçoit.  
l  Il  peut  se  «  tromper  »  dans  ce  qu’il  comprend

Besoins  pas  toujours  bien  définis  +  informaticien  qui  ne  connaît  pas  le  
métier  =  application  forcément  «  imparfaite  »  …
Pas  une  démarche  linéaire    
l  Pas  une  démarche  linéaire  :  
         «  analyse  →  conception  →  réalisation  »
l  Un  recueil  des  besoins  exhaustif  dès  le  départ  n’est  pas  réaliste      
   dans  les  cas  complexes.

Analyser Concevoir Réaliser

ACSI
….  mais  une  démarche  «  itérative  »              
 


Processus  de  développement  itératif  et  travail  d’analyse  itératif  sur  le  terrain  :

4-
1- Poser des Soumettre son
questions Travail
Quoi? Pourquoi? Comprendre
Comment? Qui? le métier
… Accepter les
changements

2 - Analyser les
réponses 3 – Modéliser
Cohérentes? But? Lecteurs?
Complètes? Notation?
Suffisantes? …
Quelques  concepts

Système  d’information

Entreprise Utilisateurs

Domaine  d’étude

Besoins Méthode Analyse

Système  informatique

9
Quelques  concepts

Entreprise Entreprise

Système  informatique
Domaine  d’étude
Analyse    
Besoins
Méthode Système  
d’information

Utilisateurs Utilisateurs

10
Système  d’Information
Définitions
l  Un  SI  est  l’ensemble  des  moyens  techniques  et  humains  et  des  méthodes  qui  
perme[ent  le  traitement  des  informations  au  sein  d’une  organisation  et  dans  
ses  rapports  à  son  environnement.  
l  Un  SI  est  un  ensemble  d’éléments,  matériels  ou  pas,  en  interaction  entre  eux,  
transformant  des  éléments    d’entrée  en  éléments  de  sortie.

Eléments  en  entrée Système Eléments  en  sortie

Exemple
l  Une  entreprise  qui  commercialise  des  produits
l  En  entrée:  des  produits  achetés,  des  commandes,  les  paiements  des  clients  
l  En  sortie:  des  produits  vendus,  des  factures,  les  paiements  des  fournisseurs
11
Système  d’Information
l  Contexte  :  Une  entreprise  est  décomposée  de  trois  sous-­‐‑systèmes:
l  Un  système  de  pilotage  (ou  de  décision)  qui  définit  les  objectifs,  
contrôle  et  prend  les  décisions
l  États  statistiques,  historiques,  décisions,  plan…

l  Un  système  opératoire  qui  réalise  les  tâches


l  Gestion  de  production  et  des  stocks,  facturation,  compatibilité…

l  Un  système  d’information  qui  sélectionne  les  informations  pertinentes  


dans  le  système  opératoire,  les  traite  pour  fournir  des    informations  
synthétiques  au  système  de  décision  qui  peut  alors  renvoyer  des  
directives  vers  son  système  opératoire.


12
Système  d’Information
Entreprise/Organisation

Système  de  Décision  


Environnement

réfléchi,  décide,  contrôle


Système Flux  de  décisions
de  pilotage
Demande  et    
restitution     Information  
d’information de  décision

Flux  d’informations
Système  d’Information   SI
mémorise,  traite,  diffuse

Demande  et    
collecte   Information  
d’information de  représentation
     Flux
Système   physiques
 opérant
Flux  entrant Système  Opérant   Flux  sortant
transforme,  produit
13
Système  d’information
l  Une  partie  du  SI  peut  être  informatisée
l  Ce  système  informatisé  prend  appui  sur  un  système  
informatique  composé  de  matériel  et  de  logiciel  de  base  


Système  d’information

Système  informatisé

Système  informatique

14
Système  d’information
Caractérisation  «  informatique  »  d’un  SI

S.I.

infrastructure
(distribuée)
base(s) de applications
données
règles d’usage, de validation, de sécurité, de suivi et
d’évolution…

Algorithmique Programmation

Bases de données Interfaces utilisateurs

Réseaux et systèmes Systèmes distribués


Système  d’information

Un  système  d’information                Un  système  informatique

Met  en  œuvre
Un  Système  
L’organisation
d’Information
Qui  sont  mis  à    
la  disposition  de  

Des  ressources  
informatiques
Des  ressources  
humaines
D’autres  
ressources:  tél...

16
Système  d’information
l  Le  fonctionnement  d’un  SI  suppose  :
l  Le  stockage  des  informations  
l  Données
l  La  définition  des  procédures  agissant  sur  les  informations  stockées  
l  Traitements
Aspects  d’un  SI
l  Statique  :  Mémoire  de  l’organisation
l  Enregistrement  des  faits  :  base  d’information
l  Enregistrement  des  structures  de  données,  etc.
l  Dynamique  :
l  Mise  à  jour  des  données
l  Changement  des  règles,  structures  et  contraintes  de  l’univers  extérieur

17
Système  d’Information  :  Problématique

l  Champ  d’application  très  vaste  dû  à  la  variété  des  systèmes  :
l  Bureautique,  informatique  de  gestion,  informatique  scientifique,  imagerie,  
etc.
l  Compléxité  intrinsèque  des  S.I.  :
l  Utilisation  de  nombreuses  techniques  pour  la  modélisation  des  systèmes  
(théorie  des  BD,  les  LP,  les  automates,  etc)

Besoin  de  méthodes  pour  la  construction  d’un  SI


18
Système  d’Information  :  Problématique
l  Vue  «  réaliste  »  d’un  SI  :  complexité
l  Grand  nombre  de  métiers,  d’échanges,  de  données,  d’applications,  de  serveurs…
Système  d’Information  :  Méthode

l  Une  méthode  définit  un  processus  d’informatisation,  possède  


un  champ  d’étude  et  décrit  une  démarche  à  suivre
l  Une  méthode  
l  S’appuie  sur  des  concepts    théoriques  
l  Aide  à  la  mise  en  place  d’un  langage  commun  au  sein  de  
l’organisation
l  Doit  perme[re  une  meilleure  communication    entre  tous  les  
partenaires


20
Système  d’Information  :  Méthode

Composants  d’une  méthode  de  construction  d’un  S.I.

Démarche Modèles
Méthode  de  
construction  
d’un    S.I.

Outils  et  techniques langages

21
Système  d’Information  :  Méthode

Composants  d’une  méthode


l  Démarche
l  Processus  à  suivre  pour  effectuer  les  travaux  demandés.  Elle  est  
découpée  en  étapes.
l  Modèles
l  Ensemble  de  concepts  et  de  règles  destinés  à  expliquer  et  à  
construire  la  représentation  de  phénomènes  organisationnels
l  Langages
l  Destinés  à  spécifier  et  à  simplifier  la  communication
l  Outils  et  techniques  
l  Aide  à  la  mise  en  œuvre  des  modèles,  des  langages  et  de  la  
démarche. 22
La  notion  de  modèle
l  Au  centre  de  la  démarche  d’ACSI
l  Modèle  =  représentation  simplifiée  d’une  réalité  sur  
laquelle  on  veut  être  renseigné.
l  S’exprime  avec  un  ensemble  de  concepts  dotés  de  règles  
d’utilisation  et  de  notations  (souvent  graphiques).
l  En  ACSI  les  modèles  servent  à  :
l  communiquer  :  vérifier  que  l’analyste  a  bien  compris  les  

utilisateurs  grâce  à  des  modèles  du  problème  (modèles  


d’analyse)
l  préparer  la  réalisation  :  grâce  à  des  modèles  de  la  solution  

(modèles  de  conception).


Un  modèle…

La  réalité  ?

But  ?
Lecteurs  ?
Notation  ?
Autant   de   modèles   que   de   buts,   de   lecteurs,   de  
notations  …  de  modélisateurs.

Modèle pour touriste

même
réalité

Modèle pour technicien


Bonnes  pratiques
l  Décrire  d’abord  les  grandes  lignes  de  ce  qu’on  a  
compris.
l  Faire  valider  ce  qu’on  pense  avoir  compris  
l  modéliser  =  apprendre  en  se  posant  des  questions
l  Détailler  ensuite  les  modèles.
l  Faire  valider  de  manière  itérative.

26
Qualités  pour  devenir  un  bon  analyste-­‐‑concepteur  

l  Décrire  d’abord  les  grandes  lignes  de  ce  qu’on  a  compris.
l  qualités  relationnelles  
l  écoute,  travail  en  équipe

l  ténacité  et  rigueur  


l  synthétiser  ce  qui  est  important,  ne  pas  se  noyer  dans  les  
détails,  fuir  «  l’à-­‐‑peu-­‐‑près  »,  accepter  les  remises  en  
cause…
l  créativité  
l  pas  de  rece[es  toutes  faites

Métiers  difficiles  mais  plus  valorisants  et  mieux  payés  :
l  analyste,  chef  de  projet,  architecte  SI,  consultant  ...
Quelques  méthodes

l  MERISE
l  Méthode  d’Etude  et  de  Réalisation  Informatique    pour    les  Systèmes  d’Entreprises
l  AXIAL
l  Analyse  et  Conception  des  Systèmes  d’Information  Assistés  par  Logiciels
l  SSADM
l  Structured  Systems  and  Design  Method
l  SADT
l  Structured  Analysis  and  Design  Techniques
l  OOA
l  Object-­‐‑Oriented  Analysis
l  OMT
l  Object  Modeling  Technique
28
MERISE

29
MERISE  :  Historique

l  Approche  ancienne  :  


l  Merise  date  des  années  1978  et  1979.  Elle  résulte  d’une  
demande  du  ministère  de  l’Industrie  (en  1977)  qui  
souhaitait  obtenir  une  méthode  de  conception  de  système
d’information.  
l  Origine  :
l  Ce  sont  le  Centre  Techniques  de  l’Equipement  et  le  Centre  
d’Etudes  techniques  de  l’Equipement  qui  sont  à  l’origine  de  
ce[e  méthode.  

30
MERISE  :  Définition

MERISE  :
l  Méthode  d’Etude  et  de  Réalisation  Informatique    pour    
les  Systèmes  d’Entreprises
l  Méthode  Eprouvée  pour  Retarder  Indéfiniment  la  Sortie  
des  Etudes
l  MEthode  pour  Rassembler  les  Idées  Sans  Effort  

31
MERISE  :  Définition

l  Merise  est  une  méthode  d’analyse  et  de  conception


l  Analyse  :  Etude  du  problème
l  Etudier  le  système  existant
l  Comprendre  les  besoins  :  diagnostiquer
l  En  déduire  le  niveau  conceptuel  :  donner  une  vision  fonctionnelle    
du  système
l  Conception  :  Etude  de  la  solution
l  Proposer  de  nouvelles  solutions  organisationnelles

32
MERISE  :  La  démarche
l  La  démarche  de  construite  d’un  SI  doit  être  conduite  suivant  trois  axes  (les  
cycles)  :  
l  Cycle  de  vie  :  échelle  de  temps
l  On  sait  dans  quel  ordre  on  fait  les  choses
l  Cycle  d’abstraction  :  à  3  niveaux  
l  On  sait  dans  quelle  logique  on  doit  travailler
l  Cycle  de  décision  :  choix  organisationnels  et  techniques
l  On  sait  ce  qu’on  doit  décider  à  chaque  étape

33
MERISE  :  La  démarche
l  Cycle  de  vie
l  Démarche  d’informatisation  :  succession  de  
phases  contrôlables  par  l’organisation  
(planning,  échéances,  moyens  humains…).

l  Se  situe  sur  une  échelle  de  temps  qui  va  du  
point  de  départ  à  l’exploitation  du  système,  en  
passant  par  sa  naissance,  sa  maturité  et  sa  
maintenance
l  Cycle  de  décision
l  Représente  l’ensemble  des  choix  à  faire  durant  
le  déroulement  du  cycle  de  vie.
l  Ces  décisions  fixent  :
l  Les  objectifs  organisationnels  et  techniques,  les  
priorités  de  développement,  les  ressources  allouées  
au  projet,  la  mise  en  place  et  le  suivi  de  plannings  
d’avancement.
l  Les  décisions  sont  prises  hiérarchiquement
34
MERISE  :  La  démarche
l  Cycle  d’abstraction
l  Niveau  conceptuel  :  
l  Quoi  ?
l  Niveau  Organisationnel  :  
l  Qui  ?  Quand  ?  Où  ?
l  Niveau    Logique  :  
l  Avec  quoi  ?  Quels  outils  ?
l  Niveau  Physique
l  Comment  ?

35
MERISE  :  Cycle  d’abstraction
Exemple
l  Niveau  conceptuel  :  
l  Un  client  effectue  une  demande  de  service  à  la  compagnie  pour  assurer    
son  véhicule,  la  compagnie  lui  propose  un  devis
l  Niveau  Organisationnel/Logique  :  
l  Un  client  effectue  une  demande  de  service  à  l’agence  de  son  choix,  par  
courrier,  pour  assurer  un  véhicule.  Un  agent  de  service  concerné,  si  le    
client  est  solvable,  prend  contact  par  téléphone  pour  une  visite  à  domicile  
afin  d’examiner  plus  précisément  ses  besoins  et  établir  un  devis.
l  Niveau  Physique
l  Le  fichier  central  inter  assurances  est  accessible  par  Internet.    
Les  agences  sont  connectées  au  siège  de  la  compagnie.  Chaque  agence  
dispose  d’un  PC  et  peut  traiter  ses  données  en  local  grâce  à  ACCESS
36
Le  niveau  conceptuel

l  Décrire  le  QUOI  indépendamment  de  toute  contrainte  


d’organisation  ou  technique.
l  Définir  les  activités,  les  données,  …  indépendamment  des  
aspects  organisationnels  et  techniques.
Exemples
l  Faire  la  pré-­‐‑facturation  ou  de  la  post-­‐‑facturation
l  Une  commande  client  pourra  être  livrée  en  plusieurs  fois,    
chaque  livraison  donnant  lieu  à  une  facture.
l  Les  invariants  du  point  de  vue  des  données  :  contrats,  clients,  etc.
l  Les  invariants  du  point  de  vue  des  traitements  :    signer  un  
contrat,  éme[re  une  facture,  etc. 37
Le  niveau  organisationnel/logique

l  Exprimer  les  choix  organisationnels  de  ressources  


humaines  et  matérielles
l  Définir  indépendamment  des  moyens  de  traitement  et  
de  stockage  de  données  actuels  et  futurs
l  La  répartition  géographique  et  fonctionnelle  des  sites  de  
traitements
l  Le  mode  de  fonctionnement  :  temps  réel  /  temps  différé
l  La  répartition  du  travail  homme/machine
l  Les  postes  de  travail
l  Etc.
38
Le  niveau  organisationnel/logique

l  Le  schéma  logique  est  la  traduction  du  schéma  conceptuel  selon  
un  modèle  existant  (hiérarchique-­‐‑réseau-­‐‑relationnel).
l  Ces  schémas  sont  totalement  indépendants  de  la  technologie  
utilisée.
Exemples
l  La  facturation  sera  décentralisée  dans  les  agences  
l  Réaliser  telle  partie  par  la  machine,  laisser  l’autre  partie  pour  un  traitement
manuel.
l  Créer  un  type  de  poste  de  travail  (  agent  de  saisie,  etc)

Exemples  d’éléments  organisationnels


l  Un  document  (rapport  d’activité,  tableau  de  bord,  etc)
l  La  sécurité
l  La  date 39
Le  niveau  physique

l  Le  COMMENT  FAIRE.  Le  logiciel  de  développement  


ainsi  que  le  type  du  matériel  qui  sera  utilisé  sont  choisis
l  Répond  aux  besoins  des  utilisateurs  sur  les  aspects  
logiciels  et  matériels.
l  Définir  complètement  :  
l  Les  fichiers,  les  programmes
l  L’implantation  physique  des  données  et  des  traitements
l  Les  ressources  à  utiliser
l  Les  modalités  de  fonctionnement

40
L’approche  Données/Traitements

l  Pour  étudier  et  développer  l’informatique  d’une    


organisation,  il  est  nécessaire  de  connaître  :
l  Ses  échanges  internes  et  externes
l  Comment  elle  réagit  à  une  sollicitation  externe
l  Quelle  est  la  structure  des  informations  qu’elle  utilise
l  Merise  décrit  ce[e  connaissance  sous  la  forme  de  trois  
découpages  :
l  Communication
l  Traitement
l  Données
41
L’approche  Données/Traitements

l  Communication  :
l  Etude  des  échanges  entre  les  composants  de  l’organisation
l  Traitements  :
l  Etude  des  évènements  
l  Indépendance  entre  les  domaines
l  Données
l  Etude  du  vocabulaire  de  l’organisation
l  Intégration  des  domaines  :  vue  globale  

42
Courbe  de  soleil

43
Les  modèles  MERISE

Données Traitements
Niveau  Conceptuel
Quoi
MCD MCT
Qui   Niveau  Organisationnel/Logique
Quand  
Où MLD MOT
Niveau  Opérationnel/Physique
Comment
MPD MPT

44
Modélisation  Conceptuelle  des  données

l  Modèle  E/A


l  Concepts  et  règles  de  modélisation
l  Démarche  de  construction  d’un  modèle  E/A

45
Modèle  Entité/Association
l  Il  s’agit  d’un  modèle  conceptuel  de  MERISE  et  de  AXIAL
l  Il  permet  d’exprimer  l’ensemble  des  informations  que  l’on  veut  
prendre  en  compte  dans  un  système  d’information
l  La  solution  est  basée  sur  un  formalisme  de  représentations
l  Guider  le  raisonnement  du  concepteur
l  Obliger  à  respecter  des  normes
l  Utiliser  un  langage  commun

l  Le  résultat  est  un  schéma  conceptuel  de  données  clair,  cohérent,  
complet  et  normalisé
l  Ce  résultat  est  indépendant  des  considérations  techniques  ou  
organisationnelles 46
Modèle  Entité/Association

Une  bibliothèque
Organisation

Les  livres  avec  leur  référence,  leur  titre  et  leur  auteur
Les  abonnés  avec  leur  nom  et  leur  adresse
Les  emprunts  de  livre  par  les  abonnées Modèle  Conceptuel  de  Données

L564 Les  misérables V.  Hugo


Base  de  
R876 Germinal E.  Zola données

47
Concepts  et  règles  de  modélisation
l  Les  principaux  concepts  du  modèle  E/A  sont  :  
l  Entité
l  Association
l  Propriétés
l  Contraintes  d’intégrité
l  Le  modèle  E/A  identifie,  décrit  et  modélise  les  entités  et  les  
associations  à  l’aide  d’une  représentation  graphique
Entités

Abonné
Livre

Emprunt
nom 0,n 0,n référence
adresse Titre
1er  auteur
48
Propriétés
Association
Concepts  et  règles  de  modélisation
Propriété
l  Une  propriété  est  une  donnée  élémentaire  qu’on  perçoit  sur  une  entité  et  sur  
une  association
l  Exemple
l  Les  abonnées  ont  les  propriétés  suivantes  :    nom,  adresse,  date  de  naissance,  etc.

l  Chaque  propriété  ne  peut  avoir  une  occurrence  qu’une  seule  fois.  
l  Exemple
l  Nom  d’abonné  :  Dupond,  Durand,  Martin.
l  Nom  d’auteur  :  Hugo,  Zola.

l  Une  propriété  se  décrit  par  tout  ou  partie  des  éléments  suivants  :
l  Définition  :  ce  qu’elle  représente  et  son  intérêt  dans  le  contexte
l  Domaine  de  valeur  :  quantité,  nombre  ,  date,  etc.
l  Longueur  :  nombre  de  caractères  
l  Caractéristiques  complémentaires  :  
l  Obligatoires  ou  facultative  ;  naturelle  ou  calculée;  élémentaire,  décomposable  ;  normée  :  en  interne  ou  
49

par  des  organismes  officiels  (n°  INSEE)


Concepts  et  règles  de  modélisation
Entité
l  Une  entité  est  un  élément  ou  un  objet  concret  ou  abstrait  du  monde  réel  qui  
existe.
Bibliothèque  réelle Modèle  conceptuelle  :  Entité

Dupond Abonné

Martin
Durand

l  Une  occurrence  d’une  entité  est    représentée  par  l’ensemble  de  valeurs  de    
ce[e  entité. Dupond

Abonné
Martin

Durand


50
Concepts  et  règles  de  modélisation
l  Formellement,  une  entité  est  définie  par  son  nom  et  l’ensemble  
des  propriétés  qui  la  définissent.
l  Une  entité  doit  disposer  d’une  propriété  particulière  qui  jouera    
le  rôle  d’identifiant  de  l’entité.
l  Un  identifiant  définit  d’une  manière  unique  les  occurrences  
d’une  entité
 Exemple
l  N°  INSEE  pour  l’entité  ABONNE
l  À  chaque  numéro  INSEE,  correspond  une  seule  valeur  de  l’ensemble  :    
nom,  prénom,  âge,  etc.

51
Concepts  et  règles  de  modélisation
Règles  d’identification
l  Plusieurs  types  d’identifiant
l  Identifiant  simple  naturel  (nom  d’un  pays)  ou  artificiel  (n°  client)
l  Identifiant  composé  (n°  sécurité  sociale)
l  Identifiant  relatif  comprenant  des  propriétés  n’appartenant  pas  à  l’entité  à  
identifier
l  Un  identifiant  doit  être  :  
l   univalué  :  une  occurrence  entité  correspond  à  une  valeur  de  l’identifiant
l  Discriminant  :  une  valeur  de  l’identifiant  correspond  à  une  occurrence  de  
l’entité
l  Stable
l  Minimal  (pour  les  identifiants  composés)
52
Concepts  et  règles  de  modélisation
Entité  :  Règles  de  vérification
l  Une  entité  a  un  seul  identifiant
l  Une  entité  a  au  moins  une  propriété
l  Une  information  ne  peut  être  que  dans  une  seule  entité.    
Pour  être  dans  ce[e  entité,  elle  doit  dépendre  de  l’identifiant.
l  Une  entité  participe  a  au  moins  une  association

53
Concepts  et  règles  de  modélisation
Association
l  Une  association  modélise  un  ensemble  de  liens  logiques  de  même  
nature  entre  deux  ou  plusieurs  occurrences  d’entités,  ayant  intérêt  
significatif  pour  le  système  à  représenter.
l  Une  association  n’existe  qu’à  travers  les  entités  qu’elle  relie.
l  Chaque  occurrence  d’une  association  doit  pouvoir  être  distinguée  des  
autres  occurrences  de  la  même  association.
l  On  désigne  en  général  une  association  par  le  nom  d’un  verbe.
l  Verbe  à  l’infinitif  :  appartenir,  concerner
l  La  forme  passive  et  active  permet  d’orienter  la  lecture    de  l’association.

54
Concepts  et  règles  de  modélisation
Exemple
l   L’association  Emprunt  entre  les  entité  Abonné  et  Livre.R876

Livre
Abonné
Emprunt
nom référence
adresse Titre
1er  auteur
l  Occurrences  :

Livre
Abonné
Emprunt

Dupont L564
Paris Les  Misérables
V.  Hugo Livre
Abonné
Emprunt

Martin R876
Lyon Germinal
E.Zola

55
Concepts  et  règles  de  modélisation
l Une  association  peut  avoir  des  propriétés.
Exemple

Livre
Abonné
Emprunt
nom référence
adresse Date  emprunt
Titre
1er  auteur

Une  association  a  pour  identifiant  la  concaténation  des  identifiants  des  


l 
entités  qu’elle  relie.
Exemple
l  L’association  Emprunt  a  pour  identifiant  nom  et  référence.

56
Concepts  et  règles  de  modélisation
l  On  distingue  différents  types  d’association  :
l  Les  associations  binaires  :  qui  associent  2  entités
l  Exemple  :  ENSEIGNANT                        Noter                        COURS
l  Les  associations  n-­‐‑aires  :    qui  associent  plus  de  2  entités
l  Exemple  :  ENSEIGNANT                        Noter                        COURS

                       

                         MATIERE

l  Les  associations  réflexives:  qui  associent  les  occurrences  de  la  même  entité
l  Exemple  :  CLIENT                        Parrainer

57
Concepts  et  règles  de  modélisation
Les  cardinalités
l  Une  cardinalité  caractérise  la  participation  d’une  entité  à  une  
association.
l  Elle  représente  le  nombre  d’occurrences  d’une  association    pour  chaque  
occurrence  d’entité  qu’elle  relie.
l  On  distingue  :
l  La  cardinalité  minimale  :  donne  le  nombre    minimum  de  participations  de  
chacune  des  occurrences  d’une  entité  à  une  association
l  La  cardinalité  minimale  est  égale  à  0  ou  1  :
§  0  s’il  existe  une  occurrence  de  l’entité  ne  participant  pas  à  l’association
§  1  si  toute  occurrence  de  l’entité  participe  à  l’association
l  La  cardinalité  maximale  :  donne  le  nombre  maximum  de  chacune  des  occurrences  
d’une  entité  à  une  association
l  La  cardinalité  maximale  est  égale  à  1  ou  tout  nombre  fixé  (2,3…)  ou  à  n.
58
Concepts  et  règles  de  modélisation
Exemple
l  Un  cours  est  enseigné  par  au  moins  un  enseignant  (1,…)  ou  par  plusieurs  
enseignants  (..,n).


Cours
Enseignant
Enseigner
nom 0,n 1,n Numéro  cours
Prénom   Titre  cours  

Age


l  Un  enseignant  peut  n’enseigner  aucun  cours  (0,..)    ou  plusieurs  cours  (..,n).

59
Concepts  et  règles  de  modélisation
Les  contraintes  d’intégrité
l  Une  contrainte  d’intégrité  (CI)  est  définie  comme  une  assertion  qui  doit
être  vérifiée  par  des  données  à  des  instants  déterminés.
l  Une  CI  permet  de  spécifier  des  propriétés  sémantiques  du  réel  perçu    
qui  ne  sont  pas  exprimables  avec  le  modèle  E/A.
l  On  distingue  :
l   les  contraintes  sur  les  propriétés
l  Les  contraintes  sur  les  cardinalités

60
Concepts  et  règles  de  modélisation
Contraintes  sur  les  propriétés
l  Les  contraintes  liées  aux  propriétés  correspondent  à  des    
contrôles  à  assurer  pour  vérifier  l’intégrité  des  données  et  la  
cohérence  par  rapport  au  système  à  représenter
l  Les  contraintes  de  valeur  
l  C’est  l’ensemble  des  valeurs    que  peut  prendre  une  propriété  :
§  Domaine  de  valeurs
§  Contraintes  statiques  :  en  fonction  de  la  prise  par  d’autres  propriétés
§  Contraintes  dynamiques  :  lors  d’un  changement  d’état  du  SI
l  Les  dépendances  fonctionnelles

61
Concepts  et  règles  de  modélisation
Contraintes  sur  les  propriétés  (suite)
Exemples
l  Les  contraintes  de  valeur
l  Domaine  de  valeurs
l  les  valeurs  possibles  de  l’état  civil  sont  :  célibataire,  marié,  divorcé,  séparé,  veuf
l  Contraintes  statiques  
l  date  d’ouverture  de  compte  inférieure  ou  égale  à  la  date  du  premier  mouvement
l  Contraintes  dynamiques  
l  la  valeur  de  l’état  civil  peut  devenir  divorcé  si  la  valeur  précédente  était  marié  ou  séparé

l  Les  dépendances  fonctionnelles


l  À    numéro  tiers  correspond  un  seul  nom  du  tiers
l  À  numéro  de  compte  correspond  une  seule  valeur  type  de  compte

62
Concepts  et  règles  de  modélisation
Contraintes  d’intégrité  fonctionnelle  CIF
Une  CIF  entre  deux  entités  exprime  le  fait  que  l’identifiant  de  la  
l 
première  détermine  une  occurrence  de  la  deuxième.
Exemple
l  Un  véhicule  appartient  à  une  seule  personne.  
l  Si  on  connait  le  matricule  du  véhicule,  on  peut    savoir  toutes  les  informations  nécessaires  sur  
son  propriétaire
l  Une  commande  est  passée  par  un  et  un  seul  client
l  Si  on  connait  le  numéro  de  la  commande,  on  peut  déterminer  les  informations  sur  le  client  qui  
l’a  passée

63
Les  règles  de  validation  d’un  modèle  E/A
Règle  1
Toutes  les  propriétés  doivent  être  élémentaires  (non  décomposables)
Règle  2
Chaque  objet  doit  posséder  un  identifiant  et  un  seul.  
Règle  3
Les  propriétés  d’un  objet  autres  qu’un  identifiant  doivent  être  en  
dépendance  fonctionnelle  monovaluée  de  cet  identifiant
Exemple  NumMatricule    détermine  NomSalarié  et  Num  Matricule  multidétermine  Diplôme


SALARIE
SALARIE

DIPLOME
    Obtenir  
Num  matricule   Num  matricule   0,n 0,n Libellé  Diplôme
Niveau  
Nom  Salarié   Nom  Salarié  
 
……   ……  
64
Diplôme
Les  règles  de  validation  d’un  modèle  E/A
Règle  4  
Une  propriété  ne  peut  qualifier  qu’une  seule  entité  ou  qu’une  seule  
association
Exemple
La  propriété    Adresse  Client  ne  peut  être  présente  à  la  fois  dans  l’entité  CLIENT  et  
l’entité  FACTURE



CLIENT FACTURE
 
  Correspond
Num  Facture
Num  Client   0,n 1,1 Date  Facture  

Nom  Client   …..  
……   Adresse  Client  
Adresse  Client

Redondance
65
Les  règles  de  validation  d’un  modèle  E/A
Règle  4  (suite)
Une  propriété  ne  peut  s’appeler  Adresse  dans  CLIENT  et  FACTURE.  Si  c’est  
le  cas,  il  faut  les  renommer  Adresse  Client  et  Adresse  Facture.
Exemple



CLIENT FACTURE
 
CLIENT FACTURE
 
  Num  Facture   Num  Facture
Num  Client   Date  Facture   Num  Client   Date  Facture  
Nom  Client   …..   Nom  Client   …..  
……   Adresse     ……   AdresseFacture  
Adresse Adresse  Client

66
Les  règles  de  validation  d’un  modèle  E/A
Règle  5
La  dépendance  fonctionnelle  transitive  doit  être  écartée
Exemple


CLIENT
CATEGORIE
 
CLIENT
Num  Client     Appartient  
Num  Client   1,1 0,n Code  Catégorie
Nom  Client  
……  
Nom  Client   Intitulé  
……   Taux  Remise
Catégorie  Client  

Taux  Remise

Num  Client  détermine  Catégorie  Client


Catégorie  client  détermine  le  taux  de  remise
Num  Client  détermine  Taux  de  remise

67
Les  règles  de  validation  d’un  modèle  E/A
Règle  6
Pour  chaque  occurrence  d’une  association,  il  doit  exister  une  et  une  seule  
occurrence  de  chacune  des  deux  entités  liées
Exemple  :  Un  article  est  fourni  et  stocké  dans  un  emplacement    
Dans  le  cas  où  certains  articles  proposés  par  les  fournisseurs  ne  seraient  pas  en  stock,  la  règle  6  
n’est  pas  respectée.  La  règle  de  gestion  est  donc  composée  en  :  un  article  est  fourni  par  un  
fournisseur  ET  un  article  est  stocké  dans  un  emplacement


ARTICLE
ARTICLE
    0,n Fournir  

Num  Article   Num  Article  
Désignation   Désignation  



 

 
0,n
0,n FOURNISSEUR 0,n FOURNISSEUR

EMPLACEMENT
EMPLACEMENT
Adresse   Num  Fournisseur Adresse   Num  Fournisseur
0,n Stocker  
0,n Nom  Fournisseur   0,n Stocker  
Nom  Fournisseur  
Surface   Quantité Surface   Quantité
……   …..   ……   …..  
Mode    Stockage   Adr  Fournisseur Mode    Stockage   Adr  Fournisseur
68
Les  règles  de  validation  d’un  modèle  E/A
Règle  7
Les  propriétés  d’une  association  doivent  dépendre  de  la  totalité  de  
l’identifiant  de  l’association.
Exemple  


EMPLOYE
EMPLOYE

   
Num  Employe  
Num  Employe  
Nom  
Nom  
   
1,n
BATIMENT
SERVICE
1,n
BATIMENT SERVICE

1,n
Nom  Service  
         Affecter   1,n Nom  Bâtiment  
Nom  Service          Affecter  
1,n Nom  Bâtiment  
Date  début   Budget   1,n      Date  début  

Budget        Date  fin
Date  fin  

Prime  pédagogique

1,n                  Prime  
1,n
 

Prime  pédagogique

69

Démarche  de  construction  d’un  modèle  E/A
But  :  obtenir  une  représentation  du  système  à  développer

l  Deux  approches  pour  la  construction  d’un  modèle  E/A
l  L’approche  ascendante
l  L’approche  descendante

70
Approche  ascendante

l  L’approche  ascendante  se  déroule  en  plusieurs  étapes  :


l  Recueillir  des  informations  utiles
Analyse  des  besoins
l  Expliciter  clairement  les  règles  de  gestion
l  Etablir  la  liste  des  propriétés
l  Construire  le  dictionnaire  de  données
l  Construire  le  graphe  des  dépendances  fonctionnelles Conception  du  MCD
l  Etablir  le  modèle  conceptuel  de  données

71
Approche  ascendante
Exemple  :  Cas  de  gestion  des  commandes  et  des  factures
Recueillir  des  informations  utiles
l  Rassembler  des  exemplaires  des  différents  documents  et  fichiers  en  usage
Expliciter  des  règles  de  gestion  
l  Règle  1:  Le  client  peut  passer  une  ou  plusieurs  commandes  ou  aucune  commande
l  Règle  2  :  Une  commande  peut  concerner  un  ou  plusieurs  produits
l  Règle  3  :  Une  commande  est  passée  par  un  représentant  qui  n’est  pas  toujours  le  même  pour  un  client  
donné
Identifier  les  propriétés
l  Numéro  bon
l  Date  de  la  commande
l  Nom  client
l  Numéro  client
l  Adresse  client
l  Nom  du  représentant
l  Numéro  représentant
l  Référence  du  produit
l  Quantité  achetée
l  Désignation  du  produit
l  Prix  unitaire 72
l  Montant  d’une  ligne
l  Total  commande
Approche  ascendante
Construction  du  dictionnaire  de  données
l  Un  dictionnaire  de  données  est  une  structure  qui  rassemble  l’ensemble  des  
données  relatif  à  un  sujet
l  Le  but  d’un  dictionnaire  de  données  est  de  recenser,  structurer  et  donner  une  
première  analyse    des  informations  du  sujet
l  L’origine  des  informations  provient  de  :
l  Description  de  l’activité  
l  Description  des  objectifs
l  Analyse  des  documents  utilisés
l  Les  interviews
l  Les  fichiers  existants

73
Approche  ascendante
Construction  du  dictionnaire  de  données
l  Exemple

74
Approche  ascendante
Construction  du  graphe  de  dépendances  fonctionnelles
l  Dépendance  fonctionnelle
l  Soient  a  et  b  deux  propriétés  quelconques.  b  dépend  de  a  (on  note  a→b)  si  chaque  
valeur  de  a  détermine  de  manière  unique  la  valeur  de  b
Exemple  
l  Numéro  Client  → Nom  Client
l  Numéro  Client →Adresse
l  Numéro  Client  → Numéro  Produit

l  Graphe  de  dépendances  fonctionnelles


l  Un  graphe  qui  permet  de  visualiser  les  dépendances  fonctionnelles  est  appelé  
graphe  de  dépendances  fonctionnelles  (GDF).

75
Approche  ascendante
 Construction  du  graphe  de  dépendances  fonctionnelles  (suite)
l  Etapes  de  construction  d’un  GDF
l  Extraction  du  dictionnaires  de  données  de  toutes  les  propriétés  qui  ne  sont  ni  
calculées  ni  concaténées  (Règle  de  validation  n°  1)
l  Suppression  de  Adresse,  Montant  et  Total

l  Construction  du  GDF

NBON
REFPRO
QTE

NCLI
DATE NREP
DESIGN PU

NOMREP NOMCLI RUECLI VILLECLI

76
Approche  ascendante
 Construction  du  graphe  de  dépendances  fonctionnelles  (suite)
l  Etapes  de  construction  d’un  GDF
l  S’il  reste  des  propriétés  isolées,  on  cherche  des  DF  qui  conduisent  à  des  
propriétés  à  partir  de  propriétés  concaténées
NBON
REFPRO
QTE
DATE NREP NCLI
DESIGN PU

NOMREP NOMCLI RUECLI VILLECLI


l  On  élimine  les  DF  obtenues  par  transitivité
l  NBON  →  NOMREP  est  une  DF  obtenue  par  transitivité
NBON
REFPRO
QTE
DATE NREP NCLI
DESIGN PU

NOMREP NOMCLI RUECLI VILLECLI 77


Approche  ascendante
 Réalisation  du  MCD
l  Les  arcs  terminaux  obtenus  à  partir  des  propriétés  élémentaires  définissent  les  
entités
l  Entités  COMMANDE,  REPRESENTANT,  PRODUIT,  CLIENT
l  Les  origines  des  arcs  sont  les  identifiants
l  COMMANDE(NBON),  REPRESENTANT(NREP),  PRODUIT(REFPRO),  
CLIENT(NCLI)


COMMANDE
  PRODUIT
NBON  
Date   REFPRO  
  DESIGN  
QTE
PU  

REPRESENTANT
CLIENT
NCLI  
NREP NOMCLI  
NOMREP   RUECLI  
VILLECLI  

78
Approche  ascendante
 Réalisation  du  MCD
l  Les  arcs  restants  me[ent  en  évidence  les  associations
l  L’association  PASSE,  OBTIENT  et  COMPOSE
l  Les  propriétés  non  isolées  restantes  sont  affectées  à  des  associations
l  QTE  est  affectée  à  l’association  COMPOSE
l  Les  propriétés  isolées  doivent  constituer  des  entités  isolées


COMMANDE
  1,n PRODUIT
NBON  
COMPOSE  
  0,n
Date   QTE REFPRO  
  DESIGN  
1,1
1,1 PU  

OBTIENT PASSE


0,n 0,n

REPRESENTANT
CLIENT
NCLI  
NREP NOMCLI  
NOMREP   RUECLI  
79
VILLECLI  

Approche  descendante
l  L’approche  descendante  se  déroule  en  plusieurs  étapes  :
l  Recueillir  des  informations  utiles Analyse  des  besoins
l  Expliciter  clairement  les  règles  de  gestion
l  Structuration Conception  du  MCD

80
Approche  descendante
Recueil  des  informations  utiles
l  Consiste  à  recueillir,  auprès  des  utilisateurs,  les  informations  utiles.
l  L’utilité  d’une  information  se  mesure  en  examinant  les  objectifs  
assignés  au  système

Entrées
Questions Sorties  
Réponses

En  règle  général,  le  système  doit  produire  des  documents    


en  réponse  à  la  fourniture  d’informations

81
Approche  descendante
Structuration
l  Consiste  à  me[re  en  évidence  les  entités  en  regroupant  les  informations  par  
affinité
Recueil  des  informations Structuration

info1 Entité  A
info2 Info1
Entité  B
Info2
info3 info3 Info5
info4 Info6

info5 info4

info6

Une    fois  positionnée  dans  une  entité,  une  information  


n’est  plus  disponible  pour  décrire  une  autre  entité 82
Approche  descendante

Structuration  (suite)
l  Me[re  en  évidence  les  associations  porteuses  d’informations
l  Les  informations  qui  ne  sont  pas  regroupables  dans  une  entité  sont  des  informations  
indépendantes  qui  sont  placées  dans  des  associations

(Entité  A,  Entité  B)


Entité  A
Info1
Entité  B
Info2
info3 Info5
Info6
info4

83
Normalisation
l  Une  fois  structurées,  on  obtient  un  schéma  conceptuel  de  données  formé  
d’un  ensemble  d’entités  décrites  à  l’aide  de  propriétés,  et  reliées  entre  elles  
par  des  associations
l  La  normalisation  consiste  à  vérifier  que  certaines  règles  de  «  bonne  qualité  »  
sont  respectées.  
l  Trois  séries  de  contrôle  :
l  Les  propriétés
l  La  structuration
l 
Les  cardinalités

84
Normalisation
Normalisation  des  propriétés
l  Chaque  propriété  est  unique
l  Chaque  propriété  est  bien  localisée
l  Chaque  propriété  a  un  nom  significatif
l  Eviter  les  redondances  évidentes  ou  cachées


Produit

Produit

Tarif
Prix1 1,n coûte
Prix2 code
prix


Client Prospect Personne

Code  personne
Code  client Code  prospect
Type  (C,P)
Nom  client Nom  prospect
Nom  personne

85
Normalisation
Normalisation  des  associations
l  Vérifier  l’unicité  des  noms  d’association
l  L’absence  d’associations  fantôme
l  La  non  redondance  des  chemins
l  La  non  décomposabilité
Exemple
Association  fantôme E1 E2
1,1
A 1,1



1,1
E3

l  Une  occurrence  de  E1  n’est  liée  qu’à  une  seule  occurrence  de  E2  et  de  E3  :  E1,  E2  et  E3  
sont  une  seule  et  même  entité  et  A  n’a  pas  lieu  d’être. 86
Normalisation
Exemple  (suite)
Suppression  de  la  redondance  des  chemins
E1 E2 E1 E2
A 1,1 A 1,1


1,1

C C

B 1,1 E3 B E3




Division
Salarié
0,n 1,1
travaille
Tous  les  salariés  occupent  un  bureau  situé  dans  
0,n 1,1

 le  département  dans  lequel  ils  travaillent
occupe

Situé  dans
1,1 Bureau
0,n 87


Les  extensions  MERISE

88
Spécialisation/Généralisation

Spécialisation  simple
l  La  spécialisation  simple  permet  de  modéliser,  dans  l’ensemble  
des  occurrences  d’une  entité,  des  sous-­‐‑ensembles  d’occurrences  
présentant  des  spécificités
l  Ces  spécificités  peuvent  porter  sur  des  propriétés  ou  des  
relations
Exemple
l  Un  assuré  peut  être  une    entreprise,  un  particulier  ou  les  deux.
l  On  distingue  3  entités  :  ASSURE,  ENTREPRISE  et  PARTICULIER
l  Un  assuré  a  les  propriétés  N°  Assuré,  Nom,  Adresse,  Type  et    Téléphone
l  Un  assuré  particulier  a  en  plus  une  profession  et  une  classe  d’âge
l  Une  entreprise  a  un  N°  SIREN  et  une  forme  juridique
89
Spécialisation/Généralisation
Spécialisation  simple






Spécialisation  multiple

90
Spécialisation/Généralisation
Contraintes  sur  spécialisation  
l  Elles  expriment  les  participations  des  occurrences  de  l’entité    
sur-­‐‑type  aux  entités  sous-­‐‑types
Types  de  contraintes
l  Pas  de  contraintes
§  Un  assuré  peut  être    particulier,  entreprise,  ni  particulier  ni  entreprise,  ou  les  
deux  à  la  fois
l  Exclusivité
§  Un  assuré  peut  être    soit  particulier  soit  entreprise,  soit  ni  particulier  ni  
entreprise  mais  pas  les  deux  à  la  fois
l  Totalité
§  Tout  assuré  est  un  particulier,  entreprise  ou  les  deux
l  Partition
91
§  Tout  assuré  est  soit  une  entreprise  soit  un  particulier
Spécialisation/Généralisation
 Spécialisation  à  sur-­‐‑types  multiples
C’est  une  notion  proche  de  la  notion  de  l’héritage  multiple
l 

Exemple
l  Etudiant  salarié

92
Spécialisation/Généralisation
Généralisation
l  La  généralisation  est  un  processus  de  modélisation  perme[ant  de  rassembler  
dans  une  même  entité  toutes  les  propriétés  communes,  et  de  garder  les  
propriétés  spécifiques  dans  les  entités  spécialisées
l  Le  concept  d’héritage  consiste  à  transme[re  les  propriétés  de  l’entité  super  
type  vers  les  entités  sous  types
l  Les  entités  sous  types  peuvent  avoir  leur  propre  identifiant

93
Spécialisation/Généralisation
Restrictions  et  sous  types  d’associations
Exemple
l  On  dispose  de  trois  entités  :  EMPLOYE,  CHEF_PROJET  et  PROJET.
l  CHEF_PROJET  étant  un  sous  type  de  EMPLOYE.  A  l’entité  PROJET  peuvent  être  
affectés  des  employés  via  une  association  Travailler.  Plusieurs  employés  peuvent  
travailler  sur  un  même  projet  mais  à  un  projet  est  affecté  un  et  un  seul  chef  de  projet
l  Pour  l’entité  CHEF_PROJET,  il  a  y  modification  des  cardinalités  de  l’association  
Travailler.
l  On  introduit  une  nouvelle  association  Gérer  entre  CHEF_PROJET  et  PROJET    
en  notant  bien  que  c’est  une  spécialisation  de  l’association  Travailler

94
Notions  complémentaires
Contraintes  intra-­‐‑association
l  On  ne  peut  pas  toujours  représenter    avec  les  cardinalités  les  contraintes  d’intégrité  
fonctionnelles  CIF
l  Une  CIF  sur  une  association  binaire

l  Une  CIF  sur  une  association  ternaire

95
Notions  complémentaires
Contraintes  inter-­‐‑associations
l  Les  contraintes  inter-­‐‑associations  expriment  les  conditions  entre  deux  ou  plusieurs  
associations
l  Contraintes  sur  la  participation  d’une  entité  à  plusieurs  associations

96
Notions  complémentaires
Exclusivité  de  participation  d’une  entité  à  plusieurs  relations
l Deux  (ou  plusieurs)  associations  au  départ  d’une  entité  peuvent  avoir  des  existences,  
en  termes  d’occurrences,  mutuellement  exclusives.  On  l’exprime  par  une  contrainte  X.
Exemple
l  Si  une  occurrence  de  l’entité  ARTICLE  participe  à  l’association  Acheter,  elle  ne  peut  pas  
participer  à  l’association  Approvisionner  et  réciproquement.

97
Notions  complémentaires
Simultanéité  de  participation  d’une  entité  à  plusieurs  relations
l Toute  occurrence  de  l’entité  participe  de  façon  simultanée  à  deux  (ou  plusieurs)  
associations.  On  l’exprime  par  la  contrainte  S.
Exemple
l  Toute  occurrence  de  l’entité    COMMANDE  participant  à  l’association  Passer  participe  simultanément  à  
l’association  Porter

98
Notions  complémentaires
Totalité  de  participation  d’une  entité  à  plusieurs  relations
l Toute  occurrence    de  l’entité  participe  au  moins    à  l’une  des  associations.    
On  l’exprime  par  T.
Exemple
l  Tout  véhicule  est  au  minimum  relié  soit  à  un  contrat  par  l’association  Couvrir,  soit  à  un  sinistre  par  
l’association  Impliquer,  soit  les  deux.  

99
Notions  complémentaires
Totalité  et  exclusivité  de  participation  d’une  entité  à  plusieurs  relations
Exemple
l  Une  entité  COMMANDE  participant  à  deux  associations  Passer  et  Provenir,  toute  
occurrence  de  COMMANDE  participe    soit  à  l’association  Passer,  soit  à  l’association  
Provenir.

100
Notions  complémentaires
Inclusion  de  participation  d’une  entité  à  plusieurs  relations
Exemple
l  Si  une  occurrence  de  l’entité  PERSONNE  participe  à  l’association  Souscrire,  elle  
participe  à  l’association  Effectuer  mais  pas  réciproquement.

101
Notions  complémentaires
Modélisation  du  temps
l  Modélisation  de  propriétés  à  valeurs  calendaires
l  Date  de  naissance,  date  de  livraison…sont  représentées  dans  un  schéma  par  des  propriétés  

DATE
FACTURE

FACTURE

1,1 échoir  
0,n NuméroFacture  
NuméroFacture   Date Date    échéance  


déconseillé

préférable

l  Modélisation  de  séries  chronologiques


l  Le  chiffre  d’affaires  mois  par  mois  des  clients
l  La  température  quotidienne  d’un  pays  

MOIS

CLIENT

0,n
a_obtenu  

Montant_CA  
0,n Nom  Mois
Numéro  Client   Année
102

Notions  complémentaires
Modélisation  du  temps
l  Historisation  de  propriété
l  Conserver  les  valeurs  antérieures  d’une  propriété  pour  chaque  occurrence  de  l’entité  ou  l’association
l  Historique  des  salaires  d’un  employé

HISTO-­‐‑SALAIRE

EMPLOYE
0,n A_abtenu  
1,1
Num  Employé      salaire   JJ  MM  AA




l  Historisation  d’une  entité  ou  d’association
l  Conserver  l’ensemble  des  valeurs  antérieures  de  toutes  les  propriétés  de  l’entité  ou  de  l’association


EMPLOYE  (H)

Num  Employé  
Nom  Employé  
103
Adresse  
Notions  complémentaires
Identification  relative
l  Un  identifiant  relatif  est  utilisé  pour  une  entité  dont  l’existence  dépend  totalement  
d’une  autre  entité


CHAMBRE
HOTEL
NumChambre
Num  Hotel   1,n Comporte  
1,1 Surface   Entité  faible
Catégorie        

Type  
Adresse   Nbr  lits

104
Modélisation  Logique    
de  Données  Relationnelle

105
Modélisation  Logique  de  Données
l  La  modélisation  logique  des  données  est  une  représentation  des  données,  
issue  de  la  modélisation  conceptuelle  des  données.
l  Elle  est  exprimée  dans  un  formalisme  général  et  compatible  avec  l’état  de  
 l’art  technique,  et  tient  compte  des  aspects  coût/performance  liés  aux  
traitements.
l  L’élaboration  du  modèle  logique  de  données  (MLD)  consiste  à  :
l  Transformer  le  MCD  en  un  MLD  exprimé  dans  un  formalisme  logique  adapté  au  
SGBD  envisagé
l  Quantifier  en  volume  le  modèle  logique
l  Valoriser  l’activité  générée  par  les  modèles  externes  associés  aux  traitements
l  Effectuer  une  optimisation  générale

106
Modèles  de  Données
l  Plusieurs  modèles  (ou  formalismes)  théoriques  de  bases  de  données  sont  
disponibles  pour  représenter  le  MLD  :

l  Modèle  hiérarchique

l  Modèle  réseau  (ou  CODASYL)

l  Modèle  relationnel

l  Modèle  orienté  objet  

107
Modèles  de  Données

Modèle  hiérarchique
l  Les  données  sont  organisées  selon  une  arborescence
l  Concepts
l  Nœuds  de  l’arbre  :  entités
l  Chemins  entre  les  nœuds  :  liens  entre  les  objets
l  Les  liens  sont  exclusivement  de  type  1:N

108
Modèles  de  Données

Modèle  réseau
l  Concepts
l  Les  articles  :  définition  des  entités
l  Les  ensembles  :  association  entre  un  article  propriétaire  et  n  articles  membres
l  Un  modèle  réseau  peut  être  représenté  par  un  graphe  des  occurrences  :
l  Les  nœuds  :  articles
l  Les  arcs  :  ensembles
l  Les  arcs  ont  les  noms  des  ensembles  et  sont  orientés  du  propriétaire  vers  les  membres.
l  Le  modèle  privilégie  les  liens  1:N  et  permet  une  représentation  symétrique  des  liens  N:M

109
Modèles  de  Données

Modèle  relationnel

l  Concepts
l  Tables  :  sous-­‐‑ensemble  du  produit  cartésien  de  plusieurs  domaines
l  Chaque  élément  de  la  table  est  appelé  n-­‐‑uplet  ou  tuple
l  Chaque  tuple  est  composé  de  plusieurs  atributs

110
Modèles  de  Données

Modèle  orienté  objet

l  Concepts
l  Les  objets  :  structures  et  méthodes
l  Les  classes  :  description  de  schéma,  collection  d’objets
l  Identité  d’objet
l  Héritage

111
Modèles  Logique  de  Données  Relationnel
l  Défini  par  E.F.  Codd  en  1970  à  IBM
l  Bases  théoriques
l  Concepts  issus  de  la  théorie  des  ensembles  
l  Algèbre  relationnelle  perme[ant  de  définir  une  collection  de  relations
l  Notions  fondamentales
l  Domaines
l  Relations
l  A[ributs
l  Clés  primaires  et  clés  étrangères
l  Tuples  (ou  n-­‐‑uplet)

112
Modèle  Logique  de  Données  Relationnel
l  Un  domaine  est  un  ensemble  de  valeurs  caractérisé  par  un  nom  (entiers,  dates,  etc)
l  Une  table  (ou  relation)  est  un  sous-­‐‑ensemble  du  produit  cartésien  de  plusieurs  
domaines
l  Les  colonnes  sont  les  a^ributs  et  les  lignes  sont  les  tuples
l  L’ordre  des  colonnes  est  sans  importance
l  Un  a[ribut  prend  ses  valeurs  dans  un  domaine
l  Plusieurs  colonnes  peuvent  appartenir  à  un  même  domaine  
l  On  associe  un  nom  à  chaque  colonne

Exemple

113
Modèle  Logique  de  Données  Relationnel
Clé  primaire
l  Un  ou  plusieurs  a[ributs  perme[ent  d’identifier  de  façon  unique  chaque  tuple
de  la  table.  Il  s’agit  de  la  clé  primaire
l  La  clé  primaire  d’une  table  est  l’ensemble  minimal  d’a[ributs  dont  la  
connaissance  des  valeurs  permet  d’identifier  un  tuple  unique  de  la  table  
considérée
l  Tout  a[ribut  participant  à  la  clé  primaire  est  non  NULL  (NULL  =  valeur  indéterminée)
l  La  valeur  de  la  clé  primaire  d’une  ligne  ne  devrait  pas  changer  au  cours  du  temps
l  La  clé  primaire  est  dite    simple  si  elle  est  constituée  d’un  seul  a[ribut  et  composée  dans  le  cas  
contraire

114
Modèle  Logique  de  Données  Relationnel
Clé  étrangère
l  Une  clé  étrangère  est  un  sous  groupe  d’a[ributs  qui  doit  apparaitre  comme  clé  dans  une  
autre  table
l  Une  même  table  peut  avoir  plusieurs  clés  étrangères  mais  une  seule  clé  primaire  
(éventuellement  composée  de  plusieurs  colonnes)
l  Une  clé  étrangère  peut  être  composée  (c’est  le  cas  si  la  clé  primaire  référencée  est  composée)  
l  Implicitement  chaque  colonne  qui  compose  une  clé  primaire  ne  peut  pas  recevoir  la  valeur  
vide  (NULL  interdit)

115
Règles  de  passage  d’un  MCD  à  un  MLDR
l  Notations
l  On  dit  qu’une  association  binaire  (entre  deux  entités  ou  réflexive)  est  de  type  :
l  1,1  (un  à  un)  si  aucune  des  2  cardinalités  maximales  n’est  n
l  1,n  (un  à  plusieurs)  si  une  des  2  cardinalités  maximales  est  n
l  n,m  (plusieurs  à  plusieurs)  si  les  2  cardinalités  maximales  sont  n

116
Règles  de  passage  d’un  MCD  à  un  MLDR
Règle  1
l  Toute  entité  devient  une  table  dans  laquelle  les  propriétés  deviennent  les  colonnes.
l  L’identifiant  de  l’entité  constitue  alors  la  clé  primaire  de  la  table.
Règle  2
l  Une  association  binaire  de  type  1,n  disparaît,  au  profit  d’une  clé  étrangère  dans  la  table  coté  
0,1  ou  1,1  qui  référence  la  clé  primaire  de  l’autre  table.  Ce[e  clé  étrangère  ne  peut  pas    
recevoir  la  valeur  vide  si  la  cardinalité  est  1,1

117
Règles  de  passage  d’un  MCD  à  un  MLDR
Règle  3
l  Une  association  binaire  de  type  n,m  devient  une  table  supplémentaire  (table  de  jonction)    
dont  la  clé  primaire  est  composée  des  deux  clés  étrangères.  

118
Règles  de  passage  d’un  MCD  à  un  MLDR
Règle  4
l  Une  association  binaire  de  type  1,1  est  traduite  comme  une  association  binaire  de  type  1,n  sauf  
que  la  clé  étrangère  se  voit  imposer  une  contrainte  d’unicité  (ce[e  contrainte  d’unicité  impose  à  
la  colonne  correspondante  de  ne  prendre  que  des  valeurs  distinctes).  






119
Règles  de  passage  d’un  MCD  à  un  MLDR
Règle  5
l  Une association non binaire est traduite par une table supplémentaire dont la clé primaire est
composée d’autant de clés étrangères que d’entités en association. Les attributs de l’association
deviennent les colonnes de cette nouvelle table.

120
Passage  d’un  MCD  à  un  MLDR
Association  réflexive
l  Lorsqu’une  association  est  réflexive  (*,n)-­‐‑(*,1),  on  duplique  la  clé  de  la  relation  avec  un  nom  
différent.  

EMPLOYE

1,1
EMPLOYE
Matricule  
Matricule  
Est-­‐‑ Nom  
Nom   chef   Prénom  
Prénom  
Date  embauche  
Date  embauche 0,n #Matricule_chef

l  Lorsqu’une  association  est  réflexive  (*,n)-­‐‑(*,n),  on  créé  une  relation  de  lien  ayant  comme  clé  
une  clé  composée  de  deux  fois  l’identifiant  de  l’entité.  


TRAVAIL 0,n TRAVAIL DECOMPOSE

Num  travail   Num  travail   Num  travail    
décomposé  
 Numtravailensemble    
Désignation   Désignation  
Durée   Durée
0,n
121
Passage  d’un  MCD  à  un  MLDR
Spécialisation
l  Solution  1  :  On  exprime  les  sous  types    par  des  relations  spécifiques,  
correspondant  à  des  associations  (0,1)  –  (1,1)
l  Solution  2  :  On  duplique  la  totalité  du  contenu  du  sur-­‐‑type  dans  les  sous  
types  associés
l  Solution  3  :  On  duplique  la  totalité  du  contenu  du  sur-­‐‑type  dans  les  sous  
types  associés  et  on  supprime  le  sur-­‐‑type
l  Solution  4  :  On  transfère  la  totalité  des  sous  types  dans  la  table  
correspondant  au  sur-­‐‑type

Généralisation
l  Les  sous  types  ont  leurs  propres  identifiants.  
l  Seules  les  transformations  des  solutions  1  et  2  (de  la  spécialisation)  sont  possibles
122
Règles  de  passage  d’un  MCD  à  un  MLDR
Exemple  :  voir  tableau  
   

123
Modélisation  Physique  
de  Données

124
Modélisation  Physique  des  données
l  Il  s’agit  de  la  formalisation  opérationnelle  des  données
l  Spécifier  comment  seront  réalisés  les  éléments  du  système
l  Modèle  Physique  des  Données


Base  de  données  relationnelles
l  Une  bases  de  données  relationnelles  est  un  ensemble  de  relations

125
Modélisation  Physique  des  données
l  La  représentation  standard  d’une  base  de  données  relationnelle  est  le  mode  
formel  :
l  Exemple
FILM(NoIdentification,  NoDistributeur,  Titre,  AnnéeProduction,  Durée,  Producteur,Réalisateur,  Genre)
ACTEUR-­‐‑FILM(NomActeur,  NoIdentification)
DISTRIBUTEUR(NoDistributeur,  Nom,  Adresse,  Rachat)
CASSETTE(NoSérie,  NoIdentification,  Format)
CASSETTE-­‐‑LOUÉE(NoSérie,  NoBon,  DateRetour)
BON-­‐‑LOCATION(NoBon,  NoClient,  DateLocation)
CLIENT(NoMembre,  Nom,  Adresse,  NoTél,  NoCarteCrédit,  MontantDépôt)

l  Une  dernière  étape  avant  l’implémentation  perme[ra  d’optimiser  la  base  de  
données  :  la  normalisation

126
Exemple  d’anomalies  sur  un  modèle  relationnel  

l  Les  principales  anomalies  rencontrées  sont  les  suivantes  :


l  Anomalie  de  mise  à  jour  :  si  on  doit  changer  une  information  redondante,  par  exemple  la  
durée  du  film,  il  faut  changer  ce[e  information  dans  plusieurs  tuples.
l  Anomalie  de  suppression  :  si  un  ensemble  de  valeurs  devient  vide,  on  peut  perdre  d'ʹautres  
informations  par  effet  de  bord.  Par  exemple,  si  on  supprime  "ʺle  vent  se  lève"ʺ,  on  perd  comme  
information  que  Cillian  Murphy  est  un  acteur.

Solution

127
Normalisation  et  Décomposition
Normalisation

l  L'ʹétude  de  la  normalisation  des  relations  obtenues  a  pour  objectif  
de  vérifier  la  non  redondance  de  données  dans  notre  système  
d'ʹinformations,  et  ainsi  éviter  certaines  anomalies  de  stockage  
dans  la  future  implantation  d'ʹune  base  de  données.
l  Plusieurs  formes  normales  (FN)  existent  :  
l  1FN  
l  2FN
l  3FN
l  FN  de  Boyce-­‐‑Codd

128
 Formes  normales

Première  forme  normale  (1FN)


l  Une  relation  est  en  première  forme  normale  (1FN)  si  chacun  de  ses  a[ributs  
contient  une  valeur  atomique.  
l  On  parle  d'ʹa[ributs  de  relation  monovalués.
l  La  démarche  à  suivre  est  la  suivante  :
l  Sortir  le  groupe  répétitif  de  la  relation  initiale
l  Transformer  le  groupe  répétitif  en  relation,  rajouter  dans  la  clé  de  ce[e  nouvelle  relation    
la  clé  primaire  de  la  relation  initiale

129
 Formes  normales

Deuxième  forme  normale  (2FN)


l  Une  relation  est  en  deuxième  forme  normale  (2FN)  si  :
l  elle  est  en  première  forme  normale.
l  les  a[ributs  n'ʹappartenant  pas  à  la  clé  primaire  ne  dépendent  pas  fonctionnellement  d'ʹune  
partie  de  la  clé.
l  Les  a[ributs  non-­‐‑clés  sont  en  dépendance  fonctionnelle  pleine  avec  la  clé.

l  Le  processus  est  le  suivant  :


l  Regrouper  dans  une  relation  les  a[ributs  dépendant  de  la  totalité  de  la  clé  primaire  et  conserver  ce[e  clé  pour  
ce[e  relation
l  Regrouper  dans  une  autre  relation  les  a[ributs  dépendant  d’une  partie  de  la  clé,  et  faire  de  ce[e  partie  de  clé  la  
clé  primaire  de  la  nouvelle  relation

130
 Formes  normales

Troisième  forme  normale  (3FN)


l  Une  relation  est  en  troisième  forme  normale  (3FN)  si:
l  elle  est  en  2FN
l  tout  a[ribut  non  clé  ne  dépend  pas  fonctionnellement  d'ʹun  autre  a[ribut  non  clé.
l  tous  les  a[ributs  non-­‐‑clés  sont  en  dépendance  fonctionnelle  directe  avec  la  clé.

l  Il  s’agit  donc  d’éliminer  les  dépendances  transitives  au  sein  d’une  relation.  La  
démarche  est  la  suivante  :
l  Conserver  dans  la  relation  initiale  les  a[ributs  dépendant  directement  de  la  clé
l  Regrouper  dans  une  relation  les  a[ributs  dépendant  transitivement.  L’a[ribut  de  transition
reste  dupliqué  dans  la  relation  initiale,  et  devient  la  clé  primaire  de  la  nouvelle  relation

131
 Formes  normales

Forme  normale  Boyce-­‐‑Codd


l  Une  relation  est  en  forme  normale  Boyce-­‐‑Codd  si:
l  Elle  est  en  3FN
l  Tout  a[ribut  n’appartenant  pas  à  une  clé  dépend  de  ce[e  clé  entièrement  et  aucun  a[ribut  de  
la  clé  ne  dépend  d’un  autre  a[ribut.

Ensemble.  des  a[ributs-­‐‑clés

x x x x
x x x x
x x x
x x x x
x
x x

ensemble des attributs non clés


Cette dépendance concrétise le fait
que la relation n’est pas en
3FNBCK.
132
 Formes  normales

Résultat  final  de  l‘exemple

133
Formes  normales

l  Les  trois  premières  formes  normales  sont  les  plus  utilisées.  Le  processus  de  
normalisation  cherche  le  plus  souvent  à  obtenir  des  relations  en  troisième  
forme  normale.  
l  Il  existe  certes  des  processus  automatisés  qui  vont  au-­‐‑delà  et  produisent  des  
relations  encore  plus  «  pures  »  (avec  4FN  et  5FN).
l  Le  processus  de  normalisation  fait  intervenir  des  mécanismes  qui  agissent  sur  
un  ensemble  réduit  de  dépendances.  Ce[e  réduction  est  obtenue  par  
dérivation,  par  application  de  règles  de  transformation.
l  PRINCIPE  :  on  enlève  toute  dépendance  que  l’on  peut  retrouver  en  
appliquant  une  série  de  règles  de  dérivation.
l  CONTRAINTE  :  on  garde  toute  dépendance  qui  permet  de  retrouver  une  
dépendance  qui  a  été  enlevée  en  accord  avec  le  principe  précédent.

134
Approche  de  décomposition

l  On  peut  produire  un  schéma  relationnel  à  partir  de  contraintes,  


les  principales  étant  les  dépendances  fonctionnelles.
l  Approche  de  décomposition  

Principe  
l  A  partir  d’une  relation  composée  de  tous  les  a[ributs,  décomposer  ce[e  
relation  en  sous-­‐‑relations  sans  anomalie
l  Processus  de  raffinement  successif  devant  aboutir  à  isoler  les  entités  et  
associations  du  monde  réel
l  Obtenir  une  décomposition  sans  perte  à  partir  d’une  bonne  compréhension  
des  propriétés  sémantiques  des  données  

135
 Algorithme  de  décomposition

l  La  procédure  de  décomposition  ou  de  normalisation  est  :


l  Utiliser  en  entrée  un  graphe  C  de  DF
l  Editer  les  a[ributs  isolés  dans  C
l  Réduire  C
l  Tant  qu’une  DF  n’inclut  pas  tous  les  a[ributs,  faire  :
§  Rechercher  le  plus  grand  ensemble  d’a[ributs  X  tels  que  X  →  A1,  ….,  X  →  An
§  Editer  la  relation  R(X,  A1,  A2,  …..,  An)
§  Eliminer  les  DF  figurant  dans  R  de  C
§  Réduire  C
l  Editer  la  relation  composée  de  tous  les  a[ributs  restants

Exemple  
l  Voir  tableau

136
Quelques  opérateurs  de  manipulation  des  données
l  L'ʹUNION  de  deux  relations  (définies  sur  les  mêmes  domaines)  fournit  une  nouvelle  relation  qui  
contient  tous  les  n-­‐‑uplets  des  deux  relations  initiales.
l  L'ʹINTERSECTION  de  deux  relations  (ayant  mêmes  domaines)  fournit  une  nouvelle  relation  qui  
contient  les  n-­‐‑uplets  communs  aux  deux  relations  initiales.  
l  La  DIFFERENCE  de  deux  relations  (ayant  mêmes  domaines)  fournit  une  nouvelle  relation  qui  
contient  les  n-­‐‑uplets  de  la  1ère  qui  ne  se  trouvent  pas  dans  la  2ème.  
l  La  PROJECTION  d'ʹune  relation  (opérateur  unaire)  fournit  une  nouvelle  relation  définie  pour  les  
seuls  a[ributs  demandés.  
l  La  SELECTION  d'ʹune  relation  (opérateur  unaire)  fournit  une  nouvelle  relation  restreinte  aux  n-­‐‑
uplets  qui  respectent  une  proposition  logique  formulée  à  l'ʹaide  d'ʹopérateurs  de  comparaison  et  /
ou  d'ʹopérateurs  logiques.
l  La  JOINTURE  de  deux  relations  (ayant  un  a[ribut  commun)  fournit  une  nouvelle  relation  
concaténant  deux  à  deux  les  n-­‐‑uplets  des  deux  relations  initiales  ayant  même  valeur  pour  
l'ʹa[ribut  commun.    


137
Rétro-­‐‑Conception

138
Pourquoi  la  rétro-­‐‑conception

l  But
l  Passer  d’un  schéma  relationnel  à  un  schéma  Entité-­‐‑Association  équivalent
l  Pourquoi  ?
l  Analyse  n’a  pas  été  faite  ou  a  été  perdue
l  Comment  ?
l  Appliquer  les  étapes  de  transformation  «  à  l’envers  »
l  Remarque
l  Ne  fournit  pas  une  solution  unique  (perte  d’information  sur  le  schéma  
relationnel  par  rapport  au  schéma  E/A)

139
Principes  de  la  rétro-­‐‑conception

l  Appliquer  à  l’envers  les  étapes  de  traduction  :


l  Une  relation  ne  possédant  pas  de  clé  étrangère  au  sein  de  sa  clé  :    
l  Une  entité
l  Une  relation  dont  la  clé  comprend  une  clé  étrangère  et  une  clé  "ʺlocale"ʺ  :
l  Un  ensemble  d'ʹentité  faible  par  rapport  à  l'ʹensemble  d'ʹentité  correspondant  à  la  
clé  étrangère
l  Une  relation  possédant  une  clé  étrangère  à  l'ʹextérieur  de  sa  clé  :
l   Une  entité  plus  association  monovaluée  vers  l'ʹentité  correspondant  à  la  clé  
étrangère
l  Une  relation  dont  la  clé  est  intégralement  composée  de  clés  étrangères  :
l  Une  association  multivaluée  entre  les  ensembles  d'ʹentités  correspondant
aux  clés  étrangères

140
Modélisation  Conceptuelle  
de  Communication

141
Modèle  conceptuel  de  communication

l  Le  modèle  conceptuel  de  communication  (MCC),  représente  les  systèmes  


fonctionnels  externes  et  internes  à  l’entreprise.  
l  A  chaque  fonction  correspond  un  objectif  de  l’entreprise.  
l  Les  échanges  d’informations  entre  ces  fonctions  sont  répertoriées  et  les  informations  
recensées.

l  La  première  étape  de  ce  modèle  est  d'ʹarriver  à  isoler  le  système.  
l  Il  s'ʹagit  donc  de  définir  le  système  et  les  éléments  externes  avec  lesquels  il  échange  des  flux  
d'ʹinformation.  Ces  éléments  extérieurs  sont  appelés  acteurs  externes.  
l  La  seconde  étape  consiste  à  découper  l'ʹorganisation  en  entités  appelées  acteurs  internes.  
l  La  dernière  étape  est  l'ʹanalyse  des  flux  d'ʹinformation,  c'ʹest-­‐‑à-­‐‑dire  la  définition  des  processus.  

142
Acteurs
l  Un  acteur  est  représenté  par  un  cercle  libellé  par  le  nom  de  l’acteur
l  L’acteur  représente  une  unité  active  intervenant  dans  le  
fonctionnement  d’un  système  opérant.  
l  Il  peut  être  stimulé  par  des  flux  d’information
l  Il  peut  transformer  et  éme[re  des  flux  d’information
l  Un  acteur  «  fait  quelque  chose  »,  il  est  actif
l  Exemple
l   Service  comptabilité,  Guichet  ...
l  Un  acteur  est  un  rôle  plutôt  qu’une  personne  physique
l  Exemple  
l   «  Direction  »  et  pas  «  Jean-­‐‑Claude  »
l  Il  peut  être  pertinent  de  modéliser  séparément  deux  fonctions  assumées  
par  une  même  personne  physique
l  On  distingue  les  acteurs  internes  et  externes 143
Flux  d’information

l  Un  flux  d’information  est  représenté  par  une  flèche  entre  deux  
acteurs,  étiquetée  par  le  nom  du  flux
l  Echange  d’informations  entre  deux  acteurs
l  Exemple
l  documents,  appels  téléphoniques,  données  informatiques

144
Acteurs  externes

l  Eléments  externes  avec  lesquels  le  système  échange  des  flux  
d’information
l  Exemple  
l  clients,  fournisseurs...

145
Acteurs  internes

l  Acteurs  faisant  partie  du  système  d’information  étudié


l  Ex  :  guichet,  service  informatique...
l  Si  le  système  est  complexe,  on  peut  considérer  un  acteur  interne  
comme  un  sous-­‐‑domaine  et  détailler  ce  sous-­‐‑domaine  dans  un  
nouveau  MCC

146
Modélisation  Conceptuelle  
des  Traitements

147
Modèle  conceptuel  de  traitement  (MCT)

l  Le  MCT  représente  formellement  les  activités  exercées  par  le  


domaine
l  Il  repose  sur  la  prise  en  compte  des  échanges  (flux)  du  domaine  
avec  son  environnement
l  Il  s’effectue  en  faisant  abstraction  de  l’organisation  et  des  choix  
technologiques

La  définition  des  interactions  du  domaine  avec  son  environnement    
prime  sur  la  manière  dont  on  assurera  ces  activités

l  Le  résultat  est  un  modèle  conceptuel  de  traitements  (MCT)  clair,
cohérent,  complet,  fidèle  et  normalisé
148
MCT  et  MCC

l  Le  MCT  est  un  «  zoom  »  sur  le  MCC


l  Dans  les  MCC,  on  représente  les  messages  échangés  entre    
acteurs
l  Dans  les  MCT,  on  représente  comment  un  acteur  de  
l’organisation  réagit  quand  il  reçoit  ce  message  et  quelle  
opération  il  effectue

149
Modèle  conceptuel  de  traitement

l  Une  administration  qui  gère  des  demandes  de  promotion

l  Toute  demande  de  promotion  doit  subir  un  examen  


préalable  perme[ant  de  déterminer  si  elle  est  recevable  ou  
non
l  L’examen  du  dossier  d’une  demande  recevable  ne  peut  se  
faire  qu’après  rapport  du  supérieur  hiérarchique
l  Après  examen  du  dossier  par  l’autorité  compétente,  la  
promotion  sera  accordée  ou  refusée

l  Les  différents  programmes  informatiques  de  l’activité  de  


gestion  des  promotions

150
Modèle  conceptuel  de  traitement

151
Modèle  conceptuel  de  traitement

Exemple  

152
Modèle  conceptuel  de  traitement

Exemple  :  Passage  du  MCC  au  MCT

153
Modèle  conceptuel  de  traitement

Principe  général

154
Modèle  conceptuel  de  traitement

l  Le  MCT  exprime  ce  qu’il  faut  faire,  mais  n’indique  pas  qui  doit  le  
faire  ni  quand  le  faire  ni  où  le  faire  (niveau  organisationnel)
l  Le  MCT  traduit  les  règles  de  gestion  du  domaine  étudié
l  Les  principaux  concepts  utilisés  sont  :
l   L’événement  /  Le  résultat
l   L’Opération  -­‐‑  La  synchronisation
l   Le  processus
l  L’utilisation  d’un  formalisme  graphique

155
Concepts  et  règles  de  modélisation

l  Le  domaine
l  L’acteur
l  L’événement  /  Le  résultat-­‐‑message
l  L’opération
l  La  synchronisation
l  Les  conditions  d'ʹémission
l  Le  processus

156
Le  domaine

l  A  chaque  finalité  de  l’entreprise  est  associé  un  domaine  d’activité
l  la  gestion  commerciale,  la  gestion  de  la  production,  la  gestion  des  ressources  humaines…
l  Chaque  domaine  d’activité  est  décomposée  en  plusieurs  fonctions
l  la  gestion  des  ressources  humaines  :
l  la  paie  des  personnels  ou  le  déroulement  de  carrière

l  On  représente  le  domaine  d’activité  par  un  diagramme  de  flux
l  Un  flux  est  la  représentation  de  l’échange  d’informations  entre  deux  activités,  ou  entre  une  
activité  et  un  partenaire  extérieur  à  l’entreprise

157
Le  domaine

158
L’acteur

l  Un  acteur  est  une  entité  organisationnelle  identifiable  par  les  


missions  qu’il  remplit  dans  le  cadre  du  champ  d’étude  défini
l  Exemple  1  
l  L’employé  dans  le  domaine  de  la  gestion  des  promotions
l  Exemple  2
l  L’abonné  dans  le  domaine  de  la  gestion  des  prêts  de  bibliothèque

159
L’évènement

l  Les  flux  reçus  et  émis  par  le  domaine  sont  modélisés  par  des  évènements

l  Un  événement  est  la  représentation  d’un  fait  nouveau  pour  le  S.I.
l  C’est  un  déclencheur  d’une  réaction  du  S.I.
l  Un  évènement  est  accompagné  d’un  message,  qui  correspond  à  l’ensemble  
d’informations  associées  au  fait  nouveau
160
L’évènement

événement
Il y a une facture qui vient
E1 E2 d’arriver
E3
a b c

facture
Maison PHILDEX Nantes, le 18 mai 2003
OPERXY FACTURE

message Frais de port


Total à payer
associé à E3 En votre aimable règlement.

161
L’évènement

l  Dans  un  MCT,  on  ne  représente  que  des  types  d’événement
l  On  distingue  :
l   les  évènements  externes,  les  évènements  internes  et  les  évènements  temporels
l  Un  évènement  temporel  représente  des  échéances  (fin  de  mois,  chaque  
jour...)
l  Un  évènement  externe  provient  de  l’extérieur  du  champ  de  l’étude  
(domaine)
l  Contenu  du  message  :  uniquement  des  informations  extérieures

162
L’évènement

l  Un  évènement  interne  est  généré  par  le  traitement  du  domaine
l  Deux  cas  possibles  :
l  Vers  l’extérieur  du  domaine
l  Vers  une  autre  opération  (chaînage  interne)
l  Contenu  du  message  :  enrichi  par  la  base  d’information  du  domaine  

externe

OPERXY

OPERYZ
interne

163
L’opération

l  L’opération  décrit  le  comportement  du  domaine  étudié  et  de  son  
S.I.  par  rapport  à  la  survenance  d’événements
l  Elle  est  déclenchée  par  la  survenance  des  occurrences  
d’événements,  ou  de  plusieurs  événements  et/ou  des  états  
préalables  à  l’opération
l  L’exécution  de  l’opération  comprend  l’ensemble  des  activités  (ou
fonctions  ou  actions)  que  le  domaine  effectue  à  partir  des  
informations  fournies  par  l’événement  et  de  celles  déjà  connues  
dans  la  mémoire  du  SI
l  L’opération  est  ininterruptible
l  Elle    se  déroule  sans  a[ente  d’aucun  nouveau  événement

164
L’opération

Exemple  

165
Le  résultat

l  Le  résultat  est  un  évènement  émis  en  sortie  d’une  opération
l  Il  s’agit  donc  d’un  évènement  interne,  qui  peut  éventuellement  participer  
au  déclenchement  d’une  opération  ultérieure
l  Le  résultat  est  un  message  sortant  du  domaine  en  direction  d’un  
acteur  externe  ou  d’un  domaine  connexe

166
Le  synchronisation

l  La  synchronisation  est  une  condition  préalable  au  déclenchement  


de  l’opération
l  Elle  se  traduit  par  une  expression  logique  s’appliquant  sur  la  
présence  (ou  l’absence)  des  occurrences  d’événements  et/ou  des  
états  préalables  à  l’opération
l  Si  la  condition  est  vérifiée,  l’opération  peut  démarrer  et  les  
occurrences  déclencheuses  sont  consommées  par  l’opération
l  Si  la  condition  est  non  vérifiée,  la  synchronisation  et  les  
occurrences  d’événements  présentes  restent  en  a[ente  jusqu’à  ce  
qu’elle  soit  vérifiée

167
Conditions  d’émission

l  L’émission  des  résultats  est  soumise  à  des  conditions  traduites  


par  des  expressions  logiques
l  Plusieurs  résultats  de  nature  et  destination  différentes,  ainsi  que  
plusieurs  états  d’objets  différents  peuvent  être  émis  par  une  
même  condition
l  L’  expression  des  conditions  d’émission  peut  être  considérée  
comme  vraie  ou  fausse  à  n’importe  quelle  étape  du  déroulement  
de  l’opération  et  plusieurs  peuvent  avoir  la  valeur  «vraie»  à  
l’issue  d’une  opération

168
Le  processus

l  Le  processus  est  un  enchaînement  d’opérations  qui  concourent  à  


un  même  but,  c-­‐‑à-­‐‑d  à  l’élaboration  d’un  ou  plusieurs  résultats  en  
réponse  d’un  ou  plusieurs  événements  extérieurs  au  domaine
l  Il  représente  un  sous-­‐‑ensemble  du  domaine  étudié  dont  les  
événements  initiaux  et  les  résultats  finaux  délimitent  un  état  
stable  du  domaine
l  Exemple  
l  La  gestion  de  bibliothèque
l  La  gestion  des  abonnés
l  La  gestion  des  prêts  de  livre
l  La  gestion  des  achats

169
La  démarche  de  construction  d’un  MCT

Les  étapes  de  la  démarche  sont  :


1.  Déterminer  le  champ  de  l’étude  
l  Définition  du  domaine  étudié  (Gestion  de….)
l  Identifier  les  acteurs  extérieurs
2.  Identifier  les  principaux  processus  du  domaine  étudié
3.  Relever  et  ordonnancer  les  flux  d’informations
l  Recenser  les  flux  entre  domaine  et  acteurs  extérieurs
l  Rechercher  les  relations  de  précédence
4.  Découper  chaque  processus  en  opérations
5.  Décrire  chaque  opération  avec  sa  synchronisation,  ses  fonctions  et
ses  conditions  d’émission
170
La  démarche  de  construction  d’un  MCT

Exemple
l  Cas  de  «  la  Quincaillerie  de  la  gare  »
l  Identification  des  acteurs
l  Les  acteurs  internes  :  Magasin,  Service  des  achats
l  Les  acteurs  externes  :  Fournisseur,  Comptabilité
l  Identification  des  flux  échangés  entre  les  acteurs

171
La  démarche  de  construction  d’un  MCT

l  Élaboration  du  graphe  d’ordonnancement  des  flux

172
La  démarche  de  construction  d’un  MCT

l  Élaboration  du  MCT

173
La  démarche  de  construction  d’un  MCT

l  Élaboration  du  MCT  (suite)

174
Vérification  du  MCT

l  Un  acteur  émet  au  moins  un  événement,  ou  reçoit  au  moins  un  
résultat
l  Un  événement  externe  provient  d’au  moins  un  acteur
l  Un  résultat  provient  d’au  moins  une  opération
l  Tout  résultat  a  au  moins  une  destination  :  un  acteur  ou  une  
opération

175
Validation  du  MCT

l  Une  expression  logique  associée  à  une  synchronisation  ou  à  


l'ʹémission  d’un  résultat  ne  peut  être  toujours  fausse
l  Contrôler  un  fonctionnement  cyclique
l  S’assurer  que  tout  résultat  ou  état  du  MCT  peut  être  produit
l  Analyser  les  situations  de  conflit  
l  Un  événement  ou  un  résultat  contribue  à  plusieurs  synchronisations  ou    
est  destiné  à  plusieurs  acteurs

176
Affinage  du  MCT

l  Élimination  des  traitements  redondants

177
Spécification  du  MCT

Le  M.C.T.  doit  être  composé  


l  d’une  ou  de  plusieurs  représentations  graphiques
l  Le  modèle  général  des  processus
l  Par  processus,  un  schéma  d’enchaînement  des  opérations  d’une  description  textuelle  
comprenant    pour  chaque  opération  :
l  une  description  succincte
l  la  liste  des  événements  contributifs  et  du  message  associé
l  la  liste  des  états  préalables  à  l’opération
l  les  conditions  de  la  synchronisation
l  les  fonctions  de  l’opération
l  les  résultats  produits  et  les  messages  associés
l  les  états  résultants
l  les  conditions  de  production  de  ces  résultats

178
Spécification  du  MCT

l  Une  description  type  d’opération


179
Modélisation  Organisationnelle  
des  Traitements

180
Modèle  Organisationnel  des  Traitements  (MOT)

l  Le  Modèle  Organisationnel  des  Traitements  (MOT)  décrit  


l’organisation  des  traitements  du  système  étudié.  Il  consiste  à  
répondre  aux  questions  suivantes  :
l  Qui  fait  quoi  ?  Avec  quelles  ressources  ?  
l  Quand  fait-­‐‑on  les  traitements  ?
l  D'ʹoù  exécute-­‐‑t-­‐‑on  les  traitements  ?
l  Le  MOT  représente  les  «  opérations  »  du  MCT  sous  une  forme  
détaillée,  puisque  l'ʹorganisation  interne  de  l'ʹentreprise  est  ici  
prise  en  compte.  
l  Chaque  opération  du  MCT  se  trouve  donc  subdivisée  en  
«  procédures  fonctionnelles  »  (PF)  qui  sont,  elles  aussi,  
initerruptibles.  
181
Modèle  Organisationnel  de  Traitement  (MOT)

MOT  =  MCT  +  lieu  +  moment  +  nature


l  Lieu
l  Qui  exécute  ?  Acteurs  (MCC)
l  Moment
l  Quand  exécute-­‐‑t-­‐‑on  l’opération  ?
l  fréquence  (jour,  mois,…),  dates  au  plus  tôt  et  au  plus  tard,  temps  moyen
l  Nature
l  Manuelle
l  Automatique  ou  Différé
l  Temps  Réel    ou  Interactive  ou  Conversationnel

182
Concepts  de  base

l  Un  poste  de  travail  est  une  entité  physique  comprenant  des  ressources  sur  un  
lieu  donné.
l  Les  ressources  d’un  poste  de  travail  sont  les  moyens  matériels  et  humains  
dont  le  poste  doit  être  muni  pour  qu’une  tâche  puisse  y  être  exécutée.    
Ce  sont  essentiellement  :
l  les  intervenant
l  les  moyens  d’entrée  et  de  sortie  informatiques
l  les  moyens  de  traitement  des  données  (ordinateurs,  micro,  etc.  …)
l  les  logiciels
l  les  ensembles  de  données  stockées  utilisées
l  Une  procédure  (ou  procédure  fonctionnelle,  PF)  est  un  ensemble  logique  de  
tâches  exécutées  consécutivement  par  un  poste  de  travail  .  Elle  est  
ininterruptible
l  Une  tâche  est  une  unité  élémentaire  de  traitement.  Elle  résulte  de  la  décomposition  
organisationnelle  de  l'ʹopération  conceptuelle.  Elle  est  effectuée  par  un  poste  de  travail.
183
Concepts  de  base

l  La  périodicité  (ou  fréquence)  est  la  période  d’exécution  d’une  tâche  sur  un  
poste  de  travail.  Ce[e  indication  répond  à  la  question  QUAND  ?  
l  La  périodicité  définit  l’instant  (aléatoire,  périodique  régulier,  périodique  irrégulier,  plage  de  
temps,  calendaire,  etc.…)  de  déclenchement  d’une  tâche.
l  Les  acteurs  (ou  intervenants)  sont  les  personnes  exécutant  une  procédure  et  
faisant  partie  d’un  poste  de  travail.
l  Le  degré  d’automatisation  est  l’information  qui  décrit  la  nature  de  la  tâche.  
L'ʹexécution  d'ʹune  tâche  utilise  des  ressources  humaines  et  informatiques.  On  
distingue,  pour  exécuter  une  tâche,  la  manière  :
l  manuelle  :  le  traitement  est  réalisé  par  une  ressource  humaine
l  conversationnelle  :  l'ʹexécution  de  la  tâche  est  réalisée  par  un  dialogue  entre  l'ʹhomme  et  la  
machine  grâce  à  une  interface  homme-­‐‑machine  (IHM).  On  parle  aussi  de  tâche  interactive  ou  
en  temps  réel
l  automatique  :  l'ʹexécution  de  la  tâche  est  réalisée  grâce  à  l'ʹinformatique  seule  par  une  procédure
automatisée  et  autonome.  On  parle  de  procédure  en  temps  différé  ou  de  procédure  batch  
184
Correspondance  entre  MCT  et  MOT

Agrégation  d’opérations  en  une  procédure

B C
A B C
B ou C

B ou C
Opération  1
•   Action  1
A D PF •   Action  2

A et D

Opération  2
Résultat

Résultat
Niveau Conceptuel Niveau Organisationnel
185
Correspondance  entre  MCT  et  MOT
Composition  d’une  opération  en  plusieurs  procédures

PF1

Opération  1
PF2

Niveau Conceptuel Niveau Organisationnel


l  Pour  quels  raisons  doit  on  décomposer  :
l  La  tâche  (ou  action)  doit  être  effectuée  de  plusieurs  façons  différentes
§  Manuel,  temps  réel  ou  différé
§  A  chaque  nature  de  travail  correspond  une  procédure  différente
l  Changement  de  lieu,  de  personne  (poste  de  travail)
l  Introduction  d’un  évènement  spécifique  au  niveau  organisationnel  :  délai
186
Correspondance  entre  MCT  et  MOT
Correspondance  Opération/Procédure
l  Chaque  opération  est  effectuée  dans  un  seul  poste  de  travail,  avec  une  seule  nature  de  
traitement.  Il  ne  lui  correspond  qu’une  seule  procédure

Opération  1 PF1 Procédure  1

Niveau Conceptuel Niveau Organisationnel

187
Démarche  de  passage  du  MCT  au  MOT

l  On  étudie  pour  toutes  les  actions  d’une  opération  du  MCT  :
l  Lieu  du  traitement  :  si  plusieurs  lieux  existent,  l’opération  devra  être  
découpée  en  autant  de  procédures
l  Chronologie  :  si  des  actions  ne  peuvent  se  dérouler  consécutivement,  il  y  
aura  lieu  de  faire  plusieurs  procédures
l  Nature  ou  type  :  différée,  manuelle,  temps  réel

188
Etapes  de  construction  d’un  MOT

Les  étapes  de  la  construction  d’un  MOT  sont  :


l  Décomposer  les  opérations  du  MCT  en  sous-­‐‑opérations  appelées  
procédures  fonctionnelles
l  Affecter  et  localiser  chaque  procédure

l  Détailler  l'ʹanalyse  de  chaque  procédure

l  Définir  l'ʹenchaînement  des  procédures

189
Etapes  de  construction  d’un  MOT

Décomposition  des  opérations  du  MCT


l  Pour  chaque  opération  du  MCT,  il  faut  au  préalable  vérifier  l’exhaustivité  du  
recensement  des  tâches.  
l  Regrouper  les  tâches  de  l’opération  en  procédures.  Il  s’agit  de  veiller  au  
respect  des  trois  unités  :  lieu,  temps,  nature  de  traitement

l  Exemple  
l  L'ʹopération  Ouvrir_dossier  peut  être  décomposée  en  les  procédures  
suivantes  :
l  vérifier  la  déclaration  (assuré  connu,  circonstances  bien  décrites  ...)
l  l'ʹignorer  ou  lui  affecter  un  numéro  de  dossier
l  enregistrer  les  informations  nécessaires  dans  la  base
l  désigner  un  expert  pour  le  nouveau  dossier
l  transme[re  le  dossier  à  l'ʹexpert 190
Etapes  de  construction  d’un  MOT

Identification  des  procédures


l  Il  s’agit,  tout  particulièrement,  de  spécifier  pour  chaque  
procédure  son  type  et  son  poste  de  travail.  
l  Pour  chaque  procédure  sont  fournis  :
l  Un  nom
l  Un  mode  de  réalisation  (manuelle,  automatisée  totalement  ou  
partiellement,  interactive,  différée  ...)
l  Une  localisation  (où?)
l  Une  affectation  (qui?)
l  Une  fréquence  d'ʹactivation

191
Etapes  de  construction  d’un  MOT

Identification  des  procédures  (suite)


l  Exemple

192
Etapes  de  construction  d’un  MOT

Analyse  détaillée  des  procédures


l  Décrire  :
l  les  événements  ou  données  nécessaires  au  déclenchement  de  la  procédure  
et  les  résultats  qu'ʹelle  produit
l  les  traitements  effectués  et  les  actions  réalisées  sur  la  base  
l  les  supports  des  données  et  des  résultats  (formulaire  papier,  écrans  de  
dialogue  etc.)

193
Etapes  de  construction  d’un  MOT

Enchaînement  des  procédures


l  Exemple  de  formalisme  du  MOT
Temps                          Enchaînement  des  procédures                                                                                            Nature                    Poste

 date  début    Date  de dossier


inscription début
et
déposé          Manuelle      Guichet

 
PF1                        Vérifier  dossier
5'ʹ
erreur   correct
dossier dossier
incomplet complet

   TR    Guichet
 
PF2                        saisie  élts  dossier
3'ʹ    toujours
 

dossier
enregistré
           Manuelle Guichet
PF3                      écriture  n°  inscript.
 
3'ʹ                                    classement  par  couleur
   
 toujours
194
dossier
trié
Etapes  de  construction  d’un  MOT

l  Il  est  intéressant,  pour  la  compréhension  du  MOT,  d'ʹindiquer  le  
support  du  flux  d'ʹinformations  ou  de  l'ʹévénement  mentionné  :  
l  Pour  les  tâches  issues  de  procédures  TR  (temps  réel),  il  faut  décrire  des  
écrans
l  Pour  les  tâches  éditant  des  états,  décrire  les  maque[es  d’états
l  Pour  les  tâches  automatique,  il  faut  donner  les  segments  de  données  
accédés  en  consultation,  modification,  ajout  ou  suppression  et  préciser  les  
critères  d’accès.
l  Ce[e  étape  est  formalisée  par  une  fiche  descriptive  pour  chaque  
PF.  
l  Les  fiches  descriptives  peuvent  être  aussi  créées  pour  les  postes  
de  travail.
195
Etapes  de  construction  d’un  MOT
l  Exemple  d’une  fiche  descriptive  d’un  PF
n° procédure : PF6

Libellé : Saisie note

Nature : TR

Evénements traités : " retour dossier noté "

Evénements résultants : " notes saisies "

Volume : 2 000 * 2 j = 4 000

Durée : 3' * 4 000 = 12 000' = 200 h

Actions sur la BD : Segment dossier en MAJ 196

Segment Enseignant en MAJ


Conclusion

l  Le  MOT  cerne  l'ʹactivité  de  chaque  poste  de  travail  (informatique  ou  non),  et  
de  chaque  service,  en  tenant  compte  du  "ʺplanning"ʺ,  du  type  de  ressources  
(manuel,  automatisé),  du  type  de  support  (document  écrit,  magnétique  etc.)  
l  Ce[e  représentation  est  donc  détaillée  et  très  concrète,  et  les  symboles  
graphiques  utilisés  peuvent  être  influencés  par  le  contexte.  
l  Les  fiches  descriptives  qui  doivent  accompagner  chaque  PF  détaillent  les  
règles  de  synchronisation  et  d'ʹémission.  Elles  constituent  donc  une  première  
ébauche  des  algorithmes  essentiels  pour  les  PF  appelées  à  être  informatisées

197
Inscription à un établissement Universitaire : Exercice MOT

Consignes d ’organisation : Informatique centralisée . à faire :


Travail
- tableau de détermination des procédures
l  .   Les   candidats   déposent   les   dossiers   à   un   guichet   de   - M.O.T.
réception  qui  vérifie  leur  contenu  et  les  enregistrent  sous  un   - Fiche descriptive de la PF « saisie des notes »
numéro  d  ’inscription  s  ’ils  sont  complets.  Il  transmet  tous  les  
soirs  les  dossiers  à  chaque  département        (  tri  par  couleur  de  
la  chemise  ).
MCC Dossier déposé
l                Tous   les   matins   le   secrétariat   de   chaque   département  
Refus notifié
reçoit   les   dossiers   et   les   répartit   par   paquet   de   dix.   Ceux-­‐‑ci  
sont  ventilés  vers  les  enseignants  qui  ont  deux  jours  pour  les   Avis d ’admissibilité envoyé
examiner   et   donner   une   note.   Le   secrétariat   saisit   alors  
Avis d ’admission définitif
chaque   note   ,   puis   ventile   les   dossiers   vers   d   ’autres   Inscription
enseignants  de  façon  à  obtenir  une  deuxième  notation  qui  est   Candidat
à  son  tour  saisie.  
à un Collante reçue
établissementDemande d ’inscription déposée
l                Chaque   fin   de   semaine   pour   les   dossiers   possédant   2  
notes   ,   la   moyenne   est   calculée   et   un   écart   supérieur   de   2   universitaire
Avis d ’inscription envoyé
points   entre   les   deux   notes   fait   sortir   les   dossiers   en  
anomalie.   Celui-­‐‑ci   doit   être   examiné   de   nouveau   jusqu’à   Dossier refusé déposé trop tard

obtenir  un  consensus.


dossier Avis
l                 A  la  date  de  clôture  des  dossiers  ,  le  secrétariat  envoie  les   Refus déposé
notifié admissibilité
réponses   aux   candidats   :   ceux   qui   ont   une   moyenne   envoyé
supérieure   à   10   reçoivent   une   letre   d   ’admissibilité   ,   les  
autres  une  letre  de  refus.  Les  candidats  déjà  bacheliers  ayant   dossier
la   moyenne   reçoivent   une   letre   d   ’admission   définitive   (   =   refusé Collante
demande  d’inscription  ).   reçue

ou
Graphe de Précédence
l                 Les  candidats  admissibles  apportent  leur  «  collante  »  au   Avis
secrétariat   qui   enregistre   leur   réussite   au   bac   et   leur   donne   Evénements temporels d ’admission
définitive
une   demande   d   ’inscription   portant   le   même   numéro   que   le   D1 : date début période dépôt dossier
D2 : date fin période dépôt dossier
dossier. D3 : date clôture inscriptions
l                 Les  candidats  doivent  alors  payer  leurs  droits  à  la  caisse   avis demande
d ’inscription d ’inscription
de  l  ’établissement  et  y  déposer  leur  demande  d  ’inscription  
envoyé déposée
correctement  remplie.  Leur  inscription  est  alors  définitive
Dossier
   Date  de déposé
Exercice    MOT  :       début
Inscription  Universitaire
 et

Examen    dossiers
avis
accepté admissibilité
date collante
TJ   clôture  
refusé
bac                    bac

 et
dossier
refusé
date Admission
refus définitive
notifié
toujours

avis  admission
définitive
demande    Date  de
inscription  clôture
inscription

 et
 et
 clôture
 inscription inscriptions

 toujours
 toujours

avis
candidat
d'ʹ  inscription
forclos