Class Diagrams Oct 20, 2006

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?

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

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

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

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

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

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

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

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

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

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)

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)

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)

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)

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)

Design Structure Matrix View: Naïve Design 1 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

DSM View: Sorting Type & Storage Type Hidden 1 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

DSM View: Element Type Hidden 1 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

DSM View: UI Type Hidden 1 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

Reorganized Final DSM View 1 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

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

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: