Cours 09 DFD

Systèmes d’information dans
les entreprises (GTI515)

Chargé: JF Couturier
Cours 9
MTI515 Automne 2013 JF Couturier 1

Département de génie logiciel et des TI
Retour sur les dernier cours
 Énoncé de laboratoire
 Type de processus d’affaires
 BPM
 Modélisation, mesure, optimisation
 BPMN
 Workflow patterns

Plan du cours
 Le diagramme de flux de données
 Les différents niveaux
 Exemples de DFD
 Les règles
 Exemples d’erreurs
 Étude de cas
 Transition vers L’ERD
 Dictionnaire de données
Bilan
 Processus d’affaires – BPMN ou UML
 Vision
 Modèle du domaine
 Diagramme des CU
 Cas d’utilisation
 Archétypes et stéréotypes
 SRS – Exigences
Avons-nous…
 Oublié quelque chose?
 …analyser les données?
 Nous avons observé la séquence des
actions d’un point de vue
comportementales.
 Nous avons peut-être identifié les
principaux éléments dans le
diagramme d’activité
Le DFD - Data-Flow Diagram
 Diagramme de flux de données
 L’une des méthodes disponibles pour analyser les
systèmes orientées données.
 Le DFD met l’emphase sur la logique du système étudié.
 Les analystes systèmes peuvent représenter
graphiquement les mouvement de données à l’intérieur
de l’organisation
 Le DFD est une représentation populaire dans la
représentation et la modélisation des flux de données.

Petit retour en arrière
 Avant l’analyse et le design orientée
objet (OOAD) il y avait…
 Structured Analysis And Design
 DFD  Processus
 ERD  Modèle de données
 Dictionnaire de données  Description
 Toujours utilisées, peut s’avérer très utile
de pouvoir décoder ces notations

Avantage du DFD
 Par rapport à une narration des
mouvements de données
 Compréhension des interrelations entre
les systèmes et les sous systèmes
 Documenter ce que système actuel
connait
 Analyser le système proposé

DFD vs le cas d’utilisation
 Le cas d’utilisation décrit les
interactions entre le système et un
acteur (généralement)
 Le cas d’utilisation n’explique pas d’où
viennent les données
 Par contre le CU fournit de précieuses
informations pour créer le DFD

Limite du DFD
 Le DFD ne représente pas les décisions ou
les évènements dans le temps.
 La fonction du DFD est d’illustrer les sources
de données, les destinations, les flux, les
magasins de données et les
transformations faites aux données.

Limite du DFD
 Si vous devez modéliser un système qui
servira d’entrepôt de données, le DFD ne
vous sera pas très utile.
 Peu ou pas de processus à documenter
 Dans ce cas, un ERD risque d’être plus
intéressant.
 In contrario, le ERD n’illustre pas les
transformations que l’on retrouve
normalement dans un processus

Notation
 Gane et Sarson
 "Structured Systems Analysis: Tools and
Techniques", by C. Gane and T. Sarson
(New York: IST, Inc., 1977)”
 DeMarco et Yourdon
 DeMarco. Structured Analysis and
System Specification,Prentice Hall,1979.
 Yourdon. Modern Structured Analysis,
Yourdon Press Computing Series,1988
Dennis, Alan R., Barbara Haley Wixom, and David Tegarden. "Chapter 8 - Moving on to Design".
Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, Third
Edition. John Wiley & Sons. © 2009. Books24x7.
<http://common.books24x7.com/book/id_29675/book.asp> (accessed May 29, 2009)

Process - Processus
 Dans le DFD
 Des instructions pas à pas qui
transforment des entrées en sorties.
 Travail accompli par un ordinateur, une
personne ou les deux
Satzinger et al. Analyse et conception de systèmes d’information, p.196

Processus
 Quelques exemples de processus valides
 Exécuter un calcul (i.e., moyenne, écart-type)
 Prendre des décisions (i.e., Déterminer la disponibilité d’un
produit)
 Trier, filtrer et autre opérations de groupe sur les données
 Organiser les données dans une forme intéressante (i.e.,
générer un rapport, répondre à une question)
 Déclencher d’autres processus (i.e. Ouvrir le four, commander
un robot)
 Utiliser des données emmagasinées (CRUD)
http://facweb.cs.depaul.edu/yele/Course/IT215/DFD%20Mechanics.ppt

Data flow – flot de données
 Données se déplaçant d’un endroit à
un autre, comme une entrée / sortie,
vers un processus.
 Données sur une personne, une place
ou une chose qui se déplacent dans le
système.
 Le nom du flot doit représenter le
mouvement dans le système.

Data store – Magasin de données
 Données au repos, stockées pour un usage

ultérieur. Correspond généralement à une entité de
donnée sur un diagramme entité-relation.
 Interne au système
 Le magasin de données peut prendre plusieurs
formes:
 Documents physiques
 Document informatisés
 Calepins
 On identifie généralement les magasin de données
à l’aide d’une référence unique du type D1, D2, D3

Entité externe
 Source ou destination des données hors du
système.
 Personnes, système ou base de données
externes
 Se trouve à l’extérieur du système tout en
interagissant avec lui
 Reçoit de l’information du système, fournit
de l’information au système ou déclenche
des actions

Dennis, Alan R., Barbara Haley Wixom, and David Tegarden. "Chapter 8 - Moving on to Design".
Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, Third
Edition. John Wiley & Sons. © 2009. Books24x7.
<http://common.books24x7.com/book/id_29675/book.asp> (accessed May 29, 2009)

Plan du cours
 Exemples de DFD
 Les règles
 Études de cas
Les
différents
niveaux
Dennis, Alan R., Barbara Haley Wixom, and David Tegarden. "Chapter 8 -
Moving on to Design". Systems Analysis and Design with UML Version
2.0: An Object-Oriented Approach, Third Edition. John Wiley & Sons. ©
2009. Books24x7.
<http://common.books24x7.com/book/id_29675/book.asp> (accessed May
29, 2009)

Le niveau du contexte
 Contient uniquement un processus
représentant l’ensemble du système.
 On donne à ce processus le numéro zéro.
Ne pas confondre avec le niveau 0.
 Tous les agents externes sont représentés
dans le diagramme de contexte, ainsi que
les flots de données majeurs.
 Le diagramme de contexte ne contient
aucun magasin de données.

Le niveau 0
 Le diagramme 0 est l’explosion du diagramme
contextuel.
 Devrait inclure de 3 à 9 processus.
 Davantage de processus risque de nuire à la
compréhension.
 Les processus sont numérotés avec un entier.
 Les principaux magasin de données et toutes les
agents externes sont représentés dans le
diagramme 0.
 Un processus par PMÉ
 Un processus par cas d’utilisation

Le niveau 0
 On constate qu’au niveau 0, on retrouve tous les agents
externes et tous les flux de données du diagramme contextuel
 On a ajouté un magasin de donnée, 3 processus (1, 2, 3) et 2
nouveau flux de données (A et B)
 L’équilibre entre les niveaux doit être maintenu. Au niveau
contextuel, nous avons les liens Z, Y, Z. On les retrouvent tous
au niveau 1. Nous avons en plus les liens A, B, M, N
Dennis, Alan R., Barbara Haley Wixom, and David

Tegarden. "Chapter 8 - Moving on to Design".
Systems Analysis and Design with UML Version 2.0:
An Object-Oriented Approach, Third Edition. John
Wiley & Sons. © 2009. Books24x7.
<http://common.books24x7.com/book/id_29675/boo
k.asp> (accessed May 29, 2009)

Le niveau 1
 On augmente le niveau de détail d’un cran
 En général, chaque processus au niveau 0 sera décomposé
au niveau 1. Dans ce cas-ci nous aurions 3 diagrammes de
niveau 1 pour les processus 1, 2 et 3
 La numérotation suit une logique 2  2.1, 2.2, 2.3


Le niveau 1
 L’équilibre entre les niveau doit être
maintenu. Au niveau 0, nous avons les
liens M, N, Y, B et A pour le processus 2.
On les retrouvent tous au niveau 1. Nous
avons en plus les liens C, G, H, J, K.
 Pour savoir d’où vient B et où vont A et Y,
nous devons remonter d’un niveau.
 Intéressant mais peut rapidement devenir
fastidieux. Pour éviter cela, l’approche
suggérée est d’ajouter les entités externes
dans les niveaux inférieurs.
 Détail du cas d’utilisation, chaque étape Dennis, Alan R., Barbara Haley Wixom, and David
devient un processus An Object-Oriented Approach, Third Edition. John

Le niveau 2 et suivants…
 Nous pouvons continuer à détailler nos processus d’un niveau
