Software Architecture Review

1
Software Architecture Review

• SE540 Software Architecture
• Mark Ardis, Rochester Institute of Technology
• Fall 2007

2
Acknowledgements

• Some of the material in these slides is taken
  from Software Architecture in Practice, 2nd
  edition by Bass, Clements and Kazman.
• Some of the material in these slides is taken
  from An Introduction to Software Architecture
  by Garlan and Shaw.
• Some of the material in these slides is taken
  from Software Product Lines Practices and
  Patterns by Clements and Northrop.

3
Outline

• Architecture Business Cycle
• Architectural Structures
• Documenting Software Architectures
• Designing Software Architectures
• Software Product Lines
• Commonality Analysis

4
Stakeholders

• Developing Organization Management
• Marketing
• End User
• Maintenance Organization
• Customer

5
Architecture Business Cycle

• Stakeholders
• Developing Organization
• Technical Environment
• Architect's Experience

6
Architectural Structures
7
Module Structures

• Decomposition - contains
• Uses - calls
• Layered - controlled access
• Class - inheritance

8
Component-and-Connector Structures

• Client-Server
• Concurrency - parallel execution
• Process - synchronization
• Repository

9
Allocation Structures

• Work assignment - who does what
• Deployment - allocation to hardware
• Implementation - mapping to files

10
Suggested View Documentation Template

• Primary presentation elements and their
  relationships
• Element catalog -- explains the picture
• Context diagram -- how the system relates to its
  environment
• Variability guide how to exercise any variation
  points
• Architecture background why the design
  reflected in the view came to be
• Glossary of terms used
• Other information

11
Pictorially
12
Documenting Interfaces

• Interface identity - unique name
• Resources provided
• Locally defined data types - if used
• Exception definitions - including handling
• Variability provided - for product lines
• Quality attribute characteristics - what is
  provided?
• Element requirements
• Rationale and design issues - why these choices
• Usage guide - protocols

13
2. Resources Provided

• Syntax - signature
• Semantics
• assignment of values to data
• changes in state
• events signaled or messages sent
• how other resources will behave differently in
  future
• humanly observable results
• Usage restrictions
• initialization requirements
• limit on number of actors using resource

14
7. Element Requirements

• Specific, named resources
• syntax
• semantics
• usage restrictions
• Assumptions

15
What is an Architectural Style?
16
Architectural Style Architectural Pattern

• Architectural Style Components Connectors
  Constraints
• Components computational elements
• Connectors interactions between components
• Constraints how components and connectors may be
  combined

17
Call and Return
18
Data Abstraction (Object Oriented)
19
Implicit Invocation (Callback)
Announcement of events
20
Pipe and Filter
21
Layered
22
Repositories (Database or Blackboard)
23
Interpreter
24
Distributed Processes

• Often described in terms of their topology
• ring
• star
• Sometimes described in terms of communication
  protocols
• client/server
• heartbeat

25
Domain-Specific

• Specific to a family of systems -- a product line
• Some components are common, but may be
  implemented in different ways
• Connections between common components are
  preserved across family

26
State Transition Systems

• Set of states
• Set of transitions between states
• Good style for reactive systems

27
Examples
28
Compiler Pipe and Filter
29
Compiler Modified Pipe and Filter
30
Compiler Repository
31
Attribute-Driven Design

• Recursive decomposition
• Start with
• Functional requirements (use cases)
• Constraints
• Quality attributes (scenarios)

32
Attribute-Driven Design Process

• Choose module to decompose
• Refine module
• Choose architectural drivers
• Choose architectural pattern
• Instantiate modules, allocate functionality, and
  represent using multiple views
• Define interfaces
• Refine use cases and scenarios---make them
  constraints for sub-modules
• Repeat until done

33
2.a) Choose Architectural Drivers

• Drivers are combination of functional
  requirements and quality attributes
• Prioritize requirements and select those that
  will "shape" the architecture
• May need some investigation to determine drivers

34
2.b) Choose Architectural Pattern

• Use tactics to achieve quality attributes
• Patterns package tactics

35
2.c) i) Instantiate Modules

• Refine (or interpret) the pattern for your
  particular problem
• Result is a decomposition into sub-modules

36
2.c) ii) Allocate Functionality

• Use the use cases to identify flow of information
• Assign responsibilities to sub-modules
• Pattern may help this process

37
2.c) iii) Represent Using Multiple Views

• Pick one view from each major category
• Module
• Decomposition, Uses, Class
• Component and Connector
• Client-server, Concurrency, Process, etc.
• Allocation
• Work assignment, Deployment, Implementation

38
2.d) Define Interfaces

• Each view provides information about interfaces
• Need to identify services provided and used

39
2.e) Refine Use Cases and Quality Scenarios

• Associate use cases and quality attributes to
  sub-modules
• may need to break up use cases
• Quality scenarios
• may be satisfied by decomposition
• may impose constraints on sub-modules
• may be neutral with respect to decomposition
• may not be satisfiable with decomposition

40
Software Product Lines

• SE540 Software Architecture
• Mark Ardis, Rochester Institute of Technology
• Fall 2006

41
Outline

• Motivation for Product Lines
• Paradox of Re-Use
• Architectural Support
• Challenges and Organizational Support

42
Airbus Beats Boeing in Huge Jetliner Deal with
USAir (11/6/96 NY Times)

• USAir, which had never bought a plane from
  Airbus, will purchase 120 Airbus A319s, A320s,
  and A321s...
• USAirs current fleet is a hodgepodge of nine
  types of aircraft
• A simplified domestic fleet would allow USAir to
  lower costs.
• Importance of Commonality
• USAir will reduce costs by using one aircraft
  type
• Airbus is reducing its production costs by
  reusing one aircraft type

43
Product Line Engineering
44
Economics Of Families

• Without Product-Line Engineering

With Product-Line Engineering
Cumulative
Cost
Number of Family Members
45
Re-Use Opportunities

• Requirements
• Architectural Design
• Software Elements
• Modeling and Analysis
• Testing

• Project Planning
• Processes, methods, tools
• People
• Exemplar Systems
• Defect Elimination

46
Failure of Re-Use

• If you build it, they will come.
• Re-Use libraries
• too sparse - not useful
• too rich - too difficult to search
• elements too small - easier to rewrite
• elements too large - too difficult to use
• architectural mismatch
• unknown pedigree

47
Success of Product Line Re-Use

• Context
• Architecture defined
• Quality attributes known
• Re-Use is planned
• Commonalities are known
• Application engineering is planned and supported

48
Scope How Big is the family?

• Consider market segmentation
• Customers should also have commonalities
• May need separate families for separate markets
• Consider supporting technology
• Narrow scopes can be automated more easily
• Broader scopes require more process discipline

49
Architectural Support for Variation

• Build process - include/exclude
• Build process - number of replicated elements
• Selection at compile or build - maintain
  interfaces but vary qualities
• Inheritance - allow different specializations
• Reflection - adapt to context
• Overloading - different types

50
Requirements for Success

• Software Engineering Practices
• Technical Management Practices
• Organizational Management Practices

51
Software Engineering Practices

• Architectural definition
• Architectural evaluation
• Component development
• COTS use
• Mining existing assets

• Requirements engineering
• Software system integration
• Testing
• Domain understanding

52
Technical Management Practices

• Configuration management
• Data collection and tracking
• Make/Buy/Mine analysis
• Process definition

• Scoping
• Technical planning
• Technical risk management
• Tool support

53
Organizational Management Practices

• Business case
• Customer management
• Acquisition strategy
• Funding
• Launching and institutionalizing
• Market analysis

• Operations
• Organizational planning
• Organizational risk management
• Organization structure
• Technology forecasting
• Training

54
Organizational Structures

• Development department (small)
• Business units (medium-sized)
• Domain engineering unit (large)
• Hierarchical domain engineering units(very large)

55
CelsiusTech Case Study

• SE540 Software Architecture
• Mark Ardis, Rochester Institute of Technology
• Fall 2006

56
Outline

• CelsiusTech Background
• Product-Line Results
• Motivation for Change
• Quality Attributes and Tactics

57
CelsiusTech Background

• Swedish naval defense contractor
• 2000 staff, 3M annual sales
• Command, Control and Communication (C3) systems
• Swedish corvettes (380 tons)
• Australian/New Zealand frigates (3225 tons)
• Danish patrol vessels (2700 tons)
• Swedish submarines (1330 tons)
• ...

58
Product-Line Projects
59
Code Re-Use
60
Motivation for Change

• 1975 - 80
• 30-100K SLOC assembly and RTL/2
• Analog to 16-bit digital
• 1980 - 85
• 700 SLOC RTL/2
• Minicomputers, multi-processors
• 1986 - future
• Ada
• Microcomputers, fault-tolerant
• Prototyping, iterative process

61
Organizational Structures

• Prior to 1986
• functional areas
• 1986 to 1991
• product-line development
• 1992 - 1998
• application engineering

62
Project Organization Prior to 1986
63
Project Organization 1986 - 1991
64
Project Organization 1992 - 1998
65
Quality Attributes

• Performance
• Modifiability
• Safety, reliability, and availability
• Testability

66
Tactics - Performance

• Introduce concurrency
• Reduce demand
• Multiple copies
• Increase resources

67
Tactics - Modifiability

• Semantic coherence
• Anticipate expected changes
• Generalize modules
• Abstract common services
• Interface stability

• Intermediary
• Configuration files
• Component replacement
• Standard protocols

68
Tactics - Safety, Reliability, Availability

• Exceptions
• Active redundancy
• State resynchronization
• Transactions

69
Tactics - Testability

• Separate interface from implementation

70
Commonality Analysis

• SE540 Software Architecture
• Mark Ardis, Rochester Institute of Technology
• Fall 2006

71
Outline

• Commonality Analysis Overview
• Exercise -- learn how to do it!

