PEMODELAN ANALISIS

Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang

membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain yang

komprehensip bagi perangkat lunak yang dibangun.

Elemen Model Analisis

Model analisis harus dapat mencapai tiga sasaran utama yakni untuk :

• Menggambarkan apa yang dibutuhkan untuk pelanggan

• Membangun dasar bagi pembuatan desain perangkat lunak

• Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.

Rekayasa Perangkat Lunak

Untuk mencapai sasaran tersebut dibuatlah model analisis yang berisi:

• Data Dictionary

Penyimpanan yang berisi deskripsi dari semua obyek data yang dikonsumsi atau diproduksi

oleh perangkat lunak.

• Entity Relationship Diagram (ERD)

Menggambarkan hubungan antara obyek data.

• Data Flow Diagram (DFD)

o Memberikan indikasi mengenai bagaiman data ditransformasi pada saat data bergerak

melalui sistem

o Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.

• State Transition Diagram

Menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal.

• Control Specification (CSPEC)

Informasi tambahan mengenai aspek kontrol dari perangkat lunak

Pemodelan Data

Untuk dapat menjawab sebagai berikut :

• Bagaimana komposisi dari masing-masing obyek data dan atribut apa yang menggambarkab

obyek tersebut?

• Dimana obyek saat ini berada?

• Bagaimana hubungan antara masing-masing obyek data dan obyek lainnya?

• Bagaimana hubungan antara obyek dengan proses yang mentransformasikannya?

Digunakan Entity Relational Diagram (ERD)

Obyek Data, Atribut dan Hubungan

• Obyek Data

Adalah representasi dari hamper semua informasi gabungan yang harus dipahami oleh

perangkat lunak

• Atribut

Menentukan property suatu obyek data dan mengambil salah satu dari tiga karakteristik yang

berbeda.

o Menamai sebuah contoh dari obyek data

o Menggambarkan contoh

o Membujat referensi ke contoh yang lain pada tabel yang lain.

• Hubungan

Obyek data disambungkan satu dengan lainnya dengan berbagai macam cara.

Kardinalitas dan Modalitas

Kardinalitas

Model data harus dapat merepresentasikan jumlah peristiwa dari obyek di dalam hubungan yang

diberikan

o Satu ke satu (1:1)

Misalnya: seorang suami hanya dapat memiliki satu istri, dan seorang istri hanya mempunyai

satu suami.

o Satu ke banyak (1:N)

Misalnya: seorang ibu dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki

satu ibu.

o Banyak ke banyak (M:N)

Misalnya: seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan

dapat memiliki banyak paman.

Modalitas

Modalitas dari suatu hubungan adalah nol bila tidak ada kebutuhan eksplisit untuk hubungan yang

terjadi atau hubungan itu bersifat opsional. Modalitas bernilai satu jika suatu kejadian dari hubungan

merupakan perintah.

Entity Relational Diagram

Pada mulanya digunakan untuk desain sistem database relational dan telah dikembangkan oleh

yang lainnya. Serangkaian komponen utama diidentifikasikan untuk ERD: obyek data, atribut,

hubungan dan berbagai tipe indicator. Tujuan utama dari ERD adalah untuk mewakili obyek data dan

hubungan mereka.

Pemodelan Fungsional dan Aliran Informasi.

Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis komputer.

Sistem tersebut menerima input dengan berbagai cara dan menghasilkan suatu output. Akibatnya kita

dapat menciptakan suatu model aliran bagi setiap sistem berbasis komputer tanpa melihat ukuran dan

kompleksitasnya.

Diagram Aliran Data/ Data Flow Diagram (DFD)

Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang

diaplikasikan pada saat data bergerak dari input menjadi output.

Dikenal juga dengan sebutan grafik aliran data atau buble chart.

Komponen-komponen DFD :

o Proses

o External entity

o Data Flow

o Data Store

Proses

o Simbol proses adalah :

o Proses menunjukkan apa yang dikerjakan oleh sistem

o Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol.

File atau Data Store

o Simbol :

o File atau Data Store adalah tempat penyimpanan data

o Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store

o Setiap data store mempunyai nama yang unik

External Entity

External entity adalah di luar sistem, tetapi mereka merupakan salah satu bagian yang memberikan

input data ke dalam sistem atau digunakan oleh output sistem

Source : External entity yang memberikan input data ke dalam sistem

Sinks : External entity yang menggunakan data sistem

Data Flow

Simbol : anak panah menunjukkan arah aliran

Aliran data pada sistem :

antara dua proses

dari sebuah data store ke sebuah proses

dari sebuah proses ke sebuah data store

dari sebuah source ke sebuah proses

dari sebuah proses ke sebuah sink

Menggambarkan Sistem Dengan Dataflow Diagram

Langkah awal adalah membuat “DIAGRAM KONTEKS”

Diagram konteks : DFD di mana sistem terdiri dari satu proses

Pada tahap ini terlihat semua external entity yang berinteraksi dengan sistem dan data flow, antara

external entity dan sistem

Budget monitoring system
System berinteraksi dengan 3 external entity, yaitu :

DEPARTEMENTS
MANAGEMENTS
SUPPLIERS

Aliran data utama dari Departements adalah “Spending Request”.

Sebagai tanggapan dari sistem, Departemen menerima “Rejected Request” atau aliran data

“Delivery Advice”

Management menerima data flow “Request For Special Approval”, yang kemudian memberikan respons
Management juga mengirim data flow “Budget Allocation” ke sistem dan mendapatkan data flow “Spending Summaries”
Supplier menerima data flow “Part Order” dan mengembalikan data flow “Supplier Delivery Advice”

Setelah mendapatkan “Diagram Konteks”, langkah selanjutnya adalah membuat DFD yang

