2012 7:55 PM. Latar Belakang. Collaborations > Thesis > MPEG Slidr thesis

1 dari 23

http://www.urremote.com/collaborations/thesis/mpeg-slidr-thesis?tmpl=/s...

Collaborations > Thesis > MPEG Slidr thesis

Contents 1 BAB I PENDAHULUAN 1.1 Latar Belakang 1.2 Rumusan Masalah 1.3 Tujuan 1.4 Manfaat 1.5 Ruang Lingkup dan Batasan masalah 1.6 Sistematika Pembahasan 2 BAB II DASAR TEORI 2.1 Web Service 2.1.1 REST (representational state transfer) 2.1.2 SOAP (Simple Object Access Protocol) 2.2 Pola Desain Perangkat Lunak (Software Design Pattern) 2.3 Penilaian Kelayakan Perangkat Lunak 2.4 Tingkatan Aplikasi (Application Tier) 3 BAB III METODE 3.1 Tempat dan Waktu Penelitian 3.2 Data 3.2.1 Sumber data 3.2.2 Jenis data 3.2.3 Metode Pengumpulan Data 3.3 Rancangan Sistem 3.3.1 Sasaran pengembangan aplikasi 3.3.2 Fase pemodelan usecase 3.3.3 Fase pemodelan domain sistem 3.3.4 Fase pemodelan desain sistem 3.3.5 Fase Pemodelan Implementasi Sistem 4 Metode Testing Sistem 4.1 Unit testing 4.2 Integration testing 4.3 Functional testing 4.4 System testing

BAB I PENDAHULUAN Latar Belakang Membuat aplikasi web yang bisa dikenal dan dikunjungi banyak orang, bukanlah pekerjaan yang mudah. Karena banyak faktor yang harus diperhitungkan selain kenyamanan dan kemudahan dalam penggunaan serta fitur-fitur unik yang cukup lengkap. Untuk mewujudkan website tersebut sudah tentu dibutuhkan waktu dan dana produksi yang tidak sedikit. Disamping itu dana perawatan dan promosi yang gencar adalah faktor penting yang perlu diperhitungkan pula. Sehingga dibutuhkan solusi yang tepat untuk melakukan produksi website dengan fitur yang memadai, biaya produksi rendah dan perawatan yang murah. Salah satu topik dalam WEB 2.0 yang cukup marak dibicarakan di awal tahun 2006 adalah Web Mash-up. Dimana dengan mash-up pengembang (developer) bisa menggabungkan content dari beberapa website yang ada melalui API (application programming interface), grabbing, scraping dan bot, menjadi sebuah service atau website dengan kemampuan maupun kegunaan baru. Beberapa website terkenal sudah menyediakan layanan API yang bebas digunakan untuk keperluan mash-up seperti: Google, Yahoo!, E-bay, YouTube, Flickr, WebJay, Groopers, Amazon dan masih banyak lagi. Keuntungan yang bisa diberikan oleh mash-up dilihat dari sisi pemakai layanan API adalah biaya untuk proses produksi business logic maupun proses perawatan yang minimum. Karena produksi business logic dan proses perawatan dilakukan di pihak penyedia layanan API. Disamping itu dengan melakukan mash-up ke website terkenal maka secara tidak langsung kita bisa memfasilitasi dan menarik minat sekian banyak orang yang menjadi account member website tersebut, untuk memakai layanan website yang kita buat. Tentu saja hal ini adalah strategi bisnis yang baik untuk mendapatkan pengunjung dengan biaya promosi minimal. Meskipun mash-up memberikan banyak keuntungan namun ada beberapa kelemahan yang terkait dengan nilai kehandalan sebuah perangkat lunak. Kelemahan yang paling utama adalah ketergantungan terhadap aspek business logic yang sewaktu-waktu bisa berubah

5/16/2012 7:55 PM

2 dari 23


tergantung kebijakan pihak penyedia layanan API. Perubahan tidak hanya menyangkut masalah hak akses (gratis menjadi tidak gratis) tapi juga pada struktur data yang sewaktu-waktu bisa berubah sesuai dengan perkembangan businiess logic yang ada di pihak pemberi layanan API. Kelemahan lain adalah ketergantungan terhadap stabilitas layanan penyedia API. Dimana stabilitas fungsi dan layanan website yang dibuat 100% tergantung pada stabilitas layanan API. Meskipun kelemahan-kelemahan yang telah diuraikan diatas merupakan hal yang fatal namun masalah ini bisa diatasi dengan melakukan mash-up ke beberapa layanan sejenis, sehingga faktor ketergantungan website terhadap sebuah layanan API bisa dikurangi. Tetapi dengan cara tersebut muncul permasalahan baru yaitu diperlukan extentibelity (kemampuan aplikasi untuk dikembangkan) yang memadai, sehingga jika sewaktu-waktu salah satu service dihilangkan atau ditambahkan, tidak memerlukan waktu dan biaya yang tinggi untuk melakukan proses perbaikan maupun reproduksi. Dari uraian diatas maka dalam proposal tugas akhir ini akan dibahas mengenai pembuatan website dengan layanan pembuatan slide gambar dalam bentuk video yang mana website ini akan melakukan mash-up ke tiga layanan API yaitu Flickr (www.flickr.com) dan Webjay (webjay.org) yang dijadikan sebagai sumber gambar dan YouTube (www.youtube.com) yang dijadikan sebagai tempat penyimpanan video. Point utama yang akan dibahas dalam proposal tugas akhir ini adalah melakukan desain dan implementasi abstraksi business logic sehingga aplikasi website yang dibuat mempunyai availability (ketersediaan layanan secara penuh selama rating waktu tertentu) dan extentibelity memadai dengan tujuan untuk menunjang kebutuhan terhadap stabilitas layanan website dan menekan biaya perbaikan dan reproduksi.

Rumusan Masalah Dari uraian diatas maka dalam proposal tugas akhir yang berjudul “Perencanaan Abstraksi Mash-Up Business Logic pada Aplikasi Slide Gambar Online” dapat dirumuskan masalah yaitu, bagaimana mendesain aplikasi slide gambar online dengan melakukan mash-up ke tiga website (Flickr, Webjay dan YouTube) yang mana website yang dibuat harus mempunyai availability dan extentibelity memadai dengan tujuan untuk menunjang kebutuhan terhadap stabilitas layanan website dan menekan biaya perbaikan dan reproduksi?

Tujuan Tujuan dibuatnya proposal tugas akhir ini adalah untuk membuat aplikasi slide gambar online yang mempunyai extentibelity dan availability memadai untuk mendukung kinerja aplikasi, sehingga diharapkan aplikasi web yang dibuat bisa menguntungkan dari sisi pembuatan dan bisa memberikan kenyamanan layanan dan menarik banyak minat pengunjung.

