Rekayasa perangkat lunak (rpl)

(1)

REKAYASA

PERANGKAT LUNAK

(RPL)

REKAYASA

PERANGKAT LUNAK

(RPL)

Betha Nurina Sari,M.Kom

(2)

 Pemodelan Hasil Analisis Kebutuhan

(3)

Membangun Model Analisis

Elemen-elemen model analisis

 Elemen-elemen berbasis skenario

 Fungsional—memproses narasi untuk fungsi software

 Use-case—gambaran interaksi antara aktor dan

sistem

 Elemen-elemen berbasis Class

 Dipengaruhi oleh skenario

 Elemen-elemen Perilaku/Behavioral

 State diagram

 Elemen-elemen berorientasi aliran

 Data flow diagram

(4)

Berbasis Skenario :

Use-Cases

Sekelompok skenario pengguna yang

menggambarkan alur penggunaan sistem

Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan PL dalam berbagai cara

Setiap skenario menjawab pertanyaan-pertanyaan berikut :

 Siapa aktor primer dan sekunder ?  Apa tujuan aktor ?

 Prekondisi apa yang harus ada sebelum cerita dimulai?  Apa tugas atau fungsi utama yang dilakukan oleh aktor ?  Ekstensi apa yang harus diperhatikan ketika cerita

(5)

(6)

(7)

PERANCANGAN SOFTWARE

7

 Proses untuk mendefinisikan suatu model

atau rancangan sistem dengan

menggunakan teknik dan prinsip tertentu

sedemikian sehingga model atau rancangan

tersebut dapat diwujudkan menjadi

Perangkat Lunak.

 Proses mendefinisikan arsitektur PL,

komponen, modul, antarmuka,

pendekatan pengujian, serta data untuk

memenuhi kebutuhan yang sudah ditentukan sebelumnya.

 Proses bertahap dimana semua kebutuhan

yang ada diterjemahkan menjadi suatu cetak biru yang akan digunakan untuk

(8)

Strategi Perancangan

8

 Top Down

 Bottom Up

 Organizational

Struktur proses perancangan dipengaruhi oleh faktor-faktor non teknis yang timbul dari faktor-faktor organisasi pemakai peangkat lunak

 Blue Print

(9)

3 Karakteristik Evaluasi

Perancangan

9

 Perancangan harus mengimplementasi-kan

keseluruhan kebutuhan eksplisit dan

mengakomodasi semua kebutuhan implisit

yang diinginkan

 Perancangan harus menjadi panduan yang

dapat dibaca, dipahami bagi programmer dan

penguji PL

 Perancangan harus memberikan suatu

(10)

Perancangan Sistem

10

 Proses Perancangan

Serangkaian langkah iteratif yang memungkinkan desainer menggambarkan semua aspek sistem yang dibangun

 Model Perancangan

(11)

OBJEK PERANCANGAN

11



Data



Struktur tabel basis data / file data



Struktur data internal



Arsitektur perangkat lunak



Structure chart



Struktur menu program



Antarmuka pemakai

(12)

TRANSFORMASI MODEL ANALISIS - PERANCANGAN

Model Analisis

• Diagram Konteks

• DFD level 1, 2, …

• Kamus Data

• Spesifikasi Proses

• E-R Diagram

Model Perancangan

• Rancangan Data

• Arsitektur PL

(Structure Chart)

• Antarmuka Pemakai

• Spesifikasi Program

(13)

PERANCANGAN BASIS DATA

13

 Transformasi Diagram E-R (conceptual

data model, CDM) menjadi model relasi

(skema relasi, tabel relasi).

 Penentuan atribut relasi sesuai

dengan kamus data yang telah dibuat.

 Normalisasi.

 Pendefinisian struktur tabel.

 Pembuatan relasi antar tabel

(14)

CONTOH STRUKTUR TABEL

BASIS DATA

Tabel Penjualan

 Fungsi : Menyimpan data transaksi penjualan

 Jenis : Tabel Transaksi

 Primary Key : No_Faktur+Kode_Brg

 Foreign Key : Kode_Brg

 Struktur Tabel :

