Objetos entidad, frontera y control

Los objetos de entidad representan la información persistente rastreada por el sistema. Los objetos de
frontera representan la interacción entre los actores y el sistema. Los objetos de control representan las
tareas realizadas por el usuario y soportadas por el sistema.

1. Objetos frontera: Estos objetos representan entidades del sistema con las cuales el actor se relaciona
directamente. Vienen a ser interfaces de usuario,ventanas, formularios,incluso botones. Se representan
mediante la siguiente notación.

2. Objetos entidad: Representan objetos extraídos del modelo del dominio como por ejemplo:bases de
datos,ficheros,tablas de bases de datos o clases que almacenan algún tipo de información.La notación que
utilizaremos para representarlos es la siguiente:

3. Objetos de control:Las clases de control son, en definitiva, las que manejan a las anteriores,soportando
lo que se ha venido en llamar lógica de negocio.Permiten la interconexion entre objetos entidad y los
objeto frontera.

En el ejemplo Reloj2B, Año, Mes, Día son objetos de entidad, FronteraBotón y FronteraPantallaLCD son
objetos de frontera, ControlCambioFecha es un objeto de control que representa la actividad de cambiar la
fecha oprimiendo combinaciones de botones.

Un objeto de control se crea, por lo general, al inicio del caso de uso y deja de existir cuando termina.
Es responsable de la recopilación de información de los objetos de frontera y de enviarla a los objetos
entidad.
Por ejemplo, los objetos de control describen el comportamiento asociado con la secuencia de formularios,
las colas deshacer y de historia y el envió de información en un sistema distribuido.

Diagrama Robustez 1 1
Restricciones entre las relaciones de objetos

Diagrama Robustez 1 2
Diagrama Robustez 1 3
Identificación de objetos entidad

La Heuristica de Abbott hace corresponder partes del habla(por ejemplo nombres,verbos posesivos,verbos
de acción,adjetivos) con componentes del modelo(por ejemplo objetos,operaciones,relaciones de herencia,
clases).
La tabla 5-1 proporciona ejemplos de tales correspondencias examinando el caso de uso
"ReportarEmergencia" de la figura 5-11.

Diagrama Robustez 1 4
Por ejemplo,después de un primer examen del caso de uso "ReportarEmergencia" (figura 5-11) usamos el
conocimiento del dominio de aplicación y entrevistas con los usuarios para identificar los objetos
(Despachador,ReporteDeEmergencia,OficialCampo e Inccidente). Observe que el objeto
"ReporteDeEmergencia" no se menciona de manera explicita en el caso de uso "ReportarEmergencia". El
paso 3 del caso de uso hace referencia a un reporte de emergencia como "información enviada por el
OficialCampo". Después de revisar con el cliente descubrimos que a esta información se le menciona por lo
general como el reporte de emergencia, y se decide nombrar "ReporteDeEmergencia" al objeto
correspondiente.

Los objetos de frontera representan la interfaz del sistema con los actores. En cada caso de uso, cada actor
interactúa con, al menos, un objeto de frontera. El objeto de frontera recopila la información del actor y la
traduce hacia una forma neutral de interfaz que puede ser usada por los objetos de entidad y también por
los objetos de control.

Los objetos de frontera modelan la interfaz de usuario a un nivel burdo. No describen con detalle los
aspectos visuales de la interfaz de usuario. Por ejemplo, objetos de frontera como "botón" o "concepto de
menú" están demasiado detallados. Primero, los desarrolladores pueden discutir los detalles de interfaz de
usuario con más facilidad con bosquejos y maquetas. Segundo, la idea del diseño de la interfaz de usuario
continuará evolucionando a consecuencia de la prueba de utilidad.

Diagrama Robustez 1 5
Diagrama Robustez 1 6
Examinando el caso de uso "ReportarEmergencia" encontramos los siguientes objetos de frontera (tabla 5-
3)

Observe que el formulario "FormularioIncidente" no se menciona de manera explicita en ningún lugar del
caso de uso "ReportarEmergencia".Identificamos este objeto observando que el "Despachador" necesita
una interfaz para ver el reporte de emergencia enviado por el "OficialCampo" y para regresar un acuse de
recibo. Los términos usados para describir los objetos de frontera en el modelo de análisis deben apegarse
a la terminología del usuario, aunque sea tentador usar términos del dominio de implementación.

