1. Object-Oriented Architecture & Design – Lecture 3 (of 3) Advanced Topics David Woollard University of Southern California Computer Science Department Software Architecture Group California Institute of Technology NASA 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 2

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 3

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? 4

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 5

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? 6

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 7

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 8

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 9 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! 10

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 11

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: 12 # of instances 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 13

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” 14

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 15

16. Incomplete Specification Click to add text 16 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 17

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) 18

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

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 20

21. Zope Architecture 21 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: 22 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 23

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 24

25. Questions Now that we have finished three days of OOA&D, what questions do you have? 25