Asi Baru

Solusi :
Bagian Akademik tidak perlu mencatat data siswa dan kwitansi pembayaran siswa secara manual lagi, tapi cukup langsung memasukkan data siswa dan kwitansi pembayaran secara komputerisasi dan menggunakan database.

Konsep dan Prinsip Desain

Konsep dan Prinsip Desain

 

Konsep dan prinsip memiliki tujuan, dan adapun tujuannya adalah untuk menghasilkan suatu model atau representasi dari entitas yang kemudian akan dibangun.

Desain Perangkat Lunak dan Rekayasa Perangkat Lunak

Fase pengembangan terdiri dari tiga langkah yaitu design, code generation (manual or automatic) dan testing. Setiap langkah melakukan transformasi informasi dengan suatu cara yang akhirnya menghasilkan software komputer yang valid.

Software Requirements

Dijelaskan dengan information domain, functional and performance requirments, dan feed the design step. Dengan menggunakan satu dari sejumlah metode desain, langkah desain menghasilkan :

1. Desain data (difokuskan pada definisi dari struktur data)
2. Desain arsitektur (mendefinisikan hubungan antara elemen struktur utamadari program)
3. Desain interface
4. Desain prosedural (mengubah struktur elemen kedalam prosedur software)

Selama desain, kita dapat membuat keputusan yang akan mempengaruhi kesuksesan konstruksi software dan kemudahan maintenance-nya. Desain sangat penting karena dapat menentukan kualitas dari suatu software.

Proses Desain

Software design 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.

Agar dihasilkan desain dengan kriteria yang baik, maka suatu desain haruslah :

1. Memperlihatkan organisasi hirarki yang mengontrol elemen-elemen software
2. Berkenaan dengan modul. 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

Evolusi Desain Software

Merupakan suatu proses kontinu yang terus berlangsung selama tiga dekade. Beberapa metodologi telah tumbuh, dan secara umum memiliki karakteristik sebagai berikut :

1. Mekanisme penerjemahan suatu model analisis ke dalam representasi desain.
2. Notasi untuk merepresentasikan komponen-komponen fungsional dan interface-nya.
3. Heuristik bagi penyaringan dan partisi
4. Pedoman bagi penilaian kualitas

Prinsip desain

Desain perangkat lunak berupa model dan proses. Proses desain adalah

serangkaian langkah iteratif yang memungkinkan desainer menggambarkan

semua aspek perangkat lunak yang dibangun. Model desain adalah ekivalen

rencana arsitek untuk sebuah “rumah”, yang dimulai dengan menyajikan

totalitas dari hal yang akan dibangun.

Konsep-konsep desain

1. Abstraksi

Jika kita menggunakan suatu solusi modular untuk beberapa masalah,

maka beberapa level / tingkat abstrasi dapat ditampilkan / diperlihatkan.

1. Pada level tertinggi, suatu solusi berada pada term yang umum dengan menggunakan bahasa natural
2. Level yang lebih rendah lebih berorientasi pada prosedur-prosedur

Contoh :

Abstraksi 1

The software will incorporate a computer graphics interface that will enable visual communication with the drafts person and a digitizer interface that replace the drafting board and square. All line and curve drawing, all geometric computation, and all sectioning and auxiliary views will be performed by the CAD Comp.

Abstraksi 2

CAD Software tasks :
user interaction task ;
2-D drawing creation task ;
graphics display task ;
drawing file management task ;
end.

Abstraksi 3

procedure : 2-D drawing creation ;
repeat until (drawing creation task terminates)
do while (digitizer interaction occurs)
digitizer interface task ;
determine drawing request case ;
line : line drawing task ;
circle : circle drawing task ;
…
…
end ;
do while (keyboard interaction occurs)
keyboard interaction task ;
process analysis / computation case ;
view : auxiliary view task ;
section : cross sectioning task ;
…
…
end
…
…
end repetition ;
end procedure.

2. Penyaringan

Penyaringan stepwise adalah strategi desain top-down yang diusulkan oleh Wiklaus Wirth.

