BAB IV ANALISIS DAN PERANCANGAN PERANGKAT · PDF fileSKPL ID Deskripsi SKP-F- 01 GXUnit...

13
IV-1 BAB IV ANALISIS DAN PERANCANGAN PERANGKAT LUNAK 4.1 Kebutuhan Perangkat Lunak 4.1.1 Deskripsi Umum Sistem Kakas pembangkit kasus uji unit testing yang dibangun diberi nama GXUnit. Komponen penyusun kasus uji umum yang sudah dirumuskan pada subbab 3.2 akan menjadi masukan untuk aplikasi ini. Pengguna akan diminta untuk memasukkan komponen penyusun kasus uji tersebut satu persatu kemudian masukan tersebut akan diterjemahkan ke dalam format XML. Kasus uji dalam format XML ini kemudian dapat dikonversi ke dalam bahasa pemrograman Java. Pengguna dapat menjalankan kasus uji dalam bahasa Java ini melalui GXUnit dimana GXUnit kemudian akan melakukan interaksi dengan salah satu xUnit framework, dalam kasus GXUnit ini digunakan framework JUnit. Secara global, proses kerja GXUnit dapat dilihat pada Gambar IV-1. Gambar IV-1 Arsitektur GXUnit Idealnya,GXUnit sebagai kakas pembangkit kasus uji unit testing ini memiliki kemampuan untuk menerjemahkan kasus uji dari format XML ke dalam berbagai bahasa pemrograman, dan mampu berinteraksi dengan beberapa xUnit framework dalam menjalankan pengujian. Agar mampu menerjemahkan kasus uji dari format XML ke beberapa bahasa pemrograman, kakas GXUnit harus dilengkapi dengan parser untuk masing-masing bahasa pemrograman dan pembangunan parser yang spesifik terhadap bahasa pemrograman ini merupakan hal yang cukup sukar diimplementasikan. Oleh karena itu, kakas GXUnit dibatasi hanya

Transcript of BAB IV ANALISIS DAN PERANCANGAN PERANGKAT · PDF fileSKPL ID Deskripsi SKP-F- 01 GXUnit...

IV-1

BAB IV ANALISIS DAN PERANCANGAN

PERANGKAT LUNAK

4.1 Kebutuhan Perangkat Lunak

4.1.1 Deskripsi Umum Sistem

Kakas pembangkit kasus uji unit testing yang dibangun diberi nama GXUnit. Komponen

penyusun kasus uji umum yang sudah dirumuskan pada subbab 3.2 akan menjadi masukan

untuk aplikasi ini. Pengguna akan diminta untuk memasukkan komponen penyusun kasus uji

tersebut satu persatu kemudian masukan tersebut akan diterjemahkan ke dalam format XML.

Kasus uji dalam format XML ini kemudian dapat dikonversi ke dalam bahasa pemrograman

Java. Pengguna dapat menjalankan kasus uji dalam bahasa Java ini melalui GXUnit dimana

GXUnit kemudian akan melakukan interaksi dengan salah satu xUnit framework, dalam kasus

GXUnit ini digunakan framework JUnit. Secara global, proses kerja GXUnit dapat dilihat

pada Gambar IV-1.

Gambar IV-1 Arsitektur GXUnit

Idealnya,GXUnit sebagai kakas pembangkit kasus uji unit testing ini memiliki kemampuan

untuk menerjemahkan kasus uji dari format XML ke dalam berbagai bahasa pemrograman,

dan mampu berinteraksi dengan beberapa xUnit framework dalam menjalankan pengujian.

Agar mampu menerjemahkan kasus uji dari format XML ke beberapa bahasa pemrograman,

kakas GXUnit harus dilengkapi dengan parser untuk masing-masing bahasa pemrograman

dan pembangunan parser yang spesifik terhadap bahasa pemrograman ini merupakan hal

yang cukup sukar diimplementasikan. Oleh karena itu, kakas GXUnit dibatasi hanya

IV-2

menerjemahkan kasus uji ke dalam satu bahasa pemrograman saja, yaitu bahasa Java yang

dianggap sebagai salah satu bahasa pemrograman yang luas penggunaannya serta xUnit

framework yang dipilih adalah JUnit yang dianggap sebagai salah satu xUnit framework yang

