Tuesday, May 12, 2009

Tren Terbaru Software dan Karakteristiknya

Software atau perangkat lunak penggunaannya sudah “menjalar” ke semua aspek kehidupan. Jika kita lihat diberbagai instansi atau organisasi, maka kita akan mengenal istilah Sistem Informasi, mulai dari Akademik (SIA) di sekolah-sekolah, sampai ke Sistem Informasi Ketenagakerjaan (SIK). Beragam produksi Software juga menjadi pilihan atas penggunaan Software tersebut, mulai dari yang harga rendah, sedang atau harga tinggi, atau mulai dari software luar negeri atau software lokal.
Merebaknya penggunaan Software di satu sisi menguntungkan Programmer dan developer Software, karena banyaknya order dan pendapatan yang bisa diperoleh. Namun di sisi lain cukup mengkhawatirkan karena di Indonesia tidak ada institusi yang secara aktif bertugas membuat standard dalam pengukuran kualitas perangkat lunak. Jadi pengembang dan software house di Indonesia belum bisa mulai memperhatikan masalah kualitas perangkat lunak ini.

Kualitas perangkat lunak (software quality) adalah tema kajian dan penelitian turun temurun dalam sejarah ilmu rekayasa perangkat lunak (software engineering). Kajian dimulai dari apa yang akan diukur (apakah proses atau produk), apakah memang perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan parameter pengukuran kualitas perangkat lunak.

Bagaimanapun juga mengukur kualitas perangkat lunak memang bukan pekerjaan mudah. Ketika seseorang memberi nilai sangat baik terhadap sebuah perangkat lunak, orang lain belum tentu mengatakan hal yang sama. Sudut pandang seseorang tersebut mungkin berorientasi ke satu sisi masalah (misalnya tentang reliabilitas dan efisiensi perangkat lunak), sedangkan orang lain yang menyatakan bahwa perangkat lunak itu buruk menggunakan sudut pandang yang lain lagi (usabilitas dan aspek desain).
Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat lunak, adalah apa yang sebenarnya mau kita ukur. Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan perangkat lunak (process) dan hasil produk yang dihasilkan (product). Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan sesuai dengan yang diharapkan oleh pengguna. Hal ini berangkat dari pengertian kualitas (quality) menurut IEEE Standard Glossary of Software Engineering Technology [3] yang dikatakan bahwa:
“The degree to which a system, component, or process meets customer or user needs or expectation.”

Dari sudut pandang produk, pengukuran kualitas perangkat lunak dapat menggunakan standard dari ISO 9126 atau best practice yang dikembangkan para praktisi dan pengembang perangkat lunak. Taksonomi McCall adalah best practice yang cukup terkenal dan diterima banyak pihak, ditulis oleh J.A. McCall dalam technical report yang dipublikasikan tahun 1977 [1].

Di lain pihak, dari sudut pandang proses, standard ISO 9001 dapat digunakan untuk mengukur kualitas perangkat lunak. Dan diskusi tentang ini berkembang dengan munculnya tema kajian tentang CMM (The Capability Maturity Model) yang dikembangkan di Software Engineering Institute, Carnegie Mellon University serta beberapa kajian lain seperti SPICE (Software Process Improvement and Capability Determination) dan BOOTSTRAP. CMM, SPICE dan BOOTSTRAP mengukur kualitas perangkat lunak dari seberapa matang proses pengembangannya.

Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi McCall [1], atribut tersusun secara hirarkis, dimana level atas (high-level attribute) disebut faktor (factor), dan level bawah (low-level attribute) disebut dengan kriteria (criteria). Faktor menunjukkan atribut kualitas produk dilihat dari sudut pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan sebab akibat (cause-effect) [4][5].

