synthesis-based software architecture design bedir tekinerdoğan university of twente department of...
TRANSCRIPT
Synthesis-Based Software Architecture Design
Bedir Tekinerdoğan
University of Twente
Department of Computer ScienceEnschede, The Netherlands
e:mail – [email protected]
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.