Plan de Tesis Saldaña Valqui, Edwin I. DATOS GENERALES 1.TITULO “APLICACIÓN DE TECNOLOGIA WEB PARA LA GESTION DE ADMISION A CONSULTORIOS EXTERNOS DE PACIENTES DEL HOSPITAL VICTOR RAMOS GUARDIA DE HUARAZ APLICANDO METODOLOGIA ICONIX”. 2.AUTOR SALDAÑA VALQUI, EDWIN JOHN 3.ASESOR Ing. VIGO PEREYRA, LILIANA PATRICIA 4. TIPO DE INVESTIGACION APLICADA 5. REGIMEN DE INVESTIGACION LIBRE y ORIENTADA. (Atiende los intereses del Investigador y de la Institución) 6. INSTITUCION / LOCALIDAD 1
Transcript
Plan de Tesis Saldaña Valqui, Edwin
I. DATOS GENERALES
1. TITULO
“APLICACIÓN DE TECNOLOGIA WEB PARA LA GESTION DE ADMISION
A CONSULTORIOS EXTERNOS DE PACIENTES DEL HOSPITAL VICTOR
RAMOS GUARDIA DE HUARAZ APLICANDO METODOLOGIA ICONIX”.
2. AUTOR
SALDAÑA VALQUI, EDWIN JOHN
3. ASESOR
Ing. VIGO PEREYRA, LILIANA PATRICIA
4. TIPO DE INVESTIGACION
APLICADA
5. REGIMEN DE INVESTIGACION
LIBRE y ORIENTADA. (Atiende los intereses del Investigador y de la Institución)
6. INSTITUCION / LOCALIDAD
Localidad: Huaraz – Ancash
Empresa: Hospital Víctor Ramos Guardia
1
Plan de Tesis Saldaña Valqui, Edwin
7. DURACION DEL PROYECTO
Inicio: Abril 2011
Final: Julio 2011
Duración: 4 Meses
8. CRONOGRAMA DE ACTIVIDADES
Actividades Abril Mayo Junio Julio
Modelo dominio de la aplicación
Modelo de casos de uso
Análisis robusto
Diagramas de secuencias
Diagrama de clases
Elaboración de memoria de tesis
9. RECURSOS
Hardware Una computadora Intel Corel 2 Duo
Laptop
Impresora
Escáner
Software Rational Rose
Erwin
Sql Server 2008
Net Bean
Visio
MS Office
Internet
Otros Material de Escritorio: Papel, lapiceros,
impresiones, cartuchos de tinta, copias
2
Plan de Tesis Saldaña Valqui, Edwin
10. PRESUPUESTO
Costo del Proyecto Costo S/.
Personal
Servicio del Asesor
Servicio Tesista x 4 meses
S/. 1,000
S/. 5,000
Software
Licencia Sql Server 2008
Java
S/.12,000
Gastos Operativos:
Gastos en información (Libros, revistas, software, etc.)
Gastos Varios (Luz, papel, impresión, copias, tintas)
Gastos de Movilidad
S/. 200
S/. 700
S/. 500
11.FINANCIACION
Recursos propios
II. PLAN DE INVESTIGACION
1. EL PROBLEMA
La problemática del Hospital Víctor Ramos Guardia se centra más que todo en las área
de admisión, archivos y área del SIS, por eso nos centraremos mas en describir la
problemática de estas áreas.
En el área de admisión y Archivos existe una demora en los tiempos de atención a los
pacientes, porque el paciente tiene que estar pendiente de que su historia sea remitida al
consultorio respectivo para su atención, de lo contrario tiene que el mismo ir al área de
archivo averiguar el porqué no llega su historia al consultorio, debido que a veces la
historia no se encuentra ni en el área de archivo.
3
Plan de Tesis Saldaña Valqui, Edwin
Otro de los problemas es con los Pacientes SIS (Seguro Integral de Salud), estos
pacientes son atendido en la oficina del SIS, este tipo de pacientes tienen que madrugar
todos los días haciendo colas para alcanzar un cupo de atención en alguna especialidad,
luego tienen que hacer nuevamente colas en admisión para que sean registrados y le
puedan sacar su historia.
Los pacientes cuando se acercan a solicitar información acerca de los horarios de los
médicos, esta área de Admisión y SIS no cuentan con información actualizada y
oportuna acerca de los horarios de los médicos para brindar información real al
paciente.
1.1. FORMULACION DEL PROBLEMA
Como resolver el problema de las colas, madrugadas y falta de cupos para los
pacientes que necesitan pasar consultas, aplicando tecnología WEB. ?
2. HIPOTESIS
La Gestión de citas, es la mejor manera de brindar un mejor servicio, permitiendo de
esta manera generar mayor lealtad en sus pacientes y liberarlos de la pérdida de su
tiempo.
De esta forma se busca la comodidad de los pacientes y ahorrar tiempo en sus gestiones
diarias. Evitar largas colas, amanecidas y repetitivas llamadas para conseguir un cupo de
atención etc.
La gestión de citas permitiría a los pacientes seleccionar los servicios y/o consultorios
que desean atenderse, seleccionar y conocer el médico que se encuentre de turno, así
como la fecha y hora en la que desean pasar consulta, todo ello de acuerdo a los
parámetros y franjas horarias definidas por el hospital
4
Plan de Tesis Saldaña Valqui, Edwin
3. OBJETIVOS
3.1 OBJETIVOS GENERALES
Diseñar y desarrollar un Sistema de Gestión de Citas para la admisión de
pacientes a consultorios externos.
3.2 OBJETIVOS ESPECIFICOS
Determinar los requerimientos del Sistema.
Analizar y Diseñar el Sistema Informático Web utilizando la
metodología ágil ICONIX.
Elaborar el prototipo del Sistema Informático Web usando el IDE
NetBeans 6.9 (Java JSP) con el gestor de Bases de Datos SQL Server
2008.
Diseñar el modelo de la Base Datos en un Diagrama que muestre los
elementos de información y el modo en que se relacionan.
4 FUNDAMENTO TEORICO
4.1 LA ORGANIZACIÓN
El Hospital Víctor Ramos Guardia, está localizado en la ciudad de Huaraz Av.
Luzuriaga s/n provincia de Huaraz, departamento de Ancash. El hospital
obedece a los lineamientos dispuestos por el Ministerio de Salud para el
cumplimiento de los programas, tendientes a lograr la protección de la familia
además de ser apoyada por algunas ONG. Esta institución dedicada
principalmente a la atención de los pacientes que no cuentan con Seguro Social,
brindando servicios tales como: consultas, emergencias, hospitalización y una de
especialidades como laboratorio, rayos-x, cobaltoterapia, ecografías, banco
sangre, etc.
Una de las tareas más importantes se realiza en el departamento de Estadística,
ya que de ellos dependerá la rapidez con que el paciente será atendido. Esta área
atiende solo por Consultorios Externos un promedio de 250 personas en el turno
de mañana, de lunes a viernes desde 7.00am a 1.00 pm.
5
Plan de Tesis Saldaña Valqui, Edwin
4.2 LENGUAJE DE MODELAMIENTO UNIFICADO 2.0
(UML)
UML son las siglas para Unified Modeling Language que es un lenguaje gráfico
que cuenta con una sintaxis y una semántica visual para el modelamiento de
distintos aspectos del mundo real en un mejor entendimiento e interpretación y
que usa varias técnicas de modelado unificándola en una sola; en pocas palabras
permite especificar, visualizar, construir y documentar los elementos que forman
el desarrollo de un sistema software y no software. Se ha convertido en un
estándar de facto en la mayoría de los sectores de la industria, incluyendo las
finanzas, la militar y la ingeniería. Ya que el UML proviene de técnicas
orientadas a objetos, se crea con la fuerte intención de que este permita un
correcto modelado orientado a objetos.
Las raíces del UML provienen de tres métodos distintos. El método de Grady
Booch, la Técnica de Modelado de Objetos de James Rumbaugh y “Objetory”,
de Ivar Jacobson. Conocidas estas tres personalidades como “los tres amigos”.
En 1994 Booch, Rumbaugh y Jacobson dieron forma a la primera versión del
UML y en 1997 fue aceptado por la OMG1, fecha en la que fue lanzada la
versión v1.1 del UML. Desde entonces, UML atravesó varias revisiones y
refinamientos hasta llegar a la versión actual: UML 2.0.2
Figura N°. Evolución del UML (PAVON MESTRAS, 2004)
1
2
6
Plan de Tesis Saldaña Valqui, Edwin
4.3 APLICACIÓN WEB
Una Aplicación Web es un conjunto de páginas Web estáticas y dinámicas. Una
página Web estática es aquélla que no cambia cuando un usuario la solicita: el
servidor Web envía la página al navegador Web solicitante sin modificarla. Por
el contrario, el servidor modifica las páginas Web dinámicas antes de enviarlas
al navegador solicitante. La naturaleza cambiante de este tipo de página es la que
le da el nombre de dinámica.
Por ejemplo, podría diseñar una página para que mostrara los resultados del
programa de salud y dejara cierta información fuera (como el nombre del
empleado y sus resultados) para calcularla cuando la página la solicite un
empleado en particular.
Principales Ventajas de una Aplicación Web:
Una empresa puede migrar de sistema operativo o cambiar el Hardware
libremente sin afectar el funcionamiento de las aplicaciones de servidor.
No se requieren complicadas combinaciones de Hardware/Software para
utilizar estas aplicaciones. Solo un computador con un buen navegador
web.
Se facilita el trabajo a distancia. Se puede trabajar desde cualquier PC o
computador portátil con conexión a Internet.
Actualizar o hacer cambios en el Software es sencillo y sin riesgos de
incompatibilidades. Existe solo una versión en el servidor lo que implica
que no hay que distribuirla entre los demás computadores. El proceso es
rápido y limpio.
Al funcionar en un navegador, se requiere un conocimiento básico de
informática para utilizar una aplicación web.
7
Plan de Tesis Saldaña Valqui, Edwin
4.4 ESTANDARES WEB
Los estándares web son un conjunto de recomendaciones dadas por el World
Wide Web Consortium (W3C3) y otras organizaciones internacionales acerca de
cómo crear e interpretar documentos basados en el Web. Son un conjunto de
tecnologías orientadas a brindar beneficios a la mayor cantidad de usuarios,
asegurando la vigencia de todo documento publicado en el Web.
El objetivo es crear un Sistema Web usable para todos, con sitios accesibles a
más personas y que funcionen en cualquier dispositivo de acceso a Internet.
(Gallego Carrillo, 2005).
4.4.1 BENEFICIOS:
Un sitio basado en estándares web mostrará una mayor consistencia
visual. Gracias al uso de xhtml para el contenido y css para la
apariencia, se puede transformar rápidamente un sitio web, sin
importar que se trate de una página web, realizando cambios en un
solo lugar. (Núñez Ramos, 2003).
Los estilos que separan apariencia de contenido usan menos código,
además, CSS permite conseguir efectos que antes requerían el uso de
Javascript4 e imágenes, por lo que los sitios basados en estándares
utilizan menos ancho de banda y se muestran más rápido a los
usuarios, mejorando dramáticamente la experiencia de estos. (Núñez
Ramos, 2003).
Los estándares basados en XHTML válido son más relevantes para los
motores de búsqueda, contienen mayor información y menos código,
por lo que un sitio basado en estándares web tendrá una mejor
posición.
3
4
8
Plan de Tesis Saldaña Valqui, Edwin
De manera similar, la posición en directorios, editados por humanos,
se verá beneficiada pues el sitio será más usable.
XHTML es una aplicación de XML, por lo que el contenido puede ser
procesado de muchas formas, permitiendo la creación de sitios
extensibles. (Gallego Carrillo, 2005).
El uso de validadores nos permite crear xhtml bien estructurado.
Un sitio basado en estándares web, es compatible con todos los
navegadores actuales, y lo será con versiones futuras. Funcionará tan
bien en un ordenador, un navegador aural y un teléfono móvil dentro
de diez años. (Gallego Carrillo, 2005).
Un sitio basado en estándares web, es más fácil de mantener y
actualizar, el código es más simple, de esta forma se elimina la
dependencia de un solo desarrollador.
Un sitio basado en estándares web, es más accesible, permitiendo a
personas con discapacidades utilizar su contenido.
4.5 WAE (EXTENSIÓN APLICACIÓN WEB DE UML)
Es el único exclusivamente basado en UML. Ha sido desarrollado por Jim
Conallen, empleado de Rational Software Corporation. WAE como UML es
recomendado usarlo en lenguajes orientados a objetos. Jim opta por ampliar
UML sencillamente porque es más barato hacer un estándar ampliando que
creándolo de cero. Lo primero que se plantea es que las aplicaciones Web
presentan problemas que UML no contempla solución. UML no facilita la tarea
de diferenciar código cliente (scripts) de código servidor. UML puede ser
extendido para permitir una nueva semántica: estereotipos, listados de etiquetas
(tags) y restricciones (constraints): (Charlie & Orozco , 2008)
9
Plan de Tesis Saldaña Valqui, Edwin
Estereotipos: nos deja atribuir un significado semántico nuevo
para un elemento modelo.
Lista de etiquetas: es la definición de una propiedad nueva (lista
de campo-valor) que puede ser asociada con un elemento modelo.
Restricciones: especifica las condiciones para trabajar con
estereotipos bajo las cuales el modelo puede ser considerado para una
buena estructuración.
5 METODOLOGIA ICONIX
Iconix se define como un “Proceso” de desarrollo de software práctico. ICONIX está
entre la complejidad del RUP (Rational Unified Process) y la simplicidad y
pragmatismo del XP (Extreme Programming), sin eliminar las tareas de análisis y de
diseño que XP no contempla.
Iconix es un proceso simplificado a comparación de otros procesos tradicionales, que
unifica conjunto de métodos orientados a objetos, con el objetivo de abarcar todo el
ciclo de vida de un proyecto. Fue elaborado por Doug Rosenberg y Kendall Scott a
partir de una síntesis del proceso unificado de los “tres amigos” Booch, Rumbaugh y
Jacobson, que han dado soporte y conocimientos a la metodología Iconix desde 1993.
Presenta claramente actividades de cada fase y muestra una secuencia de faces que
deben ser seguidos. Además Iconix está adaptado a los patrones y ofrece el soporte de
Uml, enfocado por casos de uso y es un proceso iterativo e incremental. (Whitten,
2002)
Las tres características fundamentales de Iconix son:
Iterativo e Incremental: varias iteraciones ocurren entre el desarrollo del
modelo del dominio y la identificación de los casos de uso. El modelo estático
es incrementalmente refinado por los modelos dinámicos.
Trazabilidad: cada paso está referenciado por algún requisito. Se define
trazabilidad como la capacidad de seguir una relación entre los diferentes
artefactos producidos.
10
Plan de Tesis Saldaña Valqui, Edwin
Dinámica UML: La metodología ofrece un uso “dinámico del UML”
como los diagramas del caso de uso, diagramas de secuencia y de colaboración.
(MAIA, 2004)
Figura Nº . Enfoque de Iconix (Fernández, 2008)
5.1FASES
5.1.1 ANÁLISIS DE REQUISITOS
Identificar en el “mundo real” los objetos y todas las relaciones de
agregación y generalización entre ellos. Utilizar un diagrama de clases
de alto nivel definido como modelo de dominio.
El trabajo es iniciado con un relevamiento informal de todos los
requisitos que en principio deberían ser parte del sistema. Luego con los
requisitos se construye el diagrama de clases, que representa las
agrupaciones funcionales con que se estructura el sistema que se
desarrolla.
De generarse el sistema a este nivel de especificación, se obtendría el
menú principal del sistema con la interfaces iniciales de los casos o
11
Plan de Tesis Saldaña Valqui, Edwin
actividades de cada división funcional. Los diagramas del segundo nivel
o superior, accesibles a partir de cada escenario o estado del nivel
anterior, representan los casos, actividades y secuencias de interacción de
cada división funcional.
En estos se pueden reutilizar interfaces ya definidas en otros diagramas.
Presentar, si es posible, una Prototipación rápida de las interfaces
del sistema, los diagramas de navegación, etc., de forma que los
clientes puedan comprender mejor el sistema propuesto.
Con el prototipo se espera que las especificaciones iniciales estén
incompletas. En general se necesita entre 2 y 3 reuniones para
establecer las especificaciones iniciales. La rapidez con la que se
genera el sistema es esencial para que no se pierda el estado de
ánimo sobre el proyecto y que los usuarios puedan comenzar a
evaluar la aplicación en la mayor brevedad posible.
Durante la evaluación se debe capturar información sobre lo que
les gusta y lo que les desagrada a los usuarios, al mismo tiempo
poner atención al porque reaccionan los usuarios en la forma en
que lo hacen.
Los cambios al prototipo son planificados con los usuarios antes
de llevarlos a cabo.
El proceso se repite varias veces y finaliza cuando los usuarios y
analistas están de acuerdo en que el sistema ha evolucionado lo
suficiente como para incluir todas las características necesarias o
cuando es evidente que no se obtendrá mayor beneficio con una
iteración adicional.
El diseño de prototipos es una técnica popular de ingeniería para
desarrollar modelos a escala (o simulados) de un producto o sus
componentes. Cuando se aplica al desarrollo de sistemas de
información el diseño de prototipos implica la creación de un
modelo o modelos operativos de trabajo de un sistema o
subsistema.
12
Plan de Tesis Saldaña Valqui, Edwin
Existen cuatro tipos de prototipos:
Prototipo de viabilidad: para probar la viabilidad de una
tecnología específica aplicable a un sistema de
información.
Prototipo de Necesidades: utilizado para “descubrir” las
necesidades de contenido de los usuarios con respecto a la
empresa.
Prototipo de Diseño: es el que usa Iconix. Se usa para
simular el diseño del sistema de información final. Se
centra en la forma y funcionamiento del sistema deseado.
Cuando un analista crea un prototipo de diseño, espera
que los usuarios evalúen este prototipo, como si formara
parte del sistema final. Los usuarios deberían evaluar la
facilidad de aprendizaje y manejo del sistema, así como el
aspecto de las pantallas y los informes y los
procedimientos requeridos para utilizar el sistema. Estos
prototipos pueden servir como especificaciones parciales
de diseño o evolucionar hacia prototipos de información.
Prototipo de Implantación: es una extensión de los
prototipos de diseño donde el prototipo evoluciona
directamente hacia el sistema de producción.
Identificar los casos de uso del sistema mostrando los actores
involucrados. Utilizar para representarlo el modelo de casos de
uso.
Organizar los casos de uso en grupos, o sea, utilizar los diagramas
de paquetes.
Asociar los requisitos funcionales con los casos de uso y con los
objetos del dominio (trazabilidad). (Whitten, 2002)
5.1.2 ANÁLISIS Y DISEÑO PRELIMINAR
Describir los casos de uso, como un flujo principal de acciones,
pudiendo contener los flujos alternativos y los flujos de excepción.
13
Plan de Tesis Saldaña Valqui, Edwin
La principal sugerencia de ICONIX, en esta actividad, es que no se
debe perder mucho tiempo con la descripción textual. Debería usarse
un estilo consistente que sea adecuado al contexto del proyecto.
Realizar un diagrama de robustez. Se debe ilustrar gráficamente las
interacciones entre los objetos participantes de un caso de uso. Este
diagrama permite analizar el texto narrativo de cada caso de uso e
identificar un conjunto inicial de objetos participantes de cada caso
de uso. (Whitten, 2002)
El análisis de robustez ayuda a identificar los objetos que participaran
en cada caso de uso. Estos objetos que forman parte de los diagramas
de robustez se clasifican dentro de los tres tipos siguientes:
Objetos de interfaz: usados por los actores para comunicarse
con el sistema. Son con los que los actores interactúan con el
sistema, generalmente como ventanas, pantalla, diálogos y
menús.
Objetos entidad: son objetos del modelo del dominio. Son a
menudo tablas y archivos que contiene archivos para la
ejecución de dicho caso de uso.
Objetos de control: es la unión entre la interfaz y los objetos
entidad. Sirven como conexión entre los usuarios y los datos.
Los controles son “objetos reales” en un diseño, pero
usualmente sirven como una especie de oficinista para
asegurar que no se olvide ninguna funcionalidad del sistema
la cual puede ser requerida por algún caso de uso. (Whitten,
2002)
Esta técnica tan simple pero poderosa sirve como interfaz entre el
“que” y el “como” de un análisis. Además el análisis de robustez
provee de una gran ayuda a saber si las especificaciones del sistema
son razonables.
El análisis de robustez facilita el reconocimiento de objetos. Esto es
un paso crucial ya que es casi seguro que se olvida algunos objetos
durante el modelado del dominio; y de esta manera se podrán
14
Plan de Tesis Saldaña Valqui, Edwin
identificar antes de que esto cause problemas serios, además sirve
para identificar más y mejores clases, antes del desarrollo del
diagrama de secuencias.
Las reglas básicas que se deben aplicar al realizar los diagramas de
análisis de robustez:
Actores solo pueden comunicarse con objetos interfaz.
Las interfaces solo pueden comunicarse con controles y
actores.
Los objetos entidad solo pueden comunicarse con controles.
Los controles se comunican con interfaces, objetos identidad
y con otros controles pero nunca con actores.
Tomando en cuenta que los objetos entidad y las interfaces son
sustantivos y los controles son verbos. Se pueden enunciar de
manera sencilla que los sustantivos nunca se comunican con otros
sustantivos, pero los verbos, si pueden comunicarse con otros verbos
y a su vez con sustantivos.
Actualizar el diagrama de clases ya definido en el modelo de dominio
con las nuevas clases y atributos descubiertas en los diagramas de
robustez.
5.1.3 DISEÑO
Especificar el comportamiento a través del diagrama de secuencia.
Para cada caso de uso identificar los mensajes entre los diferentes
objetos. Es necesario utilizar los diagramas de colaboración para
representar la interacción entre los objetos. El diagrama de secuencia
muestra interacciones entre objetos según un punto de vista temporal.
El contexto de los objetos no se representa de manera explícita como
en los diagramas de colaboración. La representación se concentra
sobre la expresión de las interacciones. (Whitten, 2002)
A pesar de que a partir de los diagramas de casos de uso y de los
diagramas de robustez ya tenemos entre un 75 y 80 por ciento de
15
Plan de Tesis Saldaña Valqui, Edwin
atributos de nuestras clases identificados, es hasta el diagrama de
secuencia donde se empiezan a ver que métodos llevaran las clases de
nuestro sistema. (MAIA, 2004)
Esto se debe a que hasta que vemos interactuando a los objetos de
nuestras clases con los actores y con otros objetos de manera
dinámica, hasta ese momento tenemos suficiente información como
para poder empezar a especificar los métodos de nuestras respectivas
clases.
El diagrama de secuencia es el núcleo de nuestro modelo dinámico y
muestra todos los cursos alternos que pueden tomar todos nuestros
casos de uso. Los diagramas de secuencia se componen de
4 elementos que son: el curso de acción, los objetos, los mensajes y
los métodos (operaciones) (Whitten, 2002)
Terminar el modelo estático, adicionando los detalles del diseño en el
diagrama de clases.
Verificar si el diseño satisface todos los requisitos identificados.
5.1.4 IMPLEMENTACIÓN
Utilizar el diagrama de componentes, si fuera necesario para apoyar
el desarrollo. Es decir, mostrar la distribución física de los elementos
que componen la estructura interna del sistema.
El diagrama de componentes describe los elementos físicos y sus
relaciones en el entorno de realización. El diagrama muestra las
opciones de realización. (Deepak , Crupi, & Malks, 2007)
Escribir/ Generar el código.
La importancia de la interactividad, interactividad, accesibilidad y
navegación en el software harán que el usuario se sienta seguro y
cómodo al poder hacer uso de la aplicación sin inconvenientes tales
como son los problemas de comunicación. Este y otros problemas
16
Plan de Tesis Saldaña Valqui, Edwin
como la realización de cambios, son factores que deben ser tenidos en
cuenta.
Pero además debemos tener en cuenta factores como:
La Reusabilidad: Es la posibilidad de hacer uso de los
componente en diferentes aplicaciones.
La Extensibilidad: Que consiste en modificar con facilidad
el software.
La Confiabilidad: Realización de sistemas descartando las
posibilidades de error.
Realizar pruebas. Test de unidades, de casos, datos y resultados. Test
de integración con los usuarios para verificar la aceptación de los
resultados. (Whitten, 2002)
5.2DIAGRAMAS QUE USA ICONIX
5.2.1 DIAGRAMA DE CASOS DE USO
Un diagrama de casos de uso (Use Case Diagram) es una
representación gráfica de parte o el total de los actores y casos de uso
del sistema, incluyendo sus interacciones. Todo sistema tiene
como mínimo un diagrama Main Use Case, que es una representación
gráfica del entorno del sistema (actores) y su funcionalidad principal
(casos de uso).
Un diagrama de casos de uso muestra, por tanto, los distintos requisitos
funcionales que se esperan de una aplicación o sistema y cómo se
relaciona con su entorno (usuarios u otras aplicaciones).
Un caso de uso, denotando un requisito funcional exigido al sistema, se
representa en el diagrama por una elipse y un nombre significativo.
un actor en un caso de uso representa un rol que alguien o algo podría
desempeñar y no un alguien o algo específico.
17
Plan de Tesis Saldaña Valqui, Edwin
Ejemplo de Diagrama de Casos de Uso
Figura Nº. Diagrama de Casos de Uso (Enterprise Architect Example
Diagrams)
5.2.2 DIAGRAMA DE ROBUSTEZ
El análisis de robustez juega varios papeles esenciales dentro del
proceso de ICONIX, se refinará su texto de caso de uso y su modelo
estático diseñado como resultado del análisis de robustez.
El análisis de robustez proporciona un control de sanidad ayudándole a
asegurar que su texto de caso de uso es correcto y que usted no ha
especificado una conducta imposible para el sistema o el conjunto de
objetos que se tiene no es razonable. Este refinamiento del texto de
caso de uso cambia la naturaleza del texto de la perspectiva manual de
un usuario a una descripción del uso en el contexto del modelamiento
de objetos. También proporciona una integridad y control de exactitud
ayudándole a determinar si el caso uso toma la dirección de todos los
18
Plan de Tesis Saldaña Valqui, Edwin
caminos alternativos necesarios. El tiempo que se emplea en los dibujo
de diagramas de robustez hasta aquí, y también hacia la producción del
texto que adhiere a algunas pautas bien definidas, el tiempo que se
ahorra es significativo para dibujar los diagramas secuencia. El
análisis de robustez habilita el descubrimiento continuo de objetos; un
paso crucial porque ciertamente se obvio de algunos objetos durante el
modelamiento del dominio. También se puede determinar diferencias
de denominación de objetos y conflictos antes de que ellos causen
serios problemas. Y, el análisis de robustez le ayuda a asegurar que se
ha identificado la mayoría de las clases del dominio antes de empezar
los diagramas de secuencia.
Finalmente, el análisis de robustez llena el papel del Modelo
preliminar, cerrando el hueco entre el análisis y el modelo detallado.
Los tres estereotipos que aplicamos a los objetos durante el análisis de
robustez:
Los Objetos Limite, son los objetos con que los actores (por ejemplo,
los usuarios) estarán actuando recíprocamente en el nuevo sistema.
Éstos frecuentemente incluyen ventanas, pantallas, diálogos y menús.
Los Objetos Entidad, trazan a menudo las tablas de la base de datos y
archivos que contienen la información que necesita sobrevivir a " la
ejecución de caso de uso. Algunos de sus objetos entidad son " objetos
transeúntes ", como los resultados de búsqueda.
Los objetos Control, (controles) incluyen la lógica de la aplicación y
sirve como el tejido que une entre los usuarios y los datos guardados.
Esto es donde usted frecuentemente captura reglas de negocio
cambiantes y políticas, y localiza los cambios a estos objetos sin
romper su interfaz de usuario o su esquema de la base de datos. De vez
en cuando (quizás 20 por ciento del tiempo), los controladores son "los
objetos "reales en un modelo, pero los controladores normalmente
sirven como guías para asegurar que no se olvide de cualquier
19
Plan de Tesis Saldaña Valqui, Edwin
funcionalidad y la conducta del sistema requerido por sus casos de uso.
Usted realiza el análisis de robustez para un caso de uso. Utilizando el
texto del caso de uso, una frase a la vez, y dibujando a los actores, el
límite apropiado, el objeto entidad y el controlador, y las conexiones
entre los varios elementos del diagrama. Usted debe poder encajar el
camino básico y todos los caminos alternados en un diagrama. Cuatro
reglas básicas se aplican:
Los Actores sólo pueden interactuar con los objetos límite.
Los objetos límite sólo pueden interactuar con controladores y
actores.
Los objetos entidad sólo pueden interactuar con controladores.
Los controladores pueden interactuar con objetos limite y
objetos entidad, y con otros controladores, pero no con actores.
Ejemplo de Diagrama de Robustez
Figura Nº. Diagrama de Robustez (Enterprise Architect Example
Diagrams)
20
Plan de Tesis Saldaña Valqui, Edwin
5.2.3 DIAGRAMA DE MODELO DE DOMINIO
Un Modelo de Dominio es un artefacto de la disciplina de análisis,
construido con las reglas de UML durante la fase de concepción, en la
tarea construcción del modelo de dominio, presentado como uno o más
diagramas de clases y que contiene, no conceptos propios de un sistema
de software sino de la propia realidad física.
Los modelos de dominio pueden utilizarse para capturar y expresar el
entendimiento ganado en un área bajo análisis como paso previo al
diseño de un sistema, ya sea de software o de otro tipo. Similares a los
mapas mentales utilizados en el aprendizaje, el modelo de dominio es
utilizado por el analista como un medio para comprender el sector
industrial o de negocios al cual el sistema va a servir. (Garcerant , 2008)
Ejemplo de Diagrama de Modelo de Dominio
21
Plan de Tesis Saldaña Valqui, Edwin
Figura Nº. Diagrama de Modelo de Dominio (Enterprise Architect Example
Diagrams)
5.2.4 DIAGRAMA DE CLASES
Un diagrama de Clases representa las clases que serán utilizadas dentro
del sistema y las relaciones que existen entre ellas. Los diagramas de
Clases por definición son estáticos esto es, representan que partes
interactúan entre sí. La clase define el ámbito de definición de un
conjunto de objetos. (Latina, 2007)
Ejemplo de Diagrama de Clases
Figura Nº. Diagrama de Clases (Enterprise Architect Example Diagrams)
22
Plan de Tesis Saldaña Valqui, Edwin
5.2.5 DIAGRAMA DE SECUENCIA
El diagrama de secuencia de un sistema es una representación que
muestra, en determinado escenario de un caso de uso, los eventos
generados por actores externos, su orden y los eventos internos del
sistema. Se estudia el comportamiento del sistema, desde la perspectiva
de qué es lo que hace, y no de cómo lo hace. Durante la operación del
sistema, los actores generan eventos, solicitando alguna operación a
cambio.
La creación de los diagramas de secuencia depende de la formulación
de los casos de uso. (Guerrero, 2005).
Ejemplo de Diagrama de Secuencia
Figura Nº. Diagrama de Secuencia (Enterprise Architect Example Diagrams)
23
Plan de Tesis Saldaña Valqui, Edwin
5.3 CONFIGURACIÓN METODOLÓGICA
Las siguientes Fases de la metodología ICONIX, es representada en siguiente