à un autre.
 Pour identifier à quel niveau nous nous trouvons, identifier le
nombre de chiffres après le premier point.
 Conserver l’équilibre entre chaque niveau
 Dans ce cas-ci
 M, N, K, H, G, C


Les étapes pour créer le DFD
 Créer un DFD est un travail itératif avec des
améliorations continues
 Les étapes
1. Créer un diagramme contextuel
2. Identifier les Cas d’utilisation (!), là où les utilisateurs
utilisent le système
3. Créer un fragment de DFD pour chaque cas d’utilisation
4. Créer un diagramme de niveau 0 pour chaque fragment
5. Décomposer au niveau 1, 2, …
6. Revenir à l’étape 1 et réviser si nécessaire
7. Valider le DFD avec les utilisateurs
Plan du cours
 Les règles
 Exemples de DFD
 Études de cas
Exemples de DFD

Exemples de DFD

Exemples de DFD
http://venki5014.files.wordpress.com/2008/08/dfd-1.jpg

Exemples de DFD
http://venki5014.files.wordpress.com/2008/08/praneeth-sdo-dfd-22.jpg

Niveau contextuel
Systems Analysis and Design with UML

Version 2.0: An Object-Oriented
Approach, Third Edition by Alan R.
Dennis, Barbara Haley Wixom and David
Tegarden

Niveau 0

Tegarden

Niveau 1

Tegarden

Plan du cours
 Exemples de DFD
 Les règles
 Études de cas
Quelques règles
 Règles qui s’appliquent à tous les DFD
 Les intrants d’un processus sont toujours
différents des extrants
 Les objets (éléments) du DFD ont tous
un nom unique
 Par souci de clarté, vous pouvez utiliser
plusieurs fois les magasins de données et
les agents externes dans un même
diagramme.

Quelques règles
 Processus  Magasin de données
 Ne peut pas avoir  Les données ne
peuvent se déplacer
que des extrants d’un magasin à un
 Ne peut pas avoir autre.
que des intrants  Les données ne
peuvent aller ni venir
 Un processus est directement d’une
libellé avec un source externe
verbe  Un magasin de
données est libellé par
un nom.

Quelques règles
 Agents externes  Flux de données
 Les données ne  Un flux de données
n’a qu’une seule
peuvent se direction
déplacer entre
 Un flux de données
agents externes. est libellé par un nom.
 Les agents  Un flux de données ne
externes sont peut pointer
libellé par un nom. directement sur le
processus d’origine.

Quelques règles
 Flux de données (Suite)
 Un flux de données qui se dirigent vers un
magasin de données implique une mise à jour
(update)
 Un flux de données provenant d’un magasin de
données implique une récupération ou une
utilisation (retrieve)

Quelques règles
 Diagramme de contexte
 1 processus, numéroté 0
 Les agents externes
 Les principaux flux de données
 Pas de magasin de données
 Ils sont internes au système
 Les magasin de données externe sont représentés
comme des agents externes
 Comment départagez-vous ce qui est interne de ce
qui est externe?

Quelques règles
 Un DFD ne représente pas les
décisions
 Un DFD ne représente pas les
évènements dans le temps
 Le DFD ne représente pas la séquence
 Un diagramme BPMN ou un
diagramme d’activité fait ce travail.

Plan du cours
 Exemples de DFD
 Les règles
 Études de cas
Erreurs communes
 Erreurs de flux de données
 Un flux de données ne peut avoir 2 directions
 Un flux de données ne peut pointer sur le processus d’origine
 Un flux de données n’ayant pas de source
 Un flux de données n’ayant pas de destination
 Un flux de données doit être libellé avec un nom, pas un verbe
 Erreurs de connexions
 Les données ne peuvent se déplacer directement d’un magasin
à un agent externe
 Les données ne peuvent se déplacer d’un magasin à un autre.

Exemples d’erreurs
 Un processus ne peut pas avoir que des flux
entrants (blackhole)
 Un processus ne peut pas avoir que des flux
sortants (miracle)
1 2
Add Add
New New
Customer Customer

 Les magasins de données et les
entités externes ne peuvent êtres reliés
directement
Customer D1 Customer
Vendor D2 Vendor Master

 Libellé incorrectement les flux de données
