Propuesta de La DSIA

Direccin de Servicios de Informacin Administrativa
Vicerrectorado Administrativo
Universidad de Los Andes
Propuesta para el
Documento de Diseo de Sistemas
de la DSIA
Versin 1.0
Grupo de Diseo de la DSIA

William J. Montilva C.
Lena Snchez B.
Lus E. Porras C.
Marisol Daz B.
Marzo, 2008
1 Introduccin
Este informe presenta una propuesta de la estructura que podra llevar el documento de
diseo del sistema (DDS) elaborado por el Grupo de Diseo adscrito a la Unidad de
Desarrollo de la Direccin de Servicios de Informacin Administrativa (UD-DSIA) de la
Universidad de Los Andes.
El documento DDS ser utilizado por el Grupo de Programacin de la UD-DSIA como una
gua para la codificacin e implementacin de los sistemas o aplicaciones que pudieran ser
desarrollados para las unidades administrativas de esta institucin universitaria.
Entre los objetivos que persigue esta propuesta para la especificacin del diseo de
software tenemos:
1. Producir un documento tcnico que describa todos los detalles del diseo de la
arquitectura del sistema o aplicacin y de todos los componentes que la conforman.
2. Proporcionar todos los detalles tcnicos requeridos por el Grupo de Programacin
para programar o producir cada uno de los componentes de software de la
aplicacin o sistema.
3. Servir de insumo para la planificacin y ejecucin de las pruebas de unidad,
integracin y aceptacin que realizar el Grupo de Pruebas al sistema.
4. Servir como material de gua o entrenamiento al nuevo personal que pueda ser
incorporado a un proyecto, proporcionando la informacin necesaria de cmo una
solucin ha sido diseada y como va a ser implementada.
5. Servir como un acuerdo entre el Grupo de Diseo, el Grupo de Programacin y el
Grupo de Pruebas, de cmo va a ser implementada y probada la funcionalidad
descrita en la especificacin de requisitos del sistema.
Esta propuesta ha sido organizada de la siguiente manera. La estructura del DDS, en su
primera versin, es presentada en la seccin 2. La seccin 3 describe cada uno de los puntos
(secciones o apartados) que contiene el DDS. La seccin 4 presenta algunas de las fichas
tcnicas creadas por el Grupo de Diseo 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 Diseo

Con la finalidad de producir un documento de diseo 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. Introduccin
1.1.
1.2.
1.3.
1.4.
1.5.
Propsito del sistema

Objetivos y restricciones de diseo
Definiciones, acrnimos y abreviaturas
Referencias
Estructura del documento
2. Arquitectura del Sistema

2.1. Arquitectura lgica (descomposicin en subsistemas)
2.2. Arquitectura fsica (topologa del sistema)
3. Diseo de los subsistemas

3.1. Diseo 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. Realizacin 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 grfica de usuario del caso de uso
3.1.3.1.5. Diagrama de navegacin del caso de uso
3.1.3.2. Realizacin del caso de uso <nombre caso de uso 2>
3.2. Diseo del subsistema <nombre del subsistema 2>
4. Diseo 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 Diseo del Sistema (DDS)
3 Descripcin de las secciones del documento

A continuacin se describe con detalle el contenido de cada una de las secciones de la
plantilla propuesta para el documento de diseo.
3.1
Portada del documento

La portada del DDS contendr los siguientes elementos:
Nombre del proyecto o sistema: seala el nombre del proyecto o sistema que
va a ser desarrollado.
Identificador del proyecto: corresponde a un nmero interno que la
organizacin le asigna a un determinado proyecto.
Versin: es un nmero compuesto de dos dgitos que hace referencia a la

versin del documento de diseo elaborado para este proyecto. El primer dgito
indica la versin del documento, puede ser incrementado cuando el grupo de
diseo considere que han sido realizado cambios importantes que ameriten una
nueva versin. El segundo dgito seala que han ocurrido cambios en la versin
de un documento, es por ello que ste nmero comienza en cero para una nueva
versin 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 elaboracin del documento de
diseo o el nombre del grupo de diseo.
Fecha: ndica la fecha en la que se publica est versin 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 pgina en que cada una de ellas comienza.
3.3
Introduccin
Esta seccin del DDS proporciona al lector una apreciacin global de lo que se tratar
en este documento. Describe el propsito y alcance de este documento y a quien va
dirigido. (1-2 prrafos)
Presenta adems, en los siguientes apartados, una visin general del sistema o
subsistema a desarrollar, las decisiones y restricciones de diseo. Una lista con las
principales definiciones de los trminos, acrnimos y abreviaturas, una lista de los
documentos que sirven de referencia y por ltimo, un resumen de la estructura o
organizacin de este documento de diseo.
3.3.1
Propsito del sistema
Esta seccin proporciona el punto de entrada para entender el sistema y el ambiente

en el cual este sistema operar. Presenta una visin global y resumida del sistema,
tomando como base lo escrito en el Documento de Especificacin de Requisitos del
sistema (DER) y especficamente donde se describe la aplicacin.
Consiste en realizar una breve descripcin del sistema, su mbito o contexto, sus
caractersticas ms relevantes, los procesos o funciones principales, as como sus
entradas y salidas ms importantes, sin incluir detalles de implementacin. En forma
opcional, podra incluirse un diagrama de contexto o general del sistema que muestre
los componentes principales del sistema y los sistemas externos que interactan con
l, adems de los flujos de datos que entran y salen del mismo. (1-5 prrafos)
Un ejemplo de la redaccin de esta seccin se muestra a continuacin.
El subsistema de Reservas es uno de los sistemas informticos de la cadena hotelera
KMG, cuyo propsito 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
operarn 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 reservacin 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 asignacin de una

habitacin al nuevo husped.
Sugerencia de otros hoteles de la cadena cuando no existan habitaciones

