UNIVERSIDAD TCNICA FEDERICO SANTA MARA SEDE VIA DEL MAR JOS MIGUEL CARRERA

SISTEMA DE ADMINISTRACIN DE GIFTCARD

Trabajo de Taller de Aniisis y Diseo Alumnos: Alexis Barra Marcelo Corts Gonzalo Canales Profesor: Jos Luis Mart

2011

Historia de Revisin del Documento Fecha 11-08-2011 Versin 0.1 Modificacin Descripcin del Problema. Definicin de los Autor Equipo de Trabajo Equipo de Trabajo. Equipo de Trabajo. 31-08-2011 0.4 Correccin del diagrama caso de uso general y a la descripcin del caso de uso CU13 Cierre Terminal. 01-10-2011 0.5 Incorporacin diagramas de diseo. Equipo de Trabajo Equipo de Trabajo 02-10-2011 0.6 Correcciones a casos de uso y diagramas para mantener consistencia entre las diferentes representaciones. 30-10-2011 0.7 Cambios en el formato y estructura del documento. Correcciones a casos de uso, contratos y diagramas de acuerdo a las observaciones recibidas. 31-10-2011 0.8 Se profundiza en la definicin del problema y en el diseo arquitectnico. 01-11-2011 0.9 Se profundiza en la definicin del trabajo. Equipo de Trabajo Equipo de Trabajo Equipo de Trabajo Equipo de Trabajo

Requerimientos Funcionales. 29-08-2011 0.2 Revisin de requerimientos funcionales. Definicin de casos de uso. 31-08-2011 0.3 Descripcin general y actualizacin casos de uso.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

INDICE

1.

Definicin del Problema..........................................................................................................4 1.1. 1.2. 1.3. Descripcin General de la Organizacin. ................................................................................. 4 rea / Unidad del Problema. ........................................................................................................ 4 Problema Detectado......................................................................................................................... 5 Proceso a Desarrollar. ..................................................................................................................... 7 Personas................................................................................................................................................ 7 Producto a Desarrollar. .................................................................................................................. 8 Proyecto de Desarrollo de Software.......................................................................................... 8 Identificacin de Requisitos. ........................................................................................................ 9 Modelo de Casos de Uso. ............................................................................................................. 15 Modelo del Negocio. ...................................................................................................................... 18 Modelo del Dominio. ..................................................................................................................... 19 Modelo de Casos de Uso. ............................................................................................................. 20 Diagramas de Estados. ................................................................................................................. 35 Diseo Arquitectnico. ................................................................................................................ 37 Diseo de la Interfaz. .................................................................................................................... 39 Diseo de la Lgica. ....................................................................................................................... 42 Diseo de los Datos. ...................................................................................................................... 45

2.

Definicin del Trabajo. ............................................................................................................7 2.1. 2.2. 2.3. 2.4.

3.

Recoleccin y Anlisis de Requisitos. .................................................................................9 3.1. 3.2. 3.3.

4.

Anlisis Orientado al Objeto. .............................................................................................. 19 4.1. 4.2. 4.3.

5.

Diseo del Sistema. ................................................................................................................ 37 5.1. 5.2. 5.3. 5.4.

6. Conclusiones................................................................................................................................. 46

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

INTRODUCCIN El proyecto se desarrollar en la empresa ORSAN Red Comercio que es parte del conglomerado de empresas denominado grupo ORSAN, que ofrece servicios comerciales y financieros a las empresas nacionales. El rea afectada de la empresa ORSAN Red Comercio, es la Gerencia de Proyectos Corporativos, la que desea reutilizar el sistema de administracin de giftcard existente en la empresa. La situacin actual es que el sistema es administrado centralizadamente y no est en operacin. Se desea ofrecer un servicio que le permita a las empresas suscritas a l, administrar la emisin y carga de tarjetas giftcard en el sistema, y gestionar en que comercios podrn ser utilizadas. El sistema actual no cuenta con un mdulo de administracin de perfiles de usuario que permita definir los mdulos del sistema a los cuales tendr accesos un perfil, y tampoco cuenta con un mdulo de administracin de usuarios que permita definir los perfiles que podr utilizar un usuario. Adicionalmente, se detect que el sistema no cuenta con un mtodo de cifrado que permita almacenar las claves de los usuarios y de las tarjetas en forma segura. Para lograr el objetivo ser necesario revisar el cdigo fuente y documentar las funcionalidades del sistema, para luego incorporar los mdulos de administracin de usuarios y perfiles requeridos, e incorporar el cifrado de las claves de usuarios y tarjetas. El sistema est desarrollado en Microsoft Visual Studio 2005 WebForms, framework ASP.NET 3.5, ADO.NET, lenguaje de programacin C#, y Base de Datos SQL Server 2005, corriendo en Windows 2003 Server.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

1. DEFINICIN DEL PROBLEMA. 1.1. Descripcin General de la Organizacin.

El grupo Orsan es un conglomerado de empresas de servicios comerciales y financieros que participa activamente apoyando a las principales empresas nacionales en el desarrollo de sus negocios a travs de una variada oferta de Multiservicios Comerciales y Financieros. Por ms de dos dcadas ha entregado asesora integral a sus clientes convirtindose en un socio estratgico e innovador de ms de 1.500 empresas nacionales a lo largo de todo el pas. Las empresas que componen el conglomerado son: 1.2. Red Contact Less. Tarjetas de Aproximacin. Cheque Compra. Garantizacin de Cheques. Red Comercio. Terminales Transaccionales. Info Data. Generacin de Informes Comerciales. Cobranzas. Cobranzas Generales. Legal Services. Cobranzas Judiciales. Factoring. Factorizacin de Documentos. Recauda. Recaudacin de Valores Call Center. Multiservicios Va Telefnica. rea / Unidad del Problema.

ORSAN Red Comercio comenz a operar en Agosto de 2002, a travs de la instalacin de los primeros 50 terminales multifuncin-multipropsito en el comercio nacional. El proyecto consider ser un switch de transacciones, para facilitar la colocacin de crdito de las distintas casas comerciales con sus respectivos clientes, permitiendo de este modo el uso de tarjetas de crdito como instrumento de compra en distintos comercios y para pagar distintos servicios de consumo masivo como salud y transporte entre otros. Esta red de tecnologa permite, en el mismo terminal, la lectura, verificacin y garantizacin de cheques como medio de pago. Adems, incorpora un lector de huella digital que actualmente est en uso tanto en instituciones de salud como en otras que lo estn incorporando como norma de seguridad para sus usuarios. La unidad en que se presenta el problema es la Gerencia de Proyectos Corporativos, la que desea reutilizar software existente en la empresa para ofrecer un servicio de administracin de tarjetas giftcard a sus clientes.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

