Architectural Architectural TransformationsTransformations

Vincenzo AmbriolaAlina Kmiecik

Javier ReyesJavier ReyesCOMP 685COMP 685

Professor LingardProfessor LingardFall 2007Fall 2007

IntroductionIntroduction

The software development process can be described as a set of transformations that convert less specified documents and diagrams into more formal and detailed ones.

Architectural transformations change the software structure and directly influence system properties like quality and functionality.

They construct the software architecture, which is the input of the next development stage.

They can provide good mechanisms for early-stage software quality management because of their influence on software quality.

It can decrease software production costs and speed up time-to-market.

Makes software architect responsible not only for functional decomposition, but also for non-functional requirements fulfillment.

Architectural Architectural TransformationsTransformations

There are two general groups of transformations: for change and for explanatory purposes.

Change transformations are used to modify and improve the software architecture.

Explanatory purposes transformations are applied for architecture analysis and understanding.

Change TransformationsChange Transformations

The software architect can use several transformations to improve a software architecture.

They can be classified into three groups: highest level transformations middle level transformations lowest level transformations

At a first glance this classification seems to separate operations performed at particular levels of the structure and suggests that they are independent.

Transformations applied in one diagram force changes to upper and lower levels of the structure.

Architecture Description Architecture Description LanguageLanguage

It is impossible to provide any analysis or architectural change without adopting a formal architecture representation.

Almost every ADL concentrates on some particular aspects of software architecture and it is not easy to find a language that can represent all architectural perspectives.

Architectural transformations cannot be defined before all nuances of the software architecture are well described in a unified and formalized manner.

UML is a description language on its own, but it cannot model every feature of a software architecture.

UML is more popular than any ADL and is used during software development from early phases to detailed design.

Performing or even presenting the results of architectural transformations in UML would make them comprehensible to everyone, not only to the specialists acquainted with a specific description language.

For this reason it is worth to look for a description language integrated with UML, which closes the gap between architectural design and other development stages.

Non-functional requirements vs. software

architecture Nonfunctional requirements refer to the

whole software and thus they cannot be presented in software architecture as components or functions offered by the system, as it is the case with functional requirements.

Non-functional requirements determine the architectural style and influence software structure and system properties.

Software architecture drives the quality characteristics of the system which are the measure aspects for non-functional requirements satisfaction.

Architectural StylesArchitectural Styles

Architectural styles influence the frequency and the number of links between components, and force some implementation solutions like component replication and data access.

Process AutomationProcess Automation

An automation mechanism could be An automation mechanism could be provided to perform architectural provided to perform architectural transformations.transformations.

Software Architecture Software Architecture TransformationTransformation

Jan BoschJan BoschProfessor of Software EngineeringProfessor of Software Engineering

University of Groningen, NetherlandsUniversity of Groningen, NetherlandsJan.Bosch@cs.rug.nlJan.Bosch@cs.rug.nl

http://www.cs.rug.nl/~boschhttp://www.cs.rug.nl/~bosch

Copyright © 2001 Jan Bosch

Overview ARCS/ADMOverview ARCS/ADM

requirementspecification

functionality-basedarchitectural design

applicationarchitecture

OK

architectureassessment

QA optimizingsolutions

architecturetransformation

not OK

FR

QR

MethodMethod

three main phases:three main phases: functionality-based design functionality-based design assessment of QAsassessment of QAs architecture transformationarchitecture transformation

Architecture Architecture TransformationTransformation

architecture transformation process:architecture transformation process: identify unfulfilled quality attributesidentify unfulfilled quality attributes for each quality attributefor each quality attribute

identify locations where QA is inhibitedidentify locations where QA is inhibited select the most appropriate transformationselect the most appropriate transformation perform the transformation on the architectureperform the transformation on the architecture

Architecture Architecture TransformationTransformation

transformations (primarily) change the transformations (primarily) change the structure of the architecturestructure of the architecture

