1. Synthesis-Based Software Architecture Design
Bedir Tekinerdoğan University of Twente
Department of Computer Science Enschede, The Netherlands
e:mail –

2. Engineering=Problem Solving
Requirement
Specification
(Need)
Impacts
Technical
Problem
Conceive
Solution Domain Knowledge
Search
Solution Description
Apply
Alternative(s)
Identify
(Quality)
Criteria
Evaluate
Select
Artifact
Implement
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.

3. Synthesis-Based Software Architecture Design

4. Example: Atomic Transaction Architecture
Synthesis-Based Software Architecture Design
Example Project:
Atomic Transaction Architecture Design for
Car Dealer System
INEDIS
The outline of my talk is as follows:

5. Car Dealer Information System
Manufacturers
& Importerships
Lease
Companies
External services
Registration
Taxes
server
Dealers
PC work-
stations
Workshop & order
processing
Stock Management
New and used
car management
Accounting
SubDealers
In de NEDIS architectuur zijn een aantal auto dealers verbonden middels een netwerk. Elk dealer heeft een client server architectuur waarbinnen een aantal workstations gekoppeld zijn aan een centrale database server bevat. Het systeem biedt de functies: Order aafhandeling, voorraadbeheer, accounting enz.
Dit is kort gezegd het NEDIS systeem.
Large and complex distributed information system

6. Selecting the Sub-Systems
system layer
application layer
Workshop &
Order processing
Stock
Management
New & used car
Accounting
Leasing
Other Services
network
Transaction
Sub-System
Control-Flow
Sub-System
.……..
Other
Subsystems

7. Transactions - Concurrency
Car reservation application
if car.available
then car.reserve
end.
Dealer 1
available
Dealer 2
Inconsistency through concurrent access.

8. Transactions - Failures
Money transfer application
withdraw(100)
account 1
account1.withdraw(100);
account2.store(100).
store(100)
failure
account 2
Inconsistency through failures.

9. 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;
An atomic transaction is a mechanism which maintains consistency
of the objects even in case of concurrency and failures.
As such atomic transaction provide a further degree of transparency in distributed systems, namely concurrency transparency and failure transparency
No concurrency or recovery code needed!

10. Transaction Specifications
begin transaction
account.transfer;
end transaction
begin transaction
if car.free
then car.reserve;
end transaction
begin transaction
car.order;
end transaction
begin transaction
account.open;
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

11. Different Transaction Implementations
begin transaction
account.transfer;
end transaction
begin transaction
if car1.free
then car.reserve;
end transaction
begin transaction
car.order;
end transaction
begin transaction
account.open;
end transaction
begin transaction
if car1.free
then car.reserve;
end transaction
begin transaction
account.open;
end transaction
2PL TS
optimistic
not
serial

12. 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)
De probleem stelling voor ons onderzoek kan als volgt geformuleerd worden. Allereerst dient NEDIS in vesrchillende omgevingen te opererern. Dit houdt in dat het moet opereren binnen verschillende landen, voor verschillende auto merken en voor verschillende dealers.
Reuse

13. 1. Requirements Analysis
Interviews
Literature
Study
System Study

14. 1. Requirements Analysis
Understand problem from client’s perspective:
Textual Requirement Specifications
Use-Cases
Scenarios
Prototypes
State Transition Diagrams
Conventional requirements analysis techniques.

15. Use case Modeling
Transaction Protocol
Adaptation Protocol

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

17. Generalizing Requirements
Initial Requirements
Generalized/Restated 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.

18. Identifying Subproblems
Transparent Concurrency Control
P2.
Transparent Recovery
P3.
Transparent Transaction Management
P4.
Adaptable Transaction Protocols
Optimistic,
Two-PL,
Timestamp Ordering...
Image Logging
Operation Logging
Restarting
Checkpointing
Flat, Nested,
Open, Closed?
Initialization,
compile-time,
run-time?
P0.
Adaptable Transaction Architecture

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

20. 3. Domain Analysis in Synbad
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
Domain Experts
Domain Literature

21. 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. Identify the essence of the domain, the fundamental stable concepts….
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. 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

