Dalam generative programming, kita juga akan menemukan konsep Aspect-Oriented Programming serta Generic Programming. Dapat dikatakan bahwa dengan mempelajari generative programming, kita akan mempelajari berbagai konsep/paradigma sekaligus. Ini dapat menjadi nilai tambah tersendiri.

Bagi yang berminat mempelajari Generative Programming dapat membaca tesis Generative Programming – Principles and Techniques of Software Engineering Based on Automated Configuration and Fragment-Based Component Models

Berbagai paper/jurnal tersedia secara online, maupun buku Generative Programming edisi cetak.

Fakta yang ada, Informatika cenderung bukan eksakta, Informatika cukup sulit digolongkan sebagai suatu ilmu (science), rekayasa (engineering), atau bahkan seni (art). Tidak seperti science atau engineering lainnya, Informatika minim standarisasi dan banyak berisi perdebatan serta klaim-klaim yang cenderung membuatnya malah mirip ilmu sosial.

Misal, kita bertanya pada para Fisikawan, apa itu geombang supersonik? apa itu kecepatan cahaya? apa itu medan elektromagnetik? apa perbedaan kecepatan dengan percepatan? maka kita akan dapatkan jawaban seragam walaupun dari sumber yang berbeda-beda. Hal ini tidak berlaku di Informatika.

Contoh pertanyaan sederhana seputar informatika:

1. Bagaimana cara mengukur besarnya suatu perangkat lunak?
2. Apa perbedaan data dengan informasi?
3. Apa yang dimaksud dengan software, program, dan aplikasi?

Pertanyaan sederhana yang sangat mendasar seperti di atas saja sudah memiliki variasi jawaban yang sangat beragam, dan sebagian besar jawaban tersebut hanyalah ARGUMEN, bukan sesuatu yang pasti (dapat dibuktikan secara ilmiah) seperti pada ilmu pasti lainnya. Alhasil dunia teknologi informasi dibanjir buzzword – buzzword yang bahkan berbau hoax. Inilah fenomena yang terjadi, semua ini mungkin karena informatika memang minim standarisasi. Tapi apakah informatika membutuhkan standarisasi? Masih perlu diperdebatkan lagi.. Debat lagi, debat lagi..

1. Requirement Analysis and Specification
2. Architectural Design
3. Detailed Design
4. Coding
5. Testing

Jika kita melakukan desain dengan menggambarkan diagram kelas dengan UML, ER Diagram, Activity Diagram, Sequence Diagram, Collaboration Diagram, dsb sejatinya kita sedang melakukan perancangan arsitektur (struktur). Padahal ada dua macam perancangan, yaitu perancangan arsitektur (struktur) dan perancangan behavior (perilaku). Pada buku Software Modeling and Design disebutkan bahwa perancangan behavior (perilaku) ada pada tahap ke-3, yaitu detailed design. Perancangan ini dilakukan dengan menggunakan Program Design Language (PDL) atau pseudocode. Setelah itu baru dilakukan proses coding.

Jika kita cermati, PDL maupun pseudo code tidak terlalu populer, baik di lingkungan akademik maupun industri. Bahasa pemrograman tingkat tinggi sudah sangat ekspresif, apalagi dengan semakin banyaknya domain specific language (DSL) yang jauh lebih ekspresif lagi. Jadi boleh dikatakan bahwa tahapan PDL atau pseudocode dapat dihilangkan. Alasannya adalah perbedaan level of abstraction pada bahasa pemrograman dengan PDL atau pseudocode tidak terlalu signifikan.

Dengan kata lain, detailed design dapat dilakukan tanpa bantuan PDL atau pseudocode, melainkan langsung dengan bahasa pemrograman “asli”. Sehingga source code merupakan dokumen desain, dan coding adalah aktivitas perancangan perilaku (bahavior) suatu perangkat lunak.

Mengapa PDL atau pseudocode “gagal”? Karena abstraksi yang dilakukan tidak tepat pada tempatnya. Kalau kita ambil analogi di bidang electrical engineering, antara komponen elektronika tube dan transistor memiliki fungsi yang sama (dalam bahasa software engineering: memenuhi kebutuhan fungsional yang sama). Walalupun ’sama’, desain yang dihasilkan dapat menjadi sangat berbeda. Misal, desain amplifier dengan tube dan desain amplifier dengan transistor akan berbeda. Dalam perancangan, kita tidak bisa membuat komponen X yang merupakan abstraksi dari transistor dan tube, karena walaupun ’sama’, keduanya berbeda.

