universidad autónoma metropolitana …148.206.53.84/tesiuami/uam4355.pdf · como el de inventarios...

..

Casa abierta al tiempo UNIVERSIDAD AUTóNOMA METROPOLITANA

PROYECTO: Help Desk (Grupo Yoli),.

PERIODO bE REALIZACION: Trimestre 00-1. Trimestre 00-P.

REPORTE CORRESPONDIENTE A PROYECTO I1

INTEGRANTES: Rosas Cuevas Jesus Manuel. Nuñez Razo Juan Salvador.

ASESOR: Luis

Proyecto I1 1

Reporte del Sistema Help Desk Grupo Yoli

C O N T E N I D O

1.

2.

3.

4.

2 2 5 9 0 3 PRESENTACION DEL TRABAJO l. 1 Introducción 1.2 Motivación del Proyecto 1.3 Estructura

OBJETIVOS 2.1 Objetivos Generales del Proyecto 2.2 Objetivos Específicos del Proyecto

MARCO TEORICO 3.1 Introducción 3.2 Desarrollo por prototipos 3.3 Metodología Orientada a Objetos 3.4 Conceptos fundamentales de la Programación Orientada a Objetos 3.5 Análisis y Diseño Orientado a Objetos

3.5:l Modelo de Casos 3.5.2 Modelo de Interfaz 3.5.3 Modelo del Dominio del Problema 3.5.4 Modelo de Análisis

..

3.6 Programación en Power Builder 7.0

DESARROLLO PRACTICO 4.1 Modelo de Requerimientos a Nivel General 4.2 Modelo de Use Case a Nivel General 4.3 Modelo del Dominio del Problema a Nivel General 4.4 Caso de Uso Levantamiento de Reporte

4.4.1 Modelo de Requerimientos 4.4.1.1 Modelo de Casos de Uso 4.4.1.2 Modelo de Interfaz 4.4.1.3 Modelo del Dominio del Problema

4.4.2 Modelo de Análisis (Escenarios) 4.4.3 Modelo de Diseño (Escenarios)

4.5 Caso de Uso Atención de un Reporte 4.5.1 Modelo de Requerimientos

4.5.1.1 Modelo de Casos de Uso 4.5.1.2 Modelo de Interfaz 4.5.1.3 Modelo del Dominio del Problema


4.6 Caso de Uso Atención de una Acción 4.6.1 Modelo de Requerimientos

Proyecto I1 2

Reporte del Sistema Help Desk Grupo Yoli '



4.7 Caso de Uso Conclusión de una Acción 4.7.1 Modelo de Requerimientos



4.8 Caso de Uso Reasignación de Acciones 4.8.1 Modelo de Requerimientos



4.9.1 Modelo d'k Requerimientos 4.9 Caso de Uso Cierre de Reporte

4.9.1.1 Modelo de Casos de Uso 1 ) 4.9.1.2 Modelo de Interfaz t . 4.9.1.3 Modelo del Dominio del Problema 9 4.9.2 Modelo de Análisis (Escenarios) t. 4.9.3 Modelo de Diseño (Escenarios)

", \

4 '

