Rekayasa Perangkat Lunak (MKB111011) Pertemuan ke-6
Eko Harry Pratisto, S.T., M.Inf oTech. oTech.
[email protected]
Pemodelan Spesifikasi Kebutuhan Perangkat Lunak
Pemodelan Spesifikasi Kebutuhan Perangkat Lunak
emo e an spes as kebutuhan perangkat lunak › Rekayasa perangkat lunak pada umumnya dimulai dengan pemodelan yang menunjukkan spesifikasi kebutuhan perangkat lunak dan representasi perancangan perangkat lunak yang akan aka n dik dikemba embangka ngkan n
Pemodelan spesifikasi kebutuhan perangkat lunak › Kata-kata tertulis merupakan sarana komunikasi terbaik tetapi bukan cara yang terbaik untuk merepresentasikan spesifikasi kebutuhan perangkat lunak komputer › Pemodelan menggunakan gabungan dari bentuk teks dan diagram agar: – Mudah dipahami – Dapat langsung dilakukan penilaian untuk mengetahui kebenaran, kelengkapan dan konsistensinya
Mengapa pemodelan penting? › Untuk melakukan validasi terhadap spesifikasi-spesifikasi kebutuhan perangkat lunak perlu diperiksa modelmodel tersebut dari sudut pandang: – Model berbasis skenario – Model data (informasi) – Model berbasis kelas
› Masing-masing model merepresentasikan spesifikasi-spesifikasi kebutuhan perangkat lunak yang berbeda sehingga meningkatkan kemungkinan akan
Model-model analisis › Pekerjaan pemodelan spesifikasispesifikasi kebutuhan pada dasarnya akan menghasilkan beberapa jenis model: – Model berbasis skenario ; menggambarkan spesifikasi kebutuhan perangkat lunak dari berbagai sudut pandang “aktor” dari sistem – Model data ; menjelaskan area informasi untuk permasalahan yang akan diselesaikan – Model berorientasi kelas ; memperlihatkan kelas-kelas dalam konteks object oriented programming dan bagaimana kelas-kelas tersebut bekerjasama untuk mencapai sasaran
Model-model analisis – Model berorientasi aliran ; menggambarkan elemen-elemen fungsional sistem/perangkat lunak dan menggambarkan bagaimana perilakunya terhadap data yang melintasi sistem – Model perilaku ; menggambarkan bagaimana perangkat lunak berperilaku terhadap kejadian-kejadian yang datang dari luar sistem
Model-model analisis › Dari model-model analisis yang dijelaskan sebelumnya dapat memberikan informasi kepada seorang perancang perangkat lunak yang dapat diterjemahkan menjadi arsitektur sistem, interface dan perancangan tingkat komponen. › Pada akhirnya pengembang dan pengguna sistem dapat melakukan penilaian kualitas saat kelak perangkat lunak selesai dikembangkan.
Filosofi analisis › Dalam mendapatkan spesifikasi-spesifikasi kebutuhan perangkat lunak, fokus utama terletak pada bukan . › Kita berfokus pada: – apa yang terjadi saat pengguna berinteraksi dalam suatu keadaan tertentu – objek apa saja yang dimanipulasi – fungsi apa yang harus dapat dilakukan oleh sistem – perilaku apa yang akan diperlihatkan sistem – Batasan-batasan apa yang ditetapkan
Aturan-aturan analisis (Arlow and Neustadt) › Model seharusnya berfokus pada kebutuhan-kebutuhan yang tampak di dalam area permasalahan / jangan terlalu rinci. › Segala pertimbangan yang berkait dengan infrastruktur dan model-model non fungsional lainnya ditunda hingga tahap perancangan dimulai. › Diupayakan agar sebagai analisis sistem, kita merasa pasti bahwa model-model kebutuhan memberikan nilai tertentu
Aturan-aturan analisis (Arlow and Neustadt) › Usahakan agar model sesederhana mungkin. Jangan membuat diagramdiagram tambahan saat tidak ada informasi baru yang ditambahkan.
Pendekatan-pendekatan untuk pemodelan spesifikasi kebutuhan › Ada dua macam pendekatan untuk pemodelan analisis: – Analisis terstruktur ; dimana kita memperlakukan data dan proses yang melakukan transformasi data tersebut sebagai entitas yang terpisah. Objek-objek data dimodelkan dengan cara mendefiniskan atribut-atributnya serta relasi-relasinya – Analisis berorientasi objek; berfokus pada pendefinisian kelas-kelas dan cara bagaimana mereka saling berinteraksi satu sama lain untuk memenuhi kebutuhan para pengguna. UML (Unified Modelling Language)
misal: Use case User stories
misal: Diagram state Diagram urutan
misal: Diagram kelas Diagram kolaborasi
misal: DFD Model data
Pemodelan berbasis skenario Membuat Use Case mendefinisikan fungsionalitas sistem dari sudut pandang pengguna memperlihatkan apa yang › pengguna dapat lakukan dengan sistem memperlihatkan peran dari › pengguna yang berinteraksi dengan sistem merupakan diagram › yang menunjukkan keterlibatan antara ›
Batasan sistem › Sangat penting untuk mendefinisikan batasan sistem sebelum melengkapi kebutuhan dan use case. › Termasuk didalamnya: – What IS in the system – What is NOT in the system
Aktor › Tipe atau kategori pengguna (user) › Mendefinisikan peran yang pengguna dapat lakukan › Satu orang dapat berperan sebagai beberapa aktor › Aktor bisa merupakan sistem lain (tidak harus manusia) › Aktor merupakan bagian eksternal dari sistem
Katalog aktor › Katalog aktor adalah kumpulan informasi dari semua aktor › Setiap aktor terdiri: 1. 2. 3. 4. 5.
Nama aktor Deskripsi Daftar Use Case Representatif pengguna Detail kontak representatif pengguna
Contoh customer bank 1. Nama aktor – Customer
2. Deskripsi – Customer bank (memiliki rekening di bank)
3. Daftar Use Case – ATM penarikan, ATM transfer, ATM saldo, dll
4. Representatif pengguna – Eko Harry
5. Detail Kontak representatif pengguna
Use Case › Setiap use case terdiri dari: 1. Nama use case 2. Deskripsi use case 3. Daftar aktor › Bisa saja lebih dari 1 aktor
4. Dialog › › › › ›
Antara aktor dan sistem Aktor melakukan…. Sistem melakukan… Aktor melakukan… ….
5 Skenario/variasi
Use Case Vs Skenario/Variasi › Setiap selesainya tahapan suatu kejadian yang dilakukan oleh aktor kita identifikasikan sebagai Use Case › Skenario atau variasi – Daripada menuliskan sejumlah banyak use case
Representasi dari Use Case
Nama Use case
Contoh Use Case penggunaan ATM 1. Nama – ATM Penarikan tunai
2. Deskripsi – Use case menggambarkan penarikan uang dari mesin ATM
3. Daftar aktor – Customer
Contoh Use Case penggunaan ATM 4. Dialog – – – – – – – – – –
Sistem Aktor Sistem Aktor Sistem Aktor Sistem Aktor Sistem Aktor
: masukkan kartu : memasukkan kartu : menanyakan PIN : memasukkan PIN : transaksi apa yang diinginkan? : pilih penarikan tunai : masukkan nominal yang diinginkan : pilih Rp 50.000,00 : mengeluarkan uang Rp. 50.000,00 : selesai
Contoh Use Case penggunaan ATM 5. Variasi: – PIN salah – mempersilahkan 3x percobaan lalu tahan kartu – Saldo tidak cukup – memberi notifikasi saldo tidak mencukupi
Use case diagram Penarikan tunai
Transfer
customer
Cek saldo
pembayaran
Refill uang
Staff bank
Keuntungan Use Case Modelling › Fokus pada cara sistem akan digunakan › Penggunaan praktis untuk pengembangan perangkat lunak › Fokus pengembangan use case secara prioritas › Dasar dari user manual (panduan pengguna
Kerugian Use Case Modelling › Tidak ada spesifikasi untuk kebutuhan non behavioural › Tambahan notasi dan proses yang harus dipelajari
Sistem Interface
Perpotongan antara Use Case dan Batasan Sistem dinamakan Sistem Interface
Prototipe atau sketsa User Interface › Disarankan sebagai cara yang praktis untuk spesifikasi kebutuhan pengguna › Seorang sistem analis membangun sketsa atau prototipe sederhana dari user interface
Alat untuk membuat prototipe atau sketsa user interface › Alat sketsa – Pandangan storyboard dari user interface
› Visual development tools › Program drawing
Keuntungan dari sketsa atau prototipe user interface › Tidak susah untuk dibuat dan mudah untuk didiskusikan › Memberi pengguna kesan yang baik akan fungsionalitas sistem › Secara umum jelas dan tidak ambigu › Sebagai pedoman untuk pengembangan
Kerugian dari sketsa atau prototipe user interface › Tidak ada spesifikasi untuk kebutuhan non fungsional › Tidak terlihat prioritas kebutuhan
Contoh user interface Silahkan pilih transaksi > Cek Saldo > Penarikan tunai > Pembayaran
Transfer < Lain – lain <
Pertanyaan…?? Komentar…???