Kalau kita amati secara lebih teliti, mayoritas buku yang terbit belakangan ini sudah jarang yang menggunakan kata implementasi untuk proses coding. Coding ya ditulis coding, tanpa embel – embel implementasi.

(*) Artikel ini pendapat pribadi penulis, tidak untuk dijadikan referensi

1. Code adalah implementasi

Ini mungkin pendapat yang sudah sangat umum, tapi sebenarnya masalah ini tidak dapat dianggap sepele. Ini dapat menjadi awal dari sebuah kehancuran. Ada kesalahpahaman di sini, banyak yang menyalah artikan bahwa implementasi itu ‘tinggal mengerjakan aja, sedikit pakai otak’, mirip seperti (maaf) tukang, padahal kenyataannya di dunia software tidak seperti itu. Sehingga saat ini berkembang pendapat bahwa programming (dalam hal ini coding) adalah pekerjaan yang levelnya paling ‘rendah’, bahkan untuk lulusan S1 dianggap tidak pantas berprofesi sebagai programmer. Konon, programming itu urusan lulusan SMK. Pendapat seperti ini sangat umum di Indonesia. Akan tetapi, jika Anda lihat pekerja di luar negeri, Twitter atau Google misalnya, syarat untuk menjadi programmer (coding), ada yang sampai level Phd. Mitos ini harus dibuang jauh – jauh kalau IT Indonesia mau maju. Dampak lainnya yang dapat kita lihat, gaji programmer di Indonesia tergolong rendah, ini juga akibat dari anggapan bahwa source code adalah implementasi, sehingga programmer dapat disamakan dengan (maaf) tukang, maka programmer dapat dibayar relatif rendah. Coba saja bila anggapan yang beredar dalam masyarakat adalah source code = desain, maka kondisinya akan sangat berbeda.
Pada kenyataannya, sebenarnya source code itu adalah desain, hanya saja dia memeiliki level abstraksi yang beragam (ada yang tinggi dan ada pula yang rendah). Kita bisa saja membuat suatu source code dengan level abstraksi yang lebih tinggi daripada diagram UML sekalipun. Jadi, source code sebenarnya adalah dokumen desain, dia memiliki representasi berupa teks. Sedangkan dokumen desain lainnya yang cukup populer adalah UML, yang memiliki representasi berupa grafis.

2. Proses analisis kebutuhan dan desain tidak mempedulikan implementasi

Ini anggapan yang dapat berakibat fatal, menyebabkan kegagalan perangkat lunak. Kalau kita bandingkan dengan engineering lain, mungkin dapat dianalogikan seperti merancang alat elektronika tanpa mempedulikan hukum fisika.
Misal, seorang arsitek atau desainer perangkat lunak disuruh membuat aplikasi bioinformatika untuk membuat simulasi DNA. Kalau dia tidak mempedulikan implementasi, bagaimana mungkin dia akan menghasilkan desain suatu perangkat lunak yang dapat bekerja dengan baik pada komputer performa tinggi, baik dengan arsitektur GPU (misal nVidia Tesla), CPU (misal Intel Xeon), maupun campuran keduanya, yang notabene ketiganya memiliki arsitektur dan teknik pemrograman yang sangat berbeda. Karena ketiga arsitektur prosesor tersebut sangat berbeda, maka membutuhkan analisis dan desain yang sangat berbeda juga.
Hal lain yang mungkin terjadi adalah biaya pembuatan software menjadi sangat mahal, termasuk karena software yang dihasilkan tidak efisien sehingga kebutuhan akan hardware meningkat.

3. Dokumen perangkat lunak hanyalah analisis kebutuhan (spesifikasi) dan desain

Ini adalah salah satu akibat dengan kesalah pahaman dalam memahami bahwa source code adalah implementasi (lihat poin 1). Sejatinya source code juga termasuk dokumen analisis dan desain perangkat lunak, hanya saja pada umumnya dia memiliki level abstraksi yang lebih rendah.

4. Mempelajari “konsep pemrograman”, otomatis menguasai berbagai bahasa pemrograman

