¿Qué diagramas, además del diagrama de clase y el diagrama de flujo de trabajo, son útiles para explicar cómo funciona una aplicación?

7

Estoy trabajando en un pequeño proyecto Delphi, compuesto de dos unidades. Una unidad es para la GUI y la otra para administración de datos, análisis de archivos, iteración de listas, etc. Ya he hecho un diagrama de clase y mi workflow parece un infierno, es demasiado complejo, incluso para que cualquiera lo lea. He considerado hacer un diagrama de flujo de datos, pero sería aún más complejo. Un diagrama de casos de uso tampoco sería útil. ¿Me falta algún tipo de diagrama que pueda representar de alguna manera la relación entre mis dos unidades?

    
pregunta programstinator 09.11.2012 - 12:34

3 respuestas

3

Si desea mostrar relaciones estáticas entre sus componentes, el Diagrama de componentes UML debería ayudarlo. Si desea mostrar interacciones entre estos componentes, intente utilizar el Diagrama de secuencia UML. También debe recordar acerca de mantenerse en el mismo nivel de abstracción, por ejemplo. No entre en detalles (como presionar la casilla de verificación), cuando está tratando de describir el sistema en el nivel de componente ("gui" vs "otra" unidad). Su diagrama de flujo de trabajo no tiene mucho sentido ahora, ya que debería centrarse en un escenario específico (por ejemplo, cargar un informe) en lugar de tratar de mostrar todos los escenarios posibles en un solo diagrama.

También creo que tiene un problema más grave por debajo, ya que su "otra unidad" está haciendo demasiado trabajo y está rompiendo el Principio de Responsabilidad Única. Podría pensar en dividir la "otra unidad" en más componentes, cada uno de ellos asumiendo una responsabilidad específica (por ejemplo, analizar archivos, generar informes, ordenar informes).

    
respondido por el rmaruszewski 09.11.2012 - 13:08
5

Referencias de diagramas UML clásicos

Dos grandes referencias para UML y sus muchos tipos de diagramas incluyen UML Distilled de Martin Fowler en el que se describe cada diagrama de la misma manera en que podría esperarse que se describiera un patrón (se nombra, se describe, se enumeran las fuerzas y se identifica la aplicabilidad). Una referencia más completa es Grady Booch (et. All) en Análisis y diseño orientado a objetos con aplicaciones .

Diagramas de estado anidados

Usted menciona que su flujo de trabajo se ve como el infierno, y con frecuencia el arte de hacer un buen diagrama es su nivel de detalle. La referencia de Booch tiene un gran material sobre máquinas de estado anidadas que me quitaron los calcetines cuando lo leí. Un diagrama de estado puede tener una carga de estados y transiciones, pero al utilizar su representación anidada muchas transiciones que puede ocurrir desde cualquier estado puede representarse en un diagrama externo y las transiciones que son más específicas a una localidad de unos pocos estados pueden representarse mediante un diagrama interno.

Diagramas de actividad

El flujo de trabajo podría prestarse a mostrarse en un diagrama de actividad . Los diagramas de actividad son superiores al diagrama de flujo de varias maneras, pero pueden representar cosas similares como las decisiones y la iteración. Una cosa que me gusta de ellos es que muestran actividades paralelas y, a veces, representan la división del trabajo en el sistema usando particiones o como se llaman más comúnmente, carriles de natación. También pueden representar la sincronización con una barra de sincronización que tiene un arco entrando y múltiples arcos saliendo (bifurcación) y múltiples arcos entrando y un solo arco saliendo (unir). Al igual que las máquinas de estados, UML también permite anidar diagramas de actividades para estructurar mejor y limitar el nivel de detalle.

Diagramas de flujo de datos

Si no te importa una explosión del pasado, un diagrama del diagrama estructurado que UML rechazó, pero para el que creo que UML no ha dado un reemplazo totalmente satisfactorio es diagrama de flujo de datos (DFD). Este tipo de diagrama es hermosamente simple en su uso de cuatro símbolos para mostrar un proceso, almacén de datos, flujo de datos y entidades externas. Las entidades externas se muestran en los lados derecho e izquierdo del diagrama para mostrar quién o qué proporciona entradas y salidas al sistema, los datos se etiquetan a medida que pasan de un proceso de transformación de datos a otro. Si los datos se obtienen o se producen para el almacenamiento, eso también se muestra, generalmente con los almacenes de datos ubicados debajo de los procesos que los consumen / producen.

Usando diagramas para diseñar mejor

Hay muchos otros diagramas disponibles. Tu editor de diagramas favorito podría expandir o limitar tus elecciones. Idealmente, los diagramas deberían ayudarlo a mejorar la consistencia y la integridad de sus diseños. Un diagrama complejo y difícil de dibujar podría estar diciéndole que su diseño es demasiado complejo e incluso puede mostrarle algunas relaciones que puede simplificar.

    
respondido por el DeveloperDon 09.11.2012 - 13:50
0

Mi sugerencia sería crear un diagrama de arquitectura para ilustrar la idea de alto nivel de todo el proyecto.

también si el diagrama de clase es demasiado complejo, entonces rompa las unidades y muestre la interacción de las unidades en lugar de todas las clases.

    
respondido por el paritosh 09.11.2012 - 12:36

Lea otras preguntas en las etiquetas