Software Architecture Quality Attributes. Good or Bad? Measurable criterions required...

Slides:



Advertisements
Similar presentations
Unit Testing in the OO Context(Chapter 19-Roger P)
Advertisements

DAIMI(c) Henrik Bærbak Christensen1 Software Architecture Quality Attributes.
Executional Architecture
DAIMIHenrik Bærbak Christensen1 Testability Tactics How to make software testable...
Quality Attributes Or, what’s wrong with this: Exterminator kit – place bug on block, strike with mallet.
Instructor: Tasneem Darwish
SWE Introduction to Software Engineering
Design Patterns CS is not simply about programming
Evaluating Software Architectures RiSE’s Seminars Clement’s book :: Chapters 05 Eduardo Cruz.
DAIMIHenrik Bærbak Christensen1 What is Software Quality?
1 Software Testing and Quality Assurance Lecture 40 – Software Quality Assurance.
1 Software Testing and Quality Assurance Lecture 30 – Testing Systems.
Evaluating Architectures Quality control: rarely fun, but always necessary
Systems Design. Analysis involves understanding and documenting user requirements in a clear and unambiguous way. It focuses on the business side and.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Non-functional requirements
Oracle High Availability Doug Smith CIS 764 Fall Semester 2007.
Objektorienteret netværkskommunikation Presentation: Architectures for Distributed Systems.
Software Project Management Fifth Edition
 The software systems must do what they are supposed to do. “do the right things”  They must perform these specific tasks correctly or satisfactorily.
1 Computer Systems & Architecture Lesson 2 3. Understanding Quality Attributes.
ITEC224 Database Programming
An Introduction to Software Architecture
CSE 303 – Software Design and Architecture
Eng. Mohammed Timraz Electronics & Communication Engineer University of Palestine Faculty of Engineering and Urban planning Software Engineering Department.
Software Software is omnipresent in the lives of billions of human beings. Software is an important component of the emerging knowledge based service.
Design (1) Design involves decisions on how to deliver the agreed functionality to the users. Design involves development of a clear, unambiguous and consistent.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
This chapter is extracted from Sommerville’s slides. Text book chapter
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
1 Software Engineering Ian Sommerville th edition Instructor: Mrs. Eman ElAjrami University Of Palestine.
1 Software Architecture in Practice Quality attributes.
Introduction to Software Engineering. Why SE? Software crisis manifested itself in several ways [1]: ◦ Project running over-time. ◦ Project running over-budget.
Presentation: Architectural Design for Distributed Systems Objektorienteret netværkskom.
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Chapter 13: Software Quality Project Management Afnan Albahli.
6/23/2005 R. GARDNER OSG Baseline Services 1 OSG Baseline Services In my talk I’d like to discuss two questions:  What capabilities are we aiming for.
Test Stubs... getting the world under control. TDD of State Pattern To implement GammaTown requirements I CS, AUHenrik Bærbak Christensen2.
Evaluating Architectures. Quality Control Rarely fun, but always necessary 1.
CS 350 – Software Design Expanding Our Horizons – Chapter 8 The traditional view of objects is that they are data with methods. Sometimes objects could.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
# 1 AMI Enterprise Task Force of the Utility AMI Working Group SRS Team Plan Discussion For further information, contact Joe Zhou Team Lead
1 Software Architecture in Practice Quality attributes (The amputated version)
Cloud Computing and Architecture Architectural Tactics (Tonight’s guest star: Availability)
Review of Parnas’ Criteria for Decomposing Systems into Modules Zheng Wang, Yuan Zhang Michigan State University 04/19/2002.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Multi Dimensional Variance: How to make ultra flexible software!
Refactoring and Integration Testing or Strategy, introduced reliably by TDD The power of automated tests.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
2005WICSA Towards an Operational Framework for Architectural Prototyping Klaus Marius Hansen Henrik Bærbak Christensen Author Department of Computer.
CSHenrik Bærbak Christensen1 Flexibility and Maintainability And their metrics: coupling and cohesion.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
Software Architecture in Practice Architectural Prototyping.
Software Architecture in Practice A few notes on H1.
ISS Team Group Member ◦ Nguy ễ n Nh ậ t Minh ◦ Nguy ễ n Kh ắ c Khu ◦ Ph ạ m Ng ọ c Hi ế u ◦ Nguy ễ n Ng ọ c Khánh ◦ Nguy.
Software Architecture in Practice
Scalability: Load Balancing
Software Architecture in Practice
Software Architecture Quality Attributes
Software engineering.
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Software Engineering and Architecture
From Use Cases to Implementation
Presentation transcript:

Software Architecture Quality Attributes

Good or Bad? Measurable criterions required...

Henrik Bærbak Christensen3 What does “good” mean? Question: Is this little C program an example of good or bad software? Exercise 1: Argue that this is a good program! Exercise 2: Argue that this is a bad program ! int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z-- ;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79- 77?1:0:p 158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q ;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Henrik Bærbak Christensen4 (What did the C program do?)

Henrik Bærbak Christensen5 The need for measuring The server should be highly available... My software is really reusable! Our high performance server will... These are simply claims Actual measurements on well defined scale is better...

Henrik Bærbak Christensen6 Quality Attributes The problem about ”good” or ”bad” is that they are subjective measures... We need to measure our software. This requires –that we define the aspects/qualities we measure –that we agree on some kind of scale: a metric Quality attributes (da: kvalitets-attributter)

