Pengantar: Pembangkitan Data Uji dari Spesifikasi statechart

Pengantar: Pembangkitan Data Uji dari Spesifikasi Statechart (Irya Wisnubhadra)

Pengantar: Pembangkitan Data Uji dari Spesifikasi statechart Irya Wisnubhadra Program studi Teknik Informatika, Fakultas Teknologi Industri Universitas Atma Jaya Yogyakarta Jl. Babarsari No. 43 Yogyakarta 55281 E-mail: [email protected]

Abstract This research focused on generating test case and testing from statechart specification. In software industry, most testing is conducted based on source code. Testing based on specification is only implemented informally and manually that make this testing ineffective. To overcome this ineffectiveness problem, automatic test case generation and testing is implemented. Statechart is chosen as specification for test case generation because it provides the overall dynamic behavior of the system. To demonstrate this processes, a prototype that called SCDTG (StateChart Data Test Generator) has been developed. SCDTG has the following functions: Interactive editor for generating XML notation-based statechart specification (inspired from UML), Data test generator with following coverage criteria: Transition Coverage, Full Predicate Coverage and Transition Pair Coverage, C++ source code generator that represents statechart in statemachine class. C++ test script (test driver) generator. SCDTG is designed in UML, coded in C++ and implemented under MS-DOS and LINUX operating system. Keywords: Testing, Test Case Generation, Specification, Statechart, Coverage criteria.

1. Latar Belakang Sejak tahun 1950-an perangkat lunak mulai banyak dikembangkan oleh manusia untuk membantunya dalam memecahkan berbagai macam persoalan yang bervariasi dari persoalan keseharian sampai persoalan yang sangat kompleks. Perangkat lunak dikembangkan dalam beberapa tahap yaitu : analisis, perancangan, pemrograman dan pengujian. Perangkat lunak dalam pengembangannya harus diuji karena proses analisis, perancangan dan pemrogramannya tidak bebas kesalahan. Pengujian dilakukan untuk mengetahui apakah perangkat lunak telah sesuai dengan kebutuhan. Pengujian diharapkan dapat menemukan kesalahan pada perangkat lunak. Pada pengujian, untuk dapat menemukan kesalahan pada perangkat lunak diperlukan data uji. Data uji dapat secara efektif ditentukan jika proses pembangkitannya dilakukan secara otomatis. Pengujian perangkat lunak terdiri dari pengujian unit, pengujian integrasi dan pengujian sistem. Pengujian sistem adalah pengujian berdasar spesifikasi / kebutuhan perangkat lunak. Pengujian ini biasanya dilakukan berdasarkan spesifikasi yang dianalisa secara informal dan manual. Pengujian ini tidak memiliki metode dan kriteria formal sehingga hasil pengujiannya bisa menjadi tidak konsisten dan rancu. Dukungan alat bantu untuk pengujian inipun jarang ditemukan. 43

Jurnal Teknologi Industri, Vol. VI No. 1, Januari 2002: 43 - 54

