User guide and best practices for NDT-Profile 2.X Proyecto NDT-Suite 2.X Autor: IWT2 Gruop Version: 02.03 Date: 05/05/2010

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Hoja de Control de Modificaciones

Hoja de Control de Modificaciones Título

Guía de uso y buenas prácticas para NDT-Profile 2.X

Versión

02.03

Realizado

Grupo IWT2

Fecha:

07/04/2011

CONTROL DE VERSIONES Versión

Descripción / Motivo versión

Fecha de presentación

01.00

Documento inicial

12/09/2008

01.01

Añadidos artefactos para la gestión del 02/03/2009 mantenimiento del sistema

01.02

Corregida la numeración de tablas y figuras

01.03

Incorporadas las modificaciones solicitadas 17/03/2008 por los técnicos de la Oficina Técnica de Calidad y Gestión de Proyectos

01.04

Comentarios de los técnicos de la Oficina 31/03/2009 Técnica de Calidad y Gestión de Proyectos

02.00

Revisión del documento para su adaptación 26/11/2009 a NDT-Profile 2.X

02.01

Corrección de errores tras modificaciones 13/04/2010 en NDT-Profile 2.X

02.02

Corrección de errores por parte de Julián 05/05/2010 García

02.03

Se completa la información de campos 07/04/2011 obligatorios en la definición de los requisitos funcionales

07/03/2009

Página 2 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Índice

Índice 1. 2.

Objetivos del documento.....................................................................................................................9 Introducción a NDT-Suite ..................................................................................................................10 2.1. NDT-Profile................................................................................................................................10 2.2. NDT-Quality...............................................................................................................................10 2.3. NDT-Driver ................................................................................................................................10 2.4. Uso de este manual ..................................................................................................................11 3. Descripción de NDT-Profile...............................................................................................................12 3.1. Paquetes y estructura de carpetas............................................................................................12 3.2. Matrices de trazabilidad ............................................................................................................14 3.3. Baselines...................................................................................................................................16 4. Modelado UML con Enterprise Architect. Reglas generales .............................................................20 4.1. Diagramas .................................................................................................................................20 4.1.1. Diagramas de casos de uso .............................................................................................22 4.1.2. Diagramas de actividades ................................................................................................22 4.2. Artefactos ..................................................................................................................................23 4.3. Conectores ................................................................................................................................34 5. Buenas prácticas comunes a todos los elementos ...........................................................................38 5.1. Subsistemas..............................................................................................................................38 5.2. Matrices de trazabilidad ............................................................................................................38 5.3. Buenas prácticas para los artefactos ........................................................................................39 5.4. Linkado de documentos ............................................................................................................40 6. Participantes......................................................................................................................................42 7. Control de versiones .........................................................................................................................45 8. Objetivos del proyecto.......................................................................................................................47 9. Estudio de Viabilidad del Sistema (EVS)...........................................................................................48 10. Ingeniería de Requisitos....................................................................................................................50 10.1. Objetivos del sistema ................................................................................................................52 10.2. Modelo de negocio ....................................................................................................................54 10.2.1. Modelos de procesos........................................................................................................55 10.2.2. Identificación de servicios.................................................................................................55 10.3. Requisitos de almacenamiento de información.........................................................................57 10.4. Nuevas naturalezas...................................................................................................................62 10.5. Requisitos de actores................................................................................................................63 10.6. Requisitos funcionales ..............................................................................................................67 10.7. Requisitos de interacción ..........................................................................................................70 10.7.1. Frases...............................................................................................................................70 10.7.2. Prototipos de visualización ...............................................................................................76 10.7.3. Listados ............................................................................................................................79 10.8. Requisitos no funcionales .........................................................................................................82 11. Análisis del sistema...........................................................................................................................87 11.1. Definición de servicios...............................................................................................................89 11.2. Clases de contenido..................................................................................................................92 11.3. Modelo de navegación ..............................................................................................................96 11.3.1. Actores en estudio............................................................................................................96 11.3.2. Nodos ...............................................................................................................................99 11.3.3. Queries ...........................................................................................................................102 11.3.4. Índices ............................................................................................................................105 11.3.5. Menús.............................................................................................................................106 11.4. Modelo de interfaz abstracta ...................................................................................................108

Página 3 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Índice 12. Diseño del sistema ..........................................................................................................................109 12.1. Diseño de servicios .................................................................................................................111 12.2. Descripción de la arquitectura.................................................................................................116 12.3. Modelo de clases de diseño....................................................................................................116 12.3.1. Acceso a datos ...............................................................................................................117 12.3.2. Negocio ..........................................................................................................................119 12.3.3. Presentación...................................................................................................................121 12.4. Prototipos de diseño................................................................................................................123 12.5. Modelo físico de datos ............................................................................................................124 13. Construcción ...................................................................................................................................125 14. Pruebas del sistema........................................................................................................................126 14.1. Pruebas de implantación.........................................................................................................127 14.2. Pruebas de sistemas...............................................................................................................130 14.3. Pruebas de aceptación............................................................................................................132 14.4. Ejecución de las pruebas ........................................................................................................136 15. Mantenimiento del sistema..............................................................................................................139 16. Generar documentación..................................................................................................................143 17. Reparar y Compactar el fichero EAP...............................................................................................145 18. Glosario ...........................................................................................................................................146 19. Bibliografía y referencias .................................................................................................................147

Página 4 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Lista de Figuras

Lista de Figuras Figura 1. Pantalla principal de Enterprise Architect ....................................................................................12 Figura 2. Eligiendo elementos en el toolbox ...............................................................................................13 Figura 3. Caja de herramientas del navegador del proyecto ......................................................................14 Figura 4. Listado de matrices de trazabilidad .............................................................................................15 Figura 5. Accediendo a la gestión de baselines..........................................................................................16 Figura 6. Versionado de baselines .............................................................................................................17 Figura 7. Comparar el estado actual con el anterior ...................................................................................17 Figura 8. Completa visualización del estado de cada uno de los artefactos...............................................18 Figura 9. Botones de comparación de baselines ........................................................................................18 Figura 10. Importar y exportar baselines ....................................................................................................19 Figura 11. Eligiendo el tipo de diagrama ....................................................................................................20 Figura 12. Ejemplo de diagrama de caso de uso bien construido ..............................................................22 Figura 13. Ventana de propiedades (pestaña General)..............................................................................24 Figura 14. Eligiendo detalles (pestaña Details)...........................................................................................25 Figura 15. Pantalla de atributos ..................................................................................................................26 Figura 16. Pantalla de introducción de la cardinalidad ...............................................................................27 Figura 17. Pantalla de operaciones ............................................................................................................28 Figura 18. Pantalla de condiciones de un artefacto....................................................................................29 Figura 19. Visualizando los links de un artefacto........................................................................................30 Figura 20. Definiendo los escenarios de un artefacto.................................................................................31 Figura 21. Pestaña de vinculación de archivos..........................................................................................32 Figura 22. Pestaña de visualización de los valores etiquetados.................................................................33 Figura 23. Propiedades generales de un conductor ...................................................................................34 Figura 24. Pestaña para definir condiciones en un conector ......................................................................35 Figura 25. Pestaña source y target role de un conector .............................................................................36 Figura 26. Ejemplo de matriz de trazabilidad..............................................................................................38 Figura 27. Linkado de documentos.............................................................................................................40 Figura 28. Toolbox Participantes ................................................................................................................42 Figura 29. Propiedades estándares de Participantes .................................................................................43 Figura 30. Valores etiquetados de Participantes ........................................................................................44 Figura 31. Propiedades estándares de Control de Versiones ....................................................................45 Figura 32. Estructura del EVS ....................................................................................................................48 Figura 33. Estructura del DRS ....................................................................................................................51 Figura 34. Toolboxes para requisitos..........................................................................................................52 Figura 35. Toolbox para objetivos...............................................................................................................52 Figura 36. Propiedades estándares de un objetivo.....................................................................................53 Figura 37. Crear un nuevo Diagrama de Procesos para definir el modelo de negocio...............................55 Figura 38. Toolbox para servicios...............................................................................................................55 Figura 39. Propiedades estándares de un Servicio ....................................................................................56 Figura 40. Toolbox para requisitos de la información .................................................................................58 Figura 41. Propiedades estándares de un requisito de almacenamiento ...................................................59 Figura 42. Tipos de datos ...........................................................................................................................61 Figura 43. Valores etiquetados de un requisito de almacenamiento ..........................................................61 Figura 44. Valores etiquetados de una nueva naturaleza...........................................................................63 Figura 45. Toolbox para actores .................................................................................................................64 Figura 46. Propiedades estándares de un actor .........................................................................................65 Figura 47. Valores etiquetados de un actor ................................................................................................65 Figura 48. Toolbox para requisitos funcionales ..........................................................................................67

Página 5 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Lista de Figuras Figura 49. Propiedades estándares de un requisito funcional ....................................................................68 Figura 50. Valores etiquetados de un requisito funcional ...........................................................................69 Figura 51. Toolbox para frases ...................................................................................................................71 Figura 52. Propiedades de un artefacto UIControl......................................................................................72 Figura 53. Propiedades estándares de una frase .......................................................................................73 Figura 54. Valores etiquetados de una frase ..............................................................................................73 Figura 55. Conexiones de los artefactos de interacción .............................................................................75 Figura 56. Toolbox para prototipos de visualización...................................................................................77 Figura 57. Propiedades de un prototipo de visualización ...........................................................................78 Figura 58. Valores etiquetados de un prototipo de visualización................................................................79 Figura 59. Toolbox para listados.................................................................................................................80 Figura 60. Propiedades de un listado .........................................................................................................81 Figura 61. Valores etiquetados de un listado..............................................................................................81 Figura 62. Toolbox para requisitos no funcionales .....................................................................................83 Figura 63. Propiedades de un requisito no funcional..................................................................................84 Figura 64. Valores etiquetados de un requisito no funcional ......................................................................85 Figura 65. Estructura del DAS ....................................................................................................................88 Figura 66. Toolboxes de análisis ................................................................................................................88 Figura 67. Toolbox de servicios de análisis ................................................................................................89 Figura 68. Propiedades estándares de un Servicio ....................................................................................90 Figura 69. Toolbox de clases de contenido ................................................................................................93 Figura 70. Propiedades estándares de clases de persistencia...................................................................94 Figura 71. Valores etiquetados de una clase de análisis............................................................................95 Figura 72. Toolbox para actores de estudio................................................................................................96 Figura 73. Propiedades estándares de un actor de estudio .......................................................................97 Figura 74. Valores etiquetados de un actor de estudio...............................................................................98 Figura 75. Toolbox para las clases del modelo navegacional ....................................................................99 Figura 76. Propiedades estándares y valores etiquetados de un nodo ....................................................100 Figura 77. Propiedades estándares y valores etiquetados de una query .................................................103 Figura 78. Propiedades estándares y valores etiquetados de un índice...................................................105 Figura 79. Propiedades estándares y valores etiquetados de un menú ...................................................107 Figura 80. Estructura del DDS ..................................................................................................................110 Figura 81. Toolboxes de diseño................................................................................................................110 Figura 82. Toolbox de servicios de diseño ...............................................................................................112 Figura 83. Propiedades estándares de un Servicio de diseño..................................................................113 Figura 84. Toolbox de clases de diseño ...................................................................................................117 Figura 85. Propiedades estándares y valores etiquetados de una clase de acceso a datos....................118 Figura 86. Propiedades estándares y valores etiquetados de una clase de negocio ...............................120 Figura 87. Propiedades estándares y valores etiquetados de una clase de presentacion .......................122 Figura 88. Estructura del la fase de construcción .....................................................................................125 Figura 89. Estructura del DPS ..................................................................................................................126 Figura 90. Artefactos de pruebas..............................................................................................................127 Figura 91. Toolbox para pruebas de implantación....................................................................................127 Figura 92. Propiedades estándares de una prueba de implantación........................................................128 Figura 93. Valores etiquetados de una prueba de implantación...............................................................129 Figura 94. Toolbox para pruebas de sistema............................................................................................130 Figura 95. Propiedades estándares de una prueba de sistema ...............................................................131 Figura 96. Toolbox para pruebas de aceptación.......................................................................................133 Figura 97. Propiedades estándares de una prueba de aceptación ..........................................................134 Figura 98. Toolbox para la ejecución de pruebas .....................................................................................136 Figura 99. Propiedades estándares de una batería de pruebas...............................................................137

Página 6 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Lista de Figuras Figura 100. Estructura del DMS................................................................................................................139 Figura 101. Toolbox de mantenimiento ....................................................................................................140 Figura 102. Propiedades estándares de una petición de mantenimiento .................................................140 Figura 103. Valores etiquetados de una petición de mantenimiento ........................................................141 Figura 104: Master Document DRS..........................................................................................................143 Figura 105. Ventana de opciones generación de documentación en EA .................................................144 Figura 106. Compactar ficheros EAP .......................................................................................................145

Página 7 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Lista de Tablas

Lista de Tablas Tabla 1. Reglas de uso de manual .............................................................................................................11 Tabla 2. Reglas Paquetes y estructuras de paquetes ................................................................................14 Tabla 3. Reglas matrices trazabilidad.........................................................................................................15 Tabla 4. Reglas de los baselines ...............................................................................................................19 Tabla 5. Tipos de diagramas para los apartados del proyecto ...................................................................21 Tabla 6. Reglas para Diagrama de Actividades..........................................................................................23 Tabla 7. Matrices de Trazabilidad...............................................................................................................39 Tabla 8. Reglas de Documentos.................................................................................................................41 Tabla 9. Nomenclatura de Participantes.....................................................................................................42 Tabla 10. Reglas de Participantes ..............................................................................................................44 Tabla 11. Reglas de Control de Versiones .................................................................................................46 Tabla 12. Reglas de Objetivos....................................................................................................................47 Tabla 13. Nomenclatura de Estudio de Viabilidad ......................................................................................49 Tabla 14. Nomenclatura de Requisitos.......................................................................................................50 Tabla 15. Reglas de Objetivos (OBJ) .........................................................................................................54 Tabla 16. Reglas de Servicios ....................................................................................................................57 Tabla 17. Reglas de Requisitos de Almacenamiento (RA) .........................................................................62 Tabla 18. Reglas de Nuevas Naturalezas (NA) ..........................................................................................63 Tabla 19. Reglas de Actores (AC) ..............................................................................................................66 Tabla 20. Reglas de Requisitos Funcionales (RF)......................................................................................70 Tabla 21. Reglas de Frases (FR)................................................................................................................76 Tabla 22. Reglas de Prototipos de Visualización (PV)................................................................................79 Tabla 23. Reglas de Listados (LI) ...............................................................................................................82 Tabla 24. Reglas de Requisitos No Funcionales (RNF) .............................................................................85 Tabla 25. Nomenclatura de Análisis ...........................................................................................................87 Tabla 26: Tipificación técnica de los Servicio .............................................................................................91 Tabla 27. Reglas de Servicios de Análisis..................................................................................................92 Tabla 28. Reglas de Clases de Persistencia (CL y CLn) ............................................................................95 Tabla 29. Reglas de Clases de Navegación...............................................................................................96 Tabla 30. Reglas de Actores en Estudio (AE).............................................................................................98 Tabla 31. Reglas de Nodos (NO)..............................................................................................................101 Tabla 32. Reglas de Queries (QU) ...........................................................................................................104 Tabla 33. Reglas de Índices (IN) ..............................................................................................................106 Tabla 34. Reglas de Menús (ME) .............................................................................................................108 Tabla 35. Nomenclatura de Diseño ..........................................................................................................109 Tabla 36: Tipificación técnica de los Servicios..........................................................................................114 Tabla 37. Reglas de Servicios de Diseño .................................................................................................116 Tabla 38. Reglas de Acceso a datos (AD)................................................................................................119 Tabla 39. Reglas de Negocio (NE) ...........................................................................................................121 Tabla 40. Reglas de Clases de presentación (PR) ...................................................................................123 Tabla 41. Reglas de Modelo Físico de Datos ...........................................................................................124 Tabla 42. Nomenclatura de Pruebas ........................................................................................................126 Tabla 43. Reglas de Pruebas (PI, PS, PA) ...............................................................................................135 Tabla 44. Nomenclatura de Mantenimiento ..............................................................................................139 Tabla 45. Reglas de Mantenimiento (IS, PM) ...........................................................................................142 Tabla 46. Glosario.....................................................................................................................................146 Tabla 47. Bibliografía................................................................................................................................147

Página 8 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 1. Objetivos del documento Este documento surge como fruto del trabajo de 10 años de los componentes del grupo de investigación en Ingeniería Web y Testing Temprano de la Universidad de Sevilla. Uno de los principales productos obtenidos en estos años es la metodología de desarrollo NDT orientada a entornos web e hipermedia. En la web http://www.iwt2.org/ se puede encontrar un recopilatorio de los trabajos más destacados producidos en estos 10 años, así como las herramientas de soporte a NDT mencionadas en las siguientes secciones.

Página 9 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 2. Introducción a NDT-Suite Navigational Development Techniques (NDT) es una metodología para el desarrollo de sistemas Web e hipermedia. NDT-Suite es un conjunto de herramientas para aplicar la metodología NDT. NDT-Suite soporta las fases de requisitos, análisis, diseño, construcción e implantación, pruebas y mantenimiento, todas ellas basadas en la metodología Métrica V3. La fusión realizada se basa en definir un proceso, similar al de Métrica V3 pero haciendo uso de los modelos de UML y de las extensiones que NDT realiza de ellos, así como de sus procesos de ingeniería guiada por modelos. NDT-Suite se compone de cuatro herramientas, que son: NDT-Profile, NDT-Quality y NDT-Driver. 2.1. NDT-Profile NDT-Profile es una herramienta diseñada sobre un perfil definido, en base a los metamodelos de NDT, sobre la herramienta Enterprise Architect. Tras un estudio comparativo de 10 herramientas, esta fue la que daba mayor soporte y ofrecía mejores ventajas. El profile (perfil) sobre Enterprise ofrece una serie de herramientas y definición de artefactos propios para trabajar con la metodología NDT permitiendo una sencilla gestión de documentación. Este profile se distribuye como un proyecto vacío de Enterprise Architect. El uso de NDT-Profile ofrece la posibilidad de disponer de todos los artefactos de NDT de una manera sencilla, puesto que están integrados en la propia herramienta pero, además, también permite utilizar todos los modelos de UML e integrarlos fácilmente en la metodología NDT. Como novedad, la herramienta NDT-Profile 2.X proporciona un conjunto de plantillas con los que generar de manera totalmente automática un documento para algunas de las fases del ciclo de vida. En concreto: las fases de requisitos, la fase de análisis, la fase de diseño y la fase de pruebas del sistema. Encontrará más información en el apartado 16-Generar documentación de este documento. 2.2. NDT-Quality NDT-Quality automatiza parte de la revisión metodológica de un proyecto desarrollado con NDT-Profile, creando un informe con la descripción de las inconsistencias que se han encontrado durante la revisión, verificando además que el paso de requisitos a análisis y de análisis a diseño se hace forma correcta. NDT-Quality genera un informe consistente en una serie de errores cometidos. Estos errores están tipificados como “Leves” y “Graves” y revisan aspectos propios de la metodología NDT como fallos en definiciones completas, malas definiciones de restricciones, etc. Los errores, además, se muestran agrupados según la fase en la que se hayan cometido: Estudio de Viabilidad, Requisitos, Análisis, Diseño o Pruebas. Además, también valida la trazabilidad entre las fases y controla la consistencia entre una y otra fase. También comprueba que el prototipo resultante sea navegable. 2.3. NDT-Driver NDT-Driver permite, tomando como entrada un fichero elaborado mediante NDT-Profile 2.X, ejecutar de manera automática las transformaciones definidas en la metodología NDT. Para ello, es imprescindible que la herramienta NDT-Quality no informe de ningún error grave.

