Dirección de Servicios de Información Administrativa

Vicerrectorado Administrativo
Universidad de Los Andes

Propuesta para el
Documento de Diseño de Sistemas
de la DSIA

Versión 1.0

Grupo de Diseño de la DSIA

William J. Montilva C.
Lena Sánchez B.
Luís E. Porras C.
Marisol Díaz B.

Marzo, 2008
1 Introducción
Este informe presenta una propuesta de la estructura que podría llevar el documento de
diseño del sistema (DDS) elaborado por el Grupo de Diseño adscrito a la Unidad de
Desarrollo de la Dirección de Servicios de Información Administrativa (UD-DSIA) de la
Universidad de Los Andes.
El documento DDS será utilizado por el Grupo de Programación de la UD-DSIA como una
guía para la codificación e implementación de los sistemas o aplicaciones que pudieran ser
desarrollados para las unidades administrativas de esta institución universitaria.
Entre los objetivos que persigue esta propuesta para la especificación del diseño de
software tenemos:
1. Producir un documento técnico que describa todos los detalles del diseño de la
arquitectura del sistema o aplicación y de todos los componentes que la conforman.
2. Proporcionar todos los detalles técnicos requeridos por el Grupo de Programación
para programar o producir cada uno de los componentes de software de la
aplicación o sistema.
3. Servir de insumo para la planificación y ejecución de las pruebas de unidad,
integración y aceptación que realizará el Grupo de Pruebas al sistema.
4. Servir como material de guía o entrenamiento al nuevo personal que pueda ser
incorporado a un proyecto, proporcionando la información necesaria de cómo una
solución ha sido diseñada y como va a ser implementada.
5. Servir como un acuerdo entre el Grupo de Diseño, el Grupo de Programación y el
Grupo de Pruebas, de cómo va a ser implementada y probada la funcionalidad
descrita en la especificación de requisitos del sistema.
Esta propuesta ha sido organizada de la siguiente manera. La estructura del DDS, en su
primera versión, es presentada en la sección 2. La sección 3 describe cada uno de los puntos
(secciones o apartados) que contiene el DDS. La sección 4 presenta algunas de las fichas
técnicas creadas por el Grupo de Diseño de la DSIA, utilizadas para describir las notaciones
empleadas para construir los diversos de diagramas de UML presentes en el documento
DDS.

2 Estructura del Documento de Diseño

Con la finalidad de producir un documento de diseño que cumpla con los objetivos antes
mencionados, presentamos aquí una propuesta inicial de la estructura de dicho documento,
el cual se muestra en la figura 1.
Portada del documento

Tabla de Contenido

1. Introducción
1.1. Propósito del sistema
1.2. Objetivos y restricciones de diseño
1.3. Definiciones, acrónimos y abreviaturas
1.4. Referencias
1.5. Estructura del documento

2. Arquitectura del Sistema

2.1. Arquitectura lógica (descomposición en subsistemas)
2.2. Arquitectura física (topología del sistema)

3. Diseño de los subsistemas

3.1. Diseño del subsistema <nombre del subsistema 1>
3.1.1. Vista de uso del subsistema
3.1.2. Vista de datos del subsistema
3.1.3. Realizaciones de Casos de Uso
3.1.3.1. Realización del caso de uso <nombre caso de uso 1>
3.1.3.1.1. Escenario del caso de uso
3.1.3.1.2. Diagrama de clase del caso de uso
3.1.3.1.3. Diagrama de secuencia detallado del caso de uso
3.1.3.1.4. Interfaz gráfica de usuario del caso de uso
3.1.3.1.5. Diagrama de navegación del caso de uso
3.1.3.2. Realización del caso de uso <nombre caso de uso 2>
3.2. Diseño del subsistema <nombre del subsistema 2>

4. Diseño de la Base de Datos

4.1. Esquema Conceptual
4.2. Esquema Implementable
4.3. Diccionario de Datos

Anexos

Figura 1. Estructura del Documento de Diseño del Sistema (DDS)

3 Descripción de las secciones del documento

A continuación se describe con detalle el contenido de cada una de las secciones de la
plantilla propuesta para el documento de diseño.
3.1 Portada del documento
La portada del DDS contendrá los siguientes elementos:
• Nombre del proyecto o sistema: señala el nombre del proyecto o sistema que
va a ser desarrollado.
• Identificador del proyecto: corresponde a un número interno que la
organización le asigna a un determinado proyecto.
• Versión: es un número compuesto de dos dígitos que hace referencia a la
versión del documento de diseño elaborado para este proyecto. El primer dígito
indica la versión del documento, puede ser incrementado cuando el grupo de
diseño considere que han sido realizado cambios importantes que ameriten una
nueva versión. El segundo dígito señala que han ocurrido cambios en la versión
de un documento, es por ello que éste número comienza en cero para una nueva
versión y se incrementa en una unidad cada vez que se publique o entregue un
nuevo documento con cambios. Ejemplos: 1.0, 1.3, etc.
• Autores: lista de las personas que participan en la elaboración del documento de
diseño o el nombre del grupo de diseño.
• Fecha: índica la fecha en la que se publica está versión del documento
entregada formalmente.
3.2 Tabla de Contenido
La tabla de contenido del DDS, detalla las diferentes secciones y apartados del
documento e indica la página en que cada una de ellas comienza.
3.3 Introducción
Esta sección del DDS proporciona al lector una apreciación global de lo que se tratará
en este documento. Describe el propósito y alcance de este documento y a quien va
dirigido. (1-2 párrafos)
Presenta además, en los siguientes apartados, una visión general del sistema o
subsistema a desarrollar, las decisiones y restricciones de diseño. Una lista con las
principales definiciones de los términos, acrónimos y abreviaturas, una lista de los
documentos que sirven de referencia y por último, un resumen de la estructura o
organización de este documento de diseño.
3.3.1 Propósito del sistema
Esta sección proporciona el punto de entrada para entender el sistema y el ambiente
en el cual este sistema operará. Presenta una visión global y resumida del sistema,
tomando como base lo escrito en el Documento de Especificación de Requisitos del
sistema (DER) y específicamente donde se describe la aplicación.
Consiste en realizar una breve descripción del sistema, su ámbito o contexto, sus
características más relevantes, los procesos o funciones principales, así como sus
entradas y salidas más importantes, sin incluir detalles de implementación. En forma
opcional, podría incluirse un diagrama de contexto o general del sistema que muestre
los componentes principales del sistema y los sistemas externos que interactúan con
él, además de los flujos de datos que entran y salen del mismo. (1-5 párrafos)
Un ejemplo de la redacción de esta sección se muestra a continuación.
“El subsistema de Reservas es uno de los sistemas informáticos de la cadena hotelera
KMG, cuyo propósito fundamental es mantener en forma centralizada y unificada todas las
reservas que se realizan en todos sus hoteles afiliados. Este subsistema permitirá que
todos los clientes de la empresa puedan realizar todas sus actividades por Internet y
especialmente sus reservas. Así mismo, los recepcionistas en cada uno de los hoteles
operarán utilizando la misma interfaz de usuario, una vez que un cliente llegue al hotel para
hacer su check-in o decida modificar o cancelar una reservación o se retire del hotel
haciendo su respectivo check-out.
Este subsistema deberá ser capaz de apoyar todos los procesos y actividades para la
reserva de habitaciones, entre ellos:
• El registro de una reserva realizada por un cliente o el recepcionista del hotel.
• La toma de una reserva (check-in) por parte de un cliente y la asignación de una
habitación al nuevo huésped.
• Sugerencia de otros hoteles de la cadena cuando no existan habitaciones
disponibles en el hotel que un cliente desea reservar.
• La modificación o cancelación de una reserva previamente registrada.
• La notificación al cliente para confirmar una reserva cuando se han realizado
cambios en la misma.
• La confirmación de una reserva mediante una notificación al cliente bien sea por e-
mail, fax, celular o beeper.
• La detección de reservas caducadas o reservas no tomadas.
• El cálculo de una comisión por penalización de aquellos clientes que no cancelaron
a tiempo una reserva.
• La notificación al sistema de facturación para que éste realice la apertura de una
cuenta a fin de registrar los consumos realizados por sus huéspedes.
El subsistema tendrá como entrada:
• La información personal de sus clientes
• Los datos de una reserva, la cual será capturada a través de un formulario
El subsistema deberá producir la siguiente información como salida:
• El mensaje de confirmación de una reserva
• La factura o recibo de consumo de un cliente
• La comisión por penalización de una reserva no cancelada
• Información estadística de reservas tomadas, modificadas, canceladas y
caducadas.”
3.3.2 Objetivos y restricciones de diseño
Describe los principales objetivos, limitaciones o restricciones que tienen un gran
impacto en el diseño del sistema. (1-5 párrafos)
Una gran mayoría de estos objetivos y restricciones lo determinan:
 • La infraestructura tecnológica que posea la organización donde será instalado