Salah satu spesifikasi yang menjelaskan kebutuhan perangkat lunak adalah statechart. Statechart adalah diagram yang menggambarkan kelakuan sistem secara keseluruhan dalam bentuk transisi, status dan event yang memicu terjadinya transisi. Oleh karena jarangnya dukungan alat bantu, metode dan kriteria formal pada pengujian dan pembangkitan data uji berdasar spesifikasi maka masalah ini menjadi pembahasan utama pada penelitian ini. Spesifikasi yang dipilih adalah spesifikasi statechart karena statechart menggambarkan dinamika sistem secara keseluruhan. 2. Pengembangan Perangkat Lunak Perangkat lunak dikembangkan dengan menggunakan paradigma tertentu. Paradigma tersebut disebut paradigma rekayasa perangkat lunak. Paradigma rekayasa perangkat lunak mempunyai banyak macam. Paradigma yang dipakai pada pengembangan perangkat lunak dipengaruhi oleh jenis perangkat lunak yang akan dikembangkan.Paradigma rekayasa perangkat lunak yang paling banyak dipakai adalah paradigma waferfall, atau classic life cyle . Tahapan pengembangan ini kemudian dikembangkan oleh U.S. Department of Defense sehingga menjadi tahap : 1. Analisis Kebutuhan (Software Requirement). Tahap ini adalah tahap analisis semua permasalahan yang akan diselesaikan oleh perangkat lunak. Domain informasi, fungsi yang dibutuhkan, kelakuan, kinerja dan antar muka perangkat lunak ditentukan pada tahap ini. 2. Perancangan awal (Preliminary Design). Perancangan awal perangkat lunak berfokus pada transformasi kebutuhan perangkat lunak ke entitas-entitas yang akan digunakan pada tahap pemrograman. Perancangan dilakukan dengan fokus pada empat atribut perangkat lunak : struktur data, arsitektur perangkat lunak, representasi antar muka dan algoritma. 3. Perancangan rinci (Detailed Design). Tahap ini berfokus pada penjabaran hasil perancangan awal ke bentuk yang lebih rinci. 4. Pemrograman (Coding). Tahap ini adalah tahap penterjemahan hasil perancangan rinci kedalam kode mesin. 5. Pengujian Unit (Unit Testing). Tahap ini adalah tahap awal pengujian yang dilakukan menemukan kesalahan dengan memberikan masukan tertentu kemudian memeriksa apakah hasil sudah sesuai dengan yang diharapkan. Pengujian unit dilakukan dengan memeriksa setiap unit (modul) program berdasarkan rancangan rinci. 6. Pengujian Integrasi (Integration Testing). Pengujian integrasi difokuskan untuk menguji integrasi dari modul-modul berdasarkan rancangan awal. 7. Pengujian Sistem (System Testing). Pengujian sistem difokuskan pada pengujian sistem perangkat lunak secara keseluruhan. Pengujian ini didasarkan pada Software Requirement Specification (SRS) yang telah dibuat pada tahap analisis perangkat lunak. 8. Penyerahan, Produksi dan Penggunaan (Delivery, Production and Deployment). Pengoperasian perangkat lunak setelah selesai dilakukan pengujian sistem. 9. Perawatan dan Pengembangan (Maintenance and Enhancement). Tahap perawatan dan pengembangan dilakukan karena dibutuhkan penyempurnaan atau pembetulan kesalahan yang terjadi ketika perangkat lunak sudah dipakai. 10. Perencanaan Pengujian Sistem Perangkat Lunak (Software System Test Planning). Tahap ini adalah tahap penentuan perencanaan pengujian sistem dan pendokumentasiannya. Tahap ini menggunakan SRS sebagai dasar penentuan test plan 44


11. Perencanaan Pengujian Integrasi (Integration Test Planning). Tahap ini adalah tahap penentuan perencanaan pengujian integrasi dan pendokumentasiannya. Perencanaan pengujian menggunakan rancangan awal sebagai dasar penentuan test plan. Penentuan test plan meliputi urutan integrasi modul, data uji pengujian integrasi dan prosedur pengujian integrasi. 12. Perencanaan Pengujian Unit (Unit Test Planning). Tahap ini adalah tahap penentuan perencanaan pengujian unit dan pendokumentasiannya. Perencanaan pengujian menggunakan rancangan rinci sebagai dasar. Test plan dibuat untuk setiap unit untuk menguji modul secara independen dan teliti. Secara diagram tahapan diatas dapat digambarkan sebagai berikut : 1 Software requirement

10 System test planning

2 Preliminary design

11 Integration test plan

3 Detailed design

12 Unit test planning

7 System testing 6 Integration testing 5 Unit testing

8 Delivery production deployment

9 Maintenance enhancement

4 Coding

Gambar 1. Siklus hidup pengembangan perangkat lunak Pembahasan utama penelitian ini adalah terletak pada tahapan analisis kebutuhan perangkat lunak (software requirement), system test planning dan pengujian sistem yang tampak pada gambar 1, sebagai kotak dengan bayang-bayang dengan nomor 1,7, dan 10. Tahapan analisis kebutuhan dan pengujian akan dijelaskan pada paparan selanjutnya. 2.1. Analisis Kebutuhan Perangkat Lunak Tahap awal pada pengembangan perangkat lunak adalah analisis kebutuhan perangkat lunak. Tahap ini merupakan tahap penting pada pengembangan perangkat lunak karena hasil analisis pada tahap ini akan digunakan pada tahap selanjutnya. Proses analisis kebutuhan perangkat lunak dapat dijabarkan dalam lima bagian penting, yaitu : pengenalan masalah ( problem recognition), evaluasi dan sintesa, pemodelan (modeling), pembuatan spesifikasi dan review. Analisis kebutuhan menghasilkan spesifikasi fungsional dan behavioral dari perangkat lunak, antarmuka perangkat lunak dengan sistem la in, batasan-batasan yang ada dan kekangan-kekangan yang harus dipenuhi oleh perangkat lunak itu sendiri. Analisis kebutuhan perangkat lunak merupakan tahap awal penting yang harus dilakukan dengan baik. Kesalahan yang terjadi pada tahap analisis ini akan menyebabkan kesalahan yang lebih besar pada tahap selanjutnya. Penyebaran kesalahan ini dengan sendirinya akan membutuhkan biaya yang lebih besar dalam perbaikannya.

