Chapter 3 Specification of Requirements Models. 3.1 Introduction Sistem berbasis komputer mengintegrasikan, pengolahan informasi sub-sistem, satu atau.

Presentasi berjudul: "Chapter 3 Specification of Requirements Models. 3.1 Introduction Sistem berbasis komputer mengintegrasikan, pengolahan informasi sub-sistem, satu atau."— Transcript presentasi:

1 Chapter 3 Specification of Requirements Models

2 3.1 Introduction Sistem berbasis komputer mengintegrasikan, pengolahan informasi sub-sistem, satu atau sistem komputasi yang lebih mampu menangkap, menyimpan, mengolah, transfer, hadir dan mengelola informasi. Dalam desain sistem berbasis komputer, ini membenarkan perlu untuk menggabungkan beberapa entitas teknologi: (1) perangkat lunak, firmware, dan (analog dan digital) hardware, untuk memproses dan menyimpan informasi, (2) komunikasi layanan jaringan untuk mengangkut informasi, (3) sensor dan aktuator untuk berinteraksi dengan lingkungan fisik, dan (4) antarmuka manusia-mesin untuk pertukaran informasi dengan operator manusia. Meskipun sistem berbasis komputer dapat secara ketat didasarkan pada teknologi komputer, mereka biasanya meliputi badan lain yang seperti operator manusia, subsistem organisasi, dokumentasi, dan manual.

3 3.2 Modeling vs. Specification Keputusan pertama pengembang, ketika mereka ingin menentukan sebuah sistem, adalah untuk memilih bagian dari sistem mereka ingin untuk mempertimbangkan mana. Pemilihan bagian itu mendefinisikan tampilan sistem, yaitu, perspektif sistem yang perlu diwakili [5]. Pandangan ini memiliki eksistensi hanya konseptual dalam pikiran manusia, dan, menurut untuk representasi terstruktur dan informal, setidaknya pada pandangan dari pengembang.

4

5 Formalisasi tampilan sistem terjadi ketika itu berasal model. Ini Model terdiri dari representasi, masih konseptual, pandangan sistem, menurut meta-model tertentu. Ini meta-model sesuai dengan satu set (fungsional atau struktural) elemen komposisi dan aturan komposisi yang memungkinkan untuk membangun sebuah model yang mewakili pandangan sistem. Model ini melayani tujuan menjelaskan dan berbagi pandangan konseptual diadakan di pikiran manusia. Dengan cara ini, pengembang membuat pandangan mereka tersedia untuk penilaian orang lain dan reformulasi lanjut.

6 3.3 Meta-Models Categories Meskipun dua meta-model yang terlibat dalam pembangunan spesifikasi sistem mungkin tidak persis sama, seseorang dapat berasumsi, untuk tujuan penyederhanaan, bahwa bahasa representasi telah sadar dipilih dengan mempertimbangkan karakteristik meta-model (yang tidak selalu benar). Idealnya, bahasa representasi harus memungkinkan spesifikasi yang diinginkan karakteristik sistem, dalam cara yang tidak ambigu. Hal ini dimungkinkan, jika meta-model bahasa adalah: (1) formal (akurat, ketat), untuk menghindari ketidakjelasan dalam interpretasi representasi sistem, (2) lengkap, untuk memungkinkan pembangunan representasi yang benar-benar menggambarkan tampilan sistem. ini adalah bukan sifat mutlak, karena mereka bergantung pada sistem tertentu yang akan ditentukan. Dalam [17], Gajski et al. mengatur paling umum meta-model yang berbeda menjadi lima kelompok. Sebuah deskripsi singkat dari masing-masing kategori meta-model disajikan berikutnya.

7 1.State Oriented Meta-Models 2.Activity Oriented Meta-Models 3.Structure Oriented Meta-Models 4.Data Oriented Meta-Models 5.Heterogeneous Meta-Models 6.Multiple-View Approach

8 1.State Oriented Meta-Models Berorientasi keadaan meta-model memungkinkan pemodelan sistem sebagai seperangkat State dan satu set transisi. Transisi antara State berkembang menurut beberapa eksternal stimulus. Ini meta-model yang memadai untuk model sistem yang sementara perilaku adalah aspek yang paling penting yang akan diambil. Statecharts dan Petri Net adalah contoh State yang berorientasi meta-model.

9

