1 Capitulo 5 Evaluación de Arquitecturas de Software.

1

Capitulo 5Evaluación de Arquitecturas de

Software

2

Contenido

• Introducción• Tipos de evaluación

– Cualitativa– Cuantitativa

• Expedientes de escenarios• Métodos de evaluación

– Basada en escenarios– Simulación– Modelo matemático– Basado en experiencia

3

Introducción

• La idea principal de la metodología en estudio es que los atributos de calidad de un sistema puedan ser evaluados explícitamente durante el diseño arquitectónico.

• Tradicionalmente se implementa el sistema y después se evalúa. El problema es que no existe un sistema implementado para ser evaluado.

• Se propone evaluar el diseño y cuando cumpla con los requisitos establecidos implementarlo.

4

Introducción

• Como puede medirse una especificación abstracta??

• La meta de este capitulo es:

Evaluar el potencial de la arquitectura diseñada para alcanzar los niveles requeridos en los atributos de calidad.

• Ejemplo– Rendimiento – NO usar Blackboard– Flexibilidad – Usar Blackboard

5

Introducción

• La evaluación de una arquitectura tiene como meta:

– Satisfacer los atributos de calidad

– Satisfacer a los clientes

– Proveer soporte para una línea de productos

• La evaluación puede ser absoluta o relativa

6

Evaluación de Arquitectura

Orientado a la Arquitectura

Enfoque en atributos de calidad

Clientes ExpertosCualitativo

(comparación)Cuantitativo(predicción)

7

Tipos de Evaluación

• Evaluación cualitativa

• Evaluación cuantitativa

• Evaluación de valores máximos-mínimos

8

Evaluación Cualitativa

• Las técnicas de evaluación cualitativas descansan sobre el conocimiento que los arquitectos han acumulado con la experiencia en la solución de ciertos tipos de problemas.– Evaluación por pares

– Patrones

– Conocimiento estadístico, etc.

• Este conocimiento es inexplícito y generalmente no esta documentado en las organizaciones

9

Formas de evaluación cualitativa

• Asignar diseñadores experimentados al proyecto.– Diseñadores experimentados son escasos y el

conocimiento es propio

• Ingeniería de conocimiento. – Capturar en documentos el conocimiento de los

ingenieros

• Inteligencia artificial.– El conocimiento cualitativo se captura para construir

herramientas inteligentes que asistan al personal menos experimentado

10

Evaluación Cualitativa

• Ejemplo: Comparar dos arquitecturas relativamente a un atributo de calidad establecido.

• Desventaja: La respuesta de la evaluación es boolena: A1 es mejor que A2 o viceversa.

• La comparación podría ser relativa a mas de un atributo de calidad. Pero que pasa si las respuestas son contradictorias?

11

Evaluación Cuantitativa

• Las técnicas de evaluación cuantitativa miden las propiedades de un sistema; es difícil usarlas durante el proceso de desarrollo debido a que la información del proyecto es incompleta

• Ejemplo: Se requiere evaluar el rendimiento (transacciones/segundo) de un sistema o el tiempo promedio de respuesta (segundos/transacciones) o estimar el costo de mantenimiento por año.– Si podemos generar estimaciones verídicas entonces

podemos tomar mejores decisiones seleccionando la mejor arquitectura.

12

Evaluación Cuantitativa

• Las estimaciones mejoraran al mismo tiempo que el sistema se diseña

• Estas mejoraran considerablemente cuando el sistema se implemente

• NOTA IMPORTANTE: una estimación debe consistir de un valor estimado acompañado por un estimado de su beneficio

13

Evaluación de un valor máximo (mínimo) teórico de un atributo de

calidad

• En la fase de diseño de la arquitectura no hay forma de determinar los valores máximos (rendimiento) o mínimos (tiempo de repuesta) teóricos que el sistema podrá alcanzar.

• Se debe monitorear el sistema en su desarrollo para modificar la arquitectura o renegociar los valores de los atributos de calidad.

14

Tipos de Evaluación

• La evaluación cuantitativa es mas costosa que la cualitativa.

• La evaluación cuantitativa no es exacta. (predice)