ou les objets du DFD
 Exemples d’erreurs
 Libellés absents pour les flux et les objets du DFD
 Flux de données libellé avec un verbe
 Processus libellé avec un nom
 Trop de processus ou de flux de données

dans un diagramme.
 Une dizaine au maximum

 Omettre les flux de données dans le
diagramme
 Décomposition déséquilibrée entre un
processus parent et un diagramme
enfant.
 Les flux de données du parents
devraient se retrouver dans le
diagramme enfant

Qualités d’un DFD
 Lisible
 Minimiser la complexité
 Cohérent et balancer/équilibrer
 Représente précisément les exigences du système
 Réduire la surcharge d’information – règle du 7 +/- 2
 Un DFD ne devrait pas avoir plus de 7 +/-2 processus
 Pas plus de 7 +/- 2 flux de données ne devrait entrer ou
sortir d’un processus ou d’un magasin de données dans
un seul DFD

Plan du cours
 Exemples de DFD
 Les règles
 Études de cas
Étude de cas
 Faites le DFD pour le garage
 PMÉ :
 Prendre RV, Écrire DS, Écrire BT, Réparer
la voiture
 Données
 BT, DS, Client, Facture, RV
 Participants
 Client, Garagiste, Chef de service, Chef
d’atelier
Plan du cours
 Les règles
 Exemples de DFD
 Études de cas
Avec le DFD…
 On commence le ERD
 Entity-Relationships Diagram
 Ce que l’ER couvre
 Les liens entre les données
 La création des tables
 Leurs différents attributs, les types, les contraintes
référentielles
 Ce que l’ER ne couvre pas

 Les états et les transformations des données
ERD
 Le diagramme entité-relation nous
permet de conceptualiser la couche de
persistance.
 Le diagramme entité-relation reprend
souvent plusieurs éléments du modèle
du domaine.
 Cependant, certaines transformations
seront souvent nécessaires.
Persistance
 Lorsque vous utilisez une couche de
persistance orientée objet, c’est
souvent le framework qui va organisé
la structure des tables (hibernate)
 Si vous utilisez une couche de
persistance relationnelle, vous devez
programmer une couche d’accès aux
données qui fera la liaison avec vos
objets
Étapes pour faire le ERD
 Vous récupérer les entités identifiées dans le
modèle du domaine ainsi que dans le DFD.
 Incluant les attributs et leurs types
 Vous considérer les liens unissant ces
entités
 Vous identifier les cardinalités (souvent déjà
présentes dans le modèle du domaine)

Les types d’association
 Relation 1 à 1(1:1)
 Relation 1 à plusieurs (1:M)
 Relation plusieurs à plusieurs (M:N)
 Nécessité d’avoir une entité
d’association…Classe d’association!

Les formes normales
 Une fois que vos entités et leurs
relations ont été identifiés, vous pouvez
appliquez les 3 formes normales
 Les 3 formes normales sont des règles
de conceptions dans la réalisation des
tables relationnelles.

1er forme normale
 Une table est à la première forme
normale (1NF) si elle ne contient pas
de groupes répétitif de données.
http://fr.wikipedia.org/wiki/Forme_normale_(bases_de_donn%C3%A9es_relationnelles)

2ème forme normale
 tous les attributs non-clés ne
dépendent pas d'une partie de la clé
primaire mais bien de la totalité de la
clé primaire.

3ème forme normale
 Tous les attributs n'appartenant pas à
la clé ne dépendent pas d'un attribut
non-clé. En d'autres termes, la
dépendance fonctionnelle est directe.

Créer la base de données
 Une fois que vous avez créer votre
ERD et que les 3 formes normales ont
été appliquées, vous êtes en mesure
de créer votre base de données
 ou votre schéma, selon la terminologie
de votre SGBD

Exemple
 Voir un exemple de ERD

Plan du cours
 Les règles
 Exemples de DFD
 Études de cas
Dictionnaire de données
 Dictionaries are like watches; the worst
is better than none, and the best
cannot be expected to go quite true.”
Mrs. Priozzi Anecdotes of Samuel
Johnson, 1786

 Le dictionnaire de données est un document
qui accompagne généralement la
documentation d’un système
 Documente les tables, les vues, les
procédures stockées de la couche de
persistance d’un système
 Dans le dictionnaire de données, nous
pouvons également documenter des
contraintes métiers.

Échange de données
 Le dictionnaire de données sera
particulièrement utile lorsque on veut
échanger des données.
 Il permet de standardiser la
