Documentación del flujo/iteración de aplicaciones web

Question

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

Answer 1

Utilizamos diagramas de clase UML usando una variación del ensayo de Conallen Modeling Web Application Design with UML. Encontrará que este ensayo se ha convertido en different incarnations around the net y que incluso se ha convertido en un libro Building-Web-Applications-UML-2nd.

Mi recorrido de 2 centavos del enfoque que usamos:

Siguiendo papel de Conallen, que define un nuevo UML entidades (estereotipos) para representar una página web o una parte de una página para que pudiéramos distinguir el servidor- código del lado (por ejemplo, servlets Java o JSP] del lado del cliente HTML/Javascript/AJAX que generó Por ejemplo:.

• [página web]
• [nav bar]
• [página de contenido ]
• [encabezado]
• [pie]

Hubo nuevos associationss como:

• [construye] - se relaciona código del lado del servidor para el fragmento de la página web o página que generó
• [aparente-enlace] - se utiliza entre las páginas del cliente en el diagrama de sitemap
• [enlace] - enlace URL, es decir, solicitud GET
• [enviar] - formulario de devolución al servidor, solicitud es decir, la POST
• [cliente-redirección] - del lado del cliente redirigir
• [servidor de redireccionamiento] - duh

Por último, algunos de los nuevos diagramas (en su mayoría sólo especializaciones de los diagramas de clases), tales como:

• [mapa del sitio] -> como un diagrama de clases - muestra relaciones estáticas ([-Link aparente] s) entre [página web] s desde el punto de usuario de vista
• [página generación] -> como un diagrama de clases - muestra las clases estáticamente relacionadas con un desplazamiento de una página web específica: qué código lo generó, qué código maneja la publicación posterior
• [composición de página] - muestra un diagrama de clases: muestra las cosas que conforman una determinada [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 Rational Rose extensiones icono lo necesario para hacer los diagramas de aspecto medio decente.

La mala noticia:

• este enfoque fue mucho trabajo - que ahora tenía el doble de muchas entidades para modelar con, ya que estábamos ahora modelando las entidades del lado del cliente, además del servidor -las clases de la parte

leer uno de los periódicos Conallen de fotos de lo que estoy hablando, pero como dije, no siguió su enfoque estrictamente - sólo tomando las piezas que necesitábamos. Espero que esto ayude.

Answer 2

Los casos de uso como parte de los diagramas de actividad son utilizados por algunos de los colegas de la mina, pero esto es bueno tal vez para algunos visión general de navegación estática de alto nivel.

Estoy a punto de desarrollar 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ágina web.

Answer 3

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

Answer 4

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

Cada página debe tener un propósito. Enfóquese primero en ese propósito y diseñe todo lo demás a su alrededor.

proceso:

• boceto a cabo las partes principales de un elemento de la lista sharpie and paper
• ignore the details desde el principio (que acaba de obtener en el camino)
• crear algo real tan pronto como sea posible (es decir, crear unos pocos 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 y luego agregar los componentes de diseño y iniciar la programación

Es mucho más fácil añadir la programación a algo que ya ha sido diseñado y pensado vs diseñar una aplicación para evitar la programación existente (que en la mayoría de los casos requiere código para ser reescrito para adaptarse a los problemas de diseño/flujo que se perdieron al principio).