Directriz: Clase de análisis
Existen tres estereotipos de clase de análisis: Límite, Control y Entidad. En esta directriz se explica su significado y uso.
Relaciones
Descripción principal

Estereotipos de clase de análisis

Las clases de análisis se pueden estereotipar como una de las siguientes:

  • Clases de límite
  • Clases de control
  • Clases de entidad

A parte de proporcionarle una orientación más específica del proceso para encontrar las clases, estos estereotipos producen un modelo de objeto robusto porque los cambios del modelo tienden a afectar sólo a un área específica. Los cambios en la interfaz de usuario, por ejemplo, afectarán sólo a las clases de límite. Los cambios en el flujo de control afectarán sólo a las clases de control. Los cambios de la información a largo plazo afectarán sólo a las clases de entidad. Sin embargo, estos estereotipos resultan especialmente útiles para ayudar a identificar clases en análisis y en diseño temprano. Probablemente debe considerar la utilización de un conjunto de estereotipos ligeramente diferente en fases posteriores del diseño para mejorar la correlación con el entorno de implementación, el tipo de aplicación, etc.

Clase de límite Icono de clase de límite

Una clase de límite es una clase que se utiliza para modelar la interacción entre el entorno del sistema y los trabajos internos. Tal interacción implica la transformación y la traducción de sucesos y cambios de notación en la presentación del sistema (como la interfaz).

Las clases de límite modelan los componentes del sistema que dependen del entorno. Las clases de entidad y las de control modelan los componentes que son independientes del entorno del sistema. Por lo tanto, cambiar la GUI o el protocolo de comunicación debe significar cambiar sólo las clases de límite, no las clases de control y de entidad.

Las clases de límite también facilitan la compresión del sistema porque aclaran los límites del sistema. Ayudan en el diseño proporcionando un buen punto de partida para identificar los servicios relacionados. Por ejemplo, si identifica una interfaz de la impresora pronto en el diseño, podrá ver que también debe modelar el formato de las salidas impresas.

Las clases de límites comunes incluyen ventanas, protocolos de comunicación, interfaces de impresoras, sensores y terminales. No tiene que modelar componentes de interfaces de rutinas, como botones, como clases de límites separados. Generalmente, toda la ventana es el objeto de límite más pequeño. Las clases de límite también resultan útiles para capturar interfaces para posibilitar las API no orientadas a objetos, como por ejemplo código heredado.

Debe modelar las clases de límite de acuerdo con el tipo de límite que representan. La comunicación con otro sistema y la comunicación con un actor humano (mediante una interfaz de usuario) tienen diferentes objetivos. Para comunicar con un actor humano, la preocupación más importante es cómo se presentará la interfaz al usuario. Para comunicar con otro sistema, la preocupación más importante es el protocolo de comunicación.

Un objeto de límite (una instancia de clase de límite) puede sobrevivir a una instancia de guión de uso si, por ejemplo, debe aparecer en una pantalla entre el rendimiento de dos guiones de uso. Normalmente, sin embargo, los objetos de límite viven sólo durante la instancia de guión de uso.

Encontrar las clases de límite

Una clase de límite hace de intermediario entre la interfaz y algo fuera del sistema. Los objetos de límite aíslan el sistema de los cambios del entorno (los cambios en las interfaces a otros sistemas, cambios en los requisitos del usuario, etc.), evitando que estos cambios afecten al resto del sistema.

Un sistema puede tener diferentes tipos de clases de límite:

  • Clases de interfaz de usuario - clases que hacen de intermediario en la comunicación con usuarios humanos del sistema.
  • Clases de interfaz de sistema - clases que hacen de intermediario en la comunicación con otros sistemas
  • Clases de interfaz de dispositivo - clases que proporcionan la interfaz a los dispositivos (como sensores), que detectan sucesos externos
Encontrar las clases de interfaz de usuario

