�ݺ�ߣ

Metodologi Desain
Perangkat Lunak
~ ~ Meet 05 ~ ~
Program Studi Informatika
Universitas Teknologi Yogyakarta
Donny Avianto, S.T., M.T.

Konsep Desain
– Desain perangkat lunak berada di inti teknis rekayasa perangkat lunak dan
diterapkan terlepas dari model proses perangkat lunak yang digunakan.
– Dimulai setelah kebutuhan perangkat lunak dianalisis , desain perangkat
lunak adalah tindakan rekayasa perangkat lunak terakhir dalam aktivitas
pemodelan dan menetapkan tahapan untuk konstruksi (pembuatan kode
dan pengujian).
– Tahap desain menghasilkan desain data/kelas, desain arsitektur, desain
antarmuka, dan desain komponen.

Konsep Desain
– Desain data/kelas mengubah model kelas menjadi realisasi kelas desain dan
struktur data yang diperlukan untuk mengimplementasikan perangkat lunak.
– Objek dan hubungan yang didefinisikan digambarkan oleh atribut kelas dan notasi
lainnya memberikan dasar untuk aktivitas desain data.
– Desain arsitektur mendefinisikan hubungan antara elemen struktural utama
dari perangkat lunak, gaya arsitektur, dan pola yang dapat digunakan untuk
mencapai kebutuhan system.
– Desain antarmuka menggambarkan bagaimana perangkat lunak
berkomunikasi dengan sistem yang beroperasi dengannya, dan dengan
manusia yang menggunakannya. Antarmuka menyiratkan aliran informasi
(misalnya, data dan/atau kontrol) dan jenis perilaku tertentu.

Konsep Desain
– Desain komponen mengubah elemen struktural arsitektur perangkat lunak
menjadi deskripsi prosedural komponen perangkat lunak.

Importance of software design
– Pentingnya desain perangkat lunak dapat dinyatakan dengan satu kata yaitu
kualitas.
– Desain adalah tempat di mana kualitas dipupuk dalam rekayasa perangkat lunak.
– Desain adalah satu-satunya cara Anda dapat secara akurat menerjemahkan
kebutuhan stakeholder ke dalam produk atau sistem perangkat lunak .
– Desain perangkat lunak berfungsi sebagai dasar untuk semua rekayasa perangkat
lunak dan aktivitas pendukung perangkat lunak yang mengikutinya.
– Tanpa desain, Anda berisiko membangun sistem yang tidak stabil—sistem yang
akan gagal jika dilakukan perubahan kecil; sitem yang mungkin sulit untuk diuji;
sistem yang kualitasnya tidak dapat dinilai sampai akhir dalam proses perangkat
lunak.

– Metode untuk menghasilkan desain PL sangat beragam.
– Ada yang driven by data, memungkinkan struktur data untuk mendikte
arsitektur program dan komponen pemrosesan yang dihasilkan.
– Ada yang dibentuk oleh pola tertentu, menggunakan informasi tentang
domain masalah (model persyaratan) untuk mengembangkan gaya
arsitektur dan pola pemrosesan.
– Ada yang berorientasi objek, menggunakan objek domain masalah sebagai
penggerak untuk pembuatan struktur data dan metode yang
memanipulasinya.
– Namun semua menganut seperangkat prinsip desain yang dapat diterapkan,
terlepas dari metode yang digunakan

– Prinsip 1. Desain harus dapat dilacak ke kebutuhan PL. Kebutuhan PL
menjelaskan domain informasi masalah, fungsi yang terlihat pengguna,
perilaku sistem, dan satu set kelas yang dibutuhkan
– Prinsip 2. Selalu pertimbangkan arsitektur sistem yang akan dibangun.
Arsitektur perangkat lunak adalah kerangka dari sistem yang akan dibangun.
Ini mempengaruhi antarmuka, struktur data, aliran dan perilaku control
program, cara pengujian dapat dilakukan, pemeliharaan sistem yang
dihasilkan, dan banyak lagi.
– Prinsip 3. Desain data sama pentingnya dengan desain fungsi pemrosesan.
Desain data yang terstruktur dengan baik membantu menyederhanakan
aliran program, membuat desain dan implementasi komponen perangkat
lunak lebih mudah, dan membuat pemrosesan keseluruhan lebih efisien

