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.
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.
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 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.
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.
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).
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.
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.
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.
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
-
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.
|