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 faktafakta 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 orangorang, 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
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 orangorang 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 prosesproses 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: 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.
22
• 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.
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:
{
}
⎧arg max u∈J (r ) [τ(r, u )] ⋅ [η(r, u )]β , jika q ≤ q 0 (eksploitasi) k s=⎨ sebaliknya (eksplorasi bias) S ⎩
(1)
Menurut Dorigo & Gambardella (1997, p55), cara menghitung nilai peluang semut k pada kota r memilih untuk bergerak ke kota s:
⎧ [τ(r, s )]⋅ [η(r, s )]β ⎪⎪ β p k (r, s ) = ⎨ ∑ [τ(r, u )]⋅ [η(r, u )] ⎪ u∈J k (r ) ⎪⎩ 0
jika s ∈ J k (r ) lainnya
(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:
τ (r , s) ← (1 - ρ) ⋅ τ(r, s ) + ρ ⋅ Δτ(r, s )
(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:
τ (r , s) ← (1 - α) ⋅ τ(r, s ) + α ⋅ Δτ(r, s )
(4)
Dimana:
( )−1 ,
⎧L Δτ(r, s ) = ⎨ gb ⎩ 0
jika (r, s ) ∈ perjalanan global terbaik sebaliknya
(5)
Keterangan: α
= parameter kerusakan feromon (0 < α < 1)
Lgb = panjang dari perjalanan global terbaik
2.9
Object-Oriented
Menurut Bennett, Mcrobb, & Farmer (2006, p60), pendekatan objectoriented 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
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
(Mathiassen, et al., 2000, p51).
35
• 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).
36
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, pp7677). • 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).
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 objekobjek. 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
Sumber: Mathiassen, et al., 2000, p337 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 (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).
Sumber: Mathiassen, et al., 2000, p140 Gambar 2.8 Fungsi Update
40
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).
Sumber: Mathiassen, et al., 2000, p140 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).
Sumber: Mathiassen, et al., 2000, p140 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).
41
Sumber: Mathiassen, et al., 2000, p140 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 aktoraktor 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.
Sumber: Mathiassen, et al., 2000, p343 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 (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 navigation diagram dapat dilihat pada Gambar 2.13.
44
Sumber: Mathiassen, et al., 2000, p344 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.
45
Sumber: Mathiassen, et al., 2000, p174 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
Kemampuan fungsi untuk dapat bekerja secara benar dan lengkap sesuai Functional
dengan harapan dan kebutuhan user (Bennett, Mcrobb, & Farmer, 2010, p354-355). Penghematan sumber daya yang digunakan untuk menjalankan fungsi,
Efficient
meliputi penyimpanan disk, waktu pemrosesan, dan kapasitas jaringan guna untuk mengoptimalkan solusi yang dihasilkan (Bennett, Mcrobb, & Farmer, 2010, p355).
46
Biaya tetap dari hardware dan software yang digunakan dan juga biaya Economical
yang ditimbulkan dari menjalankan sistem (Bennett, Mcrobb, & Farmer, 2010, p356). Kehandalan sistem yang diukur dari ketidakmudahan hardware atau software gagal dan dapat dipercaya untuk memelihara integritas dari data
Reliable
dalam sistem (Bennett, Mcrobb, & Farmer, 2010, p356). Keamanan sistem yang harus dirancang untuk menghindari adanya serangan jahat dari orang luar dan terhadap orang dalam yang tidak
Secure
berhak (Bennett, Mcrobb, & Farmer, 2010, p356). Kemampuan sistem untuk dapat beradaptasi terhadap perubahan kebutuhan bisnis yang berbeda-beda dari waktu ke waktu (Bennett,
Flexible
Mcrobb, & Farmer, 2010, p356-357). Kemampuan penerapan pada program utilitas dibanding sistem informasi besar, mencakup juga penerapan pada hardware yang berbeda.
General
Sistem yang sama harus dapat digunakan pada client di industri lain (Bennett, Mcrobb, & Farmer, 2010, p357). Kemampuan pembangunan sistem dengan penulisan kode program berdasarkan sudut pandang programmer (Bennett, Mcrobb, & Farmer,
Buildable
2010, p357). Manageable
Maintainable
Usable
Kemampuan pengelolaan terhadap konsekuensi perubahan bagian dari sistem dalam pengembangan (Bennett, Mcrobb, & Farmer, 2010, p357). Kemampuan perancangan yang baik untuk mendukung pemeliharaan sistem yang semakin mudah (Bennett, Mcrobb, & Farmer, 2010, p357). Kemampuan sistem untuk dapat memuaskan kebutuhan user dan produktif (Bennett, Mcrobb, & Farmer, 2010, p358). Kemampuan sistem untuk dapat dipakai kembali, baik dalam berupa
Reusable
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 komponenkomponen 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. 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
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).
Sumber: 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
Sumber: Mathiassen, et al., 2000, p200 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
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.
Sumber: Mathiassen, et al., 2000, p339 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).
51
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).
Sumber: Mathiassen, et al., 2000, p216 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). 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).
Sumber: 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). 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 System Interface
User Interface
... Function
More Clients
Model (local)
: Server User Interface
System Interface
Function
Model (common)
Sumber: Mathiassen, et al., 2000, p219 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 nonalgoritmic (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 dapat dilihat pada Gambar 2.20.
Sumber: Mathiassen, et al., 2000, p340 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
Sumber: Mathiassen, et al., 2000, p341 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 objectoriented 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.
58
Sumber: Mathiassen, et al., 2000, p332 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.
