estructura de la tesis v05.docx

UNIVERSIDAD RICARDO PALMAFACULTAD DE INGENIERIA

ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA

“SISTEMA INTEGRAL DE PLANES Y SEGUIMIENTO DE BENEFICIOS PARA MASCOTAS DE LA CLINICA

VETERINARIA EL TRIGAL”

PROYECTO DE TESISPARA OPTAR EL TÍTULO PROFESIONAL DE

INGENIERO INFORMÁTICO

PRESENTADO POR: - Jeannette Marilú Barrientos Álvarez.

- Juan José Caro Salazar.

ASESOR: - Ing. Roger Vargas

LIMA – PERÚ

2013

Resumen

La Clínica Veterinaria ”El Trigal” al igual que todas tiene objetivos específicos de

negocio que cubrir, aumentar ingresos, comunicación inter-sede con varias sedes y

ajustar sus sistemas a los requerimientos del negocio. La capacidad para responder

rápidamente a los objetivos planteados y optimizar los procesos de negocio es un factor

clave para la competitividad y el crecimiento de la empresa.

Con el uso de entornos orientados a servicios se pretende que la empresa mejore

la interacción con los clientes, proveedores, es decir, conseguir una mayor rentabilidad

permitiendo responder de forma más rápida y adaptarse adecuadamente a las presiones

del mercado.

Palabras claves

Las siguientes palabras serán manejadas en el siguiente trabajo: SOA, Web Services,

Servicios Web, UDDI, WSDL, SOAP.

Contents

CAPÍTULO I INTRODUCCIÓN..................................................................................5

1. VISION DEL PROYECTO.......................................................................................61.1. Antecedentes del Problema......................................................................................6

1.2. Formulación del Problema.........................................................................................7

1.3. Marco Teórico.................................................................................................................8

1.3.1. Glosario.........................................................................................................................8

1.3.2. Introducción a las tecnologías básicas..............................................................9

1.3.2.1. Paradigmas de Programación...........................................................................9

1.3.2.2. Programación estructurada.............................................................................10

1.3.2.3. Programación modular......................................................................................10

1.3.2.4. Programación orientada a objetos................................................................10

1.3.2.5. Software distribuido...........................................................................................12

1.4. Estado del Arte............................................................................................................14

1.4.1. Servicios Web...........................................................................................................14

1.4.1.1. Arquitectura Funcional de los Servicios Web............................................15

1.4.1.2. Estándares de los Servicios Web...................................................................16

1.4.1.3. Ciclo de Vida de los Servicios Web...............................................................17

1.4.1.4. Arquitectura de los Servicios Web................................................................20

1.4.1.5. Dispositivos Móviles y Servicios Web...........................................................21

1.4.2. Arquitectura Orientada a Servicios...................................................................22

1.4.2.1. Elementos de SOA..............................................................................................23

1.5. Objetivo..........................................................................................................................26

1.5.1. Objetivo General.....................................................................................................26

1.5.2. Objetivo Especifico.................................................................................................27

1.6. Importancia...................................................................................................................27

1.6.1. Justificación Académica........................................................................................27

1.6.2. Beneficios Tangibles..............................................................................................27

1.6.3. Beneficios Intangibles...........................................................................................28

1.7. Alcance...........................................................................................................................28

2. Modelado del Negocio......................................................................................292.1. Actores de Negocio....................................................................................................29

2.2. Diagrama de caso de uso del Negocio................................................................29

3. Requerimientos del Proyecto.......................................................................30

3.1. Requerimientos Funcionales...................................................................................30

3.2. Requerimientos No Funcionales............................................................................30

3.3. Diagrama de Actores del Sistema.........................................................................32

3.4. Definición de casos de uso del Sistema..............................................................32

3.5. Modelo Conceptual.....................................................................................................49

3.6. Diagrama de Secuencia............................................................................................50

3.6.1. Validar Usuario.........................................................................................................50

3.6.2. Mantener Póliza.......................................................................................................51

3.6.3. Reservar Cita Medica.............................................................................................52

3.7. Benchmarking..............................................................................................................53

3.8. Prototipos.......................................................................................................................53

3.8.1. Registrar Póliza........................................................................................................53

3.8.2. Reservar Cita Medica.............................................................................................54

3.9. Matriz de Requerimientos de Negocio vs Funcionales..................................54

CAPÍTULO I

INTRODUCCIÓN

1. VISION DEL PROYECTO

1.1. Antecedentes del Problema

En las últimas décadas los departamentos de Tecnologías de la Información de

las empresas han construido una infraestructura que soporta en gran medida la

operación de sus empresas y sus clientes. El resultado de este proceso ha sido

la creación y mantenimiento de un número considerable de aplicaciones de uso

interno, cada una responsable de sus propias tareas.

Los negocios exigen crear aplicaciones cada vez más complejas, en menos

tiempo y con menor presupuesto. En muchos casos crear estas aplicaciones

requiere de funcionalidades ya antes implementadas como parte de otros

sistemas. Ante esta situación los arquitectos de software se enfrentan a dos

opciones:

Tratar de reutilizar la funcionalidad ya implementada en otros sistemas.

Una labor difícil de realizar, debido a que estos no fueron diseñados

para integrarse o se elaboraron para plataformas y/o tecnologías

incompatibles entre ellas.

Re-implementar la funcionalidad requerida. Aunque implica más tiempo

de desarrollo, es en la mayoría de los casos la más fácil y segura.

A pesar de que no sea la más acertada a largo plazo, la segunda opción es la

más escogida. Esto trae como resultado:

Funcionalidad replicada en varias aplicaciones.

Dificultad de migración de los sistemas internos, al haber múltiples

conexiones desde sistemas que dependen de estos para su

funcionamiento.

Al no haber una estrategia de integración de aplicaciones, se generan

múltiples puntos de fallo, que pueden detener la operación de todos los

sistemas muy fácilmente.

El inconveniente final es una pobre respuesta al cambio. Las

aplicaciones siguen siendo concebidas desde un principio como islas

independientes.

En la arquitectura SOA la funcionalidad deseada se descompone en unidades

(servicios) que pueden ser distribuidos en diferentes nodos conectados a través

de una red y que, asimismo, son combinados entre sí para alcanzar el resultado

deseado. Estos servicios pueden proporcionar datos a otros o llevar a cabo

actividades de coordinación entre uno o varios servicios.

Las aplicaciones necesarias para obtener los correspondientes procesos de

