UML

(Unified Modeling
Language)
ediwidodo@usm.ac.id
Pendahuluan
• Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan
pengkodean (coding)
• Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan
gedung
• Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak
dapat memahami sistem itu secara menyeluruh.
• Dengan pemodelan, diharapkan perangkat lunak yang dihasilkan dapat memenuhi semua
kebutuhan pengguna dengan lengkap dan tepat (termasuk scalability, robustness, security)
• UML merupakan salah satu alat bantu yang sangat handal dalam bidang pengembangan
sistem berorientasi objek karena UML menyediakan bahasa pemodelan visual yang
memungkinkan pengembang sistem membuat blue print atas visinya dalam bentuk yang
baku
Definisi
• Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah
menjadi standar dalam industri untuk visualisasi, merancang dan
mendokumentasikan sistem piranti lunak.
• Notasi UML merupakan sekumpulan bentuk khusus untuk menggam-
barkan berbagai diagram piranti lunak.
• UML digunakan pada tahap analisa dan desain. Desain yang dihasilkan
berupa diagram-diagram UML yang akan diterjemahkan menjadi kode
program pada tahap pengkodean
Fungsi UML
• Menggambarkan batasan sistem dan fungsi-fungsi sistem secara umum,
dibuat dengan use case dan actor
• Menggambarkan kegiatan atau proses bisnis yang dilaksanakan secara
umum, dibuat dengan interaction diagrams
• Menggambarkan representasi struktur statik sebuah sistem dalam bentuk
class diagrams
• Membuat model behavior ”yang menggambarkan kebiasaan atau sifat sebuah
sistem” dengan state transition diagrams
• Menyatakan arsitektur implementasi fisik menggunakan component and
development diagram, untuk menyampaikan atau memperluas fungsionality
dengan stereotypes.
Komponen Pada UML
Komponen Pada UML
• Structure Diagram adalah diagram komponen yang terdapat di dalam
system.
• Contoh : Komponen Penjualan, Komponen Pembelian, dll. Yang terdapat
dalam ERP sebuah perusahaan

• Behaviour Diagram adalah diagram perilaku yang menggambarkan

interaksi antara user dengan system
• Contoh : Bagiamana cara user bagian penjualan dalam membuat permintaan
pembelian menggunakan system ERP
Activity Diagram
• Diagram ini menggambarkan tentang aktifitas yang terjadi pada system
• Dari pertama sampai akhir, diagram ini menunjukkan langkah – langkah dalam
proses kerja sistem yang kita buat
• Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih.
• Aktivitas menggambarkan proses yang berjalan, sementara use case
menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas
• Fungsi activity diagram
• Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses
• Memperlihatkan urutan aktifitas proses pada sistem
• Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram
Element Activity Diagram
• Action
• Langkah dalam aktivitas dimana pengguna atau perangkat lunak melakukan tugas yang
diberikan
• Decision Node
• Cabang bersyarat yang mencakup satu input dan dua atau lebih output
• Control Flow
• konektor yang menunjukkan aliran langkah dalam diagram
• Start Node
• Melambangkan awal aktifitas
• End Node
• Melambangkan akhir aktifitas
Contoh Diagram Aktifitas
Use Case Diagram
• Use case diagram merupakan gambaran dalam bentuk grafis tentang
interaksi antara user (users) dengan system.
• Use case merukapan “apa” yang diperbuat oleh system, bukan
“bagaimana” system bekerja.
• Fungsi Use Case
• Menjelaskan fasilitas atau sistem requirement dari software
• Menggambarkan komunikasi atau interaksi pengguna dan sistem
• Melakukan serangkaian test dari fungsi sistem secara umum
Elemen Use Case
• Actor
• Mempresentasikan seseorang atau sesuatu (seperti perangkat,sistem lain) yang
berinteraksi dengan sistem.
• Actor hanya berinteraksi dengan use case tetapi tidak memiliki kontrol atas use case
• Use Case
• Adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna
sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.
• Association
• Garis yang menghubungkan antara actor dengan use case
• System Boundary
• Batasan system pada use case
Contoh Diagram Use Case
Sistem Penjualan

Actor

Use Case