Berikut adalah Faktor Kualitas (Quality Factor dan Quality Criteria) dari Perangkat Lunak
1. Correctness—> Completeness, Consistency, Traceability
2. Reliability —> Accuracy, Error Tolerane, Consistency, Simplicity
3. Efficiency —> Execution Efficiency, STorage Efficiency
4. Integrity —> Access Control, Access Audit
5. Usability —> Communicativeness, Operability, Training
6. Maintainability —> Consistency, Conciseness, Simplicity, Modularity, Self-documentation
7. Testability —> Simplicity, Modularity, Instrumentation, Self -documentation
8. Flexibility —> Expandability, Generality, Modularity, Self-doc
9. Portability —> Software System Independence, Hardware Independent, Self-documentation
10. Reusability —> Generality, software System Independence Hardware Independence, Modularity
11. Interoperability —> Communication Commonality, Data Commonalit Modularity.

Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria dalam suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan [2]. Rumus pengukuran yang digunakan adalah:
F1 = w1c1 + w2c2 + … + wncn
Dimana:
F1 adalah nilai total dari faktor a
wn adalah bobot untuk kriteria i
cn adalah nilai untuk kriteria i

Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai berikut:
Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor
Tahap 2: Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1)
Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <= 10)
Tahap 4: Berikan nilai pada tiap kriteria
Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn

Requerment Software Engineering

Definisi
Requirement menurut IEEE Standard Glossary of Software Engineering Technology (IEEE Std 610.12-1990) dapat diartikan sebagai berikut.
• Suatu kondisi atau kemampuan yang diperlukan oleh user untuk memecahkan masalah atau mencapai tujuan
• Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standard, spesifikasi atau dokumen formal lain
• Gambaran yang terdokumentasi dari kondisi atau kemampuan yang disebut pada kondisi 1 dan 2 diatas

Menurut Sommerville requirement adalah spesifikasi dari apa yang harus diimplementasikan, deskripsi bagaimana sistem harusnya berkerja atau bagian-bagian yang ada didalam sistem, bisa juga dijadikan batasan dalam proses pengembangan sistem.

Ada beberapa macam requirement menurut Sommerville yaitu:

a. User Requirement (kebutuhan pengguna)

Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan perasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

b. System requirement (kebutuhan system)

Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

c. Software design specification ( spesifikasi rancangan perangkat lunak)

Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

Secara umum, requirement dibagi menjadi 2 yaitu

Functional requirement : menjelaskan tentang fungsional dari sistem
Non-Functional requirement : yang berperan untuk member batasan pada solusi atau biasa disebut quality requirement.
Requirement yang baik mempunyai karakteristik untuk tetap konsisten, dibutuhkan, tidak ambigu, dan bisa diverifikasi. Selain itu requirement juga harus lengkap, kenapa?
• Kesesuaian dengan keinginan pelanggan.
• Mengestimasi serta menjaga jadwal dan biaya pengembangan
• Menjaga arsitektur, desain, implementasi, dan tes dari pengembangan agar terhindar dari ketidak lengkapan dan kesalahan karena asusmsi yang salah.
• Menghindari ambigu
• Keamanan, telah terbukti banyak kegagalan terjadi karena tidak lengkapnya requirement.

Donald Firesmith merekomendasikan menggunakan multi requirement model sehingga sudut pandang bisa lebih luas dan detil, model tersebut harus di identifikasi, analisis, dan didokumentasikan. Gunakan checklist untuk memeriksa apakah model telah terimplementasi dalam requirement. Buatlah model sesuai dengan kebutuhan proyek secara spesifik. Serta memastikan pengalaman dan keragaman anggota team untuk menyesuaikan dengan kekomplekan sistem yang sedang dibangun. Selain itu gunakan repository untuk menyimpan metadata requirement untuk mendapatkan requirement sesuai dengan kebutuhan proyek, dan gunakan alat yang mampu mengidentifikasikan metadata dan report yang kurang. Dengan metode requirement iterative dan incremental, secara berkelanjutan kebutuhan pelanggan dan pengguna akan selalu berkembang sehingga requirement juga akan ikut berkembang, hal ini berarti requirement yang lengkap menjadi state yang relative.