affect quality attributes, but not affect quality attributes, but not application domain functionalityapplication domain functionality

imposearchitectural

style

scope of impactarchitecturecomponent

added functionality,rules and/ or constraints

restructuring

transformation type

imposearchitectural

pattern

applydesignpattern

convertQR to

functionality

Architecture Architecture TransformationTransformation

transformation techniquestransformation techniques impose architectural styleimpose architectural style impose architectural patternimpose architectural pattern apply design patternapply design pattern convert QR to functionalityconvert QR to functionality

Example: Fire Alarm Example: Fire Alarm SystemSystem

Input

Input

Input

Input

Input

Output

Output

Input

Output

Impose Architectural Impose Architectural StyleStyle

reorganize functionality according to reorganize functionality according to architectural stylearchitectural style

architectural style predominant in architectural style predominant in (sub)system(sub)system

each style has an associated suitability for each style has an associated suitability for different QAsdifferent QAs

exampleexample layered architecture for HW dependent and layered architecture for HW dependent and

independent functionalityindependent functionality blackboard in fire-alarm systemblackboard in fire-alarm system

Impose Architectural Impose Architectural StyleStyle

pipes and filterspipes and filters layerslayers blackboardblackboard object-orientationobject-orientation implicit invocationimplicit invocation

performanceperformance maintainabilitymaintainability reliabilityreliability safetysafety securitysecurity

ExampleExample

Input

Input

Input

Input

Input

Output

Output

Input

Output

Deviation

Deviation

Impose Architectural Impose Architectural PatternPattern

not predominant, but affects not predominant, but affects complete (sub)systemcomplete (sub)system

deals with aspects of a system deals with aspects of a system (AOP), e.g. concurrency, distribution(AOP), e.g. concurrency, distribution

exampleexample concurrency, e.g. periodic objectsconcurrency, e.g. periodic objects transaction managementtransaction management

Impose Architectural Impose Architectural PatternPattern

concurrencyconcurrency operating system processesoperating system processes operating system threadsoperating system threads non-preemptive threadsnon-preemptive threads application-level schedulerapplication-level scheduler

persistencepersistence database management systemdatabase management system application-level persistence and transaction application-level persistence and transaction

handlinghandling

Impose Architectural Impose Architectural PatternPattern

distributiondistribution brokersbrokers remote method invocationremote method invocation

graphical user interfacegraphical user interface model-view-controllermodel-view-controller presentation-abstraction-controlpresentation-abstraction-control

ExampleExample

Input

Input

Input

Input

Input

Input

Deviation

DeviationOuput

Ouput

Ouput

Scheduler

Apply Design PatternApply Design Pattern

affects a limited number of classesaffects a limited number of classes traditionally focussed on development traditionally focussed on development

QAs, e.g. flexibility and reusability (now QAs, e.g. flexibility and reusability (now extending)extending)

exampleexample strategy pattern (flexibility ++, performance strategy pattern (flexibility ++, performance

--)--) abstract factory (extensibility++, abstract factory (extensibility++,

performance-)performance-)

Apply Design PatternApply Design Pattern

FaçadeFaçade Abstract factoryAbstract factory StrategyStrategy ObserverObserver

performanceperformance maintainabilitymaintainability reliabilityreliability safetysafety securitysecurity

ExampleExample

Deviation

Deviation

InputDevice

InputPoint

InputDevice

InputPoint

InputDevice

InputPoint

InputDevice

InputPoint

OutputDevice

OutputPoint

OutputDevice

OutputPoint

OutputDevice

OutputPoint

InputDevice

InputPoint

Convert QR to Convert QR to FunctionalityFunctionality

each QR has several possible each QR has several possible solutionssolutions

select one solution and extend select one solution and extend architecture functionality with QR architecture functionality with QR related functionalityrelated functionality

exampleexample introduce redundant objectsintroduce redundant objects mutual consistency checking algorithmmutual consistency checking algorithm

Convert QR to Convert QR to FunctionalityFunctionality