45


2.1.1. Spesifikasi Spesifikasi secara lengkap biasa disebut SKPL ( Spesifikasi Kebutuhan Perangkat Lunak) atau SRS (Software Requirement Specification). Spesifikasi merupakan dokumen hasil akhir tahap analisis kebutuhan perangkat lunak. Spesifikasi menjelaskan secara lengkap apa yang akan dikerjakan oleh perangkat lunak tanpa menjelaskan bagaimana perangkat lunak mengerjakannya. Spesifikasi berisi deskripsi dan informasi lengkap tentang model fungsional dan model behavioral perangkat lunak yang akan dikembangkan. Spesifikasi juga berisi batasan, kekangan dan lingkungan operasi perangkat lunak. Termasuk juga didalamnya adalah penjelasan efisiensi, keandalan, keamanan, maintainability, portability, visibility dan standard compliance dari perangkat lunak. Spesifikasi dalam organisasi pengembangan perangkat lunak berfungsi sebagai sarana untuk : 1. komunikasi antara pelanggan(customer), pemakai(user), analis dan perancang. 2. mendukung aktivitas pengujian. 3. mengendalikan perkembangan pengembangan perangkat lunak. Bentuk spesifikasi diantaranya adalah FSM dan Statechart. Finite State Machine (FSM) adalah bahasa spesifikasi yang menggunakan mesin hipotesa untuk menggambarkan sistem dalam bentuk state (status), input (masukan) dan output (keluaran). Input adalah masukan ke sistem yang menyebabkan sistem menghasilkan respon berupa output dan perubahan status. Statechart adalah pengembangan Finite State Machine(FSM) yang ditemukan oleh Harel untuk mempermudah pemodelan sistem real-time yang kompleks. Pengembangan FSM pada statechart adalah adanya kondisi sistem saat transisi berlangsung dan adanya superstate, yaitu kumpulan status yang mempunyai transisi bersama. P Hasil Pengujian Program

Komputer

T Data Uji

Gambar 2. Pengujian Perangkat Lunak

Spesifikasi perangkat lunak yang banyak dipakai kebanyakan ditulis dengan menggunakan bahasa natural. Hal ini menyebabkan spesifikasi cenderung untuk menjadi rancu (ambigu), tidak lengkap, tidak konsisten dan sulit untuk dipelihara. Karena masalah tersebut maka muncul metode lain dalam pembuatan spesifikasi yang disebut dengan metode formal yang menghasilkan spesifikasi formal dan standar spesifikasi dalam bentuk UML. 2.2. Pengujian Perangkat Lunak Pengujian perangkat lunak adalah proses untuk mencari kesalahan pada setiap item perangkat lunak, mencatat hasilnya, mengevaluasi setiap aspek pada setiap komponen (sistem) dan mengevaluasi fasilitas-fasilitas dari perangkat lunak yang akan dikembangkan . 46


Pengujian yang baik tidak hanya ditujukan untuk menemukan kesalahan pada perangkat lunak tetapi juga untuk dapat ditemukannya data uji yang dapat menemukan kesalahan secara lebih teliti dan cepat. Gambaran abstrak pengujian perangkat lunak dapat diillustrasikan pada gambar 2. Pengujian perangkat lunak menggunakan teknik atau metoda tertentu yang disebut dengan metode pengujian. Metode tersebut adalah Black Box Testing dan White Box Testing. Selain black box testing dan white box testing terdapat pendekatan lain dalam metode pengujian, metode tersebut adalah pengujian berdasar kode sumber dan pengujian berdasar spesifikasi. Pengujian berdasar kode sumber Pengujian berdasar kode sumber (source code-based testing) adalah pengujian yang data ujinya dibangkitkan berdasar kode sumber perangkat lunak. Pengujian ini adalah pengujian yang paling umum digunakan. Pada pembangkitan data uji berdasar kode sumber (source code-based test case generation), kriteria pengujian diperlakukan pada perangkat lunak untuk menghasilkan requirement pengujian. Sebagai contoh, jika kriteria pengujian pencabangan digunakan, maka pembangkitan data uji harus melibatkan setiap pencabangan pada program. Pengujian berdasar kode sumber ini adalah sama dengan white-box testing, hanya berbeda dalam pendekatannya saja. Gambaran abstrak proses pengujian berdasar kode sumber tampak pada gambar 3. Actual Output Spesifikasi

