Synthesis-Based Software Architecture Design Bedir Tekinerdoğan University of Twente Department of...

Synthesis-Based Software Architecture Design

Bedir Tekinerdoğan

University of Twente

Department of Computer ScienceEnschede, The Netherlands

e:mail – bedir@cs.utwente.nl

http://www.cs.utwente.nl/~bedir/

http://trese.cs.utwente.nl/taosad/

2© Bedir Tekinerdoğan

Engineering=Problem SolvingRequirement

Specification(Need)

See: B. Tekinerdogan, Chapter 2, On the Notion of Software Engineering: A Problem Solving Perspective, PhD Thesis, University of Twente, 2000.

Solution Domain Knowledge

SearchTechnical Problem

Conceive

Artifact

Implement

SolutionDescription

Apply

Alternative(s)Identify

(Quality)Criteria

EvaluateSelect

Impacts

Mature Engineering adheres to this problem solving model

3© Bedir Tekinerdoğan

Synthesis-Based Software Architecture Design

Plan 0: 1 2 3 4 5

Synthesis-BasedSoftware ArchitectureDesign

0

DefineConceptualStructure

4

SpecifyInformalRequirements

1

Plan 1: 1 2 3

GeneralizeRequirements

IdentifySub-Problems

PrioritizeSub-Problems

1 2 3 4SpecifySub-Problems

3

DefineAlternativesfor eachConcept

DescribeConstraints

2

Plan 4: 12

DefineSemantics ofArchitecture

Plan 5: 1 2

1 DefineDynamicBehavior

2

ExtractSolution DomainConcepts

3Identify andPrioritizeKnowledgeSources

2Identify andPrioritizeSolution Domains

1

Plan 3: 1234

Plan 2: 1 2 3 4

?

Defineformalsmodels

4BuildingPrototype

3Use-Caseand ScenarioAnalysis

2

RequirementsAnalysis

1 TechnicalProblemAnalysis

2 AlternativeDesign SpaceAnalysis

4ArchitectureSpecification

5SolutionDomainAnalysis

3

4© Bedir Tekinerdoğan

Synthesis-Based Software Architecture

Design

Example Project:Atomic Transaction

Architecture Design for Car Dealer System

INEDIS

Example: Atomic Transaction Architecture

5© Bedir Tekinerdoğan

Large and complex distributed information system

server

Dealers

PC work-stations

Manufacturers& Importerships

Lease Companies

External servicesRegistration

Taxes

Workshop & orderprocessing

Stock Management

New and used car management

AccountingSubDealers

Car Dealer Information System

6© Bedir Tekinerdoğan

Selecting the Sub-Systems

Transaction Sub-System

Control-FlowSub-System .……..

OtherSubsystems system layer

application layer

Workshop &Order processing

Stock Management

New & used car Management

Accounting Leasing

Other Services

network

7© Bedir Tekinerdoğan

Car reservation application

available

Dealer 1

Dealer 2

Inconsistency through concurrent access.

if car.availablethen car.reserveend.

if car.availablethen car.reserveend.

Transactions - Concurrency

8© Bedir Tekinerdoğan

Money transfer application

withdraw(100)

account1.withdraw(100);account2.store(100). store(100)

account 1

account 2failure

Inconsistency through failures.

Transactions - Failures

9© Bedir Tekinerdoğan

startTransactionif car.freethen car.reserve; else abortend.

endTransaction;

startTransaction - start a transaction. commit / endTransaction - successfully completes

the transaction. abort - restores the effects of the transaction.

No concurrency or recovery code needed!

Atomic Transactions

© Bedir Tekinerdoğan

transaction system provides transparent concurrency control and recovery

Transaction Specifications

begin transactionif car.freethen car.reserve;end transaction

begin transactionif car1.freethen car.reserve;end transaction

begin transaction car.order;end transaction

begin transaction account.open;end transaction

begin transaction account.open;end transaction

begin transaction account.transfer;end transaction

© Bedir Tekinerdoğan

Different Transaction Implementations

begin transactionif car1.freethen car.reserve;end transaction

begin transactionif car1.freethen car.reserve;end transaction

begin transaction car.order;end transaction

begin transaction account.open;end transaction

begin transaction account.open;end transaction

begin transaction account.transfer;end transaction

2PL TS optimisticnot

serial

12© Bedir Tekinerdoğan

Design a Transaction Architecture that provides the

fundamental abstractions of transaction systems.

The system must be able to adapt to different transaction protocols and optimize itself based on the system characteristics.

