Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Minggu 6 Prinsip & Konsep Desain. Terjemahan model analisis menjadi desain software.

Presentasi serupa


Presentasi berjudul: "Minggu 6 Prinsip & Konsep Desain. Terjemahan model analisis menjadi desain software."— Transcript presentasi:

1 Minggu 6 Prinsip & Konsep Desain

2 Terjemahan model analisis menjadi desain software

3 Terjemahan Model Analisis (cont.) Data design  mengubah model informasi (entity relationship diagram dan data dictionary) menjadi struktur data Architectural design  berisi hubungan antar elemen dalam program Interface design  menjelaskan bagaimana bagaimana komunikasi di dalam perangkat lunak, dengan sistem, dan dengan manusia yang menggunakannya.  Sebuah interface mengandung maksud sebuah aliran informasi.

4 Terjemahan Model Analisis (cont.) Procedural design  mengubah elemen struktural dari arsitektur program menjadi deskripsi prosedural dari komponen perangkat lunak

5 Petunjuk Dalam Melakukan Desain Sebuah desain harus menunjukkan organisasi secara hirarkis Sebuah desain harus bersifat modular; jadi, sebuah perangkat lunak seharusnya dapat dibagi-bagi secara lojik menjadi beberapa elemen yang melakukan fungsi atau subfungsi secara spesifik Sebuah desain harus mengandung abstraksi data dan prosedural Sebuah desain harus mengarah pada modul- modul (prosedur atau subrutin) yang menunjukkan karakteristik fungsional

6 Petunjuk Dalam Melakukan Desain (cont.) Sebuah desain harus mengarah pada antarmuka yang mengurangi kompleksitas hubungan antar modul dan dengan lingkungan luar Sebuah desain harus diturunkan menggunakan metode yang berulang yang diarahkan oleh informasi yang dihasilkan pada tahap analisis perangkat lunak

7 Prinsip Desain Prinsip Desain memungkinkan perekayasa Perangkat lunak untuk mengendalikan proses desain Proses desain tidak boleh mengalami “tunnel vision”  Desainer harus memperhatikan pendekatan-pendekatan alternatif, menilainya berdasarkan persyaratan masalah, sumber daya yang ada untuk melakukan pekerjaan, dan konsep desain Desain harus dapat dilacak ke model analisis Tidak melakukan desain pada hal yang sama berulang- ulang Desain harus merepresentasikan masalah pada keadaan nyata Desain harus memperlihatkan keseragaman dan integrasi

8 Prinsip Desain (cont.) Desain harus terstruktur untuk mengatisipasi adanya perubahan Desain bukan coding, coding bukan desain Penilaian kualitas desain harus dilaksanakan pada saat desain tersebut dibuat Desain harus di-review untuk meminimasi kesalahan konseptual

9 Konsep Desain Konsep desain : memberikan kerangka kerja untuk mendapatkan program yang berfungsi dengan benar Abstraksi  Mengijinkan desainer berfokus pada pemecahan masalah tanpa risau tentang detail level rendah yang tidak relevan Procedural abstraction – sequence dari event Data abstraction – kumpulan objek data

10 Data abstraction

11 Procedural Abstraction

12 Konsep desain-penyaringan Pada setiap langkah(penyaringan), satu atau beberapa instruksi dari program yang diberikan didekomposisi ke dalam instruksi- instruksi yang lebih detail. Penyaringan spesifikasi berhenti bila semua instruksi diekspresikan dalam bentuk bahasa pemrograman yang mendasar

13 Procedural Abstraction

14 Konsep Desain Modularitas  Derajat di mana software dapat dimengerti dengan memeriksa komponen-komponennya secara independent  C(p1)>C(p2) maka E(p1)>E(p2)  C(p1+p2)>C(p1)+C(p2) maka E(p1+p2)>E(p1)+E(p2)  Keterangan : C(x) : fungsi untuk mengukur kompleksitas permasalahan x E(x) : fungsi untuk menentukan usaha (dalam waktu) yang diperlukan untuk memecahkan masalah x

15 Modularitas Lebih mudah dibangun, lebih mudah diubah, lebih mudah diperbaiki

16 Konsep Desain Arsitektur software  Arsitektur merupakan struktur hirarki dari komponen program(modul), cara bagaimana komponen tersebut berinteraksi, dan struktur data yang digunakan oleh komponen Hirarki kontrol  Disebut juga struktur program, merepresentasikan organisasi (secara hirarkis) komponen program(modul) serta mengimplikasikan suatu hirarki kontrol  Tidak merepresentasikan aspek prosedural SW(misalnya urutan proses, pengulangan operasi)

17 Hirarki kontrol Lebar kedalaman

18 Hirarki kontrol Depth mengindikasikan tingkat kontrol Width mengindikasikan rentang keseluruhan kontrol Fan-out : pengukuran jumlah modul yang dikontrol secara langsung oleh modul yang lain Fan-in : berapa banyak modul yang secara langsung mengontrol sebuah modul yang diberikan Superordinat : modul yang mengontrol modul lain, misalnya M adalah super ordinat untuk modul a, b, c Subordinat : modul yang dikontrol modul lain

19 Konsep Desain Pembagian struktural  Partisi horizontal mendefinisikan tiga partisi(input, transformasi data, dan output)  Partisi vertikal(factoring) menyatakan bahwa kontrol(pembuatan keputusan) dan kerja harus didistribusikan secara top down dalam arsitektur program Keputusan kontrol dalam modul level atas dan pemrosesan kerja dalam modul yang lebih rendah

