UNIFIED MODELING LANGUAGE

LANJUTAN

GERSON FEOH, S.KOM

STIKOM BALI
2009
Pemodelan Visual
Bangun rumaharsitek rancangan rumah(denah atau maket)
yang akan memandu kontraktor/pembangun rumah kita.
Bangun sistem informasi/perangkat lunak pemodelan visual
proses penggambaran informasi-informasi secara grafis dengan
notasi-notasi baku yang telah disepakati sebelumnya.
Fungsi pemodelan visual :
Tinjauan umum bagaimana arsitektur sistem secara keseluruhan.
Penelaahan bagaimana objek-objek dalam sistem saling mengirimkan
pesan (message) dan saling bekerjasama satu sama lain.
Menguji apakah sistem/perangkat lunak sudah berfungsi seperti yang
seharusnya.
Dokumentasi sistem/perangkat lunak untuk keperluan-keperluan
tertentu di masa yang akan datang.
Awal Notasi Pemodelan Visual
Notasi-notasi UML terbentuk dari :
Notasi Booch Graddy Booch
Notasi OMT (Object Modeling Technique) DR. James
Rumbaugh
Notasi OOSE (Object Oriented Software Engineering) Ivar
Jacobson.
Dimulai pada Oktober 1994, DR.Rumbaugh bergabung
dengan Booch di Rational Software Corporation.
Proyek pertama menggabungkan metoda Booch dan
OMT.
Jenis Diagram UML
UML Diagram Statis & Diagram Dinamis.
Diagram Statis :
Class Diagram
Object Diagram
Use Case Diagram
Component Diagram
Deployment Diagram
Diagram Dinamis :
Sequence Diagram
Collaboration Diagram
Statechart Diagram
Activity Diagram
DIAGRAM STATIS
Class Diagram
Diagram ini memperlihatkan himpunan kelas-kelas, antarmuka-antarmuka, kolaborasi-kolaborasi, serta relasi-relasi.
Diagram ini umum dijumpai pada pemodelan sistem berorientasi objek.
Meskipun bersifat statis, sering pula diagram kelas memuat kelas-kelas aktif.
Object Diagram
Diagram ini memperlihatkan objek-objek serta relasi-relasi antar object.
Diagram object memperlihatkan instansiasi statis dari segala sesuatu yang dijumpai pada diagram kelas.
Use Case Diagram
Diagram ini memperlihatkan himpunan use case dan aktor-aktor (suatu jenis khusus dari kelas).
Diagram ini terutama sangat penting untuk mengorganisasi dam memodelkan perilaku dari suatu sistem yang dibutuhkan serta
diharapkan pengguna.
Component Diagram
Diagram komponen ini memperlihatkan organisasi serta kebergantungan sistem/perangkat lunak pada komponen-komponen
yang telah ada sebelumnya.
Diagram ini berhubungan dengan diagram kelas dimana komponen secara tipikal dipetakan kedalam satu atau lebih kelas-kelas,
antarmuka-antarmuka (interfaces), serta kolaborasi-kolaborasi.
Deployment Diagram
Diagram ini memperlihatkan konfigurasi saat aplikasi dijalankan (saat run-time).
Diagram ini memuat simpul-simpul (node) beserta komponen-komponen yang ada didalamnya.
Deployment diagram berhubungan erat dengan diagram komponen dimana deployment diagram memuat satu atau lebih
komponen-komponen.
Diagram ini sangat berguna saat aplikasi kita berlaku sebagai aplikasi yang dijalankan pada banyak mesin (distibuted computing)
DIAGRAM DINAMIS
Sequence Diagram
Diagram urutan adalah diagram interaksi yang menekankan pada pengiriman pesan
(message) dalam suatu waktu tertentu.
Collaboration Diagram
Diagram kolaborasi adalah diagram interaksi yang menekankan organisasi struktural dari
object-object yang menerima serta mengirim pesan (message).
Statechart Diagram
Diagram state ini memperlihatkan state-state pada sistem; memuat state, transisi, event,
serta aktifitas.
Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka
(interface), kelas, kolaborasi, dan terutama penting pada pemodelan sistem-sitem yang
reaktif.
Activity Diagram
Diagram aktivitas ini adalah tipe khusus dari diagram state yang memperlihatkan aliran
dari suatu aktifitas ke aktifitas lainnya dalam suatu sistem
Diagram ini terutama penting dalam pemodelan fungsi-fungsi dalam suatu sistem dan
memberi tekanan pada aliran kendali antarobjek.
Contoh Hubungan Antar Diagram
Diagram kelas (class diagram) juga dapat (dan biasanya harus)
dibuat untuk melihat kelas-kelas yang terlibat dalam suatu
sistem dan bagaimana mereka saling berhubungan satu sama
lain.
Selanjutnya, diagram komponen dapat dikembangkan untuk
menggambarkan bagaimana kelas-kelas dipetakan menjadi
komponen-komponen implementasi.
Terakhir, deployment diagram dapat juga dikembangkan untuk
melihat penyebaran komponen-komponen dalam jaringan
komputer yang ada untuk sistem/perangkat lunak yang
sedang kita kembangkan.
Beberapa Fungsi Dokumentasi :
Para pengembang dapat menggunakan diagram use case untuk mendapatkan pemahaman yang
komprehensif tentang sistem dan lingkungan luar yang melingkupi sistem.
Para calon penggunan dan manajer proyek dapat menggunakan diagram use case untuk mendapatkan
pandangan peringkat paling atas tentang sistem dan untuk menentukan persetujuan tentang lingkup
proyek.
Manajer proyek dapat menggunakan diagram use case untuk membagi sistem secara keseluruhan
menjadi bagian-bagian yang dapat dikelola secara seksama.
Calon pengguna dan analis sistem dapat melihat diagram use case untuk dapat memahami
fungsionalitas sistem yang diharapkan.
Para penulis teknik dapat melihat diagram use case untuk menulis panduan-panduan (manual) dan
merancang pelatihan-pelatihan.
Analis sistem dan para pengembang dapat melihat Sequence Diagram dan Collaboration Diagram untuk
memahami bagaimana logika sistem berjalan, objek-objek yang terlibat dalam suatu sistem, serta
pesan-pesan (message) yang dikirimkan suatu objek ke objek-objek lainnya.
Para penguji dapat menggunakan diagram use case, Sequence Diagram, serta Collaboration Diagram
untuk mendapatkan informasi-informasi yang dibutuhkan bagi langkah-langkah pengujian sistem.
Beberapa Fungsi Dokumentasi :
Para pengembang dapat menggunakan diagram kelas (Class
Diagram) dan Statechart Diagram untuk mendapatkan rincian
sistem dan bagaimana objek-objek berhubungan dan bekerja.
Para pengembang juga dapat menggunakan Componen Diagram
serta Deployment Diagramuntuk melihat bagaimana berkas-
berkas yang dapat dieksekusi langsung (misalnya file .EXE
dan .COM), berkas-berkas DLL, atau komponen-komponen
lain akan dibuat, dan dibagian mana dalam jaringan komputer
komponen-komponen itu akan diletakkan.
Para pengembang juga dapat menggunakan model-model
UML untuk melacak kode-kode pemrograman.
Sekilas Pemodelan Bisnis
Pemodelan bisnis adalah studi tentang organisasi/perusahaan.
Selama proses pemodelan bisnis, kita melakukan pemeriksaan
struktur organisasi/perusahaan dan bagaimana mereka saling
berhubungan.
Kita juga melakukan pemeriksaan pada aliran-aliran kerja
(workflow) dalam perusahaan, bagaimana mereka bekerja,
seberapa efektif mereka, dsb.
Selain itu, kita juga harus melakukan pemeriksaan-pemeriksaan
pada entitas-entitas diluar sistem, entah itu individu-individu atau
perusahaan lain, yang berinteraksi dengan perusahaan yang kita
kembangkan sistem/perangkat lunaknya, serta mencari implikasi-
implikasi dari interaksi-interaksi yang terjadi itu.
Use Case
Diagram
Use Case dan Aktor
Perbedaan Use Case pada model bisnis dan model sistem:
Use Case :
Model bisnis : mendeskripsikan apa yang dikerjakan perusahaan.
Model sistem : mendeskripsikan sistem yang akan/sedang dikembangkan
dalam perusahaan.
Aktor :
Model bisnis : bersifat eksternal terhadap perusahaan.
Model sistem : bersifat eksternal terhadap sistem yang akan/sedang
dikembangkan.
Pekerja bisnis :
Model bisnis : bersifat internal dalam perusahaan.
Model sistem : tidak digunakan.
Aktor
Aktor adalah seseorang atau sesuatu yang berinteraksi dengan
sistem yang sedang kita kembangkan.
Aktor berada diluar lingkup sistem/perangkat lunak yang
sedang kita kembangkan (bersifat eksternal).
3 jenis aktor :
1. Para pengguna sistem/perangkat lunak.
2. Sistem/perangkat lunak lain yang berinteraksi dengan
sistem/perangkat lunak yang akan kita kembangkan.
3. Waktu.
Penjelasan Jenis Aktor 1
Orang-orang yang hadir secara fisik, atau para pengguna.
Mereka adalah aktor yang paling umum dan hadir disetiap
sistem/perangkat lunak (untuk mengembangkan sistem yang
tidak ada penggunannya?).
Ex :
Menik dalam sistem informasi akademis peran yang berbeda
staf pengajar dan mahasiswa S3.
Penjelasan Jenis Aktor 2
Merupakan sistem lain diluar sistem yang ada.
Ex :
Sistem Informasi Akademis (perangkat lunak yang akan kita
kembangkan)berinteraksi langsung Sistem Akuntansi
Universitas, Sistem Penyediaan Saran dan Prasarana, dsb.
Penjelasan Jenis Aktor 3
Waktu menjadi aktor ketika ia memicu event-event tertentu
bagi sistem/perangkat lunak yang kita kembangkan.
Ex :
Jika kita tinjau sistem operasi Windows, yang akan
memunculkan screen saver setelah komputer yang bersangkutan
tidak menerima aksi apa-apa dari penggunannya selama
beberapa waktu tertentu.
Dalam hal ini, waktu yang memicu pemunculan screen saver
dapat dianggap sebagai aktor untuk sistem.
Use Case
Use Case adalah peringkat tertinggi dari fungsionalitas yang
dimiliki sistem.
Use Case menggambarkan bagaimana seseorang akan
menggunakan/memanfaatkan sistem.
Ex : Sistem Pemesanan Layanan Penerbangan.
Identifikasi use case terlebih dahulu apa yang akan
sistem/perangkat lunak kerjakan untuk memberi suatu nilai tambah
pada lingkungannya?
Misalkan, sistem/perangkat lunak memungkinkan para pengguna:
membeli karcis,
mengubah pemesanan,
serta membatalkan pemesanan.
3 hal yang mungkin terjadi diatas adalah kandidat kuat use case yang
baik bagi sistem kita.
Use Case Lanjutan...
Keunggulan dari cara memandang sistem sebagai kumpulan aktor
dan use case adalah kemampuannya untuk memisahkan
implementasi sistem dari alasan mengapa sistem harus
ada.
Ia akan membantu kita untuk berfokus pada apa yang paling
penting, yaitu menentukan apa yang dibutuhkan serta apa
harapan pengguna terhadap sistem/perangkat lunak
yang sedang dikembangkan, dan tidak terlalu mempedulikan
bagaimana kelak ia akan diimplementasikan.
Dengan melihat pada use case, para pengguna dapat melihat
fungsionalitas apa yang akan disediakan oleh sistem dan
menyetujui (atau menolak) lingkup sistem sebelum proyek
berjalan lebih jauh dan akan menghabiskan waktu dan biaya.
Menemukan Use Case
Dapat dimulai dengan memperhatikan setiap dokumentasi yang
pengguna siapkan.
Ex :
Mulai dari pernyataan-pernyataan visi dan misi organisasi/perusahaan.
Bertanya pada diri sendiri, apa saja yang diharapkan oleh para
pengguna dari sistem/perangkat lunak yang kita kembangkan.
Apa yang akan pengguna kerjakan dengan sistem yang akan
dikembangkan?
Apa yang para pengguna butuhkan untuk memelihara informasi-
informasi ?
Apakah yang perlu sistem lakukan saat terjadi event tertentu yang
datang dari luar sistem ?
Proses Kerja Use Case Sistem dan
Use Case Bisnis
Use Case bisnis cenderung merupakan peringkat yang sangat
tinggi.
Dalam suatu use case bisnis biasanya bisa kita dapatkan satu
atau lebih use case sistem.
Setelah use case sistem dapat ditelusuri hingga use case bisnis,
langkah berikutnya adalah melacak kebutuhan ke use case
sistem.
Use case sistem mendeskripsikan fungsionalitas yang
disediakan oleh sistem.
Aliran Event
Aliran event : rincian-rincian spesifik yang digunakan untuk
mendeskripsikan apa yang akan sistem kerjakan untuk secara nyata
mengembangkan sistem/perangkat lunak tersebut.
Fungsi aliran event : mendokumentasikan aliran-aliran logika
dalam setiap use case.
Dokumen ini akan medeskripsikan secara rinci apa yang akan
pengguna lakukan dan apa yang sistem/perangkat lunak itu sendiri
akan lakukan untuk menanggapi tindakan-tindakan pengguna
padanya.
Sasaran aliran event : mendekripsikan apa yang akan sistem
kerjakan dan bukan pada bagaimana sistem akan melakukannya.
Rincian use case biasanya dideskripsikan dalam bentuk :
Aliran aliran primer
Aliran aliran alternatif
Cakupan Aliran-Aliran Event Primer
dan Aliran-Aliran alternatif
Bagaimana use case berawal ?
Berbagai lintasan normal (primer) dalam use case.
Setiap penyimpangan (deviasi) dari aliran normal dalam
use case (aliran-aliran alternatif).
Setiap aliran kesalahan (exception atau error).
Bagaimana use case berakhir.
Contoh Kasus : Use Case
Pembelian Tiket
Aliran Normal (Primer)
1. Use Case berawal saat penumpang memilih pilihan-pilihan
informasi penerbangan.
2. Sistem akan memunculkan promp untuk menentukan kota asal
penumpang serta kota lain yang menjadi tujuannya.
3. Pengguna memasukkan asalnya serta tujuannya beserta tanggal
penerbangannya.
4. Sistem akan menampilkan daftar penerbangan yang tersedia. Kasus
pertama muncul disini, yaitu K1: Penerbangan yang diharapkan
tidak tersedia.
5. Penumpang memilih penerbangan yang akan dipesan.
6. Sistem memunculkan jumlah uang yang harus dibayarkan
penumpang.
7. Sistem memunculkan prompt untuk jenis kartu kredit, nomor,
nama, serta tanggal kadaluarsa.
Contoh Kasus : Use Case
Pembelian Tiket
Aliran Normal (Primer)
8. Pengguna memasukkan jenis kartu kredit, nomor, nama,
serta tanggal kadaluarsa.
9. Sistem akan memunculkan informasi-informasi kartu kredit.
Disini akan muncul 3 kasus yang mungkin, yaitu: K2:
Rekening tidak sah, K3: Dana yang ada tidak
mencukupi serta K4: Sistem kredit tidak dapat diakses.
10. Sistem akan menghasilkan pemesanan kursi pesawat untuk
penumpang.
11. Sistem akan menghasilkan dan menampilkan kode kursi
penumpang.
12. Penumpang akan menerima tiket dan kode kursi.
13. Use Case berakhir.
Contoh Kasus : Use Case
Pembelian Tiket
Aliran-aliran alternatif :
K1: Penerbangan yang Diharapkan Tidak Tersedia
1. Sistem akan menampilkan pesan bahwa tidak ada penerbangan yang
tersedia untuk kota-kota asal dan kota-kota tujuan, tanggal pemberangkatan,
serta tanggal tiba.
2. Pengguna mengkonfirmasi pesan.
3. Aliran kembali ke aliran primer (langkah 2)
K2 : Rekening Tidak Sah
1. Sistem akan memunculkan bahwa kartu kredit yang dimiliki penumpang
tidak sah.
2. Aliran kembali ke aliran primer (langkah 8).
3. Jika sampai 3 kali aliran 2 tidak dapat berlangsung dengan baik, munculkan
pesan konfirmasi bahwa penumpang tidak dapat memesan tiket yang
diharapkannya.
4. Kembali ke aliran primer (langkah 2).
Contoh Kasus : Use Case
Pembelian Tiket
Aliran-aliran alternatif :
K3: Dana yang Ada Tidak Mencukupi
1. Sistem akan memunculkan pesan bahwa dana yang dimiliki penumpang
tidak mencukupi untuk melakukan transaksi pemesanan tiket.
2. Aliran kembali ke aliran primer (langkah 2).
K4: Sistem Kredit Tak Dapat Diakses.
1. Sistem akan menampilkan pesan bahwa sistem kredit tidak dapat
diakses.
2. Aliran kembali ke aliran primer (langkah 8).
3. Jika sampai 3 kali aliran 2 tidak dapat berlangsung dengan baik,
munculkan pesan konfirmasi bahwa penumpang tidak dapat memesan
tiket yang diharapkannya.
4. Kembali ke aliran primer (langkah 2).
Relasi
Fungsi relasi : menghubungkan Use Case dan aktor.
Relasi dalam model UML :
Relasi Asosiasi : relasi yang terjadi antara aktor dengan use case.
Asosiasi digambarkan dengan garis lurus dengan kepala panah disalah satu ujungnya.
Relasi Cakupan (include relationship) : memungkinkan suatu use case untuk menggunakan
fungsionalitas yang disediakan oleh use case lainnya.
Ex: jika dua atau lebih use case memiliki sejumlah besar fungsi yang identik, fungsionalitas-
fungsionalitas yang sama ini dapat dipisahkan menjadi use case tersendiri.
Masing-masing use case yang lain dapat memiliki include relationship dengan use case yang
baru.
Relasi Perluasan (extends relationship)
Memungkin suatu use case memiliki kemungkinan untuk memperluas fungsionalitas yang
disediakan use case yang lainnya.
Ini agak mirip dengan include relationship namun pada extend relationship tidak harus
terjadi apa yang diharapkan.
Relasi Generalisasi : memperlihatkan bahwa beberapa aktor atau use case memiliki sesuatu hal
yang bersifat umum.
Ex : Penumpang bisa dibedakan menjadi penumpang pribadi dan penumpang perusahaan
yang mungkin bisa dibedakan lagi menjadi perusahaan pribadi dan pemerintah.