2. LANDASAN TEORI. 5 Universitas Kristen Petra

(1)

5

Universitas Kristen Petra

Bab 2 ini berisi tentang landasan teori dalam pembuatan Tugas Akhir.

Landasan teori yang dibuat meliputi teori tentang web portal, object oriented programming (OOP), unfield modeling language (UML), entity control and boundary classes, dan model view controller (MVC) patterns.

2.1. Web Portal

Web portal adalah situs web yang menyediakan kemampuan tertentu yang dibuat sedemikian rupa dengan tujuan untuk mencoba menuruti selera para pengunjungnya. Kemampuan portal yang lebih spesifik adalah penyediaan kandungan informasi yang dapat diakses menggunakan beragam perangkat, misalnya komputer pribadi, komputer jinjing (notebook), PDA (Personal Digital Assistant), atau bahkan telepon genggam. (Wikipedia ensiklopedia bebas, 2007).

Sebuah portal berarti sebuah “pintu” atau sebuah titik masuk (entry point) atau titik awal untuk sesuatu. Portal dapat berupa web seperti Yahoo, Excite, MSN dan AOL, atau web yang sangat spesifik dan terfokus pada minat tertentu, seperti sebuah web portal untuk pengumpul komik, pecinta boneka ataupun PHP programmer. (Waters, et al., 2002).

Web dibagi menjadi dua tipe utama, yaitu content sites dan portal sites.

Sebuah content site adalah web dengan informasi, produk atau pelayanan yang dikunjungi untuk suatu tujuan tertentu. Portal sites adalah web yang dikunjungi untuk menemukan content sites. (Waters, et al., 2002).

Web portal dapat mempunyai banyak jenis, seperti web portal daerah, web portal pemerintah, web portal perusahaan dan web portal komunitas

Web portal mempunyai beberapa keuntungan seperti :

1 Pengintegrasian kepandaian (intelligent) dan akses ke isi perusahaan, aplikasi dan proses.

2 Meningkatkan komunikasi dan kolaborasi pelanggan, rekan dan para pekerja.

(2)

3 Menyatukan, akses real-time ke informasi yang diadakan oleh sistem yang terpisah.

4 Memudahkan user untuk memodifikasi dan pemeliharaan penyajian website sesuai dengan selera.

2.2. Object Oriented Programming

Pemrograman berorientasi obyek (object oriented programming, OOP) memandang aplikasi perangkat lunak sebagai kumpulan obyek yang saling berinteraksi di dalam suatu sistem. Merancang suatu aplikasi dengan teknik OOP dilakukan dengan membagi fungsi-fungsi berdasar pembagian tanggung jawab.

(Azis, 2005).

Keuntungan yang diperoleh dari pendekatan berorientasi obyek ini adalah kemudahan untuk mengelola kompleksitas aplikasi yang dibuat dan kemudahan untuk melakukan perubahan dan pengembangan dari aplikasi tersebut.

Dengan teknik OOP, jalinan komunikasi antar-pemrogram juga dipermudah karena masing-masing class yang dibuat akan dilengkapi dengan interface yang menjadi standar bagaimana class tersebut bisa dihubungi. Interface ini mencakup :

1. Nama

2. Operasi yang menjadi tugasnya 3. Cara penggunaannya

4. Hasil yang diperoleh

Tingkat saling ketergantungan antarmodul yang rendah akan memudahkan penggantian, perbaikan, atau pengembangan suatu modul dengan tidak menimbulkan efek pada modul lainnya.

2.2.1. Obyek

Elemen dasar dari konsep pemrograman berorientasi obyek (OOP) adalah obyek itu sendiri. Obyek merupakan abstraksi sesuatu dalam dunia nyata. Sesuatu ini dapat berupa benda, aktivitas, manusia, business system atau workflow.

Sebuah obyek memiliki atribut dan metode. Atribut adalah data yang terkandung di dalam obyek, sedangkan metode adalah operasi-operasi yang

(3)

disediakan oleh obyek untuk mengkases atau memodifikasi atribut yang dimilikinya.

