bab 2 landasan teori - library & knowledge...

13

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.

14

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.

15 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.

16

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:

17

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).

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

18

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

19

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

20

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).

21 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:

Algoritma deterministik: pada setiap langkah eksekusi hanya terdapat

maksimum satu jalan untuk diproses.

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:

Optimasi online: ditujukan untuk permasalahan yang membutuhkan solusi

dalam waktu cepat dan biasanya permasalahan tersebut terjadi secara

berulang-ulang.

Optimasi offline: ditujukan untuk permasalahan yang membutuhkan solusi

tidak dalam waktu cepat dan biasanya masalah ini terjadi dalam periode

waktu yang lama.

22

• Berdasarkan analogi yang digunakan:

Algoritma minimasi: algoritma yang menggunakan analogi meminimalkan

sesuatu pada dunia nyata.

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.

23

• 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.

24 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

25

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

26

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).

27 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.

28

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:

( ) ( )[ ] ( )[ ]{ }⎩⎨⎧ η⋅τ=

β∈

Su,ru,rmax args rJu k

bias) i(eksploras sebaliknyasi)(eksploita qq jika , 0≤

(1)

Menurut Dorigo & Gambardella (1997, p55), cara menghitung nilai

peluang semut k pada kota r memilih untuk bergerak ke kota s:

( )( )[ ] ( )[ ]( )[ ] ( )[ ]

( )⎪⎪⎩

⎪⎪⎨

⎧

∑ η⋅τ

η⋅τ

=∈

β

β

0

u,ru,rs,rs,r

s,rprJu

kk

( )

lainnya

rJ 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.

29

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:

( ) ( ) ( )s,rs,r-1 s),(r τΔ⋅ρ+τ⋅ρ←τ (3)

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:

ρ = parameter (0 < ρ < 1)

30 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:

( ) ( ) ( )s,rs,r-1 s),(r τΔ⋅α+τ⋅α←τ (4)

Dimana:

( ) ( )⎩⎨⎧

=τΔ−

0Ls,r

1gb ( )

sebaliknya terbaikglobal perjalanan sr, 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.

31 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).

32 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.

• Untuk memodelkan aktivitas-aktivitas yang ada dalam siklus hidup.

33 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

• Component design

34


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


35

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

problem domain yang ditunjukkan atau dialami oleh satu atau lebih objek


• 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:

Generalization structure: sebuah kelas umum (super class) yang

menjelaskan properti umum ke sekelompok kelas khusus (subclasses)


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).

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:

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)


36

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:

Urutan: event dalam sekumpulan kejadian terjadi satu persatu.

Seleksi: tepat satu kejadian terjadi dari sekumpulan kejadian.

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).

37

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.

38


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).

39

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


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:

Fungsi update diaktivasi oleh sebuah event problem domain dan

menghasilkan sebuah perubahan dalam state model (Gambar 2.8)



Gambar 2.8 Fungsi Update

40

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

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

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).

41


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).

42

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

43

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


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


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

navigation diagram dapat dilihat pada Gambar 2.13.

44


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


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.

45


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).

46

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).

Sumber: Bennett, Mcrobb, & Farmer, 2010, p 354-358

47

• 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

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.

Model: tanggung jawab utama dari komponen adalah untuk memegang

objek yang mewakili problem domain (Mathiassen, et al., 2000, p201).

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).

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

48

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

client, yang dapat membagi sebuah database atau sumber daya lain. Tanggung

49

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


Component diagram dapat digunakan untuk memodelkan baik pandangan

abstrak, logis dari komponen-komponen dalam sistem atau subsistem atau

50

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


51

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

distribusi:

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).

52

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).

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

53

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).

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 InterfaceUser Interface

...

: Server

Function

Model(common)

System InterfaceUser Interface

More Clients


Gambar 2.19 Pola Terdesentralisasi Deployment Diagram

54

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

55

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).

56

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



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.

57


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


58


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).

59 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.

bab 2 landasan teori - library & knowledge...

Documents