• La evaluación cualitativa tiende a ser mas usada. (costo-beneficio)

15

Expedientes de Escenarios

• Problema: Generalmente los requisitos de calidad se omiten o se especifican pobremente en los requerimientos de los clientes.– Las interfaces deben ser fáciles de usar.

– El sistema debe ser capaz de soportar una carga alta de trabajo.

• Para evaluar la arquitectura cuantitativamente con respecto a sus atributos de calidad, estos deben ser especificados explícitamente.

16

Expedientes

• Posiblemente los usuarios/clientes no saben/pueden especificar los atributos de calidad explícitamente (e.g. Confiabilidad = 0.9999) pero usando su imaginación, describen de manera general el funcionamiento del sistema.

• Esto nos da un conjunto de escenarios para un atributo de calidad en particular, los cuales constituyen un expediente.

• A cada escenario de un expediente se le asigna una importancia relativa.

17

Tipos de Expedientes

• Expedientes de Cambios (Mantenimiento)

• Expedientes de Uso (Eficiencia/Rendimiento, Confiabilidad)

• Expedientes de Peligro (Seguridad)

18

Expedientes

• Este método expande la idea de desarrollar casos de uso para especificar el comportamiento esperado del sistema.

• Los casos de uso serán usados para caracterizar el rendimiento del sistema, e.g. Cual es el tiempo de respuesta esperado para un escenario específico?

19

Expedientes

• El problema es que muchos escenarios caen fuera de los casos de uso normales.

• Ejemplo: Situaciones de peligro para especificar requerimientos de seguridad o escenarios de cambios a futuro para especificar requerimientos de mantenibilidad.

20

Expedientes de Escenarios

Expediente completo vs Selección de escenarios

HW OS

GUI

App

...

...

HW OS

GUI

App

...

21

Expedientes Completos o Selección

• Un expediente completo es aquel que contiene todos los escenarios concernientes a un atributo de calidad.– A menos que el sistema sea demasiado

pequeño, el número de escenarios será demasiado grande como para ser desarrollado completamente.

– Ejemplo: En un expediente de mantenimiento, como se podrían anticipar todos los escenarios de cambios futuros?

22

Expedientes Completos o Selección

• Si se decide usar un conjunto de escenarios seleccionados, entonces habrá otros problemas:– Para que el conjunto sea representativo, los escenarios

deben seleccionarse aleatoriamente del conjunto completo. (experimentos en investigación)

– Debemos confiar en que el arquitecto tiene la experiencia para seleccionar los escenarios que formaran parte del expediente y que reflejen al expediente completo. (Esto puede realizarse usando algunas técnicas grupales e.g. FMEA).

FMEA Failure Modes and Effects Analysis

23

Definiendo Expedientes

• La definición de expedientes se puede realizar de dos formas– Bottom-up– Top-down

24

Definiendo Expedientes Bottom-up

1. Entrevistar a los clientes

2. Categorizar los escenarios

3. Asignar pesos a los escenarios

4. Iterar estos pasos hasta cubrir los aspectos mas relevantes del sistema

25

Definiendo Expedientes Top-down

1. Definir categorías de escenarios:– Particionar los escenarios en un número de

subgrupos basados en alguna característica del grupo.

– Ejemplo: agrupar los casos de uso en base a los actores identificados.

– Tratar de identificar de 4 a 8 categorías en cada expediente.

26


2. Selección y definición de escenarios para cada categoría:

– Una vez que se han agrupado los escenarios en subgrupos debe ser mas fácil seleccionar los escenarios mas representativos.

– Producir hasta 10 escenarios por expediente.

27


3. Asignar peso a cada escenario (usar datos históricos o estimados).

– Para los casos de uso, el peso representa la frecuencia de ejecución de cada escenario.

– Para escenarios de Mantenimiento, el peso representa la probabilidad de que ese escenario ocurra.

– Seleccionar un esquema de asignación de pesos, 1 a 10, 1 a 100, (--,-,0,+,++), (1,3,9) como en QFD.

– Normalizar pesos. Una vez que los pesos se han asignado, suma todos los pesos y divide cada peso individual por la suma. (los pesos deben sumar 1 y pueden ser fácilmente interpretados)

