Kenangan…

Satu tahun telah berlalu. Tapi kenangan tentang almarhumah Bu Wanti masih saja tetap jelas. Ada saja yang memicunya. Salah satunya adalah masa-masa awal semester seperti ini.

Biasanya, beliau yang ‘repot’ mengatur alokasi pengajar, termasuk siapa sebaiknya membina siapa. Beliau yang ‘repot’ mengatur koordinasi dengan para asisten. Ya, concern beliau terhadap berbagai kegiatan akademik selalu ‘lebih’. Tidak peduli itu tugas beliau atau bukan…

Masa perwalian seperti ini juga mengingatkan saya pada beliau, karena saya menggantikannya menjadi wali akademik sebagian mahasiswa Prodi IF Angkatan 2005. Mudah-mudahan tidak mengecewakan…

Beliau adalah salah satu guru dan teman terbaik. Mudah-mudahan Allah SWT menerima seluruh amal baiknya, memaafkan seluruh dosanya, dan selalu melapangkan kuburnya…

Requirement Model: Use Case Diagram

Use case digunakan untuk memodelkan fitur fungsional sofware. Sebuah use case memodelkan sebuah fitur fungsional. Kalau di-zoom, sebuah use case terdiri dari serangkaian aksi yang jika dijalankan dengan skenario tertentu akan memberikan result value bagi satu atau lebih actor.

Actor memodelkan dunia luar yang terkait langsung dengan software yang sedang dimodelkan. Actor bisa menggambarkan hardware atau software lain yang terhubung dengan software yang sedang dimodelkan, atau menggambarkan role pengguna software (wewenang sekelompok orang).

Jadi, use case diagram -yang terdiri dari sekumpulan use case dan actor- ditujukan sebagai sarana untuk mendefinisikan fitur-fitur utama software, lingkup dari software…

Use case diagram harus mudah dipahami oleh developer maupun customer yang mungkin tidak paham teknis pembangunan software. Karena itu, use case diagram harus dibuat sederhana, menggunakan bahasa yang jelas, dan tidak memunculkan aspek teknis. Saat mengidentifikasi use case, pastikan seluruh fitur fungsional software sudah terwakili. Saat mengidentifikasi actor, pastikan seluruh entitas dunia luar yang terkait langsung dengan software sudah pula terwakili. Untuk mendapatkan diagram use case yang baik, biasanya diperlukan beberapa iterasi. Modifikasi diagram use case bahkan masih bisa dilakukan saat kita sudah masuk ke tahap analisis dan design.

Use case diagram diadopsi UML (Unified Modeling Language) sebagai salah satu bahasa modelnya. Ide awal use case diagram ini adalah dari metode OOSE (Object-oriented S/W Engineering) – nya Ivar Jacobson. Cukup bersih untuk memodelkan software requirements…

S/W Architecture vs NFRs

Arsitektur seperti apa yang cocok untuk software yang sedang kita bangun, erat kaitannya dengan kebutuhan non fungsional yang telah ditetapkan (non functional requirements/NFRs). Satu NFR dengan NFR lainnya bisa saling sinergi, bisa juga terjadi konflik. Berikut adalah beberapa contohnya:

• Jika performansi adalah NFR yang kritis, pilihkan arsitektur software yang melokalisasi fungsi-fungsi yang kritis pada sebuah modul atau sejumlah kecil modul. Dengan demikian, fungsi-fungsi kritis tersebut dapat dieksekusi tanpa butuh banyak effort untuk komunikasi antar-modul…

• Jika security adalah NFR yang kritis, maka struktur layered architecture adalah pilihan tepat. Aset yang harus diamankan disembunyikan di lapisan terdalam dengan validasi tingkat tinggi untuk setiap akses terhadap layer ini…

• Jika safety adalah NFR yang kritis, maka fungsi-fungsi terkait safety ini juga sebaiknya dilokalisasi di satu atau sejumlah kecil modul sehingga meminimasi biaya dan effort untuk melakukan safety validation…

• Jika availability adalah NFR yang kritis, pastikan ada komponen yang berjalan redundant sehingga jika terjadi kegagalan pada suatu komponen software, komponen cadangannya bisa mengambil alih…

• Jika maintainability adalah NFR yang kritis, maka arsitektur yang membagi software dalam komponen-komponen yang masing-masing terbungkus dengan baik, adalah pilihan yang tepat. Modifikasi dilokalisasi di sebuah komponen, dengan efek perubahan yang seminimal mungkin terhadap komponen lainnya…

Bagaimana jika ada konflik ??

Kompromi perlu dilakukan untuk menentukan prioritas kebutuhan, sehingga solusi yang dipilih adalah solusi optimal…

Naik angkot…

Menjelang akhir semester duanya di SMP, anak sulung saya mulai belajar pulang naik angkot. Jadi, rutinitas menjemputnya dengan menelusuri Jl. Djuanda, terus ke Jl. Merdeka dan Jl. Jawa yang padat pun pun bisa dihentikan…

