29
e. Penekanan pada kecepatan dapat berimpak terhadap kualitas yang disebabkan jalan-jalan pintas yang disarankan dengan buruk melalui
metodologi tersebut.
2.6 Object Oriented Analysis OOA
OOA adalah pendekatan yang digunakan untuk mempelajari objek yang sudah ada untuk mengetahui apakah mereka dapat digunakan kembali atau
diadopsi untuk pemakaian baru. Atau menentukan satu objek baru atau yang dimodifikasi yang akan digabung dengan objek yang sudah ada ke dalam suatu
aplikasi komputasi bisnis yang sangat berharga Whitten, 2004. OOA adalah suatu pendekatan yang digunakan untuk mempelajari objek-
objek yang sudah ada untuk digunakan kembali dan disesuaikan untuk penggunaannya yang baru. Selain itu, OOA juga dapat digunakan untuk membuat
objek baru atau bisa juga untuk merubah objek yang sudah ada untuk dipadukan dengan objek-objek lainnya sehingga membentuk suatu aplikasi bisnis yang
berdaya guna tinggi Whitten, 2001.
2.7 Object Oriented Design OOD
Object Oriented Design OOD adalah suatu pendekatan yang digunakan untuk menentukan solusi terbaik bagi piranti lunak dalam hal perpaduan objek
objects, atribut attributes dan method methods. Perancangan suatu piranti lunak berorientasi objek membutuhkan penggunaan arsitektur piranti lunak
berlapis multilayered software architecture, juga membutuhkan spesifikasi dari subsistem yang menyediakan fungsi- fungsi functions yang dibutuhkan. Selain
30
itu, gambaran tentang penggunaan objek yang membentuk sistem dan gambaran mekanisme komunikasi yang memungkinkan aliran data mengalir melalui lapisan
layers, subsistem dan objek juga dibutuhkan. Semua itu dilakukan dan diselesaikan dengan menggunakan pendekatan OOD Whitten, 2001.
OOAD merupakan sekumpulan petunjuk umum yang mengarahkan kepada aktivitas analisis dan perancangan. Untuk membuat metode kita menjadi
lebih berguna, kita merancangnya hingga terdapat penyesuaian, perkembangan, dan substitusi bagian dapat dengan mudah diimplementasikan Mathiassen, 2000.
Terdapat 4 aktivitas utama yang digunakan dalam menggunakan metode Unified Software Deployment untuk OOAD Object Oriented Analysis and
Design Mathiassen, 2000. Yaitu :
1. Problem Domain Analysis
Dalam tahapan ini sistem dirancang sesuai dengan kebutuhan informasi dari pengguna, tahapan ini menentukan hasil dari keseluruhan aktivitas analisis
dan perancangan. Tahapan dari Problem Domain Analysis ini adalah : a Menentukan Class yang ada dalam sistem dengan melakukan proses
identifikasi dari definisi sistem yang telah dikembangkan. b Menganalisa dan mengembangkan struktur hubungan dari class
– class yang ada.
c Menganalisa Behavior dari class – class tersebut.untuk menentukan state
dari setiap class yang termasuk dalam sistem ini. Hasil laporan perancangan yang dihasilkan dari tahapan ini adalah :
31
a System Definition : mendefinisikan seluruh sistem sebagai sebuah model yang akan dilihat user saat sistem jadi.
b Class Diagram : untuk menggambarkan hubungan antara class-class dalam sebuah sistem.
c State Diagram : untuk menggambarkan bagaimana state dari daur hidup kelas yang ada di dalam sistem ini.
Dapat dilihat dari tahap ini telah dapat dilihat model aplikasi secara keseluruhan bagaimana aplikasi tersebut akan terbentuk.
2. Application Domain Analysis
Tahapan ini berfokus pada bagaimana sistem akan digunakan oleh pengguna. Tahap ini dan tahap sebelumnya dapat dimulai secara bergantian,
tergantung pada kondisi pengguna. Terdapat 3 tahapan yang akan dilakukan dalam Application Domain Analysis Mathiassen, 2000, yaitu:
a Menentukan usage, yaitu menentukan Aktor dan use case yang terlibat dan interaksinya.
b Menentukan fungsi sistem untuk memproses informasi dan membuat daftar fungsi.
c Menentukan interface pengguna dan sistem, untuk interaksi sesungguhnya dari pengguna dan sistem informasi yang dirancang.
Laporan yang akan dihasilkan dari tahapan ini adalah :
32
a Use Case Diagram, yang menggambarkan interaksi pengguna sebagai aktor dengan sistem informasi.
b Function List, yaitu kemampuan yang harus dimiliki sistem sebagai kebutuhan dasar dari user.
c User Interface Navigation Diagram, yaitu diagram untuk menggambarkan tampilan layar yang akan dirancang untuk memenuhi kebutuhan user.
3. Architectural Design
Dalam tahap ini dirancang arsitektur hubungan antara client dan server yang memadai untuk sistem agar dapat berjalan baik. Perancangan tahap ini
menentukan bagaimana struktur sistem fisik akan dibuat dan bagaimana distribusi sistem informasi pada rancangan fisik tersebut. Laporan yang dihasilkan adalah
Deployment Diagram.
4. Component Design
Tahap terakhir dalam Unified Software Deployment sebelum melakukan programming. Sistem akan dimodelkan secara lengkap dalam diagram yang
disebut programming. Sistem akan dimodelkan secara lengkap dalam diagram yang disebut sebagai Component Diagram. Di tahap ini terlihat bagaimana sistem
bekerja dan interaksi yang terjadi antara sistem dan pengguna.
33
2.7.1 Unified Modeling Language UML
UML merupakan kesatuan dari bahasa pemodelan yang dikembangkan oleh Booch, Object Modeling Technique OMT dan Object Oriented Software
Engineering OOSE. Metode Booch dari Grady Booch sangat terkenal dengan nama metode Design Object Oriented. Metode ini menjadikan proses analisis dan
design ke dalam empat tahapan iterative, yaitu: identifikasi kelas-kelas dan objek- objek, identifikasi semantic dari hubungan obyek dan kelas tersebut, perincian
interface dan implementasi Munawar, 2005. UML adalah bahasa grafis untuk mendokumentasi, menspesifikasikan, dan
membangun sistem perangkat lunak Hariyanto, 2004. UML adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang membantu
mendeskripsikan dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemograman berorientasi objek OO Whitten, 2004.
Tabel 2.1 Unsur-unsur pembentuk UML Munawar, 2005
Diagram Tujuan
keterangan Activity
Perilaku prosedural paralel Sudah ada di
UML 1 Class
Class, fitur dan relasinya Sudah ada di
UML 1
Communication Interaksi diantara obyek. Lebih
menekankan ke link Di UML 1
disebut Collaboration
Component Struktur dan koneksi dari komponen
Sudah ada di UML 1
Composite Structure
Dekomposisi sebuah class saat runtime Baru untuk
UML 2 Deployment
Penyebaraninstalasi ke klien Sudah ada di
UML 1
34
Interaction Overview
Gabungan antara activity Sequence diagram
Baru untuk UML 2
Object Contoh konfigurasi instance
Tidak resmi ada di UML 1
Package Struktur hirearki saat kompilasi
Tidak resmi ada di UML 2
Sequence interaksi antar obyek. Lebih menekankan
pada urutan Sudah ada di
UML 1 State Machine
Bagaimana event mengubah sebuah obyek
Sudah ada di UML 1
Timing Interaksi antar obyek. Lebih menekankan
pada waktu Baru untuk
UML 2
Use Case Bagaimana user berinteraksi dengan
sebuah system Sudah ada di
UML 1
2.7.1.1 Sejarah UML
Pengembangan UML dimulai dari kerja sama Grady Booch dan James Rumbaugh pada 1994 untuk mengkombinasikan dua metodologi terkenal Booch
dan OMT. Kemudian Ivan Jacobson, pencipta metode OOSE Object Oriented Sotware Engineering bergabung. Usulan UML diberikan ke OMG Object
Management Group-konsorsium standarisasi teknologi objek agar UML dijadikan bahasa dan notasi pemodelan dilakukan pada 1997. OMG menerima
UML, UML telah menjadi standar de-facto karena pencipta-penciptanya sangat popular. Banyak pengembang perangkat lunak yang mengadopsi UML. OMG
adalah konsorsium yang beranggotakan lebih dari 850 perusahaan untuk mendefinisikan standar-standar teknologi objek termasuk COBRA Common
Object Request Broker Architecture Hariyanto, 2004.
35
2.7.2 Pengertian Obyek
Sebuah obyek memiliki keadaan sesat state dan perilaku behaviour. State sebuah obyek adalah kondisi obyek tersebut yang dinyatakan dalam
attributeproperties. Sedangkan perilaku suatu obyek mendefinisikan bagaimana sebuah obyek bertindakberaksi dan memberikan reaksi. Berikut adalah gambaran
ringkas tentang sebuah obyek lengkap dengan attribute dan operationnya Munawar, 2005.
TV merk
model noSeri
besarInch ubahVolume
ubahChanel aturKontras
Gambar 2.4 obyek Munawar, 2005
2.7.3 Diagram UML
UML memiliki beberapa diagram yang digunakan untuk menggambarkan suatu sistem. Tujuan pembuatan diagram ini adalah agar sistem mudah dimengerti
oleh semua pihak, baik yang teknis maupun non teknis. Beberapa contoh dari diagram tersebut, antara lain:
2.7.3.1 Use Case Diagram
Use case diagram adalah urutan langkah-langkah yang secara tindakan saling terkait skenario, baik terotomatisasi maupun secara manual, untuk tujuan
melengkapi satu tugas bisnis tunggal Whitten, 2004. Use case diagram adalah deskripsi fungsi dari sebuah sistem dari persfektif pengguna. Use case diagram
Nama Obyek Nama Obyek
Operation
36
bekerja dengan cara mendeskripsikan tipikal interaksi antara user pengguna sebuah sistem dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah
sistem dipakai Munawar, 2005. Use case diagram secara grafis menggambarkan interaksi antara sistem,
sistem eksternal dan pengguna Whitten, 2004. Use case diagram menunjukan sekumpulan
kasus fungsional
dan aktor
jenis kelas
khusus dan
keterhubungannya.
2.7.3.2 Diagram Struktur Statis
2.7.3.2.1 Class Diagram
Class diagram menggambarkan struktur objek sistem. Diagram ini menunjukan kelas objek yang menyusun sistem dan juga hubungan antara kelas
objek tersebut Whitten, 2004.
2.7.3.2.2 Object Diagram
Object diagram menyajikan sebuah “snapshot” tentang objek sistem pada
poin waktu tertentu. Diagram ini tidak digunakan sesering diagram kelas, tetapi, saat digunakan, dapat membantu seorang developer untuk memahami struktur
sistem secara lebih baik Whitten, 2004. Object diagram adalah gambaran objek-objek secara ringkas di sebuah
sistem pada suatu waktu Munawar, 2005.
37
2.7.3.3 Diagram Interaksi
Diagram interaksi memodelkan sebuah interaksi, terdiri dari satu set objek, hubungan-hubungannya, dan pesan yang terkirim diantara objek Whitten, 2004.
2.7.3.3.1 Sequence Diagram
Sequence diagram untuk menggambarkan perilaku pada sebuah scenario. Diagram ini menunjukan sejumlah contoh obyek dan message pesan yang
diletakkan diantara obyek-obyek ini di dalam use case Munawar, 2005. Sequence diagram secara grafis 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 Whitten, 2004.
2.7.3.3.2 Collaboration Diagram
Collaboration diagram serupa dengan sequence diagram, tetapi tidak focus pada timing atau sekuensi pesan. Diagram ini malahan menggambarkan interaksi
atau kolaborasi antara objek dalam sebuah format jaringan Whitten, 2004. Collaboration
diagram adalah
perluasan dari
objek diagram.
Collaboration diagram menunjukan message-message objek yang dikirimkan satu sama lain Munawar, 2004.
2.7.3.4 State Diagram
UML memiliki sebuah model diagram untuk memodelkan behavior objek khusus yang kompleks diagram statechart dan sebuah diagram untuk
38
memodelkan behavior dari sebuah use case atau sebuah metode Whitten, 2004, yaitu;
2.7.3.4.1 Statechart Diagram
Statechart diagram digunakan untuk memodelkan behavior objek khusus yang dinamis. Diagram ini menggambarkan siklus hidup objek-berbagai keadaan
yang dapat diasumsikan oleh objek dan event-event yang menyebabkan objek
beralih dari satu state ke state lain Whitten, 2004. 2.7.3.4.2
Activity Diagram
Activity diagram adalah teknik untuk mendeskripsikan logika prosedural, proses bisnis dan aliran kerja dalam banyak kasus. Activity diagram mempunyai
peran seperti halnya flowchart, akan tetapi perbedaannya dengan flowchart adalah activity diagram bisa mendukung perilaku paralel sedangkan flowchart tidak bisa
Munawar, 2005.
Activity diagram
secara grafis
digunakan untuk
menggambarkan rangkaian aliran aktivitas baik proses bisnis atau use case Whitten, 2004.
2.7.3.5 Diagram Implementasi
2.7.3.5.1 Component Diagram
Component diagram digunakan untuk menggambarkan organisasi dan ketergantungan komponen-komponen software sistem. Diagram ini dapat
digunakan untuk menunjukan bagaimana kode pemrograman dibagi menjadi modul-modul atau component Whitten, 2004.
Component diagram adalah bagian fisik dari sebuah sistem, karena menetap di komputer, bukan di benak para analis Munawar, 2004.
39
2.7.3.5.2 Deployment Diagram
Deployment diagram mendeskripsikan arsitektur fisik dalam istilah “node”
untuk hardware dan software dalam sistem. Diagram ini menggambarkan konfigurasi komponen-komponen software run-time, prosesor, dan peralatan yang
membentuk arsitektur sistem Whitten, 2004. Deployment diagram menunjukan tata letak sebuah sistem secara fisik,
menampakkan bagian-bagian software yang berjalan pada bagian-bagian
hardware.
2.8 Database Management System DBMS
2.8.1 Pengertian DBMS
Database adalah sebuah cara mendokumentasikan berbagai macam data yang kemudian dimanajemen dengan sebuah sistem untuk kemudian disimpan
dalam sebuah media penyimpanan. Dengan demikian data-data tersebut dapat diakses dengan mudah dan cepat. Media penyimpanan tersebut dapat kita
ibaratkan sebagai sebuah storage penyimpanan, misalnya Hardisk Nugroho, 2005. Database Management System DBMS adalah suatu perangkat lunak yang
ditujukan untuk menangani penciptaan, pemeliharaan, dan pengendalian akses data. Dengan menggunakan perangkat lunak ini pengelolaan data menjadi mudah
dilakukan Kadir, 2009.
Basis data tidak hanya merupakan kumpulan file. Lebih dari itu, basis data adalah pusat sumber data yang caranya dipakai oleh banyak pemakai untuk
berbagai aplikasi. Inti dari basis data adalah database management system
40
DBMS, yang membolehkan pembuatan, modifikasi, dan pembaharuan basis data, mendapatkan kembali data, dan membangkitkan laporan Kendall, 2003.
Tujuan basis data yang efektif yaitu Kendall, 2003: 1. Memastikan bahwa data dapat dipakai di antara pemakai untuk berbagai
aplikasi. 2. Memelihara data baik keakuratan maupun kekonsistenannya.
3. Memastikan bahwa semua data yang diperukan untuk aplikasi sekarang dan yang akan datang akan disediakan dengan cepat.
4. Membolehkan basis data untuk berkembang dan kebutuhan pemakai untuk berkembang.
5. Membolehkan pemakai untuk membangun pandangan personalnya tentang data tanpa memperhatikan cara data disimpan secara fisik.
2.8.2 Arsitektur Database
Arsitektur basis data dimaksudkan untuk membuat abstraksi terhadap basis data. Tujuannya agar DBMS dapat diakses secara efisien tanpa mengharuskan
pemakai mengetahui detail tentang cara data disimpan dan dipelihara Kadir, 2003.
Ada tiga level dalam arsitektur basis data Kadir, 2003: 1. Level eksternal
Level eksternal yang menyatakan lapisan pandangan atau subskema adalah level yang berhubungan secara langsung dengan pemakai. Pada level ini,
pemakai cukup mengenal struktur data yang sederhana dalam basis data supaya bias mengakses basis data. Pemakai tidak perlu mengetahui detail
tentang atribut data misalnya ukuran data. Dengan menggunakan pandangan
41
view, pemakai dapat melihat data dengan bentuk yang berbeda dengan keadaan aslinya.
2. Level konseptual Level konseptual yang menyatakan skema konseptual menjabarkan data apa
yang tersimpan dalam basis data dan juga menjabarkan hubungan-hubungan antar data. Level ini biasa dipakai administrator basis data.
3. Level internal Level internal yang menyatakan skema internal adalah level yang
berhubungan secara langsung dengan basis data dan menjabarkan bagaimana data disimpan dalam basis data. Level ini berurusan langsung dengan hal yang
antara lai sebagai berikut: 1. Alokasi ruang penyimpanan data
2. Deskripsi rekaman dalam penyimpanan 3. Konpersi data dan teknik enkripsi data
2.9 GUI
Graphical User Interface
Saat ini perangkat lunak danatau sistem informasi yang laku dijual dan dipasarkan adalah yang bersifat ramah pengguna user friendly tanpa
mengorbankan esensinya, yaitu memecahkan masalah tertentu di lingkup pengguna. Seharusnya sejak awal sekali memikirkan hal ini, meski
pelaksanaannya terletak lebih banyak pada saat perancangan Adi, 2005. Pada dasarnya aplikasi harus memiliki cara untuk berkomunikasi dengan penggunanya.
Tampilan memiliki fungsi-fungsi utama sebagai berikut Adi, 2005:
42
1. Input. Antarmuka pengguna harus dirancang untuk mentransformasikan aksi yang seharusnya dilakukan oleh pengguna.
2. Output. Antarmuka pengguna seharusnya menggunakan gambaran tampilan yang baik sebagai cara untuk mengkomunikasikan keluaran dari
aplikasi.
Dibawah ini adalah prinsip-prinsip untuk melakukan perancangan tampilan Adi, 2005:
1. Buat tampilan sederhana. Dengan konsep antarmuka yang ramah, seharusnya membuat aplikasi sedemikian rupa sehingga mudah digunakan
serta mudah dipelajari. 2. Buat antarmuka transparan dan alami. Antarmuka pengguna seharusnya
intuitif dan alami sehingga pengguna dapat memperkirakan apa yang terjadi jika melakukan sesuatu terhadap antarmuka pengguna tersebut.
3. Buat tampilan sedemikian rupa sehingga pengguna dapat mengendalikan aplikasi. Pengguna harus dapat merasakan bahwa seolah-olah dia yang
melakukan proses tertentu, bukannya computer atau aplikasi tertentu.
2.10 Konsep Dasar Internet
