Ana José Medina Romero

INDICE

1. INTRODUCCIÓN

2. ELEMENTOS DEL DISEÑO DE CASOS DE USO

EN RUP

3. CLASES

4. MODELO DE DISEÑO

5. PASOS A DISCUTIR

6. CRITERIOS DE LA ARQUITECTURA

7. DISEÑO DE LOS CASOS DE USO

Paso 1: Crear realización de casos de uso

Paso 2: Descripción de la interacción
Paso 3: Simplificación del diagrama de
secuencia
Paso 4: Descripción de la conducta
consistencia-relación.
Paso 5: Descripción de los mecanismos de
diseño.

8. CONCLUSIONES
1. INTRODUCCIÓN

En este documento se explicará la segunda parte sobre la

transformación de los requisitos capturados en casos de uso y código
implementable.

La primera parte fue dedicada al análisis de los casos de uso,

en la que se introdujo un estudio de un caso simple de alquiler de
vehículo.

Por lo tanto ahora nos centraremos en la transformación de esos

casos de uso a código.

2. ELEMENTOS DEL DISEÑO DE CASOS DE USO EN RUP

La figura 1 que se muestra a continuación está sacada de RUP.

Nos muestra que el diseño de casos de uso está en el mismo

contexto que las otras actividades de análisis y diseño.

Figure 1: Use Case Design activity in RUP

En RUP el propósito del diseño de casos de uso es el siguiente:

• Refinar la realización de casos de uso en términos de

interacciones.
• Refinar requisitos en los métodos u operaciones de las clases
del diseño.
• Refinar requisitos en las operaciones de subsistemas y/o sus
interfaces.
 Podemos alternativamente expresar que la meta del diseño de
casos de uso es transformar cada abstracción del proyecto en una o más
clases de diseño que sean representaciones implementables.

La implementación de las clases se realiza después de que el

diseño sea estable. En el diseño, deseamos expresar, apropiadamente,
cómo acercarnos a la implementación de modo que la programación real
sea sólo cuestión del lenguaje y de la plataforma.

En la figura 2 se ilustran los pasos que constituyen el diseño

de los casos de uso.

Figure 2: The steps of Use Case Design

La actividad del diseño implica el mantenimiento de múltiples

perspectivas simultáneamente en el sistema del software que se está
construyendo.

Por ejemplo, al igual que un cubo tiene 6 caras, las cuales son
independientes, pero forman parte del mismo todo, el diseño de un
sistema es multi-faceta, incluyendo: implementación, despliegue,
arquitectura, componentes, clases, patrones, interfaces, estructura
estática e interacciones, etc., y todo forma parte del mismo proyecto.
3. CLASES

Se poseen objetos orientados y componentes basados en el diseño

de estrategias enfocadas o que se centran en clases.

En la disciplina del diseño, describiremos nuestras clases, y

sus relaciones con otras clases o subsistemas, de manera que ahora
tengamos en cuenta lo importante de la tecnología.

Preocupaciones:

• ¿Cómo represento relaciones uno a muchos o muchos a muchos

entre dos clases?
• ¿Cómo represento el acceso desde y hacia un dato almacenado?
• ¿Qué aspectos de mi clase deben ser visibles a los objetos de
otras clases?
• ¿Qué aspectos deben ser invisibles a otras clases?
• ¿Cómo proporciono una interfaz simplificada a los objetos
múltiples?
• ¿Cómo separo el comportamiento de mis clases con el
comportamiento de la tecnología que mi sistema requiere?

4. EL MODELO DE DISEÑO

El resultado de nuestras actividades en el diseño de casos de

uso, producirá el contenido del Design Model, modelo de diseño, de
RUP, incluyendo (no limitado):

• Las clases del diseño (es decir, clases de análisis más

clases de la tecnología) necesitadas en nuestro sistema.
• La realización del contenido del documento de la arquitectura
del software a través del diseño de clases.
• Las operaciones y las cualidades que cada clase del diseño
poseerá.
• La especificación de los tipos de datos actuales, de los
valores iniciales, o de las interfaces para los subsistemas
específicos.
• División de nuestro sistema funcionalmente por subsistemas o
categoría arquitectónica.

El modelo de diseño se convertirá en la materia prima que

nuestra disciplina de implementación transformará en código
ejecutable.
5. PASOS A DISCUTIR

En el diseño de casos de uso se siguen los pasos de la Figura 2,

añadiendo como se puede ver en la lista siguiente el de definir los
mecanismos del diseño.

Por lo tanto, los pasos a seguir en el diseño de casos de uso