Manfaat Manfaat dibuatnya proposal tugas akhir ini, ditujukan kepada rekan-rekan mahasiswa atau pengembang (developer) yang tertarik untuk membuat aplikasi dengan layanan memadai dan dana yang bisa ditekan seminimal mungkin. Adapun hal-hal yang akan didapat adalah sebagai berikut: Menambah pengetahuan dibidang desain aplikasi N-Tier dengan dukungan extentibelity dan availability memadai. Menambah pengetahuan di bidang desain aplikasi dengan pola, khususnya pola Abstract, Adapter dan Template Methode.

Ruang Lingkup dan Batasan masalah Karena luasnya permasalahan yang disajikan diatas, maka untuk membuat pembahasan yang lebih terfokus maka permasalahan dibatasi sebagai berikut: Desain aplikasi digambarkan dengan diagram UML (Unified modelling language) dengan alasan untuk memudahkan dalam desain aplikasi N-Tier dan memudahkan dalam menggambarkan pola Abstract, Adapter dan Template Methode, yang digunakan untuk abstraksi. Implementasi mash-up service hanya pada Flickr, Webjay dan YouTube yang mana alasan memakai ketiga service ini adalah pada layanan API yang mendukung standar REST (representational state transfer). Untuk melengkapi testing extentibelity dan availability maka dibuat 3 buah service lokal, yaitu UrRemote Image, UrREmote List, dan UrRemote Video. Yang mana proses pembuatan service tersebut tidak akan dibahas dalam tulisan ini. Aplikasi web ditempel (dengan iframe) pada CMS Media Wiki dengan alasan suatu saat aplikasi akan dikembangkan sebagai aplikasi yang bisa di sharing. Sehingga pengembang (developer) lain bisa menempelkan aplikasi ini di website yang dibuat. Dan manajemen (otentikasi dan otorisasi) user sepenuhnya diserahkan pada CMS Media Wiki. Manajemen proses untuk melayani beberapa permintaan pembuatan video dari beberapa client secara bersamaan digunakan dengan Thread Pool tanpa prioritas, dengan alasan tidak ada otorisasi spesifik yang dipakai oleh aplikasi yang memungkinkan diperlukannya prioritas. Bahasa yang digunakan untuk Presentation Layer adalah BXML (Backbase Extensible Markup Language) dengan alasan BXML adalah bahasa client scrip berbasis AJAX (Assyncrhonous JavaScript And XML) yang tidak tergantung pada server base language, sehingga diharapkan kinerja aplikasi di sisi client akan lebih baik. Bahasa yang digunakan untuk Business Logic adalah bahasa C# dengan alasan .Net Framework khususnya bahasa C# memiliki kemampuan dalam membuat server side web programming yang cukup baik dan mudah, disamping itu mempunyai dukungan penuh terhadap reflection yang mana hal ini bisa diakali untuk memudahkan dalam proses abstraksi aplikasi. Tidak akan membahas masalah aspek keamanan pada client side application, server side application dan komunikasi data di protokol HTTP. Karena hal tersebut akan membuat pembahasan jauh menyimpang dari rumusan masalah. Untuk melakukan kompresi video dari gambar ke WMV akan menggunakan COM (Component Object Model) Windows Media Format 9.0 yang mana library ini menyediakan fasilitas Video Image yang bisa menghasilkan slide show gambar. Disamping itu juga bertujuan untuk membuat video yang bersifat standar. Sehingga jika suatu saat dilakukan penambahan Video Service hanya diperlukan proses konversi ke video yang didukung. Untuk kompatibelitas dengan YouTube maka video WMV yang sudah di hasilkan dikonversikan kedalam bentuk MPEG2, dengan bantuan COM (Component Object Model) DirectShow dan Filter Elecard MPEG2 Encoder.

5/16/2012 7:55 PM

3 dari 23


Sistematika Pembahasan Adapun sistematika penulisan Proposal Tugas Akhir yang berjudul “Perencanaan Abstraksi Mash-Up Business Logic pada Aplikasi Slide Gambar Online” adalah sebagai berikut : BAB I PENDAHULUAN Berisi secara lengkap gambaran umun isi tulisan, di mulai dari latar belakang, rumusan masalah, tujuan, manfaat, ruang lingkup dan batasan masalah dan sistematika penulisan. BAB II TINJAUAN PUSTAKA Berisi teori-teori penunjang yang diperlukan dalam perancangan dan pembangunan dari aplikasi slide gambar online. Yang meliputi Teori UML (Unified Modelling Language), Teori ERD (Entity Relationship Diagram), Teori Web Service yang menyangkut REST dan SOAP. Teori Pola Desain Perangkat Lunak (Software Design Pattern). Teori Desain Aplikasi yang meliputi Nilai Kelayakan Perangkat Lunak dan Aplikasi Terdistribusi (Distributed Application). BAB III METODE Berisi pembahasan secara detail tentang perancangan dan pembangunan dari aplikasi slide gambar online yang meliputi tempat dan waktu penelitian, data, rancangan aplikasi slide gambar online.

BAB II DASAR TEORI Web Service Perkembangan web service berasal dari kebutuhan terhadap RPC (Remote Procedure Call) yang semakin hari semakin berkembang seiring dengan berkembangnya bahasa pemrograman. Dengan digunakan pemrograman berorientasi objek (PBO), maka RPC tidak relevan lagi digunakan dalam hubungannya dengan PBO, karena penekanan dalam PBO adalah hubungan atau komunikasi pesan (messege) antara satu objek dengan objek lain. Perkembangan selanjutnya dari RPC adalah Remote Method Invocation (RMI) yang merupakan istilah dari bahasa java (remoting dalam .Net), untuk melakukan pertukaran messege (invocation) antar remote object. RMI mempunyai beberapa kelebihan yaitu kecepatan dan performa, tetapi mempunyai kekurangan dalam interopability (kemampuan dalam melakukan operasi antar platform), kekurangan ini bisa dijelaskan karena RMI tidak memakai suatu standar yang resmi dalam protokol maupun skema data yang dipakai. Sehingga dalam penerapannya RMI yang dibuat dalam bahasa java hanya bisa dipanggil oleh aplikasi java. Demikian juga dengan RMI yang dibuat dengan .Net (remoting) hanya bisa dipanggil dari aplikasi .Net. Web service adalah cara untuk mengintegrasikan aplikasi web menggunakan standar XML, SOAP, WSDL dan UDDI yang berjalan di Protokol Internet (IP), yang bertujuan untuk memberikan interopability yang lebih tinggi. (Beal, 2005) XML (Extensible Markup Language) adalah spesifikasi standar yang dibakukan oleh W3C (World Wide Web Consortium), yang secara khusus di desain untuk dokumen web. XML memberikan kebebasan kepada desainer untuk menentukan sendiri tag-tag data seperi halnya HTML-Tag. Sehingga hal ini akan memudahkan dalam pemahaman definisi data, transmisi data, validasi data dan interpretasi data antar aplikasi dan perusahaan. SOAP (Simple Object Access Protocol) adalah sebuah protokol pemaketan data XML dalam web service, baik itu akan digunakan sebagai request maupun response. SOAP sangat tergantung dari sistem operasi dan protokol pengiriman (transport protocol) yang digunakan. Adapun protokol pengiriman yang didukung adalah SMTP, MIME dan HTTP. WSDL (Web Service Description Language) adalah suatu bahasa dalam format XML yang digunakan untuk menggambarkan isi dan kemampuan web service dalam pertukaran pesan. WSDL adalah bahasa yang digunakan oleh UDDI dalam memberikan definisi metadata dari sebuah web service. UDDI (Universal Description, Definition and Integration) adalah direktori terdistribusi berbasis web, yang memungkinkan sebuah proses bisnis (business process) atau logika bisnis (business logic) untuk mendaftarkan dirinya, atau menemukan logika bisnis lain dalam internet. Dalam dunia nyata UDDI bisa dikatakan sebagai katalog dari logika bisnis di internet. Meskipun web service mempunyai keunggulan dalam interopability, pada beberapa permasalahan RMI masih mempunyai keunggulan. Salah satunya RMI bisa mendukung pola observer sehingga memungkinkan sebuah hubungan remote object mendukung pemrograman event drivent. Disamping itu karena sifat hubungan antar remote object pada web service memakai hubungan loosely coupled maka dalam web service setiap kali sebuah method (fungsi yang melekat pada objek) dipanggil, pada saat itu pula objek web service dibuat. Hal ini berakibat pada kesulitan dibuatnya sebuah objek singleton (objek yang hanya boleh mempunyai satu instance selama siklus hidup aplikasi). Web service dikategorikan mejadi dua menurut jenisnya yaitu REST Representational State Transfer) dan SOAP (Simple Object Access Protocol), yang masing-masing mempunyai kelemahan dan keunggulan.

REST (representational state transfer) REST adalah salah satu jenis web service sederhana. Sesuai dengan namanya, dalam REST setiap URL yang tersedia mewakili sebuah atau beberapa objek. Karena REST adalah tipe web service yang paling sederhana maka hanya bisa diakses dengan protokol HTTP, dengan fungsi GET, POST, PUT atau DELETE. Adapun spesifikasi kelebihan dan kekurang REST adalah sebagai berikut : Pesan (message) diwakili oleh xml sederhana tanpa ada protokol pemaketan data seperti halnya SOAP. Sehingga informasi yang diterima lebih mudah dibaca dan diparsing di sisi client. Pada sisi server tidak diperlukan program untuk melayani setiap permintaan atau manipulasi data dari client. Pengamanan data sepenuhnya diserahkan pada protokol HTTP. Untuk proses akses data dilakukan dengan memakai verb HTTP seperti GET, POST, PUT dan DELETE. Tidak ada fungsi atau metode formal yang bisa diwakili oleh kontrak sebuah interface. Sehingga Dalam pengaplikasiannya REST lebih banyak digunakan karena sifatnya yang sederhana dan lebih mudah dalam pembuatan maupun pengembangannya.

5/16/2012 7:55 PM

4 dari 23


Beberapa contoh web service REST yang dipakai oleh website-website terkenal adalah: Flickr API, YouTube API, Amazon API, Webjay API.

SOAP (Simple Object Access Protocol) SOAP bisa dikatakan sebagai implementasi web service yang lebih mapan, dengan memakai beberapa standarisasi dari W3C, sehingga mempunyai interopability yang lebih tinggi. Permasalahan awal dari perkembangan SOAP web service adalah pembuatan program di bagian client dan server yang bisa dikatakan cukup sulit. Tapi dengan bantuan tools dari beberapa developer, seperti Visual Studio, membuat sebuah SOAP web service menjadi lebih gampang, sehingga sangat membatu dalam pembuatan dan pengembangan. Beda halnya dengan REST, SOAP web service lebih menekankan pada akses objek secara sederhana dibandingkan dengan transfer objek yang diwakili oleh sebuah URL. Sehingga bahasa pemrograman terlihat lebih nyata dengan SOAP web service. Yang mana sekema ataupun kontrak dari objek digambarkan secara jelas oleh WSDL dalam format XML schema. Adapun spesifikasi kelebihan dan kekurangan dari SOAP web service adalah sebagai berikut : Pesan (message) dipaket dalam standarisasi SOAP envelope. Yang mana pada header paket bisa disisipi dengan otentikasi dan pengamanan yang dibuat sendiri. Tidak hanya bisa memakai protokol HTTP tapi juga bisa juga berjalan di SMPT atau MIME. Cara akses dan manipulasi data tergantung web service. Pengamanan dan Autentikasi data dilakukan sepenuhnya oleh aplikasi di server. Metode dan struktur kelas, secara formal digambarkan oleh WSDL dalam sekema XML. Karena pembuatan dan pengembangan SOAP web service cukup memakan biaya maka hingga saat ini masih sedikit perusahanperusahaan yang memakai SOAP web service. Beberapa contoh SOAP web service adalah Google API, Yahoo! API, del.icio.us

Pola Desain Perangkat Lunak (Software Design Pattern) Design pattern adalah sebuah istilah bahasa Inggris dalam rekayasa perangkat lunak yang mengacu kepada solusi umum yang dapat digunakan secara berulang kali untuk menyelesaikan masalah-masalah umum yang ditemukan dalam disain perangkat lunak. Sebuah design pattern tidak berbentuk solusi akhir yang dapat langsung diterjemahkan menjadi kode program. Design pattern merupakan penjelasan atau template yang menunjukkan bagaimana cara menyelesaikan sebuah masalah yang kemudian dapat digunakan di berbagai situasi yang berbeda-beda. Design pattern untuk object-oriented biasanya menunjukkan relasi dan interaksi antar kelas dan objek, tanpa menjelaskan kelas dan objek akhir yang terlibat dalam sebuah aplikasi. Algoritma biasanya tidak disebut sebagai design pattern, karena algoritma menjadi solusi masalah komputasi bukan masalah disain. Design pattern banyak dikembangkan oleh GoF (Gang of Four). Dalam bukunya, design pattern dikategorikan menjadi empat tergantung kegunaannya. Yaitu Creational Patterns, Structural Patterns, dan Behavioral Patterns. Creational Patterns. Abstract Factory, Builder, Factory Method, Prototype, dan Singleton Structural Patterns: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy Behavioral Patterns: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

