Arquitectura software

Cliclo de vida arqui: Requisitos arquitecturales- diseño de la arquitectura- implementación de la arquitectura- evaluación de la arquitectura.

Tareas de ingeniería de requisitos respecto a la arquitectura: Identificar escenarios relevantes-priorizar escenarios-detallar escenarios-documentar arquitectura preliminar-escenario funcional, casos de uso-escenario no funcional, escenario de calidad.

Quality Attribute Workshop:Método que reúne a los participantes tempranamente en el ciclo de vida, durante un día, para descubrir los atributos de calidad orientadores de un sistema intensivo de software.QAW se centra en el sistema y los participantes y se utiliza antes que se defina la arquitectura del sistema.

Attribute-Driven Design (ADD): Es un método de diseño arquitectónico dirigido por los atributos de calidad que se quiere que posea el sistema, más que por la funcionalidad de la aplicación, que queda en un segundo nivel (Bass et al., 2001).

Architectural Styles (ABAS): (Klein y Kazman, 1999), por su parte, es a la arquitectura lo que los patrones de diseño a los objetos, es decir, son soluciones basadas en estilos arquitectónicos que han surgido de la experiencia de resolver problemas que se presentan de manera frecuente. ABAS utiliza los atributos de calidad para definir un marco de aplicación de un estilo arquitectónico concreto, proporcionando un razonamiento, cuantitativo o cualitativo, que fundamente la utilización de un estilo arquitectónico en un diseño determinado.

Architecture Tradeoff Analysis Method (ATAM): (Kazman et al., 2000) es la evolución de un método anterior llamado SAAM (Software Architecture Analysis Method) (Kazman et al., 1994), para el análisis de arquitecturas software basado en la utilización de escenarios, en el que la evaluación de una arquitectura no se realiza para identificar de manera precisa el comportamiento de un atributo de calidad, lo cual no es posible en fases tempranas del diseño por falta de información, sino para descubrir qué decisiones de diseño afectan de una u otra forma a los atributos de calidad.

Esto se hace a través de la identificación de:  Riesgos: decisiones aplazadas o decisiones cuyo efecto no se alcanza a valorar.

Puntos sensibles: partes de la arquitectura que pueden tener mucha influencia en algún atributo de calidad.

Puntos de compromiso: partes de la arquitectura cuya modificación significa mejorar algún atributo de calidad a costa de empeorar otro. Es lo que sucede, en algunos casos, con la modificabilidad y el rendimiento.

Cost- Benefit Analysis Method (CBAM): (Kazman et al., 2002) es un método para evaluar los beneficios, costes y riesgos de las diferentes decisiones que se toman para diseñar la arquitectura software del sistema. Al igual que QAW, también está pensado para su integración con ATAM, ya que los resultados producidos por la evaluación de la arquitectura, especialmente las estrategias arquitectónicas a seguir, se utilizan como entrada en CBAM para tomar decisiones basadas en criterios económicos.

Views and Beyond (V&B): (Clements et al., 2002a) es la propuesta realizada en el SEI para documentar la arquitectura software de un sistema. De acuerdo con la definición de arquitectura como la estructura o estructuras del sistema, V&B propone la definición de una serie de vistas relevantes de la arquitectura software del sistema, documentando cada una de ellas, así como las características que afecten a más de una o a todas en general.

Algunas realidades sobre los atributos de calidad: Suelen estar pobremente especificados, o directamente no especificados (“un requerimiento que no es testeable no es implementable”). - En general no se analizan sus dependencias. - La importancia de estos atributos varía con el dominio para el cual se construye el software. - Las “tácticas” de arquitectura no son fines en si mismas, son formas de alcanzar atributos de calidad deseados.

Distintas clasificaciones de atributos de calidad: IEEE Std 1061 / ISO 9126

Calidad: Si los sistemas fallan pueden causar diferentes consecuencias (perdidas tiempo, dinero)- No es suficiente con satisfacer los requerimientos funcionales - Existe un contexto tecnológico que debe analizarse.