Dirección de Servicios de Información Administrativa Vicerrectorado Administrativo Universidad de Los AndesPropuesta para el Documento de Diseño de Sistemas de la DSIA Versión 1.0 Grupo de Diseño de la DSIA William J. Montilva C. Lena Sánchez B. Luís E. Porras C. Marisol Díaz B. Marzo, 2008 1 Introducción Este informe presenta una propuesta de la estructura que podría llevar el documento de diseño del sistema (DDS) elaborado por el Grupo de Diseño adscrito a la Unidad de Desarrollo de la Dirección de Servicios de Información Administrativa (UD-DSIA) de la Universidad de Los Andes. El documento DDS será utilizado por el Grupo de Programación de la UD-DSIA como una guía para la codificación e implementación de los sistemas o aplicaciones que pudieran ser desarrollados para las unidades administrativas de esta institución universitaria. Entre los objetivos que persigue esta propuesta para la especificación del diseño de software tenemos: 1. Producir un documento técnico que describa todos los detalles del diseño de la arquitectura del sistema o aplicación y de todos los componentes que la conforman. 2. Proporcionar todos los detalles técnicos requeridos por el Grupo de Programación para programar o producir cada uno de los componentes de software de la aplicación o sistema. 3. Servir de insumo para la planificación y ejecución de las pruebas de unidad, integración y aceptación que realizará el Grupo de Pruebas al sistema. 4. Servir como material de guía o entrenamiento al nuevo personal que pueda ser incorporado a un proyecto, proporcionando la información necesaria de cómo una solución ha sido diseñada y como va a ser implementada. 5. Servir como un acuerdo entre el Grupo de Diseño, el Grupo de Programación y el Grupo de Pruebas, de cómo va a ser implementada y probada la funcionalidad descrita en la especificación de requisitos del sistema. Esta propuesta ha sido organizada de la siguiente manera. La estructura del DDS, en su primera versión, es presentada en la sección 2. La sección 3 describe cada uno de los puntos (secciones o apartados) que contiene el DDS. La sección 4 presenta algunas de las fichas técnicas creadas por el Grupo de Diseño de la DSIA, utilizadas para describir las notaciones empleadas para construir los diversos de diagramas de UML presentes en el documento DDS. 2 Estructura del Documento de Diseño Con la finalidad de producir un documento de diseño que cumpla con los objetivos antes mencionados, presentamos aquí una propuesta inicial de la estructura de dicho documento, el cual se muestra en la figura 1. Portada del documento Tabla de Contenido 1. Introducción 1.1. 1.2. 1.3. 1.4. 1.5. Propósito del sistema Objetivos y restricciones de diseño Definiciones, acrónimos y abreviaturas Referencias Estructura del documento 2. Arquitectura del Sistema 2.1. Arquitectura lógica (descomposición en subsistemas) 2.2. Arquitectura física (topología del sistema) 3. Diseño de los subsistemas 3.1. Diseño del subsistema <nombre del subsistema 1> 3.1.1. Vista de uso del subsistema 3.1.2. Vista de datos del subsistema 3.1.3. Realizaciones de Casos de Uso 3.1.3.1. Realización del caso de uso <nombre caso de uso 1> 3.1.3.1.1. Escenario del caso de uso 3.1.3.1.2. Diagrama de clase del caso de uso 3.1.3.1.3. Diagrama de secuencia detallado del caso de uso 3.1.3.1.4. Interfaz gráfica de usuario del caso de uso 3.1.3.1.5. Diagrama de navegación del caso de uso 3.1.3.2. Realización del caso de uso <nombre caso de uso 2> 3.2. Diseño del subsistema <nombre del subsistema 2> 4. Diseño de la Base de Datos 4.1. Esquema Conceptual 4.2. Esquema Implementable 4.3. Diccionario de Datos Anexos Figura 1. Estructura del Documento de Diseño del Sistema (DDS) 3 Descripción de las secciones del documento A continuación se describe con detalle el contenido de cada una de las secciones de la plantilla propuesta para el documento de diseño. 3. detalla las diferentes secciones y apartados del documento e indica la página en que cada una de ellas comienza. en los siguientes apartados. sus características más relevantes.0. Versión: es un número compuesto de dos dígitos que hace referencia a la versión del documento de diseño elaborado para este proyecto. 1. 3. Una lista con las principales definiciones de los términos. El primer dígito indica la versión del documento. puede ser incrementado cuando el grupo de diseño considere que han sido realizado cambios importantes que ameriten una nueva versión. podría incluirse un diagrama de contexto o general del sistema que muestre . En forma opcional. (1-2 párrafos) Presenta además. así como sus entradas y salidas más importantes.3.1 Portada del documento La portada del DDS contendrá los siguientes elementos: • • • Nombre del proyecto o sistema: señala el nombre del proyecto o sistema que va a ser desarrollado. su ámbito o contexto. Fecha: índica la fecha en la que se publica está versión del documento entregada formalmente. Identificador del proyecto: corresponde a un número interno que la organización le asigna a un determinado proyecto. Consiste en realizar una breve descripción del sistema. los procesos o funciones principales. una visión general del sistema o subsistema a desarrollar. Presenta una visión global y resumida del sistema. las decisiones y restricciones de diseño.2 diseño o el nombre del grupo de diseño. una lista de los documentos que sirven de referencia y por último. tomando como base lo escrito en el Documento de Especificación de Requisitos del sistema (DER) y específicamente donde se describe la aplicación. es por ello que éste número comienza en cero para una nueva versión y se incrementa en una unidad cada vez que se publique o entregue un nuevo documento con cambios. un resumen de la estructura o organización de este documento de diseño.3. Describe el propósito y alcance de este documento y a quien va dirigido.1 Propósito del sistema Esta sección proporciona el punto de entrada para entender el sistema y el ambiente en el cual este sistema operará. El segundo dígito señala que han ocurrido cambios en la versión de un documento. Autores: lista de las personas que participan en la elaboración del documento de • • 3. Tabla de Contenido La tabla de contenido del DDS.3 Introducción Esta sección del DDS proporciona al lector una apreciación global de lo que se tratará en este documento. acrónimos y abreviaturas. sin incluir detalles de implementación.3. Ejemplos: 1. etc. La toma de una reserva (check-in) por parte de un cliente y la asignación de una habitación al nuevo huésped. La modificación o cancelación de una reserva previamente registrada. (1-5 párrafos) Una gran mayoría de estos objetivos y restricciones lo determinan: .3. una vez que un cliente llegue al hotel para hacer su check-in o decida modificar o cancelar una reservación o se retire del hotel haciendo su respectivo check-out. además de los flujos de datos que entran y salen del mismo. El subsistema tendrá como entrada: • • La información personal de sus clientes Los datos de una reserva. Así mismo. Sugerencia de otros hoteles de la cadena cuando no existan habitaciones disponibles en el hotel que un cliente desea reservar. Este subsistema permitirá que todos los clientes de la empresa puedan realizar todas sus actividades por Internet y especialmente sus reservas. El cálculo de una comisión por penalización de aquellos clientes que no cancelaron a tiempo una reserva. Este subsistema deberá ser capaz de apoyar todos los procesos y actividades para la reserva de habitaciones. (1-5 párrafos) Un ejemplo de la redacción de esta sección se muestra a continuación. La confirmación de una reserva mediante una notificación al cliente bien sea por email. la cual será capturada a través de un formulario El subsistema deberá producir la siguiente información como salida: • • • • El mensaje de confirmación de una reserva La factura o recibo de consumo de un cliente La comisión por penalización de una reserva no cancelada Información estadística caducadas. limitaciones o restricciones que tienen un gran impacto en el diseño del sistema. La detección de reservas caducadas o reservas no tomadas.2 Objetivos y restricciones de diseño Describe los principales objetivos. los recepcionistas en cada uno de los hoteles operarán utilizando la misma interfaz de usuario. La notificación al sistema de facturación para que éste realice la apertura de una cuenta a fin de registrar los consumos realizados por sus huéspedes. cuyo propósito fundamental es mantener en forma centralizada y unificada todas las reservas que se realizan en todos sus hoteles afiliados. modificadas.” de reservas tomadas. canceladas y 3. La notificación al cliente para confirmar una reserva cuando se han realizado cambios en la misma. celular o beeper. fax.los componentes principales del sistema y los sistemas externos que interactúan con él. “El subsistema de Reservas es uno de los sistemas informáticos de la cadena hotelera KMG. entre ellos: • • • • • • • • • El registro de una reserva realizada por un cliente o el recepcionista del hotel. 3. en nuestro caso continuaremos con el subsistema de Reservas. el tiempo de respuesta para la realización de una reserva debe ser menor a 3 minutos cuando el cliente la realiza directamente por teléfono o en la recepción del hotel. características mínimas que deben poseer los computadores a ser instalados. El software que será utilizado para la construcción del sistema y el ambiente operativo donde éste será ejecutado. se desea reutilizar un sistema de facturación existente en la empresa. donde las reservas por Internet deben realizarse en menos de 5 segundos. . empleando el lenguaje de programación PHP para generar el contenido dinámico de las páginas web y de la programación de la lógica de la aplicación.3 Definiciones. Además. el tiempo de respuesta con las agencias de viajes para realizar una reserva debe ser de al menos 5 segundos. Este podría utilizar como navegador el Internet Explorer o algún navegador de software libre como el Mozilla Firefox. acrónimos y abreviaturas En este apartado se deben incluir todos los términos técnicos. Así mismo. acrónimos y abreviaturas que serán usadas en el documento. • • • • • A continuación se muestra un ejemplo de los objetivos y restricciones que se le imponen a un sistema. entre otros. el desarrollo de la interfaz gráfica se realizará en forma sencilla utilizando un editor HTML con manejo de Forms. seguridad. o bien. el sistema deberá permitir que las actividades para el registro. De igual manera. deben proveerse los mecanismos para que las agencias de viajes puedan operar con el sistema. cuando no exista disponibilidad de habitaciones en el hotel deseado. Los requisitos de desempeño. modificación. una vez llenado el formulario por parte del cliente. El sistema requerido deberá ejecutarse bajo la plataforma Microsoft Windows.” 3. a fin de poder utilizar los servicios que ofrece dicho sistema.• La infraestructura tecnológica que posea la organización donde será instalado este sistema. “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. check-in y check-out presentan altas exigencias de desempeño. Un ejemplo de estos términos técnicos utilizados podrían ser los casos de uso. El uso de estándares y normativas que deben ser tomadas en cuenta para el desarrollo del sistema. arquitectura del sistema. El sistema utilizará el protocolo estándar de comunicación HTTP a través del canal de comunicación TCP/IP. Por otra parte. Así mismo. La reutilización de componentes de software existentes en la organización. mediante el uso de Web Services. confiabilidad y calidad impuestos al sistema. Los requisitos de interfaz de usuario que se le impondrán al sistema. En este sentido. La empresa tiene como política no realizar reservas por encima de su disponibilidad (overbooking). características de la red que comunicará estos computadores y el protocolo usado. por ejemplo: manejador de base de datos a utilizar. Por otra parte. Debido a que los procesos de reserva. etc. eliminación y consulta de una reserva efectuada por un cliente o recepcionista pueda llevarse a cabo a través de la web. el sistema o recepcionista debería estar en capacidad de sugerir a los clientes otros hoteles de la cadena. tal como se muestra en la siguiente figura [1].5 Estructura del documento Presenta una breve descripción de como el documento ha sido organizado. Se debe incluir también. 3.3. Una breve descripción de la asignación de la funcionalidad de cada subsistema debe ser incluida. 3. Capa de Capa de Presentación Presentación Presentació Capa Lógica Capa Lógica Ló de Negocio de Negocio Capa de Capa de Datos Datos . Uno de los patrones arquitectónicos más usados en la actualidad para el desarrollo de aplicaciones de porte empresarial es el denominado “arquitectura de 3 o más capas”. así como el detalle de los servicios proporcionados por cada subsistema.1 Arquitectura lógica del sistema Esta sección presenta la estructura lógica global de la arquitectura del sistema.4.siglas definidas para ciertos productos del diseño como Diagramas de Secuencias Detallados (DSD). 3. la lógica del negocios (automatización del flujo trabajo) y la gestión de los datos (bases de datos). entre otros.4 Referencias Proporciona una lista completa de todos los documentos utilizados o referenciados en este documento. de acuerdo a un patrón arquitectónico elegido. La arquitectura del sistema se representa a través de un gráfico que muestra como la funcionalidad del sistema ha sido dividida en subsistemas o componentes. una descripción del estilo o patrón arquitectónico utilizado para dar forma a la arquitectura del sistema.3. los aspectos de presentación de la aplicación (interfaz de usuario). 3. Este estilo arquitectural separa lógicamente y en algunos casos físicamente.4 Arquitectura del sistema Describe la arquitectura del sistema tanto en su forma lógica como física. Se comunica únicamente con la capa de lógica de negocios. . Finalmente. La capa de lógica de negocios tiene la responsabilidad de manejar la funcionalidad del sistema. controlando la captura y presentación de los datos y recibiendo los eventos accionados por lo usuarios a través de la interfaz. Un ejemplo de la descripción y estructura de la arquitectura para un sistema de video juegos es mostrada a continuación [2]: “El sistema empleará el estilo arquitectónico de capas y será organizado en tres capas: la capa de interfaz. Esta capa se comunica con la capa de presentación para recibir solicitudes y presentar resultados y con la capa de datos. la capa de almacenamiento guardará los datos requeridos por el sistema. La capa de la aplicación contendrá la lógica y reglas para almacenar datos en la capa de la base de datos y también para recuperar éstos de acuerdo con las necesidades de las usuario.La capa de presentación es la encargada de manejar la interfaz del usuario. para solicitar al gestor de base de datos que almacene o recupere datos. La capa de interfaz contendrá la interfaz gráfica del usuario que le permitirá a los usuarios interactuar con el sistema. La capa de datos (llamada en algunos casos capa de persistencia) es la responsable del almacenamiento y recuperación de los datos. implementando a través de objetos de negocio (programas) las reglas de negocio que deben cumplirse. conteniendo el video player y todos sus menús. Esta capa se comunica únicamente con la capa de lógica de negocios. la capa de la aplicación y la capa de almacenamiento. Esta capa será implementada usando el Java Media Framework y el Java Swing Package. El estilo arquitectónico de tres-capas será usado porque no sólo separa la interfaz del usuario de los datos almacenados. Cada capa sugiere un tipo diferente de módulos o componentes e indica el rol que cada uno de ellos juega en esa capa. provee una capa de lógica de la aplicación. Esta separación lógica permite que una capa pueda ser modificada sin alterar el resto de las capas o introducir pequeños cambios en alguna de ellas. la complejidad inherente del procesamiento de sus datos y haga posible que éste sistema sea mucho más fácil de mantener y de reutilizar. Esta capa intermedia hace posible que este sistema esconda a sus usuarios. sino que también. Esta capa consiste de un módulo por caso de uso. la arquitectura propuesta para este sistema. sin que esto afecte la capa de interfaz. “El patrón de arquitectura elegido para el Subsistema de Reservas es el de niveles de abstracción o capas. la capa de la aplicación podría ser modificada si hay cualquier cambio en el formato de los archivos de datos y sus atributos. Por ejemplo. La capa de Interfaz de Usuario tiene como objetivo el manejo de la lógica del usuario. Los módulos identificados y sus interdependencias se presentan en el siguiente diagrama: . es presentada en la siguiente figura [3]. La capa de aplicación provee una capa intermedia que permite que los datos almacenados en la base de datos y los componentes GUI están débilmente acoplados. el cual agrupa la lógica realizada por el caso de uso y el conjunto de páginas web dinámicas utilizadas por dicha lógica.” Para el Subsistema de Reservas de la cadena hotelera KMG. creándose para ello. . una clase interfaz por caso de uso. donde cada módulo llevará a cabo todas las interfaces requeridas por los casos de uso vinculados a ese subsistema. Estos servicios son aún más básicos que el de la capa superior y pueden ser compartidos por otros subsistemas.La capa de Servicios del Sistema contiene los servicios básicos que debe proveer el sistema. La siguiente figura muestra los servicios básicos de esta capa. La capa de Servicios de Negocio agrupa los módulos que representan los servicios para el manejo de información del negocio. Se crea un módulo por subsistema. Cada módulo de esta capa ofrece una única interfaz con los servicios que permiten que las operaciones de la capa superior puedan ser realizadas. En esta capa se definen las clases controladoras encargadas de manejar la lógica de los casos de uso. estos servicios son directamente utilizados por los módulos de la capa superior. El siguiente diagrama muestra los módulos de esta capa. Los servicios de esta capa son mostrados a continuación. Un ejemplo de la arquitectura física del sistema de Video Juegos es mostrado a continuación [2]: .4." 3. como el de facturación y mensajería. En esta capa residen principalmente adaptadores de los servicios brindados por la plataforma. entre ellos el módulo de acceso a datos y la comunicación a otros sistemas. Para describir la asignación del software al hardware utilice los diagramas de despliegue y de componentes de UML.La capa de Infraestructura contiene todos los módulos necesarios para utilizar los servicios de la plataforma.2 Arquitectura física del sistema Esta sección describe la topología del sistema. mostrando como serán asignados en forma física los diferentes subsistemas o componentes (software) a los diferentes equipos de computación (hardware). El primer nodo representa a las estaciones de trabajo de los usuarios finales. LegacyServer. El nodo Server representa al equipo en donde correrá el servidor web y la aplicación del Subsistema de Reservas. etc. LegacyServer. la arquitectura física es representada con el siguiente diagrama [3]. Server. El último nodo. “Esta arquitectura física considera la distribución de la aplicación en cuatro tipos de nodos: Cliente. procesos. un diagrama de despliegue en UML. El nodo Recepción corresponde a la estación de trabajo ubicada en la recepción del hotel.” Se puede incluir adicionalmente bajo esta arquitectura.) son distribuidos sobre el hardware. Recepción.Continuando con el ejemplo del subsistema de Reservas. entre ellos el sistema de facturación. representa a aquella infraestructura informática necesaria para correr los sistemas legados. tal como se indica en la siguiente figura [1]. . que muestre como los componentes de software (servicios. 5 Diseño de los subsistemas Esta sección describe cada uno de los subsistemas que han sido determinados en la arquitectura lógica del sistema. Esta organización crea una jerarquía de diagramas de casos de uso. 3.1 Diseño 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. Cuando los casos de uso contenidos en estos diagramas son numerosos. mostrados mediante una vista de datos y la inclusión de una serie de elementos de modelado que describen como los casos de uso del sistema pueden ser realizados. se incluye una descripción de la funcionalidad del subsistema a través de una vista de casos de uso. analista y encargados de las pruebas.1 3. estos podrían ser agrupados de forma funcional utilizando los paquetes (carpetas) de UML. Para ello.3. Un ejemplo de la vista de casos de uso para el subsistema de Reservas es mostrado en la siguiente figura [3]: . no deberían pasar de tres niveles.1. Una descripción del modelo de datos que soporta. los cuales contienen los casos de uso más representativos de este subsistema.5. los cuales por razones de claridad.5. Para esta vista se utilizan los diagramas de casos de uso de UML. En estos diagramas se muestran conceptos (objetos). representa la porción del modelo conceptual de datos que será utilizada por este subsistema. Las clases de entidad se refieren a aquellas clases que van a guardar datos en forma persistente a través de un manejador de base de datos. En otras palabras. asociaciones entre conceptos (relaciones) y atributos de conceptos (atributos).Otro ejemplo de la Vista de casos de uso para un sistema de Video Club.1. podría ser: Gestión de Socios Gestión de Películas Gestión de Alquileres - - - 3.5.2 Vista de Datos del subsistema <nombre del subsistema> Esta vista muestra el subconjunto de clases de entidad que serán utilizadas por este subsistema. Un ejemplo de la vista de datos relacionada con el sistema de Reservas sería [3]: Subsistema de Reservas . Para la construcción de esta vista se utilizan los diagramas de clases de UML. es distribuido en función de los objetos o clases que colaboran entre si para realizar una operación.1. El escenario del caso de uso hacer reserva es mostrado a continuación [3]: .1. De manera opcional.1 Realización del caso de uso: <nombre del caso de uso> Para describir la realización de un caso de uso será necesario: una descripción textual de los pasos realizados en ese caso de uso (escenario).3 Realizaciones de Casos de Uso <nombre del subsistema> En esta sección se detalla como cada uno de los casos de uso que pertenecen a este subsistema van a ser realizados. incorporando detalles de la interfaz. vistas o formularios) involucrados en la realización del caso de uso y un diagrama de navegación a través de la interfaz de usuario. que mediante una descripción textual muestra el flujo de eventos que ocurre entre uno o más actores y el sistema. se puede mostrar los componentes de la interfaz gráfica de usuario (pantallas.3. sus atributos y nombres de las clases utilizadas en la realización del caso de uso. La realización de un caso de uso permite expresar como el comportamiento definido en un escenario. Escenario del caso de uso: <nombre del caso de uso> En este apartado se presenta el escenario del caso de uso. 3.5. un diagrama de las clases que participan en ese caso de uso y un diagrama de secuencia o de colaboración que muestra como la clases interactúan.5.3. El Cajero entrega el recibo de compra y devuelve dinero al Cliente El Cliente se marcha con los artículos comprados. Las clases de interfaz modelan la interacción entre el sistema y sus diferentes usuarios. interfaces y operaciones. navegabilidad y dependencias. Se registra la venta. de interfaz y de control. El Cajero registra la cantidad de efectivo recibida y el Sistema gestiona el pago. El Sistema elimina los datos de la venta actual.1.3 Asociados Precondición El Cajero se identifica y autentica Curso Normal (Básico) Paso Acción 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. son utilizadas para controlar el flujo de operaciones que debe realizar el sistema en respuesta a los eventos generados por un actor. Diagrama de clases de diseño del caso de uso: <nombre del caso de uso> Un diagrama de clases en UML es presentado aquí. El Cajero cancela la venta. 2. genera el recibo y actualiza el inventario. El Cajero le dice al Cliente el total de la venta. El sistema registra la línea de venta y presenta la descripción del producto. Este diagrama muestra la especificación de las clases software que intervienen en este caso de uso. El Sistema registra la venta completa. Las clases de control o activas. El Sistema resta el artículo de la compra y muestra la suma parcial. RF 2. El Cajero introduce el identificador del artículo para eliminarlo. El cliente le pide al Cajero que cancele la venta: 1. Se actualiza la Postcondición contabilidad y el inventario Cursos Alternos o Excepcionales Paso Acción 3a 3-7a 8a Introducción de un artículo inválido: 1. El Sistema calcula y presenta el monto total de la venta con sus impuestos. El sistema señala el error y rechaza la entrada. El Cajero inicia una nueva venta. denominadas así en el Proceso Unificado (RUP). En algunos casos. el cual contiene las clases software que manejaran la lógica del negocio y cuyos nombres son derivados . se construye básicamente un Modelo de Diseño de Objetos que corresponde a la capa del dominio o lógica de la aplicación. asociaciones. su importe y su respectivo impuesto. asociadas con la entrada de datos y salida de información. Si hay varios productos de un mismo tipo. 2. El cliente le pide al Cajero que elimine un artículo de la compra: 1. Caso de Uso Procesar Venta Descripción 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).Otro ejemplo de un escenario de caso de uso para un sistema de Punto de Venta se presenta en la siguiente figura. El Cliente efectúa un pago en efectivo. precio y suma parcial. para mostrar las clases de diseño de software que colaboran en la realización del caso de uso. El cajero registra el identificador de cada producto. métodos. presentando sus atributos. Cajero Tipo Primario Requisitos RF 1. Las clases de identidad representan a aquellos elementos del mundo real o conceptual a los que se les guardará información perdurable en el sistema. posiblemente con un monto mayor que el total de la venta. Los tipos de clases de diseño que son incluidas en estos diagramas son las clases de entidad. 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 Cajero puede introducir su cantidad. Pudiera ser un elemento opcional cuando la realización del caso de uso sea sencilla e involucre pocas clases o pocos métodos. para llevar a cabo la funcionalidad descrita por el escenario. así como la secuencia de mensajes intercambiados por estos. El siguiente ejemplo ilustra un diagrama de clases de diseño para un sistema de Punto de Venta. los de control con el estereotipo <<controlador>> y el resto de ellos. La siguiente figura muestra el diagrama de secuencia para el caso de uso procesar venta. . sin estereotipo. Un diagrama de secuencia se usa principalmente para mostrar en que orden interactúan los objetos o clases en la realización de un caso de uso. que hacen referencia a los objetos de entidad. Este diagrama usa estereotipos para indicar los tipos de objetos que interactúan. por ejemplo: los de interfaz con el estereotipo <<UI>>.de los conceptos del negocio. Diagrama de secuencia del caso de uso: <nombre del caso de uso> Un diagrama de secuencia de UML es colocado aquí para complementar la descripción textual (escenario) de un caso de uso. .Un ejemplo que hace uso de clases genéricas de software. de la lógica de la aplicación y del acceso a datos es mostrado en el siguiente diagrama de secuencia del caso de uso registrar usuario de un sistema de Reservaciones Aéreas [4]. creadas para el manejo de la interfaz. . formularios o vistas) involucrados en la realización de este caso de uso.Caso de uso: Crear Registro Usuario Interfaz gráfica de usuario del caso de uso: <nombre del caso de uso> En este apartado se mostrarán los diferentes componentes de la interfaz gráfica del usuario (pantallas. Adicionalmente se podría incluir aquí. Para el caso del subsistema de Reservas. ventanas. los componentes de la interfaz que permite ingresar los datos de una reserva son mostrados en las siguientes figuras. los formatos de impresión asociados a este caso de uso o en general al subsistema asociado. En este caso. La siguiente figura presenta un posible diagrama de navegación para el caso de uso hacer reserva. donde se muestran los diferentes componentes de la interfaz de usuario presentes en la realización de este caso de uso. se utilizaría un diagrama de estados de UML para mostrar dicha navegabilidad.Diagrama de navegación del caso de uso: <nombre del caso de uso> Esta sección es opcional y podría ser utilizada sólo cuando la realización del caso de uso tenga cierta navegación compleja que sea necesario describirla. . representado a través de uno o más diagramas de clases en UML o diagramas entidad-asociación. están lógica y físicamente organizados. Este esquema es el producto de la integración de los diferentes diagramas (de clases en UML o de . El primer nivel muestra el modelo conceptual de la base de datos. contiene los diseños de la base de datos que determinan como los datos que van a ser incluidos en la base de datos.6 Diseño de la Base de Datos Esta sección del DDS. 3. El segundo nivel presenta el modelo implementable de la base de datos. el diseño de la base de datos se establece en dos niveles de detalle. el cual es independiente del entorno tecnológico utilizado.1 Esquema Conceptual de la Base de Datos Este apartado presenta el esquema conceptual de datos del sistema. Para ello.3.6. descrito mediante un diagrama físico de la base datos que depende directamente del manejador de base de datos utilizado. donde se incluyen detalles de implementación física de acuerdo al manejador de base de datos a usar.. para representar el modelo conceptual de datos del subsistema de Reservas.1 * * Cliente -idCliente : Integer -nombre : String -usuario : String -password : String -email : String -tel : String -fax : String Reserva -idReserva : Integer -checkin -checkout -estado * 1 TipoHabitación -nombre : String * * 1 1 * 0. .6...2 Esquema Implementable de la Base de Datos Esta sección presenta el resultado de la conversión del esquema conceptual de la base de datos a un esquema implementable (en nuestro caso. En el caso de utilizar la herramienta de diseño PowerDesigner.. Recepción -IPAddress : String 0. Un diagrama de clases en UML es mostrado aquí.* EstadoReserva Huésped -nombre : String -documento : String -pais : String -Pendiente -En Curso -Finaliza -Cancelada -NoTomada Clase enumerada 3. El esquema implementable de la base de datos del sistema de Reservas. Los datos contenidos en este esquema son derivados directamente de los requisitos funcionales del sistema. Si se utiliza la herramienta de diseño PowerDesigner.entidad-asociación) de cada proceso de negocio o subsistema que haya sido establecido. el modelo relacional).* 1 Hotel -nombre : String -ciudad : String 1 1 1. los diagramas generados como Modelo Orientado a Objeto (Object-Oriented Model) o Modelo Conceptual de Datos (Conceptual Data Model) son incluidos en esta sección.* Habitación -nombre : String 0. 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]. éste genera un diagrama denominado Modelo Físico de Datos (Physical Data Model) que describe gráficamente la estructura de la base de datos y sus características físicas. Describiendo cada una de las tablas que la componen y sus campos asociados.3 Diccionario de Datos Este apartado es opcional. longitud y el posible dominio de valores que podría tomar. tipo de dato. el cual podría denominarse Modelo de Datos del Sistema o Diccionario de Datos del Sistema. sacarlo de este documento y crear un documento aparte con este contenido. cada campo es identificado por un nombre de dato. descripción. Si el contenido del diccionario de datos es muy grande se recomienda.6. Adicionalmente. Esta sección presenta un listado organizado de todas las estructuras de almacenamiento de la base de datos. 3.3.7 Anexos Esta sección incluirá toda la información adicional o de soporte al diseño del sistema. Los anexos podrían incluir: • • • • • Tabla de definición de usuarios (actores) Tabla de opciones del sistema (indicando el caso de uso asociado) Matriz usuario-opciones del sistema Tabla de descripción de reglas de negocio del sistema Tabla de casos de uso-reglas de negocio . 0. Registrar ingreso a Tesorería Símbolo Actor o Rol Paquete de casos de uso 1 1 .0 Definición del producto: Diagrama que permite especificar los requisitos funcionales de un sistema Utilidad para el cliente del proceso de diseño: Permite estructurar el sistema en funciones y definir los actores o roles que tendrán acceso a dichas funciones. Powerdesigner12. se anexan las fichas definidas por cada producto de diseño.O 1 4 . En algunos casos.1 Ficha Técnica para los Diagramas de Casos de Uso Universidad de Los Andes Vicerrectorado Administrativo DSIA – Área de Ingeniería de Requisitos y Diseño de Software FICHA TÉCNICA DEL PRODUCTO: DIAGRAMA DE CASOS DE USO Fase en la que se usa: Ingeniería de Requisitos y Diseño de Software Fecha:28 /11 /2007 Metodología: UML Nombre del producto: Diagrama de Caso de uso Herramientas para construirlo: PowerDesigner 12. o por fases del proceso organizacional a quien los casos de uso dan soporte. el cual puede ser: grupos de funciones. el actor es un sistema. Produce un resultado de valor para los actores 2. Bu s c a r O P f n a n c e i i <<e x t e n d >> 1 7 . Estas fichas describen las notaciones empleadas para construir los diversos de diagramas de UML presentes en este documento DDS. Va d a r i l r e c a u d o s << e x t e n d > > 1 6 .O P d e SAF 1 2 . I n g r e s a r O P f n a n c e r a s i i d e a s l Caso de uso . Tienen el propósito de servir como una referencia rápida al lector de este documento para entender la simbología utilizada en cada uno de estos diagramas.0 Versión: 2. Símbolos utilizados y su significado Nombre del símbolo Significado Es quien interactúa con el sistema. Ac t u a z a r i l r e c a u d o s p o r t i o p d e p Re c e p c o n s t a i i <<e x t e n d >> 1 5 . Bu s c a r CP . por usuarios. Visio Versión: 1.4 Fichas Técnicas de Productos de Diseño En esta sección se describen algunas de las fichas técnicas de productos usadas en el diseño de sistemas. A continuación. Nivel de detalle requerido para Diseño: a nivel de funciones que realizan alguna transacción que involucra un conjunto de datos. Es un conjunto de casos de uso agrupados según un cierto criterio. Ca r g a r CP . Función que el sistema pone a la disposición de los actores. Ca r g a r O P f n a n c e r a s i i d e l Dp t o N ó m 1 3 . Puede acceder a una o más funciones. 4.5 Visual Architect 2. Continuación ficha técnica: Diagramas de Casos de Uso Relación de comunicación Relación include Relación extend Relación de generalización Usado para establecer una asociación bidireccional entre un actor y un caso de uso Usado para establecer la relación entre 2 casos de uso. Diagramas de Procesos. Usado para establecer la relación “es un” entre actores o casos de uso. en el cual un caso de uso contiene o incluye al otro Usado para establecer la relación entre 2 casos de uso en la cual uno extiende el comportamiento del otro. Relaciones entre casos de uso: extend. Reglas del negocio que aplican para cada caso de uso. El caso de uso 2 se realiza si dentro del caso de uso 1 se da cierta condición. Diagramas de actividades. include y actores que participan en cada caso de uso. generales y específicos caso de uso 1 <<include>> Caso de Uso 2 caso de uso 1 <<extend>> Caso de Uso 2 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. Alias utilizados para este producto: Bibliografía consultada: Vistas de uso Modelado de sistemas usando UML 2. Elementos asociados a un caso de uso: Requisitos que resuelve.0 . Cargar OP financieras del Dpto Nómina 13. 1. Si hay más de un nivel en los paquetes de casos de uso.Validar recaudos <<extend>> 16. utilizando números ordinales.1. Los paquetes de casos de uso también deben tener números.Buscar CP-OP 14. etc. Los números deben tener 3 dígitos. Paleta de colores: B/N para todos los elementos del diagrama.Continuación ficha técnica: Diagramas de Casos de Uso Ejemplo de este producto: 11.Actualizar recaudos por tipo de pago Recepcionista <<extend>> 15.2. se puede usar jerarquía: 1.Cargar CP-OP de SAFEP 12.Buscar OP financiera <<extend>> 17.Ingresar OP financieras de las UAD Consideraciones especiales: la numeración de los casos de uso de todo el subsistema o sistema es estrictamente secuencial. Gris para casos de uso que son definidos en un diagrama o paquete y se utilizan en otro Estandarizado por: Grupo de Ingeniería de Requisitos y Diseño de Software . seguidos de un punto y el nombre del caso de uso. 0 Versión: 2. Controlar pagos . Usado para identificar el tipo de paquete. Powerdesigner12.2 Ficha Técnica para la Organización de Casos de Uso Universidad de Los Andes Vicerrectorado Administrativo DSIA – Área de Ingeniería de Requisitos y Diseño de Software FICHA TÉCNICA DEL PRODUCTO: ORGANIZACIÓN DE CASOS DE USO Fase en la que se usa: Ingeniería de Requisitos y Diseño Detallado Fecha14/1 /2008 Metodología: UML Nombre del producto: Diagrama de Paquetes de Casos de Uso Herramientas para construirlo: PowerDesigner 12. Solicitar pagos 6. Se muestran a partir del segundo nivel. Puede ser usado para agrupar funcionalmente los casos de usos de un sistema.0 Definición del producto: Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado. Utilidad para el cliente del proceso de diseño: Permite estructurar el sistema en subsistemas o módulos. el cual puede ser: 1. Nivel de detalle requerido para Diseño: Símbolos utilizados y su significado Nombre del símbolo Significado Es quien interactúa con el sistema. Es un conjunto de paquetes o de casos de uso agrupados según un cierto criterio. Se muestran a partir del segundo nivel. Puede acceder a uno o más paquetes. En algunos casos. << subsistema >> 4. 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. Cargar información Símbolo Actor o Rol Paquete Relación de comunicación Estereotipo Relación de dependencia Usado para establecer una asociación bidireccional entre un actor y un paquete.4. el actor es un sistema.5 Visio Versión: 1. 0. Diagramas de procesos. Inventario de Procesos. El Lenguaje Unificado de Modelado. Rumbaugh. Árbol de Procesos. Jacobson y Booch. Arquitectura de Software. Ejemplo de este producto: A nivel de sistema: Sistema de Emisión y Control de Pagos <<sistema>> <<subsistema>> Subsistema 1 <<subsistema>> Subsistema 2 <<subsistema>> Subsistema 3 .Continuación ficha técnica: Organización de Casos de Uso Insumos: Cadena de Valor de procesos. Diagrama de Jerarquía de procesos. Adrián Lasso. Diagramas de actividades. Diagrama de Referencia. Alias utilizados para este producto: Bibliografía consultada: Modelado de sistemas usando UML 2. se pudiera presentar en forma de árbol: Subsistemas Módulos Casos de Uso .Continuación ficha técnica: Organización de Casos de Uso Formulacion Presupuesto <<Subsistema>> <<Subsistema>> <<Subsistema>> GestionarLineamientos Formular Anteproyecto Formular Proyecto <<Subsistema>> GestionarModificacionesPpto RealizarEstadisticas <<Subsistema>> GestionarIngresoSistema <<Subsistema>> Administración del Sistema <<Subsistema>> Si hay más de 2 niveles dentro de los subsistemas. Máxima cantidad de niveles: 3 Criterios de buen empaquetamiento: alta cohesión y bajo acoplamiento entre paquetes. Solicitar pagos Revisor de documentación <<Gestión Cuentas Bancarias>> 1.5 Manejar Cuentas en Divisa Supervisor de Tesorería : 2 Revisor de instrumentos de pago <<módulo>> 7. Cargar información <<módulo>> 2.Continuación ficha técnica: Organización de Casos de Uso A nivel de un subsistema: Object-Oriented Model Model: Modelo de Casos de uso Package: Diagram: SUBSISTEMA GESTIÓN DE PAGOS Author: Nancy B.2. Controlar pagos <<Gestión Cuentas Bancarias>> 1. Tramitar pagos Supervisor de Tesorería : 1 <<Gestión Cuentas Bancarias>> 1.2 Cheques <<módulo>> 6. se deben mostrar las relaciones de dependencia y los actores.1 Autorización de Transferencia de Fondos <<módulo>> 4.Consultar pagos Gestor de Pagos : 2 Consideraciones especiales: Cuando haya más de 2 niveles se dibuja en forma de árbol. Generar pagos <<Gestión Cuentas Bancarias>> 1. de García Date: 14/01/2008 Version: 2 Recepcionista <<módulo>> 1.3 Manejar movimientos <<módulo>> 5.2.2. Registrar ingreso a Tesorería Controlador Financiero Gestor de Pagos : 1 <<módulo>> 3. Gris para casos de uso que son definidos en un diagrama o paquete y se utilizan en otro Estandarizado por: Grupo de Ingeniería de Requisitos y Diseño de Software . a nivel de un módulo. Paleta de colores: B/N para todos los elementos del diagrama. 1. Se utiliza para mostrar las diferentes opciones posibles de un conjunto donde todas tienen la misma posibilidad de ser seleccionadas por el usuario.El sistema activa el caso de uso “Imprimir orden”. se utiliza para manejar condiciones de validación. “El usuario < acción >” Ejemplo: “El usuario selecciona Guardar.El sistema muestra la información de la orden en pantalla.4. OpenOffice Notación Numeración de los pasos: números ordinales: 1. o lo que debe ocurrir antes que se ejecute este flujo .. Cuando haya más de una acción dentro de un flujo excepcional..Si el usuario selecciona “Imprimir”: 3b. Puntos de excepción.3 Ficha Técnica para los Escenarios de Casos de Uso Universidad de Los Andes Vicerrectorado Administrativo DSIA – Área de Ingeniería de Requisitos y Diseño de Software FICHA TÉCNICA DEL PRODUCTO: ESCENARIOS DE CASOS DE USO Fase en la que se usa: Nombre del producto: Escenario de caso de uso (realización del caso de uso detallado) Herramientas para construirlo: PowerDesigner 12.. el sistema muestra un mensaje de advertencia. Flujo excepcional: 2. se incorporan números...0 Símbolos utilizados y su significado Nombre de la sección Flujo de eventos normal o especificación del caso de uso Significado Conjunto de pasos escrito en lenguaje natural que muestra el flujo de eventos principal. PowerDesigner 12. Ejemplo: flujo normal: 2. etc. Flujo excepcional: Conjunto de pasos que describen las acciones que se deben realizar en caso de ocurrir alguna condición excepcional. diferente al flujo normal de eventos. Numeración de pasos de un flujo alternativo: Números ordinales seguidos de una letra.1.Si la orden no existe. Flujo alternativo o puntos de extensión. Frases empleadas: Fecha: 28/11/2007 Versión 1.El usuario selecciona una opción.. 2..0 Metodología: UML Versión: 2. Por lo general. a través de una secuencia de acciones que ocurren entre los actores y el sistema. “El sistema <acción>” Ejemplo: “El sistema guarda el número..2.2..5 Word. fecha de la orden en la Base de Datos”.Si el usuario selecciona “Guardar”: 3a. manejo de errores. . Numeración de pasos de un flujo alternativo: Ejemplo: flujo normal: 3. 3b.El sistema guarda los datos suministrados en la Base de Datos. Ejemplo: “El usuario Ingresó al sistema de Ordenes de Pago” Precondiciones o condiciones de entrada Describen la condición previa al conjunto de acciones del flujo feliz. Flujo alternativo: 3a. Flujo alternativo: Conjunto de pasos que describen el flujo de acciones al ocurrir una cierta condición. Flujo de eventos excepcionales o alternativos.a..n. el sistema finaliza el caso de uso. 6. Localidad. Representante Legal. 5. Post-condition of use case Se guardaron los datos de los Contratistas en la BD del sistema. 3. C. Extension of use case 2a. El sistema busca los datos digitalizados de los Contratistas: Nombre. 5. Cargar información de Contratistas 1. El sistema muestra mensaje de confirmación para iniciar la carga de información de los Contratistas 2. Cargar información de Contratistas 4_Cargar_informacion_de_Contratistas Package '1. Exceptions of use case 5a. Action steps of use case 1.I.Continuación ficha técnica: Escenarios de Casos de Uso Postcondiciones o condiciones de salida Describe el estado final obtenido después de ejecutarse el flujo normal de eventos. Para cada registro el sistema asigna un número de contratista y guarda la información. * El sistema almacenó los datos de la solicitud y actualizó el estado de la misma. Cargar información' 2. 6. 7. Card of use case Name Code Parent 4. Tlf. Pre-condition of use case Debe haberse recibido la información digitalizada de los Contratistas. del Representante. List of all dependencies of the use case Code Association_4 Class Name Use Case Association Name Association_4 . El sistema muestra mensaje de ingreso realizado y finaliza el caso de uso. colocando el cursor en el campo erróneo. Dirección. El usuario confirma que desea iniciar el proceso de carga.0 Ejemplos de este producto: Use Case: 4. 4. 4. 3. * El usuario registró los datos de la solicitud de autorización para la apertura de una cuenta bancaria. El sistema valida Nombre y RIF. El usuario selecciona no realizar el procso de carga. Actividad. RIF. Alias utilizados para este producto: Bibliografía consultada: Modelado de Sistemas usando UML 2. 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. los mismos deben considerar todos los datos que se registran. bien sea que se van a resolver dentro del mismo caso de uso o a través de un extend. 1. Sin embargo. con el detalle que se requiere en virtud que estos escenarios serán el insumo para el diseñador. se redacta en forma parecida a 2). Si el usuario selecciona <opcion c> se realiza el caso de uso Caso de uso C. Flujo alternativo: 1. 3) Cuando el escenario ofrezca varias opciones. se redacta así: Ejemplo: caso de uso con relación extend a través de las opciones <opción a> <opción b> y <opción c> Flujo feliz: 1. Si el usuario selecciona <opcion b> se realiza el caso de uso Caso de uso B. 2) Cuando el escenario ofrezca varias opciones.a. no deben involucrar aspectos de interfaz gráfica como por ejemplo: pulsar botones.Continuación ficha técnica: Escenarios de Casos de Uso Consideraciones especiales: 1) Los escenarios de Casos de Uso para Ingeniería de Requisitos. El usuario selecciona una opción. mientras que las opciones se consideran dentro de los flujos alternativos. sólo que la opción más frecuente y su flujo se consideran dentro del flujo feliz. Si el usuario selecciona <opcion a> se realiza el caso de uso Caso de uso A.c. 1. Tampoco deben involucrar nombres de clases ni de atributos de clases. Paleta de colores: Blanco y Negro Estandarizado por: Grupo de Ingeniería de Requisitos y Diseño de Software . de las cuales una de ellas es la que más se utiliza y existen otras opciones.b. las cuales tienen la misma posibilidad de ser elegidas y el caso de uso tenga una relación de extend con otros casos de uso. condiciones sobre los mensajes e iteraciones. insistiendo en la cronología del envío de mensajes.4.0 Versión: 1. También se necesita identificar la clase controladora que resolverá el evento del sistema. tomando en cuenta que por cada uno de éstos existen varios eventos del sistema o hilos de operación. Nivel de detalle requerido para Programación: Se puede obtener uno o más diagramas de secuencia detallados para un caso de uso. :clase 2 Ejecución ó caja de activación Indica la duración. El nivel de detalle debe incluir: métodos utilizados por clase. mostrando las interacciones entre los objetos desde el punto de vista temporal.0 Definición del producto: Diagrama que describe la dinámica de una aplicación o una parte de ella. Símbolos utilizados y su significado Nombre del símbolo Actor Significado Representa al actor que inicia los eventos del sistema ó recibe mensajes del sistema a través de la clase controladora. tipos de mensajes (síncronos. y debe estar previamente definida con todas sus operaciones. cuáles métodos se requieren de las instancias de las clases involucradas en la realización del caso de uso. Representa la duración de la vida del objeto dentro del diagrama de secuencia. valores de retorno. :clase 2 . y debidamente documentada.0 Versión: 2. Símbolo Línea de vida Línea de vida asociada a un objeto. 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. Utilidad para el cliente del proceso de diseño: Permite conocer en detalle para cada evento del sistema o hilo de operación. Facilita la programación orientada a objetos.4 Ficha Técnica para los Diagramas de Secuencia Universidad de Los Andes Vicerrectorado Administrativo DSIA – Área de Ingeniería de Requisitos y Diseño de Software FICHA TÉCNICA DEL PRODUCTO: Diagrama de Secuencia Diseño Arquitectónico Fecha:1 / 10 / 2007 Diseño Detallado Metodología: UML Nombre del producto: Diagrama de secuencia detallado Herramientas para construirlo: PowerDesigner 12 Visual Architect 2. atributos o parámetros que se pasan a través de los mensajes. asíncronos. de retorno). así como el ordenamiento de los mensajes entre los objetos. éstos se hacen explícitos.Continuación ficha técnica: Diagramas de Secuencia Indica una referencia que se hace de una interacción. e) Creación de objeto: indica el inicio de vida del objeto a quien se envía el mensaje. Las condiciones se separan por líneas punteadas. Establecen el tipo de comunicación entre objetos del diagrama. Valor de retorno o variable de retorno: es el valor que retorna el método invocado. d) Retorno: muestra el retorno a partir de una llamada de un objeto. sino que continúa su ejecución. la cual puede definirse como un pedazo del diagrama de secuencia que es utilizado en otra parte. existen varios tipos: Indefinido: puede ser un flujo síncrono o asíncrono b) Síncrono: el objeto que envía un mensaje espera una respuesta. f) Destrucción de objeto: indica la destrucción explícita del objeto o la finalización de su línea de vida. “Calcular” es un método del objeto b. c) Asíncrono: el objeto que manda el mensaje no espera la respuesta del otro objeto. Nota: para los mensajes indefinidos.y) . g) Mensaje “this”: es un mensaje que envía un objeto a sí mismo. Se utilizan para demarcar dentro del diagrama de secuencia. así como la referencia a otro diagrama de secuencia. Argumentos o parámetros: si el método requiere de argumentos para su ejecución. Método: el método indica la acción que realizará la clase que recibe dadas las condiciones y parámetros de la clase que envía. la sección de acciones dada una u otra condición. asíncronos o tipo “this” se puede incluir la caja de duración. a) Uso de la interacción ref SequenceDiagram_121() Alternativas de interacción alt [Condition] [Condition] Mensajes entre objetos :clase 1 Actor mensaje "this" Mensaje indefinido Mensaje síncrono Mensaje asíncrono Mensaje de retorno Creación del objeto :clase 2 Destrucción del objeto Elementos de un mensaje objetoa:clase 1 objeto b:clase 2 m n:= 1 [Si x > 2]: z:= Calcular(x. pueden mostrarse los valores que retorna. En el ejemplo. Algunos diseñadores excluyen este tipo de mensajes. bradapp. A Software Design Specification Template.DSIA Referencias Bibliográficas [1] Lasso. Craig Lraman Paleta de colores: B/N para todos los elementos del diagrama. y. y Rivero M. Diseño de Software. Software Design Specification Document.0 UML y Patrones. A. Reporte Técnico RT03-15. InCo Pedeciba. 2Communicate. A. se encierra en un recuadro las acciones y se coloca la iteración entre corchetes. UML y Patrones. Prentice Hall. Edición. [3] Wei Lin. Java e Internet. Estandarizado por: GDS. J.. 2007 [7] Larman. Méjico. y Vignaga. Ingeniería de Software Orientada a Objetos con UML.0. 2003 . 2da. D. SAD del Subsistema de Reservas del Sistema de Gestión Hotelera. 2003. Versión 1. CEISoft. Arquitectura de Software.m] Alias utilizados para este producto: Vistas de uso Bibliografía consultada: Modelado de sistemas usando UML 2. 2004.2. Para el caso que la iteración no se haga para un mensaje sino para una pieza del diagrama. http://www. B. v: 1.net [6] Montilva. http://www. z) *[n:= 1. 2006.y) IngresaDatos(x.Continuación ficha técnica: Diagramas de Secuencia Elementos de un mensaje Condición: Indica entre corchetes la condición bajo la cual se ejecuta el método invocado. A. objetoa:clase 1 objeto b:clase 2 objeto c:clase 3 [Si x > 2]: z:= Calcular(x. [5] Appleton. [4] Weitzenfeld.com/doc/210452/Arquitectura-deSoftware-Adrian-Lasso [2] Perovich.scribd. Uruguay. Iteración: Indica desde qué valor hasta qué valor se va a repetir la ejecución del método invocado. Montevideo. C.