Penilaian Kelayakan Perangkat Lunak Penilaian kelayakan sistem meliputi standar kelayakan suatu aplikasi. Adapun hal-hal yang menjadi poin penilaian adalah : Scalability Scalability adalah kemampuan sebuah aplikasi dalam memberikan performa secara keseluruhan, jika sebuah atau beberapa faktor pembeban ditambahkan. Faktor pembebanan umumnya meliputi banyaknya pemakai, jumlah data yang sedang diatur oleh aplikasi, dan banyaknya transaksi. Performa dapat dilihat dari jumlah beban dan respon waktu yang diberikan oleh aplikasi. Jumlah beban diukur dari jumlah pekerjaan yang bisa dilakukan oleh suatu aplikasi dalam batasan waktu yang telah ditentukan. Sedangkan respon waktu adalah selang waktu yang dibutuhkan antara seorang pemakai dalam meminta proses dan menerima hasil yang diminta. Availability Adalah kemampuan sebuah aplikasi dalam menyediakan layanan dalam semua kondisi yang mungkin terjadi. Tidak bisa dipungkiri bahwa program yang paling robust pun kadang-kadang tidak bisa menyediakan layanan. Maka sebuah aplikasi harus didesain secara hati-hati sehingga resiko yang terjadi untuk kejadian-kejadian yang tidak terduga bisa diperkecil. Contohnya, sebuah aplikasi harus tetap bisa digunakan pada fungsi-fungsi tertentunya jika satu atau beberapa service tidak bisa beroperasi, baik itu karena perbaikan atau terjadi kesalahan teknis. Maintainability Adalah nilai kemudahan sebuah aplikasi dalam proses perbaikan. Sebuah aplikasi yang baik harus bisa diperbaiki dengan mudah. Desain yang benar dan sejauh mana sebuah aplikasi harus di pecah menjadi bagian-bagian yang berdiri sendiri sangat membantu dalam perbaikan. Disamping itu proses pembuatan kode program yang baik dan konsisten baik itu dalam hal pemberian nama variabel, fungsi, kelas atau namespace, akan sangat membantu dalam perbaikan.

5/16/2012 7:55 PM

5 dari 23


Security Adalah kemampuan sebuah aplikasi dalam menjaga keamanan privasi dan otoritas layanan yang disediakan. Privasi bisa dikatakan sebagai kemampuan aplikasi dalam memanajemen data-data yang tidak berhak diakses oleh pengguna lain yang masih dalam suatu level. Sedangkan otoritas adalah kemampuan sebuah aplikasi dalam memanajemen hak akses terhadap fungsi atau proses menurut level pengguna. Manageability Adalah nilai kemudahan aplikasi dalam proses manajemen. Sebuah aplikasi yang baik harus menyediakan tools yang bisa digunakan untuk memonitor kesehatan aplikasi secara teknis, fungsi backup data yang memadai, fungsi untuk perluasan baik itu perluasan data maupun perluasan sub aplikasi dan lain-lain. Performa Adalah kemampuan aplikasi dalam memberikan kecepatan sebuah proses. Lain halnya dengan scalability performa lebih menekankan pada kecepatan dan optimasi masing-masing layanan atau proses. Optimasi bisa didapat dengan melakukan desain aplikasi yang benar, sehingga didapat sebuah kode program yang optimal, yang mana antara faktor maintainability dan scalability tetap harus dijaga. Sebuah aplikasi yang mudah diperbaiki biasanya akan dipecah menjadi beberapa bagian, logikanya semakin banyak dipecah semakin mudah untuk diperbaiki, tetapi tidak demikian halnya dengan scalability yang akan lebih baik jika aplikasi tidak dipecah.

Tingkatan Aplikasi (Application Tier) Sebuah aplikasi yang mudah diperbaiki biasanya akan dipecah menjadi beberapa bagian, logikanya semakin banyak dipecah semakin mudah untuk diperbaiki, tetapi tidak demikian halnya dengan scalability yang akan lebih baik jika aplikasi tidak dipecah. Sebuah program aplikasi yang baik adalah aplikasi yang bisa dikembangkan pemakaiannya, disamping itu maintenance yang akan dilakukan tidak merepotkan. Maka dalam pembuatan sebuah aplikasi perlu dilakukan pembagian tingkatan – tingkatan objek untuk memudahkan pengembangan dan maintenance. Tingkatan-tingkatan dalam sebuah aplikasi tersebut diistilahkan sebagai TIER. Multi tier application adalah sebuah cara dalam membuat program basis data yang mana objek-objek aplikasi tersebut dibagi dalam beberapa tingkatan tergantung dari keperluan. Secara logika semakin banyak tingkatan yang dibuat semakin mudah untuk dikembangkan dan maintenance-nya tetapi akan memboroskan pekerjaan dan menurunkan performa aplikasi tersebut. Jadi sebelum kita memutuskan untuk membuat sebuah Multi Tier Application perlu dipertimbangkan sejauhmana program tersebut akan digunakan dan seberapa banyak tingkatan objek yang diperlukan. Menurut tingkatannya Multi Tier Application dibagi menjadi tiga yaitu Two Tier Application, Three Tier Application dan N Tier Application. Yang masing-masing mempunyai keunggulan dan kelemahan tersendiri.

BAB III METODE Tempat dan Waktu Penelitian Penelitian dilakukan di Laboratorium Komputer Universitas Udayana, dari bulan Januari sampai Maret 2007.

Data Sumber data Data yang digunakan dalam perancangan dan implementasi aplikasi ini, diperoleh melalui studi kepustakaan, yaitu melalui studi literatur mash-up dan data yang didapat secara langsung dari penelitian di lapangan.

Jenis data Data yang digunakan dalam penelitian berupa data primer, yang didapat dengan cara melakukan pengamatan atau percobaan.

Metode Pengumpulan Data Pengumpulan data yang diperlukan, dilaksanakan dengan beberapa metode, antara lain : Metode Observasi Yaitu melakukan pengumpulan data berdasarkan pengamatan dari hasil percobaan yang telah dilakukan. Metode Studi Literatur Menganalisa data yang diperoleh sehingga akan diperoleh suatu kesimpulan yang lebih terarah pada pokok pembahasan.

Rancangan Sistem Rancangan aplikasi akan dibagi dalam beberapa tahap, yang mana masing-masing tahap mempunyai hubungan yang cukup erat dan saling berhubungan, sehingga tahap kedua adalah lanjutan dari tahap pertama, tahap ketiga adalah lanjutan dari tahap kedua dan seterusnya. Adapun tahapan rancangan sistem adalah: Studi Kelayakan Sistem, Fase Pemodelan Usecase, Fase Pemodelan Domain Sistem, Fase Desain Sistem, Fase Pemodelan Implementasi Sistem dan Metode Test Driven.

Sasaran pengembangan aplikasi Untuk mendapat aplikasi yang sesuai dengan tujuan, maka sebelum melakukan desain sistem secara keseluruhan, ditentukan syarat minimal kehandalan aplikasi yang harus dicapai. Tidak semua aspek kehandalan aplikasi dipakai sebagai acuan dalam aplikasi ini. Adapun aspek-aspek yang harus dicapai adalah sebagai berikut: Aspek Scalability