self-monitoringself-monitoring top-level monitoring layertop-level monitoring layer entity-based monitoringentity-based monitoring

redundancyredundancy N-version programmingN-version programming recovery blocksrecovery blocks acceptance testsacceptance tests

ExampleExample

Output

Output

Deviation

Deviation

Output

Output

Deviation

Deviation

AlarmInput

AlarmInput

AlarmInput

AlarmInput

Fault Input

Fault Input

Fault Input

ExampleExample

AlarmHandler

activate( )reset( )

*

0

AlarmDetectorDevice

reset( ) Sends alarm events

1 ControllingAlgortihm

calculate( )0

Normaliser

normalise( )denormalise( )

Device

getValue( )setValue( )

*

0

hazard surveillance

10

Distribute RequirementsDistribute Requirements

decompose system requirement to decompose system requirement to requirement for multiple requirement for multiple componentscomponents

exampleexample fault-tolerance divided into FT-fault-tolerance divided into FT-

communication and FT-computationcommunication and FT-computation response-time requirement divided into response-time requirement divided into

shorter component response times shorter component response times

ExampleExample

Deviation

Deviation

InputDevice

InputPoint

InputDevice

InputPoint

InputDevice

InputPoint

InputDevice

InputPoint

OutputDevice

OutputPoint

OutputDevice

OutputPoint

OutputDevice

OutputPoint

InputDevice

InputPoint

CommunicationSoftware

ConclusionConclusion

transformation techniquestransformation techniques impose architectural styleimpose architectural style impose architectural patternimpose architectural pattern apply design patternapply design pattern convert QR to functionalityconvert QR to functionality

imposearchitectural

style

scope of impactarchitecturecomponent

added functionality,rules and/ or constraints

restructuring

transformation type

imposearchitectural

pattern

applydesignpattern

convertQR to

functionality

ConclusionConclusion

architecture transformation

interface

relation

component

sof twarearchitecture

requirementspecification

functionalrequirement

qualityrequirement

scenario profi le

archetype

systemcontext

structure

designdecision

component

relation

transformation

rationale

structural eff ect

constraint

rule

priority

relationrelation

interface

assessmentresult

uses

affects

Architectural Architectural Transformations Transformations for Improving the for Improving the

Efficiency of Efficiency of Object-Oriented Object-Oriented

SystemsSystemsTom TourwéTom Tourwé

Programming Technology LabProgramming Technology Lab

Vrije Universiteit BrusselVrije Universiteit Brussel

OverviewOverview

What problem are we trying to What problem are we trying to tackle exactly?tackle exactly?

What are the requirements for the What are the requirements for the solution?solution?

How do we combine these different How do we combine these different requirements?requirements?

Reasons for loss of Reasons for loss of performanceperformance

Objectifying all kinds of thingsObjectifying all kinds of things operations (e.g. Visitor DP)operations (e.g. Visitor DP) state (e.g. State DP)state (e.g. State DP) algorithms (e.g. Strategy, Command DP)algorithms (e.g. Strategy, Command DP) interactions (e.g. Mediator DP)interactions (e.g. Mediator DP)

Favor aggregation over inheritanceFavor aggregation over inheritance ““Programming to Interfaces” Programming to Interfaces”

approachapproach

Reasons for loss of Reasons for loss of performanceperformance

This can not be tackled by existing This can not be tackled by existing techniquestechniques only focus on statically binding messagesonly focus on statically binding messages no knowledge about abstractions and no knowledge about abstractions and

indirectionsindirections can not convert aggregation into can not convert aggregation into

inheritanceinheritance not able to “specialize” the program for a not able to “specialize” the program for a

specific usage patternspecific usage pattern

ExampleExample

FactoryApplication

Abstraction Im plem ent.

ImplA

ExampleExample

FactoryApplication

Abstraction Im plem ent.

ImplA

ExampleExample

Application

Abstraction

Im plA

SolutionSolution

