Pembangunan framework untuk domain aplikasi kuliner

BIODATA PENULIS

  1. DATA PRIBADI

  nama : Daeng Rosanda jenis kelamin : Laki-laki tempat, tanggal lahir : Bandung, 28 Juli 1989 agama : Islam kewarganegaraan : Indonesia status : Belum kawin anak ke : Satu dari dua bersaudara alamat : Kp Tegalkembang Desa / Kec. Kutawaringin Kab.

  Bandung 40951 telepon : +6285861264300 e-mail : daengrosanda@gmail.com

  2. RIWAYAT PENDIDIKAN

  1. Sekolah Dasar : SDN Kopo II tahun ajaran 1995 - 2001

  2. Sekolah Menengah Pertama : SMP Negeri 1 Katapang Bandung tahun ajaran 2001 - 2004

  3. Sekolah Menengah Atas : SMAN 1 Soreang tahun ajaran 2004-2007

  4. Perguruan Tinggi : FTIK Unikom Bandung tahun ajaran 2008- 2013

  Demikian riwayat hidup ini saya buat dengan sebenar-benarnya dalam keadaan sadar dan tanpa paksaan.

  Bandung, 27 Agustus 2013 (Daeng Rosanda)

  PEMBANGUNAN FRAMEWORK UNTUK DOMAIN APLIKASI KULINER SKRIPSI

  Diajukan untuk Menempuh Ujian Akhir Sarjana Program Studi Teknik Informatika

  Fakultas Teknik dan Ilmu Komputer

DAENG ROSANDA 10108088 PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS TEKNIK DAN ILMU KOMPUTER UNIVERSITAS KOMPUTER INDONESIA 2013

KATA PENGANTAR

  Assalamu’alaikum Wr. Wb., Alahmdulillahi Rabbil’alamin, segala puji dan syukur panjatkan kepada

  Allah SWT Tuhan semesta alam, karena dengan izin dan karunia-Nya sehingga

  PEMBANGUNAN

  penulis dapat menyelesaikan skripsi dengan judul “

  FRAMEWORK UNTUK DOMAIN APLIKASI KULINER ”.

  Skripsi ini disusun dalam rangka memenuhi tugas akhir program starta satu Program Studi Teknik Informatika Fakultas Teknik dan Ilmu Komputer Universitas Komputer Indonesia.

  Dalam menyusun skripsi ini, penulis merasa banyak kekurangan. Kekurangan ini terjadi karena keterbatasan penulis dalam hal ilmu pengetahuan dan pemahaman penulisan. Akan tetapi, penulis berusaha menyusun laporan ini dengan segenap usaha yang bisa dilakukan.

  Selama tahap penyusunan skripsi ini, penulis mendapatkan bimbingan dari berbagai pihak yang telah meluangkan waktu dan tenaganya untuk membantu penulis dalam menyelesaikan penyusunan skripsi ini. Oleh karena itu, penulis ingin mengucapkan terimakasih sebesar-besarnya kepada :

  1. Tuhan Yang Maha Esa yang telah memberikan pemahaman ilmu, kesempatan, rasa ingin tahu dan kesehatan.

  2. Orang tua penulis yang senantiasa memberikan dukungan moral dan material serta berjuta nasihat kasih sayang dan motivasi dalam menyelesaikan penyusunan skripsi ini.

  3. Bapak Adam Mukharil Bachtiar, S.Kom., M.T., sebagai dosen pembimbing skripsi yang telah memberikan dorongan, motivasi, ilmu dan filosofi selama menjalani penelitian skripsi.

  4. Bapak Alif Finandhita, S.Kom., sebagai penguji satu yang telah membantu mengarahkan dan meluruskan tentang perbaikan-perbaikan yang harus dilakukan penulis.

  5. Ibu Dian Dharmayanti, S.T., M.Kom., sebagai penguji tiga yang telah membimbing dalam perbaikan penelitian skripsi ini.

  6. Saudara Andi Insanudin, S. Kom, yang telah membantu penulis dalam menentukan gaya sifat kode Android beserta penguji aplikasinya.

7. Bapak Ray Rizaldy, S.T., PT. GITS Indonesia, yang telah “memfisik” penulis dalam pengkajian teori dan aplikasi i, library, dan framework.

  8. Bapak dan Ibu Dosen Teknik Informatika Unikom.

  9. Bapak Prof. Dr. H. Denny Kurniadie, Ir., M.Sc., sebagai Dekan Fakultas Teknik dan Ilmu Komputer Universitas Komputer Indonesia

  10. Bapak Irawan Afrianto, S.T., M.T., sebagai ketua program studi Teknik Informatika.

  11. Teman-teman IF-2 2008 seperjuangan yang telah membantu penulis dari mulai proposal sampai dengan selesainya tugas akhir ini.

  12. Seluruh adik kelas dan kakak kelas maupun rekan seperjuangan teknik Informatika Unikom yang sewaktu penulis mengulang, dengan ikhlas memberikan informasi dan dukungan sehingga penulis sampai bisa sejauh ini.

  13. Dan berbagai pihak yang telah ikut mendukung, memotivasi, dan suksesor yang tidak bisa penulis sebutkan satu persatu.

  Akhir kata, penulis mohon maaf yang sebesar-besarnya atas keterbatasan dan kekurangan ini. Namun demikian penulis tetap berharap semoga skripsi ini dapat bermanfaat.

  Wassalammu ’alaikum Wr. Wb.

  Bandung, 29 Juli 2013 Penulis,

  

DAFTAR ISI

  ABSTRAK .............................................................................................................. ii ABSTRACT ........................................................................................................... iii KATA PENGANTAR ........................................................................................... iv DAFTAR ISI .......................................................................................................... vi DAFTAR GAMBAR ............................................................................................. ix DAFTAR TABEL ................................................................................................... x DAFTAR SIMBOL ................................................................................................ xi DAFTAR LAMPIRAN ........................................................................................ xiii

  BAB I PENDAHULUAN ....................................................................................... 1 I.1 Latar Belakang Masalah ........................................................... 1 I.2 Perumusan Masalah .................................................................. 2 I.3 Maksud dan Tujuan .................................................................. 2 I.4 Batasan Masalah ....................................................................... 3 I.5 Metodologi Penelitian ............................................................... 3 I.6 Metode Pengumpulan Data ....................................................... 4 I.6.1 Metode Pembangunan Perangkat Lunak .................................. 4 I.6.2 Sistematika Penulisan ............................................................... 6 BAB II LANDASAN TEORI ................................................................................. 7 II.1 Design Pattern (Perancangan Pola) ......................................... 7 II.1.1 Pola Penciptaan (Creational Pattern) ....................................... 7 II.1.2 Pola Struktural (Structural Pattern) ......................................... 9 II.1.3 Pola Tingkah Laku (Behavioral Pattern) ............................... 11 II.2 Framework ............................................................................. 13 II.2.1 Analisis Domain .................................................................... 13 II.2.2 Frozen spot ............................................................................ 14 II.2.3 Hotspot .................................................................................. 15 II.2.4 Kartu Hotspot ........................................................................ 15 II.3 Metapatterns .......................................................................... 17

  II.4.1 Pengujian Berorientasi Objek (OO Testing) ......................... 18

  II.4.2 Pengujian Implementasi Framework ..................................... 18

  II.5 Kuliner ................................................................................... 19

  II.6 Klien Server ........................................................................... 19

  II.7 Android .................................................................................. 19

  II.8 Google Play ........................................................................... 20

  II.9 Alat Pemodelan ..................................................................... 20

  II.9.1 UML ...................................................................................... 20

  BAB III ANALISIS DAN PERANCANGAN SISTEM ...................................... 23 III.1 Analisis Sistem ....................................................................... 23 III.1.1 Analisis domain masalah ....................................................... 23 III.1.2 Analisis proses bisnis ............................................................. 24 III.1.3 Analisis Frozen spot ............................................................... 37 III.1.4 Analisis Hotspot ..................................................................... 39 III.1.5 Analisis perancangan pola...................................................... 46 III.1.6 Spesifikasi kebutuhan perangkat lunak .................................. 49 III.1.7 Analisis kebutuhan non fungsional ........................................ 50 III.2 Perancangan Sistem ............................................................... 52 III.2.1 Perancangan kelas .................................................................. 52 BAB IV IMPLEMENTASI DAN PENGUJIAN SISTEM ................................... 56 IV.1 Implementasi sistem............................................................... 56 IV.1.1 Implementasi perangkat keras................................................ 56 IV.1.2 Implementasi perangkat lunak ............................................... 56 IV.1.3 Batasan Implementasi ............................................................ 57 IV.1.4 Hasil Implementasi ................................................................ 57 IV.1.5 Kelas-kelas dalam framework................................................ 59 IV.2 Pengujian Sistem .................................................................... 60 IV.2.1 Rencana pengujian ................................................................. 60 IV.2.2 Pengujian Orientasi Objek ..................................................... 61 IV.2.3 Pengujian implementasi framework ...................................... 63

  BAB V KESIMPULAN DAN SARAN ................................................................ 67 V.1 Kesimpulan................................................................................. 67 V.2 Saran ........................................................................................... 67 DAFTAR PUSTAKA ........................................................................................... xv

  DAFTAR PUSTAKA [1] arief. (2008, Maret) ComLabs-USDI | Institut Teknologi Bandung.

  [Online].

  HYPERLINK "http://www.comlabs.itb.ac.id/blog/2008/03/19/risman-adnan-ekosistem- pengembangan-software-indonesia/"

  

http://www.comlabs.itb.ac.id/blog/2008/03/19/risman-adnan-ekosistem-

