1. Class Design Phases

2. Where Are We? We’ve done our Product Design resulting in –Use Cases/Use Case diagrams –Class diagrams (initial) –State diagrams –Deployment diagram

3. Where Are We? (cont.) We’ve also produced –Object Persistence specifications –Process Architecture –Human-Computer Interface specifications What’s next? –Class Design (internals)

4. The Deliverables of the Class Design Process Class diagrams are further refined in this phase of development Object diagrams are created Interaction diagrams are created Class skeletons are created to embody all analysis and design information created to this point in the development process

5. Relationships of SE Phases and UML Diagrams Analysis Use CasesScenariosClass Diagrams Class Design Object Diagrams Interaction Diagrams Class Diagrams Class Skeletons Implementation Class Definitions

6. Relationships of SE Phases and UML Diagrams Analysis Use CasesScenariosClass Diagrams Class Design Object Diagrams Interaction Diagrams Class Diagrams Class Skeletons Implementation Class Definitions

7. Class Skeletons We will preview class skeletons to better understand the objectives of design Class skeletons are partial class definitions Class skeletons should be heavily commented, so that the purpose of all attributes, methods, and constructors is clear Class skeletons are the basis for the implementation phase of development

8. Contents of Class Skeletons A list of the roles the class plays within the system Information concerning when objects of the class are created and deleted (information maintenance) For each role, the semantics of the class All attributes with access modifiers, types, names, and semantics For all constructors and methods, their signature, semantics, preconditions and postconditions

