Knowledge Acquisition in automated specification: Perbedaan antara revisi

'''KAOS''' adalah pendekatan ''[[Goal-oriented Requirement Engineering (GORE)|goal-oriented requirements engineering]]'' dengan serangkaian teknik analisis formal. KAOS adalah singkatan dari ''Knowledge Acquisition in autOmated Specification'' ,<ref name=":0">{{Cite journal|last=Dardenne|first=A.|last2=Fickas|first2=S.|last3=van Lamsweerde|first3=A.|title=Goal-directed concept acquisition in requirements elicitation|url=http://dx.doi.org/10.1109/iwssd.1991.213081|journal=Proceedings of the Sixth International Workshop on Software Specification and Design|publisher=IEEE Comput. Soc. Press|doi=10.1109/iwssd.1991.213081|isbn=0818623209}}</ref>, tetapi pada <ref>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. </ref> KAOS adalah singkatan dari ''Keep All Objects Satisfied''. KAOS berasal dari kerja sama antara [[Universitas Oregon|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.<ref name=":1">Respect-IT, “A KAOS Tutorial V1.0”, Objectiver, 2007</ref>. 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 .<ref name=":2">{{Cite journal|last=Heaven|first=W.|last2=Finkelstein|first2=A.|date=2004|title=UML profile to support requirements engineering with KAOS|url=http://dx.doi.org/10.1049/ip-sen:20040297|journal=IEE Proceedings - Software|volume=151|issue=1|pages=10|doi=10.1049/ip-sen:20040297|issn=1462-5970}}</ref>. 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]] <ref>R. Brachman, H. Levesque (Eds.). "Readings in Knowledge Representation". Morgan Kaufmann, 1985. </ref> 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.<ref name=":3">Alexei Lapouchnian. “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>.

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.<ref name=":2" />.

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.<ref>{{Cite journal|last=Darimont|first=R.|last2=Delor|first2=E.|last3=Massonet|first3=P.|last4=van Lamsweerde|first4=A.|title=GRAIL/KAOS: an environment for goal-driven requirements analysis, integration and layout|url=http://dx.doi.org/10.1109/isre.1997.566851|journal=Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering|publisher=IEEE Comput. Soc. Press|doi=10.1109/isre.1997.566851|isbn=0818677406}}</ref>.

'''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.<ref>{{Cite journal|last=Letier|first=Emmanuel|last2=van Lamsweerde|first2=Axel|date=2002-11-01|title=Deriving operational software specifications from system goals|url=http://dx.doi.org/10.1145/605466.605485|journal=ACM SIGSOFT Software Engineering Notes|volume=27|issue=6|pages=119|doi=10.1145/605466.605485|issn=0163-5948}}</ref>.

'''Agen ''(agent)''''' adalah sejenis objek yang bertindak sebagai [[prosesor]] untuk operasi. Agen adalah komponen aktif yang dapat berupa [[manusia]], [[Alat|perangkat,]] [[perangkat lunak]], dll. Agen melakukan operasi yang dialokasikan untuk mereka. KAOS memungkinkan analis menentukan objek mana yang dapat diamati atau dikendalikan oleh agen.<ref name=":3" />.

'''Tujuan ''(goal)''''' dalam KAOS didefinisikan dalam <ref>{{Cite journal|last=van Lamsweerde|first=A.|title=Elaborating security requirements by construction of intentional anti-models|url=http://dx.doi.org/10.1109/icse.2004.1317437|journal=Proceedings. 26th International Conference on Software Engineering|publisher=IEEE Comput. Soc|doi=10.1109/icse.2004.1317437|isbn=0769521630}}</ref> 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.<ref name=":0" />. 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.<ref name=":3" />.

Secara keseluruhan, spesifikasi KAOS adalah kumpulan dari model inti berikut:<ref name=":1" />:

'''Pemodelan tujuan ''(goal modelling)''''' di mana tujuan diwakili, dan ditugaskan ke agen.<ref name=":1" />.

'''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:<ref name=":1" />:

* 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.<ref name=":1" />.

* 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''").<ref name=":1" />.

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.<ref name=":1" />.

'''Pemodelan operasi ''(operation model), m'''''odel 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 .<ref name=":1" />.