propuesta documento de disenio de la dsia -...

Dirección de Servicios de Información Administrativa Vicerrectorado Administrativo

Universidad de Los Andes

Propuesta para el

Documento de Diseño de Sistemas

de la DSIA

Versión 1.0

Grupo de Diseño de la DSIA

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

Marzo, 2008

1 Introducción Este informe presenta una propuesta de la estructura que podría llevar el documento de diseño del sistema (DDS) elaborado por el Grupo de Diseño adscrito a la Unidad de Desarrollo de la Dirección de Servicios de Información Administrativa (UD-DSIA) de la Universidad de Los Andes.

El documento DDS será utilizado por el Grupo de Programación de la UD-DSIA como una guía para la codificación e implementación de los sistemas o aplicaciones que pudieran ser desarrollados para las unidades administrativas de esta institución universitaria.

Entre los objetivos que persigue esta propuesta para la especificación del diseño de software tenemos:

1. Producir un documento técnico que describa todos los detalles del diseño de la arquitectura del sistema o aplicación y de todos los componentes que la conforman.

2. Proporcionar todos los detalles técnicos requeridos por el Grupo de Programación para programar o producir cada uno de los componentes de software de la aplicación o sistema.

3. Servir de insumo para la planificación y ejecución de las pruebas de unidad, integración y aceptación que realizará el Grupo de Pruebas al sistema.

4. Servir como material de guía o entrenamiento al nuevo personal que pueda ser incorporado a un proyecto, proporcionando la información necesaria de cómo una solución ha sido diseñada y como va a ser implementada.

5. Servir como un acuerdo entre el Grupo de Diseño, el Grupo de Programación y el Grupo de Pruebas, de cómo va a ser implementada y probada la funcionalidad descrita en la especificación de requisitos del sistema.

Esta propuesta ha sido organizada de la siguiente manera. La estructura del DDS, en su primera versión, es presentada en la sección 2. La sección 3 describe cada uno de los puntos (secciones o apartados) que contiene el DDS. La sección 4 presenta algunas de las fichas técnicas creadas por el Grupo de Diseño de la DSIA, utilizadas para describir las notaciones empleadas para construir los diversos de diagramas de UML presentes en el documento DDS.

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

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.

Portada del documento Tabla de Contenido 1. Introducción

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

2. Arquitectura del Sistema

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

3. Diseño de los subsistemas

3.1. Diseño del subsistema <nombre del subsistema 1> 3.1.1. Vista de uso del subsistema 3.1.2. Vista de datos del subsistema 3.1.3. Realizaciones de Casos de Uso

3.1.3.1. Realización del caso de uso <nombre caso de uso 1> 3.1.3.1.1. Escenario del caso de uso

3.1.3.1.2. Diagrama de clase del caso de uso 3.1.3.1.3. Diagrama de secuencia detallado del caso de uso 3.1.3.1.4. Interfaz gráfica de usuario del caso de uso 3.1.3.1.5. Diagrama de navegación del caso de uso

3.1.3.2. Realización del caso de uso <nombre caso de uso 2> 3.2. Diseño del subsistema <nombre del subsistema 2>

4. Diseño de la Base de Datos 4.1. Esquema Conceptual 4.2. Esquema Implementable 4.3. Diccionario de Datos

Anexos

3.1 Portada del documento La portada del DDS contendrá los siguientes elementos:

• Nombre del proyecto o sistema: señala el nombre del proyecto o sistema que va a ser desarrollado.

• Identificador del proyecto: corresponde a un número interno que la organización le asigna a un determinado proyecto.

• Versión: es un número compuesto de dos dígitos que hace referencia a la versión del documento de diseño elaborado para este proyecto. El primer dígito indica la versión del documento, puede ser incrementado cuando el grupo de diseño considere que han sido realizado cambios importantes que ameriten una nueva versión. El segundo dígito señala que han ocurrido cambios en la versión de un documento, es por ello que éste número comienza en cero para una nueva versión y se incrementa en una unidad cada vez que se publique o entregue un nuevo documento con cambios. Ejemplos: 1.0, 1.3, etc.

• Autores: lista de las personas que participan en la elaboración del documento de diseño o el nombre del grupo de diseño.

• Fecha: índica la fecha en la que se publica está versión del documento entregada formalmente.

3.2 Tabla de Contenido La tabla de contenido del DDS, detalla las diferentes secciones y apartados del documento e indica la página en que cada una de ellas comienza.

3.3 Introducción Esta sección del DDS proporciona al lector una apreciación global de lo que se tratará en este documento. Describe el propósito y alcance de este documento y a quien va dirigido. (1-2 párrafos)

Presenta además, en los siguientes apartados, una visión general del sistema o subsistema a desarrollar, las decisiones y restricciones de diseño. Una lista con las principales definiciones de los términos, acrónimos y abreviaturas, una lista de los documentos que sirven de referencia y por último, un resumen de la estructura o organización de este documento de diseño. 3.3.1 Propósito del sistema

Esta sección proporciona el punto de entrada para entender el sistema y el ambiente en el cual este sistema operará. Presenta una visión global y resumida del sistema, tomando como base lo escrito en el Documento de Especificación de Requisitos del sistema (DER) y específicamente donde se describe la aplicación.

Consiste en realizar una breve descripción del sistema, su ámbito o contexto, sus características más relevantes, los procesos o funciones principales, así como sus entradas y salidas más importantes, sin incluir detalles de implementación. En forma opcional, podría incluirse un diagrama de contexto o general del sistema que muestre

los componentes principales del sistema y los sistemas externos que interactúan con él, además de los flujos de datos que entran y salen del mismo. (1-5 párrafos)

