1. Lecture 13 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor

2. 2 Types of Scenarios

3. 3 Usage of scenarios

4. 4 Availability General Scenario

5. 5 Sample Availability Scenario Artifact: Process Source: External to System Environme nt: Normal Operation Response Measure: No Downtime Stimulus: Unanticipat ed message Response: Inform Operator to Continue

6. 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. 7 Specifying Requirements

8. 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. 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. 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. 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. 12 Performance Timing –Events, interrupts, messages, requests… –Measuring time between arrival and response Complicated by –Large # of possible sequences and combos

13. 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. 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. 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. 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. 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. 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. 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

20. Tactics

21. 21 Tactics & Strategies Tactic – Fundamental design decisions that impart desired quality attributes to a design Architectural Strategy – A collection of tactics

22. 22 Example

23. 23 Where to Tactics Fit in? Idea about System Important Qualities Focus with Quality Scenarios Tactics form 1 st broad brush strokes

24. 24 Organizing Tactics

25. 25 Availability Tactics

26. 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. 27 Availability: Fault Detection Ping/Echo Heartbeat/Watchdog Exceptions

28. 28 Availability: Fault Recovery Prevention and Repair –Voting –Active Redundancy (Two parallel systems) –Passive Redundancy (Master & backup components) –Spare Reintroduction –Checkpoint/Rollback

29. 29 Availability: Fault Prevention Removal from service to prevent failures Transactions Monitor processes for faults and create replacement processes

30. 30 Availability Tactics

31. 31 Modifiability Tactics

32. 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. 33 Modifiability: Localize Modifications Maintain semantic coherence –Coupling and cohesion Anticipate expected changes Generalize

34. 34 Modifiability: Prevent Ripple Hide information Maintain existing interfaces Restrict communication paths Use an intermediary

35. 35 Modifiability: Defer Binding Time Runtime registration Configuration files Polymorphism Component replacement Define protocols

36. 36 Modifiability Tactics

37. 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