– Prinsip 4. Antarmuka harus dirancang dengan hati-hati. Antarmuka yang
dirancang dengan baik membuat integrasi lebih mudah dan membantu
penguji dalam memvalidasi fungsi komponen.
– Prinsip 5. Desain antarmuka pengguna harus disesuaikan dengan kebutuhan
pengguna akhir. Namun, dalam setiap kasus, itu harus menekankan
kemudahan penggunaan. Antarmuka pengguna adalah manifestasi yang
terlihat dari perangkat lunak. Tidak peduli seberapa canggih fungsi
internalnya, tidak peduli seberapa komprehensif struktur datanya, tidak
peduli seberapa baik arsitekturnya, desain antarmuka yang buruk sering
mengarah pada persepsi bahwa perangkat lunak itu "buruk".

– Prinsip 6. Desain tingkat komponen harus independen secara fungsional.
Fungsionalitas yang diberikan oleh komponen harus kohesif—yaitu, harus
fokus pada satu dan hanya satu fungsi.
– Prinsip 7. Komponen harus digabungkan secara loosely coupled satu sama
lain dan dengan lingkungan eksternal. Penggabungan dicapai dengan banyak
cara—melalui antarmuka komponen, melalui pesan, dan melalui data global.
Seiring dengan peningkatan level coupling, kemungkinan propagasi error
juga meningkat dan kemampuan pemeliharaan perangkat lunak secara
keseluruhan menurun. Oleh karena itu, kopling komponen harus dijaga
serendah mungkin

– Prinsip 8. Representasi desain harus mudah dimengerti. Tujuan desain adalah
untuk mengkomunikasikan informasi kepada :
– Tim yang akan menghasilkan kode,
– Tim yang akan menguji perangkat lunak, dan
– Orang lain yang mungkin memelihara perangkat lunak di masa depan.
Jika desain sulit dipahami, tidak akan berfungsi sebagai media komunikasi yang
efektif.
– Prinsip 9. Desain harus dikembangkan secara iteratif. Dengan setiap iterasi,
desainer harus berusaha untuk kesederhanaan yang lebih besar. Seperti hampir
semua aktivitas kreatif, desain terjadi secara berulang. Iterasi pertama bekerja
untuk memperbaiki desain dan memperbaiki kesalahan, tetapi iterasi selanjutnya
harus berusaha untuk membuat desain sesederhana mungkin.

– Prinsip 10. Penciptaan model desain tidak menutup kemungkinan untuk
penedekatan agile. Beberapa pendekatan agile bersikeras bahwa kode
adalah satu-satunya dokumentasi desain yang diperlukan. Namun tujuan dari
model desain adalah untuk membantu orang lain yang harus memelihara dan
mengembangkan sistem. Sangat sulit untuk memahami tujuan tingkat yang
lebih tinggi dari sebuah fragmen kode atau interaksinya dengan modul lain
dalam lingkungan run-time multithreaded modern.

Main program/subprogram
architecture

DFD
– Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan
tim pengembang untuk menggambarkan sistem sebagai suatu jaringan
proses fungsional yang dihubungkan satu sama lain dengan alur data, baik
secara manual maupun komputerisasi.
– DFD ini sering disebut juga dengan nama Bubble chart, Bubble diagram,
model proses, diagram alur kerja, diagram alir data, atau model fungsi.

Entitas Eksternal
– Entitas eksternal mewakili entitas yang berkomunikasi dengan sistem yang
sedang dikembangkan.
– Terdapat dua jenis Entitas eksternal :
1. Terminator Sumber (source) : merupakan terminator yang menjadi sumber.
2. Terminator Tujuan (sink) : merupakan terminator yang menjadi tujuan data

Entitas Eksternal
– Entitas dapat berupa orang, sekelompok orang, organisasi, departemen di
dalam organisasi, atau perusahaan yang sama tetapi di luar kendali sistem
yang sedang dibuat modelnya.
– Entitas dapat juga berupa departemen, divisi atau sistem di luar sistem yang
berkomunikasi dengan sistem yang sedang dikembangkan.

