1. Arquitectura de Software
presentación de
Perspectiva de la
Evolución
Andrés Pineda
Juan Cubillos
Facultad de Ingeniería
Universidad Católica de Colombia

2. Calidad Aplicabilidad Preocupaciones
Deseada
4
Actividades Tactica
6
Trampas
Ciclo de Vida del Desarrollo

3. Perspectivas
Colección de actividades, tácticas y lineamientos que
son utilizadas para asegurar que el sistema presente
un conjunto de propiedades de calidad que requieren
consideración a través de un número de vistas de
arquitectura.
ARQUITECTURALES
• Considerar de manera aislada no es muy práctico
por lo que usar un punto de vista para crear una
PERSPECTIVAS
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.

4. Perspectivas
Las mas relevantes:
– Seguridad
ARQUITECTURALES
– Desempeño y escalabilidad
– Disponibilidad y recuperabilidad
PERSPECTIVAS
– Evolución

5. PERSPECTIVAS
ARQUITECTURALES
Catalogo de Perspectivas

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

7. PERSPECTIVAS
ARQUITECTURALES

8. APLICABILIDAD DE LAS
VISTAS

9. Aplicabilidad
El 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
APLICABILIDAD
cumplir con el atributo
• Otros artefactos que podrán ayudar
a validar que el sistema si cumple
con un atributo

10. APLICABILIDAD

11. PREOCUPACIONES (CONCERTS)
Evolución de las Perspectivas

12. Magnitud del Cambio
CONCERTS

13. Dimensiones del Cambio
CONCERTS

14. Riesgo del Cambio
Escala de tiempo para el cambio
CONCERTS
El entorno de los sistemas cambia
constantemente y raras veces sobreviven
al impacto del tiempo. Los cambios deben
ser programados y estudiados

15. CONCERTS Escala de tiempo para el cambio

16. CONCERTS Cuando Pagar por el Cambio

17. ESCENARIOS DE CALIDAD Complejidad del Desarrollo

18. CONCERTS Preservación del Conocimiento

19. CONCERTS Confiabilidad del cambio

20. ACTIVIDADES
Evolución de las Perspectivas

21. ACTIVIDADES

22. TÁCTICAS
Evolución de las Perspectivas

23. 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
TACTICAS
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).

24. 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
TACTICAS
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.

25. 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
TACTICAS
en algunos ámbitos problemáticos (en
particular los sistemas de bases de datos
que requieren la evolución del esquema
significativo).

26. TRAMPAS
Evolución de las Perspectivas

27. 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
TRAMPAS
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.

28. 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
TRAMPAS
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.

29. 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
TRAMPAS
usuarios del sistema no se ve afectado

30. EJEMPLO
Evolución de las Perspectivas

31. 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
EJEMPLO
Políticas, amenazas, disponibilidad, detección,
recuperación y auditoría

32. Ejemplo – Perspectiva Seguridad
• Actividades
1. Identificar recursos sensitivos
2. Definir políticas de seguridad
3. Identificar amenazas al sistema
4. Diseñar la implementación de seguridad
EJEMPLO
5. Evaluar los riesgos de seguridad

33. Ejemplo – Perspectiva Seguridad
Tácticas Arquitecturales
1. Aplicar principios conocidos de seguridad
2. Usar mecanismos de identificación y autenticación
3. Asegurar la integridad y protección de la información
4. Asegurar mecanismos de auditoría
5. Proteger la disponibilidad
6. Integrar tecnologías de seguridad
Problemas y mal uso
EJEMPLO
1. El sistema no esta diseñado en caso de fallas
2. Tecnología de seguridad nunca antas probada
3. La seguridad es problema del desarrollador

34. EJEMPLO