Transcript What is Software Architecture Important

Software Architecture and CBSE
CEN6502, Spring 1998, (c) Yi Deng
1
Software Architecture
The software architecture of a program or system is the
structure or structures of the system, which comprise
software components, the externally visible properties of
these components, and the relationships among them.
CEN6502, Spring 1998, (c) Yi Deng
2
Where Do Architectures Come From
• Architectures are influenced by system stakeholders (fig.1.2)
• Influenced by technical and organizational factors
– Customers and end users (cost, performance, platform
compatibility, security, modifiability, interoperability with other
systems, etc.)
– Developing organization. (immediate business, long term business,
and organizational structure.)
– Background and experience of the architects.
– Technical environment (industry standard practices, prevalent SE
techniques at the time of development.)
• Architecture issues are orthogonal to system functionality or functional
requirements.
CEN6502, Spring 1998, (c) Yi Deng
3
Architecture Business Cycle
•
•
•
•
Organizational goals influence requirements
Requirements lead to an architecture
Architecture yield systems
Systems suggest future new organizational capabilities and
requirements.
CEN6502, Spring 1998, (c) Yi Deng
4
The Feedback Cycle
• Architecture can affect the structure and enterprise goals of
the developing organization.
• Can affect the customer requirements for the next system
• Will affect the architects’ experience and perception
• Some systems will influence and actually change the SE
culture and practice, e.g. CORBA, Java, WWW
CEN6502, Spring 1998, (c) Yi Deng
5
What Is and Is Not Software Architecture
• Typical, but uninformative, presentation of a top-level
architecture (fig. 2.1.)
• Information not conveyed by the structure:
– The nature of the components
– Significance of the links
– Significance of the layout
– How does the architecture operate at runtime.
CEN6502, Spring 1998, (c) Yi Deng
6
Software Architecture
The software architecture of a program or system is the
structure or structures of the system, which comprise
software components, the externally visible properties of
these components, and the relationships among them.
CEN6502, Spring 1998, (c) Yi Deng
7
What an Architecture Should Convey
• Architecture defines components
• Systems can comprise more than one structure and no one
structure is the architecture
• The behavior of each component is part of the architecture
CEN6502, Spring 1998, (c) Yi Deng
8
Styles, Reference Models and Reference
Architectures
• An architecture style is a description of component types and a pattern
of their runtime control and/or data structure, a set of constraints on an
architecture. E.g. client-server
• A reference model is a division of functionality together with data flow
between components, a standard decomposition of a known problem
into parts that cooperatively solve the problem
• A reference architecture is a reference model mapped onto software
components (that will cooperatively implement the functionality
defined in the reference model) and data flows between the
components
• (Reference Model + Architectural Style)  Reference
Architecture  Software Architecture  System
Architecture
CEN6502, Spring 1998, (c) Yi Deng
9
Why is Software Architecture Important
• Communication among stakeholders
– Represents common high-level abstraction of a system
• Early design decisions
– Earliest point at which the system to be built can be
analyzed
– Carry weight that is essential to the cost and success of
project
• Transferable abstraction of a system
– Key to extension, migration and evolution
– Basis for large-scale reuse
CEN6502, Spring 1998, (c) Yi Deng
10
Architecture Manifests Early Design Decisions
• Defines constraints on an implementation
– Implementation must be divided into prescribed components,
which interact with each other in the prescribed fashion, and each
component must fulfill its responsibility to the other components
as dictated by the architecture
• Dictates organizational structure
– As the basis for work-breakdown structure
– WBS in turn dictates unit planning, budget, scheduling, inter-team
comm channels, configuration control, integration/testing
procedures, etc.
CEN6502, Spring 1998, (c) Yi Deng
11
Early Design Decisions
• Inhabits a system’s quality attributes
– For large systems, quality attributes are increasingly
satisfied in system structure and division of
functionality, rather than in its algorithms and data
structures
– E.g., modifiability depends heavily on modularization,
performance on volume and nature of communication
between components, reusability on nature of coupling
– Architecture alone cannot guarantee the functionality
and quality required of the system
CEN6502, Spring 1998, (c) Yi Deng
12
Early Design Decisions
• Predicting system qualities by studying its architecture
• Makes it easier to reason about and manage change
• Helps in evolutionary prototyping
– Potential performance problems can be identified early
in the product’s life cycle
– The system is executable early on
– Helps to reduce potential risk in the project early on
CEN6502, Spring 1998, (c) Yi Deng
13
Architecture as a Transferable, reusable model
• Product lines share a common architecture -- domain specific software
architecture
• Systems can be built by using large, externally developed components
– Focussing on composing or assembling components, as opposed to
programming
• Not in mature stage of practice, problem of architectural mismatch
• Make explicit of architectural context, build wrappers to bridge the gap
• Less is more: it pays to restrict the vocabulary of design alternatives
CEN6502, Spring 1998, (c) Yi Deng
14
Architectural Structures
• Table 2.1., p38.
CEN6502, Spring 1998, (c) Yi Deng
15
Air Traffic Control - A Case Study
•
•
•
•
Purpose: to get a sense of what’s involved in architectural level design
Among the most demanding of all software applications
Hard real-time: timing deadlines must be met absolutely
Safety-critical: human life is at stake if the system does not perform
correctly
• Highly distributed: requiring dozens of controllers to work together to
guide aircraft through the airways system
• ATC is a multibillion-dollar undertaking
CEN6502, Spring 1998, (c) Yi Deng
16
ATC
• Controlled by FAA
• Typical flight process (fig. 11.1,2)
– Ground control coordinates the movement of aircraft on
the ground at an airport
– Towers control aircraft flying within an airport’s
terminal control area
– En route centers divide the skies over the country into
22 large sections of responsibilities
CEN6502, Spring 1998, (c) Yi Deng
17
Initial Sector Suite System (ISSS)
• Intended to be an upgraded hardware/software system for
the 22 en route centers
• One part of a planned, much larger, government
procurement for next generation ATC system for US
(AAS)
• This fact has profound impact on its architecture - great
incentive to adopt common designs and components where
possible, e.g. interfaces to radio systems, to flight plan
DBs, to each other, interpreting radar data, requirements
for reliability and performance, etc.
CEN6502, Spring 1998, (c) Yi Deng
18
Sense of Scale
• Support up to 210 consoles per en route center. Each
console contains a workstation-class processor (IBM
RS/6000)
• Each center controls 400-2440 separate aircraft tracks
simultaneously
• 16-40 radars to support a single facility
• A center can have 60-90 control positions each with one or
several devoted consoles.
CEN6502, Spring 1998, (c) Yi Deng
19
Requirements and Qualities
• Ultrahigh availability: system is absolutely prohibited from being
inoperative for longer than very short periods of time (99.999%)
• High performance: system has to be able to process large number of
aircraft without “losing” any of them
• Openness - can be integrated with other (software/hardware) systems
• Ability to field subsets of the system in case of budget cut
• Ability to make changes to functionality and handle upgrades
• Ability to operate with and interface to a bewildering set of external
systems, some decades old and others not yet implemented
• Must satisfy a great number of stakeholders, particularly the
controllers
CEN6502, Spring 1998, (c) Yi Deng
20
Requirements
• Acquire radar target reports that are stored in an existing ATC system
(HCS)
• Convert the radar reports for display and broadcast to all consoles
• Handle conflicting alerts or other data transmitted by HCS
• Interface to HCS for input and retrieval of flight plans
• Provide extensive monitoring and control information, e.g. network
management, to allow site administrators to reconfigure the installation
in realtime.
• Providing recording capability to later playback
• Providing general GUO facilities
• Provide reduced backup capability in the event of HCS, primary
networks or primary radar sensors failures
CEN6502, Spring 1998, (c) Yi Deng
21
Architectural Approach
• Distributed multiprocessor systems, and a front-end effort for
schedulability analysis
• Message-based systems serving as a unifying paradigm under which
each unit can determine its processing requirements based on set of
messages it is allowed to receive
• Client-server architectures meant to promote modularity, strong
cohesion and loose coupling
• Built-in redundancy. Both software and hardware
• Table-driven start-up configuration providing the capability to
configure the ISSS for different sites without changing the code.
• Patterns of software to promote reuse, to minimize necessary creativity
and to improve maintainability and easier extension
CEN6502, Spring 1998, (c) Yi Deng
22
ISSS System Architecture
•
•
•
•
•
•
•
•
Fig. 11.5.
HCS heart of the en route automation system. Two host computers with
primary/backup setup.
Common consoles are controllers’ workstations
Connected via LCN - four parallel token rings connected by bridges for
redundancy and to balance load
The Enhanced Direct Access Radar Channel (EDARC) provides backup
display of aircraft position and limited flight data (raw radar data)
Backup Comm Network (BCN) - Ethernet using TCP/IP, used for other
functions besides EDARC, and backup for LCN
Both LCN and BCN have associated Monitor & Control (M&C) consoles
for monitoring and maintenance
Test and Training subsystem for testing new hardware/software and for
training personnel without interfering with ATC mission
CEN6502, Spring 1998, (c) Yi Deng
23
ISSS Software Architecture
• Architecture affects behavior, performance, fault-tolerance,
and maintainability
• Architecture is shaped by stringent requirements in any of
these areas
• Dominant factor: ultrahigh system availability requirement
• Two classes of software:
– Operational software facilitates ATC
– Support software helps to generate, develop, install and initialize
operational software
– Roughly same size
CEN6502, Spring 1998, (c) Yi Deng
24
ISSS Components
• Computer Software configuration items (CSCI), defined by
government software development standard, largest components,
primarily for work assignments
– Display management (350K lines)
– Common system services (345K), general utilities
– Recording, analysis and playback (31K) for capturing ATC
sessions for later analysis
– National Airspace System Modification entailing a modification of
software resides on HCS
– The IBM AIX OS
CEN6502, Spring 1998, (c) Yi Deng
25
ISSS Components
• Applications. Each corresponds to a process in the sense of Dijkstra’s
CSP, and is at the core of the approach the ISSS designers adopted for
fault tolerance. (fig.11.6)
– ISSS constructed to operate on a process group
– Each process group hosts a separate copy of one or more
applications, one executing copy is primary (primary address
space(PAS)), the others are secondary (standby address
space(SAS)), together called an operational unit
– Functional group (FG) non-fault-tolerant applications, run
independently on different processors
• Applications interact with each other in a client-server fashion
• Switch over between PAS and SAS
CEN6502, Spring 1998, (c) Yi Deng
26
ISSS Components
• Programming Language Entities
– Applications (operational units and functional groups) are
decomposed into Ada packages.
– Packaging is a design activity intended to embody abstraction and
information hiding, and carried out by an operational unit’s chief
designer
• Threads
– Consists of software, executing as one or more CSP, that fulfills a
logically related piece of functionality
– Form the basis for test plan, and in fact formed the basis for
defining major deliverable versions of ISSS software
CEN6502, Spring 1998, (c) Yi Deng
27
ISSS Connections
• Message based
• Almost no Ada rendezvous or other synchronization operations for
meeting hard deadlines
• Fig. 11.8
CEN6502, Spring 1998, (c) Yi Deng
28
ISSS As A Layered Architecture
• Fig. 11.10
CEN6502, Spring 1998, (c) Yi Deng
29
Fault Tolerance
• Cold restart of the system is out of question
• Immediate switch-over seemed best approach
• Fault tolerant hierarchy architecture (Fig. 11.11) - describes how faults
are detected and isolated and how the system recovers
• PAS/SAS scheme traps and recovers errors in a single application
• Fault tolerant hierarchy traps and recovers from cross application
errors
• Each level is meant to produce another increment in system
availability above that produced by lower levels. Each level
asynchronously
– Detects errors in self, peers, lower levels
– Handles exceptions from lower levels
– Diagnoses, recovers, reports and raises exceptions
CEN6502, Spring 1998, (c) Yi Deng
30
Fault Tolerance
• FT Levels
– Physical (network, processor, and I/O devices
– OS
– Runtime environment
– Application
– Local Availability
– Group Availability
– Global Availability
– System monitor and control
CEN6502, Spring 1998, (c) Yi Deng
31
Fault Tolerance
• At each level
– Fault detection (and isolation) is performed by built in tests, event
timeouts, network circuit tests, group membership protocol, and as
a last resort, human reaction to alarms and indicators
– Fault recovery is performed, and can be manual or automatic. For
local, group, and global availability managers, the recovery
methods are table-driven
– Four types of recovery:
• In a switchover, the SAS takes over almost immediately from
its PAS
• A warm restart uses checkpoint data
• A cold restart uses default data and loses state history
• A cutover is used to transition to new (or old) logic or
adaptation data
CEN6502, Spring 1998, (c) Yi Deng
32
Exploiting Patterns in Software Architecture
• A pattern is a small collection of atomic units and a description of their
relationships
• In OO design, a pattern is a collection of object classes and the
inheritance and uses relationship among them
• A pattern addresses a recurring design problem that arises in specific
design situations, and presents a solution to it.
• Patterns document existing, well-proven design experience
• Patterns allow us to understand complex systems in larger conceptual
chunks
• E.x. Windows GUI, and more generally Model-View-Controller
pattern of GUI design (p.5Buschmann).
CEN6502, Spring 1998, (c) Yi Deng
33
What Makes A Pattern
• Context - specification of situations in which the problem occurs.
Critical to the usability of patterns
• Problem - describe the problem that arises repeatedly in the given
context
– Requirements the solution must fulfill, e.g. that peer-to-peer IPC
must be efficient to certain extent
– Constraints you must consider, e.g. IPC must follow certain
protocol
– Desired properties that the solution should have, e.g. support
extensibility
CEN6502, Spring 1998, (c) Yi Deng
34
What Makes A Pattern (cont’d)
• Solution - shows how to solve the recurring problem, or better, how to
balance the forces associated with it.
– Pattern structure, a spatial configuration of elements, stress static
aspects of the solution
– Runtime behavior, addresses dynamic aspects of the solution.
– E.g. Model-View-Controller patterns includes the following
statement: “Controllers receives input, usually as events that
denote mouse movement, activation of mouse buttons, or keyboard
input. Events are translated to service requests, which are sent
either to the model or to the view”.
CEN6502, Spring 1998, (c) Yi Deng
35
Component-Based Development and Architecture
•
•
•
Develop systems from existing components
Buy, don’t build. Shift emphasis from programming software to composing
software systems
Benefits
– Being able to take faster advantage of new products and new technology
– Significantly reduced time-to-market because of off-the-shelf components
are ready to use
– Higher employee productivity, with emphasis not on coding but on
reusing and integrating
– More reliable components because the components more likely be used,
tested and validated in multiple systems
– More changeable and extensible systems because more attention will be
paid on component interface and independence, and system architecture
– More benefits will be yielded if the components conform to community
wide standards
CEN6502, Spring 1998, (c) Yi Deng
36
Issues in CBSD
• Increasing component size and complexity. Wide range of COTS
components available: OS, DBMS, network managers, CASE tools,
ORBs, or domain specific middlewares.
• “Buying” means less control on every aspect of a system’s
development.
• How can this loss of control be reconciled with our desire for quality?
– Part of answer lies in the assertion that, for larger systems, quality
lives primarily in the architecture
– The other part of answer: One must take care to integrate
components so that they don’t compromise the architecture and the
qualities it helps to manifest
CEN6502, Spring 1998, (c) Yi Deng
37
Issues in CBSD
• Architecture Mismatch, a special case of interface mismatch. Not all
components work together - even if they claim to
– Components are often “almost” compatible, where “almost” is a
euphemism for not
– More insidious: components appear to work together - the
assembled code compiles and even executes - but the system
produces the wrong answer because the components don’t work
together as expected
– Components that were not developed specifically for your system
may not meet all of your requirements
– Worse, you may not know if they are suitable or not until your buy
them and try them, because component interfaces are notoriously
poor at specifying their quality attributes
CEN6502, Spring 1998, (c) Yi Deng
38
Issues in CBSD
• Interface - assumptions that the components can make about each other
• Interface = Provides + Requires (+ side affects) , or Syntax +
Semantics
• Unfortunately, this definition goes beyond what has become the
normal concept of interface in current practice.
• What can you do?
– Avoid it by carefully specifying and inspecting the components for
your system
– Detect those cases you have not avoided by carefully qualification
of the components
– Repair those cases you’ve detected by adapting the components
CEN6502, Spring 1998, (c) Yi Deng
39
Techniques for Repairing Interface Mismatch
• Change the code: often not possible and desirable
• Wrappers.
– A form of encapsulation whereby some component is encased
within an alternative abstraction
– Clients access wrapped component services only through an
alternative interface provided by the wrapper
– Interface translation include:
• Translating an element of a component interface into an
alternative element
• Hiding an element of a component interface
• Preserving without change of an element of a component’s
interface
– CORBA IDL can be used to specify the new interface
CEN6502, Spring 1998, (c) Yi Deng
40
Techniques for Repairing Interface Mismatch
• Bridges
– Will translate between some requires assumptions of an arbitrary
component to some provides assumptions of some other arbitrary
component
– Key difference with wrapper: the repair code is independent of any
particular component, must be explicitly invoked by some external
agent, and is typically a transient process
– Typically focus on narrower range of translation than wrappers do
– E.g. bridge from postscript generator to PDF display
CEN6502, Spring 1998, (c) Yi Deng
41
Techniques to Avoid Interface Mismatch
• Disciplined approach to specifying as many assumptions
about a component’s interface as is feasible
• Assertions about the sufficiency of services
• Assumptions about environment behavior
• Assertions about implementability or resource
requirements
CEN6502, Spring 1998, (c) Yi Deng
42