Apa Aspek-Oriented Software Development? Aspek-Oriented Software Development (AOSD), kadang-kadang hanya disebut Aspek-Oriented Programming (AOP), adalah pendekatan baru untuk desain perangkat lunak yang menangani masalah-masalah modularitas yang tidak ditangani dengan baik oleh pendekatan lainnya, termasuk Pemrograman Terstruktur dan Object-Oriented Programming (OOP ). AOSD melengkapi, tetapi tidak menggantikan pendekatan-pendekatan. Khas perusahaan dan aplikasi internet hari ini harus mengatasi "masalah" seperti keamanan, perilaku transaksional, penebangan, dll. Subsistem yang menyediakan layanan ini dapat diimplementasikan dengan cara modular. Namun, untuk menggunakan layanan ini, Anda harus memasukkan "boilerplate" sama fragmen kode ke berbagai tempat di seluruh aplikasi untuk memanggil layanan tersebut. Ini melanggar "jangan ulangi dirimu sendiri" (KERING) prinsip dan kompromi modularitas sistem secara keseluruhan, karena kode doa yang sama tersebar di seluruh aplikasi. Misalnya, jika Anda ingin mengontrol akses ke layanan tertentu dalam aplikasi Anda, Anda bisa memasukkan otorisasi pengecekan boilerplate pada awal setiap metode yang perlu kontrol ini. Karena ini boilerplate berlebihan muncul di banyak tempat di kode tersebut, sekarang akan sulit dan rawan kesalahan untuk memodifikasi atau mengganti pendekatan keamanan kemudian, yang harus menjadi perlu. Selain itu, kode aplikasi Anda sekarang kusut dengan kode untuk keamanan (dan mungkin lainnya) kekhawatiran, yang keduanya kejelasan kompromi dan membuat sulit untuk menggunakan kembali kode Anda dalam konteks lain, karena Anda akan harus menyeret sepanjang pendekatan keamanan yang sama, yang mungkin tidak sesuai. Karena masalah seperti keamanan biasanya melintasi sejumlah batas modul aplikasi (misalnya, kelas). Kami menyebutnya lintas sektoral. Perhatikan bahwa hilangnya modularitas adalah di persimpangan antara keprihatinan yang berbeda. AOP mengembalikan modularitas dengan mengembangkan lintas sektoral, atau aspek, secara terpisah dan kemudian menggabungkan mereka dengan modul lain yang menggunakan mekanisme deklaratif atau program yang modular. Artinya, titik persimpangan didefinisikan sekali, di satu tempat, membuat mereka mudah untuk memahami dan memelihara. Modul lain tidak memerlukan modifikasi yang akan disarankan oleh aspek. Ini "persimpangan" proses, kadang-kadang disebut tenun, dapat terjadi pada membangun atau menjalankan waktu. AOSD tenun merupakan inovasi kunci yang menyediakan query berbutir sangat halus dan semantik komposisi. Dimana kode tradisional menghubungkan memiliki kemampuan untuk menyelesaikan metode dan nama variabel, tenun menambahkan kemampuan untuk menggantikan tubuh dengan implementasi metode baru, masukkan kode sebelum dan sesudah pemanggilan metode, variabel instrumen membaca dan menulis, dan negara baru bahkan asosiasi dan perilaku dengan kelas-kelas yang ada , biasanya untuk menambahkan "mixin" perilaku.

