Class Design Phases

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 Cases Scenarios Class Diagrams Object Diagrams Interaction Diagrams Class Diagrams Class Skeletons Class Design Class Definitions Implementation

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

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 variablesprivate 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 methodspublic 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 class-name attribute1 attribute2 method1() method2(int) method3()

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

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

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

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

22. Class Diagrams (cont.) • Multiplicity • Cardinality of an association relationship Patron 0..1 0..* Resouce

23. Class Diagrams (cont.) • Role • Descriptive label about the part an object plays in the association Patron 0..1 0..* Resouce Borrower

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

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 Patron Address Name Overdue Notice Patron Resource

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 interactionsbetween 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 • Analysis phase instance of Use Case Scenario • Design phase instance of Class Diagram Interaction Diagram • You’ll have one for each scenario

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

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 Initiate Game Scenario {Requirement #2} :Life CreateGrid(rows, columns) GetSizes(rows, columns) :Grid :User Interface DrawGrid() CreateCell() EnterSize(rows) EnterSize(columns) :Cell User

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

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

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) : Library System validatePatron(MemDate) getResource(ResourceID) Checkout(ResourceID) getPatron(PatronID) update(Patron) : Patron : LibraryDatabase create(LibraryDatabase) ( See deliverable 5.3 for entire diagram )

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

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

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) : Library System : Patron : LibraryDatabase getResource(ResourceID) getPatron(PatronID) create(LibraryDatabase) 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 :Cell (0,0) occupied :Cell (0,1) occupied :Grid rows = 12 Cols = 16 :Life :Cell (11,15) unoccupied

47. LMS Case Study: Object Diagram (partial) :Book currentP: Student : List name = “SOTY”author=“b. hooks”ISBN= ... name=“Gert Stein”libraryID=6747632homephone=5554321workphone=5551234membership=05011999expire=05012002 :Book name = “FOF”author=“Ehrenreich”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 patternscavenging • 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 Resource CheckableResource ReserveResource Book Electronic Media