Synthesis-Based Software Architecture Design - PowerPoint PPT Presentation

Loading...

PPT – Synthesis-Based Software Architecture Design PowerPoint presentation | free to download - id: 61f28-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Synthesis-Based Software Architecture Design

Description:

Taj Mahal. Taj Mahal : Built by Mogol Shah Cihan (turkish origin) in memory of his beloved ... Summary on Structure in History ... – PowerPoint PPT presentation

Number of Views:113
Avg rating:3.0/5.0
Slides: 86
Provided by: bedirteki
Learn more at: http://trese.cs.utwente.nl
Category:

less

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

Title: Synthesis-Based Software Architecture Design


1
Synthesis-Based Software Architecture Design
  • Bedir TekinerdoganBillkent University,
  • Department of Computer EngineeringBilkent,
    Ankara, Turkey
  • email - bedir_at_cs.bilkent.edu.tr
  • http//www.cs.bilkent.edu.tr/bedir/

2
About the presenter...
  • Since 1974 in The Netherlands...
  • Affiliated from the University of Twente, The
    Netherlands (since September 15, 2002).
  • Education
  • All in The Netherlands (Nursery school, primary
    school, High school, University, MSc, Research
    Assistant, PhD, Post-Doc, Assistant Professor...)
  • MSc. in Computer Science in (1994) and PhD (2000)
    at University of Twente
  • Background/Research
  • Software Engineering (in particular
    object-orientation)
  • Software Architecture Design
  • Aspect-Oriented Software Development

3
Related Topics
  • Software Product Line Engineering
  • Domain Engineering and Application Engineering
  • Scoping Product Lines
  • Aspect-Oriented Software Development
  • How to identify and cope with crosscutting
    concerns?
  • Automating Software Design Methods
  • Artifact/Heuristic Rule Modeling
  • Alternative Management
  • How to identify, select, and balance design
    alternatives?
  • Synthesis-Based Software Architecture Design
    (Synbad)
  • How to apply synthesis in architecture design?

4
Table of Contents
Part I. Rationale for Software Architecture
5
Part IRationale for Software Architecture
  • Intuitive notion of architecture
  • Structure in other disciplines
  • Structure in history of software engineering

6
What is Architecture?
  • Architecture (Websters)  1 the art or science
    of building specifically the art or practice of
    designing and building structures and especially
    habitable ones2 agtformation or construction as
    or as if as the result of conscious act ltthe
    architecture of the gardengt b a unifying or
    coherent form or structure ltthe novel lacks
    architecturegt3 architectural product or
    work4 a method or style of building5 the
    manner in which the components of a computer or
    computer system are organized and integrated

7
Building Architectures
8
Computer Architecture
9
Car Architecture
10
Architecture
11
Taj Mahal
12
Bricks are not enough...
Build me a palace!
13
You need an architect first...
14
Software Development
  • Lists
  • Arrays
  • Class
  • Object
  • Procedures
  • Functions
  • Algorithms
  • Etc.

15
Large, complex software systems...
  • Large (Distributed) System
  • Many people working on the same problem
  • Overly Complex
  • Millions of Code...
  • Should be delivered on time and within budget!

Programming in the Large
16
Coding is not enough...
  • Lists
  • Arrays
  • Class
  • Object
  • Procedures
  • Functions
  • Algorithms
  • Etc.

17
A Software Architect?
18
Does Software have Structure?!
  • Yes!!
  • Dijkstra, 1968
  • ...Correct arrangement of the structure of
    software systems before simple programming...
  • Parnas, 1972
  • ...selected criteria for the decomposition of
    the system impact the structure of the programs
    and several design principles must be followed to
    provide a good structure...

Edsger Dijkstra 1930-2002
19
Structure in Software
  • 1960s - Structured Programming
  • Functional/algorithmic decomposition
  • 1970s - Structured Design
  • Methodology/guidelines for dividing programs into
    subroutines.
  • 1980s Modular programming languages
  • Modular (object-based) programming
  • Grouping of sub-routines into modules with data.
  • Object decomposition
  • 1990s Towards Software Architectures
  • Object-Oriented Analysis/Design/Programming
    started being commonly used
  • Software Architecture Design
  • 2000s- Software Product Line Architectures

