Durante este proceso se describirán los principales aspectos técnicos del proyecto a partir de los artefactos obtenidos en el proceso de Análisis. Se realizará el diseño de los componentes que tendrá el software mediante la especificación de la arquitectura tecnológica; los diagramas de arquitectura de software realizados en notación UML, principalmente a través de los diagramas de clase y los diagramas de secuencia; los diseños de las interfaces que ofrecen cada uno de los módulos; los diseños de pantalla que tendrán los módulos y los flujos de navegación entre los mismos.

Para la realización de este proceso, será necesario consultar los artefactos resultados de la disciplina de requisitos, así como los artefactos que son el resultado de la fase de Análisis.

Los siguientes son los roles participantes en este proceso:

Para esta tarea se deben de dar de alta JIRAs con los siguientes datos, y registrar las horas de trabajo en ellas:

2.1. Iniciar la creación de un nuevo Documento de Diseño.

Utilizaremos el siguiente documento maestro:

2.2. Escribir la siguiente sección del Documento de diseño:

• “1. Introducción”, en la que se debe describir de manera resumida el alcance del documento de diseño.
  • Para su elaboración, puede consultarse el documento de Análisis, el de Visión, los requisitos y casos de uso.

Para esta tarea se deben de dar de alta JIRAs con los siguientes datos, y registrar las horas de trabajo en ellas:

2.1. Iniciar la creación de un nuevo Documento de Diseño Modulo.

Tenemos dos plantillas, según sea un Modulo Web o un Modulo de Servicios. Lo único que cambia en esas plantillas es el diagrama de arquitectura tecnológica del módulo.

*Las plantillas hacen uso de los gráficos Diagrama de Arquitectura Tecnológica de Módulo Web y Diagrama de Arquitectura Tecnológica de Módulo de Servicios que también pueden ser descargados y modificados.

De manera similar a la fase de análisis, podemos partir de dos plantillas web proporcionadas por MEDEA con los tipos de módulos mas comunes.

3.1. Para un proyecto basado en Web, podemos utilizar la plantilla que contiene esta arquitectura estándar:

- Documento de Diseño de Modulo Web con su correspondiente:

- Diagrama de Arquitectura Tecnológica de Módulo Web.

3.2. Si no se utiliza esa arquitectura por defecto, o se necesita hacer modificaciones, tendremos que escribir los siguientes apartados en el Documento de Diseño del Modulo.

• X.1 Arquitectura Tecnológica del Módulo
  • “X.1.1 Diagrama de Arquitectura Tecnológica”. Diagrama de arquitectura en el que aparecen la estructura interna del módulo a bajo nivel. Aparecen con que tecnologías se implementan las capas y componentes software más relevantes.
  • “X.1.2 Breve Descripción Arquitectura Tecnológica”. Breve descripción de cada una de esas capas y tecnologías utilizadas.

El gráfico será insertado como objeto OLE (Insertar → Objeto → Objeto OLE), pudiendo arrastrar directamente el documento odg modificado.

En esta tarea se definirá cómo van a estar implementados los distintos Casos de Uso / Historias de nuestro sistema. Este diseño tendrá una parte estática y otra dinámica. No es obligatorio hacer un diseño completo, pero sí hacerlo como mínimo de las historias / casos de uso fundamentales del sistema. Se podrá referenciar a la arquitectura por defecto de un proyecto Fundeweb.

Para esta tarea se deben de dar de alta JIRAs con los siguientes datos, y registrar las horas de trabajo en ellas:

2.1. Escribir la siguiente sección del Documento de Diseño de Modulo:

• “X.2. Diseño UML”.
  • “X.2.1 Modelado de Clases (Estático)”.En este apartado se escribirán tantos diagramas de clases como sean necesarios. Se incluirá tanto el diagrama de clases como su explicación correspondiente. Servirán para la creación posterior de los diagramas de secuencia.

* El diagrama se realizará con la herramienta Astah. Para más información de cómo realizarlo seguir el siguiente manual, en el apartado Diagramas de Diseño

• Por cada diagrama de clases es necesario escribir:
  • “X.2.1.N Diagrama de Clases XXXXX” Aparecerá el diagrama de clases.
  • “X.2.1.N+1 Explicación Diagrama de Clases XXXXX” Explicación del diagrama.