1.3.

Problema Detectado.

La situacin actual es que el sistema es administrado centralizadamente y no est en operacin. ORSAN Red Comercio desea ofrecer un servicio que le permita a las empresas suscritas a l, administrar la emisin y carga de tarjetas giftcard en el sistema, y gestionar en que comercios podrn ser utilizadas. El sistema actual no cuenta con un mdulo de administracin de perfiles de usuario que permita definir los mdulos del sistema a los cuales tendr accesos un perfil, y tampoco cuenta con un mdulo de administracin de usuarios que permita definir los perfiles que podr utilizar un usuario. Adicionalmente, se detect que el sistema no cuenta con un mtodo de cifrado que permita almacenar las claves de los usuarios y de las tarjetas en forma segura. El servicio pondr a disposicin de las empresas una plataforma tecnolgica para gestionar la emisin, venta y administracin de las tarjetas, la instalacin de terminales POS en las sucursales de los comercios en que sern utilizadas las tarjetas, un IVR y un switch para la autorizacin de las transacciones realizadas con las tarjetas, y un sitio Web corporativo a travs del cual los clientes podrn consultar el estado y las transacciones realizadas con sus tarjetas. 1.3.1. Objetivo. El objetivo principal del proyecto es documentar y realizar las modificaciones necesarias para contar con una plataforma nica que de soporte a todas las empresas suscritas al servicio, de modo tal que cada una de ellas pueda emitir y administrar sus tarjetas. Para alcanzar el objetivo principal es necesario que el sistema de cumplimiento a los siguientes objetivos secundarios: Incorporar la administracin de usuarios y perfiles. o o Permitir el registro de los mdulos existentes en el sistema. Permitir la creacin de perfiles de usuario para configurar a las opciones que tienen acceso a travs de los mdulos. o Permitir la creacin de usuarios y la asociacin de uno o ms perfiles. Almacenar las claves de los usuarios utilizando un algoritmo de cifrado. o Almacenar las claves (pines) de las tarjetas utilizando un algoritmo de cifrado. Mejorar la seguridad del sistema. o

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

1.3.2. Alcances del Proyecto. La operacin de una empresa comienza con la configuracin y activacin en el sistema de la empresa, el comercio, las sucursales y terminales asociados a cada sucursal del comercio por parte del administrador de ORSAN Red Comercio. Se asume que, una vez activada la empresa, el administrador de la empresa es responsable de la carga y administracin de las tarjetas en el sistema. El alcance del proyecto ser la estandarizacin de la informacin referente a las empresas, comercios, sucursales, usuarios, tarjetas y la autorizacin y registro de las transacciones de activacin, reversa y anulacin de activacin, consumo, reversa y anulacin de consumo y cierre de terminal provenientes de los POS instalados en las sucursales de los comercios. Los Stakeholders identificados en el sistema son: Gerente Proyectos Corporativos Jefes de proyectos Desarrolladores Analistas Clientes Sponsors

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

2. DEFINICIN DEL TRABAJO. 2.1. Proceso a Desarrollar.

[Diagrama de actividades y descripcin del proceso] 2.2. Personas.

Las personas que participarn en el desarrollo del proyecto son: Jefe de Proyecto del Sistema. Persona responsable de la planificacin y seguimiento del proyecto por parte de la empresa desarrolladora del producto. Deber coordinar reuniones con el cliente para obtener la informacin necesaria para el desarrollo del producto, estimar la duracin y costo de las actividades, controlar el avance del proyecto y dar solucin a los problemas que se pueden presentar durante la implementacin. Analista. Persona encargada del anlisis y diseo del producto, su documentacin y las adaptaciones que sea necesario realizar al diseo inicial para que el producto de respuesta a las necesidades del cliente. Programador. Persona encargada de implementar las funcionalidades del sistema y especificadas en el documento de diseo. Deber realizar las pruebas necesarias para certificar su correcto funcionamiento y generar los scripts y procedimientos de instalacin necesarios para la puesta en marcha del sistema. Jefe de Proyecto Orsan. Persona encargada de proporcionar la informacin necesaria para el desarrollo del producto, y de coordinar y controlar las actividades necesarias al interior de Orsan. Es la contraparte del Jefe de Proyecto del Sistema. Administrador de Base de Datos Orsan. Persona encargada de la administracin de las bases de datos en Orsan, responsable de la instalacin y administracin de la base de datos del Sistema de Administracin de Giftcard. QA Orsan. Persona responsable de la certificacin del correcto funcionamiento del producto de acuerdo a las funcionales requeridas por Orsan.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

2.3.

Producto a Desarrollar.

El producto a desarrollar es el Sistema de Administracin de Giftcard, el cual permitir a tener acceso a las distintas funcionalidades de acuerdo al perfil o rol que desempean. Administrador Orsan. Podr configurar las empresas emisoras de tarjetas y los usuarios y perfiles que tendr la empresa. Administrador Empresa. Podr administrar las tarjetas y los comercios y sucursales a travs de los cuales las comercializar. Cliente. Podr utilizar las tarjetas en las sucursales de los comercios configurados por la empresa emisora. 2.4. Proyecto de Desarrollo de Software.

[Carta Gantt del proyecto]

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

3. RECOLECCIN Y ANLISIS DE REQUISITOS. 3.1. Identificacin de Requisitos.

