Pemrograman Berorientasi Objek

2.7 Pemrograman Berorientasi Objek

Pemrograman berorientasi objek merupakan paradigma baru dalam rekayasa software yang didasarkan pada objek dan kelas. Diakui para ahli bahwa pemrograman berorientasi objek merupakan metodologi terbaik yang ada saat ini dalam rekayasa software. Pemrograman berorientasi objek menggantikan pemrograman terstruktur karena mempunyai banyak keunggulan dalam menangani proyek yang luar biasa kompleks (Hariyanto, 2007). Pemrograman berorientasi objek memandang software bagian per bagian, dan menggambarkan satu bagian tersebut dalam satu objek. Satu objek dalam sebuah model merupakan suatu fokus selama dalam proses analisis, perancangan dan implementasi dengan menekankan pada state, perilaku (behavior) dan interaksi objek dalam model tersebut.

Pemrograman berorientasi objek merupakan suatu konsep yang banyak digunakan oleh pengembang software, karena menawarkan kemudahan dalam desain, pengembangan, dan perawatan, sehingga merupakan pendekatan yang efektif untuk membangun perangkat lunak yang fleksibel. Teknologi pemodelan dan pemrograman berorientasi objek memudahkan dalam pengembangan software , baik pengubahan, menambah, dan memperbaiki arsitektur software (Sumarta, Siswoyo, & Juhana, 2004).

Pemrograman berorientasi objek adalah sebuah konsep pemrograman untuk membuat kode program yang lebih terstruktur, terkelompok, berdasarkan objek- objek yang terlibat sehingga bagian-bagiannya dapat digunakan untuk pembuatan aplikasi lain. Pemrograman berorientasi objek membagi-bagi kode program Pemrograman berorientasi objek adalah sebuah konsep pemrograman untuk membuat kode program yang lebih terstruktur, terkelompok, berdasarkan objek- objek yang terlibat sehingga bagian-bagiannya dapat digunakan untuk pembuatan aplikasi lain. Pemrograman berorientasi objek membagi-bagi kode program

2.7.1 Prinsip-prinsip Pemrograman Berorientasi Objek

Ada tujuh prinsip pengembangan berorientasi objek yang terdiri dari empat prinsip utama, yaitu abstraksi (abstraction), enkapsulasi (encapsulation), modularitas (modularity), hirarki (hierarchy)], dan tiga prinsip tambahan, yaitu mengetik (typing), konkurensi (concurrency), dan ketekunan (persistence) (Booch, 1994). Jika ada prinsip utama yang tidak terpenuhi, maka tidak dapat dianggap berorientasi objek. Sedangkan prinsip tambahan berguna untuk kemudahan, tetapi tetap dapat dianggap berorientasi objek walaupun tidak ada.

Berikut ini adalah penjelasan dari empat prinsip utama dari pemrograman berorientasi objek:

a. Abstraksi Memfokuskan perhatian pada karakteristik objek yang paling penting dan paling dominan yang bisa digunakan untuk membedakan objek tersebut dari objek lainnya. Dengan abstraksi ini pengembang bisa menerapkan konsep KIS (Keep It Simple) pada objek di dunia nyata yang memiliki tingkat kerumitan yang tinggi.

b. Enkapsulasi Menyembunyikan banyak hal yang terdapat dalam objek yang tidak perlu diketahui oleh objek lain. Dalam praktek pemrograman enkapsulasi diwujudkan dengan membuat suatu kelas interface yang akan dipanggil oleh objek lain, sementara di dalam objek yang dipanggil terdapat kelas lain yang mengimplementasikan apa yang terdapat dalam kelas interface. Objek lain hanya tahu dia perlu memanggil kelas interface tanpa perlu tahu proses apa saja yang dilakukan di dalam kelas implementasinya, dan untuk menuntaskan proses tersebut perlu berhubungan dengan objek mana saja. Dengan demikian bila terjadi proses perubahan pada proses implementasi maka objek pemanggil tidak akan terpengaruhi secara langsung.

c. Modularitas Membagi sistem yang rumit menjadi bagian-bagian yang lebih kecil yang bisa mempermudah pengembang memahami dan mengelola objek tersebut. Contohnya adalah sistem akademis yang bisa dibagi menjadi kemahasiswaan, daftar mata kuliah, pembayaran uang kuliah, dan lain- lain.

d. Hirarki Hirarki berhubungan dengan abstraksi dan modularitas, yaitu pembagian berdasarkan urutan dan pengelompokan tertentu. Misalnya untuk menentukan objek mana yang berada pada kelompok yang sama, objek mana yang merupakan komponen dari objek yang memiliki hirarki lebih tinggi. Semakin rendah hirarki objek berarti semakin jauh abstraksi dilakukan terhadap suatu objek.