pengembangan-software-indonesia/

  [2] Roger S Pressman, Rekayasa Perangkat Lunak. Yogyakarta: Penerbit Andi, 2002. [3] Mohamed E Fayad, Ralph E Johnson, and Douglas C Schmidt, Building Application Framework. New York: John Wiley & Sons, 1999. [4] Ian Sommerville, Software Engineering, Eight Edition ed.: Addison Wesley, 2007. [5] Alessandro Pasetti, Software Frameworks and Embedded Control Systems, Gerhard Goss, Juris Hartmanis, and Jun Van Leeuwen, Eds.

  Berlin; Heidelberg; New York; Tokyo; Barcelona; Hong Kong; Milan; Paris, German: Springer, 2002. [6] Erich Gamma, Richard Helm, Ralp Johnson, and John Vlissides, Design

  Patterns Element of Reusable Object-Oriented Software. Massachusetts: Addison-Wesley, 1996.

  [7] Steven John Metsker and William C Wake, Design Patterns in Java.: Addison-Weley, 2006. [8] Brian Myers, Beginning Object-Oriented ASP.NET 2.0 with VB.NET.: Apress, 2005. [9] Eric Freeman, Elisabeth Freeman, Kathy Sierra, and Bart Bates, A Brain- Friendly Guide Head First Design Pattern.: O'Reilly, 2004. [10] Moisés Daniel Díaz. (2002) MOISESDANIEL.COM. [Online].

  HYPERLINK "http://www.moisesdaniel.com/wri/metapatternsdpe.htm"

  http://www.moisesdaniel.com/wri/metapatternsdpe.htm

  [11] P. Jalote and Y. R. Muralidhara, "A coverage based model for software reliability estimation," Proceedings of First International Conference on

  Software Testing, Reliability and Quality Assurance, vol. I, no. 12, pp. 6- 10, Dec 1994.

  [12] Naufal Tawang Zulfikar Adi, Membangun Aplikasi Layanan Pencarian

  Lokasi Kuliner Terdekat di Yogyakarta Berbasis Android. Yogyakarta, Indonesia: Repository STMIK AMIKOM Yogyakarta, 2013.

  [13] Masoud Norsati, Ronak Karimi, and Hojat Allah Hasanvand, "Mobile Computing: Principles, Devices, and Operating Systems," World Applied Programming, vol. 2, no. 7, pp. 1-10, July 2012.

  "http://android.stackexchange.com/questions/34958/what-are-the- minimum-hardware-specifications-for-android"

  http://android.stackexchange.com/questions/34958/what-are-the- minimum-hardware-specifications-for-android

  [15] Issa M. Saleh, Models and Modeling: Cognitive Tools for Scientific

  Enquiry, Myint Swe Khine, Ed. London, New York: Springer Dordrecht Heidelberg, 2011.

  [16] UML Distilled: A Brief Guide to the Standard Object Modeling Language. [17] Sherif M Yacoub and Hany Husein Ammar, Pattern Oriented Analysis

  and Design: Composing Patterns to Design Software Systems.: Addison- Wesley, 2004.

  [18] Yuyun Alamsyah, Bangkitnya Bisnis Kuliner Tradisional Meraih Untung

  dari Bisnis Masakan Tradisional Kaki Lima sampai Restauran, Edisi Pertama ed. Jakarta, Indonesia: Elex Media Komputindo, 2008.

  [19] Andri Wijaya, "Kematangan Industri Perangkat Lunak Indonesia (KIPI v1.0) dan Capability Matuity Model (CMM)," Algoritma, vol. 4, no. 3, pp.

  1-8, Oktober 2008. [20] James A. Highsmith, Agile Software Development Ecosystems, 1st ed.

  Indianapolis, United States of America: Addison-Wesley Professional, 2002. [21] Naufal Tawang Zulfikar Adi, Membangun Aplikasi Layanan Pencarian

  Lokasi Kuliner Terdekat Di Yogyakarta Berbasis Android. Yogyakarta,

  Indonesia: REPOSITORY STMIK AMIKOM YOGYAKARTA, Agustus 2012, vol. I. [Online].