3.1.1. Requisitos Funcionales. A partir de los requerimientos de usuario se definieron los requerimientos funcionales del sistema, los que se detallan a continuacin. RF-01. Una empresa es la que emite las tarjetas GiftCard (rol emisor). El sistema registrar los siguientes datos de identificacin de una empresa: RF-02 El sistema registrar en un log histrico de auditora los cambios que se hagan en los datos de una empresa, el usuario que los realiz y la fecha y hora en que lo hizo. RF-03 Un comercio es en dnde se utilizan las tarjetas (rol adquirente). El sistema registrar los siguientes datos de un comercio: RF-04 El sistema registrar en un log histrico de auditora los cambios que se hagan en los datos de un comercio, el usuario que los realiz y la fecha y hora en que lo hizo. RUT. Razn social. Nombre de fantasa. Direccin. Fecha de creacin. Fecha de la ltima actualizacin. Estado. Cdigo de comercio. Usuario. RUT. Razn social. Nombre de fantasa. Direccin. Fecha de creacin. Fecha de la ltima actualizacin. Estado. Indicador de consumo variable. Indica si las tarjetas emitidas por la empresa permiten consumos parciales inferiores al monto de la tarjeta o no. Usuario.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

RF-05 El sistema registrar los siguientes datos de una sucursal perteneciente a un comercio: RF-06 El sistema registrar en un log histrico de auditora los cambios que se hagan en los datos de una sucursal, el usuario que los realiz y la fecha y hora en que lo hizo. RF-07 El sistema permitir administrar el estado de cada empresa, comercio y sucursal registrados en el sistema. Los estados posibles son: Creado. Estado inicial de una entidad al ser ingresada al sistema. Activo. Estado que indica que la entidad est en condiciones de procesar transacciones provenientes de los POS instalados en las sucursales de un comercio. RF-08 El sistema permitir que un usuario autenticado, perteneciente a una empresa, pueda realizar la carga masiva de las tarjetas que la empresa desea emitir a partir de un archivo Excel que deber contener los siguientes datos: Estado. El estado inicial de una tarjeta cargada es Inactiva. Nmero de tarjeta PAN de 16 dgitos, donde los 6 primeros corresponden al cdigo de la empresa, los dos siguientes son de contenido libre y los 8 ltimos corresponden al nmero de la tarjeta, cuya combinacin debe ser nica. Monto de la tarjeta sin puntos ni comas. Fecha inicio vigencia en formato AAAAMMDD. Fecha vencimiento vigencia AAAAMMDD. RUT empresa asociada sin puntos. DV empresa asociada. Nmero PIN de 6 dgitos. Inactivo. Estado que indica que la entidad no puede procesar transacciones provenientes de los POS instalados en las sucursales de un comercio. Cdigo sucursal. Direccin. Tipo fono autorizacin IVR. Cdigo rea fono autorizacin IVR. Nmero fono autorizacin IVR. Clave sucursal. Fecha de creacin. Fecha de la ltima actualizacin. Estado. Usuario.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

RF-09 El sistema permitir que un usuario autenticado, perteneciente a una empresa, pueda realizar la carga individual de una tarjeta. RF-10 El sistema registrar los siguientes datos al cargar una tarjeta: RF-11 El sistema permitir descartar una tarjeta cargada previamente que no haya sido utilizada previamente y que est en estado Inactiva, quedando en estado Descartada. RF-12 El sistema registrar al menos los siguientes datos de las transacciones que se realicen al utilizar una tarjeta: Nmero de transaccin Nmero de tarjeta PAN. Cdigo de sucursal. Cdigo de autorizacin retornado. Cdigo de transaccin. Cdigo de resultado de la transaccin. Glosa de retorno por rechazo. Cdigo de POS. Cdigo de cajero. Monto de la transaccin. Fecha de la transaccin. Origen de la transaccin. Los orgenes identificados son POS e IVR. RUT empresa Estado tarjeta. El estado inicial de una tarjeta es Inactiva. Nmero de tarjeta PAN. Monto tarjeta. Fecha inicio vigencia. Fecha vencimiento vigencia. Nmero PIN. Fecha de creacin. Fecha de la ltima actualizacin. Fecha de vencimiento anterior a la activacin de la tarjeta.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

RF-13 El sistema registrar los siguientes datos cada vez que una tarjeta cambie de estado producto de una transaccin: RF-14 El sistema tendr un mdulo de registro de los usuarios del sistema que contendr al menos los siguientes datos: RF-15 El sistema administrar perfiles de usuario en el acceso a los mdulos del sistema, los cuales son al menos los siguientes: RF-16 El sistema deber permitir configurar los mdulos a los que tiene acceso un perfil determinado. RF-17 El sistema permitir visualizar las tarjetas cargadas de acuerdo a los siguientes criterios de seleccin: Nmero de tarjeta. Fecha de creacin desde-hasta. Fecha de activacin desde-hasta. Fecha de consumo desde-hasta. Estado de la tarjeta. Cdigo empresa. Cdigo comercio. Cdigo sucursal. Administrador General Orsan. Tiene acceso a todas las empresas. Administrador Empresa. Tiene acceso a todos los mdulos, pero slo tiene acceso a los datos de la empresa propia. Usuario Clave Nombre completo Estado Nmero de tarjeta PAN. Cdigo de transaccin. Nmero de transaccin. Cdigo de autorizacin. Estado tarjeta previo. Estado tarjeta posterior. Fecha de la actualizacin.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

RF-18 El sistema permitir visualizar las transacciones realizadas, y los totales de activacin, consumo, devolucin de activacin y devolucin de consumo, de acuerdo a los siguientes criterios de seleccin: Fecha desde-hasta. Tipo de origen. Los orgenes identificados son: o o POS IVR. Activacin. Consumo. Devolucin de activacin. Devolucin de consumo. xito. Error.

Tipo de transaccin. Los tipos de transaccin identificados son: o o o o

Resultado de la transaccin. o o

RF-19

Cdigo de empresa. Cdigo de comercio. Cdigo de sucursal. Nmero de tarjeta.

El sistema tendr un mdulo de registro de los terminales asignados a cada una de las sucursales de cada comercio configurado que contendr al menos los siguientes datos: RF-20 El sistema permitir exportar las consultas realizadas a un archivo Excel. RF-21 El sistema proveer una interfaz para el mdulo de autorizacin que permita realizar la activacin de una tarjeta. RF-22 El sistema proveer una interfaz para el mdulo de autorizacin que permita realizar la anulacin de la activacin de una tarjeta. RF-23 El sistema proveer una interfaz para el mdulo de autorizacin que permita realizar el consumo realizado al utilizar una tarjeta. RF-24 El sistema proveer una interfaz para el mdulo de autorizacin que permita realizar la anulacin del consumo realizado al utilizar una tarjeta. Nmero de terminal Cdigo de comercio Cdigo de sucursal Cdigo de terminal Fecha de registro

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

