Pengertian UML, Metode Penggunaan, dan Activity Use Case Diagram
Pengertian UML (Unified Modelling Language), Metode Penggunaan, Jenis Diagram UML, dan Activity Use Case Diagram Menurut Para Ahli - Unified Modelling Language (UML) adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain system perangkat lunak, khususnya system yang dibangun menggunakan pemrograman berorientasi objek (OO).
UML merupakan standar yang relatif terbuka yang dikontrol oleh Object Management Group (OMG), sebuah konsorsium terbuka yang terdiri dari banyak perusahaan.OMG dibentuk untuk membuat standar-standar yang menukung interoperabilitas, khususnya interoperabilitas system berorientasi objek.OMG mungkin lebih dikenal dengan standar-standar CORBA (Common Object Request Broker Architecture).
UML lahir dari penggabungan banyak bahasa pemodelan grafis berorientasi objek yang berkembang pesat pada akhir tahun 1980-an dan awal tahun 1990-an. Sejak kehadirannya pada tahun 1997, UML menghancurkan menara Babel tersebut menjadi sejarah.
METODE PENGGUNAAN UML
Martin Fowler dan Steve Mellor menggolongkan tiga cara/metode menggunakan UML:
UML sebagai sketsa
Dengan sketsa, developer menggunakan UML untuk membantu menyampaikan beberpa aspek dari sebuah system. Sketsa dapat dibuat dalam bentuk forward engineering atau reverse engineering. Forward engineering menggambar sebuah diagram UML sebelum membuat kode,
UML sebagai blueprint
Penggunaan UML sebagai blueprint menyampai-kan suatu keutuhan.Seperti halnya sketsa, blueprint juga bisa disajikan dalam sebuah forward engineering maupun dalam reverse engineering.Dalam forward engineering, blueprint dibuat oleh seorang desainer yang pekerjaannya membuat desain yang detail untuk dikodekan oleh seorang programmer.Desain tersebut harus cukup lengkap, daam artian seluruh keputusan desain telah dijabarkan dan programmer harus dapat mengikutinya secara langsung tanpa perlu berpikir keras. Desainer bisa jadi orang yang sama dengan programmer, tetapi biasanya desainer adalah developer yang lebih senior yang mendesain untuk sebuah tim programmer.
Dalam reverse engineering, blueprint bertujuan untuk menyampaikan informasi detail tentang kode baik dalam bentuk okumen cetak atau sebagai browser grafis interaktif. Blueprint dapat menunjukan setiap detail sebuah class dalam sebuah bentuk grafis yang memudahkan developer dalam memahaminya.
Blueprint membutuhkan piranti yang lebih canggih dari pada yang dibutuhkan sketsa untuk menangani detailnya.Piranti forward engineering mendukung penggambaran diagram dan menyimpannya dalam suatu tempat untuk menyimpan informasi.Piranti reverse engineering membaca source code dan menginterpretasinya untuk dimasukan ke dalam ruang penyimpanan, lalu membuat diagram. Piranti yang dapat melakukan kedua engineering tersebut, baik forward maupun reverse, disebut piranti roundtrip.
Beberapa piranti menggunakan source code sebagai tempat penyimpanan dan menggunakan diagram sebagai penggambaran kode. Piranti-piranti ini sangat terkait dengan pemrograman dan acap kali berintegrasi secara langsung dengan editor pemrograman.
Batas yang memisahkan blueprint dan sketsa sebenarnya kabur, tetapi perbedaannya terletak pada fakta bahwa sketsa dibuat tidak lengkap, hanya menunjukan informasi penting, sedangkan blueprint cenderung komprehensif dan acapkali bertujuan meringkas pemrograman menjadi aktivitas yang simple dan sedikit mekanis. Dengan kata lain, sketsa bersifat eksploratif sedangkan blueprint bersifat definitive.
UML sebagai bahasa pemrograman
Salah satu pertanyaan menarik tentang UML sebagai bahasa pemrograman adalah tentang bagaimana memodelkan logika behavioral. UML 2 menawarkan tiga cara untuk pemodelan behavior: interaction diagram, state diagram, dan activity diagram.
Notasi dan Meta-Model
UML, dalam posisinya saat ini membedkan notasi dan meta-model.Notasi adalah grafik yang Anda lihat di model, merupakan sintaks grafis dari bahasa pemodelan.Contohnya, notasi class diagram menentukan bagaimana pokok-pokok dan konsep, seperti class, association, dan multiplicity digambarkan.
Kebanyakan bahasa p[emodelan grafis memiliki sedikit detail, notasi mereka cenderung berupa intuisi dari pada definisi formal. Metode-metode ini sebenarnya informal, tetapi banyak orang yang menganggap mereka berguna – dan kegunaan inilah yang paling penting.Akan tetapi para metodologis berusaha mencari cara-cara untuk memperbaiki detail metode ini tanpa mengorbankan kegunaannya. Salah satu cara melakukannya adalah dengan mendefinisikan meta-model sebuah diagram, biasanya class diagram, yang mendefinisikan konsep bahasa tersebut.
Gambar 1 memperlihatkan sebagian kecil meta-model UML, menunjukan hubungan antar fitur.Banyak orang yang terlibat dalam perkembangan UML hanya tertarik pada meta-model, khususnya karena hal ini penting dalam penggunaan UML dan sebagai bahasa pemrograman.
DIAGRAM-DIAGRAM UML
UML 2 terdiri dari 13 jenis diagram resmi seperti tertulis dalam Table 1 dan mengklasifikasi mereka seperti pada Gambar 2. Jenis-jenis diagram bukanlah hal yang mutlak. Acapkali secara legal seseorang dapat menggunakan elemen-elemen dari satu jenis diagram untuk diagram yang lain.
Tabel 1. Jenis diagrm resmi UML
ACTIVITY DIAGRAM
Activity diagram adalah teknik untuk menggambarkan logika prosedural, proses bisnis, dan jalur kerja. Dalam beberapa hal, diagram ini memainkan peran mirip sebuah diagram alir, tetapi perbedaan prinsip antara diagram ini dan notasi diagram alir adalah diagram ini mendukung behavior parallel.
Dalam UML 1, activity diagram dianggap sebagai kasus khusus state diagram. Dalam UML 2, activity diagram telah dikembangkan sehingga menjadi diagram yang benar-benar berdiri sendiri, tidak ditemukan lagi keterikatan dengan state diagram.
Gambar 3 memperlihatkan sebuah contoh sederhana dari sebuah activity diagram.Kita mulai pada node action awal dan kemudian melakukan action Menerima Pesanan.Sekali kita melakukan-nya, kita mendapatkan percabangan.Sebuah percabangan memiliki satu aliran masuk dan beberapa aliran keluar.Gambar 3 menjelaskan bahwa Mengisi Pesanan, Mengirim Invoice, dan action setelahnya dilakukan secara parallel. Pada dasarnya, hal ini berarti bahwa rangkaian-rangkaian antara mereka tidak saling berkaitan.
Activity diagram memungkinkan siapapun yang melakukan proses untuk memilih urutan dalam melakukannya. Dengan kata lain, diagram hanya menyebutkan aturan-aturan rangkaian dasar yang harus kita ikuti.Hal ini penting untuk pemodelan bisnis karena proses-proses sering muncul secara parallel.Ini juga berguna pada algoritma yang bersamaan, di mana urutan-urutan independent dapat melakukan hal-hal secara parallel.
UML 1 mempunyai aturan-aturan tertentu untuk menyeimbangkan percabangan dan join karena activity diagram merupakan kasus khusus di state diagram. Dengan UML 2, penyeimbangan tersebut tidak lagi diperlukan. Kita akan menemukan bahwa node pada sebuah activity diagram disebut sebagai action, bukan activity. Jelasnya, activity mengacu pada serangkaian action, sehingga diagram tersebut menampilkan sebuah activity yang tersusun dari action.
Behavior kondisional dilukiskan oleh keputusan dan merge. Sebuah keputusan, disebut cabang di UML 1, memiliki sebuah aliran masuk tunggal dan beberapa aliran keluar. Setiap aliran keluar memiliki sebuah penjaga: sebuah kondisi Boolean yang diletakkan di dalam tanda kurung kotak. Setiap saat kita sampai pada sebuah keputusan, kita hanya dapat mengambil satu aliran keluar, jadi penjaga harus sama-sama eksklusif.Penggunaan [else] sebagai sebuah penjaga menunjukkan bahwa aliran [else] harus digunakan jika seluruh penjaga di keputusan tersebut bernilai false.
Sebuah penggabungan memiliki banyak aliran input dan sebuah output tunggal. Sebuah penggabungan menandai berakhirnya behavior kondisional yang dimulai oleh sebuah keputusan.
Memecah Sebuah Action
Action dapat dipecah ke dalam subactivity.Action dapat digunakan baik sebagai subactivity maupun sebagai metode pada class.Kita dapat menampilkan sebuah subactivity dengan menggunakan symbol penggaruk.Kita dapat menampilkan panggilan pada sebuah metode dengan sintaks class_name::method_name. Kita juga dapat menulis sebuah potongan kode ke dalam symbol action jika behavior yang digunakan bukan panggilan metode tunggal.
Kita dapat mengambil logika pengiriman pada Gambar 3 dan menjabarkannya sesuai dengan activity mereka, seperti diperlihatkan pada Gambar 4. Kemudian kita akan memanggilnya sebagai sebuah action, seperti yang diperlihatkan pada Gambar 5.
Partisi
Diagram aktivitas (activity diagram) memberi tahu kita tentang apa yang terjadi, tetapi diagram ini tidak memberi tahu kita tentang siapa yang melakukan apa. Dalam konteks pemrograman, hal ini berarti diagram tidak tidak menyampaikan class mana yang bertanggung jawab untuk setiap action. Dalam konteks pemodelan proses bisnis, hal ini tidak menyampaikan bagian mana dari sebuah organisasi yang melakukan action apa. Hal ini tidak menjadi masalah, sering lebih masuk akal untuk berkonsentrasi pada apa yang telah dilakukan dari pada siapa melakukan bagian apa dari behavior tersebut.
Gambar 6.memperlihatkan pembuatan partisi sederhana (dari Gambar 3) satu dimensi. Model ini sering disebut sebagai swim lanes, karena seperti jalur berenang dan merupakan satu-satunya bentuk yang digunakan di UML 1. Di UML 2, kita dapat menggunakan jaringan dua dimensi, di mana metafora berenang sudah tidak lagi berada di air. Kita juga dapat menggunakan setiap dimensi dan memisahkan baris dan kolom secara hirarkis.
USE CASE DIAGRAM
Use case adalah teknik untuk merekam persyaratan fungsional sebuah system. Use case mendeskripsi-kan interaksi tipikal antara para pengguna sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana system tersebut digunakan. Jika kita simak kembali pembahasan pada SAP 10 tentang use case, kita akan mendapatkan bahwa terdapat dua hal (atau istilah) yang tidak dapat dipisahkan dari use case, yakni scenario dan aktor.Skenario adalah rangkaian langkah-langkah yang menjabarkan sebuah interaksi antara seorang pengguna dengan sebuah system.Berikut adalah sebuah contoh bagaimana scenario dijalankan. Jika kita memiliki sebuah toko on line berbasis Web, kita memiliki scenario Buy a Product yang akan seperti ini:
Pelanggan melihat-lihat katalog dan menam-bahkan barang-barang yang diinginkan ke dalam keranjang belanja.Pada saat pelanggan tersebut ingin membayar, pelanggan menjabarkan tentang informasi pengiriman barang dan kartu kredit serta mengkonfirmasi transaksi. Sistem kemudian memeriksa otorisasi pada kartu kredit lalu mengkonfir-masi transaksi secara langsung dan mengi-rimkan sebuah e-mail tindak lanjut.
Skenario ini adalah salah satu yang dapat terjadi.Meskipun demikian, otorisasi kartu kredit dapat juga gagal. Dan ini akan menjadi scenario yang berbeda. Tentu masih banyak scenario lain yang bisa dan mungkin terjadi. Namun kita menemukan kenyataan bahwa seluruh scenario ini berbeda tetapi mirip satu sama lain. Inti persamaan mereka adalah pengguna mempunyai tujuan yang sama: yakni untuk membeli sebuah produk. Pengguna tersebut tidak selalu berhasil, tetapi tujuannya tetap sama. Tujuan pengguna tersebut merupakan kunci use case: sebuah use case adalah serangkaian scenario yang dikemas menjadi satu oleh tujuan pengguna umum.
Dalam use case, para pengguna disebut sebagai aktor. Aktor merupakan sebuah peran yang diamainkan seorang pengguna dalam kaitannya dengan system.Aktor dapat meliputi pelanggan, petugas layanan konsumen, manajer penjualan, dan analis produk. Seorang aktor dapat menggunakan banyak use case, sebaliknya, sebuah use case juga dapat digunakan oleh beberapa aktor.
Kandungan Use Case
Gambar 21-1 memperlihatkan sebuah model yang umum digunakan untuk menuliskan kandungan atau isi use case. Kita mulai dengan mengambil salah satu scenario sebagai scenario keberhasilan utama (MSS – main success scenario). Kita membuat isi use case dengan menuliskan scenario keberhasilan utama sebagai serangkaian langkah-langkah bernomor. Kemudian ambil scenario lain dan tulis mereka sebagai ekstensi, jabarkan mereka sebagai variasi scenario keberhasilan utama. Ekstensi-ekstensi tersebut dapat berupa keberhasilan – pengguna mencapai keberhasilan, seperti pada 3a – atau kegagalan, seperti pada 6a.
Setiap use case memiliki aktor utama yang meminta system untuk memberi sebuah layanan. Aktor utama adalah aktor dengan tujuan yang akan dipenuhi use case dan biasanya, tetapi tidak selalu, merupakan inisiator use case. Selain itu terdapat banyak aktor lain yang berkomunikasi dengan system pada saat menjalankan use case. Mereka dikenal sebagai aktor sekunder.Setiap langkah dalam use case adalah sebuah elemen dalam interaksi antara aktor dan system.
Contoh Teks Use Case:
-----------------------------------------------------------------------------------
Pembelian Sebuah Produk
Tingkat Tujuan: Sea Level
Skenario Keberhasilan Utama:
3a: Konsumen adalah langganan
.1: Sistem menampilkan informasi pengiriman barang, harga, dan tagihan saat ini
.2: Pelanggan dapat menerima atau menghi-raukan default ini, kembali ke MSS di langkah 6
6a: Sistem gagal meng-otorisasi pembelian kredit
.1: Pelanggan dapat memasukkan kembali informasi kartu kredit atau membatalkan
-----------------------------------------------------------------------------------
Setiap langkah harus berupa pernyataan sederhana dan dengan jelas menunjukkan siapa yang menjalankan langkah tersebut.Langkah tersebut harus menunjukkan tujuan aktor, bukan mekanisme yang harus dilakukanaktor.Konsekuensinya, kita tidak menjabarkan antarmuka pengguna dalam use case.
Sebuah akstensi dalam sebuah use case menyebutkan sebuah kondisi yang menghasilkan interaksi berbeda dari yang disebutkan dalam MSS dan menyebutkan apa perbedaannya. Mulailah sebuah ekstensi dengan menunjuk langkah di mana kondisi tersebut terdeteksi dan sediakan sebuah gambaran singkat tentang kondisi tersebut. Urutkan kondisi tersebut dengan langkah-langkah bernomor menggunakan model yang sama dengan MSS. Akhiri langkah-langkah ini dengan menjelaskan di mana kita kembali ke MSS, jika kita melakukannya.
Seperti halnya langkah-langkah dalam scenario, kita dapat menambah beberapa informasi umum lain pada sebuah use case.
DIAGRAM USE CASE
UML tidak menjelaskan isi sebuah use case tetapi menyediakan sebuah bentuk diagram untuk menampilkannya, seperti diperlihatkan pada Gambar 21-2. Meskipun diagram sering berguna, ini bukanlah suatu keharusan. Dalam pengolahan use case, jangan terlalu memperhatikan diagram. Sebaliknya, berkosentrasilah pada isi tekstual use case tersebut. Diagram use case hanya menampil-kan aktor, use case, dan hubungan antara mereka:
Tingkatan-Tingkatan Use Case
Sebuah use case dapat terdiri dari beberapa tingkatan. Inti use case berada pada tingkat sea level. Use case sea level khususnya mewakili sebuah interaksi diskrit antara aktor utama dan system. Use case semacam ini akan memberikan nilai pada aktor utama dan biasanya memberi waktu beberapa menit sampai setengah jam bagi aktor utama untuk menyelesaikan. Use case yang ada di sana hanya karena mereka dimasukkan oleh use case sea level adalah fish level. Lebih tinggi, use case kite level menampilkan bagaimana use case sea level sesuai dengan interaksi bisnis yang lebih luas. Use case kite level biasanya merupakan use case bisnis, sedangkan use case sea dan fish level merupakan use case system. Kebanyakan use case berada pada tingkatan sea level.
Sekian artikel tentang Pengertian UML (Unified Modelling Language), Metode Penggunaan, Jenis Diagram UML, dan Activity Use Case Diagram Menurut Para Ahli. Semoga bermanfaat.
Daftar Pustaka
UML merupakan standar yang relatif terbuka yang dikontrol oleh Object Management Group (OMG), sebuah konsorsium terbuka yang terdiri dari banyak perusahaan.OMG dibentuk untuk membuat standar-standar yang menukung interoperabilitas, khususnya interoperabilitas system berorientasi objek.OMG mungkin lebih dikenal dengan standar-standar CORBA (Common Object Request Broker Architecture).
UML lahir dari penggabungan banyak bahasa pemodelan grafis berorientasi objek yang berkembang pesat pada akhir tahun 1980-an dan awal tahun 1990-an. Sejak kehadirannya pada tahun 1997, UML menghancurkan menara Babel tersebut menjadi sejarah.
METODE PENGGUNAAN UML
Martin Fowler dan Steve Mellor menggolongkan tiga cara/metode menggunakan UML:
- Sketsa
- Blueprint
- Bahasa pemrograman
UML sebagai sketsa
Dengan sketsa, developer menggunakan UML untuk membantu menyampaikan beberpa aspek dari sebuah system. Sketsa dapat dibuat dalam bentuk forward engineering atau reverse engineering. Forward engineering menggambar sebuah diagram UML sebelum membuat kode,
- Identify, Yaitu mengidentifikasikan masalah
- Mengindentifikasikan penyebab masalah
- Mengidentifikasikan titik keputusan
- Mengidentifikasikan personil-personil kunci
- Understand, Yaitu memahami kerja dari sistem yang ada
- Menentukan jenis penelitian
- Merencanakan jadual penelitian
- Mengatur jadual wawancara
- Mengatur jadual observasi
- Mengatur jadual pengambilan sampel
- Membuat penugasan penelitian
- Membuat agenda wawancara
- Mengumpulkan hasil penelitian
- Analyze, Yaitu Menganalis Sistem
- Menganalisis kelemahan Sistem
- Menganalisis kebutuhan Informasi pemakai / manajemen
- Report, Yaitu membuat laporan hasil analisis
- Pelaporan bahwa analisis telah selesai dilakukan
- Meluruskan kesalah-pengertian mengenai apa yang telah ditemukan dan dianalisis oleh analis sistem tetapi tidak sesuai menurut manajemen
- Meminta pendapat-pendapat dan saran-saran dari pihak manajemen
Meminta persetujuan kepada pihak manajemen untuk melakukan tindakan selan-jutnya.
 |
| image source: |
baca juga:
Penggunaan UML sebagai blueprint menyampai-kan suatu keutuhan.Seperti halnya sketsa, blueprint juga bisa disajikan dalam sebuah forward engineering maupun dalam reverse engineering.Dalam forward engineering, blueprint dibuat oleh seorang desainer yang pekerjaannya membuat desain yang detail untuk dikodekan oleh seorang programmer.Desain tersebut harus cukup lengkap, daam artian seluruh keputusan desain telah dijabarkan dan programmer harus dapat mengikutinya secara langsung tanpa perlu berpikir keras. Desainer bisa jadi orang yang sama dengan programmer, tetapi biasanya desainer adalah developer yang lebih senior yang mendesain untuk sebuah tim programmer.
Dalam reverse engineering, blueprint bertujuan untuk menyampaikan informasi detail tentang kode baik dalam bentuk okumen cetak atau sebagai browser grafis interaktif. Blueprint dapat menunjukan setiap detail sebuah class dalam sebuah bentuk grafis yang memudahkan developer dalam memahaminya.
Blueprint membutuhkan piranti yang lebih canggih dari pada yang dibutuhkan sketsa untuk menangani detailnya.Piranti forward engineering mendukung penggambaran diagram dan menyimpannya dalam suatu tempat untuk menyimpan informasi.Piranti reverse engineering membaca source code dan menginterpretasinya untuk dimasukan ke dalam ruang penyimpanan, lalu membuat diagram. Piranti yang dapat melakukan kedua engineering tersebut, baik forward maupun reverse, disebut piranti roundtrip.
Beberapa piranti menggunakan source code sebagai tempat penyimpanan dan menggunakan diagram sebagai penggambaran kode. Piranti-piranti ini sangat terkait dengan pemrograman dan acap kali berintegrasi secara langsung dengan editor pemrograman.
Batas yang memisahkan blueprint dan sketsa sebenarnya kabur, tetapi perbedaannya terletak pada fakta bahwa sketsa dibuat tidak lengkap, hanya menunjukan informasi penting, sedangkan blueprint cenderung komprehensif dan acapkali bertujuan meringkas pemrograman menjadi aktivitas yang simple dan sedikit mekanis. Dengan kata lain, sketsa bersifat eksploratif sedangkan blueprint bersifat definitive.
UML sebagai bahasa pemrograman
Salah satu pertanyaan menarik tentang UML sebagai bahasa pemrograman adalah tentang bagaimana memodelkan logika behavioral. UML 2 menawarkan tiga cara untuk pemodelan behavior: interaction diagram, state diagram, dan activity diagram.
Notasi dan Meta-Model
UML, dalam posisinya saat ini membedkan notasi dan meta-model.Notasi adalah grafik yang Anda lihat di model, merupakan sintaks grafis dari bahasa pemodelan.Contohnya, notasi class diagram menentukan bagaimana pokok-pokok dan konsep, seperti class, association, dan multiplicity digambarkan.
Kebanyakan bahasa p[emodelan grafis memiliki sedikit detail, notasi mereka cenderung berupa intuisi dari pada definisi formal. Metode-metode ini sebenarnya informal, tetapi banyak orang yang menganggap mereka berguna – dan kegunaan inilah yang paling penting.Akan tetapi para metodologis berusaha mencari cara-cara untuk memperbaiki detail metode ini tanpa mengorbankan kegunaannya. Salah satu cara melakukannya adalah dengan mendefinisikan meta-model sebuah diagram, biasanya class diagram, yang mendefinisikan konsep bahasa tersebut.
 |
| Gambar 1. Sebagian kecil meta-model UML |
Gambar 1 memperlihatkan sebagian kecil meta-model UML, menunjukan hubungan antar fitur.Banyak orang yang terlibat dalam perkembangan UML hanya tertarik pada meta-model, khususnya karena hal ini penting dalam penggunaan UML dan sebagai bahasa pemrograman.
DIAGRAM-DIAGRAM UML
UML 2 terdiri dari 13 jenis diagram resmi seperti tertulis dalam Table 1 dan mengklasifikasi mereka seperti pada Gambar 2. Jenis-jenis diagram bukanlah hal yang mutlak. Acapkali secara legal seseorang dapat menggunakan elemen-elemen dari satu jenis diagram untuk diagram yang lain.
Tabel 1. Jenis diagrm resmi UML
| Diagram | Kegunaan | Turunan |
| Activity | Behavioral prosedural dan paralel | UML 1 |
| Class | Class, fitur, dan hubungan-hubungan | UML 1 |
| Communication | Interaksi antar objek; Penekanan pada jalur |
Diagram kolaborasi UML 1 |
| Component | Struktur dan koneksi komponen | UML 1 |
| Composite Structure | Dekomposisi runtime sebuah class | Baru UML 2 |
| Deployment | Pemindahan artifak ke Node |
UML 1 |
| Interaction overview | Campuran sequence dan activity diagram | Baru UML 2 |
| Object | Contoh konfigurasi dari contoh-contoh | Tidak resmi UML 1 |
| Package | Struktur hirarki Compile-time |
Tidak resmi UML 1 |
| Sequence | Interaksi antar objek; Penekanan pada sequen |
UML 1 |
| State machine | Bagaimana event me-ngubah objek selama aktif | UML 1 |
| Timing | Interaksi antar objek; Penekanan pda timing |
Baru UML 2 |
| Use Case | Bagaimana pengguna berinteraksi dengan sebuah system | UML 1 |
 |
| Gambar 2. Klasifikasi jenis diagram UML |
ACTIVITY DIAGRAM
Activity diagram adalah teknik untuk menggambarkan logika prosedural, proses bisnis, dan jalur kerja. Dalam beberapa hal, diagram ini memainkan peran mirip sebuah diagram alir, tetapi perbedaan prinsip antara diagram ini dan notasi diagram alir adalah diagram ini mendukung behavior parallel.
Dalam UML 1, activity diagram dianggap sebagai kasus khusus state diagram. Dalam UML 2, activity diagram telah dikembangkan sehingga menjadi diagram yang benar-benar berdiri sendiri, tidak ditemukan lagi keterikatan dengan state diagram.
Gambar 3 memperlihatkan sebuah contoh sederhana dari sebuah activity diagram.Kita mulai pada node action awal dan kemudian melakukan action Menerima Pesanan.Sekali kita melakukan-nya, kita mendapatkan percabangan.Sebuah percabangan memiliki satu aliran masuk dan beberapa aliran keluar.Gambar 3 menjelaskan bahwa Mengisi Pesanan, Mengirim Invoice, dan action setelahnya dilakukan secara parallel. Pada dasarnya, hal ini berarti bahwa rangkaian-rangkaian antara mereka tidak saling berkaitan.
 |
| Gambar 3. Sebuah activity diagram sederhana |
Activity diagram memungkinkan siapapun yang melakukan proses untuk memilih urutan dalam melakukannya. Dengan kata lain, diagram hanya menyebutkan aturan-aturan rangkaian dasar yang harus kita ikuti.Hal ini penting untuk pemodelan bisnis karena proses-proses sering muncul secara parallel.Ini juga berguna pada algoritma yang bersamaan, di mana urutan-urutan independent dapat melakukan hal-hal secara parallel.
UML 1 mempunyai aturan-aturan tertentu untuk menyeimbangkan percabangan dan join karena activity diagram merupakan kasus khusus di state diagram. Dengan UML 2, penyeimbangan tersebut tidak lagi diperlukan. Kita akan menemukan bahwa node pada sebuah activity diagram disebut sebagai action, bukan activity. Jelasnya, activity mengacu pada serangkaian action, sehingga diagram tersebut menampilkan sebuah activity yang tersusun dari action.
Behavior kondisional dilukiskan oleh keputusan dan merge. Sebuah keputusan, disebut cabang di UML 1, memiliki sebuah aliran masuk tunggal dan beberapa aliran keluar. Setiap aliran keluar memiliki sebuah penjaga: sebuah kondisi Boolean yang diletakkan di dalam tanda kurung kotak. Setiap saat kita sampai pada sebuah keputusan, kita hanya dapat mengambil satu aliran keluar, jadi penjaga harus sama-sama eksklusif.Penggunaan [else] sebagai sebuah penjaga menunjukkan bahwa aliran [else] harus digunakan jika seluruh penjaga di keputusan tersebut bernilai false.
Sebuah penggabungan memiliki banyak aliran input dan sebuah output tunggal. Sebuah penggabungan menandai berakhirnya behavior kondisional yang dimulai oleh sebuah keputusan.
Memecah Sebuah Action
Action dapat dipecah ke dalam subactivity.Action dapat digunakan baik sebagai subactivity maupun sebagai metode pada class.Kita dapat menampilkan sebuah subactivity dengan menggunakan symbol penggaruk.Kita dapat menampilkan panggilan pada sebuah metode dengan sintaks class_name::method_name. Kita juga dapat menulis sebuah potongan kode ke dalam symbol action jika behavior yang digunakan bukan panggilan metode tunggal.
Kita dapat mengambil logika pengiriman pada Gambar 3 dan menjabarkannya sesuai dengan activity mereka, seperti diperlihatkan pada Gambar 4. Kemudian kita akan memanggilnya sebagai sebuah action, seperti yang diperlihatkan pada Gambar 5.
 |
| Gambar 4. Sebuah Activity Diagram Tambahan |
Partisi
Diagram aktivitas (activity diagram) memberi tahu kita tentang apa yang terjadi, tetapi diagram ini tidak memberi tahu kita tentang siapa yang melakukan apa. Dalam konteks pemrograman, hal ini berarti diagram tidak tidak menyampaikan class mana yang bertanggung jawab untuk setiap action. Dalam konteks pemodelan proses bisnis, hal ini tidak menyampaikan bagian mana dari sebuah organisasi yang melakukan action apa. Hal ini tidak menjadi masalah, sering lebih masuk akal untuk berkonsentrasi pada apa yang telah dilakukan dari pada siapa melakukan bagian apa dari behavior tersebut.
 |
| Gambar 5. Modifikasi Gambar 3. |
 |
| Gambar 6. Partisi pada Activity Diagram |
Gambar 6.memperlihatkan pembuatan partisi sederhana (dari Gambar 3) satu dimensi. Model ini sering disebut sebagai swim lanes, karena seperti jalur berenang dan merupakan satu-satunya bentuk yang digunakan di UML 1. Di UML 2, kita dapat menggunakan jaringan dua dimensi, di mana metafora berenang sudah tidak lagi berada di air. Kita juga dapat menggunakan setiap dimensi dan memisahkan baris dan kolom secara hirarkis.
USE CASE DIAGRAM
Use case adalah teknik untuk merekam persyaratan fungsional sebuah system. Use case mendeskripsi-kan interaksi tipikal antara para pengguna sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana system tersebut digunakan. Jika kita simak kembali pembahasan pada SAP 10 tentang use case, kita akan mendapatkan bahwa terdapat dua hal (atau istilah) yang tidak dapat dipisahkan dari use case, yakni scenario dan aktor.Skenario adalah rangkaian langkah-langkah yang menjabarkan sebuah interaksi antara seorang pengguna dengan sebuah system.Berikut adalah sebuah contoh bagaimana scenario dijalankan. Jika kita memiliki sebuah toko on line berbasis Web, kita memiliki scenario Buy a Product yang akan seperti ini:
Pelanggan melihat-lihat katalog dan menam-bahkan barang-barang yang diinginkan ke dalam keranjang belanja.Pada saat pelanggan tersebut ingin membayar, pelanggan menjabarkan tentang informasi pengiriman barang dan kartu kredit serta mengkonfirmasi transaksi. Sistem kemudian memeriksa otorisasi pada kartu kredit lalu mengkonfir-masi transaksi secara langsung dan mengi-rimkan sebuah e-mail tindak lanjut.
Skenario ini adalah salah satu yang dapat terjadi.Meskipun demikian, otorisasi kartu kredit dapat juga gagal. Dan ini akan menjadi scenario yang berbeda. Tentu masih banyak scenario lain yang bisa dan mungkin terjadi. Namun kita menemukan kenyataan bahwa seluruh scenario ini berbeda tetapi mirip satu sama lain. Inti persamaan mereka adalah pengguna mempunyai tujuan yang sama: yakni untuk membeli sebuah produk. Pengguna tersebut tidak selalu berhasil, tetapi tujuannya tetap sama. Tujuan pengguna tersebut merupakan kunci use case: sebuah use case adalah serangkaian scenario yang dikemas menjadi satu oleh tujuan pengguna umum.
Dalam use case, para pengguna disebut sebagai aktor. Aktor merupakan sebuah peran yang diamainkan seorang pengguna dalam kaitannya dengan system.Aktor dapat meliputi pelanggan, petugas layanan konsumen, manajer penjualan, dan analis produk. Seorang aktor dapat menggunakan banyak use case, sebaliknya, sebuah use case juga dapat digunakan oleh beberapa aktor.
Kandungan Use Case
Gambar 21-1 memperlihatkan sebuah model yang umum digunakan untuk menuliskan kandungan atau isi use case. Kita mulai dengan mengambil salah satu scenario sebagai scenario keberhasilan utama (MSS – main success scenario). Kita membuat isi use case dengan menuliskan scenario keberhasilan utama sebagai serangkaian langkah-langkah bernomor. Kemudian ambil scenario lain dan tulis mereka sebagai ekstensi, jabarkan mereka sebagai variasi scenario keberhasilan utama. Ekstensi-ekstensi tersebut dapat berupa keberhasilan – pengguna mencapai keberhasilan, seperti pada 3a – atau kegagalan, seperti pada 6a.
Setiap use case memiliki aktor utama yang meminta system untuk memberi sebuah layanan. Aktor utama adalah aktor dengan tujuan yang akan dipenuhi use case dan biasanya, tetapi tidak selalu, merupakan inisiator use case. Selain itu terdapat banyak aktor lain yang berkomunikasi dengan system pada saat menjalankan use case. Mereka dikenal sebagai aktor sekunder.Setiap langkah dalam use case adalah sebuah elemen dalam interaksi antara aktor dan system.
Contoh Teks Use Case:
-----------------------------------------------------------------------------------
Pembelian Sebuah Produk
Tingkat Tujuan: Sea Level
Skenario Keberhasilan Utama:
- Pelanggan melihat-lihat katalog dan memilih barang untuk dibeli
- Pelanggan memeriksa
- Pelanggan mengisi informasi pengiriman barang (alamat, pengiriman sehari atau 3 hari)
- Sistem menampilkan informasi seluruh harga, termasuk pengiriman
- Pelanggan mengisi informasi kartu kredit
- Sistem meng-otorisasi pembelian
- Sistem meng-konfirmasi penjualan secara langsung
- Sistem mengirim e-mail konfirmasi ke pelanggan
3a: Konsumen adalah langganan
.1: Sistem menampilkan informasi pengiriman barang, harga, dan tagihan saat ini
.2: Pelanggan dapat menerima atau menghi-raukan default ini, kembali ke MSS di langkah 6
6a: Sistem gagal meng-otorisasi pembelian kredit
.1: Pelanggan dapat memasukkan kembali informasi kartu kredit atau membatalkan
-----------------------------------------------------------------------------------
Setiap langkah harus berupa pernyataan sederhana dan dengan jelas menunjukkan siapa yang menjalankan langkah tersebut.Langkah tersebut harus menunjukkan tujuan aktor, bukan mekanisme yang harus dilakukanaktor.Konsekuensinya, kita tidak menjabarkan antarmuka pengguna dalam use case.
Sebuah akstensi dalam sebuah use case menyebutkan sebuah kondisi yang menghasilkan interaksi berbeda dari yang disebutkan dalam MSS dan menyebutkan apa perbedaannya. Mulailah sebuah ekstensi dengan menunjuk langkah di mana kondisi tersebut terdeteksi dan sediakan sebuah gambaran singkat tentang kondisi tersebut. Urutkan kondisi tersebut dengan langkah-langkah bernomor menggunakan model yang sama dengan MSS. Akhiri langkah-langkah ini dengan menjelaskan di mana kita kembali ke MSS, jika kita melakukannya.
Seperti halnya langkah-langkah dalam scenario, kita dapat menambah beberapa informasi umum lain pada sebuah use case.
- Sebuah pra kondisi menjelaskan apa yang harus dipastikan bernilai true sebelum system memungkinkan use case mulai. Hal ini berguna untuk memberi tahu programmer kondisi apa yang tidak harus diperiksa kodenya.
- Sebuah jaminan menjabarkan apa yang dipasti-kan pada akhir use case oleh system. Jaminan yang berhasil akan menghasilkan scenario yang berhasil, jaminan yang minimal akan menghasilkan semua scenario.
- Sebuah pemicu merupakan sebuah event yang akan memulai use case.
DIAGRAM USE CASE
UML tidak menjelaskan isi sebuah use case tetapi menyediakan sebuah bentuk diagram untuk menampilkannya, seperti diperlihatkan pada Gambar 21-2. Meskipun diagram sering berguna, ini bukanlah suatu keharusan. Dalam pengolahan use case, jangan terlalu memperhatikan diagram. Sebaliknya, berkosentrasilah pada isi tekstual use case tersebut. Diagram use case hanya menampil-kan aktor, use case, dan hubungan antara mereka:
- Aktor mana yang menggunakan use ase mana
- Use case mana yang memasukan use case lain.
 |
| Gambar 8. Diagram Use Case |
Tingkatan-Tingkatan Use Case
Sebuah use case dapat terdiri dari beberapa tingkatan. Inti use case berada pada tingkat sea level. Use case sea level khususnya mewakili sebuah interaksi diskrit antara aktor utama dan system. Use case semacam ini akan memberikan nilai pada aktor utama dan biasanya memberi waktu beberapa menit sampai setengah jam bagi aktor utama untuk menyelesaikan. Use case yang ada di sana hanya karena mereka dimasukkan oleh use case sea level adalah fish level. Lebih tinggi, use case kite level menampilkan bagaimana use case sea level sesuai dengan interaksi bisnis yang lebih luas. Use case kite level biasanya merupakan use case bisnis, sedangkan use case sea dan fish level merupakan use case system. Kebanyakan use case berada pada tingkatan sea level.
Sekian artikel tentang Pengertian UML (Unified Modelling Language), Metode Penggunaan, Jenis Diagram UML, dan Activity Use Case Diagram Menurut Para Ahli. Semoga bermanfaat.
Daftar Pustaka
- Alan Denis, et all, System Analysis and Design With UML 2.0, Wiley, 2005
- Munawar, Pemrograman Visual dengan UML,Graha Ilmu,2005
Izin copas Gan...
BalasHapusBlog Ane