Class diagrams

Class Diagrams Depicting Classes and Static Relationships

UML Class Diagrams Class diagrams allow us to express classes in UML Including attributes and methods Class diagrams allow us to declare our classes (visually)

Classes in UML HockeyPlayer Person Kiwi Class Names Athlete Fruit Apple

Classes in UML As you can imagine, the class shapes shown here are a major part of class diagrams Both forms are acceptable for classes that have no attributes or methods The two empty blocks are used for holding declarations of attributes and methods The top block is used to hold the class name

Attributes in Classes Athlete teamName: String Person age: Duration height: Length Fruit numSeeds: Integer Apple skinColour: Colour diameter: Length

Attributes in Classes Attributes are specified using the form: name : type This format is taken from Eiffel, which uses a Pascal-like syntax Names are usually alphanumeric Types are logical types from the domain In this example, an apple’s diameter is a quantity of type ‘Length’, which could be represented as a float or double in C++ or Java

Attribute Modifiers Attributes can be read/write (default) or read only Attributes that are read only are preceded with the modifier ‘/’ Attributes can be defined on the objects (default) or the class Class attributes are preceded with the modifier ‘$’

Attribute Modifiers Attributes can have different visibilities Public attributes, denoted with the modifier ‘+’, can be accessed from outside the class Private attributes, denoted with the modifier ‘-’, can only be accessed from within the class Protected attributes, denoted with the modifier ‘#’, can be accessed from within the class, or any descendant (e.g. a subclass)

Attributes in Classes Fruit -numSeeds: Integer Apple -skinColour: Colour #diameter: Length $carboRatio: Real Athlete +teamName: String Person / age: Duration height: Length

Operations in Classes Person +birthday() +getHeight(): Length Apple +getSkinColour(): Colour +bite(depth: Length)

Operations in Classes Operations can be defined, using the form: opName([in|out|inout] param1 : type1,…) : returnType The modifiers in, out, and inout specify which direction(s) the parameters are to travel in: input to the operation out: output from the operation inout: input to the operation, possibly modified, then output from the operation Often, if no modifier is specified, a parameter is assumed to be input only (in) Again, type1 and returnType are types from the application domain

Abstract Classes and Methods Athlete {abstract} +getPointsTotal() {abstract}

Abstract Classes and Methods The class Athlete was declared abstract This is analogous to abstract classes in Java The getPointTotals() method was declared abstract This means the method is not implemented in this class, but left for a (concrete) subclass to implement This method being abstract makes it necessary for Athlete to be declared an abstract class

Genericity in Classes Genericity, or run-time determined types, in a class can be represented in UML This allows you to design classes to work on a group of types, where the type is ‘generic’ at compile time The type, specified at run-time, is an argument or parameter to the class This, such classes are called parameterized classes

Parameterized Classes Printer +print(item : T) T

Parameterized Classes Printer +print(item : T) T ImagePrinter << bind >> <Image>

Class Diagrams Ok, so now we’ve seen what classes look like in UML We now need to know how to define relationships between these classes There are three types of relationships: A ‘is a type of’ B (inheritance) A ‘is associated with’ B (association) A ‘is a part of’ B (composition)

Inheritance This is an alternate notation Fruit Apple Kiwi

Multiple Inheritance CDWriter StorageDevice CDReader

Groups Whenever we create a subclass, we are defining a new group of objects, that is a subset of the superclass’ group To be even more complete, when we define inheritance, we usually use keywords to give details about those groups

Overlapping/Disjoint Groups Overlapping/Disjoint Overlapping: Groups are overlapping if there are objects that are members of both groups Disjoint: Groups are disjoint if there are no objects that are members of both groups

Overlapping Groups Overlapping/Disjoint Example: Say we have a superclass called ‘Movie’ Say we have two subclasses of ‘Movie’ called ‘Comedy’ and ‘Action’ Since it is possible for a movie to have both action and comedy, the two groups are overlapping

Overlapping Groups overlapping Movie Comedy Action

Overlapping Groups Comedy Action Movies A Venn Diagram

