DIVISI~N DE CIENCIAS BASICAS E INGENIERIA DEPARTAMENTO DE ...148.206.53.84/tesiuami/UAM1959.pdf ·...

DIVISI~N DE CIENCIAS BASICAS E INGENIERIA

DEPARTAMENTO DE COMPUTACION

”Help Desk“

TESIS QUE PRESENTA EL ALUMNO: FLORES GÁLVEZ IBSEN.

MATRÍCULA: 95319569.

PARA LA OBTENCI~N DEL GRADO DE: LICENCIADO EN COMPUTACI~N.

Sistema Help Desk Contenido

C O N T E N I D O

l. PRESENTACION DEL TRABAJO 1.1 Introducción 1.2 Motivación del Proyecto 1.3 Estructura

2. OBJEINOS 2.1 Objetivos Generales del Proyecto 2.2 Objetivos Específicos del Proyecto

3. 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.1 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

4. 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

4.6.1.1 Modelo de Casos de Uso

1-1 1-1 1-1 1-1

2-1 2-1 2-1

3-1 3-1 3-2 3-4 3-5 3-8 3-9 3-10 3-11 3-13 3-15

4-1 4-1 4-4 4-5 4-6 4-6 4-6 4-7 4-9 4-10 4-11 4-13 4-13 4-13 4-14 4-17 4-18 4-19 4-21 4-21 4-2 1

Sistema Help Desk Contenido

4.6.1.2 Modelo de Interfaz 4.6.1.3 Modelo del Dominio del Problema


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 de Requerimientos 4.9. l. 1 Modelo de Casos de Uso 4.9.1.2 Modelo de Interfaz 4.9.1.3 Modelo del Dominio del Problema

4.9 Caso de Uso Cierre de Reporte


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

4.10. l. 1 Modelo de Casos de Uso 4.10.1.2 Modelo de Interfaz 4.10.1.3 Modelo del Dominio del Problema


4.11 Modelo de Construcción

5. CONCLUSIONES

6. BIBUOGRAFIA

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

4-22 4-25 4-26 4-27 4-29 4-29 4-29 4-30 4-32 4-33 4-34 4-36 4-36 4-36 4-37 4-39 4-40 4-41 4-43 4-43 4-43 4-44 4-46 4-47 4-48 4-50 4-50 4-50 4-51 4-52 4-52 4-52 4-53

5-1

6-1

a1-1 A2-1 “1

Sistema Help Desk Presentación 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. 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, 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).

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 como 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.

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.

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 98para la parte del análisis y Power Builder 7.0 para la parte de construcción.

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.

1-1

Sistema Help Desk Presentación del Trabajo

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

Desarro//o práctico; 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.

Conc/usiones; Expresan todo lo que se vivió a lo largo del proyecto, así como las experiencias de cada uno de los participantes.

Bibfibgrafla; 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 ellas 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.

1-2

Sistema Help Desk Objetivos

2.1 Objetivos Generales del Proyecto

Desarrollar el Proyecto utilizando una metodologí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.

2.2 Objetivos Específicos del Proyecto

AI concluir el desarrollo del módulo Help Deskse dispondrá de una herramienta que permita:

e

e

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. Enterar a los involucrados en un reporte de cualquier cambio que en dicho reporte se presente. Reasignación de acciones a otro Asesor. Generación de reportes de atención por mantenimiento preventivo. Registro de encuestas de calidad de la atención por parte de los usuarios. Configuración de 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.

2- 1

Sistema Help Desk Marco Teórico

& MARCO TEORICO

3.1 Introducci6n

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. 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&odos de Análisis y Diseiio

Orientadós-por Orientados por las funciones la informaci6n

.~ ~ . .

" " _ >

Estructurados Orientado-por Oflentado los Datos Objetos

. J _I . .

Yourdon Otros PSÚPSA "odelo UML Coad-Yourdon Relaciona1 -Martin-Odell -Entidades v -Rumbaugh OMGlOMT

- Estnkturado - sf& Orr Asociaciones modem0 - SADT (IDEF) Ross JSD

- Gane-SaBon - SASS De Marco DSSD - Ward-Nlellor

-BoOCh Jackson GOOD (NASA)

Seidewitz-Stark

QOSD Wassennan-Pircher -HOOD

-0OJSD -0ODLEIOOSA Shlaer-Mellor CRC y RDD BeckCunningham

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.

3-1


Herramientas /a Procesos

\ \

h45tctdo

Arquitecbm

Fig. 3.1.2 Componentes de las filosofias 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 problema.

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

3 -2


v€Tsión o - ...

... -

V&ón 1

Ajustes a la Especilicación

Análisis c

c

4

c

Diseño

Programación

Pruebas Previas Implantación

Implantaoi6n

Fig. 3.2.1 Modelo por Pmtotipos

Mientras avanza cada proceso, si se encuentran fallas que tengan un peso considerado, no se intenta corregirlos 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 hnifiarkar con el problemaf debe determinar las fünciones prindpalesf se debe establecer una prkvera versión de los requen-mientos.

Segundo prototipo: S;e debe generar un prototipo con mayor füncionafidac$ con almnces más amplios que en la versión anterior, se deben generar los requerimientos definitivos del sishema.

Tercer prototipo. Es la prlinera versión utifizable del si3temaf no contiene detalles especficos, sine para generar versiones sauientes que sean utiizables.

Prototipo Versión 1.0: Incorpora todos los requen?nientos 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.

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

3-3


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 programacion Orientada a Objetos, cuando se le incorpora el modelado conceptual y el diseño por bloques; la ISOO incluye el levantamiento de requerimiento como actividad principal. Sus procesos se 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.

Rquerirrientos dd I klarin

Modelo Pnilisis nimmim

V Moddo de Pnilisis

Modelo de * Rquximientcs Modelo de

as€ñ0 Modelo de

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. Pntehas

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 Modelos de Análisis y de Requerimientos 0 Construcción Modelo de Diseño y de Implantación 0 Pruebas Modelo de Pruebas

3-4


Donde:

Requerimientos de Usuario Modelo de Requerimientos

Modelo de Análtsis

Modelo de Disí70 Modelo de Construcción Modelos 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 del 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.

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: T i 0 aquello que pueda d-dinguirse denfro del universo de la apkcadón 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 interadan 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

3-5


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 lo 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úbkw 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 am@o 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. 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.

3-6


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 heredan se dice que son clases descendientes y de las que se hereda son ascendentes. En UML la relación de herencia entre dos clases, se indica por medio de una flecha hueca que apunta a la clase ascendente.

Dentro de una jerarquía de herencia, a las clases que no generan directamente ningún objeto se les llama abstractas. A las clases que generan directamente objetos se les denomina concretas.

Los objetos se relacionan con otros de varias formas, una de las más frecuentes es a través de Asociaciones Estáticas, este tipo de vínculo tiene la característica que su 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 objetos incorporando reglas de negocio. La asociación se indica con una línea uniendo a las dos clases. Muchas reglas de negocio se refieren a los niveles 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 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, lo 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-7


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. 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 lo 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 cbsos= E&ae el conocimiento hncional findamental del problema de una fonna estructurada y pmgresiva, siendo la base para establecer la estructura del sistema.

Modelo de Interfaz: Establéce el whculo visual entre desamllador y usuario para concretar aspcbos de la interacción que el sistema pudiese tener con su entorno externo.

Modefo del Dominio del Problema: E3tablece los principales objetos que constituirán al sistema y sus relaciones entre SL

La descripción del Modelo de Casos, Modelo de Interf-az 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-8


3.5.1 Modelo de Casos

Es necesario preguntar al usuario que es lo 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 lo más siete transacciones que a su juicio son las que caracterizan al sistema, gracias a esto, se elimina gran 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 de'

Fig. 3.5.1 Diagrama de Casos

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

3 -9


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 con relaciones de herencia, pero con el estereotipo de Uso (figura 3.5.3).

Actor Caso Actor Caso

<<tictiende>>

Actor Caso Caso Caso Caso

Fig. 3.5.2 Caso que tiene otro caso como Fig. 3.5.3 Caso que usa otros Casos para realizar su Extensión 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 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).

3-10


Agmga a la 0D y cont inwAgrwdo Fig. 3.5.4 El programa tiene un estado inicial

- ~ ~ . ~ ~ - .--~_>;AgregarunRegistro 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á

Agrega . . ." 3 .~ . (címlo negro) de donde parte la ejecución y

." . .. . ~ . .. Fin de Agregar -> Pantalla Principal ,< . ~ . ." . capturar la informaaó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 negro con marco.

I

Fin del Programa

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 Gmddatos a Clases a parhr del aso: 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. Himinación de canddatos 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: 4 Regigro: Todos los objetos necesitan almacenar información. 4 Más 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.

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

4 Atributos y funcionakdad 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.

4 Más de una ins¿ancia. Una clase debe generar más de un objeto. 3. Es¿ableomiento de los atnbuhos 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: 4 Información de referencia. Sólo es necesario designar una clave y una

4 Infamació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

descripción.

de la organización.

3-1 1


acuerdo a un estándar tal como sólo mayúsculas, sólo minúsculas, mayúsculas y

4.

5

6.

z

8. 9.

1 o.

11.

minúsculas, guiones de separaciones entre los elementos del nombre, etc. Determinación de los atributos que pudiesen ser llaves relaciona/es: 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 "@". Identificación de las asociaciones estáticas 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 mulOplicidad o caroinalidad de las asociaciones binarias detect3das: 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 ("*"). Reemplazo 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 bákicos 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. Identificación de estructuras de Generallizacíón-Esaeciallizació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 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 visibibdad de los atributos y métodos: En general, todos los elementos con los que se está 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

direcciones.

3-12


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.

12. Eslab/ecimiennto de ainButos secundarios: La forma de ir incorporando nuevos atributos está en función de la especialización que se va teniendo en los caws 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 siguiente 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 lo 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.

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 interfat, de t a l 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.

3-13


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 Tier 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 entre 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:

l. Lkfinición de exenaios: 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: 1. Proceso de dseño: 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 con base en 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

3-14


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 te corresponde.

2. Proceso de anábsis dinsmio de componentes: Es donde se identifican agrupamientos de objetos que se visualizarán como componentes de programación.

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

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/Setvidor; 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 (TextEbxes), etc., Los Painters que editan objetos pueden ser accedidos de tres maneras desde la Barra Principal:

l. 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”usted puede Crear o Modificar una base de datos, y realizar algunas manipulaciones a la información contenida en ellas. Se deben

3-15


observar los siguientes puntos para tratar de obtener una buena conexión a la Base de Datos en cuestión:

O 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 de la 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.

O 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 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.

3-16

Sistema Help Desk Desarrollo Práctico

4.1 Modelo de Requerirnientos a Nivel General

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

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

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

2. 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, UserName, Compañía, Gafete, Descripción corta, Detalle del problema, Impacto y prioridad, 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: 3.1 Atención de un reporte

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

4- 1


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:

Clasificación del problema (categoría, subcategoría, subsubcategoría, subsubsubcategoría) y 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.

3.2 Atención de Una Acción

Las acciones son atendidas por los asesores y é&os cuando las comienzan a realizar deben indicar el número de minutos que planean emplear. Las acciones tendran 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 setvicio que éI percibió.

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

3.5 Notificación de Cambios de Estado del Reporte. Con el levantamiento de un reporte puede configurarse a quién deben notificársele los cambios de estado, preestableciendo notificaciones por usuario, tipo de falla, equipo y valor del estado.

Debe notificar al usuario del reporte cada vez que hay un cambio en el estado. El usuario puede configurar sobre qué cambios de estado desea recibir la notificación.

4-2


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 respedo.

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.

5. Seguimiento. Deben existir mecanismos para darle seguimiento a un reporte para todos los actores.

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. 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, configuraci6n registrada del

4-3


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 General de Casos de la figura 4.2.1, muestra la interacción entre los Actores y Casos hallados en el sistema Help Desk.

DUGRAUAGENERALECASOSDEUSO

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

4-4


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.

Corflmza Id-CmfiCnra : lag Id-Ernp : lag

uscerio "Uslerio: long UscrName-Usuario : sting Id-ccfltilma : long

1

Dese-Tipocambio

1 .:

1 .:

Falla

Respesta : string 1 .:

1. 1

Problema 1 .: Id-Prcblema : lag

Id-Falla: long Desc-Prabkma : string

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

4-5


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 Intetfaz 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.

/

,,?f4\ "~ ." q \

/A Levantamientode Reporte f - -~ ~ - ~~ ~~

~ 'F' Help Desk

Usuario Final Figura 4.4.1 Diagrama de Caso de Uso Levantamiento de Reporte

PASOS:

1. El usuario final captura su ID de Usuario. 2. El sistema verifica el Identificador y despliega los datos del usuario y los

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

5. El usuario final selecciona el tipo de reporte que se está llevando a cabo. 6. El usuario final captura una descripción breve del problema. 7. El usuario final captura una descripción detallada de la situación. 8. El usuario final captura la descripción del impacto del problema y selecciona la

prioridad correspondiente. 9. El Usuario captura el identificador de usuario al cual se le deben hacer las

notificaciones y configura el tipo de notificación y estados sobre los cuales desea recibir notificaciones.

10. El sistema asigna automáticamente la primera acción a realizar, el asesor que atenderá dicha acción y el estado inicial de la acción.

11. El sistema registra los datos del reporte, asigna un estado al reporte y un identificador, además le asigna el reporte a un asesor.

conjuntos que tiene asignados.

correspondiente.

4-6


4.4.1.2 Modelo de Interfaz 0 Diagrama de Transici6n de Estados

La siguiente figura muestra el diagrama de transición de estados del use case Levantamiento de Reporte.

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

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

I

RUQI

Figura 4.4.3 Pantalla desde la cual se puede agregar un Reporte al Sistema.

4-7


La figura 4.4.4 muestra la pantalla de captura de datos para realizar el levantamiento de un Reporte en el Sistema. Se muestra un ejemplo del uso de dicha ventana.

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

4-8


4.4.1.3 Modelo del Dominio del Problema EI diagrama de clases estáticas del Levantamiento de Reporte se muestra en la siguiente figura.

. .~ " ~

Tipo- ~ "" . . .. . . . . ~ ."!

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

,Id-TipoRep : long Reporte ,Nom-TipoReporte : string; i Id-Rep : long

c. ." . ~ ~~ ~~- ~

.. ~ - . . ... 1

Y\. ~ Id-Campana : long 1 . . 1 ',,,,\ ~ IdJipoRep : long

lld-Conjunto : long '\ ',, I i Id-Usuario : long

&=-corta : string : Id-Statusfiep : long i bsc-lmpacto : string .Id-Prioridad : long

1-*;Username_Notif: string A,'? Id-Asesor : long

1 ..* !

Asesor L//' j Stat-Notif : string ~~ ~... .~

1 Id-Asesor : long 'l..l #Id-Confianza : long I

: Espec-Asesor : string j i Calif-Asesor : long

'i De=-Cierre : string ]Calidad-Servicio : string ~ Des-larga : string i Fechareg-Rep : string

í

/'l..l

1 ..*

'\ 1 ..*\

'A I

i Tipo- Id StatusRep : Ions 1 Nom-status : string

1-11 . - ~.~~

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

4-9


4.4.2 Modelo de Análisis (Escenarios) En el esquema siguiente se puede observar la interacción entre usuarios y objetos del sistema a fin de determinar la colaboración que entre ellos exista para levantar un reporte.

: Usuario Final

v 4: ofget-max( ) 1

on asesodev : cd asesores : u

uf asesor 6: ofget-asesofllong) asesores 1

3: of-selecciona-asesor( ) On k V E P : Uf >

b levreDorte 5: ExeCsQLO 7: ExecSQLO

4 L v

8: of-set-reporte(long, long, long, long, String, String, String, Long, Long. String, String, Long)

cd leVreP : Uf d b v r a w r t q

1 1 3'

> A 9: ExeCsQLO

: BD Yoli

Figura 4.4.6 Diagrama de Colaboración del Caso de Uso Levantamiento de Reporte.

4-10


4.4.3 Modelo de Diseño (Escenarios) A partir del diagrama de colaboración del Levantamiento de Reporte se obtiene su diagrama de secuencia en esta etapa de diseño y se puede observar con detalle en la siguiente figura.

Usuario. 2. O sistema veiflca el lentificador

y despliega los datos del usuario y los conjuntos que tlene asignados 3. El usuario final selecciona la clav e del conjunto que presenta la falla 4. El sistema verifica la clave del conjunto y despliega la descripci6n correspondientes 5. El usuario final selecciona el tipo

cabo de reporte que se este kvando a

6. 8 usuario final captura una descripcion breve del probkma. 7. El usuario final captura una

descripci6n detallada de la situaci6n. 8. O usuario final captura la descripcion del impacto del problema y selecciona !a prioridad correspondiente. 9. E Usuario captura el identificado

hacer las notiicaciones y configura

r de usuario al cual se le deben

el tipo de notiicacion y estados sobre los cuales desea recibir notificaciones 10. O sistema asigna aulomaticamente la primera accion

a realizar. el asesor que atender6 dicha accion y el estado inicial de I a accion. 1 1 . O sistema registra los detos de I reporte. asigna un estado al reporte y un identificador. a d e d s I e asigna el reporte a un asesor

w levantar: w on IevreD : uf b on asesorlev: u od leww : uf d od asesores : u : Usuario Final sheet base 1emt)orte f b asesor lewworta f d asesores : BD yoli

,.El usuario fina,captuta su Klde (id-usr, id-coni, desc-b. desc-I, impacto, usr-notif, tipo-r, prior-r) + Aceptar 1 I 2 1 ,

I

of_guarda-reporte(long, long, long, long, String, String, long. String. String, String) > of-selecciona-asesor( ) I

> , I I

of_get-max( ) i ~ >

ExecSQLO >

ofdet-asesor(long) >

ExecSQLO >

oLset-reporte(long, long, long. long, String, String. String, Long, Long. String, String, Long) > I

Figura 4.4.7 Diagrama de Secuencia del Caso de Uso Levantamiento de Reporte.

4-1 1


0 Diagrama de Clases Dinámicas En la figura siguiente se muestra el diagrama de clases dinámicas del Levantamiento de Reporte.

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

4-12


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.


,./y Atención de Reportes

,' I. ,, ,N

Administración de C a t ~ l o g o s

Help Desk

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

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 Sistemas, Subsistemas, Fallas y Problemas.

6.- El Asesor selecciona un Problema con la siguiente ruta:

7.- El Asesor escribe la lista de Acciones necesarias para resolver el problema y les asigna a c/u un Asesor. 8.- El sistema Help Desk actualiza el Reporte.

Sistema ->Subsistema -> Falla -> Problema.

4-13


4.5.1.2 Modelo de Interfaz 0 Diagrama de Transición de Estados

La siguiente figura muestra el diagrama de transición de estados del use case Atención de un Reporte.

Administraaón de Reporte

> >

Solicitud de Id del Asesor. Salir >e A

Aceptar( id-asesor X asesor no registrado ] Salir

v Aceptar( id-asesor ) I Asesor válido

Aceptar Mensaje de error

h v > Atenci6n de Reportes

Definir pmblernaq id-reporte ) Salir

Guardar I Datos incorrectos

7

Guardar

I V Asignación Pmblerna-Acdón-Asesor

Figura 4.5.2 Diagrama de Transición de Estados de Atención de un Reporte.

4-14


Layouts Para que un asesor pueda observar los reportes que tiene asignados, deberá ingresar su identificador.

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", es decir, se enlistan las razones por las que se creó el problema.

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

4-15


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

Aoow 1pERNANDU GOMEZ JORGE 3kH4vU FLORES LAMBERT0

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

4-16


4.5.1.3 Modelo del Dominio del Problema El diagrama de clases estáticas para la Atención de un Reporte se muestra en la siguiente figura.

j Id-Asesor : long I i Id-Confianza : long & j Espec-Asesor : string1 ..I i Calif-Asesor : long 1

Tipo- Id-TipoFalla : long 1

i IdSistema : long i Desc-TipoFalla : string)

-~ ...~ .. ~. .

.. . Reporte

. . ~ ~ -" ~

Id-Rep : long i Id-Campana : long ; Id-TipoRep : long / i Id-Conjunto : long 1 Id-Usuario : long '/

/Desc-corta : string ~ 1 ..* I

1 ..* Id-StatusRep : long ~

----iDesc-lmpacto : string I Id-Prioridad : long ~1 j Usemame-Notif : string iC.<---~~-~~ -~

1 Id-Asesor : long j 'Stat-Notif : string 'Desc-Cierre : string ~

:Calidad-Servicio : string ! Desc-larga : string j

: Fechareg-Rep : string I

l..* ; "" Falla , 1..l

- - +Id-Falla : long ~

; Id-TipoFalla : long ; Desc-Falla : string :

\

1 Nom-status : string1

. . ~ "1

, Action 1 Id-Pcdon : long

1 -1 1 Id-Reporte : long I Id-kesor : long j Desc-Mon : string / ~ i e m p o ~ l a n - ~ ~ c i o n : long; 1 Stat-kcion : long i 1 TiempoReal-Won : longi /Avance-kcion : long I !Complej-Accion : string I I Id-Problema : long I

Stat-Problema : long j 1 Avance-Problema : long '

I"" ~~~ ~~ ~ ." . .

I

I

! 1

\ i / l ..I i I

Probl i

' Id-Problema : long I Id-Falla : long I 1 Desc-Problema : string/

1 -~ . .~ I

1 ..* j I

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

4-17


4.5.2 Modelo de Análisis (Escenarios) En el esquema siguiente se puede observar la interacción entre usuarios y objetos del sistema a fin de determinar la colaboración que entre ellos exista para dar atención y seguimiento a un reporte.

''\, 10: opensheetwithpann(1d-reporte)

13: of-set-repproba'cc(l'ong, long, listbox, listbox)

Figura 4.5.7 Diagrama de Colaboración del Caso de Uso Atención de un Reporte.

4-18


4.5.3 Modelo de Diseño (Escenarios) A partir del diagrama de colaboración de Atención de Reporte se obtiene su diagrama de secuencia en esta etapa de diseño y se puede observar con detalle en la siguiente figura.

of-ggst.,aresor(bng) 7

od msncon ut d

>'

I

>

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

4-19


0 Modelo de Clases Dinámicas En la figura siguiente se muestra el diagrama de clases dinámicas de Atención de un Reporte.

-I

la

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

4-20


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

(1 ,,/ _,/' -1

+

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.

4-2 1


4.6.1.2 Modelo de Interfaz 0 Diagrama de Transici6n de Estados

La siguiente figura muestra el diagrama de transición de estados del use case Atención de una Acción.

Admón. de Reportes( Id-asesor ) Atención de Acciones( Id-asesor, d-reporte )

> Atención de Reportes > Atención de Acciones < Salir

Cancelar

Modificar( id-acción )

Aceptar I Datos correctos

Aceptar V Mensaje de Error >Actualizar datos

< Aceptar I Datos incorrectos

Figura 4.6.2 Diagrama de Transición de Estados de Atención de una Acción.

4-22


. Layouts 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.

Figura 4.6.3 Pantalla principal para el control de Acciones.

4-23


En la pantalla de la figura 4.6.4, el Asesor puede cambiar los valores de tiempo y avance de una Acción.

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

4-24


4.6.1.3 Modelo del Dominio del Problema El diagrama de clases estáticas para la Atención de una Acción se muestra en la siguiente figura.

Report . . ~

; Id-Rep : long Id-Campana : long

I Id-TipoRep : long Id-Conjunto : long

h e s o I ~ Desc-corta : string

~~

. .. -~ - ; Id-Usuario : long ~ ~ .. . "" . ~- """2

Id-hesor : long j 1 ..* Id-StatusRep : long Id-Confianza : long ~ - 1 , Desc-Impacto : string Espec-hesor : string1 ..I ~ Id-Prioridad : long Calif-hesor : long j I Usemame-Notif : string . .. . . -. . . . . .; j Id-Asesor : long

: Stat-Notif : string ; Desc-Cierre : string i Calidad-Servicio : strin! j Desc-larga : string Fechareg-Rep : string ."

.- ~ . . ~ ~. - - ~ . Tipo

". ". .~ . ' I Id-StatusRep : long j Nom-status : string 3- -

1 ..I

Accion ~ Id-Accion : long

, Id-Asesor : long I Desc-hion : string / Tiem poPlan-Accion : long I Stat-Accion : long ~ TiempoReal-kcion : long iAvance-kcion : long iComplej-Accion : string Id-Problema : long

'Stat-Problema : long j Avance-Problema : long

-I-*! Id-Reporte : long

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

1 ..*

V I ..I Proble

: Id-Problema : long i I Id-Falla : long ~ Desc-Problema : string! .~ . . I

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

4-25


4.6.2 Modelo de Análisis (Escenarios) En el esquema siguiente se puede observar la interacción entre usuarios y objetos del sistema a fin de determinar la colaboración que entre ellos exista para atender una acción que solucione un problema.

2: of-valida_asesor(Long) 3: of_get-asesor(long)

w administrar: > on asesor: uf > od asesores: u w sheet base b asesor f d asesores

1: Id-asesor + Aceptar 7 5: opensheetwithparm(¡d-asesor)

v 4: ExecSQLO

4

6: of-lIenadw(uf-i-dwestandar, integer)7: of-getdata(uf-i-dwestandar, Integer) 9: Id-repolte + Atender Accione% adman reporte : > on reDorte : uf b >od atencion reDorte : u

7 w sheet base Btencion reoorte f d atencion reoorte ~ ". '. .. .

,/'11: Id_pmblema, IdLacciÓn + Modificar 8: ExecSQLO

-A

: Asem 10: opensheetwithparm(str-reporte) 20: ExecSQLO I- A 2 "7 ~~ 22: ExecSQLO 15: ExecSQLO V > /A

od atencion a : uf 4 : BD Yoli atencion accion

w atencion acciones : w sheet base I

14: of-getdata(uf-i-dwestandar, Integer)

19: of-update-accion(long. long, long, long, long)

I I 12: opensheetwithparm(str_modificación )

V 21: of-update-problema(id-reporte, status-problema, id-problema)

16: Tpo-planeado, avance-acción + Aceptar 13: of-llenadw(uf-i-dwestandar, integer)

> w atencion acciones2 > on atenciona : uf b : w sheet base atencion accion

17: of-valida-informacion(editmask editmaslc, editmask editma* >

> 18: of-actualiza-accionflong, long, long, long, Long, long, long)

Figura 4.6.7 Diagrama de Colaboración del Caso de Uso Atención de una Acción.

4-26

Sistema Help Desk Desarrollo Practico

4.6.3 Modelo de Diseño (Escenarios) A partir del diagrama de colaboración de la Atención de una Acción se obtiene su diagrama de secuencia en esta etapa de diseño y se puede observar con detalle en la siguiente figura.

y administar. , w admon w atancion w atendon on amsor . uf on WDOR(I : uf on a t s w o n s : od 8mm es t- 8~ r : nc.on YOlI w neet b a q ntoorte. w a c c i o n ~ 4 : w a c u o n s s 2 . w 4LA.SWl b at enclon uf b atendon f d aatsores reoorte u f d u1 d atencion

Id-aatmr + Aceptar , I

ExecSaLO 1

opsnrhbatwithparml id-a~~r) I I > I

of_llanadw(ul_l_dwestandar. tnteger) I 1

ol~gatdats(uf_~_dwestandar. Integer)

I 7 ExecSaLI l

, ~

I

I

I I

ExecSOLO 7

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

4-27


O Modelo de Clases Dinámicas En la figura siguiente se muestra el diagrama de clases dinámicas de la Atención de una Acción.

7

7-7

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

4-28


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 ésta, 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.


Asesor

Help Desk

Figura 4.7.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 actualiza el Porcentaje de Avance al 100%". 8.- El Asesor indica el tiempo real dedicado a realizar la 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.

4-29


4.7.1.2 Modelo de Interfaz Diagramas de Transición de Estados La siguiente figura muestra el diagrama de transición de estados del use case Conclusión de una Acción.

Admón. de Reportes (id-asesor) Atención de Acciones( Id-asesor, id-reporte )

Atención de Reportes r - - - - 1 Atención de Acciones

. ~ .

i k 0" ~ ~ .~. . . . "> ~ ~~~ .~~~ ~~~~ ~~ ~.

Figura 4.7.2 Diagrama de Transición de Estados de Conclusión de una Acción.

4-30


Layouts E3á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.

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

4-3 1


4.7.1.3 Modelo del Dominio del Problema El diagrama de clases estáticas para la Conclusión de una Acción se muestra en la siguiente figura.

. ~~

Aseso -~ ""

Id-Asesor : long Id-Confianza : long Espec-Asesor : string Calif-Asesor : long ~ . . ~- . . ..

1 ..I 1 ..* ~

Report diRep long id-Campana : long id-TipoRep : long Id-Conjunto : long Id-Usuario : long Desc-corta : string Id-StatusRep : long Desc-Impacto : string Id-Prioridad : long Username-Notif : string Id-Asesor : long Stat-Notif : string Desc-Cierre : string Calidad-Servicio : strin! Desc-larga : string Fechareg-Rep : string . "" ~~ ~~ . ~ - -

\1/1 ..I Proble

Id-Problema : long ! Id-Falla : long Desc-Problema : string;

. ". . . - . ~~ "" ~~~ - . .

1 ..*

Acuon Id-Accion : long Id-Reporte : long Id-Asesor : long Desc-Won : string TtempoPlan-Accion : Ions Stat-kcion : long TiempoReal-Accion : Ion! Avance-kcion : long Complej-Accion : string Id-Problema : long Stat-Problema : long Avance-Problema : long

. . . . "" ~" .~ ~~~~ -~

~~~~~ ~-~~ ~ ~~.~~ ~

1 ..*

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

4-32


4.7.2 Modelo de Análisis (Escenarios) En el esquema siguiente se puede observar la interacción entre usuarios y objetos del sistema a fin de determinar la colaboración que entre ellos exista para dar por terminada una acción.

2: of-valida-asesor(long) 3: of_get-asesor(long)

w adminittrar : > on asesor: uf > od asesores: u w sheet base b asesor f d asesores

1 : Id-asesor + Aceptar 7 5: opensheetwithparm(id-asesor)

V 4: ExecSQLO

d

6: of-llenadw(uf-i-dwe&andar, integer)7: of-getdata(uf-i-dwettandar, Integer) 9: Id-reporte + Atender Accione+ admon reDorte : > on reporte : uf b >pd atendon reporte : u,

7- w sheet baw atencion reDorte f d atencion reporte ; I

~

/ll\: Id_problema, Idlacción + Modificar 8: ExecSQLO

-1

: Asesor 10: opensheetwithpam(str-reporte) A 2 ~ r' 20: ExecSQLO I':

V 22: ExecSQLO 15: ExecSQLO

> P\ od atendon a : uf 4 : BD Yoli

atencion accion w atencion acciones

: w sheet base

12: opensheetwithparm(str-rnodificación )

14: of_getdata(uf-i-dwettandar, Integer)

A 19: of-update-accion(long, long, long, long, long)

A 21: of-update-problema(id-reporte, status-problema, idgroblema)

v 16: Tpo-planeado, avance-acción. Tpo-real, Avane-problema +Aceptar

> 13: of-llenadw(uf-i-dwe&andar, integetj w atencion acdoneQ > on atenciona : uf b

: w sheet base atencion aocion >

17: of-valida-informacion(editma~ editma* editmask. editmaw

18: of-actualiza-accionflong, long, long, long, Long, long, long) >

Figura 4.7.5 Diagrama de Colaboración para el Caso de U s o Conclusión de una Acción.

4-3 3


4.7.3 Modelo de Diseño (Escenarios) A partir del diagrama de colaboración de la Conclusión de una Acción se obtiene su diagrama de secuencia en esta etapa de diseño y se puede observar con detalle en la siguiente figura.

Figura 4.7.6 Diagrama de Secuencia para el Caso de U s o Conclusión de una Acción.

4-34


a Modelo de Clases Dinámicas En la figura siguiente se muestra el diagrama de clases dinámicas de la Conclusión de una Acción.

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

4-35


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.


./H.

,/-7 Reasignacion de Accion

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.

4-36


4.8.1.2 Modelo de Interfaz 0 Diagramas de Transición de Estados

La siguiente figura muestra el diagrama de transición de estados del use case Reasignación de una Acción.

Admón. de Reportes(id-asesor) Atención de Acciones( Id-asesor, id-reporte ) ,-

e- > Atención de Reportes ~- ~ ~

¡ Atenaón de Acciones ~ -3 if ~.

, Reasignarf id-acción )

i ;i i

Figura 4.8.2 Diagrama de Transición de Estados de Reasignación de una Acción.

4-37


Layouts 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.

4-38


4.8.1.3 Modelo del Dominio del Problema El diagrama de clases estáticas para la Reasignación de una Acción se muestra en la siguiente figura.

1 !dStatusRep : long/ j Nom-status : string¡ - i ~~ ~~

Id-TpoRep : long jld-Conjunto : long ' j Id-Usuario : long :y' j Desc-corta : string ~ 1, ,*

1 1. .* j Id-StatusRep : long I ~~ ~~ ~~ -~ ~ i Dese-Impacto : string ~

Ild-Prioridad : long : iUsemame-Notif : string ~ 1 j Id-Asesor : long - -

! Stat-Notif : string ibsc-cierre : string : iCalidad-Senicio : string, r Desc-larga : string Fechareg-Rep : string

l..'

~. . .~ .~ -~ ~~~ ~ .~ - ~ . ~ . ~~~ ~

Accion Id-Accion : long Id-Reporte : long Id-Asesor : long Desc-Accion : string TempoPlan-Accion : 104 Stat-Accion : long TempoReal-Accion : long Avance-Accion : long Complej-Accion : string IdProblema : long Stat-Problema : long Auance-Problema : long

~~ ~~~ -~ ~~.

~~~~~ ~~~- ~ ~ ~~ . 4 * I . .

@..l Proble

Id-Problema : long : Id-Falla : long Desc-Problema : string

Figura 4.8.4 Modelo del Dominio del Problema del Caso de Uso ReasignacMn de Acciones.

4-3 9


4.8.2 Modelo de Análisis (Escenarios) En el esquema siguiente se puede observar la interacción entre usuarios y objetos del sistema a fin de determinar la colaboración que entre ellos exista para reasignar acciones entre Asesores.

Figura 4.8.5 Diagrama de Colaboración para el Caso de U s o Reasignación de Acciones.

4-40


4.8.3 Modelo de Diseño (Escenarios) A partir del diagrama de colaboración de la Reasignación de una Acción se obtiene su diagrama de secuencia en esta etapa de diseño y se puede observar con detalle en la siguiente figura.

>

i >

i

I i

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

4-4 1


0 Modelo de Clases Dinámicas En la figura siguiente se muestra el diagrama de clases dinámicas de la Reasignación de Acciones.

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

4-42


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 este sea Cerrado. A s í 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 \i

Cierre de Reporte \

Hdp 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 Servicios". 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".

4-43


4.9.1.2 Modelo de Interfaz Diagramas de Transición de Estados

La siguiente figura muestra el diagrama de transición de estados del use case Cierre de Reporte.

Figura 4.9.2 Diagrama de Transición de Estados para Cierre de Reporte

Layouts 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".

I

Figura 4.9.3 Pantalla de control de Reportes.

4-44


La figura siguiente muestra la pantalla de Cierre de Reportes, en la cual el usuario da una breve descripción del cierre y la calidad del servicio que recibió.

Figura 4.9.4 Pantalla de Cierre de Reportes.

4-45


4.9.1.3 Modelo del Dominio del Problema El diagrama de clases estáticas del Cierre de Reporte se muestra en la siguiente figura.

Reporte Id-Rep : long Id-Campana : long Id-TipoRep : long Id-Conjunto : long Id-Usuario : long Desc-corta : string

Id-Usuario : long Desc-Impacto : string .Id-StatusRep : long UserName-Usuario : string Id-Prioridad : long I..' l..lYom-status : string Id-Confianza : long Usemame-Notif : string

U sua no 1 1. :ldStatusRep : long TipoStatus

"Asesor : long Stat-Notif : string Desc-Cierre : string Calidad-Servicio : string Desc-larga : string Fechareg-Rep : string

1 ..*

Respuesta Id-Rep : long Id-Pregunta : long Respuesta : string

l..'

Pregunta

Id-Pregunta : long Pregunta : string

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

4-46


4.9.2 Modelo de Análisis (Escenarios) En el esquema siguiente se puede observar la interacción entre usuarios y objetos del sistema a fin de determinar la colaboración que entre ellos exista para cerrar y dar por terminado un reporte.

2: of-cierra-reporte(long, string, String)

v

Figura 4.9.6 Diagrama de Colaboración para el Caso de U s o Cierre de Reporte.

4-47


4.9.3 Modelo de Diseño (Escenarios) A partir del diagrama de colaboración del Cierre de Reporte se obtiene su diagrama de secuencia en esta etapa de diseño y se puede observar con detalle en la siguiente figura.

: Usuario Final w cerrar: w on cierre rep : od atencion

child uf b atencion reDorte : uf d : BD Yoli -

id-reporte, desc-cierre, calidad-servicio + Cerrar > 1.- El Usuario Final llena el custionario d e "Evaluaci6n de Calidad de Servicios". 2.- El Usuario Final dB el visto bueno para que el Reporte asociado a BI sea CERRADO. 3.- El sistema Help Desk cambia el status del Reporte a "CERRADO".

oLcierra-reporte(lmg, string, String)

>' of-update_ciem-reporte(lcmg, String, String)

> I ExecSQLO

>

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

4-48


Modelo de Clases Dinámicas En la figura siguiente se muestra el diagrama de clases dinámicas del Cierre de Reporte.

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

4-49


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 catálogos de sistemas, 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 subcams: Catálogo de Sistemas, Catálogo de Subsistemas, Catálogo de Fallas y Catálogo de Problemas. Los Diagramas de Caso de Uso correspondientes a dichos subcasos pueden consultarse en el Anexo 1.

4.10.1.1 Modelo de Caso de Uso

Administrador Administración de Catálogos

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

4-50


4.10.1.2 Modelo de Interfaz

Se muestran una pantalla como ejemplo ya que es muy similar en todos los subcasos (Sistemas, Subsistemas, Fallas y Problemas).

Figura 4.10.2 Pantalla general de mantenimiento de Catálogo.

4-5 1


4.10.1.3 Modelo del Dominio del Problema El diagrama correspondiente a este Modelo (Administración de Catálogos) se muestra en la siguiente figura.

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

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

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

4-52


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.

1 , GeneraLPbl 1

Figura 4.9.9 Modelo de Construcción

4-53

Sistema Help Desk Conclusiones

En estos tiempos en que la tecnología se desarrolla a grandes pasos, es necesario que tanto empresas pequeñas como grandes trabajen con sistemas automatizados que agilicen el tiempo de respuesta y disminuyan la carga de trabajo para quienes laboran dentro de estas. Un sector importante en estas empresas es aquel que hace uso de equipo de cómputo ya que es común que lleguen a tener dificultades con este y requieran de una atención rápida y precisa para solucionar sus problemas, es por ello que un sistema como el Help Desk es tan necesario para ofrecer una respuesta inmediata y adecuada en cada caso.

El Help Desk que forma parte de un proyecto de Ingeniería de Software entre la Universidad Autónoma Metropolitana Iztapalapa y Grupo Yoli, me permitió desarrollar mis habilidades en la programación así como también puse en práctica los conocimientos adquiridos en cursos como Anáfisis y Obet70 Orientado a Objetos e Ingeniená de Sofbware.

El haber participado en este Proyecto me deja muchas satisfacciones, tanto a nivel personal como académico ya que desarrollé la primera etapa del Módulo de Atención a Usuarios (Help Desk), el cual tiene como 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 Grupo Yoli, y notificar a los involucrados automáticamente, de cualquier cambio presentado en el estado de atención de reporte.

El uso de Rational Rose 98 es otro aspecto importante de mi aprendizaje 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.

El lenguaje de programación Power Builder ZO es una herramienta que permitió el desarrollo del sistema haciendo uso de una metodología Orientada a Objetos de forma fácil y transparente.

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.

5-1

Sistema Help Desk Bibliografia

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

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

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

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

6- 1

Sistema Help Desk Anexo 1

- 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.

Administrador A\ Administrador "---?A

Help Desk

Figura AL1 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.

Al-1


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

Administrador A\

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.

Al -2


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

Administrador A\

Help Desk

Figura AL3 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.

Al -3


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

Administrador A\

Help Desk

Figura A1.4 Diagrama de Caso de Uso Insertar Subsistema

PASOS:

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

Al -4


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

Administrador A\

5?/ 7 Modificar Subsistema

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 cat6logo.

Al -5


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

Administrador A\

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.

A1-6


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

Administrador A\ 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.

Al -7


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

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.

A1-8


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

Administrador A\

Help Desk

Figura A1.9 Diagrama de Caso de Uso Eliminar Falla

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

Al -9


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 Al.10 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.

A1-10


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

Administrador A\ Modificar Problema

Help Desk

Figura Al.11 Diagrama de Caso de Uso Modificar Problema

PASOS:

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

Al-11


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

Administrador A\ A

Eliminar Problema

Help Desk

Fiqura 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 catAlogo.

Al-12


ANEXO 2 Diagramas de Colaboración Secundarios

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

: Bd Yoli

: Administrador 2: of_insetta-sistema(desc-sistema) 1

A l 4: ExecSQLO

; \ j ; j

!

Figura A2.1 Diagrama de Colaboración 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.

: Administrador 2: of-modifica-sistema(desc-sistema, id-sistema)

: BQ Yoli

Figura A2.2 Diagrama de Colaboración Modificar (Catálogo de Sistemas)

A2- 1


Catálogo de Sistemas - Eliminar EI siguiente diagrama corresponde al escenario Eliminar del Subcaso de USO Catálogo de Sistemas.

(-J ~~-~ - > /w cat sistemas : , A 1: id-sistema + Eliminar ~. . ~

~ . I w sheet base : BC/ Yoli I

I ." .. ~~~~~

: Administrador 4: execSQLO

Figura A2.3 Diagrama de Colaboración 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: desc-subsistema + Guardar

~~ -.> jw cat subsistemas . . . ~ . . . . . -, 1 : w sheet base

~

,- - ~~

: Administrador

: B( Yoli

4: ExecSQLO

.. .

Figura A2.4 Diagrama de Colaboración Insertar (Catálogo de Subsistemas)

A2-2


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

1: desc-subsistema + Modificar " . . "" "" ~-

(7 jw cat subsistemas '

A L# .~ . - - j : w sheet base

I

!. . ~~~ "~ "

: Administrador

\'/

A : Bd Yoli

2: of-modifica-subsistema(d&c-subsistema, id-subsistema) I I ! I

; 3: of-update-subsistema(desc-subsistema, id-subsistema)--l--- -

:on cataloaos : urj 1 0 ~ 1 cataloaos : u4 ~ b catalwos ~ - - I d catalwos i . .

i

Figura A2.5 Diagrama de Colaboración Modificar (Catálogo de Subsisternas)

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

: Administrador

: Bd Yoli

4: ExecSQLO i

A ;

2: of-elimina-subsistema(id-subsistema) / I \ ~

Figura A2.6 Diagrama de Colaboración Eliminar (Catálogo de Subsistemas)

A2-3


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

: Administrador 2: of_nserta_falla(desc-falla, id-subsistema)

, 1

: v I 3: of-set-hlla(desc-hlla, id-subs

ion catalwos : uf . . "9 j b catalwos ,- -~

- . .

Figura A2.7 Diagrama de Colaboración Insertar (Catálogo de Fallas)

: Bd Yoli

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

1: desc-falla . . .. - ... - . .... . .

2 -T- A

" . ~ w cat fallas : w~ x - ~ -1 sheet base I : Bd Yoli

~

I"~"""." ~ .!

: Administrador 4: ExecSQLO

~1 2: of_modifica_falla(desc_falla, id-falla) /I\ I

' V , !

I

- .. .." ~" "" 3: of-update-falla(desc-falla. id-falla)--- . i - - - -!

,on catalwos : uf ------> j o d catalwos : 4 4 d catalwos ~

Figura A2.8 Diagrama de Colaboración Modificar (Catálogo de Fallas)

A2-4


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

0 A : Bd Yoli

4: ExecSQLO 1 1

Figura A2.9 Diagrama de Colaboración Eliminar (Catálogo de Fallas)

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

1: descgroblema + Guardar A : B d Yoli

Figura AZ.10 Diagrama de Colaboración Insertar (Catálogo de Problemas)

A2-5


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

1 : descgroblema + modificar-^._- ~

iw cat Droblemas : j --! w sheet base : l3Lj Yoli

! I -. .. "" .. ". . -

: Administrador 2: of-modificagroblema(descgroblema, idgroblema) 4: ExecSQLO

Figura A2.11 Diagrama de Colaboración 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

4.

: Administrador 2: of_eliminagroblema(idgroblema)

V

Yoli

4: ExecSQLO

A2-6


ANEXO 3 Diagramas de Secuencia Secundarios

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

: Administrador y Cat ' In 'Ota' w sheet base gf b cataloaos y

oaos : gd cataloaos : f d catslows

: BD Y d i

desc-sistema + Guardar l . El Adminisirador escribe la descripcibn

> I

del sistema. 2. EIAdminisiraador presiona el botbn guardar. 3 . E l Sistema Help Desk actualiza el CetYogo.

of-inserta_sistema(desc_sistema) I I > ,

of_set_sistema(desc_oist~ma)

>' ExecSQLO I

> I

~ ~ ~

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

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

1. El Administrador escribe la nueva rlescripcibn del Sistema.

2. El Sistema Help Desk actualiza el catálogo.

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

A3- 1


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

descgmblema + Modificar ~ "" 3;

1. El Administrador ~ I escribe la nwva ; of_modificagroblema(des;_problema. id-problema) descripción del problema

2. El Sistema Help , Desk actualiza el cat&logo.

, L

.~ __" j ' ~

- 8

of-updategroblema(descgroblema, id-problema) .,

1 : ~~ ~. 3:

Ll ~ ExecSQLO 7" I

I

Figura A3.11 Diagrama 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.

2. El Sistema Help Desk a c t u a l i z a el Catálogo.

of-update-pmblema(id-problema) ~~ . ~ "3 ̂;

: : 1 :

." I

" ExecSQLO '

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

A3 -6

DIVISI~N DE CIENCIAS BASICAS E INGENIERIA DEPARTAMENTO DE ...148.206.53.84/tesiuami/UAM1959.pdf ·...

Documents

Transcript of DIVISI~N DE CIENCIAS BASICAS E INGENIERIA DEPARTAMENTO DE ...148.206.53.84/tesiuami/UAM1959.pdf ·...