Artefacto: Especificación de servicio
Este artefacto es un elemento de modelo que proporciona la especificación estructural y de comportamiento para una instancia de servicio. Una especificación de servicio también puede identificar un conjunto de políticas que controlan el acceso a un servicio o el uso de dicho servicio. Esta especificación actúa como un contrato entre el cliente de servicio y el implementador de servicio; el cliente entiende cómo interactuar con un servicio y el implementador entiende el comportamiento esperado de la implementación.
Clases de producto de trabajo: Elemento de modelo
Objetivo

Las siguientes personas utilizan la interfaz de servicio:

  • Implementadores de los servicios, para un entendimiento de la interfaz que proporciona el servicio, pero también el comportamiento que esperan sus clientes.
  • Implementadores de clientes de servicio, para un entendimiento de la interfaz que el servicio proporciona, pero también la forma con la que el servicio espera interactuar.
  • Diseñadores de servicios, en la comprensión de la relación entre especificaciones y la relación entre servicios y especificaciones que implementan.
  • Aquellos que diseñan la siguiente versión del sistema, para entender las funciones del modelo de servicio.
  • Aquellos que prueban las clases, para planificar tareas de prueba.

La especificación de servicio debe proporcionar al proveedor (implementador) de un servicio y al cliente de un servicio una especificación razonable y completa de los siguientes aspectos:

  • Especificación de interfaz; especifica el conjunto de operaciones suministradas por un servicio que realiza esta especificación. Cada operación tiene nombre y proporciona una firma compuesta de mensajes de entrada, salida y excepción.
  • Especificación de comportamiento; especifica el protocolo entre el servicio y el cliente. Un servicio puede ser con estado (implícito o explícito; véase la directriz Gestión de estado para servicios) o puede tener determinados requisitos conversacionales cumplidos por el cliente.
  • Especificación de política; especifica restricciones y políticas relativas al funcionamiento del servicio. Algunos ejemplos de políticas son la seguridad (consulte Tarea: Identificar patrones de seguridad), la disponibilidad, la calidad de servicio, etc.; estos ejemplos también representan requisitos no funcionales de la solución como un todo.
  • Especificación de variabilidad; especifica cómo se configura el servicio en caso de despliegue y cómo puede dar soporte a guiones de uso genéricos a través de la variabilidad en su comportamiento tanto dinámicamente (mensajes en el tiempo de ejecución) y estáticamente (mediante de parámetros de configuración).
Relaciones
Artefacto del contenedor
RolesResponsable: Modificado por:
TareasEntrada a: Salida de:
Descripción
Descripción principal

El uso de una interfaz indica un conjunto de operaciones proporcionadas por un servicio. Observe que un servicio puede implementar más de una interfaz. Por convención, es posible adjuntar una máquina de estado de protocolo o Colaboración UML 2.0 a dicha especificación para indicar el orden de invocación de las operaciones en una especificación de servicio. Con tal especificación de comportamiento, cualquier servicio de implementación se puede validar no sólo frente a la especificación estática sino dinámica de su estructura y comportamiento.

El uso de una clase permite que una especificación señale directamente un conjunto de funcionalidades necesarias, así como proporcionarlas como unidad completa.

Observe que la especificación de servicio sólo puede proporcionar funciones públicas. La posibilidad de incluir propiedades en una especificación de servicio permite el modelado de recursos.

La especificación tiene una propiedad "estado" que se utiliza para representar un concepto común entre las metodologías de arquitectura orientada a servicios; la de un ciclo de vida distinto para descripciones de servicio. En el perfil se utiliza una enumeración para capturar estos valores comunes, tal como aparece a continuación.

  • Candidato (valor predeterminado):  señala que la especificación de servicio se ha creado a partir de alguna tarea de identificación pero todavía no ha sido aceptada formalmente. La aceptación puede incluir el traslado de determinadas pruebas (SOMA), la alineación con la cartera de servicios empresariales (RUP/SOA), etc. 
  • Aceptado: señala que un servicio se ha movido desde un estado candidato a aceptado, aunque esto simplemente entraña que el servicio se desarrollará, el ámbito del servicio deberá todavía determinarse.
  • Expuesto: señala que el servicio deberá exponerse fuera de su ámbito inmediato. Esto implica que el servicio se vuelva disponible para su reutilización, no especificar el ámbito particular, no deberá leerse como "público en Internet", por ejemplo.

Igualmente, la propiedad "origen" permite al diseñador indicar qué técnica o dominio de origen se ha utilizado para identificar este servicio. Consulte Tarea: Análisis de procesos empresariales, Tarea: Análisis de modelo de datos, Tarea: Análisis de activos existentes, Tarea: Análisis de reglas empresariales y Tarea: Análisis de guiones de uso empresariales (SOA).

Personalización
Opciones de representaciónRepresentación UML:

Interfaz o Clase, estereotipada como <<Especificación de servicio>>. Una especificación debería también proporcionar una máquina de estado de protocolo o colaboración que documente su especificación de comportamiento.

Propiedades:

  • status : SpecificationStatus; indica una especificación de servicio como servicio candidato, es decir, un servicio que se ha identificado pero que todavía no se ha calificado para desarrollo.
  • source : Serie; esta propiedad se utiliza para capturar el "método" o la técnica utilizados para identificar la especificación de servicio.

Cuando se utiliza una clase como representación para una especificación de servicio, la clase NO debería incluir ningún comportamiento.


Más información