PhD defense: David Ameller


Published on

Presentation slides of my PhD defense

Published in: Career, Technology, Education
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

PhD defense: David Ameller

  1. 1. Non-Functional Requirements as drivers of Software Architecture Design David Ameller Barcelona, 23th January 2014 Thesis supervised by Xavier Franch
  2. 2. 2 Outline Introduction PART I NFRs in Model-Driven Development PART II PART III NFRs in Software Architecture Arteon, Quark, and ArchiTech Conclusions
  3. 3. Introduction
  4. 4. 4 Non-Functional Requirements (NFRs) The system 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. 5 Model-Driven Development (MDD) “is simply 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. 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.
  7. 7. 7 Relation of NFRs with 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. 8 Objective of this thesis 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. 9 Example (1/3) ACME travel agency 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. 10 Example (2/3) Architectural styles and 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. 11 Example (3/3) ACME Luxury ACME World-wide Different NFR specifications lead to different software systems
  12. 12. 12 Timeline PART I PART II PART III 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. 13. DSDM Euromicro SEAA RE (31 cites) 2007 2008 2009 2010 PART I NFRs in Model-Driven Development 2011 2012 2013
  14. 14. 14 Objective of PART I 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. 15 Current approach (in practice) 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. 16 Our approach (automatic) All requirements 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. 17 Our approach (interactive) The first 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. 18 Example Knowledge Models PIM (nf) R1: The system shall detect and report unauthorized data access PIM/PSM (nf) App. server DBMS Security FW + Firewall Requirements Source subsystem Protected subsystem Architecture
  19. 19. 19 Benefits of our approach NFRs are fully integrated into MDD No need to modify the code Architectural decisions depend on NFRs Knowledge reuse
  20. 20. 20 Drawbacks of our approach New model (PIM/PSM) need to be maintained New transformations are needed We need to maintain the architectural knowledge
  21. 21. 21 Conclusions of PART I 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. 22. First study Second study RE IEEESoft. (IF 1.5) ECSA EASA REFSQ 2007 2008 2009 PART II NFRs in Software Architecture 2010 Third study 2011 2012 2013
  23. 23. 23 Empirical studies Study the role 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. 24 First study Non-Functional Requirements in 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. 25 Second study How do software 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. 26 Third study The role of 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. 27 Conclusions of PART II 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. 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. 29 Arteon Architectural knowledge ontology Divided in two modules Described in UML Extendibility and Reuse Minimal encoding bias Minimal ontological commitment
  30. 30. 30 Arteon: SE Module Logical view 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. 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. 32 Quark Architects shall have a central role Architects shall have the last word Quark Requirements Decisions Architects shall be able to reuse decisions Decisions shall provide detailed information
  33. 33. 33 Quark 2 Decision inference Constraints and QRs Prioritization Guidance Decisions 1 Architectural specification Requirements 3 Decision making Incompatibilities Evaluation Constraints QRs Constraints and QRs 4 Architectural refinement Dependencies Restrictions Decisions Decisions
  34. 34. 34 ArchiTech Implemented as Eclipse Plugin Knowledge management and decision-making ArchiTech-CRUD Implementation of Arteon ArchiTech-DM Implementation of Quark Implemented by Oriol Collell
  35. 35. 35 ArchiTech
  36. 36. 36 Conclusions of PART III 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. 37. Conclusions
  38. 38. 38 Conclusions of this thesis 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. 39. 39 Thank you
  40. 40. 40