disponibles en el hotel que un cliente desea reservar.
La modificacin o cancelacin de una reserva previamente registrada.
La notificacin al cliente para confirmar una reserva cuando se han realizado

cambios en la misma.
La confirmacin de una reserva mediante una notificacin al cliente bien sea por email, fax, celular o beeper.
La deteccin de reservas caducadas o reservas no tomadas.
El clculo de una comisin por penalizacin de aquellos clientes que no cancelaron

a tiempo una reserva.
La notificacin al sistema de facturacin para que ste realice la apertura de una

cuenta a fin de registrar los consumos realizados por sus huspedes.
El subsistema tendr como entrada:
La informacin personal de sus clientes
Los datos de una reserva, la cual ser capturada a travs de un formulario
El subsistema deber producir la siguiente informacin como salida:
El mensaje de confirmacin de una reserva
La factura o recibo de consumo de un cliente
La comisin por penalizacin de una reserva no cancelada
Informacin estadstica
caducadas.
3.3.2
de
reservas
tomadas,
modificadas,
canceladas
Objetivos y restricciones de diseo
Describe los principales objetivos, limitaciones o restricciones que tienen un gran

impacto en el diseo del sistema. (1-5 prrafos)
Una gran mayora de estos objetivos y restricciones lo determinan:
La infraestructura tecnolgica que posea la organizacin donde ser instalado

este sistema, por ejemplo: manejador de base de datos a utilizar, caractersticas
mnimas que deben poseer los computadores a ser instalados, caractersticas de
la red que comunicar estos computadores y el protocolo usado, etc.
El software que ser utilizado para la construccin del sistema y el ambiente

operativo donde ste ser ejecutado.
La reutilizacin de componentes de software existentes en la organizacin.
Los requisitos de interfaz de usuario que se le impondrn al sistema.
Los requisitos de desempeo, seguridad, confiabilidad y calidad impuestos al

sistema.
El uso de estndares y normativas que deben ser tomadas en cuenta para el

desarrollo del sistema, entre otros.
A continuacin 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 poltica no realizar reservas por encima de su disponibilidad (overbooking). En este
sentido, el sistema o recepcionista debera 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, modificacin,
eliminacin y consulta de una reserva efectuada por un cliente o recepcionista pueda
llevarse a cabo a travs 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
desempeo, 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 realizacin de una reserva debe ser menor a 3 minutos cuando el cliente la realiza
directamente por telfono o en la recepcin 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.
Adems, se desea reutilizar un sistema de facturacin 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 podra
utilizar como navegador el Internet Explorer o algn navegador de software libre como el
Mozilla Firefox. El sistema utilizar el protocolo estndar de comunicacin HTTP a travs
del canal de comunicacin TCP/IP. Por otra parte, el desarrollo de la interfaz grfica se
realizar en forma sencilla utilizando un editor HTML con manejo de Forms, empleando el
lenguaje de programacin PHP para generar el contenido dinmico de las pginas web y
de la programacin de la lgica de la aplicacin.
3.3.3
Definiciones, acrnimos y abreviaturas
En este apartado se deben incluir todos los trminos tcnicos, acrnimos y

abreviaturas que sern usadas en el documento. Un ejemplo de estos trminos
tcnicos utilizados podran ser los casos de uso, arquitectura del sistema, o bien,
siglas definidas para ciertos productos del diseo 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 descripcin de como el documento ha sido organizado.

3.4
Arquitectura del sistema

Describe la arquitectura del sistema tanto en su forma lgica como fsica.
3.4.1
Arquitectura lgica del sistema
Esta seccin presenta la estructura lgica global de la arquitectura del sistema, de

acuerdo a un patrn arquitectnico elegido. La arquitectura del sistema se representa
a travs de un grfico que muestra como la funcionalidad del sistema ha sido dividida
en subsistemas o componentes.
Una breve descripcin de la asignacin de la funcionalidad de cada subsistema debe
ser incluida, as como el detalle de los servicios proporcionados por cada subsistema.
Se debe incluir tambin, una descripcin del estilo o patrn arquitectnico utilizado
para dar forma a la arquitectura del sistema.
Uno de los patrones arquitectnicos ms usados en la actualidad para el desarrollo de
aplicaciones de porte empresarial es el denominado arquitectura de 3 o ms capas.
Este estilo arquitectural separa lgicamente y en algunos casos fsicamente, los
aspectos de presentacin de la aplicacin (interfaz de usuario), la lgica del negocios
(automatizacin del flujo trabajo) y la gestin de los datos (bases de datos), tal como
se muestra en la siguiente figura [1].
Capa de
Capa de
Presentacin
Presentaci
Presentacin
Capa Lgica
Capa L
Lgica
de Negocio
de Negocio
Capa de
Capa de
Datos
Datos
La capa de presentacin es la encargada de manejar la interfaz del usuario,

controlando la captura y presentacin de los datos y recibiendo los eventos
accionados por lo usuarios a travs de la interfaz. Esta capa se comunica nicamente
con la capa de lgica de negocios.
La capa de lgica de negocios tiene la responsabilidad de manejar la funcionalidad
del sistema, implementando a travs de objetos de negocio (programas) las reglas de
negocio que deben cumplirse. Esta capa se comunica con la capa de presentacin 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 recuperacin de los datos. Se comunica nicamente con la capa
de lgica de negocios.
Un ejemplo de la descripcin y estructura de la arquitectura para un sistema de video
juegos es mostrada a continuacin [2]:
El sistema emplear el estilo arquitectnico de capas y ser organizado en tres capas: la
capa de interfaz, la capa de la aplicacin y la capa de almacenamiento.
La capa de interfaz contendr la interfaz grfica 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 mens.
La capa de la aplicacin contendr la lgica y reglas para almacenar datos en la capa de la
base de datos y tambin 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 arquitectnico de tres-capas ser usado porque no slo separa la interfaz del
usuario de los datos almacenados, sino que tambin, provee una capa de lgica de la
aplicacin. La capa de aplicacin provee una capa intermedia que permite que los datos
almacenados en la base de datos y los componentes GUI estn dbilmente acoplados.
Esta separacin lgica permite que una capa pueda ser modificada sin alterar el resto de
las capas o introducir pequeos cambios en alguna de ellas. Por ejemplo, la capa de la
aplicacin podra 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 ms fcil 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 patrn de arquitectura elegido para el Subsistema de Reservas es el de niveles de