Kajian dari konsep tersebut adalah “Pada setiap langkah (penyaringan), satu atau beberapa instruksi dari program yang diberikan didekomposisi ke dalam instruksi-instruksi yang lebih detail. Dekomposisi berurutan atau penyaringan spesifikasi berhenti bila semua instruksi diekspresikan dalam bentuk bahasa pemrograman atau komputer yang mendasar. Jika tugastugas disaring, maka data harus disaring juga, didekomposisi atau distruktur, dan adalah wajar untuk menyaring program dan spesifikasi data secara paralel” . Abstraksi dan penyaringan adalah konsep kompementer. Kedua konsep tersebut membantu desainer dalam menciptakan suatu model desain lengkap jika desain berkembang.

3. Modularitas

Software dibagi ke dalam elemen-elemen terpisah yang dapat dipanggil, yang disebut dengan modul.

Misalkan :

C(x) : fungsi kompleksitas dari suatu masalah

E(x) : fungsi usaha/waktu yang diperlukan untuk memecahkan suatu masalah

P1 ,P2 = masalah 1, masalah 2

Jika : C(P1) > C(P2) maka : E(P1) > E(P2)

Berdasarkan penelitian :

1. C ( P1 + P2 ) > C ( P1 ) + C ( P2 )

2. E ( P1 + P2 ) > E ( P1 ) + E ( P2 )

4. Arsitektur perangkat lunak

Arsitektur perangkat lunak menyinggung 2 karakteristik penting dari sebuah program komputer:

1. Hirarki struktur dari komponen-komponen prosedural ( modul )
2. Struktur data

5. Partisi structural

Struktur progam harus dipartisi baik secara horizontal maupun vertikal. Partisi horizontal menentukan cabang-cabang terpisah dari hirarki modular untuk setiap fungsi program mayor. Keuntungannya :

a. Menghasilkan perangkat lunak yang lebih mudah diuji.

b. Membawa kepada perangkat lunak yang lebih mudah dipelihara.

c. Menghasilkan penyebaran efek samping yang lebih sedikit.

d. Menghasilkan suatu perangkat lunak yang lebih mudah untuk diperluas.

Partisi vertikal menyatakan bahwa kontrol dan kerja harus didistribusikan secara top-down dalam arsitektur program.

6. Hirarki Kontrol (Program Structure)

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

7. Prosedur perangkat lunak

Prosedur perangkat lunak berfokus pada detail-detail pemrosesan dari masing-masing modul secara individual. Prosedur harus memberikan spesifikasi yang teliti terhadap pemrosesan, mencakup urutan event, poinpoin keputusan nyata, operasi repetitif, dan organisasi struktur data.

8. Struktur data

Struktur data adalah representasi dari hubungan logis antara elemenelemen

data individual.

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;

9. Penyembunyian informasi

Prinsip penyembunyian informasi menyatakan bahwa modul ditandai dengan keputusan desain tersembunyi dari semua desain lain.

Contoh :

Black Box : input, output, & proses diketahui tetapi proses detail tidak diketahui.

Bagi Modul B, Modul C adalah Black Box

USE CASE

USE CASE

Deskripsi singkat tentang USE CASE

• Perilaku sistem adalah bagaimana sistem beraksi dan bereaksi. Perilaku ini merupakan aktifitas sistem yang bisa dilihat dari luar dan bisa diuji.
• Perilaku sistem ini dicapture di dalam USE CASE. USE CASE sendiri mendeskripsikan sistem, lingkungan sistem, serta hubungan antara sistem dengan lingkungannya.

Defenisi Use Case

• Deskripsi dari sekumpulan aksi sekuensial yang ditampilkan sistem yang menghasilkan yang tampak dari nilai ke actor khusus. Use Case digunakan untuk menyusun behavioral things dalam sebuah model. Use case direalisasikan dengan sebuah collaboration. Secara gambar, sebuah use case digambarkan dengan sebuah ellips dengan garis penuh, biasanya termasuk hanya namanya, seperti gambar berikut :

