ARQUITECTURA DE SOFTWARE Y ATRIBUTOS DE CALIDAD

Implicancias de la Definicin
2

La arquitectura es una abstraccin del sistema. Los sistema pueden tener y tienen una estructura. Todo sistema tiene una arquitectura. Tener una arquitectura no es lo mismo que tener una arquitectura conocida por todos. Si no se desarrolla la arquitectura explcitamente, se obtendr una de todas formas, pero puede no gustarnos lo que obtenemos!

Por qu es importante la Arquitectura?

3

Representa las decisiones de diseo ms tempranas

lo ms difcil de cambiar lo ms difcil de tener correcto vehculo de comunicacin entre los interesados se ocupa de performance, modificabilidad, confiabilidad, seguridad transferible, abstraccin reutilizable

Es el primer artefacto de diseo

Esencial para la reutilizacin sistemtica

Una buena arquitectura sienta las bases para un sistema exitoso Una mala arquitectura generalmente provoca alguna forma de desastre

Los Requisitos Determinan el Diseo

Variadas formas de requisitos

Conocimiento disponible

Sistema

Cmara

Sensores

Host

Sistema de Visin

Controlador

Arquitectura Arquitecto

Motores

Desarrollo de Sistemas de Software

Requisitos funcionales del software

Si todo lo que importara fuese la funcionalidad, cualquier software monoltico servira, ... pero otras cosas tambin importan

Los atributos de calidad del software y su caracterizacin son esenciales.

Modificabilidad Interoperabilidad Disponibilidad Seguridad Predictabilidad Portabilidad ...

Manejadores de atributos de calidad

Arquitectura del software

Software

tiene estas cualidades

Arquitectura y Funcionalidad
6

La funcionalidad es en gran medida ortogonal a los requisitos de calidad:

la

funcionalidad es la capacidad del sistema de hacer lo que se pretenda que hiciese; los sistemas se descomponen en elementos para lograr variados propsitos, ms all de la funcionalidad:
las

opciones de arquitectura promueven ciertas cualidades al tiempo que implementan la funcionalidad deseada.

Desafos
8

Qu significan con precisin atributos de calidad tales como modificabilidad, seguridad, performance y confiabilidad? Cmo se estructura el sistema de modo que tenga estas cualidades deseadas? Se puede analizar el sistema para determinar si tiene estas cualidades? Cun temprano puede realizarse este anlisis? Cmo se sabe si una arquitectura de software es apropiada para un sistema sin tener que construir el sistema primero?

Realidad sobre Arquitectura de Software

Los requisitos de atributos de calidad son las principales guas para el diseo de la arquitectura. La medida en que un sistema alcance sus requisitos de atributos de calidad depende de las decisiones de arquitectura. El desarrollo requiere ser guiado por las decisiones de arquitectura.

Influencia de los Interesados

10

Administrador de la organizacin desarrolladora

Encargado de marketing

Usuario final

Encargado de mantenimiento

Cliente

Bajos costos, ocupar personal, aumentar el valor de los activos corporativos

Elementos atractivos, terminar rpido, comparable a la competencia

Comportamiento, performance, seguridad, confiabilidad, usabilidad

Modificabilidad

Bajos costos, terminar rpido, sin muchos cambios

Arquitecto

Cmo puedo hacer para que el sistema tenga todo esto?

Interesados Involucrados
11

Los objetivos organizacionales y las propiedades del sistema requeridos por el negocio raramente se comprenden y menos an se articulan completamente. Los requisitos de calidad del cliente casi nunca se documentan, lo cual resulta en:
objetivos

que no se alcanzan; conflicto inevitable entre los interesados.

Interesados Involucrados
12

Los arquitectos deben identificar e involucrar activamente a los interesados de modo de:
comprender

las restricciones reales del sistema; administrar las expectativas de los interesados; negociar las prioridades del sistema; tomar decisiones de compromiso.

Arquitectura de Software - Introduccin

Desarrollo de Software Tradicional

Descripciones operacionales Requisitos funcionales de alto nivel Sistemas legados

