Architectures for Software Systems - PowerPoint PPT Presentation

Loading...

PPT – Architectures for Software Systems PowerPoint presentation | free to download - id: 929cf-ZTczN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Architectures for Software Systems

Description:

Lecture 3: Frontier of Software Architecture. Emerging techniques and technologies ... Good designers (implementors don't necessarily qualify) ... – PowerPoint PPT presentation

Number of Views:41
Avg rating:3.0/5.0
Slides: 75
Provided by: DAVIDG182
Learn more at: http://tucs.fi
Category:

less

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

Title: Architectures for Software Systems


1
  • Architectures for Software Systems
  • Lecture 2
  • Software Architecture in Practice

David Garlan Carnegie Mellon University
2
Course Outline
  • Lecture 1 Overview of Software Architecture
  • What is software architecture?
  • Architectural concepts styles
  • Lecture 2 SW Arch in Practice
  • Product line frameworks
  • Integration standards
  • Architectural design reviews
  • Architectural analysis
  • Lecture 3 Frontier of Software Architecture
  • Emerging techniques and technologies
  • How to find out more about this topic

3
This Lecture
  • In this lecture, we survey four aspects of
    architecture are essential to practical software
    systems development
  • Product line frameworks
  • Integration standards
  • Architectural design reviews
  • Architectural analysis

4
Specialized Architectural Styles
  • Introducing more specificity to an architectural
    style leads to
  • More constrained designs
  • Ability to exploit specialized analyses, code
    reuse, tools
  • There is a spectrum of points on the
    power-generality continuum

Generic Component Integration Standards
Domain-Spec Component Integration Standards
5
Part 1 Product Line Frameworks
  • Observation most products are similar to others
    built before and to be built in the future
  • Could achieve economies of production by
  • defining the common, shared aspects
  • providing reusable infrastructure to support
    these common aspects
  • defining a way to specialize the framework for a
    particular product
  • At the core of this effort one typically finds an
    architecture that establishes a common vision for
    the structure, content, and variability of
    products in the family

6
Product-line Frameworks
Individual product development
Product-line architectures (company assets)
Development Effort
Off-the-shelf components (OS, tools, compiler,
...)
7
Economics of Product Lines
Cumulative Cost
Number of Products Built
8
Case StudyOscilloscopes at Tektronix
  • Increasing complexity of instrumentation systems.
  • Increasing role of software in products that were
    once largely hardware
  • Raised expectations of users
  • Separate development cultures.
  • Similar products developed by different divisions
  • Little sharing
  • Build-from-scratch methods.
  • New hardware gt new software New UI gt new
    software
  • Inflexible and brittle products.
  • Increasingly serious bugs due to concurrency.
  • Excessive time-to-market ( 4-5 years).

9
The Challenge
  • Allow reuse between product divisions
  • Build next generation instrumentation systems
  • Support better interactive response to user
    changes
  • Multiple hardware platforms for same user
    interface
  • Multiple user interfaces for same platform
    (vertical markets)
  • Reduce time to market

10
The Arena Oscilloscopes
traces and measurements
waveforms
signals
Oscilloscope
11
Oscilloscope O-O Approach
First attempt was an Object-Oriented Decomposition
waveform w time-gt voltage max -gt
voltage min -gt voltage invert ... add ...
Result Hundreds of classes, little structure, no
overall pattern
12
Oscilloscope Layered Approach
Second attempt was a Layered Architecture
Result Boundaries of abstraction not realistic
13
Oscilloscope Pipe-Filter Approach
Third attempt was a Pipe-Filter Architecture
Signal
Waveform
Trace
Times
Measurement
Result A better model, but not clear how to
model user input.
14
Oscilloscope Extended Pipe-Filter Approach
Fourth attempt was Pipe-Filter Architecture with
Parameterized Filters.
Size
Coupling
Kind,Rate
Trans
Couple
Acquire
Clip
To-XY
Signal
Waveform
Trace
Times
Measure
Measurement
Result Elegant model, but not directly useful to
implementors.
15
Oscilloscope Solution
  • Pipe-Filter Architecture with Parameterized
    Filters and Colored Pipes

Coupling
Kind,Rate
Trans
Size
Couple
Acquire
Clip
To-XY
Signal
Waveform
Trace
Times
Measure
Measurement
Result Elegant model, and implementable.
16
Results
  • Models used as basis for next generation of
    oscilloscope products.
  • Led to highly successful framework, in which
    time-to-market was cut substantially for products
    in the family.
  • High reliability of products.
  • Flexibility of user interface.
  • Led to new frameworks beyond oscilloscopes.
  • New thrust of research/development
    collaborations.

17
Mechanisms that Helped
  • Use of formalism (for a later lecture)
  • several Z models
  • used to clarify discussion
  • also contributed to documentation
  • Use of prototyping
  • concurrent with design
  • mostly focused on translation to object-oriented
    concepts and performance
  • Development environment for engineers
  • applicable once architectural style was defined
  • Frequent design reviews
  • grounded design in reality

18
Mechanisms that Helped (continued)
  • Success requires
  • Domain experts and system builders
  • Expertise in abstraction and formal models
  • Willingness to abandon old design patterns
  • Willingness to reject inappropriate architectures
  • Tools
  • Not needed during conceptualization
  • Essential during development
  • Management
  • Must keep hands off the process initially
  • Must help enforce standards later

19
Some Conclusions
  • Architectural product-line design involves
    iteration
  • Simple PF gt (refine component types)
  • Configurable PF gt (refine connectors)
  • Configurable PF with colored pipes
  • Architectural product-line design involves
    interaction
  • Product developers (reality check)
  • Management (financial commitment
    follow-through)
  • Good designers (implementors dont necessarily
    qualify)
  • Extra-functional issues implementation concerns
    affect architectural choices
  • space considerations
  • latency concerns
  • Product line architectural frameworks pay off
  • significant reduction in time to market
  • significant improvement in quality

20
Part 2 Component Integration Standards
  • In general it is hard to make components
    developed by different parties work together
  • Signature conformance is not enough
  • orders of invocation
  • assumptions about locus of control
  • data representations
  • synchronization conditions
  • lookup/discovery/naming
  • failure handling
  • One way to ameliorate the problems is to get the
    parties to agree on certain standards of
    interoperability
  • Often called component integration standards (or
    frameworks)

21
Elements of Component Integration Standards
  • Rules about interfaces of components
  • structure, content, required capabilities
  • Rules of engagement
  • the connectors ways components interact
  • Run time infrastructure to support
    interoperability
  • often as an API to lower level communication
    services
  • Naming/discovery conventions
  • often via a name registry
  • Base of reusable assets
  • component building blocks
  • System generation tools
  • create running systems from descriptions of the
    parts

22
The Politics of Component Integration Standards
  • Some standards are de facto
  • often imposed by a major vendor (IBM, Microsoft,
    ATT, )
  • example COM, visual basic
  • Others are cooperative standards defined by a
    segment of the industry
  • typically designed by committee
  • often in reaction to the first category
  • examples NIST/ECMA model for CASE tools OMG
    standards (DCE, UML, ) HLA
  • Others are developed by national standards bodies
  • often growing out of the second category
  • examples OSI Protocol Stack, X/Open

23
Case Study The HLA
  • Simulation is big business
  • hundreds of simulators, vendors
  • one simulation training system for the Army cost
    2 Billion alone
  • Many applications
  • prediction
  • analysis
  • training
  • post mortem evaluations
  • Many varieties
  • real time
  • mixed virtual and real
  • statistical sampling

24
Distributed Simulation
  • A key problem is combining different simulations
    into a joint "exercise".
  • May involve dozens or hundreds of simulations
  • Usually highly distributed
  • Produced by multiple vendors
  • There are many different syntactic and semantic
    models
  • How data is represented
  • How time is represented
  • Whether real-time or off-line

25
History
  • Early days
  • Ad hoc simulations and brittle compositions
  • Emergence of standards
  • Usually only appropriate for certain class of
    simulation
  • Examples DIS, JSIMS
  • Many developed under auspices of Defense Modeling
    and Simulation Office (DMSO)
  • DIS Standard
  • Provided event-based broadcast
  • All simulations receive all events
  • Events are filtered at the receiving site
  • Does not scale
  • DoD interest in producing more comprehensive,
    scalable architectural standard

26
Emergence of the High Level Architecture (HLA)
  • Recognition that no specific architectural style
    or framework would satisfy all simulation needs
  • However, believed that could define common
    abstract architectural specification that could
    be specialized for specific simulation
    communities
  • Asked for feasibility proposals
  • Developed new proposed standard based on the
    synthesis of the best ideas from these proposals
  • Involved leading simulation architects and
    developers
  • Version 1.0 of the HLA published late 1996.
  • approx. 150 pages, pre/post condition format
  • Available on the web http//www.dmso.mil/projects
    /hla

27
Goals of the HLA
  • Define shared standard for simulation
  • protocols for interaction
  • data modeling mechanisms
  • procedures for set-up and take-down
  • Permit multiple implementation bases of the
    run-time infrastructure
  • allow different models for timing, data
    representation, etc.
  • different degrees of scalability allowed
  • multiple vendors
  • Specify clearly what are the rights and
    responsibilities of a simulation to participate
    in a simulation
  • essentially an API for simulations

28
Architecture of HLA Federation
29
Extracts of HLA Specification
30
Main Technical Features
  • Event-based interaction
  • Simulations publish certain event data and
    subscribe to other event data
  • SimInterface describes what a simulation can do
    and what its obligations are
  • Defined in terms of pre- post-conditions on API
    calls
  • The RTI is defined mainly in terms of 5 groups of
    calls
  • Federation, Declaration, Object, Ownership, Time
  • Each determines some portion of the overall
    protocol for communication and interaction

31
Key Issues in the Design
  • Time model
  • discrete event versus shared clock versus ...
  • Fidelity model
  • what is meaning of event data
  • Delivery policy
  • avoid bottlenecks
  • how do you say what you are interested in?
  • Handling of actions
  • sometimes not ok to ignore events
  • Data services
  • dead reckoning services, geography and
    line-of-site services
  • Variable aggregation
  • treat collection of simulated entities as unit
    sometimes
  • Encapsulation
  • view an entire federation as a single federate in
    a larger simulation

32
Key Issues (continued)
  • Ownership transfer
  • per attribute
  • dynamic -- and sometimes forced
  • Start-up, pausing, take-down
  • distributed agreement
  • Data collection facilities
  • for post mortem analysis
  • Exceptions
  • what to do when a simulation does not behave as
    expected
  • Comprehensibility of documentation
  • specification partitioned into management groups
  • interactions between groups problematic
  • Conformance testability
  • how to certify that a simulation or RTI is
    compliant with standard

33
Some Observations
  • The connectors are where most of the interesting
    action is
  • getting these right is critical to success
  • An API is a key ingredient to make a standard a
    reality, but its not enough by itself
  • must also understand timing, protocols, etc.
  • The basic form of interaction is only a small
    part of the architecture
  • management of the parts, handling errors,
    pause-resume, negotiation about shared data,
    performance-enhancing features
  • Conformance testing becomes a serious issue
  • both for parts providers and for infrastructure
    providers

34
Pause on Join
Federate
Federate
(1) joinFedExecution (2) requestPause (3)
schedulePause (4) pauseAchieved
(5) joinFedExecution (6) requestPause
RTI
35
Problem!
Federate
Federate
(1) joinFedExecution (2) requestPause (3)
schedulePause (4) pauseAchieved (7)
schedulePause
(5) joinFedExecution (6) requestPause
RTI
36
Key Issues
  • An architectural design must bridge the gap
    between requirements and implementations
  • Todays lectures focus on three relationships
  • between requirements and architecture
  • between architecture and implementations
  • between alternative architectures

37
From Requirements to Architectures
  • The problem develop an architecture for a system
    or product family that satisfies critical system
    requirements
  • Impediments
  • Requirements specification is not a mature
    discipline
  • Requirements may change frequently
  • Requirements may not be fully known independently
    of a solution
  • The need to develop a product line changes
    requires new processes for relating requirements
    and architectures
  • Caveats
  • This is an area of active research and change
  • What we know represents only a partial solution
  • Your mileage may vary

38
Techniques
  • 1. Architectural Design Reviews
  • bring stakeholders together to determine
    feasibility of an architectural design to solve a
    particular problem
  • 2. Product-line Engineering/Commonality Analysis
  • identify common requirements of a group of
    products
  • 3. Rules-of-thumb and Automated Design Guidance
  • codify criteria and guidance for choosing
    appropriate architectural designs
  • 4. Problem Frames
  • identify recurring structures of problems that
    lend themselves to methodological solutions
  • 5. Architecture-based Analysis
  • use analytic techniques to decide whether an
    architectural design will lead to a system that
    meets its requirements

39
Part 3Architectural Design Reviews
  • Complement normal design review process
  • Prescribe guidelines for architectural
    description and rationale
  • Define a process of formal airing of architecture
    that leads to list of issues that must be
    resolved
  • May be done using corporate design review
    boards or by a product group itself
  • Can be used to produce corporate architectural
    assets
  • Checklists of issues that an architecture must
    consider
  • Standard solutions to common domain-specific
    problems
  • Case studies and examples
  • Measurement of costs/benefits

40
Architectural Design ReviewsThe ATT Experience
  • Design Reviews at ATT
  • Architecture Review Board (ARB) created 1988
  • Facilitates reviews for projects
  • Process consists of two reviews
  • Approximate costs 70 staff-days (distributed
    across about 15 people)
  • Results
  • Reviewed over 350 projects voluntary
    participation
  • A correct architecture has the largest single
    impact on cost and quality of the product
    (Maranzano 1995)
  • Based on experience we found an average
    savings of at least one-half staff year per
    project reviewed, and substantially larger
    savings on several projects reviewed
  • Residual effect on product quality through
    checklists

41
Architectural Design Reviews at ATT
42
Architectural Design Reviews at ATTKey Insights
  • Different logical times that a design review can
    happen -- with different cost/benefits
  • discovery versus sign-off reviews
  • Requirements/Architecture/Implementation evolve
    in parallel
  • waterfall model does not usually apply
  • Checklists encode design knowledge
  • often domain-specific
  • record of past gottchas
  • Benefit from organizational infrastructure
  • transfer of expertise between projects
  • calibration of effort/documentation/results

43
Excerpt from ATTArchitectural Review Board
Checklists
44
Highlights of the ATT Process
  • ARB appoints a review team of experts
  • voluntary participation, encouraged by corp
    management
  • Project team provides architecture documents to
    ARB team 2 weeks before scheduled review
  • documentation follows standard (but not rigid)
    format
  • ARB generates a list of questions and concerns
    several days before the review
  • ARB and members of project meet for 2 days
  • ARB documents preliminary findings for the
    project
  • Project team develops action plan based on
    findings
  • Project team and ARB team present the evaluation
    and action plan to project management and ARB
    directors

45
Technical Drivers
  • Simplicity of architecture
  • uniformity, use of standards, shared
    infrastructure
  • Central role for error handling
  • should be an arch driver, not an afterthought
  • Operations, Administration, and Management (OAM)
  • often determines feasibility of architecture
  • Performance handled systematically, but at high
    level
  • process boundaries made explicit in design
  • use back-of-envelope calculations to determine
    throughputs, bottlenecks, points of failure
  • allocate resource budgets to components
  • Monitoring capabilities
  • to permit visibility into running system

46
Limitations of the ATT Approach
  • Focused on architectures for individual systems
    -- not product lines
  • commonalities between projects captured in
    checklists
  • some concern for reuse and standards, but not
    built in to process
  • Savings estimates deal only with development
    costs no estimate of savings after deployment,
    such as
  • reduced costs for maintenance and evolution
  • reduced costs for downstream projects
  • improved system quality
  • Not a significant change in corporate processes
  • merely complements existing review processes
  • does not change the fundamental economics of
    product development
  • no uniform architectural representation standards

47
Part 4Evaluating an Architectural Design
  • Determining whether an architecture satisfies its
    requirements often involves
  • Being very explicit about what the requirements
    really are
  • Understanding where one has to make tradeoffs
    between different designs
  • Applying formal analysis where possible to
    determine the consequences of an architectural
    choice
  • Mediating between desires of different
    stakeholders
  • These goals can be achieved by an architectural
    evaluation process
  • We will look at an example of one such process
    ATAM

48
The ATAM Process
  • 1) Collect system usage scenarios from various
    stakeholders
  • 2) Collect requirements/constraints/environment
  • These are the requirements for which analyses
    will be performed
  • 3) Describe architectural designs
  • Describe multiple, competing architectural
    options
  • 4) Perform attribute-specific analyses
  • Analyze properties of each architecture option in
    isolation
  • 5) Identify sensitivities
  • Determine the sensitivity of the various
    attributes to the available architectural design
    options
  • 6) Identify tradeoffs
  • Determine which architectural elements are
    sensitive to multiple attributes (e.g. of
    servers affects both the cost of the system and
    its overall reliability)
  • 7) Repeat

49
ATAM
PHASE IV Tradeoffs
PHASE I Scenario Requirements Gathering
IdentifyTradeoffs
Collect Scenarios
Collect Requirements, Constraints, Environment
Identify Sensitivities
DescribeArchitectural Views
Attribute Specific Analyses
Realize Scenarios
PHASE II Architectural Views Scenario
Realization
PHASE III Model Building Analyses
50
Case Study
  • A Remote Temperature Sensor system
  • measure the temperatures of a set of furnaces
  • report temperatures to an operator
  • operator can change the furnace temperatures
    settings, reporting rate (10-99 secs.)
  • We want to design the system and understand its
    performance, security, reliability, cost, . . .

51
Functional View of System
Furnace Server
Operator 1
Operator 2
ADC
Comm
Operator n-1
Operator n
52
Performance Scenarios
  • The performance requirements and analysis are
    guided by two scenarios
  • An operator sends a control request and receives
    the first periodic update.
  • An operator receives periodic updates at a
    specified rate.
  • Performance Requirements
  • PR1 Operator must receive the first temperature
    reading within F seconds of sending a request.
  • PR2 Given that Operator C has requested a
    periodic update every T(i) seconds, it must
    receive a temperature on the average every T(i)
    seconds.
  • PR3 The interval between receipt of consecutive
    periodic updates must be not more than 2T(i)
    seconds