este sistema, por ejemplo: manejador de base de datos a utilizar, características
mínimas que deben poseer los computadores a ser instalados, características de
la red que comunicará estos computadores y el protocolo usado, etc.
• El software que será utilizado para la construcción del sistema y el ambiente
operativo donde éste será ejecutado.
• La reutilización de componentes de software existentes en la organización.
• Los requisitos de interfaz de usuario que se le impondrán al sistema.
• Los requisitos de desempeño, seguridad, confiabilidad y calidad impuestos al
sistema.
• El uso de estándares y normativas que deben ser tomadas en cuenta para el
desarrollo del sistema, entre otros.
A continuación se muestra un ejemplo de los objetivos y restricciones que se le
imponen a un sistema, en nuestro caso continuaremos con el subsistema de
Reservas.
“La gerencia general de la cadena hotelera KMG desea mantener el control de todas las
reservas que se hacen en los distintos hoteles afiliados a su cadena. La empresa tiene
como política no realizar reservas por encima de su disponibilidad (overbooking). En este
sentido, el sistema o recepcionista debería estar en capacidad de sugerir a los clientes
otros hoteles de la cadena, cuando no exista disponibilidad de habitaciones en el hotel
deseado.
Por otra parte, el sistema deberá permitir que las actividades para el registro, modificación,
eliminación y consulta de una reserva efectuada por un cliente o recepcionista pueda
llevarse a cabo a través de la web. Así mismo, deben proveerse los mecanismos para que
las agencias de viajes puedan operar con el sistema, mediante el uso de Web Services.
Debido a que los procesos de reserva, check-in y check-out presentan altas exigencias de
desempeño, donde las reservas por Internet deben realizarse en menos de 5 segundos,
una vez llenado el formulario por parte del cliente. Así mismo, el tiempo de respuesta para
la realización de una reserva debe ser menor a 3 minutos cuando el cliente la realiza
directamente por teléfono o en la recepción del hotel. De igual manera, el tiempo de
respuesta con las agencias de viajes para realizar una reserva debe ser de al menos 5
segundos.
Además, se desea reutilizar un sistema de facturación existente en la empresa, a fin de
poder utilizar los servicios que ofrece dicho sistema.
El sistema requerido deberá ejecutarse bajo la plataforma Microsoft Windows. Este podría
utilizar como navegador el Internet Explorer o algún navegador de software libre como el
Mozilla Firefox. El sistema utilizará el protocolo estándar de comunicación HTTP a través
del canal de comunicación TCP/IP. Por otra parte, el desarrollo de la interfaz gráfica se
realizará en forma sencilla utilizando un editor HTML con manejo de Forms, empleando el
lenguaje de programación PHP para generar el contenido dinámico de las páginas web y
de la programación de la lógica de la aplicación.”
3.3.3 Definiciones, acrónimos y abreviaturas
En este apartado se deben incluir todos los términos técnicos, acrónimos y
abreviaturas que serán usadas en el documento. Un ejemplo de estos términos
técnicos utilizados podrían ser los casos de uso, arquitectura del sistema, o bien,
 siglas definidas para ciertos productos del diseño como Diagramas de Secuencias
Detallados (DSD), entre otros.
3.3.4 Referencias
Proporciona una lista completa de todos los documentos utilizados o referenciados en
este documento.
3.3.5 Estructura del documento
Presenta una breve descripción de como el documento ha sido organizado.
3.4 Arquitectura del sistema
Describe la arquitectura del sistema tanto en su forma lógica como física.
3.4.1 Arquitectura lógica del sistema
Esta sección presenta la estructura lógica global de la arquitectura del sistema, de
acuerdo a un patrón arquitectónico elegido. La arquitectura del sistema se representa
a través de un gráfico que muestra como la funcionalidad del sistema ha sido dividida
en subsistemas o componentes.
Una breve descripción de la asignación de la funcionalidad de cada subsistema debe
ser incluida, así como el detalle de los servicios proporcionados por cada subsistema.
Se debe incluir también, una descripción del estilo o patrón arquitectónico utilizado
para dar forma a la arquitectura del sistema.
Uno de los patrones arquitectónicos más usados en la actualidad para el desarrollo de
aplicaciones de porte empresarial es el denominado “arquitectura de 3 o más capas”.
Este estilo arquitectural separa lógicamente y en algunos casos físicamente, los
aspectos de presentación de la aplicación (interfaz de usuario), la lógica del negocios
(automatización del flujo trabajo) y la gestión de los datos (bases de datos), tal como
se muestra en la siguiente figura [1].

Capa de
Capa de
Presentación
Presentació
Presentación

Capa Lógica
Capa Ló
Lógica
de Negocio
de Negocio

