Komponen-komponen DFD :
- Proses : menunjukkan apa yang dikerjakan oleh sistem. Setiap proses
memiliki nama yang unik dan nomor yang ditempatkan dalam simbol.
- External entity adalah di luar sistem, tetapi mereka merupakan salah
satu bagian yang memberikan input data ke dalam sistem atau digunakan
oleh output sistem
- Data Flow adalah tempat penyimpanan data
- Data Store : Proses dapat menempatkan data ke dalam data store atau
mengambil / mendapatkan data store. Setiap data store mempunyai nama
yang unik External Entity
Pemodelan Tingkah Laku :
Model prilaku menggambarkan bagaimana PL merespon event atau stimulan
eksternal. Untuk model tersebut, anlisis harus melakukan langkah-langkah
sebagai berikut :
- Evaluasi semua use-case untuk mendapatkan pemahaman menyeluruh tentang urutan interaksi di dalam sistem.
- Mengenali event yang mengendalikan urutan interaksi dan memahami bagaimana event mempunyai relasi terhadap objek spesifik.
- Membuat urutan untuk setiap use-case.
- Membangun state diagram untuk sistem.
- Review model behavioral untuk memverifikasi akurasi dan konsistensi
Model Proses Perangkat Lunak Evolusioner
Model evolusioner
adalah model iteratif. Model itu ditandai dengan tingkah laku yang
memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat
lunak yang lebih lengkap sedikit demi sedikit.
Model Pertambahan
Model inkremental menggabungkan elemen-elemen
model sekuensial linier dengan filosofi prototipe iteratif. Pada saat
model pertambahan dipergunakan, pertambahan pertama sering merupakan
produk inti (core product), yaitu sebuah model pertambahan yang
dipergunakan, tetapi beberapa muka tambahan tetap tidak disampaikan.
Produk inti tersebut dipergunakan oleh pelanggan (atau mengalami
pengkajian lebih detail). Sebagai hasil dari pemakaian dan/atau
evaluasi, maka dikembangkan rencana bagi pertambahan selanjutnya.
Rencana tersebut menekankan modifikasi produk inti untuk secara lebih
baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta
fungsionalitas tambahan. Proses ini diulang mengikuti penyampaian setiap
pertambahan sampai bisa menghasilkan produk yang lengkap.
Model
proses pertambahan tersebut, seperti model prototipe dan
pendekatan-pendekatan evolusioner yang lain, bersifat iteratif. Tetapi
tidak seperti model prototipe, model pertambahan berfokus pada
penyampaian produk operasional dalam setiap pertambahannya. Pertambahan
awal ada di versi stripped down dari produk akhir, tetapi memberikan
kemampuan untuk melayani pemakai dan juga menyediakan platform untuk
evaluasi oleh pemakai.
Model Spiral
Model spiral yang pada awalnya diusulkan oleh Boehm
adalah model proses perangkat lunak yang evolusioner yang merangkai
sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis
dari model sekuensial linier. Model itu berpotensi untuk pengambangan
versi pertambahan perangkat lunak secara cepat.
- Model spiral dibagi menjadi sejumlah aktivitas kerangka kerja,
disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas.
Gambar 2.8. menggambarkan model spiral yang berisi enam wilayah tugas :
Komunikasi pelanggan – tugas-tugas yang dibutuhkan untuk membangun
komunikasi yang efektif di antara pengembang dan pelanggan
- Perencanaan – tugas-tugas yang dibutuhkan untuk mendefinisikan
sumber-sumber daya, ketepatan waktu, dan proyek informasi lain yang
berhubungan.
- Analisis risiko – tugas-tugas yang dibutuhkan untuk menaksir risiko-risiko, baik manajemen maupun teknis.
- Perekayasa – tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut
- Konstruksi dan peluncuran – tugas-tugas yang dibutuhkan untuk
mengkonstruksi, menguji, memasang (install) dan memberikan pelayanan
kepada pemakai (contohnya pelatihan dan dokumentasi).
- Evaluasi pelanggan – tugas-tugas yang dibutuhkan untuk memperoleh
umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi
perangkat lunak, yang dibuat selama masa perekayasaan, dan
diimplementasikan selama masa pemasangan.
Ketika proses evolusioner ini mulai, tim rekayasa perangkat lunak
bergerak searah jarum mengelilingi spiral tersebut dengan dimulai
intinya. Lintasan pertama putaran spiral menghasilkan perkembangan dari
spesifikasi produk; putaran spiral selanjutnya mungkin dipakai untuk
mengembangkan sebuah prototipe, dan secara progresif mengembangkan versi
perangkat lunak yang lebih canggih. Tidak seperti model proses
klasik yang berakhir pada saat perangkat lunak sudah disampaikan, model
spiral bisa disesuaikan agar perangkat lunak bisa dipakai selama hidup
perangkat lunak komputer.
Model spiral menjadi sebuah pendekatan yang
realistis bagi perkembangan sistem dan perangkat lunak skala besar.
Karena perangkat lunak terus bekerja selama proses bergerak, pengembang
dan pemakai memahami dan bereaksi lebih baik terhadap risiko dari setiap
tingkat evolusioner. Model spiral menggunakan prototipe sebagai
mekanisme pengurangan risiko.
Model Rakitan Komponen
Model
rakitan komponen menggabungkan beberapa karakteristik model spiral.
Model ini bersifat evolusioner, sehingga membutuhkan pendekatan iteratif
untuk menciptakan perangkat lunak. Tetapi model rakitan komponen
merangkai aplikasi dari komponen perangkat lunak sebelum dipaketkan
(kadang-kadang disebut “kelas”).
Model rakitan komponen membawa
kepada penggunaan kembali perangkat lunak, dan kegunaan kembali tersebut
memberi sejumlah keuntungan yang bisa diukur pada perekayasa perangkat
lunak.
Model perkembangan Konkuren
Model proses konkuren
sering digunakan sebagai paradigma bagi pengembangan aplikasi
klien/server. Sistem klien/server dirancang dari serangkaian komponen
fungsional. Bila diaplikasikan kepada klien/server, model proses
konkuren akan mendefinisikan aktivitas di dalam dua dimensi : dimensi
sistem, dan dimensi komponen. Isu tingkat sistem ditujudengan
menggunakan tiga aktivitas : desain, assembly, dan pemakaian. Dimensi
komponen dituju dengan dua aktivitas : desain dan rea-lisasi. Konkuren
dicapai dengan dua cara :
- aktivitas sistem dan komponen yang berlangsung secara simultan dan
dapat dimodelkan dengan menggunakan pendekatan orientasi keadaan yang
digambarkan di atas;
- aplikasi klien/server khusus diimplementasikan dengan banyak
komponen di mana masing-masing bisa dirancang dan direalisasikan secara
konkuren.
4.Mekanik dari analisis terstruktur
a.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.
b.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
c.membuat sebuah 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).
d.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.
e.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.
5.Kamus Data
Kamus data adalah suatu daftar data elemen yang terorganisir dengan
definisi yang tetap dan sesuai dengan sistem, sehingga user dan analis
sistem mempunyai pengertian yang sama tentang input, output, dan
komponen data strore. Kamus data ini sangat membantu analis sistem
dalam mendefinisikan data yang mengalir di dalam sistem, sehingga
pendefinisian data itu dapat dilakukan dengan lengkap dan terstruktur.
Pembentukan kamus data dilaksanakan dalam tahap analisis dan perancangan
suatu sistem. Pada tahap analisis, kamus data merupakan alat
komunikasi antara user dan analis sistem tentang data yang mengalir di
dalam sistem, yaitu tentang data yang masuk ke sistem dan tentang
informasi yang dibutuhkan oleh user. Sementara itu, pada tahap
perancangan sistem kamus data digunakan untuk merancang input, laporan
dan database.
6.Overview mengenai metode analisis
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.
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.
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.
Suber : http://hendriipunj.blogspot.co.id/
http://lhabreinda.blogspot.co.id/2012/06/pemodelan-analisis-mekanik-dari.html
http://blog.uad.ac.id/fendhias/2014/11/09/pemodelan-analisis-versi-terstruktur/
