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-1
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 SKP-F- 01
SKP-F-02 SKP-F-03
Deskripsi GXUnit menyediakan fasilitas bagi user untuk memanipulasi (create, update,delete) kasus uji GXUnit mampu menyusun kasus uji general dari input yang diberikan user ke dalam bentuk dokumen XML GXUnit mampu melakukan parsing dokumen XML GXUnit mampu melakukan konversi dari format kasus uji XML ke dalam
SKP-F-04
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 GXUnit memiliki antarmuka yang memudahkan pengguna dalam penyusunan kasus uji. GXUnit melakukan parsing kode program yang akan diuji untuk
SKP-NF- 01
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. System CreateKasusUji <<extend>> ManageKasusUji
<<extend>> UpdateKasusUji
<<extend>> DeleteKasusUji KonversiKasusUji Tester
RunningKasusUji
Gambar IV-2 Diagram Use Case GXUnit
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
GXU-A-01
Tester
Deskripsi 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
GXU-U-01
ManageKasusUji
GXU-U-02
CreateKasusUji
Fungsi yang
Deskripsi
dicakup
Memilih pengelolaan kasus uji antara lain: create, update, dan delete
SKP-F-01
Membuat kasus uji general baru dalam SKP-F-01, bentuk arsip XML
SKP-F-02
Melakukan update terhadap kasus uji GXU-U-03
UpdateKasusUji
XML
yang
sudah
di-generate SKP-F-01
sebelumnya GXU-U-04
DeleteKasusUji
Menghapus kasus uji yang sudah ada
SKP-F-01
Melakukan konversi kasus uji dari bahasa XML ke bahasa pemrograman GXU-U-05
KonversiKasusUji
Java
menggunakan
bantuan
file
konfigurasi. Dalam kasus uji ini juga
SKP-F-03, SKP-F-04
dilakukan parsing dokumen XML Menjalankan kasus uji dalam bahasa GXU-U-06
RunningKasusUji
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.
: 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-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.
IV-7
GXUInterface
TestCaseController
XMLCreator
TestCase
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 2 3 4 5 6 7 8 9 10 11
GXUInterface TestCaseController XMLCreator XMLParser ConfigParser Converter CompilerJava JUnitRunner CSVController TestCase ConvertedTestCase
Boundary Controller Controler Controller Controller Controller Controller Controller Controller Entity 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
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
3
XMLCreator
XMLCreator
Generator arsip XML
4
XMLParser
XMLParser
Parser kasus uji XML
Controller yang menangani operasi terhadap kasus uji
IV-9
No
Nama Kelas Perancangan
Nama Kelas Analisis
5
ConfigParser
ConfigParser
6
Converter
Converter
Keterangan Parser file konfigurasi Generator kasus uji dalam bahasa pemrograman tertentu Controller yang memanggil
7
CompilerJava
CompilerJava
JavaCompiler untuk mengkompilasi kasus uji Controller yang memanggil
8
JunitRunner
JUnitRunner
9
CSVController
CSVController
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
TestRunner pada JUnit Parser dan generator file eksternal tambahan
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
<<entity>> Assertion
<<entity>> TestMethod
<<entity>> Variable
-assertion: Assertion -name: String
-type: String -value: String -name: String
+TestMethod(origin, assertion, result, params, n) +getAssertion() +getName()
+Variable(type, value, name) +getName() +getType() +getValue()
<<entity>> Configuration -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()
<
> TestCaseController
<> XMLCreator
-message: String -creator: XMLCreator
-myData: TestCase -dom: Document -testcase: TestCase
+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(testcase) +runXMLCreator(testcase) +loadData(testcase) +createDocument() +createDOMTree(testcase) +createSetupVarEle(testcase) +createTestingMethEle(testcase) +printToFile(testcase)
<> ConfigParser
+processLineByLine() +readCSV() +updateCSV()
<<entity>> TestCase -name: String -var: Variable -testmethod: TestMethod -testSuite: TestSuite +TestCase(name, var, testmethod) +getName() +getTestMethod() +getVar() +getTestSuite()
<> ReportController
<> Converter
-fileName
+TestSuite(name, testcase, method, suite) +getName() +getTestCase() +getMethod() +getSuite()
+XMLParser() +runXMLParser() +parseXMLFile() +parseDocument() +getTestCase(element) +getTextValue(element, tagName) <> GXUInterface
<> CSVController
-name: String -member_testcase: String -member_method: String -member_suite: String
-myTestCase: TestCase -dom: Document
+ConfigParser() +runConfigParser() +parseXMLFile() +parseDocument() +getConfiguration() +getTextValue()
+Converter() +runConverter() +buildInit() +buildVar() +buildTestMethod() +buildTestSuite() +printToFile()
<<entity>> TestSuite
<> XMLParser
-myConfig: Configuration -dom: Document
-config: Configuration
-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
<<entity>> ConvertedTestCase
+ReportController() +getReport(testcase) +processReport() +viewReport()
-fileName -language -location
<> RunTestController
+ConvertedTestCase()
-testCase: File -xUnit: String -status: int
<> JUnitRunner -fileName: String +JUnitRunner(fileName) +runTestCase()
<> CompilerJava
+RunTestController() +runTest(testCase, XUnit)
<> XUnitController +XUnitController() +runTest(testcase) +getReport(testcase)
-fileName: String +CompilerJava(fileName) +compileFile()
Gambar IV-6 Diagram Kelas Perancangan Keseluruhan
<<entity>> TestReport -testcase: TestCase -result: String -pass: String -fail: String -summary: String +TestReport() +getTestCase() +getResult() +getPass() +getFail() +getSummary()
+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()
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