1. Lecture 12z ATAM Case Study Nightingale System
CSCE 742 Software Architectures
Lecture 12z ATAM Case Study Nightingale System
Topics
Evaluating Software Architectures
What an evaluation should tell
What can be examined, What Can’t
ATAM
Next Time: Case Study: the Nightingale System
Ref: The “Evaluating Architectures” book and Chap 11
June 21, 2017

2. Overview Last Time New: Analysis of Architectures Next time:
Why, When, Cost/Benefits
Techniques
Properties of Successful Evaluations
New: Analysis of Architectures
Next time:
References:

3. Figure taken from http://www.sei.cmu.edu/ata/ata_method.html
Conceptual Flow ATAM
Figure taken from

4. Grok
Google grok
ftp site
Gunzip
Tar xvf

5. Stimuli

6. Architectural Decisions

7. Availability Characterization

8. Questions: Performance-Related Stimuli
What is the client loading in terms of the number of concurrent sessions?
How would you characterize the event model (periodic or stochastic)?
What internal state changes trigger computations?

9. Questions: Performance-Related Architectural Decisions
Are the server processors single-(nonpreemptable) or multithreaded (preemptable)?
How are (fixed or dynamic) priorities assigned to processes?
Are processes statically or dynamically allocated to hardware?
What is the physical distribution of the hardware and Its connectivity?
What are the bandwidth characteristics of the network?
How is arbitration done in the network?
Do you use synchronous or asynchronous protocols?

10. Questions: Performance-Related Architectural Decisions (continued)
What is the location of firewalls and their impact on bandwidth?
How are resources allocated to service requests? !
What internal state changes trigger
If there are multiple processes/threads competing for a shared resource, how are
priorities assigned to these processes/ threads and the process/thread controlling the shared resource?
Are there any relatively slow communication channels along an important communication path (e.g., a modem)?

11. Questions: Performance-Related Responses
What is the performance impact of a thin versus a thick client in terms of latency or throughput?
What are the performance characteristics of the middleware? What are the effects of load balancing and arbitration on throughput?
Are there any computations that must be performed in a specific order?

12. Availability Characterization

13. Availability-Related Stimuli
How are hardware and software failuresidentified?
Can active as well as passive failures be identified?
If redundancy is used in the architecture, are there any common-mode failures?
Availability-Related of other components?
Architectural Decisions
If redundancy is used in the architecture, used to detect dead components? what type of redundancy (analytic, Availability-Related Responses
. replication, functional)?
Athd'
How do you know that all critical components have been replicated?
If live redundant components are used in the architecture, how does the system
choose when their results differ?
Does one component detect the failure
Is there any kind of system "heartbear
re ere I eren eve so service
If redundancy is used in the architecture, available? How are these characterized? how long does it take to switch between '- -
instances of a redundant component? If a backing store IS used, how .QuIckly can a backup be made and how quIckly can If redundancy is used in the architecture, state be restored from the backup? how many replicas of each critical
component and connection are used?

14. Availability-Related Architectural Decisions
If redundancy is used in the architecture, used to detect dead components? what type of redundancy (analytic, replication, functional)?
If redundancy is used in the architecture, how long does it take to switch between instances of a redundant component?
If redundancy is used in the architecture, how many replicas of each critical component and connection are used?
How do you know that all critical components have been replicated?
If live redundant components are used in the architecture, how does the systemchoose when their results differ?
Does one component detect the failure of other components?
Is there any kind of system "heartbeart” to detect dead components?

15. Availability-Related Responses
Are there different levels of service available? How are these characterized?
If a backing store is used, how quickly can a backup be made and how quickly can state be restored from the backup?

16. Modifiability Characterization

17. Modifiability-Related Stimuli
What new functionality do you anticipate adding in future versions of the system?
Do you anticipate the need for making your system more secure in the future?
How do you plan to handle migration to new releases of your operating system?