Un ejemplo de la redacción de esta sección se muestra a continuación. “El subsistema de Reservas es uno de los sistemas informáticos de la cadena hotelera KMG, cuyo propósito fundamental es mantener en forma centralizada y unificada todas las reservas que se realizan en todos sus hoteles afiliados. Este subsistema permitirá que todos los clientes de la empresa puedan realizar todas sus actividades por Internet y especialmente sus reservas. Así mismo, los recepcionistas en cada uno de los hoteles operarán utilizando la misma interfaz de usuario, una vez que un cliente llegue al hotel para hacer su check-in o decida modificar o cancelar una reservación o se retire del hotel haciendo su respectivo check-out.

Este subsistema deberá ser capaz de apoyar todos los procesos y actividades para la reserva de habitaciones, entre ellos:

• El registro de una reserva realizada por un cliente o el recepcionista del hotel.

• La toma de una reserva (check-in) por parte de un cliente y la asignación de una habitación al nuevo huésped.

• Sugerencia de otros hoteles de la cadena cuando no existan habitaciones disponibles en el hotel que un cliente desea reservar.

• La modificación o cancelación de una reserva previamente registrada.

• La notificación al cliente para confirmar una reserva cuando se han realizado cambios en la misma.

• La confirmación de una reserva mediante una notificación al cliente bien sea por e-mail, fax, celular o beeper.

• La detección de reservas caducadas o reservas no tomadas.

• El cálculo de una comisión por penalización de aquellos clientes que no cancelaron a tiempo una reserva.

• La notificación al sistema de facturación para que éste realice la apertura de una cuenta a fin de registrar los consumos realizados por sus huéspedes.

El subsistema tendrá como entrada:

• La información personal de sus clientes

• Los datos de una reserva, la cual será capturada a través de un formulario

El subsistema deberá producir la siguiente información como salida:

• El mensaje de confirmación de una reserva

• La factura o recibo de consumo de un cliente

• La comisión por penalización de una reserva no cancelada

• Información estadística de reservas tomadas, modificadas, canceladas y caducadas.”

3.3.2 Objetivos y restricciones de diseño

Describe los principales objetivos, limitaciones o restricciones que tienen un gran impacto en el diseño del sistema. (1-5 párrafos)

Una gran mayoría de estos objetivos y restricciones lo determinan:

• La infraestructura tecnológica que posea la organización donde será instalado este sistema, por ejemplo: manejador de base de datos a utilizar, características mínimas que deben poseer los computadores a ser instalados, características de la red que comunicará estos computadores y el protocolo usado, etc.

• El software que será utilizado para la construcción del sistema y el ambiente operativo donde éste será ejecutado.

• La reutilización de componentes de software existentes en la organización.

• Los requisitos de interfaz de usuario que se le impondrán al sistema.

• Los requisitos de desempeño, seguridad, confiabilidad y calidad impuestos al sistema.

• El uso de estándares y normativas que deben ser tomadas en cuenta para el desarrollo del sistema, entre otros.

A continuación se muestra un ejemplo de los objetivos y restricciones que se le imponen a un sistema, en nuestro caso continuaremos con el subsistema de Reservas. “La gerencia general de la cadena hotelera KMG desea mantener el control de todas las reservas que se hacen en los distintos hoteles afiliados a su cadena. La empresa tiene como política no realizar reservas por encima de su disponibilidad (overbooking). En este sentido, el sistema o recepcionista debería estar en capacidad de sugerir a los clientes otros hoteles de la cadena, cuando no exista disponibilidad de habitaciones en el hotel deseado.

Por otra parte, el sistema deberá permitir que las actividades para el registro, modificación, eliminación y consulta de una reserva efectuada por un cliente o recepcionista pueda llevarse a cabo a través de la web. Así mismo, deben proveerse los mecanismos para que las agencias de viajes puedan operar con el sistema, mediante el uso de Web Services.

Debido a que los procesos de reserva, check-in y check-out presentan altas exigencias de desempeño, donde las reservas por Internet deben realizarse en menos de 5 segundos, una vez llenado el formulario por parte del cliente. Así mismo, el tiempo de respuesta para la realización de una reserva debe ser menor a 3 minutos cuando el cliente la realiza directamente por teléfono o en la recepción del hotel. De igual manera, el tiempo de respuesta con las agencias de viajes para realizar una reserva debe ser de al menos 5 segundos.

Además, se desea reutilizar un sistema de facturación existente en la empresa, a fin de poder utilizar los servicios que ofrece dicho sistema.

El sistema requerido deberá ejecutarse bajo la plataforma Microsoft Windows. Este podría utilizar como navegador el Internet Explorer o algún navegador de software libre como el Mozilla Firefox. El sistema utilizará el protocolo estándar de comunicación HTTP a través del canal de comunicación TCP/IP. Por otra parte, el desarrollo de la interfaz gráfica se realizará en forma sencilla utilizando un editor HTML con manejo de Forms, empleando el lenguaje de programación PHP para generar el contenido dinámico de las páginas web y de la programación de la lógica de la aplicación.”

3.3.3 Definiciones, acrónimos y abreviaturas

En este apartado se deben incluir todos los términos técnicos, acrónimos y abreviaturas que serán usadas en el documento. Un ejemplo de estos términos técnicos utilizados podrían ser los casos de uso, arquitectura del sistema, o bien,

siglas definidas para ciertos productos del diseño como Diagramas de Secuencias Detallados (DSD), entre otros. 3.3.4 Referencias

Proporciona una lista completa de todos los documentos utilizados o referenciados en este documento. 3.3.5 Estructura del documento

Presenta una breve descripción de como el documento ha sido organizado.

3.4 Arquitectura del sistema Describe la arquitectura del sistema tanto en su forma lógica como física. 3.4.1 Arquitectura lógica del sistema

Esta sección presenta la estructura lógica global de la arquitectura del sistema, de acuerdo a un patrón arquitectónico elegido. La arquitectura del sistema se representa a través de un gráfico que muestra como la funcionalidad del sistema ha sido dividida en subsistemas o componentes.

Una breve descripción de la asignación de la funcionalidad de cada subsistema debe ser incluida, así como el detalle de los servicios proporcionados por cada subsistema. Se debe incluir también, una descripción del estilo o patrón arquitectónico utilizado para dar forma a la arquitectura del sistema.

Uno de los patrones arquitectónicos más usados en la actualidad para el desarrollo de aplicaciones de porte empresarial es el denominado “arquitectura de 3 o más capas”. Este estilo arquitectural separa lógicamente y en algunos casos físicamente, los aspectos de presentación de la aplicación (interfaz de usuario), la lógica del negocios (automatización del flujo trabajo) y la gestión de los datos (bases de datos), tal como se muestra en la siguiente figura [1].

Capa de Presentación

Capa de Capa de PresentaciPresentacióónn

Capa Lógica

de NegocioCapa LCapa Lóógica gica

de Negociode Negocio

Capa de Datos

Capa de Capa de DatosDatos

Capa de Presentación

Capa de Capa de PresentaciPresentacióónn

Capa Lógica

de NegocioCapa LCapa Lóógica gica

de Negociode Negocio

Capa de Datos

Capa de Capa de DatosDatos

La capa de presentación es la encargada de manejar la interfaz del usuario, controlando la captura y presentación de los datos y recibiendo los eventos accionados por lo usuarios a través de la interfaz. Esta capa se comunica únicamente con la capa de lógica de negocios.

La capa de lógica de negocios tiene la responsabilidad de manejar la funcionalidad del sistema, implementando a través de objetos de negocio (programas) las reglas de negocio que deben cumplirse. Esta capa se comunica con la capa de presentación para recibir solicitudes y presentar resultados y con la capa de datos, para solicitar al gestor de base de datos que almacene o recupere datos.

La capa de datos (llamada en algunos casos capa de persistencia) es la responsable del almacenamiento y recuperación de los datos. Se comunica únicamente con la capa de lógica de negocios.

Un ejemplo de la descripción y estructura de la arquitectura para un sistema de video juegos es mostrada a continuación [2]:

“El sistema empleará el estilo arquitectónico de capas y será organizado en tres capas: la capa de interfaz, la capa de la aplicación y la capa de almacenamiento.

La capa de interfaz contendrá la interfaz gráfica del usuario que le permitirá a los usuarios interactuar con el sistema. Esta capa será implementada usando el Java Media Framework y el Java Swing Package, conteniendo el video player y todos sus menús.

La capa de la aplicación contendrá la lógica y reglas para almacenar datos en la capa de la base de datos y también para recuperar éstos de acuerdo con las necesidades de las usuario.

Finalmente, la capa de almacenamiento guardará los datos requeridos por el sistema.

El estilo arquitectónico de tres-capas será usado porque no sólo separa la interfaz del usuario de los datos almacenados, sino que también, provee una capa de lógica de la aplicación. La capa de aplicación provee una capa intermedia que permite que los datos almacenados en la base de datos y los componentes GUI están débilmente acoplados. Esta separación lógica permite que una capa pueda ser modificada sin alterar el resto de las capas o introducir pequeños cambios en alguna de ellas. Por ejemplo, la capa de la aplicación podría ser modificada si hay cualquier cambio en el formato de los archivos de datos y sus atributos, sin que esto afecte la capa de interfaz. Esta capa intermedia hace posible que este sistema esconda a sus usuarios, la complejidad inherente del procesamiento de sus datos y haga posible que éste sistema sea mucho más fácil de mantener y de reutilizar.”

Para el Subsistema de Reservas de la cadena hotelera KMG, la arquitectura propuesta para este sistema, es presentada en la siguiente figura [3].

“El patrón de arquitectura elegido para el Subsistema de Reservas es el de niveles de abstracción o capas. Cada capa sugiere un tipo diferente de módulos o componentes e indica el rol que cada uno de ellos juega en esa capa.

La capa de Interfaz de Usuario tiene como objetivo el manejo de la lógica del usuario. Esta capa consiste de un módulo por caso de uso, el cual agrupa la lógica realizada por el caso de uso y el conjunto de páginas web dinámicas utilizadas por dicha lógica. Los módulos identificados y sus interdependencias se presentan en el siguiente diagrama:

La capa de Servicios del Sistema contiene los servicios básicos que debe proveer el sistema; estos servicios son directamente utilizados por los módulos de la capa superior. En esta capa se definen las clases controladoras encargadas de manejar la lógica de los casos de uso, creándose para ello, una clase interfaz por caso de uso. Se crea un módulo por subsistema, donde cada módulo llevará a cabo todas las interfaces requeridas por los casos de uso vinculados a ese subsistema. La siguiente figura muestra los servicios básicos de esta capa.

La capa de Servicios de Negocio agrupa los módulos que representan los servicios para el manejo de información del negocio. Estos servicios son aún más básicos que el de la capa superior y pueden ser compartidos por otros subsistemas. Cada módulo de esta capa ofrece una única interfaz con los servicios que permiten que las operaciones de la capa superior puedan ser realizadas. El siguiente diagrama muestra los módulos de esta capa.

La capa de Infraestructura contiene todos los módulos necesarios para utilizar los servicios de la plataforma. En esta capa residen principalmente adaptadores de los servicios brindados por la plataforma, entre ellos el módulo de acceso a datos y la comunicación a otros sistemas, como el de facturación y mensajería. Los servicios de esta capa son mostrados a continuación."

3.4.2 Arquitectura física del sistema

Esta sección describe la topología del sistema, mostrando como serán asignados en forma física los diferentes subsistemas o componentes (software) a los diferentes equipos de computación (hardware). Para describir la asignación del software al hardware utilice los diagramas de despliegue y de componentes de UML.