24. Map problems to domains
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
P0.
Adaptable Transaction Architecture
P1.
Transparent Concurrency Control
P2.
Transparent Recovery
P3.
Transparent Transaction Management
P4.
Adaptable Transaction Protocols

25. Map problems to domains
Solution Domain
P0.
Adaptable Transaction Architecture
P1.
Transparent Concurrency Control
P2.
Transparent Recovery
P3.
Transparent Transaction Management
P4.
Adaptable Transaction Protocols
Transaction Management
Concurrency Control
Recovery
Adaptability

26. Search knowledge sources in domain
Domain: Transaction Processing ID
Knowledge Source
Form
KS1
Concurrency Control & Recovery in Database Systems [Bernstein et al. 87]
Textbook
KS2
Atomic Transactions [Lynch et al. 94]
KS3
An Introduction to Database Systems [Date 90]
KS4
Database Transaction Models for Advanced Applications [Elmagarmid 92]
KS5
The design and implementation of a distributed transaction system based on atomic data types [Wu et al. 95]
Journal. paper
KS6
Transaction processing: concepts and techniques [Gray & Reuter 93]
KS7
Principles of Transaction Processing [Bernstein & Newcomer 97]
KS8
Transactions and Consistency in Distributed Database Systems [Traiger et al. 82]
Journal paper

27. Problems, Knowledge Domain, Knowledge Source

28. Extract common concepts from knowledge sources
Transactions
Systems
Domain Literature
common
Existing Systems
Domain Experts

29. Glossary of Domain Transaction Domain Transaction Transaction Manager
The 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.
PolicyManager
PolicyManager 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.
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.
Transaction
Transaction
Manager
DataManager
Transaction Domain
PolicyManager
RecoveryManager
Scheduler

30. Identifying basic concepts
The transaction manager provides transaction operations for the application which accesses the objects.
Transaction
Manager
Transaction
Application
manages
accesses
Atomic
Object

31. 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
Recovery
Manager

32. 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
Data
Manager

33. Top-Level conceptual architecture
Transaction
Application
Manager
Atomic
Object
manages
accesses
Begin transaction
Begin transaction
Policy
Manager
coordinates
Read/Update
Determine Policy
Data
Manager
Scheduler
Recovery
coordinates
manages
Request
Concurrency Control
Log, Undo?

34. 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. Identify Knowledge Domains per Component
Specific Domains

36. 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].
KS4
Concurrency Control & Recovery in Database Systems [Bernstein et al. 87]
KS5
Concurrency Control and Reliability in Distributed Systems [Bhargava 87]
KS6
Concurrency Control in Distributed Database Systems [Bernstein & Goodman 83]

37. Scheduler Conceptual Architecture
Synchronization
Decision
uses
Commit
Protocol
has
Abort
Accept
Handler
Reject
Delay
Global
interacts
Performance
Failure
Management

38. 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!

39. Alternative Design Space Analysis
coordinates
manages
accesses
<Concept>
Transaction
Application
<concept>
Manager
Data
Scheduler
Recovery
Object
Policy

40. Performance Failure Detector
Feature Modeling
Scheduler
Scheme
Strategy
Performance Failure Detector
TwoPL
Timstamp Ordering
Optim.
Serial.
Aggr.
Cons..
Deadlock Detection
Inf. Block.
Infinite Rest.art
Cyclic Rest.art
32 alternatives
RecoveryManager
Log Manager
Failure
Atomicity
Synchronizer
Restarting
Oper. Log
Defer. Update
Update in Place
Recoverable.
Cascadeless
Checkpointing
Strict
Undo
Redo
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. Defining inter-component constraints
transaction
transaction manager
less certain!
policy manager
data manager
conflicts
scheduler
recovery manager

42. Defining intra-component constraints
transaction
policy manager
transaction manager
data manager
policy manager
data manager
scheduler
recovery manager
scheduler
conflicts

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

44. Focus by client transaction transaction manager policy manager
data manager
scheduler
recovery manager

45. 5. Architecture Specification
Transaction
Theory

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