Henrik Bærbak Christensen7 Measuring quality Performance Maintainability Usability Quality Attribute Metric Measurement Choose alternatives Quality Framework

Henrik Bærbak Christensen8 ’Quality communities’ One aspects of qualities is that most of them have dedicated research communities associated: –performance freaks (algorithm people, database,...) –usability freaks (HCI – human computer interface ) –security freaks –cost freaks (managers ) –reusability freaks (pattern community )...which has lead to lack of common vocabulary… –user input, attack, event, failures, are all stimulus We need to provide common ground

Henrik Bærbak Christensen9 SAiP’s Contribution The book Software Architecture in Practice has defined a framework that allow different architecturally qualities to be expressed in a similar form: A quality framework Quality Attributes: Set of qualities to consider Quality Metric: A technique for measuring them

Henrik Bærbak Christensen10 Quality framework (Bass et al.) System quality attributes –Availability –Modifiability –Performance –Security –Testability –Usability –Interoperability –Scalability –Deployability –… Business qualities –Time to market –Cost –Projected lifetime –Targeted market –Roll-out schedule –Integration with legacy sys. Architectural qualities –Conceptual integrity –Correctness and completeness –Buildability

Henrik Bærbak Christensen11 Exercise System quality attributes –Availability –Modifiability –Performance –Security –Testability –Usability Business qualities –Time to market –Cost –Projected lifetime –Targeted market –Roll-out schedule –Integration with legacy sys. Architectural qualities –Conceptual integrity –Correctness and completeness –Buildability Which of these will have the greatest impact on your professional and personal lives?

The System Qualities Availability –Concerned with the probability that the system will be operational when needed Modifiability –Concerned with the ease with which the system supports change Performance –Concerned with how long it takes the system to respond when an event occurs Henrik Bærbak Christensen12

The System Qualities Security –Concerned with the systems ability to withstand attacks/threats Testability –Concerned with the ease with which the software can be made to demonstrate its faults Usability –Concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides Henrik Bærbak Christensen13

“We want them all” Qualities in conflict

Henrik Bærbak Christensen15 The conflict of qualities Many qualities are in direct conflict – they must be balanced ! –modifiability and performance many delegations costs in execution speed – and memory footprint –cost and reusability highly flexible software costs time, effort, and money –security and availability availability through redundancy – increase opportunities of attack –etc.

Design Patterns in Perspective Examples of Good turning Bad

Henrik Bærbak Christensen17 Iteration In a distributed system, the clients need to iterate over all order lines in a order object... Using RMI – Remote Method Invocation – the code looks exactly the same even when the Order object is on the server side !!! Great! Iterator is a nice, flexible, design pattern Iterator i = order.iterator(); while ( i.hasNext() ) { OrderLine entry = (OrderLine) i.next(); [process entry] }

Henrik Bærbak Christensen18 The sequence diagram All is fine...

Henrik Bærbak Christensen19... but Let us consider the deployment of objects

Henrik Bærbak Christensen20... what about performance ? Message-call is much more expensive over a network –2002 data: msg/sec local; 220 msg/sec remote –90-times slow-down – probably even worse today. The iterator pattern ensures an extreme slow- down compared to transfering all order line objects in a single network package !

Henrik Bærbak Christensen21 Another example... Singleton –Ensure a class only has one instance, and provide a global point of access to it. However, a singleton in a distributed system is a major headache! –one server becomes two servers with a load balancer for scalability now there are two singletons ! –really only one singleton a major performance bottle-neck to ensure the system will never ever scale ! Actually – many consider singleton an anti-pattern!

Maintainability in Details A key quality in design patterns, frameworks, and compositional designs... (Repeating a previous slides show ) Henrik Bærbak Christensen22

Henrik Bærbak Christensen23 The Bass Framework The Bass framework is rather coarse grained. Another, much more detailed, framework is the ISO 9126 standard. In particular it restate most qualities into sub qualities.

Sub Qualities of Maintainability Compare: cost of ease of change (Bass et al.) Henrik Bærbak Christensen24

Analyzability Examples: –The Account program Henrik Bærbak Christensen25

Changeability Examples –The size of the Maze program is only present in terms of magic numbers –Consider using constants like MAZE_WIDTH instead –Delegation based techniques to encapsulate variability Henrik Bærbak Christensen26

Stability War story –Person ID in ABC ID = RFID tag; used by inference engine to detect ”activities” Later a student programmer changed it CPR –Nothing worked during a demo for the physicians  Henrik Bærbak Christensen27

Testability Examples –The GammaTown pay station rate strategy –... And lots of others Henrik Bærbak Christensen28

Flexibility Note: Not an ISO definition, but my own Examples –Almost everything in my book... Henrik Bærbak Christensen29

Summary Architectural Qualities: Maintainability is just one of several qualities of a software system –Qualities often are in conflict –Software architect must find the proper balance between them –Maintainability (= techniques from this course) are not necessarily a primary driver! Maintainability –Has sub qualities Stability, changeability, testability, analyzability –Flexiblity: change by addition, not by modification... Henrik Bærbak Christensen30

Summary There is no good or bad software! –There is software that measure differently on the different qualities Fast but difficult to change Maintainable but performs less Etc. OK, OK: Software that is not maintainable, performs lousy, is insecure, unreliable… is bad software… Henrik Bærbak Christensen31