Unit 7 - More on dynamic modelling - states and activities Flashcards
UML has a more structured way of indicating conditional, alternative and iterative behaviour. This is based on the use of a more general notion of what
is called a fragment, which is sometimes referred to as a frame. What are some standard labels?
Opt, alt or loop, standing for optional, alternative or looping behaviour.
. Optional fragment. The behaviour specified inside the fragment is only executed if a guard, shown at the top of the box, is true
. Alternative fragment. This is used where we want to choose from a number of mutually exclusive pieces of behaviour. The box is divided, with alternatives in sub-boxes along with appropriate guards.
One sub-box can be labelled with the guard else, to indicate it contains the default behaviour. (Hence the opt fragment is like a simplified alternative fragment, with one guard and no default behaviour.)
. Loop fragment. The behaviour is repeated while a guard, shown in the top left-hand corner, remains true or a variable moves between two bounds.
Why must the conditions on a message send be mutually exclusive in a sequential system?
If conditions were not mutually exclusive, more than one condition might be true. This would mean that multiple messages would be sent at once, resulting in multiple receiving objects being active at the same time – leading to the possibility of non-deterministic
behaviour.
Figure 2 shows two conditional message sends originating at the same moment on the timeline, meaning that all the guards are evaluated before any message is sent. Could the same behaviour be
implemented if the messages (and their conditions) were separated on the time line?
Yes, provided that the conditions were mutually exclusive, so that the first message could not affect the state of the receiver before the second message arrived. We might use code such as the following:
if (room.ready) room.accept(jill);
if (!room.ready) room.requestCleaner();
Suggest a reason why an object’s lifeline must branch in cases such as Figure 2. How is this handled in Figure 5?
The Room object will receive different messages depending on which branch is executed in the Hotel object. It makes no sense for the messages to arrive at just one lifeline, as that would imply that the Room object received all of the messages in a single interaction. Instead, we show a fork in the lifeline of the receiving object to reflect the fork of control in the sending object in Figure 2.
In Figure 5 the alternatives are shown using the alternative fragment. Although the figure doesn’t show a branching lifeline, this same branching is implied by the alternatives in the fragment, in their separate boxes.
How would you change the sequence diagrams in Figures 3 and 6 to sound the car’s horn five times each time it moved forward?
To get the horn to sound five times for every forward movement in the sequence diagram in Figure 3 you would add an iteration clause to the second, nested message: *[j := 1..5] sound().
In Figure 6 you would add the extra iteration by including a fragment within the
existing fragment.
Give three strategies for implementing use cases.
One central class. Some designers like to minimise the knowledge the interface must have of the
business model by making the interface send all messages to a single object – usually some general object like a System or Hotel. In the case of the hotel
chain model each message could initially be sent to the Hotel, which would then forward the message to whatever object is to do the work.
Actor classes. Other designers are of the opinion that a clearer structure will result if the message is sent to a software object corresponding to the real-world actor who initiated the operation. For example, when a person arrives at a hotel they initiate the checking in process.
Use cases as classes. In a third strategy, interface messages are sent neither to a system object like a Hotel nor to the object corresponding to an actor. Instead, a new class is defined for each use case. There might be classes such as CheckerIn, CheckerOut and ReservationMaker. Each would have a method with a name like run, with a suitable number of arguments. The user interface would then create a single instance of the appropriate class, initialise it suitably and then send the run(…) message.
What is the main disadvantage of defensive programming?
The main disadvantage of defensive programming is that the same constraints within each precondition may be checked repeatedly in different operations.
Which of the three strategies for implementing use cases is being used when we place methods such as createGuest(lastname : String, firstname : String, address : String) in the Hotel class?
We are following the strategy of using one central class here.
Are use case objects consistent with the twin aims of high cohesion and low coupling?
Yes and no. Yes, because high cohesion asks us to ‘do one thing and do it well’. A CheckerIn class should only support the one activity of checking in. No, because having an extra class for each use case introduces more coupling through the extra associations involved.
Suppose you are designing the graphical user interface (GUI) part of a hotel system. You need to be able to check in people known to the system as well as new people. What operations on the business model might be needed to support a usable GUI?
Checking in unknown people would involve the creation of a new Guest object, requiring an operation createGuest(firstName, lastName, address).
Recall the library system in Exercise 4 in Block 1 Unit 3. Suppose you wanted to minimise the dependency of the user interface on the rules and concepts of the library domain. Which messages should be sent from the user interface and to which object should the user interface send its messages?
A solution can be found from the first of the three strategies discussed above. The messages sent from the user interface correspond to each of the library’s use cases. . reserveBook(…) . borrowCopyOfBook(…) . returnCopyOfBook(…) . updateCatalogue(…) . enrolNewMember(…) . browseCatalogue(…).
What is a state machine?
It is a model that shows how an object changes from state to state in response to events.
What features are common to all state machine diagrams?
. states, represented by the round-cornered rectangles containing their names
. events, given as labels on transition arrows
. transitions, represented by arrows and identified by the events that give rise to them. Transitions occur as a response to an event, and cause a change of state.
What does a state machine model?
. its initial state when first created
. the different states it can be in while it exists
. how it can move from state to state in response to events – the state transitions that are possible.
What is used in UML to represent a state machine’s initial state?
A solid black circle.
What is used in UML to represent a state machine’s final state?
A black circle surrounding a solid black circle, to show that processing has been terminated.
Figure 15 shows a simple state machine diagram for the class Copy in a library model. What should happen if the copy returned message arrives when an object of the class Copy is in the state on shelf (assuming that we are not using design by contract)?
Something has gone wrong. The state of the system does not describe the fact that the copy of the book is on loan, so it cannot be returned. There must be some means of indicating or recording an error, such as a message to a log file.
Give an example of an architectural decision that would provide a general solution to the problem of unexpected messages.
At an architectural level we might introduce a single object of a class Error, which is globally accessible to objects in the software system. Such an object would be responsible for reporting errors due to unexpected messages, for example.
