Materi Konsep dan Prinsip Desain
05.37 |
DESAIN PERANGKAT LUNAK DAN REKAYASA PERANGKAT LUNAK
Desain perangkat lunak berada pada inti dari proses rekayasa perangkat desain dan diaplikasikan tanpa memperhatikan model proses rekayasa untuk digunakan. Begitu persyaratan lunak menjadi yang pertama dari tiga aktifitas teknik – desain, pembuatan kode, dan pengujian – yang diperlukan untuk membangun dan menguji perangkat lunak yang masing-masing menghasilkan perangkat lunak komputer yang tervalidasi.
Masing-masing elemen model analisis memberikan informasi yang diperlukan untuk menciptakan suatu model. Persyaratan perangkat lunak, yang dimanifestasikan oleh data, fungsional, dan model-model perilaku, mengisi langkah desain. Dengan menggunakan satu dari sejumlah metode desain, langkah desain data, desain arsitektur, desain interface, serta desain prosedural.
Desain data mentransformasikan menentukan model domain informasi yang dibuat selama analisis ke dalam struktur data yang akan diperlukan untuk mengimplementasi perangkat lunak.
Desain arsitektur menentukan hubungan diantara elemen-elemen struktur utama dari program.
Desain interface menggambarkan bagaimana perangkat lunak berkomunikasi dalam dirinya sendiri, dengan sistem berinteroperasi dengannya, dan dengan manusia yang menggunakannya.
Desain prosedural mentransformasikan elemen-elemen dari arsitektur program ke dalam suatu deskripsi prosedural dari komponen-komponen perangkat lunak. Informasi yang diperoleh dari PSPEC, CSPEC, dan STD berfungsi sebagai dasar bagi desain prosedural. Selama desain, kita membuat keputusan yang akan mempengaruhi kesuksesan perangkat lunak, dan yang penting, kemudian dimana perangkat lunak dapat dipelihara.
Desain perangkat lunak berada pada inti dari proses rekayasa perangkat desain dan diaplikasikan tanpa memperhatikan model proses rekayasa untuk digunakan. Begitu persyaratan lunak menjadi yang pertama dari tiga aktifitas teknik – desain, pembuatan kode, dan pengujian – yang diperlukan untuk membangun dan menguji perangkat lunak yang masing-masing menghasilkan perangkat lunak komputer yang tervalidasi.
Masing-masing elemen model analisis memberikan informasi yang diperlukan untuk menciptakan suatu model. Persyaratan perangkat lunak, yang dimanifestasikan oleh data, fungsional, dan model-model perilaku, mengisi langkah desain. Dengan menggunakan satu dari sejumlah metode desain, langkah desain data, desain arsitektur, desain interface, serta desain prosedural.
Desain data mentransformasikan menentukan model domain informasi yang dibuat selama analisis ke dalam struktur data yang akan diperlukan untuk mengimplementasi perangkat lunak.
Desain arsitektur menentukan hubungan diantara elemen-elemen struktur utama dari program.
Desain interface menggambarkan bagaimana perangkat lunak berkomunikasi dalam dirinya sendiri, dengan sistem berinteroperasi dengannya, dan dengan manusia yang menggunakannya.
Desain prosedural mentransformasikan elemen-elemen dari arsitektur program ke dalam suatu deskripsi prosedural dari komponen-komponen perangkat lunak. Informasi yang diperoleh dari PSPEC, CSPEC, dan STD berfungsi sebagai dasar bagi desain prosedural. Selama desain, kita membuat keputusan yang akan mempengaruhi kesuksesan perangkat lunak, dan yang penting, kemudian dimana perangkat lunak dapat dipelihara.
Desaign Perangkat Lunak
Desain suatu
perangkat lunak merupakan proses beberapa tahap yang difokuskan pada 4 atribut
yang berbeda dari sebuah program yaitu: Struktur Data, Arsitektur software,
Tampilan antarmuka, Algoritma (prosedur). Desain ini didokumentasikan dan
menjadi bagian dari konfigurasi perangkat lunak
· Desain Antar Muka
Desain antarmuka harus dibuat yang menarik, interaktif, mudah dipelajari, mudah digunakan dan mudah dipahami. Beberapa faktor yang perlu diperhatikan dalam desain antarmuka, yaitu :
a. Ruang gerak mata
b. Sarana komunikasi
c. Mudah digunakan
d. Ergonomic (kenyamana & keamanan), yang meliputi : Penentuan ukuran, jenis, warn & format font, Pemilihan warna, Menyajikan objek yang tipis / kecil dengan pilihan warna, Ruang gerak mata
e. Cognitive Psychology, yang meliputi : Jumlah warna, Simbol standart & tata letak, Penggunaan kata yang tidak berkonotasi ganda. Mis. Masukkan nama anda, bisa dispesifikasikan menjadi masukkan nama user dll
f. Aneka ragam dialog, yang meliputi : Model menu datar, check box dll
· Permasalahan yang ada pada desain perangkat lunak :
a. Waktu respon sistem, diukur mulai saat user melakukan beberapa aksi kontrol sampai dengan perangkat lunak merespon dengan menampilkan output / aksi yang diperlukan.
b. Fasilitas help untuk pemakai. Ada 2 jenis fasilitas help yaitu :
§ Help integrated, fasilitas help yang dimasukkan ke dalam perangkat lunak, yang memungkinkan user untuk memilih topik yang sesuai dengan kegiatan yang dilakukan.
§ Help Add-On, fasilitas help yang ditambahkan setelah aplikasi perangkat lunak selesai dikembangkan yang dapat berupa manual user-line dengan kemampuan query yang terbatas.
Beberapa hal yang perlu dipertimbangkan dalam membuat desain help :
· Apakah help dapat diperoleh untuk semua fungsi sistem dan keseluruhan waktu selama interaksi sistem ?
· Bagaimana user mengakses help? Pilihan meliputi : menu help, kunci fungsi khusu, perintah help
· Bagaimana help diprepresentasikan? Pilihan meliputi : sebuah jendela terpisah, refensi untuk dokumen yang tercetak serta satu atau dua baris usulan yang dibuat pada suatu lokasi layer yang tetap
· Bagaimana pemakai kembali ke interaksi normal?pilihan mencakup tombol return yang ditampilkan pada layer dan kunci fungsi atau urutan control
· Bagaimana informasi help distruktur? Pilihan mencakup struktur “datar” di mana semua informasi diakses melalui suatu kata kunci, hirarki informasi bertingkat, kegunaan hiperteks.
c. Penanganan informasi kesalahan
Sering kali pesan kesalahan tidak memberikan indikasi nyata mengenai apa yang salah atau dimana dapat memperoleh informasi tambahan. Karakteristik peringatan kesalahan adalah :
· Pesan harus menggambarkan masalah dalam istilah yang dapat dipahami oleh pemakai
· Pesan harus memberikan nasihat instruktif untuk membetulkan kesalahan
· Pesan harus mengindikasikan konsekuensi negatif dari kesalahan, cont. File data yang secara potensial dikorup) sehingga pemakai dapat mengecek untuk memastikan bahwa hal tersebut tidak terjadi (atau membetulkan bila memang terjadi)
· Pesan harus disertai oleh sebuah isyarat visual atau bunyi untuk mengiringi tampilan pesan
· Pesan tersebut harus tidak ”menghakimi” yaitu penyusunan kata tidak boleh menyalahkan pemakai.
d. Pelabelan perintah
Perintah yang diketik merupakan mode yang umum dari interaksi antara pemakai dan perangkat lunak sistem dan biasa dipakai untuk aplikasi setiap tipe. Dalam banyak keadaan, user dapat memilih fungsi-fungsi yang disediakan. Beberapa hal yang perlu diperhatikan dalam mendesain perintah :
· Apakah setiap pilihan menu memiliki perintah yang sesuai?Bagaimana pentuk yang akan diambil oleh perintah? Pilihan meliputi : urutan kontrol (mis. ^P), tombol fungsi, kata yang diketikkan
Definisi yang lain oleh H.D. Mills adalah pemrograman terstuktur tidak harus dicirikan secara panjang lebar dengan absennya go to,melainkan timbulnya terstruktur.
Sedangkan definisi yang lebih akurat lagi dinyatakan oleh N. Wirth bahwa pemrograman terstuktur adalah formulasi program secara hierarkis,struktur berkelompok dari pernyataan-pernyataan dan objek-objek komputasi. Pernyataan Wirth sendiri bukanlah mendefininisikan perangkat atau konstruksi kontrol logika yang dapat digunakan, atau tidak membatasi teknik formulasi terstuktur yang tersedia untuk desain program.
Prinsip utama dari pemrograman yang terstuktur adalah bahwa jika urutan suatu proses telah sampai pada suatu baris sintaks tertentu, maka proses selanjutnya tidak boleh melompat mundur kebaris sebelumnya, kecuali untuk proses dengan struktur kontrol repetition/looping. Modifikasi akan sulit dilakukan terhadap suatu program, jika kode programnnya yang dibuat tidak terstruktur dengan baik. Biasanya para pemrogram (programmer) akan merasa sangat perlu untuk memahami metodologi perancangan program yang terstruktur, jika mereka sedang membuat program yang besar dan komplek.
Pemrograman terstruktur dipandang oleh banyak pemrogram sebagai sinonim untuk pemrogramman modular atau top-down. Sebenarnya pemrograman modular adalah suatu sub kelas dari metodologi perancangan dalam suatu kelas umum dari metodologi penyederhanaan persoalan yang diketahui sebagai pemrograman terstruktur.
Pemrograman terstuktur dapat divisualisasikan sebagai aplikasi dan metode penyederhananaan persoalan dasar untuk menyusun terstruktur persoalan hierarki yang bisa dikelola.Untuk memperolah suatu pengetahuan yang lebih besar dari perbedaan antara sub kelas berbagai metodologi yang terkandung dalam pemrograman terstruktur, pertama kita harus memandang tujuan dari proses kemurnian. Kita diberikan suatu persoalan, biasanya kita menspesifikasi kedalam bahasa kita, dan mensyaratkan untuk menunjukan suatu penyelesaian persoalan tersebut ke dalam suatu bahasa pemrograman tingkat tinggi.
Bila persoalan tidak lebih dari”menghitung jumlah dari A dan B”, persoalan ini akan langsung diterjemahkan kedalam RESULT = A+B. Jika persoalan besar atau rumit, maka sistem yang didefinisikan untuk menyelesaikan persoalan tersebut haruslah disederhanakan menjadi sub sistem dimana setelah sejumlah penyederhanaan, secara hierarkis menjadi modul-modul. Setelah penyederhanaan tambahan, hasilnya merupakan suatu program yang terstruktur. Masing-masing sub kelas metodologi dapat digambarkan dengan:
Program yang baik/terstuktur mempunyai ciri-ciri sebagai berikut :
· Desain Antar Muka
Desain antarmuka harus dibuat yang menarik, interaktif, mudah dipelajari, mudah digunakan dan mudah dipahami. Beberapa faktor yang perlu diperhatikan dalam desain antarmuka, yaitu :
a. Ruang gerak mata
b. Sarana komunikasi
c. Mudah digunakan
d. Ergonomic (kenyamana & keamanan), yang meliputi : Penentuan ukuran, jenis, warn & format font, Pemilihan warna, Menyajikan objek yang tipis / kecil dengan pilihan warna, Ruang gerak mata
e. Cognitive Psychology, yang meliputi : Jumlah warna, Simbol standart & tata letak, Penggunaan kata yang tidak berkonotasi ganda. Mis. Masukkan nama anda, bisa dispesifikasikan menjadi masukkan nama user dll
f. Aneka ragam dialog, yang meliputi : Model menu datar, check box dll
· Permasalahan yang ada pada desain perangkat lunak :
a. Waktu respon sistem, diukur mulai saat user melakukan beberapa aksi kontrol sampai dengan perangkat lunak merespon dengan menampilkan output / aksi yang diperlukan.
b. Fasilitas help untuk pemakai. Ada 2 jenis fasilitas help yaitu :
§ Help integrated, fasilitas help yang dimasukkan ke dalam perangkat lunak, yang memungkinkan user untuk memilih topik yang sesuai dengan kegiatan yang dilakukan.
§ Help Add-On, fasilitas help yang ditambahkan setelah aplikasi perangkat lunak selesai dikembangkan yang dapat berupa manual user-line dengan kemampuan query yang terbatas.
Beberapa hal yang perlu dipertimbangkan dalam membuat desain help :
· Apakah help dapat diperoleh untuk semua fungsi sistem dan keseluruhan waktu selama interaksi sistem ?
· Bagaimana user mengakses help? Pilihan meliputi : menu help, kunci fungsi khusu, perintah help
· Bagaimana help diprepresentasikan? Pilihan meliputi : sebuah jendela terpisah, refensi untuk dokumen yang tercetak serta satu atau dua baris usulan yang dibuat pada suatu lokasi layer yang tetap
· Bagaimana pemakai kembali ke interaksi normal?pilihan mencakup tombol return yang ditampilkan pada layer dan kunci fungsi atau urutan control
· Bagaimana informasi help distruktur? Pilihan mencakup struktur “datar” di mana semua informasi diakses melalui suatu kata kunci, hirarki informasi bertingkat, kegunaan hiperteks.
c. Penanganan informasi kesalahan
Sering kali pesan kesalahan tidak memberikan indikasi nyata mengenai apa yang salah atau dimana dapat memperoleh informasi tambahan. Karakteristik peringatan kesalahan adalah :
· Pesan harus menggambarkan masalah dalam istilah yang dapat dipahami oleh pemakai
· Pesan harus memberikan nasihat instruktif untuk membetulkan kesalahan
· Pesan harus mengindikasikan konsekuensi negatif dari kesalahan, cont. File data yang secara potensial dikorup) sehingga pemakai dapat mengecek untuk memastikan bahwa hal tersebut tidak terjadi (atau membetulkan bila memang terjadi)
· Pesan harus disertai oleh sebuah isyarat visual atau bunyi untuk mengiringi tampilan pesan
· Pesan tersebut harus tidak ”menghakimi” yaitu penyusunan kata tidak boleh menyalahkan pemakai.
d. Pelabelan perintah
Perintah yang diketik merupakan mode yang umum dari interaksi antara pemakai dan perangkat lunak sistem dan biasa dipakai untuk aplikasi setiap tipe. Dalam banyak keadaan, user dapat memilih fungsi-fungsi yang disediakan. Beberapa hal yang perlu diperhatikan dalam mendesain perintah :
· Apakah setiap pilihan menu memiliki perintah yang sesuai?Bagaimana pentuk yang akan diambil oleh perintah? Pilihan meliputi : urutan kontrol (mis. ^P), tombol fungsi, kata yang diketikkan
Desaign Rekayasa perangkat Lunak
Desain prosedural terjadi setelah data,
desain arsitektur, dan interface, dibangun.Dalam dunia yang ideal,
spesifikasi prosedural diperlukan untuk menetapkan detail algoritma yang
akan dinyatakan dalam suatu bahasa ibu seperti bahasa inggris. Akan
tetapi, semua anggota organisasi pengembangan perangkat lunak
menggunakan bahasa ibu (paling tidak secara teori), orang di luar domain
perangkat lunak dapat lebih memahami spesifikasi tersebut dan tidak ada
pelajaran baru yang Sayangnya ada satu masalah kecil, desain prosedural
harus menentukan detail desain prosedural tanpa ada ambiguitas, dan
tidak ada ambiguitas. Di dalam bahasa ibu bukan merupakan hal hal wajar.
Dengan menggunakan suatu bahasa ibu, kita dapat menuliskan serangkaian
langkah prosedural dalam begitu banyak cara yang berbeda. Kita kerap
kali bersandar pada konteks untuk mendapatkan fakta penting. Kita sering
menulis seolah-olah ada dialog dengan pembaca (sebenarnya tidak).
Karena alasan tersebut dan hal lainnya, harus digunakan mode yang lebih
terbatas untuk mempresentasikan detail prosedural.
PEMROGRAMAN TERSTUKTUR REKAYASA PERANGKAT LUNAK
Definisi – definisi mendasar dari pemrograman yang terstruktur adalah sebagai berikut :- Teori pemrograman terstruktur memperlakukan pengkorversian diagram alir besar dan kompleks ke dalam bentuk standar sedemikian rupa sehingga mereka dapat dipresentasikan dengan iterasi dan nesting (pengumpulan) sejumlah kecil struktur logika kontrol dasar dan standar (H.D. Mills, Chief Programmer Teams:Principle and Procedures).
- Pemrograman terstruktur adalah cara pengorganisasian dan pengkodean program-program yang kompleks dan membuat program tersebut lebih mudah dipahami dan dimodifikasi (J.R.Donaldson,Struktured programming
- Konsep dasar [dari pemrograman terstuktur] adalah suatu pembuktian kebenaran, (R.A.Karp)
- Pemrograman terstuktur bukanlah obat mujarab-ia benar-benar terdiri dari suatu atribut yang biasanya tidak inherent (menjadi sifat) dalam pemrograman atau sebarang jenis yang lain (D.Butterworrth)
Definisi yang lain oleh H.D. Mills adalah pemrograman terstuktur tidak harus dicirikan secara panjang lebar dengan absennya go to,melainkan timbulnya terstruktur.
Sedangkan definisi yang lebih akurat lagi dinyatakan oleh N. Wirth bahwa pemrograman terstuktur adalah formulasi program secara hierarkis,struktur berkelompok dari pernyataan-pernyataan dan objek-objek komputasi. Pernyataan Wirth sendiri bukanlah mendefininisikan perangkat atau konstruksi kontrol logika yang dapat digunakan, atau tidak membatasi teknik formulasi terstuktur yang tersedia untuk desain program.
Prinsip utama dari pemrograman yang terstuktur adalah bahwa jika urutan suatu proses telah sampai pada suatu baris sintaks tertentu, maka proses selanjutnya tidak boleh melompat mundur kebaris sebelumnya, kecuali untuk proses dengan struktur kontrol repetition/looping. Modifikasi akan sulit dilakukan terhadap suatu program, jika kode programnnya yang dibuat tidak terstruktur dengan baik. Biasanya para pemrogram (programmer) akan merasa sangat perlu untuk memahami metodologi perancangan program yang terstruktur, jika mereka sedang membuat program yang besar dan komplek.
Pemrograman terstruktur dipandang oleh banyak pemrogram sebagai sinonim untuk pemrogramman modular atau top-down. Sebenarnya pemrograman modular adalah suatu sub kelas dari metodologi perancangan dalam suatu kelas umum dari metodologi penyederhanaan persoalan yang diketahui sebagai pemrograman terstruktur.
Pemrograman terstuktur dapat divisualisasikan sebagai aplikasi dan metode penyederhananaan persoalan dasar untuk menyusun terstruktur persoalan hierarki yang bisa dikelola.Untuk memperolah suatu pengetahuan yang lebih besar dari perbedaan antara sub kelas berbagai metodologi yang terkandung dalam pemrograman terstruktur, pertama kita harus memandang tujuan dari proses kemurnian. Kita diberikan suatu persoalan, biasanya kita menspesifikasi kedalam bahasa kita, dan mensyaratkan untuk menunjukan suatu penyelesaian persoalan tersebut ke dalam suatu bahasa pemrograman tingkat tinggi.
Bila persoalan tidak lebih dari”menghitung jumlah dari A dan B”, persoalan ini akan langsung diterjemahkan kedalam RESULT = A+B. Jika persoalan besar atau rumit, maka sistem yang didefinisikan untuk menyelesaikan persoalan tersebut haruslah disederhanakan menjadi sub sistem dimana setelah sejumlah penyederhanaan, secara hierarkis menjadi modul-modul. Setelah penyederhanaan tambahan, hasilnya merupakan suatu program yang terstruktur. Masing-masing sub kelas metodologi dapat digambarkan dengan:
- Jangkauan proses keaslian yang padanya metodologi menjadi efektif.
- Pendekatannya ke proses keaslian.
- Aplikasi yang berguna
Program yang baik/terstuktur mempunyai ciri-ciri sebagai berikut :
- Dapat dijalankan dengan baik dan benar (sesuai dengan keinginan pemrogram).
- Dapat dijalankan secara efisien dan efektif dengan tidak banyak menggunakan sintaks yang tidak perlu (menghasilkan output yamg tepat dan benar dalam waktu yang singkat).
- Mudah dibaca dan dipahami oleh orang lain maksud dan tujuan objek yang akan ditampilkan (memiliki logika perhitungan yang tepat dalam memecahkan masalah, dan ditulis dalam bahasa yang standar yaitu bahasa Indonesia/Inggris terstuktur,sehingga tidak menimbulkan arti ganda). Mudah diperbaiki, jika terjadi kesalahan (semua operasi yang dilakukan harus terdefinisi dengan jelas dan berakhir setelah sejumlah langkah dilakukan).
- Biaya perawatan dan dokumentasi yang dibuthkan rendah
- Program hanya terdiri dari tiga struktur kontrol, yaitu stuktur urut,stuktur seleksi, dan struktur repetisi/iterasi
Biaya pengujian yang dibutuhkan rendah
Memiliki dokumentasi yang baik
LANGKAH-LANGKAH PENGEMBANGAN PROGRAM
Suatu
program yang baik membutuhkan suatu standar, sehingga akan memudahkan
pemrogram untuk merancang, dan merawat program. Sehingga perlu dipahami
beberapa langkah yang harus dilakukan dalam merancang suatu program yang
terstruktur. Langkah –langkah tersebut adalah sebagai berikut:
1. Definisikan Masalah
Pemahaman
permasalahan merupakan suatu hal yang sangat penting bagi sipemrogram.
Sipemrogram perlu memahami permasalahan yang dihadapi dan yang akan
diselesaikan oleh pemesan program, agar hasil pendefinisian masalah
tidak menyimpang dari masalah yang sedang dihadapi.
Setelah
menyamakan persepsi tentang suatu masalah yang dihadapi dan akan
diselesaikan, maka pemrogram dapat mengidentifikasi permasalahan
tersebut secara rinci, dan menentukan ruang lingkup permasalahan yang
akan diselesaikan terlebih dahulu, dan kemungkinan kendala-kendala yang
akan dihadapi, lalu berapa lama proses penyelesaian masalah tersebut.
Pemrograman harus membuat langkah-langkah penyelesaian masalah
berdasarkan ruang lingkup permasalahan yang ditentukan, sehingga
pekerjaan pembuatan program terarah dan terjadwal dengan baik.
Masalah
yang perlu didefinisikan adalah komponen input dari suatu program yang
akan dirancang tersebut apa saja yang akan terjadi didalam menyelesaikan
program tersebut dan menampilkan hasilnya, yang terakhir adalah
komponen output yang diinginkan seperti apa, dan formatnya bagaimana.
2. Merancang Outline Pemecahan Masalah
Dalam
merancang outline pemecahan masalah pemrogram perlu membuat rincian
proses secara rinci (meliputi proses apa saja yang terjadi pada menu
utama, lalu masing-masing sub menu dalam menu utama tesebut akan
mengerjakan berapa proses,setiap proses yang terjadi berinteraksi dengan
file apa saja, dan berapa file yang terlibat dalam proses tersebut).
Setelah
rincian proses dan file yang berinteraksi diketahui, pemrogram
menentukan berapa bentuk stuktur kontrol yang terlibat dalam satu
proses,dan jenis stukturnya apa saja dan berapa banyak, misalkan baris
1-10 menggunakan struktur urut atau seleksi, dan baris 11-20 menggunakan
struktur repetisi repeat-until atau for-do, dst.
Judul
dari setiap proses (modul) apa saja, dan deklarasikan seluruh variable
yang akan digunakan dalam setiap proses (modul), baik variable lokal
maupun variable global. Setelah itu tentukan deskripsi dari proses
(modul) tersebut. Setelah outline selesai, maka transformasikan outline
tersebut kedalam algoritma, dengan menggunakan pseudecode yang dapat
ditulis dengan struktur Indonesia (bahasa Indonesia terstuktur) atau struktur Inggris (bahasa Inggris tersrtuktur).
Desain
algoritma yang dibuat haruslah sama dengan langkah-langkah penyelesaian
masalah yang ditentukan, karena algoritma dibuat untuk menyelesaikan
masalah yang dihadapi oleh pemrogram.
Algoritma
yang telah dibuat tersebut perlu dilakukan pengujian agar output yang
dihasilkan nantinya dapat sesuai dengan keinginan sipemrogram. Disamping
pengujian juga perlu dibuat format input / output yang jelas, serta
komentar untuk setiap baris yang dapat membantu pemrogram dalam
mengingat tujuan dari perintah tersebut.Pengujian algoritma tersebut
dapat dilakukan dengan menggunakan diagram overview dan diagram rinci
HIPO (HIRARKI Plus Input dan Output).
3. Pengkodean Program
Algoritma
yang telah selesai dilakukan pengujian,dapat langsung ditransformasikan
kedalam salah satu bahasa pemrograman yang diinginkan atau yang
dikuasai oleh sipemrogram. Bahasa pemrograman yang baik harusalah dapat
dipakai pada berbagai jenis komputer yang berbeda-beda dan berbaai jenis
sistem informasi, hal ini dikenal dengan portabilitas. Pemrogram juga
haruslah menentukan batas waktu minimum dalam penulisan suatu modul
program, dari awal hingga siap dioperasikan.
Tujuan
pengkodean adalah terjadinya efisiensi terhadap memori yang akan
digunakan, efisiensi perintah dalam setiap modul program,serta efisiesi
terhadap penggunaan fasilitas input dan output yang akan berpengaruh
langsung terhadap porseor ataupun terhadap pengguna.
4. Eksekusi Program
Pekerjaan
komputer (prosesor) pada dasarnya hanya dua yaitu fetch (membaca
instruksi/ program dari memori), lalu execute (mengeksekusi
instruksi/program tesebut) dan menampilkan hasilnya ke media output
seperti printer, monitor dll.Untuk memperoleh eksekusi program dengan
kecepatan maksimum, maka perlu diperhatikan beberapa faktor, seperti
jenis bahasa pemrograman yang dipilih apakah sanggup mengangkat data
yang akan diproses, dan spesifikasi perangkat keras yang digunakan.
5. Dokumentasi Dan Pemeliharaan Program
Penulisan
program yang kompleks harus selalu didokumentasikan setiap kurun waktu
tertentu, jadwal dokumentasi juga perlu dibuat demi menjaga keamanan
terhadap program dan data dari orang-orang yang tidak bertanggung jawab.
Pemeliharaan
program berfungsi untuk menjabarkan aktivitas dari hasil analisis
terhadap sistem dan dilakukan setelah program diimplementasikan dan
telah digunakan beberapa saat oleh pemakai. Pemeliharaan mencangkup:
- Format tampilan yang disesuaikan dengan keinginan pengguna
- Fungsi-fungsi yang tidak sesuai dengan keinginan pengguna
- Adaptasi dengan spesifikasi prosesor yang baru dan ssistem operasi yang baru.
- Dan lain-lain.
KOMPONEN PEMROGRAMAN TERSTUKTUR
Pemrograman terstuktur memiliki tiga komponen utama yaitu :.
1. Pemrograman Top-Down
Teknik
Top-Down didefinisikan sebagai suatu masalah yang kompleks dibagi-bagi
kedalam beberapa kelompok masalah yang lebih kecil. Dari kelompok
masalah yang kecil tersebut dianalisis. Apabila dimungkinkan, maka
masalah tersebut akan dipilah-pilah lagi menjadi sub bagian yang lebih
kecil, dan setelah itu mulai disusun langkah-langkah untuk menyelesaikan
secara detail.
Bila
ada masalah yang kompleks, maka pemecahan masalah dilakukan dengan
menggabungkan prosedur-prosedur yang ada menjadi satu kesatuan program
guna menyelesaikan masalah tersebut, teknik ini dikenal dengan Teknik
Bottom-Up yang sudah mulai ditinggalkan pemrogram karena kurang efektif.
2. Pemrograman Modular
Pada
teknik top-down masalah yang besar dan kompleks dibagi-bagi kedalam
kelompok masalah yang lebih kecil. Kelompok masalah yamg lebih kecil
tersebut dinamakan modul. Satu modul akan mewakili satu rincian proses
detail yang sudah mewakili media penyimpanan dan struktur data yang
jelas.
Teknik
pemrograman terstruktur yang digunakan untuk mengimplemetasikan
langkah-langkah pemecahan masalah pada kelompok masalah yang kecil
tersebut dinamakan teknik pemrograman modular.
Modul
program didefinisikan sebagai sekumpulan instruksi yang memiliki
operasi-operasi dan data yang didefinisikan; memiliki stuktur internal
yang tidak tergantung pada subprogram yang lain, dan merupakan satu
kesatuan yang utuh yang akan dieksekusi secara berulang-ulang.
3. Teorema Struktur / Struktur Kontrol
Perancangan
program terstruktur tidak dipengaruhi oleh kelebihan dan keunggulan
salah satu bahasa pemrograman yang sedang populer pada saat itu, namun
lebih dipengaruhi oleh tiga teorema struktur / struktur kontrol yang
akan digunakan. Karena pada dasarnya algoritma dari program yang telah
terstuktur akan dapat ditransformasikan kedalam bahasa pemrograman dan
jenis sistem informasi apa saja. Terdapat tiga teorema struktur yaitu:
- Struktur Urut
- Struktur Seleksi
- Struktur Repetisi/pengulangan.
============================================================================
1. Desain dan Kualitas Perangkat Lunak
2. Evolusi Desain Perangkat Lunak
Software design dibagi dalam 2 tahap :
1.Preliminary Design, Pada tahap ini difokuskan dengan transformasi dari keperluan/kebutuhan ke dalam data dan arsitektur software
2.Detail Design, Difokuskan pada penghalusan representasi arsitektur yang berisi struktur data detail dan algoritma untuk software.
Agar dihasilkan desain dengan kriteria yang baik, maka suatu desain haruslah :
1.Memperlihatkan organisasi hirarki yang mengontrol elemen-elemen software
2.Berkenaan dengan modul. Software secara logika terbagi dalam elemen-elemen yang membentuk fungsi dan sub fungsi
3.Berisi representasi yang berbeda dan terpisah dari data dan prosedur
4.Membentuk modul (contoh subroutine dan procedure) yang memperlihatkan karakteristik fungsi yang tidak saling bergantung
5.Diturun
PROSES PERANGKAT LUNAK
Serangkaian kegiatan dan hasil yang berhubungan dengannya, yang menuju pada dihasilkannya produk perangkat lunak.
Kegiatan-kegiatan mendasar yg umum bagi semua proses Perangkat Lunak :
1. Spesifikikasi Perangkat Lunak à Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.
2. Pengembangan (Perancangan dan Implementasi) Perangkat Lunak à Perangkat lunak yang memenuhi spesifikasi harus di produksi
3. Validasi Perangkat Lunak à Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak bekerja sesuai dengan apa yang diinginkan oleh pelanggan.
4. Evolusi Perangkat Lunak à Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.
PROSES DESAIN
Desain perangkat lunak adalah suatu proses
interaktif yang melaluinya persyaratan diterjemahkan ke dalam suatu
‘cetak biru’ untuk membangun perangkat lunak. Pada dasarnya cetak biru
menggambarkan suatu pandangan menyeluruh perangkat lunak, yaitu bahwa
desain dapat dihadirkan pada tingkat abstraksi yang tinggi – tingkat
yang dapat secara langsung ditelusuri sampai data spesifik, fungsional,
dan persyaratan behavioral. Pada saat iterasi desain berjalan,
penyaringan berikutnya membawa kepada representasi desain pada tingkat
abstraksi yang jauh lebih rendah. Hal itu tetap dapat ditelusuri pada
persyaratan, tetapi koneksi menjadi lebih halus.1. Desain dan Kualitas Perangkat Lunak
2. Evolusi Desain Perangkat Lunak
Software design dibagi dalam 2 tahap :
1.Preliminary Design, Pada tahap ini difokuskan dengan transformasi dari keperluan/kebutuhan ke dalam data dan arsitektur software
2.Detail Design, Difokuskan pada penghalusan representasi arsitektur yang berisi struktur data detail dan algoritma untuk software.
Agar dihasilkan desain dengan kriteria yang baik, maka suatu desain haruslah :
1.Memperlihatkan organisasi hirarki yang mengontrol elemen-elemen software
2.Berkenaan dengan modul. Software secara logika terbagi dalam elemen-elemen yang membentuk fungsi dan sub fungsi
3.Berisi representasi yang berbeda dan terpisah dari data dan prosedur
4.Membentuk modul (contoh subroutine dan procedure) yang memperlihatkan karakteristik fungsi yang tidak saling bergantung
5.Diturun
PROSES PERANGKAT LUNAK
Serangkaian kegiatan dan hasil yang berhubungan dengannya, yang menuju pada dihasilkannya produk perangkat lunak.
Kegiatan-kegiatan mendasar yg umum bagi semua proses Perangkat Lunak :
1. Spesifikikasi Perangkat Lunak à Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.
2. Pengembangan (Perancangan dan Implementasi) Perangkat Lunak à Perangkat lunak yang memenuhi spesifikasi harus di produksi
3. Validasi Perangkat Lunak à Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak bekerja sesuai dengan apa yang diinginkan oleh pelanggan.
4. Evolusi Perangkat Lunak à Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.
=========================================================================
Banyak pemrogram terus menerus mendesain secara implisit, dengan melakukan desain prosedural pada saat dikodekan. Hal itu sama dengan mengambil desain piramid dan mendirikannya pada titiknya, hasil desain yang sangat tidak stabil. Perubahan yang paling kecil dapat menyebabkan piaramid tersebut (dan program) tumbang.
A. Model air terjun (waterfall) à Biasa juga disebut siklus hidup perangkat lunak. Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.
1. Analisis dan Definisi Persyaratan à Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user sistem.
2. Perancangan sistem dan Perangkat Lunak à Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak. Menentukan arsitektur sistem secara keseluruhan.
3. Implementasi dan pengujian unit à Perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.
4. Integrasi dan Pengujian Sistem à Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, PL dikirim ke User.
5. Operasi dan Pemeliharaan à Biasanya merupakan fase siklus yg paling lama (walaupun tidak seharusnya). Sistem diinstall dan di pakai.
Pemeliharaan mencakup koreksi dan berbagai error yg tdk ditemukan pada tahap2 sebelumnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem.
=========================================================================
I. Ruang Lingkup
A. Sasaran Sistem
B. Persyaratan utama software
C. Batasan-batasan dan pembatasan desain
II. Desain Data
A. Obyek data dan struktur data resultan
B. Struktur file dan database
1. Struktur file eksternal
a.struktur logis
b.deskripsi record logis
c.metode akses
2. data global
3. file dan referensi lintas data
III. Desain Arsitektural
A. Kajian data dan aliran control
B. Struktur program yang diperoleh
IV. Desain Interface
A. Spesifikasi interface manusia-mesin
B. Aturan desain interface manusia-mesin
C. Desain interface eksternal
1. Interface untuk data eksternal
2. Interface untuk sistem atau peralatan eksternal
V. Desain Prosedural
Untuk masing-masing modul :
A. Naratif pemrosesan
B. Deskripsi Interface
C. Deskripsi bahasa (atau lainnya) desain
D. Modul-modul yang digunakan
E. Struktur data internal
F. Keterangan/larangan/pembatasan
VI. Persyaratan Lintas-Referensi
VII. Ketetentuan pengujian
1. Panduan pengujian
2. Strategi integrasi
3. Pertimbangan Khusus
KONSEP DESAIN
- Abstraksi
Abstraksi
memungkinkan desainer menentukan prosedur dan data, dan masih menekan detail
tingkat rendah.
Terdapat 3 macam bentuk abstraksi, yaitu :
a. Abstraksi prosedural.
Merupakan urutan instruksi yang diberi nama yang mempunyai fungsi tertentu dan terbatas.
b. Abstraksi data.
Kumpulan data yang bernama yang menggambarkan obyek data.
c. Abstraksi kontrol.
Mengimplikasikan suatu mekanisme kontrol program tanpa menentukan detail-detail internal
Terdapat 3 macam bentuk abstraksi, yaitu :
a. Abstraksi prosedural.
Merupakan urutan instruksi yang diberi nama yang mempunyai fungsi tertentu dan terbatas.
b. Abstraksi data.
Kumpulan data yang bernama yang menggambarkan obyek data.
c. Abstraksi kontrol.
Mengimplikasikan suatu mekanisme kontrol program tanpa menentukan detail-detail internal
- Penyaringan
Penyaringan
stepwise (dengan serangkaian langkah) adalah strategi desain top-down yang
diusulkan oleh Wiklaus Wirth. Kajian dari konsep tersebut adalah
“Pada setiap langkah (penyaringan), satu atau beberapa instruksi dari program yang diberikan didekomposisi ke dalam instruksi-instruksi yang lebih detail. Dekomposisi berurutan atau penyaringan spesifikasi berhenti bila semua instruksi diekspresikan dalam bentuk bahasa pemrograman atau komputer yang mendasar. Jika tugas-tugas disaring, maka data harus disaring juga, didekomposisi atau distruktur, dan adalah wajar untuk menyaring program dan spesifikasi data secara paralel” . Abstraksi dan penyaringan adalah konsep kompementer. Kedua konsep tersebut membantu desainer dalam menciptakan suatu model desain lengkap jika desain berkembang.
“Pada setiap langkah (penyaringan), satu atau beberapa instruksi dari program yang diberikan didekomposisi ke dalam instruksi-instruksi yang lebih detail. Dekomposisi berurutan atau penyaringan spesifikasi berhenti bila semua instruksi diekspresikan dalam bentuk bahasa pemrograman atau komputer yang mendasar. Jika tugas-tugas disaring, maka data harus disaring juga, didekomposisi atau distruktur, dan adalah wajar untuk menyaring program dan spesifikasi data secara paralel” . Abstraksi dan penyaringan adalah konsep kompementer. Kedua konsep tersebut membantu desainer dalam menciptakan suatu model desain lengkap jika desain berkembang.
- Modularitas
Modularitas
merupakan atribut tunggal dari perangkat lunak yang memungkinkan sebuah program
untuk dikelola secara intelektual.
Meyer menyebutkan 5 kriteria yang memungkinkan kita untuk mengevaluasi suatu metode desain dengan merujuk pada kemampuannya untuk menentukan sistem modular yang efektif.
a. Dekomposisi modular.
b. Komposabilitas modular.
c. Kemampuan pemahaman modular.
d. Kontinuitas modular.
e. Proteksi modular.
Meyer menyebutkan 5 kriteria yang memungkinkan kita untuk mengevaluasi suatu metode desain dengan merujuk pada kemampuannya untuk menentukan sistem modular yang efektif.
a. Dekomposisi modular.
b. Komposabilitas modular.
c. Kemampuan pemahaman modular.
d. Kontinuitas modular.
e. Proteksi modular.
- Arsitektur Perangkat Lunak
Arsitektur
perangkat lunak mencakup “struktur keseluruhan perangkat lunak dan cara dimana
struktur memberikan integrasi konseptual bagi suatu sistem”. Shaw dan Garlan
menjelaskan sekumpulan properti yang seharusnya ditetapkan sebagai bagian dari
desain arsitektural :
a. Properti struktural.
Menentukan komponen suatu sistem dan cara dimana komponen-komponen tersebut dikemas dan berinteraksi satu dengan yang lain.
b. Properti ekstra-fungsional.
Menekankan pada bagaimana arsitektur desain memenuhi persyaratan kinerja, kapasitas, reliabilitas, keamanan, adaptibilitas, dan karakteristik sistem yang lain.
c. Keluarga dari sistem yang berhubungan.
Desain harus memiliki kemampuan untuk memakai lagi blok bangunan arsitektural tersebut.
a. Properti struktural.
Menentukan komponen suatu sistem dan cara dimana komponen-komponen tersebut dikemas dan berinteraksi satu dengan yang lain.
b. Properti ekstra-fungsional.
Menekankan pada bagaimana arsitektur desain memenuhi persyaratan kinerja, kapasitas, reliabilitas, keamanan, adaptibilitas, dan karakteristik sistem yang lain.
c. Keluarga dari sistem yang berhubungan.
Desain harus memiliki kemampuan untuk memakai lagi blok bangunan arsitektural tersebut.
- Hirarki Kontrol
Hirarki
kontrol, disebut juga struktur program merepresentasikan organisasi komponen
program serta mengimplikasikan suatu hirarki kontrol. Hirarki kontrol tidak
mengimplikasikan aspek prosedural dari perangkat lunak, seperti urutan proses,
kejadian/urutan dari keputusan, atau pengulangan operasi.
- Partisi Struktural
Struktur
progam harus dipartisi baik secara horizontal maupun vertikal.
Partisi horizontal menentukan cabang-cabang terpisah dari hirarki modular untuk setiap fungsi program mayor. Keuntungannya :
a. menghasilkan perangkat lunak yang lebih mudah diuji.
b. Membawa kepada perangkat lunak yang lebih mudah dipelihara.
c. Menghasilkan penyebaran efek samping yang lebih sedikit.
d. Menghasilkan suatu perangkat lunak yang lebih mudah untuk diperluas.
Partisi vertikal menyatakan bahwa kontrol dan kerja harus didistribusikan secara top-down dalam arsitektur program.
Partisi horizontal menentukan cabang-cabang terpisah dari hirarki modular untuk setiap fungsi program mayor. Keuntungannya :
a. menghasilkan perangkat lunak yang lebih mudah diuji.
b. Membawa kepada perangkat lunak yang lebih mudah dipelihara.
c. Menghasilkan penyebaran efek samping yang lebih sedikit.
d. Menghasilkan suatu perangkat lunak yang lebih mudah untuk diperluas.
Partisi vertikal menyatakan bahwa kontrol dan kerja harus didistribusikan secara top-down dalam arsitektur program.
- Struktur Data
Struktur
data adalah representasi dari hubungan logis antara elemen-elemen data
individual.
- Prosedur Perangkat Lunak
Prosedur
perangkat lunak berfokus pada detail-detail pemrosesan dari masing-masing modul
secara individual. Prosedur harus memberikan spesifikasi yang teliti terhadap
pemrosesan, mencakup urutan event, poin-poin keputusan nyata, operasi
repetitif, dan organisasi struktur data.
- Penyembunyian Informasi
Prinsip
penyembunyian informasi menyatakan bahwa bahwa modul ditandai dengan keputusan
desain tersembunyi dari semua desain lain.
========================================================================
Desain modular afektif
DESAIGN MODULAR AFEKTIF
1. Independensi fungsional
Merupakan hasil pertumbuhan langsung dari modularitas dan konsep abstraksi dan penyembunyian informasi.
Independensi fungsional dicapai dengan mengembangkan modul dengan fungsi “single-minded” dan suatu “aversi” ke interaksi eksesif dengan modul yang lain.
1. Independensi fungsional
Merupakan hasil pertumbuhan langsung dari modularitas dan konsep abstraksi dan penyembunyian informasi.
Independensi fungsional dicapai dengan mengembangkan modul dengan fungsi “single-minded” dan suatu “aversi” ke interaksi eksesif dengan modul yang lain.
2. Kohesi
Kohesi adalah suatu ekstensi natural dari konsep penyembunyian informasi. Modul kohesi melakukan suatu tugas tunggal pada suatu prosedur perangkat lunak yang memerlukan sedikit interaksi dengan prosedur yang sedang dilakukan di bagian lain dari suatu program.
Kohesi adalah suatu ekstensi natural dari konsep penyembunyian informasi. Modul kohesi melakukan suatu tugas tunggal pada suatu prosedur perangkat lunak yang memerlukan sedikit interaksi dengan prosedur yang sedang dilakukan di bagian lain dari suatu program.
3. Perangkaian
Perangkaian adalah pengukuran interkoneksi diantara modul-modul pada sebuah struktur progam. Perangkaian tergantung pada kompleksitas interface diantara modul-modul, titik dimana entri atau referensi dibuat untuk sebuah modul dan data yang dilewatkan pada interface tersebut.
Desain Modular Efektif
Informasi yang disimpan: Modul-modul seharusnya dispesifikasi dan didesain sehingga detail internal dari modul darus dapat terlihat atau dapat diakses terhadap modul lainnya.
Keuntungan utama: mengurangi pengaruh perubahan pada testing(pengujian) dan maintenance(perawatan).
Independen fungsional: Mendesain modul-modul berdasarkan fitur fungsional independen.
Keuntungan utama: modularity efektif
Cohesion: sebuah ekstensi alami dari konsep informasi yang disimpan sebuah modul dapat menampilkan sejumlah tusk
Sebuah modul cohesive menampilkan sebuha task tunggal dalam sebuah prosedur dengan interaksi kecil dengan lainnya.
Goal: untuk mencapai cohesion yang tinggi untuk modul-modul pada sebuah sistem.
Tipe-tipe yang berbeda dari cohesion:
- coincidentally cohesive: sekumpulan task yang berhubungan satu sama lain secara bebas.
- logically cohesive: koneksi logical antara elemen-elemen pemrosesan
- communication cohesion: data di-share antar elemen-elemen pemrosesan - procedural cohesion: pemesanan antara elemen-elemen pemrosesan
Desain Modular Efektif
Coupling: (Gambar 13.8)
Suatu ukuran interkoneksi antar modul-modul dalam sebuah struktur program.
Coupling tergantung pada kompleksitas interface antar modul.
Goal: mencoba untuk coupling terendah yang mungkin antar modul.
Coupling yang baik à mengurangi atau mencegah pengaruh perubahan dan efek ripple.
à mengurangi biaya pada perubahan program, testing,
maintenance
Tipe-tipe coupling:
- data coupling: parameter passing atau interaksi data
- control coupling: share logical kontrol yang berhubungan (untuk sebuah data kontrol)
- common coupling: sharing data umum
- content coupling: modul, penggunaan data atau pengontrolan
informasi di-maintain modul lain.
Perangkaian adalah pengukuran interkoneksi diantara modul-modul pada sebuah struktur progam. Perangkaian tergantung pada kompleksitas interface diantara modul-modul, titik dimana entri atau referensi dibuat untuk sebuah modul dan data yang dilewatkan pada interface tersebut.
Desain Modular Efektif
Informasi yang disimpan: Modul-modul seharusnya dispesifikasi dan didesain sehingga detail internal dari modul darus dapat terlihat atau dapat diakses terhadap modul lainnya.
Keuntungan utama: mengurangi pengaruh perubahan pada testing(pengujian) dan maintenance(perawatan).
Independen fungsional: Mendesain modul-modul berdasarkan fitur fungsional independen.
Keuntungan utama: modularity efektif
Cohesion: sebuah ekstensi alami dari konsep informasi yang disimpan sebuah modul dapat menampilkan sejumlah tusk
Sebuah modul cohesive menampilkan sebuha task tunggal dalam sebuah prosedur dengan interaksi kecil dengan lainnya.
Goal: untuk mencapai cohesion yang tinggi untuk modul-modul pada sebuah sistem.
Tipe-tipe yang berbeda dari cohesion:
- coincidentally cohesive: sekumpulan task yang berhubungan satu sama lain secara bebas.
- logically cohesive: koneksi logical antara elemen-elemen pemrosesan
- communication cohesion: data di-share antar elemen-elemen pemrosesan - procedural cohesion: pemesanan antara elemen-elemen pemrosesan
Desain Modular Efektif
Coupling: (Gambar 13.8)
Suatu ukuran interkoneksi antar modul-modul dalam sebuah struktur program.
Coupling tergantung pada kompleksitas interface antar modul.
Goal: mencoba untuk coupling terendah yang mungkin antar modul.
Coupling yang baik à mengurangi atau mencegah pengaruh perubahan dan efek ripple.
à mengurangi biaya pada perubahan program, testing,
maintenance
Tipe-tipe coupling:
- data coupling: parameter passing atau interaksi data
- control coupling: share logical kontrol yang berhubungan (untuk sebuah data kontrol)
- common coupling: sharing data umum
- content coupling: modul, penggunaan data atau pengontrolan
informasi di-maintain modul lain.
Desain modular afektif
G.
Modularitas Konsep modularitas dalam perangkat lunak komputer telah didukung
selama hampir empat dekade. Arsitektur perangkat lunak memasukkan modularitas,
dimana perangkat lunak dibagi ke dalam komponen-komponen bernama dan dapat
dipanggil terpisah. Lima kriteria yang memungkinkan kita mengevaluasi suatu
metode desain dengan merujuk pada kemampuannya untuk menentukan sistem modular
yang efektif. Dekomposibilitas modular. Bila metode desain memberikan suatu
mekanisme sistematis untuk melakukan dekomposisi terhadap masalah menjadi
submasalah-submasalah, maka metode desain akan mengurangi kompleksitas
keseluruhan masalah, sehingga dapat mencapai solusi modular efektif.
Komposabilitas modular, bila suatu metode desain memungkinkan komponen-komponen
desain (reusable) yang ada untuk dipasang ke dalam sebuah sistem baru, maka
metode desain akan menghasilkan suatu solusi modular yang tidak berulang.
Kemampuan pemahaman modular, jika sebuah modul dapat dipahami sebagai unit yang
berdiri sendiri (tanpa referensi dari modul lain), maka modul akan lebih mudah
dibangun dan diubah. Kontinuitas modular, Bila perubahan kecil pada persyaratan
sistem menyebabkan perubahan kecil pada modul individual dan bukan perubahan
sistem secara luas, maka pengaruh dari efek samping yang disebabkan oleh
kesalahan oleh perubahan dapat diminimalkan. Proteksi modular, Bila terjadi
kondisi yang menyimpang pada modul tersebut, pengaruh dari efek samping yang
disebabkan oleh kesalahan akan diminimalkan. Akhirnya penting untuk dicatat
bahwa suatu sistem dapat di desain secara modular, bahkan juga bila
implementasinya harus “monolistik”. Ada situasi (misalnya perangkat lunak real
time, perangkat lunak embedded) di mana kecepatan dan subrutin, prosedur) tidak
dapat diterima. Dalam situasi seperti itu, perangkat lunak dapat dan harus
dirancang dengan modularitas sebagai sebuah filosofi yang diprogram tidak
kelihatan modular pada saat pertamanya, filosofi harus dijaga, dan program
tersebut akan memberikan manfaat sistem modular.
=========================================================================
HEURISTIK DESAIN BAGI MODULARITAS YANG EFEKTIF
1. Evaluasi “iterasi pertama” dari struktur program untuk mengurangi perangkaian dan meningkatkan kohesi.
2. Usahakan meminimalkan struktur dengan fan-out yang tinggi; usahakan untuk melakukan fan-in pada saat kedalaman (depth) bertambah.
3. Jagalah supaya lingkup efek dari suatu model ada dalam lingkup control.
4. Evaluasi interface modul untuk mengurangi kompleksitas dan redundansi.
5.Tetapkan modul-modul yang fungsinya dapat diprediksi, tetapi hindari modul yang terlalu restriktif.
6.Usahakan modul-modul “entri kontrol" dengan menghindari “hubungan patalogis”
7.Kemaslah software berdasarkan batasan desain dan persyaratan probabilitas.
=========================================================================
=========================================================================
HEURISTIK DESAIN BAGI MODULARITAS YANG EFEKTIF
1. Evaluasi “iterasi pertama” dari struktur program untuk mengurangi perangkaian dan meningkatkan kohesi.
2. Usahakan meminimalkan struktur dengan fan-out yang tinggi; usahakan untuk melakukan fan-in pada saat kedalaman (depth) bertambah.
3. Jagalah supaya lingkup efek dari suatu model ada dalam lingkup control.
4. Evaluasi interface modul untuk mengurangi kompleksitas dan redundansi.
5.Tetapkan modul-modul yang fungsinya dapat diprediksi, tetapi hindari modul yang terlalu restriktif.
6.Usahakan modul-modul “entri kontrol" dengan menghindari “hubungan patalogis”
7.Kemaslah software berdasarkan batasan desain dan persyaratan probabilitas.
=========================================================================
MODEL DESAIN
Prinsip dan konsep desain disini dimaksudkan membangun sebuah fondasi
untuk pembuatan model desain yang mencakup representasi data,
arsitektur, interface, dan prosedural. Seperti model analisis
sebelumnya. Pada model desain, masing-masing representasi desain
diikatkan dengan yang lainnya, dan semua dapat ditelusuri balik ke
persyaratan perangkat lunak.Banyak pemrogram terus menerus mendesain secara implisit, dengan melakukan desain prosedural pada saat dikodekan. Hal itu sama dengan mengambil desain piramid dan mendirikannya pada titiknya, hasil desain yang sangat tidak stabil. Perubahan yang paling kecil dapat menyebabkan piaramid tersebut (dan program) tumbang.
Model Proses Perangkat Lunak
A. Model air terjun (waterfall) à Biasa juga disebut siklus hidup perangkat lunak. Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.
1. Analisis dan Definisi Persyaratan à Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user sistem.
2. Perancangan sistem dan Perangkat Lunak à Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak. Menentukan arsitektur sistem secara keseluruhan.
3. Implementasi dan pengujian unit à Perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.
4. Integrasi dan Pengujian Sistem à Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, PL dikirim ke User.
5. Operasi dan Pemeliharaan à Biasanya merupakan fase siklus yg paling lama (walaupun tidak seharusnya). Sistem diinstall dan di pakai.
Pemeliharaan mencakup koreksi dan berbagai error yg tdk ditemukan pada tahap2 sebelumnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem.
=========================================================================
DOKUMENTASI DESAIN
Outline spesifikasi desain :I. Ruang Lingkup
A. Sasaran Sistem
B. Persyaratan utama software
C. Batasan-batasan dan pembatasan desain
II. Desain Data
A. Obyek data dan struktur data resultan
B. Struktur file dan database
1. Struktur file eksternal
a.struktur logis
b.deskripsi record logis
c.metode akses
2. data global
3. file dan referensi lintas data
III. Desain Arsitektural
A. Kajian data dan aliran control
B. Struktur program yang diperoleh
IV. Desain Interface
A. Spesifikasi interface manusia-mesin
B. Aturan desain interface manusia-mesin
C. Desain interface eksternal
1. Interface untuk data eksternal
2. Interface untuk sistem atau peralatan eksternal
V. Desain Prosedural
Untuk masing-masing modul :
A. Naratif pemrosesan
B. Deskripsi Interface
C. Deskripsi bahasa (atau lainnya) desain
D. Modul-modul yang digunakan
E. Struktur data internal
F. Keterangan/larangan/pembatasan
VI. Persyaratan Lintas-Referensi
VII. Ketetentuan pengujian
1. Panduan pengujian
2. Strategi integrasi
3. Pertimbangan Khusus
USE CASE
01.56 |
Sebuah
use case adalah metodologi yang digunakan dalam analisis sistem untuk
mengidentifikasi, memperjelas, dan mengatur persyaratan sistem.
Kasus penggunaan terdiri dari satu set urutan yang mungkin dari
interaksi antara sistem dan pengguna dalam lingkungan tertentu dan
terkait dengan tujuan tertentu.
Ini terdiri dari sekelompok elemen (misalnya, kelas dan interface) yang
dapat digunakan bersama-sama dengan cara yang akan memiliki efek lebih
besar daripada jumlah elemen yang terpisah digabungkan. Kasus penggunaan harus berisi kegiatan semua sistem yang memiliki signifikansi bagi pengguna.
Sebuah use case dapat dianggap sebagai kumpulan skenario yang mungkin
terkait dengan tujuan tertentu, memang, kasus penggunaan dan tujuan
kadang-kadang dianggap sinonim.
Sebuah use case (atau set use case) memiliki karakteristik ini:
- Mengatur kebutuhan fungsional
- Model tujuan sistem / aktor (user) interaksi
- Catatan jalan (disebut skenario) dari peristiwa pemicu untuk tujuan
- Menjelaskan salah satu aliran utama peristiwa (juga disebut kursus dasar tindakan), dan mungkin yang lain, yang disebut arus yang luar biasa dari peristiwa (juga disebut kursus alternatif tindakan)
- Apakah multi-level, sehingga satu use case dapat menggunakan fungsi satu lagi.
Gunakan kasus dapat digunakan selama beberapa tahap pengembangan
perangkat lunak, seperti perencanaan kebutuhan sistem, memvalidasi
desain, pengujian perangkat lunak, dan membuat garis besar untuk bantuan
online dan manual pengguna.
Memulai dengan metodologi menggunakan kasus
| Untuk menjelajahi bagaimana use case digunakan di perusahaan, berikut adalah beberapa sumber daya tambahan untuk belajar tentang metodologi use case: |
| Pro dan kontra dari diagram use case: Menempatkan terlalu banyak ke dalam diagram use case sering dapat membuat teknik lain yang berguna kasus penggunaan hampir tidak berguna. Kevlin Henney merekomendasikan pendekatan yang lebih seimbang dan terkendali agar tidak kehilangan pembaca dalam berbagai gelembung dan teks mikroskopis. |
| Dari diagram use case untuk diagram konteks : Ada godaan untuk mempertimbangkan menggunakan diagram kasus sebagai diagram konteks karena mereka melakukan konteks pertunjukan. Tapi memiliki satu diagram untuk kedua akan menghasilkan awan terbaca gelembung. |
| Lima perangkap kasus gunakan untuk menghindari:
Mempekerjakan kasus penggunaan selama analisis persyaratan perangkat
lunak membantu Anda meningkatkan kesempatan Anda untuk mengembangkan
perangkat lunak yang benar-benar memenuhi kebutuhan mereka. Tapi ada perangkap Anda harus menghindari, kata pakar Karl E. Wiegers. =================================================
Deskripsi singkat tentang USE CASE
Defenisi Use Case
Kegunaan Use Case adalah untuk menspesifikasikan konteks sistem, menggambarkan
kebutuhan sistem, memvalidasikan arsitektur sistem, menjalankan implementasi
dan meng-generate test case.
Include Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut. Included use case tidak pernah berdiri sendiri, tetapi hanya merupakan bagian dari beberapa use case yang lebih besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah contoh dari pendelegasian - sekumpulan dari tanggung jawab sebuah sistem diambil dan ditangkap di dalam satu tempat (included use case) - kemudian bagian lainnya dari sistem (use case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka memerlukan fungsi-fungsi use case tersebut. Extend Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan perluasan perilaku dari use case asal. Use case asal dapat berdiri sendiri, tetapi untuk kondisi tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. Hubungan perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user sebagai perilaku yang dapat dipilih dari sistem. Hubungan perluasan juga dapat digunakan untuk memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu. Pada akhirnya, hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat dimasukkan dalam titik tertentu.
Digunakan untuk berkomunikasi dengan end user dan domain expert
o
Menyediakan buy-in pada tahap awal pengembangan sistem.
o
Memastikan pemahaman yang tepat tentang requirement / kebutuhan sistem.
·
Digunakan untuk mengidentifikasi
o
Siapa yang berinteraksi dengan sistem dan apa yang harus dilakukan sistem.
o
Interface yang harus dimiliki sistem.
·
Digunakan untuk ferifikasi
o
Semua requirement yang telah dicapture.
o
Tim pengembang memahami requirement.
Macam-macam Use Case
Scenerio Form
Penjelasan penulisan use case dari sudut pandang actor.
Dialog antara actor dan sistem yang menunjukkan interaksi antar keduanya.
·
Precoditions, yang harus dipertemukan agar use cases dapat bekerja dengan
sukses.
·
Postconditions, mendefinisikan kondisi-kondisi dimana use cases berakhir.
·
Postconditions mengidentifikasi hasil yang dapat diobservasi dan status
akhir dari sistem setelah use case telah komplit.
·
Flow of events, yang mendefinisikan aksi pengguna dan respon sistem
terhadap aksi yang dilakukan. Flow of events merupakan kompresi dari skenario
normal, yang mendefinisikan tingkah laku umum dari sistem untuk use case, dan
cabang-cabang alternatif, dimana bagian lain yang telah tersedia dapat
digunakan oleh use case.
Use Case dan Test Cases akan bekerja dengan baik dalam dua cara,
yaitu:
·
Jika use case dari sistem komplit, akurat dan jelas, maka pembuatan test
cases dapat dilakukan secara langsung.
·
Jika use case tidak dalam kondisi yang baik, maka pembuata test cases akan
membantu dalam melakukan debug terhadap test cases.
Modul Use Case
Mulai dengan kondisi atau kejadian normal biasa:
·
Acuhkan pengecualian, alternatif, dll.
·
Use case harus dinamai dan perspektif pengguna sebagai kata kerja aktif.
·
Menunjukkan deskripsi tujuan dari use case dan defenisi fungsionalitas tingkat
tinggi. TAMBAHAN MENGENAI USE CASE DIAGRAMUSE CASE DIAGRAM•Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. •Menggambarkan kebutuhan system dari sudut pandang user •Mengfokuskan pada proses komputerisasi (automated processes) •Menggambarkan hubungan antara use case dan actor •Use case menggambarkan proses system (kebutuhan system dari sudut pandang user) •Secara umum use case adalah: –Pola perilaku system –Urutan transaksi yang berhubungan yang dilakukan oleh satu actor •Use case diagram terdiri dari –Use case –Actors –Relationship –System boundary boxes (optional) –Packages (optional) USE CASE • Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana” system mengerjakannya • Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor. • Use case dinotasikan dengan gambar (horizontal ellipse) • Use case biasanya menggunakan kata kerja • Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama ACTOR • Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system • Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan • Actor memberi input atau menerima informasi dari system • Actor biasanya menggunakan Kata benda • Tidak boleh ada komunikasi langsung antar actor • Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system • Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan) • Letakkan actor utama anda pada pojok kiri atas dari diagram ASSOCIATION • Associations bukan menggambarkan aliran data/informasi • Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case • Ada 4 jenis relasi yang bisa timbul pada use case diagram 1. Association antara actor dan use case 2. Association antara use case 3. Generalization/Inheritance antara use case 4. Generalization/Inheritance antara actors ASSOCIATION ANTARA ACTOR DAN USE CASE • Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data • Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case • association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda ASSOCIATION ANTARA USE CASE (LANJUT) • <<extend>> perluasan dari use case lain jika kondisi atau syarat terpenuhi – Kurangi penggunaan association Extend ini, terlalu banyak pemakaian association ini membuat diagram sulit dipahami. – Tanda panah terbuka harus terarah ke parent/base use case – Gambarkan association extend secara vertical GENERALIZATION/INHERITANCE ANTARA ACTOR • Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case USE CASE SYSTEM BOUNDARY BOXES • Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of of your system). • Biasanya digunakan apabila memberikan beberapa alternative system yang dapat dijadikan pilihan • System boundary boxes dalam penggunaannya optional Contoh Kasus Usecase
CONTOH KASUS USE CASE PADA GALLERY VCD
VCD House adalah sebuah gallery yang bergerak di bidang retail dan
menjual produk-produk hiburan seperti VCD,DVD,CD playstation,
accessories dan lain-lain. VCD house saat ini mempunyai beberapa cabang
yang tersebar diberbagai mal di Jakarta dan bekasi.
Pada setiap cabang, VCD house menemparkan 2 orang petugas untuk menjaga
tokonya. Biasanya kedua orang ini bertugas secara bergiliran dengan
system shift. Untuk mengendalikan keseluruhan cabangnya, pemilik VCD
House mempekerjakan 2 or ang bagian keuangan, 3 orang bagian
pengontrolan stok dan 3 orang supervisor.
Proses penjualan dimulai saat seorang pelanggan menanyakan tentang suatu
produk kepada petugas toko. Oleh petugas toko, permintaan tersebut akan
ditulis dalam bentuk bon. Selanjutnya atas dasar bon tersebut, petugas
toko akan mengecek dan mengambil barang yang dipesan. Bilamana barang
tidak ada atau jumlah permintaan tidak sesuai, petugas akan bertanya
kepada pelanggan apakah transaksi akan tetap dilakukan. Bila transaksi
tetap dilakukan dengan cara mengambil barang jenis lain atau mengubah
jumlah barang yang dipesan, maka petugas akan melaporkan perhitungan
pembayaran. Saat pembayaran dilakukan petugas akan menanyakan kembali
kategori pembayaran yang akan dilakukan oleh pelanggan. Pembayaran bisa
dilakukan secara tunai(cash) , dengan kartu kredit atau dengan kartu
debit. Jika pembayaran dilakukan secaraa tunai, transaksi akan langsung
dicatat pada buku penjualan. Namun bila dilakukan dengan kartu kredit
atau kartu debit, akan dilakukan otorisasi terlebih dahulu dengan mesin
otorisasi yang telah disediakan oleh bank. Setelah semua prose situ
selesai, barula proses penjualan itu dicatat di buku penjualan
|
Langganan:
Postingan (Atom)












