PENGEMBANGAN BERORIENTASI OBJEK

G

agasan orientasi objek sebenarnya dikembangkan sejak tahun 1965-an , perangkat pengembangnya lahir 1967-an,1990 mulai kajian secara insentif,1999 UML menjadilan Notasi bersama untuk pengembangan orientasi objek.Ivar jacobson,Grady Booch,James Rumbaugh menulis buku tentang UML yang .

Paradigma pengembangan/perancangan sistem

1. Paradigma konvensional ( pendekatan terstruktur)
2. Paradigma berorientasi objek

13.1 Paradigma

Paradigma konvensional mengacu kepada strategi dekomposisi yang berdasarkan pada struktur alghoritma atau fungsional. Paradigma ini telah berkembang meliputi seluruh tahap/aktivitas proses perancangan dari mulai pemrograman terstruktur. Paradigma ini telah meliputi seluruh pengembangan sistem secara lengkap dari analisa kebutuhan ( user requirment), analisa masalah perancangan, pemrograman, testing hingga perawatan. Para pakar antara lain:

1. Analisis terstruktur ( structured analysis, DeMarco 1978)

2. Perancangan Terstruktur ( Structured design, Yourdon & Constantine,1979)

3. Teknik analisis dan perancangan terstruktur ( SoftTech,1978)

( DAD, Bagan Terstruktur). Paradigma Orientasi objek adalah pergeseran paradigma, meluncur hingga proses mental bukan hanya sekedar perubahan pada bahasa pemrograman saja. Orientasi Objek adalah cara pandang bukan sekedar Algoritma yang diterapkan pada bahasa yang berorientasi objek. Cara pandang ini harus di distribusikan dali level bawah hingga atas.Edward Berard, menyatakan manfaat teknologi berorientasi objek dapat ditingkatkan jika diterapkan pada seluruh proses perancangan sistem sedini mungkin dan secara kesuluruhan. Meyer, menyatakan Gagasan Berorientasi objek dimaksudkan untuk diterapkan pada semua tahap pengembangan sistem , termasuk Analisis,perancangan, implementasi hingga perawatan.

Terdapat banyak metode analisis berorientasi objek. Masing-masing metode memperkenalkan proses untuk analisis sistem, sejumlah diagram dan notasi di proses yang memungkinkan rekayasawan nienciptakan model analisis secara konsisten. Beberapa metode analisis berorientasi objek yang popular adalah: Metode Anallsis Booch mendefinisikan sekumpulan tugas analisis yang diterapkan ulang page masing-masing langkah di proses makro. Pendekatan evolusioner diterapkan. Pada pengembangan mikro dilakukan" identifikasi kelas dan objek, semantics kelas dan objek dan mendefinisikan keterhubungan antar kelas dan objek-­objek, serta serangkaian aktivitas untuk memperbaiki model analisis. Metode Analisis Rumbaugh (OMT - Object Modeling Technique) Pada Metode Analisis Rumbaugh (OMT - Object Modeling Technique),analisis dilakukan beragam tahap dengan catatan sebagai berikut Pengembang berpengalaman dapat mengkombinasikan beberapa tahap ataumelakukan tahap-tahap tertentu secara parallel,Iterasi tahap-tahap diperlukan pada tingkat-tingkat abstraksi lebih bawah untuk menambahkan rincian-rincian ke model,Setelah seluruh analisis diselesaikan,pada abstraksi tingkat tinggi, subsistem­subsistem, proyek besar dapat dirancang secara independen dan kongkuren untuk abstraks tingkat-tingkat bawah .

Model analisis harus memasukkan informasi, yang berarti dari perspektif dunia nyata dan harus mempresentasikan pandangan ekstemal terhadap sistem itu. Model harus dapat di mengerti client dan harus menyediakan basis yang berguna untuk menyatakan kebutuhan sistem. Kebutuhan adalah yang memang benar ­benar diperlukan, secara internal konsisten, dan mampu dipenuhi. Model rancangan dituntun oleh relevansi menuju implementasi komputer. Model rancangan harus efisien dan praktis dikodekan. Dalam prakteknya banyak bagian model analisis yang telah siap di implementasikan tanpa perubahan, terdapat overlap antara model analisis dan rancangan. Pada tahap analisis memiliki tujuan mengembangkan model, mengenai apa yang akan dilaksanakan sistem. Model, diekspresikan dengap objek-objek dan keterhubungannya, aliran kontrol dinamis dan transformasi fungsional.

Proses menangkap kebutuhan dan berkonsultasi dengan pembeli harus terus-menerus selama analisis. Memberikan deskripsi awal mengenai masalah (pernyataan masalah),bangun model objek melalui tahapan Identifikasi kelas-kelas objek,membuat kamus berisi deskripsi kelas-kelas, atribut-atribut dan asosiasi-asosiasi. Mengembangkan model dinamis seperti Persiapkan skenario-skenario dari barisan-barisan interaksi,Identifikasi kejadian-kejadian antara objek-objek dan persiapkan jejak kejadian untuk tiap scenario,Persiapkan diagram alir kejadian untuk sistem itu. Membangun model fungsional dapat meliputi Identifikasi nilai-nitai masukan dan keluaran,Deskripsikan yang dilakukan tiap fungsi. Metode Jacobson (OOSE - Object Oriented Software Engineering)Metode ini berbeda dengan lainnya pada penekanan pada use-case - yaitu deskripsi atau skenario mengenai cara pemakai berinteraksi dengan sistem atau produk.

13.2 PENDEKATAN BERORIENTASI OBJEK

Metode adalah ” Prosedur untuk melakukan sesuatu” sedang metodologi adalah ” studi mengenai metode” sedangkan metode perancangan selalu berrevolusi.

Sistem-sistem berbasis komputer merupakan hasil dari analisis dan dirancang sebaik mungkin. Pendekatan konvensional ( aliran data atau terstruktur) tidak berdasarkan entitas-entitas di dunia eksternal dan hal ini mempersulit dalam mengelola dan mengadaptasi ketika terjadi perubahan kebutuhan.

Pendekatan berorientasi objek lebih efektif karena objek-objek dapat merepresentasikan bagian-bagian dari dunia eksternal,mempersempit kesenjangan ( gap) konseptual antara dunia eksternal dan komponen-komponen perangkat lunak.

Pengembangan sistem berorientasi objek berbeda dengan pengembangan konvensional yang memandang perangkat lunak sebagai fungsi dan data yang terisolasi. Pada pendekatan konvensional menekankan pada fungsi , namun juga ada pendekatan pada data. Pandangan berorientasi objek berpusat pada objek yang mengkombinasikan data dan fungsi secara serentak. Berorientasi objek adalah cara memandang persoalan menggunakan model-model yang diorganisasikan seputar objek yang mengkombinasikan struktur data dan perilaku suatu entitas.

Pada pendekatan berorientasi objek , blok pembangunan utama sistem adalah objek dan/atau kelas. Rumbaugh menyatakan bahwa kandidat-kandidat kelas umumnya dapat merupakan sesuatu yang dapat diperoleh dari kosa kata ( Vocabulary) di ruang persoalan dan/atau ruang solusi. Kelas adalah deskripsi himpunan objek yang serupa. Kelas merupakan cetak biru dari objek dan setiap objek memiliki identitas. Paradigma orientasi objek merupakan evolusi dari sejumlah konsep dari bidang berbeda yang ternyata berkesimpulan konvergen ( mengkerucut pada satu titik) yaitu: Kelas objek yang digunakan untuk mensimulasikan dunia nyata.

Keunggulan pengembangan sistem berorientasi objek:

● Mengarahkan penggunaan ulang komponen-komponen program sebelumnya.

● Mudah dipelihara karena struktur secara inhern sudah decuple

● Lebih mudah diadaptasi dan diskala menjadi sistem lebih besar, karena dapat

merakit sistem-sistem yang digunakan ulang.

Langkah pertama menuju analisis berorientasi objek adalah berkaitan dengan pembuatan model yang presisi, relevan ,tegas dapat dipahami dn benar dari dunia nyata. Maksud analisis berorientsi objek adalah memodelkan domain persoalan sehingga dapata dimengerti dan bertindak sebagai basis stabil ditahap perancangan.

