Optimization and Simulation Document No.

Laboratory

Form No.
Article 3rd Module
Effectively Apply

Module Name Use Case and Activity Diagram

Lab work Logistics Information System and Database Design Application

Development

Program Learning PLO 6. Able to design integrated system according to technical

standard, applicable safety and environmental health and
Outcomes
considering performance and reliability aspect, ease of
implementation and sustainability, and concentrate on economic,
social, and cultural aspect

Course Learning CLO 5. Able to model and design business process and database

Outcome design in an integrated system

1. Unified Modelling Language (UML)

UML (Unified Modelling Language) is a general-purpose, developmental modelling

language in the field of software engineering that is intended to provide a standard way to
visualize the design of a system. This is also a modelling language for systems or software
with an 'object-oriented' paradigm, a set of integrated diagrams, which was developed to
help system and software developers’ complete specifications, visualization, architectural
design, construction, simulation and testing, and documentation. The Purpose of Using
UML is to:
a. Provide a modelling language that is independent of various programming
languages and engineering processes.
b. Provide ready-to-use models, an expressive visual modelling language for
developing and exchanging models in an easy and generally understandable
manner.
 c. Integrate best practices contained in modelling.

UML serves as a (blueprint) blueprint because it is very complete and detailed. With this
blueprint it will be possible to know detailed information about program coding or even
read the program and reinterpret it in the form of a diagram (reserve engineering). The
nine types of diagrams in UML that can be used in this module are 2:

a) Use Case Diagrams

A use case diagram was proposed by Ivar Jacobson by 1986. Use Case diagrams
state the visualization of interactions that occur between users (actors) and the
system. This diagram is a good picture to explain the context of a system so that
the boundaries of the system are clearly visible (Larman, 2005). There are 2
important elements that must be described, namely actors and UC. Actor is
anything that interacts directly with the system, can be a person (which is indicated
by his role and not his name/personnel) or other computer systems. Actors are
denoted by a stickman symbol with a noun name at the bottom that represents the
role/system. Actors can be primary, which initiates the running of a UC, or
secondary, which helps run a UC. Use cases allow you to understand and
communicate the purpose of a system or its components. A use case diagram is a
UML model that is used to graphically show a use case and its relationship to the
user (Sat zinger et al., 2011). Use Case diagrams are usually developed in the early
stages of development and people often apply use case modelling for several
purposes:
- Define system context.

- Capture system requirements.

- Validation of system architecture.

- Drive implementation and generate test cases.

The symbols of use case diagram area as follows.

Symbol Description

Actor

Someone interacts with use case (system function)

that has a responsibility toward the system (inputs)
and has expectation from the system (outputs)

Use Case

Description that represents the system’s functions.

Association

The participation of an actor in use case is shown by

connecting an actor to a use case by a solid link. Actors
may be connected to use cases by associations,
indicating that the actor and the use case communicate
with one another using messages.
Generalization

Generalization is a parent-child relationship in use

case, where one of them is in a more general form the
other. The child use case is connected to the parent use
case.
 Include

Include is the relationship between use cases when a

use case is depicted as using the functionality of
another use case. An additional use case relation to a
use case where an added use case requires this use case
to carry out its functions or as a condition for running
this use case. A use case includes the functionality
described in another use case as a part of its business
process flow.
Extend

Extend described the relationship between use cases,

where a use case is another use case is another use case
functionality if certain conditions are met. An
additional use case relation to a use case where the
added use case can stand alone even without the
additional use case.

b) Activity Diagrams

Activity diagrams describe various activity flow in the system being designed, how
each one the flow begins, the decision that may happen and how they ended.
Activity diagrams can also be described parallel processes what might happen to
multiple executions. Activity diagram is one of behavioural diagram in UML
diagram that described dynamic aspects of the system. The activity diagram is very
useful when you want to illustrate work flowing through a business process. You
can also document complex use cases with what is known as an interaction
overview diagram. Activity diagram is essentially an advanced version of flow
chart that modelling the flow from one activity to another activity. Activity
diagrams describe how activities are coordinated to provide a service which can be
at different levels of abstraction. An activity diagram resembles a horizontal
flowchart that shows the action and events as they occur. Activity diagrams show
the order in which the action take place and identify the outcomes (Shelly and
Rosenblatt., 2012). The symbols of activity diagram area as follows.
Symbol Description

Initial State

Initial state is portraying the beginning of a set of actions

or activities.

Activity Final State

Activity final state is portraying the end or stop all control

flows in a set of actions or activities.
Activity

Activity is used to represent a set of actions.

Decision

Decision represents a test condition to ensure that the

control flow or object flow only goes down one path.

Fork Node

Fork node used to split behaviour into a set of parallel or

concurrent flows of activities/actions.

Join Node

Join node combine two parallel activities/actions into one

activity/action or bring back together a set of parallel or
concurrent flows of activities/action.
 Swimlane

Swimlane is a way to group activities performed by the

same actor on an activity diagram or to group activities in
a single thread.

Control Flow & Object Flow

Control flow shows the sequence of execution. Object

flow shows the flow of an object from one activity/action
to another activity/action.

2. Study Case Example

You are one of the IT Developer Staff at the FRI company. This company engaged in logistics
or delivery of goods. One day, your manager wants an information system that can manage
transactions and make deliveries online. The following is the order of all the activities:

1. Admin does open the website: The system will display the Logistics Page.
2. Admin chooses a login: the system will display the login page. Admin needs to fill the
username and password. If the password is correct, the system will display the main
menu page, but if the password is wrong, the system will display an error login
notification and return to the login page.
 REFERENCES

Wati Embun F, Kusumo Anggoro A. (2016). Penerapan Metode Unified Modeling

Language (UML) Berbasis Desktop Pada Sistem Pengolahan Kas Kecil Studi Kasus
Pada PT Indo Mada Yasa Tangerang. Vol. 5 No. 1, 24-36

Kurniawan Tri.A. (2017) Pemodelan Use Case (UML): Evaluasi Terhadap Beberapa Kesalahan
Dalam Praktik. Vol.5, No. 1, hlm. 77-86

Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modeling Language User Guide.
California: Addison Wesley Longman Publishing Co., Inc.
Chonoles, M. J., & Schardt, J. A. (2003). UML 2 for Dummies. For Dummies.

Satzinger, J., Jackson, R., & Burd, S. (2011). Systems Analysis and Design in a Changing
Worlf (6th Ed). Boston: Cengage Learning.
Shelly, G., & Rosenblatt, H. (2012). Essentials of Systems Analysis and Design 9th Ed.
Boston: Cengage Learning

Keith, J.; Kohlamn, R. (2006) Majik Consulting white paper series ABN 87 007 192 109