QFD (Quality Function Deployment)

28

Definiendo Expedientes

• Formas de asignar pesos:– Individual (arquitecto)– Grupal (el equipo de diseño en sesión

interactiva)– Grupal previa. Cada miembro prepara

individualmente y en reunión grupal se define el peso de cada escenario

29

Expedientes de Atributo de Calidad

• Los atributos de calidad pueden ser definidos en:– Rendimiento/ Eficiencia– Mantenimiento– Confiabilidad– Seguridad externa– Seguridad en los datos

30


• Rendimiento/ Eficiencia.- Medir la eficiencia del sistema en ejecución:– rendimiento, número de escenarios por unidad de

tiempo– tiempo de respuesta de un escenario especifico.

• Arquitecturas pobremente diseñadas causan “cuellos de botella”.

• Expediente: Describe el conjunto de escenarios funcionales de una instancia especifica para uno de los usuarios.

31

Rendimiento/ Eficiencia

• Categorías.- Se encuentran descomponiendo los escenarios de uso en tipos de usuarios (actores) y/o interfaces del sistema.

• Pesos.- representa la frecuencia de ejecución del escenario.

• Información para la Descripción de la Arquitectura– Comportamiento del sistema para cada escenario

– El tiempo promedio (y peor caso) de retraso en cada componente del sistema.

– Usar datos históricos

32


• Confiabilidad.- Es una función de diferentes factores (arquitectura, diseño detallado, implementación, experiencia, etc).

- La confiabilidad de la arquitectura se basa en la interacción de los componentes durante la ejecución y los efectos de los errores en el sistema.

- Los escenarios de uso que atraviesan varios componentes tendrán menor confiabilidad que aquellos que usan uno solo.

33


• Confiabilidad- Expediente.- Los escenarios de uso se evalúan

respecto a la confiabilidad del componente.- Peso.- Los pesos asociados a cada escenario y la

confiabilidad de los componentes permiten calcular la confiabilidad del sistema.

- Información de la descripción de la arquitectura- Se requiere información de la confiabilidad de los

componentes (datos históricos o estimaciones por experiencia).

34


• Seguridad ExternaEvalúa los efectos negativos o destructivos del sistema. No se relaciona con la funcionalidad del sistema sino con los efectos en el mundo real.

- Efectos físicos- La maquina no detecta burbujas de aire en la sangre.- El sistema bancario realiza transacciones incorrectas.

- Se deben detectar errores internos y errores en los datos de entrada.

35

Expedientes de Atributo de Calidad• Seguridad Externa- Expediente de daños / peligro.- Describen

situaciones en las que NO detectar una falla puede traer consecuencias negativas o desastrosas.

- Categorías.- Se organizan de acuerdo a documentos certificados, los puntos de interacción del sistema con el mundo real o componentes críticos los cuales al fallar, pueden provocar situaciones de peligro.

- Información de la descripción de la arquitectura- Seguridad se usa en sistemas embebidos- Seguridad del software se deriva de la seguridad del

sistema.

36


• Seguridad en los datos- Intento de alterar partes del sistema

- Información secreta o confidencial no disponible a usuarios no autorizados.

- Disponibilidad.- Negar el servicio ante ataques.- Sistemas militares, negocios, gobierno deben

mantener su información disponible solo para usuarios autorizados.

37

Expedientes de Atributo de Calidad• Seguridad en los datos Expediente que contiene los aspectos que serán

evaluados. Ejemplo: Acceso a información secreta

Interno Externo (intento de acceso No autorizado)No intencional

Intencional

- Categorías.- Usar todas las interfaces del sistema

- Información de la descripción de la arquitectura.- Depende del aspecto a ser evaluado (Disponible/ Confidencial / Integridad)

38


• Mantenimiento. La meta es absorber los requerimientos de cambios sin modificar la arquitectura.

• Cambios con impacto en la arquitectura son prohibitivos.

• Expediente. Dos tipos de categorías:– Identificar los cambios de categorías con base en interfaces e

identificar pesos con base en la estabilidad de cada interfase. (hardware, SO, interfaces con otros sistemas, interfase de usuario)

– Cambios en escenarios. Describen cambios en el funcionamiento del sistema.

• Peso.- Indica la probabilidad de que el cambio ocurra en un periodo de tiempo.

39

Mantenimiento

• Información para la Descripción de la Arquitectura.– Los escenarios de cambios se evalúan respecto al impacto

que provocan en la arquitectura.

– El impacto se calcula en términos de LOC que deben cambiarse.

– Debe estimarse el número de LOC de cada componente del sistema para realizar la evaluación del atributo de mantenimiento.

LOC: Lines of code.

40

EjemploCategoryMarket Driven

HardwareHardware

Hardware

SafetyMedical Adv.

Medical Adv.Medical Adv.Com.and I/O

Algorithms

Scenario Description (Weight)Change measurement units from Celsius to Fahrenheit for temperature in

a treatment. (0.043)Add second concentrate pump and conductivity sensor. (0.043)Replace blood pumps using revolutions per minute with pumps using

actual flow rate (ml/s). (0.087)Replace duty-cycle controlled heater with digitally interfaced heater

using percent of full effect. (0.174)Add alarm for reversed flow through membrane. (0.087)Modify treatment from linear weight loss curve over time to inverse

logarithmic. (0.217)Change alarm from fixed flow limits to follow treatment. (0.087)Add sensor and alarm for patient blood pressure (0.087)Add function for uploading treatment data to patient’s digital journal.

(0.043)Change controlling algorithm for concentration of dialysis fluid from PI

to PID. (0.132)

41

Ejemplo

• Pág.. 90• Categorías:

– Enfocadas al Mercado– Hardware– Regulaciones de seguridad– Avances médicos en la ciencia– Comunicación y E/S– Implementación de algoritmos

42

Resumen de Expedientes

• Crear un expediente para cada atributo de calidad• Definir dos conjuntos de escenarios

– Para diseño (completos)– Para evaluación (parciales)

• Definir las categorías de los escenarios (4 a 6)• Definir escenarios para cada categoría ( max. 10)• Asignar pesos (frecuencia, probabilidad, etc.)• Normalizar los pesos

43

Cuatro Métodos de Evaluación

1. Basada en escenarios

2. Basada en simulación

3. Basada en un modelo matemático

4. Basada en la experiencia

44

Basada en Escenarios

• Este método depende directamente de el expediente definido para el atributo de calidad que será evaluado.

• La efectividad de la evaluación depende de que la selección de escenarios sea representativa. Si los escenarios no son representativos del mundo real, el método puede resultar “sospechoso”.

45


Expediente de escenarios

Análisis deImpacto

Análisis deImpacto

Puntos Problema De la

Arquitectura

Resultados de la Evaluación

Predicción de Atributos de

Calidad

Predicción de Atributos de

Calidad

Valores de QA

Arquitectura de Software

46


• Análisis de Impacto:– Evalúa el impacto de cada escenario en la arquitectura.

• Para escenarios de cambios:– Cuantos componentes requieren modificación?

– Cuantos componentes nuevos se requieren?

– Cuantas líneas de código (nuevas/modificadas)?

• Para escenarios de rendimiento:– Ejecutando el escenario a través de los componentes: Cual es el

tiempo de ejecución por componente y cual es el tiempo de sincronización entre componentes?

– Recolecta y totaliza los resultados

47


• Predicción de Atributos de Calidad usando los resultados del análisis de impacto.– Para mantenimiento:

• Predecir el esfuerzo requerido en promedio para mantenimiento usando como medida el número de líneas de código o las horas de trabajo.

• Calcular el costo de mantenimiento (numero de horas de trabajo para cada LOC * Total LOC)

– Para rendimiento: predecir el tiempo de respuesta o el número de transacciones

48

Ejemplo. Sistema de Diálisis

• Proceso artificial para remover agua y otros elementos de la sangre de un paciente con problemas en los riñones.

• Definición de categorías:– Enfocadas al Mercado– Hardware– Regulaciones de seguridad– Avances médicos en la ciencia– Comunicación y E/S– Implementación de algoritmos

• Definición (selección) de escenarios por categoría.• Asignación de pesos y normalización.• Resumen del expediente de mantenimiento (tabla)


Categoría Descripción del escenario Peso P Norm.

Enfocadas al Mercado

C1 Cambia medida de temperatura de grados Celsius a Fahrenheit en el 1 tratamiento

0.043

Hardware C2 Agregar segunda bomba y un sensor de conductividad 1 0.043

Hardware C3 reemplazar bombas de sangre usando revoluciones por minuto 2

con bombas usando tasa de flujo actual (ml/s)

0.087

Hardware C4 Reemplazar controlador de calor con uno de interfase digital 4

usando % de efecto total

0.174

Seguridad C5 Agregar alma para detectar reversión de flujo 2 0.087

Avances médicos C6 modificar tratamiento de curva de peso lineal sobre el tiempo 5

a logaritmo inverso

0.217

Avances médicos C7 cambia alarma de limites fijos de flujo a tratamiento 2 0.087

Avances médicos C8 Agregar sensor y alarma para pacientes con presión sanguínea 2 0.087

Com. e I/O C9 Agregar función para actualizar datos del tratamiento en el diario 1

digital del paciente

0.043

Algoritmos C10 cambiar algoritmo controlador para concentración de fluido de 3

PI a PID

0.132

Tabla de Expediente de cambios para mantenimiento

Suma 23 1.0

50

Arquitectura del sistema

Interfase Hombre-Máquina

Hardware API

Sistema de Control Sistema de Protección

IHM.- Responsable de presentar interfaces y alarmas al usuario.

SC.- configuración del sistema para operación y monitoreo.

SP.- Detecta situaciones que ponen en riesgo al paciente e inicia procesos para regresar a un estado seguro.Nota: Los componentes no vienen en el libro.

Tamaño de componentes

Componente LOC

HDFTreatment 200

ConcentrationDevice 100

ConcCtrl 175

Acetate Pump and Conductivity Sensor 100

HaemoDialysisMachines 500

Fluidheater 100

AlarmDetectorDevice 100

52

Basada en EscenariosTabla de Análisis de Impacto de cada escenario en la arquitectura

Escenario Componenetes Afectados Volumen

C1 HDFTreatment (20% cambio) + nuevo componente Normaliser type

0.2 * 200 + 20 = 60

C2 ConcentrationDevice (20% cambio) + ConcCtrl (50% cambio) + reuso de Acetate Pump and Conductivity Sensor con 10% modificacion c/u

0.2 * 100 + 0.5 *175 + 0.1 * 100 +

0.1 * 100 = 127.5

C3 HaemoDialysisMachines (10% cambio) + new AlarmHandler + new AlarmDevice

0.1 * 500 + 200 + 100 = 350

C4 Fluidheater (10% cambio) remove DutyCycleControl and replace with reused SetCtrl

0.1 * 100 = 10

C5 HDFTreatment (50% cambio) 0.5 * 200 = 100

C6 AlarmDetectorDevice (50% cambio) HDFTreatment (20% cambio) + HaemoDialysisMachines (20% cambio)

0.5 * 100 + 0.2 * 200 + 0.2 * 500 =190

C7 See C3 = 350

C8 New ControllingAlgorithm + new Normalizer 100 + 20 = 120

C9 HDFTreatment (20% cambio) + HaemoDialysisMachines (50% cambio)

0.2 * 200 + 0.5 * 500 = 290

C10 Replacement with new ControllingAlgorithm = 100

53

Usando las tablas anteriores es posible calcular el número promedio de LOC para cada escenario.

0.043*60 + 0.043*127.5 +0.087*350 +0.174* 10 +0.087*100 +0.217*190 +0.087*350 +0.087*120 +0.043*290 +0.132*100

Cambios 145 LOCen promedio

Peso normalizado del escenario * LOC afectadas

Cálculo del esfuerzo de mantenimiento-Asumiendo 20 requerimientos de cambio por año y 1 LOC por hora de trabajo

20 (req.) * 145 (LOC por req.) / 1 (LOC por hora) =2900 horas de trabajo en un año

Cuantas personas se requieren para realizar el mantenimiento?

RequerimientosLOC x Req