paling berkembang dan luas penggunaannya.

4.1.2 Spesifikasi Kebutuhan Perangkat Lunak

Berdasarkan penjelasan atau deskripsi perangkat lunak di atas, dapat disimpulkan beberapa

fungsionalitas yang harus dimiliki oleh GXUnit. Secara umum, GXUnit harus mampu

membantu pengguna dalam me-manage kasus uji, men-generate kasus ujinya dalam format

XML dan kemudian menerjemahkan kasus uji XML tersebut dalam bahasa pemrograman

tertentu agar nantinya dapat dijalankan melalui GXUnit yang akan memanggil xUnit

Framework tertentu untuk menjalankan kasus uji tersebut. Dalam pembangunan perangkat

lunak GXUnit ini penerjemahan kasus uji dilakukan ke dalam bahasa Java dan xUnit

Framework yang digunakan adalah JUnit. Selain itu, karena GXUnit merupakan kakas bantu

untuk membentuk kasus uji, maka sebaiknya memiliki antarmuka yang mudah digunakan

penguna.

Spesifikasi kebutuhan fungsional perangkat lunak GXUnit dapat dilihat pada Tabel IV-1.

Tabel IV-1 Spesifikasi Kebutuhan Fungsional Perangkat Lunak

SKPL ID Deskripsi

SKP-F- 01 GXUnit menyediakan fasilitas bagi user untuk memanipulasi (create,

update,delete) kasus uji

SKP-F-02 GXUnit mampu menyusun kasus uji general dari input yang diberikan user ke

dalam bentuk dokumen XML

SKP-F-03 GXUnit mampu melakukan parsing dokumen XML

SKP-F-04

GXUnit mampu melakukan konversi dari format kasus uji XML ke dalam

bahasa pemrograman Java sesuai spesifikasi JUnit dengan bantuan file

konfigurasi

SKP-F-05 GXUnit mampu menjalankan kasus uji dalam bahasa Java dengan cara

memanggil JUnit

IV-3

Spesifikasi kebutuhan non-fungsional perangkat lunak GXUnit dapat dilihat pada tabel IV-2.

Tabel IV-2 Spesifikasi Kebutuhan Non-Fungsional Perangkat Lunak

SKPL ID Deskripsi

SKP-NF- 01

GXUnit memiliki antarmuka yang memudahkan pengguna dalam penyusunan

kasus uji. GXUnit melakukan parsing kode program yang akan diuji untuk

mendapatkan daftar nama method yang ada dalam kode program tersebut

sehingga memudahkan pengguna dalam memilih method untuk diuji tanpa

harus melihat ke kode program asli.

4.1.3 Model Use Case

4.1.3.1 Diagram Use Case

Secara umum fungsionalitas perangkat lunak GXUnit telah dituangkan dalam spesifikasi

kebutuhan perangkat lunak. Kemudian untuk memodelkan perangkat lunak, digunakan

diagram use case. Dari fungsionalitas yang sebelumnya telah dijelaskan diturunkan menjadi

beberapa use case yang menggambarkan aksi yang dapat dilakukan pengguna terhadap

perangkat lunak GXUnit antara lain me-manage kasus uji dimana aksi ini dapat dibagi

menjadi tiga bagian yaitu membuat, mengubah, dan menghapus kasus uji. Kemudian,

pengguna dapat memilih untuk mengkonversi kasus uji dalam bentuk XML yang sudah ada

ke dalam bahasa pemrograman tertentu. Dari kasus uji yang sudah terbentuk, pengguna dapat

memilih untuk menjalankan kasus ujinya melalui GXUnit. Pada Gambar IV-2 berikut ini

digambarkan diagram use case dari perangkat lunak GXUnit yang akan dibangun.

Gambar IV-2 Diagram Use Case GXUnit

System

Tester

ManageKasusUji

KonversiKasusUji

UpdateKasusUji

<<extend>>

DeleteKasusUji

<<extend>>

CreateKasusUji

<<extend>>

RunningKasusUji

IV-4

4.1.3.2 Definisi Aktor

Terdapat satu aktor yaitu user sebagai aktor yang mengoperasikan perangkat lunak Definisi

aktor dapat dilihat pada Tabel IV-3.

Tabel IV-3 Definisi Aktor

No Aktor Deskripsi

GXU-A-01 Tester Aktor yang mengoperasikan perangkat lunak yang akan

memanfaatkan aplikasi untuk melakukan unit testing

4.1.3.3 Definisi Use Case

Definisi masing-masing use case dapat dilihat pada Tabel IV-4.

Tabel IV-4 Definisi Use Case

No Use Case Deskripsi Fungsi yang

dicakup

GXU-U-01 ManageKasusUji Memilih pengelolaan kasus uji antara

lain: create, update, dan delete SKP-F-01

GXU-U-02 CreateKasusUji Membuat kasus uji general baru dalam

bentuk arsip XML

SKP-F-01,

SKP-F-02

GXU-U-03 UpdateKasusUji

Melakukan update terhadap kasus uji

XML yang sudah di-generate

sebelumnya

SKP-F-01

GXU-U-04 DeleteKasusUji Menghapus kasus uji yang sudah ada SKP-F-01

GXU-U-05 KonversiKasusUji

Melakukan konversi kasus uji dari

bahasa XML ke bahasa pemrograman

Java menggunakan bantuan file

konfigurasi. Dalam kasus uji ini juga

dilakukan parsing dokumen XML

SKP-F-03,

SKP-F-04

GXU-U-06 RunningKasusUji

Menjalankan kasus uji dalam bahasa

pemrograman Java dengan cara

memanggil xUnit Framework yang

bersangkutan yaitu JUnit

SKP-F-05

IV-5

4.1.3.4 Skenario Use Case

Setiap use case yang telah didefinisikan akan didefinisikan skenario use case yang merupakan

gambaran detail interaksi antara aktor dengan perangkat lunak GXUnit. Contoh skenario

normal untuk use case ManageKasusUji(GXU-U-03) dan CreateKasusUji (GXU-U-02) dapat

dilihat pada Tabel IV-5. Daftar lengkap skenario setiap use case dapat dilihat pada Lampiran

Acuan Teknis Subbab 2.3.4.

Tabel IV-5 Skenario ManageKasusUji dan CreateKasusUji

Aksi Aktor Reaksi Sistem

SKENARIO NORMAL (GXU-SK-02-1):

1.Memilih halaman manage kasus uji

2.Menampilkan halaman manage kasus uji

3.Memilih aksi create

4.Menampilkan form create kasus uji

5.Memasukkan data yang diminta oleh sistem sebagai input dalam membuat kasus uji baru

6.Memilih opsi untuk men-generate kasus uji dalam format XML

7.Menyusun semua input yang sudah diberikan aktor menjadi susunan kasus uji

8 .Membentuk kasus uji dalam arsip XML

SKENARIO ALTERNATIF 1, kegagalan membentuk arsip XML (GXU-SK-02-2):

1.Memilih halaman manage kasus uji

2.Menampilkan halaman manage kasus uji

3.Memilih aksi create

4.Menampilkan form create kasus uji

5.Memasukkan data yang diminta oleh sistem sebagai input dalam membuat kasus uji baru

6.Memilih opsi untuk men-generate kasus uji dalam format XML

7.Menyusun semua input yang sudah diberikan aktor menjadi susunan kasus uji

8.Membentuk kasus uji dalam format XML

9.Gagal membentuk kasus uji dalam format XML, menampilkan pesan kesalahan

Post kondisi: Terbentuknya sebuah dokumen XML yang merupakan representasi kasus uji

general

IV-6

4.2 Model Analisis

4.2.1 Realisasi Use Case Tahap Analisis

Pada realisasi use case tahap analisis ini akan didefiniskan interaksi antar elemen pada

perangkat lunak untuk setiap use case yang ada. Interaksi antar elemen untuk setiap use case

digambarkan menggunakan sequence diagram yang disusun berdasarkan skenario yang

sebelumnya sudah dijabarkan. Contoh sequence diagram use case CreateKasusUji untuk

skenario normal dapat dilihat pada Gambar IV-3 dan sequence diagram untuk use case lain

dapat dilihat pada Lampiran Acuan Teknis Subbab 3.1.

Gambar IV-3 Sequence Diagram Analisis ManageKasusUji dan CreateKasusUji untuk skenario

normal

Pada sequence diagram tersebut terdapat beberapa kelas yang terlibat dan kelas-kelas