5/16/2012 7:55 PM

6 dari 23


Untuk memenuhi target scalability maka aplikasi harus bisa melakukan manajemen proses untuk beberapa user dengan benar. Pemecahan untuk kasus ini dilakukan dengan melakukan pendaftaran proses-proses besar kedalam sebuah thread pool, sehingga untuk beberapa proses yang mempunyai waktu eksekusi lama bisa berjalan simultan dengan interaksi yang dilakukan user dan tidak mengganggu kerja di sisi presentasi. Adapun pencarian besar kecilnya proses dan penggambilan keputusan untuk mendaftarkan sebuah proses ke thread pool, akan dilakukan dalam proses desain. Aspek Extensibility dan Availability Salah satu kelemahan aplikasi yang memakai mash-up sebagai layanan utama adalah pada aspek availability, karena ketersediaan layanan sepenuhnya tergantung dari mash-up service yang dipakai. Untuk memecahkan masalah tersebut maka dilakukan pengembangan program dengan aspek extensibility tinggi. Untuk kedepannya aplikasi akan melakukan mash-up dengan beberapa mash-up service sejenis sehingga jika salah satu mash-up service tidak berfungsi maka user masih bisa memakai aplikasi dengan memakai layanan mash-up yang lain. Peran extentibelity disini adalah membuat aplikasi yang mudah dikembangkan tanpa melakukan compile ulang program secara keseluruhan. Untuk memecahkan kasus tersebut maka aplikasi akan didesain untuk bisa menerima add-ins yang akan menghubungkan antara aplikasi dengan mash-up service. Sehingga jika dilakukan penambahan fungsi layanan baru (image maupun movie) pihak pemrogram hanya perlu membuat sebuah add-ins (berupa file library dalam format .Net assembly) dan mendaftarkannya pada aplikasi, tanpa melakukan compile ulang pada program utama. Aspek Maintainability Aplikasi yang baik adalah aplikasi yang bisa diperbaiki dengan mudah, salah satu faktor penting dalam mudah tidaknya sebuah aplikasi untuk diperbaiki adalah pada pelaporan kesalahan (error report) yang benar dan terstruktur. Untuk memecahkan masalah ini maka pelaporan kesalahan dalam aplikasi akan dilakukan dengan mengkategorikan jenis kesalahan menjadi beberapa bagian sesuai dengan keperluan dan tipe kesalahan. Disamping itu pelaporan kesalahan program harus dilengkapi dengan bagian modul yang mengalami kesalahan, sehingga web-master yang melakukan perbaikan program akan bisa melakukan analisa penyebab kesalahan yang terjadi dengan mudah. Pelaporan kesalahan pada aplikasi ini akan dibuat dalam bentuk file xml. Performance Performance adalah salah satu aspek penting dalam menarik minat pemakai, sebuah aplikasi dengan respon yang wajar cenderung lebih membuat nyaman dibandingkan sebuah aplikasi dengan tampilan indah tapi mempunyai respon yang lambat. Untuk memecahkan masalah ini maka aplikasi akan dikembangkan dengan memakai teknologi AJAX framework BXML (Backbase Extensible Markup Language), sehingga diharapkan dengan memakai AJAX respon aplikasi di sisi client akan meningkat, dengan mengabaikan beberapa kelemahan AJAX seperti waktu loading data di awal aktivasi aplikasi dan Infinite Assyncrhonous Loading. Yang bisa diterima sebagai cacat teknologi. Karena tidak semua perangkat lunak yang dikembangkan bisa memenuhi semua aspek kehandalan aplikasi secara sempurna, maka dalam aplikasi ini ditentukan beberapa aspek yang tidak menjadi target pengembangan aplikasi. Adapun aspek-aspek tersebut adalah sebagai berikut: Aspek Manageability Aspek manageability tidak menjadi target dalam aplikasi ini karena aplikasi tidak diharapkan untuk bisa dimanajemen secara spesifik. Hal ini disebabkan karena aplikasi dikembangkan sebagai sebuah layanan publik, sehingga jika dilakukan proses manajemen (dalam hal ini manajemen user), maka aplikasi akan cenderung menjadi sebuah aplikasi yang mempunyai privasi dengan hak akses yang berbeda-beda. Disamping itu juga user akan merasa lebih nyaman jika memakai fasilitas sebuah layanan internet tanpa melakukan registrasi account yang cukup memakan waktu. Untuk permasalahan penyalahgunaan sumber daya oleh orang-orang yang tidak berhak sudah dilakukan oleh mash-up service bersangkutan. Sebagai contoh seorang user yang ingin melakukan upload video atau melakukan pengambilan foto yang bersifat privat harus memasukkan user name dan password mash-up service bersangkutan. Sehingga permasalahan penyalahgunaan sumberdaya sudah dipecahkan oleh mash-up service bersangkutan. Aspek Security Dengan tidak mengikutkan aspek security dalam aplikasi bukan berarti aplikasi yang dibuat adalah sebuah aplikasi yang sama sekali tidak aman. Tetapi proses pengamanan data sepenuhnya dipercayakan kepada mash-up service bersangkutan. Dalam aplikasi yang dibuat terdapat dua buah faktor yang menjadi lubang besar dalam masalah security yaitu: Password tidak disandikan dalam pengiriman data dari client ke server dan masalah kepercayaan dalam pemberian username dan password. Untuk permasalahan pertama bisa dijelaskan sebagai berikut, username dan password yang dimasukkan user tidak disandikan disisi client dan dikirim sepenuhnya dalam bentuk plain text. Hal ini disebabkan karena BXML tidak menyediakan fungsi untuk melakukan penyandian data yang dikirim, dan seandainya dibuat sebuah fungsi untuk penyandian data maka diperlukan sebuah modul dengan desain dan analisa terpisah diluar dari batasan aplikasi yang dibuat. Dan merupakan hal yang sia-sia jika dilakukan penyandian secara sederhana tanpa ada desain dan analisa yang berarti. Untuk permasalahan ke dua bisa dijelaskan sebagai berikut: Aplikasi tidak bisa memberikan tanggung jawab secara nyata apakah username dan password untuk mash-up service bersangkutan tidak disalah gunakan oleh aplikasi. Hal ini merupakan kasus yang sering terjadi dalam aplikasi mash-up. Pemecahan kasus ini dilakukan dengan cara membuat sebuah username dan password default untuk masing-masing mash-up servcie sehingga untuk user yang tidak percaya, bisa memakai account default aplikasi ini.

Fase pemodelan usecase Fase pemodelan usecase adalah fase pertama dalam desain aplikasi dengan UML. Dalam fase ini akan dijelaskan tentang gambaran umum sistem, desain tampilan program, penggalian usecase, pembuatan usecase diagram dan penjelasan beberapa fungsi-fungsi penting dengan activity diagram. Adapun langkah selengkapnya adalah sebagai berikut: Gambaran umum sistem

5/16/2012 7:55 PM

7 dari 23


Secara singkat aplikasi yang akan dibuat bisa dijelaskan sebagai berikut, aplikasi yang dibuat adalah aplikasi yang bisa menghasilkan slide gambar (sebuah video yang menampilkan beberapa gambar statis yang ditampilkan dalam bentuk slide) dari beberapa gambar yang ada. Adapun sumber gambar dan tempat penyimpanan video memanfaatkan fasilitas yang sudah disediakan oleh situs-situs terkenal. Dalam hal ini website yang dipakai adalah: www.flickr.com yang dipakai sebagai sumber gambar dan www.youtube.com yang dipakai sebagai tujuan penyimpanan video. Seperti ditunjukkan pada gambar berikut:

Pemodelan input, output dan proses Seperti yang disampaikan diatas, aplikasi akan melakukan pengambilan gambar dari image mash-up service, dalam hal ini diambil dari www.flickr.com dengan memanfaatkan webservice REST yang sudah disediakan oleh flickr untuk keperluan mash-up. Untuk kedepannya aplikasi didesain untuk bisa dikembangkan menjadi aplikasi yang bisa mengambil gambar dari situs-situs terkenal lain seperti www.friendster.com, picture.aol.com dan yang lainnya. Yang mana dengan penambahan fungsi tersebut pemrogram tidak perlu melakukan compile ulang pada keseluruhan aplikasi, tetapi cukup dengan membuatkan sebuah Add-Ins dalam format assembly .Net yang akan menjadi perantara antara aplikasi dan mash-up service bersangkutan. Proses yang dilakukan oleh aplikasi adalah melakukan konversi dari gambar-gambar yang didapat dari mash-up service tersebut menjadi sebuah video slide gambar. Secara spesifik proses konversi tersebut seperti ditunjukkan pada gambar berikut:

Pemodelan proses kompatibility pada pembuatan video / list Dari gambar diatas bisa dilihat bahwa proses pembuatan video terdiri dari dua langkah yang terpisah yaitu Images To WMV dan Compatibility. Alasan dilakukan pemisahan proses tersebut bisa dijelaskan sebagai berikut, konversi awal dari gambar ke WMV (windows media video) bertujuan untuk membuat sebuah video yang bersifat umum, baik itu untuk diterima di movie mash-up service tempat upload vidoe maupun untuk proses konversi kompatibilitas yang bisa diterima di movie mash-up service tujuan. Proses kompatibiliatas bertujuan untuk melakukan penyesuaian terhadap video yang bisa diterima pada movie mash-up service tujuan, karena kedepannya movie mash-up service bisa lebih dari satu. Sebagai contoh penerapannya pada www.youtube.com video WMV yang dihasilkan oleh proses Images To WMV tidak memberikan hasil yang optimal pada video hasil yang ditampilkan oleh youtube, dan mungkin saja hasilnya akan berbeda lagi untuk situs tujuan yang lain. Hal inilah yang menyebabkan mengapa dipilih WMV sebagai video awal dari proses yang terjadi, karena WMV adalah sebuah video yang bersifat universal di sistem operasi Windows, untuk melakukan konversi ke jenis video lain sudah tersedia filter directshow (dengan lisensi gratis) untuk melakukan load dan proses konversi ke jenis video lain. Disamping itu windows mempunyai library COM Windows Media Format Video Image yang bisa melakukan konversi dari gambar ke WMV tanpa harus mengetahui format kompresi WMV. Dalam tulisan ini proses kompatibilitas dengan youtube dilakukan dengan melakukan konversi video dari WMV ke MPEG2. Untuk proses upload data ke youtube sebenarnya terdapat sebuah hambatan karena youtube tidak menyediakan API untuk melakukan upload data. Maka disini dilakukan proses yang dikenal dengan istilah web roboting. Secara umum proses web roboting untuk upload data ke youtube adalah melakukan request manual melalui protokol HTTP ke server youtube, baik itu untuk login, pemesanan tempat upload server, dan proses pengiriman data. Secara resmi youtube tidak memberikan aturan tertulis tentang pemakaian web robot untuk proses upload video, aturan yang jelas tertulis adalah pembatasan terhadap upload data yang hanya boleh maximum 100 Mb setiap kali kirim, asalkan masih memakai account resmi yang sudah terdaftar di youtube. Sehingga masalah legal tidak legalnya pemakaian web robot pada proses upload data ini bisa diabaikan. Untuk memperjelas pemodelan keseluruhan blok aplikasi dan manajemen interaksi untuk masing-masing jenis user bisa dilihat pada gambar berikut:

5/16/2012 7:55 PM

8 dari 23


Gambaran umum sistem Dari gambar diatas bisa dilihat bahwa dalam aplikasi terdapat tiga jenis user yaitu User (pemakai biasa), Web Master dan Extensibility Programmer, yang masing-masing mempunyai interaksi berbeda-beda terhadap aplikasi. Dari gambar juga bisa dilihat add-ins dibagi dalam dua kelompok umum yaitu Images dan Movie, yang mana untuk jenis add-ins yang bertugas untuk melakukan pengambilan gambar ke mash-up service harus mempunyai sifat umum sesuai dengan kontrak yang ada pada add-ins images. Demikian juga halnya dengan add-ins movie, harus mengikuti kontrak yang ada pada kontrak add-ins movie. Desain tampilan aplikasi (user interface) Desain tampilan aplikasi bertujuan untuk memperlihatkan dan memperjelas fungsi-fungsi apa saja yang ada dan mungkin diperlukan oleh aplikasi. Disamping itu juga penamaan bagian-bagian tampilan sangat penting untuk memudahkan pembuatan kode program. Dalam penerapannya bentuk tampilan aplikasi bisa saja berbeda dengan apa yang ada dalam desain, selama fungsi aplikasi tidak berubah.

Tampilan program utama

Gambar diatas menunjukkan aplikasi terdiri dari dua bagian yang terpisah yaitu Image Pallete dan Image Roll. Image Pallete adalah daftar gambar yang diperoleh dari image mash-up service dengan metode pencarian tertentu. Image Basket (terdiri dari gambar dan subtitle) pada Image Pallete bersifat statis yaitu tidak bisa didelete, diedit maupun di pindah-pindah. Dalam hal ini Image Pallete bertugas menjadi penyedia gambar untuk Image Roll. Image Roll adalah daftar gambar yang akan dijadikan video, user bebas melakukan perubahan posisi gambar dengan cara drag-drop,

5/16/2012 7:55 PM

9 dari 23