LOC x hora Predicción

20 145 1 2900

20 145 2 1450

20 145 5 580

20 145 10 290

20 145 20 145

Que significa la predicción?

55

Evaluación basada en escenarios

• Puede usarse para comparar dos o mas arquitecturas cualitativamente, en este caso no es necesario cuantificar el impacto solo estimar usando alguna escala (--,-,+,++) y totalizar.

• Es buena para evaluar atributos de calidad de desarrollo. Para atributos operacionales otras técnicas son mejores.

56

Evaluación Basada en Escenarios

• La evaluación consiste de dos pasos: – Análisis del impacto: toma la arquitectura y el

expediente como entrada y genera datos que representan el impacto de cada escenario.

– Predicción de atributo de calidad: Usa los datos generados en el paso anterior para hacer declaraciones a cerca del nivel del atributo de calidad.

57

Basada en Simulación

• Implementación de la arquitectura en un prototipo

• Contexto de simulación abstracto

• Evaluación con la ejecución de escenarios

• Ejemplo– rendimiento– confiabilidad

58

Basada en Simulación- Proceso

• Define e implementa el contexto del sistema

• Implementación abstracta de los componentes de la arquitectura

• Implementación de los expedientes

• Simulación del sistema con los escenarios

• Recolecta resultados y predice atributos de calidad

• Identifica errores de funcionalidad

59

measurementitem

trigger

trigger

triggerinstantiate

get value (5x)

update (10x)

actuate

actuate

trigger

Ejemplo Simulación de un proceso de inspección de latas

• La predicción del atributo de calidad depende de:– El expediente usado para la simulación– La implementación del contexto– La relación entre la arquitectura usada en la

simulación y la arquitectura real

60

61

Basada en un Modelo Matemático

• Modela la arquitectura usando aproximaciones

• Análisis estático por cálculos

• Relación con otras técnicas de evaluación

• ejemplo– Modelado de rendimiento– Modelado de tareas en tiempo real

62

Modelo Matemático - Proceso

1. Selecciona el modelo matemático abstracto adecuado (sistemas en tiempo real, alto rendimiento, etc.)

2. Representa la arquitectura en términos del modelo

3. Estima los datos requeridos de entrada

4. Calcula la salida del modelo e interpreta resultados

5. Predicción de atributos de calidad, obtén una conclusión

6. Escribe lista de problemas de la arquitectura

Assessing the Friction Stir Welding Process With Mathematical Modeling

Dr. Paul Colegrove, Cranfield University, United Kingdom, and COMSOL, Inc, Burlington, Massachusetts

Saturday, September 01 2007

63

Figure 3: A customized user interface runs a Mathematical Model of FSW to analyze various materials and configurations.

64

Basado en Experiencia

• Especialmente para ingenieros de software experimentados

• Argumentos lógicos guían el razonamiento

• Base para otras técnicas

• Equipos de ingenieros para evaluación de arquitecturas

65

Satisfacción de Clientes

• Reunión después del diseño arquitectónico (usuarios finales, clientes, operadores, implementadores, etc.)

• Cada grupo define sus escenarios principales• Mezcla de los escenarios y creación de un

subconjunto• Discusión de escenarios (max. 20) para solucionar

conflictos• Si los conflictos permanecen, el diseño de la

arquitectura se rechaza , sino se continua con el desarrollo

66

Líneas de Productos de Software

• Meta: determinar la capacidad de la arquitectura para soportar todos los productos de una familia

• Métodos de evaluación:– Evaluación por contexto

– Evaluación por cada miembro de la familia de productos

– Evaluación por los sistemas mas importantes

• Evaluación para futuros miembros de la familia

67

Conclusión

Prioridad

Arquitectura deSoftware

Especificación deRequerimientos

Resultados de Evaluación

Requerimientos deCalidad

RequerimientosFuncionales

Expediente de escenarios

Diagrama deContexto

Interfase

Arquetipos Relación

Componentes

Relación

Decisión de Diseño

Estructura

1 Capitulo 5 Evaluación de Arquitecturas de Software.

Documents

Transcript of 1 Capitulo 5 Evaluación de Arquitecturas de Software.