BAB I PENDAHULUAN I.1 Latar Belakang Masalah Pengembangan perangkat lunak kuliner dipicu oleh keanekaragaman

  kuliner yang tersebar diseluruh Indonesia. Perangkat lunak kuliner merupakan aplikasi yang dapat menyajikan data tempat kuliner berdasarkan urutan tertentu. Berdasarkan hasil observasi di PT GITS Indonesia, perangkat lunak kuliner menjadi media promosi bagi pelaku bisnis kuliner. Namun demikian, pembangunan perangkat lunak tidak terlepas dari produktifitas para pengembangnya. Menurut prediksi IDC, di Indonesia ada sekitar 56,5 ribu pengembang perangkat lunak pada tahun 2006. Tetapi, Malaysia dan Singapura ternyata mampu memproduksi perangkat lunak lebih banyak jika dibandingkan dengan Indonesia meskipun jumlah pengembang mereka lebih sedikit. Hal tersebut menunjukan bahwa kuantitas bukan merupakan faktor penentu produktifitas [1].

  Berdasarkan hasil analisis tiga aplikasi kuliner dari Google Play terdapat kesamaan fungsional umum diantara aplikasi tersebut. Dengan keadaan seperti itu harusnya produktifitas perangkat lunak kuliner dapat dioptimalkan, karena gambaran proses bisnis dapat terlihat secara jelas. Namun, hal ini belum bisa dimanfaatkan dengan baik. Terbatasnya waktu pembangunan perangkat lunak membuat pengembang perangkat lunak lebih fokus terhadap pembangunan perangkat lunak daripada analisisnya. Analisis yang tidak tepat dapat menimbulkan biasnya sistem yang akan dibangun.

  Dampak lain dari masalah ini adalah tidak adanya tatacara yang baku dalam pembangunan perangkat lunak. Sehingga penggunaan kembali fungsional yang telah dibangun sulit dilakukan. Dari masalah tersebut dapat disimpulkan bahwa penggunaan kembali fungsional yang telah dibangun dapat mempersingkat waktu pembangunan perangkat lunak. Adapun metode yang dapat menjadi solusi dari masalah tersebut adalah framework [2].

  Framework merupakan aplikasi setengah jadi yang didalamnya telah ada fungsional umum pada suatu domain aplikasi tertentu [3]. Pemilihan domain kasus kuliner didasari oleh hasil kuesioner yang diberikan terhadap 30 programmer dari berbagai latar belakang. Dari 30 responden, 24 diantaranya memilih domain kasus kuliner karena dilatarbelakangi oleh belum adanya framework yang melingkupi domain kasus tersebut. Dengan terdefinisinya semua kebutuhan dasar pembangunan framework, diharapkan pembangunan framework akan menjadi solusi yang tepat dalam meningkatkan produktifitas pembangunan perangkat lunak untuk domain kasus kuliner. Oleh karena itu, penelitian “pembangunan framework untuk domain aplikasi kuliner” dibuat.

  I.2 Perumusan Masalah

  Berdasarkan penjabaran latar belakang masalah, maka perumusan permasalahan yang terdapat pada penelitian ini adalah bagaimana cara membangun framework untuk domain aplikasi kuliner.

  I.3 Maksud dan Tujuan

  Maksud dari penelitian ini adalah untuk membangun framework yang dapat membantu pengembang perangkat lunak dalam membangun perangkat lunak kuliner.

  Adapun tujuannya yaitu:

  1. Menyediakan fungsionalitas umum yang mungkin ada pada sebuah perangkat lunak kuliner.

  2. Memberikan gambaran tentang kebutuhan dasar yang ada pada perangkat lunak kuliner.

  3. Memudahkan pengembangan perangkat lunak kuliner karena struktur kode telah baku sesuai dengan pendekatan perancangan pola.

  I.4 Batasan Masalah

  Dalam pembuatan perangkat lunak ini, pembahasan masalah dibatasi agar tidak menyimpang dari tujuan yang ingin dicapai, adapun batasan masalahnya adalah:

  1. Terdiri dari dua bagian sistem, yaitu sub sistem untuk klien dan sub sistem untuk server.

  2. Konsentrasi pembangunan framework hanya pada sub sistem klien. Sedangkan untuk sub sistem server hanya berfungsi sebagai layanan dan pengelolaan data kuliner yang berada diluar arsitektur sistem klien selanjutnya disebut dengan Web service.

  3. Web service diasumsikan telah terdefinisi dengan berformat json dengan variabel data yang telah ditentukan.

  4. Pembangunan framewok hanya untuk aplikasi klien saja.

  5. Pendekatan analisis pembangunan perangkat lunak menggunakan analisis berorientasi objek.

  6. Bahasa pemrograman yang didukung untuk sisi klien adalah Java.

  7. Pembangunan framework hanya untuk perangkat keras bebas gerak berbasis Android.

  8. Domain kasus penelitan hanya terbatas pada aplikasi penyaji tempat kuliner.

  I.5 Metodologi Penelitian

  Metodologi yang digunakan dalam penelitian ini menggunakan dua metode, yaitu metode pengumpulan data dan metode pembangunan perangkat lunak.

  I.6 Metode Pengumpulan Data

  Adapun teknik pengumpulan data yang akan digunakan terdiri dari dua cara pengumpulan data, yaitu :

  1. Studi Literatur

  Studi literatur merupakan teknik pengumpulan data melalui pengkajian literatur, jurnal, paper, dan bacaan-bacaan yang ada kaitannya dengan judul penelitian.

  2. Observasi Observasi merupakan teknik pengumpulan data melalui pengamatan langsung dilapangan sehingga suatu kesimpulan dari penelitian dapat dicapai.

  3. Kuesioner Dengan kuesioner, pengumpulan data dilakukan melalui pertanyaan- pertanyaan yang diberikan terhadap responden melalui internet untuk menghimpun data yang diperlukan untuk penelitian ini.

I.6.1 Metode Pembangunan Perangkat Lunak

  Dalam pembuatan aplikasi ini menggunakan waterfall model sebagai tahapan pengembangan perangkat lunaknya [4]. Adapun proses tersebut antara lain:

  1. Requirement analysis and definition Tahap requirement analysis and definition adalah tahap dimana pengumpulan kebutuhan telah terdefinisi secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap.

  2. System and software design Tahap system and software design merupakan tahap mendesain perangkat lunak yang dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.

  3. Implementation and unit testing Tahap requirement analysis and definition merupakan tahap hasil desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji berdasarkan unit-unitnya.

  4. Integration and system testing Tahap integration and system testing merupakan tahap penyatuan unit-unit program kemudian sistem diuji secara keseluruhan.

  5. Operation and maintenance Tahap operation and maintenance merupakan tahap mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi yang sebenarnya.

  Dari berbagai tahapan-tahapan tersebut, untuk lebih jelasnya bisa dilihat pada Gambar I.1.

  Requirements definition System and Software Design Implementation and unit testing Integration and system testing

  Operation and maintenance

Gambar I.1 Waterfall Model

