lecture 7: uml class diagrams cse 111 7/15/20151copyright w. howden

Lecture 7:UML Class Diagrams

CSE 111

04/19/23 1Copyright W. Howden

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

04/19/23 Copyright W. Howden 2

Copyright W. Howden 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

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

04/19/23 Copyright W. Howden 4

Copyright W. Howden 5

GUIFrame LogOnDialog

OptionSelectionDialog

SelectDaterPrefsDialog EntermemberDataDialog SelectedDateeDialog

MessageDialog

DomainLogic <<parameter>>

<<Local Variable>>

<<attribute>>

<<attribute>>

Attribute

<<parameter>>

<<parameter>>

<<parameter>>

Copyright W. Howden 6

+setVisible()+show()+buttonAction(in id : int)+DaterOptionSelectionDialog(in gUIGuiFrame)

+getADate: Button+setMemberData: Button-parentFrame: Frame

DaterOptionSelectionDialog

+show()+setVisible()+LogOnDialog(): LogOnDialog()+buttonAction(in id:buttonID)

+OKButton: Button+nameField: TextField-parentFrame: Frame

LogOnDialog

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

04/19/23 Copyright W. Howden 7

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.

04/19/23 Copyright W. Howden 8

Copyright W. Howden 9

1b: [Button = Start] show()

dL : DomainLogic

: LogOnDialog : GUIFrame

System

GUI Frame Presentation Logic

3a: [1b & userType == MEMBER] show()

2: [1b] userType = getUserType()

3b: [1b & userType = UNAUTH] create(gUI, "Unauthorized")4: [1b & userType = UNAUTH] show()

1a: [Button == End] Exit

Start/End Button

: DaterOptionSelectionDialog

: MessageDialog

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

04/19/23 Copyright W. Howden 10

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

04/19/23 Copyright W. Howden 11

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

04/19/23 Copyright W. Howden 12

Copyright W. Howden 13

6b: [mD == null] create(gUI, "No Date")7b: [mD == null] show()

6a: [mD /= null] create (gUI, mD.name, mD.dateeData)7a: [ mD /= null] show()

: DaterOptionSelectionDialog : SelectDateePropsDialog

daterPrefs : DaterPreferences

: SelectDaterPrefsDialog

dL : DomainLogic

: MessageDialog

GetADateButton

4: userName = getUserName()5: mD = getDate(userName, daterPrefs)2: create()

3: show()

1: create()

8: setVisible(false)

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

04/19/23 Copyright W. Howden 14

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

04/19/23 Copyright W. Howden 15

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

04/19/23 Copyright W. Howden 16

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)

04/19/23 Copyright W. Howden 17

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

04/19/23 Copyright W. Howden 18

Copyright W. Howden 19

GUIFrame LogOnDialog

OptionSelectionDialog

SelectDaterPrefsDialog EntermemberDataDialog SelectedDateeDialog

MessageDialog

DomainLogic <<parameter>>

<<Local Variable>>

<<attribute>>

<<attribute>>

Attribute

<<parameter>>

<<parameter>>

<<parameter>>

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

04/19/23 Copyright W. Howden 20

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

04/19/23 Copyright W. Howden 21

04/19/23 Copyright W. Howden 22

1b: [Button = Start] show()

dL : DomainLogic

: LogOnDialog : GUIFrame

System

GUI Frame Presentation Logic

3a: [1b & userType == MEMBER] show()

2: [1b] userType = getUserType()

3b: [1b & userType = UNAUTH] create(gUI, "Unauthorized")4: [1b & userType = UNAUTH] show()

1a: [Button == End] Exit

Start/End Button

: DaterOptionSelectionDialog

: MessageDialog

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

04/19/23 Copyright W. Howden 23

Copyright W. Howden 24

6b: [mD == null] create(gUI, "No Date")7b: [mD == null] show()

6a: [mD /= null] create (gUI, mD.name, mD.dateeData)7a: [ mD /= null] show()

: DaterOptionSelectionDialog : SelectDateePropsDialog

daterPrefs : DaterPreferences

: SelectDaterPrefsDialog

dL : DomainLogic

: MessageDialog

GetADateButton

4: userName = getUserName()5: mD = getDate(userName, daterPrefs)2: create()

3: show()

1: create()

8: setVisible(false)

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.

04/19/23 Copyright W. Howden 25

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

04/19/23 Copyright W. Howden 26

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

04/19/23 Copyright W. Howden 27

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

04/19/23 Copyright W. Howden 28

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.

04/19/23 Copyright W. Howden 29

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

04/19/23 Copyright W. Howden 30

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

04/19/23 Copyright W. Howden 31