Class Diagrams using UML: Model Static Relationships

Class Diagrams using UML

Object-Oriented Software Systems Engineering – Chapter 4 Slide 1

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 Customer
{persistent} {persistent}
dateReceived * belong to 1
isPrepaid name : Name
number : String address : String
price : Money creditRating() : String
dispatch()
close()
1
{if Order.customer.creditRating is
“poor” then Order.isPrepaid
Must be true} Corporate Customer Personal Customer
contactName
has

creditCard#
creditRating
creditLimit
remind()
* billForMonth(bn : Integer)
OrderLine
{persistent}
quantity : Integer
refer to 1
price : Money *
isSatisfied : Boolean Product


Class Diagrams

 Purpose
 model the static view of a system
 how they are related, but not how they interact to
achieve particular behaviour
 model static relationships between classes
 association and generalisation are the two
principal kinds of relationships
 Scope
 abstraction : the key domain class
 only the aspects of the domain which are important
to the application
 a class should be named using the vocabulary of the
domain


Static Modelling - Class

 Class
 name
 attributes - 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 take
 visibility - 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 class
 describe what any object of the class can do
 describe the interface to the class - what the class can do
and what services it offers
 signature, 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

Frame name
Underlining
denotes static
Header : FrameHeader
- FrameID : Long attributes

private - encrypt()
protected # setCheckSum()
operations
public + addMessage(m : Message) : Status

signature


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 B
 an object of class A has an attribute whose values are
objects of class B or collections of objects of class B
 an 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

Car Person
owns
model company car driver name

0..* 1..*
opname() opname()

Multiplicity Role Name

Name Role
indicates the role played by
verb/noun from a problem domain
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>>
<<boundary>>
PumpControl
Nozzle

In
triggers
out
start
stop


Static Modelling Generalization Relationship

 Generalization
relationship 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

Customer
name
address

creditRating():String

Corporate Personal
Customer Customer
contactName creditCard#
creditRating
creditLimit

remind()
billForMonth(Integer)


An Example of Generalisation

Vehicle

Boat
Car

SportCar Truck MotorBoat SailingBoat


Static Modelling Aggregation with
examples

Aggregation indicates that a relationship between
the classes is "whole-part”.
• Shared aggregation
the parts may be parts of many wholes
Membership
club member
Team Person

0..* 1..*

Car
• Composition aggregation
strong ownership - the whole owns the parts,
the part lives inside the whole 4
Wheel Engine


Static Modelling - Aggregation

 Aggregation indicates that a relationship between
the classes is "whole-part”
 Shared aggregation – the parts may be parts of
many wholes

Membership
club member
Team Person

0..* 1..*


Static Modelling - Aggregation

 Composition aggregation
 Strong ownership
 The whole owns the parts; the parts live inside the whole

Car

4
Wheel Engine


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.


LibraryMember Copy of Book Book
{persistent} {persistent} {persistent}
CopyID: int
0..1 0..* MemberID : Object 1..* 1 Title: String
Publisher: String
LoanTime: int Author: String
ISBN: int
borrowed()
TotalCopies: int
returned()
AvailabelCopies: int
updateAvaCopies()
reservedCopy() addBook ()
removeBook()
findBook()
borrowable()

Journal
{persistent}
MemberOfStaff
{persistent}
0..1 0..*

addJournal ()
removeJournal(
)
findJournal()

Examples of Class Diagrams

 On the next two slides examples of class diagrams
are given
 One relating to course management
 The other relating to order processing
 Study the diagrams to see if you can understand
them


School Department
Chairperson
name : Name name : Name 0..1
has
address : String address : String
PhoneNo : Number PhoneNo : Number
1 1..* 1..*
addStudent() addStaff
removeStudent() removeStaff
getStudent() getStaff
getAllStudent() getAllStaff
addDepartment()
removeDepartment() 1..*

assigned to
getDepartment()
getAllDepartment()

own
1..*
1..*
member

Course 1..* 0..1
{persistent} Academic Staff
* name : Name
Student {persistent}
courseID : Number
{persistent} attends teaches name : Name
addCourse
name : Name 1..*
updatCourse *
studentID : Number * * getCourse


Order Customer
dateReceived * belong to 1
isPrepaid name : Name
number : String address : String
price : Money creditRating() : String
dispatch()
close()
1

Corporate Customer Personal Customer
contactName
has

creditCard#
creditRating
creditLimit
remind()
* billForMonth(bn : Integer)
OrderLine
{persistent}
quantity : Integer
refer to 1
price : Money *
isSatisfied : Boolean Product


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
Use case collaboration
realizes Order
Place order
management

<<interface>>
UserInterface realizes
Bank Account


Realizing use cases - Relationship

 Realized in a collaboration
 shows an internal implementation dependent solution of
a use case in terms of classes & their relationships

<<realizes>>

Collaboration
Use Case
<<implements>>
<<implements>>

<<implements>>

Use case description: Class A Class B Class C
1. Insert the coins
2. Choose a drink
3. Deliver a drink Oper1() Oper1() Oper1()
4. E.t.c Oper2() Oper2() Oper2()
Oper3() e.t.c Oper3() e.t.c Oper3() e.t.c


Interfaces in UML

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

AccountHolder 1 name:String BankEmployee
1..* 1..* 1
balance:Currency
has accountNo:String looksAfter

credit(Amount:double)
debit(Amount:double)
suspend()
chargeFee(Amount:double)
getBalance();double
UserInterface
interface administers


Interfaces in UML

• A more detailed representation

<<interface>> realises BankAccount
UserInterface
name:String
credit(Amount:long) balance:long
debit(Amount:long) accountNo:Int
getBalance():long
credit(Amount:long)
debit(Amount:long)
<<uses>> dependency
suspend()
1 1..* chargeFee(Amount:long)
AccountHolder getBalance();long
has


Dependencies - relationship

 Dependency is a using relationship
 a change in one thing may effect another
 shown 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

<<friend>>
 Example Class A Class B
 friend
 specifies that source is given special visibility into the target
 instanceOf
 source object is an instance of the target classifier
 instantiate
 source 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


Class Diagrams using UML: Model Static Relationships

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à Class Diagrams using UML: Model Static Relationships

Similaire à Class Diagrams using UML: Model Static Relationships (20)

Plus de APU

Plus de APU (19)

Class Diagrams using UML: Model Static Relationships

Notes de l'éditeur