RF-25 El sistema proveer una interfaz para el mdulo de autorizacin que permita realizar el cierre de un terminal. 3.1.2. Requisitos No Funcionales. A partir de los requerimientos de usuario se definieron los requerimientos no funcionales del sistema, los que se detallan a continuacin. RNF-01. El sistema operar en ambiente Web, tanto intranet como extranet. RNF-02. El sistema ser desarrollado en Microsoft Visual Studio 2010 utilizando el lenguaje de programacin C# y la base de datos Microsoft SQL Server 2005. RNF-03. El sistema deber ser desarrollado en ambiente Web, utilizando tecnologa ASP y validado en los navegadores IE8, IE9, Chrome12, FireFox 3.5 o superior. RNF-04. El sistema deber proveer una disponibilidad 7x24. En caso de cadas atribuibles al sistema, no deber pasar ms de 2 horas sin servicio. En los casos de no disponibilidad por razones ajenas al sistema, no son responsabilidad de este desarrollo. RNF-05. Se harn talleres de capacitacin a los empleados de Orsan que harn uso del sistema durante 2 das, considerando 3 horas en cada jornada. RNF-06. Los mdulos del sistema, con los que se configuran los perfiles de usuario, estarn pre-cargados en el sistema con al menos los siguientes datos: Cdigo. Descripcin.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

3.2.

Modelo de Casos de Uso.

3.2.1. Actores del Sistema. En la etapa de anlisis se identificaron los actores del sistema, que corresponden a las entidades externas que interactan con el sistema, los cuales se tipifican a continuacin. Switch Autorizador. Actor que recibe las transacciones de activacin, consumo, anulacin de activacin, anulacin de consumo y cierre desde los terminales instalados en las sucursales de los comercios. Administrador General Orsan. Actor o persona que administra las empresas, comercio, sucursales, terminales asociados a las sucursales de cada comercio, los perfiles de usuario y los usuarios del sistema. Administrador Empresa. Actor o persona que puebla la informacin de la aplicacin en la base de datos propios de la empresa. 3.2.2. Casos de Uso. Los casos de uso son muy importantes en la etapa de anlisis de un proyecto. Con estos se logra identificar la envergadura del proyecto, adems de si estn contemplados todos los requerimientos del cliente. Para este proyecto, a partir de los requerimientos funcionales obtenidos se definieron los siguientes casos de uso.

Ref. CU01 CU02 CU03 CU04 CU05 CU06 CU07 CU08 CU09 CU10 CU11 CU12 CU13 CU14

Funcin. Cargar Tarjetas Masivas. Descartar Tarjeta Consultar Transacciones Activar Tarjeta Reversar Activacin Tarjeta Reversar-Anular Consumo Tarjeta Cerrar Terminal Consumir Tarjeta Mantener Usuarios Mantener Perfiles Mantener Empresas Mantener Comercios Mantener Sucursales Mantener Terminales

Categora. Evidente Evidente Evidente Evidente Evidente Evidente Evidente Evidente Evidente Evidente Evidente Evidente Evidente Evidente

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

3.2.3. Diagrama Caso de Uso General. El diagrama de caso de uso general representa la interaccin entre los actores externos y el sistema. A su vez, este diagrama tiene todos los casos de uso que representan las distintas funcionalidades que ofrecer el sistema y que se muestra a continuacin: [Eliminar espacio a la derecha]

Figura 1: Diagrama Caso de Uso General.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

3.2.4. Matriz de Trazabilidad. La matriz de trazabilidad tiene como objetivo validar la relacin entre los requerimientos funcionales y los caso de uso. Cada requerimiento funcional debe estar relacionado con al menos un caso de uso, y cada caso de uso debe pertenecer al menos a un requerimiento funcional.

CASOS DE USO CU01 RF-01 RF-02 RF-03 RF-04 RF-05 RF-06 RF-07 RF-08 RF-09 RF-10 RF-11 REQUERIMIENTOS RF-12 RF-13 RF-14 RF-15 RF-16 RF-17 RF-18 RF-19 RF-20 RF-21 RF-22 RF-23 RF-24 RF-25 CU02 CU03 CU04 CU05 CU06 CU07 CU08 CU09 CU10 CU11 CU12 CU13 CU14

Figura 2: Matriz de Trazabilidad.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

3.3.

Modelo del Negocio.

Modelar el proceso de negocio es una parte esencial de cualquier proceso de desarrollo de software. Permite al analista capturar los eventos, las entradas, los recursos y las salidas ms importantes vinculadas con el proceso de negocio y los procedimientos que lo gobiernan. Dado que el modelo de procesos de negocio normalmente es ms amplio que la parte de sistema computacional considerada, tambin permite al analista identificar claramente qu est dentro del alcance del sistema propuesto y qu se implementar de otras formas (por ejemplo: un proceso manual). Este modelo provee una descripcin de dnde encaja el sistema de software considerado dentro de la estructura organizacional y de las actividades habituales.

Figura 3: Modelo de Proceso de Negocio del Sistema.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

4. ANLISIS ORIENTADO AL OBJETO. 4.1. Modelo del Dominio.

El modelo de dominio es una representacin visual esttica del entorno real del proyecto, es decir, un diagrama con los objetos existentes relacionados con el proyecto y las relaciones que hay entre ellos, que ayuda a comprender los conceptos que utilizan y con los que trabajan los usuarios.

Figura 4: Modelo de Dominio del Sistema.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

4.2.

Modelo de Casos de Uso.

Un caso de uso narrativo es un documento que describe la secuencia de acciones que debe ejecutar un actor externo para completar un proceso cuando utiliza el sistema. Un caso de uso no es un requerimiento ni especificacin funcional; sin embargo, estn implcitos en la narracin del mismo. 4.2.1. Casos de Uso Narrativos. [Aplicar correcciones a los casos de uso] A continuacin se presentan los casos de uso desarrollados en este informe: CU01 Cargar Tarjetas Masivas. CU02 Descartar Tarjeta. CU04 Activar Tarjeta. CU08 Consumir Tarjeta.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

CU01 Cargar Tarjetas Masivas.

Caso de uso Actores Propsito

