Lecture 13

Enterprise

Systems

Development( CSC447)

COMSATS Islamabad

Muhammad Usman, Assistant Professor

2

Types of Scenarios

3

Usage of scenarios

4

Availability General Scenario

5

Sample Availability Scenario

Artifact:Process

Source:External to

System

Environment:

Normal Operation

Response Measure:

No Downtime

Stimulus:Unanticipated message

Response:Inform

Operator to Continue

6

Example: Modifiabilty

Artifact:Code

Source:Developer Environme

nt:At Design

Time

Response Measure:In three hours

Stimulus:Wishes to change UI

Response:Modificatio

n made with no side

effects

7

Specifying Requirements

8

Availability

• Fault = Something went wrong or was unexpected• Failure = System is unavailable• Note: Can talk about degraded modes of operation ~

degrees of availability• In considering availability must consider mean time to

failure plus recovery time

9

General Scenarios for Availability• Source – Internal or External?• Stimulus – omission, crash, timing, response• Artifact – what should be available?• Environment – State/Mode of system• Response – What is the desired response? (logging,

restart)• Response Measure – Time intervals or repair time

10

Modifiability

• Chief concerns– What can change?– Who makes the change? What is the change mechanism

and binding time?» Ex: Change the code vs change configuration file

11

General Scenarios for Modifiability• Source – User, developer, sys admin…• Stimulus – Wishes to add/delete/mod

functionality/quality attribute/capacity• Artifact – UI, Platform, environment,…• Environment – run, compile, build, design• Response – Locates section of architecture, makes

modification,…• Response Measure – Cost, effort, time, ripple

12

Performance

• Timing– Events, interrupts, messages, requests…– Measuring time between arrival and response

• Complicated by– Large # of possible sequences and combos

13

General Scenarios for Performance• Source – where does event come from?• Stimulus – characterize arrival (sporadic, simultaneous,

periodic)• Artifact – System• Environment – System mode• Response – process event; change mode• Response Measure – Latency, deadline, throughput,

miss rate, data loss

14

Security

• Ability of the system to prevent unauthorized use while allowing authorized use

• Properties– Confidentiality of data from unauthorized access– Integrity (delivered as intended)– Assurance of identity– Availability for authorized use– Auditing

15

Security General Scenarios

• Source – human or another system; anticipated/actual sources important

• Stimulus – The attack• Artifact – Services of system or data• Environment – Mode, firewall status• Response – Granting/withdrawing access• Response Measure – Difficulty of attacks, recovery from

attacks

16

Testability

• How can we find faults in the system?• Is a test harness available?• Can pieces of the system be tested independently and

at different levels of integration?

17

General Scenarios for Testability

• Source – Who performs test• Stimulus – What triggers testing?• Artifact – design, code, part/whole system• Environment – Time at which test occurs• Response – provides access to state, provides results,

etc.• Response Measure – Coverage, effectiveness (prob of

finding error), effort/time to test

18

Usability

• How easy is it for the user to accomplish a desired task?– Learning system features– Using system effectively– Minimizing impact of errors– Adapting to user needs– Increasing confidence & satisfaction

19

General Scenarios for Usability

• Source – User• Stimulus – What the user wants to do• Artifact – System• Environment – Runtime or config time• Response – What the system does• Response Measure – time, tries, number of errors or

solutions, learning curve

Tactics

21

Tactics & Strategies

• Tactic – Fundamental design decisions that impart desired quality attributes to a design

• Architectural Strategy – A collection of tactics

22

Example

23

Where to Tactics Fit in?

Idea about System

Important Qualities

Focus with Quality

ScenariosTactics form 1st

broad brush strokes

24

Organizing Tactics

25

Availability Tactics

26

Availability Tactics

• Goal: Stop a Fault from becoming a Failure

• Fault Detection– How to tell when a fault has occurred?

• Fault Recovery– How to deal with a fault when it occurs?– Preparation and Repair– Recovery and reintroduction

• Fault Prevention– How to stop faults from occurring?

27

Availability: Fault Detection

• Ping/Echo• Heartbeat/Watchdog• Exceptions

28

Availability: Fault Recovery

• Prevention and Repair– Voting– Active Redundancy (Two parallel systems)– Passive Redundancy (Master & backup components)– Spare

• Reintroduction– Checkpoint/Rollback

29

Availability: Fault Prevention

• Removal from service to prevent failures• Transactions• Monitor processes for faults and create replacement

processes

30

Availability Tactics

31

Modifiability Tactics

32

Modifiability Tactics

• Localize modifications– Minimize the # modules that must change

• Prevent ripple effects– Limit necessary modifications to localized modules (those

directly affected)• Control deployment time & cost

– Defer binding time

33

Modifiability: Localize Modifications• Maintain semantic coherence

– Coupling and cohesion• Anticipate expected changes• Generalize

34

Modifiability: Prevent Ripple

• Hide information• Maintain existing interfaces• Restrict communication paths• Use an intermediary

35

Modifiability: Defer Binding Time

• Runtime registration• Configuration files• Polymorphism• Component replacement• Define protocols

36

Modifiability Tactics

37

References

• Bass, L., Clements, P. and Kazman, R., Software Architecture in Practice, Second Edition (2006), Addison-Wesley.

• Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, j., Little, R., Nord, R. and Stafford, J., Documenting Software Architectures: Views and Beyond, 2002, Addison-Wesley. Documenting Software Architectures