This is the training material on UML. The supportive source code can be cloned from https://github.com/sommukhopadhyay/RestaurantSystem

1. UML Training
by
Somenath Mukhopadhyay
+91 9748185282
som@som-itsolutions.com / som.mukhopadhyay@gmail.com

2. Part I – Use Case
Part II – Class Diagram
Part III – Sequence Diagram

3. Use Case Analysis

4. What is a Use Case
● A formal way of representing how a business system
interacts with its environment
● Illustrates the activities that are performed by the users of
the system
● A scenario-based technique in the UML
●
A sequence of actions a system performs that yields a
valuable result for a particular actor.

5. What is an Actor?
● A user or outside system that interacts with the system
being designed in order to obtain some value from
that interaction
● Use Cases describe scenarios that describe the interaction
between users of the system (the actor) and the system
itself.

6. ● Use case diagrams describe what a system does from
the standpoint of an external observer. The emphasis is
on what a system does rather than how.
● Use case diagrams are closely connected to scenarios.
A scenario is an example of what happens when
someone interacts with the system.

7. Step 1 - Identify the actors
As we read the scenario, define those people or systems
that are going to interact with the scenario.
A customer enters a restaurant and requests for a table. The receptionist finds an empty table and
asks the customer to occupy it.

8. Questions for identifying People
Actors
● Ask client and domain experts how system will be
used
● Who will perform the obvious tasks?
Secondary tasks of maintenance and
administration? Interact with other systems?

9. Questions for identifying other
Actors
● What other entity is interested in the
scenario/system?
● What other entity will supply the scenario/system
with this information, use this information, and
remove this information?
● Does the system use an external resource?

10. Actors
An Actor is outside or external the system.
It can be a:
● Human
● Peripheral device (hardware)
● External system or subsystem
● Represented by stick figure

11. Step 2 – Recording the use case
For each actor, what interactions they require of the system – each
is a use case
● What tasks does the actor want the system to perform
● What information must the actor provide to the system
● Are there events that the actor must tell system about
● Does actor need to be informed when something happens
● Does actor help initialize or shut down the system

12. Case Study – Restaurant System
Actor : Customer
● What tasks does the actor want the system to perform?
- Find an empty table to occupy, display the menu card, take the order & accept the payment
● What information must the actor provide to the system?
- How many guests are there with him, choice of his menu and how many plates for each of
them
● Are there events that the actor must tell system about?
- Whether he wants to pay through credit card/check/cash
● Does actor need to be informed when something happens?
- If any menu chosen by the customer is not available he has to be informed
● Does actor help initialize or shut down the system
- no

13. Resulting Use Cases –
Actor : Customer
Customer enters the Restaurant and asks the receptionist for an
empty table
Customer looks at the menu & places an order
Customer is notified when any item of the menu is not available
Customer complets the food, leaves the table and pays the bill
Note: simple phrases, without much details initially.

14. Other Actors
● The receptionist opens the chart of the empty table
and suggests one to the customer
● The waiter takes order from the customer, notifies
him if anything is not available and serves him the
food
● The cashier calculates the bill and gives it to the
customer
● An external system (say a tablet) may be used as
an Actor for displaying & ordering the menu

15. Use Cases – Restaurant System
Use Case Name Request A Table
Actor Customer
Description
Describes the process when a
customer steps inside a restaurant and
asks the Receptionist/May I Help You
for a Table
Normal Flow
Customer enters the Restaurant and
asks for a table
Exceptional Flow None

16. Use Case Name ProduceTheTableChart
Actor Receptionist/May I Help You
Description
Describes the process when the
receptionist opens the chart to see
which table is empty
Normal Flow
1. Receptionist opens the chart and
finds out which table is empty
2. She asks the customer to occupy
the vacant table
Exceptional Flow
If all the tables are occupied, the
receptionist puts the customer in a
queue

17. Use Case Name Manage Menu & Order
Actor External System (Say a Tablet)
Description
It displays the menu items and their
prices
Normal Flow
1. Displays the menu items and their
prices
2. Lets one to choose and pick from
the list and how many plates for each
item
Exceptional Flow
When a menu item is not available, it
lets others know about that

18. Use Case Name Place An Order
Actor Customer
Description
Describes the process when a
customer looks at the menu table and
orders for some items
Normal Flow
1. Customer looks at the menu table
2. Customer chooses some from the
table and decides how many plates for
each menu item
3. Customer places the order
Exceptional Flow None

19. Use Case Name Collects The Order
Actor Waiter
Description
Describes the process when a waiter
collects an order from a customer and
serves foods to the later
Normal Flow
1. Waiter collects the order from the
customer
2. Waiter delivers the food
Exceptional Flow
When any menu item is not available
the waiter lets the customer know
abotu it

20. Use Case Name Collect Money
Actor Cashier
Description
Describes the process when a
customer wants to pay the bill
Normal Flow
1. Cashier opens the Billing System
and find out how much is due for the
current customer
2. Cashier asks the customer what
kind of payment method the later
wants to use : Cash/Credit Card/Check
3. If the customer wants to pay using
credit card, the cashier processes it
using a machine
4. The cashier collects the money
Exceptional Flow
When the customer does not have any
credit balance in his credit card

21. Use Case Name Update Account Info
Actor Cashier
Description
Describes the process when the
cashier updates the Account Info in the
main System after the customer pays
the bill
Normal Flow The cashier updates the Account Info
in the System
Exceptional Flow None

22. Use Case Name Produce Billing System Info
Actor External System ( May be a Tablet)
Description
Describes the process when the Actor
interacts with the Server/Legacy
System to show the amount due for
the current customer
Normal Flow
Starts interacting with the backend
system and shows the Amount due for
the current customer
Exceptional Flow The Backend system is down

23. Use Case Name Pay Bill
Actor Customer
Description
Describes the process when the
customer wants to pay the bill
Normal Flow The customer proceeds to the cash
counter and pays the bill
Exceptional Flow None

24. Use Case Name Pay Bill By Cash
Actor Customer
Description
Describes the process when the
customer wants to pay the bill in Cash
Normal Flow The customer proceeds to the cash
counter and pays the bill in Cash
Exceptional Flow
The customer does not have the
required amount of cash at that
moment

25. Use Case Name Pay Bill By Cheque
Actor Customer
Description
Describes the process when the
customer wants to pay the bill through
Check
Normal Flow
The customer proceeds to the cash
counter and pays the bill through check
Exceptional Flow None

26. Use Case Name Pay Bill By Credit Card
Actor Customer
Description
Describes the process when the
customer wants to pay the bill through
Credit Card
Normal Flow
The customer proceeds to the cash
counter and pays the bill through
Credit Card
Exceptional Flow
The customer does not have the
required credit amount in his credit
card account

27. Relationships between Use Cases
● Include
● Extend

28. Include Relationship
● Represents the inclusion of the functionality of one use
case within another
● Arrow is drawn from the base use case to the used
use case
● Write << include >> above arrowhead line

29. Restaurant System – Use Case Diagram

30. Class Diagrams

31. What is a Class Diagram
● A Class Diagram is a diagram describing the
static structure of a system
● It shows the system's
● classes
● attributes
● operations (or methods),
● Relationships among the classes.

32. Essential elements of a UML Class
Diagram
● Class
● Attributes
● Operations
● Relationships
➔ Dependency
➔ Aggregation
➔ Composition
➔ Inheritance
➔ Realization
● Constraint Rules and Notes

33. Class
● A class in UML Class Diagram has
➔ Attributes ( state)
➔ Operations (behavior)
● It has static relationship with the other classes of the system
● Each Atrribute & Operation has different visibilities
➔ “+” for public
➔ “-” for private
➔ “#” for protected

34. Relationship between classes

35. The relationships are called as
● Dependency : class A uses class B
● Aggregation : class A has a class B
● Composition : class A owns a class B
● Inheritance : class B is a Class A (or class A is
extended by class B)
● Realization : class B realizes Class A (or interface
A is realized by class B)

36. Dependency
Dependency is represented when a reference to one class is passed in as a method
parameter to another class or a local variable of another class is created in a member
function. For example, an instance of class B is passed in to a method of class A:
● public class A {
public void doSomething(B b) {
.......
}
● public class A{
public void doSomething(){
B b = new B();
.........
}

37. Aggregation
If class A stored the reference to class B for later use we
would have a different relationship called Aggregation. A
common and obvious example of Aggregation would be
via setter injection:
● public class A {
private B _b;
public void setB(B b) { _b = b; }

38. Composition
● Aggregation is the weaker form of object
containment (one object contains other
objects). The stronger form is called
Composition. In Composition the containing
object is responsible for the creation and life
cycle of the contained object (either directly or
indirectly)
● In the next three slides you will see the
example of composition

39. Composition – via member
initialization
● public class A {
private B _b = new B();

40. Composition - via constructor
initialization
● public class A {
private B _b;
public A() {
_b = new B();
} // default constructor

41. Composition – via lazy initialization
public class A {
private B _b;
public void doSomethingUniqueToB() {
if (null == _b) {
_b = new B();
}
return _b.doSomething();
} // doSomethingUniqueToB()

42. Inheritance
public class A {
...
} // class A
public class B extends A {
....
} // class B

43. Realization
public interface A {
...
} // interface A
public class B implements A {
...
} // class B

44. Case Study – Restaurant System
Find out the nouns from the Use Case Analysis.
These are likely to be major classes.
First the classes for the major Actors
● Customer
● Receptionist
● Waiter
● Cashier

45. Case Study – Restaurant System

56. Refactoring – Introducing Employee
Class

58. Sequence Diagram

59. ● UML Specifies a number of interaction
diagrams to model dynamic aspects of the
system
● Dynamic aspects of the system
– Messages moving among objects of classes
– Flow of control among objects
– Sequences of events

60. Dynamic Diagram
The most important dynamic diagrams are -
● Interaction Diagrams - Set of objects or roles and
the messages that can be passed among them
– Sequence Diagrams - emphasize time ordering
– Communication Diagrams - emphasize structural
ordering
● State Diagrams - State machine consisting of
states, transitions, events and activities of an object

61. Sequence Diagram
● Describe the flow of messages, events, actions
between objects
● Show concurrent processes and activations
● Show time sequences that are not easily
depicted in other diagrams
● Typically used during analysis and design to
document and understand the logical flow of
your system

63. Participating Objects
● Squares with object type, optionally preceded
by object name and colon
● Object's "life line" represented by dashed
vertical line
● Message (method call) indicated by horizontal
arrow to other object

64. Messages
● Messages are (method call) indicated by
horizontal arrow to other object
● Dashed arrow back indicates return (optional)
● Different arrowheads for normal / concurrent
(asynchronous) methods

65. Lifetime of Objects
● Creation: arrow with 'new/create' written above
it
– notice that an object created after the start of
the scenario appears lower than the others
● Deletion: an X at bottom of object's lifeline
– Java doesn't explicitly delete objects; they fall
out of scope and are garbage-collected