Prinsip dan Konsep Desain

Desain Perangkat Lunak dan RPL

Proses desain
 Suatu proses yang melawati serangkaian kebutuhan yang membentuk sebuah perangkat lunak 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.

Kualitas desain dan software
Agar dihasilkan desain yang baik suatu desain haruslah :

1. Memperlihatkan organisasi hirarki yang mengontrol elemen-elemen software.
2. 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. Diturunkan dengan menggunakan metode perulangan yang didukung oleh informasi yang ada selama analisa kebutuhan software

Program structure
Program structure menampilkan / menyajikan organisasi ( seringkali organisasi hirarki ) dari komponen-komponen program ( modul-modul ) dan mengandung arti hirarki dari kontrol program. Notasi yang digunakan adalah diagram tree. Biasanya dinamakan structure chart.

Data structure
Menggambarkan relasi logikal antara sejumlah elemen.contoh :

type G = array [1..100] of integer;

...

...

Procedure S ( var T : G ; n : integer ; sum : integer );

Var

I : integer;

begin

sum := 0;

for I:=1 to n do

sum := sum + t[i];

end;

Software procedure
Difokuskan pada detail pemrosesan dari setiap modul secara individu.Prosedur harus mengandung spesifikasi yang benar / tepat dari pemrosesan,termasuk : sequence of events, decision points, repetitive operations, dan struktur data.

Modularitas

Software dibagi kedalam nama-nama yang terpisah dan elemen-elemen yang dapat dipanggil, yang disebut dengan modul, yang termasuk kedalam memenuhi syarat-syarat permasalahan
Misalkan :

C(x) = fungsi kompleksitas dari suatu masalah

E(x) = fungsi usaha/waktu yang diperlukan untuk memecahkan suat masalah

Prinsip Desain
David [DAV95] memaparkan sekumpulan prinsip untuk desain software:

1.     Proses desain seharusnya tidak bertahan dari “tunnel vision”.
2.     Desain harus dapat di trace ke model analisa.
3.     Desain seharusnya tidak menemukan/invent wheel.
4.     Desain harus “memperkecil jarak intellectual” antara software dan masalah-masalah pada dunia nyata.
5.     Desain harus mengeluarkan uniformity dan integrasi.
6.     Desain harus terstruktur untuk mengakomodasi perubahan.
7.     Desain harus terstruktur untuk mendegradasi secara halus(degrade gently).
8.     Desain bukan coding.
9.     Desain harus di-assessed untuk kualitas.
10.     Desain harus diulang untuk meminimalis kesalahan konsep.

  Konsep Desain

Abstraction
Abstraction adalah gambaran dari fungsi suatu program. Gambaran ini bisa bertingkat-tingkat. Tingkat yang paling atas adalah gambaran suatu fungsi program dengan menggunakan bahasa alami. Pada tingkat terendah, menghasilkan abstraksi yang bersifat prosedural/ langkah perlangkah dengan menggunakan istilah yang teknis dan bisa diimplementasikan menjadi fungsi program. contoh :
Program : Iklan Part-time Job
Fungsi: Pendaftaran calon part-timer
Abstraction 1 (highest level): Calon part-timer dalam melakukan upload syarat-syarat yang diperlukan untuk melamar: surat lamaran, CV, foto, transkrip, data diri.
Abstraction 2 (lower level):
Procedural abstraction :

1.     Tampilkan pilihan part-time job
2.     Input data
3.     Verifikasi format

Refinement
Penjelasan detil dari abstraction refinement membantu designer untuk memperlihatkan detil dari lowest level dari abstraction. Abstraction dan refinement merupakan konsep yang saling melengkapi.

Konsep Desain – Modularity
Software dibagi komponen dengan nama dan alamat yang berbeda, disebut modul. Meyer [MEY88] mendefenisikan lima kriteria yang memungkinkan kita mengevaluasi sebuah metode desain