Ini salah satu upaya mencari ’silver bullet’. Seperti matematika, untuk menghitung luas persegi, anda dapat menggunakan perkalian, penjumlahan (sigma), atau integral. Perkalian, penjumlahan, dan integral merupakan bahasa matematika. Dengan mempelajari konsep menghitung luas dengan perkalian, tidak akan menjamin anda dapat menguasai konsep menghitung luas dengan menggunakan metode penjumlahan (sigma) atau integral. Jadi setelah mempelajari konsep menghitung luas dengan perkalian, kita tidak bisa berkata bahwa: “Saya telah menguasai konsep menghitung luas, apapun metodenya”. Demikian pula pada pemrograman, dengan mempelajari suatu bahasa tertentu, tidak ada jaminan dapat mengerti bahasa lainnya. Yang perlu dicatat, dalam pemrograman, konsep pemrograman tidak memonopoli ‘pemberian pengaruh’, justru sering kali bahasa pemrograman-lah yang memengaruhi konsep pemrograman, sehingga melahirkan konsep-konsep baru. Bahasa pemrograman dan konsep pemrograman merupakan dua hal yang tidak terpisahkan.

5. Perangkat lunak itu abstrak, tidak nyata. Sehingga software engineering berbeda dengan engineering lainnya

Ini biasanya menjadi ‘kambing hitam’ atas payahnya kualitas software engineering saat ini. Kalau kita telusuri, justru software engineering itu berhadapan dengan sesuatu yang sangat nyata. Kita dapat mengetahui perilaku software yang kita buat sampai pada level yang paling kecil, yaitu kode mesin. Kita tidak perlu melakukan prediksi atau eksperimen terhadap perilaku dari kode mesin tersebut, karena itu sudah pasti, kode tersebut akan dieksekusi sesuai desain arsitektur prosesor yang digunakan, kecuali ada kesalahan pada hardware. Justru engineering lainnya (engineering klasik), yang ‘dianggap berhubungan dengan BENDA NYATA’, tidak memiliki kelengkapan informasi seperti ini. Seperti kita tahu bahwa sampai sekarang para ilmuan masih belum menemukan kepastian terhadap bagian terkecil dari materi, ada berbagai teori yang muncul, seperti yang dipelajari dalam fisika kuantum, string theory, dan m-theory. Justru engineering klasik itulah yang sebenarnya bermain dengan hal yang tidak nyata, karena tidak semua informasi yang tersedia telah diketahui. Sehingga engineering klasik lebih sering melakukan eksperimen daripada software engineering. Sedangkan eksperimen pada software engineering mungkin hanya dilakukan saat stress test atau pengukuran kinerja, reliabilitas, dan skalabilitas. Ini semakin memperjelas, bahwa sebenarnya eksperimen dalam software tersebut dilakukan ketika berhubungan dengan hardware, yaitu berkaitan dengan performa prosesor, memory, I/O, dsb. Akan sulit memprediksi secara akurat penurunan kinerja prosesor atau memory pada kondisi tertentu (misal suhu tertentu), kecuali melalui eksperimen. Sedangkan source code, yang menjadi inti dari software, itu sudah sangat nyata, tidak ada yang abstrak, walaupun tidak kasat mata, perilakunya dapat ditentukan secara pasti tanpa perlu melakukan eksperimen.

*ini hanya pendapat pribadi, tidak untuk dijadikan referensi

Anda pernah melihat jembatan Suramadu? Jembatan itu pasti memiliki desain, sedangkan jembatan yang berdiri kokoh menghubungkan pulau Jawa dengan pulau Madura tersebut merupakan implementasi dari desain tersebut.
Bisakah kita menyeberang dari pulau Jawa ke pulau Madura dengan desain jembatan Suramadu? Jelas tidak bisa.
Bisakah kita menyeberang dari pulau Jawa ke pulau Madura dengan implementasi jembatan Suramadu? Bisa.
Dari sini bisa disimpulkan bahwa sesuatu dikatakan sebagai implementasi jika dapat digunakan oleh end-user.

Sebagai perbandingan, sekarang banyak software open source, ambil satu contoh Mozilla Firefox. Anda dapat mengunduh file installer (binary) maupun source code-nya.
Pertanyaan yang sama, kalau saja source code itu dianggap sebagai implementasi, bisakah kita menjelajahi halaman web dengan source code Firefox? Tidak bisa.
Bagi yang tetap bersikeras mungkin akan mengatakan bisa, asal source code tersebut di-compile dulu. Nah, pendapat seperti ini justru semakin mempertegas bahwa source code bukanlah implementasi, karena masih harus di-compile atau di-interpret dulu, atau dengan kata lain SOURCE CODE HARUS –DIIMPLEMENTASIKAN– OLEH COMPILER MAUPUN INTERPRETER SUPAYA DAPAT DIGUNAKAN OLEH END USER.