18. Modifiability-Related Architectural Decisions
Do any components have access to the implementation details of global variables?
Do you use Indirection mechanisms such as 'publisher/subscriber’?
How do you handle the possibility of changes in message formats?
Are Implementation details or low-level services ever exposed to enhance performance?

19. Modifiability-Related Responses
How many interfaces will change as a consequence of a change to some functionality?
Do changes to your user interface affect application modules?
What changes will result from adding a source of data such as a new sensor or user input field?
What is the impact of a change in functionality on the ability to meet performance requirements?
How many components, connectors, and Interfaces will be affected by removing obsolete data from the data repository?
How much will It cost to change from a uniprocessor to a multiprocessor platform?
How long do you anticipate it will take to deploy your change?

20. Case Study: The Nightingale System
Phase 0:
Major producer of health care systems read web site and called
Large system, millions of lines of code
Well into implementation, already has first customer
Why now?
Better sooner than later and plan to sell many copies
To serve as information backbone at hospitals etc.
Negotiations took about a month
Team of 6 members
Kickoff day:
Evaluation team, project manager, lead architect, project manager for first customer
Documentation incomplete and unclear
Fill in the gaps with the architect

21. Nightingale: Phase 1 Meeting consisted of Step 1: Present the ATAM
Team
Lead architect
Project manager
Project manager of first customer
Two lead designers
Step 1: Present the ATAM
Used standard viewgraph presentation
1 hour long
Most had heard some of it in kickoff meeting, no problems

22. Nightingale: Phase 1 Step 2: Present Business Drivers
Customer Project manager presented the business objective of the Nightingale system
Business requirements
Support first customer’s diverse uses
Treatment tracking
Payment histories
Trend spotting
Creation of new version for doctor’s offices (product line)
Replace old legacy system

23. Nightingale: Phase 1 First Customer’s Business requirements
Ability to deal with diverse cultural and regional differences
Multiple languages
New system as fast as legacy system
New system combines distinct legacy financial systems
Business Constraints for the system
No lost jobs commitment  retraining
Adoption of buy rather than build
Recognition that the customer’s marketplace had shrunk
Technical constraints
Use COTS wherever possible
Two year development time frame with upgrades in hardware every 26 weeks

24. Nightingale: Phase 1 Quality Attributes rated as high priority
Performance
Usability –
high turnover of users  high training costs
Maintainability
Quality Attributes rated somewhat lower priority
Security
Scalability
Modularity
Testability and supportability

25. Nightingale: Phase 1 Step 3 Present the architecture
Nightingale consisted of two major subsytems
Online transaction manager (OLTM)
Decision support and report Generation Manager (DSRGM)
Nightingale was highly configurable
OLTM was strongly layered
Repository based system
Relied on COTS
Central DB, a rules engine, a work flow engine, CORBA, web engine, software distribution tool
Heavily Object Oriented

26. Layered view of the OLTM (Online Transaction Manager)

27. Communication, data flow of OLTM

28. Data Flow Architectural View of the OLTM

29. Catalog Architectural Approaches
Layering especially in OLTM
Object Oriented
Use of Configuration files
Client-server transaction processing
A data-centric architectural pattern, with large DB

30. Generate Quality Attribute Utility Tree
Table 11.5

31. Utility Tree continued

32. Utility Tree continued

33. Utility Tree continued

41. Step 9 Present results

42. Three Risk Themes Over-reliance on specific COTS products.
Error recovery processes were not fully defined. The customer’s knowledge of available tools was incomplete.
Documentation issues

43. PHASE 3: FOLLOW-UP final report that contains: a list of risks,
nonrisks,
sensitivity points, and
tradeoff points.
a catalog of architectural approaches used,
the utility tree and
brainstormed scenarios, and the record of analysis of each selected scenario.
the set of risk themes identified by the evaluation team and an indication of which business drivers are jeopardized by each one.

44. References
“Evaluating Software Architectures: Methods and Case Studies” by Clements, Kazman and Klein, published by Addison-Wesley, Part of the SEI Series in Software Engineering.
SEI Software Architecture publications