Capa de
Capa de
Datos
Datos
La capa de presentación es la encargada de manejar la interfaz del usuario,
controlando la captura y presentación de los datos y recibiendo los eventos
accionados por lo usuarios a través de la interfaz. Esta capa se comunica únicamente
con la capa de lógica de negocios.
La capa de lógica de negocios tiene la responsabilidad de manejar la funcionalidad
del sistema, implementando a través de objetos de negocio (programas) las reglas de
negocio que deben cumplirse. Esta capa se comunica con la capa de presentación para
recibir solicitudes y presentar resultados y con la capa de datos, para solicitar al
gestor de base de datos que almacene o recupere datos.
La capa de datos (llamada en algunos casos capa de persistencia) es la responsable
del almacenamiento y recuperación de los datos. Se comunica únicamente con la capa
de lógica de negocios.
Un ejemplo de la descripción y estructura de la arquitectura para un sistema de video
juegos es mostrada a continuación [2]:
“El sistema empleará el estilo arquitectónico de capas y será organizado en tres capas: la
capa de interfaz, la capa de la aplicación y la capa de almacenamiento.
La capa de interfaz contendrá la interfaz gráfica del usuario que le permitirá a los usuarios
interactuar con el sistema. Esta capa será implementada usando el Java Media Framework
y el Java Swing Package, conteniendo el video player y todos sus menús.
La capa de la aplicación contendrá la lógica y reglas para almacenar datos en la capa de la
base de datos y también para recuperar éstos de acuerdo con las necesidades de las
usuario.
Finalmente, la capa de almacenamiento guardará los datos requeridos por el sistema.
 El estilo arquitectónico de tres-capas será usado porque no sólo separa la interfaz del
usuario de los datos almacenados, sino que también, provee una capa de lógica de la
aplicación. La capa de aplicación provee una capa intermedia que permite que los datos
almacenados en la base de datos y los componentes GUI están débilmente acoplados.
Esta separación lógica permite que una capa pueda ser modificada sin alterar el resto de
las capas o introducir pequeños cambios en alguna de ellas. Por ejemplo, la capa de la
aplicación podría ser modificada si hay cualquier cambio en el formato de los archivos de
datos y sus atributos, sin que esto afecte la capa de interfaz. Esta capa intermedia hace
posible que este sistema esconda a sus usuarios, la complejidad inherente del
procesamiento de sus datos y haga posible que éste sistema sea mucho más fácil de
mantener y de reutilizar.”
Para el Subsistema de Reservas de la cadena hotelera KMG, la arquitectura propuesta
para este sistema, es presentada en la siguiente figura [3].

“El patrón de arquitectura elegido para el Subsistema de Reservas es el de niveles de

abstracción o capas. Cada capa sugiere un tipo diferente de módulos o componentes e
indica el rol que cada uno de ellos juega en esa capa.
La capa de Interfaz de Usuario tiene como objetivo el manejo de la lógica del usuario. Esta
capa consiste de un módulo por caso de uso, el cual agrupa la lógica realizada por el caso
de uso y el conjunto de páginas web dinámicas utilizadas por dicha lógica. Los módulos
identificados y sus interdependencias se presentan en el siguiente diagrama:
La capa de Servicios del Sistema contiene los servicios básicos que debe proveer el
sistema; estos servicios son directamente utilizados por los módulos de la capa superior.
En esta capa se definen las clases controladoras encargadas de manejar la lógica de los
casos de uso, creándose para ello, una clase interfaz por caso de uso. Se crea un módulo
por subsistema, donde cada módulo llevará a cabo todas las interfaces requeridas por los
casos de uso vinculados a ese subsistema. La siguiente figura muestra los servicios
básicos de esta capa.

La capa de Servicios de Negocio agrupa los módulos que representan los servicios para el
manejo de información del negocio. Estos servicios son aún más básicos que el de la capa
superior y pueden ser compartidos por otros subsistemas. Cada módulo de esta capa
ofrece una única interfaz con los servicios que permiten que las operaciones de la capa
superior puedan ser realizadas. El siguiente diagrama muestra los módulos de esta capa.
 La capa de Infraestructura contiene todos los módulos necesarios para utilizar los servicios
de la plataforma. En esta capa residen principalmente adaptadores de los servicios
brindados por la plataforma, entre ellos el módulo de acceso a datos y la comunicación a
otros sistemas, como el de facturación y mensajería. Los servicios de esta capa son
mostrados a continuación."

3.4.2 Arquitectura física del sistema

Esta sección describe la topología del sistema, mostrando como serán asignados en
forma física los diferentes subsistemas o componentes (software) a los diferentes
equipos de computación (hardware). Para describir la asignación del software al
hardware utilice los diagramas de despliegue y de componentes de UML.
Un ejemplo de la arquitectura física del sistema de Video Juegos es mostrado a
continuación [2]:
 Continuando con el ejemplo del subsistema de Reservas, la arquitectura física es
representada con el siguiente diagrama [3].

“Esta arquitectura física considera la distribución de la aplicación en cuatro tipos de nodos:

Cliente, Recepción, Server, LegacyServer.
El primer nodo representa a las estaciones de trabajo de los usuarios finales. El nodo
Recepción corresponde a la estación de trabajo ubicada en la recepción del hotel.
El nodo Server representa al equipo en donde correrá el servidor web y la aplicación del
Subsistema de Reservas.
El último nodo, LegacyServer, representa a aquella infraestructura informática necesaria
para correr los sistemas legados, entre ellos el sistema de facturación.”

Se puede incluir adicionalmente bajo esta arquitectura, un diagrama de despliegue en UML,

que muestre como los componentes de software (servicios, procesos, etc.) son distribuidos
sobre el hardware, tal como se indica en la siguiente figura [1].
3.5 Diseño de los subsistemas
Esta sección describe cada uno de los subsistemas que han sido determinados en la
arquitectura lógica del sistema. Para ello, se incluye una descripción de la
funcionalidad del subsistema a través de una vista de casos de uso. Una descripción
del modelo de datos que soporta, mostrados mediante una vista de datos y la
inclusión de una serie de elementos de modelado que describen como los casos de
uso del sistema pueden ser realizados.
3.5.1 Diseño del Subsistema <nombre del subsistema >
3.5.1.1 Vista de Uso del subsistema <nombre del subsistema>
Esta vista muestra la funcionalidad del sistema como es percibida por los usuarios
finales, analista y encargados de las pruebas.
Para esta vista se utilizan los diagramas de casos de uso de UML, los cuales
contienen los casos de uso más representativos de este subsistema. Cuando los casos
de uso contenidos en estos diagramas son numerosos, estos podrían ser agrupados de
forma funcional utilizando los paquetes (carpetas) de UML. Esta organización crea
una jerarquía de diagramas de casos de uso, los cuales por razones de claridad, no
deberían pasar de tres niveles.
Un ejemplo de la vista de casos de uso para el subsistema de Reservas es mostrado en
la siguiente figura [3]:
Otro ejemplo de la Vista de casos de uso para un sistema de Video Club, podría ser:

Gestión de Socios Gestión de Películas Gestión de Alquileres

- - -

3.5.1.2 Vista de Datos del subsistema <nombre del subsistema>

Esta vista muestra el subconjunto de clases de entidad que serán utilizadas por este
subsistema. Las clases de entidad se refieren a aquellas clases que van a guardar datos
en forma persistente a través de un manejador de base de datos. En otras palabras,
representa la porción del modelo conceptual de datos que será utilizada por este
subsistema.
Para la construcción de esta vista se utilizan los diagramas de clases de UML. En
estos diagramas se muestran conceptos (objetos), asociaciones entre conceptos
(relaciones) y atributos de conceptos (atributos).
Un ejemplo de la vista de datos relacionada con el sistema de Reservas sería [3]:
Subsistema de Reservas
3.5.1.3 Realizaciones de Casos de Uso <nombre del subsistema>
En esta sección se detalla como cada uno de los casos de uso que pertenecen a este
subsistema van a ser realizados. La realización de un caso de uso permite expresar
como el comportamiento definido en un escenario, es distribuido en función de los
objetos o clases que colaboran entre si para realizar una operación.
3.5.1.3.1 Realización del caso de uso: <nombre del caso de uso>
Para describir la realización de un caso de uso será necesario: una descripción textual
de los pasos realizados en ese caso de uso (escenario), un diagrama de las clases que
participan en ese caso de uso y un diagrama de secuencia o de colaboración que
muestra como la clases interactúan. De manera opcional, se puede mostrar los
componentes de la interfaz gráfica de usuario (pantallas, vistas o formularios)
involucrados en la realización del caso de uso y un diagrama de navegación a través
de la interfaz de usuario.
‰ Escenario del caso de uso: <nombre del caso de uso>
En este apartado se presenta el escenario del caso de uso, que mediante una
descripción textual muestra el flujo de eventos que ocurre entre uno o más actores y
el sistema, incorporando detalles de la interfaz, sus atributos y nombres de las clases
utilizadas en la realización del caso de uso.

El escenario del caso de uso hacer reserva es mostrado a continuación [3]:

Otro ejemplo de un escenario de caso de uso para un sistema de Punto de Venta se
presenta en la siguiente figura.

Caso de Uso Procesar Venta CU-01

Este caso de uso de uso permite que un Cajero capture la venta de una
Descripción
serie de productos y registre su pago en efectivo
Actores Cliente (Iniciador), Cajero
Tipo Primario
Requisitos
RF 1.1, RF 2.3
Asociados
Precondición El Cajero se identifica y autentica
Curso Normal (Básico)
Paso Acción
Este caso de uso comienza cuando un Cliente llega a la caja del Terminal de punto
1
de venta (TPDV) con productos para comprar.
2 El Cajero inicia una nueva venta.
El cajero registra el identificador de cada producto. Si hay varios productos de un
3
mismo tipo, el Cajero puede introducir su cantidad.
El sistema registra la línea de venta y presenta la descripción del producto, precio y suma
4 parcial.
El Cajero repite los pasos 3 y 4 hasta que termine de introducir los productos y le
5
indica al TPDV que se concluyo la venta.
6 El Sistema calcula y presenta el monto total de la venta con sus impuestos.
7 El Cajero le dice al Cliente el total de la venta.
El Cliente efectúa un pago en efectivo, posiblemente con un monto mayor que el
8
total de la venta.
9 El Cajero registra la cantidad de efectivo recibida y el Sistema gestiona el pago.
10 El Sistema registra la venta completa, genera el recibo y actualiza el inventario.
11 El Cajero entrega el recibo de compra y devuelve dinero al Cliente
12 El Cliente se marcha con los artículos comprados.
Se registra la venta, su importe y su respectivo impuesto. Se actualiza la
Postcondición
contabilidad y el inventario
Cursos Alternos o Excepcionales
Paso Acción
3a Introducción de un artículo inválido:
1. El sistema señala el error y rechaza la entrada.
El cliente le pide al Cajero que elimine un artículo de la compra:
3-7a 1. El Cajero introduce el identificador del artículo para eliminarlo.
2. El Sistema resta el artículo de la compra y muestra la suma parcial.
El cliente le pide al Cajero que cancele la venta:
8a 1. El Cajero cancela la venta.
2. El Sistema elimina los datos de la venta actual.

‰ Diagrama de clases de diseño del caso de uso: <nombre del caso de uso>
Un diagrama de clases en UML es presentado aquí, para mostrar las clases de diseño
de software que colaboran en la realización del caso de uso. Este diagrama muestra la
especificación de las clases software que intervienen en este caso de uso, presentando
sus atributos, métodos, asociaciones, interfaces y operaciones, navegabilidad y
dependencias.
Los tipos de clases de diseño que son incluidas en estos diagramas son las clases de
entidad, de interfaz y de control, denominadas así en el Proceso Unificado (RUP).
Las clases de identidad representan a aquellos elementos del mundo real o conceptual
a los que se les guardará información perdurable en el sistema. Las clases de interfaz
modelan la interacción entre el sistema y sus diferentes usuarios, asociadas con la
entrada de datos y salida de información. Las clases de control o activas, son
utilizadas para controlar el flujo de operaciones que debe realizar el sistema en
respuesta a los eventos generados por un actor.
En algunos casos, se construye básicamente un Modelo de Diseño de Objetos que
corresponde a la capa del dominio o lógica de la aplicación, el cual contiene las
clases software que manejaran la lógica del negocio y cuyos nombres son derivados
de los conceptos del negocio. El siguiente ejemplo ilustra un diagrama de clases de
diseño para un sistema de Punto de Venta.

‰ Diagrama de secuencia del caso de uso: <nombre del caso de uso>

Un diagrama de secuencia de UML es colocado aquí para complementar la
descripción textual (escenario) de un caso de uso. Pudiera ser un elemento opcional
cuando la realización del caso de uso sea sencilla e involucre pocas clases o pocos
métodos.
Un diagrama de secuencia se usa principalmente para mostrar en que orden
interactúan los objetos o clases en la realización de un caso de uso, así como la
secuencia de mensajes intercambiados por estos, para llevar a cabo la funcionalidad
descrita por el escenario.
La siguiente figura muestra el diagrama de secuencia para el caso de uso procesar
venta. Este diagrama usa estereotipos para indicar los tipos de objetos que
interactúan, por ejemplo: los de interfaz con el estereotipo <<UI>>, los de control
con el estereotipo <<controlador>> y el resto de ellos, sin estereotipo, que hacen
referencia a los objetos de entidad.
Un ejemplo que hace uso de clases genéricas de software, creadas para el manejo de
la interfaz, de la lógica de la aplicación y del acceso a datos es mostrado en el
siguiente diagrama de secuencia del caso de uso registrar usuario de un sistema de
Reservaciones Aéreas [4].
 Caso de uso: Crear Registro Usuario