Mungkin masih ada lagi pendapat yang mengatakan bahwa setelah source code, tidak ada lagi campur tangan manusia, proses kompilasi dilakukan sepenuhnya oleh mesin, sehingga source code dianggap sebagai implementasi. Menurut saya pendapat ini tidak valid karena seharusnya suatu aplikasi juga dapat di-generate secara otomatis (dari diagram UML misalnya) tanpa melibatkan coding yang dilakukan oleh manusia. Kalau kasus ini apakah diagram UML dianggap sebagai implementasi?

Source Code = Design atau Implementasi?

Tulisan ini sebagai tanggapan atas pendapat yang menyatakan bahwa programmer/coder = do-er dan programming/coding = implementation.

Sebelum melanjutkan studi di teknik informatika (rekayasa perangkat lunak aka software engineering), saya sempat mengenyam pendidikan teknik elektro (informatika) di salah satu PTN. Saya diajari menghitung rangkaian elekrik dan juga merancangnya. Rangkaian elektrik dihitung dan dirancang dengan menggunakan hukum-hukum yang berlaku, misal hukum Ampere.
Dalam merancang, digunakan gambar rangkaian elektrik. Misal gambar rangkaian penyearah arus seperti di bawah ini:

Rangkaian Penyearah Arus

Gambar tersebut menjadi acuan kita dalam membuat sirkuit PCB (Printed Circuit Board). Misal, dari gambar tersebut, dapat menghasilkan PCB seperti gambar di bawah ini.

PCB Rangkaian Penyearah Arus

Dua gambar tersebut adalah desain. Yang satu desain rangkaian elektrik, yang satunya lagi desain PCB. Rangkaian elektrik dapat menghasilkan berbagai gambar PCB yang berbeda, tergantung yang merancang PCB tersebut.
Dari desain PCB, kita dapat melakukan proses manufaktur untuk membuat PCB yang sebenarnya.

Terus apa hubungannya dengan Software Engineering? Kalau di Software Engineering kita sering mendengar istilah SDLC (Software Development Life Cycle). Biasanya berisi tahapan analisis – desain – implementasi – pengujian – pemeliharaan. Tahap programming atau coding biasanya dimasukkan ke dalam tahap implementasi.

Karena masuk di tahap implementasi, maka muncul pendapat bahwa yang dilakukan hanya men-translate apa-apa yang ada di desain/perancangan menjadi source code. Dan kegiatan ini (coding) dianggap tidak membutuhkan effort yang besar.

Coba kita bandingkan dengan yang terjadi pada Electrical Engineering, setelah membuat rangkaian elektrik, insinyur elektro dapat membuat gambar PCB. Tapi saya tidak pernah mendengar satu orangpun insinyur elektro yang mengatakan bahwa gambar PCB adalah implementasi, mereka sepakat bahwa gambar tersebut adalah desain. Padahal jelas-jelas PCB dibuat dengan 100% mengacu pada rangkaian elektrik. Karena membuat PCB-pun tidak sembarangan, butuh keahlian khusus, karena antara satu komponen elektrinik dengan komponen lainnya dapat saling interferensi. Selain itu PCB yang dihasilkan dapat bervariasi tergantung desainer yang membuat.
Implementasi adalah proses ketika PCB tersebut di-manufaktur/dibuat ke papan PCB kemudian komponen-komponen elektronika yang dibutuhkan dipasang (disolder) di PCB tersebut, dan perangkat tersebut dapat berfungsi sebagaimana mestinya.

Jika analogi seperti ini yang digunakan, maka coding seharusnya bukan masuk di tahapan implementasi. Karena dalam proses coding, walaupun harus 100% mengacu pada desain (yang sifatnya lebih high-level), tetap saja ada perhitungan lain yang harus dilakukan, hal ini menjadi bagian dari proses refactoring.

Lalu siapa yang melakukan impementasi? Bisa compiler atau interpreter.

Kesimpulan saya, posisi source code setara dengan posisi gambar PCB pada electrical engineering. Baik source code maupun gambar PCB adalah desain yang paling low-level.

