Presentation is loading. Please wait.

Presentation is loading. Please wait.

Synthesis-Based Software Architecture Design

Similar presentations


Presentation on theme: "Synthesis-Based Software Architecture Design"— Presentation transcript:

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. 


Download ppt "Synthesis-Based Software Architecture Design"

Similar presentations


Ads by Google