Defina una clase de límite para cada par de actores de guión de uso. Esta clase se puede visualizar si tiene la responsabilidad de coordinar la interacción con el actor. También puede definir clases de límite adicionales para representar clases subsidiarias a las que las clases de límite principales delegan algunas de estas responsabilidades. Esto es especialmente cierto para aplicaciones GUI basadas en ventanas, donde puede modelar un objeto de límite para cada ventana, o uno para cada forma. Modele sólo las abstracciones de claves del sistema; no modele todos los botones, las listas y los objetos gráficos de la GUI. El objetivo del análisis es formar una buena imagen de cómo está compuesto el sistema, no diseñar hasta el último detalle. En otras palabras, identificar las clases de límite sólo para los fenómenos del sistema o para lo que se menciona en el flujo de sucesos de la ejecución de guión de uso.

Haga esbozos, o utilice volcados de pantalla desde un Prototipo de interfaz de usuario, que ilustra el comportamiento y la apariencia de las clases de límite.

Encontrar las clases de interfaz de sistema

Una clase de límite que comunica con un sistema externo es responsable de gestionar el diálogo con el sistema externo; proporciona la interfaz de ese sistema para el sistema que se está construyendo.

Ejemplo

En un cajero automático, la retirada de dinero debe verificarse a través de la red de cajeros automáticos, un actor (que a su vez verifica la retirada con el sistema de cuentas del banco). Se puede identificar un objeto denominado Interfaz de la red de cajeros automáticos para proporcionar comunicación con la red de cajeros automáticos.

Es posible que la interfaz a un sistema existente ya esté bien definida; si lo está, las responsabilidades deben derivarse directamente desde la definición de interfaz. Si existe una definición de interfaz formal, se puede revertir la ingeniería y no es necesario definirla formalmente aquí; simplemente, tenga en cuenta el hecho que la interfaz existente se reutilizará durante el diseño.

Encontrar las clases de interfaz de dispositivo

El sistema puede contener elementos que actúan como si fueran externos (cambian de valor espontáneamente sin que les afecte ningún objeto del sistema), como equipamiento sensor. Aunque es posible representar este tipo de dispositivo externo mediante actores, los usuarios del sistema pueden encontrarlo confuso, ya que tiende a colocar los dispositivos y los actores humanos en el mismo nivel. Cuando nos apartamos de la recopilación de requisitos, sin embargo, debemos tener en cuenta el origen de todos los sucesos externos y asegurarnos de que disponemos del modo para que el sistema detecte estos sucesos.

Si el dispositivo está representado como actor en el modelo de guión de uso, es fácil de justificar mediante una clase de límite para que haga de intermediario entre la comunicación entre el dispositivo y el sistema. Si el modelo de guión de uso no incluye estos "dispositivos-actores", ahora es el momento apropiado para añadirlos, actualizando las Descripciones suplementarias de los guiones de uso cuando sea apropiado.

Para cada "dispositivo-actor", cree una clase de límite para capturar las responsabilidades del dispositivo o sensor. Si ya existe una interfaz bien definida para el dispositivo, téngala en cuenta para una posterior referencia durante el diseño.

Clase de control icono de clase de control

Una clase de control es una clase que se utiliza para modelar el comportamiento de control específico a uno o a varios guiones de uso. Los objetos de control (instancias de clases de control) a menudo controlan otros objetos, para que el comportamiento sea de tipo de coordinación. Las clases de control resumen el comportamiento de guión de uso específico.

El comportamiento de un objeto de control está estrechamente relacionado con la ejecución de un guión de uso específico. En muchos casos de ejemplo, incluso puede decir que los objetos de control "ejecutan" las ejecuciones de guión de uso de análisis. Sin embargo, algunos objetos de control pueden participar en más de una ejecución de guiones de uso de análisis si las tareas de guión de uso están fuertemente relacionadas. Además, varios objetos de control de diferentes clases de control pueden participar en un guión de uso. No todos los guiones de uso requieren un objeto de control. Por ejemplo, si el flujo de sucesos en un guión de uso está relacionado con un objeto de entidad, un objeto de límite puede realizar el guión de uso en colaboración con el objeto de entidad. Puede empezar identificando una clase de control por ejecución de guiones de uso de análisis y, a continuación, perfeccionando esto a medida que se identifican más ejecuciones de guiones de uso de análisis y se descubren más similitudes.

