Artefactos EA: nomenclatura, contenido y relaciones

El estereotipo a usar para cada tipo de elemento es el que aparece indicado en la primera fila de la tabla correspondiente. Por ejemplo, `Participante (estereotipo "Participante")'. Ese es el tipo de elemento que debe seleccionarse (de la "Toolbox" correspondiente) para crear el elemento.

Aunque no se indique explícitamente en la normativa, cualquier tipo de elemento se puede agrupar por subsistemas, utilizando para la nomenclatura de dichos elementos los dos niveles de numeración (YYY-XXX, donde YYY corresponde al subsistema y XXX al elemento en cuestión). En la normativa se indica en aquellos en los que es aconsejable (siempre y cuando existan subsistemas), pero se pueden usar ambas alternativas en cualquier tipo de elemento, agruparlos por subsistemas (YYY-XXX) o no (XXX).

Con carácter general para todos los estereotipos usados en los aplicativos software, las relaciones a incluir deben ser únicamente las descritas en esta normativa. La inclusión de otro tipo de relaciones puede dar lugar a errores a la hora de generar la documentación asociada o al exportar la información a otras herramientas. Si bien en cada uno de los estereotipos se describen las relaciones que debe tener con el resto, en caso de duda, en el apartado correspondiente a las matrices de trazabilidad se puede consultar la obligatoriedad de cada una de las relaciones, en la tabla con las comprobaciones a realizar (aquellas relaciones que no aparezcan en la tabla no son obligatorias).

No deberán embeberse unos elementos del modelado dentro de otros, salvo en los casos contemplados en la normativa, como puede ser el caso de los procesos de negocio asociados a casos de uso concretos.

En todos los elementos modelados, pero sobre todo en las clases y tablas, existen muchos más campos en cada uno de los estereotipos correspondientes además de los que aparecen en este documento. Es recomendable, aunque no vayan a ser revisados o incluidos en la documentación asociada, incluir la mayor cantidad de información posible, y cuanto más detallada mejor, puesto que será de gran ayuda tanto a la hora de consultar la información en el futuro como por ejemplo para generar código fuente o scripts de manera automática.

Por último el campo estado debe cumplimentarse conforme a las siguientes instrucciones:

• Propuesto (Proposed): Cuando se trate de un elemento de nueva creación, que ha sufrido cambios desde la anterior entrega, o que en la anterior entrega no fue aprobado, en definitiva, cuando se trate de un elemento a revisar.
• Aprobado (Approved): Una vez revisada la entrega, aquellos elementos que se encuentren en el estado propuesto y que no presenten carencias ni errores deberán actualizar el valor del campo estado pasando de propuesto a aprobado (este estado aprobado será el que presenten en la siguiente entrega salvo que sufran cambios, en dicho caso deberán volver a aparecer en el estado propuesto).
• N/A (no aplica): Se utilizará este valor para especificar diferentes circunstancias. Los elementos con este valor en el campo estado, salvo excepciones concretas en determinados proyectos, no serán tenidos en cuenta en la revisión. Es conveniente en estos elementos indicar en la descripción el motivo por el que están en ese estado. Para distinguir el motivo por el que están en el estado N/A se deberá seleccionar según dicho motivo uno de los siguientes valores disponibles:
  • N/A - Borrado logico. Para indicar que un elemento no debe tenerse en cuenta porque se ha prescindido de él, pero sin eliminarse del modelado, para poder consultarlo a modo de histórico.
  • N/A - Borrador. Para indicar que el elemento está en borrador, ya que realmente pertenece a futuras entregas.
  • N/A - Previo normativa. Para indicar que se trata de elementos ya existentes antes de la aplicación de la normativa, y que por tanto no la cumplen (ya sea total o parcialmente).
  • N/A. En los casos de prueba de integración predefinidos se usará este valor en el caso de que para el aplicativo en cuestión no aplique la realización de ese caso de prueba de integración predefinido. También se utilizará cuando el motivo sea uno distinto a los recogidos en los anteriores puntos y para mantener la compatibilidad con las entregas realizadas basadas en versiones anteriores a la v01r09 de la normativa, en las cuales sólo se contemplaba este valor genérico para el N/A.

Participante

Objetivo del Sistema 

Requisito Funcional 

Requisito de Integración

Requisito no Funcional 

Requisito de Información 

Subsistema 

Actor 

Sistema 

Caso de Uso 

Pantalla 

Informe 

Interface 

Clase 

Tabla 

Caso de Prueba 

Caso de Prueba de Integración 

La forma de trabajar con los casos de prueba predefinidos es la siguiente:

• Los casos de prueba correspondientes a MACO y a BDU son genéricos, no están asociados a un servicio concreto como ocurre con los correspondientes al ESB, y deben ejecutarse siempre (en caso de que no apliquen debe modificarse su estado indicando "N/A"). Estos casos de prueba no deben eliminarse ni modificarse (ni siquiera su nomenclatura que es específica), salvo para añadir las relaciones con las interfaces de servicio que deban ser probadas por cada uno de ellos            así como el resultado de las pruebas llevadas a cabo por el proveedor. 
• Los casos de prueba asociados al ESB y a los servicios REST deben ejecutarse todos ellos para cada uno de los servicios incluidos en los interfaces existentes (los del ESB en todos los servicios SOAP, excepto MACO y BDU, y los REST en todos los servicios REST). En este caso los casos de prueba se han incluido a modo de plantilla, para cada servicio deberán crearse los casos de prueba correspondientes a partir de los predefinidos ya existentes (los predefinidos incluidos a modo de plantilla no deben modificarse ni eliminarse). En estos casos de prueba específicos para cada uno de los servicios creados a partir de los casos de prueba predefinidos se deberán hacer los siguientes cambios:
  • Cambiar su estado a "Proposed".
  • En su descripción sustituir "[INDICAR SERVICIO]" por el nombre del servicio correspondiente.
  • Cambiar su nombre (y su alias) de acuerdo a la nomenclatura correspondiente a los casos de prueba de integración. Por ejemplo:

CPI-ESB1 - Mensaje correcto -> CPI001 - Mensaje correcto SERVICIO1

             CPI002 - Mensaje correcto SERVICIO2

          -

• Se debe añadir la relación con la interface de servicio a la que pertenece el servicio a probar. 

• Si es necesario añadir más casos de prueba además de los predefinidos (tanto para MACO y BDU como para ESB y REST) se crearán siguiendo las indicaciones anteriores y ajustándose a la nomenclatura y al formato descritos en la tabla que las precede.

Caso de Prueba Funcional de Interoperabilidad 

Excepción