53
Availability Scenarios
  • The availability requirements and analysis are
    guided by two scenarios
  • A server suffers a software failure and is
    rebooted.
  • A server suffers a power supply failure and is
    replaced.
  • Availability requirements
  • AR1 Server must not be unavailable for more than
    60 minutes per year.

54
Security Scenarios
  • The security requirements and analysis are guided
    by two scenarios
  • A threat object between the server and operators
    modifies temperatures received by the operators.
  • A server is spoofed to misrepresent temperatures
    received by the operators.
  • Security Requirements
  • SR1 lt 0.001 probability of temperature readings
    corrupted before they arrive at the operator.

55
Option 1 Client-Server
Furnace Client 1
RTS Server
Furnace Client 2
Furnace Client n-1
Furnace Client n
All furnace tasks share the ADC and Comm
56
Option 2 Client-Server-Server
Furnace Server 1
Furnace Client 1
Furnace Client 2
Furnace Server 2
Furnace Client n-1
Furnace Client n
Each server has its own ADC and Comm. Each server
services 1/2 the furnaces and acts as backup
for the other 1/2.
57
Option 3 Client-Intelligent Cache Server
Furnace Client 1
RTS Server
Furnace Client 2
Furnace Client n-1
Furnace Client n
Intelligent cache is a wrapper for the
clients stores updates and extrapolates into
the future. Extrapolated values less meaningful
over time.
58
Performance Assumptions
  • To do analysis, assumptions must be made, e.g.
  • Relatively infrequent control requests
  • Requests are not dropped
  • No message priorities
  • Network communication time between client and
    server (C_net 1200 ms)
  • Server latency furnace task computation (C_fnc
    120 ms)