Banyak tujuan yang ingin dicapai dengan melatihnya naik angkot. Salah satunya tentu saja untuk melatih keberanian dan ke-PD-an. Dan, saat naik angkot juga bisa digunakan untuk mengamati berbagai hal: berbagai ragam orang, berbagai kejadian… Naik angkot juga bisa melatih kesabaran kita saat angkot terpaksa ‘ngetem’ agak lama… juga melatih kita untuk berpikir dari sudut pandang yang lain…

Yang penting, pastikan kita naik dan turun dari angkot di tempat yang benar…  Angkot-angkot yang berhenti di sembarang tempat itu tentunya karena ada kontribusi kesalahan dari penumpangnya kan ??

OOD: Dependency between classes…

Hal lain yang perlu diperhatikan saat design adalah ketergantungan sebuah kelas terhadap kelas lainnya. Idealnya, ketergantungan dibuat seminimal mungkin agar modifikasi di sebuah kelas tidak terlalu besar pengaruhnya terhadap kelas lain.

Ketergantungan (dependency) kelas B terhadap kelas A dinyatakan dengan visibility kelas A terhadap kelas B. Ada beberapa jenis visibility (diambil dari definisi RUP), yaitu:

• global visibility; biasanya untuk kelas-kelas utility; kelas utility A visible terhadap B apabila instans kelas B bisa menggunakan seluruh service dari kelas A; apabila kelas A dimodifikasi, maka kelas B perlu dimodifikasi pula di bagian-bagian yang memanfaatkan service kelas A.
• parameter visibility; kelas A parameter visible terhadap kelas B jika method kelas B punya parameter bertipe kelas A. Jika kelas A dimodifikasi, maka hanya method terkait saja yang mungkin harus dimofifikasi di kelas B.
• field visibility; kelas A field visible terhadap kelas B jika kelas A di-create dan di-invoke oleh kelas B; visibility jenis ini digambarkan sebagai asosiasi (bukan dependensi)
• local visibility; kelas A local visible terhadap kelas B jika service kelas A hanya diperlukan pada suatu method di kelas B; ketergantungan kelas B terhadap kelas A hanya ada di method tsb.

Dependency digambarkan dengan garis putus-putus dan arah panah terhadap kelas yang menyediakan service (kelas A pada contoh-contoh di atas).

Buat apa lagi ini ? Tentu saja untuk memperkirakan efek modifikasi sebuah kelas terhadap kelas lainnya…

Triple “E” for life…

Update untuk posting saya tentang Software Vaganza. Dengan berbagai pertimbangan, pelaksanaan acara ini jadi agak mundur. Rencananya, acara akan dilaksanakan awal masa kuliah semester II 08/09.

Triple “E” for life adalah tema diangkat. Ya, enterprise, education, dan tidak lupa entertainment, adalah bidang-bidang yang tidak bisa lepas dari dukungan software.

Kesempatan berpartisipasi di pameran software-nya dibuka bagi seluruh mahasiswa Teknik Informatika ITB dan alumninya. Sedangkan talk show dan mini workshop-nya terbuka untuk umum…

Tunggu pengumuman resminya…

Penghuni baru…

Setelah beberapa tahun tersimpan di gudang, akhirnya aquarium kami diaktifkan kembali. Minggu lalu, saya pergi ke Gampang Ingat di lantai atas Borma Dago untuk mencari calon penghuninya. Ternyata, setelah di sana, jadi tambah banyak maunya…

Akhirnya, rumah kami bertambah dengan sembilan penghuni baru: ikan arwana (kecil; 20cm-an); dua kura-kura brazil, dua ikan niasa kecil, dua ikan cupang, dan dua ikan pipih kecil.

Ini dia yang paling cool :

AspectJ – Example

Salah satu bahasa pemrograman yang mendukung aspect oriented programming (AOP) adalah Java dengan library-nya AspectJ. Sempat dibahas sedikit dari tulisan ini dan komentar-komentarnya…

Berikut adalah beberapa konsep baru yang diperkenalkan dalam AOP:  joinpoint, poincut, dan advice.

Joinpoint merupakan definisi lokasi pada kode program, dimana saat eksekusi, aspek tertentu akan dieksekusi sesuai dengan aturan yang telah ditetapkan. Joinpoint didefinisikan di dalam sebuah aspect dengan menggunakan dua macam konstruktor, yaitu poincut dan advice.

Pointcut merupakan konstruktor yang digunakan untuk menunjuk joinpoint tertentu pada saat eksekusi. Sebuah pointcut dideklarasikan dengan menggunakan kata kunci pointcut. Ada banyak tipe poincut, berikut adalah contohnya untuk tipe pemanggilan method :   poincut lokasi1 () : call (int Date.getHour());

Artinya, kita mendefinisikan sebuah lokasi pada kode program (lokasi1), yaitu lokasi pemanggilan method getHour() dari kelas Date.

