Managing Trade-offs among Architectural Tactics using Feature models and Feature Solution Graphs
•
0 likes•347 views
The document proposes using feature models and feature-solution graphs to manage trade-offs between architectural tactics. Feature models represent variability in tactics and design alternatives, and feature-solution graphs relate these with forces, prohibits, and suggests relationships. This allows detecting conflicts between alternatives, explaining involved tactics and qualities, and propagating decisions. The approach is illustrated using tactics and alternatives for database-based web applications. Limitations include only detecting constraints-based conflicts and consideration of specific quality attributes.
Recommended
More Related Content
What's hot
What's hot (14)
Viewers also liked
Viewers also liked (20)
Similar to Managing Trade-offs among Architectural Tactics using Feature models and Feature Solution Graphs
Similar to Managing Trade-offs among Architectural Tactics using Feature models and Feature Solution Graphs (20)
Recently uploaded
Recently uploaded (20)
Managing Trade-offs among Architectural Tactics using Feature models and Feature Solution Graphs
- 1. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs Jaime Chavarriaga, jchavarr@vub.ac.be Carlos Noguera, cnogera@vub.ac.be Rubby Casallas, rcasalla@uniandes.edu.o Viviane Jonckers, vejoncke@vub.ac.be
- 2. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs
- 3. Architectural Tactics How to achieve a quality attribute ?
- 4. Architectural Tactics there are tactics for each quality attribute Bass et al. Software Architecture in Practice Addison-Wesley 2014
- 5. Architectural Tactics there are designs to implement these tactics Kim et al. Quality-driven architecture development using architectural tactics JSS, 82 (2009)., 1121-1231
- 6. Architectural Tactics … using code or deployment options.
- 8. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs
- 9. Trade-offs Considering multiple quality attributes…
- 10. Trade-offs … an architect may select multiple tactics and design alternatives
- 11. Trade-offs Conflicts may occur: two design alternatives cannot be selected at the same time These options cannot be selected at the same time !!
- 13. Trade-off Management Software architects must deal with trade-offs ⓪ Decide about tactics and design alternatives ❶ Detect conflicts among design alternatives ❷ Determine which tactics and qualities are involved ❸ Decide how to solve the conflict 13
- 14. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs
- 15. Our Proposal ❶ Feature models to represent variability in: • Architectural Tactics related to QAs, • Platform design alternatives / configuration options ❷ Feature Solution Graphs to represent: • Relationships between these feature models ❸ Automated tasks to help architect’s work
- 16. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs
- 17. Feature Models r a b f2f1 f3 f4 f5 Or Group Alternative Group Optional Feature Mandatory Feature
- 18. Configuration r a b f2f1 f3 f4 f5 Or Group Alternative Group Optional Feature Mandatory Feature C1 = { r, a, f1, b, f3 } valid
- 19. Configuration r a b f2f1 f3 f4 f5 Or Group Alternative Group Optional Feature Mandatory Feature C2 = { r, b, f3 } invalid
- 20. Valid Feature Models Set of valid configurations= 𝑓𝑚 is valid if 𝑓 𝑚 ≠ ∅
- 21. FM for Architectural Tactics Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency
- 22. FM for Architectural Alternatives Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires
- 23. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs
- 24. Feature Solution Graph (FS-Graphs) forces prohibits suggests
- 25. Feature Solution Graph (FS-Graphs) forces prohibits suggests
- 26. Feature Solution Graph (FS-Graphs) forces prohibits suggests
- 27. Feature Solution Graph (FS-Graphs) forces prohibits suggests 𝑓𝑠𝑔 = < 𝑓𝑚 𝑠 , 𝑓𝑚 𝑡, 𝐹𝑂𝑅, 𝑃𝑅𝑂, 𝑆𝑈𝐺 >
- 29. Example relationships 29 Architectural Tactic Design Alternatives Maintain copies of data Suggests result cache Forces entity cache Maintain copies of computation Forces multi-node web tier Introduce concurrency Forces optimistic locking Reduce overhead Prohibits pessimistic locking Suggests sticky-session load balancer Active redundancy Forces normal load balancer Transactions Prohibits optimistic locking Prohibits session server
- 30. Example FS-Graphs Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency suggests suggests
- 31. Example FS-Graphs Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency forces
- 32. Example FS-Graphs Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency prohibits
- 33. Example FS-Graphs Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency
- 34. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs
- 35. Trade-off Management Software architects must deal with trade-offs ⓪ Decide about tactics and design alternatives ❶ Detect conflicts among design alternatives ❷ Determine which tactics and qualities are involved ❸ Decide how to solve the conflict
- 36. Propagate Decisions ⓪ Decide about tactics and design alternatives Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency
- 37. Propagate Decisions ⓪ Decide about tactics and design alternatives Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency
- 38. Propagate Decisions ⓪ Decide about tactics and design alternatives Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency
- 39. Propagate Decisions ⓪ Decide about tactics and design alternatives Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency
- 40. Propagate Decisions ⓪ Decide about tactics and design alternatives – Feature-Architecture Relationships [Janota:] – Multi-view Feature Models [Hubaux:2010] – Constraint propagation on Configuration Links [Rein-Jury:2013] – Decision propagation on FS-Graphs [Chavarriaga:2014]
- 41. Propagate Decisions ⓪ Decide about tactics and design alternatives forces prohibits suggests forces prohibits suggests 𝑓𝑠𝑔′ 𝐴𝑅2𝐷𝐸 = 𝒂𝒑𝒑𝒍𝒚𝑭𝑺𝑮 𝑐 𝐴𝑅, 𝑓𝑠𝑔 𝐴𝑅2𝐷𝐸 𝑓𝑚′ 𝐷𝐸 = 𝒔𝒑𝒆𝒄𝒊𝒂𝒍𝒊𝒛𝒆𝑭𝑺𝑮 𝑐 𝐴𝑅, 𝑓𝑠𝑔 𝐴𝑅2𝐷𝐸
- 42. Detect Conflicts ❶ Detect conflicts among design alternatives Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency
- 43. Detect Conflicts ❶ Detect conflicts among design alternatives Architectural Alternatives Deployment View Web Tier Additional Tier Cache Service Layer Business Logic Layer LockingResult Cache Optimistic Pessimistic Logic View Session Server Single Node Multi Node Sticky Load Balancer Normal Load Balancer requires Tactics Performance Availability Active Redundancy Transactions Reduce Overhead Copies of Data Copies of Computation Introduce Concurrency
- 44. Detect Conflicts ❶ Detect conflicts among design alternatives forces prohibits suggests forces prohibits suggests 𝑓𝑠𝑔′ 𝐴𝑅2𝐷𝐸 = 𝒂𝒑𝒑𝒍𝒚𝑭𝑺𝑮 ( 𝑐 𝐴𝑅, 𝑓𝑠𝑔 𝐴𝑅2𝐷𝐸 ) 𝑓𝑚 𝐷𝐸 ∈ 𝑓𝑠𝑔′ 𝐴𝑅2𝐷𝐸 , There is a conflict if 𝑓 𝑚 𝐷𝐸 = ∅ i.e, if 𝒔𝒑𝒆𝒄𝒊𝒂𝒍𝒊𝒛𝒆𝑭𝑺𝑮 𝐶𝐴𝑅 , 𝑓𝑠𝑔 𝐴𝑅2𝐷𝐸 ) = ∅
- 45. Explain Conflicts ❷ Determine which tactics and qualities are involved forces prohibits suggests forces prohibits suggests If there is a conflict caused by 𝐶𝐴𝑅 𝐶′ 𝐴𝑅 ⊂ 𝐶𝐴𝑅 is an explanation if 𝒔𝒑𝒆𝒄𝒊𝒂𝒍𝒊𝒛𝒆𝑭𝑺𝑮 𝐶𝐴𝑅 − 𝐶′ 𝐴𝑅, 𝑓𝑠𝑔 𝐴𝑅2𝐷𝐸 ) ≠ ∅
- 46. Explain Conflicts ❷ Determine which tactics and qualities are involved – Hitting Set Directed Acyclic Graph [Reiter:1987] – Diagnosis Theory [Reiter:1987] – QuickXplain [Junker:2004] – FastDiag [Felferning:2012] – Propagating Decisions [Chavarriaga:2014]
- 47. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs
- 48. FM for Architectural Tactics
- 49. FM for Architectural Tactics 6 Quality Attributes 79 Architectural Tactics Bass et al. Software Architecture in Practice Addison-Wesley 2014
- 50. FM for Jelastic Cloud Computing
- 51. Jelastic …Session Server App Server Tomcat Glassfish Jetty HA requires Tactics Performance Availability… forces TPC LB forces prohibits Passive Redundancy Active Redundancy Reduce Overhead HTTP LB Load Balancer Relating architectural tactics to configuration options
- 52. Relating architectural tactics to configuration options 52
- 53. Possible Combination of Tactics Availability Performance Security Testability Availability 289 277,151 54,527 867 Performance 959 91,105 2.877 Security 95 285 Testability 3
- 54. Possible Combination of Tactics Availability Performance Security Testability Availability 289 25 valid 264 confl 277,151 8 valid 277,143 confl 54,527 4,487 valid 50,040 confl 867 75 valid 792 confl Performance 959 31 valid 928 confl 91,105 2,945 valid 88,160 confl 2.877 93 valid 2784 confl Security 95 95 valid 0 confl 285 285 valid 0 confl Testability 3 3 valid 0 confl
- 55. detected Conflicts Availability Performance Security Testability Availability 91.3% 99.9% 91.7% 91.3% Performance 96.7% 96.7% 96.7% Security 0% 0% Testability 0%
- 56. Managing Trade-offs among Architectural Tactics using Feature Models and Feature-Solution Graphs
- 57. Conclusions • We have presented our approach – To model architectural tactics and their implementation – To detect trade-off points – To explain trade-off solutions • We have illustrated our approach using architectural tactics and design alternatives for database-based web applications.
- 58. Conclusions • Limitations: – Our approach only detects conflicts caused by constraints defined in the models. • Conflicts not related with constraints in the model cannot be detected – Only considers quality attributes that can be realized using architectural tactics • It does not consider attributes such as development and deployment costs. • Current/Future work: – Support for configuration processes with multiple vires and multiple stakeholders. – Specially those where stakeholders decide at the same time.
- 59. Questions ? Jaime Chavarriaga, jchavarr@vub.ac.be Carlos Noguera, cnogera@vub.ac.be Rubby Casallas, rcasalla@uniandes.edu.o Viviane Jonckers, vejoncke@vub.ac.be
Editor's Notes
- Estoy realizando mi investigación doctoral en el contexto de la administración de variabilidad, en particular en el uso de múltiples modelos de features para modelar productos complejos y guíar procesos colaborativos de configuración. Hoy voy a presentar nuestras ideas sobre como aplicar múltiples modelos de features y feature-solution graphs para gestionar trade-offs entre tácticas de arquitectura de software. El manejo de los trade-off es una tarea común en arquitectura de software, y aquí estamos presentando una propuesta para ayudar el trabajo de los arquitectos
- En la presentación, primero voy a explicar un poco las tácticas de arquitectura y la ocurrencia de los trade-offs, luego presentaré nuestra propuesta y algunas experiencias sobre su aplicación.
- En un producto de software, la arquitectura se define para atender los requerimientos en términos de funcionalidades y de atributos de calidad. Por ejemplo, en un producto determinado, el producto puede tener requerimientos en torno a atributos de calidad como rendimiento, disponibilidad, seguridad o escalabilidad.
- En propuestas como el Attribute Driven Design del Software Engineering Institute, los arquitectos toman los requerimientos de atributos de calidad y un conjunto de tácticas de arquitectura para definir la arquitectura del producto. Las tácticas de arquitectura son descripciones de diseños que permiten lograr un atributo de calidad. Por ejemplo, si el arquitecto debe cumplir con requerimientos en torno al rendimiento de la aplicación, puede usar diseños que planteen copias de computación, copias de datos o que reduzcan el overhead o la latencia de los procesos.
- Estas tácticas de arquitectura le premiten al arquitecto seleccionar que patrones de diseño incluir en la solución. Por ejemplo, si yo deseo mantener copias de computación puede usar un patrón con delegados de servicio que repartan tareas entre varios hilos o en un pool de objetos. Kim – other authors Quality-driven architecture development using architectural tactics
- Igualmente, para el caso de aplicaciones empresariales, estas tácticas también pueden ser implementadas usando patrones o esquemas de despliegue. Por ejemplo, si deseo lograr un mayor rendimiento aplicando la táctica de múltiples copias de computación, puedo usar diferentes opciones de despliegue. However, sometimes missed in the literature, there are other forms to implement architectural tactics. In Enterprise Platforms and Cloud Computing, some tactics can be implemented using deployment options. In these environments, applications run in application servers and middleware with multiple alternatives for configuration.
- Por ejemplo, con el fin de mantener copias de computación, el arquitecto de software puede optar por servidores de aplicaciones con un balanceo de carga o servidores de aplicaciones en cluster (Options to deploy in cloud computing) For instance, a Java application may be deployed in a Cloud platform such as Jelastic using multiple options. An application can be installed using a single tomcat application server, multiple application servers using an sticky session load balancer or an application server cluster with a non-sticky session load balancer
- Cada una de las tácticas se enfoca en un único atributo de calidad. Una situación de trade-off, de negociación, se da cuando se intentan lograr varios atributos de calidad al tiempo. Puede ocurrir que una decisión que ayude a lograr un atributo de calidad vaya en contra del logro de otro atributo de calidad. Si se tienen dos tácticas o dos patrones de diseño en conflicto. Es necesario que el arquitecto detecte el conflicto y seleccione una de las dos tácticas o patrones. Debe revisar cuál atributo de calidad es más importante o cuál táctica y patrón es más conveniente, seleccionar uno y desechar el otro.
- Por ejemplo, consideremos un caso en donde se desea lograr al tiempo rendimiento y disponibilidad
- Es posible que un arquitecto opte, para el rendimiento, por mantener copias de computación usando un balanceador de carga en TCP/IP, que es muy rápido. Por otro lado, el mismo arquitecto, intentando lograr disponibilidad, puede optar por utilizar redundancia activa usando servidores en clusters.
- Es posible que un arquitecto opte, para el rendimiento, por mantener copias de computación usando un balanceador de carga en TCP/IP, que es muy rápido. Por otro lado, el mismo arquitecto, intentando lograr disponibilidad, puede optar por utilizar redundancia activa usando servidores en clusters.
- Es posible que un arquitecto opte, para el rendimiento, por mantener copias de computación usando un balanceador de carga en TCP/IP, que es muy rápido. Por otro lado, el mismo arquitecto, intentando lograr disponibilidad, puede optar por utilizar redundancia activa usando servidores en clusters.
- Cada una de las tácticas se enfoca en un único atributo de calidad. Una situación de trade-off, de negociación, se da cuando se intentan lograr varios atributos de calidad al tiempo. Puede ocurrir que una decisión que ayude a lograr un atributo de calidad vaya en contra del logro de otro atributo de calidad. Si se tienen dos tácticas o dos patrones de diseño en conflicto. Es necesario que el arquitecto detecte el conflicto y seleccione una de las dos tácticas o patrones. Debe revisar cuál atributo de calidad es más importante o cuál táctica y patrón es más conveniente, seleccionar uno y desechar el otro.
- Feature Models have been used to represent variability in a domain. For instance, to represent which options or configuration elements can be included in an application. Our approach is based on feature models to represent alternatives about the architectural tactics that can be used to achieve a Quality Attribute and the Diverse options to configure Jelastic. We are proposing the use of Feature-Solution graphs to relate the architectural tactics to the jelastic configuration options. We use these graphs to represent how an architectural tactic can be implemented using that configuration options.
- Cada una de las tácticas se enfoca en un único atributo de calidad. Una situación de trade-off, de negociación, se da cuando se intentan lograr varios atributos de calidad al tiempo. Puede ocurrir que una decisión que ayude a lograr un atributo de calidad vaya en contra del logro de otro atributo de calidad. Si se tienen dos tácticas o dos patrones de diseño en conflicto. Es necesario que el arquitecto detecte el conflicto y seleccione una de las dos tácticas o patrones. Debe revisar cuál atributo de calidad es más importante o cuál táctica y patrón es más conveniente, seleccionar uno y desechar el otro.
- Extractos -números, con tamaño
- Numero de opciones Note they are features…
- Cada una de las tácticas se enfoca en un único atributo de calidad. Una situación de trade-off, de negociación, se da cuando se intentan lograr varios atributos de calidad al tiempo. Puede ocurrir que una decisión que ayude a lograr un atributo de calidad vaya en contra del logro de otro atributo de calidad. Si se tienen dos tácticas o dos patrones de diseño en conflicto. Es necesario que el arquitecto detecte el conflicto y seleccione una de las dos tácticas o patrones. Debe revisar cuál atributo de calidad es más importante o cuál táctica y patrón es más conveniente, seleccionar uno y desechar el otro.
- Cada una de las tácticas se enfoca en un único atributo de calidad. Una situación de trade-off, de negociación, se da cuando se intentan lograr varios atributos de calidad al tiempo. Puede ocurrir que una decisión que ayude a lograr un atributo de calidad vaya en contra del logro de otro atributo de calidad. Si se tienen dos tácticas o dos patrones de diseño en conflicto. Es necesario que el arquitecto detecte el conflicto y seleccione una de las dos tácticas o patrones. Debe revisar cuál atributo de calidad es más importante o cuál táctica y patrón es más conveniente, seleccionar uno y desechar el otro.
- Cada una de las tácticas se enfoca en un único atributo de calidad. Una situación de trade-off, de negociación, se da cuando se intentan lograr varios atributos de calidad al tiempo. Puede ocurrir que una decisión que ayude a lograr un atributo de calidad vaya en contra del logro de otro atributo de calidad. Si se tienen dos tácticas o dos patrones de diseño en conflicto. Es necesario que el arquitecto detecte el conflicto y seleccione una de las dos tácticas o patrones. Debe revisar cuál atributo de calidad es más importante o cuál táctica y patrón es más conveniente, seleccionar uno y desechar el otro.
- Extractos -números, con tamaño
- Extractos -números, con tamaño
- Numero de opciones Note they are features…
- From 2,147,483,647 combinations of tactics only 210,862,079 results in valid configurations in Jelastic.
- Usamos técnicas que estamos desarrollando en nuestor proyecto doctoral
- Future work: Recommenders for cloud configuration in Jelastic and other platforms - Tool support for FS-Graphs