Association
Sequence Diagram
• 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 biasa digunakan untuk menggambarkan skenario
atau rangkaian langkah-langkah yang dilakukan sebagai respons dari
sebuah event untuk menghasilkan output tertentu.
• Diawali dari apa yang men-trigger aktivitas tersebut, proses dan
perubahan apa saja yang terjadi secara internal dan output apa yang
dihasilkan
Element Sequence Diagram
• Object
• komponen berbentuk kotak yang mewakili sebuah class atau object. Bagaimana sebuah object
berperilaku pada sebuah system.
• Activation boxes
• komponen yang berbentuk persegi panjang yang menggambarkan waktu yang diperlukan
sebuah object untuk menyelesaikan tugas. Lebih lama waktu yang diperlukan, maka activation
boxes akan lebih panjang.
• Actors
• komponen yang berbentuk stick figure. Komponen yang mewakili seorang pengguna yang
berinteraksi dengan system.
• Lifeline
• komponen yang berbentuk garis putus - putus. Lifeline biasanya memuat kotak yang berisi
nama dari sebuah object. Berfungsi menggambarkan aktifitas dari object.
Contoh Sequence Diagram

• Diagram disamping
yang menjadi Actors
adalahAdministrator.
• Activation boxes
biasanya memilik garis
yang memberitahu
aktifitas yang terjadi
ketika actors atau
objects berinteraksi ke
object lain
Package Diagram
• Fungsi utama dari package diagram adalah untuk mengelompokkan
beberapa elemen /komponen diagram dalam UML yang berbeda,
secara bersama-sama ke suatu tingkat atau tempat yang lebih tinggi,
sehingga menjadi sebuah paket
Contoh Package Diagram
State Chart Diagram
• Statechart diagram menggambarkan transisi dan perubahan keadaan
(dari satu state ke state lainnya) suatu objek pada sistem sebagai
akibat dari stimuli yang diterima
• Pada umumnya statechart diagram menggambarkan class tertentu
(satu class dapat memiliki lebih dari satu statechart diagram).
• Dalam UML, state digambarkan berbentuk segiempat dengan sudut
membulat dan memiliki nama sesuai kondisinya saat itu.
Contoh state chart Diagram
Tahapan Membuat UML
Tahapan Membuat UML
1. Menentukan Functional Requirement
2. Membuat Domain Model
3. Membuat Use Case
4. Requirement Review
5. Robustness Analysis
6. Preliminary Design Review
7. Technical Architecture
8. Sequence Diagram
9. Critical Design Review
10. Penulisan Coding
1. Functional Requirement
• Gunakan Word untuk menuliskan functional requirement (apa yang
dapat dilakukan oleh sistem?)
• Tahap ini melibatkan business analyst, pelanggan, end user, dan
project stakeholders lainnya.
• Functional requirement bersifat tidak terstruktur dan tidak dapat
dipakai dalam perancangan secara langsung.
• Berikut ini adalah contoh potongan dari function requirement untuk
sebuah sistem bengkel motor yang sederhana
Contoh Sederhana Sistem Informasi Bengkel
• System harus dapat memproses work order untuk motor mulai dari
antri sedang dikerjakan mekanik, selesai di servis dan proses
pembayaran
• Sebuah work order memiliki informasi jenis pekerjaan dan sparepart
yang dijual
• Harga ongkos servis berdasarkan jenis pekerjaan dan tipe motor
2. Domain Model
• Salah satu fungsi domain model adalah menyamakan istilah yang akan pakai
diproses selanjutnya.
• Misalnya, apakah saya akan memakai istilah ‘work order’ atau ‘pekerjaan servis’?
• Apa saya akan memakai sebutan ‘sparepart‘ atau ‘suku cadang‘ Walau terlihat sepele,
perbedaan istilah seringkali menimbulkan salah paham dalam komunikasi tim.
• Pada tahap ini, domain model adalah class diagram yang hanya memakai
relasi pewarisan (is-a/adalah sebuah) dan agregasi (has-a/memiliki
sebuah).
• Class diagram ini belum memiliki atribut dan operasi. Nantinya, di proses
selanjutnya, domain model akan diperbaiki dan dikembangkan menjadi lebih
detail.
Contoh
• Domain Model versi Awal
3. Use Case
• Use case mendefinisikan behavioural requirements berdasarkan
functional requirement (dan sumber lainnya).
• Kalimat yang dipakai dalam use case harus berupa kalimat aktif
• misalnya “pengguna men-klik tombol Login”.
• Kalimat pasif seperti “Sistem menyediakan tombol Login” adalah ciri-
ciri functional requirement dan bukan bagian dari use case.
• Use case harus mengandung nama di domain model
• Sebuah use case hampir mirip seperti dokumentasi sistem. Kita perlu
menspesifikasikan seperti apa cara pakai sistem (termasuk respon
sistem) sebelum sebuah sistem dibuat.
Contoh

