MODUL MATAKULIAH

PEMODELAN SISTEM
Unified Modeling Language (UML)

Dosen Pengampu

EDY NASRI. S.Kom, M.Kom

UNIVERSITAS BANTEN JAYA

FAKULTAS ILMU KOMPUTER
 PENDAHULUAN
Pertemuan-1

The Unified Modeling Language (UML) is the

standard modeling language for software and systems
development. (russ miles & kim hamilton)

UML adalah bahasa untuk menspesifikasi, memvisualiasi,

membangun dan mendokumentasikan artifacts (bagian dari
informasi yang digunakan atau dihasilkan oleh proses
pembuatan perangkat lunak, artifact tersebut dapat berupa
model, deskripsi atau perangkat lunak) dari sistem
perangkat lunak, seperti pada pemodelan bisnis dan sistem
non perangkat lunak lainnya [HAN98].
anas©2015

Unified Modelling Language (UML) adalah sebuah

"bahasa" yg telah menjadi standar dalam industri untuk
memvisualisasi, merancang dan mendokumentasikan sistem
piranti lunak.

UML dibuat oleh Grady Booch, James Rumbaugh, dan Ivan

Jacobson dibawah bendera Rational Software Corp [Han98].
anas©2015

Objective (Tujuan) :

1. Mengetahi Konsep Object Oriented

2. Mengenal konsep dan bagian-bagian UML
3. Pengembangan piranti lunak dapat memenuhi semua kebutuhan
pengguna dengan lengkap dan tepat, termasuk faktor-faktor :
Scalability, Robustness, Security dst.
anas©2015
SEJARAH UML

UML (Unified Modeling Language) merupakan pengganti

dari metode analisis berorientasi object dan design
berorientasi object (OOA&D) yang dimunculkan sekitar
akhir tahun 80-an dan awal tahun 90-an.
Sampai dengan tahun 1990 metodologi pemodelan
berorientasi objek telah bermunculan di dunia. Diantaranya
adalah: metodologi booch [1], metodologi coad [2],
metodologi OOSE [3], metodologi OMT [4], metodologi
shlaer-mellor [5], metodologi wirfs-brock [6], dsb.
UML dimulai secara resmi pada oktober 1994, ketika
Rumbaugh bergabung dengan Booch pada Relational
Software Corporation. Proyek ini memfokuskan pada
penyatuan metode Booch dan OMT.
anas©2015

UML versi 0.8 merupakan metode penyatuan yang dirilis

pada bulan Oktober 1995. Dalam waktu yang sama,
Jacobson bergabung dengan Relational dan cakupan dari
UML semakin luas sampai diluar perusahaan OOSE.
Dokumentasi UML versi 0.9 akhirnya dirilis pada bulan
Juni 1996.
anas©2015

UML 1.0 ditawarkan menjadi standarisasi dari Object Management

Group (OMG). Dan pada Januari 1997 dijadikan sebagai standar
bahasa pemodelan.

Antara Januari–Juli 1997 gabungan group tersebut memperluas

kontribusinya sebagai hasil respon dari OMG dengan memasukkan
Adersen Consulting, Ericsson, Object Time Limeted, Platinum
Technology, Ptech, Reich Technologies, Softeam, Sterling Software dan
Taskon. Revisi dari versi UML (versi 1.1)

Di sini beberapa partner yang berkontribusi pada UML 1.0,

diantaranya Digital Equipment Corporation, Hewlett-Packard, I-Logix,
Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft,
Oracle, Relational, Texas Instruments dan Unisys.
anas©2015

Booch, Jacobson, Rumbaugh 2013  UML 2.5

Th 1994. Munculnya tokoh pelopor (Booch,Rumbough dan Jacobson)

Th 1995. Direlease draft pertama UML (versi 0.8)
Th 1996. Pengkoordinasian oleh Object Management Group (OMG)
Th 1997. Munculnya UML (versi 1.1)
Th 1999. Penyusunan 3 buku UML oleh (Booch,Rumbough dan Jacobson).
Th 1999. UML menjadi standart bahasa permodelan berorientasi objek
Th 2003. Direlease UML versi 1.5
Th 2004 direlease UML Versi 2.0
anas©2015
Analysis Design Paradigm and Diagrams

1. Data-oriented  DFD
2. Process-oriented  Flowchart
3. Object-oriented (data + process)  UML
anas©2015
Konsep Dasar Pemrograman
Berorientasi Objek

Class , Object, Method, Attribute

 Berorientasi Objek?
Attribute: Contoh Implentasi
Topi, Baju, Jaket, Pemrogramaan dengan PHP
Tas Punggung,
Tangan, Kaki, Mata

Behavior:
Cara Jalan ke Depan
Cara Jalan Mundur
Cara Belok ke Kiri
Cara Memanjat
en
anas©2015

 Berorientasi Objek?
Attribute (State):
Ban, Stir, Pedal Rem, Pedal Gas,
Warna, Tahun Produksi
Behavior:
Cara Menghidupkan Mesin
Cara Manjalankan Mobil
Cara Memundurkan Mobil

Attribute  Variable(Member)
Behavior  Method(Fungsi)
anas©2015 Segitiga Sukses Dalam
Pengembangan Software

Notation:
Standard

Process:
Tools: Support
Customer-
Standard and
Oriented
Process
Methodology
anas©2015
UML Tools

• Rational Rose
• Visual Paradigm
• Enterprise Architect
• Microsoft Visio
• Star UML
• Netbeans UML Plugin
anas©2015
UML 2.0 Diagrams

UML versi 2.0 memiliki 14 diagram dibagi 2 kelompok

utama:
1. Structure Diagrams
2. Behavior Diagrams
anas©2015
UML Structure Diagrams

Mewakili data dan hubungan statis dalam suatu sistem

informasi :

1. Class Diagram
2. Object Diagram
3. Package Diagram
4. Deployment Diagram
5. Component Diagram
6. Composite Structure Diagram
anas©2015
Structure Diagrams
1. Class Diagrams
 Common vocabulary (Kosa kata
umum) yang digunakan oleh analis dan
pengguna
 Mewakili hal-hal (misal: karyawan,

gaji, ...)
 Menunjukkan hubungan antara kelas

