BAB II LANDASAN TEORI

2.1 Arsitektur Perangkat Lunak Arsitektur

perangkat

lunak

adalah

sekumpulan

pernyataan

yang

menggambarkan komponen perangkat lunak dan fungsi-fungsi yang ada pada komponen tersebut. Krafzig, dkk. (2004) menyatakan bahwa arsitektur perangkat lunak itu menggambarkan struktur teknis, batasan-batasan, ciri-ciri, serta antarmuka pada komponen-komponen tersebut. Arsitektur merupakan rancangan fisik sistem dan oleh karena itu membutuhkan rencana yang matang pada saat pembuatannya. Arsitektur perangkat lunak merupakan struktur sebuah sistem, yang meliputi elemen perangkat lunak, sifat (property) yang tampak dari elemen itu, serta relasi diantara elemen-elemen tersebut. Sifat yang tampak misalnya fungsi apa saja disediakan oleh elemen, bagaimana kinerjanya, bagaimana penanganan kesalahan, serta sumber daya apa saja yang dipergunakan. Menurut Erl (2009) ada tiga elemen yang saling berkaitan erat ketika berbicara tentang arsitektur perangkat lunak. Pertama adalah arsitektur teknologi, yaitu desain fisik dari suatu perangkat lunak. Kedua adalah infrastruktur teknologi, yaitu lingkungan pendukung yang termasuk di dalamnya perangkat keras dan perangkat lunak. Ketiga adalah perangkat lunak itu sendiri.

16

17 Istilah “arsitektur” berasal dari istilah yang digunakan pada bidang konstruksi bangunan. Sebuah bangunan memiliki desain fisik yang digambarkan dalam cetak biru arsitektur (architecture blueprint) atau disebut juga spesifikasi arsitektur. Suatu bangunan berada dalam lingkungan tertentu. Lingkungan ini bisa memberikan dukungan ataupun tidak terhadap bangunan tersebut. Sebagai contoh, bangunan perumahan yang dididukung oleh sarana transportasi, pembangkit tenaga listrik, dan sistem pembuangan limbah. Lingkungan pendukung inilah yang disebut infrastruktur. Agar bangunan dapat memanfaatkan infrastruktur tersebut, desain fisiknya harus mengintegrasikan berbagai infrasturktur tadi ke dalam arsitekturnya. Oleh karena itu, spesifikasi arsitektur sebuah bangunan haruslah memperhatikan infrastruktur di sekitarnya. Begitu juga dengan perangkat lunak, rancangan arsitekturnya harus memperhatikan infrastruktur di mana perangkat lunak ini akan ditempatkan seperti yang dinyatakan oleh Alvin Menurut Fielding (2000) sebuah arsitektur perangkat lunak merupakan abstraksi dari elemen run-time suatu sistem perangkat lunak selama beberapa tahap operasi. Suatu sistem dapat terdiri dari berbagai tingkat abstraksi dan banyak fase operasi yang masing-masing memiliki arsitektur perangkat lunak sendiri. 2.2 Konsep Arsitektur Berorientasi Layanan Seperti yang dinyatakab oleh Alvin (2010) apabila melihat kehidupan sehari-hari, aktivitas yang terjadi di dalam kota tempat kita tinggal dapat dijadikan

18

analogi untuk memahami apa itu layanan (service). Salah satu aktivitas yang dapat dikatakan berorientasi layanan (service oriented) adalah kegiatan bisnis. Setiap perusahaan telah berorientasi layanan, masing-masing perusahaan menawarkan layanan yang dapat digunakan oleh beragam konsumen. Secara kolektif, mereka membentuk suatu komunitas bisnis. Suatu komunitas bisnis tidak ditangani oleh perusahaan tunggal yang menyediakan semua layanan, melainkan ada berbagai perusahaan yang menawarkan layanannya masing-masing. Berbagai perusahaan yang tergabung dalam komunitas tersebut dapat tersebar di berbagai tempat.

Keterkaitan antara perusahaan yang satu dengan yang lainnya juga haruslah dibuat seminimal mungkin. Hal ini diperlukan agar apabila terdapat suatu perusahaan yang sangat berpotensi, perusahaan tersebut dapat berkembang dan maju terus tanpa terhalang oleh ketergantungan pada perusahaan lain. Perusahaan ada yang bersifat mandiri sehingga dapat mengembangkan kegiatan bisnisnya sendiri. Namun walaupun bersifat mandiri, berbagai perusahaan tersebut tetap harus mematuhi suatu aturan tertentu, misalnya penggunaan mata uang yang standar untuk urusan pertukaran barang dan jasa. Aturan ini adalah hal penting, terutama untuk konsumen. Dengan adanya standarisasi, konsumen tidak dipaksakan untuk mengikuti aturan baru yang dibuat oleh suatu perusahaan tertentu. Hal ini akan menjaga keharmonisan kegiatan bisnis yang ada. Berdasarkan analogi di atas, layanan dapat diartikan sebagai suatu unit solusi mandiri yang tidak seutuhnya terisolasi serta mengikuti suatu aturan atau standarisasi tertentu.

19

Layanan dapat pula diartikan sebagai sekumpulan kemampuan. Contohnya layanan pemesanan barang yang menawarkan kemampuan untuk membuat, memeriksa status, mengganti, serta membatalkan pesanan. Mabrouk (2008) mengutip definisi layanan dari “Web Services and Service-Oriented Architecture: The Savvy Manager’s Guide” sebagai fungsifungsi yang telah terdefinisi, bersifat independen, serta tidak bergantung pada keadaan layanan yang lainnya. Setiap perangkat lunak atau setiap sistem yang memanggil, menggunakan dan berinteraksi dengan suatu layanan dikatakan pengguna layanan (service consumer). Sebagai contoh terdapat suatu aplikasi yang berinteraksi dengan layanan, maka aplikasi tersebut dikatakan sebagai pengguna layanan. Ada juga layanan yang memanggil dan berinteraksi dengan layanan lain. Dalam hal ini, layanan tersebut juga berperan sebagai pengguna layanan.

2.2.1 Prinsip Berorientasi Layanan Erl (2005) memaparkan beberapa prinsip umum pada berorientasi layanan sebagai berikut: 1. Service reusability. Layanan dapat digunakan ulang, sehingga layanan harus didesain agar dapat mendukung penggunaan kembali. 2. Service contract. Agar service dapat berinteraksi, mereka harus memberikan kontrak yang berisi bentuk layanan dan informasi yang dipertukarkan. 3. Service loose coupling. Layanan tidak terhubung erat. Maksudnya layanan didesain agar dapat bekerja tanpa bergantung pada layanan tertentu.