• Contoh use case diagram berdasarkan

functional requirement di langkah 1 dan
memakai domain model dari langkah 2
• Perhatikan, setiap usecase menggunakan kalimat
aktif
Skenario setiap usecase
• Membuat Work Order Baru
• Basic Scenario
• Front Desk memilih Motor di Screen ListMotor dan men-klik tombol untuk membuat WorkOrder.
• Sistem akan membuat sebuah WorkOrder baru dengan status sedang antri.
• Alternate Scenario
• Motor belum terdaftar - Front Desk terlebih dahulu menambah Motor baru dengan men-klik
tombol untuk menambah Motor baru sebelum mengerjakan langkah yang ada di Basic Scenario.
• Motor yang sudah memiliki WorkOrder yang sedang antri - Sistem akan menampilkan pesan
kesalahan.

• Catatan: pada saat membuat use case ini, terlihat bahwa dibutuhkan use case menambah Motor.
Dalam contoh ini, use case tersebut diabaikan.
Skenario setiap usecase
• Mengubah Status WorkOrder menjadi sedang dikerjakan oleh Mekanik
• Basic Scenario
• Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder dan memilih menu untuk
menandakan bahwa Workorder tersebut sedang dikerjakan.
• Sistem akan menampilkan Screen PengerjaanWorkOrder. Front Desk memilih nama
Mekanik yang mengerjakan WorkOrder dan men-klik tombol untuk menyimpan
perubahan.
• Sistem akan mengubah status WorkOrder menjadi sedang dikerjakan serta mencatat
tanggal & jam mulai dikerjakan.
• Alternate Scenario
• Status WorkOrder yang dipilih bukan sedang antri - Sistem akan menampilkan pesan
kesalahan.
Skenario setiap usecase
• Menambah Sparepart yang dipakai selama pengerjaan WorkOrder
• Basic Scenario
• Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder dan memilih menu untuk menambah Sparepart
di WorkOrder. Sistem akan menampilkan Screen TambahSparepart yang berisi daftar Sparepart untuk WorkOrder
yang dipilih. Disini Front Desk akan mengisi data ItemSparepart dengan memilih Sparepart, memasukkan jumlah
Sparepart, lalu men-klik tombol Tambah ItemSparepart. Sistem akan memperbaharui daftar ItemSparepart di layar.
• Front Desk men-klik tombol Simpan untuk selesai. Sistem akan menyimpan perubahan Sparepart pada WorkOrder
terpilih.
• Alternate Scenario
• Terdapat lebih dari satu jenis Sparepart yang perlu ditambahkan - Front Desk kembali menambah data
ItemSparepart. Setelah semua ItemSparepart selesai dimasukkan, Front Desk men-klik tombol Simpan di Screen
TambahSparepart. Sistem akan menyimpan perubahan.
• Status WorkOrder yang dipilih bukan sedang dikerjakan - Sistem akan menampilkan pesan kesalahan.

• Catatan: pada saat membuat use case ini, terlihat bahwa ada yang kurang pada domain model, yaitu
ItemSparepart. Segera update domain model! Terlihat juga bahwa dibutuhkan sebuah metode untuk menghapus
Sparepart dan meng-edit jumlah Sparepart terpakai. Pada contoh ini, use case tersebut diabaikan.
Skenario setiap usecase
• Mengubah status WorkOrder menjadi selesai dikerjakan
• Basic Scenario
• Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder, lalu memilih menu
untuk mengubah status WorkOrder menjadi selesai dikerjakan. Sistem akan
menampilkan dialog konfirmasi.
• Bila kasir menkonfirmasi, Sistem akan mengubah status WorkOrder tersebut menjadi
selesai dikerjakan dan mencatat jam selesai dikerjakan. Front Desk kemudian
mengerjakan use case "Mencetak rincian WorkOrder termasuk biaya".
• Alternate Scenario
• Status WorkOrder bukan sedang dikerjakan - Sistem akan menampilkan pesan kesalahan.
Skenario setiap usecase
• Mencetak rincian WorkOrder termasuk biaya
• Basic Scenario
• Front Desk memilih tombol untuk mencetak. Sistem kemudian mencetak detail WorkOrder
ke printer.
• Detail WorkOrder yang dicetak meliputi tanggal, plat nomor motor, jam mulai dikerjakan, jam
selesai dikerjakan, nama mekanik yang mengerjakan, rincian seluruh Sparepart yang dipakai
(jumlah & harga eceran tertinggi Sparepart), ongkos servis dan total yang harus dibayar.
• Alternate Scenario
• Status WorkOrder bukan selesai dikerjakan - Sistem akan menampilkan pesan kesalahan.