2. Object Diagrams
 Mempunyai kemiripan dengan class

diagrams
 Instansiasi dari class diagram

 Hubungan antara obyeks

anas©2015
Structure Diagrams
3. Package Diagrams
 Kelompok Elemen UML bersama
untuk membentuk tingkat
konstruksi yang lebih tinggi

4. Deployment Diagrams Package

 Menunjukkan arsitektur dan
komponen software fisik dari
sistem
 contoh, node jaringan Deployment

5. Component Diagrams
 Hubungan fisik antar komponen
perangkat lunak
 contoh – Client / Server (mesin
yang menjalankan software )

Component
anas©2015
Structure Diagrams

6. Composite Structure
 Menggambarkan struktur internal dari kelas
yang kompleks

class

part port

interfaces
anas©2015
UML Behavior Diagrams

1. Activity Diagram 5. Timing Diagram

2. Sequence Diagram 6. Behavior State Machine
3. Communication 7. Protocol State Machine
Diagram 8. Use Case Diagrams
4. Interaction Diagram
anas©2015
Behavior Diagrams

1. Activity Diagrams
 Proses model dalam sistem informasi
 Contoh: alur kerja bisnis, logika bisnis
2. Interaction Diagrams
 Menunjukkan interaksi antara objek-objek
3. Sequence Diagrams
 Pemesanan berbasis waktu interaksi
4. Communication Diagrams
 Komunikasi di antara satu set berkolaborasi objek dari suatu
kegiatan
anas©2015
Behavior Diagrams
5. Interaction Diagrams
 Sekilas aliran kontrol dari sebuah proses

6. Timing Diagrams
 Menunjukkan bagaimana sebuah objek berubah dari waktu
ke waktu

7. State Machines
 Memeriksa perilaku satu kelas
 Model tempat yang berbeda dan dapat mengalami tempat
transisi objek

8. Use-Case Diagrams
 Menunjukkan interaksi antara sistem dan lingkungan
 Menangkap kebutuhan bisnis
anas©2015 SYSTEM ANALYSIS AND
DESIGN DENGAN UML

1. System Analysis
1. Business Process Identification

 Use Case Diagram

2. Business Process Modeling

 Activity Diagram or Business Process Modeling Notation

(BPMN)
3. Business Process Realization

 Sequence Diagram (Buat untuk setiap use case dengan

menggunakan pola Boundary-Control-Entity)
anas©2015 SYSTEM ANALYSIS AND
DESIGN DENGAN UML
2. System Design
1. Program Design
1. Class Diagram (Gabungkan Boundary-Control-Entity
Class dan susun story dari sistem yang dibangun)
2. Package Diagram (Gabungan class yang sesuai, boleh
menggunakan pola B-C-E)
3. Deployment Diagram (arsitektur software dari sistem
yang dibangun)
2. User Interface Design (Buat UI design dari Boundary Class)
3. Entity-Relationship Model (Buat ER diagram dari Entity
Class)
anas©2015
BAGIAN DARI UML
anas©2015
UML Process (EA sparx systems.)

1. Use Cases Diagram

2. Activity Diagram
3. Sequence Diagram
4. Class Diagram
5. Deployment Diagrams
anas©2015
UML Process (Kendal, 2011)
1. A use case diagram, describing how the system is used. Analysts start
with a use case diagram
2. An activity diagram, illustrating the overall flow of activities. Each use
case may create one activity diagram
3. Sequence diagrams, showing the sequence of activities and class
relationships. Each use case may create one or more sequence
diagrams
4. Class diagrams, showing the classes and relationships. Sequence
diagrams are used to determine classes
5. Statechart diagrams, showing the state transitions. Each class may
create a statechart diagram, which is useful for determining class
methods
anas©2015
anas©2015
UML Process (Barclay, 2004)

(Barclay, 2004)
anas©2015
USER CASE DIAGRAM
Pertemuan-2

Use case diagram menggambarkan fungsionalitas yang diharapkan

dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat
sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan
sebuah interaksi antara aktor dengan sistem. Use case merupakan
sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create
sebuah daftar belanja, dan sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang
berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan
tertentu.

Gb. Use Case

anas©2015

Use case diagram dapat sangat membantu bila kita sedang

menyusun requirement sebuah sistem, mengkomunikasikan rancangan
dengan klien, dan merancang test case untuk semua feature yang ada
pada sistem.

Sebuah use case dapat meng-include fungsionalitas use case lain

sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan
bahwa use case yang di-include akan dipanggil setiap kali use case
yang meng-include dieksekusi secara normal.
Sebuah use case dapat di-include oleh lebih dari satu use case lain,
sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik
keluar fungsionalitas yang common.
anas©2015

Sebuah use case juga dapat meng-extend use case lain dengan
behaviour-nya sendiri. Sementara hubungan generalisasi antar use
case menunjukkan bahwa use case yang satu merupakan spesialisasi
dari yang lain.

Tujuan Praktikum:
1. Praktikan mampu membuat sebuah skenario suatu sistem yang nantinya
dapat diimplementasikan menjadi sebuah perangkat lunak.
2. Praktikan bisa memahami alur dari setiap tahap yang digunakan dalam
perancangan perangkat lunak menggunakan UML.
3. Praktikan dapat memahami hubungan atara actor dengan use case diagram.
4. Praktikan mampu membuat use case diagram dari skenario yang telah ada.
anas©2015

Use case diagram terdiri atas:

1. Use case
 menjabarkan aktifitas aktor dalam sistem yang memberikan hasil yang bisa
dilihat
2. Aktor
 Entitas eksternal (di luar sistem) yang berinteraksi dengan sistem yang
berpartisipasi dalam use case
 Bisa berupa orang, pengguna, sistem lain, atau event eksternal
3. Deskripsi Use Case
 Teks narasi dari Use Case berupa catatan atau dokumen yang terhubung ke
