This document outlines a proposed systematic architecture design (SAD) framework that aims to integrate non-functional requirements (NFRs) into model-driven development (MDD) processes. It presents a motivation example comparing two travel agency systems with different NFRs. It then proposes an NFR-aware MDD process with either automatic or interactive variants. The SAD contributions include tools like ArchiTech and an ontology-based knowledge system called Arteon. Future work includes further implementing and validating parts of the proposed framework through empirical studies.

1. Systematic Architecture
Design

David Ameller
<dameller@essi.upc.edu>

2. Systematic Architecture Design
Outline
1.
2.
3.
4.
5.
6.
Introduction
Motivation example
NFR-aware MDD process
SAD contributions
Arteon
Conclusions and future work
2

3. Systematic Architecture Design
1. INTRODUCTION
3

4. Systematic Architecture Design
1.1 (Initial) Objective
Define a MDD
framework that
integrates NFRs
• Why?
– NFRs is one of our topics of interest
– It is problem with critical consequences
– Most existing MDD approaches do not consider
NFRs
4

5. Systematic Architecture Design
1.2 Main topics
Adaptable process
MDD
NFRs
Semi-automatic
treatment
5

6. Systematic Architecture Design
1.3 MDD definition
PIM
HelloWorld
M2M
Show()
PSM
Swing
HelloWorld
POJO
Show()
M2T
Code
JDBC
…
show() {
print(“Hello World”);
}
…
“Model-driven
development 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

7. Systematic Architecture Design
1.4 State of practice
• NFRs are dealt outside of the MDD process
• Modify the PSM, the M2T transformation
and the generated code
E.g. Modify the code to obtain a service application
Longer production, lower reliability, and
worse maintenance
• Modify the M2M transformation in order to
support specific NFRs
E.g. Add SOA to the M2M transformation
Increases complexity, longer production if
new transformation is needed
This situation is even worse if we consider
the current tool limitations
7

8. Systematic Architecture Design
1.5 The role of NFRs
Many prominent researchers say that NFRs mainly
impact on the architecture, more concretely in the
decision making process.
Security
Req. "The system shall detect and
report unauthorised data accesses”
Architectural
decisions
Integrability
Req. "The system shall keep our
current Data Base Management
System (DBMS)”
Technological
decisions
8

9. Systematic Architecture Design
2. MOTIVATION EXAMPLE
9

10. Systematic Architecture Design
2. Motivation example (I)
• ACME travel agency web portal
• We consider two different scenarios:
A. ACME luxury offers vacation packages to exotic
destinations in 5-star hotels.
B. ACME world-wide offers hundreds of packages from
other transportation and accommodation sites.
10

11. Systematic Architecture Design
2. Motivation example (II)
• Both scenarios have common functionalities
 User management, payment facilities, searches
• But some NFRs are different:
ACME Luxury
ACME World-wide
Security
“The system shall detect and “The system shall detect and
report unauthorised data
report unauthorised data
accesses”
accesses”
Scalability
Not important, low expected
visitors
“The system should be
prepared to high connection
demands to ensure the
success of the portal”
11

12. Systematic Architecture Design
2. Motivation example (III)
• Starting the decision making
 The type of application
• It is a constraint of the system to be a web application
 The architecture of the system
• In this example, we focus on the deployment view
12

13. Systematic Architecture Design
2. Motivation example (IV)
• Architectural decisions
Performance
Security
Availability
Maintenance
Scalability
Complexity
Single-Server
Configuration
Poor
Poor
Poor
Good
Poor
Good
DBMS separated
Firewall
Replication
Average
Good
Poor
Average
Poor
Average
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.
13

14. Systematic Architecture Design
2. Motivation example (V)
Different NFR specifications lead to different
software systems
ACME Luxury
ACME World-wide
Our position is that it should be possible to
generate both systems with a MDD process
that considers NFRs
14

15. Systematic Architecture Design
3. NFR-AWARE MDD PROCESS
15

16. Systematic Architecture Design
3. Our proposal
A MDD process should be able to deal with NFRs
and should be able to certify that the result is
compliant with the initial NFRs
Drive
NFRs ADs
Compliance
• We explore two variants of the MDD process:
 Automatic and Interactive
16

17. Systematic Architecture Design
3.1 Automatic NFR-aware MDD
• 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

18. Systematic Architecture Design
3.2 Interactive NFR-aware MDD
• 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

19. Systematic Architecture Design
3.3 Firewall example
• Deciding the need of firewall components
19

20. Systematic Architecture Design
3.4 Benefits of our proposal
 NFRs are fully integrated into MDD
 No need to modify the code
 Architectural decisions depend on NFRs
 Knowledge reuse
20

21. Systematic Architecture Design
3.5 Drawbacks of our proposal
New model (PIM/PSM) need to be maintained
New transformations are needed
We need to maintain the architectural
knowledge
21

22. Systematic Architecture Design
4. SAD CONTRIBUTIONS
22

23. PIMF+NF
M2MArch
PIM/PSM
F+NF
• What do we need to do?
 The main effort should be to
include architectural design as
part of the MDD.
M2MTech
PSMF+NF
M2T
He
lp t
Ar
c
od
rede hiitscc
aso e otv
cn
isa uer l
ion raan
bos
ut d
NFRs
c
ati s
tom ces
n
-au e pro t
mi altme
Se pttab
a re
Ad
Systematic Architecture Design
4.1 From MDD to Architecture
AK
MDD
Architectural design
Need of detailed
as part of the process
knowledge
CodeF+NF
23

24. 4.2 SAD Overview
Systematic Architecture Design
PIMNF
Context
PIMNF
SRS NF
Human
support
PIMF
M2MArch
SAD
Architectural
decisions
Architectural
views
M2MTech
PSMF+NF
24

25. Systematic Architecture Design
4.2 SAD Overview
Context
SRSNF
Requirements
analysis
Human
support
Quality
Goals
And
Constraints
Architectural
decision-making
Architectural
decisions
25

26. Systematic Architecture Design
4.3 Quark method
Knowledge
acquisition
26

27. Systematic Architecture Design
4.4 Arteon
Arteon
Requirements
Stakeholder
needs
Rationale
Constraints
and goals
to fulfill
Structural
Elements
Architectural
elements
to use
MDD
Transformations
to apply
* One of the design principles recommended the separation of ontology concepts in modules
Architecture
design
27

28. Systematic Architecture Design
4.5 ArchiTech
• Implemented as Eclipse Plugin
 To be near the MDD community
• Knowledge management is already
implemented
• We are working now on the Decision-Making
part of the tool
 As a difference, the tool will use a question-answer
mechanism to obtain the non-functional aspects
• Implemented by Oriol Collell
28

29. Systematic Architecture Design
4.6 Empirical studies
• “How do Software Architects consider Non-Functional
Requirements: A Survey”
 Electronic survey, 60 software architects.
• “How do Software Architects consider Non-Functional
Requirements: An Exploratory Study”
 13 semi-structured interviews.
• “The role of quality attributes in service-based systems
design”
 Electronic survey, 31 SOA software architects.
• Everis collaboration
 9 semi-structured interviews.
29

30. Systematic Architecture Design
5. ARTEON
30

31. Systematic Architecture Design
5.1 Introduction
AK1 = Design + Decisions + Rationale
Ontologybased AK
Support
System
1Kruchten et
al. “Building up and reasoning about architecture knowledge”, 2006.
31

32. Systematic Architecture Design
5.2 Arteon overview
Arteon
Requirements
Stakeholder
needs
Rationale
Constraints
and goals
to fulfill
Structural
Elements
Architectural
elements
to use
MDD
Transformations
to apply
* One of the design principles recommended the separation of ontology concepts in modules
Architecture
design
32

33. Systematic Architecture Design
5.3 Structural Elements (I)
File
PHP
Apache
MySQL
33

34. Systematic Architecture Design
5.3 Structural Elements (II)
Logical
File
Development
PHP
Deployment
Platform
Apache
MySQL
34

35. Systematic Architecture Design
5.3 Structural Elements (III)
35

36. Systematic Architecture Design
5.3 Structural Elements (IV)
Architectural
Element
Style
belong_to
*
belong_to
Architectural
Architectural
View
1
* Framework
*
ViewModel
Style
Variation
Component
Implementation
36

37. Systematic Architecture Design
5.3 Structural Elements (V)
3-layer style
(Layered style)
Web development
(Package based)
Web deployment
(DBMS separated)
LAMP
(Stack solution)
Architectural views
have their own
styles
37

38. Systematic Architecture Design
5.3 Structural Elements (VI)
Variations:
• DAO
• Controllers
• Replication
• OSS
DAO and datamapper are not
combinable
Components:
• Class, Layer
• Package
• Server
• Script language
Layers are
composed by
classes
38

39. Systematic Architecture Design
5.3 Structural Elements (VII)
specializes
related_to
0..1 * * *
Architectural
Element
Architectural
View
Architectural
Framework
{ Disjoint }
< variation_for
1
Style
1..*
< apply_to
*
*
Style
Variation
*
incompatible_with
*
implementable_with
*
*
Component
* *
connectable_with
*
*
Implementation
* *
composable_with
< apply_to
39

40. 5.4 Reasoning module (I)
Systematic Architecture Design
impose
*
*
Property
Decision
/set_action_over
*
Decisional
Element
*
*
Architectural
Element
*
{ disjoint,
complete}
Existence
Decision
*
1..*
/have_impact_on
Decision
/give_value
/set_condition
1..*
Element
Property
Quality
Attribute
*
{ disjoint,
complete}
Attribute
40

41. 5.4 Reasoning module (II)
“use only OSS”
Systematic Architecture Design
impose
/have_impact_on
Decision
*
*
{ disjoint,
complete}
Property “License” equal “OSS”
Existence
Decision
*
1..*
*
Element “Apache”
Architectural
Element
Property
Decision
/set_action_over
*
Decisional Element “Apache” has the value
Element “OSS” for the property “License”
*
*
/give_value
/set_condition
1..*
Element
Property
Property “License”
Quality
Attribute
*
{ disjoint,
complete}
Attribute
41

42. Systematic Architecture Design
5.5 Benefits of Arteon
Share AK between architects
Ontologybased AK
Support
System
Reuse AK between projects
Community oriented solution
Decision-making guidance
More reliability to architecture design
42

43. Systematic Architecture Design
6. CONCLUSIONS AND FUTURE WORK
43

44. Systematic Architecture Design
6.1 Conclusions
• We have…
 Formulated an NFR-aware general process
• Explored variations of this process
• Compared all different alternatives
 Described the SAD role and its contributions
• ArchiTech, Arteon, Quark, …
 Went into the details of Arteon
44

45. Systematic Architecture Design
6.2 Future work
• Our research agenda includes:
 In relation to the presented work
•
•
•
•
Consider the bottom-up process
Include correctness and completeness
Implement the key-parts of the framework
Modeling NFRs as part of the MDD process
 Drive empirical studies to:
• Obtain Architectural Knowledge
• Understand the architectural design practice (NFRs)
• Validate the ontology in a case study
45

46. Comments and Questions
David Ameller
<dameller@essi.upc.edu>