Romi Satria Wahono

 Lahir di Madiun, 2 Oktober 1974

 SD Sompok Semarang (1987)
 SMPN 8 Semarang (1990)
 SMA Taruna Nusantara, Magelang (1993)
 S1, S2 dan S3 (on-leave)
Department of Computer Sciences
Saitama University, Japan (1994-2004)
 Core Competence: Software Engineering,
Computational Intelligence
 Founder dan Koordinator IlmuKomputer.Com
 CEO PT Brainmatics Cipta Informatika
The Unified Modelling
Language (UML)
What is the UML?
 UML: Unified Modeling Language
 UML can be used for modeling all processes
in the development life cycle and across
different implementation technologies
(technology and language independent)
 UML is the standard language for
visualizing, specifying, constructing, and
documenting the artifacts of a software-
intensive system
What is the UML?
 UML is an object-oriented modeling language
• semi-formal (UML 2.0 added much more formality)
• process independent
UML can be used with a variety software development process models
• customizable and extensible
• model structure (static) and behavioral (dynamic)
aspects of a system
 UML is a communication tool – for the team, and
other stakeholders
• A standard way to create a visual model
Sejarah UML

 In the 90s many people Booch, Jacobson, Rumbaugh

creating OO diagramming languages
 Three different ones created by Grady Booch,
Ivar Jacobson, James Rumbaugh
 Joined forces with
Rational (company) to
create Unified Modeling
Langauge (UML)
Sejarah UML
2003  UML 2.0
Why Modeling?
Modeling captures essential parts of the system
(James Rumbaugh)

Business Process Computer System

Visual Modeling is modeling using

standard graphical notations
Modeling Captures Business Process
Use Case Analysis is a technique to
capture business process from user’s
perspective
The Triangle of Success

Notation:
Standard

Process: Tools:
Support
Client-
Standard and
Oriented
Process
UML Notation (Diagrams)
Use-Case
Diagram Statechart
Class Diagram Diagram add f ile

DocumentList

Use Case 1 FileMgr Document

add( )
Actor A Actor B fetchDoc( ) delete( )
name : int
docid : int
sortByName( ) numField : int Writing
add f ile [ numberOf file==MAX ] /
f lag OFF
get( )
open( ) read() fill the
Use Case 2 close( ) code..
Openning
FileList read( )
sortFileList( )
fList create( )
fillDocument( ) close f ile
add( )
delete( )
1

Use Case 3 Reading

close f ile
Closing

rep

Deployment
File
Repository

(from Persistence) GrpFile

read( )
name : char * = 0

read( )
readDoc( )
open( )
readFile( )

Diagram
create( )
fillFile( )

Collaboration 9: sortByName ( )
Repository DocumentList

Diagram 1: Doc view request ( )

mainWnd : MainWnd
L

2: fetchDoc( )
FileManager
Window95

¹®¼°ü¸®
Windows95

Windows95

Document
Ŭ¶óÀ̾ðÆ®.EXE

4: create ( ) gFile : GrpFile ¹®¼°ü¸® ¾ÖÇø´

8: fillFile ( ) Windows
NT

user : Clerk Solaris

fileMgr : FileMgr ¹®¼°ü¸® ¿£Áø.EXE

3: create ( ) GraphicFile Alpha

UNIX
ÀÀ¿ë¼¹ö.EXE
6: fillDocument ( )
File FileList
Windows
NT

IBM

7: readFile ( ) Mainframe

5: readDoc ( )
document : Document
repository : Repository
µ¥ÀÌŸº£À̽º¼¹ö

mainWnd fileMgr :
FileMgr
document :
Document
gFile repository
Component
Diagram
user

Target
ƯÁ¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view request ( )
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.

2: fetchDoc( )

3: create ( )

4: create ( )

System
5: readDoc ( )

ÈÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocument ( )

¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.

7: readFile ( )

Forward and
8: fillFile ( )