CU01 Cargar Tarjetas Masivas Administrador general, Administrador empresa. Permitir cargar informacin de tarjetas, tanto para Activarlas o Reutilizarlas (expiradas inactivas) con el fin de venderlas y ser consumidas por los clientes de los comercios asociados.

Tipo Resumen

Evidente. El actor sube un archivo con la informacin de las tarjetas a cargar en el sistema. El sistema las valida y las deja con estado inactivas o activas, dependiendo de la opcin seleccionada.

Referencia cruzadas

No hay

Precondicin El Administrador general o de empresa debe estar autenticado en el sistema. Seccin Principal. Accin de los actores. Flujo normal 1. de eventos. El Actor selecciona la opcin de Carga de Tarjetas 2. El sistema despliega pantalla con la 3. El actor selecciona el opcin de subir archivo a cargar. Masiva. Respuesta del sistema. Adems, debe tener creado el archivo con el formato correspondiente para subirlo al sistema.

archivo a subir y presiona el botn Subir. 4. El sistema sube el archivo seleccionado por el actor, valida el formato del nombre del archivo y 5. El actor selecciona la accin (opcin) que desea realizar: Cargar Activar Reusar y presiona el botn 6. Cargar: El sistema comienza la carga revisando que el PAN y PIN sean vlidos y no existan en la base de datos y, posteriormente, Procesar. sus registros y lo deja disponible en RAM.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

que sean vlidos cada uno de los siguientes atributos: RUT de la Empresa a la cual pertenecer la tarjeta. Tambin debe existir asociado a una empresa. Monto Emisin. Tipo consumo tarjeta (T/P). Fecha Inicio Vigencia. Fecha Trmino Vigencia. Por ltimo, el sistema registra la informacin de la tarjeta en la base de datos, tabla Tarjeta con estado Inactiva. Activar: El sistema comienza la activacin revisando que cada uno de los siguientes atributos sean vlidos y existan en la tabla Tarjeta: RUT de la Empresa a la cual pertenecer la tarjeta. Monto Emisin. Tipo consumo tarjeta (T/P). Fecha Inicio Vigencia. Fecha Trmino Vigencia. Estado. Debe estar Inactiva. Por ltimo, el sistema actualiza la informacin de la tarjeta en la base de datos, en la tabla AuditTarjeta, con la informacin anterior de la tarjeta y en la tabla Tarjeta con estado Activa y actualiza la fecha de edicin. Reusar: El sistema comienza la reutilizacin revisando que cada uno de los siguientes atributos sean vlidos y existan en la tabla Tarjeta: RUT de la Empresa a la cual pertenecer la tarjeta. Monto Emisin.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

Tipo consumo tarjeta (T/P). Fecha Inicio Vigencia. Fecha Trmino Vigencia. Estado. Debe estar Inactiva. Se mantiene estado. Por ltimo, el sistema actualiza la informacin de la tarjeta en la base de datos, en la tabla AuditTarjeta, con la informacin anterior de la tarjeta y en la tabla Tarjeta con estado Activa y actualiza las nuevas fechas de vigencia y la fecha de edicin. Para cada una de las opciones anteriores, el sistema despliega el resultado de la carga con el total de registros procesados, registros OK y registros errneos. Adems, de la lista de las tarjetas (registros) que no se pudieron cargar con el detalle de la falla. Flujos alternativos. Flujo alternativo de 4. eventos 4.1. El sistema a el no subir, archivo encuentra el archivo subir desplegando a cargar.

mensaje de error No se pudo Seleccione un archivo a subir. El flujo contina en el punto 2. 4.2 El sistema despliega el siguiente mensaje de error Formato del nombre del archivo no vlido. Intente con un nuevo archivo o modifique el actual. El flujo contina en el punto 2. 4.3. Error en formato registro. El sistema despliega el siguiente mensaje de error Formato de registros del archivo no vlido. Intente con un nuevo archivo o modifique el actual. El flujo contina en el punto 2. 6.1. Error en validacin de uno de sus

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

datos. El sistema guarda en RAM los datos de la tarjeta, de la carga misma y el cdigo del error correspondiente a la validacin. El flujo se mantiene en el punto 4. 6.2. Error al guardar registro en tabla. El sistema no pudo generar registro de la tarjeta. El sistema guarda en RAM los datos de la tarjeta, de la carga misma y el cdigo del error correspondiente al problema de registro de la tarjeta. El flujo se mantiene en el punto 4. Post condicin El actor carga la informacin de las tarjetas en el sistema y las deja con estado: Para carga y reuso: Inactiva, para su posterior activacin. Para activacin: Activa, para su posterior consumo.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

CU02 Descartar Tarjeta.

Caso de uso Actores Propsito Tipo Resumen Referencia cruzadas

CU02 Descartar Tarjeta Administrador Empresa Descartar una tarjeta cargada previamente en el sistema. Evidente. El actor ingresa el nmero PAN de una tarjeta para descartar. -

Precondicin El actor debe haber ledo o seleccionado una tarjeta. Seccin Principal. Accin de los actores. Flujo normal 1. de eventos. El actor ingresa el nmero PAN de una tarjeta. 2. El sistema consulta y recupera los datos de la tarjeta desde la tabla de Tarjetas. 3. 4. 5. El sistema valida la integridad de la tarjeta. El sistema valida que el estado actual de la tarjeta sea INACTIVA. El sistema registra el estado actual de la tarjeta histrico de tarjetas. 6. El sistema actualiza el estado de la tarjeta como DESCARTADA en la tabla de Tarjetas. 7. 8. Flujos alternativos. Flujo alternativo de 1. eventos 2.1. El sistema falla al consultar el estado actual de la tarjeta y genera y despliega un mensaje de error. 2.2. El flujo contina en el punto 8. Flujo alternativo de 2. Flujo eventos 3.1. El sistema falla al validar la integridad de la tarjeta genera y despliega un mensaje de error. 3.2. El flujo contina en el punto 8. 4.1. El sistema falla al validar que el El actor finaliza la accin de descartar tarjeta. El sistema genera y despliega respuesta exitosa. en el log Respuesta del sistema.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

alternativo de 3. eventos

estado actual sea INACTIVA y, genera y despliega un mensaje de error. 4.2. El flujo contina en el punto 8.

