Choosing an Architectural style

1
Choosing an Architectural style

2
Rules of Thumb for Choosing Styles

• The goal of style catalogs is to develop a design
  handbook If your problem looks like x, use
  style y.
• The practice is not that advanced yet. The best
  that we can do is offer rules of thumb.

3
Data-Flow Style

• Use if
• it makes sense to view your system as one that
  produces a well-defined, easily-identified output
  that is the direct result of sequentially
  transforming a well-defined, easily-identified
  input in a time-independent fashion
• integrability (in this case, resulting from
  relatively simple interfaces between components)
  is important

4
Data-Flow Substyles

• Pipe and filter the computation involves
  transformations on continuous streams of data
• Closed loop control your system involves
  controlling continuing action, is embedded in a
  physical system, and is subject to unpredictable
  external perturbation so that preset algorithms
  go awry

5
Call-and-Return Style

• Use if
• the order of computation is fixed, and
• components can make no useful progress while
  awaiting the results of requests to other
  components

6
Call-and-Return Substyles -1

• Object-oriented overall modifiability and
  integrability (via careful attention to
  interfaces) are driving quality requirements
• Abstract data types many system data types whose
  representation is likely to change
• Objects many like modules, commonalties could be
  exploited through inheritance
• Call-and-return-based client-server
  modifiability with respect to the production of
  data and how it is consumed is important

7
Call-and-Return Substyles -2

• Layered
• if the tasks in your system can be divided
  between those specific to the application and
  those generic to many applications but specific
  to the underlying computing platform
• if portability across computing platforms is
  important
• if you can use an already-developed computing
  infrastructure layer (operating system, network
  management package, etc.)

8
Independent Component Style

• Use if
• your system runs on a multi-processor platform
  (or may do so in the future)
• your system can be structured as a set of loosely
  coupled components
• meaning that one component can continue to make
  progress somewhat independently of the state of
  other components
• performance tuning is important
• by re-allocating work among processes

9
Independent Component Substyles

• Communicating processes
• message-passing is sufficient as an interaction
  mechanism
• Lightweight processes
• access to shared data is critical to meet
  performance goals
• Distributed objects the reasons for the
  object-oriented style and the interacting process
  style all apply

10
Independent Component Substyles

• Broadcast
• all of the components need to be synchronized
  from time to time, and/or
• availability is an important requirement
• Event systems
• you want to decouple the consumers of events from
  their signalers, or
• you want scalability in the form of adding
  processes that are triggered by events already
  detected/signaled in the system

11
Data-Centered Style

• Use if central issue is the storage,
  representation, management, and retrieval of a
  large amount of related long-lived data
• transactional database/repository
• order of component execution is determined by a
  stream of incoming requests to access/update the
  data, and the data is highly structured
• blackboard
• you want scalability in the form of adding
  consumers of data without changing the producers
  or
• you want modifiability in the form of changing
  who produces and consumes which data

12
Virtual Machine Style

• Use if you have designed a computation, but have
  no fixed machine to run it on

13
Unit operations

• Codification of design operations applied to an
  architecture.
• Include
• abstraction
• compression
• part-whole decomposition
• is-a decomposition
• replication
• resource sharing

14
Abstraction

• Creates a virtual component.
• Used for
• simulated target platform
• layered systems
• common interface to heterogeneous set of
  underlying implementations

15
Compression

• Combines two components into a single component
• Used to
• enhance performance
• speed up system development

16
Decomposition

• Breaks up a large component into smaller pieces.
• Part-whole Decomposition
• Components are built from a fixed small set of
  subcomponents (e.g model view controller).
• For integrability, extensibility, and
  understandability

17
Decomposition

• Is-a Decomposition
• A subcomponent represents a specialization of its
  parent's functionality (e.g. class hierarchies).
• Used for reuse by increments.

18
Replication

• Exact duplication of a component
• Used for enhancing
• reliability (redundant operation)
• performance enhancement (data caching)

19
Resource Sharing

• Encapsulates either data or services and shares
  them among multiple independent consumers
  (examples shared databases, servers in
  client/servers).
• Used for
• integrability
• portability
• modifiability

20
Unit Operations and Qualities
Scalability System modifiability Integrability Por
tability Sequential performance Concurrent
performance Fault tolerance Ease of system
creation Component modifiability Ease of
component creation Reusability
Abstraction - Compression - -
- - - - - Part-whole decomposition
is-a decomposition - Replicat
ion - Resource sharing - -
21
Software Architecture Evaluation
22
When and Why To Analyze Architecture -1

• When building a system
• Architecture is the earliest artifact where
  tradeoffs are visible.
• Analysis should be done when deciding on
  architecture.
• The reality is that analysis is often done during
  damage control, later in the project.

23
When and Why To Analyze Architecture -2

• When acquiring a system
• Architectural analysis is useful if the system
  will have a long lifetime within organization.
• Analysis provides a mechanism for understanding
  how the system will evolve.
• Analysis can also provide insight into other
  visual qualities.

24
Architectural Reviews

• Questioning techniques to evaluate any aspect of
  an architecture for any given reason
• Scenario-based techniques (e.g SAAM)
• Questionnaire-based techniques
• Measuring techniques to answer questions about a
  specific quality
• Metrics quantitative interpretations of
  observable measures (e.g complexity metrics,
  performance metrics)
• Simulations, prototypes, experiments
  domain-specific models of an architecture or
  performance model

25
Review Process

• Preconditions
• Understand the context of the review
• Planned review vs Unplanned review
• Timing of the review (early, full)
• Assemble the right people
• Set organizational expectations and support
• Prepare for review (Read-Ahead Material)
• Obtain representation of the architecture

26
Review Process

• Activities of the review itself
• Evaluate e.g
• "run" the scenarios,
• answer the items in checklist,
• perform experiments,
• execute the prototypes
• Record issues (and members comments)
• Rank the issues (project-threatening, major,
  minor)

27
Review Process

• Activities of the review itself
• Watch Warning signs
• architecture forced to match organization
• top-level components number over 25
• one requirement drives entire design
• architecture depends on alternatives in the
  operating system
• choice of software components is dictated by
  hardware personnel
• redundancy not needed for reliability
• design is exception driven
• no identifiable architect

28
Review Process

• Report of review results
• Set of ranked issues
• Enhanced system documentation
• Set of scenarios for future use
• Identification of potentially reusable components
• Estimation of costs and benefits

29
Architecture Analysis Method (SAAM)

• Most useful in evaluating non-runtime qualities
• Specifies context through scenarios.
• SAAM steps
• Identify and assemble stakeholders
• Develop and prioritize scenarios
• Describe candidate architecture(s)
• Classify scenarios as direct or indirect
• Perform scenario evaluation
• Reveal scenario interactions
• Generate overall evaluation

30
SAAM Analysis produces

• Technical results provides insight into system
  capabilities
• Social results
• forces some documentation of architecture
• acts as communication vehicle among stakeholders

31
Scenarios

• A scenario is a brief description of a
  stakeholders interaction with a system.
• When creating scenarios, it is important to
  consider all stakeholders, especially
• end users
• developers
• maintainers
• system administrators

32
Step 1 Identify and Assemble Stakeholders -1
Stakeholder Interest Customer Sc
hedule and budget usefulness of system
meeting customers (or markets)
expectations End user Functionality,
usability Developer Clarity and completeness
of architecture high cohesion and limited
coupling of parts clear interaction
mechanisms Maintainer Maintainability ability
to locate places of change
33
Step 1 Identify and Assemble Stakeholders -2
Stakeholder Interest System Ease in finding
sources of administrator operational
problems Network Network performance, administra
tor predictability Integrator Clarity and
completeness of architecture high cohesion
and limited coupling of parts clear
interaction mechanisms
34
Step 1 Identify and Assemble Stakeholders -3
Stakeholder Interest Tester Integrated,
consistent error- handling limited component
coupling high component cohesion
conceptual integrity Application Architectural
clarity, completeness builder (if Interaction
mechanisms simple product line tailoring
mechanisms architecture) Representative Interoper
ability of the domain

35
Step 2 Stakeholders Develop and Prioritize
Scenarios

• Scenarios should be typical of the kinds of
  activities that the system must support
• functionality
• development activities
• change activities
• Scenarios also can be chosen to give insight into
  the system structure.
• Scenarios should represent tasks relevant to all
  stakeholders.
• Rule of thumb 10-20 scenarios

36
Step 3 Describe Candidate Architectures -1

• It is frequently necessary to elicit appropriate
  architectural descriptions.
• Structures chosen to describe the architecture
  will depend on the type of qualities to be
  evaluated.
• Static structures will be used to evaluate
  modification scenarios.
• Dynamic structures will be used to evaluate
  runtime qualities.

37
Step 3 Describe Candidate Architectures -2

• Typically, the architect is asked to bring the
  following documentation to an evaluation, as a
  starting point
• a description of the logical or module structure,
  with a clear definition of the responsibilities
  of each component
• a description of the process structure
• a data flow diagram showing how the modules
  interact at run time
• a description of the interconnection mechanism(s)
  used to distribute data and control among
  architectural components at run time
• a description, if needed, of the uses
  structure, showing how potential subsets will be
  realized

38
Step 4 Classify Scenarios

• There are two classes of scenarios.
• Direct scenarios are those that can be executed
  by the system without modification.
• Indirect scenarios are those that require
  modifications to the system.
• The classification depends upon both the scenario
  and the architecture.
• The classification should have gradations.
• indirect How hard is the change? (SAAM elicits
  this information.)
• direct How hard is it to execute? (SAAM does not
  consider this.)

39
Step 5 Perform Scenario Evaluation

• For each indirect scenario
• identify the components, data connections,
  control connections, and interfaces that must be
  added, deleted, or modified
• estimate the difficulty of modification
• Difficulty of modification is elicited from the
  architect and is based on the number of
  components to be modified and the effect of the
  modifications.
• A monolithic system will score well on this step,
  but not on next step.

40
Step 6 Reveal Scenario Interactions

• When multiple indirect scenarios affect the same
  components, this could indicate a problem.
• could be good, if scenarios are variants of each
  other
• change background color to green
• change background color to red
• could be bad, indicating a potentially poor
  separation of concerns
• change background color to red
• port system to a different platform

41
Step 7 Generate Overall Evaluation

• Not all scenarios are equal.
• The organization must determine which scenarios
  are most important.
• Then the organization must decide as to whether
  the design is acceptable as is or if it must be
  modified.

42
Interaction of SAAM Steps
scenario development
individual evaluation of indirect scenarios
assessment of scenario interaction
classification of scenarios
overall evaluation
architecture description
43
Example 1 KWIC

• Two architectures shared memory and abstract
  data type (ADT)
• Four scenarios
• 1. Operate in an incremental rather than a batch
  fashion. Program to accept one sentence at a
  time.
• 2. Program to eliminate entries beginning with
  noise words.
• 3. Change the internal representation of
  sentences (e.g., compressed or uncompressed).
• 4. Change the internal representation of
  the intermediate data structure (e.g., store
  indexes as shifted sentences or as pointers to
  input).

44
Solution 1Shared Memory
45
Solution 2 Abstract Data Types
Set char
Set char
Setup
Char
Word
alph
i-th
Word
Char
Circular shift
Alphabetic shift
46
Evaluation of architectures

• Scenario 1 (operate in incremental mode)
• Shared-Memory - Modification of
• Input to yield control after each sentence
• Master Control (routines are called repetitively)
• Alphabetizer to be incremental (e.g. insertion
  sort)
• Abstract Data Type
• Input to yield control after each sentence
• Master Control (routines are called repetitively)
• Alphabetizer to be incremental (e.g. insertion
  sort)
• Tie for both architectures

47
Evaluation of architectures

• Scenario 2 (elimination of noise words)
• Shared-Memory Modification of
• Circular Shift to eliminate shifted sentences
  beginning with noise words
• Abstract Data Types Modification of
• Circular Shift to eliminate shifted sentences
  beginning with noise words

48
Evaluation of architectures

• Scenario 3 (modify internal representation of
  input sequence)
• Shared-Memory Modification of
• All except Master Control
• Abstract Data Types Modification of
• Characters abstraction
• Abstract Data Types architecture scores better

49
Evaluation of architectures

• Scenario 4 (modify representation of intermediate
  data structures)
• Shared-Memory Modification of
• Circular Shift
• Alphabetizer
• Output
• Abstract Data Types Modification of
• Circular Shift
• Alphabetizer
• Abstract Data Types architecture scores better

50
Shared Memory KWIC
51
ADT KWIC
1
4
52
Scenario Interaction Analysis

• ADT is better
• Both architectures show scenario interaction in
  same number of components
• Shared-Memory Contention is among 3 of the
  scenarios in 2 components (Circular Shift,
  Alphabetizer)
• ADT no component has contention for more than 2
  scenarios

53
Evaluation of This Scenario Set
Shared Abstract memory data
types Scenario 1 0 0 Scenario
2 0 0 Scenario 3 - Scenario
4 - Contention -
54
Example 2 SAAM Applied to Revision Control
System

• WRCS is a large, commercially-available
  revision control system.

55
Architectural Representation of WRCS
56
Scenarios Used in WRCS

• User scenarios
• compare binary file representations
• configure the products toolbar
• Maintainer
• port to another operating system
• make minor modifications to the user interface
• Administrator
• change access permissions for a project
• integrate with a new development environment

57
Scenario Interactions

• Each indirect scenario necessitated a change in
  some modules. This can be represented either
  tabularly or visually.
• The number of scenarios that affected each module
  can be shown with a table or graphically, with a
  fish-eye view.
• A fish-eye view uses size to represent areas of
  interest.

58
Scenario Interaction Table
Module No. changes main 4 wrcs 7 diff 1 bind
iff 1 pvcs2rcs 1 sccs2rcs 1 nwcalls 1 nwspxipx
1 nwnlm 1 hook 4 report 1 visdiff 3 ctrls
2
59
Scenario Interaction Fish-Eye