Pendapat yang mengatakan bahwa coding hanya urusan lulusan SMK, sedangkan coding adalah pekerjaan yang ‘menjijikkan’ untuk kalangan S1 (atau lebih tinggi), adalah pernyataan yang tidak memiliki dasar ilmiah. Ini pendapat berbau ‘feodalism’.

Workers adalah proses-proses yang melakukan komputasi

Supervisors adalah proses yang memonitor perilaku workers. Supervisor akan melakukan restart terhadap workers jika terjadi hal yang salah.

Supervision tree merupakan struktur hierarki aplikasi yang tersusun atas supervisors dan workers.

Supervisor dapat melakukan supervise terhadap workers maupun supervisors.

Berikut contoh gambar supervision tree:

Supervision Tree

Keterangan:
- Kotak melambangkan supervisor
- Lingkaran menggambarkan workers

Dalam kotak (supervisor) ada yang berisi “1″ dan “a”. Kalau “1″ berarti supervisor tersebut menggunakan strategi one for one, sedangkan kalau “a” berarti supervisor tersebut menggunakan strategi one for all.

Seperti apa strategi one for one dan one for all tersebut? berikut penjelasannya.

One for one

One For One Supervision

All for one

All For One Supervision

Strategi one for one biasa digunakan bila proses-proses yang di-supervisi adalah proses yang independen, sedangkan strategi all for one digunakan bila proses-proses tersebut saling bergantung satu sama lain.

Supervision sangat populer di lingkungan bahasa pemrograman Erlang. Selain itu ada beberapa library, seperti Akka yang memiliki API untuk bahasa pemrograman Scala dan Java.

Untuk lebih jelas tentang Supervision Principles, khususnya dalam bahasa pemrograman Erlang, anda dapat membaca Erlang Design Principles versi 4.9

Berikut ini langkah-langkah instalasi SBT di sistem operasi Mac OS X 10.6 Snow Leopard. Cara ini kurang lebih juga dapat diimplementasikan di sistem operasi lain yang masih dalam keluarga *NIX, seperni Linux dan BSD.
Jalankan perintah di bawah ini melalui terminal Anda:

Pada saat tulisan ini ditulis, versi terbaru SBT adalah 0.7.4.

Lalu bagaimana cara melakukan update SBT?

Mudah saja, pada dasarnya kita hanya perlu mengganti file JAR yang lama dengan file JAR yang lebih baru. Perintahnya kurang lebih seperti ini:

Catatan: Ganti [latest-version] dengan versi SBT terbaru yang tersedia.

Grammar DSL Tanggal

Contoh implementasi DSL-nya:

Kemarin dikurangi 3 tahun ditambah 7 bulan

Hampir mirip dengan versi Scala di tulisan terdahulu, hanya saja DSL kali ini tidak menggunakan Conjunction (kalau yang versi Scala ada Conjunction “dan” nya).
Dalam interpreter pattern, semua expression dijadikan class, baik non-terminal expression maupun terminal expression.
Beruikut ini source code-nya:

Code di atas bukanlah code untuk produksi, mungkin lebih cocok sebagai prototype saja, hanya sebagai contoh bagaimana kita membuat DSL dengan interpreter pattern. Code di atas sangat tidak efisien dan harus di-refactor ulang, jadi jangan coba-coba memasukannya ke dalam production code, karena secara coding tidak elegan dan performanya juga payah. Silahkan dicoba sendiri dan Anda akan mengetahui bahwa waktu eksekusi code tersebut tergolong lambat.

Kembali ke pemrograman fungsional, menampung hasil fungsi ke dalam cache juga biasa disebut dengan istilah memoize. Berikut ini adalah contoh memoized function dengan bahasa Erlang:

Kita tahu bahwa sebagian besar orang makan 3 kali dalam satu hari, sehingga dapat dipastikan bila sebagian besar pemanggilan fungsi akan menggunakan parameter 3. Oleh karena itu, fungsi frekuensi_makan_perhari(3) dapat kita buat cache-nya, sehingga beban kerja CPU berkurang karena tidak melakukan perhitungan matematika setiap mengeksekusi fungsi dengan parameter 3. jadi setiap kali ada yang memanggil fungsi dengan parameter 3, maka yang dipanggil adalah frekuensi_makan_perhari(3) bukan frekuansi_makan_perhari(N), karena memang itulah yang secara pattern sesuai (dengan pattern matching).

Ini adalah contoh yang sangat sederhana, mungkin masih belum menggambarkan bagaimana potensi memoized function yang sebenarnya.