Unified Modeling Language (UML)
Unified Modelling Language merupakan bahasa pemodelan untuk sistem atau PL yang berparadigma “berorientasi Objek”. Pemrograman berorientasi obyek merupakan kelanjutan dari proses analisis dan desain berorientasi obyek. Dalam pemrograman berorientasi obyek ini, komponen yang didesain dalam proses desain kemudian diimplementasikan dengan menggunakan bahasa pemrograman berorientasi obyek.
UML diciptakan oleh : Grady Booch, James Rumbaugh dan Ivan Jacobson tahun 1995. 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. Namun demikian UML dapat digunakan untuk memahami dan mendokumentasikan setiap sistem informasi.
a) Tujuan UML
Tujuan utama UML diantaranya untuk :
Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.
Memberikan bahasa pemodelan yang bebas dari berbagai bahasa pemrograman dan proses rekayasa.
Menyatukan praktek-praktek terbaik yang terdapat dalam bahasa pemodelan.
b) Cakupan UML
UML menggabungkan konsep Booch, OMT dan OOSE, sehingga UML merupakan suatu bahasa pemodelan tunggal yang umum dan digunakan secara luas oleh para user ketiga metode tersebut dan bahkan para user metode lainnya.
UML menekankan pada apa yang dapat dikerjakan dengan metode-meode tersebut.
UML berfokus pada suatu bahasa pemodelan standar, bahkan pada proses standar. Meskipun UML harus diaplikasikan dalam konteks sebuah proses, dari pengalaman, bahwa organisasi dan masalah yang berbeda juga memerlukan proses yang berbeda pula.
Ada 10 macam diagram untuk memodelkan aplikasi berorientasi objek, namun dalam blog ini akan di bahas 6 macam diagram diantaranya ;
1. Use Case Diagram
menggambarkan sebuah fungsionalitas yang diharapkan dari sebuah sistem dan bagaimana sistem berinteraksi dengan dunia luar. Yang ditekankan dalam Use Case Diagram adalah ”apa” yang diperbuat sistem, dan bukan “bagaimana” sistem itu melakukannya.
Sebuah Use Case mempresentasikan sebuah interaksi antara actor dengan sistem. Use Case Diagram juga menjelaskan manfaat sistem jika dilihat menurut pandangan orang yang berada diluar sistem (actor). Use Case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng - create sebuah daftar daftar belanja dan sebagainya.
Contoh diagram use case sebagai berikut:
2. Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).
Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lainlain. Class memiliki tiga area pokok :
Nama (dan stereotype)
Atribut
Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut :
Private, tidak dapat dipanggil dari luar class yang bersangkutan
Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya.
Public, dapat dipanggil oleh siapa saja
HUBUNGAN ANTAR CLASS
- AsosiasiRelasi antar kelas dengan makna yang umum, biasanya relasi ini dilengkapi dengan multiplicity. Hubungannya dapat digambarkan dengan garis lurus.
- AgregasiMerupakan gambaran suatu hubungan antar kelas, kelas tersebut merupakan bagian darisuatu kelas yang lain. Hubungannya dapat digambarkan dengan tanda panah disalah satuujungnya dan diamond kosong di salah satu ujungnya.
- GeneralisasiMerupakan gambaran suatu hubungan antar kelas, yang memiliki makna (umum-khusus).Hubungannya dapat digambarkan dengan gria lurus dengan tanda panah kosong di dalahsatu ujungnya.
Di bawah ini, merupakan contoh dari kelas diagram study kasus family member
2. Object Diagram
Diagram objek ialah merupakan suatu diagram yang mengambarkan objek-objek dalamsuatu system. Bila pada kelas diagram terdapat banyak relasi antar kelas, namun pada diagramobjek, hanya terdapat satu relasi antar kelas, yaitu asosiasi. Tidak hanya itu, pada diagram objekyang didefinisikan hanya nama objek dalam suatu kelas beserta atributnya saja, tanpa operasiyang dilakukan oleh objek tersebut.
Penulisan nama pada objek diagram, bisa kita tulis nama kelasnya saja, tanpa diikutinama objeknya. Jangan lupa, nama kelas awalnya harus ditulis dengan huruf capital.
Di bawah ini, merupakan contoh dari diagram objek :
3. Activity Diagram
Memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses. Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis. Diagram ini sangat mirip dengan sebuah flowchart karena kita dapat memodelkan sebuah alur kerja dari satu aktivitas ke aktivitass lainnya atau dari satu aktivitas ke keadaan sesaat (state). Juga sangat berguna ketika ingin menggambarkan perilaku paralel atau menjelaskan bagaimana perilaku dalam berbagai use case berinteraksi.
Contoh Activity Diagram
4. Sequence Diagram
Sequence diagram menjelaskan secara detail urutan proses yang dilakukan dalam sistem untuk mencapai tujuan dari use case: interaksi yang terjadi antar class, operasi apa saja yang terlibat, urutan antar operasi, dan informasi yang diperlukan oleh masing-masing operasi.
contoh Sequence Diagram :
5. Collaboration Diagram
Collaboration diagram dipakai untuk memodelkan interaksi antar object di dalam sistem. Berbeda dengan sequence diagram yang lebih menonjolkan kronologis dari operasi-operasi yang dilakukan, collaboration diagram lebih fokus pada pemahaman atas keseluruhan operasi yang dilakukan oleh object.
contoh Collaboration Diagram:
PENGUJIAN PERANGKAT LUNAK
1. Definisi
Pengujian adalah proses untuk menemukan error pada perangkat lunak sebelum di-delivery kepada pengguna.
2. Tujuan Pengujian
Pengujian adalah proses menjalankan program dengan maksud mencari kesalahan (error)
Kasus uji yang baik adalah kasus yang memiliki peluang untuk mendapatkan kesalahan yang belum diketahui.
Pengujian dikatakan berhasil bila dapat memunculkan kesalahan yang belum diketahui
Jadi pengujian yang baik bukan untuk memastikan tidak ada kesalahan tetapi untuk mencari sebanyak mungkin kesalahan yang ada pada program
Pengujian perangkat lunak seharusnya menghabiskan waktu 30% – 40% dari total biaya pembangunan perangkat lunak. Pengujian merupakan bagian dari salah satu tugas software verification dan validation, yang merupakan bagian dari software quality assurance
Pengujian perangkat lunak mencakup :
Strategi : Mengintegrasikan metode perancangan kasus uji dalam sekumpulan langkah yang direncanakan
metode pengujian, mencakup Perancangan kasus uji dengan menggunakan metode White Box atau Black Box
3. Dasar-dasar Pengujian Perangkat Lunak
Pengembang perangkat lunak sesuai dengan sifatnya dasar mereka adalah manusia pembangun. Pengujian mengharuskan pengembang membuang pemikiran sebelumnya mengenai “kebenaran” perangkat lunak yang baru saja dikembangkan dan mengatasi konflik minat yang terjadi pada saat kesalahan ditemukan.
4. Sasaran Pengujian
Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan.
Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.
Pengujian yang sukses dadalah pengujian yang mengungkapkan semua kesalahan yang belum pernah ditemukan sebelumnya.
5. Prinsip Pengujian
Semua pengujian harus dapat dirunut sampai kepada spesifikasi kebutuhan perangkat lunak.
Pengujian harus dimulai dari lingkup yang kecil ke lingkup yang besar
Pengujian yang mendalam tidak mungkin dilakukan karena tidak mungkin mengeksekusi semua jalur permutasi
Supaya efektif (memiliki probabilitas yang tinggi dalam menemukan kesalahan), pengujian harus dilakukan oleh pihak lain yang independen
Pengujian harus direncanakan jauh sebelum dilakukan
Metode Perancangan Kasus Uji
Perancangan test case adalah perancangan untuk menyediakan kemungkinan-kemungkinan yang cukup tinggi untuk menemukan kesalahan (sesuai dengan tujuan Uji coba) dengan jumlah waktu dan usaha yang minimum
Metode Kasus Uji : Metode yang dapat membantu memastikan kelengkapan pengujian dan memberikan kemungkinan tertinggi untuk mengungkapkan kesalahan pada perangkat lunak
A. Pengujian Black_Box.
Black_Box adalah pengujian untuk mengetahui apakah semua fungsi perangkat lunak telah berjalan semestinya sesuai dengan kebutuhan fungsional yang telah didefinsikan. Metode Black Box memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya menggunakan semua persyaratan fungsional untuk suatu program. Black Box dapat menemukan kesalahan dalam kategori berikut :
Fungsi-fungsi yang tidak benar atau hilang
Kesalahan interface
Kesalahan dalam strutur data atau akses basisdata eksternal
Inisialisasi dan kesalahan terminasi
validitas fungsional
kesensitifan sistem terhadap nilai input tertentu
batasan dari suatu data
B. Pengujian White_Box
White_Box merupakan metode pengujian dengan menggunakan struktur kontrol program untuk untuk memperoleh kasus uji . Dengan menggunakan white box akan didapatkan kasus uji yang :
Menjamin seluruh jalur independen di dalam modul yang dieksekusi sekurang-kurangnya sekali
menguji semua keputusan logikal
menguji seluruh Loop yang sesuai dengan batasannya
menguji seluruh struktur data internal yang menjamin validitas
C. Pengujian Basic Path
Basis Path merupakan teknik uji coba white box (Tom Mc Cabe). Untuk mendapatkan kompleksitas lojik dari suatu prosedur dan menggunakan ukuran ini sebagai petunjuk untuk mendefinisikan himpunan jalur yang akan diuji . Basis Path menggunakan notasi graph untuk menggambarkan aliran kontrolnya.
Tujuannya adalah untuk meyakinkan bahwa himpunan test case akan menguji setiap path pada suatu program paling sedikit satu kali. Titik awal untuk path testing adalah suatu program flow graph yang menunjukkan node-node yang menyatakan program decisions (mis.: if-then-else condition) dan busur menyatakan alur control Statements dengan conditions adalah node-node dalam flow graf.
Pengujian basis path memungkinkan desain test case mengukur kompleksitas logiss dari desain procedural dan menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi. Test case yang dilakukan untuk menggunakan basis set tersebut dijamin untuk menggunakan setia statemen di dalam program paling tidak sekali selama pengujian.
Notasi Diagram Alir
Diagram Alir atau grafik program menggambarkan aliran control logika.
Kompleksitas Siklomatis
Kompleksitas Siklomatis adalah metric perangkat lunak yang memberikan pengukuran kuantitaif terhadap kompleksitas logis suatu program. Kompleksitas Siklomatis menentukan jumlah jalur independen dalam basis set suatu program dan memberikan batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan bahwa semua statemen telah dieksekusi sedikitnya satu kali.
Jalur independen adalah jalur yang melalui program yang mengintroduksi sedikitnya satu rangkaian statemen proses baru atau suatu kondisi baru.
Melakukan Test Case
- Dengan menggunakan desain atau kode sebagai dasar, gambarkan sebuah grafik alir yang sesuai.
- Tentukan kompleksitas siklomatis dari grafik alir resultan.
- Tentukan sebuah basis set dari jalur independen secara linier.
-Siapkan test case yang akan memaksa adanya eksekusi setiap basis set.
Matrik Grafis
-Matrik grafis adalah matriks bujur sangkar yang ukurannya sama dengan jumlah simpul pada grafik alir
-Masing masing baris dan kolom sesuai dengan yang diidentifikasi kan, dan entri matriks sesuai dengan edge di antara simpul.
D. Pengujian Struktur Kontrol
Pengujian Kondisi
Pengujian Aliran data
Pengujian Loop