‰ Interfaz gráfica de usuario del caso de uso: <nombre del caso de uso>
En este apartado se mostrarán los diferentes componentes de la interfaz gráfica del
usuario (pantallas, ventanas, formularios o vistas) involucrados en la realización de
este caso de uso.
Adicionalmente se podría incluir aquí, los formatos de impresión asociados a este
caso de uso o en general al subsistema asociado.
Para el caso del subsistema de Reservas, los componentes de la interfaz que permite
ingresar los datos de una reserva son mostrados en las siguientes figuras.
‰ Diagrama de navegación del caso de uso: <nombre del caso de uso>
Esta sección es opcional y podría ser utilizada sólo cuando la realización del caso de
uso tenga cierta navegación compleja que sea necesario describirla. En este caso, se
utilizaría un diagrama de estados de UML para mostrar dicha navegabilidad.
La siguiente figura presenta un posible diagrama de navegación para el caso de uso
hacer reserva, donde se muestran los diferentes componentes de la interfaz de
usuario presentes en la realización de este caso de uso.
3.6 Diseño de la Base de Datos
Esta sección del DDS, contiene los diseños de la base de datos que determinan como
los datos que van a ser incluidos en la base de datos, están lógica y físicamente
organizados. Para ello, el diseño de la base de datos se establece en dos niveles de
detalle.
El primer nivel muestra el modelo conceptual de la base de datos, representado a
través de uno o más diagramas de clases en UML o diagramas entidad-asociación, el
cual es independiente del entorno tecnológico utilizado. El segundo nivel presenta el
modelo implementable de la base de datos, descrito mediante un diagrama físico de la
base datos que depende directamente del manejador de base de datos utilizado.
3.6.1 Esquema Conceptual de la Base de Datos
Este apartado presenta el esquema conceptual de datos del sistema. Este esquema es
el producto de la integración de los diferentes diagramas (de clases en UML o de
entidad-asociación) de cada proceso de negocio o subsistema que haya sido
establecido. Los datos contenidos en este esquema son derivados directamente de los
requisitos funcionales del sistema.
En el caso de utilizar la herramienta de diseño PowerDesigner, los diagramas
generados como Modelo Orientado a Objeto (Object-Oriented Model) o Modelo
Conceptual de Datos (Conceptual Data Model) son incluidos en esta sección.
Un diagrama de clases en UML es mostrado aquí, para representar el modelo
conceptual de datos del subsistema de Reservas.

0..* 1 Hotel
Recepción Habitación
-nombre : String
-IPAddress : String -nombre : String
-ciudad : String
1 1..*

1 0..1 *

*
Cliente
-idCliente : Integer Reserva
-nombre : String 1
-idReserva : Integer
-usuario : String
-checkin *
-password : String TipoHabitación
-checkout
-email : String 1 * -estado -nombre : String
-tel : String
-fax : String * 1

0..*
Clase enumerada
EstadoReserva
Huésped -Pendiente
-nombre : String -En Curso
-documento : String -Finaliza
-pais : String -Cancelada
-NoTomada

3.6.2 Esquema Implementable de la Base de Datos

Esta sección presenta el resultado de la conversión del esquema conceptual de la base
de datos a un esquema implementable (en nuestro caso, el modelo relacional), donde
se incluyen detalles de implementación física de acuerdo al manejador de base de
datos a usar.
Si se utiliza la herramienta de diseño PowerDesigner, éste genera un diagrama
denominado Modelo Físico de Datos (Physical Data Model) que describe
gráficamente la estructura de la base de datos y sus características físicas.
El esquema implementable de la base de datos del sistema de Reservas, el cual utiliza
el modelo relacional y que será ejecutado sobre el gestor de base de datos Microsoft
Access es mostrado en la siguiente figura [3].
 3.6.3 Diccionario de Datos
Este apartado es opcional. Si el contenido del diccionario de datos es muy grande se
recomienda, sacarlo de este documento y crear un documento aparte con este
contenido, el cual podría denominarse Modelo de Datos del Sistema o Diccionario de
Datos del Sistema.
Esta sección presenta un listado organizado de todas las estructuras de
almacenamiento de la base de datos. Describiendo cada una de las tablas que la
componen y sus campos asociados. Adicionalmente, cada campo es identificado por
un nombre de dato, descripción, tipo de dato, longitud y el posible dominio de valores
que podría tomar.
3.7 Anexos
Esta sección incluirá toda la información adicional o de soporte al diseño del sistema.
Los anexos podrían incluir:
• Tabla de definición de usuarios (actores)
• Tabla de opciones del sistema (indicando el caso de uso asociado)
• Matriz usuario-opciones del sistema
• Tabla de descripción de reglas de negocio del sistema
• Tabla de casos de uso-reglas de negocio
4 Fichas Técnicas de Productos de Diseño

En esta sección se describen algunas de las fichas técnicas de productos usadas en el diseño
de sistemas. Estas fichas describen las notaciones empleadas para construir los diversos de
diagramas de UML presentes en este documento DDS.
Tienen el propósito de servir como una referencia rápida al lector de este documento para
entender la simbología utilizada en cada uno de estos diagramas. A continuación, se anexan
las fichas definidas por cada producto de diseño.

4.1 Ficha Técnica para los Diagramas de Casos de Uso

Universidad de Los Andes

Vicerrectorado Administrativo
DSIA – Área de Ingeniería de Requisitos y Diseño de Software

FICHA TÉCNICA DEL PRODUCTO: DIAGRAMA DE CASOS DE USO

Fase en la que se usa: Ingeniería de Requisitos Nombre del producto: Diagrama de

y Diseño de Software Caso de uso

Fecha:28 /11 /2007 Metodología: UML Herramientas para construirlo:

PowerDesigner 12, Powerdesigner12.5
Visual Architect 2.0, Visio
Versión: 1.0 Versión: 2.0
Definición del producto: Diagrama que permite especificar los requisitos funcionales de
un sistema
Utilidad para el cliente del proceso de diseño: Permite estructurar el sistema en
funciones y definir los actores o roles que tendrán acceso a dichas funciones.
Nivel de detalle requerido para Diseño: a nivel de funciones que realizan alguna
transacción que involucra un conjunto de datos.
Símbolos utilizados y su significado
Nombre del símbolo Significado Símbolo
Es quien interactúa con el
sistema. Puede acceder a
Actor o Rol una o más funciones. En
algunos casos, el actor es
un sistema.

Paquete de casos de uso Es un conjunto de casos de 2. Registrar ingreso a Tesorería

uso agrupados según un 1 1 . Ca r g a r CP - O P d e SAF

cierto criterio, el cual puede 1 2 . Ca r g a r O P f n

i a n c e
i r a s d e l Dp t o N ó m

ser: grupos de funciones, Re c e p c o

i n si t a
1 3 . A c t u a zil a r r e c a u d o s p o r t ip o d e p

