Transcript Balancing Domain Alternatives

Synthesis-Based Software
Architecture Design
Bedir Tekinerdoğan
Billkent University,
Department of Computer Engineering
Bilkent, Ankara, Turkey
e:mail - [email protected]
http://www.cs.bilkent.edu.tr/~bedir/
About the presenter...



Since 1974 in The Netherlands...
Affiliated from the University of Twente, The
Netherlands (since September 15, 2002).
Education



All in The Netherlands (Nursery school, primary school,
High school, University, MSc, Research Assistant, PhD,
Post-Doc, Assistant Professor...)
MSc. in Computer Science in (1994) and PhD (2000) at
University of Twente
Background/Research:



Software Engineering (in particular object-orientation)
Software Architecture Design
Aspect-Oriented Software Development
© Bedir Tekinerdoğan
2
Related Topics


Software Product Line Engineering

Domain Engineering and Application Engineering

Scoping Product Lines
Aspect-Oriented Software Development


Automating Software Design Methods


Artifact/Heuristic Rule Modeling
Alternative Management


How to identify and cope with crosscutting concerns?
How to identify, select, and balance design alternatives?
Synthesis-Based Software Architecture Design (Synbad)

How to apply synthesis in architecture design?
© Bedir Tekinerdoğan
3
Table of Contents
Part I. Rationale for Software Architecture
Part II. Contemporary Architecture Design Methods
Part III. Synthesis-based software architecture design
© Bedir Tekinerdoğan
4
Part I
Rationale for
Software Architecture
Intuitive notion of architecture
Structure in other disciplines
Structure in history of software engineering
What is Architecture?

Architecture (Webster’s):
1: the art or science of building; specifically: the art or
practice of designing and building structures and
especially habitable ones
2 a>:formation or construction as or as if as the result of
conscious act <the architecture of the garden> b: a
unifying or coherent form or structure <the novel lacks
architecture>
3: architectural product or work
4: a method or style of building
5: the manner in which the components of a computer or
computer system are organized and integrated
© Bedir Tekinerdoğan
6
Building Architectures
© Bedir Tekinerdoğan
7
Computer Architecture
© Bedir Tekinerdoğan
8
Car Architecture
© Bedir Tekinerdoğan
9
Architecture
Describes (is) Structure
Consisting of components
which forms the foundation of the whole....
© Bedir Tekinerdoğan
10
Taj Mahal
Taj Mahal : Built by Mogol Shah Cihan (turkish origin) in memory of his beloved wife Mümtaz Mahal 1648
© Bedir Tekinerdoğan
11
Bricks are not enough...
Build me a
palace!
© Bedir Tekinerdoğan
12
You need an architect first...
Architecture Design
Architecture Realization
Building
Architecture
© Bedir Tekinerdoğan
13
Software Development








Lists
Arrays
Class
Object
Procedures
Functions
Algorithms
Etc.
© Bedir Tekinerdoğan
//********************************************************************
import InventoryItem;
import java.util.StringTokenizer;
import java.io.*;
public class Inventory
{
//----------------------------------------------------------------// Reads data about a store inventory from an input file,
// creating an array of InventoryItem objects, then prints them.
//----------------------------------------------------------------public static void main (String[] args)
{
final int MAX = 100;
InventoryItem[] items = new InventoryItem[MAX];
StringTokenizer tokenizer;
String line, name, file="inventory.dat";
int units, count = 0;
float price;
try
for (int scan = 0; scan < count; scan++)
System.out.println (items[scan]);
}
catch (FileNotFoundException exception)
{
System.out.println ("The file " + file + " was not found.");
}
catch (IOException exception)
{
System.out.println (exception);
}
}
}
14
Large, complex software systems...





Large (Distributed) System
Many people working on the
same problem Programming
Overly Complex in the Large
Millions of Code...
Should be delivered on time
and within budget!
© Bedir Tekinerdoğan
15
Coding is not enough...








