Object-Oriented Architecture & Design – Lecture 2 UML in Depth and Advanced Topics

1. Object-Oriented Architecture &Design – Lecture 2UML in Depth and Advanced Topics Ivo Krka

2. Story Arc • Storyline in episodic form • Goal for OOA&D: Move from requirements to design, reified by a model • Last time • OO is a useful design construct • OO has a place in Architecture, but Architecture is a lot larger than OO • Design is an iterative process • Requirements are incomplete • Requirements conflict with other requirements • Requirements can be non-functional and imply levels-of-service • What parts need to be built from scratch? • What are the best choices for reuse?

3. Outline for Today • How do I determine the terminology • Domain Modeling • Now that I have some designs in mind, how do I capture them? • Use Case Diagrams • Sequence Diagrams • Class Diagrams • Deployment Diagrams • How do NFP affect design? • How should you document COTS? • How should you document frameworks?

4. Example – Internet Bookstore • Online retail outlet for purchasing books • Provide basic user capabilities for: • Searching for books • Reviews & rating of books • Purchase of books • Interfaces to shipping and inventory management

5. Internet Bookstore Requirements (1/2) • The bookstore shall accept orders over the internet • The bookstore shall maintain a list of accounts for up to 1,000,000 customers • The bookstore shall provide password protection for all accounts • The bookstore shall provide the ability to search the master book catalog • The bookstore shall provide a number of search methods on that catalog, including search by author, search by title, search by ISBN number, and search by keyword • The bookstore shall provide a secure means of allowing customers to pay by credit card

6. Internet Bookstore Requirements (2/2) • The bookstore shall provide a secure means of allowing Customers to pay via purchase order • The bookstore shall provide a special kind of account that is pre-authorized to pay via purchase order • The bookstore shall provide electronic links between the Web and the book information database (BID) and the shipping fulfillment center • The bookstore shall maintain reviews of books and should allow anyone to upload review comments • The bookstore shall maintain ratings on books based on customer inputs

7. Domain Modeling • Necessary to ground both requirements and design (and hopefully implementation) in terminology shared by all stakeholders • A methodology for building terminology, as well as discovering and refining use-cases and requirements • Many techniques exist

8. Domain Modeling Guidelines (1/2) • Focus on real-world (problem domain) objects. • Use generalization (is-a) and aggregation (has-a) relationships to show the objects relate to each other. • Limit your initial domain modeling efforts to a couple of hours. • Organize your classes around key abstractions in the problem domain. • Don’t mistake your domain model for your data model. Source: Use case driven object modeling with UML: theory and practice by Doug Rosenberg and Matt Stephens

9. Domain Modeling Guidelines (2/2) • Don’t confuse an object (a single instance) with a database table (a collection of things). • Use the domain model as a project glossary. • Do your initial domain model before you write your use cases, to avoid name ambiguity. • Don’t expect your final class diagrams to precisely match your domain model, but there should be some resemblance between them. • Don’t put screens and other GUI-specific classes on your domain model. Source: Use case driven object modeling with UML: theory and practice by Doug Rosenberg and Matt Stephens

10. Sounds a lot like OO, right?

11. Example Technique: Color Modeling • First used for Java software development in 1997 • Refined by Peter Coad, et. al., in Java Modeling in Color with UML • Focuses on identifying different varieties of domain classes (or ‘archetypes’): • Party/Place/Thing • Role • Activity • Description (we aren’t going to cover this one) • First step in the technique to to start with enumerating the activities in the problem domain that the software should support • Identify each Party, Place or Thing who participate in the activity • Identify what Roles the Party, Place or Things play while interacting with the activity

12. Internet Bookstore Domain Model • As an initial example let us focus on the activity of account registration • Two requirements suggest that this is a domain activity: • “The bookstore shall maintain a list of accounts for up to 1,000,000 customers” • “The bookstore shall provide password protection for all accounts” • Since the requirements refer to accounts with password protection, you can assume that ‘People’ in the role of ‘Customers’ will have to register with the Internet Bookstore in order to create accounts for themselves • Of course, like everything else during this early phase of the development process, this assumption must be verified with the relevant critical stakeholders

13. Color Modeling – Acct. Registration • In color modeling, each object has a stereotype (this is a UML term) in ‘<>’ and a color indicating its archetype • <activity> classes are colored pink • <party>, <place>, and <thing> classes are colored green • <role> classes are colored yellow • Why is there a privileged account vs. an ordinary account? • “The bookstore shall provide a special kind of account that is pre-authorized to pay via purchase order” <Party> Person Is A <Role> Customer Performs <Activity> Registration Produces <Thing> Account <Thing> Privileged Account <Thing> Ordinary Account

14. Why UML • Started in 1994, led by Rational Software Corporation, fused a number of modeling approaches • Booch Technique • Object Modeling Technique • Object-Oriented Software Engineering • Extensive industry adoption • Significant tool support • Not the only ADL, but usually a decent choice

