BAB 2 LANDASAN TEORI

(1)

BAB 2

LANDASAN TEORI

2.1 Pengertian Umum 2.1.1 Pengertian Sistem

Menurut O'Brien (2005, p29), sistem adalah sekelompok komponen dan elemen-elemen yang saling berhubungan, bekerja sama, dan mendukung demi mencapai tujuan bersama, yaitu menghasilkan output dengan memberikan input dalam proses transformasi yang teratur.

• Input melibatkan kegiatan yang berhubungan dengan penangkapan berbagai elemen yang akan memasuki sistem untuk diproses.

• Pemrosesan melibatkan proses perubahan masukan (input) menjadi keluaran (output).

• Output melibatkan perpindahan elemen yang telah diproduksi oleh proses transformasi ke tujuan akhirnya.

Menurut McLeod Jr & Schell (2004, p9), sistem adalah sekelompok elemen-elemen yang terintegrasi dengan maksud yang sama untuk mencapai suatu tujuan.

2.1.2 Pengertian Informasi

Menurut McLeod Jr & Schell (2004, p12), informasi adalah data yang telah diproses, atau data yang memiliki arti. Sedangkan data terdiri dari fakta-fakta dan angka-angka yang relatif tidak berarti bagi pemakai.

(2)

Menurut Turban, Rainer, & Potter (2003, p15), informasi adalah sebuah koleksi dari fakta (data) yang dikelola dalam beberapa cara sehingga data tersebut memiliki arti bagi penerima. Dengan kata lain, informasi datang dari data yang telah diproses. Data adalah fakta mentah atau penjelasan dasar dari benda, kejadian, aktivitas, dan transaksi yang ditangkap, direkam, disimpan, dan diklasifikasi, tetapi tidak teratur untuk menyampaikan arti tertentu.

2.1.3 Pengertian Transportasi

Menurut Chopra & Meindl (2010, p380), transportasi merujuk pada pergerakan produk dari satu lokasi ke lokasi lain yang dimulai dari sebuah rantai pasokan ke pelanggan. Peran transportasi menjadi semakin penting dalam global

supply chains.

2.1.4 Pengertian Algoritma

Menurut Mutakhiroh, et al. (2007, p33), algoritma merupakan kumpulan perintah yang dapat diterjemahkan secara bertahap dari awal hingga akhir dan digunakan untuk memecahkan suatu permasalahan.

2.1.5 Pengertian Optimasi

Menurut Berlianty & Arifin (2010, p9), optimasi adalah proses pencarian satu atau lebih penyelesaian yang berhubungan dengan nilai-nilai ekstrim dari satu atau lebih objektif pada suatu masalah sampai tidak dapat ditemukan lagi solusi ekstrim.

(3)

2.2 Sistem Informasi

2.2.1 Pengertian Sistem Informasi

Menurut Turban, Rainer, & Potter (2003, p15), sistem informasi adalah mengumpulkan, mengolah, menyimpan, menganalisis, dan menyebarkan informasi untuk sebuah tujuan tertentu. Sistem informasi mengolah input dan menghasilkan output yang dikirimkan kepada user atau kepada sistem lain.

Sistem informasi dapat merupakan kombinasi teratur apa pun dari orang-orang, hardware, software, jaringan komunikasi, dan sumber daya data yang mengumpulkan, mengubah, dan menyebarkan informasi dalam sebuah organisasi (O'Brien, 2005, p5).

Menurut Bennett, Mcrobb, & Farmer (2006, p14), sistem informasi dibangun untuk membantu manusia dalam aktivitasnya dalam upaya mencapai tujuannya mengenai hal-hal yang mungkin dapat terjadi pada aktivitas tersebut. Sistem aktivitas manusia merupakan penjelasan dari arti yang tersedia dalam aktivitas pengembangan sistem informasi. Masing-masing sistem informasi dimaksudkan untuk membantu pemenuhan tujuan dari sistem aktivitas manusia.

2.2.2 Peran Dasar Sistem Informasi dalam Bisnis

Menurut O'Brien (2005, p10), terdapat tiga alasan mendasar untuk semua aplikasi bisnis dalam teknologi informasi yang juga merupakan tiga peran penting sistem informasi untuk sebuah perusahaan bisnis, seperti yang terlihat pada Gambar 2.1.

(4)

Sumber: O'Brien, 2005, p10

Gambar 2.1 Peran Dasar Sistem Informasi dalam Bisnis

2.2.3 Computer-Based Information System (CBIS)

Menurut Turban, Rainer, & Potter (2003, p16), computer-based

information system adalah sebuah sistem informasi yang menggunakan teknologi

komputer dan telekomunikasi untuk melakukan tugas-tugas yang dimaksudkan. Komponen dasar dari sistem informasi adalah sebagai berikut:

• Hardware: seperangkat peralatan yang menerima data dan informasi, mengolahnya, dan memperlihatkannya (Turban, Rainer, & Potter, 2003, p16). • Software: seperangkat program komputer yang memungkinkan hardware

untuk mengolah data (Turban, Rainer, & Potter, 2003, p16). Menurut Turban, Rainer, & Potter (2003, p95), software memungkinkan user untuk membangun sebuah sistem komputer untuk menjalankan fungsi tertentu yang menyediakan nilai bisnis. Ada dua tipe software:

(5)

9 Software sistem: sekumpulan instruksi yang pada umumnya melayani sebagai sebuah penengah antara hardware komputer dan program aplikasi, dan dapat juga dimanipulasi secara langsung oleh user yang memiliki pengetahuan (Turban, Rainer, & Potter, 2003, p95).

9 Software aplikasi: sekumpulan instruksi komputer yang menyediakan fungsionalitas yang lebih spesifik bagi user. Fungsionalitas tersebut dapat luas, seperti pengolahan kata umum, atau sempit, seperti sebuah program pembayaran organisasi (Turban, Rainer, & Potter, 2003, p95).

• Database: sebuah koleksi yang teratur dari file atau record yang berhubungan yang menyimpan data dan hubungan diantara data tersebut (Turban, Rainer, & Potter, 2003, p16).

• Network: sebuah sistem koneksi yang mengijinkan penyebaran sumber daya diantara komputer yang berbeda (Turban, Rainer, & Potter, 2003, p16).

• Procedures: strategi, kebijakan, metode, dan peraturan untuk menggunakan sistem informasi (Turban, Rainer, & Potter, 2003, p16).

• People: elemen yang paling penting dalam sistem informasi; termasuk orang-orang yang bekerja dengan sistem informasi atau menggunakan output (Turban, Rainer, & Potter, 2003, p16).

2.2.4 Pengembangan Sistem

Menurut Turban, Rainer, & Potter (2003, p461), pengembangan sistem merupakan sekumpulan aktivitas yang dibutuhkan secara menyeluruh untuk

(6)

membangun sebuah solusi sistem informasi bagi sebuah masalah atau peluang bisnis.

System Development Life Cycle (SDLC) merupakan metode

pengembangan sistem tradisional yang digunakan oleh kebanyakan organisasi sekarang ini. SDLC adalah sebuah kerangka terstruktur yang terdiri dari proses-proses yang berurutan dari sistem informasi yang dikembangkan (Gambar 2.2). SDLC termasuk investigasi sistem, analisis sistem, perancangan sistem, pemograman, pengujian, implementasi, operasi, dan maintenance (Turban, Rainer, & Potter, 2003, p461).

Sumber: Turban, Rainer, & Potter, 2003, p464

Gambar 2.2 Delapan Tahapan SDLC

Investigasi sistem dimulai dengan masalah bisnis. Masalah (dan peluang) biasanya tidak hanya memerlukan pemahaman dari sudut pandang internal, tetapi juga melihatnya dari sudut pandang sebagai mitra organisasi (supplier atau

(7)

customer). Sudut pandang lain yang berguna adalah dari pesaing (Turban,

Rainer, & Potter, 2003, p464).

Analisis sistem merupakan penilaian dari masalah bisnis yang direncanakan organisasi untuk dapat dipecahkan dengan sebuah sistem informasi. Tahap ini menentukan masalah bisnis, mengidentifikasi penyebabnya, menemukan solusi, dan mengidentifikasi kebutuhan informasi yang harus dipenuhi oleh solusi. Pemahaman masalah bisnis membutuhkan pemahaman pada beragam proses yang terlibat di dalamnya (Turban, Rainer, & Potter, 2003, p467).

Menurut Turban, Rainer, & Potter (2003, p468), perancangan sistem menjelaskan bagaimana sistem akan melakukan tugas untuk dapat memecahkan masalah bisnis. Hasil dari fase perancangan sistem adalah perancangan teknikal yang dikhususkan pada:

• Output, input, dan user interface sistem.

• Hardware, software, database, telekomunikasi, personal, dan prosedur. • Bagaimana komponen-komponen terintegrasi.

Pemograman melibatkan perubahan dari spesifikasi perancangan ke dalam kode komputer (Turban, Rainer, & Potter, 2003, p468). Bahasa pemograman menyediakan blok bangunan dasar untuk seluruh software sistem dan aplikasi. Bahasa pemograman memungkinkan manusia untuk memberitahu komputer hal apa yang dilakukan dan maksud dari sistem software dikembangkan (Turban, Rainer, & Potter, 2003, p109). Bahasa pemograman yang digunakan dalam sebuah lingkungan grafis biasanya merujuk pada bahasa

(8)

pemograman visual. Bahasa ini menggunakan sebuah mouse, ikon, simbol pada layar, atau menu pull-down untuk membuat pemograman lebih mudah dan intuitif. Visual Basic dan Visual C++ merupakan contoh dari bahasa pemograman visual (Turban, Rainer, & Potter, 2003, p112).

Pengujian dirancang untuk mendeteksi error (”bugs”) dalam kode komputer. Pengujian memeriksa apabila kode komputer akan menghasilkan hasil yang diharapkan dan diinginkan pada beberapa kondisi tertentu. Pengujian memerlukan sejumlah besar waktu, usaha, dan biasa untuk dapat dilakukan (Turban, Rainer, & Potter, 2003, p470).

Implementasi adalah proses pengkonversian dari sistem lama ke sistem baru. Dalam sebuah proses konversi paralel, sistem lama dan sistem baru dioperasikan secara bersamaan pada sebuah periode waktu. Dalam sebuah proses konversi langsung, sistem lama dihentikan dan sistem baru dinyalakan pada satu waktu tertentu. Proses konversi pilot memperkenalkan sistem baru dalam satu bagian dari organisasi seperti dalam satu bangunan atau dalam satu area fungsional. Proses konversi bertahap memperkenalkan komponen-komponen dari sistem baru, seperti modul individu, dalam tahapan (Turban, Rainer, & Potter, 2003, p471).

Setelah konversi, sistem baru akan beroperasi untuk satu waktu, sampai sistem baru tidak lagi memenuhi tujuannya. Sistem memerlukan beberapa tipe

maintenance, yaitu debugging yang merupakan sebuah proses yang berkelanjutan

sepanjang kehidupan sistem dan updating yang digunakan untuk mengakomodasi perubahan dalam kondisi bisnis (Turban, Rainer, & Potter, 2003, p471).

(9)

2.3 Algoritma Optimasi

Menurut Suyanto (2010, p1), algoritma optimasi (optimization

algorithms) dapat didefinisikan sebagai algoritma atau metode numerik untuk

menemukan nilai x yang akan menghasilkan nilai sekecil (atau sebesar) mungkin pada suatu fungsi f(x).

Menurut Suyanto (2010, p2-6), cara pengklasifikasian algoritma optimasi yang biasa dilakukan, antara lain:

• Berdasarkan metode operasinya:

9 Algoritma deterministik: pada setiap langkah eksekusi hanya terdapat maksimum satu jalan untuk diproses.

9 Algoritma probabilitik: digunakan untuk memecahkan permasalahan dengan ruang pencarian yang sangat besar. Hampir semua algoritma probabilistik menggunakan konsep pengambilan sampel secara acak yang berulang-ulang (repeated random sampling) untuk menghasilkan solusi. Solusi”bagus” yang dihasilkan belum tentu merupakan solusi paling optimum (global optimum), tetapi sudah dapat diterima oleh user.

• Berdasarkan akurasi dan kecepatan:

9 Optimasi online: ditujukan untuk permasalahan yang membutuhkan solusi dalam waktu cepat dan biasanya permasalahan tersebut terjadi secara berulang-ulang.

9 Optimasi offline: ditujukan untuk permasalahan yang membutuhkan solusi tidak dalam waktu cepat dan biasanya masalah ini terjadi dalam periode waktu yang lama.

(10)

• Berdasarkan analogi yang digunakan:

9 Algoritma minimasi: algoritma yang menggunakan analogi meminimalkan sesuatu pada dunia nyata.

9 Algoritma maksimasi: algoritma yang menggunakan analogi memaksimalkan sesuatu pada dunia nyata.

2.4 Konsep Perencanaan Rute

Menurut Woodward (1986, pp112-113), perencanaan rute merupakan bagian penting dalam pengiriman yang bermanfaat untuk meminimalkan biaya pengiriman. Penggunaan komputer sebagai basis perhitungan, penyimpanan informasi, dan penghubung dengan departemen pengiriman merupakan langkah yang pesat dalam menyusun rute kendaraan. Dengan digunakannya teknik ini, maka kegiatan pengiriman barang sehari-hari dapat mengefisienkan penggunaan waktu kendaraan maupun jarak tempuh kendaraan.

2.5 Pencarian Jalur Terpendek

Menurut Mutakhiroh, et al. (2007, p34), secara umum penyelesaian masalah pencarian jalur terpendek dapat dilakukan menggunakan dua buah metode, yaitu metode algoritma konvensional dan metode heuristik.

• Metode konvensional: berupa algoritma yang menggunakan perhitungan matematis biasa, seperti: algoritma Djikstraa, algoritma Floyd-Warshall, dan algoritma Bellman-Ford.

(11)

• Metode heuristik: sub bidang dari kecerdasan buatan yang digunakan untuk melakukan pencarian dan penentuan jalur terpendek, seperti: algoritma semut dan algoritma genetika.

2.6 Traveling Salesman Problem (TSP)

2.6.1 Pengertian TSP

TSP merupakan sekumpulan kota dan biaya perjalanan (atau jarak) yang diberikan antara masing-masing pasangan kota yang digunakan untuk menemukan jalur terbaik kunjungan ke semua kota dan kembali ke titik awal dalam upaya meminimalkan biaya atau jarak perjalanan (Davendra, 2010, p1). Tujuan dari TSP adalah untuk menemukan jalur terpendek dengan melewati semua kota tepat satu kali, dan akhirnya kembali ke kota awal (Panigrahi, Shi, & Lim, 2011, p375).

2.6.2 Klasifikasi TSP

2.6.2.1 Symmetric Traveling Salesman Problem (STSP)

Menurut Davendra (2010, p1), V = {v1, ..., vn} merupakan sekumpulan

kota, A = {(r,s) : r,s ∈ V menjadi kumpulan sisi, dan drs = dsr menjadi sebuah

pengukuran yang berhubungan dengan sisi (r,s) ∈ A. STSP merupakan masalah dalam menemukan sebuah panjang minimal perjalanan tertutup yang mengunjungi masing-masing kota satu kali.

(12)

2.6.2.2 Asymmetric Traveling Salesman Problem (ATSP)

Menurut Davendra (2010, p2), jika drs ≠ dsr setidaknya untuk satu (r,s)

kemudian TSP menjadi sebuah ATSP. Menurut Davendra (2010, p7) yang mengutip dari Dantzig, Fulkerson, & Johnson (1954) mengatakan bahwa formulasi memperluas kasus asimetris menjadi lebih mudah.

2.7 Pengertian Metaheuristik

Menurut Dorigo & Stutzle (2004, p33), metaheuristik merupakan sekumpulan konsep algoritma yang digunakan dalam penentuan metode heuristik untuk diterapkan pada masalah yang berbeda. Jadi, metaheuristik adalah sebuah kerangka algoritma umum yang juga melakukan perubahan dalam pengadaptasian pada sebuah masalah khusus.

Menurut Dorigo & Stutzle (2004, p33), penggunaan metaheuristik meningkatkan kemampuan pencarian solusi dengan kualitas tinggi yang berhubungan dengan masalah optimisasi kombinasi.

2.8 Ant Colony Optimization (ACO)

Menurut Berlianty dan Arifin (2010, pp61-62), algoritma semut pertama kali dikemukakan oleh Dorigo dan kawan-kawan yang merupakan sebuah pendekatan awal terhadap berbagai masalah sulit seperti masalah Traveling

Salesman Problem dan masalah tugas ganda (Quadratic Assignment Problem).

ACO terinspirasi dari perilaku spesies semut dalam mencari makan. Semut-semut tersebut meninggalkan feromon di tanah dalam upaya untuk menandai beberapa jalur yang disenangi yang harus diikuti oleh anggota lainnya

(13)

dari koloni. ACO memanfaatkan sebuah mekanisme serupa untuk memecahkan permasalahan optimisasi (Dorigo, Birattari, & St¨utzle, 2006, p28).

Menurut Panigrahi, Shi, & Lim (2011, p374), prinsip dasar dari ACO adalah bahwa semut-semut seringkali menemukan jalur terpendek antara sumber makanan dan sarang semut. Semut asli meninggalkan feromon di tanah pada saat berjalan, dan semut asli memiliki sebuah kesukaan untuk melewati jalur yang memiliki jumlah feromon yang lebih banyak. Gambar 2.3 menunjukkan prinsip pemanfaatan feromon semut untuk membangun jalur terpendek dari sebuah sarang ke sumber makanan dan kembali.

Sumber: Panigrahi, Shi, & Lim, 2011, p374

Gambar 2.3 Prinsip ACO

Dorigo & Stutzle (2004, p67) menyatakan bahwa perjalanan semut dibangun dengan prosedur berikut: (1) pemilihan, yang didasarkan pada beberapa kriteria, seperti kota awal dimana semut berada; (2) penggunaan feromon dan nilai heuristik untuk membangun sebuah rute perjalanan dengan memasukkan kota yang belum dikunjungi semut; dan (3) kembali ke kota awal. Setelah seluruh semut menyelesaikan perjalanannya, semut-semut akan meninggalkan

(14)

feromonnya pada perjalanan yang dilewatinya. Sebagai gambaran, Gambar 2.4 mengilustrasikan pemilihan kota tujuan selanjutnya.

Sumber: Dorigo & Stutzle, 2004, p67

Gambar 2.4 Pemilihan Kota Selanjutnya

Menurut Dorigo, Birattari, & St¨utzle (2006, p31), metaheuristik ACO dapat dilihat dari algoritma berikut:

Set parameters, initialize pheromone trails

While termination condition not met do

Construct Ant Solutions Apply Local Search (optional) Update Pheromones

Endwhile

Setelah tahap inisialisasi dilakukan, metaheuristik mengulang lebih dari tiga fase: pada masing-masing iterasi, sejumlah solusi dibangun oleh semut; solusi ini kemudian dikembangkan melalui pencarian lokal (tahapan ini bersifat optional), dan pada akhirnya feromon diperbaharui (Dorigo, Birattari, & St¨utzle, 2006, p31).

(15)

2.8.1 Nearest Neighbor (NN)

Salesman memulai pada beberapa kota dan kemudian mengunjungi kota

terdekat dari kota awal. Dari sana kemudian akan mengunjungi kota-kota terdekat dan juga lokasi yang belum dikunjungi sejauh ini, sampai seluruh kota telah dikunjungi, dan salesman kembali pada titik awal (Reinelt, 1994, p73; Johnson & McGeoch, 1995, pp7-8).

Menurut Reinelt (1994, p74), prosedur dari nearest neighbor: (1) memilih sebuah node j secara bebas, kemudian menetapkan l = j dan T = {1, 2, …, n}\{j}; (2) selama T ≠ Ø lakukan langkah berikut: (2.1) cij = min {cli | i ∈ T} dan (2.2)

menghubungkan l ke j dan T = T \ {j} dan l = j; dan (3) menghubungkan l kepada

node pertama (yang dipilih pada langkah (1) untuk membentuk sebuah

perjalanan.

2.8.2 Ant Colony System (ACS)

Menurut Suyanto (2010, p220), Ant Colony System (ACS) merupakan metode perbaikan dari Ant System (AS) yang menambahkan pembaharuan feromon lokal sebelum pembaharuan feromon global (untuk sebuah tour secara lengkap) dilakukan.

Menurut Dorigo & Gambardella (1997, p55), ACS memiliki tiga aspek utama: (1) aturan transisi yang menyediakan sebuah jalan langsung untuk menyeimbangkan antara eksplorasi sisi baru dan eksploitasi dari akumulasi pengetahuan mengenai masalah; (2) aturan pembaharuan global diterapkan hanya kepada rute perjalanan semut terbaik; dan (3) ketika semut membangun sebuah solusi, aturan pembaharuan feromon lokal diterapkan.

(16)

Penetapan parameter pada ACS yang didasarkan pada pembelajaran ACS untuk masalah TSP yang menghasilkan kinerja yang baik, antara lain: β = 2 sampai 5, ρ = 0.1, m = 10, α = 0.1, q0 = 0.9, dan nilai τ0 = 1/n.Cnn. Cnn merupakan

panjang dari sebuah perjalanan yang dihasilkan dari heuristik nearest neighbor. Sedangkan n merupakan jumlah kota (Dorigo & Stutzle, 2004, p71; Dorigo & Gambardella, 1997, p56).

2.8.2.1 Aturan Transisi

Menurut Dorigo & Gambardella (1997, p55), pada tahap ini seekor semut diposisikan pada node r memilih kota s dengan aturan penerapan sebagai berikut:

( )

{

[

( )

]

[

( )

]

}

⎩ ⎨ ⎧ _τ _⋅ _η = ∈ β S u , r u , r max arg s u Jk r bias) i (eksploras sebaliknya si) (eksploita q q jika , ≤ ₀ (1)

Menurut Dorigo & Gambardella (1997, p55), cara menghitung nilai peluang semut k pada kota r memilih untuk bergerak ke kota s:

( )

[

( )

]

[

]

[

( )

]

( ) ⎪ ⎪ ⎩ ⎪⎪ ⎨ ⎧ ∑ τ ⋅ η η ⋅ τ = ∈ β β 0 u , r u , r s , r s , r s , r p r J u k k

( )

lainnya r J s jika ∈ _k (2)

Menurut Dorigo & Gambardella (1997, p56), setiap waktu seekor semut pada kota r harus memilih sebuah kota s untuk dilalui dengan memberi contoh nilai random 0 ≤ q ≤ 1. Jika q ≤ q0, maka sisi terbaik s akan dipilih (eksploitasi), sebaliknya sebuah sisi akan dipilih berdasarkan nilai peluang pk(r,s) (eksplorasi bias) jika q < q0.

(17)

Keterangan:

τ = nilai feromon

η = invers jarak δ, bernilai sebesar δ1

Jk(r) = kumpulan kota yang akan dikunjungi oleh semut k pada kota r β = parameter penentu kepentingan relatif feromon dengan jarak (β > 0) q = angka random terdistribusi seragam, bernilai antara 0 sampai 1

q0 = parameter penentu kepentingan relatif antara eksploitasi dengan eksplorasi (0 ≤ q0 ≤ 1)

S = variabel acak yang dipilih berdasarkan distribusi peluang pk (r,s)

2.8.2.2 Aturan Pembaharuan Lokal

Menurut Dorigo & Gambardella (1997, p56), ketika membangun sebuah solusi dari TSP, semut mengunjungi sisi dan mengubah tingkat feromonnya dengan menerapkan aturan pembaharuan lokal dengan nilai sebagai berikut:

( ) ( )

1- r,s

( )

r,s s)

,

(r ← ρ ⋅τ +ρ⋅Δτ

τ ₍₃₎

Menurut Efendi & Maulinda (2010, p93), pengaruh dari pembaharuan lokal ini adalah untuk membuat tingkat ketertarikan ruas-ruas yang ada berubah secara dinamis: setiap kali seekor semut menggunakan sebuah ruas maka ruas ini dengan segera akan berkurang tingkat ketertarikannya, secara tidak langsung semut yang lain akan memilih ruas-ruas lain yang belum dikunjungi.

Keterangan:

(18)

2.8.2.3 Aturan Pembaharuan Global

Menurut Dorigo & Gambardella (1997, p56), pada ACS hanya semut terbaik (semut yang membangun perjalanan terpendek mulai dari awal jalur perjalanan) yang diperbolehkan untuk meninggalkan feromon. Pembaharuan global dilakukan setelah seluruh semut telah menyelesaikan perjalanannya. Tingkat feromonnya diperbaharui sesuai dengan:

( ) ( )

1- r,s

( )

r,s s) , (r ← α ⋅τ +α⋅Δτ τ ₍₄₎ Dimana:

( )

⎩ ⎨ ⎧ = τ Δ − 0 L s , r 1 gb

( )

sebaliknya terbaik global perjalanan s r, jika , ∈ (5) Keterangan:

α = parameter kerusakan feromon (0 < α < 1) Lgb = panjang dari perjalanan global terbaik

2.9 Object-Oriented

Menurut Bennett, Mcrobb, & Farmer (2006, p60), pendekatan

object-oriented menyediakan sebuah mekanisme untuk memetakan masalah dunia nyata

menjadi abstraksi software yang akan dikembangkan secara efektif. Penggunaan dari pendekatan object-oriented menjadi semakin diperlukan karena kebutuhan sistem informasi yang semakin meningkat kerumitannya. Object-orientation juga bertujuan untuk menyediakan sebuah mekanisme dalam mendukung penggunaan ulang dari kode program, model perancangan, dan analisis.

(19)

2.10 System Definition

Menurut Mathiassen, et al. (2000, p24), system definition adalah sebuah penjelasan ringkas dari sebuah sistem terkomputerisasi yang terlihat dalam bahasa alami. System definition memperlihatkan properti dasar untuk pengembangan dan penggunaan sistem.

2.10.1 FACTOR

Menurut Mathiassen, et al. (2000, p39-40), kriteria FACTOR terdiri dari enam elemen:

• Functionality: fungsi sistem yang mendukung tugas dari application domain. • Application domain: bagian dari sebuah organisasi yang mengadministrasikan,

mengawasi, atau mengendalikan sebuah problem domain.

• Conditions: kondisi pada saat sistem akan dikembangkan dan digunakan. • Technology: baik teknologi yang digunakan untuk mengembangkan sistem

dan teknologi yang akan digunakan untuk menjalankan sistem. • Objects: objek-objek utama dalam problem domain.

• Responsibility: tanggung jawab keseluruhan sistem dalam hubungannya dengan konteks.

Kriteria FACTOR dapat digunakan dalam dua cara, yaitu dapat digunakan untuk mendukung pengembangan system definition. Atau, definisi dapat dimulai dengan menjelaskan sistem dan kemudian menggunakan kriteria untuk melihat bagaimana system definition memenuhi masing-masing dari enam faktor tersebut (Mathiassen, et al. 2000, p40).

(20)

2.10.2 Rich Picture

Rich picture digunakan selama seleksi sistem untuk menunjukkan

keseluruhan persepsi dari tugas dalam menghadapi proyek pengembangan sistem. Rich picture secara khusus menjelaskan baik sebuah masalah sistem dan

application domain. Rich picture tidak didasarkan pada notasi khusus

(Mathiassen, et al., 2000, p335).

2.10.3 Activity Diagram

Menurut Bennett, Mcrobb, & Farmer (2010, pp122-123), activity diagram digunakan untuk memodelkan aspek yang berbeda dari sebuah sistem dalam pemodelan proses bisnis sebuah sistem yang sudah ada atau potensial. Oleh sebab itu, activity diagram ini digunakan dalam siklus hidup pengembangan sistem. Activity diagram sesungguhnya merupakan diagram alir dalam sebuah konteks object-oriented.

Menurut Bennett, Mcrobb, & Farmer (2010, p123), tujuan digunakannya

activity diagram antara lain:

• Untuk memodelkan sebuah proses atau tugas.

• Untuk menjelaskan sebuah fungsi sistem yang diwakilkan oleh sebuah use

case.

• Untuk menjelaskan logika operasi dalam spesifikasi operasi.

(21)

2.11 Object Oriented Analysis & Design (OOA&D)

Menurut Mathiassen, et al. (2000, p135), Object Oriented Analysis &

Design (OOA&D) merupakan sebuah metode yang digunakan untuk

menganalisis dan merancang sistem yang berorientasi objek.

Problem domain adalah bagian dari sebuah konteks yang

diadministrasikan, diawasi, atau dikendalikan oleh sebuah sistem. Application

domain adalah organisasi yang mengadministrasikan, mengawasi, atau

mengendalikan sebuah problem domain (Mathiassen, et al. 2000, p6). Hubungan antara problem domain dan application domain terlihat pada Gambar 2.5.

Sumber: Mathiassen, et al., 2000, p7

Gambar 2.5 Konteks Sistem

Menurut Mathiassen, et al. (2000, p15), ada empat aktivitas utama dalam OOA&D, seperti yang terlihat pada Gambar 2.6:

• Analisis problem domain • Analisis application domain • Architectural design

(22)

Sumber: Mathiassen, et al., 2000, p15

Gambar 2.6 Empat Aktivitas Utama dalam OOA&D

2.11.1 Analisis Problem Domain

Pemodelan problem domain menyediakan sebuah bahasa dalam menampilkan kebutuhan kepada sistem. Tujuan dari analisis problem domain adalah untuk mengembangkan sebuah model (Mathiassen, et al., 2000, pp45-46).

Istilah-istilah yang terdapat dalam analisis problem domain:

• Objek: sebuah entitas dengan identitas, state, dan behavior. Selama analisis

problem domain, sebuah objek adalah sebuah abstraksi dari fenomena dalam problem domain tersebut, contoh: customer, pegawai, dan kontrak

(23)

• Event: sebuah event merupakan abstraksi dari sebuah aktivitas atau proses

problem domain yang ditunjukkan atau dialami oleh satu atau lebih objek

(Mathiassen, et al., 2000, p51).

• Class: sebuah penjelasan dari sekumpulan objek yang membagi struktur, pola

behavior, dan atribut (Mathiassen, et al., 2000, p53).

• Menurut Mathiassen, et al. (2000, p72), struktur antara kelas ada dua tipe: 9 Generalization structure: sebuah kelas umum (super class) yang

menjelaskan properti umum ke sekelompok kelas khusus (subclasses) (Mathiassen, et al., 2000, p72).

Struktur generalisasi memperlihatkan pewarisan: kelas khusus mewariskan properti dan pola behavioral dari kelas umum. Properti umum diterapkan pada seluruh objek pada tingkat spesialisasi, dengan penambahan pada properti spesialisasi masing-masing (Mathiassen, et al., 2000, p73).

9 Cluster: sekumpulan kelas yang saling berhubungan. Sebuah cluster menyampaikan keseluruhan pemahaman dari sebuah problem domain dengan membaginya menjadi subdomain yang lebih kecil (Mathiassen, et

al., 2000, p74).

• Menurut Mathiassen, et al. (2000, p75), struktur antara objek ada dua tipe: 9 Aggregation: sebuah objek superior (keseluruhan) terdiri dari sejumlah

objek inferior (bagian). Sebuah struktur agregasi digambarkan sebagai sebuah garis antara kelas dari keseluruhan (whole) dan bagian (part) (Mathiassen, et al., 2000, p76).

(24)

9 Association: sebuah hubungan penting antara sejumlah objek-objek. Sebuah struktur asosiasi juga merupakan sebuah relasi antara dua atau lebih objek. Sebuah struktur asosiasi digambarkan sebagai sebuah garis sederhana antara kelas-kelas yang relevan (Mathiassen, et al., 2000, pp76-77).

• Event trace: sebuah urutan kejadian yang melibatkan sebuah objek tertentu. Sebuah event trace bersifat unik untuk sebuah objek spesifik; event trace merupakan urutan kejadian yang tepat dimana objek terlibat selama sebuah jangka waktu (Mathiassen, et al., 2000, p90).

• Pola behavioral: sebuah penjelasan dari event trace yang memungkinkan untuk seluruh objek di dalam kelas (Mathiassen, et al., 2000, p90).

Menurut Mathiassen, et al. (2000, p93), notasi untuk pola behavioral: 9 Urutan: event dalam sekumpulan kejadian terjadi satu persatu. 9 Seleksi: tepat satu kejadian terjadi dari sekumpulan kejadian. 9 Iterasi: sebuah kejadian terjadi nol atau beberapa kali.

Lambang untuk urutan adalah “+”, lambang untuk seleksi adalah “|”, dan lambang untuk iterasi adalah “*” (Mathiassen, et al., 2000, p93).

• Attribute: sebuah penjelasan properti dari sebuah kelas atau sebuah event. Spesifikasi atribut merupakan sebuah bagian dari sebuah definisi kelas dan didasarkan pada pemahaman dari behavior objek (Mathiassen, et al., 2000, p92).

(25)

Menurut Mathiassen, et al. (2000, p47), langkah-langkah dalam analisis

problem domain:

• Classes: untuk memodelkan problem domain, akan dimulai dari aktivitas kelas, dan melalui proses tersebut akan ditentukan fenomena mana yang penting dalam konteks proyek. Abstraksi, klasifikasi, dan seleksi merupakan tugas utama dalam aktivitas kelas. Aktivitas kelas menghasilkan sebuah event

table (Mathiassen, et al., 2000, p49).

• Structure: struktur berfokus pada hubungan antara kelas-kelas dan objek-objek. Dalam aktivitas struktur, penjelasan ditambahkan dengan memasukkan hubungan struktural antara kelas-kelas dan objek-objek (Mathiassen, et al., 2000, p69).

Class diagram menunjukkan struktur asosiasi di antara kelas-kelas dan

seringkali digunakan sebagai pendukung sejumlah interaksi yang dapat mewakili beberapa use case yang berbeda (Bennett, Mcrobb, & Farmer, 2010, p206). Class diagram menyediakan sebuah gambaran koheren dari problem

domain (Mathiassen, et al., 2000, pp69-70). Notasi penggambaran class diagram dapat dlihat pada Gambar 2.7.

(26)

Gambar 2.7 Notasi Dasar untuk Class Diagram

• Behavior: sistem biasanya berhubungan dengan kenyataan yang dinamis, sehingga harus dapat dipahami hal apa yang akan terjadi dalam problem

domain dalam waktu tersebut. Tujuan dasar sistem adalah untuk mendaftar,

menyimpan, dan menghasilkan informasi mengenai events dari problem

domain. Hasil dari aktivitas behavior ini adalah berupa grafis dalam sebuah statechart diagram (Mathiassen, et al., 2000, p89).

2.11.2 Analisis Application Domain

Analisis application domain berfokus pada penentuan kebutuhan untuk fungsi dan tampilan antar muka sistem yang berinteraksi dengan analisis problem

domain. Tujuan dari analisis problem domain adalah untuk menentukan

kebutuhan untuk model sistem, yang menyediakan kosakata dalam penentuan kebutuhan fungsi dan tampilan antar muka (Mathiassen, et al., 2000, p115).

(27)

Istilah-istilah yang terdapat dalam analisis application domain:

• Aktor: sebuah abstraksi dari user dan sistem lain yang berinteraksi dengan sistem sasaran (Mathiassen, et al., 2000, p119).

• Use case: sebuah pola interaksi antara sistem dan aktor pada application

domain. Perangkat lengkap use case menentukan seluruh penggunaan dari

sistem sasaran dalam application domain (Mathiassen, et al., 2000, p120). • Function: sebuah fasilitas untuk membuat sebuah model berguna bagi aktor.

Sebuah fungsi diaktivasi, dieksekusi, dan menyediakan sebuah hasil (Mathiassen, et al., 2000, p138).

Menurut Mathiassen, et al. (2000, p138-139), ada beberapa macam tipe

fungsi yang menunjukkan relasi antara model dan konteks sistem dan memiliki karakteristik yang membantu ketika fungsi-fungsi dinyatakan. Empat tipe fungsi tersebut antara lain:

9 Fungsi update diaktivasi oleh sebuah event problem domain dan menghasilkan sebuah perubahan dalam state model (Gambar 2.8) (Mathiassen, et al., 2000, p138).

(28)

9 Fungsi signal diaktivasi oleh perubahan dalam state model dan menghasilkan reaksi dalam konteks; reaksi tersebut dapat berupa tampilan pada aktor pada application domain, atau campur tangan langsung pada

problem domain (Gambar 2.9) (Mathiassen, et al., 2000, p138).

Gambar 2.9 Fungsi Signal

9 Fungsi read diaktivasi oleh kebutuhan informasi dalam tugas aktor dan menghasilkan sistem yang menampilkan bagian relevan dari model (Gambar 2.10) (Mathiassen, et al., 2000, p138).

Gambar 2.10 Fungsi Read

9 Fungsi compute diaktivasi oleh kebutuhan informasi dalam tugas aktor dan terdiri dari sebuah perhitungan yang melibatkan penyajian informasi bagi aktor atau model; hasilnya adalah sebuah tampilan dari hasil perhitungan (Gambar 2.11) (Mathiassen, et al., 2000, p138-139).

(29)

Gambar 2.11 Fungsi Compute

Sistem sasaran terdiri dari model (M), function (F), dan interface (I). Konteks sistem terdiri dari application domain (AD) dan problem domain (PD). Untuk masing-masing dari empat tipe tersebut, dijelaskan di mana eksekusi fungsi diinisiasi dan di mana fungsi berdampak (Mathiassen, et al., 2000, p140).

Keterangan gambar:

Dampak dari pemrosesan

* Initiative

• Interface: fasilitas-fasilitas yang membuat sebuah model dan fungsi sistem tersedia bagi aktor. Interface menghubungkan sistem kepada seluruh aktor-aktor yang relevan dalam konteks (Mathiassen, et al., 2000, p151).

(30)

Menurut Mathiassen, et al. (2000, p118), langkah-langkah dalam analisis

application domain:

• Usage: untuk dapat dipergunakan, sebuah sistem harus sesuai dengan

application domain, yaitu melalui penjelasan aktor dan use case berdasarkan

sebuah pemahaman dari aktivitas application domain. Use case menyediakan gambaran kebutuhan dan fungsionalitas sistem dari sudut pandang user (Mathiassen, et al., 2000, p119 ; Bennett, Mcrobb, & Farmer, 2010, p154).

Use case diagram digunakan untuk menunjukkan fungsi yang disediakan

sistem dan user mana yang akan berhubungan dengan fungsi tersebut (Bennett, Mcrobb, & Farmer, 2010, p154). Notasi penggambaran use case

diagram dapat dilihat pada Gambar 2.12.

Gambar 2.12 Notasi untuk Use Case Diagram

• Functions: berfokus pada sistem apakah yang dapat membantu aktor dalam pekerjaannya. Dalam aktivitas usage, pertanyaannya adalah seputar bagaimana sistem akan digunakan. Sulit untuk menganalisis ”apa” tanpa

(31)

menganalisis ”bagaimana”, aktivitas usage dan function terhubung secara dekat (Mathiassen, et al., 2000, p137).

Tujuan dari aktivitas analisis fungsi adalah untuk menentukan kapabilitas pemrosesan informasi dari sistem dengan membangun sebuah daftar lengkap fungsi-fungsi, seperti sebuah spesifikasi terperinci dari bagian yang rumit (Mathiassen, et al., 2000, p139).

Kriteria pusat untuk analisis fungsionalitas sistem adalah bahwa analisis diakhiri dengan sebuah daftar fungsi yang lengkap dan konsisten dengan use

case (Mathiassen, et al., 2000, p139).

• Interface: digunakan oleh aktor-aktor untuk berinteraksi dengan sebuah sistem. Analisis tersebut dimulai dari use case, model masalah, dan kebutuhan fungsional, dan hasil dalam penentuan dari elemen tampilan antar muka (Mathiassen, et al., 2000, p151).

Navigation diagram merupakan sebuah jenis spesial dari statechart diagram yang berfokus pada keseluruhan tampilan antar muka user yang

dinamis. Diagram tersebut menunjukkan keikutsertaan window dan transisi antara keduanya (Mathiassen, et al., 2000, p344). Notasi penggambaran

(32)

Gambar 2.13 Notasi untuk Navigation Diagram

2.11.3 Architectural Design

Arsitektur komponen berfokus pada kelas (aspek stabil) yang menyusun sistem dalam komponen yang berhubungan, dan terutama memperhatikan pertimbangan secara logis. Arsitektur komponen memecahkan sistem menjadi komponen-komponen yang dapat diidentifikasi dan berhubungan satu sama lain (Mathiassen, et al., 2000, p174).

Arsitektur proses berfokus pada objek (aspek dinamis) yang menyusun proses-proses sistem untuk mencapai koordinasi dan penggunaan efisien dari

technical platform, dan terutama memperhatikan pertimbangan secara fisik.

Arsitektur proses memecahkan sistem menjadi beberapa proses yang saling berinteraksi (Mathiassen, et al., 2000, p174).

Hubungan dan perbandingan antara arsitektur komponen dan arsitektur proses dapat dilihat pada Gambar 2.14.

(33)

Gambar 2.14 Arsitektur Komponen dan Arsitektur Proses

Istilah-istilah yang terdapat dalam perancangan arsitektur:

• Kualitas dan objektif perancangan: kriteria-kriteria ini diterapkan untuk menentukan apakah sebuah perancangan memenuhi tujuannya (Bennett, Mcrobb, & Farmer, 2010, p 354). Kriteria-kriteria tersebut dapat dilihat pada Tabel 2.1.

Tabel 2.1 Kriteria Klasik untuk Kualitas Software Kriteria Pengukuran dari

Functional

Kemampuan fungsi untuk dapat bekerja secara benar dan lengkap sesuai dengan harapan dan kebutuhan user (Bennett, Mcrobb, & Farmer, 2010, p354-355).

Efficient

Penghematan sumber daya yang digunakan untuk menjalankan fungsi, meliputi penyimpanan disk, waktu pemrosesan, dan kapasitas jaringan guna untuk mengoptimalkan solusi yang dihasilkan (Bennett, Mcrobb, & Farmer, 2010, p355).

(34)

Economical

Biaya tetap dari hardware dan software yang digunakan dan juga biaya yang ditimbulkan dari menjalankan sistem (Bennett, Mcrobb, & Farmer, 2010, p356).

Reliable

Kehandalan sistem yang diukur dari ketidakmudahan hardware atau

software gagal dan dapat dipercaya untuk memelihara integritas dari data

dalam sistem (Bennett, Mcrobb, & Farmer, 2010, p356).

Secure

Keamanan sistem yang harus dirancang untuk menghindari adanya serangan jahat dari orang luar dan terhadap orang dalam yang tidak berhak (Bennett, Mcrobb, & Farmer, 2010, p356).

Flexible

Kemampuan sistem untuk dapat beradaptasi terhadap perubahan kebutuhan bisnis yang berbeda-beda dari waktu ke waktu (Bennett, Mcrobb, & Farmer, 2010, p356-357).

General

Kemampuan penerapan pada program utilitas dibanding sistem informasi besar, mencakup juga penerapan pada hardware yang berbeda. Sistem yang sama harus dapat digunakan pada client di industri lain (Bennett, Mcrobb, & Farmer, 2010, p357).

Buildable

Kemampuan pembangunan sistem dengan penulisan kode program berdasarkan sudut pandang programmer (Bennett, Mcrobb, & Farmer, 2010, p357).

Manageable Kemampuan pengelolaan terhadap konsekuensi perubahan bagian dari

sistem dalam pengembangan (Bennett, Mcrobb, & Farmer, 2010, p357).

Maintainable Kemampuan perancangan yang baik untuk mendukung pemeliharaan

sistem yang semakin mudah (Bennett, Mcrobb, & Farmer, 2010, p357).

Usable Kemampuan sistem untuk dapat memuaskan kebutuhan user dan

produktif (Bennett, Mcrobb, & Farmer, 2010, p358).

Reusable

Kemampuan sistem untuk dapat dipakai kembali, baik dalam berupa kelas atau komponen yang sudah ada untuk diturunkan ke sistem lain (Bennett, Mcrobb, & Farmer, 2010, p358).

(35)

• Kondisi: teknikal, organisasi, dan kesempatan dan batasan manusia yang terlibat dalam melakukan sebuah tugas (Mathiassen, et al., 2000, p178).

• Arsitektur komponen: sebuah struktur sistem yang menyusun komponen-komponen yang saling berhubungan. Tujuan utama dari arsitektur komponen-komponen adalah bahwa sistem menjadi mendalam dan fleksibel (Mathiassen, et al., 2000, p190-191).

• Komponen: sebuah bagian terbatas dari sebuah sistem dan biasanya mengandung lebih dari satu kelas, yang berfokus pada tanggung jawab komponen dalam hubungannya dengan komponen lainnya (Mathiassen, et al., 2000, p191).

Menurut Mathiassen, et al. (2000, p201), tiga perhatian utama dalam komponen adalah: model, fungsi, dan interface.

9 Model: tanggung jawab utama dari komponen adalah untuk memegang objek yang mewakili problem domain (Mathiassen, et al., 2000, p201). 9 Fungsi: tanggung jawab utama dari sebuah function component adalah

untuk menyediakan fungsionalitas model. Apabila sistem memiliki kebutuhan fungsional yang rumit, maka perlu dilakukan pemisahan pada

function component (Mathiassen, et al., 2000, p203).

9 Interface: tanggung jawab utama dari sebuah interface component adalah untuk menangani interaksi antara aktor dan fungsionalnya (Mathiassen, et al., 2000, p204).

• Arsitektur proses: sebuah struktur pengeksekusian sistem yang terdiri dari proses-proses yang saling bergantungan. Tujuan dari perancangan arsitektur

(36)

proses adalah untuk menyusun kegiatan eksekusi pada sebuah tingkat fisikal (Mathiassen, et al., 2000, p210-211).

Menurut Mathiassen, et al. (2000, p175-176), langkah-langkah dalam perancangan arsitektur:

• Kriteria: membantu dalam mengelompokkan prioritas perancangan. Tidak ada resep umum atau sederhana untuk perancangan yang baik; untuk mencapainya, kondisi dari masing-masing proyek pengembangan tertentu harus dipertimbangkan (Mathiassen, et al., 2000, p177).

• Pola arsitektur client-server: arsitektur ini dikembangkan untuk menangani distribusi dari sebuah sistem antara beberapa processor yang tersebar secara geografis. Komponen-komponen dalam sebuah arsitektur client-server adalah sebuah server dan beberapa client (lihat Gambar 2.15) (Mathiassen, et al., 2000, p197).

Gambar 2.15 Pola Arsitektur Client-Server

Tanggung jawab server adalah untuk menyediakan hal yang umum bagi

(37)

jawab client adalah untuk menyediakan sebuah interface lokal untuk user. Arsitektur berlapis menawarkan sebuah disiplin hierarki, dimana arsitektur

client-server merupakan sebuah ekspresi dari pemikiran jaringan (Mathiassen, et al., 2000, pp197-198).

Untuk memperoleh bentuk tersebut, pola client-server digunakan sebagai sebuah dasar, kemudian diuraikan dalam arsitektur dasar, menggunakan komponen model (M), fungsi (F), dan user interface (U) (Mathiassen, et al., 2000, p200). Macam pola distribusi arsitektur diperlihatkan dalam Tabel 2.2.

Tabel 2.2 Bentuk Berbeda dari Distribusi Arsitektur Client-Server

Client Server Arsitektur

U U + F + M Distributed presentation

U F + M Local presentation

U + F F + M Distributed functionality

U + F M Centralized data

U + F + M M Distributed data

Proses: arsitektur proses membawa kepada tingkatan fisikal dari sistem yang berfokus pada distribusi dan eksekusi, dan bekerja dengan proses dan objek sebagai lawan dari komponen dan kelas. Arsitektur proses juga berhubungan dengan peralatan eksternal yang akan dieksekusi oleh sistem dan dipertimbangkan apabila koordinasi penyebaran sumber daya diperlukan (Mathiassen, et al., 2000, p209).

Component diagram dapat digunakan untuk memodelkan baik pandangan

(38)

komponen fisik yang dipakai (Bennett, Mcrobb, & Farmer, 2010, p564).

Deployment diagram merupakan diagram implementasi utama dalam UML

yang digunakan untuk menunjukkan konfigurasi dari elemen proses waktu berjalan dan artifak software dan proses yang berada di dalamnya (Bennett, Mcrobb, & Farmer, 2010, p566). Notasi penggambaran deployment diagram dapat dilihat pada Gambar 2.16.

Gambar 2.16 Notasi untuk Deployment Diagram

Perancangan arsitektur proses dapat dikatakan sebagai titik keberangkatan dari komponen logis yang muncul dari aktivitas komponen. Tujuannya adalah untuk mencapai sebuah distribusi logis mengenai komponen-komponen dalam processor yang tersedia untuk eksekusi (Mathiassen, et al., 2000, p213).

(39)

Menurut Mathiassen, et al. (2000, p215-219), ada tiga macam pola

distribusi:

9 Pola terpusat: solusi paling mudah bagi masalah distribusi adalah mendistribusikan sesedikit mungkin, yang dapat dicapai dengan menyimpan semua data dalam server pusat dan client hanya menangani

user interface (Gambar 2.17) (Mathiassen, et al., 2000, p215-216).

Gambar 2.17 Pola Terpusat Deployment Diagram

Keuntungan dari pola ini, antara lain: dapat diimplementasi dengan client yang tidak mahal, semua data konsisten dikarenakan hanya berada pada satu tempat, strukturnya sederhana untuk dapat dipahami dan diimplementasi, dan kepadatan jaringannya menengah (Mathiassen, et al., 2000, p216).

(40)

Kerugian dari pola ini, antara lain: kekuatan tingkat rendah, client tidak dapat melakukan apapun apabila server atau jaringan down, waktu pengaksesan tinggi dikarenakan aktivasi beberapa fungsi client termasuk perubahan dengan server, dan perancangan tidak memfasilitasi cadangan (backup) data (Mathiassen, et al., 2000, p217).

9 Pola terdistribusi: pada pola ini, segala sesuatunya didistribusikan kepada

client dan server hanya perlu mengumumkan pembaharuan model antara client. Sebuah salinan dari model lengkap terletak pada masing-masing client (Gambar 2.18) (Mathiassen, et al., 2000, p217).

Gambar 2.18 Pola Terdistribusi Deployment Diagram

Keuntungan dari pola ini, antara lain: waktu pengaksesan rendah, dikarenakan fungsi dan model berada pada client lokal dan tidak terjadi kepadatan jaringan, kekuatan dimaksimasi karena seorang client dapat melanjutkan pekerjaan bahkan ketika jaringan, server, dan seluruh client lain down, dan banyaknya cadangan (backup) data karena setiap client

(41)

memiliki sebuah salinan dari model lengkap (Mathiassen, et al., 2000, p218).

Kerugian dari pola ini, antara lain: jumlah dari data berlimpah dan potensi ketidak-konsistenan antara data yang berada pada client yang berbeda, kepadatan jaringan tinggi sebagai akibat dari pembaharuan pada client diumumkan kepada seluruh client, kebutuhan teknis meningkat karena

client harus menjalankan model, fungsi, dan interface, dan arsitektur akan

lebih rumit untuk dipahami dan diimplementasi (Mathiassen, et al., 2000, p218).

9 Pola terdesentralisasi: pola ini terletak di antara dua pola sebelumnya.

Client memiliki data masing-masing, sehingga hanya data umum yang

terletak dalam server (Gambar 2.19) (Mathiassen, et al., 2000, p218).

: Client Function Model (local) System Interface User Interface

...

: Server Function Model (common) System Interface User Interface More Clients

(42)

Keuntungan dari pola ini, antara lain: konsistensi data karena tidak ada penggandaan data antar client atau antara client dan server, beban jaringan rendah karena jaringan hanya digunakan ketika data umum diperbaharui di

server, dan waktu pengaksesan untuk data lokal rendah, meskipun akses

untuk data umum memerlukan waktu yang lebih panjang (Mathiassen, et al., 2000, p218).

Kerugian dari pola ini, antara lain: seluruh processor harus memiliki kemampuan untuk mengeksekusi fungsi kompleks dan mempertahankan sebuah model besar, biaya hardware meningkat, dan sistem tidak memiliki fasilitas cadangan (backup) built-in, yang memungkinkan perlunya penanganan lokal (Mathiassen, et al., 2000, p218).

2.11.4 Component Design

Menurut Mathiassen, et al. (2000, p231), dua komponen sistem yang umum: model component dan function component. Model component merupakan sebuah bagian dari sistem yang mengimplementasikan model problem domain (Mathiassen, et al., 2000, p236). Function component merupakan sebuah bagian dari sistem yang mengimplementasikan kebutuhan fungsional. Tujuan dari

function component adalah untuk memberikan pengaksesan user interface dan

komponen sistem lainnya dari model. Function component merupakan hubungan antara model dan usage (Mathiassen, et al., 2000, p251-252).

Istilah-istilah yang terdapat dalam perancangan komponen:

• Operasi: sebuah properti proses yang dikhususkan dalam sebuah kelas dan diaktivasi melalui objek kelas (Mathiassen, et al., 2000, p252). Spesifikasi

(43)

operasi merupakan penjelasan yang paling rinci dari perilaku sebuah model sistem (Bennett, Mcrobb, & Farmer, 2010, p 310). Ada dua macam cara umum dalam spesifikasi operasi, yaitu: algoritmic (prosedural) dan

non-algoritmic (deklarasi) (Bennett, Mcrobb, & Farmer, 2010, p 292).

Menurut Mathiassen, et al. (2000, p233), langkah-langkah dalam perancangan komponen:

• Model component: tujuan dari model component adalah mengirimkan data sekarang dan data histori pada fungsi, interface, user, dan sistem lain. Hasil dari aktivitas model component adalah sebuah versi revisi dari class diagram dari aktivitas analisis. Revisi tersebut secara khusus terdiri dari penambahan kelas baru, atribut, dan struktur untuk mewakili event (Mathiassen, et al., 2000, p235-236).

• Function component: behavior dalam sebuah sistem object-oriented dijelaskan sebagai operasi pada kelas sistem. Behavior kemudian dapat diaktivasi melalui objek kelas yang relevan (Mathiassen, et al., 2000, p251).

Menurut Mathiassen, et al. (2000, p265), tiga penjelasan bentuk yang

relevan untuk spesifikasi terperinci dari operasi: spesifikasi operasi, sequence

diagram, dan statechart diagram.

Sequence diagram menunjukkan sebuah interaksi antar objek yang

memodelkan objek pada saat objek tersebut memainkan perannya dan berhubungan melalui pesan (Bennett, Mcrobb, & Farmer, 2010, p262).

(44)

Diagram ini memperlihatkan bagaimana eksekusi operasi dalam sebuah objek melibatkan panggilan untuk operasi dalam objek lain. Dengan kata lain, diagram ini menunjukkan hubungan antara objek-objek dan panggilan operasi (Mathiassen, et al., 2000, p266). Notasi penggambaran sequence diagram dapat dilihat pada Gambar 2.20.

Gambar 2.20 Notasi untuk Sequence Diagram

Statechart diagram digunakan untuk menspesifikasi hubungan antara

sebuah state objek dan perubahan state dalam bentuk dari panggilan operasi, yang menerima dari objek lain atau event problem domain (Mathiassen, et al., 2000, p266). Notasi penggambaran sequence diagram dapat dilihat pada Gambar 2.21.

(45)

Gambar 2.21 Notasi Dasar untuk Statechart Diagram

2.12 Unified Modeling Language (UML)

Unified Modeling Language (UML) merupakan usaha yang dilakukan

untuk menstandarisasi notasi object-oriented yang dimulai pada tahun 1997. UML menjawab kebutuhan notasi dari sebuah proses pengembangan

object-oriented yang dapat membentuk dasar dari generasi otomasi dari bagian kode

program, mulai dari analisis awal sampai penjelasan rancangan terperinci (Mathiassen, et al., 2000, p331). Seluruh konten yang tercakup dalam OOA&D dapat dilihat pada Gambar 2.22.

(46)

Gambar 2.22 Penggunaan Penjelasan OOA&D

2.13 Dokumentasi

Proses dokumentasi memberikan peningkatan pada masalah klasik antara pembuatan sebuah gambaran dan penyimpanan perincian. Rincian dapat menghilangkan gambaran. Sebuah standar dokumentasi membantu dalam mengendalikan kesama-rataan dokumentasi. Meskipun dokumen analisis dan perancangan berbeda, akan tetapi tetap mengikuti prinsip yang sama (Mathiassen, et al., 2000, p299). Sebuah standar dokumentasi memberitahukan hal-hal apa saja yang dikandung dalam sebuah dokumen (Mathiassen, et al., 2000, p301).

(47)

2.13.1 Dokumen Analisis

Menurut Mathiassen, et al. (2000, p300), dokumen analisis merupakan sebuah penyajian koheren dari hasil analisis. Dokumen analisis membentuk dasar untuk sebuah spesifikasi kebutuhan – sebuah persetujuan formal tertulis antara

user dan pengembang.

2.13.2 Dokumen Desain

Menurut Mathiassen, et al. (2000, p300), dokumen desain merupakan sebuah penyajian koheren dari hasil perancangan. Dokumen perancangan harus bertindak sebagai sebuah bingkai referensi untuk masing-masing programmer dan menguatkan kerjasama dan koordinasi diantara programmer.