Lists
Arrays
Class
Object
Procedures
Functions
Algorithms
Etc.
© Bedir Tekinerdoğan
16
A Software Architect?
//********************************************************
************
import InventoryItem;
import java.util.StringTokenizer;
import java.io.*;
public class Inventory
{
//----------------------------------------------------------------// Reads data about a store inventory from an
input file,
// creating an array of InventoryItem objects, then
prints them.
//----------------------------------------------------------------public static void main (String[] args)
{
final int MAX = 100;
InventoryItem[] items = new InventoryItem[MAX];
StringTokenizer tokenizer;
String line, name, file="inventory.dat";
int units, count = 0;
float price;
Software Architecture
Design
Software Architecture
Realization
try
for (int scan = 0; scan < count; scan++)
System.out.println (items[scan]);
}
catch (FileNotFoundException exception)
{
System.out.println ("The file " + file + " was not
found.");
}
catch (IOException exception)
{
System.out.println (exception);
}
}
}
Application
Software Architecture
© Bedir Tekinerdoğan
17
Does Software have Structure?!


Yes!!
Dijkstra, 1968:


‘’...Correct arrangement of the
structure of software systems
before simple programming...‘’
Parnas, 1972:

‘’...selected criteria for the
decomposition of the system
impact the structure of the
programs and several design
principles must be followed to
provide a good structure...’’
© Bedir Tekinerdoğan
Edsger Dijkstra 1930-2002
18
Structure in Software

1960s - Structured Programming


1970s - Structured Design


Modular (object-based) programming


Grouping of sub-routines into modules with data.
Object decomposition
1990s – Towards Software Architectures



Methodology/guidelines for dividing programs into subroutines.
1980s – Modular programming languages


Functional/algorithmic decomposition
Object-Oriented Analysis/Design/Programming started being
commonly used
Software Architecture Design
2000s- Software Product Line Architectures
© Bedir Tekinerdoğan
19
Structure in Software
PROBLEMS SOLVED
APPROACH
1950
Simple, algorithmic
Programming any-which-way
Data intensive,
business applications
Programming in-the-small
- information hiding, modularization
Large, complex, distributed
Programming in-the-large
- object-oriented design
- CASE tools
- libraries
1960
1970
1980
1990
2000
Mega programs
2010
© Bedir Tekinerdoğan
Programming in-the-world
- software architecture, product lines,
aspect-orientation
20
Rationale for Software Architecture
Problem
understanding





Software
Architecture
Analysis
Design
Implementation
Architecture is explicit representation
of global structure of system
Improves communication among
different stakeholders
Guides analysis and design phases
Can predict global performance
Gross level reuse
© Bedir Tekinerdoğan
21
Summary on Structure in History







The more complex the problems the more the need to provide
an explicit structure.
Increased consciousness on structure of software
Structure idea did not stop at programming level but moved
up to design methods.
This has logically culminated in Software Architecture
Successfully applied in industry which have specific
architecture design teams/divisions.
Active Software Architecture Design community with its own
conferences, workshops, publications...
Is one of the most fundamental concepts in software
engineering.
© Bedir Tekinerdoğan
22
Part II
Software Architecture
Design Methods
Existing methods
Classification and Evaluation
Software Architecture is …



The gross-level structure of the system
which comprise software components,
and the relationships among them.
How to produce a
software architecture?
© Bedir Tekinerdoğan
24
Architecture Design Methods