Use Case dan menjelaskan proses atau aktivitas yang dilakukan di Use case
4. Boundary Sistem
anas©2015 Komponen-komponen dalam
Use Case Diagram
1. Actor
Actor adalah mempersentasikan peran seseorang atau
sesuatu (seperti perangkat atau sistem lainnya) yang
berintraksi dengan sistem, actor digambarkan dengan stick
man.
Aktor tidak merepresentasikan orang atau sistem secara fisik, namun
perannya Sehingga seseorang yang berinteraksi dengan sistem dalam peran
yang berbeda akan direpresentasikan dengan beberapa aktor

Gb. Actor
anas©2015
Relasi dalam Use Case
Ada beberapa relasi yang terdapat pada use case
diagram:
1. Association, menghubungkan link antar element.
2. Generalization, disebut juga inheritance
(pewarisan), sebuah elemen dapat merupakan
spesialisasi dari elemen lainnya.
3. Dependency, sebuah element bergantung dalam
beberapa cara ke element lainnya
4. Aggregation, bentuk assosiation dimana sebuah
elemen berisi elemen lainnya
anas©2015

Tipe relasi/ stereotype yang mungkin terjadi pada use case

diagram:

1. <<include>> , yaitu kelakuan yang harus terpenuhi

agar sebuah event dapat terjadi, dimana pada kondisi ini
sebuah use case adalah bagian dari use case lainnya.
2. <<extends>>, yaitu kelakuan yang hanya berjalan di
bawah kondisi tertentu seperti menggerakkan alarm.
3. <<communicates>>, mungkin ditambahkan untuk
asosiasi yang menunjukkan
asosiasinya adalah communicates association . Ini
merupakan pilihan selama asociasi hanya tipe ralationship
yang dibolehkan antara actor dan use case.
anas©2015

Relasi Include

Relasi Extend statemen kondisional (if-then)

anas©2015

Relasi Generalisasi

Contoh 1

Contoh 2
anas©2015

Contoh Studi Kasus

Berikut ini adalah contoh dari sebuah studi kasus yang menagani Aplikasi
pada sebuah ATM dengan skenario sbb:
Sebuah bank mengoperasikan ATM dan mengelola banyak tabungan, setiap
nasabah memiliki setidaknya satu rekening tabungan pada satu bank
tertentu. Setiap tabungan dapat diakses melalui kartu debit. Proses utama
sistem ATM berkomunikasi dengan pusat komputer dan didesain untuk
menangani beberapa transaksi. Setiap transaksi menunjuk sebuah tabungan
tertentu. Suatu transaksi akan menghasilkan satu dari dua hal berikut:
transaksi diterima atau mengeluarkan pesan penolakan transaksi".
Untuk melakukan sebuah transaksi akan melalui dua tahap: pengecekan
tabungan dan pemroses transaksi. Proses pengecekan tabungan akan
menetapkan persetujuan untuk proses transaksi. Jika persetujuan ditolak,
ATM akan mengeluarkan pesan penolakan, namun jika diterima, transaksi
akan diproses de ngan menggunakan nomor rekening tabungan dan ATM
membaca dari kartu debit. Pengecekan tabungan dilakukan bersamaan pada
saat ATM memvalidasi kartu debit dari bank yang bersangkutan. Jika kartu
valid, password akan dicek dengan nasabah.
anas©2015
uc UCD - Sistem ATM

Sistem ATM

Memasukkan Kartu Memasukkan PIN

«include»

Mengecek Saldo uc Sistem ATM

Sistem ATM

Pengguna
Mentransfer Uang

Memasukkan Kartu Memasukkan PIN

«include»

Melakukan Logout Mengambil Uang

Melihat Saldo

Gambar. Contoh Use Case

«extend»

Mengirim Uang

Pengguna «extend» Admin

Memilih Transaksi

«extend»

Mengambil Uang

Mengganti Kotak
Melakukan Logout Deposit
anas©2015

Tugas 1

1. Buat Judul Rencana pembuatan Aplikasi di tempat kerja masing-masing

2. Buat Use Case
3. Kirim Ke Email paling lambat Rabu /11-03-15/Jam 12:00
4. Diprint kumpulkan saat pertemuan kamis /12-03-15
anas©2015
USER CASE DIAGRAM dan
Pertemuan-3 ACTIVIY DIAGRAM

Pertemua 3 akan membahas :

1. Structured Design Methodology
2. Pembahasan Tugas-1 Use Case
3. Activity Diagram
anas©2015
Structured Design Methodology

Planning
(System Sebelum melakukan Tahapan
Proposal) Analysis terlebih dahulu
lakukan tahapan System
Proposal dengan element sebagi
Implement SDLC and Analysis
(System berikut :
ation (New Deliverables
Specification
System) )
1. Project Name
2. Project sponsor

Design 3. Business need

(System
4. Business requirements
Specification)
5. Business value
6. Special issues
Gambar SDLC
anas©2015
Systems Development Methodologies

Waterfall Method RAD: Prototyping

Parallel Development Extreme Programming (XP)

anas©2015

Pembahasan Tugas-1
anas©2015

Lanjutan Pembahasan USE CASE

Setelah mempelajari cara membuat Use Case pada pertemuan 2
dan pembahasan tugas maka lanjutkan dengan cara
memindahkan ke media office sebagi berikut :

uc UseCaseModel_ATM

ATM System

Masukan Kartu
ATM Masukan PIN
«include»

Melihat Saldo

«include»

Melihat Transaksi Mengirim Uang

«include»
Admin
Pengguna

«include»

Melakukan
LOGOUT
Mengambil Uang
Menganti Kotak
Deposit
anas©2015
ACTIVITY DIAGRAM

Activity Diagram Dalam UML,

diagram aktivitas digunakan untuk menampilkan urutan kegiatan.
Diagram aktivitas menunjukkan alur kerja dari titik awal ke titik
finish merinci banyak jalur keputusan yang ada dalam perkembangan
peristiwa yang terkandung dalam kegiatan ini.
Dapat digunakan untuk situasi detil di mana pemrosesan paralel
dapat terjadi dalam pelaksanaan beberapa kegiatan. Diagram
aktivitas yang berguna untuk pemodelan bisnis digunakan untuk
merinci proses yang terlibat dalam kegiatan bisnis. Contoh diagram
aktivitas ditunjukkan di bawah ini.

Gb. Activity
anas©2015

Diagram Aktivitas
• Menjelaskan tentang urutan aktivitas dalam sistem (Pemodelan perilaku
sistem)
• Diagram aktivitas selalu terasosiasi ke sebuah Class, sebuah Operator dan
sebuah Use Case.
• Diagram ini bisa aktivitas sekuensial (berurut) dan paralel
 Paralel dilakukan dengan fork/wait
 Urutan aktivitas dalam eksekusi paralel tidak dipentingkan (bisa dilakukan di
waktu yang sama atau tidak)
anas©2015
Toolbox Activity Diagram

en

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
anas©2015

Action :Sebuah elemen Aksi menjelaskan proses dasar

atau transformasi yang terjadi dalam suatu sistem. adalah unit
fungsional dasar dalam diagram Activity. Keduanya merupakan proses,
tapi Kegiatan dapat berisi beberapa langkah atau proses terurai, yang
en
masing-masing dapat diwujudkan dalam Aksi.
Partition
Enterprise Architect mendukung dua jenis Kegiatan partisi Fitur
Kegiatan Partisi, yang digunakan untuk mengatur secara logis unsur
Kegiatan Unsur Kegiatan Partisi, dijelaskan dalam topik ini, yang
digunakan untuk mengatur secara logis diagram Activity.
en

en
anas©2015

Initial element
digunakan oleh Activity dan State Machine diagram. Dalam diagram Activity
mendefinisikan awal aliran ketika sebuah Kegiatan dipanggil. Dengan State
Machines, elemen awal adalah pseudo-state yang digunakan untuk
menunjukkan keadaan default dari suatu Composite State.

Decision
Decision (keputusan) merupakan elemen dari suatu diagram Activity atau
Interaksi Overview diagram yang menunjukkan jalur perkembangan bersyarat:
jika kondisi benar, maka proses berlanjut salah satu cara; jika tidak, maka lain.

en
anas©2015

Final

Final menunjukkan penyelesaian suatu kegiatan; setelah mencapai Final,

semua eksekusi dalam diagram Activity dibatalkan. Jenis lain dari simpul akhir,
Arus Akhir, menggambarkan keluar dari sistem yang tidak memiliki efek pada
arus mengeksekusi lain dalam Kegiatan
en

Fork/Join Fork /Join

 Untuk garpu atau membagi aliran menjadi beberapa
aliran bersamaan
 Untuk bergabung dengan aliran sejumlah arus
en bersamaan
 Untuk kedua bergabung dan garpu sejumlah arus
masuk ke nomor arus keluar
anas©2015

Control Flow

Menunjukkan urutan dari action state

• Jika action state sumber telah terproses, action state
target dapat mulai diproses
• Ditunjukkan dengan garis tebal

Object Flow

Menunjukkan bahwa sebuah action state memasukkan

atau menghasilkan sebuah object. Misalnya:
 Action state: “Project Manager Enters Report
Criteria “ Menghasilkan object Report Criteria
anas©2015

en

Activity Diagram
anas©2015

Activity Diagram

en
anas©2015 Activity Diagram Studi Kasus
ATM system
Contoh Studi Kasus ATM System

en
anas©2015

act memasukan_kartu en act Memasukan_PIN en

Pengguna ATM System Pengguna ATM System
Mulai Mulai

tidak
Menyiapkan Kartu memasukan PIN

tidak sampai 3 x?
Memvalidasi Account
Masukan Kartu Memvalidasi Kartu

pin valid?
Kartu Valid tidak
? Mengeluarkan Kartu
ya ya

ya
Menampilkan Menu_Utama Membelokir Kartu
Menampilkan Menu_Pin

Selesai
selesai

Gb. Memasukan kartu Gb. Memasukan Pin

anas©2015

act Mengecek_Saldo

act mentranfser_uang
Pengguna ATM System

Pengguna ATM System

mulai
en
en
mulai

Memilih Mengecek Memproses Pengecekan

Saldo di Menu Utama Saldo
Memilih mentransfer
uang di Menu Utama

Menampilkan Saldo di
Menu Saldo Memasukkan Account tidak
Tujuan

Memasukan Jumlah Memvalidasi Account

Selesai Uang yang dikirim Tujuan

tidak
account tujuan valid?

ya

Menghitung Kecukupan
Gb. Menegecek Saldo Saldo Pengiriman

saldo cukup?

ya

Mentranfer Uang

Selesai

Gb. Mentransfer Uang

anas©2015

act mengambil_uang

Pengguna ATM System

mulai
act Melakukan_Logout
en
Pengguna ATM System

tidak Mulai
Memilih Menu mengambil
uang di Menu Utama

Memasukan Jumlah Uang Mengecek ketercukupan Memilih Keluar dari Memproses Logout
saldo Menu_Utama

Saldo Cukup ? Mengeluarkan Kwinatnsi

ya

Memproses Pengamblilan Mengambil Kwitansi Mengeluarkan Kartu

Uang

Mengambil Uang diKotak Mengeluarkan Uang di

Uang Kotak Uang Mengambil Kartu

Selesai

Selesai

Gb. Mengambil Uang

Gb. Melakukan LOGOUT
anas©2015

Tugas 2

1. Perbaiki Judul
2. Perbaiki Use Case
3. Buat Activity Diagram sesuai dengan Use Case yang dibuat
4. Kirim Ke Email paling lambat Rabu /18-03-15/Jam 12:00
5. Diprint kumpulkan saat pertemuan kamis /19-03-15
anas©2015
SEQUENCE DIAGRAM
Pertemuan-4 & 5

1. Pembahasan Tugas Activity

2. Pembahasan Sequence Diagram
anas©2015

Sequence Diagram (Diagram Urutan) adalah bentuk diagram interaksi yang

menunjukkan benda yang bertahan mengalir halaman, dengan interaksi dari
waktu ke waktu direpresentasikan sebagai pesan diambil sebagai anak panah dari
garis sumber ke target. Sequence diagram pandai menunjukkan objek yang
berkomunikasi dengan yang benda lain; dan apa pesan memicu komunikasi.
Sequence diagram tidak dimaksudkan untuk menunjukkan logika prosedural
yang kompleks.

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar

sistem (termasuk pengguna, display, dan sebagainya) berupa message yang
digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal
(waktu) dan dimensi horizontal (objek-objek yang terkait).
anas©2015

