Quality Attributes and Architectural Styles

1
Quality Attributes and Architectural Styles

• Lecture 5

2
References

• Chapter 4 Quality Attributes from Software
  Architectures in Practice.
• Chapter 5 Moving from Qualities to Architectural
  Styles from Software Architectures in Practice.
• An Introduction to Software Architecture by David
  Garlan and Mary Shaw, Jan 1994, CMU-CS-94-166.
  Tech Report, School of Computer Science, Carnegie
  Mellon University. Available from
  http//www-2.cs.cmu.edu/afs/cs/project/able/www/pa
  per_abstracts/intro_softarch.html

3
Quality Attributes

• Systems often designed to fulfill functional
  requirements.
• Essential quality attributes of the system are
  often ignored.
• Systems often re-engineered not for deficiencies
  in functionality but of lack of certain quality
  attributes , e.g.,
• Inability to maintain
• Inability to port
• Insecure
• Mapping of a systems functionality onto software
  structures determines the architecture's support
  for qualities.

4
Quality Attributes and Architectures

• Categories of quality attributes.
• Observable via execution ( i.e., observable at
  run time).
• Not observable via execution ( i.e., observable
  during development cycle).
• Knowledge of qualities in the first category does
  not necessarily imply any knowledge of qualities
  in the second category.
• Qualities must be considered at all phases of
  development.

5
Quality Attributes and Architectures(Contd)

• Different qualities manifest themselves
  differently during these phases e.g.,
• Modifiability is largely architectural.
• Performance has both architectural and non-
  architectural dependencies.
• Architecture is critical to the realization of
  many qualities of interest in a system.
• These qualities should be designed in and
  evaluated at the architectural level
• Some qualities are not architecturally sensitive.
• Attempting to achieve these qualities or analyze
  them through architectural means is not fruitful.

6
System Quality Attributes Discernable at Run Time
System Quality Attribute Architectural in Nature ? Architectural Issues
Performance Yes Inter-component communications, dividing functionality to exploit parallelisms
Security Yes Specialized components e.g., secure kernels, authentication servers, firewalls
Availability Yes Fault tolerance with redundant components
Functionality No Interaction with other quality attributes
Usability Yes Modifiability issues, Information flows, Efficiency related to performance
7
System Quality Attributes not Discernable at Run
Time
System Quality Attribute Architectural in Nature ? Architectural Issues
Modifiability Yes Modularization, encapsulating behavior
Portability Yes Portability Layer
Reusability Yes Loose coupling among components
Integrability Yes Compatible interconnection mechanisms, consistent components interfaces, uses relation allows incremental builds
Testability Yes Modularized encapsulating components uses relation allows incremental builds
8
Business Qualities

• Time to Market
• Usually leads to the reuse existing and COTS
  components.
• The ability to insert a component into a system
  depends on the decomposition of the system into
  components, one or more of which are pre built.
• Cost
• Different architectures yield different
  development costs.

9
Business Qualities (Contd)

• Projected Lifetime of the System
• Modifiability and portability essential for
  systems that are intended to have a longer life
  time.
• Modifiability and portability increases time to
  market.
• Targeted Market
• Platform as well as feature sets determines the
  size of the potential market.
• Product line approach i.e. common core around
  which layers of software of increasing
  specificity are constructed.

10
Business Qualities (Contd)

• Extensive use of Legacy System
• Appropriate integration mechanisms essential to
  integrate new and existing systems.
• Property with marketing importance but which has
  substantial architectural complications.

11
Qualities of the Architecture

• Conceptual Integrity
• Unifies design of a system at all levels.
• Similar things should be performed in similar
  ways.
• Correctness and Completeness
• Allows all the system's requirements and runtime
  resources constraints to be met.

12
Qualities of the Architecture (Contd)

• Buildability
• Allows the system to be completed by the
  available team in a timely manner and to be open
  to certain changes as the system development
  progresses.
• Refers to the case of constructing a desired
  system.
• Measured in terms of cost and times.
• Depends upon the match between the materials used
  to build the system and the available tools.
• Systems that casts a solution in terms of well
  understood concepts is more buildable.

13
Introduction to Architectural Styles

• Qualities provide general guidelines and goals
  for a system but are too vague to enable the
  design of a system.
• Architectural styles are system patterns used in
  achieving architectural aspects of software
  quality.
• Architectural styles have a few key features and
  rules for combining those features so that
  architectural integrity is preserved.

14
Introduction to Architectural Styles (Contd)

• Architectural styles determined by
• A set of component types (e.g., data
  repositories, processes, procedures) that perform
  some function at runtime.
• A topological layout of these components
  indicating their runtime interrelationships.
• A set of semantic constraints (e.g., a
  non-modifiable data repository).
