7

BAB 2

LANDASAN TEORI

2.1 e-Application Berbasiskan Web

Aplikasi e-app berbasiskan Web adalah suatu aplikasi yang dapat membentuk

halaman – halaman web berdasarkan permintaan pemakai. Aplikasi ini adalah aplikasi

yang berbasiskan client/server melalui suatu media jaringan. Client mewakili komputer

yang digunakan oleh seorang pemakai yang hendak menggunakan aplikasi, sedangkan

server mewakili komputer yang menyediakan layanan aplikasi. Dalam konteks e-

application berbasiskan web, client dan server berhubungan melalui internet dan

intranet. Yang menarik, model client/server yang menggunakan aplikasi web dapat

melibatkan bermacam – macam plathform.

Ciri khas lain pada penggunaan aplikasi web, pemakai menggunakan perangkat

lunak yang dinamakan web browser atau yang biasa disebut browser saja (misalnya,

Internet Explorer, MozillaFirefox, Google Chrome) untuk mengakses aplikasi web yang

diletakan didalam web server. Server web adalah sebuah perangkat lunak server yang

berfungsi menerima permintaan HTTP atau HTTPS dari klien yang dikenal dengan

browser web dan mengirimkan kembali hasilnya dalam bentuk halaman-halaman web

yang umumnya berbentuk dokumen HTML. Server web yang terkenal diantaranya

adalah Apache Web Server, Apache TomCat dan Microsoft Internet Information Service

(IIS). Apache merupakan server web antar-platform, sedangkan IIS hanya dapat

beroperasi di sistem operasi Windows.

Komputer yang bertindak sebagai server umumnya menyediakan database server,

selain software web server yang ditujukan untuk melayani permintaan pemakai yang

8

hendak mengakses aplikasi web. Database server adalah server yang melayani akses

terhadap database. Contoh dari software database server yang tersedia dipasarana adalah

Oracle 11g , Microsoft SQL Server 2008 dan MySQL 5.0

2.2 Arsitektur three-tier client server untuk e-Application

Arsitektur three-tier client/server adalah arsitektur hasil proses evolusi dari two-

tier client server. Pola arsitektur ini diciptakan untuk menutup kelemahan yang ada

didalam arsitektur two-tier client/server. Konsep dari arsitektur three-tier client/server

membagi lapisan client/server menjadi tiga tier. Tier yang pertama disebut dengan data

server. Tier ini umumnya mengimplementasi problem domain model. Tier yang kedua

adalah application server. Tier ini umumnya mengimplementasi function dan interface

system. Tier yang ketiga adalah thin client. Tier ini biasanya hanya mengimplementasi

user interface.

Dibuatnya tier application server pada dasarnya bertujuan untuk mengurangi

beban data server yang dalam two-tier client/server berperan sebagai centralized server.

Untuk menangani request dari computer client yang jumlahnya sangat banyak, computer

application server jumlahnya dapat dipasang lebih dari satu unit. Dengan begitu

diharapkan penggunaan arsitektur three-tier dapat memangkas waktu akses sehingga

menjadi relative rendah.

9

ServerData

Application Server

ThinClient

ThinClient

ThinClient

Printer

Gambar 2.1 Three-Tier Client/Server (Irwanto, 2007)

Kehebatan arsitektur three-tier client/server ditandai dengan adanya fitur load

balancing pada tier application server. Dimana sinkonisasi beberapa application server

dapat melakukan load balancing secara dinamis. Dengan load balancing praktis tidak

ada satu application server yang sangat sibuk sementara application server yang lainnya

terlalu santai.

Tidak cukup sampai disitu, arsitektur three-tier client/server juga dilengkapi

dengan fitur fault tolerance. Ketika sebuah application server down atau crash, maka

dengan fitur fault tolerance semua thin client yang terhubung dengan application server

yang crash akan di-switch secara otomatis ke application server yang lain tanpa harus

melakukan kompilasi ulang thin client. Dengan fitur fault tolerance ini diharapkan

kinerja software system menjadi high level robustness.

Arsitektur three-tier client/server memiliki tingkat fleksibilitas yang tinggi

terhadap perubahan. Andaikan terjadi perubahan pada tingkat functionality didalam

10

applikasi, maka kita cukup mengkompilasi ulang atau menginstall ulang application

server. Semua thin client yang berhubungan dengan application server tersebut, entah

berapa jumlahnya ataupun entah dimana ia berada maka ia akan menjalani perubahan itu

dengan sendirinya.

Dengan dijelaskanya arsitektur dan fitur dari three-tier client server seolah-olah

arsitektur ini tidak terdapat kekurangan. Sebenarnya kekurangan nya ada, membuat

software system dengan three-tier client/server tidaklah simple seperti two-tier atau

dengan kata lain proses development nya lebih kompleks.

Secara umum terdapat 2 jenis application server yaitu web server dan midle tier

application server. Web server adalah internet server yang berfungsi untuk menangani

request dari client (internet browser). Web server akan memberikan data-data yang

diminta oleh client setelah memproses request. Perangkat lunak web server yang banyak

terdapat dipasaran adalah Apache web server, Apache Tomcat, Microsoft IIS dan

sebagainya. Sementara middle tier application server adalah server yang tugasnya

mengimplementasi business rules. Didalam platform Java, middle tier application server

typically adalah J2EE application server seperti contoh nya JBOSS, Oracle Web Logic,

Sun GlassFish Application server. Umumnya application tersebut mengimplementasi

EJB container. EJB sendiri berperan sebagai component yang mengenkapsulasi business

rules.

2.3 Database

Menurut C.J Date (2000, p13), database adalah sistem terkomputerisasi yang

tujuan utama adalah memelihara informasi dan membuat informasi tersedia saat

11

dibutuhkan. Sebuah system database dapat memiliki beberapa database. Setiap

database dapat berisi / memiliki sejumlah objek database, yang antara lain yaitu :

a. Field

Field adalah sekumpulan kecil dari kata atau sebuah deretan angka –

angka.

b. Record

Record adalah kumpulan dari file yang berelasi secara logis. Contoh :

nama, alamat, nomor telepon, dan sebagainya.

c. File

File atau berkas adalah kumpulan dari record yang berelasi secara logis.

Contoh : berkas transaksi toko A yang mempunyai record tanggal, kode

barang, dan harga.

d. Entity

Entity adalah orang, tempat, benda, atau kejadian yang berkaitan dengan

informasi yang disimpan. Contoh : pelanggan, pekerja, dan sebagainya.

e. Attribute

Attribute adalah karakteristik yang menjelaskan suatu entity. Contoh :

nama pelanggan, umur pekerja, dan sebagainya.

f. Primary key

12

Primary key adalah sebuah field yang nilainya unik yang tidak sama

antara satu record dan record lain. Primary key digunakan sebagai tanda

pengenal suatu tanda pengenal dari suatu field.

g. Foreign key

Foreign key adalah sebuah field yang nilainya berguna untuk

menghubungkan primary key lain yang berada pada table yang berbeda.

2.3.1 Relational Database

Relational database adalah representasi logical dari data yang berbentuk tabel.

Data tersebut dapat diakses tanpa ada ketergantungan dengan struktur fisik dari database

tersebut. Relational database merupakan sistem database yang paling banyak dipakai

saat ini. Salah satu bahasa yang sering dipakai untuk memanipulasi data adalah SQL.

Data dalam relational database disimpan didalam table dmana terdapat kolom dan baris

(Connoly, 2002).

Model relasional ini didasarkan pada konsep matematika dari suatu hubungan,

yang secara fisik direpresentasikan sebagai sebuah tabel. Suatu relasi adalah tabel

dengan kolom dan baris. Sebuah RDBMS hanya memerlukan database yang dirasakan

oleh pengguna sebagai tabel. Namun, persepsi ini hanya berlaku untuk struktur logis dari

database, itu tidak berlaku untuk struktur fisik dari database, yang dapat

diimplementasikan dengan menggunakan berbagai struktur penyimpanan.

Atribut adalah suatu properti dari suatu entitas atau jenis hubungan. Sifat khusus

dari suatu jenis entity disebut atribut. Dalam model relasional, hubungan yang

digunakan untuk menyimpan informasi tentang objek yang harus diwakili dalam

13

database. Relasi direpresentasikan sebagai sebuah tabel dua dimensi di mana baris tabel

sesuai dengan catatan pribadi dan kolom tabel sesuai dengan atribut. atribut dapat

muncul dalam urutan apapun dan hubungan tersebut tetap akan hubungan yang sama,

dan karena itu menyampaikan makna yang sama.

Domain adalah himpunan nilai-nilai yang diperbolehkan untuk satu atau lebih

atribut. Domain merupakan fitur yang sangat kuat dari model relasional. setiap atribut