memperlihatkan proses dari sistem utama, yang dinamakan dengan TOP LEVEL DFD

Top level DFD memperlihatkan berbagai proses yang membentuk sistem
Setiap proses mempunyai sebuah nama unik dan nomor proses
Dari DFD di atas kita lihat bahwa data flow “Spending Request” dari Departements menuju ke proses “Check Funding”. Proses “Check Funding” melihat “Allocated Budget” dan menetapkan apakah izin khusus diperlukan dari management untuk diteruskan ke permintaan.
Data flow “Approved Request” menuju ke proses “Classify Expenditure”, dan kemudian dimasukkan pada data store “Departemental-Accounts” dan “Type-Accounts”.
Akhirnya, jika diperlukan, “Part Order” untuk menetapkan bagian ( part ) semula dalam “Spending Request” diurus oleh supplier.
Dua proses lainnya : “Setup Budget” dan “Provide Spending Summaries”

Kita dapat memperluas setiap proses pada Top Level DFD. Sebagai contoh diambil proses “Classify

Expenditure”

Data Flow Diagram yang baik :

Ketiadaan dari struktur flowchart
Penyimpanan data
Penamaan yang baik

Perbedaan antara Flowchart dan Data Flow Diagram :

Flowchart terdiri dari box-box yang mendeskripsikan :

Komputasi
Decision / Keputusan
Iterasi
Loop

Data Flow Diagram bukan Flowchart program dan tidak mempunyai elemen kontrol

DFD yang baik harus :

Tidak mempunyai aliran data yang split up ke dalam sejumlah aliran data lain
Tidak mempunyai garis yang berpotongan
Tidak terdapat iterasi antara 2 proses ; 1 proses dengan dirinya sendiri
Tidak mengandung aliran data yang berfungsi sebagai signal untuk mengaktifkan suatu proses

Mekanik dari Analisis Terstruktur

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 :

ü 1.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.

ü 2.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.

ü 3. Dimanapun sambungan ada, analis dan pelanggan menciptakan satu pasangan hubungan objek atau lebih .

ü 4. Untuk masing-masing pasangan hubungan objek, dicari kardinalitas dan modalitas.

ü 5.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.

ü 6. Atribut dari masing-masing eantitas didefinisikan

ü 7. Diagram entitas diformalisasikan dan dikaji

ü Langkah 1 sampai 7 diulangi smpai pemodelan data terlengkap

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

Me 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.

lelah 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).

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.

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.

Kamus Data

Kamus data adalah suatu kumpulan data elemen yang terstruktur dengan pengertian yang
konsisten dan sesuai dengan sistem, sehingga pengguna maupun analis sistem memiliki
pemahama yang sama mengenai masukan, keluaran dan komponen simpanan data .
Pembentukan kamus data didasarkan pada alur data yang terdapat pada Diagram Alir Data (DAD). Alira data pada DAD bersifat umum (hanya menunjukkan nama alur datanya tanpa
menunjukkan struktur dari alur data). Unutk menunjukkan struktur dari aliran data
secara detail maka dibutuhkan sebuah kamus data.

Kamus Data (KD) dibuat pada tahap analisis sistem dan digunakan baik pada tahap analisis maupun pada tahap perancangan sistem. Pada tahap analisis sistem, KD dapat digunakan sebagai alat komunikasi antara analisis sistem dengan pemakai sistem tentang data yang mengalir di sistem, yaitu tentang data yang masuk ke sistem dan tentang informasi yang dibutuhkan oleh pemakai sistem. Pada tahap perancangan sistem, KD digunakan untuk merancang input, merancang laporan-laporan dan database. Kamus data dibuat berdasarkan arus data yang ada di DAD.

Manfaat Kamus Data

Kamus Data (KD) adalah katalog fakta tentang data dan kebutuhan-kebutuhan informasi
dari suatu sistem informasi. Kamus data selain digunakan untuk dokumentasi dan mengurangi redudansi, juga dapat digunakan untuk:

Memvalidasi diagram aliran data dalam hal kelengkapan dan keakuratan
Menyediakan suatu titik awal untuk mengembangkan layar dan laporan-laporanMenentukan muatan data yang disimpan dalam file-file
Mengembangkan logika untuk proses-proses diagram aliran data

Fungsi Kamus Data

Kamus Data mendefinisikan elemen data dengan fungsi sebagai berikut:

Menjelaskan arti aliran data dan penyimpanan data dalam DFD
Mendeskripsikan komposisi paket data yang bergerak melalui aliran (misalnya
alamat
diuraikan menjadi kota, negara dan kode pos)
Mendeskripsikan komposisi penyimpanan data
Menspesifikasikan nilai dan satuan yang relevan bagi penyimpanan dan aliran
Mendeskripsikan hubungan detil antar penyimpanan (yang akan menjadi titik perhatian dalam entity-relationship diagram)

Hubungan antara DFD dan KD

Kamus data dibuat dengan memperhatikan dan menggambarkan muatan aliran data,
simpanan dataa dan proses-proses seperti pada gambar di atas. Setiap simpanan data dan
aliran data bisa ditetapkan dan kemudian diperluas sampai mencakup detail-detail elemen
yang dimuatnya. Logika dari setiap proses ini bisa digambarkan dengan menggunakan data
yang mengalir menuju dan keluar dari proses tersebut.

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.

SUMBER

http://minangmylife.blogspot.co.id/2016/04/pemodelan-analisis.html

http://fairuzelsaid.com/kamus-data/

http://lhabreinda.blogspot.co.id/2012/06/pemodelan-analisis-mekanik-dari.html

http://ermawita91.blogspot.co.id/2012/06/materi-pemodelan-analisis.html

http://rickyrahmanharvard.blogspot.co.id/2012/06/pemodelan-fungsional-dan-aliran.html