Disjoint Groups Overlapping/Disjoint Example: Say we have a superclass called ‘Book’ Say we have two subclasses of ‘Book’ called ‘Paperback’ and ‘Hardcover’ Since a book is either a paperback or a hardcover book, the two groups are disjoint

Disjoint Groups disjoint Book Paperback Hardcover

Disjoint Groups Hardcover Paperback Books

Complete/Incomplete Groups Complete/Incomplete Complete: The groups listed contain all possible objects that belong to the superclass’ group I.e. No more disjoint subclasses can be defined Incomplete: The groups listed do not contain all possible objects that belong to the superclass’ group

Complete Groups Complete/Incomplete Example: Consider our superclass ‘Book’ with its subclasses ‘Hardcover’ and ‘Paperback’ Are there any other kinds of book? The answer is ‘no’, this the groups are complete

Complete Groups disjoint, complete Book Paperback Hardcover

Complete Groups Hardcover Paperback Books

Incomplete Groups Complete/Incomplete Example: Consider our superclass ‘Movie’ with its subclasses ‘Comedy’ and ‘Action’ Are there any other kinds of movie? The answer is ‘yes’, this the groups are incomplete

Incomplete Groups overlapping, incomplete Movie Comedy Action

Incomplete Groups Action Movies Comedy There are more items

Completeness/Disjointness We have seen examples for: Overlapping, incomplete Disjoint, complete Is it possible to have groups that are: Overlapping, complete? Disjoint, incomplete? What are some examples?

Overlapping, complete What about sets of numbers? Say we have a superclass called ‘Number’ and three subclasses called ‘Integer’, ‘Real’, and ‘Complex’ All numbers possible are represented, thus the groups are complete Yet, the number 14, for example, falls into all three categories It should be fairly obvious that 14 is both an Integer and a Real number

Disjoint, Incomplete What about living creatures? We may have a class ‘LivingThing’ and two subclasses ‘Plant’ and ‘Animal’ Most biologists would agree that plants and animals are disjoint Nothing is a plant and an animal However, Fungi are not plants and are not animals The groups Plants and Animals are not complete

Group Separation As you may have already noticed, class hierarchies are highly subjective You can often create subclasses of a given class using several different attributes to distinguish subclasses For example, consider ‘Vehicle’ One set of subclasses might be ‘Aircraft’, ‘Boat’, ‘Automobile’ Another set might be ‘GasPowered’, ‘SolarPowered’, … Another might be ‘WheeledVehicle’, ‘WingedVehicle’, …

Group Separation In the example, each set of subclasses may have different values for completeness and disjointness Typically, which set of subclasses you choose depends on the problem domain For example, if it is irrelevant if a vehicle has wings or wheels, we wouldn’t use those subclasses Perhaps we only care about arrival times and costs

Association Associations between classes represent logical relationships objects of those classes might hold For example, a ‘Person’ class might have an association ‘HomeAddress’ with another class ‘Location’ This is because an instance of Person might have an instance of Location as its home address

Association Keep in mind, associates deal with objects, rather than classes Thus they declare what associations are possible between their instances There may be several instances of the association at any time The number of instances changes over time One instance may hold several instances of the same association

Association An association contains: The name of the association This name describes the association Multiplicity at each end of the association This describes the number of instances that may occur at that end of the association The role of the class at each end (optional) This is usually a name used to describe the instances with respect to that association The last two will be described individually

Association Let’s illustrate these concepts with an example Say we have two classes, ‘Person’ and ‘MusicalInstrument’ , and an association called ‘Plays’ The association Plays represents all instances where a Person plays a Musical Instrument

Association Plays We might have the following instances of ‘Plays’: Bob plays Piano Lucy plays Saxophone Lucy plays Trumpet Sue plays Drums Person MusicalInstrument

Association Plays The multiplicity of Person means: How many people can play a given instrument? What is the answer? Person MusicalInstrument

Association Plays The multiplicity of Person means: How many people can play a given instrument? Any number of people can play a given instrument, including zero This is represented using 0..* Person MusicalInstrument

Association Plays The multiplicity of MusicalInstrument means: How many instruments can a person play? What is the answer? 0..* Person MusicalInstrument

