Downloaded 22 times
![6
Software Architecture (SA)
Presentation
Business
“The software
architecture […] is the
structure or structures
of the system”
Persistence
L. Bass, P. Clements, and R. Kazman.
Software Architecture in Practice, 2003.](https://image.slidesharecdn.com/phdpresentation-140123040456-phpapp01/85/PhD-defense-David-Ameller-6-320.jpg)
Uploaded byDavid Ameller
PhD defense: David Ameller
This thesis explores how non-functional requirements (NFRs) can drive software architecture design. It proposes a model-driven development framework that fully integrates NFRs. Empirical studies show that architects consider NFRs just as important as functional requirements when making decisions. The thesis also presents Arteon, an ontology for architectural knowledge; Quark, a method for decision-making based on NFRs; and ArchiTech, a tool that implements Arteon and Quark.
More Related Content
Similar to PhD defense: David Ameller
PhD defense: David Ameller
- 1. Non-Functional Requirements as driversof Software Architecture Design David Ameller Barcelona, 23th January 2014 Thesis supervised by Xavier Franch
- 2. 2 Outline Introduction PART I NFRs inModel-Driven Development PART II PART III NFRs in Software Architecture Arteon, Quark, and ArchiTech Conclusions
- 3.
- 4. 4 Non-Functional Requirements (NFRs) Thesystem shall support real-time operations The system shall keep our current Data Base Management System “a description of a property or characteristic that a software system must exhibit or a constraint that it must respect” K. Wiegers. Software Requirements, 2003.
- 5. 5 Model-Driven Development (MDD) “issimply the notion that we can construct a model of a system that we can then transform into the real thing” S. Mellor et al., “Model-Driven Development”. IEEE Software, 2003. PIM HelloWorld Show() M2M PSM GWT HelloWorld POJO M2T Code Show() JDBC … show() { print(“Hello World”); }
- 6. 6 Software Architecture (SA) Presentation Business “Thesoftware architecture […] is the structure or structures of the system” Persistence L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice, 2003.
- 7. 7 Relation of NFRswith MDD and SA PART I PART II & III NFRs MDD NFRs make MDD adaptable, while MDD could be used to systematize NFRs SA NFRs are used to make architectural decisions, while architectural knowledge could be used to reason about NFRs
- 8. 8 Objective of thisthesis Explore the role of Non-Functional Requirements in the Software Architecture Design Propose novel ideas to integrate NFR in software development Run empirical studies of the current architectural practices Design new techniques, methods, and tools
- 9. 9 Example (1/3) ACME travelagency web portal ACME luxury: travel packages to exotic destinations in 5-star hotels ACME world-wide: hundreds of travel packages Functional requirements are equal User management Payment facilities Searches Non-Functional Requirements have differences Security: “The system shall detect and report unauthorised data accesses” Scalability: “The system should be prepared to high connection demands to ensure the success of the portal”
- 10. 10 Example (2/3) Architectural stylesand components Types of NFR Performance Security Availability Maintenance Scalability Complexity Single-Server Configuration Poor Poor Poor Good Poor Good DBMS separated Average Good Poor Average Poor Average Firewall Replication Neutral Improve Neutral Damage Neutral Damage Improve Neutral Improve Damage Improve Damage The table is based on S. Ceri et al., Designing Data-Intensive Web Applications, 2002.
- 11. 11 Example (3/3) ACME Luxury ACMEWorld-wide Different NFR specifications lead to different software systems
- 12. 12 Timeline PART I PART II PARTIII 2007 2008 PART I 2009 2010 2011 2012 2013 NFRs in Model-Driven Development PART II NFRs in Software Architecture PART Arteon, Quark, and ArchiTech III
- 13. DSDM Euromicro SEAA RE(31 cites) 2007 2008 2009 2010 PART I NFRs in Model-Driven Development 2011 2012 2013
- 14. 14 Objective of PARTI Define a MDD framework that integrates NFRs Most existing MDD approaches do not consider NFRs It is problem with critical consequences “A Comedy of Errors: the London Ambulance Service case study” Anthony Finkelstein & John Dowell, 1993.
- 15. 15 Current approach (inpractice) Modify the PSM, the M2T transformation and the generated code Longer production, lower reliability, and worse maintenance Modify the M2M transformation in order to support specific NFRs Increases complexity, longer production if new transformation is needed
- 16. 16 Our approach (automatic) Allrequirements are specified at PIM level We propose to use M2M transformations able to deal with NFRs (M2March, M2Mtech) We propose an intermediate model (PIM/PSM) to reflect architectural decisions made from NFRs The code (software product) is compliant with the stated NFRs
- 17. 17 Our approach (interactive) Thefirst approach is conceptually sound but may be too complex In this case PIM is unaware of NFRs We propose to use human interaction to obtain NFRs (with architectural and technological consequences) Hybrid approaches are possible
- 18. 18 Example Knowledge Models PIM (nf) R1: Thesystem shall detect and report unauthorized data access PIM/PSM (nf) App. server DBMS Security FW + Firewall Requirements Source subsystem Protected subsystem Architecture
- 19. 19 Benefits of ourapproach NFRs are fully integrated into MDD No need to modify the code Architectural decisions depend on NFRs Knowledge reuse
- 20. 20 Drawbacks of ourapproach New model (PIM/PSM) need to be maintained New transformations are needed We need to maintain the architectural knowledge
- 21. 21 Conclusions of PARTI We proposed a flexible framework to deal with NFRs in MDD The architecture should be part of the MDD process to support NFRs Need to gather knowledge that relates NFRs and Architectural decisions
- 22. First study Second study RE IEEESoft. (IF1.5) ECSA EASA REFSQ 2007 2008 2009 PART II NFRs in Software Architecture 2010 Third study 2011 2012 2013
- 23. 23 Empirical studies Study therole of NFRs in Software Architecture First study Second study Third study Type Electronic survey Interviews Electronic survey Number of respondents 60 13 31 Number of RQs 5 6+7 3 Target population Software industry Software architects Software architects Target information Practical experience Single project Single project/NFR Population origin World-wide (>50% Spain) Spain World-wide Execution 2009 2010 2011 Publication 2010 2012/13 2013
- 24. 24 First study Non-Functional Requirementsin industrial practice Half of respondents did not use NFRs to make architectural decisions Respondents stated that: “need tools for NFRs management” Respondents stated that: “want to have the last word on decision-making” More empirical evidence for software architecture is needed
- 25. 25 Second study How dosoftware architects deal with Non-Functional Requirements? Companies did not have the role of architect clearly defined NFRs were mostly elicited by the architects Architects considered Non-technical NFRs as relevant as technical NFRs Most of the architectural decisions had the influence of a NFR
- 26. 26 Third study The roleof Quality Attributes in Service-Based Systems design QAs are often considered as important as functionality We could not identify QAs predominance in particular domains We could not find a relation between QAs and decisions Ad-hoc decisions are often used in SBS
- 27. 27 Conclusions of PARTII Architects take into account all kinds of requirements in architectural decisions There is a wide space in the gap between researchers and practitioners Replication and new empirical studies are required in this area
- 28. ArchiTech Quark Arteon DSDM 2007 2008 2009 PART III Arteon,Quark, and ArchiTech IWSSA TOPI RESPE CIbSE (among best papers) 2010 2011 2012 2013
- 29. 29 Arteon Architectural knowledge ontology Dividedin two modules Described in UML Extendibility and Reuse Minimal encoding bias Minimal ontological commitment
- 30. 30 Arteon: SE Module Logicalview Architectural Element 3-Layers style Style 4+1 views framework Architectural View 3-Layers with data-mapper Persistence layer Style Variation Component Architectural Framework Hibernate Implementation
- 31. 31 Arteon: R Module Attribute Constraint Attribute“License” Attribute “License” equal “OSS” Restriction Element “Apache” Decisional Element Condition Quality Attribute Decision “Use Apache” Decision Element Attribute “Reliability” Effect “Improved” Value “OSS” Value
- 32. 32 Quark Architects shall have acentral role Architects shall have the last word Quark Requirements Decisions Architects shall be able to reuse decisions Decisions shall provide detailed information
- 33.
- 34. 34 ArchiTech Implemented as EclipsePlugin Knowledge management and decision-making ArchiTech-CRUD Implementation of Arteon ArchiTech-DM Implementation of Quark Implemented by Oriol Collell
- 35.
- 36. 36 Conclusions of PARTIII Arteon provides a way to share and reuse architectural knowledge Quark provides a decision-making method and improves the reliability of the process ArchiTech implements both, and serves as a proof of concept
- 37.
- 38. 38 Conclusions of thisthesis Theoretical approach that handles NFRs in the MDD process Empirical studies oriented to understand software architects, and in particular the role of NFRs Created means to manage architectural knowledge, and then use it to make architectural decisions
- 39.
- 40.