Un ejemplo de la arquitectura física del sistema de Video Juegos es mostrado a continuación [2]:

Continuando con el ejemplo del subsistema de Reservas, la arquitectura física es representada con el siguiente diagrama [3].

“Esta arquitectura física considera la distribución de la aplicación en cuatro tipos de nodos: Cliente, Recepción, Server, LegacyServer.

El primer nodo representa a las estaciones de trabajo de los usuarios finales. El nodo Recepción corresponde a la estación de trabajo ubicada en la recepción del hotel.

El nodo Server representa al equipo en donde correrá el servidor web y la aplicación del Subsistema de Reservas.

El último nodo, LegacyServer, representa a aquella infraestructura informática necesaria para correr los sistemas legados, entre ellos el sistema de facturación.”

Se puede incluir adicionalmente bajo esta arquitectura, un diagrama de despliegue en UML, que muestre como los componentes de software (servicios, procesos, etc.) son distribuidos sobre el hardware, tal como se indica en la siguiente figura [1].

3.5 Diseño de los subsistemas

Esta sección describe cada uno de los subsistemas que han sido determinados en la arquitectura lógica del sistema. Para ello, se incluye una descripción de la funcionalidad del subsistema a través de una vista de casos de uso. Una descripción del modelo de datos que soporta, mostrados mediante una vista de datos y la inclusión de una serie de elementos de modelado que describen como los casos de uso del sistema pueden ser realizados. 3.5.1 Diseño del Subsistema <nombre del subsistema > 3.5.1.1 Vista de Uso del subsistema <nombre del subsistema>

Esta vista muestra la funcionalidad del sistema como es percibida por los usuarios finales, analista y encargados de las pruebas.

Para esta vista se utilizan los diagramas de casos de uso de UML, los cuales contienen los casos de uso más representativos de este subsistema. Cuando los casos de uso contenidos en estos diagramas son numerosos, estos podrían ser agrupados de forma funcional utilizando los paquetes (carpetas) de UML. Esta organización crea una jerarquía de diagramas de casos de uso, los cuales por razones de claridad, no deberían pasar de tres niveles.

Un ejemplo de la vista de casos de uso para el subsistema de Reservas es mostrado en la siguiente figura [3]:

Otro ejemplo de la Vista de casos de uso para un sistema de Video Club, podría ser:

3.5.1.2 Vista de Datos del subsistema <nombre del subsistema>

Esta vista muestra el subconjunto de clases de entidad que serán utilizadas por este subsistema. Las clases de entidad se refieren a aquellas clases que van a guardar datos en forma persistente a través de un manejador de base de datos. En otras palabras, representa la porción del modelo conceptual de datos que será utilizada por este subsistema.

Para la construcción de esta vista se utilizan los diagramas de clases de UML. En estos diagramas se muestran conceptos (objetos), asociaciones entre conceptos (relaciones) y atributos de conceptos (atributos).

Un ejemplo de la vista de datos relacionada con el sistema de Reservas sería [3]: Subsistema de Reservas

-

Gestión de Socios

-

Gestión de Películas

-

Gestión de Alquileres

3.5.1.3 Realizaciones de Casos de Uso <nombre del subsistema>

En esta sección se detalla como cada uno de los casos de uso que pertenecen a este subsistema van a ser realizados. La realización de un caso de uso permite expresar como el comportamiento definido en un escenario, es distribuido en función de los objetos o clases que colaboran entre si para realizar una operación. 3.5.1.3.1 Realización del caso de uso: <nombre del caso de uso>

Para describir la realización de un caso de uso será necesario: una descripción textual de los pasos realizados en ese caso de uso (escenario), un diagrama de las clases que participan en ese caso de uso y un diagrama de secuencia o de colaboración que muestra como la clases interactúan. De manera opcional, se puede mostrar los componentes de la interfaz gráfica de usuario (pantallas, vistas o formularios) involucrados en la realización del caso de uso y un diagrama de navegación a través de la interfaz de usuario. Escenario del caso de uso: <nombre del caso de uso>

En este apartado se presenta el escenario del caso de uso, que mediante una descripción textual muestra el flujo de eventos que ocurre entre uno o más actores y el sistema, incorporando detalles de la interfaz, sus atributos y nombres de las clases utilizadas en la realización del caso de uso. El escenario del caso de uso hacer reserva es mostrado a continuación [3]:

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

Caso de Uso Procesar Venta CU-01

Descripción Este caso de uso de uso permite que un Cajero capture la venta de una serie de productos y registre su pago en efectivo

Actores Cliente (Iniciador), Cajero Tipo Primario Requisitos Asociados RF 1.1, RF 2.3

Precondición El Cajero se identifica y autentica Curso Normal (Básico)

Paso Acción

1 Este caso de uso comienza cuando un Cliente llega a la caja del Terminal de punto de venta (TPDV) con productos para comprar.

2 El Cajero inicia una nueva venta.

3 El cajero registra el identificador de cada producto. Si hay varios productos de un mismo tipo, el Cajero puede introducir su cantidad.

4 El sistema registra la línea de venta y presenta la descripción del producto, precio y suma parcial.

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

6 El Sistema calcula y presenta el monto total de la venta con sus impuestos. 7 El Cajero le dice al Cliente el total de la venta.

8 El Cliente efectúa un pago en efectivo, posiblemente con un monto mayor que el total de la venta.

9 El Cajero registra la cantidad de efectivo recibida y el Sistema gestiona el pago. 10 El Sistema registra la venta completa, genera el recibo y actualiza el inventario. 11 El Cajero entrega el recibo de compra y devuelve dinero al Cliente 12 El Cliente se marcha con los artículos comprados.

Postcondición Se registra la venta, su importe y su respectivo impuesto. Se actualiza la contabilidad y el inventario

Cursos Alternos o Excepcionales Paso Acción

