Object-Oriented Architecture & Design – Lecture 2 (of 3) UML in Depth David Woollard University of Southern California Computer Science Department Software Architecture Group California Institute of Technology NASA Jet Propulsion Laboratory Data Management Group

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

From 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 imply other missing requirements – Requirements conflict with other requirements – Requirements can be non-functional and imply levels-of-service Would an Internet bookstore designed to service 100 customers have a different architecture from an Internet Bookstore designed to support 100 Million? Domain Modeling is a useful activity to flesh out requirements and design concerns as well as standardize on language 3

Outline for Today Now that I have some designs in mind, how do I capture them? – Use Case Diagrams – Sequence Diagrams – Class Diagrams – Deployment Diagrams Assignment Specifics 4

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 5

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 6

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 7

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 8

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

Use Case 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 We’ll see examples on later slides – You know what an Interface Class is & what an Entity Class is, so don’t worry if you don’t yet know what a Control Class is (you’ll find out soon) – The messages they exchange 10

UML Use-Case Symbols Interface Classes are labeled with: – These objects interact with actors in the use-case Entity Classes are labeled with: – These are data classes Control Classes are labeled with: – These can be thought of as activity or control flow classes Actors in the use-case are labeled with: 11 NOTE: Don’t get caught up on diagram specifics

Use-Case: Step 1 Step 1: The Customer clicks the Login button on the Home Page 12 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.

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

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

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

But what about off-nominal cases? 16

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

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

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. 19 I’ll leave the rest of the alternatives to you as an exercise.

Search by Author Use Case The Customer types the name of an Author on the Search Page and then presses the Search button. The system ensures that the Customer typed a valid search phrase, and then searches the Catalog and retrieves all of the Books with which that Author is associated. Then the system retrieves the important details about each Book, and creates a Search Results object with that information. Then the system displays the list of Books on the Search Results Page, with the Books listed in reverse chronological order by publication date. Each entry has a thumbnail of the Book's cover, the Book's title and authors, the average Rating, and an Add to Shopping Cart button. The Customer presses the Add to Shopping Cart button for a particular Book. The system passes control to the Add Item to Shopping Cart Use-Case. 20

Search by Author Alternatives If the Customer did not type a search phrase before pressing the Search button, the system displays an error message to that effect and prompts the Customer to type a search phrase. If the system was unable to find any Books associated with the Author that the Customer specified, the system displays a message to that effect and prompts the Customer to perform a different search. If the Customer leaves the page in a way other than by pressing an Add to Shopping Cart button, the system returns control to the Use-Case from which this Use- Case received control. 21

Search by Author Use-Case Diagram 22

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 method should belong to – Which object(s) calls which method, and at exactly what point during the course of the Use-Case 23 Use Case Description

Log In Sequence Diagram 24

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

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 26 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…

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

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

ARB Specifics In the first ARB (10/18-10/22), you will need to generate the following: – System Analysis Artifacts and Information Model Use-Case Model System Context Model – Design Model Initial Design At the very least, a deployment diagram 29

Artifacts and Information Model Primary documentation of Entity Classes Use Class Diagrams to model the Entity classes Similar to E-R diagram Ultimately, we will use these diagrams to develop the persistence layers in the system 30

Use Case Models Capture all nominal cases Keep the specification to a high level Alternatives for primary use-cases Show hierarchical relationships 31

Context Diagram Basically just as advertised Show the hierarchy of the user classes and how they interact with the system 32

Rationale Tutorial & Workshop Tip will be holding tutorials on using Rational software in the next week – Please attend if you are unfamiliar On 10/11, we will be holding a design workshop – Bring in your designs prior to ARB – We can provide feedback on: Scope Detail Modeling nomenclature 33

Conclusions 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 34