Selasa, 04 Agustus 2009

KONSEP DAN PRINSIP DESAIN

Desain software dan software engineering
Process desain
Prinsip desain
Konsep desain
- Abstraksi, perbaikan, modularity
Arsitektur software
- Hirarki control
- Partisi struktural
- Struktur data
- Procedur software
- Information yang tersembunyi
Desain modular yang efektif
- Ketergantungan fungsional, kohesi, penggabungan
Desain heuristic untuk modularity efektif
Model desain
Dokumentasi desain

Desain Software dan Software Engineering

Desain ->Langkah pertama dalam fase pengembangan untuk prodengineer manapun. Bertindak sebagai pondasi untuk semua software engineering dan pemeliharaan software dengan langkah-langkah yang mengikutinya.

Tujuan seorang perancang adalah menghasilkan suatu model(atau penyajian) dari sebuah entitas yang akan dibangun

Input desain software : Model analisa kebutuhan dan dokumentasi spesifikasi
Output desain software : Model desain dan dokumentasi spesifikasi desain

Desain - menerjemahkan kebutuhan ke model desain lengkap untuk sebuah produk software.
- menyediakan representasi software yang dapat diduga untuk kualitas.

Desain Software

Sejumlah metode desain dapat digunakan untuk menghasilkan desain software:
- Desain data: mentransformasi model domain informasi ke struktur data
- Desain arsitektur: menggambarkan relasi antar elemen struktural utama program
- Desain interface : mendeskripsikan bagaimana software berkomunikasi with user
- Desain prosedur: mentransformasikan elemen structural arsitektur program ke sebuah deskripsi prosedur dari komponen software.

Evolusi desain software:
- Konstruksi program modular[DEN73] dan metode perbaikan top-down[WIR71].
- Pemrograman terstruktur [DAH71, MIL72].
- Perpindahan data flow/data structure ke sebuah defenisi desain[JAC75][WAR74].
- Pendekatan berorientasi object[JAC92][GAM95].

Fitur umum metode desain software:
- Sebuah mekanisme untuk perpindahan sebuah model analisa ke representasi desain
Sebuah notasi untuk merepresentasi komponen fungsional dan interface-nya.
Heuristic untuk perbaikan dan partisi
Panduan untuk assessment kualitas

Proses Desain

Desain software --> sebuah proses iteratif dimana kebutuhan diterjemahkan ke sebauh “blueprint” untuk mengkonstruksi software.

Desain direpresentasikan pada level atas abstraction. Saat iterasi desain terjadi, perbaikan subsequent membawa ke representasi desain pada level abstraksi yang lebih bawah.

Kualitas desain sangat penting. Dua metode digunakan untuk mengecek kualitas:
a) Tinjauan ulang teknis formal, dan b) desain walkthrough

Tiga fitur umum sebuah desain yang baik dari McGlaughlin’s [McG91]:
- Desain harus mengimplementasikan semua kebutuhan(eksplisit/implisit)
- Desain harus dapat dibaca dan dimengerti
- Desain harus menyediakan suatu gambar lengkap software pada aspek aspek data, fungsi dan perilaku.


Kualitas Desain

Untuk mengevaluasi sebuah desain software, sebauh criteris kualitas desain dapat digunakan.

Berikut panduan untuk sebuah desain yang baik:
- Sebuah desain harus A design should exhibit a hierarchical organization about software
- Sebuah desain harus modular berdasarkan pada partisi logical.
Sebuah desain terdiri dari data dan abstraksi prosedural.
Sebuah desain harus membawa ke modul dengan fitur fungsional yang independen.
Sebuah desain harus membawa interface yang sederhana antar modul.
Sebuah desain harus diturunkan menggunakan metode yang dapat berulang.

Proses desain software memacu desain yang baik dalam aplikasi dengan prinsip desain fundamental, metodologi yang sistematik, dan melalui review(pengulangan).


Prinsip Desain

David [DAV95] memaparkan sekumpulan prinsip untuk desain software:

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

Faktor kualitas eksternal: diobservasi oleh user.
Faktor kualitas internal: penting untuk engineer.

Konsep Desain

Abstraksi:

Tiap langkah pada proses software engineering adalah sebuah perbaikan pada tingkatan abstraksi dari solusi software.

