UML (Unified Modeling Language) | Teknik Pengujian Sistem

**UML (Unified Modeling Language)**

adalah bahasa spesifikasi standar untuk mendokumentasikan, menspesifikasikan, dan membangun system (Flowler,2006). Unified Modeling Language (UML) adalah himpunan struktur dan teknik untuk pemodelan desain program berorientasi objek (OOP) serta aplikasinya.

UML adalah metodologi untuk mengembangkan sistem OOP dan sekelompok perangkat/tool untuk mendukung pengembangan sistem tersebut. UML mulai diperkenalkan oleh Object Management Group, sebuah organisasi yang telah mengembangkan model, teknologi, dan standar OOP sejak tahun 1980-an. Sekarang UML sudah mulai banyak digunakan oleh para praktisi OOP. UML merupakan dasar bagi perangkat (tool) desain berorientasi objek dari IBM. UML adalah suatu bahasa yang digunakan untuk menentukan, memvisualisasikan, membangun, dan mendokumentasikan suatu sistem informasi.

UML dikembangkan sebagai suatu alat untuk analisis dan desain berorientasi objek oleh Grady Booch, Jim Rumbaugh, dan Ivar Jacobson. Namun demikian UML dapat digunakan untuk memahami dan mendokumentasikan setiap sistem informasi. Penggunaan UML dalam industri terus meningkat. Ini merupakan standar terbuka yang menjadikannya sebagai bahasa pemodelan yang umum dalam industri peranti lunak dan pengembangan Sistem[Sumantri, Ade : 2012 dan Purnomo, Hadi : 2013].

UML menyediakan 10 macam diagram untuk memodelkan aplikasi berorientasi objek, yaitu :

Use Case Diagram untuk memodelkan proses bisnis.
Conceptual Diagram untuk memodelkan konsep yang ada didalam aplikasi.
Sequence Diagram untuk memodelkan pengiriman pesan (message) antar obyek.
Collaboration Diagram untuk memodelkan interaksi antar obyek.
State Diagram untuk memodelkan perilaku obyek di dalam sistem.
Activity Diagram untuk memodelkan perilaku obyek di dalam sistem.
Class Diagram untuk memodelkan struktur kelas.
Object Diagram untuk memodelkan struktur obyek.
Component Diagram untuk memodelkan komponen obyek.
Deployment Diagram untuk memodelkan distribusi aplikasi.

Sejarah Unified Modeling Language (UML)

Bahasa permodelan berorientasi objek muncul antara sekitar pertengahan tahun 1979-an dan akhir tahun 1980-an yang dikenal dengan bahasa pemograman berorientasi objek dan aplikasi komplek yang berkembang, yang dimulai untuk eksperimen dengan pendekatan alternative untuk analis dan desain. Sejumlah metode berorientasi objek bertambah dari kurang lebih 10 sampai lebih dari 50 selama periode 1989 dan 1994. Beberapa user pengguna metode ini menemukan permasalahan dalam bahasa permodelan ini yang dibutuhkan mereka untuk kelengkapan, sehingga timbul dengan yang dinamakan perang metode. Belajar dari pengalaman, metode generasi baru mulai muncul dengan metode yang terkemuka, seperti Booch, Jacobson’s OOSEE (Obejct Oriented Softwarengeneering) dan Rumbaugh’s OMT (Object Modeling Technique). Metode penting lainnya seperti Fusion, Shler_mellor dan Coad-Yourdan. Setiap metode ini merupakan metode yang lengkap, meskipun setiap metode diakui memiliki kelebihan dan kekurangan. Dalam waktu yang singkat metode Booch paling terrasa dalam desain dan membangun tahapan projek, OOSE memberikan dukungan yang baik untuk use cases seperti cara untuk menjalankan permintaan, analisis dan desain level tinggi, dan OMT-2 sangat berguna untuk analisis dan sistem informasi data intensif.

Gambaran UML

UML sebagai bahasa permodelan

UML merupakan bahasa permodelan yang memiliki pembendaharaan kata dan cara untuk mempresentasikan secara focus pada konseptual dan fisik dari suatu sistem. Contoh untuk software system yang intensif membutuhkan bahasa yang menunjukan pandangan yang berbeda dari arsitektur sistem, ini sama seperti menyusun/mengembangkan Software Development Life Cycle (SLDC). Dengan UML akan memberitahukan kita bagaimana untuk membuat dan membaca bentuk model yang baik, tetapi UML tidak dapat memberitahukan model apa yang akan dibangun dan kapan akan membangun model tersebut. Ini merupakan aturan dari Software Development Process.

UML sebagai bahasa untuk menggambarkan Visualizing system

UML tidak hanya merupakan rangkaian symbol grafikal, cukup dengan tiap symbol pada notasi UML merupakan penetapan simantik yang baik. Dengan cara ini, satu pengembang dapat menulis model UML dan pengembang lain atau perangkat yang sama lainnya dapat mengartikan bahwa model tersebut tidak ambigu. Hal ini akan mengurangi error yang terjadi karena perbedaan bahasa dalam komunikasi model konseptual dengan model lainnya. UML merupakan suatu model ekaplisit yang menggambarkan komunikasi informasi pada sistem. Sehingga kita tidak kehilangan informasi kode implementasi yang hilang dikarenakan developer memotong coding dari implementasi.

UML sebagai bahasa untuk menspesifikasikan sistem (specifying)

Maksudnya membangun model yang sesuai, tidak ambigu dan lengkap. Pada faktanya UML menunjukan semua spesifikasi keputusan analisis, desain dan implementasi yang penting yang harus dibuat pada saat pengembangan dan penyebaran dari sistem software intensif.