I.6.2 Sistematika Penulisan

  Sistematika penulisan skripsi ini disusun untuk memberikan gambaran umum mengenai penelitian yang dikerjakan. Sistematika penulisan dalam tugas akhir ini adalah sebagai berikut :

  BAB 1 Pendahuluan Bab 1 menguraikan latarbelakang permasalahan, merumuskan inti tersebut, menentukan maksud dan tujuan, kegunaan penelitian, pembatasan masalah, metode penelitian, dan sistematika penulisan.

  BAB 2 Landasan Teori Bab 2 menguraikan bahan-bahan kajian, konsep dasar, dan teori dari para ahli yang berkaitan dengan penelitian. Meninjau permasalahan dan hal-hal yang berguna dari penelitian-penelitian dan sintesis serupa yang pernah dikerjakan sebelumnya dan menggunakannya sebagai acuan pemecahan masalah pada penelitian ini.

  BAB 3 Analisis dan Perancangan Sistem Bab 3 menguraikan hasil analisis dari objek penelitian untuk mengetahui hal atau masalah apa yang timbul dan mencoba memecahkan masalah tersebut dengan mengaplikasikan perangkat-perangkat yang digunakan.

  BAB 4 Perancangan dan Implementasi Bab 4 menguraikan tentang perancangan solusi beserta implementasinya dari masalah-masalah yang telah dianalisis. Pada bagian ini juga akan ditentukan bagaimana sistem dirancang, dibangun, diuji dan disesuaikan dengan hasil penelitian.

  BAB 5 Kesimpulan dan Saran Bab 5 menguraikan tentang kesimpulan dari hasil penelitian beserta saran untuk pengembangan selanjutnya.

BAB II LANDASAN TEORI II.1 Design Pattern (Perancangan Pola) Perancangan pola merupakan salah satu cara untuk menangani permasalahan dalam pembangunan perangkat lunak berorientasi objek. Perancangan pola menjabarkan semua teknik-teknik yang ada untuk merekayasa semua perancangan sehingga struktur tertentu dapat digunakan secara optimal. Pada pembangunan pembangunan Framework perancangan pola secara khusus

  memegang peranan penting, karena setiap sub rutin yang ada akan dirancang ulang berdasarkan pola tertentu tanpa menghilangkan fungsional tertentu baik secara interaksi maupun batasnya [5]. Setiap pola akan menjelaskan suatu permasalahan yang terjadi secara berulang sehingga akan menjabarkan bagaimana cara penyelesaiannya [6].

  Perancangan pola adalah penjelasan dari interaksi objek dan kelas yang disesuaikan untuk memecahkan masalah perancangan secara umum dalam konteks tertentu [6]. Setiap perancangan pola terfokus terhadap masalah atau isu pada perancangan berorientasi objek. Setiap masalah yang terjadi memiliki suatu keterkaitan yang disebut dengan pola. Dari pola-pola inilah, masalah dapat dijabarkan sehingga alur penyelesaian suatu masalah dapat terpecahkan. Berdasarkan tujuannya, perancangan pola dibagi kedalam tiga bagian yaitu Creational Pattern, Structural pattern, dan Behavioral Pattern.

II.1.1 Pola Penciptaan (Creational Pattern)

  Penciptaan objek dari suatu kelas disebut instansiasi [7]. Pada saat instansiasi objek diciptakan dari suatu kelas. Instansiasi ini memiliki pola yang disebut dengn pola penciptaan. Pola penciptaan merupakan tahap dimana penciptaan kelas menjadi objek [6]. Sehingga pada penciptaan objek beserta penyusunnya seperti properti dan metode telah terdefenisi dengan pola ini.

II.1.1.1 Pembangun ( Builder)

  Pola pembangun merupakan salah satu pola penciptaan yang menitik beratkan cara suatu objek dibangun. Pada pola ini, setiap komponen yang membangun objek tersebut akan memiliki kriteria yang sama meskipun penerapannya berbeda-beda [6]. Tujuan dari pola ini adalah untuk membuat objek kompleks yang independen dari bagian-bagian yang membentuk objek lain. Pola ini akan memisahkan bagian kode secara representatif dengan kode secara konstruktif sehingga pengendalian dalam pembangunan kelas dapat dilakukan dengan mudah. Dengan demikian pola pembangun dapat memisahkan kelas pembangun dengan kelas penyusun lainnya sehingga dapat menghasilkan objek yang bervariasi.

  Pada pola ini terdiri dari beberapa komponen penyusun diantaranya adalah

  

Builder, ConcreteBuilder, Director, dan Product [6]. Komponen Builder

  merupakan suatu kelas interface yang berisi metode abstrak untuk membuat pola dari bagian produk yang akan dibangun. Komponen ConcreteBuilder merupakan suatu kelas yang berisi metode yang diimplementasikan berdasarkan komponen

  

Builder pada kelas ini juga berisi interface untuk mendapatkan kembali dari

  komponen Product. Komponen Director berisi tentang konstruksi dari pada komponen yang ada dengan menggunakan interface dari komponen Builder.

  

Product merupakan komponen yang berisi tentang objek kompleks yang tersusun

dari pola Builder sebelumnya. Untuk lebih jelasnya bisa dilihat pada Gambar II.1.

  Director Builder builder Construct() BuildPart()

  For all objects in structure { builder->BuildPart() _{ConcreteBuilder Product} } builder BuildPart()

  

GetResult()

  II.1.2 Pola Struktural (Structural Pattern)

  Pola Struktural merupakan salah satu pola struktur yang ada dalam kelas yang digunakan untuk menyusun kelas melalui sifat turunan (inheritance) [6]. Turunan dalam konsep berorientasi objek merupakan salah satu cara yang mengizinkan suatu kelas untuk mendapatkan semua komponen yang ada pada kelas induknya [8]. Prinsip turunan ini, memiliki suatu pola didalam baik objek maupun kelasnya. Pola Struktural akan menjelaskan bagaimana cara perakitan suatu objek beserta pola-pola didalamnya.

  II.1.2.1 Adapter

  Pola Adapter memungkinkan untuk menghubungkan dua kelas yang berbeda tanpa mengubah struktur dan kode keduanya dengan menggunakan

  