1. Modular composability: sebuah metode desain memungkinkan komponen desain yang telah ada dirakit ke sebuah sistem baru.
2. Modular understandability: sebuah modul dapat dimengerti sebagai sebuah unit yang berdiri sendiri dan akan lebih mudah membangun dan mengubahnya.
3. Modular continuity: perubahan kecil terhadap kebutuhan sistem menghasilkan perubahan pada tiap modul, dibanding perubahan system-wide.
4. Modular protection: sebuah kondisi aberrant terjadi dalam sebuah modul dan efeknya di-constrain dalam modul.

Software architecture
-       Struktur software secara keseluruhan

-        Struktur hirarki/berjenjang dari modul-modul program. Untuk menggambarkan

-        Struktur modul-modul tersebut beberapa model yang ada adalah :

1.      framework model : identifikasi pola yang berulang-ulang

2.      dynamic model : identifikasi bagaimana konfigurasi sistem berubah karena kejadian-kejadian tertentu

3.      process model: fokus pada proses teknis yang harus dikerjakan sistem

4.      functional model : menggambarkan hirarki sistem berdasarkan fungsinya

Software procedure
Fokus pada detil proses pada tiap modul. Prosedur menjelaskan proses, urutan kejadian, proses perulangan, penentuan keputusan/arah. Ini bisa digambarkan dengan menggunakan Flow Chart yang bertingkat.

Information Hiding
Ide dari information hiding (menyembunyikan informasi) adalah modul dirancang sedemikian rupa sehinga inforamsi (prosedur dan data) yang di dalamnya tidak dapat di akses oleh modul lain yang tidak memerlukannya.

Desain Modular Efektif
Modular design   mereduksi komplesitas masalah, menyediakan fasilitas untuk melakukan perubahan ( dalam hal pemeliharaan ), dan memudahkan implementasi dengan pengembangan paralel dari bagian-bagian yang berbeda dalam suatu sistem.

1. Module types : abstraksi dan penyembunyian informasi dipakai untuk mendefinisikan modul-modul di dalam lingkungan software architecture. Suatu modul mungkin dikategorikan sebagai berikut:  Sequential module   dieksekusi tanpa interupsi yang dilakukan software aplikasi, Incremental module   dapat diinterupsi oleh program aplikasi dan kemudian kembali ke titik semula setelah interupsi selesai,Parallel module   dieksekusi secara simultan dengan modul lain dalam lingkungan Concurrent multiprocessor
2. Independensi Fungsional : konsep functional independence berkembang dari modularitas dan konsep abstraksi serta information hiding. Independence diukur dengan menggunakan 2 kriteria kualitatif, yaitu : cohesion, coupling.
3. Cohesion ( keterpautan ) : suatu modul kohesif membentuk sebuah tugas tunggal di dalam suatu software prosedur dan memerlukan sedikit interaksi dengan prosedur yang dibuat dalam bagian lain dari suatu program.

• Coincidental cohesion : sebuah modul yang membentuk sejumlah tugas yang berhubungan satu sama lain dengan longgar
• Logically cohesion : sebuah modul yang membentuk tugas-tugas yang dihubungkan secara logical
• Temporal cohesion : jika sebuah modul berisi sejumlah tugas yang dihubungkan dengan segala yang harus dieksekusi di dalam waktu yang bersamaan.
• Procedural cohesion : jika pemrosesan elemen-elemen dari suatu modul dihubungkan dan harus dieksekusi dalam urutan spesifik
• Communication cohesion : jika pemrosesan elemen-elemen dikonsentrasikan pada satu area dari suatu struktur data.

    4.   Coupling ( bergandengan ) : merupakan suatu pengukuran dari keterkaitan / keterhubungan antara sejumlah modul dalam struktur program.

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 yang dibicarakan pada bab ini membangun sebuah fondasi untuk pembuatan model desain yang mencakup representasi data, arsitektur, interface dan prosedur.

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

VIII. Catatan Khusus

IX. Lampiran