Sebagai contoh sebuah obyek rekening tabungan akan memiliki atribut sebagai berikut :

1. nomor_rekening

2. nama_pemilik_rekening 3. saldo_tabungan

Sedangkan metode-metode yang dimiliki oleh obyek rekening tabungan adalah sebagai berikut :

1. informasi_data_rekening 2. melihat_saldo

3. pengambilan 4. penyetoran

Sebuah obyek bekerja berdasarkan perintah (message) yang dikirimkan kepadanya. Bagaimana cara mengirimkan perintah ke obyek diatur oleh interface yang disediakan oleh obyek tersebut. Obyek berinteraksi dengan obyek lainnya dengan cara mengirim perintah ke interface yang disediakan oleh obyek tersebut.

Perintah yang dikirim menyebutkan metode mana yang diminta beserta parameter yang diminta.

2.2.2. Class

Obyek-obyek seringkali memiliki karekteristik yang sama. Si Andi mempunyai nama, tanggal lahir, jenis kelamin, tinggi badan, berat badan dan sebagainya. Andi dapat melakukan beberapa aktivitas seperti makan, berjalan, tidur, belajar dan sebagainya. Si Jenny juga mempunyai nama, tanggal lahir, jenis kelamin, tinggi badan, berat badan seperti Andi. Selain itu Jenny juga dapat melakukan beberapa hal seperti yang dapat dilakukan oleh Andi.

Dalam contoh di atas Andi dan Jenny dapat dikatakan sebagai obyek dari class Manusia, karena mereka mempunyai karakteristik yang dimiliki oleh class Manusia. Atribut seperti, nama, tanggal lahir, jenis kelamin, tinggi badan, berat badan dan metode atau fungsi seperti makan, berjalan, tidur, belajar adalah atribut dan fungsi yang dimiliki oleh class Manusia.

(4)

Gambar 2.1. Class Rekening Tabungan

Seperti contoh sebelumnya, rekening tabungan yang dimiliki oleh seseorang hanyalah salah satu dari berjuta-juta rekening tabungan yang ada.

Semua rekening tabungan memiliki karakteristik yang sama yang merupakan ciri- ciri atau atribut dari sebuah class yang bernama rekening tabungan seperti nomor rekening, nama pemilik rekening, dan saldo tabungan. Pada umumnya semua rekening tabungan dapat melakukan operasi seperti menyetor atau melakukan penarikan. Akan tetapi nilai atribut dari masing-masing obyek rekening tabungan akan berbeda-beda.

Ketika bank akan mengeluarkan sebuah rekening tabungan, bank pembuat menggunakan fakta bahwa rekening tabungan itu memiliki definisi karakteristik tertentu yang harus dimiliki oleh obyek rekening tabungan. Rekening tabungan yang baru dibuat tersebut adalah instance dari sebuah class yang bernama rekening tabungan. Dalam hal ini bank membuat rekening tabungan berdasarkan sebuah cetakan atau sebuah blueprint untuk rekening tabungan. Cetakan atau blueprint obyek ini disebut class.

2.2.3. Inheritance

Selain dapat membuat obyek sebagai instance dari sebuah class, dapat juga membuat sebuah class berdasarkan pada sebuah class yang telah ada

(5)

sebelumnya. Pembuatan sebuah class baru berdasarkan pada sebuah class yang sudah ada sebelumnya disebut inheritence. Class baru yang mewarisi sifat-sifat class sebelumnya disebut subclass dan class yang mewariskan sifat-sifatnya disebut superclass.

Gambar 2.2. Inheritence dari Class Rekening Tabungan

Subclass akan mewarisi semua metode-metode dari class yang lama (superclass). Selain itu, sebuah subclass juga dapat memodifikasi metode-metode yang ada, bahkan dapat juga menambahkan metode-metode baru yang belum ada pada superclass.

Keuntungan dari penggunaan inheritence adalah :

1. Di dalam subclass dapat didefinisikan metode yang lebih spesifik pada metode yang ada di superclass. Hal ini memungkinkan penggunaan berulang (reuse) dari kode program.

