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 eapplication 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 7
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 twotier 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
Data
Server Printer
Application Server
Thin Client
Thin Client
Thin Client
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 EntityRelationship (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 sintakssintaks 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 modelmodel 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
Behavior
Classes
Structure
Model
Gambar 2.6 Aktivitas dalam problem-domain model
Tabel 2.1 Aktivitas dalam problem-domain analysis Activity
Content
Classes
Object and events in part of Class, object, and event problem domain
Concepts
32 Structure
How
classes
and
conceptually tied Behavior
objects Generalization,
aggregation,
association, and cluster
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
Interfaces
Usage
function
Requirement
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 Use case and actor people and systems in the context
Function
What are the system’s Function information
processing
capabilities Interfaces
What
are
the
target Interface, user interface,
35 system’s
interface and system interface
requirements
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
Dokumen Pemodelan Domain
Problem Domain Model Component Design
Functional System Component Design
PDM Component
Functional Component
Interface Component Design
Interface Component & Sequence Diagram
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 Representasikanlah sequence dan selection
bertipe
sequence
event dan
yang selection
sebagai state attribute dari class yang bersangkutan. tersebut
Setiap
terjadi,
kali
event
sistem
akan
menetepakan nilai yang baru kepada state attribute tersebut. Untuk event yang berjenis Representasikan event yang bertipe inserting iteration
iterasi
sebagai
Selanjutnya,
class
lekatkan
class
baru. 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 iteration
&
Retrieving berkolerasi
dengan
bersangkutan. tersebut
class
yang
kali
event
sistem
akan
Setiap
terjadi,
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.. Component Spesification Deployment Diagram
Mendesign Component Architecture
Mendesign Process Architecture
Architecture Component Specification
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). Interface
User Interface
System Interace
Domain Model
Functional
Problem Domain Model
DataBase Access
Gambar 2.11 Logical Component Architecture Menurut Irwanto (2006, P139), ketika membuat arsitektur komponen kita perlu membuat atau menetapkan Client/Server Architecture Pattern.
50
<>
<>
<>
<<Sever>>
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
I
F+M
Local Presentation
I+F
F+M
Distributed Functionality
I+F
M
Centralize Model
I+F+M
M
Distributed Model
Distributed Presentation
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
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
Node_Name
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
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.
Client1
-End1<<10 T Ethernet>>
* -End2 -End4
Server
1 Client2
-End3
*
<<10 T Ethernet>>
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.
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 kelaskelas 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
Customers
SalesOrder
-CustID : String -Nama : String -Alamat : String -Telp : String -Username : String
-End12 -End11
1
1..*
-SOID : String -Tgl : Date -CustID : String -NoValidation : String
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.
SalesOrder -SOID : String -Tgl : Date -CustID : String -NoValidation : String
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
Customers -CustID : String -Nama : String -Alamat : String -Telp : String -Username : String
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.
Account -NoAc : String -CustId : String -TglOpenAcc : Date -Mutasi -Balance : float -AccountState : Integer -TglDibekukan : Date +Deposit() +GetTransactions() +MenghitungBalance() : float +Withdraw ()
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
Customers -CustID : String -Nama : String -Alamat : String -Telp : String -Username : String
SalesOrder -End11
1
-End12
1..*
-SOID : String -Tgl : Date -CustID : String -NoValidation : String
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 -ID : String -Nama : String +Orang() +Jalan() +Lari()
Polisi
Teroris
-PoliceID : String -Kesatuan : String +Polisi() +Menembak()
-TerorisID : String -Spesialisasi : String +Teroris() +Menembak()
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
Account Customer -CustID : String -Nama : String -CustomerState : Integer -Acc : Account -Address : Customer Address +ChangeCustomerAddress() +Deposit() +Withdraw()
-End1
-End2
1
1..*
-NoAc : String -CustId : String -TglOpenAcc : Date -Mutasi : Transactions -Balance : float -AccountState : Integer -TglDibekukan : Date +Deposit() +GetTransactions() +MenghitungBalance() : float +Withdraw ()
Gambar 2.22 Hubungan Aggregation d.
Composition Composition adalah sebuah tipe aggregation yang kuat. Artinya setiap kelas komponen hanya dimiliki oleh satu kelas saja. Customer -CustID : String -Nama : String -CustomerState : Integer -Acc : Account -Address : Customer Address
1 1..*
-End4
Customer Address -CustID : String -Alamat : String -Telepon : String -TglBerlaku : String
-End1 -End3 1..*
-End2
Account -NoAc : String -CustID : String -TglOpenAcc : Date -Balance : float -AccountState : Integer -Mutasi : Transaction -TglDibekukan : Date
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 pekerjaanpekerjaan 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.
Use Case 1
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.
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