Advice mendefinisikan potongan kode yang akan dieksekusi pada sebuah joinpoint. Ada tiga jenis advice, yang masing-masing menentukan di sebelah mana advice tersebut akan disisipkan. Jenis advice pertama dieksekusi sebelum joinpoint (before advice), jenis kedua dieksekusi setelah joinpoint (after advice), dan yang terakhir dieksekusi pada joinpoint (around advice).

Contohnya:  before () : lokasi1 () { system.out.println (“Before : ” + thisJoinPoint);  }

Kode aspect yang lengkap untuk contoh di atas adalah sbb:

public aspect ngeDebug {
pointcut lokasi1 ()   :  call (int Date.getHour ());
before () : lokasi1 ()    { system.out.println (“Before : ” + thisJoinPoint);}}

Jadi, saat debuging misalnya, kita tidak perlu “menabur” kode println dimana-mana (yang kemudian sering lupa dihapus), tapi cukup mendefinisikan sebuah aspect ngeDebug seperti di atas…

OOD: Association between objects

Seperti telah dijelaskan sebelumnya, asosiasi memodelkan komunikasi antar objek saat run-time. Seperti halnya objek yang kita instansiasi dari kelasnya, maka saat run time, akan terbentuk instans dari asosisasi yang disebut link. Link ini bisa terbentuk dan terputus secara dinamis selama eksekusi. Asosiasi menggambarkan bahwa sebuah objek menggunakan fasilitas objek lainnya; misalnya mengakses atributnya atau memanggil salah satu method-nya.

Ada dua jenis khusus asosisasi:

• agregasi; sebuah objek “berisi” objek yang lain; sebuah objek (whole) merupakan agregat (gabungan) dari beberapa objek yang lain (parts)…

• komposisi; bentuk khusus dari agregasi dengan kepemilikan yang lebih kuat (strong ownership); objek-objek parts dimiliki oleh hanya satu objek whole; saat objek whole ‘hilang’ dari memori, maka seluruh objek part-nya ikut ‘hilang’…

Sebuah asosiasi bisa kita lengkapi informasi tambahan berupa nama asosiasi, role suatu objek pada setiap asosiasi, serta multiplicity-nya (1:1, 1:N, N:M, dst). Nama dan role akan membantu pemahaman kita terhadap model (mis. pada diagram kelas). Multiplicity memberikan gambaran jumlah link yang mungkin terbentuk saat run time.

Apakah model design kita harus selengkap ini ?

Sekali lagi, model yang lengkap akan membantu kita saat akan merancang setiap kelas lebih detil lagi (detail design), sehingga akhirnya siap dipetakan ke bahasa pemrograman tertentu…

Dan satu lagi, model yang baik adalah model yang secara komprehensif menyatakan persoalan yang sebenarnya, serta mudah dipahami (aspek readability)…

Apa itu Aspect ?

Unit program terkecil yang saat ini digunakan pada paradigma pemrograman prosedural atau berorientasi objek umumnya berupa prosedur dan kelas. Pendekatan tersebut tepat untuk digunakan pada persoalan dimana sistem hanya dibangun dari komponen – komponen fungsional. Namun, pendekatan tersebut tidak dapat digunakan untuk mengimplementasikan aspek – aspek khusus (special concerns) pada sistem. Misalnya aliran data pada sistem terdistribusi, pemulihan (failure recovery), persistensi (persistence), sinkronisasi proses (process synchronization), dan lain – lain. Aspek – aspek khusus tersebut biasanya akan langsung diimplementasikan sebagai barisan kode program yang mungkin tersebar (terduplikasi) pada kelompok kode program yang mewakili komponen – komponen fungsional.

Paradigma atau pendekatan pemrograman tersebut di atas belum mendukung aktivitas separation of concerns yang baik pada fase perancangan dan implementasi, sehingga menyebabkan program yang dihasilkan lebih sulit untuk dikembangkan, dipahami, dan dipelihara.

Pemrograman berorientasi aspek (Aspect Oriented Programming/AOP) merupakan paradigma pemrograman yang relatif baru, diperkenalkan sebagai hasil dari penelitian yang dilakukan oleh Gregor Kiczales di Xerox ‘s Palo Alto Research Center (PARC). Paradigma ini dikembangkan sebagai salah satu solusi untuk persoalan separating crosscutting concerns pada kode program. Dengan pendekatan pemrograman berorientasi aspek ini, persoalan didekomposisi menjadi kumpulan kelas (class) dan aspek (aspect). Kelas mewakili komponen – komponen yang memiliki peran fungsional dalam domain persoalan sistem perangkat lunak yang akan dikembangkan. Sedangkan aspek mewakili komponen – komponen yang tidak dapat didefinisikan sebagai komponen fungsional, namun keberadaannya tetap memiliki pengaruh pada performansi dan semantik sistem secara keseluruhan.