4. class diagrams using uml

Slide 1Object-Oriented Software Systems Engineering – Chapter 4

Class Diagrams using UML


Objectives

In this chapter we will: Introduce class diagram notation Discuss how to identify problem domain classes Discuss the different relationships which exist

between classes Introduce the concept of an Interface


Class Diagram- order processing (Association with navigability

adornments)Order {persistent}

1dateReceivedisPrepaidnumber : Stringprice : Moneydispatch()close()

Customer {persistent}

name : Nameaddress : String

*

OrderLine {persistent}

quantity : Integerprice : MoneyisSatisfied : Boolean

*

1

Corporate Customer {persistent}

remind()billForMonth(bn : Integer)

contactNamecreditRatingcreditLimit

Personal Customer {persistent}

creditCard#

creditRating() : String

Product * 1

belong to

has

refer to

{if Order.customer.creditRating is“poor” then Order.isPrepaidMust be true}


Class Diagrams

Purposemodel the static view of a systemhow they are related, but not how they interact to

achieve particular behaviourmodel static relationships between classes

association and generalisation are the two principal kinds of relationships

Scope abstraction : the key domain classonly the aspects of the domain which are important

to the applicationa class should be named using the vocabulary of the

domain


Static Modelling - Class

Class nameattributes - describe characteristics of the objects operations - used to manipulate attributes and to perform

other actions

Attribute has type - which tells what values the attribute can takevisibility - tells whether the attribute is visible and can be

referenced from classes other than the one in which it is defined (private, public, protected)

may have a default value - assigned at the time an object of the class is created


Static Modelling - Class

Operations (methods)a function defined within a class and can be only applied

to the objects of that classdescribe what any object of the class can dodescribe the interface to the class - what the class can do

and what services it offerssignature, visibility, scope


O-O Concepts Messages and Methods

Objects perform work when sent messages Messages are sent to objects to invoke their behaviour

(methods) For example a Customer object could sent a message to a

pump to start pumping

Methods are the implementation of the behaviour invoked when a message arrives they only have access to an objects attributes (data)- unless

data attributes are declared as static


O-O Concepts Messages and Methods

Methods are defined by their signature visibility(public,private,protected,default) return type method name method parameters

Different methods can have same name but a different parameters,these will decide which method is invoked at runtime (method overloading)


O-O Concepts Full Class UML Notation

operations

Frame

Header : FrameHeader- FrameID : Long

+ addMessage(m : Message) : Status

# setCheckSum()

- encrypt()

public

name

attributes

signature

protected

Underlining denotes static

private


Static Modelling Association - Relationships

Association relationship that describes a set of links class A and class B are associated if

an object of class A sends a message to an object of class B

an object of class A creates an object of class Ban object of class A has an attribute whose values are

objects of class B or collections of objects of class Ban object of class A receives a message with an object

of class B as an argument

Multiplicity a range that tells how many objects are linked placed near the class it is applicable to ranges : n..m 0..1 0..* 1..* 2 1,2,4,8


An Example of Association

Nameverb/noun from a problem domain

Multiplicity

Car

model

opname()

Person

name

opname()0..*

ownsdrivercompany car

1..*

Role Name

Roleindicates the role played by the class in terms of association placed near the class it applies to


Static Modelling – Normal Association

If an association is only ever used in one direction it can be labeled with an arrow head at the end

<<control>>

PumpControl

triggers

<<boundary>>

Nozzle

In

out

start

stop


Static Modelling Generalization Relationship

Generalizationrelationship between a general thing

(superclass or parent) and a more specific kind of that thing (subclass of child)

the child will inherit all the structure and behaviour of the parent

the child may add new structure and behaviour or it may modify the behaviour of the parent

the child is substitutable for the parent


Examples of Generalisation

A taxonomic relation between a more general and a more specific element

The more specific element is fully consistent with the more general contains additional properties

The relationship between the classes is inheritance

the specific class inherits everything (attributes, operations, relations) from the general class


An Example of Generalisation

nameaddress

creditRating():String

Customer


remind()billForMonth(Integer)

CorporateCustomer

creditCard#

PersonalCustomer


An Example of Generalisation

Vehicle

Car Boat

SportCar Truck SailingBoatMotorBoat


Static Modelling Aggregation with examples

Aggregation indicates that a relationship between the classes is "whole-part”.

Wheel Engine

Car

4

PersonTeam

1..*

Membershipclub member

0..* 1..*

• Composition aggregationstrong ownership - the whole owns the parts, the part lives inside the whole

• Shared aggregationthe parts may be parts of many wholes


Static Modelling - Aggregation

Aggregation indicates that a relationship between the classes is "whole-part”

Shared aggregation – the parts may be parts of many wholes

PersonTeam

1..*

Membershipclub member

0..* 1..*


Static Modelling - Aggregation

Composition aggregation Strong ownershipThe whole owns the parts; the parts live inside the whole

Wheel Engine

Car

4


Identification of Classes

Noun identification technique This technique involves two stages:

Select all the nouns and noun phrases in a requirements specification of the system as candidates for classes

Discard candidate which are inappropriate for any reasons

How do we decide which are inappropriate?


Discarding Candidate Classes

Candidates may be inappropriate for many reasons:redundant : the same class is given more than one name

vague : cannot tell unambiguously what is meant by a noun

an event or an operation : where noun refers to something which is done to or by the system

an attribute : where the noun refers to something simple with no interesting behaviour

meta-language : where the noun forms part of the way we define things (e.g., requirements, system)

outside the scope of the system : where the noun is relevant to describing how the system works but does not refer to something inside the system


Identifying Classes for a Library

Consider the following example

A library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals.


Book {persistent}

1 Title: StringPublisher: StringAuthor: StringISBN: intTotalCopies: intAvailabelCopies: int

addBook ()removeBook()findBook()borrowable()

Copy of Book {persistent}

CopyID: intMemberID : ObjectLoanTime: int

borrowed()returned()updateAvaCopies()reservedCopy()

1..*

LibraryMember {persistent}

MemberOfStaff {persistent}

Journal {persistent}

0..*

addJournal ()removeJournal()findJournal()

0..1

0..1 0..*


Examples of Class Diagrams

On the next two slides examples of class diagrams are given

One relating to course managementThe other relating to order processing

Study the diagrams to see if you can understand them


School {persistent}

has

1..*

Department {persistent}

1

Student {persistent} attends

*

Course {persistent}

*

1..*

*

1..*

Academic Staff {persistent}

teaches

Chairperson

assi

gned

to

mem

ber

*

1..*

1..*

1..*

1..*

0..1

0..1ow

n

name : Nameaddress : StringPhoneNo : Number

addStudent()removeStudent()getStudent()getAllStudent()addDepartment()removeDepartment()getDepartment()getAllDepartment()


addStaffremoveStaffgetStaffgetAllStaff

name : NamestudentID : Number

name : NamecourseID : Number name : NameaddCourseupdatCoursegetCourse


School {persistent}

has

1..*

Department {persistent}

1

Student {persistent} attends

*

Course {persistent}

*

1..*

*

1..*

Academic Staff {persistent}

teaches

Chairperson

assi

gned

to

mem

ber

*

1..*

1..*

1..*

1..*

0..1

0..1ow

n


addStudent()removeStudent()getStudent()getAllStudent()addDepartment()removeDepartment()getDepartment()getAllDepartment()


addStaffremoveStaffgetStaffgetAllStaff

name : NamestudentID : Number

name : NamecourseID : Number name : NameaddCourseupdatCoursegetCourse


Order {persistent}

1dateReceivedisPrepaidnumber : Stringprice : Moneydispatch()close()

Customer {persistent}

name : Nameaddress : String

*

OrderLine {persistent}

quantity : Integerprice : MoneyisSatisfied : Boolean

*

1

Corporate Customer {persistent}

remind()billForMonth(bn : Integer)


Personal Customer {persistent}

creditCard#

creditRating() : String

Product * 1

belong to

has

refer to


Realisation

A semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out

semantically a cross between a dependency and generalisation

used in two cases

<<interface>>

UserInterfaceBank Account

realizes

realizesPlace order

Order

management

Use case collaboration


Realizing use cases - Relationship

Realized in a collaborationshows an internal implementation dependent solution of

a use case in terms of classes & their relationships

Oper1()

Oper2()

Oper3() e.t.c

Class A

Oper1()

Oper2()

Oper3() e.t.c

Class B

Oper1()

Oper2()

Oper3() e.t.c

Class CUse case description:

1. Insert the coins

2. Choose a drink

3. Deliver a drink

4. E.t.c

Use Case

<<realizes>>

<<implements>>

<<implements>>

<<implements>>

Collaboration


Interfaces in UML

• UML has a short hand notation for representing interfaces but does not show the methods associated with the interface

name:String

balance:Currency

accountNo:String

credit(Amount:double)

debit(Amount:double)

suspend()

chargeFee(Amount:double)

getBalance();double

BankAccount

AccountHolder BankEmployee

UserInterfaceadministers

1 11..* 1..*

has looksAfter

interface


Interfaces in UML

• A more detailed representation

name:String

balance:long

accountNo:Int

credit(Amount:long)

debit(Amount:long)

suspend()

chargeFee(Amount:long)

getBalance();long

BankAccount

credit(Amount:long)

debit(Amount:long)

getBalance():long

<<interface>>

UserInterface

AccountHolder

<<uses>>

1 1..*

has

realises

dependency


Dependencies - relationship

Dependency is a using relationshipa change in one thing may effect anothershown as a stereotype e.g. friend

one class takes an object of another class as a parameter one class accesses a global object of another class one class calls a class scope method in another class

Class A Class B<<friend>>

Examplefriendspecifies that source is given special visibility into the targetinstanceOfsource object is an instance of the target classifierinstantiatesource creates instances of the target


Summary

In this chapter we have: Introduced class diagram notation Discussed how to identify problem domain

classes Discussed the different relationships which exist

between classes Introduced the concept of an Interface

4. class diagrams using uml

Documents

static modelling class

object of class b

objectof class b

key domain class

problem domainthe class

class diagram notation

set of links class

class diagrams purpose