UML sebagai bahasa untuk membangun sistem (Construction)

UML bukan bahasa pemograman visual, tetapi model UML dapat dikoneksikan secara langsung pada pemograman visual.

UML sebagai bahasa untuk pendokumentasian sistem (Documantation)

Maksudnya UML menunjukan dokumentasi dari arsitektur sistem dan detail dari semuanya. UML hanya memberikan bahasa untuk memperlihatkan permintaan dan untuk tes. UML menyediakan bahasa untuk memodelkan aktifitas dari perencanaan proyek dan manajemen pelepasan (Release management).

Konsep Dasar UML

Dari penjelasan rumit yang terdapat didokumen dan buku-buku UML sebenarnya konsep dasar UML bias diterangkan dalam table dibawah ini :

Tabel 2.1 Konsep Dasal UML

Use Case Diagram

Use case diagram menggambarkan fungsionalisme yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Seorang/sebuah actor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan tertentu. Use case dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang text case untuk semua feature yang ada pada sistem.

[Yasin, Verdi, 2012, Rekayasa Perangkat Lunak Berorientasi Objek, Jakarta, Mitra Wacana Media]

Pengujian Sistem

Pengujian menyajikan anomali yang menarik bagi perekayasa perangkat lunak. Pada proses perangkat lunak, perekayasa berusaha membangun perangkat lunak dari konsep abstrak ke implementasi yang dapat dilihat, baru kemudian dilakukan pengujian.

Pengujian White Box

White Box Testing adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) perangkat lunak akan dites dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik.

Pada pengujian white box terdapat 2 metode yaitu Basis Path dan Struktur kendali. Pengujian basis path adalah pengujian yang memungkinkan penguji dapat mengukur kompleksitas logis dari desain procedural dan menggunakannya sebagai pedoman untuk menetapkan himpunan basis dari semua jalur eksekusi. Kasus uji dihasilkan untuk melakukan sekumpulan basis yang dijamin untuk mengeksekusi setiap perintah dalam program, sedikitnya satu kali selama uji coba.

Terdapat beberapa proses yang harus di lakukan dalam uji coba basis path yaitu diantaranya :

Notasi Diagram Alir

Sebelum metode basis path diperkenalkan, terlebih dahulu akan dijelaskan mengenai notasi sederhana dalam bentuk diagram alir (grafik alir). Diagram alir menggambarkan aliran kontrol logika yang menggunakan notasi.

Kompleksitas Siklomatis

Kompleksitas siklomatis adalah metriks perangkat lunak yang memberikan pengukuran kuantitatif terhadap kompleksitas logis suatu program. Bila metriks ini digunakan dalam konteks metode pengujian basis path, maka nilai yang terhitung untuk kompleksitas siklomatis menentukan jumlah jalur independen dalam basis set suatu pemrograman memberi batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan bahwa semua statemen telah dieksekusi sedikitnya satu kali.

Jalur independen adalah jalur yang memlalui progarm yang mengintroduksi sedikitnya satu rangkaian statemen proses baru atau suatu kondisi baru. Bila dinyatakan dengan terminologi grafik alir, jalur independen harus bergerak sepanjang paling tidak satu edge yang tidak dilewatkan sebelum jalur tersebut ditentukan

Melakukan Test Case

Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis path.

Matriks Grafis

Prosedur untuk mendapatkan grafik alir dan menentukan serangkaian basis path, cocok dengan mekanisasi. Untuk mengembangkan peranti perangkat lunak yang membantu pengujian basis path, struktur data yang disebut matriks grafis dapat sangat berguna.

Matriks garfis adalah matriks bujur sangkar yang ukurannya sama dengan jumlah simpul pada grafik alir. Masing-masing baris dan kolom sesuai dengan simpul yang diidentifikasikan dan entry matriks sesuai dengan edge diantara simpul.

Pengujian Black Box

Pengujian black-box berfokus pada persyaratan fungsional perangkat lunak. Dengan demikian, pengujian black-box memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya menggunakan semua peryaratan fungsional untuk suatu program. Pengujian black-box bukan merupakan alternatif dari teknik white-box tetapi merupakan pendekatan komplementer yang kemungkinan besar mampu mengungkap kesalahan daripada metode white-box[Ade, S : 2012 dan Hadi, Purnomo : 2013].

Pengujian black-box berusaha menemukan kesalahan dalam kategori sebagai berikut :

Fungsi-fungsi yang tidak benar atau hilang.
Kesalahan interface.
Kesalahan dalam struktur data atau akses database eksternal.
Kesalahan kinerja.
Inisialisasi dan kesalahan internal.

Tidak seperti pengujian white box yang dilakukan pada awal proses pengujian, pengujian black box cenderung diaplikasikan selama tahap akhir pengujian. Karena pengujian black box memperhatikan struktur kontrol, maka perhatian berfokus pada domain informasi.

Dengan mengaplikasikan teknik black box, maka dapat menarik serangkaian test case yang memenuhi kriteria berikut ini :

Test case yang mengurangi, dengan harga lebih dari satu, jumlah test case tambahan yang harus didesain untuk mencapai pengujian yang dapat dipertanggungjawabkan.
Test case yang memberi tahu sesuatu mengenai kehadiran atau ketidakhadiran kelas kesalahan daripada memberi tahu kesalahan yang berhubungan hanya dengan pengujian spesifik yang ada.

UML (Unified Modeling Language) | Teknik Pengujian Sistem