Synthesis-Based Software Architecture Design

1. Synthesis-Based Software Architecture Design Bedir TekinerdoğanUniversity of Twente Department of Computer ScienceEnschede, The Netherlands e:mail – bedir@cs.utwente.nl http://www.cs.utwente.nl/~bedir/ http://trese.cs.utwente.nl/taosad/

2. Conceive Technical Problem Solution Domain Knowledge Search Apply Impacts Identify Alternative(s) SolutionDescription Select Evaluate Implement (Quality) Criteria Artifact Mature Engineering adheres to this problem solving model 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, 2000.

3. Synthesis-Based Software Architecture Design

4. INEDIS Example Project: Atomic TransactionArchitecture Design for Car Dealer System Synthesis-Based Software Architecture Design Example: Atomic Transaction Architecture

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

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

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

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

9. startTransaction if car.free then car.reserve; else abort end. endTransaction; No concurrency or recovery code needed! Atomic Transactions • startTransaction - start a transaction. • commit / endTransaction - successfully completes the transaction. • abort - restores the effects of the transaction.

10. 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 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. 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. Requirements Interviews System Study Literature Study 1. Requirements Analysis Requirements Analysis

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

15. Transaction Protocol Adaptation Protocol 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 • 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. 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.

18. Optimistic, Two-PL, Timestamp Ordering... P1. Transparent Concurrency Control Image Logging Operation Logging Restarting Checkpointing P2. Transparent Recovery P3. Transparent Transaction Management Flat, Nested, Open, Closed? P4. Adaptable Transaction Protocols Initialization, compile-time, run-time? 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 • 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. 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 http://www.acm.org/class/1998/overview.html

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

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

26. Search knowledge sources in domain Domain: Transaction Processing

27. Problems, Knowledge Domain, Knowledge Source

28. Transactions Systems Domain Literature common Existing Systems Domain Experts 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. 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. manages Transaction Manager Atomic Object accesses Transaction Application Identifying basic concepts • The transaction manager provides transaction operations for the application which accesses the objects.

31. coordinates manages Recovery Manager Data Manager Atomic Object Scheduler coordinates 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. coordinates Transaction Manager Data Manager Policy Manager coordinates 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. manages accesses coordinates Transaction Manager Transaction Application Recovery Manager Policy Manager Data Manager Atomic Object Scheduler manages coordinates Top-Level conceptual architecture Begin transaction Begin transaction Read/Update Determine Policy 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. Specific Domains Identify Knowledge Domains per Component

36. Refining the Scheduler Domain: Concurrency control

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

38. Current architecture design approaches do not have an explicit alternative space analysis process! 4. Alternative Design Space Analysis 1. Define Alternatives for each architectural concept 2. Identify and describe constraints among alternatives.

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

40. RecoveryManager Scheduler Checkpointing PerformanceFailure Detector Restarting LogManager Failure Atomicity Synchronizer Scheme Strategy Commit Fuzzy Undo Redo Aggr. Cons.. Cache No-Undo/Redo TwoPL Oper.Log Undo/No-Redo Recoverable. Defer.Update TimstampOrdering Cascadeless DeadlockDetection CyclicRest.art No-Undo/No-Redo Strict Optim. Updatein Place Serial. Inf. Block. InfiniteRest.art 118 alternatives 32 alternatives 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. <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.