systematic architecture design

Systematic Architecture Design

David Ameller

<[email protected]>

2

Outline

1. Introduction2. Motivation example3. NFR-aware MDD process4. SAD contributions5. Arteon6. Conclusions and future work


3


1. INTRODUCTION

4


1.1 (Initial) Objective

Why?NFRs is one of our topics of interest

It is problem with critical consequencesMost existing MDD approaches do not consider NFRs

Define a MDD framework that integrates NFRs

5


1.2 Main topics

Semi-automatic treatment

NFRs MDDAdaptable process

6

1.3 MDD definition

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


M2M

M2T

PIM

PSM

Code

HelloWorld

Show()

HelloWorld

Show()

Swing

POJO

JDBC

…show() { print(“Hello World”);

}…

7

• 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

• 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

1.4 State of practice

• NFRs are dealt outside of the MDD processSystematic Architecture Design

This situation is even worse if we consider the current tool limitations

8

1.5 The role of NFRsSystematic Architecture Design

Req. "The system shall keep our current Data Base Management System (DBMS)”

Many prominent researchers say that NFRs mainly impact on the architecture, more concretely in the decision making process.

Req. "The system shall detect and report unauthorised data accesses”

Security

Integrability

Architectural decisions

Technological decisions

9


2. MOTIVATION EXAMPLE

10

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.


11

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 report unauthorised data accesses”

“The system shall detect and report unauthorised data accesses”

Scalability Not important, low expected visitors

“The system should be prepared to high connection demands to ensure the success of the portal”

12

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


13

• Architectural decisions

2. Motivation example (IV)

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 Damage


The table is based on S. Ceri et al., Designing Data-Intensive Web Applications, 2002.

14

2. Motivation example (V)Systematic Architecture Design

ACME Luxury

ACME World-wide

Different NFR specifications lead to different software systems

Our position is that it should be possible to generate both systems with a MDD process that considers NFRs

15


3. NFR-AWARE MDD PROCESS

16


3. Our proposal

• We explore two variants of the MDD process: Automatic and Interactive

Drive

Compliance

ADsNFRs

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

17

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


18

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


19

3.3 Firewall example• Deciding the need of firewall components


20

3.4 Benefits of our proposal

NFRs are fully integrated into MDDNo need to modify the codeArchitectural decisions depend on NFRsKnowledge reuse


VS.

21

3.5 Drawbacks of our proposal

New model (PIM/PSM) need to be maintainedNew transformations are neededWe need to maintain the architectural knowledge


VS.

22


4. SAD CONTRIBUTIONS

23

NFRs

AK MDD

Help

to d

iscov

er a

nd

reas

on a

bout

Adaptable process

Need of detailed knowledge

Architectural design as part of the process

NFRs

AK MDD

PSMF+NF

PIMF+NF

CodeF+NF

4.1 From MDD to Architecture• What do we need to do?

The main effort should be to include architectural design as part of the MDD.


M2MArch

M2T

PIM/PSMF+NF

M2MTech

24

PIMNF Human support

PIMF

PSMF+NF


4.2 SAD Overview

Context

PIMNF

Architecturaldecisions

M2MArch

M2MTech

Architecturalviews

SRSNF

SAD

25


4.2 SAD Overview

Requirements analysis

Human support

SRSNFContext

Architecturaldecision-making

Architecturaldecisions

Quality GoalsAnd

Constraints

26


4.3 Quark method

Knowledge acquisition

27


4.4 Arteon

Arteon

Require-ments

Rationale Structural Elements MDD

Stakeholder needs

Constraints and goals to fulfill

Architecturalelementsto use

Transformationsto apply

Architecturedesign

* One of the design principles recommended the separation of ontology concepts in modules

28


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

29


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.

30


5. ARTEON

31


5.1 Introduction

AK1 = Design + Decisions + Rationale

1Kruchten et al. “Building up and reasoning about architecture knowledge”, 2006.

Ontology-based AK Support System

32


5.2 Arteon overview

Arteon

Require-ments

Rationale Structural Elements MDD

Stakeholder needs

Constraints and goals to fulfill

Architecturalelementsto use

Transformationsto apply

Architecturedesign

* One of the design principles recommended the separation of ontology concepts in modules

33


5.3 Structural Elements (I)

File PHP

Apache

MySQL

34


5.3 Structural Elements (II)Logical Development

Deployment Platform

File PHP

Apache

MySQL

35


5.3 Structural Elements (III)

36


ArchitecturalView

ArchitecturalFramework

Style StyleVariation Component Implemen-

tation

ArchitecturalElement

5.3 Structural Elements (IV)

1*

belong_to

*

belong_to

ViewModel

ArchitecturalView


ArchitecturalElement *

37


5.3 Structural Elements (V)3-layer style(Layered style)

Web deployment(DBMS separated)

Web development(Package based)

LAMP(Stack solution)

Architectural views have their own styles

38


5.3 Structural Elements (VI)Variations: • DAO• Controllers• Replication• OSS

Components: • Class, Layer• Package• Server• Script language

DAO and data-mapper are not combinable

Layers are composed by classes

39


ArchitecturalView



tation


5.3 Structural Elements (VII)

* *incompatible_with

1 *< variation_for

* *connectable_with

* *composable_with

* *< apply_to

* *implementable_with

*1..*

< apply_to

{ Disjoint }

* *related_tospecializes

0..1 *


tation

40


5.4 Reasoning module (I)

* /set_action_over

Decision

Decisional Element

Existence Decision

PropertyDecision

Element Property

Quality Attribute

Attribute

1..*

**

/give_value1..*

*

/set_condition

{ disjoint, complete}


* *

*

*

impose /have_impact_onDecision

Decisional Element

Existence Decision

PropertyDecision

Element Property

Quality Attribute

Attribute


41


5.4 Reasoning module (II)

* /set_action_over1..*

**

/give_value1..*

*

/set_condition



* *

*

*

impose /have_impact_onDecision

Decisional Element

Existence Decision

PropertyDecision

Element Property

Quality Attribute

Attribute


“use only OSS”

Property “License” equal “OSS”

Property “License”

Element “Apache”

Element “Apache” has the value “OSS” for the property “License”

42


5.5 Benefits of Arteon

Ontology-based AK Support System

Share AK between architects

Reuse AK between projects

Community oriented solution

More reliability to architecture design

Decision-making guidance

43


6. CONCLUSIONS AND FUTURE WORK

44

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


45

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 studyS

ystematic Architecture Design

Comments and Questions

David Ameller<[email protected]>

systematic architecture design

Education

proposal nfrs

role of nfrs

nfrs m2march

specific nfrs

unaware of nfrs

stated nfrs

nfrs knowledge reuse20

state of practice nfrs