Nostalgia…

Sabtu (21 Feb) kemarin saya hadir di acara reuni SMA 8 Bandung untuk para alumni lulusan tahun 89 (reuni adalah salah satu dampak dari semakin populernya software untuk social-networking). Jadi, sudah 20 tahun sebagian besar dari kami tidak bertemu. Ada banyak cerita bahagia, ada juga cerita sedih. Salah satunya adalah telah wafatnya beberapa guru-guru kami dan rekan-rekan kami. Tiga diantara rekan yang telah wafat itu pernah jadi teman sekelas saya…

Agak kaget juga saat bertemu para guru yang ternyata banyak yang sudah sepuh. Ya, 20 tahun telah benar-benar berlalu. Saat-saat seperti ini biasanya mengingatkan saya bahwa saya sudah tidak muda lagi (saya selalu merasa muda karena selalu dikelilingi para anak muda ).  Jatah umur tentunya semakin berkurang. Apa yang telah saya lakukan 20 tahun ini ya ?? Mudah-mudahan sebagian besarnya dicatat sebagai bagian dari amal kebaikan…

Berikut ini adalah salah satu foto saat reuni (alumni kelas Fisika-3):

The Problem of Multiple Inheritance

Ya, meskipun konsep multiple inheritance itu diperlukan, ternyata ada masalah untuk diimplementasikan. Sesuai dengan konsepnya, inheritance memungkinkan kita mengakses data (atribut/data slot) atau meng-invoke method pada suatu objek yang tidak didefinisikan pada kelas objek tsb. Compiler akan mencarikannya di kelas-kelas ancestor-nya. Pada single inheritance, algoritme pencarian data atau method tsb tidak terlalu sulit. Compiler tinggal mencari ke definisi kelas parent-nya. Jika tidak ada, terus dicari ke kelas parent dari parent-nya, dst-nya sampai ketemu atau sampai di ujung inheritance-chain (akan ada pesan error jika tidak ketemu).

Nah, pada multiple inheritance, algoritma pencarian menjadi lebih rumit, karena parent sebuah kelas bisa lebih dari satu. Kemana compiler harus mulai mencari, ke parent A-kah atau parent B dulu ? Perlu backtrack jika di satu path tidak ketemu. Belum lagi jika ada shared-parent, masalah bertambah lagi. Atau jika ada lebih dari satu data slot atau method dengan nama yang sama, hingga terjadi clash…

Beberapa bahasa pemrograman berorientasi objek menggunakan pendekatan yang berbeda-beda untuk penanganan masalah-masalah tersebut. Akan tetapi, dari beberapa literatur dinyatakan bahwa penanganan masalah ini belum dianggap mature…

Yang perlu diperhatikan adalah, dengan adanya perbedaan pendekatan dan penanganan di berbagai bahasa, berhati-hatilah jika akan berpindah bahasa. Pastikan bahwa hasil optimal yang sudah dicapai di suatu bahasa tidak jadi salah setelah program anda di-porting ke bahasa yang lain.

Gunakan multiple inherintance hanya jika benar-benar dibutuhkan saja. Hindari jika bisa…

Kenapa perlu standard ?

Secara umum, keuntungan menggunakan standard tertentu untuk suatu hal adalah agar kita bisa memprediksi kualitas. Suatu hal dijadikan standard tentunya setelah diuji-coba dan terbukti menghasilkan produk -dimana standard tsb diterapkan- yang berkualitas baik. Selain itu, apabila kita terbiasa menggunakan standard, maka kita sudah punya bayangan relatif jelas tentang hal yang harus dilakukan. Tidak ada effort lagi untuk belajar hal baru.

Hal yang sama terjadi jika kita mengadopsi suatu standard dalam membuat berbagai artifak dalam pembangungan software.  Kita tidak bingung lagi untuk mendefinisikan apa saja yang harus ada dalam suatu artifak, mis. SRS (Software Requirement Specification). Saat lain, kita tidak bingung ketika harus ‘membaca’ dan memahami suatu SRS misalnya.

Yang harus diperhatikan adalah bagaimana kita bisa memilih standard yang paling sesuai dengan kebutuhan. Tentunya, kita perlu sedikit mempelajari terlebih dahulu beberapa standard hingga akhirnya bisa memilih salah satu yang paling pas.  Atau, mencari informasi tentang berbagai pengalaman praktis penerapan standard pada suatu proyek. Banyaknya standard memang membuat bingung. Seperti pada gambar di posting yang lalu.

Jadi, untuk sesuatu hal yang harus kita lakukan berulang-ulang, dengan harapan dapat menghasilkan produk yang kualitasnya relatif sama, pastikan kita mengadopsi standard tertentu…

Green Computing

Gerakan hijau atau gaya hidup hijau ternyata sudah merambah ke berbagai bidang, termasuk salah satunya bidang IT. Gerakan atau gaya hidup ini berkaitan dengan isu peduli/ramah lingkungan. Para vendor IT sudah mulai bergerak dengan memproduksi berbagai produk yang hemat energi, berbagai produk dengan material dan kemasan yang ramah lingkungan…

Lalu, bagaimana dengan kita, para konsumen ? Kita bisa berperan dengan menjadi konsumen hijau. Beberapa yang disarankan antara lain:

• mempertahankan perangkat keras selama mungkin; tidak selalu tergoda untuk memperbaharui sistem operasinya…
• menghemat penggunaan berbagai bahan habis seperti kertas dan tinta
• menggunakan barang (hampir) bekas

Kita sering tergoda untuk upgrade perangkat karena sudah tidak puas dengan performansi perangkat lama. Padahal sebenarnya, kebutuhan kita tidak sampai sebesar itu. Upgrade sistem operasi juga seringkali menjadi penyebab kebutuhan upgrade perangkat, karena fitur sistem operasi yang baru membutuhkan resources yang lebih besar. Yang harus disadari adalah bahwa kalau kita ganti perangkat, maka perangkat lama akan menambah jumlah sampah elektronik.

Barang (hampir) bekas mungkin masih bisa digunakan kalau sesuai dengan kebutuhan kita. Bisa barang second ataupun refurbished (barang second yang sudah dikembalikan ke kondisi awal oleh produsennya).

Nah, siapkah kita berpartisipasi dalam gerakan hijau ini ??

(dari suplemen majalah Info Komputer)

Software Technology Maturation

Samuel Redwine dan William Riddle (1985) me-review sejumlah software technology untuk melihat bagaimana teknologi tersebut dibangun dan dikembangkan. Mereka menemukan fakta bahwa suatu teknologi akhirnya masuk ke tahap popular setelah 15 sampai 20 tahunan. Mereka juga mengidentifikasi enam tahapan yang dilalui agar mencapai tahap popular tersebut, sbb:

• Basic research; investigasi berbagai ide dasar dan konsep, serta membentuk struktur awal problem…
• Concept formulation; mengumpulkan ide-ide secara informal, membentuk komunitas riset, mempublikasikan contoh solusi untuk problem tertentu…
• Development and extension; mulai memanfaatkan teknologi (preliminary use), memperjelas ide-ide yang mendasarinya, membuat berbagai generalisasi (tidak lagi spesifik problem tertentu)…
• Internal enhancement and exploration; memperluas pendekatan ke domain lain, memanfaatkan teknologi untuk menyelesaikan real problem, membangun berbagai materi pelatihan, mempublikasikan berbagai nilai tambah…
• External enhancement and exploration; sama dengan di atas, tetapi melibatkan komunitas yang lebih luas, memperlihatkan berbagai bukti adanya nilai tambah dan kemungkinan pemanfaatannya (applicability)…
• Popularization; mendefinisikan kualitas, menyediakan versi-versi terbaru dari teknologi, komersialisasi dan pemasaran, memperluas komunitas pengguna…

Jadi, bersabarlah kalau kita punya ide baru. Butuh komitmen, konsistensi dan waktu tahunan untuk sampai tahap popular…

Empat sekawan…

Ini bukan tentang perkawanan biasa. Ini adalah empat sekawan yang perlu diperhatikan saat kita membuat definisi kelas:

1. Constructor (ctor); member function yang secara otomatis akan dipanggil jika ada penciptaan sebuah objek; tentukan apakah cukup dengan default ctor saja atau perlu didefinisikan user-defined ctor…
2. Destructor (dtor); member function yang secara otomatis akan dipanggil jika ada pemusnahan objek…
3. Copy constructor (cctor); member function yang secara otomatis dipanggil jika ada penciptaan sebuah objek baru dengan cara menduplikasi dari objek yang sudah ada;  perlu dibuat, jika ada data member berupa pointer (jika tidak, yang dijalankan adalah bitwise copy)…
4. Operator assignment (=); member function yang melakukan overload terhadap operator assignment (=); perlu dibuat untuk kasus-kasus tertentu…

Jadi, jangan lupakan empat sekawan di atas…

Realisasi Use Case

Setelah mendefinisikan kebutuhan dalam bentuk use case, bagaimana merealisasikannya ? Setiap use case harus dibuat deskripsinya lengkap dengan berbagai kemungkinan skenarionya. Skenario memberi gambaran bagaimana interaksi actor dan sistem. Selanjutnya, kita bisa mulai mengidentifikasi objek-objek apa saja yang akan terlibat dalam suatu use case (breakdown dari ’sistem’). Tentu saja dengan mengacu deskripsi skenario yang telah dibuat. Kemudian gambarkan dalam bentuk diagram interaksi (boleh collaboration diagram atau sequence diagram) agar lebih jelas bagaimana sebuah skenario berjalan dalam terminologi kolaborasi antar objek. Ya, pada paradigma berorientasi-objek, suatu skenario berjalan melalui kolaborasi antar objek. Dari diagram interaksi tersebut, selanjutnya kita gambarkan diagram kelas. Diagram ini menunjukkan kelas-kelas yang harus ada agar objek-objek yang dibutuhkan bisa diinstansiasi dari kelas-kelas tersebut. Diagram kelas menunjukkan berbagai jenis relasi antar kelas. Relasi ini harus konsisten dengan diagram interaksi objek yang sudah kita buat sebelumnya.