por usuarios, o por fases del

<<e x t e n d >> 1 5 . Bu s c a r CP - O

1 4 . Va d
il a r r e c a u d o s

<< e x t e n d > >

1 6 . Bu s c a r O P f n
i a n c e
i

proceso organizacional a
<<e x t e n d >>

1 7 . I n g r e s a r O P f n
i a n c e
i r a s d e a
l s

quien los casos de uso dan

soporte.
Caso de uso Función que el sistema pone
a la disposición de los
actores. Produce un
resultado de valor para los
actores
Continuación ficha técnica: Diagramas de Casos de Uso

Relación de comunicación Usado para establecer una

Relación include
asociación bidireccional
entre un actor y un caso de
uso
Usado para establecer la
relación entre 2 casos de <<include>>
uso, en el cual un caso de caso de uso 1 Caso de Uso 2

uso contiene o incluye al

otro
Relación extend Usado para establecer la
relación entre 2 casos de <<extend>>
uso en la cual uno extiende caso de uso 1 Caso de Uso 2

el comportamiento del otro.

Relación de generalización
El caso de uso 2 se realiza
si dentro del caso de uso 1
se da cierta condición.
Usado para establecer la Utilizada entre actores:
relación “es un” entre
actores o casos de uso,
generales y específicos
usuario autorizado

usuario 1 usuario 2

Utilizada en casos de uso

Imprimir

Imprimir Reporte de Saldos Imprimir Reporte de disponibilidad

Insumos: Requisitos Funcionales del Sistema, Diagramas de Procesos, Diagramas de

actividades.
Elementos asociados a un caso de uso: Requisitos que resuelve. Reglas del negocio que
aplican para cada caso de uso. Relaciones entre casos de uso: extend, include y actores
que participan en cada caso de uso.
Alias utilizados para este producto: Bibliografía consultada:

Vistas de uso Modelado de sistemas usando UML 2.0

Continuación ficha técnica: Diagramas de Casos de Uso

Ejemplo de este producto:

11.Cargar CP-OP de SAFEP

12.Cargar OP financieras del Dpto Nómina

13.Actualizar recaudos por tipo de pago

Recepcionista

<<extend>> 15.Buscar CP-OP

14.Validar recaudos

<<extend>>

16.Buscar OP financiera

<<extend>>

17.Ingresar OP financieras de las UAD

Consideraciones especiales: la numeración de los casos de uso de todo el

subsistema o sistema es estrictamente secuencial, utilizando números ordinales,
seguidos de un punto y el nombre del caso de uso. Los números deben tener 3
dígitos. Los paquetes de casos de uso también deben tener números. Si hay más
de un nivel en los paquetes de casos de uso, se puede usar jerarquía: 1.1, 1.2, etc.
Paleta de colores: B/N para todos los elementos del diagrama. Gris para casos de
uso que son definidos en un diagrama o paquete y se utilizan en otro
Estandarizado por: Grupo de Ingeniería de Requisitos y Diseño de Software
4.2 Ficha Técnica para la Organización de Casos de Uso

Universidad de Los Andes

Vicerrectorado Administrativo
DSIA – Área de Ingeniería de Requisitos y Diseño de Software

FICHA TÉCNICA DEL PRODUCTO: ORGANIZACIÓN DE CASOS DE USO

Fase en la que se usa: Ingeniería de Requisitos Nombre del producto: Diagrama de

y Diseño Detallado Paquetes de Casos de Uso

Fecha14/1 /2008 Metodología: UML Herramientas para construirlo:

PowerDesigner 12, Powerdesigner12.5
Visio
Versión: 1.0 Versión: 2.0
Definición del producto: Los paquetes ofrecen un mecanismo general para la
organización de los modelos/subsistemas agrupando elementos de modelado.
Puede ser usado para agrupar funcionalmente los casos de usos de un sistema.

Utilidad para el cliente del proceso de diseño: Permite estructurar el sistema en

subsistemas o módulos.
Nivel de detalle requerido para Diseño:

Símbolos utilizados y su significado

Nombre del símbolo Significado Símbolo
Es quien interactúa con el
sistema. Puede acceder a
Actor o Rol uno o más paquetes. En
algunos casos, el actor es
un sistema.

Paquete Es un conjunto de paquetes

o de casos de uso
agrupados según un cierto
criterio, el cual puede ser:
1. Cargar información

Relación de comunicación Usado para establecer una

Estereotipo
Relación de dependencia
asociación bidireccional
entre un actor y un paquete.
Se muestran a partir del
segundo nivel.
Usado para identificar el tipo << subsistema >>
de paquete, si se trata de
Usada para denotar cuando
un caso de uso de un
paquete se relaciona con un
caso de uso de otro 4. Solicitar pagos

paquete. Se muestran a
partir del segundo nivel.

6. Controlar pagos
Continuación ficha técnica: Organización de Casos de Uso

Insumos: Cadena de Valor de procesos, Diagramas de procesos, Diagrama de Jerarquía

de procesos, Diagramas de actividades. Inventario de Procesos, Árbol de Procesos.
Alias utilizados para este producto: Bibliografía consultada:
Modelado de sistemas usando UML 2.0.

El Lenguaje Unificado de Modelado.

Diagrama de Referencia, Rumbaugh,
Jacobson y Booch.

Arquitectura de Software, Adrián Lasso.

Ejemplo de este producto:

A nivel de sistema:

Sistema de Emisión y Control de Pagos

<<sistema>>

<<subsistema>>
<<subsistema>>
Subsistema 1
Subsistema 2

<<subsistema>>
Subsistema 3
Continuación ficha técnica: Organización de Casos de Uso

Formulacion Presupuesto

<<Subsistema>> <<Subsistema>> <<Subsistema>>

GestionarLineamientos Formular Anteproyecto Formular Proyecto

<<Subsistema>>
<<Subsistema>>
GestionarModificacionesPpto RealizarEstadisticas

<<Subsistema>> <<Subsistema>>
GestionarIngresoSistema Administración del Sistema

Si hay más de 2 niveles dentro de los subsistemas, se pudiera presentar en

forma de árbol:
Subsistemas Módulos Casos de Uso
Continuación ficha técnica: Organización de Casos de Uso

A nivel de un subsistema:
Object-Oriented Model
Model: Modelo de Casos de uso
Package:
Diagram: SUBSISTEMA GESTIÓN DE PAGOS
Author: Nancy B. de García Date: 14/01/2008
Version: 2

Recepcionista
<<módulo>>
1. Cargar información

<<módulo>>
2. Registrar ingreso a Tesorería

Controlador Financiero

Gestor de Pagos : 1

<<módulo>> Supervisor de Tesorería : 1

3. Tramitar pagos

<<Gestión Cuentas Bancarias>>

1.2.1 Autorización de Transferencia de Fondos

<<módulo>>
4. Solicitar pagos

Revisor de documentación

