Enunciado
Quetzalix es una aplicación para hacer el seguimiento de llamadas a un centro help-desk de atención informática a los usuarios de una empresa. Se pretende modelar con UML la información necesaria para hacer un seguimiento de todas las incidencias, es decir, su registro, su resolución y su cierre.
Se provoca una incidencia cuando falla el PC de un usuario. Entonces el técnico del help-desk registra toda la información de la incidencia: fecha de creación, hora de creación, comentario. Se creará un registro con estos datos rellenados y cuatro más:
- el estado de la incidencia, que puede tomar los valores (abierto, en resolución, cerrado). En el momento de registrar la llamada, estado se pone a abierto.
-causa de la resolución. En el momento de registrar la llamada, causa se pone a blancos.
-fecha de la resolución. En el momento de registrar la llamada, este campo se pone a blancos.
-hora de la resolución. En el momento de registrar la llamada, este campo se pone a blancos.
Sus métodos son los necesarios para hacer todo el seguimiento de la incidencia y para actualizar el valor de estado, causa, fecha, y hora de la resolución.
Los datos del usuario son: -nombre
-apellido -localización -PC asignado
Y los métodos para dar de alta a un usuario y para asignarle una operación.
5
Los datos del técnico son: -nombre
-apellido
Y el método para dar de alta a un técnico.
Un usuario está relacionado con sus incidencias, que pueden ser varias o incluso ninguna, y una incidencia está relacionada con un usuario; un técnico registra varias incidencias, incluso ninguna. Lógicamente una incidencia solo puede estar registrada una vez y por un solo técnico. Una vez abierta la llamada, se le asigna a un técnico para que resuelva el problema. Un técnico puede tener varias incidencias asignadas o ninguna, pero una incidencia solo puede ser asignada a un técnico. Una incidencia puede no tener asignada a ninguno, que es en el momento cuando se registra la incidencia. Cuando una incidencia se le asigna a un técnico, estado se pone en resolución. Una vez que el técnico resuelve la incidencia, la cierra, y se actualizan los datos estado (que se pone a cerrado), causa, fecha y día de la resolución. Un técnico puede cerrar muchas incidencias e incluso ninguna; una incidencia solo es cerrada por un técnico y puede que por ninguno (cuando no está resuelta).
Para coordinar todo esto, se crea una lista de incidencias que contiene todas las incidencias. El creador de esta lista es el coordinador. La lista puede estar vacía inicialmente. Una incidencia no puede existir sin pertenecer a esta lista. Un coordinador no es más que un técnico que en un momento puntual asume tareas de coordinación. Los datos de la lista son fecha_apertura y el método necesario para su creación.
Para esta aplicación se solicita:
a. Un diagrama de casos de uso para representar toda la funcionalidad. Identificar bien los actores.
b. Un diagrama de clases del dominio de la aplicación que se han ido describiendo en el enunciado. Es importante mostrar las relaciones que hay entre las distintas clases, indicando multiplicidad en las relaciones de asociación y agregación, e indicando el nombre de las asociaciones. También deben existir los atributos y métodos necesarios para que se pueda cubrir toda la funcionalidad descrita en el enunciado. Indicar los parámetros de los métodos.
c. Según el enunciado, ¿a cuál de las clases se le puede aplicar el patrón Singleton?. Indica cómo quedaría actualizada la clase (sus métodos
CASOS PRÁCTICOS DE UML 73
y/o atributos) para cumplir este patrón, y cual sería el contenido de método(s) nuevos(s) y la inicialización y tipo del nuevo atributo.
d. Un diagrama de estados para reflejar los sucesivos estados por los que pasa una incidencia, con las siguientes características:
- Solo un estado inicial y final. - No hay condiciones.
- No hay estados compuestos.
- Las transiciones deben estar etiquetadas.
- Los estados intermedios deben contemplar los sucesivos estados por los que pasa una incidencia y deben tener las acciones asociadas que afectan a los atributos de la incidencia. Estas acciones se realizan en el momento de entrar en cada estado.
Solución
Diagrama de casos de uso
CASOS PRÁCTICOS DE UML 75
Diagrama de clases
Figura 43. Diagrama de clases
Según el enunciado, los prototipos de los métodos deben tener los parámetros mínimos para realizar la funcionalidad, por tanto quedarían
como sigue, por ejemplo para la clase Incidencia:
Se distinguen métodos que inicializan los parámetros de la clase según el enunciado (registrar), métodos que cambian algún valor de la clase con valores recibidos (los que comienzan por actualizar), y métodos que cambian valor sin necesitar valores recibidos (resolver y cerrar).
De manera análoga se tratan el resto de las clases. Se ha tomado Incidencia por ser la mas compleja.
Patrón Singleton
La clase a la cual se le puede aplicar este patrón es la de ListaIncidencias por tener solo una instancia.
Figura 45. Clase ListaIncidencias
El nuevo atributo ejemplarunico tiene las siguientes características (extraído de la caja de diálogo del Bouml):
Figura 46. Características del atributo ejemplarunico
El método nuevo getejemplarunico tiene el siguiente contenido (extraído de la caja de diálogo del Bouml):
CASOS PRÁCTICOS DE UML 77 Figura 47. Características del método getejemparunico
Diagrama de estados
CASOS PRÁCTICOS DE UML 79