20 Pembagian struktural Partisi Horizontal  Menentukan cabang-cabang terpisah dari hirarki modular untuk setiap fungsi program mayor  Menggunakan modul kontrol untuk mengkoordinasikan komunikasi antara fungsi- fungsi

21 Keuntungan Partisi Horizontal Menghasilkan software yang lebih mudah diuji Membawa software yang lebih mudah dipelihara Menghasilkan penyebaran efek samping yang lebih sedikit Menghasilkan software yang lebih mudah diperluas

22 Kerugian Partisi Horizontal Partisi horizontal menyebabkan lebih banyak data yang dilewatkan melalui interface modul dan dapat merumitkan keseluruhan kontrol dari aliran program(bila pemrosesan membutuhkan pergerakan yang cepat dari suatu fungsi ke fungsi yang lain)

23 Pembagian struktural Partisi vertikal  Desain, sedemikian sehingga pembuatan keputusan dan kerja dibuat bertingkat-tingkat  Modul pembuatan keputusan sebaiknya terletak pada puncak arsitektur

24 Keuntungan partisi vertikal Sifat : perubahan pada modul kontrol memiliki probabilitas penyebaran efek samping yang lebih tinggi ke modul yang menjadi sub ordinatnya Secara umum perubahan program berada di seputar perubahan input, komputasi, dan output Struktur kontrol keseluruhan program (perilaku dasar) sangat kecil probabilitas untuk berubah,  sehingga kurang rentan terhadap efek samping pada saat perubahan dibuat, sehingga menjadi lebih dapat dipelihara

25 Konsep Desain Struktur data  Representasi dari hubungan logis antara elemen- elemen data individual Software procedure  Spesifikasi proses yang seksama(event sequences, titik-titik keputusan, operasi pengulangan, struktur data) Penyembunyian informasi  Informasi (data dan procedur) yang terkandung dalam modul tidak dapat diakses oleh modul lain, yang tidak mempunyai kebutuhan terhadap informasi tersebut

26 Dokumentasi Desain I. Lingkup Sistem II. Desain Data III. Desain Arsitektur IV. Desain Antarmuka V. Desain Prosedural VI. Catatan Khusus VII. Appendix

27 Data Design Mengubah objek data yang didefinisikan pada model analisis menjadi struktur data yang ada dalam perangkat lunak Atribut yang dimiliki objek data, hubungan di antara objek data, dan penggunaannya dalam program, semuanya mempengaruhi pemilihan struktur data

28 Architectural Design Menggunakan karakteristik aliran informasi dalam model analisis untuk menghasilkan struktur program Sebuah data flow diagram dipetakan menjadi struktur program menggunakan dua pendekatan :  Transform mapping  Transaction mapping

29 Architectural Design (cont.) Transform mapping : diterapkan untuk sebuah aliran data yang menunjukkan batas yang jelas antara data yang masuk dan yang keluar  DFD dipetakan menjadi sebuah struktur yang mengalokasikan kontrol menjadi input, pemrosesan, dan output bersama dengan hirarki modul Transaction mapping :  diterapkan jika sebuah item informasi menyebabkan percabangan, yang disebut transaksi, yang memicu aliran data lain sepanjang salah satu dari beberapa jalur  DFD dipetakan menjadi sebuah struktur yang mengalokasikan kontrol menjadi sebuah sub struktur yang mendapatkan dan mengevaluasi sebuah transaksi

30 Karakteristik Aliran

31 Contoh Kasus Transform Flow

32 Contoh Kasus Transaction Flow

33 Langkah-langkah Transform Mapping Isolasi pusat transfromasi dengan mengkhususkan batas aliran masuk dan keluar Lakukan pemfaktoran tingkat pertama Lakukan pemfaktoran tingkat kedua Pemfaktoran menghasilkan struktur program di mana modul tingkat puncak membuat keputusan dan modul tingkat bawah melakukan sebagian besar kerja input, komputasi, dan output Saringlah struktur program iterasi pertama dengan menggunakan heuristik desain bagi kualitas perangkat lunak yang telah ditingkatkan  Modul diledakkan atau disatukan

34 Transform Mapping

35 Pemfaktoran tingkat pertama untuk sensor monitor

36 Pemfaktoran tingkat kedua untuk sensor monitor

37 Struktur program untuk sensor monitor

38 Struktur program tersaring untuk sensor monitor

39 Transaction Mapping

40 Langkah-langkah Transaction Mapping Petakan DFD pada sebuah struktur program yang sesuai dengan pemrosesan transaksi Faktorkan dan saringlah struktur transaksi dan struktur masing-masing jalur aksi Saringlah struktur program iterasi pertama dengan menggunakan heuristik desain untuk kualitas perangkat lunak yang dikembangkan

41 Pemfaktoran tingkat satu untuk sub sistem user interaction

42 Potongan pertama struktur program untuk sub sistem user interaction

43 Interface Design Meliputi antarmuka program internal dan eksternal serta desain untuk antarmuka pengguna Desain antarmuka internal dan eksternal diarahkan oleh informasi yang diperoleh dari model analisis


Download ppt "Minggu 6 Prinsip & Konsep Desain. Terjemahan model analisis menjadi desain software."

Presentasi serupa


Iklan oleh Google