relasi didefinisikan pada domain. Domain mungkin akan berbeda untuk setiap atribut,

atau dua atau lebih atribut dapat didefinisikan di domain yang sama. Konsep domain

adalah penting karena memungkinkan pengguna untuk menentukan di tempat pusat

makna dan sumber nilai-nilai bahwa atribut dapat terus. Sebagai hasilnya, lebih banyak

informasi tersedia untuk sistem ketika melakukan pelaksanaan operasi relasional, dan

operasi yang secara semantik tidak benar dapat dihindari. Tuple adalah deretan relasi.

Unsur relasi adalah baris atau tupel dalam tabel. Sebaliknya, jumlah tupel disebut

cardinality dari hubungan dan perubahan ini sebagai tupel yang ditambahkan atau

dihapus. Kardinalitas adalah milik perluasan hubungan dan ditentukan dari contoh

khusus dari relasi pada saat tertentu. Akhirnya, kita memiliki definisi database

relasional: kumpulan hubungan normalisasi hubungan dengan nama yang berbeda.

Database relasional terdiri dari hubungan yang tepat terstruktur. Kita lebih suka

kesesuaian ini sebagai normalisasi. Aturan intergritas yang pertama berlaku untuk

primary key sebagai dasar hubungan adalah:

1. Entity integrity

Dalam hubungan dasar, tidak ada atribut dari primary key yang bisa null.

Menurut definisi, primary key adalah minimal identifier yang digunakan untuk

14

mengidentifikasi tupel secara unik. Ini berarti tidak ada subset dari primary key

yang cukup untuk menyediakan identifikasi yang unik dari tuple. Jika kita

membiarkan null untuk setiap bagian dari primary key, kami menyiratkan bahwa

tidak semua atribut diperlukan untuk membedakan antara tuple, yang

bertentangan dengan definisi dari primary key.

2. Referential integrity

Aturan integitas kedua yang berlaku merupakan foreign key. Jika foreign

key yang ada di relasi, tiap-tiap nilai dari foreign key harus cocok dengan nilai

candidate key dari beberapa tuple dalam satu hubungan atau nilai kunci asing

harus sepenuhnya null.

2.3.1.1 Data Modeling

Dua tujuan utama dari data model adalah untuk membantu dalam memahami

(semantik) yang berarti data dan memfasilitasi komunikasi tentang persyaratan

informasi. Sebuah data model membuat lebih mudah untuk memahami makna data, dan

dengan demikian kita data model untuk memastikan bahwa kita mengerti:

• Perspektif setiap user data;

• Sifat data itu sendiri, independen dari representasi fisik;

• Penggunaan data di tampilan pengguna.

Tingkat tinggi yang paling populer dalam data model yang digunakan dalam desain

database, dan yang kami gunakan dalam buku ini, didasarkan pada konsep dari Entity-

Relationship (ER) model.

15

2.3.1.2 Phases database design

Menurut Connoly (2002), database desain dibuat untuk tiga tahap utama, yaitu

konseptual, logis, dan desain fisik.

‐ Conceptual database design adalah proses membangun model informasi yang

digunakan dalam suatu perusahaan, independen dari semua pertimbangan fisik.

Langkah pertama desain database disebut desain database konseptual, dan

melibatkan penciptaan model data konseptual dari bagian dari perusahaan yang

kita tertarik dalam pemodelan. Model data dibangun menggunakan dokumen

informasi yang saya persyaratan spesifikasi pengguna. Sepanjang proses

mengembangkan sebuah model data konseptual, model diuji dan divalidasi

terhadap persyaratan pengguna.

‐ Logical database design adalah proses membangun model informasi yang

digunakan dalam suatu perusahaan yang didasarkan pada model data tertentu,

tetapi independen dari DBMS tertentu dan pertimbangan fisik lainnya.

Merupakan fase kedua dari desain database, yang menghasilkan penciptaan

model data logis dari bagian perusahaan yang kita tertarik pada pemodelan. Data

model konseptual yang dibuat pada fase sebelumnya adalah halus dan dipetakan

ke model data logis. Selama proses pengembangan model data logis, model diuji

dan divalidasi terhadap persyaratan pengguna. Teknik normalisasi digunakan

untuk menguji kebenaran dari model data logis. Normalisasi memastikan bahwa

hubungan yang berasal dari data model tidak menampilkan data redundansi.

Menyediakan physical database designer dengan sarana untuk membuat

pengorbanan yang sangat penting untuk desain database yang efisien.

16

‐ Physical database design adalah proses memproduksi deskripsi implementasi

database pada penyimpanan sekunder, tetapi menggambarkan hubungan dasar,

organisasi file, dan indeks yang digunakan untuk mencapai akses yang efisien

terhadap data, dan setiap kendala terkait integritas dan langkah-langkah

keamanan. Merupakan tahap akhir dari proses perancangan basis data. Meskipun

struktur ini adalah DBMS-independent, dikembangkan sesuai dengan model data

tertentu seperti jaringan, relasional, atau hierarkis. Dalam mengembangkan

desain database fisik, pertama-tama kita harus mengidentifikasi sistem database

target. Oleh karena itu, desain fisik disesuaikan dengan sistem DBMS tertentu.

Tujuan utama dari physical database design adalah untuk menjelaskan

bagaimana kita berniat untuk mengimplementasikan logical database design.

Untuk relational model ini meliputi:

Membuat satu set tabel relasional dan kendala pada tabel ini dari

informasi yang disajikan dalam logical data model;

Mengidentifikasi struktur penyimpanan yang spesifik dan metode akses

data untuk mencapai kinerja yang optimal untuk sistem database;

Merancang perlindungan keamanan untuk sistem.

Idealnya, konseptual dan logical database design untuk sistem yang lebih besar harus

dipisahkan dari desain fisik karena tiga alasan utama:

Ini berkaitan dengan subjek yang berbeda - apa, bukan bagaimana;

Hal ini dilakukan pada waktu yang berbeda-apa yang harus dipahami sebelum

bagaimana dapat ditentukan;

17

Hal ini membutuhkan keahlian yang berbeda, yang sering ditemukan pada orang

yang berbeda

‐ Logical database design untuk relational model

Langkah 2 membangun dan memvalidasi logical data model.

Langkah 2.1 Hapus fitur yang tidak kompatibel dengen model relasional

(langkah opsional)

Langkah 2.2 Turunan relasi untuk logical data model lokal .

Langkah 2.3 Validasikan hubungan dengan menggunakan normalisasi

Langkah 2.4 Validasi hubungan terhadap transaksi pengguna

Langkah 2.5 Tentukan batasan integritas

Langkah 2.6 Review logical data model dengan pengguna

Langkah 3 Membangun dan memvalidasi global logical data model.

Langkah 3.1 Gabungkan local logical data models ke dalam model global

Langkah 3.2 Validasi global logical data model

Langkah 3.3 Periksa pertumbuhan di masa depan

Langkah 3.4 Review global logical data model dengan pengguna

‐ Physical database design untuk relational databases

Langkah 4 Menerjemahkan logical data model untuk DBMS yang dipilih

Step 4.1 Merancang relasi-relasi dasar

Step 4.2 Merancang representasi data yang berasal

Step 4.3 Merancang kendala-kendala perusahaan

Langkah 5 Merancang physical representation

Step 5.1 Menganalisi transaksi

18

Step 5.2 Memilih file-file organisasi

Step 5.3 Memilih indeks-indeks

Step 5.4 Memperkirakan kebutuhan disk space.

Langkah 6 Mendesain user view

Langkah 7 Mendesain mekanisme keamanan

Langkah 8 Mempertimbangkan pengenalan dalam pengkontrolan redundancy

Langkah 9 Memantau dan tune sistem operasional

2.3.2 SQL

Tujuan dari SQL

Idealnya, bahasa basis data harus memungkinkan user untuk:

Membuat database dan struktur relational;

Melakukan tugas-tugas dasar manajemen data, seperti penyisipan, modifikasi, dan

penghapusan data dari hubungan;

Melakukan kedua query sederhana dan kompleks.

Bahasa database harus melakukan tugas ini dengan meminimalkan effort dari user,

dan struktur juga sintaks perintah harus relatif untuk mudah dipelajari. Sebuah bahasa

pemrograman juga harus portabel, yaitu harus sesuai dengan beberapa standar yang

diakui sehingga kita dapat menggunakan struktur dan sintaks perintah yang sama ketika

pindah dari DBMS ke yang lainnya. Dan SQL dimaksudkan untuk memenuhi

persyaratan ini.

19

Sebagai sebuah bahasa pemrograman, standar ISO SQL memiliki dua komponen

utama:

Data Definition Language (DDL) untuk mendefinisikan struktur database dan

mengkontrol akses ke data. DDL ini berfungsi lebih ke dalam memanipulasi

