Paradigma rekayasa perangkat lunak terakhir yaitu berbasis obyek (object-oriented) telah meraih sukses besar. Usaha meningkatkan mutu desain program dengan dicapainya peningkatan readability, reusability serta dekomposisi struktural (modularity). Ini merupakan motivasi utama pergeseran dari pemrograman prosedural menjadi berbasis obyek. Dalam desain berbasis obyek, lokalisasi komponen dan obyek didasarkan atas unit fungsi (seperti book, account, log). Satu desain unit fungsi yang bersih, besar kemungkinan akan dimodifikasi, untuk menambahkan fitur yang melibatkan berbagai macam unit fungsi lain. Sebagai contoh unit fungsi account, untuk mendapatkan unit fungsi tracing, profiling, atau auditing, maka ditambahkan unit fungsi Log. Scattering (satu concern muncul di mana-mana) dan tangling (satu obyek/komponen terdapat berbagai macam concern) cenderung muncul bersamaan, sebagai konsukuensi logis dari adanya berbagai macam fitur dalam satu unit fungsi. Hal inilah yang menjadikan desain berbasis obyek tidak lagi memiliki modularitas yang bersih. Muncul ide membentuk paradigma baru yaitu berbasis aspek (aspect-oriented). Satu aspek mewakili satu unit fungsi (concern) yang bisa menjadi fitur di unit fungsi lain.
1. INTRODUCTION
Paradigma berbasis obyek telah membawa dunia rekayasa perangkat lunak menapaki era baru. Bahkan boleh dikatakan sebagai babak revolusi dalam pengembangan perangkat lunak. Ide besar Design Pattern yang dipromotori oleh ‘Gang of Four’ (GoF, Erich Gamma, Richard Helm, Ralph Johnson, dan John Vlissides).
Business Object merupakan unit representasi dari model bisnis yang dijalankan oleh aplikasi, seperti Account dan CreditTransfer. Selain dari konsrentasi bisnis (business concerns), supaya aplikasi lebih mudah dipantau dan dikelola, diberikan fitur-fitur lain, seperti Logging atau Tracing, Security, Session, Pooling, dan lainlain, yang kesemuanya itu bukan konsentrasi bisnis, namun merupakan kensontrasi teknis (technical concerns). Hal ini mengakibatkan source code Business Object tidak benar-benar bersih, karena di dalamnya ada aspek-aspek lain dari obyek bisnis itu sendiri, ini disebut tangling.
Dari sisi teknis Logging misalnya, kode program yang mengakses Logging ini bisa muncul di berbagai macam kode program business objects bahkan juga ada di setiap layer aplikasi, hal ini disebut scattering. Scattering dan tangling ini cenderung akan muncul secara bersamaan dalam pengembangan perangka lunak. Menyebabkan source code menjadi tidak independen dan bersih.
Pada tahun 1996, Gregor Kickzales, berangkat dari ide reflection dalam pemrograman, melontarkan gagasan brilian tentang pemrograman berbasis aspect (aspect-oriented programming, AOP). Pada tahun 1998-2000, Gregor Kickzales mendapat grant dari DARPA untuk melakukan riset tentang AOP yang terbagi menjadi 2 fase. Fase pertama 1998-1999 lebih banyak tentang AOP itu sendiri sebagai landasan, sementara fase kedua 2000-2002 adalah pengembangan AspectJ sebagai implementasi AOP. Walaupun pada masa awal ide ini boleh dikatakan tidak terlalu banyak mendapat dukungan, namun sejak tahun 2000, melalui usaha tiada henti dan memberikan contoh yang lebih nyata dengan implementasi AspectJ, akhirnya publik pun mulai menunjukkan penerimaannya terhadap gagasan ini. Project dan implementasi pemrograman berbasis aspect ini pun mulai marak dalam berbagai bahasa. AspectC merupakan project implementasi aspect-oriented dengan bahasa C/C++, AspectS untuk Smalltalk, AspectNet untuk C# .Net, Pythius untuk Phyton, dan AspectR untuk Ruby. Sementara AspectJ, HyperJ, DemeterJ, Java Aspect Component (JAC dari AOPSYS), Nano, AspectWerkz, dan lain sebagainya, merupakan jajaran nama-nama project implementasi aspect-oriented untuk Java.
Sementara itu JSR 1.5 ‘Tiger’, memasukan ide metadata yang merupakan komplementari dari aspect-oriented. Pemrograman berbasis aspek (aspect-oriented programming) hadir untuk memotong silang (crosscut) permasalahan scaterring dan tangling. Metodologi ini bukan menggantikan metodologi pemrograman berbasis obyek atau pendahulunya, namun hanya merupakan ekstensi pengembangan dari yang ada.
2. CROSSCUTTING CONCERNS
Prilaku crosscutting concerns bisa berbagai macam cara. Seorang developer membuat suatu
sistem berdasarkan berbagai macam requirements (kebutuhan). Kita bisa mengklasifikasikan requirement ini secara luas menjadi kebutuhan level inti modul dan kebutuhan level sistem. Banyak kebutuhan level sistem cenderung menjadi ortogonal (independen secara mutual) terhadap yang lain dan juga ke kebutuhan level modul. Kebutuhan level sistem cenderung untuk me-crosscut banyak inti modul. Sebagai misal Session sebagai kebutuhan level sistem akan ortogonal dengan kebutuhan level sistem yang lain misal Security, dan juga ortogonal dengan kebutuhan level modul misal CreditTransfer.
sistem berdasarkan berbagai macam requirements (kebutuhan). Kita bisa mengklasifikasikan requirement ini secara luas menjadi kebutuhan level inti modul dan kebutuhan level sistem. Banyak kebutuhan level sistem cenderung menjadi ortogonal (independen secara mutual) terhadap yang lain dan juga ke kebutuhan level modul. Kebutuhan level sistem cenderung untuk me-crosscut banyak inti modul. Sebagai misal Session sebagai kebutuhan level sistem akan ortogonal dengan kebutuhan level sistem yang lain misal Security, dan juga ortogonal dengan kebutuhan level modul misal CreditTransfer.
EmoticonEmoticon