Página 10 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Esta herramienta sólo genera los modelos básicos de la fase en cuestión, proporcionando un punto de partida al usuario para que éste complete dichos modelos básicos. 2.4. Uso de este manual Este manual describe en detalle el uso de NDT-Profile, así como las buenas prácticas que son obligatorias. Las herramientas de soporte solo podrán utilizarse si se han seguido las buenas prácticas definidas en este manual. Tabla 1. Reglas de uso de manual

Buenas prácticas Las buenas prácticas de este manual son de aplicación obligatoria en todos los proyectos desarrollados sobre NDT-Profile. No se dará por válido ningún entregable que haya modificado u omitido la estructura de información y buenas prácticas definidas en este documento

Página 11 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 3. Descripción de NDT-Profile 3.1. Paquetes y estructura de carpetas El perfil de NDT se distribuye como un proyecto vacío para la herramienta Enterprise Architect, el cual funciona como plantilla para crear nuevos proyectos. Las fases de desarrollo incluidas en el proyecto son las fases definidas en Métrica. Dichas fases serán identificadas por las siguientes siglas. - EVS: documento del estudio de viabilidad del sistema. - DRS: documento de requisitos del sistema. - DAS: documento de análisis de sistema. - DDS: documento de diseño del sistema. - DPS: documento de plan de pruebas del sistema. - DMS: documento de mantenimiento del sistema. Además, se introduce una serie de carpetas con información adicional sobre el proyecto: - PARTICIPANTES: se describirán las empresas y personas que participarán en el proyecto. - CONTROL DE VERSIONES: se describirán las diferentes líneas bases (baselines). - OBJETIVOS DEL PROYECTO: se describirán los objetivos a cumplir en el proyecto. Una vez se abre la plantilla, el equipo se encuentra con la pantalla principal que se muestra en la Figura 1. NOTA: La distribución mostrada en la Figura 1 podría verse modificada si el usuario de la herramienta Enterprise Architect la hubiera alterado según sus preferencias.

Figura 1. Pantalla principal de Enterprise Architect

En el centro (marcado con el número 1 en la Figura 1) se encuentra la zona de trabajo sobre la que se desarrolla el diagrama abierto. Aquí es donde aparecerán todos los elementos que se encuentren

Página 12 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario dibujados en el diagrama que se encuentre activo en ese momento. Justo debajo hay una serie de pestañas, que corresponden con los diagramas que se encuentren abiertos. A la zona de trabajo han de ir agregándose los artefactos, enlaces y demás elementos que se consideren necesarios a partir del toolbox (marcado con el número 2 en la Figura 1). Cada tipo de diagrama tiene un toolbox asociado, que será el que se active cuando se muestre el diagrama. Si no se visualiza el panel del toolbox, éste se muestra pulsando sobre el menú View > Toolbox, o bien pulsando Alt+5. También es posible seleccionar el conjunto de herramientas con el que se desea trabajar en la caja de herramientas (como se muestra en la Figura 2). Por ejemplo, para seleccionar las herramientas de requisitos en la caja de herramientas, se selecciona en “More tools…”, se posiciona sobre “NDT Requisitos del Sistema” y se selecciona el toolbar correspondiente.

Figura 2. Eligiendo elementos en el toolbox

En el perfil de NDT existen siete conjuntos de herramientas, uno para cada una de las fases del ciclo de vida que cubre:  NDT Control de cambios y participantes, para cubrir esas secciones  NDT Estudio de viabilidad, para cubrir la fase de estudio de viabilidad  NDT Requisitos, para cubrir la fase de ingeniería de requisitos  NDT Análisis, para cubrir la fase de análisis  NDT Diseño, para cubrir la fase de diseño  NDT Pruebas, para cubrir la fase de pruebas  NDT Mantenimiento, para cubrir la fase de mantenimiento En cada momento, el equipo de desarrollo seleccionará el conjunto de herramientas correspondiente a la fase en la que estén trabajando.

Página 13 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Arriba a la derecha se encuentra el Project Browser (marcado con el número 3 en la Figura 1), que permite navegar en el proyecto. Aquí se muestran paquetes, diagramas, elementos y propiedades de elementos. Desde aquí se permite arrastrar y soltar elementos entre carpetas, o bien arrastrar hacia el diagrama activo. Además, haciendo clic derecho sobre los elementos se pueden realizar diferentes acciones sobre los mismos. Si no se visualiza el panel del Project Browser, éste se muestra pulsando sobre el menú View > Project Browser, o bien pulsando Alt+0. Abajo a la derecha se encuentran diferentes paneles (marcado con el número 4 en la Figura 1) de diversas utilidades. Entre ellos encontramos el panel Notes, que muestra la descripción del elemento que se encuentra activo en ese momento o el panel Tagged Values, que nos muestra los valores etiquetados de los artefactos. Éste último es necesario, puesto que existen valores etiquetados de obligado cumplimiento y, aunque éstos sean opcionales, los valores etiquetados nos dan información importante sobre los artefactos. Para visualizar el panel Tagged Values hay que activar en el menú la opción View > Tagged Values, o bien pulsar Ctrl+Mayusculas+6. Dentro del navegador del proyecto hay una serie de opciones (Figura 3) como crear documento, diagrama, clases, carpetas, búsqueda y avanzar y retrasar en el navegador:

Figura 3. Caja de herramientas del navegador del proyecto

Con el primer botón creamos una carpeta principal (que cuelga directamente del proyecto). En NDTProfile este botón no es necesario que lo utilicemos. El segundo botón nos permite crear un paquete. El tercer botón abre el cuadro de diálogo para crear un nuevo diagrama. El cuarto botón abre el cuadro de diálogo para crear un nuevo documento. Tabla 2. Reglas Paquetes y estructuras de paquetes

Buenas prácticas La estructura de carpetas del NDT-Profile no puede ser modificada. Solo se puede crear nuevas carpetas dentro de las carpetas ya existentes. Se permite importar elementos de una carpeta a otra, arrastrándolo con el ratón o con la opción “move” del Enterprise Architect. La carpeta PROFILE, en caso de aparecer, nunca debe ser modificada

3.2. Matrices de trazabilidad Mantener la trazabilidad entre los artefactos de un proyecto es una de las tareas más importantes en los proyectos software. NDT-Profile gestiona la trazabilidad de artefactos mediante el uso de las matrices de trazabilidad. Las matrices de trazabilidad son una herramienta de visualización que permite ver de manera cómoda y global, todas las relaciones existentes entre dos grupos de elementos (por ejemplo entre requisitos y casos de uso o entre casos de uso y clases). Esto la convierte en la herramienta perfecta para añadir un gran número de relaciones rápidamente y, por tanto, en la herramienta perfecta para definir la trazabilidad entre dos conjuntos de artefactos.

Página 14 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Mediante el panel Resources (Figura 4) se accede al listado de matrices de trazabilidad definidas en NDTProfile. Si no se visualiza el panel, éste se muestra pulsando sobre el menú View > Resources, o bien pulsando Alt+6.

Figura 4. Listado de matrices de trazabilidad

Las matrices están ordenadas por la fase en la que se deben cumplimentar y para acceder a ellas basta con hacer doble clic encima.

Tabla 3. Reglas matrices trazabilidad

Buenas prácticas Las matrices de trazabilidad definidas en el proyecto no pueden modificarse y deben ser cumplimentadas aquellas que pertenezcan a la fase en la que se encuentre el proyecto

Página 15 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Al igual que en el caso de la estructura de carpetas, las matrices de trazabilidad definidas en el proyecto no pueden modificarse en cuanto a su estructura, y todas deben ser cumplimentadas. En la sección 5.2 se amplía la información sobre cómo utilizar las matrices de trazabilidad incluidas en NDT-Profile. 3.3. Baselines En cualquier momento, durante el proyecto, se requiere comparar los cambios de las distintas versiones que van surgiendo en el NDT-Profile. Para solucionar el problema se usa la referencia de estado o baseline tal como lo llama en Enterprise Architect. Las baselines son imágenes de un momento dado en el proceso. Se pueden crear tantas baselines como se necesite (véase la Figura 5). Se usa en versiones diferentes de cada profile o cada fase de NDT. Es decir, se puede crear baselines de forma general (Profile) o de forma local (EVS, DRS, DAS, DDS, DPS). Veamos un ejemplo de crear una baseline para el proyecto al completo, una vez creados artefactos. Se selecciona el profile o la fase en el Project Browser, y con el botón derecho del ratón se selecciona Package Control > Manager Baselines.

Figura 5. Accediendo a la gestión de baselines

Cuando se precise, se añade una nueva versión de baseline pulsando en el botón New Baseline.

Página 16 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 6. Versionado de baselines

Se añade una versión y la descripción “Note” es opcional y siempre bajo la norma NDT. Una vez ya creado el baseline se puede continuar trabajando. En cualquier momento se puede ver el estado anterior a los cambios. Para ver la comparación y los cambios existentes respeto al estado anterior se va a la misma ventana anterior, como se muestra en la Figura 7:

Figura 7. Comparar el estado actual con el anterior

Se selecciona la baseline deseada y el botón Show Differences. A partir de ahora se visualiza un árbol de todo el profile o la fase a la que se ha sometido a una baseline tal como indica en la Figura 8:

Página 17 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 8. Completa visualización del estado de cada uno de los artefactos

Y dependiendo de los cambios que se ha hecho, se visualizan unos triángulos sobre los iconos de los artefactos con diferentes colores, así el verde indica que el objeto es nuevo respecto a la baseline o versión anterior, el rojo indica un objeto que ha sido borrado, el azul es un objeto modificado y finalmente el amarillo indica un objeto movido de carpetas. También se puede visualizar el estado de las propiedades y atributos de cada artefacto. En la parte derecha de la ventana de comparación, las propiedades de los elementos que han sido modificadas aparecen sombreadas en azul claro. Encima de la ventana de comparación hay una serie de botones con diferentes utilidades. La barra de botones se muestra en la Figura 9:

Figura 9. Botones de comparación de baselines

Por ejemplo, el segundo botón, teniendo seleccionado un elemento, hará que éste revierta su estado actual a como estaba según el baseline usado en la comparación. El décimo botón muestra una serie de opciones para configurar los elementos que se muestran en la ventana de comparación para así restringir qué tipos de elementos se visualizarán. Se puede crear tantas baselines como se estime oportuno necesario, y siempre acorde a las versiones de los entregables que se realicen. Nota: Las baselines ocupan espacio dentro del archivo .eap, puesto que se almacenan dentro. Para evitar que el eap aumente excesivamente de tamaño y se corrompa se recomienda que se exporten a xml y se eliminen del eap. Para exportarlo hay que seleccionar el baseline correspondiente, pulsar en el botón Export File y seleccionar la ubicación donde se guardará. Cuando se necesite consultar el baseline, basta con importar el archivo xml con el que se quiera comparar el modelo actual. Para ello hay que

Página 18 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario pulsar en el botón Import File y seleccionar el archivo xml de nuestro disco duro. La ubicación de estos botones se muestra en la Figura 10.

Figura 10. Importar y exportar baselines

Tabla 4. Reglas de los baselines

Buenas prácticas Con cada entregable se deberá entregar un baseline en xml que englobe a todo el profile indicando la versión y la fecha.

Página 19 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 4. Modelado UML con Enterprise Architect. Reglas generales A continuación se proponen las reglas generales de los diferentes elementos de UML que nos encontraremos en NDT-Profile. 4.1. Diagramas No hay límites en el número de diagramas ni de nuevos paquetes que se pueden crear dentro de un paquete. Para crear diagramas en cualquiera de los apartados del proyecto se actúa de la siguiente manera: se selecciona el paquete dónde se desea crear el diagrama. Después, se selecciona el icono (Figura 2) de la caja de herramientas del proyecto y se selecciona el tipo de diagramas correspondiente a la fase en la que se encuentre. También se puede añadir seleccionando la carpeta en la que se quiere añadir el diagrama y pulsando sobre el botón derecho, colocarse sobre Add y seleccionar Add diagram… El resultado se muestra en la Figura 11. Existen varios grupos de diagramas definidos, uno por cada fase de NDT-Profile. Dentro de cada uno de ellos existen un conjunto de diagramas, tal y como se muestra en la Figura 11. Además, existen otros grupos de diagramas predefinidos por la herramienta, entre los que se encuentran los diagramas UML.

Figura 11. Eligiendo el tipo de diagrama

Las correspondencias entre los apartados del proyecto y los distintos tipos de diagrama de la herramienta Enterprise Architect se muestran en la Tabla 5. Los apartados que no están incluidos en la tabla no tienen ningún tipo de diagrama asociado, por lo que puede usarse un tipo de diagrama a libre elección o bien usar un documento de texto anexo.

Página 20 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Tabla 5. Tipos de diagramas para los apartados del proyecto

Apartado PARTICIPANTES CONTROL DE VERSIONES EVS - Requisitos de Almacenamiento EVS - Actores EVS - Requisitos Funcionales EVS - Requisitos de Interacción EVS - Requisitos No Funcionales DRS - Objetivos DRS - Modelos de Procesos DRS - Identificación de Servicios DRS - Requisitos de Almacenamiento DRS - Actores DRS - Requisitos Funcionales DRS - Requisitos de Interacción DRS - Requisitos No Funcionales DAS - Definición de Servicios DAS - Clases de Contenido DAS - Clases de Procesos DAS - Actores de Estudio DAS - Clases de Navegación DDS - Diseño de Servicios DDS - Diseño de Servicios (1) DDS - Diseño de Servicios (2) DDS - Diseño de Servicios (3) DDS - Entorno Tecnológico DDS - Clases de Diseño DDS - Modelo Físico de Datos DPS - Pruebas de Implantación DPS - Pruebas de Sistema DPS - Pruebas de Aceptación DMS - Incidencias Software DMS - Peticiones de Mejora

Tipo de diagrama Diagramas Control - NDT Participantes Diagramas Control - NDT Control de Versiones Diagramas EVS - Requisitos de Almacenamiento Diagramas EVS - Actores del Sistema Diagramas EVS - Requisitos Funcionales Diagramas EVS - Requisitos Interacción Diagramas EVS - Requisitos No Funcionales Diagramas DRS - Objetivos Diagramas DRS - Procesos Diagramas DRS - Servicios Diagramas DRS - Requisitos de Almacenamiento Diagramas DRS - Actores Diagramas DRS - Requisitos Funcionales Diagramas DRS - Requisitos Interacción Diagramas DRS - Requisitos No Funcionales Diagramas DAS - Servicios Diagramas DAS - Clases de Contenido Diagramas DAS - Clases de Procesos Diagramas DAS - Diagrama de Secuencia Diagramas DAS - Actores de Estudio Diagramas DAS - Modelo Navegacional Diagramas DDS - WSDL SOAML - SoaML Component Diagram SOAML - SoaML Sequence Diagram Diagramas DDS - Entorno Tecnológico Diagramas DDS - Clases de Diseño Diagramas DDS - Modelado de Datos Diagramas DPS - Pruebas de Implantación Diagramas DPS - Pruebas de Sistema Diagramas DPS - Pruebas de Aceptación Diagramas DMS - Mantenimiento Diagramas DMS - Mantenimiento

(1) Cada servicio ha de tener asociado un diagrama WSDL (2) Cada servicio ha de tener asociado un diagrama SoaML Component (3) Cada servicio puede tener asociado un diagrama SoaML Sequence Estos diagramas se encuentran ya creados en su carpeta correspondiente, por lo que basta con ir añadiendo artefactos al diagrama. Al abrir el diagrama, se cargará el conjunto de herramientas correspondiente a la fase en la que se esté trabajando, facilitando la tarea de añadir los artefactos, ya que estarán disponibles solo aquellos que se pueden añadir al diagrama, así como sus posibles conexiones. Por ejemplo, si se desea cumplimentar el apartado de los requisitos de almacenamiento se debe abrir el diagrama en la sección 3.1.1 de la carpeta DRS. Una vez abierto, para añadir un nuevo requisito de almacenamiento se selecciona en el toolbox el artefacto RA y se arrastra hasta el panel central. Cuando se añade un elemento, este se incorpora a la carpeta en la que se encuentra el diagrama, en el ejemplo anterior (figura 11) en la carpeta 3.1.1. Este artefacto debe moverse posteriormente a la carpeta 3.1.2, que es donde se encuentran los Requisitos de Almacenamiento definidos.

Página 21 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

4.1.1. Diagramas de casos de uso

A la hora de describir tanto la funcionalidad del sistema, como el conjunto de pruebas, se utilizan diagramas de casos de uso. Estos diagramas han de cumplir una serie de reglas básicas de modelado para que puedan considerar válidos, algo que no siempre se observa cuando se realiza este tipo de diagrama. En la Figura 12 podemos ver un ejemplo de diagrama bien construido.

Figura 12. Ejemplo de diagrama de caso de uso bien construido

En primer lugar, en un diagrama de casos de uso ha de aparecer, como mínimo, un actor, puesto que ha de especificarse quién puede ejecutar la funcionalidad. Además, todos los casos de uso han de tener un enlace al actor, o bien, tener una relación include o extend (ambas son definidas por UML) con un caso de uso enlazado a un actor. El enlace con el actor ha de ser del tipo use y sus propiedades pueden ser editadas tal y como se explica más adelante en el apartado 4.3. También es un requisito fundamental que en el diagrama (o entre todos los diagramas) han de aparecer todos los casos de uso que se hayan definido. 4.1.2. Diagramas de actividades

Es posible utilizar diagramas de actividades tanto en la definición del comportamiento de requisitos funcionales como en el comportamiento de casos de prueba. Para ayudar a construir unos diagramas de actividades semánticamente correctos, a continuación se definen una serie de prácticas de obligado cumplimiento a la hora de elaborar este tipo de diagramas.

Página 22 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Tabla 6. Reglas para Diagrama de Actividades

Buenas prácticas para diagramas de actividades Todo diagrama de actividades debe tener un único punto de inicio. Además, debe existir un y solo un flujo entre el diagrama de inicio y la primera actividad. Todo diagrama de actividades debe tener, al menos, un nodo final. Dicho nodo no debe tener ningún flujo de salida. Toda actividad tendrá un y solo un flujo de salida. Dicho flujo no podrá tener ninguna guarda. Todos los flujos de salida de una decisión deberán tener una guarda distinta. Es decir, una decisión no podrá tener más de un flujo de salida con la misma guarda. Todas las actividades de un diagrama de actividades deben definirse en el propio diagrama de actividades. No puede existir más de un diagrama de actividades con el mismo nombre. Todas las actividades y decisiones que participan en el diagrama de actividades deben mostrarse en el diagrama de actividades. Además, todas las asociaciones que involucren a miembros del diagrama de actividades deben mostrarse en el diagrama de actividades. No puede existir más de un flujo entre los dos mismos elementos de un diagrama de actividades No puede existir más de una actividad con el mismo nombre en el mismo diagrama de actividades. 4.2. Artefactos Haciendo doble clic sobre cualquier artefacto aparecen sus propiedades estándares, tal y como se muestra en la Figura 13. Las propiedades estándares son aquellas propiedades ya definidas por Enterprise Architect para cada artefacto. Cuando se añade un nuevo artefacto, se deben rellenar las propiedades definidas como obligatorias en este manual. También es muy recomendable rellenar las propiedades no obligatorias. En la Figura 13, se muestra todas las posibles propiedades estándares, que están disponibles para todos los artefactos que hereden de Clase (OBJ, Servicio, RA, NA, CL, CLn, NO, QU, IN, ME, PR, NE, AD, PM e IS). Los artefactos que hereden de otro tipo de elemento (por ejemplo, AC o RF) no tendrán alguna de las pestañas, pero las que tengan, coincidirán con las que se definen a continuación.

Página 23 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 13. Ventana de propiedades (pestaña General)

El campo Name ha de contener el nombre del elemento a crear, según la nomenclatura específica, que se irá detallando en las tablas de nomenclatura de las distintas fases. El campo Stereotype se rellenará automáticamente con el estereotipo del elemento que hemos creado. El campo Author deberá contener el nombre de la empresa o persona que haya modelado el elemento. En el campo Notes se debe desarrollar una descripción del elemento. En el campo Language se ha de indicar el lenguaje del artefacto, siendo en EVS y DRS el lenguaje NDT-Requisitos, en DAS y DDS el lenguaje de programación seleccionado (actualmente, NDT-Driver trabaja únicamente con C# y Java) y para el modelo de datos la base de datos que se esté usando (Oracle, MySQL y SQLServer). Estos campos de propiedades son (a menos que se indique expresamente lo contrario) un subconjunto de los campos obligatorios a cumplimentar en el modelado de elementos.

Página 24 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario El campo Alias se utiliza para referenciar a otro artefacto a partir del cual se ha construido el elemento que se quiere modelar (generalmente se usará en las transformaciones automáticas realizadas por NDTDriver). Este campo es obligatorio en algunos tipos de artefactos (NO, QU, IN, ME, PR, NE y AD). El campo Status se puede utilizar para indicar el estado del elemento. El campo Version se puede utilizar para indicar la versión del elemento. Estos campos son opcionales, a menos que se indique expresamente lo contrario, en el modelado de elementos con NDT. El resto de campos no tienen ningún uso en NDT, si bien, no se restringe su uso.

Figura 14. Eligiendo detalles (pestaña Details)

A través de la pestaña Details (Figura 14) se puede acceder a los atributos y a las operaciones de los artefactos a través de los botones Attributes y Operations, respectivamente. Los atributos son obligatorios en diferentes artefactos (RA, NA, Servicios, CL, CLn, NO, QU, PR y AD) y las operaciones son obligatorias en los NO y NE. Además, mediante el botón Collection Classes se especifica si el artefacto

Página 25 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario es una colección. El resto de campos y funcionalidades en la pestaña Details no tienen ningún uso específico en NDT, por lo que no resulta relevante en esta guía. En la Figura 15 se puede observar la pantalla a través de la cual se pueden insertar atributos a un artefacto, en concreto la pestaña General.

Figura 15. Pantalla de atributos

Cuando se defina un atributo, éste ha de tener, obligatoriamente, un nombre, un tipo, una descripción y una cardinalidad. La cardinalidad se completa en la pestaña Detail, tal y como se observa en la Figura 16.

Página 26 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 16. Pantalla de introducción de la cardinalidad

La cardinalidad ha de introducirse en los campos Lower bound y Upper bound. Por ejemplo, si la cardinalidad fuera 0..*, habría que introducir un 0 en Lower bound y un * en Upper bound. Si estos campos no se rellenan, la cardinalidad que se muestra es 1..1. En la Figura 17 se puede observar la pantalla a través de la cual se pueden añadir operaciones a un artefacto, en concreto la pestaña General.

Página 27 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 17. Pantalla de operaciones

Los campos obligatorios en las operaciones son el nombre, la descripción y el alias. En el campo alias ha de ir el nombre del artefacto RF al que hace referencia la operación. El resto de campos y pestañas no tienen un uso definido en NDT, si bien, pueden utilizarse para aumentar la descripción de las operaciones. La pestaña Require no tiene ninguna funcionalidad en NDT, por lo que no se definirá en esta guía. La siguiente pestaña es Constraints, donde se pueden definir las diferentes condiciones que se aplican a los artefactos que definamos. En la Figura 18 podemos ver el contenido de la pestaña.

Página 28 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 18. Pantalla de condiciones de un artefacto

Un condición ha de tener definido el nombre (cuadro de texto Constraint), el tipo y la descripción. El tipo ha de ser Invariant (Invariante) para los RA y NA, o Pre-Condition (Pre-Condición) o Post-Condition (PostCondición) para los RF y PS. En la pestaña Links se visualizan los enlaces del artefacto con otros. Esta pestaña permite ordenar los artefactos enlazados por nombre, estereotipo o conexión, entre otros, tal y como se observa en la Figura 19.

Página 29 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 19. Visualizando los links de un artefacto

La pestaña Scenarios se utiliza para describir el comportamiento de un RF mediante escenarios. Como se explica más adelante, en concreto en el apartado concerniente a los Requisitos Funcionales, un RF se puede definir mediante diagramas de actividades o mediante escenarios. En el caso de elegir esta segunda opción, a través de esta pestaña, que se observa en la Figura 20, podemos describir los escenarios.

Página 30 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 20. Definiendo los escenarios de un artefacto

Los escenarios han de tener un nombre, un tipo (ha de ser "Basic Path", Alternate o Exception, no se pueden añadir más tipos en NDT) y una descripción detallando los pasos de ese escenario. Siempre debe existir un escenario de tipo "Basic Path". La secuencia del escenario normal ha de ser mediante números consecutivos (1, 2, 3,…), sin embargo, la secuencia de los escenarios de excepción deben tener un número compuesto (2.1, 3.1, 3.2,…). En definitiva, los escenarios deben ser una secuencia ordenada de pasos numerados y no deben aparecer saltos en ella. Si lo desea, puede utilizar la especificación estructurada que proporciona Enterprise Architect 8.

Página 31 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario La siguiente pestaña (Files) hace referencia a los archivos que se vinculan a un artefacto, ya sea un documento, una imagen o cualquier otro tipo de fichero. La interfaz que ofrece esta pestaña es la que se observa en la Figura 21.

Figura 21. Pestaña de vinculación de archivos

Estos archivos son externos y, al contrario que los documentos que se anexan a un documento, no ocupan espacio en el proyecto EAP. Eso sí, si se opta por vincular un archivo en local, en el caso de que el proyecto EAP se desee mandar a una persona que lo tenga que abrir desde otra red, se tendrá que enviar el EAP junto con los documentos que se hayan vinculado. Además, se aconseja que junto con el EAP, se creen una serie de carpetas para albergar los documentos que se requieren en las diferentes fases que define NDT, introduciendo en el campo File Path la ruta relativa al archivo, y no la ruta completa tal y como la muestra inicialmente Enterprise Architect. La estructura de carpetas que proponemos es la siguiente: junto con el EAP, se crea una carpeta docs, y dentro de ella colgarían las

Página 32 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario carpetas control, evs, drs, das, dds, dps y dms. Cada carpeta correspondería a cada una de las fases que se definen en NDT-Profile. La siguiente pestaña es la pestaña Tagged Values. Esta pestaña se muestra tal y como observamos en la Figura 22.

Figura 22. Pestaña de visualización de los valores etiquetados

La funcionalidad de esta pestaña es la de mostrar los valores etiquetados que se definan para cada artefacto. Muestra la misma información que la pestaña Tagged Values que se describió en el apartado 3.1, es decir, a la izquierda aparece el nombre, y a la derecha el valor que toma.

Página 33 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 4.3. Conectores En NDT es posible relacionar artefactos mediante los conectores. Los conectores son enlaces entre dos artefactos con una serie de propiedades que describirán en este apartado. Podemos ver un ejemplo de dos artefactos (en este caso, un actor y un requisito funcional) enlazados con un conector de tipo Use en la Figura 23.

Figura 23. Propiedades generales de un conductor

En la pestaña General se observan las propiedades básicas del conector. En el título de la ventana aparece el nombre del tipo de conector que se ha usado, en este caso UseCase. Este tipo de conector es genérico de UML, si bien, hay otros muchos conectores que son extensiones de UML definidas expresamente en NDT-Profile. Estos conectores se detallarán dentro de los artefactos que hacen uso de ellos, en los apartados de la fase del ciclo de vida que le corresponda, si bien, las propiedades de los conectores son comunes para todos.

Página 34 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario En el campo Source aparece el artefacto de origen del conector, y en el campo Target aparece el artefacto de destino del conector. Estos campos no son editables ya que es una propiedad intrínseca del conector. En el campo Name podemos dar un nombre al conector, que aparecerá junto a la línea dibujada en el diagrama. En el campo Direction podemos seleccionar la dirección que toma el conector (Source>Destination, Destination->Source, Bi-Directional y Unespecified), apareciendo una flecha que indica la dirección en aquellos algunos tipos de conectores. En el campo Stereotype podemos dar un estereotipo al enlace. En el caso de los enlaces definidos expresamente para NDT-Profile, este campo mostrará el estereotipo que extiende al enlace, no siendo aconsejable su modificación. Además, en el campo Notes podemos añadir una descripción al enlace, si bien no es algo obligatorio en NDT-Profile. En la siguiente pestaña, Constraints, tal y como se observa en la Figura 24, podemos definir condiciones para el enlace.

Figura 24. Pestaña para definir condiciones en un conector

Esta pestaña es exactamente igual a la pestaña Constraints de los artefactos, ya descrita en el apartado anterior.

Página 35 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Las dos pestañas siguientes, Source Role y Target Role, hacen referencia al rol de origen y de destino del enlace. Ambas pestañas son iguales y se observan en la Figura 25.

Figura 25. Pestaña source y target role de un conector

Esta pestaña tiene especial relevancia, dentro de NDT-Profile, en la transformación de requisitos de almacenamiento de información (RA y NA) a artefactos del modelo de contenido de la fase de análisis (CL y CLn). Si se usa NDT-Driver para hacer la transformación automática, y centrándonos en la transformación RA a CL, existirá un enlace entre dos CL si alguno de los RA de los que procede tenía un dato específico de tipo el otro RA. Entonces, el enlace tendrá como rol el nombre del dato específico y como cardinalidad (Multiplicity), la cardinalidad del dato específico. Si esto se hiciera manualmente, habría que seleccionar el rol con el primer combobox que aparece, en el que mostrarían los atributos del elemento de origen, en el caso de estar en la pestaña Source Role, o el de destino, en caso de estar en la pestaña Target Role. La cardinalidad del enlace se selecciona con el combobox Multiplicity.

Página 36 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario El resto de campos, y la pestaña Tagged Values, no tienen funcionalidad específica en NDT-Profile, si bien, no se restringe su uso y se permite a fin de enriquecer la descripción de los conectores.

Página 37 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 5. Buenas prácticas comunes a todos los elementos 5.1. Subsistemas En algunos sistemas extensos puede resultar más cómodo separar cada conjunto de artefactos en diferentes carpetas o subsistemas. Para ello, en cada toolbox existe un artefacto Subsistema que crea una nueva carpeta y dentro de esta, el diagrama correspondiente al tipo de artefacto que lo ha creado. Así, conseguimos clasificar cada tipo de artefacto en diferentes carpetas. Estos artefactos, a pesar de estar en carpetas diferentes, se pueden arrastrar a cualquier diagrama, además de poder seguir la trazabilidad mediante matrices o diagramas de una forma más organizada. 5.2. Matrices de trazabilidad Una matriz de trazabilidad es una pantalla de Enterprise Architect (Figura 26) dónde las filas representan los elementos de un modelo definido por el usuario y las columnas representan otros elementos de otro modelo (o incluso del mismo modelo) también definido por el usuario. Seleccionando una casilla (intersección de una fila con una columna, es decir, intersección de dos elementos) Enterprise Architect automáticamente añade una relación (en este caso una relación de trazabilidad) entre ambos elementos.

Figura 26. Ejemplo de matriz de trazabilidad

Todos los artefactos deben tener definidos relaciones de trazabilidad. De esta manera, en cualquier momento es posible conocer qué objetivos satisfacen los requisitos, qué requisitos implementan las clases, que clases persisten en las tablas de bases de datos, etc. El origen de la relación de trazabilidad debe ser el elemento que implementa y el destino del elemento implementado. Por ejemplo, entre un requisito funcional de la fase de requisitos y una clase de análisis existirá una relación de trazabilidad con origen la clase y destino el requisito funcional si dicha clase participa en la implementación del comportamiento definido en el requisito funcional. Las matrices de trazabilidad incluidas en NDT-Profile se describen en la Tabla 7:

Página 38 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Tabla 7. Matrices de Trazabilidad

Fases DRS

Matriz OBJ x RA

DRS DRS

OBJ x NA OBJ x AC

DRS

OBJ x RF

DRS DRS DRS

OBJ x FR OBJ x LI OBJ x PV

DRS

OBJ x RNF

DRS DRS DRS DRS-DAS DRS-DAS

BPMN x Servicios BPMN x RF BPMN x Servicios Servicios (DRS) x Servicios (DAS) RA x CL

DRS-DAS

NA x CLn

DRS-DAS DRS-DAS DRS-DAS DRS-DAS DAS-DDS DAS-DDS

RF x CP FR x QU LI x IN PV x NO Servicios (DAS) x Servicios (DDS) CL x AD

DAS-DDS

CLn x AD

DAS-DDS DAS-DDS DAS-DDS DAS-DDS DAS-DDS

CP x NE QU x PR IN x PR NO x PR CL x Table

DRS-DPS DRS-DPS

RF x PS RF x PA

Descripción Trazabilidad entre los objetivos del sistema y los requisitos de almacenamiento relacionados Trazabilidad entre los objetivos del sistema y las nuevas naturalezas Trazabilidad entre los objetivos del sistema y los actores de la ingeniería de requisitos Trazabilidad entre los objetivos del sistema y los requisitos funcionales Trazabilidad entre los objetivos del sistema y las frases Trazabilidad entre los objetivos del sistema y los listados Trazabilidad entre los objetivos del sistema y los prototipos de visualización Trazabilidad entre los objetivos del sistema y los requisitos no funcionales Relaciones entre el modelo de negocio y los servicios identificados Relaciones entre modelo de negocio y requisitos funciones Relaciones entre el modelo de negocio y los servicios identificados Trazabilidad entre los servicios de requisitos y los servicios de análisis Trazabilidad entre los requisitos de almacenamiento y las clases de persistencia Trazabilidad entre las nuevas naturalezas y las clases de persistencia Trazabilidad entre los requisitos funcionales y las clases de procesos Trazabilidad entre las frases y las queries Trazabilidad entre los listados y los índices Trazabilidad entre los prototipos de visualización y los nodos Trazabilidad entre los servicios de análisis y los servicios de diseño Trazabilidad entre las clases de contenido y las clases de acceso a datos Trazabilidad entre las clases naturaleza de contenido y las clases de acceso a datos Trazabilidad entre clases de procesos y clases de negocio Trazabilidad entre las queries y las clases de presentación Trazabilidad entre los índices y las clases de presentación Trazabilidad entre los nodos y las clases de presentación Trazabilidad entre las clases de contenido y las tablas del modelo físico de datos Trazabilidad entre los requisitos funcionales y las pruebas de sistema Trazabilidad entre los requisitos funcionales y las pruebas de aceptación

5.3. Buenas prácticas para los artefactos Estas reglas se aplican a todos los artefactos a cumplimentar en todos los documentos de las fases EVS, DRS, DAS, DDS, DPS y DMS. Todos los artefactos (requisitos, casos de uso, clases, casos de prueba, paquetes, etc.) deben tener un nombre y una descripción que aporte valor. Además, como se verá más adelante, todos los elementos

Página 39 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario tienen un código numérico. Dicho código no puede coincidir la numeración de dos artefactos del mismo tipo. Todo elemento debe tener una descripción, incluyendo los datos específicos, escenarios, etc. 5.4. Linkado de documentos Junto con la entrega del fichero EAP con el Profile se deben adjuntar una carpeta, llamada docs, que contiene todos los documentos que se adjuntan en los diferentes artefactos de tipo Document que aparecen en diversas carpetas de cada fase. Así, dentro de la carpeta docs tendrá, a su vez las siguientes carpetas: control, evs, drs, das, dds, dps y dms.

Figura 27. Linkado de documentos

Para linkar un documento hay que hacer doble clic sobre el artefacto Document, ir a la pestaña Files y en el campo File Path seleccionar el archivo que se quiera adjuntar. Posteriormente hay que dejar únicamente la ruta relativa (por ejemplo, docs\drs\Documento.doc), ya que de esta manera se puede abrir el documento desde Enterprise Architect. Esto se puede ver en la Figura 27. Si el documento no fuera muy extenso, se puede introducir en el campo Notes del artefacto correspondiente, ya que a partir de la versión 7.5 de Enterprise Architect tiene un editor WYSIWYG que permite dar varias opciones de formato al texto.

Página 40 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Tabla 8. Reglas de Documentos

Documentos Un artefacto de tipo Document ha de tener un documento linkado, o si no es demasiado extenso, el contenido se introducirá en el campo Notes. El campo File Path ha de contener una ruta relativa, para que se pueda abrir el documento directamente desde el Enterprise Architect.

Página 41 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 6. Participantes En esta sección se deberá incluir todas las instancias de los participantes indicando sus datos, roles, etc.… Para ello, se utilizarán los artefactos del toolbox Participantes, seleccionando el artefacto correspondiente según la categoría del participante. En la Figura 28 se muestra el toolbox Participantes.

Figura 28. Toolbox Participantes

En la siguiente tabla se enumeran los artefactos que aparecen en Participantes, así como la estructura del nombre. Tabla 9. Nomenclatura de Participantes

Requisito Cliente Proveedor Comité Equipo de Proyecto Equipo de Desarrollo

Nombre Nombre Nombre Nombre EP-XX.Nombre ED-XX.Nombre

El artefacto Cliente representa al Cliente del producto final, por lo que llevará el nombre del organismo o empresa al que representa. El artefacto Proveedor representa a la empresa que desarrolla el sistema. El artefacto Comité representa a cada una de las personas perteneciente a los diferentes comités que tuviera el proyecto (por ejemplo, de seguimiento, de trabajo, etc.). Puede estar asociado al cliente.

Página 42 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario El artefacto Equipo de Proyecto representa a las personas participantes en el proyecto. Lo normal es que exista una por rol definido en el valor etiquetado. Puede estar enlazado a Proveedor o Cliente. El artefacto Equipo de Desarrollo representa a los encargados del desarrollo del sistema. Deberá estar enlazado a Proveedor o Cliente. Todos los artefactos tienen las mismas propiedades estándares (nombre, autor y descripción). A continuación, mostramos uno de ellos:

Figura 29. Propiedades estándares de Participantes

Página 43 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario No existen valores etiquetados para los participantes Cliente, Proveedor y Comité, pero sí hay un valor etiquetado Tipo Participante en los participantes Equipo de Proyecto y Equipo de Desarrollo. Para estos, el valor etiquetado se debe cumplimentar obligatoriamente.

Figura 30. Valores etiquetados de Participantes

Tabla 10. Reglas de Participantes

Diagramas de Participantes Debe contener a todos los participantes según el esquema de la organización Los únicos enlaces que deben aparecer son los del toolbox El nombre del artefacto Equipo de Proyecto es EP-XX(X).Nombre El nombre del artefacto Equipo de Desarrollo es ED-XX(X).Nombre En Equipo de Proyecto y Equipo de Desarrollo debe seleccionarse el tipo en los valores etiquetados

Página 44 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 7. Control de versiones La hoja de control de modificaciones ofrecerá una descripción de cada una de las versiones que se vayan entregando del proyecto. No será necesario entrar en un detalle profuso porque éste se gestionará mediante baselines, como se explica en el apartado 3.3, pero sí deberá justificar los cambios realizados a nivel genérico. Para este apartado se ofrece solo un artefacto, el artefacto Control de Versiones. A continuación se muestran las propiedades estándares de Control de Versiones.

Figura 31. Propiedades estándares de Control de Versiones

Página 45 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Las propiedades estándares son el nombre (que deberá ser la fecha), la versión, la descripción y el archivo del baseline (que se asociará como si de un documento se tratara, tal y como se explica en el apartado 5.4). Tabla 11. Reglas de Control de Versiones

Diagramas de Control de Versiones Debe haber tantos artefactos de control de versiones como versiones hay del documento. Debe haber tantos baselines (xml) como versiones hay del documento. Cada artefacto de control de versiones debe tener linkado un baseline. Este documento ha de estar en la carpeta docs\baseline\. En la pestaña Files, en el campo File Path ha de tener la ruta relativa.

Página 46 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 8. Objetivos del proyecto Este apartado, incluirá, bien un documento vinculado o bien una descripción genérica del proyecto en el campo Notes, si ésta no es muy extensa En cualquier caso, la información proporcionada no debe ser demasiada detallada y debe ofrecer una visión general de los objetivos a alcanzar con el proyecto. Tabla 12. Reglas de Objetivos

Documento de Objetivos Debe tener linkado un documento. Este documento ha de estar en la carpeta docs\objetivos\. En la pestaña Files, en el campo File Path ha de tener la ruta relativa. Si el documento es corto, se podría rellenar en el campo Notes y no haría falta el linkado del documento.

Página 47 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 9. Estudio de Viabilidad del Sistema (EVS) La estructura de la documentación del estudio de viabilidad se muestra en la Figura 32.

Figura 32. Estructura del EVS

Además, se ha definido en el perfil de NDT un conjunto de herramientas para el estudio de viabilidad. Para la definición de los artefactos deben utilizarse los artefactos del grupo de herramientas existente, que se cargará al abrir el diagrama que se quiera describir. En la siguiente tabla se enumeran los artefactos que aparecen en la fase de Estudio de viabilidad, así como la estructura del nombre.

Página 48 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Tabla 13. Nomenclatura de Estudio de Viabilidad

Requisito Requisito de almacenamiento Nueva naturaleza Actor Requisito funcional Frase Prototipo de visualización Listado Requisito no funcional

Nombre RA-XX.Nombre NA-XX.Nombre AC-XX.Nombre RF-XX.Nombre FR-XX.Nombre PV-XX.Nombre LI-XX.Nombre RNF-XX.Nombre

En esta sección, además de definir los artefactos que correspondan, se deberán crear una serie de documentos, tales como Alcance del Sistema, Situación Actual, Estudio de Alternativas y Descripción de la Solución Propuesta. Estos documentos se deben adjuntar al archivo EAP tal y como se ha descrito en la sección 5.4. Los artefactos del Estudio de Viabilidad son exactamente los mismos que se definen en el siguiente apartado (Requisitos), si bien, en la fase de Estudio de Viabilidad no se describen con tanta profundidad. Si en un proyecto no se realiza el Estudio de Viabilidad, esta carpeta ha de eliminarse.

Página 49 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 10. Ingeniería de Requisitos A continuación se describen los distintos artefactos definidos por NDT para los Requisitos, la manera de introducir dicha información en la herramienta Enterprise Architect y las reglas que hay que seguir. Como se ha comentado con anterioridad, cada artefacto lleva un código identificativo. Los códigos de cada artefacto se muestran en la Tabla 14. Tabla 14. Nomenclatura de Requisitos

Requisito Objetivo Servicio Requisito de almacenamiento Nueva naturaleza Actor Requisito funcional Frase Prototipo de visualización Listado Requisito no funcional

Nombre OBJ-XX.Nombre Servicio-XX.Nombre RA-XX.Nombre NA-XX.Nombre AC-XX.Nombre RF-XX.Nombre FR-XX.Nombre PV-XX.Nombre LI-XX.Nombre RNF-XX.Nombre

Página 50 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario La estructura del documento de requisitos del sistema y su relación con la estructura de paquetes del perfil de NDT se muestra en la Figura 33.

Figura 33. Estructura del DRS

Página 51 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Las herramientas correspondientes para la definición de los artefactos de requisitos se muestran en la Figura 34.

Figura 34. Toolboxes para requisitos

10.1. Objetivos del sistema Los objetivos describen las necesidades a satisfacer por el sistema. Estos objetivos se detectan en las entrevistas con el cliente y usuarios, y deben definirse mediante el artefacto OBJ que ofrece NDT-Profile. En la Figura 35 se muestra el toolbox definido para los objetivos.

Figura 35. Toolbox para objetivos

Para crear un objetivo, basta con pinchar sobre el toolbox en el artefacto OBJ y arrastrar hasta el diagrama donde se quiera modelar. En la Figura 36 se observa un objetivo, sus propiedades estándares y sus valores etiquetados.

Página 52 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 36. Propiedades estándares de un objetivo

En el artefacto OBJ existen una serie de campos que son obligatorios para que la descripción del objetivo se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada objetivo debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 14, el nombre debe cumplir el formato siguiente OBJ-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de objetivos. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el objetivo. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el objetivo que se está tratando. - Estabilidad (valor etiquetado): Este valor etiquetado recoge la probabilidad de que el objetivo sufra cambios en su definición. Debe escogerse uno de los valores predefinidos.

Página 53 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Importancia (valor etiquetado): Este valor indica la importancia que tiene el hecho de que el sistema cumpla con el objetivo para el cliente. Debe escogerse uno de los valores predefinidos. Urgencia (valor etiquetado): Este valor indica la urgencia del cumplimento del objetivo. Debe escogerse uno de los valores predefinidos.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los objetivos. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el objetivo en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del objetivo. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Atributos (dentro de pestaña Details, botón Attributes): Opcionalmente se pueden añadir atributos al objetivo si se estima oportuno. La forma de añadir atributos se explica dentro del apartado 4.2 (Figura 15). - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. Los objetivos se pueden enlazar entre sí mediante el conector es SubObjetivo de, que aparece en el toolbox, visto en la Figura 35. Este conector denota una relación de agregación entre objetivos. Para hacer uso de este conector, basta con pinchar en el toolbox para seleccionar, pinchar en el objetivo de origen y arrastrar hacia el objetivo de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. A continuación, en la Tabla 15, hacemos un pequeño resumen de aquellas reglas que debe cumplir la definición de un objetivo en NDT-Profile. Tabla 15. Reglas de Objetivos (OBJ)

Diagramas de Objetivos Tiene un diagrama de tipo Objetivos Todos los OBJ han de estar contenidos en el diagrama Los únicos enlaces que deben aparecer son los del toolbox Definición de Objetivos El nombre del artefacto es OBJ-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro OBJ con la misma numeración Los tagged values Estabilidad, Importancia y Urgencia son obligatorios El único enlace entre OBJ es el del toolbox "es SubObjetivo de" 10.2. Modelo de negocio Cuando el proceso de desarrollo esté orientado a Servicios y ambientes SOA, o bien, cuando no se haya definido un estudio de viabilidad y se desee tener una visión global de los modelos de negocio del sistema, se debe detallar este apartado de NDT-Profile.

Página 54 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 10.2.1.Modelos de procesos

En la primera de las carpetas de las que consta el modelo de negocio (Modelos de procesos) se documentarán todos los modelos de procesos de negocio del sistema utilizando BPMN. En la carpeta correspondiente encontraremos un diagrama de Procesos. Si queremos añadir más diagramas, no hay más que crearlo, seleccionando el tipo de diagrama que se indica en la Figura 37.

Figura 37. Crear un nuevo Diagrama de Procesos para definir el modelo de negocio

10.2.2.Identificación de servicios

Dentro del modelo de negocio también encontramos una carpeta para la identificación de servicios. Aquí se describirán los servicios existentes que se han identificado como susceptibles de ser incorporados en el sistema. En la Figura 38 se muestra el toolbox definido para los servicios.

Figura 38. Toolbox para servicios

Página 55 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Para crear un servicio, basta con pinchar sobre el toolbox en el artefacto Servicio y arrastrar hasta el diagrama donde se quiera modelar. En la Figura 39 se observan las propiedades estándar de los servicios.

Figura 39. Propiedades estándares de un Servicio

En el artefacto Servicio existen una serie de campos que son obligatorios para que la descripción del servicio se considere correcta. En el caso de los atributos del servicio, éstos se añaden al artefacto desde el Toolbox DRS-Servicios, visto en la Figura 38. Para ello, en el toolbox se pincha sobre el atributo a añadir y se arrastra al servicio deseado. Aparecerá una pantalla para asignar el valor que se desee. Estos campos obligatorios son los siguientes: - Nombre (campo Name): Cada objetivo debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 14. Nomenclatura de Requisitos, el nombre debe cumplir el formato siguiente Servicio-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de servicios. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el servicio.

Página 56 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el servicio que se está tratando. Gestión de cambios (atributo): Son datos relativos a las versiones, ramificaciones de desarrollo, funcionalidades obsoletas, compatibilidades, fechas relacionadas, responsables de los cambios, motivos de los mismos, históricos de versiones anteriores, etc.. Gestión de vida (atributo): Datos relacionados con el estado en que se encuentra el servicio en determinados contextos (desarrollo, pruebas, integración, producción). Por ejemplo, mantiene que las versiones activas de un servicio en desarrollo son x y x+1, mientras que en producción es x-3. Además, mantiene datos de dependencias (deberían ser mínimas tratándose de servicios) cómo las que puede haber por la pertenencia del servicio a un BPM.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los servicios. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el servicio en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del servicio. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. Tabla 16. Reglas de Servicios

Diagramas de Servicios Debe tener un diagrama de tipo Servicios Todos los Servicios han de estar contenidos en el diagrama Definición de Servicios El nombre y la descripción han de estar rellenos Cada servicio que no sea del repositorio de servicios ha de tener, como mínimo, los atributos que aparecen en el toolbox Si un servicio está en el repositorio de servicios, debe tener todos los datos y ha de arrastrarse hacia el diagrama (no debe estar en la carpeta del project browser) 10.3. Requisitos de almacenamiento de información Los requisitos de almacenamiento de información, junto con las nuevas naturalezas, determinan todas las necesidades de almacenamiento que se detecten durante la realización de las entrevistas. Concretamente, un requisito de almacenamiento representa un concepto relevante para el que es necesario almacenar información en el sistema. En la Figura 40 se muestra el toolbox definido para los requisitos de almacenamiento, también compartido para las nuevas naturalezas.

Página 57 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 40. Toolbox para requisitos de la información

Para crear un requisito de almacenamiento, basta con pinchar sobre el toolbox en el artefacto RA y arrastrar hasta el diagrama donde se quiera modelar. En la Figura 40 se observa un requisito de almacenamiento y sus propiedades estándares.

Página 58 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 41. Propiedades estándares de un requisito de almacenamiento

En el artefacto RA existen una serie de campos que son obligatorios para que la descripción del requisito de almacenamiento se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada objetivo debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 14, el nombre debe cumplir el formato siguiente RA-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de requisitos de almacenamiento. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje en el que está el artefacto. En este caso sería NDT Requisitos.

Página 59 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Datos específicos (dentro de pestaña Details, botón Attributes): Los datos específicos representan el conjunto de descriptores de un RA desde el punto de vista de los usuarios y el cliente. La forma de añadir atributos se explica dentro del apartado 4.2 (Figura 15). Recordar que un atributo ha de tener obligatoriamente un nombre, un tipo (ver Figura 42), una descripción y una cardinalidad.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los requisitos de almacenamiento. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Importancia (valor etiquetado): Este valor indica la importancia que tiene el hecho de que el sistema tenga el concepto que modela el artefacto para el cliente. Debe escogerse uno de los valores predefinidos. - Urgencia (valor etiquetado): Este valor indica la urgencia del cumplimento del concepto que modela el artefacto. Debe escogerse uno de los valores predefinidos. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. - Estabilidad (valor etiquetado): Este valor etiquetado recoge la probabilidad de que el artefacto sufra cambios en su definición. Debe escogerse uno de los valores predefinidos. - Fuentes (valor etiquetado): Este valor informa de las fuentes de la versión del artefacto. - Intervalo temporal (valor etiquetado): Este valor indica el tiempo durante el artefacto tiene vigencia. Puede tomar dos valores, Presente y Presente y pasado. Al definirse los datos específicos del requisito funcional hay que indicar obligatoriamente el tipo. Al ser ésta una fase del desarrollo del ciclo de vida temprana, los tipos han de estar detallados en el lenguaje NDT-Requisitos. A continuación, Figura 42, se muestran los diferentes tipos de datos permitidos en NDTProfile para los requisitos de almacenamiento.

Página 60 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 42. Tipos de datos

Figura 43. Valores etiquetados de un requisito de almacenamiento

Página 61 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Tabla 17. Reglas de Requisitos de Almacenamiento (RA)

Diagramas de Requisitos de Almacenamiento Debe tener un diagrama de tipo Requisitos de Almacenamiento Todos los RA y NA han de estar contenidos en el diagrama Definición de Requisitos de Almacenamiento Debe tener un diagrama de tipo Requisitos de Almacenamiento Todos los RA han de estar contenidos en el diagrama El nombre del artefacto es RA-XX(X).Nombre El nombre del artefacto ha de estar en singular, usando la notación CamelCase y empezando en mayúscula La descripción está rellena El lenguaje es NDT Requisitos No existe ningún otro RA con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío El tipo del atributo pertenece al lenguaje del artefacto La descripción del atributo está rellena

10.4. Nuevas naturalezas Las nuevas naturalezas, junto con los requisitos de almacenamiento, determinan todas las necesidades de almacenamiento que se detecten durante la realización de las entrevistas. Las nuevas naturalezas se diferencian de los requisitos de almacenamiento en que los NA definen requisitos de información que ya existen en otros sistemas, de los cuales se va a hacer uso, o bien son nuevos dominios que se definen de manera concreta para el sistema que se está modelando. Las propiedades de una nueva naturaleza son las mismas que las de un requisito de almacenamiento de información, por lo que las figuras vistas anteriormente también son válidas para las nuevas naturalezas. Los valores etiquetados de una naturaleza se muestran en la Figura 44.

Página 62 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 44. Valores etiquetados de una nueva naturaleza

Tabla 18. Reglas de Nuevas Naturalezas (NA)

Definición de Nuevas Naturalezas Debe tener un diagrama de tipo Nuevas Naturalezas Todos los NA han de estar contenidos en el diagrama El nombre del artefacto es NA-XX(X).Nombre El nombre del artefacto ha de estar en singular, usando la notación CamelCase y empezando en mayúscula La descripción está rellena No existe ningún otro NA con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío La descripción del atributo está rellena El lenguaje es NDT Requisitos El tipo del atributo pertenece al lenguaje del artefacto 10.5. Requisitos de actores Un actor básico es todo actor que se identifica de forma individual atendiendo a algún tipo de criterio o punto de vista a la hora de interaccionar con el sistema. La experiencia dice que para identificar los actores básicos que interactúan con un sistema web, pueden existir diferentes criterios para hacerlo. La aplicación de cada uno de ellos resulta en la identificación de un grupo determinado de actores básicos. Cada actor básico corresponde a un rol individualizado de interacción con el sistema software. Cuando se plantea esta tarea no hay que preocuparse de si una misma persona física o usuario pueda actuar como diferentes actores, los actores deben estudiarse en el entorno de la aplicación. En la Figura 45 se muestra el toolbox definido modelar los actores del sistema como artefactos de tipo AC.

Página 63 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 45. Toolbox para actores

Para crear un actor, basta con pinchar sobre el toolbox en el artefacto AC y arrastrar hasta el diagrama donde se quiera modelar. En las Figura 46 y Figura 47 se observa un actor, sus propiedades estándares y sus valores etiquetados.

Página 64 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 46. Propiedades estándares de un actor

Figura 47. Valores etiquetados de un actor

Página 65 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario En el artefacto AC existen una serie de campos que son obligatorios para que la descripción del actor se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada actor debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 14, el nombre debe cumplir el formato siguiente AC-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de actores. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje en el que está el artefacto. En este caso sería NDT Requisitos. Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los actores. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Importancia (valor etiquetado): Este valor indica la importancia que tiene el hecho de que el sistema tenga el concepto que modela el artefacto para el cliente. Debe escogerse uno de los valores predefinidos. - Urgencia (valor etiquetado): Este valor indica la urgencia del cumplimento del concepto que modela el artefacto. Debe escogerse uno de los valores predefinidos. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. - Estabilidad (valor etiquetado): Este valor etiquetado recoge la probabilidad de que el artefacto sufra cambios en su definición. Debe escogerse uno de los valores predefinidos. - Fuentes (valor etiquetado): Este valor informa de las fuentes de la versión del artefacto. La generalización entre actores está permitida y se manifiesta con el conector Hereda de existente en el toolbox de Actores. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre el actor de origen y arrastrar hasta el actor de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Todo actor debe tener al menos una asociación con un caso de uso o bien extender a actores que tengan, al menos, un caso de uso ya que si no un actor define un ente externo al sistema que no tienen ninguna relación con el mismo, por lo que es irrelevante. Tabla 19. Reglas de Actores (AC)

Diagramas de Actores Debe tener un diagrama de tipo Actores Todos los AC han de estar contenidos en el diagrama Solo se pueden enlazar mediante el link Hereda de Definición de Actores El nombre del artefacto es AC-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula

Página 66 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario La descripción está rellena No existe ningún otro AC con la misma numeración El lenguaje es NDT Requisitos El tipo del atributo pertenece al lenguaje del artefacto 10.6. Requisitos funcionales Un requisito funcional define el comportamiento de una funcionalidad específica del sistema. En los sistemas también hay que recoger qué se va a poder hacer con la información y las posibilidades funcionales del mismo. Los requisitos funcionales responden a la pregunta de ¿qué se puede hacer en el sistema? Para realizar la captura y definición de las necesidades funcionales NDT hace uso de dos técnicas. Por un lado, propone utilizar los diagramas de casos de uso [Jacobson 1995], que representan de manera gráfica la funcionalidad del sistema. Sin embargo, el uso exclusivo de los diagramas, puede resultar demasiado ambiguo en algunos casos. Por ello, NDT propone acompañar a estos diagramas de información textual, recogida mediante patrones, que aclaran su significado y lo que representan. En la Figura 48 se muestra el toolbox definido modelar los requisitos funcionales.

Figura 48. Toolbox para requisitos funcionales

Para crear un requisito funcional, basta con pinchar sobre el toolbox en el artefacto RF y arrastrar hasta el diagrama donde se quiera modelar. Para obtener más información sobre cómo trabajar con los diagramas de casos de uso, se recomienda leer el apartado 4.1.1 de esta guía, donde se explica cómo han de ser estos diagramas. En la Figura 49 se observa un requisito funcional y sus propiedades estándares.

Página 67 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 49. Propiedades estándares de un requisito funcional

Los valores etiquetados de un requisito funcional se muestran en la Figura 50.

Página 68 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 50. Valores etiquetados de un requisito funcional

En el artefacto RF existen una serie de campos que son obligatorios para que la descripción del requisito funcional se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada requisito funcional debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 14, el nombre debe cumplir el formato siguiente RF-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de requisitos funcionales. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Restricciones (pestaña Constraints): En un requisito funcional se deben definir obligatoriamente restricciones. Éstos han de detallarse en la pestaña Constraints (ya descrita en el apartado 4.2 de esta guía, en la Figura 18) y los tipos que puede tener son precondición y post-condición. Si la funcionalidad no tuviera ninguna restricción, tanto en precondición como en post-condición se dejará claro que no aplica. - Diagrama de actividades o escenarios: Los requisitos funcionales han de estar descritos obligatoriamente mediante escenarios o un diagrama de actividades. Ambas opciones están disponibles, la primera mediante la pestaña Scenarios que se observa en la Figura 20 y la segunda haciendo doble clic sobre el RF. Si la funcionalidad que se quiere describir es compleja se usarán los diagramas de actividades obligatoriamente, que están descritos con más profundidad en el apartado 4.1.2. - Lenguaje (campo Language): En este campo se especifica el lenguaje en el que está el artefacto. En este caso sería NDT Requisitos. Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los requisitos funcionales. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Complejidad (campo Complexity): Este campo recoge la complejidad del requisito funcional. Por defecto, el requisito funcional será de complejidad baja, pero se recomienda que exista al menos uno de complejidad alta.

Página 69 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. Importancia (valor etiquetado): Este valor indica la importancia que tiene el hecho de que el sistema tenga el concepto que modela el artefacto para el cliente. Debe escogerse uno de los valores predefinidos. Urgencia (valor etiquetado): Este valor indica la urgencia del cumplimento del concepto que modela el artefacto. Debe escogerse uno de los valores predefinidos. Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. Estabilidad (valor etiquetado): Este valor etiquetado recoge la probabilidad de que el artefacto sufra cambios en su definición. Debe escogerse uno de los valores predefinidos. Fuentes (valor etiquetado): Este valor informa de las fuentes de la versión del artefacto. Frecuencia esperada (valor etiquetado): recoge la frecuencia con la que se espera que sea ejecutada la funcionalidad que representa el artefacto.

Tabla 20. Reglas de Requisitos Funcionales (RF)

Diagramas de Requisitos Funcionales Debe tener un diagrama de tipo Requisitos Funcionales Todos los RF han de estar contenidos en el diagrama Definición de Requisitos Funcionales El nombre del artefacto es RF-XX(X).Nombre El nombre del RF ha de estar en infinitivo El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro RF con la misma numeración El RF tiene un diagrama de actividades, o escenarios Los escenarios han de tener nombre, descripción y un tipo (normal o excepción) Los escenarios tienen que estar numerados secuencialmente El diagrama de actividad tiene que tener un nodo de inicio, un nodo de fin y, al menos, una actividad Todos los objetos del diagrama de actividades ha de tener nombre Las actividades han de tener un enlace de salida y, al menos, un enlace de entrada El nodo de inicio ha de tener un enlace de salida El nodo de fin ha de tener, como mínimo, un enlace de entrada Los enlaces de un nodo de decisión tienen que tener un valor en sus guardas Si el RF tiene constraints, ha de tener un nombre, una descripción y un tipo (pre-condición o postcondición) En el diagrama, todos los RF tienen asociado un AC, o bien es parte de otro RF El lenguaje es NDT Requisitos El tipo del atributo pertenece al lenguaje del artefacto

10.7. Requisitos de interacción 10.7.1. Frases

La manera en la que se modela cómo el usuario desea recuperar la información es mediante las frases. Una frase representa un criterio de recuperación de información en el sistema.

Página 70 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario En la Figura 51 se muestra el toolbox definido modelar las frases como artefactos de tipo FR.

Figura 51. Toolbox para frases

Para crear una frase, basta con pinchar sobre el toolbox en el artefacto FR y arrastrar hasta el diagrama donde se quiera modelar. Para crear un elemento UIControl sobre el FR, basta pinchar sobre el elemento y arrastrar encima del FR al que se le quiera asociar. Al igual que los requisitos de almacenamiento tienen atributos, las frases tienen artefactos de tipo UIControl asociados. A continuación, en la Figura 52, se explica cómo ha de describirse un elemento UIControl.

Página 71 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 52. Propiedades de un artefacto UIControl

Estos artefactos UIControl también tienen unas propiedades que han de rellenarse obligatoriamente, como son el nombre (campo Name), descripción (campo Notes) y elemento al que referencia (campo Alias). En el caso de que el UIControl sea un botón, éste tendrá en el campo Alias el nombre del Requisito Funcional del que coja la funcionalidad. En el caso de que sea de tipo Caja de Texto y refiera a algún atributo de un Requisito de Almacenamiento (o al RA completo) también deberá reflejarse en el campo Alias. Además, si un artefacto UIControl sólo fuera visible para alguno o algunos de los actores con los que está asociada la Frase, se usará la restricción Pre-condición (Pestaña Constraints) para ello. Volviendo a las frases, las propiedades estándar de este artefacto son las que se muestran en la Figura 53.

Página 72 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 53. Propiedades estándares de una frase

Los valores etiquetados se muestran en la Figura 54.

Figura 54. Valores etiquetados de una frase

Los campos obligatorios son el nombre, el autor, la descripción, al menos un artefacto tipo botón y al menos un artefacto tipo caja de texto. Además, cada frase debe tener uno o varios actores asociados, que son los que pueden realizar esas búsquedas.

Página 73 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario En el artefacto FR existen una serie de campos que son obligatorios para que la descripción de la frase se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada frase debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 14, el nombre debe cumplir el formato siguiente FR-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de frases. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Artefacto tipo botón (UIControl): Las frases han de tener, como mínimo, un artefacto UIControl de tipo botón, que indican una funcionalidad. Este botón ha de tener completados, obligatoriamente, el nombre, el alias y la descripción. Esta información se amplía con la Figura 52. - Artefacto tipo caja de texto (UIControl): Las frases han de tener, como mínimo, un artefacto UIControl de tipo caja de texto, que indican un dato. Este botón ha de tener completados, obligatoriamente, el nombre y la descripción. Si la información que se muestra proviene de un requisito de información, ha de indicarse en el alias. Esta información se amplía con la Figura 52. - Lenguaje (campo Language): En este campo se especifica el lenguaje en el que está el artefacto. En este caso sería NDT Requisitos. Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de las frases. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Importancia (valor etiquetado): Este valor indica la importancia que tiene el hecho de que el sistema tenga el concepto que modela el artefacto para el cliente. Debe escogerse uno de los valores predefinidos. - Urgencia (valor etiquetado): Este valor indica la urgencia del cumplimento del concepto que modela el artefacto. Debe escogerse uno de los valores predefinidos. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. - Estabilidad (valor etiquetado): Este valor etiquetado recoge la probabilidad de que el artefacto sufra cambios en su definición. Debe escogerse uno de los valores predefinidos. - Fuentes (valor etiquetado): Este valor informa de las fuentes de la versión del artefacto.

Página 74 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 55. Conexiones de los artefactos de interacción

Las frases se pueden enlazar con cualquier otro artefacto de interacción (LI o PV) mediante el conector Interactúa con, que aparece en el toolbox visto en la Figura 51. Este conector denota una relación de asociación entre artefactos de interacción, tal y como se observa en la Figura 55. Para hacer uso de este conector, basta con pinchar en el toolbox para seleccionar, pinchar en el artefacto de interacción de origen y arrastrar hacia el artefacto de interacción de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Además de este conector, las frases se han de enlazar con los actores mediante el conector Participa en, que aparece en el toolbox, visto en la Figura 51. Este conector denota una relación de asociación entre artefactos de interacción y actores, tal y como se observa en la Figura 55. Para hacer uso de este conector, basta con, en primer lugar, arrastrar el actor al diagrama de prototipos de visualización, pinchar en el toolbox para seleccionar, pinchar en el actor y arrastrar hacia el prototipo de visualización en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer

Página 75 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía.

Tabla 21. Reglas de Frases (FR)

Diagramas de Frases Debe tener un diagrama de tipo Requisitos de interacción Todos los FR han de estar contenidos en el diagrama Los FR solo pueden enlazarse a otros artefactos de interacción mediante el enlace Interactúa con Los FR solo pueden enlazarse a los AC mediante el enlace Participa en Definición de Frases El nombre del artefacto es FR-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro FR con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío El tipo del atributo es un RA, o un atributo de éste La descripción del atributo está rellena El lenguaje es NDT Requisitos El tipo del atributo pertenece al lenguaje del artefacto 10.7.2. Prototipos de visualización

Un prototipo de visualización permite expresar las posibilidades de navegación existente en el sistema, además de hacer referencia a qué datos se muestran a cada uno de los actores y qué funcionalidad se le asocia a cada módulo de presentación de la información. Para conseguir estos prototipos, es aconsejable hacer un estudio de los objetivos y de las entrevistas. Además, el tener definidos los requisitos y las frases de las tareas anteriores ayuda a identificarlos mejor.

Página 76 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 56. Toolbox para prototipos de visualización

En la Figura 56 se visualiza el toolbox para el modelado de los prototipos de visualización como artefactos PV. Para crear un prototipo de visualización, basta con pinchar sobre el toolbox en el artefacto PV y arrastrar hasta el diagrama donde se quiera modelar. Para crear un elemento UIControl sobre el PV, basta pinchar sobre el elemento y arrastrar encima del PV al que se le quiera asociar. La forma de describirse un elemento UIControl ya ha sido detallada en el apartado anterior, en concreto en la Figura 52. A continuación, se observan las propiedades estándares de un prototipo de visualización, en la Figura 57.

Página 77 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 57. Propiedades de un prototipo de visualización

Las propiedades estándares de un prototipo de visualización son las mismas que las de una frase, ya mostradas anteriormente. Sus valores etiquetados son los mismos que los de un objetivo, también mostrado con anterioridad.

Página 78 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 58. Valores etiquetados de un prototipo de visualización

En los prototipos de visualización, los datos obligatorios y opcionales son también los mismos que los de las frases, por lo que no se describirán nuevamente. Los prototipos de visualización se pueden enlazar con cualquier otro artefacto de interacción y entre sí mediante el conector Interactúa con y con actores mediante el enlace Participa en, que aparecen en el toolbox visto en la Figura 56. Estos conectores se explican en el apartado 10.7.1 y se observa en la Figura 55. Tabla 22. Reglas de Prototipos de Visualización (PV)

Diagramas de Prototipos de Visualización Debe tener un diagrama de tipo Requisitos de interacción Todos los PV han de estar contenidos en el diagrama Los PV solo pueden enlazarse a otros artefactos de interacción mediante el enlace Interactúa con Los PV solo pueden enlazarse a los AC mediante el enlace Participa en Definición de Prototipos de Visualización El nombre del artefacto es PV-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro PV con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío El tipo del atributo es un RA, o un atributo de éste La descripción del atributo está rellena El nombre de las operaciones deben ser el nombre de algún RF La descripción de la operación está rellena El lenguaje es NDT Requisitos El tipo del atributo pertenece al lenguaje del artefacto

10.7.3. Listados

Un listado permite modelar el resultado de una búsqueda, expresando aquellos campos que son necesario mostrar para, posteriormente, acceder al prototipo de visualización que corresponda.

Página 79 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 59. Toolbox para listados

En la Figura 56 se visualiza el toolbox para el modelado de los listados como artefactos LI. Para crear un listado, basta con pinchar sobre el toolbox en el artefacto LI y arrastrar hasta el diagrama donde se quiera modelar. Para crear un elemento UIControl sobre el LI, basta pinchar sobre el elemento y arrastrar encima del LI al que se le quiera asociar. La forma de describirse un elemento UIControl ya ha sido detallada en el apartado anterior, en concreto en la Figura 52. A continuación, se observan las propiedades estándares de un listado, en la Figura 57.

Página 80 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 60. Propiedades de un listado

Las propiedades estándares de un listado son las mismas que las de una frase, ya mostradas anteriormente. Sus valores etiquetados son los mismos que los de un objetivo, también mostrado con anterioridad.

Figura 61. Valores etiquetados de un listado

Página 81 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario En los listados, los datos obligatorios y opcionales son también los mismos que los de las frases, por lo que no se describirán nuevamente. Los listados se pueden enlazar con cualquier otro artefacto de interacción mediante el conector Interactúa con y con actores mediante el enlace Participa en, que aparecen en el toolbox visto en la Figura 59. Estos conectores se explican en el apartado 10.7.1 y se observa en la Figura 55 Tabla 23. Reglas de Listados (LI)

Diagramas de Listados Debe tener un diagrama de tipo Requisitos de interacción Todos los LI han de estar contenidos en el diagrama Los LI solo pueden enlazarse a otros mediante el enlace Interactúa con Definición de Listados El nombre del artefacto es LI-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro LI con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío El tipo del atributo es un RA, o un atributo de éste La descripción del atributo está rellena El nombre de las operaciones deben ser el nombre de algún RF La descripción de la operación está rellena El lenguaje es NDT Requisitos El tipo del atributo pertenece al lenguaje del artefacto

10.8. Requisitos no funcionales Los requisitos no funcionales aparecen en NDT-Profile como una herramienta para contemplar requisitos no cubiertos en ninguno de los anteriores. Un requisito no funcional es un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos. En la Figura 62 se muestra el toolbox definido modelar los requisitos no funcionales como artefactos de tipo RNF.

Página 82 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 62. Toolbox para requisitos no funcionales

Para crear un requisito funcional, basta con pinchar sobre el toolbox en el artefacto RNF y arrastrar hasta el diagrama donde se quiera modelar.

Página 83 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 63. Propiedades de un requisito no funcional

En el artefacto RNF existen una serie de campos que son obligatorios para que la descripción del requisito no funcional se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada requisito no funcional debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 14, el nombre debe cumplir el formato siguiente RNF-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de requisitos no funcionales. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje en el que está el artefacto. En este caso sería NDT Requisitos.

Página 84 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los requisitos no funcionales. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Importancia (valor etiquetado): Este valor indica la importancia que tiene el hecho de que el sistema tenga el concepto que modela el artefacto para el cliente. Debe escogerse uno de los valores predefinidos. - Urgencia (valor etiquetado): Este valor indica la urgencia del cumplimento del concepto que modela el artefacto. Debe escogerse uno de los valores predefinidos. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. - Estabilidad (valor etiquetado): Este valor etiquetado recoge la probabilidad de que el artefacto sufra cambios en su definición. Debe escogerse uno de los valores predefinidos. - Fuentes (valor etiquetado): Este valor informa de las fuentes de la versión del artefacto.

Figura 64. Valores etiquetados de un requisito no funcional

Tabla 24. Reglas de Requisitos No Funcionales (RNF)

Diagramas de Requisitos No Funcionales Tiene un diagrama de tipo Requisito No Funcional Todos los RNF han de estar contenidos en el diagrama Definición de Requisitos No Funcionales El nombre del artefacto es RNF-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro RNF con la misma numeración Todos los RNF están dentro del diagrama

Página 85 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario El lenguaje es NDT Requisitos El tipo del atributo pertenece al lenguaje del artefacto

Página 86 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 11. Análisis del sistema La fase de análisis contendrá los productos resultantes de analizar, definir y estructurar los requisitos establecidos en la fase anterior. A continuación, se describe como modelar cada elemento del análisis mediante las herramientas anteriores. Cada artefacto lleva un código identificativo. Los códigos de cada artefacto se muestran en la Tabla 25. Tabla 25. Nomenclatura de Análisis

Análisis Servicios Clases Clases de Nuevas Naturalezas Clases de Proceso Actor en Estudio Nodos Queries Índices Menús

Nombre Servicio-XX.Nombre CL-XX.Nombre CLn-XX.Nombre CP-XX.Nombre AE-XX.Nombre NO-XX.Nombre QU-XX.Nombre IN-XX.Nombre ME-XX.Nombre

La estructura del documento de análisis del sistema y su relación con la estructura de paquetes del perfil de NDT se muestra en la Figura 65.

Página 87 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 65. Estructura del DAS

Las herramientas correspondientes para la definición de los artefactos de análisis se muestran en la Figura 66.

Figura 66. Toolboxes de análisis

Página 88 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 11.1. Definición de servicios Una vez identificados los servicios en la fase de "Requisitos del Sistema" tendremos dos tipos de servicios. Los que hemos aportado del repositorio del cliente, que ya estén definidos y diseñados y los servicios que hemos identificados para nuestro proyecto. Son estos últimos, los servicios que debemos definir en esta fase. La definición de lo servicios pretende reunir la mayor parte de la información relevante asociada al mismo. En la Figura 67 se muestra el toolbox definido para los artefactos de tipo Servicios.

Figura 67. Toolbox de servicios de análisis

En la Figura 68 se observan las propiedades estándar de los Servicios.

Página 89 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 68. Propiedades estándares de un Servicio

En el artefacto Servicio de análisis existen una serie de campos que son obligatorios para que la descripción del servicio se considere correcta. En el caso de los atributos del servicio, éstos se añaden al artefacto desde el Toolbox DAS-Servicios, visto en la Figura 67. Para ello, en el toolbox se pincha sobre el atributo a añadir y se arrastra al servicio deseado. Aparecerá una pantalla para asignar el valor que se desee. Estos campos obligatorios son los siguientes: - Nombre (campo Name): Cada objetivo debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 25, el nombre debe cumplir el formato siguiente Servicio-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de servicios. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el servicio. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el servicio que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto.

Página 90 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

-

-

Espacio (atributo): Agrupación taxonómica general del servicio. Origina espacios de nombres que comienzan con la rama más genérica de la taxonomía y concluye con la más específica. Se suele representar con los nombres de cada uno de los nodos separados por puntos (p.ej. junta-andalucia.ccul.empleados…). Información aportada por la pertenencia a un repositorio. Definición (atributo): Descripción exhaustiva del servicio. Debe ser indexable mediante herramientas de búsqueda. Taxonomía (atributo): Nodo de la taxonomía de servicios al que pertenece. Información aportada por la pertenencia a un repositorio. Semántica (atributo): Lista de palabras clave para las valoraciones realizadas por motores de búsqueda. Suelen ser adjetivos y sustantivos íntimamente relacionados con la funcionalidad del servicio. Entidades de negocio (atributo): Lista de entidades de negocio relacionadas con el servicio. Se recogerán en este campo las entidades principales asociadas al negocio (en caso de utilizar entidades auxiliares que caen fuera del ámbito de la funcionalidad, no serán incluidas). Tipificación técnica (atributo): Cualquier servicio ha de encontrarse tipificado técnicamente. A continuación se presenta el árbol de tipificación de servicios:

Tabla 26: Tipificación técnica de los Servicio

Raíz

Tipo

TIPOLOGÍA

PROCESO

Subtipo COORDINACIÓN PROCESO

FUNCIONAL

NEGOCIO PROXY WRAPPER

TECNOLÓGICO

CONTROL UTILIDAD

-

-

Descripción Se encarga de coordinar una secuencia o flujo formado por varios procesos. Se encarga de realizar funciones propias de lógica de procesos (toma de decisiones, sincronización, etc.). Encapsula lógica de negocio atomizada. Proporciona una funcionalidad de negocio remota implementada por aplicaciones distribuidas. Encapsula funcionalidades de negocio proporcionadas por aplicaciones legacy. Proporciona funciones horizontales de reparto, seguridad, sesión, etc. (Dispatcher, façades…). Proporciona funcionalidades ajenas al negocio (cálculos, helpers…).

Gestión de cambios (atributo): Son datos relativos a las versiones, ramificaciones de desarrollo, funcionalidades obsoletas, compatibilidades, fechas relacionadas, responsables de los cambios, motivos de los mismos, históricos de versiones anteriores, etc. Gestión de vida (atributo): Datos relacionados con el estado en que se encuentra el servicio en determinados contextos (desarrollo, pruebas, integración, producción). Por ejemplo, mantiene que las versiones activas de un servicio en desarrollo son x y x+1, mientras que en producción es x-3. Además, mantiene datos de dependencias (deberían ser mínimas tratándose de servicios) cómo las que puede haber por la pertenencia del servicio a un BPM. Políticas (atributo): Especificación de las políticas que aplican al servicio que serán definidas en el modelo de gobierno SOA. Seguridad (atributo): Especificación de las restricciones de seguridad que aplican al servicio que serán definidas en el modelo de gobierno SOA. Monitorización funcional (atributo): Indicadores de monitorización funcional que aplican al servicio que serán definidos en el modelo de gobierno SOA.

Página 91 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Alertas (atributo): Niveles y tipologías de alerta en función de los indicadores anteriormente definidos. Disponibilidad (atributo): Indica, la franja o franjas horarias y los días en los que el servicio puede ser utilizado. Por ejemplo, de 8:00 a 20:00 de lunes a viernes no festivos, o un 24hx7días. Máximo número de invocaciones / tiempo (atributo): Indica el número máximo de invocaciones que un cliente puede realizar en una unidad de tiempo definida, por ejemplo, 10 invocaciones / segundo. Tiempo máximo de respuesta (atributo): Tiempo máximo de procesamiento de mensajes. Cláusulas (atributo): Otras cláusulas que puedan aplicar a la particularidad de la contratación y en su caso, al incumplimiento. Operaciones (dentro de pestaña Details, botón Operations): Los servicios han de tener, como mínimo una operación. La forma de añadir operaciones se explica dentro del apartado 4.2 (Figura 17). Recordar que una operación de un servicio ha de tener obligatoriamente un nombre, unos parámetros, un valor de retorno y una descripción.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los servicios. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el servicio en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del servicio. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. Tabla 27. Reglas de Servicios de Análisis

Definición de Servicios Debe tener un diagrama de tipo Servicios El nombre y la descripción han de estar rellenos Cada servicio que no sea del repositorio de servicios ha de tener, como mínimo, los atributos que aparecen en el toolbox Si un servicio está en el repositorio de servicios, debe tener todos los datos y ha de arrastrarse hacia este diagrama (no debe estar en la carpeta del project browser) Los atributos han de tener cumplimentado obligatoriamente, al menos, el nombre, el tipo y el estereotipo. Las operaciones, han de tener relleno el nombre, los parámetros, el valor de retorno y la descripción. 11.2. Clases de contenido El modelo de clases de contenido representa el diagrama de clases derivado de los requisitos de almacenamiento de información. Permite modelar cómo se estructura la información que maneja en el sistema. En la Figura 48 se muestra el toolbox definido modelar las clases de contenido como artefactos de tipo CL, en el caso de clases que provienen de los RA de requisitos, y artefactos de tipo CLn, para clases que provienen de los NA de requisitos.

Página 92 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 69. Toolbox de clases de contenido

Para crear una clase, basta con pinchar sobre el toolbox en el artefacto CL o CLn y arrastrar hasta el diagrama donde se quiera modelar. Para ver las propiedades estándares de una clase, se hará doble clic sobre el CL, observándose la pantalla de la Figura 70.

Página 93 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 70. Propiedades estándares de clases de persistencia

En los artefactos CL y CLn existen una serie de campos que son obligatorios para que la descripción de las clases de persistencia se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada requisito no funcional debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 25, el nombre debe cumplir el formato siguiente CL-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de requisitos no funcionales. CLnXX.Nombre en el caso de las CLn. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando.

Página 94 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto. Atributos (dentro de pestaña Details, botón Attributes): Los atributos representan el conjunto de descriptores de un CL desde el punto de vista de los usuarios y el cliente. La forma de añadir atributos se explica dentro del apartado 4.2 (Figura 15). Recordar que un atributo ha de tener obligatoriamente un nombre, un tipo, una descripción y una cardinalidad.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de las clases. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna.

Figura 71. Valores etiquetados de una clase de análisis

Las clases de persistencia se pueden enlazar entre sí mediante los conectores agregación, asociación, composición y generalización que aparece en el toolbox visto en la Figura 69Figura 35. Estos conectores son extensiones de los conectores aggregation, association, composition y generalization de UML. Para hacer uso de estos conectores, basta con pinchar en el toolbox para seleccionar el conector, pinchar en la clase de origen y arrastrar hacia la clase de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 28. Reglas de Clases de Persistencia (CL y CLn)

Diagramas de Prototipos de Visualización Debe tener un diagrama de tipo Clases de persistencia Todos los CL y CLn han de estar contenidos en el diagrama Definición de Prototipos de Visualización El nombre del artefacto es CL-XX(X).Nombre o CLn-XX(X).Nombre El nombre del artefacto ha de estar en singular, usando la notación CamelCase y empezando en mayúscula

Página 95 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario La descripción está rellena No existe ningún otro RA con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El lenguaje del artefacto debe ser un lenguaje de programación válido El tipo del atributo no está vacío El tipo del atributo debe ser un tipo del lenguaje del artefacto La descripción del atributo está rellena Existe un CL/CLn por cada RA/NA Cada atributo del RA/NA está en el CL/CLn El tipo del atributo del CL/CLn es igual al del RA/NA La cardinalidad del atributo del CL/CLn es igual al del RA/NA Si hay un atributo de tipo RA en el RA/NA, existe una asociación entre los CL/CLn equivalentes La cardinalidad de la asociación es la cardinalidad del atributo que crea la asociación en el RA/NA 11.3. Modelo de navegación El modelo de navegación puede variar sustancialmente dependiendo del actor que en cada momento interactúe con el sistema. Por ello se definen los actores en estudio a partir de los actores definidos en los requisitos y se realizara un diagrama de navegación para cada uno de los actores en estudio. Tabla 29. Reglas de Clases de Navegación

Diagrama de Clases de Navegación Debe tener un diagrama de tipo Modelo navegacional Todos los Nodos, Queries, Índices y Menús han de estar contenidos en el diagrama Los artefactos solo pueden enlazarse a otros mediante los enlaces Navega a 11.3.1.Actores en estudio

Los actores en estudio se definen como agrupaciones de los actores definidos en requisitos y se representan mediante los artefactos AE-XX de NDT-Profile. Esta tarea solo será obligatoria cuando el equipo detecte que los actores pueden agruparse para reducir la necesidad de elaborar modelos iguales para actores diferentes. En la Figura 72 se muestra el toolbox definido modelar los actores.

Figura 72. Toolbox para actores de estudio

Página 96 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Para crear un actor, basta con pinchar sobre el toolbox en el artefacto AE y arrastrar hasta el diagrama donde se quiera modelar. En las Figura 73 y Figura 74 se observa un actor de estudio, sus propiedades estándares y sus valores etiquetados.

Figura 73. Propiedades estándares de un actor de estudio

En el artefacto AE existen una serie de campos que son obligatorios para que la descripción del actor se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada actor debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 14, el nombre debe cumplir el formato siguiente AE-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de actores.

Página 97 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los actores. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Colección (botón Collection Classes en pestaña Details): Mediante este apartado se indicará si la clase es una colección. Si no lo fuera, no habría que rellenar nada. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna.

Figura 74. Valores etiquetados de un actor de estudio

Como en los actores del sistema en requisitos, la generalización entre actores de estudio está permitida y se manifiesta con el conector Hereda de existente en el toolbox de la Figura 74. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre el actor de origen y arrastrar hasta el actor de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 30. Reglas de Actores en Estudio (AE)

Diagramas de Actores en Estudio Debe tener un diagrama de tipo Actores en estudio

Página 98 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Todos los Actores en estudio han de estar contenidos en el diagrama Solo se pueden enlazar mediante el link Hereda de Definición de Actores en Estudio El nombre del artefacto es AE-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro AE con la misma numeración Existe un AE por cada AC El lenguaje del artefacto debe ser un lenguaje de programación válido 11.3.2.Nodos

Un nodo es un punto de la navegación en la que el usuario puede trabajar con la información: recuperar o modificar datos del sistema, así como disponer de las posibilidades funcionales del mismo. Los nodos se generan a partir de los prototipos de visualización. Básicamente, cada prototipo de visualización genera un nodo, y los artefactos UIControl que no sean de tipo botón del prototipo pasan a ser atributos y los artefactos UIControl tipo botón pasan a ser las operaciones de los nodos. A continuación, en la Figura 75, se observa el toolbox para modelar los nodos, junto con el resto de clases del modelo navegacional, como un artefacto de tipo NO.

Figura 75. Toolbox para las clases del modelo navegacional

En la Figura 76 podemos ver las propiedades estándares de un nodo modelado como un artefacto de tipo NO.

Página 99 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 76. Propiedades estándares y valores etiquetados de un nodo

En el artefacto NO existen una serie de campos que son obligatorios para que la descripción del nodo se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada nodo debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 25, el nombre debe cumplir el formato siguiente NO-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de nodos. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto.

Página 100 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

-

Artefacto asociado (Alias): En este campo se especificará el artefacto desde el que se genera el artefacto actual, en este caso, el prototipo de visualización del que procede. Atributos (dentro de pestaña Details, botón Attributes): Los atributos se crean a partir de los artefactos UIControl que no sean de tipo botón. La forma de añadir atributos se explica dentro del apartado 4.2 (Figura 15). Recordar que un atributo ha de tener obligatoriamente un nombre, un tipo, una descripción y una cardinalidad. Operaciones (dentro de pestaña Details, botón Operations): Las operaciones se crean a partir de los artefactos UIControl de tipo botón. La forma de añadir operaciones se explica dentro del apartado 4.2 (Figura 17). Recordar que una operación ha de tener obligatoriamente un nombre, un alias y una descripción.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los nodos. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. Los nodos pueden conectarse a cualquier otro artefacto del modelo de navegación mediante los enlaces Navega a, que se muestra en la Figura 75. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre el nodo de origen y arrastrar hasta el artefacto de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 31. Reglas de Nodos (NO)

Definición de Nodos El nombre del artefacto es NO-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro NO con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío El tipo del atributo es un CL, o un atributo de éste La descripción del atributo está rellena El nombre de las operaciones deben ser el nombre de algún RF La descripción de la operación está rellena Existe un NO por cada PV Cada atributo del PV está en el NO El tipo del atributo del NO es el CL correspondiente al RA del atributo del PV La cardinalidad del atributo del NO es igual al del PV La operación del NO es la clase de Control correspondiente al RF de la operación del PV Si hay un enlace simple (no múltiple) entre dos PV, debe haber un enlace idéntico entre los dos NO correspondientes Si hay un enlace entre un PV y un FR, debe haber un enlace idéntico entre los NO y QU

Página 101 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario correspondientes El lenguaje del NO debe ser un lenguaje de programación válido 11.3.3.Queries

Una query representa aquellos puntos de la navegación donde el sistema solicita información al usuario que es esencial para continuar con la navegación. Las queries se generan a partir de las frases. Básicamente, cada frase genera una query, y los artefactos UIControl que no sean de tipo botón del prototipo pasan a ser atributos y los artefactos UIControl tipo botón pasan a ser las operaciones de las queries. En la Figura 75, se observa el toolbox para modelar las queries, junto con el resto de clases del modelo navegacional, como un artefacto de tipo QU. En la Figura 77 podemos ver las propiedades estándares de una query modelada como un artefacto de tipo QU.

Página 102 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 77. Propiedades estándares y valores etiquetados de una query

En el artefacto QU existen una serie de campos que son obligatorios para que la descripción de la query se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada query debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 25, el nombre debe cumplir el formato siguiente QU-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de queries. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto.

Página 103 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

-

Artefacto asociado (Alias): En este campo se especificará el artefacto desde el que se genera el artefacto actual, en este caso, el prototipo de visualización del que procede. Atributos (dentro de pestaña Details, botón Attributes): Los atributos se crean a partir de los artefactos UIControl que no sean de tipo botón. La forma de añadir atributos se explica dentro del apartado 4.2 (Figura 15). Recordar que un atributo ha de tener obligatoriamente un nombre, un tipo, una descripción y una cardinalidad. Operaciones (dentro de pestaña Details, botón Operations): Las operaciones se crean a partir de los artefactos UIControl de tipo botón. La forma de añadir operaciones se explica dentro del apartado 4.2 (Figura 17). Recordar que una operación ha de tener obligatoriamente un nombre, un alias y una descripción.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los nodos. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. Las queries pueden conectarse a cualquier otro artefacto del modelo de navegación mediante los enlaces Navega a, que se muestra en la Figura 75. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre la query de origen y arrastrar hasta el artefacto de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 32. Reglas de Queries (QU)

Definición de Queries El nombre del artefacto es QU-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro QU con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío El tipo del atributo es un CL, o un atributo de éste La descripción del atributo está rellena Existe un QU por cada FR Cada atributo del FR está en el QU El tipo del atributo del QU es el CL correspondiente al RA del atributo del FR La cardinalidad del atributo del QU es igual al del FR Si hay un enlace entre un PV y un FR, debe haber un enlace idéntico entre los NO y QU correspondientes El lenguaje del QU debe ser un lenguaje de programación válido

Página 104 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 11.3.4.Índices

Un índice representa aquellos puntos de navegación donde al usuario se le facilita una lista de posibles resultados a visualizar. Todos referidos a la misma información. Los índices se generan a partir de un enlace múltiple entre prototipos de visualización. Si el enlace entre dos prototipos de visualización tiene cardinalidad múltiple, entre los nodos generados se crea un índice, conectándolo a ambos. En la Figura 75, se observa el toolbox para modelar los índices como un artefacto de tipo IN. En la Figura 78 podemos ver las propiedades estándares de un índice modelado como un artefacto de tipo IN.

Figura 78. Propiedades estándares y valores etiquetados de un índice

En el artefacto IN existen una serie de campos que son obligatorios para que la descripción del índice se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada índice debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 25, el nombre debe cumplir el formato siguiente IN-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de índices.

Página 105 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los índices. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. Las índices pueden conectarse a cualquier otro artefacto del modelo de navegación mediante los enlaces Navega a, que se muestra en la Figura 75. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre el índice de origen y arrastrar hasta el artefacto de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 33. Reglas de Índices (IN)

Definición de Índices El nombre del artefacto es IN-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro IN con la misma numeración Existe un IN por cada enlace múltiple entre dos PV, ese IN tendrá un enlace a cada PV El lenguaje del IN debe ser un lenguaje de programación válido 11.3.5.Menús

Un menú representa un punto de la navegación desde la que el usuario puede ir a varias opciones diferentes. La diferencia entre el menú y el índice es que en el índice todos los elementos que aparecen se refieren a la misma información. En un menú las opciones entre las que se puede elegir no tienen por qué estar relacionadas. El paso de detección de menús realmente se basa en garantizar la calidad del modelo de navegación final. La inclusión de menús en el modelo de navegación va a tener como objetivo el garantizar que todas las partes del modelo navegacional son alcanzables desde cualquier otro punto. En la Figura 75, se observa el toolbox para modelar los índices como un artefacto de tipo ME. En la Figura 79 podemos ver las propiedades estándares de un menú modelado como un artefacto de tipo ME.

Página 106 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 79. Propiedades estándares y valores etiquetados de un menú

En el artefacto ME existen una serie de campos que son obligatorios para que la descripción del menú se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada menú debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 25, el nombre debe cumplir el formato siguiente ME-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de menú. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto.

Página 107 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los menús. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. Los menús pueden conectarse a cualquier otro artefacto del modelo de navegación mediante los enlaces Navega a, que se muestra en la Figura 75. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre el menú de origen y arrastrar hasta el artefacto de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 34. Reglas de Menús (ME)

Definición de Menús El nombre del artefacto es ME-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro ME con la misma numeración El lenguaje del ME debe ser un lenguaje de programación válido 11.4. Modelo de interfaz abstracta En general, la recomendación para la elaboración de la interfaz abstracta, es hacer uso de los prototipos HTML generados por NDT-Prototypes. Sin embargo, los equipos pueden elaborar un prototipo de la interfaz en base a las necesidades o al modelo que prefieran. No se entiende como una actividad obligatoria pero se recomienda su uso pues resulta muy válida como técnica de validación con los usuarios. Se tendrá que linkar la carpeta donde estén esos prototipos, que deberá ser la carpeta /docs/das/interfaz abstracta. La forma de linkar es tal y como se ha descrito en la sección 5.4.

Página 108 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 12. Diseño del sistema La fase de diseño, engloba los aspectos concretos de cómo el análisis se implementará en la máquina. Está orientado a la plataforma concreta con la que se vaya a trabajar y debe corresponderse con la estructura del futuro código. A continuación, se describe como modelar cada elemento del análisis mediante las herramientas anteriores. Cada artefacto lleva un código identificativo. Los códigos de cada artefacto se muestran en la Tabla 35. Tabla 35. Nomenclatura de Diseño

Diseño Servicios Presentación Negocio Acceso a datos Tabla

Nombre Servicio-XX.Nombre PR-XX.Nombre NE-XX.Nombre AD-XX.Nombre Según cliente

La estructura del documento de diseño del sistema y su relación con la estructura de paquetes del perfil de NDT se muestra en la Figura 80.

Página 109 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 80. Estructura del DDS

Las herramientas correspondientes para la definición de los artefactos de diseño se muestran en la Figura 81.

Figura 81. Toolboxes de diseño

Página 110 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 12.1. Diseño de servicios Una vez definidos los servicios que hemos detectado en el proyecto, se procederá en esta fase al diseño técnico de dichos servicios. En la Figura 82 se muestra el toolbox definido para los artefactos de tipo Servicios.

Página 111 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 82. Toolbox de servicios de diseño

Página 112 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario En la Figura 83 se observan las propiedades estándar de los Servicios. Los campos obligatorios son el nombre del artefacto, el autor, la descripción y los atributos obligatorios.

Figura 83. Propiedades estándares de un Servicio de diseño

Página 113 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario En el artefacto Servicio de diseño existen una serie de campos que son obligatorios para que la descripción del servicio se considere correcta. En el caso de los atributos del servicio, éstos se añaden al artefacto desde el Toolbox DDS-Servicios, visto en la Figura 67. Para ello, en el toolbox se pincha sobre el atributo a añadir y se arrastra al servicio deseado. Aparecerá una pantalla para asignar el valor que se desee. Estos campos obligatorios son los siguientes: - Nombre (campo Name): Cada objetivo debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 25, el nombre debe cumplir el formato siguiente Servicio-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de servicios. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el servicio. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el servicio que se está tratando. - Responsable del dominio (atributo): En este campo se indica la persona de máxima responsabilidad del dominio. - Responsable técnico del dominio (atributo): En este campo se indica la persona responsable del dominio. - Espacio (atributo): Agrupación taxonómica general del servicio. Origina espacios de nombres que comienzan con la rama más genérica de la taxonomía y concluye con la más específica. Se suele representar con los nombres de cada uno de los nodos separados por puntos (p.ej. junta-andalucia.ccul.empleados…). Información aportada por la pertenencia a un repositorio. - Definición (atributo): Descripción exhaustiva del servicio. Debe ser indexable mediante herramientas de búsqueda. - Taxonomía (atributo): Nodo de la taxonomía de servicios al que pertenece. Información aportada por la pertenencia a un repositorio. - Semántica (atributo): Lista de palabras clave para las valoraciones realizadas por motores de búsqueda. Suelen ser adjetivos y sustantivos íntimamente relacionados con la funcionalidad del servicio. - Entidades de negocio (atributo): Lista de entidades de negocio relacionadas con el servicio. Se recogerán en este campo las entidades principales asociadas al negocio (en caso de utilizar entidades auxiliares que caen fuera del ámbito de la funcionalidad, no serán incluidas). - Tipificación técnica (atributo): Cualquier servicio ha de encontrarse tipificado técnicamente. A continuación se presenta el árbol de tipificación de servicios: Tabla 36: Tipificación técnica de los Servicios

Raíz TIPOLOGÍA

Tipo PROCESO

Subtipo COORDINACIÓN PROCESO

FUNCIONAL

NEGOCIO PROXY WRAPPER

TECNOLÓGICO

CONTROL

Descripción Se encarga de coordinar una secuencia o flujo formado por varios procesos. Se encarga de realizar funciones propias de lógica de procesos (toma de decisiones, sincronización, etc.). Encapsula lógica de negocio atomizada. Proporciona una funcionalidad de negocio remota implementada por aplicaciones distribuidas. Encapsula funcionalidades de negocio proporcionadas por aplicaciones legacy. Proporciona funciones horizontales de reparto, seguridad, sesión, etc. (Dispatcher, façades…).

Página 114 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario UTILIDAD

-

-

Proporciona funcionalidades ajenas al negocio (cálculos, helpers…).

Mensajes (atributo): Es la información que requieren las operaciones para variar su comportamiento. El mensaje es de ida y vuelta. Normalmente se representa mediante parámetros de entrada y salida. Tipos (atributo): Restricciones de forma y contenido de los mensajes. Se recomienda realizar definiciones de tipos que sean estándar y serializables. Errores / Excepciones (atributo): Posibles malfuncionamientos de las operaciones. Localización (atributo): Punto de invocación del servicio. Gestión de cambios (atributo): Son datos relativos a las versiones, ramificaciones de desarrollo, funcionalidades obsoletas, compatibilidades, fechas relacionadas, responsables de los cambios, motivos de los mismos, históricos de versiones anteriores, etc. Gestión de vida (atributo): Datos relacionados con el estado en que se encuentra el servicio en determinados contextos (desarrollo, pruebas, integración, producción). Por ejemplo, mantiene que las versiones activas de un servicio en desarrollo son x y x+1, mientras que en producción es x-3. Además, mantiene datos de dependencias (deberían ser mínimas tratándose de servicios) cómo las que puede haber por la pertenencia del servicio a un BPM. Responsable (atributo): Responsable de los entregables del contrato / servicio. Dueño (atributo): Nivel máximo de escalamiento en términos del contrato / servicio. Consultado (atributo): Quién debe ser consultado antes de tomar cualquier acción sobre el presente contrato / servicio. Informado (atributo): Quién debe ser informado de cualquier decisión o acción que se vaya a tomar sobre el presente contrato / servicio. Políticas (atributo): Especificación de las políticas que aplican al servicio que serán definidas en el modelo de gobierno SOA. Seguridad (atributo): Especificación de las restricciones de seguridad que aplican al servicio que serán definidas en el modelo de gobierno SOA. Monitorización funcional (atributo): Indicadores de monitorización funcional que aplican al servicio que serán definidos en el modelo de gobierno SOA. Monitorización técnica (atributo):. Alertas (atributo): Niveles y tipologías de alerta en función de los indicadores anteriormente definidos. Disponibilidad (atributo): Indica, la franja o franjas horarias y los días en los que el servicio puede ser utilizado. Por ejemplo, de 8:00 a 20:00 de lunes a viernes no festivos, o un 24hx7días. Máximo número de invocaciones / tiempo (atributo): Indica el número máximo de invocaciones que un cliente puede realizar en una unidad de tiempo definida, por ejemplo, 10 invocaciones / segundo. Tiempo medio de respuesta (atributo):. Tiempo máximo de respuesta (atributo): Tiempo máximo de procesamiento de mensajes. Cláusulas (atributo): Otras cláusulas que puedan aplicar a la particularidad de la contratación y en su caso, al incumplimiento. Operaciones (dentro de pestaña Details, botón Operations): Los servicios han de tener, como mínimo una operación. La forma de añadir operaciones se explica dentro del apartado 4.2 (Figura 17). Recordar que una operación de un servicio ha de tener obligatoriamente un nombre, unos parámetros, un valor de retorno y una descripción.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los servicios. Éstos son:

Página 115 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Estado (campo Status): Este campo recoge la situación en la que se encuentra el servicio en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. Versión (campo Version): A través de este campo se gestionan las diferentes versiones del servicio. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica.

Además, el servicio ha de tener asociado dos diagramas. Uno de ellos lo tiene asociado por defecto, que es el diagrama WSDL. Se cumplimentará con el toolbox WSDL que trae predefinido Enterprise Architect 7.5. Otro diagrama obligatorio es el diagrama SOAML Component, que habrá que crearlo. Este diagrama viene predefinido en Enterprise Architect 7.5. Adicionalmente, es aconsejable realizar un diagrama de secuencia del servicio. Para esto usaremos el diagrama SOAML Sequence que trae predefinido Enterprise Architect 7.5. Tabla 37. Reglas de Servicios de Diseño

Definición de Servicios de Diseño Debe tener un diagrama de tipo Servicios El nombre y la descripción han de estar rellenos Cada servicio que no sea del repositorio de servicios ha de tener, como mínimo, los atributos que aparecen en el toolbox Si un servicio está en el repositorio de servicios, debe tener todos los datos y ha de arrastrarse hacia este diagrama (no debe estar en la carpeta del project browser) Cada servicio debe tener asociado un diagrama WSDL Cada servicio debe tener asociado un diagrama SoaML Component 12.2. Descripción de la arquitectura Para comenzar a definir el diseño de cualquier sistema, es necesario definir la arquitectura tecnológica del sistema. Esta parte se divide en un diagrama para definir el entorno tecnológico y en una serie de documentos. En el diagrama de esta carpeta debe describirse el entorno tecnológico, el lenguaje de programación, el entorno de programación, etc. Debe estar descrito con un nivel de detalle que no dé lugar a errores. Para ello, se utilizará el diagrama de componentes que hay creado por defecto en NDT-Profile. Los documentos restantes han de describir como el sistema accede a sistemas externos, el rendimiento que se espera del sistema, los mecanismos de seguridad, la adaptación a la LOPD o la previsión de crecimiento en el futuro. Estos documentos se deben adjuntar al archivo EAP tal y como se ha descrito en la sección 5.4. 12.3. Modelo de clases de diseño En el modelo de clases será la evolución de las clases de análisis incluyendo los patrones de diseño necesarios, las clases y métodos necesarios para su correcta implementación. En la Figura 84 se muestra el toolbox definido para las clases de diseño, compartido entre las clases Negocio, Presentación y Acceso a datos.

Página 116 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 84. Toolbox de clases de diseño

12.3.1.Acceso a datos

Un artefacto Acceso a datos es la evolución de los artefactos del modelo de contenido de análisis. A partir de cada clase de contenido (CL y CLn) se genera una clase de acceso a datos con los mismos atributos. En la Figura 85 podemos ver las propiedades estándares de un artefacto de acceso a datos modelado como un artefacto de tipo AD.

Página 117 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 85. Propiedades estándares y valores etiquetados de una clase de acceso a datos

En el artefacto AD existen una serie de campos que son obligatorios para que la descripción de la clase de acceso a datos se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada clase de presentación debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 35, el nombre debe cumplir el formato siguiente AD-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de clases de presentación. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto. - Artefacto asociado (Alias): En este campo se especificará el artefacto desde el que se genera el artefacto actual, en este caso, la clase de contenido del que procede. - Atributos (dentro de pestaña Details, botón Attributes): La forma de añadir atributos se explica dentro del apartado 4.2 (Figura 15). Recordar que un atributo ha de tener obligatoriamente un nombre, un tipo, una descripción y una cardinalidad.

Página 118 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los nodos. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Nombre_Clase (valor etiquetado): En este campo se indica el nombre exacto de la clase en la que se implementa. - Paquete (valor etiquetado): En este campo se indica el nombre exacto del paquete con contiene a la clase implementada. - Tecnología (valor etiquetado): En este campo se indica, mediante un desplegable, la tecnología de la clase. Las clases de diseño se pueden conectarse a cualquier otro artefacto del modelo de clases de diseño mediante los enlaces AS (Asociación), que se muestra en la Figura 84. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre el artefacto de origen y arrastrar hasta el artefacto de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 38. Reglas de Acceso a datos (AD)

Definición de Clases de acceso a datos El nombre del artefacto es AD-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro AD con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío El tipo del atributo es un AD, o un atributo de éste La descripción del atributo está rellena Existe un AD por cada clase de contenido Cada atributo de un CL está en el AD La cardinalidad del atributo del AD es igual al del CL El lenguaje del AD debe ser un lenguaje de programación válido

12.3.2.Negocio

Un artefacto Negocio es la evolución de las clases de proceso. A partir de cada CP se genera un artefacto de negocio con las mismas operaciones. En la Figura 86 podemos ver las propiedades estándares de un artefacto de negocio modelado como un artefacto de tipo NE.

Página 119 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 86. Propiedades estándares y valores etiquetados de una clase de negocio

En el artefacto NE existen una serie de campos que son obligatorios para que la descripción de la clase de negocio se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada clase de negocio debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 35, el nombre debe cumplir el formato siguiente NE-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de clases de negocio. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto. - Artefacto asociado (Alias): En este campo se especificará el artefacto desde el que se genera el artefacto actual, en este caso, el prototipo de visualización del que procede. - Operaciones (dentro de pestaña Details, botón Operations): La forma de añadir operaciones se explica dentro del apartado 4.2 (Figura 17). Recordar que una operación ha de tener obligatoriamente un nombre, un alias y una descripción.

Página 120 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los nodos. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Nombre_Clase (valor etiquetado): En este campo se indica el nombre exacto de la clase en la que se implementa. - Paquete (valor etiquetado): En este campo se indica el nombre exacto del paquete con contiene a la clase implementada. - Tecnología (valor etiquetado): En este campo se indica, mediante un desplegable, la tecnología de la clase. Las clases de diseño se pueden conectarse a cualquier otro artefacto del modelo de clases de diseño mediante los enlaces AS (Asociación), que se muestra en la Figura 84. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre el artefacto de origen y arrastrar hasta el artefacto de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 39. Reglas de Negocio (NE)

Definición de Clases de negocio El nombre del artefacto es NE-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro NE con la misma numeración El nombre de las operaciones debe empezar en minúscula, usando la notación CamelCase La descripción de la operación está rellena Existe un NE por cada artefacto CP El lenguaje del PR debe ser un lenguaje de programación válido

12.3.3.Presentación

Un artefacto Presentación es la evolución de los artefactos del modelo de navegación (NO, QU e IN). A partir de cada artefacto del modelo de navegación se genera un artefacto Presentación en el modelo de clases de diseño con los mismos atributos y/o operaciones, si las hubiese. En la Figura 87 podemos ver las propiedades estándares de un artefacto de presentación modelado como un artefacto de tipo PR.

Página 121 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 87. Propiedades estándares y valores etiquetados de una clase de presentacion

En el artefacto PR existen una serie de campos que son obligatorios para que la descripción de la clase de presentación se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada clase de presentación debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 35, el nombre debe cumplir el formato siguiente PR-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de clases de presentación. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Lenguaje (campo Language): En este campo se especifica el lenguaje de programación en el que está el artefacto. - Artefacto asociado (Alias): En este campo se especificará el artefacto desde el que se genera el artefacto actual, en este caso, el prototipo de visualización del que procede. - Atributos (dentro de pestaña Details, botón Attributes): La forma de añadir atributos se explica dentro del apartado 4.2 (Figura 15). Recordar que un atributo ha de tener obligatoriamente un nombre, un tipo, una descripción y una cardinalidad.

Página 122 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Operaciones (dentro de pestaña Details, botón Operations): La forma de añadir operaciones se explica dentro del apartado 4.2 (Figura 17). Recordar que una operación ha de tener obligatoriamente un nombre, un alias y una descripción.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los nodos. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Nombre_Clase (valor etiquetado): En este campo se indica el nombre exacto de la clase en la que se implementa. - Paquete (valor etiquetado): En este campo se indica el nombre exacto del paquete con contiene a la clase implementada. - Tecnología (valor etiquetado): En este campo se indica, mediante un desplegable, la tecnología de la clase. Las clases de diseño se pueden conectarse a cualquier otro artefacto del modelo de clases de diseño mediante los enlaces AS (Asociación), que se muestra en la Figura 84. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre el artefacto de origen y arrastrar hasta el artefacto de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Tabla 40. Reglas de Clases de presentación (PR)

Definición de Clases de presentación El nombre del artefacto es PR-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro PR con la misma numeración El nombre del atributo no está vacío El nombre del atributo debe empezar en minúscula, usando la notación CamelCase El tipo del atributo no está vacío El tipo del atributo es un AD, o un atributo de éste La descripción del atributo está rellena El nombre de las operaciones debe empezar en minúscula, usando la notación CamelCase La descripción de la operación está rellena Existe un PR por cada artefacto de navegación, excepto ME Cada atributo del NO está en el PR El tipo del atributo del PR es el AD correspondiente al NO del atributo del CL La cardinalidad del atributo del PR es igual al del NO El lenguaje del PR debe ser un lenguaje de programación válido 12.4. Prototipos de diseño Si es necesario porque no se haya alcanzado con la definición de la interfaz abstracta, en la fase de diseño se puede abordar la elaboración de un prototipo de la aplicación para validar con los responsables del área usuaria.

Página 123 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario Se aconseja partir de los prototipos generados por NDT-Prototypes y modificarlos añadiendo la funcionalidad, requerimientos y necesidades propias del área usuaria. 12.5. Modelo físico de datos Para los sistemas que se fundamenten sobre bases de datos relacionales, será necesario desarrollar el modelo entidad relación. El modelo entidad relación se definirá mediante el diagrama entidad relación y un diccionario de datos que describa cada uno de los elementos que en el diagrama aparecerán. Tabla 41. Reglas de Modelo Físico de Datos

Diseño del Modelo Físico de Datos Debe tener un diagrama de tipo Modelado de datos, con el toolbox Data Modeling Todos los Tables han de estar contenidos en el diagrama Diccionario de datos El nombre del artefacto debe cumplir la nomenclatura específica marcada por el cliente (en caso de Cultura, ORBE) El alias del table es el nombre del CL del que procede El tipo del artefacto es table La descripción está rellena El nombre de los campos no está vacío El tipo de los campos no está vacío El alias de los campos es el nombre del atributo del que procede (CL) La descripción de los campos está rellena

Página 124 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 13. Construcción La fase de construcción simplemente está constituida por los productos resultantes de la implementación de la estructura conceptual definida en las fases anteriores. La estructura de la fase de construcción y su relación con la estructura de paquetes del perfil de NDT se muestra en la Figura 88.

Figura 88. Estructura del la fase de construcción

La fase de construcción se divide, básicamente, en una serie de documentos. Estos documentos se deben adjuntar al archivo EAP tal y como se ha descrito en la sección 5.4. Los documentos de código fuente y script de BBDD no tienen porqué estar rellenos, pero sí deben contener un enlace, o bien a subversión, o bien al archivo correspondiente.

Página 125 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 14. Pruebas del sistema La fase de pruebas, en contraposición con otras fases, se realiza de manera paralela con el resto de fases del ciclo de vida. La estructura del documento de diseño del sistema y su relación con la estructura de paquetes del perfil de NDT se muestra en la Figura 89.

Figura 89. Estructura del DPS

La fase de pruebas se divide, básicamente, en una serie de documentos y en la definición de los artefactos de prueba. Los documentos han de describir el grado de profundidad y alcance de las pruebas, los requerimientos del entorno necesarios para la ejecución de las pruebas, y la planificación temporal de las pruebas. Estos documentos se deben adjuntar al archivo EAP tal y como se ha descrito en la sección 5.4. En una segunda parte, hay que definir tres tipos de artefactos de prueba. Cada artefacto lleva un código identificativo. Los códigos de cada artefacto se muestran en la Tabla 42. Tabla 42. Nomenclatura de Pruebas

Pruebas Pruebas de Implantación Pruebas de Sistemas Pruebas de Aceptación

Nombre PI-XX.Nombre PS-XX.Nombre PA-XX.Nombre

El conjunto de herramientas para la definición de pruebas se muestra a continuación, en la Figura 90.

Página 126 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 90. Artefactos de pruebas

14.1. Pruebas de implantación Las pruebas de implantación están orientadas al Departamento de Sistemas. Definirán las pruebas a realizar una vez implantado el sistema para verificar la implantación. En la Figura 48 se muestra el toolbox definido para modelar las pruebas de implantación como artefactos de tipo PI.

Figura 91. Toolbox para pruebas de implantación

Para crear una prueba de implantación, basta con pinchar sobre el toolbox en el artefacto PI y arrastrar hasta el diagrama donde se quiera modelar. Para obtener más información sobre cómo trabajar con los diagramas de casos de uso, se recomienda leer el apartado 4.1.1 de esta guía, donde se explica cómo han de ser estos diagramas. En la Figura 92 se observa una prueba de implantación modelada como un artefacto de tipo PI y sus propiedades estándares.

Página 127 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 92. Propiedades estándares de una prueba de implantación

Los valores etiquetados de un requisito funcional se muestran en la Figura 93.

Página 128 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 93. Valores etiquetados de una prueba de implantación

En el artefacto PI existen una serie de campos que son obligatorios para que la descripción de la prueba de implantación se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada prueba de sistema debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 42, el nombre debe cumplir el formato siguiente PI-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de pruebas de implantación. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Restricciones (pestaña Constraints): En un requisito funcional se deben definir obligatoriamente restricciones. Éstos han de detallarse en la pestaña Constraints (ya descrita en el apartado 4.2 de esta guía, en la Figura 18) y los tipos que puede tener son precondición y post-condición. Si la funcionalidad no tuviera ninguna restricción, tanto en precondición como en post-condición se dejará claro que no aplica. - Diagrama de actividades o escenarios: Las pruebas han de estar descritos obligatoriamente mediante escenarios o un diagrama de actividades. Ambas opciones están disponibles, la primera mediante la pestaña Scenarios que se observa en la Figura 92 y la segunda haciendo doble clic sobre el prueba. Si la funcionalidad que se quiere describir es compleja se usarán los diagramas de actividades obligatoriamente, que están descritos con más profundidad en el apartado 4.1.2. - Parámetros de entrada (valor etiquetado): Se indicarán aquellos parámetros de entrada que sean necesarios para ejecutar la prueba. - Resultado esperado (valor etiquetado): Se indicará el resultado de salida que se debe obtener para que la prueba se considere satisfactoria. Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los requisitos funcionales. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos.

Página 129 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. Fecha de realización (valor etiquetado): En este campo se podrá indicar la fecha en la que se ha realizado la prueba que modela el artefacto. Resultado de la prueba (valor etiquetado): En este campo se indicará el resultado de salida obtenido en la ejecución de la prueba.

14.2. Pruebas de sistemas Las pruebas de sistema se derivan desde los casos de uso definidos durante la fase de requisitos. Éstas representan las pruebas funcionales a realizar en el sistema. En la Figura 94 se muestra el toolbox definido para modelar las pruebas de sistema como artefactos de tipo PS.

Figura 94. Toolbox para pruebas de sistema

Para crear una prueba de sistema, basta con pinchar sobre el toolbox en el artefacto PS y arrastrar hasta el diagrama donde se quiera modelar. Para obtener más información sobre cómo trabajar con los diagramas de casos de uso, se recomienda leer el apartado 4.1.1 de esta guía, donde se explica cómo han de ser estos diagramas. En la Figura 95 se observa una prueba de sistema modelada como un artefacto de tipo PS y sus propiedades estándares.

Página 130 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 95. Propiedades estándares de una prueba de sistema

Los valores etiquetados de todas las pruebas son idénticos, por lo que son los mismos que se muestran en la Figura 93. En el artefacto PS existen una serie de campos que son obligatorios para que la descripción de la prueba de sistema se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada prueba de sistema debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 42, el nombre debe cumplir el formato siguiente PS-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de pruebas de sistema. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto.

Página 131 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

-

-

Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. Restricciones (pestaña Constraints): En un requisito funcional se deben definir obligatoriamente restricciones. Éstos han de detallarse en la pestaña Constraints (ya descrita en el apartado 4.2 de esta guía, en la Figura 18) y los tipos que puede tener son precondición y post-condición. Si la funcionalidad no tuviera ninguna restricción, tanto en precondición como en post-condición se dejará claro que no aplica. Diagrama de actividades o escenarios: Las pruebas han de estar descritos obligatoriamente mediante escenarios o un diagrama de actividades. Ambas opciones están disponibles, la primera mediante la pestaña Scenarios que se observa en la Figura 92 y la segunda haciendo doble clic sobre el prueba. Si la funcionalidad que se quiere describir es compleja se usarán los diagramas de actividades obligatoriamente, que están descritos con más profundidad en el apartado 4.1.2. Parámetros de entrada (valor etiquetado): Se indicarán aquellos parámetros de entrada que sean necesarios para ejecutar la prueba. Resultado esperado (valor etiquetado): Se indicará el resultado de salida que se debe obtener para que la prueba se considere satisfactoria.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los requisitos funcionales. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. - Fecha de realización (valor etiquetado): En este campo se podrá indicar la fecha en la que se ha realizado la prueba que modela el artefacto. - Resultado de la prueba (valor etiquetado): En este campo se indicará el resultado de salida obtenido en la ejecución de la prueba. Las pruebas de sistema deben definir relaciones de trazabilidad entre los elementos del sistema bajo prueba y los casos de prueba. Por ejemplo, las pruebas del sistema deberán permitir seguir la traza a los requisitos funcionales que se estén probando. Esto se consigue mediante las matrices de trazabilidad (para más información sobre las matrices, ver el apartado 3.2 de esta guía). 14.3. Pruebas de aceptación Las pruebas de aceptación serán un subconjunto de las pruebas de sistema y están orientadas a realizarse por los usuarios finales. En la Figura 96 se muestra el toolbox definido para modelar las pruebas de aceptación como artefactos de tipo PA.

Página 132 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 96. Toolbox para pruebas de aceptación

Para crear una prueba de aceptación, basta con pinchar sobre el toolbox en el artefacto PA y arrastrar hasta el diagrama donde se quiera modelar. Para obtener más información sobre cómo trabajar con los diagramas de casos de uso, se recomienda leer el apartado 4.1.1 de esta guía, donde se explica cómo han de ser estos diagramas. En la Figura 97 se observa una prueba de sistema modelada como un artefacto de tipo PA y sus propiedades estándares.

Página 133 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 97. Propiedades estándares de una prueba de aceptación

Los valores etiquetados de todas las pruebas son idénticos, por lo que son los mismos que se muestran en la Figura 93. En el artefacto PA existen una serie de campos que son obligatorios para que la descripción de la prueba de aceptación se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada prueba de aceptación debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 42, el nombre debe cumplir el formato siguiente PA-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de pruebas de aceptación. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto.

Página 134 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

-

-

Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. Restricciones (pestaña Constraints): En un requisito funcional se deben definir obligatoriamente restricciones. Éstos han de detallarse en la pestaña Constraints (ya descrita en el apartado 4.2 de esta guía, en la Figura 18) y los tipos que puede tener son precondición y post-condición. Si la funcionalidad no tuviera ninguna restricción, tanto en precondición como en post-condición se dejará claro que no aplica. Diagrama de actividades o escenarios: Las pruebas han de estar descritos obligatoriamente mediante escenarios o un diagrama de actividades. Ambas opciones están disponibles, la primera mediante la pestaña Scenarios que se observa en la Figura 92 y la segunda haciendo doble clic sobre el prueba. Si la funcionalidad que se quiere describir es compleja se usarán los diagramas de actividades obligatoriamente, que están descritos con más profundidad en el apartado 4.1.2. Parámetros de entrada (valor etiquetado): Se indicarán aquellos parámetros de entrada que sean necesarios para ejecutar la prueba. Resultado esperado (valor etiquetado): Se indicará el resultado de salida que se debe obtener para que la prueba se considere satisfactoria.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los requisitos funcionales. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. - Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. - Fecha de realización (valor etiquetado): En este campo se podrá indicar la fecha en la que se ha realizado la prueba que modela el artefacto. - Resultado de la prueba (valor etiquetado): En este campo se indicará el resultado de salida obtenido en la ejecución de la prueba.

Tabla 43. Reglas de Pruebas (PI, PS, PA)

Diagrama de Pruebas Cada tipo de prueba debe tener un diagrama de tipo Pruebas de Implantación Todos los PI, PS y PA han de estar contenidos en sus respectivos diagramas Definición de Pruebas El nombre del artefacto es PI-XX(X).Nombre, PS-XX(X).Nombre o PA-XX(X).Nombre El nombre del PI, PS o PA ha de estar en infinitivo El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro prueba con la misma numeración La prueba tiene un diagrama de actividades, o escenarios Los escenarios han de tener nombre y descripción Los escenarios tienen que estar numerados secuencialmente El diagrama de actividad tiene que tener un nodo de inicio, un nodo de fin y, al menos, una actividad Todos los objetos del diagrama de actividades ha de tener nombre Las actividades han de tener un enlace de salida y, al menos, un enlace de entrada

Página 135 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario El nodo de inicio ha de tener un enlace de salida El nodo de fin ha de tener, como mínimo, un enlace de entrada Los enlaces de un nodo de decisión tienen que tener un valor en sus guardas Si la prueba tiene constraints, ha de tener un nombre y una descripción En el diagrama, todas las pruebas tienen asociado un AC, o bien es parte de otra prueba 14.4. Ejecución de las pruebas En este paquete se expondrán los detalles de la ejecución de las pruebas. Las baterías de pruebas representan un conjunto de pruebas (tomadas de los apartados anteriores) realizados por algún participante del proyecto. En la Figura 98 se muestra el toolbox definido para modelar el resultado de la ejecución de pruebas.

Figura 98. Toolbox para la ejecución de pruebas

Para crear una batería de pruebas, basta con pinchar sobre el toolbox en el artefacto Prueba Realizada y arrastrar hasta el diagrama donde se quiera modelar. En la Figura 95 se observa una batería de pruebas modelada como un artefacto de tipo Prueba realizada y sus propiedades estándares.

Página 136 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 99. Propiedades estándares de una batería de pruebas

Los valores etiquetados de todas las pruebas son idénticos, por lo que son los mismos que se muestran en la Figura 99. En el artefacto Prueba Realizada existen una serie de campos que son obligatorios para que la descripción de la batería de pruebas se considere correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada prueba de sistema debe tener un nombre descriptivo. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Fecha Inicio (valor etiquetado): Se indicará la fecha en la que se comienza a ejecutar la batería de pruebas. - Fecha Fin (valor etiquetado): Se indicará la fecha en la que se finaliza la batería de pruebas. - Pruebas Correctas (valor etiquetado): Se indicará el número de pruebas que se han finalizado satisfactoriamente.

Página 137 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

-

Pruebas Incorrectas (valor etiquetado): Se indicará el número de pruebas que no se han finalizado satisfactoriamente. Pruebas Totales (valor etiquetado): Número de pruebas totales que se se han ejecutado en la batería de pruebas. Atributos (dentro de pestaña Details, botón Attributes): La forma de añadir atributos es similar a como se hacen en los Servicios. Del toolbox se arrastra el atributo Prueba al artefacto. En el nombre se indicará el nombre de la prueba. Además, cada atributo tiene dos valores etiquetados más que se describen a continuación. Fecha (valor etiquetado de atributos): Fecha de ejecución de la prueba. Resultado (valor etiquetado de atributos): Se seleccionará de la lista desplegable el resultado que se ha obtenido al ejecutar la prueba.

Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los requisitos funcionales. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos. - Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. Además, las baterías de pruebas deben enlazarse a los participantes del proyecto que las realicen mediante el enlace Realiza (que se muestra en el toolbox de la Figura 98), tomando como origen el participante (que ha de arrastrarse desde el paquete de Participantes) y como destino la batería de pruebas que realice. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía.

Página 138 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 15. Mantenimiento del sistema El proceso de mantenimiento, al contrario de otros procesos que se ejecutan en desarrollo, es un proceso que comienza cuando el proyecto ha pasado a producción y que termina cuando el sistema cae en desuso. La estructura del documento de mantenimiento del sistema se muestra en la Figura 100.

Figura 100. Estructura del DMS

Esta fase consta de la definición de dos tipos de artefactos, Incidencias software y Peticiones de mejora. Tabla 44. Nomenclatura de Mantenimiento

Pruebas Incidencia software Petición de mejora

Nombre IS-XX.Nombre PM-XX.Nombre

Las incidencias software son errores que se detectan durante la ejecución del sistema y que conllevan la detección de un error que contradice el conjunto de requisitos definidos para el sistema. Las peticiones de mejora son propuestas que el usuario puede realizar para mejorar el sistema en cuanto a interfaz, navegabilidad, funcionalidad, etc. El conjunto de herramientas para la definición de artefactos de mantenimiento se muestra a continuación, en la Figura 101.

Página 139 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Figura 101. Toolbox de mantenimiento

Las propiedades estándares son las mismas para los dos tipos de artefactos, que se observan en la Figura 102.

Figura 102. Propiedades estándares de una petición de mantenimiento

Página 140 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario

Los valores etiquetados se muestran a continuación, en la Figura 103.

Figura 103. Valores etiquetados de una petición de mantenimiento

En los artefactos PM e IS existen una serie de campos que son obligatorios para que la descripción de las peticiones e incidencias se consideren correcta. Esta serie de campos son los siguientes: - Nombre (campo Name): Cada menú debe clasificarse con un código y un nombre descriptivo. Tal y como se indica en la Tabla 44, el nombre de las peticiones de mejora debe cumplir el formato siguiente PM-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de peticiones de mejora. En el caso de las incidencias software el nombre debe cumplir el formato siguiente IS-XX.Nombre, siendo XX un número de dos cifras o, excepcionalmente, de tres cifras, en caso de que exista un número elevado de incidencias software. - Autor (campo Author): Este campo recoge el nombre de la empresa o persona de la empresa encargada de definir el artefacto. - Descripción (campo Notes): En este campo se describe, con la profundidad de detalle que el autor estime oportuno, el artefacto que se está tratando. - Tipo (valor etiquetado): Este campo indica el tipo de incidencia que se está tratando. En el caso de las incidencias software, el tipo ha de ser obligatoriamente Correctivo. En el caso de las peticiones de mejora el tipo ha de ser Adaptativo o Aumentativo. - Criticidad (valor etiquetado): Este valor indica el grado de criticidad que tiene la resolución de la incidencia que modela el artefacto dentro del sistema. Debe escogerse uno de los valores predefinidos. Existen, además otros campos que son opcionales, si bien, se recomienda que se cumplimenten para una mejor definición de los menús. Éstos son: - Estado (campo Status): Este campo recoge la situación en la que se encuentra el artefacto en su proceso de desarrollo. El valor se debe seleccionar entre los posibles que se muestran predefinidos.

Página 141 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario -

Versión (campo Version): A través de este campo se gestionan las diferentes versiones del artefacto. Este campo tiene sentido cuando se trata de sistemas grandes en los que la gestión de versiones sea una tarea crítica. Comentarios (valor etiquetado): En este campo se permite al autor del objetivo indicar cualquier otro tipo de información que estime oportuna. Fecha de resolución (valor etiquetado): En este campo se podrá indicar la fecha en la que se ha resuelto la incidencia que modela el artefacto.

Toda incidencia software o petición de mejora debe definir relaciones de trazabilidad con los artefactos afectados. Se deja a criterio del coordinador del proyecto definir si dichos artefactos corresponden a los requisitos, análisis o diseño del sistema. Para ello, las incidencias pueden conectarse a cualquier otro artefacto del proyecto mediante los enlaces Implica a, que se muestra en la Figura 101. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre la incidencia de origen y arrastrar hasta el artefacto de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Además, las incidencias software o peticiones de mejora se pueden enlazar entre ellos mediante los enlaces Procede de, que se muestra en la Figura 101, para indicar que una incidencia se crea para complementar otra incidencia. Para hacer uso de este conector, basta con pinchar sobre él en el toolbox, pinchar sobre la incidencia de origen y arrastrar hasta la incidencia de destino en el diagrama. Una vez creada la línea que modela el conector, si se quieren editar sus propiedades, habría que hacer doble clic sobre el conector, pasando a la pantalla de propiedades que se describe en el apartado 4.3 de esta guía. Una vez definidas las incidencias software, se debe crear una subcarpeta en 1.2. DEFINICIÓN DE INCIDENCIAS SOFTWARE con el nombre “1.2..Nombre del artefacto”. Dentro de esa carpeta se deberán arrastrar todos aquellos artefactos que son necesarios de modificar o crear para resolver dicha incidencia. Al igual, una vez definidas las peticiones de mejora, se debe crear una subcarpeta en 2.2. DEFINICIÓN DE PETICIONES DE MEJORA con el nombre “2.2..Nombre del artefacto”. Dentro de esa carpeta se deberán arrastrar todos aquellos artefactos que son necesarios de modificar o crear para satisfacer dicha petición. Tabla 45. Reglas de Mantenimiento (IS, PM)

Diagrama de Mantenimiento Debe tener un diagrama de tipo Mantenimiento Todos los IS y PM han de estar contenidos en sus respectivos diagramas Solo puede tener enlaces Procede de o Implica a Definición de Mantenimiento El nombre del artefacto es IS-XX(X).Nombre o PM-XX(X).Nombre El nombre del artefacto debe usar la notación CamelCase, empezando en mayúscula La descripción está rellena No existe ningún otro IS o PM con la misma numeración

Página 142 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 16. Generar documentación Para facilitar la tarea de redactar un documento para cada una de las principales fases del ciclo de vida de un proyecto software, NDT-Profile 2.X proporciona un conjunto de plantillas diseñadas en Enterprise Architect. Las fases del ciclo de vida para las que disponemos de esta funcionalidad son: la fase de Requisitos, la fase de Análisis, la fase de Diseño, y la fase de Pruebas del Sistema. Para cada una de estas fases, existe en NDT-Profile un paquete denominado DOCUMENTACIÓN en donde se encuentra diseñado el documento maestro. Gracias a este conjunto de plantillas, Enterprise Architect permite generar de manera totalmente automática un documento estructurado con toda la información recogida en cada una de las fases del ciclo de vida mencionadas anteriormente. A continuación, se mostrará el procedimiento para obtener el documento asociado a la fase de Requisitos. Para el resto de fases, el procedimiento sería totalmente análogo. 1- Una vez abierto el proyecto creado en base a la herramienta NDT-Profile 2.X, abrir el diagrama lógico situado en el paquete /DRS/4. DOCUMENTACIÓN/:

Figura 104: Master Document DRS

Página 143 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 2- A continuación, seleccionamos el Master Document Documentación DRS visualizado en el diagrama anterior. 3- Nos dirigimos a Proyect > Documentation > Ritch Text Format (RTF) Report. (Alternativamente, puede pulsar F8) para abrir la ventana de opciones:

Figura 105. Ventana de opciones generación de documentación en EA

4- Indicar dónde guardar el documento de salida y pulsar sobre el botón Generate.

Página 144 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Manual de Usuario 17. Reparar y Compactar el fichero EAP Si estamos utilizando el fichero EAP y no estamos trabajando sobre proyecto en un servidor de datos, necesitaremos realizar varios pasos para que nuestro proyecto esté lo más seguro posible. Debido a que cuando estamos trabajando con el Enterprise Architect se va generando mucha información basura que hace que nuestro fichero tenga un gran tamaño, tenemos que ir haciendo regularmente dos operaciones que serían:  Repair .EAP File.  Compact .EAP File Ambas operaciones están dentro del menú Tools -> Manage .EAP File, tal y como se muestra en la Figura 106.

Figura 106. Compactar ficheros EAP

Página 145 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Glosario 18. Glosario A continuación se indican los términos utilizados, en el presente documento. Tabla 46. Glosario

Término Enterprise Architect CASE NDT

Descripción Enterprise Architect Computer Aided Software Engineering Navigational Development Techniques

Página 146 de 147

Proyecto NDT-Suite 2.X User guide and best practices for NDT-Profile 2.X Anexo 19. Bibliografía y referencias A continuación se indican referencias bibliográficas relevantes. Tabla 47. Bibliografía

Referencia NDT http://www.iwt2.org

Título

Código No

Página 147 de 147