10 2.Activity Oriented Meta-Models Activity Oriented Meta-Models memungkinkan pemodelan sistem sebagai serangkaian kegiatan yang berkaitan dengan data atau dengan eksekusi dependensi. Ini meta-model sangat cocok untuk model sistem dimana data dipengaruhi oleh urutan transformasi pada tingkat yang konstan. Data flow diagram (DFD) dan diagram alur adalah dua contoh berorientasi aktivitas meta-model.

11 3. Structure Oriented Meta-Models Structure Oriented Meta-Models memungkin- kan deskripsi sistem modul fisik dan interkoneksi adanya. Ini meta-model yang didedikasikan untuk karakterisasi komposisi fisik dari suatu sistem, bukan fungsinya. Diagram blok, juga disebut " component-connectivity diagrams" (CCD), berorientasi meta-model yang paling sering digunakan struktur. UML penyebaran dan komponen diagram didasarkan pada ini meta-model.

12 4. Data Oriented Meta-Models Data Oriented Meta-Models memungkinkan pemodelan sistem sebagai kumpulan data yang berhubungan dengan beberapa jenis atribut. Ini meta-model mendedikasikan lebih penting untuk organisasi data daripada fungsi sistem. UML tidak memiliki jenis diagram secara eksklusif didasarkan pada meta-model, karena nikmat sistem berorientasi objek dan tidak mempromosikan penggunaan diagram terutama didedikasikan untuk pemodelan data. Namun demikian, adalah mungkin untuk berpendapat bahwa diagram UML class adalah sebagian data yang berorientasi meta- model.

13 Data berorientasi meta-model, biasanya, digunakan dalam metodologi berdasarkan analisis struktur tradisional dan teknik desain [46]. Entity relationship diagrams(ERD) dan Jackson’s structured diagrams (JSDs) adalah dua contoh data berorientasi meta-model. ERD [6] menggambarkan sistem sebagai kumpulan entitas dan hubungan yang ada di antara mereka. Setiap entitas sesuai dengan unik jenis data dengan satu atau atribut yang lebih spesifik. Ini meta-model berguna ketika pengembang ingin mengatur hubungan yang kompleks antara berbagai jenis data. ERD tidak bisa model karakteristik fungsional atau temporal.

14 5. Heterogeneous Meta-Models Meta-model heterogen memungkinkan penggunaan, dalam representasi sistem yang sama, beberapa karakteristik dari meta- model yang berbeda, yaitu empat kategori yang dijelaskan sebelumnya. Ini meta-model solusi yang baik ketika sistem yang relatif kompleks harus dimodelkan. Control/data flow graphs (CDFGs), object process diagrams (OPDS) dan program state machines (PSMS) adalah contoh meta-model heterogen.

15

16 6. Multiple-View Approach Dengan meningkatnya kompleksitas sistem, penggunaan meta- model yang berbeda untuk mewakili berbagai jenis karakteristik sistem menjadi praktek umum. Sebuah sistem dimodelkan oleh satu set model yang berbeda, masing-masing sesuai dengan pandangan yang berbeda dari sistem, yang ditujukan untuk mewakili satu set baik dipisahkan karakteristik sistem, lihat Gambar. 3.6, di mana kriteria yang ditunjukkan terkait dengan karakteristik masing-masing pandangan ini dimaksudkan untuk menangkap. Beberapa pendekatan pandangan ini tidak sesuai untuk penggunaan meta-model yang heterogen, karena informasi dalam pandangan yang berbeda mungkin tidak secara eksplisit terkait melalui struktur informasi umum. Sebaliknya, dalam meta-model heterogen pandangan yang berbeda harus memegang struktur informasi umum dalam representasi terintegrasi yang unik. Notasi UML memungkinkan adopsi beberapa pandangan pendekatan.

17 3.4 Specification Methodology Deskripsi formal, perbandingan, dan konstruksi metode dan teknik untuk pengembangan sistem adalah tujuan utama dari komunitas metode rekayasa [19]. Meta-model proses pembangunan juga disebut " meta-process models" dan meta-model dari pengembangan produk, atau kiriman, disebut meta-data models' (dalam bab ini kita sebut ini hanya "meta-models"). Beberapa pendekatan terkenal dengan teknik metode adalah: ISO / IEC 12207 [22], OPEN [15] dan PIE [8]. Tindakan mendefinisikan metodologi spesifikasi kita sendiri disebut "situational method engineering" [44] dan dalam konteks ini bahwa penting untuk mempertimbangkan berikut tiga isu utama [39]: spesifikasi bahasa, kontrol kompleksitas, dan kontinuitas Model.

