Tugas RPL pertemuan 4

Nama              : Muhamad Farhan

NIM                : 11182941

Kelas               : 11.6AB.07

Rangkuman Slide Pertemuan 4

Link blog        : http://suckats.blogspot.com/2021/04/tugas-rpl-pertemuan-4.html

 

Konsep Perancangan

1.     Pendahuluan

Perancangan software merupakan tempat dimana aturan kebutuhan stakeholder, bisnis dan pertimbangan teknis disatukan untuk membentuk sebuah software secara bersamaan. Menurut Ian Sommerville, perancangan software adalah membangun suatu solusi permasalahan yang memenuhi kebutuhan-kebutuhan perangkat lunak. Perancangan menciptakan model software yang menjelaskan tentang arsitektur, struktur data, interface dan komponen yang dibutuhkan pada software yang akan dibuat. Tujuannya adalah untuk menghasilkan model software yang memperlihatkan kekuatan (fleksibilitas, efektifitas dan kecepatan), komoditas (hasil produk) dan kenyamanan (kemudahan dalam menggunakan software).

 

Model Perancangan

1.      Perancangan kelas

Mengubah model kelas menjadi realisasi kelas perancangan dan struktur data yang diperlukan software. Objek, relasi dan konten data rinci digambarkan oleh atribut kelas dan notasi sebagai dasar perancangan data. Perancangan data dan perancangan arsitektur software dapat terjadi bersamaan. Perancangan kelas yang terperinci terjadi karena setiap komponen software dirancang

 

2.      Perancangan Arsitektur

Mendefinisikan hubungan elemen structural utama software, gaya dan pola arsitektur yang digunakan dan kendala yang mempengaruhi cara arsitektur dapat diimplementasikan. Mewakili perancangan kerangka kerja arsitektur system berbasis computer yang berasal dari model kebutuhan

 

3.      Perancangan interface

Menggambarkan bagaimana software berkomunikasi dengan system yang berinteraksi dan manusia yang menggunakannya. Menyiratkan informasi dan perilaku tertentu. Perancangan interface tingkat komponen mengubah elemen structural software menjadi deskripsi procedural komponen software

 

2.      Proses perancangan

Proses yang bersifat iterative dimana spesifikasi kebutuhan diubah menjadi blueprint software. Blueprint menggambarkan pandangan holistic software. Yaitu, perancangan diwakili pada tingkat abstraksi tinggi pada tingkat yang dapat langsung ditelusuri ke tujuan system dan data terperinci, fungsional dan perilaku. Saat perancangan berlangsung, penghalusan akan menggerakan abstraksi yang lebih rendah

 

A.    Atribut-atribut kualitas software

Tiga karakteristik umum yang berfungsi sebagai panduan untuk evaluasi perancangan yang baik:

1.      Perancangan harus mengimplementasi kebutuhan eksplisit yang ada, dan kebutuhan implisit yang diinginkan stakeholder

2.      Perancangan harus mudah dibaca dan dimengerti oleh developer dan penguji untuk mendukung software

3.      Perancangan harus menyediakan gambaran lengkap tentang menangani permasalahan data, fungsional, dan perilaku pengimplementasian software

 

Panduan Kualitas software

Untuk mengevaluasi kualitas representasi perancangan, rancangan software harus :

1.     Menggunakan pola arsitektur yang mudah dikenali, tersusun atas komponen-komponen yang menunjukkan karakteristik perancangan yang baik, dapat diimplementasikan secara evolusioner dan memfasilitasi implementasi dan penguji

2.     Bersifat modular, yang artinya software harus menjadi bagian sub-sistem

3.     Berisi representasi data, arsitektur, objek, interface dan komponen yang berbeda

4.     Memuat struktur data yang sesuai dengan kelas yang akan diimplementasikan dan digambarkan dengan pola yang mudah dikenali

5.     Mengarah pada komponen yang menunjukkan karakteristik fungsional independent

