Upload
joleen-adams
View
222
Download
5
Tags:
Embed Size (px)
Citation preview
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