15. Log-in Use Case • The Customer clicks the Login button on the Home Page. • The system displays the Login Page. • The Customer enters his or her user ID and password and then clicks the Login button. • The system validates the login information against the persistent Account data and then returns theCustomer to the Home Page.

16. Use Case Modeling Basics • The purpose of Use-Case Design is to discover the necessary: • Interface Objects & their classes • e.g. pages, dialog boxes, representations of entities • Entity Objects & their classes • Both temporary & persistent, • e.g., data structures, DB tables, etc • Control Objects & their classes • Activity or control flow classes • The messages they exchange

17. UML Use-Case Symbols • Interface Classes are labeled with: • Entity Classes are labeled with: • Control Classes are labeled with: • Actors in the use-case are labeled with: NOTE: Don’t get caught up on diagram specifics

18. Log-in Use Case • The Customer clicks the Login button on the Home Page. • The system displays the Login Page. • The Customer enters his or her user ID and password and then clicks the Login button. • The system validates the login information against the persistent Account data and then returns theCustomer to the Home Page.

19. Use-Case: Step 1 • Step 1: The Customer clicks the Login button on the Home Page • Step 1: The Customer clicks the Login button on the Home Page Q. Why did we not explicitly model the login button? Short Answer: Judgment call Longer Answer: “Click log In” is a simple behavior, the whole of which can be conveyed simply.

20. Use-Case: Step 2 • The system displays the Login Page. A good intuitive understanding of Control Objects is that they will ultimately become methods

21. Use-Case: Step 3 • The Customer enters his or her user ID and password and then clicks the Login button.

22. Use-Case: Step 4 • The system validates the login information against the persistent Account data and then returns the Customer to the Home Page.

23. But what about off-nominal cases?

24. Log-in Use Case Alternatives • If the Customer clicks the New Account button on the Login Page, the system invokes the Open Account Use-Case. • If the Customer clicks the Password Reminder button on the Login Page, the system displays the reminder word stored for that Customer, in a separate dialog box. When the Customer clicks the OK button, the system returns the Customer to the Login Page. • If the Customer enters a user ID that the system does not recognize, the system displays a message to that effect and prompts the Customer to either enter a different ID or click the New Account button. • If the Customer enters an incorrect password, the system displays a message to that effect and prompts the Customer to reenter his or her password. • If the Customer enters an incorrect password three times, the system displays a page telling the Customer that he or she should contact customer service, and also freezes the Login Page.

25. Use-Case: Alternative 1 • If the Customer clicks the New Account button on the Login Page, the system invokes the Open Account Use-Case. Illustration of hierarchical Use-case composition.

26. Use-Case: Alternative 2 • If the Customer clicks the Password Reminder button on the Login Page, the system displays the reminder word stored for that Customer, in a separate dialog box. I’ll leave the rest of the alternatives to you as an exercise.

27. Search by Author Use-Case Diagram

28. Sequence Diagram Basics • Top Elements – Classes in the eventual design • Actors, Interface Classes, Entity Classes • Left Elements – Use Case Description • Arrows indicate Messages • What the methods should be • Which object each methodshould belong to • Which object(s) calls whichmethod, and at exactly whatpoint during the course ofthe Use-Case Use Case Description

29. Log In Sequence Diagram

30. Class Diagrams • Some of your objects will be implemented as classes • Each class consists of three elements: • name • attributes • Operations • Relationships between classes:

31. Class Relationships • Association • Binary association • N-ary association • One-way navigation • Named association • Association by roles • Association multiplicity • Aggregation • Basic aggregation • Multiple aggregation • Self-aggregation • Composition • Generalization • Basic generalization • Multiple generalization (Powertype) • Dependency • Basic dependency • Usage dependency • Creation dependency • Instantiation dependency • Abstraction dependency • Derivation dependency • Realization dependency • Refinement dependency • Trace dependency • Permission dependency • Substitution dependency Some Advice: For the purposes of your assignments in this class, stick to the basics: - Binary, N-ary associations w/ multiplicity - Basic aggregation/composition - Basic dependencies Remember, it’s a model of your system…

32. Deployment Diagrams • Deployment diagrams show the relationship between the hardware and software components in the system Typically not very useful for 577 projects, but useful to Understand for more complex, Distributed systems.

33. Context Diagrams • Show a system’s external interfaces. From Agile Modeling: Effective Practices for Extreme Programming and the Unified Process by Scott Ambler.

34. UML Summary • 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

35. 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

36. 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?

37. 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

38. 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 • Higher the reliability - higher the cost

39. 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 • Even some big companies do it

40. 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

41. 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

42. 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”

43. 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

44. 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

45. COTS in Design • Selection of COTS was partially covered in the last 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)

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

47. 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

48. Zope Architecture Often, there is some level of documentation for a framework’s architecture http://plone.org/documentation/kb/plone-architecture

49. Zope in Your Design • Start by documenting the high level architecture: Browser Zope Core Object Store

50. 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