Presentation is loading. Please wait.

Presentation is loading. Please wait.

Lecture 7: UML Class Diagrams CSE 111 7/15/20151Copyright W. Howden.

Similar presentations


Presentation on theme: "Lecture 7: UML Class Diagrams CSE 111 7/15/20151Copyright W. Howden."— Presentation transcript:

1 Lecture 7: UML Class Diagrams CSE 111 7/15/20151Copyright W. Howden

2 Context After completion of the collaboration diagrams, we have identified class objects that will be needed to perform the subsystem responsibilities We now have the classes for our design From the sequence and collaboration diagram messages, we know what the methods in the classes will be 7/15/2015Copyright W. Howden2

3 3 UML Class Diagrams Nodes - Classes – Attributes: simple variables – Names and signatures of methods – Similar to Domain model classes, but + methods Edges – Relationships between classes – Association (class A has a class variable of type B) – Object visibility – Inheritance and aggregation (described later) If diagrams are cluttered, put class details in separate diagrams for each class

4 Sample Diagram GUI class structure for DS – Shows GUI classes and their relationships – We will also need DS and DB class diagrams Once the class diagrams are complete, we can begin to code – create Java classes corresponding to design classes – write the class methods, using the logic in the collaboration diagrams 7/15/2015Copyright W. Howden4

5 5

6 6

7 Object Visibility Object visibility: object x can “see” an object y – i.e. x sends a message to y (executes one of its methods) i.e. a method in x calls a method of y – x references one of y’s public variables i.e. a method in x references the value of a class variable of y 7/15/2015Copyright W. Howden7

8 Class Design and Object Visibility How can we arrange for the required object visibility to occur in our design? Object visibility is incorporated into an object- oriented design in four ways: attribute, parameter, local variable and global The following examples illustrate ways to incorporate required visibility into a design. First example uses attribute and parameter visibility and the second local variable visibility. 7/15/2015Copyright W. Howden8

9 9

10 Object Visibility and Suggested Design Solution In its response to the Start button being pushed, :GUIFrame completes a logon and then sends a getUserType() message to object dL:DomainLogic Solution to the dL visibility requirement – In our design, the constructor for GUIFrame will have a parameter that is used to pass in an instance dL of DomainLogic. The constructor will then assign dL to a class variable of GUIFrame – This design solution uses two types of visibility: attribute and parameter 7/15/2015Copyright W. Howden10

11 Attribute Object Visibility Attribute visibility : – an object is visible because it is a class variable in the class from which visibility is required In this example, the :GUIFrame method that is processing the Start message/event can “see” dL:DomainLogic, and hence send it a meassage, because it will be an attribute in the GUIFrame class 7/15/2015Copyright W. Howden11

12 Parameter Object Visibility Parameter visibility: - an object is visible inside a method because it was passed in as a parameter in a call to the method In this example the constructor for GUIFrame can see the object dL in order to assign to the dL class variable for GUIFrame because dL is passed in as a parameter to the constructor 7/15/2015Copyright W. Howden12

13 Copyright W. Howden13

14 Object Visibility and Suggested Design Solution In its response to the getDateButton message/event, the :DaterOptionSelectionDialog object creates a :SelectDataPrefsDialog object and then sends it a show() message. Solution to the implied visibility requirement – in our design, the method that is processing the getDateButton message/event will have a local variable to which it assigns the result of the create() action (i.e. call to SelectDaterPrefsDialog constructor). – This design solution uses local variable object visibility 7/15/2015Copyright W. Howden14

15 Local Variable Object Visibility an object is visible because it is the value of a local variable in the method from which visibility is required In the example the DaterOptionSelectionDialog method that is processing the getADate() message can “see” the created SelectDaterPrefsDialog, and hence send it a message, because it has been assigned to a local variable in the method 7/15/2015Copyright W. Howden15

16 Global Variable Object Visibility No examples in the DS Possible ways to do this – static variable in a class that is imported into all subsystems 7/15/2015Copyright W. Howden16

