b/hr

Seberapa besar ?

Kesulitan dalam menentukan ‘ukuran’ use case -menurut saya- mirip dengan kesulitan untuk menentukan ‘ukuran’ class. Apakah suatu fitur X cukup dijadikan sebuah use case atau harus dipecah menjadi beberapa use case ?

Menentukan use case untuk software yang akan kita buat tidak bisa dilakukan sekali jadi. Perlu iterasi yang mungkin lebih dari dua kali. Bisa jadi, saat awal kita mendefinisikan sebuah use case X, tetapi di iterasi berikutnya kita memutuskan untuk memecahnya menjadi use case X1 dan X2 (atau sebaliknya: menggabung beberapa use case menjadi sebuah use case saja). Keputusan tersebut biasanya dibuat setelah kita lebih detil menurunkan skenario use
case atau saat kita sudah mulai melakukan analisis use case (lihat realisasi use case).

Salah satu pedoman yang bisa digunakan adalah dengan melihat kelas-kelas yang berhasil diidentifikasi untuk use case tersebut, serta melihat kolaborasi antar class untuk setiap skenario use case. Jika skenario-skenario use case memperlihatkan kolaborasi class yang berbeda, mungkin itu adalah pertanda bahwa use case bisa dipecah. Jika hasil identifikasi class menunjukkan jumlahnya yang terlalu sedikit (kurang dari 3 misalnya), mungkin itu pertanda bahwa ‘ukuran’ use case kita terlalu kecil.

Kecil atau besar ?  Mana yang lebih baik ? Seperti class jika use case kita terlalu kecil, use case kita memang jadi lebih generik, tetapi kita akan kesulitan mengelola sekian banyak use case. Jika use case terlalu besar, fitur yang dimodelkan jadi terlalu spesifik sehingga akan sulit di-reuse. Jadi, carilah ‘ukuran’ yang paling optimal, yang sedang-sedang saja…

Safe Programming

Safe programming adalah bagian dari dependable programming, yaitu pemrograman yang memanfaatkan teknik dan programming constructs yang bisa mendukung fault avoidance dan fault tolerance. Fault pada program biasanya terjadi karena programmer melakukan kesalahan. Bisa kesalahan dalam menginterpretasikan spesifikasi program yang seharusnya dibuat, atau karena program yang over-complex, atau karena penggunaan programming construct yang rawan menyebabkan error.

Salah satu usaha yang dapat dilakukan untuk meningkatkan dependability dari kode program kita adalah dengan menerapkan safe programming, dimana kita menghindar sebanyak mungkin dari penggunaan programming construct yang rawan menyebabkan error. Berikut beberapa contohnya:

• penggunaan floating point number; sering menyebabkan kesalahan saat kita melakukan operasi pembandingan…
• pointers; ini adalah low-level construct yang menunjuk alamat memori
• dynamic memory allocation; memori yang dialokasi saat run-time seringkali lupa untuk didealokasi…
• parallelism; agak sulit memprediksi efek dari interaksi antar proses…
• recursion; konstruksi program memang jadi lebih bersih, tetapi agak sulit menelusuri lojik program…
• penggunaan interrupt yang bisa mengakibatkan terhentinya proses yang kritis…
• inheritance pada OOP yang sulit ditelusuri karena kode yang tersebar…
• dan masih banyak lagi…

Beberapa project yang kritis dengan sengaja melarang penggunaan programming construct yang rawan menyebabkan error ini. Beberapa bahasa pemrograman sudah menghilangkan programming contruct tsb (misalnya Java yang tidak lagi mengenal pointer dan menyediakan mekanisme garbage collection).

Dengan mengetahui adanya beberapa programming construct yang ‘berbahaya’ tersebut, bukan berarti kita harus meninggalkannya. Tapi kita harus lebih berhati-hati dan melakukan pengujian yang lengkap…

Boleh beli juga ?

Setiap hari Jum’at di Sekolah Alam Bandung adalah hari wirausaha. Pada hari itu, siswa dianjurkan untuk berjualan apa saja. Jadilah sejak pagi Jum’at kemarin saya sudah sibuk membuatkan penganan untuk jualan. Saya buatkan makaroni plus sosis yang dimasak ala fetuccini-nya Pizza Hut. Makaroninya saya pilih yang berbentuk spriral, daging asap diganti irisan sosis, dan cream-nya diganti dengan susu. Untuk Kiki (3 SD) saya buatkan 10 paket yang katanya mau dijual @ Rp 1.500,- dan untuk Didit (TK A) saya buatkan 10 paket (lebih kecil) yang siap dijual @ Rp 500,-

Siangnya saya cek: jualan Kiki habis semua dan jualan Didit sisa satu. Horeee… hari ini sukses…

Tapi hari itu Kiki jadi jajan lebih banyak (karena merasa punya banyak uang), sementara uang Didit utuh sama sekali. Saya jadi heran, kenapa Didit tidak tergoda untuk jajan ya ?

Malamnya Didit tanya, “Ibu, kalo aku jualan, boleh nggak aku juga beli-beli ?” Rupanya dia bingung, kalau jadi penjual apa boleh jadi pembeli juga…

