1. System Sequence Diagrams
Tutorial

2. Use-Case for Monopoly game
Use Case UC1: Play Monopoly Game
Scope: Monopoly application
Level: user goal
Primary Actor: Person
Stakeholders: Person: Wants to easily observe the output of the game simulation.

3. Use-Case for Monopoly game
Main Success Scenario:
1. Person enters number of players and requests new game initialization.
2. Person starts play
3. System displays game trace for next player move
4. Repeat step three until a winner or Person cancels.
The following would be part of the supplementary specication in a RUP project:
Domain Specic Rules: The rules for the game are:
Two to eight players can play.
A game is played as a series of rounds on a board comprised by 40 squares. During a round, each player takes one turn.
In each turn, a player advances his/her piece clockwise around the board a number of squares equal to the sum of the numbers rolled on two six-sided dice.
After the dice are rolled, the name of the player and the roll are displayed, as well as the target square's name.

4. Use-Case Diagram

5. Domain Model Remember the key idea of the Domain Model:
A domain model is a representation of real-world conceptual
classes, not of software artifacts. It is not a set of diagrams
describing software classes with responsibilities.
Considering this, a possible Domain model for the given example
would contain:
MonopolyGame
Die
Board
Player
Piece
Square 5

6. Domain Model of the Monopoly Game

7. Sequence Diagram On Sequence Diagrams:
Time flow is organized from top to bottom.
Focus of control is shown using an activation box which is optional, but commonly used.
A return from a message may be shown as a dashed open-arrowed line. Many practitioners exclude them.
Messages sent to self can be illustrated using a nested activation box.
Conditional messages are shown in square-brackets. Can be converted to communication diagrams and vice versa.

8. System Sequence Diagram
On System Sequence Diagrams:
An SSD should be done for the main success scenario of the use case, and frequent or complex alternative scenarios.
Properties of an SSD:
The UML does not define something called a system sequence diagram.
SSDs are part of the Use-Case Model (although not
mentioned explicitly within the UP documentation) { a
visualisation of the interactions implied in the use cases.
Treat the system as a black-box.
Show user interaction(s) with the system and the actions
induced by these.

9. System Sequence Diagram

10. Operation Contracts Contracts in the UML are Operation Specifications.
Help define system behavior.
Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model.
Usually defined for system operations (identified for example with an SSD).
Contain pre-conditions to express noteworthy assumptions
about the system's state before the operation's execution.
Contain post-conditions which define the state of objects in
the Domain Model after completion.

11. Operation Contract Contract C01: initialize
Operation: initialize(numberOfPlayers: integer)
References: Use Case UC1: Play Monopoly Game
Preconditions: Monopoly Game application running
Postconditions:
A Board instance b was created.
b was associated with 40 squares.
2 dice were created.
The appropriate number of players was created.
A Piece is created and associated with each player.
All pieces were placed on the initial square.

12. Public Library High level format: Name: search for book
Actors: patron (Initiator), librarian
Type: primary, essential
Description: This use case beginning when patron come to librarian and ask him about certain book in library by give name of author ,then librarian search in system and tell the patron about department and number of shelf that book founded there.

13. Expanded format: Name: search for book
Actors: patron (Initiator), librarian
Type: primary, essential
Description: This use case beginning when patron come to librarian and ask him about certain book in library by give name of author ,then librarian search in system and tell the patron about department and number of shelf that book founded there.

14. Typical course of event:
Actor Action
System response
1- This use case beginning when the patron come to library and ask librarian about certain book
2-The librarian asks the patron about name of author book and enters it to the system.
3- The system display all books that written by this author and ask about name of book.
4-the librarian ask the patron about the name of book that written by this author and edition and enter the name to system.
5-The system display the book and position on the library with available number of edition.
6-The librarian ask system to print report
About position of book in library.
7-system print the report with all Information about position of book
8-The librarian give the patron the report
With information of position like:
Department, number of shelf

15. Alternatives:
Alternative 3: the name of author not exist in the library so cancel the search
Alternative 5: the name of book not exist in the library, so cancel searching