18 1.Specification Language 2.Complexity Control 3.Model Continuity 4.Non-Functional Requirements

19 1. Specification Language Bahasa spesifikasi harus memungkinkan representasi dari pandangan sistem tertentu, tanpa ambiguitas. Ini adalah tujuan utama dari bahasa spesifikasi, dan hubungan mereka dengan meta-model telah dibahas. Selain itu, bahasa spesifikasi harus menawarkan dukungan untuk menganalisis dan penalaran tentang spesifikasi. Mekanisme analisis yang tersedia tergantung pada spesifikasi bahasa itu sendiri. Namun, pada dasarnya ada dua jenis mekanisme: resmi analisis dan eksekusi spesifikasi. Analisis formal penting untuk memverifikasi apakah spesifikasi inkoheren, namun keberadaannya hanya mungkin jika bahasa spesifikasi memiliki basis matematika yang solid. Spesifikasi executable memungkinkan pengujian awal prototipe sistem untuk validasi persyaratan, rendering proses spesifikasi yang lebih kuat dan dimengerti.

20 2. Complexity Control Kontrol dari kompleksitas proses spesifikasi dapat dilakukan dalam dua dimensi yang berbeda: Kompleksitas representasi dan kompleksitas pembangunan. Kompleksitas sistem tidak hanya tergantung pada kardinalitas bagian- bagiannya, tetapi terutama pada cara bagian-bagiannya berinteraksi di antara mereka; lihat Gambar. 3.7, di mana sistem yang diwakili oleh lingkaran dan interaksi dengan anak panah.

21 3. Model Continuity Model yang diperoleh dalam tahap awal pembangunan harus gigih, menghindari menulis ulang mereka di setiap langkah. Untuk mendukung desain dan implementasi metodologi, model ini kontinuitas perhatian harus menjamin kesesuaian dalam model evolusi sepanjang seluruh proses pembangunan. Hal ini dimungkinkan dengan memungkinkan model yang akan disempurnakan melalui dimasukkannya atribut perilaku dan struktural baru yang diperoleh sepanjang desain dan tahapan pelaksanaan; lihat Gambar. 3.9.

22 4. Non-Functional Requirements Kebutuhan non-fungsional membatasi eksplorasi desain ruang, karena mereka biasanya memaksakan, pada tahap awal pengembangan, desain tertentu dan solusi implementasi. Semacam ini persyaratan dapat digolongkan ke dalam tiga kelompok yang berbeda: tujuan desain, keputusan desain, dan kendala desain. Tujuan desain terkait dengan persyaratan umum kinerja sistem kualitatif. Tujuan desain khas muncul dalam bentuk "itu harus secepat mungkin, "" itu harus murah "atau" itu harus mudah beradaptasi. "Meskipun, tujuan rancangan ini tidak benar-benar persyaratan, mereka dapat diubah menjadi kendala desain jika beberapa metrik dapat dibuat. Jika tidak, tujuan desain hanya boleh digunakan untuk memilih di antara alternatif setara fungsional, bila tidak ada kriteria yang lebih tegas untuk keputusan; lihat Bab. 12 untuk informasi lebih lanjut tentang pendukung keputusan dalam rekayasa persyaratan.

23 3.5 Requirements Transformation Masalah mendapatkan persyaratan sistem model dari kebutuhan pengguna yang dapat langsung digunakan dalam tahap desain tidak sederhana dan mudah dan menghadapi beberapa kesulitan [26]. Secara generik, melibatkan beberapa keputusan yang tidak dapat dibuat dengan metode atau alat, karena diskontinuitas alami antara model fungsional dan struktural. Holland and Lieberherr menganggap bahwa identifikasi objek dan deskripsi hubungan antara mereka adalah dua dari tiga tantangan desain berorientasi objek dalam pembangunan model berorientasi objek

24 1. User Requirements Modeling Identifikasi komponen sistem membutuhkan definisi model untuk menangkap fungsionalitas sistem yang ditawarkan untuk para penggunanya. Gunakan kasus adalah salah satu teknik yang paling cocok untuk tujuan itu, karena mereka adalah sederhana dan mudah dibaca. Bahkan, mereka hanya meliputi tiga konsep utama (use cases, actors and relations). Ini rendahnya jumlah konsep adalah karakteristik mendasar untuk melibatkan stakeholder non-teknis dalam proses capture persyaratan.

25

