1. Class Diagrams Oct 20, 2006

2. Recap: CRC Cards Process
Initial class list
Refined class list
while (More use case scenarios left) do
Take a use case scenario
Assign responsibilities to classes
Find super- and sub-classes
Find collaborators od
Remember, Initial class list often comes from domain model and use case scenarios
Often a limited number of use case scenarios are considered.
Division into responsibilities, which together fulfill the users’ goal is often partially done in the sequence diagram (in the analysis phase)
Question: Why only partially?

3. Today’s Lecture Class Diagrams Basics Class Diagram Notations
Classifier, attributes, operations
Interface implementation, subclassing
Dependency
Associations (multiplicities)
Application of information hiding and DSMs

4. Example: Switch-Motor System
Scenario: Motor can run, when the Switch state is on
Class list: Switch and Motor
R1: Store the decision condition
R2: Make a decision
R3: Run the motor

5. Class Diagram UML Design Notation
Shows classes, their attributes and methods
Interfaces
Collaborations
Dependency, Generalization, Relationships
Remember: Design - complete description of structure and partial description of function
A class diagram describes the structure

6. Class Diagram View Switch Motor -state:bool -switch:Switch1
-state:bool
-switch:Switch
switch
+getState():bool
+run()
Class Diagram: three parts – class name, attributes, and operations
The first part may also contain stereotypes.

7. Common Stereotypes <<interface>>
<<type>> structure & behavior
<<enumeration>> collection of discrete values
<<implementationClass>> helper class
<<class>> is assumed by default

8. * Also multiplicity, default value, and property
Attribute Name, Types
Motor
- switch : Switch
+run()
Visibility
Attribute
Type
Attribute
Name
* Also multiplicity, default value, and property

9. Visibility public → + private → - protected → # package → ~
derived → /

10. Alternative Notation Motor +run() Switch -state:bool +getState():bool
Multiplicity 1
switch
Association
(Containment)

11. Operations: Visibility, Args, Return Types
Switch
-state : bool
+getState(): bool
+setState(bool)
Return Type
Visibility
Operations
Argument Type

12. A Slightly Complex Example
SortingApplication
storage:IStorage
sort:ISort
<<interface>>
IStorage
+add(int)
+length():int
+itemAt(int):int
+setAt(int, int)
+createNew():IStorage 1
sort
storage
+Main(string[]):int 1
<<interface>>
ISort
+sort(IStorage)
MergeSort …
QuickSort
A new type of arrow: Interface implementation, subclassing arrows
Why is IStorage interface designed like this? (Why createNew?)
Do we need to convert from IStorage to arrays and back now?
What are some design decision that are likely to change here?
Decision to stick to two chosen list representations might change
Is the implementation robust against that? How?
Decision to use a sorting representations might change
Is this implementation robust against that? How?
Decision to have only lists of integers might change
What will be the effect of this change?
On storage components?
On sorting components?
On the application module?
On the UI module?
Array …
+add(int)
LinkedList …
+add(int)

13. Hiding Design Decision
<<interface>>
IElement
IntElement
item:int
+get():int
+set(int)
SortingApplication
0..* 1
storage:IStorage
sort:ISort
<<interface>>
IStorage
+add(IElement)
+length():int
+itemAt(int):IElement
+setAt(int, IElement)
+createNew():IStorage 1
sort
storage
+Main(string[]):int 1
<<interface>>
ISort
+sort(IStorage)
MergeSort …
QuickSort
A new type of arrow: composition
What does IElement accomplishes here?
What is missing from IElement interface declaration?
Comparison
Cloning
User interface might change
What are some additional dependencies in this application?
Array …
+add(IElement)
LinkedList …
+add(IElement)

14. Additional Dependencies
<<interface>>
IElement
IntElement
item:int
+get():int
+set(int)
0..* 1
<<interface>>
IStorage
+add(IElement)
+length():int
+itemAt(int):IElement
+setAt(int, IElement)
+createNew():IStorage
sort
SortingApplication 1 1
storage:IStorage
sort:ISort
storage
<<interface>>
ISort
+sort(IStorage)
MergeSort …
QuickSort
+Main(string[]):int
What is the remaining problem with this implementation? (if any)
Main control module, center of all dependence (We will learn about factory method in the later part of this class.)
What is the architectural style that this system is organized in?
Array …
+add(IElement)
LinkedList …
+add(IElement)