yang mana image basket-nya didapat dari image pallete. Untuk menghapus image basket yang tidak diinginkan bisa dilakukan dengan menekan tombol Remove Button bisa juga dengan menekan tomboh Delete di keyboard. Aplikasi akan menyediakan tiga buah history untuk film yang telah dibuat. History adalah daftar video yang sudah dibuat oleh masingmasing user, baik itu yang sukses, dalam pengerjaan maupun yang gagal. Meskipun manajemen user tidak dipakai dalam aplikasi, user bisa membuat video yang bersifat privat. Meskipun dalam list history nama video tersebut kelihatan tetapi user yang tidak berhak tidak akan bisa melakukan navigasi ke video tersebut karena youtube secara otomatis menentukan hak akses dari masing-masing video. Untuk lebih jelasnya bentuk masing-masing history bisa dilihat pada gambar berikut:

Tampilan dialog history untuk film atau list yang sukses Dari gambar diatas bisa dilihat terdapat tiga kolom utama dalam success history yaitu Owner, Title dan Destination yang mana title berupa sebuah hyperlink yang bisa melakukan redirect ke video bersangkutan. Destination menunjukkan website tempat video tersebut di upload, untuk kedepannya hal ini akan berguna jika jumlah movie mash-up service sudah lebih dari satu. Filter yang disediakan untuk kolom owner dan title bertujuan untuk menampilkan data tertentu sesuai keinginan pemakai.

Tampilan dialog history untuk film atau list yang masih dalam proses pembuatan Untuk On Progress History bentuknya hampir sama dengan success history yang membedakan adalah adanya kolom status dan title yang bukan berupa hyperlink. Kolom status menunjukkan proses yang sedang terjadi pada video bersangkutan. Adapun status yang ada adalah: Queued: menunjukkan video sudah masuk dalam antrian thread pool tapi belum diproses. Creating: menunjukkan video sedang dibuat ke dalam bentuk WMV Compatibility: menunjukkan video sedang dalam proses konversi ke bentuk video lain (dalam hal ini ke bentuk MPEG2) Uploading: menunjukkan video sedang dalam proses di kirim ke server movie mash-up service tujuan.

5/16/2012 7:55 PM

10 dari 23


Tampilan dialog history untuk film atau list yang gagal dibuat Failed History adalah daftar film-film yang gagal dibuat karena alasan tertentu. Penjelasan mengenai kegagal film bisa dilihat pada kolom description. Untuk melakukan interaksi dengan mash-up service disediakan Hud (dialog tambahan) untuk masing-masing mash-up service. Field isian disesuaikan dengan mash-up service bersangkutan. Seperti ditunjukkan gambar berikut:

Tampilan Hud untuk pembuatan film dengan YouTube Gambar diatas menunjukkan Hud yang digunakan untuk melakukan interaksi dengan youtube. Beberapa field yang tersedia disesuaikan dengan field-field isian yang dibutuhkan untuk melakukan upload video ke youtube. Untuk field isian Default User, akan dibuat sebuah account youtube yang akan digunakan jika user tidak ingin memberikan username dan passwordnya, karena alasan keamanan. Untuk default user semua video akan dibuat dalam bentuk publik.

Tampilan Hud untuk mengambil gambar dari Flickr Untuk melakukan interaksi dengan Flickr terdapat tiga kategori untuk metode pencarian gambar.

Dengan Username Adalah metode pencarian gambar yang spesifik terhadap id user. Id user bisa berupa flickr id maupun yahoo id yang terdaftar di flickr.

5/16/2012 7:55 PM

11 dari 23


Dengan Tags Tags adalah metode pencarian gambar dengan kriteria yang diisikan oleh user pada saat foto tersebut di upload. Dengan Recent Images Recent image adalah metode pencarian gambar untuk mendapatkan gambar-gambar terbaru (yang baru di upload) Gambar yang akan ditampilkan pada image pallete bisa diurut menurut Interestingness (rate foto tersebut yang didapat dari user lain). Penggalian usecase dari desain tampilan program Dalam laporan ini usecase digali dari tampilan program yang telah dibuat. Yang mana hal ini lebih mudah dilakukan dibandingkan dengan memperkirakan usecase yang diperlukan di awal desain. Dari tampilan program yang telah disajikan diatas maka dapat digali beberapa usecase sebagai berikut: tabel ------------------------------Usecase diatas digali berdasarkan interaksi yang bisa dilakukan oleh user. Masing-masing usecase yang mempunyai lingkup kecil digolongkan kedalam usecase yang mempunyai lingkup lebih besar dan dijadikan extension. Pembentukan usecase diagram Dari hasil penggalian usecase yang telah dilakukan diatas, kemudian dibentuk sebuah usecase diagram yang menunjukkan interaksi user dengan usecase bersangkutan secara kasar. Untuk lebih jelasnya berikut adalah gambaran usecase diagram yang didapat untuk memodelkan interaksi user dengan aplikasi.

Pemodelan usecase awal untuk aplikasi slide image Dari gambar diatas bisa dilihat user melakukan interaksi ke lima jenis usecase yang terbentuk. Masing-masing usecase mewakili tampilan program yang dibuat. Karena desain usecase dilakukan pada sisi abstrak maka pendefinisian usecase yang bersifat turunan (flickr dan youtube) tidak digambarkan, mengingat aplikasi didesain untuk mempunyai aspek extensibility tinggi.

Fase pemodelan domain sistem Aplikasi yang akan dibuat, akan dibuat dalam bentuk aplikasi N-Tier yang mana masing-masing lapisan aplikasi mempunyai tanggung jawab sendiri-sendiri terhadap suatu fungsi maupun suatu pemencahan kasus. Sehingga diharapkan dengan pemisahan lapisan maka aplikasi akan lebih mudah untuk diperbaiki dan dikembangkan untuk kedepannya. Dalam pemodelan domain sistem ini juga akan digali usecase-usecase yang mungkin timbul akibat pemisahan lapisan aplikasi. Dan dilakukan juga penjelasan pada fungsi-fungsi yang dianggap penting. Desain lapisan aplikasi Lapisan aplikasi yang dibuat bertujuan untuk memisahkan secara tegas, fungsi, operasi maupun tanggung jawab yang ada pada aplikasi. Disamping itu juga lapisan aplikasi akan dipakai acuan dalam pembagian namespace pada tahap pembuatan kode program. Untuk lebih jelasnya pembagian lapisan aplikasi bisa dilihat pada gambar berikut:

5/16/2012 7:55 PM

12 dari 23


