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.
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
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
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
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
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
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
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
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
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
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
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
The outline of the presentation will begin with an introduction, then the motivation, the SOTA, then our proposal, an NFR #en efar# aware MDD process. And finally the research agenda and the conclusions.
To end with the introduction I want to clarify which is the objective of this work.#read blue box#We need to identify these challenges #read answer 1#.#haw# To do so, #read answer 2#.
The approaches that not support NFRs can deal with NFRs outside of the process.One way is to Modify the PSM… #read##click# Other way is to modify the M2M… #read##click# the situation is worse if… #read#
Many authors said that NFRs and the architecture of the system are very related topics, in fact this conference have a whole dedicated session to architecture. Concretely we think that NFRs are used to make architectural decisions.#click# also we consider as a type of these decisions, the technological decisions. For example a requirement such as #read NFR# will impact on a technological decision.
To motivate this work I will use an example about a travel agency with two scenarios. On the one hand ACME luxury that offers vacation packages…In the other hand ACME WW offers…Both scenarios share common functionalities. For example user management…
To exemplify the impact of the NFRs in the architecture we will use as example the deployment view. For this view of the architecture we have several configurations e.g. SSC and DBMS separated. And we have several components that can be used with these configurations.
#click# In this table we see the relationship between quality attributes and NFRs. Observe that the configurations have concrete values while the components can improve or damage the initial values.#click# in the concrete case of the ACME travel agency. Scalability will determine the use of replication #click# and the Security will determine the use of BDMS separated and Firewall.
Here we can see again that different NFRs lead to different software systems.So, Our position.. #read#
As I said before, a MDD process should be able to deal with NFRs and also should be able to certify the result is compliant with the specified NFRs.To do this we propose two variants of a process that can deal with NFRs.One is fully automatic and the second one is interactive.
The problem of the previous variant is that it is too complex. For this variant we use a standard “pi Ai Em” #click#, a PIM unaware of NFRs.And we use #click# interaction with the user to obtain the NFRs necessary to: first, generate the architecture, and second, generate the PSM.From this point we will have all necessary NFRs to generate the software product.#click# it is important to notice that these are extreme variants, it is more than possible that the best solution is between the two variants.
#read##click&read##click&read#
In the paper you will find a more exhaustive list of topics that require further research. This is a selection of the most relevant ones.#click&read##click&read##click&read##click&read##click&read##click&read##click&read#