Adapter [9]. Adapter dapat menjadi solusi untuk ketidakcocokan interface dari

  masing-masing kelas. Adapter dapat digunakan ketika ingin menggunakan kembali kelas tanpa harus melakukan pencocokan terlebih dahulu. Adapter dapat berjalan pada tingkat kelas maupun objek. Adapter juga terdiri dari Adapter satu arah dan dua arah.

  Adapun komponen-komponen penyusun dari kelas Adapter meliputi

  

Client, Target, Adapter, dan Adaptee [6]. Client merupakan komponen yang

  mengkolaborasikan objek dengan interface dari komponen Target. Target merupakan komponen yang berisikan interface untuk mendefinisikan domain spesifik yang digunakan oleh Client. Komponen Adapter bermanfaat untuk mengadaptasikan interface dari komponen Adaptee terhadap interface dari komponen Target. Untuk lebih jelasnya bisa dilihat pada Gambar II.2.

  «interface» TargetIF Client interfaceMethod( ) SpecificRequest()

  Adaptee Adapter ... otherMethod( ) interfaceMethod( )

  

Gambar II.2 Perancangan pola Adapter

II.1.2.2 Dekorator ( Decorator)

  Pola dekorator merupakan salah satu pola dimana kelas membutuhkan perangkat tambahan terhadap objek secara dinamik [6]. Dekorator lebih memberikan fleksibilitas terhadap methodnya jika dibandingkan dengan penurunan (inheritance). Dekorator juga memungkinkan penggunaan ulang komposisi yang menyusun objek atau kelas tertentu.

  Adapun komponen penyusun dari pola dekorator antara lain

AbstractService, ConcreteService, AbstractWrapper, dan ConcreteWrapper.

  

AbstractService merupakan komponen yang menyediakan atribut dan metode

  abstrak untuk digunakan sebagai patokan pada sub kelasnya. ConcreteService merupakan komponen nyata yang telah mendefinisikan seluruh komponen abstrak dari komponen AbstractService. AbstractWrapper merupakan komponen yang berfungsi untuk mendefinisikan sebagian atribut atau metode abstrak dari komponen AbstractService. ConcreteWrapper merupakan komponen yang telah mendefinisikan atribut atau metode yang abstrak pada komponen sebelumnya. Untuk lebih jelasnya bisa dilihat pada Gambar II.3.

  AbstractService Operation1( ) Operation2( ) ...

  ConcreteService AbstractWrapper Operation( ) Operation( ) Component->operation() Operation2( ) Operation2( )

  ... ...

  ConcreteWrapperA ConcreteWrapperB Decorator::Operation(); Operation( ) Operation( ) AddedBeahvior(); Operation2( ) Operation2( ) ... ...

  

Gambar II.3 Perancangan pola Dekorator

  II.1.3 Pola Tingkah Laku (Behavioral Pattern)

  Pola tingkah laku atau pola perilaku merupakan pola yang menjelaskan algortima dan aliran kontrol yang ada pada prinsip turunan [6]. Pola perilaku pada objek juga menjelaskan bagaimana sekumpulan objek berinteraksi untuk melakukan suatu pekerjaan yang tidak dapat dikerjakan oleh objek tersendiri. Sehingga dengan melalui pendekatan ini, interaksi, cara kerja, dan tingkah laku lainnya yang ada pada kelas atau objek dapat didefinisikan menjadi suatu pola tertentu.

  II.1.3.1 Strategi ( Strategy)

  Pola strategi merupakan sekumpulan algoritma yang saling mengenkapsulasi satu sama lain [6]. Pada pola ini diatur oleh suatu konsep

  

interface pengaturan komposisinya, sehingga isi masing-masing dari komposisi

  konsisten. Peranan pola ini berada pada parameter dalam algoritma yang akan

  pada penggunaan pola ini jika dan hanya jika suatu algoritma dependensi terhadap kelas yang dibangunya. Untuk lebih jelasnya bisa dilihat pada Gambar II.4.

  strategy Context Strategy ContextInterface() AlgorithmInterface() ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC AlgorithmInterface() AlgorithmInterface() AlgorithmInterface()

  

Gambar II.4 Perancangan Pola Strategy

II.1.3.2 Iterator

  Pola Iterator adalah pola yang digunakan untuk penelusuran sekumpulan objek tanpa membongkar implementasinya [9]. Objek yang ditelusuri oleh

  

Iterator biasanya objek terunut. Iterator dapat menelusuri sampai dengan tahap

  properti dari objek. Dengan demikian pola yang ditelusuri oleh Iterator bersifat agregat karena Iterator tidak memiliki komposisi dari pola lainya. Untuk lebih jelasnya bisa dilihat pada Gambar II.5. strategy Context Strategy ContextInterface() AlgorithmInterface() ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC AlgorithmInterface() AlgorithmInterface() AlgorithmInterface()

  

