4. class diagrams using uml
description
Transcript of 4. class diagrams using uml
Slide 1Object-Oriented Software Systems Engineering – Chapter 4
Class Diagrams using UML
Slide 2Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 3Object-Oriented Software Systems Engineering – Chapter 4
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}
Slide 4Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 5Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 6Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 7Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 8Object-Oriented Software Systems Engineering – Chapter 4
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)
Slide 9Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 10Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 11Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 12Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 13Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 14Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 15Object-Oriented Software Systems Engineering – Chapter 4
An Example of Generalisation
nameaddress
creditRating():String
Customer
contactNamecreditRatingcreditLimit
remind()billForMonth(Integer)
CorporateCustomer
creditCard#
PersonalCustomer
Slide 16Object-Oriented Software Systems Engineering – Chapter 4
An Example of Generalisation
Vehicle
Car Boat
SportCar Truck SailingBoatMotorBoat
Slide 17Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 18Object-Oriented Software Systems Engineering – Chapter 4
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..*
Slide 19Object-Oriented Software Systems Engineering – Chapter 4
Static Modelling - Aggregation
Composition aggregation Strong ownershipThe whole owns the parts; the parts live inside the whole
Wheel Engine
Car
4
Slide 20Object-Oriented Software Systems Engineering – Chapter 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?
Slide 21Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 22Object-Oriented Software Systems Engineering – Chapter 4
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.
Slide 23Object-Oriented Software Systems Engineering – Chapter 4
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..*
Slide 24Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 25Object-Oriented Software Systems Engineering – Chapter 4
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()
name : Nameaddress : StringPhoneNo : Number
addStaffremoveStaffgetStaffgetAllStaff
name : NamestudentID : Number
name : NamecourseID : Number name : NameaddCourseupdatCoursegetCourse
Slide 26Object-Oriented Software Systems Engineering – Chapter 4
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()
name : Nameaddress : StringPhoneNo : Number
addStaffremoveStaffgetStaffgetAllStaff
name : NamestudentID : Number
name : NamecourseID : Number name : NameaddCourseupdatCoursegetCourse
Slide 27Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 28Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 29Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 30Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 31Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 32Object-Oriented Software Systems Engineering – Chapter 4
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
Slide 33Object-Oriented Software Systems Engineering – Chapter 4
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