BAB 2 TINJAUAN PUSTAKA -...

BAB 2

TINJAUAN PUSTAKA

Pada bab ini akan dibahas teori mengenai FSM yang meliputi defenisi FSM, kelebihan

dan kekurangan FSM, teknik pemodelan FSM, implementasi FSM pada perangkat

lunak, dan interaksi manusia dengan komputer yang meliputi defenisi serta prinsip

utama mendesain antarmuka (interface).

2.1 Finite State Machine (FSM)

Bahasa formal dapat dipandang sebagai entitas abstrak, yaitu sekumpulan string-string

simbol alphabet tertentu. Namun bahasa juga dapat dipandang sebagai entitas-entitas

abtrak yang dapat dikenali atau dibangkitkan melalui suatu mesin komputasi. Mesin

yang dapat mengenali bahasa kelas ini adalah finite state machine.

2.1.1 Defenisi FSM

Ada beberapa definisi mengenai Finite State Machine (FSM) atau sering juga disebut

dengan Finite State Automata (FSA).

1. FSM didefenisikan sebagai perangkat komputasi yang memiliki input berupa

string dan output yang merupakan satu dari dua nilai yang dapat di-accept dan

reject (Rich : 2009).

2. Finite Automata adalah model matematika sistem dengan masukan dan

keluaran diskrit. Sistem dapat berada di salah satu dari sejumlah berhingga

konfigurasi internal disebut state (Hariyanto : 2004).

Universitas Sumatera Utara

3. FSM adalah sebuah metodologi perancangan sistem kontrol yang

menggambarkan tingkah laku atau prinsip kerja sistem dengan menggunakan

tiga hal berikut: State (Keadaan), Event (kejadian) dan action (aksi). Pada satu

saat dalam periode waktu yang cukup signifikan, sistem akan berada pada

salah satu state yang aktif. Sistem dapat beralih atau bertransisi menuju state

lain jika mendapatkan masukan atau event tertentu, baik yang berasal dari

perangkat luar atau komponen dalam sistemnya itu sendiri. Transisi keadaan

ini umumnya juga disertai oleh aksi yang dilakukan oleh sistem ketika

menanggapi masukan yang terjadi. Aksi yang dilakukan tersebut dapat berupa

aksi yang sederhana atau melibatkan rangkaian proses yang relatif kompleks

(Setiawan : 2006).

Gambar 2.1 Contoh diagram state sederhana (Sumber: Setiawan, 2006)

Diagram tersebut memperlihatkan FSM dengan dua buah state dan dua buah

input serta empat buah aksi output yang berbeda : seperti terlihat pada gambar, ketika

sistem mulai dihidupkan, sistem akan bertransisi menuju state0, pada keadaan ini

sistem akan menghasilkan Action1 jika terjadi masukan Event0, sedangkan jika terjadi

Event1 maka Action2 akan dieksekusi kemudian sistem selanjutnya bertransisi ke

keadaan State1 dan seterusnya.

Secara formal FSM dinyatakan oleh 5 tupel atau M=(Q, ∑, δ, S, F),

(Utdirartama, 2001) dimana:

Q = himpunan state/kedudukan

∑ = himpunan symbol input/masukan/abjad

δ = fungsi transisi

S = state awal/ kedudukan awal (initial state), S Q

F = himpunan state akhir, F Q


FSM terdiri dari dua jenis, yaitu FSM ber-output dan FSM tidak ber-output.

FSM tidak ber-output digunakan untuk pengenalan bahasa dalam komputer, dengan

input yang dimasukkan akan diperoleh apakah input tersebut dikenal oleh bahasa

komputer atau tidak. Salah satu penggunaan FSM tidak ber-output adalah program

compiler, yaitu program untuk memeriksa apakah perintah yang digunakan pengguna

benar atau salah. Sementara untuk FSM ber-output digunakan untuk merancang mesin

atau sistem (Zen, 2008). Dan FSM yang akan digunakan dalam penelitian ini adalah