72
Domain Engineering
Commonality Analysis
Analysis Document, Application Modeling Language
Tools, Process
73
Commonality Analysis Process

• Consensus process
• All domain experts invited to participate
• Led by a trained moderator
• Real-time editing of the document

74
Commonality Analysis Sections

• Dictionary Technical vocabulary of the domain
• Commonalities Assertions about every member of
  the family
• Variabilities Assertions about variation across
  the family
• Parameters of Variation Type and binding time of
  variabilities
• Issues and To-Do List Parking lot for divisive
  issues or incomplete sections

75
Dictionary of Terms

• Lists the key terms for the family
• unit, status, action for configuration control
• Defines technical terms precisely
• unit - the set of circuits and a set of
  associated protocols (e.g. CLNKs, QLNKs) that
  comprise a single configurable entity
• Separates technical terms from ordinary
  vocabulary
• technical terms will appear italicized in later
  text

76
Commonalities

• Assumptions that are true for every family member
• Every X has the following attributes...
• Every unit has a status.
• Every unit has a list of allowed actions which
  must include at least remove and restore.

77
Variabilities

• Assumptions on how family members differ
• Examples
• A child unit has one or more parent units
• A unit may have 0 or 1 switch physical unit groups

78
Parameters of Variation
link
name
values
default
binding time
unit name
alphanumeric strings
none
specification
V1
inhibit state
V5
boolean
specification
false
V23, V24, V25
input request
ltunit name, unit number, action, ... gt
required
run
79
Issues and To-Do List

• Issues
• document items that need further thought or
  investigation, chronologically arranged
• record decisions
• document alternatives that were considered
• To-do list
• tasks that remain, usually with assignments to
  team members
• useful when changes leave document in
  inconsistent state

80
Domain Specific Languages for Product Line
Engineering

• SE540 Software Architecture
• Mark Ardis, RIT

81
Product Line Engineering
82
Domain Engineering
Commonality Analysis
Analysis Document, Application Modeling Language
Tools, Process
83
Eli Whitney

• Born December 8, 1765
• Raised on a farm in rural Massachusetts
• Attended Yale College 1789-1792
• What did Whitney do in 1793?

84
The Cotton Gin

• Whitney invented the cotton gin in 1793
• Southern planters refused to pay royalties on
  patent
• The gin was easy to manufacture
• Southern legislatures conspired against Whitney
• Whitneys company was out of business by 1797
• What did Whitney do in 1798?

85
Flintlock Components
86
Whitneys Gamble on Automation

• Whitney offered to make 10,000 muskets in 2 years
• No other manufacturer had ever made more than a
  few hundred muskets
• Automation was needed to improve the efficiency
  of the locksmiths
• Whitney invented milling machines to produce
  interchangeable parts
• Demonstrated for Congress in 1802

87
Configuration Control Technology
Domain Engineering Environment
Application Engineering Environment
88
Configuration ControlDevelopment Environment
Application Data
RAD
Reusable Assets
Knowledge Base
C Code
Application Environment Interface
Application Specific Configuration Control
89
RAD Tool
90
Parameters of Variation
link
name
values
default
binding time
unit name
alphanumeric strings
none
specification
V1
inhibit state
V5
boolean
specification
false
V23, V24, V25
input request
ltunit name, unit number, action, ... gt
required
run
91
Domain Specific Languages

• Validation and Realization algorithms
• Experimented with several different notations
• Translated into VFSM
• Reviewed by domain experts outside team
• Configuration specification
• Simple translation of parameters of variation
• Graphical tool facilitated marketing of DECC
• Composability enabled simulator development

92
Realization Jargon

• " Remove Realization
• realization(DECCrm)
• sendclientremovebegin
• ...
• invokeelevatespare_mate
• ...
• invokedelevateself
• invokeremovechild
• chk(result,abortORfail)
• ...
• sendrmtceremove
• sendclientremoveend
• end

93
Realization Flowcharts
94
Realization Grammar

• ltrealizationgt "realization(" lttextgt ")"
  ltstmtlistgt
• "end"
• ltstmtlistgt "" ltstmtgt ... ltstmtgt ""
• ltstmtgt ltchkgt ltsetgt ltsendgt
  ltinvokegt
• ltskipexpsgt ltskipendgt lttextgt
• ltchkgt "chk(" lttextgt ")" ltstmtlistgt
• ltsetgt "set(" lttextgt ")" ltstmtlistgt
• ltsendgt "send" ltstmtlistgt
• ltinvokegt "invoke" ltstmtlistgt
• ltskipendgt "skipend" ltstmtlistgt
• ltskipexpsgt "skipexps" ltstmtlistgt
• lttextgt any free-form text (including
  empty)

95
Configuration Language

• unit.class(Unit1)
• unit.number.segments1
• max.units0
• inhibit.condno
• routine.maintno
• soft.switchno

• unit(Unit1 0)
• children
• child(Unit2 0)
• mate.spares
• spare(Unit1 1)

96
Configuration Control Technology
Domain Engineering Environment
Application Engineering Environment