abstraccin o capas. Cada capa sugiere un tipo diferente de mdulos 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 lgica del usuario. Esta
capa consiste de un mdulo por caso de uso, el cual agrupa la lgica realizada por el caso
de uso y el conjunto de pginas web dinmicas utilizadas por dicha lgica. Los mdulos
identificados y sus interdependencias se presentan en el siguiente diagrama:
La capa de Servicios del Sistema contiene los servicios bsicos que debe proveer el
sistema; estos servicios son directamente utilizados por los mdulos de la capa superior.
En esta capa se definen las clases controladoras encargadas de manejar la lgica de los
casos de uso, crendose para ello, una clase interfaz por caso de uso. Se crea un mdulo
por subsistema, donde cada mdulo llevar a cabo todas las interfaces requeridas por los
casos de uso vinculados a ese subsistema. La siguiente figura muestra los servicios
bsicos de esta capa.
La capa de Servicios de Negocio agrupa los mdulos que representan los servicios para el
manejo de informacin del negocio. Estos servicios son an ms bsicos que el de la capa
superior y pueden ser compartidos por otros subsistemas. Cada mdulo 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 mdulos de esta capa.
La capa de Infraestructura contiene todos los mdulos necesarios para utilizar los servicios
de la plataforma. En esta capa residen principalmente adaptadores de los servicios
brindados por la plataforma, entre ellos el mdulo de acceso a datos y la comunicacin a
otros sistemas, como el de facturacin y mensajera. Los servicios de esta capa son
mostrados a continuacin."
3.4.2
Arquitectura fsica del sistema
Esta seccin describe la topologa del sistema, mostrando como sern asignados en
forma fsica los diferentes subsistemas o componentes (software) a los diferentes
equipos de computacin (hardware). Para describir la asignacin del software al
hardware utilice los diagramas de despliegue y de componentes de UML.
Un ejemplo de la arquitectura fsica del sistema de Video Juegos es mostrado a
continuacin [2]:
Continuando con el ejemplo del subsistema de Reservas, la arquitectura fsica es

representada con el siguiente diagrama [3].
Esta arquitectura fsica considera la distribucin de la aplicacin en cuatro tipos de nodos:

Cliente, Recepcin, Server, LegacyServer.
El primer nodo representa a las estaciones de trabajo de los usuarios finales. El nodo
Recepcin corresponde a la estacin de trabajo ubicada en la recepcin del hotel.
El nodo Server representa al equipo en donde correr el servidor web y la aplicacin del
Subsistema de Reservas.
El ltimo nodo, LegacyServer, representa a aquella infraestructura informtica necesaria
para correr los sistemas legados, entre ellos el sistema de facturacin.
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
Diseo de los subsistemas
Esta seccin describe cada uno de los subsistemas que han sido determinados en la
arquitectura lgica del sistema. Para ello, se incluye una descripcin de la
funcionalidad del subsistema a travs de una vista de casos de uso. Una descripcin
del modelo de datos que soporta, mostrados mediante una vista de datos y la
inclusin de una serie de elementos de modelado que describen como los casos de
uso del sistema pueden ser realizados.
3.5.1
3.5.1.1
Diseo del Subsistema <nombre del subsistema >

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 ms representativos de este subsistema. Cuando los casos
de uso contenidos en estos diagramas son numerosos, estos podran ser agrupados de
forma funcional utilizando los paquetes (carpetas) de UML. Esta organizacin crea
una jerarqua de diagramas de casos de uso, los cuales por razones de claridad, no
deberan 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, podra ser:
Gestin de Socios
Gestin de Alquileres
3.5.1.2
Gestin de Pelculas
Vista de Datos del subsistema <nombre del subsistema>
Esta vista muestra el subconjunto de clases de entidad que sern utilizadas por este
subsistema. Las clases de entidad se refieren a aquellas clases que van a guardar datos
en forma persistente a travs de un manejador de base de datos. En otras palabras,
representa la porcin del modelo conceptual de datos que ser utilizada por este
subsistema.
Para la construccin 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 sera [3]:
Subsistema de Reservas
3.5.1.3
Realizaciones de Casos de Uso <nombre del subsistema>
En esta seccin se detalla como cada uno de los casos de uso que pertenecen a este
subsistema van a ser realizados. La realizacin de un caso de uso permite expresar
como el comportamiento definido en un escenario, es distribuido en funcin de los
objetos o clases que colaboran entre si para realizar una operacin.
3.5.1.3.1 Realizacin del caso de uso: <nombre del caso de uso>
Para describir la realizacin de un caso de uso ser necesario: una descripcin 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 colaboracin que
muestra como la clases interactan. De manera opcional, se puede mostrar los
componentes de la interfaz grfica de usuario (pantallas, vistas o formularios)
involucrados en la realizacin del caso de uso y un diagrama de navegacin a travs
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
descripcin textual muestra el flujo de eventos que ocurre entre uno o ms actores y
el sistema, incorporando detalles de la interfaz, sus atributos y nombres de las clases
utilizadas en la realizacin del caso de uso.
El escenario del caso de uso hacer reserva es mostrado a continuacin [3]:
Otro ejemplo de un escenario de caso de uso para un sistema de Punto de Venta se