<<Gestión Cuentas Bancarias>>

1.3 Manejar movimientos

<<módulo>>
<<módulo>>
5. Generar pagos
6. Controlar pagos
<<Gestión Cuentas Bancarias>>
1.2.2.2 Cheques <<Gestión Cuentas Bancarias>>
1.5 Manejar Cuentas en Divisa

Supervisor de Tesorería : 2

Revisor de instrumentos de pago <<módulo>>

7.Consultar pagos

Gestor de Pagos : 2

Consideraciones especiales:
Cuando haya más de 2 niveles se dibuja en forma de árbol; a nivel de un módulo,
se deben mostrar las relaciones de dependencia y los actores.
Máxima cantidad de niveles: 3
Criterios de buen empaquetamiento: alta cohesión y bajo acoplamiento entre
paquetes.

Paleta de colores: B/N para todos los elementos del diagrama. Gris para casos de
uso que son definidos en un diagrama o paquete y se utilizan en otro
Estandarizado por: Grupo de Ingeniería de Requisitos y Diseño de Software
4.3 Ficha Técnica para los Escenarios de Casos de Uso

Universidad de Los Andes

Vicerrectorado Administrativo
DSIA – Área de Ingeniería de Requisitos y Diseño de Software

FICHA TÉCNICA DEL PRODUCTO: ESCENARIOS DE CASOS DE USO

Fase en la que se usa: Nombre del producto: Escenario de

caso de uso (realización del caso de
uso detallado)
Fecha: 28/11/2007 Metodología: UML Herramientas para construirlo:
PowerDesigner 12, PowerDesigner
Versión 1.0 Versión: 2.0 12.5
Word, OpenOffice
Símbolos utilizados y su significado
Nombre de la Significado Notación
sección
Conjunto de pasos escrito en lenguaje Numeración de los pasos: números
Flujo de eventos natural que muestra el flujo de eventos ordinales: 1., 2., ..n.
normal o principal, a través de una secuencia de Frases empleadas:
especificación del acciones que ocurren entre los actores y el “El usuario < acción >”
caso de uso sistema. Ejemplo: “El usuario selecciona Guardar.
“El sistema <acción>”
Ejemplo: “El sistema guarda el número,
fecha de la orden en la Base de Datos”.
Flujo de eventos Flujo alternativo: Numeración de pasos de un flujo
excepcionales o Conjunto de pasos que describen el flujo de alternativo:
alternativos. acciones al ocurrir una cierta condición. Se Números ordinales seguidos de una
Flujo alternativo o utiliza para mostrar las diferentes opciones letra. Cuando haya más de una acción
puntos de extensión. posibles de un conjunto donde todas tienen dentro de un flujo excepcional, se
Puntos de excepción. la misma posibilidad de ser seleccionadas incorporan números.
por el usuario. Ejemplo: flujo normal:
2.- El sistema muestra la información
Flujo excepcional: de la orden en pantalla.
Conjunto de pasos que describen las Flujo excepcional:
acciones que se deben realizar en caso de 2.a.- Si la orden no existe, el sistema
ocurrir alguna condición excepcional, muestra un mensaje de advertencia.
diferente al flujo normal de eventos. Por lo
general, se utiliza para manejar condiciones Numeración de pasos de un flujo
de validación, manejo de errores, etc. alternativo:
Ejemplo: flujo normal:
3.- El usuario selecciona una opción.
Flujo alternativo:
3a.1.- Si el usuario selecciona
“Guardar”:
3a.2.- El sistema guarda los datos
suministrados en la Base de Datos.
3b.1.- Si el usuario selecciona
“Imprimir”:
3b.2.- El sistema activa el caso de uso
“Imprimir orden”.

Precondiciones o Describen la condición previa al Ejemplo:

condiciones de conjunto de acciones del flujo feliz, “El usuario Ingresó al sistema de
entrada o lo que debe ocurrir antes que se Ordenes de Pago”
ejecute este flujo
Continuación ficha técnica: Escenarios de Casos de Uso

Postcondiciones Describe el estado final obtenido * El usuario registró los datos de la

o condiciones de después de ejecutarse el flujo solicitud de autorización para la
salida normal de eventos. apertura de una cuenta bancaria.
* El sistema almacenó los datos de
la solicitud y actualizó el estado de
la misma.

Alias utilizados para este producto: Bibliografía consultada:

Modelado de Sistemas usando UML 2.0

Ejemplos de este producto:

Use Case: 4. Cargar información de Contratistas

1. Card of use case

Name 4. Cargar información de Contratistas

Code 4_Cargar_informacion_de_Contratistas
Parent Package '1. Cargar información'

2. Action steps of use case

1. El sistema muestra mensaje de confirmación para iniciar la carga de información de los
Contratistas
2. El usuario confirma que desea iniciar el proceso de carga.
3. El sistema busca los datos digitalizados de los Contratistas: Nombre, RIF, Dirección,
Localidad, Tlf, Actividad, Representante Legal, C.I. del Representante.
4. El sistema valida Nombre y RIF.
5. Para cada registro el sistema asigna un número de contratista y guarda la información.
6. El sistema muestra mensaje de ingreso realizado y finaliza el caso de uso.

3. Exceptions of use case

5a. Si ya existe el Nombre o RIF el sistema muestra mensaje “XXXX ya existe” (donde
XXXX puede ser Nombre o RIF ) y regresa al paso 1, colocando el cursor en el campo
erróneo.

4. Extension of use case

2a. El usuario selecciona no realizar el procso de carga, el sistema finaliza el caso de uso.

5. Pre-condition of use case

Debe haberse recibido la información digitalizada de los Contratistas.

6. Post-condition of use case

Se guardaron los datos de los Contratistas en la BD del sistema.

7. List of all dependencies of the use case

Name Code Class Name

Association_4 Association_4 Use Case Association
Continuación ficha técnica: Escenarios de Casos de Uso

Consideraciones especiales:
1) Los escenarios de Casos de Uso para Ingeniería de Requisitos, no deben
involucrar aspectos de interfaz gráfica como por ejemplo: pulsar botones.
Tampoco deben involucrar nombres de clases ni de atributos de clases. Sin
embargo, los mismos deben considerar todos los datos que se registran, con
el detalle que se requiere en virtud que estos escenarios serán el insumo
para el diseñador.
2) Cuando el escenario ofrezca varias opciones, las cuales tienen la misma
posibilidad de ser elegidas y el caso de uso tenga una relación de extend
con otros casos de uso, se redacta así:
Ejemplo: caso de uso con relación extend a través de las opciones <opción a>
<opción b> y <opción c>
Flujo feliz:
1. El usuario selecciona una opción.
Flujo alternativo:
1.a. Si el usuario selecciona <opcion a> se realiza el caso de uso Caso de
uso A.
1.b. Si el usuario selecciona <opcion b> se realiza el caso de uso Caso de
uso B.
1.c. Si el usuario selecciona <opcion c> se realiza el caso de uso Caso de
uso C.
3) Cuando el escenario ofrezca varias opciones, de las cuales una de ellas es
la que más se utiliza y existen otras opciones, bien sea que se van a resolver
dentro del mismo caso de uso o a través de un extend, se redacta en forma
parecida a 2), sólo que la opción más frecuente y su flujo se consideran
dentro del flujo feliz, mientras que las opciones se consideran dentro de los
flujos alternativos.
Paleta de colores: Blanco y Negro
Estandarizado por: Grupo de Ingeniería de Requisitos y Diseño de Software
4.4 Ficha Técnica para los Diagramas de Secuencia

