Summary Class responsibility cards can be used to help allocate responsibilities between different classes. The use of stereotype classes, such as entity, boundary and control classes also help achieve this. Robustness/communication diagrams show the different classes which collaborate to achieve the goal of each use case. The aim is for each class to have appropriate responsibilities, and a class that is relatively small, clearly focussed and self-contained is easier to develop, test and maintain and has a much greater potential for reuse than a large class with responsibilities or functionality that are not clearly focussed. Such classes help produce a system that is more resilient to changes in its requirements, as change will be localised.

Object Interaction Sequence diagrams

Aim to determine the most best way to send messages between objects in order to support a particular user requirement.

Sequence diagrams show the interactions between objects in the sequential order that those interactions occur. Like communication diagrams, they show message passing between objects and actors, but time sequence is shown and they are a bit more detailed. They are most commonly used to describe one use case (but can also be drawn at different levels of detail)

Basic Points Objects are drawn horizontally and have a dashed line called a lifeline coming down from them. Time proceeds down the page. A message is shown by an arrow from the lifeline of the sending object to the receiving object. The sequence of messages can include loops and branching. They can also refer to other sequence diagrams. Sequence diagrams can also show concurrency and time constraints.

Other Guidelines 1.Know the level you’re working at e.g. use case 2.Identify main elements e.g. using the collaboration diagram 3.Consider alternative scenarios or ways of doing things. 4.Draw the outline structure with a labelled frame and objects 5.Add the lifelines, starting with the lifeline that is first involved. 6.Add the detailed interaction from the first message and so on… 7.Identify any interaction fragments that might be used elsewhere and give these their own sequence diagram. This makes them as reusable as possible. 8.Annotate for clarity 9.Check set of sequence diagrams for consistency and also for consistency with other UML diagrams/models, in particular, class diagrams. 10.As with other UML diagrams it is important to refine the model to get the best solution- i.e one that describes the behaviour unambiguously and clearly.