II-1
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-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 terus-
menerus 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
Transactionmanager 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-and-
drop 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
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:
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(); } }
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-View-
Controller 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.
Algoritma II-2 Kode Program PersonEditPart.java dengan Menggunakan GEF
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(); } ... }