1 Modelo de Casos de Uso 4.10.1.2 Modelo de

(1)

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:

(2)

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.1 Modelo de Casos de Uso

4.5.1.2 Modelo de Interfaz

4.5.1.3 Modelo del Dominio del Problema

4.5.2 Modelo de Análisis (Escenarios) 4.5.3 Modelo de Diseño (Escenarios) 4.6 Caso de Uso Atención de una Acción

4.6.1.1 Modelo de Casos de Uso

(3)

Sistema Help Desk Contenido

4.6.1.2

Modelo de Interfaz

4.6.1.3

Modelo del Dominio del Problema

4.6.2

Modelo de Análisis (Escenarios)

4.6.3

Modelo de Diseño (Escenarios)

4.7

Caso de Uso Conclusión de una Acción

4.7.1

Modelo de Requerimientos

4.7.1.1

Modelo de Casos de Uso

4.7.1.2

Modelo de Interfaz

4.7.1.3

4.7.2

4.7.3

4.8

Caso de Uso Reasignación de Acciones

4.8.1

4.8.1.1

4.8.1.2

Modelo de Interfaz

4.8.1.3

4.8.2

4.8.3

4.9.1

4.9.

l.

1

4.9.1.2

Modelo de Interfaz

4.9.1.3

4.9

Caso de Uso Cierre de Reporte

4.9.2

4.9.3

4.10.1

4.10

Caso de Uso Administración de Catálogos

4.10.

l.

1

4.10.1.2

Modelo de Interfaz

4.10.1.3

4.10.2

4.10.3

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)

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

(5)

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

(6)

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

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.

(7)

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

(8)

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

(9)

Sistema Help Desk Marco Teórico

v€Tsión o

-

...

... -

V&ón 1

Ajustes a la Especilicación

Análisis

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

(10)

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:

(11)

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.

(12)

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,

(13)

Sistema Help Desk Marco Teórico

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.

(14)

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

(15)

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

(16)

Sistema Help Desk Marco Teórico

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

(17)

Agmga a la 0D y

c o n t i n w A g r w d o 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.

(18)

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

(19)

Sistema Help Desk Marco Teórico

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.

(20)

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.

(21)

Sistema Help Desk Marco Teórico

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. objeto, esto desde el Painter de Librerías, el cual se puede accesar desde la barra principal. Desde el Browser el cual también se accesa desde la barra principal.

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

(22)

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

(23)

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

(24)

Sistema Help Desk Desarrollo Práctico

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.

(25)

Sistema Help Desk Desarrollo Práctico

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

(26)

Sistema Help Desk Desarrollo Práctico

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.

D U G R A U A G E N E R A L E C A S O S D E U S O

(27)

Sistema Help Desk Desarrollo Práctico

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 : olng 1

Dese-Tipocambio

1 :.

Falla

Respesta : string 1 .:

1. 1

Problema 1 :. Id-Prcblema : lag

Id-Falla: long Desc-Prabkma : string

(28)

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.

(29)

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

(30)

Sistema Help Desk Desarrollo Práctico

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.

(31)

Sistema Help Desk Desarrollo Práctico

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

(32)

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

(33)

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 s e 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 l e w w : 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

(34)

0 Diagrama de Clases Dinámicas

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