3a Introducción de un artículo inválido: 1. El sistema señala el error y rechaza la entrada.

3-7a El cliente le pide al Cajero que elimine un artículo de la compra: 1. El Cajero introduce el identificador del artículo para eliminarlo. 2. El Sistema resta el artículo de la compra y muestra la suma parcial.

8a El cliente le pide al Cajero que cancele la venta: 1. El Cajero cancela la venta. 2. El Sistema elimina los datos de la venta actual.

Diagrama de clases de diseño del caso de uso: <nombre del caso de uso>

Un diagrama de clases en UML es presentado aquí, para mostrar las clases de diseño de software que colaboran en la realización del caso de uso. Este diagrama muestra la especificación de las clases software que intervienen en este caso de uso, presentando sus atributos, métodos, asociaciones, interfaces y operaciones, navegabilidad y dependencias.

Los tipos de clases de diseño que son incluidas en estos diagramas son las clases de entidad, de interfaz y de control, denominadas así en el Proceso Unificado (RUP). Las clases de identidad representan a aquellos elementos del mundo real o conceptual a los que se les guardará información perdurable en el sistema. Las clases de interfaz modelan la interacción entre el sistema y sus diferentes usuarios, asociadas con la entrada de datos y salida de información. Las clases de control o activas, son utilizadas para controlar el flujo de operaciones que debe realizar el sistema en respuesta a los eventos generados por un actor.

En algunos casos, se construye básicamente un Modelo de Diseño de Objetos que corresponde a la capa del dominio o lógica de la aplicación, el cual contiene las clases software que manejaran la lógica del negocio y cuyos nombres son derivados

de los conceptos del negocio. El siguiente ejemplo ilustra un diagrama de clases de diseño para un sistema de Punto de Venta.

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

Un diagrama de secuencia de UML es colocado aquí para complementar la descripción textual (escenario) de un caso de uso. Pudiera ser un elemento opcional cuando la realización del caso de uso sea sencilla e involucre pocas clases o pocos métodos.

Un diagrama de secuencia se usa principalmente para mostrar en que orden interactúan los objetos o clases en la realización de un caso de uso, así como la secuencia de mensajes intercambiados por estos, para llevar a cabo la funcionalidad descrita por el escenario.

La siguiente figura muestra el diagrama de secuencia para el caso de uso procesar venta. Este diagrama usa estereotipos para indicar los tipos de objetos que interactúan, por ejemplo: los de interfaz con el estereotipo <<UI>>, los de control con el estereotipo <<controlador>> y el resto de ellos, sin estereotipo, que hacen referencia a los objetos de entidad.

Un ejemplo que hace uso de clases genéricas de software, creadas para el manejo de la interfaz, de la lógica de la aplicación y del acceso a datos es mostrado en el siguiente diagrama de secuencia del caso de uso registrar usuario de un sistema de Reservaciones Aéreas [4].

Caso de uso: Crear Registro UsuarioCaso de uso: Crear Registro Usuario

Interfaz gráfica de usuario del caso de uso: <nombre del caso de uso>

En este apartado se mostrarán los diferentes componentes de la interfaz gráfica del usuario (pantallas, ventanas, formularios o vistas) involucrados en la realización de este caso de uso.

Adicionalmente se podría incluir aquí, los formatos de impresión asociados a este caso de uso o en general al subsistema asociado.

Para el caso del subsistema de Reservas, los componentes de la interfaz que permite ingresar los datos de una reserva son mostrados en las siguientes figuras.

Diagrama de navegación del caso de uso: <nombre del caso de uso>

Esta sección es opcional y podría ser utilizada sólo cuando la realización del caso de uso tenga cierta navegación compleja que sea necesario describirla. En este caso, se utilizaría un diagrama de estados de UML para mostrar dicha navegabilidad.

La siguiente figura presenta un posible diagrama de navegación para el caso de uso hacer reserva, donde se muestran los diferentes componentes de la interfaz de usuario presentes en la realización de este caso de uso.

3.6 Diseño de la Base de Datos Esta sección del DDS, contiene los diseños de la base de datos que determinan como los datos que van a ser incluidos en la base de datos, están lógica y físicamente organizados. Para ello, el diseño de la base de datos se establece en dos niveles de detalle.

El primer nivel muestra el modelo conceptual de la base de datos, representado a través de uno o más diagramas de clases en UML o diagramas entidad-asociación, el cual es independiente del entorno tecnológico utilizado. El segundo nivel presenta el modelo implementable de la base de datos, descrito mediante un diagrama físico de la base datos que depende directamente del manejador de base de datos utilizado. 3.6.1 Esquema Conceptual de la Base de Datos

Este apartado presenta el esquema conceptual de datos del sistema. Este esquema es el producto de la integración de los diferentes diagramas (de clases en UML o de

entidad-asociación) de cada proceso de negocio o subsistema que haya sido establecido. Los datos contenidos en este esquema son derivados directamente de los requisitos funcionales del sistema.

En el caso de utilizar la herramienta de diseño PowerDesigner, los diagramas generados como Modelo Orientado a Objeto (Object-Oriented Model) o Modelo Conceptual de Datos (Conceptual Data Model) son incluidos en esta sección.

Un diagrama de clases en UML es mostrado aquí, para representar el modelo conceptual de datos del subsistema de Reservas.

-idCliente : Integer-nombre : String-usuario : String-password : String-email : String-tel : String-fax : String

Cliente

-idReserva : Integer-checkin-checkout-estado

Reserva

-nombre : String-documento : String-pais : String

Huésped

-nombre : String-ciudad : String

Hotel

-nombre : StringTipoHabitación

-Pendiente-En Curso-Finaliza-Cancelada-NoTomada

EstadoReserva

-nombre : StringHabitación

Clase enumerada

1 1..*

*

0..1

* 1

1

