UML Class Diagrams Sipping from the Fire Hose

1. UML Class DiagramsSipping from the Fire Hose

2. Class diagrams depict the static relationships that exist between classes. REMEMBER! In general, you are only guaranteed what you see, not what you don’t.

3. Forms of the UML Class Notation Fully Expanded Fully Elided ClassName ClassName <attributes> <operations> Partially Elided (operations only) Partially Elided (attributes only) ClassName ClassName <attributes> <operations>

4. Visibility and Static notations Visibility Static Public:+name Private: -name Protected: #name Package: ~name Underline : name or Dollar sign: $name

5. Attributes represents characteristics of a class. Generic Form for an Attribute [stereotype][visibility] name [: type [= initial value]] Note: [ ] mean optional. So, we can optionally show stereotype, visibility, type, etc.

6. Attribute Examples No information about type No information about default value Attribute is not static (has instance scope) Unspecified visibility (often assumed private) name No information about type No information about default value Attribute is not static (has instance scope) Attribute is protected # name Is an instance or reference to an instance of the class, String (language dependent) No information about default value Attribute is not static (has instance scope) Attribute is protected # name : String

7. Attribute Examples No information about type No information about default value Attribute is static (has class scope) Attribute is private - count Is an instance of int Has initial value of 0 Attribute is static (has class scope) Attribute is public + count : int := 0 Example of a constant attribute (uses the frozen constraint) # name : String = “Fred” {frozen}

8. Operations represent processes that a class knows how to execute. Generic Form for an Operation [stereotype] [visibility] [static] name ([parameter list]) [: return type] Parameter List is defined as [direction] name [ : type [= default value]] Direction is either in, out, or inout. When unspecified, it is assumed to be in.

9. Operation Examples No information about return type No information about parameters Operation has instance scope Visibility unspecified (often assumed public) getCount() Returns an instance of int No information about parameters Operation has instance scope Operation is public + getCount() : int Operation is public Operation has instance scope Has an “in” parameter “to” of type “String” Returns value of type “Status” + updateName (in to : String) : Status

10. Operation Examples

11. Class Examples – Elided vs. Expanded Fully Elided Fully Expanded BillardBall BillardBall # position : Position # direction : float # energy : float init(in atPosition : Position) : void hitBy (in ball : BillardBall) : void currentPosition() : Position

12. Class Example - Dog Java UML - Fully expanded public class Dog { private Breed breed; private intageInYears; private Name name; private booleanisFixed; private booleanisHungry; private booleanisAsleep; private booleanisBarking; publicbooleanisHungry() {...}; publicbooleanisAsleep() {...}; public void eat() {...}; public void speak() {...}; public void hush() {...}; } Dog - breed : Breed - ageInYears: int - name : Name - isFixed: boolean - isHungry: boolean - isAsleep: boolean - isBarking: boolean isHungry() : boolean isAsleep() : boolean eat() : void speak() : void hush() : void

13. Class Example – Dog Java UML - Fully Elided Dog public class Dog { private Breed breed; private intageInYears; private Name name; private booleanisFixed; private booleanisHungry; private booleanisAsleep; private booleanisBarking; publicbooleanisHungry() {...}; publicbooleanisAsleep() {...}; public void eat() {...}; public void speak() {...}; public void hush() {...}; } UML - Partially Elided Dog isHungry() : boolean isAsleep() : boolean eat() : void speak() : void hush() : void

14. On to relationships…

15. UML provides notations for describing the type of relationship that can exist between two classes. Dependency Association Aggregation Composition Generalization Realization

16. Dependency is the weakest relationship and implies a target change may affect the source. • Represented by a dashed arrow • Further investigation is required to understand Position BilliardBall

17. A dependency can occur via formal parameters or by local variables within a method. This is a transient relation. public class BilliardBall { private int color; private int number; private intxPixel; private intyPixel; public void setPosition (Position p) {…} public void hitBy (BilliardBall b) {…} public void draw() {…} }; public class Position { private double x; private double y; private double z; public void moveTo (double x, double y, double z) {…} public void tranform (Matrix matrix) {Matrix t; …} };

18. Attributes of another class type are persistent relationships and are stronger than transient. public class BilliardBall { private int color; private int number; private Position position; public void setPosition (Position p) {…} public void hitBy (BilliardBall b) {…} public void draw() {…} }; public class Position { private double x; private double y; private double z; public void moveTo (double x, double y, double z) {…} public void tranform (Matrix matrix) {…} };