• Menggambarkan benda-benda yang berpartisipasi dalam kasus penggunaan

• Tampilkan pesan yang melewati antara objek untuk penggunaan-kasus
tertentu dari waktu ke waktu

Jenis-Jenis Kelas

1. Boundary Class:
o Class yang berinteraksi dengan aktor langsung (user interface)
o Form, input, UI ini masuk di sini
2. Control Class:
o Class yang berhubungan dengan pemrosesan, penghitungan, kalkulasi,
komputasi, query, dst
3. Entity Class:
o Class yang berhubungan dengan data, penyimpanan data/file
anas©2015

Elements Sequence Diagram

anas©2015
anas©2015

An Actor :
Aktor adalah pengguna sistem; pengguna dapat berarti pengguna
manusia, mesin, atau bahkan sistem lain atau subsistem dalam model.
Apa pun yang berinteraksi dengan sistem dari luar atau sistem batas
disebut sebagai Aktor. Aktor yang biasanya terkait dengan penggunaan
Kasus.

Lifeline :
Lifeline adalah peserta individu dalam interaksi (yaitu, Lifelines tidak
dapat memiliki keragaman). Sebuah Lifeline merupakan elemen
dihubungkan berbeda.
Jalur hidup yang tersedia di Sequence diagram. Ada elemen Lifeline
berbeda untuk Timing diagram ,Namun, meskipun representasi
berbeda antara dua jenis diagram.
anas©2015

Boundary :
Obyek stereotip bahwa model beberapa sistem batas, biasanya layar
user interface. juga dapat membuat Boundary sebagai Kelas stereotip.
Elemen batas yang digunakan dalam analisis untuk menangkap
pengguna interaksi, arus layar dan interaksi elemen (atau 'kolaborasi').
Ini adalah View dalam pola Model-View-Controller.

Control :
Control adalah Obyek stereotip bahwa model entitas pengendali atau
manajer. Sebuah Kontrol mengatur dan jadwal kegiatan lain dan
elemen, urutan dan diagram Komunikasi. Ini adalah pengendali pola
Model-View-Controller.
anas©2015

Entity :
Entity adalah Obyek stereotip bahwa model penyimpanan atau yang
menangkap informasi atau pengetahuan dalam suatu sistem. Ini
adalah Model dalam pola Model-View-Controller.

Fragment

Sebuah Gabungan Fragment mencerminkan bagian atau potongan

interaksi (disebut operan interaksi) yang dikendalikan oleh operator
interaksi, yang sesuai kondisi boolean dikenal sebagai kendala
interaksi. Ini menampilkan sebagai jendela transparan, dibagi
dengan garis horizontal untuk setiap operan.
anas©2015

Contoh Kasus
Diagram urutan pemodelan proses
pembelian disederhanakan. Sebuah
loop fragmen dibuat untuk beralih
melalui jumlah yang tidak diketahui
item untuk pembelian, setelah itu
kasir meminta pembayaran. Pada
titik ini, dua opsi pembayaran
dianggap dan fragmen alternatif
dibuat, dibagi untuk menunjukkan
dua operan: uang tunai dan kartu
kredit. Setelah fragmen selesai, kasir
memberikan tanda terima kepada
pelanggan, di bawah kondisi
terpenuhi bahwa persyaratan
pembayaran dipenuhi.
anas©2015

Message (pesan) :
Pesan menunjukkan arus informasi atau transisi kendali antar elemen. Pesan
dapat digunakan oleh Timing Diagram, Diagram urutan dan Komunikasi
Diagram (tapi tidak Interaksi Overview diagram) untuk mencerminkan
perilaku sistem. Jika antara Kelas atau contoh classifier, daftar terkait operasi
tersedia untuk menentukan acara.

Self-Message
cerminkan proses baru atau metode dipanggil dalam operasi panggilan jalur,
Panggilan diri Pesan menunjukkan nested invocation; tingkat aktivasi baru
ditambahkan dengan masing-masing panggilan.
anas©2015

Interaction

Sebuah elemen Interaksi digunakan pada Sequence diagram untuk

menggambarkan sistem, mewakili interaksi tersebut pada berbagai tingkat
detail, untuk diperiksa tidak hanya oleh para profesional desain, tetapi juga oleh
pengguna akhir dan stakeholder. Sebuah elemen Interaksi dapat berisi jenis
berikut diagram:
anas©2015

Abstraction

Abstraction adalah hubungan antara dua elemen yang mewakili konsep yang
sama, baik pada tingkat yang berbeda dari abstraksi atau dari sudut pandang
yang berbeda. Diagram ini di atas menunjukkan bahwa dua Kelas pelanggan
yang berbeda dari model yang berbeda (model Domain dan model Code)
merupakan konsep yang sama. Hubungan Abstraksi adalah subtipe dari
hubungan ketergantungan.

Endpoint
digunakan dalam diagram Interaksi (Sequence,
Timing, Komunikasi atau Ikhtisar Interaksi) untuk
mencerminkan pesan hilang atau ditemukan secara
berurutan.
anas©2015
anas©2015
anas©2015

Contoh Kasus Bank System

en
anas©2015

sd Memasukan Kartu

Pengguna
KotakKartu ProsesValidasiKartu MenuPIN

MasukanKartu()

ValidasiKartu()

alt Kartu v alid? Tampilkan()

[ya]

[tidak] MengeluarkanKartu()
anas©2015

sd Memasukan_Pin

:Pengguna
MenuPIN ProsesValidasiAccount Account Login MenuUtama

MasukKanPIN()

validasi(id, pin)

getIDLogin()

getPIN()

alt PIN Valid? Tampilkan()

[ya]

[tidak]
alt lebih dari 3x ?

[tidak] tampilkan()

[ya]

blokirAccount()
errorKartuDiblokir()
anas©2015

sd mengecek_saldo

:Pengguna
MenuUtama ProsesMengecekSaldo Account Balance Transaksi MenuMenecekSaldo

MengecekSaldo()

LihatSaldo(id)

getIDBalance()

getSaldo()

setTransaksi(tgl,jenis)

tampilkanHasil(saldo)
anas©2015

sd Mentransfer_Uang

:Pengguna
MenuUtama MenuMentransferUang ProsesMentransferUang Account pengiriman: Penerimaan: Transaksi
Balance Balance
MemilihMentransferUang()

Tampilkan()

MemasukkanJumlahUang()

MemasukanAccountTujuan()

TranfserUang(id, jumlah)

getIDBalance()

getSaldo()

alt Saldo Cukup ?

[ya] setSaldo(saldo)

tampilkanUangBerhasilDikirim()

setTransaksi(tgl, jenis)

[Tidak]
tampilkanErrorSaldoTidakCUkup()
anas©2015

Bersambung……………..
Tugas 3
1. Buat Design Form
2. Buat Sequence Diagram sesuai tugas Use Case dan Activity yang dibuat
3. Kirim Ke Email paling lambat Rabu /8-04-15/Jam 12:00
4. Diprint kumpulkan saat pertemuan kamis /9-04-15
anas©2015
CLASS DIAGRAM
Pertemuan-6 & 7
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan
sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi
objek. Class menggambarkan keadaan (atribut/properti) suatu sistem,
sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut
(metoda/fungsi).

Class Diagram menunjukkan blok bangunan dari setiap sistem objek-

berorientasi. Class Diagram menggambarkan pandangan statis model, atau
bagian dari model, menggambarkan apa atribut dan perilaku nya bukan
merinci metode untuk pencapaian operasi. Class Diagram yang paling berguna
dalam menggambarkan hubungan antara kelas dan interface. Generalisasi,
agregasi, dan asosiasi semua berharga dalam mencerminkan warisan,
komposisi atau penggunaan, dan koneksi masing-masing.
anas©2015

Tujuan :
 Mahasiswa membuat class diagram dalam suatu system
 Mahasiswa mampu mendefinisikan paket dalam UML
 Mahasiswa dapat mengambarkan relasi antar class dan typenya

Class diagram menggambarkan struktur dan deskripsi class, package dan objek
beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan
lain-lain.

Class memiliki tiga area pokok :

1. Nama (dan stereotype)
2. Atribut
3. Metoda
anas©2015

Sifat Class Diagram

Atribut dan metoda dapat memiliki salah satu

sifat berikut :
 Private, tidak dapat dipanggil dari luar class yang bersangkutan
 Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-
anak yang mewarisinya
 Public, dapat dipanggil oleh siapa saja
anas©2015
Toolbox Class Diagram

en
anas©2015
Class diagram elements dan connectors

Package
Uraian :
Namespace serta elemen yang dapat terkandung dalam
namespace lain dalam Paket . Sebuah Paket dapat memiliki atau
bergabung dengan Paket lain, dan unsur-unsurnya dapat diimpor
ke namespace. Selain menggunakan Paket di Browser Project
untuk mengatur isi proyek dan dapat menarik Paket ke ruang
kerja diagram (most diagram types, both standard and extended)
penggambaran untuk struktural atau relasional, termasuk impor
Paket atau gabungan.
Class
Representasi dari jenis objek yang mencerminkan struktur dan
perilaku objek seperti dalam sistem. Meskipun Class dapat
didefinisikan baik untuk mengontrol pelaksanaannya sendiri atau
sebagai template atau class parameter yang menentukan
parameter yang harus ditentukan oleh any binding class
anas©2015

Class dapat memiliki atribut (data) dan metode (operasi atau perilaku).
class dapat mewarisi karakteristik dari parent class dan mendelegasikan
perilaku class lain. Model class biasanya menggambarkan struktur logis
dari sistem dan merupakan blok bangunan dari mana komponen
dibangun.
Interface
Interface adalah spesifikasi perilaku (atau kontrak) yang
pelaksana setuju untuk bertemu. Dengan menerapkan
Interface, Kelas dijamin untuk mendukung perilaku yang
diperlukan, yang memungkinkan sistem untuk treat
unsur-unsur non-terkait dengan cara yang sama; yaitu,
melalui interface umum.
anas©2015

Data Type
Tipe data adalah jenis tertentu classifier, mirip dengan Kelas kecuali
bahwa tipe data dapat sub Tipe Data tidak sendiri, dan contoh dari tipe
data diidentifikasi hanya dengan nilai. Sebagai contoh, sebuah instance
dari kelas Orang adalah object, tetapi sebuah instance dari Integer Data 12
Type.
anas©2015

Table

Table adalah Kelas stereotip. biasanya menggunakan elemen

ini di data diagram Modeling.
Unsur Tabel memiliki dialog Properties khusus, dengan
pengaturan untuk jenis database dan kemampuan untuk
mengatur informasi kolom dan operasi yang berhubungan
dengan data seperti pemicu dan indeks. Saat membuat Tabel,
pastikan Anda mengatur jenis database default untuk tabel itu,
jika tidak, anda tidak memiliki tipe data untuk memilih dari
saat membuat kolom.
anas©2015

Composition

Sebuah Komposisi digunakan untuk menggambarkan sebuah elemen yang

terdiri dari komponen yang lebih kecil, biasanya dalam Kelas atau Paket
diagram. Sebuah komponen - atau sebagian contoh - dapat dimasukkan dalam
maksimum satu komposisi pada suatu waktu. Jika komposisi dihapus,
biasanya semua bagian-bagiannya akan dihapus ; Namun, bagian dapat secara
individual dihapus dari komposisi tanpa harus menghapus seluruh komposisi.
Komposisi yang transitif, hubungan asimetris dan dapat rekursif.
anas©2015

Aggregation

Konektor Agregasi adalah jenis asosiasi yang menunjukkan bahwa unsur

mengandung atau terdiri dari unsur-unsur lain. Hal ini digunakan dalam
model kelas, model paket dan model Object untuk menunjukkan bagaimana
unsur-unsur yang lebih kompleks (agregat) yang dibangun dari kumpulan
elemen sederhana (bagian komponen, misalnya, sebuah mobil dari roda, ban
motor dan sebagainya).

