Tutorial UML
IV.3 Fase de Construcción: Diseño de Alto Nivel
En la fase de Diseño de Alto Nivel de un ciclo de desarrollo se investiga sobre el problema, sobre los conceptos relacionados con el subconjunto de casos de uso que se esté tratando. Se intenta llegar a una buena comprensión del problema por parte del equipo de desarrollo, sin entrar en cómo va a ser la solución en cuanto a detalles de implementación.
Cuando el ciclo de desarrollo no es el primero, antes de la fase de Diseño de Alto Nivel hay una serie de actividades de planificación. Estas actividades consisten en actualizar los modelos que se tengan según lo que se haya implementado, pues siempre se producen desviaciones entre lo que se ha analizado y diseñado y lo que finalmente se construye. Una vez se tienen los modelos acordes con lo implementado se empieza el nuevo ciclo de desarrollo con la fase de Diseño de Alto Nivel.
En esta fase se trabaja con los modelos de Diseño de Alto Nivel construidos en la fase anterior, ampliándolos con los conceptos correspondientes a los casos de uso que se traten en el ciclo de desarrollo actual.
IV.3.1 Actividades
Las actividades de la fase de Diseño de Alto Nivel son las siguientes:
1. Definir Casos de Uso Esenciales en formato expandido. (si no están definidos )
2. Refinar los Diagramas de Casos de Uso.
3. Refinar el Modelo Conceptual.
4. Refinar el Glosario. (continuado en posteriores fases)
5. Definir los Diagramas de Secuencia del Sistema.
6. Definir Contratos de Operación.
7. Definir Diagramas de Estados. (opcional)
IV.3.2 Modelo Conceptual
Una parte de la investigación sobre el dominio del problema consiste en identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar un Diagrama de Estructura Estática de UML, al que se va a llamar Modelo Conceptual.
En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no de componentes software.
El objetivo de la creación de un Modelo Conceptual es aumentar la comprensión del problema. Por tanto, a la hora de incluir conceptos en el modelo, es mejor crear un modelo con muchos conceptos que quedarse corto y olvidar algún concepto importante.
IV.3.2.1 Identificación de Conceptos
Para identificar conceptos hay que basarse en el documento de Especificación de Requisitos y en el conocimiento general acerca del dominio del problema.
En la Tabla 1 se muestran algunas categorías típicas, junto con ejemplos pertenecientes al dominio de los supermercados y al de la reserva de billetes de avión:
Otro consejo para identificar conceptos consiste en buscar sustantivos en los documentos de requisitos o, más concretamente, en la descripción de los casos de uso. No es un método infalible, pero puede servir de guía para empezar.
Para poner nombre a los conceptos se puede usar la analogía con el cartógrafo, resumida en los siguientes tres puntos:
• Usar los nombres existentes en el territorio: Hay que usar el vocabulario del dominio para nombrar conceptos y atributos.
• Excluir características irrelevantes: Al igual que el cartógrafo elimina características no relevantes según la finalidad del mapa (por ejemplo datos de población en un mapa de carreteras), un Modelo Conceptual puede excluir conceptos en el dominio que no son pertinentes en base a los requisitos.
• No añadir cosas que no están ahí: Si algo no pertenece al dominio del problema no se añade al modelo.
IV.3.2.2 Creación del Modelo Conceptual
Para crear el Modelo Conceptual se siguen los siguientes pasos:
1. Hacer una lista de conceptos candidato usando la Lista de Categorías de Conceptos de la Tabla 1 y la búsqueda de sustantivos relacionados con los requisitos en consideración en este ciclo.
2. Representarlos en un diagrama.
3. Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer.
4. Añadir los atributos necesarios para contener toda la información que se necesite conocer de cada concepto.
IV.3.2.3 Identificación de Asociaciones
Una asociación es una relación entre conceptos que indica una conexión con sentido y que es de interés en el conjunto de casos de uso que se está tratando.
Se incluyen en el modelo las asociaciones siguientes:
• Asociaciones para las que el conocimiento de la relación necesita mantenerse por un cierto período de tiempo (asociaciones “necesita-conocer”).
• Asociaciones derivadas de la Lista de Asociaciones Típicas que se muestra en la Tabla 2.
Tabla 1 Lista de Conceptos Típicos
Tipo de Concepto Ejemplos
Objetos físicos o tangibles Avión
Terminal de Caja
Especificaciones, diseños o descripciones de cosas Especificación de Producto
Descripción de Vuelo
Lugares Supermercado
Aeropuerto
Transacciones Venta, Pago
Reserva
Líneas de una transacción Artículo de Venta
Roles de una persona Cajero
Piloto
Contenedores de otras cosas Supermercado, Cesta
Avión
Cosas en un contenedor Artículo
Pasajero
Otros ordenadores o sistemas electromecánicos externos a nuestro sistema Sistema de Autorización de Tarjetas de Crédito
Sistema Controlador de Tráfico Aéreo
Conceptos abstractos Hambre
Organizaciones Departamento de Ventas
Compañía Aérea Toto
Eventos Venta, Robo, Reunión
Vuelo, Accidente, Aterrizaje
Reglas y políticas Política de Devoluciones
Política de Cancelaciones
Catálogos Catálogo de Productos
Catálogo de Piezas
Archivos financieros, de trabajo, de contratos, de asuntos legales Recibo, Contrato de Empleo
Registro de Revisiones
Instrumentos y servicios financieros Línea de Crédito
Stock
Manuales, libros Manual del Empleado
Manual de Reparaciones
Tabla 2 Lista de Asociaciones Típicas
Categoría Ejemplos
A es una parte física de B Ala – Avión
A es una parte lógica de B Artículo en Venta –Venta
A está físicamente contenido en B Artículo – Estantería
Pasajero – Avión
A está lógicamente contenido en B Descripción de Artículo – Catálogo
A es una descripción de B Descripción de Artículo – Artículo
A es un elemento en una transacción o un informe B Trabajo de Reparación – Registro de Reparaciones
A es registrado/archivado/capturado en B Venta – Terminal de Caja
A es un miembro de B Cajero – Supermercado
Piloto – Compañía Aérea
A es una subunidad organizativa de B Sección – Supermercado
Mantenimiento – Compañía Aérea
A usa o gestiona B Cajero – Terminal de Caja
Piloto – Avión
A comunica con B Cliente – Cajero
Empleado de Agencia de Viajes – Pasajero
A está relacionado con una transacción B Cliente – Pago
Pasajero – Billete
A es una transacción relacionada con otra transacción B Pago – Venta
Reserva – Cancelación
A está junto a B Ciudad – Ciudad
A posee B Supermercado – Terminal de Caja
Compañía Aérea – Avión
Una vez identificadas las asociaciones se representan en el Modelo Conceptual con la multiplicidad adecuada.
IV.3.2.4 Identificación de Atributos
Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de información de los casos de uso que se estén desarrollando en ese momento.
Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los tipos complejos deberían ser modelados como conceptos y ser relacionados mediante asociaciones.
Incluso cuando un valor es de un tipo simple es más conveniente representarlo como concepto en las siguientes ocasiones:
• Se compone de distintas secciones. Por ejemplo: un número de teléfono, el nombre de una persona, etc.
• Tiene operaciones asociadas, tales como validación. Ejemplo: NIF.
• Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin.
• Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesetas o en euros.
Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no es un modelo definitivo, pues a lo largo del desarrollo se va refinando según se le añaden conceptos que se habían pasado por alto.
IV.3.3 Glosario
En el glosario debe aparecer una descripción textual de cualquier elemento de cualquier modelo, para eliminar toda posible ambigüedad. Se ordena alfabéticamente por término.
Un formato tipo para el glosario es el que se muestra en la Tabla 3.
Tabla 3 Formato tipo de Glosario
Término Categoría Descripción
Banco concepto Entidad que ofrece servicios financieros a sus clientes
Realizar Reintegro caso de uso El Cliente realiza un reintegro de su cuenta
... ... ...
IV.3.4 Diagramas de Secuencia del Sistema
Además de investigar sobre los conceptos del sistema y su estructura, también es preciso investigar en el Diseño de Alto Nivel sobre el comportamiento del sistema, visto éste como una caja negra. Una parte de la descripción del comportamiento del sistema se realiza mediante los Diagramas de Secuencia del Sistema.
En cada caso de uso se muestra una interacción de actores con el sistema. En esta interacción los actores generan eventos, solicitando al sistema operaciones. Por ejemplo, en el caso de una reserva de un billete de avión, el empleado de la agencia de viajes solicita al sistema de reservas que realice una reserva. El evento que supone esa solicitud inicia una operación en el sistema de reservas.
Los casos de uso representan una interacción genérica. Una instancia de un caso de uso se denomina escenario, y muestra una ejecución real del caso de uso, con las posibles bifurcaciones y alternativas resueltas de forma particular.
Un Diagrama de Secuencia de Sistema se representa usando la notación para diagramas de secuencia de UML (ver página 11). En él se muestra para un escenario particular de un caso de uso los eventos que los actores generan, su orden, y los eventos que se intercambian entre sistemas.
Para cada caso de uso que se esté tratando se realiza un diagrama para el curso típico de eventos, y además se realiza un diagrama para los cursos alternativos de mayor interés.
En la Figura 38 se muestra el Diagrama de Secuencia del Sistema para el caso de uso Realizar Reintegro de un cajero automático.
Figura 38 Ejemplo de Diagrama de Secuencia del Sistema
IV.3.4.1 Construcción de un Diagrama de Secuencia del Sistema
Para construir un Diagrama de Secuencia del Sistema para el curso típico de eventos de un caso de uso, se siguen los siguientes pasos:
1. Representar el sistema como un objeto con una línea debajo.
2. Identificar los actores que directamente operan con el sistema, y dibujar una línea para cada uno de ellos.
3. Partiendo del texto del curso típico de eventos del caso de uso, identificar los eventos (externos) del sistema que cada actor genera y representarlos en el diagrama.
4. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama.
Los eventos del sistema deberían expresarse en base a la noción de operación que representan, en vez de en base a la interfaz particular. Por ejemplo, se prefiere “finalizarOperación” a “presionadaTeclaEnter”, porque captura la finalidad de la operación sin realizar compromisos en cuanto a la interfaz usada.
IV.3.5 Contratos de Operaciones
Una vez se tienen las Operaciones del Sistema identificadas en los Diagramas de Secuencia, se describe mediante contratos el comportamiento esperado del sistema en cada operación.
Un Contrato es un documento que describe qué es lo que se espera de una operación. Tiene una redacción en estilo declarativo, enfatizando en el qué más que en el cómo. Lo más común es expresar los contratos en forma de pre- y post-condiciones en torno a cambios de estado.
Se puede escribir un contrato para un método individual de una clase software, o para una operación del sistema completa. En este punto se verá únicamente éste último caso.
Un Contrato de Operación del Sistema describe cambios en el estado del sistema cuando una operación del sistema es invocada.
A continuación se ve un ejemplo de Contrato:
Contrato
Nombre: leerTarjeta (número_tarjeta: número)
Responsabilidades: Comprobar que la tarjeta numero_tarjeta es correcta y presentar las opciones disponibles.
Referencias Cruzadas: Funciones del Sistema: R1.2, R1.6, R1.7
Casos de Uso: Reintegro
Notas:
Excepciones: Si la tarjeta es ilegible o no pertenece a los tipos de tarjetas aceptadas, indicar que ha habido un error.
Salida:
Pre-condiciones: No hay una operación activa.
Post-condiciones: • Una nueva Operación se ha creado. (creación de instancia).
• La Operación se ha asociado con Cajero. (asociación formada).
La descripción de cada apartado de un contrato es como sigue:
Nombre: Nombre de la operación y parámetros.
Responsabilidades: Una descripción informal de las responsabilidades que la operación debe desempeñar.
Referencias Cruzadas: Números de referencia en los requisitos de funciones del sistema, casos de uso, etc.
Notas: Comentarios de diseño, algoritmos, etc.
Excepciones: Casos excepcionales. Situaciones que debemos tener en cuenta que pueden pasar. Se indica también qué se hace cuando ocurre la excepción.
Salida: Salidas que no corresponden a la interfaz de usuario, como mensajes o registros que se envían fuera del sistema. (En la mayor parte de las operaciones del sistema este apartado queda vacío)
Pre-condiciones: Suposiciones acerca del estado del sistema antes de ejecutar la operación.
Post-condiciones: El estado del sistema después de completar la operación.
IV.3.5.1 Construcción de un Contrato
Los pasos a seguir para construir un contrato son los siguientes:
1. Identificar las operaciones del sistema a partir de los Diagramas de Secuencia del Sistema.
2. Para cada operación del sistema construir un contrato.
3. Empezar escribiendo el apartado de Responsabilidades, describiendo informalmente el propósito de la operación. Este es el apartado más importante del contrato.
4. A continuación rellenar el apartado de Post-condiciones, describiendo declarativamente los cambios de estado que sufren los objetos en el Modelo Conceptual. Puede ser que este apartado quede vacío si no cambia el valor de ningún dato de los maneja el sistema (por ejemplo en una operación del sistema que tan solo se encarga de sacar por pantalla algo al usuario).
5. Para describir las post-condiciones, usar las siguientes categorías:
• Creación y borrado de instancias.
• Modificación de atributos.
• Asociaciones formadas y retiradas.
6. Completar el resto de apartados en su caso.
IV.3.5.2 Post-condiciones
Las post-condiciones se basan en el Modelo Conceptual, en los cambios que sufren los elementos del mismo una vez se ha realizado la operación.
Es mejor usar el tiempo pasado o el pretérito perfecto al redactar una post-condición, para enfatizar que se trata de declaraciones sobre un cambio en el estado que ya ha pasado. Por ejemplo es mejor decir “se ha creado un nuevo Cliente” que decir “crear un Cliente”.
Cuando se ha creado un objeto, lo normal es que se haya asociado a algún otro objeto ya existente, porque si no queda aislado del resto del sistema. Por tanto, al escribir las post-condiciones hay que acordarse de añadir asociaciones a los objetos creados. Olvidar incluir estas asociaciones es el fallo más común cometido al escribir las post-condiciones de un contrato.
IV.3.6 Diagramas de Estados
Para modelar el comportamiento del sistema pueden usarse los Diagramas de Estados que define UML (ver página 13).
Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos:
- Una clase software.
- Un concepto.
- Un caso de uso.
En la fase de Diseño de Alto Nivel sólo se haría para los dos últimos tipos de elemento, pues una clase software pertenece al Diagrama de Clases de Diseño.
Puesto que el sistema entero puede ser representado por un concepto, también se puede modelar el comportamiento del sistema completo mediante un Diagrama de Estados.
La utilidad de un Diagrama de Estados en esta fase reside en mostrar la secuencia permitida de eventos externos que pueden ser reconocidos y tratados por el sistema. Por ejemplo, no se puede insertar una tarjeta en un cajero automático si se está en el transcurso de una operación.
Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de Estados del sistema sería una combinación de los diagramas de todos los casos de uso.
El uso de Diagramas de Estados es opcional. Tan solo los usaremos cuando consideremos que nos ayudan a expresar mejor el comportamiento del elemento descrito.