19. UML provides different notations to denote different types of relationships. • To some degree, other relationships are a form of dependency • Stereotypes can be used to create relationship types not part of the standard notations

20. Association • Directed relationship • Represented by a regular line with an arrow • May be bi-directional • Represented by a line (no arrow heads) • Implies that an instance of the source is aware of an instance of the target

21. An association is a directed relationship that indicates the source is associated to one or more instances of the target. Unidirectional Association Car Road Bidirectional Association Professor University

22. IST 240 Method: • Associations require an attribute • Associations will have “set” operations • Ex: ‘set*’ ‘add*’ • Other option: use constructor • Associations may have ‘get’ operations • Examples: ‘get*’ or ‘find*’ or ‘to*’ • May be “get” like (e.g., find*())

23. Source Code Example - Unidirectional public class Car { private Road currentRoad; private intspeedInMPH; public void setCurrentRoad(Road r){…} public Road getCurrentRoad() {…} public void setSpeedInMPH (intnewSpeedInMPH) {…} public void setSpeedInKPH (intnewSpeedInMPH) {…} public intgetSpeedInMPH() {…} public intgetSpeedInKPH() {…} } public class Road { private String name; private int speedLimitInMPH; public void setName(String name) {…} public void setLimitInMPH (int limitInMPH) {…} public void setLimitInKPH (int limitInKPH) {…} pubic String getName() {…} public int getLimitInMPH() {…} public int getLimitInKPH() {…} };

24. Source Code Example - Bidirectional class Professor { private String name; private CV cv; private University currentEmployer; public void setUniversity (University u) {…} public void displayCV() {…} } class University { private Professor professors[100]; private intcurrentNumberOfProfessors; public void hireProfessor (Professor p) {…} public void fireProfessor (Professor p) {…} }

25. Associations may have role namesand multiplicity. Multiplicity Options [ 0 <= n <= m ] n exactly n n.. * at least n * Unspecified * .. m at most m n .. m between n and m

26. Examples of role names and multiplicity. Unidirectional Association * 0..1 Car Road currentRoad Bidirectional Association * 1 Person University employee employer

27. Shared Aggregation represents “part of” but not “ownership”. • It is more notional than anything. • It acts like an association. 1 0..1 Car Driver currentDriver

28. Shared Aggregation can also be bidirectional. 0..1 0..1 Car Driver currentDriver

29. IST 240 Method • Aggregations require an attribute • Aggregations may/may not have “set” operations for the attribute • Aggregations may/may not have “get” operations for the attribute

30. Source Code Example public class Car { private Road currentRoad; private intspeedInMPH; private Driver currentDriver; public void setCurrentRoad(Road r){…} public Road getCurrentRoad() {…} public void setDriver(Driver d){…} public Driver getDriver() {…} public void setSpeedInMPH (intnewSpeedInMPH) {…} public void setSpeedInKPH (intnewSpeedInMPH) {…} public intgetSpeedInMPH() {…} public intgetSpeedInKPH() {…} } public class Driver { private String name; private booleanisDriving; private Car currentCar; public void drive() {…} public void stopDriving() {…} public void setCar(Car car) {…} public Car getCar() {…} };

31. Composite Aggregation, or composition, represents ‘ownership’. 4 Car Wheel myWheels Note: The composee cannot outlive the composer.

32. IST 240 Method • Compositions require an attribute • Compositions do not have “set” operations for the attribute • Compositions may have “get” operations for the attribute • Need to do this carefully!

33. Source Code Example public class Car { private Road currentRoad; private intspeedInMPH; private Driver currentDriver; private Wheel wheels[]; public Car() wheels = new Wheel[4]; for (int w=0; w<wheels.length; ++w) wheels[w] = new Wheel(); } } public void setCurrentRoad(Road r){…} public Road getCurrentRoad() {…} public void setDriver(Road r){…} public Driver getDriver() {…} public void setSpeedInMPH (intnewSpeedInMPH) {…} public void setSpeedInKPH (intnewSpeedInMPH) {…} public intgetSpeedInMPH() {…} public intgetSpeedInKPH() {…} }

34. Putting It Together 4 0..1 Wheel Car Road 0..1 Driver