negocio se logran mediante la combinación de colecciones de pequeños

módulos llamados servicios. Estos módulos pueden ser empleados por grupos

de usuarios provenientes de la propia organización o ajenos a la misma y las

nuevas aplicaciones creadas del aprovechamiento de servicios presentes en un

repositorio global muestran mayor flexibilidad y uniformidad. De este modo se

consigue un ahorro en el esfuerzo de desarrollo pues se re-aprovechan las

funcionalidades comunes a las distintas aplicaciones además de favorecer la

interacción entre organizaciones dado que se logra la homogeneización de la

apariencia y del nivel y tipo de datos de entrada para la validación de los

usuarios.

En este entorno de trabajo, las unidades básicas son los servicios. Los servicios

son unidades de funcionalidad que desarrollan su actividad de forma

independiente y que se aproxima al concepto que los humanos asocian a los

mismos como puede ser la visualización del estado de una cuenta bancaria, o

la emisión de una petición de un billete de avión o de tren. En lugar de que los

servicios contengan en su código fuente llamadas a otros, se definen

protocolos que describen cómo pueden comunicarse entre sí.

1.2. Formulación del Problema

El área de Tecnología Informática (TI) en las Organizaciones actuales se puede

caracterizar por tener diversidad de sistemas que tienen entre sí dependencias

complejas, que han ido creciendo en forma separada y heterogénea a lo largo

de los años. Un desafío que se plantea es poder integrarlos para reaccionar

ágilmente a los cambios en los requerimientos del negocio, principalmente en

dos aspectos: los procesos de la Organización y las tecnologías disponibles.

Service Oriented Architecture (SOA) es un estilo de Arquitectura de Software

basado en la definición de servicios reutilizables, con interfaces públicas bien

definidas, donde los proveedores y consumidores de servicios interactúan en

forma desacoplada para realizar los procesos de negocio. Los servicios

representan grupos lógicos de operaciones relacionadas con algún concepto

del negocio, y los procesos del negocio se realizan mediante secuencias

definidas de invocaciones a servicios, en orquestación o coreografías de

servicios. La definición y disponibilidad de estosservicios para toda la

Organización es la base del enfoque SOA.

En la Clínica Veterinaria “El Trigal” cuenta con un gran número de clientes y

con ello un volumen considerable de información, asimismo se relaciona con

sus otras sucursales. La necesidad que actualmente tiene la empresa es de

integrar esta información ya que ha encontrado un nicho de mercado el cual

quiere empezar a explotar, el mercado en el cual quiere entrar y ser pionero en

el Perú son los Seguros para Mascotas marcando como alcance inicial los

seguros para perros; si bien las mascotas reciben cuidados médicos sin estar

asegurados, cuando se les diagnostica enfermedades sobre las cuales se

requiere tratamientos prolongados y con un costo elevado las personas

(clientes) se desalientan. El plan de seguro propuesto, cubrirá las necesidades

básicas y protegerá ante eventos de mayor envergadura. Cuando las mascotas

no tienen seguro se debe pagar por cada consulta que se realiza. Al tener

cobertura, se tiene más posibilidades de mantener mejor la salud de la

mascota, ya que consultara a su veterinario con mayor frecuencia, porque esas

visitas están cubiertas por el plan. Y mediante la interconexión de las clínicas

veterinarias asociadas se podrá generar reportes de control e indicadores para

la clínica veterinaria “El Trigal”.

1.3. Marco Teórico

1.3.1. Glosario

SOA: La arquitectura orientada a servicios de cliente (en inglés Service

Oriented Architecture), es un concepto de arquitectura de software que define

la utilización de servicios para dar soporte a los requisitos del negocio.

Web Services: es una tecnología que utiliza un conjunto de protocolos y

estándares que sirven para intercambiar datos entre aplicaciones. Distintas

aplicaciones de software desarrolladas en lenguajes de programación

diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los

servicios web para intercambiar datos en redes de ordenadores como Internet.

Servicios Web: Un servicio web (en inglés, Web services)

UDDI: Universal Description, Discovery and Integration. Es un directorio

distribuido basado en Web que le permite a los negocios listarse a sí mismos

en Internet y descubrir otros, similar a las páginas blancas y amarillas de una

guía telefónica tradicional.

WSDL: describe la interfaz pública a los servicios Web. Está basado en XML y

describe la forma de comunicación, es decir, los requisitos del protocolo y los

formatos de los mensajes necesarios para interactuar con los servicios listados

en su catálogo. Las operaciones y mensajes que soporta se describen en

abstracto y se ligan después al protocolo concreto de red y al formato del

mensaje.

SOAP: (siglas de Simple Object Access Protocol) es un protocolo estándar que

define cómo dos objetos en diferentes procesos pueden comunicarse por medio

de intercambio de datos XML.

1.3.2. Introducción a las tecnologías básicas

Esta introducción es útil para tener una visión clara del tópico “De dónde

venimos y donde vamos” en el mundo del desarrollo de software”

1.3.2.1. Paradigmas de Programación

Los paradigmas de programación son enfoques partículas para el desarrollo del

software. Son distintas maneras de visualizar y resolver problemas de

programación.

1.3.2.2. Programación estructurada

En la década del 60 surgió los principios de la programación estructurada, en

esa época solo estaba permitido el uso de tres lógicas de control:

- Secuencia: bloque de sentencias que se ejecutan una a continuación de

otra.

- Condicional: bloque de sentencias que se ejecutan solo si cumple una

condición.

- Interacción: repetición mientras se cumple una condición dada.

Los programas desarrollados con este paradigma eran mucho más fáciles de

entender que los desarrollados mediante una programación desestructurada.

1.3.2.3. Programación modular

Se usan subprogramas estructurados que se denominan módulos, que

interactúan entre sí para resolver el problema planteado. La comunicación

entre los módulos se realiza mediante el intercambio de parámetros.

Cada módulo tiene la ventaja de que es reutilizable y puede ser considerado

una caja negra es con ello que se consigue independencia entre los módulos.

1.3.2.4. Programación orientada a objetos

Se popularizo en la década de los 90, este paradigma permite resolver

problemas mediante el trabajo colaborativo de los objetos. Se pretende

modelar objetos del mundo real en las aplicaciones dando lugar al concepto de

objetos. Los objetos tienen propiedades y comportamientos:

- Propiedad: cada uno de los datos (atributos) que tiene el objeto.

