Synthesis-Based%20Software%20Architecture%20Design - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Synthesis-Based%20Software%20Architecture%20Design

Description:

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

Number of Views:62
Avg rating:3.0/5.0
Slides: 47
Provided by: Bedir3
Learn more at: http://trese.cs.utwente.nl
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Synthesis-Based%20Software%20Architecture%20Design


1
Synthesis-Based Software Architecture Design
Bedir TekinerdoganUniversity of Twente
Department of Computer ScienceEnschede, The
Netherlands email bedir_at_cs.utwente.nl http//ww
w.cs.utwente.nl/bedir/
http//trese.cs.utwente.nl/taosad/
2
EngineeringProblem Solving
Requirement Specification (Need)
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
5
Car Dealer Information System
6
Selecting the Sub-Systems
7
Transactions - Concurrency
Car reservation application
Dealer 1
available
Dealer 2
8
Transactions - Failures
Money transfer application
withdraw(100)
account 1
account1.withdraw(100) account2.store(100).
store(100)
failure
account 2
9
Atomic Transactions
  • startTransaction - start a transaction.
  • commit / endTransaction - successfully completes
    the transaction.
  • abort - restores the effects of the transaction.

10
Transaction Specifications
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
Projects Problem Statement
13
1. Requirements Analysis
Requirements Analysis
14
1. Requirements Analysis
  • Understand problem from clients perspective
  • Textual Requirement Specifications
  • Use-Cases
  • Scenarios
  • Prototypes
  • State Transition Diagrams

15
Use case Modeling
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
  • 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.
  • 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.

18
Identifying Subproblems
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
  1. For each sub-problem, identify and prioritize the
    solution domains P ? D
  2. For each solution domain, identify and prioritize
    knowledge sources D?KS
  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)

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
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
  • 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

ACM Computing Classification System
http//www.acm.org/class/1998/overview.html
24
Map problems to domains
25
Map problems to domains
Solution Domain
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 Textbook
KS3 An Introduction to Database Systems Date 90 Textbook
KS4 Database Transaction Models for Advanced Applications Elmagarmid 92 Textbook
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 Textbook
KS7 Principles of Transaction Processing Bernstein Newcomer 97 Textbook
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
29
Glossary of Domain
Transaction 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. DataMana
ger 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.

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.

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.

33
Top-Level conceptual architecture
Begin transaction
Begin transaction
Determine Policy
Read/Update
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
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. 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
37
Scheduler Conceptual Architecture
38
4. Alternative Design Space Analysis
1. Define Alternatives for each architectural
concept 2. Identify and describe constraints
among alternatives.
39
Alternative Design Space Analysis
40
Feature Modeling
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.
  • ltScheduler.sch.optgt mutex ltRecoveryManager.Fas.Str
    gt
  • Example constraint within a concept
  • A two phase locking scheduler requires deadlock
    detection.
  • ltScheduler.sch.2plgt requires ltScheduler.PFD.DLgt

W. Weihl. The impact of recovery on concurrency
control. Proc. of the 8th ACM-SIGACT-SIGMOD sympos
ium 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. 
About PowerShow.com