Entitas Eksternal
– Ada tiga hal penting yang harus diingat tentang entitas eksternal :
1. entitas eksternal merupakan bagian/lingkungan luar sistem. Alur data yang
menghubungkan entitas eksternal dengan berbagai proses sistem,
menunjukkan hubungan sistem dengan dunia luar.
2. Tim pembuat sistem tidak dapat mengubah isi atau cara kerja organisasi,
atau prosedur yang berkaitan dengan entitas eksternal.
3. Hubungan yang ada antar entitas eksternal yang satu dengan yang lain
tidak digambarkan pada DFD.

Proses
– Komponen proses menggambarkan bagian dari sistem yang
mentransformasikan input menjadi output
– Proses diberi nama untuk menjelaskan proses/kegiatan apa yang
sedang/akan dilaksanakan.
– Pemberian nama proses dilakukan dengan menggunakan kata kerja transitif
(kata kerja yang membutuhkan obyek), seperti Menghitung Gaji, Mencetak
KRS, Menghitung Jumlah SKS

Proses
– Ada 3 hal yang perlu diperhatikan tentang proses :
1. Proses harus memiliki input dan output.
2. Proses dapat dihubungkan dengan komponen entitas eksternal, data store
atau proses lain melalui alur data.
3. Sistem/bagian/divisi/departemen yang sedang dianalisis oleh tim
pengembang sistem digambarkan dengan komponen proses.

Proses
– Berikut ini merupakan suatu contoh proses yang salah :
– Contoh proses
– Umumnya kesalahan proses di DFD adalah :
1. Proses mempunyai input tetapi tidak menghasilkan output. Kesalahan ini disebut dengan black
hole (lubang hitam), karena data masuk ke dalam proses dan lenyap tidak berbekas seperti
dimasukkan ke dalam lubang hitam (lihat proses 1).
2. Proses menghasilkan output tetapi tidak pernah menerima input.Kesalahan ini disebut dengan
miracle (ajaib), karena ajaib dihasilkan output tanpa pernah menerima input (lihat proses 2).

Data Store
– Komponen ini digunakan untuk membuat model sekumpulan paket data dan
diberi nama dengan kata benda jamak, misalnya Mahasiswa

Data Store
– Suatu data store dihubungkan dengan alur data hanya pada komponen
proses, tidak dengan komponen DFD lainnya. Alur data yang
menghubungkan data store dengan suatu proses mempunyai pengertian
sebagai berikut :
1. Alur data dari data store yang berarti sebagai pembacaan atau
pengaksesan satu paket tunggal data, lebih dari satu paket data, sebagian
dari satu paket tunggal data, atau sebagian dari lebih dari satu paket data
untuk suatu proses
2. Alur data ke data store yang berarti sebagai pengupdatean data, seperti
menambah satu paket data baru atau lebih, menghapus satu paket atau
lebih, atau mengubah/memodifikasi satu paket data atau lebih

Data Flow
– Suatu data flow / alur data digambarkan dengan anak panah, yang
menunjukkan arah menuju ke dan keluar dari suatu proses.
– Alur data ini digunakan untuk menerangkan perpindahan data atau paket
data/informasi dari satu bagian sistem ke bagian lainnya.
– Alur data perlu diberi nama sesuai dengan data/informasi yang dimaksud,
biasanya pemberian nama pada alur data dilakukan dengan menggunakan
kata benda, contohnya Laporan Penjualan

Data Flow
1. Konsep Paket Data (Packets of Data)
– Apabila dua data atau lebih mengalir dari suatu sumber yang sama menuju ke
tujuan yang sama dan mempunyai hubungan, dan harus dianggap sebagai
satu alur data tunggal, karena data itu mengalir bersama-sama sebagai satu
paket.

Data Flow
2. Konsep Alur Data Menyebar (Diverging Data Flow)
– Alur data menyebar menunjukkan sejumlah tembusan paket data yang yang
berasal dari sumber yang sama menuju ke tujuan yang berbeda, atau paket
data yang kompleks dibagi menjadi beberapa elemen data yang dikirim ke
tujuan yang berbeda, atau alur data ini membawa paket data yang memiliki
nilai yang berbeda yang akan dikirim ke tujuan yang berbeda.

