[Précédente] [Index] [Remonter] [Suivante]        [Portail du laboratoire de génie logiciel]

Buts

  • Vision du système d'information des entreprises

  • Couplage données et traitement au niveau conceptuel

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é.

Entreprise et système d'information

 

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).

 

Niveaux

 

  • Décomposition d'une fonction en sous-fonctions "internes"

    • Diviser pour régner

    • Niveaux d'abstraction

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 Demander informations au client pour en comprendre les lignes principales du traitement des commandes, par contre, ce sera absolument nécessaire pour comprendre le détail de l'enregistrement d'une commande dans le système informatique.

Symbolisme

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.

Classification des fonctions

Frame function

Fonction frontière, cadre d'un DFD

Local function

Fonction interne à une fonction frontière
Sous-fonction

 

Global function

Fonction globale, elle est représentée à l'extérieur d'une fonction frontière

 

Common function

Fonction commune, elle est utilisée à l'intérieur de plusieurs fonctions frontière

 

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.

Classification des flux de données

Flow

Flux "normal" de données

Resolved flow

Flux de données représenté dans le diagramme mais créé et existant à un niveau de fonction inférieur

 

Global flow

Flux de données entre une fonction globale et un élément externe à la fonction frontière

 

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.

Éléments du référentiel

Process modeler Dataflow diagrammer Référentiel (RON)
Process Step Function Business Function
Business Unit - Business Unit
- External External
Store Datatore Datastore
Trigger
Outcome
- Process Event

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.

  1. 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. 
  2. 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és des fonctions (Definition)

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.

Propriétés des fonctions (Entity Usages)

L'onglet Entity Usages permet de définir les manipulations d'entités supportées par la fonction.

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. 

Entités référencées

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:

  1. 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.
  2. Plus tard, en enrichissement des modules, nous établirons le lien de référence.

Relations maître-détails

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.

Propriétés des fonctions (Attribute Usages)

L'onglet Attribute Usages permet de définir les attributs utilisés lors des manipulations d'entités.

Le raisonnement précédent, relatif aux entités, s'applique à l'identique aux attributs d'entités.