FSM ber-output, dan untuk selanjutnya akan dituliskan dengan FSM saja.

Ada dua metode utama untuk memperlakukan FSM untuk menghasilkan

output. Yaitu Moore Machine dan Mearly Machine yang dinamakan berdasarkan

penemunya.

2.1.1.1 Moore Machine

Gambar 2.2 Moore State Machine (Sumber: Brownlee, 2010)

Moore Machine adalah tipe dari FSM dimana output dihasilkan dari state.

Pada gambar diatas mencontohkan dimana state mendefenisikan apa yang harus

dilakukan (Brownlee, 2010). Keluaran pada Moore Machine diasosiasikan sebagai

state (Hariyanto, 2004). Dan pada penelitian ini, penulis menggunakan Moore

Machine.


2.1.1.2 Mearly Machine

Gambar 2.3 Mearly State Machine (Sumber: Brownlee, 2010)

Mearly Machine berbeda dengan Moore Machine dimana keluarannya

merupakan hasil dari transisi antar state (Brownlee, 2010). Keluaran pada Mearly

Machine diasosiasikan sebagai transisi (Hariyanto, 2004)

2.1.2 Kelebihan FSM

FSM memiliki beberapa kelebihan (Brownlee, 2010), diantaranya :

1. Sederhana, sehingga mudah diimplementasikan

2. Bisa diprediksi responnya

3. Komputasi ringan

4. Relatif fleksibel

5. Merupakan metode AI lama yang bisa digunakan pada berbagai sistem

6. Mudah ditransfer dari abstrak menjadi kode program

2.1.3 Kelemahan FSM

Selain memiliki banyak kelebihan, FSM juga mempunyai beberapa kelemahan

(Brownlee, 2010), diantaranya :

1. Karena sifatnya bisa diprediksi, maka implementasi pada game kurang disukai

2. Implementasi pada sistem yang lebih besar lebih sulit karena pengaturan dan

pemeliharaannya jadi kompleks


3. Sebaiknya hanya digunakan pada sistem dimana sifat sistem bisa

didekomposisi menjadi state.

4. Kondisi untuk transisi state adalah tetap

2.1.4 Teknik Pemodelan FSM

Finite State Machine bukanlah metode yang baru. FSM sudah lama ada dan konsep

dekomposisi biasanya sudah dipahami dan sering digunakan oleh orang-orang yang

memiliki pengalaman dalam membuat program komputer atau desain program

komputer. Ada beberapa teknik pemodelan abstrak yang bisa digunakan untuk

membantu defenisi atau pemahaman dan desain dari FSM, mayoritas teknik ini

berasal dari disiplin ilmu desain atau matematika (Lee: 1998).

1. Diagram Transisi State

Juga dikenal sebagai Diagram Gelembung (Bubble Diagram). Menunjukkan

relasi antara state dengan input yang menyebabkan transisi state.

2. Diagram Pengambilan Keputusan State-Aksi.

Diagram Alir sederhana dengan tambahan gelembung yang menunjukkan

penungguan terhadap input.

3. Diagram Grafik State

Salah satu bentuk dari notasi UML yang berfungsi untuk menunjukkan sifat

individu dari objek sebagai nomor state dan transisi dari state tersebut.

4. Analisa Hirarki Perintah

Meskipun tidak seperti state, ini merupakan teknik dekomposisi perintah yang

melihat dari sudut pandang bagaimana caranya perintah dibagi jadi sub

perintah dan urut sesuai urutan kejadiannya.


2.1.5 Implementasi FSM pada perangkat lunak

Implementasi Finite State Machine dalam perangkat lunak merupakan permasalahan

tersendiri yang sudah banyak diteliti oleh pakar-pakar insinyur perangkat lunak

(software engineer ). Desain Finite State Machine memang tampak mudah dan

sederhana karena hanya terdiri dari serangkaian lingkaran dan anak panah yang

masing-masing memiliki label. Desain FSM biasanya direpresentasikan dalam tabel