ocurre un milagro

Los atributos de calidad rara vez se capturan como parte de la especificacin de requisitos; generalmente son slo vagamente comprendidos; frecuentemente pobremente articulados

Arquitectura de sistema especfico Arquitectura del software Diseo detallado Implementacin

Arquitectura y Atributos de Calidad

14

Un sistema puede evaluarse de dos formas para comprobar que cumple sus atributos de calidad:
atributos
Cmo

observables mediante la ejecucin:

se comporta el sistema durante la ejecucin? los resultados esperados?

Entrega Los

entrega en un tiempo razonable? los resultados una precisin tolerable?

Tienen Se

comporta apropiadamente al interactuar con otros sistemas?

Arquitectura y Atributos de Calidad

15

atributos
Cun

no observables en la ejecucin:

fcil es integrar el sistema, probarlo o modificarlo?

caro ha sido su desarrollo?

Cun

Cunto

se tard en tenerlo disponible en el mercado?

Arquitectura de Software - Introduccin

16

Atributos de Calidad Observables durante la Ejecucin

Performance Seguridad Disponibilidad Funcionalidad Usabilidad

Performance
17

Tiempo que requiere el sistema para responder a un evento o estmulo, o bien el nmero de eventos procesados en un intervalo de tiempo. La performance de un sistema depende de:
comunicacin

entre las componentes asignacin de funcionalidad a las componentes algoritmos elegidos para implementar la funcionalidad codificacin de los algoritmos

Performance en la Arquitectura
18

Puede analizarse la performance en la arquitectura mediante:

anlisis de las tasas de llegada distribucin de los requerimientos tiempos de procesamiento tamao de las colas latencia (tasa de servicio)

de servicios

Se puede simular el sistema mediante modelos estocsticos basados en informacin histrica de carga. Histricamente la performance ha sido muy importante, pero ltimamente otras cualidades tambin lo son.

Seguridad
19

Medida de la capacidad del sistema para resistir intentos de uso y negacin de servicios a usuarios no autorizados sin restar servicios a los usuarios autorizados. Tpicos ataques:
negacin de servicios - impedir que un servidor pueda dar servicios a sus usuarios. Se hace inundndolo con requerimientos o consultas. impostor de direccin IP - el atacante asume la identidad de un host confiable para el servidor. El atacante usualmente inhibe al host confiable mediante negacin de servicios.

Seguridad y Arquitectura
20

Estrategias de arquitectura para prevenir, detectar y responder a ataques de seguridad:

poner

un servidor de autentificacin entre los usuarios externos y la porcin del sistema que da los servicios; instalar monitores de redes para la inspeccin y el registro de los eventos de la red; poner el sistema detrs de un firewall de comunicaciones donde toda comunicacin desde y hacia el sistema se canaliza a travs de un proxy; construir el sistema sobre un kernel confiable

Seguridad y Arquitectura
21

Todas estas estrategias implican identificar componentes especializados y coordinar su funcionamiento con las dems componentes.

Arquitectura de Software - Introduccin

Disponibilidad
22

Proporcin del tiempo que el sistema est en ejecucin. Se mide como el tiempo entre fallas o la rapidez en que el sistema puede reiniciar la operacin cuando ocurre una falla.

tiempo _ promedio _ entre _ fallas tiempo _ promedio _ entre _ fallas tiempo _ medio _ reparacin

Disponibilidad y Arquitectura
23

Tcnicas de arquitectura para promover disponibilidad:

tolerancia a fallas
instalar componentes redundantes que se harn cargo de la ejecucin en caso de fallas disponer de canales de comunicacin redundantes

robustez

separacin de intereses da lugar a sistemas ms fcilmente integrables y probables

fcilmente reparable
diseo de componentes fciles de modificar bajo acoplamiento

Funcionalidad
24

Habilidad de un sistema para hacer la tarea para la cual fue creado. Todas las partes del sistema deben coordinarse para logra el objetivo comn:
asignar

la responsabilidad a cada componente cada cual debe saber el momento en que debe ejecutar su responsabilidad