Realisasi use case dilakukan di tahap analisis dan berlanjut di tahap design. Bedanya, realisasi use case tahap analisis melibatkan objek dan kelas  tahap analisis, sedangkan realisasi use case tahap design melibatkan objek dan kelas tahap design. Apa bedanya ? Lihat lagi posting OOA vs OOA…

Software vs Budaya

Dari talk show di Software Vaganza Jum’at lalu, ada beberapa hal yang menarik untuk dicatat. Dibuka oleh Pak Windy sebagai moderator yang bertanya tentang peluang IT -khususnya software- di masa yang akan datang, Pak Armein mengemukakan bahwa peran software akan semakin besar, bahkan berpotensi besar untuk mempengaruhi budaya. Karena itu, adalah tanggung-jawab moral bagi para software engineer untuk merancang software yang membawa pengaruh positif terhadap budaya. Facebook misalnya, saat ini cenderung membuat kita lebih dekat dengan ‘teman’ yang lokasi fisiknya jauh, dibandingkan dengan tetangga atau teman kost di dekat kita (secara fisik). Software adalah sarana yang seharusnya membantu kita untuk menjadi lebih mudah melakukan berbagai hal. Misalnya, perangkat musik yang cukup rumit bisa digantikan dengan software tertentu. Dan Pak Armein pun menyumbangkan ’suara emasnya’ diiringi musik dari perangkat mobile-nya…

Pak Riki dari Kominfo menceritakan tentang usaha-usaha pemerintah untuk memanfaatkan software dalam rangka membangun good governance. Ya, dengan bantuan software, kontrol dan transparansi menjadi lebih mudah. Keteraturan dan disiplin bisa dibangun dengan lebih mudah. Selain itu, ‘budaya’ untuk menggunakan software legal atau open source software juga masih disosialisasikan pemerintah ke seluruh Pemda…

‘Budaya’ anak muda yang senang bermain game juga jadi peluang. Mas Octa dari Sangkuriang Studio berbagi pengalaman tentang pembuatan game Nusantara Online dan kiprahnya di tingkat Asia Pasifik. Kita (Indonesia) ternyata tertinggal beberapa tahun, tetapi justru jadi peluang tersendiri…

Nah, tantangan lagi untuk para software engineer ya…

Belajar konsep OOP…

Belajar konsep OOP (object-oriented programming) ternyata agak sulit apabila belum belajar beberapa konsep  Sistem Operasi. Bagaimana memori dikelola (memory management), bagaimana sebuah  sebuah proses dialokasi di memori,  bagaimana sebuah statement program dieksekusi…

Saat belajar konsep OOP, saya harus menjelaskan konsep code sharing atau alokasi memori untuk object saat runtime, apakah di stack memory atau di heap memory, yang memerlukan beberapa pemahaman konsep di atas (paragraf pertama). Belum lagi kalau masuk ke eksekusi kode. Beberapa pengetahuan yang dibahas di kuliah Pembangunan Kompilator akan sangat bermanfaat.

Kenapa pula harus belajar sampai ke konsepnya ? Tentu saja agar kita tidak terjebak pada hanya belajar bahasa pemrograman tertentu saja. Kita tahu ‘isi’-nya, sehingga kita bisa memanfaatkannya secara maksimal saat kita membuat program. Kita juga bisa dengan mudah berpindah dari satu bahasa ke bahasa lainnya.

Jadi, jika saat ini belajar konsep OOP masih sulit dipahami atau dibayangkan, pelajari kembali saat anda mulai paham konsep-konsep terkait lainnya…

Jum’at ini: Software Vaganza 2

Software Vaganza ke-2 akan dilaksanakan Jum’at 13 Februari 2009 mulai jam 9 pagi di Galeri Utama Campus Center Timur ITB. Acara ini terbuka untuk umum dan gratis. Rencananya, akan ada acara talk show “IF in Triple E for Life“, talk show “IF Inside“, serta demo dan pameran software produk mahasiswa dan alumni Prodi Teknik Informatika. Selain itu,  akan ada workshop singkat tentang website technology. Khusus workshop, tempat sangat terbatas sehingga calon peserta harus mendaftarkan diri terlebih dahulu (siapa cepat dia dapat).

Harapannya, acara ini akan lebih membuat para pengunjung lebih mengenal Informatika, serta peluangnya (terutama pemanfaatan software) di berbagai bidang…

Acara ini diselenggarakan oleh Prodi Teknik Informatika ITB, dan dipersiapkan oleh panitia yang sebagian besar anggotanya adalah para mahasiswa asisten laboratorium pendukung Prodi Teknik Informatika ITB. Terima kasih atas seluruh kerja kerasnya…