Flujo alternativo de 4. eventos

5.1. El sistema falla al registrar el estado actual de la tarjeta en el log histrico de tarjetas, y, genera y despliega un mensaje de error. 5.2. El flujo contina en el punto 8.

Flujo alternativo de 5. eventos

5.1. El sistema falla al actualizar el estado de la en tarjeta la como de DESCARTADA tabla

Tarjetas, y genera y despliega un mensaje de error. 5.2. El flujo contina en el punto 8.

Post condicin

La tarjeta ha sido descartada.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

CU04 Activar Tarjeta.

Caso de uso Actores Propsito Tipo Resumen Referencia cruzadas

CU04 Activar Tarjeta Switch, Administrador Empresa Activar una tarjeta cargada previamente en el sistema. Evidente. El actor ingresa el nmero PAN de una tarjeta para activar. CU01

Precondicin El actor debe haber ledo o seleccionado una tarjeta. Seccin Principal. Accin de los actores. Flujo normal 1. de eventos. El actor ingresa el nmero PAN de una tarjeta. 2. El sistema consulta y recupera los datos de la tarjeta desde la tabla de Tarjetas. 3. 4. 5. El sistema valida la integridad de la tarjeta. El sistema valida que el estado actual de la tarjeta sea INACTIVA. El sistema registra el estado actual de la tarjeta histrico de tarjetas. 6. El sistema actualiza el estado de la tarjeta como ACTIVA en la tabla de Tarjetas. 7. 8. Flujos alternativos. Flujo alternativo de 1. eventos 2.1. El sistema falla al consultar el estado actual de la tarjeta y, genera y despliega un mensaje de error. 2.2. El flujo contina en el punto 8. Flujo alternativo de 2. Flujo eventos 3.1. El sistema falla al validar la integridad de la tarjeta, y, genera y despliega un mensaje de error. 3.2. El flujo contina en el punto 8. 4.1. El sistema falla al validar que el El actor finaliza la accin de activar tarjeta. El sistema genera y despliega respuesta exitosa. en el log Respuesta del sistema.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

alternativo de 3. eventos

estado actual sea INACTIVA y, genera y despliega un mensaje de error. 4.2. El flujo contina en el punto 8.

Flujo alternativo de 4. eventos

5.1. El sistema falla al registrar el estado actual de la tarjeta en el log histrico de tarjetas y, genera y despliega un mensaje de error. 5.2. El flujo contina en el punto 8.

Flujo alternativo de 5. eventos

6.1. El sistema falla al actualizar el estado de la tarjeta como ACTIVA en la tabla de Tarjetas y, genera y despliega un mensaje de error. 6.2. El flujo contina en el punto 8.

Post condicin

La tarjeta ha sido activada.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

CU08 Consumir Tarjeta.

Caso de uso Actores Propsito Tipo Resumen

CU08 Consumir Tarjeta Switch. Generar las transacciones de consumo de las tarjetas (ventas) por parte de los clientes a travs de los comercios y sus sucursales. Evidente. El usuario solicita el consumo de la tarjeta a travs del actor Switch, el cul realiza las distintas peticiones al sistema para poder validar y generar la compra del cliente (beneficiario).

Referencia cruzadas

No hay

Precondicin La tarjeta debe estar en estado Activa con saldo suficiente para realizar la compra y fecha de compra dentro del rango de vigencia. Seccin Principal. Accin de los actores. Flujo normal 1. de eventos. El Actor recibe peticin de Consumo de tarjeta y a su vez enva peticin al 2. El sistema recibe la peticin del Actor (Switch) y realiza las siguientes validaciones: Que la tarjeta exista y est activa y dentro de la fecha de vigencia. Que la tarjeta corresponda al comercio y el terminal, sucursal, comercio y empresa estn activos. Que la tarjeta tenga saldo suficiente. En el caso de las tarjetas con modalidad consumo nico, que la tarjeta tenga el mismo monto que el consumo a realizar. El sistema genera la transaccin en la base de datos, tabla Transaccion con los siguientes campos (entre otros): Cd. transaccin Cd. retorno transaccin Cd. autorizacin transaccin Glosa retorno sistema. Respuesta del sistema.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

Monto transaccin Fecha transaccin Cdigo cajero Luego, actualiza el saldo de la tarjeta, y si corresponde, tambin el estado de la tarjeta. El sistema responde mensaje de xito de la transaccin al Actor. 3. Flujos alternativos. Flujo alternativo de 3. eventos 2.1. El sistema no encuentra el cdigo de la tarjeta o la encuentra en estado distinta de Activa o que ya no est vigente, desplegando uno de los siguientes mensajes error: Tarjeta no existe. Tarjeta no vlida. Tarjeta Expirada. El flujo contina en el punto 3. 2.2. El sistema indica que la tarjeta no corresponde al comercio asociado, a travs del siguiente mensaje de error: Tarjeta no corresponde al comercio. El flujo contina en el punto 3. 2.3. El sistema indica que la tarjeta no tiene saldo suficiente. Error: Tarjeta no tiene saldo suficiente para efectuar la compra. El flujo contina en el punto 3. 2.4. El sistema indica que la tarjeta es de tipo consumo total y que los montos de consumo y de tarjeta no coinciden. usarse asignado. El flujo contina en el punto 3. 2.4. El sistema no pudo generar el registro de la compra (consumo) en la base de datos, tabla Transaccion. Error: Error al grabar la transaccin. Error: el Tarjeta monto debe total por El actor devuelve respuesta a quien solicit la peticin.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

El flujo contina en el punto 3. 2.5. El sistema no pudo responder al Actor. en la Se realiza de reversa datos, de tabla consumo (CU06) de la transaccin base Transaccion. Error: Error en el proceso, se reversa transaccin. El flujo contina en el punto 3. Post condicin Se cierra el ciclo de consumo a travs de una transaccin.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

4.2.2. Diagramas de Secuencia. [Aqu se podran incluir los diagramas de secuencia de anlisis]

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

4.2.3. Contratos. La creacin de un contrato de operacin est supeditada a la creacin previa del modelo de dominio, los diagramas de secuencia y la identificacin de las operaciones del sistema. Los contratos de operacin: Describen el cambio de un estado a otro de los objetos del dominio como resultado de una operacin. No son obligatorios y se utilizan cuando los detalles y la complejidad de los cambios de estado implcitos en la operacin hacen difcil su captura en los casos de uso. [Revisar y corregir contratos] Contrato CO01.

