Documentación del flujo / iteración de la aplicación web [cerrado]

Question

¿Qué artefactos / diagramas se usan para documentar el flujo de una aplicación web teniendo en cuenta los vínculos entre las páginas estáticas y cómo los componentes de vista dinámica (formularios html, JSP, Ajax, etc.) interactúan con los componentes del lado del servidor (Servlets, Struts) , etc)? ¿Usa diagramas UML?

Answer 1

Utilizamos diagramas de clases UML utilizando una variación del ensayo de Conallen Modelando el diseño de aplicaciones web con UML . Encontrarás que este ensayo se ha convertido en diferentes encarnaciones en la red e incluso se ha convertido en un libro Building-Web-Applications-UML-2nd .

Mi recorrido de 2 centavos por el enfoque que usamos:

Siguiendo el documento de Conallen, definimos nuevas entidades UML (estereotipos) para representar una página web o parte de una página para poder distinguir el código del lado del servidor (por ejemplo, servlet de Java o JSP) del HTML del lado del cliente / javascript / AJAX que generó. Por ejemplo:

• [página web]
• [barra de navegación]
• [contenido de la página]
• [encabezado]
• [pie de página]

Hubo nuevas asociaciones como:

• [compilaciones]: relaciona el código del lado del servidor con la página web o el fragmento de página que generó
• [enlace aparente]: se usa entre las páginas del cliente en el diagrama del mapa del sitio
• [enlace] - enlace de URL, es decir, solicitud GET
• [submits]: envío de formulario al servidor, es decir, solicitud POST
• [redirección de cliente] - redirección del lado del cliente
• [servidor-redirección] - duh

Finalmente, algunos diagramas nuevos (en su mayoría solo especializaciones de diagramas de clase) como:

• [mapa del sitio] - > como un diagrama de clase: muestra relaciones estáticas ([aparente-enlace] s) entre [página web] s desde el punto de vista del usuario
• [generación de página] - > como un diagrama de clase: muestra las clases relacionadas estáticamente con una página web específica: qué código lo generó, qué código maneja el envío posterior
• [page-composition] - como un diagrama de clase - muestra las cosas que conforman una [página web]
• [diagramas de secuencia]: el único otro cambio fue que los diagramas de secuencia ahora podrían incluir entidades del lado del cliente como actores.

La buena noticia:

• encontramos las extensiones del icono de Rational Rose que necesitábamos para hacer que los diagramas se vean medio decentes.

Las malas noticias:

• este enfoque era mucho trabajo, ahora teníamos el doble de entidades con las que modelar, ya que ahora modelamos las entidades del lado del cliente además de las clases del lado del servidor.

Lea uno de los documentos de Conallen para ver fotos de lo que estoy hablando, pero como dije, no siguió su enfoque estrictamente; solo tomamos las piezas que necesitábamos. Espero que esto ayude.

Answer 2

Usé diagramas de estado UML para documentar la navegación de la página de aplicaciones web en el pasado.

Answer 3

Recomiendo tomar el enfoque de 37signals para el desarrollo de aplicaciones.

Cada página debe tener un propósito. Primero, concéntrese en ese propósito y diseñe todo lo demás a su alrededor.

Proceso:

• dibuje las partes principales con un sharpie y papel
• elemento de lista
• ignorar los detalles desde el principio (solo se interponen en el camino)
• cree algo real tan pronto como sea posible (es decir, cree unos cuantos archivos html con enlaces que van a otras páginas para mostrar cómo fluirá la aplicación
• una vez que se establece el flujo del sitio, agregue los componentes de diseño y comience a programar

Es mucho más fácil agregar programación a algo que ya ha sido diseñado y pensado en comparación con el diseño de una aplicación para solucionar la programación existente (que en la mayoría de los casos requiere que el código se reescriba para adaptarse a los problemas de diseño / flujo que se omitieron en la principio).

Answer 4

Algunos de mis colegas utilizan los casos de uso como parte de los diagramas de actividad, pero esto es bueno tal vez para una visión general de navegación estática de alto nivel.

Estoy a punto de desarrollar un DSL personalizado, que se asemejará al formato de escenario BDD utilizado en Cucumber con Webrat. En mi humilde opinión, tales escenarios contienen suficiente información para crear modelos de interacción y páginas web.