F28SD2 Software Design

1
F28SD2 Software Design
Class Diagrams Interaction Diagrams
Monica Farrow EM G.30
monica_at_macs.hw.ac.uk http//vision.hw.ac.uk
2
Object-oriented versus function-oriented design
Catalog
Librarian
Object-oriented Decompose by objects
Book
Library
Function-oriented Decompose by processes
Catalog
Record Loans
Add Resources
Report Fines
3
Class Diagram

• A class diagram is a type of static structure
  diagram that describes the structure of a system
  by showing the system's classes, their
  attributes, and the relationships between the
  classes.

4
What are Class Diagrams used for?

• Initially for design
• What classes do we need?
• What attributes will they have (instance
  variables)?
• What operations will they have (methods)
• How do they interact?
• Finally for documentation
• Detailed diagrams show variables and methods
• Higher level diagrams show class interaction

5
Recap classes and objects

• A class is a set of objects that share a common
  structure and a common behaviour
• E.g Dog. All dogs have a size, name and breed,
  and they can all bark.
• Each object has its own private data. There can
  be lots of objects (specific dogs) which are
  described by one class (Dog).
• Husky dog called Musher, size 80
• Poodle called Tina, size 40
• Labrador called Goldie, size 50

6
Showing State and Behaviour

• The class diagram shows the state and behaviour
  of objects of a particular class, by splitting
  the rectangle into three sections.
• NB The order of names, types, and return types is
  a little different to how they are written in
  java

Dog

• Class name at the top
• Attributes in the middle
• Name then type
• Operations at the bottom
• Name, parameters then return value

- size int - breed String - name String
bark(numTimes int) - barkOnce() getName()
String setName(n String) other get/set
methods
7
Protection

• Shows accessibility
• public
• can be accessed by any class
• - private
• can be accessed only by this class
• protected
• can be accessed by this class and its
  subclasses

8
Access in java instance variables

• Generally, instance variables should always be
  private
• This hides the way in which the information is
  stored from the user
• Provide get/set methods for all the instance
  variables which are likely to be accessed by
  other classes
• e.g. Dog d1 new Dog()
• d1.setName(Fido)
• YES String nameD1 d1.getName()
• NO String nameD1 d1.name

9
Access in java methods

• Methods are usually public, unless they are
  solely used by methods of the same class
• bark is public, used by anyone to specify the
  number of times to be barkedpublic void bark(int
  numTimes) //for the given number of
  times// call the barkOnce method
• barkOnce is private, it is called internally by
  bark. Other classes do not know about it and
  should not use it.

10
Protected Access in java - subclasses
Dog

• In this diagram, the PetDog and WorkDog classes
  CAN use the protected instance variables
• All other classes must use the get/set methods

size int breed String name String
bark(numTimes int) - barkOnce() getName()
String setName(n String) other get/set
methods
PetDog
WorkDog - type String
11
Associations

• An object may know about other objects via
  associations.
• E.g. an owner has some dogs
• When drawing associations, the attributes and
  operations are often omitted

has
Owner
Dog
12
Class diagram notation

• Rectangles with names - classes
• Lines joining classes - represent associations
  between objects of that class
• We can optionally attach labels to the
  association lines to ease reading - these give a
  name to an association.
• Black triangle may be used to indicate direction
  of label (Owner has Dogs)

Dog
Owner
has
13
Multiplicities (cardinality)

• We can also add multiplicities to show the degree
  of association - very much like
  entity-relationship diagrams. Note how they are
  read
• An owner has 0 or more dogs.
• A dog has only one owner.

0..
1
Owner
Dog
has
14
Navigability

• Open arrow heads on the associations show
  navigability
• This indicates which object needs to know about
  which other object to make an association work
• We try to keep navigability one way to reduce
  coupling the number of links between classes
• Where no navigability is shown this can mean two
  way or not yet defined - be consistent

15
Loose coupling

• Aim to keep dependencies between classes to a
  minimum
• Suppose that you have written a Date class (there
  is one supplied with java, but it makes a good
  example here).
• You want to keep the date of birth of your dogs.

Dog
Date
- size int - breed String - name String
getYear() int Etc etc
Born on
16
Loose coupling

• From this design diagram, we add a date to the
  Dog class
• The Date class instance variables should just
  relate to the date (eg int day, int month, int
  year), and should not include a list of dogs with
  that date of birth
• It would be very useful to be able to use your
  Date class in lots of programs, but this is not
  possible if details of Dogs are included with the
  Date class

