Presentation slides of my PhD defense

1. Non-Functional Requirements
as drivers of
Software Architecture Design
David Ameller
Barcelona, 23th January 2014
Thesis supervised by Xavier Franch

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. Introduction

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
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
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
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
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
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
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
Example (3/3)
ACME Luxury
ACME World-wide
Different NFR specifications
lead to different software
systems

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. DSDM
Euromicro SEAA RE (31 cites)
2007
2008
2009
2010
PART I
NFRs in Model-Driven Development
2011
2012
2013

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
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
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
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
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
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
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
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. 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
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
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
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
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
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. 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
Divided in two modules
Described in UML
Extendibility and Reuse
Minimal encoding bias
Minimal ontological commitment

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
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 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
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
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
ArchiTech

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. Conclusions

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
Thank
you

40. 40