È¸é °´Ã¼´Â ÀоîµéÀÎ 9: sortByName ( )

°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡
º¸¿©ÁØ´Ù.

Sequence Reverse
Diagram Engineering
UML Tools
 Rational Rose
 Visual Paradigm
 Enterprise Architect
 Microsoft Visio
 Star UML
 Netbeans UML Plugin
UML 2.0
UML version 2.0 has 14 diagrams in 2
major groups:
1. Structure Diagrams
2. Behavior Diagrams
UML 2.0 Diagram
UML Structure Diagrams
Represent the data and static
relationships in an information system
1. Class Diagram
2. Object Diagram
3. Package Diagram
4. Deployment Diagram
5. Component Diagram
6. Composite Structure Diagram
Structure Diagrams
1. Class Diagrams
• Common vocabulary used by analyst and users
• Represent things (employee, paycheck,…)
• Shows the relationships between classes
2. Object Diagrams
• Similar to class diagrams
• Instantiation of a class diagram
• Relationships between objects
3. Package Diagrams
• Group UML elements together to form higher level
constructs
Structure Diagrams
4. Deployment Diagrams
• Shows the physical architecture and software
components of system
• For example, network nodes
5. Component Diagrams
• Physical relationships among software components
• Example – Client/Server (Which machines run which
software)
6. Composite Structure
• Illustrates internal structure of a complex class
UML Behavior Diagrams
Depict the dynamic relationships among the
instances or objects that represent the
business information system
1. Activity Diagram 5. Timing Diagram
2. Sequence Diagram 6. Behavior State
3. Communication Machine
Diagram 7. Protocol State
4. Interaction Overview Machine
Diagram 8. Use Case Diagrams
Behavior Diagrams
1. Activity Diagrams
• Model processes in an information system
• Example: Business workflows, business logic
2. Interaction Diagrams
• Shows interaction among objects
3. Sequence Diagrams – Time
• Time-based ordering of the interaction
4. Communication Diagrams – Messages
• Communication among a set of collaborating objects of
an activity
Behavior Diagrams
4. Interaction Overview Diagrams
• Overview of flow of control of a process
5. Timing Diagrams
• Show how an object changes over time
6. State Machines
• Examines behavior of one class
• Models the different states and state transitions an
object can experience
7. Use-Case Diagrams
• Shows interaction between the system and
environment
• Captures business requirements
UML Problems
 UML is modeling notation, it is not a
development process or a methodology
• UML driven development process?

 UML is too complex, difficult to understand

quickly
• Should we use all UML diagrams?
UML Driven Process
1. Model the organization business process with
activity diagrams or business process modeling
notation (BPMN)
2. Display the boundary of a system & its major
functions using use case diagram
3. Illustrate use case realizations with interaction
diagrams (sequence diagram and activity diagrams)
4. Represent a static structure of a system using
class and component diagram
5. Reveal the physical implementation architecture
with deployment diagrams
UML Driven Process (Simplified)

1. Activity Diagram (Business Process)

2. Use Cases Diagram
3. Sequence Diagram
4. Activity Diagram
5. Class Diagram
6. Component Diagram
7. Deployment Diagram
Business Process Modeling
with Activity Diagrams
BPM With Activity Diagrams
 A number of activities support a business
process across several departments
 Activity diagrams model the behavior in a
business process
Actions and Activities
 Performed for a specific business reason
 Names begin with a verb and end with a
noun
• “Make Appointment”
 Each activity normally associated with a use
case
Object Nodes
 Activity and Actions usually modify objects
 Object nodes model these objects
 Objects represent a flow of information from
between activities or actions
Control & Object Flows
 Control Flows (solid line)
• Paths of execution through the business process
• Can only be attached to actions or activities
 Object Flows (dashed line)
• Model the flow of objects through a business process
• Show actual objects entering and exiting the system
• An object is on one end, an action or activity is on the
other end
Control Nodes
1. Initial – Only one, at top left
2. Final Activity – Stop the process
3. Final Flow – Stop this flow only
4. Decision – Guarded test conditions
5. Merge – Following decisions
6. Fork – Split parallel execution
7. Join – Join parallel execution
Activity Diagram (Business Process)
act Activ ity Diagram

Mulai

Memasukkan Kartu

kartu valid? [tidak]

[ya]

Memasukkan PIN

PIN benar? [tidak]

[ya]

Menampilkan Menu Utama

lakukan transaksi? [tidak]

[ya]

Melihat Saldo Mengambil Uang Mengirim Uang Melakukan Logout

Mengeluarkan Kartu

Mengeluarkan Kuitansi

Selesai
Swimlanes
 The business process may be broken into
persons of responsibility
 Identify this with swimlanes
Activity Diagram (Business Process)
Use Case Diagram
Use Case Diagram
 Map a Use Case Diagram to the Business Process Model
to define exactly what functionality you are intending to
provide from the business user perspective
 As each Use Case is added, create a traceable link from
the appropriate business processes to the Use Case
 This mapping clearly states what functionality the new
system will provide to meet the business requirements
outlined in the process model
 Use Case Diagram define what user (Actor) do to the
