Pengertian UML dan Cara Pengujian Perangkat Lunak | LAN NETWORKING

1. UML (Unified Modelling Language)

Pengertian UML (Unified Modelling Language)

UML (Unified Modelling Language) adalah sebuah “bahasa” yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun.

UML mendefinisikan diagramdiagram sebagai berikut:

• use case diagram
• class diagram
• statechart diagram
• activity diagram
• sequence diagram
• collaboration diagram
• component diagram
• deployment diagram

 1.1 Macam-Macam Diagram UML

Penjelasan dari masing-masing diagram tersebut akan dijelaskan dalam bentuk sub bab berikut ini :

1.1.1 Use Case Diagram
Use Case diagram adalah gambar dari beberapa atau seluruh aktor dan use case dengan tujuan mengenali interaksi mereka dalam suatu sistem. Oleh karena itu, use case diagram dapat membantu menganalisa kebutuhan suatu sistem. Dalam use case diagram terdapat istilah seperti aktor, use case dan use case relationship.

• Aktor

Aktor mewakili siapa pun atau apa saja yang harus berinteraksi dengan sistem. Aktor bisa didefinisikan sebagai berikut :

1. Aktor hanya memberikan informasi kepada sistem.
2. Aktor hanya menerima informasi dari sistem.
3. Aktor memberikan dan menerima informasi ke dan dari sistem.

Adapun pertanyaan yang berguna untuk membantu mengenali aktor dalam suatu sistem:

1. Siapa orang yang berkepentingan dalam sistem?
2. Dimana organisasi sistem akan digunakan?
3. Siapa yang akan diuntungkan dari penggunaan sistem?
4. Siapa yang akan memenuhi sistem dengan informasi, menggunakan informasi dan menghapus informasi?
5. Siapa yang mendukung dan menggunakan sistem?
6. Apakah sistem menggunakan sebuah sumber dari luar?
7. Apakah satu bermain menjadi beberapa peran yang berbeda?
8. Apakah sistem mempengaruhi dengan sistem turunannya?

• Use Case

Use Case Model adalah dialog antara aktor dengan sistem yang akan menggambarkan fungsi yang diberikan oleh sistem.Ada beberapa pertanyaan yang dapat membantu mengenal use case untuk sistem, yaitu sebagai berikut:

1. Apakah tugas dari setiap aktor?
2. Dapatkah aktor melakukan, membuat, menyimpan, merubah, menghapus atau membaca informasi?
3. Apakah use case akan membuat, menyimpan, mengganti, menghapus atau membaca informasi?
4. Dapatkah aktor menginformasikan sistem tentang perubahan yang terjadi perubahan dari luar secara mendadak?
5. Apakah aktor perlu menginformasikan tentang kejadian dalam sistem?
6. Apakah use case akan mendukung dan mempertahankan sistem?
7. Bisakah semua fungsi use case memenuhi kebutuhan?

•  Use Case Relationship

Use Case Relationship adalah suatu hubungan baik itu antara aktor dan use case atau antara use case dan use case. Hubungan antara aktor dan use case disebut dengan communicate association.

 1.1.2 Kelas Diagram

Kelas Diagram berfungsi untuk menjelaskan tipe dari object sistem dan hubungannya dengan object yang lain. Object adalah nilai tertentu dari setiap attribute kelas entity. Pada penggambaran kelas diagram ada dikenal dengan kelas analisis yaitu kelas ber-stereotype. Tapi yang biasanya dipakai adalah kelas diagram tanpa stereotype.

1.1.3 State Diagram

State diagram menggambarkan urutan keadaan yang dilalui object dalam suatu kelas, karena suatu kejadian menyebabkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.

1.1.4 Activity Diagram

Activity Diagram berupa flow chart yang digunakan untuk memperlihatkan aliran kerja dari sistem. Notasi yang digunakan dalam activity diagram adalah sebagai berikut:

• Activity

Notasi yang menggambarkan pelaksanaan dari beberapa proses dalam aliran pekerjaan. 

• Transition

Notasi yang digunakan untuk memperlihatkan jalan aliran kontrol dari activity ke activity.
 

• Decision

Notasi yang menandakan kontrol cabang aliran berdasarkan decision point.
 

• Synchronization Bars

Aliran kerja notasi ini menandakan bahwa beberapa aktivitas dapat diselesaikan secara bersamaan (pararel)

1.1.5 Sequence Diagram

Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

1.1.6 Collaboration Diagram

Collaboration adalah cara alternatif untuk mengetahui tahap-tahap terjadinya suatu aktivitas. Perbedaan antara collaboration dan sequence diagram adalah collaboration diagram memperlihatkan bagaimana hubungan antara beberapa objek, sedangkan yang kedua sequence diagram memperlihatkan bagaimana urutan kejadian

1.1.7 Component Diagram

Component diagram berfungsi untuk menggambarkan komponen run-time dan executable yang dibuat untuk sistem. Komponen saling berelasi menggunakan depedecy relation (Hubungan ketergantungan, yang ditandai dengan garis putus-putus). Komponen run-time memperlihatkan pengelompokan kelas untuk run-time library seperti Java Applet, Active-X Component dan Dynamic Libraries. Komponen executable memperlihatkan interface dan memanggil dependencies beberapa executable. Interface kelas diperlihatkan seperti lollypop.

1.1.8 Deployment Diagram

Deployment Diagram memperlihatkan konfigurasi pada jalannya proses run-time elements  dan proses software yang ada pada diagram. Run-time elements menggambarkan node yang berkoneksi menandakan adanya komunikasi diantaranya. Diagram ini membantu tim untuk mengerti sistem topology

2. Tool Yang Mendukung UML

Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial

maupun opensource. Beberapa diantaranya adalah:

• Rational Rose (www.rational.com)
• Together (www.togethersoft.com)
• Object Domain (www.objectdomain.com)
• Jvision (www.object-insight.com)
• Objecteering (www.objecteering.com)
• MagicDraw (www.nomagic.com/magicdrawuml)
• Visual Object Modeller (www.visualobject.com)
• StarUML

3. Requirement

Requerement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem.

3.1 Jenis Requirements

3.1.1  Requirement Fungsional

Kebutuhan fungsional harus mendefinisikan aksi dasar yang harus diambil oleh

perangkat lunak untuk menerima dan memproses masukan dan menghasilkan keluaran.

3.3.2   Requuirement Non Fungsional

Bagian ini menspesifikasikan ukuran kuantitatif yang harus dipenuhi oleh perangkat

lunak. Uraian minimal pada bagian ini berisi sebuah tabel, dengan kolom: Kriteria

Kebutuhan, Tuntutan kebutuhan. Kebutuhan tersebut antara lain: Performansi,
Batasan Memori, Modus Operasi, Adaptasi Situs atau Ergonomi.

4. Testing (Pengujian Perangkat Lunak)

Adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean.

Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat lunak adalah:

1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan
2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya
3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya

Sasaran utama desain test case adalah untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak. Untuk mencapai sasaran tersebut, digunakan 4 kategori yang berbeda dari tehnik desain test case: Pengujian white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-Down.

4.1 Pengujian white-box berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.

Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.

4.2 Tehnik pengujian black-box berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.

Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.

Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.

4.3 Integrasi Top-Down adalah pendekatan incremental dengan menggerakkan ke bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top-down memeriksa control mayor atau keputusan pada saat awal di dalam proses pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.

Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.

4.4 Pengujian Integrasi Bottom-up memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi