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

1. Object-Oriented Architecture &Design – Lecture 3 (of 3)Advanced Topics David Woollard

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: But we processed 250+ instances in 12 hours # of instances minutes

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: Browser Zope Core Object Store

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 NFPsinvolves • 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 of OOA&D, what questions do you have?