26 2. 4SRS Technique Transformasi kasus penggunaan menjadi model arsitektur yang mewakili persyaratan sistem adalah tugas yang sulit. Sebuah teknik yang disebut 4 step rule set (4SRS) diusulkan untuk membantu dengan tugas itu di [13]. Teknik 4SRS diatur sebagai empat langkah untuk mengubah kasus penggunaan menjadi objek: object creation (step 1), object elimination (step 2), Object packaging and aggregation (step 3) dan object association (step 4). Pada step1 (object creation), setiap kasus penggunaan harus diubah menjadi tiga objek (satu antarmuka, satu data, dan satu kontrol). Setiap objek menerima referensi dari kasus penggunaan masing-masing ditambahkan dengan akhiran (i, d, c) yang menunjukkan kategori objek (dalam pendekatan ini, referensi objek mulai dengan "O"). Ini adalah "otomatis" langkah sepenuhnya, karena tidak ada kebutuhan untuk setiap jenis keputusan tertentu atau alasan untuk konteks tertentu dari setiap kasus penggunaan. Dari langkah ini pada, hanya ada benda sebagai entitas desain. Gunakan kasus masih digunakan dalam langkah-langkah berikut untuk memungkinkan pengenalan kebutuhan ke model objek.

27 Pada Step 2 ( object eliminasi ), itu harus diputuskan mana dari tiga obyek harus dijaga untuk sepenuhnya mewakili, dalam istilah komputasi, kasus penggunaan, dengan mempertimbangkan seluruh sistem dan tidak setiap kasus digunakan dalam isolasi. Keputusan-keputusan ini harus didasarkan pada deskripsi tekstual untuk setiap kasus digunakan. Langkah ini bertujuan untuk memutuskan mana dari objek yang dibuat pada langkah 1 harus disimpan dalam model objek. Hal ini juga menghilangkan redundansi dalam persyaratan pengguna elisitasi dan mendeteksi persyaratan yang hilang. Pada step 3 (object packaging and aggregation), benda- benda yang tersisa (orang-orang yang dipertahankan setelah langkah 2) yang ada keuntungan dalam diperlakukan dengan cara yang terpadu harus memberikan asal ke agregasi atau paket objek semantik konsisten. Langkah ini mendukung pembangunan model objek yang benar-benar koheren, karena memperkenalkan lapisan semantik tambahan pada tingkat abstraksi yang lebih tinggi, yang bekerja sebagai "merekat fungsional" untuk objek.

28 Step 4 (object association) dari teknik 4SRS mendukung pengenalan asosiasi dalam model objek, sepenuhnya didasarkan pada informasi dari penggunaan model kasus dan dihasilkan dalam mikro-langkah 2i. Mengenai informasi dalam penggunaan model kasus, jika deskripsi tekstual kasus penggunaan memiliki petunjuk tentang jenis urutan menggunakan kasus yang dimasukkan ke dalam, informasi ini harus digunakan untuk memasukkan asosiasi dalam model objek

29

30 3. System Requirements Modeling Sistem model arsitektur mengungkapkan persyaratan sistem, tetapi juga deskripsi informal objek. 4SRS membantu untuk menentukan arsitektur logis untuk sistem dengan menangkap semua persyaratan fungsional dan non- fungsional niat nya. Yang pertama memberikan asal ke deskripsi tekstual untuk setiap objek dalam Model dan kemudian telah diklasifikasikan sebagai keputusan desain dan kendala desain. Tujuan desain yang tidak diizinkan di persyaratan sistem model yang dihasilkan oleh teknik 4SRS.

31 Kesimpulan Cara perhitungan benar persyaratan sistem dari kebutuhan pengguna merupakan topik penting dalam persyaratan teknik penelitian. Kegiatan ini menjamin bahwa tahap desain didasarkan pada kebutuhan klien yang efektif tanpa salah pikiran apapun sewenang-wenang diperkenalkan oleh para pengembang selama proses persyaratan sistem spesifikasi. Salah satu pendekatan untuk mendukung penurunan ini adalah dengan mengubah kebutuhan pengguna model ke model persyaratan sistem, dengan memanipulasi spesifikasi yang sesuai. Kebutuhan pengguna, biasanya, dijelaskan dalam bahasa alami dan dengan diagram informal pada tingkat yang relatif rendah detail dan terfokus dalam masalah domain. Persyaratan sistem terdiri dari model abstrak dari sistem, pada tingkat yang relatif tinggi detail, dan merupakan representasi sistem pertama yang digunakan pada awal tahap desain.