i( 4.10 Caso de Uso Administración de Catálogos



4.10.1 Modelo de Requerimientos

4.11 Modelo de Construcción

5. CONCLUSIONES

6. BIBLIOGRAFIA

.:

7. ANEXOS Anexo 1 Diagramas de Casos de Uso detallados Anexo 2 Diagramas de Colaboración secundarios Anexo 3 Diagramas de Secuencia secundarios

Proyecto I1 3


h>\ Casa abierta al tiemno

- l. PRESENTACION DEL TRABAJO

1.1 Introducción

Help Desk forma parte de un proyecto general de Ingeniería de Software, el cual se desarrolla gracias a un convenio entre la Universidad Autónoma Metropolitana unidad Iztapalapa y Grupo Yoli (Acapulco). Dicho convenio permitirá que se pueda incrementar los recursos de software y hardware al Laboratorio de Ingeniería de Software, utilizado por los alumnos de proyecto terminal de la Licenciatura en Computación, en donde se desarrollan proyectos paralelos para la misma empresa como el de Inventarios y el de Pronostico de ventas, y no sólo para dicha empresa, sino también para la propia UAM, tales como el proyecto de Educación a Distancia para la división de Ciencias Sociales y Humanidades (CSH), entre otros.

Grupo Yoli es una empresa particular dedicada al embotellamiento de Coca Cola y otros productos. Sus oficinas centrales se encuentran en Acapulco, Guerrero y se encarga de distribuir en todo el estado.

El presente trabajo se encargará del desarrollo del Módulo de Atención a Usuarios (Help Desk), el cual tiene comc propósito general automatizar los procesos de levantamiento, administración y atención de reportes de problemas en todo tipo de equipos con que cuenta la empresa, y notificar a los involucrados automáticamente, de cualquier cambio presentado en el estado de atención de reporte. Se pretende que Help Desk sea una herramienta que permita automatizar totalmente tareas de atención a usuarios de informática, ayudando a agilizar los procesos de solución de problemas y de toma de decisiones.

r3

1.2 Motivación del Proyecto

El hecho de trabajar en un proyecto que será utilizado en la Empresa Grupo Yoli de Acapulco, fue mi principal motivo de ingreso a dicho desarrollo, ya que durante nuestra vida universitaria no siempre se tienen este tipo de experiencias con proyectos reales que nos introducen al terreno profesional desarrollando de la forma en que se trabaja en las empresas de ingenieria de software orientado a objetos, ademas del contacto con el cliente para la especificación de requerimientos.

Otro de los alicientes que tuve fue utilizar técnicas de Ingeniería de Software para el desarrollo del sistema Help Desk, como la planeación de actividades, el análisis, diseño y construcción basado en la metodología Orientada a Objetos utilizando UML. Para llevar a cabo lo anterior, se hizo uso de herramientas actuales como Rational Rose 98 para la parte del análisis y Power Builder 7.0 para la parte de construcción.

Proyecto I1 4


hw Casa abierta al tiemoo

1.3 Estructura

El presente trabajo describe en forma extensa y detallada toda la documentación del Proyecto Help Desk. Este documento está estructurado de la siguiente manera:

Objetivos: Describen las metas que se esperan alcanzar y cubrir al finalizar el proyecto. Se dividen en objetivos generales y objetivos particulares.

Marco tedrico: Explica las técnicas, metodologías y herramientas utilizadas para el desarrollo del proyecto, así como algunos otros puntos que es necesario mencionar.

Desarrollo prdctico: Es la parte en la cual se encuentra la base del Proyecto, es decir, es la documentación que se realizó a lo largo de todo el desarrollo del Módulo. En este punto se encuentran descritos los modelos de Requerimientos, de Análisis, de Diseño y de Construcción, los cuales pertenecen a la metodología de Orientación a Objetos utilizando UML.

Conclusiones: Expresan todo lo que se vivió a lo largo del proyecto, así como las experiencias de cada uno de los participantes.

BibliografiB: Son todas las fuentes de conocimiento que fueron empleadas para poder desarrollar este proyecto, así como la base que sustenta las técnicas y metodologías utilizadas. Entre el¡as se encuentran libros, manuales, etc.

Anexos: Es toda aquella documentación que no está comprendida en los puntos anteriores, tal como Manual de Usuario, Manual de instalación, diagramas secundarios, etc.

.:'

,.. * '

Proyecto I1 5

Reporte del Sistema Help Desk "Y"IIILli*OliI;I"Y*UI,."WLlil*I Casa abierta al tiempo Grupo Yoli

- 2. OBJETIVOS

2.1 Objetivos Generales del Proyecto

Desarrollar el Proyecto utilizando una metodolgía Orientada a Objetos, tanto en análisis y diseño como en construcción. La generación de un módulo que permita dar atención a usuarios de equipo de cómputo de manera eficiente. El desarrollo de un módulo que facilite su mantenimiento con respecto a cambios en requerimientos y corrección de errores no detectados en fases previas a su utilización.Para lograr este objetivo es necesario aplicar la filosofia de la orientación a objetos (Modelo de tres capas,etc.).

2.2 Objetivos Específicos del Proyecto

Al concluir el desarrollo del módulo Help Desk se dispondrá de una herramienta que permita:

.I .': Registrar de manera oportuna y eficiente todos los reportes de atención a usuarios que reciba el Sistema. Administrar y darle seguimiento, hasta su conclusión, a cada reporte registrado de una manera oportuna y eficiente por mediso de filtros y atención directa del reporte. Enterar a los involucrados en un reporte de cualquier cambio que en dicho reporte se presente. Reasignar acciones a otro Asesor. Generar reportes de atención por mantenimiento preventivo. Registrar encuestas de calidad de la atención por parte de los usuarios. Configurar las comunicaciones a los involucrados. Generar información que facilite la toma de decisiones. Estar integrado con otros módulos del Sistema de Información del Grupo Yoli. Generar catalogos para eliminar capturas largas e ¡necesarias.

Proyecto I1 6

Reporte del Sistema Help Desk GruaoYoli

Casa abiertaal tiempo

- 3. MARCO TEORICO

3.1 Introducción

La mayor parte de software que se produce hoy en día no cumple con el requisito de que sea una solución efectiva ya que sólo logran satisfacer algunos aspectos de los problemas que presentan las diferentes organizaciones ademas que su mantenimiento es dificil y costoso. Esto es ya que no se sigue una metodología para el Análisis y Diseño. Hay diferentes tipos de Métodos para el Análisis y Diseño de Sistemas, los cuales se pueden apreciar en la figura 3.1.1.

Métodos de Análisis y Diseño /' \

\

'/ Orientados por las funciones /' '

Estrudbrados Otros

Yourdon Otros PSUPSA

.p v - Estructurado - Orr

- Gane-Sarson - SASS De Marco - Ward-Mellor

moderno - SADT (IDEF) Ross

'\ Orientados por la información

\

Orientado-por Orientado i ;

los Datos Objetos / \

-Modelo UML Relaciona1 -Entidades y Asociaciones -Jackson JSD DSSD Warnier-Orr

-Coad-Yourdon "artin-Odell -Rumbaugh OMGlOMT -BOOCh -GOOD (NASA) Seidewitz-Stark

-0OSD Wasserman-Pircher

-0ODLE/OOSA Shlaer-Mellor -CRC y RDD Beck-Cunningham

-HOOD

-0OJSD

Fig. 3.1.1 Metodologías de Análisis y Diseño de Sistemas

Para la realización de una actividad, existe un sinnúmero de posibles formas de hacerlo, pero todas contemplan una serie de pasos y una motivación especial para su aplicación. Bajo un enfoque genérico todas las filosofías de desarrollo contemplan los niveles mostrados en la figura 3.1.2.

Proyecto I1 7

Reporte del Sistema Help Desk Gruao Yoli

Casa abierta al tierntm

Herramientas /'n

Fig. 3.1.2 Componentes de las filosofías de desarrollo

Como podemos ver, la base de la pirámide es la Arquitectura, que es donde residen los otros componentes (Método, Procesos y Herramientas), es la forma en la cual se visualiza la secuencia y los criterios de pasos para la construcción de "algo"; a esto se le llama Arquitectura de Desarrollo. En esta Arquitectura se plantean los principios para las formas de trabajo, como puede ser la forma de organizar las actividades y el enfoque que se debe de adoptar para resolver cada problem.

La arquitectura, propone Métodos que describen la forma de generar productos del desarrollo. Estos métodos son la secuencia de pasos necesarios para realizar el desarrollo del Sistema; a sí mismo, cada paso del Método es un Proceso del Desarrollo, por medio del cual se van cubriendo etapas del desarrollo del Sistema. Y para la elaboración eficiente de cada Proceso, se utilizan Herramientas que son las que soportarán las actividades de cada proceso.

3.2 Desarrollo por prototipos

El desarrollo por prototipos limita el riesgo que se adquiere durante la realización de un Sistema, ya que al final de cada prototipo, se tienen puntos de evaluación en los cuales se decide si el prototipo cumplió con los requerimientos proporcionados por los usuarios; si no los llegó a cumplir, se deberán hacer adecuaciones, donde cada adecuación surge como un prototipo por si mismo, acotando el riesgo que se adquiere de versión en versión. La forma de un modelo por prototipos puede verse en la figura 3.2.1

Proyecto I1 8

_ _ , Reporte del Sistema Help Desk Grupo Yoli

Versión O

+-

Fig. 3.2.1 Modelo por Prototipos

Mientras avanza cada proceso, si se encuentran fallas que tengan un peso considerado, no se intenta corregirlo5:en ese momento, solamente se registran en una bitácora para luego corregirlas cuando se genere el siguiente prototipo.

Cada prototipo está formado por:

Primer prototipo: El equipo de desarrollo se debe familiarizar con el problema, debe determinar las funciones principales, se debe establecer una primera versión de los requerimientos.

Segundo prototipo: Se debe generar un prototipo con mayor funcionalidad, con alcances más amplios que en la versión anterior, se deben generar los requerimientos definitivos del sistema.

Tercer prototipo. Es la primera versión utilizable del sistema, no contiene detalles específicos, sirve para generar versiones siguientes que sean utilizables.

Prototipo Versión 1 .O: Incorpora todos los requerimientos encontrados y es totalmente operacional.

Con esta forma de desarrollo se logra la retroalimentación entre los desarrolladores y los usuarios, de tal forma que se establece una correspondencia entre el aprendizaje de uno con la experiencia de los otros. Con este tipo de desarrollo, los desarrolladores podrán hacer simultáneamente el análisis y la programación ya que se estarán creando sistemas basados en componentes. En ningún momento se pierde el control de las actividades y entregables que se están generando con el prototipo.

Proyecto I1 9

Reporte del Sistema Help Desk Casa abierta al tempo "m," 1111.1 I"VIII'.UW(I:**I

GrupoYoli

Es necesario que la duración del prototipo no sea muy larga. Cada proyecto es distinto a otros, generalmente se establece que en un proyecto debe generarse de tres a cinco versiones, así que es conveniente dividir el tiempo disponible en partes iguales para cada prototipo. Con intervalos cortos, se pueden mostrar resultados rápidamente, aunque estos no sean los definitivos, reducen la ansiedad de los usuarios y de los directivos de las organizaciones.

Es importante señalar que el desarrollo por prototipos supone que cada versión se inicia desde cero. La reutilización debe hacerse en todos los niveles y no sólo en los componentes de programación, para lograr esto, es necesario contar con las herramientas que permitan dicha reutilización a niveles altos como el enfoque de Orientación a Objetos. Por esto, se utilizará la Programación Orientada a Objetos, es decir, la arquitectura de desarrollo con orientación a objetos basándose en la metodología de Ingeniería de Software Orientada a Objetos (ISOO) propuesta por Jacobson.

3.3 Metodología Orientada a Objetos Esta metodología se crea a partir de la programación Orientada a Objetos, cuando se le incorpora el modelado conceptual y el diseño por bloques; la ISOO incluye el levantamiento de t'5querimiento como actividad principal. Sus procesos $e centran en .la elaboración de Modelos del Sistema. Cada modelo es una forma de visualizar el sistema en distintos momentos del desarrollo; cada modelo, es una descripción de aspectos relevantes para cada proceso del desarrollo. Los procesos que la integran son los que se muestran en la figura 3.3.1.

Fkquerimentos rld I klarin

M d e l o Málisis - nimmim

Modd o de h á l i i s

Fig. 3.3.1 Proceso de Ingeniería de Software Orientada a Objetos (ISOO). Los óvalos se refieren a los procesos, los rectángulos a los distintos modelos que se generan.

Proyecto I1 10


La arquitectura de desarrollo plantea que cada proceso aplique conceptos de Orientación a Objetos. Los procesos junto con los modelos que generan son:

0 Análisis 0 Construcción 0 Pruebas

Donde:

Requerimientos de Usuario Modelo de Requerimientos

Modelo de Análisis

Modelo de Diseño Modelo de Construcción Modelos de Pruebas

Modelos de Análisis y de Requerimientos Modelo de Diseño y de Implantación Modelo de Pruebas

Información escrita, verbal del usuario proporciona al equipo de desarrollo Es el destilado de la Especificación de Requerimientos puesto en un formato estándar, el cual permite su actualización sin cambiar la estructura original, establece la Estructura Funcional del sistema, muestra los casos más relevantes de prueba Plantea las interacciones básicas de los objetos que compondrán el sistema Muestra a detalle la interacción de los objetos Describe la constitución modular de los componentes del sistema, también su programación en un lenguaje de programación Muestra la estrategia de pruebas de cada elemento.$lel sistema desde un nivel objeto hasta un nivel de integración de los componentes

Existen varias docenas de notaciones distintas para la descripción de conceptos de Orientación a Objetos como pueden ser las Clases, Asociaciones, Herencia, etc. AI unirse los metodistas más importantes de Orientación a Objetos (Grady Booch, James Rumbaugh e Ivar Jacobson) surge una notación unificada en la cual se describen los distintos diagramas que pueden integrarse a los modelos así como los elementos de cada diagrama. Esta notación recibió el nombre de Lenguaje Unificado para Modelado (UML).

UML permite incorporar todos los conceptos planteados en las metodologías más importantes de desarrollo con Orientación a Objetos, tales como Diagramas de Casos, Diagramas de Clases, Diagramas de Estados, Diagramas de Componentes, etc. UML es una herramienta notacional, que apoya los procesos de Análisis, Construcción y Pruebas.

Los conceptos fundamentales de la programación Orientada a Objetos se describen a detalle en la sección 3.4.

Proyecto I1 1 1

Reporte del Sistema Help Desk Casa abierta al tiemPo

Grupo Yoli

3.4 Conceptos fundamentales de la Programación Orientada a Objetos

El enfoque de orientación a objetos es una forma de observar la realidad, el enfoque se basa en el concepto de objeto, el cual es: Todo aquello que pueda distinguirse dentro del universo de la aplicacidn que sea único. Los objetos tienen propiedades o estados y la única forma de afectar esas propiedades y estados es a través de los comportamientos que exhibe el objeto.

Los objetos pueden estar compuestos de otros objetos más elementales. Como podemos ver, la realidad se puede establecer como un conjunto de objetos que interactúan entre sí a través del enfoque Orientado a Objetos.

Dentro de la definición de objetos encontraremos algunos que serán muy parecidos ya que pueden compartir la misma definición de características. Ya que todos los objetos se parecen, se puede establecer que son obtenidos de la misma plantilla. A esta plantilla, se le llama Clase.

Una clase es una ayuda notacional en el análisis para establecer las propiedades y funciones que serán comunes a todos los objetos que se generen a partir de ella. Cada clase se representa a través de un rectángulo en el que hay tres divisiones, la primera indica el nombre de la Clase, la segunda contendrá las propiedades que debe tener cada objeto y la tercera,contiene los métodos por medio de los cuales, se ,~ modificarán las propiedades de los objetos.

Es importante aclarar que dentro de este documento, la notación que se utilizará será la de UML ya que en la actualidad este tipo de notación es la que tiene la mayor aceptación dentro de la comunidad de desarrolladores con Orientación a Objetos.

En el enfoque orientado a objetos, todos los objetos se generan a partir de clases, a cada objeto generado se dice que es una instancia de la clase, el cual tendrá las propiedades y funciones indicadas en la clase. Tomando en cuenta el punto de vista de los desarrolladores, las clases existen en los momentos en que se está relacionado varios objetos de la realidad, lo cual se da durante la etapa de levantamiento de requerimientos, durante el análisis, el diseño y la programación, sin embargo en el momento en que se ejecuta la aplicación, no existen las clases, lo que sí existe, son instancias de esas clases, en otras palabras, objetos generados a partir de ellas.

Los objetos tienen una conceptualización interesante, pues lo que interesa de ellos es Io que puedan realizar y no como lo hagan, a esta propiedad se le llama encapsulamiento. Este encapsulamiento contempla lo que otros objetos pueden ver de un objeto dado; la visibilidad de un objeto es privada cuando el Único código que puede utilizarlos es el que está dentro de las funciones del objeto; la visibilidad es pública cuando cualquier función de cualquier objeto del sistema puede hacer referencia de la propiedad o de la función que tenga esta visibilidad; la visibilidad amigo es cuando se puede definir un tipo de visibilidad en la que sólo algunos objetos estarán autorizados para hacer referencia a la propiedad o a la función; visibilidad protegida es cuando se establece un tipo de visibilidad de acceso para que propiedades y funciones sean referenciables por código de funciones de subclases dentro de la jerarquía.

Proyecto I1 12

Reporte del Sistema Help Desk UW,1I.IC*O A"( . *L"IUI.U*WII*I Casa abierta al tiempo

Grupo Yoli

El polimorfismo se define como la característica de que el objeto que pide la ejecución de una función a otro objeto, no necesita saber la naturaleza del objeto dueño de la función.

A la característica de que las subclases tomen definiciones de la clase principal se conoce como Herencia.

El concepto de herencia, va asociado a la Especialización en donde se establece que cierta clase de objetos puede tener clases de objetos más especializadas, las cuales por ser especializaciones, tienen todos los elementos de la clase genérica y pueden modificar la funcionalidad heredada o pueden agregar una nueva funcionalidad para especializarse.

La herencia es uno de los mecanismos más importantes para poder asegurar la reutilización de componentes. Dentro de una estructura de herencia, las clases que c;'

Pf" heredan se dice que son clases descendientes y de las que se hereda son &...c.

ascendentes. En UML la relación de herencia entre dos clases, se indica por medio ?', .*. I?;. ._ P.,, ,;

de una flecha hueca que apunta a la clase ascendente. ^d*a "d. *

P' Dentro de una jerarquía de herencia, a las clases que no generan directamente q c

y: ningún objeto se les llama abstractas. A las clases que generan directamente $." 2 objetos se les denomina concretas. si5 m z Los objetos se relaciona; con otros de varias formas, una de las más frecuenteces a 3 ' -J. \- través de Asociaciones Estáticas, este tipo de vínculo tiene la característica que su i- 5; tiempo de duración es mayor al tiempo que tarda en ejecutarse el código que los vincula. Estas asociaciones son muy útiles ya que permiten la estructuración de los E I '

objetos incorporando reglas de negocio. La asociación se indica con una línea I' ', - . uniendo a las dos clases. Muchas reglas de negocio se refieren a los niveles "1

máximos y mínimos de vinculación entre distintos objetos de la aplicación. Este tipo de información es la multiplicidad o cardinalidad de la asociación y se indica colocando un rango en los extremos de la asociación.

En la multiplicidad el "*" indica que el dato de una instancia de la asociación es desconocido al momento en que se realiza el análisis; una asociación tiene una dirección, la cual indica la forma de navegar en la asociación para encontrar una y sólo una instancia.

La multiplicidad es de gran valor cuando se está haciendo el Modelo de Requerimientos del sistema, ya que ayuda a validar los requerimientos con los usuarios y clarifica situaciones de ambigüedad.

Un caso particular de una asociación estática, es cuando se encuentra que un objeto no sólo está asociado con otro, sino que además uno es parte del otro, a este tipo de situación se le llama asociación de agregación. A la agregación se le puede establecer en dos tipos: composición y simple.

En la agregación por composición los objetos y la asociación se dieron simultáneamente y cuando desaparezca un objeto, el otro también desaparecerá así como la asociación. En la agregación simple, los objetos pueden crearse en tiempos distintos y la asociación se da en cualquier momento después de que existen los dos objetos. La agregación se denota con un rombo en el extremo de la asociación en

3 -1

m 0 gz7

* .' 1 ' /

L . '\,'

:- 1

5; *(

Proyecto I1 13

Reporte del Sistema Help Desk h3\ Casa abierta al tiemno

Grupo Yoli

donde se encuentra la clase a la que se le están agregando objetos; a la agregación por composición se le denota con el rombo sólido, mientras que la agregación simple es con el rombo vacío.

Un criterio para determinar el tipo de agregación es revisar la multiplicidad de la asociación, si se tiene una multiplicidad de uno a varios, Io más seguro es que se tenga una agregación simple. Si se tiene una multiplicidad de uno a uno, es casi seguro que se tiene una agregación de composición.

Una vez explicado lo anterior, el entendimiento del Análisis y Diseño Orientado a Objetos será mayor. Debe recordar que la notación que se utilizará en esquemas y diagramas es UML, la cual ya ha sido descrita en párrafos anteriores.

3.5 Análisis y Diseño Orientado a Objetos

La primera parte de todo el proceso de desarrollo está planteado con el Modelo de Análisis que está compuesto por dos procesos más elementales que son el Proceso de Análisis de requerimientos y el Proceso de Análisis dinámico, los cuales a su vez generan dos modelos que son el Modelo de Requerimientos y el Modelo de Análisis Dinámico.

05 En el Proceso de Análisis de Requerimientos es donde se recolectan todos los requerimientos del usuario, ya establecido el modelo de requerimientos, se establece el modelo dinámico del sistema para poder conocer las características principales de la estructura del sistema.

En el proceso de Análisis de Requerimientos, el efecto de manejar requerimientos erróneos es muy grave, pues constituyen los elementos de entrada para el proceso de desarrollo y todas las etapas del desarrollo se basan en los requerimientos, de tal forma que si se tienen requerimientos equivocados se creará un sistema que cumplirá tales requerimientos, por Io que no se obtendrá el sistema que espera el usuario. El objetivo principal no es el levantar el requerimiento, sino que el equipo de desarrollo se familiarice con el problema.

Lo primero que se tiene que hacer es involucrar a los desarrolladores en la problemática del usuario. AI principio, el conocimiento que adquieren los desarrolladores es muy limitado, pero luego se llega a un punto en el que se entienden los conceptos fundamentales; esta adquisición de conocimiento, no sólo será de capacitación, también debe aprovecharse para establecer los requerimientos básicos del sistema.

El Modelo de Requerimientos está formado por otros tres modelos que son:

Modelo de Casos: Extrae el conocimiento funcional fundamental del problema de una forma estructurada y progresiva, siendo la base para establecer la estructura del sistema.

Modelo de Interfaz: Establece el vinculo visual entre desarrollador y usuario para concretar aspectos de la interacción que el sistema pudiese tener con su entorno externo.

Proyecto I1 14

Reporte del Sistema Help Desk Casa abterta al tiempo

GrupoYoli "*IY ,~i l i l "1_I . .*"I1h l i . " s"I~ L

Modelo del Dominio del Problema: Establece los principales objetos que constituirán al sistema y sus relaciones entre s i

La descripción del Modelo de Casos, Modelo de Interfaz y Modelo del Dominio del Problema se explica con mayor detalle en las secciones 3.5.1, 3.5.2 y 3.5.3 respectivamente.

3.5.1 Modelo de Casos

Es necesario preguntar al usuario que es Io que quiere que haga el sistema para que los desarrolladores estén conscientes de ello. Este modelo plantea que todo principio sea el establecer las principales transacciones que contendrá el sistema, entendiendo como transacción cualquier interacción que el sistema tendrá con los agentes externos a él.

La labor del analista es frenar al usuario a que plantee a Io más siete transacciones que a su juicio son las que caracterizan al sistema, gracias a esto, se elimina wan cantidad de transacciones que en este momento-del desarrollo, sólo causan confusión y pérdida de atención a los que realmente son importantes. El número siete es una referencia sobre la cual se puede tener más o menos transacciones. Lo importante es plantear las transacciones más significativas y no las secundarias.

En este modelo cada transacción recibe el nombre de Caso, el cual necesita que se especifique, no sólo con su nombre sino también la secuencia de pasos necesarios para llevarlo a cabo. Cada iteración con el sistema será realizada por un agente externo a éI, a este agente se le conoce como Actor; estos actores, no forman parte del sistema, son los que interactúan con éI a través de los Casos.

Un actor no necesariamente tiene que ser una persona (puede ser otro sistema). En notación UML este modelo se plantea por medio de un Diagrama de Casos, en los cuales los casos se describen por medio de óvalos con el nombre del Caso; los actores se describen por medio de la figura de alambre de una persona como lo podemos ver en la figura 3.5.1.

La relación entre los actores y los casos se muestra con flechas.

Una vez descrito el caso por parte del usuario, se está en posición de documentarlo en una herramienta Case que permita la definición de los casos.

Actor Nombre del Caso

Fig. 3.5.1 Diagrama de Casos

Proyecto I1 15


También es posible establecer asociaciones estáticas entre casos pues son clases. El modelo de casos permite la incorporación de conocimiento no considerado en la etapa de requerimientos normal, pues sólo se incorpora como especialización en donde corresponda; no se corrige nada, sólo se agrega y en el peor de los casos se estará reemplazando un caso completo por otro, de tal forma que la estructura funcional básica de las transacciones del sistema no se ve alterada.

Los casos normales no incluyen información acerca de decisiones, ya que están haciendo suposiciones de transacciones perfectas; en ciertos casos es necesario documentar la información referente a situaciones de excepción, como transacciones en las que es necesario pedir autorización o marcar un error, en estos casos se puede agregar casos que manejen la excepción a través de una relación de Extensión la cual es un estereotipo de una relación de herencia (figura 3.5.2), cada caso tiene su propio Actor y están relacionados entre sí, la relación de herencia simplemente especifica una especialización pero con un significado particular que debe entenderse como una extensión al comportamiento del Caso.

Hay otro tipo de Caso, este se da cuando utiliza de otros Casos para realizar transacciones que puede darse de forma similar a través de relaciones de agregación o composición entre casos. La forma de denotarlo es nuevamente cotli-elaciones de herencia, pero con el estereotipo de Uso*(figura 3.5.3).

Fig. 3.5.2 Caso que tiene otro caso como Extensión

Caso Caso Caso

Fig. 3.5.3 Caso que usa otros Casos para realizar su actividad

3.5.2 Modelo de Interfaz

Este modelo establece un vínculo entre el Usuario y el Analista mostrando cada Caso de forma gráfica, está formado por la definición de las interfaces principales que participarán en la ejecución de un caso cuando el sistema exista; las interfaces son pantallas, reportes o llamadas a otros sistemas. Generalmente se toma como "regla" que cada caso tendrá de dos a tres pantallas que se pueden considerar como significativas.

La elaboración de estas pantallas, debe ser muy rápida y sin emplear demasiados recursos visuales ya que por el momento no son relevantes, pueden hacerse bajo herramientas visuales o a mano en papel. Se tiene que mostrar la forma en que

Proyecto I1 16


se irán activando dependiendo de la interacción que tenga el usuario con el sistema, para hacer esto, se utilizan Diagramas de Transición de Estados (figura 3.5.4).

,/-, ,, Agrega a la 0D y

\ continua Agregando Fig. 3.5.4 El programa tiene un estado Inicial

Agregar un Registro llega a un estado o pantalla (rectángulo) en la que el usuario plantea acciones a realizar. En este caso lo que puede hacer es agregar registros o finalizar el programa. Si va a agregar registros, cambia a una pantalla en donde podrá

0 Pantalla Principal < ~~~ ~ capturar la información de cada registro, aquí podrá agregar a la base de datos todo lo capturado o bien regresar a la pantalla principal y puede decidir terminar el programa, si esto pasa, se llega al estado final que es el círculo

Agrega -1- ~ ~ (círculo negro) de donde parte la ejecución y

\

Fin de Agregar

Fin del Programa v / \ negro con marco. \o;

3.5.3 Modelo del dominio del Problema *: .: Hasta aquí tenemos identificados los requerimientos funcionales principales, pero falta identificar los principales objetos de información que determinan la estructura del sistema. Este modelo tiene como objetivo principal, el identificar los objetos de información y las relaciones que guardan entre sí que se muestra en un Diagrama de Clases; para cada caso del modelo de casos, obtenemos un diagrama de Clases, el cual contendrá los objetos que necesite para desarrollarse. La forma de obtenerlo sigue un esquema sistematizado en el cual hay una serie de pasos para llevarlo a cabo. Estos pasos son:

1. Identificación de los Candidatos a Clases a partir del Caso: Se tomará la descripción textual del caso y se identificarán los sustantivos de cada oración como candidatos a objetos y consecuentemente a clases.

2. Eliminación de candidatos inadecuados: Algunos de los candidatos seleccionados no deben convertirse en clases, pues no corresponden a objetos. Cuando se esté haciendo la eliminación, se debe tomar en cuenta lo siguiente: + Registro: Todos los objetos necesitan almacenar información. + M5s de un atributo: Cuando un objeto tiene un solo atributo, lo más seguro es

que en realidad sea un atributo de otro objeto, es posible que existan objetos con un solo atributo.

+ Funcionalidad: Los objetos deben tener comportamiento que sea relevante para el problema, no pueden existir objetos sin métodos.

+ Atributos y funcionalidad comunes: Todos los atributos y métodos propuestos para la clase deben aplicar para todos y cada uno de los objetos que se espera se generen a partir de ella.

+ Mis de una instancia. Una clase debe generar más de un objeto.

Proyecto I1 17

Reporte del Sistema Help Desk Casa abierta al tiempo U,VIH:,:I"l"~i*"UIMI.UsVII:I"'

Grupo Yoli

3.

4.

5.

6.

7.

8. 9.

Establecimiento de los atributos de cada clase: Ya establecidas, es posible asignarle los atributos básicos a cada una. La información que contendrán las clases puede ser: + Información de referencia. Sólo es necesario designar una clave y una

+ Información sensible al tiempo. Son clases que estarán registrando transacciones

Es necesario estandarizar algunos aspectos: los nombres de las clases en singular o en plural, pero uniformes en este aspecto; los nombres de los atributos uniformes de acuerdo a un estándar tal como sólo mayúsculas, sólo minúsculas, mayúsculas y minúsculas, guiones de separaciones entre los elementos del nombre, etc. Determinación de los atributos que pudiesen ser llaves relacionales: Es importante comenzar a plantear que las clases serán la base para la definición de relaciones, por lo que los atributos que constituirán la llave relacional, se indica con "a". Identificación de las asociaciones estiticas entre clases: Una vez establecidas las clases en una forma básica es necesario establecer los vínculos que tendrán entre sí los objetos: + Se establecen todas las combinaciones válidas de asociaciones binarias. + Se parte de la base que cada asociación binaria puede recorrerse en las dos

+ Se establecen todas las combinaciones válidas de asociaciones ternarias. + Se establecen todas las combinaciones válidas de asociaciones cuaternarias. Identificación de la' multiplicidad o cardinalidad de las asociaciones bintirias detectadas: Una vez identificadas las asociaciones se está en posición de establecer la cardinalidad de todas las asociaciones binarias. La forma de determinar la cardinalidad, consiste en establecer cuantos elementos a lo mínimo y a lo máximo podemos relacionar un objeto con los objetos del otro lado de la asociación. Los valores que pueden darse son O, 1, 2, ... ; cuando se desconoce en forma precisa el número de objetos que se relacionan, se aplicará el concepto de muchos ("*' I) .

Remplazo de asociaciones que impliquen a más de dos clases y/o asociaciones cuya multiplicidad sea uno a uno o muchos, por asociaciones binarias de uno a muchos. Cuando el diagrama ya contempla asociaciones, existe la posibilidad que el modelo oculte información en las asociaciones muchos a muchos, pues en ellas se establecen vínculos complejos entre conjuntos de objetos. La forma de simplificar las asociaciones muchos a muchos, consiste en incluir una nueva clase en lugar de la asociación, la cual estará asociada con las existentes asociaciones uno a muchos dirigiendo el lado muchos hacia el extremo en donde se ubica la nueva clase, los atributos de la nueva clase, serán las llaves relacionales de las clases con quien se estará vinculando, más los atributos correspondientes a ella. Las relaciones uno a uno normalmente corresponden a situaciones en las que se establecieron atributos como clases de tal manera que están vinculados a una razón de uno por uno. Identificación de las asociaciones de agregación y/o composición. Identificación de los métodos b5sicos de las clases: El modelo que se está generando es un modelo estático, el cual probablemente sea implantado en una Base de Datos; los métodos básicos son métodos que tendrán todas las clases, tales como constructores, destructores, métodos que permitan la consulta de los atributos del objeto (get), métodos de escritura sobre los atributos (set). Debemos observar los verbos dentro del Caso, los cuales nos describirán las acciones que deben realizar los objetos del mundo real.

descripción.

de la organización.

direcciones.

10, Identificación de estructuras de Generalización-Especialización: La determinación de estas estructuras no se da necesariamente en el primer ciclo de análisis. La identificación de la herencia se da en el momento en que los objetos en los casos se

Proyecto I1 18

Reporte del Sistema Help Desk GrupoYoli

11.

12.

parecen pero varían en sus propiedades o en sus comportamientos. Las subclases sólo especifican los atributos que son únicos para cada subclase, mientras que por otro lado, comparten todos los atributos de la clase genérica de la estructura. Determinación de los niveles de visibilidad de los atributos y métodos: En general, todos los elementos con los que se est6 trabajando interactúan entre sí para proporcionar la funcionalidad establecida en el Caso, por esto otros objetos fuera de este modelo tendrán una visibilidad limitada de los elementos analizados. Sin embargo, para los elementos dentro del modelo será necesario establecer niveles de visibilidad para generar un modelo que coloque un nivel de encapsulamiento adecuado. Los atributos o propiedades de las clases siempre deben tener una visibilidad privada o protegida en el caso que la clase participe en una estructura de Generalización y Especialización. Los métodos que deben ser públicos son con los que se le van a enviar mensajes a los objetos que se construyan a partir de la clase. Establecimiento de atributos secundarios: La forma de ir incorporando nuevos atributos está en función de la especialización que se va teniendo en los casos y de la estabilidad que esté exhibiendo el modelo de requerimientos.

Cada uno de los pasos pueden repetirse las veces que sea necesario hasta obtener un modelo estable con respecto a los ajustes que se le vayan dando al modelo. En el punto que los ajustes sean menores y podamos considerar que no afectan la estructura fundamental del modelo del Dominio del Problema, estamos en la posibilidad de continuar con la sigyjente etapa del método que es el Modelo de Análisis.

3.5.4 Modelo de Análisis

Consta de identificar las interacciones más significativas entre los objetos obtenidos y por supuesto descubrir nuevos objetos que pueden ayudar a llevar a cabo la interacción. En primer lugar se establecen los distintos tipos de objetos que pueden estar presentes dentro de un sistema, luego se plantea el mecanismo de colaboración entre los objetos, luego se establecen los mensajes entre los objetos y la secuencia de los mismos.

Todos los objetos son iguales, pueden establecer ciertas funciones específicas a los objetos que componen un programa y por Io mismo pueden establecer categorías, las cuales permiten mejorar los aspectos de calidad interna de los componentes de los programas ya que exhiben mejores niveles de cohesión y acoplamiento que son elementos con los que se evalúa la calidad de un sistema. Las categorías más simples de objetos son:

1. Objetos interfaz: Son especializados en la interacción con los actores, presentan información en formatos cercanos al actor y/o permiten la adquisición de información del actor hacia el sistema realizando las conversiones en formato necesarias. No tratan con aspectos de la aplicación. Su construcción está ligada directamente al modelo de interfaz, no contienen mucha lógica relacionada con la aplicación. Todas las transacciones inician y terminan con la interacción entre un actor y un objeto interfaz, por esto es muy fácil su identificación dado el modelo de casos.

Proyecto I1 19

Reporte del Sistema Help Desk Gruoo Yoli

2. Objetos de negocios: Son especializados en los servicios referentes a la lógica de la aplicación y reglas de negocio que tienen que seguirse para la realización de la funcionalidad del programa. No tratan con aspectos de interfaz con los actores ni con las fuentes de datos o de información. Dan servicio a otros objetos como los de interfaz, de tal forma que proporcionan servicios o métodos a otros objetos. Funcionan como gestores con otros objetos para la realización de la lógica de una transacción. Implantan en sus métodos, los algoritmos de la aplicación y las reglas de negocio.

3. Objetos de datos: Su función principal es la de aislar los detalles de implantación de las conexiones con las fuentes de datos para los demás objetos de los programas. Son objetos de servicio, de tal forma que sus decisiones sólo se restringen a la forma en que se consultarán o enviarán datos a las fuentes de datos.

Cuando un programa se estructura sólo con estos tres tipos de objetos, se dice que se está utilizando un modelo de Tres Capas o de Three Tier; este modelo permite estructurar los programas para obtener mejores niveles de mantenimiento, permite aislar el efecto del mantenimiento. Esta situación permite establecer control de versiones de los objetos y no del programa completo. Este modelo puede expandirse en un modelo Multicapa o Multi T e r que incorpora más de tres niveles.

El proceso de Análisis consiste en identificar los objetos dinámicos de un programa y las relaciones dinámicas que guardan ent% sí, establece los objetos dinámicos, su tipo, las relaciones que guardan entre sí, y las clases de donde se originan.

Un escenario es una instancia de un caso que sigue todos los pasos descritos por el caso, con valores reales de los intercambios de información entre el actor y el programa, puede visualizarse como un caso de prueba. Los pasos involucrados en el Proceso de Análisis son:

rl

1. Definición de escenarios: Para cada caso del modelo de requerimientos, se establecen sus escenarios los cuales describirán instancias de los Casos en modalidades normales, de excepción y de error. Un escenario está compuesto por la descripción del caso y por la descripción de los valores para cada paso del caso. Cada escenario es una instancia o ejemplo del caso, es como un conjunto de valores específicos y de acciones específicas del usuario sobre el caso. Para cada caso se seleccionan los escenarios más probables y que generen mejor entendimiento de la operación del caso. Los casos que se consideran más significativos son:

+ Escenario de operación más simple del caso. + Escenario de operación correcta más representativa del caso. + Escenario de operación incorrecta del caso. + Escenario de operación con excepciones del caso.

Una vez concluido el proceso del análisis, el siguiente paso de la metodología lo constituye el proceso de construcción en donde se detalla el modelo análisis dinámico considerando aspectos de implantación además de establecer la estructura de distribución de los objetos que estarán componiendo al sistema. El proceso de construcción se alimenta del modelo de análisis y que está constituido por tres procesos más elementales:

Proyecto I1 20

h!%!t Reporte del Sistema Help Desk ” m X ~ I C I ” : ” l . L I Y I U i i . ” ~ ” l : l * ~ Casa aberta al tiempo

1. Proceso de diseiio: Es el refinamiento del modelo dinámico obtenido por parte del análisis tomando en cuenta aspectos de implantación, toma como una de sus herramientas principales a los diagramas de secuencia que describe un modelo dinámico que facilita la conceptualización de la dinámica del sistema cuando está procesando un escenario. Una de las herramientas del diseño es el diagrama de secuencia que es una gráfica con dos ejes. En el eje vertical se tiene la dimensión del tiempo. En el eje horizontal se tienen los objetos participantes en el escenario. Aunque los objetos se pueden colocar en cualquier posición en el eje, se recomienda colocarlos en el orden que se van utilizando en base a la capa a la que pertenecen, o sea, en primer lugar los objetos de la capa de interfaz, a continuación los objetos de la capa de negocio y en último lugar los objetos de la capa de datos. En los extremos se colocan los actores que participen en el escenario. La interacción entre los objetos se describe a través de flechas que simbolizan los mensajes que entre los mismos. Cada mensaje entre objetos describe, quién envía el mensaje (cliente), quién lo procesará (servidor) apuntando la flecha del mensaje hacia el servidor. Cada mensaje está asociado a un método de la clase a la que pertenece el objeto y por lo regular también incluye en su descripción a los parámetros involucrados en la interacción. Los objetos que están activos se denotan con barras verticales sobre las líneas de vida de cada objeto. Es recomendable ubicar en cada diagrama de secuencia, la descripción paso a paso del caso correspondiente para ubicar las interacciones, en qué momento de la ejecución del caso se dan; para esto, se puede colocar la descripción del lado izquierdo del diagrama y cada punto se coloca a la altura de la interacción que le coFresponde.

2. Proceso de anilisis dinimico de componentes: Es donde se identifican agrupamientos de objetos que se visualizarán como componentes de programación.

3. Proceso de programacidn: Es en sí la programación de los métodos de las clases y la elaboración de los programas.

Grupo Yoli

.:

3.6 Programación en Power Builder 7.0

Debido a que la plataforma cliente es Powerbuilder 7.0, se hace una breve descripción de su uso.

Esta Versión esta orientada al análisis, diseño y desarrollo de aplicaciones Cliente/Servidor; es una herramienta corporativa que cubre todas las fases del ciclo de desarrollo de aplicaciones de negocio, incluyendo el acceso nativo a diferentes bases de datos.

En Power Builder a un editor de objetos utilizado para construir objetos o ‘una herramienta para manipular o administrar sus Bases de Datos o librerías se le conoce con el nombre de “painter”. Por ejemplo, si usted construye una ventana debe hacerlo en el “Window Painter”, es aquí donde usted define las propiedades de la ventana, le agrega controles tales como botones(buttons), cajas de texto (TextBoxes), etc., Los Painters que editan objetos pueden ser accedidos de tres maneras desde la Barra Principal:

Proyecto I1 21

Reporte del Sistema Help Desk Casa abierta al tiempo "MLl,,,~*"I"l:LUUIHi."e"L~ 1"I

Grupo Yoli

1. Haciendo Click en New o Inherit, para crear un objeto nuevo o abrir uno ya existente. 2. Haciendo Doble-Click a un objeto o seleccionando Edit desde el menú tipo popup del

3. Desde el Browser el cual también se accesa desde la barra principal. objeto, esto desde el Painter de Librerías, el cual se puede accesar desde la barra principal.

El "library Painter" mencionado anteriormente y el "Database Painter" se pueden accesar desde la barra principal.

Dentro del 'DataBase Painter'hsted puede Crear o Modificar una base de datos, y realizar algunas manipulaciones a la información contenida en ellas. Se deben observar los siguientes puntos para tratar de obtener una buena conexión a la Base de Datos en cuestión:

0 AI crear el User-DSN en la opción Utilities del "DB Profile" el cual se muestra como una estructura de Arbol, al expandir Utilities se observa la opción ODBC-Administrator, al hacer doble click sobre esta se abre la ventana del ODBC Data Source Administrator, al elegir agregar uno nuevo o configurar uno ya existente, de todos los parámetros a ingresar, se debe tener cuidado en la pestaña 'Database", que es donde pide la ubicación deJa base de datos, al darle esta ubicación se debe ser Lo mas explícito posible del lugar o servidor donde se encuentra, para que otros usuarios que entren a la Aplicación no tengan problemas de conexión a la Base de Datos.

0 Una Vez hecho el punto anterior, es posible, accesar al profile de la Base de Datos en cuestión esto se logra pulsando el botón izquierdo del mouse, seleccionando antes la B.D. en la estructura de árbol mostrada en el DB-Profile, en este profile de lo mas importante a observar en este profile es que es aquí donde se le agrega el DSN creado anteriormente, el otro punto importante se encuentra en la pestaña titulada "Preview", donde se puede observar la información que debemos incluir en el archivo .INI.

Proyecto I1 22

Reporte del Sistema Help Desk Casa abierta al tiempo "U*H_,i10I.I;*LIUIHI-WV(,11111

GrupoYoli

- 4. DESARROLLO PRACTICO

4.1 Modelo de Requerimientos a Nivel General

Los requerimientos generales del sistema Help Desk se describen en las siguientes líneas:

l. Niveles de Usuario Deben existir distintos niveles de usuarios del sistema:

Administrador Asigna permisos, define nuevas categorías y en general le da Tantenimiento a los catálogos.

Help Desk en el sistema. Recibe los reportes de problemas por parte de los usuarios y los registra

Asesor Tiene asignados los reportes de los usuarios, los atiende, les da seguimiento y los soluciona, agregando la solución a la base de ronocimiento de soluciones.

Asesor Tiene asignado,reportes los cuales solo inspeccionara que sean atendidos Responsable y solucionados. Usuario final Levanta los reportes directamente en el sistema, les da seguimiento a sus

reportes y a los de su grupo de trabajo y tiene acceso a la base de conocimiento de soluciones.

Gerencia Consulta los indicadores de la incidencia y atención de los reportes para apoyar la toma de decisiones.

7 L. Levantamiento del Reporte Un reporte se puede levantar de dos maneras:

0 Directamente por el usuario 0 Por registro del Help Desk

El levantamiento debe considerar: IdReporte, Compañía, Gafete, Descripción corta, Detalle del problema, Impacto y prioridad, Asesor responsable, Equipo y software involucrados, con los cuales se pueden dar listas por omisión de clasificaciones de problemas.

El Help Desk genera la primera acción a realizar y ésta es asignada automáticamente a un asesor. Esta primera Acción tiene un status de PENDIENTE.

3. Administración de los Reportes: Proyecto I1 23

Reporte del Sistema Help Desk "UY(,I:iOl"i.I;*"U*hli.*n,,;l*I Casa abierta al tiempo

3.1 Atención de un reporte

GrupoYoli

El asesor asignado a la primera acción de un reporte debe indicar que está comenzando a tenderla, en este momento el Estado del Reporte y la Acción deben cambiar a EN PROCESO. En este inicio indicará la opción de solución que piensa realizar y el número de horas que planea utilizar en desarrollar la acción.

Cuando el Asesor hace la atención del Reporte realizando una Acción, puede detectar problemas más específicos que los que especificó el usuario, de tal forma que puede agregar nuevos problemas al reporte y especificarlos de la siguiente forma:

Problema (Tipo de problema, subtipo de problema, subsubtipo de problema, subsubsubtipo de problema) y descripción del problema de tipo texto.

Cada problema identificado debe tener una o varias acciones asociadas para su solución. Cada acción se asigna automáticamente al mismo asesor, pero este puede reasignarlas a otro asesor. Las acciones tendrán en este momento el estado de PENDIENTE, los problemas también tendrán estado de PENDIENTE.

R .': 3.2 Atención de Una Acción

Las acciones son atendidas por los asesores y éstos cuando las comienzan a realizar deben indicar el número de minutos que planean emplear. Las acciones tendrán un estado de EN PROCESO.

3.3 Conclusión de una acción El asesor puede indicar el avance que tiene la realización de una Acción a través de un Porcentaje de Avance. Si el porcentaje de avance es el 100°/~ el asesor debe indicar el tiempo real dedicado a realizar la acción y en qué porcentaje la acción resolvió el problema asociado.

3.4 Cierre de un Reporte El usuario ligado al reporte una vez que se encontró una solución satisfactoria debe dar su visto bueno directamente a tal solución por medio del sistema o del Help Desk, y en ese momento el estado del reporte debe cambiar a CERRADO. En esta opción se recogerán los comentarios del usuario con respecto a la calidad del servicio que éI percibió.

También el Help Desk puede cerrar reportes indicando las consideraciones realizadas para considerarlo cerrado.

Proyecto I1 24


h3\ Casa abierta al tiernno

3.5 Notificación de Cambios de Estado del Reporte. Con el levantamiento de un reporte puede configurarse el tipo de notificacion que desea el usuario, se divide en tres estados: Notificar en cada cambio, Notificar al final o Sin notificar. De los cuales inicia por default en Notificar en cada cambio.

El asesor debe ser notificado de cualquier asignación o cambio de asignación que lo involucre e igualmente podrá configurar si desea recibir notificaciones al respecto.

3.6 Reasignación de Acciones. La asignación primaria de acciones debe ser automática, es decir, ninguna acción estará sin asignación de asesor.

Las acciones de un reporte pueden reasignarse a otro asesor de manera manual, por el asesor que está asignado a la acción o bien por el Help Desk.

4. Escalamiento de Reportes. Un reporte será escalado en su prioridad con base al tiempo pendiente de resolución y complejidad.

-2 4

5. Seguimiento. Deben existir mecanismos para darle seguimiento a un reporte para todos los actores(como primera opción mediante la asignación de asesores responsables independiente del asesor asignado).

6. Bitácora de cambios. Todo cambio en un reporte debe estar registrado en una bitácora. El cambio registrado en la bitácora debe contener UserName del usuario que modificó el reporte, Fecha y Hora, IdReporte involucrado y tipo de modificación que realizó. No se pueden eliminar y modificar registro de la bitácora. La bitácora debe purgarse periódicamente sólo de reportes ya resueltos

7. Acceso a las Bitácoras. Es un sistema experto disponible a todos los asesores para acceder a la bitácora sólo para efectos de consulta.

8. Consultas: 8.1 Consultas de los Usuarios.

Los reportes y consultas en los que están involucrados directamente pueden ser consultados en todas sus características.

8.2 Consultas de Asesores. Los reportes y consultas en los que están involucrados directamente pueden ser consultados en todas sus características.

8.3 Consultas Gerenciales.

Proyecto I1 25

Reporte del Sistema Help Desk Grueo Yoli

Consultas de estadística de reportes y la posibilidad de las consultas de asesores y consultas de usuario.

9. Mantenimientos preventivos. La información de mantenimiento preventivo debe generarse por evento de manera periódica, la información debe ser: Equipo, tipo de acciones que deben realizarse, fecha programada, ubicación del equipo, configuración registrada del equipo, estado = ASIGNADO, campaña del mantenimiento preventivo, asesor asignado.

La información base debe obtenerse de la información de inventario de equipos de computo. Cada reporte por mantenimiento preventivo, debe procesarse como los

descritos por mantenimiento correctivo.

4.2 Modelo de Use Case a Nivel General El Modelo de Casos, en notación UML, se plantea por medio de un Diagrama de Casos. Los casos se describen por medio de un óvalo con el nombre de cada caso y los actores por medio de una figura de alambre de una persona.

El Diagrama de Casos de la figura 4.2.1, muestra la interacción entre los Actores y Casos hallados en el sistema Help Desk.

*Z

D l f f i R A M A G E N E R A L D E C A S O S D E U S O

L' / ~ c BO Help Desk

~~ ~

Figura 4.2.1 El Diagrama de Casos de Nivel General muestra la interacción entre Actores y Casos.

Proyecto I1 26


4.3 Modelo del Dominio del Problema a Nivel General

Este modelo tiene como objetivo principal, el identificar los objetos de información y las relaciones que guardan entre sí. En el caso del Help Desk, el Diagrama de Clases se muestra en la figura 4.3.1.Figura

4.4 Caso de Uso Levantamiento de Reporte 4.4.1 Modelo de Requerimientos

Este caso de uso describe las actividades que se llevan a cabo para registrar e identificar un reporte dentro del sistema. El Reporte es asignado inicialmente a un asesor que atienda y solucione los problemas que sean reportados posteriormente. Adelante se muestra el Modelo de Casos y el de Interfaz correspondiente a este Caso de Uso.

4.4.1.1 Modelo de Caso de Uso Este modelo está conformado por un diagrama del caso y una lista de pasos a seguir como su descripción. .’: , \ .x

-._ .<’ <<USA>>I

Levantamiento de Help Desk Reporte / ,

, <<USA>>I Usuario Final

Catalogo de Síntomas Figura 4.4.1 Diagrama de Caso de Uso Levantamiento de Reporte

PASOS:

1. El usuario final captura su ID de Usuario o lo puede buscar de la pantalla buscar usuarios que aparece al oprimir el botón de Buscar donde puede ser interno o externo(ver figura 4.4.1.1).

2. El sistema verifica el Identificador y despliega los datos del usuario y los conjuntos que tiene asignados.

3. El usuario final selecciona la clave del conjunto que presenta la falla. 4. El sistema verifica la clave del conjunto y despliega la descripción

correspondiente. 5. El usuario final selecciona el tipo de reporte que se está llevando a

cabo(preventivo o correctivo). 6. El usuario final captura una descripción breve del problema o selecciona el

sintoma de la pantalla(cata1ogo) de sintomas que aparece al aprimir el botón de sintomas(ver figura 4.4.1.2).

7. El usuario final captura una descripción detallada de la situación.

Proyecto I1 21


8. El usuario final captura la descripción del impacto del problema y selecciona la prioridad correspondiente de entre tres opciones: Baja, Media y Alta que por default aparece la prioridad Media.

9. El Usuario selecciona cuando desea ser notificado por cambios en el reporte de entre tres opciones: Noticar en cada cambio, Notificar al final y Sin notificar, que por default aparece Notificar en cada cambio. El usuario selecciona un asesor responsable el cual verificará que el reporte sea atendido. El sistema asigna automáticamente la primera acción a realizar, el asesor que atenderá dicha acción . El sistema registra los datos del reporte, asigna un estado al reporte(pendiente de atender) y un identificador. El sistema refresca la pantalla de control de Help Desk donde se visualiza el reporte recien levantado.

10.

11.

12.

13.

DIAGRAMA GENERAL DE CLASES HELP DESK

TahdComPanla 1 1 : TahdSucursal

o . I

TahdSlnfoma

1 '

Figura 4.3.1 Diagrama de clases a Nivel General del sistema Help Desk.

Proyecto I1 28

Reporte del Sistema Help Desk Casa abierta al tiempo "WM,l.l,(ii.l.lbUliNI."sUL,:II'

Grupo Yoli

4.4.1.2 Modelo de Interfaz

0 Diagrama de Transición de Estados Agregar RepOrte Aceptar

Levantam O

> Confirma > < <

A AceptarIDatos Correctos

Aceptar Cancelar

:. < AceptariDatos Incompletos Salir

~~ v ~~~ ~~~

Error

Figura 4.4.2 Diagrama de Transición de Estados de Levantamiento de Reporte

Layouts Esta primera pantalla muestra una lista de Reportes ya dados de alta, es aquí donde se utiliza la opción "Agregar Reporte".

Obs. Dos opciones de accesar a la pantalla de Control de Help Desk: por menú o por el ícono.

Figura 4.4.3 Pantalla desde la cual se puede agregar un Reporte al SiStema(B0tOfI Agregar Reporte).

Proyecto I1 29

Reporte del Sistema Help Desk Casa a b i z a l tiempo Wmiii,:,"*.l~*"u,Ml.Wul~:r*~

Grupo Yoli

Figura 4.4.3.1 Pantallas de busqueda de usuarios dentro de la pantalla Levantamiento de Reporte

Figura 4.4.2.1 Pantallas que muestran el catalogo de sintomas de la pantalla Levantar Reporte.

Proyecto I1 30

Reporte del Sistema Help Desk jix Casa abierta al tiemm

Grupo Yoli

Figura 4.4.3.2 Esta pantalla Filtro(aparece oprimiendo el boton de Selección Reportes) que sirve para seleccionar reportes por Status, Fecha y por Zona, o la combinacón de estos tres tipos, con la opción de recuperar todos los reportes oprimiendo el botón de Todos.

Figura 4.4.4 Pantalla para captura de datos del levantamiento de Reporte.

Proyecto I1 31


Figura 4.5.3 En esta pantalla se solicita el ID de Asesor para mostrar los reportes que tiene asignados.

En esta pantalla se selecciona un Reporte y se utiliza la opción: "Definir Problemas"

Figura 4.5.4 En esta pantalla se muestra todos los reportes asignados al Asesor.

Proyecto I1 32

Reporte del Sistema Help Desk Casa abierta al tiempo "*I*IYlllil"I.I.*"U,HI.,"W,,illl

GrupoYoli

En la pantalla de la figura 4.5.5, el Asesor puede definir problemas y detallar una lista de Acciones con tiempo de realización que resuelvan dicho Problema así como el o los Asesores que atenderán dichas Acciones.

Figura 4.5.5 Pantalla de definición de problemas y asignación de Acciones.

La figura 4.6.3 muestra la pantalla principal para el control de Acciones. Dicha pantalla muestra una lista de Problemas asociadas a un Reporte y una lista de Acciones asociadas al Problema seleccionado.

En la pantalla de la figura 4.6.4, el Asesor puede cambiar los valores de tiempo(Actua1izar) y avance de una Acción así como reasignar una acción.

Proyecto I1 33


Figura 4.6.3 Pantalla principal para el control de Acciones.

Proyecto I1 34


Figura 4.6.4 Pantalla para cambio en los valores de control de una Acción.

Proyecto I1 35


Básicamente son las mismas pantallas que para el Caso de Uso Atención de un Acción, sólo que en este caso es posible escribir el Tiempo Real dedicado a atender la Acción y el porcentaje en que ésta resolvió el Problema asociado, para poder concluir la acción, el porcentaje de avancede avance debe ser del 100°/~.

Figura 4.7.3 Pantalla para la conclusión de una Acción.

Proyecto I1 36


En figura 4.8.3 se muestra la pantalla correspondiente al Caso Reasignación de Acciones.

En esta pantalla es posible seleccionar un Asesor de la lista o bien escribir su nombre, si es que se conoce, para asignarle la Acción mostrada en el apartado "Datos Actuales".

Figura 4.8.3 Pantalla para reasignación de Acciones.

Proyecto I1 37


La figura 4.9.3 muestra la pantalla de control de Reportes, es ahí donde puede seleccionarse alguno que tenga un status "Concluido" para poder pasarlo a "Cerrado"

Figura 4.9.3 Pantalla de control de Reportes.

La figura siguiente muestra la pantalla de Cierre de Reportes.

Proyecto I1 38


Figura 4.9.4 Pantalla de Cierre de Reportes.

Proyecto I1 39

Reporte del Sistema Help Desk Casa abierta al tiempo Grupo Yoli

W m l i : ~ D ~ " I . , b ~ " U 1 U i l " ~ , . l * r

4.4.1.3 Modelo del Dominio del Problema El diagrama correspondiente a este Modelo se muestra en la siguiente figura.

1 ..

*?

TahdAsesor Id_Asesor : Id-Confianza : Espec-kesor : CalifAsesor :

Id"a Id-TpoRep : / 1.. Id-Conjunto : /

7

/

x Id-Usuario : /

Figura 4.4.5 Modelo del Dominio del Problema del Caso de Uso Levantamiento de Reporte

Proyecto I1 40

n n

.?

U aJ

I

I n O 3 a, U


Casa abierta al tiemoo

0 Diagrama de Clases Dinámicas ~ ~ ~~

<<Interface w-levant

open( openshee openwithpar opensheetwithpa

A

uf-b-levrep ofguarda-repo of-llenad of-l lenx

uf-d-levrep of-set-report ofgetdat ofgetdat

uf-b-ases of-obten-idases of-obten-idnom-ase

ofget-ases

of-selecciona-ase ofget-idases

of-valida-ases < ~~ ~~~

ofget-idnom-ase ofget-ma

of-valida-ases ofget-nornbr of-llenad ofgetdat of-llenad ofgetdat

uf-d-asesor

Figura 4.4.8 Diagrama de Clases dinámicas de Levantamiento de Reporte.

4.5 Atención de un Reporte 4.5.1 Modelo de Requerimientos

En este USE CASE, el Asesor identifica los problemas; selecciona las Acciones para resolverlos y asigna dichas acciones a uno o más Asesores.

4.5.1.1 Modelo de Caso de Uso Este modelo está conformado por un diagrama del caso y una lista de pasos a seguir como su descripción.

Asesor

<<usa>> ~ ,~

/ Catálogo de Sintomas

, Atención de Reportes Administración de Catálogos , _

,/

Help Desk

Figura 4.5.1 Diagrama de Caso de Uso de Atención de un Reporte

Proyecto I1 1


PASOS: 1.- El Asesor ingresa su Identificador. 2.- El sistema Help Desk muestra los reportes que tiene asignados el Asesor. 3.- El Asesor selecciona el Reporte por atender. 4.- El Asesor selecciona la opción de "Definición de Problemas". 5.- El sistema Help Desk muestra catálogos de Tipoproblema, SubTpoproblema, SubsubTipoproblema, SubsubsubTipoproblema. 6.- El Asesor selecciona un Problema con la siguiente ruta: Tipoproblema-SubTipoproblema-SubsubTipoproblema-SubsubsubTipoproblema y escribe una descripción textual del problema.

7.- El Asesor escribe la lista de Acciones necesarias para resolver el problema con el tiempo planeado y el real de la acción posteriormente les asigna a c/u un Asesor . 8.- El sistema Help Desk actualiza el Reporte.


9: 9:

1

TahdReoons

1

Figura 4.5.6 Modelo del Dominio del Problema del Caso de Uso Atención de un Reporte

Proyecto I1 2


Casa abierta al tiempo

l. Ingresa su Id el sistema regresa los reportes que tiene asignados este asesor.

4.5.2 Modelo de Diseño (Escenarios)

I \

w administrar : w admon re rte w atencion rewrte : on asesor : uf on reoorte : uf b on atercionreo od as esores : uf od atencion i&!SX w sheet base : w sheet :se w sheet base b asesor atencion reuorte : uf b alencion d asesores rewrte : uf d m

Id-asesor + Aceptar > i of-valda-asesor(Long) I >' i ! i I i

ofget-asesor(1ong) I

i i >'

i ExecSQL() >

I opensheetwithparm(id-asesor)

>

2. clic en "definición de Problemas"

Id-reporte + Definir ProMemas ~ ~ ~ >

opensheetwithparm(ld-reporte) ~ ~~ >-

Sistema, Subsistema, Falla, Problema, Acción, Asesor + Agregar +Guarda Acciones

3. Selecciona I I > I

'roblema y lctualiza Xegistro

1 ofguarda-reppfobacc(long, long, listbox, listbox) >

ol-set-repprobacc(long, long, listbox, listbox)

I 1 I ~ > I I I ExecSQLO >

I

I I I - of_limpla_listas(listbox, listbox)

~ >- I

, a l

I

Figura 4.5.8 Diagrama de Secuencia del Caso de Uso Atención de un Reporte.

Proyecto I1 3

Reporte del Sistema HelD Desk Grupo Yoli

0 Modelo de Clases Dinámicas

<<Interface>> w-administrar

open0 opensheet() openwithparm() < opensheehvithparm()

~~ ~~ ~

uf-b-asesor of-obten-idasesor() of-obten-idnom-asesor() of-selecciona-asesor() of-valida-asesor() of-valida-asesor() of-llenadw() of-llenadw()

~~

~ ~ ~~~~

~~~~~ ~~

uf-b-atencion-reporte ofguarda-repproiqcc() of-limpialistas() of-llenadw() ofllenadw() < of-cierra-reporte()

~~ -~~ <<Interface>>

w-atención-reporte

open0 < opensheet0 openwithparrn() opensheehvithparrn()

Figura 4.5.9 Diagrama de Clases Dinámicas de Atención de Reportes.

uf-d-asesores ~ ~~~~ ~ ~.

ofget-asesor() ofget-idasesoro ofget-idnom-asesor() ofget_max() ofget-nombre() ofgetdata() ofgetdata()

~ ~ ~~~~~ ~

uf-d-atencion-reporte get-asesor() of-setrepprobacc() ofgetdata() ofgetdata() of-update-cierre-reporte()

.7

Proyecto I1 4


bjq!! Casa abierta al tiempo

4.6 Atención de una Acción 4.6.1 Modelo de Requerimientos

En este USE CASE, el sistema Help Desk cambia el status de una Acción a "En proceso", al especificar el Asesor el tiempo que piensa tardarse en resolverla.


,~,7 Atencion de una Acción

Help Desk

Figura 4.6.1 Diagrama de Caso de Uso de Atención de una Acción

PASOS

1.- El Asesor ingresa su Identificador. 2.- El sistema Help Desk muestra los reportes que tiene asignados el Asesor. 3.- El Asesor selecciona un Reporte. 4.- El sistema Help Desk muestra la lista de Problemas asociados al Reporte. 5.- El Asesor selecciona un Problema. 6.- El sistema Help Desk muestra una lista de Acciones asociadas al Problema. 7.- El Asesor selecciona una Acción y presiona el botón "Modificar Acción" 8.- El sistema Help Desk muestra una pantalla con algunos datos de la Acción. 9.- El Asesor especifica el tiempo que planea ocupar para resolver dicha acción y el porcentaje de avance que tiene la misma. 10.- El sistema Help Desk actualiza el Reporte.

Proyecto I1 5


Casa abierta al tlemuo


TahdTipo-de-Cambio

ID-Tipocambio Desc-TlpoCambo

l..' TahdAleclacion-de-Reporte

&Fech_Cam blo

T a h d R e p o r t e

Usuario-Notif ,

1

1 :

Ta hdAsesor

T a h d P r o b l e m a -~

id-Problema Id-Rep I d T i p P r o b l e m a

4* Id-SSTipoPmblem a I d S l i p P r o b l e m a

@Statgroblema @vaance_Problema ::@esc-Probl. Slrlng

, , , ~ ~ l d - S S S T i p o P i o b l e m a

Figura 4.6.5 Modelo del Dominio del Problema del Caso de Uso Atención de una Acción

1 .:

1

T a h d A c c i o n

I :

~ ~~ .

Proyecto I1 6

h a Reporte del Sistema Help Desk Casa abierta al tiempo

Grupo Yoli "uln~lu;r"ii;,;,~urui,Vhtli*l


El sistema 1 ualiza las :iones y na el mce del lblema. I

Figura 4.6.8 Diagrama de Secuencia del Caso de Uso Atención de una Acción

Proyecto I1 7


h3\ Casa abierta al tiemPo



open0 . opensheet0 openwithparm0 opensheetwithparm0

<<Interface>> w-admon-reporte

open0 opensheet0 openwithparm0 opensheetwithpaw0

<:

- ~ . ~ ~~ ~

/ S,

<<Interface>> w-atencion-acciones

open0 opensheet0 openwithparm0 opensheetwithparm()

f\

<<Interface>> w-atencion-acciones2

opensheet() openwithparm0 opensheetwithparm()

open0 ,x' \

uf-b-asesor of-obten-idasesoro of-obtenidnom-asesor() of-selecciona-asesor() of-valida-asesor() of-valida-asesor() of-llenadw() ofLllenadw()

uf-b-atencion-reporte ofguarda-repprobacc0 of-limpia-listas() of-llenadw() of-llenadw() of-cierra-repo!e()- ~~~~ -~

uf-d-asesores . ~

ofget-asesor() ofget-idasesor() ofgetidnom-asesoro ofget-max() ofget-nombre() ofgetdata0 ofgetdata0

uf-d-atencion-reporte get-asesor0 ofLsetLrepprobacc0 ofgetdata0 ofgetdata() of-update-cierre-reporte0

~ ~~~~ -~ -~ ~ ~~

. ~~~ ~ ~-

uf-d-atencion-accion ofget-total-accionesgendientes() ofget-totalgroblemasgendientes()

uf-b-atencion-accion of-update-acciono of-actualiza-acciono of-update-asesor-actividad0 of-llenadw() of-llenadw() of-reasigna-acciono of-update-reporte() of-valida-information() ofgetdata0

ofgetdata0

-<- --of-updategroblema() of-updategroblema()

Figura 4.6.9 Diagrama de Clases Dinámicas para Atención de una Acción.

Proyecto I1 8

Reporte del Sistema Help Desk Gruso Yoli

4.7 Conclusión de una Acción 4.7.1 Modelo de Requerimientos

En este USE CASE, el Asesor actualiza el porcentaje de avance de una Acción en 100% e indica el tiempo real dedicado a &a, también indica el porcentaje en que esta Acción resuelve el Problema asociado. El sistema Help Desk actualiza el status del Problema y a su vez el del Reporte.


V

Conclusión de una Acción A

I

Figura 4.7.1 Diagrama de Caso de Uso de Conclusión de una Acción

PASOS

1.- El 2.- El 3.- El 4.- El 5.- El 6.- El 7.- El

Asesor ingresa su Identificador. sistema Help Desk muestra los reportes que tiene asignados el Asesor. Asesor selecciona un Reporte. sistema Help Desk muestra la lista de Problemas asociados al Reporte. Asesor selecciona un Problema. sistema Help Desk muestra una lista de Acciones asociadas al Problema. Asesor selecciona la Acción y actualiza el Porcentaje de Avance al 100%"

8.- El Asesor indica el tiempo rea¡ dedicado a realizar l a Acción y el porcentaje en que ésta resolvió el Problema asociado.

9.- El sistema Help Desk actualiza el Porcentaje de Avance del Problema asociado.

10.-El sistema Help Desk actualiza el status del Reporte.

Proyecto I1 9



ID-Tipocambio Desc_TipoCamtio

1 .: TahdAlectacion-de-Reporte

@Fech-Cam blo

1 .:

.?

TahdAsesor ~~ ~~

T a h d R e p o r t e T a h d P r o b l e r n a

Id-Problema Id-Rep

.?

1

vi IdTipoProLlem a Id-StipProta'ema

kSSTipoPmblem a -SSSTipoProblema

1

Vance_Problema

1 .:

1 .:

1

T a h d A c c i o n

1.:

Figura 4.7.4 Modelo del Dominio del Problema del Caso de Uso Conclusión de una Acción

Proyecto I1 10

Yeclea su id asesor. El tema trae reportes

xiados a : asesor

Seleccione nder :iones y jpués de : en )difícar, el tema abrira ?antala de :¡ones.

\ . modifique :I tiempo de wance + iceptar, el iistema suma odos los lvances de las miones isociadas a :se problema

Reporte del Sistema Help Desk Casa abierta al tlempo

Grupo Yoli "~*.I:I"~il . .L"UUI.,"~U1:l*l


~~~ ~ ~

, , ~- - ~~ ~

w administrar : w adrnon w atencion w atencion on asesor : uf on rewrte : uf on atenciona : cd as esores : od atencion od atencion a ~~~ ~~ ~~~~~ . ~ ~~ ~ ~ ~~ ~~

:Asesor w sheet base recorte: w acciones: w acciones2: w p atencion ul b atencion uf d asesores recorte : uf d : uf d atenclon-

Id-asesor + Aceptar > 1 of-valida-asesor(Long) I

ofget_asesw(long)

I I

> I

1 > i I

ExecSQti)

cpensheetwithparm(id-asesor) > > I ,

ofllenadw(uf-i-dwestandar, integer)

I I

>' ~ I ofgetdata(uf-i-westandar, Integer)

, I >'

~ EXWSQL() i

Id-reporte + Atender Acciones I > I

> -1 07

~nsheetwithparm(str-reporte) > I

Idgroblema, Id-accion + Modifica I I I > I I

~ensheetwithpam(str_modf saclon i 2 i

ol_Ilenadw(ul_i_dwestandar, integer) > I

ofgetdata(uf_i_dwestandar, Integer) i >

I I I T I

Tpoganeado, avance-acclón, Tp-real. Avancegroblema t Aceptar I >

of_valida_informacion(editmask. edtiask, &mask, iitmask) I I I I f

~ I ol_updategroblema(id_reporte, statusgroblema. Idgroblema) >

ExecSQL() >

Figura 4.7.6 Diagrama de Secuencia para el Caso de Uso Conclusión de una Acción.

Proyecto I1 11



uf-b-asesor . <<Interface>> of-obten-idasesor0 w-administrar of-obten-idnom-asesor()

open0 of-selecciona-asesor() ~

opensheet() of-valida-asesor() openwithparm() of-valida-asesor() opensheetwithparm() of-llenadwo

of-llenadw()

2'

I ',

<<Interface>> w-admon-reporte

open0 <' opensheet() openwithparm() opensheetwithparm0

, - S,


open0 opensheet() openwithparm() opensheetwithparm()

,?

~~~~ ~~~

~ ~~~~ ~ ~ ~~

<<Interface>> w-atencion-acciones2 open0 opensheet() openwithparm() opensheetwithparm()

<

~~~ -

uf-b-atencion-reporte ofguardauepprobacc0 of-limpia-listas() of-IlenadwO of-llenadw() of-cierra-reporte()

uf-b-atencion-accion of-actualiza-acciono of-llenadw() of-llenadw() of-reasigna-acciono of-valida-information()

, ".

uf-d-asesores ofgetLasesor() ofget-idasesor() ofget-idnom-asesor() ofget-max() ofgetLnombre() ofgetdata0 ofgetdata0

uf-d-atencion-reporte get-asesor() ofLsetLrepprobacc0 ofgetdata0 ofgetdata() of-update-cierre-reporte0

uf-d-atencionaccion ofget-total_accionesgendientes() ofget-totalgroblemasgendientes() of-update-action() of-update-asesor-actividad() of-updategrablema0 of-updategroblema() of-updatecreporte0 ofgetdata() ofgetdata()

Figura 4.7.7 Modelo de Clases Dinámicas para Conclusión de una Acción.

Proyecto I1 12


4.8 Reasignación de Acciones 4.8.1 Modelo de requerimientos

En este USE CASE, el Asesor asignado a una Acción en particular puede reasignarla a otro Asesor.


Asesor

/

Reasignacion de Accion -7 R

Help Desk

Figura 4.8.1 Diagrama de Caso de Uso de Conclusión de una Acción

PASOS

1.- El Asesor ingresa su Identificador. 2.- El sistema Help Desk muestra los reportes que tiene asignados el Asesor. 3.- El Asesor selecciona un Reporte. 4.- El sistema Help Desk muestra la lista de Problemas asociados al Reporte. 5.- El Asesor selecciona un Problema. 6.- El sistema Help Desk muestra una lista de Acciones asociadas al Problema. 7.- El Asesor selecciona la Acción y entra a la opción "Reasignar Acción". 8.- El sistema Help Desk muestra una pantalla con una lista de Asesores disponibles.

9.- El Asesor selecciona un Asesor para reasignar la Acción. 10.-El sistema Help Desk actualiza los datos de la Acción.

Proyecto I1 13



Ta hdAsesor

ID-Asesor , ,

T a h d R e p o r t e T a h d P r o b l e m a

V D - R e p @Jesc-corta $@Slat-Rep

Id-TipnProblem a IdStipoProblema Id-SSTlpoPmblem a I

sc-Impacto

Usuario-Notil SSSTipoProblema

1 1 .:

v a m e-Problem a esc-Probi : Strmg

1 .:

1

T a h d A c c i o n

I . . '

Proyecto I1

Figura 4.8.4 Modelo del Dominio del Problema del Caso de Uso Reasignación de Acciones.

14


1 .Teclea su id de asesor. El sistema trae los reportes asociados a ese asesor

2.Seleccione atender acciones y después reasignar accion, el sistema le moestra la pantalla de reasignar.


~~ ~ ~ ~~~~~ ~

w aMinistrar : w admon w atencion w atencion on asesor : uf on retorte : uf on atenciona : sd aseso res : od atmcion w sheet base retorte : w acciones : w acciones3 : w LF&.s.H b atencion u1 b atenclon uf d asesores rewrte: u1 d

~~ ~ .~ ~ ~~ ~~

~~~~ ~ ~~~ ~ ~~~~ ~~ ~ ~~

Id-asesor + Aceptar ~ ~~ ~ ~ ~~ ~~

/ of-valida-asesorjlong) ' ,