*1

*

1 *

*

0..*

-IPAddress : StringRecepción 10..*

3.6.2 Esquema Implementable de la Base de Datos

Esta sección presenta el resultado de la conversión del esquema conceptual de la base de datos a un esquema implementable (en nuestro caso, el modelo relacional), donde se incluyen detalles de implementación física de acuerdo al manejador de base de datos a usar.

Si se utiliza la herramienta de diseño PowerDesigner, éste genera un diagrama denominado Modelo Físico de Datos (Physical Data Model) que describe gráficamente la estructura de la base de datos y sus características físicas.

El esquema implementable de la base de datos del sistema de Reservas, el cual utiliza el modelo relacional y que será ejecutado sobre el gestor de base de datos Microsoft Access es mostrado en la siguiente figura [3].

3.6.3 Diccionario de Datos

Este apartado es opcional. Si el contenido del diccionario de datos es muy grande se recomienda, sacarlo de este documento y crear un documento aparte con este contenido, el cual podría denominarse Modelo de Datos del Sistema o Diccionario de Datos del Sistema.

Esta sección presenta un listado organizado de todas las estructuras de almacenamiento de la base de datos. Describiendo cada una de las tablas que la componen y sus campos asociados. Adicionalmente, cada campo es identificado por un nombre de dato, descripción, tipo de dato, longitud y el posible dominio de valores que podría tomar.

3.7 Anexos Esta sección incluirá toda la información adicional o de soporte al diseño del sistema. Los anexos podrían incluir:

• Tabla de definición de usuarios (actores)

• Tabla de opciones del sistema (indicando el caso de uso asociado)

• Matriz usuario-opciones del sistema

• Tabla de descripción de reglas de negocio del sistema

• Tabla de casos de uso-reglas de negocio

4 Fichas Técnicas de Productos de Diseño En esta sección se describen algunas de las fichas técnicas de productos usadas en el diseño de sistemas. Estas fichas describen las notaciones empleadas para construir los diversos de diagramas de UML presentes en este documento DDS.

Tienen el propósito de servir como una referencia rápida al lector de este documento para entender la simbología utilizada en cada uno de estos diagramas. A continuación, se anexan las fichas definidas por cada producto de diseño.

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

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

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

Fase en la que se usa: Ingeniería de Requisitos y Diseño de Software

Nombre del producto: Diagrama de Caso de uso

Fecha:28 /11 /2007 Versión: 1.0

Metodología: UML Versión: 2.0

Herramientas para construirlo: PowerDesigner 12, Powerdesigner12.5 Visual Architect 2.0, Visio

Definición del producto: Diagrama que permite especificar los requisitos funcionales de un sistema Utilidad para el cliente del proceso de diseño: Permite estructurar el sistema en funciones y definir los actores o roles que tendrán acceso a dichas funciones. Nivel de detalle requerido para Diseño: a nivel de funciones que realizan alguna transacción que involucra un conjunto de datos.

Símbolos utilizados y su significado Nombre del símbolo Significado Símbolo

Actor o Rol

Es quien interactúa con el sistema. Puede acceder a una o más funciones. En algunos casos, el actor es un sistema.

Paquete de casos de uso Es un conjunto de casos de

uso agrupados según 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.

< < e x t e n d > >

< < e x t e n d > >

< < e x t e n d > >

R e c e p c io n is t a

1 1 . C a r g a r C P - O P d e S A F

1 2 . C a r g a r O P f in a n c ie r a s d e l D p t o N ó m

1 7 . I n g r e s a r O P f in a n c ie r a s d e la s

1 4 . V a lid a r r e c a u d o s

1 5 . B u s c a r C P - O

1 6 . B u s c a r O P f in a n c ie

1 3 . A c t u a liz a r r e c a u d o s p o r t ip o d e p

2. Registrar ingreso a Tesorería

Caso de uso

Función que el sistema pone a la disposición de los actores. Produce un resultado de valor para los actores

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

Relación de comunicación Usado para establecer una

asociación bidireccional entre un actor y un caso de uso

Relación include

Usado para establecer la relación entre 2 casos de uso, en el cual un caso de uso contiene o incluye al otro

<<include>>

caso de uso 1 Caso de Uso 2

Relación extend Usado para establecer la relación 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 condición.

<<extend>>

caso de uso 1 Caso de Uso 2

Relación de generalización Usado para establecer la relación “es un” entre actores o casos de uso, generales y específicos

Utilizada entre actores:

usuario autorizado

usuario 1 usuario 2 Utilizada en casos de uso

Imprimir

Imprimir Reporte de Saldos Imprimir Reporte de disponibil idad

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: Vistas de uso

Bibliografía consultada: Modelado de sistemas usando UML 2.0

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

Ejemplo de este producto:

<<extend>>

<<extend>>

<<extend>>

Recepcionista

11.Cargar CP-OP de SAFEP

12.Cargar OP financieras del Dpto Nómina

17.Ingresar OP financieras de las UAD

14.Validar recaudos

15.Buscar CP-OP

16.Buscar OP financiera

13.Actualizar recaudos por tipo de pago

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

4.2 Ficha Técnica para la Organización de Casos de Uso


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

Nombre del producto: Diagrama de Paquetes de Casos de Uso

Fecha14/1 /2008 Versión: 1.0


Herramientas para construirlo: PowerDesigner 12, Powerdesigner12.5 Visio

Definición del producto: Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado. Puede ser usado para agrupar funcionalmente los casos de usos de un sistema. Utilidad para el cliente del proceso de diseño: Permite estructurar el sistema en subsistemas o módulos. Nivel de detalle requerido para Diseño:


Actor o Rol

Es quien interactúa con el sistema. Puede acceder a uno o más paquetes. En algunos casos, el actor es un sistema.

Paquete Es un conjunto de paquetes