6.     Memuat interface yang mengurangi kompleksitas hubungan komponen dan lingkungan eksternal

7.     Harus diturunkan dari metode perulangan yang terkendali yang diperoleh selama analasis software

8.      Direpresentasikan dengan notasi yang efektif saat mengkomunikasikan maknanya

Atributi-atribut kualitas

1.      Fungsionalitas

Dinilai dengan mengevaluasi fitur-fitur, kemampuan, fungsi-fungsi umum yang disampaikan program dan keamanan system

2.      Penggunaan

Dinilai dengan pertimbangan factor manusia, estetika, konsistensi dan dokumentasi

 

3.      Keandalan

Dievaluasi dengan mengukur frekuensi dan tingkat kegagalan, akurasi keluaran, waktu antar kegagalan, recovery dan prediktibilitas program.

4.      Kinerja

Diukur dengan kecepatan pemrosesan data, waktu tanggap, konsumsi sumber daya, throughput dan efeisiensi

5.      Daya dukung

Menggabungkan kemampuan program untuk dikembangkan , beradaptasi, melayani kebutuhan pengguna, kemampuan uji, kompatibilitas dan konfigurabilitas

 

3.      Konsep-Konsep Perancangan

Konsep perancangan pada dasarnya akan menyediakan kebutuhan

-          Kriteria yang digunakan untuk membagi software menjadi komponen mandiri

-          Rincian struktur data yang dapat dipisahkan dari representasi konseptual

-          Kriteria yang digunakan untuk mendefinisikan kualitas teknisi perancangan software

 

A.    Abstraksi

Pada tingkat abstraksi tertinggi, penyelesaian masalah dalam istilah luas dinyatakan dalam Bahasa pada lingkungan permasalahan. Pada tingkat lebih rendah, deskripsi yang terperinci dari penyelesaian masalah harus diberikan. Terminologi berorientasi masalah digabungkan dengan terminology berorientasi implementasi yang bertujuan agar dapat menyelesaikan masalah. Pada tingkat terendah, penyelesaian dapat diimplementasikan secara langsung dengan Bahasa pemrograman yang dipilih

 

B.     Arsitektur

Merupakan struktur keseluruhan software dan bagaimana cara struktur tersebut memberikan integritas konseptual untuk sebuah software. Juga merupakan struktur dari modul program yang menjelaskan bagaimana komponen-komponen tersebut berinteraksi, dan struktur data yang digunakan oleh komponen

Properti sebagai bagian dari perancangan arsitektur:

-          Properti structural

Mendefinisikan komponen sistem dan menjelaskan bagaimana komponen-komponen tersebut dikemas dan berinteraksi satu sama lain.

-          Properti fungsional tambahan

Deskripsi perancangan seharusnya bisa menyelesaikan permasalahan tentang bagaimana arsitektur perancangan mencapai kebutuhan kinerja, kapasitas, keandalan, keamanan, kemampuan beradaptasi, dan karakteristik lainnya.

-          Keluarga system yang berhubungan

Perancangan arsitektural seharusnya dibuat melalui pola perulangan

 

 

C.    Pola (Pattern)

Pola adalah suatu wawasan yang di dalamnya memuat esensi dari solusi yang terbukti untuk permasalahan perancangan PL dalam konteks tertentu [Brad Appleton]. Tujuan dari setiap pola adalah untuk memberikan deskripsi yang memungkinkan perancang untuk menentukan apakah pola:

A.    Berlaku untuk pekerjaan saat ini

B.     Dapat digunakan Kembali

C.     Berfungsi sebagai panduan untuk mengembangkan pola serupa, tetapi berbeda fungsional atau struktural

 

D.    Pemisahan perhatian

Adalah konsep perancangan yang menunjukkan bahwa masalah yang kompleks dapat diselesaikan jika permasalahan itu dibagi menjadi bagian-bagian yang lebih kecil yang lebih mudah diselesaikan dan/atau dioptimalkan secara independent. Dapat diimplementasikan menggunakan konsep perancangan software yang saling berhubungan seperti: modularitas, aspek-aspek, kemandirian fungsional, dan penghalusan.

 

