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 Managers Guide sebagai fungsi-

fungsi 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 API-

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

<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<SOAP-ENV:Header>
...
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>
...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP_ENV:Envelope>

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.

<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"

SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
...
Message information goes here
...
</SOAP-ENV:Envelope>

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

<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<SOAP-ENV:Header>
<t:Transaction
xmlns:t="http://www.tutorialspoint.com/transaction/"
SOAP-ENV:mustUnderstand="true">5</t:Transaction>
</SOAP-ENV:Header>
...
</SOAP-ENV:Envelope>

3. SOAP Body, berisi data yang berhubungan dengan aplikasi tertentu yang sedang

dipertukarkan.

<?xml version="1.0"?>
<SOAP-ENV:Envelope
........
<SOAP-ENV:Body>
<m:GetDescription xmlns:m="http://www.tp.com/Description">
<m:Item>Computers</m:Item>
</m:GetDescription>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

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 :

<?xml version="1.0"?>
<SOAP-ENV:Envelope
........
<SOAP-ENV:Body>
<m:GetDescriptionResponse
xmlns:m="http://www.tp.com/Description">
<m:Description>This is Description</m:Description>
</m:GetDescriptionResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 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.

<?xml version='1.0' encoding='UTF-8'?>

<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>
<faultcode xsi:type="xsd:string">SOAP-
ENV:Client</faultcode>
<faultstring xsi:type="xsd:string">
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.
</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

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
HTTP Analogi
No Aksi Deskripsi
Method Perintah
Mengambil atau 1. Digunakan untuk
1 GET memperoleh memperoleh Ambil itu!
resources resource data
Menyimpan atau 1. Digunakan untuk
menambahkan menyimpan atau Simpan
2 PUT
resources baru menambahkan disitu!
resource baru
Menyimpan atau 2. Method ini dapat
menambahkan digantikan oleh
resources baru method POST,
Simpan
3 PUT karena method ini
disitu!
tidak dapat
digunakan pada
beberapa browser
Merubah 1. Digunakan untuk
resources yang merubah resource
sudah ada yang sudah ada
2. Method ini dapat
digunakan untuk
4 POST Ubah itu!
menggantikan
methop PUT,
karena method ini
lebih umum
digunakan.
Menghapus 1. Digunakan untuk
resources yang menghapus Hilangkan
5 DELETE
sudah ada resource yang itu!
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=ISO-8859-1">
</HEAD>
<BODY><H1>401 Unauthorised.</H1></BODY>
</HTML>

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).
3 REST memiliki noun berupa
resources.
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).
RPC-style mendefinisikan
methods.
Akses didefinisikan dengan
cara bagaimana
mengeksekusi methods di
server dengan menggunakan
standar tertentu (XML-RPC
atau SOAP) sebagai layer
messaging.
RPC style memiliki verb
berupa methods.
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 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 kebutuhan-

kebutuhan 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 Major Area View Diagrams Main Concepts

1 Structural Static View Class Class, association,

Diagram generalization,
dependency,
realization,
interface
Use Case View Use Case Use case, actor,
Diagram association, extend,
include, use case
generalization
Implementation Component Component, interface,
View Diagram dependency,
realization
Deployment Deployment Node, component,
View Diagram dependency, location

2 Dynamic State Machine Statechart State, event,

View Diagram transition, action
 48

Tabel 2.3 Konsepsi dasar Unified Modeling Language (lanjutan)

No Major Area View Diagrams Main Concepts

Activity View Activity State, activity,

Diagram completion
transition, fork,
join.
Interaction Sequence Interaction, object,
View Diagram message, activation

Collaboration Collaboration,
Diagram interaction,
collaboration, role,
message
3 Model Model Class Diagram Package, subsystem,
Management Management model
View
4 Extensibil All All Constraint,
ity 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 anak-

anak 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 di-

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