presenta en la siguiente figura.
CU-01
Caso de Uso Procesar Venta

Descripcin
Actores
Este caso de uso de uso permite que un Cajero capture la venta de una
serie de productos y registre su pago en efectivo
Cliente (Iniciador), Cajero
Tipo
Primario
Requisitos
RF 1.1, RF 2.3
Asociados
Precondicin
El Cajero se identifica y autentica
Curso Normal (Bsico)
Paso
1
2
3
4
5
6
7
Accin
Este caso de uso comienza cuando un Cliente llega a la caja del Terminal de punto
de venta (TPDV) con productos para comprar.
El Cajero inicia una nueva venta.
El cajero registra el identificador de cada producto. Si hay varios productos de un
mismo tipo, el Cajero puede introducir su cantidad.
El sistema registra la lnea de venta y presenta la descripcin del producto, precio y suma
parcial.
El Cajero repite los pasos 3 y 4 hasta que termine de introducir los productos y le
indica al TPDV que se concluyo la venta.
El Sistema calcula y presenta el monto total de la venta con sus impuestos.
El Cajero le dice al Cliente el total de la venta.

El Cliente efecta un pago en efectivo, posiblemente con un monto mayor que el
total de la venta.
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 artculos comprados.

Se registra la venta, su importe y su respectivo impuesto. Se actualiza la
Postcondicin
contabilidad y el inventario
Cursos Alternos o Excepcionales
Paso
3a
3-7a
8a
Accin
Introduccin de un artculo invlido:

1. El sistema seala el error y rechaza la entrada.
El cliente le pide al Cajero que elimine un artculo de la compra:
1. El Cajero introduce el identificador del artculo para eliminarlo.
2. El Sistema resta el artculo de la compra y muestra la suma parcial.
El cliente le pide al Cajero que cancele la venta:
1. El Cajero cancela la venta.
2. El Sistema elimina los datos de la venta actual.
Diagrama de clases de diseo del caso de uso: <nombre del caso de uso>
Un diagrama de clases en UML es presentado aqu, para mostrar las clases de diseo
de software que colaboran en la realizacin del caso de uso. Este diagrama muestra la
especificacin de las clases software que intervienen en este caso de uso, presentando
sus atributos, mtodos, asociaciones, interfaces y operaciones, navegabilidad y
dependencias.
Los tipos de clases de diseo 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 informacin perdurable en el sistema. Las clases de interfaz
modelan la interaccin entre el sistema y sus diferentes usuarios, asociadas con la
entrada de datos y salida de informacin. 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 bsicamente un Modelo de Diseo de Objetos que
corresponde a la capa del dominio o lgica de la aplicacin, el cual contiene las
clases software que manejaran la lgica del negocio y cuyos nombres son derivados
de los conceptos del negocio. El siguiente ejemplo ilustra un diagrama de clases de

diseo 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

descripcin textual (escenario) de un caso de uso. Pudiera ser un elemento opcional
cuando la realizacin del caso de uso sea sencilla e involucre pocas clases o pocos
mtodos.
Un diagrama de secuencia se usa principalmente para mostrar en que orden
interactan los objetos o clases en la realizacin 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
interactan, 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 genricas de software, creadas para el manejo de
la interfaz, de la lgica de la aplicacin y del acceso a datos es mostrado en el
siguiente diagrama de secuencia del caso de uso registrar usuario de un sistema de
Reservaciones Areas [4].
Caso de uso: Crear Registro Usuario
Interfaz grfica de usuario del caso de uso: <nombre del caso de uso>
En este apartado se mostrarn los diferentes componentes de la interfaz grfica del

usuario (pantallas, ventanas, formularios o vistas) involucrados en la realizacin de
este caso de uso.
Adicionalmente se podra incluir aqu, los formatos de impresin 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 navegacin del caso de uso: <nombre del caso de uso>
Esta seccin es opcional y podra ser utilizada slo cuando la realizacin del caso de
uso tenga cierta navegacin compleja que sea necesario describirla. En este caso, se
utilizara un diagrama de estados de UML para mostrar dicha navegabilidad.
La siguiente figura presenta un posible diagrama de navegacin para el caso de uso
hacer reserva, donde se muestran los diferentes componentes de la interfaz de
usuario presentes en la realizacin de este caso de uso.
3.6
Diseo de la Base de Datos

Esta seccin del DDS, contiene los diseos de la base de datos que determinan como
los datos que van a ser incluidos en la base de datos, estn lgica y fsicamente
organizados. Para ello, el diseo 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
travs de uno o ms diagramas de clases en UML o diagramas entidad-asociacin, el
cual es independiente del entorno tecnolgico utilizado. El segundo nivel presenta el
modelo implementable de la base de datos, descrito mediante un diagrama fsico 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 integracin de los diferentes diagramas (de clases en UML o de
entidad-asociacin) 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 diseo PowerDesigner, los diagramas
generados como Modelo Orientado a Objeto (Object-Oriented Model) o Modelo
Conceptual de Datos (Conceptual Data Model) son incluidos en esta seccin.
Un diagrama de clases en UML es mostrado aqu, para representar el modelo
conceptual de datos del subsistema de Reservas.
Recepcin
0..*
Hotel
Habitacin
-nombre : String
-ciudad : String
-IPAddress : String
-nombre : String
1
1..*
0..1
*
Cliente
-idCliente : Integer
-nombre : String
-usuario : String
-password : String
-email : String
-tel : String
-fax : String
Reserva
-idReserva : Integer
-checkin
-checkout
-estado
1
*
TipoHabitacin
-nombre : String
0..*
EstadoReserva
Husped
-nombre : String
-documento : String
-pais : String
3.6.2
Clase enumerada
-Pendiente
-En Curso
-Finaliza
-Cancelada
-NoTomada
Esquema Implementable de la Base de Datos
Esta seccin presenta el resultado de la conversin del esquema conceptual de la base

