1 Ying SHEN SSE, Tongji UniversityQuality Attributes Ying SHEN SSE, Tongji University

2 Lecture objectives This lecture will enable students tobe familiar with different system qualities and examples through a real project (ICDE system).

3 Architecture and requirementsAll requirements encompass the following categories: Functional requirements Quality attribute requirements Constraints Requirements for a system come in a variety of forms: textual requirements, mockups, existing systems, use cases, user stories, and more Functional requirements. These requirements state what the system must do, and how it must behave or react to runtime stimuli. 2. Quality attribute requirements. These requirements are qualifications of the functional requirements or of the overall product. A qualification of a functional requirement is an item such as how fast the function must be performed, or how resilient it must be to erroneous input. A qualification of the overall product is an item such as the time to deploy the product or a limitation on operational costs. 3. Constraints. A constraint is a design decision with zero degrees of freedom. That is, it's a design decision that's already been made. Examples include the requirement to use a certain programming language or to reuse a certain existing module, or a management fiat to make your system service oriented. These choices are arguably in the purview of the architect, but external factors (such as not being able to train the staff in a new language, or having a business agreement with a software supplier, or pushing business goals of service interoperability) have led those in power to dictate these design outcomes.

4 Functional requirementsFunctional requirements state what the system must do, and how it must behave or react to runtime stimuli. Functionality does not determine architecture. If functionality is the only requirement, a single monolithic module works! Although functionality is independent of structure, it is achieved by assigning responsibilities to architectural elements. Functionality is the ability of the system to do the work for which it was intended Assigning responsibilities to architectural elements is a fundamental architectural design decision.

5 Quality attribute requirementsQuality attribute (QA) requirements are qualifications of the functional requirements or of the overall product. A quality attribute can be regarded as measuring the “goodness” of a product along some dimension of interest to a stakeholder. A quality attribute (QA) is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders

6 Quality attributes QAs specify how well the system performs its functions: How fast must it respond? How easy must it be to use? How secure does it have to be against attacks? How easy should it be to maintain? Software qualities are not orthogonal. A change in structure that improves one quality often affects the other qualities.

7 Constraints A constraint is a design decision with zero degrees of freedom. Use a certain programming language or to reuse a certain existing module These choices are arguably in the purview of the architect, but external factors (such as not being able to train the staff in a new language, or having a business agreement with a software supplier, or pushing business goals of service interoperability) have led those in power to dictate these design outcomes.

8 A Case Study in Quality AttributeFrom Essential Software Architecture

9 ICDE system Information Capture and Dissemination Environment (ICDE) is a software system for providing intelligent assistance to financial analysts scientific researchers intelligence analysts analysts in other domains

10 ICDE schematic

11 ICDE system ICDE automatically captures and stores data of actions performed by a user when operating a workstation. Example: When a user performing Google search, ICDE will store in a database: The search query string List of returned pages displayed in the browser Data can be later used by 3rd parties to offer intelligent help to find potentially useful details overlooked by users

12 ICDE use cases

13 ICDE version 1.0 ICDE Version 1.0 application architectureAnalyst Workstation Data Collection Data Analysis Data Store ICDE Version 1.0 application architecture

14 Data collection The collection component comprises a number of loosely coupled processes that transparently track the user’s relevant activities and store them in the Data Store.

15 Data store This component comprises a commercial-off-the-shelf (COTS) relational database. The relational database stores information in various tables regarding the user activities, with timestamps added so that the order of events can be reconstructed.

16 Data analysis A graphical user interface (GUI) based tool supports a set of queries on the data store.

17 ICDE version 1.0 ICDE version 1.0 in productionBasically a complex, raw information capture tool, GUI for looking at captured data 2 tier client-server, single machine deployment Java, Perl, SQL, Programmatic access to data through very complex SQL (38 tables, 46 views) ICDE v1.0 was only deployed in a small user trial involving a few users. This deployment successfully tested the software functionality and demonstrated the concepts of data capture and storage.

18 ICDE version 2.0 ICDE v2.0 scheduled for development in 12 month timeframe Fixed schedule, budget Major changes to: Enhance data capture tools (GUI) Support 3rd party tool integration, testing, data access and large production scale deployments (150’s of users)

19 ICDE version 2.0 Business goals:

20 Architecturally significant requirements for ICDE v2.0ICDE project requirements: Heterogeneous platform support for access to ICDE data Instantaneous event notification (local/distributed) Over the Internet, secure ICDE data access Ease of programmatic data access ICDE project team requirements: Insulate 3rd party projects and ICDE tools from database evolution Scalable infrastructure to support large, shared deployments Minimize license costs for a deployment Unknowns Minimize dependencies, making unanticipated changes potentially easier

21 Summary ICDE is a reasonably complex system It will be used to illustrate concepts during the remainder of this course

22 What are quality attributesOften know as –ilities Reliability Availability Portability Scalability Performance

