fit2005-lecture4-4pp

7/31/2019 fit2005-lecture4-4pp

1/13

www.monash.edu.au

FIT2005 Software Analysis, Design & Architecture

Module 4:

Modelling Software Internals:

Object Interactions

Includes images from the book UML 2 and the Unified Process by Jim Arlow et al andThe Unified Modeling Language Reference Manual by James Rumbaugh et al 2

COMMONWEALTH OF AUSTRALIA

Copyright Regulations 1969WARNING

This material has been reproduced and communicated toyou by or on behalf of Monash University pursuant to Part

VB of the Copyright Act 1968(the Act).

The material in this communication may be subject tocopyright under the Act. Any further reproduction or

communication of this material by you may be the subject ofcopyright protection under the Act.

Do not remove this notice.

3

Interactions

Interactions involve two or more entities which exchangeinformation/data

Real-world interactions

E.g. shopping, phone-conversation, driving in traffic

Object interactions

One object sends a message to another object

Object-Oriented Programs are built by describing objectinteractions

Analysis and Design specifies these interactions

Interaction Sequence an ordered set of interactionswhich achieve some purpose

4

Operation, Method, Message

Operation a function or transformation that may beapplied to an object

The specification of whatan object is capable of doing

Method the code

detail specifying howan object will achieve the function

Message any communication received by an objectasking it to perform a specific operation

Invocation of operation during programs execution


2/13

5

Focus of Control

For the period of time that a method is doing stuff, wesay it has the focus of control

i.e. the CPU is doing the instructions of the method currentlyholding control.

Sending a message usually has the effect of changingwhich method has focus of control

Sender method will wait (pause) until the called method hasconcluded, then resumes its work

Only the method which has focus of control can send a message.

Multi-Threaded programs are programs which simulatemultiple (concurrent) focus of control.

This is how operating systems run multiple programs at once

6

Types of Messages

Synchronous The sender will wait until receiverreturns focus of control back to sender

Asynchronous The sender will not wait, but continueexecuting after the message has been sent.

Message Return A reply sent from the receiver of anearlier synchronous or asynchronous message to thesender of the original message

Focus of control is given to the sender of original message

7

Types of Message (2)

Object Creation the sender creates a new instance ofthe class which receives the message

Object Destruction The sender destroys the receiver

Found Message The sender of the message is out ofscope of the interaction as depicted (in diagram)

Lost Message A message which never reaches itsdestination (during the period depicted)

8

Messages Notation

[Source: Arlow]


3/13

9

Messages Notation (2)

[Source: Arlow - Table 12.2]

10

Lifeline

Lifeline a participant in an interaction

Name optional

Type necessary

Selector optional condition to select a single instance

Notation:

Same icon as the classifier it is a placeholder of (e.g. Class orActor or subsystem)

No underline though it represents how aninstance couldparticipate in the interaction, rather than a particular instance.

Sometimes drawn with a tail dotted vertical line

[Source: Arlow Figure 12.4]

11

Interaction Diagrams

Interaction Diagrams model any type of interactions

In use case realisation, they model interactions between objectsand actors that realise the use case

UML defines 4 types of Interaction Diagrams Sequence Diagram

Communication Diagram

Interaction Overview Diagram

Timing Diagram

Diagrams are usually named in top-left corner, and thename is prefixed by sd

12

Sequence Diagram

Sequence Diagrams show interactions between lifelinesas a time-ordered sequence of messages

[Source: Arlow]


4/13

13

Guards

A Guard is a Boolean expression which evaluates to true

or falseat run-time

Written inside square brackets

Examples:

[ x < 3 ]

[ selectedProduct = null ]

[ savings > 100 & creditRating = good ]

Should use relational operators:

= < >= !=

Can use logical operators:& | !

14

Guards (2)

A Guard can be used on a message to selectively controlwhether the message is to be sent at all

It is placed before the message name

If the message is skipped, then so are all messageswhich would have been sent during processing of thatmessage

Guards are also used in combined fragments

15

Combined Fragments

Combined Fragments enable more complex controlstructures in sequence diagrams

3 type of control available in most programming:

Sequence ordered steps

Selection choosing one course of action from several choices

Repetition repeating some sequence

A combined fragment has one operator, one or moreoperands, and zero or more guard conditions

16

Combined Fragments - Notation

[Source: Arlow]


5/13


6/13

21

Continuations

Continuations allow you to continue an interaction on aseparate diagram

No further message shown in current diagram

[Source: Arlow Figure 13.11] [Source: Arlow Figure 13.12]

22

Communication Diagrams

Communication Diagrams are another type ofinteraction diagram

They emphasise the static structure of the system Similar to an object diagram (shows links),

except we dont show actual objects, we show placeholders

Sequence of messages requires explicit numbering

www.monash.edu.au


Use Case Realisation


Use Case Realisation

Use Case Realisation Finding the classes, and theinteractions between them, which realise the behaviour ofa use case

Goals:

Find out which classes interact

Find out the key operations needed in the classes

Find out the key attributes needed in the classes

Find the important relationships between classes

Develop class diagrams and interaction diagrams


7/13

25

A Use Case Realisation for a Bank Loan System

Source: Armour, p. 210

26

Another UC Realisation for the Bank Loan System

Source: Armour p. 210

27

Idioms

There are common interaction-tasks we find are neededby different systems.

These are called idioms

Idioms you need to know about are: Creation of new objects to store data

Communicating information to other objects

Establishing links between objects

Obtaining information from an object

Obtaining information from an object which is not immediatelyaccessible

These will be demonstrated by referring to an example

28

Sallys Business

Sally Smith runs a small retail business, and requires a

computer program which can keep track of the inventory of

products it sells, as well as produce invoices for purchases

made by customers. Additionally, information aboutcustomers is maintained so that customers who spend a lot

at the store can be rewarded with discounts. Sally wants to

be able to know who has purchased items from her each

week, and also wants to know which products are running

low in inventory


8/13

29

Sallys Business Identified Use Cases

From this general statement about the system Sallywants, several use cases may have been defined,

including: Add new product type

Add new loyal customer

Process Customer Purchase

30

Sallys Business Identified Classes

We can also identify several classes just from looking atsignificant nouns mentioned in the description:

Customer to keep track of details of the name of thecustomer, some unique customer ID (or barcode of a rewardscard)

Product to keep track of details of the name and price ofproducts for sale in the store

Purchase to keep track of details of items purchased in onetransaction

Shop a place to represent other information about Sallysbusiness, and in which to aggregate objects of the precedingtypes

31

Example: Process Customer Purchase

When a customer is purchasing items, there is specificprocessing that must be done. We can describe this ingeneral terms as follows:

When a customer is ready to purchase some items,they will bring these to the counter. The counter clerkwill scan the barcode of all items, and scan thecustomers loyalty-card, the system will report thedetails of each item to the screen and print a docket.Finally, payment is processed.

We should convert it first to a use case, then we can thinkabout how to design interactions between objects

Interactions can be described using algorithms

32

Interaction Algorithm for the Purchasing use case

Create a new Purchase objectAsk for the customers unique codeLocate the Customer object which contains the details of the customerWhile there are more items to be purchased:

Ask for the code of the next productLocate the Product object corresponding to that productNote the Product as having been part of the Purchase transactionAsk the Product what its priceisAdd the price to the total costof the PurchaseDisplay the Products Nameand Priceto the ScreenPrint the Products Nameand Priceto the Docket

End WhileDisplay the Purchases total coston the screen

Print the Purchases total coston the docketProcess payment (a separate algorithm)Link the Purchase to the Customer.

Some nouns indicate likely objects

Verbs indicate likely processing, which will be messages

Other nounsindicatelikely attributes of

objects


9/13

33

Collaborations in the Purchase use case

Objects will collaborate with other objects to achievesome functionality within the system

Messages are sent to some objects to obtain information

The information is used by some coordinating process,which may send the raw or processed information to yetfurther objects

Some of the steps in the algorithm will themselves needseparate use case realisations

E.g. the Locate the Product object corresponding to that productinvolves complex steps we would not include these in thepurchase use case realisation though.

