Pregunta

Tengo que desarrollar una aplicación CRUD, que se codificará en php.

Tengo 3 actores principales (usuarios, administradores y médicos - esto es para una hipotética hospital), cada uno con diferentes casos de uso ya definidos.

A pesar de que me siento los casos de uso son más que suficiente para el modelo exitosamente el diagrama de clases, se me ha pedido específicamente para incluir también DataFlow Diagramas en la documentación del proyecto.

He estado leyendo sobre los diagramas de flujo de datos y parece que por lo general tiene en primer lugar un nivel 0 DataFlow Diagrama, al que llaman Diagrama de contexto.

Siendo que esto es básicamente una aplicación de 3 niveles con 3 actores diferentes, ¿cómo debo modelar el Diagrama de contexto?

Ser que un Diagrama de contexto se supone que sólo nos dicen lo que entra y lo que sale de nuestro sistema, no puedo imaginar nada más interesante / descriptivo que el esquema siguiente:

text alt

¿Se supone que esto es algo como esto, o estoy totalmente perdido el punto? Esta página PHP se conectará a una base de datos Oracle, pero supongo que si la idea es considerar el sistema como un todo en el Diagrama de contexto, que debe "ocultar" este hecho en el diagrama anterior.

¿Dónde debo ir desde aquí? Sé que debería "zoom" El proceso de sistema a algo más detallado. Tal vez el siguiente paso sería para representar cada uno de los casos de los usuarios en un diagrama de flujo de datos? Cómo puedo incluir repositorios de datos, ya? Por ejemplo, uno para los usuarios, otra para los médicos y otro para los administradores?

Gracias

¿Fue útil?

Solución

¿Está seguro no hay nada más interactúa el sistema con? p.ej. entrada de diagnóstico, etc.?

Si no es así, entonces su diag contexto es básicamente bien - aunque probablemente me muestro cada entidad una vez y utilizar las flechas de doble cabeza. Estoy de acuerdo con su razonamiento para el DB - es parte del sistema, no externo a él -. Lo que no se muestran en el CD

En cuanto a los próximos pasos, otra vez estás en la dirección correcta. Intenta modelar el flujo para cada caso de uso como un DFD. DFDs son muy útiles para ilustrar las aplicaciones de procesamiento intensivo. Es difícil saber si eso es un buen partido a su problema o no.

Encontrará DFD también son útiles para la conducción y la validación de su diagrama de clases. De hecho, esa es una de sus fortalezas: almacenes de datos en el DFD debe correlacionarse con el contenido de su diagrama de clases (no necesariamente un almacén de datos a una clase sin embargo). Así que incluyen almacenes de datos a medida que trabaja a través de los procesos. Lo encontrará expulsa a algo más que los Actores.

HTH.

Otros consejos

Algunas observaciones:

DFD no me dice mucho, excepto que los usuarios, los administradores y los médicos la utilizan, pero me da ninguna pista de lo que reciben del sistema (excepto "Salida de datos"). OIA el diagrama de contexto no me da la más mínima idea, lo que el sistema hace .

Es cierto que, si el sistema es grande, entonces puede ser difícil de describir los flujos de datos en pocas palabras, pero casi cualquier cosa es mejor que "datos".

El hecho de que el sistema es una arquitectura de 3 capas es irrelevante para el DFD. Este es un detalle de implementación. DFDs son una herramienta de análisis. Describir lo que desea que el sistema debe hacer, no cómo se logra esto.

Me resulta particularmente útil para centrarse en los flujos salientes. Mientras que los usuarios, administradores y médicos proporcionan entrada al sistema, lo más probable es que nada quieren a hacer. Es algo que Tienes que ver con el fin de obtener la salida deseada.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top