Homework Due Next Week

1. Homework Due Next Week • Use Case Diagram, Class Diagram, User Interface, State Diagram

2. Design Phases continued

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

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

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. System Decomposition • Convert general/abstract models created during the analysis phase into detailed models • Stepwise refinement/evolutionary development • Leads directly to the system implementation

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

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

10. 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()

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

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

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

14. 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.)

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

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

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

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

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

20. 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)

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

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

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

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

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

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

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

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

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

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

31. 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()

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

33. Object Diagram • Yet another look at the system • Encompasses a snapshot of the running system • Contains object instances and their relationships rather than classes • Indirectly related to (or analogous to) Informal Scenarios

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

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

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

37. Code • But what is “well written code”?

38. What About This Code? main(t,_,a ) char * a; { return! 0<t? t<3? main(-79,-13,a+ main(-87,1-_, main(-86, 0, a+1 ) +a)): 1, t<_? main( t+1, _, a ) :3, main ( -94, -27+t, a ) &&t == 2 ?_ <13 ? main ( 2, _+1, "%s %d %d\n" ) :9:16: t<0? t<-72? main( _, t, "@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+,/+#n+,\ /#;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/+k#;q#'r}eKK#}\ w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){nl]!/n{n#'; r{#w'r nc{nl]'\ /#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'\ }{nlwb!/*de}'c ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'\ {n' ')# }'+}##(!!/") : t<-50? _==*a ? putchar(31[a]): main(-65,_,a+1) : main((*a == '/') + t, _, a + 1 ) : 0<t? main ( 2, 2 , "%s") :*a=='/'|| main(0, main(-61,*a, "!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry") ,a+1);}

39. Code

40. Diagrams to Code • Code can be written in many, many different styles for many, many different goals • The diagrams are nice and useful but they’re not code • How can we convert them to code while retaining their documentary nature? • We need an intermediate step • Class skeletons

41. Class Skeleton • Consists of these sections • List of roles • Information maintenance • Attributes • Constructors • Methods • Can be written in the target language or a psuedo-language

42. Roles • Behavior of the class within a context • In a particular situation, what does the class provide? • May partition the class into functionalities that can be designed independently

43. Information Maintenance • Specifies when objects of a particular class type are created and deleted • Not all classes/instances will be used throughout the entire execution of the system

44. Attributes • Instancevariables • Hold data specific to an instance of the class • Class variables • Hold data common to all instances of the class • Also called static class variables

45. Constructors/Destructors • Called when a class is instantiated • Allocation of memory for the instance • Initialization of instance variables • Modification of class variables • Called when a class instance is removed from the system • Deallocate instance memory • Modification of class variables

46. Methods • Non-static member functions • Modify/operate on instance variables of the class • Static member functions • Modify/operate on the class variables of the class

47. 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 form. // Deletion: Patrons are removed from the library database // 3 years after their membership has expired

48. Skeleton (cont.) // Instance variables: private String name; // name of Patron in // <last-name, first-name, MI> order private long PatronID; // Patron’s library identification // number sequentially generated private long homephone; // Patron’s home phone number in // 11 digits (xxx)yyy-zzzz stored as // xxxyyyzzzz private Date memberDate; // date of first membership in // mmddyyyy format private Date expireDate; //date membership expires in // mmddyyyy format private List resourceList; // Object reference to Patron’s // list of checked out resources private Address homeAddress; // Object reference to // patron’s home address

49. Skeleton (cont.) // Class variables: private static long nextPatronID; // keeps track of the // next patron membership ID to // be assigned // Constructors: public Patron(String name, long homePhone, Date memberDate, Date expireDate, String street, String city, String state, long zip) { // TODO List: // PatronID = getnextPatronID() // Create an Address object initialized with street, // city, state, and zip // Create Date objects for membership data and // expiration dates initialized with memberDate and // expireDate.

50. Skeleton (cont.) // Precondition: Library database can accept another // entry and memory allocation succeeds // Postcondition: Library database will contain another // Patron and Address entry } // Destructors: (C++ -- finalize() in Java) ~Patron() { // Precondition: Patron object is not null // deallocate any memory allocated by the constructor // or other nonstatic methods } // Static methods: public static long getnextPatronID() { return nextPatronID; nextPatronID++;}