Object-Oriented Architecture &Design – Lecture 3 (of 3)

Advanced Topics

David Woollard

University of Southern CaliforniaComputer Science DepartmentSoftware Architecture Group

California Institute of TechnologyNASA Jet Propulsion Laboratory

Data Management Group

2

Story Arc• Storyline in episodic form• Goal for OOA&D:

Move from requirements to design, reified by a model • OOA&D will be split across 3 lectures

– Lecture 1: Problem Decomposition (9/15)– Lecture 2: UML in Depth (9/29)– Lecture 3: Advanced Topics – NFP, Incomplete Specification,

Relationship to Frameworks, etc. (10/1)• OOA&D Workshop (10/11)

– Interactive session to review your designs

3

From Last Time• UML is an industry standard for documenting software

system design• UML is a LARGE standard (I’m being polite), so this lecture

is intended to be an introduction, not a comprehensive guide

• Use-cases help designers to:– Create sequence diagrams– Tease out objects that will be implemented as classes– Understand class methods

• Rationale tutorial and the design workshop will help to flesh out your designs prior to the ARB

4

Outline for Today• How do NFP affect design?• How do you cope with incomplete

specification?• How should you document COTS?• How should you document frameworks?

5

NFPs in Requirements• Non-functional properties crop up in requirements all the

time– “The system shall be reliable”– “The system shall be performant”– “The system shall be scalable”

• Each of these requirements suggest that there is a desired level of service– A measure (often qualitative) of operational or global conditions– Often, setting a target is in iterative process between

stakeholders:• e.g., How reliable? performant? scalable?• Often this requires modeling, costing, and testing exercises

6

Reliability Example• Reliability is an important requirement for

software in multiple domains:– Embedded systems – Mission- and Safety-critical systems such as spacecraft– Transactional systems (i.e., banking systems)

• Assume that a customer asks you to build a reliable software system for them. How would you proceed?

7

Define Reliability• A software system that can in no way cause harm to a

human being– Insulin delivery system

• Up-time or availability– Web servers, telephony systems

• Fault-free, Fault-tolerant– Aviation

• BASE (Basically Available, Soft state, Eventual consistency)– Search systems

8

Define Criteria• How reliable does the system need to be and how are

stakeholders going to evaluate it?– “Shall do no harm” is a measure, but how will you evaluate

it?• Modeling system fault trees can be used• In this case, there may be applicative gov’t regulations

– Availability is often measure in % up-time or acceptable amount of downtime

– BASE systems have a fuzzier notion of correctness• E.g., a Google search for “software architecture” returns

potentially different sets of links but all are links from a high-quality superset… you should not get results for llamas

9

Convey Cost/Risk to Stakeholders• Most levels of service involve the notion of diminishing

returns– Approach perfection asymptotically and w/ exponential costs

• Example: Suppose that 95% up-time is the nominal availability of the a software system– To reach 97%, it will cost 3x– To reach 99.8%, it will cost 12x– Reaching 100% is impossible

• In the face of mounting costs, customers will often re-assess the risk involved in reducing the desired level of service

This is not a lecture on risk, but remember that:Risk = Likelihood of failure * impact of failure

10

How Do You Design for Reliability?• Increase component/subsystem reliability– Software modeling can be used (simulation, white box/black

box testing, fault tree modeling, formal methods, etc)– You are only as good as your assumptions

• Component replication– If a component is critical, incorporate redundancy and fail-

over strategy– You usually can’t eliminate all single points of failure

• Ignore it– Microsoft does!

11

Performance Example• Like Reliability, Performance is in the eye of

the beholder– Performance can mean processing speed– Efficient use of a constrained resource• Performance with regard to memory usage

– Potentially, the customer really means scalability, e.g. performant w.r.t. adding new users/load

• Also like reliability, these definitions imply different metrics and different costs to achieve

12

Performance Example• Grid processing systems are designed to manage many

instances of multiple different types of executables– We trade the individual wall clock performance of on

instance against the overall throughput in the system– An executable on your local machine might take 2 wall-

clock hours to complete. Grid performance:

0 100 200 300 400 5000

5

10

15

20

25

Wall-Clock Runtime Histogram

# of

inst

ance

s

minutes

But we processed 250+ instances in 12 hours

13

Designing for Performance• Strategies for computing speed performance (i.e.,

wall-clock time)– Model your bottlenecks (timing and break-point

analysis)• Can be done at design time w/ simulation

– Alternate deployments• e.g., bring computation to data

– Algorithm modifications– Understanding customer requirements for accuracy

• Sort-of the right answer is often much faster than the exact right answer

14

Scale – A Type of Performance• Scale tends to be a performance-oriented NFR– Scale-up requirements• “The system shall nominally operate with x number of

clients but be able to add 3x clients within a certain performance parameter”

– Scale-down requirements• “The system shall shed unnecessary resources”

– Load requirements• “The system shall be capable of handling 1 million

simultaneous requests”

15

Efficient Scaling is Difficult• (And Costly!)• Examples abound in the “big data” world– Replication techniques– Eventual consistency– Virtualization– Parallel algorithms (Map-Reduce)

• Putting realistic constraints on the system while balancing future needs is a necessary conversation amongst stakeholders

16

Incomplete Specification• Click to add text

That was a joke

17

Frameworks, Libraries & COTS• Seldom do we as software engineers get to

design was a clean slate– Frameworks & Libraries are a codification of

common design idioms in a particular domain– COTS/GOTS often an option for implementing a

subsystem/portion of functionality– Brownfield design is also common• Your system will need to be integrated into an existing

environment

18

COTS in Design• Selection of COTS is beyond the topic of this

lecture, but how do you capture it in design?– Use-cases are independent of COTS– COTS components are often objects in sequence

diagrams– COTS are also documented in context diagrams

(treated as an external system)

19

Libraries in Design• Treat them similarly to COTS– Unlike COTS, they will not appear in Context

Diagrams

20

Frameworks in Design• Frameworks, unlike libraries, utilize inversion

of control– This implies that your customizations are

integrated into an existing design– Example: Web Content Management System

21

Zope Architecture

Often, there is some level of documentation for a framework’s architecture

http://plone.org/documentation/kb/plone-architecture

22

Zope in Your Design• Start by documenting the high level

architecture:

Object Store

Zope Core

Browser

23

Zope in Your Design• Develop your Use Cases• Document your Information Architecture– This will be what you implement in Zope’s DB

• Use the Zope components in your sequence diagrams

• Class diagrams should be used for any custom code

24

Conclusions• Design for NFPs involves– Defining stakeholder expectations– Choosing metrics– Negotiating Risk and Cost

• Requirements are often incomplete – work use cases

• Frameworks, Libraries, and COTS all have impacts on how you document your design

25

Questions

Now that we have finished three days ofOOA&D, what questions do you have?