Introducción
Como parte del proceso de análisis, el arquitecto desarrolla un diagrama de localidad inicial. La vista de localidad es
una síntesis de consideraciones no funcionales y proporciona un contexto para ver cómo se tratan los requisitos no
funcionales como la fiabilidad y la capacidad.
La práctica estándar de ingeniería permite preparar el presupuesto de capacidad, la frecuencia de errores permitida,
etc. Este esfuerzo tiene como resultado un conjunto de requisitos suplementarios derivados para cada elemento de
localidad. Estos requisitos determinan las características de la localidad. Las características y los requisitos
derivados se vuelven a visitar cuando se determina y se perfecciona el particionado de los subsistemas (en
localidades).
Los requisitos suplementarios del nivel de sistema también afectan a los subsistemas (hardware, software, personas),
con las características del subsistema, junto con las características de localidad, que se combinan para obtener las
características del sistema deseadas.
Calidad de las medidas de servicio
La calidad del servicio (QoS) es una noción que incluye aspectos de los requisitos no funcionales. La lista de estas
características es potencialmente larga, incluye muchas "capacidades" como fiabilidad, mantenimiento y utilización, y
posiblemente especialidades de ingeniería completas, como seguridad, factores humanos y etc. Los problemas importantes
de especialidades de ingeniería suelen tratarlos expertos de estas disciplinas. Los problemas que suelen recaer sobre
el ingeniero de software y del sistema son los que están relacionados con:
-
Rendimiento: eficacia, en el tiempo, con que el sistema realiza sus funciones; es decir, capacidad de respuesta,
rendimiento, satisfacción de horas límite.
-
Fiabilidad/tolerancia a errores: durante cuanto tiempo puede seguir el sistema realizando las funciones necesarias
antes de que se produzca un error y cómo sobrelleva los errores parciales. El sistema Tiempo medio entre errores
(MTBF) es una medida de fiabilidad.
-
Mantenimiento: con qué facilidad se puede mantener el sistema en ejecución, así como diagnosticar y arreglar
problemas del sistema. El sistema Tiempo medio de reparación (MTTR) es una medida de mantenimiento.
Antes de construir el sistema, el ingeniero del sistema debe basarse a menudo en modelos del sistema para definir
soluciones alternativas y la asignación y creación de presupuesto de los requisitos no funcionales. Estos modelos se
analizan para ver si satisfacen la calidad deseada de los niveles de servicio y, después, se puede seleccionar una
solución (normalmente, con el coste como factor). Este tipo de estudios de mercado son importantes en el diseño
de sistemas en todos los niveles de perfeccionamiento. La síntesis de las soluciones candidatas depende en gran medida
de la capacidad y la experiencia del arquitecto. El análisis de estas soluciones (a través del modelado matemático, la
simulación, etc.) debería ser relativamente mecánico. Aún así, la fiabilidad de estos análisis variará
considerablemente en función de la viabilidad de los datos de entrada y la fidelidad de los modelos.
Hay disponible un conjunto de técnicas para que el análisis de modelos con respecto a las medidas de QoS que se
enumeran más arriba sea tratable; por ejemplo, el análisis de ritmo monotónico para el examen del rendimiento de los
sistemas de software incorporados en tiempo real [véase Klein, M. H., et al. A Practitioners' Handbook for Real-Time
Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993], y Análisis de
Modos de Fallo, Efectos y Criticidad (FMECA), para la caracterización y la identificación de riesgos de seguridad y
errores de hardware [véase Kececioglu, Dimitri, Reliability Engineering Handbook, Vol. 2, PTR Prentice Hall, 1991].
Se está añadiendo soporte para estos tipos de análisis en UML mediante el suministro de perfiles, señaladamente el
"UML Profile for Schedulability, Performance, and Time Specification" y el "UML Profile for Modeling Quality
of Service and Fault Tolerance Characteristics and Mechanisms". Estos perfiles (disponibles en www.omg.org) definen anotaciones para modelos UML que permiten
analizarlos en busca de las características definidas en el perfil, y las predicciones cuantitativas respecto a estas
características, mediante la utilización de varias herramientas y técnicas de análisis de modelos existentes y futuras.
|