2. Dapat dibuat sebuah superclass yang bersifat generik yang disebut abstract class. Abstract class ini berisikan metode-metode “kosong”. Metode-metode ini kemudian “diisi” sesuai spesifikasi dari subclass.

(6)

2.2.4. Polymorphism

Polymorphism berarti sebuah obyek dapat memiliki berbagai bentuk, yaitu sebagai obyek dari class-nya sendiri ataupun sebagai obyek dari superclass-nya.

Ada dua macam bentuk polymorphism, yaitu overloading dan overridding.

Overloading adalah penggunaan satu nama untuk beberapa metode yang berbeda dalam suatu class. Metode-metode yang namanya sama ini dibedakan satu dengan yang lain berdasarkan parameter yang disediakan masing-masing metode. Misal dalam class bangun ruang, metode untuk menghitung luas terdiri dari beberapa metode berdasarkan bangun ruangnya. Jika obyek adalah lingkaran, maka metode menghitung luas yang dipakai yaitu metode dengan parameter hanya jari-jari saja. Sedangkan obyek persegi panjang akan menggunakan metode menghitung luas dengan parameter panjang dan lebar.

Overriding adalah mendeklarasikan sebuah metode dengan nama dan parameter yang sama dengan suatu metode dari superclass-nya. Metode yang dideklarasikan di subclass akan meng-override metode superclass-nya, sehingga variabel di dalam subclass ini akan menutupi variabel di dalam superclass-nya.

2.2.5. Hubungan antar Class

Saat melakukan perancangan aplikasi dengan metode berorientasi obyek akan terlihat bahwa class-class yang di dalam suatu aplikasi memiliki hubungan satu terhadap yang lainnya. Terdapat tiga macam hubungan antara satu class dengan class lainnya, yaitu: generalization, dependency dan associations.

2.2.5.1. Generalization

Generalization adalah hubungan antar-class dimana class yang satu merupakan generalisasi dari class lainnya yang lebih spesifik atau spesialis. Class yang lebih general disebut superclass, sedangkan yang lebih spesifik disebut subclass. Generalization biasa juga disebut inheritence. Hubungan yang timbul biasa disebut “is-a relationship”. Sebagai contoh, lingkaran dan persegi panjang adalah bangun ruang. Atau pada contoh sebelumnya, Tabungan Haji, Tabungan Pendidikan dan Tabungan Pensiun adalah Tabungan. Class yang memiliki satu superclass disebut single inheritence. Class yang memiliki lebih dari satu

(7)

superclass disebut multiple inheritence. Class yang tidak memiliki superclass disebut baseclass.

2.2.5.2. Dependency

Dependency adalah hubungan ketergantungan antar satu class dengan class lainnya. Pada hubungan ini satu class dapat mengubah spesifikasi atau kondisi (state) dari class lainnya. Contohnya, class Pintu memiliki hubungan dependency dengan class Operasi_Pintu dimana class Operasi_Pintu dapat mengubah kondisi class Pintu, dari kondisi tertutup menjadi terbuka.

2.2.5.3. Association

Association adalah hubungan struktural yang menspesifikasikan bahwa obyek dari sebuah class berhubungan dengan obyek dari class lainnya dan sebaliknya. Contohnya, class Dosen memiliki hubungan “mengajar” dengan class Universitas dimana hubungan mengajar ini bersifat many-to-many, yang berarti satu obyek instance dari class Dosen dapat mengajar di satu atau lebih obyek instance dari class Universitas dan sebaliknya.

Association memperlihatkan sebuah hubungan yang setara dimana satu class tidak lebih superior daripada class lainnya. Adakalanya hubungan ini tidak setara dimana class yang satu merupakan bagian dari class lainnya, seperti hubungan aggregation. Aggregation adalah hubungan yang timbul yang biasa disebut “has-a relationship”, sebagai contoh class Kendaraan mempunyai class Mesin.

2.3. Unfield Modeling Language (UML)