Dog
- size int - breed String - name String -
dob Date
17
Tight cohesion

• Aim for each class to be a meaningful entity.
• Each class should be cohesive by containing
  related data and operations of that data
• Finding the number of days between 2 dates is the
  sort of operation that many programs might want
  to use
• This should therefore be provided in the Date
  class
• Otherwise all the classes using the Date class
  who wanted to use this feature would have to
  write their own subtracting routine, producing
  duplicate code.

18
Generalisation and specialisation

• Objects give us greater flexibility than standard
  functional libraries - this is where the power of
  the object-oriented approach starts to appear ...
• We often find that objects are very similar
  without being identical
• The parts of different classes which are the same
  can be factored out as a generalisation of all of
  them
• The differences can be added to this to form a
  family of specialisations

19
Generalisation and specialisation
Account
Savings account
Current account

• Account is a generalisation, also known as parent
  class or super-class
• Current account and Savings account are
  specialisations, also known as child class or
  sub-class
• Specialisations may have additional attributes
  and/or operations
• Account provides balance for current account and
  savings account
• Current account has cheque book numbers also and
  an operation to order a new cheque book

20
Account classes
Account abstract

• Specialisations may have different
  implementations for operations

balance Real rate Real
withdraw(aReal) deposit(aReal) curBal()Real
CurrentAccount
SavingsAccount
-chequeNo Integer
withdraw(aReal)
withdraw(aReal) newBook()
Overriding same subclass
method name as superclass same signature.
Different body.
21
An abstract class

• SavingsAccount and CurrentAccount both define
  their own version of withdraw(), since there are
  different rules (e.g. savings cant go into
  overdraft)
• Operation withdraw() is not implemented at the
  level of Account. The signature is specified, to
  show that the subclasses MUST provide it.
• This makes Account an abstract class.
• You cannot have meaningful objects defined just
  by an abstract class. (i.e. you cant create an
  object of an abstract class)
• In UML class diagrams, an abstract class is
  either shown by the property abstract below its
  name, or by using italics.

22
Interfaces in Java

• Many java library classes use interfaces.
• An interface provides ONLY the specification of
  the methods, with no implementation
• For example, the List class specifies that
  subclasses must provide add and remove methods

23
Interface notation in UML

• Use ltltinterfacegtgt as shown in the previous slide
  for interfaces.
• Alternatively a ball and socket notation can be
  used.
• The diagram shows that ArrayList implements the
  List interface, and that the Owner class uses the
  List interface

List
Owner
ArrayList
Dog
24
Class Diagram

• If possible, show instance variables and methods
  and navigability in the same diagram
• For large systems, this is not always possible

25

• Interaction Diagrams

26
Determining classes, attributes and operations

• Use CRC cards (Class, Responsibilities,
  Collaborations)
• Write class, attributes and operations on index
  cards. Talk through scenarios, holding up cards
  at appropriate times and identifying how the
  classes interact.
• Use sequence and collaboration/communication
  diagrams
• Shows interaction between the classes
• Use state machine diagrams
• Shows how an object behaves when it receives a
  message
• Previous lecture

27
Typical class responsibilities

• All classes will maintain data about their
  fields, in the following ways
• Some data will be set in the constructor
• Some data may be returned with accessor methods
• Some data may be altered with mutator methods
• Some data, or combination of data, may be
  required as a String (for display)
• You may need to provide a method to determine if
  2 objects are equal
• E.g. Same name and phone number (?)
• You may need to provide a method comparing two
  objects with respect to a field
• E.g. compare names used to sort then print

28
Deciding on classes and details

• How to decide which classes?
• Noun analysis of requirements specification or
  use case scenarios to find suitable classes and
  attributes. Some nouns may be redundant,
  descriptive or out of the scope of the system.
• Scenarios
• The verbs in these descriptions also give clues
  to the messages passed between objects
• Once you have a plausible set of classes, you
  should work out exactly how they interact. Take
  each scenario of each use case and work through
  it what methods are called by which classes?
• You can use Sequence Diagrams and/or CRC cards to
  help with this.

29
CRC cards

• One common way of checking for a good design and
  guiding its refinement is to use CRC cards
• CRC stands for Classes, Responsibilities,
  Collaborations
• Although CRC is not part of UML, they add some
  very useful insights throughout development
• CRC Card Modelling is a simple yet powerful
  object-oriented hands-on analysis technique
• It was first developed as a teaching tool, then
  used as a collaborative technique to involve
  users, analysts and programmers in the design
  process