transisi state atau dengan state diagram. Namun jika tiba waktunya

mengimplementasikan FSM dalam suatu aplikasi perangkat lunak, maka ada suatu

permasalahan yang sering timbul yaitu kode program FSM menjadi rumit dan

kompleks ketika sistem yang dibangun adalah sistem yang besar atau kompleks. Bagi

pemula yang masih belajar implementasi FSM dengan sistem sederhana mungkin hal

ini tidak terlalu berpengaruh maupun terasa. Namun bagi seorang programer

profesional, maka implementasi FSM untuk sistem yang besar atau kompleks

memerlukan suatu desain struktur yang baik dan optimal (Wijaya, 2009).

Pada dasarnya implementasi FSM bisa dibagi menjadi tiga (3) cara, dimana

masingmasing cara memiliki kelebihan dan kekurangan masing-masing. Ketiga cara

tersebut adalah sebagai berikut (Wijaya, 2009):

1. Cara tradisional

2. Lookup table

3. Object Oriented

Sebagai contoh sistem yang digunakan untuk melihat perbedaan antara cara

satu dengan yang lain adalah sistem mesin minuman dalam kaleng menggunakan

koin. Desain FSM sistem tersebut tampak pada gambar.


Gambar 2.4 FSM mesin minuman dalam kaleng menggunakan koin

(Sumber:Yacoub, 1998)

2.1.5.1 Cara Tradisional

Kelebihan dari cara tradisional adalah mudah untuk diimplementasikan. Cara ini

adalah cara klasik yang paling mudah untuk menerapkan FSM pada perangkat lunak

sekaligus merupakan cara klasik yang biasanya masih banyak digunakan pada mikro

komputer dengan sumber daya pemroses yang terbatas (limited hardware resources ).

Kekurangan dari cara tradisional adalah bahwa implementasi yang mudah tersebut

hanya berlaku jika sistem yang digunakan adalah sistem yang kecil. Seiring dengan

membesarnya sistem dan membesarnya tingkat kompleksitas maka implementasi dan

pemeliharaannya juga akan semakin rumit (Wijaya, 2009).

Tabel 2.1: Implementasi cara tradisional (Sumber: Yacoub, 1998)

switch(state){

case Broken:

//kode state Broken disini;

break;

case Unlock:

// kode state Unlock disini;

break;

default:

// kode Lock disini

break;

}


Ciri khas dari implementasi FSM menggunakan cara tradisional adalah dengan

menggunakan perintah if then atau select case atau switch pada kode program. Salah

satu contoh implementasi cara tradisional pada kode program adalah seperti pada tabel

2.1.

Semakin banyak jumlah state yang digunakan pada sistem, maka semakin

banyak juga penulisan kode dan semakin panjang perintah switch. Karena semua state

berada dalam satu ruang lingkup perintah switch, maka jika terjadi salah ketik pada

salah satu state akan membuat state yang lain terlihat kacau juga. Semakin panjang

state yang digunakan, maka efisiensi pengetikan program juga akan menurun, karena

programer harus mencari state yang ingin dia tambahkan diantara state lain yang

banyak jumlahnya. Jika ada perogramer baru yang harus meneruskan pemrograman

sebelumnya, maka akan membutuhkan waktu yang cukup lama bagi programer baru

tersebut untuk memahami algoritma kode perangkat lunak karena berada dalam satu

file yang panjang (Wijaya,2010).

Selain itu programer harus teliti dalam memastikan bahwa tiap state memiliki

suatu kondisi tertentu untuk transisi ke state lain. Karena jika ada state yang tidak

memiliki transisi ke state lain, maka program akan looping terus pada state tersebut

(Wijaya, 2010).

2.1.5.2 Lookup table

Cara lain mengimplementasikan FSM dalam perangkat lunak adalah dengan

menggunakan lookup table. Tabel ini berisi semua transisi state yang mungkin terjadi

pada sistem. Tabel ini direpresentasikan sebagai matriks pada kode program dimana

tiap baris merepresentasikan event atau transisi state dan kolomnya merepresentasikan

state sedangkan elemennya merepresentasikan next state (Wijaya, 2010).

Kelebihan dari lookup table adalah kemudahannya untuk diimplementasikan

dan pemeliharaannya lebih fleksibel. Implementasinya menggunakan matriks

sehingga tidak begitu sulit menggunakan berbagai bahasa pemrograman untuk


mengimplementasikannya. Pemeliharaannya juga cukup fleksibel karena tabel atau

matriks tersebut mudah untuk dibaca maksudnya dan dipahami (Wijaya, 2010).

Kelemahan dari lookup table adalah ketika diimplementasikan untuk sistem

yang besar atau kompleks maka respon sistem akan jadi lebih lambat karena ukuran

dimensi matriks yang digunakan menjadi besar sehingga memerlukan alokasi memori

yang besar dan waktu proses lebih lama untuk mencari hubungan state pada matriks.

Hal ini membuat implementasi lookup table jarang digunakan untuk sistem yang besar

dan kompleks (Wijaya, 2010).

Salah satu contoh lookup tabel yang digunakan adalah seperti tampak pada

Tabel 2.2.

Tabel 2.2: Contoh Lookup table FSM (Sumber: Yacoub, 1998)

Dengan menggunakan lookup table diatas, maka transisi state yang satu

menuju state yang lainnya bisa lebih mudah dipahami. Implementasi matriks tersedia

pada berbagai macam bahasa pemrograman. Implementasi lookup table pada sistem

yang kecil banyak disukai karena kemudahan implementasi dan fleksibilitasnya (Van

Houten: 2004).

Contoh lain penerapan FSM dengan lookup table adalah seperti pada gambar

dibawah ini (Hariyanto, 2004).

Unlock Lock Broken

Coin Unlock

Pass Lock

Failed Broken Broken

Fixed Lock


S A B

Gambar 2.5 Contoh FSD (Sumber: Hariyanto, 2004)

FSD pada gambar 2.4 diatas memiliki formal sebagai berikut :

M=(Q, ∑, δ, S, F)

Dimana :

Q = {S, A, B}

∑ = {digit, . }

S = S

F = B

Tabel 2.3 Contoh Tabel Transisi (Sumber: Hariyanto, 2004)

Tabel transisi state (Lookup table) merupakan metode untuk

merepresentasikan struktur finite automata di program komputer. Ketika

direpresentasikan sebagai array di memori komputer, pengaksesan dapat dilakukan

secara cepat serta struktur array ini sangat mudah untuk dimanipulasi di komputer

(Hariyanto, 2004).

δ Masukan

Digit .

S S A

A B

B B

digit digit

digit . start


2.1.5.3 Object Oriented

Kelebihan penggunaan OOP pada FSM adalah fleksibilitasnya yang tinggi dan

pemeliharaannya yang mudah baik pada sistem yang sederhana, menengah, maupun

sistem yang kompleks (Yacoub, 1998: 1998). Selain itu juga mendapatkan manfaat

dari salah satu kelebihan OOP yaitu penggunaan kembali kode yang telah diketik

(code reusability) sehinga pengetikan kode menjadi lebih sedikit (Wijaya, 2010).

Salah satu alternatif implementasi Finite State Machine adalah menggunakan

pemrograman berorientasi objek (Object Oriented Programming) atau yang sering

disingkat sebagai OOP (Wijaya, 2010).

Kelemahan OOPFSM adalah hanya bisa diimplementasikan menggunakan

bahasa pemrograman yang mendukung OOP seperti C++ dan Java. Selain itu

diperlukan pemahaman yang teknis mengenai teknik pemrograman berorientasi objek

(Wijaya, 2010).

Desain OOP biasanya direpresentasikan menggunakan UML (Universal

Markup language) untuk menggambarkan variabel dan metode yang dimiliki oleh

suatu class dan untuk menggambarkan relasi antara class yang satu dengan class yang