Program Compare

Coverage Criterion Spesifikasi

Expected Output

Data Uji

Gambar 3. Pengujian berdasar kode sumber Spesifikasi (dapat berupa spesifikasi informal atau formal) digunakan sebagai dasar untuk penulisan Program. Program kemudian digunakan untuk membangkitkan Data Uji dengan kriteria tertentu. Contoh kriteria pengujian adalah kriteria cakupan (coverage criterion) yaitu setiap pencabangan harus diuji paling tidak sekali. Eksekusi Data Uji pada Program menghasilkan keluaran aktual yang akan dibandingkan dengan keluaran yang diharapkan (expected output). Keluaran yang diharapkan dihasilkan dari spesifikasi. Code-based test case generation menggunakan spesifikasi untuk membangkitkan kode sumber dan melakukan pengecekan keluaran pada program. Pengujian berdasar spesifikasi Pengujian berdasar spesifikasi (specification-based testing) adalah pengujian yang data ujinya dibangkitkan berdasar spesifikasi perangkat lunak. Spesifikasi perangkat lunak selain berfungsi sebagai acuan teknis pengembangan perangkat lunak, khususnya spesifikasi dalam bentuk formal, juga merupakan alat yang dapat digunakan untuk pengujian perangkat lunak. Spesifikasi formal menjelaskan fungsi dari perangkat lunak yang terbentuk dalam suatu format tertentu sehingga dari spesifikasi ini dapat dilakukan proses otomasi untuk pembangkitan data pengujian. 47


Proses pembangkitan data uji berdasar spesifikasi perangkat lunak digunakan untuk menemukan kesalahan dari spesifikasi perangkat lunak sendiri. Jika langkah ini dilakukan maka masalah-masalah yang muncul dapat dieliminasi pada tahap awal pengembangan perangkat lunak yang pada akhirnya akan menghemat waktu dan sumber daya yang lain. Lebih dari itu pembangkitan data uji pada awal pengembangan perangkat lunak dapat meningkatkan efektivitas perencanaan dan utilisasi sumber daya. Gambaran abstrak untuk specification-based testing tampak pada gambar 4. Actual Output Spesifikasi

Program Compare Expected Output

Spesifikasi

Data Uji

Gambar 4. Pengujian berdasar spesifikasi Pada specification-based testing Spesifikasi selain digunakan untuk membuat Program juga digunakan untuk membangkitkan Data Uji. Dalam hal ini, spesifikasi adalah spesifikasi yang bisa dibangkitkan data ujinya dalam bentuk yang diformalkan. Specification-based testing menggunakan spesifikasi formal sebagai masukan untuk pembangkitan data ujinya. Pembangkitan data uji dilakukan secara otomatis. Karena spesifikasi formal mempunyai penjelasan yang lengkap, konsisten dan tidak rancu maka hasil pembangkitan data ujinya diharapkan dapat mencakup semua kemungkinan kesalahan dan memenuhi semua kelengkapan dari spesifikasi. Data ujinya kemudian dieksekusi pada perangkat lunak dan diharapkan pada akhirnya perangkat lunak yang dihasilkan bersifat andal. Salah satu kelebihan pembangkitan data uji berdasar spesifikasi adalah bahwa data uji dapat dibangkitkan pada tahap awal pengembangan perangkat lunak dan siap eksekusi sebelum program selesai dibangun. Sebagai tambahan, ketika data uji dibangkitkan akan ditemukan ketidak-konsistenan dan kerancuan pada spesifikasi, sehingga spesifikasi dapat diperbaiki sebelum program ditulis. Perbandingan pengujian berdasar spesifikasi dan pengujian berdasar kode sumber Kedua metode pengujian berdasar spesifikasi dan pengujian berdasar kode sumber ini mempunyai karakteristik sendiri-sendiri, keduanya dapat dibandingkan seperti pada tabel 1. Tabel 1 Pembandingan specification-based testing dan source code-based testing sumber pembang-kitan data uji sudut pandang pengujian kriteria formal dukungan tools tahap digunakan

48

Pengujian berdasar spesifikasi spesifikasi

Pengujian berdasar kode sumber kode sumber

external view, menguji apa yang diinginkan belum ada jarang pengujian sistem

internal view, menguji apa yang dibangun sudah ada cukup banyak pengujian unit