59
Performance Analysis
Option 1
Option 2
Option 3
60
Availability Assumptions
  • For each option we posit a set of failure rates
    and repair rates
  • server failure rates from 0 per year to 24 per
    year
  • repair rates 1/2 day (service call), 10 minutes
    (reboot)
  • N.B. We only consider server reliability

61
Availability Analysis of Option 1 Markov Model
  • s

S
F
  • s

62
Availability of Option 1
1/2 Day Repair
Failures/year
Availability
Hours down/year
8
0.98916
94.959
16
0.97855
187.882
24
0.96817
278.833
10 Minute Repair
Failures/year
Availability
Hours down/year
8
0.99985
1.33313
16
0.9997
2.66586
24
0.99954
3.9982
63
Availability Analysis of Option 2 Markov Model
  • s

F
S
S-S
  • s
  • s

64
Availability of Option 2
65
Availability Analysis of Option 3 Markov Model
  • c
  • s

F
C
S-C
  • s
  • s

66
Availability of Option 3 (1 Min Cache)
67
Availability of Option 3 (5 Min Cache)
68
Initial Results
  • Option 1 poor performance and availability
    least expensive
  • Option 2 excellent availability, at extra cost
    excellent performance (both servers running)
    performance of Option 1 otherwise.
  • Option 3 slightly better availability than
    Option 1 better performance than Option 1
    (jitter can be bounded), slightly greater cost
    than Option 1 lower cost than Option 2.

