systematic architecture design

Systematic Architecture Design

David Ameller

<dameller@essi.upc.edu>

Outline

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

1. INTRODUCTION

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

1.2 Main topics

Semi-automatic treatment

NFRs MDDAdaptable process

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.

HelloWorld

Show()

HelloWorld

Show()

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

• 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

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

2. MOTIVATION EXAMPLE

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.

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”

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

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

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

3. NFR-AWARE MDD PROCESS

3. Our proposal

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

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

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

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

3.3 Firewall example• Deciding the need of firewall components

3.4 Benefits of our proposal

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

3.5 Drawbacks of our proposal

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

4. SAD CONTRIBUTIONS

AK MDD

Adaptable process

Need of detailed knowledge

Architectural design as part of the process

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

PIM/PSMF+NF

M2MTech

PIMNF Human support

PSMF+NF

4.2 SAD Overview

Context

Architecturaldecisions

M2MArch

M2MTech

Architecturalviews

4.2 SAD Overview

Requirements analysis

Human support

SRSNFContext

Architecturaldecision-making

Architecturaldecisions

Quality GoalsAnd

Constraints

4.3 Quark method

Knowledge acquisition

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

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

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.

5. ARTEON

5.1 Introduction

AK1 = Design + Decisions + Rationale

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

Ontology-based AK Support System

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

5.3 Structural Elements (I)

File PHP

Apache

5.3 Structural Elements (II)Logical Development

Deployment Platform

File PHP

Apache

5.3 Structural Elements (III)

ArchitecturalView

ArchitecturalFramework

Style StyleVariation Component Implemen-

tation

ArchitecturalElement

5.3 Structural Elements (IV)

belong_to

ViewModel

ArchitecturalView

ArchitecturalElement *

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

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

ArchitecturalView

tation

5.3 Structural Elements (VII)

* *incompatible_with

1 *< variation_for

* *connectable_with

* *composable_with

* *< apply_to

* *implementable_with

< apply_to

{ Disjoint }

* *related_tospecializes

0..1 *

tation

5.4 Reasoning module (I)

* /set_action_over

Decision

Decisional Element

Existence Decision

PropertyDecision

Element Property

Quality Attribute

Attribute

/give_value1..*

/set_condition

{ disjoint, complete}

impose /have_impact_onDecision

Decisional Element

Existence Decision

PropertyDecision

Element Property

Quality Attribute

Attribute

5.4 Reasoning module (II)

* /set_action_over1..*

/give_value1..*

/set_condition

{ disjoint, complete}

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”

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

6. CONCLUSIONS AND FUTURE WORK

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

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<dameller@essi.upc.edu>

systematic architecture design

proposal nfrs

role of nfrs

nfrs m2march

specific nfrs

unaware of nfrs

stated nfrs

nfrs knowledge reuse20

state of practice nfrs

Education

maturity models architecture: a large systematic mapping

information architecture 1wucm1. information architecture a...

systematic instructional design

sad: systematic architecture design · 1.3. systematic...

design development of built environment20_may-_28... · •...

a systematic development of a secure architecture for the

a systematic approach to design critique

architecture and design - vmware validated design 4 ·...

the systematic design of instruction - open universiteit...

the systematic design of instruction - hastudio.us

bloc design architecture & design

architecture / urban design interior design · architecture...

design – product design & architecture

systematischer entwurf von software-architekturen ·...

bhsd - systematic design process

indicators of healthy architecture—a systematic literature...

gemmini: enabling systematic deep-learning architecture

systematic development and the service oriented architecture

financial system architecture and systematic risk ·...

design research systematic inventive thinking