Diagram lapisan aplikasi Dari gambar diatas bisa dilihat bahwa secara kasar aplikasi dibagi dalam 4 lapisan besar yaitu Presentation, Business Logic, Add-Ins dan Exception Manager untuk lapisan pendukung dibuat dalam bentuk satu lapisan yang terpisah. Penjelasan masing-masing lapisan adalah sebagai berikut: Presentation Adalah semua aspek yang berhubungan dengan tampilan program, baik itu yang akan berupa tampilan program (sub lapisan UI) maupun komponen pendukung tampilan program (sub lapisan UI Component). Penerapan dalam aplikasi Slide Image presentation sepenuhnya dibuat dengan BXML. Business logic (business object) Business object adalah jantung dari aplikasi Slide Image. Yang mana dalam aplikasi, business logic mempunyai tugas utama untuk mengolah data dan membagi-bagikan tugas kepada lapisan yang mempunyai hak untuk mengerjakannya. Dalam Business Logic terdapat lima sub lapisan yang masing-masing mempunyai tugas dan akses yang berbeda-beda. Facade biasa juga disebut sebagai Business Interface adalah lapisan (objek) yang bertugas untuk memberi bentuk sederhana terhadap keseluruhan business object. Facade memberikan akses yang mudah dimengerti kepada dunia luar untuk memodelkan sebuah pekerjaan yang rumit kedalam fungsi-fungsi sederhana, yang mana isi dan proses masing-masing fungsi tersebut tidak perlu diketahui oleh dunia diluar business object. Workflows adalah objek yang bertugas untuk mengatur urutan langkah kerja dari masing-masing komponen yang bekerja dibawahnya. Workflows mempunyai akses sepenuhnya terhadap semua komponen pendukung yang ada pada business object. Tujuan dibuatnya workflows adalah untuk untuk memisahkan persilangan operasi yang mungkin terjadi pada masing-masing fungsi yang ada dalam business object kedalam bentuk yang baku. Sehingga akan memudahkan dalam perbaikan program jika suatu saat dalam aplikasi terjadi perubahan kebijakan tentang langkah-langkah pengambilan gambar maupun proses upload video. Component, Contract dan DAL (Data Access Layer) adalah fungsi-fungsi yang mempunyai tugas khusus yang nantinya dipakai oleh add-ins maupun workflows. Component, Contract dan DAL tidak boleh mempunyai hak akses ke lapisan lain, hal ini bertujuan untuk memperkecil kemungkinan terjadinya persilangan operasi yang menyebabkan sulitnya dalam pelacakan kesalahan, perbaikan dan pengembangan program. Component adalah fungsi-fungsi kecil yang mempunyai tugas khusus seperti melakukan upload data ke protokol HTTP, konversi gambar ke WMV dan sebagainya. Contract adalah aturan (dalam bahasa program interface dan base class) yang harus diikuti oleh add-ins. Contract bertujuan untuk menyamakan bentuk operasi dan sifat dari objek add-ins sehingga mempunyai kesamaan untuk masing-masing jenis add-ins (Images atau Video). DAL (data access layer) adalah object yang bertuga untuk melakukan akses ke database. Add-Ins Add-ins digunakan sebagai penghubung antara aplikasi dan mash-up service, yang harus mengikuti kontrak tertentu sehingga bisa dibuat terpisah dan bisa diload secara real time oleh aplikasi. Add-ins sebenarnya adalah sebuah sistem kecil yang bisa juga terdiri dari presentation dan business object. Tapi karena sistem yang dibuat spesifik terhadap sebuah masalah (mendapat gambar atau upload video) maka aplikasi tidak dibagi kedalam lapisan-lapisan yang lebih kecil lagi. Exception Manager Exception manager adalah sebuah objek global yang dipakai oleh semua lapisan. Exception manager bertugas untuk melakukan pelaporan kesalahan maupun error yang terjadi pada aplikasi. Meskipun exception manager adalah sebuah objek global tapi lapisan yang berhak melakukan penangkapan dan pelaporan kesalahan adalah lapisan workflows, sedangkan lapisan lain hanya berhak untuk melakukan pelemparan (throwing) kesalahan. Komunikasi client side dan server side

5/16/2012 7:55 PM

13 dari 23


Pemodelan hubungan antara client side dan server side

Pembentukan usecase diagram sesuai dengan lapisan aplikasi

Pemodelan untuk abstraksi add-ins masing-masing mashup

5/16/2012 7:55 PM

14 dari 23


Pemodelan untuk usecase history

Penjelasan usecase dengan activity diagram

Pemodelan untuk proses pengambilan gambar ke mashup service

5/16/2012 7:55 PM

15 dari 23


Pemodelan untuk proses pembuatan list dan upload ke mashup service

Pemodelan untuk proses pembuatan film dan upload ke mashup service

5/16/2012 7:55 PM

16 dari 23


Fase pemodelan desain sistem Desain database Membuat class diagram dari usecase diagram

Pemodelan class diagram sementara sebelum masing-masing method digali

5/16/2012 7:55 PM

17 dari 23


Pemodelan asosiasi masing-masing kelas utama sebelum masing-masing method digali

Menggali method yang dipakai

Penggalian method saat inisialisasi mashup list

5/16/2012 7:55 PM

18 dari 23


Penggalian method saat inisialisasi image menu

Penggalian method saat inisialisasi list menu

Penggalian method saat inisialisasi movie menu

Penggalian method saat pembuatan list

Penggalian method saat pembuatan film

5/16/2012 7:55 PM

19 dari 23


Penggalian method saat pengambilan gambar dari image mashup

Penggalian method saat action paging di image pallete dilakukan

Penggalian method saat melakukan filter di history

Penggalian method saat aksi paging dilakukan di history

Penggalian method saat tombol refresh di klik

5/16/2012 7:55 PM

20 dari 23


Penggalian method saat history diinisialisasi

Bentuk akhir class diagram

Pemodelan class diagram secara lengkap

5/16/2012 7:55 PM

21 dari 23


Pemodelan asosiasi masing-masing kelas utama secara lengkap

Penjelasan beberapa method penting

5/16/2012 7:55 PM

22 dari 23


Penjelasan method untuk memanggil add-ins secara real time

Penjelasan pemanggilan method secara real time

Fase Pemodelan Implementasi Sistem

5/16/2012 7:55 PM

23 dari 23


Deployment diagram

Pemodelan untuk deployment aplikasi

System requirement untuk development Windows XP Profesional SP2 Visual Studio 2005 Elecard MPEG2 Encoder STD Windows Media Format SDK 9.0 Windows Flatform SDK Microsoft SQL Manajemen System express SQL server 2005 Express Backbase Community Edition 3.0 (Development) CMS Media Wiki IIS port 6666 Apache port 80 System requirement untuk server Windows XP Profesional SP2 .Net Framework 2.0 MFC shared environtment 8.0 Elecard MPEG2 Encoder STD Windows Media Player 9.0 SQL server 2005 Express Backbase Community Edition 3.0 (Production) CMS Media Wiki IIS port 6666 Apache port 80 System requirement untuk client Semua mesin yang bisa dipakai untuk browsing Semua sistem operasi yang bisa dipakai browsing Browser yang mendukung AJAX

Metode Testing Sistem Unit testing Integration testing Functional testing System testing

5/16/2012 7:55 PM

2012 7:55 PM. Latar Belakang. Collaborations > Thesis > MPEG Slidr thesis

Recommend Documents