15. Architectural Style: Layered
<<interface>>
IElement
SortingApplication
storage:IStorage
sort:ISort
+Main(string[]):int
IntElement
item:int
+get():int
+set(int)
0..* 1
<<interface>>
IStorage
+add(IElement)
+length():int
+itemAt(int):IElement
+setAt(int, IElement)
+createNew():IStorage 1
storage
sort 1
<<interface>>
ISort
+sort(IStorage)
MergeSort …
QuickSort
Layer 2
Layer 1
Is it strictly layered? Why? Why not?
How can we make it strictly layered?
Array …
+add(IElement)
LinkedList …
+add(IElement)

16. Architectural Style: 3-tiered
<<interface>>
IElement
SortingApplication
storage:IStorage
sort:ISort
+sort(…):IStorage
IntElement
item:int
+get():int
+set(int)
0..* UI
app:SortingApplication
+Main(string[]):int 1
<<interface>>
IStorage
+add(IElement)
+length():int
+itemAt(int):IElement
+setAt(int, IElement)
+createNew():IStorage 1 1
storage
app
sort 1
<<interface>>
ISort
+sort(IStorage)
MergeSort …
QuickSort
Layer 3
Layer 2
Layer 1
What else changed here?
Consider the design decision that user will input at console, and user will received output at console.
Array …
+add(IElement)
LinkedList …
+add(IElement)

17. Design Structure Matrix View: Naïve Design1 2 3 4 5 6 7 8 9
Input Type : 1 .
Output Type : 2
Sorting Type: 3
Storage Type: 4
Element Type: 5
UI Type: 6
Sorting Module: 7 X
Storage Module: 8
Master Module: 9

18. DSM View: Sorting Type & Storage Type Hidden1 2 3 4 5 6 7 8 9 10 11
Input Type : 1 .
Output Type : 2
Sorting Type: 3
Storage Type: 4
Element Type: 5
UI Type: 6
Sorting Module: 7 X
Storage Module: 8
Master Module: 9
Storage Interface: 10
Sorting Interface: 11

19. DSM View: Element Type Hidden1 2 3 4 5 6 7 8 9 10 11 12 13
Input Type : 1 .
Output Type : 2
Sorting Type: 3
Storage Type: 4
Storage Element Type: 5
UI Type: 6
Sorting Module: 7 X
Storage Module: 8
Master Module: 9
Storage Interface: 10
Sorting Interface: 11
Element Interface: 12
Element Module: 13

20. DSM View: UI Type Hidden1 2 3 4 5 6 7 8 9 10 11 12 13 14
Input Type : 1 .
Output Type : 2
Sorting Type: 3
Storage Type: 4
Storage Element Type: 5
UI Type: 6
Sorting Module: 7 X
Storage Module: 8
Sorting Control Module: 9
Storage Interface: 10
Sorting Interface: 11
Element Interface: 12
Element Module: 13
User Interface Module: 14

21. Reorganized Final DSM View1 2 3 4 5 6 7 8 9 10 11 12 13 14
Input Type : 1 .
Output Type : 2
User Interface Type: 3
User Interface Module: 4 X
Sorting Control Module: 5
Storage Element Type: 6
Storage Element Interface: 7
Storage Element Module: 8
Storage Type: 9
Storage Interface: 10
Storage Module: 11
Sorting Type: 12
Sorting Interface: 13
Sorting Module: 14

22. Summary Class diagrams represent design structure
Three parts: name, attribute, operations
Visibility, attribute type, multiplicity
Association, association multiplicity
Generalization i.e. interface impl, subclassing
Composition i.e. class A contains class B
Applied information hiding, DSM, layering

24. Problem Description: design and implement a sorting application for positive integers. This application must:
R1: Ask the user for an input list of numbers;
R2: Ask the user for the choice of storage technique for the numbers. Two storage techniques are supported Array that inherits from java.util.ArrayList and Linked List that inherits from java.util.LinkedList,
R3: Ask the user for the choice of sorting algorithm. Two sorting algorithms merge sort and quick sort, are supported.
R4: Sort the numbers, and
R5: Output the sorted numbers.
Initial Class List:
Refined Class List: