Quelques questions concernant le contexte et les diagrammes DataFlow

Question

Je dois développer une application CRUD, qui sera codé en php.

J'ai 3 acteurs principaux (utilisateurs, administrateurs et médecins - c'est un hypothétique hôpital), chacun avec différents cas d'utilisation déjà définis.

Bien que je pense que les cas d'utilisation sont plus que suffisant pour modèle le succcs diagramme de classes, je suis étant spécifiquement demandé d'inclure également les diagrammes DataFlow dans la documentation du projet.

J'ai lu sur les diagrammes DataFlow, et il semble que vous avez généralement d'abord un niveau 0 DataFlow Diagramme, auquel ils appellent diagramme de contexte.

Etant donné que cela est essentiellement une application 3 niveaux avec 3 différents acteurs, comment dois-je modéliser le diagramme de contexte?

Etant donné que un diagramme de contexte est censé nous dire ce qui entre et ce qui sort de notre système, je ne peux pas imaginer quelque chose de plus intéressant / descriptif que le schéma suivant:

Est-ce censé être quelque chose comme ça, ou suis-je totalement absente le point? Cette page php se connecte à une base de données Oracle, mais je suppose que si l'idée est de considérer dans son ensemble du système dans le diagramme de contexte, je « cacher » ce fait dans le schéma ci-dessus.

Où dois-je aller d'ici? Je sais que je devrais « zoomer » le processus système pour quelque chose de plus détaillé. Peut-être que l'étape suivante serait de représenter chacun des cas d'utilisation dans un diagramme DataFlow? Dois-je inclure des référentiels de données, déjà? Par exemple, l'un pour les utilisateurs, d'autres pour les médecins et encore une autre pour les administrateurs?

Merci

Answer 1

Êtes-vous sûr qu'il n'y a rien d'autre le système interagit avec? par exemple. entrée de diagnostic, etc.?

Dans le cas contraire, votre contexte diag est fondamentalement ok - bien que je serais probablement montrer chaque entité une fois et utiliser les flèches à deux têtes. Je suis d'accord avec votre raisonnement pour le db - ça fait partie du système, et non pas en dehors d'elle -. Alors ne le montre pas sur le CD

En ce qui concerne les prochaines étapes, encore une fois que vous êtes sur la bonne voie. Essayez modéliser le flux pour chaque cas d'utilisation comme DFD. DFD sont très utiles pour illustrer des applications de traitement intensif. Difficile de savoir si c'est un bon match à votre problème ou non.

Vous trouverez DFD sont également utiles pour chasser et valider votre diagramme de classes. En fait, c'est l'un de leurs points forts: datastores sur la DFD doivent en corrélation avec le contenu de votre diagramme de classes (pas nécessairement un datastore à une classe bien). Alors, ne comprennent datastores que vous travaillez à travers les processus. Vous le trouverez chasse plus que les acteurs.

HTH.

Answer 2

Quelques remarques:

DFD ne me dit pas grand-chose, sauf que les utilisateurs, administrateurs et médecins utilisent, mais il ne me donne aucune idée de ce qu'ils obtiennent du système (sauf « Sortie des données »). OIEau le diagramme de contexte ne me donne pas la moindre idée, ce que le système Finalité .

Il est vrai que, si le système est grand, il peut être difficile de décrire les flux de données en quelques mots, mais à peu près tout est mieux que « les données ».

Le fait que le système est une architecture de 3TIER est sans importance pour la DFD. Ceci est un détail de mise en œuvre. DFD sont un outil d'analyse. Vous décrivez ce que vous voulez que le système à faire, pas comment cela se fait.

Je trouve particulièrement utile de se concentrer sur les flux sortants. Alors que les utilisateurs, les administrateurs et les médecins fournissent des données au système, ce n'est rien plus probable qu'ils veulent à faire. Il est quelque chose qu'ils Vous à faire pour obtenir la sortie désirée.