Data Flow
3. Konsep Alur Data Mengumpul (Converging Data Flow)
– Beberapa alur data yang berbeda sumber bergabung bersama-sama menuju
ke tujuan yang sama.

Data Flow
4. Konsep Sumber atau Tujuan Alur Data
– Semua alur data harus minimal mengandung satu proses.
– Maksud kalimat ini adalah :
a) Suatu alur data dihasilkan dari suatu proses dan menuju ke suatu data store
dan/atau terminator
b) Sutu alur data dihasilkan dari suatu data store dan/atau terminator dan menuju ke
suatu proses
c) Suatu alur data dihasilkan dari suatu proses dan menuju ke suatu proses.

Membuat Data Flow Diagram
1. Identifikasi terlebih dahulu semua entitas luar yang terlibat di sistem.
2. Identifikasi semua input dan output yang terlibat dengan entitas luar.
3. Buat Diagram Konteks (diagram context)
– Diagram ini adalah diagram level tertinggi dari DFD yang menggambarkan hubungan
sistem dengan lingkungan luarnya.
4. Caranya :
5. Tentukan nama sistemnya.
6. Tentukan batasan sistemnya.
7. Tentukan terminator apa saja yang ada dalam sistem.
8. Tentukan apa yang diterima/diberikan terminator dari/ke sistem.
9. Gambarkan diagram konteks.

1. Identifikasi terlebih dahulu semua entitas luar yang terlibat di sistem.
2. Identifikasi semua input dan output yang terlibat dengan entitas luar.
3. Buat Diagram Konteks (diagram context)
– Diagram ini adalah diagram level tertinggi dari DFD yang menggambarkan hubungan
sistem dengan lingkungan luarnya.
– Caranya :
1. Tentukan nama sistemnya.
2. Tentukan batasan sistemnya.
3. Tentukan terminator apa saja yang ada dalam sistem.
4. Tentukan apa yang diterima/diberikan terminator dari/ke sistem.
5. Gambarkan diagram konteks.

4. Membuat DFD level 1
– Caranya:
– Tentukan proses utama yang ada pada sistem.
– Tentukan apa yang diberikan/diterima masing-masing proses ke/dari sistem sambil
memperhatikan konsep keseimbangan (alur data yang keluar/masuk dari suatu
level harus sama dengan alur data yang masuk/keluar pada level berikutnya).
– Munculkan data store (master) sebagai sumber maupun tujuan alur data.
– Hindari perpotongan arus data
– Beri nomor pada proses utama (nomor tidak menunjukkan urutan proses).

5. Membuat DFD level 2, 3, 4 dst.
– Diagram ini merupakan dekomposisi dari level sebelumnya.
– Proses dekomposisi dilakukan sampai dengan proses siap dituangkan ke dalam
program.
– Aturan yang digunakan sama dengan level satu

meet_05 - MDPL - INF Kls A.pptx

HIPO
(Hierarchy Plus Input-Proses-Output)

HIPO (Hierarchy Plus Input-Proses-Output)
– Merupakan metodologi yang dikembangkan dan didukung oleh IBM.
– Sebenarnya merupakan alat dokumentasi program.
– Sekarang banyak digunakan sebagai alat disain dan teknik dokumentasi
dalam siklus pengembangan sistem.
– Berbasis pada fungsi, yaitu tiap-tiap modul didalam sistem digambarkan oleh
fungsi utamanya.

Sasaran HIPO
– Menyediakan suatu struktur guna memahami fungsi-fungsi dari sistem
– Menekankan fungsi-fungsi yang harus diselesaikan oleh program, bukan
menunjukkan perintah-perintah program yang digunakan untuk
melaksanakan fungsi tersebut
– Menyediakan penjelasan yang cukup dari input yang digunakan dan output
yang dihasilkan oleh masing-masing fungsi
– Menyediakan output yang tepat dan sesuai dengan kebutuhan-kebutuhan
pemakai

Terima Kasih
ada pertanyaan…???

�ݺ�ߣ

meet_05 - MDPL - INF Kls A.pptx

Recommended

More Related Content

Similar to meet_05 - MDPL - INF Kls A.pptx (20)

Recently uploaded (8)

meet_05 - MDPL - INF Kls A.pptx