• Catatan: use case ini dipisahkan dari use case "Mengubah status WorkOrder menjadi selesai
dikerjakan" karena dianggap nanti akan ada use case lain yang dapat mencetak rincian WorkOrder
tetapi tidak ditampilkan disini.
4. Requirement Review
• Melihat ulang hasil pada langkah sebelumnya
• Pada saat melakukan analisa dalam membuat use case, ada hal yang masih kurang. Seperti
perlu menambahkan class ItemSparepart pada domain model.
• Pada beberapa situasi, ditemukan ada use case yang masih kurang, misalnya use case
“Tambah Motor baru“.
• Pada langkah ini, dipastikan bahwa use case & domain model telah dibuat
dengan baik.
• Pelanggan juga perlu dilibatkan untuk memastikan bahwa use case (behavioral
requirement) & functional requirement sesuai dengan yang diharapkan.
• Ingatlah selalu bahwa bagian terpenting dari sebuah sistem bukanlah seberapa
keren design pattern yang diterapkan di class diagram, tetapi sejauh mana sistem
tersebut memenuhi requirements.
5. Robustness Analisys
• Robustness analysis dipakai untuk menjembatani analisis dan
perancangan. Robustness analysis harus diterapkan pada setiap use
case yang ada.
• Pada Enterprise Architect, robustness analysis dapat digambarkan
dengan menggunakan Analysis Diagrams.
• Semakin detail robustness analysis, maka semakin banyak hal yang
kurang dari use case dan domain model yang akan ditemukan
Analisys diagram untuk use case
Melengkapi Domain Model dengan Attribut
6. Preliminary Design Review
• Kembali lagi seluruh tim melakukan review dan memastikan bahwa
semua yang telah dibuat sesuai dengan requirement
• Tahap Ini adalah langkah terakhir dimana pelanggan (stackholder)
terlibat! Hal ini karena langkah berikutnya melibatkan proses
technical
• Akan berbahaya bila membiarkan pelanggan yang non-technical
atau semi-technical mengambil keputusan untuk hal-hal yang bersifat
teknis (misalnya framework atau database yang dipakai).
• Walaupun demikian, pelanggan boleh memberikan komentar
mengenai tampilan
7. Technical Architecture
• Tentukan framework apa yang akan dipakai.
• Database yang akan dipakai
• Teknologi komunikasi yang akan digunakan
• Analisa lain yang berhubungan dengan spesifikasi teknis untuk
mewujudkan requirement spesification
8. Sequence Diagram
• Sequence diagram dibuat untuk setiap use case yang ada,
berdasarkan hasil robustness anaylsis
• Dalam membuat sequence diagram, tujuannya adalah menemukan
operasi (behavior) untuk setiap class yang ada, bukan menunjukkan
step-by-step operasi secara detail!
• Sequence diagram dibuat untuk setiap use case yang ada, berdasar-
kan hasil robustness anaylsis
9. Critical Design Review
• Kembali melakukan review untuk memastikan bahwa tidak ada yang
kurang pada sequence diagram.
• Pastikan bahwa setiap class yang ada telah memiliki atribut dan
operasi yang didefinisikan secara lengkap (memiliki nama, tipe data,
parameter, dsb).
• Contoh, pada use case “Menambah Sparepart yang dipakai selaman
pengerjaan WorkOrder”, sistem harus mengurangi jumlah stok Sparepart bila
pengguna meng-klik tombol simpan. Oleh sebab itu, segera perbaharui teks
use case
Domain Model yang telah diperbaharui.
10. Coding
• Pada tahap ini, developer berperan mengubah rancangan (design)
menjadi kode program.
• Karena semua telah direncanakan dan dipikirkan sebelumnya, maka
proses coding dapat dianggap sebagai sebuah pembuktian (test)
bahwa rancangan yang dibuat sudah benar
• Terkadang terdapat beberapa hal yang lolos dari perancangan dan
baru terungkap saat coding; pada kasus tersebut, perubahan pada
rancangan harus segera dilakukan sehingga kode program dan
rancangan bisa tetap sinkron