~

I > ofget-asesorjlong)

> opensheetwithparm(1d-asesor)

ExecSQLO

> I ! > 'of_llenadw(uf~-estandar, integer)

I I I

~

I I > ofgetdata(ufj-dwstandar, Integer)

1 Id-reparte +Atender Acciones >

opemheetwithparm(str-reporte) .1 >

3. Seleccione :1 asesor al mal se le eeasignara :Sta accion, el sistema lctualiza el -egistro.

Id-asesor + Aceptar

> ExecSQLO

>

olgetdalajuf- i-~standar, Integer) '

ofgetdata(uf-i-dwestandar)

ExecSQLO 1 >

I

> I

ol-update-asesor_actividad(long. long)

7 ExecSQLj) 1 >

Figura 4.8.6 Diagrama de Secuencia para el Caso de Uso Reasignación de Acciones.

Proyecto I1 15

Reporte del Sistema Help Desk "lun*.,o,o*.l;h"uru,.vu,:rrr Casa abierta al tiempo Grupo Yoli



openo , opensheet0 openwithparm0 opensheetwithparm()

. \

uf-b-asesor of-obten-idasesoro of-obten-idnom-asesor() of-selecciona-asesoro x of-valida-asesor() of-valida-asesor() of-llenadw() of-llenadw()

uf-d.-asesores ofget-asesor() ofget-idasesoro ofgetjdnom-asesor() o f g e t m a 0 ofget-nombre() ofgetdata() ofgetdata0

<<Interface>> . ~~~ ~

uf-b-atencionyepoK uf-d-atencion-reporte

w-admon-reporte ofguarda-repprobacco get-asesor() open0 opensheet0 of-llenadw() ofgetdata0 openwithparm0 of-llenadwo ofgetdata()

_I of-limpia-listas() ..

,' . of-set-repprobacco

of-cierra-reporte0 of-update-cierre-reporte0 ..

"7" ~~


opensheet() openwithparm0 opensheetwithparm()

open0

~~~~

/ S

~ ~ ~~~~~~~ ~ ~

<<Interface>> w-atencion-acciones3

open0 x opensheet0 openwithparm0 opensheetwithparm()

.. ~ ~ ~~~

uf-d-atencion-accion ofget-total-accionesgendientes()

uf-b-atencion-accion ofget-totalgroblemasgendientes() of-actualiza-acciono of-update-acciono of-llenadw() of-update-asesor-actividad0 of-llenadw() of-updategroblema0

of-reasigna-acciono of-updategroblema() of-valida-information() of-update-reporte0

x - ~

ofgetdata0 ofgetdata()

