Introduction to Software Architecture

1
Introduction toSoftware Architecture

• TV Prabhakar

2
Antecedents of Software Architecture
3
What is Software Architecture?

• 150 definitions
• What are they?
• Both a process and a product

4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
What type of requirements drive architectural
design?

• Answer Quality attribute requirements are the
  primary drivers for architecture design.
• Do you agree?

11
(No Transcript)
12
(No Transcript)
13
Architecture and Functionality

• Functionality is largely orthogonal to quality
  attribute requirements.
• Functionality is the ability of a system to do
  the work it was intended to do.
• Systems are decomposed into elements to achieve a
  variety of purposes other than function.
• Architectural choices promote certain qualities
  as well as implement the desired functionality.

14
Effects of Architectural Decisionson Quality
Attributes

• The degree to which a system meets its quality
  attribute requirements is dependent on
  architectural decisions.
• A change in structure improving one quality often
  affects the other qualities.
• Architecture is critical to the realization of
  quality attributes.
• These product qualities should be designed into
  the
• architecture.
• Architecture can only permit, not guarantee, any
  quality attribute.

15
Architecture-centric development?

• Architecture-centric development involves
• Creating the business case for the system
• Understanding the requirements
• Creating or selecting the architecture
• Documenting and communicating the architecture
• Analyzing or evaluating the architecture
• Implementing the system based on the architecture
• Ensuring that the implementation conforms to the
  architecture
• Maintaining the architecture
• The architecture must be both prescriptive and
  descriptive.

16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
Attribute-Driven Design

• The Attribute-Driven Design (ADD) method,
  developed at the SEI, is an approach to defining
  a software architecture that bases the
  decomposition process on the quality attributes
  the software must fill.
• a recursive decomposition process where, at each
  stage in the decomposition, tactics and
  architectural patterns are chosen to satisfy a
  set of quality scenarios.

23
(No Transcript)
24
ADD Method's Inputs and Outputs

• Inputs
• constraints
• functional requirements
• quality attribute requirements
• Outputs
• first several levels of module decomposition
• various other views of the system as appropriate
• set of elements for functionality and the
  interactions among them

25
Architecture Documentation

• Architecture documentation is important if and
  only if communication of the architecture is
  important.
• How can an architecture be used if it cannot be
  understood?
• How can it be understood if it cannot be
  communicated?
• Documenting the architecture is the crowning step
  to creating it.
• Documentation speaks for the architect, today and
  20 years from today.

26
(No Transcript)
27
Issues Addressed byan Architectural Design

• Gross decomposition of a system into interacting
  components
• typically hierarchical
• using rich abstractions for component
  interaction(or system glue)
• often using common design idioms/styles
• Emergent system properties
• performance, throughput, latencies
• reliability, security, fault tolerance,
  evolvability
• Rationale and assignment of function to
  components
• relates requirements and implementations
• Envelope of allowed change
• load-bearing walls, limits of scalability and
  adaptation
• design idioms and styles

28
Schools of Thought

• 4 1 View
• Zachmann Framework
• RM - ODP
• IEEE
• OMG
• TOGAF
• Product Lines

29
4 1 view

• Philips Kruchten, Rational Software,
  Architectural Blueprints - The 41 View Model of
  Software Archtecture, IEEE Software, 1995
• Use case view
• Logical view
• Process view
• Implementation view
• Deployment view

30
41 view
31
What do the views do?

• logical view is the object model of the design
  (when an object-oriented design method is used),
• process view captures the concurrency and
  synchronization aspects of the design,
• physical view which describes the mapping(s) of
  the software onto the hardware and reflects its
  distributed aspect,
• development view describes the static
  organization of the software in its development
  environment
• illustrated by a few selected use cases, or
  scenarios

32
Taxonomy of Styles

• Data Flow
• Batch Sequential
• Dataflow Network(pipes filters)
• acyclic, fanout, pipeline, Unix
• Closed loop control
• Call-and-return
• Main program/subroutines
• Information hiding(ADT, Object naïve
  client/server)

33
Taxonomy..

• Interacting Processes
• LW processes, distributed objects
• Event systems
• implicit invocation, pure events
• Data-oriented repository
• Transactional databases
• True client/server
• Blackboard
• Modern compiler

34
Taxonomy..

• Data-sharing
• compound documents
• Hypertext
• Fortran COMMON
• LW processes
• Hierarchical
• Layered
• Interpreter

35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38
(No Transcript)
39
(No Transcript)
40
Architectural Styles

• An architectural style consists of
• component/connector types, topology
• constraints on the topology and behavior
• an informal description of the costs and benefits
  of the style, e.g. use the pipe and filter style
  when reuse is desired and performance is not a
  top priority

41
Styles, Patterns and Idioms

• POSA, Buschmann etal
• GOF

42
References

• sei.cmu.edu
• IEEE
• OMG
• POSA
• GOF
• WWISA
• www.cetus-links.org
• Bredemeyer.com