Nombre Ref. Cruzadas PreCondiciones PostCondiciones

procesarCargaTarjetas(tarjeta: Tarjeta) No hay Tener disponible un archivo en Excel con la lista de las tarjetas a subir y el formato adecuado. El sistema subi y registr las tarjetas con el estado: Carga: Inicial Inactiva y los datos iniciales de sta, como los cdigos de identificacin de la tarjeta, el monto asociado y fechas de vigencia. El sistema cre una asociacin entre la tarjeta y la empresa. El sistema gener un registro de auditora de la operacin. Activacin: Activa y fechas de vigencia actualizadas. El sistema gener un registro de auditora de la operacin. Reuso: Inactiva y fechas de vigencia actualizadas. El sistema gener un registro de auditora de la operacin.

Contrato CO02. Nombre descartarTarjeta(tarjeta: Tarjeta)

Ref. Cruzadas No hay PreCondiciones PostCondiciones El sistema descart la tarjeta quedando con estado Descartada. El sistema gener un registro de auditora de la operacin. Tarjeta cargada en el sistema con estado Inactiva.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

Contrato CO04.

Nombre Ref. Cruzadas PreCondiciones PostCondiciones

activarTarjeta(tarjeta: Tarjeta) procesarCargaTarjetas() CU01 Tarjeta cargada en el sistema con estado Inactiva. El sistema activ la tarjeta quedando con estado Activa y disponible para ser usada por el cliente final. El sistema gener un registro de auditora de la operacin.

Contrato CO08.

Nombre Ref. Cruzadas PreCondiciones

registrarTransaccion(transaccion: Transaccion) activarTarjeta() - CU04 El actor (Switch) recibe la peticin de consumo desde el exterior del sistema, ya sea de un terminal POS, Web u otra interfaz. La tarjeta est con estado Activa con saldo suficiente (el mismo monto para el consumo y el de la tarjeta para el caso que sea de tipo consumo total) y el terminal, sucursal, comercio y empresa, activos.

PostCondiciones

El sistema gener el registro de transaccin de la tarjeta. El sistema actualiz el estado a Consumida (slo para tarjetas con saldo igual a cero). El sistema gener un registro de auditora de la operacin.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

4.3.

Diagramas de Estados.

Los diagramas de estado muestran la secuencia de estados por los que pasa un caso de uso, un objeto a lo largo de su ciclo de vida o bien, todo el sistema. En l se indican qu eventos hacen que pase de un estado a otro, y cules son las respuestas y acciones que genera. En el siguiente diagrama se presentan los diagramas de estado para las entidades Empresa y Tarjeta. [Los diagramas de estado pueden ser por clase o caso de uso] 4.3.1. Diagrama de Estado Entidad Empresa.

Figura 14: Diagrama de Estado Entidad Empresa. 4.3.2. Diagrama de Estado Entidad Tarjeta.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

Figura 15: Diagrama de Estado Entidad Tarjeta.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

5. DISEO DEL SISTEMA. 5.1. Diseo Arquitectnico.

El diseo arquitectnico corresponde al proceso de diseo que identifica los subsistemas comunicacin. El sistema de administracin de giftcard fue desarrollado utilizando una arquitectura de 2 capas, construido con tecnologa Microsoft Visual Studio 2005, WebForms, framework ASP.NET 3.5, ADO.NET y lenguaje de programacin C#. Capa Aplicacin Propsito Interfaz de usuario, lgica de las Datos reglas y procesos del negocio o dominio. Responsable de mantener la integridad de la BD. Normalmente incluye la lgica del manejo de transacciones. 5.1.1. Diagrama de Contexto Arquitectnico. El diagrama de contexto del sistema permite modelar el contexto, representando el flujo de informacin dentro y fuera del sistema, la informacin del usuario y el procesamiento relevante de soporte. Se aplica para modelar la manera en que el software interactuar con las entidades ubicadas ms all de sus lmites. El sistema destino es el Sistema de Administracin de Giftcard, tiene tres actores que interactan con l produciendo o consumiendo informacin para el procesamiento de los requisitos (Administrador Orsan, Administrador Empresa y Cliente), e interacta de igual a igual con un sistema par que est representado como el Switch Autorizador. Herramienta de Software Pginas web ASP.NET WebForms (aspx), archivos code-behind (aspx C#). Servidor de Base de Datos SQL Server 2005, ADO.NET y stored procedures. que conforman el sistema y la infraestructura de control y

Figura xx: Diagrama de Contexto Arquitectnico.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

5.1.2. Diagrama de Despliegue. Los diagramas de despliegue representan la arquitectura de ejecucin de un sistema, y representan los artefactos del sistema como nodos, los cuales se interconectan a travs de rutas de comunicacin para crear redes de sistema de complejidad arbitraria. Un nodo es un elemento de hardware o software que se representa como una caja en tres dimensiones y puede ser usado como contenedor. Una instancia de nodo se distingue del nodo porque su nombre est subrayado y tiene dos punto antes del tipo de nodo base. A un nodo se le asocia un estereotipo estndar seleccionado de entre varios provistos. Los artefactos son productos del desarrollo de software y contienen archivos fuentes, ejecutables y documentos, y se denotan por un rectngulo con un nombre, un estereotipo y un cono del documento. Una asociacin representa una ruta de comunicacin entre dos nodos. En el siguiente diagrama se presenta el diagrama de despliegue para el Sistema de Administracin de GiftCard.

Figura 17: Diagrama de Despliegue del Sistema.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

5.2.

Diseo de la Interfaz.