lain (Wijaya, 2010).

Salah satu contoh desain OOFSM digambarkan pada Gambar 2.3. Pada

Gambar 2.3 tersebut tampak relasi antara class yang satu dengan class yang lain.


Gambar 2.6 Contoh OOFSM untuk mesin minuman dalam kaleng

(Sumber: Yacoub, 1998)

Desain pada FSM berbasis objek berdasarkan pemicu transisi state dibagi

menjadi dua golongan yaitu state driven dan owner driven. Pada desain state driven,

maka transisi state di picu pada saat program state sedang dijalankan. Semua metode

atau subrutin yang mewakili seluruh aksi dan event ditempatkan pada class state dan

entitas pengguna state yang akan membuat instance dari tiap state yang akan dialami

oleh entitas tersebut. Sedangkan pada desain owner driven, maka transisi state dipicu

pada saat terjadi event pada entitas, dan seluruh aksi dan event ditempatkan pada class

entitas tersebut (Wijaya, 2010).

Contoh desain state driven transition ditunjukkan pada Gambar 2.4.

Gambar 2.7 Contoh OOPFSM Menggunakan State Driven Transition

(Sumber: Yacoub, 1998)


Pertimbangan yang harus diperhatikan ketika membuat desain OOPFSM ada

tiga hal yaitu (Wijaya, 2010):

1. Kemudahan untuk dipahami (understandability).

2. Kemudahan untuk diamati mulai dari desain sampai implementasi

(Traceability).

3. Fleksibel dan memungkinkan untuk dilakukan penambahan (Flexibility and

extendsibility).

2.2 Bagan Alir (Flowchart)

Flowchart merupakan diagram yang memperlihatkan aliran kontrol seluruh sistem

termasuk program, input, output, dan database. (Whitten, 1998). Dengan adanya

flowchart, maka runtutan proses berjalannya suatu aplikasi dapat dilihat lebih jelas.

Simbol-simbol FlowChart dapat dilihat pada Tabel 3.3.


Tabel 2.4 Simbol-simbol FlowChart

Simbol Nama Fungsi

Terminator

(Terminal) Menunjukkan awal dan akhir program

Preparation

(Persiapan) Memberikan nilai awal pada suatu variabel

atau counter

Garis Alir Menunjukkan arah aliran program

Proses Proses perhitungan dan proses pengolahan

data

Keputusan Operasi perbandingan logika

Input/Ouput Data Proses input output data, parameter dan

informasi

Proses Terdefinisi Proses yang detilnya dijelaskan terpisah,

misalnya dalam bentuk subroutine.

Penghubung Penghubung bagian-bagian FlowChart yang

berada pada satu halaman.

Penghubung

Halaman Penghubung bagian-bagian FlowChart yang

berada pada halaman berbeda.

Struktur Case Memproses sebuah blok statemen pada salah

satu kondisi case yang terpenuhi.


2.3 Interaksi Manusia Dengan Komputer

Mengapa interaksi manusia dengan komputer dibutuhkan?. Contoh: tombol pilihan

save (menyimpan) dan delete (menghapus) pada menu di suatu aplikasi. Jika terjadi

kesalahan pada penerapan pilihan ini, maka dapat menyebabkan kehilangan beberapa

jam kerja atau sama dengan bencana. Dari sinilah sistem harus didesain dengan

memperhatikan dan menghargai pekerjaan yang dilakukan orang sehari-hari (Subakti,

2006).

2.3.1 Definisi Interaksi Manusia Dengan Komputer

Bidang ilmu interaksi manusia dan komputer adalah ilmu yang mempelajari tentang

bagaimana mendesain, mengevaluasi, dan mengimplementasikan sistem komputer

yang interaktif sehingga dapat digunakan oleh manusia dengan mudah. Definisi

interaksi manusia dan komputer sebuah hubungan antara manusia dan komputer yang

mempunyai karakteristik tertentu untuk mencapai suatu tujuan tertentu dengan