Kelengkapan requirement harus tetap dijaga karena banyak requirement engineering yang tidak tahu bahwa sebenarnya requirement mereka kurang lengkap sehingga bisa menimbulkan “bencana” dalam pengembangan sistem, untuk itu perlu dibuat beberapa model requirement agar sudut pandang terhadap setiap detil bisa dipantau, den mengunakan repository untuk memudahkan dokumentasi dan verifikasi kepada stakeholder, selain itu memungkinkan juga melakukan check kelengkapan requirement berdasarkan template model proyek yang telah dispesifikasikan sesuai dengan kompleksitasnya.

Banyak orang sering salah dalam mendefinisikan requirement untuk sistem yang mereka bangun, kerena mereka kurang mendapat pelatihan dan pengalaman dalam membuat requirement. Bahkan di bangku kuliah yang mengajarkan mata kuliah system engineering hanya mengajarkan pengenalan untuk materi menulis requirement.

Aspek yang penting dari sistem engineering adalah merubah kebutuhan user menjadi jelas, ringkas, dan dapat diverifikasi. Requirement yang baik menyatakan sesuatu yang dibutuhkan, dapat diverifikasi, memungkinkan, dan Jelas.

Terdapat beberapa masalah yang sering ditemui dalam membuat requirement, diantaranya adalah : membuat asumsi yang buruk, menulis implementasi (HOW) daripada requirement (WHAT), menjelaskan operasional daripada kebutuhan, mengunakan istilah yang salah, mengunakan bahasa yang kurang tepat, requirement tidak lengkap, dan menspesifikasikan requirement secara berlebihan.

Asusmsi yang buruk terjadi karena pembuat requirement tidak mempunyai akses yang cukup terhadap informasi yang dibutuhkan. Hal ini bisa dikurangi dengan cara mendokumentasikan informasi yang kritis seperti kebutuhan, tujuan, batasan, misi dan lain-lain. Selain itu semua asumsi juga harus didokumentasikan sehingga ketika direview asumsi bisa diperbaiki jika tidak sesuai.

Spesifikasi requirement harus menyatakan Apa yang dibutuhkan (WHAT), bukan bagaimana hal tersebut di sediakan (WHY). Caranya dengan mentanyakan mengapa (WHY) anda membutuhkan requirement tersebut.

Istilah juga penting untuk diperhatikan, penulis requirement harus bisa membedakan istilah shall (bisa), will (akan) ,dan should (harus). Requirement mengunakan Shall (bisa), pernyataan fakta mengunakan will (akan), dan Tujuan mengunakan Should (harus). Saat ini Requirement Spesification telah berpindah dari yang berkarateristik waterfall menjadi iterative, incremental, parallel, dan timebox.

Iterative Requirement Engineering : cocok digunakan untuk proses pengembangan yang terdapat fase penting yang belum pasti, misalnya pada software yang dibuat untuk ditawarkan kepada pelanggan, requirement pada software ini bisa berubah 180 deraajat karena pelanggan bisa membutuhkan sesuatu yang belum dipikirkan oleh pengembang, oleh sebab itu model iterative requirement engineering cocok untuk pengembangan software diatas, untuk memperbaiki dan meningkatkan kualitas software perlu melakukan iterasi yang berulang-ulang.

Incremental Requirement Engineering : Jika software yang akan dibuat terlalu besar dan komplek sehingga tidak bisa dibuat semua sekaligus, maka incremental requirement engineering sesuai untuk pengembangan software tersebut. Hal ini dikarenakan requirement elicitation, analysis,dan specification biasanya dilakukan secara incremental, dengan penambahan requirement dilakukan harian atau mingguan setelah perubahan signifikan dilakukan. Contoh yang paling mudah ditemukan adalah software seperti **legal copy** of microsoft word atau **legal copy** of corel draw yang mempunyai banyak versi seiring dengan perubahan tahun.

