COMMONWEALTH OF AUSTRALIA
FIT2005 Software Analysis, Design & Architecture
Copyright Regulations 1969 WARNING
Module 4: Modelling Software Internals: Object Interactions
Includes images from the book UML 2 and the Unified Process by Jim Arlow et al and The Unified Modeling Language Reference Manual by James Rumbaugh et al
This material has been reproduced and communicated to you 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 to copyright under the Act. Any further reproduction or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice.
[Link]
2
Interactions
Interactions involve two or more entities which exchange information/data Real-world interactions
E.g. shopping, phone-conversation, driving in traffic
Operation, Method, Message
Operation a function or transformation that may be applied to an object
The specification of what an object is capable of doing
Method the code
detail specifying how an object will achieve the function
Object interactions
One object sends a message to another object
Object-Oriented Programs are built by describing object interactions
Analysis and Design specifies these interactions
Message any communication received by an object asking it to perform a specific operation
Invocation of operation during programs execution
Interaction Sequence an ordered set of interactions which achieve some purpose
3 4
Focus of Control
For the period of time that a method is doing stuff, we say it has the focus of control
i.e. the CPU is doing the instructions of the method currently holding control.
Types of Messages
Synchronous The sender will wait until receiver returns focus of control back to sender Asynchronous The sender will not wait, but continue executing after the message has been sent. Message Return A reply sent from the receiver of an earlier synchronous or asynchronous message to the sender of the original message
Focus of control is given to the sender of original message
Sending a message usually has the effect of changing which method has focus of control
Sender method will wait (pause) until the called method has concluded, then resumes its work Only the method which has focus of control can send a message.
Multi-Threaded programs are programs which simulate multiple (concurrent) focus of control.
This is how operating systems run multiple programs at once
Types of Message (2)
Object Creation the sender creates a new instance of the class which receives the message Object Destruction The sender destroys the receiver
Messages Notation
Found Message The sender of the message is out of scope of the interaction as depicted (in diagram) Lost Message A message which never reaches its destination (during the period depicted)
[Source: Arlow]
Messages Notation (2)
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 or Actor or subsystem) No underline though it represents how an instance could participate in the interaction, rather than a particular instance. Sometimes drawn with a tail dotted vertical line
[Source: Arlow Figure 12.4] [Source: Arlow - Table 12.2]
10
Interaction Diagrams
Interaction Diagrams model any type of interactions
In use case realisation, they model interactions between objects and actors that realise the use case
Sequence Diagram
Sequence Diagrams show interactions between lifelines as a time-ordered sequence of messages
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 the name is prefixed by sd
[Source: Arlow]
11 12
Guards
A Guard is a Boolean expression which evaluates to true or false at run-time Written inside square brackets Examples:
[x<3] [ selectedProduct = null ] [ savings > 100 & creditRating = good ]
Guards (2)
A Guard can be used on a message to selectively control whether the message is to be sent at all
It is placed before the message name
If the message is skipped, then so are all messages which would have been sent during processing of that message Guards are also used in combined fragments !=
Should use relational operators: = < <= > >= Can use logical operators: & | !
13
14
Combined Fragments
Combined Fragments enable more complex control structures 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
Combined Fragments - Notation
A combined fragment has one operator, one or more operands, and zero or more guard conditions
[Source: Arlow]
15 16
Combined Fragments - Operators
Opt A single operand which executes if the condition is true Alt A set of operands with mutually exclusive conditions, of which only one may execute (or maybe none) Ref The combined fragment refers to another interaction
Allows you to link interactions across diagrams.
Selection/Branching in Sequence Diagrams
Loop Repeat the operand some number of times Break allows an unbounded loop to exit
[Source: Arlow]
17 18
Repetition in Sequence Diagrams
Interaction Occurrences
You can insert another interaction at any point in a sequence diagram using a ref fragment
Must state the name of the interaction to be inserted The ref fragment must overlap all lifelines which will be required in the other interaction to glue the two together
Multiple interactions can therefore include the other interaction
Caters for include from use-cases
[Source: Arlow]
19 20
Continuations
Continuations allow you to continue an interaction on a separate diagram
No further message shown in current diagram
Communication Diagrams
Communication Diagrams are another type of interaction 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
[Source: Arlow Figure 13.11]
[Source: Arlow Figure 13.12]
21 22
Use Case Realisation
Use Case Realisation Finding the classes, and the interactions between them, which realise the behaviour of a 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
FIT2005 Software Analysis, Design & Architecture
Use Case Realisation
Includes images from the book UML 2 and the Unified Process by Jim Arlow et al and The Unified Modeling Language Reference Manual by James Rumbaugh et al
Develop class diagrams and interaction diagrams
[Link]
24
A Use Case Realisation for a Bank Loan System
Another UC Realisation for the Bank Loan System
Source: Armour, p. 210
25
Source: Armour p. 210
26
Idioms
There are common interaction-tasks we find are needed by different systems.
These are called idioms
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 about customers 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
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 immediately accessible
These will be demonstrated by referring to an example
27
28
Sallys Business Identified Use Cases
From this general statement about the system Sally wants, several use cases may have been defined, including: Add new product type Add new loyal customer Process Customer Purchase
Sallys Business Identified Classes
We can also identify several classes just from looking at significant nouns mentioned in the description: Customer to keep track of details of the name of the
customer, some unique customer ID (or barcode of a rewards card)
Product to keep track of details of the name and price of
products for sale in the store
Purchase to keep track of details of items purchased in one
transaction
Shop a place to represent other information about Sallys
business, and in which to aggregate objects of the preceding types
29
30
Example: Process Customer Purchase
When a customer is purchasing items, there is specific processing that must be done. We can describe this in general terms as follows: When a customer is ready to purchase some items, they will bring these to the counter. The counter clerk will scan the barcode of all items, and scan the customers loyalty-card, the system will report the details 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 think about how to design interactions between objects
Interactions can be described using algorithms
31
Interaction Algorithm for the Purchasing use case
Some nouns indicate likely objects Create a new Purchase object Ask for the customers unique code Locate the Customer object which contains the details of the customer While there are more items to be purchased: Ask for the code of the next product Locate the Product object corresponding to that product Note the Product as having been part of the Purchase transaction Ask the Product what its price is Other nouns indicate Add the price to the total cost of the Purchase likely attributes of Display the Products Name and Price to the Screen objects Print the Products Name and Price to the Docket End While Display the Purchases total cost on the screen Print the Purchases total cost on the docket Process payment (a separate algorithm) Link the Purchase to the Customer. Verbs indicate likely processing, which will be messages
32
Collaborations in the Purchase use case
Objects will collaborate with other objects to achieve some 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 yet further objects Some of the steps in the algorithm will themselves need separate use case realisations
E.g. the Locate the Product object corresponding to that product involves complex steps we would not include these in the purchase use case realisation though.
Things to keep in mind for interactions
To collaborate, one object must have a reference (link) to the 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 can go via some intermediate object If a message is sent to a lifeline of a class which has subclasses (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
33
34
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 other parts 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 future access?
Goal: Creation of Objects
Sequence which demonstrates creating a new Product object
35 36
Goal: Communicating information to other objects
Objects are independent encapsulated units. The only way that any other object can know something that some particular object knows, is if it gets told or asks specifically for that information. For example, a Purchase object (representing a transaction) needs to be told that another Product is being added to the current Transaction / bill. Need to consider: what operations will be provided to receive communication of information?
Goal: Communicating information to other objects
Purchase provides chargeProduct to be told information
37
Purchase calls the getPrice method to gather information
38
Example with a loop:
Goal: Establishing links between objects
Recall that a link is a somewhat permanent connection between 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 a purchase. The way we indicated which product was being purchased, was by ensuring that an object (prod) was given as a parameter conveyed by a message sent to another (to pur). Once an object has been conveyed as a parameter, it is possible for the recipient object to remember the reference in its own memory space for the future.
This would occur once a purchases payment is approved
39 40
Goal: Obtaining an object reference from a collection or repository
By collection or repository we mean some class which holds 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
Goal: Obtaining an object reference from a collection or repository
The collection must provide operations to perform searches / 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.
41
42
Goal: Obtaining an object that is linked
If you know that an object you want is linked to from another object that you currently know, you could ask to be given the link For example, a University knows which Unit objects are linked to it. So you could ask the University for a specific Unit.
Goal: Obtaining an object that is linked
43
44
Goal: Obtaining directly accessible information
Quite often in developing interactions for processing use cases, we need to get information from multiple linked objects, to use in the processing, e.g. to calculate something. The previous example illustrated this where just one object (a Unit) was asked for information. More often, multiple objects will be involved, and the information must be collated from those objects and possibly passed on by other messages.
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 the supplier of the cereal product that has just been added to the Purchase object. In order to get such information requires the use of a technique 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.
45 46
Concurrency Active Classes
An Active Object is an object which has its own thread of control, distinct from other objects They are instances of Active Classes Notation: double-edged left and right sides
FIT2005 Software Analysis, Design & Architecture
Advanced topics in modelling interactions
Includes images from the book UML 2 and the Unified Process by Jim Arlow et al and The Unified Modeling Language Reference Manual by James Rumbaugh et al
FTPServer
Connection
[Link]
48
Concurrency in sequence diagrams
The par combined fragment allows for concurrent threads to be expressed in one diagram Each operand (section) of par runs independent of each other.
Critical region
A critical region means a fragment where the events will take exclusive control of the objects which receive them
No other parallel fragments requiring that object will be able to execute events in parallel
Source: Rumbaugh
Source: Rumbaugh
49
50
Another concurrency example
Readings
Prescribed:
Arlow: Chapters 12 and 13 and parts of 20
51
52
