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
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:
Figure taken from http://www.sei.cmu.edu/ata/ata_method.html Conceptual Flow ATAM Figure taken from http://www.sei.cmu.edu/ata/ata_method.html
Grok Google grok ftp site Gunzip Tar xvf
Stimuli
Architectural Decisions
Availability Characterization
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?
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?
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)?
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?
Availability Characterization
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?
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?
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?
Modifiability Characterization
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?
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?
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?
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
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
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
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
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
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
Layered view of the OLTM (Online Transaction Manager)
Communication, data flow of OLTM
Data Flow Architectural View of the OLTM
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
Generate Quality Attribute Utility Tree Table 11.5
Utility Tree continued
Utility Tree continued
Utility Tree continued
Step 9 Present results
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
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.
References “Evaluating Software Architectures: Methods and Case Studies” by Clements, Kazman and Klein, published by Addison-Wesley, 2002. Part of the SEI Series in Software Engineering. SEI Software Architecture publications http://www.sei.cmu.edu