o de casos de uso agrupados según un cierto criterio, el cual puede ser:

1. Cargar información

Relación de comunicación Usado para establecer una

asociación bidireccional entre un actor y un paquete. Se muestran a partir del segundo nivel.

Estereotipo Usado para identificar el tipo de paquete, si se trata de

<< subsistema >>

Relación de dependencia

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.

6. Controlar pagos

4. Solicitar pagos

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

Insumos: Cadena de Valor de procesos, Diagramas de procesos, Diagrama de Jerarquía de procesos, Diagramas de actividades. Inventario de Procesos, Árbol de Procesos. Alias utilizados para este producto:

Bibliografía consultada: Modelado de sistemas usando UML 2.0. El Lenguaje Unificado de Modelado. Diagrama de Referencia, Rumbaugh, Jacobson y Booch. Arquitectura de Software, Adrián Lasso.

Ejemplo de este producto: A nivel de sistema:

Sistema de Emisión y Control de Pagos

<<sistema>>

<<subsistema>>

Subsistema 1<<subsistema>>

Subsistema 2

<<subsistema>>Subsistema 3


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

Formulacion Presupuesto

Formular Anteproyecto Formular Proyecto

GestionarIngresoSistema

GestionarModificacionesPpto

GestionarLineamientos

RealizarEstadisticas

Administración del Sistema

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

<<Subsistema>> <<Subsistema>>

<<Subsistema>> <<Subsistema>>

Subsistemas Módulos Casos de Uso


A nivel de un subsistema:

Object-Oriented ModelModel: Modelo de Casos de usoPackage: Diagram: SUBSISTEMA GESTIÓN DE PAGOSAuthor: Nancy B. de García Date: 14/01/2008 Version: 2

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

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

<<módulo>>

3. Tramitar pagos

<<módulo>>5. Generar pagos

<<módulo>>

6. Controlar pagos

<<módulo>>4. Solicitar pagos

Gestor de Pagos : 1

Recepcionista

Controlador Financiero

Revisor de documentación

Supervisor de Tesorería : 1

Revisor de instrumentos de pago <<módulo>>7.Consultar pagos

<<Gestión Cuentas Bancarias>>

1.2.2.2 Cheques

<<Gestión Cuentas Bancarias>>

1.2.1 Autorización de Transferencia de Fondos

<<Gestión Cuentas Bancarias>>1.5 Manejar Cuentas en Divisa

Supervisor de Tesorería : 2

Gestor de Pagos : 2

<<Gestión Cuentas Bancarias>>1.3 Manejar movimientos

Consideraciones especiales: Cuando haya más de 2 niveles se dibuja en forma de árbol; a nivel de un módulo, se deben mostrar las relaciones de dependencia y los actores. Máxima cantidad de niveles: 3 Criterios de buen empaquetamiento: alta cohesión y bajo acoplamiento entre paquetes. Paleta de colores: B/N para todos los elementos del diagrama. Gris para casos de uso que son definidos en un diagrama o paquete y se utilizan en otro Estandarizado por: Grupo de Ingeniería de Requisitos y Diseño de Software

4.3 Ficha Técnica para los Escenarios de Casos de Uso


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

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

caso de uso (realización del caso de uso detallado)

Fecha: 28/11/2007 Versión 1.0


Herramientas para construirlo: PowerDesigner 12, PowerDesigner 12.5 Word, OpenOffice

Símbolos utilizados y su significado Nombre de la

sección Significado Notación

Flujo de eventos normal o especificación del caso de uso

Conjunto de pasos escrito en lenguaje natural que muestra el flujo de eventos principal, a través de una secuencia de acciones que ocurren entre los actores y el sistema.

Numeración de los pasos: números ordinales: 1., 2., ..n. Frases empleadas: “El usuario < acción >” Ejemplo: “El usuario selecciona Guardar. “El sistema <acción>” Ejemplo: “El sistema guarda el número, fecha de la orden en la Base de Datos”.

Flujo de eventos excepcionales o alternativos. Flujo alternativo o puntos de extensión. Puntos de excepción.

Flujo alternativo: Conjunto de pasos que describen el flujo de acciones al ocurrir una cierta condición. 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 condición excepcional, diferente al flujo normal de eventos. Por lo general, se utiliza para manejar condiciones de validación, manejo de errores, etc.

Numeración de pasos de un flujo alternativo: Números ordinales seguidos de una letra. Cuando haya más de una acción dentro de un flujo excepcional, se incorporan números. Ejemplo: flujo normal: 2.- El sistema muestra la información de la orden en pantalla. Flujo excepcional: 2.a.- Si la orden no existe, el sistema muestra un mensaje de advertencia. Numeración de pasos de un flujo alternativo: Ejemplo: flujo normal: 3.- El usuario selecciona una opción. Flujo alternativo: 3a.1.- Si el usuario selecciona “Guardar”: 3a.2.- El sistema guarda los datos suministrados en la Base de Datos. 3b.1.- Si el usuario selecciona “Imprimir”: 3b.2.- El sistema activa el caso de uso “Imprimir orden”.

Precondiciones o condiciones de entrada

Describen la condición previa al conjunto de acciones del flujo feliz, o lo que debe ocurrir antes que se ejecute este flujo

Ejemplo: “El usuario Ingresó al sistema de Ordenes de Pago”

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.

* El usuario registró los datos de la solicitud de autorización 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:

Bibliografía consultada: Modelado de Sistemas usando UML 2.0

Ejemplos de este producto:

Use Case: 4. Cargar información de Contratistas

1. Card of use case

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

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

4. Extension of use case 2a. El usuario selecciona no realizar el procso de carga, el sistema finaliza el caso de uso.

5. Pre-condition of use case Debe haberse recibido la información digitalizada de los Contratistas.

6. Post-condition of use case Se guardaron los datos de los Contratistas en la BD del sistema.