- Comportamiento: cada una de las operaciones (métodos) mediante las

cuales se puede interactuar con el objeto.

Una clase es el conjunto de propiedades y comportamiento de un objeto

específico. Se puede decir que la clase es la estructura en la cual se puede

basar para crear el objeto.

Características de la programación orientada a objetos:

- Abstracción: se basa en la obtención de las características esenciales de un

objeto. Ejemplo las características comunes del objeto empleado.

- Encapsulamiento: es la unión en una clase de las características y

comportamientos.

- Herencia: una clase no es una entidad aislada sino que puede relacionarse

entre sí formando una jerarquía.

- Polimorfismo: cuando se habla de polimorfismo se puede referir a dos

cosas:

o Posibilidad de almacenar objetos de un determinado tipo en

variables de tipos antecesores del primero.

o Posibilidad de tener diferentes métodos dentro de una clase con el

mismo nombre pero con diferentes argumentos.

class Empleado{

string DNI;int numEmpleado;string NombreEmpleado;void ALtaEmpleado (string DNI, int numEmpleado, string Nombre Empleado){…}…

}

Figura 1 Ejemplo de clase

Figura fig = new Figura ();Figura fig2 = new Circulo ();fig.Dibujar(); //Dibujará una figurafig2.Dibujar(); //Dibujará un círculo


Ventajas del lenguaje orientado a objetos:

- Reutilización y extensión del código

- Flexibilidad de crear sistemas complejos

- Se relaciona con el mundo real

- Agiliza el desarrollo de software

- Suministra el trabajo en equipo

- Facilita el mantenimiento del software

1.3.2.5. Software distribuido

El software distribuido se define como un sistema cuyos componentes están

ubicados en diferentes maquinas (servidores) y que se comunican entre si

mediante la transmisión de mensajes.

Estos sistemas son acoplados, es decir los componentes de cada capa tienen

una dependencia muy alta con los componentes de otras capas. Entre los

diferentes modelos de arquitecturas distribuidas tenemos:

1. Cliente-Servidor

Sistema donde el cliente tiene toda la lógica de negocio, acceso a datos

y el servidor en un solo repositorio de información.

double sumar (int opl, intop2) {…}double sumar (double opl, double op2) {…}


Figura 4 Arquitectura cliente/servidor

2. Arquitectura en tres Niveles (N-Tier)

La arquitectura de tres capas libera al cliente del procesamiento de la

lógica de negocio y accesos de datos para que pueda convertirse en un

cliente más ligero.

Descripción de las capas:

o Nivel de presentación: es una aplicación cliente que únicamente se

encarga de implementar la interface con el usuario. Este nivel en un

inicio se implementaba como una aplicación Windows, pero ha ido

evolucionando de tal forma que en la actualidad puede ser una

aplicación web.

o Nivel aplicación: son componentes que se encargan del

procesamiento de la lógica del negocio. El nivel de negocio está

situado en un servidor o varios.

o Nivel de datos: Son los servidores de base de datos, como servidores

SQL Server, Oracle, DB2, etc.

Ventajas de los sistemas distribuidos

- Escalabilidad

- Concurrencia y agilidad (respuestas rápidas al cliente)

- Reutilización de componentes

Desventajas de los sistemas distribuidos

- Costos altos para la puesta en producción

- Costos altos para la administración

- Dependencia de las redes de comunicación

- Foco en la seguridad de la información

Figura 5 Ejemplo de Arquitectura de 3 Capas

1.4. Estado del Arte

1.4.1. Servicios Web

La década de los 80's fue marcada por el surgimiento de la PC y de la interfase

gráfica. En la década de los 90's Internet permitió conectar computadoras en

una escala global. En principio la conexión fue entre PCs y servidores por

medio del explorador de Internet. A comienzos de este siglo es clara la

necesidad de permitir a las computadoras conectadas a Internet comunicarse

entre ellas.

Desde entonces se va dando forma al nuevo modelo de computación

distribuida llamado servicios Web basados en XML. El objetivo es permitir

comunicarse entre sí a sistemas heterogéneos dentro y fuera de una empresa.

Esta comunicación es independiente del sistema operativo, lenguaje o modelo

de programación.

La simplicidad de las interacciones en el modelo de programación Web

posibilita construir sistemas incrementalmente. A diferencia del acoplamiento

fuerte de RPC y de los sistemas de objetos distribuidos, que requieren la

implantación de todas las piezas de una aplicación de una vez, podemos añadir

tantos clientes y servidores a sistemas basados en Web como necesitemos.

Podemos establecer fácilmente conexiones a aplicaciones nuevas de un modo

descentralizado, sin ninguna coordinación central más allá del registro de

nombres DNS, y con un grado de interoperabilidad, escalabilidad y capacidad

de gestión extraordinariamente alto.

La siguiente figura 2.1 nos muestra el comportamiento de las arquitecturas

durante su evolución.

1.4.1.1. Arquitectura Funcional de los Servicios Web

La arquitectura se basa en tres tipologías de servicios como se muestran en la

figura.

Figura 7 Arquitectura funcional de un Servicio Web

Figura 6 Arquitectura funcional de un Servicio Web

a) Servicios de Catalogación.

Sirven al proveedor para publicar un servicio en la red. Los aporta la

Agencia.

b) Servicios de Localización.

Sirven al usuario para localizar funcionalmente el servicio que necesita. La

localización y descubrimiento del servicio puede ser:

- Estática, navegando el futuro cliente.

- Dinámica en tiempo de diseño o ejecución utilizando un servicio UDDI.

c) Servicios de Utilización

Una vez escocido el servicio y encontrado el proveedor, permiten pedir e

instanciar el objeto que debe proporcionar el servicio.

1.4.1.2. Estándares de los Servicios Web

XML: (Lenguaje de Marcado eXtensible) Es un formato universal para

representar los datos. XML-RPC: son protocolos sobre los que se establece

el intercambio.

Los Servicios Web se basan en XML para estructurar la información, lo que

permite:

o Homogeneidad para facilitar la comprensión de las máquinas

o Diferentes plataformas / marcos de trabajo

WSDL: (Lenguaje de Descripción de Servicios Web) Lenguaje por medio del

cual un servicio Web describe entre otras cosas qué hace o qué

funcionalidad implementa.

Es el lenguaje de la interfaz pública para los servicios Web. Es una

descripción basada en XML de los requisitos funcionales necesarios para