20
Structure in Software
APPROACH
PROBLEMS SOLVED
1950
Programming any-which-way
Simple, algorithmic
1960
Programming in-the-small - information hiding,
modularization
Data intensive, business applications
1970
Programming in-the-large - object-oriented
design - CASE tools - libraries
1980
Large, complex, distributed
1990
2000
Programming in-the-world - software
architecture, product lines, aspect-orientation
Mega programs
2010
21
Rationale for Software Architecture
Design
Software Architecture
Analysis
Implementation
Problem understanding
  • Architecture is explicit representation of global
    structure of system
  • Improves communication among different
    stakeholders
  • Guides analysis and design phases
  • Can predict global performance
  • Gross level reuse

22
Summary on Structure in History
  • The more complex the problems the more the need
    to provide an explicit structure.
  • Increased consciousness on structure of software
  • Structure idea did not stop at programming level
    but moved up to design methods.
  • This has logically culminated in Software
    Architecture
  • Successfully applied in industry which have
    specific architecture design teams/divisions.
  • Active Software Architecture Design community
    with its own conferences, workshops,
    publications...
  • Is one of the most fundamental concepts in
    software engineering.

23
Part II Software Architecture Design Methods
  • Existing methods
  • Classification and Evaluation

24
Software Architecture is
  • The gross-level structure of the system
  • which comprise software components,
  • and the relationships among them.