La funcionalidad es ortogonal a la estructura, y de hecho muchas estructuras diferentes pueden lograr la misma funcionalidad.

Usabilidad
25

Aprendibililidad Cun rpido y fcil es para un usuario el aprender a usar la interfaz del sistema? Eficiencia El sistema responde con la rapidez apropiada a las exigencias del usuario? Recordabilidad Pueden los usuarios recordar cmo usar el sistema entre dos sesiones de uso?

Propenso a errores El sistema anticipa y previene los errores comunes de los usuarios? Manejo de errores El sistema ayuda a los usuarios a recuperarse de los errores? Satisfaccin El sistema facilita la tarea de los usuarios?

Usabilidad y Arquitectura
26

Gran parte de los mecanismos para lograr usabilidad no tienen relacin con la arquitectura:
modelo

mental del usuario del sistema reflejado en la interfaz usuaria, distribucin de elementos y colores en la pantalla.

Otros elementos s tienen relacin con la arquitectura:

la

informacin relevante para el usuario debe estar disponible para una determinada interfaz
debe

disponerse de un conector que traiga esta informacin al componente que corresponda

Atributos de Calidad no Visibles durante la Ejecucin

27

Modificabilidad Portabilidad Reusabilidad Integrabilidad Testabilidad

Modificabilidad
28

Habilidad para hacer cambios al sistema de una forma rpida y poco costosa. Es el atributo de calidad ms ntimamente relacionado con la arquitectura. Hacer modificaciones en un sistema consta de dos etapas:
localizar

el (los) lugar(es) donde debe aplicarse el

cambio aplicar el cambio propiamente tal

Modificabilidad en el Proceso de Desarrollo

29

Ya desde el desarrollo es deseable que un sistema sea mantenible ya que pasa por mltiples etapas:
control

de versiones, control de configuracin, cuanto ms locales los cambios, mejor.

La arquitectura define:
las

componentes y sus reponsabilidades, las condiciones en que cada componente puede cambiar.

Modificabilidad y Arquitectura
30

Las modificaciones suelen venir de cambios en el negocio:

extender o cambiar la capacidades - la extensibilidad permite seguir siendo competitivo en el mercado quitar capacidades no deseadas - simplificar el producto para hacerlo ms liviano o ms barato adaptarse a nuevos ambientes de ejecucin portabilidad hace al producto ms flexible para ms clientes reestructurar - racionalizar servicios, modularizar, optimizar, o crear componentes reusables para futuros desarrollos

Portabilidad
31

Habilidad de un sistema para ejecutar en diferentes ambientes (hardware, software, o una combinacin de ambos). Un sistema es portable si todas las supocisiones acerca del ambiente particular de ejecucin se confinan a una nica (o unas pocas) componente(s). En una arquitectura, el encapsulamiento de las dependencias se hace en una capa de portabilidad que da al sistema una serie de servicios independientes del ambiente.

Reusabilidad
32

Es la capacidad que tiene un sistema para que su estructura o alguna de sus componentes puedan ser usadas en futuras aplicaciones. La reusabilidad se relaciona con la arquitectura en que las componentes son las principales unidades de reutilizacin: la reusabilidad depender del acoplamiento de la componente reusar una componente implica reusar la clausura transitiva de todas las componentes dependientes en la estructura de uso La reusabilidad es una forma particular de

Reusabilidad y Modificabilidad
33

1. Un sistema S est compuesto de 100 componentes (S1 a S100). Se construye otro sistema T, y se descubre que las n primeras componentes son idnticas y pueden reutilizarse. 2. Un sistema S compuesto por 100 componentes est funcionando y se desea modificarlo. Las modificaciones slo afectan 100-n componentes dejando a las restantes incambiadas. El nuevo sistema modificado recibe el nombre T. modificabilidad son dos caras de La reusabilidad y la una misma moneda Hacer un sistema que es modificable permite obtener los beneficios de la reutilizacin

Integrabilidad
34