Dua pendekatan source code-based testing dan specification based testing digunakan pada pengujian perangkat lunak. Keduanya bersifat saling melengkapi. Pengujian berdasar kode sumber dilakukan pada pengujian unit, sedangkan pengujian berdasar spesifikasi dilakukan pada pengujian sistem. Tidak tertutup kemungkinan pengujian berdasar spesifikasi dilakukan pada spesifikasi per unit. Perpaduan kedua metode juga bisa dilakukan dengan cara membangkitkan data uji berdasarkan spesifikasi dan kemudian menggunakan analisis code-based coverage untuk mengukur kualitas data uji. Penelitian ini membahas pembangkitan data uji berdasar spesifikasi khususnya spesifikasi statechart. 3. Pembangkitan data uji dari spesifikasi statechart UML Dewasa ini kebutuhan perangkat lunak dengan tingkat kompleksitas tinggi dan kritis cukup meningkat. Perangkat lunak tersebut biasanya mempunyai deskripsi yang jelas, lengkap dan bahkan dalam bentuk spesifikasi formal. Pada kenyataannya deskripsi yang jelas tersebut kebanyakan hanya ada pada tingkat (level) unit, sedang pada tingkat sistem deskripsi hanya dilakukan secara informal. UML merupakan notasi pemodelan yang cukup baik untuk menjelaskan perangkat lunak pada semua tingkat pengembangan perangkat lunak. Dan ini merupakan peluang yang dapat digunakan untuk penentuan data uji. Walaupun UML tidak terlalu formal tetapi deskripsi pada UML cukup teliti dan lengkap untuk menjelaskan perangkat lunak. Statechart UML dipilih sebagai awal pembangkitan data uji berdasar spesifikasi karena statechart menjelaskan kelakuan (behavior) sistem. Pengujian kelakuan perangkat lunak sebenarnya dapat dilakukan dengan menguji setiap metode (method) dari suatu objek, karena kelakuan suatu objek diimplementasikan dari metodenya. Tetapi pengujian setiap metode objek hanya menguji sebagian kelakuan objek bukan keseluruhan dari sistem. Statechart UML adalah diagram yang menggambarkan kelakuan sistem secara keseluruhan. Karena menggambarkan kelakuan sistem secara keseluruhan maka pembangkitan data uji berdasar statechart (state machine) dan pengujian yang dilakukan dengan data uji tersebut dianggap menguji keseluruhan sistem. 3.1. Mesin Status (State Machine) Statechart pada UML dibuat berdasar State Machine yang digunakan oleh David Harel. Mesin Status (State machine) adalah mesin yang menggambarkan atau memodelkan kelakuan dari objek secara individual. Mesin Status menggambarkan urutan status dari suatu objek yang hidup pada suatu waktu (lifetime) karena respon dari event. Mesin Status dan komponen-komponen pendukungnya secara konseptual dapat dijelaskan sebagai berikut : 1. Mesin Status : mesin yang menggambarkan urutan status (state) dari suatu objek yang hidup pada waktu hidup (lifetime) nya karena respon dari event. 2. Status (state) : kondisi atau situasi pada saat suatu objek hidup. Status tersebut bisa keadaan yang : memenuhi suatu kondisi, melakukan suatu aktivitas, atau menunggu suatu event. Pada statechart UML status digambarkan dengan kotak bersudut tumpul. 3. Event : spesifikasi suatu kejadian (occurrence) yang mempunyai alokasi ruang dan waktu. Didalam konteks Mesin Status, event adalah kejadian (occurrence) dari suatu pemicu (stimulus) yang memicu suatu transisi status. Pada statechart UML event digambarkan (dituliskan) sebagai teks yang menyertai transisi. 49


4. Transisi : adalah hubungan antara dua status yang menunjukkan bahwa objek pada pada saat status pertama akan melakukan suatu aksi tertentu dan masuk ke status kedua jika suatu event terjadi dan suatu kondisi tertentu dipenuhi. Pada statechart UML transisi digambarkan dengan anak panah berarah, dengan asal anak panah adalah status sumber (asal) dan anak panah tujuan adalah status target (tujuan). 5. Aktivitas : adalah eksekusi suatu fungsi yang non atomic pada mesin status. Pada statechart UML aktivitas digambarkan (dituliskan) sebagai teks yang menyertai event dan transisi. 6. Aksi : adalah komputasi atomik yang dihasilkan dari perubahan status atau mengembalikan suatu nilai. Pada statechart UML aktivitas digambarkan (dituliskan) sebagai teks yang menyertai event dan transisi. Status, event dan transisi karena mempunyai penjelasan yang cukup banyak dan masingmasing mempunyai karakteristik khusus maka akan dijelaskan lebih lengkap pada sub-bab berikutnya. Contoh mesin status dengan komponen lengkap tampak pada gambar 5. dibawah ini. Mesin status ini menggambarkan behavior sistem penjejak (tracking system) yang mempunyai beberapa status, event dan transisi dan aksi. time event