Las clases de control pueden contribuir en la comprensión del sistema porque representan las dinámicas del sistema, gestionando las tareas principales y los flujos de control.

Cuando el sistema efectúa el guión de uso, se crea un objeto de control. Los objetos de control habitualmente mueren cuando el guión de uso correspondiente se ha llevado a cabo.

Tenga en cuenta que una clase de control no maneja todo lo necesario en un guión de uso. En cambio, coordina las tareas de otros objetos que implementan la funcionalidad. La clase de control delega trabajo a los objetos que se han asignado a la responsabilidad de la funcionalidad.

Encontrar las clases de control

Las clases de control proporcionan un comportamiento de coordinación en el sistema. El sistema puede efectuar algunos guiones de uso sin objetos de control (utilizando sólo objetos de entidad y de límite); especialmente los guiones de uso que implican sólo la simple manipulación de información almacenada.

Los guiones de uso más complejos generalmente requieren una o más clases de control para coordinar el comportamiento de los otros objetos del sistema. Los ejemplos de objetos de control incluyen programas como gestores de transacciones, coordinadores de recursos y manejadores de errores.

Las clases de control desacoplan de forma efectiva los objetos de entidad y de límite entre ellos, haciendo que el sistema sea más tolerante a cambios en el límite del sistema. También desacoplan el comportamiento específico de guión de uso de los objetos de entidad, haciéndolos más reutilizables en los guiones de uso y los sistemas.

Las clases de control proporcionan un comportamiento que:

  • Es independiente del entorno (no cambia cuando el entorno cambia),
  • Define la lógica de control (orden entre sucesos) y transacciones en un guión de uso.
  • Cambia poco si la estructura interna o el comportamiento de las clases de entidad cambian,
  • Utiliza o establece el contenido de diferentes clases de entidad y, por lo tanto, necesita coordinar el comportamiento de estas clases de entidad.
  • No se realiza del mismo modo cada vez que se activa (el flujo de sucesos pasa por diferentes estados).
Determine si es necesaria una clase de control

El flujo de sucesos de un guión de uso define el orden en que se efectúan las diferentes tareas. Empiece investigando si el flujo de puede gestionar con el límite que ya está identificado y por las clases de entidad. Para flujos de sucesos simples que principalmente entran, recuperan y muestran, o modifican información, no está justificada una clase de control separada; las clases de límite serán responsables de coordinar el guión de uso.

Los flujos de sucesos deben estar resumidos en una clase de control separada cuando es complejo y consta de comportamiento dinámico que puede cambiar independientemente de las interfaces (clases de límite) o los almacenes de información (clases de entidad) del sistema. Resumiendo los flujos de sucesos, la misma clase de control puede reutilizarse de forma potencial para una serie de sistemas que pueden tener diferentes interfaces y diferentes almacenes de información (o, como mínimo, las estructuras de datos subyacentes).

Ejemplo: gestión de una cola de tareas

Puede identificar una clase de control a partir del guión de uso Realizar tarea en el Sistema de manipulación de almacén. Esta clase de control gestiona una cola de Tareas, asegurando que las tareas se efectúan en el orden correcto. Efectúa la tarea siguiente en la cola cuando el equipamiento de transporte adecuado está asignado. El sistema puede, por lo tanto, llevar a cabo varias tareas al mismo tiempo.

El comportamiento definido por el objeto de control correspondiente es más fácil de describir si lo divide en dos clases de control, Realizador de tareas y Manejador de colas. Un objeto Manejador de colas manejará sólo el orden de la cola y la asignación de equipamiento de transporte. Un objeto Manejador de colas es necesario para toda la cola. Cuando el sistema efectúe una tarea, creará un nuevo objeto Realizador de tareas, que llevará a cabo la Tarea. Por lo tanto, necesitamos un objeto Realizador de tareas para cada tarea que el sistema lleva a cabo.

Las clases demasiado complejas deben dividirse en clases con un conjunto coherente y relacionado de responsabilidades.

Las clases complejas deben dividirse en líneas de responsabilidades similares