Parallel Requirement Engineering : dilaksanakan jika pengembangannya memiliki banyak aktifitas dan harus atau bisa dilakukan secara bersamaan, biasanya dalam proyek tersebut memiliki banyak sumber daya manusia dan hanya memiliki tenggat waktu yang rasional.

Timebox Requirement Engineering : jika proyek diselesaikan dalam waktu tertentu (deadline), maka harus dilakukan dengan memberikan batasan waktu (timebox) terhadap fase.Yang perlu diperhatikan adalah keempat karateristik tersebut tidak harus dipilih salah satu dalam pengembangan requirement, namun sebaiknya digunakan semuanya, karena sejatinya keempat karakteristik tersebut tidak bersebrangan dan bisa mendukung satu sama lain untuk kelangsungan suatu proyek.
Modern Requirement

Yang menjadi tulang punggung dari modern requirement adalah repository. Dengan adanya repository memungkinkan untuk mengkontrol requirement dengan lebih fleksibel. Siapa yang menulis requirement, siapa yang mensetujui dapat mudah diketahui, perubahan dan history perubahan requirementpun bisa dilakukan, status pengerjaan requirement pun bisa diset dan dilihat ketika tahap pengembangan.

Selain itu dokumen requirement bisa dengan mudah digenerate dari repository dengan banyak versi untuk stakeholder yang berbeda-beda. Selain itu modern requirement juga terintegrasi dengan aktifitas dari stakeholder (misal IDE untuk menganalisa dan mendesign perangkat lunak) sehingga memudahkan dalam kerja sama tim pengembang perangkat lunak.

Pada akhirnya modern requirement mampu menghilangkan permasalah yang muncul di traditional requirement. Pembuatan requirement saat ini lebih cepat, lebih murah, dan mudah dikelola, selain itu requirement yang kurang lengkap dan tidak konsisten, ambigu, susah dimengerti lebih mudah diketahui dan diperbaiki karena fasilitas evaluasi modern requirement yang bisa melakukan review dan perubahan requirement di repository dengan mudah dan cepat.
Modern Requirement tool

Terdapat beberapa tool yang medukung modern requirement diantaranya adalah iRise Application Simulator. Tujuan dari iRise adalah memungkinkan bisnis analis / requirement engineering untuk mengembangkan requirement sekaligus dengan membuat simulasi aplikasi sehingga ketidaksamaan persepsi requirement dapat dihindari antar stakeholder. Selain itu terdapat JIRA , yang merupakan bug, issue tracking, dan project manajement system. JIRA didesain dengan focus penyelesaian tugas dengan mudah dan fleksibel. Selain itu memungkinkan untuk menuliskan fungsional baru sehingga JIRA bisa dipergunakan sebagai requirement repository.
Sumber :

1. http://romisatriowahono.net
2. http://en.wikipedia.org/wiki/Requirement
3. http://www.irise.com/products/
4. http://www.atlassian.com/beyond/go_beyond.jsp
5. http://santang.wordpress.com/2008/10/16/software-dan-karakteristiknya/

Wednesday, November 5, 2008

Konsep OOP

Konsep OOP di Java


Pemrograman berorientasi objek diciptakan untuk mempermudah pengembangan program dengan cara mengikuti model yang telah ada dalam kehidupan nyata. Dalam paradigma ini, sesuai dengan model kehidupan nyata, segala bagian dari suatu permasalahan adalah objek. Objek-objek ini kemudian juga dapat berupa gabungan dari beberapa objek yang lebih kecil. Sebagai contoh adalah sebuah mobil. Mobil adalah sebuah objek dalam kehidupan nyata. Namun mobil sendiri terbentuk dari beberapa objek yang lebih kecil seperti roda ban, mesin, jok, dll. Mobil sebagai objek yang merupakan gabungan dari objek yang lebih kecil dibentuk dengan membentuk hubungan antara objek-objek penyusunnya. Begitu juga dengan sebuah program. Objek besar dapat dibentuk dengan menggabungkan beberapa objek-objek dalam bahasa pemrograman. Objek-objek tersebut berkomunikasi dengan saling mengirim pesan kepada objek lain.


Konsep-konsep pemrograman berorientasi objek dalam Java secara umum sama dengan yang digunakan oleh bahasa-bahasa lain. Jadi kebanyakan konsep yang ada dalam java juga terdapat dalam bahasa selain Java. Namun, terkadang terdapat perbedaan-perbedaan kecil antara penerapan konsep-konsep tersebut dalam masing-masing bahasa.


Objek


Baik dalam dunia nyata atau dalam sebuah program, sebuah objek memiliki dua karakteristik, yaitu state dan behaviour. State adalah keadaan dari sebuah objek, seperti mobil memiliki state warna, model, tahun pembuatan, kondisi, dll. Sedang behaviour adalah kelakuan dari objek tersebut, seperti mobil dapat melaju, membelok, membunyikan klakson, dll. Objek menyimpan statenya dalam satu atau lebih variabel, dan mengimplementasikan behaviournya dengan metode. Dengan penjelasan di atas, dapat disimpulkan bahwa objek adalah bagian software yang dibentuk dengan variabel-variabel dan metode-metode yang berhubungan dengan variabel tersebut.


Dengan karakteristik tersebut, kita dapat memodelkan berbagai objek dalam kehidupan nyata ke dalam objek-objek dalam sebuah program. Lebih lanjut kita dapat memodelkan objek-objek abstrak ke dalam sebuah program. Contoh umum untuk konsep abstrak seperti ini adalah objek Event, yaitu objek untuk mewakili peristiwa klik atau tombol ditekan.
Sebuah objek yang dibentuk dari sebuah kelas biasa disebut instans dalam terminologi OOP. Artinya objek tersebut adalah wujud nyata dari sebuah kelas. Variabel dan metode dari instans ini disebut variabel instans dan metode instans. Setiap instans menyimpan variabelnya sendiri-sendiri, jadi nilai variabel untuk tiap instans bisa berbeda.



Kelas


Kelas adalah semacam cetakan, atau template, untuk membuat objek. Ibaratkan sebuah rancangan rumah yang digunakan untuk membangun ratusan rumah. Rumah yang dibangun tersebut adalah objek dari kelas rancangan rumah. Hal ini dapat dilakukan karena semua objek rumah yang dibangun memiliki karakteristik yang sama, sehingga dapat dibuatkan semacam blueprint­nya. Tetapi objek-objek yang dibangun tetap akan memiliki bentuk fisik tertentu sendiri-sendiri, seperti variabel dalam sebuah program, atau pintu sebuah objek rumah. Dengan penjelasan ini, kelas dapat kita definisikan kembali menjadi sebuah blueprint, atau prototipe, yang mendefinisikan variabel dan metode yang sama untuk semua objek sejenis. Sebagai contoh, misalkan kita ingin membuat kelas Rumah, maka kita harus membuat sebuah kelas yang mendefinisikan semua variabel yang dimiliki objek dari kelas tersebut. Selain itu, kelas tersebut juga harus mendeklarasikan metode-metode yang dimiliki objek dari kelas dan juga membuat implementasi dari metode tersebut. Dengan adanya kelas ini, kita dapat membuat sebanyak apapun objek-objek rumah yang sejenis, yaitu jenis yang didefinisikan oleh kelas Rumah. Setiap objek Rumah diciptakan, sistem akan mengalokasikan sejumlah memori untuk objek tersebut dan variabel-variabelnya. Dengan begitu setiap objek akan memiliki salinan masing-masing untuk setiap variabel instans.

Setelah mengenal konsep kelas, berikutnya variabel kelas. Variabel kelas sebenarnya sama dengan variabel instans. Bedanya adalah, setiap objek berbagi satu dan hanya satu variabel kelas, tapi masing-masing memiliki salinan dari variabel instans. Misalkan kelas Rumah yang kita buat hanya akan mendukung 2 lantai, dan setiap objek Rumah terdiri atas 2 lantai. Maka informasi ini cukup disimpan satu kali, karena nilainya tidak berbeda untuk semua objek. Lebih jauh, bila ada satu objek yang mengubah nilai dari variabel kelas, maka semua objek sejenis lainnya akan mengikuti perubahan itu. Di samping variabel, terdapat juga metode kelas. Metode jenis ini dapat langsung dipanggil melalui kelas dan bukan dari instans kelas tersebut.


Contoh Kelas dan Objek
class Rumah
{
String warna;
String luas;
int type;
}

public class RumahBeraksi
{
public static void main(String[] args)
{
Rumah rumahku = new Rumah();
rumahku.warna="Biru";
rumahku.luas="120 M2";
rumahku.type=45;

System.out.println("Warna Rumahku : " + rumahku.warna);
System.out.println("Luas Rumahku : " + rumahku.luas);
System.out.println("Type Rumahku : " + rumahku.type);
}
}

Pewarisan


Terminologi asing untuk pewarisan adalah inheritance. Mungkin dalam literatur lain kita akan sering menjumpai istilah ini. Secara gamblang, pewarisan berarti sebuah kelas mewarisi state dan behaviour dari kelas lain. Sebagai contoh, sebuah kelas RumahMewah akan mewarisi state dan behaviour dari kelas Rumah. Begitu juga dengan kelas RumahSederhana. Kelas RumahMewah dan RumahSederhana disebut subkelas, atau kelas anak, dari kelas Rumah, yang disebut superkelas, atau kelas induk.


Seluruh subkelas akan mewarisi (inherits) state dan behaviour dari superkelasnya. Dengan begitu, semua subkelas dari superkelas yang sama akan memiliki state dan behaviour yang sama. Namun, masing-masing subkelas bisa menambah sendiri state atau behaviournya. Misalkan, pada kelas Rumah tidak terdapat variable kolamRenang, namun subkelas RumahMewah memiliki variabel tersebut. Contoh lain misalnya kelas Rumah tidak memiliki metode nyalakanAlarm, namun rumah mewah memiliki metode itu.
Dalam kasus tertentu subkelas mungkin memiliki implementasi behaviour yang berbeda dengan superkelasnya. Hal seperti ini disebut override. Contohnya subkelas SepedaBalap memiliki implementasi metode ubahGigi yang berbeda dengan implementasi metode tersebut pada superkelas Sepeda.


Tingkat pewarisan tidak hanya terbatas pada dua tingkatan. Dari contoh di atas, kita bisa saja membuat subkelas dari kelas SepedaBalap, dan seterusnya. Kita bisa terus memperpanjang tingkat pewarisan ini sepanjang yang kita butuhkan. Dengan begitu, subkelas-subkelas yang dibuat akan lebih khusus dan lebih terspesialisasi. Namun terdapat batasan pewarisan dalam Java yang disebut single inheritance. Artinya sebuah kelas hanya dapat mewarisi sifat dari satu dan hanya satu superkelas saja. Dalam beberapa bahasa pemrograman berorientasi objek lain, yang berlaku adalah multiple inheritance. Artinya sebuah kelas dapat mewarisi sifat dari beberapa superkelas sekaligus.


Dalam Java, terdapat kelas Object yang merupakan superkelas dari semua kelas dalam Java, baik yang builtin ataupun yang kita buat sendiri, lansung maupun tidak langsung. Karena itu sebuah variabel bertipe Object akan dapat menyimpan referensi ke objek apapun dalam bahasa Java. Kelas Object ini memiliki behaviour yang dibutuhkan semua objek untuk dapat dijalankan di Java Virtual Machine. Sebagai contoh, semua kelas mewarisi metode toString dari kelas Object, yang mengembalikan representasi String dari objek tersebut.


Manfaat penggunaan konsep pewarisan antara lain: pertama, kita dapat menggunakan kembali kelas-kelas yang kita buat (sebagai superkelas) dan membuat kelas-kelas baru berdasar superkelas tersebut dengan karakteristik yang lebih khusus dari behaviour umum yang dimiliki superkelas. Kedua, kita dapat membuat superkelas yang hanya mendefinisikan behaviour namun tidak memberi implementasi dari metode-metode yang ada. Hal ini berguna jika kita ingin membuat semacam template kelas. Kelas semacam ini disebut kelas abstrak, karena behaviournya masih abstrak dan belum diimplementasikan. Subkelas-subkelas dari kelas semacam ini, yang disebut kelas konkret, mengimplementasikan behaviour abstrak tersebut sesuai dengan kebutuhan masing-masing.


Sedikit penjelasan mengenai kelas abstrak, kelas ini bisa memiliki hanya satu atau lebih metode abstrak. Subkelas dari kelas ini bertanggung jawab untuk memberikan implementasi untuk metode-metode abstrak tersebut. Sebagai akibat dari keberadaan metode abstrak ini, kelas abstrak tidak dapat diinstanskan (dibuatkan instansnya) atau digunakan untuk menciptakan sebuah objek dari kelas tersebut.


Interface


Arti harfiah dari interface adalah antarmuka, yaitu suatu alat untuk digunakan benda-benda yang tidak terhubung secara langsung untuk berinteraksi. Dalam bahasa pemrograman, interface digunakan oleh berbagai objek yang tidak terhubung untuk saling berinteraksi. Jadi dalam bahasa pemrograman, interface dapat didefinisikan sebagai koleksi definisi metode-metode dan variabel-variabel konstan, namun tanpa implementasi. Implementasi akan dilakukan oleh kelas-kelas yang mengimplements interface ini. Tanpa implementasi di sini tidak seperti pada kelas abstrak yang merupakan metode-metode yang tidak melakukan apa-apa, melainkan hanya sekedar nama metode saja.


Sebelumnya telah disebutkan bahwa sebuah kelas tidak dapat menjadi subkelas dari beberapa superkelas, melainkan hanya bisa menjadi subkelas dari satu superkelas saja. Hal ini membuat desain program lebih rapi dan teratur, sehingga dapat mengurangi kompleksitas program. Namun, terkadang hal ini dapat menjadi suatu halangan yang tidak menyenangkan, yaitu saat kita membutuhkan suatu kelas yang memiliki sifat-sifat dari dua atau lebih kelas lain. Pada masalah seperti ini, interface dapat memberikan alternatif jalan keluar.


Dengan adanya interface maka beberapa kelas akan dapat menangani interaksi yang sama namun dengan behaviour yang bisa berbeda. Misalnya beberapa kelas mengimplementasi sebuah interface yang sama, maka kelas-kelas tersebut dapat menangani interaksi sesuai interface tersebut, namun tiap kelas dapat memiliki implementasi yang berbeda-beda. Begitu juga bila sebuah kelas mengimplementasi banyak interface, maka kelas tersebut akan dapat menangani interaksi-interaksi sesuai salah satu interface yang diimplement oleh kelas tersebut. Namun, kelas tersebut harus mengimplementasi sendiri behaviournya. Di sinilah letak perbedaan penggunaan interface dengan multiple inheritance. Dalam multiple inheritance, layaknya single inheritance, subkelas tidak harus mengimplementasikan sendiri behaviournya karena secara default kelas tersebut akan mengikuti behaviour superkelasnya.

Tuesday, May 8, 2007

Welcome to My Site

Selamat datang para bloggers at my little page. Mungkin tidak seperti yang di bayangkan, tapi lumayanlah untuk pemula.