35. Composition vs. Shared Aggregation • Composers cannot share instances composees • Composees cannot outlive their composer. 0..1 Car Owner owner 4 Car Wheel

36. With aggregation, two instances of the source can share the same instance(s) of the target. 0..1 :Car :Owner Car Owner owner :Car  The same Owner instance is associated to two different Car instances.

37. Aggregation permits instances of the target to be shared with instances of other non-composing classes. A B :A :B :D :C D C  This is okay.

38. With composition, two instances of the source object cannot share the same instance(s) of the target. 4 Car Wheel :Wheel :Car owner :Wheel :Wheel :Wheel :Car Key concept: An instance of the composeecannotoutlive the instance of the composer.  The same Wheel instances are associated to two different Car instances.

39. Compositions are tricky. :A :B :C A B C  An instance of B cannot be owned by two instances of different classes.

40. Compositions are tricky. :A :B :C A B C  This is fine … BUT… A B C What happens when the A instance is destroyed?

41. Remember: The design constrains the implementation. These all need to be implemented correctly. Often this means that the code must be inspected as a whole and not just looking at a couple classes. A B C A B C A B C

42. IST 240 Method • Don’t use shared aggregation • Shared aggregation can be modeled using an association

43. Generalization/Specialization represents subclassing. Vehicle AquaticVehicle LandVehicle Sub Boat Tank Auto

44. Source Code Example Vehicle public class Vehicle { . . . }; public class AquaticVehicle extends Vehicle { . . . }; public class Sub extends AquaticVehicle { . . . }; AquaticVehicle Sub

45. Realization <<interface>>Vehicle public interface Vehicle { . . . }; public class AquaticVehicleimplements Vehicle { . . . }; AquaticVehicle Vehicle AquaticVehicle

46. Use UML relationships to model the MediaPlayer system.

47. Class diagrams can get complicated quickly. You will need to use multiple diagrams to communicate effectively. • Consider a clock: • Potential classes: • Clock • Display • SixtySecondTimer • Alarm • TimeManager Set Time Set Alarm Alarm On Alarm Off Hour Minute Snooze • ButtonManager • ModeManager • Time • Mode (enumeration)

48. Clock TimeManager SixtySecondTimer + TimeManager() + setDisplay(newDisplay : Display) : void + setModeManager(newModeMgr : ModeManager) : void + setAlarm(newAlarm : Alarm) : void + SixtySecondTimer() + setTimeManager (newTimeMgr : TimeManager : void + start() : void -timer -timeMgr -display Clock ModeManager -modeMgr Display +Clock() + start() : void + ModeManager() + Display() -buttonMgr ButtonManager Alarm -alarm + ButtonManager() + setModeManager(newModeMgr : ModeManager) : void + setTimeManager(newTimeMgr : TimeManager) : void + Alarm()

49. TimeManager Time TimeManager + TimeManager() + setDisplay(newDisplay : Display) : void + setModeManager(newModeMgr : ModeManager) : void + setAlarm(newAlarm : Alarm) : void + incrementCurrentMinute() : void + incrementCurrentHour() : void + incrementAlarmHour() : void + incrementAlarmMinute() : void + snooze() : void + showCurrentTime() : void + showAlarmTime() : void + Time(initHour : int, initMinute : int) + addOneMinute() : void + incrementHour() : void + incrementMinute() : void + getHour() : int + getMinute() : int +equals(time : Time) : boolean -modeMgr ModeManager + getCurrentMode() - currentTime - alarmTime - snoozeTime Alarm -display Display -alarm + on() + off() + showHour(newHour : int) : void + showMinute(newMinute : int) : void

50. ButtonManager ButtonManager TimeManager + incrementCurrentMinute() : void + incrementCurrentHour() : void + incrementAlarmHour() : void + incrementAlarmMinute() : void + snooze() : void + showCurrentTime() : void + showAlarmTime() : void + ButtonManager() + doIncrementHour() : void + doIncrementMinute() : void + doSnooze() : void + doSetTime() : void + doSetAlarm() : void + doAlarmOn() : void + doAlarmOff() : void + setModeManager(newModeMgr : ModeManager) : void + setTimeManager(newTimeMgr : TimeManager) : void -timeMgr <<enumeration>> Mode -modeMgr ModeManager + SET_ALARM + SET_TIME + ALARM_ON + ALARM_OFF + setMode(newMode : Mode) : void + getMode() : Mode