17 Object Visibility in Class Diagrams Relationships shown using: – dotted lines, indicate that: an object of class A has visibility to an object of class B > bracketed labels describe kind of visibility Sample relationship (next slide with diagram) – GUIFrame has parameter visibility to DomainLogic (also had attribute visibility – not shown) 7/15/2015Copyright W. Howden17

18 Additional Relationships OptionSelectionDialog has local variable visibility to EnterMemberDataDialog because the method in OSD that responds to events creates an instance of EMDD that it assigns to one of its local variables SelectDaterPreferencesDialog has parameter visiblity to GUIFrame because a dialog object has to link back to its parent, via a parameter in its constructor 7/15/2015Copyright W. Howden18

19 Copyright W. Howden19

20 Class Visibility Class visibility: class A can “see” another class B Class visibility from class A to class B is required if A contains declarations of objects of type B Object visibility solutions lead to class visibility requirements 7/15/2015Copyright W. Howden20

21 Class Visibility and Class Organization How can we organize our class definitions in such a way that the required class visibility occurs? In Java we have the following methods for organizing our class definitions Inner classes, files, packages, imports We will look at the two examples given for object visibility and consider how their ensuing class visibility requirements can be satisfied 7/15/2015Copyright W. Howden21

22 7/15/2015Copyright W. Howden22

23 Class Visibility and Suggested Solution Class GUIFrame needs to be able to see class DomainLogic, because in the earlier object visibility solution – A class attribute/variable of type DomainLogic was included in the GUIFrame class – The GUIFrame constructor has a parameter of type DomainLogic Solution to the GUIFrame->DomainLogic class visibility requirement – import the DomainLogic package, which contains the DomainLogic class, into the file containing the GUIFrame Class definition 7/15/2015Copyright W. Howden23

24 Copyright W. Howden24

25 Class Visibility and Suggested Solution Class DaterOptionSelectionDialog needs to be able to see class SelectDaterPrefsDialog because in the earlier object visibility solution: – the method in DaterOptionSelectionDialog that responds to the getADateButton event has a local variable of type SelectedDaterPresDialog to which it assigns an instance of this class Solution to the DaterOptionsSelectionDialog -> SelectedDaterPrefsDialog visibility requirement – Both classes are defined as inner classes in GUIFrame. Methods in one class can use the other class. 7/15/2015Copyright W. Howden25

26 Class Visibility Summary Packages: GUI, DL, DB, Globals GUI imports DL and DL imports DB All import Globals, and some standard library classes Some classes in GUI, DL are defined as inner classes to the GUIFrame class but this was not necessary 7/15/2015Copyright W. Howden26

27 Summary 1 We started by identifying some basic concepts and events in our problem domain model Then we selected a system architecture Next we sketched properties of the system interface and the subsystem interfaces using sequence diagrams 7/15/2015Copyright W. Howden27

28 Summary 2 After this we began to determine how how the subsystems react to requests, using collaboration diagrams This resulted in identification of classes and class method signatures After this we considered how to use variables to implement the required object visibility 7/15/2015Copyright W. Howden28

29 Summary 3 Now we are at the point of constructing detailed design descriptions of our classes and their interrelationships Classes will have to be grouped so that if one class needs to see another, it will be able to. We determined how to do this using packages, imports and inner classes. 7/15/2015Copyright W. Howden29

30 Summary 4 We are now ready to start programming – Create Java classes that correspond to the design classes in our design diagrams – Group the classes according to how we solved the class visibility considerations – Write the logic of the methods by considering the logic in the collaboration diagrams which correspond to those methods Next time: designing methods 7/15/2015Copyright W. Howden30

31 Assignment 6 Construct class diagrams for phase 1 Show instances of object visibility in the diagrams, including labels that indicate how the required visibility will be accomplished – attribute, parameter, local variable and global – for each instance of object variability, indicate how the associated required class visibility will be accomplished 7/15/2015Copyright W. Howden31


Download ppt "Lecture 7: UML Class Diagrams CSE 111 7/15/20151Copyright W. Howden."

Similar presentations


Ads by Google