phd defense: david ameller
Post on 10-May-2015
1.452 Views
Preview:
DESCRIPTION
TRANSCRIPT
Software Architecture Design
Non-Functional Requirements
as drivers of
David Ameller
Barcelona, 23th January 2014
Thesis supervised by Xavier Franch
2
Outline
Introduction
PART I
PART II
PART III
Conclusions
NFRs in Model-Driven Development
NFRs in Software Architecture
Arteon, Quark, and ArchiTech
Introduction
4Non-Functional Requirements (NFRs)
“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.
The system shall keep our current Data Base Management System
The system shall support real-time
operations
5
Model-Driven Development (MDD)
M2M
M2T
PIM
PSM
Code
HelloWorld
Show()
HelloWorld
Show()
GWT
POJO
JDBC
…show() { print(“Hello World”);}
“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.
6
Software Architecture (SA)
“The software architecture […] is
thestructure or
structures of the system”
L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice, 2003.
Presentation
Persistence
Business
7
Relation of NFRs with MDD and SA
NFRsMDD SA
NFRs make MDD adaptable, while
MDD could be used to
systematize NFRs
NFRs are used to make
architectural decisions, while
architectural knowledge could be used to reason
about NFRs
PART I PART II & III
8
Objective of this thesis
Explore the role of Non-Functional Requirements
in the Software Architecture
DesignPropose novel ideas to integrate NFR in software
development
Run empirical studies of the current architectural practices
Design new techniques, methods, and tools
9
Example (1/3)
ACME travel agency web portalACME luxury: travel packages to exotic destinations in 5-star hotelsACME world-wide: hundreds of travel packages
Functional requirements are equalUser managementPayment facilitiesSearches
Non-Functional Requirements have differencesSecurity: “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”
10Example (2/3)
Single-Server
Configuration
DBMS separated Firewall Replication
Performance Poor Average Neutral ImproveSecurity Poor Good Improve NeutralAvailability Poor Poor Neutral ImproveMaintenance Good Average Damage DamageScalability Poor Poor Neutral ImproveComplexity Good Average Damage DamageThe table is based on S. Ceri et al., Designing Data-Intensive Web Applications, 2002.
Types
of
NFR
Architectural styles and components
11Example (3/3)
Different NFR specifications lead to different software
systems
ACME Luxury
ACME World-wide
12Timeline
2007 2008 2009 2010 2011 2012 2013
PART I
PART IIPART III
NFRs in Model-Driven DevelopmentNFRs in Software Architecture
Arteon, Quark, and ArchiTech
PART I
PART II
PART III
PART INFRs in Model-Driven Development
2007 2008 2009 2010 2011 2012 2013
DSDMEuromicro SEAA RE (31 cites)
14Objective of PART I
Define a MDD framework that integrates NFRs
It is problem with critical consequences
Most existing MDD approaches do not consider NFRs
“A Comedy of Errors: the London Ambulance Service case study”Anthony Finkelstein & John Dowell, 1993.
15Current 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
16Our 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
17Our 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
18Example
Models
Know
led
ge
PIM (nf) PIM/PSM (nf)
Requirements Architecture
R1: The system shall detect and report unauthorized data
access
Security
Firewall
+
FW
Source subsyste
m
Protected subsyste
m
App. server
DBMS
19Benefits of our approach
vs.NFRs are fully integrated into MDD
No need to modify the code
Architectural decisions depend on NFRs
Knowledge reuse
20Drawbacks of our approach
vs.
New model (PIM/PSM) need to be maintained
New transformations are neededWe need to maintain the architectural knowledge
21Conclusions 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
PART IINFRs in Software Architecture
2007 2008 2009 2010 2011 2012 2013
EASA REFSQ
Firststudy
RE IEEE
Secondstudy
Soft. (IF 1.5)
Thirdstudy
ECSA
23Empirical studies
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
Study the role of NFRs in Software Architecture
24First study
Non-Functional Requirements in industrial practice
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
Half of respondents did not use NFRs to make architectural decisions
25Second 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
26Third study
The role of Quality Attributes in Service-Based Systems
design
We could not identify QAs predominance in particular domains
We could not find a relation between QAs and decisions
QAs are often considered as important as functionality
Ad-hoc decisions are often used in SBS
27Conclusions 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
PART IIIArteon, Quark, and ArchiTech
2007 2008 2009 2010 2011 2012 2013
DSDM
Arteon
IWSSA TOPI RESPE
ArchiTech
CIbSE(among best papers)
Quark
29Arteon
Architectural knowledge ontology
Divided in two modules
Described in UML
Extendibility and Reuse
Minimal encoding bias
Minimal ontological commitment
30
ArchitecturalView
ArchitecturalFramework
Style StyleVariation Component Implemen-
tation
ArchitecturalElement
Arteon: SE Module
4+1 views framework
Logical view
3-Layers style
3-Layers with data-
mapper
Persistence layer Hibernate
31
Constraint
Decisional Element
Restriction Element AttributeQuality Attribute
Decision
Effect
Value
Condition
Attribute
Arteon: R Module
Attribute “License” equal “OSS”
Attribute “License”
Element “Apache”
Value “OSS”
Decision “Use
Apache”
“Reliability”
“Improved”
32Quark
DecisionsRequirements
Architects shall have the last
word
Architects shall have a central
role
Architects shall be able to
reuse decisions
Decisions shall provide detailed
information
Quark
33Quark
Decisionmaking
Architecturalspecification
Decisioninference
Architecturalrefinement
2
1 3
4
Decisions
DecisionsConstraints and QRs
Constraints and QRs
Requirements Decisions
DependenciesRestrictions
EvaluationIncompatibilities
GuidancePrioritization
ConstraintsQRs
34ArchiTech
Implemented as Eclipse Plugin
Knowledge management and decision-making
ArchiTech-CRUD
Implemented by Oriol Collell
ArchiTech-DM
Implementation of Arteon
Implementation of Quark
35ArchiTech
36Conclusions 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
Conclusions
38Conclusions 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
Thankyou
40
?.
top related