struktur dari database. Contohnya, DDL ini dapat digunakan untuk membuat

table atau menghapus table, selain itu dapat membuat key atau index dengan

menggunakan DDL ini, membuat relasi antar table juga bisa dilakukan dengan

DDL ini. Beberapa statemen atau sintaks yang sering dijumpai didalam DDL

adalah sebagai berikut:

‐ CREATE TABLE, bertugas untuk membuat table;

‐ ALTER TABLE, bertugas untuk merubah struktur suatu table;

‐ DROP TABLE, bertugas untuk menghapus suatu table;

‐ CREATE INDEX, bertugas untuk membuat suatu index dalam table;

‐ DROP INDEX, bertugas untuk menghapus suatu index dalam table.

Data Manipulation Language (DML) untuk mengambil dan mengupdate data.

Merupakan sekumpulan sintaks-sintaks atau statemen untuk mengakses data

dalam database, tetapi SQL sendiri juga bisa digunakan untuk melakukan proses

insert, update, atau delete. Berikut ini adalah penjelasan singkat dari sintaks-

sintaks tersebut:

‐ SELECT, bertugas untuk mengakses data dari suatu table dalam database;

20

‐ UPDATE, bertugas untuk mengupdate atau merubah data dalam suatu table pada

database;

‐ DELETE, bertugas untuk menghapus data dari suatu table dalam database;

‐ INSERT, bertugas untuk menambahkan data ke dalam suatu table dalam

database.

2.4 Rekaryasa Perangkat Lunak

Software engineering adalah pembentukan dan penggunaan prinsip-prinsip

engineering untuk memperoleh software secara ekonomis yang handal dan bekerja

secara efisien pada mesin yang nyata.

IEEE mendifinisikan software engineering sebagai penerapan suatu pendekatan

yang sistematis, disiplin dan terkuantifikasi atas pengembangan, penggunaan dan

pemeliharaan perangkat lunak, serta studi atas pendekatan –pendekatan ini, yaitu

penerapan pendekatan engineering atas perangkat lunak.

Gambar 2.2 Software engineering layers

Software engineering adalah teknologi yang berlapis. Seperti yang terlihat pada

gambar 2.2, teknik pendekatan apapun (termasuk software engineering) harus bertumpu

pada komitmen organisasi terhadap kualitas. Manajemen kualitas total, Six Sigma, dan

filosofi yang sama dan filosofi yang sama mengembangkan budaya proses perbaikan

21

berkesinambungan, dan inilah budaya yang akhirnya mengarah pada pengembangan

pendekatan yang semakin lebih efektif untuk rekayasa perangkat lunak. landasan yang

mendukung rekayasa perangkat lunak adalah quality focus. Dasar untuk rekayasa

perangkat lunak adalah proses lapisan atau process layer. Proses rekayasa perangkat

lunak adalah perekat yang memegang lapisan teknologi bersama-sama dan

memungkinkan pengembangan rasional dan tepat waktu dalam pengembangan

perangkat lunak komputer. Proses perangkat lunak membentuk dasar bagi kontrol

manajemen proyek perangkat lunak dan menetapkan konteks di mana metode teknis

yang diterapkan, produk kerja (model, dokumen-dokumen, data, laporan, formulir, dll)

diproduksi, tonggak ditetapkan, kualitas dijamin, dan perubahan adalah dikelola dengan

baik.

Metode rekayasa perangkat lunak menyediakan teknik “bagaimana” untuk

membangun perangkat lunak. Metode mencakup array yang luas dari tugas yang

meliputi komunikasi, analisis persyaratan, pemodelan desain, konstruksi program,

pengujian, dan dukungan. Metode rekayasa perangkat lunak bergantung pada

seperangkat prinsip-prinsip dasar yang mengatur setiap area teknologi dan termasuk

aktifitas modeling dan teknik lainnya deskriptif.

Alat Software engineering memberikan dukungan otomatis atau semi-otomatis

untuk proses dan metode. Ketika Alat yang terintegrasi sehingga informasi yang dibuat

oleh salah satu alat yang dapat digunakan oleh yang lain, sebuah sistem untuk

mendukung pengembangan perangkat lunak, yang disebut computer-aided software

engineering, yang ditetapkan.

22

2.4.1 Model Software Development Process

Ada beberapa model proses software yang umum digunakan, contohnya adalah

Model Sekuensial Linear, Unified Process (UP). Sekuensial Linear ini juga dikenal

dengan nama “Classic Life Cycle ” atau “Waterfall Model”. Model ini adalah model

klasik yang pertama kali ada dan bersifat sistematis, berurutan dalam membangun

software. Setelah muncul model water fall, seiring dengan berjalan nya waktu model-

model lain pun bermunculan. Salah satu model yang muncul dalam waktu belakangan

ini adalah Unified Process (UP) yang gambar model nya seperti dibawah ini:

Gambar 2.3 Unified Process (Larman, C. 1998)

Model ini menggunakan phase dan iterasi di dalam pengembangan perangkat

lunak. Di dalam setiap iterasi terdapat requirements, design, implementation, dan system

test. Dari setiap iterasi terdapat proses penambahan atau incremental. UP menggunakan

23

konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model

dengan menggunakan Unified Model Language (UML).

Tahapan yang dilakukan pada setiap iterasi di dalam UP adalah sebagai berikut:

1. Requirements – pada tahapan ini requirement analysis untuk aplikasi

dilakukan. Pada tahap ini proses pengumpulan kebutuhan user yang berkaitan

dengan software yang akan dibangun dilakukan secara intensif. Proses

capturing requirement dilakukan dengan teknik wawancara dengan end-user

dan owner kemudian disusul dengan pembuatan use case diagram awal untuk

memberikan menggambarkan bentuk software yang akan dibangun kepada

end-user dan owner.

2. Analysis & Design – Fase analysis dan design fase crusial pada masa

pengembangan piranti lunak. Fase analysis kita menganalisa apa yang terjadi

pada problem domain, apa yang dibutuhkan oleh system dalam rangka

memonitor dan memaintain problem domain. Fase design berbicara tentang

bagaimana mem-produce solusi agar software yang dibangun dapat

memenuhi requirement yang diinginkan oleh user.

3. Implementation – Mengimplementasikan hasil perancangan piranti lunak

kedalam kode program perangkat lunak yang dapat dieksekusi oleh

computer.

4. Test – Fase testing dilakukan untuk mengetahui apakah software yang

dibangun telah berjalan dengan baik sesuai yang diinginkan, serta menguji

kelayakan sistem untuk di deploy. Proses pengujian berfokus pada logika

internal perangkat lunak, memastikan bahwa semua pernyataan sudah diuji.

24

Pada fase ini kita memastikan bahwa input yang diberikan setelah diproses

dapat memberikan output yang valid dan actual sesuai dengan yang

dibutuhkan.

5. Deployment – Pada tahapan ini sistem mulai digunakan oleh user.

Gambar 2.4 Schedule-oriented terms in the UP (Larman, C. 1998)

Life Cycle UP dibagi kedalam empat fase yaitu sebagai berikut:

1. Inception— pada tahap ini, awal sebuah ide dikembangkan menjadi visi

produk, memeriksa dan mengkonfirmasi pemahaman tentang inti kenapa

proyek ini harus dicoba. Tahap awal menetapkan kelayakan produk dan

menentukan ruang lingkup proyek.

2. Elaboration—pada tahap ini mayoritas dari use-case ditetapkan secara rinci

dan arsitektur sistem dirancang. Fase ini berfokus pada kemampuan proyek.

Tahap ini mengidentifikasi resiko dan jadwal, staf dan profil biaya untuk

keseluruhan proyek.

25

3. Construction—Selama tahap kontruksi, produk dipindahkan dari arsitektur

dasar ke keseluruhan sistem secara lengkap. Arsitektural yang tadinya

dirancang diterapkan ke dalam sistem dengan menggunakan kode.

4. Transition—pada fase terakhir ini system di deploy ke users. Feedback dari user

diterima dan digunakan untuk perbaikan kedepannya. Fase ini juga termasuk

konversi system dan pelatihan users. Fase ini sering diawali dengan rilis beta

dari aplikasi.

2.4.2 Requirements Engineering

Requirements analysis adalah kegiatan rekayasa perangkat lunak yang berfokus

kepada pengumpulan kebutuhan user dan menganalisis kebutuhan itu. Kegiatan ini harus

disesuaikan dengan kebutuhan proses, proyek, produk, dan orang yang melakukan

pekerjaan. Dari perspektif proses software, Requirements Engineering (RE) adalah

tindakan rekayasa perangkat lunak yang dimulai selama kegiatan berkomunikasi dan

berlanjut sampai ke kegiatan modeling team harus dapat menyesuaikan pada pendekatan

