Software%20Architecture%20

1
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

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

3
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

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

5
Early Design Decisions - continued

• Inhabits a systems 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

6
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 products life cycle
• The system is executable early on
• Helps to reduce potential risk in the project
  early on

7
Elements of Good Architecture

• Manage change and complexity
• Adapt to system extensions
• Minimize interdependencies among complex modules
• Allow reasonable cost estimation

8
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

9
Coupling of Architectural Design and
Implementation
10
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?

11
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

12
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 customers high-level
  description of property to specifications that
  can be mapped to code?
• Can we support hard real-time Quality of Service?

13
Less Control In Development

• Buying means less control on every aspect of a
  systems 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 dont
  compromise the architecture and the qualities it
  helps to manifest

14
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 dont 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

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

16
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 youve detected by adapting
  the components

17
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
  components interface
• CORBA IDL can be used to specify the new interface

18
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

19
Techniques to Avoid Interface Mismatch

• Disciplined approach to specifying as many
  assumptions about a components interface as is
  feasible
• Assertions about the sufficiency of services
• Assumptions about environment behavior
• Assertions about implementability or resource
  requirements

20
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.
• Whats next?

21
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

22
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?

23
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 systems
  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

24
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

25
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

26
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