Konsep, Prinsip, dan Pemodelan AnalisisKONSEP DAN PRINSIP ANALISIS
1. Analisis kebutuhan perangkat lunak
Analisis kebutuhan merupakan langkah awal untuk menentukan gambaran perangkat yang akan dihasilkan ketika pengembang melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat tergantung pada keberhasilan dalam melakukan analisis kebutuhan. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning.
Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik, tetapi analisa kebutuhan yang tidak tepat menghasilkan perangkat yang tidak berguna. Mengetahui adanya kesalahan pada analisis kebutuhan pada tahap awal memang jauh lebih baik, tapi kesalahan analisis kebutuhan yang diketahui ketika sudah memasuki penulisan kode atau pengujian, bahkan hampir masuk dalam tahap penyelesaian merupakan malapetaka besar bagi pembuat perangkat lunak. Biaya dan waktu yang diperlukan akan menjadi sia sia.
Analisis kebutuhanAnalisa kebutuhan adalah suatu proses untuk mendapatkan informasi, mode, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi dari klien yang akan menjadi acuan untuk melakukan desain perangkat lunak.
Analisis kebutuhan merupakan satu di antara banyak aktivitas kritis pada proses rekayasa kebutuhan perangkat lunak untuk memahami ranah permasalahan dari sistem yang berjalan dan ranah solusi dari sistem yang akan dibuat(Yen et.al, 1998).
Ada tiga faktor yang harus dipenuhi ketika melakukan analisis kebutuhan ini, yaitu lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisis. Detail maksudnya adalah berhasil mengumpulkan informasi yang terperinci. Semua data dari analisis kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang dipikirkan oleh pihak analisis.
Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok:
a.Identifikasi Masalah
b.Evaluasi dan sintesis
c.Pemodelan
d.Spesifikasi
e.Review
2. Teknik komunikasi
Menurut Gause dan Weinberg menyarankan agar analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan.
Contoh:
- Siapa di balik permintaan untuk pekerjaan ini?
- Apa keuntungan ekonomi dari pemecahan yang berhasil?
Rangkaian pertanyaan berikutnya memungkinkan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.
- Masalah apakah yang akan diselesaikan oleh pemecahan ini?
- Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana pemecahan tersebut akan digunakan
3. Prinsip-prinsip analisis
Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:
- Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
- Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
- Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
- Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
- Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
- Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku, yaitu:
- Model Fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output.
4. Prototyping perangkat lunak
a. Prototyping Perangkat
Analisis harus dilakukan tanpa mengabaikan paradigma rekayasa perangkat lunak yang di aplikasikan; tetapi bentuk yang diambil oleh analisis akan bermacam- macam. Dalam banyak kasus sangat mungkin untuk mengaplikasikan prinsip operasional dan menarik sebuah model perangkat lunak yang melaluinya sebuah desain dapat dikembangkan, pengaplikasian prinsip analisis dan penyusunan model perangkat lunak yang akan dibangun yang disebut prototype untuk penilaian pelanggan danpengembang.
b. Pemilihan prototyping
Paradigma prototyping terbatas dan tidak terbatas. Pendekatan terbatas sering disebut : throw away prototyping. Dengan menggunakn pendekatan tersebut, prototyping sebagai sebuah demonstrasi kasar dari sebuah persyaratan.Kemudian prototype dikesampingkan dan perangkat lunak direkayasa dengan menggunakan suatu paradigma yang berbeda.Pendekatan tidak terabatas sering disebut evolusionary prototyping,menggunakan prototyping sebagai bagian utama dari aktivitas analisis yang akan diteruskan ke dalam desain dan konstruksi.
c. Metode dan Peranti Prototyping
Agar prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dengan dapat menilai hasil dan perubahan yang di rekomendasikan. Untuk melakukan prototyping dengan tepat ad tiga kelas metode dan peranti generik, teknik generasi keempat komponen perangkat lunak reusable, spesifikasi normal,dan lingkungan prototyping.
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.
1. 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.
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
2. 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)
a. 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.
b. 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.
c. 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.
3. 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
Bagaimana membuat : Decisions dan Interactive Control
- Decisions dalan DFD
- Perulangan dalam DFD
Penyimpanan Data
- Data store tidak boleh membuat “elemen data” baru
- Proses juga tidak dapat membuat data baru ; hanya mengambil data dan mengeluarkannya ke dalam sebuah bentuk data baru
Beberapa petunjuk dalam pemakaian nama ( penamaan )
a. Penamaan “Proses”
Nama proses harus frase tunggal dan dapat mendeskripsikan suatu proses dalam sebuah kalimat
Nama proses harus mendefinisikan kegiatan / aksi yang spesifik
Jika suatu proses menangani beberapa proses, maka harus dipecah menjadi beberapa proses
b. Penamaan Data Store
Gunakan nama yang khas / spesifik
Ingat bahwa setiap data store hanya berisi satu set struktur data
Contoh
Machine_Schedules and Parts_Used
pisahkan ke dalam 2 data store
c. Penamaan Data Flows antara Proses
Gunakan 1 kata / frase. Contoh : “Kuitansi” , “Cek” , dan sebagainya
Jangan menggunakan nama yang sama untuk setiap data flow
4. Mekanik dari analisis terstruktur
– bangun ERD
– bangun DFD + Data Dictionary + P-SPEC
– (bangun CFD)
– bangun STD + C-SPEC
5. Kamus Data (Data Dictionary)
• Menyimpan semua objek data yang
dibutuhkan dan dihasilkan oleh PL
– objek data yang muncul pada:
•ERD
•DFD
•STD
– harus selengkap dan serinci mungkin
• contoh: Nama = nama_depan + nama_belakang
• Berisi:
–Name
• nama utama yang muncul pada objek data, data store atau eksternal entity
– Alias
• nama lain yang digunakan
– Where-used/how-used
• daftar proses yang menggunakan data dan bagaimana menggunakannya.
– Content description
• notasi untuk merepresentasikan isi data
– Supplementary information
•Notasi:
Jenis Notasi Arti
======================================
= Terdiri atas
urutan + dan
pilihan [ | ] atau
pengulangan { } Pengulangan sebanyak n kali
( ) Data optional
* * pembatas komentar
• Contoh:
– nama mahasiswa = nama depan + nama
belakang
– jenis kelamin = [perempuan | laki-laki]
– nomor telepon = (kode negara) + kode wilayah
+ nomor
6. Overview mengenai metode analisis
Berikut sekilas mengenai Overview 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.
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..”
JSD memiliki enam langkah pengembangan sistem, yaitu:
-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.
Terdapat dua jenis diagram yang dipakai dalam paket SADT, yaitu:
1. Diagram kegiatan (yang dinamakan aktigram)
Menurut Gause dan Weinberg menyarankan agar analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan.
Contoh:
- Siapa di balik permintaan untuk pekerjaan ini?
- Apa keuntungan ekonomi dari pemecahan yang berhasil?
Rangkaian pertanyaan berikutnya memungkinkan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.
- Masalah apakah yang akan diselesaikan oleh pemecahan ini?
- Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana pemecahan tersebut akan digunakan
Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:
- Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
- Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
- Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
- Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
- Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
- Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku, yaitu:
- Model Fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output.
4. Prototyping perangkat lunak
a. Prototyping Perangkat
Analisis harus dilakukan tanpa mengabaikan paradigma rekayasa perangkat lunak yang di aplikasikan; tetapi bentuk yang diambil oleh analisis akan bermacam- macam. Dalam banyak kasus sangat mungkin untuk mengaplikasikan prinsip operasional dan menarik sebuah model perangkat lunak yang melaluinya sebuah desain dapat dikembangkan, pengaplikasian prinsip analisis dan penyusunan model perangkat lunak yang akan dibangun yang disebut prototype untuk penilaian pelanggan danpengembang.
b. Pemilihan prototyping
Paradigma prototyping terbatas dan tidak terbatas. Pendekatan terbatas sering disebut : throw away prototyping. Dengan menggunakn pendekatan tersebut, prototyping sebagai sebuah demonstrasi kasar dari sebuah persyaratan.Kemudian prototype dikesampingkan dan perangkat lunak direkayasa dengan menggunakan suatu paradigma yang berbeda.Pendekatan tidak terabatas sering disebut evolusionary prototyping,menggunakan prototyping sebagai bagian utama dari aktivitas analisis yang akan diteruskan ke dalam desain dan konstruksi.
c. Metode dan Peranti Prototyping
Agar prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dengan dapat menilai hasil dan perubahan yang di rekomendasikan. Untuk melakukan prototyping dengan tepat ad tiga kelas metode dan peranti generik, teknik generasi keempat komponen perangkat lunak reusable, spesifikasi normal,dan lingkungan prototyping.
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.
1. 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.
• Menggambarkan apa yang dibutuhkan untuk pelanggan
• Membangun dasar bagi pembuatan desain perangkat lunak
• Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.
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
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
2. 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)
a. 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.
b. 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.
c. 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.
3. 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
Bagaimana membuat : Decisions dan Interactive Control
- Decisions dalan DFD
- Perulangan dalam DFD
Penyimpanan Data
- Data store tidak boleh membuat “elemen data” baru
- Proses juga tidak dapat membuat data baru ; hanya mengambil data dan mengeluarkannya ke dalam sebuah bentuk data baru
Beberapa petunjuk dalam pemakaian nama ( penamaan )
a. Penamaan “Proses”
Nama proses harus frase tunggal dan dapat mendeskripsikan suatu proses dalam sebuah kalimat
Nama proses harus mendefinisikan kegiatan / aksi yang spesifik
Nama proses harus mendefinisikan kegiatan / aksi yang spesifik
Jika suatu proses menangani beberapa proses, maka harus dipecah menjadi beberapa proses
b. Penamaan Data Store
Gunakan nama yang khas / spesifik
Ingat bahwa setiap data store hanya berisi satu set struktur data
Contoh
Machine_Schedules and Parts_Used
pisahkan ke dalam 2 data store
c. Penamaan Data Flows antara Proses
Gunakan 1 kata / frase. Contoh : “Kuitansi” , “Cek” , dan sebagainya
Jangan menggunakan nama yang sama untuk setiap data flow
4. Mekanik dari analisis terstruktur
– bangun ERD
– bangun DFD + Data Dictionary + P-SPEC
– (bangun CFD)
– bangun STD + C-SPEC
5. Kamus Data (Data Dictionary)
• Menyimpan semua objek data yang
dibutuhkan dan dihasilkan oleh PL
– objek data yang muncul pada:
•ERD
•DFD
•STD
– harus selengkap dan serinci mungkin
• contoh: Nama = nama_depan + nama_belakang
• Berisi:
–Name
• nama utama yang muncul pada objek data, data store atau eksternal entity
– Alias
• nama lain yang digunakan
– Where-used/how-used
• daftar proses yang menggunakan data dan bagaimana menggunakannya.
– Content description
• notasi untuk merepresentasikan isi data
– Supplementary information
•Notasi:
Jenis Notasi Arti
======================================
= Terdiri atas
urutan + dan
pilihan [ | ] atau
pengulangan { } Pengulangan sebanyak n kali
( ) Data optional
* * pembatas komentar
• Contoh:
– nama mahasiswa = nama depan + nama
belakang
– jenis kelamin = [perempuan | laki-laki]
– nomor telepon = (kode negara) + kode wilayah
+ nomor
– bangun DFD + Data Dictionary + P-SPEC
– (bangun CFD)
– bangun STD + C-SPEC
5. Kamus Data (Data Dictionary)
• Menyimpan semua objek data yang
dibutuhkan dan dihasilkan oleh PL
– objek data yang muncul pada:
•ERD
•DFD
•STD
– harus selengkap dan serinci mungkin
• contoh: Nama = nama_depan + nama_belakang
• Berisi:
–Name
• nama utama yang muncul pada objek data, data store atau eksternal entity
– Alias
• nama lain yang digunakan
– Where-used/how-used
• daftar proses yang menggunakan data dan bagaimana menggunakannya.
– Content description
• notasi untuk merepresentasikan isi data
– Supplementary information
•Notasi:
Jenis Notasi Arti
======================================
= Terdiri atas
urutan + dan
pilihan [ | ] atau
pengulangan { } Pengulangan sebanyak n kali
( ) Data optional
* * pembatas komentar
• Contoh:
– nama mahasiswa = nama depan + nama
belakang
– jenis kelamin = [perempuan | laki-laki]
– nomor telepon = (kode negara) + kode wilayah
+ nomor
6. Overview mengenai metode analisis
Berikut sekilas mengenai Overview 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.
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..”
JSD memiliki enam langkah pengembangan sistem, yaitu:
1. Entity Action Step
2. Entity Struture Step.
3. Initial Model Step.
4. Function Step.
5. System Timing Step.
6. Implementation Step
-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.
Terdapat dua jenis diagram yang dipakai dalam paket SADT, yaitu:
1. Diagram kegiatan (yang dinamakan aktigram)
2. Diagram dflta (yang dinamakan datagram)
Tidak ada komentar:
Posting Komentar