Tropos
Artikel ini sebatang kara, artinya tidak ada artikel lain yang memiliki pranala balik ke halaman ini. Bantulah menambah pranala ke artikel ini dari artikel yang berhubungan atau coba peralatan pencari pranala. Tag ini diberikan pada Februari 2023. |
Tropos [1][2] adalah metodologi pengembangan perangkat lunak berorientasi agen yang dibuat oleh sekelompok penulis dari berbagai universitas di Kanada dan Italia. Metodologi Tropos dimaksudkan untuk mendukung semua kegiatan analisis dan desain dalam proses pengembangan perangkat lunak, mulai dari analisis domain aplikasi hingga implementasi sistem. Secara khusus, Tropos bertumpu pada gagasan membangun model calon sistem (sistem-to-be) dan lingkungannya, yang secara bertahap disempurnakan dan diperluas, menyediakan antarmuka umum untuk berbagai kegiatan pengembangan perangkat lunak, serta dasar untuk dokumentasi dan evolusi perangkat lunak.[2] Singkatnya, dua keistimewaan Tropos adalah:[2]
- Gagasan agen dan gagasan mentalistik terkait digunakan dalam semua fase pengembangan perangkat lunak, mulai dari analisis kebutuhan awal hingga implementasi aktual[2]
- Peran penting diberikan pada analisis kebutuhan awal yang mendahului perspektif spesifikasi kebutuhan calon sistem.[2]
Proses pengembangan perangkat lunak Tropos terdiri dari lima fase: early requirements, late requirements, architectural design, detailed design dan implementation. Empat fase terakhir sudah memiliki kedudukan yang kuat dalam literatur Rekayasa Perangkat Lunak dan didukung oleh berbagai metodologi dan alat (tools). Tahap pertama (early requirements analysis) diterima dengan baik di komunitas riset Rekayasa Kebutuhan, tetapi tidak dipraktikkan secara luas.[2]
Metode Tropos
suntingAnalisis kebutuhan merupakan fase awal dalam banyak metodologi rekayasa perangkat lunak. Seperti dengan pendekatan lain, tujuan akhir dari analisis kebutuhan di Tropos adalah untuk menyediakan seperangkat kebutuhan fungsional dan non-fungsional untuk calon sistem. Analisis kebutuhan di Tropos dibagi dalam dua fase utama: early requirements dan late requirements. Keduanya memiliki pendekatan konseptual dan metodologi yang sama. Lebih tepatnya, selama fase pertama, requirement engineer mengidentifikasi domain pemangku kepentingan dan model mereka sebagai aktor, yang bergantung satu sama lain untuk tujuan (goal) yang ingin dicapai, rencana (plan) yang akan dilakukan, dan sumber daya (resource) yang harus dilengkapi. Dengan mendefinisikan dengan jelas dependensi ini, maka dimungkinkan untuk menyatakan mengapa, di samping apa dan bagaimana, fungsionalitas sistem dan, sebagai hasil terakhir, untuk memverifikasi bagaimana implementasi akhir sesuai dengan kebutuhan awal. Dalam tahap late requirement analysis, model konseptual diperluas termasuk aktor baru, yang mewakili sistem, dan sejumlah ketergantungan dengan aktor lain pada lingkungannya. Ketergantungan ini menentukan semua kebutuhan fungsional dan non-fungsional dari calon sistem.[2]
Fase architectural design dan detailed design fokus pada spesifikasi sistem, sesuai dengan kebutuhan yang dihasilkan dari fase sebelumnya. Architectural design mendefinisikan arsitektur global sistem dalam hal sub-sistem, yang saling terhubung melalui data dan aliran kontrol. Sub-sistem direpresentasikan dalam model sebagai aktor, sementara interkoneksi data / kontrol direpresentasikan sebagai dependensi. Architectural design juga menyediakan pemetaan aktor sistem ke serangkaian agen perangkat lunak, masing-masing ditandai oleh kemampuan khusus. Fase detailed design bertujuan menentukan kemampuan dan interaksi agen. Pada titik ini, biasanya, platform implementasi telah dipilih dan dapat diperhitungkan untuk melakukan detailed design yang akan memetakan langsung ke kode.[2]
Kegiatan Implementation mengikuti langkah demi langkah dari spesifikasi desain terinci berdasarkan pemetaan yang ditetapkan antara konstruksi platform implementasi dan gagasan dari tahap detailed design.[2]
Konsep utama Tropos
suntingModel dalam Tropos diperoleh sebagai contoh dari metamodel konseptual yang bertumpu pada konsep / hubungan berikut:[2]
Aktor (actor) yang memodelkan entitas yang memiliki tujuan strategis dan intensionalitas dalam sistem atau peraturan organisasi. Seorang aktor mewakili agen fisik, sosial atau perangkat lunak serta peran atau posisi. Definisi klasik Artificial Intelligence (AI) dari agen perangkat lunak, yaitu, perangkat lunak yang memiliki sifat seperti otonomi, kemampuan sosial, reaktivitas, proaktif, seperti yang diberikan, misalnya dalam,[3] di Tropos, peran didefinisikan sebagai karakterisasi abstrak dari perilaku aktor dalam beberapa konteks khusus atau domain pekerjaan, sementara posisi mewakili serangkaian peran, biasanya dimainkan oleh satu agen. Seorang agen dapat menempati suatu posisi, sementara suatu posisi dikatakan mencakup suatu peran.[2]
Tujuan (goal) yang mewakili kepentingan strategis aktor. Goal atau tujuan dibedakan menjadi hard goal dan soft goal. Soft goal tidak memiliki definisi yang jelas dan / atau kriteria untuk memutuskan apakah goal tersebut tercapai atau tidak. Menurut penelitian Chung, dkk.[4], perbedaan sifat pencapaian ini digarisbawahi dengan mengatakan bahwa goal dipenuhi sementara soft goal terpenuhi. Soft goals biasanya digunakan untuk memodelkan kebutuhan non-fungsional.[2]
Rencana (plan) yang mewakili pada tingkat abstrak mengenai cara melakukan sesuatu. Eksekusi rencana dapat menjadi sarana untuk memuaskan goal atau untuk memuaskan soft goal.[2]
Sumberdaya (resource) yang mewakili entitas fisik atau informasi.[2]
Ketergantungan (dependency) antara dua aktor, yang menunjukkan bahwa satu aktor bergantung, untuk beberapa alasan, pada yang lain untuk mencapai beberapa tujuan, melaksanakan beberapa rencana, atau memberikan sumber daya. Aktor yang digantungi disebut depender, sedangkan yang bergantung disebut dependee. Objek yang menjadi pusat ketergantungan disebut dependum. Secara umum, dengan bergantung pada aktor lain untuk suatu dependum, seorang aktor dapat mencapai tujuan yang tidak dapat dicapai dengan sendirinya, atau tidak dengan mudah, atau tidak dapat. Pada saat yang sama, depender menjadi rentan. Jika dependee gagal memberikan dependum, depender akan terkena dampak buruk dalam kemampuannya untuk mencapai tujuannya.[2]
Kemampuan (capability) yang mewakili kemampuan aktor dalam menentukan, memilih dan melaksanakan rencana untuk pemenuhan tujuan, mengingat kondisi dunia tertentu dan di hadapan peristiwa tertentu.[2]
Keyakinan (belief) yang mewakili aktor pengetahuan dunia.[2]
Aktivitas Pemodelan
suntingBerbagai kegiatan berkontribusi pada perolehan model kebutuhan awal pertama, penyempurnaan dan evolusinya ke dalam model-model berikutnya, antara lain:[2]
Pemodelan aktor (actor modelling), yang terdiri dari mengidentifikasi dan menganalisis baik aktor di dalam sebuah lingkungan, maupun aktor dan agen sistem. Secara khusus, pada tahap early requirement, pemodelan aktor berfokus pada pemodelan pemangku kepentingan dari domain aplikasi dan niat mereka sebagai aktor sosial yang ingin mencapai tujuan. Selama tahap late requirement, pemodelan aktor berfokus pada definisi aktor dari calon sistem, sedangkan dalam tahap architectural design, pemodelan aktor berfokus pada struktur dari aktor calon sistem yang akan menentukannya dalam hal sub-sistem, yang saling berhubungan melalui data dan aliran kontrol. Dalam tahap detailed design, agen sistem didefinisikan untuk menentukan semua gagasan yang diperlukan oleh target platform implementasi, dan akhirnya, selama fase implementation, pemodelan aktor sesuai dengan pengkodean agen.[2]
Pemodelan ketergantungan (dependency modelling), yang terdiri dari mengidentifikasi aktor yang saling bergantung satu sama lain untuk mencapai tujuan, rencana yang akan dilakukan, dan sumber daya yang harus dilengkapi. Secara khusus, pada fase early requirement, pemodelan ini berfokus pada pemodelan dependensi tujuan antar aktor sosial dari peraturan organisasi. Ketergantungan baru dapat diperoleh dan ditambahkan ke model setelah analisis tujuan dilakukan selama kegiatan pemodelan tujuan (goal modelling). Selama late requirement, pemodelan dependensi berfokus pada analisis dependensi aktor calon sistem. Dalam fase architectural design, aliran data dan kontrol antara sub-aktor dari aktor calon sistem dimodelkan dalam hal dependensi, memberikan dasar untuk pemodelan kemampuan (capability modelling) yang akan dimulai nanti dalam architectural design bersama dengan pemetaan aktor sistem untuk agen.[2]
Pemodelan tujuan (goal modelling) bertumpu pada analisis tujuan aktor, dilakukan dari sudut pandang aktor, dengan menggunakan tiga teknik penalaran dasar: analisis means-end, analisis kontribusi, dan dekomposisi AND / OR. Secara khusus, analisis means-end bertujuan untuk mengidentifikasi rencana, sumber daya dan soft goal yang menyediakan sarana untuk mencapai tujuan. Analisis kontribusi mengidentifikasi tujuan yang dapat berkontribusi secara positif atau negatif dalam pemenuhan tujuan yang akan dianalisis. Dalam arti tertentu, ini dapat dianggap sebagai perpanjangan dari analisis means-end, dengan tujuan sebagai means. Dekomposisi AND / OR menggabungkan dekomposisi AND dan OR dari root goal menjadi sub-goal, memodelkan struktur tujuan yang lebih baik. Pemodelan tujuan diterapkan pada model early requirement dan late requirement untuk menyempurnakannya dan untuk mendapatkan dependensi baru. Selama architectural design, pemodelan tujuan berkontribusi untuk memotivasi dekomposisi pertama dari aktor calon sistem menjadi satu set sub-actor.[2]
Pemodelan rencana (plan modelling) dapat dianggap sebagai teknik analisis yang melengkapi pemodelan tujuan (goal modelling). Pemodelan ini bertumpu pada teknik penalaran analog yang digunakan dalam pemodelan tujuan, yaitu, means-end, analisis kontribusi dan dekomposisi AND/ OR. Secara khusus, dekomposisi AND / OR memberikan deklarasi AND dan OR dari root plan ke dalam sub-plan[2].
Pemodelan kemampuan (capability modelling) dimulai pada akhir architectural design ketika sub-actor sistem telah ditentukan dalam hal tujuan mereka sendiri dan ketergantungan dengan aktor lain. Untuk mendefinisikan, memilih dan melaksanakan rencana untuk mencapai tujuannya sendiri, masing-masing sub-actor sistem harus diberi kemampuan ‘"individual" khusus. Kemampuan "sosial" tambahan juga harus disediakan untuk mengelola ketergantungan dengan aktor lain. Tujuan dan rencana yang dimodelkan sebelumnya menjadi bagian integral dari kapabilitas. Dalam detailed design, kemampuan masing-masing agen ditentukan lebih lanjut dan kemudian dikodekan selama fase implementation.[2]
- ^ Mao Xinjun, "Agent-Oriented Software Development", Tsinghua University Press, Beijing, 2005.
- ^ a b c d e f g h i j k l m n o p q r s t u v w P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos, A.Perini. "TROPOS: An Agent-Oriented Software Development Methodology". Journal of Autonomous Agents and Multi-Agent Systems, 2003.
- ^ H. Nwana, ‘‘Software agents: An overview,’’ Knowl. Eng. Rev. J., vol. 11, no. 3, 1996.
- ^ L. K. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, "Non-Functional Requirements in Software Engineering", Kluwer Publishing, 2000.