1. Design Class Diagrams

2. What are you going to learn about today?
Design class diagram notation

3. Object-Oriented Design
“Define software objects and how they collaborate to satisfy their requirements”
You need to be able to reason about a design
To understand designer’s intent
To critique/improve the design

4. Source code not best medium for reasoning
Lots of redundancy and detail irrelevant for some program understanding tasks
Especially poor at depicting relationships among classes in OO programs
Solution: Use abstract, visual representations— for example, Design Class Diagrams (DCDs)

5. Let’s learn UML class diagrams by example

6. Consider this Java class
UML
public class Airplane {
private int speed;
public Airplane() { }
public void
setSpeed(int speed) {
this.speed = speed; }
public int getSpeed() {
return speed;

7. Based on this UML, how do you model… a class?
Java
UML
public class Airplane {
private int speed;
public Airplane() { }
public void
setSpeed(int speed) {
this.speed = speed; }
public int getSpeed() {
return speed;
Airplane
Box with class name—simple!

8. Based on this UML, how do you model… instance variables and methods?
Java
UML
Attribute compartment
public class Airplane {
private int speed;
public Airplane() { }
public void
setSpeed(int speed) {
this.speed = speed; }
public int getSpeed() {
return speed;
Airplane
speed
setSpeed
getSpeed
Operation compartment

9. Tip: Sketch classes starting from the upper left
Sale
Payment
Store
address

10. Based on this UML, how do you model… constructors?
Java
UML
Constructor stereotype
public class Airplane {
private int speed;
public Airplane() { }
public void
setSpeed(int speed) {
this.speed = speed; }
public int getSpeed() {
return speed;
Airplane
speed
<<constructor>> Airplane
setSpeed
getSpeed

11. Based on this UML, how do you model… attribute types?
Java
UML
Attribute type
public class Airplane {
private int speed;
public Airplane() { }
public void
setSpeed(int speed) {
this.speed = speed; }
public int getSpeed() {
return speed;
Airplane
speed : int
<<constructor>> Airplane
setSpeed
getSpeed

12. Based on this UML, how do you model… method signatures?
Java
UML
public class Airplane {
private int speed;
public Airplane() { }
public void
setSpeed(int speed) {
this.speed = speed; }
public int getSpeed() {
return speed;
Airplane
speed : int
<<constructor>> Airplane()
setSpeed(speed : int)
getSpeed() : int
Parameter list
Return type (omit void)

13. Based on this UML, how do you model… visibility?
Java
UML
public class Airplane {
private int speed;
public Airplane() { }
public void
setSpeed(int speed) {
this.speed = speed; }
public int getSpeed() {
return speed;
Airplane
- speed : int
+ <<constructor>> Airplane()
+ setSpeed(speed : int)
+ getSpeed() : int
- means private
+ means public
# means protected

14. How to model a reference to a class instance?
Java
UML
public class Airport {
... }
public class Airplane {
private Airport home;
private int speed;
Airplane
- speed : int
+ <<constructor>> Airplane()
+ setSpeed(speed : int)
+ getSpeed() : int

15. Like this? Java UML Airplane - home : Airport ✖ - speed : int
public class Airport {
... }
public class Airplane {
private Airport home;
private int speed;
Airplane
- home : Airport
- speed : int
Not like this! ✖
+ <<constructor>> Airplane()
+ setSpeed(speed : int)
+ getSpeed() : int

16. Like this—with an association (arrow)!
Java
UML
public class Airport {
... }
public class Airplane {
private Airport home;
private int speed;
Airplane
- speed : int
+ <<constructor>> Airplane()
+ setSpeed(speed : int)
+ getSpeed() : int * 1
- home
Airport

17. Distinguish between data types and non-data types!
Instances of data types are plain old values
Examples: integers, strings, dates, dollar amounts
No need to distinguish between two instances of the same dollar amount
Instances of non-data types have identity
Examples: Sale, Register, Airport, City, Employee
Even if two employees had the same name and salary, they would still be distinct employee instances
In Design Class Diagrams, model
attributes as data types
associations among non-data types

18. But what are these things?
Airplane
- speed : int
+ <<constructor>> Airplane()
+ setSpeed(speed : int)
+ getSpeed() : int * 1
- home
Airport

19. Examples of multiplicities8
Also common to see 0..*

20. How many Airplanes per Airport? How many Airports per Airplane?
- speed : int
+ <<constructor>> Airplane()
+ setSpeed(speed : int)
+ getSpeed() : int *
1 Airport per Airplane
0 or more Airplanes per Airport 1
- home
Airport

21. Based on this UML, how do you model… inheritance?
Java
UML
public class Airplane {
... }
public class Jet
extends Airplane {
Airplane … …
With a triangle arrow
Jet … …

22. Based on this UML, how do you model… interfaces?
With a dashed triangle arrow
Interface
stereotype
Public operations only
Java
UML
public interface Flyable {
public void fly(); }
public class Airplane
implements Flyable {
public void fly() {
...
<<interface>>
Flyable
+ fly()
Airplane …
+ fly()

23. With these notations, you be able to express the structure of your object-oriented designs

24. Refinement process: Unfolding the design
Design Classes
refine
Implementation
public class Register {
private int id;
private Sale currentSale;
... }
public class Sale {
private DateTime time;
... }

25. Refinement is not mechanical
class City {
...
protected:
string cityName;
unsigned population;
vector<Airport*> serves; };
class Airport {
string airportName;
CODE airportCode;
ZONE timeZone;
vector<City*> serves;
One possible refinement
class City {
...
protected:
string cityName;
unsigned population; };
class Airport {
string airportName;
CODE airportCode;
ZONE timeZone;
multimap<City*, Airport*> cityServes;
multimap<Airport*, City*> airportServes;
Another possible refinement

26. A word about agile modeling (quoting Larman)
Experienced analysts and modelers know the secret of modeling:
Thus, we favor hand-drawn diagrams over typeset ones
The purpose of modeling (sketching UML, …) is primarily to understand, not to document.

27. Benefits of refinement process
Postpones design decisions until ready to make them
Manages complexity
Less refined designs more abstract

28. Summary Design as refinement process
Summary
Design as refinement process
Lot o’ class diagram notations and conventions

29. Now, I’m going to introduce a bunch of new class diagram notations and conventions to help you make your DCDs more expressive (All notations from last time still apply)

30. Full format of attribute notation
Class
attr op
visibility name : type multiplicity = default {property}
Examples:

31. Full format of attribute notation
Class
attr op
visibility name : type multiplicity = default {property}
Examples:

32. Full format of attribute notation
Class
attr op
visibility name : type multiplicity = default {property}
Examples:

33. Visibility + Public - Private # Protected ~ Package
Any class that can see the containing class can see
- Private
Only containing class can see
# Protected
Only containing class and its descendants can see
~ Package
Only classes within containing package can see

34. Full format of attribute notation
Class
attr op
visibility name : type multiplicity = default {property}
Examples:

35. Full format of attribute notation
Class
attr op
visibility name : type multiplicity = default {property}
Examples:

36. Full format of attribute notation
Class
attr op
visibility name : type multiplicity = default {property}
Examples:

37. Full format of operation notation
Class
attr op
visibility name (parameters) : return-type {property}
Examples:

38. Full format of operation notation
Class
attr op
visibility name (parameters) : return-type {property}
Examples:

39. Full format of operation notation
Class
attr op
visibility name (parameters) : return-type {property}
Examples:
Same as with attributes

40. Full format of operation notation
Class
attr op
visibility name (parameters) : return-type {property}
Examples:

41. Full format of operation notation
Class
attr op
visibility name (parameters) : return-type {property}
Examples:

42. Modeling attributes and associations
public class Register {
private int id;
private Sale currentSale;
... }
public class Sale {
private DateTime time;

43. Distinguish between data types and non-data types!
Instances of data types are plain old values
Examples: integers, strings, dates, dollar amounts
No need to distinguish between two instances of the same dollar amount
Instances of non-data types have identity
Examples: Sale, Register, Airport, City, Employee
Even if two employees had the same name and salary, they would still be distinct instances
In Design Class Diagrams, model
attributes as data types
associations among non-data types

44. Modeling an ordered list
Multiplicity Properties:
set
unordered, unique elements (default)
bag
unordered, non-unique elements
ordered set
ordered, unique elements
list (or sequence)
ordered, non-unique elements

45. Modeling a method

46. Omit setter and getter operations from design classes
Added noise outweighs value
Assume you have them if you need them

47. Modeling constructors

48. Generalization implies inheritance
Objects of subclass have all attributes and methods of superclass

49. Modeling dependencies
public class Foo {
public void doX() {
System.runFinalization();
... }
Foo depends on System
Model like this

50. Modeling interfaces
An interface is essentially an abstract class with only abstract, public operations (no attributes and no methods)

51. Three ways to model constraints1 2 3

52. Modeling hashes with qualified associations
Multiplicities are different than usual:
(catalog, ID)  1 description
description  1 (catalog, ID)
Implies catalog  0..* description
Key type If numbers, could be itemID : Integer

53. Modeling relationships with association classes
Each link between a Company object and a Person object is an instance of Employment

54. Modeling templates
Binding notations:

55. User-defined compartments

56. Modeling active objects
Each instance of Clock has its own thread of control that executes within run()
Note the bars