establecer una comunicación con los servicios Web.

SOAP: (Protocolo Simple de Acceso a Objetos) Es un protocolo que permite

mover los datos entre aplicaciones y sistemas. Es el mecanismo por medio

del cual los servicios Web son invocados e interactúan.

UDDI: (Descubrimiento, Descripción e Integración Universal) Lenguaje que

permite publicar, encontrar y usar los Servicios Web basados en XML. Es la

'Página Amarilla' de los servicios Web, es decir un directorio para poder

encontrarlos. Puede ser accedido con un explorador en http://www.uddi.org

o programáticamente.

WS-Security: Protocolo de seguridad aceptado como estándar por OASIS.

Garantiza la autenticación de los actores y la confidencialidad de los

mensajes enviados.

1.4.1.3. Ciclo de Vida de los Servicios Web

El ciclo de vida de los Servicios consiste en los siguientes 6 pasos

importantes, como muestra la figura.

Figura 8 Vocabulario XML

1. El ciclo se origina cuando las empresas se deciden a desarrollar y

exponer la funcionalidad de sus aplicaciones en forma de Servicio

Web.

2. Una vez que los Servicios Web se han desarrollado, deben ser

registrados en un nodo UDDI para poder ser localizado por los

potenciales usuarios. En dicho registro se aportaran datos sobre la

empresa, los Servicios Web que se ofrecen etc. y también la

descripción de las interfaces de uso de cada Servicio Web (WSDL).

Cuando algún consumidor solicite dicho Servicio Web, el servidor UDDI

le redirigirá a la URI proporcionada por el fabricante.

3. Los posibles consumidores (proveedores, clientes, socios...) se

conectan al servidor UDDI para buscar los Servicios Web que les

interesan.

4. Una vez que encuentran el Servicio Web que desean, obtienen la

descripción de sus interfaces de uso (WSDL).

5. Gracias a la descripción de las interfaces de uso, los consumidores son

capaces de elaborar paquetes SOAP para comunicarse con el

proveedor del Servicio Web.

6. El proveedor del Servicio Web elabora un paquete SOAP como

respuesta a la petición del consumidor del Servicio Web.

Para esta tecnología, se requiere de tres entidades participantes:

Figura 9 Vocabulario XML

a) El Proveedor

Anuncia sus servicios con un Agente, cuando un Solicitante busca en un

Agente un servicio, encuentra al Proveedor y establece el enlace para

hacer uso de los servicios, como muestra la figura siguiente:

b) El Proveedor

Construye el Servicio con el lenguaje y el Middleware necesario. Define

la Descripción del Servicio que incluye, con un documento escrito con

Servicios WEB Description Language (WDSL):

o Las prestaciones.

o La utilización del servicio por terceros.

o La localización

c) Publica

La oferta del servicio en las páginas amarillas del Universal Description,

Discovery and Integration (UDDI). El fabricante también puede

encontrar aquí otros servicios ya creados que le faciliten su trabajo. La

Agenda UDDI fue creada en septiembre de 2000 por IBM, Ariba y

Microsoft y posteriormente se sumaron otros actores como Compaq y

SAP.

El usuario final, conocido como el solicitante, localiza y enlaza el servicio

WEB a través de SOAP (Simple Object Access Protocol) mediante un

Figura 10 Servicios Web

mecanismo de tipo RPC sobre el protocolo HTTP y un intercambio de

mensajes XML.

El objetivo final de los servicios web es la creación de directorios en

línea que puedan ser localizados de un modo sencillo con un alto nivel

de fiabilidad. XML es utilizado para etiquetar los datos, SOAP es usado

para transferir los datos, WDSL es utilizado para describir los servicios

disponibles y UDDI es usado para listar qué servicios están disponibles.

1.4.1.4. Arquitectura de los Servicios Web

La arquitectura se basa en los siguientes componentes:

a) Marco de Mensajería

Simple SOAP: Simple Object Access Protocol permite intercambiar

información estructurada en un ambiente descentralizado y distribuido.

"Messaging Framework" define, usando tecnologías XML, un marco

extensible de mensajería que contiene una construcción del mensaje

que se pueda intercambiar con una variedad de protocolos subyacentes.

Web Services Addressing (WS-Addressing): Direccionamiento de

Servicios Web. La dirección de los servicios Web proporciona

mecanismos neutrales para transportar los servicios web y los

mensajes. Define un sistema de características abstractas y una

representación de XML para referirse a servicios de la Web y para

facilitar la dirección final de los mensajes. Esta especificación permite a

los sistemas de mensajería soportar la transmisión del mensaje a través

de redes que incluyen el procesado de nodos tales como gestión final,

cortafuegos y pasarelas mediante una forma de transporte neutro.

SOAP Message Transmission Optimization (MTOM): Descripción

de la Optimización de la Transmisión del Mensaje. Describe una

característica abstracta y una puesta en práctica concreta para

optimizar el formato de la transmisión y/o de la vía de los mensajes

SOAP.

b) Descripción de los servicios

Web Services Description Language (WSDL): Lenguaje de

Descripción de los Servicios Web. La especificación define el lenguaje

básico que puede usarse para describir servicios Web basados en un

modelo abstracto de lo que ofrece el servicio. También define los

criterios de conformidad de los documentos en relación a este lenguaje.

Web Services Choreography Description Language (WS-CDL):

Lenguaje de Descripción de la Coreografía de los Servicios Web. Es un

lenguaje basado en XML que describe colaboraciones peer to peer de

los participantes definiendo, desde un punto de vista global, un

comportamiento observable común y complementario; donde ordenado

el mensaje, intercambia el resultado de acuerdo a un objetivo de

negocios común.

Los servicios web que se basan en XML permiten que las aplicaciones

compartan información y que además invoquen funciones de otras

aplicaciones independientemente de cómo se hayan creado dichas

aplicaciones e independientemente del sistema operativo o plataforma

en que se ejecuten y de los dispositivos utilizados en el acceso.

1.4.1.5. Dispositivos Móviles y Servicios Web

La convergencia entre los dispositivos móviles y los servicios de la red

Internet, aunque prevista, teorizada y resuelta técnicamente desde finales

del siglo pasado, se ha venido retrasando por diversas causas hasta,

bruscamente, acelerarse y consolidarse irremediablemente a partir de

finales del año 2007. Aspectos comerciales, con la entrada de nuevos

actores y estrategias al mundo de la comunicación telefónica; de uso y

necesidad social, como la comunicación audiovisual personalizada; o de la

utilización popular de nuevas aplicaciones red, como la localización

geográfica, por ejemplo, coadyuvan a ello. Sin embargo, aun compartiendo

muchos aspectos comunicativos y técnicos con la denominada web 2.0, los

dispositivos móviles y su uso personalizado, contextual y ubicuo poseen

especificidades comunicativas que apenas se empiezan a apuntar en estos

nuevos usos cotidianos.

La creación y el Consumo de Contenidos

En tanto que dispositivos tecnológicos convergentes, tanto por lógicas

derivadas del propio desarrollo de la tecnología como meramente

comerciales entre fabricantes, se han incrementado las herramientas de

producción de contenidos por parte del usuario: limitados en cuanto

tamaño y operatividad del teclado, han permitido sin embargo, a través de

una cámara cada vez más mayor calidad de fotografía y vídeo y de recursos

simples de edición, junto con diversos puertos de comunicaciones

(infrarrojos o bluetooth) una verdadera producción audiovisual en un

contexto personalizado del “aquí y ahora”. Se trata de un uso de la

tecnología muy personal, además de ampliar la experiencia comunicativa y

de entretenimiento, ha coadyuvado, por otra parte, a la transformación de

los contenidos de los media tradicionales.

Por tanto la web 2.0 móvil se convierte en impulsora de una nueva

convergencia digital, añadida a la del escritorio y sin contradicción alguna

con ésta, puesto que se ejerce a través de las sinergias entre aplicaciones

móviles en red.

1.4.2. Arquitectura Orientada a Servicios

La Arquitectura Orientada a Servicios (Service-Oriented Architecture, SOA) es

un concepto de arquitectura de software que define la utilización de servicios

como construcciones básicas para el desarrollo de aplicaciones. Es una

arquitectura de una aplicación donde las funcionalidades se definen como

servicios independientes, con interfaces invocadas bien definidas, que pueden

ser llamadas en secuencias dadas para formar procesos de negocios.

a) Ventajas de una arquitectura orientada a servicios

Una estrategia de aplicaciones empresariales debe facilitar su

integración.

Exponer procesos de negocio como servicios es la clave a la flexibilidad

de la arquitectura. Esto permite que otras piezas de funcionalidad

(incluso también implementadas como servicios) hagan uso de otros

servicios de manera natural, sin importar su ubicación física.

Así un sistema evoluciona con la adición de nuevos servicios y su

mejoramiento, y donde cada servicio evoluciona de una manera

independiente. La Arquitectura Orientada a Servicios (SOA) resultante,

define los servicios de los cuales estará compuesto el sistema, sus

interacciones, y con qué tecnologías serán implementados. Las

interfaces que utiliza cada servicio para exponer su funcionalidad son

gobernadas por contratos, que definen claramente el conjunto de

mensajes soportados, su contenido y las políticas aplicables.

1.4.2.1. Elementos de SOA

Los componentes de una Arquitectura Orientada a Servicios son:

o Repositorio de Servicios

o Bus de servicios

o Consumidores

o Servidores

- Servidores

Un servicio de negocio es un componente reutilizable de software, con

significado funcional completo, y que está compuesto por:

o Contrato: especificación de la finalidad, funcionalidad, forma de uso

y restricciones del servicio.

o Interfaz: mecanismo de exposición del servicio a los usuarios.

o Implementación: debe contener la lógica o el acceso a datos.

Repositorio de Servicios

Bus de servicios

Consumidores

Servidores

Figura 11 Elementos de SOA

Tipos de servicios.- pueden existir varios tipos de servicios, según su

finalidad

o Servicios básicos: pueden estar centrados en datos o en lógica y

encapsulan funcionalidades como cálculos complejos, acceso a

datos y reglas complejas de negocio.

o Servicios intermediarios: servicios adaptadores, façades, etc.

o Servicios de proceso: servicios de negocio que encapsulan la lógica

de proceso. Pueden residir en herramientas BPM.

o Servicios públicos: servicios accesibles por terceros (fuera de la

organización)

- Repositorio de Servicios

Un repositorio de servicios proporciona facilidades para descubrir servicios

y adquirir la información necesaria para su uso, en particular fuera del

alcance temporal y funcional del proyecto en el que se crearon.

Además de la propia información de contrato, los repositorios pueden

proporcionar información acerca de:

o Localización.

o Personas de contacto.

o Restricciones técnicas.

o Service Level Agreements (SLAs). Acuerdos de Nivel de Servicio.

Servicio

Contrato

Implementación

Lógica

Datos

Interfaz

Grafico 12 Elementos de SOA - Servidores

- Bus de Servicios

La intersección de la arquitectura orientada a servicios con la integración

de aplicaciones y el modelado de procesos de negocio, dan lugar a un

nuevo producto de nominado bus de servicios conocido también como ESB

(Enterprise Service Bus- Bus Empresarial de Servicios).

El ESB es un elemento de software, un middleware, una infraestructura

basada en estándares, que proporciona servicios para la construcción de

arquitecturas más complejas basadas en eventos y en un motor de

mensajería (el BUS).

El bus de servicios es el elemento de las arquitecturas SOA que conecta los

servicios con sus consumidores y que proporciona:

Conectividad: el propósito principal de un bus de servicios es

interconectar a los participantes de una arquitectura SOA.

Soporte a la heterogeneidad de tecnologías: debe ser capaz de

conectar a participantes basados en distintos lenguajes de

programación, sistemas operativos, entornos de ejecución y

protocolos de comunicación.

Soporte a la heterogeneidad de paradigmas de

comunicación: debe ser capaz de mantener distintos modos de

comunicación (por ejemplo comunicaciones síncronas y asíncronas).

Grafico 13 Elementos de SOA – Repositorio de Servicios

El ESB permite la integración de aplicaciones de forma rápida, directa y

basada en estándares. Es una suite de productos independientes de la

infraestructura de facilita el procesado, la transformación de datos, el

enrutamiento y la orquestación de procesos usando Servicios Web.

1.5. Objetivo

1.5.1. Objetivo General

El objetivo principal de este proyecto de investigación proveer una solución

que respalde esta nueva opción para la salud de las mascotas mediante la

creación de la póliza de seguro. También la Interconexión entre las clínicas

veterinarias asociadas, para poder llevar la información centralizada de la

mascota y generación de reportes de control e indicadores para la clínica