requirements engineering yang ada, namun proses adaptasi bukan berarti harus

ditinggalkan.

Adalah penting bahwa software team membuat upaya nyata untuk memahami

requirements atau permintaan-permintaan didalam problem sebelum team berupaya

untuk memecahkan masalah dari requirements. Requirements engineering membentuk

dasar yang solid untuk desain dan konstruksi. Tanpa ini, perangkat lunak yang

dihasilkan akan memiliki probabilitas tinggi dan tidak memenuhi kebutuhan pelanggan.

Requirements engineering menyediakan mekanisme yang tepat untuk memahami

apa yang diinginkan oleh pelanggan, menganalisis kebutuhan, menilai kelayakan,

26

menegosiasikan solusi yang masuk akal, menentukan solusi jelas, memvalidasi

spesifikasi, dan mengelola persyaratan sebagaimana mereka berubah menjadi suatu

sistem operasional. Proses Requirements engineering dicapai melalui pelaksanaan tujuh

fungsi yang berbeda: permulaan, pendatangan, elaborasi, negosiasi, spesifikasi, validasi,

dan manajemen.

Penting untuk dicatat bahwa beberapa fungsi Requirements engineering terjadi

secara paralel dan semuanya disesuaikan dengan kebutuhan proyek. Semua berusaha

untuk menentukan apa yang diinginkan oleh pelanggan, dan semua berfungsi untuk

membangun landasan yang kokoh untuk desain dan konstruksi dari apa yang pelanggan

mendapat.

2.4.3 Object Oriented Analysis and Design

Hal yang paling penting dalam metode OOA&D (selanjutnya akan disebut

OOAD) menggunakan obyek dan kelas sebagai konsep dasar dan terbentuk pada empat

prinsip dasar untuk analisa dan desain: memodelkan konteks sistem, menekankan pada

pertimbangan arsitektural, penggunaan kembali pola yang mengekspresikan ide desain

yang telaih dibangun dengan baik, dan menyatukan metode untuk setiap situasi

pengembangan. Prisinp ini adalah dasar dari OOAD dan turunannya (Mathiassen et al

2000).

OOAD adalah pendekatan software engineering yang memodelkan sistem sebagai

sekelompok obyek yang saling berinteraksi. Setiap obyek mewakili entity dalam sistem

yang dimodelkan, dan dikarakteristikkan oleh kelasnya, state (elemen data), dan

behavior-nya. Banyak model dapat dibuat untuk menunjukkan struktur statik, sifat yang

27

dinamis, dan run-time deployment dari obyek yang berkolaborasi. Ada sejumlah notasi

untuk merepresentasikan model ini, contohnya Unified Modeling Language (UML).

Object-Oriented analysis (OOA) menggunakan teknik modeling obyek untuk

menganalisa kebutuhan fungsional pada sebuah sistem. Object-oriented design (OOD)

memperinci model analisis untuk menghasilkan spesifikasi implementasi. OOA fokus

pada apa yang akan dilakukan sistem, sementara OOD fokus pada bagaimana sistem

melakukannya.

2.4.3.1 Aktivitas Utama Dalam OOAD

OOAD adalah sekumpulan panduan umum untuk melakukan analisa dan desain.

Oleh karena itu harus dipadukan pada organisasi dan proyek. Untuk membuat metode

lebih berguna, beradaptasi, perbaikan, dan pergantian bagian akan mudah

diimplementasikan.

OOAD menggambarkan empat sudut pandang utama pada sistem dan konteksnya:

Isi sistem informasi, bagaimana sistem akan digunakan, sistem secara keseluruhan dan

komponen-komponen sistem. Sudut pandang ini di sambungkan pada analisa, desain

arsitektural, dan desain komponen secara berurutan. Setiap aktivitas memberi hasil yang

spesifik, yang nantinya akan dimasukkan dalam dokumentasi analisa dan desain.

Dokumen aktivitas ini akan tergantung pada bagaimana OOAD dipadukan sesuai

dengan kebutuhan proyek.

Hal utama yang harus dilakukan sebelum mendesain sistem software adalah

mengerti problem domain dan application domain. Setelah melewati beberapa analisis,

aktivitas dapat maju ke desain sistem software object-oriented lalu desain aplikasi.

Menurut Mathiassen et al (2000) dan Irwanto (2006), aktivitas OOAD adalah :

28

Gambar 2.5 Aktivitas Utama OOAD

29

Keterangan :

• Problem Domain Analysis adalah aktivitas untuk mengidentifikasi problem

domain. Hasil dari aktivitas ini adalah model yang sesuai dengan problem

domain

• Application Domain Analysis adalah aktivitas untuk menentukan kebutuhan

sistem. Hasil dari aktivitas ini adalah daftar lengkap dari kebutuhan sistem secara

keseluruhan

• Component Design adalah aktivitas untuk mendesain semua komponen yang

dibutuhkan sistem. Hasil dari aktivitas ini adalah spesifikasi dari komponen

• Persistence Design adalah aktivitas mendesain seluruh transient object menjadi

persistence object ketika proses komputasi berlangsung. Hasil dari aktivitas ini

adalah specification of persistence

• Architectural Design adalah aktivitas untuk menggambarkan sistem secara

keseluruhan dan koneksinya diantara komponen utama dari sistem dan

interaksinya. Hasil dari aktivitas ini adalah spesifikasi arsitektur.

2.4.4 Metodologi

Dibawah ini adalah methodology yang dilakukan pada fase analysis dan design pada

object oriented software development.

2.4.4.1 Aktivitas Analisis

Keberhasilan dalam pengembangan sistem tergantung pada pengertian developer

pada aplikasi sistem. Sistem dapat dilihat dari dua sudut pandang yang saling

30

melengkapi: sistem memodelkan sesuatu (problem domain) dan dioperasikan oleh user

(application domain).

Problem domain adalah bagian dari konteks yang diatur, dimonitor atau dikontrol

oleh sistem. Problem domain menggambarkan tujuan sistem, sebagai bagian dari realita

bahwa sistem membantu mengatur, memonitor atau mengontrol.

Application domain adalah kelompok yang mengatur, memonitor atau mengontrol

problem domain. Application domain adalah bagian daru kelompok user. Kesuksesan

(atau kegagalan) sistem tergantung pada seberapa baik koneksi antara application

domain dan problem domain bersama berfungsi secara keseluruhan.

2.4.4.1.1 Problem Domain Analysis

Problem Domain Analysis fokus pada sistem untuk multimedia dokumen.

Mendesain kelas, struktur dan sifat dari multimedia dokumen. Hasil dari tahap ini adalah

model yang sesuai pada dokumen multimedia.

Titik awal untuk analisa problem domain adalah definisi sistem. Elemen “obyek”

dari definisi sistem memberi patokan untuk memilih obyek, kelas dan event.

Class menggambarkan pendekatan pada tugas dari mendefinisikan isi dari sebuah

sistem informasi. Problem domain didefinisikan dan dikarakteristikkan dengan memilih

kelas dan event. Kelas mendefinisikan bagian yang berhubungan dengan problem

domain dan event sebagai elemen dasar dari object behavior karena event berasosiasi

langsung dengan obyek. Hasil dari class activity adalah tabel event yang berisi kelas

yang terpilih dan event yang berhubungan.

Structure mengatur hubungan struktrual diantara kelas dan obyek. Hubungan

dalam problem domain baik itu struktur abstrak statik diantara kelas, atau dinamik,

31

struktur konkrit diantara obyek. Hasil aktivitas struktur dalam class diagram

menunjukkan kelas yang dipilih dan hubungan struktural yang relevan diantara kelas dan

obyek.

Behavior mengatur sifat (behavior) dan interaksi obyek. Aktivitas ini

menggambarkan properti dan atribut yang dinamis untuk setiap kelas yang dipilih.

Deskripsi behavior dan atribut membuat karakteristik lebih tepat untuk setiap obyek

dalam problem domain. Hasil dari aktivitas ini adalah state diagram yang

menggambarkan sifat umum dan atribut dari setiap kelas.

System Definition

Model

Classes

Structure

Behavior

Gambar 2.6 Aktivitas dalam problem-domain model

Tabel 2.1 Aktivitas dalam problem-domain analysis

Activity Content Concepts

Classes Object and events in part of

problem domain

Class, object, and event

32

Structure How classes and objects

conceptually tied

Generalization, aggregation,

association, and cluster

Behavior Dynamic properties in objects Event trace, behavioral pattern,

and attribute

Behavior pattern adalah deskripsi dari event trace yang mungkin untuk semua

objek di dalam class. Event trace adalah urutan event-event dari suatu objek tertentu.

Behavior pattern dapat digambarkan dalam state diagram.

State Diagram menggambarkan behavior umum dari semua objek dari class