3.1. Escribir la siguiente sección del Documento de Diseño de Modulo:

• “X.2.2 Modelado de Comportamiento (Dinámico)”. En esta sección aparecerán los diagramas de secuencia para modelar como se implementarán los Casos de Uso / Historias de Usuario. Los diagramas de secuencias serán realizados con la herramienta astah UML. Se harán tantos como sean necesarios, sin ser obligatorio tener modelado todo el sistema ni toda una historia completa, al minimo detalle.
  • Por cada diagrama de secuencia será necesario escribir:
    • “X.2.2.N Diagrama de Secuencia XXXXXX”. Aparecerá el diagrama de secuencia.
    • “X.2.2.N+1 Explicación Diagrama de Secuencia XXXXXX”. Explicación del diagrama de secuencia.

• NOTAS:
• X: Número de Modulo en el Documento de Diseño

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

La creación de las interfaces del servicio, será necesario hacerla cuando el proyecto vaya a proporcionar al exterior (aunque sea para utilizarlo dentro sólo de ATICA por otros proyectos), funcionalidad. Ya sea a través de Servicios SOA, Ejbs remotos, Servlet o PAOs.

La forma más eficiente de tenerlo es através de la wiki, ya que los cambios serán visibles instantánemente por todos los usuarios potenciales de la funcionalidad.

En caso de que no exista se deberá crear una entrada en la Wiki del programador, con los servicios del grupo de trabajo.

Por cada servicio publicado, habrá que especificar la información que indicamos a continuación. Ditinguiremos entre una interfaz RMI y otra SOAP, se rellenará la que convenga en cada caso.

• Nombre del Servicio . Nombre del servicio a publicar (Servicio de Gente)
• Acceso RMI . Crear los siguientes subapartados.
  • Interfaz. Se creará una nueva página en la wiki y aqui se colocará un enlace . Aparecerá en ella la especificación de la interfaz del servicio (similar al javadoc del servicio a publicar). Deben estar todos los métodos públicos , sus parámetros y los tipos de datos. Ejemplo:

        /**
         * Devuelve un sello de tiempo calculado sobre los datos que se proporcionan. No incluye el certificado de la TSA.
         * @param claimedIdentity Identificación de la aplicación invocadora
         * @param resumenDigital Resumen digital SHA-1 de los datos sobre los que se desea calcular el sello de tiempo.
         * @return Sello de tiempo calculado sobre los datos proporcionados. No incluye el certificado de la TSA
         * @throws ServicioFirmaUMUException No se ha podido generar el sello de tiempo
         */
        public byte [] generaSelloDeTiempo (ClaimedIdentity claimedIdentity, byte [] resumenDigital) throws ServicioFirmaUMUException;

• 
  
  • Punto de acceso. Se indicará como obtener el EJB. Nombre que tiene al publicarlo. Ejemplo.

    Nombre JNDI del servicio: "ejb/ServicioFirmaUMU".
    Utilizar el siguiente código para recuperar una referencia al servicio: 
     
    ServicioFirmaUMU servicioFirmaUMU = 
       (ServicioFirmaUMU) BuscadorServiciosAtica.obtenerServicio(ServicioFirmaUMU.ID);

• 
  
  • Ejemplo de código. Se creará una nueva página en la wiki, esto será un enlace a esa página. Tendrá distintos ejemplos de llamada usando el servicio.

• Acceso SOAP . Crear los siguientes subapartados.
  • Interfaz WSDL. Se creará una nueva página en la wiki y aqui se colocará un enlace . Aparecerá en ella la especificación del WSDL del servicio.

• 
  
  • Punto de acceso. Se indicará las urls donde está publicado el servicio en desarrollo/explotación. Ejemplo.

    Para el acceso al servicio a través del Servicio Web.
        Servidor de desarrollo: http://eadmin2testpruebas.um.es/eadmin2test/services/ServicioValidacionAvanzadaCertificadosUMU
        Servidor de explotación: http://eadmin2.um.es/eadmin2/services/ServicioValidacionAvanzadaCertificadosUMU

• 
  
  • Ejemplo de código. Se creará una nueva página en la wiki, esto será un enlace a esa página. Tendrá distintos ejemplos de llamada usando el servicio.

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

2.1. Escribir la siguiente sección del Documento de Diseño de Modulo:

• “X.3. Modelo Lógico de Datos”. En él se mostrará el modelado lógico de los datos. Se modelarán los conceptos lógicos del sistema, representados a través de entidades y relaciones, con independencia del sistema físico para realizar la persistencia.
• Por cada diagrama lógico de datos necesario escribir:
  • “X.3.N Diagrama Lógico de Datos XXXXX” Aparecerá el diagrama de Lógico de datos.La herramienta para realizarlo será el Oracle Data Modeler. El diagrama hecho con el data modeler que consistirá en un xml y una carpeta con los datos del diagrama, se comprimirá en un zip para añadirlo al control de versiones. Ayuda extra se puede encontrar en el manual

Para incluir el manual usar la opción File → Print Diagram → To Image File. Luego importarla como imagen.

• “X.3.N+1 Explicación Diagrama Lógico de Datos XXXXX” Explicación del Diagrama Lógico de Datos.

• NOTAS:
  • X: Número de Modulo en el Documento de Diseño

¿Cuando es beneficioso definir la interfaz usuario del sistema ?

• Cuando en el documento de requisitos, no aparece suficientemente reflejado, cómo serán las pantallas de la aplicación.

• Cuando conocemos suficientemente los componentes visuales que vamos a utilizar y ya están sufucientemente probados. Si no, no merece la pena diseñar pantallas que luego cuando sean desarrolladas, vayan a cambiar sustancialmente.

Tampoco va a ser siempre necesario que aparezcan absolutamente TODAS las pantallas de la aplicación. Deberíamos de centrarnos en las que tengan más complejidad y sean más propensas a errores entre la comunicación CLIENTE/ANALISTA DE REQUISITOS , ANALISTA DE REQUISITOS / DESARROLLADORES.

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

2.1. Escribir la siguiente sección del Documento de Diseño de Modulo:

• “X.4. Modelado de Pantallas”. En él se mostrará el diseño de las pantallas de la aplicación. Se incluirán tanto imagenes como diagramas de navegación.

• “X.4.1 Prototipo de Pantallas” En ella se mostrarán imagenes de las pantallas de la aplicación.

¿Con qué herramientas hacer esas imagenes de pantalla?

• Si se dispone de herramientas/conocimiento para realizar pantallas “reales” en este primer prototipo en poco tiempo (menos de 2 dias), se debería de optar por esta opción, ya que será trabajo que ya formará parte del desarrollo. En el documento se incluirán captura de estas pantallas “reales”,en formato png.

• Si no, utilizar la herramienta pencil que permite realizar prototipos fácilmente.

Incluso es posible simplemente dibujarla en papel y más tarde incluirla en el documento, haciendoles una foto. Lo importante NO es la herramienta.

3.1. Escribir la siguiente sección del Documento de Diseño de Modulo:

• “X.4.2 Flujo de Navegación de Páginas”. En este punto se mostrará el diagrama de navegación entre páginas. Se hará un diagrama en OpenDraw en el que aparecerán las páginas (nombre de la página en cajas) y flechas interconectándolas, indicando que se puede navegar de una a otra.

• NOTAS:
  • X: Número de Modulo en el Documento de Diseño

• NOTAS:
  • XXX: Código del proyecto.
  • 1.2.3: Número de version del documento.
  • [NombreMódulo]: Nombre del módulo que se describe en este documento.

• NOTAS:
  • XXX: Código del proyecto.
  • 1.2.3: Número de version del documento.
  • [NombreMódulo]: Nombre del módulo que se describe en este documento.

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.Gestionproyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja ANA.

1. Abre el fichero Diagramas UML.

- Cuenta el numero de clases que cuelgan de la carpeta Diseño.

1. Ir a la wiki del grupo de trabajo. Identificar el número de Servicios en la wiki que se van a desarrollar / modificar.

1. Ir a la wiki del grupo de trabajo. Identificar el número de Servicios en la wiki que se van a desarrollar / modificar.

- Por cada Servicio ir a la página de Definición de la Interfaz y contar el número de mñetodos a desarrollar / modificar.

1. Abrir el documento Modelo Lógico de Datos.
2. Ir a Logical carpeta Entities. Contar el número de entidades.

1. Por cada documento de diseño del modulo.
   1. Abrir el documento
   2. Contar el numero de pantallas. Añadirlo al número final.