tersebut digambarkan melalui Diagram Kelas Analisis. Pada diagram kelas analisis ini

terdapat perbedaan penggambaran setiap jenis kelas, apakah kelas boundary, control, atau

entity, dan interaksi antar kelas direpresentasikan dengan adanya garis asosiasi antara dua

kelas. Contoh diagram kelas analisis use case CreateKasusUji dapat dilihat pada Gambar IV-4

dan diagram kelas analisis selengkapnya dapat dilihat pada Lampiran Acuan Teknis Subbab

3.1.

: Tester : GXUInterface : TestCaseController : TestCase : XMLCreator

1 : Memilih halaman manage kasus uji

2 : Menampilkan halaman manage kasus uji

3 : Memilih aksi create kasus uji

4 : Menampilkan form create kasus uji

5 : Memasukkan data untuk membuat kasus uji

6 : Memilih men-generate kasus uji general

7 : menyusun input menjadi susunan kasus uji

8 : membentuk kasus uji sebagai dokumen XML

9 : menampilkan pesan keberhasilan

IV-7

Gambar IV-4 Diagram Kelas Analisis CreateKasusUji

4.2.2 Kelas Analisis

Tabel IV-5 berikut berisikan nama-nama kelas yang terlibat dalam setiap use case yang

terdapat pada analisis aplikasi GXUnit ini, beserta masing-masing jenisnya (boundary,

controller, atau entity).

Tabel IV-6 Kelas Analisis

No Nama Kelas Jenis

1 GXUInterface Boundary 2 TestCaseController Controller 3 XMLCreator Controler 4 XMLParser Controller 5 ConfigParser Controller 6 Converter Controller 7 CompilerJava Controller 8 JUnitRunner Controller 9 CSVController Controller 10 TestCase Entity 11 ConvertedTestCase Entity

4.3 Model Perancangan

4.3.1 Batasan Perancangan

Perancangan perangkat lunak GXUnit ini berpedoman pada framework MVC (Model View

Controller). Dalam implementasi MVC, digunakan:

a. Java Plain Class sebagai Model

b. Java Frame sebagai View

c. Java Plain Class sebagai Controller

GXUInterface

TestCase

XMLCreatorTestCaseController

IV-8

Model dalam perancangan perangkat lunak ini merupakan kelas Java biasa berupa objek yang

memiliki serangkaian atribut dan method. Dalam proses berjalannya perangkat lunak ini,

berbagai macam data yang diperlukan akan disimpan sementara ke dalam bentuk objek.

View berfungsi sebagai boundary antara perangkat lunak dengan user. View bertugas

menampilkan berbagai form kepada user agar user dapat memasukkan data input yang

diperlukan oleh perangkat lunak.

Controller berfungsi sebagai pengatur logika jalannya perangkat lunak. Controller juga

merupakan penghubung antara view dengan model.

4.3.2 Perancangan Rinci Struktur Kelas

Proses analisis sebelumnya telah menghasilkan beberapa kelas yang terlibat dalam perangkat

lunak GXUnit ini. Pada tahapan perancangan ini dilakukan identifikasi lebih lanjut terhadap

hasil proses analisis sebelumnya. Identifikasi dilakukan sedekat mungkin dengan kode

program yang akan diimplementasikan selanjutnya sehingga benar-benar dapat

merepresentasikan perangkat lunak sesungguhnya.

Dari daftar kelas analisis pada subbab 4.2.2, terdapat kelas yang dipecah menjadi beberapa

kelas pada tahap perancangan ini, misalnya kelas TestCase yang dipecah menjadi kelas

Variabel, TestMethod, TestSuite, dan TestCase. Hal ini dilakukan untuk

memudahkan pemrosesan setiap komponen penyusun kasus uji.

Keseluruhan kelas perancangan beserta keterhubungannya satu sama lain dapat dilihat

padaGambar IV-6.

4.3.3 Kelas Perancangan

Tabel IV-7 berikut berisikan daftar kelas perancangan yang semuanya berasal dari kelas

analisis. Dalam tabel ini dapat dilihat kesesuaian antara kelas pada tahap analisis dengan kelas

pada tahap perancangan.

Tabel IV-7 Daftar Kelas Perancangan