Keempat prinsip dasar ini merupakan hal yang mendasari teknologi objek yang perlu ditanamkan dalam cara berpikir pengembang berorientasi objek.

2.7.2 Bahasa Pemrograman Berorientasi Objek

Sebuah bahasa berorientasi objek bukan hanya yang berbasis obyek, tetapi juga menyediakan dukungan untuk pewarisan dan polimorfisme (Booch, 1994). Jadi, sebuah bahasa pemrograman dinyatakan mendukung pemrograman berorientasi objek jika bahasa itu mendukung syarat-syarat pemrograman berorientasi objek sebagai berikut:

a. Enkapsulasi (encapsulation) Mampu membungkus atribut-atribut dan metode-metode dalam sebuah kelas, dan dapat mencegah pengaksesan langsung terhadap atribut-atribut dan metode-metode yang diinginkan di dalam sebuah kelas.

b. Pewarisan (inheritance) Memungkinkan adanya pendefinisian kelas baru yang memiliki sifat-sifat keturunan dari kelas lain.

c. Polimorfisme (polymorphism) Memungkinkan pembuatan pengaksesan metode-metode dengan nama yang sama namun berbeda parameter masukan atau berbeda kelas.

2.7.3 Desain Pemrograman Berorientasi Objek

UML (Unified Modelling Language) adalah salah satu alat bantu yang sangat handal di dunia pengembangan sistem berorientasi objek karena menyediakan bahasa pemodelan visual yang memungkinkan pengembang membuat cetak biru atas visi mereka dalam bentuk baku, mudah dimengerti, serta dilengkapi mekanisme yang efektif untuk berbagi (sharing) dan mengkomunikasikan rancangan dengan pihak lain (Munawar, 2005).

Sejak tahun 1997, UML telah dijadikan sebagai standar pengembangan berorientasi objek (Dennis, Wixom, & Roth, 2009), juga sebagai standar bahasa grafis dan notasi untuk menggambarkan model berorientasi objek (Gomaa, 2011). Pemodelan dengan UML dapat menghasilkan gambaran yang jelas dan memberikan

mendesain, dan mengimplementasikannya (Sumarta, Siswoyo, & Juhana, 2004). UML (Unified Modelling Language) merupakan metodologi kolaborasi antara metode-metode Booch, OMT (Object Modeling Technique), serta OOSE (Object Oriented Software Engineering) dan beberapa metode lainnya, merupakan metode yang paling sering digunakan saat ini untuk analisis dan perancangan sistem dengan metode berorientasi objek (Nugroho, 2009).

UML 2 digambarkan dalam 13 jenis diagram resmi (Fowler, 2003) yang dapat dilihat pada gambar di bawah ini:

Class Diagram

Component Diagram

Composite Structure Diagram

Structure Deployment Diagram

Diagram

Object Diagram

Package Diagram

Diagram

Activity Diagram

Use Case Diagram

Behavior Diagram

State Machine Diagram

Sequence Diagram

Diagram Interaction

Overview Diagram

Timing Diagram

Gambar 2. 2 Jenis diagram resmi UML 2

Berikut ini adalah penjelasan diagram-diagram dari gambar 3.1 di atas:

A. Class Diagram Diagram kelas (Class Diagram) juga merupakan salah satu diagram yang ada pada UML. Diagram kelas (class diagram) menggambarkan struktur aplikasi berorientasi objek dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun aplikasi. Kelas memiliki apa yang disebut aribut dan metode/operasi. Atribut merupakan variabel-variabel yang A. Class Diagram Diagram kelas (Class Diagram) juga merupakan salah satu diagram yang ada pada UML. Diagram kelas (class diagram) menggambarkan struktur aplikasi berorientasi objek dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun aplikasi. Kelas memiliki apa yang disebut aribut dan metode/operasi. Atribut merupakan variabel-variabel yang

B. Component Diagram Component diagram merupakan diagram UML yang menampilkan komponen dalam sistem dan hubungan antara mereka. Component diagram adalah diagram yang digunakan untuk menggambarkan organisasi dan ketergantungan komponen-komponen software . Component diagram berguna untuk memodelkan komponen objek. Pada component view , akan difokuskan pada organisasi fisik sistem. Pertama, diputuskan bagaimana kelas-kelas akan diorganisasikan menjadi kode pustaka. Kemudian akan dilihat bagaimana perbedaan antara berkas eksekusi, berkas Dynamic Link Library (DDL), dan berkas runtime lainnya dalam sistem.

C. Composite Structure Diagram Composite structure diagram adalah diagram untuk menunjukkan dekomposisi secara hierarkis sebuah class ke sebuah struktur internal. Hal ini memungkinkan untuk memecah objek yang kompleks menjadi bagian-bagian yang kecil.