[Agregar referencia y pantallas restantes] Los prototipos de pantallas son representaciones iniciales y globales de las pantallas del software que se quiere crear. Con estas se obtiene una retroalimentacin desde el usuario final hacia el ingeniero, lo que permite mejorarlas con aporte de estos mismos usuarios. Un buen diseo de prototipo de pantalla se basa usualmente, en metodologas o principios de usabilidad preestablecidos y comprobados en su eficacia. Para este proyecto nos basamos en la Metodologa de los 10 principios de usabilidad de Jakob Nielsen, uno de los mayores expositores en cuanto a la usabilidad. Los 10 principios de usabilidad de Nielsen o Heursticas son los siguientes: Visibilidad del estado del sistema: el sistema siempre debera mantener informados a los usuarios de lo que est ocurriendo, a travs de retroalimentacin apropiada dentro de un tiempo razonable (H1). Relacin entre el sistema y el mundo real: el sistema debera hablar el lenguaje de los usuarios mediante palabras, frases y conceptos que sean familiares al usuario, ms que con trminos relacionados con el sistema. Seguir las convenciones del mundo real, haciendo que la informacin aparezca en un orden natural y lgico (H2). Control y libertad del usuario: hay ocasiones en que los usuarios elegirn las funciones del sistema por error y necesitarn una salida de emergencia claramente marcada para dejar el estado no deseado al que accedieron, sin tener que pasar por una serie de pasos. Se deben apoyar las funciones de deshacer y rehacer (H3). Consistencia y estndares: los usuarios no deberan cuestionarse si acciones, situaciones o palabras diferentes significan en realidad la misma cosa; siga las convenciones establecidas (H4). Prevencin de errores: mucho mejor que un buen diseo de mensajes de error es realizar un diseo cuidadoso que prevenga la ocurrencia de problemas (H5). Reconocimiento antes que recuerdo: se deben hacer visibles los objetos, acciones y opciones, El usuario no tendra que recordar la informacin que se le da en una parte del proceso, para seguir adelante. Las instrucciones para el uso del sistema deben estar a la vista o ser fcilmente recuperables cuando sea necesario (H6). Flexibilidad y eficiencia de uso: la presencia de aceleradores, que no son vistos por los usuarios novatos, puede ofrecer una interaccin ms rpida a los usuarios expertos que la que el sistema puede proveer a los usuarios de todo tipo. Se debe permitir que los usuarios adapte el sistema para usos frecuentes (H7). Esttica y diseo minimalista: los dilogos no deben contener informacin que es irrelevante o poco usada. Cada unidad extra de informacin en un

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

dilogo, compite con las unidades de informacin relevante y disminuye su visibilidad relativa (H8). Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores: los mensajes de error se deben entregar en un lenguaje claro y simple, indicando en forma precisa el problema y sugerir una solucin constructiva al problema (H9). Ayuda y documentacin: incluso en los casos en que el sistema pueda ser usado sin documentacin, podra ser necesario ofrecer ayuda y documentacin. Dicha informacin debera ser fcil de buscar, estar enfocada en las tareas del usuario, con una lista concreta de pasos a desarrollar y no ser demasiado extensa (H10). En las pginas siguientes, se mostrarn tres prototipos de pantallas generados para los CU ms importantes de este proyecto (CU01, CU02 y CU04). Las heursticas de usabilidad estn identificadas con una H y su nmero de acuerdo a los 10 principios anteriores. En este caso se muestran mximo tres principios, ya que los dems son internos o no aplican en la pantalla: 5.2.1. Pantalla Cargar Tarjetas Masivas.

Figura 18: Pantalla Cargar Tarjetas Masivas.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

5.2.2. Pantalla Descartar Tarjeta.

Figura 19: Pantalla Descartar Tarjeta. 5.2.3. Pantalla Activar Tarjeta.

Figura 20: Pantalla Activar Tarjeta.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

5.3.

Diseo de la Lgica.

Los Diagramas de Colaboracin, al igual que los diagramas de Secuencia, son una forma de representar la interaccin entre objetos, la diferencia est en que los diagramas de colaboracin implementan una situacin puntual y no contextual, asociada a la operacin o caso de uso establecido. Este diagrama implementa la asociacin del diagrama de clases mediante el paso de los mensajes entre un objeto y otro. A continuacin se presentan los diagramas de colaboracin para los siguientes casos de uso: CU01 Cargar Tarjetas Masivas. CU02 Descartar Tarjeta. CU04 Activar Tarjeta. CU08 Consumir Tarjeta.

[Corregir Diagramas] Diagrama de Colaboracin CU01 Cargar Tarjetas Masivas.

Figura 10: Diagrama de Colaboracin CU01 Cargar Tarjetas Masivas.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

Diagrama de Colaboracin CU02 Descartar Tarjeta.

Figura 11: Diagrama de Colaboracin CU02 Descartar Tarjeta. Diagrama de Colaboracin CU04 Activar Tarjeta.

Figura 12: Diagrama de Colaboracin CU04 Activar Tarjeta.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

Diagrama de Colaboracin CU08 Consumir Tarjeta.

Figura 13: Diagrama de Colaboracin CU08 Consumir Tarjeta.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

5.4.

Diseo de los Datos.

El modelo relacional es un modelo de datos basado en la teora de las relaciones, en donde los datos se estructuran lgicamente en forma de relaciones (tablas), siendo un objetivo fundamental del modelo mantener la independencia de esta estructura lgica respecto al modo de almacenamiento y a otras caractersticas de tipo fsico. Este modelo persigue una serie de objetivos, que se pueden resumir en independencia fsica y lgica, flexibilidad, uniformidad y sencillez. [Cmo se obtuvo? Resumen de la aplicacin de los 9 pasos de normalizacin]

Figura 16: Modelo Relacional del Sistema.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011

6. CONCLUSIONES. Los procesos de anlisis y diseo son procesos iterativos, que se inician con un alto nivel de abstraccin y, a medida que se va depurando el diseo del sistema, se va bajando de nivel, alcanzando un detalle suficiente como para enfrentar la implementacin del sistema. Cada iteracin plantea diferentes desafos, en cuanto a las problemticas que se deben resolver en cada una, a la notacin que debe ser utilizada y a la metodologa a seguir para lograr obtener los productos deseados en cada paso del proceso. A travs del desarrollo de este trabajo hemos podido constatar los problemas a los que se enfrenta en su trabajo un ingeniero de software. Desde la idea inicial, pasando por la definicin del alcance del proyecto y el levantamiento de requerimientos, hasta llegar a la definicin de la arquitectura y la especificacin de los componentes del sistema, es posible visualizar el dinamismo de estos procesos, que hacen que el sistema est en constante revisin y refinamiento para llegar a un producto de calidad.

Universidad Tcnica Federico Santa Mara - Taller de Anlisis y Diseo 2011