Capitulo 5

Evaluacin de Arquitecturas de
Software

Contenido
Introduccin
Tipos de evaluacin
Cualitativa
Cuantitativa

Expedientes de escenarios
Mtodos de evaluacin

Basada en escenarios
Simulacin
Modelo matemtico
Basado en experiencia
2

Introduccin
La idea principal de la metodologa en estudio es
que los atributos de calidad de un sistema puedan
ser evaluados explcitamente durante el diseo
arquitectnico.
Tradicionalmente se implementa el sistema y
despus se evala. El problema es que no existe un
sistema implementado para ser evaluado.
Se propone evaluar el diseo y cuando cumpla
con los requisitos establecidos implementarlo.
3

Introduccin
Como puede medirse una especificacin
abstracta??
La meta de este capitulo es:
Evaluar el potencial de la arquitectura
diseada para alcanzar los niveles
requeridos en los atributos de calidad.
Ejemplo
Rendimiento NO usar Blackboard
Flexibilidad Usar Blackboard
4

Introduccin
La evaluacin de una arquitectura tiene
como meta:
Satisfacer los atributos de calidad
Satisfacer a los clientes
Proveer soporte para una lnea de
productos
La evaluacin puede ser absoluta o relativa
5

Evaluacin de
Arquitectura

Orientado a la
Arquitectura

Clientes

Expertos

Enfoque en
atributos de calidad

Cualitativo
(comparacin)

Cuantitativo
(prediccin)
6

Tipos de Evaluacin
Evaluacin cualitativa
Evaluacin cuantitativa
Evaluacin de valores
mximos-mnimos
7

Evaluacin Cualitativa
Las tcnicas de evaluacin cualitativas descansan
sobre el conocimiento que los arquitectos han
acumulado con la experiencia en la solucin de
ciertos tipos de problemas.
Evaluacin por pares
Patrones
Conocimiento estadstico, etc.

Este conocimiento es inexplcito y generalmente

no esta documentado en las organizaciones
8

Formas de evaluacin cualitativa

Asignar diseadores experimentados al proyecto.
Diseadores experimentados son escasos y el
conocimiento es propio

Ingeniera 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
9

Evaluacin Cualitativa
Ejemplo: Comparar dos arquitecturas
relativamente a un atributo de calidad
establecido.
Desventaja: La respuesta de la evaluacin es
boolena: A1 es mejor que A2 o viceversa.
La comparacin podra ser relativa a mas de un
atributo de calidad. Pero que pasa si las
respuestas son contradictorias?
10

Evaluacin Cuantitativa
Las tcnicas de evaluacin cuantitativa miden las
propiedades de un sistema; es difcil usarlas
durante el proceso de desarrollo debido a que la
informacin 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 ao.
Si podemos generar estimaciones verdicas entonces
podemos tomar mejores decisiones seleccionando la
mejor arquitectura.
11

Evaluacin Cuantitativa
Las estimaciones mejoraran al mismo
tiempo que el sistema se disea
Estas mejoraran considerablemente cuando
el sistema se implemente
NOTA IMPORTANTE: una estimacin
debe consistir de un valor estimado
acompaado por un estimado de su
beneficio
12

Evaluacin de un valor mximo

(mnimo) terico de un atributo de
calidad
En la fase de diseo de la arquitectura no hay
forma de determinar los valores mximos
(rendimiento) o mnimos (tiempo de repuesta)
tericos 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.
13

Tipos de Evaluacin
La evaluacin cuantitativa es mas costosa
que la cualitativa.
La evaluacin cuantitativa no es exacta.
(predice)
La evaluacin cualitativa tiende a ser mas
usada. (costo-beneficio)

14

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 fciles 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 explcitamente.
15

Expedientes
Posiblemente los usuarios/clientes no saben/pueden
especificar los atributos de calidad explcitamente
(e.g. Confiabilidad = 0.9999) pero usando su
imaginacin, 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.
16

Tipos de Expedientes
Expedientes de Cambios (Mantenimiento)
Expedientes de Uso
(Eficiencia/Rendimiento, Confiabilidad)
Expedientes de Peligro (Seguridad)

17