Use an open precompilerUse an open precompiler has detailed knowledge about a system. has detailed knowledge about a system.

This knowledge is provided by the This knowledge is provided by the developer through annotations in a developer through annotations in a special purpose languagespecial purpose language

can use this knowledge to transform a can use this knowledge to transform a system. How this should be done is system. How this should be done is specified in another languagespecified in another language

Annotation LanguageAnnotation Language

Enables the developer to express “facts” about Enables the developer to express “facts” about the systemthe system

embedded in the code in the form of commentsembedded in the code in the form of comments Should be (based on) a logic languageShould be (based on) a logic language

Annotation LanguageAnnotation Language

/** ConcreteVisitor(PrettyPrintVisitor). operationname(PrettyPrintVisitor, prettyprint). acceptname(PrettyPrintVisitor, accept). */public class PrettyPrintVisitor implements Visitor { … }

/** VisitedElement(IfStatementNode). */public class IfStatementNode implements Node { … }

Transformation Transformation LanguageLanguage

Specifies how the compiler should Specifies how the compiler should transform a systemtransform a system

specified separately from that systemspecified separately from that system can be seen as an aspect languagecan be seen as an aspect language

should be able to use the information should be able to use the information provided in the annotation languageprovided in the annotation language

should be as expressive and as simple should be as expressive and as simple as possibleas possible

Transformation Transformation LanguageLanguage

A mix of functional and logic A mix of functional and logic languagelanguage Logical: specifies WHEN to transformLogical: specifies WHEN to transform

use the logic facts provided by the use the logic facts provided by the programmerprogrammer

use the matching capabilities of a logic use the matching capabilities of a logic engineengine

Functional: specifies HOW to transformFunctional: specifies HOW to transform specify easily which transformations should specify easily which transformations should

be performedbe performed

Transformation Transformation LanguageLanguage

Available transformations are limitedAvailable transformations are limited only high-level transformationsonly high-level transformations

addclass, addmethod, delete, changename, addclass, addmethod, delete, changename, addformal, changetype, …addformal, changetype, …

low-level transformations are handled low-level transformations are handled by a special “replace” functionby a special “replace” function

Use refactorings to actually perform Use refactorings to actually perform the transformationthe transformation

Simple ExampleSimple Example

package test;spec Simple<class Test> {

?returntype m(?Formal) {deleteformal(?Formal),move(?Formal.type).

}}

Move method m from class TestMove method m from class Test

Typical ExampleTypical Example

class PrettyPrintVisitor { void visitIfStatementNode(IfStatementNode x) { this.print(“if(“);

x.itsCondition().accept(this); this.print(“)”);

x.itsThenPart().accept(this); x.itsElsePart().accept(this);

}}

class IfStatementNode { void prettyprint(PrettyPrintVisitor x) { x.print(“if(“);

this.itsCondition().prettyprint(x); x.print(“)”);

this.itsThenPart().prettyprint(x); this.itsElsePart().prettyprint(x);

}}

VS.

Typical ExampleTypical Example

package test.visitors;

spec VisitorSpec<class ?Visitor> {

?returntype ?method (?Formal) {

changetype(?Formal.type, ?Visitor.type),

replace(“this”, ?Formal.name), replace(?Formal.name, “this),

replace(“?rec.” + ?acceptname + “(?x)”, “?rec.” + ?operationname + “(?x)”),

move(?Formal.type), changename(?operationname).

} :- VisitedElement(?Formal.type), operationname(?Visitor, ?operationname),

acceptname(?Visitor, ?acceptname).

} :- ConcreteVisitor(?Visitor).

ImplementationImplementation

Java Parser

SpecParser

Refactorings Repository

To Be DoneTo Be Done

Finish implementation of the Finish implementation of the SpecParserSpecParser

Perform some benchmarks on small Perform some benchmarks on small systemssystems

Perform some benchmarks on real Perform some benchmarks on real systemssystems

Develop more formal notation for Develop more formal notation for assessing the performance gainsassessing the performance gains