• Representasi atau model yang digunakan dalam Rekayasa Perangkat Lunak untuk menggambarkan fungsional requirement suatu sistem.
• Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem.
• Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan perangkat lunak dalam berbagai cara.
• Suatu Use Case adalah suatu sekuensial aksi yang dilakukan oleh sistem, yang akan secara bersama-sama, memproduksi hasil yang dibutuhkan oleh pengguna sistem. Use Case mendefinisikan alur proses sepanjang sistem berbasis pada kegunaan sebagaimana yang biasa dilakukan (secara manual).

Contoh sederhana:
Konsumen pesan tiket pesawat

Contoh lebih lengkap:
Use Case pada Sistem Rumah Sakit

Kegunaan Use Case adalah untuk menspesifikasikan konteks sistem, menggambarkan kebutuhan sistem, memvalidasikan arsitektur sistem, menjalankan implementasi dan meng-generate test case.

Include
Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut. Included use case tidak pernah berdiri sendiri, tetapi hanya merupakan bagian dari beberapa use case yang lebih besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah contoh dari pendelegasian - sekumpulan dari tanggung jawab sebuah sistem diambil dan ditangkap di dalam satu tempat (included use case) - kemudian bagian lainnya dari sistem (use case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka memerlukan fungsi-fungsi use case tersebut.

Extend
Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan perluasan perilaku dari use case asal. Use case asal dapat berdiri sendiri, tetapi untuk kondisi tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. Hubungan perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user sebagai perilaku yang dapat dipilih dari sistem. Hubungan perluasan juga dapat digunakan untuk memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu. Pada akhirnya, hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat dimasukkan dalam titik tertentu.
Manfaat Model Use Case

• Digunakan untuk berkomunikasi dengan end user dan domain expert
  • Menyediakan buy-in pada tahap awal pengembangan sistem.
  • Memastikan pemahaman yang tepat tentang requirement / kebutuhan sistem.
• Digunakan untuk mengidentifikasi
  • Siapa yang berinteraksi dengan sistem dan apa yang harus dilakukan sistem.
  • Interface yang harus dimiliki sistem.
• Digunakan untuk ferifikasi
  • Semua requirement yang telah dicapture.
  • Tim pengembang memahami requirement.

Macam-macam Use Case

• Narative Form
  Bentuk teks bebas dalam format paragraph.
• Scenerio Form
  Penjelasan penulisan use case dari sudut pandang actor.
• Conversation Form
  Dialog antara actor dan sistem yang menunjukkan interaksi antar keduanya.

Perbandingan Bentuk Use Case

Format Penulisan Use Case
Tiap Use Case memiliki:

• Precoditions, yang harus dipertemukan agar use cases dapat bekerja dengan sukses.
• Postconditions, mendefinisikan kondisi-kondisi dimana use cases berakhir.
• Postconditions mengidentifikasi hasil yang dapat diobservasi dan status akhir dari sistem setelah use case telah komplit.
• Flow of events, yang mendefinisikan aksi pengguna dan respon sistem terhadap aksi yang dilakukan. Flow of events merupakan kompresi dari skenario normal, yang mendefinisikan tingkah laku umum dari sistem untuk use case, dan cabang-cabang alternatif, dimana bagian lain yang telah tersedia dapat digunakan oleh use case.

Use Case dan Test Cases akan bekerja dengan baik dalam dua cara, yaitu:

• Jika use case dari sistem komplit, akurat dan jelas, maka pembuatan test cases dapat dilakukan secara langsung.
• Jika use case tidak dalam kondisi yang baik, maka pembuata test cases akan membantu dalam melakukan debug terhadap test cases.

Modul Use Case
Mulai dengan kondisi atau kejadian normal biasa:

• Acuhkan pengecualian, alternatif, dll.
• Use case harus dinamai dan perspektif pengguna sebagai kata kerja aktif.
• Menunjukkan deskripsi tujuan dari use case dan defenisi fungsionalitas tingkat
  tinggi.