Tarea: Requisitos no funcionales de servicio de documentos
Esta tarea define y especifica los servicios y la estructura de una solución orientada a servicios desde el punto de vista de las colaboraciones de elementos de diseño contenidos y subsistemas/interfaces externos.
Objetivo
  • Definir los servicios y la estructura de una solución orientada a servicios desde el punto de vista de las colaboraciones de elementos de diseño contenidos y subsistemas/interfaces externos.
  • Analizar el servicio para encontrar puntos en común y variabilidad (consulte Directriz: Análisis de variabilidad).
  • Documentar la especificación de servicios.
  • Determinar las dependencias y la comunicación entre los servicios.
Relaciones
Descripción principal
Esta tarea ajusta el conjunto de Artefactos: Especificación de servicio identificados y calificados durante la Actividad: Identificar servicios y ofrece detalles y estructuras adicionales. Este detalle de nivel de diseño incluye servicios de interfaz, mensaje y composición, y la asignación de servicios a los proveedores.
Pasos
Documentar requisitos no funcionales

El uso de la arquitectura orientada a servicios ofrece la oportunidad de elegir un Artefacto: Proveedor de servicios basado no sólo en la funcionalidad que proporciona sino en las Calidades de servicio (QoS) que puede garantizar. Uno de los motivos para cambiar un proveedor de servicio puede a menudo ser resultado de un cambio en los requisitos no funcionales, necesitándose un nuevo nivel de QoS no actualmente soportado por un proveedor existente. También puede derivar de la degradación de la QoS esperada por el cliente de servicio. Una arquitectura orientada a servicios permite esta agilidad a menor coste, en general, que otros estilos arquitectónicos.

La calidad de servicio se puede observar desde dos perspectivas: la del proveedor y la del cliente. El proveedor de servicios garantiza proporcionar y mantener una calidad de servicio para cada uno de sus servicios o grupo de servicios. El cliente de servicio, por otro lado, "compara" las calidades de servicio deseadas y elige un proveedor según éstas. También es importante observar que en valores comerciales en los que el cliente y el proveedor entran en un contrato legal sobre el uso del servicio, estas garantías de calidad de servicio se ejemplifican en acuerdos de nivel de servicio, frecuentemente con penas asociadas con el no cumplimiento de un proveedor de dichos acuerdos.

Por tanto, es muy importante especificar claramente los requisitos no funcionales necesarios para el cliente (por ejemplo, coste de transacción, rendimiento, disponibilidad, seguridad, etc.) de un servicio o un conjunto de servicios. En esta tarea de Especificación de servicio, identificamos requisitos no funcionales para la QoS deseada. Los requisitos no funcionales se utilizarán para asignar recursos para componentes de servicio que ofrecen los servicios y para financiar la realización y el mantenimiento de componentes de servicio que garanticen la entrega de la QoS a lo largo del tiempo. Deberán tomarse decisiones clave sobre arquitectura para garantizar que se conseguirá la calidad de servicio prometida basada en requisitos no funcionales.

La forma en que los requisitos no funcionales se relacionan con el Artefacto: Especificación de servicio no se define en esta directriz. No hay límites establecidos en lo que constituye dicho requisito, obviamente QoS, la seguridad se ha mencionado anteriormente, entre los ejemplos están:

  • Disponibilidad (por ejemplo, tiempo medio entre anomalías)
  • Ventana operativa (¿hay algún tiempo en el que no espere utilizar este servicio?)
  • Tiempo de respuesta (¿con qué rapidez responde el servicio a una solicitud?)
  • Rendimiento en hora punta (¿cuántas solicitudes de servicio pueden producirse por unidad de tiempo, por ejemplo , por segundo, por minuto, por hora?)
Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información