veterinaria “El Trigal”.

1.5.2. Objetivo Especifico

Grafico 14 Elementos de SOA – Bus de Servicios

1. Recopilar la información existente sobre la Solución de SOA a través de

los años, consultar medios bibliográficos y así obtener las definiciones,

antecedentes, su evolución, bases teóricas y casos de aplicación.

2. Plantear cuál es la metodología adecuada para la gestión de la solución

de SOA y desarrollar el plan del proyecto.

3. Desarrollar un comparativo entre las diferentes herramientas de SOA,

elegir la herramienta adecuada para implementar el proyecto en la

Clínica Veterinaria “El Trigal” y describir sus características y

funcionalidad.

4. Generación de reportes de control e indicadores para la clínica

veterinaria “El Trigal”

a. Indicador 1: Nro. De enfermedades por mes y tipo de

enfermedad.

b. Indicador 2: Nro. De consultas al mes.

c. Indicador 3: Nro. De atenciones realizadas al mes.

d. Indicador 4: Nro. De historias clínicas generadas.

1.6. Importancia

1.6.1. Justificación Académica

Aplicar los conocimientos adquiridos sobre Servicios Web para desarrollar

un aplicativo que permita sostener el nicho de mercado que la clinica

veterinaria ha logrado identificar.

1.6.2. Beneficios Tangibles

- Información actualizada y agilizada

- Generación de reportes

1.6.3. Beneficios Intangibles

- Buen servicio

- Buena imagen de la institución

- Satisfacción de los clientes

- Control adecuado de la Información

1.7. Alcance

▪ Se seguirá la metodología RUP en el desarrollo del sistema

▪ Él se realizara el modelado teniendo en cuenta el UML

▪ Se modelara los CUS

▪ Se realizara el análisis del sistema

▪ Se realizara el diseño del sistema

▪ El desarrollo se realizara en ASP.

▪ La arquitectura será WCF

▪ Se utilizara un motor de base de datos.

▪ No se integrara con otros aplicativos de la clínica veterinaria.

▪ El sistema permitirá el registro de los datos de cada una de las

mascotas.

▪ La interfaz esta en lenguaje español.

▪ Se implementará el aplicativo web y móvil como piloto en 1 clínica

veterinaria.

▪ Se utilizará el protocolo SOAP para el servicio web

▪ Se implementará mensajes de correo como alertas.

2. Modelado del Negocio

2.1. Actores de Negocio

Gerente General: es el dueño de la clínica veterinaria.

Medico Veterinario: es el médico de la clínica veterinaria.

Cliente: es el dueño de la mascota asegurada.

2.2. Diagrama de caso de uso del Negocio

Administrar Póliza: En este Caso de Uso del Negocio se encuentra el proceso de la generación de la póliza de seguro para la mascota, donde envía la información de esta para su seguimiento.

Administrar Información: En este Caso de Uso de Negocio se encuentra el proceso en el cual se administra la información propiamente de la empresa como pueden ser cliente, proveedores, mascotas, documentación, reportes, etc.

Administrar Citas: En este Caso de Uso de Negocio se encuentra el proceso del registro de la cita médica de la mascota, así como el cronograma de citas registradas.

3. Requerimientos del Proyecto

3.1. Requerimientos Funcionales

Nombre del Requisito: Generar PólizaDescripción El usuario ingresara los datos necesarios para el registro de la

póliza.

Nombre del Requisito: Registrar Cita MedicaDescripción El usuario ingresara los datos necesarios para el registro de la

cita.

Nombre del Requisito: Generar ReportesDescripción El usuario ingresara consultara los reportes que desea solicitar.

Nombre del Requisito: Consultar CronogramasDescripción El usuario podrá consultar sus cronogramas de pagos, así como

el cronograma de citas y vacunas de la mascota.

3.2. Requerimientos No Funcionales

Nombre Disponibilidad

Descripción

El sistema deberá estar disponible el 98% de las 24 horas que representan al día.

Nombre Escalabilidad

Descripción

El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental, de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados afectando el código existente de la menor manera posible; para ello deben incorporarse aspectos de reutilización de componentes.

El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción y puesta en marcha inicial.

Nombre Seguridad

DescripciónEl sistema contará con claves encriptados y sistemas de autenticación a través de cuentas de Usuario. Además de hacer comparaciones de data para evitar cualquier fraude de terceros en la manipulación directa de la base de datos Se concluye que el sistema es totalmente seguro.

Nombre Mantenibilidad

DescripciónToda el sistema deberá estar complemente documentado, cada

uno de los componentes de software que forman parte de la

solución propuesta deberán estar debidamente documentados

tanto en el código fuente como en los manuales de

administración y de usuario.

El sistema debe contar con una interfaz de administración que

incluya: Administración de usuarios.

El sistema debe estar en capacidad de permitir en el futuro su

fácil mantenimiento con respecto a los posibles errores que se

puedan presentar durante la operación del sistema.

Nombre Flexibilidad

DescripciónEl sistema debe ser diseñado y construido con los mayores

niveles de flexibilidad en cuanto a la parametrización de los

tipos de datos, de tal manera que la administración del sistema

sea realizada por un administrador funcional del sistema.

3.3. Diagrama de Actores del Sistema

Gerente General: es la persona encargada administración general del sistema, así como los permisos de esta.

Médico Veterinario: es la persona encargada del registro de las pólizas para las mascotas, así como dar seguimiento a la mascota.

Cliente: es la persona que solicita la póliza para su mascota.

Administrador del Sistema: es la persona encargada de la administración del sistema, así como dar soporte a la información de la clínica.

3.4. Definición de casos de uso del Sistema

Especificación de caso de uso: Validar Usuario

Nombre del Caso de Uso del Sistema :

Validar Usuario

Descripción :

Este caso de uso se encargará de validar la existencia del usuario dentro del negocio.

Actores: Usuario

Pre- condiciones:

No existe pre-condición en este caso de uso

Flujo Normal

Acción de los Actores Respuesta del Sistema

1. El usuario Web ejecuta el aplicativo del sistema.

3. El Usuario Web Ingresa su usuario y contraseña.

2. El sistema muestra la pantalla del Login, el cual le pide que ingrese su usuario y contraseña.

1. EL Sistema verifica los datos ingresados y le permite ingresar a la página principal.

Post Condiciones: El usuario ingresará al sistema para hacer uso del aplicativo.

