9
2.1. Teori yang Berkaitan dengan Software Engineering 2.1.1. Software Project Management
Stellman & Greene (2005:ix) mendefinisikan bahwa software project management adalah seni dan ilmu dalam merencanakan dan memimpin proyek perangkat lunak. Software project management memerlukan pengetahuan mengenai siklus pengembangan perangkat lunak secara menyeluruh, mulai dari menentukan visi proyek, merencanakan tugas-tugas yang perlu dilakukan, mengumpulkan orang-orang yang akan mengerjakan tugas tersebut, memperkirakan usaha yang akan dikeluarkan, merancang jadwal pengerjaan, mengawasi pekerjaan yang sedang dilakukan, mengumpulkan kebutuhan-kebutuhan, merancang dan membangun program perangkat lunak, dan menguji coba produk.
2.1.2. Waterfall Model
Pressman (2009:39) menjelaskan bahwa model waterfall digunakan sebagai pendekatan sistematis dalam mengembangkan perangkat lunak. Model waterfall dapat disebut sebagai classic life cycle. Dalam model waterfall, terdapat lima tahap dalam mengembangkan sebuah perangkat lunak, yaitu:
Gambar 2.1 Proses pengembangan perangkat lunak waterfall Communication
Planning
Modeling
Construction
a. Communication
Tujuan akhir dari fase communication adalah agar developer memiliki gambaran sistem akhir yang akan dihasilkan dan mengumpulkan kebutuhan dari perangkat lunak. Tahap communication terdiri dari empat langkah, yaitu:
1. membuat garis besar dari tujuan dan sasaran dari sistem akhir yang akan dihasilkan,
2. melakukan survei dengan menggunakan kuesioner untuk menentukan target pengguna dan kebutuhan lain yang diharapkan dari sistem yang akan dihasilkan, 3. menganalisis masalah dan kendala yang mungkin
terjadi beserta solusi untuk menyelesaikannya, dan 4. menganalisis kebutuhan perangkat keras, perangkat
lunak, authoring tools, serta delivery platform yang tepat untuk digunakan pada tahap selanjutnya.
b. Planning
Pada tahap planning, developer mulai membuat estimasi biaya dan jumlah orang yang dibutuhkan dalam pengembangan perangkat lunak. Selain estimasi, disusun juga penjadwalan dengan membuat timeline agar perangkat lunak dapat berjalan dan selesai tepat waktu.
c. Modeling
Pada tahap modeling, developer melakukan analisis dan merancang sistem dari perangkat lunak sesuai dengan kebutuhan pengguna.
d. Construction
Pada tahap construction, dilakukan perancangan kode (coding) sesuai dengan rancangan perangkat lunak yang telah ditentukan. Setelah perancangan kode selesai dilakukan, akan dilakukan beberapa uji coba untuk menguji perangkat lunak yang telah dibangun.
e. Deployment
Pada tahap deployment, dilakukan implementasi sistem ke dalam lingkungan tujuan.
2.1.3. Interaksi Manusia dan Komputer a. Lima Faktor Manusia Terukur
Shneiderman (2009:32) mengemukakan lima faktor manusia terukur, yaitu:
1. Waktu untuk belajar (time to learn): waktu yang dibutuhkan oleh pengguna untuk mempelajari cara melakukan sebuah aksi pada sebuah rangkaian tugas. 2. Kecepatan kinerja (speed of performance): tolak ukur
kecepatan dari performa aplikasi bagi pengguna untuk menyelesaikan tugas tertentu.
3. Tingkat kesalahan (rate of errors): besar dan variasi kemungkinan kesalahan yang dilakukan oleh pengguna saat menyelesaikan tugas tertentu. Koreksi akan kesalahan juga akan mempengaruhi kecepatan kinerja. 4. Ingatan dari waktu ke waktu (retention over time):
kemampuan pengguna untuk mempertahankan daya ingatnya dalam menyelesaikan tugas tertentu dengan menggunakan aplikasi selama jangka waktu tertentu. Sangat berpengaruh dari waktu untuk belajar dan intesitas penggunaan aplikasi.
5. Kepuasan subjektif (subjective satisfaction): kepuasan pribadi pengguna dalam menggunakan beberapa aspek dalam aplikasi yang dapat diukur melalui wawancara ataupun kuesioner.
b. Delapan Aturan Emas (Eight Golden Rules)
Delapan aturan emas yang harus diimplementasikan dalam merancang sistem menurut Shneiderman (2009:88) yaitu:
1. Mempertahankan konsistensi (strive for consistency) Konsistensi urutan aksi sangat dibutuhkan dalam kondisi-kondisi yang mirip, konsistensi penggunaan warna, huruf kapital, dan jenis huruf.
2. Memenuhi kegunaan universal (cater to universal usability)
Mengenali kebutuhan dari pengguna yang berbeda-beda dengan desain yang fleksibel untuk memfasilitasi perubahaan dari konten. Berikan perbedaan bagi pengguna pemula dan pengguna berpengalaman, seperti penjelasan bagi pengguna pemula dan jalan pintas bagi pengguna berpengalaman. 3. Memberikan umpan balik yang informatif (offer
informative feedback)
Untuk setiap tindakan yang dilakukan pengguna berikanlah umpan balik dari sistem. Untuk tindakan yang sering dilakukan dan kurang penting, dapat menggunakan respon sederhana, sedangkan untuk tindakan yang jarang dilakukan dan cukup penting, umpan balik yang diberikan harus lebih menarik perhatian pengguna.
4. Merancang dialog untuk menghasilkan suatu penutupan (design dialogs to yield closure)
Kumpulan tindakan harus dikelompokkan ke dalam suatu kumpulan awal, tengah, dan akhir. Umpan balik yang informatif sebagai penyelesaian dari sebuah kumpulan tindakan harus memberikan petunjuk bahwa kumpulan tindakan tersebut sudah selesai dan kemudian mengarahkan pengguna menuju kumpulan tindakan berikutnya.
5. Mencegah terjadinya kesalahan (prevent errors)
Sistem harus dirancang sedemikian rupa sehingga pengguna tidak dapat membuat kesalahan fatal. Jika pengguna membuat kesalahan, tampilan antarmuka harus dapat mendeteksi adanya kesalahan dan memberikan instruksi sederhana yang membangun dan spesifik untuk dilakukan perbaikan. Sebagai contoh, seharusnya pengguna tidak perlu menuliskan
ulang nama serta alamat jika mereka hanya memasukkan kode pos yang tidak valid. Solusi yang perlu ditawarkan adalah pengguna harus dituntun untuk memperbaiki bagian tertentu yang salah.
6. Mudah kembali ke tindakan sebelumnya (permit easy reversal of actions)
Sebisa mungkin membuat sebuah tindakan yang telah dilakukan pengguna dapat dibatalkan atau kembali ke saat sebelum dilakukannya tindakan tersebut. Fitur ini mengurangi kecemasan pengguna dalam melakukan tindakan, karena pengguna tahu bahwa kesalahan dapat dibatalkan, sehingga mendorong pengguna untuk mengeksplorasi tindakan yang belum pernah dilakukan pengguna.
7. Membuat pengguna merasa memiliki kendali (support internal locus of control)
Pengguna yang berpengalaman menginginkan agar mereka dapat bertanggung jawab atas tampilan antarmuka dari aplikasi dan tampilan antarmuka memberikan respon atas tindakan pengguna.
8. Mengurangi beban ingatan jangka pendek (reduce short term memory load)
Manusia memiliki kemampuan yang terbatas untuk mengolah informasi dalam memori jangka pendek, sehingga dibutuhkan desain antarmuka yang sederhana dan mudah mengingat informasi dari satu layar dan menggunakan informasi di layar lainnya.
2.1.4. Unified Modelling Language (UML)
Whitten (2007:371) menjelaskan bahwa Unified Modeling Language (UML) adalah sekumpulan pemodelan yang digunakan dalam menentukan atau menjelaskan sistem perangkat lunak mengenai objek. Pendekatan permodelan yang semua tekniknya berorientasi objek merupakan permodelan objek.
Pada mulanya, proses pengembangan sistem perangkat lunak memiliki banyak metode yang beragam. Sehingga seringkali terjadi kebingungan atau kesalahpahaman dalam proses pengembangan suatu sistem perangkat lunak. Sehingga pada tahun 1994, Grady Booch dan James Rumbaugh bersama-sama menggabungkan ide masing-masing mengenai pengembangan sistem berorientasi objek dengan tujuan menciptakan suatu standar tunggal dalam proses pengembangan sistem berorientasi objek. Pada tahun 1995, Ivar Jacobson bergabung dan mereka bertiga memiliki tujuan utama untuk menciptakan sebuah standar untuk bahasa permodelan berorientasi objek. Pada tahun 1997, Unified Modeling Language (UML) versi 1.0 resmi dirilis. Sedangkan untuk yang saat ini digunakan adalah UML 2.0. UML tidak mendeskripsikan sebuah metode, tetapi hanyalah sebuah notasi yang sampai sekarang diterima luas sebagai standar untuk pemodelan objek.
a. Use Case Diagram
Whitten (2007:246) menyatakan bahwa use case diagram merupakan sebuah diagram yang menggambarkan interaksi antara sistem dan sistem eksternal dengan pengguna. Dengan kata lain, use case diagram menggambarkan siapa yang akan menggunakan sistem dan dengan cara apa yang diharapkan pengguna untuk dapat berinteraksi dengan sistem.
Komponen penyusun use case diagram, yaitu: - Actor
Actor menjalankan suatu aktivitas pada sebuah sistem dengan tujuan melengkapi beberapa tugas bisnis yang menghasilkan sesuatu yang dapat diukur.
Gambar 2.3 Contoh actor pada use case Diagram
- Relationship
Relationship digambarkan dengan sebuah garis penghubung antara dua simbol dalam use case diagram. Makna dari relasi dalam use case diagram dapat bermacam-macam tergantung bagaimana garis yang digambarkan dan jenis simbol yang terhubung. Ada beberapa jenis hubungan dalam use case diagram, antara lain:
• Associations
Associations merupakan hubungan antara actor dengan use case yang menyatakan use case tersebut memiliki interaksi dengan actor yang terhubung langsung. Association digambarkan dengan garis lurus yang tidak terputus-putus antara use case dengan actor baik searah maupun dua arah.
Gambar 2.4 Contoh hubungan associations pada use case diagram
• Extends
Extends membantu untuk menghasilkan use case baru yang merupakan hasil ekstraksi fungsi dari use case aslinya, agar use case aslinya dapat menjadi lebih sederhana dan mudah dipahami. Extends pada umumnya tidak dijelaskan dalam tahap penentuan kebutuhan pengguna. Extends pada use case diagram digambarkan dengan garis putus-putus yang diberi label <<extends>> dengan panah menunjuk kepada use case utama.
Gambar 2.5 Contoh hubungan extends pada use case diagram
• Uses / Include
Seorang actor dapat menjalankan beberapa use case yang sama. Untuk menghilangkan redundansi use case yang digunakan, maka hal tersebut dapat diatasi dengan membuat suatu abstract use case dimana use case dengan
abstract use case akan dihubungkan melalui sebuah garis putus-putus yang diberi label <<uses>>atau <<include>> dengan panah menunjuk kepada abstract use case.
Gambar 2.6 Contoh hubungan uses pada use case diagram
• Depends On
Depends on merupakan sebuah hubungan use case yang menjelaskan bahwa use case akan berjalan terlebih dahulu sebelum use case yang lainnya berjalan. Depends on dapat membantu mengurutkan kejadian use case dalam use case diagram. Depends on digambarkan dengan garis solid ataupun putus-putus yang diberi label <<depends on>> dengan panah menunjuk kepada use case yang memiliki keterkaitan.
Gambar 2.7 Contoh hubungan depends on pada use case diagram
- Use Case
Use case adalah bagian dari fungsi sistem secara keseluruhan yang dapat diperoleh dari narasi atau skenario. Use case digambarkan dengan elips horisontal yang berisi nama use case di tengahnya.
Gambar 2.8 Contoh use case pada use case diagram
- Boundary
Boundary merupakan batasan area untuk use case yang berperan menjelaskan sistem yang digambarkan oleh use case diagram tersebut. Use case akan berada di dalam boundary dan actor yang menjalankan sistem berada di luar boundary. Boundary digambarkan dengan kotak persegi panjang disertai dengan nama sistem pada bagian atas.
b. Activity Diagram
Whitten (2007:390) menjelaskan activity diagram adalah sebuah diagram yang dapat digunakan untuk menggambarkan alur dari sebuah proses bisnis, sebuah use case, atau logika dari perilaku objek. Activity diagram terlihat serupa dengan diagram alir (flowchart) dalam hal menggambarkan alur berurutan dari sebuah aktivitas atau proses bisnis, tetapi yang membedakan adalah activity diagram dapat menggambarkan aktivitas secara paralel sedangkan flowchart tidak dapat menggambarkan aktivitas secara paralel.
Gambar 2.10 Contoh activity diagram (Sumber: Whitten, 2007:392)
- Initial node: simbol titik awal pada activity diagram yang digambarkan dengan lingkaran utuh dan padat. - Action: aktivitas yang dilakukan oleh actor yang
membentuk urutan aktivitas secara keseluruhan pada activity diagram. Action digambarkan dengan persegi panjang dengan empat sudutnya yang agak melengkung dengan bagian tengah yang mendeskripsikan nama aktivitas.
- Flow/edge: alur aktivitas yang menghubungkan satu action ke action berikutnya sehingga membentuk
urutan aktivitas. Flow digambarkan menggunakan tanda panah yang menunjuk kepada action yang berikutnya dilakukan. Flow/edge yang melalui decision akan memiliki keterangan kondisi yang ditulis di dalam kurung siku ([condition]) menuju action berikutnya. - Decision: simbol yang digunakan untuk memisahkan
alur aktivitas berdasarkan kondisi yang akan dilakukan actor. Decision digambarkan dengan bentuk berlian yang memecah satu alur aktivitas menjadi dua atau lebih alur aktivitas berdasarkan kondisi tertentu.
- Merge: pasangan dari simbol decision yang berbentuk berlian dan memiliki fungsi untuk menggabungkan beberapa alur aktivitas hasil pemecahan simbol decision menjadi satu alur aktivitas.
- Fork: simbol yang menggambarkan aktivitas paralel yang dilakukan pada activity diagram. Fork digambarkan dengna sebuah bar hitam yang memecah satu alur aktivitas menjadi dua atau lebih alur aktivitas. - Join: pasangan dari simbol fork yang berbentuk bar
hitam dimana memiliki fungsi untuk menggabungkan beberapa alur aktivitas hasil pemecahan simbol fork menjadi satu alur aktivitas.
- Activity final: simbol akhir proses pada activity diagram yang digambarkan dengan lingkaran utuh yang memiliki cincin di luarnya.
c. Sequence Diagram
Whitten (2007:394) menjelaskan bahwa sequence diagram merupakan sebuah diagram yang menggambarkan interaksi antara aktor dengan sistem untuk sebuah use case scenario melalui pesan dalam pelaksanaan use case. Sequence diagram menggambarkan pesan yang dikirim dan diterima melalui objek-objek dalam use case secara berurutan.
Gambar 2.11 Contoh sequence diagram (Sumber: Whitten, 2007:395)
Keterangan:
1. Actor: aktor utama dari use case yang ditunjukan dengan simbol actor seperti pada use case diagram. 2. System: sebuah kotak yang menggambarkan sistem
(:) merupakan standar dari notasi sequence diagram untuk menunjukkan sebuah instance yang sedang berjalan pada sebuah sistem.
3. Lifelines: garis putus-putus vertikal yang menyambung kebawah dari actor atau sistem yang menunjukkan siklus hidup dari sebuah objek dalam sequence diagram.
4. Activation bars: sebuah bar yang digunakan untuk menunjukkan periode waktu ketika sebuah objek berinteraksi dalam sequence diagram aktif.
5. Input messages: panah horisontal dari actor menuju sistem yang menunjukkan pesan yang dimasukkan ke dalam sistem. Aturannya adalah huruf pertama pada kata pertama menggunakan huruf kecil, diikuti dengan huruf pertama kapital pada kata kedua dan seterusnya dan tanpa spasi, diikuti dengan semua parameter yang dikirimkan ke sistem dengan aturan nama yang sama dan dipisahkan dengan tanda koma jika lebih dari satu parameter.
6. Output messages: panah horisontal dari sistem menuju actor yang digambarkan dengan garis putus-putus. Pesan yang disampaikan berupa jawaban atas pesan yang telah dikirim pengguna sebelumnya. Tidak ada standar khusus dalam penulisan output messages. 7. Receiver Actor: actor lain atau sistem eksternal yang
menerima pesan dari sistem yang berhubungan.
8. Frame: sebuah kotak yang memiliki satu atau lebih pesan untuk membagi sequence diagram menjadi sebuah fragmen yang memiliki fungsi khusus seperti loops, alternate fragment, atau optional. Untuk fungsi optional, kondisinya dituliskan dalam kurung kotak yang akan menunjukkan kondisi yang harus terpenuhi untuk menjalankan aktivitas dalam fragmen tersebut.
d. Class Diagram
Menurut Whitten (2007:400), sebuah class diagram merupakan gambaran grafis struktur objek dari sistem statis. Yang menunjukan bahwa sistem terdiri dari objek dan serta hubungan antara kelas-kelas objek.
Gambar 2.12 Contoh class diagram (Sumber: Whitten, 2007:661)
Class diagram terbangun atas 3 bagian, yaitu: - Nama class
- Atribut class - Operasi class
Gambar 2.13 Struktur class pada class diagram
Multiplicity dalam class diagram menggambarkan berapa banyak objek yang dapat mengisi properti dari class.
Tabel 2.1 Multiplicity dalam class diagram
Multiplicity Deskripsi
1 Harus ada hanya satu dan tidak lebih 0..1 Dapat tidak atau memiliki hanya satu
* Dapat tidak atau memiliki lebih dari satu
Hubungan antar class digambarkan dengan sebuah garis dalam class diagram. Ada beberapa jenis hubungan dalam class diagram, antara lain:
- Associations
Associations merupakan hubungan class yang menyatakan class tersebut memiliki interaksi yang terhubung langsung. Associations digambarkan dengan garis lurus tegas dari class asal menuju ke class tujuan. Fungsi associations adalah memberikan keterangan mengenai relasi antar class dan properti lainnya.
Gambar 2.14 Contoh association
Generalization berfungsi untuk menggambarkan turunan dalam class diagram. Generalization digambarkan dengan garis dengan anak panah segitiga yang menunjuk dari subclass menuju superclass. Subclass memiliki properti-properti yang ada pada superclass, namun dapat memiliki atribut dan method tambahan yang tidak dimiliki oleh superclass.
Gambar 2.15 Contoh generalization
2.2. Teori yang Berkaitan dengan Penelitian (Tematik) 2.2.1. HTML5
a. Definisi
HTML5 adalah teknologi pengembangan dari HTML yang pada awalnya dirancang untuk berbagi dokumen statis berbasis teks pada internet. Seiring berjalannya waktu, para pengguna web menginginkan interaktivitas yang lebih dalam HTML. HTML5 dirancang untuk membuat pengembangan aplikasi web menjadi lebih mudah, alami, logis, dan lebih bermanfaat karena menghilangkan kebutuhan untuk memasang plugin. Wang, Salim, & Moskovits (2013:1) menjelaskan, dengan menggunakan HTML5, sekarang dapat menggunakan semantik markup language seperti <header> sebagai pengganti <div class="header">. HTML5 memudahkan developer untuk menambahkan konten multimedia melalui kode pemrograman, dengan menggunakan tag seperti <audio> dan <video> untuk menetapkan dan menampilkan jenis media yang sesuai. Pada HTML5, terdapat tag <canvas> yang
memiliki basis JavaScript untuk membuat gambar pada halaman web. HTML5 juga dilengkapi dengan berbagai fitur baru seperti penyimpanan offline & online yang membuat aplikasi HTML5 bekerja lebih cepat, meskipun tidak ada koneksi internet. Aplikasi yang interaktif dan mampu menarik pengguna dapat dikembangkan dengan menggunakan teknologi HTML5.
b. Konektivitas
Wang, Salim, & Moskovits (2013:2) menjelaskan bahwa konektivitas HTML5 meliputi teknologi WebSocket, server-sent event, cross-document messaging. Sebelum HTML5, komunikasi antar jendela dan jendela browser lainnya dibatasi dengan alasan keamanan. Dengan semakin berkembangnya teknologi web, aplikasi web mulai menyatukan konten dan aplikasi dari situs yang berbeda dan membuat kebutuhan akan komunikasi antar aplikasi web menjadi sangat diperlukan. Spesifikasi HTML5 untuk cross-document messaging juga menjelaskan dan memurnikan keamanan domain dengan memperkenalkan konsep asal, yang didefinisikan oleh skema, host, dan port. Pada dasarnya, dua URL dianggap berasal dari asal yang sama jika dan hanya jika mereka memiliki skema, host, dan port yang sama. Cross-document messaging mengatasi keterbatasan dengan memungkinkan pesan yang akan ditransmisi berasal dari asal yang berbeda. Ketika pesan dikirim, pengirim menentukan alamat penerima dan ketika pesan diterima, alamat pengirim telah dimasukkan sebagai bagian dari pesan. Asal-usul pesan disediakan oleh browser dan tidak dapat dipalsukan. Di sisi penerima, penerima dapat memutuskan pesan yang akan diproses dan yang akan diabaikan. Cross-document messaging merupakan contoh yang baik dimana spesifikasi HTML5 menyederhanakan komunikasi antara aplikasi web dengan API yang sangat kuat. Namun, fokusnya menjadi terbatas untuk berkomunikasi antar jendela, tab, dan iFrames.
2.2.2. Real-Time Systems a. Definisi
Menurut Laplante & Ovaska (2011:5), sistem real-time adalah sebuah sistem yang harus memenuhi batasan response-time atau risiko konsekuensi yang berat, termasuk kegagalan. Response-time adalah waktu antara penyajian sekelompok input ke dalam sistem dan realisasi dari perilaku yang diperlukan, termasuk ketersediaan segala output yang berhubungan. Sedangkan Lengstorf & Leggetter (2013:5) mendefinisikan real-time sebagai ketepatan waktu antara waktu terjadinya sebuah kejadian dan waktu sadarnya seseorang akan hal tersebut.
b. Klasifikasi
Laplante & Ovaska (2011:6) mengklasifikasikan sistem real-time menjadi tiga bagian, yaitu :
1. Soft Real-Time System adalah sesuatu yang memiliki kinerja yang menurun namun tidak musnah atas terjadinya kegagalan dalam memenuhi batasan response-time yang diharapkan.
2. Hard Real-Time System adalah sesuatu yang gagal memenuhi batasan response-time sehingga mengakibatkan kegagalan sistem secara lengkap atau bencana.
3. Firm Real-Time System adalah sistem dengan batasan waktu yang tegas namun tetap dapat mentoleransi beberapa kasus terjadinya batasan waktu yang terlewati.
2.2.3. WebSocket a. Definisi
WebSocket adalah teknologi komunikasi bidirectional, full-duplex, single-socket dengan menggunakan protokol berbasiskan Hyper Text Transfer Protocol (HTTP) melalui socket Transmission Control Protocol (TCP). Wang, Salim, & Moskovits (2013:7) menjelaskan, dengan WebSocket, komunikasi real-time menjadi lebih efisien karena sekali koneksi WebSocket dibuat, server dapat melakukan handshake dengan pengguna setiap saat sehingga membuat WebSocket menghemat bandwidth, daya CPU, dan mengurangi latency.
Gambar 2.16 WebSocket
(Sumber: Wang, Salim, & Moskovits, 2013:7)
b. WebSocket API (Application Programming Interfaces) WebSocket Application Programming Interfaces (API) berfungsi untuk mengontrol protokol WebSocket dan membuat aplikasi WebSocket. Wang, Salim, & Moskovits (2013:13) menjelaskan, dengan adanya WebSocket API, memungkinkan aplikasi menggunakan protokol WebSocket untuk komunikasi dua arah (full-duplex) dengan host remote. Upgrade dari protokol HTTP mendirikan sambungan WebSocket untuk protokol WebSocket selama terjadinya handshake antara pengguna dan server, melalui dasar koneksi TCP yang sama.
WebSocket menggunakan protokol jaringan web berupa HTTP yang digunakan untuk berkomunikasi antara pengguna dan server. Protokol HTTP yang diterapkan WebSocket adalah HTTP/1.1., sehingga setiap permintaan yang dikeluarkan tidak memerlukan pengaturan koneksi TCP yang baru dan dapat membuat koneksi tetap. Wang, Salim, & Moskovits (2013:38) menjelaskan bahwa dalam TCP, tiap individu byte yang tiba di penerima akan tiba secara berurutan. Dalam WebSocket, pesan ditransmisikan dengan urutan pesan diskrit. Dengan WebSocket, pesan multi-byte akan tiba dengan menyeluruh dan dalam urutan. Karena batas pesan yang dibangun ke dalam protokol WebSocket, memungkinkan untuk mengirim dan menerima pesan secara terpisah, dan menghindari kesalahan fragmentasi umum.
d. Handshake WebSocket Pembuka
Wang, Salim, & Moskovits (2013:40) menerangkan bahwa setiap koneksi WebSocket selalu diawali dengan permintaan HTTP. Permintaan ini sangat mirip seperti permintaan lainnya, kecuali dalam hal permintaan mengandung header khusus: Upgrade. Upgrade header menunjukan bahwa pengguna ingin meng-upgrade koneksi ke protokol berbeda. Dalam hal ini, protokol berbeda tersebut adalah WebSocket. Permintaan HTTP untuk mengupgrade WebSocket dari pengguna ke server disebut juga handshake WebSocket pembuka.
Gambar 2.17 Permintaan HTTP dari pengguna (Sumber: Wang, Salim, & Moskovits, 2013:41)
Gambar 2.18 Respon HTTP dari server (Sumber: Wang, Salim, & Moskovits, 2013:41)
Gambar 2.19 Handshake WebSocket pembuka (Sumber: Wang, Salim, & Moskovits, 2013:41)
Setelah upgrade berhasil, sintaks koneksi beralih ke format data-framing digunakan untuk mewakili pesan WebSocket. Koneksi tidak akan berhasil kecuali server merespon dengan kode 101response, Upgradeheader, dan Sec-WebSocket-Acceptheader. Nilai dari header Sec-WebSocket-Acceptresponse berasal dari header Sec-WebSocket-Keyrequest dan berisi respon kunci khusus yang harus persis dengan apa yang diharapkan pengguna. Untuk tercapai kesuksesan hand shake, server WebSocket harus merespon dengan computed key. Respon ini menunjukkan bahwa server mengerti protokol WebSocket secara khusus. Tanpa respon yang tepat, ada kemungkinan untuk mengelabui beberapa server HTTP untuk melakukan upgrade koneksi secara sengaja. Dalam handshake WebSocket pembuka dan
penghitungan key respon, protokol WebSocket bergantung pada Sec-Header yang didefinisikan dalam RFC 6455.
Tabel 2.2 WebSocket Sec-Headers dan deskripsi (RFC 6455)
Header Deskripsi
Sec-WebSocket-Key Hanya dapat muncul satu kali dalam permintaan HTTP. Digunakan dalam handshake WebSocket pembuka dari pengguna ke server untuk mencegah serangan lintas protokol.
Sec-WebSocket-Accept Hanya dapat muncul satu kali dalam respon HTTP. Digunakan dalam handshake WebSocket pembuka dari pengguna ke server untuk mengkonfirmasi bahwa server memahami protokol WebSocket.
Sec-WebSocket-Extensions
Dapat muncul lebih dari satu kali pada permintaan HTTP, tetapi hanya dapat muncul sekali pada respon HTTP. Digunakan dalam handshake WebSocket pembuka dari pengguna ke server, dan dari server ke pengguna untuk setuju menggunakan satu set protocol-level extensions selama koneksi.
Sec-WebSocket-Protocol
Digunakan dalam handshake WebSocket pembuka dari pengguna ke server, dan dari server untuk negosiasi sebuah
sub-protokol. Header ini mengiklankan protokol yang dapat digunakan aplikasi client-side. Server menggunakan header yang sama untuk memilih protokol.
Sec-WebSocket-Version Digunakan dalam handshake WebSocket pembuka dari pengguna ke server untuk mengindikasikan kecocokan versi.
(Sumber: Wang, Salim, & Moskovits, 2013:43)
e. Format Pesan
Wang, Salim, & Moskovits (2013:43) memaparkan bahwa pesan diwakili pada jaringan dengan sintaks biner yang menandai batas antara pesan dan yang termasuk jenis informasi singkat. Header biner ini menandai batas antara sesuatu dengan yang lainnya, yang disebut frame. Frame adalah data parsial yang dapat dikombinasikan untuk membentuk pesan. WebSocket tidak menunjukkan informasi tingkat frame kepada aplikasi yang memungkinkan untuk menangani data unit sub-pesan pada tingkat protokol, meskipun API bekerja dalam pesan. Umumnya hanya terdapat satu frame dalam pesan, tetapi pesan terdiri dari beberapa frame. Server dapat menggunakan nomor yang berbeda dari frame untuk mulai mengirimkan data sebelum seluruh data tersedia.
Gambar 2.20 Ilustrasi WebSocket frame header (Sumber: Wang, Salim, & Moskovits, 2013:44)
Kode WebSocket framing bertanggung jawab dalam beberapa hal berikut, yaitu opcodes, length, decoding text, masking, dan multi-frame messages. Setiap pesan WebSocket memiliki opcode yang menspesifikasikan tipe dari muatan pesan. Opcode memiliki nilai numerik yang terdiri dari 4 bit pada byte pertama pada frame header. Dengan 4 bit yang digunakan untuk opcodes, menjadikan adanya 6 nilai yang berbeda.
Tabel 2.3 Definisi opcodes Opcode Tipe Muatan Pesan Deskripsi
1 Teks Tipe data dari pesan
adalah teks.
2 Biner Tipe data dari pesan
adalah biner.
8 Close Pengguna atau server mengirim handshake tertutup ke server atau pengguna.
9 Ping Pengguna atau server mengirim ping ke server atau pengguna.
10 (hex 0xA)
Pong Pengguna atau server mengirim pong ke server atau pengguna.
Protokol WebSocket melakukan encoding pada panjang frame menggunakan nomor variabel dari bit, yang memungkinkan pesan berukuran kecil untuk menggunakan encoding dan tetap memungkinkan protokol membawa pesan dengan ukuran sedang dan bahkan ukuran besar. Untuk pesan yang memiliki ukuran lebih kecil dari 126 byte, panjang frame dikemas dalam satu dari dua header byte pertama. Untuk pesan yang memiliki ukuran diantara 126 dan 216 byte, 2 byte tambahan digunakan. Untuk pesan yang memiliki ukuran lebih besar dari 126 bytes, 8 byte dari panjang pesan sudah dimasukkan. Panjang frame di-encode ke dalam 7 bit terakhir dari byte kedua dalam frame header. Nilai 126 dan 127 dalam field diperlakukan sebagai sinyal khusus tambahan untuk menyelesaikan panjang encoded. WebSocket frame dikirim dari browser ke server dengan masked untuk masking konten bukan untuk mencegah konten yang terbocorkan, akan tetapi dimaksudkan untuk alasan keamanan yang tidak biasa dan untuk meningkatkan kecocokan dengan proxy HTTP yang ada. Bit pertama dari byte kedua dari frame header mengindikasikan bahwa ada masked pada frame. Protokol WebSocket membutuhkan mask pengguna pada setiap frame yang dikirimkan. Setiap muatan yg diterima oleh WebSocket server, pertama-tama akan dilakukan unmasking sebelum diproses. Setelah dilakukan unmasking, server mempunyai isi asli dari pesan. Pesan biner dapat dikirim langsung dan pesan teks akan di decode dengan UTF-8 dan ditunjukkan oleh server API sebagai strings.
Gambar 2.21 Unmasking muatan (Sumber: Wang, Salim, & Moskovits, 2013:47)
Fin bit dalam format frame memungkinkan pesan multi-frame atau streaming bagian dari pesan yang tersedia, yang mungkin terfragmentasi atau tidak lengkap. Untuk mentransmisikan sebuah pesan yang tidak lengkap, dapat dilakukan pengiriman frame yang memiliki fin bit yang diset ke nol. Frame terakhir yang memiliki fin bit diset ke satu, mengindikasikan bahwa pesan berakhir dengan muatan dari frame.
f. Handshake WebSocket Penutup
Wang, Salim, & Moskovits (2013:46) memaparkan bahwa koneksi WebSocket selalu diawali dengan handshake pembuka, sebagai satu-satunya jalan untuk melakukan inisialisasi percakapan. Pada internet atau jaringan lainnya, koneksi dapat ditutup kapan saja, sehingga tidak mungkin koneksi selalu diakhiri dengan handshake penutup. Terkadang soket TCP dapat tertutup secara tiba-tiba. Handshake penutup menutup koneksi dan mengizinkan aplikasi untuk memberitahukan perbedaan antara koneksi yang ditutup secara sengaja dan ditutup secara tidak sengaja. Ketika WebSocket tertutup, titik akhir pemutusan koneksi mengirimkan kode numerik dan string yang berisi alasan mengapa socket tertutup. Kode ditampilkan dalam unsigned 16-bit integer.
Tabel 2.4 Definisi kode WebSocket penutup
Code Nama Deskripsi
1000 Normal Close Sesi selesai dengan sukses. 1001 Going Away Koneksi tertutup karena
aplikasi dalam keadaan going away dan tidak ada
kemungkinan untuk
melakukan follow up. Server mungkin akan melakukan shutting down dan aplikasi
pengguna akan tertutup. 1002 Protocol Error Terjadi error pada protokol 1003 Unacceptable Data
Type
Menerima pesan dengan tipe tidak diduga yang tidak dapat ditangani.
1004 Reserved Status kode cadangan, dan akan didefinisikan nanti. 1005 Reserved Status kode cadangan, dan
akan didefinisikan nanti. 1006 Reserved Status kode cadangan, dan
akan didefinisikan nanti. 1007 Invalid Data Menerima format pesan yang
tidak sesuai dengan tipe pesan. 1008 Message Violates
Policy
Aplikasi memutus koneksi untuk alasan tidak tercakupi oleh kode lain.
1009 Message Too Large Pesan yang diterima terlalu besar untuk ditangani aplikasi. 1010 Extension Required Aplikasi membutuhkan satu
atau lebih ekstensi spesifik bahwa server tidak melakukan negosiasi.
1011 Unexpected Condition Aplikasi tidak dapat melanjutkan penanganan koneksi untuk alasan tak terduga.
1015 TLS Failure (reserved) WebSocket menggunakan kode ini untuk mengindikasikan TLS gagal sebelum terhadi WebSocket handshake.
Tabel 2.5 Daftar empat kategori kode penutup dalam WebSocket.
Kode Nama Description
0-999 Prohibited Kode dibawah 100 adalah tidak valid dan tidak dapat digunakan untuk tujuan apapun.
1000-2999
Reserved Kode ini dicadangkan untuk penggunaan dalam ekstensi dan versi revisi dari protokol WebSocket itu sendiri.
3000-3999
Registration Required
Kode ini ditujukan untuk penggunaan oleh “Libraries, Framework, dan Aplikasi”
4000-4999
Private Kode ini digunakan untuk tujuan kustom dalam aplikasi.
(Sumber: Wang, Salim, & Moskovits, 2013:49)
2.2.4. WebRTC (Web Real-Time Communication) a. Definisi
Menurut Johnston & Burnett (2012:3), WebRTC merupakan sebuah upaya untuk menambahkan kemampuan komunikasi real-time ke dalam semua browser dan membuat kemampuan ini dapat diakses pengembang web melalui tag standar HTML5 dan API JavaScript. Dengan mengikuti standar-standar yang ditentukan dalam WebRTC, browser menjadi berkemampuan untuk berinteraksi secara langsung dengan browser. Tentunya WebRTC juga memiliki sejumlah arsitektur seperti model segitiga dan trapesium.
b. Model Browser Web
Pemindahan informasi antara browser dengan web server dapat melalui berbagai metode, seperti HTTP, yang berjalan melalui TCP, atau melalui beberapa metode implementasi
baru, yang berjalan melalui protokol WebSocket. Konten aplikasi dibawa dalam HTML yang biasanya memiliki JavaScript dan CSS (Cascading Style Sheets). Pada kasus sederhana, browser mengirim HTTP request ke sebuah web server untuk meminta konten, dan web server mengirim respon berupa dokumen atau gambar. Pada kasus yang lebih rumit, server mengirim JavaScript yang dapat berjalan pada browser, berinteraksi dengan browser melalui API dan dengan pengguna melalui klik dan select. Browser melakukan pertukaran informasi dengan server melalui jalur HTTP terbuka atau WebSocket.
Gambar 2.22 Model browser web (Sumber: Johnston & Burnett, 2012:4)
c. Fungsi Komunikasi Real-Time dalam Browser
Fungsi RTC berinteraksi dengan aplikasi web menggunakan API standar. Fungsi RTC berkomunikasi dengan sistem operasi melalui browser. Fitur baru dari WebRTC adalah interaksi yang muncul antara browser, yang biasanya disebut koneksi peer, dimana fungsi RTC dalam satu browser berkomunikasi menggunakan protokol standar on-the-wire dengan fungsi RTC pada browser lainnya atau VoIP (Voice over Internet Protocol) atau aplikasi video. Ketika pertukaran informasi pada web menggunakan TCP, protokol on-the-wired
antara browser dapat menggunakan protokol pengiriman lainnya seperti UDP (User Datagram Protocol). Protokol lainnya yang terbaru adalah signaling server, yang menyediakan jalur pengiriman sinyal antara browser dan ujung lainnya dari koneksi peer.
Gambar 2.23 Komunikasi WebRTC (Sumber: Johnston & Burnett, 2012:5)
d. Elemen Sistem WebRTC
Elemen-elemen yang terdapat pada sistem WebRTC adalah web server, browser yang berjalan pada berbagai sistem operasi di berbagai perangkat, seperti komputer desktop, tablet, handphone, dan server lainnya. Terdapat juga elemen tambahan seperti gateway ke Public Switched Telephone Network (PSTN) dan titik akhir dari komunikasi internet seperti telepon Session Initiation Protocol (SIP) dan pengguna atau jingle client. WebRTC memungkinkan komunikasi antara perangkat-perangkat ini.
Gambar 2.24 Elemen sistem WebRTC (Sumber: Johnston & Burnett, 2012:5)
e. Arsitektur WebRTC
Arsitektur yang umum digunakan adalah dimana kedua browser menjalankan aplikasi WebRTC yang sama, diunduh dari halaman web yang sama, sehingga menghasilkan hubungan seperti bentuk segitiga. Penyusunan ini dinamakan segitiga karena bentuk dari pengiriman sinyal dan alur media/data antara ketiga elemen ini. Sedangkan, koneksi peer membangun transmisi untuk alur data dan media antara browser secara langsung.
Gambar 2.25 Arsitektur segitiga WebRTC (Sumber: Johnston dan Burnett, 2012:6)
f. Multi-Party Session dalam WebRTC
Selain komunikasi hanya antara dua browser atau browser dengan sebuah tujuan lainnya, WebRTC juga mendukung session dengan banyak pihak atau konferensi yang melibatkan banyak browser sekaligus. Salah satu cara untuk mengimplementasikan hal ini adalah setiap browser harus membangun sebuah koneksi peer dengan browser lainnya dalam sebuah session. Terkadang juga disebut arsitektur konferensi full mesh atau fully distributed. Setiap browser memiliki koneksi peer secara langsung dengan setiap browser lainnya. Ketika sebuah browser baru bergabung dalam sebuah session, koneksi peer baru dibangun untuk mengirim dan menerima aliran media.
Gambar 2.26 Konstruksi full mesh (Sumber: Johnston dan Burnett, 2012:10)
Cara kedua adalah dengan menggunakan sebuah server/mixer/selector yang terpusat dimana hanya akan membutuhkan sebuah koneksi peer tunggal antara setiap browser dengan sebuah media server. Setiap browser tidak perlu membangun sebuah koneksi peer untuk setiap masing-masing browser lainnya. Kadang-kadang disebut arsitektur konferensi “centrally-mixed”. Setiap browser mengirimkan media ke server, dimana selanjutnya akan didistribusikan ke
browser lainnya. Ketika terdapat browser baru yang bergabung dalam session, tidak perlu ada koneksi peer yang dibangun pada setiap browser yang telah ada sebelumnya. Sebaliknya, aliran media yang berasal dari browser yang baru ini akan diterima oleh koneksi peer antara browser yang telah ada dengan media server.
Gambar 2.27 Konstruksi centrally-mixed (Sumber: Johnston dan Burnett, 2012:11)
Arsitektur full mesh memiliki keuntungan sebagai berikut, yaitu tidak diperlukannya sebuah media server, latency transmisi media yang lebih kecil, dan kualitas yang lebih tinggi. Namun, kekurangannya adalah arsitektur ini tidak cocok untuk konferensi dengan pihak yang berkuantitas besar karena bandwidth yang dibutuhkan akan bertambah seiring bertambahnya peserta baru. Sedangkah arsitektur terpusat memiliki keuntungan yaitu mampu menangani session dengan skala yang besar dan juga dapat meminimalisasi jumlah pemrosesan yang dibutuhkan oleh setiap browser ketika ada peserta baru yang bergabung, namun menjadi tidak efisien ketika hanya ada satu atau sejumlah kecil browser yang terlibat.
2.3. Hasil Penelitian atau Produk Sebelumnya
Liu & Sun (2012:2) memaparkan bahwa WebSocket memiliki tingkat traffic dan latency yang lebih rendah. Namun baik WebSocket maupun HTTP memiliki tingkat keamanan yang sama.
a. Network Traffic dan Latency
Komunikasi antara klien dan server yang menggunakan koneksi HTTP membutuhkan header yang ditambahkan pada pesan permintaan dari klien dan respon dari server. Data header pada pesan permintaan dan respon tidak akan digunakan oleh pengguna, selain cookie dan session. Dan data ini perlu dicantumkan untuk setiap pesan yang dikirimkan baik oleh klien maupun server. Akibatnya adalah data ini akan mengkonsumsi sejumlah bandwidth yang mengakibatkan traffic jaringan yang semakin besar bila menggunakan metode Comet dan polling. Sedangkan pada WebSocket, header hanya akan diisi dengan mekanisme HTTP upgrade pada interaksi pertama antara client dan server untuk mengubah protokol HTTP menjadi WebSocket yang dimana mekanisme ini biasanya dikenal dengan istilah initial handshake. Untuk interaksi berikutnya, header tidak dicantumkan kembali pada header, tetapi setiap pesan akan ditambahkan dua bit informasi kontrol yang di-encode oleh UTF-8, bit pertama adalah “\x00” dan bit kedua adalah “\xFF”. Dengan adanya dua bit informasi kontrol ini, header tidak akan menjadi sepanjang header setiap pesan yang terdapat pada koneksi HTTP sehingga mampu pengurangi jumlah bandwidth dan waktu yang dialokasikan untuk membaca header.
Tabel 2.6 Perbandingan header pada HTTP dan WebSocket
Perbandingan HTTP WebSocket Header request GET /long-polling HTTP/1.1 Host: www.kaazing.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; GET /text HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: www.WebSocket.org
en-US; rv:1.9) Gecko/2008061017 Firefox/3.0 Accept: text/html,application/xhtm l+xml,application/xml;q = 0.9, */*; q = 0.8 Accept-Language: en-us,en;q = 0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q = 0.7,*;q = 0.7 Keep-Alive: 300 Connection: keep-alive Cache-Control: max-age = 0 Referer: http://www.example.com/ Header footer Date: Tue, 16 Aug 2008
00:00:00 GMT Server: Apache/2.2.9 (Unix) Content-Type: text/plain Content-Length: 12 GET /text HTTP/1.1 Upgrade: WebSocket Connection: Upgrade b. Efisiensi
Liu & Sun (2012) menjelaskan efisiensi adalah kunci utama dari transmisi data real-time dan juga menjadi sebuah standar yang penting dalam melakukan evaluasi apakah protokol layak untuk transmisi data real-time. Protokol WebSocket memiliki efisiensi sekitar 10x lipat dibandingkan dengan koneksi HTTP, baik dari segi jumlah paket,
jumlah bit, dan waktu yang terkonsumsi dalam interaksi antara klien dan server.
Tabel 2.7 Perbandingan efisiensi WebSocket dengan HTTP