Perancangan berorientasi objek, merupakan cetak biru dan pemrograman dengan bahasa berorientasi objek

Hal ini berbeda denga metode konvensional ( analisa/perancangan terstruktur yang menggunakan tool DFD yang berorientasi pada aliran, dan perancangan pada bagan terstruktur yang berorientasi pada hirarki.

Keunggulan berorientasi objek adalah:

1. Bekerja dengan pendekatan objek
2. Mudah dikembangkan dan membantu ekspoitasi bahasa pemrograman orientasi objek.

Kriteria-kriteria pendekatan objek untuk metodologi dan bahasa.Berikut ini adalah kriteri-kriteria penting pendekatan objek pada metodologi dan bahasa:

1. Seamlesness

Konsep berorientasi objek dapat diterapkan diseluruh siklus hidup pengembangan sistem( syatem development life cycle) dari analisis., perancangan hingga implementasi. Kelas-kelas yang sama terus dibawa dari satu tahap samapai tahap berikutnya tanpa perubahan notasi.

13.3 PENGEMBANGAN SISTEM BERORIENTASI OBYEK

Unified Modeling Language (UML) adalah cara sukses merombak analisa berorientasi objek dan desain, dan muncul pertama kali pada tahun 90an. Itu ada setelah banyak pemikiran – pemikiran gabungan dari Booch, Rumbaugh (OMT) dan Jacobson, yang dianggap sebagai pendahulu munculnya UML. UML menembus proses standarisasi bersama OMG (Object Management Group) dan sekarang menjadi standar pembuatan sistem yang sering dipakai.

UML disebut juga contoh bahasa yang Terdiri dari banyak cara dan kaidah – kaidah yang sangat penting dalam perancangan dan desain suatu sistem, UML sebagai grafis utama untuk catatan cara mendesain dengan cepat dan prosedural. Dalam mendesain dan merancang sistem UML menganjurkan tahapan – tahapan dalam pengerjaannya. Karena UML adalah bagian yang sangat penting untuk dijadikan sebagai kaidah dalam perancangan dan desain sistem. Sebuah kepastian adalah bagian kunci terpenting dalam melakukan komunikasi untuk sebuah rancangan, jika anda berdiskusi dengan seseorang tentang perancangan dan desain yang terstruktur, UML adalah hal kedua yang anda butuhkan untuk dipahami, bukan sekedar proses untuk mendapatkan desain yang bagus.

Seperti kebanyakan pengembangan perangkat lunak yang sekarang, UML juga dapat menjalankan objek pada bahasa pemrograman. Banyak orang yang kagum dengan kelayakan desain dengan dunia orientasi objek. Cara desain ini sangat populer pada pengembangan industri pada tahun 70an dan 80an. Dan banyak membantu secara teknik seseorang untuk menganalisa dan mendesain dengan benar dimana sangat dibutuhkan untuk pengembangan yang berorientasi objek.

Pendekatan berorientasi objek mempunyai keunggulan sebagai berikut :

v Pendekatan objek menuntun penggunaan ulang (reuse) komponen – komponen program sebelumnya. Penggunaan kembali menuntun pengembangan perangat lunak yang lebih cepat dan berkualitas lebih tinggi.

v Perangkat lunak yang dikembangkan dengan berorientasi objek mempermudah pemeliharaannya karena strukturnya secara inheren sudah decouple.

v Sistem berorientasi objek lebih mudah diadaptasi dan diskala menjadi sistem lebih besar karena sistem – sistem lebih besar dibuat dengan merakit subsistem – subsistem yang dapat diguna ulang.

Organisasi sistem keseluruhan disebut arsitektur sistem (system architecture). Kriteria aplikasi dicirikan kepentingan relatif terhadap model objek dan dinamis. Selama perancangan sistem, seluruh struktur ditetapkan. Perancangan sistem mempartisi persoalan menjadi subsistem – subsistem yang dapat dikerjakan secara independen oleh beberapa orang.

Tahap perancangan dimulai dengan hasil keluaran yang dihasilkan tahap analisis, dan aktivitas yang dilakukan adalah secara perlahan bergeser tekanannya dari dominan aplikasi / persoalan / masalah menuju ke domain komputasi, melibatkan :

· Pendefinisian strategi implementasi.

· Penyelesaian trade-off kriteria – kriteria kualitas yang muncul.

Kelas – kelas tambahan ditambahkan ditahap ini berkaitan dengan penyelesaian implementasi yang kompleks untuk mengejar efisiensi, kinerja dan fleksibilitas. Hal ini sangat berbeda dengan metode konvensional (analisis / perancangan terstruktur) dimana

· Kakas utama di analisis terstruktur adalah DFD berorientasi aliran , sementara

· Kakas utama di perancangan terstruktur adalah structured chart berorientasi hirarki.

Salah satu klaim pendekatan berorientasi objek dalam pengembangan sistem adalah transisi yang mulus dari tahap analisis,perancangan, pengkodean, dan pengujian dan seterusnya. UML mendefinisikan diagram-diagram sebagai berikut:

· use case diagram

· class diagram

· statechart diagram

· activity diagram

· sequence diagram

· collaboration diagram

· component diagram

· deployment diagram

Langkah-Langkah Penggunaan UML,Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:

1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.
2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.
4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.
5. Berdasarkan use case diagram, mulailah membuat activity diagram.
6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
7. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.
9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
• Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
• Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.
13. Piranti lunak siap dirilis.

13.3.1 Aktor dan Use Case Diagram

Aktor dapat teridiri dari seseorang,sekelompok orang ,divisi atau sesuatu yang dapat berinteraksi dengan system saat ini atau yang dikemabangkan. Aktor terdapat di luar system/perangkat lunak yang dikembangkan dan bersifat eksternal. Aktor adalah pemakai sistem dapat berupa manusia atau sistem terotomatisasilain. Aktor adalah sesuatu atau seseorang yang berinteraksi dengan sistem, yaitu siapa atau apa yang menggunkan sistem. Yang dimaksud dengan berinteraksi adalah aktor mengirim atau menerima pesan ke atau dari sistem atau mempertukarkan informasi dengan sistem.

Aktor adalah tipe (kelas). Aktor mempresentasikan peran bukan pemakai individu dari sistem. Aktor mempunyai nama. Nama yang dipilih seharunya menyatakan peran aktor. Aktor berkomunikasi dengan sistem lewat pengiriman dan penerimaan pesan. use-case selalu diawali oleh aktor yang mengirim pesan, disebut dengan stimulus. use-case dapat mengirim pesan ke satu aktor atau lebih.

Gambar 13.1 Aktor dan Usecase

Diagram use-case (use-case diagram) diciptakan oleh Ivar Jacobson, merupakan salah satu diagram untuk memodelkan pengembangan sitem. Diagram use-case menunjukkan sekumpulan use-case , aktor dan hubungannya. Diagram use-case beruguna untuk menvisualisasikan, menspsifikasikan dan mendokumentasikan kebutuhan sistem dan meruapakan pusat pemodelan perilaku sistem, subsistem dan kelas. use-case merupakan interaksi antara aktor eksternal dan sistem, hasil yang dapat diamati oleh aktor, berorientasi pada tujuan , dideskripsikan pada diagram use-case dan teks.use-case melibatkan:

a. sistem

b. Aktor, entitas-entitas luar yang berkomunikasi dengan sistem

c. use-case merupakan fungsionalitas yang di persepsi oleh aktor.

d. Relasi adalah relasi anatar aktor dengan use-case

Diagram use-case digunakan untuk mendeskripsikan apa yang akan dilakukan oleh sistem yang terdiri dari langkah-lakah atau tahapan-tahapan proses yang menjadi unteraksi dalam sistem. Diagram use-case menggantikan diagram Konteks pada pendekatan terstruktur / konvensional.

Tujuan utama pemodelan use-case adalah:

1. Memutuskan dan mendeskripsikan kebutuhan-kebutuhan funsional system.
2. Mendeskripsikan dengan jelas dan konsisten dari apa yang seharusnya dilakukan secara menyeluruh.
3. Menyediakan basis pengujian sistem yang memverivikasi sitem.
4. Mempunyai kemampuan penelusuran kelas yang dipengaruhi use-case dalam perancangan dan implementasi.

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.

Gambar 13.2 tahapan proses sistem

Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri.

Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.