Expedientes
Este mtodo expande la idea de desarrollar
casos de uso para especificar el
comportamiento esperado del sistema.
Los casos de uso sern usados para
caracterizar el rendimiento del sistema, e.g.
Cual es el tiempo de respuesta esperado
para un escenario especfico?
18

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.
19

Expedientes de Escenarios
Expediente completo

vs

Seleccin de escenarios

GUI

...

App

GUI
App

...
HW

...
OS

HW OS

20

Expedientes Completos o
Seleccin
Un expediente completo es aquel que contiene
todos los escenarios concernientes a un atributo
de calidad.
A menos que el sistema sea demasiado pequeo,
el nmero de escenarios ser demasiado grande
como para ser desarrollado completamente.
Ejemplo: En un expediente de mantenimiento,
como se podran anticipar todos los escenarios
de cambios futuros?
21

Expedientes Completos o
Seleccin
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 investigacin)
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 tcnicas grupales e.g. FMEA).
22

FMEA Failure Modes and Effects Analysis

Definiendo Expedientes
La definicin de expedientes se puede
realizar de dos formas
Bottom-up
Top-down

23

Definiendo Expedientes Bottom-up

1.
2.
3.
4.

Entrevistar a los clientes

Categorizar los escenarios
Asignar pesos a los escenarios
Iterar estos pasos hasta cubrir los aspectos
mas relevantes del sistema

24

Definiendo Expedientes Top-down

1. Definir categoras de escenarios:

Particionar los escenarios en un nmero de

subgrupos basados en alguna caracterstica
del grupo.
Ejemplo: agrupar los casos de uso en base a
los actores identificados.
Tratar de identificar de 4 a 8 categoras en
cada expediente.
25

Definiendo Expedientes Top-down

2. Seleccin y definicin de escenarios para
cada categora:

Una vez que se han agrupado los escenarios

en subgrupos debe ser mas fcil seleccionar
los escenarios mas representativos.
Producir hasta 10 escenarios por expediente.

26

Definiendo Expedientes Top-down

3. Asignar peso a cada escenario (usar datos
histricos o estimados).

Para los casos de uso, el peso representa la frecuencia

de ejecucin de cada escenario.
Para escenarios de Mantenimiento, el peso representa
la probabilidad de que ese escenario ocurra.
Seleccionar un esquema de asignacin 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 fcilmente interpretados)
27

QFD (Quality Function Deployment)

Definiendo Expedientes
Formas de asignar pesos:
Individual (arquitecto)
Grupal (el equipo de diseo en sesin
interactiva)
Grupal previa. Cada miembro prepara
individualmente y en reunin grupal se define
el peso de cada escenario

28

Expedientes de Atributo de
Calidad
Los atributos de calidad pueden ser
definidos en:

Rendimiento/ Eficiencia
Mantenimiento
Confiabilidad
Seguridad externa
Seguridad en los datos
29

Expedientes de
Atributo de Calidad
Rendimiento/ Eficiencia.- Medir la
eficiencia del sistema en ejecucin:

rendimiento, nmero de escenarios por unidad de

tiempo
tiempo de respuesta de un escenario especifico.

Arquitecturas pobremente diseadas causan

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

30

Rendimiento/ Eficiencia
Categoras.- Se encuentran descomponiendo los escenarios
de uso en tipos de usuarios (actores) y/o interfaces del sistema.

Pesos.- representa la frecuencia de ejecucin del escenario.

Informacin para la Descripcin de la Arquitectura
Comportamiento del sistema para cada escenario
El tiempo promedio (y peor caso) de retraso en cada
componente del sistema.
Usar datos histricos

31

Expedientes de Atributo de
Calidad
Confiabilidad.- Es una funcin de diferentes

factores (arquitectura, diseo detallado, implementacin,

experiencia, etc).

- La confiabilidad de la arquitectura se basa en la

interaccin de los componentes durante la
ejecucin y los efectos de los errores en el sistema.
- Los escenarios de uso que atraviesan varios
componentes tendrn menor confiabilidad que
aquellos que usan uno solo.
32

Expedientes de Atributo de
Calidad
Confiabilidad
- Expediente.- Los escenarios de uso se evalan
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.
- Informacin de la descripcin de la arquitectura
- Se requiere informacin de la confiabilidad de los
componentes (datos histricos o estimaciones por
experiencia).
33