- Abstraksi data: Sekumpulan data
- Abstraksi prosedural:
Satu urutan instruksi pada sebuah fungsi spesifik
- Abstraksi kontrol:
Sebuah program mengkontrol mekanisme tanpa menspesifikasikan detail internal.

Refinement(perbaikan): Perbaikan sebenarnya adalah sebuah proses dari elaborasi.

Stepwise dari perbaikan adalah sebuah strategi desain top-down yang dikeluarkan oleh Niklaus [WIR71].
Arsitektur sebuah program dikembangkan dengan sukses memperbaiki
level detail procedural.

Proses perbaikan program analog terhadap proses perbaikan dan partisi yang digunakan selama analisa kebutuhan. Perbedaan utama berada pada level detail implementasi, disamping pendekatannya.

Abstraksi dan perbaikan secara komplemen dikonsep.
Abstraksi memungkinkan seorang desainer untuk menspesifikasi prosedur dan data w/o detail.
Perbaikan membantu desainer untuk me-reveal detail low-level.

Konsep Desain - Modularity

Konsep modularity telah dipakai selama hampir empat dekade.
Software dibagi komponen dengan nama dan alamat yang berbeda, disebut modul.
Meyer [MEY88] mendefenisikan lima kriteria yang memungkinkan kita mengevaluasi sebuah metode desain dengan bergantung kepada kemampuannya mendefenisikanfive sebuah sistem modular efektif:
Modular decomposability: sebuah metode desain menyediakan sebuah mekanisme sistematik untuk men- decompose atau membagi masalah ke sub-masalahà mengurangi kompleksitas dan mendapatkan modularity

Modular composability: sebuah metode desain memungkinkan komponen desain yang telah ada dirakit ke sebuah sistem baru.

Modular understandability: sebuah modul dapat dimengerti sebagai sebuah unit yang berdiri sendiri dan akan lebih mudah membangun dan mengubahnya.

Modular continuity: perubahan kecil terhadap kebutuhan sistem menghasilkan perubahan pada tiap modul, dibanding perubahan system-wide.

Modular protection: sebuah kondisi aberrant terjadi dalam sebuah modul dan efeknya di-constrain
dalam modul.

Arsitektur Software

Arsitektur software adalah struktue hirarki dari komponen program components dan interaksinya.

Shaw dan Garlan [SHA95a] menggambarkan sekumpulan properti desain arsitektur:

Properti structural : Desain arsitektur mendefenisikan komponen sistem dan interaksinya.

Properti extra-functional : Desain arsitektur harus meng-address bagaimana arsitektur desain menerima kebutuhan untuk performance, kapasitas, ketersediaan(reliability), adaptability, keamanan.

Kumpulan sistem yang berhubungan:
desain arsitektur harus menggambar pola yang dapat diulang pada desain dengan sistem yang sama.






Metode desain arsitektural yang berbeda:

Model structural: merepresentasikan arsitektur sebagai sebuah koleksi terorganisir dari komponen

Model framework: meningkatkan level desain abstraksi dengan mengidentifikasi secara berulang
framework desain arsitektur(pola-pola)

Model dinamis: meng-address aspek-aspek perilaku arsitektur program

Model prosess: fokus pada desain bisnis atau proses teknis

Model functional: dapat digunakan untuk merepresentasikan hierarki fungsional sebuah sistem

Partisi Structural

Struktur program harus dipartisi secara horizontal dan vertikal. (Gambar 13.4)

(1)Partisi horizontal menggambarkan cabang-cabang yang terbagi dari hierarki modular untuk tiap fungsi program utama.

Cara termudah adalah mempartisi sebuah sistem menjadi:
input, transformasi data(pemrosesan), dan output

Keuntungan dari partisi horizontal:
- mudah untuk diuji, di-maintain, dan extend
- efek yang lebih kecil pada perubahan propagasi atau error propagasi

Kerugian: lebih banyak data dilewatkan melalui interface modul
--> menyulitkan kontrol keseluruhan dari aliran program

(2) Partisi vertical memaparkan kontrol dan work harus terdistribusi top-down dalam struktur program.

Keuntungan: baik pada kesesuain untuk perubahan:
- mudah untuk me-maintain perubahan
- mengurangi pengaruh perubahan dan propagasi.

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.

2 komentar: