8. Gestién de Peticiones/Portfolio. ITProjects 3. Especificacién de los casos de uso de administracién Alta Template Proyecto Caso de uso: Alta Template Proyecto Actores: Administrador Tipo; primario, esencial Propésito: Crear un nuevo template de planificacién para la creacién de proyectos. Resumen: El usuario administrador desea crear una nueva plantilla (template) de planificacién de proyectos. Curso tipico de acontecimientos Pe ae ate eee ee) 1. El caso de uso se inicia cuando el Administrador indica al sistema que desea dar de alta un nuevo template. 2. El sistema muestra el formulario de alta para los templates. |. El usuario indica el nombre del template y el nombre del fichero de Project que lo contiene. 4. El sistema valida los campos. | 5. El sistema almacena el nuevo, template y muestra el resultado de la operacién. Cursos alternativos Linea 4: El sistema no valida los campos del formulario. El sistema muestra el formula indicando los campos que no son correctos. ~ 249 -8. Gestién de Peticiones/Portfolio. ITProjects Eliminar Template Proyecto Caso de uso Eliminar Template Proyecto Actores: Administrador Tipo: primario, esencial Propésito: Eliminar toda la informacién relacionada con el template indicado. Resumen: El administrador desea eliminar el template. Curso tipico de acontecimientos De CN ace Cee ed Reed EI caso de uso se inicia cuando el | Admit rador indica al sistema que desea eliminar un template existente. 2. El templates existentes en el sistema. istema muestra la lista de los 3. El usuario indica cual es el template que desea eliminar del sistema. 4. El sistema valida el template y muestra un mensaje de confirmacién | al usuario. 5. El usuario confirma que desea eliminar el template. 6. El sistema elimina el template y toda la informacién asociada a el en el sistema. Cursos alternativos Linea | sistema no puede mostrar el listado de los templates posibles. Linea 5: El usuario no confirma la eliminacién. El sistema cancela la eliminacién y finaliza el caso de uso. = 250 -8. Gestién de Peticiones/Portfolio. ITProjects Linea 6: El sistema no puede eliminar el template y la informacién asociada. El sistema muestra un error: “Imposible eliminar el template” y finaliza el caso de uso. ~251-8. Gestién de Peticiones/Portfolio. ITProjects Modificar Template Proyecto Caso de uso Modificar Template Proyecto Actores: Administrador Tipo primario, esencial Propésito: Modificar la informacién de un template de proyecto. Resumen, El administrador desea modificar un template. Curso tipico de acontecimientos Pree ae Taco ee een ae 1. El caso de uso se inicia cuando el Administrador indica al sistema que desea modificar_ un _—_ template existente. 2. El sistema muestra la lista de los | templates existentes en el sistema. 3. El usuario indica cual es el template que desea modificar del sistema. 4, El sistema valida el template y | muestra el formulario de modificacién de los templates. 5. El usuario modifica los campos del formulario del template. 6. El sistema valida los cambios en el template. 7. Almacena la nueva informacién. Cursos alternativos Linea 2: El sistema no puede mostrar el listado de los templates posibles. Linea 5: El usuario no confirma la eliminacién. El ema _cancela la eliminacién y finaliza el caso de uso. = 252 =8. Gestidn de Peticiones/Portfolio. ITProjects Linea 6: EI sistema no puede validar la informacién del formulario. El sistema muestra el formulario indicando los campos incorrectos del formulario. Linea 7: El sistema no puede almacenar la nueva informacion del template. El sistema muestra un mensaje de error: "No se puede guardar la informacién del template.”. = 253 -8. Gestin de Peticiones/Portfolio. ITProjects Alta Usuario Caso de uso Alta Usuario: Actores: Sistema Externo META4, Reloj(Iniciador) Tipo primario, esencial Propésito: Afiadir nuevos usuarios de! Area de Tecnologias al sistema desde la gestién de RR.HH Resumen A las 00:00h de cada dia el usuario Reloj indica al sistema que desea crear los nuevos usuarios del Area de IT que estan presentes en META4. Curso tipico de acontecimientos Pe eae Ree eR mee 1, El caso de uso se inicia a las 00:00h. 2. El usuario Sistema Externo META4 compruebasi_existen nuevos usuarios del Area de IT. 3. El Sistema Externo META4 envia los datos de los nuevos empleados del | Area de IT. 4, El sistema recibe los datos de los usuarios y comprueba si existian con anterioridad. En caso que no existan el sistema da de alta los nuevos usuarios. Cursos alternativos Linea 3: El Sistema Externo META4 no encuentra los datos de los usuarios. El sistema no envia los nuevos usuarios. = 254-8. Gestién de Peticiones/Portfolio. ITProjects Modificar Usuario Caso de uso: Modificar Usuario Actores Sistema Externo META4, Reloj(Iniciador) Tipo! primario, esencial Propésito: Modificar la informacién existente de los usuarios del sistema en funcién de los usuarios del Area de Tecnologias de la gestién de RR.HH Resumen’ ‘A las 00:00h de cada dia el usuario Reloj indica al sistema que desea modificar la informacién de los usuarios que existen en el sistema. Curso tipico de acontecimientos PCN eae Coe ee ee} 1. El caso de uso se inicia a las 00:00h. 2. El usuario Sistema Externo META4 comprueba si existen nuevos usuarios del Area de IT. datos de los empleados del Area de | | 3. El Sistema Externo META4 envia los | I. | 4. El sistema recibe los datos de los usuarios y comprueba si existian con anterioridad. Comprueba sila informacion que ha recibido es diferente de lo que existe en el, sistema y modifica la informacion de los usuarios. Cursos alternativos Linea 3: El Sistema Externo META4 no encuentra los datos de los usuarios. EI sistema no envia los nuevos usuarios. = 255 -8. Gestién de Peticiones/Portfolio. ITProjects Eliminar Usuario Caso de uso: Eliminar Usuario Actores: Sistema Externo META4, Reloj(Iniciador) Tipo: primario, esencial Propésito: Eliminar la informacién del sistema de un usuario. Resumen: A las 00:00h de cada dia el usuario Reloj indica al sistema que desea eliminar a los usuarios que son empleados del Area de IT y que han sido eliminados en META4. Curso tipico de acontecimientos DN ee ace Coe ee ec 1. El caso de uso se inicia a las 00:00h. 2. El usuario Sistema Externo META4 consulta la informacién de los empleados que forman parte del Area de IT. 3, El Sistema Externo META4 envia la informacion al sistema. 4. El sistema recibe los datos y consulta que usuarios que aparecen en el sistema no estén presentes en los datos de META4. El sistema elimina los usuarios del sistema que no estén presentes en META4. Cursos alternativos Linea 3: El Sistema Externo META4 no encuentra los datos de los usuarios. EI sistema no envia los nuevos usuarios. Linea 4: El sistema no puede eliminar los usuarios. Finaliza el caso de uso. = 256 -8. Gestidn de Peticiones/Portfolio. ITProjects Validar Usuario Caso de uso Validar Usuario Actores: Sistema, Usuario(Genérico) (Iniciador) Tipo: primario, esencial Propésito: Identificar el usuario y aplicar la seguridad Resumen: EI usuario arranca la aplicacién. El sistema valida al usuario conectado mediante las credenciales del usuario. El sistema valida con la informacién almacenada en el sistema sobre los usuarios y aplica la seguridad sobre las funcionalidades del sistema. Curso tipico de acontecimientos Pree ade Peer ieee 1, El caso de uso se inicia cuando el usuario inicia la ejecucién del sistema. EI sistema recoge las credenciales del usuario. 3. El sistema recoge las credenciales de! usuario. 4. El sistema el usuario del sistema mediante las credenciales. 5. If usuario es valido then Initiate Aplicar Seguridad else el sistema muestra un mensaje de usuario no) valido. Cursos alternativos Linea : El sistema no puede validar las credenciales con los usuarios del sistema. Muestra un mensaje de error: “El sistema no puede validar el usuario en este momento. Inténtelo més tarde.” = 257 =8. Gesti6n de Peticiones/Portfolio. ITProjects Aplicar Seguridad Caso de uso: Aplicar Seguridad Actores: Sistema (Iniciador) Tipo: primario, esencial Propésito: Aplicar la seguridad del usuario sobre las funcionalidades del sistema. Resumen: EI sistema realiza un recorrido por las funcionalidades del sistema restringiendo el acceso a estas en caso que la seguridad asociada al usuario lo indique. Curso tipico de acontecimientos Pree ae ae Cee oe eer) 1. El sistema inicia el caso de uso cuando tiene que aplicar la seguridad del usuario que ha validado previamente. 2. El sistema la seguridad asociada al usuario. | 3. El sistema modifica el acceso a las| funcionalidades en funcién de la seguridad relacionada con el usuario. Cursos alternatives inea 2: El sistema no puede consultar la seguridad asociada al usuario. El sistema indica que el usuario no es valido a causa que no tiene un modelo de seguridad. = 258 -8. Gestién de Peticiones/Portfolio. ITProjects 8.1.3. Diagrama de Clases El diagrama de clases muestra la representacion de los objetos que tienen relevancia en el sistema. EI diagrama de clases muestra las entidades principales del sistema con los atributos y las relaciones entre ellas (Asociaciones).. 1. Estructura principal de las clases del sistema La estructura principal del diagrama de clases la forman las entidades Proyecto y Peticin y la relacién que tienen entre ellas. En primer lugar se muestra las entidades principales del sistema, las entidades Proyecto y Peticién. Cada proyecto debe estar relacionado como minimo con una peticién. ed Domain Objects” Peticion %Cubleno: integer Dessipcion: Sting Fecha Alta: Date Nombre: Sting ie Asignacion ‘Yeasonacion: Integer ‘AbsProyecto ‘Desxipcion: Sting Fecha. Fin: Date Fecha Inicio: Date * Nombre: Sting A | Proyecto-Tarea Proyecto Figura 98: Entidades Proyecto - Peticién = 259 -8. Gestidn de Peticiones/Portfolio. ITProjects Cada proyecto soluciona un porcentaje de las peticiones que tiene asociadas. Esto se modela mediante la clase asociativa Asignacién. Para cada relacién entre proyecto y peticién almacena el porcentaje de cubricién del proyecto sobre la peticién. Los proyectos se dividen en Proyectos y Proyectos-Tarea. Esta divisién se modela como la especializacién de la clase AbsProyecto que es Abstracta. La estructura principal sobre los empleados se modela de la siguiente manera. ed Domain Objects || [eames | | neeates PefF | | t pt. lente | | Departamento . Petcion Opt Rewoneabie 7 wewbieto: noger ome ot =| oessipcon: Stina {Got debe perenceral Area de I") ot Soliant ubDeparamento T#bala ‘SubBeparar Contacto Cente Rewonsie au ‘Persona Responsable Peticién} ‘apelidor: Sting ; identiieador Sting inilales.Stimg fo. nombre: Sting Figura 99: Clase peticién y estructura de empleados. Para establecer la estructura jerérquica y modelar la estructura empresarial de CUATRECASAS se representa mediante las clases Area - Departamento - Empleado. Dentro de cada departamento puede existir un conjunto de subdepartamento, esto se representa mediante una composicién de departamentos. Para contemplar la informacién sobre quién realiza y gestiona la peticién se afiaden las relaciones, las clases anteriores y la clase que modela la Peticién. = 260 -8. Gestidn de Peticiones/Portfolio. ITProjects Documento brea: Sting Tipo 'NumObe: integer Referencia: Sting Taentfieador, Sting nombre: Sting 1 “es analiss de es tno Documento De Analiss + tanatiza_peticion Clasificacion ext se clastica 7 %eGubieno= Integer : Mentiicador: Sing Descnpcion: Sting nombre: Sting Fecha_Alta: Date Nombre: Sting Tipo: Sting aa : q] deseipcion: Sing hombre: Sting Tipo Probloma Peticlon_Correctva ~ descipcion: Sting 1 4]- Widen: Integer nombre: Sting Figura 100: Clasificacién de las peticiones Para cada reunién se define un conjunto de clasificaciones posibles. Para modelar este hecho se han creado las clases de Tipo y Clasificacién. Tal y como se ha definido si el tipo de peticién es correctivo, la peticién debe llevar asociado un conjunto de problemas. Esta restriccién queda contemplada mediante la especializacién de la clase peticién en la clase Peticion_Correctiva y la utilizacién del atributo derivado /Tipo para discriminar. Por otro lado las clases las peticiones pueden tener asociado un conjunto de documentos. Este conjunto de documentos queda modelado por la clase Documento y la relacién con la peticién. EI diagrama de clases de dominio finalmente esté definido de la siguiente manera = 261-8. Gestidn de Peticiones/Portfolio. ITProjects Figura 101; Diagrama de clases de dominio A continuacin se expresa las restricciones integridad del dominio: Claves Primaria: Clase Clave Peticion Identificador Proyecto Identificador AbsProyecto Nombre Documento NumDoc Tipo Identificador Clasificacion Identificador Estado Nombre Problema N.iden = 262 =8. Gestién de Peticiones/Portfolio. ITProjects Area Identificador Departamento Identificador Empleado Identificador PerfilDeSeguridad Nombre No se han expresado las claves de las clases asociativas ya que son la composicién del conjunto de las claves de las clases de la asociacién. Las restricciones de integridad que no pueden expresarse de forma grafica en el diagrama de clases anterior son: roy Perera) El Jefe de Proyecto debe pertenecer a un departamento del Area de IT. EI departamento responsable de un proyecto debe ser el mismo que el del Jefe de Proyecto. RI.3_ | Los problemas relacionados con los proyectos deben ser la suma de los problemas relaciondos con las peticiones que tienen relacién con el proyecto. RI.4 | El contacto y la persona solicitante deben pertenecer al departamento. RLS | La suma de las asignaciones de las peticiones a los proyectos debe ser menor 0 igual a 100. RL6 | Las personas responsables de las peticiones deben formar parte de un departamento del Area de IT. Tabla 24; Restricciones de Integridad Textuales = 263 -8. Gestién de Peticiones/Portfolio. ITProjects 8.1.4. Diagrama de colaboracién En este apartado se muestran los diagramas de secuencia basicos entre el sistema y los actores. Estos diagramas tienen Ia finalidad de mostrar el aspecto dinamico del sistema de software. 1. Diagramas de secuencia actor ~ sistema de los casos de uso Los diagramas de secuencia muestran, para un escenario particular cuales son los eventos generados por los actores externos sobre el sistema y que operaciones basicas producen en el sistema. Alta Peticién ‘8d Use Case R ‘System TecnicotT InicloNuevaPeticiond MuestaFormulatio TTipo}*|Corectival cago de Us AfadirProblemas | AltaPaticion|Nombre, Destipcién, Tipo) pPeticion Figura 102: Diagrama de Secuencia de Alta Peticién. ~ 264-8. Gestidn de Peticiones/Portfolio. ITProjects Modificar Peticion ‘System ssa Genérico i Iniciar Modifica Petclon:Peticion) MuostraFormularoPeticion() ae Tipfconectvo} 99 do Uso Afadir Problems GvarsarPeticiond | RO sdModiear Peta? | (om Actors) (rom Primary Uso Cases) Figura 103: Diagrama de Secuencia Modificar Peticién Buscar Peticion 6 Buscar Peticion g ‘Sytem ‘Umiaio Genésico InicioBuscarPeticion)) FomulaoBusquedag |g —______fomulariofusauedad BuscaPeticion(nombre, intenaloFechas stp responsable, perwona_responsable) MortrartitadoResitadon) (tom Actors) (tom Pray Uso Cases) Figura 104; Diagrama de Secuencia Buscar Peticién = 265 -8. Gestidn de Peticiones/Portfollo. ITProjects Buscar Mis Peticiones ‘sd Buscar Mis Peticiones | g ‘System Usuario Genérico InicioBuscarMisPatic MosarLitadoRes tom Actors) (rom actors) Figura 105: Diagrama de Secuencia Buscar Mis Peticiones Consultar Peticion ‘8d Consullar Peticion i | Ustatio Genesco | | niiogon iciond p:Poticlon= Caso de Uso BuscarPeticiond) : Mostra‘DatosPeticion(o) (tom Actors) (om Actors) Figura 106: Diagrama de Secuencia Consultar Peticién = 266 =8. Gestion de Peticiones/Portfolio. ITProjects Afiadir Problemas ‘5d Afiadir Problemas g ‘System Ussario Genérico Iniciar AtadirProblemas) Mostrat.itaProblemacdp:ListaProblemas ‘AfadiiProblemalp:Problema) GuardarProbiemas) i -r—rrer) __ui (rom Actors) (tom Actors) Figura 107: Diagrama de Secuencia Afladir Problemas Aiiadir Documento sd Anadir Documento 7 g ‘System Usuario Genérico InleloAnadiocumento() at Not ofaro valido en Humming} Loaintummingbind(ussario.pasowors) Mouira LitaDocumentos HummingbirdOM(:Lé:ListaDacumentos GuardarDocteferenca, liberia, nombre) from Actor) (rom Actors) Figura 108: Diagrama de Secuencia Afiadir Documento = 267 -8. Gestién de Peticiones/Portfolio. ITProjects Enviar Notificacién Responsable ‘sd Enviar Noticacidn Responsable i =| 8 sar Uwagooit Sistema | inictotnviamotteaconResonsbted Enda ine notfieaionesal Sane (Téneo) yal romana ce ew, Figura 109: Diagrama de Secuencia Enviar Notificacién Responsable Alta Proyecto 2d Alta Proyecto 3g ‘System Usuario Genérico IniciarAltaProyecto(p:Peticion) | MuaeraFomularonltaProyectog [Unser fesea afadir Peticiones) Iniciar Madi Peticiones. Iniciar Alta Proyecto EPM (pr: Proyecto) GuardarProyectod prProyecto hom Actors) (rom Actors) Figura 110: Diagrama de Secuencia Alta Proyecto = 268 -8. Gestidn de Peticiones/Portfolio. ITProjects Alta Proyecto EPM ‘84 At Proyecto EP ‘System (tom Actors) (rom Actors) Figura 111: Diagrama de Secuencia Alta Proyecto EPM Afiadir Peticiones ‘Syaem Iniciar Afadir Peticiones) MuestaListaPeticiones) IpListaPotciones oop AfiadiPeticlonp:Peticlon, kadignacion: Integer) GuardarPeticiones) (tom Actor) thom Actors) Figura 112: Diagrama de Secuencia Afiadir Peticione: = 269 -8. Gestién de Peticiones/Portfoli TTProjects cronizar Proyectos EPM ‘st Sneronizar Proyectos EPH Inia SnconzaP yes PM() | CbtenainfomeciontpLetaProyecoe) k cwaluaPoyecon.pépm LisaProyetoEPM) (romécton) (rom keto) Figura 113: Diagrama de Secuencia Sincronizar Proyectos EPM Consultar Proyecto | sa Consultar Proyecto” ‘Umalo Genérico onsltarProyecto) Verinfonmacion(p:Proyecto) MuedtaDatosProyecto(o:Proyecto) (rom Actors) Figura 114: Diagrama de Secuencia Consultar Proyecto ‘Syaom (trom Actors) = 270-jones/Portfolio. ITProjects Buscar Mis Proyectos Mis Proyectos 7 g Syaom | Usiado Genero i Iniciar Buscar Mis Proyectos) ObtenerUsuariog: e: Empleado MosrarLitadoProyectoso: Lp: ListadoProyectos (hom Actors) (tom Actors) Figura 115: Diagrama de Secuencia Buscar Mis Proyectos 2. Diagramas de Secuencia de Administracién Alta Template Proyecto 4 Alta Template Proyecto / ‘System (om Actors) hom Actors) Figura 116: Diagrama de Secuencia Alta Template Proyecto -271-8. Gestién de Peticiones/Portfolio. ITProjects Mo icar Template Proyecto (sa moaiticar Template Proyecto” g ‘System ‘Agminisrador | | | InicioModiticarTemplateProyectog FormularoTemplateProyecttm:Template) ModiicarTemplato(en Template) | homActors) (hom Actors) Figura 117: Diagrama de Secuencia Modificar Template Proyecto Eliminar Template Proyecto 0 Eliminar Template Proyecto / g ‘System Administrador {niclarEliminarTemplateProyecton, ListadoTomplatoProyectoo: Ip: LetaTemplato (rom Actors) (tom Actors) Figura 118: Diagrama de Secuencia Eliminar Template Proyecto -272-8. Gestidn de Peticiones/Portfolio. ITProjects Alta Usuario i (rom Actos) wom Acton) romAcion) Figura 11! jagrama de Secuencia Alta Usuario Modificar Usuario . i Inicdosicatinaiog nenersonod.onpOl: Lemp: Lisatmpleatos (romActos) (romAcion) omacon) Figura 120: Diagrama de Secuencia Modificar Usuario Eliminar Usuario IneorminarUmaro) (tom het) (rom Acton) (rom Acton) Figura 121: Diagrama de Secuencia Eliminar Empleados 273 -8. Gestidn de Peticiones/Portfolio. ITProjects Validar Usuario j = j Sidema ‘Uaiatio Gentico i Iniciar ValidarUsianog Joienercredencial): ue Crodencislessieno Iniciar Cas de Us ApliarSeguidad (tom Acton) (rom) crs) (romActor) ~274-8. Gestién de Peticiones/Portfolio. ITProjects 8.1.5. Diagrama de Representacién/Prototipo En este apartado se muestra la especificacién de las interficies de usuario. Para esto se ha realizado un disefio de las interficies de usuario mediante el prototipado visual. Las siguientes figuras muestran un primer disefio de las interficies de usuario que posterior mente se validan con el usuario final. | IT Projects rojo” Paton | 3848 (Juan Bacort Barra) Tsetse JL | nuova Petcion Paco 1 do 2 | || soiree teste i " Gi rasa - q min tri . i 3 Pere Cos rasan . . §| . 2 ewes 4 . . ress ino] Sp ———— sowie jgura 123: Pantalla Alta Peticion -275-8. Gestién de Peticiones/Portfolio. ITProjects LSS _——— wore - ane J IT Projects a staan nein E a enn 4 (Gemanoentos ae [os ose [enero “ Lonunane |ionen [RT Tiiwere Figura 124: IT Projects Jane (ua Sacer Bares) a (we Tie Sette pome a eae at eee SSS SS os — aes oe E Ss So eee x SSS See 2 H i= Same ee ae % Eco coasscmcomenees| re cctomrs =o leew em xh (xceccmemes I SSS Ss Resse“ fel occ cece pe cee & E ieeon|momnanerreesesenecos | in Une oo x fs eee ee me ° ee ee See eee ac opto ao 2 | =e =e xi eo | som concise (Stems se 4 oe 25 ee ae y [===SSsrs Se b a a) RT) eee es Steere Figura 125: Pantalla Buscar Peticiones - 276 -8. Gestidn de Peticiones/Portfolio. ITProjects IT Projects BAB (an Bacar Barrera) se Chita Cee (exam, foun nse oe 06 ve (sam teoninornce 2 cme tes ‘om Seominomace so Sam Poon (ESS ie seenaae [gman nee | Qronmnee RE iow Figura 126: Pantalla Mis Proyectos 8.1.6. Especificacion de la Seguridad A continuacién se define la seguridad para cada uno de los tipos de usuario que se contemplan en el sistema: Usuario Externo: © Creacién de Peticiones Usuario IT: © Creacién de Peticiones © Modificacién de sus propias peticiones © Consulta de Peticiones/Proyectos © Creacién de Proyectos-Tarea Usuario DIT © Igual al Usuario IT © Creacién de Proyectos Administrador © Igual al Usuario DIT © Administracién de los Templates de generacién de proyecto. -277-8. Gestién de Peticiones/Portfolio. ITProjects 8.1.7. Especificacién de la politica de notificacién Cada vez que se realiza un cambio sobre una peticién o proyecto el sistema debe notificar a los afectados. El sistema de notificacién seleccionado es el e-mail. La politica de notificaciones se define de la siguiente forma: - Se envia una notificacién al responsable de la peticién: © Crear/Modificar una peticién © Crear un proyecto - Se envia al notificacién al responsable jerérquico del responsable de la peticién: © Crear Peticién © Modificar responsable de Peticién © Modificar estado de la Peticién © Crear Proyecto Estas notificaciones se deben enviar mediante el sistema interno de correo e-mail. - 278 -8. Gestidn de Peticiones/Portfolio. ITProjects 8.1.8. Diagrama de Navegacién El diagrama de navegacién muestra de forma grafica el flujo de interaccién entre las diferentes interficies de usuario. A continuacién se muestra el diagrama de interaccién del sistema. Figura 127: Diagrama de navegacién = 279-8. Gestién de Peticiones/Portfolio. ITProjects 8.2. Diseho En la etapa de disefio se define el funcionamiento interno del sistema. Es aqui donde se definen las estructuras de informacién internas y la cooperacién entre ellas para poder llevar a cabo las funcionalidades especificadas en el punto anterior. Para realizar el disefio se han seguido las directrices marcadas en el capitulo 6, donde se define cuales son los puntos que debe contemplar la etapa de disefio. Dado que el desarrollo de todas las partes del disefio para cada uno de los casos de uso anteriores es sumamente extensa, solamente se han desarrollado de forma formal los casos de uso mas importantes del sistema. El ejercicio de disefio se ha realizado con todos los casos de uso pero no se muestra en el documento de manera formal. 8.2.1. Diagrama de Clases de Disefio. En este momento se formaliza las clases identificadas en el apartado de especificacién y se afiaden las clases asociadas a las interficies, controladores, etc. Estas clases adicionales son las que proporcionan el conjunto de funcionalidades descritas anteriormente. La estructura de las clases de disefio se han agrupado por paquetes teniendo en cuenta la estructura de disefio en tres capas. Se ha decidido reducir la formalizacién dado que en caso contrario el documento se amplia de forma considerable. A continuacién se explican las decisiones de disefio principales que se han tomado y como se ha disefiado la estructura en tres capas. 1. Persistencia de Datos En primer lugar el disefio de las clases de la capa de Gestidn de datos. El disefio de la capa se basa el patron de disefio Fachada y Factory de manera que el resultado es el siguiente. = 280 -8. Gestién de Peticiones/Portfolio. ITProjects Somme + Sietober) Boome ‘eon Oban Figura 128: Clases ejemplo de Persistencia de datos Para cada uno de los elementos de dominio que son persistentes se ha disefiado el controlador de persistencia de datos. Estos controladores implementan las Interficies IAccess, IaddRelation y IdeleteRelation. Para el acceso se ha disefiado un control de tipo Singleton de la base de datos que tiene visibilidad sobre el disefio de las interficies. A la vez, este controlador utiliza la clase Singleton ControladorFactory que tiene la responsabilidad de crear los controladores en funcién del objeto que se desea guardar. 2818. Gestidn de Peticiones/Portfolio. ITProjects El objeto controlador implementa las operaciones Load y Save. De forma que dado un objeto de dominio este se puede almacenar en la base de datos instanciando el controladorDB y realizando un Save sobre el objeto de forma transparente a la capa de Dominio. En este caso el sistema gestor de BD's es SQLServer 2000. En base al las entidades del dominio se ha disefiado en conjunto de tablas que forman la estructura de la base de datos. Para realizar este disefio se ha partido del diagrama de clases de especificacién se realizado un ejercicio de normalizacién del esquema, transformando las relaciones en tablas de relacién. ed Domain Objects | Pet 7 wGubieno: Integer Doszipcion: Sting Feona_Alta: Date Nombre: Sting 4 Tipo: Sting Idonticador: intoger | 1 Asignacion ‘Wasgnacion: Integer ‘AbsProyecto TDpt Rewonsable: Sting Deseripcion: Sting | Fecha: Fin: Dale | Fecha inicio: Date | Nombre: Sting | 4 TipoProyecto: Sting 1 Gatogora: Sting Figura 129: Esquema Peticién ~ Proyecto en clases de Especificacin Este esquema se transforma al siguiente conjunto de tablas. = 282-