tertentu, yang terdiri dari bagian-bagiannya dan transisi di antaranya dan juga dapat

menjelaskan usecase. Statechart diagram menggambarkan transisi dan perubahan

keadaan suatu objek pada sistem sebagai akibat dari stimulasi yang diterima.

Notasi pada behavioral pattern terdiri dari tiga macam yaitu:

1. Sequence merupakan events yang terjadi sekali saja

2. Selection merupakan sesuatu yang keluar dari peristiwa yang terjadi

3. Iteration merupakan events yang terjadi nol atau lebih

2.4.4.1.2 Application Domain Analysis.

Application domain analysis fokus ada bagaimana target sistem digunakan,

mendefinisikan kebutuhan untuk fungsi dan antarmuka sistem. Hasil dari aktivitas ini

adalah daftar lengkap dari kebutuhan sistem secara keseluruhan.

33

Spesifikasi kebutuhan bukan pekerjaan yang muda, user mungkin tidak mengerti

pilihan teknis untuk langsung menulis kebutuhan yang optimal, oleh karena itu,

kerjasama diantara developer dan user dibutuhkan mengenai kebutuhan pengguna,

fungsi dan antarmuka yang harus di evaluasi.

Usage mengatur bagaimana menentukan sistem agar sesuai dengan application

domain. Cara untuk melakukannya adalah dengan menggambarkan aktor dan use case

berdasarkan pengertian dari aktivitas application domain. Use Case menyediakan

gambaran dari kebutuhan sistem yang berasal dari sudut pandang user dan menyediakan

dasar untuk mendefinisikan dan evaluasi kebutuhan fungsi dan antarmuka dasar.

Function fokus pada apa yang dapat sistem lakukan untuk mendukung aktor / user

dan menentukan kapabilitas pemrosesan informasi. Karena usage fokus pada “apa yang

akan dilakukan sistem?” maka function fokus pada “bagaimana sistem akan digunakan”,

itulah sebabnya usage dan function sangat erat terhubung

Interfaces digunakan oleh aktor untuk berinteraksi dengan sistem dan menentukan

antarmuka sistem. Analisis dimulai dari use case, problem model dan kebutuhan

fungsional, hasilnya adalah penentuan pada elemen antarmuka.

34

System Definition

Requirement

Usage

function

Interfaces

Gambar 2.7 Aktivitas dalam application-domain model

Mendefinisikan kebutuhan adalah pekerjaan yang berulang antara usage, function

dan interface. Analisa kebutuhan fokus pada setiap aktivitas secara bergantian seperti

gambar 2.8 tunjukkan diatas. Untuk membuat hasil yang sesuai dan konsisten, tabel 2.2

dibawah memberi gambaran aktivitas analisis application domain.

Tabel 2.2 Aktivitas dalam analisis problem-domain

Activity Content Concepts

Usage Who system interact with

people and systems in the

context

Use case and actor

Function What are the system’s

information processing

capabilities

Function

Interfaces What are the target Interface, user interface,

35

system’s interface

requirements

and system interface

Use case diagram menjelaskan manfaat suatu sistem jika dilihat menurut

pandangan orang yang berada di luar sistem. Diagram ini menunjukkan fungsionalitas

suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar.

Use case diagram digunakan selama proses analisis untuk menangkap requirements

sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap

desain, use case diagram berperan untuk menetapkan perilaku (behavior) sistem saat

diimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa use case

diagram. Kebutuhan atau requirements sistem adalah fungsionalitas apa yang harus

disediakan oleh sistem kemudian didokumentasikan pada model use case yang

menggambarkan fungsi sistem yang diharapkan (use case), dan yang mengelilinginya

(actor), serta hubungan antara actor dengan use case (use case diagram) itu sendiri.

Menurut Armour et al (2001, P104 – 110) Usecase mendeskripsikan sekumpulan

transaksi didalam system, Oleh karena nya setiap interaksi dan behaviour harus

diidentifikasi dan dimodelkan. Berikut dibawah ini adalah model usecase diagram

berserta identifikasi transaction yang dijabarkan kedalam detail usecase specification.

2.4.4.2 Aktivitas Desain

Selama analisis dan desain, sangat penting untuk mengerti sistem secara

keseluruhan. OOAD menekankan pada arsitektur sistem sebagai kunci utama, fokus

pada pengertian, fleksibilitas dan kegunaan sebagai kualitas desain yang penting.

Arsitektur sistem harus mudah dimengerti karena merupakan dasar untuk keputusan dan

36

sebagai komunikasi dan perangkat kerja dalam pekerjaan ke depan. Harus fleksibel

karena pengembangan sistem berada dalam lingkungan yang berubah-ubah.

2.4.4.2.1 Component Design

Component Design fokus pada menentukan implementasi dari kebutuhan di dalam

framework arsitektural. Titik awal Component design adalah spesifikasi aplikasi dan

kebutuhan sistem. Hasil dari aktivitas ini adalah spesifikasi dari komponen yang

tersambung.

Aktivitas connecting component adalah untuk mendesain koneksi antara

komponen-komponen agar mendapatkan desain yang fleksibel dan komprehensif. Hasil

dari aktivitas ini adalah class diagram dari komponen-komponen yang terlibat.

Gambar 2.8 Component Design

37

Dalam object oriented software engineering dinyatakan bahwa suatu software

terdiri atas komponen-komponen yang masing-masing memiliki responsibility dan

saling berinteraksi satu dengan yang lainnya. Menurut Irwanto (2006, P42-45),

sebuah software minimal harus memiliki tiga buah komponen dasar, yaitu:

a. Component Interface.

b. Component Function.

c. Problem Domain Model.

Komponen interface adalah komponen yang memiliki responsibility untuk

menjembatani interaksi antara actor (user) dengan software system. Komponen

function adalah komponen yang merepresentasikan fungsi-fungsi dalam piranti

lunak untuk mengontrol dan mengadministrasi problem domain. Komponen

problem domain adalah komponen yang memodelkan domain masalah didalam

suatu konteks atau bisnis proses.

Oleh karena itu didalam aktivitas desain komponen untuk piranti lunak, aktivitas

utamanya adalah mendesain tiga komponen diatas tadi seperti yang ditunjukkan

pada gambar dibawah ini:

38

Problem DomainModel Component

Design

DokumenPemodelan Domain

Functional SystemComponent Design

Interface ComponentDesign

PDMComponent

FunctionalComponent

InterfaceComponent

&SequenceDiagram

Gambar 2.9 Aktivitas mendesain komponen (Irwanto, 2006)

Untuk pembahasan langkah-langkah masing-masing desain dibahas pada subbab

dibawah ini.

2.4.4.2.1.1 Design Component Problem Domain Model (PDM)

Untuk merancang komponen problem domain model (PDM), kita tidak bisa

membuatnya sembarangan. Oleh karena itu kita harus meng-comply seperangkat

aturan atau kaidah desain. Menurut Irwanto (2006, P46-61) aturan atau kaidah

untuk mendesain komponen PDM terdiri atas delapan langkah yang dilakukan

secara iterative, yaitu:

1. Langkah pertama yang dilakukan ketika merevisi class diagram adalah

memerhatikan design pattern untuk mengoptimalkan solusi desain.

39

Peninjauan design pattern kita lakukan secara iterasi pada setiap langkah

desain dan baru berhenti ketika komponen problem domain model sudah

valid. Implementasi suatu pattern ketika merevisi class diagram

memungkin-kan terjadinya penambahan class dan perubahan struktur pada

class diagram secara fundamental. Penambahan class-class baru di dalam

class diagram dan perubahan struktur yang terjadi di sana memungkinkan

pola behavior objek dari class diagram tersebut otomatis ikut berubah dan

bertambah.

2. Langkah yang kedua adalah memeriksa konsistensi multiple inheritance.

Pada langkah tersebut, kita memeriksa apakah pada class diagram terdapat

multiple inheritance. Jika benar, maka kita harus meninjau dan memastikan

ulang apakah technical platform yang digunakan C++? Jika tidak, maka

multiple inheritance yang terdapat pada class diagram harus direvisi

menjadi single inheritance.

3. Langkah ketiga adalah mempresentasikan private event dan common event

dari class-class yang memiliki hubungan struktur asosiasi dan agregasi.

Representasi event dapat dibuat ke dalam sebuah tabel sehingga dapat

menyederhanakan pola behavior objek yang kompleks tanpa kehilangan

gambaran perspektifnya. Untuk concrete class yang memiliki hubungan

structural dengan abstract class, pola behavior abstract class tersebut akan

didelegasikan oleh subclass-nya.

40

4. Langkah keempat, setelah dibuat tabel representasi event untuk class-class

yang memiliki hubungan struktural agregasi dan asosiasi, periksalah satu

