Pertemuan 9

PRINSIP DAN KONSEP DESAIN

Pokok Bahasan dalam RPL :

Desain PL dan Rekayasa PL

Prinsip Desain

Konsep Desain

Desain Modular Afektif

Model Desain

Dokumentasi Desain

Buku Referensi :
Pressman, RS., 2008, Software
Engineering: A Practitioners Approach,
New York: McGraw-Hill
Sommerville, I, 2007, Software
Engineering, Addsion Wesley

TUJUAN PRINSIP DAN KONSEP DESAIN

Memahami konsep dan prinsip desain PL
Mengerti desain secara modular dapat mengurangi
kompleksitas program dan mudah dimplementasikan
Memahami model desain
Membuat dan mengetahui isi dari dokumentasi

DESAIN PL DAN REKAYASA PL

Hal yang harus diperhatikan :
Desain Data
Transformasi model domain informasi ke dalam struktur data. Obyek dan
hubungan data ditetapkan dalam ERD, isi data detail digambarkan dalam kamus
data.
Desain Arsitektur
Menentukan hubungan antara elemen struktur utama dari program.
Desain Interface
Bagaimana PL berkomunikasi dalam dirinya sendiri, dengan sistem dan
manusia. Interface mengimplikasikan aliran informasi, data dan diagram aliran
kontrol memberikan informasi yang dibutuhkan bagi desain interface.
Desain Prosedural
Mentransformasikan elemen struktural dari arsitektur program ke dalam suatu
deskripsi prosedural dari komponen PL. Informasi yang diperoleh dari PSPEC,
CSPEC dan STD berfungsi sebagai dasar bagi desain prosedural.

DESAIN PL DAN REKAYASA PL (lanjutan)

PROSES DESAIN
Desain dan Kualitas
Desain
harus
mengimplementasikan
semua
kebutuhan eksplisit yang ada dalam model analisis,
dan dia harus mengakomodasi semua kebutuhan
implisit yang diinginkan oleh konsumen.
Desain harus dapat berupa panduan yang dapat
dibaca dan dipahami oleh orang-orang yang akan
membuat kode, dan mereka yang menguji serta
nantinya mendukung PL tersebut.
Desain harus menyediakan gambaran utuh dari PL,
menggambarkan domain data, fungsional, dan
perilaku dari perspektif implementasi.

Panduan Kualitas
Sebuah desain harus menampilkan arsitektur yang
1. Dibuat menggunakan pola atau style arsitektural yang sudah
dikenal,
2. Terdiri dari komponen-komponen yang menunjukkan karakteristik
desain yang baik dan
3. Dapat diimplementasi dalam bentul yang evolusioner.
Untuk sistem yang lebih kecil, desain kadang dapat
dikembangkan secara linear.
Sebuah desain harus berbentuk modular; oleh karena itu PL harus
secara logis dipartisi menjadi beberapa elemen subsistem
Sebuah desain harus berisi representasi yang berbeda dari data
,arsitektur, antarmuka, dan komponen.

Panduan Kualitas (lanjutan)

Sebuah desain harus menuju struktur data yang tepat untuk classclass yang akan diimplementasi dan digambar dari pola data yang
dikenal.
Sebuah desain harus menuju komponen-komponen yang
menunjukkan karakteristik fungsional yang dindpeneden.
Sebuah desain harus menuju antarmuka yang mengurangi
kompleksitas koneksi antara kompoenen-komponen dan dengan
lingkungan eksternal.
Sebuah desain harus diturunkan menggunakan method berulang
yang diatur oleh informasi yang disebut selama analisis kebutuhan
PL.
Desain harus direpresentasikan menggunakan notasi yang secara
efektif mengkomunikasikan maknanya.

Evolusi Desain PL
Karakteristik Umuj :
1. Mekanisme penerjemahan suatu model analisis ke
dalam representasi desain.
2. Notasi untuk merepresentasikan komponen-komponen
fungsional dan interfacenya.
3. Heuristik bagi penyaringan dan partisi.
4. Pedoman bagi penilaian kualitas.

PRINSIP DESAIN
Menurut Davis :
Proses desain tidak boleh berjalan dengan kacamata
kuda
Proses desain harus bisa dirujuk dari model analisis.
Proses desain tidak boleh mengulang penemuanpenemuan dasar.
Desain harus dapat meminimalkan jarak intelektual
antara PL dan permasalah yang ada di dunia nyata.
Desain harus menampakkan keseragaman dan
integrasi.

PRINSIP DESAIN (lanjutan)

Desain harus terstruktur untuk mengakomodasi
perubahan.
Desain harus terstruktur untuk turun secara
bertahap, walaupun ketika data, event, atau kondisi
operasi yang menyimpang ditemui.
Desain bukan coding dan coding bukan desain.
Desain harus dapat dipantau kualitasnya mulai dari
dia dibuat, bukan setelah jadi.
Desain harus direview untuk meminimalkan
kesalahan semantik (konseptual).

KONSEP KONSEP DESAIN

Konsep desain PL fundamental memberikan kerangka kerja untuk
mendapatkan program yang berfungsi dengan benar.
Konsep Dasar :
abstraksidata, prosedur, kontrol
arsitekturStruktur keseluruhan PL
Patterns/polamemuat esensi dari solusi desain yang sudah
terbukti
modularitasPembagian data dan fungsi
menyembunyikaninterface terkendali
Independensi fungsisingle-minded function dan low coupling
refinementelaborasi detail dari semua abstraksi
Refactoringsebuah teknik reorganisasi yang menyederhanakan
desain

Abstraksi Data

Abstraksi Prosedur

Penyaringan
Penyaringan Stepwise adalah strategi desain top down yang
diusulkan ole Wiklaus Wirth.
Penyaringan sebenarnya adalah proses elaborasi . Dimulai
dengan suatu statemen fungsi pada suatu tingkat abstraksi
tinggi.
Statemen fungsi adalah statemen yang menggambarkan
fungsi atau informasi secara konseptual.
Penyaringan membantu desainer untuk mengungkapkan
detail tingkat rendah ketika desain berjalan.

Modularitas
Meyer : 5 kriteria mengevaluasi metode
desain
1. Dekomposabilitas Modular
2. Komposabilitas Modular
3. Kemampuan Pemahaman Modular
4. Kontinuitas Modular
5. Ptoreksi Modular

Arsitektur PL
Shaw dan Garlan : sekumpulan properti sebagai bagian dari
desain arsitektural :
1. Properti Struktural
spek representasi desain arsitektur ini menentukan
komponen-komponen sebuah sistem (mis: modul, objek,
filter), dan pola komponen-komponen tersebut dipaket dan
berinteraksi satu dengan yang lain. Sebagai contoh: objek
dipaket untuk enkapsulasi baik data dan proses yang
memanipulasi data dan berinteraksi dengan invokasi method

Arsitektur PL (lanjutan)
2. Properti Ekstra Fungsional
Deskripsi desain arsitektur harus menggambarkan
bagaimana arsitektur mencapai kebutuhan kinerja,
kapasitas, reliabilitas, keamanan, adaptabilitas, dan
karakteristik sistem yang lain.
3. Keluarga dari sistem yang berhubungan
Desain arsitektur harus dapat menggambar pola-pola yang
diulang, yang secara umum ditemukan dalam disain keluarga
atau sistem yang mirip. Esensinya, desain harus mempunyai
kemampuan untuk menggunakan kembali blok-blok
bangunan arsitektur.

Patern / Pola
Design Pattern Template
Nama Patternmenggambarkan esensi pattern dalam nama yang
singkat tapi ekspresif Intent/Tujuanmenjelaskan pattern dan apa
yang dilakukan
Juga dikenal sebagai/Also-known-asDaftar sinonim untuk pattern
terkait
Motivation/Motivasimenyediakan contoh masalah
Aplikabilitasmenjelaskan situasi desain spesifik dimana pattern
dapat diterapkan
Strukturmenggambarkan class yang dibutuhkan untuk implementasi
pattern
Participantsmenggambarkan tanggungjawab class-class yang
diperlukan untuk mengimplementasikan pattern
Collaborationsmenggambarkan bagaimana participan berkolaborasi
untuk memikul tanggung jwabanya.
Konsekuensimenggambarkan pengaruh desain terhadap pattern
dan potensi masalah yang harus diperhatikan ketika pattern
diimplementasi.
Related patternsrelasi referensi silang design patterns

Hierarki Kontrol
Disebut juga struktur program.
Yang paling umum digunakan adalah diagram pohon
Depth dan width mengindikasikan jumlah modul yang dikontrol dan
rentang keseluruan kontrol
Fan-out pengukuran jumlah modul yang dikontrol secara langsung
oleh modul yang lain.
Fan-in mengindikasikan berapa banyak modul yang secara langsung
mengontrol sebuah modul yang diberikan.
Hubnugan kontrol diantara kontrol :
Superordinat (modul yang mengontrol modul lain).
Subordinat (modul yang dikontrol modul lain
Visibilitas (komponen program yang dapat dipakai sebagai data oleh
komponen lainnya)
Konektivitas (Komponen yang dipakai secara tidak langsung oleh
sebuah modul yang ditetapkan)

Hierarki Kontrol (lanjutan)

Partisi Struktural
Partisi Vertikal
Didesain sehingga pengambilan keputusan dan pekerjaan
distratifikasi
Modul pengambilan keputusan tetap ada di puncak arsitektur
decision--makers
decision

workers

Partisi Struktural (lanjutan)

Partisi Horizontal
Tentukan cabang yang terpisah pada hierarki modul untuk
setiap fungsi utama
Gunakan modul kontrol untuk koodinasi komunikasi antar
fungsi2x
function 3

function 1

function 2

Struktur Data

Struktur Data menentukan :

Organisasi dan kompleksitas
Item Skalar
Metode akses
Vektor Sekuensial

DESAIN MODULAR AFEKTIF

Mudah untuk dibangun, mudah untuk dirubah dan mudah untuk ditetapkan

Modularitas
Berapakah jumlah modul yang pas untuk desainPL tertentu?

Penyembunyian Informasi

Mengapa Informasi disembunyikan?

Mengurangi efek samping
Membatasi pengaruh global dari keputusan
desain lokal
Menekankan komunikasi melalui interface yang
terkendali
Mengurangi penggunaan data global
Merujuk pada enkapsulasisebuah atribut dari
desain kualitas tinggi
Menghasilkan PL dengan kualitas tinggi

Langkah-langkah Refinement

Indepedensi Fungsi
Kohesi
Suatu ekstensi natural dari konsep penyembunyian informasi
Kohesif Koisidental
Modul yang melakukan serangkaian tugas yang saling
berhubungan secara lepas.
Kohesif secara Logis
Modul yang melakukan tugas-tugas yang berhubungan secara
logis.
Kohesif Temporal
Modul berisi tugas-tugas yang berhubungan dengan kenyataan
bahwa semua harus dieksekusi dalam jangkauan waktu yang
sama.

Indepedensi Fungsi (lanjutan)

Modul melakukan tugas :
1. Menghitung data suplemen yang didasarkan pada data yang
dihitung secara orisinil.
2. Menghasilkan laporan kesalahan pada workstation pemakai.
3. Melakukan kalkulasi follow up yang diminta oleh pemakai.
4. Memperbaharui basis data.
5. Memungkinkan pemilian menu untuk pemesanan berikutnya.
Kohesif Prosedural
Elemen pemrosesan dari suatu modul dihubungkan dan harus
dieksekusi dalam suatu urutan yang spesifik.
Kohesi Komunikasional
Semua elemen pemrosesan berkonsentrasi pada satu area dari
suatu struktur data.

Perangkaian
Perangkaian :
Pengukuran interkoneksi diantara modul-modul pada sebuah
struktur program
Heuristik Desain
1. Evaluasi iterasi pertama dari struktur program untuk
mengurangi perangkaian dan meningkatkan kohesi.
2. Usahakan meminimalkan struktur dengan fan-out yang
tinggi ; usahakan untuk melakukan fan-in pada saat
kedalaman bertambah.
3. Jaga lingkup efek dari suatu modul ada dalam lingkup kontrol
dari modul itu.
4. Evaluasi interface modul untuk mengurangi kompleksitas
dan redudansi dan meningkatkan konsistensi

Perangkaian (lanjutan)
5. Tetapkan modul-modul yang fungsinya dapat diprediksi,
tetapi hindari modul yang terlalu restriktif.
6. Usahakan modulmodul entri terkontrol menghindari
hubungan patologisdengan
7. Kemaslah PL berdasarkan batasan desain dan persyaratan.

MODEL DESAIN
Direpresentasikan sebagai sebuah piramid.
Konsep Desain OO
Desain Class
Entity classes
Boundary classes
Controller classes
Inheritancesemua tanggung jawab superclass akan diwarisi
oleh semua subclassnya
Messagesstimulasi beberapa perilaku yang dapat terjadi
pada objek penerima pesan
Polymorphismsebuah karakteristik yang mengurangi usaha
yang dibutuhkan untuk memperluas desain

DESAIN CLASS
Analisis class disempurnakan dalam desain untuk menjadi
class-class entitas
Class-class boundary dikembangkan selama desain untuk
membuat interface(mis. Layar interaktif atau laporan cetak)
yang dilihat pengguna dan berinteraksi.
- Class-class boundary didesain dengan tanggungjawab untuk
mengelola cara objek entitas ditampilkan kepada user.
Class-class control didesain untuk mengelola :
- Pembuatan atau perubahan objek entitas;
- nstansiasi object boundary dengan mengambil informasi
dari objek entitas;
- Komunikasi kompleks antara sekelompok objek;
- Validasi data yang dikomunikasikan antar objek atau antar
pengguna dan aplikasi.

Inheritance
Pilihan-pilihan desain :
- Class dapat didesain dan dibangun dari nol. Jika demikian,
inheritance tidak digunakan.
- Hierarki class dapat dicari untuk mencari kemungkinan jika
sebuah class yang lebih tinggi pada hierarki (superclass)
memiliki atribut-atribut dan operasi-operasi yang paling
banyak dibutuhkan. Class baru ini diturunkan dari superclass
dan beberapa tambahan dapat diberikan jika dibutuhkan.
- Hierarki class dapat di restrukturisasi sehingga atributatribut dan operasi-operasi yang dibutuhkan dan diturunkan
oleh class baru tersebut.
- Karakteristik dari class yang sudah ada dapat di override dan
atribut-atribut dan operasi-operasi dengan versi berbeda
dapat diimplementasikan untuk class baru tersebut.

Message

Polymorphism
Pendekatan konvensional
case of graphtype:
if graphtype = linegraph then DrawLineGraph (data);
if graphtype = piechart then DrawPieChart (data);
if graphtype = histogram then DrawHisto (data);
if graphtype = kiviat then DrawKiviat (data);
end case;
Semua graphs menjadi subclass dari class umum yang disebut
graph. Menggunakan konsep over loading, setiap subclass
mendefinisikan operasi yang disebut draw. Sebuah object
dapat mengirim pesan draw pada salah satu instansiasi objek
dari salah satu subclassnya. Objek yang menerima message
akan menjalankan operasi draw nya sendriri untuk membuat
graph yang sesuai..

Model Desain

Elemen Model Desain

Elemen-elemen Data
Data model --> struktur data
Data model --> arsitektur database
Elemen-elemen arsitektur
Domain aplikasi
Class-class analisis, relasinya, kolaborasi dan perilaku diubah menjadi
realisasi desain
Patterns dam styles (Chapter 10)
Elemen-elemen interface
user interface (UI)
Interface external pada sistem lain, piranti-piranti, jaringan-jaringan
atau produsen maupun konsumen informasi lainnya
Interface internal antara komponen-komponen desain.
Elemen-elemen komponen
Elemen-elemen deploy

Elemen Interface

Elemen Komponen

Elemen Deployment

Design Pattern
Desainer terbaik di segala bidang tetap mempunyai keterbatasan
untuk melihat pola yang mencirikan sebuah masalah dan
menghubungkannya dengan pola yang dapat dikombinasikan untuk
membuat solusi
Sebuah deskripsi dari design pattern dapat juga dilihat sebagai
sekumpulan design forces.
Design forcesmenjelaskan kebutuhan non fungsional (misalkan
:
kemudahan perawatan, portabilitas) yang dihubungkan
dengan PL
dimana pattern akan diaplikasikan.
Karakteristik pattern (class, tanggungjawab, dan kolaborasi)
mengindikasikan atribut-atrobit desain yang harus diatur untuk
memungkinkan pattern mengakomodasi permasalahan yang
bervariasi

Frameworks
Sebuah framework bukan merupakan pattern
arsitektur, namun lebih merupakan kerangka dengan
sekumpulan plug points (yang juga disebut
hooksdan slots) yang memungkinkannya untuk
beradaptasi dengan domain permasalahan tertentu.
Gamma et al mencatat bahwa:
Design patterns lebih abstrak dari frameworks.
Design patterns adalah elemen-elemen
arsitektural yang
lebih kecil daripada frameworks
Design patterns lebih umum daripada
frameworks

DOKUMENTASI DESAIN
Ruang lingkup
a. sasaran sistem
b. persyaratan utama PL
c. batasan dan pembatasan desain
Desain Data
a. Obyek dan struktur data resultan
b. Struktur file dan database
1. struktur file eksternal
2. data global
a. struktur logis
b. deskripsi record logis
c. metode akses
3. file dan referensi lintas data

DOKUMENTASI DESAIN (lanjutan)

Desain arsitektural
a. Kajian data dan aliran kontrol
b. Struktur program yang diperoleh
Desain interface
a. Spesifikasi interfacde manusia mesin
b. Aturan desain interface manusia mesin
c. Desain interface eksternal
1. Interface untuk data eksternal
2. Interface untuk sistem atau peralatan eksternal
Desain prosedural
Untuk masing-masing model
a. Naratif pemrosesan
b. Deskripsi interface
c. Deskripsi bahasa (atau lainnya) desain

DOKUMENTASI DESAIN (lanjutan)

c. Deskripsi bahasa (atau lainnya) desain
d. Modul yang digunakan
e. Struktur data internal
f. Keterangan / larangan / pembatasan
Persyaratan lintas referensi
Ketentuan Pengujian
Panduan pengujian
Strategi integrasi
Pertimbangan khusus

Catatan Khusus
Lampiran

Pertemuan 10
METODE DESAIN (1)

Pokok Bahasan dalam RPL :

Desain Data

Desain Arsitektur

Proses Desain Arsitektur

Pasca Pemrosesan Desain

Optimasi Desain Arsitektur

Buku Referensi :
Pressman, RS., 2008, Software
Engineering: A Practitioners Approach,
New York: McGraw-Hill
Sommerville, I, 2007, Software
Engineering, Addsion Wesley

Tujuan Metode Desain

Menjelaskan maksud dari arsitektur PL dan
kenapa sangat penting.
Memhami model data, struktur data,
database, data warehouse, desain data pada
level komponen

DESAIN DATA

1.
2.
3.
4.
5.
6.
7.

Aktivitas pertama (dan beberapa sering mengatakan yang terpenting) dari 4

aktivitas desain yang dilakukan selama RPL.
Prinsip-prinsip :
Prinsip analisis sistematik yang diaplikasikan pada fungsi dan perilaku seharusnya
diaplikasikan juga pada data.
Semua struktur data dan operasi yang dilakukan pada masing-masing struktur
data harus diidentifikasi.
Kamus data harus dibangun dan digunakan untuk menentukan baik data
maupun desain program.
Keputusan desain data tingkat rendah harus ditunda sampai akhir proses desain.
Representasi stuktur data hanya boleh diketahui oleh modul-modul yang harus
menggunakan secara langsung data yang diisikan didalam struktur terseb ut.
Pustaka struktur data dan operasi yang berguna yang dapat diaplikasikan pada
struktur data tersebut harus dikembangan.
Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi
dari tipe-tipe data absktrak.

DESAIN ARSITEKTUR
Untuk mengembangkan struktur program modular dan
merepresentasikan hubungan kontrol antar modul.
Membentuk struktur program dan struktur data dengan
menentukan interface yang memungkinkan data mengalir
melalui program.
Kontributor
Perintis desain PL yang didasarkan pada aliran data melalui
sebuah sistem.
Area Aplikasi
luasnya aplikasi dimana aplikasi dapat diaplikasikan.

PROSES DESAIN ARSITEKTUR

Langkahnya :
1. Tipe aliran informasi dibangun
2. Batas aliran diindikasikan.
3. DFD dipetakan kedalam struktur program.
4. Hierarki kontrol ditentukan dengan
pemfaktoran.
5. Struktur resultan disaring/diperhalus dengan
menggunakan pengukuran desain dan
heuristik.

PROSES DESAIN ARSITEKTUR (lanjutan)

Aliran Transformasi
Keseluruhan aliran data terjadi dalam cara yang berurutan
dan mengikuti satu atau hanya beberapa jalur garis lurus,
bila segmen dari aliran data menunjukkan karakteristik
tersebut, maka disitu ada aliran transformasi.
Aliran transaksi
Ditandai dengan pergerakan data sepanjang jalur masuk yang
mengkonversikan informasi dunia eksternal ke dalam suatu
transaksi.

Karakteristik Aliran

PEMETAAN TRANSFORMASI
Serangkaian langkah desain yang mengijinkan sebuah DFD dengan
karakteristik aliran transformasi untuk dipetakan ke dalam tempalte yang
telah ditentukan untuk struktur program.
Langkah-langkah :
1. Kaji model sistem fundamental.
2. Kaji dan saring diagram aliran data untuk PL.
3. Tentukan apakah DFD memiliki karakteristik aliran transformasi atau
transaksi.
4. Isolasi pusat transformasi dengan mengkhususkan batas aliran masuk
dan keluar.
5. Lakukan pemfaktoran tingkat pertama.
6. Lakukan pemfaktoran tingkat kedua.
7. Saringlah struktur program iterasi pertama dengan menggunakan
heuristik desain bagi kualitas perangkat lunak yang telah ditingkatkan.

PEMETAAN TRANSFORMASI (LANJUTAN)

b
d

data flow model

x1
x2
b

x4

x3
c

"Transform" mapping

PEMETAAN TRANSAKSI
Langkah-langkah desain :
1. Kaji model sistem fundamental.
2. Kaji dan saring diagram aliran data untuk PL.
3. Tentukan apakah DFD memiliki karakteristik aliran
transformasi atau transaksi.
4. Identifikasi pusat transaksi dan karakteristik aliran sepanjang
masing-masing jalur aksi.
5. Petakan DFD pada sebuah struktur program yang sesuai
dengan pemrosesan transaksi.
6. Faktorkan dan saringkan struktur transaksi dan struktur
masing-masing jalur aksi.
7. Saring struktur program iterasi pertama dengan menggunakan
heuristik desian untuk kualitas PL yng dikembangkan.

PEMETAAN TRANSAKSI (lanjutan)

Program
Architecture

PASCA PEMROSESAN DESAIN

Tugas yang harus dilakukan :
Mengembangkan narasi pemrosesn untuk masingmasing modul.
Menyediakan deskripsi interface untuk masingmasing modul.
Menentukan struktur data lokal dan global.
Mencatat semua batasan desain.
Mengkaji desain.
Mempertimbangkan optimasi (bila diperlukan dan
dibenarkan).

OPTIMASI DESAIN ARSITEKTUR

Pendekatan :
1. Kembangkan dan saring struktur program tanpa memperatikan
optimasi kinerja-kritis.
2. Gunakan Peranti CASE yang mensimulasi kinerja run-time untuk
mengisolasi area inefisiensi.
3. Selama iterasi desain selanjutnya, pilihlan judul yang dicurigai
time-hot dan dengan hati-hati kembangkanlah prosedur
(algoritma) untuk efisiensi waktu.
4. Kodekan sebuah bahasa pemrograman yang sesuai.
5. Instrumentasikan PL untuk mengisolasi modul yang menjelaskan
utilisasi proses yang berat.
6. Bila perlu, desain ulang atau kodekan kembali bahasa yang
tergantung pada mesin untuk meningkatkan efisiensi.

Pertemuan 11
METODE DESAIN (2)

Pokok Bahasan dalam RPL :

Desain Interface

Desain Interface Manusia Mesin

Desain Prosedural

Coding

Buku Referensi :
Pressman, RS., 2008, Software
Engineering: A Practitioners Approach,
New York: McGraw-Hill
Sommerville, I, 2007, Software
Engineering, Addsion Wesley

Tujuan Metode Desain

Menjelaskan maksud dari arsitektur PL dan
kenapa sangat penting.
Memhami model data, struktur data,
database, data warehouse, desain data pada
level komponen

DESAIN INTERFACE
Memfokuskan diri pada 3 area perhatian :
1. Desain interface antara modul-modul PL.
2. Desain interface antara PL dan prosedur dan konsumen informasi, bukan
manusia lainnya (yakni entitas eksternal lainnya).
3. Desain interface antara seorang manusia (user) dan komputer.
Desain interface pemakai internal
(desain interface inter-modular) dikendalikan oleh data yang harus
mengalir diantara modul-modul dan karakteristik bahasa pemrograman
dimana PL akan diimplementasikan.
Desain interface pemakai eksternal
Dimulai dengan evaluasi terhadap masing-masing entitas eksternal yang
direpresentasikan pada DFD model analisis.
Desain Interface Pemakai
Berkaitan dengan studi terhadap manusia juga terhadap isu-isu teknologi

DESAIN INTERFACE MANUSIA MESIN

Dimulai dengan membuat model-model fungsi sistem yang
berbeda-beda. Kemudian digambarkan tugas yang
berorientasi pada manusia dan komputer yang dibutuhkan
untuk mencapai fungsi sistem.
Model-Model Desain Interface
1. Model Desain
Menggabungkan data, arsitektur, interface, dan representasi
prosedural dari PL
1. Model Pemakai
2. Persepsi Sistem
3. Cara Sistem

DESAIN INTERFACE MANUSIA MESIN (lanjutan)

2. Model Pemakai
Menggambarkan para pemakai akhir dari sistem, meliputi
profil, usia, jenis kelamin, kemampuan fisik, pendidikan, latar
belakang etnis dan kultural, motivasi, tujuan dan
kepribadian.
3. Persepsi Sistem
Citra sistem yang ada dikepala seorang pemakai akhir.
4. Cara Sistem
merangkai manifestasi bagian luar dari sistem berbasis
komputer, dengan semua informasi yang mendukung, yang
menggambarkan siteksis dan semantik sistem.

DESAIN INTERFACE MANUSIA MESIN (lanjutan)

Pemodelan dan Analisis Tugas
Proses desain interface :
1. Tentukan tujuan untuk tugas.
2. Petakan tujuan untuk serangkaian aksi khusus.
3. Tentukan urutan aksi saat tindakan akan dieksekusi pada
tingkat interface.
4. Indikasikan keadaan sistem.
5. Tentukan mekanisme kontrol.
6. Perlihatkan bagaimana mekanisme kontrol mempengaruhi
keadaan sistem.
7. Indikasikan bagaimana pemakai menginterpretasi keadaan
sistem dari informasi yang diberikan melalui interface.

DESAIN INTERFACE MANUSIA MESIN (lanjutan)

Masalah desain :
1. Apakah help dapat diperoleh untuk semua fungsi sistem .
2. Bagaimana pemakai memperoleh help
3. Bagaimanan help akan direpresentasikan
4. Bagaimana pemakai kembali ke interaksi normal.
5. Bagaimana informasi help distruktur.

DESAIN INTERFACE MANUSIA MESIN (lanjutan)

Peranti Implementasi
User Interface Development :
- Mengatur perangkat input (mouse / keyboard)
- Menvalidasi input pemakai.
- Menangani kesalahan dan menampilkan pesan kesalahan.
- Memberikan umpan balik.
- Menyediakan help dan promt.
- Penanganan jendela dan field, scrolling paa jendela.
- Membangun koneksi antara PL aplikasi dan interface.
- Mengisolasi aplikasi dari fungsimanajemen interface.
- Memungkinkan pemakai mengkostumasi interface.

DESAIN INTERFACE MANUSIA MESIN (lanjutan)

Evaluasi Desain
- Panjang dan kompleksitas spesifikasi tertulis dari sistem dan
interfacenya, mengindikasikan jumlah waktu belajar yang
dibutuhkan para pemakai sistem.
- Jumlah perintah atau aksi yang ditentukan dan jumlah ratarata argumen per perintah atau operasi individual per aksi,
megindikasikan waktu interaksi dan efisiensi keseluruhan
dari sistem tersebut.
- Jumlah aksi, perintah, dan keadaan sistem yang diindikasikan
oleh model desain, menunjukkan beban memori pada
pemakai sistem.
- Gaya interface, fasilitas help dan protokol penanganan
kesalaan memberikan suatu indikasi umum mengenai
komplesitas interface dan tingkat dimana interface akan
diterima oleh pemakai.

DESAIN INTERFACE MANUSIA MESIN (lanjutan)

-

Siklus evaluasi desain

Desain
Permulaaan

Membuat
Prototipe
Interface #n

Pemakai
mengevaluasi
interface

Modifikasi
desain
dilakukan

Desain Interface dilengkapi

Membuat
Prototipe
Interface #1

Evaluasi
dipelajari oleh
desainer

PEDOMAN DESAIN INTERFACE

1. Interaksi Umum
- Konsisten
- berikan umpan balik
- Verifikasi terhadap aksi destruktif yang signifikan.
- kemudahan pembatalan sebagian besar aksi.
- kurangi jumlah informasi yang harus diingat diantara aksiaksi.
- Adanya efisiensi dalam dialog, gerakan dan pemikiran.
- Memaafkan kesalahan
- Kategorikn aktivitas menurut fungsidan atur geografi layar.
- Sediakan fasilitas elp yang sensitif.
- Gunakan verbal aksi yang sederana untuk menerima
perintah.

PEDOMAN DESAIN INTERFACE (LANJUTAN)

2. Tampilan Informasi










Hanya menampilkan informasi yang relevan dengan konteks yang ada.

Jangan membanjiri pemakai dengan data.
Gunakan label yang konsisten, penyingkatan standar dan warna yang
dapat diprediksi.
Ijinkan pemakai untuk memelihara konteks visual.
Hasilkan pesan kesalahan yang berarti.
Gunakan huruf besar dan kecil, identasi dan pengelompokkan teks untuk
membantu pemahamannggolongkan tipe informasi
Gunakan jendela untuk mengolongkan tipe informasi yang berbeda.
Gunakan tampilan analog untuk merepresentasikan informasi yang
lebih mudah diasimilasikan dengan bentuk representasi ini.
Pertimbangkan ketersediaan gfeografi layar tampilandan gunakan secara
efisien.

PEDOMAN DESAIN INTERFACE (LANJUTAN)

3. Input Data









Minimalkan jumlah aksi input yang dibutuhkan dari pemakai.

Jaga konsistensi diantara tampilan informasi dan input data.
Ijinkan pemakai mengkustomasi input.
Interaksi harus fleksibel, tetapi juga diatur ke mode input yang disukai
pemakai.
Nonaktifkan perintah yang tidak sesuai di dalam konteks aksi yang
sedang berlangsung.
Biarkan pemakai mengontrol aliran interkatif.
Sediakan help untuk membantu semua aksi input.
Hilangkan input mickey mouse.

DESAIN PROSEDURAL
Terjadi setelah data, desain arsitektur dan interface
dibangun.
Pemrograman Terstruktur
Urutan
(langkah pemrosesan yang penting dalam spesifikasi
sembarang algoritma).
Kondisi
(fasilitas bagi pemrosesan yang dipilih berdasarkan beberapa
kejadian logis).
Pengulangan
(menyediakan looping)

DESAIN PROSEDURAL (lanjutan)

Notasi Desain Grafis
Peranti grafis memberikan bentuk gambar yang bagus yang
telah menggambarkan detail prosedural.
Bagan Alir merupakan representasi grafis yang paling luas
dipakai.
Notasi Desain Berbentuk Tabel
Tabel keputusan memberikan sebuah notasi yang
menerjemahkan aksi-aksi dan kondisi ke dalam bentuk tabel.

DESAIN PROSEDURAL (lanjutan)

Langkah untuk mengembangkan tabel keputusan :
1. Daftarkan semua aksi yang dapat diasosiasikan dengan
sebuah prosedur tertentu (atau modul).
2. Daftarkan semua kondisi (atau keputusan yang dibuat)
selama eksekusi prosedur.
3. Hubungkan serangkaian kondisi tertentu dengan aksi
tertentu, dengan mengeliminasi kombinasi dari kondisi yang
mungkin.
4. Tentukan aturan-aturan dengan menunjukkan aksi, apa yang
terjadi bagi serangkaian kondisi.

DESAIN PROSEDURAL (lanjutan)

Baasa Desain Program (PDL) atau pseudocode :
bahasa pasar yang menggunakan kosakata dari satu bahasa
dan keseluruhan sintaks dari yang lain.
Karakteristik bahasa desain :
1. Sintalks kata kunci (keyword) tersedia untuk semua gagasan
terstruktur, deklarasi data dan karakteristik modularitas.
2. Sintaks bebas dari bahasa natural yang menggambarkan ciriciri pemrosesan.
3. Fasilitas deklarasi data yang harus meliputi struktur data
kompleks (linked list) dan sederhana (skalar, array).
4. Definisi subprogram dan teknik pemanggilan yang
mendukung berbagai mode deskripsi interface.

CODING

Pertemuan 12

IMPLEMENTASI

POKOK BAHASAN

Makna & Tujuan Implementasi

Perencanaan Implementasi

Hal Penting Dalam Implementasi

Persiapan Dokumentasi

Pemasangan Atau Konversi Sistem Baru Ke Sistem Lama

Evaluasi Sistem Baru

Lingkungan Pemrograman

Programming Style

Prinsip Portability & Reusable (Kemudahan & Penggunaan

Ulang Komponen)

CASE Tools

Makna & Tujuan Implementasi (1)

 Tahap implementasi merupakan tahap besar di akhir
produksi PL
 Tahap ini merupakan proses pembuatan kode program
dalam bahasa pemrograman tertentu sesuai dengan
platform dan kesepakatan dengan customer.
 Merupakan tahap transformasi dari hasil desain ke
dalam program yang dpt dijalankan pada komputer
yang akan digunakan di dalam sistem.
 Baik buruknya implementasi sangat tergantung pada
baik buruknya hasil final dari tahap desain

Makna & Tujuan Implementasi (2)

 Melibatkan
pengintegrasian
semua
komponen
rancangan sistem termasuk PL, konversi ke sistem
operasi.
 Proses implementasi melibatkan:
 Perencanaan
 Pengeksekusian

Rencana Implementasi (1)

Rencana ini merupakan formulasi rinci dan
representasi grafik mengenai cara pencapaian
implementasian sistem yang akan dilaksanakan
(tergantung pada kompleksitas proyek)

Tim implementasi yg terlibat:

Manajer dan beberapa staff

Profesional sistem yang merancang sistem

Perwakilan Vendor

Pemakai Primer

Pengcode/programmer

Teknisi

Contoh Rencana Implementasi

Hal Penting Dalam Implementasi

1. Persiapan Tempat

Diperlukan dokumentasi, yang perlu dipersiapkan :
 Ruang (sesuai dengan platform teknologi yang
akan digunakan Micro, mini atau mainframe)
 Listrik, telepon, koneksi lainnya, ventilasi, AC,
keset anti debu, karpet, rak, penyangga barang,
meja, penyimpan disk/pita, lemari kabinet, tempat
personil, lokasi printer, dudukan printer, dan
furniture lain yg dirancang secara ergonomis
 Pengujian burn in (simulasi operasi pd vendor)

Hal Penting Dalam Implementasi (2)

2. Pelatihan Personil
 Tdk ada sistem yang bekerja secara memuaskan
jika para pemakai dan orang lain yang berinteraksi
dengan sistem tersebut tidak dilatih secara benar
 Pelatihan personil tidak hanya meningkatkan
keahlian/ketrampilan
pemakai,
namun
juga
memudahkan penerimaan mereka terhadap sistem
baru
 Pelatihan
meningkatkan
kepercayaan
diri,
meminimalkan sesi kesalahan, kerusakan pada
tahap awal.

Hal Penting Dalam Implementasi (3)

 Sasaran pelatihan:
1. Personil teknis yang akan mengoperasikan dan
memelihara sistem tersebut.
2. Berbagai pekerja dan supervisor yang akan berinteraksi
langsung dengan sistem untuk mengerjakan tugas dan
membuat keputusan
3. Manajer umum
4. Pihak luar yang berinteraksi dengan sistem
3. Cakupan Pelatihan:
 Tutorial, mengajarkan cara menjalankan sampai pelatihan
untuk mengajarkan pokok2 sistem baru

Hal Penting Dalam Implementasi (4)

4. Program Pelatihan:
 Pelatihan in house
 Pelatihan yang disediakan oleh vendor
 Jasa pelatihan luar
5. Teknik dan Alat Bantu Pelatihan:
 Teleconferesi
 PL pelatihan interaktif
 Pelatihan dengan instruktur
 Pelatihan magang
 Manual prosedur
 Buku teks

Hal Penting Dalam Implementasi (5)

6. Software Untuk Pelatihan Interaktif:
 CBT (Computer-Based Training)
 ABT (Audio-Based Training)
 VBT (Video-Based Training)
 VOD (Video-Optical Disc)
7. Persiapan/Pembuatan Dokumen
 Dokumentasi adalah materi tertulis/video/audio yang
menjabarkan cara beroperasinya sebuah sistem,
termasuk pokok bahasan yang harus dikuasi oleh
pemakai.

Hal Penting Dalam Implementasi (6)

 Tujuan dokumentasi:
1. Pelatihan
2. Penginstruksian
3. Pengkomunikasian
4. Penetapan standar kinerja
5. Pemeliharaan sistem
6. Referensi historis
 Empat area utama dokumentasi:
1. Dokumen pemakai
2. Dokumen Sistem
3. Dokumen Perangkat lunak
4. Dokumen operasi

Hal Penting Dalam Implementasi (7)

Penjelasan
Tanpa dokumentasi yang jelas dan akurat
Pengembangan sistem

Hal Penting Dalam Implementasi (8)

8. Konversi File & Sistem
 Merupakan proses pengubahan dari sistem lama ke
sistem baru
 Kompleksitas dalam pengkonversian tergantung
pada beberapa faktor, yaitu :
 Jenis Perangkat Lunak
 Database
 HardWare
 Kendali
 Jaringan
 Prosedur

Hal Penting Dalam Implementasi (9)

 Metode konversi:
1. Konversi Langsung
Sistem yang lama langsung digantikan dengan sistem
yang baru
2. Konversi Paralel
Sistem lama masih dijalankan sambil menjalankan
sistem baru, jika sistem baru sudah dianggap stabil
maka sistem lama akan dihentikan
3. Konversi Phase-in
Sistem lama digantikan secara berangsur angsur sedikit
demi sedikit akhirnya sistem lama akan tergantikan
dengan sistem baru
4. Konversi Pilot
Dilakukan secara segmentasi bagian per bagian

Konversi ini baik dilakukan jika :

 Sistem baru tidak menggantikan sistem lama
 Sistem lama sepenuhnya tidak bernilai
 Sistem baru bersifat kecil/sederhana
 Rancangan sistem baru sangat berbeda dari sistem
lama

 Memberikan derajat proteksi yang tinggi dari kegagalan

sistem baru
 Biaya yang dibutuhkan cukup besar karena keduanya
harus jalan bersama-sama

 Sistem baru di implementasikan sedikit demi sedikit

untuk menggantikan sistem lama
 Sistem harus disegmentasi
 Perlu biaya tambahan utk membangun interface
temporer dg sistem lama
 Proses implementasi membutuhkan waktu yang
panjang

 Perlunya segmentasi organisasi

 Resiko lebih rendah dibandingkan metode konversi
langsung
 Biaya lebih rendah dibanding metode paralel
 Cocok digunakan apabila adanya perubahan prosedur,
HardWare, dan SoftWare

Konversi File Data

Keberhasilan konversi sistem sangat tergantung pada
seberapa jauh profesional sistem menyiapkan konversi
file data yang diperlukan di dalam sistem baru

Konversi/Modifikasi Meliputi:
 Format file
 Isi file
 Media penyimpanan

Metode Dasar Konversi:
1. Konversi File Total
Dpt digunakan pada ke-4 metode konversi sistem

Konversi File Data (2)

2. Konversi File Gradual
 Lebih banyak digunakan utk metode paralel dan
phase-in
 Selama konversi file perlu diperhatikan prosedur
kendali untuk memastikan integrasi data
 Prosedur kendali utk masing2 file berbeda
 Suatu transaksi diterima dan dimasukkan ke dalam
sistem
 Program mencari file master baru untuk record yang
akan diupdate oleh transaksi tsb.jika record tsb ada
maka pengupdatean record selesai

Konversi File Data (3)

2. Konversi File Gradual (Lanjutan)
 Jika record tidak ditemukan dalam file master baru, file
master lama diakses untuk record yang tepat, dan
ditambahkan pada file master baru dan diupdate
 Jika transaksi untuk record baru, record baru disiapkan
dan ditambahkan ke file master baru.

Klasifikasi file:
 File Master
 File Transaksi
 File Index
 File Tabel
 File Backup

Tahapan Implementasi
 Struktur dekomposisi, struktur data, dan identitas dipilih
dan di kerjakan sampai prosedur desain mudah untuk
ditata ulang dalam sebuah implementasi
 Level abstraksi pada desain, misal class, modul,
algoritma, struktur data, dan tipe data harus diwujudkan
dalam implementasi
 Antarmuka antara komponen sistem perangkat lunak
harus diwujudkan secara jelas pada tahap implementasi
 Kode program tersebut harus dapat di cek
konsistensinya pada setiap objek dan operasinya
secara langsung menggunakan kompilator.

Kriteria Lingkungan Pemrograman

1. Modularity (Modularitas)
Program dapat dibuat dalam bentuk modul2 yang lebih
kecil dan mudah dalam integrasinya
2. Dokumentasi Nilai Pada Bahasa Pemrograman
Dokumentasi mengenai penjelasan coding/komponen
yang digunakan
3. Struktur Data Dalam Bahasa Pemrograman
Ketersediaan struktur data yang kompleks akan
membantu mempermudah proses
4. Struktur Aliran Pengendali
Suatu kasus khusus melibatkan suatu pengujian kondisi
dan akan memberikan alternatif untuk dilaksanakan
sesuai kondisi yang ada

Kriteria Lingkungan Pemrograman (2)

5. Efisiensi
 Penulisan kode lebih singkat
 Pemakaian memori penyimpanan lebih kecil
 Hasil program dapat dijalankan dengan cepat
6. Integritas
Kemudahan dalam pembacaan dan mekanisme dalam
pengecekan tipe dan antarmodul
7. Portability (Multiplatform)
Bahasa pemrograman atau hasil programnya dapat
dijalankan di beberapa platform yang berbeda
8. Dukungan Dialog
Fasilitas interaktif dari program dengan lingkungan luar

Kriteria Lingkungan Pemrograman (3)

9. Quality
Kualitas kompilator sangat tergantung pada fitur-fitur
yang disediakan dan mampu mendukung kinerja
pembuataan koding yang bekualitas.
10. Ketersediaan Pustaka (Library)
Menyediakan pustaka/library
aplikasi yang kompleks

yang

bervariasi

11. Ketersediaan Tool Pembangunan

Semua peralatan terintegrasi dalam satu interface

untuk

Kriteria Lingkungan Pemrograman (4)

12. Kebijakan Instansi (Tim)
Pemilihan bahasa pemrograman ditentukan
institusi (tim) atau oleh penggunanya

oleh

13. Kebutuhan Eksternal

Adanya tambahan alat baru atau PL baru yang harus
terhubung dengannya

Programming Style

Menulis sebuah program adalah seni dan merupakan
proses yang kreatif

Gaya pemrograman pada programmer mempengaruhi
tingkat kemudahan pembacaan program yang dibuatnya

Buku Code Complete
Mengulas tuntas suatu gaya pemrograman bahkan di
dalamnya diberkan contoh variasi yang cukup banyak.

Gaya pemrograman yang baik sangat didukung dari tahap
desain dan perencanaan implementasi yang baik

PERTEMUAN 13
STRATEGI PENGUJIAN
PERANGKAT LUNAK

Strategi uji coba perangkat lunak dilakukan

untuk memudahkan para perancang untuk
menentukan keberhasilan system yang telah
dikerjakan

Proses Testing

Unit
Testing

Module
Testing

Component Testing

Sub-system
Testing

Integration Testing

System
Testing

Acceptance
Testing

User
Testing

Proses Testing

Unit testing
Pengujian masing-masing unit komponen program
untuk meyakinkan bahwa sudah beroperasi secara
benar

Module Testing
Pengujian terhadap koleksi unit-unit komponen yang
saling berhubungan.

Sub-system Testing
Pengujian terhadap koleksi module-module
membentuk suatu sub-system (aplikasi)

yang

Proses Testing

System Testing
Pengujian terhadap integrasi sub-system,
keterhubungan antar sub-system

yaitu

Acceptance Testing
 Pengujian terakhirs sebelum sistem dipakai oleh
user.
 Melibatkan pengujian dengan data dari pengguna
sistem.
 Biasa dikenal sebagai alpha test (beta test
untuk software komersial, dimana pengujian
dilakukan oleh potensial customer)

Rencana Pengujian

Proses testing
Deskripsi fase-fase utama dalam pengujian

Pelacakan Kebutuhan
Semua kebutuhan user diuji secara individu

Item yg diuji
Menspesifikasi komponen sistem yang diuji

Jadual Testing

Prosedur Pencatatan Hasil dan Prosedur

Kebutuhan akan Hardware dan Software

Kendala-kendala
Mis: kekuranga staff, alat, waktu dll.

Failure and Faults

 Failure: output yang tidak benar/tidak sesuai ketika
sistem dijalankan
 Fault: kesalahan dalam source code yang mungkin
menimbulkan failure ketika code yang fault tersebut
dijalankan

Prioritas Testing

Hanya test yang lengkap yang dapat meyakinkan
sistem terbebas dari kesalahan, tetapi hal ini sangat
sulit dilakukan.

Prioritas dilakukan terhadap pengujian kemampuan
sistem, bukan masing-masing komponennya.

Pengujian untuk situasi yang tipikal lebih penting
dibandingkan pengujian terhadap nilai batas.

Test Data Dan Kasus Test

 Test Data
Input yang direncanakan digunakan oleh sistem.
 Test Cases
Input yang digunakan untuk menguji sistem dan
memprediksi output dari input jika sistem beroperasi
sesuai dengan spesifikasi.

Pendekatan Strategis Pengujian

Perangkat Lunak

Pengujian Unit
Pengujian Integrasi
Pengujian Validasi
Pengujian Sistem

Pengujian Unit
 Berfokus pada inti terkecil dari desain perangkat
lunak yaitu modul
 Uji coba unit selalu berorientasi pada white box
testing
 Dapat dikerjakan paralel atau beruntun dengan modul
lainnya.

Pengujian Unit (2)

Pengujian Unit (3)








Apakah jumlah parameter input sama dengan jumlah

argumen?
Apakah antara atribut dan parameter argumen sudah
cocok?
Apakah antara sistem satuan parameter dan argumen
sudah cocok?
Apakah jumlah argumen yang ditransmisikan ke modul
yang dipanggil sama dengan atribut parameter?
Apakah atribut dari argumen yang ditransmisikan ke
modul yang dipanggil sama dengan atribut parameter?
Apakah sistem unit dari argumen yang ditransmisikan
ke modul yang dipanggil sama dengan sistem satuan
parameter?

Pengujian Unit (4)

 Apakah jumlah atribut dan urutan argumen ke fungsifungsi built-in sudah benar?
 Adakah referensi ke parameter yang tidak sesuai dengan
poin entri yang ada?
 Apakah argumen input only diubah?
 Apakah definisi variabel global konsisten dengan modul ?
 Apakah batasan yang dilalui merupakan argumen?

Pengujian Unit (5)

 Test case harus didesain untuk mengungkap kesalahan
dalam kategori
1. Pengetikan yang tidak teratur dan tidak konsisten
inisialisasi yang salah atau nilai-nilai default
2. Nama variabel yang tidak benar
3. Tipe data yang tidak konsisten
4. Underflow,
overflow
dan
pengecualian
pengalamatan

Seberapa Baik Sistem

Yang Sudah di Bangun

Dua Aspek yang dipertimbangkan:
 Apakah implementasi sudah sesuai dengan
spesifikasi ?
 Apakah spesifikasi sesuai dengan kebutuhan user ?

Validasi
 Apakah sistem yang dikembangkan sudah benar?
 Pengujian dimana sistem ketika diimplementasikan
sesuai dengan yang diharapkan

Verifikasi
 Apakah sistem dikembangkan dengan cara yang
benar ?
 Pengujian apakah sistem sudah sesuai dengan
spesifikasi

Integration Testing
 Pengujian keseluruhan system atau sub-system yang
terdiri dari komponen yang terintegrasi.
 Test integrasi menggunakan black-box dengan test
case ditentukan dari spesifikasi.
 Kesulitannya adalah menemukan/melokasikan
 Penggunaan Incremental integration testing dapat
mengurangi masalah tersebut.

T1

T1

A
T1

T2

T2
T2

T3
T3

C
T4

T3
C

T4
T5

D
Test sequence
1

Test sequence
2

Test sequence
3

Pendekatan Integration Testing

Top-down Testing
Berawal dari level-atas system dan terintegrasi dengan
mengganti masing-masing komponen secara top-down
dengan suatu stub (program pendek yg mengenerate
input ke sub-system yang diuji).

Bottom-up Testing
Integrasi components di level hingga sistem lengkap
sudah teruji.
Pada prakteknya, kebanyakan test
integrasi
menggunakan kombinasi kedua strategi pengujian tsb.

Top Down Testing

Level 1

Testing
sequence

Level 2
Level 2
stubs

Level 3
stubs

Level 1

Level 2

Level 2

...

Level 2

Bottom Up Testing
Test
drivers
Level N

Test
drivers

Level N

Level N1

Level N

Level N1

Level N

Level N

Level N1

Testing
sequence

Pendekatan Testing

Architectural Validation
Top-down integration testing lebih baik digunakan
dalam menemukan error dalam sistem arsitektur.

System Demonstration
Top-down integration testing hanya membatasi
pengujian pada awal tahap pengembangan system.

Test Implementation
Seringkali lebih mudah dengan menggunakan bottomup integration testing

Interface Testing
 Dilakukan kalau module-module dan sub-system
terintegrasi dan membentuk sistem yang lebih besar
 Tujuannya untuk medeteksi fault terhadap kesalahan
interface atau asumsi yang tidak valid tentang interface
tersebut.
 Sangat
penting
untuk
pengujian
terhadap
pengembangan
sistem
dengan
menggunakan
pendekatan object-oriented yang didefinisikan oleh
object-objectnya

Pengujian Validasi

Kajian Konfigurasi (audit)
 Elemen dari proses validasi
 Memastikan apakah semua elemen konfigurasi
perangkat lunak telah dikembangkan dengan tepat

Pengujian Alpha dan Beta
 Pengujian Alpha
 Usability labs
 Usability factors checklist
 Pengujian Beta

Pengujian Sistem





Pengujian Perbaikan
Pengujian Keamanan
Pengujian Stress
Pengujian Kinerja

Pengujian Aplikasi Server








Volume Testing
Stress Testing
Performance Testing
Data Recovery Testing
Data Backup and Restore Testing
Data Security Testing

Volume Testing
 Menemukan kelemahan sistem selama melakukan
pemrosesan data dalam jumlah yang besar dalam
periode waktu yang singkat.
 Tujuan: meyakinkan bahwa sistem tetap melakukan
pemrosesan data antar batasan fisik dan batasan logik.
 Contoh:
Mengujikan proses antar server dan antar partisi hardisk
pada satu server.

Stress Testing
 Tujuan: mengetahui kemampuan sistem dalam
melakukan transaksi selama periode waktu puncak
proses.
 Contoh periode puncak: ketika penolakan proses login
on-line setelah sistem down atau pada kasus batch,
pengiriman batch proses dalam jumlah yang besar
dilakukan setelah sistem down.
 Contoh: Melakukan login ke server ketika sejumlah
besar workstation melakukan proses menjalankan
perintah sql database.

Performance Testing
 Dilakukan secara paralel dengan Volume dan Stress
testing untuk mengetahui unjuk kerja sistem (waktu
respon, throughput rate) pada beberapa kondisi proses
dan konfigurasi.
 Dilakukan pada semua konfigurasi sistem perangkat
keras dan lunak. Misal : pada aplikasi Client-Server
diujikan pada kondisi korporate ataupun lingkungan
sendiri (LAN vs. WAN, Laptop vs. Desktop)
 Menguji sistem dengan hubungannya ke sistem yang
lain pada server yang sama.
 Load Balancing Monitor
 Network Monitor

Data Recovery Testing

 Investigasi dampak kehilangan data melalui proses
recovery ketika terjadi kegagalan proses.
 Penting dilakukan karena data yg disimpan di server
dapat dikonfigurasi dengan berbagai cara.
 Kehilangan Data terjadi akibat kegagalan sistem,
hardisk rusak, peghapusan yang tidak sengaja,
kecelakaan, virus dan pencuri.

Data Backup dan Restore Testing

 Dilakukan untuk melihat prosedur back-up dan
recovery.
 Diakukan dengan mensimulasikan beberapa kesalahan
untuk menguj i proses backup dan recovery.
 Pengujian dilakukan terhadap strategi backup: frekuensi
, medium, waktu, mekanisme backup (manual/
otomatis), personal, ? Berapa lama backup akan
disimpan.
 Switching antara live dan backup server ketika terjadi
kerusakan (load log transaction pada back-up kemudian
melakukan recovery).

Data Security Testing

 Privilege access terhadap database diujikan pada
beberapa user yang tidak memiliki privilege access ke
database.
 Shutdown database engine melalui operating system
(dengan beberapa perintah OS) yang dapat mematikan
aplikasi database.

Debugging

PERTEMUAN 14

TEKNIK PENGUJIAN
PERANGKAT LUNAK

TESTING

Pengujian perangkat lunak adalah proses menjalankan
dan mengevaluasi sebuah perangkat lunak secara manual
maupun otomatis untuk menguji apakah perangkat lunak
sudah memenuhi persyaratan atau belum, atau untuk
menentukan perbedaan antara hasil yang diharapkan
dengan hasil sebenarnya.

Pengujian merupakan suatu tahapan pengerjaan yang
bertujuan mencari kesalahan program. Kesalahan yang
terjadi selama proses pengembangan perangkat lunak
akan mengakibatkan bertambahnya waktu untuk
menyelesaikan pekerjaan tersebut.

Pengujian hendaknya dilakukan pada setiap tahap
pengembangan yaitu mulai dari tahap analisis kebutuhan
sampai dengan tahap perawatan.

KENAPA HARUS DIUJI ?

 Kita bukan seorang programmer yang cukup baik
 Kita mungkin tidak dapat cukup berkonsentrasi untuk
menghindari kesalahan
 Kita terkadang lupa menggunakan pemrograman
terstruktur secara penuh, perancangan atas-bawah
untuk mendapatkan solusi
 Kita kadang buruk dalam mengerjakan sesuatu

KENAPA HARUS DI UJI (2)

 Kita seharusnya dapat membedakan apa yang dikatakan
programmer lain atau pelanggan dan apa yang
sebenarnya mereka pikirkan
 Kita seharusnya merasa bersalah apabila seseorang
harus menguji koding kita
 Pengujian
kesalahan

merupakan

suatu

perizinan

terhadap

PRINSIP PENGUJIAN
Beberapa prinsip pengujian yang harus diperhatikan
(diusulkan oleh Davis):
1. Semua pengujian harus dapat ditelusuri sampai ke
persyaratan pelanggan.
2. Pengujian harus direncanakan lama sebelum
pengujian itu dimulai.
3. Prinsip Pareto berlaku untuk pengujian PL. Prinsip
Pareto mengimplikasikan 80% dari semua kesalahan
yang ditemukan selama pengujian sepertinya akan
dapat ditelusuri sampai 20% dari semua modul
program.

PRINSIP PENGUJIAN (2)

4. Pengujian harus mulai "dari yg kecil" dan berkembang
ke pengujian "yang besar".
5. Pengujian yg mendalam tidak mungkin.
6. Paling efektif, pengujian dilakukan oleh pihak ketiga
yang independen

SASARAN PENGUJIAN


Glen Mayers menyatakan sejumlah aturan yang dapat

dipandang sebagai sasaran dari pengujian
 Pengujian perangkat lunak adalah suatu proses
pengeksekusian
program
dengan
tujuan
menemukan kesalahan (error)
 Pengujian (Test case) yang baik adalah yang
mempunyai
probabilitas
yang
tinggi
untuk
menemukan error yang tak diketemukan
 Pengujian yang sukses adalah pengujian yang
dapat menemukan kesalahan (error) yang tidak
ditemukan sebelumnya

TUJUAN PENGUJIAN
Tujuan
yang diinginkan dari pelaksanaan pengujian
perangkat lunak adalah :
 Menilai apakah perangkat lunak yang dikembangkan
telah memenuhi kebutuhan pemakai.
 Menilai apakah tahap pengembangan perangkat lunak
telah sesuai dengan metodologi yang digunakan.
 Membuat
dokumentasi
hasil
pengujian
yang
menginformasikan kesesuaian perangkat lunak yang
diuji dengan spesifikasi yang telah ditentukan.

TEST ABILITAS
Testabilitas Perangkat Lunak adalah seberapa
mudah sebuah program komputer dapat diuji.
Karena pengujian sangat sulit, perlu diketahui apa
yang dapat dilakukan untuk membuatnya menjadi
mudah.

Karakteristik PL yang Di Uji

OPERABILITAS
Semakin baik dia bekerja semakin efisien dia dapat diuji.

OBSERVABILITAS
Apa yang anda lihat adalah apa yang anda uji.

KONTROLABILITAS
Semakin baik kita dapat mengontrol PL, semakin banyak
pengujian yang dapat diotomatisasi dan dioptimalkan.

DEKOMPOSABILITAS
Dengan mengontrol ruang lingkup pengujian kita dapat
lebih cepat mengisolasi masalah dan melakukan
pengujian kembali.

Karakteristik PL yang Di Uji (2)

KESEDERHANAAN
Semakin sedikit yg diuji semakin cepat pengujian.

STABILITAS
Semakin sedikit perubahan semakin sedikit gangguan
pengujian.

KEMAMPUAN DIPAHAMI
Semakin banyak informasi yang dimiliki semakin detail
pengujiannya.

11

ATRIBUT PENGUJIAN YANG BAIK






Memiliki probabilitas yg tinggi menemukan kesalahan.

Tidak redundan.
Harusnya jenis terbaik.
Tidak boleh terlalu sederhana atau terlalu kompleks

DESAIN TEST CASE

Terdapat bermacam-macam rancangan metode test case
yang dapat digunakan, semua menyediakan pendekatan
sistematis untuk uji coba. Yang terpenting metode
menyediakan kemungkinan yang cukup tinggi untuk
menemukan kesalahan.

DESAIN TEST CASE (2)

Terdapat 2 macam test case:
1. Pengetahuan tentang fungsi yang spesifik dari produk
yang telah dirancang untuk diperlihatkan, test dapat
dilakukan untuk menilai masing-masing fungsi apakah
telah berjalan sebagaimana yang diharapkan.
2. Pengetahuan tentang cara kerja dari produk, test dapat
dilakukan untuk memperlihatkan cara kerja dari produk
secara rinci sesuai dengan spesifikasinya.

PERANCANGAN TEST CASE

Dua macam pendekatan test yaitu :
1. Black Box Testing
Test case ini bertujuan untuk menunjukkan fungsi
Perangkat Lunak tentang cara beroperasinya
beroperasinya,, apakah
pemasukan data keluaran telah berjalan sebagaimana
yang diharapkan dan apakah informasi yang disimpan
secara eksternal selalu dijaga kemutakhirannya
kemutakhirannya..

PERANCANGAN TEST CASE (2)

2. White Box Testing (Structural Testing)

Adalah meramalkan cara kerja perangkat lunak
secara rinci
rinci,, karenanya logikal path (jalur logika
logika))
perangkat lunak akan ditest dengan menyediakan
test case yang akan mengerjakan kumpulan kondisi
dan atau pengulangan secara spesifik
spesifik.. Secara
sekilas dapat diambil

Dijamin semua independent path (jalur bebas)
bebas) telah
dijalankan setidaknya satu kali

Teknik Pengujian Per.Lunak@Berta

16

PERANCANGAN TEST CASE (3)

White Box (Lanjutan
Lanjutan))

Menjalankan semua keputusan logis pada sisi true &
false

Menjalankan semua looping

Melakukan struktur data internal untuk menjamin
validitas
kesimpulan white box testing merupakan petunjuk untuk
mendapatkan program yang benar secara 100%
100%.

Teknik Pengujian Per.Lunak@Berta

17

WHITE BOX TESTING

1. Basis Path Testing
 Teknik uji coba White Box yang diusulkan Tom Mccabe
(1976). Metode ini memungkinkan perancang test case
mendapatkan ukuran kekompleksan logical dari
perancangan prosedural dan menggunakan ukuran ini
sebagai petunjuk untuk mendefinisikan basis set dari jalur
pengerjaan.
 Test case yang didapat digunakan untuk mengerjakan
basis set yang menjamin pengerjaan setiap perintah
minimal satu kali selama uji coba. Contoh dari Basis Path
Testing :

Notasi Diagram Alir

Cyclomatic Complexity

Graph Metrix

WHITE BOX TESTING (2)

2. Loop Testing

Loop Sederhana
Pengujian loop sederhana dilakukan dgn mudah,
dimana n jumlah maksimum yg diijinkan melewati
loop tsb.
1. Lewati loop secara keseluruhan
2. Hanya satu yg dapat melewati loop
3. m dapat melewati loop dimana m< n

Loop terangkai

Loop tidak terstruktur

19

WHITE BOX TESTING (3)

Loop Tersarang
Pengujian loop ini menggunakan pendekatan loop
sederhana.. Petunjuk pengujian loop tersarang :
sederhana
1. Dimulai dari loop paling dalam
dalam.. Atur semua loop ke
nilai minimum
minimum..
2. Kerjakan dgn prinsip loop sederhana untuk loop yg
paling dalam sementara tahan loop yg di luar pada
parameter terkecil (nilai kounter terkecil
terkecil))
3. Kemudian lanjutkan untuk loop yg diatasnya
diatasnya..
4. Teruskan sampai semua loop selesai di uji.
uji.

WHITE BOX TESTING (4)

Loop Terangkai
Pengujian loop ini menggunakan pendekatan loop
sederhana bila masing-masing loop independen, tetapi
bila dua loop dirangkai dan pencacah loop 1 digunakan
sebagai harga awal loop 2 maka loop tsb jadi tidak
independen, maka pendekatan yang diaplikasikan ke
loop tersarang direkomendasikan.

Loop Tidak Terstruktur
Kapan saja memungkinkan, loop ini didisain kembali
agar
mencerminkan
penggunaan
komsepsi
pemrograman tertruktur.

WHITE BOX TESTING (5)

BASIS PATH TESTING

1. Notasi Diagram Alir (Program Flow Graph)

Teknik Pengujian Per.Lunak@Berta

23

BASIS PATH TESTING (2

(2)
 Notasi Diagram Alir (2)

BASIS PATH TESTING (3)

Perancangan
Prosedural
Dalam Bentuk Flowchart

BASIS PATH TESTING (4

(4)
Gambar
Grafik Alir


Lingkaran/node :
Menggambarkan satu/lebih perintah prosedural. Urutan
proses dan keputusan dapat dipetakan dalam satu node.

Tanda panah/edge :
Menggambarkan aliran kontrol. Setiap node harus
mempunyai tujuan node

Region :
Adalah daerah yg dibatasi oleh edge dan node.
Termasuk daerah diluar grafik alir.

Program Flow Graphs



Menggambarkan alur kontrol

kontrol.. Setiap cabang ditunjukkan
oleh path yang terpisah dan loop ditunjukkan oleh
arrows looping kembali ke loop kondisi node
node..
Digunakan sebagai basis untuk menghitung cyclomatic
complexity
Cyclomatic complexity
= Jumlah edges Jumlah Node +2
Cyclomatic complexity menyatakan jumlah test untuk
menguji control statements

bottom > top

while bottom <= top

2

if (elemArray [mid] == key

8
5

(if (elemArray [mid]< key

6

9
7

Independent Paths






1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9
Test cases harus ditentukan sehingga
semua path tersebut tereksekusi.

Teknik Pengujian Per.Lunak@Berta

30

BLACK BOX TESTING






Pendekatan pengujian dimana program dianggap

sebagai suatu black-box (kotak hitam)
Program test case berbasiskan spesifikasi
Test planning dapat dimulai sejak awal proses
pengembangan sistem
Merupakan metode pelengkap White Box Testing.
Berfokus pada kebutuhan fungsional dari PL.
Memungkinkan
perancang
untuk
memperoleh
sekumpulan kondisi2 input yang secara penuh menguji
semua kebutuhan fungsional suatu program

Teknik Pengujian Per.Lunak@Berta

31

BLACK BOX TESTING (2)



Metode ini berusaha menemukan kesalahan yang

termasuk kategori di bawah ini

Fungsi2 yg hilang atau tidak benar

Kesalahan pada antarmuka

Kesalahan pada struktur data atau pengaksesan
database ekternal

Kesalahan pada performance

Kesalahan pada inisialisasi dan terminasi

BLACK BOX TESTING (3)

Contoh Black Box Testing adalah
1. Equivalence Partitioning

Membagi domain input dari program ke dalam klas2
data

Input data dan output hasil terdapat di klas yang
berbeda yang sesuai dengan klas inputnya

Masing-masing klas equivalensi partition diprosres
dimana program akan memproses anggota klas-klas
tersebut secara equivale.

Test cases dipilih dari masing-masing partisi

BLACK BOX TESTING (4

(4)
2. Boundary Value Analysis (BVA)

Melengkapi
Equivalence
Partitioning,
dengan
melakukannya dari domain output BVA merupakan
pilihan test case yang mengerjakan nilai yang telah
ditentukan, dengan teknik perancangan test case

Melengkapi test case equivalence partitioning yg
fokusnya pada domain input.

Teknik Pengujian Per.Lunak@Berta

34

PERTEMUAN 6
COMPONENT DIAGRAM

Component Diagram

Component diagram menggambarkan struktur dan

hubungan antar komponen piranti lunak, termasuk
ketergantungan (dependency) di antaranya.

Komponen piranti lunak adalah modul berisi code, baik
berisi source code maupun binary code, baik library
maupun executable, baik yang muncul pada compile
time, link time, maupun run time.

Umumnya komponen terbentuk dari beberapa class
dan/atau package, tapi dapat juga dari komponenkomponen yang lebih kecil.

Komponen dapat juga berupa interface, yaitu kumpulan
layanan yang disediakan sebuah komponen untuk
komponen lain.
Contoh component diagram:

Component Diagram
Menggambarkan alokasi semua class dan object kedalam komponen dalam
desain fisik system software, termasuk pengaturan dan kebergantungan
antar komponen software
Component dapat terdiri dari
logical component, seperti business component, process component, dll
Physical component (software arsitektur) , seperti Com+, dot
NET,CORBA, dll
Component digambarkan
dengan bentuk pada UML versi 1.*:
Pada UML versi 2 digambarkan dengan bentuk
atau

atau

atau

Stereotypes yang dapat digambarkan pada bentuk component

<<application>>,kumpulan aplikasi system
<<executable>>,component yang jalan di client
<<file>>, data file
<<database>>
<<infrastructure>>, technical component didalam system <<document>>
<<source code>>, source file
<<library>>
<<table>>, table data dalam sebuah database
<<web service>>
<<XML DTD>>
<<UI>>, User interface (screen, pages, report)
dll

Component Diagram

Dependencies
dimodelkan dengan garis terputus dengan panah terbuka
gambarkan dependencies dari kiri ke kanan
Contoh:
<<ASP>> Source Code bergantung pada
<<database>> MySQL
Dimungkinkan sebuah component dependencies pada interfaces
component lainnya
Contoh:

Inheritance
inheriting/child component diletakkan dibawah parent component, dengan
arah panah menuju ke parent component
dimodelkan dengan garis dengan panah tertutup
Contoh:
Menu Utama
<<UI>>

Penjualan
<<application>>

Pembelian
<<application>>

Interfaces - Component Diagram

Interfaces adalah kumpulan >=1 methode dan >=0 attribute yang dapat
dipakai pada class tanpa menjadi behavior suatu class.
Jenis interface ada 2 macam yaitu :
Provide, digambarkan dengan bentuk lollipop
Pada UML 1.* bisa juga digambarkan dengan garis terputus dengan panah
tertutup

Required, digambarkan dengan bentuk socket

Penggambaran
interfaces dapat juga
dilakukan dengan
menambah bagian
component seperti
contoh dibawah ini

Bentuk grafik

Component Diagram

port
adalah bentuk object yang menjelaskan interaksi antara object dan
lingkungannya
digambarkan sebagai kotak kecil di pinggiran component

Assembly connector
Penghubung antara
2/lebih component
dimana
sebuah/beberapa
component provides
interfaces dan
component lain required
interfaces
Digambarkan dengan
gabungan bentuk
interfaces
contoh:

Component Diagram (Acknowledgments Toeko triyanto)

Simpan database
server

Kirim

Isi data

Browsing

Deployment Diagram

Deployment Diagram

Deployment/physical
diagram
menggambarkan
detail
bagaimana komponen di-deploy dalam infrastruktur sistem, di
mana komponen akan terletak (pada mesin, server atau piranti
keras apa), bagaimana kemampuan jaringan pada lokasi
tersebut, spesifikasi server, dan hal-hal lain yang bersifat
fisikal

Sebuah node adalah server, workstation, atau piranti keras
lain yang digunakan untuk men-deploy komponen dalam
lingkungan sebenarnya. Hubungan antar node (misalnya
TCP/IP) dan requirement dapat juga didefinisikan dalam
diagram ini

Deployment diagram digunakan untuk melayani pemodelan
hardware yang digunakan dalam implementasi sistem dan
asosiasinya antara komponen-komponen tersebut. Elemen
yang digunakan dalam deployment diagram adalah nodes
(ditunjukkan sebagai sebuah cube), komponen (ditunjukkan
sebagai sebuah kotak bujursangkar) dan juga asosiasi.

 Deployment diagram ini menunjukkan hardware yang digunakan pada

jaringan kantor yang kecil. Application server (node) terhubung dengan
database server (node) dan database client (component) sudah
terinstall dalam application server. Workstation juga terhubung
(association) dengan application server dan juga ke printer.

Deployment Diagram
Menggambarkan arsitektur system
Pemetaan software(component pada component diagram) yang jalan di
sebuah hardware (node pada deployment diagram)
Software component tidak selalu menggambarkan setiap software
component yang ada pada sebuah Komputer(system operasi/Microsoft
Office, dll), akan tetapi software component tersebut akan digambarkan
ketika ada hubungan dengan pengimplementasian sebuah system
Menggambarkan bagaimana s/w dan h/w bekerja sama
Menggambarkan topologi jaringan
Artifact
Spesifikasi dari bentuk physic informasi yang digunakan atau dihasilkan
Contoh : source file, script, executable file, table di database, document
word/excel, e-mail, dll
Digambarkan dengan bentuk
Dapat dihubungkan dengan component pada component diagram
Hanya digambarkan dalam sebuah node

perhatikan potongan program dibawah ini yang sesuai dengan artifact yang ada:
<! order.ASp>
<!-- #include file=buka.asp -->
<!-- #include file=uler.txt -->
<!-- #include file=data.css -->//code style sheet
<script src="tgl.js">
//javascript
</script>

Node - Deployment Diagram

Adalah hardware seperti
computer/PDA ,lap top, handphone
peralatan komunikasi data (router,hub,switch,modem)
dll
Nama Node
Digambarkan dengan bentuk kotak 3 dimensi
Node dapat
digabungkan dengan
Node dapat digambarkan
component pada
dengan bentuk visual,
component diagram
ataupun gabungan antara
node dan visual

Association (connection) - Deployment Diagram

Digambarkan dengan sebuah garis
yang menghubungkan antara
node
Setiap association mempunyai sebuah stereotypes seperti
Stereotypes

Istilah

Asychronous

Hubungan asynchronous

HTTP

HyperText Transport Protocol (internet protocol_

JOBC

Java Database Connectivity, a Java API for database access.

ODBC

Open Database Connectivity, a Microsoft API for database access.

RMI

Remote Method Invocation, a Java communication protocol.

RPC

Communication via remote procedure calls

Synchronous

Komunikasi synchronous

Web Services

Komunikasi melalui Web Services protocols seperti as SOAP and UDDI

Ethernet

Ethernet Card

Client

<<asynchronous>>

1 Server

association dimungkinkan mempunyai multiplicity (0..1, 1..*, dll)

Dependencies - Deployment Diagram

Digambarkan dengan garis terputus yang berpanah terbuka
deploy
Sebuah garis terputus dengan ujung panah terbuka yang tertuju ke node
dengan sebuah stereotypes <<deploy>> untuk menggambarkan software
yang terdapat pada sebuah hardware
dimungkinkan
sebuah node
memiliki node yang
lain
faktur.asp dependencies
terhadap order.asp

cara diatas dapat digambarkan dengan memasukkan artifact/software ke

dalam node/hardware

atau

Manifest - Deployment Diagram

bentuk fisik dari artifact
digambarkan dengan sebuah garis terputus dengan ujung panah terbuka
yang tertuju ke component dengan sebuah stereotypes <<manifest>>

Interaction Overview Diagram

Sebuah jenis activity
Diagram yang
memperlihatkan alur
control dalam system
atau business process.
Setiap node/activity
didalam diagram
mewakili interaction
diagram yang lain
Interaction Overview
Diagram menggunakan
notasi yang dipakai
pada Activity diagram
dan Sequence Diagram
Interaction,
sd
dilambangkan dengan
gambar dibawah ini

Sd = sequence diagram

Interaction Overview Diagram

Contoh
Interaction overview diagram
Sequence diagram

Timing Diagram
Memperlihatkan interaksi ketika tujuan utama diagram adalah waktu
Menggambarkan perubahan dalam state atau kondisi dari pengelompokkan
instance atau tugas berlebihan
Biasanya dipakai untuk memperlihatkan perubahan dalam state object
berlebihan dalam merespon ke external events
Dipakai untuk memperlihatkan perilaku dari sebuah/beberapa object melalui
periode waktu
Ada 2 jenis
Timing diagram yaitu
Concise/
simple notation

Dipakai untuk mengeksplorasi sebuah/beberapa object melalui periode waktu

keterangan gambar :
 object

 states

 Lifeline

 Timing Constrant

:seminar
proposed, scheduled, enrolling students,
Being Taught, Final Exams, Closed
| {Nov 1 .. Des 31} | {jan 1 .. July 31}

Timing Diagram
Robust notation

State
/condition

Object
Lifeline

Messag
e

Composite Structure Diagram

Menggambarkan stuktur internal dari pengelompokkan (class, component, use

case), termasuk hubungan pengelompokkan ke bagian lain dari system
Collaboration
Mendefinisikan struktur dari kerjasama element/role
Ditampilkan dalam bentuk elipse dengan garis terputus, yang berisi nama
collaboration
Digunakan untuk menjelaskan bagaimana system bekerja

atau

Composite Structure Diagram

Collaboration occurrence
Sebuah collaboration dihubungkan ke sebuah methode atau object melalui
collaboration occurrence
Digambarkan dengan sebuah elipse dengan garis terputus yang berisi nama
occurrence (kejadian/peristiwa), titik dua dan type collaboration
Contoh:
retail:sale
Keterangan gambar :
Collaboration sale menggambarkan
collaboration antara role buyer dan
seller
Collaboration brokeredsale
menggambarkan collaboration
diantara 3 role yaitu producer,
broker dan consumer
Collaboration brokeredsale terdiri
dari 2 occurrence dari collaboration
sale yaitu wholesale:sale dan
retail:sale
Ocucurrence wholesale
mengindikasikan collaboration sale
dimana producer sebagai seller dan
broker adalah buyer
Role
Digambarkan dengan kotak
Broker
dengan berisi nama Role

Composite Structure Diagram

Contoh Deploment Diagram (Acknowledgments Toeko triyanto)

Client Browser

Client Browser

Client Browser

 Package Diagram
Sebuah bentuk pengelompokkan yang memungkinkan untuk
mengambil sebuah bentuk di UML dan mengelompokkan
elemen-elemennya dalam tingkatan unit yang lebih tinggi.
Kegunaan package yang paling umum adalah untuk
mengelompokkan class.
Package Diagram
Menggambarkan pengelompokan dari suatu class-class

Contoh package diagram (Acknowledgments Toeko triyanto)

tunggakan

guestbook

keluhan
pelanggan

kwitansi

i_01
master_pelangg
an

perintah_kerja
index/home

pelanggan_reg

master_status

mutasi
user.
modul

Master_tarif

Entity Relationship Diagram (ERD)

ERD adalah :
Model untuk menjelaskan hubungan antar data dalam
basis data berdasarkan suatu persepsi bahwa real word
terdiri dari objek-object dasar yang mempunyai hubungan
atau relasi antara objek-objek tersebut

TAHAP MEMBUAT ERD

1. Keluarkan semua atribut yang dimiliki oleh dokumen
sumber
2. Tentukan Atribut yang dapat menjadi Primary Key
jika TIDAK ADA boleh DIBUAT BARU lalu tentukan
ketergantungan atribut terhadap primary key nya
3. Tentukan nama entitas dari kelompok atribut yang
telah bergantung terhadap primary keynya.
4. Gambarkan hubungan masing-masing entitas beserta
atribut atributnya.
5. Tentukan Cardinality/tingkat hubungan dari masingmasing Entitas yang telah terhubung.

Notasi dan Penamaan Untuk Konstruksi Skema Diagram ER

No
1.

2.

Simbol

Keterangan
Entity Type
Suatu yang ada (secara eksplisit
keberadaannya dapat nyata dapat
perbedaan antar entity harus jelas.
Ex. Pegawai, Departemen

ada) namun
virtual, serta

Weak entity Type

Suatu entity yang tidak punya key atribut keberadaannya
tidak perlu berdiri sendiri / diluar system. Didalam weak
dimungkinkan 1 weak memiliki banyak entity. Setidaknyatidaknya memiliki 1 relasi.
Ex.
Karyawan

Departemen

Salary

3.

Attribute
Keterangan yang dimilikientity / sifat-sifat yang melekat
pada entity yang perlu dicatat.
Ex. Pegawai: Nopeg, Nama, Alamat, Jenis Kel, tgl. Masuk

4.

Key Attribute
Bila didalam attribute terdapat nilai sama, maka kita perlu
membuat Key attribute sehingga dipastikan tidak akan
terjadi nilai/record sama.
Ex. Pegawai : sebagai key adalah NoPeg
NoPeg
Nama
Alamat
P01
Bella
Malang
P02
Bella
Batu

5.

Multivalued Attribute
Satu entity yang memiliki 2 attribute sama
Ex. Departemen yang memiliki 2 lokasi pabrik
Departemen
Departemen

Lokasi

Hal ini bukan berarti bias untuk orang yang

mempunyai 2 nama atau 2 alamat
6.

Composite Attribute
Attribute yang mempunyai nilai attribute lebih dari Satu
Ex. Nama :
Nama Depan
Alamat :
Jalan
Nama Tengah
Nomer
Nama Belakang
Kota

7.

Derived Attribute
Merupakan kombinasi dari attribute-attribute dimana
keberadaannya tidak perlu disimpan.
Ex.
Mata Kuliah
MHS

E1

E2

8.

Identifying Relationship Type

Bila entity mempunyai hubungan lebih dari satu
entity lain.
E1

E2

9.

Relationship Type
Menyatakan hubungan antar attribute sehingga
terjadi pemetaan.
Ex.
M
Mahasiswa

Bisa
Ambi
l

*
*
Range
Domain

Hasil Dari Relasi :

One To One
(1:1)
One To Many (1:N)
Many To Many (1:M)

N
Mat. Kul
#
#
#
#
Kodomain

Derajat Relationship
 UNARY RELATIONSHIP

 BINARY RELATIONSHIP

 N-ARY RELATIONSHIP

ENTITY-RELATIONSHIP DIAGRAM

PEGAWAI

PUNYA

JABATAN

PEGAWAI

MEMPUNYAI

JABATAN

PEGAWAI

DIPUNYAI OLEH

JABATAN

PROYEK

KERJA

PEGAWAI

PROYEK

DIKERJAKAN OLEH

PEGAWAI

PROYEK

MENGERJAKAN

PEGAWAI

ENTITY-RELATIONSHIP DIAGRAM

PEGAWAI

PUNYA

JABATAN

PROYEK

KERJA

PEGAWAI

MHSISWA

IKUT

MT-KULIAH

ENTITY-RELATIONSHIP DIAGRAM

PEGAWAI

NO-PEG
NAMA
ALAMAT

PROYEK

NIM
NAMA
ALAMAT

NO-PEG
KD-JAB

KD-PROY
NM-PROY
ANGGARAN

MHSISWA

PUNYA

KERJA

KD-JAB
URAIAN
TUNJANGAN

IKUT
NIM
KD-MATKUL
NILAI

PEGAWAI
NO-PEG
NAMA
HONOR

KD-PROY
NO-PEG

JABATAN

MT-KULIAH
KD-MATKUL
NM-MATKUL
SKS

ENTITY-RELATIONSHIP DIAGRAM

 JENIS ENTITY
PEGAWAI

ISI

ABSEN

STRONG ENTITY

WEAK ENTITY

TIDAK MEMPUNYAI KEY

PEGAWAI
NO-PEG
NAMA
ALAMAT

ISI
NO-PEG

ABSEN
TANGGAL
JAM-MASUK
JAM-PULANG

ENTITY-RELATIONSHIP DIAGRAM

NO-PEG
NO-PROY
NO-PEG
NAMA
PEGAWAI
GAPOK
LAMA-KERJA
JABATAN
M

NO-PEG
KD-BAG

PUNYA

KD-BAG
NAMA-BAG

BAGIAN

1
M

KERJA

PROYEK

NO-PROY
NAMA-PROY
BIAYA

PAKAI

N
BARANG

NO-PROY
KD-BAR
JUMLAH

KD-BAR
HARGA-BAR
NAMA-BAR

KASUS : ANALISA SISTEM BERJALAN

Posedur Sistem Berjalan
Perusahaan Bina Sarana Indonesia adalah perusahaan
usaha dagang yang bergerak di bidang distributor
penjualan elektronik (TV, kulkas, kipas angin, radio dan
lain lain), Perusahaan ini menjual barang elektronik
kepada customer secara tunai dengan nilai transaksi
Rp. 50.000.000,-(lima puluh juta rupiah). Customer
adalah badan usaha atau toko pengecer yang menjual
produknya kepada pelanggan secara perorangan. Pada
prosedur sistem berjalan ini, Customer pada saat
memesan barang diharuskan melampiri dokumen PO
terlebih dahulu, dan PO paling lama satu minggu untuk
di konfirmasi pada Customer. Maka untuk lebih jelasnya
prosedur dari sistem berjalan adalah sebagai berikut:

a. Prosedur Order Penjualan

Setiap costumer dapat memesan barang datang
langsung atau melalui faximile dengan
menyertakan dokumen PO yang diterima oleh
bagian penjualan. Kemudian bagian penjualan
berdasarkan PO, memeriksa pesanan barang
dengan menggunakan kartu stock, apabila stock
barang ada maka di hitung nilai penjualan dan
dicatat kedalam faktur penjualan. Jika stock
barang tidak ada, maka di catat ke dokumen
Daftar Permintaan Stock Barang (DPSB), faktur
penjualan rangkap 4 (empat), yang telah di buat
didistribusikan ke Kasir

b. Prosedur Pembayaran Tunai

Setelah customer mendapat konfirmasi tentang
pesanan pembelian disetujui, maka customer
melakukan transaksi pembayaran melalui transfer uang
ke bank yang ditunjuk dengan bukti setoran.
Berdasarkan bukti setoran, Kasir membuka arsip
penjualan yang dicocokan dengan bukti setoran.
Apabila sesuai dengan nilai penjualan maka dibuatkan
kwitansi lunas, dan merekap nilai penjualan
Harian/Daily Sales Report (DSR). Distribusi dokumendokumen berdasarkan nilai transaksi penjualan sebagai
berikut : untuk Kwitansi dan faktur penjualan di berikan
kepada customer. Gudang mendapat tembusan
pengeluaran barang dari kasir sesuai barang yang di
pesan, dan Copy faktur diberikan ke Bagian Penjualan.

c. Prosedur Pennyiapan Barang kirim

Gudang Setelah menerima Tembusan pengeluaran
barang, maka menyiapkan barang yang akan dikirim
dengan mencatat barang keluar ke kartu gudang
dan membuat dokumen
surat keluar barang yang ditembuskan ke bagian
Penjualan.
d. Prosedur Pengiriman Barang
Bagian Penjualan berdasarkan Surat keluar barang,
selanjutnya membuka arsip faktur penjualan untuk
mencatat barang yang akan dikirim ke dokumen
Surat Jalan. Dokumen surat keluar barang
didistribusikan ke Bagian Pengiriman beserta barang
dan disampaikan ke Customer

e.Prosedur Pembuatan Laporan

Setiap akhir periode di buat laporan penjualan bulanan,
berdasarkan rekap penjualan harian dan faktur
penjualan. Laporan stock barang keluar berdasarkan
Kartu Stock dan Kartu Gudang.
Ke-dua laporan
tersebut diberikan kepada Manajer Penjualan untuk
proses evaluasi penjualan selama satu bulan.
PERTANYAAN :
1. Gambarkan DAD yang terdiri dari :
- Diagram KONTEKS
- Diagram NOL
- Diagram DETAIL
2. Analisa beberapa permasalahan dari Prosedur Sistem
Penjualan

RANCANGAN SISTEM USULAN

A. Prosedur Order Penjualan
Setiap Customer dapat memesan barang datang
langsung atau melalui faximile dengan menyertakan
dokumen PO yang diterima oleh Bagian Penjualan.
Kemudian Bagian Penjualan berdasarkan PO,
mengecek jumlah pesanan dan status Customer dengan
stock barang yang berada di file barang dan status
Customer berdasarkan file Customer. Apabila stock
barang ada maka di lakukan proses pengentrian
transaksi nilai penjualan yang disimpan ke file faktur dan
file Isi_faktur. Kemudian berdasarkan file faktur dan file
Isi_faktur dicetak ke dokumen faktur penjualan(4
rangkap) yang dikirimkan ke Kasir.

B. Prosedur Pembayaran Tunai

Setelah Customer mendapat konfirmasi tentang
pesanan
pembelian
disetujui,
maka
Customer
melakukan transaksi pembayaran melalui transfer uang
ke bank yang ditunjuk dengan bukti setoran.
Berdasarkan bukti setoran, Kasir membuka transaksi
pembayaran dengan membuka database penjualan (file
barang, file customer, file faktur, file Isi_faktur ).
Kemudian data pembayaran disimpan kedalam file
bayar. Berdasarkan file bayar maka dilakukan
pencetakan kwitansi ( dua rangkap ). Semua dokumen
penjualan didistribusikan oleh Kasir ke beberapa bagian,
yaitu sebagai berikut :
Kwitansi Asli dan Faktur Penjualan Asli diberikan ke Customer.
Copy kwitansi dan Copy Faktur Penjualan di berikan ke Bagian
Akunting
Copy Faktur didistribusikan ke Bagian Penjualan, Bagian
Gudang (Tembusan Pengeluaran Barang).

C. Prosedur Jurnal Penjualan

Bagian Akunting melakukan proses up-date transaksi
jurnal penjualan berdasarkan file bayar dan file perkiraan
yang disimpan ke file jurnal.
D. Prosedur Pengiriman Barang
Bagian Penjualan membuat dokumen Surat Jalan (SJ)
dengan mengentry jumlah barang yang dijual
berdasarkan
database
penjualan(fie
barang,file
customer, file faktur dan file Isi_faktur) yang disimpan
dalam file SJ dan file Isi_SJ. Dokumen SJ di berikan ke
bagian Pengiriman yang diantar ke Customer. Dokumen
SJ didistribusikan ke Gudang untuk menyiapkan barang
agar dikirimkan Ke Customer.

E. Prosedur Pembuatan Laporan

Setiap akhir periode di buat laporan penjualan bulanan,
berdasarkan rekap penjualan harian dan faktur
penjualan. Laporan stock barang keluar berdasarkan
Kartu Stock dan Kartu Gudang. Ke-dua laporan tersebut
diberikan kepada Manajer Penjualan untuk proses
evaluasi penjualan selama satu bulan.
PERTANYAAN :
1. Gambarkan DAD Usulan yang terdiri dari :
- Diagram KONTEKS
- Diagram NOL
- Diagram DETAIL
2. Gambarkan ERD dari kasus tersebut

Latihan
1. Suatu network yang menggambarkan suatu sistem
automatic/ komputerisasi , manual dan gabungan dari
keduanya dalam susunan berbentuk komponen sistem
yang saling berhubungan sesuai dengan aturan mainnya
a. DFD
d. entity
b. proses
e. jaringan
c. entitas
2. Simbol relationship pada ERD biasanya menggunakan
keterangan berupa
a. kata benda
d. kata sifat
b. kata kerja
e. kata perintah
c. kata pengganti

2. Simbol relationship pada ERD biasanya menggunakan keterangan

berupa
a. kata benda
d. kata sifat
b. kata kerja
e. kata perintah
c. kata pengganti
3. Dibawah ini adalah pernyataan yang benar dari aturan main DFD ,
kecuali
a. Dlm DFD tidak boleh menghubungkan antara EXTERNAL
ENTITY dgn EXTERNAL ENTITY secara langsung
b. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgn
DATA STORE secara langsung
c. Dlm DFD tidak boleh menghubungkan antara DATA STORE
dgnEXTERNAL ENTITY secara langsung (atau sebaliknya)
d. Setiap PROSES harus ada DATA FLOW yg masuk dan tidak
ada DATA FLOW yg keluar.
e. Salah semua

3. Dibawah ini adalah pernyataan yang benar dari aturan main DFD ,
kecuali
a. Dlm DFD tidak boleh menghubungkan antara EXTERNAL
ENTITY dgn EXTERNAL ENTITY secara langsung
b. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgn
DATA STORE secara langsung
c. Dlm DFD tidak boleh menghubungkan antara DATA STORE
dgnEXTERNAL ENTITY secara langsung (atau sebaliknya)
d. Setiap PROSES harus ada DATA FLOW yg masuk dan tidak
ada DATA FLOW yg keluar.
e. Salah semua
4. Tahapan proses pembuatan DFD yang menggambarkan sistem
secara global
a. Diagram konteks
d. Diagram Nol
b. Diagram Detail
e. diagram Top Down
c. Diagram Objek

4. Tahapan proses pembuatan DFD yang menggambarkan

sistem secara global
a. Diagram konteks
d. Diagram Nol
b. Diagram Detail
e. diagram Top Down
c. Diagram Objek

5. Gambar diatas adalah

a. unary relationship
b. N-ary relationship
c. M-ary relationship

d. binary relationship
e. ternary relationship

5. Gambar diatas adalah

a. unary relationship
b. N-ary relationship
c. M-ary relationship

d. binary relationship
e. ternary relationship

1. Suatu network yang menggambarkan suatu sistem automatic/

komputerisasi , manual dan gabungan dari keduanya dalam
susunan berbentuk komponen sistem yang saling berhubungan
sesuai dengan aturan mainnya
a. DFD
d. entity
b. proses
e. jaringan
c. entitas

Latihan
1. Untuk menggambarkan struktur dan hubungan antara
komponen piranti lunak termasuk ketergantungan
diantaranya menggunakan
a. package diagram
b. class diagram
c. collaboration diagram
d. deployment diagram
e. component diagram
2. Dependencies dimodelkan dengan
a. garis panah tertutup
d. lingkaran
b. garis panah terputus
e. garis
c. kotak persegi

2. Dependencies dimodelkan dengan

a. garis panah tertutup
d. lingkaran
b. garis panah terputus
e. garis
c. kotak persegi
3. Deployment diagram adalah diagram untuk menggambarkan
a. flowchart
d. sistem
b. komponen
e. proses
c. arsitektur sistem

3. Deployment diagram adalah diagram untuk menggambarkan

a. flowchart
d. sistem
b. komponen
e. proses
c. arsitektur sistem

4.Penggambaran garis panah tertutup pada component

diagram adalah
a. inheritance
d. dependencies
b. objek
e. entitas
c. polymorphisme

4.Penggambaran garis panah tertutup pada component

diagram adalah
a. inheritance
d. dependencies
b. objek
e. entitas
c. polymorphisme

5. Jenis interfaces pada component diagram adalah

a. provide dan proccess
d. provide dan required
b. proccess dan required
e. entity dan provide
c. requiered dan entity

5. Jenis interfaces pada component diagram adalah

a. provide dan proccess
d. provide dan required
b. proccess dan required
e. entity dan provide
c. requiered dan entity
1. Untuk menggambarkan struktur dan hubungan antara
komponen piranti lunak termasuk ketergantungan
diantaranya menggunakan
a. package diagram
b. class diagram
c. collaboration diagram
d. deployment diagram
e. component diagram