Helpdesk

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: LICENCIADOEN COMPUTACI~N. Sistema Help Desk Contenido CONTENIDO l . PRESENTACION DEL TRABAJO 1.1Introducción 1.2 Motivación del Proyecto 1.3 Estructura 1-1 1-1 1-1 1-1 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 Modelode Casos 3.5.2 Modelo de Interfaz 3.5.3 ModelodelDominiodelProblema 3.5.4 ModelodeAnálisis 3.6 Programación en Power Builder 7.0 4.DESARROLLOPRACTICO 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 ModelodeRequerimientos 4.4.1.1 Modelo de Casos de Uso 4.4.1.2 Modelode Interfaz 4.4.1.3 Modelo del Dominio del Problema 4.4.2 ModelodeAnálisis(Escenarios) 4.4.3 ModelodeDiseño(Escenarios) 4.5 Caso de Uso Atención de un Reporte 4.5.1 ModelodeRequerimientos 4.5.1.1 Modelo de Casos de Uso 4.5.1.2 Modelode Interfaz 4.5.1.3 Modelo del Dominio del Problema 4.5.2 ModelodeAnálisis(Escenarios) 4.5.3 ModelodeDiseño(Escenarios) 4.6 Caso de Uso Atención de una Acción 4.6.1 ModelodeRequerimientos 4.6.1.1 Modelo de Casos de Uso 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 Modelode Interfaz 4 . 6 . 1 . 3 Modelo del Dominio del Problema 4 . 6 . 2 ModelodeAnálisis(Escenarios) 4.6.3 ModelodeDiseño(Escenarios) 4.7Caso de Uso Conclusión de una Acción 4.7.1 ModelodeRequerimientos 4 . 7 . 1 . 1 Modelo de Casos de Uso 4.7.1.2 Modelode Interfaz 4.7.1.3 Modelo del Dominio del Problema 4.7.2 ModelodeAnálisis(Escenarios) 4 . 7 . 3 ModelodeDiseño(Escenarios) 4.8Caso de Uso Reasignación de Acciones 4.8.1 ModelodeRequerimientos 4 . 8 . 1 . 1 Modelo de Casos de Uso 4.8.1.2 Modelode Interfaz 4 . 8 . 1 . 3 Modelo del Dominio del Problema 4 . 8 . 2 ModelodeAnálisis(Escenarios) 4 . 8 . 3 ModelodeDiseño(Escenarios) 4.9Caso de Uso Cierre de Reporte 4 . 9 . 1 ModelodeRequerimientos 4 . 9 . l. 1 Modelo de Casos de Uso 4.9.1.2 Modelode Interfaz 4 . 9 . 1 . 3 Modelo del Dominio del Problema 4.9.2 ModelodeAnálisis(Escenarios) 4.9.3 ModelodeDiseño(Escenarios) 4.10 Caso de Uso Administración de Catálogos 4.10.1 Modelo de Requerimientos 4.10. l. 1 ModelodeCasosde Uso 4.10.1.2 Modelo de Interfaz 4.10.1.3 Modelo del Dominio del Problema 4 . 1 0 . 2 Modelo de Análisis (Escenarios) 4.10.3 Modelo de Diseño (Escenarios) 4.11 Modelo Construcción de 5. CONCLUSIONES 6. BIBUOGRAFIA 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 7. ANEXOS Anexo 1 Diagramas de Casos de Uso detallados Anexo 2 Diagramas de Colaboración secundarios Anexo 3 Diagramas de Secuencia secundarios a1-1 A2-1 “1 Guerreroyse encarga de distribuir en todo el estado.0 para la parte de construcción. en donde se desarrollan proyectos.Help Sistema Trabajo 1. utilizado por los alumnos de proyecto terminal de la Licenciatura en Computación. Dicho convenio permitirá que se pueda incrementar los recursosdesoftwareyhardwarealLaboratoriodeIngenieríadeSoftware. Se dividen en objetivos generales y objetivos particulares.2 Motivación del Proyecto El hecho de trabajar en un proyecto que será utilizado en la Empresa Grupo Yoli de Acapulco. 1-1 .yaquedurante nuestra vida universitaria no siempre se tienen este tipode experiencias.elanálisis. Otro de los alicientes que tuve fue utilizar técnicas de Ingeniería de Software para el desarrollodelsistemaHelpDesk. 1.fue miprincipalmotivodeingresoadichodesarrollo. administración y atención de reportes de problemas en todo tipo de equipos con que cuenta la empresa.3 Estructura El presente trabajo describe en forma extensay detallada toda la documentación del Proyecto Help Desk.comolaplaneacióndeactividades. el cual se desarrolla gracias a un convenio entre la Universidad Autónoma Metropolitana unidad Iztapalapa y Grupo Yoli. diseño y construcción basado en la metodología Orientada a Objetos utilizando UML. El presente trabajo se encargará del desarrollo del Módulo de Atención a Usuarios los procesos de (Help Desk). y notificar a los involucrados automáticamente. GrupoYoliesunaempresa particular dedicada al embotellamiento de Coca Colay otros productos. no sólo paradichaempresa. Describen las metas que se esperan alcanzar y cubriralfinalizarel proyecto. 1. talescomoelproyectodeEducaciónaDistanciaparaladivisiónde Ciencias Sociales y Humanidades (CSH). de cualquier cambio presentado en el estado de atención de reporte. Susoficinascentrales se encuentranenAcapulco. se hizo uso de herramientas actuales como Rational Rose 98para la parte del análisis y Power Builder 7. Se pretende que Help Desk sea una herramienta que permita automatizar totalmentetareasdeatenciónausuariosdeinformática.1 Introducción Help Desk forma parte de un proyecto general de Ingeniería de Software.sinotambiénparala propia UAM.ayudandoaagilizar los procesos de solución de problemas y de toma de decisiones. el cual tiene como propósito general automatizar levantamiento. Para llevar a cabo lo anterior. Este documento está estructurado de la siguiente manera: Objetivos. En este punto se encuentran descritos los modelos de Requerimientos. metodologías y herramientas utilizadas para el la cual se encuentralabasedelProyecto.Help Sistema desarrollo del proyecto. Conc/usiones. así como la base que sustenta las técnicas y metodologías utilizadas. tal como Manual de Usuario. etc.Expresan todo lo que se vivió a lo largo del proyecto. de Análisis. etc. Entre ellasse encuentran libros. Anexos. de Diseño y de Construcción. es la documentación quese realizó a lo largo de todo el desarrollo del Módulo. Desarro//o práctico. Marco teóEco: Explica las técnicas. así como algunos otros puntos que es necesario mencionar. así como experiencias de cada uno de los participantes. los cuales pertenecen a la metodología de Orientación a Objetos utilizandoUML. Sontodaslasfuentesdeconocimientoquefueronempleadaspara anteriores.Es laparteen las poder desarrollar este proyecto.es decir. diagramas secundarios. Manual de instalación. Es todaaquelladocumentaciónquenoestácomprendidaen Bibfibgrafla. manuales. los puntos 1-2 . 2 Objetivos Específicosdel 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. tanto en análisis y diseño como en construcción.1 . Generar información que facilite la toma de decisiones. Reasignación de acciones aotro Asesor. El desarrollo de un módulo que facilite su mantenimientoconrespectoacambios enrequerimientosycorreccióndeerroresnodetectadosenfasespreviasasu utilización. los usuarios.1 Objetivos Generales del Proyecto DesarrollarelProyectoutilizandounametodologíaOrientadaaObjetos.Sistema Help Desk Objetivos 2. a cada reporte registrado de una manera oportuna y eficiente. Registro de encuestas de calidad de la atención por parte de Configuración de las comunicaciones a los involucrados. Estar integrado con otros módulos del Sistema de Información del Grupo Yoli. 2. La generacióndeunmóduloquepermitadaratenciónausuariosdeequipode cómputo de manera eficiente. 2. Generación de reportes de atención por mantenimiento preventivo. Administrar y darle seguimiento. hasta su conclusión. Enterara los involucradosenunreportedecualquiercambioqueendicho reporte se presente. Estnkturado . Orientados por la informaci6n "" _ > . pero todas contemplan una serie de pasos y una motivación especial para su aplicación.Gane-SaBon .~ Estructurados Orientado-por los Datos Oflentado Objetos _ I . Yourdon Otros PSÚPSA UML "odelo . Hay diferentes tipos de Métodos para el Análisis y Diseño de Sistemas. 3. Esto es ya que no se sigue una metodología para el Análisis y Diseño.existeunsinnúmerodeposiblesformasde hacerlo.Sistema Help Desk Teórico Marco & MARCO TEORICO 3. los cuales se pueden apreciar en la figura3..1 Metodologías de Análisisy Diseño de Sistemas Para larealizacióndeunaactividad.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.1. 3-1 .Ward-Nlellor Relaciona1 -Entidades v Asociaciones Jackson JSD DSSD Coad-Yourdon -Martin-Odell -Rumbaugh OMGlOMT -BoOCh GOOD (NASA) Seidewitz-Stark -HOOD QOSD Wassennan-Pircher -0OJSD -0ODLEIOOSA Shlaer-Mellor CRC y RDD BeckCunningham Fig.2.SADT (IDEF) Ross . J .1.sf& Orr modem0 .1. Bajo un enfoque genérico todas las filosofías de desarrollo contemplan los niveles mostrados en la figura3. M&odos de Análisis y Diseiio Orientadós-por las funciones ~.SASS De Marco .1.. donde cada adecuación surge como un prototipo por si mismo.2 Componentes de las filosofias de desarrollo Como podemos ver. 3. En esta Arquitectura se plantean los principiosparalasformasdetrabajo. a sí mismo.Sistema Help Desk Teórico Marco Herramientas Procesos h45tctdo Arquitecbm /a \\ Fig. cada paso del Método es un Proceso del Desarrollo. ya que al final de cada prototipo. Y para la elaboración eficiente de cada Proceso. 3. es la forma en la cual se visualiza la secuencia y los criterios de pasos para la construcción de "algo". por medio del cual se van cubriendo etapas del desarrollo del Sistema.1. propone Métodos que describen la forma de generar productos del Desarrollo por prototipos El desarrollo por prototipos limita el riesgo que se adquiere durante la realización de un Sistema. si no los llegó a cumplir.2 La arquitectura.2. se tienen puntos de evaluación en los cuales se decide si el prototipo cumplió con los requerimientos proporcionados por los usuarios.1 3 -2 . que es donde residen los otros componentes (Método. se utilizan Herramientas que son las que soportarán las actividades de cada proceso. desarrollo.comopuedeserlaformadeorganizarlas actividades y el enfoque que se debe de adoptar para resolver cada problema. acotando el riesgo que se adquiere de versión en versión. se deberán hacer adecuaciones. a esto se le llama Arquitectura de Desarrollo. Estos métodossonlasecuenciadepasosnecesariospararealizarel desarrollo del Sistema. la base de la pirámide es la Arquitectura. Procesos y Herramientas). La forma de un modelo por prototipos puede verse en la figura 3. .. aprendizaje de uno con la experiencia de los otros. Tercer prototipo. si se encuentran fallas que tengan un peso considerado.Sistema v€Tsióno - V&ón .Enningúnmomentose pierde el control de las actividades y entregables que seestángenerandoconel prototipo. sine para generar versiones sauientes que sean utiizables. generalmente se establece que en un proyecto debe generarse de 3-3 . solamente se registran en una bitácora para luego corregirlas cuandose genere el siguiente prototipo.. Con este tipo de desarrollo. los desarrolladores podrán hacer simultáneamente el análisis y la programación ya que se estaráncreandosistemasbasadosencomponentes.e debe generar un prototipo con mayor füncionafidac$ con que en la versión anterior. Cada prototipo está formado por: Primer prototipo= El equipo de desarrollo se debe hnifiarkar con el problemaf debe se debe establecer una prkvera versión de los determinar las fünciones prindpalesf requen-mientos. se deben generar los almnces más amplios requerimientos definitivos del sishema.Cadaproyectoes distinto a otros. 3 . Segundo prototipo: S. 1 Modelo por Pmtotipos Mientras avanza cada proceso.nose intenta corregirlos en ese momento. Es necesarioque la duracióndel prototipo noseamuylarga.. 1 Ajustes a la Especilicación Análisis c Diseño c 4 Programación Pruebas Previas Implantación c .0: Incorpora totalmente operacional. Es la prlinera versión utifizable del si3temaf no contiene detalles especficos. y es Con esta forma de desarrollo se logra la retroalimentación entre los desarrolladores de tal forma que se establece una correspondencia entre el y los usuarios. todos los requen?nientos encontrados Prototipo Versión 1. 2 . Implantaoi6n Fig. es una descripción de aspectos relevantes para cada proceso del desarrollo. Cada modelo es una forma de visualizar el sistema en distintos momentos del desarrollo.3. Susprocesos se centran en la elaboración de Modelos del Sistema. cuando se le incorpora el modelado conceptual y el diseño por bloques. los óvalos refieren se a los procesos.1 Proceso Ingeniería de de Los Software Orientada a Objetos (ISOO). La reutilización debe hacerse en todos los niveles y no sólo en los componentes de programación. esdecir. la ISOO incluye el levantamiento de requerimiento como actividad principal.Poresto. reducen la ansiedad de los usuarios y delos directivos de las organizaciones.la arquitecturadedesarrolloconorientaciónaobjetosbasándoseenla metodología de Ingeniería de Software Orientada a Objetos (ISOO) propuesta por Jacobson. así que es conveniente dividir el tiempo disponible en partes igualesparacadaprototipo.3 Metodología Orientada a Objetos Esta metodología se crea a partir de la programacion Orientada a Objetos. es necesario contar con las herramientasquepermitandichareutilizaciónanivelesaltoscomoelenfoquede OrientaciónaObjetos.1. Pntehas La arquitectura de desarrollo plantea que cada proceso aplique conceptos de Orientación a Objetos. se rectángulos a los distintosmodelosque generan.Marco Sistema Help Desk tres a cinco versiones. Es importante señalar que el desarrollo por prototipos supone que cada versión se inicia desde cero. Rquerirrientos dd I klarin Modelo Pnilisis nimmim V Moddo de Pnilisis * Modelo de Rquximientcs Modelo de as€ñ0 Modelo de Fig.Conintervaloscortos. para lograr esto. se utilizará la Programación Orientada a Objetos. aunque estos no sean los definitivos.sepuedenmostrarresultados rápidamente. Los procesos junto con los modelos que generan son: 0 0 0 Análisis Construcción Pruebas Modelos de Análisisy de Requerimientos Modelo de Diseño y de Implantación Modelo de Pruebas 3-4 . 3. Los procesos que la integran son los que se muestran en la figura3.3. 3. cada modelo. Requerimientos estructura original.4.Herencia. el enfoque se basa en el concepto de objeto.DiagramasdeComponentes. DiagramasdeClases. larealidad se puedeestablecercomounconjuntodeobjetosque interadan entre sí a través del enfoque Orientado a Objetos. verbal del usuario proporciona al equipo de desarrollo Usuario Es eldestiladodelaEspecificación de Requerimientospuesto en un Modelo de el cual permite su actualización sin cambiar la formato estándar. sea 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. Ya que todos los 3-5 . UML es una herramienta notacional.Asociaciones. el cual es: T i 0 aquello que pueda d-dinguirse denfro del universo de la apkcadón que único.Como podemosver.talescomoDiagramasde Casos. muestra los casos más relevantes de prueba Análtsis Plantea las interacciones básicas de los objetosquecompondrán el Modelo de sistema Modelo de Disí70 Muestra a detalle la interacción de los objetos Describe la constitución modular de los componentes del sistema.4 Conceptos fundamentales de la Programación Orientada a Objetos El enfoque de orientación a objetos es una forma de observar la realidad. Construcción y Pruebas. Dentro de la definición de objetos encontraremos algunos que serán muy parecidos yaquepuedencompartirlamismadefinicióndecaracterísticas. 3.DiagramasdeEstados. Los objetospuedenestarcompuestosde otros objetosmáselementales. Modelo de Construcción también su programación en un lenguaje de programación Muestra la estrategia de pruebasdecadaelementodel sistema desde Modelos de un nivel objeto hasta un nivel de integración de los componentes Pruebas Existen varias docenas de notaciones distintas para la descripción de conceptos de OrientaciónaObjetoscomopuedenserlasClases. Los conceptos fundamentales de la programación Orientada a Objetos se describen a detalle en la sección 3. que apoya los procesos de Análisis. UML permiteincorporartodos los conceptosplanteadosenlasmetodologíasmás importantesdedesarrolloconOrientaciónaObjetos.Sistema Help Desk Teórico Marco Donde: Requerimientos de Información escrita.etc. etc. Esta notación recibió el nombre de Lenguaje Unificado para Modelado (UML). establece la Estructura Funcional del sistema. 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. AI unirse los metodistas más importantes de Orientación a Objetos (Grady Booch. todos los objetos se generan a partir de clases. 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. en otras palabras. Este encapsulamiento contempla lo que otros objetos pueden ver de un objeto dado. 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. a cada objeto generado se dicequeesunainstanciadelaclase. El concepto de herencia.elcualtendrálas propiedades y funciones indicadas en la clase. En el enfoque orientado a objetos.lasegundacontendrálaspropiedadesque debe tener cada objeto y la tercera contiene los métodos por medio de los cuales. objetos generados a partir de ellas. 3-6 . pues lo que interesa de ellos es lo que puedan realizar y no como lo hagan. va asociado a la Especialización en donde se establece que cierta clase de objetos puede tener clases de objetos más especializadas. se modificarán las propiedades de los objetos. se puede establecer que son obtenidos de la misma plantilla. tienen todos los elementos de la clase genérica y pueden modificar la funcionalidad heredada o pueden agregar una nueva funcionalidad para especializarse. no existen las clases. Tomando en cuenta el punto de vista de los desarrolladores. son instancias de esas clases. Es importante aclarar que dentro de este documento. el diseño y la programación. a esta propiedad se le llama encapsulamiento. Los objetos tienen una conceptualización interesante. durante el análisis. las cuales por ser especializaciones. esta plantilla. las clases existen en los momentos en que se está relacionado varios objetos de la realidad. El polimorfismo se define como la característica de que el objeto que pide la ejecución de una función a otro objeto. A la característica de que las subclases tomen definiciones de la clase principal se conoce como Herencia. objetosestaránautorizadosparahacerreferenciaalapropiedad visibilidad protegida es cuando se establece untipo de visibilidad de acceso para que propiedades y funciones sean referenciables por código de funciones de subclases dentro de la jerarquía.Sistema objetos se parecen. la primeraindicaelnombredela Clase. la notación que se utilizará seráladeUMLyaqueenlaactualidadeste tipo denotacióneslaquetienela mayoraceptacióndentrodelacomunidaddedesarrolladoresconOrientacióna Objetos. funciones que serán comunes a todos Cada clase se representa a través de un rectángulo en el que hay tres divisiones. no necesita saber la naturaleza del objeto dueño de la función. A Una clase es una ayuda notacional en el análisis para establecer las propiedades y los objetos que se generen a partir de ella. la visibilidad am@o escuando se puededefiniruntipodevisibilidadenlaque sólo algunos o alafunción. se le llama Clase. sin embargo en el momento en que se ejecuta la aplicación. lo que sí existe. lo cual se da durante la etapa de levantamiento de requerimientos. La multiplicidad es de gran valor cuando se está haciendo el Modelo de Requerimientos del sistema. En la agregación simple. Estas asociaciones son muy útiles ya que permiten la estructuración de los objetos incorporando reglas de negocio. sino que además uno es parte del otro. A las clases que generan directamente objetos se les denomina concretas. 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. la cual ya ha sido descrita en párrafos anteriores. Un criterio para determinar el tipo de agregación esrevisarlamultiplicidaddela asociación. una de las más frecuentes es a través de Asociaciones Estáticas. lo másseguroesque se tengaunaagregaciónsimple. 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.escasi seguro que se tiene una agregación de composición. Dentrodeunajerarquíadeherencia. de una flecha hueca que apunta a la clase ascendente. La asociación se indica con una línea uniendo a las dos clases. a este desituación se le llamaasociacióndeagregación.alasclasesquenogenerandirectamente ningún objeto se les llama abstractas. En lamultiplicidadel "*" indicaqueeldatodeunainstanciadelaasociaciónes desconocidoalmomentoenque se realizaelanálisis. Si se tieneunamultiplicidaddeunoauno. mientras que la agregación simple es con el rombo vacío. Dentro de una estructura de herencia. los Un caso particular de una asociación estática. a la agregación por composición se le denota con el rombo sólido. si se tiene una multiplicidad de uno a varios. A laagregaciónselepuede establecer en dos tipos: composición y simple. 3-7 .EnUML la relación de herencia entre dos clases. las clases que heredan se dice que son clases descendientes y de las que se hereda son se indica por medio ascendentes. Los objetos se relacionan con otros de varias formas. el otro también desaparecerá así como la asociación.unaasociacióntieneuna dirección. ya que ayuda a validar los requerimientos con usuarios y clarifica situaciones de ambigüedad. Unavezexplicado lo anterior. 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. Debe recordar que la notación que diagramas es UML.Sistema Help Desk Marco Teórico La herenciaesunode los mecanismosmásimportantesparapoderasegurarla reutilización de componentes.elentendimientodelAnálisis y DiseñoOrientadoa se utilizará en esquemas y Objetos será mayor. es cuando se encuentra que un objeto tipo no sólo está asociado con otro. los objetos pueden crearse en tiempos distintos y la asociaciónse da en cualquier momento después de que existen los dos objetos. la cual indica la forma de navegar en la asociación para encontrar una y sólo una instancia. En agregación la por composición los objetos asociación la y se dieron simultáneamente y cuando desaparezca un objeto. Muchas reglas de negocio se refieren a los niveles máximos y mínimos de vinculación entre distintos objetos de la aplicación. 3 Problema se explica respectivamente.Sistema 3. El objetivo principal no es el levantar el requerimiento. Modelo de Interfaz: Establéce el whculo visual entre desamlladory usuario para su entorno concretar aspcbos de la interacción que el sistema pudiese tener con externo. 3. En el proceso de Análisis de Requerimientos.no sólo será de capacitación. el efecto de manejar requerimientos erróneos es muy grave. conocimiento el que adquieren los desarrolladores es muy limitado.5. también debe aprovecharse para establecer los requerimientos básicos del sistema.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. ya establecido el modelo de requerimientos.5.1. se establece el modelo dinámico del sistema para poder conocer las características principales de la estructura del sistema. por lo que no se obtendrá el sistema que espera el usuario. 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.estaadquisicióndeconocimiento.5. pues constituyen los elementos de entrada para el proceso de desarrollo y todas las etapas del desarrollo se basan en los requerimientos. Dominio del Problema: E3tablece los principales objetos que constituirán Modefo del al sistema y sus relaciones entre SL Casos. Lo primero que se tiene que hacer es involucrar a los desarrolladores en la problemática del usuario. La descripción del Modelo de 3-8 . En el Proceso de Análisis de Requerimientos es donde se recolectan todos los requerimientos del usuario. Modelo de Interf-az y Modelo del Dominio del con mayor detalle en las secciones 3. pero luego se llega a un punto en el que se entienden los conceptosfundamentales. sino que el equipo de desarrollose familiarice con el problema.2 y 3. siendo la base para establecer la estructura del sistema. los cuales a su vez generan dos modelos que son el Modelo de Requerimientos y el Modelo de Análisis Dinámico. de tal forma que si se tienen requerimientos equivocados se creará un sistema que cumplirá tales requerimientos. AI principio. ya que están haciendo suposiciones de transacciones perfectas. en En notación UML este modelo se plantea por medio de un Diagrama de los cuales los casos se describen por medio de óvalos con el nombre del Caso. sólo se agregayenelpeorde los casos se estaráreemplazandouncasocompletoporotro. estos actores. a este agente se le conoce como Actor. en ciertos casos es necesario documentar información la referente situaciones a de excepción.5. En este modelo cada transacción recibe el nombre de Caso. Lo importante es plantear las transacciones más significativas y no las secundarias. no sólo con su nombre sino también la secuencia de pasos necesarios para llevarlo a cabo. el cual necesita que se especifique. Los casos normales no incluyen información acerca de decisiones.1 Modelo de Casos Marco Teórico Es necesario preguntar al usuario que es lo que quiere que haga el sistema para que los desarrolladores estén conscientes de ello. sólo causan confusión y pérdida de atención a los que realmente son importantes. no forman parte del sistema.5. sonlos que interactúan con éI a través delos Casos. pues sólo se incorpora como especialización endondecorresponda. se está en posición de documentarlo en una herramienta Case que permita la definición delos casos. 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.no se corrigenada.1. como 3 -9 . entendiendo como transacción cualquier interacción que el sistema tendrá con los agentes externos aél. Un actor no necesariamente tiene que ser una persona (puede ser otro sistema). gracias a esto.de tal formaquela estructura funcionalbásica de las transacciones del sistema nose ve alterada. El modelo de casos permite la incorporación de conocimiento no considerado en la etapa de requerimientos normal. 3. Actor Fig. Cada iteración con el sistema será realizada por un agente externo a éI.5. Este modelo plantea que todo principio sea el establecer las principales transacciones que contendrá el sistema.1 Nombre de' Diagrama de Casos Una vez descrito el caso por parte del usuario. se elimina gran cantidad de transacciones que en este momento del desarrollo. Casos. También es posible establecer asociaciones estáticas entre casos pues son clases.los actores se describen por medio de la figura de alambre de una persona como lo podemos ver en la figura3. El número siete es una referencia sobre la cual se puede tener más o menos transacciones. La relaciónentre los actores y los casos se muestra con flechas.Sistema Help Desk 3. La elaboración de estas pantallas. cada caso tiene su propio Actor y están relacionados entre sí.5. las interfaces son pantallas. La formadedenotarloesnuevamente con relaciones de herencia.5. 3-10 . para hacer esto. particular que debe entenderse como una extensión al comportamiento del Hay otro tipo de Caso. se utilizan Diagramas de Transición de Estados (figura 3.2 Caso que tiene otro caso como Extensión Fig. está formado por la definición de las interfaces principales que participarán en la ejecución de un caso cuando el sistema exista.Sistema Desk Marco Teórico transacciones en las que es necesario pedir autorización o marcarunerror.5.3). este se dacuandoutilizadeotros Casos pararealizar transacciones que puede darse de forma similar a través de relaciones de agregación o composiciónentrecasos.4). pero con el estereotipo de Uso (figura 3. pueden hacerse bajo herramientas visuales o a mano en papel.2 Modelo de Interfaz Este modelo establece un vínculo entre el Usuario y el Analista mostrando cada Caso de forma gráfica. reportes o llamadas a otros sistemas. la relación deherenciasimplementeespecificaunaespecializaciónperoconunsignificado Caso.3 Caso que usa otros Casos para realizar su actividad 3.2).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. debe ser muy rápida y sin emplear demasiados recursos visuales ya que por el momento no son relevantes. Generalmente se toma como "regla" que cada caso tendrá de dos a tres pantallas que se pueden considerar como significativas. 3.5.5.5. Actor Caso <<tictiende>> Actor Caso Actor Caso Caso Caso Caso Fig. Se tiene que mostrar la forma en que se iránactivandodependiendodelainteracciónquetengaelusuarioconel sistema. 3. 3. ~ . La informaciónquecontendránlasclasespuede ser: 4 Información de referencia. cambia a una pantalla en donde podrá capturar informaaón la cada registro.Una clase debe generar más de un objeto. . ..elidentificar los objetos de información y las relaciones que guardan entre sí que se muestra en un Diagrama de Clases. lo másseguroes que en realidad sea un atributo de otro objeto. pero uniformes en este aspecto. 3. Fin deAgregar ~ . Himinación de canddatos inadecuados: Algunosdeloscandidatosseleccionadosno deben convertirse en clases. Son clases que estarán registrando transacciones de la organización.. En lo que puede hacer es agregar este caso registros o finalizar el programa. 4 Atributos y funcionakdadcomunes: Todos losatributos y métodospropuestos para la clase deben aplicar para todos y cada uno de los objetos que se espera se generen a partir de ella.siesto pasa. 4 Infamación sensible al tiempo. pues no corresponden a objetos.~ . pero falta identificar los principales objetos de información que determinan la estructuradelsistema. .3 Modelo del dominio del Problema Hasta aquí tenemos identificados los requerimientos funcionales principales.4 El programa tiene un estado inicial (címlo negro) donde de parte ejecución la y un llega a estado o pantalla (rectángulo) la en que el usuario plantea acciones a realizar.5." . ->Pantalla Principal . los nombres de los atributos uniformes de 3-1 1 . 4 Más de un atributo: Cuandoun objeto tiene un solo atributo. " 3 . Cuando se esté haciendo la eliminación. para cada caso del modelo de casos.5. 2. . . es posible que existan objetos con un solo atributo. - Agrega ~ .Sistema Help Desk Agmga a la 0D y continwAgrwdo . 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. no pueden existir objetos sin métodos. obtenemos un diagrama de Clases. ~ . Es¿ableomiento de los atnbuhos de cada clase: Ya establecidas.< .Estemodelotienecomoobjetivoprincipal. el cual contendrá los objetos que necesite para desarrollarse. se llegaal estado finalque es elcírculo negro con marco. I la Fin del Programa 3. es posible asignarle losatributosbásicosacadauna. . Sólo es necesario designar una clave y una descripción. . Estos pasos son: 1 . de aquí podrá a agregar datos base de todo lo capturado o bien regresar a la pantalla principal y puededecidirterminarelprograma. ~ ~ - Marco Teórico Fig. Si va a agregar registros. .--~_>. 4 Funcionakdidad: Los objetosdebentenercomportamientoquesearelevantepara el problema. " .AgregarunRegistro . Es necesario estandarizar algunos aspectos: los nombres de las clases en singular o en plural. se debe tomar en cuentalo siguiente: 4 Regigro: Todos los objetos necesitan almacenar información. 4 Más de una ins¿ancia. La forma de obtenerlo sigue un esquema sistematizado en el cual hay una serie de pasos para llevarlo a cabo. + Se establecen todas las combinaciones válidas de asociaciones ternarias. 1 . .métodosquepermitanlaconsultade los atributosdel objeto (get). Los valores que pueden darse son O. Identificación delos métodos bákicos de las clases: El modelo que se está generando es un modelo estático. sólo minúsculas. todos los elementos con los que se está trabajando interactúan entre sí para proporcionar la funcionalidad establecida en el C a s o . Cuandoeldiagramayacontemplaasociaciones. por lo que los atributos que constituirán la llave relacional.métodosdeescriturasobre los atributos(set).consisteen incluirunanuevaclaseenlugardela asociación.mayúsculasy minúsculas. La forma de determinar la lo mínimoya lo máximo cardinalidad. 5 Identificación de las asociaciones estáticas entre clases: Unavezestablecidaslas 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.. de la mulOplicidad o caroinalidad de las asociaciones binarias 6 . y/o composición. Identificación de estructuras de Generallizacíón-Esaeciallización: La determinación de se da necesariamente en el primer ciclo de análisis. Determinación de los niveles de visibibdad de los atributos y métodos: En general. Las relacionesunoa unonormalmentecorrespondenasituacionesenlasqueseestablecieronatributos como clases de tal manera que están vinculados a una razón de unopor uno. 4. + Se establecen todas las combinaciones válidas de asociaciones cuaternarias. 11. por esto otros objetos fuera de este modelo tendrán una visibilidad limitada de los elementos analizados. Sin embargo. serán las llaves relacionales de las clases con quien se estarávinculando.Sistema Help Desk Marco Teórico acuerdoa un estándar tal como sólo mayúsculas. pues en ellas se establecen La forma de simplificar las vínculos complejos entre conjuntos de objetos.más los atributoscorrespondientesaella. 1o.. la cualestaráasociadaconlasexistentesasociacionesunoamuchos dirigiendoelladomuchoshaciaelextremoendonde se ubicalanuevaclase.mientrasquepor otro lado. Identificación detect3das:Una vez identificadas las asociacionesse está en posición de establecer la cardinalidad de todas las asociaciones binarias. Las subclases sólo especifican los atributosquesonúnicosparacadasubclase. asociacionesmuchosamuchos. Determinación de los atributos que pudiesenser llaves relaciona/es: Es importante comenzar a plantear que las clases serán la base para la definición de relaciones. z Reemplazo de asociaciones que impliquen a más de dos clases y/o asociaciones cuya multiplicidad seaunoauno o muchos. comparten todos los atributos de la clase genérica la de estructura. los atributos de la nueva clase. se aplicará el concepto de muchos ("*"). 2. 8. cuando se desconoce en forma precisa el número de objetos quese relacionan. etc. los métodos básicos son métodos que tendrán todas las clases.consisteenestablecercuantoselementosa podemosrelacionar unobjeto con los objetosdel otro ladodelaasociación. guiones de separaciones entre los elementos del nombre. por asociacionesbinariasdeunoamuchos. se indica con "@". + Se partedelabasequecadaasociaciónbinariapuederecorrerseenlasdos direcciones. para los elementos dentro del modelo será necesario establecer niveles de visibilidad para generar un modelo que coloque un nivel de encapsulamiento 3-12 . . La estas estructuras no identificación de la herenciase da en el momento en que los objetos en los casos se parecenperovaríanensuspropiedades o en sus comportamientos. tales como constructores. el cual probablemente sea implantado en una Base de Datos. los cuales nos describirán las acciones que deben realizar los objetos del mundo real. Identificación de las asociaciones de agregación 9.destructores.Debemosobservar los verbos dentro del Caso.existe la posibilidad que el modelo oculte información en las asociaciones muchos a muchos. No tratan con aspectos de la aplicación. En el punto que los ajustes sean menores y podamos considerar que no afectan la estructura fundamental del modelo del Dominio del Problema. Todos los objetos son iguales.nocontienenmuchalógicarelacionadaconlaaplicación. 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ónyEspecialización.Implantanensusmétodos. Las categorías más simples de objetos son: 1 .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. 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. 3. luegose plantea el mecanismo decolaboraciónentre los objetos. Son especializados en la interacción con los actores. los algoritmosdelaaplicaciónylasreglas de negocio. Su construcción está ligada directamente al modelodeinterfaz. Funcionancomogestorescon otros objetosparalarealizacióndelalógicadeuna transacción.Sistema Help Desk Marco Teórico adecuado. de t a l forma que proporcionan servicios o métodos a otros objetos.Todas lastransaccionesinicianyterminanconlainteracciónentreunactoryunobjeto interfaz. 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. 3. Objetos interfaz. 2. 12. pueden establecer ciertas funciones específicas a los objetos que componen un programa y por lo mismo pueden establecer los aspectosdecalidadinternade los categorías. estamos en la posibilidad de continuar con la siguiente etapa del método que es el Modelo de Análisis.lascualespermitenmejorar componentesde los programasyaqueexhibenmejoresnivelesdecohesióny acoplamiento que son elementos con los que se evalúa la calidad de un sistema. por esto es muy fácil su identificación dado el modelo de casos.Danservicioaotrosobjetoscomo los de interfat. presentan información en formatos cercanos al actor y/o permiten la adquisición de información delactorhaciaelsistemarealizandolasconversionesenformatonecesarias.luego se establecen los mensajesentre los objetos y la secuencia de l o s mismos.5. Objetos de datos: Su función principal es la de aislar los detalles de implantación de los demás objetos de los programas. lasconexionesconlasfuentesdedatospara 3-13 . Objetosdenegocios: Sonespecializadosen los servicios referentes a la lógica de la aplicaciónyreglasdenegocioquetienenqueseguirsepara la realizacióndela funcionalidad del programa. No tratan con aspectos de interfaz con los actores ni con lasfuentesdedatos o deinformación. Los métodosquedebenserpúblicossoncon los que se le van a enviar mensajes a los objetos que se construyan a partir de la clase. a continuación los objetos delacapadenegocio y en últimolugar los objetosdelacapadedatos.puedevisualizarsecomo un caso de prueba. Aunque los objetos se pueden colocar en cualquier posición en el eje.EstemodelopuedeexpandirseenunmodeloMulticapa o MultiTier que incorpora más de tres niveles. con valores reales de los intercambios de información entre el actor y el programa. Escenario de operación con excepciones del caso. El proceso de construcción se alimenta del modelo de análisis y que está constituido por tres procesos más elementales: 1. el siguiente paso de la metodología lo constituyeelprocesodeconstrucciónendonde se detallaelmodeloanálisis dinámico considerando aspectos de implantación además de establecer la estructura de distribución delos objetos que estarán componiendo al sistema. se recomienda colocarlos en el orden que se van utilizando con base en la capa a la que pertenecen.Unadelasherramientasdeldiseñoeseldiagramade secuencia que es una gráfica con dos ejes. 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. Los casos que se consideran más significativos son: + + + Escenario de operación más simple del caso. y las clases de donde se originan. establece los objetos dinámicos. se establecen sus escenarios los cuales describirán instancias de los Casos en modalidades normales. Una vez concluido el proceso del análisis. o sea. es como un conjunto de valores específicos y de accionesespecíficasdelusuariosobreel caso. Proceso de dseño: Es elrefinamientodelmodelodinámicoobtenido por partedel análisis tomando en cuenta aspectos de implantación. se dice que se estáutilizandounmodelodeTresCapas o de Three Tier. Escenario de operación correcta más representativa del caso. Paracadacaso se seleccionan los escenariosmásprobables y quegenerenmejorentendimientodelaoperacióndel caso.Sistema Help Desk Marco Teórico Son objetos de servicio.en primer lugar los objetos de la capa de interfaz. las relaciones que guardan entre sí. Lkfinición de exenaios: Para cada caso del modelo de requerimientos. este modelo permite estructurar los programas para obtener mejores niveles de mantenimiento. El proceso de Análisis consiste en identificar los objetos dinámicos de un programa y las relaciones dinámicas que guardan entre sí. Esta situación permite establecer control de versiones de los objetos y no del programa completo. Un escenario es una instancia de un caso que sigue todos los pasos descritos por el caso. En el eje horizontal se tienen los objetos participantes en el escenario. Escenario de operación incorrecta del caso.En los 3-14 . Los pasosinvolucrados en el Proceso de Análisis son: l. En el eje vertical se tiene la dimensión del tiempo. su tipo. 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. permite aislar el efecto del mantenimiento. Cada escenario es una instancia o ejemplo del caso. Cuando un programa se estructura sólo con estos tres tipos de objetos. toma como una de sus herramientas principales a los diagramas de secuencia que describe un modelo dinámicoquefacilitalaconceptualizacióndeladinámicadelsistemacuandoestá procesandounescenario. etc. la descripción interacciones. 3. Los Painters queeditanobjetospueden seraccedidos de tres maneras desde la Barra Principal: HaciendoClickenNew o Inherit.. quién lo procesará (servidor) apuntando la flecha del mensaje hacia el servidor. le agrega controles tales como botones(buttons). el cual se puede accesar desde la barra principal. diseño y desarrollo de aplicaciones Cliente/Setvidor. En Power Builder a uneditordeobjetos utilizado para construir objetos o una herramientaparamanipular o administrar sus Bases de Datos o librerías se le usted construyeunaventana conocecon el nombre de “painter”. esto desde el Painter de Librerías. se hace una breve descripción de su uso. Haciendo Doble-Click a un objeto o seleccionando Edit desde el menú tipo popup del objeto.si debe hacerlo en el “Window Painter“.6 ProgramaciónenPowerBuilder 7. Cada y por lo mensaje está asociado a un método de la clase a la que pertenece el objeto regular también incluye en su descripción a los parámetros involucrados en la interacción. Proceso de anábsis dinsmio de componentes:Es donde se identifican agrupamientos de objetos quese visualizarán como componentes de programación. Esta Versión esta orientada al análisis. Es recomendable ubicar en cada diagrama de paso a paso del caso correspondiente para ubicar las secuencia. se puede y cadapunto se colocaa la colocarladescripcióndelladoizquierdodeldiagrama altura de la interacción que te corresponde. cajas de texto (TextEbxes). Se deben 3-15 . es aquí donde usted define las propiedades de la ventana. en qué momento de la ejecución del caso se dan.0. 3. para esto. El “library Painter” mencionado anteriormente y el “Database Painter” se pueden accesar desde la barra principal. quién envía el mensaje (cliente). Proceso de pmgramación:Es en sí la programación de los métodos de las clases y la elaboración de los programas.Porejemplo. Dentro del “DataBase Painter”usted puede Crear o Modificar una base de datos.paracrearunobjetonuevo o abrirunoyaexistente. 3.Sistema Desk Teórico Marco extremos se colocan los actores que participen en el escenario.0 Debido a que la plataforma cliente es Powerbuilder 7. 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. 2. 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. Desde el Browser el cual también se accesa desde la barra principal. Los objetos que están activos se denotan con barras verticales sobre las líneas de vida de cada objeto. 2. l. y realizar algunas manipulaciones a la información contenida en ellas. el otro punto importante se encuentra en la pestaña titulada “Preview”. accesar al profile de la Base de Datos en cuestión esto se logra pulsando el botón izquierdo del mouse. al expandir Utilities se observa la opción ODBC-Administrator. es posible.INI. seleccionando antes la B. de todoslos parámetros a ingresar. 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. se debetenercuidadoen la pestaña”Database“. en la estructura de árbol mostrada en el DB-Profile.queesdondepidela 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. donde se puede observar la información que debemos incluir en el archivo . 3-16 . en este profile de lo mas se le agrega el DSN creado importante a observar es que es aquí donde anteriormente. al elegir agregar uno nuevoo configurar uno ya existente.Sistema Help Desk Marco Teórico 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 deArbol. al hacer doble click sobre estase abre la ventana delODBC Data Source Administrator.D. PENDIENTE. y en general le da 2.1 . 3. define nuevas mantenimiento a los catálogos. LevantamientodelReporte Un reporte se puede levantar de dos maneras: 0 0 Directamente por el usuario Por registro del Help Desk El levantamiento debe considerar: IdReporte. Gafete. Administración de los Reportes: 3.1 Atención de un reporte El asesorasignadoa la primera acción de un reporte debe indicar que está y la Acción comenzandoatenderla.enestemomentoelEstadodelReporte EN PROCESO. Compañía.Sistema 4. UserName. con los cuales se pueden dar listas por omisión de clasificaciones de problemas. Detalle del problema. Equipo y software involucrados. Descripción corta.1 ModelodeRequerirnientos a NivelGeneral Los requerimientos generales del sistema Help Desk se describen en las siguientes líneas: 1. El Help Desk genera la primera acción realizar a y ésta es asignada Esta primera Acción tiene un status de automáticamente un aasesor. Impacto y prioridad. NivelesdeUsuario Deben existir distintos niveles de usuarios del sistema: categorías Administrador Asigna permisos. En este inicio indicará la opción de solución debencambiara 4. 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.2 Atención de Una Acción Las acciones son atendidas por los asesores y é&os cuando las comienzan a Las realizar deben indicar el número de minutos que planean emplear. subsubsubcategoría) y texto. El usuariopuedeconfigurarsobrequécambiosdeestadodesearecibirla notificación. 3. CuandoelAsesorhace la atención del Reporte realizando una Acción. 3. 3. subsubcategoría. tipo de falla. En esta opción se recogerán los comentarios del usuario con respecto a la calidad del setvicio queéI percibió. equipo y valor del estado.3 Conclusión de una acción El asesorpuedeindicarelavancequetienelarealizacióndeunaAccióna través de un Porcentaje de Avance. TambiénelHelpDeskpuedecerrarreportesindicandolasconsideraciones realizadas para considerarlo cerrado. Cada problema identificado debe tener una o varias acciones asociadas para susolución.pero este puede reasignarlas a otro asesor. y en ese momento el estado del reporte debe cambiar a CERRADO.Sistema Práctico que piensa realizar y el número de horas que planea utilizar en desarrollar la acción. preestableciendo notificaciones por usuario. acciones tendranun estado de ENPROCESO. Las acciones tendrán en este momento el estado de PENDIENTE. 3. puede detectar problemas más específicos que los queespecificóelusuario. Si el porcentaje de avance es el 100% el asesordebeindicareltiemporeal dedicado a realizar la acción y en qué porcentaje la acción resolvió el problema asociado. Debe notificar al usuario del reporte cada vez que hay un cambio en el estado.Cadaacción se asignaautomáticamentealmismoasesor. los problemas también tendrán estado de PENDIENTE.de tal forma que puede agregar nuevos problemas al reporte y especificarlos de la siguiente forma: Clasificación del problema (categoría. 4-2 .5 NotificacióndeCambiosdeEstadodelReporte. subcategoría. Con el levantamiento de un reporte puede configurarse a quién deben notificársele los cambios de estado. Fecha y Hora. es decir. IdReporte involucrado y tipo de modificación que realizó. Un reporteseráescaladoensuprioridadconbasealtiempopendientede resolución y complejidad. ubicación del equipo. Los reportes y consultas en los que están involucrados directamente pueden ser consultados en todas sus características. El cambio registrado en la bitácora debe contener UserName del usuario que modificó el reporte. La bitácora debe purgarse periódicamente sólo de reportes ya resueltos 7.1 Consultas de los Usuarios. Seguimiento. 8. tipo de acciones que deben realizarse. Mantenimientospreventivos. La asignaciónprimariadeaccionesdebeserautomática.No se pueden eliminar y modificar registro de la bitácora. configuraci6n registrada del 4-3 . Bitácoradecambios. 9.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. Los reportes y consultas en los que están involucrados directamente pueden ser consultados en todas sus características.ninguna Las acciones de un reporte pueden reasignarse a otro asesor de manera manual. La informacióndemantenimientopreventivodebegenerarseporeventode manera periódica. Deben existir mecanismos para darle seguimiento a un reporte para todos actores.6 Reasignación de Acciones. fecha programada. la información debe ser: Equipo. 3. acción estará sin asignación de asesor. EscalamientodeReportes. 4. y la posibilidad de las consultas de 8. los Todo cambioenunreportedebeestarregistradoenunabitácora.2 Consultas de Asesores. 6. 8. Consultas de estadística de reportes asesores y consultas de usuario. Consultas: 8.3 Consultas Gerenciales. 5. por el asesor que está asignado a la accióno bien por el Help Desk. AccesoalasBitácoras. Es un sistema experto disponible a todos los asesores para acceder a la bitácora sólo para efectos de consulta. El DiagramaGeneralde Casos delafigura 4. se planteapormediodeunDiagramade Casos. La información base debe obtenerse de la información de inventario de equipos de computo. 4-4 . Cada reporte por mantenimiento preventivo.estado = ASIGNADO.Sistema Desk Práctico Desarrollo equipo.2.2. muestralainteracciónentre Actores y Casos hallados enel sistema Help Desk. debe procesarse como los descritos por mantenimiento correctivo.2 Modelo de Use Case a Nivel General El Modelode Casos. DUGRAUAGENERALECASOSDEUSO los Figura 4.asesor asignado. Los casos se describen por medio de un óvalo con el nombre de cada casoy los actores por medio de una figura de alambre de una persona.campañadelmantenimientopreventivo. 4.1. ennotación UML.1 El Diagrama de Casos de Nivel General muestra la interacción entreActores y Casos. Sistema Help Desk 4.1 Diagrama de clases a Nivel General del sistema HelpDesk. el identificar los objetos de información y las relaciones que guardan entre sí. Problema Id-Prcblema : lag Id-Falla: o ln g Desc-Prabkma :s t r i n g Figura 4. el Diagrama de Clases se muestra en la figura 4. 1 Falla 1 : .3. Corflmza a g Id-CmfiCnra : l Id-Ernp : lag uscerio "Uslerio: long UscrName-Usuario : sting Id-ccfltilma :o ln g 1 t r i n g Respesta:s 1 :. 1. 4-5 .3 Desarrollo Práctico Modelo del Dominio del Problema a Nivel General Este modelo tiene como objetivo principal.1. En el caso del Help Desk. Dese-Tipocambio 1 : .3. 1 : . 4. El Usuariocapturaelidentificadordeusuarioalcual se ledebenhacerlas notificaciones y configurael tipo denotificación y estadossobre los cuales desea recibir notificaciones. 3. 7. El sistema asigna automáticamente la primera acción a realizar.4. 6. 4-6 . 5. El usuario final captura la descripción del impacto del problema y seleccionala prioridad correspondiente. El sistema verifica el Identificador y despliega los datos del usuario y los conjuntos que tiene asignados. El usuario final captura una descripción detallada de la situación. El sistemaregistra los datosdelreporte. 10. 4. El usuario final selecciona la clave del conjunto que presenta la falla.4. el asesor que atenderá dicha accióny el estado inicial de la acción. 1 .1. y una lista de pasos / . El usuario final selecciona el tipo de reporte que se está llevando a cabo. El reporte es asignado inicialmente a un asesor que atienda y solucione los problemas que sean reportados posteriormente. 1 1 .Sistema 4.asignaunestadoalreporte y un identificador. " Help Desk Levantamientode Reporte f - -~ ~ - ~ ~~ ~~ /A Usuario Final \ q F '' Figura 4.1 Diagrama de Caso de Uso Levantamiento de Reporte PASOS: 2. 8.1Modelode Caso de Uso Este modelo está conformado por un diagrama del caso a seguir como su descripción.?f4\ "~ .1 Modelo de Requerimientos Caso de Uso Levantamiento de Reporte Este caso de uso describe las actividades que se llevan a cabo para registrar e identificar un reporte dentro del sistema. 9. 4.4 4. El sistema verifica clave la del conjunto y despliega descripción la correspondiente. además le asigna el reporte a un asesor. El usuario final captura una descripción breve del problema. Adelante se muestra el Modelo de Casos y el de Intetfaz correspondiente a esteCaso de Uso. El usuario final captura su ID de Usuario.. 2 0 Desarrollo Práctico Modelo de Interfaz Diagrama de Transici6n de Estados La siguientefiguramuestraeldiagramadetransicióndeestadosdel case Levantamiento de Reporte.es aquí donde se utiliza la opción "Agregar Reporte". Layouts E& primera pantalla muestra una I RUQI Figura 4.2 Diagrama de Transición de Estados de Levantamiento de Reporte lista deReportes ya dadosdealta.1.3 Pantalla desde la cual se puede agregar un Reporte al Sistema.4.4. use Figura 4. 4-7 .4.Sistema 4. 4 muestra la pantalla de captura de datos para realizar el levantamiento de un Reporte en el Sistema.Sistema Help Desk Desarrollo Práctico La figura 4. 4-8 .4.4 Pantalla para captura de datos del levantamiento de Reporte.4. Se muestra un ejemplo del uso de dicha ventana. Figura 4. ~ " ~ ~ " " Tipo.~.. .Username_Notif: string A.'? Id-Asesor : long ~ ~ .3 Modelodel Dominio delProblema EI diagrama de clases estáticas del Levantamiento de Reportese muestra en la siguiente figura.. Reporte ~ ~~ ~~~ i Id-Rep : long Id-Campana : long IdJipoRep : long lld-Conjunto : long '\ ' .4." .~~ Id StatusRep : Ions Nom-status : string I i 1 Figura 4.. .~ Id-Asesor : long #Id-Confianza : long : Espec-Asesor : string i Calif-Asesor : long 1 L//' 'l.Nom-TipoReporte : string...1 Y\. ~ c.* Asesor ~~ ~. .l I i' j De=-Cierre : string ]Calidad-Servicio : string í Des-larga : string Fechareg-Rep : string ~ j Stat-Notif : string '\ 1. .* ! : Id-Statusfiep : long i bsc-lmpacto : string .... 1 /'l. . 1.5 Modelo del Dominio del Problema del Caso de Uso Levantamiento de Reporte 4-9 .. ' . . \ .. . . . .4. . .1. .Id-TipoRep : long . ...Id-Prioridad : long 1-*.l 1. .Sistema Help Desk Desarrollo Práctico 4.. Ii Id-Usuario : long &=-corta : string 1. " ! . - ~~~~~~ ~~~ ~~~~ ~ .*\ A ' i Tipo1-11 . 4. v l o n g .Sistema Help Desk 4. 4-10 . String. String. String. String.4. String.2 Modelo de Análisis (Escenarios) Desarrollo Práctico 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. Long. Long) cd leVreP : Uf d bvrawrtq 9: ExeCsQLO 4 11 L > A 3' : BD Yoli Figura 4. long. Long.6 Diagrama de Colaboración del Caso de Uso Levantamiento de Reporte.l o n g . : Usuario Final v on asesodev : uf 4: ofget-max( ) 1 c d asesores : u 6: ofget-asesofllong) asesor asesores 1 3: of-selecciona-asesor( ) On k V E P : Uf b levreDorte > 5: ExeCsQLO 7: ExecSQLO 8: of-set-reporte(long. String. Long. y despliega los datos del usuario y los conjuntos que tlene asignados 3. String. Long.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ñoy se puede observar con detalle en la siguiente figura. long. asigna un estado al reporte y un identificador. String) > of-selecciona-asesor( > ) . of_guarda-reporte(long.captutasu Klde Usuario. long. String. El usuario final selecciona el tipo de reporte que s e este kvando a cabo 6. + Aceptar 1 1 I . El usuario final captura una descripci6n detallada de la situaci6n. a d e d s I e asigna el reporte a un asesor Figura 4. long. prior-r) I . O sistema veiflca el lentificador (id-usr. String. Long) > I 9. 1 1 . String. El usuario final selecciona la clav e del conjunto que presenta la falla 4. String. String. w levantar: w : Usuario Final sheet base 2 on IevreD : uf b on asesorlev: u od l e w w : uf d od asesores : u 1emt)orte f b asesor lewworta f d asesores : BD yoli impacto. long. desc-I.El usuario fina. desc-b. of_get-max( ) ~ I II > i ExecSQLO > ofdet-asesor(long) 7.Sistema 4. long. O sistema asigna aulomaticamente la primera accion a realizar. String.4. O sistema registra los detos de I reporte. tipo-r. 8. usr-notif. long.4. El sistema verifica l a clave del conjunto y despliega la descripci6n correspondientes 5. O usuario final captura la descripcion del impacto del a prioridad problema y selecciona ! correspondiente. el asesor que atender6 dicha accion y el estado inicial de I a accion.7 Diagrama de Secuencia del Caso de Uso Levantamiento de Reporte. > ExecSQLO > oLset-reporte(long.. 4-1 1 . 2. E Usuario captura el identificado r de usuario al cual se le deben hacer las notiicaciones y configura el tipo de notiicacion y estados sobre los cuales desea recibir notificaciones 10. id-coni. long. 8 usuario final captura una descripcion breve del probkma. String. 4.8 Diagrama de Clases dinámicas de Levantamientode Reporte. 4-12 . Figura 4.Sistema Help Desk Diagrama de Clases Dinámicas Desarrollo Práctico 0 En la figura siguiente se muestra el diagrama de clases dinámicas del Levantamiento de Reporte. Sistema 4..El sistema Help Desk muestra los reportes que tiene asignados el Asesor.Fallas Problemas.. y y 4-13 .. Help Desk Figura 4.5.. 4.. 8.5.1.El Asesor ingresa su Identificador. Atención de Reportes Administración de C a t ~ l o g o s .seleccionalasAcciones para resolverlosy asigna dichas acciones a unoo más Asesores.-El Asesor selecciona la opción de "Definición de Problemas". 3.5.El Asesor selecciona un Problema con la siguiente ruta: Sistema ->Subsistema -> Falla -> Problema. 7.Subsistemas.. 4./y .1 Modelode Caso de Uso Este modelo está conformado por un diagrama del caso seguir comosu descripción.El Asesor escribe la lista de Acciones necesarias para resolver el problema les asigna a c/u un Asesor. 6. N . 2. elAsesor identifica los problemas.El sistema Help Desk muestra catálogos deSistemas.' I .1 Modelo de Requerimientos Eneste USE CASE. 5.1 Diagrama de Caso de Uso de Atención de un Reporte PASOS 1.. y una lista de pasos a .5 Atención de un Reporte 4.El sistema Help Desk actualiza el Reporte..El Asesor selecciona el Reporte por atender. Salir >e A Salir Aceptar( id-asesor X asesor no registrado ] v Aceptar Mensaje de Aceptar( id-asesor ) I Asesor válido error h v > Atenci6n de Reportes ) Definir pmblernaq id-reporte Salir Guardar I Datos incorrectos Guardar I 7 V Asignación Pmblerna-Acdón-Asesor Figura 4.5.2 0 Práctico Modelo de Interfaz 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.1. 4-14 .Sistema 4.2 Diagrama de Transición de Estados de Atención de un Reporte.5. Administraaón de Reporte > > Solicitud de Id del Asesor. es decir.5. 4-15 . pantalla se solicitael ID de Asesor para mostrarlosreportesquetiene En esta pantalla se selecciona un Reporte y se utiliza la opción: "Definir Problemas".5.3 En esta asignados. deberá Figura 4. Figura 4.4 En esta pantalla se muestra todos los reportes asignados al Asesor. se enlistan las razonespor las que se creó el problema.DesarrolloSistema Help Desk Layouts Para que un asesor pueda observar ingresar su identificador. los reportes que tiene asignados. 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. 5 .Sistema Help Desk Práctico Desarrollo En la pantalla de la figura 4. A o o w 1pERNANDU GOMEZ JORGE 3kH4vU FLORES LAMBERT0 Figura 4 . 4-16 .5. 5 Pantalla de definición de problemas y asignación de Acciones.5. Sistema 4.5.1.3 ModelodelDominio 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 Id-Confianza : long & j Espec-Asesor : string1..I i Calif-Asesor : long 1 I Reporte Id-Rep : long i Id-Campana : long ; Id-TipoRep : long Id-Conjunto : long 1 Id-Usuario : long '/ I /Desc-corta : string 1..* 1..* Id-StatusRep : long ----iDesc-lmpacto : string I Id-Prioridad : long ~1 j Usemame-Notif : string ~-<.Ci Id-Asesor : long j 'Stat-Notif : string 'Desc-Cierre : string :Calidad-Servicio : string ! Desc-larga : string j : Fechareg-Rep :string " ~ 1 Nom-status : string1 i / . . ~ ~ ~ 1 -~ ~ I Action . ". . I" 1 Id-Pcdon : long I 1-1 Id-Reporte : long I Id-kesor : long j Desc-Mon :string long; / ~ i e m p o ~ l a n - ~ ~:c ion 1 Stat-kcion :long 1 TiempoReal-Won : longi /Avance-kcion : long I !Complej-Accion : string I Id-Problema : long I I Stat-Problema : long j 1 Avance-Problema :long ~~~ ~~ ~ , "1 1 i I ! '1 Tipo-~ Id-TipoFalla : long ...~ . . ~.. 1 l..* -- i IdSistema : long i Desc-TipoFalla : string) Falla , 1..l +Id-Falla : long ; Id-TipoFalla : long ;Desc-Falla :string : " " ~ ; \ \ i / l ..I I Probl iI -~ . .~ ' Id-Problema : long I 1..* j I Id-Falla : long I 1 Desc-Problema : string/ i 1 Figura 4.5.6 Modelo del Dominio del Problema delCaso de Uso Atención de un Reporte 4-17 Sistema 4.5.2 Modelo de Análisis (Escenarios) En el esquema siguiente se puede observar la interacción entre usuarios y objetos ellos existaparadar delsistema a fin dedeterminarlacolaboraciónqueentre 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 Sistema 4.5.3 Modelo de Diseño (Escenarios) A partir deldiagramadecolaboracióndeAtencióndeReporteseobtiene su diagrama de secuencia en esta etapa de diseño y se puede observar con detalle en la siguiente figura. od msncon ut d I of-ggst.,aresor(bng) 7 > >' Figura 4.5.8 Diagrama de Secuencia delCaso de Uso Atención de un Reporte. 4-19 Sistema Desk Modelo de Clases Dinámicas Práctico Desarrollo 0 En la figura siguiente se muestra el diagrama de clases dinámicas de Atención de un Reporte. 4-20 .9 Diagrama de Clases Dinámicas de Atención de Reportes.5. la -I Figura 4. . 7.El sistema Help Desk muestra los reportes que tiene asignados el Asesor.El Asesor selecciona una Acción y presiona el botón "Modificar Acción" 8.El Asesor especifica el tiempo que planea ocupar para resolver dicha acción y el porcentaje de avance que tiene la misma. 2.El sistema Help Desk muestra una pantalla con algunos datos de la Acción.6 Atención de una Acción 4. 3.6.1 Modelo de Requerimientos EnesteUSE CASE.El sistema Help Desk muestra una lista de Acciones asociadas al Problema.DesarrolloSistema Help Desk Práctico 4. / + Help Desk _ .1.~..El Asesor selecciona un Problema. / ' 1 Figura 4.1 Diagrama de Caso de Uso de Atención de una Acción PASOS 1.6. y una lista de pasos ..-El sistema Help Desk actualiza el Reporte. 6.7 Atencion de una Acción ( 1 .... 4.El sistema Help Desk muestra la lista de Problemas asociados al Reporte.El Asesor ingresa su Identificador.El Asesor selecciona un Reporte. 4.1 Modelo deCasode Uso Este modelo está conformado por un diagrama del caso a seguir como su descripción. 10. 4-2 1 . 9. .. 5.. al especificar el Asesor el tiempo que piensa tardarse en resolverla.6. elsistemaHelpDeskcambiaelstatusdeunaAccióna"En proceso".. 2 Diagrama de Transición de Estados de Atención de una Acción.DesarrolloSistema Help Desk 4.6.1.2 Modelo de Interfaz Diagrama de Transici6n de Estados La siguiente figura muestraeldiagramadetransicióndeestadosdeluse 0 case Atención de una Acción. de Reportes( Id-asesor ) Atención de Acciones( Id-asesor. 4-22 .6. Admón. d-reporte ) > Atención de Reportes Salir > Atención de Acciones < Cancelar Modificar( id-acción ) Aceptar I Datos correctos Aceptar datos >Actualizar Error de Mensaje V < Aceptar I Datos incorrectos Figura 4. Sistema Práctico .3 Pantalla principal para el control de Acciones.6. La figura 4. Dicha pantalla muestra una lista de Problemas asociadas a un Reporte y una lista de Acciones asociadas al Problema seleccionado. Layouts Figura 4. 4-23 .6.3 muestra la pantalla principal para el control de Acciones. 4.4 Pantalla para cambio en los valores de control de una Acción.Sistema Desk Desarrollo Práctico En la pantalla de la figura 4. Figura 4.6. el Asesor puede cambiar los valores de tiempo y avance de una Acción.6. 4-24 . . .. Id-Rep : long Id-Campana : long I Id-TipoRep : long Id-Conjunto : long . . / ~ -~ ~~~~~~~~~ ~~ ~ 1. ~ - - ~ . Desc-Cierre : string i Calidad-Servicio : strin! j Desc-larga : string Fechareg-Rep : string . ' I Id-StatusRep : long j Nom-status : string 31 . .* V I . -~ " " ~"""2 I h eso . " Accion Id-Accion : long -I-*! Id-Reporte : 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 ~ . Id-Usuario : long Desc-corta : string 1. -~ .. . .6. . -.Sistema Desk 4.3 Desarrollo Práctico ModelodelDominiodelProblema El diagrama de clases estáticas para la Atención de una Acción se muestra en la siguiente figura..~..1 ..6.~ Id-Falla : long Desc-Problema : string! . . Desc-Impacto : string Id-Prioridad : long Ij Usemame-Notif : string Id-Asesor : long : Stat-Notif : string .~ ~~ ~ ~ Tipo ".I - .* Id-StatusRep : long . Report ... Figura 4. . . " .5 Modelo del Dominio del Problema delCaso de Uso Atención de una Acción 4-25 . . Id-hesor : long j Id-Confianza : long Espec-hesor : string1. . .... . .1.~ . .I Calif-hesor : long j ~ ~ ~ .I Proble : Id-Problema : long I ~ i I . Sistema 4. long. 4-26 .6. avance-acción + Aceptar 21: of-update-problema(id-reporte. long. 2: of-valida_asesor(Long) 3: of_get-asesor(long) w administrar: w sheetbase 1: Id-asesor + Aceptar > on asesor: uf b asesor > od asesores: u f d asesores 7 5: opensheetwithparm(¡d-asesor) 4: ExecSQLO v > 4 Integer) 6: of-lIenadw(uf-i-dwestandar. long. . Long. integer)7: of-getdata(uf-i-dwestandar. I Integer) 12: opensheetwithparm(str_modificación ) I I long. long. IdLacciÓn + Modificar 8: ExecSQLO -A : Asem 10:opensheetwithparm(str-reporte) V w atencion acciones : w sheetbase 22: ExecSQLO A 20: ExecSQLO 2 15: ExecSQLO > /A : BD Yoli "7 I- ~~ od atencion a : uf 4 atencion accion 14: of-getdata(uf-i-dwestandar. . id-problema) > w atencion acciones2 : wbase sheet > 17: of-valida-informacion(editmask editmaslc. editmask editma* 18: of-actualiza-accionflong. 7 w base sheet Btencion reoorte f d atencion reoorte .6. 9: Id-repolte + Atender Accione% adman reporte : on reDorte : uf b >od atencion reDorte : u ~ '. long." .2 Modelo de Análisis (Escenarios) Práctico 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. long) V 16: Tpo-planeado. long. integer) atenciona on : uf b atencion accion status-problema. long) > > Figura 4.7 Diagrama de Colaboración del Caso de Uso Atención de una Acción. 13: of-llenadw(uf-i-dwestandar./'11: Id_pmblema.. 19: of-update-accion(long. w w atancion w atendon accion~4: aw cuonss2 .Sistema Help Desk 4. tnteger) I I 1 ol~gatdats(uf_~_dwestandar.SWl atb nc. ~ ExecSOLO I 7 I I I Figura 4.3 Modelo de Diseño (Escenarios) Desarrollo Practico 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.8 Diagrama de Secuencia del Caso de Uso Atención de una Acción 4-27 . Integer) I I 7 ExecSaLIl . . f ud u1 d atencion 8~ YOlI I ExecSaLO opsnrhbatwithparmlid-a~~r) 1 > I of_llanadw(ul_l_dwestandar. y a d m i n i s t a r . w admon w n e e t b a q ntoorte. uf on WDOR(I : uf on a t s w o n s : od 8mm r es : t enclon uf atendon b f d aatsores reoorte 4LA.6.6.on Id-aatmr + Aceptar .w on a m s o r . 9 Diagrama de Clases Dinámicas para Atención de una Acción.6. 7 7-7 Figura 4. 4-28 .Sistema Help Desk Desarrollo Práctico O Modelo de Clases Dinámicas En la figura siguiente se muestraeldiagramadeclasesdinámicasdela Atención de una Acción. ...El sistema Help Desk actualiza el Porcentaje de Avance del Problema asociado.El sistema Help Desk muestra la lista de Problemas asociados al Reporte.El Asesor selecciona un Problema. 7. 9.-El sistema Help Desk actualiza el status del Reporte.7 Conclusión de una Acción 4.. 4-29 . 6. 8.7.1 Diagrama de Caso de Uso de Conclusión de una Acción PASOS en que ésta resolvió el Problema asociado. 1. 4... El sistema Help Desk actualiza el status del Problemay a su vez el del Reporte.El sistema Help Desk muestralos reportes que tiene asignados el Asesor... el Asesor actualiza el porcentaje de avance de una Acción en 1 0 0 % eindicaeltiemporealdedicadoa ésta.7. 10.1. Asesor Help Desk Figura 4.El Asesor selecciona la Acción y actualiza el Porcentaje de Avance al 100%".El sistema Help Desk muestra una lista de Acciones asociadas al Problema.El Asesor selecciona un Reporte. 4.El Asesor indica el tiempo real dedicado a realizar la Acción y el porcentaje 2..7.Sistema 4. 3.1ModelodeCasode Uso Este modelo está conformado por un diagrama del caso y una lista de pasos a seguir como su descripción. 5. también indica el porcentaje en que esta Acción resuelve el Problema asociado.El Asesor ingresa su Identificador.1 Modelo de Requerimientos EnesteUSECASE. 1 Atención de Acciones --. ~.2 Diagrama de Transición de Estados de Conclusión de una Acción.1. . "> Atención de Reportes r . de Reportes(id-asesor) Atención de Acciones( Id-asesor. ~ .7. deestadosdel use Admón.2 Modelo de Interfaz Diagramas de Transición de Estados La siguientefiguramuestraeldiagramadetransición case Conclusión de una Acción. . ~.~~~ ~~~~ ~~ .- i k Figura 4. id-reporte ~ ~~~ ) 0" ~ ~ .Sistema 4..7. 4-30 . Figura 4. 4-3 1 . sólo que en este caso es posible escribir el Tiempo Real dedicado y el porcentaje en que éSta resolvió el Problema a atender la Acción asociado.7.3 Pantalla para la conclusión de una Acción.Sistema Help Desk Layouts Desarrollo Práctico E3ásicamente son las mismas pantallas que para el Caso de Uso Atención de un Acción. * \1/1 .7.3 Modelodel Dominio del Problema El diagrama de clases estáticas para la Conclusión de una Acción se muestra en la siguiente figura.* : long Id-StatusRep 1 . ~ - - Acuon.Desarrollo Sistema Help Desk 4.~~ ~ 1.. .I Id-Confianza : long Espec-Asesor :string Calif-Asesor : long -~ " " ~ ~ .1.7.. ~~ Aseso Id-Asesor : long 1. -.. . ~~ " " ~~~ Figura 4.* 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 . . .I . ! Id-Problema : long Id-Falla : long Desc-Problema : string. . Proble " .~ -~ 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 . . ~- .4 Modelo del Dominio del Problema delCaso de Uso Conclusión de una Acción 4-32 . . Report diRep long id-Campana : long id-TipoRep : long Id-Conjunto : long Id-Usuario : long Desc-corta : string 1.. " " ~" ~~~~ ~~~~~ ~-~~ ~ ~~. .." " ~~ ~~ .... . A Integer) 12: opensheetwithparm(str-rnodificación ) A long. 2:of-valida-asesor(long) of_get-asesor(long) 3: w adminittrar : w sheetbase 1: Id-asesor + Aceptar > on asesor: uf b asesor > od asesores: u f dasesores 7 5: opensheetwithparm(id-asesor) 4: ExecSQLO V d Integer) 9: Id-reporte + Atender Accione+ 6: of-llenadw(uf-i-dwe&andar.7. long) Figura 4. editmaw 18: of-actualiza-accionflong. 21: of-update-problema(id-reporte. long.7. integer)7: of-getdata(uf-i-dwettandar.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. long. Tpo-real. Long. 19: of-update-accion(long. status-problema. long. avance-acción.5 Diagrama de Colaboración parael Caso de U s o Conclusión de una Acción. > 7. 4-33 . long.Sistema Help Desk Desarrollo Práctico 4. Idlacción + Modificar : Asesor 10: opensheetwithpam(str-reporte) A 22:ExecSQLO 20: ExecSQLO 2 I ' : ~ r' V w atencion acciones : w sheetbase 15: ExecSQLO > P\ : BD Yoli od atendon a : uf 4 atencion accion 14: of_getdata(uf-i-dwettandar. ~ w sheet b a w atencion reDorte f d atencion reporte 8 : ExecSQLO 1 I /ll\: Id_problema. Avane-problema +Aceptar 13: of-llenadw(uf-i-dwe&andar. long) v 16: Tpo-planeado. idgroblema) > w atencion acdoneQ base : w sheet > > > integetj on atenciona : uf b atencion aocion 17: of-valida-informacion(editma~ editma* editmask. long. long. admon reDorte : on reporte : uf b >pd atendon reporte : u . 7.6 Diagrama de Secuencia para el Caso de U s o Conclusión de una Acción. 4-34 .Sistema Help Desk Desarrollo Práctico 4. Figura 4.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ñoy se puede observar con detalle en la siguiente figura.7. 7 Modelo de Clases Dinámicas para Conclusión de una Acción.Sistema a Práctico Modelo de Clases Dinámicas Enlafigurasiguiente se muestra el diagramadeclasesdinámicasdela Conclusión de una Acción.7. Figura 4. 4-35 . 1Modelode Este modelo está conformado por un diagrama del a seguir como su descripción.El Asesor selecciona un Asesor para reasignar la Acción.. 1..El sistema Help Desk muestra una pantalla con una lista de Asesores disponibles.8... / 7 . 8.8 Reasignación de Acciones 4. 3.El sistema Help Desk muestra una lista de Acciones asociadas al Problema. 10. 4. 7. / H .El Asesor selecciona la Acción y entra a la opción "Reasignar Acción".1.El Asesor selecciona un Problema. 5..8.El Asesor selecciona un Reporte.-El sistema Help Desk actualizalos datos de la Acción. el Asesor asignado a una Acción en particular puede reasignarla a otro Asesor. 6. 4. 9.El Asesor ingresa su Identificador.1 Modelo de requerimientos En este USE CASE.. 4-36 . Caso de Uso caso y una lista de pasos .1 Diagrama de Caso de Uso de Conclusión de una Acción PASOS 2. Reasignacion de Accion Help Desk Figura 4...El sistema Help Desk muestra la lista de Problemas asociados al Reporte.El sistema Help Desk muestralos reportes que tiene asignados el Asesor.8..esk Sistema Help Práctico 4. Reasignarf id-acción ) i Figura 4. 4-37 . id-reporte ) . ~~ ~ e- > Atención de Reportes ~ -3Atenaón de Acciones ¡ if ~.i i .2 Diagrama de Transición de Estados de Reasignación de una Acción. de Reportes(id-asesor) Atención de Acciones( Id-asesor.8. Admón.1.2 Modelo de Interfaz 0 Diagramas de Transición de Estados Desarrollo Práctico La siguientefiguramuestraeldiagramadetransicióndeestadosdeluse case Reasignación de una Acción.Sistema Help Desk 4.8. . 4-38 . Figura 4.3 Pantalla para Reasignación de Acciones. En esta pantalla es posible seleccionar un Asesor de la lista o bien escribir sunombre.3 se muestra la pantalla correspondiente alCaso Reasignación de Acciones.8.8.Sistema Layouts En figura 4. si esque se conoce.paraasignarlelaAcciónmostradaen el apartado "Datos Actuales". 8..~ -~ ~~~ ~ . ~~~ ~ ~~ ~ ~ Ild-Prioridad : long iUsemame-Notif : string 1 j Id-Asesor : long ! Stat-Notif : string ibsc-cierre : string : iCalidad-Senicio : string.1.3 Modelo del Dominio del Problema El diagrama de clases estáticaspara la Reasignación de una Acciónse muestra en la siguiente figura.' Id-Reporte : long Id-Asesor : long Desc-Accion : string TempoPlan-Accion : 1 0 4 Stat-Accion : long TempoReal-Accion : long Avance-Accion : long Complej-Accion : string IdProblema : long Stat-Problema : long Auance-Problema : long ~~ ~~~ ~~~~~ ~~~~ ~ ~~ .~ . .. ~ . 4 I..~ .Sistema 4.* j Id-StatusRep : long -~ i Dese-Impacto : string - j Nom-status i ~~ ~~ : string¡ 1 ~~ ~~ I ~ ~. Id-Accion : long l.* 1..4 Modelo del Dominio del Problema delCaso de Uso ReasignacMn de Acciones. .8. r Desc-larga : string Fechareg-Rep : string ~ : - - Accion -~ ~~. 1 !dStatusRep : long/ Id-TpoRep : long jld-Conjunto : long ' j Id-Usuario : long : y ' j Desc-corta : string 1.l Proble Id-Problema : long : Id-Falla : long Desc-Problema : string Figura 4. * @.. 4-3 9 .~ . 5 Diagrama de Colaboración para el Caso de U s o Reasignación de Acciones. 4-40 . y objetos Figura 4.8.8.2 Modelo de Análisis (Escenarios) Práctico En el esquema siguiente se puede observar la interacción entre usuarios del sistema a fin de determinar la colaboración que entre ellos exista para reasignar acciones entre Asesores.DesarrolloSistema Help Desk 4. Sistema Desarrollo Práctico 4.8. > i > i I i Figura 4. 4-4 1 .8.3 Modelo de Diseño (Escenarios) A partir del diagrama de colaboración de la Reasignación de una Acción se obtiene y se puedeobservarcon sudiagramadesecuenciaenestaetapadediseño detalle en la siguiente figura.6 Diagrama de Secuencia para el Caso de Uso Reasignación de Acciones. Figura 4.Sistema Modelo de Clases Dinámicas 0 En la figura siguiente se muestra el diagrama de clases dinámicas de la Reasignación de Acciones. 4-42 .8.7 Modelo de Clases Dinámicas para Reasignación de Acciones. El sistema Help Desk cambia el status del Reporte a "CERRADO".El Usuario Final llena el cuestionario de "Evaluación de Calidad de Servicios". A s í mismo..9 Cierre de Reporte 4.El UsuarioFinaldaelvistobuenoparaqueelReporteasociadoa 1.1ModelodeCasode Uso Usuario Final \i Cierre de Reporte \ Hdp Desk Figura 4. el usuario ligado al Reporte da su visto bueno para que este seaCerrado. éI sea CERRADO.1 Modelo de Requerimientos EnesteUSECASE..1 Diagrama de Caso de Uso de Cierre de Reporte PASOS: 2 .9. 3. 4-43 .1.elusuariodarásuscomentariosacercadelacalidad del servicio que recibió. . 4.9.DesarrolloSistema Help Desk 4.9. esk Sistema Help Práctico 4. Layouts La figura 4. Figura 4. 4-44 .1.2 Diagrama de Transición de Estados para Cierre de Reporte puedeseleccionarsealgunoquetengaunstatus"Concluido"parapoder pasarlo a "Cerrado".9.3 Pantalla de control de Reportes.9.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.esahídonde I Figura 4.9.3 muestralapantalladecontroldeReportes.9. 4-45 . en la cual el y lacalidaddelservicioque usuariodaunabrevedescripcióndelcierre recibió. Figura 4.Sistema La figura siguiente muestra la pantalla de Cierre de Reportes.4 Pantalla de Cierre de Reportes.9. ..:ldStatusRep : long ..3 Modelo del Dominio del Problema clases estáticas del Cierre de Reporte siguiente figura. El diagrama de se muestra en la Reporte Id-Rep : long Id-Campana : long Id-TipoRep : long Id-Conjunto : long Id-Usuario : long Desc-corta : string 1.5 Modelo del Dominio del Problema del Caso de Uso Cierre de Reporte. 4-46 .' Pregunta Id-Pregunta : long Pregunta : string Figura 4..9.' : string "Asesor : long Stat-Notif : string Desc-Cierre : string Calidad-Servicio : string Desc-larga : string Fechareg-Rep : string 1.* no sua U 1 TipoStatus : long l.Id-StatusRep : string : long I.Sistema Help Desk Desarrollo Práctico 4.9.lYom-status : string Id-Usuario Desc-Impacto : long UserName-Usuario Id-Prioridad : string Usemame-Notif : long Id-Confianza Respuesta Id-Rep : long Id-Pregunta : long Respuesta : string l.1. String) v Figura 4.2 Modelo de Análisis (Escenarios) Desarrollo Práctico En el esquema siguiente se puede observar la interacción entre usuarios y objetos y del sistema a fin de determinar la colaboración que entre ellos exista para cerrar dar por terminado un reporte. string.9.9. 4-47 .Sistema Help Desk 4. 2:of-cierra-reporte(long.6 Diagrama de Colaboración para el Caso de U s o Cierre de Reporte. string.3 Modelo de Diseño (Escenarios) A partir del diagrama de colaboración del Cierre de Reporte se obtiene su y se puede observar con detalle diagrama de secuencia en esta etapa de diseño en la siguiente figura. String) I ExecSQLO > Figura 4. desc-cierre.Sistema 4. 3. : Usuario Final w cerrar: w child - on cierrerep : uf b atencion + Cerrar od atencion reDorte : uf d : BD Yoli id-reporte.El Usuario Final dB el visto bueno para que el Reporte asociado a BI sea CERRADO. 2..9. > String. > oLcierra-reporte(lmg.7 Diagrama de Secuencia para el Caso de Uso Cierre de Reporte... 4-48 .E l Usuario Final llena el custionario d e "Evaluaci6n de Calidad de Servicios". calidad-servicio 1.9.El sistema Help Desk cambia el status del Reporte a "CERRADO". String) >' of-update_ciem-reporte(lcmg. 8 Modelo de Clases Dinámicas para Cierre de Reporte. Figura 4.Sistema Modelo de Clases Dinámicas En la figura siguiente se muestra el diagrama de clases dinámicas del Cierre de Reporte.9. 4-49 . 4-50 . subsistemas. 4.1. Este Caso de Uso se compone de los subcams: Catálogo de Sistemas.10 Administración de Catálogos 4.10.10.1 Diagrama de Caso de Uso de Administración de Catálogos.1 Modelo de Caso de Uso Administrador Administración de Catálogos Figura 4.CatálogodeFallas y Catálogo deProblemas. tipo de reporte y todos aquellos que el sistema requiera para su funcionamiento.Sistema 4. campaña. preguntas. fallas. Los Diagramasde Caso de Uso correspondientesadichossubcasospuedenconsultarseenel Anexo 1 . Catálogo de Subsistemas.1 Modelo de Requerimientos Práctico Es el caso de uso empleado por el administrador para dar mantenimiento a los catálogos de sistemas.10. 10.2 Modelo de Interfaz Práctico Desarrollo Se muestranunapantallacomoejemployaque es muysimilarentodos subcasos (Sistemas. Subsistemas.Sistema Help Desk 4. los Figura 4.10.2 Pantalla general de mantenimiento deCatálogo.1. Fallas y Problemas). 4-5 1 . 3 Modelo de Diseño (Escenarios) LOS diferentesescenariosdeesteCasode Anexo 3 Uso puedenserconsultadosenel 4-52 .10.Sistema 4.10.1. se Figura 4.3 Modelo del Dominio del Problema El diagrama correspondiente a este Modelo (Administración de Catálogos) Práctico muestra en la siguiente figura.10.10.2 Modelo de Análisis (Escenarios) Los diferentesescenariosdeesteCasode Anexo 2 Uso puedenserconsultadosenel 4.3 Modelo del Dominio del Problema del Caso de Uso Administración de Catálogos 4. GeneraLPbl Figura 4.9 Modelo de Construcción 4-53 .elcual puede verse en la siguiente figura.9. 1 1 .Sistema Help Desk 4.11 Desarrollo Práctico Modelode Construcción Estemodeloesrepresentadoconeldiagramadecomponentesdelsistema. Sistema Help Desk Conclusiones Enestostiemposenque la tecnología se desarrolla a grandes pasos. el cual tiene como propósito general automatizar los procesosde levantamiento. 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. El uso de Rational Rose 98 es otro aspecto importante de mi aprendizaje yaque. es por ello que un sistema como el Help Desk es tan necesario para ofrecer una respuesta inmediata y adecuada en cada caso. El lenguaje de programación Power Builder ZO esunaherramientaquepermitióel desarrollodelsistemahaciendousodeunametodologíaOrientada a Objetosdeforma fácil y transparente. y notificar a los involucrados automáticamente. además de poder conocer más a fondo su uso. de cualquier cambio presentado en el estado de atención de reporte. tanto a nivel personalcomoacadémicoyaquedesarrollélaprimeraetapadelMódulodeAtencióna Usuarios(HelpDesk). administración y atención de reportes de problemas en todo tipo de equiposconquecuentaGrupoYoli. El Help Desk que forma parte de un proyecto de Ingeniería de Software entre la Universidad Autónoma Metropolitana Iztapalapa y Grupo Yoli. es una herramientaCASE que facilita enormemente el trabajo de Análisisy Diseño Orientado a Objetos. me permitió desarrollar mis habilidadesenlaprogramaciónasícomotambiénpuseenprácticalosconocimientos adquiridos en cursos como Anáfisis y Obet70 Orientado a Objetose Ingeniená de Sofbware.Unsector importante enestasempresasesaquelquehaceusodeequipode 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. personal tengo la satisfacción de haber desarrollado un sistema que En el aspecto permitirádaratenciónalosusuariosdeequipodecómputodelaEmpresaYolide Acapulco de forma rápida y eficiente. 5-1 . El haber participado en este Proyecto me deja muchas satisfacciones. Luis Fernando. D. Ivar. Object Oriented Software Engineering. Patrik. Ivar. Benjamin Cummings.F. Análisis y Diseño Orientado a Objetos. Prentice Hall. Edward.. Magnus. 1992 Castro Careaga. William B. Jonsson. 1994 Jacobson. Power Builder 6. Heys. Addison-Wesley. aUse Case Driven Approach Addison-Wesley. 1999. 1995 Jacobson. Object Oriented Analysis and Design with Applications. Universidad Autónoma Metropolitana. Gunnar Object Oriented Software Engineering. Overyaard. 1998 6..Sistema Yourdon.1 . Christerson. Edición Especial. México. El sistema Help Desk Actualiza el catálogo.El Administrador escribe la descripción del Sistema. Al-1 .El Administrador presiona el botón Guardar...Sistema Help Desk Anexo 1 7.. ANEXOS ANEXO 1 Diagramas de Caso de Uso Detallados Catálogo de Sistemas Insertar EnesteUSE CASE el Administrador puede dar de alta un nuevo Sistema dentro del catálogo. 3. 2. - Administrador A\ "---?A Help Desk Figura A L 1 Diagrama de Caso de Uso Insertar Sistema PASOS: 1. - Administrador A\ Help Desk Figura A1. Al -2 .Sistema Help Desk Anexo 1 Catálogo de Sistemas Modificar En este USE CASE el Administrador puede modificar un Sistema dentro del catálogo.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. El sistema Help Desk Actualiza el catálogo..Sistema Help Desk Anexo 1 Catálogo de Sistemas Eliminar En este USE CASE el Administrador puede eliminar un Sistema dentro del catálogo.El Administrador selecciona el Sistema a eliminar del Catálogo. - Administrador A\ Help Desk Figura A L 3 Diagrama de Caso de Uso Eliminar Sistema PASOS: 1. 2.. A l -3 . Sistema Help Desk Anexo 1 Catálogo de Subsistemas Insertar En este USE CASE el Administrador puede dar de altaun nuevo Subsistema dentro del - catálogo.4 Diagrama de Caso de Uso Insertar Subsistema PASOS: 3.El sistema Help Desk Actualiza el catálogo. 1. Al -4 . Administrador A\ Help Desk Figura A1.. 2.El Administrador presiona el botón Guardar..El Administrador escribe la descripción del Subsistema.. Sistema Help Desk Anexo 1 Catálogo de Subsistemas Modificar En este USE CASE el Administrador puede modificar un Subsistema dentro del catálogo. - Administrador A\ 5?/ Help Desk 7 Modificar Subsistema Figura A1.El Administrador escribe la nueva descripción del Subsistema.-El sistema Help Desk Actualiza el cat6logo.5 Diagrama de Caso de Uso Modificar Subsistema PASOS: 1.. 2. Al -5 . 2.El Administrador selecciona el Subsistema a eliminar del Catálogo.El sistema Help Desk Actualiza el catálogo.Sistema Help Desk Anexo 1 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. PASOS: 1.. A1-6 .6 Diagrama de Caso de Uso Eliminar Subsistema. Al -7 ..7 Diagrama de Caso de Uso Insertar Falla PASOS: 1.El Administrador escribe la descripción de la Falla.-El Administrador presiona el botón Guardar. 3.. 2. Administrador A\ Insertar Falla Help Desk Figura A1.El sistema Help Desk Actualiza el catálogo.Sistema Help Desk Catálogo de Fallas Insertar Eneste USE CASE elAdministradorpuededardealtaunanuevaFalladentrodel Anexo 1 - catálogo. .-El sistema Help Desk Actualiza el catálogo.Sistema Help Desk Anexo 1 Catálogo de Fallas Modificar En este USE CASE el Administrador puede modificar una Falla dentro del catálogo.El Administrador escribe la nueva descripción dela Falla 2. A1-8 .8 Diagrama de Caso de Uso Modificar Falla PASOS: 1. - Help Desk Figura A1. 1.Sistema Help Desk Anexo 1 Catálogo de Fallas Eliminar En este USE CASE el Administrador puede eliminar una Falla dentro del catálogo.El sistema Help Desk Actualiza el catálogo. Al -9 .El Administrador selecciona la Falla a eliminar delCatálogo.9 Diagrama de Caso de Uso Eliminar Falla 2... - Administrador A\ Help Desk Figura A1. A1-10 ...10 Diagrama de Caso de Uso Insertar Problema PASOS: 1.El sistema Help Desk Actualiza elcatálogo.El Administrador presiona el botón Guardar.. Administrador A\ Insertar Problema Help Desk Figura Al.El Administrador escribe la descripción del Problema 2.Sistema Help Desk Anexo 1 Catálogo de Problemas Insertar En este USECASE el Administrador puede dar de alta un nuevo Problema dentro del - catálogo. 3. El sistema Help Desk Actualiza el catálogo.Sistema Help Desk Anexo 1 Catálogo de Problemas Modificar En este USE CASE el Administrador puede modificar un Problema dentro del catálogo.11 Diagrama de Caso de Uso Modificar Problema PASOS: 2. - Administrador A\ Modificar Problema Help Desk Figura Al.. L.El Administrador escribe la nueva descripción del Problema Al-11 . .El Administrador selecciona el Problema a eliminar del Catálogo.El sistema Help Desk Actualiza el catAlogo. 1.Sistema Help Desk Anexo 1 Catálogo de Problemas Eliminar En este USE CASE el Administrador puede eliminar un Problema dentro del catálogo.12 Diagrama de Caso de Uso Eliminar Problema PASOS: 2. - Administrador A\ A Eliminar Problema Help Desk Fiqura A1.. Al-12 . \ j ! Figura A2. j .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.2 Diagrama de Colaboración Modificar (Catálogo de Sistemas) A2. - : BQ Yoli : Administrador 2: of-modifica-sistema(desc-sistema. id-sistema) Figura A2.1 . - : Bd Yoli : Administrador 2: of_insetta-sistema(desc-sistema) 1 4: ExecSQLO A l .Sistema Help Desk Anexo 2 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. I w sheet base ~ - > ~ : BC/ Yoli I A I .> . ~~~~~ : Administrador 4: execSQLO Figura A2.. . .Sistema Help Desk Anexo 2 Catálogo de Sistemas Eliminar EI siguiente diagrama corresponde al escenario Eliminar del Subcaso de USOCatálogo de Sistemas... ( J ~~-~ sistemas / w cat :. -. . - 1: desc-subsistema + Guardar ~~ -. .4 Diagrama de Colaboración Insertar(Catálogo de Subsistemas) A2-2 .. .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. .~ .- - ~~ : Administrador 4: ExecSQLO . 1: id-sistema + Eliminar ~. jw cat subsistemas 1 : w sheet base ~ :( B Yoli . . Figura A2." . \'/ id-subsistema) I I ! I .- .j : w sheet base " " "" " A : B d Yoli A I ! . .1 0 ~ 1 cataloaos : u4 I d catalwos i i Figura A2. ~( 7 jw cat subsistemas ' L # ..6 Diagrama de Colaboración Eliminar (Catálogo de Subsistemas) A2-3 .. ..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. 3:of-update-subsistema(desc-subsistema.~ . :on cataloaos : urj ~ b catalwos ~ .Sistema Help Desk Anexo 2 Cat6logo de Subsistemas Modificar El siguiente diagrama corresponde al escenario Modificar del Subcaso de Uso Catálogo de Subsistemas. 2: of-elimina-subsistema(id-subsistema) /I\ Figura A2. ~~~ "~ " : Administrador 2: of-modifica-subsistema(d&c-subsistema. - : B d Yoli : Administrador 4: ExecSQLO A i ~ . id-subsistema)--l--. - 1: desc-subsistema + Modificar . . .-~ I - :v Figura A2.... .id-falla) 4: ExecSQLO /I\ .. ~ . " ~" " " 3: of-update-falla(desc-falla. I! ' V . . - . catalwos . .on : uf ------> id-falla)--.-! j o d catalwos : 4 4 catalwos d ~ Figura A2. " 9 ion catalwos : uf j catalwos b .. : Administrador 2: of_modifica_falla(desc_falla. 1 3: of-set-hlla(desc-hlla. i . id-subsistema) . . - : Bd Yoli : Administrador 2: of_nserta_falla(desc-falla. .7 Diagrama de Colaboración Insertar (Catálogode Fallas) Catálogo de Fallas Modificar El siguiente diagrama corresponde al escenario Modificar del Subcaso de Uso Catálogo de Fallas. - A 2 -T" 1: desc-falla ~ ..Sistema Desk Anexo 2 Catálogo de Fallas Insertar El siguiente diagrama corresponde al escenario Insertar del Subcaso de Uso Catálogo de Fallas. ... ." ! . .. ..8 Diagrama de Colaboración Modificar (Catálogo de Fallas) A2-4 ... id-subs . . w cat fallas : w~ sheet base ~ -1 ~ I : Bd Yoli x ~1 I I"~""". Sistema Help Desk Anexo 2 Catálogo de Fallas Eliminar El siguiente diagrama corresponde al escenario Eliminar del Subcaso de Uso Catálogo de Fallas. - : B d Yoli A 1 1 0 4: ExecSQLO Figura A2.9 Diagrama de Colaboración Eliminar(Catálogo de Fallas) Catálogo de ProblemasInsertar 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ónInsertar (Catálogo de Problemas) A2-5 Sistema Help Desk Anexo 2 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 4: ExecSQLO . " " . ." . . - I : Administrador 2: of-modificagroblema(descgroblema, idgroblema) 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. Yoli : Administrador 4: ExecSQLO 2: of_eliminagroblema(idgroblema) V A2-6 Sistema Help Desk ANEXO 3 Diagramas de Secuencia Secundarios Anexo 3 Catálogo de Sistemas Insertar El siguiente diagrama correspondeal escenario Insertar del Subcaso de Uso Catálogo de Sistemas. - : Administrador y Cat w sheet base ' In gf cataloaos b 'Ota' oaos : gd cataloaos : y f d catslows : BD Y d i desc-sistema + Guardar l . El Adminisirador escribe la descripcibn del sistema. 2 . EIAdminisiraador presiona el botbn > I of-inserta_sistema(desc_sistema) I > , I guardar. 3 . E l Sistema Help Desk actualiza el CetYogo. of_set_sistema(desc_oist~ma) >' ExecSQLO > I I ~ ~ ~ Figura A 3 . 1 Diagrama de SecuenciaInsertar (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 actualizael catálogo. Figura A3.2 Diagrama de Secuencia Modificar (Catálogo de Sistemas) A3- 1 L .Sistema Help Desk Anexo 3 Catálogo de Problemas Modificar El siguiente diagrama corresponde al escenario Modificar del Subcaso de Uso Catálogo de Problemas. - descgmblema + Modificar ~ "" 1..11 Diagrama de Secuencia Modificar (Catálogo de Problemas) Catálogo de Problemas Eliminar El siguiente diagrama corresponde al escenario Eliminar del Subcaso de de Problemas. ~ : : I "3 1 : ^. 1 : ~~ ~.~ __" .12 Diagrama de Secuencia Eliminar (Catálogo de Problemas) A3 -6 . id-problema) j ' -8 . 3. - Uso Catálogo 2. ~ escribe la nwva descripcióndel problema of_modificagroblema(des." of-update-pmblema(id-problema) ~~ . 2. El Sistema Help Desk a c t u a l i z a el Catálogo. El Sistema Help Desk actualizael cat&logo._problema. id-problema) . 3: Ll ~ ExecSQLO 7" I I Figura A3. . of-updategroblema(descgroblema. El Administrador ~ I . " ExecSQLO ' Figura A3.