- Application semantics (short, long, nested etc.)

- System conditions (throughput, response time, etc.)

- Data semantics (flat data, BLOB, etc)Reuse

Project’s Problem Statement

13© Bedir Tekinerdoğan

1. Requirements Analysis

RequirementsAnalysis

InterviewsSystem

StudyLiterature

Study

Requirements

14© Bedir Tekinerdoğan

Understand problem from client’s perspective:

Textual Requirement Specifications Use-Cases Scenarios Prototypes State Transition Diagrams

Conventional requirements analysis techniques.

1. Requirements Analysis

15© Bedir Tekinerdoğan

start Transaction

commit Transaction

abort Transaction

set Transaction properties

Application User

Transaction Protocol

initiate policy

insert criteria

remove criteria

update criteria

System administrator

Adaptation Protocol

Use case Modeling

16© Bedir Tekinerdoğan

1. Generalize/Restate Requirements and

determine the relevant concerns/problems.

2. Identify Sub-Problems

3. Specify Sub-Problems

4. Prioritize Sub-Problems

2. Technical Problem Analysis

17© Bedir Tekinerdoğan

Generalizing Requirements

The system should provide locking and optimistic scheduling protocols

The system should keep a log of the data before starting a transaction.

The system should provide transaction operators such as start, commit and abort.

The system should adapt based on the scheduling protocols.

Various scheduling protocols must be provided.

Various logging techniques need to be provided.

Both flat transactions and nested transactions must be supported.

The system should adapt based on application semantics, system state and data semantics.

Initial Requirements Generalized/Restated Requirements

18© Bedir Tekinerdoğan

Identifying Subproblems

P0. Adaptable Transaction

Architecture

P1. Transparent

Concurrency Control

P2. Transparent

Recovery

P3. Transparent

Transaction Management

P4. Adaptable Transaction

Protocols

Optimistic,Two-PL,Timestamp Ordering...

Image LoggingOperation LoggingRestarting Checkpointing

Flat, Nested, Open, Closed?

Initialization, compile-time,run-time?

19© Bedir Tekinerdoğan

3. Domain Analysis is the systematic activity of collecting, organizing and storing domain knowledge

20© Bedir Tekinerdoğan

3. Domain Analysis in Synbad

1. For each sub-problem, identify and prioritize the solution domains: P D

2. For each solution domain, identify and prioritize knowledge sources: DKS

3. From each knowledge source extract domain concepts: KS C

4. Structure the solution domain concepts.

5. Refine the solution domain concepts: C (Ci..Cn)

Domain LiteratureDomain ExpertsExisting Systems

21© Bedir Tekinerdoğan

Domain An area of knowledge or activity Characterized by a set of concepts and terminology Understood by practitioners in that area.

G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1997.

22© Bedir Tekinerdoğan

Example domains Driver Monitoring Insurance Systems Health Care Systems Transaction Systems Car Dealer System Image Processing Stock Management Information Retrieval Control Systems Retail System Production Systems …

Identify the essence of the domain, the

fundamental stable concepts….

23© Bedir Tekinerdoğan

Example computing domain classification

•A. General Literature •A.0 GENERAL •A.1 INTRODUCTORY AND SURVEY •A.2 REFERENCE (e.g., dictionaries, encyclopedias, glossaries) •A.m MISCELLANEOUS

•B. Hardware •B.0 GENERAL •B.1 CONTROL STRUCTURES AND MICROPROGRAMMING

(D.3.2) •B.2 ARITHMETIC AND LOGIC STRUCTURES •B.3 MEMORY STRUCTURES •B.4 INPUT/OUTPUT AND DATA COMMUNICATIONS •B.5 REGISTER-TRANSFER-LEVEL IMPLEMENTATION •B.6 LOGIC DESIGN •B.7 INTEGRATED CIRCUITS •B.8 PERFORMANCE AND RELIABILITY     (C.4) •B.m MISCELLANEOUS

•C. Computer Systems Organization •C.0 GENERAL •C.1 PROCESSOR ARCHITECTURES •C.2 COMPUTER-COMMUNICATION NETWORKS •C.3 SPECIAL-PURPOSE AND APPLICATION-BASED SYSTEMS

(J.7) •C.4 PERFORMANCE OF SYSTEMS •C.5 COMPUTER SYSTEM IMPLEMENTATION •C.m MISCELLANEOUS

•D. Software •D.0 GENERAL •D.1 PROGRAMMING TECHNIQUES (E) •D.2 SOFTWARE ENGINEERING (K.6.3) •D.3 PROGRAMMING LANGUAGES •D.4 OPERATING SYSTEMS (C) •D.m MISCELLANEOUS

•E. Data •E.0 GENERAL •E.1 DATA STRUCTURES •E.2 DATA STORAGE REPRESENTATIONS •E.3 DATA ENCRYPTION •E.4 CODING AND INFORMATION THEORY (H.1.1) •E.5 FILES (D.4.3, F.2.2, H.2) •E.m MISCELLANEOUS

•F. Theory of Computation •F.0 GENERAL

•F.1 COMPUTATION BY ABSTRACT DEVICES •F.2 ANALYSIS OF ALGORITHMS AND PROBLEM COMPLEXITY (B.6, B.7, F.1.3) •F.3 LOGICS AND MEANINGS OF PROGRAMS •F.4 MATHEMATICAL LOGIC AND FORMAL LANGUAGES •F.m MISCELLANEOUS

•G. Mathematics of Computing •G.0 GENERAL

•G.1 NUMERICAL ANALYSIS •G.2 DISCRETE MATHEMATICS •G.3 PROBABILITY AND STATISTICS •G.4 MATHEMATICAL SOFTWARE •G.m MISCELLANEOUS

•H. Information Systems •H.0 GENERAL •H.1 MODELS AND PRINCIPLES •H.2 DATABASE MANAGEMENT (E.5) •H.3 INFORMATION STORAGE AND RETRIEVAL •H.4 INFORMATION SYSTEMS APPLICATIONS •H.5 INFORMATION INTERFACES AND PRESENTATION (e.g., HCI) (I.7) •H.m MISCELLANEOUS

•I. Computing Methodologies •I.0 GENERAL •I.1 SYMBOLIC AND ALGEBRAIC MANIPULATION          •I.2 ARTIFICIAL INTELLIGENCE •I.3 COMPUTER GRAPHICS •I.4 IMAGE PROCESSING AND COMPUTER VISION          •I.5 PATTERN RECOGNITION •I.6 SIMULATION AND MODELING (G.3) •I.7 DOCUMENT AND TEXT PROCESSING          (H.4, H.5) •I.m MISCELLANEOUS

•…….

ACM Computing Classification Systemhttp://www.acm.org/class/1998/overview.html

24© Bedir Tekinerdoğan

Map problems to domains

P0. Adaptable Transaction

Architecture

P1. Transparent

Concurrency Control

P2. Transparent

Recovery

P3. Transparent

Transaction Management

P4. Adaptable Transaction

Protocols

H.2 DATABASE MANAGEMENT (E.5) •H.2.0 General

•Security, integrity, and protection [**] •H.2.1 Logical Design

•Data models •Normal forms •Schema and subschema

•H.2.2 Physical Design •Access methods •Deadlock avoidance •Recovery and restart

•H.2.3 Languages (D.3.2) •Data description languages (DDL) •Data manipulation languages (DML) •Database (persistent) programming languages •Query languages •Report writers

•H.2.4 Systems •Concurrency •Distributed databases          •Multimedia databases     •Object-oriented databases     •Parallel databases     •Query processing •Relational databases     •Rule-based databases     •Textual databases     •Transaction processing

•H.2.5 Heterogeneous Databases •Data translation [**] •Program translation [**]

•H.2.6 Database Machines

ACM Computing Classification System

Search

25© Bedir Tekinerdoğan

Map problems to domains

P0. Adaptable Transaction

Architecture

P1. Transparent

Concurrency Control

P2. Transparent

Recovery

P3. Transparent

Transaction Management

P4. Adaptable Transaction

Protocols Adaptability

Recovery

Concurrency Control

Transaction Management

Solution Domain

26© Bedir Tekinerdoğan

Search knowledge sources in domain

ID Knowledge Source Form

KS1 Concurrency Control & Recovery in Database Systems [Bernstein et al. 87]

Textbook

KS2 Atomic Transactions [Lynch et al. 94] Textbook

KS3 An Introduction to Database Systems [Date 90] Textbook

KS4 Database Transaction Models for Advanced Applications [Elmagarmid 92]

Textbook

KS5The design and implementation of a distributed transaction system

based on atomic data types [Wu et al. 95]Journal. paper

KS6Transaction processing: concepts and techniques [Gray & Reuter 93] Textbook

KS7Principles of Transaction Processing [Bernstein & Newcomer 97] Textbook

KS8 Transactions and Consistency in Distributed Database Systems [Traiger et al. 82]

