Transcript Software Architecture – An Overview

Software Architecture – An Overview
• The software architecture of a system is the
composition of software components, the structures
that interconnect them, and the rules by which they
interact and integrate
• Software architecture as a style and method of
design or strategic policies and patterns that shape a
system
• Separation of architecture from application design
Where Do Architectures Come From?
• Architectures are influenced by system stakeholders
• 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.
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
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
communication channels, configuration control, integration/testing
procedures, etc.
Early Design Decisions - continued
• 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
Early Design Decisions - continued
• 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
Elements of Good Architecture
• Manage change and complexity
• Adapt to system extensions
• Minimize interdependencies among complex
modules
• Allow reasonable cost estimation
CORBA Architectural Advantage
•
•
Set clear distinction and coupling between enterprise architecture and
application design (next slide)
Helps to separate application software from the underlying
infrastructure
– Location transparency
– Dynamic binding
– Abstraction of distributed computing environment
•
•
Separates interface from implementation, which allows architecture to
be defined independent of how it is implemented
Together, the above allow developers to focus on architecture and
business logic, and maintain separation of concerns
Coupling of Architectural Design and
Implementation
Still A Long Way To Go …
• Current middleware products are becoming too huge, monolithic
systems that are themselves almost the antithesis of a
component-based system
• To date, ORB implementations are not robust and performance
is poor above 10K objects
• When middleware products have a lifecycle of 6 months to a few
years, how does one build applications with fifteen year
lifecycle? How do you even migrate an application to new
releases of the same middleware product?
More Roadblocks
• Service as components? Cross vendor portability and cross
ORB service are not solved
• System developers and runtime administrators find it very
difficult to resolve faults that originate with “black-box”
components.
• How to ensure system-wide reliability, performance, security, etc
beyond single vendor ORB
Software Architecture and Composition
• CORBA only addresses components, but does not have a
standard way to specify connections, constraints, or patterns of
interactions
• How to insert system-wide non-functional properties into
component software architecture
• How do we go from the customer’s high-level description of
property to specifications that can be mapped to code?
• Can we support hard real-time Quality of Service?
Less Control In Development
• “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
Architecture Mismatch
• Not all components work together - even if they claim to
– Components are often “almost” compatible, where “almost” is a
euphemism for not
– 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
What Should Be In Interface
• 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 About Interface Mismatch
• 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
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
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
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
Software Architecture in the Future
•
•
•
•
•
1960s. Assembly languages, subroutines, semicolon as connectors
1970s. Structuring of programs to achieve qualities beyond correct
function. Data flow analysis, ER diagrams, info hiding. Modules as
building blocks
1980s. Module-based languages, information hiding, and associated
methodologies crystallized into concept of objects.
1990s. Object matures. Standard object-based architectures in terms of
frameworks. Give standard vocabulary for components leading to new
infrastructures, e.g. CORBA. Interchangeable components based on
OLE.
What’s next?
Architecture and Legacy Systems
• Goal. Making intelligent changes to a system in which an
organization has a large investment
– Determining the existing architecture of a legacy system
– Determine the goal state of a re-engineered architecture
– Developing a strategy to migrate the system to the new architecture
• Migration may involves
– re-engineering of parts of the system
– wrapping of existing parts to work within a new infrastructure
– completely replacing the existing system
Architecture Archaeology and
Conformance
• Many systems have no documented architecture at all
• Architecture is represented in such a way that the relationship
between the documentation and the actual system, particularly
its source code, is unclear
• Architectural representations are frequently out of phase with
the actual system due to maintenance of the system without a
similar effort to maintain the architectural representation
• Serious problem in assessing architectural conformance - how
do we what was designed is what was built?
Architectural Conformance Problem
•
•
•
•
Maintenance activities may alter architecture
How do we know maintenance operations are not eroding the
architecture, breaking down abstractions, bridging layers,
compromising information hiding, and so forth?
Underlying causes:
– System has too many runtime relationships (data flow, control flow,
code structure, etc) need to be maintained
– Architecture represented in a system’s documentation may not
coincide with any of these structures. It frequently describes some
ad hoc combination of runtime structures
Tools for architectural extraction and conformance
Achieving an Architecture
• Plan for quality attributes
• Having meaningful and quantifiable definitions of various
qualities
• Creating or selecting an architecture based on a set of
functional and quality requirements
• Understanding and measuring tradeoffs involved in any
architectural decision
Understanding Quality Attributes
• What does “modifiability” mean?
• Fundamental problem is lack of suitable models for discussing
them.
• Exception: performance can be discussed, analyzed and
measured based on resource availability and resource
consumption
Creating and Selecting an Architecture
• Major research area: quantitative architecture evaluation
• Understanding relationship between requirements and
architecture - how a system is “driven” into a certain
architectural style family.
• Expected results:
– Taxonomy of systems’ problem spaces
– Taxonomy of systems’ context spaces
– Taxonomy of systems’ solution spaces