sémantique du domaine métier d’une
organisation  Glossaire

 Certains SGBD permettent de
documenter les champs d’une tables
(SQL Server entre autres)
 On peut alors exécuter des vues
affichant un rapport, par table et par
champs.
 Un fichier Excel peut tout aussi bien
faire l’affaire
 On annexera souvent au dictionnaire
de données un ERD pour visualiser les
liens entre les tables
 Dans les gros systèmes, l’ERD peut
devenir difficile à lire, il faut alors le
segmenter

Exemples
 Voir exemples de DD
 Un autre exemple

Ressources
 DFD
 Gane-Sarson et DeMarco-Yourdon
 ERD
 Wiki de Yourdon
 Data dictionary

Prochain cours
 Normes et cadriciels
 Lectures
 À venir


Langue

Cours 09 DFD

Transféré par

Informations du document

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Cours 09 DFD

Transféré par

Droits d'auteur :

Systèmes d’information dans

les entreprises (GTI515)

MTI515 Automne 2013 JF Couturier 1

MTI515 Automne 2013 JF Couturier 2

MTI515 Automne 2013 JF Couturier 6

MTI515 Automne 2013 JF Couturier 7

MTI515 Automne 2013 JF Couturier 8

MTI515 Automne 2013 JF Couturier 9

MTI515 Automne 2013 JF Couturier 10

MTI515 Automne 2013 JF Couturier 11

MTI515 Automne 2013 JF Couturier 13

Satzinger et al. Analyse et conception de systèmes d’information, p.196

MTI515 Automne 2013 JF Couturier 14

MTI515 Automne 2013 JF Couturier 15

Satzinger et al. Analyse et conception de systèmes d’information, p.196

MTI515 Automne 2013 JF Couturier 16

 Données au repos, stockées pour un usage

MTI515 Automne 2013 JF Couturier 17

MTI515 Automne 2013 JF Couturier 18

MTI515 Automne 2013 JF Couturier 19

MTI515 Automne 2013 JF Couturier 21

MTI515 Automne 2013 JF Couturier 22

MTI515 Automne 2013 JF Couturier 23

Dennis, Alan R., Barbara Haley Wixom, and David

MTI515 Automne 2013 JF Couturier 24

Dennis, Alan R., Barbara Haley Wixom, and David

MTI515 Automne 2013 JF Couturier 25

MTI515 Automne 2013 JF Couturier 26

Dennis, Alan R., Barbara Haley Wixom, and David

MTI515 Automne 2013 JF Couturier 27

MTI515 Automne 2013 JF Couturier 30

MTI515 Automne 2013 JF Couturier 31

MTI515 Automne 2013 JF Couturier 32

MTI515 Automne 2013 JF Couturier 33

Systems Analysis and Design with UML

MTI515 Automne 2013 JF Couturier 34

Systems Analysis and Design with UML

MTI515 Automne 2013 JF Couturier 35

Systems Analysis and Design with UML

MTI515 Automne 2013 JF Couturier 36

MTI515 Automne 2013 JF Couturier 38

MTI515 Automne 2013 JF Couturier 39

MTI515 Automne 2013 JF Couturier 40

MTI515 Automne 2013 JF Couturier 41

MTI515 Automne 2013 JF Couturier 42

MTI515 Automne 2013 JF Couturier 43

MTI515 Automne 2013 JF Couturier 45

MTI515 Automne 2013 JF Couturier 47

Vendor D2 Vendor Master

MTI515 Automne 2013 JF Couturier 48

 Trop de processus ou de flux de données

MTI515 Automne 2013 JF Couturier 49

MTI515 Automne 2013 JF Couturier 50

MTI515 Automne 2013 JF Couturier 51

 Ce que l’ER ne couvre pas

MTI515 Automne 2013 JF Couturier 58

MTI515 Automne 2013 JF Couturier 59

MTI515 Automne 2013 JF Couturier 60

MTI515 Automne 2013 JF Couturier 61

MTI515 Automne 2013 JF Couturier 62

MTI515 Automne 2013 JF Couturier 63

MTI515 Automne 2013 JF Couturier 64

MTI515 Automne 2013 JF Couturier 65

MTI515 Automne 2013 JF Couturier 68

MTI515 Automne 2013 JF Couturier 69

MTI515 Automne 2013 JF Couturier 70