Journal paper

Domain: Transaction Processing

27© Bedir Tekinerdoğan

Problems, Knowledge Domain, Knowledge Source

SolutionDomain

KnowledgeSource

TechnicalProblem

includes

Solution DomainConcept

Sub-Problem

includes

solutionprovided by

derive

solutionprovided by

solves

solves*

1..*

1..*1..*

1..*

28© Bedir Tekinerdoğan

Extract common concepts from knowledge sources

Domain Literature

Domain Experts

Existing Systems

Transactions Systems

common

29© Bedir Tekinerdoğan

Glossary of Domain

Transaction Domain

Transaction

TransactionManager

Scheduler

RecoveryManager

DataManager

PolicyManager

TransactionThe concept Transaction represents a transaction block as defined by the programmer.

TransactionManager The concept TransactionManager provides mechanisms for initiating, starting and terminating the transaction. It keeps a list of the objects that are affected by the transaction. If a transaction reaches its final state successfully, then TransactionManager sends a commit message to the corresponding objects to terminate the transaction. Otherwise an abort message is sent to all the participating objects to undo the effects of the transaction. The TransactionManager concept includes knowledge about a variety of commit and abort protocols.

PolicyManagerPolicyManager determines the mechanisms for adapting transaction protocols.

Scheduler is responsible for the concurrency control mechanism. It provides the concurrency control by restricting the order in which the operations are processed. Incoming operations may be accepted, rejected or put in a delay queue. Concurrency control may be based on syntactic ordering of the operations (e.g. read, write) or it may use semantic information of the transaction, such as information on the accessed data types. Traditional concurrency control techniques are locking, timestamp ordering and optimistic scheduling.

RecoveryManagerThe concept Recovery Manager is responsible for the recovery in case of transaction aborts, system failures and/or media failures. Failures may have an effect on data objects and on transactions that read the data objects. Recovery of the data objects needs caching and undo/redo mechanisms. Recovery of the effected transactions requires scheduling for recovery so that failures are prevented.

DataManagerThe concept DataManager controls the access to its object and keeps it consistent by applying concurrency control and recovery mechanisms. Further it may be responsible for the version management and the replication management of the data objects.

Data ObjectThe concept Data Object represents a data object that needs to be accessed in a consistent way. This means that the object must fulfill the consistency constraints set by the application.

30© Bedir Tekinerdoğan

Identifying basic concepts The transaction manager provides transaction operations for

the application which accesses the objects.

manages

accesses

Transaction Manager

Transaction Application

AtomicObject

31© Bedir Tekinerdoğan

Identifying basic concepts Each atomic object is managed by a data manager who

ensures that the object is accessed in a consistent way. For this it uses scheduling and recovery mechanisms.

AtomicObject

manages DataManager

coordinatesScheduler

coordinatesRecoveryManager

32© Bedir Tekinerdoğan

Identifying basic concepts The transaction behavior need to be dynamically changed

according to predefined criteria. For this an adequate policy management must be provided. The policy management will coordinate also the actions between the transaction management and data management.

coordinates

DataManager

coordinatesTransaction

Manager

PolicyManager

33© Bedir Tekinerdoğan

Top-Level conceptual architecture

PolicyManager

coordinates

TransactionApplication

Transaction Manager

AtomicObject

manages

accesses

DataManager

SchedulerRecoveryManager

coordinates

manages

Begin transaction

Begin transaction

Request

Determine Policy

Concurrency Control

Log, Undo?

Read/Update

34© Bedir Tekinerdoğan

Refine each architectural component Apply the same steps

For each sub-problem identify and prioritize the solution domains For each solution domain identify and prioritize knowledge

sources Extract solution domain concepts from solution domain

knowledge. Structure the solution domain concepts. Refine the solution domain concepts.

If needed iterate to problem

35© Bedir Tekinerdoğan

Identify Knowledge Domains per Component

Transaction Management

- Commit Protocols- Abort Protocols- Transaction structuring and specification- Control systems, sensing application semantics a...

Scheduling

Data Management

Recovery

Policy Management

- Performance and reliability analysis- Statistics- Control Systems

- Consistency constraint management- Coordination protocols- Control Systems

- Concurrency control- Deadlock detection/handling

- Data object recovery mechanisms- Scheduling for recovery of transactions- Checkpointing

Specific Domains

36© Bedir Tekinerdoğan

Refining the Scheduler

ID Knowledge Source Form

KS1 Concurrency Control in Advanced Database Applications [Barghouti & Kaiser 91]

Journal paper

KS2 Concurrency Control in Distributed Database Systems [Cellary et al. 89]

Textbook

KS3 The theory of Database Concurrency Control [Papadimitriou 86]. Textbook

KS4 Concurrency Control & Recovery in Database Systems [Bernstein et al. 87]

Textbook

KS5 Concurrency Control and Reliability in Distributed Systems [Bhargava 87]

Journal paper

KS6 Concurrency Control in Distributed Database Systems [Bernstein & Goodman 83]

Textbook

Domain: Concurrency control

37© Bedir Tekinerdoğan

Scheduler Conceptual Architecture

Scheduler SynchronizationDecision

uses

CommitProtocol

has

AbortProtocol

has

AcceptHandler

has

RejectHandlerhas

DelayHandler

has

GlobalSynchronization

Decision

interacts

PerformanceFailure

Management

interacts

interacts

38© Bedir Tekinerdoğan

1. Define Alternatives for each architectural concept

2. Identify and describe constraints among alternatives.

Current architecture design approaches do not have an explicit alternative space analysis process!

4. Alternative Design Space Analysis

39© Bedir Tekinerdoğan

coordinates

manages

accesses

coordinates

manages

<Concept>TransactionApplication

<concept>Transaction

Manager

<concept>Data

Manager

<concept>Scheduler

<concept>RecoveryManager

<concept>Data

Object

<concept>Policy

Manager

Alternative Design Space Analysis

40© Bedir Tekinerdoğan

Feature Modeling

Scheduler

Scheme StrategyPerformance

Failure Detector

TwoPL

TimstampOrdering

Optim.Serial.

Aggr. Cons..

DeadlockDetection

Inf. Block. Infinite

Rest.art

CyclicRest.art

32 alternatives

RecoveryManager

LogManager

FailureAtomicity

Synchronizer

Restarting

Oper.Log

Defer.Update

Updatein Place

Recoverable.

Cascadeless

Checkpointing

Strict

UndoRedo Undo/

No-Redo

No-Undo/Redo

No-Undo/No-Redo

Commit

Cache

Fuzzy

118 alternatives

alternative Scheduler: (Scheme = TwoPl, Strategy = Aggressive, Performance Failure Detector = Infinite Blocking)

41© Bedir Tekinerdoğan

transaction

transaction manager

policy manager

data manager

scheduler recovery manager

less certain!

conflicts

Defining inter-component constraints

42© Bedir Tekinerdoğan

transaction

transaction manager

policy manager

data manager

scheduler recovery managerconflictsscheduler

data manager

policy manager

Defining intra-component constraints

43© Bedir Tekinerdoğan

Reducing Design Space – Domain Constraints

Example constraint among concepts:

An optimistic scheduler cannot be combined with a strict recoverymanager. <Scheduler.sch.opt> mutex <RecoveryManager.Fas.Str>

Example constraint within a concept:

A two phase locking scheduler requires deadlock detection. <Scheduler.sch.2pl> requires <Scheduler.PFD.DL>

W. Weihl. The impact of recovery on concurrency control. Proc. of the 8th ACM-SIGACT-SIGMODsymposium on Principles of Database Systems, Philadelphia, 1989.

44© Bedir Tekinerdoğan

transaction

transaction manager

policy manager

data manager

scheduler recovery manager

Focus by client

45© Bedir Tekinerdoğan

5. Architecture Specification

TransactionTheory

t:TransactionApplication tm:TransactionManager

pm:PolicyManager

dm:DataManager

rm:RecoveryManagersched:Scheduler

a:DataObject

1.1:start(t)

1.2b:chooseTransactionProtocols(t)

2.1:handleOperation(t, o)

2.2:handleOperation(t, o)

2.4:dispatch( o)

3.1:commit(t)

3.2 commit(t)

1.2a:readParameterValues()

4.1:abort(t)

4.2:abort(t)

2.3b:handleOperation(t, o)3.3a commit(t)4.3b:abort(t)

2.3a:handleOperation(t, o)3.3a commit4.3a:abort(t)

2:handleOperation(t, o)1:start(t)

3:commit(t)4:abort(t)

46© Bedir Tekinerdoğan

More information... B. Tekinerdogan, Synthesis Based Software Architecture Design,

Ph.D. thesis, University of Twente, The Netherlands, March 2000.

M. Aksit (Ed.), Software Architectures and Component Technology: The State of the Art in Research and Practice, Kluwer Academic Publishers, 2001.