Gambar II.5 Perancangan Pola Iterator

  II.2 Framework Framework adalah perangkat lunak setengah jadi yang didalamnya

  terdapat komponen yang bisa digunakan secara berulang baik sebagian maupun seluruh dari sistem yang direpresentasikan oleh sekumpulan kelas abstrak beserta relasinya untuk membangun perangkat lunak yang baru [3]. Framework terdiri dari sekumpulan fungsionalitas umum sehingga pembangunan aplikasi bisa dimulai terhadap hal yang spesifiknya. Framework digunakan sebagai bahan dasar untuk pembangunan suatu aplikasi. Framework dapat digunakan secara berulang, karena Framework memiliki semua fungsional yang ada pada domain kasus tertentu. Pembangunan Framework dapat ditempuh dengan cara analisis domain, analisis Frozen spot, analisis hotspot dan analisis perangkat uji.

  II.2.1 Analisis Domain

  Analisis domain pada Framework adalah salah satu tahap untuk mengumpulkan kebutuhan dasar pembangunan Framework. Pada analisis ini dibutuhkan tiga aplikasi yang dapat menunjukan bahwa suatu fungsionalitas yang merupakan suatu proses pengelompokan perangkat lunak yang berdasarkan pada kesamaan fungsionalnya meskipun secara spesifik berbeda. Sehingga dengan adanya analisis domain, semua fungsional yang identik dari masing-masing aplikasi dalam suatu domain kasus dapat terdefinisi.

  Analisis domain dapat ditempuh dengan cara mengelompokan berbagai aplikasi dari segi proses bisnis. Proses bisnis ini yang nantinya akan membedakan atau menyamakan fungsional antar aplikasi. Setiap proses bisnis yang ada masing- masing aplikasi maka disebut hotspot. Sedangkan setiap proses bisnis yang ada diantara salah satu aplikasi maka disebut dengan Frozen spot [3].

  Untuk menentukan domain kasus secara jelas, maka dibutuhkan minimal 3 aplikasi yang berjalan pada suatu domain kasus yang sama. Dengan demikian, dengan analisis yang lebih mendalam terhadap perbedaan dan kesamaan secara proses bisnis dapat dilihat secara jelas. Hal ini sangat penting, karena dalam pembangunan Framework fungsional yang dibangun hanya berkonsentrasi terhadap proses bisnis umum yang pasti ada pada setiap aplikasi dalam suatu domain kasus tertentu [3].

  II.2.2 Frozen spot Frozen spot merupakan suatu fungsional yang identik ada pada suatu

  domain kasus tertentu [3]. Frozen spot biasanya berupa fungsional keseluruhan maupun bagian dari suatu fungsional yang ada. Pada dasarnya, irisan dari setiap fungsional yang ada antar aplikasi disebut Frozen spot. Frozen spot juga bisa dibilang bahan mentah suatu fungsional yang nantinya ada kemungkinan diurai menjadi hotspot. Namun, Frozen spot tidak selalu ada pada setiap aplikasi pada domain kasus yang sama. Sehingga jika ada fungsional yang tidak bisa diurai maka akan tetap menjadi Frozen spot.

  II.2.3 Hotspot Hotspot merupakan inti dari perancangan Framework yang akan menentukan jenis arsitektur perangkat lunak pada domain kasus tertentu [3]. dalam suatu domain kasus tertentu. Hotspot pada dasarnya merupakan fungsional yang ada pada masing-masing aplikasi dalam suatu domain kasus tertentu.

  Hotspot ini bisa didapatkan melalui penguraian dari Frozen spot.

  Selain dari penguraian Frozen spot, hotspot juga bisa muncul karena kebutuhan hotspot yang telah terdefinisi. Penguraian hotspot dibagi kedalam dua bagian yaitu whitebox dan metode blackbox [3]. Metode pendefinisian hotspot secara whitebox merupakan pendefinisian hotspot berdasarkan kebutuhan dari

  

hotspot lainnya. Sedangkan secara blackbox, hotspot didefinisikan melalui

  penguraian dari Frozen spot. Syarat dari metode ini yaitu fungsional harus ada pada setiap aplikasi dalam suatu domain kasus. Sehingga cara ini dapat ditempuh dengan cara mendefinisikan Frozen spot terlebih dahulu.

II.2.4 Kartu Hotspot

  Kartu hotspot merupakan salah satu cara untuk mendefinisikan kebutuhan fungsional perangkat lunak [3]. Tujuan dari kartu hotspot adalah untuk membedakan aspek implementasi dari masing-masing aplikasi sehingga kemampuan akomodasi dari suatu hotspot dapat terukur. Dengan demikian, proses identifikasi fungsional dari proses bisnis dapat dijabarkan secara nyata. Adapun bagian-bagian dari kartu hotspot antara lain nama hotspot, derajat fleksibilitas, deskripsi umum dan contoh kasus penerapan dari hotspot yang bersangkutan.

  Nama hotspot dalam kartu hotspot biasanya mengacu pada fungsionalitasnya. Derajat fleksibilitas merupakan tanda suatu kondisi hotspot yang bersangkutan dapat diadaptasikan secara langsung atau harus disesuaikan terlebih dahulu, biasanya dalam bagian ini terdiri dari dua bagian yaitu Adaptation

  

without restart dan adaptation by end user [3]. Adaptation without restart berarti

  adaptasi dari hotspot yang bersangkutan bisa langsung digunakan. Sedangkan

  

adaptation by end user berarti hotspot tersebut sebelum digunakan harus

  disesuaikan terlebih dahulu oleh pengguna sebelum digunakan. Adaptation by end

  

user juga bisa diartikan bahwa fungsional yang disusun pada kartu hotspot masih

  bersifat abstrak sehingga jika fungsionalitas tersebut akan dijalankan maka harus

  

