Arquitectura de Software

presentación de

Perspectiva de la Evolución

Andrés PinedaJuan Cubillos

Facultad de IngenieríaUniversidad Católica de Colombia

Ciclo de Vida del Desarrollo

2Aplicabilidad 3Preocupaciones1Calidad Deseada

5Tactica 6Trampas4Actividades

PERS

PECT

IVAS

AR

QU

ITEC

TURA

LES

Perspectivas

Colección de actividades, tácticas y lineamientos queson utilizadas para asegurar que el sistema presenteun conjunto de propiedades de calidad que requierenconsideración a través de un número de vistas dearquitectura.

• Considerar de manera aislada no es muy práctico por lo que usar un punto de vista para crear una vista para cada atributo de calidad no es funcional.

• Las perspectivas no se aplican de manera aislada por el contrario se usan con cada una de las vistas de la arquitectura para analizar y validar sus cualidades y llevar decisiones futuras.

PERS

PECT

IVAS

AR

QU

ITEC

TURA

LES

Perspectivas

Las mas relevantes: – Seguridad– Desempeño y escalabilidad– Disponibilidad y recuperabilidad– Evolución

PERS

PECT

IVAS

AR

QU

ITEC

TURA

LES

Catalogo de Perspectivas

PERS

PECT

IVAS

AR

QU

ITEC

TURA

LES

Perspectivas

La metodología propuesta guía el proceso de diseño de la arquitectura para garantizar que un sistema exhiba una o más atributos de calidad relevantes para los stakeholders.

PERS

PECT

IVAS

AR

QU

ITEC

TURA

LES

APLICABILIDAD DE LAS VISTAS1

APLI

CABI

LIDA

DAplicabilidadEl objetivo de aplicar una perspectiva a una vista es encontrar y/o definir:• Cómo la arquitectura va a cumplir

un atributo de calidad?• Posibles mejoras al diseño para

cumplir con el atributo• Otros artefactos que podrán

ayudar a validar que el sistema si cumple con un atributo

APLI

CABI

LIDA

D

PREOCUPACIONES (CONCERTS)

Evolución de las Perspectivas

1 3

CON

CERT

SMagnitud del Cambio

CON

CERT

SDimensiones del Cambio

Riesgo del Cambio

Escala de tiempo para el cambioEl entorno de los sistemas cambia constantemente y raras veces sobreviven al impacto del tiempo. Los cambios deben ser programados y estudiados

CON

CERT

S

Escala de tiempo para el cambioCO

NCE

RTS

Cuando Pagar por el CambioCO

NCE

RTS

ESCE

NAR

IOS

DE

CALI

DAD

Complejidad del Desarrollo

CON

CERT

SPreservación del Conocimiento

CON

CERT

SConfiabilidad del cambio

ACTIVIDADES

Evolución de las Perspectivas

1 4

ACTI

VIDA

DES

TÁCTICAS

Evolución de las Perspectivas

1 5

TACT

ICAS

Construir puntos de variación en el software:

Una estrategia menos extrema que la adopción de un estilo arquitectónico completo es adoptar soluciones específicas y localizadas de diseño para apoyar ciertos tipos de cambios en lugares específicos en el sistema. Este enfoque implica la identificación de los lugares en los que soporta un cierto tipo de cambio, es de importancia crítica y especificando un mecanismo para lograr el cambio requerido. Llamamos a estos lugares en los puntos del sistema de variación (tomando el término de arquitectura de línea de producto).

Usa los puntos de extensión estándar:

Un enfoque relacionado a la construcción de sus propios puntos de variación es considerar cómo se pueden utilizar los puntos de extensión integrados en tecnologías estándar para proporcionar apoyo a los cambios en el sistema. Muchos de los principales sistemas de tecnologías de la información ofrecen puntos de extensión estándar (por ejemplo, la capacidad de la plataforma J2EE para agregar soporte para nuevos tipos de bases de datos, a través de la interfaz JDBC, y los sistemas externos, a través de la interfaz JCA).

TACT

ICAS

Construir puntos de variación en el software:Lograr el Cambio Confiable:

Un gran desafío para los arquitectos, desarrolladores y administradores de sistemas de muchos se trata de cambio de una manera fiable. Usted, como nosotros, probablemente ha visto un cambio supuestamente sencillo llegar a tener una serie de efectos secundarios graves que causó grandes problemas cuando se despliega.

Preservar los entornos de desarrollo:

Una vez que el proyecto ha entregado una cantidad significativa de funcionalidad, el entorno de desarrollo original es a menudo desmontados o evolucionado. Con el tiempo, usted puede fácilmente llegar al punto donde no se conoce el número exacto de los compiladores, sistemas operativos, parches, bibliotecas, herramientas de construcción, y así sucesivamente utilizado para crear el sistema. Esto puede ser un problema particular para los desarrolladores de productos que soportan una amplia gama de plataformas y versiones de productos.

TACT

ICAS

Aplicar modelos basados en estilos arquitectónicos:Si usted tiene requerimientos importantes para la evolución del sistema, puede valer la pena considerar la adopción de un estilo de arquitectura global que se centra especialmente en el apoyo a cambio. Basados Metamodelo sistemas proporcionan un alto grado de flexibilidad en algunos ámbitos problemáticos (en particular los sistemas de bases de datos que requieren la evolución del esquema significativo).

TRAMPAS

Evolución de las Perspectivas

1 6

TRAM

PAS

Priorización de las dimensiones incorrectas:

Al considerar cómo permitir el cambio en su arquitectura, es fácil centrarse en las dimensiones que conocemos o que le parezca de importancia inmediata porque los principales interesados subrayan su importancia.

Cambios que nunca suceden:

Posibles cambios de forma creíble podrían hacerse a cualquier sistema. Usted no puede realmente diseñar una arquitectura que permite a todos, ciertamente no uno que también puede ser entregado de una manera costo-efectiva y oportuna con un nivel aceptable de riesgo.

TRAM

PAS

Impactos de la evolución en las propiedades de calidad crítica:

La construcción de un sistema de apoyo a la evolución no es sin costo. En particular, los sistemas altamente flexibles (tales como los sistemas basados en metamodelo descritos anteriormente) puede traer costos significativos en términos de eficiencia en tiempo de ejecución y rendimiento, así como el proceso de desarrollo más complejo que implica a su complejidad.

Perdidos Entornos de desarrollo

Ya hemos mencionado que la evolución (y prueba) es más probable que se pierda de entorno de despliegue. Además, los entornos de desarrollo son a menudo sujetos a cambio y evolución independiente como prioridades de desarrollo y soporte de carga de trabajo y, naturalmente, cambian con el tiempo.

TRAM

PAS

Ad Hoc Gestión de Versiones

Al implementar en un entorno de prueba, que en realidad no importa si el proceso va mal porque nadie está seriamente afectado, algunas pruebas fallan, la gente realice que el despliegue ha fracasado y que tienen que volver a implementar, pero los usuarios del sistema no se ve afectado

EJEMPLO

Evolución de las Perspectivas

1 7

EJEM

PLO

Ejemplo – Perspectiva de Seguridad

• Calidad Deseada

La habilidad del sistema para controlar, monitorear y auditar quien puede desempeñar cuáles acciones sobre los recursos y la habilidad de detectar y recuperarse de fallas en los mecanismos de seguridad

• Concerns

Políticas, amenazas, disponibilidad, detección,recuperación y auditoría

EJEM

PLO

Ejemplo – Perspectiva Seguridad

• Actividades

1. Identificar recursos sensitivos2. Definir políticas de seguridad3. Identificar amenazas al sistema4. Diseñar la implementación de seguridad5. Evaluar los riesgos de seguridad

EJEM

PLO

Ejemplo – Perspectiva Seguridad

Tácticas Arquitecturales

1. Aplicar principios conocidos de seguridad2. Usar mecanismos de identificación y autenticación3. Asegurar la integridad y protección de la información4. Asegurar mecanismos de auditoría5. Proteger la disponibilidad6. Integrar tecnologías de seguridad

Problemas y mal uso

7. El sistema no esta diseñado en caso de fallas8. Tecnología de seguridad nunca antas probada9. La seguridad es problema del desarrollador

EJEM

PLO