menjalankan sebuah sistem yang bertopengkan sebuah antarmuka (interface)

(Ariyus,2007).

2.3.2 Prinsip Utama Mendesain Antarmuka (Interface)

Berikut ini beberapa hal yang menjadi prinsip utama mendesain antarmuka yang baik

dengan memperhatikan karakteristik manusia & komputer (Hestiningsih, 2007) :

2.3.2.1 User compatibility

Antarmuka merupakan topeng dari sebuah sistem atau sebuah pintu gerbang masuk ke

sistem dengan diwujudkan ke dalam sebuah aplikasi perangkat lunak. Oleh karena itu

sebuah perangkat lunak seolah-olah mengenal penggunanya, mengenal karakteristik

penggunanya, dari sifat sampai kebiasaan manusia secara umum. Desainer harus


mencari dan mengumpulkan berbagai karakteristik serta sifat dari pengguna karena

antarmuka harus disesuaikan dengan pengguna yang jumlahnya bisa jadi lebih dari 1

dan mempunyai karakter yang berbeda. Hal tersebut harus terpikirkan oleh desainer

dan tidak dianjurkan merancang antarmuka dengan didasarkan pada dirinya sendiri.

Survey adalah hal yang paling tepat (Hestiningsih, 2007).

2.3.2.2 Product Compatibility

Sebuah aplikasi yang bertopengkan antarmuka harus sesuai dengan sistem aslinya.

Seringkali sebuah aplikasi menghasilkan hasil yang berbeda dengan sistem manual

atau sistem yang ada. Hal tersebut sangat tidak diharapkan dari perusahaan karena

dengan adanya aplikasi perangkat lunak diharapkan dapat menjaga produk yang

dihasilkan dan dihasilkan produk yang jauh lebih baik. Contoh : sistem melalui

antarmuka diharapkan menghasilkan report/laporan serta informasi yang detail dan

akurat dibandingkan dengan sistem manual (Hestiningsih, 2007).

2.3.2.3 Task Compatibility

Sebuah aplikasi yang bertopengkan antarmuka harus mampu membantu para

pengguna dalam menyelesaikan tugasnya. Semua pekerjaan serta tugas-tugas

pengguna harus diadopsi di dalam aplikasi tersebut melalui antarmuka. Sebisa

mungkin pengguna tidak dihadapkan dengan kondisi memilih dan berpikir, tapi

pengguna dihadapkan dengan pilihan yang mudah dan proses berpikir dari tugas-tugas

pengguna dipindahkan dalam aplikasi melalui antarmuka. Contoh : Pengguna hanya

klik setup, tekan tombol next, next, next, finish, ok untuk menginstal suatu perangkat

lunak (Hestiningsih, 2007).


2.3.2.4 Work Flow Compatibility

Sebuah sistem sudah pasti mengapdopsi sistem manualnya dan didalamnya tentunya

terdapat urutan kerja dalam menyelesaikan pekerjaan. Dalam sebuah aplikasi,

software engineer harus memikirkan berbagai runutan rununtan pekerjaan yang ada

pada sebuah sistem. Jangan sampai pengguna mengalami kesulitan dalam

menyelesaikan pekerjaannya karena pengguna mengalami kebingungan ketika urutan

pekerjaan yang ada pada sistem manual tidak ditemukan pada perangkat lunak yang

dihadapinya. Selain itu pengguna jangan dibingungkan dengan pilihan-pilihan menu

yang terlalu banyak dan semestinya menu-menu merupakan urutan dari runutan

pekerjaan. Sehingga dengan workflow compatibility dapat membantu seorang

pengguna dalam mempercepat pekerjaannya (Hestiningsih, 2007).

2.3.2.5 Consistency

Sebuah sistem harus sesuai dengan sistem nyata serta sesuai dengan produk yang

dihasilkan. Banyak perusahaan dalam menjalankan sistemnya menggunakan sistem

yang berbeda di setiap divisi dalam perusahaan tersebut. Ada pula yang menggunakan

