Está en la página 1de 39

Universidad de Los Andes Vicerrectorado Administrativo Direccin de Servicios de Informacin Administrativa Coordinacin de Desarrollo de Software Grupo de Diseo

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

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

Tabla de Contenido
Tabla de Contenido ............................................................................................................................................ 2 1. Introduccin .............................................................................................................................................. 3 2. Estructura del Documento de Diseo........................................................................................................ 3 3. Descripcin de las secciones del documento ............................................................................................ 4 3.1. Portada del documento .................................................................................................................... 5 3.2. Tabla de Contenido ......................................................................................................................... 5 3.3. Introduccin .................................................................................................................................... 5 3.3.1. Propsito del sistema ............................................................................................................. 5 3.3.2. Objetivos y restricciones de diseo........................................................................................ 7 3.3.3. Definiciones, acrnimos y abreviaturas ................................................................................. 8 3.3.4. Referencias ............................................................................................................................ 8 3.3.5. Estructura del documento ...................................................................................................... 8 3.4. Arquitectura del sistema .................................................................................................................. 8 3.4.1. Arquitectura lgica del sistema.............................................................................................. 8 3.4.2. Arquitectura fsica del sistema............................................................................................. 12 3.5. Diseo de los subsistemas ............................................................................................................. 14 3.5.1. Diseo del Subsistema <nombre del subsistema > .............................................................. 14 3.5.1.1. Vista de Uso del subsistema <nombre del subsistema> ................................................. 14 3.5.1.2. Vista de Datos del subsistema <nombre del subsistema> .............................................. 16 3.5.1.3. Realizaciones de Casos de Uso <nombre del subsistema> ............................................ 16 3.5.1.3.1. Realizacin del caso de uso: <nombre del caso de uso>................................................ 16 3.5.1.3.1.1. Escenario del caso de uso: <nombre del caso de uso> .............................................. 17 3.5.1.3.1.2. Diagrama de clases de diseo del caso de uso: <nombre del caso de uso> ............... 18 3.5.1.3.1.3. Diagrama de secuencia del caso de uso: <nombre del caso de uso> ......................... 19 3.5.1.3.1.4. Interfaz grfica de usuario del caso de uso: <nombre del caso de uso> .................... 21 3.5.1.3.1.5. Diagrama de navegacin del caso de uso: <nombre del caso de uso> ...................... 22 3.6. Diseo de la Base de Datos ........................................................................................................... 23 3.6.1. Esquema Conceptual de la Base de Datos ........................................................................... 23 3.6.2. Esquema Implementable de la Base de Datos...................................................................... 24 3.6.3. Diccionario de Datos ........................................................................................................... 25 3.7. Anexos........................................................................................................................................... 25 4. Fichas Tcnicas de Productos de Diseo ................................................................................................ 26 4.1. Ficha Tcnica para los Diagramas de Casos de Uso ..................................................................... 27 4.2. Ficha Tcnica para la Organizacin de Casos de Uso ................................................................... 30 4.3. Ficha Tcnica para los Escenarios de Casos de Uso ..................................................................... 34 4.4. Ficha Tcnica para los Diagramas de Secuencia ........................................................................... 37 5. Referencias Bibliogrficas ...................................................................................................................... 39

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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.

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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. 4

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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.

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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. de reservas tomadas, modificadas, canceladas y

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

3.3.2.

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

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes


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].

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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.

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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].

10

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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:

11

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes


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]:

12

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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.

13

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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.

Diseo 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 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]:

14

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

Otro ejemplo de la Vista de casos de uso para un sistema de Video Club, podra ser:

Gestin de Socios

Gestin de Pelculas

Gestin de Alquileres

15

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

3.5.1.2. 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.

16

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

3.5.1.3.1.1. 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.

17

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes


Caso de Uso Procesar Venta
Descripcin Actores
CU-01

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 Accin