per satu apakah pada tabel-tabel tersebut sekurang-kurangnya terdapat satu

buah common event? Jika ada yang tidak, maka mungkin pada class

diagram kita terdapat hubungan struktural yang keliru atau ada kekurangan

pada pola behavior objek kita. Karena pada prinsipnya jika dua buah class

memiliki hubungan struktur asosiasi atau agregasi, maka dipertimbangkan

sekurang-kurangnya terdapat satu buah common event yang memengaruhi

objek-objek dari dua class tersebut, dan sebaliknya jika pada pola behavior

terdapat dua atau lebih objek yang memiliki common event, maka

dipertimbangkan bahwa classifier objek-objek tersebut memiliki hubungan

structural agregasi atau asosiasi. Jika pada pola behavior atau class diagram

kita terdapat kekurangan, maka perbaiki dahulu keduanya sebelum

melangkah ke tahap selanjutnya.

5. Langkah kelima, presentasikan event yang terdapat pada pola behavior

objek ke dalam komponen problem domain model. Pada saat kita

mendesain sebuah sistem, mungkin saja kita mendesain sebuah sistem yang

kompleks. Dalam situasi itu, bisa saja kita memiliki pola behavior yang

kompleks dan banyak. Agar tidak mudah kehilangan gambaran perspektif,

disarankan agar tabel representasi event tabel di update berdasarkan

keperluan desain ketika kita merepresentasikan event ke dalam komponen

problem domain model. Berikut ini adalah cara dan aturan yang digunakan

41

untuk mempresentasikan event ke dalam komponen problem domain

model dan meng-update tabel representasi event:

a. Pertama, seperti yang telah disinggung di atas bahwa atribut

merupakan descriptive property dari event. Oleh karena itu

asosiasikanlah semua atribut yang berhubungan dengan event pada

pola behavior objek.

b. Kedua, representasikanlah event-event yang terdapat pada pola

behavior ke dalam komponen problem domain model dengan aturan

sebagai berikut:

Tabel 2.3 Tabel Aturan Merepresentasikan Event (Irwanto, 2006)

Untuk event yang berjenis

sequence dan selection

Representasikanlah event yang

bertipe sequence dan selection

sebagai state attribute dari class yang

bersangkutan. Setiap kali event

tersebut terjadi, sistem akan

menetepakan nilai yang baru kepada

state attribute tersebut.

Untuk event yang berjenis

inserting iteration

Representasikan event yang bertipe

iterasi sebagai class baru.

Selanjutnya, lekatkan class baru

tersebut kepada class yang memiliki

iteration event menggunakan struktur

agregasi. Setiap kali iteration event

terjadi, sistem akan menghasilkan

objek baru pada class tersebut.

Untuk event yang berjenis Representasikanlah atribut yang

42

updating & Retrieving

iteration

berkolerasi dengan class yang

bersangkutan. Setiap kali event

tersebut terjadi, sistem akan

mengubah dan menetapkan nilai

yang baru kepada atribut-atribut

tersebut atau meretrieve objek-objek

tertentu sesuai dengan kriteria yang

diinginkan.

c. Ketiga, tentukanlah jenis iteration event, di mana didapat pola

behavior objek, ke dalam tabel representasi event sesuai dengan

proses bisnis dan definisi sistem yang berlaku.

6. Langkah keenam, setelah selesai merepresentasikan semua event yang

terdapat pada pola behavior, langkah selanjutnya adalah mendesain

association class. Jika pada class diagram kita terdapat association class,

maka lekatkanlah association class tersebut dengan pasangan class yang

menimbulkannya dengan menggunakan hubungan struktur agregasi.

Ketika kita mendesain association class, ada dua hal yang harus kita

perhatikan yaitu:

a. Pertama, jika pada class diagram terdapat association class yang

ditimbulkan akibat multiplicity many to many pada hubungan struktur

binary association, maka semua sesuai dengan aturan desain, lekatkan

association class dengan dua class menggunakan hubungan struktur

agregasi.

43

b. Kedua, association class tidak selalu muncul pada binary association,

tetapi juga bisa muncul pada ternary association atau bahkan pada

level yang lebih tinggi lagi N-ary association.

Walaupun penentuan multiplitcity sepertinya merupakan hal yang sepele,

akan tetapi apabila kita berhadapan dengan ternary dan N-ary association,

maka penentuan multiplicity bukanlah hal yang remeh. Salah menentukan

multiplicity dapat memberikan dampak yang kurang baik pada skala yang

panjang di kemudian hari.

7. Langkah ketujuh, revisi class diagram yang akan dilakukan pada proses

desain komponen problem domain model memberikan dampak perubahan

class dan struktur pada class diagram. Pada langkah ketujuh ini kita akan

memeriksa apakah di dalam komponen problem domain model kita

terdapat hubungan struktur antar-class yang sudah tidak lagi berguna? Jika

ada, maka struktur relationship itu harus dibuang.

Langkah kedelapan, periksalah atribut-atribut yang memiliki hubungan struktur, apakah

sudah lengkap? Jika sudah, periksalah kembali apakah hubungan struktur yang

digunakan sudah tepat. Navigation association adalah assosiasi satu arah, atau istilah

lainnya unidirectional association. Penggunaan association structure yang tepat di dalam

desain efektif menjaga agar coupling antarobjek tetap rendah. Sebaliknya, penggunaan

association structure yang tidak tepat secara efektif meninggikan coupling antarobjek

dalam desain kita.

44

2.4.4.2.1.2 Design Component Function

Merancang komponen sistem fungsional software adalah suatu kegiatan

yang amat penting untuk dilakukan mengingat tidak ada software yang tidak

memiliki functional system. Apabila sebuah software tidak memiliki functional

system, praktis software menjadi tidak berguna dan problem domain model yang

telah kita buat menjadi sia-sia (Irwanto, 2006). Apabila kia bicara mengenai

functional system, makan pada prinsipnya kita tengah membicarakan apa yang

dapat dilakukan oleh sistem. Oleh karena itu, hal tersebut tentunya sangat terkait

erat dengan responsibility sistem. Didalam studi literature yang dilakukan oleh

Irwanto (2006, P63-64) menyatakan pendapat Larman (1998, P170-187) bahwa

Inti dari aktivitas desain pada fase ini pada prinsipnya adalah menetapkan

responsibility sistem pada software kita dengan memerhatikan objek-objek yang

berkolaborasi di dalam software sistem tersebut. Oleh karena itu, pada fase ini

keahlian menetapkan system responsibility melalui interaction diagram menjadi

pokok masalah yang penting.

Menurut Mathiassen et al (2000: 260), ada tiga buah pola yang harus kita

perhatikan pada saat menetapkan responsibility, yaitu:

a. Model class placement

Pola ini menetapkan method di dalam komponen problem domain model.

Method yang ditetapkan dengan menggunakan pola ini biasanya

mengakses hanya single objek atau objek yang memiliki struktur agregasi

yang sederhana.

45

b. Function class placement

Pola ini menetapkan method di dalam komponen sistem fungsional.

Method yang ditetapkan dengan menggunakan pola ini biasanya

mengakses banyak objek yang berbeda yang terdapat di dalam komponen

problem domain model.

c. Active function

Pola active function biasanya digunakan apabila di dalam sistem kia

terdapat signaling functionality. Biasanya active function ada di dalam

sistem realtime.

Menurut Irwanto (2006, P66-72) ada tiga langkah-langkah desain yang harus

dilakukan untuk membuat function komponen adalah sebagai berikut:

a. Langkah pertama membuat atau merevisi CRC card

b. Langkah kedua menetapkan responsibility software system dengan

menggunakan model class placement terlebih dahulu yang di deskripsikan

dengan menggunakan interaction digram UML.

Langkah ketiga, setelah penetapan system responsibility dengan pola model class

placement dilakukan melalui collaboration diagram, selanjutnya kita memeriksa apakah

ada system responsibility yang tidak bisa ditetapkan dengan menggunakan model class

placement? Jika ada, maka tetapkanlah responsibility software sistem tersebut dengan

menggunakan pola function class placement.

46

2.4.4.2.2 Persistent Design

Persistent design adalah perancangan struktur data yang ada pada applikasi

software kedalam database. Hal ini sangatlah penting untuk dilakukan mengingat tanpa

adanya database didalam storage, semua data yang terdapat pada application workspace

akan hilang ketika listrik padam. Salah satu aspek penting lainnya adalah untuk

menjawab kebutuhan akan pemuatan kembali data dari database ke memory application

workspace ketika sewaktu-waktu dibutuhkan kembali.

Secara garis besar langkah-langkah persistent design dalam perancangan software

adalah sebagai berikut dibawah ini:

1. Langkah pertama adalah membuat logical database design dengan input