30
Creating a CRC card

• The name of a class, at the top

The collaborators of the class, which help to
carry out each responsibility, on the RHS. These
are classes used by the class named at the top,
NOT classes which use the responsibility
The responsibilities of the class, on the
LHS. (These turn into methods)
31
What is the CRC Card method?

• It is a method to help identify classes and
  methods in OO design
• Once you have identified potential classes (e.g.
  by finding nouns in the requirements spec) you
  use one card for each class
• On this you write down the responsibilities of
  that class
• these are the potential methods
• Once you agree that the classes and
  responsibilities seem OK
• you determine, for each class, which other
  classes it needs to collaborate with and write
  this on the card

32
Example LotList
Part of design of auction system
LotList LotList
Responsibilities Collaborators
maintain list of lots  
add a lot, given details Lot (constructor)
print all Lots Lot (get String)
find Lot, given the id Lot returnedLot class has get id
print each Lot giving bid details Lot another get string method - devolve Bid details to Lot
get each lot in turn Lot returned
33
Lot
Lot Lot
Responsibilities Collaborators
maintain data about id, description, bid  
return details as String (without bid)  
getId  
bidFor to replace new bid if higher Bid - getValue
return String showing details of lot, and Bid Bid - get details of Bid and Customer
34
CRC CARD MODELLING Overview

• A group of people should talk through a scenario.
  
• Write a card for each object, initially with just
  the attributes and any obvious methods
  (responsibilities)
• Cards for each class are divided amongst the
  people
• As you talk through a scenario, whenever it seems
  that a class is needed, the person with that card
  raises it.
• Through discussion, you can determine a suitable
  sequence of method calls between objects
• These can be documented using Sequence Diagrams

35
CRC CARD MODELLING

• At least, the idea of having a card (or page)
  with detailed responsibilities and collaborations
  of each class seems very valuable at the design
  stage an informal class diagram
• My examples show the collaborators opposite the
  responsibility in which they collaborate.
• Usually you will just see a list of collaborating
  classes, not linked to responsibilities

36
SEQUENCE DIAGRAMS

• One of the two types of interaction diagrams.
• Useful for showing complex interactions between a
  limited number of objects.
• Can be used to show one scenario of use from a
  technical perspective.
• Shows order of interaction vertically.
• Not useful for most users.
• Can show high or low level of detail

37
Example Sequence Diagram - planning
Notes Assumes details stored in a list X shows
deletion Can also do new() as message which
creates an object in which case lifeline only
starts at this point
aName
aDirectory
aContactDetail
delete (Jo Lo)
Get next contact detail object from list
See if contact detail objects name is Jo Lo
See if name is Jo Lo
Delete this object
message
object
lifeline
Activation box
38
Example Sequence Diagram - detail
See method calling another method in same class
small superimposed box Also NB the method name
on the arrowline belongs to the object at the
point of the arrow. sameName is in
ContactDetail class. The activation box shows
how long the method lasts for.
aName
aDirectory
aContactDetail
delete (Jo Lo)
aCD getNext()
ok name.equals (Jo Lo)
ok aCD.sameName(Jo Lo)
del(aCD)
39
Example Sequence Diagram - frames
Notes Frames show repetition and conditional
actions However, Activity diagrams show logic
better than sequence diagrams. Too many loops and
alteratives make the diagram complex. You could
just show the collaborations between the objects
as in the previous slide.
aName
aDirectory
aContactDetail
delete (Jo)
loop
for each contact detail until found
ok name.equals (Jo)
ok aCD.sameName(Jo)
if found
alt
del(aCD)
40
Lifelines

• Lifeline elements are placed across the top of
  the diagram
• Represent either roles or object instances that
  participate in the sequence
• Drawn as a box with a dashed line descending from
  the centre of the bottom edge
• The lifeline objects name is placed inside the
  box.

ac1Account
aCustomer

• The UML standard for naming a lifeline follows
  the format of
• Instance (Object) Name Class Name
• Underlined in UML1

41
Messages 1

• The messages show what operations take place
  between objects
• i.e. which methods are needed in which classes.
• Return is often assumed (not shown on the
  diagram)
• Leads to less clutter and therefore increased
  clarity

Synchronous (procedure)
Asynchronous (concurrent)
42
Messages 2

• You may also see diagrams without the activation
  box shown
• Objects can send messages to themselves (i.e.
  call their own methods)
• Messages may be numbered and nested
• Parameters may be passed
• Values may be returned using assignment
• Not all case tools use arrows in the same way!

