Proyecto Help Desk en plataforma SOA Modelo de Dominio Versión.3 Historia de revisiones Fecha Versión Descripción Autor 8/08/2005.0 Se presenta modelo de dominio, restricciones y observaciones. 25/08/2005. Se agregaron las entidades Alertas, Transición, las subclases de Estado, la base de conocimientos y la asociación subespecialidades, así como aclaraciones y restricciones sobre las mismas. 0/09/2005.2 Se agregaron las entidades Item, CategoriaItem, Tarea, Subastados, SubTareas y Guarda, y asociaciones relacionadas con esas nuevas clases. También, las restricciones que surgieron por el agregado antes mencionado. 08/09/2005.3 Se agregaron las asociaciones responsable, dentro, la asociación entre rol e incidente, la clase AtributoAdicional, el campo fecha_fin y se eliminó hora en la clase Evento, junto a sus restricciones correspondientes. Agustín Centurión Ignacio Moreira Ignacio Moreira Ignacio Moreira Modelo de Dominio Página de
Contenido. MODELO DE DOMINIO...3 2. OBSERVACIONES...4 2.. RESTRICCIONES...4 2.2. OBSERVACIONES Y ACLARACIONES...5 Modelo de Dominio Página 2 de 2
. Modelo de Dominio En esta sección, se incluye el Modelo de Dominio realizado en forma gráfica, para tener una primera idea de la realidad planteada por el cliente. Transicion Prioridad TareaIntermedio TareaFinal TareaInicial inicial final Descripcion:String Tarea de salida dentro de entrada actual Incidente ticket : int descripcion:string descrip_corta:string Alertas Evento fecha_ini : Date fecha_fin : Date descripcion : String Tipo : String asociado Categoria incluido en posee tipo resuelve Especialidad registra Usuario LinkAll tiene busca Base de Conocimiento TipoAplicacion:String Rol Funcionalidad usa asociado Estado Nombre:String responsable subcategoria subespecialidad Guarda condicion : boolean CategoriaItem subcategoria reporto Item problema:string solucion:string descripcion:string archivoadjunto ranking;integer fechaingreso:date asignado EstadoInicial EstadoFinal EstadoNoAsign ado EstadoInterme dio AtributoAdicional nombre: String Tipo : TipoPredefinido Tecnico Administrador Usuario ingresa conoce corresponde tiene {order} Modelo de Dominio Página 3 de 3
2. Observaciones En esta sección, se realizan observaciones y aclaraciones sobre el modelo gráfico presentado en la sección. Las mismas, están separadas en dos partes, restricciones y observaciones. 2.. Restricciones En esta sección, se encuentran restricciones sobre el modelo de dominio, que no se pueden representar en forma gráfica. El Estado Actual del Incidente tiene que ser el mismo Estado de la Tarea asociada al Evento (el cual esta asociado a ese Incidente), con Fecha mas reciente. La Prioridad de un Incidente es mayor o igual que la Prioridad de la categoría de dicho incidente. Los Incidentes son identificados por el ticket. En las transiciones dentro de cada estado, la tarea inicial es distinta a la tarea final. Dentro de cada estado, no puede existir una transición que tenga como tarea inicial a la TareaFinal. Dentro de cada estado,no puede existir una transición que tenga como tarea final a la TareaInicial. Para cada Estado del sistema, debe existir al menos una transición, que tenga en la tarea inicial a la TareaInicial. Para cada estado, debe existir al menos una transición, que tenga en la tarea final a la TareaFinal. Cuando el evento más reciente en el tiempo de un incidente esta asociado al estado EstadoNoAsignado, ése incidente no puede tener asignado un Técnico, y el evento debe de haber sido ingresado por el sistema. Los incidentes que tienen asignados un técnico, deben de tener asociado un evento que describa que el incidente le fue asignado a ese técnico. Los incidentes que tienen asignados un usuario, deben de tener asociado un evento que describa que el incidente fue reportado por ese usuario. Cuando un incidente entra en un estado, el evento mas reciente en el tiempo asociado a ese incidente, se encuentra asociado con la tarea TareaInicial de ése estado. Cuando un incidente que se encuentra en un estado llega a la tarea TareaFinal de ese estado, se da el cambio de Estado del incidente, pasando a la TareaInicial de ese nuevo estado actual. Todo Estado del sistema, debe tener asociado una TareaInicial y una TareaFinal, pudiendo no haber ninguna TareaIntermedia. Un rol registra eventos asociados a una tarea. Esta tarea, debe de estar incluida dentro del grupo de tareas que el rol tiene asignado. Modelo de Dominio Página 4 de 4
2.2. Observaciones y Aclaraciones En esta sección, se incluyen observaciones, aclaraciones y justificaciones sobre las decisiones tomadas para realizar el Modelo de Dominio. Debido a que el cliente especificó que los roles no eran estáticos, sino que estos podrían variar, o sea cambiar el tipo de rol, es que se creó la entidad Rol. El cliente también dio a entender de que existirían tres roles básicos; Administrador, Técnico y Usuario. También se pensó en la posibilidad de tener una entidad Rol, y una generalización con los distintos Roles, dado que se especificó que en algún momento el Usuario tendría un conjunto de Roles dado su perfil. Dicho rol representaría al usuario dentro del Help Desk. También se decidió tener una entidad Evento por el hecho de modelar la realidad de que un Incidente puede llevar un registro de estados, reportes a lo largo de su historia, por lo cual también se puede ver que cada Evento tiene una fecha de inicio y otra de fin, asociados. Ambas fechas, incluyen el día y la hora ( hora, minuto y segundo), ya que de este modo, se simplifica el cálculo de, entre otras cosas, los tiempos dedicados a cada incidente por parte de los técnicos. Cuando un incidente entra en una tarea dentro de un estado, se disparan ciertas alertas según la evaluación de la guarda asociada, al igual que cuando se sale de esa tarea y cuando se encuentra en dicha tarea. Por esto es que se modelaron las asociaciones de salida, dentro y de entrada. Las 3 subtareas (TareaInicial, TareaFinal y TareaNoAsignado) fueron modelados porque son tareas conocidas, y la TareaIntermedio para modelar que se pueden agregar mas adelante, nuevas tareas. Las transiciones modelan el pasaje de una tarea a otra. La guarda, es la condición que se debe de cumplir para que se realice dicho pasaje. La base de conocimiento, es donde el técnico guarda información acerca de los problemas resueltos anteriormente, a la cual pueden consultar los usuarios, el administrador y el propio técnico. La base esta compuesta por un conjunto de Ítems. Un ítem consta de una categoría, la descripción del problema, la descripción de la solución, una descripción corta del problema, una fecha de ingreso, ranking y archivo adjunto. La ideas en las que se basan el modelado de la clase Tarea, es que cada estado en el que puede estar un incidente, contiene un conjunto de Tareas. Las tareas, pueden ser de varios tipos, identificando hasta ahora los tipos TareaInicial, TareaFinal, TareaIntermedio y TareaNoAsignado. Las tareas, tienen asociados transiciones que modelan el paso de una tarea a otra, y también un conjunto de alertas de entrada y de salida, que se disparan en el sistema cuando se entra y se sale respectivamente de esa tarea, y se cumplen sus correspondientes guardas. En la Base de conocimiento, el atributo TipoAplicación se usará para saber qué tipo de aplicación va a usar la Base. La asociación responsable, entre el Técnico y el incidente, sirve para poder modelar cuál es el técnico encargado del incidente, aunque sobre el mismo estén trabajando varios técnicos a la vez, cada uno con diferentes tareas. Cuando un incidente es reportado Modelo de Dominio Página 5 de 5
y se le asigna un técnico por primera vez, el mismo será el responsable. Luego, el técnico responsable y el Administrador serán capaces de cambiar el responsable por otro técnico. La idea, es que el responsable cumpla, entre otras, la funcionalidad de chatear con el usuario que reportó el incidente del cual es responsable. Los Atributos Adicionales, son los que serán ingresados por el administrador, y los mismos tendrán un orden definido. Modelo de Dominio Página 6 de 6