Expedientes de Atributo de
Calidad
Seguridad Externa
Evala los efectos negativos o destructivos del
sistema. No se relaciona con la funcionalidad del
sistema sino con los efectos en el mundo real.
- Efectos fsicos
- 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.
34

Expedientes de Atributo de Calidad

Seguridad Externa
- Expediente de daos / peligro.- Describen

situaciones en las que NO detectar una falla puede traer

consecuencias negativas o desastrosas.
- Categoras.- Se organizan de acuerdo a documentos
certificados, los puntos de interaccin del sistema con el
mundo real o componentes crticos los cuales al fallar,
pueden provocar situaciones de peligro.

- Informacin de la descripcin de la arquitectura

- Seguridad se usa en sistemas embebidos
- Seguridad del software se deriva de la seguridad del
sistema.
35

Expedientes de Atributo de
Calidad
Seguridad en los datos
- Intento de alterar partes del sistema
- Informacin secreta o confidencial no disponible a
usuarios no autorizados.

- Disponibilidad.- Negar el servicio ante ataques.

- Sistemas militares, negocios, gobierno deben
mantener su informacin disponible solo para
usuarios autorizados.
36

Expedientes de Atributo de Calidad

Seguridad en los datos
Expediente que contiene los aspectos que sern
evaluados.
Ejemplo: Acceso a informacin secreta
Interno
No intencional

Externo

(intento de acceso
No autorizado)

Intencional

- Categoras.- Usar todas las interfaces del sistema

- Informacin de la descripcin de la arquitectura.Depende del aspecto a ser evaluado (Disponible/
Confidencial / Integridad)

37

Expedientes de Atributo de
Calidad
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 categoras:

Identificar los cambios de categoras 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.

38

Mantenimiento
Informacin para la Descripcin de la Arquitectura.
Los escenarios de cambios se evalan respecto al impacto
que provocan en la arquitectura.
El impacto se calcula en trminos de LOC que deben
cambiarse.
Debe estimarse el nmero de LOC de cada componente
del sistema para realizar la evaluacin del atributo de
mantenimiento.
LOC: Lines of code.
39

Ejemplo
Category
Market Driven
Hardware
Hardware
Hardware
Safety
Medical 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 patients digital journal.
(0.043)
Change controlling algorithm for concentration of dialysis fluid from PI
to PID. (0.132)
40

Ejemplo
Pg.. 90
Categoras:

Enfocadas al Mercado
Hardware
Regulaciones de seguridad
Avances mdicos en la ciencia
Comunicacin y E/S
Implementacin de algoritmos
41

Resumen de Expedientes
Crear un expediente para cada atributo de calidad
Definir dos conjuntos de escenarios
Para diseo (completos)
Para evaluacin (parciales)

Definir las categoras de los escenarios (4 a 6)

Definir escenarios para cada categora ( max. 10)
Asignar pesos (frecuencia, probabilidad, etc.)
Normalizar los pesos
42

Cuatro Mtodos de Evaluacin

1.
2.
3.
4.

Basada en escenarios
Basada en simulacin
Basada en un modelo matemtico
Basada en la experiencia

43

Basada en Escenarios
Este mtodo depende directamente de el expediente
definido para el atributo de calidad que ser
evaluado.
La efectividad de la evaluacin depende de que la
seleccin de escenarios sea representativa. Si los
escenarios no son representativos del mundo real, el
mtodo puede resultar sospechoso.
44

Basada en Escenarios
Expediente de
escenarios

Arquitectura de
Software
Anlisis
Anlisisde
de
Impacto
Impacto

Resultados de
la Evaluacin

Puntos Problema
De la
Arquitectura

Prediccin
Prediccinde
de
Atributos
de
Atributos de
Calidad
Calidad

Valores de QA
45

Basada en Escenarios
Anlisis de Impacto:
Evala el impacto de cada escenario en la arquitectura.
Para escenarios de cambios:
Cuantos componentes requieren modificacin?
Cuantos componentes nuevos se requieren?
Cuantas lneas de cdigo (nuevas/modificadas)?

Para escenarios de rendimiento:

Ejecutando el escenario a travs de los componentes: Cual es el
tiempo de ejecucin por componente y cual es el tiempo de
sincronizacin entre componentes?

Recolecta y totaliza los resultados

46

Basada en Escenarios
Prediccin de Atributos de Calidad usando los
resultados del anlisis de impacto.
Para mantenimiento:
Predecir el esfuerzo requerido en promedio para
mantenimiento usando como medida el nmero de lneas de
cdigo 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

nmero de transacciones
47

Ejemplo. Sistema de Dilisis

Proceso artificial para remover agua y otros elementos de
la sangre de un paciente con problemas en los riones.
Definicin de categoras:

Enfocadas al Mercado
Hardware
Regulaciones de seguridad
Avances mdicos en la ciencia
Comunicacin y E/S
Implementacin de algoritmos

Definicin (seleccin) de escenarios por categora.

Asignacin de pesos y normalizacin.
Resumen del expediente de mantenimiento (tabla)
48

Basada
en
Escenarios
Tabla de Expediente de cambios para mantenimiento
Categora

Peso

P Norm.

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

tratamiento

0.043

Hardware

C2 Agregar segunda bomba y un sensor de conductividad

0.043

Hardware

C3 reemplazar bombas de sangre usando revoluciones por minuto

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

0.087

Hardware

C4 Reemplazar controlador de calor con uno de interfase digital

usando % de efecto total

0.174

Seguridad

C5 Agregar alma para detectar reversin de flujo

0.087

Avances mdicos

C6 modificar tratamiento de curva de peso lineal sobre el tiempo

a logaritmo inverso

0.217

Avances mdicos

C7 cambia alarma de limites fijos de flujo a tratamiento

0.087

Avances mdicos

C8 Agregar sensor y alarma para pacientes con presin sangunea

0.087

Com. e I/O

C9 Agregar funcin para actualizar datos del tratamiento en el diario

digital del paciente

0.043

Algoritmos

C10 cambiar algoritmo controlador para concentracin de fluido de

PI a PID

0.132

23

1.0

Enfocadas al
Mercado

Descripcin del escenario

Suma

Arquitectura del sistema

Interfase Hombre-Mquina

Sistema de Control

Sistema de Proteccin

Hardware API
Nota: Los componentes no vienen en el libro.

IHM.- Responsable
de presentar
interfaces y alarmas
al usuario.
SC.- configuracin
del sistema para
operacin y
monitoreo.
SP.- Detecta
situaciones que
ponen en riesgo al
paciente e inicia
procesos para
regresar a un estado
50
seguro.

Tamao de componentes
Componente

LOC

HDFTreatment

200

ConcentrationDevice

100

ConcCtrl

175

Acetate Pump and Conductivity Sensor

100

HaemoDialysisMachines

500

Fluidheater

100

AlarmDetectorDevice

100

Basada en Escenarios
Tabla de Anlisis de Impacto de cada escenario en la arquitectura
Escenario

Componenetes Afectados

C1

HDFTreatment (20% cambio) + nuevo componente

Normaliser type

C2

ConcentrationDevice (20% cambio) + ConcCtrl (50%

cambio) + reuso de Acetate Pump and Conductivity
Sensor con 10% modificacion c/u

C3

HaemoDialysisMachines (10% cambio) + new

AlarmHandler + new AlarmDevice

C4

Fluidheater (10% cambio) remove DutyCycleControl and

replace with reused SetCtrl

C5

HDFTreatment (50% cambio)

C6

AlarmDetectorDevice (50% cambio) HDFTreatment

(20% cambio) + HaemoDialysisMachines (20% cambio)

C7

See C3

C8

New ControllingAlgorithm + new Normalizer

C9

HDFTreatment (20% cambio) + HaemoDialysisMachines

(50% cambio)

C10

Replacement with new ControllingAlgorithm

Volumen
0.2 * 200 + 20 = 60
0.2 * 100 + 0.5 *175 + 0.1 * 100 +
0.1 * 100 = 127.5
0.1 * 500 + 200 + 100 = 350
0.1 * 100 = 10
0.5 * 200 = 100
0.5 * 100 + 0.2 * 200 + 0.2 * 500 =190
= 350
100 + 20 = 120
0.2 * 200 + 0.5 * 500 = 290
52
= 100

