1. Class Diagrams Software Design and Development

2. Classes in a Class Diagram zClass name onlyExample zWith DetailsExample Class Name attributes methods Bank Account Bank Account double balance deposit() withdraw()

3. Relationships zInheritance (arrow) Õexample: between Secretary and Employee zComposition/Aggregation (diamond) Õexample: between Car and Wheel zAssociation (line) Õexample: between Borrower and Book

4. Inheritance Secretary Employee public class Secretary extends Employee { … }

5. Composition/Aggregation Car Wheel 4 w[] public class Car { Wheel w[];... public Car() { w = new Wheel[4]; … }... } Note: [ ] in diagram is sometimes left out since w does not need to be an array

6. Association BorrowerBook currBorrbk[] 31 public class Borrower { Book bk[]; … public Borrower() { bk = new Book[3]; } public class Book { Borrower currBorr; … }

7. Notational Details zCardinality ÕSpecifies the number of objects that may participate in the relationship zRoles and Navigability ÕSpecifies relationship name and access zAggregation versus Composition zDependencies

8. Cardinality zAlso known as multiplicity ÕExact number (mandatory) ÕRange (e.g., 0..5) Õ* (many-valued) zSpecifies the number of objects that may be associated with an object of the other class zFor associations, multiplicity is specified on both participants

9. Roles and Navigability zRole name placed on the side of a participant zLet A and B be associated classes and let rrr be the role specified on B’s side Õrrr is the role of B in the relationship Õrrr is a member in class A Õrrr refers to one or more (depending on multiplicity) B objects zAn arrowhead indicates the ability to access B participant(s) from A

10. Uni-directional Navigability PriceChecker getPrice() pc FastFood Counter public class FastFoodCounter { PriceChecker pc; … public void add( … ) { … double pr = pc.getPrice(); … } … } public class PriceChecker { // no access to counter }

11. Bi-directional Navigability BorrowerBook currBorrbk[] 31 public class Borrower { Book bk[]; … public Borrower() { bk = new Book[3]; } public class Book { Borrower currBorr; … } Note: double arrowheads may be omitted (bi-directional navigability assumed)

12. Aggregation versus Composition zPart-of relationships zAggregation ÕPart may be independent of the whole but the whole requires the part ÕUnfilled diamond zComposition (“stronger” form of aggregation) ÕPart is created and destroyed with the whole ÕFilled diamond zDefinitions and distinctions between aggregation and composition still “under debate”

13. Mandatory Parts Car Wheel 4 wheels public class Car { private Wheel wheels[4]; // wheel objects are created externally... public Car(Wheel w1, Wheel w2, … ) … // wheels required in constructor // w1, w2, … will be checked for null values }

14. Dependencies zSome classes use other classes but are not related to them in ways previously discussed xNot relationships in the sense that participants do not become attributes in another class zMost common example: ÕAs local variables in (or arguments to) a method of the class

15. Dependency Example Parser getOrder() uses Restaurant processOrders() public class Restaurant { … public void processOrders() { Parser p = new Parser(…); // call getOrder() in this method } … }

16. Use Cases and Object Interaction Software Design and Development

17. Depicting System Behavior zFirst, identify the use cases ÕUse case: typical interaction between a user and the system zUse Case Diagram ÕDepicts all use cases for a system zInteraction Diagram ÕDepicts a single use case as a collection of interacting objects

18. Example: Use Case Diagram Facilitate Checkout Facilitate Return Search for Book LIBRARY SYSTEM Borrower Librarian

19. Use Case Diagram Notation zStick Figures – Actors ÕCould be a human user or a subsystem zEllipses - Use Cases zLinks - between actors and use cases zLinks between use cases Õ >: to depict inclusion of a use case Õ >: to depict variations of a general use case

20. Example: > Facilitate Checkout Facilitate Return Librarian Log-in > Note: UML v.1.3 uses > instead of >

21. Example: > Search for Book query Borrower By Author By Subject > Note: query is called an extension point

22. Describing a Use Case zNarrative ÕLibrary example (Facilitate Checkout): Given a borrower’s ID Card and the book to be borrowed, the librarian enters the borrower’s ID number and the book’s catalogue number. If the borrower is allowed to check out the book, the system displays that the book has been recorded as borrowed zOr, an Interaction Diagram

23. Example: Interaction Diagram Checkout Screen :Borrower :Book 1: checkIfDelinquent() 3: borrowBook() 2: checkIfAvailable() 4: setBorrower()

24. Interaction (Collaboration) Diagram Notation zRectangles: Classes/Objects zArrows: Messages/Method Calls zLabels on Arrows Õsequence number (whole numbers or X.X.X notation) Õmethod name (the message passed) Õmore details, if helpful and necessary (iterators, conditions, parameters, types, return types)

25. Methods zInteraction Diagrams suggest/imply methods for classes ÕHas consequences on detailed class diagram zThe label(s) of an arrow should be a method of the class the arrow points to zLibrary System ÕBorrower class should have at least two methods (checkIfDelinquent and borrowBook)

26. Including Conditions and Types Checkout Screen r:Borrower b:Book 1: delinq = checkIfDelinquent():boolean 3:[!delinq & avail] borrowBook(Book b) 2: avail = checkIfAvailable():boolean 4: setBorrower( Borrower bk )

27. Interaction Diagrams and Object-Oriented Code zNote correspondences between messages passed and method calls in actual code zExample: ÕborrowBook() is defined in Borrower and is called from the code in CheckOutScreen ÕsetBorrower() is defined in Book and is called from borrowBook() method of Borrower zOther diagramming details imply if statements and loops in code

28. Creating an Object znew means a constructor is being called ÕImplies object creation :Customer :CustomerList 1: addCustomer(custdetails) :Encoder 2: new Note: this means the addCustomer method will contain code that creates a Customer object

29. Iteration z* is an iterator Õmeans the method is called repeatedly :Branch :Store 1: printSalesSummary() :Manager 2: * getTotalSales() Note: Store needs data from all branches to produce a summary

30. Summary zProvide a Use Case Diagram to depict the use cases of a system zFor each use case, describe and provide an Interaction Diagram ÕDepict use case as a collection of interacting objects zOther diagramming techniques that aid in building a dynamic model: ÕState diagram: describes object state changes ÕActivity diagram: describes method behavior