Especificación de caso de uso: Mantener Cliente


Mantener Cliente

Descripción :

Este caso de uso se encargará registrar nuevos clientes de la clínica veterinaria.

Actores: Usuario

Pre- condiciones:

1. El usuario debe haber ingresado al sistema

Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Cliente.

3. El usuario presiona el botón de “Nuevo Cliente”.

5. El usuario ingresa los datos necesarios para el registro.

2. El sistema muestra la pantalla de Mantener Cliente con la grilla de clientes registrados (en caso existan).

4. El sistema carga una ventana popup donde se ingresaran los datos necesarios para el registro.

6. El sistema validara los datos ingresados y registrara el cliente si todo esta correcto.

Flujo Alterno

1. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos del cliente, modificara los datos necesario y procederá a guardar.

2. En caso el usuario requiera eliminar algún registro, seleccionara el registro y confirmara la eliminación y se actualizara la grilla con los nuevos datos.

Post Condiciones: Se visualizará la grilla con los nuevos datos.

Especificación de caso de uso: Mantener Plan


Mantener Plan

Descripción :

Este caso de uso se encargará registrar nuevos planes de seguros de la clínica veterinaria.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Plan.

3. El usuario presiona el botón de “Nuevo Plan”.


2. El sistema muestra la pantalla de Mantener Plan con la grilla de planes registrados (en caso existan).


6. El sistema validara los datos ingresados y registrara el plan si todo esta correcto.

Flujo Alterno

3. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos del plan, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Mantener Raza


Mantener Raza

Descripción :

Este caso de uso se encargará registrar nuevas razas.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Raza.

3. El usuario presiona el botón de “Nueva Raza”.


2. El sistema muestra la pantalla de Mantener Raza con la grilla de razas registradas (en caso existan).


6. El sistema validara los datos ingresados y registrara la raza si todo esta correcto.

Flujo Alterno

5. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos de la raza, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Mantener Enfermedad


Mantener Enfermedad

Descripción :

Este caso de uso se encargará registrar nuevas enfermedades.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Enfermedad.

2. El usuario presiona el botón de “Nueva Enfermedad”.


2. El sistema muestra la pantalla de Mantener Enfermedad con la grilla de enfermedades registradas (en caso existan).


6. El sistema validara los datos ingresados y registrara la enfermedad si todo esta correcto.

Flujo Alterno

1. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos de la enfermedad, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Mantener Tipo de Enfermedad


Mantener Tipo de Enfermedad

Descripción :

Este caso de uso se encargará registrar nuevos tipos de enfermedad.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Tipo de Enfermedad.

3. El usuario presiona el botón de “Nuevo Tipo”.


2. El sistema muestra la pantalla de Mantener Tipo de Enfermedad con la grilla de tipo de enfermedad registrados (en caso existan).


6. El sistema validara los datos ingresados y registrara el tipo de enfermedad si todo esta correcto.

Flujo Alterno

1. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos del tipo de enfermedad, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Mantener Perfil


Mantener Perfil

Descripción :

Este caso de uso se encargará registrar nuevos perfiles de la clínica veterinaria.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Perfil.

3. El usuario presiona el botón de “Nuevo Perfil”.


2. El sistema muestra la pantalla de Mantener Perfil con la grilla de perfiles registrados (en caso existan).


6. El sistema validara los datos ingresados y registrara el perfil si todo esta correcto.

Flujo Alterno

1. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos del perfil, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Mantener Clínica Veterinaria


Mantener Clínica Veterinaria

Descripción :

Este caso de uso se encargará registrar nuevas clínicas veterinarias.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Clínica Veterinaria.

3. El usuario presiona el botón de “Nueva Clínica”.


2. El sistema muestra la pantalla de Mantener Clínica Veterinaria con la grilla de clínicas registradas (en caso existan).


6. El sistema validara los datos ingresados y registrara la clínica si todo esta correcto.

Flujo Alterno

1. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos de la clínica, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Mantener Médico


Mantener Perfil

Descripción :

Este caso de uso se encargará registrar nuevos médicos.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Medico.

3. El usuario presiona el botón de “Nuevo Medico”.


2. El sistema muestra la pantalla de Mantener Medico con la grilla de médicos registradas (en caso existan).


6. El sistema validara los datos ingresados y registrara el médico si todo esta correcto.

Flujo Alterno

1. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos del médico, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Mantener Póliza


Mantener Póliza

Descripción :

Este caso de uso se encargará registrar nuevas pólizas.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Mantener Póliza.

3. El usuario presiona el botón de “Nueva Póliza”.

5. El usuario buscara el cliente para el registro de la póliza.

7. El usuario seleccionara el cliente, luego ingresara los datos de la mascota y seleccionara el modo de pago.

9. El usuario procederá a registrar la póliza, previamente aceptando los términos y condiciones.

2. El sistema muestra la pantalla de Mantener Póliza con la grilla de pólizas registradas (en caso existan).


6. El sistema mostrara la lista de clientes en el sistema.

8. El sistema mostrara las cuotas y montos de pago.

10. El sistema validara los datos ingresados y registrara la póliza si todo esta correcto.

Flujo Alterno

1. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos de la póliza, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Enviar Promoción


Enviar Promoción

Descripción :

Este caso de uso se encargará de enviar promociones de la clínica.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Enviar Promoción.

3. El usuario presiona el botón de “Nueva Promoción”.

5. El usuario ingresa los datos necesarios para el envío de la promoción.

2. El sistema muestra la pantalla de Enviar Promoción con la grilla de promociones enviadas (en caso existan).


6. El sistema validara los datos ingresados y registrara la promoción e enviara un mail a todos los clientes.


Especificación de caso de uso: Enviar Mail de Alerta de Próxima Vacuna.


Enviar Mail de Alerta de Próxima Vacuna

Descripción :

Este caso de uso se encargará enviar un mail de alerta a los clientes, para comunicarles que la siguiente vacuna de su mascota está por llegar.

Actores: Usuario

Pre- condiciones:

Flujo Normal


1. El sistema validara las fechas próximas de las vacunas de las mascotas para enviar un mail de alerta a los clientes.


Especificación de caso de uso: Enviar Mail de Alerta de Próxima Cuota.


Enviar Mail de Alerta de Próxima Cuota

Descripción :

Este caso de uso se encargará enviar un mail de alerta a los clientes, para comunicarles que su siguiente cuota a pagar esta por vencer.

