Directriz: Creación de aplicaciones web con el UML
En esta directriz, el análisis de guión de uso avanza un paso en el diseño de aplicaciones web.
Relaciones
Elementos relacionados
Descripción principal

Referencias

Los libros y los documentos siguientes son referencias para estas directrices:

Elaborar un análisis de guión de uso

La diferencia, en comparación con lo que se encuentra en Tarea: Análisis de guión de uso es que las clases de límite están más centradas en un objetivo concreto. Los objetos de estas clases tienen una vida corta, y cualquier estado de cliente (en páginas web) necesita gestionarse explícitamente con mecanismos específicos. Por ejemplo, las páginas de Microsoft Active Server utilizan "cookies" como índice en una correlación del estado de todos los clientes activos actualmente.

Asimismo, cuando lea la especificación de un guión de uso, se aplica lo siguiente: 

  • Cualquier mención a una página web se traduce en una clase de límite. 
  • Cualquier mención un hiperenlace se traduce en una asociación de una clase de límite a otras clases de límite o clase de controlador. 
  • Los verbos o descripciones de procesos tienden a correlacionar con clases de controlador. 
  • Los nombres se correlacionan con clases de entidad. 

La clase de límite, a través de la cual se inicia la comunicación, habla a una clase de controlador. La clase de controlador no responderá típicamente a través de la misma instancia de esta clase de límite.

Utilización de diagramas de interacción

Cuando el guión de uso está en marcha, los casos de ejemplo se pueden describir con diagramas de secuencia. Esto ayuda a validar la existencia de objetos de análisis contra un caso de ejemplo de un guión de uso. Si se descubre que los objetos de análisis no participan en ninguno de los casos de ejemplo, serán sospechosos y deberán volverse a evaluar. El riesgo es que si profundiza demasiado, los diagramas resultan grandes y difíciles de gestionar. Para evitar esto, concéntrese en casos de ejemplo breves y separados, e incluya sólo objetos de controlador de límite y principal y objetos de entidad.

Recuerde que los objetos de límite en las aplicaciones web tienen una duración limitada. Una clase de límite puede, no obstante, crear varias instancias durante la ejecución de un caso de ejemplo, lo que significa que diferentes objetos de límite crean instancias desde la misma clase del diagrama.

El actor en un diagrama de secuencia de nivel de análisis interactúa con un objeto de límite. Se envía un mensaje de navegación desde el actor hasta el objeto de límite.

Creación de las clases de diseño inicial

Diseños de clases de límite iniciales

Una clase de límite se puede correlacionar con una clase de página de cliente.

Si la clase de límite implica la entrada de información, habitualmente se asociará con un formulario (o un formulario web) a través de la agregación. Un formulario se puede modelar como una clase anidada de la página cliente, ya que todo su ciclo de vida está gobernado por la página cliente. Los formularios siempre tienen una relación enviar a la página servidor, que procesa los valores del formulario, que finalmente conduce a una nueva página de cliente devuelta.

Si la interfaz de usuario requiere cualquier comportamiento dinámico en el cliente, la forma más sencilla de cumplirlo puede ser mediante el uso de HTML dinámico en el cliente. En el modelo de diseño, esto suele aparecer como operaciones en la página cliente. Las operaciones en la página cliente se correlacionan directamente con las funciones de scripts de Java. Los atributos de la página Java se correlacionan directamente con la página de variables de ámbito de la página. Los manejadores de sucesos HTML dinámicos se capturan como valores etiquetados.

Si la interfaz de usuario tiene un comportamiento muy sofisticado, debe considerar la asociación de un applet con la clase de límite, mediante una agregación.

Si la arquitectura se basa en un sistema de objeto distribuido (como un RMI, IIOP o DCOM), la página de cliente puede hacer referencia a interfaces a componentes que comunican directamente con el servidor mediante RMI, IIOP o DCOM, superando el HTTP. Estos tipos de relaciones están habitualmente estereotipadas <<rmi>>, <<iiop>> o <<dcom>> para indicar al diseñador las áreas donde se producirá el tráfico de red, donde se pueden producir los cuellos de botella.

Diseños de clases de entidad iniciales

En el diseño de una aplicación web, la única diferencia sobre clases de entidad es, si el objeto se encuentra en el ámbito de la página cliente, que el objeto de entidad correlacionará con un objeto de java script.

Diseños de clases de controlador iniciales

Las clases de control se correlacionan con páginas servidor. Los controladores expresan y coordinan la lógica empresarial y coordinan otras lógicas. Habitualmente se encuentran en el servidor. Muchos objetos de controlador son responsables de construir páginas cliente (esencialmente, producen HTML como salida principal). Los objetos de controlador pueden interactuar con recursos del lado del servidor, como bases de datos, componentes de nivel medio, monitores de transacción, etc.  

Las clases de controlador habitualmente correlacionan con páginas web con scripts del servidor (página de servidor activo, páginas de servidor java).