BAB II DASAR TEORI
2.1 Stratigrafi Stratigrafi adalah cabang ilmu Geologi yang mempelajari lapisan batuan dan proses pembentukannya. Ilmu ini pertama kali ditemukan dan diterapkan pertama kali oleh William Smith di Inggris sekitar tahun 1790 dan 1800. Lapisan batuan dapat menggambarkan skala waktu Geologi, sehingga dapat memberikan suatu gambaran yang lebih jelas mengenai masa lampau dan adanya suatu kosakata umum yang digunakan jika membicarakan mengenai masa lampau. Oleh karena itu ilmu Stratigrafi muncul pada waktu itu.
Batuan yang ada saat ini menyimpan informasi mengenai keadaan bumi masa lampau, khususnya batuan sedimen yang merupakan hasil sedimentasi batuan masa lampau dan biasanya menyimpan jasad organisme yang hidup pada masa lampau (dalam bentuk fosil). Batuan sedimen tersusun dalam lapisan demi lapisan yang terbentuk dalam waktu yang sangat lama. Setiap lapisan yang baru terbentuk akan terletak di atas lapisan batuan yang sudah ada sebelumnya, sehingga dapat disimpulkan bahwa lapisan batuan yang tertua usianya berada di bagian paling bawah (dari urutan lapisan batuan) sedangkan batuan yang berusia paling muda berada di bagian paling atas lapisan batuan (prinsip superposisi), kecuali lapisan batuan tersebut telah mengalami tektonisasi, sehingga urutannya dapat terbalik.
Stratigrafi berhubungan dengan lapisan batuan dan klasifikasinya menjadi satuan yang terurut berdasarkan interpretasi sejarahnya. Salah satu tujuan dari Stratigrafi adalah untuk menghasilkan kronologi yang tepat bukan hanya urutan dari suatu kejadian di masa lampau, namun juga tanggal terjadinya kejadian tersebut. Klasifikasi ilmu Stratigrafi menjadi dasar untuk hal-hal ini.
Ada tiga kategori penting dari klasifikasi Stratigrafi yaitu lithostratigraphy, biostratigraphy, dan chronostratigraphy, yang merupakan cara untuk melakukan klasifikasi lapisan batuan dalam satuan yang memiliki arti masing-masing. a. Lithostratigraphy Lithostratigraphy melakukan klasifikasi berdasarkan karakter dari batuan dan perbedaan dari tipe/jenis batuan (misal: lempung/tanah liat, kalsit, dan lain lain).
II-1
II-2 Pembagian dalam lithostratigraphy diatur dalam sistem hirarki (lithostratigraphic units) yaitu: 1. Group Gabungan dua atau lebih formasi yang serupa atau saling berhubungan. 2. Formation (formasi) Sekumpulan members yang disatukan oleh karakteristik yang sama (lithologically homogenous), dan dapat dibedakan dari unit batuan bagian atas dan bawahnya. Karakteristik yang dipilih untuk menentukan suatu formasi dapat mencakup satu atau lebih kriteria berikut: a. Composition of mineral grains b. Color c. Textural properties d. Thickness and geometry of stratification e. Character of any organic remains f.
Outcrop character
Produk hasil sedimentasi dari setiap lingkungan punya karakteristik unik walaupun proses akumulasi terjadi pada waktu yang sama dan bertumpukan satu di atas yang lain. Dengan kata lain, formasi dapat bervariasi baik secara lateral maupun vertikal. Formation merupakan unit fundamental dalam Stratigrafi. 3. Members Sekumpulan bed yang disatukan oleh suatu karakteristik yang sama. 4. Bed Sebuah lapisan yang dapat dibedakan dalam urutan batuan/satuan unit terkecil dalam lithostratigraphy. b. Biostratigraphy Dalam biostratigraphy, keberadaan fosil dalam lapisan batuan digunakan dalam melakukan interpretasi dari urutan sejarah. c. Chronostratigraphy Tujuan chronostratigraphy adalah untuk mengorganisasi urutan batuan pada suatu skala global dalam unit chronostratigraphic, sehingga ada relasi antara kejadian yang terjadi secara lokal dengan standar tunggal global. Untuk melakukan ini perlu dibuat suatu ekivalensi antara satuan chronostratigraphy dengan satuan waktu. Dalam pembuatan Tugas Akhir ini difokuskan pada biostratigraphy, karena berhubungan dengan fosil Moluska.
Simbol Lithologi Simbol umum yang digunakan dalam ilmu batuan dapat dilihat pada Gambar II-1.
II-3
Gambar II-1 Simbol Lithology
2.2 Sistem dan Rekayasa Sistem Kata “sistem” banyak dipergunakan dalam beragam konteks dan bidang ilmu. Sistem dapat didefinisikan sebagai A system is a purposeful collection of interrelated components that work together to achieve some objective.[SOM04] Namun dalam konteks keilmuan Informatika, sistem yang terkait dengan perangkat lunak adalah computer-based system dan socio-technical system. Kamus Webster mendefinisikan computer-based system sebagai: A set or arrangement of elements that are organized to accomplish some predefined goal by processing information.[PRE05]
II-4 Sedangkan socio-technical system sebagai sistem yang tidak hanya mencakup satu atau lebih sistem teknis yang ada, namun juga mengenai pengetahuan suatu sistem bekerja/digunakan untuk mencapai tujuan yang lebih luas [SOM04].
Satu karakteristik dari semua sistem adalah ciri-ciri dan tingkah laku komponen dari sistem yang berinteraksi dengan erat (tightly coupled/inextricably intermingled). Keberhasilan menggunakan salah satu komponen sistem bergantung pada kinerja dari komponen yang lain. Sistem biasanya berbentuk hirarki dan mencakup sistem lain yang disebut sub-sistem [SOM04] [PRE05].
Proses rekayasa sistem biasanya dimulai dengan sebuah “world view” [PRE05], kemudian “world view” dikembangkan untuk lebih berfokus pada domain/ruang lingkup masalah tertentu. Dengan adanya domain yang spesifik, dilakukan analisis terhadap kebutuhan elemen sistem kemudian akhirnya elemen sistem itu sendiri dianalisis, dirancang, dan dikonstruksi (Gambar II-1).
Gambar II-2 System Engineering Hierarchy
Karena terdiri dari komponen/elemen yang beragam, maka rekayasa perangkat lunak sangat penting untuk menghasilkan sebuah sistem komputer yang baik. Software engineers perlu mengerti rekayasa sistem karena masalah rekayasa perangkat lunak seringkali merupakan hasil dari keputusan rekayasa sistem [SOM04].
II-5
2.3 Rekayasa Perangkat Lunak Berbeda dengan rekayasa sistem yang mempunyai ruang lingkup yang luas, rekayasa perangkat lunak merupakan bagian spesifik/salah satu proses dari rekayasa sistem. IEEE memberikan definisi rekayasa perangkat lunak sebagai berikut [PRE05] Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). Rekayasa perangkat lunak merupakan layered technology [PRE05]. Landasan yang mendukung rekayasa perangkat lunak adalah fokus terhadap kualitas (quality focus). Proses perangkat lunak (software process) dapat didefinisikan sebagai kumpulan aktivitas dan hasilnya yang menghasilkan produk perangkat lunak [SOM04] [JAC99]. Proses perangkat lunak mendefinisikan sebuah kerangka kerja/framework yang harus dibuat untuk menghasilkan teknologi rekayasa perangkat lunak yang efektif. Metode rekayasa perangkat lunak (methods) merupakan cara untuk membangun perangkat lunak (secara teknis, mencakup aktivitas pemodelan dan teknik lainnya). Kakas rekayasa perangkat lunak (tools) menyediakan dukungan bagi proses dan metode rekayasa perangkat lunak.
Langkah pertama dalam pembangunan suatu perangkat lunak dimulai dengan proses rekayasa perangkat lunak/proses perangkat lunak (software process). Proses perangkat lunak merupakan suatu proses yang rumit karena karakteristik proses perangkat lunak yang beragam, dan banyaknya elemen yang terlibat dalam pembangunan perangkat lunak. Oleh karena itu diperlukan suatu pemodelan dalam proses perangkat lunak, sehingga proses yang ada bisa terstruktur dan terkontrol dengan baik yang akan memberikan suatu pandangan yang lebih sederhana terhadap proses perangkat lunak.
Gambar II-3 Software Engineering Layer
Model proses dapat didefinisikan sebagai representasi abstrak dari proses perangkat lunak. Setiap model proses mewakili sebuah proses dari sudut pandang tertentu, sehingga hanya memberikan sebagian informasi mengenai keseluruhan proses perangkat lunak. Beberapa model proses yang umum digunakan antara lain:
II-6 1) Waterfall model Dalam model ini, beberapa kegiatan yang dilakukan antara lain [PRE01]: a) System/information engineering and modeling b) Software requirement analysis c) Design d) Code generation e) Testing f) Support Namun beberapa masalah umum yang muncul dari model ini adalah: a) Dalam kenyataan model ini jarang digunakan dalam proyek perangkat lunak b) Sulit bagi customer untuk menyatakan semua kebutuhannya secara eksplisit c) Customer harus sabar untuk melihat hasil perangkat lunak yang dapat berjalan (setelah melalui tahapan yang ada) d) Dapat menimbulkan “blocking states”, karena sifatnya yang sekuensial 2) Evolutionary process model Model proses evolusioner biasanya lebih efektif dari model waterfall jika dibutuhkan sistem dalam waktu yang singkat. Keunggulan lain dari model ini adalah kemungkinan untuk melakukan pengembangan spesifikasi perangkat lunak (secara incremental). Namun, beberapa kekurangan dari model ini antara lain [SOM04] : a) Sistem sulit terstruktur karena adanya perubahan yang dapat terjadi terusmenerus selama proses perangkat lunak berjalan. Hal ini juga mengakibatkan masalah dengan perencanaan proyek akibat tidak jelasnya jumlah siklus yang diperlukan untuk menghasilkan produk perangkat lunak akhir (akibat adanya perubahan). b) Kemajuan dari proses perangkat lunak diukur dari hasil/deliverables yang ada, namun untuk suatu model proses yang dapat mengalami perubahan sewaktu-waktu, hal ini tidak efektif. c) Model ini kurang cocok digunakan untuk perangkat lunak dalam skala besar, kompleks, yang memiliki waktu penggunaan yang lama, dan bagian-bagian sistemnya dikembangkan oleh berbagai tim. 3) Component-based software engineering Kata kunci yang ada pada model ini adalah penggunaan ulang/reuse dari komponen perangkat lunak yang sudah ada. Suatu perangkat lunak terdiri dari berbagai komponen,
dan
dengan
menggunakan
ulang
komponen
yang
sudah
ada/dikembangkan sebelumnya, maka waktu proses yang berlangsung akan menjadi semakin singkat, sehingga biaya dan resiko dalam proses perangkat lunak akan semakin kecil. Karena konsep penggunaan ulang komponen perangkat lunak yang
II-7 sudah ada sebelumnya, perlu adanya integrasi komponen yang baru dengan sistem secara keseluruhan. Namun seringkali karena penggunaan dari komponen perangkat lunak yang sudah ada sebelumnya, perangkat lunak hasil akhir tidak memenuhi requirement dari pengguna (perlu adanya konfigurasi dan penyesuaian terhadap requirement pengguna). Proses perangkat lunak tidaklah terlepas dari perubahan. Oleh karena itu sebaiknya aktivitas proses dilakukan secara berulang (secara iteratif) seiring dengan pengembangan dan perbaikan sistem yang ada sebagai cara untuk menangani perubahan yang terjadi [SOM04].
2.4 Arsitektur Perangkat Lunak Arsitektur perangkat lunak adalah kerangka kerja fundamental untuk menstrukturkan suatu sistem. Karakter sistem seperti performansi, keamanan, dan availability dipengaruhi dari arsitektur yang digunakan. Perangkat lunak terdiri dari berbagai macam jenis dan kegunaan, dan aristektur dari masing-masing perangkat lunak tersebut berbeda satu dengan yang lain. Namun ketika arsitektur aplikasi perangkat lunak ditinjau secara mendalam dapat ditemui kesamaan diantaranya. [SOM04] menjelaskan empat arsitektur umum dari aplikasi perangkat lunak, yaitu: 1. Data-processing applications Sesuai dengan namanya, sistem ini berfokus pada data dan basis data (aplikasi perangkat lunak yang bersifat data-driven). Sistem ini melakukan pemrosesan data secara bersamaan/batch tanpa intervensi pengguna secara eksplisit selama pemrosesan data. Aksi spesifik yang diambil oleh aplikasi bergantung dari data yang diproses. Arsitektur dari batch-processing systems memiliki tiga komponen utama yaitu input, proses, dan output (Gambar II-4). Komponen input mengumpulkan dari satu atau lebih sumber masukan; komponen proses melakukan komputasi menggunakan input yang ada/didapatkan; komponen output menghasilkan keluaran yang akan ditulis kembali ke basis data dan dicetak. 2. Transaction-processing applications Aplikasi jenis ini merupakan aplikasi yang berpusat pada basis data. Aplikasi ini memproses permintaan pengguna akan informasi dan melakukan update informasi pada basis data. Transaction-processing systems biasanya merupakan sistem interaktif yang penggunanya melakukan asynchronous request terhadap suatu layanan/service. Struktur dari aplikasi pemrosesan transaksi dapat digambarkan seperti pada Gambar II-5.
II-8
Gambar II-4 Model Arsitektur Data Processing System
I/O processing
Application logic
Transaction manager
Database
Gambar II-5 Model Arsitektur Transaction Processing Application
3. Event-processing systems Sistem ini memberi respon dari event yang terjadi di lingkungan sistem atau dari antarmuka pengguna. Event ini dapat berupa perintah dari pengguna atau perubahan pada variabel yang dimonitor oleh sistem. Contoh aplikasi jenis ini antara lain aplikasi permainan/games, word processor/editing system, dan real-time system. 4. Language-processing systems Sistem ini menerima masukan berupa bahasa natural atau buatan/artificial dan membuat representasi lain dari bahasa tersebut sebagai output. Dalam sistem ini terdapat komponen translator dan mesin abstrak yang akan melakukan eksekusi bahasa yang diciptakan. Contoh aplikasi yang menggunakan sistem ini adalah compiler bahasa pemrograman.
2.5 Object Oriented Paradigm Paradigma berorientasi objek memiliki beberapa keuntungan bila dibandingkan dengan metode pengembangan klasik (structured paradigm). Teknologi objek menekankan pada penggunaan ulang (reuse). Penggunaan ulang (dari komponen program) akan mengakibatkan pengembangan perangkat lunak yang lebih cepat dan program yang memiliki kualitas lebih tinggi. Perangkat lunak berorientasi objek lebih mudah dipelihara karena strukturnya yang bersifat tidak terikat. Hal ini mengakibatkan efek samping yang lebih sedikit jika terjadi perubahan dalam pengembangan. Dan sistem berorientasi objek lebih mudah dikonfigurasi dan lebih mudah dikembangkan. [PRE01]
II-9 Dengan pendekatan berorientasi objek, domain permasalahan dimodelkan sebagai sekumpulan objek yang memiliki atribut tertentu dan perilaku tertentu. Objek-objek berinteraksi satu sama lain melalui protokol pertukaran pesan. Objek-objek dikategorikan dalam class dan subclass. Dalam pengembangan menggunakan pendekatan objek, keuntungan yang didapatkan adalah mekanisme enkapsulasi dari objek dan penggunaan ulang objek-objek dan class. Tahapan dalam object oriented software engineering: a. Object oriented analysis (OOA) Dalam tahapan ini, hal yang dikerjakan antara lain mendefinisikan class/object yang mewakili masalah yang akan diselesaikan, relasi class/object dengan class/object yang lain, atribut dan operasi dari suatu objek, serta mekanisme untuk berkomunikasi/bertukar pesan. Untuk mencapai hasil seperti di atas beberapa langkah. OOA dimulai dengan mendeskripsikan use-case (berupa skenario yang menerangkan interaksi aktor dengan produk yang akan dibangun), kemudian pemodelan class-responsibility-collaborator (CRC) melakukan translasi dari informasi yang terdapat dalam use-case menjadi representasi class dan hubungannya dengan class lain, kemudian karakteristik statik dan dinamik dari class kemudian dimodelkan dengan UML (atau metode lain). [PRE01] b. Object oriented design (OOD) OOD melakukan transformasi model yang dihasilkan dari OOA menjadi model desain yang berfungsi sebagai cetak biru bagi pembangunan perangkat lunak. Desain yang dihasilkan dari OOD memiliki beragam tingkat modularitas yang berbeda, sehingga pengembang perangkat lunak dapat menggunakan ulang desain yang dibangun yang berakibat meningkatkan kecepatan pengembangan perangkat lunak dan kualitas produk. OOD dibagi menjadi dua tahap yaitu desain sistem dan desain objek. Desain sistem membuat arsitektur produk dan mempertimbangkan spesifikasi dari tiga komponen yaitu user interface, data management functions, dan task management facilities. Desain objek berfokus pada detil dari masing-masing class.[PRE01] c. Object oriented programming (OOP) Hasil dari OOD diimplementasikan dengan bahasa pemrograman yang berorientasi objek (misalnya menggunakan bahasa pemrograman C++ atau Java). d. Object oriented testing Pengujian dilakukan dengan melakukan review dari model hasil OOA dan OOD. Pengujian dilakukan secara sistematis, mulai dari masing-masing class dan operasi yang berlaku dalam class tersebut, kemudian dilanjutkan dengan pengujian interaksi class tersebut dengan class lain. Use-case yang sudah ada juga digunakan untuk mengetahui kesalahan yang ada pada pengujian. [PRE01]
II-10
2.6 Unified Process Proses pengembangan dan pembangunan perangkat lunak mengalami evolusi, seiring dengan perkembangan perangkat lunak yang semakin kompleks. Salah satu cara untuk memudahkan proses
pengembangan
perangkat
lunak
adalah
dengan
menggunakan
pemodelan.
Kebutuhan/permasalahan yang diberikan oleh pengguna perangkat lunak dijadikan sebagai suatu masukan bagi pengembang perangkat lunak yang kemudian dimodelkan untuk membangun perangkat lunak akhir. Pemodelan yang ada juga beragam, tergantung kepada permasalahan yang dihadapi oleh pihak pengembang dalam pembangunan perangkat lunak (masing-masing punya kelebihan untuk suatu domain permasalahan dan kelemahan untuk domain permasalahan yang lain). Karena keragaman pemodelan yang digunakan, ditemui suatu kesulitan karena tidak adanya suatu standar dalam proses pemodelan. Oleh karena itu, Ivar Jacobson, Grady Booch, dan James Rumbaugh membuat suatu penggabungan dari proses pembangunan perangkat lunak yang ada, dengan mengambil keunggulan dari model-model dan proses-proses yang beragam tersebut serta menamakannya Unified Process.
Gambar II-6 Hubungan antara Phase dan Workflow pada Unified Process
Unified Process adalah suatu proses pengembangan perangkat lunak, yaitu serangkaian kegiatan yang diperlukan untuk mengubah kebutuhan pengguna menjadi suatu perangkat lunak. Unified Process menekankan kepada tiga hal yaitu use-case driven, architecture centric, serta iterative dan incremental. 1. Use case driven Use case adalah suatu urutan aksi yang dilakukan oleh suatu sistem untuk memberikan suatu hasil atau nilai bagi aktor. Aktor adalah pengguna sistem yang berinteraksi dengan use case. Aktor adalah suatu peran dalam sistem, dapat berupa seseorang atau sistem lain. Dalam metode unified process ada beberapa workflow utama yang dilakukan dalam pembangunan
suatu
perangkat
lunak,
yaitu
requirement,
analysis,
design,
II-11 implementation, dan test. Sepanjang workflow ini, use case menjadi suatu tolok ukur dalam pembangunan perangkat lunak. Ada beberapa alasan use case baik digunakan dan diterima secara luas. Dua alasan utama adalah: 1) Memberikan suatu makna sistematik dan intuitif dari proses pengumpulan kebutuhan fungsional dengan fokus pada nilai tambah untuk pengguna. 2) Use case menggerakkan seluruh proses pengembangan, misalnya pada analisis, desain, dan tes mulai dilakukan dari use case. 2. Architecture centric Perangkat lunak bukanlah suatu benda nyata, oleh karena itu, proses pembangunan suatu perangkat lunak membutuhkan suatu pemahaman dasar antara pihak-pihak yang terlibat dalam proses pembangunan perangkat lunak yaitu berupa arsitektur perangkat lunak. Dengan adanya suatu arsitektur perangkat lunak, bisa didapat suatu gambaran umum dari berbagai sudut pandang mengenai perangkat lunak yang dibangun dan disepakati bersama. 3. Iterative and incremental Ide dasar dari metode iterative dan incremental adalah mengembangkan perangkat lunak dengan mengambil keuntungan dari hasil pengembangan perangkat lunak tahap sebelumnya. Langkah yang dilakukan dengan metode iterative dan incremental adalah membangun perangkat lunak mulai dari bagian kecil kebutuhan perangkat lunak, kemudian semakin dikembangkan fungsionalitasnya pada setiap siklus/iterasi yang dilakukan (ada perubahan versi pada setiap iterasi) begitu seterusnya sampai perangkat lunak akhir dihasilkan. Beberapa kegunaan dari pengembangan secara iterative dan incremental antara lain: 1) Untuk menangani resiko yang critical dan signifikan sejak awal (risk mitigation). 2) Membangun
suatu
arsitektur
yang
kokoh
(robust)
sebagai
panduan
pengembangan perangkat lunak. 3) Menyediakan suatu kerangka kerja yang dapat menangani perubahan kebutuhan dengan lebih baik. 4) Untuk membangun sistem sedikit demi sedikit menuju produk akhir daripada dibuat sekaligus (menekan biaya yang dibutuhkan untuk menangani perubahan pada akhir proses pengembangan). 5) Membuat proses pengembangan perangkat lunak yang memungkinkan staff bekerja lebih efektif (ada proses pembelajaran melalui iterasi/siklus yang ada).
2.6.1 Workflow Core workflow yang ada dalam suatu unified process antara lain:
II-12 1. Requirement Requirement dilakukan pada awal proses pengembangan perangkat lunak. Langkah ini bertujuan untuk memiliki suatu gambaran dan tujuan produk akhir yang benar. Hal ini dicapai dengan menjelaskan kebutuhan sistem dengan baik, sehingga sebuah kesepakatan dapat dicapai antara pihak pelanggan/pengguna dan pihak pengembang tentang batasan mengenai kemampuan sistem yang akan dibuat (yang dapat dan tidak dapat dilakukan oleh sistem). Akhir dari tahap requirement ini adalah suatu hasil berupa sekumpulan artifak yang digunakan sebagai milestone dalam tahap ini dan juga sebagai landasan bagi tahap berikutnya, yaitu tahap analisis. 2. Analysis Pengumpulan kebutuhan dari pengguna belum dapat menggambarkan sistem secara menyeluruh, oleh karena itu diperlukan tahap analisis untuk mengetahui lebih detil mengenai kebutuhan sistem lainnya. Pada tahap analisis dilakukan perbaikan terhadap kebutuhan yang sudah dihasilkan tahap sebelumnya dengan menggunakan model analisis. 3. Design Tujuan dari tahap perancangan antara lain: 1) Memahami secara mendalam khususnya mengenai kebutuhan non-fungsional dan batasan sistem. 2) Melakukan dekomposisi implementasi sistem sehingga dapat ditangani oleh tim pengembang. 3) Mampu menggambarkan antarmuka antar subsistem pada siklus awal pengembangan perangkat lunak. 4) Menghasilkan arsitektur perangkat lunak yang stabil dan cetak biru dari model implementasi. Tahap ini menghasilkan model desain dan deployment model yang akan digunakan sebagai input dari tahap berikutnya yaitu tahap implementasi. 4. Implementation Tujuan dari implementasi adalah: 1) Merencanakan integrasi sistem pada setiap integrasi (secara incremental). 2) Melakukan implementasi dari kelas perancangan dan subsistem yang ditemukan selama tahap perancangan. 3) Melakukan pengujian unit dan integrasi terhadap komponen sistem. Hasil dari tahap implementasi adalah model implementasi yang terdiri dari elemen berikut: 1) Implementasi subsistem dan keterkaitan, antarmuka, serta isinya. 2) Komponen sistem yang sudah diuji
II-13 3) Architectural view dari model implementasi. 5. Test Inti dari tahap ini adalah melakukan validasi terhadap hasil tahap implementasi. Tujuan pengujian adalah sebagai berikut: 1) Membuat rencana pengujian pada setiap iterasi, termasuk integration tests dan system tests. 2) Merancang dan membuat kasus pengujian (test case) 3) Melakukan bermacam tes dan menangani hasil tes tersebut secara sistematis. Hasil dari tahap ini adalah model pengujian yang terdiri dari: 1) Test cases 2) Test procedures 3) Test components
2.6.2 Phase 1. Inception Tujuan utama dari fase ini adalah menentukan business case dari sistem yang akan dibuat. Untuk membuatnya dibutuhkan empat langkah yaitu: 1) Membatasi lingkup dari sistem yang akan dibuat. 2) Menjelaskan kandidat arsitektur sistem. 3) Mengidentifikasi resiko yang akan mempengaruhi proses pembuatan sistem. 4) Pembuatan prototipe untuk meyakinkan kepada pengguna bahwa sistem yang akan dibangun dapat memberikan keuntungan kepada mereka. 2. Elaboration Produk dari fase ini adalah arsitektur sistem yang stabil dan rencana pembangunan sistem dengan kepastian keberhasilan yang tinggi. Pada fase ini langkah-langkah yang dilakukan antara lain: 1) Membuat standar arsitektur yang meliputi fungsionalitas dan fitur sistem yang penting. 2) Melakukan identifikasi resiko kritis yang akan mempengaruhi proses pembuatan sistem. 3) Menentukan standar yang akan diraih berdasarkan kualitas (misalnya reliability dan response time). 4) Melakukan implementasi terhadap use case fungsionalitas sampai kurang lebih 80% dari seluruh use case. 5) Mengajukan perkiraan yang meliputi jadwal, staff yang diperlukan, dan biaya yang diperlukan dalam batasan proses bisnis yang ada.
II-14 3. Construction Hasil dari fase ini adalah produk yang siap untuk diuji oleh pengguna (beta testing). Aktivitas yang dilakukan pada tahap konstruksi antara lain: 1) Memperluas identifikasi, deskripsi, dan realisasi use case sampai seluruh use case. 2) Menyelesaikan analisis, perancangan, implementasi, dan pengujian. 3) Menjaga integritas dari arsitektur, dan melakukan modifikasi jika perlu. 4) Melakukan pemantauan terhadap resiko kritis dan signifikan yang diakibatkan dari fase insepsi dan elaborasi, dan jika mungkin menangani resiko tersebut. 4. Transition Fase transisi merupakan proses adaptasi dari produk beta (beta release) terhadap lingkungan sistem yang ada. Aktivitas yang dilakukan pada fase ini antara lain: 1) Aktivitas persiapan 2) Memberikan saran kepada customer jika harus melakukan penyesuaian terhadap lingkungan yang ada sehingga sesuai dengan lingkungan perangkat lunak dapat bekerja. 3) Persiapan petunjuk penggunaan dan dokumentasi lain untuk produk akhir. 4) Menyesuaikan perangkat lunak untuk bekerja pada parameter sesungguhnya dari lingkungan pengguna. 5) Memperbaiki kesalahan atau kerusakan yang ditemukan sebagai umpan balik dari pengujian perangkat lunak versi beta. 6) Melakukan modifikasi terhadap perangkat lunak terhadap masalah-masalah yang belum ditemui. Fase transisi berakhir dengan produk akhir yang dapat berjalan dengan baik.
2.7 Standard Widget Toolkit (SWT) SWT pada dasarnya adalah GUI-library yang terintegrasi di dalam Eclipse sebagai fondasi GUI. Dalam hirarki Platform, SWT berada di dalam workbench Eclipse (Gambar II-7), yang merupakan dasar tampilan Eclipse tersebut. SWT secara khusus memang dikembangkan untuk Eclipse.
Gambar II-7 Arsitektur Eclipse
II-15 Kelebihan dari SWT bila dibandingkan dengan AWT dan Swing yang dikeluarkan SUN Microsystem antara lain: 1) Komponen SWT didesain untuk efisiensi, akses yang portable terhadap fasilitas UI (user interface) di mana SWT diimplementasi dan dikembangkan. 2) SWT lebih cepat dibandingkan Swing. 3) Native look & feel, di platform mana pun SWT berada, tampilannya telah disesuaikan dengan platform tersebut, seperti Linux, OS X dan Windows. 4) Desain yang sederhana. 5) Kode sumber dari SWT yang bersifat open source.
SWT terdiri dari beberapa paket utama yaitu: 1) org.eclipse.swt: paket ini memiliki kelas-kelas yang mendefinisikan konstanta dan exceptions yang digunakan oleh kelas-kelas SWT yang lain. Sebuah paket SWT terdiri dari tiga kelas: SWT, SWTException, dan SWTError. 2) org.eclipse.swt.widgets: paket ini memiliki komponen utama dari SWT widget, termasuk interface dan kelas pendukung. 3) org.eclipse.swt.events: paket ini mendefinisikan events dan listeners yang digunakan oleh komponen SWT. Paket ini memiliki tiga grup kelas yang berbeda, yaitu: Listener interfaces, kelas Adapter, dan kelas Event. 4) org.eclipse.swt.dnd: terdiri dari kelas-kelas yang mendukung fungsi drag-anddrop dari SWT widgets. 5) org.eclipse.swt.layout: terdiri dari kelas-kelas yang menyediakan fungsi penempatan dan pengaturan ukuran SWT widgets secara otomatis. 6) org.eclipse.swt.print: terdiri dari kelas-kelas yang menyediakan fungsi pencetakan/print bagi SWT widgets. 7) org.eclipse.swt.graphics: terdiri dari kelas-kelas yang mengimplementasikan points, rectangles, regions, colors, cursors, fonts, graphics contexts yang mengimplementasikan operasi penggambaran primitif, dan kelas yang menangani gambar baik untuk menampilkan gambar dan public API untuk melakukan loading/saving terhadap gambar.
Salah satu contoh penggunaan SWT dalam pembuatan aplikasi sederhana dapat dilihat pada Algoritma II-1.
II-16 import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; public class HelloWorld { public static void main (String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setText("My First SWT Application"); shell.setSize(300, 100); Label label = new Label(shell, SWT.NONE); label.setText("Hello, world! "); label.setSize(100, 50); label.setLocation(20, 20); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } shell.dispose(); } } Algoritma II-1 Kode Program HelloWorld.java dengan Menggunakan SWT
2.8 Graphical Editing Framework (GEF) Graphical Editing Framework atau GEF merupakan suatu library untuk memudahkan pembuatan suatu editor/tampilan grafik yang interaktif pada kakas pengembangan Eclipse. Komponen GEF dipisahkan menjadi dua plug-in (Gambar II-8) yaitu: a) GEF
(org.eclipse.gef)
-
sebuah
framework
yang
dibuat
di
atas
komponen/plug-in draw2d. b) Draw2d (org.eclipse.draw2d) - lightweight toolkit untuk menggambar dan melakukan layout di atas sebuah SWT (Standard Widget Toolkit) Canvas.
Gambar II-8 Layering dari Komponen Penyusun GEF
2.8.1 GEF (org.eclipse.gef) Draw2d berfokus pada penggambaran dan pengaturan dari figure secara efisien. Plug-in GEF menambahkan sebuah editing layer di atas Draw2d. Tujuan dari framework ini adalah untuk:
II-17 a) Memfasilitasi tampilan dari beberapa model yang ada secara grafik dengan menggunakan figure dari draw2d. b) Mendukung interaksi dari mouse, keyboard, atau Eclipse workbench. c) Menyediakan komponen umum yang berhubungan dengan tujuan a) dan b). GEF dibangun atas arsitektur Model-View-Controller (MVC). MVC merupakan sebuah pola arsitektur pada rekayasa perangkat lunak. Dengan menerapkan MVC, maka yang terjadi adalah isolasi antara business logic dengan user interface, sehingga menghasilkan suatu aplikasi yang lebih fleksibel (perubahan terhadap user interface tidak mempengaruhi business logic perangkat lunak, begitu juga sebaliknya). Penggambaran hubungan antara Model-ViewController dapat dilihat pada Gambar II-9.
2.8.1.1 Model Model merupakan sebuah objek yang dapat menyimpan data. Beberapa persyaratan dari sebuah model yang harus diketahui antara lain: a) Model harus menyimpan semua data penting yang akan diubah oleh pengguna. b) Model tidak boleh mengacu/mengetahui mengenai tampilannya. Model hanya berfungsi sebagai penampung data saja. c) Model harus mengimplementasikan semacam mekanisme notifikasi (khususnya jika terjadi perubahan data pada model). Saat pengguna berinteraksi dengan figure, sebuah Command diciptakan untuk melakukan enkapsulasi perubahan terhadap model dan melakukan validasi terhadap aksi pengguna (mendukung aksi undo dan redo terhadap model), sehingga pengguna tidak melakukan perubahan terhadap model secara langsung.
Gambar II-9 High Level View dari GEF (org.eclipse.gef)
II-18 2.8.1.2 View (Figures/Treeitems) View merupakan sekumpulan objek yang melakukan fungsi penggambaran pada layar. Pada GEF, penggambaran model yang ada dilakukan menggunakan plug-in draw2d. Beberapa ketentuan yang harus dimiliki oleh view: a) View tidak boleh menyimpan data penting yang tidak tersimpan pada model. b) View tidak boleh memiliki referensi kepada model atau controller (bersifat independen).
2.8.1.3 Controller (EditPart) Karena view tidak memiliki referensi terhadap model dan sebaliknya, maka hubungan antara model dan view merupakan tanggung jawab controller. Pada GEF, controller merupakan subclass dari editpart. Terdapat tiga macam cara dasar untuk melakukan subclass dari editpart, yaitu menggunakan AbstractTreeEditPart untuk editpart yang ada pada tree viewer,
melakukan
extend
terhadap
AbstractGraphicalEditPart
dan
AbstractConnectionEditPart untuk editpart yang ada pada graphical viewers. Ada editpart antara setiap objek model dan view yang akan direpresentasikan secara grafik, dengan kata lain jika sebuah model memiliki anak, maka untuk setiap anak terdapat editpart yang bersesuaian juga dengan figure-nya (Gambar II-10).
Gambar II-10 Hubungan Model-View-Controller
2.8.2 Draw2D (org.eclipse.draw2d) Draw2d adalah satu kakas lightweight dari komponen berbasis grafik yang disebut figure. Lightweight berarti bahwa satu figure hanya merupakan sebuah objek java, tanpa sumber daya bersangkutan pada sistem operasi. Figure dapat disusun melalui satu hubungan parent-child. Setiap figure mempunyai satu batasan berbentuk segi-empat di dalamnya sebagai tempat bagi figure dan anak-anaknya untuk digambar (Gambar II-11).
Gambar II-11 Ilustrasi tentang Figure
II-19 Penggambaran figure Figure dapat menggambar dirinya sendiri. Figure digambar dengan menggunakan Graphics. Graphics merupakan Method Figure.paint(Graphics) digunakan untuk menggambar suatu figure. Saat method ini dipanggil, method ini melakukan beberapa hal: 1. Menggambar figure dengan memanggil method paintFigure(Graphics). 2. Menggambar anak-anak dari figure secara rekursif dengan memanggil method paint(Graphics) pada setiap anak-anaknya sesuai dengan urutan tampilan pada list
pada
client
area
(yang
dibuat
dengan
menggunakan
method
Figure.paintClientArea()). 3. Menggambar
batasan/border
dari
figure
yang
terbentuk
dengan
method
Figure.paintBorder().
Hasil proses penggambaran ini adalah komposisi figure (yang secara struktur berbentuk pohon/tree). Urutan penggambaran figure dimulai dari root figure kemudian diikuti oleh anak-anaknya, Jika figure A merupakan anak dari B pada pohon figure, hal itu berarti figure A akan digambar di atas figure B. Asosiasi bentuk pohon/tree dengan gambar yang ditampilkan dapat dilihat pada Gambar II-12.
Gambar II-12 Figure dan Hasil Gambar Figure
Layout Manager Layout manager terdapat pada setiap figure dan merupakan objek yang bertanggung jawab untuk mengatur batasan/bound dari anak-anak figure dimana layout manager berada. Sebuah layout manager dapat digunakan untuk menempatkan children berdasarkan indeks dan/atau batasan mereka. Sebuah graphical user interface (GUI) yang dibangun menggunakan draw2d didefinisikan dengan pohon dari figure yang dibuat oleh LightweightSystem untuk menggambar GUI (Gambar II-13).
II-20
Gambar II-13 High Level View dari Draw2d
Salah
satu
contoh
penggunaan
GEF
dapat
dilihat
pada
contoh
EditPart
(PersonEditPart.java) dari sebuah model Person pada Algoritma II-2. import java.beans.*; import org.eclipse.gef.*; import org.eclipse.gef.editparts.*; public class PersonEditPart extends AbstractGraphicalEditPart implements PropertyChangeListener { ... public void activate(){ if(!isActive()) ((Person)getModel()).addPropertyChangeListener(this); super.activate(); } public void deactivate(){ ((Person)getModel()).removePropertyChangeListener(this); super.deactivate(); } public void propertyChange(PropertyChangeEvent ev){ if (ev.getPropertyName().equals(Person.PROPERTY_NAME)) refreshVisuals(); else if (ev.getPropertyName().equals(Person.PROPERTY_FRUITS)) refreshChildren(); } public void refreshVisuals(){ IPersonFigure figure = (IPersonFigure)getFigure(); Person model = (Person)getModel(); figure.setName(model.getName()); figure.setSurname(model.getSurname)); super.refreshVisuals(); } ... } Algoritma II-2 Kode Program PersonEditPart.java dengan Menggunakan GEF