Figura 4.8.7 Modelo de Clases Dinámicas para Reasignación de Acciones.

Proyecto I1 16


Casa abierta al tiempo

4.9 Cierre de Reporte 4.9.1 Modelo de Requerimientos

En este USE CASE, el usuario ligado al Reporte da su visto bueno para que éste sea Cerrado. Así mismo, el usuario dará sus comentarios acerca de la calidad del servicio que recibió.

4.9.1.1 Modelo de Caso de Uso

Usuario Final

e?

Cierre de Reporte

A

Help Desk

Figura 4.9.1 Diagrama de Caso de Uso de Cierre de Reporte

PASOS:

1.- El Usuario Final llena el cuestionario de "Evaluación de Calidad de Sehicios". 2.- El Usuario Final da el visto bueno para que el Reporte asociado a éI sea CERRADO. 3.- El sistema Help Desk cambia el status del Reporte a "CERRADO".

Proyecto I1 17

b;x Reporte del Sistema Help Desk Casa abiertaal tiempo

"IYYL*II:I"~"ly,LI11U.I~,~"L~i~*l

Grupo Yoli


TahdTipoPrioridad -+ Id-Prioridad :

1 .. 1Nom-Prioridad :

TahdReporte

Id-Rep : Id-Campana : Id-TipoRep : Id-Conjunto : Id-Usuario : Desc-corta : Id-StatusRep : Desc-Impacto : Id-Prioridad : Username-Notif : Id-Asesor : Stat-Notif : Desc-Cierre : Calidad-Servicio Desc-larga : Fechareg-Rep :

/' 1 ..

Figura 4.9.5 Modelo del Dominio del Problema del Caso de Uso Cierre de Reporte.

Proyecto I1

Reporte del Sistema Help Desk Casa abierta al tiempo "*N,XIIDI"I",i~"U1UIIBUIIII*I

Grupo Yoli


1 .Usuario final da visto bueno del reporte, y se teclea cerrar reporte. El sistema revisa si t o d s las acciones y problemas de este reporte ya heron terminadas al 100% si es asi el reporte toma el campo status se cambia ha cerrado.

i A , A / \ / 'x

~

I // '%

: BD Yoli w cerrar: w on cierre rep : 1 od atencion

: Usuario Final I

id-reporte, des-cierre, calidad-servicio + Cerrar

, 1 uf b atencion ~ : reporte: uf d , i . " L J ".l -..

- -~ - _____- )'I of-c/&ra-reporte(long, string, String)

of-update-cierre-reporte(long, String, String) ''

. . ExecSQLO

Figura 4.9.7 Diagrama de Secuencia para el Caso de Uso Cierre de Reporte.

Proyecto I1 19


Modelo de Clases Dinámicas

<<Interface>> w-cerrar

open0 opensheet() openwithparm() opensheetwithparm()

-~ ~ ~~

uf-b-atencion-reporte ofguarda-repprobacc() of-limpia-listas() of-Ilenadw() of-llenadw() of-cierra-reporte()

Figura 4.9.8 Modelo de Clases Dinámicas para Cierre de Reporte.

uf-d-atencion-reporte get-asesor() of-set-repprobacco ofgetdata() ofgetdata0 of-update-cierre-reporte()

Proyecto I1 20

Reporte del Sistema Help Desk "WL".,?1U."l:*"*"UI."~UI~:I"I Casa abierta al tiempo Grupo Yoli

4.10 Administración de Catálogos 4.10.1 Modelo de Requerimientos

Es el caso de uso empleado por el administrador para dar mantenimiento a los catalogos de sitemas, subsistemas, fallas, preguntas, campaña, tipo de reporte. y todos aquellos que el sistema requiera para su funcionamiento. Este Caso de Uso se compone de los subcasos: Catálogo de Sistemas, Catálogo de Subsistemas, Catrálogo de Fallas y Catálogo de Problemas. Los Diagramas de Caso de Uso correspondientes a dichos subcasos pueden consultarse en el Anexo l.

4.10.1.1 Modelo de Caso de Uso 2 2 5 9 0 3

Administrador Administración de Catálogos

Figura 4.10.1 Diagrama de Caso de Uso de Administración de Catálogos.

Proyecto I1 21


4.10.1.2 Modelo de Interfaz

Se muestran una pantalla como ejemplo ya que es muy similar en todos los subcasos (Tipoproblema, SubTipoproblema, SubsubTipoproblema,Subsubsub Tipoproblema).

Figura 4.10.2 Pantalla general de mantenimiento de Catálogo para el Tipo de problema.

Proyecto I1 22


Figura 4.10.2.2 Pantalla general de mantenimiento de Catálogo para el SubSubTipo de problema.

Proyecto I1 23


*f .f

Figura 4.10.2.1 Pantalla general de mantenimiento de Catálogo para el SubSubSubTipo de problema.


Figura 4.10.3 Modelo del Dominio del Problema del Caso de Uso Administración de Catálogos

Proyecto I1 24

Reporte del Sistema Help Desk Casa abierta al tiempo “U*L“:18*”Prl~*”UIUI.l”Mlill

Grupo Yoli

4.10.2Modelo de Análisi (Escenarios) Los diferentes escenarios de este Caso de Uso pueden ser consultados en el Anexo 2

4.10.3Modelo de Diseño (Escenarios) Los diferentes escenarios de este Caso de Uso pueden ser consultados en el Anexo 3

4.11 Modelo de Construcción

Este modelo es representado con el diagrama de componentes del sistema, el cual puede verse en la siguiente figura.

O’: 01

el Nuevas

$

Library . P >m Uti1erias.P

Figura 4.9.9 Modelo de Construcción

Proyecto I1 25


Casa abierta al tternoo

En el modelo anterior se ilustra, que de las Nuevas Librerias se heredaron los objetos para nuestra librería principal Helpdesk, las nuevas librerias corresponden a la filosofia de la LFC 'S de Power Builder.

- 5. CONCLUSIONES

El haber participado en este Proyecto me deja muchas satisfacciones, tanto a nivel personal como académico.

Académicamente porque me enfrenté al desarrollo de un sistema, en el cual pude poner en práctica los conocimientos adquiridos en cursos como Ana'lisis y Diseño Orientado a Objetos e Ingenierh de Software.

El uso de Rational Rose 98 es otro aspecto importante ya que, además de poder conocer más a fondo su uso, es una herramienta CASE que facilita enormemente el trabajo de Análisis y Diseño Orientado a Objetos.

Power Builder 7.0 es Cha herramienta que permitió el desarrollo del sistema Raciendo uso de una metodología Orienta a a Objetos de forma fácil y transparente. As¡ como de las nuevas librerias con la filosofia LFC's que facilitan la herencia de objetos ya elaborados, para mejora de el desarrollo de sistemas.

En el aspecto personal tengo la satisfacción de haber desarrollado un sistema que permitirá dar atención a los usuarios de equipo de cómputo de la Empresa Yoli de Acapulco de forma rápida y eficiente.

Proyecto I1 26


Yourdon, Edward. Object Oriented Analysis and Design with Applications, Benjamin Cummings, 1994

Jacobson, Ivar. Object Oriented Software Engineering, Addison-Wesley, 1995

Yourdon, Edward. Object Oriented Sistem Design, Yourdon Press, 1994

Muller, Pierr-Alan. Instant UML, Wrox, Birmingham, Canadá, 1997 *’

Brooks, Federick. The Mythical Man Month, Addison-Wesley, 1995

ar Jacobson, Ivar; Christerson, Magnus; Jonsson, Patrik; Overgaard, Gunn Object Oriented Software Engineering, a Use Case Driven Approach Addison-Wesley, 1992

Humphrey, Watts S. A Discipline for Software Engineering. Addison Wesley, 1995

Gamma, Erich, Helm, Richard; Johnson, Ralph; Vlissides, John Design Patterns Addison-Wesley, 1995

Castro Careaga, Luis Fernando. Análisis y Diseño Orientado a Objetos, Universidad Autónoma Metropolitana, México, D.F., 1999.

William B., Heys. Edición Especial, Power Builder 6, Prentice Hall, 1998

Proyecto I1 27


- 7. ANEXOS

ANEXO 1 Diagramas de Caso de Uso Detallados

Catálogo de Sistemas - Insertar En este USE CASE el Administrador puede dar de alta un nuevo Sistema dentro del catálogo.

Help Desk

Figura A l . l Diagrama de Caso de Uso Insertar Sistema

PASOS:

1.- El Administrador escribe la descripción del Sistema. 2.- El Administrador presiona el botón Guardar. 3.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 28

Reporte del Sistema Help Desk Casa abierta al tiempo "**IR_III"I"ldlOK(HI..UIUL,lil(

Grupo Yoli

Catálogo de Sistemas - Modificar En este USE CASE el Administrador puede modificar un Sistema dentro del catálogo.

Help Desk

Figura A1.2 Diagrama de Caso de Uso Modificar Sistema