El beneficio principal de esta división es que disponemos de responsabilidades de manejo de colas separadas (algo genérico para muchos guiones de uso) desde las tareas específicas de la gestión de tareas, que son específicas para este guión de uso. Esto facilita la comprensión de las clases y las hace más fáciles de adaptar a medida que el diseño madura. También tiene beneficios en el equilibrio de la carga del sistema, ya que muchos Realizadores de tareas se pueden crear cuando sea necesario para manejar la carga de trabajo.

Resumir el flujo principal de sucesos y los flujos alternativos/excepcionales de sucesos en clases de control separadas

Para simplificar los cambios, se resume el flujo principal de sucesos y los flujos alternativos de sucesos en diferentes clases de control. Si los flujos alternativos y de excepción son totalmente independientes, sepárelos también. Esto facilitará que el sistema se amplíe y se mantenga a lo largo del tiempo.

Dividir las clases de control donde dos actores comparten la misma clase de control

También puede ser necesario dividir las clases de control cuando varios actores utilizan la misma clase de control. De este modo, aislamos los cambios de los requisitos de un actor del resto del sistema. En los casos en que el coste del cambio es elevado o las consecuencias son problemáticas, debe identificar todas las clases de control relacionadas con más de un actor y dividirlas. En el caso ideal, cada clase de control debe interactuar (a través de algún objeto de límite) con un actor, o ninguno.

Ejemplo: gestión de llamadas

Considere el guión de uso LLamada local. Inicialmente, podemos identificar una clase de control para gestionar la misma llamada.

Los diferentes actores implicados en un guión de uso suelen requerir clases de control separadas

La clase de control que gestiona las llamadas telefónicas locales en un sistema telefónico se pueden dividir rápidamente en dos clases de control, Comportamiento-A y Comportamiento-B, una para cada actor implicado.

En una llamada local, hay dos actores: el Suscriptor-A que inicia la llamada, y el Suscriptor-B que la recibe. El Suscriptor-A levanta el receptor, oye el tono de línea, y marca una serie de dígitos, que el sistema almacena y analiza. Cuando el sistema ha recibido todos los dígitos, envía el tono de marcado al Suscriptor-A, y la señal de llamada al Suscriptor-B. Cuando el Suscriptor-B responde, el tono y la señal se detienen, y puede empezar la conversación entre los suscriptores. La llamada finaliza cuando ambos suscriptores cuelgan.

Deben controlarse dos comportamientos: Qué sucede en el lugar del Suscriptor-A y qué sucede en el lugar del Suscriptor-B. Por este motivo, el objeto de control original se divide en dos objetos de control, Comportamiento-A y Comportamiento-B.

No tiene que dividir una clase de control si:

  • Puede asegurar de forma razonable que el comportamiento de los actores relacionado con los objetos de la clase de control nunca cambiarán, o que cambiarán muy poco.
  • El comportamiento de un objeto de clase de control hacia un actor es insignificante en comparación con el comportamiento hacia otro actor, un único objeto puede mantener todo el comportamiento. Combinar los comportamientos de este modo tendrá un efecto insignificante en la capacidad de cambio.

Clase de entidad Icono de clase de entidad

Una clase de entidad es una clase que se utiliza para modelar información y el comportamiento asociado que debe almacenarse. Los objetos de entidad (instancias de clases de entidad) se utilizan para mantener y actualizar la información sobre algún fenómeno, como un suceso, una persona, o algún objeto real. Habitualmente son persistentes, teniendo atributos y relaciones necesarias durante un periodo prolongado, a veces para toda la vida del sistema.

Un objeto de entidad no suele ser específico para una ejecución de guiones de uso de análisis; a veces, un objeto de entidad no es ni siquiera específico del mismo sistema. Los valores de los atributos y relaciones suelen venir de un actor. Un objeto de entidad también puede ser necesario para ayudar a realizar tareas internas del sistema. Los objetos de entidad pueden tener un comportamiento tan complicado como el de otros estereotipos de objeto. Sin embargo, a diferencia de otros objetos, este comportamiento está fuertemente relacionado con el fenómeno que representa el objeto de entidad. Los objetos de entidad son independientes del entorno (los actores).