spesifikasi komponen problem domain model. Output dari aktivitas tersebut

adalah membuat diagram ER.

2. Langkah kedua adalah membuat physical database design dengan input

diagram ER. Berdasarkan diagram ER tersebut, kita kemudian membuat script

DDL. Setelah script DDL selesai, kita akan membuat database yang baru dan

memasukkan instruksi DLL tersebut ke dalam database menjadi metadata

dalam database schema.

Dalam membuat logical database design dengan input spesifikasi komponen

problem domain model terdapat beberapa tata-cara yang harus di-comply. Untuk

membuat instance komponen PDM dapat persistent ke dalam relational database maka

di dalam persistent desain terdapat beberapa metode untuk melakukan hal tersebut.

Menurut Bennett et al (2002: P455), pemecahan struktur data suatu class

menjadi tabel dapat dilakukan melalui dua buah cara, pertama dilakukan dengan cara

47

normalisasi, dan yang kedua dengan cara memetakan class ke tabel dengan serangkaian

aturan. Untuk memetakan struktur data ke dalam tabel, kita dapat memilih salah satu

cara yang telah disebutkan.

Dalam studi literaturnya, Bennett et al (2002, P460) mencatat bahwa menurut

Rumbaugh (1991) dan Brown dan Whitenack (1996), tata cara dan aturan memetakan

class ke tabel adalah sebagai berikut:

a. Class dengan struktur data simple langsung menjadi tabel.

b. Object identifier menjadi primary key.

c. Class yang berisi instance dari class lain (embedded class) sebagai atribut

harus dipisah ke tabel lain. Objek dari embedded class harus dialokasikan

pada object identifier yang unik.

Untuk class yang berisi collection, alokasikan object identifier ke dalam class yang

meng-handle collection tersebut. Class tersebut akan direpresentasikan ke dalam tabel.

Selanjutnya, buatlah tabel secara terpisah yang berisi dua kolom. Kolom yang pertama

digunakan untuk menangani object identifier dari objek yang berisi collection. Kolom

yang kedua digunakan untuk menangani object identifier dari objek yang berada di

dalam collection.

2.4.4.2.3 Architectural Design

Inti dari aktivitas design adalah mendesign arsitektur software. Mengapa arsitektur

software itu merupakan artifak yang sangat penting? Karena software architecture

bukan hanya menentukan apa yang dapat dilakukan dan yang tidak dapat dilakukan

48

software tersebut, lebih dari itu software architecture mendeskripsikan logical solution

secara menyeluruh dari software yang hendak dibangun tanpa harus benar-benar

membangunnya. Dengan adanya arsitektur software, para stakeholder dapat memahami

dan mengerti bagaimana secara logical software tersebut akan berjalan sebelum

membangunnya. Keberhasilan dan keampuhan sebuah software sebetulnya banyak

ditentukan oleh keampuhan arsitekturnya (Irwanto, 2006).

Arsitektur sebuah system terdiri atas dua buah bagian yaitu arsitektur komponen dan

arsitektur proses. Saat mendesign arsitektur software, arsitektur komponen dan proses

inilah yang yang harus dibuat..

Mendesign ComponentArchitecture

Mendesign ProcessArchitecture

ComponentSpesification

Architecture ComponentSpecification

DeploymentDiagram

Gambar 2.10 Aktivitas Pada Mendesign Architecture Software (Irwanto, 2006)

2.4.4.2.3.1 Mendesign Architecture Component

Pada architecture component, kita akan mendesign struktur software system yang terdiri

dari component-component yang saling berhubungan. Arsitektur sebuah software system

49

defaultnya dibuat dengan menggunakan logical component. Sehingga rancangan konsep

setiap elemen yang membentuk software system tersebut dapat terlihat dengan jelas dan

mudah dipahami. Apa sebetulnya yang dilakukan ketika berada dalam fase design ini?

sebenarnya yang dilakukan sederhana, yakni: menggambarkan rancangan konsep setiap

element yang membentuk software system kita dalam sebuah diagram dan

menghubungkan elemen-elemen (component) tersebut (irwanto, 2006).

Gambar 2.11 Logical Component Architecture

Menurut Irwanto (2006, P139), ketika membuat arsitektur komponen kita perlu

membuat atau menetapkan Client/Server Architecture Pattern.

Interface

Domain Model

DataBase Access

Functional Problem Domain Model

User Interface System Interace

50

Gambar 2.12 Client/Server Architecture Pattern

Client/server architecture pattern dibuat untuk menggambarkan distribusi logical

component software system ke processor yang tersebar oleh karena faktor geografis.

bentuk distribusi logical component nya diurai pada tabel berikut ini

Tabel 2.4 Distribusi Komponen Logis pada Client/Server Architecture

Client Server Architecture

I I+F+M Distributed Presentation

I F+M Local Presentation

I+F F+M Distributed Functionality

I+F M Centralize Model

I+F+M M Distributed Model

2.4.4.2.3.2 Mendesign Architecture Process

Architecture process adalah sebuah artifak penting lainnya yang harus kita buat

setelah membuat architecture component. Oleh karena pada fase ini kita

mendeskripsikan struktur ekseskusi dari suatu system, maka pada fase ini kita

<<Client>> <<Client>> <<Client>>

<<Sever>>

51

berhubungan dengan aspek dinamis dari software system dan physical device yang

mengeksekusi software system tersebut.

Menurut Irwanto (2006, P146) prinsip membuat arsitektur proses adalah

Distribusikanlah component instant ke processor yang telah tersedia, yang kemudian

digambarkan dengan menggunakan deployment diagram dan buatlah arsitektur proses

software system kita tanpa adanya bottleneck.

Didalam UML Arsitektur proses digambarkan dengan menggunakan deployment

diagram. secara semantic deployment diagram diagram pada umumnya berisi:

• Node

Node adalah physical element yang ada pada saat run time dan

merepresentasikan computational resource yang pada umumnya mempunyai

memory dan kemampuan prosesing. Node biasanya digunakan untuk

mengambarkan topology harware dimana software system kita dieksekusi.

Secara semantic dalam UML, node dilambangkan dengan symbol

Gambar 2.13 Node Symbol

Untuk membedakan node yang satu dengan node yang lain, maka setiap node

harus diberi nama yang unik secara textual.

• Dependency dan connection link

Node_Name

52

Setiap node didalam deployment diagram mempunyai hubungan dengan

node yang lain. Dalam konteks ini secara semantic hubungan digambarkan

dengan notasi association. Notasi association ini dibuat untuk melambangkan

physical connection antara node.

Gambar 2.14 Gambar Deployment Diagram

2.4.5 Coding and Testing

Testing adalah proses pengujian sebuah program dengan maksud tertentu

menemukan kesalahan sebelum di-deploy kepada pengguna akhir. Pengujian

perangkat lunak terdiri atas proses verifikasi dan validasi. Verifikasi mengacu

pada seperangkat dari kegiatan yang memastikan perangkat lunak yang benar

mengimplementasikan fungsi yang spesifik. Validasi mengacu pada pada

kegiatan yang berbeda yang memastikan bahwa perangkat lunak yang telah

dibangun dapat dilacak dengan requirement pelanggan.

Client1

Server

-End1

*

-End2

1

Client2 -End3

*

-End4

1

<<10 T Ethernet>>

<<10 T Ethernet>>

53

Gambar 2.15 Testing Strategy

Testing Strategy:

• Kita mulai dengan ‘pengujian kecil’ dan bergerak ke arah ‘pengujian besar’

• Untuk software conventional

- Model (komponen) adalah fokus awal kita

- Integrasi modul berikut.

• Untuk software berbasis OO

- Berfokus pada saat ‘pengujian dalam skala kecil’ perubahan dari modul

individu (pandangan konvensional) untuk kelas OO yang meliputi atribut

dan operasi dan mengimplikasikan komunikasi dan kolaborasi.

Verifikasi dan validasi mencakup beragam kegiatan SQA yang meliputi review

teknis formal, kualitas dan audit konfigurasi, pemantauan kinerja, simulasi, studi

kelayakan, kajian dokumentasi, review database, analisa algoritma, pengujian

pengembangan, pengujian kegunaan, pengujian kualifikasi, dan pengujian instalasi.

54

Setelah mengembangkan desain, penulisan program yang sebenarnya pun dimulai.

Penulisan program tersebut disebut coding. Coding adalah menerjemahkan persyaratan

logika dari pseudocode atau diagram alur ke dalam suatu bahasa pemograman baik

huruf, angka, dan symbol yang membentuk program.

2.4.6 Maintenance

Perangkat lunak akan mengalami perubahan stelah disampaikan kepada

pelanggan. Perubahan akan terjadi karena kesalahan-kesalahan ditentukan, karena

perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-perubahan di

