Minggu 6 Prinsip & Konsep Desain

Slides:



Advertisements
Presentasi serupa
Design Perangkat Lunak
Advertisements

KONSEP PENGEMBANGAN REKAYASA PERANGKAT LUNAK
Teknik Pemrograman Terstruktur
PERANCANGAN PERANGKAT LUNAK (SOFTWARE DESIGN)
DASAR-DASAR PENGUJIAN PERANGKAT LUNAK
Bab 6 PERANCANGAN PERANGKAT LUNAK
DESAIN ARSITEKTUR PERANGKAT LUNAK
UNIFIED MODELLING LANGUAGE
Perancangan Perangkat Lunak lanjutan Kuliah - 7
PEMODELAN ANALISIS Kuliah - 5
KONSEP DESAIN SOFTWARE DATABASE
By: Mr. Haloho Pemodelan Proses.
Pengujian Sofware – strategi
REKAYASA SISTEM.
Desain Sistem By Hendro Joko Prasetyo, M.Kom.
Interaction Diagram.
PERANCANGAN PERANGKAT LUNAK
BUSINESS PROCESS REENGINEERING (BPR).
REKAYASA PERANGKAT LUNAK REQUIREMENTS ANALYSIS FUNDAMENTALS
Prototyping Aplikasi Teknologi Informasi
Metode Desain Dr. Ema Utami, S.Si, M.Kom.
PROSES DESIGN SISTEM BASIS DATA
RE-ENGINEERING.
Kelompok 5 : Asdin Ines Lestari Neng Susanti Siti Robiahtul Adawiyah Vena Senja Maba SOFTWARE REQUIREMENTS.
TEKNIK TESTING DAN STRATEGI TESTING
PERANCANGAN BASIS DATA
KONSEP DAN PRINSIP ANALISIS
BUSINESS PROCESS REENGINEERING
Desain Sistem.
PriNciples That Guide Practice
ARSITEKTUR DAN PEMODELAN APLIKASI
Design Perangkat Lunak
PERANCANGAN PERANGKAT LUNAK ( PL )
REKAYASA PERANGKAT LUNAK
DESAIN SISTEM.
Pertemuan 6 Implementasi Modularitas Dalam Bahasa Pemrograman
Data Flow Diagram (DFD)
Design Basis Data Kelompok 9
PENDEKATAN UNTUK MEMBANGUN SISTEM
Perancangan Sistem Informasi
PENGEMBANGAN PERANCANGAN SISTEM
11. REKAYASA SISTEM BERBASIS KOMPUTER
KONSEP DESAIN SOFTWARE DATABASE
Rekayasa Perangkat Lunak
12. KONSEP DAN PRINSIP ANALISIS
KEBUTUHAN & SPESIFIKASI SOFTWARE
Analisis Kinerja Sistem Pertemuan ke 3
DATA FLOW DIAGRAM.
Analisis dan Perancangan Sistem Informasi Erik Kurniadi
Rekayasa Perangkat Lunak Pertemuan 7
Desain Perangkat Lunak Analisis Persyaratan Perangkat Lunak
10 Perancangan Arsitektural
Pemodelan Sistem Bisnis
KEBUTUHAN & SPESIFIKASI SOFTWARE
Analisa dan Perancangan Sistem Informasi Operasional
REKAYASA SISTEM BERBASIS KOMPUTER
Pengembangan Sistem Informasi
ANALISA KEBUTUHAN PERANGKAT LUNAK
REKAYASA KEBUTUHAN PL.
KELOMPOK 6 Modeling Adnin Devit C F
Analisis dan Desain Berorientasi Obyek
Desain Sistem.
Rekayasa Perangkat Lunak
DASAR - DASAR PERANCANGAN PERANGKAT LUNAK
DASAR - DASAR PERANCANGAN PERANGKAT LUNAK
Teknik Pemrograman Terstruktur
KEBUTUHAN & SPESIFIKASI SOFTWARE
Pemrograman Terstruktur
Rekayasa Perangkat Lunak
12. KONSEP DAN PRINSIP ANALISIS
Transcript presentasi:

Minggu 6 Prinsip & Konsep Desain

Terjemahan model analisis menjadi desain software

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.

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

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

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

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

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

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

Data abstraction

Procedural Abstraction

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

Procedural Abstraction

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

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

Konsep Desain Arsitektur software Hirarki kontrol 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)

Hirarki kontrol kedalaman Lebar

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

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

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

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

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)

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

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

Konsep Desain Struktur data Software procedure Penyembunyian informasi 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

Dokumentasi Desain Lingkup Sistem Desain Data Desain Arsitektur Desain Antarmuka Desain Prosedural Catatan Khusus Appendix

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

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

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

Karakteristik Aliran

Contoh Kasus Transform Flow

Contoh Kasus Transaction Flow

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

Transform Mapping

Pemfaktoran tingkat pertama untuk sensor monitor

Pemfaktoran tingkat kedua untuk sensor monitor

Struktur program untuk sensor monitor

Struktur program tersaring untuk sensor monitor

Transaction Mapping

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

Pemfaktoran tingkat satu untuk sub sistem user interaction

Potongan pertama struktur program untuk sub sistem user interaction

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