|
|
|
Les diagrammes de flux de données, DFD, permettent de modéliser la manière
dont les traitements utilisent les données au niveau conceptuel. Dans la
terminologie des DFD, les traitements sont appelés Fonctions et les
données sont appelées Entrepôts de données.
Dans une approche top/down d'analyse des systèmes d'information, les fonctions
correspondent aux processus de traitement de données de la modélisation
des processus métier effectuée avec Process Modeler.
Les entrepôts de données s'apparentent aux entités et permettent de faire le
lien avec la modélisation des données
effectuée avec Entity Relationshipe Diagrammer.
La modélisation des flux de données, avec Dataflow
Diagrammer, et des données, avec Entity Relationshipe Diagrammer, se
fait, usuellement, sous forme d'allers-retours entre les 2 points de vue. Les 2
outils de modélisation, respectivement les 2 modèles, se complètent et
permettent de construire des spécifications de systèmes informatiques dont les
aspects statiques et dynamiques sont contrôlés et validés l'un par rapport à
l'autre.
Voir cahier 25 Matrix Diagrammer
pour optimiser la vérification de couplage entre données et traitements
Un diagramme de flux de données, DFD, est toujours construit en tant qu'élément descriptif d'une fonction. Oracle parle de fonction frontière, Frame Function, pour indiquer la fonction sur laquelle un diagramme est basé.
|
Les flèches en rouge, représentent les flux de données entrant ou sortant du sous -système d'information de l'entreprise vue comme un système |
Dans un premier temps, la modélisation des processus avec Process Modeler permet de comprendre le métier et les activités menées par les entreprises. Le cadre de réflexion est l'entreprise dans son ensemble; c'est-à-dire, en prenant en compte ses trois sous-systèmes: système opérant, système de pilotage et système d'information.
Dans un deuxième temps, la modélisation des flux de données avec Dataflow
Diagrammer permet de comprendre ou spécifier le fonctionnement du système
d'information.
La compréhension du système d'information implique l'identification des flux
d'informations échangés avec son environnement; ensuite, le système
d'information doit être étudié en tant qu'entrepôts de données, de
traitements de données et de flux de données internes et externes.
Si le contexte de l'entreprise est compris et connu de l'analyste, l'étude du système d'information peut se faire en occultant la modélisation des processus métier.
Rappel:
Une entreprise est un système complexe qui peut être compris à l’aide de la systémique; ce système-entreprise peut être décomposé en trois sous-systèmes : le sous-système opérant (SO) ; le sous-système de pilotage (SP) et le sous-système d’information (SI).
Le sous-système opérant ou technologique active les processus métier de l’entreprise pour créer la valeur ajoutée; le sous-système de pilotage ou de décision coordonne l’ensemble de l’activité en fonction des objectifs ; le sous-système d'information ou de mesure décrit, mémorise et capte l'ensemble des événements et des transformations caractéristiques à la fois du sous-système de décision et du sous-système d'opération (base d'information, entrée, sortie, traitement).
|
|
Une fonction peut être vue de manière macroscopique comme une boîte noire ou de manière microscopique comme une boîte dont l'intérieur est décrit.
La décomposition d'une fonction en plusieurs sous-fonctions nous permet d'atteindre plusieurs objectifs prônés par les approches méthodologiques d'ingénierie des systèmes d'information:
- la complexité peut être abordée en faisant des allers-retours entre la vison globale et l'étude des éléments; dans notre cas, il s'agit d'allers-retours entre fonction et sous-fonctions;
- la représentation doit se faire sous forme de niveaux montrant plus ou moins de détails selon les besoins spécifiques de communication; pour l'exemple ci-dessus, il ne sera certainement pas nécessaire de montrer le détail de la fonction
|
|
| Elément | Description |
| External
Acteur externe |
Un acteur externe est situé à l'extérieur de la fonction
frontière. Il représente l'environnement de la fonction frontière. Un acteur externe est la source et/ou le destinataire de flux de données avec la fonction frontière et/ou ses éléments. Un acteur externe peut être une personne, une unité d'organisation ou n'importe quelle autre "chose" qui peut émettre ou recevoir de l'information d'une fonction interne à un conteneur (fonction frontière). |
| Function
Fonction frontière |
Une fonction est un élément de traitement des données transportées par les flux de données. |
| DataFlow
Flux de données |
Un flux de données représente le lien dynamique entre les
éléments d'un diagramme; ce lien se matérialise par un transfert de données
dans le sens indiqué par la flèche. Un flux de données doit impérativement aboutir et/ou partir d'une fonction. |
| Datatore
Entrepôt de données |
Un entrepôt de données est une collection de données temporaire ou permanent utilisée
par une fonction. La collection de données peut être des attributs d'entités ou des conteneurs, items, non classifiés. |
|
|
|
|
|
|
|
|
|
|
|
|
Oracle a créé trois classificateurs pour les fonctions.
| Frame function
Fonction frontière |
Le terme de fonction frontière ou Frame function est
utilisé par Oracle pour décrire la fonction sur laquelle un diagramme de
flux de données, DFD, est basé. Les fonctions internes à la fonction
frontière sont nommées locales et les fonctions situées à l'extérieur
de la fonction frontière sont nommées globales. |
| Local function Fonction locale |
Le terme de fonction locale ou Local function est
utilisé par Oracle pour décrire les fonctions qui sont représentées à
l'intérieur d'une fonction frontière; les fonctions locales sont des
enfants de la fonction frontière qui les accueille. |
| Global function Fonction globale |
Le terme de fonction globale ou Global function est
utilisé par Oracle pour décrire les fonctions qui sont représentées à
l'extérieur d'une fonction frontière; les fonctions globales ne sont pas
enfants de la fonction frontière qui supporte le diagramme. |
| Commun function (Master function) Fonction commune |
Le terme de fonction commune ou Common function est
utilisé par Oracle pour décrire les fonctions qui sont utilisées comme
parties de hiérarchie de plusieurs fonctions. Les fonctions communes sont
créées par référence à une fonction maîtresse, Master function;
seule la fonction maîtresse peut être spécifiée et détaillée. |
|
|
|
|
|
|
|
Oracle a créé trois classificateurs pour les flux de données.
| Flow Flux (de données) |
Le terme de flux ou Flow est
utilisé par Oracle pour décrire un flux de données "normal";
c'est-à-dire, un flux de données qui ne part et/ou n'aboutit qu'à des
fonctions locales. |
| Resolved flow Flux (de données) résolu |
Le terme de flux résolu ou Resolved flow est
utilisé par Oracle pour décrire un flux de données lié à une ou
des fonction(s)
de niveau(x) inférieur(s) aux fonctions locales.
Un flux résolu n'est qu'une représentation particulière d'un flux normal; le concepteur ne crée pas de flux résolu. Un flux résolu est dessiné en traits-tillés. Un flux résolu peut être une agrégation de plusieurs flux
"normaux". |
| Global flow Flux (de données) global |
Le terme de flux global ou Global flow est
utilisé par Oracle pour décrire un flux de données entre une fonction
globale et d'autres éléments qui sont à l'extérieur de la fonction
frontière.
Un flux global n'est qu'une représentation dans un contexte
particulier d'un flux normal; le concepteur ne crée pas de flux global. |
|
|
Un processus métier de Process modeler et une fonction de Dataflow
diagrammer sont tous deux des objets de nature identique intitulés, Business
function, dans le référentiel de Designer. Simplement, chacun des
deux outils de modélisation en montre des aspects particuliers.
Pour l'aspect métier, sont mis en évidence des éléments organisationnels
comme des délais ou des coûts; pour l'aspect du système d'information, sont
mis en évidence des caractéristiques informatiques comme les entités et
attributs utilisés.
Un entrepôt ou Store de Process Modeler et un entrepôt ou Datastore de Dataflow Diagrammer sont également tous deux des
objets de nature identique dans le référentiel de Designer.
Pour l'aspect métier, un entrepôt, peut être de nature matérielle ou
physique alors que pour l'aspect du système d'information, un entrepôt ne peut
contenir que des données.
|
Transition entre processus métier et fonction "informatique" |
|
|
Pour de la modélisation de flux de données deux démarches sont possibles.
- Une modélisation des processus métiers de l'entreprise a été
effectuée; dès lors, les processus, les entrepôts et les flux qui ont
trait aux données peuvent être intégrés et vus à l'éclairage de leur
appartenance au système d'information ou à ses canaux de communication.
Naturellement, dans un souci d'affinement de la compréhension du système d'information, des fonctions, entrepôts et flux de données peuvent être créés pour ce seul besoin. - Les processus métiers n'ont pas été modélisés; dès lors, tous les éléments de modélisation, fonctions, entrepôts et flux de données doivent être créés.
Certains processus métier comme "Préparer commande" comportent
des étapes "matérielles" et d'autres de traitement de données. Pour
notre exemple, une étape "matérielle" peut être de sortir les
produits du magasin et les mettre dans un bac qui sera envoyé à l'expédition;
une étape de traitement de commande peut consister à lire une commande ou
créer un bulletin de livraison.
Lors de la reprise de processus métier en fonction de DFD, seules les étapes
de traitement de données seront mises en évidences; les étapes
"matérielles" seront ignorées tout comme les entrepôts et flux
matériels.
|
|
| Propriété | Signification |
| Elementary | Une fonction élémentaire est une opération, transaction,
qui ne peut pas être interrompue. Cette propriété est essentielle car elle est utilisée par l'outil de transformation des fonctions en modules pour déterminer les fonctions qui doivent générer un module. Voir l'assistant de transformation des DFD en MLT |
| Atomic | Mis à jour par Designer; indique qu'une fonction ne peut
plus être décomposée. Les fonctions atomiques sont les feuilles de l'arborescence de fonctions. Voir diagrammes de hiérarchie de fonctions |
| To be automated | Indique que la fonction doit être automatisée ou informatisée; cette propriété ne sert que de documentation, elle n'est pas interprétée par l'assistant de transformation de fonctions en modules. |
|
|
Selon les concepts théoriques de la modélisation des flux de données, la définition de manipulation ou d'utilisation d'entités de données se fait par l'intermédiaire de l'utilisation des entrepôts de données. Un entrepôt de données devrait être associé à une entité; ainsi, par transitivité, la manipulation de données des fonctions est définie par les flux allant ou venant des entrepôts de données.
Designer d'Oracle permet naturellement d'effectuer cette association entre entités d'une part et entrepôts de données et flux de données d'autre part. Toutefois, dans la vision de transformation automatique par Application Design Transformer, de fonctions en modules, l'utilisation des entités par les fonctions doit être spécifiée au niveau des propriétés des fonctions.
Remarque pratique: Souvent en modélisation des processus nous nommons le processus de manière spécifique comme "Enregistrer commande" ou "Saisir nouveau client" alors qu'ensuite au niveau des fonctions du SI nous prévoierons une utilisation plus générale des entités; par exemple, le processus métier "Saisir nouveau client" deviendra une fonction de gestion des clients qui permettra la recherche, l'insertion, la modification ou encore la suppression de clients.
|
|
Designer ne nous permet pas de définir l'utilisation d'associations qui lient les entités.
Ainsi, dans l'exemple ci-dessus, nous ne pouvons pas spécifier que nous souhaitons utiliser l'association existant entre COMMANDE et CLIENT; cette association nous permet de référencer le client qui passe une commande.
Pour contourner ce problème, nous procédons en 2 phases:
- En modélisation des fonctions, DFD, nous indiquons les entités référencées en tant qu'utilisation d'entité avec l'affichage ou l'interrogation, propriété Retrieve, comme seules opérations possibles.
- Plus tard, en enrichissement des modules, nous établirons le lien de référence.
|
|
L'impossibilité de définir une association entre entités comme nous venons de le voir ne nous permet pas de montrer un lien maître et détails.
Ainsi dans l'exemple ci-dessus, nous ne pouvons pas spécifier que notre fonction ne manipule pas toutes les occurrences de LIGNECOMMANDE mais, seulement celles de l'occurrence de COMMANDE sélectionnée.
Comme pour le cas précédent, nous définissons l'utilisation des deux entités COMMANDE et LIGNECOMMANDE; ensuite, nous pourrons spécifier cette relation maître/détails lors de l'enrichissement des modules.
|
|
Le raisonnement précédent, relatif aux entités, s'applique à l'identique aux attributs d'entités.