No Nama Kelas Perancangan Nama Kelas Analisis Keterangan

1 GXUInterface GXUInterface Kelas boundary

2 TestCaseController TestCaseController Controller yang menangani

operasi terhadap kasus uji

3 XMLCreator XMLCreator Generator arsip XML

4 XMLParser XMLParser Parser kasus uji XML

IV-9

No Nama Kelas Perancangan Nama Kelas Analisis Keterangan

5 ConfigParser ConfigParser Parser file konfigurasi

6 Converter Converter Generator kasus uji dalam

bahasa pemrograman tertentu

7 CompilerJava CompilerJava

Controller yang memanggil

JavaCompiler untuk

mengkompilasi kasus uji

8 JunitRunner JUnitRunner Controller yang memanggil

TestRunner pada JUnit

9 CSVController CSVController Parser dan generator file

eksternal tambahan

10 TestCase TestCase Entity test case

11 TestSuite TestCase Entity test suite

12 TestMethod TestCase Entity test method

13 Variable TestCase Entity variable

14 ConvertedTestCase ConvertedTestCase Entity test case dalam bahasa

pemrograman

4.3.4 Perancangan Antarmuka

4.3.4.1 Perancangan Antarmuka ManageKasusUji

Perancangan antarmuka untuk manage kasus uji dapat dilihat pada Gambar IV-5. Pada

antarmuka ini pengguna dapat memilih satu dari tiga aksi yang mungkin dilakukan yaitu

membuat kasus uji baru, melakukan update terhadap kasus uji yang sudah dibangkitkan

sebelumnya atau menghapus kasus uji.

Gambar IV-5 Rancangan Antarmuka ManageKasusUji

IV-10

Gambar IV-6 Diagram Kelas Perancangan Keseluruhan

GXUInterface<<boundary>>

TestCaseController<<control>>

-message: String-creator: XMLCreator

+TestCaseController()+makeTestMethod(name, assertion)+makeTestCase(name, var, testmethod)+makeVariable(type, name, value)+makeTestSuite(name, testcase, method, suite)+makeAssertion()+convertTestCase(testcase)+deleteTestCase(fileName)+updateTestCase(fileName)+updateFile()

XMLCreator<<control>>

-myData: TestCase-dom: Document-testcase: TestCase

+XMLCreator(testcase)+runXMLCreator(testcase)+loadData(testcase)+createDocument()+createDOMTree(testcase)+createSetupVarEle(testcase)+createTestingMethEle(testcase)+printToFile(testcase)

TestCase<<entity>>

-name: String-var: Variable-testmethod: TestMethod-testSuite: TestSuite

+TestCase(name, var, testmethod)+getName()+getTestMethod()+getVar()+getTestSuite()

Variable<<entity>>

-type: String-value: String-name: String

+Variable(type, value, name)+getName()+getType()+getValue()

TestMethod<<entity>>

-assertion: Assertion-name: String

+TestMethod(origin, assertion, result, params, n)+getAssertion()+getName()

XMLParser<<control>>

-myTestCase: TestCase-dom: Document

+XMLParser()+runXMLParser()+parseXMLFile()+parseDocument()+getTestCase(element)+getTextValue(element, tagName)

TestSuite<<entity>>

-name: String-member_testcase: String-member_method: String-member_suite: String

+TestSuite(name, testcase, method, suite)+getName()+getTestCase()+getMethod()+getSuite()

Converter<<control>>

-config: Configuration

+Converter()+runConverter()+buildInit()+buildVar()+buildTestMethod()+buildTestSuite()+printToFile()

Configuration<<entity>>

-language: String-ext: String-type: String-extend: String-include: String-construct: String-var_location: String-varsetup_param: String-varcleanup_param-meth_type: String-meth_assert: String-suite_location: String-suite_file: String-suite_init: String-suite_build: String-suite_new: String-suite_addtcase: String-suite_addmeth: String-suite_addsuite: String-suite_clean: String

+Configuration()+getLanguage()+getExt()+getType()+getExtend()+getInclude()+getConstruct()+getVarLocation()+getVarSetupParam()+getVarCleanupParam()+getMethType()+getMethAssert()+getSuiteLocation()+getSuiteFile()+getSuiteInit()+getSuiteBuild()+getSuiteNew()+getSuiteAddTC()+getSuiteAddTM()+getSuiteAddTS()+getSuiteClean()