9. LMS Class Skeleton public class Patron { // Class Semantics and roles // Library Patrons function in two primary // roles, as researchers who use index, // reference and database materials, and as // borrowers of loanable resources. // Information maintenance // Creation: new patrons are introduced // into the system by library staff when // presented with a library membership // application or from information // retrieved from a web-based application

10. More LMS Class Skeleton // Information maintenance continued // Deletion: patrons are removed from the // library database 3 years after their // membership expires // // Instance variables private String name; // Patron name in // last, first, middle initial format private long PatronID; // Patron library ID // number. Automatically generated...( See deliverable 5.1 for other instance variables )

11. More LMS Class Skeleton // Class variables private static long nextPatronID; // Keeps // track of next patronID to be assigned // Constructors public Patron(String n, long home, Date m, Date e, String street, String city, String state, long zip) { // Parameters: n = name, home = homephone // PatronID = getnextPatronID() // street,city, state, and zip are used // to create an address object for // homeAddress

12. More LMS Class Skeleton // Constructors continued // Precondition: for constructor: // Library database can accept an // additional entry and memory allocation // succeeds // Postcondition: Library database will // contain an additional Patron and Address // entry } // Static methods public static long getnextPatronID() { return nextPatronID; nextPatronID++;}

13. More LMS Class Skeleton // Non-static methods public boolean validatePatron(Date e) { // ensure membership is not expired // Precondition: expireDate != null // if expireDate <= Today return false // else return true }...( See deliverable 5.1 for other non-static methods ) } // end class Patron

14. System Decomposition Convert general/abstract models created during the analysis phase into detailed models Stepwise refinement/evolutionary development Leads directly to the system implementation

15. Class Design Expand on the analysis deliverables to ensure complete functionality coverage –We’re about to commit ourselves so we want to make sure the design is complete and correct Add detail to class diagrams –Attributes –Method signatures Produce a class skeleton which will eventually turn into code

16. Class Diagrams Revisited Portray the elements of a class and the relationships between classes –Class –Interface –Relationship –Collaborations

17. Class Diagrams (cont.) Class –May be just a class name –May include attributes and/or access methods class-name attribute1 attribute2 method1() method2(int) method3()

18. Class Diagrams (cont.) Relationships (between classes) –Association –Generalization –Dependency class-1class-2 does-something-to base-classderived-class change-mechange-me too

19. Class Diagrams (cont.) Interface –Class interactions –Enforces encapsulation –Generally left out until the design phase class-1class-2 interface-1

20. Class Diagrams (cont.) Collaboration –Specifies that multiple elements must interact to produce a given behavior class-1 class-2 interface-1 class-3 update-operation

21. Class Diagrams (cont.) Access modifiers –Specify the mode of access of class methods and attributes Public Private Protected class-name -privateatt0 -privateatt1 +public0() -private0(int) #protected0()

22. Class Diagrams (cont.) Multiplicity –Cardinality of an association relationship PatronResouce 0..10..*

23. Class Diagrams (cont.) Role –Descriptive label about the part an object plays in the association PatronResouce 0..10..* Borrower

24. Class Diagrams (cont.) Constraints Tagged values –Special circumstances that must be considered –Versioning of diagrams –Associations with functional requirements –Nonstandard information PatronResource 0..10..* Borrower {Requirement #5} {Student at most 25 resources} {Faculty and staff – no limit}

25. Class Diagrams (cont.) Aggregation –Class containment –Filled diamond means the contained class cannot exist on its own –Hollow diamond means the contained class can exist on its own Address Patron Overdue Notice Resource Name

26. Aggregation Often represented as an association Often represented by inclusion of an object type (class) in the attribute field of the including class All techniques are acceptable –Just make sure your designs are clear and concise

27. Interaction Diagrams Specify the interactions between classes –This information is absent in the Class Diagrams (only show relationships) –Collaboration Diagrams Structure of interactions –Sequence Diagrams Time ordering of interactions (messages)

28. Interaction Diagrams (cont.) Consists of –Objects Instance of a class (not the class itself) Links/Messages –Association between instances –Corresponds to an association in the Class Diagram –Likely to be implemented as a method (function) call

29. Interaction Diagrams (cont.) Loosely speaking Use Case Scenario instance of Class Diagram Interaction Diagram instance of –Analysis phase –Design phase –You’ll have one for each scenario

30. Interaction Diagrams (cont.) Object-name : class method-name(params) Object Link Message Symbols

31. Collaboration Diagram Also known as a Communication diagram (UML 2.0) Describe the Structure of interactions between classes

32. Steps for Creating Collaboration Diagrams Identify a behavior to model Identify participating class and their relevant interrelationships Identify a specific scenario to model determine necessary message passing to carry out the behavior Introduce solution for object persistence, if needed

33. Collaboration Diagram :Life :Grid :User Interface CreateGrid(rows, columns) GetSizes(rows, columns) :Cell CreateCell() DrawGrid() EnterSize(rows) EnterSize(columns) User Initiate Game Scenario {Requirement #2}

34. Collaboration Diagram (cont.) :Grid :User Interface :Cell SetColor(bool occ) DrawGrid() UpdateCell(row, col) Set Cells Scenario User LBCallback(row, col)

35. Collaboration Diagram (cont.) :Grid :User Interface :Cell UpdateCell() :Ruleset UpdateCell(row, col) DrawGrid() Run Rules Scenario User StartCallback() ApplyRules() :Timer Start()

36. Collaboration Diagram (cont.) Just another step in the evolution of the system –Class Diagrams outline the general associations –Scenarios provide detailed “stories” –Combining the two provides us with clues to needed classes/methods/attributes/interfaces

37. Collaboration Diagram (cont.) Development of collaboration diagrams is an art, not a science –Basically, you’re writing programs, you’re just doing it pictorially and at a level a step or two above actual “programming” It all starts with the Use Cases and Scenarios and proceeds by adding detail to the Class Diagrams

38. LMS Case Study: Collaboration Diagram(Partial) : Patron : Library System : LibraryDatabase Checkout(ResourceI D) validatePatron(MemDat e) ( See deliverable 5.3 for entire diagram ) update(Patron ) create(LibraryDatabas e) getResource(Resource ID) getPatron(PatronID)

39. Sequence Diagram Describe the timing or ordering of interactions (messages) between classes

40. Sequence Diagram :Life:User Interface GetSizes(rows, columns) :Grid CreateGrid(rows, columns) :Cell CreateCell() DrawGrid() Initiate Game Scenario {Requirement #2} {Continue only when the rows/columns are less than 100}

41. Sequence Diagram (cont.) Similar content to Collaboration Diagrams Add the notion of “time” –Time increases from top to bottom –Topmost objects/messages are created/sent first –Objects may come and go over the life of the system Again, it’s an art, not a science

42. Sequence Diagrams Like collaboration diagrams, sequence diagrams model dynamic aspects of the system by specifying the interaction among objects to produce a particular behavior Sequence diagrams specify the time ordering of messages Sequence diagrams show the life span of each object

43. LMS Case Study: Sequence Diagram(Partial) : Patron : Library System : LibraryDatabase create(LibraryDatabas e) getResource(ResourceID) getPatron(PatronID) validatePatron (MemDate) (See deliverable 5.5 for entire diagram )

44. Object Diagrams Models a set of objects and their interrelationships during a system snapshot A system snapshot is the state of the software system at a selected moment of time Object diagrams model another static perspective of the system Unlike other diagrams, object diagrams may contain multiple instances of the same class

45. Steps for Creating Object Diagrams Identify a system snapshot within a scenario to model Identify participating classes and their interrelationships Identify all allocated objects at the time of the snapshot Show the state of each object in the snapshot Determine all interobject links

46. Object Diagram :Life :Grid rows = 12 Cols = 16 :Cell (0,0) occupied :Cell (0,1) occupied :Cell (11,15) unoccupied

47. LMS Case Study: Object Diagram (partial) currentP: Student : List name=“Gert Stein” libraryID=6747632 homephone=5554321 workphone=5551234 membership=050119 99 expire=05012002 :Book name = “SOTY” author=“b. hooks” ISBN=... :Book name = “FOF” author=“Ehrenreic h” ISBN=... (See deliverable 5.7 for entire diagram )

48. Why All The Diagrams? Code reuse –Identify reusable classes (inheritance/aggregate) Well-designed classes and methods –Private attributes (data) –Proper initialization (constructor) –Abstract data types (aggregates) –Self-documenting (attribute/method names) Assurance of data integrity –Object updates (interrelated transactions)

49. Code Reuse Collaboration diagrams are of particular use in pattern scavenging Pattern scavenging involves studying the various diagrams produced during analysis and class design to identify patterns of class interaction Once such patterns are found, they should be evaluated to determine if they can be effectively reused

50. Reuse in LMS Resourc e Checkabl e Resource Reserve Resourc e BookElectroni c Media

51. Evaluating Design Modeling software helps us produce correct, well- structured systems The resultant models can also be scrutinized for potential data integrity problems For example, in the LMS system, having update methods execute separately for the Patron and Resource objects may result in data integrity errors if system failure occurs between the initiation of the first method and the termination of the second method

52. Guidelines for Class Design Always keep data private Always initialize data in a constructor Do not use too many related primitives Not all attributes need individual accessor or mutator methods Order elements comprising class definitions consistently Break up overly complex classes into multiple classes Name classes, methods and attributes well

53. Verification of the Class Design All system requirements developed during analysis must be addressed during design –All design documents must cross reference requirements from the requirements specification All required attributes and methods must be used properly –E.g. data integrity of attributes must be enforced by update methods The modules comprising the system must work together properly

54. Why All The Diagrams? (cont.) IT’S EASIER TO CHANGE THESE DIAGRAMS THAN IT IS TO CHANGE CODE! IT’S EASIER TO DEBUG WELL WRITTEN CODE THAN POORLY WRITTEN CODE!