• A set of connectors (e.g. function calls, data
  streams , sockets that mediate communication ,
  coordination or cooperation among components.

15
Introduction to Architectural Styles (Contd)

• Styles defines a class of architectures,
• i.e., it is an abstraction for a set of
  architectures that conform to it
• Styles have following ambiguities,
• Number of components involved.
• Mechanisms by which components interact (although
  some styles explicitly bind these).
• Specific function of the system for which the
  style is being used.

16
Categorization of Styles in Related groups

• Independent Components
• Data Centered
• Data Flow
• Virtual Machine
• Call Return

17
Independent Components
Independent Components
Communicating Processes
Event Systems
Implicit Invocation
Explicit Invocation
18
Independent Components (Contd.)

• System organized as a set of concurrently
  executing processes communicating via messages.
• Goal to achieve modifiability by decoupling
  various portions of computation.
• Another goal is to achieve scalability.
• Event Systems interact by notifying each other
  of occurrence of specific events.
• Event system make use of message managers that
  manage communications among components.

19
Data Centered Architectures
Data Centered
Repositories
Blackboard
20
Data Centered Architectures (Contd.)

• Attempts to achieve the quality of integrability
  of data.
• Refers to systems that allows access and update
  of a widely accessed shared data store by clients.

Client
Client
Client
Shared Data
21
Data Centered Architectures (Contd.)

• Repositories are passive systems that respond to
  clients requests for access and update of data.
• Blackboards are active systems that notify
  clients when data of interest changes.
• A scalable style in which
• Clients are independent of each other.
• Data stores are independent of the clients
• New clients can be added easily.
• Change in one client does not affect the
  operation of other clients.

22
Data Centered Architectures (Contd.)

• Coupling between clients reduces modifiability
  but increases performance.
• When clients are built as independently executing
  processes, the style transforms to a client
  server style belonging to independent component
  style.

23
Data Flow Architectures
24
Data Flow Architectures (Contd.)

• Goal to achieve the qualities of reuse and
  modifiability.
• Style is characterized by viewing the system as a
  series of transformations on successive pieces of
  input data.
• Data enters the system and then flows through the
  components one at a time until they are assigned
  to some final destination (output or a data
  store).

25
Data Flow Architectures (Contd.)

• Batch Sequential Style
• Processing steps or components are independent
  programs.
• Assumption is that each step runs to completion
  before the next step starts.
• Each batch of data are transmitted as a whole
  between the steps.

Compressed Voice
Filter
Compress
Packetize
Filtered Voice
Digitized Voice
Packetized Voice
Compression Parameters
26
Data Flow Architectures (Contd.)

• Pipe and Filter Style
• Emphasizes the incremental transformation of data
  by successive components.
• Filters are stream transducers.
• Filters incrementally transform data (stream to
  stream ) use little contextual information and
  return no state information.
• Pipes are stateless and exist to transfer data

27
Virtual Machine Architectures
28
Virtual Machine Architectures (Contd.)

• Goal to achieve the quality of portability.
• Simulate some functionality that is not native to
  the hardware and/or software on which it is
  implemented.
• Useful for
• simulating platforms not yet constructed.
• porting the executable system to a different
  hardware.

29
Virtual Machine Architectures (Contd.)
Input
Output
Update
Interpretation Engine
Program Data
Interpreters Internal State
Data
Program Instruction
Program being Interpreted
A Typical Interpreter
30
Virtual Machine Architectures (Contd.)

• Merits and demerits of interpretation
• Ability to interrupt, query and modify programs
  at runtime.
• Interpreters introduce performance penalties as
  additional computational is involved in program
  execution.

31
Call and Return Architectures
Call and Return
Main Program
Layered
Object Oriented
Subroutine
32
Call and Return Architectures (Contd.)

• Goal of achieving the qualities of modifiability
  and scalability.
• Main Program and Subroutine Architectures.
• Classical Programming Paradigm.
• Goal is to decompose a program into its smaller
  components hierarchically to achieve
  modifiability.
• Typically a single thread of control and each
  component in the hierarchy gets this control from
  its parents and passes it along to its children.

33
Call and Return Architectures (Contd.)
Main Program and Subroutine Model
34
Call and Return Architectures (Contd.)

• Object Oriented or Abstract Data Types Systems
• Focuses on bundling data and knowledge of how to
  manipulate and access that data with a goal to
  achieve the quality of modifiability.
• The bundle is an encapsulation, hiding its
  internal secrets from its environments.
• Access to the object is through provided
  operations only.

35
Call and Return Architectures (Contd.)

• Object Oriented or Abstract Data Types Systems
  (Contd.)
• Operations of an object are known as methods and
  are constrained form of procedure calls.
• Encapsulation promotes reuse and modifiability
  through separation of concerns.
• When object abstractions form components that
  provide black box services and other components
  request those services, the style can be referred
  to as the call-based-client server style.

36
Call and Return Architectures (Contd.)
37
Call and Return Architectures (Contd.)

• Layered Systems
• Components are assigned to layers to control
  inter-component interaction.
• The goal is to achieve the qualities of
  modifiability and portability.
• In the pure version of this style, each layer
  communicates with its immediate neighbours.
• The lowest layer provides some core
  functionality.
• Each successive layer is built on its predecessor
  hiding the lower layer and providing some
  services that the upper layer can make use of.

38
Call and Return Architectures (Contd.)

• Layered Systems (Contd)
• Upper layers often provide virtual machines
  themselves, i.e., complete sets of coherent
  functionality upon which an application or a more
  complex vertical machine can be built.
• Layer bridging is impure layering where functions
  in one layer may talk to functions in layers
  other than its immediate neighbours.
• Layer bridging improves performance but at the
  cost of compromising the model.

39
Call and Return Architectures (Contd.)
User Interface
Useful System
Layer Bridging
Basic Utility
Core
40
Heterogeneous Styles

• Systems are seldom built from a single style.
• Heterogeneity in styles
• Locationally Heterogeneous
• Runtime structures reveal patterns of different
  styles in different areas.
• Example, some branches of main program and sub
  program systems have a shared data repository.
• Hierarchically Heterogeneous
• Component of one style when decomposed is
  structured according to the rules of a different
  style.
• Example, high level system is organized as layers
  but each layer is structured as an object
  oriented system.

41
Heterogeneous Styles (Contd)

• Heterogeneity in styles (Contd.)
• Simultaneously heterogeneous
• Any of several styles may well be apt
  descriptions of the system.

42
Analyzing Architectural Styles

• An architecture is almost never constructed
  entirely from one style.
• Interrelationships among styles need to be
  understood.
• Requirements
• Identify significant differences that affect the
  suitability of a style for various tasks.
• Classify styles that are variations of others
  allowing architects to chose appropriate
  combinations of styles.
• Identify features used to classify styles that
  will help designers to focus on important design
  issues.

43
Style Feature Categories

• Focus on the characteristics of interactions
  among components.
• Important discriminations among styles are
  allowable kinds of components and connectors.
• Components and connectors are the primary
  building blocks of architectures.

44
Style Feature Categories (Contd)

• A component is a unit of software that performs
  some function at runtime.
• A connector is a mechanism that mediates
  communication, coordination or cooperation among
  components.
• Selecting types of constituent parts does not
  uniquely identify the style.
• Other feature categories include control issue,
  data issues and control/data issues.

45
Control Issues

• Control issues describe how control passes among
  components and how components work together
  temporally.
• Control issues include
• Topology
• Describes the geometric form of control flow.
• Static or dynamic topologies dependent upon the
  binding of elements.

46
Control Issues (Contd)

• Control issues include (Contd)
• Synchronicity
• Describes the dependency of components actions
  upon each others control states.
• Examples include sequential processing or
  parallelism.
• Binding Time
• Describes the identity of a partner in a transfer
  of control operation.
• Categories include compile-time invocation-time
  and runtime (dynamic) binding.

47
Data Issues

• Describes how data is moved around a within
  system.
• Data issues include
• Topology
• Describes the geometric shape of systems data
  flow graph.
• Continuity
• Defines the periodicity as well as the volume of
  data exchanged between components.

48
Data Issues (Contd)

• Data issues include (Contd)
• Mode
• Describes how data is made available to
  components in a system.
• Examples include arguments, message passing,
  sharing data etc.
• Binding Time
• Defines the time when the identity of a partner
  in a transfer of control operation is established.

49
Control Data Interaction Issues

• Interaction issues describe the relationship
  between certain control and data issues
• Shape
• Isomorphism in control flow and data flow
  topologies
• Directionality
• If the shapes are the same does the control flow
  in the same direction as data or in the opposite
  direction

50
Values for Typical Features

• Topology
• Linear hierarchical, arbitrary, star.
• Synchronicity
• Sequential, asynchronous,synchronous.
• Binding Time
• Compile time, runtime, invocation time, write
  time.
• Continuity
• Sporadic, continuous.
• High volume, low volume.
• Mode
• Passed, Shared, multicast.

51
Using Styles in System Design

• Choice of architectural style depends upon the
  qualities of interest.
• A style can serve as a primary description of a
  system in an area where discourse and thought are
  most important to meet uncertainty.
• Other styles may be equally applicable.

52
Using Styles in System Design (Contd)

• Basic Rule of thumb in selecting a style
• Start with the architectural structure that
  promotes the maximum leverage on qualities
  including functionality that are difficult to
  achieve.
• Consider a style appropriate to the structure
  that addresses these qualities.
• Other styles and structures can be accommodated
  to help address secondary issues