System Sequence Diagrams
Tutorial
Use-Case for Monopoly game
•
•
•
•
•
•
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.
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.
Use-Case Diagram
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
Domain Model of the Monopoly
Game
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.
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.
System Sequence Diagram
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.
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.
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.
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.
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
• 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