69
Sensitivity Analysis
  • What is the sensitivity of attributes to various
    architectural parameters.
  • e.g. Given that Option 3 has some desirable
    characteristics, we might ask if we can improve
    availability by improving the cache.
  • To answer this, we calculate the architectural
    sensitivity of availability to cache life.

70
Sensitivity Analysis -2
This shows that availability is relatively
insensitive to cache life
71
Sensitivity Analysis -3
  • What is the sensitivity of the architecture to
    of servers?
  • Performance
  • Availability
  • Availability and performance are sensitive to the
    of servers.

72
Interim Summary
  • Option 2 has a lower level of service when one
    server fails.
  • No design completely meets its requirements.
  • Increasing the of servers from 1 to 2 helps,
    but at a high cost.

73
Benefits
  • Clarifies quality attribute requirements
  • through prioritization and estimation
  • Improves documentation
  • through explicit enumeration of evaluation
    criteria, rankings, and rationale for decisions
  • Identifies risk areas
  • points of sensitivity, instability
  • Improves communication
  • highlights were stakeholders differ about
    relative priorities
  • causes stakeholders to come to some consensus

74
Observations
  • Inexpensive way to find problems
  • compared with patch and pray
  • typical analyses take 3 days
  • may be done early in life cycle
  • Goal is to
  • make informed design choices, informed tradeoffs
  • analyze systems with respect to multiple
    attributes at the level of their architecture
  • Numbers are approximate
  • Initially the numbers are ballpark estimates.
  • Variable resolution analysis--probe deeper when
    needed through benchmarking, prototyping
  • Numbers get refined over time but the analytic
    framework persists.
About PowerShow.com