Software Architecture

1

• Software Architecture
• Alan Kelon Oliveira de Moraes
• akom_at_cin.ufpe.br
• Feb 12, 2006 Recife

2
Motivation

• Size and complexity of software systems increases
• Problems of developing large-scale software
  systems
• Patterns have emerged informally over time
• People recognize the need for a more disciplined
  approach

3
History Pre-1990

• Dijkstra published the first paper to document
  the design of a software system using
  hierarchical layers Dijkstra, 1968
• The first reference to Software Architecture
  NATO, 1969
• Parnas described the use of modularization and
  information hiding Parnas, 1972
• Stevens et al introduced the notions of module
  coupling and cohesion Stevens, 1974

4
History 1990-1998

• Software Architecture as distinct discipline
• The 1990s is the decade of software architecture
  Perry and Wolf, 1992
• The first book on software architecture Witt,
  1994.
• The first method of a SEI series was Software
  Architecture Analysis Method (SAAM) Kazman et
  al., 1994.
• The 41 Model View Is published as architecture
  method of RUP Kruchten, 1995
• Another book, The Art of System Architecting,
  nicely filled the gap between system and software
  Rechtin, 1997
• Software architecture really started to bloom!

5
History 1990-2006

• First IFIP Conference on Software Architecture
  (1999)
• Software Architecture has emerged as apropriate
  level to deal software quality Dobrica et al.,
  2002
• New methods such as SAAM Kazman et al., 1994,
  BAPO Obbink et al., 2000 and ATAM Clements et
  al., 2002 emerged or consolidated
• From basic research to an essential element of
  software system design and construction Shaw and
  Clements, 2006

6
(No Transcript)
7
Definition

• Consist of two parts Macroarchitecture and
  microarchitecture Dobrica et al., 2002
• Perry and Wolf, 1992 Shaw and Garlan, 1996
• The structure of components in a program or
  system, their interrelationships, and the
  principles and guides that control the design and
  evolution in time.
• See http//www.sei.cmu.edu/architecture/definition
  s.html for 60 more definitions...

8
Definition

• Clements et al., 1998
• The software architecture of a program or
  computing system is the structure or structures
  of the system, which comprise software
  components, the externally visible properties of
  those components, and the relationships among
  them.

9
Software architecture

• Most definitions indicate that an architecture
  Eeles
• is concerned with both structure and behavior
• is concerned with significant decisions only
• may conform to an architectural style
• is influenced by its stakeholders and its
  environment,
• embodies decisions based on rationale.

10
Roles of a SA

• Communication among stakeholders
• Early design decisions
• Reuse on several levels
• First approach to achieving quality attributes
• Basis for system analysis

11
An architecture defines structure

• Defines the composition of structural elements,
  their relationships, their interfaces, and their
  partitioning.

12
An architecture defines structure

• A structural element may be
• a subsystem
• a process
• a library
• a database
• a computational node
• a legacy system
• an off-the-shelf product

13
An architecture defines behavior

• An architecture defines the interactions between
  these structural elements
• These interactions that provide the desired
  system behavior

14
An architecture focuses on significant elements

• It is not concerned with defining all of the
  structure and all of the behavior
• Significant elements are those that have a long
  and lasting effect, such as the major structural
  elements, those elements associated with
  essential behavior, and those elements that
  address significant qualities such as reliability
  and scalability
• An architecture is an abstraction of the system
  that helps an architect manage complexity.

15
Architecture vs. Design

• Architecture
• Specify the properties of components and their
  interactions
• Design
• Involves algorithm, data structures, and
  realization

16
An architecture embodies decisions based on
rationale

• An important aspect of an architecture is not
  just the end result, the architecture itself, but
  the rationale for why it is the way it is.
• Document the decisions that have led to this
  architecture and the rationale for those
  decisions.

17
An architecture may conform to an architectural
style

• Many systems have a similar solution structure
• This similarity can be described as an
  architectural style, which can be thought of as a
  particular kind of pattern
• Problems in practice already solved
• Like a pattern, an architectural style represents
  a codification of experience, and it is good
  practice for architects to look for opportunities
  to reuse such experience.

18
A style consists of

• a set of component types (e.g., process,
  procedure) that perform some function at runtime
• a topological layout of the components showing
  their runtime relationships
• a set of semantic constraints
• a set of connectors (e.g., data streams, sockets)
  that mediate communication among components

19
Styles Garlan and Shaw, 1994

• Pipes and Filters
• Data Abstraction and Object-Oriented Organization
• Event-based, Implicit Invocation
• Layered Systems
• Repositories
• Table Driven Interpreters
• Heterogeneous Style

20

• Pipes and Filters
• Advantages
• understand the overall input/output behavior
• reuse
• systems can be easily maintained
• Disadvantages
• batch organization of processing
• performance

21
An architecture balances stakeholder needs

• Created to ultimately address a set of
  stakeholder needs
• The end user is concerned with intuitive and
  correct behavior, performance, reliability,
  usability, availability, and security.
• The system administrator is concerned with
  intuitive behavior, administration, and tools to
  aid monitoring.
• The marketer is concerned with competitive
  features, time to market, positioning with other
  products, and cost.
• The customer is concerned with cost, stability,
  and schedule.
• The developer is concerned with clear
  requirements, and a simple and consistent design
  approach.
• The project manager is concerned with
  predictability in the tracking of the project,
  schedule, productive use of resources, and
  budget.
• The maintainer is concerned with a
  comprehensible, consistent, and documented design
  approach, and the ease with which modifications
  can be made.

22

• Software architecture as a bridge Garlan, 2000

23
An architecture influences team structure

• Conways Law (1968)
• Organizations which design systems are
  constrained to produce designs which are copies
  of the communication structures of these
  organizations.
• If you have four groups working on a compiler,
  you'll get a 4-pass compiler.
• Ovaska et al., 2003
• Architecture as a Coordination Tool in Multi-site
  Software Development

24
Characteristics of a software architect

• He is a technical leader
• The architect role may be fulfilled by a team
• Understands the software development process
• Has knowledge of the business domain
• Has technology knowledge
• However, architects do not need to be technology
  experts

25
Characteristics of a software architect

• Has design skills
• Has programming skills
• Is a good communicator
• Is a negotiator
• Makes decisions

26
Architectual Design Activities
27
Attribute-Based Design

• RiSEs Seminars
• Basss book Chapter 07
• Eduardo Cruz

28
Summary

• Designing the Architecture (Chapter 7)
• Evolutionary Delivery Life Cycle
• When Can I begin Designing?
• How to identify the architectural drivers?
• Attribute-Driven Design

29
Evolutionary Delivery Life Cycle
30
Evolutionary Delivery Life Cycle
Designing the Architecture Chapter 7

• Goal
• To get user and customer feedback
• Microsoft strategy
• Skeletal system
• Early
• Low-fidelity
• Updates

31
How to identify the architectural drivers?
Designing the Architecture Chapter 7

• To priorize business goals few
• To put these business goals into quality
  scenarios or use cases
• Scenarys template
• To choose the most importants
• Impact on the architecture

32
Attribute-Driven Design
Designing the Architecture Chapter 7

• Approach to define a software architecture that
  bases the decomposition process on the quality
  attributes the software has to fulfill
• Recursive decomposition process
• Use
• Tatics
• Architectural Patterns
• Systematic approach

33
Attribute-Driven Design (cont.)
Designing the Architecture Chapter 7

• To satisfy quality attributes and functional
  requirements
• RUPs extension
• High-level design
• Detailed design and implementation
• ADD
• Detailed high-level Rational
• Input
• Functional requirements
• Constraints
• Quality attributes scenarios

34
ADD Steps (p. 157)

• Choose the module to decompose
• Module the system
• Inputs requirements, quality attributes,
  constraints
• Quality attributes scenarios
• Refine the module
• Choose the architectural drivers from the set of
  concrete quality scenarios and functional
  requirements
• Choose an architectural pattern that satisfies
  the architectural drivers
• Instantiate modules and allocate functionality
  from the use cases
• Define interfaces of the child modules
• Verify and refine use cases and quality scenaries
• Repeat the steps above for every module that
  needs further decomposition

35
ADD Steps

• Choose the module to decompose
• System
• Subsystem
• Submodules
• Choose the architectural drivers
• Combination of functional and quality
  requirements that shape the architecture or the
  particular module under considerations
• It is not always a top-down process
• Prototype
• Decomposition criterias
• Based on architectural drivers
• Requirements priorization

36
ADD Steps (cont.)

• Choose an Architectural Pattern
• Goal To establish an overall architectural
  pattern consisting of module types
• Quality attributes -gt Tatics -gt Patterns
• Instantiate Modules and Allocate Functionality
  using Multiple Views
• Instantiate module
• Use of responsability
• Allocate functionality
• Based on Use cases
• Represent the architecture with views
  (flexibility)
• Iterative process
• One view is normally sufficient
• Module decomposition
• Concurrency
• Deployment
• Others aspects can be used

37
ADD Steps (cont.)

• Define Interfaces of the Child Modules
• Documentation aspects
• Verify and Refine Use cases and Quality Scenarios
  as Constraints for the Child Modules
• Functional requirements
• Requirements use cases -gt module
• Constraints
• The decomposition satisfies the constraint
• The constraint is satisfied by a single child
  module
• The constraint is satisfied by multiple child
  module

38
ADD Steps (cont.)

• Quality scenarios
• A quality scenario may be completely satisfied by
  the decomposition without any additional impact
• A quality scenario may be satisfied by the
  current decomposition with constraints on child
  modules
• The decomposition may be neutral with respect to
  a quality scenario
• A quality scenario may not be satisfiable with
  the current decompostion
• Result
• Child module
• Responsability
• Use cases
• Interfaces
• Quality scenario
• Constraints

39
References

• L. Bass, P. C. Clements, R. Kazman. Software
  Architecture in Practice. Second Edition,
  Addison-Wesley, 2003.