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

?.