PEMODELAN TINGKAH LAKU
Pemodelan tingkah laku merupakan suatu prinsip operasional untuk semua metode analisis persyaratan tetapi hanya versi analisis terstruktur yang luas yang memberikan suatu notasi bagi tipe pemodelan ini. Untuk menggambarkan penggunaan ekstensi control dan tingkah laku Hatley dan Pirbhai, diandaikan perangkat lunak embedded dalam sebuah mesin foto kopi. Foto kopi tersebut melakukan sejumlah fungsi yang diimplikasikan oleh DFD tingkat 1. perlu dicatat bahwa penyaringan tambahan dari aliran dan definisi dari masing-masing item akan diperlukan.
MEKANIK DARI ANALISIS TERSTRUKTUR
2.1 Membuat sebuah diagram hubungan Entitas
Diagram hubungan entitas memungkinkan seorang perekayasa perangkat lunak untuk secara penuh menspesifikasikan objek data yang merupakan input dan output dari system. Pendekatan berikut ini perlu diketahui dalam membuat diagram Entitas :
ü Selama pengumpulan persyaratan, pelanggan diminta untuk mendaftar ‘hal-hal’ yang akan dituju oleh proses bisnis dan aplikasi. ‘Hal-hal’ ini dimasukkan kedalam sebuah daftar objek data input dan output dan entitas eksternal yang menghasilkan atau mengkonsumsi informasi.
ü Dengan mengambil objek satu pada satu saat , analis dan pelanggan mendefinisikan apakah ada sambungan (tidak diberi nama pada tahap ini ) ada diantara objek data dan objek lain.
ü Dimanapun sambungan ada, analis dan pelanggan menciptakan satu pasangan hubungan objek atau lebih .
ü Untuk masing-masing pasangan hubungan objek, dicari kardinalitas dan modalitas.
ü Langkah 2 sampai 4 dilanjutkan secara iterative sampai semua pasangan hubungan objek sudah didefinisikan. Sudah menjadi kebiasaan untuk menemukan penghilangan pada saat proses ini berlanjut. Objek dan hubungan baru akan ditambahkan pada saat jumlah iterasi bertambah.
ü Atribut dari masing-masing entitas didefinisikan
ü Diagram entitas diformalisasikan dan dikaji
ü Langkah 1 sampai 7 diulangi sampai pemodelan data terlengkapi.
2.2 Membuat Sebuah Model Aliran Data
Diagram aliran data (DFD) memungkinkan perekayasa perangkat lunak untuk mengembangkan model domain informasi dan domain fungsional pada saat yang sama. Beberapa tuntunan sederhana dengan terukur dapat membantu selama derivasi sebuah diagram aliran data :
1. diagram aliran data tingkat 0 harus menggambarkan perangkat lunak/system sebagai gelembung tunggal.
2. input dan output utama harus dicatat secara berhati – hati
3. penyaringan harus dimulai dengan mengisolasi proses calon, objek data, dan penyimpanan yang akan direpresentasikan pada tingkat selanjutnya.
4. semua anak panah dan gelembung harus diberi label dengan nama yang berarti
5. kontinyuitas aliran informasi harus dijaga dari tingkat ke tingkat
6. satu gelembung pada satu saat harus disaring.
Ada kecenderungan natural untuk terlalu mengkomlikasikan diagram aliran data. Hal ini terjadi bila analisis ingin menunjukkan terlalu banyak detail pada saat yang terlalu dini
2.3 Membuat Sebuah Model Aliran Kontrol
Untuk beberapa tipe aplikasi pemrosesan, model data dan diagram aliran data meruapakan hal yang diperlukan untuk memperoleh wawasan yang berarti kedalam persyaratan perangkat lunak. Tetapi, seperti yang telah dicatat, disana ada suatu kelas aplikasi yang besar yang lebih dikendalikan oleh kejadian dari pada data, yang lebih menghasilkan informasi control dari pada menghasilkan laporan dan tampilan. Dan yang memproses informasi dengan perhatian besar kepada waktu dan kinerja kerja. Aplikasi semacam itu mambutuhkan pemodelan aliran control sebagai tambahan kepemodelan aliran data.
Telah kita catat bahwa sebuah kejadian atau item control diimplementasikan sebagai harga Boolean (misalnya; benar atau salah, on atau off, 1 atau 0) atau sebuah daftar diskrit dari keadaan (kosong,penuh), untuk memilih calon kejadian yang potensial, diusulkan tuntutan berikut ini :
· Daftarlah semua sensor yang dibaca oleh perangkat lunak
· Daftarlah semua keadaan interupsi
· Bacalah semua saklar yang diaktuasi oleh operator
· Daftarlah semua keadaan data
· Dengan menarik uraian data kerja dan data benda yang diaplikasikan ke narasi pemrosesan, kajilah semua item control sebagai input /output CSPEC yang mungkin
· Gambarkanlah tingkah laku dari system dengan mengidentifikasi keadaannya ; identifikasikanlah bagaimana keadaan dicapai dan definisikanlah transisi antar keadaan.
· Fokuskanlah penghilangan yang mungkin sebuah kesalahan yang paling umum didalam menspesifikasikan control (misalnya, tanyakanlah ; adakah suatu cara dimana saya dapat masuk ke keadaan itu atau keluar darinya).
2.4 Spesifikasi Kontrol
CSPEC mempresentasikan tingkah laku system (pada tingkat dimana dia direferensikan) didalam dua cara yang berbeda. CSPEC berisi sebuah diagram transisi keadaan (STD) yang merupakan suatu spesifikasi sekuensial dari tingkah laku. Dia juga dapat berisi suatu table aktifitas proses (PAT) – sebuah spesifikasi kombinaturial dari tingkah laku.
2.5 Spesifikasi Proses
Spesifikasi Proses (PSPEC) digunsksn untuk menggambarkan semua proses model aliran yang nampak pada tingkat akhir penyaringan.Kandungan dari spesifikasi proses dapat termasuk teks naratif, bahasa design program/Progamme Design Language (PDL) dari Algoritma proses, persamaan Matematika, table, diagram atau bagan, dengan memberikan sebuah PSPEC untuk mengiringi masing-masing gelembung didalam model aliran, berarti perekayasa perangkat lunak menciptakan sebuah “spesifikasi mini”yang dapat berfungsi sebagai sebuah langkah pertama didalam kreasi spesifikasi persyaratan perangkat lunak dan sebagai penuntun bagi desaign komponen program yang akan mengimplementasikan program.
Gambar 14.0 Spesifikasi Proses Menggunakan PDL untuk proses DFD
KAMUS DATA
Kamus data telah diusulkan sebagai sebuah tata bahasa quasi-formal untuk menggambarkan kandungan dari objek yang didefinisikan selama analisis terstruktur. Notasi pemodelan yang penting ini telah didefinisikan sebagai berikut : Kamus data merupakan sebuah daftar yang teroganisasi dari elemen data yang berhubungan dengan system, dengan definisi yang tegar dan teliti sehingga pemakai dan analisis system akan memiliki pemahaman yang umum mengenai input, output, komponen penyimpan , dan bahkan kalkulasi inter-mediate.
Saat ini, kamus data hamper selalu diimplementasikan sebagai bagian dari sebuah “piranti desain dan analisis terstruktur “ CASE. Sebagian kamus data berisi informasi sebagai berikut :
- Name = sebenarnya dari data atau item control, penyimpanan data, atau entitas eksternal.
- Aliasi = nama lain yang digunakan untuk entri pertama
- Where-used/how used = suatu daftar dari proses yang menggunakan data atau item control dan bagaimana dia digunakan (misalnya input ke progress, output dari progress, sebagai suatu penyimpanan, sebagai suatu entitas eksternal)
- Content description = suatu notasi untuk mempresentasikan isi
- Supplementary information = informasi lain mengenai tipe data, harga preset (bila diketahui).
Notasi yang digunakan untuk mengembangkan diskripsi isi, yang diilustrasikan didalam Gambar 9.0 memungkinkan analisis untuk mempresentasikan data komposit (misal objek data) didalam salah satu dari tiga fundamenta yang dapat dikonstruksi olehnya :
1. sebagai sebuah urutan item data
2. sebagai suatu pilihan dari antara serangkaian item data atau
sebagai sebuah kelompok pengulangan item data
Masing-masing entri item data direpresentasikan sebagai bagian dari urutan, seleksi dan pengulangan dapat menjadi objek data lain yang memerlukan penyaringan lebih jauh lagi didalam kamus.
METODE ANALISIS KLASIK
Data Structured Systems Development
Data Structure System Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur data..
Ken Orr memperluas kerja Warnier untuk mencakup pandangan yang lebih luas mengenai domain informasi yang telah dikembangkan kedalam DSSD
Jackson System Development
Jackson System Development (JDS) mengembangkan kerja yang dilakukan oleh M.A. Jackson tentang analisis domain informasi dan hubungannya dengan desain system dan program. Dalam kalimat Jackson , “Pengembang memulai dengan menciptakan sebuah model realistis dimana system diperhatikan, realitas yang memperlengkapi masalah subjek (system)nya..”
SADT
Structured analysis and design technique (SADT) adalah sebuah teknik yang telah digunakan secara luas sebagai sebuah notasi untuk definisi system, representasi proses, analisis persyaratan perangkat lunak dan desaign system /perangkat lunak. 
0 komentar:
Posting Komentar