Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Synthesis-Based Software Architecture Design Bedir Tekinerdoğan University of Twente Department of Computer Science Enschede, The Netherlands e:mail –"— Presentation transcript:

1

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

3 © Bedir Tekinerdoğan 2 Engineering=Problem Solving Requirement Specification (Need) See: B. Tekinerdogan, Chapter 2, On the Notion of Software Engineering: A Problem Solving Perspective, PhD Thesis, University of Twente, Solution Domain Knowledge Search Technical Problem Conceive Artifact Implement Solution Description Apply Alternative(s) Identify (Quality) Criteria Evaluate Select Impacts Mature Engineering adheres to this problem solving model

4 © Bedir Tekinerdoğan 3 Synthesis-Based Software Architecture Design

5 © Bedir Tekinerdoğan 4 Synthesis-Based Software Architecture Design Example Project: Atomic Transaction Architecture Design for Car Dealer System INEDIS Example: Atomic Transaction Architecture

6 © Bedir Tekinerdoğan 5 Large and complex distributed information system server Dealers PC work- stations Manufacturers & Importerships Lease Companies External services Registration Taxes Workshop & order processing Stock Management New and used car management Accounting SubDealers Car Dealer Information System

7 © Bedir Tekinerdoğan 6 Selecting the Sub-Systems Transaction Sub-System Control-Flow Sub-System.…….. Other Subsystems system layer application layer Workshop & Order processing Stock Management New & used car Management AccountingLeasing Other Services network

8 © Bedir Tekinerdoğan 7 Car reservation application available Dealer 1 Dealer 2 Inconsistency through concurrent access. if car.available then car.reserve end. if car.available then car.reserve end. Transactions - Concurrency

9 © Bedir Tekinerdoğan 8 Money transfer application withdraw(100) account1.withdraw(100); account2.store(100). store(100) account 1 account 2 failure Inconsistency through failures. Transactions - Failures

10 © Bedir Tekinerdoğan 9 startTransaction if car.free then car.reserve; else abort end. 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

11 © Bedir Tekinerdoğan transaction system provides transparent concurrency control and recovery Transaction Specifications begin transaction if car.free then car.reserve; 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 account.open; end transaction begin transaction account.transfer; end transaction

12 © Bedir Tekinerdoğan Different Transaction Implementations begin transaction if car1.free then car.reserve; 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 account.open; end transaction begin transaction account.transfer; end transaction 2PLTSoptimistic not serial

13 © Bedir Tekinerdoğan 12 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 Projects Problem Statement

14 © Bedir Tekinerdoğan Requirements Analysis Requirements Analysis Interviews System Study Literature Study Requirements

15 © Bedir Tekinerdoğan 14 Understand problem from clients perspective: Textual Requirement Specifications Use-Cases Scenarios Prototypes State Transition Diagrams Conventional requirements analysis techniques. 1. Requirements Analysis

16 © Bedir Tekinerdoğan 15 Transaction ProtocolAdaptation Protocol Use case Modeling

17 © Bedir Tekinerdoğan 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

18 © Bedir Tekinerdoğan 17 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 RequirementsGeneralized/Restated Requirements

19 © Bedir Tekinerdoğan 18 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 Logging Operation Logging Restarting Checkpointing Flat, Nested, Open, Closed? Initialization, compile-time, run-time?

20 © Bedir Tekinerdoğan Domain Analysis is the systematic activity of collecting, organizing and storing domain knowledge

21 © Bedir Tekinerdoğan 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) Domain Literature Domain Experts Existing Systems

22 © Bedir Tekinerdoğan 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.

23 © Bedir Tekinerdoğan 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….