de datos a un esquema implementable (en nuestro caso, el modelo relacional), donde
se incluyen detalles de implementacin fsica de acuerdo al manejador de base de
datos a usar.
Si se utiliza la herramienta de diseo PowerDesigner, ste genera un diagrama
denominado Modelo Fsico de Datos (Physical Data Model) que describe
grficamente la estructura de la base de datos y sus caractersticas fsicas.
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 podra denominarse Modelo de Datos del Sistema o Diccionario de
Datos del Sistema.
Esta seccin 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, descripcin, tipo de dato, longitud y el posible dominio de valores
que podra tomar.
3.7
Anexos
Esta seccin incluir toda la informacin adicional o de soporte al diseo del sistema.
Los anexos podran incluir:
Tabla de definicin de usuarios (actores)
Tabla de opciones del sistema (indicando el caso de uso asociado)
Matriz usuario-opciones del sistema
Tabla de descripcin de reglas de negocio del sistema
Tabla de casos de uso-reglas de negocio
4 Fichas Tcnicas de Productos de Diseo

En esta seccin se describen algunas de las fichas tcnicas de productos usadas en el diseo
de sistemas. Estas fichas describen las notaciones empleadas para construir los diversos de
diagramas de UML presentes en este documento DDS.
Tienen el propsito de servir como una referencia rpida al lector de este documento para
entender la simbologa utilizada en cada uno de estos diagramas. A continuacin, se anexan
las fichas definidas por cada producto de diseo.
4.1
Ficha Tcnica para los Diagramas de Casos de Uso

DSIA rea de Ingeniera de Requisitos y Diseo de Software
FICHA TCNICA DEL PRODUCTO:
DIAGRAMA DE CASOS DE USO
Fase en la que se usa: Ingeniera de Requisitos

y Diseo de Software
Nombre del producto: Diagrama de

Caso de uso
Fecha:28 /11 /2007
Herramientas para construirlo:

PowerDesigner 12, Powerdesigner12.5
Visual Architect 2.0, Visio
Metodologa: UML
Versin: 1.0
Versin: 2.0
Definicin del producto: Diagrama que permite especificar los requisitos funcionales de
un sistema
Utilidad para el cliente del proceso de diseo: Permite estructurar el sistema en
funciones y definir los actores o roles que tendrn acceso a dichas funciones.
Nivel de detalle requerido para Diseo: a nivel de funciones que realizan alguna
transaccin que involucra un conjunto de datos.
Smbolos utilizados y su significado

Nombre del smbolo
Actor o Rol
Paquete de casos de uso
Caso de uso
Significado
Smbolo
Es quien interacta con el

sistema. Puede acceder a
una o ms funciones. En
algunos casos, el actor es
un sistema.
Es un conjunto de casos de
uso agrupados segn un
cierto criterio, el cual puede
ser: grupos de funciones,
por usuarios, o por fases del
proceso organizacional a
quien los casos de uso dan
soporte.
Funcin que el sistema pone
a la disposicin de los
actores. Produce un
resultado de valor para los
actores
2. Registrar ingreso a Tesorera
1 1 . Ca r g a r
1 2 . Ca r g a r
1 3 . A c t u a zil a r
CP - O
d e
SAF
f n
i a n c e
i r a s
r e c a u d o s
p o r
d e l Dp t o
t ip o
d e
N m
Re c e p c o
i n si t a
<<e x t e n d >>
1 4 . Va d
il a r
1 5 . Bu s c a r
CP - O
r e c a u d o s
<< e x t e n d > >
1 6 . Bu s c a r
f n
i a n c e
i
<<e x t e n d >>
1 7 . I n g r e s a r
f n
i a n c e
i r a s
d e
a
l s
Continuacin ficha tcnica: Diagramas de Casos de Uso
Relacin de comunicacin
Relacin include
Relacin extend
Relacin de generalizacin
Usado para establecer una

asociacin bidireccional
entre un actor y un caso de
uso
Usado para establecer la
relacin entre 2 casos de
uso, en el cual un caso de
uso contiene o incluye al
otro
relacin entre 2 casos de
uso en la cual uno extiende
el comportamiento del otro.
El caso de uso 2 se realiza
si dentro del caso de uso 1
se da cierta condicin.
relacin es un entre
actores o casos de uso,
generales y especficos
caso de uso 1
caso de uso 1
<<include>>
Caso de Uso 2
<<extend>>
Caso de Uso 2
Utilizada entre actores:
usuario autorizado
usuario 2
usuario 1
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:
Bibliografa consultada:
Vistas de uso
Modelado de sistemas usando UML 2.0
Continuacin ficha tcnica: Diagramas de Casos de Uso

Ejemplo de este producto:
11.Cargar CP-OP de SAFEP
12.Cargar OP financieras del Dpto Nmina
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 numeracin de los casos de uso de todo el

subsistema o sistema es estrictamente secuencial, utilizando nmeros ordinales,
seguidos de un punto y el nombre del caso de uso. Los nmeros deben tener 3
dgitos. Los paquetes de casos de uso tambin deben tener nmeros. Si hay ms
de un nivel en los paquetes de casos de uso, se puede usar jerarqua: 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 Ingeniera de Requisitos y Diseo de Software
4.2
Ficha Tcnica para la Organizacin de Casos de Uso

FICHA TCNICA DEL PRODUCTO: ORGANIZACIN DE CASOS DE USO
Fase en la que se usa: Ingeniera de Requisitos

y Diseo Detallado

Paquetes de Casos de Uso
Fecha14/1 /2008