How to produce a software architecture?
25
Architecture Design Methods
  • The Unified Software Development Process, G.
    Booch, J. Rumbaugh I, Jacobson.
  • A System of Patterns Pattern-Oriented Software
    Architecture, F. Buschman et al.
  • (Object-Oriented Modeling and Design, J. Rumbaugh
  • Design and use of software architectures, J.
    Bosch.
  • Software Architecture in Practice, P. Clements,
    L. Bass R. Kazman
  • Applied Software Architecture, C. Hofmeister et
    al.
  • Software Product Lines, P. Clements L. Northrop
  • Software Architectures Perspectives on an
    Emerging Discipline, M. Shaw
  • Synthesis-Based Software Architecture Design,
    Tekinerdogan Aksit

26
Which one to select?
B. Tekinerdogan and M. Aksit. Classifying and
Evaluating Architecture Design Methods, in
Software Architectures and Component Technology
The State of the Art in Research and Practice,
M. Aksit (Ed.), Kluwer Academic Publishers,  pp.
3 - 27, 2001.
27
Classification of Methods
  • What is the source of architectural abstractions?
  • Artifact-driven
  • Use case/Scenario-driven
  • Pattern-driven
  • Domain-driven

28
Artifact-driven
  • Start from textual requirements
  • Look at artifact types in the method and try to
    identify artifacts from requirements
    specification using heuristic rules.
  • Group the related artifacts in subsystems, these
    are the architectural components.
  • Define the relations between subsystems.

29
Example PC Factory
Requirements Specification PC FACTORY Date
16-October 2002 A software system for a computer
company, which consists of two departments, a
factory and sales and marketing department. The
factory assembles desktop PCs and tower PCs. All
the components of a PC are delivered by different
external suppliers. A PC consists of one monitor,
a cabinet, and a keyboard. The cabinet includes a
chassis. A chassis on its turn is composed of a
bus, floppy disk drive, an optional CD-ROM drive,
a memory unit, CPU, and power supply. A bus may
incorporate a network card. A memory unit
includes many RAM chips. The sales and marketing
department administers properties of each PC,
like the type, weight, make, price, amortization,
power consumption etc. A client uses a purchase
order to order PCs or set of computer components
from the company.
30
Applying Heuristics
Tentative Class identification Extract nouns
from the problem statement. Select nouns as
tentative classes. Extract tentative classes from
application domain knowledge. Extract tentative
classes from general knowledge. Class
identification Class The identified tentative
classes are used to identify classes IF
tentative class ltisRedundantgtTHEN eliminate
tentative class. IF tentative class
ltisIrrelevantgtTHEN eliminate tentative class.
IF tentative class ltisVaguegtTHEN eliminate
tentative class. IF tentative class
ltisAttributegtTHEN select tentative class as
Attribute. IF tentative class ltisOperationgtTHEN
eliminate tentative class. IF tentative class
ltisRolegtTHEN eliminate tentative class. IF
tentative class ltisImplementationConstructgtTHEN
eliminate tentative class. Select remaining
tentative classes as right classes.
I have to look for classes What are the
heuristic rules?
Ok, this is a class, this isnt. This might also
be a class, And this one also
31
Identified Classes/Subsystems
Department
Computer
Factory
Tower PC
Sales Department
Desktop PC
Chassis
Cabinet
Monitor
Order
Keyboard
Cabinet
Supplier
32
Identified Architecture
Order
Computer
Department
Supplier
33
Obstacles Artifact-Driven Approach
  • Textual requirements are imprecise and are less
    useful as a source for deriving architectural
    abstractions
  • Subsystems have poor semantics to serve as
    architectural components
  • Composition of subsystems is not well-supported.

34
Use case driven
  • Extract use cases
  • Identify fundamental classes from use cases.
  • Group these classes in packages, these are the
    architectural components.
  • Define the relations between packages.

http//www.rational.com/rup/
35
Obstacles
  • Selecting architecturally relevant use cases is
    not systematically supported.
  • Use cases do not provide a solid basis for
    architectural abstractions
  • Package construct has poor semantics to serve as
    architectural abstractions.

36
Pattern driven
  • Start with requirement specification
  • Select appropriate patterns from a pattern base.
  • Compose these patterns.

37
Pattern
  • Pattern is a generic and reusable design solution
    for recurring problems in a given context.
  • Each pattern describes a solution, problem and
    the context.
  • Patterns can be used to construct software
    architectures.
  • Examples
  • Layers, Blackboard, Pipes and Filters, etc.

Pattern Base
38
Obstacles of Pattern-Driven Approaches
  • Patterns only might not be sufficient for
    deriving architectural abstractions.
  • Selection of patterns is not well supported and
    depends on experience of software engineer.
  • Applying patterns is not straightforward and
    requires thorough analysis of the problem.
  • Composing patterns is not well supported.

39
Part III Architecture Synthesis Process
  • Problem Solving Model
  • Synthesis Process
  • Example Transaction Architecture

40
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.
41
Synthesis-Based Software Architecture Design
42
Example Atomic Transaction Architecture
43
Car Dealer Information System
44
Selecting the Sub-Systems
45
Transactions - Concurrency
Car reservation application
Dealer 1
available
Dealer 2
46
Transactions - Failures
Money transfer application
withdraw(100)
account 1
account1.withdraw(100) account2.store(100).
store(100)
failure
account 2
47
Atomic Transactions
  • startTransaction - start a transaction.
  • commit / endTransaction - successfully completes
    the transaction.
  • abort - restores the effects of the transaction.

48
Transaction Specifications
transaction system provides transparent
concurrency control and recovery
49
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
50
Projects Problem Statement
51
1. Requirements Analysis
Requirements Analysis
52
1. Requirements Analysis
  • Understand problem from clients perspective
  • Textual Requirement Specifications
  • Use-Cases
  • Scenarios
  • Prototypes
  • State Transition Diagrams

53
Use case Modeling
54
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
55
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.

56
Identifying Subproblems
P0. Adaptable Transaction Architecture
57
3. Domain Analysis
  • is the systematic activity of
  • collecting,
  • organizing and
  • storing domain knowledge

58
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
59
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.

60
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.
61
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
62
Map problems to domains
63
Map problems to domains
Solution Domain
Transaction Management
Concurrency Control
Recovery
Adaptability
64
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
65
Problems, Knowledge Domain, Knowledge Source
66
Extract common concepts from knowledge sources
67
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
68
Identifying basic concepts
  • The transaction manager provides transaction
    operations for the application which accesses the
    objects.

69
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.

70
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.

71
Top-Level conceptual architecture
Begin transaction
Begin transaction
Determine Policy
Read/Update
Request
Concurrency Control
Log, Undo?
72
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

73
Identify Knowledge Domains per Component
74
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
75
Scheduler Conceptual Architecture
76
4. Alternative Design Space Analysis
1. Define Alternatives for each architectural
concept 2. Identify and describe constraints
among alternatives.
77
Alternative Design Space Analysis
78
Feature Modeling
alternative Scheduler (Scheme TwoPl,
Strategy Aggressive, Performance Failure
Detector Infinite Blocking)
79
Defining inter-component constraints
transaction
transaction manager
less certain!
policy manager
data manager
conflicts
scheduler
recovery manager
80
Defining intra-component constraints
transaction
policy manager
transaction manager
data manager
policy manager
data manager
scheduler
recovery manager
scheduler
conflicts
81
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.
82
Focus by client
transaction
transaction manager
policy manager
data manager
scheduler
recovery manager
83
5. Architecture Specification
Transaction Theory
84
More information...
  • PhD Thesis
  • Bedir Tekinerdogan, Synthesis-Based Software
    Architecture DesignUniversity of Twente, The
    Netherlands, march 23, 2000.
  • http//www.cs.bilkent.edu.tr/bedir/PhDThesis/
  • e-mail bedir_at_cs.bilkent.edu.tr

85
(No Transcript)
About PowerShow.com