34

Things to keep in mind for interactions

To collaborate, one object must have a reference (link) tothe target object

How will it get this link in first case? Parameter?

Association?

If one object has no direct way to a target, perhaps it cango via some intermediate object

If a message is sent to a lifeline of a class which hassubclasses (next week), polymorphic behaviour will occur An instance of any subclass could be involved at run-time

More advice is in the study guide for this week.

We now look at several idioms

35

Goal: Creation of Objects

Consider the first use case: Add new product type

it aims to put some data into the system for use by otherparts of the system in the future

Questions to resolve:

Where does the information come from?

Where will it be stored?

How do we establish it in the system for futureaccess?

36

Goal: Creation of Objects

Sequence which demonstrates creating a new Productobject


10/13

37

Goal: Communicating information to other objects

Objects are independent encapsulated units.

The only way that any other object can know somethingthat some particular object knows, is if it gets told or asksspecifically for that information.

For example, a Purchase object (representing atransaction) needs to be told that another Product isbeing added to the current Transaction / bill.

Need to consider: what operations will be provided to

receive communication of information?

38

Goal: Communicating information to other objects

Purchase provides chargeProduct to be told information

Purchase calls the getPrice method to gather information

39

Example with a loop:

This would occur once a purchases payment is approved40

Goal: Establishing links between objects

Recall that a link is a somewhat permanent connectionbetween two objects one knows of the other.

links do not exist naturally, they must be explicitly made.

Consider the earlier example of adding a product to apurchase. The way we indicated which product was beingpurchased, was by ensuring that an object (prod) wasgiven as a parameter conveyed by a message sent toanother (to pur).

Once an object has been conveyed as a parameter, it is

possible for the recipient object to remember thereference in its own memory space for the future.


11/13

41

Goal: Obtaining an object reference from acollection or repository

By collection or repository we mean some class whichholds an aggregation of objects.

For example, a Library is an aggregation of many Book objects You could ask for a book by giving criteria to the Library, such

as ISBN or Call Number

The collection must provide operations to performsearches / selections

Could possibly communicate with a database system.

The methods must return the match(es), or if no match is

found either null or an empty set.

42

Goal: Obtaining an object reference from acollection or repository

43

Goal: Obtaining an object that is linked

If you know that an object you want is linked to fromanother object that you currently know, you could ask tobe given the link

For example, a University knows which Unit objects arelinked to it. So you could ask the University for a specificUnit.

44

Goal: Obtaining an object that is linked


12/13

45

Goal: Obtaining directly accessible information

Quite often in developing interactions for processing usecases, we need to get information from multiple linked

objects, to use in the processing, e.g. to calculatesomething.

The previous example illustrated this where just oneobject (a Unit) was asked for information.

More often, multiple objects will be involved, and theinformation must be collated from those objects andpossibly passed on by other messages.

46

Goal: Obtaining not-directly accessible information

Possibly trickiest part of interaction design

Example: You have a reference to a Product class, but

want to have a reference to: the address details of thesupplier of the cereal product that has just been addedto the Purchase object.

In order to get such information requires the use of atechnique akin to burrowing. In the case just described,you would do the following:

1. Send a message to the Product asking for its Supplier

object.2. Send a message to the Supplier object asking it for its

Address object

3. Send messages to the Address object to get details.

www.monash.edu.au


Advanced topics inmodelling interactions


Concurrency Active Classes

An Active Object is an object which has its own thread ofcontrol, distinct from other objects

They are instances of Active Classes

Notation: double-edged left and right sides

FTPServer * Connection1


13/13

49

Concurrency in sequence diagrams

The par combined fragment allows for concurrent threadsto be expressed in one diagram

Each operand (section) of par runs independent of eachother.

Source: Rumbaugh

50

Critical region

A critical region means a fragment where the events willtake exclusive control of the objects which receive them

No other parallel fragments requiring that object will be able toexecute events in parallel

Source: Rumbaugh

51

Another concurrency example

52

Readings

Prescribed:

Arlow: Chapters 12 and 13 and parts of 20

fit2005-lecture4-4pp

Documents