Download
1 / 32
320 likes | 490 Vues
Expedientes Laborales (EXLA). Ángel Marcos Zamarreño Juanas 20517195. Índice. Análisis Descripción de la aplicación EXLA Diagrama de casos de Uso Diagrama de actividad Casos de Prueba Diseño Modelo Conceptual Modelos de Datos Diagrama de Clases
E N D
Expedientes Laborales (EXLA) Ángel Marcos Zamarreño Juanas 20517195
Índice Análisis Descripción de la aplicación EXLA Diagrama de casos de Uso Diagrama de actividad Casos de Prueba Diseño Modelo Conceptual Modelos de Datos Diagrama de Clases Diagrama de Secuencia y Colaboración Diagrama de componentes Diagrama de Despliegue
Descripción de la aplicación • EXLA (EXpedientesLAborales) es una aplicación informática diseñada para colaborar en la gestión de los usuarios del departamento de Asesoría Jurídica de Red Eléctrica. • Los temas que contempla el sistema son registro de Expedientes y Pleitos. • Se compone de dos grandes partes: • Tablas Maestras: En ellas se define la parametrización que se utilizará durante el uso de la aplicación. • Gestión: Donde se realiza la gestión del departamento validándose los datos con aquellos introducidos en las tablas maestras.
Diagrama de Casos de Uso (I) • Existen dos actores; administrador y usuario en el que el administrador hereda del usuario ya que sus funcionales son las mismas salvo en una operación. • En estos casos de uso lo que se ha hecho es una relación entre el usuario y el caso de uso iniciar sesión; los diferentes casos de uso se relacionan con este a través de un <<extend>> esto quiere decir que hay que hacer obligatoriamente el caso Iniciar Sesión; incluso podría solo hacerse este y posteriormente abandonar la aplicación; la realización del resto de casos de uso es opcional. • Siempre que se modifica un documento posteriormente se ejecuta el caso de uso Relacionar Actuaciones; de ahí la aparición del estereotipo <<include>>
Diagrama de Casos de Uso (III) • Detalle de la única operación diferente entre usuario y administrador; para este caso lo que se ha hecho es una visibilidad directa desde el actor Administrador con los casos Abogados y Procuradores; añadiéndoles una relación <<include>> con Iniciar Sesión la cual es de obligatorio cumplimiento.
Diagrama de Actividad (I) • Modificar gestionExpediente:Incluye el escenario de 3 casos de uso. • Es un caso bastante simple cuya mayor peculiaridad es el hecho de poder cancelar el flujo en cualquier momento. Esto provoca un gran número de decisiones en el diagrama.
Diagrama de Actividad (II) • Modificar Clasificar Tribunal: Diagrama de actividad más usual con un escenario de un caso de uso. • Contempla todos los posibles casos dese la correcta modificación; hasta la introducción fallida de datos con el consiguiente mensaje de error por parte del sistema y la cancelación de la modificación en cualquier momento del desarrollo.
Casos de Prueba • El propósito de un Caso de Prueba es especificar una forma de probar el sistema, incluyendo las entradas con las que se ha de probar, los resultados esperados y los objetivos que se pretenden conseguir con estas pruebas. • Los Casos de Prueba son un producto de desarrollo de software que ayudan a validar y verificar las expectativas de los stakeholders. Deben incluirse tanto entradas esperadas y validas como inesperadas y erróneas.
Modelo Conceptual • En el diagrama se aprecia una clase principal EXLA que será la encargada de gestionar los documentos y los trabajadores con los que cuenta la aplicación • También vemos una relación entre los documentos y los trabajadores ya que los pleitos pueden tener asignado cualquier tipo de trabajador y más de uno mientras que los expedientes pueden tener o no algún abogado asignado a ellos.
Modelo de Datos (Lógico) • En el modelo se distingue una clase expediente; esta tiene asociadas un tipo expediente y actuación expediente que consideré apropiado unificar en una sola clase; • El expediente puede tener un abogado; esta clase abogado tiene a su vez relación con la clase pleito; que a su vez esta se relaciona con la clase procurador. • Muchos de los atributos de procurados coinciden con los de abogado por lo que se decidió que los dos heredasen de una clase Trabajador. • Tribunal y jurisdicción con sus relaciones no se consideraron en el diagrama conceptual; su importancia quedó reflejada en el diagrama de clases que describiremos más adelante en este mismo documento.
Modelo de Datos (Físico) • El paso de un modelo lógico a uno físico requiere un profundo entendimiento del manejador de bases de datos que se desea emplear, incluyendo características como: • Conocimiento a fondo de los tipos de objetos soportados. • Detalles acerca del indexamiento, integridad referencial, restricciones, tipos de datos, etc. • Detalles y variaciones de las versiones. • Parámetros de configuración. • Data DefinitionLanguage (DDL).
Diagrama de Clases • Estructura es muy similar a la del modelo conceptual. • En este diagrama se incluyen métodos en las clases y un mayor nivel de detalle. • Se añaden Sociedad y empleado; las cuales son accesibles desde Documento y las clases Juicio, Tribunal y Jurisdicción.
Diagr. de Interacción (Secuencia) • El usuario (y por herencia el administrador) invocan el método iniciarSesion(login,pass) este mensaje va directamente contra la clase EXLA o controlador principal. A partir de que el usuario se haya validado los mensajes entre el usuario y el sistema se realizan a través de una ventana.
Diagr. de Interacción (Secuencia) • Para llegar a modificar un expediente primero se llama a la operación consultarExpediente() el controlador no llama a ninguna otra clase ya que sólo se debería hacer una consulta a la base de datos; ocurre lo mismo con listaExpedientes. • Pasamos a elegir expediente seleccionando uno de ellos y haciendo click en la figura modificar; de ahí que se le pase un evento desde la ventana al controlador. • Por fin llegamos a la operación principal en esta si intervienen más clases como expediente y posiblemente abogado y empleado. A destacar de esta operación el punto 5.3 que repite insertar campo mientras este campo no sea abogado ni empleado y los puntos 5.4 y 5.5 que son condiciones que sólo transmitirán el mensaje si el nuevo valor es abogado o empleado; a toda esta secuencia me hubiese gustado convertirla en una iteración como se ve en la nota insertada en el mismo diagrama; sin embargo no conseguí dibujar el cuadrado que la representase con el programa Rational Rose. • El punto 6 se refiere a la elección de actuaciones; todos los elementos que aparecen en el diagrama han sido explicados con anterioridad.
Diagr. de Interacción (Colaboración) • Para realizar el diagrama de colaboración se ha partido del diagrama de secuencia y se ha utilizado un patrón controlador que favorece la cohesión del sistema.
Diagrama de Componentes • Se encuentra dividido en paquetes, los cuales cubren todas las zonas de la aplicación de forma disjunta • Se dividen en: • Navegador Web: Donde se manipula la aplicación se encuentra en el cliente (ordenador desde el cual trabaja el usuario). • Servidor web que aprovisiona los datos solicitados por el cliente. • Directorio activo LDAP: Para la autentificación de usuario. • Base de datos: Donde se almacenan expedientes, pleitos…
Diagrama de Componentes • Los componentes son: • Página JSP: La cual permite generar contenido dinámico para web así como javascript y el uso de servlets para el envió y recepción de información. • Controlador de servlet: Regula el tráfico de información entre el servidor web y la página. • Programa de búsqueda: Es realmente el controlador principal; encargado de realizar las operaciones con los datos que dispone y servírselos a bien al cliente o bien a la base de datos. • Una fuente de datos: Este componente se conecta con el controlador y será el encargado de transmitir esta información a la base de datos o al directorio activo.
Diagrama de Despliegue • Sus partes son un cliente que es un ordenador desde el cual usuario accede a la aplicación; esta se conecta con un servidor desde donde se atienden todas las peticiones de los distintos clientes una vez han sido validados. • Para realizar la validación de un usuario este debe estar dado de alta en el directorio activo LDAP; en este directorio se almacenan todos los usuarios de REE; para que un usuario sea dado de alta en una aplicación debe encontrarse en este directorio activo y además un administrador debe darle de alta en la aplicación; esto proporciona un mayor control sobre quien accede a las aplicaciones e intuyo que es el motivo por el cual yo no pude acceder a la aplicación desde mi usuario. • Por último hay una base de datos conectada con el servidor desde donde se sirven los datos solicitados por el cliente o se almacenan.
