Upload
tranthien
View
229
Download
5
Embed Size (px)
Citation preview
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