Los objetos de entidad representan conceptos clave del sistema que se está desarrollando. Ejemplos típicos de las clases de entidad en un sistema bancario son Cuenta y Cliente. En un sistema de manejo de red, los ejemplos son Nodo y Enlace.

Si ninguna otra clase utiliza el fenómeno que desea modelar, puede modelarlo como un atributo de una clase de entidad, o incluso como una relación entre clases de entidad. Por otra parte, si otra clase utiliza el fenómeno en el modelo de diseño, debe modelarlo como clase.

Las clases de entidad proporcionan otro punto de vista desde el cual se comprende el sistema porque muestran la estructura de datos lógica, que puede ayudarle a comprender qué se supone que ofrece el sistema a los usuarios.

Encontrar las clases de entidad

Las clases de entidad representan almacenes de información en el sistema; se utilizan habitualmente para representar los conceptos clave que gestiona el sistema. Los objetos de entidad suelen ser pasivos y persistentes. Sus principales responsabilidades son almacenar y gestionar información en el sistema.

Una fuente de inspiración frecuente para las clases de entidad son el Glosario (desarrollado durante los requisitos) y un modelo de dominio empresarial (desarrollado durante el modelado empresarial, si se efectúa modelado empresarial).

Restricciones de uso de los estereotipos de asociación

Restricciones para clases de límite

Se permite lo siguiente:

  • Comunicar asociaciones entre dos clases de límite, por ejemplo, para describir como una ventana específica está relacionada con otros objetos de límite.
  • Comunicar o suscribir asociaciones de una clase de límite a una clase de entidad, porque los objetos de límite pueden necesitar el seguimiento de ciertos objetos de entidad entre acciones en el objeto de límite, o estar informados de los cambios de estado en el objeto de entidad.
  • Comunicar asociaciones de una clase de límite a una clase de control, para que el objeto de límite pueda desencadenar un comportamiento concreto.

Restricciones para clases de control

Se permite lo siguiente:

  • Comunicar o suscribir asociaciones entre clases de control y clases de entidad, porque los objetos de control pueden necesitar el seguimiento de ciertos objetos de entidad entre acciones en el objeto de control, o estar informados de los cambios de estado en el objeto de entidad.
  • Comunicar asociaciones entre clases de control y de límite, permitiendo que los resultados del comportamiento invocado se comuniquen al entorno.
  • Comunicar asociaciones entre clase de control, permitiendo la construcción de patrones de comportamiento más complejos.

Restricciones para clases de entidad

Las clases de entidad sólo deben ser el origen de las asociaciones (comunicar o suscribir) a otras clases de entidad. Los objetos de clase de entidad tienden a durar mucho; los objetos de clase de control y de límite tienden a tener una vida más corta. Es coherente desde el punto de vista arquitectónico limitar la visibilidad que un objeto de entidad tiene de su entorno; de este modo el sistema es más sencillo de cambiar.

Resumen de restricciones

FromTo
(navegabilidad)

Límite

Entidad

Control

Límite

comunica

comunica

suscribe

comunica

Entidad

comunica

suscribe

 

Control

comunica

comunica

suscribe

comunica

Combinaciones de estereotipos de asociación válidos

Reforzar la coherencia

  • Cuando se identifica un nuevo comportamiento, compruebe si existe alguna clase que tenga unas responsabilidades similares, reutilizando las clases donde sea posible. Sólo cuando esté seguro de que no hay ningún objeto existente que puede efectuar el comportamiento, deberá crear las nuevas clases.
  • Cuando las clases se hayan identificado, examínelas para asegurarse de que tienen responsabilidades coherentes. Cuando las responsabilidades de las clases se desconecten, divida el objeto en dos o más clases. Actualice el diagrama de interacción según corresponda.
  • Si la clase se divide porque se descubren las responsabilidades desconectadas, examine las colaboraciones en que la clase tiene un rol para ver si la colaboración necesita una actualización. Actualice la colaboración si fuera necesario.
  • Una clase con sólo una responsabilidad no es un problema, per se, pero puede generar preguntas sobre porqué es necesaria. Esté preparado para solicitudes de identificación y para justificar la existencia de todas las clases.