The Unified Software Development Process,
G. Booch, J. Rumbaugh & I, Jacobson.
A System of Patterns: Pattern-Oriented
Software Architecture, F. Buschman et al.
(Object-Oriented Modeling and Design, J.
Rumbaugh
Design and use of software architectures, J.
Bosch.
Software Architecture in Practice, P.
Clements, L. Bass & R. Kazman
Applied Software Architecture, C. Hofmeister
et al.
Software Product Lines, P. Clements & L.
Northrop
Software Architectures: Perspectives on an
Emerging Discipline, M. Shaw
Synthesis-Based Software Architecture
Design, Tekinerdogan & Aksit
…
© Bedir Tekinerdoğan
25
Which one to select?
But which one should I select?!
Why?
B. Tekinerdogan and M. Aksit. Classifying and Evaluating Architecture Design Methods,
in Software Architectures and Component Technology: The State of the Art in Research and Practice,
M. Aksit (Ed.), Kluwer Academic Publishers, pp. 3 - 27, 2001.
© Bedir Tekinerdoğan
26
Classification of Methods

What is the source of architectural abstractions?




Artifact-driven
Use case/Scenario-driven
Pattern-driven
Domain-driven
© Bedir Tekinerdoğan
27
Artifact-driven




Start from textual requirements
Look at artifact types in the method
and try to identify artifacts from
requirements specification using
heuristic rules.
Group the related artifacts in
subsystems, these are the
architectural components.
Define the relations between
subsystems.
© Bedir Tekinerdoğan
28
Example: PC Factory
Requirements Specification: PC FACTORY
Date: 16-October 2002
A software system for a computer company, which
consists of two departments, a factory and sales and
marketing department. The factory assembles
desktop PCs and tower PCs. All the components of
a PC are delivered by different external suppliers. A
PC consists of one monitor, a cabinet, and a
keyboard. The cabinet includes a chassis. A chassis
on its turn is composed of a bus, floppy disk drive,
an optional CD-ROM drive, a memory unit, CPU,
and power supply. A bus may incorporate a network
card. A memory unit includes many RAM chips. The
sales and marketing department administers
properties of each PC, like the type, weight, make,
price, amortization, power consumption etc. A client
uses a purchase order to order PCs or set of
computer components from the company.
© Bedir Tekinerdoğan
Not precise,
Ambiguous,
Redundant,
Difficult to understand,
Not complete…
29
Applying Heuristics
Tentative Class identification
Extract nouns from the problem statement.
Select nouns as tentative classes.
Extract tentative classes from application domain knowledge.
Extract tentative classes from general knowledge.
Requirement
Specification
Requirements Specification
PC FACTORY
Date: 16-October 2002
A software system for a computer company,
which consists of two departments, a factory
and sales and marketing department.
The factory assembles desktop PCs and tower
PCs. All the components of a PC are delivered
by different external suppliers. A PC consists of
one monitor, a cabinet, and a keyboard. The
cabinet includes a chassis. A chassis on its
turn is composed of a bus, floppy disk drive, an
optional CD-ROM drive, a memory unit, CPU,
and power supply. A bus may incorporate a
network card. A memory unit includes many
RAM chips.
The sales and marketing department
administers properties of each PC, like the
type, weight, make, price, amortization, power
consumption etc. A client uses a purchase
order to order PCs or set of computer
components from the company.
© Bedir Tekinerdoğan
Class identification
Class
The identified tentative classes are used to identify classes:
IF tentative class <isRedundant>
THEN eliminate tentative class.
IF tentative class <isIrrelevant>
THEN eliminate tentative class.
IF tentative class <isVague>
THEN eliminate tentative class.
IF tentative class <isAttribute>
THEN select tentative class as Attribute.
IF tentative class <isOperation>
THEN eliminate tentative class.
IF tentative class <isRole>
THEN eliminate tentative class.
IF tentative class <isImplementationConstruct>
THEN eliminate tentative class.
Select remaining tentative classes as right classes.
I have to look for
Ok,classes…
this is a class,
thisare
isn’t.
might
What
theThis
heuristic
alsorules?
be a class,
And this one also…
30
Identified Classes/Subsystems
Department
Computer
Factory
Tower PC
Sales Department
Desktop PC
Cabinet
Department
Chassis
Monitor
Keyboard
Order
Cabinet
Order
Computer
© Bedir Tekinerdoğan
Supplier
Supplier
31
Identified Architecture
Order
Computer
Department
Supplier
© Bedir Tekinerdoğan
32
Obstacles Artifact-Driven Approach



Textual requirements are imprecise and are less
useful as a source for deriving architectural
abstractions
Subsystems have poor semantics to serve as
architectural components
Composition of subsystems is not well-supported.
© Bedir Tekinerdoğan
33
Use case driven




Extract use cases
Identify fundamental classes from
use cases.
Group these classes in packages,
these are the architectural
components.
Define the relations between
packages.
© Bedir Tekinerdoğan
http://www.rational.com/rup/
34
Obstacles



Selecting architecturally relevant use cases is not
systematically supported.
Use cases do not provide a solid basis for
architectural abstractions
Package construct has poor semantics to serve as
architectural abstractions.
© Bedir Tekinerdoğan
35
Pattern driven



Start with requirement
specification
Select appropriate
patterns from a pattern
base.
Compose these patterns.
© Bedir Tekinerdoğan
36
Pattern




Pattern is a generic and reusable design solution for
recurring problems in a given context.
Each pattern describes a solution, problem and the
context.
Patterns can be used to construct software
architectures.
Examples:

Layers, Blackboard, Pipes and Filters, etc.
Pattern Base
© Bedir Tekinerdoğan
37
Obstacles of Pattern-Driven Approaches




Patterns only might not be sufficient for deriving
architectural abstractions.
Selection of patterns is not well supported and
depends on experience of software engineer.
Applying patterns is not straightforward and requires
thorough analysis of the problem.
Composing patterns is not well supported.
© Bedir Tekinerdoğan
38
Part III
Architecture Synthesis
Process
Problem Solving Model
Synthesis Process
Example: Transaction Architecture
Engineering=Problem Solving
Requirement
Specification
(Need)
Conceive
Technical
Problem
Search
Solution Domain
Knowledge
Apply
Impacts
Identify
Solution
Description
Select
Implement
Alternative(s)
Evaluate
(Quality)
Criteria
Artifact
Mature Engineering adheres to this problem solving model
See: B. Tekinerdogan, Chapter 2, On the Notion of Software Engineering: A Problem Solving Perspective, PhD Thesis, University of Twente, 2000.
© Bedir Tekinerdoğan
40
Synthesis-Based Software Architecture Design
0
Synthesis-Based
Software Architecture
Design
Plan 0: 12345
?
1
Requirements
Analysis
Technical
Problem
Analysis
2
Solution 3
Domain
Analysis
Alternative 4
Design Space
Analysis
5
Architecture
Specification
Plan 1: 123
1
Specify
Informal
Requirements
Use-Case 2
and Scenario
Analysis
Building
Prototype
3
Define
formals
models
4
Plan 2: 1234
1
Generalize
Requirements
2
Identify
Sub-Problems
3
Specify
Sub-Problems
4
Prioritize
Sub-Problems
Plan 3: 1234
1
Identify and
Prioritize
Solution Domains
Identify and
Prioritize
Knowledge
Sources
2
3
Extract
Solution Domain
Concepts
4
Define
Conceptual
Structure
Plan 4: 12
Define
Alternatives
for each
Concept
Describe
Constraints
2
Plan 5: 12
Define
Semantics of
Architecture
© Bedir Tekinerdoğan
1
Define
Dynamic
Behavior
2
41
Example: Atomic Transaction Architecture
INEDIS
Synthesis-Based
Software Architecture
Design
© Bedir Tekinerdoğan
Example Project:
Atomic Transaction
Architecture Design for
Car Dealer System
42
Car Dealer Information System
Manufacturers
& Importerships
Dealers
server
PC workstations
Lease
Companies
External services
Registration
Taxes
Workshop & order
processing
Stock Management
New and used
car management
SubDealers
Accounting
Large and complex distributed information system
© Bedir Tekinerdoğan
43
Selecting the Sub-Systems
Workshop &
Order processing
Stock
Management
Other Services
application layer
New & used car
Management
Transaction
Sub-System
Accounting
Control-Flow
Sub-System
Leasing
.……..
Other
Subsystems
system layer
network
© Bedir Tekinerdoğan
44
Transactions - Concurrency
Car reservation application
if car.available
then car.reserve
end.
if car.available
then car.reserve
end.
Dealer 1
available
Dealer 2
Inconsistency through concurrent access.
© Bedir Tekinerdoğan
45
Transactions - Failures
Money transfer application
withdraw(100)
account 1
account1.withdraw(100);
store(100)
account2.store(100).
failure
account 2
Inconsistency through failures.
© Bedir Tekinerdoğan
46
Atomic Transactions
 startTransaction - start a transaction.
 commit / endTransaction - successfully completes the
transaction.
 abort - restores the effects of the transaction.
startTransaction
if car.free
then car.reserve;
else abort
end.
endTransaction;
No concurrency or recovery code needed!
© Bedir Tekinerdoğan
47
Transaction Specifications
begin transaction
if car.free
then car.reserve;
end transaction
begin transaction
car.order;
end transaction
begin transaction
if car1.free
then car.reserve;
end transaction
begin transaction
account.open;
end transaction
transaction system provides transparent
concurrency control and recovery
© Bedir Tekinerdoğan
begin transaction
account.transfer;
end transaction
begin transaction
account.open;
end transaction
Different Transaction Implementations
begin transaction
if car1.free
then car.reserve;
end transaction
begin transaction
car.order;
end transaction
begin transaction
if car1.free
then car.reserve;
end transaction
2PL
© Bedir Tekinerdoğan
begin transaction
account.transfer;
end transaction
TS
begin transaction
account.open;
end transaction
begin transaction
account.open;
end transaction
optimistic
not
serial
Project’s Problem Statement
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
© Bedir Tekinerdoğan
50
1. Requirements Analysis
Requirements
Analysis
Requirements
Interviews
© Bedir Tekinerdoğan
Literature
Study
System
Study
51
1. Requirements Analysis
Understand problem from client’s perspective:





Textual Requirement Specifications
Use-Cases
Scenarios
Prototypes
State Transition Diagrams
Conventional requirements analysis techniques.
© Bedir Tekinerdoğan
52
Use case Modeling
Application
User
start Transaction
initiate policy
commit Transaction
insert criteria
System
administrator
abort Transaction
set Transaction properties
Transaction Protocol
© Bedir Tekinerdoğan
remov e criteria
update criteria
Adaptation Protocol
53
2. Technical Problem Analysis
1. Generalize/Restate Requirements and
determine the relevant concerns/problems.
2. Identify Sub-Problems
3. Specify Sub-Problems
4. Prioritize Sub-Problems
© Bedir Tekinerdoğan
54
Generalizing Requirements
Initial Requirements
Generalized/Restated Requirements

The system should provide
locking and optimistic
scheduling protocols

Various scheduling protocols
must be provided.

The system should keep a
log of the data before starting
a transaction.

Various logging techniques
need to be provided.

The system should provide
transaction operators such as
start, commit and abort.

Both flat transactions and
nested transactions must be
supported.

The system should adapt
based on the scheduling
protocols.

The system should adapt
based on application
semantics, system state and
data semantics.
© Bedir Tekinerdoğan
55
Identifying Subproblems
P1.
Transparent
Concurrency Control
P0.
Adaptable Transaction
Architecture
© Bedir Tekinerdoğan
P2.
Transparent
Recovery
Optimistic,
Two-PL,
Timestamp
Ordering...
Image Logging
Operation Logging
Restarting
Checkpointing
P3.
Transparent
Transaction Management
Flat, Nested,
Open, Closed?
P4.
Adaptable Transaction
Protocols
Initialization,
compile-time,
run-time?
56
3. Domain Analysis




is the systematic activity of
collecting,
organizing and
storing domain knowledge
© Bedir Tekinerdoğan
57
3. Domain Analysis in Synbad
1.
2.
3.
4.
5.
For each sub-problem, identify and prioritize the solution
domains: P  D
For each solution domain, identify and prioritize knowledge
sources: DKS
From each knowledge source extract domain concepts:
KS  C
Structure the solution domain concepts.
Refine the solution domain concepts: C  (Ci..Cn)
Existing Systems
© Bedir Tekinerdoğan
Domain Experts
Domain Literature
58
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.
© Bedir Tekinerdoğan
59
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
…
© Bedir Tekinerdoğan
Identify the essence of
the domain, the
fundamental stable
concepts….
60
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 System
http://www.acm.org/class/1998/overview.html
© Bedir Tekinerdoğan
61
Map problems to domains
ACM Computing Classification System
P1.
Transparent
Concurrency Control
P0.
Adaptable Transaction
Architecture
P2.
Transparent
Recovery
P3.
Transparent
Transaction Management
P4.
Adaptable Transaction
Protocols
© Bedir Tekinerdoğan
Search
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
62
Map problems to domains
Solution Domain
P1.
Transparent
Concurrency Control
P2.
Transparent
Recovery
Transaction Management
Concurrency Control
P0.
Adaptable Transaction
Architecture
P3.
Transparent
Transaction Management
P4.
Adaptable Transaction
Protocols
© Bedir Tekinerdoğan
Recovery
Adaptability
63
Search knowledge sources in domain
Domain: Transaction Processing
ID
Knowledge Source
Form
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
Database Transaction Models for Advanced Applications [Elmagarmid 92]
Textbook
The design and implementation of a distributed transaction system based on atomic data
types [Wu et al. 95]
Journal. paper
Transaction processing: concepts and techniques [Gray & Reuter 93]
Textbook
Principles of Transaction Processing [Bernstein & Newcomer 97]
Textbook
Transactions and Consistency in Distributed Database Systems [Traiger et al. 82]
Journal paper
KS1
KS4
KS5
KS6
KS7
KS8
© Bedir Tekinerdoğan
64
Problems, Knowledge Domain, Knowledge Source
1..*
solution
provided by
T echnical
Problem
Solution
Domain
includes
Knowledge
Source
1..*
solution
provided by
derive
includes
*
1..*
1..*
Sub-Problem
solves
Solution Domain
Concept
solves
© Bedir Tekinerdoğan
65
Extract common concepts from knowledge sources
Transactions
Systems
Domain Literature
common
Existing Systems
Domain Experts
© Bedir Tekinerdoğan
66
Glossary of Domain
Transaction
The concept Transaction represents a transaction block as defined by the programmer.
Transaction
Transaction
Manager
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.
PolicyManager
PolicyManager determines the mechanisms for adapting transaction protocols.
DataManager
Transaction Domain
PolicyManager
RecoveryManager
Scheduler
© Bedir Tekinerdoğan
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.
RecoveryManager
The 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.
DataManager
The 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 Object
The 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.
67
Identifying basic concepts

The transaction manager provides transaction operations for
the application which accesses the objects.
Transaction
Manager
manages
Transaction
Application
accesses
Atomic
Object
© Bedir Tekinerdoğan
68
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.
coordinates
Scheduler
Atomic
Object
manages
Data
Manager
coordinates
© Bedir Tekinerdoğan
Recovery
Manager
69
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
Transaction
Manager
Policy
Manager
coordinates
© Bedir Tekinerdoğan
Data
Manager
70
Top-Level conceptual architecture
Transaction
Application Begin transaction
manages
accesses
Transaction
Manager
Read/Update
Atomic
Object
Begin transaction
coordinates
manages
Data
Manager
Policy
Manager
Determine Policy
Request
coordinates
Concurrency
Control
© Bedir Tekinerdoğan
Scheduler
Recovery
Manager
Log, Undo?
71
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
© Bedir Tekinerdoğan
72
Identify Knowledge Domains per Component
Specific Domains
Transaction
Management
Policy
Management
- Performance and reliability analysis
- Statistics
- Control Systems
Data
Management
- Consistency constraint management
- Coordination protocols
- Control Systems
Scheduling
Recovery
© Bedir Tekinerdoğan
- Commit Protocols
- Abort Protocols
- Transaction structuring and specification
- Control systems, sensing application semantics a...
- Concurrency control
- Deadlock detection/handling
- Data object recovery mechanisms
- Scheduling for recovery of transactions
- Checkpointing
73
Refining the Scheduler
Domain: Concurrency control
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
© Bedir Tekinerdoğan
74
Scheduler Conceptual Architecture
Performance
Failure
Management
interacts
Commit
Protocol
Global
Synchronization
Decision
Accept
Handler
interacts
has
has
has
Abort
Protocol
interacts
uses
Scheduler
Synchronization
Decision
has
Reject
Handler
has
Delay
Handler
© Bedir Tekinerdoğan
75
4. Alternative Design Space Analysis
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!
© Bedir Tekinerdoğan
76
Alternative Design Space Analysis
<Concept>
Transaction
Application
manages
accesses
<concept>
Transaction
Manager
<concept>
Data
Object
coordinates
manages
<concept>
Policy
Manager
<concept>
Data
Manager
coordinates
<concept>
Scheduler
© Bedir Tekinerdoğan
<concept>
Recovery
Manager
77
Feature Modeling
RecoveryManager
Scheduler
Scheme
Strategy
Aggr.
TwoPL
Performance
Failure Detector
Timstamp
Ordering
Cons..
Deadlock
Detection
Optim.
Serial.
Inf.
Block.
32 alternatives
© Bedir Tekinerdoğan
Cyclic
Rest.art
Infinite
Rest.art
Log
Manager
Oper.
Log
Defer.
Update
Failure
Atomicity
Synchronizer
Recoverable.
Restarting
Checkpointing
Commit
Undo
Redo Undo/
No-Undo/
Redo
No-Redo
Fuzzy
Cache
Cascadeless
Strict
No-Undo/
No-Redo
alternative Scheduler:
Update
(Scheme = TwoPl,
in Place
Strategy = Aggressive,
Performance Failure Detector = Infinite Blocking)
118 alternatives
78
Defining inter-component constraints
transaction
transaction manager
policy manager
data manager
scheduler
© Bedir Tekinerdoğan
less certain!
conflicts
recovery manager
79
Defining intra-component constraints
transaction
policy manager
transaction manager
data manager
policy manager
data manager
scheduler
© Bedir Tekinerdoğan
conflicts
scheduler
recovery manager
80
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-SIGMOD
symposium on Principles of Database Systems, Philadelphia, 1989.
© Bedir Tekinerdoğan
81
Focus by client
transaction
transaction manager
policy manager
data manager
scheduler
© Bedir Tekinerdoğan
recovery manager
82
5. Architecture Specification
t:TransactionApplication
1:start(t)
2:handleOperation(t, o)
3:commit(t)
4:abort(t)
tm:TransactionManager
1.1:start(t)
2.1:handleOperation(t, o)
3.1:commit(t)
4.1:abort(t)
pm:PolicyManager
1.2a:readParameterValues()
1.2b:chooseTransactionProtocols(t)
Transaction
Theory
2.2:handleOperation(t, o)
3.2 commit(t)
4.2:abort(t)
2.4:dispatch( o)
dm:DataManager
2.3a:handleOperation(t, o)
3.3a commit
4.3a:abort(t)
sched:Scheduler
© Bedir Tekinerdoğan
a:DataObject
2.3b:handleOperation(t, o)
3.3a commit(t)
4.3b:abort(t)
rm:RecoveryManager
83
More information...

PhD Thesis

Bedir Tekinerdogan,
‘Synthesis-Based Software Architecture Design’
University of Twente, The Netherlands, march 23, 2000.

http://www.cs.bilkent.edu.tr/~bedir/PhDThesis/

e-mail:
© Bedir Tekinerdoğan
[email protected]
84
© Bedir Tekinerdoğan
85