Universidad de Los Andes

Vicerrectorado Administrativo
DSIA – Área de Ingeniería de Requisitos y Diseño de Software

FICHA TÉCNICA DEL PRODUCTO: Diagrama de Secuencia

Diseño Arquitectónico Diseño Detallado Nombre del producto: Diagrama de

secuencia detallado
Fecha:1 / 10 / 2007 Metodología: UML Herramientas para construirlo:
PowerDesigner 12
Visual Architect 2.0
Versión: 1.0 Versión: 2.0
Definición del producto: Diagrama que describe la dinámica de una aplicación o una parte de
ella, mostrando las interacciones entre los objetos desde el punto de vista temporal, insistiendo
en la cronología del envío de mensajes.
Utilidad para el cliente del proceso de diseño: Permite conocer en detalle para cada evento
del sistema o hilo de operación, cuáles métodos se requieren de las instancias de las clases
involucradas en la realización del caso de uso, así como el ordenamiento de los mensajes entre
los objetos. Facilita la programación orientada a objetos.
Nivel de detalle requerido para Programación: Se puede obtener uno o más diagramas de
secuencia detallados para un caso de uso, tomando en cuenta que por cada uno de éstos
existen varios eventos del sistema o hilos de operación. El nivel de detalle debe incluir: métodos
utilizados por clase, atributos o parámetros que se pasan a través de los mensajes, valores de
retorno, condiciones sobre los mensajes e iteraciones, tipos de mensajes (síncronos, asíncronos,
de retorno). También se necesita identificar la clase controladora que resolverá el evento del
sistema, y debe estar previamente definida con todas sus operaciones, y debidamente
documentada.
Símbolos utilizados y su significado
Nombre del símbolo Significado Símbolo
Actor
Representa al actor que inicia los
eventos del sistema ó recibe
mensajes del sistema a través de la
clase controladora.

Línea de vida asociada a un objeto.

Línea de vida Representa la duración de la vida :clase 2
del objeto dentro del diagrama de
secuencia.

Ejecución ó caja de Indica la duración. Es un elemento

activación opcional que se puede utilizar para
apilar operaciones que se activan :clase 2
durante una temporalidad dada en
el objeto que emite los mensajes.
Continuación ficha técnica: Diagramas de Secuencia
Uso de la interacción
Alternativas de interacción
Mensajes entre objetos
Elementos de un mensaje
Indica una referencia que se hace
de una interacción, la cual puede ref
definirse como un pedazo del SequenceDiagram_121()
diagrama de secuencia que es
utilizado en otra parte, así como la
referencia a otro diagrama de
secuencia.
Se utilizan para demarcar dentro del alt [Condition]
diagrama de secuencia, la sección
de acciones dada una u otra
condición. Las condiciones se [Condition]
separan por líneas punteadas.
Establecen el tipo de comunicación
entre objetos del diagrama; existen
varios tipos:
a) Indefinido: puede ser un
flujo síncrono o asíncrono
b) Síncrono: el objeto que
envía un mensaje espera
una respuesta.
c) Asíncrono: el objeto que :clase 1
manda el mensaje no
espera la respuesta del Actor
otro objeto, sino que mensaje "this"
continúa su ejecución.
d) Retorno: muestra el Mensaje indefinido
retorno a partir de una Mensaje síncrono
llamada de un objeto; Mensaje asíncrono
pueden mostrarse los
valores que retorna. Mensaje de retorno
Creación del objeto
Algunos diseñadores :clase 2
excluyen este tipo de
mensajes.
e) Creación de objeto: indica Destrucción del objeto
el inicio de vida del objeto
a quien se envía el
mensaje.
f) Destrucción de objeto:
indica la destrucción
explícita del objeto o la
finalización de su línea de
vida.
g) Mensaje “this”: es un
mensaje que envía un
objeto a sí mismo.
Nota: para los mensajes indefinidos,
asíncronos o tipo “this” se puede
incluir la caja de duración.
Método: el método indica la acción
objetoa:clase 1 objeto b:clase 2
que realizará la clase que recibe
dadas las condiciones y parámetros
de la clase que envía. En el m
ejemplo, “Calcular” es un método n:= 1 [Si x > 2]: z:= Calcular(x,y)
del objeto b.
Argumentos o parámetros: si el
método requiere de argumentos
para su ejecución, éstos se hacen
explícitos.
Valor de retorno o variable de
retorno: es el valor que retorna el
método invocado.
Continuación ficha técnica: Diagramas de Secuencia

Elementos de un mensaje Condición: Indica entre corchetes la

condición bajo la cual se ejecuta el
método invocado.
objetoa:clase 1 objeto b:clase 2 objeto c:clase 3

Iteración: Indica desde qué valor

hasta qué valor se va a repetir la
ejecución del método invocado. [Si x > 2]: z:= Calcular(x,y)

Para el caso que la iteración no se IngresaDatos(x, y, z)

haga para un mensaje sino para

una pieza del diagrama, se encierra *[n:= 1..m]

en un recuadro las acciones y se

coloca la iteración entre corchetes.
Alias utilizados para este producto: Bibliografía consultada:

Vistas de uso Modelado de sistemas usando UML 2.0

UML y Patrones, Craig Lraman

Paleta de colores: B/N para todos los elementos del diagrama.

Estandarizado por: GDS- DSIA

Referencias Bibliográficas

[1] Lasso, A. Arquitectura de Software. http://www.scribd.com/doc/210452/Arquitectura-de-

Software-Adrian-Lasso
[2] Perovich, D. y Vignaga, A. SAD del Subsistema de Reservas del Sistema de Gestión
Hotelera. Reporte Técnico RT03-15, InCo Pedeciba, Montevideo, Uruguay, 2003.
[3] Wei Lin. Software Design Specification Document, v: 1.2, 2Communicate, 2006.
[4] Weitzenfeld, A. Ingeniería de Software Orientada a Objetos con UML, Java e
Internet. Méjico, 2004.
[5] Appleton, B. A Software Design Specification Template. http://www.bradapp.net
[6] Montilva, J. y Rivero M. Diseño de Software. Versión 1.0. CEISoft. 2007
[7] Larman, C. UML y Patrones. 2da. Edición. Prentice Hall. 2003