43
UML sequence diagrams

• UML Sequence diagrams (Rumbaugh, Jacobson,
  Booch, 1999) are a dynamic modelling technique,
  as are collaboration diagrams and activity
  diagrams.
• The sequence diagram is used primarily to show
  the interactions between objects in the
  sequential order that those interactions occur.
• They are used to validate and flesh out the logic
  of a usage scenario which may be
• part of a use case, perhaps an alternative course
• one entire pass through a use case
• a pass through the logic contained in several use
  cases.

44
Uses of sequence diagrams

• The transition from requirements expressed as use
  cases to the next and more formal level of
  refinement.
• Use cases are often refined into one or more
  sequence diagrams.
• Explore designs by providing a way to visually
  step through invocation of the operations
• To show how objects in an existing ( legacy)
  system currently interact. This documentation is
  very useful when moving a system to another
  organisation.
• Time consuming to build but worth the investment

45
The Basics

• The main purpose of a sequence diagram is to
  define event sequences that result in some
  desired outcome
• The focus is less on messages themselves and more
  on the order in which messages occur
  nevertheless, most sequence diagrams will
  communicate what messages are sent between a
  systems objects as well as the order in which
  they occur
• The vertical dimension shows the time sequence of
  messages/calls as they occur
• The horizontal dimension shows the object
  instances that the messages are sent to

46
Centralised or distributed control

• The next diagrams illustrate 2 alternative
  designs
• The OrderEntry maintains data about quantity and
  product
• In Centralised control, the Order class
  controls everything
• The Order class gets this quantity and product
  from the OrderEntry, asks the Product class for
  the price, and then calculates the overall price
• In Distributed control, the classes are more
  tightly coherent
• The Order class asks the OrderEntry class what
  the price is

47
Order price centralised control (from
UMLDistilled)
anOrderEntry
aProduct
anOrder
calculate Price
getQuantity
getProduct
See how the calculatePrice method in Order calls
one of its own methods
getPricingDetails
calcPrice
OrderEntry
product Product quantity int
Code in Orderint quantity entry.getQuantity()
Product prod entry.getProduct()double cost
prod.getPricingDetails() double entryCost
this.calculatePrice(quantity, cost)
getProduct Product getQuantity int
48
Order price distributed control (from
UMLDistilled) BETTER
aProduct
anOrder
anOrderEntry
calculatePrice
calcPrice
getPrice (quantity)
OrderEntry
Code in Order double entryCost
entry.calcPrice() Code in OrderEntry public
double calculatePrice() return
product.getPrice(quantity)
product Product Quantity int
calculatePrice() double
49
Collaboration / Communication Diagrams

• Called Communication diagrams in UML 2
• Also shows interaction between classes, but
  emphasises structural relationships between
  objects
• The sequences of messages shown in sequence
  diagrams can then be super-imposed on these, with
  their arrows following the links.
• Wherever a message is to be sent, there must be a
  link and, by implication, an association must
  exist between the classes.
• Furthermore, the association must be navigable in
  the required direction.

50
Basics

• Each object is shown as rectangle, which is
  labelled objectName className
• Underlined in earlier versions of UML
• Objects are linked through message paths
• Links between objects are shown like associations
  in the class model
• Messages are attached to the message paths
• The class of the object at the point of the arrow
  must provide the appropriate operation
• Messages have a sequence number to denote time
• Actors can be shown as on a use case diagram

51
Communication diagram with nested decimal
numbering
Centralised control
1 calculatePrice
an Order
a Customer
1.5.1 getDiscountInfo
1.4 calculateBasePrice 1.5 calculateDiscounts
1.3 getPricingDetails
1.1 getQuantity 1.2 getProduct
a Product
an Order Line
52
Communication diagram with numbering
Distributed control
1 calculatePrice
4 getDiscountedValue
an Order
A Customer
5 getBaseValue
2 calculatePrice
a Product
an Order Line
3 getPrice
53
Summary

• Sequence and Collaboration diagrams together form
  the interaction diagrams
• These diagrams describe the same information, and
  can be transformed into one another
• Both describe the flow of messages between
  objects
• Sequence diagrams focus on the order in which the
  messages are sent. Useful for describing the
  procedural flow through many objects, and for
  finding race conditions in concurrent systems
• Collaboration diagrams focus on relationships
  between objects, Useful for visualising the way
  several objects collaborate to get a job done,
  and for comparing a dynamic model with a static
  model
• Choose depending on what you want to make
  visually apparent