1. A Review or Brief Introduction
UML Class Diagrams
A Review or Brief Introduction
Copyright © 2016 Curt Hill

2. Introduction
In this presentation we wish to consider the most common UML diagrams in our trade
These are class diagrams
These are how we rough out the design of programs and systems in an Object Oriented fashion
Copyright © 2016 Curt Hill

3. Class The basic class is a rectangle with one to three pieces
The top portion is the class name
The properties occur in one of the pieces and the methods in another
Properties may be described by attributes or associations
If the class is described already we may leave it at just a name
Copyright © 2016 Curt Hill

4. Attribute Notation
Each attribute is described in a way similar to what you might see in a programming language
The general form is: vis name: type mult = def {propstr}
Where
Vis is visibility (+ or -)
Name and type are obvious
Mult is multiplicity
Def is default
Propstr shows other characteristics
Name is only one that is required
Copyright © 2016 Curt Hill

5. Multiplicity How many are there? Usually in brackets
If absent there is just one
This is how an array or other container class would be notated
A range is shown by a two dot ellipsis
[0..1]
An * signifies zero or more
Copyright © 2016 Curt Hill

6. Visibility UML is designed to work with any language
Therefore it has four visibility symbols
+ public
- private
# protected
~ package
These may have subtle differences from programming languages
However those differences are not important here
Copyright © 2016 Curt Hill

7. Example Here is the day from the infamous CurtDate - day: char [1]
Here is another: -title: String = “None” {readonly}
Next we look at a diagram
Copyright © 2016 Curt Hill

8. An Order Object Order + received: Date [0..1] + isPrepaid: Boolean [1]
+ lines: OrderLine[*] {ordered}
Copyright © 2016 Curt Hill

9. Associations
An association is a graphical way to do similar things as attributes
A solid line between two classes indicates an association
The contained class has the name, multiplicity and other characteristics on its end
Copyright © 2016 Curt Hill

10. Order Again Order Date Boolean OrderLine received 0..1 isPrepaid 1
lines {ordered}
Boolean *
OrderLine
Copyright © 2016 Curt Hill

11. BiDirectional Association
A bidirectional association is also possible
Denoted by double headed arrow
For two items to refer to each other usually implies pointers in C++
Such as a car object pointing at its owner with a person object pointing at an owned car
Copyright © 2016 Curt Hill

12. Implementable Class
How would we implement such a class in C++ or any other language?
Most of the primitive types are obvious
Variables such as lines would likely use a collection or container class
Private variables may have a set/get pair of methods but a readonly variable would have get without set
The next screen is an example
Copyright © 2016 Curt Hill

13. One More Time on Order class Order { private: Date received;
bool isPrepaid;
list<OrderLine> lines;
public:
Date getReceived(){
return received;}
void setReceived (Date d){
received = d; }
... };
Copyright © 2016 Curt Hill

14. Methods Methods are the operations of classes
They implement the behaviors of the class
The notation looks very similar to the attribute notation
Also similar to a prototype notation of some languages
We see what it takes to declare without implementation details
Copyright © 2016 Curt Hill

15. Methods Again The general form is: vis name (parms) : rtype {propstr}
Where
Vis is visibility (+ or -)
Name is obvious
Parms are parameters and use attribute notation
Rtype is return type
Propstr shows other characteristics
Copyright © 2016 Curt Hill

16. Parameters Again
One feature that a parameter has that an instance variable or static variable does not is direction
The three directions are: in
out
inout
Leaving direction off assumes in
Notice that C++ and Java do not distinguish between inout and out but some languages do
Copyright © 2016 Curt Hill

17. Setters and Getters
Many classes have set and get methods that give access to a single instance variable
These are usually named something like setX and getX
Where X is the variable name
These are usually left out of the UML
They do not tell us much in regards to behavior
Constructors are also often left out
Copyright © 2016 Curt Hill

18. Generalization
This is a term that refers to a concept usually implemented with inheritance
An ancestral class is a generalization of descendent classes
If we want the ancestral class we could actually receive the descendent class
Recall the person hierarchy: a person is a generalization of a student or employee
Copyright © 2016 Curt Hill

19. Person Example Continued
If a method/function requires a Person
We should be able to pass an employee or student or gradstudent
Similarly, anything that uses a student should be able to accept a gradstudent as well
Copyright © 2016 Curt Hill

20. Customer Example
We may have a distinction between customers that are individual people and those that are corporations
We accomplish this by having a Customer class which contains the similarities and derive a CorporateCustomer and PersonalCustomer class
We then state that Customer is a generalization of either of these
Copyright © 2016 Curt Hill

21. Generalization
Inheritance is usually denoted by the ancestral class (or super class or base class) shown higher
Derived classes (subclasses or subtypes) are below and point to the ancestral class
Copyright © 2016 Curt Hill

22. Person Hierarchy Person -name: string getAge(): Date Employee Student
-wage: float
-hours: int
-hours: int
-points: int
getPay(): float
getGPA (): float
Copyright © 2016 Curt Hill

23. Generalization Again Although UML is supposed to be standard
It is only as standardized as the user
There are variations in form
For example sometimes the generalization arrow is more a triangle to distinguish from other arrows
Copyright © 2016 Curt Hill

24. Person Hierarchy Again
-name: string
getAge(): Date
Employee
Student
-wage: float
-hours: int
-hours: int
-points: int
getPay(): float
getGPA (): float
Copyright © 2016 Curt Hill

25. Notes and Comments Sometimes we may want some explanation
These are attached in a rectangle with folded corner attached with a dotted line to whatever it describes
Copyright © 2016 Curt Hill

26. Commented Class Person -name: string getAge(): Date
Could be part of U or not
getAge(): Date
Copyright © 2016 Curt Hill

27. Dependency
A dependency exists whenever a change to one class mandates a change to another
Change in class structure/interface
Not a change in object value
These occur for several reasons
Class contains another class
Class method uses another class as a parameter
Class calls method of another class
Copyright © 2016 Curt Hill

28. Dependencies Again These are things that need to be monitored
Too many dependencies make a system difficult to maintain
One change has a large ripple effect
Dependencies are shown by a dashed arrow
The dependent item points to that on which it depends
Copyright © 2016 Curt Hill

29. An Example Order Customer CorpCust PrsnCust OrderLine * * 1 Product
dateReceive: Date
isPrepaid: boolean
Price: Money 1 *
Name [1]
Address [0..1]
getCreditRating(): string
Dispatch
close 1
If credit rating is “poor” then isPrepaid must be true
lineitems
* ordered
PrsnCust
CorpCust
OrderLine
creditCard
creditLimit
contactName
Quantity: integer
Price: Money
monthBill(int) * * 1
salesRep
0..1
Product
Employee
Copyright © 2016 Curt Hill

30. Finally Probably need another dose of this Copyright © 2016 Curt Hill
Needs a few more examples too
Copyright © 2016 Curt Hill