system (System Functionality
 Output:
 Use Case Diagram
Use Case
 A formal way of representing how a
business interacts with its environment
 The discrete activities performed by
the user
 Use cases are logical models that
describe the activities of a system
 Used to document the As-Is system, or
to develop the To-Be system
How Are Use-Cases Created?
 Each Use Case describes one and only
one function
 But may have several paths that the
user can take to accomplish that single
function
Types of Use-Cases Overview vs. Detail

 Overview
• High level overview of requirements
• Allows users and analysts to agree
on major requirements
• Created early, documents only basic info
Name, ID, primary actor, type, brief description
 Detail – Once user & analyst agree
• Documents all information needed for the Use
Case
Types of Use-Cases Essential vs. Real

 Essential
• Describes only essential issues needed to
understand the required functionality
• e.g. "make appt"
 Real
• Goes further and describes a specific set of
steps
• e.g. "make entry into outlook database
Steps to Create a Use Case
1. Understand the business process
model (UML AD or BPMN)
2. Prepare Use Case Diagrams for each
Use Case
3. Prepare Use Case Descriptions for
each Use Case
Use Case Diagrams

 Summarized into a single picture

 All of the use cases for the part of the
system being modeled
 Use Case Diagram tells what the
system will do
 Good for communicating with users
Use Case Diagram Syntax
 Actor
• person or system that derives benefit
from and is external to the subject
 Use Case
• Represents a major piece of system
functionality
 Association Relationship
 Include Relationship <<includes>>

 Extend Relationship <<extends>>

 Generalization Relationship
Use Case
 A major piece of
system functionality
 Can extend other Use Case
Use Cases
 Placed inside system boundary
 Labeled with descriptive
verb-noun phrase
System Boundary
 Includes the name
of the system
inside or on top Boundary
 Represents the
scope of the system
 Actors are outside the scope of the system
Actor
 A person or another
system that interacts
with the current system
 A role, not a specific user
 Provides input, actor
receives output, or both Actor/Role
Association Relationship

 Links actor and the Use Case

 Shows two-way communication
•If one-way, arrows are used
 * is for "multiplicity of the Association"

* *
Extends Relationship
 Extends Use Case to include Optional
behavior
 Arrow points from the extension Use Case
to the base Use Case

extend

Select Payment extend Make

Method Appointment
Include Relationship
 Include one Use Case from within
another
 Arrow points from base Use Case to
the included Use Case

include

include Make
Buy Receipts
Payment
Generalization Relationship
 A specialized Use Case to a more
generalized Use Case
 Arrow points from specialized to
general Use Case

Make Old Make

Appointment Appointment
Use Case Diagram for
Appointment System
Use Case Diagram with
Specialized Actor
Sample Use Case
Extend and Include Relationships
Use Case Diagram
uc Use Case Model

Sistem ATM

Memasukkan Kartu Memasukkan PIN

«include»

Melihat Saldo

Pengguna Mengirim Uang

Mengambil Uang
Melakukan Logout
Use Case Description
What are Use-Case Descriptions?
 Describe basic functions of the system
using words
1. What the user can do
2. How the system responds
Elements of a Use-Case Description
 Contains all information needed to explain
Use Case diagrams, and expresses it less
formally
 Three basic parts:
1. Overview information
2. Relationships
3. Flow of events
Elements of a Use-Case Description

Use Case Name: ID: Importance Level:

Primary Actor: Use Case Type:

Stakeholders and Interests:

Brief Description:

Trigger:

Relationships: (Association, Include, Extend, Generalization)

Normal Flow of Events:

Subflows:

Alternate/Exceptional Flows:
Overview Information
 Use Case Name
• verb-noun phrase (Make Appt)
 Use Case ID Number
• Allows specific reference
 Importance level
• Can be fuzzy or based on detailed analysis
 Primary Actor
• Normally the trigger
Overview Information

 Use Case Type

• Overview, detail, essential, or real
 Stakeholders and interests
• Always includes the primary actor
 Brief Description
• One sentence captures the essence
 Trigger
• Event that causes Use Case to begin
Relationships
 Explains relationship of Use Case to:
• Other Use Cases
• Users
 Four type of relationships
1. Association
2. Extend
3. Include
4. Generalization
Association Relationship

 Documents the communication between

the use case and the actors
 All actors are documented with the
association relationship
Extend Relationship

 The extension of the functionality to handle

optional behavior
• Make Appointment  Create New Patient
• If patient doesn’t exist in database, need to create new
patient
Include Relationship
 Represents mandatory inclusion of another Use
Case
 Enable functional decomposition
• Make Appointment  Make Payment Arrangements
• Make payment arrangements is complex enough to be a
separate use case
Generalization Relationship

 Allows use of Inheritance

 Gathers the common behavior is together
 Example:
• Make new Patient Appointment
• Make old Patient Appointment
• Both derived from Make Appointment
Flow of Events
 Describes the individual steps in the
business process
 Three type of flows:
1. Normal flow of events
2. Sub-Flows
3. Exceptional flows
Normal Flow of Events
 Includes only steps normally executed
 Listed in the order that they are performed
Sub-Flows
 Normal flow of events are decomposed into
sub-flows
 Try to keep normal flow simple and
understandable
 Can list each sub-flow as part of the Use
Case
 If it make sense, can convert a sub-flow into
its own Use Case
Exceptional Flows
 Flows that are anticipated, but not
considered normal
Guidelines for Creating
Use-Case Descriptions
 Write each step in “SVDPI” form
• Subject-Verb-Direct Object, Preposition, Indirect Object
• "The Patient contacts the office regarding an
appointment"
• Allows easier identification of classes
 Clarify initiator and receivers of action
 Write from independent observer POV
 Write at same level of abstraction
Guidelines for Creating
Use-Case Descriptions
 Ensure a sensible set of actions
 The use case represents a transaction
• Primary actor initiates action
• System validates request
• System processes request (changes state)
• System sends result to primary actor
 KISS – decompose if necessary
 Use plain language to indicate repetition
Activity Diagram
Activity Diagram
 Berbeda dengan Activity Diagram Business
Process (Global Activity Diagram), Activity
Diagram juga perlu dibuat untuk memperjelas
Sequence Diagram
 Activity Diagram dibuat secara detail
menjelaskan alur berjalannya Use Case
(algoritma program) secara detail
 Seperti juga pada Sequence Diagram, Activity
Diagram dibuat untuk tiap Use Case
Sequence Diagram
 Illustrate the objects that participate in a use case
 Show the messages that pass between objects for
a particular use-case over time
 From the inputs and outputs of the Business
Process Model and the details of the Use Case
Diagram, begin to construct the sequence diagram
 Output:
 Sequence Diagram
 Activity Diagram (Detail)
Sequence Diagram Syntax

AN ACTOR

AN OBJECT
anObject:aClass

A LIFELINE

A FOCUS OF CONTROL

A MESSAGE
aMessage()

OBJECT DESTRUCTION x
Example Sequence Diagram for
Make Appointment Use Case
BCE Pattern on Sequence Diagram
 Pembuatan object pada lifeline di sequence diagram
bisa berbeda-beda (subyektif)
 Boundary-Control-Entity (BCE) pattern membantu
standarisasi object pada lifeline:
1. Boundary Class:
- Class yang berinteraksi dengan aktor langsung (user
interface)
- Bisa berbentuk form, input, menu, dsb.
2. Control Class:
- Class yang berhubungan dengan pemrosesan,
penghitungan, kalkulasi, komputasi, query, dsb
3. Entity Class:
- Class yang berhubungan dengan data baik flatfile atau
database
 Sequence Diagram: Mengirim Uang
eraction

Pengguna
MenuUtama MenuMengirimUang PemrosesanPengirimanUang Account

memilihMengirimUang()

tampilkaMenuMengirimUang()

memasukkanAccountTujuan()

memasukkanJumlah()

kirimUang(accountTujuan, jumlah)

getAccount(accountTujuan)

getSaldo(id)

isSaldoCukup()
tampilkanHasilPengirimanUang()
 Sequence
Interaction
Diagram: Memasukkan Kartu

Pengguna
KotakKartu PemrosesanValidasiKartu MenuLogin

memasukkanKartu()

validasiKartu()

isKartuValid()

tampilkanMenuLogin()
 Sequence Diagram: Memasukkan PIN
nteraction

Pengguna
MenuLogin PemrosesanValidasiAccount Account MenuUtama

memasukkanPIN()

validasiAccount()

getAccount(id, PIN)

tampilkanMenuUtama()
 Sequence Diagram: Mengirim Uang
eraction

Pengguna
MenuUtama MenuMengirimUang PemrosesanPengirimanUang Account

memilihMengirimUang()

tampilkaMenuMengirimUang()

memasukkanAccountTujuan()

memasukkanJumlah()

kirimUang(accountTujuan, jumlah)

getAccount(accountTujuan)

getSaldo(id)

isSaldoCukup()
tampilkanHasilPengirimanUang()
 Sequence Diagram: Melihat Saldo
nteraction

Pengguna
MenuUtama PemrosesanLihatSaldo Account MenuMelihatSaldo

memilihMelihatSaldo()

lihatSaldo(id)

getSaldo(id)

tampilkanHasilMelihatSaldo()
 Sequence Diagram: Mengambil Uang
nteraction

Pengguna
MenuUtama MenuMengambilUang PemrosesanPengambilanUang Account KotakUang

memilihMengambilUang()

tampilkanMenuMengambilUang()

memasukkanJumlahUang()

ambilUang(id, jumlah)

getAccount(id)

getSaldo(id)

isSaldoCukup()
keluarkanUang(jumlah)

tampilkanHasilPengambilanUang()
 Sequence
nteraction
Diagram: Melakukan Logout

Pengguna
MenuUtama PemrosesanLogout KotakKuitansi KotakKartu

memilihMelakukanLogout()

lakukanLogout()

keluarkanKuitansi()

keluarkanKartu()
Class Diagram
 From the object-lifeline of sequence diagram and the
user interface model create the Class Model
 This is a precise specification of the objects in the
system, their data or attributes (variables) and their
behavior or operations (methods)
 Sequence diagram messages will typically map to class
operations (method)
 Class diagrams may be broken into discrete packages
and components (collection of classes)
 Output:
 Class Diagram
 Component (Package) Diagram
Class Diagrams
 Static model
 Shows
• Classes
• Relationships among classes
• Remains constant over time
Example Class Diagram
More on Attributes

 Derived attributes
• /age, for example can be calculated from birth
date and current date
 Visibility of attributes
• +Public: not hidden from any object
• #Protected: hidden from all but immediate
subclasses
• –Private: hidden from all other classes
 Default is private
More on Operations

 Constructor: creates object

 Query: see class state
 Update: change attribute values
 Operations can also be
public, protected, or private
• Default for operations is public
More on Relationships
 A primary purpose of class diagrams is
to show relationships, or associations,
between classes
 Class can be related to itself (role)
• Use a "+" sign to show it's a role and not the
name of a relationship
Relationship Multiplicity

Exactly one
Dept 1 Boss

Zero or more
Employee 0..* Child

One or more
Boss 1..* Employee

Zero or one
Employee 0..1 Spouse

Specified
range Employee 2..4 Vacation

Disjoint
Employee 1..3, 5 Committee
ranges
 Class Diagram (Sistem ATM)
class Class Model

ProsesValidasiKartu FormLogin ProsesValidasiAccount

melakukan
mengakses
Account

melakukan
mengakses
ProsesPengirimanUang
KotakKartu MenuKirimUang
mewarisi melakukan

mengakses
mewarisi
melakukan
memiliki Layar
MenuUtama
mewarisi mengakses
memiliki melakukan ProsesPengecekanSaldo
SistemATM

melakukan
melakukan
memiliki
PemrosesanLogout
mewarisi
memiliki
KotakUang ProsesPengambilanUang

KotakKuitansi

MenuPengambilanUang melakukan
ER Diagram
 From the entity class pattern of sequence
diagram, begin to construct Entity Relationship
(ER) Diagram
 ER diagram (database structure) can be
produced from the entity class of the class
diagrams
 Output:
 ER Diagram
ER Diagram
Deployment Diagram
 The Deployment model defines the physical
architecture of the system
 This work can be begun early to capture the
physical deployment characteristics
• What hardware, operating systems, network capabilities,
interfaces and support software will make up the new
system
• Where it will be deployed
• What parameters apply to disaster recovery, reliability,
back-ups and support
 Output:
• Deployment Diagram
Deployment Diagram Components
 Nodes
• Any piece of hardware in the model
• A computational resource
• Labeled by its name
• Stereotype to label the type of node

 Artifacts
• Piece of the information system
Such as software or a database table
Deployment Diagram Components

 Node with Deployment Artifact

• Shows artifact placed on a physical node
• Good for showing distribution data or
software

 Communication paths
• Links between nodes of the network
Deployment Diagram Example
Deployment Diagram
Component Diagram
Tugas
 Lakukan pengembangan software dengan mengikuti 10 proses
pengembangan software, untuk studi kasus di bawah:
1. Aplikasi Koperasi Simpan-Pinjam 6. Aplikasi Recruitment Karyawan
2. Aplikasi Penerimaan Mhs Baru 7. Aplikasi Pengolahan Nilai
3. Aplikasi Perpustakaan 8. Aplikasi Pemesanan Tiket Kereta
4. Aplikasi Stock Barang ATK 9. Aplikasi Sisfo Skripsi
5. Aplikasi Presensi-Absensi 0. Aplikasi Penjualan Obat di Apotik

 Pilih software berdasar digit terakhir dari NIM

Referensi (Process)
 Alan Dennis et al, Systems Analysis and Design with UML
– 3rd Edition, John Wiley and Sons, 2010
 Dan Pilone and Russ Miles, Head First Software
Development, O’Reilly Media, 2008
 Barclay and Savage, Object-Oriented Design with UML
and Java, Elsevier, 2004
 Paul Kimmel, UML Demystified, McGraw-Hill, 2005
 Kim Hamilton and Russell Miles, Learning UML 2.0,
O'Reilly, 2006
 Howard Podeswa, UML for the IT Business Analyst,
Course Technology, 2009
 Deloitte, Business Process Modeling – Basic Guideline and
Tips, 2008