Pertemuan 4

OOP

Febriyanno Suryana, S.Kom, MMsurya_gsc04@yahoo.com

0852 7474 1981 SI -2011

Object Oriented Programming??

OOP merupakan metodologi dalam pemrograman yang di ciptakan untuk memodelkan kasus-kasus nyata ke dalam suatu objek.

Objek merupakan kombinasi antara struktur data dan perilaku dalam satu entitas/objek.

Merupakan strategi perancangan dimana perancang sistem memikirkan ‘benda’ dan bukan operasi atau fungsi.

2

Object?

Secara spesifik objek adalah sesuatu paket yang merupakan kumpulan data dan method (perilaku)

Data Sesuatu yg menentukan karakteristik sebuah

objek Method

Aksi terhadap data (cara suatu objek melakukan sesuatu).

Sebagai contoh, objek manusia memiliki data-data seperti: tinggi badan, berat badan, warna kulit dsb. Sedangkan perilaku/method yang dimiliki manusia misalnya cara berjalan, cara bicara dan sebagainya

3

Object…

Dalam pemrograman, data-data di dalam objek akan direpresentasikan dengan variabel atau konstanta, sedangkan perilaku akan direpresentasikan dengan prosedur atau fungsi, yang kemudian disebut dengan method.

Ilustrasi tersebut digambarkan sebagai berikut:

4

objek

data

method

Berupa variabel atau konstanta

Berupa prosedur atau fungsi

Object…

5

Class?

Istilah yg masih berkaitan erat dgn objek adalah kelas. Kelas merupakan struktur umum dari objek2 tertentu.

Misal saya, anda dan yg lainnya adalah objek, yg termasuk dlm kelas manusia.

6

Class...

Class adalah suatu template yang digunakan sebagai pola desain suatu objek.

Class : rancangan mobilObjek : mobil nyata

Class harus di instansiasikan (dibuat objeknya) terlebih dahulu.

7

8

Class

Objek

Class…

9

Data

Method

Class…

10

Class…

Dlm bahasa pemrograman, sering dikatakan bahwa objek merupakan instansiasi dari sebuah kelas.

Instansiasi merupakan wujud nyata dari suatu objek.

Sebagai contoh: jika terdpt objek manusia, maka udin, amir dan ali adalah instance dari objek manusia.

dianalogikan juga bahwa tipe data adalah kelas, sedangkan var yg didefinisikan berdasarkan tipe data tersbt adalah objek. contoh jika:

x : integer ; berarti objek x adalah instance dari kelas integer.

11

Cth kode program prosedural :

<php /* procedural.php */ print "Hello, world."; ?>

12

Cth kode program OOP :

<php /* objek.php */ class HelloWorld { function myPrint() { print "Hello, world."; } } $myHelloWorld = new HelloWorld $myHelloWorld->myPrint(); ?>

13

Konsep Object Oriented

Kelas Objek Atribut/Data Metoda/Servis/Operator/Perilaku Message Event State Skenario

14

Konsep Object Oriented…

15

Konsep Object Oriented…

16

Konsep Object Oriented…

17

Konsep Object Oriented…

18

Konsep Object Oriented…

19

Objek

: Furniture

Karakteristik pengembangan PL berorientasi Objek :

Encapsulation Inheritance Polymorphism

20

Karakteristik pengembangan PL berorientasi Objek…

21

Karakteristik pengembangan PL berorientasi Objek…

22

OOP…

23

Pertemuan 4

Dasar – dasar pengujian perangkat lunak

Febriyanno Suryana, S.Kom, MMsurya_gsc04@yahoo.com

0852 7474 1981 SI -2011

Pengujian / testing Adalah proses eksekusi suatu program dengan

tujuan untuk menemukan error (Berard, 1994). Elemen kritis dari jaminan kualitas perangkat

lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean.

Pengujian sebaiknya menemukan kesalahan yang tidak disengaja dan pengujian dinyatakan sukses jika berhasil memperbaiki kesalahan tersebut.

Pengujian bertujuan untuk menunjukkan kesesuaian fungsi-fungsi perangkat lunak dengan spesifikasinya.

25

Apa yang di uji?

Test data: Input yang yang direncanakan digunakan oleh sistem.

Test cases: Input yang digunakan untuk menguji sistem dan memprediksi output dari input jika sistem beroperasi sesuai dengan spesifikasi.

26

Teknik dalam pengujian

27

Design testcases

Prepare testdata

Run programwith test data

Compare resultsto test cases

Testcases

Testdata

Testresults

Testreports

Pertanyaan dasar yg akan dijawab pada software testing

Misi dari testing.◦ Mengapa anda melakukan testing ? Apa yang ingin

anda pelajari ? Pemilihan strategi

◦ Bagaimana anda mengorganisasikan pekerjaan anda untuk meraih misi anda?

Oracle/sematic.◦ Bagaimana anda mengetahui bahwa program itu lolos

testing atau gagal? Adanya kemungkinan testing tidak sempurna

◦ Apa yang harus dilakukan untuk menyelesaikan testing secara lengkap?

Mengukur permasalahan◦ Sejauh mana testing dianggap cukup?

28

Prinsip dasar pengujian (sebagai dasar membuat test case)

Semua pengujian harus ditelusuri sampai ke persyaratan pelanggan.

Pengujian harus direncanakan jauh sebelum pengujian itu dilakukan.

Prinsip pareto berlaku untuk pengujian perangkat lunak, maksudnya 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program

Pengujian harus dimulai “dari yang kecil” dan berkembang menjadi pengujian “yang besar”

Agar lebih efektif, pengujian harus dilakukan oleh pihak ketiga yang independen

29

Langkah-langkah dalam pengujian PL?

Tentukan sasaran pengujian Tentukan karakteristik pengujian Testabilitas software

30

Sasaran Pengujian

Test case yang baik adalah test case yang memiliki profitabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.

Pengujian yang sukses adalah pengujian yang mengungkapkan semua kesalahan yang belum pernah ditemukan sebelumnya

31

Karakteristik Pengujian

Testing dimulai dari level modul dan bekerja keluar ke arah integrasi pada sistem berbasiskan komputer.

Teknik testing yang berbeda sesuai dengan poin-poin yang berbeda pada waktunya.

Testing dilakukan oleh software developer dan untuk proyek yang besar oleh group testing yang independen

Testing dan debugging adalah aktivitas yang berbeda tetapi debugging harus diakomodasikan pada setiap strategi testing.

32

Testabilitas software

Seberapa mudah sebuah program komputer dapat diuji.

Karena pengujian sangat sulit, perlu diketahui apa yang dapat dilakukan untuk dapat membuatnya lebih mudah.

33

Kriteria Software yang baik

1. OperabilitySemakin baik sw itu bekerja, semakin efisien ia dapat diuji.

2. ObservabilityApa yang anda lihat adalah apa yang anda uji.

3. ControllabilitySemakin baik kita mengontrol sw, semakin banyak pengujian yang dapat di otomatisasi dan dioptimalkan.

4. DecomposabilityDengan mengontrol ruang lingkup pengujian, kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih detail.

34

Kriteria Software yang baik…cont

5. SimplicitySemakin sedikit yang diuji, semakin cepat pengujian.

6. StabilitySemakin sedikit perubahan, semakin sedikit gangguan dalam pengujian.

7. Kemampuan dapat dipahamiSemakin banyak informasi yang dimiliki semakin detail pengujiannya.

35

Atribut pengujian yang baik

1. Memiliki probabilitas yang tinggi untuk menemukan error.o Tester harus memahami software yang diuji dan memikirkan

bagaimana software itu bisa gagal.

2. Pengujian yang baik tidak redundant/ganda.o Setiap pengujian harus mempunyai tujuan yang berbeda.

3. Pengujian yang baik tidak terlalu sederhana namun juga tidak terlalu kompleks.o Tidak mengkombinasikan beberapa test case ke dalam sebuah test

case.o Test case dilakukan secara terpisah.

36

Desain test case :

1. Pengetahuan fungsi yang spesifik dari produk yang telah dirancang untuk diperlihatkan, test dapat dilakukan dengan menilai masing-masing fungsi apakah telah berjalan sebagaimana yang diharapkan.

2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan dengan memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya.

37

Pendekatan dalam testing :

38

Pendekatan dalam testing…

39

Pendekatan dalam testing…

40

Pengujian Dasar

41

Pengujian Dasar…

Full Testing◦ Dimulai dari awal pegembangan sampai produk

diterima user Partial Testing

◦ Dimulai dari waktu setelah fase desain Endgame Testing

◦ Berorientasi pada validasi Audit Level Testing

◦ Untuk memenuhi standar dan berorientasi pada proses audit

42

Proses Testing…

43

Proses Testing

1. Unit testingPengujian masing-masing unit komponen program untuk meyakinkan bhw sudah beroperasi secara benar

2. Module TestingPengujian terhadap koleksi unit-unit komponen yang saling berhubungan.

3. Sub-system TestingPengujian terhadap koleksi module-module yang membentuk suatu sub-system (aplikasi)

44

Proses Testing…

4. System TestingPengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system

5. Acceptance TestingPengujian terakhir 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)

45

Proses Testing…

Component testing • Pengujian komponen-komponen program• Biasanya dilakukan oleh component

developer (kecuali untuk system kritis) Integration testing

• Pengujian kelompok komponen-komponen yang terintegrasi untuk membentuk sub-system ataupun system

• Dilakukan oleh tim penguji yang independen• Pengujian berdasarkan spesifikasi sistem

46

Testing Life Cycle…

47

Testing Life Cycle

Verifikasi adalah proses evaluasi sebuah sistem atau komponen untuk mendefenisikan bahwa produk memiliki fase pengembangan yang benar dimulai dari awal fase. verifikasi berbasis prosesAre we building the product right ? [Boehm,1984]

validasi adalah proses evaluasi sebuah sistem atau komponen selama atau pada akhir pengembangan untuk mendefenisikan bahwa produk sesuai dengan spesifikasi kebutuhan.validasi berbasis produkAre we building the right product ? [Boehm,1984]

48

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

Jadwal Testing Prosedur Pencatatan Hasil dan Prosedur Kebutuhan akan Hardware dan Software Kendala-kendala

◦ Mis: kekurangan staff, alat, waktu dll.

49

Prioritas Pengujian

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

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

50

Hubungan antara rencana pengujian dan proses pengembangan system

51

Failures, Faults

Failure: output yang tidak benar/tidak sesuai ketika sistem dijalankan

Fault: kesalahan dalam source code yang mungkin menimbulkan failure ketika code yg fault tsb dijalankan

52

Failure Class Deskripsi

Transient Muncul untuk input tertentu

Permanent Muncul untuk semua input

Recoverable Sistem dapat memperbaiki secara otomatis

Unrecoverable Sistem tidak dapat memperbaiki secara otomatis

Non-corrupting Failure tidak merusak data

Corrupting Failure yang merusak sistem data

53

Contoh Test CaseTest Case ID: CUST.01Function: Menambah satu pelanggan baruData Assumptions: Customer database sudah di-restore Deskripsi: Menambah satu pelanggan, melalui Form Tambah Pelanggan, dan menampilkan validasi pelanggan baru tersebut pada Tampilan Pelanggan

Aksi State Awal atau Tampilan

Data Hasil yg diharapkan (Response)

1. Aplikasi Penjualan dijalankan melalui Icon di windows

Program Manager

Tidak Ada Menu utama Aplikasi Penjualan

2. Pilih Pelanggan pada Menu Tampilan.

Tampilan Utama Penjualan

Tidak Ada Pelanggan menampilkan Tampilan..

3. Click pilihan All Customers Tampilan Pelanggan

Tidak Ada Window Pelanggan ditampilkan dengan judul “Pelanggan”.

4. Click pada Button Tambah Customer - All Customer

Tidak Ada Tampilan Tambah Pelanggan ditampilkan

5. Masukkan data untuk menambah satu pelanggan baru dan click satu kali button tambah.

Tambah Pelanggan

Nama: Andi NoorAlamat: Jl. XxxxKota: Jakarta

Data ditampilkan pada field-field yg sesuai (atau seperti yg ditampilkan oleh data sheet).

Bentuk laporan penilaian

Laporan Hasil Matrik test case Berdasarkan faktor penggunaan

54

55

Nomor Kesalahan :Nama Program:Tipe Laporan: (1. Usulan, 2.Salah Perancangan, 3. Salah program, 4. Salah dokumentasi, 5. Query)

Severity: 1. Minor, 2. Serius, 3. FatalAttachment (Y/N)

Adakah kesalahan (Y/T)Bagaimana bentuk kesalahan:Bagaimana kesalahan dapat terjadi:Usulan Perbaikan:Nama Penguji:Tanggal Uji:---------------------------------Diisi oleh programmer:

Ditujukan kepada: Tanggal:Resolusi: 1. Dapat diperbaiki2. Tidak dapat diperbaiki3. Pengujian ditarik kembali4. Bekerja sesuai spesifikasi5. Kesalahan tidak dapat dihasilkan lagi6. Tidak setuju dengan usulan-----------Sertifikasi ResolusiDibuat oleh:

Programmer, Tester: Tanggal:Project Manager:

1. Laporan hasil test

56

Hasil yang diharapkan

Tujuan Test Penolakan Pesan Kesalahan yg ditampilkan

Rancangan Test Case

Hasil yang sebenarnya

Menguji perhitungan digit input

X X Input nomor rekening (yang sudah diubah urutannya)

Pesan kesalahan penolakan dan ditampilkan

Menentukan nomor-nomor departemen dicek

X X Input nomor departemen yang salah

Pesan kesalahan penolakan dan ditampilkan

Keakuratan perhitungan

Pembayaran lembur untuk pekerja jam-jaman selama 15 jam

Pembayaran lembur sebesar 1.5 kali pembayaran normal

2. Matrik test case

57

Faktor Usabilitas

A Mudah digunakan 1 2 3 4 5

B User Friendly 1 2 3 4 5

C Mudah dimengerti 1 2 3 4 5

D Tingkat Kepercayaan 1 2 3 4 5

E Tingkat kesesuaian dengan yg dibutuhkan

1 2 3 4 5

F Waktu Respons 1 2 3 4 5

G Tingkat comfortable 1 2 3 4 5

3. Penilaian didasarkan pada faktor penggunaan

End Session

58