PASOS:

1,- El Administrador escribe la nueva descripción del Sistema. 2.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 29

Reporte del Sistema Help Desk ".*,"IIII"I"II,"u1UIIWuLII).*I Casa abierta al tiempo Grupo Yoli

Catálogo de Sistemas - Eliminar En este USE CASE el Administrador puede eliminar un Sistema dentro del catálogo.

Administrador A\

Help Desk

Figura A1.3 Diagrama de Caso de Uso Eliminar Sistema

PASOS:

1.- El Administrador selecciona el Sistema a eliminar del Catálogo. 2.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 30

Reporte del Sistema Help Desk w*L":IcIoI"I~*"u,*~YL"uIII*I Casa abierta al tempo Grupo Yoli

Catálogo de Subsistemas - Insertar 2 2 5 9 0 3 En este USE CASE el Administrador puede dar de alta un nuevo Subsistema dentro del catálogo.

Administrador A\

Help D e s k

Figura A1.4 Diagrama de Caso de Uso Insertar Subsistema

PASOS:

1.- El Administrador escribe la descripción del Subistema. 2.- El Administrador presiona el botón Guardar. 3.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 31

Reporte del Sistema Help Desk Casa a b t z a l tiemoo

Grupo Yoli

Catálogo de Subsistemas - Modificar En este USE CASE el Administrador puede modificar un Subsistema dentro del catálogo.

Administrador A\ k

Help Desk

Figura A1.5 Diagrama de Caso de Uso Modificar Subsistema

PASOS:

1.- El Administrador escribe la nueva descripción del Subsistema. 2.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 32

Reporte del Sistema Help Desk GruDo Yoli

Catálogo de Subsistemas - Eliminar En este USE CASE el Administrador puede eliminar un Subsistema dentro del catálogo.

Administrador i"--..-.----v

Help Desk

Figura A1.6 Diagrama de Caso de Uso Eliminar Subsistema.

PASOS:

1.- El Administrador selecciona el Subsistema a eliminar del Catálogo. 2.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 33

Reporte del Sistema Help Desk Casa a b i z a l tiempo Grupo Yoli

" * * L " ~ I ~ ~ O I " ~ i l l " * , U I ' , " ~ I ~ * I

Catálogo de Fallas - Insertar En este USE CASE el Administrador puede dar de alta una nueva Falla dentro del catálogo.

Insertar Falla

Help Desk

Figura A1.7 Diagrama de Caso de Uso Insertar Falla

PASOS:

1.- El Administrador escribe la descripción de la Falla. 2.- El Administrador presiona el botón Guardar. 3.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 34

Reporte del Sistema Help Desk Casa abierta al tiempo Grupo Yoli

"*YLII.IOI"".I~~"UHIH,IUIU,II*I

Catálogo de Fallas - Modificar En este USE CASE el Administrador puede modificar una Falla dentro del catálogo.

Administrador I/"-.\

Help Desk

Figura A1.8 Diagrama de Caso de Uso Modificar Falla

PASOS:

1.- El Administrador escribe la nueva descripción de la Falla 2.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 35


Catálogo de Fallas - Eliminar En este USE CASE el Administrador puede eliminar una Falla dentro del catálogo.

Eliminar Falla

Help Desk

Figura A L 9 Diagrama de Caso de Uso Eliminar Falla

PASOS:

1.- El Administrador selecciona la Falla a eliminar del Catálogo. 2.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 36


Catálogo de Problemas - Insertar . En este USE CASE el Administrador puede dar de alta un nuevo Problema dentro del catálogo.

Administrador A\ Insertar Problema

Help Desk

Figura AL10 Diagrama de Caso de Uso Insertar Problema

PASOS:

1.- El Administrador escribe la descripción del Problema 2.- El Administrador presiona el botón Guardar. 3.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 37

hm Reporte del Sistema Help Desk "*n~.luDI~lluuI*IU"~u(I:"I1

Casa abiertaal tiempo

Grupo Yoli

Catálogo de Problemas - Modificar En este USE CASE el Administrador puede modificar un Problema dentro del catálogo.

Administrador A\

o Modificar Problema

Help Desk

Figura A l . l l Diagrama de Caso de Uso Modificar Problema

PASOS:

1.- El Administrador escribe la nueva descripción del Problema 2.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 38

Reporte del Sistema Help Desk Casa abierta al tiempo "**l,1",81DIrl..L"U*UIr"IUI:**'

Grupo Yoli

Catálogo de Problemas - Eliminar En este USE CASE el Administrador puede eliminar un Problema dentro del catálogo.

Administrador A\ Eliminar Problema

Help Desk

Figura A1.12 Diagrama de Caso de Uso Eliminar Problema

PASOS:

1.- El Administrador selecciona el Problema a eliminar del Catálogo. 2.- El sistema Help Desk Actualiza el catálogo.

Proyecto I1 39


ANEXO 2 Diagramas de Secuencia Secundarios

Catálogo de Sistemas - Insertar El siguiente diagrama corresponde al escenario Insertar del Subcaso de Uso Catálogo de Sistemas.

w cat sistemas on cataloaos : od cataloaos : 1 .El administrador Admlnlstrador : w sheet base uf b cataloaos uf d cataloaos ___ : ED Yoli inserta un registro y desc-sistema + Guardar da la tecla guardar el > sistema actualiz este registro en la base de datos

of-inserta-sistema(desc-sistema) >

of-set-sistema(desc-sistema) I >

ExecSQL() ~ ~~ >

.3 -7

Figura A3.1 Diagrama de Secuencia Insertar (Catálogo de Sistemas)

Catálogo de Sistemas - Modificar El siguiente diagrama corresponde al escenario Modificar del Subcaso de Uso Catálogo de Sistemas.

1 .El administrador modifica un registro y da la tecla guardar desc-sistema + Modificar

el sistema actualiza este registro en la of-modifica-sistema(desc_sistema, id-sistema)

base de datos

:Administrador : w C t l w cat sistema on catalo- od cataloaos :

S- : BD Yoli

2 I

> , of-update-sistema(desc-sistema, id-sistema)

ExecSQLO

, ~~~ ~~~ >

>

I

Figura A3.2 Diagrama de Secuencia Modificar (Catálogo de Sistemas)

Proyecto I1 40

Reporte del Sistema Help Desk Casa abierta al tiempo "IIYI*:BI"I"l~*.U1UI""WLIII"~

Grupo Yoli

Catálogo de Sistemas - Eliminar El siguiente diagrama corresponde al escenario Eliminar del Subcaso de Uso Catálogo de Sistemas.

A [- ~ 1 :;r:;:;:;os I ~ 1 .El administrador selecciona un registro y da la tecla r : eliminar el sistema id of_e¡imina_sstema(id_astema) ~

actualiz este registro en la base de datos

:BD Yoli

id-sistema + Eliminar >I

I . . : >d l . : : : of-update-sstema(id-sstema)

i - I I c execSQL()

I

Figura A3.3 Diagrama be Secuencia Modificar (Catálogo de Sistemas)

Catálogo de Subsistemas - Insertar El siguiente diagrama corresponde al escenario Insertar del Subcaso de Uso Catálogo de Subsistemas.

1 ,El administrador : Administrador s:$t:e se uf b cataloaos uf d CataloaoS W bgstema on cataloaos: od cataloaos: :BD Yoli

inserta un registro y desc_slbsistema +Guardar

da la tecla guardar el sistema actualiz este of-inserta_slbsstema(desc_slbsstema, id-sistema) '

registro en la base de > datos of-set-wbsstema(desslbsistema, id-ssrema)

1 > I

>' ExecSQLO ~

>

I

,

Figura A3.4 Diagrama de Secuencia Insertar (Catálogo de Subsistemas)

Proyecto I1 41


Catálogo de Subsistemas - Modificar El siguiente diagrama corresponde al escenario Modificar del Subcaso de Uso Catálogo de Subsistemas.

,-\ - ir/

1 .El administrador modifica un registro y da la tecla guardar el sistema actualiz este registro en la base de datos

m I ~ cataloaos: I od cataloaos : I : Administrador 1 subsislemas: b cataloaos ~ uf d cataloaos I ___ : BD Yoli

. :

1 j of-modifica_subsistema(desc_subsstema, id-subsistema) ~

U

b - z e m a ( d e % - s u b s s t e m a , id-wbsislema)

d

n >*

.. . ExecSQL()

” I

d

Figura A3.5 Diagrama de Secuencia Modificar (Catálogo de Subsistemas) *z &

Catálogo de Subsistemas - Eliminar El siguiente diagrama corresponde al escenario Eliminar del Subcaso de Uso Catálogo de Subsistemas.

i l L/

-. -

/ w cat on cataloaos:

uf b cataloaos

1 .El administrador id-subsistema + Eliminar

modifica un registro

: Administrador

I ~~~~ ~ >

m gd cataloaos:

y da la tecla eliminar of-elimina_subsistema(id-subsstema)

el sistema actualiz > I

este registro en la base de datos

~

of-update-subsistema(id-subsistema) >

ExecSQLO >

Figura A3.6 Diagrama de Secuencia Eliminar (Catálogo de Subsistemas)

Proyecto I1 42


Catálogo de Fallas - Insertar El siguiente diagrama corresponde al escenario Insertar del Subcaso de Uso Catálogo de Fallas.

inserta un registro y da la tecla guardar el sistema actualiz este registro en la base de datos

de

I

Figura A3.7 Diagrama & Secuencia Insertar (Catálogo de Fallas) U

Catálogo de Fallas - Modificar El siguiente diagrama corresponde al escenario Modificar del Subcaso de Uso Catálogo de Fallas.

(";

i

A L.,'

: BD Yoli 1 .El administrador modifica un registro y da la tecla guardar n.-desc-fall 7 ~

el sistema actualiz of-modifica-falla(desc-falla, id-falla)

este registro en la base de datos oí-update-falla(desc_falla. id-falla)

. .

Y

r -3 ExecSQL()

, S ;- , I -1 L.!

I

Figura A3.8 Diagrama de Secuencia Modificar (Catálogo de Fallas)

Proyecto I1 43

Reporte del Sistema Help Desk YUYL":I1I"lil**"U(HI."WU:I*I Casa abierta al tiempo

Grupo Yoli

Catálogo de Fallas - Eliminar El siguiente diagrama corresponde al escenario Eliminar del Subcaso de USO Catálogo de Fallas.

f . ) Q " . . ~~~ A

1 .El administrador i w-: cataloaos: j / o ;

od

cataloaos: 1 selecciona un . . . . . . . . . . . . . . . . I

registro y da la tecla id fa l la + Eliminar

guardar el sistema actualiz este registro ; I i of-elimina_falla(id-falla)

en la base de datos

:Administrador i 2 b cataloaos j . uf d cataloaos : BD Yoii

_""_______ 7 7" -3-

L 1 T

i .

~

o~-clean_faIla(id_faIIa) - . .

ExecSQL() i r ,:

I / / / i I \ !

. . . .

. . I

! j

U

Figura A3.9 Diagrama de Secuencia Eliminar (Catálogo de Fallas) U

Catálogo de Problemas - Insertar El siguiente diagrama corresponde al escenario Insertar del Subcaso de Uso Catálogo de Problemas.

1 .El administrador des-problema + Guardar

inserta un registro y da la tecla guardar el ~ b l e m a ( d e ~ - p r o b l e r n a . id-falla) i sistema actualiz este registro en la base de of-segroblerna(desc-problema, id-falla)

datos > I

I i i

. ,

.. 7 I I

I i

ExecSQL()

U

Figura A3.10 Diagrama de Secuencia Insertar (Catálogo de Problemas)

Proyecto I1 44


Catálogo de Problemas - Modificar El siguiente diagrama corresponde al escenario Modificar del Subcaso de Uso Catálogo de Problemas.

:Administrador robl m : w

1 .El administrador desc_problema +Modificar i ~~ ~~ ~ 3

modifica un registro y da la tecla guardar of-modifica-problema(desx-problema, id-problema) ¡ el sistema actualiz

YL.s?aL on cataloaos : pd cataloaos : uf b cata loaos yf d cataloaos

: BD Yoli

> este registro en la base de datos

I I I I I

Figura A3.11 Drcigrama de Secuencia Modificar (Catálogo de Problemas) .?

Catálogo de Problemas - Eliminar El siguiente diagrama corresponde al escenario Eliminar del Subcaso de Uso Catálogo de Problemas.

1 .El administrador selecciona un

id-problema + Eliminar ... 9- i

registro y da la tecla eliminar el sistema

:BD Yoli .-

I I

actualiz este registro . , / / " en la base de datos

. . . . . . . . . . . . . . I ..I of-updategroblema(idgr0blema) , . ~ > '1

I i

ExecSQL() ~.

1

Figura A3.12 Diagrama de'secuencia Eliminar (Catálogo de Problemas)

Proyecto I1 45

universidad autónoma metropolitana …148.206.53.84/tesiuami/uam4355.pdf · como el de inventarios...

Documents