Perspectiva de la evolucion
-
Upload
andres-pineda -
Category
Technology
-
view
621 -
download
0
Transcript of Perspectiva de la evolucion
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
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.
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
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
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).
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
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