E.     Modularitas

Adalah atribut tunggal dari Software yang memungkinkan suatu program untuk dapat dikelola secara cerdas. Software monolitik adalah program besar yang terdiri dari satu modul dan tidak dapat dengan mudah dipahami. Jumlah lintasan kendali, rentang referensi, jumlah variabel, dan kompleksitas hampir tidak mungkin dimengerti. Lebih banyak modul berarti ukuran modul lebih kecil. Bertambahnya jumlah modul, maka biaya yang terkait dengan pengintegrasian juga bertambah. Tujan modularitas:

a.       Pengembangan lebih mudah direncanakan

b.      Mudah mendefinisikan versi versi software

c.       Mudah mengakomodasi perubahan

d.      Testing dan debugging lebih efisien

e.       Pemeliharaan lebih mudah

 

F.     Penyembunyian informasi

Yang dimaksud penyembunyian informasi adalah modul software harus dispesifikasikan dan dirancang sedemikian rupa sehingga informasi yang ada dalam modul tidak dapat diakses oleh modul lain yang tidak memerlukan informasi tersebut. Menyiratkan bahwa modularitas yang efektif dapat dicapai dengan mendefinisikan sejumlah modul independen yang berkomunikasi satu sama lain dalam hal informasi yang diperlukan untuk mencapai fungsi software

 

G.    Independensi Fungsional

Adalah hasil langsung dari pemisahan masalah, modularitas, dan konsep abstraksi dan penyembunyian informasi. Dapat dicapai dengan mengembangkan modul yang memiliki fungsi tunggal dan memiliki interaksi yang bersifat tertutup. Lebih mudah dikembangkan karena fungsi-fungsi di dalamnya dapat dilokalisasi dan interface disederhanakan dan juga lebih mudah untuk dipelihara dan diuji.

Modul independensi mempunyai kriteria kualitatif:

1.      Kohesifitas

Adalah indikasi dari kekuatan fungsional suatu modul. Biasanya melakukan kompleksitas tunggal dan hanya memerlukan sedikit interaksi.

2.       Coupling

Adalah indikasi kemandirian antar modul dan bergantung pada kompleksitas interface yang menghubungkan modul-modul yang ada, yaitu titik masuk suatu modul, dan data apa yang melewati interface modul.

 

H.    Penghalusan

Merupakan proses elaborasi yang dimulai dengan pernyataan deskripsi informasi yang didefinisikan pada tingkat abstraksi tinggi. Langkah penghalusan menggunakan strategi perancangan top-down. Hirarki software dikembangkan dengan dekomposisi pernyataan fungsi abstraksi prosedural secara bertahap hingga pernyataan dalam bahasa pemrograman dapat tercapai. Membantu untuk mendapatkan rincian pada tingkat rendah saat perancangan berlangsung.

 

I.        Refaktorisasi

Merupakan teknik reorganisasi perancangan software yang bertujuan untuk menyederhanakan perancangan komponen tanpa harus mengubah fungsi atau perilakunya. Refaktorisasi software, diperiksa kembali untuk menemukan:

a.       Redundansi

b.      Elemen perancangan yang tidak perlu

c.       Algoritma yang tidak diperlukan

d.      Struktur data yang buruk

e.       Kegagalan perancangan yang dapat diperbaiki untuk menghasilkan perancangan yang lebih baik

Referensi:

Sumber 1 :

https://adamhendrabrata.files.wordpress.com/2015/10/rpl-4-adam.pdf

Sumber 2 :

https://www.youtube.com/watch?v=KOlv6odO_kw


Comments

Popular posts from this blog

Tugas Struktur Data Pertemuan Ke-4

Tugas RPL Pertemuan 5 - Diagram Penggajian