representación y razonamiento sobre las decisiones de...
TRANSCRIPT
María Celeste Carignano Celtic 2009 1
Representación y Razonamiento sobre las Decisiones de Diseño de Arquitecturas de
Software.
María Celeste CarignanoInstituto de Desarrollo y Diseño - INGAR
Director: Horacio LeoneCodirector: Silvio Gonnet
María Celeste Carignano Celtic 2009 2
¿Qué es la arquitectura de un software?
• La arquitectura de software es la estructura o las estructuras de un sistema de software, las cuales comprenden los elementos de software, sus propiedades visibles externamente y las relacionesentre ellos.
(L. Bass, P.; Clements, P.; Kazman, R. “Software Architecture in Practice 2nd ed”.
Published Addison Wesley, 2003)
• La arquitectura de software es el conjunto de decisiones de diseño, las cuales, si son tomadas de manera incorrecta, pueden causar que el proyecto sea cancelado.
Eoin Woods
María Celeste Carignano Celtic 2009 3
La arquitectura de software y el ciclo de vida del software
María Celeste Carignano Celtic 2009 4
Razonamiento en arquitectura de software
• El razonamiento realizado durante el diseño arquitectónico es la explicación de CÓMO y POR QUÉ un producto arquitectónico, o parte de él, ha sido diseñado de esa manera.
(Babar, M.; Gorton, I.;Kitchenham, B. “A Framework for Supporting Architecture Knowledge and Rationale Management”, chapter 11, Rationale Management in Software Engineering, A. Dutoit, R. McCall, I. Mistrkik, and B. Paech (Eds.), pp. 237-254, Springer-Verlag, April 2006)
• Todo el razonamiento que no es documentado, con el paso del tiempo es olvidado o ignorado.
María Celeste Carignano Celtic 2009 5
Aspectos que justifican la captura del razonamiento en la Ingeniería de Software
• El tamaño, la complejidad y la vida útil de los sistemas de software son cada vez mayores.
• La naturaleza iterativa de los procesos de desarrollo de software.• El incremento de la participación de los “stakeholders” durante la
creación del sistema.
(Burge, J.; Carroll, J.; McCall, R.; Mistrík, I. “Rationale-Based Software Engineering”. Published Springer-Verlag, 2008)
En un estudio realizado sobre una población de 127 participantes: • el 85,1 % de los arquitectos considera que el uso de razonamiento
en el diseño es importante para justificar el diseño,• un 79% de los participantes dice que la documentación del
razonamiento asociado a un diseño es muy importante ya que lo ayuda a comprender el diseño del sistema para realizar mejoras al mismo,
• el 81,5% de los participantes olvida sus propias decisiones de diseño después de un tiempo.
(Tang, A.; Babar, M.; Gorton, I.; Han, J. “A Survey of Architecture Design Rationale”. Swinburne University of Technology SUTICT-TR2005.02. 2005)
María Celeste Carignano Celtic 2009 6
Utilización del razonamiento capturado
• Situaciones comunes:
• Creación, modificación o eliminación de requerimientos luego del diseño;
• Incorporación de nuevos miembros al equipo de construcción del software;
• Transferencia de conocimiento y/o capacitación por parte de arquitectos involucrados en el proyecto a nuevos diseñadores;
• Detección de problemas una vez avanzada la construcción del sistema que requieren revisar la arquitectura y analizar el impacto de las posibles soluciones;
• Falta de entendimiento de la arquitectura generada;
• Necesidad de generar nuevas arquitecturas basadas en experiencias previas de manera de evitar repetir errores anteriores y poder reproducir aciertos.
María Celeste Carignano Celtic 2009 7
Modelo Propuesto
María Celeste Carignano Celtic 2009 8
Modelo Propuesto
Todo sistema de software se
construye para satistacer las
necesidades de los
“stakeholders”, cumpliendo
con determinadas
restricciones.
María Celeste Carignano Celtic 2009 9
Modelo Propuesto
Necesidades asociadas a
funcionalidades específicas
del sistema.
Todo sistema de software
se construye para satistacer
las necesidades de los
“stakeholders”, cumpliendo
con determinadas
restricciones.
María Celeste Carignano Celtic 2009 10
Modelo Propuesto
Necesidades asociadas a
características que debe
poseer el sistema o parte de
él.
Necesidades asociadas a
funcionalidades específicas
del sistema.
Todo sistema de software
se construye para satistacer
las necesidades de los
“stakeholders”, cumpliendo
con determinadas
restricciones.
María Celeste Carignano Celtic 2009 11
Modelo Propuesto
Ejemplos:
-Seguridad
-Performance
-Disponibilidad
-Modificabilidad
-....
Necesidades asociadas a
características que debe
poseer el sistema o parte de
él.
Necesidades asociadas a
funcionalidades específicas
del sistema.
Todo sistema de software
se construye para satistacer
las necesidades de los
“stakeholders”, cumpliendo
con determinadas
restricciones.
María Celeste Carignano Celtic 2009 12
Modelo Propuesto
Un escenario ayuda a describir
un requerimiento de calidad.
Un escenario general provee
un framework para generar
escenarios concretos.
Un escenario concreto es un
escenario general con
características específicas de
un sistema.
Ejemplos:
-Seguridad
-Performance
-Disponibilidad
-Modificabilidad
-....
María Celeste Carignano Celtic 2009 13
Modelo Propuesto
Posibles partes:
-SOURCE_STIMULUS
-STIMULUS
-ARTIFACT
-ENVIRONMENT
-RESPONSE
-RESPONSE_MEASURE
Ejemplos:
-Seguridad
-Performance
-Disponibilidad
-Modificabilidad
-....
Un escenario ayuda a describir
un atributo de calidad.
Un escenario general provee
un framework para generar
escenarios concretos.
Un escenario concreto es un
escenario general con
características específicas de
un sistema.
María Celeste Carignano Celtic 2009 14
Ejemplo de Escenario Atributo de calidad Modificabilidad
Escenario general
-Costo en término del número de elementos afectados-Esfuerzo-Dinero-....
Response Measure
-Localizar los lugares de la arquitectura a ser modificados-Hacer las modificaciones sin afectar otras funcionalidades-...
Response
-En tiempo de ejecución-En tiempo de compilación-En tiempo de diseño-En tiempo de construcción
Environment
-Interfaz de usuario-Entorno-...
Artifact
Deseos de:-Agregar, eliminar o modificar una funcionalidad,-Agregar, eliminar o modificar un atributo de calidad
Stimulus
-Usuario final-Desarrollador-Administrador del sistema
Source
Escenario concreto
Usuario Final
Deseos de modificar una configuración
Interfaz de usuario
En tiempo de ejecución
Lugares de la arquitectura
a ser modificados
Cero elementos afectados
María Celeste Carignano Celtic 2009 15
Modelo Propuesto
María Celeste Carignano Celtic 2009 16
Modelo Propuesto
Durante la definición de la
arquitectura de un sistema se
puede trabajar sobre varias
alternativas de solución, en las
cuales se consideran, analizan y
evalúan posibles soluciones que
satisfagan los requerimientos
identificados.
María Celeste Carignano Celtic 2009 17
Modelo Propuesto
Es una agregación de
decisiones de diseño
arquitectónicas relacionadas.
María Celeste Carignano Celtic 2009 18
Modelo Propuesto
Es una agregación de
decisiones de diseño
arquitectónicas relacionadas.
Es una decisión tomada por un
arquitecto con el objetivo de
satisfacer un escenario de
calidad concreto, teniendo en
consideración las restricciones
impuestas a la solución.
María Celeste Carignano Celtic 2009 19
Modelo Propuesto
Una táctica influencia el control de la respuesta
de un atributo de calidad.
Es una opción de diseño para un arquitecto.
Por ejemplo, una táctica es introducir
redundancia para incrementar la disponibilidad
del sistema.
Es una agregación de
decisiones de diseño
arquitectónicas relacionadas.
Es una decisión tomada por un
arquitecto con el objetivo de
satisfacer un escenario de
calidad concreto, teniendo en
consideración las restricciones
impuestas a la solución.
Un estilo arquitectónico define una familia de
sistemas en términos de patrones de
organización estructural. Provee un vocabulario
de componentes y conectores y un conjunto de
restricciones acerca de cómo pueden ser
combinados.
María Celeste Carignano Celtic 2009 20
Modelo Propuesto
Es una agregación de
decisiones de diseño
arquitectónicas relacionadas.
Es una decisión tomada por un
arquitecto con el objetivo de
satisfacer un escenario de
calidad concreto, teniendo en
consideración las restricciones
impuestas a la solución.
María Celeste Carignano Celtic 2009 21
Modelo Propuesto
Es una agregación de
decisiones de diseño
arquitectónicas relacionadas.
Es una decisión tomada por un
arquitecto con el objetivo de
satisfacer un escenario de
calidad concreto, teniendo en
consideración las restricciones
impuestas a la solución.
María Celeste Carignano Celtic 2009 22
Modelo Propuesto
Es una agregación de
decisiones de diseño
arquitectónicas relacionadas.
Es una decisión tomada por un
arquitecto con el objetivo de
satisfacer un escenario de
calidad concreto, teniendo en
consideración las restricciones
impuestas a la solución.
Posibles valores:
-STRENGTH
-WEAKNESS
-ASSUMPTIONS
-TRADE_OFFS
-RISK
-NON_RISK
María Celeste Carignano Celtic 2009 23
Modelo Propuesto
Una decisión de diseño puede influir sobre otras.
Ejemplos de influencias son:
-Enables: “Usar Java” permite “usar J2EE”
-CONFLICTS_WITH: “se debe utilizar .Net” tiene
conflictos con “se debe utilizar Java”
-IS_AN_ALTERNATIVE_TO
-…
María Celeste Carignano Celtic 2009 24
Modelo Propuesto
Posibles estados:
-IN_DEFINITION
-SELECTED
-REJECTED
María Celeste Carignano Celtic 2009 25
Modelo Propuesto
Posibles estados:
-IDEA
-APPROVED
-REJECTED
-….
María Celeste Carignano Celtic 2009 26
Modelo Propuesto
María Celeste Carignano Celtic 2009 27
Decisiones de Diseño Arquitectónico
• A partir de la captura del rationale asociado a las decisiones de diseño se puede:
• Evaluar el impacto de una modificación.
• Analizar las soluciones propuestas para satisfacer un requerimiento.
• Entender las razones por las cuales uno o varios elementos fueron creados y relacionados.
María Celeste Carignano Celtic 2009 28
Prototipo de documentación de las decisiones de diseño arquitectónico.
Plugin de Eclipse Integrado con Rational Software Architect
María Celeste Carignano Celtic 2009 29
Reutilización de arquitecturas de software
Arquitecturas anteriores Nueva arquitectura
Pipe and filter
Layers
Model View Controller
Manage event rate
Intermediary
Authenticate users
…
María Celeste Carignano Celtic 2009 30
Caso Recuperado
Razonamiento Basado en Casos
• Razonamiento basado en casos (CBR) es una metodología para resolver problemas utilizando experiencias previas.
• CBR es capaz de utilizar el conocimiento específico de experiencias previas, situaciones o problemas concretos (casos). Un nuevo problema es resuelto encontrando un caso similar del pasado, y reusándolo en el nuevo problema.
(Pal, S.; Shiu, S. “Foundations of Soft Case-Based Reasoning”. Published Wiley, 2004)
Nuevo Caso
Caso ResueltoCaso Probado
Caso Aprendido
Problema
Base de casos
Recuperar
Reusar
Revisar
Retener
Nuevo Caso
Caso Recuperado
María Celeste Carignano Celtic 2009 31
Aplicación de Razonamiento Basado en Casos
Caso:
Problema: Requerimientos
Solución: Conjunto de
decisiones de
diseño
Caso Recuperado
Nuevo Caso
Caso ResueltoCaso Probado
Caso Aprendido
Nuevo Sistema
Base de casos
Descripto utilizando el modelo presentado Recuperación utilizando una funciónde similitud
Generación de una arquitectura inicial con las decisiones de diseño del caso recuperado
Nuevo Caso
Caso Recuperado
María Celeste Carignano Celtic 2009 32
Conclusiones y Trabajos Futuros
Conclusiones:• El modelo construido permite representar el razonamiento realizado
durante un diseño arquitectónico.• El razonamiento capturado se puede consultar para responder las
situaciones previamente planteadas.• El prototipo que se está desarrollando permite capturar el
razonamiento de manera integrada a una herramienta de modelado UML ampliamente reconocida en el mercado.
Trabajos Futuros:• Finalización del prototipo de documentación de las decisiones de
diseño arquitectónico.• Definición de la función de similitud y los mecanismo de reuso,
revisión y retención de CBR.• Validación del modelo y el mecanismo de reutilización con casos de la
industria del software.