Teknologi Komponen: EJB

Enterprise JavaBean (EJB) merupakan arsitektur komponen terdistribusi untuk development dan deployment aplikasi bisnis berbasis komponen yang dikeluarkan oleh Sun Microsystem. EJB pertama kali diperkenalkan pada tahun 1997. Tahun 2006 Sun Microsystem merilis Enterprise JavaBean (EJB) versi 3.0. Spesifikasi EJB ditulis oleh JCP (Java Community Process) yang terdiri dari beberapa perusahaan seperti SUN, IBM dan Borland. Berikut adalah sekilas tentang perkembangan EJB:

• EJB 1.0 – 2.0; adalah framework standar aplikasi enterprise meliputi transaksi dan sekuriti; standarisasi style pemrograman untuk objek terdistribusi, awal dari paradigma komponen untuk penggunaan ulang kode
• EJB 2.1 (2003); ada penambahan fasilitas seperti pooling, penambahan protokol selain RMI, mis. Web Services
• EJB 3.0 (2006); ada perubahan framework sehingga menjadi jauh lebih mudah digunakan, menggunakan model POJO, dan menggunakan teknik anotasi untuk deployment yang lebih mudah

Komponen pada teknologi ini disebut juga EJB atau singkatnya bean. Ada tiga tipe komponen yaitu: entity bean, session bean, dan message-driven bean. Interface pada teknologi ini ada tiga jenis: home interface, local interface, dan remote interface.

Tertarik ? Silahkan eksplor lebih lanjut. Tutorial online-nya cukup lengkap di situsnya Sun Java.

Advanced S/W Engineering

Kuliah Advanced S/W Engineering atau RPL Lanjut adalah kuliah baru di semester I 08/09 ini. Kuliah ini adalah kuliah wajib untuk mahasiswa Prodi IF ITB yang ingin mengambil jalur RPL. Khusus semester ini, pesertanya adalah angkatan 2006 dan 2005. Materi kuliah ini harus dirancang agak lain di masa transisi kurikulum ini.

Angkatan 2006 sudah pernah kuliah RPL 4 SKS, yang di kurikulum baru jadi 3 SKS. Angkatan 2005 malah sudah kuliah RPL, PPL (Proyek P/L), dan ada yang sudah kuliah APBO (Analisis dan Perancangan Berorientasi Objek). Jadi, sebagian besar mahasiswanya sudah mendapat banyak materi.

Jadi, apa dong isi kuliah RPL Lanjut ?

Khusus untuk semester ini, kuliah RPL Lanjut sebagian besar akan diisi dengan materi tentang Web Engineering dan Real-Time S/W Engineering. Tentu saja diawali dengan overview materi di kuliah RPL yang lalu.

OK, sampai jumpa di kelas… Ayo kita sama-sama belajar…

Tugas Akhir

(Posting ini ditujukan untuk mahasiswa yang akan mulai melaksanakan tugas akhir)

Bagaimana memulai sebuah tugas akhir ? Apakah harus punya topik dulu atau pilih pembimbing dulu ?

Dua-duanya boleh… Kalau sudah punya topik, diskusikan dengan calon pembimbing di Lab yang sesuai. Jangan ragu-ragu untuk diskusi dengan lebih dari satu dosen. Diskusi akan lebih terfokus jika topik TA sudah dirumuskan dalam bentuk draft proposal.

Kalau belum punya topik, tapi sudah punya bidang minat, silahkan hubungi dosen yang sesuai (dengan bidang minat). Siapa tau dosen ybs sudah punya topik…

Kalau belum punya topik dan belum punya minat ? Jangan ragu-ragu untuk diskusi dengan beberapa dosen…

Kalau tertarik TA di Lab RPL, beberapa contoh TA sudah saya uraikan sekilas di blog ini pada kategori final project… 

UP-Based Project Management Tool

Salma (2002) mengembangkan tool untuk manajemen proyek pembangunan perangkat lunak yang menggunakan Unified Process (UP). Tool ini memungkinkan kita menjadwalkan berbagai aktivitas UP yang harus dilakukan sepanjang proses pembangunan perangkat lunak, serta realisasinya.

Sementara itu, Nonik (2002) melakukan kajian untuk menilai bobot setiap aktivitas UP. Jika digabung, hasil TA keduanya akan dapat digunakan untuk memantau kemajuan pekerjaan pembangunan perangkat lunak.

TA-TA yang menurut saya bagus dan orisinal…