PowerDesigner 12, Powerdesigner12.5
Visio
Metodologa: UML
Versin: 1.0
Versin: 2.0
Definicin del producto: Los paquetes ofrecen un mecanismo general para la
organizacin 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 diseo: Permite estructurar el sistema en
subsistemas o mdulos.
Nivel de detalle requerido para Diseo:

Nombre del smbolo
Actor o Rol
Paquete
Significado
Smbolo
Es quien interacta con el

sistema. Puede acceder a
uno o ms paquetes. En
algunos casos, el actor es
un sistema.
Es un conjunto de paquetes
o de casos de uso
agrupados segn un cierto
criterio, el cual puede ser:
1. Cargar informacin
Relacin de comunicacin
Estereotipo
Relacin de dependencia
Usado para establecer una

asociacin bidireccional
entre un actor y un paquete.
Se muestran a partir del
segundo nivel.
Usado para identificar el tipo
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
paquete. Se muestran a
partir del segundo nivel.
<< subsistema >>
4. Solicitar pagos
6. Controlar pagos
Continuacin ficha tcnica: Organizacin de Casos de Uso
Insumos: Cadena de Valor de procesos, Diagramas de procesos, Diagrama de Jerarqua

de procesos, Diagramas de actividades. Inventario de Procesos, rbol de Procesos.
Modelado de sistemas usando UML 2.0.
El Lenguaje Unificado de Modelado.
Diagrama de Referencia, Rumbaugh,
Jacobson y Booch.
Arquitectura de Software, Adrin Lasso.
Ejemplo de este producto:

A nivel de sistema:
Sistema de Emisin y Control de Pagos
<<sistema>>
<<subsistema>>
<<subsistema>>
Subsistema 1
Subsistema 2
<<subsistema>>
Subsistema 3
Formulacion Presupuesto
<<Subsistema>>
GestionarLineamientos
<<Subsistema>>
<<Subsistema>>
<<Subsistema>>
Formular Proyecto
<<Subsistema>>
GestionarModificacionesPpto
GestionarIngresoSistema
<<Subsistema>>
Formular Anteproyecto
RealizarEstadisticas
<<Subsistema>>
Administracin del Sistema
Si hay ms de 2 niveles dentro de los subsistemas, se pudiera presentar en

forma de rbol:
Subsistemas
Mdulos
Casos de Uso
A nivel de un subsistema:
Object-Oriented Model
Model: Modelo de Casos de uso
Package:
Diagram: SUBSISTEMA GESTIN DE PAGOS
Author: Nancy B. de Garca Date: 14/01/2008
Version: 2
Recepcionista
<<mdulo>>
1. Cargar informacin
<<mdulo>>
2. Registrar ingreso a Tesorera
Controlador Financiero
Gestor de Pagos : 1
<<mdulo>>
Supervisor de Tesorera : 1
3. Tramitar pagos
<<Gestin Cuentas Bancarias>>
1.2.1 Autorizacin de Transferencia de Fondos
<<mdulo>>
4. Solicitar pagos
Revisor de documentacin

1.3 Manejar movimientos
<<mdulo>>
<<mdulo>>
5. Generar pagos
6. Controlar pagos

1.2.2.2 Cheques

1.5 Manejar Cuentas en Divisa
Supervisor de Tesorera : 2
Revisor de instrumentos de pago
<<mdulo>>
7.Consultar pagos
Gestor de Pagos : 2
Consideraciones especiales:
Cuando haya ms de 2 niveles se dibuja en forma de rbol; a nivel de un mdulo,
se deben mostrar las relaciones de dependencia y los actores.
Mxima cantidad de niveles: 3
Criterios de buen empaquetamiento: alta cohesin 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
4.3
Ficha Tcnica para los Escenarios de Casos de Uso

FICHA TCNICA DEL PRODUCTO: ESCENARIOS DE CASOS DE USO
Fase en la que se usa:
Fecha: 28/11/2007
Metodologa: UML
Versin 1.0
Versin:
2.0
Nombre del producto: Escenario de

caso de uso (realizacin del caso de
uso detallado)
PowerDesigner 12, PowerDesigner
12.5
Word, OpenOffice

Nombre de la
seccin
Flujo de eventos
normal o
especificacin del
caso de uso
Flujo de eventos
excepcionales o
alternativos.
Flujo alternativo o
puntos de extensin.
Puntos de excepcin.
Significado
Conjunto de pasos escrito en lenguaje
natural que muestra el flujo de eventos
principal, a travs de una secuencia de
acciones que ocurren entre los actores y el
sistema.
Flujo alternativo:
Conjunto de pasos que describen el flujo de
acciones al ocurrir una cierta condicin. Se
utiliza para mostrar las diferentes opciones
posibles de un conjunto donde todas tienen
la misma posibilidad de ser seleccionadas
por el usuario.
Flujo excepcional:
Conjunto de pasos que describen las
acciones que se deben realizar en caso de
ocurrir alguna condicin excepcional,
diferente al flujo normal de eventos. Por lo
general, se utiliza para manejar condiciones
de validacin, manejo de errores, etc.
Precondiciones o
condiciones de
entrada
Describen la condicin previa al

conjunto de acciones del flujo feliz,
o lo que debe ocurrir antes que se
ejecute este flujo
Notacin
Numeracin de los pasos: nmeros
ordinales: 1., 2., ..n.
Frases empleadas:
El usuario < accin >

Ejemplo: El usuario selecciona Guardar.
El sistema <accin>
Ejemplo: El sistema guarda el nmero,
fecha de la orden en la Base de Datos.
Numeracin de pasos de un flujo

alternativo:
Nmeros ordinales seguidos de una
letra. Cuando haya ms de una accin
dentro de un flujo excepcional, se
incorporan nmeros.
Ejemplo: flujo normal:
2.- El sistema muestra la informacin
de la orden en pantalla.
Flujo excepcional:
2.a.- Si la orden no existe, el sistema
muestra un mensaje de advertencia.
Numeracin de pasos de un flujo
alternativo:
Ejemplo: flujo normal:
3.- El usuario selecciona una opcin.
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.
Ejemplo:
El usuario Ingres al sistema de
Ordenes de Pago
Continuacin ficha tcnica: Escenarios de Casos de Uso

Postcondiciones
o condiciones de
salida
Describe el estado final obtenido

despus de ejecutarse el flujo
normal de eventos.
* El usuario registr los datos de la

solicitud de autorizacin para la
apertura de una cuenta bancaria.
* El sistema almacen los datos de
la solicitud y actualiz el estado de
la misma.
Modelado de Sistemas usando UML 2.0
Ejemplos de este producto:

Use Case: 4. Cargar informacin de Contratistas
1.
Card of use case

Name
Code
Parent
4. Cargar informacin de Contratistas

4_Cargar_informacion_de_Contratistas
Package '1. Cargar informacin'
2. Action steps of use case

1. El sistema muestra mensaje de confirmacin para iniciar la carga de informacin 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, Direccin,
Localidad, Tlf, Actividad, Representante Legal, C.I. del Representante.
4. El sistema valida Nombre y RIF.
5. Para cada registro el sistema asigna un nmero de contratista y guarda la informacin.
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
errneo.
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 informacin 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
Association_4
Code
Association_4
Class Name
Use Case Association
Continuacin ficha tcnica: Escenarios de Casos de Uso
Consideraciones especiales:
1) Los escenarios de Casos de Uso para Ingeniera de Requisitos, no deben
involucrar aspectos de interfaz grfica 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 sern el insumo
para el diseador.
2) Cuando el escenario ofrezca varias opciones, las cuales tienen la misma
posibilidad de ser elegidas y el caso de uso tenga una relacin de extend
con otros casos de uso, se redacta as:
Ejemplo: caso de uso con relacin extend a travs de las opciones <opcin a>
<opcin b> y <opcin c>
Flujo feliz:
1. El usuario selecciona una opcin.
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 ms se utiliza y existen otras opciones, bien sea que se van a resolver
dentro del mismo caso de uso o a travs de un extend, se redacta en forma
parecida a 2), slo que la opcin ms 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
4.4
Ficha Tcnica para los Diagramas de Secuencia

FICHA TCNICA DEL PRODUCTO: Diagrama de Secuencia
Diseo Arquitectnico
Diseo Detallado
Fecha:1 / 10 / 2007
Metodologa: UML

secuencia detallado
PowerDesigner 12
Visual Architect 2.0
Versin: 1.0
Versin: 2.0
Definicin del producto: Diagrama que describe la dinmica de una aplicacin o una parte de
ella, mostrando las interacciones entre los objetos desde el punto de vista temporal, insistiendo
en la cronologa del envo de mensajes.
Utilidad para el cliente del proceso de diseo: Permite conocer en detalle para cada evento
del sistema o hilo de operacin, cules mtodos se requieren de las instancias de las clases
involucradas en la realizacin del caso de uso, as como el ordenamiento de los mensajes entre
los objetos. Facilita la programacin orientada a objetos.
Nivel de detalle requerido para Programacin: Se puede obtener uno o ms 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 operacin. El nivel de detalle debe incluir: mtodos
utilizados por clase, atributos o parmetros que se pasan a travs de los mensajes, valores de
retorno, condiciones sobre los mensajes e iteraciones, tipos de mensajes (sncronos, asncronos,
de retorno). Tambin se necesita identificar la clase controladora que resolver el evento del
sistema, y debe estar previamente definida con todas sus operaciones, y debidamente
documentada.

Nombre del smbolo
Actor
Lnea de vida
Ejecucin caja de
activacin
Significado
Smbolo
Representa al actor que inicia los

eventos del sistema recibe
mensajes del sistema a travs de la
clase controladora.
Lnea de vida asociada a un objeto.

Representa la duracin de la vida
del objeto dentro del diagrama de
secuencia.
Indica la duracin. Es un elemento

opcional que se puede utilizar para
apilar operaciones que se activan
durante una temporalidad dada en
el objeto que emite los mensajes.
:clase 2
:clase 2
Continuacin ficha tcnica: Diagramas de Secuencia
Uso de la interaccin
Alternativas de interaccin
Mensajes entre objetos
Indica una referencia que se hace

de una interaccin, la cual puede
definirse como un pedazo del
diagrama de secuencia que es
utilizado en otra parte, as como la
referencia a otro diagrama de
secuencia.
Se utilizan para demarcar dentro del
diagrama de secuencia, la seccin
de acciones dada una u otra
condicin. Las condiciones se
separan por lneas punteadas.
ref
SequenceDiagram_121()
alt
[Condition]
[Condition]
Establecen el tipo de comunicacin

entre objetos del diagrama; existen
varios tipos:
a)
Elementos de un mensaje
Indefinido: puede ser un

flujo sncrono o asncrono
b) Sncrono: el objeto que
enva un mensaje espera
una respuesta.
c) Asncrono: el objeto que
manda el mensaje no
espera la respuesta del
otro objeto, sino que
contina su ejecucin.
d) Retorno: muestra el
retorno a partir de una
llamada de un objeto;
pueden mostrarse los
valores que retorna.
Algunos diseadores
excluyen este tipo de
mensajes.
e) Creacin de objeto: indica
el inicio de vida del objeto
a quien se enva el
mensaje.
f) Destruccin de objeto:
indica la destruccin
explcita del objeto o la
finalizacin de su lnea de
vida.
g) Mensaje this: es un
mensaje que enva un
objeto a s mismo.
Nota: para los mensajes indefinidos,
asncronos o tipo this se puede
incluir la caja de duracin.
Mtodo: el mtodo indica la accin
que realizar la clase que recibe
dadas las condiciones y parmetros
de la clase que enva. En el
ejemplo, Calcular es un mtodo
del objeto b.
Argumentos o parmetros: si el
mtodo requiere de argumentos
para su ejecucin, stos se hacen
explcitos.
Valor de retorno o variable de
retorno: es el valor que retorna el
mtodo invocado.
:clase 1
Actor
mensaje "this"
Mensaje indefinido
Mensaje sncrono
Mensaje asncrono
Mensaje de retorno
Creacin del objeto
:clase 2
Destruccin del objeto
objetoa:clase 1
objeto b:clase 2
m
n:= 1 [Si x > 2]: z:= Calcular(x,y)
Continuacin ficha tcnica: Diagramas de Secuencia

