BAB II DASAR TEORI
2.5 Unified Modeling Language
2.5.3 Beberapa Diagram Pada UML
UML sendiri terdiri atas pengelompokan diagram-diagram sistem menurut aspek atau sudut pandang tertentu. Diagram adalah yang menggambarkan permasalahan suatu model. UML mempunyai 9 diagram, yaitu; use-case, object, state, sequence, collaboration, activity, component dan deployment diagram[27].
Diagram pertama adalah use-case menggambarkan sekelompok use-case dan actor yang disertai dengan hubungan diantaranya. Diagram use-case ini menjelaskan dan menerangkan kebutuhan (requirement) yang diinginkan/dikehendaki pengguna (user), serta sangat berguna dalam menentukan struktur organisasi dan model dari pada sebuah sistem.
2.5.3.1 Use Case Diagram
Sebuah use-case seperti terlihat pada gambar 2.14 menggambarkan suatu urutan interaksi antara satu atau lebih actor dan sistem. Dalam fase requirements, model use-case menggambarkan sistem sebagai sebuah kotak hitam dan interaksi antara actor dan sistem dalam suatu bentuk naratif, yang terdiri dari input user dan respon sistem. Setiap use-case menggambarkan perilaku sejumlah aspek sistem, tanpa mengurangi struktur internalnya. Selama pembuatan model use-case secara paralel juga harus ditetapkan obyek-obyek yang terlibat dalam setiap use-case[28].
Perhatikan satu contoh sederhana dari proses perbankan, yaitu mesin teler otomatis (automated teller machine-ATM) yang memberikan kemudahan pada customer-nya untuk mengambil uang dari rekening bank secara langsung. Pada proses ini terdapat satu actor, yaitu ATM customer dan satu use-case, yaitu penarikan dana. Proses ini dapat dilihat pada gambar dibawah ini. Use-case
33 penarikan dana menggambarkan urutan interaksi antara customer dengan sistem, diawali ketika customer memasukan kartu ATM ke dalam mesin pembaca kartu dan akhirnya menerima pengeluaran uang yang dilakukan oleh mesin ATM.
Gambar 2.14 Sebuah contoh diagram use-case (use-case diagram)
2.5.3.2 Identifikasi Use-Case
Sebuah use-case dimulai dengan masukan input dari seorang actor. Use-case merupakan suatu urutan lengkap kejadian-kejadian yang diajukan oleh seseorang actor dan spesifikasi interaksi antara actor dengan sistem. Use-case yang sederhana hanya melibatkan satu interaksi/hubungan dengan sebuah actor dan use-case yang lebih kompleks melibatkan beberapa interaksi dengan actor. Use-case yang lebih kompleks juga melibatkan lebih dari satu actor[28].
Untuk menjabarkan use-case dalam sistem, sangat baik bila dimulai dengan memperhatikan actor dan aksi (action) yang mereka lakukan dalam sistem. Setiap
case menggambarkan suatu interaksi antara actor dengan sistem. Sebuah use-case harus memberikan sejumlah nilai pada satu actor.
Kemudian, kebutuhan fungsional sistem dijelaskan dalam use-case yang merupakan suatu spesifikasi eksternal dari sebuah sistem. Bagaimanapun juga, ketika membuat use-case sangatlah penting menghindari suatu dekomposisi fungsional yang dalam beberapa use-case kecil lebih menjelaskan fungsi-fungsi individual sistem daripada menjelaskan urutan kejadian yang memberikan hasil yang berguna bagi actor.
Perhatikan lagi contoh pada perbankan. Disamping penarikan melalui ATM, ATM customer, actor juga bisa menanyakan jumlah rekening atau mentransfer dana antar dua rekening. Karena terdapat fungsi yang berbeda, fungsi-fungsi pertanyaan dan pentransferan harus dibuat sebagai use-case yang terpisah, daripada menjadi bagian dari original use-case. Oleh karena itu, customer dapat mengajukan tiga use-case, yaitu withdraw funds (penarikan dana), query account dan transfer funds (pentransferan dana).
Urutan utama use-case withdraw funds, urutan utama adalah urutan tahap-tahap dalam keberhasilan pelaksanaan penarikan (withdrawal). Cabang-cabang alternatif digunakan untuk mengarahkan berbagai error cases, seperti ketika kartu ATM tidak dikenali atau dilaporkan telah hilang dan lain sebagainya.
2.5.3.3 Pendokumentasian Model Use-Case[27]
35 Use-case didokumentasikan dalam use-case model seperti contoh pada gambar 2.15 di atas, yaitu:
1. Use-Case Name. Setiap use-case diberi nama.
2. Summary. Deskripsi singkat use-case, biasanya satu atau dua kalimat.
3. Dependency. Bagian ini menggambarkan apakah use-case yang satu tergantung pada use-case yang lain, dalam arti apakah use-case tersebut termasuk pada use-case yang lain atau malah memperluas use-case lain. 4. Actors. Bagian ini memberikan nama pada actor dalam use-case. Selalu
terdapat use-case utama (primary use-case) yang memulai use-case. Di samping itu terdapat juga secondary use-case yang terlibat dalam use-case. Contohnya, dalam use case withdraw funds, ATM customer adalah actor-nya.
5. Preconditions. Satu atau lebih kondisi harus berjalan dengan baik pada permulaan use-case, contohnya mesin ATM yang tidak jalan menampilkan pesan selamat datang.
6. Deskripsi. Bagian terbesar dari use-case merupakan deskripsi naratif dari urutan utama use-case yang merupakan urutan yang paling umum dari interaksi antara actor dan sistem. Deskripsi tersebut dalam bentuk input dari actor, diikuti oleh respon pada sistem. Sistem ditandai dengan sebuah kotak hitam (black box) yang berkaitan dengan apa yang sistem lakukan dalam merespon input actor, bukan bagaimana internal melakukannya.
7. Alternatif-alternatif. Deskripsi naratif dari alternatif merupakan cabang dari urutan utama. Terdapat beberapa cabang alternatif dari urutan utama. Contohnya, jika rekening customer terdapat dana yang tidak sesuai, akan tampil permohonan maaf dan menolak kartu.
8. Postcondition. Kondisi yang selalu terjadi di akhir use-case, jika urutan utama telah dilakukan; contohnya dana customer telah ditarik.
9. Outstanding question. Pertanyaan-pertanyaan tentang use-case didokumentasikan untuk didiskusikan dengan para user.
2.5.3.4 Class Diagram[27]
Gambar 2.16 Sebuah contoh diagram kelas (class diagram)
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class seperti contoh pada gambar 2.16 di atas menggambarkan keadaan (atribut/property) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metode/fungsi).
Class diagram menggambarkan struktur dan deskripsi class, package dan obyek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi dan lain-lain.
Class memiliki tiga area pokok, yaitu: 1. Nama (dan stereotype).
2. Atribut 3. Metode
Atribut dan metode dapat memiliki salah satu sifat berikut: 1. Private, tidak dapat dipanggil dari luar class yang bersangkutan.
2. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya.
3. Public, dapat dipanggil oleh siapa saja.
37 abstrak yang hanya memiliki metode. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metode pada saat run-time.
Sesuai dengan perkembangan class model, class dapat dikelompokan menjadi package. Kita juga dapat memuat diagram yang terdiri atas package.
2.5.3.5 Hubungan Antar Class[28]
Gambar 2.17 Hubungan antar kelas pada kelas diagram (diagram class)
Terdapat 3 (tiga) hubungan antar kelas seperti terlihat pada gambar 2.17 di atas, yaitu:
1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. 2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas”).
3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metode class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram.
2.5.3.6 Statechart Diagram
Gambar 2.18 Sebuah contoh statechart diagram
Statechart diagram seperti contoh pada gambar 2.18 di atas 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)[28].
2.5.3.7 Activity Diagram
Activity diagram seperti contoh pada gambar 2.19 di bawah ini menggambarkan berbagai alir aktifitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi[27].
39 Gambar 2.19 Sebuah contoh diagram akvitas (activity diagram)
Activity diagram merupakan state diagram khusus, dimana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar sub-sistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.
2.5.3.8 Component Diagram
Gambar 2.20 Sebuah contoh diagram komponen (component diagram)
Component diagram seperti contoh pada gambar 2.20 di atas menggambarkan struktur dan hubungan antar komponen perangkat lunak, termasuk ketergantungan (dependency) di antaranya. Komponen perangkat lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run-time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil[28].
Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
2.5.3.9 Deployment Diagram
Deployment/physical diagram seperti pada gambar 2.21 di bawah ini menggambarkan detail bagaimana komponen di-deploy infrastruktur sistem, dimana komponen akan terletak (pada mesin, server atau perangkat keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server dan hal-hal lain yang bersifat fisikal[27].
Sebuah node adalah server, workstation atau perangkat keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefiniskan dalam diagram ini.
41 Gambar 2.21 Sebuah contoh deployment diagram