send action

after (2 seconds) / send c.isAlive

initial state

self transition

state

triggerless transition

noise Idle

Searching

final state

Engaging

event trigger with parameter

targetAt( p )[is Threat] / t.addTarget

contact Tracking

action

condition guard

event trigger

Gambar 5. Contoh Mesin Status Tracking System Status (State) Status (State) adalah kondisi atau situasi dari suatu objek. Objek pada kehidupannya dapat memenuhi beberapa kondisi, melakukan suatu aktivitas tertentu atau menunggu suatu event. Suatu objek dapat berada pada status tertentu pada suatu waktu. Status mempunyai beberapa bagian yaitu Nama, Entry/Exit action, Internal transition, Substates dan Deferred Event. Setiap objek mempunyai lifetime. Objek lahir pada saat penciptaan (creation) dan dihilangkan pada saat pemusnahan (destruction). Pada tenggang waktu diantaranya (lifetime) objek berinteraksi dengan objek lain. Interaksi dilakukan dengan mengirimkan message ke objek yang lain atau menerima message dari objek lain. Ada dua status khusus pada mesin status yaitu status awal (initial state) dan status akhir (final state) yang juga tampak pada gambar 5. Status awal adalah status yang menunjukkan kondisi awal atau tempat awal (default starting place) suatu mesin status. Sedangkan status akhir adalah status penutup dari mesin status yang menandakan eksekusi mesin status telah lengkap. Status awal digambarkan dengan lingkaran dengan warna dasar hitam, sedangkan 50


status akhir digambarkan dengan lingkaran dalam dengan warna hitam dan lingkaran luar tanpa warna dasar. Event Event adalah spesifikasi suatu kejadian (occurrence) yang mempunyai alokasi ruang dan waktu. Didalam konteks mesin status, event adalah kejadian dari stimulus yang memicu terjadinya transisi status. Event bisa berupa external event dan internal. External event adalah event yang ada diantara sistem dan aktornya. Contoh dari external event adalah penekanan tombol atau interupsi dari suatu external device. Sedangkan internal event adalah event yang muncul diantara objek didalam suatu sistem. Contoh dari internal event adalah overflow exception yang ada pada sistem penghitungan. Event yang dimodelkan UML terdiri dari 4 jenis, yaitu : Signal, Call, Time dan Change event. Signal, Call dan Time Event tidak dibahas di tulisan ini. Change Event Change Event adalah event yang merepresentasikan perubahan status karena pemenuhan suatu kondisi. Pada UML penggunaan change Event adalah dengan keyword when diikuti oleh ekspresi Boolean. Ekspresi tersebut bisa berupa waktu absolut (seperti : when time = 11:59) atau ekspresi kontinyu (seperti : when altitude < 1000). When(11:49PM)/SelfTest

change event

Idle

Transisi

Gambar 6. Change Event

Transisi adalah relationship atau hubungan antara dua status yang menunjukkan bahwa suatu objek pada status awal akan melakukan aksi tertentu dan memasuki status kedua. Transisi akan terjadi jika suatu event terjadi dan jika kondisi yang ditentukan dipenuhi. Jika suatu perubahan status terjadi maka dikatakan bahwa transisi terjadi. Jika suatu transisi terjadi maka status sebelum transisi disebut status sumber dan status setelah transisi terjadi disebut status tujuan. Sintaks UML untuk transisi adalah : event (arguments) [condition] ^ target.sendEvent (arguments)/ operation(arguments) Transisi mempunyai lima bagian : 1. Status sumber (Source State) : Status sumber adalah status awal dari suatu transisi. Jika suatu objek ada pada status sumber, outgoing transition akan terjadi jika objek menerima event trigger dan guard condition nya dipenuhi. 2. Event trigger : Event trigger adalah event pemicu, yaitu event yang jika diterima oleh objek pada status sumber akan memicu transisi terjadi, jika guard condition nya dipenuhi 3. Guard Condition : Ekspresi boolean yang akan dievaluasi jika transisi event diterima. Jika ekpresi bernilai true maka transisi akan terjadi, jika ekspresi bernilai false transisi tidak akan terjadi.

51


Aksi : komputasi atomik yang executable yang secara langsung bekerja pada objek yang mempunyai mesin status dan yang secara tidak langsung bekerja pada objek lain yang visible pada objek tersebut. 5. Status Tujuan (Target State ): Status tujuan adalah status akhir suatu transisi. Status ini adalah staus aktif jika suatu transisi telah lengkap terjadi. UML membagi transisi ke dalam 5 kategori yaitu : high-level transition, compound transition, internal transition, completion transition dan enabled transition. High level transition, adalah transisi yang terjadi pada composite state. Composite state adalah status yang terdiri dari beberapa substatus yang bisa konkuren. Jika composite state dipicu maka status akan keluar dari composite state dan masuk ke status tertentu. Compound transition adalah transisi yang terjadi dari suatu kumpulan status sumber ke kumpulan status tujuan. Internal transition (self transition) adalah transisi yang dieksekusi tanpa keluar dari status yang didefinisikan atau transisi yang masuk kembali ke status awal. Completion transition (triggerless transition) adalah transisi yang terjadi tanpa pemicu eksplisit. Transisi ini terjadi oleh completion event yang terjadi secara implisit. Enabled transition adalah transisi yang terjadi karena dipicu oleh suatu event. Transisi ini berasal dari status yang aktif. Transisi ini terjadi jika paling tidak ada satu jalur dari status sumber ke status tujuan. Dari inspirasi spesifikasi statechart dengan UML, suatu prototype perangkat lunak SCDTG dibuat. SCDTG mempunyai fungsi diantaranya yaitu sebagai pembangkit data uji dari spesifikasi statechart yang dituliskan dengan notasi XML (Extensible Markup Languange). Data Uji dibangkitkan dengan kriteria tertentu yang akan dibahas pada tulisan yang lain. 4.

4. Contoh kasus pembangkitan data uji Contoh kasus berikut adalah contoh pembangkitan data uji berdasar spesifikasi statechart pada kasus cruise control pada sistem automobile. Statechart cruise control pada sistem automobile adalah sebagai berikut : T4

T2 OFF

T1

INACTIVE T10

T3

CRUISE

T5 V T12 T11 V T12

T9 OVERRIDE

Gambar 7. Statechart Cruise Control Example Sistem cruise control mempunyai 4 status yaitu : • OFF (initial state) • INACTIVE • CRUISE • OVERRIDE Sistem ini mempunyai kondisi lingkungan yang mempengaruhi sistem yaitu : 52

T7 V T8


• Ignited : menunjukkan bahwa sistem automobil sedang dinyalakan. • Running : menunjukkan bahwa sistem automobil sedang berjalan. • Toofast : menunjukkan bahwa sistem automobil terlalu kencang untuk dikendalikan. • Brake : pedal rem pada sistem automobil sedang ditekan. • Activate : menunjukkan cruise control level diset sedang aktif. • Deactivate : menunjukkan cruise control level diset sedang takaktif. • Resume : menunjukkan cruise control level diset resume. Tabel transisi sistem dengan sintaks UMLdapat dilihat seperti pada tabel 2. Sintaks UML untuk transisi adalah : event (arguments) [condition] ^ target.sendEvent (arguments)/ operation(arguments) Dari tabel diatas tampak bahwa Cruise Control mempunyai 12 transisi. Event dituliskan dengan kata when, sedangkan condition (guard condition) dituliskan dalam kurung kotak. Suatu transisi dengan event when(P)[C] akan terjadi jika event P terjadi dan kondisi C dipenuhi. Maka P kemudian disebut dengan event pemicu (triggering event). Event yang ditangani pembangkitan data ujinya adalah change event dengan enabled transition. Dari spesifikasi ini kemudian beberapa kriteria dan metode dilakukan untuk melakukan pembangkitan data uji secara otomatis. Data uji hasil pembangkitan, digunakan untuk menguji perangkat lunak apakah telah sesuai dengan yang diinginkan pada spesifikasi. Tabel 2. Tabel transisi sistem cruise control (dengan notasi UML) Id T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12

Status Sumber OFF INACTIVE INACTIVE CRUISE CRUISE CRUISE CRUISE CRUISE OVERRIDE OVERRIDE OVERRIDE OVERRIDE

Event when(Ignited) when(not ignited) when(activate)[ignited and running and not brake] when(not ignited) when(running)[ignited] when(not toofast)[ignited] when(not brake)[ignited and running and not toofast] when(deactivate)[ignited] when (not ignited) when (not running)[ignited] when (activate)[ignited and running and not brake] when (resume) [ignited and running and not brake]

