Design Class Diagrams http://flic.kr/p/87iHCA

What are you going to learn about today? Design class diagram notation http://flic.kr/p/8JpkTg

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

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)

Let’s learn UML class diagrams by example

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;

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!

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

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

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

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

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)

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

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

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

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

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

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

Examples of multiplicities 8 Also common to see 0..*

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

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 … …

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()

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

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

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

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. http://flic.kr/p/7SFKjj

Benefits of refinement process Postpones design decisions until ready to make them Manages complexity Less refined designs more abstract http://flic.kr/p/7WYW68

Summary Design as refinement process http://flic.kr/p/YSY3X Summary Design as refinement process Lot o’ class diagram notations and conventions

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Modeling a method

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

Modeling constructors

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

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

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

Three ways to model constraints 1 2 3

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

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

Modeling templates Binding notations:

User-defined compartments

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