estructura de la tesis v05.docx
TRANSCRIPT
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
Figura 2 Ejemplo de clase
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 3 Ejemplo de clase
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
Nombre del Caso de Uso del Sistema :
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
Acción de los Actores Respuesta del Sistema
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
Nombre del Caso de Uso del Sistema :
Mantener Plan
Descripción :
Este caso de uso se encargará registrar nuevos planes de seguros de la clínica veterinaria.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
1. El usuario selecciona en el menú la opción de Mantener Plan.
3. El usuario presiona el botón de “Nuevo Plan”.
5. El usuario ingresa los datos necesarios para el registro.
2. El sistema muestra la pantalla de Mantener Plan con la grilla de planes 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 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.
4. 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 Raza
Nombre del Caso de Uso del Sistema :
Mantener Raza
Descripción :
Este caso de uso se encargará registrar nuevas razas.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
1. El usuario selecciona en el menú la opción de Mantener Raza.
3. El usuario presiona el botón de “Nueva Raza”.
5. El usuario ingresa los datos necesarios para el registro.
2. El sistema muestra la pantalla de Mantener Raza con la grilla de razas registradas (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 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.
6. 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 Enfermedad
Nombre del Caso de Uso del Sistema :
Mantener Enfermedad
Descripción :
Este caso de uso se encargará registrar nuevas enfermedades.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
1. El usuario selecciona en el menú la opción de Mantener Enfermedad.
2. El usuario presiona el botón de “Nueva Enfermedad”.
5. El usuario ingresa los datos necesarios para el registro.
2. El sistema muestra la pantalla de Mantener Enfermedad con la grilla de enfermedades registradas (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 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.
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 Tipo de Enfermedad
Nombre del Caso de Uso del Sistema :
Mantener Tipo de Enfermedad
Descripción :
Este caso de uso se encargará registrar nuevos tipos de enfermedad.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
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”.
5. El usuario ingresa los datos necesarios para el registro.
2. El sistema muestra la pantalla de Mantener Tipo de Enfermedad con la grilla de tipo de enfermedad 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 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.
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 Perfil
Nombre del Caso de Uso del Sistema :
Mantener Perfil
Descripción :
Este caso de uso se encargará registrar nuevos perfiles de la clínica veterinaria.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
1. El usuario selecciona en el menú la opción de Mantener Perfil.
3. El usuario presiona el botón de “Nuevo Perfil”.
5. El usuario ingresa los datos necesarios para el registro.
2. El sistema muestra la pantalla de Mantener Perfil con la grilla de perfiles 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 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.
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 Clínica Veterinaria
Nombre del Caso de Uso del Sistema :
Mantener Clínica Veterinaria
Descripción :
Este caso de uso se encargará registrar nuevas clínicas veterinarias.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
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”.
5. El usuario ingresa los datos necesarios para el registro.
2. El sistema muestra la pantalla de Mantener Clínica Veterinaria con la grilla de clínicas registradas (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 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.
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 Médico
Nombre del Caso de Uso del Sistema :
Mantener Perfil
Descripción :
Este caso de uso se encargará registrar nuevos médicos.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
1. El usuario selecciona en el menú la opción de Mantener Medico.
3. El usuario presiona el botón de “Nuevo Medico”.
5. El usuario ingresa los datos necesarios para el registro.
2. El sistema muestra la pantalla de Mantener Medico con la grilla de médicos registradas (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 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.
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 Póliza
Nombre del Caso de Uso del Sistema :
Mantener Póliza
Descripción :
Este caso de uso se encargará registrar nuevas pólizas.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
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).
4. El sistema carga una ventana popup donde se ingresaran los datos necesarios para el registro.
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.
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: Enviar Promoción
Nombre del Caso de Uso del Sistema :
Enviar Promoción
Descripción :
Este caso de uso se encargará de enviar promociones de la clínica.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
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).
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 la promoción e enviara un mail a todos los clientes.
Post Condiciones: Se visualizará la grilla con los nuevos datos.
Especificación de caso de uso: Enviar Mail de Alerta de Próxima Vacuna.
Nombre del Caso de Uso del Sistema :
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
Acción de los Actores Respuesta del Sistema
1. El sistema validara las fechas próximas de las vacunas de las mascotas para enviar un mail de alerta a los clientes.
Post Condiciones: Se visualizará la grilla con los nuevos datos.
Especificación de caso de uso: Enviar Mail de Alerta de Próxima Cuota.
Nombre del Caso de Uso del Sistema :
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
Acción de los Actores Respuesta del Sistema
1. El sistema validara las fechas próximas de cuotas de los clientes para enviarles un mail de alerta que ya va a vencer.
Post Condiciones: Se visualizará la grilla con los nuevos datos.
Especificación de caso de uso: Consultar Reporte
Nombre del Caso de Uso del Sistema :
Mantener Perfil
Descripción :
Este caso de uso se encargará de consultar reportes de acuerdo al tipo que seleccionemos.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
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
Nombre del Caso de Uso del Sistema :
Consultar Información de la Mascota
Descripción :
Este caso de uso se encargará registrar nuevos médicos.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
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
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: Reservar Cita Medica
Nombre del Caso de Uso del Sistema :
Mantener Reservar Cita Medica
Descripción :
Este caso de uso se encargará registrar una cita médica para la mascota.
Actores: Usuario
Pre- condiciones:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
1. El usuario selecciona en el menú la opción de Registrar Cita Medica.
3. El usuario presiona el botón de “Nueva Cita”.
5. El usuario ingresa los datos necesarios para el registro.
2. El sistema muestra la pantalla de Registrar Cita Medica con la grilla de citas registradas (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 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.
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: Consultar Cronograma de Citas y Vacunas
Nombre del Caso de Uso del Sistema :
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:
1. El usuario debe haber ingresado al sistema
Flujo Normal
Acción de los Actores Respuesta del Sistema
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
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 los nuevos datos.
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