KAOS adalah pendekatan goal-oriented requirements engineering dengan serangkaian teknik analisis formal. KAOS adalah singkatan dari Knowledge Acquisition in autOmated Specification,[1] tetapi pada [2] KAOS adalah singkatan dari Keep All Objects Satisfied. KAOS berasal dari kerja sama antara University of Oregon dan University of Louvain (Belgia) pada tahun 1990. Penelitian, ekstensi dan perbaikan masih dilakukan untuk metodologi ini secara teratur di University of Louvain.[3] KAOS digerakkan oleh tujuan (goal). Setelah mengidentifikasi beberapa tujuan awal untuk calon sistem, kerangka kerja KAOS memfasilitasi identifikasi tujuan lebih lanjut, dan syarat, objek, agen, dan tindakan sistem.[4] Konsep ini digambarkan sebagai kerangka multi-paradigma yang memungkinkan untuk menggabungkan berbagai tingkat ekspresi dan penalaran: semi-formal untuk pemodelan dan penataan tujuan, kualitatif untuk pemilihan di antara alternatif, dan formal, jika diperlukan, untuk penalaran yang lebih akurat. Dengan demikian, bahasa KAOS menggabungkan jaringan semantik [5] untuk pemodelan konseptual tujuan, asumsi, agen, objek, dan operasi dalam sistem, dan logika waktu linear temporal untuk spesifikasi tujuan dan objek, serta spesifikasi dasar keadaan untuk operasi. Secara umum, setiap konstruk dalam bahasa KAOS memiliki struktur dua tingkat: lapisan semantik grafis luar di mana konsep terkait dengan atribut dan hubungan, dan lapisan formal bagian dalam untuk secara formal mendefinisikan konsep. Secara keseluruhan, KAOS adalah metodologi yang dikembangkan dengan baik untuk analisis kebutuhan berorientasi tujuan yang dilengkapi dengan kerangka kerja formal yang solid. Selama perbaikan tujuan, operasionalisasi tujuan, analisis hambatan dan mitigasi, KAOS sangat bergantung pada pola-pola perbaikan formal yang terbukti sekali dan untuk semua. Oleh karena itu, pada setiap pola aplikasi, pengguna mendapat contoh bukti dari kebenaran penyempurnaan secara gratis.[6]
Metode KAOS
Kerangka kerja KAOS meminta analis untuk mendefinisikan jaringan konsep untuk domain tertentu. Tujuan (goal) dianalisis dan dipahami dengan lebih baik dengan mengidentifikasi tujuan yang memiliki tingkat yang lebih tinggi (higher-level-goals) -tujuan yang akan menjelaskan mengapa tujuan ini diinginkan - dan tujuan tersebut akan lebih jelas didefinisikan dengan membuat sub-tujuan (sub-goals). Dengan mengidentifikasi hubungan antara tujuan dengan tujuan lain, dikembangkan sebuah goal graph. Goal graph adalah jaringan semantik hubungan AND = OR = XOR antar tujuan di mana tujuan dikurangi oleh gabungan sub-goal atau disjungsi (eksklusif). Hubungan konflik (conflict relationship) antar tujuan juga dapat ditelusuri. Daun (leaves) dari goal graph adalah persyaratan - tujuan yang tidak dapat dikurangi lebih lanjut dan dapat ditugaskan sebagai tanggung jawab masing-masing agen. Suatu persyaratan ditugaskan ke agen perangkat lunak dan diambil sebagai kebutuhan, atau ke agen di domain dan diambil sebagai asumsi. Membedakan kebutuhan dari asumsi dapat mengidentifikasi batas antara perangkat lunak dan lingkungan untuk calon sistem. Secara intuitif, kebutuhan adalah pernyataan preskriptif dan asumsi deskriptif. Persyaratan dioperasionalkan oleh tindakan yang dilakukan oleh agen yang bertanggung jawab untuk masing-masing persyaratan sedemikian rupa sehingga sistem komposit memenuhi tujuan. Agen juga dapat memantau dan mengontrol objek tertentu yang diidentifikasi saat menentukan tujuan. Objek-objek ini dapat menjadi input dan output dari tindakan. Tujuan menyangkut objek, dan objek memastikan syarat jika mereka mengambil bagian dalam tindakan yang mengoperasikan persyaratan itu. Tahap akhir adalah mengidentifikasi rintangan yang mungkin terjadi pada suatu tujuan memungkinkan seseorang untuk merumuskan kembali goal graph dan memperkuat spesifikasi kebutuhan dengan memilih jalur pengurangan alternatif atau penugasan agen, atau dengan memperkenalkan tujuan baru untuk mengurangi hambatan.[4]
Metode ini secara garis besar terdiri dari (i) mengidentifikasi dan menyempurnakan tujuan secara progresif sampai kendala yang dapat diberikan kepada masing-masing agen diperoleh, (ii) mengidentifikasi objek dan tindakan secara progresif dari tujuan, (iii) memperoleh persyaratan pada objek dan tindakan untuk memenuhi kendala, dan (iv) menugaskan kendala, objek dan tindakan kepada agen yang menyusun sistem. Pengetahuan meta-level digunakan untuk memandu proses elaborasi; dibutuhkan bentuk taksonomi konseptual, aturan dan taktik yang terbentuk dengan baik untuk memilih di antara alternatif.[7]
Konsep utama KAOS
Ontologi KAOS termasuk objek (object), yang merupakan hal yang menarik dalam sistem komposit yang instansnya dapat berevolusi dari satu keadaan ke keadaan lain. Objek bisa berupa entitas, hubungan, atau events[6].
Operasi (operation) adalah hubungan input-output atas objek. Aplikasi operasi menentukan transisi keadaan. Operasi dinyatakan dengan tanda tangan di atas objek dan memiliki kondisi sebelum (pre-), sesudah (post-), dan pemicu (trigger). KAOS membuat perbedaan domain antara pra-kondisi / post-kondisi untuk operasi dan pra-kondisi / post-kondisi yang diinginkan untuk itu. Yang pertama bersifat indikatif dan menggambarkan apa arti aplikasi operasi dalam domain (tanpa resep tentang kapan operasi harus atau tidak harus diterapkan) sementara yang kedua adalah optatif dan menangkap penguatan tambahan dari kondisi untuk memastikan bahwa tujuannya tercapai.[8]
Agen (agent) adalah sejenis objek yang bertindak sebagai prosesor untuk operasi. Agen adalah komponen aktif yang dapat berupa manusia, perangkat, perangkat lunak, dll. Agen melakukan operasi yang dialokasikan untuk mereka. KAOS memungkinkan analis menentukan objek mana yang dapat diamati atau dikendalikan oleh agen.[6]
Tujuan (goal) dalam KAOS didefinisikan dalam [9] sebagai “pernyataan perspektif tentang suatu sistem yang kepuasannya secara umum membutuhkan kerja sama dari beberapa agen yang membentuk sistem itu”. Tujuan dalam KAOS dapat merujuk ke layanan (tujuan fungsional) atau kualitas layanan (tujuan non-fungsional). Di KAOS, tujuan disusun dalam penyempurnaan hierarki abstraksi AND / OR seperti biasa. Penyempurnaan tujuan (goal refinement) berakhir ketika setiap sub goal dapat direalisasikan oleh beberapa agen individu yang ditugaskan untuk itu. Hal itu berarti tujuan harus dapat diungkapkan dalam hal kondisi yang dapat dipantau dan dikendalikan oleh agen. Kebutuhan dan harapan dalam KAOS didefinisikan dengan cara yang biasa — yang pertama adalah tujuan di bawah tanggung jawab agen dalam calon sistem dan yang terakhir menjadi tujuan di bawah tanggung jawab agen di lingkungan. Pola definisi tujuan digunakan untuk spesifikasi tujuan ringan pada lapisan pemodelan. Ini ditentukan dalam logika temporal dan termasuk pola seperti 'mencapai', 'berhenti', 'mempertahankan', 'mengoptimalkan', dan 'menghindari'. KAOS juga telah mendukung jenis tujuan tambahan.[1] Misalnya, tujuan kepuasan (satisfaction goals) adalah tujuan fungsional yang berkaitan dengan pemenuhan permintaan agen; tujuan informasi (information goals) juga merupakan tujuan fungsional dan berkaitan dengan membuat agen tersebut mendapat informasi tentang keadaan objek; tujuan akurasi (accuracy goals), adalah tujuan non-fungsional yang mensyaratkan bahwa keadaan objek perangkat lunak secara akurat mencerminkan keadaan objek yang diamati / dikendalikan di lingkungan.[6]
Aktivitas Pemodelan
Secara keseluruhan, spesifikasi KAOS adalah kumpulan dari model inti berikut:[3]
Pemodelan tujuan (goal modelling) di mana tujuan diwakili, dan ditugaskan ke agen.[3]
Pemodelan objek (object modelling), yang merupakan model UML yang dapat diturunkan dari spesifikasi formal tujuan karena merujuk ke objek atau propertinya. Model objek digunakan untuk mendefinisikan dan mendokumentasikan konsep-konsep domain aplikasi yang relevan sehubungan dengan kebutuhan yang diketahui dan untuk memberikan kendala statis pada sistem operasional yang akan memenuhi kebutuhan tersebut. Sebagai bagian dari model objek, akan terdapat objek yang berkaitan dengan domain pemangku kepentingan dan objek lain yang diperkenalkan dengan tujuan untuk mengungkapkan kebutuhan atau kendala pada sistem operasional. Apa pun jenis objeknya, para pemangku kepentingan harus memahami apa artinya dan mengapa itu dibuat dalam model. Tiga jenis objek dapat hidup berdampingan dalam model objek:[3]
- Entitas: mewakili objek pasif dan independen. Misalnya, pintu lift, tombol, dll ... 'Independen' berarti deskripsi objek itu tidak perlu merujuk ke objek lain dari model. Objek tersebut mungkin memiliki atribut yang nilainya menentukan seperangkat status yang dapat ditransisikan oleh entitas. Objek 'pasif' berarti mereka tidak dapat melakukan operasi.[3]
- Agen: mewakili objek independen dan aktif. Misalnya, perusahaan lift, penumpang, dan pengontrol lift adalah agen. Objek aktif artinya mereka dapat melakukan operasi. Operasi biasanya menyiratkan transisi status pada entitas (misalnya, operasi "CloseDoor" menyiratkan transisi status berikut pada entitas "Door": atribut status berubah dari "Open" ke "Close").[3]
- Asosiasi: bergantung (dependent), objek pasif. 'Dependent' karena deskripsi objek tersebut merujuk ke objek lain. Misalnya, asosiasi 'At' menautkan 'Cage' ke 'Floor'. Sebuah perumpamaan dari asosiasi itu (katakanlah antara Cage ‘c’ dan Floor ‘f ') akan berlaku jika Cage‘ c ’saat ini terletak di Floor‘ f ’. Objek-objek itu dapat memiliki atribut yang nilainya menentukan set status yang dapat ditransisikan oleh entitas. Objek pasif sehingga mereka tidak dapat melakukan operasi. Tetapi agen dapat membuat perumpaan asosiasi mengubah status dengan melakukan operasi. Misalnya, operasi "LeaveFloor" menyiratkan transisi berikut: At (c, f) -> not At (c, f)[3]
Model objek KAOS sesuai dengan diagram kelas UML di mana entitas KAOS sesuai dengan kelas dalam UML; dan asosiasi KAOS terkait dengan tautan asosiasi biner UML atau kelas asosiasi n-ary. Inheritance tersedia untuk semua jenis objek (termasuk asosiasi). Objek dapat dikualifikasikan dengan atribut.[3]
Pemodelan operasi (operation model), model operasi KAOS menggambarkan semua perilaku yang diperlukan agen untuk memenuhi kebutuhan mereka. Perilaku dinyatakan dalam operasi yang dilakukan oleh agen. Operasi bekerja pada objek (didefinisikan dalam model objek): mereka dapat membuat objek, memicu transisi status objek dan mengaktifkan operasi lain (dengan mengirimkan suatu peristiwa). Ada dua sumber untuk mengidentifikasi operasi, antara lain dapat langsung diungkapkan oleh para pemangku kepentingan selama wawancara dan dapat diidentifikasi dengan melihat semua persyaratan yang ada.[3]
Referensi
- ^ a b Dardenne, A.; Fickas, S.; van Lamsweerde, A. "Goal-directed concept acquisition in requirements elicitation". Proceedings of the Sixth International Workshop on Software Specification and Design. IEEE Comput. Soc. Press. doi:10.1109/iwssd.1991.213081. ISBN 0818623209.
- ^ A. van Lamsweerde, E. Letier. "From Object Orientation to Goal Orientation: A Paradigm Shift for Requirements Engineering". Proc. Radical Innovations of Software and Systems Engineering, LNCS, 2003.
- ^ a b c d e f g h i Respect-IT, “A KAOS Tutorial V1.0”, Objectiver, 2007
- ^ a b Heaven, W.; Finkelstein, A. (2004). "UML profile to support requirements engineering with KAOS". IEE Proceedings - Software. 151 (1): 10. doi:10.1049/ip-sen:20040297. ISSN 1462-5970.
- ^ R. Brachman, H. Levesque (Eds.). "Readings in Knowledge Representation". Morgan Kaufmann, 1985.
- ^ a b c d Alexei Lapouchnian. “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.
- ^ Darimont, R.; Delor, E.; Massonet, P.; van Lamsweerde, A. "GRAIL/KAOS: an environment for goal-driven requirements analysis, integration and layout". Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering. IEEE Comput. Soc. Press. doi:10.1109/isre.1997.566851. ISBN 0818677406.
- ^ Letier, Emmanuel; van Lamsweerde, Axel (2002-11-01). "Deriving operational software specifications from system goals". ACM SIGSOFT Software Engineering Notes. 27 (6): 119. doi:10.1145/605466.605485. ISSN 0163-5948.
- ^ van Lamsweerde, A. "Elaborating security requirements by construction of intentional anti-models". Proceedings. 26th International Conference on Software Engineering. IEEE Comput. Soc. doi:10.1109/icse.2004.1317437. ISBN 0769521630.