Sebuah bentuk yang lebih kuat agregasi, yang dikenal sebagai Komposit
Agregasi, digunakan untuk menunjukkan kepemilikan atas seluruh bagian-
bagiannya. Bagian dapat dikelompokkan pada satu Composite Agregasi pada
suatu waktu. Jika komposit dihapus, semua bagian-bagiannya akan dihapus
dengan itu.
anas©2015

Contoh Class Buku

Class Buku terdiri dari :
– Atribut : judul, pengarang
– Method : ambilJenis(), ambilHalaman();
anas©2015

Gb. Output Class diagram Buku

anas©2015

Contoh Latihan
anas©2015
anas©2015
Contoh Studi Kasus ATM System
class Class Diagram

ProsesValidasiAccount Login
KotakUang KotakKuitansi mengakses
MenuLogin melakukan
+ KotakUang()
+ finalize() :void

mengakses

memiliki memiliki
memiliki
MenuMelihatSaldo ProsesMelihatSaldo Account

melakukan + m_Account :Account mengakses + getID() :void

SistemATM + setID() :void
mewarisi + lihatSaldo() :void
+ m_KotakDeposit :KotakDeposit MenuUtama
+ m_KotakKartu :KotakKartu + ProsesMelihatSaldo()
+ m_KotakKuitansi :KotakKuitansi mengakses
+ m_KotakUang :KotakUang
+ m_MenuLogin :MenuLogin mewarisi

+ SistemATM() MenuMengambilUang
+ finalize() :void mengakses
melakukan ProsesMengambilUang
+ main() :void
mewarisi

memiliki mewarisi
memiliki
MenuLogout
KotakDeposit
KotakKartu
ProsesMengirimUang

MenuMengirimUang + m_Account :Account

melakukan
melakukan melakukan melakukan + ProsesMengirimUang()
+ finalize() :void
+ kirimUang() :void
ProsesKotakDeposit ProsesValidasiKartu ProsesLogout
anas©2015

Tugas 4
1. Buat Class Diagram sesuai tugas Judul Proejct Masing2
anas©2015
DEPLOYMENT DIAGRAM
Pertemuan-9 & 10
Diagram deployment menggambarkan pandangan statis konfigurasi run-
time dari node pengolahan dan komponen yang berjalan pada simpul tersebut.
Menunjukkan hardware untuk sistem, perangkat lunak yang diinstal pada
perangkat keras , dan middleware (software yang bertindak sebagai jembatan
antara sistem operasi atau database dan aplikasi, terutama pada jaringan),
digunakan untuk menghubungkan mesin yang berbeda satu sama lain.

Diagram Deployment juga dapat dibuat untuk mengeksplorasi arsitektur

embedded system, menunjukkan bagaimana komponen hardware dan software
bekerja sama.

misalnya point-of-sales aplikasi yang berjalan pada jaringan komputer thin-client

yang berinteraksi dengan beberapa server internal di belakang firewall
perusahaan atau sistem layanan pelanggan dikerahkan menggunakan arsitektur
layanan web seperti NET Microsoft.
anas©2015

Fungsi Deployment Diagram

 Menunjukkan dimana setiap komponen komponen perangkat keras

perangkat lunak diinstal
 Menunjukkan hubungan komunikasi antara komponen perangkat keras.
 Menunjukkan struktur dari sistem run-time
anas©2015
Toolbox Deployment Diagram
anas©2015

en
Node adalah bagian fisik dari peralatan pada sistem
digunakan, seperti server workgroup atau workstation.
Node biasanya host komponen dan potongan executable
lain dari kode, yang dapat dihubungkan dengan proses
tertentu atau ruang eksekusi. Nodes workstation klien,
server aplikasi, mainframe, router dan server terminal.

en
en
anas©2015

Artifact adalah setiap bagian fisik informasi yang digunakan

atau dihasilkan oleh sistem, biasanya direpresentasikan
dalam diagram Deployment.

Artefak dikaitkan sifat atau operasi, dan dapat dipakai atau

berhubungan dengan Artefak lainnya. Contoh misalnya
penggunaan model kasus, desain model dll), file sumber,
executable, dokumen desain, laporan pengujian, prototipe,
buku petunjuk, dll.

Device adalah sumber daya elektronik fisik dengan

kemampuan pengolahan yang di atasnya Artefak dapat
digunakan untuk eksekusi. Perangkat kompleks dapat
terdiri dari perangkat lain; yaitu, Perangkat dapat menjadi
elemen bersarang, di mana mesin fisik diuraikan menjadi
unsur-unsurnya baik melalui kepemilikan namespace atau
melalui atribut yang diketik oleh Devices.
anas©2015

Execution Environment adalah node yang

menawarkan lingkungan eksekusi untuk tipe tertentu dari
komponen yang digunakan pada dalam bentuk artefak
executable.

Component adalah bagian modular dari sistem, yang

perilakunya ditentukan oleh interface yang disediakan
dan diperlukan. File kode sumber, DLL dan artefak
lainnya mendefinisikan sistem dapat diwujudkan dalam
Komponen. Sebuah Komponen dapat terdiri dari
beberapa Kelas, atau komponen disatukan.
anas©2015

CONTOH : Personal digital assistant

anas©2015

Diagram deployment menunjukkan beberapa gambaran

penyebaran dari artefak untuk target penyebaran
anas©2015

Contoh Studi Kasus ATM System

deployment ATM System

«device»
ATM SYSTEM(client)

«device»

KOTAK Layar
KARTU «interface»
::Database Serv er

«TCP/IP»

Kotak Uang Kotak

Kw itansi
anas©2015

Tugas 5
1. Buat Deployment Diagram sesuai tugas Judul Project Masing2
anas©2015
Data Modeling
Ketika merancang atau mendokumentasikan database :
• Membuat diagram Data Model untuk memvisualisasikan skema database
• Membuat tabel dan tampilan
• Membuat kolom, primary keys, foreign keys
• Membuat prosedur yang tersimpan
• Membuat indeks, urutan, fungsi dan pemicu
• Menghasilkan DDL untuk tabel atau seluruh paket
• Mengkonversi tipe data untuk meja, paket atau seluruh DBMS
• Mengimpor skema database dari sumber data ODBC.
Jenis-jenis Database
 DB2
 InterBase
 Informix
 Ingres
 Microsoft Access 2007
 MySQL
 Oracle 9i, 10g and 11g
 PostgreSQL
 Microsoft SQL Server 7, 2000,