Sayangnya, belum ada yang kemudian menggabungkan hasil kedua TA ini sehingga menjadi tool yang lengkap… Tool yang lengkap untuk seluruh siklus pembangunan perangkat lunak dengan Unified Process adalah salah satu topik yang saya tawarkan untuk TA di Lab RPL…

Modern ??

Adaptasi Komponen S/W

Idealnya, komponen S/W bisa langsung digunakan tanpa harus dilakukan modifikasi. Akan tetapi, seringkali terjadi kondisi dimana komponen yang akan kita gunakan perlu dimodifikasi, perlu diadaptasi. Teorinya, ada tiga kategori cara adaptasi komponen, yaitu:

1. white box; kita bisa memodifikasi source code-nya sehingga sesuai dengan kebutuhan. Ini bisa dilakukan jika source code komponen memang tersedia.
2. grey box; kita bisa memodifikasi komponen dengan memanfaatkan API yang disediakan oleh pembuat komponennya. Modifikasi ini akan lebih mudah, karena kita tidak perlu paham terlalu detil mengenai implementasi komponen tersebut.
3. black box; komponen seperti ‘kotak hitam’; kita harus menggunakan apa adanya. Adaptasi dilakukan dengan pre-processing terhadap data masukan atau post processing terhadap data keluaran komponen. Kita membuat ‘adapter’ agar komponen bisa match dengan kebutuhan kita tanpa dimodifikasi.

Itu teorinya. Kenyataannya ? Silahkan berbagi pengalaman…

Pengujian yang berhasil

Pengujian (testing) S/W yang disebut berhasil adalah pengujian yang berhasil menemukan banyak kesalahan. Artinya, kasus uji yang dirancang berhasil menjaring kesalahan pada S/W. Kesalahan akan banyak ditemukan apabila kita mendefinisikan kasus uji yang cukup lengkap, yaitu kasus uji yang mencakup berbagai kondisi: kondisi normal dan kondisi tidak normal. Tester harus bisa memprediksi berbagai kondisi yang mungkin menyebabkan kesalahan.

Jadi, pengujian bukan dikatakan berhasil jika kita tidak menemukan kesalahan pada S/W…

The Management

When technicians go out for their nightly beer they talk about basketball…
When engineers go out together on a week-end they talk about football…
When middle management gets together, they talk about tennis….
Top management discusses golf.

Conclusion: The higher up you are in management, the smaller your balls

(www.bboxbbs.ch/home/schaendi/jokes)

A good SRS…

SRS (Software Requirement Specification) yang baik adalah yang memenuhi kriteria berikut:

• correct; setiap pernyataan kebutuhan yang disebutkan adalah benar-benar merupakan fitur yang akan disediankan S/W
• unambiguous; setiap pernyataan kebutuhan hanya punya satu interpretasi
• complete; mencakup seluruh kebutuhan (fungsional, performansi, dll), definisi respon S/W terhadap seluruh data masukan (valid dan tidak valid) dalam berbagai situasi
• consistent; konsisten dengan dokumen di level yang lebih atas (mis. system requirement)
• ranked for importance and/or stability; setiap pernyataan kebutuhan diberi identitas yang menunjukkan tingkat importance/stability-nya (misalnya: essensial, conditional, optional)
• verifiable; untuk setiap pernyataan kebutuhan, harus ada proses yang cost-effective untuk memverifikasi bahwa S/W sudah memenuhi kebutuhan tersebut
• modifiable; struktur dokumen harus sedemikian rupa sehingga pengubahan yang terjadi dapat dilakukan dengan mudah, lengkap, dan konsisten
• traceable; setiap pernyataan kebutuhan harus jelas sumbernya dan mudah diacu

(Dari IEEE Std 830-1998)

Stub vs Driver

Integration testing bisa dilakukan dengan cara top-down atau bottom up. Pada cara top-down, kita memerlukan stub, yaitu modul pengganti yang berperan sebagai modul yang akan ‘dipanggil’ oleh modul yang sedang diuji. Misalnya, kita perlu stub yang membangkitkan jam kerja secara random untuk untuk menguji modul perhitungan gaji.

Sedangkan pada cara bottom-up, kita memerlukan driver, yaitu modul pengganti yang akan ‘memanggil’ modul yang sedang diuji. Misalnya, kita perlu driver yang ‘memanggil’ fungsi hitung gaji pada modul yang sedang diuji, dengan parameter yang sesuai.

Jadi, pada struktur hirarki modul, jika kita sedang menguji modul A, maka stub adalah modul pengganti untuk modul-modul di bawah A, sedangkan driver adalah modul pengganti untuk modul-modul di atas A.