Lecture 12z ATAM Case Study Nightingale System

Slides:



Advertisements
Similar presentations
Computer Systems & Architecture Lesson 2 4. Achieving Qualities.
Advertisements

ATAM Architecture Tradeoff Analysis Method
CIS 376 Bruce R. Maxim UM-Dearborn
Distributed Systems Major Design Issues Presented by: Christopher Hector CS8320 – Advanced Operating Systems Spring 2007 – Section 2.6 Presentation Dr.
Adding scalability to legacy PHP web applications Overview Mario A. Valdez-Ramirez.
Objektorienteret Middleware Presentation 2: Distributed Systems – A brush up, and relations to Middleware, Heterogeneity & Transparency.
Distributed components
Managing Data Resources
Web Caching Schemes1 A Survey of Web Caching Schemes for the Internet Jia Wang.
Lecture 17 Architecture Tradeoff Analysis Method ATAM
Evaluating Software Architectures RiSE’s Seminars Clement’s book :: Chapters 05 Eduardo Cruz.
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
Business Intelligence Dr. Mahdi Esmaeili 1. Technical Infrastructure Evaluation Hardware Network Middleware Database Management Systems Tools and Standards.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman
Introduction to Databases Transparencies 1. ©Pearson Education 2009 Objectives Common uses of database systems. Meaning of the term database. Meaning.
1 The Google File System Reporter: You-Wei Zhang.
CPSC 871 John D. McGregor Module 4 Session 3 Architecture Evaluation.
ATAM –Cont’d SEG 3202 N. Elkadri.
Lecture On Database Analysis and Design By- Jesmin Akhter Lecturer, IIT, Jahangirnagar University.
An Introduction to Software Architecture
Week 4 Lecture Part 3 of 3 Database Design Samuel ConnSamuel Conn, Faculty Suggestions for using the Lecture Slides.
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
Week 5 Lecture Distributed Database Management Systems Samuel ConnSamuel Conn, Asst Professor Suggestions for using the Lecture Slides.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
John D. McGregor Class 4 – Initial decomposition
John D. McGregor Architecture Evaluation
1 Object-Oriented Analysis and Design with the Unified Process Figure 13-1 Implementation discipline activities.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
SYSTEMSDESIGNANALYSIS 1 Chapter 21 Implementation Jerry Post Copyright © 1997.
Understanding IT Infrastructure Lecture 9. 2 Announcements Business Case due Thursday Business Analysis teams have been formed Business Analysis Proposals.
Lecture 15 Attribute Driven Design Again Topics ATAM – team expertise and experience needed Chapter 24 Next Time: June 22, 2016 CSCE 742 Software Architecture.
Lecture 15 Attribute Driven Design Again Topics ATAM – team expertise and experience needed Chapter 24 Next Time: June 22, 2016 CSCE 742 Software Architecture.
Chapter 1 Characterization of Distributed Systems
Databases and DBMSs Todd S. Bacastow January 2005.
Lecture 12 Attribute Driven Design Again
Chapter 19: Architecture, Implementation, and Testing
Part 3 Design What does design mean in different fields?
The Client/Server Database Environment
CHAPTER 3 Architectures for Distributed Systems
#01 Client/Server Computing
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 2 Database System Concepts and Architecture.
Chapter 2 Database Environment Pearson Education © 2009.
CS 425/625 Software Engineering Software Evolution
Database Environment Transparencies
Operating Systems : Overview
Chapter 6 – Architectural Design
Architectures of distributed systems Fundamental Models
Software models - Software Architecture Design Patterns
Analysis models and design models
Operating Systems : Overview
Architectures of distributed systems Fundamental Models
An Introduction to Software Architecture
Operating Systems : Overview
Operating Systems : Overview
Vanilson Burégio The Battlefield Control System – The First Case Study in Applying the ATAM Chapter 4 of: Clements, Paul et al., Evaluating.
Chapter 2: Operating-System Structures
Operating Systems : Overview
Architectures of distributed systems
Software Architecture
Software Architecture
Design Yaodong Bi.
Architectures of distributed systems Fundamental Models
Chapter 2: Operating-System Structures
Design.
#01 Client/Server Computing
Information system analysis and design
Presentation transcript:

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