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-
Demikian riwayat hidup ini saya buat dengan sebenar-benarnya dalam keadaan sadar dan tanpa paksaan.
Bandung, 27 Agustus 2013
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
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
penulis dapat menyelesaikan skripsi dengan judul “
PEMBANGUNAN
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.
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
vi
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
vi
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
vii
BAB V KESIMPULAN DAN SARAN ... 67
V.1 Kesimpulan... 67
V.2 Saran ... 67
xv
[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.
[14] Matthew Read. (2012, December) Android Enthusiasts Stack Exchange.
xvi
"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.
1
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.
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
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 :
4
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
5
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
6
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
7
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)
8
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.
9
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
10
Client
«interface» TargetIF interfaceMethod( )
Adapter interfaceMethod( ) Adaptee
...
otherMethod( )
SpecificRequest()
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.
11
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
12
pada penggunaan pola ini jika dan hanya jika suatu algoritma dependensi terhadap kelas yang dibangunya. Untuk lebih jelasnya bisa dilihat pada Gambar II.4.
Context
ContextInterface()
Strategy
AlgorithmInterface()
ConcreteStrategyB
AlgorithmInterface() ConcreteStrategyA
AlgorithmInterface()
ConcreteStrategyC
AlgorithmInterface()
strategy
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
13
Context
ContextInterface()
Strategy
AlgorithmInterface()
ConcreteStrategyB
AlgorithmInterface() ConcreteStrategyA
AlgorithmInterface()
ConcreteStrategyC
AlgorithmInterface()
strategy
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
14
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].
15
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
16
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
17
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
18
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.
II.5 Kuliner
19
kuliner yang berbeda-beda. Kuliner merupakan sebuah gaya hidup yang tidak dapat dipisahkan dari kehidupan sehari-hari.
II.6 Klien Server
Konsep klien server merupakan salah satu konsep dimana ada penyediaan data secara terpusat yang dapat didistribusikan terhadap masing-masing pengguna dengan tata cara tertentu [4]. Klien merupakan perangkat lunak yang akan dibangun pada sisi pengguna, sedangkan server merupakan perangkat lunak yang akan menampung data dan menyediakan semua layanan yang diperlukan oleh klien. Konsep klien server digunakan untuk mendistribusikan data antar klien. Komponen klien juga sering disebut sebagai front-end, sementara komponen server disebut sebagai back-end.
II.7 Android
Android merupakan sistem operasi sumber terbuka berbasis linux yang dikembangan oleh Open Handset Alliance dibawah naungan perusahaan Google [13]. Pada umumnya sistem operasi Android dirancang untuk perangkat keras mobile yang memiliki spesifikasi layar sentuh seperti smartphone dan komputer tablet. Bahasa pemrograman yang didukung oleh Android yaitu Java. Aplikasi yang ada pada sistem operasi Android telah terintegrasi dengan layanan market khusus perusahaan google play. Adapun kebutuhan minimum perangkat keras yang dibutuhkan oleh sistem operasi android bergantung terhadap versi sistem operasinya [14]. Daftar lengkap dari kebutuhan minimum sistem operasi Android dapa dilihat pada Tabel II 1.
Tabel II 1 Kebutuhan minimum perangkat keras Android
20
1.6 Kebawah 200MHz ARM versi 5 32 MB 32 MB
II.8 Google Play
Google play merupakan salah satu toko elektronik yang dikembangkan oleh perusahaan Google [13]. Google play atau disebut juga dengan Playstore secara khusus menyediakan layanan download aplikasi untuk sistem operasi Android. Playstore juga mendukung integrasi sistem dari versi Android 2.2 keatas. Playstore menyediakan daftar-daftar aplikasi berdasarkan berbagai kategori seperti permainan dan aplikasi umum.
II.9 Alat Pemodelan
Alat pemodelan merupakan salah satu perangkat lunak yang digunakan untuk memodelkan suatu konsep, perancangan, baik implementasi dari suatu gagasan. Tools pemodelan digunakan untuk membangun suatu model yang berisi bentuk objek dan konsep dari suatu gambaran yang akan disampaikan lebih sederhana yang disajikan dalam runutan untuk memudahkan dalam pemahaman suatu gagasan yang akan disampaikan [15].
II.9.1 UML
UML atau unified modeling language merupakan salah satu rumpun jenis pemodelan berbasis notasi grafik yang digunakan untuk mendeskripsikan bentuk pemodelan untuk sistem perangkat lunak berbasis objek[16]. UML merupakan standar terbuka yang dikelola oleh Open Management Group (OMG) yang berada dibawah naungan perusahaan-perusahaan konsorsium terbuka. UML merupakan suatu bahasa pemodelan yang terdiri banyak model didalamnya. Adapun salah satu dari bentuk tersebut antara lain:
1. Use case diagram
21
menekankan tingkah laku fungsional utama dalam sistem berinteraksi dengan objek diluar sistem tersebut. Selain itu, use case diagram juga telah menitik beratkan jenis hubungan diantara fungsi utama. Adapun komponen-komponen dalam use case diagram antara lain:
a. Aktor
Aktor merupakan suatu entitas yang berkaitan dengan sistem tapi bukan dari bagian dalam sistem itu sendiri. Aktor berada diluar sistem namun berkaitan erat dengan fungsionalitas didalamnya. Aktor dapat memiliki hubungan secara langsung terhadap fungsi utama baik terhadap salah satu atau semua fungsionalitas utama. Aktor juga dapat dibagi terhadap berbagai jenis atau tingkatan dengan cara digeneralisasi atau dispesifikasi tergantung kebutuhan sistemnya. Aktor biasanya dapat berupa pengguna atau database yang secara pandang berada dalam suatu ruang lingkup sistem tersebut.
b. Use case
Use case merupakan gambaran umum dari fungsi atau proses utama yang menggambarkan tentang salah satu perilaku sistem. Perilaku sistem ini terdefinisi dari proses bisnis sistem yang akan dimodelkan. Tidak semua proses bisnis digambarkan secara fungsional pada use case, tetapi yang digambarkan hanya fungsionalitas utama yang berkaitan dengan sistem. Use case menitik beratkan bagaimana suatu sistem dapat berinteraksi baik antar sistem maupun diluar sistem.
2. Class Diagram
22
Masing-masing komponen penyusun kelas memiliki hak akses seperti public,
69
BAB V
KESIMPULAN DAN SARAN
Pada bab ini akan dipaparkan kesimpulan mengenai hasil penelitian Pembangunan Framework untuk Domain Kasus Kuliner dan pembangunan perangkat lunak yang dihubungkan dengan teori mengenai segala hal yang berhubungan dengan Pembangunan Framework untuk Domain Kasus Kuliner.
V.1 Kesimpulan
Dari kegiatan penelitian Pembangunan Framework dan pembangunan perangkat lunak mengenai teori-teori mengenai kedua hal tersebut, maka dapat disimpulkan bahwa :
1. Framework telah menyediakan fungsionalitas umum yang mungkin ada pada sebuah perangkat lunak kuliner.
2. Framework memberikan gambaran tentang kebutuhan dasar yang ada pada perangkat lunak kuliner.
3. Framework memudahkan pengembangan perangkat lunak kuliner karena struktur kode telah baku sesuai dengan pendekatan perancangan pola.
V.2 Saran
Adapun saran dari hasil penelitian Pembangunan Framework untuk Domain Kasus Kuliner antara lain :
1. Penelitian lebih lanjut untuk fungsional pada framework dapat dilakukan lagi tidak hanya dengan analisis dari aplikasi yang berjalan, juga dapat dilakukan dengan cara analisis pakar kuliner (domain expert) yang tidak dilakukan pada penelitian ini.
Jurnal Ilmiah Komputer dan Informatika
Teknik Informatika – Universitas Komputer Indonesia Jl. Dipatiukur 112-114 Bandung
E-mail : daengrosanda@gmail.com1
ABSTRAK
Framework dibangun dengan tujuan untuk meningkatkan produktifitas perangkat lunak, karena
framework telah menyediakan fungsional umum yang ada pada suatu domain kasus aplikasi. Domain kasus aplikasi kuliner dipilih 24 dari 30 programmer dari berbagai latar belakang. Hal ini didasari oleh belum adanya framework dalam bidang tersebut. Selanjutnya, fungsional yang umum pada framework
didapatkan melalui hasil analisis proses bisnis yang ada pada setiap aplikasi yang telah berjalan. Implementasi fungsional yang pada framework juga dianalisis melalui analisis perancangan pola. Hasil implementasi tersebut diuji dengan menggunakan metode pengujian berorientasi objek dan pengujian implementasi perangkat lunak dari framework.
Kata kunci : framework, kuliner, design pattern.
1.PENDAHULUAN
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 [ HYPERLINK \l "1" 1 ].
1.1Framework
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 2]}.
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.
1.1.1 Analisis Domain
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
Jurnal Ilmiah Komputer dan Informatika
(KOMPUTA)
46 Edisi. .. Volume. .., Bulan 20.. ISSN : 2089-9033Gambar 1 Ilustrasi Frozen spot
1.1.3 Hotspot
Hotspot merupakan inti dari perancangan
framework yang akan menentukan jenis arsitektur perangkat lunak pada domain kasus tertentu [ HYPERLINK \l "2" 2 ]. Hotspot terdiri atas sekumpulan fungsional yang pasti ada dalam setiap aplikasi 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 2]}. 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.
1.2.1 Creational Pattern
Penciptaan objek dari suatu kelas disebut instansiasi [ HYPERLINK \l "Met06" 5 ]. 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 4]}. Sehingga pada penciptaan objek beserta penyusunnya seperti properti dan metode telah terdefinisi dengan pola ini.
Adapun pola structural yang digunakan dalam penelitian ini adalah pola Adapter dan pola
Decorator. Pola adapter memungkinkan untuk menghubungkan dua kelas yang berbeda tanpa mengubah struktur dan kode keduanya dengan menggunakan adapter 7]}. Sedangkan Pola dekorator merupakan salah satu pola dimana kelas membutuhkan perangkat tambahan terhadap objek secara dinamik [ HYPERLINK \l "4" 4 ]. Dekorator lebih memberikan fleksibilitas terhadap methodnya jika dibandingkan dengan penurunan (inheritance).
Sedangkan pola Iterator adalah pola yang digunakan untuk penelusuran sekumpulan objek tanpa membongkar implementasinya [ HYPERLINK \l "Fre04" 7 ]. 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.
1.3Perangkat Lunak Uji
Pengujian perangkat lunak merupakan tahap pengujian dimana semua pola yang telah dirancang akan diuji secara fungsionalitas 3]}. Tujuan dari pengujian perangkat lunak untuk memeriksa kesesuaian antara kebutuhan dengan fungsionalitas perangkat lunak yang telah dibangun. Dalam penelitian ini, pengujian yang akan dilakukan meliputi pengujian fungsionalitas dari setiap kelas 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.
1.3.2 Uji Implementasi
Pengujian implementasi framework merupakan pengembangan perangkat lunak yang didasari oleh
framework. Pengujian ini berupa pembangunan perangkat lunak berdasarkan framework [ HYPERLINK \l "2" 2 ]. Dengan demikian hasil dari
framework ini dapat dibuktikan fungsionalitasnya berdasarkan hasil implementasi.
2.ISI PENELITIAN
Dalam penelitian ini terdiri dari 3 bagian yaitu analisis proses bisnis, analisis frozen spot, analisis
hotspot, perancangan kelas, dan perangkat lunak uji.
2.1Analisis Proses Bisnis
