Your SlideShare is downloading. ×
4.class diagramsusinguml
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

4.class diagramsusinguml

1,219
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,219
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 1
  • Transcript

    • 1. Class Diagrams using UMLObject-Oriented Software Systems Engineering – Chapter 4 Slide 1
    • 2. 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 InterfaceObject-Oriented Software Systems Engineering – Chapter 4 Slide 2
    • 3. 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 {persistent} {persistent} contactName has creditCard# creditRating creditLimit remind() * billForMonth(bn : Integer) OrderLine {persistent} quantity : Integer refer to 1 price : Money * isSatisfied : Boolean ProductObject-Oriented Software Systems Engineering – Chapter 4 Slide 3
    • 4. 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 domainObject-Oriented Software Systems Engineering – Chapter 4 Slide 4
    • 5. 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 createdObject-Oriented Software Systems Engineering – Chapter 4 Slide 5
    • 6. 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, scopeObject-Oriented Software Systems Engineering – Chapter 4 Slide 6
    • 7. 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 staticObject-Oriented Software Systems Engineering – Chapter 4 Slide 7
    • 8. 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)Object-Oriented Software Systems Engineering – Chapter 4 Slide 8
    • 9. O-O Concepts Full Class UML Notation Frame nameUnderliningdenotes static Header : FrameHeader - FrameID : Long attributesprivate - encrypt()protected # setCheckSum() operationspublic + addMessage(m : Message) : Status signature Object-Oriented Software Systems Engineering – Chapter 4 Slide 9
    • 10. 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,8Object-Oriented Software Systems Engineering – Chapter 4 Slide 10
    • 11. 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 toObject-Oriented Software Systems Engineering – Chapter 4 Slide 11
    • 12. 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 stopObject-Oriented Software Systems Engineering – Chapter 4 Slide 12
    • 13. 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 parentObject-Oriented Software Systems Engineering – Chapter 4 Slide 13
    • 14. 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 classObject-Oriented Software Systems Engineering – Chapter 4 Slide 14
    • 15. An Example of Generalisation Customer name address creditRating():String Corporate Personal Customer Customer contactName creditCard# creditRating creditLimit remind() billForMonth(Integer)Object-Oriented Software Systems Engineering – Chapter 4 Slide 15
    • 16. An Example of Generalisation Vehicle Boat Car SportCar Truck MotorBoat SailingBoatObject-Oriented Software Systems Engineering – Chapter 4 Slide 16
    • 17. 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 Object-Oriented Software Systems Engineering – Chapter 4 Slide 17
    • 18. 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..*Object-Oriented Software Systems Engineering – Chapter 4 Slide 18
    • 19. Static Modelling - Aggregation  Composition aggregation  Strong ownership  The whole owns the parts; the parts live inside the whole Car 4 Wheel EngineObject-Oriented Software Systems Engineering – Chapter 4 Slide 19
    • 20. 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?Object-Oriented Software Systems Engineering – Chapter 4 Slide 20
    • 21. 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 systemObject-Oriented Software Systems Engineering – Chapter 4 Slide 21
    • 22. 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.Object-Oriented Software Systems Engineering – Chapter 4 Slide 22
    • 23. 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()Object-Oriented Software Systems Engineering – Chapter 4 Slide 23
    • 24. 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 themObject-Oriented Software Systems Engineering – Chapter 4 Slide 24
    • 25. School Department {persistent} {persistent} 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 * * getCourseObject-Oriented Software Systems Engineering – Chapter 4 Slide 25
    • 26. School Department {persistent} {persistent} 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 * * getCourseObject-Oriented Software Systems Engineering – Chapter 4 Slide 26
    • 27. Order Customer {persistent} {persistent} dateReceived * belong to 1 isPrepaid name : Name number : String address : String price : Money creditRating() : String dispatch() close() 1 Corporate Customer Personal Customer {persistent} {persistent} contactName has creditCard# creditRating creditLimit remind() * billForMonth(bn : Integer) OrderLine {persistent} quantity : Integer refer to 1 price : Money * isSatisfied : Boolean ProductObject-Oriented Software Systems Engineering – Chapter 4 Slide 27
    • 28. 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 AccountObject-Oriented Software Systems Engineering – Chapter 4 Slide 28
    • 29. 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.cObject-Oriented Software Systems Engineering – Chapter 4 Slide 29
    • 30. 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 administersObject-Oriented Software Systems Engineering – Chapter 4 Slide 30
    • 31. 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 hasObject-Oriented Software Systems Engineering – Chapter 4 Slide 31
    • 32. 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 targetObject-Oriented Software Systems Engineering – Chapter 4 Slide 32
    • 33. 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 InterfaceObject-Oriented Software Systems Engineering – Chapter 4 Slide 33