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(); } ... }