Introduction to Software Architecture

1
Introduction to Software Architecture
CS750 ????? ?? ?? CBSE

• 1999. Mar. 17th
• presented by Chung In Bok

2
History of research issues

• 1960s
• problem of developing large-scale software
  systems
• 1970s
• software design
• activity separate from implementation
• 1980s
• integrating designs and design process into the
  broader context of the software process and its
  management
• advances in ability to describe and analyze
  software systems ( formal descriptive techniques,
  type conformance ..)
• 1990s
• decade of software architecture

3
Origins of Software Architecture Study

• Brooks The conceptual structure
• in 1969
• conceptual structure of a computer .. As seen by
  the programmer
• where architecture tells what happens,
  implementation tells how it is made to happen
• Dijkstra and Parnas Structure matters
• Dijkistra
• in 1968
• in large part a study of software structure
• how software is partitioned and structured
• Parnas
• information-hiding modules (1972)
• software structures(1974)
• program families (1975)
• structure is important, and getting the structure
  right carries benefits

4
What are software architectures? (1/2)

• No standard, universally-accepted definition of
  the term

.. bridging the gap between requirements and
implementations (David Garlan Dewane Perry)
The structure of the components of a program
/system, their interrelationships, and principles
and guidelines governing their design and
devolution over time (SEI software architecture
discussion group)
5
What are software architectures?(2/2)

• In general, software architecture defines that
  system in terms of computational components and
  interactions among those components
• Specify the structure and topology of the system
  and show the correspondence btw. the system
  requirements and elements of the constructed
  system gt provide some rationale for the design
  decision
• Other definitions
• http//www.sei.cmu.edu/architecture/definitions.ht
  ml

6
General properties in Software Architecture

• Focus of concern
• organization of a large system (architectural
  concern)
• gross organization and global control structure
• synchronization, protocol, data access,
  assignment of functionality to design elements
• Nature of representation
• graphs of interacting components
• modularize a system as a graph of components and
  connector
• Design methods vs. architectures

requirements
requirements
methods
SW architecture
implementations
implementations
7
OO design vs. SW architecture(1/2)
(Design pattern vs. SW architecture Style)

• It is difficult to specify and enforce constraint
  generally and explicitly using standard OO design
  notations
• There is a significant limitation to OO design
• SW architecture concepts allow an architect to
  describe and encapsulate complex protocols of
  component interaction
• e.g ) simple pipe-and filter architecture

8
OO design vs. SW architecture(2/2)
9
Benefits of SW architecture(1/2)

• Understanding
• by presenting systems at a level of abstraction
  at which high-level design
• simplifies our ability to comprehend large
  systems
• Reuse
• reuse of large components
• reuse of frameworks into which components can be
  integrated
• domain-specific software architecture, design
  pattern
• Evolution
• system maintainers can better understand the
  ramifications of change, and thereby more
  accurately estimate the costs of modification

10
Benefits of SW architecture(2/2)

• Analysis
• provide new opportunities for analysis
• high-level forms of system consistency checking
• conformance to an architectural style
• domain-specific analyses for architectures that
  conform to specific styles
• dependency among the components

11
Architectural Style (1/6)

• Defines
• a family of systems in terms of a pattern of
  structural organization
• a vocabulary of components and connector type
• a set of constraints on how they can be combined
• Expose the issues that are most important and
  help the developer make effective choices and
  locate the best solution more easily

12
Architectural Style (1/7)

• Defines
• a family of systems in terms of a pattern of
  structural organization
• a vocabulary of components and connector type
• a set of constraints on how they can be combined
• Expose the issues that are most important and
  help the developer make effective choices and
  locate the best solution more easily

13
Architectural Style (2/7)

• Dataflow systems
• batch sequential
• pipes and filters
• Call-and-return systems
• main program and subroutine
• OO systems
• hierarchical layers
• Independent components
• communicating processes
• event systems
• Virtual machines
• interpreters
• rule-based systems
• Data-centered systems
• databases
• hypertext systems
• blackboards

14
Architectural Style (3/7)

• Pipes and filters
• component reads streams of data on its inputs and
  produces streams of data on its outputs
• invariants
• filters must be independent entities
• correctness of the output of a pipe-and-filter
  network should not depend on the order
• examples
• compiler, functional programming, parallel
  programming

15
Architectural Style (3/7)

• Pipes and filters
• component reads streams of data on its inputs and
  produces streams of data on its outputs
• invariants
• filters must be independent entities
• correctness of the output of a pipe-and-filter
  network should not depend on the order
• examples
• compiler, functional programming, parallel
  programming

16
Architectural Style (4/7)

• Data abstraction and OO organization
• data representation and their associated
  primitive operations are encapsulated in an
  abstract data type or object
• components are object or instances of ADT
• objects interact through function and procedure
  invocations

17
Architectural Style (5/7)

• Event-based, implicit invocation
• other components in the system can register an
  interest in an event by associating a procedure
  with it
• component can announce(broadcast) one or more
  events
• components are modules whose interfaces provide
  both a collection of procedures and a set of
  events
• invariant
• announcers of events do not know which components
  will be affected by those events
• examples
• database management systems, user interfaces ..

18
Architectural Style (6/7)

• Layered systems
• organized hierarchically
• each layer provide service to the layer above it,
  and serve as a client to the layer below
• components implements a virtual machine at some
  layer in the hierarchy
• example
• layered communication protocols

19
Architectural Style (7/7)

• Repositories
• components central data structure (repository)
  and a collection of independent components
• interactions btw. the repository and its external
  components vary significantly among systems
• examples
• applications requiring complex interpretations of
  signal processing

20
Research directions

• Architecture description language
• Architectural analysis techniques
• Architectural development methods
• Tools and environments for architectural design
• Case studies

21
Architecture Description Language Motivation(1/2)

• Software architecture and architectural style is
  informal and ad hoc
• described using informal box and line diagrams in
  design documentation ( lack of information)
• limit the usefulness of the diagrams
• architectural erosion and architectural drift
• difficult to analyze
• Need more precise descriptions of architectures
• Formal methods
• provide strong analytic power and independence
  from implementation details
• ADLs
• provide a much better match to architecture by
  defining notations for components and connectors

22
Architecture Description Language Motivation (2/2)

• Architecture Description Language based on a
  formal,abstract model of system behavior
• can provide a practical means of describing and
  analyzing interaction in software architectures
  and architectural styles

23
What needs to be specified about architectures

• Structural properties
• the ways component interact
• the ways those components can be combined into
  systems
• Extra-functional properties
• express the performance, capacity, environmental
  assumptions and global properties such as
  reliability and security
• time requirements, timing variability, real-time
  response, latency, throughput, bandwidth, space
  requirements, adaptability
• Families of related systems
• architectural styles

24
ADLs (1/2)

• Darwin
• developed by Magee and Kramer
• supports the description of dynamically
  reconfiguring architectures
• provides a semantics for its structural aspects
  through the ?-calculus
• UniCon
• developed by Shaw et al.
• focuses on compilation of architectural
  descriptions and modules into executable code
• Aesop
• developed by Garlan et al.
• provide an explicit mechanism for describing
  styles
• support methods for real-time analysis

25
ADLs (2/2)

• Rapide
• developed by Luckham et al.
• defines component types in terms of a collection
  of communication events
• emphasizes behavioral specification and the
  simulation of architectural design
• permits a form of consistency checking and
  analysis
• Wright
• developed by Robert J. Allen
• permits the description of both architectural
  styles and architectural instances (configuration
  )