ConfigParser<<control>>

-myConfig: Configuration-dom: Document

+ConfigParser()+runConfigParser()+parseXMLFile()+parseDocument()+getConfiguration()+getTextValue()

RunTestController<<control>>

-testCase: File-xUnit: String-status: int

+RunTestController()+runTest(testCase, XUnit)

ReportController<<control>>

+ReportController()+getReport(testcase)+processReport()+viewReport()

TestReport<<entity>>

-testcase: TestCase-result: String-pass: String-fail: String-summary: String

+TestReport()+getTestCase()+getResult()+getPass()+getFail()+getSummary()

XUnitController<<control>>

+XUnitController()+runTest(testcase)+getReport(testcase)

CompilerJava<<control>>

-fileName: String

+CompilerJava(fileName)+compileFile()

CSVController<<control>>

-fileName

+processLineByLine()+readCSV()+updateCSV()

Assertion<<entity>>

-type: String-actual: String-expected: String-origin_actual: String-method_actual: String-n: int-param_actual: String-origin_expected: String-method_expected: String-n2: int-param_expected: String-priora_method: boolean-priore_method: boolean-origin_priora: String-method_priora: String-n3: int-param_priora: String-origin_priore: String-method_priore: String-n4: int+param_priore: String

+Assertion(type, actual, expected)+getType()+getExpected()+getOrigin_actual()+getMethod_actual()+getN()+getParam_actual()+getOrigin_expected()+getMethod_expected()+getN2()+getParam_expected()+getPriora_method()+getPriore_method()+getOrigin_priora()+getMethod_priora()+getN3()+getParam_priora()+getOrigin_priora()+getMethod_priora()+getN4()+getParam_priore()

ConvertedTestCase<<entity>>

-fileName-language-location

+ConvertedTestCase()

JUnitRunner<<control>>

-fileName: String

+JUnitRunner(fileName)+runTestCase()

IV-11

4.3.4.2 Perancangan Antarmuka CreateKasusUji

Antarmuka untuk membentuk kasus uji baru dapat dilihat pada Gambar IV-7. Pada antarmuka

berbentuk form ini pengguna dapat memasukkan beberapa data yang diperlukan untuk

membentuk sebuah kasus uji.

Gambar IV-7 Rancangan Antarmuka Create Kasus Uji

4.3.4.3 Perancangan Antarmuka UpdateKasusUji

Antarmuka untuk memilih kasus uji yang akan di-update dapat dilihat pada Gambar IV-8.

Pada antarmuka ini pengguna dapat memilih file kasus uji yang akan di-update. Setelah user

memilih kasus uji mana yang akan di-update maka selanjutnya komponen kasus uji tersebut

akan ditampilkan dalam form yang sama dengan form create kasus uji pada Gambar IV-7 dan

user dapat melakukan update melalui form tersebut.

IV-12

Gambar IV-8 Antarmuka UpdateKasusUji untuk memilih file kasus uji

4.3.4.4 Perancangan Antarmuka DeleteKasusUji

Antarmuka untuk melakukan penghapusan kasus uji dapat dilihat pada Gambar IV-9. Pada

antarmuka ini pengguna dapat memilih arsip kasus uji yang akan dihapus. Kemudian proses

penghapusan dilakukan dengan menekan tombol “delete”.

Gambar IV-9 Antarmuka DeleteKasusUji

4.3.4.5 Perancangan Antarmuka KonversiKasusUji

Antarmuka untuk melakukan konversi kasus uji dapat dilihat pada Gambar IV-10. Pada

antarmuka ini pengguna dapat memilih file test case yang akan diuji beserta file konfigurasi

yang digunakan untuk membantu proses konversi.

IV-13

Gambar IV-10 Antarmuka KonversiKasusUji

4.3.4.6 Perancangan Antarmuka RunningKasusUji

Antarmuka untuk melakukan running kasus uji dapat dilihat pada Gambar IV-11. Pada

antarmuka ini pengguna dapat memilih file test case yang akan dijalankan (di-running)

beserta xUnit Framework yang digunakan untuk menjalankan kasus uji.

Gambar IV-11 Antarmuka Running Kasus Uji