aplikasi yang sama di divisi yang berbeda, seringkali keseragaman dalam menjalankan

sistem tidak diperhatikan. Oleh karena itu software engineer harus memperhatikan

hal-hal yang bersifat konsisten pada saat merancang aplikasi khususnya antarmuka,

contoh: penerapan warna, struktur menu, font, format desain yang seragam pada

antarmuka di berbagai bagian, sehingga pengguna tidak mengalami kesulitan pada

saat berpindah posisi pekerjaan atau berpindah lokasi dalam menyelesaikan pekerjaan.

Hal itu didasarkan pada karakteristik manusia yang mempunyai pemikiran yang

menggunakan analogi serta kemampuan manusia dalam hal memprediksi. Contoh :

keseragaman tampilan toolbar pada Word, Excell, PowerPoint, Access hampir sama

(Hestiningsih, 2007).


2.3.2.6 Familiarity

Sifat manusia mudah mengingat dengan hal-hal yang sudah sering

dilihatnya/didapatkannya. Secara singkat disebut dengan familiar. Antarmuka sebisa

mungkin didesain sesuai dengan antarmuka pada umumnya, dari segi tata letak,

model, dsb. Hal ini dapat membantu pengguna cepat berinteraksi dengan sisem

melalui antarmuka yang familiar bagi pengguna (Hestiningsih, 2007).

2.3.2.7 Simplicity

Kesederhanaan perlu diperhatikan pada saat membangun antarmuka. Tidak selamanya

antarmuka yang memiliki menu banyak adalah antarmuka yang baik. Kesederhanaan

disini lebih berarti sebagai hal yang ringkas dan tidak terlalu berbelit. Pengguna akan

merasa jengah dan bosan jika pernyataan, pertanyaan dan menu bahkan informasi

yang dihasilkan terlalu panjang dan berbelit. Pengguna lebih menyukai hal-hal yang

bersifat sederhana tetapi mempunyai kekuatan/bobot (Hestiningsih, 2007).

2.3.2.8 Direct Manipulation

Pengguna berharap aplikasi yang dihadapinya mempunyai media atau tools yang

dapat digunakan untuk melakukan perubahan pada antarmuka tersebut. Pengguna

ingin sekali aplikasi yang dihadapannya bisa disesuaikan dengan kebutuhan, sifat dan

karakteristik pengguna tersebut. Selain itu, sifat dari pengguna yang suka merubah

atau mempunyai rasa bosan. Contoh : tampilan warna sesuai keinginan (misal pink)

pada window bisa dirubah melalui desktop properties, tampilan skin winamp bisa

dirubah, dll (Hestiningsih, 2007).


2.3.2.9 Control

Prinsip control ini berkenaan dengan sifat pengguna yang mempunyai tingkat

konsentrasi yang berubah-ubah. Hal itu akan sangat mengganggu proses berjalannya

sistem. Kejadian salah ketik atau salah entry merupakan hal yang biasa bagi seorang

pengguna. Akan tetapi hal itu akan dapat mengganggu sistem dan akan berakibat

sangat fatal karena salah memasukkan data 1 digit/1 karakter saja informasi yang

dihasilkan sangat dimungkinkan salah. Oleh karena itu software engineer haruslan

merancang suatu kondisi yang mampu mengatasi dan menanggulangi hal-hal seperti

itu. Contoh : “illegal command”, “can’t recognize input” sebagai portal jika terjadi

kesalahan (Hestiningsih, 2007).

2.3.2.10 WYSIWYG

WYSIWYG = what you see is what you get = apa yang didapat adalah apa yang

dilihatnya. Contoh : apa yang tercetak di printer merupakan informasi yang terkumpul

dari data-data yang terlihat di layar monitor pada saat mencari data. Hal ini juga perlu

menjadi perhatian software engineer pada saat membangun antarmuka. Informasi

yang dicari/diinginkan harus sesuai dengan usaha dari pengguna pada saat mencari