dalam lingkungan eksternalnya, atau pelanggan membutuhkan perkembangan fungsional

atau unjuk kerja. Pemeliharaan perangkat lunak mengaplikasi lagi setiap fase

sebelumnya, lalu memperbaiki program sebelumnya dan tidak membuat yang baru lagi.

Tahap-tahap maintenance melibatkan kegiatan-kegiatan berikut:

Memantau sistem kerja. Jika kinerja turun dibawah tingkatan yang dapat diterima,

tuning atau reorganisasi database mungkin diperlukan.

Mempertahankan dan meningkatkan aplikasi database (ketika dibutuhkan).

Requirement-requirement baru dimasukkan ke dalam aplikas database melalui

tahap-tahap sebelumnya dalam siklus hidup.

Proses pemantauan berlanjut selama kehidupan aplikasi database dan pada

waktunya dapat mengakibatkan pengorganisasian ulang database untuk memenuhi

persyaratan yang berubah. Perubahan ini pada gilirannya memberikan informasi tentang

kemungkinan evolusi sistem dan sumber daya masa depan yang mungkin diperlukan.

55

2.5 Notasi UML

Pada tahun 1994, Grady Booch dan James Rambaugh sepakat bergabung untuk

menggunakan metode pengembangan berorientasi objek dengan tujuan membuat proses

standart tunggal untuk pengembangan sistem berorientasi objek. Ivar Jacobson

bergabung pada tahun 1995, dan mereka bertiga fokus membuat sebuah bahasa

pemodelan objek standart sebagai ganti dari pendekatan atau metode berorientasi onjek

standart (pada saat menuliskan, mereka bertiga memasarkan metodologi pemodelan

objek yang disebut Unfield Process). Berdasarkan kerja mereka dan hasil kerja lainnya

pada industry, Unfield Modeling Language (UML) versi 1.0 dirilis pada tahun 1997.

UML tidak menentukan metode untuk sistem – sistem pengembangan, hanya

notasi yang saat ini telah diterima luas sebagai standart untuk pemodelan objek. Object

Management Group (OMG), badan standart industry, mengadopsi UML pada bulan

November 1997 dan terus bekerja untuk meningkatkannya berdasarkan kebutuhan

industri.

2.5.1 Class Diagram

Class diagram merupakan sebuah kelas yang menggambarkan kumpulan kelas-

kelas dan hubungan strukturnya. UML memiliki class diagram; mereka adalah deskripsi

utama dalam object-oriented analysis dan design Diagram ini menunjukan kelas objek

yang menyusun sistem dan juga hubungan antara kelas objek tersebut. Di dalam

diagram kelas terdapat class, attribute dan behavior. Gambar 2.14 merupakan contoh

dari class diagram. Symbol panah menunjukan asosiasi.

56

-CustID : String-Nama : String-Alamat : String-Telp : String-Username : String

Customers

-SOID : String-Tgl : Date-CustID : String-NoValidation : String

SalesOrder-End11

1

-End12

1..*

Gambar 2.16 Contoh dari class diagram

Pada contoh diatas, satu customers bisa memiliki banyak sales order.

a. Object

Object adalah sesuatu yang nyata atau dapat dilihat, disentuh, atau dirasakan. User

menyimpan data serta mencatat perilaku mengenai sesuatu itu.

b. Class / kelas

Class merupakan satu set object yang memiliki attribute dan behavior yang sama,

yang biasa disebut dengan object class. Di bawah ini merupakan contoh dari

sebuah class / kelas.

-SOID : String-Tgl : Date-CustID : String-NoValidation : String

SalesOrder

Gambar 2.17 Class dalam UML

c. Attribute

Data yang mewakili karakteristik tentang suatu objek. Perhatikan contoh dari

attribute yang ada pada kelas orang.

57

-CustID : String-Nama : String-Alamat : String-Telp : String-Username : String

Customers

Gambar 2.18 Attribute dari Customers

d. Behavior

Behavior merupakan kumpilan dari sesuatu yang dapat dilakukan oleh obyek dan

terkait dengan fungsi-fungsi yang bertindak pada data objek. Pada siklus

berorientasi objek, perilaku objek merujuk kepada metode, operasi, atau fungsi.

+Deposit()+GetTransactions()+MenghitungBalance() : float+Withdraw ()

-NoAc : String-CustId : String-TglOpenAcc : Date-Mutasi-Balance : float-AccountState : Integer-TglDibekukan : Date

Account

Gambar 2.19 Behaviour dari kelas Account

Beberapa symbol lain yang ada pada class diagram adalah:

a. Associations

Menunjukan hubungan antara kelas yang satu dengan kelas yang lain.

58

-CustID : String-Nama : String-Alamat : String-Telp : String-Username : String

Customers

-SOID : String-Tgl : Date-CustID : String-NoValidation : String

SalesOrder-End11

1

-End12

1..*

Garis mengindikasikan hubungan / Associations

Gambar 2.20 Hubungan antara class Customers dan SalesOrder

b. Generalization

Generalization merupakan sebuah teknik antara attribute dan behavior

yang umum pada beberapa tipe kelas objek, dikelompokan ke dalam

kelasnya sendiri.

+Orang()+Jalan()+Lari()

-ID : String-Nama : String

Orang

+Polisi()+Menembak()

-PoliceID : String-Kesatuan : String

Polisi

+Teroris()+Menembak()

-TerorisID : String-Spesialisasi : String

Teroris

Gambar 2.21 Hubungan generalisasi

c. Aggregation

Terkadang sebuah kelas dapat mempunyai beberapa kelas komponen.

Dan hubungan antara kelas dengan kelas komponennya itu bernama

Aggregation.

59

+ChangeCustomerAddress()+Deposit()+Withdraw()

-CustID : String-Nama : String-CustomerState : Integer-Acc : Account-Address : Customer Address

Customer

+Deposit()+GetTransactions()+MenghitungBalance() : float+Withdraw ()

-NoAc : String-CustId : String-TglOpenAcc : Date-Mutasi : Transactions-Balance : float-AccountState : Integer-TglDibekukan : Date

Account

-End1

1

-End2

1..*

Gambar 2.22 Hubungan Aggregation

d. Composition

Composition adalah sebuah tipe aggregation yang kuat. Artinya setiap

kelas komponen hanya dimiliki oleh satu kelas saja.

-CustID : String-Nama : String-CustomerState : Integer-Acc : Account-Address : Customer Address

Customer

-CustID : String-Alamat : String-Telepon : String-TglBerlaku : String

Customer Address-NoAc : String-CustID : String-TglOpenAcc : Date-Balance : float-AccountState : Integer-Mutasi : Transaction-TglDibekukan : Date

Account

-End31

-End41..*

-End11

-End21..*

Gambar 2.23 Composition Relationship dalam UML

2.5.2 Usecase Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah

sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”.

60

Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use

case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create

sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas

manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-

pekerjaan tertentu.

Gambar 2.24 Contoh Diagram Model Use-case

Sumber : http://ilmukomputer.org/2006/08/25/pengantar-uml/

61

Pemodelan Use-case mengindetifikasi dan menggambarkan fungsi – fungsi sistem

dengan menggunakan alat yang disebut Use-case.

Gambar 2.25 Simbol Use-case

Use-case merupakan urutan langkah yang secara tindakan saling terkait (skenario),

baik termotifasi maupun secara manual, untuk melengkapi satu tugas bisnis tunggal.

Memodelkan behaviour yang dinamis untuk semua objek di dalam class,

menggambarkan daur hidup objek dan macam-macam state dari objek dan kejadian dari

objek tersebut.

2.5.3 Statechart Diagram

Sebuah statechart diagram (Mathiassen et al, 2000, p341), menggambarkan dan

memodelkan behavior yang dinamis untuk semua objek dan kejadian dari objek

tersebut.

Use Case 1

62

Gambar 2.26 State diagram

2.5.4 Sequence Diagram

Diagram rangkaian menggambarkan bagaimana objek berinteraksi dengan satu

sama lain melalui pesan pada eksekusi sebuah use-case atau operasi, diagram ini

mengilustrasikan bagaimana pesan terkirim dan diterima di antara objek dan dalam

sekuensi apa.

63

Gambar 2.27 Sequence Diagram

Di bawah ini merupakan symbol-simbol yang ada pada sequence diagram:

a. Object lifeline

Menggambarkan panjang kehidupan suatu objek selama scenario sedang

dibuat.

Gambar 2.28 Object lifeline

b. Activation

Dimana proses sedang di lakukan oleh object / class untuk memnuhi pesan/

perintah

64

Gambar 2.29 Activation symbol

c. Message

Sebuah anak panah yang mengidentifikasi pesan di antara objek. Dan objek

dapat mengirimkan pesan ke dirinya sendiri.

Gambar 2.30 Message symbol