2005 and 2008
 Sybase Adaptive Server
Anywhere, Enterprise
 Firebird.
anas©2015

Setelah menampilkan toolbook

Data modeling (database
enggenreing) :
1. Klik Table
2. Klik Properties
3. Tampil class OrderBuku
4. Pilih Jenis Database
5. Pastikan stereotype table
anas©2015

Cara Membuat Field

1. Buka Attributes
2. Tambahkan nama field
3. Tambahkan data type
4. Tambahkan size
5. Pastikan steoretype column
anas©2015

Cara menambahkan Operational

1. Buka Operational
2. Buat Primary Key
3. Buat Foreign Key
anas©2015
Contoh studi case Order Buku
Database -> Oracle
dm Gudang Buku

Gudang

«column»
*PK idGudang :VARCHAR2(10)
Lokasi :VARCHAR2(30)
Kapasitas :NUMBER(8,2)
ATM::Buku
«PK»
+ PK_Gudang(VARCHAR2) «column»
*PK ISBN :VARCHAR2(15)
FK idStok :VARCHAR2(10)
(idGudang=idGudang) idPengarang :VARCHAR2(30)
idPenerbit :VARCHAR2(20)
harga :NUMBER(8,2)
stok :NUMBER(8)
Stock
idStok=idStok «PK»
+ PK_Buku(VARCHAR2)
«column»
*PK idStock :VARCHAR2(10) «FK»
FK idGudang :VARCHAR2(10) + FK_Buku_Stok(VARCHAR2)
stockSekarang :NUMBER(8)
Order :NUMBER(8)

«PK»
+ PK_Stock(VARCHAR2)
«FK»
+ FK_Gudang_Stok(VARCHAR2)
anas©2015
Contoh studi case Sales
anas©2015

Contoh Studi Case Sistem ATM

anas©2015
Packaging Diagram

Package

Jika sistem hanya memiliki sedikit class, kita dapat mengaturnya dengan
mudah. Sebagian besar sistem dibuat dari banyak class sehingga kita
memerlukan suatu mekanisme untuk mengelompokkannya bersama untuk
memudahkan dalam hal penggunaan, perawatan, dan penggunaan
kembali . Package adalah kumpulan dari dari package atau class yang
berelasi. Dengan mengelompokkan class dalam package, kita bisa melihat
level yang lebih tinggi dari model kita atau kita bisa menggali model
dengan lebih dalam dengan melihat apa yang ada di dalam package.

Jika sistemnya kompleks, package mungkin dibuat di awal fase elaborasi

sebagai fasilitator komunikasi. Untuk sistem yang lebih sederhana, class-
class yang didapat pada tahap analisa mungkin dikelompokkan dalam
suatu package. Di UML, package digambarkan sebagai folder.
anas©2015
anas©2015

Package Relationship
Relasi yang digunakan dalam package relationship adalah dependency
relationship . Jika sebuah package A tergantung pada package B, hal ini berakibat
satu atau lebih class-class di package A memulai berkomunikasi dengan satu atau
lebih public class di package B. Package A disebut client package dan package B
disebut supplier package.
anas©2015
anas©2015
User Interface / Form

User Interface diagram yang disesuaikan UML diagram di

mana Anda secara visual dapat mewakili user interface sistem
menggunakan bentuk, kontrol dan label.

Screen digunakan untuk prototipe aliran layar User

Interface. Dengan menggunakan fitur UML seperti
persyaratan, kendala dan skenario terhadap elemen diagram
User Interface, dapat membangun pemahaman yang kuat dan
rinci dari perilaku user interface tanpa harus menggunakan
kode.

Gb. Contoh Screen

anas©2015

UI CONTROL : merupakan elemen kontrol antarmuka pengguna (seperti

kotak edit). Hal ini digunakan untuk menangkap komponen dari tata letak
layar dan persyaratan dalam Custom atau Pengguna diagram Interface.
Ada sejumlah Pengendalian UI elemen yang tersedia di halaman User
Interface dari Toolbox.
anas©2015

Contoh Interface
anas©2015
anas©2015

Contoh studi kasus sistem ATM

custom User Interface Model

Menu Login Menu Utama Menu Melihat Saldo

Melihat Saldo
Mengirim Uang Saldo anda adalah ...
PIN Mengambil Uang
Logout
«navigate» «navigate»

Pilihan

«navigate» «navigate» «navigate»

menu logut Menu Mengirim Uang

Menu Mengambil Uang

Kartu Keluar Account Penerima:

Jumlah Uang:
Kuitansi Keluar
Jumlah Uang:
Transaksi Anda Teah Selsai diakukan

Ambil Uang
Kirim Uang
anas©2015

TUGAS MANDIRI:
1. Buatlah Sesuai Judul Tugas Masing-masing
2. Use Case Diagram (Business Process Identification)
3. Activity Diagram (Business Process Modeling)
4. Sequence Diagram (Business Process Realization
5. Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story
6. Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E)
7. Deployment Diagram (arsitektur software dari sistem yang dibangun)
8. Entity-Relationship Model/Data Modeling (Buat ER diagram dari Entity Class)
9. User Interface Design (Buat UI design dari Boundary Class)
anas©2015

Is it Possible?
anas©2015

Daftar Pustaka

• Ian Sommerville, Software Engineering 9th Edition, Addison-Wesley, 2010

• Ivar Jacobson, Magnus Christerson, Patrik Jonson, and Gunnar Overgaard,
Object-Oriented
• Grady Booch, Object-Oriented Analysis and Design with Application,
Benjamin/Cummings, 1991.
• Peter Coad and Edward Yourdon, Object-Oriented Analysis, Yourdon Press, 1991.
• Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.
• James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling
Language
• Reference Manual, Addison-Wesley, 1999.
• Roger S. Pressman, Software Engineering: A Practitioner’s Approach Sevent Edition,
McGraw-Hill, 2009
• http://www.omg.org/
• http://www.sparxsystems.com.au
• James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William
Lorenson,
• Object-Oriented Modeling and Design, Prentice Hall, 1991.
anas©2015

TERIMA KASIH