Actores: Usuario

Pre- condiciones:

Flujo Normal


1. El sistema validara las fechas próximas de cuotas de los clientes para enviarles un mail de alerta que ya va a vencer.


Especificación de caso de uso: Consultar Reporte


Mantener Perfil

Descripción :

Este caso de uso se encargará de consultar reportes de acuerdo al tipo que seleccionemos.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Consultar Reporte.

3. El usuario seleccionara el reporte a consultar.

5. El usuario ingresa los datos necesarios para la consulta del reporte.

2. El sistema muestra la pantalla de Consultar Reporte con la lista de opciones de los reportes a consultar.

4. El sistema mostrara los filtros necesarios para poder consultar el reporte seleccionado (en caso tenga filtros).

6. El sistema validara los datos ingresados y realizara la consulta.

Flujo Alterno

1. Si el usuario desea exportar a PDF o Excel presionara el botón de “Exportar a PDF” o “Exportar a Excel”.

Post Condiciones: Se visualizará la grilla con el resultado de la consulta.

Especificación de caso de uso: Consultar Información de la Mascota


Consultar Información de la Mascota

Descripción :

Este caso de uso se encargará registrar nuevos médicos.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Consultar Datos de la Mascota.

3. El usuario ingresara el código de la mascota y presionara el botón “Consultar Información”.

2. El sistema muestra la pantalla de Consultar Datos de la mascota.

4. El sistema mostrara la información de la mascota.

Flujo Alterno


Post Condiciones: Se visualizará la grilla con el resultado de la consulta.

Especificación de caso de uso: Reservar Cita Medica


Mantener Reservar Cita Medica

Descripción :

Este caso de uso se encargará registrar una cita médica para la mascota.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Registrar Cita Medica.

3. El usuario presiona el botón de “Nueva Cita”.


2. El sistema muestra la pantalla de Registrar Cita Medica con la grilla de citas registradas (en caso existan).


6. El sistema validara los datos ingresados y registrara la cita si todo esta correcto.

Flujo Alterno

1. Si el usuario necesita actualizar algún registro, seleccionara un registro de la grilla y aparecerá una ventana popup con los datos de la cita, modificara los datos necesario y procederá a guardar.



Especificación de caso de uso: Consultar Cronograma de Citas y Vacunas


Consultar Cronograma de Citas y Vacunas

Descripción :

Este caso de uso se encargará registrar una cita médica para la mascota.

Actores: Usuario

Pre- condiciones:


Flujo Normal


1. El usuario selecciona en el menú la opción de Consultar Cronograma de Citas y Vacunas.

3. El usuario selecciona la mascota de quien desea consultar el cronograma y presiona el botón “Consultar”

2. El sistema muestra la pantalla de Consultar Cronograma de Citas y Vacunas, y la grilla con las mascotas del usuario.

4. El sistema carga una ventana popup con el cronograma de citas y vacunas de la mascota seleccionada.

Flujo Alterno



3.5. Modelo Conceptual

C_Usuario

+Nombre+Usuario

C_Perfil

+Nombre+Descripcion

C_Raza

+Nombre+Descripcion

C_Persona

+Nombre+Apellido_Paterno+Apellido_Materno+Nro_Doc+Fecha_Nac

C_PLan

+Nombre+Descripcion+Precio

C_Enfermedad

+Nombre+Descripcion

C_Tipo_Enfermedad

+Nombre+Descripcion

C_Clinica_Veterinaria

+Nombre+Direccion+RUC

C_Poliza

+Fecha_Creacion

C_Mascota

+Nombre+Codigo+Fecha_Nac

C_Cita

+Fecha_Cita+Hora_Cita

C_Vacuna

+Fecha_Vacuna

C_Cuota

+Nro_Cuotas+Fecha_Pago_Cuota

3.6. Diagrama de Secuencia

3.6.1. Validar Usuario

: Usuario

: I_Login : I_Pagina_Principal : C_Validar_Usuario : M_Usuario : M_Menu

1 : Ingresar Usuario y Clave()

2 : Solicita datos de usuario()

3 : Solicita datos de usuario()

4 : Devuelve datos encontrados()

5 : Muestra Principal.aspx()

6 : Solicita mostrar menu()

7 : Solicita mostrar menu()

8 : Devuelve Menu()9 : Mestra lista Menu()

3.6.2. Mantener Póliza

: Usuario

I_Pagina_Principal I_Mantener_Poliza C_Cliente M_ClienteC_Raza M_RazaC_Plan M_PlanC_Poliza M_Poliza

1 : Selecciona "Mantener Poliza"()

2 : Ingresa interface "Mantener Poliza"()3 : Consultar Razas()

4 : Consultar Razas()

5 : Devuelve lista de razas()6 : Muestra lista de razas()

7 : Presiona boton "Nueva Poliza"()

8 : Presiona boton "Buscar Cliente"()

9 : Buscar Cliente()

10 : Buscar Cliente()

11 : Devuelve lista de clientes()

12 : Muestra lista de clientes()

13 : Selecciona Cliente()

14 : Ingresa datos mascota()

15 : Selecciona Plan de Seguro()

16 : Consultar informacion del plan()

17 : Consultar informacion del plan()

18 : Devuelve informacion del plan()

19 : Muestra informacion del plan()

20 : Selecciona modo de pago()

21 : Consultar plan de cuotas()22 : Consultar plan de cuotas()

23 : Devuelve plan de cuotas()

24 : Muestra plan de cuotas()

25 : Presiona Guardar Poliza()

26 : Guardar Poliza()27 : Guardar Poliza()

28 : Devuelve Resultado()

29 : Muestra Resultado()

3.6.3. Reservar Cita Medica

: Usuario

I_Pagina_Principal I_Registrar_Cita_MEdica C_Cita M_Cita

1 : Selecciona "Registrar Cita Medica"()

2 : Ingresa Interface Registrar Cita Medica()3 : Consultar Citas()

4 : Consultar Citas()

5 : Devuelve Citas Medicas()

6 : Muestra Citas Medicas()

7 : Presiona boton "Nueva Cita"()

8 : Ingresa Datos()

9 : Registra Datos()

10 : Registra Datos()

3.7. Benchmarking

3.8. Prototipos

3.8.1. Registrar Póliza

3.8.2. Reservar Cita Medica

3.9. Matriz de Requerimientos de Negocio vs Funcionales

estructura de la tesis v05.docx

Documents