serían los siguientes:

• Crear las realizaciones de los casos de uso.

• Describir las interacciones entre los objetos del diseño.
• Simplificar los diagramas de secuencia usando subsistemas
(opcionales).
• Describir el comportamiento constancia-relacionado.
• Definir los mecanismos de diseño.
• Refinar el flujo de la descripción de los acontecimientos.
• Unificar las clases y los subsistemas.
• Evaluar los resultados.

Es importante resaltar que el orden de estos parámetros no es

fijo. La secuencia puede variar en función de la comprensión que se
tenga del dominio que se está diseñando, de la experiencia con RUP, de
las preferencias personales por los modelos a utilizar, o de la
metáfora seguida para señalar las características de las clases del
diseño.

Lo importante es que se alcance una expresión comprensiva de la

solución que se pondrá en ejecución

6. CRITERIOS DE LA ARQUITECTURA

Para empezar, puesto que el diseño es íntimamente construido

para y por la arquitectura, habrá que consultar a nuestro arquitecto y
conseguir una idea de la arquitectura total prevista para nuestro
sistema.

Para esta discusión, vamos a estipular que el arquitecto ha

elaborado un documento de la arquitectura que indica que ésta se debe
apoyar en los criterios técnicos siguientes:

1. Escalabilidad: Habrá sesiones múltiples y simultáneas de los

clientes, las cuales deben ser independientes unas de otras y
el sistema deber escalar de forma transparente a los cientos
de clientes simultáneos.
2. Capacidad de Mantenimiento: Las actualizaciones de los
componentes de software se deben hacer fácil y centralmente.
3. Simplicidad Técnica: No se desea personal que se mueva en JEE
o NET. El personal está bien formado en Java, Java
ServerPages, servlets, y Javascript.
4. Tecnología: Internet debe de ser el medio de comunicación
entre el browser y los servidores.
 En la Figura 3 se muestran los modelos arquitectónicos simples
de UML:

Figure 3: Initial deployment diagram for kiosk system

Como hemos dicho antes, aquí se ilustra la vista más simple. En

la figura 4 se muestra en mayor detalle.

Figure 4: High-level physical architecture diagram

 En la figura 4 se refleja la estructura de alto nivel de nuestra
aplicación basada en el JavaServerPage (JSP). El cliente actúa con un
navegador en una computadora que actúa como cliente. El navegador se
comunica vía HTTP (Protocolo de Transmisión de Hipertexto) al servidor
Web, invocando al servlets en el servidor Web. Se ha mostrado
únicamente la reserva de un vehículo específico. El servlet actúa en
el papel de director, coordinando los pasos necesarios para llevar a
cabo el trabajo de caso de uso “Reserva de Vehiculo”. El servlets crea
y actúa con los objetos del trabajo, como pueden ser Reserva
(Reservation), Cliente (Customer), que el JSP necesitará. El servlets
remite la demanda de servicio al JSP apropiado.

7. DISEÑO DE CASOS DE USO

Paso 1:
Crear la realización de caso de uso para cada uno de los casos de uso

La realización de casos de uso es realmente una colección de

varios diagramas UML y otros artefactos textuales, como los documentos
de Realización y Especificación de Casos de Uso de RUP, que juntos
validan que nosotros tenemos las clases, responsabilidades e
interacciones de los objetos necesarios para dictaminar el
comportamiento que debe tener el proceso de nuestro caso de uso.

En el análisis, nuestra realización de casos de uso contiene

sólo el análisis de clases y objetos, los cuales pueden poblar varios
diagramas UML, como pueden ser los diagramas de clases y los de
interacción. En nuestro diseño, la realización contendrá información
que explica como los pasos dentro de un caso de uso se llevarán a cabo
colaborando con el diseño de objetos. Los diagramas de clase, de
interacción y descripción derivados de los requisitos poblarán
nuestras realizaciones.

Paso 2:
Descripción de las interacciones entre los objetos del plan

Éste es un paso complejo. En la Figura 5 se muestra el diagrama

de clases para el alquiler de un Vehículo, en el cual también se
muestran los atributos de cada clase.
 Figure 5: Analysis-level class diagram

Esto es una descripción inicial y las relaciones entre las