24 © Bedir Tekinerdoğan 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.1 CONTROL STRUCTURES AND MICROPROGRAMMINGD.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.8 PERFORMANCE AND RELIABILITYC.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.3 SPECIAL-PURPOSE AND APPLICATION-BASED SYSTEMSJ.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.1 PROGRAMMING TECHNIQUESE D.2 SOFTWARE ENGINEERING (K.6.3)D.2 SOFTWARE ENGINEERINGK.6.3 D.3 PROGRAMMING LANGUAGES D.4 OPERATING SYSTEMS (C)D.4 OPERATING SYSTEMSC 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.4 CODING AND INFORMATION THEORYH.1.1 E.5 FILES (D.4.3, F.2.2, H.2)E.5 FILESD.4.3F.2.2H.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.2 ANALYSIS OF ALGORITHMS AND PROBLEM COMPLEXITYB.6B.7F.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.2 DATABASE MANAGEMENTE.5 H.3 INFORMATION STORAGE AND RETRIEVAL H.4 INFORMATION SYSTEMS APPLICATIONS H.5 INFORMATION INTERFACES AND PRESENTATION (e.g., HCI) (I.7)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.6 SIMULATION AND MODELINGG.3 I.7 DOCUMENT AND TEXT PROCESSING (H.4, H.5)I.7 DOCUMENT AND TEXT PROCESSINGH.4H.5 I.m MISCELLANEOUS ……. ACM Computing Classification System

25 © Bedir Tekinerdoğan 24 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)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)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

26 © Bedir Tekinerdoğan 25 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

27 © Bedir Tekinerdoğan 26 Search knowledge sources in domain IDKnowledge SourceForm 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 Domain: Transaction Processing

28 © Bedir Tekinerdoğan 27 Problems, Knowledge Domain, Knowledge Source

29 © Bedir Tekinerdoğan 28 Extract common concepts from knowledge sources Domain Literature Domain Experts Existing Systems Transactions Systems common

30 © Bedir Tekinerdoğan 29 Glossary of Domain Transaction Domain Transaction Manager Scheduler RecoveryManager DataManager PolicyManager 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. 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.

31 © Bedir Tekinerdoğan 30 Identifying basic concepts The transaction manager provides transaction operations for the application which accesses the objects. manages accesses Transaction Manager Transaction Application Atomic Object

32 © Bedir Tekinerdoğan 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. Atomic Object manages Data Manager coordinates Scheduler coordinates Recovery Manager

33 © Bedir Tekinerdoğan 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 Data Manager coordinates Transaction Manager Policy Manager

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

35 © Bedir Tekinerdoğan 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

36 © Bedir Tekinerdoğan 35 Identify Knowledge Domains per Component Specific Domains

37 © Bedir Tekinerdoğan 36 Refining the Scheduler IDKnowledge SourceForm 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

38 © Bedir Tekinerdoğan 37 Scheduler Conceptual Architecture Scheduler Synchronization Decision uses Commit Protocol has Abort Protocol has Accept Handler has Reject Handler has Delay Handler has Global Synchronization Decision interacts Performance Failure Management interacts

39 © Bedir Tekinerdoğan 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

40 © Bedir Tekinerdoğan 39 coordinates manages accesses coordinates manages Transaction Application Transaction Manager Data Manager Scheduler Recovery Manager Data Object Policy Manager Alternative Design Space Analysis

41 © Bedir Tekinerdoğan 40 Feature Modeling Scheduler SchemeStrategy 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)

42 © Bedir Tekinerdoğan 41 transaction transaction manager policy manager data manager schedulerrecovery manager less certain! conflicts Defining inter-component constraints

43 © Bedir Tekinerdoğan 42 transaction transaction manager policy manager data manager schedulerrecovery manager conflicts scheduler data manager policy manager Defining intra-component constraints

44 © Bedir Tekinerdoğan 43 Reducing Design Space – Domain Constraints Example constraint among concepts: An optimistic scheduler cannot be combined with a strict recoverymanager. mutex Example constraint within a concept: A two phase locking scheduler requires deadlock detection. requires W. Weihl. The impact of recovery on concurrency control. Proc. of the 8 th ACM-SIGACT-SIGMOD symposium on Principles of Database Systems, Philadelphia, 1989.

45 © Bedir Tekinerdoğan 44 transaction transaction manager policy manager data manager schedulerrecovery manager Focus by client

46 © Bedir Tekinerdoğan Architecture Specification Transaction Theory

47 © Bedir Tekinerdoğan 46 More information... B. Tekinerdogan, Synthesis Based Software Architecture Design, Ph.D. thesis, University of Twente, The Netherlands, March 2000.Synthesis Based Software Architecture Design 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 Bedir Tekinerdoğan University of Twente Department of Computer Science Enschede, The Netherlands e:mail –"

Similar presentations


Ads by Google