Al principio modelamos el flujo de control del caso de uso "ReportarEmergencia" con un objeto de control
para cada actor,"ControlReportarEmergencia" para el "OficialCampo" y "ControlAdministrarEmergencia"
para el "Despachador" respectivamente.(tabla 5-4)

Diagrama Robustez 1 7
La decisión de modelar el flujo de control del caso de uso "ReportarEmergencia" con dos objetos de
control procede del conocimiento de que "EstacionOficialCampo" y "EstacionDespachador" son, de hecho,
dos subsistemas que se comunican a través de un vinculo asíncrono. Esta decisión podría haberse
pospuesto hasta la actividad de diseño del sistema. Por otro lado, hacer visible este concepto en el modelo
de análisis nos permite enfocarnos en el comportamiento excepcional que es la perdida de comunicación
entre ambas estaciones.

Al modelar el caso de uso "ReportarEmergencia" modelamos la misma funcionalidad usando objetos de

entidad,frontera y control. Al cambiar de la perspectiva del flujo de eventos hacia una perspectiva
estructural incrementos el nivel de detalle de la descripción y seleccionamos términos estándar para
referirnos a las entidades del dominio de aplicación y del sistema. En la siguiente sección construimos un
diagrama de secuencia usando el caso de uso "ReportarEmergencia" y los objetos que descubrimos para
asegurar la suficiencia de nuestro modelo.

Ejemplo: El caso de uso del negocio ventas: Del pedido a la entrega

Los trabajadores dan los siguientes pasos en el caso de uso del negocio Ventas: del Pedido a la Entrega
(véase la Figura 6.4):

1. Un comprador solicita bienes o servicios contactando con el vendedor.

2. El vendedor envía una factura al comprador a través del gestor de pagos.
3. El vendedor entrega los bienes o servicios al comprador.
4. El comprador paga mediante el gestor de pagos. Esto implica la transferencia de dinero de la cuenta del
comprador a la del vendedor.

Diagrama Robustez 1 8
El gestor de pagos es un empleado del banco que se encarga de los pasos 2 y 4. Estas tareas pueden
automatizarse mediante un sistema de información.

El comprador, el vendedor y el gestor de pagos estan implicados en el caso de uso del negocio Ventas: del
Pedido a la Entrega. El gestor de pagos transfiere el deniero de una cuenta a ota tal como especifica la
factura

Busqueda de casos de uso a partir de un modelo de negocio

En primer lugar, el analista identifica un *actor* por cada trabajador y por cada actor del negocio (es decir,
cada cliente) que se convertirá en usuario del sistema de información.

Ejemplo: El actor comprador

El comprador utiliza el Sistema de Facturación y Pagos para solicitar bienes o servicios y para pagar facturas.
Por tanto el comprador es tanto un cliente como un actor ya que utiliza el sistema para pedir y pagar
mediante dos casos de uso: Solicitar Bienes o Servicios y Pagar Facturas.

Cada trabajador (y cada actor del negocio) que vaya a ser usuario del sistema de información requerirá un
soporte por parte del mismo. El soporte necesario se determina tratando cada uno de los trabajadores,
uno detrás de otro. Para cada trabajador, identificamos todas las realizaciones de casos de uso del negocio
diferentes en las que participa. El trabajador cumple un papel en cada una, de forma muy parecida al papel
que desempeña una clase en cada realización de caso de uso.

Una vez que hemos encontrado todos los roles de un trabajador o de un actor del negocio, uno por cada
caso de uso del negocio en el que participa, podemos encontrar los casos de uso de los actores del sistema
en el sistema de información. Cada trabajador y cada actor del negocio se corresponde con un actor del
sistema de información. Por cada papel de un trabajador o un actor del negocio, necesitamos un caso de
uso para el actor del sistema correspondiente.

Por tanto la manera más directa de identificar un conjunto tentativo de casos de uso es crear un caso de
uso para el actor correspondiente de cada trabajador y de cada actor del negocio. Como resultado,
obtendremos para cada caso de uso del negocio un caso de uso para cada trabajador y por cada actor del
sistema.

Diagrama Robustez 1 9