restart memungkinkan pemanggilan fungsi pada level kelas atau objek tanpa

menurunkannya terlebih dahulu.

  Bagian deskripsi umum pada kartu hotspot berisi tentang penjelasan singkat fungsional. Penjelasan ini berisikan tentang gambaran umum tentang proses apa saja yang terjadi pada hotspot yang bersangkutan. Sedangkan untuk bagian contoh kasus penerapan hotspot diisi dengan implementasi contoh kasus dari hotspot. Bagian ini diisi dengan minimal dua bentuk implementasi dari

  

hotspot yang bersangkutan. Bentuk penerapan ini biasanya digunakan untuk

  memandu secara kontras sejauh mana fleksibilitas yang ada pada hotspot tersebut diimplementasikan [5]. Untuk lebih jelasnya mengenai kartu hotspot dapat dilihat pada Gambar II.6.

  Nama Hot Spot Tingkat fleksibilitas □ adaptation without restart □ adaptation with by end user

  Deskripsi umum

Contoh implementasi, minimal dua situasi yang

berbeda

  

Gambar II.6 Gambar Kartu Hotspot

II.3 Metapatterns

  Metapatterns dalam pembangunan Framework berguna untuk mendukung

  konstruksi dari Framework [3]. Dengan adanya metapattern mengizinkan perancangan pola pada tahap meta (meta level) sehingga pengkategorian secara detail dari pola-pola yang ada dapat diperjelas. Ruang lingkup metapattern perancangan pola. Jadi, secara praktis penggunaan metapattern lebih condong terhadap penghubung dari konsep yang ada pada perangcangan pola supaya dapat mengakomodasi berbagai masalah yang ditimbulkan oleh perangcangan pola. Adapun kelebihan dari metapattern antara lain yaitu, dapat meningkatkan kualitas desain sistem, menentukan objek yang mendukung peran yang berguna dalam konteks tertentu, enkapsulasi secara kompleks, dan lebih fleksibel [10].

  Inti dari metapattern didefinisikan dari cara pandang terhadap metode- metode yang ada pada suatu kelas (class method). Metode kelas berdasarkan karakteristiknya dibedakan menjadi dua bagian, yaitu metode kait pancing (hook

  

method) dan metode contoh (template method) [3]. Metode kait pancing

  merupakan suatu metode dalam kelas yang memiliki kemampuan untuk memancing parameter tertentu terhadap fungsionalitas suatu kelas. Sedangkan metode contoh merupakan suatu pendekatan yang memanfaatkan contoh dari suatu konsep yang ada. Berbeda dari metode pancing, metode contoh mengakomodasi berbagai konsep yang telah ada sehingga perancangannya bersifat baku. Sedangkan metode pancing bisa berasal dari metode contoh yang diberikan berbagai penyesuaian sesuai dengan kebutuhan.

  Kedalaman analisis dari metapattern ini mulai dari tingkat kelas sampai dengan objek. Dengan kata lain, untuk menghubungkan dari satu perancangan pola ke pola lainnya membutuhkan kelas khusus atau bahkan akan membuat objek khusus[3]. Sehingga bentuk dari metapattern ini akan terungkap sebagai kelas atau objek. Adapun dampak dari metapattern ini adalah adanya relasi baru antar pola, seperti sifat komposisi, asosiasi, dependensi, generalisasi, spesialisasi, dan agregasi.

II.4 Pengujian Perangkat Lunak

  Pengujian perangkat lunak merupakan tahap pengujian dimana semua pola yang telah dirancang akan diuji secara fungsionalitas [5]. Tujuan dari pengujian perangkat lunak untuk memeriksa kesesuaian antara kebutuhan dengan fungsionalitas perangkat lunak yang telah dibangun. Dalam penelitian ini, yang dibangun beserta pengujian implementasi perangkat lunak yang dibangun berdasarkan pada Framework. Kedua bagian tersebut masuk kedalam pengujian orientasi objek (OO Testing) dan uji implementasi Framework.

  II.4.1 Pengujian Berorientasi Objek (OO Testing)

  Pengujian berorientasi objek merupakan pengujian yang menitik beratkan pada konsep orientasi objek [11]. Konsep utama pengujian ini meliputi tiga bagian yaitu encapsulation, polymorphisme dan inheritance. Kriteria dari pengujian ini bisa berupa pengujian pada kelas (class testing), pengujian integrasi (integration

  

testing) dan pengujian validasi (validation testing). Pengujian kelas merupakan

  pengujian yang menitik beratkan terhadap kondisi suatu kelas beserta elemen didalamnya. Sedangkan pengujian integrasi merupakan pengujian kelas atau komponen dalam kelas yang diintegrasikan terhadap suatu skenario pengujian tertentu. Pengujian validasi merupakan pengujian yang fokus terhadap daya uji kesalah suatu algoritma yang ada pada properti atau metode suatu kelas. Metode pengujian yang dilakukan pada pengujian ini adalah pengujian black box. Pengujian black box merupakan pengujian yang menitik beratkan terhadap kebutuhan dan fungsional [4].

  II.4.2 Pengujian Implementasi Framework

  Pengujian implementasi Framework merupakan pengembangan perangkat lunak yang didasari oleh Framework. Pengujian ini berupa pembangunan perangkat lunak berdasarkan Framework [3]. Dengan demikian hasil dari

  

Framework ini dapat dibuktikan fungsionalitasnya berdasarkan hasil

implementasi.