data dan juga harus sesuai dengan data yang ada pada sistem (perangkat lunak). Jika

sistem mempunyai informasi yang lebih dari yang diinginkan pengguna, hendaknya

dibuat pilihan (optional) sesuai dengan keinginan pengguna. Bisa jadi yang berlebihan

itu justru tidak diinginkan pengguna. Yang mendasar disini adalah harus sesuai

dengan kemauan dan pilihan dari pengguna (Hestiningsih, 2007).

2.3.2.11 Flexibility

Fleksibel merupakan bentuk dari dari solusi pada saat menyelesaikan masalah.

Software engineer dapat membuat berbagai solusi penyelesaian untuk satu masalah.

Sebagai contoh adanya menu, hotkey, atau model dialog yang lainnya (Hestiningsih,

2007).


2.3.2.12 Responsiveness

Setelah memberikan inputan atau memasukkan data ke sistem melalui antarmuka,

sebaiknya sistem langsung memberi tanggapan/respon dari hasil data yang diinputkan.

Selain teknologi komputer semakin maju sesuai dengan tuntutan kebutuhan manusia,

perangkat lunak yang dibangun pun harus mempunyai reaksi tanggap yang cepat. Hal

ini didasari pada sifat manusia yang semakin dinamis / tidak mau menunggu

(Hestiningsih, 2007).

2.3.2.13 Invisible Technology

Secara umum, pengguna mempunyai keingintahuan sebuah kecanggihan dari aplikasi

yang digunakannya. Untuk itu aplikasi yang dibuat hendaknya mempunyai kelebihan

yang tersembunyi. Bisa saja kelebihan itu berhubungan dengan sistem yang

melingkupinya atau bisa saja kecanggihan atau kelebihan itu tidak ada hubungannya.

Contoh : sebuah aplikasi mempunyai voice recognize sebagai media inputan, pengolah

kata yang dilengkapi dengan language translator (Hestiningsih, 2007).

2.3.2.14 Robustness

Interaksi manusia dan komputer (pembangunan antarmuka) yang baik dapat berupa

frase-frase menu atau error handling yang sopan. Kata yang digunakan harus dalam

kondisi bersahabat sehingga nuansa user friendly akan dapat dirasakan oleh pengguna

selama menggunakan sistem . Contoh yang kurang baik : YOU FALSE !!!, BAD

FILES !!!, FLOPPY ERROR, dsb. Akan lebih baik jika BAD COMMAND OR

FILES NAMES, DISK DRIVE NOT READY,dll (Hestiningsih, 2007).


2.3.2.15 Protection

Suasana nyaman perlu diciptakan oleh software engineer di antarmuka yang

dibangunnya. Nyaman disini adalah suasana dimana pengguna akan betah dan tidak

menemui suasana kacau ketika pengguna salah memasukkan data atau salah eksekusi.

Seorang pengguna akan tetap merasa nyaman ketika dia melakukan kesalahan, misal

ketika pengguna melakukan deleting atau menghapus files tanpa sengaja tidaklah

menjadi kekacauan yang berarti karena misal ada recovery tools seperti undo, recycle

bin, dll atau “are you sure....” . Proteksi disini lebih menjaga kenyamanan pengguna

ketika menggunakan sistem khususnya data-data berupa file (Hestiningsih, 2007).

2.3.2.16 Ease Of Learning And Ease Of Use

Kemudahan dalam mengoperasikan perangkat lunak hanya dengan memandangi atau

belajar beberapa jam saja. Kemudahan dalam memahami icon, menu-menu, alur data

perangkat lunak, dsb. Sesudah mempelajari, pengguna dengan mudah dan cepat

menggunakan perangkat lunak tersebut. Jika sudah memahami tentunya akan

membantu proses menjalankan sistem dengan cepat dan baik (Hestiningsih, 2007).


BAB 2 TINJAUAN PUSTAKA -...

Documents

Transcript of BAB 2 TINJAUAN PUSTAKA -...