varias clases, pero no está todavía en un formato implementable.
Ejemplos:
• ¿Qué significa que la relación entre VehicleInventory y
Vehicle es una agregación, pero la realción entre
RentalLocation y VehicleInventory es una composición?
• ¿Cómo expresamos que en el diseño Reservation debe tener
acceso a 0 o más objetos de ProtectionProduct?
• ¿Qué tipos de datos especificamos para el status de Vehicle y
el atributo specialEquipment, o para los atributos de
Reservation?
• ¿Dónde descubriremos las funciones que debemos de poner en
las clases?
• ¿Cómo representaremos una interfaz para una reserva, para el
cambio en el estado de una reserva o de un vehículo?
 Antes de responder a estas preguntas, podemos revisar el
diagrama de secuencia que se describió en la parte 1 para el caso de
uso “Check in Passenger” como se muestra en la figura 6:

Figure 6: Analysis-level sequence diagram (SQD)

En el análisis de Casos de uso, nuestra meta era demostrar la

posibilidad que nuestros objetos tienen de llevar a cabo los pasos
necesarios para realizar el caso de uso de Reserva de un Vehículo.
Nosotros simplificamos nuestra tarea asumiendo que nuestros objetos
son perennes e ignoramos la creación y destrucción de objetos. Pero
ahora, en el diseño, tenemos que demostrar explícitamente la creación
(y destrucción, dependiendo del lenguaje usado en la programación) de
nuestros objetos. También debemos de preguntar “Quien está al cargo”
de acceder y “de unir” los objetos necesarios para surtir las
necesidades del cliente.

Centrémonos en cómo transformamos este diagrama de secuencia en

una perspectiva del diseño con interacciones entre nuestros objetos.
Empezamos de nuevo con el caso de uso Reserva de Vehículo
especificando el escenario “camino feliz” donde nada sale mal.
 ¿Cómo empezará realmente dicho caso de uso? En la figura 7 se
muestra un trozo del diagrama de secuencia capturando la interacción
entre los objetos.

Cuando el cliente visita el sitio Web en el paso 1, la página de

bienvenida es visible en el navegador del cliente, a la vez se
presentan campos de la entrada que el cliente puede rellenar: fecha y
categoría del vehículo que desea reservar. Cuando el cliente en el
Paso 2 indica que requiere del sistema para buscar vehículos que
emparejen con estos criterios, el JSP, manda por correo los datos del
formulario al servlet de la Reserva (RsvnServlet) en el Paso 3. El
servlet tiene que verificar que la situación del arriendo seleccionada
se corresponde realmente con las fechas y tiempos seleccionados por el
cliente, para que en el paso 4 el servlet cree un objeto
RentalLocation vacío, y en el Paso 5 este objeto se rellenará con los
datos de la situación designada por el identificador de la situación
que se ha seleccionado. RentalLocation tiene que obtener esta
información existente de nuestra reserva on-line RDBMS, y en el Paso 6
ya hemos añadido una nueva clase de diseño, DataAccess, que implementa
el modelo Façade. Este modelo nos permite ocultar un interfaz
complicado sustituyendo una clase o un componente por un interfaz
simplificado. El objeto RentalLocation invoca al método
retrieveLocation(locationID) en el objeto DataAccess, el cual devuelve
una fila de datos estructurada. En el Paso 7 RentalLocation llama a un
método privado de sí mismo, fill(dbRecord) que analiza los datos
erróneos y asigna los campos apropiados a sus variable. A la
conclusión del Paso 7, esta instancia de RentalLocation es totalmente
poblada para una situación de arriendo específica. En el Paso 8 el
servlet hace una pregunta específica de la situación de arriendo a
través de validate(dates). Si todo es correcto la respuesta será “yes”
(OK).

Desde que la situación es abierta en los momentos y fechas

seleccionados, los servlets obtendrán la lista de vehículos que
emparejan con la demanda del cliente y se los mostrarán a dicho
cliente. En el Paso 9 el RsvnServlet crea una instancia vacía de
VehicleInventory para sostener los vehículos que emparejan con el
criterio del cliente. El en paso 10, el servlet invoca a populate() en
VehicleInventory, pasándole el criterio de la selección. Desde que la
situación del vehículo está disponible on-line, en el Paso 11 el
VehicleInventory invoca a un método, retrieveVehicles(collection), en
el objeto DataAccess. Este método sabe como crear un objeto Vehicle
vacío (Paso 12), obteniendo información del vehículo de la compañía
RDBMS (no mostrado), y en el Paso 13 invoca al método, fill(dbRecord),
en el objeto Vehicle creado. En fill(dbRecord), el objeto Vehicle
analiza los datos del dbRecord (una fila de datos), y completa las
instancias de sus propias varibles. En el paso 14 el objeto DataAccess
agrega el now-filled en el objeto Vehicle al VehicleInventory. Los
pasos 12-14 se repiten hasta que todos los vehículos concuerdan con el
resultado que han sido descritos en los objetos. Después del Paso 14,
VehicleInventory y el servlet notifican que sus demandas se han
completado.

El sistema tiene que proporcionar ahora los vehículos

concordantes disponibles al cliente. En los Pasos 15 y 16, el servlet
guarda los objetos en el objeto Session, para ser recuperado por el
próximo JSP, e invoca el método RequestDispachet.forward() para
mostrar el JSP ShowInventory en el Paso 17.

En este trozo de nuestro diseño, tenemos casi tantos mensajes

como en el diagrama de secuencia entero.

Ahora ya podemos reconstruir el diagrama de clases mostrado en

la figura 5, como se muestra en la figura 8.
 Figure 8: First class diagram updated with operations

Hasta ahora solo hemos mirado el comportamiento de recibir los

datos on-line. Tendremos que ver las salidas que produce el proceso de
arriendo cuando un cliente selecciona un vehículo específico para
reservar.
 Miremos el diagrama de secuencia de la figura 9:

Figure 9: Design SQD for second part of Reserve a Vehicle

En el paso 1 el cliente indica que desea reservar un vehículo

específico. Esta demanda se enviará al servlet que le pide al
VehicleInventory que marque el vehículo denotado por un vehicleID como
no disponible temporalmente. De esta manera se le impedirá a otro
cliente reservar el mismo vehículo. VehicleInventory a través del
método mark(expiry) indica mediante el parámetro expiry (vencimiento)
el periodo de tiempo que el cliente puede estar sin completar la
reserva, pasado ese tiempo se anulará la reserva.
 Después de marcar el vehículo, el servlet necesita preparar el
despliegue de la página de “Información de Arrendatario”, en la que el
cliente verifica la información que hay en ella. En el Paso 5 el
servlet obtiene el customerID que se habría anotado en la página de
bienvenida. Con este identificador el servelet crea (en el Paso 6) un
objeto Cliente, dirigido para populate().

En los pasos 8 y 9 el objeto Cliente sigue el modelo “familiar”

de solicitar este contenido como un dbRecord del objeto DataAccess.
Con el objeto Cliente ahora instanciaremos y poblaremos nuestro
cliente específico, en el paso 10 el servelet informa al objeto
Cliente de su correspondiente CustomerProfile (perfil de cliente).

En el paso 11 el Cliente notifica el perfil que este es el

contenido de su perfil. Ahora tenemos una asociación bidireccional
entre estos dos objetos.

Con este proceso completado, el servlet está listo para mostrar

la página de “Información de Arrendatario”, que se hace con el método
RequestDispatcher.forward().

En el paso 13, la página es activada. En los pasos 14-16 el JSP

obtendrá información genérica del objeto Customer (Cliente) y del
CustomerProfile (perfil del cliente) y mostrará los correspondientes
datos de confirmación.

En el Paso 17 la página de Información será mostrada al

navegador del cliente para la confirmación.

En el paso 18 el cliente indica si afirma, cambia y si se

continúa con la reserva.

En el paso 19 se muestra de nuevo genéricamente que el JSP

actuará recíprocamente con el objeto cliente y perfil del cliente
actualizándolos con los datos de la pantalla.

En el paso 20, la página de información se enviará la servlet,

indicando que la información de la reserva es completa. Después de
esto, nosotros debemos modelar como el sistema presentará un resumen
de la información de la reserva, incluyendo ofertas para comprar,
protección de productos, etc.

Se ha expuesto un trozo de la interacción y se han mostrado más

operaciones en nuestras clases.
Nuevo diagrama de clases en la figura 10.

Figure 10: Second class diagram updated with operations

Podemos observar que se han añadido nuevos métodos a Vehicle,

Customer y CustomerProfile. De nuestro caso de uso y lista de clases
escogemos objetos para interactuar y construimos un SQD para mostrar
esa interacción.

Los mensajes en análisis son asignados a las clases según la

responsabilidad que le hemos asignado. Los mensajes son elevados a los
métodos de la clase receptora del mensaje.

Estos métodos son necesarios porque se generan para encontrar

las metas del caso de uso que contiene muchos de los requisitos
funcionales de nuestro sistema.
Paso 3:
Simplificación del diagrama de secuencia usando subsistemas (opcional)

Este paso simplificará la conducta repetida reemplazando

agrupaciones comunes de objetos con un subsistema.

Necesitamos agrupar clases que tienen una meta común dentro de

un límite claro. Un cambio dentro de este paquete cerrado afecta a
todas las clases.

Así se pueden desarrollar modelos separados para las

interacciones internas, pudiéndose utilizar como un componente
reusable en nuestro sistema global.

Paso 4:
Descripción de la conducta consistencia-relación

Además del aislamiento físico descrito en nuestro documento de

arquitectura, necesitamos un aislamiento lógico.

Para ello introduciremos tres nuevos objetos:

• Un objeto factory, el cuál creará el objeto de análisis para

nosotros.
• Un objeto DB, el cual es el DBMS “gemelo” de un objeto de
análisis.
• persistente interface, un subsistema que está especializado
en coger información de entrada y de salida de un almacén de
datos.

En el diagrama de secuencia que se muestra en la figura 11, se

han introducido estos tres objetos y se han recreado las
interacciones.
 Figure 11: Design sequence diagram with persistence layer

Este es un diseño mucho más encapsulado. Para cada objeto del

análisis (por ejemplo, Cliente) que debe guardarse o recuperarse del
DBMS, nosotros creamos un “DB-aware” (la “base de datos consciente”)
que entiende los campos de datos.

Estos objetos residirán en el Servidor Web, y se creará y se

usará por uno de los servlets. El objeto DB-aware sabe cómo y dónde
conectar, cómo construir una declaración de SQL y conseguir
ejecutarlo, cómo tomar los datos del resultado y guardarlo en el
objeto de análisis.

Deberemos evaluar nuestra estructura de almacenamiento para

asegurar que también podemos guardar y recuperar los datos requeridos
por nuestros objetos.

Las Tablas 1-7 indican una muestra del modelo lógico. Nótese que
la mayoría de los campos de estas tablas, emparejan con los atributos
de nuestras clases, exceptuando algún caso como es el de la Tabla 3,
fecha de compra del vehículo, que no existe en nuestra clase
correspondiente porque dicho campo no es relevante en la reserva de un
vehículo.
Table 1: Rental location

LocationID Street Sales

State
<PK> Address Region

Table 2: Reservation

ReservationI LocationI VIN CustomerI StartDat ReturnDa Quote Payme

D D <FK D e te d nt
<PK> <FK> > <FK> &Time &Time Cost Method

Table 3: Vehicle

Assigned
.
VIN Location Vehicle Date Of Current
Manufacturer Make Model .
<PK> <PK> Category Purchase Mileage
.
<FK>

Table 4: Protection product

ProductType Eligibility Lower Upper Benefit

<PK> Codes Limit Limit Increment

Table 5: Customer

CustomerI Othe Driver Licens Dat

Street Email Busines Issuin
D Nam r s e e Of
Addres Addres s g
<PK> e Phon Licens Exp. Birt
s s Phone State
<FK> e e# Date h

Table 6: Customer profile

Default
CustomerID Default Default Default
Smoking Personal
<PK> Vehicle Damage Supplemental
Preference Accident
<FK> Category Waiver Liability
Insur.

Table 7: Award program

AwardID/CustID Current
YTD Redemptions
<PK> <FK> Balance
 Notar que las propiedades de la clave primaria (<PK>) y la clave
foránea (<FK>) representan las relaciones en los diagramas de clases.
La tabla correspondiente a la reserva (Reservation) sabe su cliente
(Customer) a través del campo <FK> de la tabla correspondiente al
perfil del cliente (CustomerProfile).

Una sentencia SQL podría ser:

“SELECT * FROM VEHICLE WHERE ASSIGNEDLOCATION = 42355 ORDER BY

VEHICLE.VEHICLECATEGORY”

Devolverá todos los vehículos asignados a esa situación

ordenados por categoría.

Paso 5:
Descripción de los mecanismos del diseño

Necesidades dentro de los mecanismos de análisis:

• Persistencia: Necesitamos un mecanismo de persistencia para

guardar los cambios que se hagan en los objetos.

• Seguridad: No se mostrarán los datos a un individuo que no se

identifique y autentifique.

• Interfaz del legado: Toda la información del vehículo

proviene de un sistema que tiene toda la información
centralizada para todas las situaciones de arriendo.

8. CONCLUSIONES

Se han proporcionado numerosos ejemplos que muestran como pasar

de casos de uso iniciales, los cuales contienen muchos de los
requisitos de nuestro sistema, al análisis del dominio de nuestro
problema, al diseño del dominio de nuestra solución en el contexto de
dependencias técnicas específicas para nuestro ambiente de producción.

Hay muchos más temas que tienen que ser considerados en el

desarrollo del sistema, pero estos ejemplos valen para ofrecer una
guía práctica del proceso.