1 2 3 4 5 6 7 8 9 10 11 12

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. El Sistema registra la venta completa, genera el recibo y actualiza el inventario. El Cajero entrega el recibo de compra y devuelve dinero al Cliente

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 Accin

3a

3-7a

8a

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.

3.5.1.3.1.2. 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. 18

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

3.5.1.3.1.3. 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.

19

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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].

20

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes


Caso de uso: Crear Registro Usuario

3.5.1.3.1.4. 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.

21

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

3.5.1.3.1.5. 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. 22

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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

23

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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 -IPAddress : String 0..* 1 Hotel -nombre : String -ciudad : String 1 1 1..* 0..1 * Habitacin -nombre : String

* 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 * * 1

0..* EstadoReserva Husped -nombre : String -documento : String -pais : String -Pendiente -En Curso -Finaliza -Cancelada -NoTomada

Clase enumerada

3.6.2.

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].

24

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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 25

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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.

26

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

4.1. Ficha Tcnica para los Diagramas de Casos de Uso


Universidad de Los Andes Vicerrectorado Administrativo 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 Fecha:28 /11 /2007 Metodologa: UML

Nombre del producto: Diagrama de Caso de uso Herramientas para construirlo: PowerDesigner 12, Powerdesigner12.5 Visual Architect 2.0, Visio

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 Significado
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 T esorera

Smbolo

Actor o Rol

Paquete de casos de uso

1 1 . Ca r g a r

CP- O

de

SAF

1 2 . Ca r g a r

f n i an c e i r as

d el D pt o

N m

13. A c t u az i l a r

r e c au dos

por

t i p o

d e

R ec e pc o i n s i t a

< <ex t en d>>

1 5. B us c ar

C P- O

1 4 . Va d i l ar

r ec audo s

<<ex t en d>>

1 6. B us c a r

f n i an c e i

< <ex t en d>>

1 7. I n gr e s ar

f n i anc e i r as

de

a l s

Caso de uso

27

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

Continuacin ficha tcnica: Diagramas de Casos de Uso


Relacin de comunicacin
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 Usado para establecer la 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. Usado para establecer la relacin es un entre actores o casos de uso, generales y especficos

Relacin include

caso de uso 1

<<include>> Caso de Uso 2

Relacin extend

caso de uso 1

<<extend>> Caso de Uso 2

Relacin de generalizacin

Utilizada entre actores:

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: Bibliografa consultada: Vistas de uso Modelado de sistemas usando UML 2.0

28

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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

29

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

4.2. Ficha Tcnica para la Organizacin de Casos de Uso


Universidad de Los Andes Vicerrectorado Administrativo DSIA rea de Ingeniera de Requisitos y Diseo de Software

FICHA TCNICA DEL PRODUCTO: ORGANIZACIN DE CASOS DE USO

Fase en la que se usa: Ingeniera de Requisitos y Diseo Detallado Fecha14/1 /2008 Metodologa: UML

Nombre del producto: Diagrama de Paquetes de Casos de Uso Herramientas para construirlo: PowerDesigner 12, Powerdesigner12.5 Visio

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:

Smbolos utilizados y su significado


Nombre del smbolo Significado
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

Smbolo

Actor o Rol

Paquete

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

30

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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. Bibliografa consultada: Alias utilizados para este producto: 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 1

<<subsistema>> Subsistema 2

<<subsistema>> Subsistema 3

31

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

Continuacin ficha tcnica: Organizacin de Casos de Uso


Formulacion Presupuesto

<<Subsistema>>

<<Subsistema>>

<<Subsistema>>

GestionarLineamientos

Formular Anteproyecto

Formular Proyecto

<<Subsistema>>

GestionarModificacionesPpto

RealizarEstadisticas

<<Subsistema>>

GestionarIngresoSistema

<<Subsistema>>

Administracin del Sistema

<<Subsistema>>

Si hay ms de 2 niveles dentro de los subsistemas, se pudiera presentar en forma de rbol:


Subsistemas Mdulos Casos de Uso

32

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

Continuacin ficha tcnica: Organizacin de 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>> 3. Tramitar pagos

Supervisor de Tesorera : 1

<<Gestin Cuentas Bancarias>> 1.2.1 Autorizacin de Transferencia de Fondos <<mdulo>> 4. Solicitar pagos

Revisor de documentacin

<<Gestin Cuentas Bancarias>> 1.3 Manejar movimientos

<<mdulo>> 5. Generar pagos <<Gestin Cuentas Bancarias>> 1.2.2.2 Cheques

<<mdulo>> 6. Controlar pagos <<Gestin Cuentas Bancarias>> 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 Estandarizado por: Grupo de Ingeniera de Requisitos y Diseo de Software

33

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

4.3. Ficha Tcnica para los Escenarios de Casos de Uso


Universidad de Los Andes Vicerrectorado Administrativo DSIA rea de Ingeniera de Requisitos y Diseo de Software FICHA TCNICA DEL PRODUCTO: ESCENARIOS DE CASOS DE USO Fase en la que se usa: Nombre del producto: Escenario de caso de uso (realizacin del caso de uso detallado) Herramientas para construirlo: PowerDesigner 12, PowerDesigner 12.5 Word, OpenOffice Notacin Numeracin de los pasos: nmeros ordinales: 1., 2., ..n. Frases empleadas:

Fecha: 28/11/2007 Versin 1.0

Metodologa: UML Versin: 2.0

Smbolos utilizados y su significado


Nombre de la seccin Flujo de eventos normal o especificacin del caso de uso 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.

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.

Flujo de eventos excepcionales o alternativos. Flujo alternativo o puntos de extensin. Puntos de excepcin.

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.

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

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

34

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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.

Alias utilizados para este producto:

Bibliografa consultada: 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
Code Association_4 Class Name Use Case Association

Name Association_4

35

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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 Estandarizado por: Grupo de Ingeniera de Requisitos y Diseo de Software

36

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

4.4. Ficha Tcnica para los Diagramas de Secuencia


Universidad de Los Andes Vicerrectorado Administrativo DSIA rea de Ingeniera de Requisitos y Diseo de Software FICHA TCNICA DEL PRODUCTO: Diagrama de Secuencia Diseo Arquitectnico Fecha:1 / 10 / 2007 Diseo Detallado Metodologa: UML Nombre del producto: Diagrama de secuencia detallado Herramientas para construirlo: PowerDesigner 12 Visual Architect 2.0

Versin: 2.0 Versin: 1.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.

Smbolos utilizados y su significado


Nombre del smbolo Actor Significado
Representa al actor que inicia los eventos del sistema recibe mensajes del sistema a travs de la clase controladora.

Smbolo

Lnea de vida

Lnea de vida asociada a un objeto. Representa la duracin de la vida del objeto dentro del diagrama de secuencia.

:clase 2

Ejecucin caja de activacin

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

37

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

Continuacin ficha tcnica: Diagramas de Secuencia


Uso de la interaccin
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. Establecen el tipo de comunicacin entre objetos del diagrama; existen varios tipos: 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. a)
ref SequenceDiagram_121()

Alternativas de interaccin

alt

[Condition]

[Condition]

Mensajes entre objetos

:clase 1 Actor mensaje "this" Mensaje indefinido Mensaje sncrono Mensaje asncrono Mensaje de retorno Creacin del objeto :clase 2

Destruccin del objeto

Elementos de un mensaje

objetoa:clase 1

objeto b:clase 2

m n:= 1 [Si x > 2]: z:= Calcular(x,y)

38

Direccin de Servicios de Informacin Administrativa Vicerrectorado Administrativo Universidad de Los Andes

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]

Alias utilizados para este producto: Vistas de uso

Bibliografa consultada: 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

5. 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] [4] Wei Lin. Software Design Specification Document, v: 1.2, 2Communicate, 2006. 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

39