20

4. Service abstraction. Layanan membungkus logika. Bagian yang tampak dari luar hanyalah kontrak layanan. Logika serta implementasi di balik itu tidak kelihatan dan tidak penting bagi peminta layanan. 5. Service composability. Beberapa layanan dapat disusun untuk membentuk layanan baru. 6. Service autonomy. Layanan bersifat mandiri. Pengembangan layanan dapat dilakukan terpisah. Layanan memiliki kendali penuh terhadap logika yang dimilikinya. 7. Service statelessness. Layanan tidak didesain untuk menyimpan informasi keadaan tertentu (state). 8. Service discoverability. Layanan harus dapat ditemukan. Deskripsi layanan harusdapat dicari dan dimengerti oleh peminta layanan.

Gambar 2.1 Model orientasi layanan (sumber : http://www.w3.org)

21

2.2.2 Implementasi Layanan Alvin (2010) yang mengutip dari tulisan Erl (2005) memaparkan beberapa teknologi yang dapat digunakan dalam implementasi layanan. Pada umumnya semua teknologi yang dapat digunakan untuk mengembangkan sistem terdistribusi dapat digunakan untuk mengembangkan layanan. Saat ini, layanan dapat diimplementasikan sebagai: 1. Komponen. 2. Web service. 3. REST service. Komponen adalah perangkat lunak yang didesain sebagai bagian dari sistem terdistribusi. Kemampuannya dipublikasi sebagai method, sehingga dapat dipanggil oleh aplikasi maupun perangkat lunak lain. Komponen biasanya terikat pada platform tertentu (platform-specific), contohnya adalah komponen yang dikembangkan dengan teknologi .NET ataupun Java. Web service adalah bentuk implementasi layanan yang menyediakan kontrak terpisah yang terdiri dari Web Service Description Language (WSDL) dan satu atau lebih definisi skema XML. Web service mempublikasi kemampuannya dalam bentuk operasi, membentuk antarmuka teknis yang tidak tergantung framework maupun platform tertentu. Web service terdiri dari service contract, unit layanan dan unit pemrosesan pesan. Representational State Transfer (REST) berarti membuat

sistem

terdistribusi berdasarkan resources. REST services adalah perangkat lunak yang didesain dengan penekanan pada kesederhanaan, skalabilitas, serta kegunaan.

22

2.2.3 Komponen Arsitektur Berorientasi Layanan Erl (2005) memaparkan komponen SOA sebagai berikut: 1. Pesan (messages) yaitu data yang dibutuhkan untuk menyelesaikan suatu unit kerja. 2. Operasi (operations) yaitu logika yang dibutuhkan untuk menyelesaikan suatu unit kerja. 3. Layanan (services) yaitu sekumpulan operasi yang dapat melakukan tugas tertentu. 4. Proses (processes) yaitu aturan bisnis yang menentukan operasi layanan apa yang digunakan untuk menyelesaikan suatu tugas tertentu. Sedangkan Fielding (2000) dalam laporan penelitian tesisnya menyatakan bahwa sebuah arsitektur perangkat lunak didefinisikan oleh konfigurasi dari elemen arsitektur tersebut yang terdiri atas komponen, penghubung, dan data yang kemudian dibatasi dalam hubungan antar elemen tersebut untuk mencapai kesatuan properti arsitektur yang diinginkan. 2.3 API (Application Programming Interface) API adalah kumpulan fungsi-fungsi dan protokol yang membantu programmer untuk membangun sebuah software. Di masa lalu, API pada umumnya dihubungkan dengan fungsi-fungsi pada sistem operasi. Namun dua atau tiga tahun ini, Web API menjadi populer sehingga mulai menggeserkan makna API yang pada mulanya khusus membicarakan fungsi-fungsi yang berhubungan dengan sistem operasi dan komputer desktop, menjadi kata pengganti untuk Web Service yang dulunya cukup populer.

23

Keberadaan Web API atau Web Service memungkinkan para developer baik web, desktop maupun mobile

untuk membangun aplikasi dengan

menggunakan data dari berbagai sumber data online. Belakangan, cara ini disebut mashup. Perusahaan-perusahaan ternama mulai banyak yang menyediakan APInya dalam berbagai kategori seperti social network, jual beli hingga musik.

Gambar 2.2 Kategori web API yang popular (sumber : http://web.durianapp.com ) 2.3.1 Protokol API Saat ini, protokol yang paling banyak digunakan oleh Web API adalah REST (Representational State Transfer). Contoh perusahaan yang menggunakan REST adalah Twitter, Facebook dan Google. REST mungkin dipilih karena mudah dipakai oleh developer. Di masa lalu, SOAP adalah protokol yang paling populer, tetapi belakangan turun popularitasnya terutama karena sulitnya implementasi. Penulis sendiri sempat menggunakan SOAP, tetapi banyak dibantu oleh library dan tools dalam implementasinya.

24

Gambar 2.3 Protokol web API yang banyak digunakan (sumber : http://web.durianapp.com )

2.3.2 Format Data API Sejauh ini format data yang paling populer memang XML, namun demikian JSON jelas sekali tumbuh popularitas dan penggunaannya. Banyak developer lebih suka menggunakan JSON, karena berbagai alasan, diantaranya: 1. Data bisa diakses tanpa parsing yang rumit. 2. JSON parser tersedia hampir disemua bahasa pemrograman. 3. JSON parser cepat, kecil, ringan dan tidak rumit penggunaannya. 4. Output JSON lebih kecil karena tidak perlu mencantumkan atribut dan namespace, selain itu tag yang digunakan hanya berupa kurung kurawal.

Gambar 2.4 Format data web API yang banyak digunakan (sumber : http://web.durianapp.com )

25

2.3.3 Keuntungan membangun Web API 1. Membantu membangun loyalitas terhadap brand, perhatikan bagaimana kita hampir selalu menggunakan akun Facebook ketika memainkan game online saat ini. 2. Meningkatkan ketertarikan kepada produk atau layanan perusahaan pemilik API. 3. Meningkatkan traffic. 4. Memberikan alat yang berguna bagi konsumer, terutama pengguna API (web, desktop, atau mobile developer). Dengan membangun Web API, kita bisa menarik developer lain untuk membuat aplikasi yang menggunakan fasilitas kita yang kadang kita tidak terpikirkan untuk menggunakannya semacam itu. 5. Bisa digunakan sebagai alat komunikasi bisnis antar perusahaan. Contoh penggunaannya misalnya Amazon dan PayPal. 2.4 Simple Object Access Protocol (SOAP) SOAP merupakan suatu protokol berbasis XML yang digunakan untuk kebutuhan

pertukaran

informasi

dalam

suatu

sistem

terdistribusi

dan

terdesentralisasi. SOAP merupakan protokol yang bersifat independen terhadap platform, model pemrograman, dan transport protocol yang digunakan dalam proses pertukaran pesan SOAP. Pesan SOAP dapat dikirimkan melalui HTTP, FTP atau SMTP. Pesan SOAP berbentuk sekumpulan skema XML yang mendefinisikan format untuk mentransmisikan pesan XML melalui jaringan, termasuk tipe data dan cara menstrukturkan pesan secara tepat sehingga dapat mudah dipahami oleh server

26

atau end-point lainnya. Dan berikut ini adalah contoh dari skema atau struktur pesan dari SOAP. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soapencoding"> <SOAP-ENV:Header> ... ... <SOAP-ENV:Body> ... ... <SOAP-ENV:Fault> ... ...

Pesan SOAP terdiri dari 4 bagian, yaitu : 1. SOAP Envelope, suatu selubung yang mendefinisikan apa yang ada dalam message dan bagaimana pesan harus diproses. SOAP Envelope juga mendefinisikan awal dan akhir dari pesan. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soapencoding"> ... Message information goes here ...

2. SOAP Header, berisi informasi yang berkaitan dengan keamanan serta routing. Atribut yang terdapat pada SOAP Header diantaranya adalah Actor Attibute dan MustUnderstand Attribute.

27

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soapencoding"> <SOAP-ENV:Header> 5 ...

3. SOAP Body, berisi data yang berhubungan dengan aplikasi tertentu yang sedang dipertukarkan. <SOAP-ENV:Envelope ........ <SOAP-ENV:Body> <m:GetDescription xmlns:m="http://www.tp.com/Description"> <m:Item>Computers

Skema XML di atas merupakan contoh SOAP Body yang meminta deskripsi, dilihat dari method yang dipanggil yaitu GetDescription dari suatu item komputer yang dilihat dari parameter item yang dimasukan. m:GetDescription dan elemen m:Item merupakan elemen spesifikasi aplikasi, bukan bagian dari standar SOAP. Dan contoh skema XML dari respon yang diterima adalah seperti berikut ini : <SOAP-ENV:Envelope ........ <SOAP-ENV:Body> <m:GetDescriptionResponse xmlns:m="http://www.tp.com/Description"> <m:Description>This is Description

28

4. SOAP Fault, berisi informasi mengenai kesalahan yang terjadi saat pesan SOAP diproses. Berikut ini adalah contoh kesalahan dimana klien meminta atau memanggil suatu method dengan nama ValidateCreditCard, namun service tidak mengetahui method tersebut atau tidak terdapat method tersebut. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <SOAP-ENV:Fault> SOAPENV:Client Failed to locate method (ValidateCreditCard) in class (examplesCreditCard) at /usr/local/ActivePerl-5.6/lib/ site_perl/5.6.0/SOAP/Lite.pm line 1555.

Gambar 2.5 Struktur pesan dari SOAP

29

SOAP sendiri adalah pengganti dari XML-RPC (Remote Procedure Calling), namun dengan karakteristik sendiri, tiga karakteristik utama dari SOAP antara lain: 1.

Extensibility, dapat menggunakan beberapa extension tambahan lain diantaranya antara lain security dan WebService-Routing.

2.

Neutrality, SOAP dapat digunakan diberbagai protokol transport seperti HTTP, SMTP atau TCP.

3.

Independence, SOAP tidak memiliki ketergantungan terhadap bahasa pemrograman tertentu. SOAP pertama kali didesain oleh Dave Winer, Don Box, Bob Atkinso dan

Mohsen Al-Ghosein pada tahun 1998 dalam sebuah proyek Microsoft. SOAP awalnya lebih menyerupai Internet Inter-ORB Protocol (IIOP), sebuah protokol yang merupakan bagian dari Common Object Request Broker Architecture (CORBA). 2.5 REST Terminologi REST dikemukakan oleh Roy Fielding yang merupakan salah satu penulis spesifikasi HTTP dalam disertasi Ph.D. nya untuk menggambarkan sebuah style arsitektur dari sistem jaringan. Berikut penjelasan Roy Fielding mengenai Representational State Transfer : REST is a hybrid style derived from several of the network-based architectural styles and combined with additional constraints that define a uniform connector interface (Fielding, 2010). Disertasi tersebut mengemukakan beberapa prinsip yang umum terdapat pada arsitektur jaringan berdasarkan pengujian terhadap struktur jaringan dan

30

protokol HTTP. REST sering dirujuk sebagai sebuah gaya arsitektural daripada sebagai sebuah arsitektur. Daripada mendefinisikan sebuah spesifikasi arsitektur terbaik, REST lebih mendefinisikan prinsip-prinsip yang dengannya arsitektur dibuat dan dievaluasi dengan cara meletakkan batasan-batasan pada arsitektur jaringan. REST bukanlah sebuah standar seperti SOAP. Saat ini tidak ada spesifikasi standar khusus REST di W3C. 2.5.1 Karakteristik RESTful RESTful Web Services memiliki karakteristik sebagai berikut: 1. Client-Server Interaksi dengan model pengambilan, maksudnya adalah mengkonsumsi komponen atau berarti mengambil representation. 2. Stateless Setiap request dari client ke server harus mengandung semua informasi yang diperlukan server untuk memahami maksud dari request, dan request tidak dapat memanfaatkan server untuk mengingat konteks apapun. 3. Cache Untuk meningkatkan efisiensi jaringan, respon harus dapat melabeli data sebagai cache atau non-cache. 4. Uniform interface Semua resource diakses dengan interface generik (HTTP GET, POST, PUT, DELETE). 5. Resource yang memiliki nama Sistem terdiri atas resource yang mempunyai nama berdasarkan URL-nya.

31

6. Representation resource yang saling terkoneksi Representasi dari resource saling terhubung menggunakan URL, oleh karenanya client dapat untuk berpindah dari satu state ke state lainnya. 7. Komponen berlayer Perantara seperti proxy server, cache server, gateway, dan sebagainya dapat dimasukkan sebagai komponen antara client dan resource untuk mendukung performa, keamanan, dan lainnya. 2.5.2 Konsep RESTful Secara sederhana untuk memahami konsep REST ini kita dapat menganalogikannya seperti ini, kita anggap web terdiri atas kumpulan resources. Domain-domain di internet ini memberikan resource baik kepada browser atau aplikasi yang diprogram untuk mengakses resource tersebut. Sebuah resource merupakan sesuatu (dokumen, file atau apapun) yang dinginkan oleh pengakses (client). Browser menginginkan resource tersebut disajikan dalam dokumen HTML, aplikasi lain mengingikan dalam format XML agar bisa diolah lebih lanjut. Misal, website UIN Sunan Gunung Djati memberikan resource informasi mahasiswa dengan NIM (Nomor Induk Mahasiswa) 20102246. Client dapat mengakses resource tersebut melalui URL: http://www.uinsgd.ac.id/mahasiswa/20102246 Client (browser) mengaksesnya dengan menggunakan HTTP_GET request dan kemudian sebuah representasi dari resource tersebut diberikan (misal 20102246.html, karena browser meminta dokumen html).

32

Method-method yang cukup penting dan paling sering digunakan dalam HTTP adalah POST, GET, PUT dan DELETE. Method ini sering dianalogikan sebagai operasi CREATE, READ, UPDATE dan DELETE (CRUD) dalam teknologi database. Tapi dalam HTTP operasi POST bisa meliputi Create, Update dan Delete. Operasi GET sebagai READ, operasi PUT bisa meliputi CREATE dan UPDATE, dan operasi DELETE sebagai DELETE. Tabel 2.1 Method pada HTTP request serta implementasinya pada REST No

HTTP Method

1

GET

2

3

4

5

PUT

Aksi

Analogi Perintah

Mengambil atau memperoleh resources

1. Digunakan untuk memperoleh resource data

Ambil itu!

Menyimpan atau menambahkan resources baru

1. Digunakan untuk menyimpan atau menambahkan resource baru

Simpan disitu!

Menyimpan atau menambahkan resources baru

2. Method ini dapat digantikan oleh method POST, karena method ini tidak dapat digunakan pada beberapa browser

Simpan disitu!

Merubah resources yang sudah ada

1. Digunakan untuk merubah resource yang sudah ada 2. Method ini dapat digunakan untuk menggantikan methop PUT, karena method ini lebih umum digunakan.

Ubah itu!

1. Digunakan untuk menghapus resource yang sudah ada

Hilangkan itu!

PUT

POST

DELETE

Deskripsi

Menghapus resources yang sudah ada

33

2.5.3 Prinsip RESTful Ada beberapa prinsip yang perlu dipegang agar sebuah desain Web Service itu RESTful, yaitu: 1. Kunci untuk membuat web services dalam sebuah jaringan REST (seperti Web) adalah mengidentifikasi semua bentuk konsep yang ingin kita ekspos sebagai service. 2. Membuat

sebuah

URL

untuk

setiap

resource.

Resource

harus

berbentuk noun (kata benda), bukan verb (kata kerja). Dan inilah yang membedakan antara REST dan RPC-style. Sebagai contoh: Untuk mendapatkan resource buku tertentu jangan gunakan URL seperti : http://www.tokobuku-gedex.com/books/getBook?id=0101 Perhatikan adanya verb (getBook) pada URL di atas. Gunakanlah noun, seperti: http://www.tokobuku-gedex.com/books/0101 3. Mengkategorikan resource menurut permission untuk klien, apakah membaca saja, atau dapat mengedit dan menghapus. Maksudnya apakah client hanya dapat mendapatkan representation dari resource, atau bisa memodifikasi resource. Untuk mendapatkan representation resource, client menggunakan operasi HTTP GET. Untuk membuat suatu

resource client menggunakan

operasi HTTP PUT, HTTP POST untuk mengedit suatu resource dan HTTP DELETE untuk menghapus resource.

34

4. Semua resource yang dapat diakses melalui HTTP GET tidak mempunyai efek terhadap resource. Resource hanya memberikan representasi dari resource, tidak ada modifikasi terhadap resource itu sendiri. 5. Tidak ada representasi yang berisi semua informasi. Gunakan hyperlink atau cara dalam setiap representasi resource agar client dapat memperoleh informasi lebih detail atau informasi lainnya yang berkaitan. 6. Sistem didesain untuk memberikan data secara bertahap. Jangan berikan semuanya dalam sebuah dokumen respon. Tapi sediakan hyperlink atau cara untuk memperoleh detail lebih lanjut. 7. Beri penjelasan terhadap format dari data respon menggunakan skema (DTD, W3C schema, RelaxNG atau Schematron). 8. Beri penjelasan bagaimana eksekusi services yang dibuat dengan menggunakan file WSDL/WADL atau bisa dengan dokumen HTML sederhana.

Gambar 2.6 Model orientasi resource (sumber : http://www.w3.org)

35

2.5.4 Pengamanan Web Service RESTful Dalam spesifikasi HTTP dijelaskan bahwa dalam transaksi HTTP ada sebuah metode untuk autentikasi yang disebut basic access authentication dimana client dapat menyediakan credential (username dan password) saat membuat request. Sebelum mengirim request, username dan password dienkripsi dengan menggunakan

enkripsi

base-64.

Contoh,

jika

username=gedex

dan

password=asdf maka akan digabungkan menjadi gedex:asdf dan jika diencode ke base-64 menjadi Z2VkZXg6YXNkZg==. Ini memang tidak meningkatkan sisi keamanan, tetapi agar tidak terbaca jelas saja oleh orang lain. Jika ingin meningkatkan keamanan koneksi HTTP, ada metode yang tersedia, yaitu: HTTPS skema dan HTTP 1.1 Upgrade header. Contoh proses basic access authentication: 1. Client merequest sebuah resource yang membutuhkan autentikasi, tapi client tidak menyertakan username dan password. Umumnya ini karena client langsung mengakses alamat atau mengikuti link dari sebuah resource. Berikut cara client request tanpa menyertakan credential: GET /books/underground HTTP/1.0 Host: tokobuku-gedex.com

2. Server merespon dengan kode respon 401 dan menyediakan authentication realm. HTTP/1.0 401 UNAUTHORIZED Server: Apache/2.2.8 (Win32) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_autoindex_color PHP/5.2.5 WWW-Authenticate: Basic realm="Toko Buku Gedex Site"

36

Content-Type: text/html Content-Length: 311 Date: Mon, 21 Apr 2008 06:02:12 GMT <TITLE>Error <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">

401 Unauthorised.

3. Pada saat itu client akan menghadapi authentication realm, umumnya sebuah informasi dari sistem yang sedang diakses dan akan meminta username dan password. User dapat membatalkan proses autentifikasi. 4. Jika client memberikan username dan password, request dikirim kembali dengan menyertakan authentication header. GET /books/underground HTTP/1.0 Host: tokobuku-gedex.com Authorization: Basic Z2VkZXg6YXNkZg==

5. Jika server menerima autentifikasi maka halaman yang direquest akan diberikan (umumnya kode status 200 akan diberikan), tapi jika username atau password

salah,

server

dapat

memberikan

kode

status

401

dan

menyediakan authentifikasi realm lagi. HTTP/1.0 200 OK Server: Apache/2.2.8 (Win32) DAV/2 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_autoindex_color PHP/5.2.5 Date: Mon, 21 Apr 2008 06:02:12 GMT Content-Type: text/html Content-Length: 10512

37

2.5.5 Perbedaan Web Service RESTful dan RPC-style Sebenarnya perbedaan Web Service yang RESTful dan RPC-style cukup jelas, yaitu seperti yang di jelaskan pada tabel 2.2: Tabel 2.2 Perbandingan web service dengan model REST dan model RPC No

REST style

RPC style

1

REST mendefinisikan “resources”.

2

Akses didefinisikan dengan cara bagaimana mendapatkan resource (HTTP GET), menyimpan / membuat resource (HTTP PUT), memodifikasi (HTTP POST) dan menghapus resource (HTTP DELETE).

Akses didefinisikan dengan cara bagaimana mengeksekusi methods di server dengan menggunakan standar tertentu (XML-RPC atau SOAP) sebagai layer messaging.

3

REST memiliki noun berupa resources.

RPC style memiliki verb berupa methods.

4

Dalam desain RESTful terdapat aturan yang mengikat aspek resources, yaitu interface (verbs dan jenis konten) resources. Dalam RESTful, verbs terikat pada metode request HTTP (GET, POST, PUT, DELETE). Jenis konten merupakan representasi dari resource (HTML, XML, file, dan lainnya).

Aplikasi berbasis RPC-style menyediakan objek-objek dimana setiap objek memiliki method yang dapat dieksekusi (invoke). Untuk dapat berkomunikasi dengan aplikasi RPC-style, client harus mengetahui terlebih dahulu objek-objek yang tersedia, methods yang tersedia untuk mengakses objek dan tipe objek.

Misal,

Toko

buku

RPC-style mendefinisikan “methods“.

gedex

membuat

web

services

dengan

menggunakan RPC-style. Developer-nya menggunakan XML-RPC sebagai layer messaging, yang

bisa diakses melalui URL http://www.tokobuku-

gedex.com/xml-rpc/. Methods yang disediakan adalah: 1. getBook() 2. addBook() 3. updateBook()

38 4. removeBook() 5. listBooks() 6. findBook() 7. getPenulis() 8. addPenulis() 9. updatePenulis() 10. removePenulis() 11. listPenulis() 12. findPenulis() Developer kemudian mendokumentasikan methods, parameter serta tipe data yang digunakan. Untuk mengakses aplikasi ini, client dapat menulis code (misal dengan IXR library) yang mungkin seperti ini: $client = new IXR_Client('http://tokobuku-gedex.com/xml-rpc/'); if ( !$client->query('gedex.getBook', 0101) ) { die($client->getErrorMessage()); } else { $result = $client->getResponse(); }

Dengan REST, sistem ditekankan pada koleksi resources atau nouns, misal dengan REST resource toko buku gedex didefinisikan menjadi: http://www.tokobuku-gedex.com/books http://www.tokobuku-gedex.com/books/{book} http://www.tokobuku-gedex.com/penulis http://www.tokobuku-gedex.com/penulis/{nama_penulis} Seperti telah dijelaskan di atas, bahwa setiap resource memiliki identitas noun-nya. Client dapat memulai sebuah resource dari sebuah kumpulan buku, dan kemudian berpindah ke spesifik buku tertentu, lalu kemudian melihat

39

contoh chapter yang disediakan. Client mendapatkan resource dengan standar HTTP REQUEST GET untuk mengunduh representasi resource, POST untuk mengedit resource aslinya atau DELETE untuk menghapus resource. PUT umumnya digunakan untuk operasi pembuatan atau penambahan data ke suatu resource. Perhatikan bagaimana setiap objek (sebuah resource) memiliki URL tersendiri dan dapat dengan mudah dicache, dicopy dan dibookmark. 2.5.6 Perbandingan REST dan SOAP REST API dan SOAP API merupakan dua jenis implementasi aplikasi berorientasi layanan yang saat ini paling banyak digunakan karena masing-masing implementasi memiliki kelebihan dan kekurangan serta karakteristik, pada lampiran B laporan skripsi ini dijelaskan beberapa perbedaan karakteristik dari kedua model web service tersebut.

Gambar 2.7 Analogi proses request pada SOAP dan REST

Dari penjelasan di atas dapat dikatakan bahwa SOAP tidak semudah REST dalam pengimplementasiannya, SOAP membutuhkan usaha implementasi yang lebih besar dan pengetahuan di sisi klien, sedangkan web service berbasis REST API membutuhkan implementasi yang lebih besar dan pengetahuan di sisi server.

40

Gambar 2.8 Analogi perbandingan proses pada SOAP API dan REST API 2.6

USDP Unified Software Development Process (USDP) merupakan salah satu

metode pengembangan sistem atau perangkat lunak yang diciptakan oleh mereka yang mengembangkan dan menciptakan diagram-diagram UML, yaitu Graddy Booch, Ivar Jacobson, dan DR. James Rumbaugh sebagai panduan umum yang dapat digunakan oleh para pengembang perangkat lunak dalam melakukan analisis dan perancangan suatu aplikasi berorientasi objek dengan menggunakan tool UML. Kemudian Rational Corp membuat suatu metode berdasarkan USDP yang berbasis pemodelan yang disebut Rational Unified Process (RUP). Beberapa literatur mengatakan bahwa RUP sama saja dengan USDP hanya perbedaan panggilan saja, dan ada pula literatur yang mengatakan bahwa USDP merupakan dasar dari RUP hanya saja RUP berbasis pemodelan dan merupakan

41

nama produk dari metode USDP yang diciptakan oleh Rational Corp dan kini telah dimiliki oleh IBM. Namun yang pasti metode USDP merupakan metode awal pengembangan perangkat lunak berorientasi objek dengan menggunakan tool UML yang dibangun oleh para pencipta diagram-diagram UML. Ciri utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus pengembangan perangkat lunak. 2.6.1 Fase USDP Dalam USDP terdapat 4 fase, berikut adalah penjelasan dari tiap-tiap fase tersebut: 1. Inception Dalam fase ini pengembang perangkat lunak dituntut untuk bisa melakukan interaksi dengan client sebagai langkah awal untuk pengidentifikasian kebutuhan-kebutuhan sistem yang hendak dibuat. Langkah ini cukup penting agar para pengembang perangkat lunak punya kesamaan persepsi antara sistem yang akan dibuat dengan kebutuhan pengguna. Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada fase ini: a. Business Modeling and Requirements : menganalisa, merumuskan, dan menentukan perencanaan, cakupan, serta kebutuhan utama bisnis. b. Analysis: mengadakan studi kelayakan terhadap proyek yang akan dijalani. c. Design: mendesain konsep atau prototipe teknisnya. d. Implementation : membuat prototipe konsepnya. e. Test : tahap ini tidak terlalu dipentingkan atau belum diperlukan pada fase ini.

42

Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah: a. Ruang lingkup sistem sudah terdefinisikan. b. Kebutuhan sistem sudah bisa diidentifikasi dan telah mendapat persetujuan dari stakeholder. c. Arsitektur sistem sudah jelas, walaupun mungkin masih dalam tahap perencanaan awal dan masih bisa berubah di fase selanjutnya. d. Sudah melakukan analisa terhadap segala kemungkinan resiko yang mungkin akan terjadi selama pengerjaan proyek. e. Sudah mempunyai perencanaan bisnis yang matang untuk memperlancar jalannya proyek kelak. f. Studi kelayakan proyek sudah jelas dan pasti. g. Stakeholder sudah menyetujui kerangka kerja proyek tersebut. h. Dokumen atau produk yang dihasilkan dalam fase ini adalah System Charter atau Vision Document. 2. Elaboration Fase ini digunakan untuk mematangkan konsep-konsep yang sudah terbentuk di fase inception. Fase ini belum masuk ke tahap pembuatan perangkat lunak secara langsung, tetapi lebih kepada pemantapan konsep dan peninjauan kembali terhadap rencara-rencana yang sudah ditentukan sebelumnya. Dengan demikian diharapkan proyek yang akan berjalan, resikonya dapat ditekan seminimal mungkin.

43

Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada fase ini: a. Business Modeling and Requirements : memperbaiki cakupan dan kebutuhan sistem. b. Analysis : menganalisa kebutuhan sistem dan cara membangun sistem tersebut. c. Design : membuat arsitektur yang stabil. d. Implementation : membuat garis besar arsitektur. e. Test : mengetes garis besar arsitektur yang sudah dibuat. Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah: a. Membuat garis besar dari arsitektur proyek yang lebih baik dan handal. b. Memperbaiki analisa atau meminimalkan segala kemungkinan resiko yang ada. c. Mendefinisikan atribut kualitas, misalnya atribut atau parameter apa saja yang mempengaruhi keberhasilan dan kegagalan proyek. d. Merangkum use case menjadi suatu kebutuhan fungsional. e. Membuat perencanaan detail untuk fase selanjutnya. f. Memformulasikan perencanaan kebutuhan peralatan, waktu, staf, biaya, dan sumber daya lainnya. g. Memperoleh persetujuan dari stakeholder untuk melanjutkan ke fase berikutnya. h. Dokumen atau produk yang dihasilkan dalam fase ini adalah UML Model, Software Requirements Specification (SRS), System/Subsystem Specification (SSS), System/Subsystem Design Description (SSDD), Interface Control Description (ICD), dan Software Architecture Description (SAD).

44

3. Construction Fase ini merupakan fase coding, dimana pengembang perangkat lunak sudah melakukan pembuatan sistem secara nyata. Pembuatan sistem tersebut tentunya harus mengacu kepada hal-hal atau parameter-parameter yang sudah ditentukan dan digariskan dari fase-fase sebelumnya. Berikut adalah tahap-tahap iterasi kerja yang dilakukan pada fase ini: a. Business Modeling and Requirements : menyelidiki lebih lanjut kebutuhankebutuhan proyek yang mungkin belum terpikirkan sebelumnya. b. Analysis : menyelesaikan analisis model. c. Design : menyelesaikan desain model. d. Implementation : membangun Initial Operational Capability. e. Test : melakukan pengetesan terhadap Initial Operational Capability yang telah dibuat. Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah: a. Menyelesaikan identifikasi, deskripsi, dan realisasi dari use case. b. Menjaga integritas dari arsitektur sistem. c. Merevisi analisa resiko yang ada. d. Menyelesaikan beberapa kebutuhan yang terlewatkan sebelumnya. e. Menyelesaikan analisis dan desain model. f. Membangun dan melakukan pengetesan terhadap

Initial Operational

Capability yang mengarah kepada pembentukan produk versi beta. g. Dokumen atau produk yang dihasilkan dalam fase ini adalah Software Development Plan (SDP).

45

4. Transition Tahap ini dilakukan untuk mematangkan produk akhir yang sudah jadi. Pematangan ini perlu dilakukan untuk menganalisa apakah perangkat lunak yang sudah dibuat sesuai dengan kebutuhan pengguna, atau mungkin terdapat bug yang perlu diperbaiki, dan lain-lain. Berikut adalah tahap-tahap iterasi kerja yang dilakukan pada fase ini: a. Business Modeling and Requirements : tahapan ini seharusnya sudah tidak dipakai lagi karena fase ini merupakan fase akhir, tetapi tetap dapat dilakukan jika memang masih dibutuhkan. b. Analysis : tahapan ini seharusnya sudah terselesaikan di fase sebelumnya sehingga tidak dipakai lagi, tetapi tidak menutup kemungkinan tetap dapat dilakukan jika memang masih dibutuhkan. c. Design : melakukan modifikasi terhadap desain sistem jika ditemukan masalah selama beta testing. d. Implementation :

melakukan penyesuaian pengaturan perangkat lunak agar

bisa dipakai di sisi pengguna, misalnya install dan setting database di server pengguna dan penyesuaian konfigurasi IP serta melakukan perbaikan coding yang ditemukan selama beta testing. e. Test : melakukan proses beta testing dan melakukan testing akhir di sisi pengguna. Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah: a. Memperbaiki cacat yang ditemukan pada perangkat lunak. b. Mempersiapkan perangkat lunak agar bisa dipakai oleh pengguna.

46

c. Memodifikasi perangkat lunak jika ditemukan masalah yang terlewatkan pada versi beta. d. Membuat buku manual dan dokumentasi lainnya. e. Menyediakan konsultasi dan pelatihan kepada pengguna atas pemanfaatan perangkat lunak tersebut. f. Melakukan peninjauan atau analisa setelah proyek selesai (post project review). g. Jika semua aspek sudah diselesaikan, maka dilakukan penyerahan perangkat lunak

tersebut

secara

resmi

kepada

pengguna

untuk

kemudian

diimplementasikan. h. Dokumen atau produk yang dihasilkan dalam fase ini adalah Software Test Description (STD) dan Software Test Report (STR) [26].

Gambar 2.9 Fase-fase pada Unified Process

47

2.7

UML UML (Unified Modelling Language) adalah suatu bahasa yang digunakan

untuk menentukan, memvisualisasikan, membangun, dan mendokumentasikan suatu sistem informasi. UML dikembangkan sebagai suatu alat untuk analisis dan desain berorientasi objek oleh Grady Booch, Jim Rumbaugh, dan Ivar Jacobson. Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga orang tokoh yang boleh dikatakan metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 dirilis draft pertama dari UML (versi 0.8). Kemudian, sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group (OMG – http://www.omg.org). Tabel 2.3 Konsepsi dasar Unified Modeling Language No 1

2

Major Area Structural

Dynamic

View

Diagrams

Main Concepts

Static View

Class Diagram

Class, association, generalization, dependency, realization, interface

Use Case View

Use Case Diagram

Use case, actor, association, extend, include, use case generalization

Implementation Component View Diagram

Component, interface, dependency, realization

Deployment View

Deployment Diagram

Node, component, dependency, location

State Machine View

Statechart Diagram

State, event, transition, action

48

Tabel 2.3 Konsepsi dasar Unified Modeling Language (lanjutan) No

Major Area

View

Diagrams

Main Concepts

Activity View Activity Diagram

State, activity, completion transition, fork, join.

Interaction View

Interaction, object, message, activation

Sequence Diagram

Collaboration Collaboration, Diagram interaction, collaboration, role, message 3

Model Management

Model Management View

Class Diagram Package, subsystem, model

4

Extensibil ity

All

All

Constraint, stereotype, tagged values

UML pada saat ini menyediakan berbagai macam diagram untuk memodelkan aplikasi berorientasi objek, yaitu: 1. Use Case Diagram untuk memodelkan proses bisnis. 2. Conceptual Diagram untuk memodelkan konsep-konsep yang ada di dalam aplikasi. 3. Sequence Diagram untuk memodelkan pengiriman pesan (message) antar objects pada sistem. 4. Collaboration Diagram untuk memodelkan interaksi antar objects. 5. Statechart Diagram untuk memodelkan perilaku objects di dalam sistem. 6. Activity Diagram untuk memodelkan perilaku use cases dan objects di dalam system. 7. Class Diagram untuk memodelkan struktur kelas. 8. Object Diagram untuk memodelkan struktur object.

49

9. Component Diagram untuk memodelkan komponen object. 10. Deployment Diagram untuk memodelkan distribusi aplikasi. (Sumber : http://id.wikipedia.org/wiki/UML )

Gambar 2.10 Diagram Unified Modeling Language (Munawar, 2005) 2.7.1 Use Case Diagram Use case diagram, biasanya menggambarkan apa yang dilakukan aktor terhadap sistem. Use case diagram

menggambarkan fungsionalitas yang

diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, membuat sebuah daftar belanja, dan sebagainya. Seorang atau sebuah aktor adalah sebuah entitas manusia atau mesin atau sistem lain yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.

50

Jadi dalam diagram ini akan terlihat apa saja interaksi yang terdapat dalam sistem antara aktor-aktor yang terlibat dengan sistem itu sendiri, sehingga nantinya dapat terlihat kebutuhan apa saja yang ada.

Gambar 2.11 Contoh use case diagram

2.7.2 Class Diagram Class Diagram, biasanya nantinya akan menjadi gambaran database dari sistem. Terdiri dari nama class, attribute, dan operasi atau metode yang dapat dilakukan terhadap class tersebut. Class diagram menggambarkan struktur dan deskripsi class, package serta objek beserta hubungannya satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi

51

objek. Class menggambarkan keadaan (atribut atau properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda atau fungsi). Class memiliki tiga area pokok : 1. Nama dan stereotype 2. Atribut 3. Metoda Atribut dan metoda dapat memiliki salah satu sifat berikut : 1. Private, tidak dapat dipanggil dari luar class yang bersangkutan 2. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anakanak yang mewarisinya 3. Public, dapat dipanggil oleh siapa saja

Gambar 2.12 Contoh class

52

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time. Sesuai dengan perkembangan class, model class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.

Gambar 2.13 Contoh package yang terdiri atas class-class Antar class juga dapat memiliki hubungan antar satu sama lainnya, berikut ini hubungan yang dapat terjadi antar class : 1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. 2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas...”). 3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan dapat pula menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.

53

4. Hubungan dinamis, yaitu rangkaian pesan (message) yang dilewatkan dari satu class kepada class lainnya. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

Gambar 2.14 Contoh class diagram 2.7.3 Statechart Diagram Statechart diagram menggambarkan transisi dan perubahan keadaan suatu objek dari satu state ke state lainnya pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya sebuah

statechart diagram adalah menggambarkan

class tertentu, dan satu class dapat memiliki lebih dari satu statechart diagram. Dalam UML (Unified Modelling Language), state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis

54

miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.

Gambar 2.15 Contoh statechart diagram 2.7.4 Activity Diagram Activity Diagram, menggambarkan detil aktivitas yang dilakukan oleh masing masing aktor yang terlibat dalam suatu sistem. Activity diagram menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing dari alir berawal, decision yang mungkin terjadi, dan bagaimana mereka akan berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram adalah merupakan suatu state diagram khusus, dimana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh

55

selesainya

state sebelumnya (internal processing). Oleh karena itu

activity

diagram tidak menggambarkan behaviour internal sebuah sistem dan interaksi antar subsistem secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan pada sistem, sementara itu use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision pada diagram digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

Gambar 2.16 Contoh activity diagram tanpa swimlane

56

2.7.5 Sequence Diagram Sequence Diagram menggambarkan proses yang terjadi di dalam sistem dalam rangkaian waktu. Terdapat

dua dimensi yaitu dimensi vertikal

menunjukkan waktu yang berjalan, dilakukan dari atas ke bawah dan dimensi horizontal menunjukkan objek-objek yang terlibat dalam sebuah sistem. Sequence diagram biasa digunakan untuk menggambarkan skenario atau

rangkaian

langkah-langkah yang dilakukan sebagai respon dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya.

Gambar 2.17 Contoh sequence diagram

57

2.7.6 Collaboration/Communication Diagram Collaboration diagram, hampir sama seperti sequence diagram, namun tidak diperlihatkan dimensi waktu di dalamnya, dan terdapat label sesuai class yang dipakai. Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence number, dimana message dari level tertinggi memiliki nomor satu dan message dengan level dibawahnya akan memiliki nomor induknya diikuti subnomor message tersebut. Messages dari level yang sama memiliki prefiks yang sama.

Gambar 2.18 Contoh collaboration/communication diagram

58

2.7.7 Component Diagram Component diagram

menggambarkan struktur dan hubungan antar

komponen piranti lunak, termasuk ketergantungan (dependency) diantaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time.

Gambar 2.19 Contoh component diagram Umumnya komponen terbentuk dari beberapa

class atau beberapa

package, tapi dapat juga terbentuk dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain, sehingga sebuah komponen dapat pula merupakan syarat dari adanya komponen lain. 2.7.8 Deployment Diagram Deployment diagram, biasanya digunakan untuk menggambarkan struktur jaringan dalam suatu instansi. Dengan deployment diagram bisa dijelaskan jenis perangkat yang digunakan, baik perangkat keras maupun perangkat lunak.

59

Deployment/physical diagram menggambarkan detail bagaimana komponen dideploy dalam infrastruktur sistem, dimana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisik. Sebuah node dapat merupakan suatu server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node misalnya TCP/IP, dan suatu keterangan requirement dapat juga didefinisikan dalam diagram ini.

Gambar 2.20 Contoh deployment diagram

60

2.8 Basis Data 2.8.1 Pengertian Basis Data Sistem basis data adalah sistem terkomputerisasi yang tujuan utamanya adalah memelihara data yang sudah diolah atau informasi dan membuat informasi tersedia saat dibutuhkan. Pada intinya adalah basis data media untuk menyimpan data agar dapat diakses dengan mudah dan cepat. Sistem tidak dapat dipisahkan dengan kebutuhan akan basis data apapun bentuknya, baik berupa file teks atau Database Management System (DBMS). Kebutuhan basis data dalam sistem meliputi : 1. Memasukan, menyimpan, dan mengambil data. 2. Membuat laporan berdasarkan data yang telah disimpan. 2.8.2 Database Management System (DBMS) DBMS (Database Management System) merupakan suatu sistem aplikasi yang digunakan untuk menyimpan, mengelola, dan menampilkan data. Suatu sistem aplikasi disebut DBMS jika memenuhi persyaratan minimal sebagai berikut : 1. Menyediakan fasilitas untuk mengelola akses data 2. Mampu menangani integritas data 3. Mampu menangani backup data Karena pentingnya data bagi suatu organisasi atau perusahaan, maka hampir sebagian besar perusahaan memanfaatkan DBMS dalam mengelola data yang mereka miliki, pengelolaan DBMS sendiri biasanya ditangani oleh tenaga

61

ahli yang spesialis menangani DBMS yang disebut sebagai DBA (Database Administrator). Berikut ini adalah 4 macam DBMS versi komersial yang paling banyak digunakan di dunia saat ini, yaitu : 1. Oracle 2. Microsoft SQL Server 3. IBM DB2 4. Microsoft Access Sedangkan DBMS versi open source yang cukup berkembang dan paling banyak digunakan saat ini adalah sebagai berikut : 1. MySQL dan PostgreSQL 2. Firebird 3. SQLite MySQL merupakan sistem database yang banyak digunakan untuk pengembangan aplikasi web. Alasannya karena gratis, pengelolaan datanya sederhana, memiliki tingkat keamanan yang bagus dan mudah diperoleh. 2.8.3 Model Data Model data adalah sekumpulan cara atau peralatan atau tool untuk mendeskripsikan data-data, hubungannya satu sama lain, semantiknya, serta batasan konsistensi.

62

Ada dua cara penyajian data, yaitu : Entity Relationship Diagram (ERD) dan model relasional. Keduanya menyediakan cara untuk mendeskripsikan perancangan basis data pada tingkat logika. 1. Model ERD atau Conceptual Data Model (CDM) : model yang dibuat

berdasarkan anggapan bahwa dunia nyata terdiri dari koleksi obyek-obyek dasar yang dinamakan entitas (entity) serta hubungan (relationship) antara entitas-entitas itu.

Gambar 2.21 Entity Relationship Diagram 2. Model

Relasional atau Physical Data Model (PDM) : model yang

menggunakan sejumlah tabel untuk menggambarkan data serta hubungan antara data-data tersebut. Setiap tabel mempunyai sejumlah kolom dimana setiap kolom memiliki nama yang unik.

Gambar 2.22 Contoh relasi antar tabel

63

2.9 Jejaring Sosial Social Networking Site (SNS) atau biasa disebut juga jaringan sosial didefinisikan sebagai suatu layanan berbasis web yang memungkinkan setiap individu untuk membangun hubungan sosial melalui dunia maya seperti membangun suatu profil tentang dirinya sendiri, menunjukkan koneksi seseorang dan memperlihatkan hubungan apa saja yang ada antara satu member dengan member lainya dalam sistem yang disediakan, dimana masing-masing social networking site memiliki ciri khas dan sistem yang berbeda-beda, beberapa contoh Social Networking Site diantaranya MySpace, Facebook, Cyworld, dan Bebo. Situs jejaring sosial merupakan sebuah alat bantu berbasis web yang diciptakan dengan tujuan untuk menghubungkan antara satu pengguna dengan pengguna lainnya yang tersebar diseluruh dunia. Pada umumnya situs jejaring sosial gratis untuk digunakan. Konsep pertemanan yang masih sangat populer digunakan oleh banyak situs jejaring sosial saat ini ada dua jenis konsep yaitu following/interest dan friendship. Konsep

following/interest merupakan cara

pertemanan yang memungkinkan para pengguna untuk mengikuti aktivitas dari teman yang ingin diketahui berdasarkan minat yang dimilikinya. Sedangkan, friendship merupakan cara pertemanan yang mengharuskan seorang pengguna untuk menambahkan pengguna lain sebagai teman dan harus mendapatkan persetujuan dari pengguna lain tersebut agar bisa melihat kegiatannya pada sebuah situs jejaring sosial.