Pada umumnya metode-metode yang ditujukan untuk pembangunan aplikasi berorientasi obyek menggunakan UML untuk memodelkan berbagai artefak dari perangkat lunak.

UML adalah sekumpulan simbol dan diagram untuk memodelkan software. Dengan menggunakan UML, desain software dapat diwujudkan dalam bentuk simbol dan diagram. Desain dalam bentuk simbol dan diagram kemudian dapat diterjemahkan menjadi kode program. (Kimmel, 2001)

(8)

2.3.1. Diagram UML

UML menyediakan 10 macam diagram untuk memodelkan aplikasi berorientasi obyek, yaitu :

1. Use Case Diagram, untuk memodelkan proses bisnis.

2. Activity Diagram, untuk memodelkan perilaku Use Case dan obyek di dalam sistem.

3. Class Diagram, untuk memodelkan struktur class.

4. Object Diagram, untuk memodelkan struktur obyek.

5. Conceptual Diagram, untuk memodelkan aplikasi konsep-konsep yang ada si dalam aplikasi.

6. Sequence Diagram, untuk memodelkan pengiriman message antar obyek.

7. Collaboration Diagram, unuk memodelkan interaksi antar obyek.

8. State Diagram, untuk memodelkan perilaku obyek dalam sistem.

9. Component Diagram, untuk memodelkan komponen obyek.

10. Deployment Diagram, untuk memodelkan distribusi aplikasi.

2.3.1.1. Use Case Diagram

Use Case Diagram mempunya 2 fungsi yaitu mendefinisikan fitur apa yang harus disediakan oleh sistem dan menyatakan sifat sistem dari sudut pandang user. Proses bisnis dalam diagram disebut “use case” sedangkan orang atau user dari proses tersebut disebut “actor”.

Actor digambarkan dengan sosok manusia. Use case mempresentasikan operasi-operasi yang dilakukan oleh actor. Use case digambarkan berbentuk elips dengan nama operasi di dalamnya. Actor yang melakukan operasi dihubungan garis lurus ke use case, atau yang disebut dengan asosiasi.

(9)

Gambar 2.3. Elemen-elemen dalam Use CaseDiagram

Dependensi atau hubungan ketergentungan dalam diagram Use Case terdapat dua jenis, yaitu include dan extend. Dependensi include adalah hubungan antar dua use case dimana yang satu memanggil yang lain. Jika pada beberapa use case terdapat bagian yang memiliki aktifitas yang sama maka bagian aktifitas tersebut biasanya dijadikan use case tersendiri dengan relasi dependensi setiap use case semula ke use case yang baru ini sehingga memudahkan pemeliharaan.

Hubungan ini digambarkan dengan garis putus-putus bermata panah dengan notasi <<include>> pada garis dan arah mata panah sesuai dengan arah pemanggilan.

Gambar 2.4. Contoh penggunaan dependensi include

(10)

Jika pemanggilan memerlukan adanya kondisi tertentu maka berlaku dependensi extend. Kondisi ini digambarkan serupa dengan include, dengan garis putus-putus bermata panah dengan notasi <<extend>> pada garis, namun arah panah berlawanan.

Gambar 2.5. Contoh penggunaan dependensi extend

Generalisasi mendefinisikan relasi antara dua actor atau dua use case yang mana salah satunya menurunkan dan menambahkan atau override sifat dari yang lainnya. Penggambaran menggunakan garis bermata panah kosong dari yang menurunkan mengarah kepada yang diturunkan.

Gambar 2.6. Contoh penggunaan generalisasi pada use case

2.3.1.2. Activity Diagram

Activity dagram adalah versi UML untuk sebuah flowchart. Activity diagram digunakan untuk menganalisis proses. Sebuah activity diagram bukan sebuah tool yang sempurna untuk menganalisis masalah dari sistem. Sebagai tool untuk menganalisis, pemrogram tidak ingin untuk memulai memecahkan masalah di level teknis dengan membuat class, tetapi dengan menggunakan activity diagram untuk mengerti masalah dan menyaring proses yang terdapat dalam sistem.

(11)

Setiap activity diagram selalu mempunyai satu initial state.Initial node yang digambarkan dengan simbol lingkaran padat, merupakan titik yang mengawali activity diagram. Activity diagram dapat diakhiri dengan memberikan activity final node yang digambarkan dengan lingkaran padat dengan mempunyai cincin di bagian luarnya.

Action node adalah sesuatu yang dilakukan atau yang sedang terjadi dalam activity diagram. Action node mempunyai simbol yang hampir mirip dengan use case namun mempunyai bentuk yang lebih ramping dan menyerupai bujur sangkar.

Decision node disebut decision diamonds di dalam flowchart. Simbol diamond adalah satu elemen yang membuat activity diagram mengingat akan flowchart, yang berguna untuk memberi kondisi percabangan.

Keberadaan sebuah transition fork untuk menggambarkan tingkah laku yang pararel atau bercabang. Sebuah transition join untuk mempertemukan tingkah laku yang pararel.

Gambar 2.7. Komponen-komponen dalam Activity Diagram

(12)

2.3.1.3. Class Diagram

Class diagram menggambarkan class dan hubungan antar-class di dalam sistem. Class digambarkan dibangun berdasar use case diagram, sequence diagram atau collaboration diagram yang telah dibuat sebelumnya.

2.3.1.3.1. Struktur Class

Class digambarkan dengan sebuah kotak dibagi menjadi tiga bagian.

Bagian paling atas diisikan nama class, bagian tengah diisikan atribut atau variabel yang dimiliki class dan bagian bawah diisikan dengan metode-metode atau opearsi-operasi dari class tersebut.

Gambar 2.8. Struktur Class.

2.3.1.3.2. Hubungan Antar-class

Diagram UML juga dapat digunakan untuk memodelkan hubungan antar- class. Hubungan tersebut dapat berupa generalization, realization, associations, aggregation, composition dan dependency.

(13)

2.3.1.3.2.1. Generalization

Generalization adalah hubungan antar-class yang bersifat umum (superclass atau parent class) dengan class yang bersifat lebih spesifik (subclass atau child class).

Gambar 2.9. Generalization

2.3.1.3.2.2. Realization

Realization adalah hubungan antar-class dimana sebuah class memiliki keharusan untuk mengikuti aturan yang ditetapkan class lainnya. Pada umumnya realization dipakai untuk menspesifikasikan hubungan antara sebuah interface dengan class yang mengimplementasikan interface tersebut.

Gambar 2.10. Realization

(14)

2.3.1.3.2.3. Associations

Associations adalah hubungan structural antar-instance. Sebagai contoh, obyek Perusahaan memiliki armada angkutan yang terdiri atas satu atau lebih obyek Truk.

Gambar 2.11. Associations

2.3.1.3.2.4. Aggregation

Aggregation adalah hubungan antar-class dimana class yang satu (part class) adalah bagian dari class yang lainnya. Sebagai contoh, obyek Engine merupakan bagian dari obyek Truk. Di dalam aggregation, siklus hidup part class tidak bergantung pada whole class sehingga meskipun obyek instance dari whole class telah dihapus, obyek instance dari part class masih dapat eksis.

2.3.1.3.2.5. Composition

Composition adalah aggregation dengan ikatan yang lebih kuat. Di dalam composite aggregation, siklus hidup part class sangat bergantung pada whole class sehingga bila obyek instance dari whole class dihapus maka obyek instance dari part class juga akan dihapus.

(15)

Gambar 2.12. Aggregation dan Composition

2.3.1.3.2.6. Dependency

Dependency adalah hubungan antar-class dimana sebuah class memiliki ketergantungan pada class lainnya tetapi tidak sebaliknya.

Gambar 2.13. Dependency

2.3.1.4. Sequence Diagram

Sequence diagram digunakan untuk memberikan gambaran detail dari setiap use case diagram yang telah dibuat sebelumnya. Setiap obyek yang terlibat dalam sebuah use case digambarkan dengan garis putus-putus vertical, kemudian