7. List of all dependencies of the use case

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

Name Code Class Name Association_4 Association_4 Use Case Association

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

Consideraciones especiales:

1) Los escenarios de Casos de Uso para Ingeniería de Requisitos, no deben involucrar aspectos de interfaz gráfica como por ejemplo: pulsar botones. Tampoco deben involucrar nombres de clases ni de atributos de clases. Sin embargo, los mismos deben considerar todos los datos que se registran, con el detalle que se requiere en virtud que estos escenarios serán el insumo para el diseñador.

2) Cuando el escenario ofrezca varias opciones, las cuales tienen la misma posibilidad de ser elegidas y el caso de uso tenga una relación de extend con otros casos de uso, se redacta así:

Ejemplo: caso de uso con relación extend a través de las opciones <opción a> <opción b> y <opción c> Flujo feliz:

1. El usuario selecciona una opción. Flujo alternativo: 1.a. Si el usuario selecciona <opcion a> se realiza el caso de uso Caso de

uso A. 1.b. Si el usuario selecciona <opcion b> se realiza el caso de uso Caso de

uso B. 1.c. Si el usuario selecciona <opcion c> se realiza el caso de uso Caso de

uso C. 3) Cuando el escenario ofrezca varias opciones, de las cuales una de ellas es

la que más se utiliza y existen otras opciones, bien sea que se van a resolver dentro del mismo caso de uso o a través de un extend, se redacta en forma parecida a 2), sólo que la opción más frecuente y su flujo se consideran dentro del flujo feliz, mientras que las opciones se consideran dentro de los flujos alternativos.

Paleta de colores: Blanco y Negro Estandarizado por: Grupo de Ingeniería de Requisitos y Diseño de Software

4.4 Ficha Técnica para los Diagramas de Secuencia


FICHA TÉCNICA DEL PRODUCTO: Diagrama de Secuencia

Diseño Arquitectónico Diseño Detallado

Nombre del producto: Diagrama de secuencia detallado

Fecha:1 / 10 / 2007 Versión: 1.0


Herramientas para construirlo: PowerDesigner 12 Visual Architect 2.0

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


Actor

Representa al actor que inicia los eventos del sistema ó recibe mensajes del sistema a través de la clase controladora.

Línea de vida

Línea de vida asociada a un objeto. Representa la duración de la vida del objeto dentro del diagrama de secuencia.

:clase 2

Ejecución ó caja de activación

Indica la duración. 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

Continuación ficha técnica: Diagramas de Secuencia

Uso de la interacción Indica una referencia que se hace

de una interacción, 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.

ref

SequenceDiagram_121()

Alternativas de interacción Se utilizan para demarcar dentro del diagrama de secuencia, la sección de acciones dada una u otra condición. Las condiciones se separan por líneas punteadas.

[Condition]

[Condition]

alt

Mensajes entre objetos Establecen el tipo de comunicación entre objetos del diagrama; existen varios tipos:

a) Indefinido: puede ser un flujo síncrono o asíncrono

b) Síncrono: el objeto que envía un mensaje espera una respuesta.

c) Asíncrono: el objeto que manda el mensaje no espera la respuesta del otro objeto, sino que continúa su ejecución.

d) Retorno: muestra el retorno a partir de una llamada de un objeto; pueden mostrarse los valores que retorna. Algunos diseñadores excluyen este tipo de mensajes.

e) Creación de objeto: indica el inicio de vida del objeto a quien se envía el mensaje.

f) Destrucción de objeto: indica la destrucción explícita del objeto o la finalización de su línea de vida.

g) Mensaje “this”: es un mensaje que envía un objeto a sí mismo.

Nota: para los mensajes indefinidos, asíncronos o tipo “this” se puede incluir la caja de duración.

Mensaje indefinido

Mensaje síncrono

Mensaje asíncrono

Mensaje de retorno

mensaje "this"

Creación del objeto

Destrucción del objeto

:clase 1

Actor

:clase 2

Mensaje indefinido

Mensaje síncrono

Mensaje asíncrono

Mensaje de retorno

mensaje "this"

Creación del objeto

Destrucción del objeto

Elementos de un mensaje

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. En el ejemplo, “Calcular” es un método del objeto b. Argumentos o parámetros: si el método requiere de argumentos para su ejecución, éstos se hacen explícitos. Valor de retorno o variable de retorno: es el valor que retorna el método invocado.

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

m

objeto b:clase 2objetoa:clase 1

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

m

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. Iteración: Indica desde qué valor hasta qué valor se va a repetir la ejecución del método invocado. Para el caso que la iteración no se haga para un mensaje sino para una pieza del diagrama, se encierra en un recuadro las acciones y se coloca la iteración entre corchetes.

*[n:= 1..m]

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

IngresaDatos(x, y, z)

objeto b:clase 2objetoa:clase 1 objeto c:clase 3

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

IngresaDatos(x, y, z)

Alias utilizados para este producto: Vistas de uso

Bibliografía 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

Referencias Bibliográficas

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

Software-Adrian-Lasso

[2] Perovich, D. y Vignaga, A. SAD del Subsistema de Reservas del Sistema de Gestión Hotelera. Reporte Técnico RT03-15, InCo Pedeciba, Montevideo, Uruguay, 2003.

[3] Wei Lin. Software Design Specification Document, v: 1.2, 2Communicate, 2006.

[4] Weitzenfeld, A. Ingeniería de Software Orientada a Objetos con UML, Java e Internet. Méjico, 2004.

[5] Appleton, B. A Software Design Specification Template. http://www.bradapp.net

[6] Montilva, J. y Rivero M. Diseño de Software. Versión 1.0. CEISoft. 2007

[7] Larman, C. UML y Patrones. 2da. Edición. Prentice Hall. 2003

propuesta documento de disenio de la dsia -...

Documents