Elementos de un mensaje
Condicin: Indica entre corchetes la

condicin bajo la cual se ejecuta el
mtodo invocado.
Iteracin: Indica desde qu valor
hasta qu valor se va a repetir la
ejecucin del mtodo invocado.
Para el caso que la iteracin no se
haga para un mensaje sino para
una pieza del diagrama, se encierra
en un recuadro las acciones y se
coloca la iteracin entre corchetes.
objetoa:clase 1
objeto b:clase 2
objeto c:clase 3
[Si x > 2]: z:= Calcular(x,y)

IngresaDatos(x, y, z)
*[n:= 1..m]
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 Bibliogrficas
[1]
Lasso, A. Arquitectura de Software. http://www.scribd.com/doc/210452/Arquitectura-deSoftware-Adrian-Lasso
[2] Perovich, D. y Vignaga, A. SAD del Subsistema de Reservas del Sistema de Gestin
Hotelera. Reporte Tcnico RT03-15, InCo Pedeciba, Montevideo, Uruguay, 2003.
[3]
Wei Lin. Software Design Specification Document, v: 1.2, 2Communicate, 2006.
[4] Weitzenfeld, A. Ingeniera de Software Orientada a Objetos con UML, Java e

Internet. Mjico, 2004.
[5] Appleton, B. A Software Design Specification Template. http://www.bradapp.net
[6] Montilva, J. y Rivero M. Diseo de Software. Versin 1.0. CEISoft. 2007
[7] Larman, C. UML y Patrones. 2da. Edicin. Prentice Hall. 2003

Propuesta de La DSIA

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Propuesta de La DSIA

Cargado por

Copyright:

Formatos disponibles

Direccin de Servicios de Informacin Administrativa

Grupo de Diseo de la DSIA

2 Estructura del Documento de Diseo

Portada del documento

Propsito del sistema

2. Arquitectura del Sistema

3. Diseo de los subsistemas

3.1.3.1. Realizacin del caso de uso <nombre caso de uso 1>

4. Diseo de la Base de Datos

Figura 1. Estructura del Documento de Diseo del Sistema (DDS)

3 Descripcin de las secciones del documento

Portada del documento

Identificador del proyecto: corresponde a un nmero interno que la

organizacin le asigna a un determinado proyecto.

Versin: es un nmero compuesto de dos dgitos que hace referencia a la

Autores: lista de las personas que participan en la elaboracin del documento de

diseo o el nombre del grupo de diseo.

Fecha: ndica la fecha en la que se publica est versin del documento

Propsito del sistema

Esta seccin proporciona el punto de entrada para entender el sistema y el ambiente

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 asignacin de una

Sugerencia de otros hoteles de la cadena cuando no existan habitaciones

La modificacin o cancelacin de una reserva previamente registrada.

La notificacin al cliente para confirmar una reserva cuando se han realizado

La deteccin de reservas caducadas o reservas no tomadas.

El clculo de una comisin por penalizacin de aquellos clientes que no cancelaron

La notificacin al sistema de facturacin para que ste realice la apertura de una

El subsistema tendr como entrada:

La informacin personal de sus clientes

Los datos de una reserva, la cual ser capturada a travs de un formulario

El subsistema deber producir la siguiente informacin como salida:

El mensaje de confirmacin de una reserva

La factura o recibo de consumo de un cliente

La comisin por penalizacin de una reserva no cancelada

Objetivos y restricciones de diseo

Describe los principales objetivos, limitaciones o restricciones que tienen un gran

La infraestructura tecnolgica que posea la organizacin donde ser instalado

El software que ser utilizado para la construccin del sistema y el ambiente

La reutilizacin de componentes de software existentes en la organizacin.

Los requisitos de interfaz de usuario que se le impondrn al sistema.

Los requisitos de desempeo, seguridad, confiabilidad y calidad impuestos al

El uso de estndares y normativas que deben ser tomadas en cuenta para el

A continuacin se muestra un ejemplo de los objetivos y restricciones que se le

Definiciones, acrnimos y abreviaturas

En este apartado se deben incluir todos los trminos tcnicos, acrnimos y

Proporciona una lista completa de todos los documentos utilizados o referenciados en

Estructura del documento

Presenta una breve descripcin de como el documento ha sido organizado.

Arquitectura del sistema

Arquitectura lgica del sistema

Esta seccin presenta la estructura lgica global de la arquitectura del sistema, de

La capa de presentacin es la encargada de manejar la interfaz del usuario,

Para el Subsistema de Reservas de la cadena hotelera KMG, la arquitectura propuesta

El patrn de arquitectura elegido para el Subsistema de Reservas es el de niveles de

Arquitectura fsica del sistema

Continuando con el ejemplo del subsistema de Reservas, la arquitectura fsica es

Esta arquitectura fsica considera la distribucin de la aplicacin en cuatro tipos de nodos:

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

Diseo de los subsistemas

Diseo del Subsistema <nombre del subsistema >

Vista de Datos del subsistema <nombre del subsistema>

Realizaciones de Casos de Uso <nombre del subsistema>

Escenario del caso de uso: <nombre del caso de uso>