(16)

message yang dikirim oleh obyek digambarkan dengan garis horizontal secara kronologis dari atas ke bawah.

Gambar 2.14. Sequence Diagram.

2.3.1.5. Collaboration Diagram

Collaboration diagram dipakai untuk memodelkan interaksi antar-obyek di dalam sistem. Berbeda dengan sequence diagram yang lebih menonjolkan kronologis dari operasi-operasi yang dilakukan, collaboration diagram lebih fokus pada pemahaman atas keseluruhan operasi yang dilakukan oleh obyek.

Di dalam collaboration diagram diilustrasikan class-class dan instance- nya. Dua buah instance dihubungkan dengan link line. Message digambarkan dengan garis panah di atas link line.

(17)

Gambar 2.15. Notasi Collaboratian Diagram

2.4. Entity, Control and Boundary classes

Pada mulanya pemrogram menggunakan kartu class responsibility and collaborator (CRC). Kartu CRC adalah sebuah konsep yang melibatkan sebuah teknologi rendah menggunakan 3 x 5 kartu indeks. Pemrogram menulis class- class yang ditemukan di bagian atas kartu indeks. Bagian bawah ditulis daftar tanggung jawab dan class-class lain yang dibutuhkan untuk menjalakan tanggung jawab class tersebut. Jika sebuah kartu belum ada untuk sebuah tanggung jawab maka sebuah kartu baru dibuat. (Kimmel, 2001)

Menciptakan kartu CRC adalah ide yang baik, tetapi akan sulit jika aplikasi yang akan dibuat dalam skala yang besar. Oleh karena itu untuk memudahkan pembuatan class-class maka sebelumnya menentukan terlebih dahulu entity classes, kemudian control classes dan boundary classes.

Entity classes merepresentasikan data yang dibutuhkan untuk disimpan dalam database. Entity classes mencakup juga logical entity. Logical entity adalah view atau hasil dari query yang beragam-ragam dari satu tabel atau banyak tabel.

Control classes merepresentasikan jembatan antara entity classes dengan boundary classes dan business logic di antaranya. Control classes dapat mengatur bagaimana data disusun untuk entity classes, bagaimana data disusun untuk mempresentasikan class-class dan bagaimana data disusun untuk sistem lain melalui boundary classes. Salah satu pattern yang cukup terkenal yang

(18)

menggunakan control pattern secara umum, yaitu Model View Control (MVC) pattern.

Boundary classes digunakan untuk menjembatani subsistem. Tujuannya adalah untuk menjembatani sistem dari interaksi langsung dengan subsistem yang ada di luar.

Gambar 2.16. Simbol Class Boundary, Control dan Entity. Sumber : Paul Kimmel, UML demystified : A self teaching guide (Osborne: McGraw-Hill, 2001)

figure 5-21.

2.5. Model View Controller (MVC) Patterns

MVC Pattern adalah patern dasar yang memisahkan ketiga bagian program menjadi tiga buah obyek yang terpisah. Ketiga bagian program tersebut adalah model, view dan controller. (Azis, 2005).

Gambar 2.17. MVC Pattern

Controller pada dasarnya merupakan penerima tamu dari permintaan yang datang (HTTP request). Fungsinya adalah untuk mengevaluasi permintaan yang datang, kemudianmengarahkannya ke obyek yang tepat untuk memproses permintaan tersebut.

(19)

View adalah hasil akhir yang dikirimkan ke pengguna aplikasi. Format HTML merupakan contoh umum hasil akhir yang dikirimkan dalam aplikasi web.

Model merupakan representasi dari proses bisnis di dalam aplikasi perangkat lunak. Lebih mudahnya, dapat juga disebutkan bahwa Model adalah bagian yang bertugas untuk mengolah data mentah menjadi data yang mengandung arti yang diinginkan oleh pengguna.

Bagian View dan Controller bergantung pada bagian Model, namun sebaliknya bagian Model tidak bergantung pada kedua bagian lainnya.

Gambar 2.18. Mekanisme dalam MVC Pattern