Usando las tablas anteriores es posible calcular el

nmero promedio de LOC para cada escenario.
Peso normalizado del escenario * LOC afectadas
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 LOC

en promedio

Clculo del esfuerzo de mantenimiento

-Asumiendo 20 requerimientos de cambio por ao y 1
LOC por hora de trabajo
20 (req.) * 145 (LOC por req.) / 1 (LOC por hora) =
2900 horas de trabajo en un ao

Cuantas personas se requieren

para realizar el mantenimiento?

53

Requerimientos

LOC x
Req

LOC x
hora

Prediccin

20

145

2900

20

145

1450

20

145

580

20

145

10

290

20

145

20

145

Que significa la prediccin?

Evaluacin 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 tcnicas son mejores.
55

Evaluacin Basada en Escenarios

La evaluacin consiste de dos pasos:
Anlisis del impacto: toma la arquitectura y el
expediente como entrada y genera datos que
representan el impacto de cada escenario.
Prediccin de atributo de calidad: Usa los
datos generados en el paso anterior para hacer
declaraciones a cerca del nivel del atributo de
calidad.
56

Basada en Simulacin
Implementacin de la arquitectura en un
prototipo
Contexto de simulacin abstracto
Evaluacin con la ejecucin de escenarios
Ejemplo
rendimiento
confiabilidad
57

Basada en Simulacin- Proceso

Define e implementa el contexto del sistema
Implementacin abstracta de los
componentes de la arquitectura
Implementacin de los expedientes
Simulacin del sistema con los escenarios
Recolecta resultados y predice atributos de
calidad
Identifica errores de funcionalidad
58

Simulacin de un proceso de inspeccin de latas

Ejemplo

instantiate

measurement
item

trigger

getvalue(5x)

actuate

trigger

update(10x)
actuate
trigger

trigger

59

 La prediccin del atributo de calidad

depende de:
El expediente usado para la simulacin
La implementacin del contexto
La relacin entre la arquitectura usada en la
simulacin y la arquitectura real

60

Basada en un Modelo
Matemtico
Modela la arquitectura usando
aproximaciones
Anlisis esttico por clculos
Relacin con otras tcnicas de evaluacin
ejemplo
Modelado de rendimiento
Modelado de tareas en tiempo real
61

Modelo Matemtico - Proceso

1. Selecciona el modelo matemtico abstracto
adecuado (sistemas en tiempo real, alto rendimiento, etc.)
2. Representa la arquitectura en trminos del modelo
3. Estima los datos requeridos de entrada
4. Calcula la salida del modelo e interpreta resultados
5. Prediccin de atributos de calidad, obtn una
conclusin
6. Escribe lista de problemas de la arquitectura
62

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

Figure 3: A customized user interface runs a Mathematical Model of FSW to analyze

various materials and configurations.
63

Basado en Experiencia
Especialmente para ingenieros de software
experimentados
Argumentos lgicos guan el razonamiento
Base para otras tcnicas
Equipos de ingenieros para evaluacin de
arquitecturas

64

Satisfaccin de Clientes
Reunin despus del diseo arquitectnico (usuarios
finales, clientes, operadores, implementadores, etc.)
Cada grupo define sus escenarios principales
Mezcla de los escenarios y creacin de un
subconjunto
Discusin de escenarios (max. 20) para solucionar
conflictos
Si los conflictos permanecen, el diseo de la
arquitectura se rechaza , sino se continua con el
desarrollo
65

Lneas de Productos de Software

Meta: determinar la capacidad de la arquitectura
para soportar todos los productos de una familia
Mtodos de evaluacin:
Evaluacin por contexto
Evaluacin por cada miembro de la familia de
productos
Evaluacin por los sistemas mas importantes

Evaluacin para futuros miembros de la familia

66

Conclusin
Especificacin de
Requerimientos

Arquitectura de
Software

Diagrama de
Contexto

Requerimientos
Funcionales

Arquetipos
Prioridad

Interfase

Relacin

Estructura

Componentes
Requerimientos de
Calidad

Relacin

Expediente
de escenarios

Decisin de
Diseo
Resultados de
Evaluacin

67