Association Plays The multiplicity of MusicalInstrument means: How many instruments can a person play? A person may play zero instruments, or any number of them Again, this is 0..* 0..* Person MusicalInstrument

Association Plays Essentially, an association could be considered a class itself Every instrument any person plays is an instance of the Plays association Associations would have members such as ‘name’, ‘multiplicity1’, ‘multiplicity2’, etc.. 0..* 0..* Person MusicalInstrument

Association 0..* 0..* Person MusicalInstrument Plays

Higher-Order Associations Associations need not always be between 2 classes Associations can exist between 3 or more classes as well

Composition Composition is a relationship between two classes where one class is a part of another (an ‘is a part of’ relationship) If a class A is composed of classes B, C, and D, we may say that A has components B, C, and D Compositions typically consist of a name, as well as the multiplicity of the component

Composition If a class ‘Car’ has a composition relationship with another class ‘Wheel’, we should agree that normally the multiplicity of Wheel is 4 (exactly) ‘ Vehicle’, on the other hand, could have any number of wheels (0..*) Composition is a special form of association It is important enough to have its own notation

Composition 1 1 1 2 Wing Airplane Propeller Fuselage Tail

Aggregation Aggregations is also a type of association, but again, a special one that is given its own notation This is because, like composition, it is very common An aggregation is another relationship between classes which says one class ‘is a part of’ another class

Aggregation vs. Composition Both aggregation and composition represent the ‘is a part of’ relationship The main difference is what the part represents In aggregation, the part (constituent) is meaningful without the whole (aggregate) In composition, the part (component) is not meaningful without the whole (container)

Aggregation vs. Composition A side-effect of this difference is that a component is always a part of (at most) one container However, a constituent may be a member of multiple aggregates

Aggregation vs. Composition In UML, composition is considered a special case of aggregation where constituents belong only to a single aggregate This is why some tools (such as Rational Rose) only have symbols for aggregation, and not composition

Aggregation To illustrate an constituent, again, let’s use a few examples: A Forest is an aggregate of Trees A Program is an aggregate of Statements A Fleet is an aggregate of Ships A Deck is an aggregate of Cards

Aggregation Parts of an aggregate are called constituents: A Tree is an constituent of Forest A Statement is an constituent of Program A Ship is an constituent of Fleet A Card is an constituent of Deck

Aggregation These constituents share one common property: The constituents of an aggregate are usually the same type Two other properties are also defined for aggregation: An object may be a constituent of more than one aggregate simultaneously It is possible to have an aggregate without any constituents

Aggregation An object may be a constituent of more than one aggregate simultaneously This is identified by the multiplicity of the aggregate end of the association It is possible to have an aggregate without any constituents This is identified by the multiplicity of the constituent end of the association

Aggregation 1..* 1..* Club Member

Aggregate Order Aggregates can be ordered or unordered In ordered aggregates, the order of the constituents within the aggregate is important In unordered aggregates, the order is unimportant Ordered aggregates are indicated using the symbol [ordered] Unordered is the default for aggregates

Aggregate Order 1..* 1 1..* 1 [ordered] Toybox Toy Magazine Page

Aggregation and Composition In programming, aggregation and composition are usually represented by class attributes However, for clarity, in class diagrams, aggregation and composition should always be used instead of the attribute form This is because it allows the definition of the class being used to be shown

Class Diagrams: An Example Say we are writing a word processor A word processing document consists of a number of paragraphs Each paragraph consists of a number of elements An element can be a character or an image

Class Diagrams: An Example 1 0..* [ordered] 1 0..* [ordered] Element Character Image Paragraph Document

Class Types In class diagrams, there are three basic types of classes: Entity classes: Used to model information and associated behaviour of some phenomenon or concept such as an individual, a real-life object, or a real-life event Boundary classes: Used to model interaction between the system and its actors Control classes: Used to represent coordination, sequencing, transactions and control of other objects

Class Types « control » MyControlClass « boundary » MyBoundaryClass « entity » MyEntityClass

Class Types: Alternate Notation MyEntityClass MyControlClass MyBoundaryClass

Class diagrams

More Related Content

Class diagrams