SE 380 Software Architecture

1
SE 380Software Architecture

• Chapter 5.
• Achieving Qualities

2
Achieving Qualities

• What we know
• There is a difference between functionality and
  systembusinessarchitectural quality
• Functionality is what the program does
• Architecture is how it accomplishes it
• Use case is to functionality as a quality
  scenario is to architecture
• Given the desire to achieve a particular quality
  attribute, there must be accepted methods of do
  so

3
Tactics

• A tactic is a design decision that influences the
  expression of a quality attribute
• Tactics are generally based on experience
• Each tactic is a design decision
• Can refine or enhance other tactics
• Can be mutually exclusive with other tactics
• Architectural Patterns package tactics

Stimulus
Response
Tactics to Control Response
4
Availability

• Concerned with system failure and consequences
• How loss is detected
• How frequently loss happens
• What happened during loss
• How long loss persists

5
Availability Tactics

• In general, all availability tactics will involve
  some type of redundancy, some type of fault
  detection, and some type of recovery
• Stimulus How a fault is detected

Fault Masked or Repair Made
Fault
Tactics to Control Availability
6
Fault Detection Tactics

• Ping/echo
• Heartbeat (watchdog)
• Exceptions (error codes)

7
Fault Recovery Tactics

• Voting
• Active Redundancy
• Passive Redundancy
• Spare
• Shadow Operation
• State Resynchronization
• Checkpoint / Rollback

8
Fault Prevention

• Removal from service
• Transactions
• Process monitor

9
Modifiability

• Concerned with the cost of change
• What can change
• When it is changed, and who changes it

10
Modifiability Tactics

• Localize Modifications
• Maintain semantic coherence
• Anticipate expected changes
• Generalize the module
• Limit possible options
• Prevent Ripple Effects (eight types of
  dependencies)
• Hide information
• Maintain existing interfaces
• Restrict communication paths
• Use an intermediary

11
Modifiability (cont)

• Defer Binding Time
• Runtime registration
• Config files
• Polymorphism
• Component replacement
• Adherence to defined protocols

12
Performance

• Concerned with timing and response
• Resource consumption
• Blocked time
• Contention for resources
• Availability of resources
• Dependency on other computations
• Three tactic categories
• Resource demand
• Resource management
• Resource arbitration

13
Performance Tactics

• Resource Demand
• Increase computational efficiency
• Reduce computational overhead
• Modifiability / Performance tradeoff
• Manage event rate
• Control frequency of sampling
• Bound execution times
• Bound queue size
• Resource Management
• Introduce concurrency
• Maintain multiple copies of data or computations
• Increase available resources
• Resource Arbitration ? Scheduling Policy

14
Security

• Ability to resist unauthorized use.
• Non-repudiation
• Confidentiality
• Integrity
• Assurance
• Availability
• Auditing

15
Security Tactics

• Resisting Attacks
• Authenticate users
• Authorize users
• Maintain data confidentiality (encryption)
• Maintain integrity (checksum, CRC)
• Limit exposure (firewall)
• Detecting Attacks
• Recovering From Attacks
• Audit trail

16
Testability

• Ease with which software can be made to
  demonstrate its faults through testing
• Tactics presented are concerned with testing a
  running system.

17
Testability Tactics

• Input / Output
• Record / playback
• Separate interface
• Specialized access routes / interfaces
• Internal Monitoring

18
Usability

• How easy a user can accomplish a desired task
  with the software
• Learning system features
• Using a system efficiently
• Minimizing impact of errors
• Adapting system to user needs
• Increasing confidence and satisfaction

19
Usability Tactics

• Runtime Tactics
• User Initiative
• User control ? undo, cancel
• System Initiative
• Provide user feedback
• Limit operations based on user expectations
• Design-time Tactics
• Separate user interface from business logic
• MVC

20
Tactics and Architectural Patterns

• An architect will choose a pattern or collection
  of patterns to realize one or more tactics.
• Each pattern implements multiple tactics whether
  desired or not.
• Examples

21
Architectural Patterns or Styles

• A few key features, and rules for combining them
• A set of element types
• A topological layout
• A set of semantic constraints
• A set of interaction mechanisms