D. Deployment Diagram Deployment diagram menunjukkan tata letak sebuah sistem secara fisik, menampakkan bagian-bagian software yang berjalan pada bagian-bagian hardware yang digunakan untuk mengimplementasikan sebuah sistem dan keterhubungan antara komponen-komponen hardware tersebut. Deployment diagram dapat digunakan pada bagian-bagian awal proses perancangan sistem untuk mendokumentasikan arsitektur fisik sebuah sistem.

E. Object Diagram Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah sistem pada satu titik waktu. Karena lebih menonjolkan perintah- perintah daripada class, object diagram lebih sering disebut sebagai sebuah diagram perintah.

F. Package Diagram Package diagram adalah sebuah bentuk pengelompokan yang memungkinkan untuk mengambil setiap bentuk di UML dan mengelompokkan elemen-elemen dalam tingkatan unit yang lebih tinggi. Kegunaan package yang paling umum adalah untuk mengelompokkan class .

G. Activity Diagram Activity diagram digunakan untuk mendokumentasikan alur kerja pada sebuah sistem, yang dimulai dari pandangan business level hingga ke operational level . Pada dasarnya, activity diagram merupakan variasi dari state machine diagram. Activity diagram mempunyai peran seperti halnya flowchart, akan tetapi perbedaannya dengan flowchart adalah activity diagram bisa mendukung perilaku paralel sedangkan flowchart tidak bisa.

H. Use Case Diagram Use case diagram adalah salah satu diagram yang ada dalam UML (Unified Modeling Language). Use case diagram merupakan merupakan pemodelan untuk kelakuan (behavior) aplikasi perangkat lunak yang akan dibuat. Use case diagram mendeskripsikan interaksi antara satu atau lebih aktor dengan aplikasi yang akan dibuat. Secara kasar, use case diagram digunakan untuk mengetahui fungsi/proses apa saja yang ada di dalam sebuah aplikasi dan siapa saja yang berhak menggunakan fungsi- fungsi atau proses-proses itu. Ada dua hal utama pada use case diagram yaitu pendefinisian apa yang disebut aktor dan use case, berikut ini penjelasannya:

a. Aktor merupakan orang, proses, atau aplikasi lain yang berinteraksi dengan aplikasi yang akan dibuat diluar aplikasi itu sendiri, jadi walaupun simbol dari aktor adalah gambar orang tapi aktor belum tentu merupakan orang.

b. Use case merupakan fungsi-fungsi/proses-proses yang disediakan aplikasi sebagai unit-unit yang saling bertukar pesan/berinteraksi antar b. Use case merupakan fungsi-fungsi/proses-proses yang disediakan aplikasi sebagai unit-unit yang saling bertukar pesan/berinteraksi antar

I. State Machine Diagram State machine diagram digunakan untuk menelusuri individu-individu objek melalui keseluruhan daur hidupnya, menspesifikasi semua urutan yang mungkin dari pesan-pesan yang akan diterima objek tersebut bersama-sama dengan tanggapan atas pesan-pesan tersebut. Diagram state menggambarkan transisi dan perubahan keadaan suatu objek dalam sistem sebagai akibat dari stimuli yang diterima. Pada umumnya diagram ini menggambarkan class tertentu. State diagram membantu analis, perancang dan pengembang untuk memahami perilaku objek dalam sistem.

J. Sequence Diagram Sequence diagram adalah diagram yang digunakan untuk mendokumentasikan komunikasi/interaksi antarkelas. Diagram ini menunjukkan sejumlah objek dan message (pesan) yang diletakkan diantara objek-objek di dalam use case. Perlu diingat bahwa di dalam diagram ini, kelas-kelas dan aktor-aktor diletakkan di bagian atas diagram dengan urutan dari kiri ke kanan dengan garis lifeline yang diletakkan secara vertikal terhadap kelas dan aktor.

K. Communication Diagram Communication diagram atau collaboration diagram juga menggambarkan interaksi antarobjek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message (pesan). Setiap message memiliki sequence number , di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.

L. Interaction Overview Diagram Interaction overview diagram adalah pencangkokan secara bersama antara activity diagram dengan sequence diagram. Interaction overview diagram dapat dianggap sebagai activity diagram di mana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga L. Interaction Overview Diagram Interaction overview diagram adalah pencangkokan secara bersama antara activity diagram dengan sequence diagram. Interaction overview diagram dapat dianggap sebagai activity diagram di mana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga

M. Timing Diagram Timing diagram adalah bentuk lain dari interaction diagram, di mana fokus utamanya lebih ke waktu. Timing diagram sangat berdaya guna dalam menunjukkan faktor pembatas waktu di antara perubahan state pada objek yang berbeda.