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
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
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
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
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
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 : XMLCreator : TestCase
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
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
XMLCreator TestCaseController
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
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
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()
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.
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.
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