(http://www.aspectprogramming.com/home/aosd)

Filman, R.E. dan Elrad, T. dan Clarke, S. dan Akit, M., ed. (2004) Aspek-Oriented Software Development. Addison-Wesley. ISBN 0-321-21976-7 Abstrak Pengembangan perangkat lunak berubah. Peluang Internet, bisnis terkomputerisasi, dan komputersavvy konsumen, penurunan eksponensial dalam biaya komputasi dan komunikasi, dan lingkungan yang semakin dinamis lebih lama hidup sistem yang menekan pengembang perangkat lunak untuk datang dengan cara yang lebih baik untuk menciptakan dan berkembang sistem. Ada mengobarkan dalam perangkat lunak proses pengembangan struktur, sistem, pemrograman, jaminan kualitas, dan pemeliharaan. Software adalah tentang membangun model komputasi dari beberapa bagian dari elemen atau arus informasi dunia. Untuk semua tapi sistem perangkat lunak yang paling sepele, menaklukkan rekayasa sistem membutuhkan (mungkin rekursif) membagi sistem ke dalam potongan yang dapat (pada umumnya) secara terpisah dibuat dan dikelola. Dekade terakhir abad kedua puluh melihat kebangkitan (dan mungkin dominasi) dari perspektif berorientasi objek pada modularisasi sistem. Obyek-orientasi berfokus pada memilih objek sebagai unit utama dari modularitas dan bergaul dengan obyek di semua perilaku sistem. Objek biasanya elemen dari domain atau dari proses komputasi. Obyek-orientasi mencapai batas-batasnya. Banyak hal yang peduli tentang dalam menciptakan sistem perangkat lunak (kekhawatiran) tidak rapi terlokalisasi pada perilaku spesifik "hal." Membangun sistem yang beragam membutuhkan bersamaan memanipulasi banyak keprihatinan. Contoh berbagai kekhawatiran dari non-fungsional pengertian seperti keamanan, keandalan, dan pengelolaan untuk teknik pelaksanaan tepat seperti kontrol konkurensi, caching, dan pemulihan kesalahan. Sejak teknologi pemrograman konvensional yang berpusat pada menghasilkan urutan instruksi langsung, mereka membutuhkan programmer untuk tetap menyadari semua kekhawatiran tersebut selama proses pemrograman. Programmer harus secara eksplisit mencampurnya perintah untuk mencapai kekhawatiran ini dengan kode untuk fungsi aplikasi primer. Ini menghasilkan kode kusut dan sistem yang salah dan sulit-untuk-mempertahankan. Teknologi baru yang muncul untuk memungkinkan spesifikasi yang lebih kaya dari program dan modularisasi yang lebih baik dari spesifikasi ini. Seiring dengan teknologi baru, kita juga melihat metodologi perangkat lunak baru rekayasa untuk menggunakan mereka. Salah satu yang paling menarik dari teknologi baru ini adalah berorientasi aspek pengembangan perangkat lunak (AOSD). AOSD pemrograman teknologi (aspek pemrograman berorientasi, atau AOP) menyediakan mekanisme linguistik untuk ekspresi terpisah dari keprihatinan, bersama dengan teknologi implementasi untuk menenun kekhawatiran terpisah ke dalam sistem kerja. Berorientasi aspek rekayasa perangkat lunak (AOSE) teknologi yang muncul untuk mengelola proses sistem berkembang dalam paradigma baru ini. (http://eprints.eemcs.utwente.nl/10171/)

"Pendekatan menyegarkan baru untuk memperbaiki penggunaan-kasus pemodelan dengan memperkuat dengan orientasi aspek."-Ramnivas Laddad, penulis AspectJ dalam Aksi "Sejak 1980, kasus penggunaan telah menjadi cara untuk membawa pengguna ke dalam desain perangkat lunak, tetapi kasus penggunaan menerjemahkan ke dalam perangkat lunak telah menjadi sebuah seni, di terbaik, karena barang pengguna sering tidak menghormati batas-batas kode. Sekarang aspek pemrograman berorientasi (AOP) dapat mengungkapkan keprihatinan crosscutting langsung dalam kode, orang yang mengembangkan kasus penggunaan telah mengusulkan langkah-demi-langkah metode untuk mengenali kekhawatiran crosscutting dalam kasus penggunaan dan menulis kode dalam modul terpisah. Jika metode ini sama sekali berbuah dalam desain Anda dan praktek pembangunan, mereka akan membuat perbedaan besar dalam kualitas perangkat lunak untuk pengembang dan pengguna sama. Wes-Isberg, anggota tim AspectJ "Buku ini tidak hanya menyediakan ide dan contoh dari apa yang berorientasi aspek pengembangan perangkat lunak tetapi bagaimana hal itu dapat dimanfaatkan dalam proyek pengembangan yang nyata."MichaelWard, ThoughtWorks, Inc "Tidak ada sistem yang pernah dirancang dari awal sempurna; setiap sistem terdiri dari fitur berlapis-lapis di atas fitur yang menumpuk dari waktu ke waktu. Teknik desain konvensional tidak menangani ini dengan baik, dan dari waktu ke waktu integritas kebanyakan sistem degradasi sebagai hasilnya. Untuk pertama kalinya, di sini adalah seperangkat teknik yang memfasilitasi komposisi perilaku yang tidak hanya memungkinkan sistem untuk didefinisikan dalam hal fungsi berlapis tetapi komposisi di jantung dari pendekatan. Buku ini merupakan kemajuan penting dalam metodologi modern dan sudah pasti mempengaruhi arah rekayasa perangkat lunak pada dekade berikutnya, seperti Object-Oriented Software Engineering dipengaruhi yang terakhir. "-Kurt Bittner, IBM Corporation" Gunakan kasus merupakan sarana yang sangat baik untuk menangkap persyaratan sistem dan mendorong pandangan user-centric pengembangan sistem dan pengujian. Buku ini memberikan panduan lengkap tentang eksplisit usecase-driven dari persyaratan awal pemodelan untuk desain dan implementasi. Ini menyediakan satu set sederhana namun kaya pedoman untuk mewujudkan use case model menggunakan berorientasi aspek desain dan pemrograman. Ini adalah sumber daya berharga untuk peneliti dan praktisi. "-Dr. Awais Rashid, Lancaster University, Inggris, dan penulis Aspek-Oriented Sistem Database "AOSD adalah teknologi penting yang akan membantu pengembang menghasilkan sistem yang lebih baik. Sayangnya, belum jelas bagaimana mengintegrasikan AOSD di seluruh siklus hidup proyek. Buku ini menghancurkan penghalang yang, memberikan contoh konkrit tentang cara menggunakan AOSD dari analisis kebutuhan melalui pengujian "-Charles. B. Haley, peneliti, Universitas Terbuka, UKAspect pemrograman berorientasi (AOP) adalah cara baru yang revolusioner untuk berpikir tentang rekayasa perangkat lunak. AOP diperkenalkan untuk mengatasi masalah crosscutting seperti keamanan, penebangan, ketekunan, debugging, tracing, distribusi, pemantauan kinerja, dan penanganan eksepsi dengan cara yang lebih efektif. Tidak seperti teknik pengembangan konvensional, yang menyebarkan wujud kepedulian masing-masing menjadi beberapa kelas, aspek pemrograman berorientasi melokalisasi them.Aspect berorientasi pengembangan perangkat lunak (AOSD) menggunakan pendekatan ini untuk membuat modularitas yang lebih baik untuk kebutuhan fungsional dan nonfungsional, spesifik platform, dan lebih , yang memungkinkan Anda untuk membangun sistem yang lebih dimengerti yang lebih mudah untuk mengkonfigurasi dan memperpanjang untuk memenuhi kebutuhan yang berkembang dari stakeholders buku baru ini sangat diantisipasi, Ivar Jacobson dan Pan-Wei Ng menunjukkan bagaimana menerapkan penggunaan kasus-pendekatan yang matang dan sistematis untuk berfokus pada kekhawatiran-dan pemangku kepentingan aspek-orientasi dalam membangun sistem yang kuat dan extensible.

Sepanjang buku ini, penulis menggunakan satu, dunia nyata contoh dari sistem informasi manajemen hotel untuk membuat teori dijelaskan dan beton praktek dan penulis understandable.The menunjukkan bagaimana untuk mengidentifikasi, merancang, menerapkan, menguji, dan use case refactor modul , serta memperpanjang mereka. Mereka juga menunjukkan bagaimana merancang use case modul dengan Unified Modeling Language (UML)-menekankan perangkat tambahan dibuat di UML 2.0 dan bagaimana untuk mencapai modularitas use case menggunakan teknologi aspek, terutama topik AspectJ.Key termasuk Membuat kasus untuk kasus penggunaan dan aspek Menangkap dan pemodelan masalah dengan kasus penggunaan Menjaga kekhawatiran terpisah dengan use case modul Pemodelan use-kasus irisan dan aspek menggunakan ekstensi terbaru ke notasi UML Menerapkan kasus penggunaan dan aspek dalam projectsWhatever tingkat pengalaman dengan berorientasi aspek, Aspek pemrograman Berorientasi Pengembangan Perangkat Lunak dengan Kasus Penggunaan akan mengajarkan Anda bagaimana mengembangkan software yang lebih baik dengan merangkul perubahan paradigma untuk AOSD.

(http://dl.acm.org/citation.cfm?id=1062430)

Apa yang AOSD? Berorientasi aspek pengembangan perangkat lunak (AOSD) adalah pendekatan yang relatif baru di bidang pengembangan aplikasi bisnis. Pendekatan ini didasarkan pada gagasan Aspek. Aspek adalah sudut pandang untuk mempertimbangkan beberapa pengertian proses, atau perspektif. Untuk dapat dengan cepat membedakan gagasan yang mendasari pendekatan, marilah kita mencoba dan mempertimbangkan berbagai aspek dari sebuah situs web. Informasi arsitektur mendefinisikan struktur situs. Kegunaan mengacu pada tingkat keramahan situs terhadap pengguna. Desain grafis menentukan persepsi visual dari sebuah situs. Model fungsional menggambarkan logika bisnis. Semua dari mereka adalah berbagai komponen dari proses pengembangan web-site, dan komponen masing-masing membutuhkan sumber daya yang spesifik, pendekatan dan solusi. Untuk proyek untuk menjadi sukses, semua komponen tersebut harus efisien dikembangkan dan diimplementasikan. Agar seseorang harus menemukan contoh ini terlalu rumit, mari kita perhatikan skema sederhana dan lebih universal. Ketika sebuah bangunan apartemen sedang dirancang, arsitek harus pertama menguraikan kerangka, maka skema wirework, maka rencana penyediaan air dan seterusnya dan sebagainya. Setiap tahap dalam proses ini adalah aspek yang berbeda, perspektif yang berbeda dari proyek. Tidak peduli seberapa basi kedengarannya, pendekatan yang sama dapat diimplementasikan dalam pengembangan perangkat lunak untuk mengidentifikasi berbagai aspek logika bisnis dalam aplikasi. Lebih dari 20 tahun yang lalu Bjarne Stroustrup (http://en.wikipedia.org/wiki/Bjarne_Stroustrup) diatur kode program dalam C ke set entitas logis, yang perilaku dan interaksi dapat didefinisikan dalam beberapa cara (warisan, enkapsulasi , abstraksi, polimorfisme). Ini adalah paradigma yang handal dan teruji pengembangan perangkat lunak, yang dikenal sebagai pemrograman berorientasi objek. Namun pendekatan ini memiliki keterbatasan tertentu untuk penguraian aspek logika aplikasi bisnis. Selama bertahun-tahun yang telah berlalu sejak saat itu paradigma ini muncul, sejumlah pendekatan bertujuan untuk mengatasi keterbatasan mengatakan telah muncul. Diantaranya adalah program adaptif, filter komposisi, pemrograman berorientasi aspek, hyperspaces, peran-model, subjek pemrograman berorientasi dan sebagainya. Akhir-akhir ini, pengembangan pendekatan tersebut telah pindah ke daerah AOSD. Seperti yang telah kita menunjukkan, lintas sektoral kode akan didistribusikan di antara berbagai modul, yang pasti akan merusak kualitas dari perangkat lunak berkaitan dengan transparansi logika bisnis, kemampuan beradaptasi dan upgradeability. Tujuan AOSD adalah untuk mengisolasi lintas sektoral dan tempatkan di luar logika bisnis aplikasi. Mari kita bahas beberapa aplikasi web-terpadu, misalnya CMS, dan mencoba membayangkan apa titik dan dengan cara bagaimana kita mungkin mengalami disebutkan di atas kesulitan. Misalkan, sejumlah fungsi sistem memerlukan data masukan mengkonversi dari XML ke array. Karena kenyataan bahwa dalam kasus ini XML parsing aspek hanya melibatkan sejumlah fungsi, tidak berarti ekstensi yang cukup besar. Sudah jelas, dalam hal demikian tidak perlu untuk dekomposisi yang luas dan karena itu tidak perlu AOSD untuk dilaksanakan. Solusi paling sederhana dan paling masuk akal adalah untuk memasukkan prosedur ini ke dalam metode kelas root (atau, jika tidak, ke dalam kelas eksternal, tergantung pada keadaan tertentu) dan mengaktifkannya ketika dibutuhkan. Diterima dekomposisi Namun tidak ada manipulasi dengan benda akan membantu jika kita harus memantau produktivitas,

dan tugas kami adalah untuk mengambil pada permintaan pembacaan dari semua fungsi yang dilakukan, pada awal mereka dan exit point. Seorang pembaca yang penuh perhatian akan menyarankan bahwa kita harus beralih ke contoh sebelumnya dan menggunakan pemicu untuk aktivasi atau deaktivasi menangkap statistik data. Yah, kita hanya dapat memperingatkan dia atau bahwa dia, seharusnya seorang perlu muncul untuk penebangan transaksi sistem dalam kasus-kasus tertentu, itu akan menjadi perlu untuk mengingat semua detail arsitektur program dan mengatur kembali itu. Tidak dapat diterima dekomposisi Akan jauh lebih praktis untuk tugas sistem dengan menangani event tertentu pada objek tertentu dalam aspek tertentu. Misalkan, setelah beberapa persyaratan waktu keamanan baru harus dimasukkan ke dalam proyek besar dan canggih. Kami kemudian membuat prosedur untuk pemeriksaan keamanan tambahan dan tugas sistem dengan menjalankan prosedur ini di aktivasi metode ditentukan dalam aspek keamanan. Hal ini tersirat oleh paradigma AOSD. Kami membuat tingkat abstraksi baru di luar arsitektur program yang ada, dan kemudian di dalamnya kita menyatakan fungsi yang dalam beberapa cara ini berlaku untuk seluruh sistem. Seperti yang Anda lihat dari Gambar 3, adalah mungkin untuk menentukan prosedur program yang menghadiri sistem, mengatakan, dalam aspek keamanan, dan menempatkan mereka di luar kelas utama. Dengan cara yang sama kita dapat mengobati prosedur masukan validasi data aspek. Jadi, dengan setiap kali kita membuat logika bisnis yang lebih jelas dan nyata. Sebagai soal fakta, apa yang kita dapatkan sebagai hasilnya adalah logika bisnis yang jelas di kelas utama sistem dan tepat didistribusikan di luar masalah model yang penting lintas sektor. Aspectual dekomposisi Mari kita meringkas: pendekatan berorientasi aspek didasarkan pada prinsip mengidentifikasi kode program umum dalam aspek-aspek tertentu dan menempatkan prosedur umum di luar logika bisnis utama; proses orientasi aspek dan pengembangan perangkat lunak dapat mencakup pemodelan, desain, pemrograman, reverse-engineering dan re-engineering; domain dari AOSD termasuk aplikasi, komponen dan database; interaksi dengan dan integrasi ke paradigma lain dilakukan dengan bantuan kerangka, generator bahasa program, dan arsitektur deskripsi bahasa (ADL).

Dasar-dasar dari Aspek-Oriented Approach Aspek pemrograman berorientasi memungkinkan pengembang untuk mengatur lintas sektoral ke dalam deklarasi individu - aspek. Menyediakan kemungkinan untuk mendefinisikan fungsi tertentu untuk Program poin eksekusi JoinPoints (metode aktivasi, konstruksi kelas, akses ke bidang kelas dll). Bahasa yang mendukung pemrograman berorientasi aspek (AOP) lebih sering menggunakan fungsi untuk satu set poin - pointcut. Fungsi di titik-titik ditentukan oleh kode program yang sopan disebut sebagai Saran (AspectJ). Maka, aspek menjelaskan alasan crosscutting untuk satu set khusus dari

komponen sistem. Komponen sendiri hanya mencakup logika bisnis bahwa mereka seharusnya diterapkan. Selama kompilasi program komponen yang terkait dengan aspek (Weave). Untuk lebih memahami dasar-dasar pemrograman berorientasi aspek, mari kita sekali lagi pertimbangkan contoh, yang melibatkan mendefinisikan aspek pemantauan produktivitas. (Lihat Gambar 2). Misalkan, kita ingin mengambil bacaan timer pada titik-titik masuk dan keluar dari semua metode dalam kelas seperti Model, Rekam Dokumen, dan Dispatcher. Jadi, kita harus memperkenalkan ke dalam aspek Logging sebuah pointcut dengan pencatatan semua fungsi yang diperlukan. Untuk menutupi semua metode dari kelas tertentu, sebagian AOP-mendukung bahasa menggunakan masker khusus. Sekarang mungkin untuk mendefinisikan pointcut diperlukan. Kami mendirikan Saran di entri (Sebelum) dan (Setelah) exit poin untuk metode yang tercantum dalam pointcut. Biasanya, Saran di AOP-mendukung bahasa yang tersedia untuk acara-acara seperti Sebelum, Setelah dan Sekitar, meskipun kadang-kadang acara lainnya juga hadir. Dengan demikian, dasar berikut AOP deklarasi dapat dipilih: Aspek - definisi dari satu set tertentu dari lintas sektoral melakukan tugas tertentu; Pointcut - kode penerapan sebuah Aspect: mendefinisikan kapan dan di mana fungsi dari aspek tertentu dapat diterapkan (lihat Gambar 3) Saran - kode fungsi obyek: kode fungsi langsung untuk acara tertentu. Dengan kata lain, ini adalah apa yang akan dilakukan untuk objek yang tercantum dalam pointcut.

Masih terlalu rumit? Well, saya pikir semuanya akan menjadi jelas setelah kami memperkenalkan beberapa contoh praktis. Mari kita mulai dengan yang paling sederhana di antaranya: http://www.phpclasses.org/browse/package/2633.html. Saya menulis ini perpustakaan kecil dengan maksud untuk menunjukkan baik kelebihan dan ketersediaan AOSD. Selain itu, Anda tidak perlu tahu setiap detail dari PHP atau perangkat lunak kustom untuk dapat menggunakan library ini. Hal ini cukup hanya untuk memungkinkan aop.lib.php di script Anda di PHP 4 (atau versi) dalam konfigurasi standar. Hal ini dimungkinkan untuk menentukan aspek tertentu untuk masalah crosscutting (katakanlah, untuk menjaga log transaksi), melalui memulai kelas Aspek: $ Aspect1 = Aspek baru ();

Lalu kami mendirikan pointcut dan menentukan metode itu mempengaruhi: $ PC1 = $ aspect1-> pointcut ("Contoh panggilan :: Sample atau Contoh panggilan :: sample2");

Satu-satunya hal yang tersisa adalah untuk menentukan kode program untuk entry dan exit point untuk metode dari pointcut saat ini:

$ PC1-> _before ("cetak 'preproses
';"); $ PC1-> _after ("cetak 'postprocess
';");

Dengan cara yang sama kita dapat mendefinisikan aspek tambahan, misalnya: $ Aspect2 = Aspek baru (); $ Pc2 = $ aspect2-> pointcut ("panggilan Contoh :: sample2"); $ Pc2-> _before ("cetak 'Aspect2 preprocessor
';"); $ Pc2-> _after ("cetak 'Aspect2 postprocessor
';");

Untuk memungkinkan aspek satu atau beberapa hanya menggunakan Aspek ::: berlaku () fungsi: Aspek :: berlaku ($ aspect1); Aspek :: berlaku ($ aspect2);

Seperti mungkin Anda ketahui, sebelum PHP 5 muncul metode penanganan dan acara kelas agak masalah. Sedangkan untuk peristiwa-peristiwa global - misalnya, PHP kesalahan, - satu dapat mengembangkan penangan khusus, untuk menangani event di entry dan exit point metode itu perlu untuk "manual" memasukkan semacam "notifiers". Dalam kasus kami, kami akan perlu untuk memasukkan Saran khusus _before :: (); dan Saran :: _after (); fungsi: Contoh kelas { Contoh fungsi () { Saran :: _before (); 'initilization Kelas
' cetak; Saran :: _after (); return $ ini; } fungsi sample2 () { Saran :: _before (); 'Bisnis logika sample2
' cetak; Saran :: _after (); return true; } }

Sudah jelas dari contoh di atas, dimasukkan sebelum dan sesudah kode logika metode bisnis adalah "notifiers" untuk peristiwa ini. Ketika PHP prosesor menemukan seperti "notifier", itu memeriksa aspek aktif. Dalam hal ada satu, PHP memeriksa fungsi saat ini ditentukan dalam pointcut. Jika fungsi yang ada, itu diaktifkan untuk acara tertentu (misalnya, untuk Saran :: _before ()). Seperti yang Anda lihat, sangat sederhana. Tetapi apa nilai praktis dari pendekatan ini?

Misalkan, kami telah dimasukkan "notifiers" ke dalam semua metode kelas script kami dan perpustakaan aop.lib.php diaktifkan. Kemudian suatu hari muncul kebutuhan untuk mendapatkan laporan rinci tentang distribusi beban kerja antara fungsi proyek kami. Kami membuat suatu aspek dan mendefinisikan pointcut, yang mencakup semua fungsi dalam proyek: Pemantauan $ = baru Aspek (); $ PC3 = $ Pemantauan-> pointcut ("panggilan * :: *");

Sudah jelas dari contoh, mungkin untuk menggunakan masker ::. Kemudian pada Nasihat kita dapat menggunakan fungsi konvensional untuk perhitungan waktu yang tepat dalam milidetik (ms): fungsi getMicrotime () { daftar ($ usec, $ sec) = explode ("", microtime ()); return ((float) $ usec (float) $ detik); }

Dengan bantuan yang kita dapat mengambil bacaan waktu di entry point dari masing-masing fungsi proyek dan membandingkannya dengan bacaan di exit point fungsi ', waktu yang diperoleh dari operasi logika bisnis dalam tubuh fungsi disimpan dalam variabel laporan global. Satu-satunya hal yang tersisa adalah untuk menampilkan laporan pada akhir siklus program. Contoh menggunakan aspek produktivitas pemantauan disajikan dalam naskah sample_trace.php ditemukan di arsip kit distribusi. Selain itu, perpustakaan ini memungkinkan Anda untuk mendaftar acara Anda sendiri sistem dan menentukan lintas sektoral kekhawatiran bagi mereka di masa depan. Acara sendiri dapat didefinisikan di setiap tempat kode aplikasi: Saran :: _event ("AllAPILibrariesAreLoaded");

Kita bisa menambahkan event handler untuk event yang diperlukan untuk membuat dekomposisi tambahan atau termasuk baru plug-in dalam aplikasi lengkap: fungsi MyController () {return "controller itas";} $ Aspect3 = Aspek baru (); $ PC3 = $ aspect3-> pointcut ("panggilan * :: *"); $ PC3-> _event ("AllAPILibrariesAreLoaded", "MyController ();"); $ PC3-> menghancurkan (); Aspek :: berlaku ($ aspect3);

Jangan-jangan Anda harus mendapatkan kesan bahwa AOSD hanya dapat digunakan untuk tugastugas spesifik tertentu, mari kita perhatikan contoh lain. PHP cukup toleran terhadap berbagai jenis variabel. Di satu sisi, ini adalah fitur yang sangat positif karena hal itu berarti bahwa tidak ada kebutuhan untuk selalu memeriksa kepatuhan dengan jenis dan waktu limbah untuk deklarasi. Di sisi lain, ini dapat menyebabkan kesalahan. Dalam hal proyek mengandung sejumlah besar fungsi, hampir tidak mungkin untuk mengingat sintaks kami telah menyusun untuk mereka. Namun lupa tempat menyimpan bahkan satu argumen tunggal dapat menyebabkan perubahan tak terduga dalam perilaku fungsi tersebut. Dapatkah AOSD sangat membantu dalam situasi seperti itu? Jelas! Mari kita ingat diagram pada Gambar 3. Seperti yang Anda lihat, kelas Dokumen dan Rekam berisi metode yang serupa menambah, memperbarui, menghapus, menyalin, dapatkan. Sebuah terorganisir dengan baik mensyaratkan arsitektur program sintaks yang sama untuk metode ini: add ($ id, $ data), update ($ id, $ data), menghapus ($ id), menyalin ($ id1, id2 $), get ($ id ). AOSD dapat membantu kita untuk mengatur arsitektur program serta kegiatan kita sendiri. Kita dapat mengatur masukan aspek validasi data dan menentukan pointcut untuk Dokumen dan metode Rekam kelas. Add, update, menghapus, menyalin dan mendapatkan entri fungsi acara dapat memeriksa jenis argumen pertama. Jika yang terakhir yang tidak integer, kesalahan telah pasti terjadi. Hal ini juga memungkinkan untuk mengatur pointcut kedua untuk menambah dan memperbarui metode. Apa yang akan diperiksa dalam kasus ini adalah jenis argumen kedua, yang jelas harus sesuai dengan tipe array. Dengan cara ini kita dapat menempatkan transaksi logging di luar logika bisnis proyek; sekarang adalah mungkin setiap saat untuk mendefinisikan fungsi, yang membutuhkan pemeriksaan tambahan untuk keamanan dll Yang menarik adalah kenyataan bahwa dengan bantuan AOSD kami dapat menyediakan untuk peringatan kesalahan sistem tertentu untuk ditampilkan untuk satu set tertentu dari fungsi. Misalkan, sejumlah fungsi kami berpartisipasi dalam mendirikan WML (WAP), WSDL (SOAP), RSS / ATOM atau SVG mark-up kode. Jelas, dalam hal ini tidak dapat diterima untuk menampilkan HTMLkode dengan pesan kesalahan. The "notifier" dalam prosesor kesalahan PHP akan membuat sistem menampilkan pesan baik dalam XML, atau menggunakan cara non-visual (misalnya, mengirim pemberitahuan melalui e-mail). Siapapun yang setidaknya pernah berpartisipasi dalam pengembangan perangkat lunak komersial, tahu betapa sulitnya untuk memecahkan masalah memperbarui produk akhir. Tentu, kita semua menyadari adanya perangkat lunak kontrol versi -. Misalnya, CVS (Concurrent Versions System, http://en.wikipedia.org/wiki/Concurrent_Versions_System) Namun masalahnya adalah bahwa setiap produk baru, berdasarkan yang sebelumnya, membutuhkan kustomisasi tertentu, dan lebih sering daripada tidak sama sekali tidak mudah untuk mengetahui apakah pembaruan tersebut akan mempengaruhi area disesuaikan untuk suatu proyek tertentu. Beberapa dari Anda telah pasti ditemui kasus-kasus ketika setelah update Anda harus mengembalikan seluruh proyek dari salinan data cadangan. Dan sekarang hanya mencoba untuk membayangkan sebuah kasus ketika "hilangnya" fitur disesuaikan adalah melihat hanya waktu yang lama setelah update! "Yah, mana AOSD masuk?" Anda mungkin bertanya. Masalahnya adalah bahwa AOSD justru dapat

memungkinkan kita mengatasi masalah ini: kode kustomisasi keseluruhan dapat ditempatkan di luar logika bisnis proyek karena kekhawatiran crosscutting. Anda hanya harus menentukan Aspek yang menarik, menentukan area penerapannya (pointcut) dan menguraikan kode fungsi yang sesuai. Hal ini bermanfaat mencoba untuk membayangkan bagaimana tepatnya ini akan bekerja. Mari kita ingat contoh favorit saya yang menampilkan perangkat lunak manajemen konten. Produk tersebut pasti mengandung fungsi untuk menampilkan Rekam recordset :: getList () dan mengembangkan kode untuk ini set View :: applyList (). Dalam argumen Rekam :: getList () menerima sebuah indikator recordset dan data parameter seleksi. Fungsi ini menghasilkan sebuah array dengan data hasil seleksi. View :: applyList () fungsi menerima array ini pada titik input dan menghasilkan kode format - misalnya, HTML kode untuk sebuah tabel. Misalkan, dalam produk kami katalog barang disajikan sebagai recordset tersebut. Ini adalah solusi universal untuk produk komersial, namun untuk setiap proyek tertentu berdasarkan produk ini perlu untuk memperkenalkan ke set kolom tambahan. Misalnya, tabel pada produk asli memiliki Stock Number dan bidang Item, sementara kita perlu menambahkan satu lagi, bidang Rating Pelanggan. Untuk melakukan ini, kita menulis Saran untuk Record :: getList fungsi (), yang menetapkan bahwa kolom tambahan dimasukkan ke dalam array dikembalikan pada akhir runtime. Jika View :: applyList () fungsi tidak mampu menyesuaikan sendiri secara otomatis untuk perubahan dalam array input, maka kita harus menulis Saran untuk fungsi ini juga. Mari kita berasumsi bahwa nantinya tuntutan klien bahwa kita harus menandai semua entri di set, yang meliputi barang tidak ditemukan di toko saat ini. Dalam hal ini kita menambahkan Saran untuk Lihat :: fungsi applyList (), di mana kita memeriksa nilai dari atribut Tersedia dalam toko. Perhatikan bahwa kita dapat mengatur folder Plugin terpisah untuk deklarasi aspek dan skrip yang mencakup funcyionality mereka. Dengan demikian, kita akan memiliki satu set lengkap fitur kustomisasi untuk setiap jenis proyek disimpan dalam satu folder tertentu, dan tidak akan ada masalah upgrade apapun. Kita akan dapat dengan mudah meng-upgrade script sistem, kecuali yang disimpan dalam folder Plugins. Aspek-Oriented Software Development di PHP Saat ini ada sejumlah proyek lanjutan, yang penulis telah diperkenalkan berbagai teknik AOSD dan implementasi PHP. Proyek AOPHP (http://www.aophp.net) mencakup preprocessor PHP ditulis dalam Java 1.5. Kita dapat menulis kode PHP-biasa, tetapi kita juga harus memberitahu preprocessor niat kami untuk menggunakan AOSD. Untuk melakukan ini, kita akan menggunakan struktur bukan. Kekhawatiran crosscutting dapat dimasukkan ke dalam script terpisah. sebelum (): execr (add ($ x, $ y)) | execr (sub ($ x, $ y)) { echo " Im Tentang Tambah / Sub $ x & $ y "; }

Jika perlu, skrip ini dapat diaktifkan dengan mengeluarkan instruksi sementara menyatakan kode AOPHP:

Seasar.PHP proyek (http://www.seasar.org/en/php5/index.html) menggunakan pendekatan yang berbeda. Penulisnya menggunakan XML untuk penataan aspek deklarasi, sementara integrasi dilakukan dengan bantuan PHP, yang kemudian mengeksekusi kode yang dihasilkan melalui fungsi eval (). MFAOP proyek (www.mfaop.com) didasarkan pada pendekatan yang sedikit menyerupai satu yang saya sebutkan pada contoh di atas. Penulis proyek menunjukkan bahwa yang pertama harus mengatur pointcut dan kemudian menggunakannya sesuai dengan apa yang dibutuhkan: $ Pointcut = new pointcut (); $ Pointcut-> addJoinPoint ('Contoh', 'Foo'); $ Pointcut-> addJoinPoint ('Contoh', 'bar'); $ Test1 = Aspek baru ($ pointcut, sebelum, 'echo "Sebelum $ methodName";'); $ = Test2 baru Aspek ($ pointcut, setelah, 'echo "Setelah $ methodName";');

Tidak seperti di perpustakaan aop.lib.php, bila menggunakan solusi ini tidak perlu secara manual memasukkan "notifiers" untuk setiap fungsi. Namun kita harus menginstal ekstensi PECL tambahan Classkit pada server. Dari sudut pandang saya, solusi yang paling elegan ditemukan oleh PHPAspect proyek (www.phpaspect.org). Hal ini dimungkinkan berkat penggunaan efektif dari kemampuan baru yang disediakan oleh PHP5, dan khususnya - kemungkinan untuk mendirikan kelas abstrak. PHPAspect memperkenalkan ke dalam bahasa PHP struktur tertentu; yang menyajikan aspek dinyatakan dalam bentuk yang nyata. aspek TraceOrder { pointcut logAddItem: exec (Order publik :: additem (2)); pointcut logTotalAmount: call (Order-> additem (2)); setelah logAddItem { printf ("% d% s ditambahkan ke cartn tersebut", $ jumlah, $ referensi); } setelah {logTotalAmount printf ("Total jumlah gerobak:% .2 f n", $ thisJoinPoint-> getObject () -> getAmount ()); } }

Seperti jelas dari contoh, interval dari aspek tertentu justru didefinisikan. Para pointcut dan Saran ditetapkan dengan cara yang sangat ringkas dan belum luas, yang satu mungkin berpikir ini adalah "pribumi" sintaks PHP. Proyek ini menyediakan kapasitas penanganan untuk 7 jenis Join peristiwa titik (!): Panggilan, eksekusi (exec), konstruksi kelas (baru), atribut menulis-dalam (set), atribut membaca operasi (mendapatkan), penghancuran kelas (unset) dan memblokir penangkapan (menangkap). Ada tiga jenis kemungkinan Saran: sebelum, sesudah, di sekitar. Proyek ini dikembangkan masker luar biasa fleksibel untuk menentukan interval pengawasan di pointcut. Jadi, misalnya, adalah mungkin untuk menetapkan interval untuk semua kelas dengan awalan tertentu di nama: baru (* (*)); exec (* Order :: additem (2)); hubungi (DataObject -> pembaruan (0));

Untuk dapat menginstal Aspek PHP, Anda harus PHP 5.0.0. atau versi, dan telah Console_Getopt PEAR, Console_ProgressBar, perpustakaan PHP_Beautifier diinstal. Proyek ini berhasil dipresentasikan tahun lalu pada konferensi PHP (http://afup.org/pages/forumphp/) di Perancis (ini adalah di mana proyek tersebut berasal dari), dan bagi yang saya tahu adalah membuat kemajuan yang baik. Ada kemungkinan bahwa Zend Inc akan mencakup pengalaman yang dihasilkan oleh proyek ini ke versi berikut dari PHP. Kesimpulan Jelas, AOSD bukan solusi universal. AOP tidak akan menghilangkan semua bug atau mengembangkan perangkat lunak sendiri. Saya ragu bahwa setiap pengembang menggunakan pemrograman berorientasi aspek akan mendapatkan Hadiah Nobel. Selain itu, pendekatan ini hampir tidak akan menjadi yang dominan di masa depan: pendekatan berorientasi obyek telah populer selama 20 tahun, namun banyak pengembang masih membatasi diri untuk kode prosedural. Di sisi lain, keuntungan dari AOSD sebelum pemrograman berorientasi objek adalah sebagai jelas sebagai keuntungan OOP sebelum pemrograman prosedural. Saya pikir saya akan berada di sisi aman jika saya mengatakan bahwa para pengembang yang menggunakan AOSD adalah satu langkah di depan yang lain. Kode mereka lebih jelas, lebih mudah untuk memahami, mengandung kesalahan dan kurang dapat dengan mudah dikembangkan. Dengan demikian, insinyur AOSD mampu menerapkan skala besar, proyek yang lebih dapat diandalkan dan fleksibel. Yang penting, AOSD tidak memerlukan menyelesaikan pelatihan kembali dari pengembang. AOP tidak mengubah logika pemrograman secara drastis, seperti yang terjadi dengan transisi dari prosedural ke pemrograman berorientasi objek. AOSD hanya meluas. Mengembangkan arsitektur program baru, Anda hanya mengekstrak dari segala sesuatu benda yang menurut Anda tidak cocok di sana dan menemukan tempat yang cocok untuk itu. Bayangkan bahwa untuk tahun Anda sudah ditoleransi sepotong patung, yang benarbenar tidak setuju dengan desain keseluruhan rumah Anda, tetapi Anda berharga sebagai hadiah. Dan kemudian suatu hari Anda menemukan ceruk mencolok di dinding di mana patung tampaknya cocok dengan sempurna. "Kalau begitu," Anda akan mengatakan dalam kasus itu, "ini adalah di

mana ia benar-benar milik!" Terlepas dari semua yang telah berkata, AOSD mudah untuk membiasakan diri - tidak seperti, misalnya, TDD (http://en.wikipedia.org/wiki/Test_driven_development). Pada awalnya, orang bisa mencoba dan dimasukkan ke dalam aspek kekhawatiran crosscutting sederhana, seperti penebangan, dan kemudian secara bertahap memperluas dekomposisi arsitektur program, mengumpulkan dalam aspek berbagai domain aplikasi. Mungkin, beberapa bingung oleh kenyataan bahwa di PHP saat ini tidak resmi mendukung AOSD. Namun dalam artikel ini sangat saya disajikan beberapa contoh bagaimana Anda dapat dengan mudah mengintegrasikan pendekatan AOSD dasar sendiri. Ini adalah inti dari AOSD yang penting, bukan cara tertentu di mana ia diterapkan. Apa pun pendekatan yang Anda pilih, jika Anda mampu mencapai dekomposisi efisien dalam arsitektur program itu pasti akan meningkatkan kualitas produk Anda. Hari ini AOSD didukung terutama oleh ekstensi untuk bahasa pemrograman populer, namun pemain terkemuka di pasar tidak akan ikut campur, dan AOSD secara bertahap menemukan jalan ke platform pemrograman populer (http://www.internetnews.com / dev-news/print.php/3106021). AOSD tidak akan menjadi revolusi teknologi baru, namun evolusi, di sisi lain, tidak bisa dihindari. Apakah Anda mengikutinya atau memimpin adalah masalah pilihan Anda sendiri. Sumber Daya & Referensi [1] Pan-Wei Ng, Ivar Jacobson. Aspek-Oriented Software Development dengan Kasus Penggunaan. Addison Wesley Professional (Nov 30 Juni 2004), ISBN: 0321268881. [2] Robert E. Filman, Tzilla Elrad, Siobhan Clarke, Mehmet Aksit. Aspek-Oriented Software Development. Addison-Wesley Professional (6 Oktober 2004), ISBN: 0321219767. [3] Ramnivas Laddad. Berorientasi Aspek Refactoring. Addison-Wesley Professional (29 September 2006), ISBN: 0321304721. [4] Ivan Kiselev. Aspek-Oriented Programming dengan AspectJ. Addison-Wesley Professional (17 Juli 2002), ISBN: 0672324105.

(http://dsheiko.com/weblog/aspect-oriented-software-development-and-php)