Rekayasa perangkat lunak (rpl)

SEMESTER
PENDEK
2015/2016

REKAYASA
PERANGKAT LUNAK
(RPL)

Betha Nurina Sari,M.Kom

PERTEMUAN 9-10


Pemodelan Hasil Analisis Kebutuhan

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




Elemen-elemen Perilaku/Behavioral




State diagram

Elemen-elemen berorientasi aliran





Dipengaruhi oleh skenario

Data flow diagram

Elemen-elemen berorientasi obyek

Berbasis Skenario : UseCases
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
digambarkan?

Use-Case Diagram

Berbasis Perilaku : State
Diagram

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

Strategi Perancangan
8






Top Down
Bottom Up
Organizational
Struktur proses perancangan dipengaruhi oleh faktorfaktor non teknis yang timbul dari faktor organisasi
pemakai peangkat lunak



Blue Print
Menggunakan strategi perancangan yang standar untuk
beberapa masalah yang memiliki kesamaan paradigma

9

3 Karakteristik Evaluasi
Perancangan







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
gambaran lengkap mengenai PL

Perancangan Sistem
10




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



Model Perancangan
Ekivalen rencana arsitek untuk sebuah rumah. (yang
dibuat untuk perangkat sistem memberikan berbagai
pandangan yang berbeda tentang program komputer

OBJEK PERANCANGAN
11



Data






Struktur tabel basis data / file data
Struktur data internal

Arsitektur perangkat lunak



Structure chart
Struktur menu program

Antarmuka pemakai
 Spesifikasi program (algoritma)


TRANSFORMASI MODEL ANALISIS PERANCANGAN
12


Model Analisis
• Diagram Konteks
• DFD level 1, 2, …
• Kamus Data

Model Perancangan
2

• Rancangan Data

3

• Arsitektur PL
(Structure Chart)
• Antarmuka Pemakai

• Spesifikasi Proses
1

• E-R Diagram


4

• Spesifikasi Program
(Algoritma)

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
(physical data model, PDM)



CONTOH STRUKTUR TABEL
BASIS DATA
14

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
BARANG
KODE_BRG
KODE_SUP
NAMA_BRG
SATUAN
JENIS
HRG_BELI
HRG_JUAL
JML_STOK

A8
A6
A25
A4
A1
I
I
I

KODE_SUP = KODE_SUP

SUPPLIER
KODE_SUP
NAMA_SUP
ALAMAT
KOTA
TELEPON

A6
A25
A30
A15
A12

KODE_BRG = KODE_BRG

JUAL
KODE_BRG
NO_FAKTUR
HRG_JUAL
KUANTITAS

A8
A10
I
NO_FAKTUR = NO_FAKTUR
I

BAYAR
NO_FAKTUR
TANGGAL
JML_BAYAR

A10
D
I

16

ARSITEKTUR PERANGKAT
LUNAK


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

Aliran Transformasi
17

Mentrasformasikan data eksternal ke
bentuk internal diidentfikasi sebagai
aliran masuk, terjadi transisi, data
masuk
dilewatkan
melalui
pusat
transformasi dan bergerak keluar
melalui jalur keluar.

Aliran Transaksi
18

CONTOH ARSITEKTUR PERANGKAT LUNAK
19

1
Tambah
Data Barang

id_barang

Bagian
Penjualan

Modul Pemanggil

rec_barang
id_supplier
Barang

rec_supplier

rec_supplier
Supplier

2
Tambah
Data
Supplier

Arsitektur Perangkat
Lunak
(Structure Chart)

Model Analisis (DFD level
atomik)
Proses
1.0

id_barang

Kelola Data
Induk

Proses
2.0
Tambah Data
Barang

Tambah Data
Supplier
rec_barang

id_supplier

rec_supplier

supplier

Modul-modul
atomik (procedure,
function)

Baca
Id_Barang

Rekam
Barang

Baca
Id_Supplier

Rekam
Supplier

STRUCTURE CHART (1) :
PASCAL
20

x, y

p, q

B

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.

modul pemanggil

A
notasi untuk
parameter input
yang dikirimkan
kepada modul
yang dipanggil



notasi untuk parameter
output yang diberikan pada
modul pemanggil
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;

Potongan kode
program dalam
bahasa Pascal

STRUCTURE CHART (2) : PHP
21

FormInput.html


FormInput

...

...


Rekam

Rekam.php


id

id

getId

saveId

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
Fasilitas bantuan (Help), jika diperlukan

IDENTIFIKASI RANCANGAN ANTARMUKA
PEMAKAI
1

23

Tambah
Data Barang

id_barang

Bagian
Penjualan

rec_barang
id_supplier
Barang

rec_supplier

rec_supplier
Supplier

Ada data yang
diberikan oleh
pemakai ke PL
Lihat kamus
datanya!!!
id_barang = kode_ brg +
nama_brg + satuan + jenis +
hrg_beli + hrg_jual + jml_stok +
kode_sup

2
Tambah
Data
Supplier

Ada interaksi
antara pemakai
dengan PL
Harus ada user interface
untuk Tambah Data
Barang!

Tambah Data Barang Data Barang
Tambah

XX

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

1:Milik 2:Konsinyasi
Rp.
Rp.
unit

R ekam

B atal

24

PENULISAN SPESIFIKASI
PROGRAM


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
dengan bahasa pemrograman yang
digunakan.

SPESIFIKASI PROSES
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
1
Tambah
Data Barang

id_barang

Bagian
Penjualan

rec_barang
id_supplier
Barang

rec_supplier

rec_supplier
Supplier

25

2
Tambah
Data
Supplier

SPESIFIKASI PROGRAM ( DELPHI LIKE )
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
TabelBarang.FieldByName('Kode_Brg').AsString := eKode.Text
TabelBarang.FieldByName('Nama_Brg').AsString := eNama.Text
TabelBarang.FieldByName('Satuan').AsString := eSatuan.Text
TabelBarang.FieldByName('Jenis').AsInteger:=StrToInt(eJenis.Text)
TabelBarang.FieldByName('Hrg_Beli').AsInteger:=StrToInt(eHrgBeli.Text)
TabelBarang.FieldByName('Hrg_Jual').AsInteger:=StrToInt(eHrgJual.Text)
TabelBarang.FieldByName('Jml_Stok').AsInteger:=StrToInt(eJmlStok.Text)
TabelBarang.FieldByName('Kode_Sup').AsString := DBLookupCombo1.Value;
TabelBarang.Post

PERTEMUAN 11-12


UML (Unified Modeling Language)

UML mempunyai 9 diagram, yaitu;










Diagram
Diagram
Diagram
Diagram
Diagram
Diagram
Diagram
Diagram
Diagram

Use Case
Class
Package
Object
Sequence
Collaboration
StateChart
Activity
Deployment

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
dengan sistem.





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.”

gb 1. Contoh Kegiatan Pasien yang membuat janji

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
Kumpulan dari kejadian-kejadian untuk Use Case bisa
dilakukan test kasus layak untuk kejadian-kejadian
tersebut.

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
mereka berhubungan.

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
Diagram Object

Gb.2 Contoh Diagram Class Transaksi Pembelian Barang

Diagram Package




Untuk mengatur pengorganisasian
diagram Class yang kompleks, dapat
dilakukan pengelompokan kelas-kelas
berupa package (paket-paket).
Package adalah kumpulan elemenelemen logika UML.

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

Gb.3 Contoh Diagram

Diagram Object


Ada jenis khusus dari diagram Class
yaitu diagram Object. Kegunaannya
untuk penjelasan yang sedikit dengan
relasi yang sulit, khususnya relasi
rekursif

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
tersebut masih jelas.

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
terjadinya dalam pesan yang terurut.

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

Gambar 6. Contoh Diagram Sequence ‘Pemesanan kamar
di Hotel’.

Diagram Collaboration




Diagram Collaboration juga merupakan
diagram interaction / bersifat dinamis.
Diagram membawa informasi yang sama
dengan diagram Sequence, tetapi lebih
memusatkan atau memfokuskan pada
kegiatan obyek dari waktu pesan itu
dikirimkan.



Gb.7 Contoh diagram collaboration “Pemesanan

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
berbeda bergantung pada posisinya; hanya
untuk angka 1, 2, dan seterusnya.

Diagram StateChart


Behaviors dan state dimiliki oleh obyek.
Keadaan dari suatu obyek bergantung
pada kegiatan dan keadaan yang berlaku
pada saat itu. Diagram StateChart
menunjukan kemungkinan dari keadaan
obyek dan proses yang menyebabkan
perubahan pada keadaannya.

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
Personal Id Number yang berlaku, lalu
memutuskan kesahan dari informasi
tersebut.

Logging in dapat dibagi menjadi empat tahapan proses, yaitu :
- Getting SSN (masukkan SSN)
- Getting PIN (masukkan PIN)
- Validating (periksa kesahannya)
- Rejecting (keluar)

Gambar 8. Contoh Diagram StateChart ‘Sistem Perbankan secara Online’

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 aktifitasaktifitas yang terjadi yang terkait dalam suatu
proses tunggal.
Jadi dengan kata lain, diagram ini menunjukkan
bagaimana aktifitas-aktifitas tersebut bergantung
satu sama lain.

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
hitam/putih pada bagian bawah.

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

Gambar 9. Contoh Diagram Activity ‘Pengambilan Uang
melalui ATM’

Diagram Deployment dan Component






Component adalah sebuah code module
(kode-kode module).
Diagram Component merupakan fisik
sebenarnya dari diagram Class.
Diagram Deployment menerangkan
tentang konfigurasi fisik software dan
hardware.

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

Gambar 10. Contoh Diagram Deployment ‘Sistem
Real Estate’

Diagram Deployment dan Component


Fisik hardware berbentuk seperti nodenode. Setiap komponen merupakan
bagian dari node. Pada gambar
komponen berbentuk dua kotak tersusun
yang terletak di sebelah kiri atas.

NEXT
27 Juli Pertemuan 13-14 : Pengujian
Software
1 Agustus : Presentasi Perancangan
Software
3 Agustus : Presentasi Pengujian
software
8 Agustus : UAS