Status Tujuan INACTIVE OFF CRUISE OFF INACTIVE INACTIVE OVERRIDE OVERRIDE OFF INACTIVE CRUISE CRUISE

5. Penutup Dari penjelasan diatas dapat disimpulkan bahwa 1. Spesifikasi Kebutuhan Perangkat Lunak (SKPL) yang dihasilkan pada tahap analisis perangkat lunak dapat digunakan sebagai dasar pembangkitan data uji untuk pengujian. 2. Spesifikasi yang banyak digunakan pada industri perangkat lunak adalah spesifikasi UML. 3. Spesifikasi statechart pada UML dapat digunakan sebagai dasar pembangkitan data uji untuk pengujian sistem perangkat lunak karena statechart menjelaskan kelakuan sistem secara keseluruhan. 4. Pembangkitan data uji berdasarkan spesifikasi tidak mempunyai kriteria formal. 5. Pengujian sistem biasanya dilakukan berdasarkan spesifikasi yang dianalisa secara informal dan manual. 53


6. Dukungan alat bantu otomatisasi pembangkitan data uji pada pengujian sistem jarang ditemukan. Tulisan ini akan dilanjutkan dengan tulisan lain yang menjelaskan proses otomasi pembangkitan data uji berdasar spesifikasi dan pembuatan prototype perangkat lunak SCDTG (Statechart Data Test Generator). Spesifikasi yang digunakan adalah spesifikasi yang ditulis dalam notasi XML (eXtensible Markup Language). 6. Daftar Pustaka Booch, Grady. Rumbaugh, James., dan Jacobson, Ivar. The Unified Modeling Language User Guide. Addison Wesley, 1999. Balzer, R., dan N. Goodman. Principles of Good Specification and their Implications for Specification Languages. In Software Specification Techniques (N.Gehani dan A.D. Mcgettrick, eds.), Addison-Wesley, pp. 25-39, 1986. Chi, U.H. Formal Specification of User Interfaces : A Comparison and Evaluation of Four Axiomatic Approaches. IEEE Transactions on Software Engineering 11, pp. 671-85, Agustus 1985. Chilenski, J.J., dan Miller, S.P. Applicability of modified condition/decision coverage to software testing. Software Engineering Journal, pp 193-200, September 1994. Davis, Alan M. Software Requirements – Objects, Functions and State. Prentice-Hall Inc, 1993. Eriksson, Hans-Erik., dan Penker, Magnus. UML Toolkit. John Wiley & Sons, Inc., 1998. Jones, C. Software Development : A Rigorous Approach. Englewood Cliffs, N.J. : PrenticeHall International, 1980. Myers,G., The Art of Software Testing. Wiley, 1979. Neuhold, E., dan T.Olnhoff. The Vienna Development Method and Its Use for Specification of Relational Data Base System. In IFIPS’80, Amsterdam : North-Holland, pp. 5 – 16, 1980. Offut, A Jefferson. dan Abdulrazik, Aynur. Generating test cases from UML specifications. In Proceeding of the second IEEE International Conference on Unified Modeling Language (UML99), pages 416-429, Fort Collins, CO, IEEE Computer Society Press, October 1999. Offut, A Jefferson. dan Liu, Shaoying. Generating test data from SOFL specifications. The Journal of Systems and Software, 1999. Offut, A.Jefferson. Xiong, Yiwei. dan Liu, Shaoying. Criteria for Generating Specificationbased tests. http://www.isse.gmu.edu Pressman, Roger S. Software Engineering – A Practitioner’s Approach. McGraw-Hill, Inc., 1997. Perry, William. Effective Methods for Software Testing. John Wiley & Sons, Inc., 1995. Royce, W. Managing the development of Large Software System. In IEEE WESCON, August 1970. pp. 1-9. Reprinted in Ninth IEEE International Conference on Software Engineering, Washington D.C. : Computer Society Press of Institute of Electrical and Electronics Engineers, pp. 328-38, 1987. RTCA Committee SC-167. Software consideration in airborne systems and equipment certification. Seventh draft to DO-178A/ED 12A, July 1992. Spivey, J.M., Understanding Z: A Specification Language and Its Formal Semantics. Cambridge University Press, 1988. U.S. Department of Defense. Military Standard : Defense System Software Development. DOD-STD-2167. Washington, D.C. , June 1985. 54

Pengantar: Pembangkitan Data Uji dari Spesifikasi statechart

Recommend Documents