1. Design Class Diagrams

2. What are you going to learn about today?
How to go from
Domain Models
to Design Classes
to Implementation Classes
More class diagram notations and conventions
to make your Design Class Diagrams great!

3. Iterative Development Process
We are here
Planning
Requirements
Analysis
Design
Implementation
Deployment
Testing
Evaluation
Initial Planning

4. Object-Oriented Design
“Define software objects and how they collaborate to satisfy their requirements”
How do you decide if your designs are “good”?
You need to be able to reason about a design
To understand designer’s intent
To critique/improve the design

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

6. Differences between Domain and Design models
Navigability
Navigability: “Knows about.” For example a register knows about (stores info regarding) the sale it captures, but a sale does not know about the register that captured the sale.
Attribute types
Operations compartment

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26. Modeling a method

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

28. Modeling constructors

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

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

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

32. Three ways to model constraints1 2 3

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

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

35. Modeling templates
Binding notations:

36. User-defined compartments

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

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