No. Nama Field Jenis Lebar Keterangan

1 No_Faktur String 10 Nomor Faktur 2 Kode_Brg String 8 Kode Barang

3 Hrg_Jual Long Integer 8 Harga jual barang saat transaksi 4 Kuantitas Integer 5 Banyaknya (kuantitas) barang

(15)

CONTOH RELASI ANTAR

TABEL

15

NO_FAKTUR = NO_FAKTUR KODE_BRG = KODE_BRG

KODE_SUP = KODE_SUP

(16)

ARSITEKTUR PERANGKAT

LUNAK

16



Gambaran bagaimana

elemen/komponen fungsional

perangkat lunak disusun,

diorganisasi dan distrukturkan

sehingga:

 Hubungan antar elemen/komponen

dapat dijelaskan.

 Interface yang menghubungkan

elemen/komponen dapat didefinisikan.

 Wujud dan penempatan

elemen/komponen dalam tempat

penyimpanan sekunder secara fisik

(17)

Aliran Transformasi

17

Mentrasformasikan data eksternal ke

bentuk internal diidentfikasi sebagai

aliran masuk, terjadi transisi, data

masuk

dilewatkan

melalui

pusat

transformasi dan bergerak keluar

(18)

Aliran Transaksi

(19)

CONTOH ARSITEKTUR PERANGKAT LUNAK 19 id_supplier rec_supplier rec_supplier rec_barang id_barang Bagian Penjualan Barang Supplier 1 Tambah Data Barang 2 Tambah Data Supplier Baca Id_Supplier Rekam Supplier Tambah Data Supplier id_supplier rec_supplier Baca Id_Barang Rekam Barang Tambah Data Barang id_barang _{rec_barang} Kelola Data Induk Model Analisis (DFD level

(20)

STRUCTURE CHART (1) :

PASCAL

 Modul A memanggil

modul B dengan data x dan y sebagai

parameternya.

 Modul B mengirimkan

data p dan q sebagai

return value ke modul A.

20

A

B

modul pemanggil

modul yang dipanggil p, q notasi untuk parameter _{output yang diberikan pada}

modul pemanggil x, y notasi untuk parameter input yang dikirimkan kepada modul yang dipanggil

Procedure A;

Var p, q : Real;

Procedure B(x, y : Real); Begin

p := ... { manipulasi nilai p }

q := ... { manipulasi nilai q }

End; Begin

B(x, y); { call procedure B }

End;

(21)

STRUCTURE CHART (2) : PHP

<html> ...

<form method=post action=Rekam.php> ...

</html>

21

<?

// Rekam.php

function getId() { }

function saveId(id) { }

(22)

PERANCANGAN ANTARMUKA PEMAKAI

22



Secara fisik antarmuka pemakai

yang dirancang adalah tampilan

layar (form, halaman web).



Jenisnya dapat berupa:

 Menu pilihan

 Form isian (entry)

 Penyajian informasi (report, query)

 Kotak dialog, jika diperlukan

(23)

IDENTIFIKASI RANCANGAN ANTARMUKA

PEMAKAI

23

Tambah Data Barang X

id_supplier rec_supplier rec_supplier rec_barang id_barang Bagian Penjualan Barang Supplier 1 Tambah Data Barang 2 Tambah Data Supplier

1:Milik 2:Konsinyasi

Rp. Rp.

Tambah Data Barang X

Kode Barang: Nama Barang: Satuan: Jenis: Harga Beli: Harga Jual: Jumlah Stok: Kode Supplier: unit

R ekam B atal

Ada interaksi antara pemakai

dengan PL

Harus ada user interface untuk Tambah Data

Barang!

id_barang = kode_ brg + nama_brg + satuan + jenis + hrg_beli + hrg_jual + jml_stok +

kode_sup

Ada data yang diberikan oleh pemakai ke PL

(24)

PENULISAN SPESIFIKASI

PROGRAM

24

 Deskripsi prosedural (algoritma) untuk

semua modul-modul program yang

menjadi elemen-elemen struktural dari arsitektur perangkat lunak:

 Prosedur

 Fungsi

 Merupakan penjelasan lebih rinci dan

teknis dari spesifikasi proses.

 Ditulis dengan menggunakan notasi

pseudo-code, atau notasi yang mirip

(25)

25

SPESIFIKASI PROSES SPESIFIKASI PROGRAM ( DELPHI LIKE )

Proses 1.1 Tambah Data Barang

Begin

While data barang masih ada

Do

Baca identitas barang Verifikasi

If not valid Then

tulis pesan

Else rekam ke tabel barang

End

Procedure btnRekamBarangClick

Kamus

{ Deklarasi variabel; TEdit, TDBLookupCombo, TTable terdefinisi }

eKode, eNama, eSatuan, eJenis, eHrgBeli, eHrgJual, eJmlStok: TEdit DBLookupCombo1: TDBLookupCombo

TabelBarang, TabelSupplier: TTable

Algoritma

{ Buka tabel barang dan supplier }

TabelBarang.Open TabelSupplier.Open

{ Baca identitas barang melalui komponen TEdit dan validasi } { Rekam ke tabel barang }

TabelBarang.Append

(26)

 UML (Unified Modeling Language)

(27)

UML mempunyai 9 diagram, yaitu;

• Diagram Use Case

• Diagram Class

• Diagram Package

• Diagram Object

• Diagram Sequence

• Diagram Collaboration

• Diagram StateChart

• Diagram Activity

(28)

Diagram Use Case

 Diagram Use Case menggambarkan apa

saja aktifitas yang dilakukan oleh suatu sistem dari sudut pandang pengamatan luar. yang menjadi persoalan itu apa

yang dilakukan bukan bagaimana melakukannya.

 Diagram Use Case dekat kaitannya

dengan kejadian-kejadian. Kejadian

(scenario) merupakan contoh apa yang terjadi ketika seseorang berinteraksi

(29)

 untuk lebih memperjelas lihat gambaran suatu peristiwa untuk sebuah klinik kesehatan :

 “Pasien menghubungi klinik untuk membuat janji (appointment) dalam pemeriksaan

tahunan. Receptionist mendapatkan waktu yang luang pada buku jadwal dan

memasukkan janji tersebut ke dalam waktu luang itu.”

(30)

Fungsi Diagram Use Case

 Menjelaskan fasilitas yang ada (requirements)

Use Case baru selalu menghasilkan fasilitas baru

ketika sistem di analisa, dan design menjadi lebih

jelas.

 Komunikas dengan klien

Penggunaan notasi dan simbol dalam diagram Use Case membuat pengembang lebih mudah

berkomunikasi dengan klien-kliennya.

 Membuat test dari kasus-kasus secara umum

(31)

Diagram Class

 Diagram Class memberikan pandangan

secara luas dari suatu sistem dengan menunjukan kelas-kelasnya dan

hubungan mereka.

 Diagram Class bersifat statis;

menggambarkan hubungan apa yang terjadi bukan apa yang terjadi jika

(32)

Diagram Class

 Setiap diagram Class memiliki Class

(kelas), association, dan multiplicity.

Sedangkan navigability (alur arah) dan

role (kegiatan) merupakan optional

(tidak diharuskan).

 Diagram Class dapat dibagi 2 yaitu :

 Diagram Package

(33)

(34)

Diagram Package

 Untuk mengatur pengorganisasian

diagram Class yang kompleks, dapat dilakukan pengelompokan kelas-kelas berupa package (paket-paket).

 Package adalah kumpulan

(35)

Gambar di bawah ini mengenai model bisnis dengan pengelompokan kelas-kelas dalam bentuk paket-paket :

(36)

Diagram Object

 Ada jenis khusus dari diagram Class

yaitu diagram Object. Kegunaannya untuk penjelasan yang sedikit dengan relasi yang sulit, khususnya relasi

(37)

Lihat gambar dibawah, diagram Class kecil menunjukkan

bahwa ‘department’ dapat mengandung banyak ‘department’ yang lain.

 Setiap tingkatan pada diagram berpengaruh

pada single instance (bagian tunggal). Nama

bagian digarisbawahi dalam diagram UML.

Untuk Class name (nama kelas) maupun

instance name (nama bagian) bisa mengambil dari diagram Object selama arti diagram

(38)

Diagram Sequence

 Diagram sequence merupakan salah satu

diagram yang bersifat dinamis yang

menjelaskan bagaimana suatu operasi

itu dilakukan; message (pesan) apa yang dikirim dan kapan pelaksanaannya.

 Diagram ini diatur berdasarkan waktu.

 Obyek-obyek yang berkaitan dengan

proses berjalannya operasi diurutkan dari kiri ke kanan berdasarkan waktu

(39)

Di bawah ini adalah diagram Sequence untuk pembuatan Hotel Reservation. Obyek yang mengawali urutan message adalah ‘aReservation Window’.

(40)

Diagram Collaboration

 Diagram Collaboration juga merupakan

diagram interaction / bersifat dinamis.

 Diagram membawa informasi yang sama

(41)

 Gb.7 Contoh diagram collaboration “Pemesanan

(42)

Diagram Collaboration

 Kotak kegiatan obyek diberi label dengan

nama kelas atau obyek (atau keduanya). Nama kelas dibatasi dengan colons /titik dua ( : ).

 Setiap pesan pada diagram Collaboration

mempunyai angka yang terurut.

 Pesan yang tingkatannya tertinggi adalah

angka 1. Pesan yang berada pada tingkat yang

sama memiliki prefix yang sama, namun suffix

(43)

Diagram StateChart

 Behaviors dan state dimiliki oleh obyek.

Keadaan dari suatu obyek bergantung

pada kegiatan dan keadaan yang berlaku pada saat itu. Diagram StateChart

(44)

Diagram Deployment dan Component

 Untuk lebih jelas, contoh yang digunakan

model diagram untuk login yang

merupakan bagian dari Online Banking System. Logging in terdiri atas masukan Input Social Security Number dan

(45)

Logging in dapat dibagi menjadi empat tahapan proses, yaitu : - Getting SSN (masukkan SSN)

- Getting PIN (masukkan PIN) - Validating (periksa kesahannya) - Rejecting (keluar)

(46)

Diagram Activity

 Pada dasarnya diagram Activity sering digunakan

oleh flowchart.

 Diagram ini berhubungan dengan diagram

Statechart.

 Diagram Statechart berfokus pada obyek yang

dalam suatu proses (atau proses menjadi suatu

obyek), diagram Activity berfokus pada

aktifitas-aktifitas yang terjadi yang terkait dalam suatu proses tunggal.

 Jadi dengan kata lain, diagram ini menunjukkan

(47)

Diagram Activity

 Sebagai contoh, perhatikan proses yang

terjadi. “Pengambilan uang dari bank melalui ATM.”

 Ada tiga aktifitas kelas (orang, dan

lainnya) yang terkait, yaitu : Customer, ATM, and Bank. Proses berawal dari

lingkaran start hitam pada bagian atas dan berakhir di pusat lingkaran stop

(48)

Aktivitas digambarkan dalam bentuk kotak persegi. Lihat gambar di bawah ini, agar lebih jelas :

(49)

Diagram Deployment dan Component

 Component adalah sebuah code module

(kode-kode module).

 Diagram Component merupakan fisik

sebenarnya dari diagram Class.

 Diagram Deployment menerangkan

(50)

Gambar 10 menerangkan hubungan sekitar komponen software dan hardware yang berperan dalam ruang lingkup real estate.

(51)

Diagram Deployment dan Component

 Fisik hardware berbentuk seperti

node-node. Setiap komponen merupakan bagian dari node. Pada gambar

(52)

27 Juli Pertemuan 13-14 : Pengujian Software

1 Agustus : Presentasi Perancangan Software

3 Agustus : Presentasi Pengujian software

8 Agustus : UAS