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 |
|
Roles | Responsable:
| Modificado por:
|
Tareas | Entrada 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ón | Representació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
© Copyright IBM Corp. 1987, 2006. Reservados todos los derechos.
|
|