Habilidad para hacer que piezas de software desarrolladas separadamente trabajen correctamente juntas. La integrabilidad depende de:
complejidad de las componentes mecanismos y protocolos de comunicacin claridad en la asignacin de responsabilidades calidad y completitud de la especificacin de las interfaces La interoperabilidad es una forma de integrabilidad donde las partes del sistema deben trabajar con otro sistema.

Testabilidad
35

Facilidad con la cual el software puede mostrar sus defectos (tpicamente a travs de pruebas de ejecucin). Probabilidad de que, suponiendo que el software tiene al menos un defecto, fallar en la siguiente prueba. Condiciones necesarias:
controlabilidad

- poder controlar el estado interno de las componentes observabilidad - poder observar las salidas (outputs)

Testabilidad y Arquitectura
36

Inciden en la testabilidad:
nivel

de documentacin de la arquitectura separacin de intereses uso de ocultamiento de informacin desarrollo incremental

37

Atributos de Calidad del Negocio

Caractersticas de costo y tiempo:

tiempo para poner en el mercado costo tiempo de vida til proyectada para el sistema

Caractersticas de comercializacin:
mercado objetivo planificacin uso intensivo de sistemas legados

Costo y Tiempo
38

Tiempo para poner en el mercado

poco tiempo para desarrollo presiona a la reutilizacin el uso de COTS o componentes ya desarrolladas ayuda el diseo de la nueva arquitectura debe ser capaz de albergar estos componentes. el costo un sistema que usa tecnologa conocida ser menor el aprendizaje de una nueva tecnologa podr reusarse en el futuro en una larga vida til, la modificabilidad y portabilidad son importantes, aunque esto alargue el ciclo de desarrollo

Costo

Vida til planificada del sistema

Comercializacin
39

Mercado objetivo

la plataforma y la funcionalidad determina el tamao del mercado performace, confiabilidad y usabilidad tambin son importantes para un mercado grande pero especfico, debe considerarse el enfoque de lneas de productos
si se construye un sistema bsico para ser extendido, la flexibilidad y configurabilidad son importantes si se interacta con sistemas legados, debe proveerse un mecanismo adecuado de integracin y/o interoperabilidad

Planificacin

Uso de sistemas legados

Atributos de Calidad de la Arquitectura

40

Integridad conceptual
visin

unificada usada en el diseo del sistema

Correctitud y completitud
el

sistema incluye toda la funcionalidad requerida del sistema de ser construido el sistema por el equipo de desarrollo disponible en el tiempo y costo estipulado

Factibilidad de la construccin
posibilidad

Integridad Conceptual
41

Sostendr que la integridad conceptual es la consideracin ms importante en el diseo de un sistema. Es mejor tener un sistema sin ciertas caractersticas y optimizaciones, pero que refleje un conjunto nico de ideas de diseo ms que un sistema que tiene muchas ideas buenas pero independientes y descoordinadas. [Brooks75]
En realidad Brooks se refera al diseo de la interfaz usuaria, pero tambin vale para la arquitectura: lo que la integridad conceptual de la interfaz es para el usuario, lo
es la integridad conceptual de la arquitectura para los dems stakeholders.

20 aos ms tarde: Estrategia

42

Estoy ms convencido que nunca. La integridad conceptual es esencial para la calidad del producto. Tener un arquitecto de sistema es el paso ms importante hacia tener integridad conceptual ... Despus de dictar un laboratorio de ingeniera de software ms de 20 veces, insisto que los grupos de desarrollo de 4 estudiantes deben elegir un administrador de proyecto y un arquitecto separados. [Brooks95]

Cul Arquitectura Escoger?

43

Qu estructura debo emplear para asignar trabajadores, para derivar la estructura de reparticin del trabajo, para explotar las componentes ya empaquetadas y para planificar un sistema modificable?
Qu estructura debo emplear para que el sistema, durante su ejecucin, logre sus requisitos de comportamiento y sus atributos de calidad?

La estructua de mdulos y la estructura de procesos en

ejecucin son distintas pero deben ser consistentes.