23 Quality attribute specificationArchitects are often told: “My application must be fast/secure/scale” Far too imprecise to be any use at all Quality attributes (QAs) must be made precise/measurable for a given system design, e.g. “It must be possible to scale the deployment from an initial geographically dispersed user desktops to 10,000 without an increase in effort/cost for installation and configuration.”

24 QAs of ICDE system Any other quality attributes?Performance Scalability Modifiability Security Availability Integration Any other quality attributes?

25 Performance A performance quality requirement defines a:metric of amount of work performed in unit time deadline that must be met Enterprise applications often have strict performance requirements, e.g. 1000 transactions per second 3 second average latency for a request Performance is fundamental for software system.

26 Performance - ThroughputMeasure of the amount of work an application must perform in unit time Transactions per second Messages per minute Is required throughput: Average? Peak? Many system have low average but high peak throughput requirements

27 Performance - Response timeMeasure of the latency an application exhibits in processing a request Usually measured in (milli)seconds Often an important metric for users Is required response time: Guaranteed? Average? E.g. 95% of responses in sub-4 seconds, and all within 10 seconds

28 Performance - Deadlines‘Something must be completed before some specified time’ Payroll system must complete by 2 am so that electronic transfers can be sent to bank Weekly accounting run must complete by 6 am Monday so that figures are available to management Deadlines often associated with batch jobs in IT systems.

29 ICDE performance issuesResponse time: Overheads of trapping user events must be imperceptible to ICDE users Solution for ICDE client: Decouple user event capture from storage using a queue 5. Write event to ICDE database queue 2. Write event to queue 1. Trap user event 3. Return to user thread 4. Read event from queue

30 Scalability “How well a solution to some problem will work when the size of the problem increases.” 4 common scalability issues in IT systems: Request load Connections Data size Deployments

31 Scalability – Request loadHow does an 100 tps application behave when simultaneous request load grows? E.g. From 100 to 1000 requests per second? Ideal solution, without additional hardware capacity: As the load increases, throughput remains constant (i.e tps), and response time per request increases only linearly (i.e. 10 seconds).

32 Scalability – Add more hardware …Application CPU Scale-up: Single application instance is executed on a multiprocessor machine Scale-out: Application replicated on different machines

33 Scalability - Reality Adding more hardware should improve performance:Scalability must be achieved without modifications to application architecture Reality as always is different! Applications will exhibit a decrease in throughput and a subsequent exponential increase in response time. Increased load causes increased contention for resources such as CPU, network and memory Each request consumes some additional resource (buffer space, locks, and so on) in the application, and eventually these are exhausted

34 Scalability – J2EE exampleI.Gorton, A Liu, Performance Evaluation of Alternative Component Architectures for Enterprise JavaBean Applications, in IEEE Internet Computing, vol.7, no. 3, pages 18-23, 2003.

35 Scalability – ConnectionsWhat happens if number of simultaneous connections to an application increases If each connection consumes a resource? Exceed maximum number of connections? ISP example: Each user connection spawned a new process Virtual memory on each server exceeded at 2000 users Needed to support 100Ks of users Tech crash …. An Internet service provider (ISP) is an organization that provides services for accessing, using, or participating in the Internet. Internet services typically provided by ISPs include Internet access, Internet transit, domain nameregistration, web hosting, Usenet service, colocation.

36 Scalability – Data sizeHow does an application behave as the data it processes increases in size? Chat application sees average message size double? Database table size grows from 1 million to 20 million rows? Image analysis algorithm processes images of 100MB instead of 1MB? Can application/algorithms scale to handle increased data requirements?

37 Scalability – DeploymentHow does effort to install/deploy an application increase as installation base grows? Install new users? Install new servers? Solutions typically revolve around automatic download/installation E.g. downloading applications from the Internet

38 Scalability thoughts and ICDEScalability often overlooked. Major cause of application failure Hard to predict Hard to test/validate Reliance on proven designs and technologies is essential For ICDE - application should be capable of handling a peak load of 150 concurrent requests from ICDE clients. Relatively easy to simulate user load to validate this

39 Modifiability Modifications to a software system during its lifetime are a fact of life. Modifiable systems are easier to change/evolve. Modifiability should be assessed in context of how a system is likely to change No need to facilitate changes that are highly unlikely to occur Over-engineering!

40 Modifiability Modifiability measures how easy it may be to change an application to cater for new (non-)functional requirements. ‘may’ – nearly always impossible to be certain Must estimate cost/effort Modifiability measures are only relevant in the context of a given architectural solution. Components Relationships Responsibilities

41 Modifiability scenariosProvide access to the application through firewalls in addition to existing “behind the firewall” access. Incorporate new features for self-service check-out kiosks. The COTS speech recognition software vendor goes out of business and we need to replace this component. The application needs to be ported from Linux to the Microsoft Windows platform.

42 Modifiability analysisImpact is rarely easy to quantify. The best possible is a: Convincing impact analysis of changes needed A demonstration of how the solution can accommodate the modification without change. Minimizing dependencies increases modifiability Changes isolated to single components likely to be less expensive than those that cause ripple effects across the architecture.

43 Modifiability for ICDEThe range of events trapped and stored by the ICDE client to be expanded. Third party tools to communicate new message types. Change database technology used Change server technology used

44 Security Difficult, specialized quality attribute:Lots of technology available Requires deep knowledge of approaches and solutions Security is a multi-faceted quality …

45 Security Authentication:Applications can verify the identity of their users and other applications with which they communicate. Authorization: Authenticated users and applications have defined access rights to the resources of the system. Encryption: The messages sent to/from the application are encrypted. Integrity: This ensures the contents of a message are not altered in transit. Non-repudiation: The sender of a message has proof of delivery and the receiver is assured of the sender’s identity. This means neither can subsequently refute their participation in the message exchange.

46 Security approaches SSL PKI Web Services security JAAS Operating system security Database security Etc etc SSL stands for Secure Sockets Layer. It provides a secure connection between internet browsers and websites, allowing you to transmit private data online. Sites secured with SSL display a padlock in the browsers URL and possibly a green address bar if secured by an EV Certificate. Public key cryptography is a cryptographic technique that enables users to securely communicate on an insecure public network, and reliably verify the identity of a user viadigital signatures.[2] A public key infrastructure (PKI) is a system for the creation, storage, and distribution of digital certificates which are used to verify that a particular public key belongs to a certain entity. The PKI creates digital certificates which map public keys to entities, securely stores these certificates in a central repository and revokes them if needed.[3][4][5] WS-Security describes three main mechanisms: How to sign SOAP messages to assure integrity. Signed messages also provide non-repudiation. How to encrypt SOAP messages to assure confidentiality. How to attach security tokens to ascertain the sender's identity. The Java Authentication and Authorization Service (JAAS) was introduced as an optional package (extension) to the Java 2 SDK, Standard Edition (J2SDK), v 1.3. JAAS was integrated into the J2SDK 1.4. JAAS can be used for two purposes: for authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet; and for authorization of users to ensure they have the access control rights (permissions) required to do the actions performed. Operating system security (OS security) is the process of ensuring OS integrity, confidentiality and availability. OS security refers to specified steps or measures used to protect the OS from threats, viruses, worms, malware or remote hacker intrusions. OS security encompasses all preventive-control techniques, which safeguard any computer assets capable of being stolen, edited or deleted if OS security is compromised.

47 ICDE security requirementsAuthentication of ICDE users and third party ICDE tools to ICDE server. Encryption of data to ICDE server from 3rd party tools/users executing remotely over an insecure network

48 Availability Key requirement for most IT applicationsMeasured by the proportion of the required time it is usable. E.g. 100% available during business hours No more than 2 hours scheduled downtime per week 24*7*52 (100% availability) Related to an application’s reliability Unreliable applications suffer poor availability Related to recoverability

49 Availability Period of loss of availability determined by:Time to detect failure Time to correct failure Time to restart application 𝑀𝑇𝐵𝐹 𝑀𝑇𝐵𝐹+𝑀𝑇𝑇𝑅

50 Availability High availability typically refers to designs targeting availability of percent (“5 nines”) or greater. Strategies for high availability: Eliminate single points of failure Replication and failover Automatic detection and restart percent availability

51 Availability System Availability Requirements AvailabilityDowntime/90 Days Downtime/Year 99.0% 21 hours, 36 minutes 3 days, 15.6 hours 99.9% 2 hours, 10 minutes 8 hours, 0 minutes, 46 seconds 99.99% 12 minutes, 58 seconds 52 minutes, 34 seconds 99.999% 1 minute, 18 seconds 5 minutes, 15 seconds 8 seconds 32 seconds

52 Availability for ICDE Achieve 100% availability during business hours Plenty of scope for downtime for system upgrade, backup and maintenance. Include mechanisms for component replication and failover

53 Integration Ease with which an application can be incorporated into a broader application context Use component in ways that the designer did not originally anticipate Typically achieved by: Programmatic APIs Data integration

54 Integration strategiesData – expose application data for access by other components API – offers services to read/write application data through an abstracted interface Each has strengths and weaknesses …

55 ICDE integration needsRevolve around the need to support third party analysis tools. Well-defined and understood mechanism for third party tools to access data in the ICDE data store.

56 Design trade-offs QAs are rarely orthogonalThey interact, affect each other Highly secure system may be difficult to integrate Highly available application may trade-off lower performance for greater availability High performance application may be tied to a given platform, and hence not be easily portable Architects must create solutions that makes sensible design compromises not possible to fully satisfy all competing requirements Must satisfy all stakeholder needs This is the difficult bit!

57 Summary QAs are part of an application’s nonfunctional requirementsMany QAs Architect must decide which are important for a given application Understand implications for application Understand competing requirements and tradeoffs

58 Discussion question How many other qualities of software can you name that were not covered in this lecture? With which other qualities does it most often interact?

59 Misc. quality attributesPortability Can an application be easily executed on a different software/hardware platform to the one it has been developed for? Testability How easy or difficult is an application to test? Supportability How easy an application is to support once it is deployed? Usability