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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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