Temu Alumni IF di Arkavidia

Sabtu 4 April lalu saya hadir di acara Temu Alumni Informatika. Entah memang berbeda, alumni yang hadir adalah alumni Program Sarjana Teknik Informatika (tidak ada alumni Program Magister atau Doktor). Temu Alumni ini adalah bagian dari rangkaian kegiatan HMIF ITB yang bertajuk Arkavidia.

Kesempatan berkumpul dan bertemunya rekan-rekan alumni dimanfaatkan dengan me-review organisasi Ikatan Alumni Informatika ITB yang selama ini relatif kurang ‘terdengar’ . Sejumlah rencana dibuat dan dijadwalkan untuk memperbaiki organisasi ini.

Yang agak ‘lain’ adalah alumni yang hadir kebanyakan dari angkatan senior. Kalau tidak salah hitung, yang paling banyak hadir adalah yang angkatan 86 dan 87. Angkatan mudanya malah minim sekali. Angkatan saya (89) diwakili 3 orang (4 orang kalau melihat definisi NIM). Itupun dua diantaranya tuan rumah…

Kondisi seperti ini menunjukkan apa ya ??

Diskusi Ka Prodi IF, Ketua IA IF ITB, dengan moderator Dody ‘89 beserta para juniornya…

Angkatan 89++

Belajar Pemrograman vs Bahasa Pemrograman

Di Prodi Teknik Informatika ITB, belajar pemrograman tidak sama dengan dengan belajar bahasa pemrograman. Saya sendiri mengalami masa-masa menjadi mahasiswa. Belajar pemrograman adalah belajar memecahkan masalah dengan cara-cara yang relatif bisa dipastikan benarnya. Ya, ada skema-skema yang sudah pasti benarnya (tidak ‘bocor’ dan mengandung bug), yang sebaiknya digunakan saat kita menyelesaikan persoalan tertentu. Notasi yang digunakan bisa berupa notasi algoritmik, bisa juga bahasa pemrograman tertentu. Selanjutnya, jika ingin belajar bahasa pemrograman tertentu, misalnya untuk mengerjakan tugas atau bahkan tugas akhir, maka kita dipersilahkan untuk belajar sendiri.

Di kuliah PBO (Pemrograman Berorientasi Objek) sendiri, yang ingin diajarkan adalah berbagai konsep pemrograman berorientasi objek seperti kelas, objek, inheritance, polimorfisme, dan lain-lain. Kemudian, dijelaskan singkat implementasi konsep-konsep tersebut pada bahasa tertentu seperti C++ dan Java. Karena itu, sesi kuliah khusus tentang C++ dan Java tidak terlalu panjang dan detil…

Untuk peserta kuliah PBI, selamat mengerjakan Tugas Besar. Mungkin terasa sulit ya, tetapi pasti menyenangkan …

Document Object Model (DOM)

Document Object Model (DOM) adalah rekomendasi dari W3C untuk melakukan proses terhadap dokumen terstruktur seperti XML dan HTML. DOM didefinisikan sebagai sebuah spesifikasi Application Programming Interface (API) yang bebas bahasa dan platform. DOM mendefinisikan struktur lojik dokumen serta cara untuk melakukan manipulasi dan akses terhadap dokumen tersebut. Saat ini W3C telah mengeluarkan tiga buah rekomendasi untuk DOM yaitu DOM Level 1, DOM Level 2 dan DOM Level 3.

DOM akan membentuk representasi logik dokumen terstruktur yang akan dimanipulasi dalam struktur pohon. Manipulasi terhadap bagian isi dari dokumen dilakukan dengan manipulasi terhadap elemen-elemen pohon ini. W3C telah menspesifikasikan beberapa prosedur untuk melakukan manipulasi terhadap struktur pohon DOM. Prosedur tersebut meliputi penambahan (adding), penghapusan (deleting) dan pemutakhiran (updating).

Untuk memanipulasi dokumen dengan DOM, suatu parser akan membentuk representasi logik dari bagian isi dokumen XML dalam bentuk struktur pohon. DOM tidak menjelaskan bagaimana melakukan parsing terhadap dokumen, pembuatan dokumen baru ataupun melakukan serialisasi terhadap dokumen. Hal ini dikarenakan DOM adalah spesifikasi yang bebas bahasa. Untuk melakukan fungsi-fungsi tersebut dibutuhkan DOM parser yang diimplementasikan kedalam berbagai bahasa pemrograman tertentu seperti C, C++, atau Java. Beberapa contoh DOM parser adalah Apache Xerces, Crimson, Oracle XML Parser for Java atau MsXML.

Activitas pengembangan DOM di W3C sudah ditutup sejak tahun 2004 dengan lengkapnya pengembangan DOM Level 3 Recommendations. Tapi saat ini W3C Web Applications Working Group sudah mulai bergerak untuk melakukan revisi. Jika tertari, diskusinya bisa diikuti di public-webapps@w3.org atau www-dom@w3.org mailing lists.