UML ( Unified Modeling Language ) & PENDEKATAN OOD ( Object Oriented Design ) UNTUK SISTEM WAKTU NYATA

Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal asalan.Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability, security, dan eksekusi yang robust walaupun dalam kondisi yang sulit.

Selain itu arsitekturnya harus idefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain selain programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang matang adalah mungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama. Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean(coding). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh.

Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik. Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security, dan sebagainya. Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode pemodelan (notation), proses (process) dan tool yang digunakan. Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (praoses) akan membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.

A. Pengenalan “Unified Modeling Language/UML

Unified Modelling Language (UML) adalah sebuah “bahasa” yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

Dalam suatu proses pengembangan software, analisa dan rancangan telah merupakan terminologi yang sangat tua. Pada saat masalah ditelusuri dan spesifikasi dinegoisasikan, dapat dikatakan kita berada pada tahap rancangan.

Merancang adalah menemukan suatu cara untuk menyelesaikan masalah, salah satu tool / model untuk merancang pengembangan software yang berbasis object oriented adalah UML.

1.    Konsep Objek

Obyek dalam ‘software analysis & design’ adalah sesuatu berupa konsep (concept), benda (thing), dan sesuatu yang membedakannya dengan lingkungannya. Secara sederhana obyek adalah mobil, manusia, alarm dan lain- lainnya. Tapi obyek dapat pula merupakan sesuatu yang abstrak yang hidup didalam sistem seperti tabel, database, event, system messages. Obyek dikenali dari keadaannya dan juga operasinya. Sebagai contoh sebuah mobil dikenali dari warnanya, bentuknya, sedangkan manusia dari suaranya. Ciri- ciri ini yang akan membedakan obyek tersebut dari obyek lainnya.

Alasan mengapa saat ini pendekatan dalam pengembangan software dengan object-oriented, pertama adalah scalability dimana obyek lebih mudah dipakai untuk menggambarkan sistem yang besar dan komplek. Kedua dynamic modeling, adalah dapat dipakai untuk permodelan sistem dinamis dan real time.

2.    Sejarah Singkat UML

UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO(Object-Oriented). UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan komponen-komponen yang diperlukan dalam sistem software.Pendekatan analisa & rancangan dengan menggunakan model OO mulai diperkenalkan sekitar pertengahan 1970 hingga akhir 1980 dikarenakan pada saat itu aplikasi software sudah meningkat dan mulai komplek. Jumlah yang menggunakaan metoda OO mulai diuji cobakandan diaplikasikan antara 1989 hingga 1994, seperti halnya oleh Grady Booch dari Rational Software Co., dikenal dengan OOSE (Object-Oriented Software Engineering), serta James Rumbaugh dari General Electric, dikenal dengan OMT (Object Modelling Technique).

Kelemahan saat itu disadari oleh Booch maupun Rumbaugh adalah tidak adanya standar penggunaan model yang berbasis OO, ketika mereka bertemu ditemani rekan lainnya Ivar Jacobson dari Objectory mulai mendiskusikan untuk mengadopsi masing-masing pendekatan metoda OO untuk membuat suatu model bahasa yang uniform / seragam yang disebut UML (Unified Modeling Language) dan dapat digunakan oleh seluruh dunia.

Secara resmi bahasa UML dimulai pada bulan oktober 1994, ketika Rumbaugh bergabung Booch untuk membuat sebuah project pendekatan metoda yang uniform/seragam dari masing-masing metoda mereka. Saat itu baru dikembangkan draft metoda UML version 0.8 dan diselesaikan serta di release pada bulan oktober 1995. Bersamaan dengan saat itu, Jacobson bergabung dan UML tersebut diperkaya ruang lingkupnya dengan metoda OOSE sehingga muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML version 1.3 telah diperkaya dan direspons oleh OMG (Object Management Group), Anderson Consulting, Ericsson, Platinum Technology, ObjectTime Limited, dll serta di pelihara oleh OMG yang dipimpin oleh Cris Kobryn. UML adalah standar dunia yang dibuat oleh Object Management Group (OMG), sebuah badan yang bertugas mengeluarkan standar-standar teknologi object- oriented dan software component.

3.    Pengenalan UML

UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan kata-kata dalam ‘MS Word’ untuk kegunaan komunikasi. Sebuah bahasa model adalah sebuah bahasa yang mempunyai vocabulary dan konsep tatanan / aturan penulisan serta secara fisik mempresentasikan dari sebuah sistem. Seperti halnya UML adalah sebuah bahasa standard untuk pengembangan sebuah software yang dapat menyampaikan bagaimana membuat dan membentuk model-model, tetapi tidak menyampaikan apa dan kapan model yang seharusnya dibuat yang merupakan salah satu proses implementasi pengembangan software.

UML tidak hanya merupakan sebuah bahasa pemograman visual saja, namun juga dapat secara langsung dihubungkan ke berbagai bahasa pemograman, seperti JAVA, C++, Visual Basic, atau bahkan dihubungkan secara langsung ke dalam sebuah object-oriented database. Begitu juga mengenai

pendokumentasian dapat dilakukan seperti; requirements, arsitektur, design, source code, project plan, tests, dan prototypes. Untuk dapat memahami UML membutuhkan bentuk konsep dari sebuah bahasa model, dan mempelajari 3 (tiga) elemen utama dari UML seperti building block, aturan-aturan yang menyatakan bagaimana building block diletakkan secara bersamaan, dan beberapa mekanisme umum (common).

a.     Building blocks

Ada 3 macam yang terdapat dalam building block adalah katagori benda/Things, hubungan, dan diagram. Benda/things adalah abstraksi yang pertama dalam sebuah model, hubungan sebagai alat komunikasi dari benda- benda, dan diagram sebagai kumpulan / group dari benda-benda/things.

o        Benda/Things

Adalah hal yang sangat mendasar dalam model UML, juga merupakan bagian paling statik dari sebuah model, serta menjelaskan elemen-elemen lainnya dari sebuah konsep dan atau fisik. Bentuk dari beberapa benda/thing adalah sebagai berikut:

-       sebuah kelas yang diuraikan sebagai sekelompok dari object yang mempunyai atribute, operasi, hubungan yang semantik. Sebuah kelas mengimplementasikan 1 atau lebih interfaces. Sebuah kelas dapat digambarkan sebagai sebuah persegi panjang, yang mempunyai sebuah nama, atribute, dan metoda pengoperasiannya, seperti terlihat dalam gambar 1.

-       yang menggambarkan ‘interface’ merupakan sebuah antar-muka yang menghubungkan dan melayani antar kelas dan atau elemen. ‘Interface’ / antar- muka mendefinisikan sebuah set / kelompok dari spesifikasi pengoperasian, umumnya digambarkan dengan sebuah lingkaran yang disertai dengan namanya. Sebuah antar-muka berdiri sendiri dan umumnya merupakan pelengkap dari kelas atau komponen, seperti dalam gambar 2.

-       collaboration yang didefinisikan dengan interaksi dan sebuah kumpulan / kelompok dari kelas-kelas/elemen-elemen yang bekerja secara bersama-sama. Collaborations mempunyai struktura dan dimensi. Pemberian sebuah kelas memungkinkan berpartisipasi didalam beberapa collaborations dan digambarkan dengan sebuah ‘elips’ dengan garis terpotong-potong.

-       sebuah ‘use case’ adalah rangkaian/uraian sekelompok yang saling terkait dan membentuk sistem secara teratur yang dilakukan atau diawasi oleh sebuah aktor. ‘use case’ digunakan untuk membentuk tingkah-laku benda/ things dalam sebuah model serta di realisasikan oleh sebuah collaboration. Umumnya‘use case’ digambarkan dengan sebuah ‘elips’ dengan garis yang solid, biasanya mengandung nama, seperti terlihat dalam gambar 4.

-       sebuah node merupakan fisik dari elemen-elemen yang ada pada saat dijalankannya sebuah sistem, contohnya adalaha sebuah komputer, umumnya mempunyai sedikitnya memory dan processor. Sekelompok komponen mungkin terletak pada sebuah node dan juga mungkin akan berpindah dari node satu ke node lainnya. Umumnya node ini digambarkan seperti kubus serta hanyamengandung namanya, seperti terlihat dalam gambar 5.

o        Hubungan / Relationship

Ada 4 macam hubungan didalam penggunaan UML, yaitu; dependency, association, generalization, dan realization.

-       sebuah dependency adalah hubungan semantik antara dua benda/thing yang mana sebuah benda berubah mengakibatkan benda satunya akan berubah pula. Umumnya sebuah dependency digambarkan sebuah panah dengan garis terputus-putus seperti terlihat dalam gambar 6.

-       sebuah association adalah hubungan antar benda struktural yang terhubung diantara obyek Kesatuan obyek yang terhubung merupakan hubungan khusus, yang menggambarkan sebuah hubungan struktural diantara seluruh atau sebagian. Umumnya assosiation digambarkan dengan sebuah garis yang dilengkapi dengan sebuah label, nama, dan status hubungannya seperti terliahat dalam gambar 7.

 

-       sebuah generalization adalah menggambarkan hubungan khusus dalam obyek anak/child yang menggantikan obyek parent / induk . Dalam hal ini, obyek anak memberikan pengaruhnya dalam hal struktur dan tingkah lakunya kepada obyek induk. Digambarkan dengan garis panah seperti terlihat dalam gambar 8.

-       sebuah realization merupakan hubungan semantik antara pengelompokkan yang menjamin adanya ikatan diantaranya. Hubungan ini dapat diwujudkan diantara interface dan kelas atau elements, serta antara use cases dan collaborations. Model dari sebuah hubungan realization seperti terlihat dalam gambar 9.

o        Diagram

UML sendiri terdiri atas pengelompokkan diagram-diagram sistem menurut aspek atau sudut pandang tertentu. Diagram adalah yang menggambarkan permasalahan maupun solusi dari permasalahan suatu model. UML mempunyai 9 diagram, yaitu; use-case, class, object, state, sequence, collaboration, activity, component, dan deployment diagram. Diagram pertama adalah use case menggambarkan sekelompok use cases dan aktor yang disertai dengan hubungan diantaranya. Diagram use cases ini menjelaskan dan menerangkan kebutuhan / requirement yang diinginkan/ dikehendaki user/pengguna, serta sangat berguna dalam menentukan struktur organisasi dan model dari pada sebuah sistem.

UML mendefinisikan diagram-diagram sebagai berikut:

a.    Use – Case Diagram

Use-case diagram adalah gambaran graphical dari beberapa atau semua actor, use-case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. 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 dapat digunakan selama proses analisis untuk menangkap requirement 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 system 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.

Komponen Pembentuk Use-case Diagram

-       Actor

Pada dasarnya actor bukanlah bagian dari use-case diagram, namun untuk dapat terciptanya suatu use-case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use-case, tetapi tidak memiliki kontrol atas use-case. Actor digambarkan dengan stick man. Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship

Gambar 2.1. Actor

Ada beberapa kemungkinan yang menyebabkan actor tersebut terkait dengan sistem  antara lain :

-       Yang berkepentingan terhadap sistem dimana adanya arus informasi, baik yang diterimanya maupun yang dia inputkan ke sistem

-       Orang ataupun pihak yang akan mengelola sistem tersebut

-       External resource yang digunakan oleh sistem

-       Sistem lain yang berinteraksi dengan sistem yang akan dibuat

b.    Use-case

Use-case adalah gambaran fungsionalitas dari suatu sistem, pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun. Use-case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use-case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.

Cara menentukan Use-case dalam suatu sistem :

-       Pola perilaku perangkat lunak aplikasi

-       Gambaran tugas dari sebuah actor

-       Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor

-       Apa yang dikerjakan oleh suatu perangkat lunak (*bukan bagaimana cara mengerjakannya”)

c.    Relasi dalam Use-case

Ada beberapa relasi yang terdapat pada use-case diagram :

-       Association, menghubungkan link antar elemen.

-       Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.

-       Dependency, sebuah element bergantung dalam beberapa cara ke elemen lainnya.

-       Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.

Tipe relasi atau  stereotype yang mungkin terjadi pada use-case diagram :

1.     <<include>>, yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use-case adalah bagian dari use-case lainnya.

2.     <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.

3.     <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use-case.

1.    Class Diagram

Diagram yang menunjukkan sekumpulan class, interface dan collaboration serta relationships. Diagram ini biasa ditemukan pada pemodelan object oriented system. Class diagram menunjukkan view desain statik dari sebuah sistem. Class diagram yang termasuk active class menunjukkan view proses statik sebuah sistem.

2.    Object Diagram

Object diagram adalah bentuk lain dari class diagram tetapi  menggunakan cara yang berbeda. Perbedaan diantara keduanya adalah pada object diagram memperlihatkan beberapa object yang merupakan instansi dari sebuah class. Sebuah object diagram menggunakan notasi penggambaran yang sama dengan class diagram kecuali dalam penulisan nama dan hubungan antar object. Object diagram dapat digunakan untuk menggambarkan class diagram yang kompleks meskipun penggunaannya tidak sepenting class diagram.

3.    Sequence Diagram

Diagram interaksi yang menekankan pada waktu pengiriman message. Sequence diagram menunjukkan sekumpulan objek dan pengiriman serta penerimaan message antar objek. Objek yang umumnya memiliki nama atau instansiasi dari class, tapi dapat pula merupakan turunan dari things lain, seperti collaboration, component dan node. Diagram ini digunakan untuk mengilustrasikan dynamic view dari system.

4.    Collaboration Diagram

Diagram interaksi yang menekankan pada struktur organisasi dari objek yang menerima dan megirim message. Collaboration diagram menunjukkan sekumpulan objek dan hubungan diantaranya serta pengiriman dan penerimaan message. Objek yang umumnya memiliki nama atau instansiasi dari class, tapi dapat pula merupakan turunan dari things lain, seperti collaboration, component dan node. Diagram ini digunakan untuk mengilustrasikan dynamic view dari system.

5.    Activity Diagram

Activity diagram menggambarkan urutan aktifitas yang digunakan untuk menjelaskan aktifitas dari sebuah operasi. Pada activity diagram terdapat keadaan aksi yang berisi spesifikasi dari aktifitas tertentu. Diagram ini berisi, pilihan keputusan dan kondisi serta spesifikasi message yang dikirim atau diterima sebagai gambaran dari aksi.

6.    State Diagram

Sebuah state diagram menggambarkan keadaan mesin, transisi, event dan activity. Diagram ini adalah pelengkap khusus untuk mendeskripsikan sebuah class yang menggambarkan state dari objek dari class dan event yang menyebabkan state berubah. Event tersebt dapat berasal dari objek yang mengirimkan suatu message atau dari kondisi yang terpenuhi.

7.    Component Diagram

Component diagram menjelaskan struktur fisik kode pada komponen kodede. Sebuah komponen dapat berupa komponen source code, komponen binary atau komponen executable. Komponen berisi informasi tentang logical class. Ketergantungan diantara komponen dapat memudahkan untuk menganalisa bagaimana komponen yang lain terpengaruh dengan perubahan pada sebuah component.

8.    Deployment Diagram

Deployment diagram menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak pada sebuah system. Kita dapat memperlihatkan computer dan alat yang terhubung (nodes), serta ketergantungan antar component. Dengan model yang baik, kita dapat memakai semua cara dari sebuah node pada arsitektur fisik ke komponen ke class implementasi ke objek yang berinteraksi dan terakhir ke dalam use case.

B.   PENDEKATAN OOD ( Object Oriented Design ) UNTUK SISTEM WAKTU NYATA

Pemrograman Berorientasi Objek merupakan perbaikan dari pemrograman structural (atau disebut juga fungsional). Kelemahan dari pemrograman structural adalah kurangnya modularitas dari data yang ada. Sebuah perubahan pada sebuah data yang tersimpan menyebabkan banyaknya perubahan yang harus dilakukan pada data – data lain yang berhubungan.  Salah satu contoh permasalahan yang timbul akibat dari pemrograman structural ini adalah permasalahan Y2K (bug yang terjadi pada tahun 2000) yang menyebabkan kerugian materi dalam jumlah yang besar. OO memberikan sebuah metode untuk membangun perangkat lunak yang lebih handal (robust) dengan semakin besar dan kompleksnya sistem.

a.  Konsep

o        Modularitas

Sistem berorientasi objek terdiri dari modul – modul. Modularitas adalah sebuah konsep yang menekankan penggabungan data – data dan fungsi – fungsi yang berhubungan ke dalam sebuah kesatuan (modul) yang sama.

Ada 2 hal yang yang perlu diketahui tentang modul :

- Untuk setiap modul yang ada, mungkin terdapat beberapa variabel. Setiap variabel memiliki nilai tersendiri.

- Sebuah modul berkomunikasi dengan modul lain dengan cara saling memanggil fungsi yang ada.

o        Enkapsulasi

Enkapsulasi adalah sebuah konsep yang menekankan bahwa hanya setiap variabel yang memiliki data itu sendirilah yang dapat melakukan perubahan (modifikasi) terhadap data tersebut ataupun membaca data tersebut. Konsep ini memberikan struktur yang handal (robust) tetapi menyebabkan perubahan lebih mudah bisa dilakukan terhadap sistem.

o        Terminologi

Setiap modul pada sistem berorientasi objek disebut juga sebagai objek. Pada dunia nyata, objek memiliki 2 karakteristik, yaitu : data dan kelakuan.

Data untuk setiap objek secara umum disebut atribut dari objek. Kelakuan yang berbeda dari setiap objek disebut juga metode dari objek. Metode adalah analogi langsung dari fungsi atau prosedur pada bahasa pemograman.

Kelas adalah template dari sebuah objek. Sebuah kelas mendeskripsikan atribut dan metode yang akan ada untuk semua variabel dari kelas.

o        Kelebihan dan Kelemahan Object Oriented Programming dibanding Structural Programming

Pengembangan perangkat lunak menuntut keahlian teknis yang tinggi, ketekunan luar biasa, serta kemampuan mengelola proyek yang memadai. Di masa lalu, pengembangan perangkat lunak memakan waktu yang lama, biaya yang melebihi perkiraan, kurang memenuhi harapan dan kebutuhan pengguna dan yang paling parah banak perangkat lunak yang tidak bisa digunakan setelah selesai dikembangkan karena jauh dari apa yang diharapkan pengguna.

Pada saat ini, perangkat lunak yang dikembangkan harus mampu mengakomodasi perubahan-perubahan yang terjadi sangat cepat terutama untuk merespon perubahan lingkungan bisnis dan kebutuhan pengguna yang berubah dengan cepat. Oleh karena itu diperlukan metode pengembangan perangkat lunak yang lebih sesuai. Metode terstruktur yang selama ini digunakan dirasakan kurang memadai lagi.

Dalam pengembangan perangkat lunak dengan metode terstruktur, para perancang mulai dengan mengembangkan blok-blok standar kode untuk melakukan operasi tertentu, kemudian menyalinnya ke aplikasi lain yang ditulis. Hal tersebut menyulitkan saat terjadi perubahan pada blok-blok kode awal, sebab pengembang harus menyalinnya dimanapun kode awal tersebut disalin, yang pada akhirnya menjadikan waktu pengembangan lebih lama.

Pemrograman berorientasi obyek (Object Oriented Programming-OOP) dipandang merupakan kerangka kerja yang paling baik saat ini untuk menggantikan metode terstruktur. Dengan OOP para pengembang menciptakan blokblok kode yang dinamakan objek. Objek-objek ini kemudian digunakan oleh berbagai aplikasi. Dan apabila suatu saat terjadi perubahan, para pengembang hanya melakukan perubahan sekali saja dan dengan mudah mewariskannya ke objek lain yang menjadi turunannya.

Paradigma OOP adalah para pengembang membagi aplikasi-aplikasi yang besar menjadi objek-objek yang mandiri satu terhadap lainnya. Karena OOP menggunakan paradigma yang berbeda dengan pemrograman terstruktur, maka dibutuhkan tool yang berbeda pula. Salahsatu tool tersebut adalah UML (Unified Modelling Language). UML merupakan tool yang sangat sesuai karena konsep dasarnya adalah memodelkan kelas-kelas beserta atribut di dalamnya bersamaan dengan relasi-relasi yang terjadi antar kelas yang bersangkutan. Selain itu, UML memungkinkan pengembang sistem untuk melakukan perancangan hingga ke model fisik perangkat keras (misalnya pada jaringan komputer).

Kelebihan pada umumnya :

- Sistem yang dibangun lebih handal (robust).

- Memiliki gambaran yang lebih baik tentang dunia nyata.

Kelemahan pada umumnya

- Sulit untuk menggambarkan kelakuan dari sistem secara keseluruhan disebabkan oleh karena kelas adalah kesatuan yang bersifat low-level.

o        Karakteristik Dasar Sistem Berorientasi Objek

Sistem berorientasi objek berfokus untuk menangkap struktur dan perilaku dari sistem informasi dalam modul kecil yang mencakup baik data dan proses. Modul-modul kecil ini dikenal sebagai objek. Pada bagian ini bab, kita menjelaskan karakteristik dasar sistem berorientasi objek, yang meliputi kelas, objek, metode, pesan, enkapsulasi, menyembunyikan informasi, pewarisan, polimorfisme, dan dynamic binding.

1.    Classes and Objects

Kelas adalah template umum kita gunakan untuk mendefinisikan dan membuat variabel tertentu, atau bisa disebut benda. Setiap objek berhubungan dengan kelas. Sebagai contoh, semua objek yang menangkap informasi mengenai pasien dapat masuk ke dalam kelas yang disebut Pasien, karena ada atribut (misalnya, nama, alamat, dan tanggal lahir) dan metode (contoh menyisipkan misalnya, menginputkan pasien baru, memelihara informasi, dan menghapus entri ) semua itu adalah apa yang pasien bagikan (lihat Gambar 2.1).

Sebuah objek adalah variabel dari kelas. Dengan kata lain, sebuah objek adalah orang, tempat, peristiwa, atau hal yang ingin kita peroleh sebagai informasi. Jika kita membangun sebuah sistem pendaftaran untuk kantor dokter, kelas mungkin termasuk dokter, pasien, dan perjanjian. Para pasien tertentu seperti Jim Maloney, Mary Wilson, dan Theresa Marks dianggap contoh, atau objek, dari kelas pasien.  Setiap objek memiliki atribut yang mendeskripsikan informasi tentang objek, seperti nama pasien, tanggal lahir, alamat, dan nomor telepon. Keadaan suatu obyek ditentukan oleh nilai atribut dan hubungan dengan obyek lain pada suatu titik waktu tertentu. Sebagai contoh, pasien mungkin memiliki kondisi “baru” atau “sekarang” atau “telah berobat.”

Setiap objek juga memiliki behaviors. Behaviors adalah sifat yang menentukan apa yang dapat dilakukan oleh objek. Sebagai contoh, objek perjanjian dapat berupa menjadwalkan janji baru, menghapus janji, dan mencari janji yang tersedia berikutnya.

Gambar 2.1 Classes And Object

Salah satu aspek yang lebih membingungkan pengembangan sistem berorientasi objek adalah kenyataan bahwa di kebanyakan bahasa pemrograman berorientasi objek, baik kelas dan variabel dari kelas masing-masing dapat memiliki atribut dan metode. Atribut dari kelas dan metode cenderung digunakan untuk atribut model (atau metode) yang berhubungan dengan isu-isu terkait dengan semua variabel kelas. Misalnya, untuk membuat objek pasien baru, pesan dikirim ke kelas pasien untuk membuat sebuah keterangan yang baru untuk kelas itu sendiri. Dari sudut pandang seorang analisis sistem dan desain, maka kita akan berfokus pada atribut dan metode dari objek dan bukan dari kelas.

2.    Methods and Messages

Metode menerapkan perilaku obyek. Sebuah metode tidak lebih dari suatu tindakan yang dapat objek lakukan. Dengan demikian, mereka bersifat analog dengan fungsi atau prosedur dalam bahasa pemrograman tradisional seperti C, COBOL, atau Pascal. Message adalah informasi yang dikirim ke objek untuk memicu metode. Pada dasarnya, pesan adalah fungsi atau prosedur yang dipanggil dari satu objek ke objek lain. Misalnya, jika seorang pasien, baru mendaftar ke kantor dokter, sistem akan mengirim pesan untuk memasukkan informasi ke aplikasi tersebut. Objek pasien akan menerima pesan (instruksi) dan melakukan apa yang perlu untuk dilakukan, tentang memasukkan pasien baru ke dalam sistem (execute adalah metode yang dipakai). Lihat Gambar 2.2.

3.    Encapsulation and Information Hiding

Ide-ide enkapsulasi dan menyembunyikan informasi sangat berhubungan dalam sistem berorientasi objek. Walaupun tidak ada satu pun penjelasan yang baru. Enkapsulasi hanyalah kombinasi sederhana dari proses dan data ke dalam satu kesatuan. Pendekatan tradisional untuk pengembangan sistem informasi cenderung untuk menjadi proses-sentris (misalnya, sistem terstruktur) ataupun data-sentris (misalnya, teknik informasi). Pendekatan berorientasi objek menggabungkan proses dan data ke dalam (objek) secara keseluruhan yang bisa hadir secara bebas tanpa terpengaruh (objek) lain.

Gambar 2.2 Messages and Methods

Information hiding pertama kali diperkenalkan dalam pengembangan sistem terstruktur. Prinsip menyembunyikan informasi menunjukkan bahwa hanya informasi yang dibutuhkan untuk menggunakan sebuah modul perangkat lunak yang akan diterbitkan kepada pengguna modul. Biasanya, hal ini berarti informasi yang dibutuhkan untuk diteruskan ke modul, dan informasi yang kembali dari modul yang telah diterbitkan. Persisnya bagaimana modul dalam menerapkan fungsi yang dibutuhkan adalah tidak relevan. Kita benar-benar tidak peduli bagaimana benda melakukan fungsinya, selama fungsinya bisa terjadi. Dalam sistem berorientasi objek, menggabungkan enkapsulasi dengan prinsip menyembunyikan informasi, menunjukkan bahwa prinsip menyembunyikan informasi diterapkan pada objek bukan hanya menerapkannya pada fungsi atau proses. Dengan demikian, objek diperlakukan seperti kotak hitam.

Secara fakta, bahwa kita bisa menggunakan objek dengan metode memanggil adalah kunci untuk penggunaan ulang karena hal ini melindungi kerja internal objek dari perubahan yang terjadi di sistem luar, dan menjaga sistem dari keterpengaruhan ketika ada perubahan dilakukan terhadap suatu objek. Pada Gambar 2.2, perhatikan bagaimana sebuah pesan (insert pasien baru) akan dikirim kepada suatu objek, namun algoritma internal yang diperlukan untuk menanggapi pesan, tersembunyi dari bagian yang lain dari sistem. Satu-satunya informasi yang objek perlu tahu adalah seperangkat operasi, atau metode, yang objek lain dapat lakukan dan apa pesan yang perlu dikirim untuk memicunya.

4.    Inheritance

Pewarisan, sebagai karakteristik pengembangan sistem informasi, diusulkan dalam pemodelan data di akhir 1970-an dan awal 1980-an. Literatur pemodelan data menyarankan menggunakan pewarisan untuk mengidentifikasi tingkat yang lebih tinggi, atau lebih umum, seperti kelas dari objek. Setting umum dari atribut dan metode dapat diatur menjadi superclasses. Biasanya, kelas diatur dalam hirarki dimana superclasses, atau kelas umum, berada di atas, dan subkelas, atau kelas tertentu, di bagian bawah. Pada Gambar 2.3, seseorang adalah superclass daripada kelas Dokter dan kelas Pasien. Dokter, pada gilirannya, adalah superclass untuk dokter umum dan spesialis. Perhatikan bagaimana kelas (misalnya, dokter) dapat berfungsi sebagai superclass dan subclass secara bersamaan. Hubungan antara kelas dan superclass dikenal sebagai hubungan A-Kind-Of (AKO). Sebagai contoh, pada Gambar 2.3, seorang dokter umum adalah A-Kind dari dokter, dan merupakan A-Kind-Of dari orang.  Subclass mewarisi atribut dan metode yang sesuai dari superclasses di atas mereka. Artinya, setiap subclass berisi atribut dan metode dari superclass induknya. Sebagai contoh, Gambar 2.3 menunjukkan bahwa baik dokter dan pasien adalah subclass orang dan karena itu akan mewarisi atribut dan metode dari class orang. Pewarisan akan membuatnya pendefinisian kelas lebih sederhana. Alih-alih seperti mengulang atribut dan metode di dokter dan pasien yang kelasnya terpisah, atribut dan metode pada umumnya ditempatkan di kelas orang dan diwarisi oleh kelas-kelas di bawahnya. Perhatikan bagaimana jauh lebih efisien hirarki dari kelas objek daripada objek yang sama tanpa hirarki pada Gambar 2.4.

Gambar 2.3 Hirarki Class

Kebanyakan kelas di seluruh hirarki akan mengakibatkan kasus, setiap kelas yang memiliki variabel disebut kelas konkret. Misalnya, jika Mary Wilson dan Jim Maloney adalah attribut nama dari kelas pasien, pasien akan dianggap sebagai kelas konkret. Beberapa kelas tidak menghasilkan kasus karena mereka digunakan hanya sebagai template untuk kelas yang lebih spesifik lain (terutama kelas yang berlokasi tinggi pada sebuah hirarki). Kelas-kelas yang disebut sebagai kelas abstrak. Orang akan menjadi contoh dari kelas abstrak. Daripada membuat objek dari orang, kita akan menciptakan contoh yang mewakili kelas-kelas yang lebih spesifik dari Dokter dan Pasien, kedua jenis orang (lihat Gambar 2.3). Apa jenis kelas adalah kelas dokter umum? Mengapa?

Gambar 2.4 Pewarisan

5.    Polymorphism and Dynamic Binding

Polimorfisme berarti bahwa pesan yang sama dapat diartikan berbeda oleh kelas yang berbeda dari objek. Sebagai contoh, memasukkan pasien berarti sesuatu yang berbeda dari memasukkan janji. Dengan demikian, bagian yang berbeda informasi yang perlu dikumpulkan dan disimpan. Untungnya, kita tidak perlu khawatir tentang bagaimana sesuatu diselesaikan saat menggunakan objek. Kita hanya mengirim pesan ke objek, dan objek yang akan bertanggung jawab untuk menafsirkan pesan secara tepat. Sebagai contoh, jika kita mengirim pesan “Gambarkan bentukmu” untuk objek persegi, objek lingkaran, dan objek segitiga, hasilnya akan sangat berbeda, walaupun pesan tersebut adalah sama. Perhatikan pada Gambar 2.5 bagaimana setiap objek merespon dengan tepat (dan berbeda) meskipun pesan adalah identik.

Polimorfisme bisa dibentuk melalui dynamic binding. Dinamis, atau terlambat, binding adalah teknik yang menunda untuk menentukan tipe objek sampai waktu running. Dengan demikian, metode khusus yang biasa disebut tidak dipilih oleh sistem berorientasi objek sampai sistem berjalan. Hal ini berbeda untuk binding statis. Dalam sistem statis terikat, jenis objek akan ditentukan pada waktu kompilasi. Oleh karena itu, pengembang harus memilih metode mana yang harus dipanggil disamping mengijinkan sistem untuk melakukannya. Inilah sebabnya mengapa di sebagian besar bahasa pemrograman tradisional anda akan menemukan logika yang rumit dalam mengambil keputusan berdasarkan berbagai jenis objek dalam sistem. Sebagai contoh, dalam bahasa pemrograman tradisional, daripada mengirim pesan “Gambarlah bentukmu” ke berbagai jenis objek grafis pada Gambar 2.5, Anda akan harus menulis logika keputusan menggunakan pernyataan case atau satu set pernyataan untuk menentukan objek grafis apa yang ingin anda gambar, dan anda harus menamai setiap fungsi gambar secara berbeda (misalnya, menggambar-persegi, menggambar lingkaran, atau menggambar-segitiga). Hal ini jelas akan membuat sistem yang jauh lebih rumit dan lebih sulit untuk dipahami.

Gambar 2.5 Polimorfisme dan Enkapsulasi

o        Object Oriented Development (OOD)

Dewasa ini konsep object oriented telah mendominasi hampir seluruh aspek komputerisasi. Mulai dari software game, aplikasi bisnis, DBMS, bahkan sampai ke sistem operasi. Hal tersebut terjadi karena konsep object oriented dipandang sebagai suatu konsep yang maju dan dianggap mampu memodelkan hampir semua fenomena yang ada di dunia ini. Hal lain yang menarik adalah kemampuannya untuk mengembangkan perangkat lunak secara incremental dan mengurangi biaya yang sulit dicapai oleh meodologi sebelumnya.

Membangun sistem perangkat lunak dapat diibatkan dengan membangun gedung bertingkat. Gedung bertingkat tidak mungkin dibangun tanpa memiliki cetak biru arsitektur yang lengkap. Proses tradisional untuk melakukan pengembangan sistem informasi dinamakan System Development Life Cycle (SDLC), yang memuat langkah-langkah yang seharusnya diikuti oleh para profesional dalam pengembangan sistem informasi untuk menetapkan spesifikasi, mengembangkan, dan memelihara sistem informasi. Beberapa metode yang cukup dikenal adalah metode air terjun (waterfalls) dan prototyping.

o        Pemodelan perancangan

Untuk memodelkan aplikasi dunia nyata (real world) menggunakan metodologi berorientasi objek, kita perlu memodelkan data maupun proses yang berjalan pada objek yang bersangkutan. Dalam konteks pengembangan sistem berorientasi objek (Object Oriented Development – OOD), terdapat beberapa keuntungan dari penggunaan pemodelan berorientasi objek, yaitu :

- Kemampuan untuk menangani tipe-tipe data dan masalah-masalah yang lebih kompleks dan rumit

-   Memperbaiki komunikasi antara pengguna, analis, perancang, dan pemrogram

-    Meningkatkan derajad konsistensi antara tahap analisis, perancangan, serta kegiatan pemrograman karena menggunakan model yang sama untuk setiap tahap

-    Ketangguhan sistem (robustness)

-    Kemampuan untuk menggunakan ulang hasil analisis, perancangan, serta pemrograman (reusable component) pada suatu proyek ke proyek lainnya.

Untuk mengembangkan model perancangan, kita harus mengidentifikasi dan menyelidiki konsekuensi pada lingkungan implementasi akibat langkah-langkah perancangan. Semua keputusan strategis, misalnya penanganan kesalahan dan pustaka komponen yang akan dipakai berulang-ulang harus dibuat. Selanjutnya kita menggunakan keputusan itu untuk beradaptasi dengan lingkungan implementasi. Langkah terakhir adalah membuat formalisasi model perancangan untuk mendeskripsikan bagaimana objek-objek berinteraksi satu sama lain lewat suatu skenario (use case) yang telah dikembangkan sebelumnya.

Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean (coding). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik. Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security, dan sebagainya. Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode pemodelan (notation), proses (process) dan tool yang digunakan.

UML (Unified Modelling Language) adalah bahasa pemodelan standar pada rekayasa perangkat lunak. Dengan menggunakan UML akan berdampak pada peningkatan produktifitas dan dan kualitas serta pengurangan biaya dan waktu. Kerumitan arsitektur dalam pengembangan perangkat lunak bisa diatasi dengan menggambarkan cetak biru sistem tersebut. Di sinilah UML bisa banyak berperan.

C.   Task dan Multithreading Java

Dengan  seiring  berjalannya  waktu dan  tuntutan  teknologi  ternyata  ditemukan  kelemahan  yang  sebenarnya  bisa  diminimalisir  pada proses.  Untuk  itulah  diciptakan  thread  yang  merupakan  cara  dari  komputer  untuk  menjalankan dua  atau  lebih  task  dalam  waktu  bersamaan,  sedangkan  multithreading  adalah  cara  komputer untuk  membagi-bagi  pekerjaan  yang  dikerjakan  sebagian-sebagian  dengan  cepat  sehingga menimbulkan  efek  seperti  menjalankan  beberapa  task  secara  bersamaan  walaupun  otaknya hanya  satu.  Di  sini  kita  akan  belajar  mengapa  harus  ada  thread,  perbedaan  thread  dengan proses,  keuntungan  dan  kerugian  pengimplementasian  thread,  model-model  multithreading, pengimplementasian  pustaka  thread,  pembatalan  thread,  thread  pools,  penjadwalan  thread dan thread di Linux.

a.    Keuntungan dan Kerugian MultiThreading

Multiprocessing  merupakan  penggunaan  dua  atau  lebih  CPU  dalam  sebuah  sistem  komputer. Multitasking  merupakan  metode  untuk  menjalankan  lebih  dari  satu  proses  dimana  terjadi pembagian  sumberdaya  seperti  CPU.  Multithreading  adalah  cara pengeksekusian  yang mengizinkan  beberapa  thread  terjadi  dalam  sebuah  proses,  saling  berbagi  sumber  daya  tetapi dapat dijalankan secara independen.

Keuntungan  dari  sistem  yang  menerapkan  multithreading  dapat  kita  kategorikan  menjadi  4 bagian:

-    Responsif. Aplikasi interaktif menjadi tetap responsif meskipun sebagian dari program sedang diblok atau melakukan operasi lain yang panjang. Umpamanya, sebuah thread dari web browser dapat  melayani  permintaan  pengguna  sementara  thread  yang  lain  berusaha  menampilkan gambar.

-    Berbagi  sumber  daya.  Beberapa  thread  yang  melakukan  proses  yang  sama  akan  berbagi sumber  daya.  Keuntungannya  adalah  mengizinkan  sebuah  aplikasi  untuk mempunyai  beberapa thread yang berbeda dalam lokasi memori yang sama.

-    Ekonomis. Pembuatan sebuah proses memerlukan pengalokasian memori dan sumber daya. Alternatifnya adalah dengan menggunakan thread, karena thread membagi memori dan sumber daya  yang  dimilikinya  sehingga  lebih  ekonomis  untuk  membuat  thread  dan  context  switching thread.  Akan  susah  mengukur  perbedaan  waktu  antara  thread  dan  switch,  tetapi  secara  umum pembuatan  dan  pengaturan  proses  akan  memakan  waktu  lebih  lama  dibandingkan  dengan thread.  Pada  Solaris,  pembuatan  proses  memakan  waktu  30  kali  lebih  lama  dibandingkan pembuatan  thread  sedangkan  proses  context  switch  5  kali  lebih  lama  dibandingkan  context switching thread.

-    Utilisasi  arsitektur  multiprosesor.  Keuntungan  dari  multithreading  dapat  sangat  meningkat pada  arsitektur  multiprosesor,  dimana  setiap  thread  dapat  berjalan  secara  paralel  di  atas procesor  yang  berbeda.  Pada  arsitektur  processor  tunggal,  CPU  menjalankan  setiap  thread secara  bergantian  tetapi  hal  ini  berlangsung  sangat  cepat  sehingga  menciptakan  ilusi  paralel, tetapi pada kenyataannya hanya satu thread yang dijalankan CPU pada satu-satuan waktu. 

Adapun kerugian dari multithreading adalah :

-    Jika  digunakan  secara  berlebihan,  multithreading  akan  berdampak  pada  pemborosan resource  dan  CPU  yang  dialokasikan  untuk  switching  threads.  Misalnya  jika  heavy  disk  I/O terlibat,  akan  lebih  cepat  jika  hanya  memiliki  1  atau  2  thread  yang  melaksanakan  tugas  secara berurutan,  daripada  menggunakan  multithread  yang  masing-masing mengeksekusi  sebuah  task pada waktu yang sama.

-    Sistem yang memiliki kecepatan prosesor dan memory yang cenderung sama, sehingga tidak ada  efisiensi  yang  hilang  (mengacu  kepada  latency),  tidak  akan  memperoleh  peningkatan bandwidth yang signifikan jika menggunakan multithreading. 

-    Multithreading  menghasilkan  program  yang  lebih  kompleks.  Menggunakan  multiple thread sendiri  tidak  akan  menciptakan  kerumitan,  tapi  interaksi  antar  thread-lah  yang  mengakibatkan kompleksitas tersebut.

-    Thread  yang  banyak  bisa  saling  berinterferensi  ketika  saling  berbagi  sumber  daya  hardware seperti cache.

b.    Model MultiThreading

Beberapa terminologi yang akan dibahas:

1.    Thread pengguna: Thread yang pengaturannya dilakukan oleh pustaka thread pada tingkatan pengguna.  Karena  pustaka  yang  menyediakan  fasilitas  untuk  pembuatan  dan  penjadwalan thread, thread pengguna cepat dibuat dan dikendalikan.

2.    Thread Kernel: . Thread  yang  didukung langsung oleh kernel.  Pembuatan,  penjadwalan  dan manajemen  thread  dilakukan  oleh  kernel  pada  kernel  space.  Karena  dilakukan  oleh  sistem operasi, proses pembuatannya akan lebih lambat jika dibandingkan dengan thread pengguna.

c.    Model-Model MultiThreading:

1.    Model  Many-to-One.  Model  ini  memetakan  beberapa  thread  tingkatan  pengguna  ke  sebuah thread.  tingkatan  kernel.  Pengaturan  thread  dilakukan  dalam  ruang  pengguna  sehingga  efisien. Hanya satu thread pengguna yang dapat mengakses thread kernel pada satu saat. Jadi Multiple thread tidak dapat berjalan secara paralel pada multiprosesor. Kekurangannya adalah ketika ada satu blocking systemc call, semua akan menjadi terblok juga. Contoh: Solaris Green Threads dan GNU Portable Threads.

2.    Model One-to-One. Model ini memetakan setiap thread tingkatan pengguna ke setiap thread. Ia  menyediakan  lebih  banyak  concurrency  dibandingkan  model  Many-to-One.  Keuntungannya sama  dengan  keuntungan  thread  kernel.  Kelemahan  model  ini  ialah  setiap  pembuatan  thread pengguna memerlukan tambahan thread kernel. Karena itu, jika mengimplementasikan sistem ini maka  akan  menurunkan  kinerja  dari  sebuah  aplikasi  sehingga  biasanya  jumlah  thread  dibatasi dalam sistem. Contoh: Windows NT/XP/2000 , Linux, Solaris 9, OS/2.

3.    Model  Many-to-Many.  Model  ini  memultipleks  banyak  thread  tingkatan  pengguna  ke  thread kernel  yang  jumlahnya  sedikit  atau  sama  dengan  tingkatan  pengguna.  Model  ini  mengizinkan developer  membuat  thread  sebanyak  yang  ia  mau  tetapi  concurrency  tidak  dapat  diperoleh karena  hanya  satu  thread  yang  dapat  dijadwalkan  oleh  kernel  pada  suatu  waktu.  Keuntungan dari  sistem  ini  ialah  kernel  thread  yang  bersangkutan  dapat  berjalan  secara  paralel  pada multiprosessor dan lebih efisien. Contoh : Solaris 2, IRIX, HPUX.

Model-Model MultiThreading

d.    Pustaka Thread

Pustaka  Thread  atau  yang  lebih  familiar  dikenal  dengan  Thread  Library  bertugas  untuk menyediakan  API  untuk  programmer  dalam  menciptakan  dan  memanage  thread.  Ada  dua  cara dalam mengimplementasikan pustaka thread:

1.    Menyediakan  API  dalam  level  pengguna  tanpa  dukungan  dari  kernel  sehingga  pemanggilan fungsi  tidak  melalui  system  call.  Jadi,  jika  kita  memanggil  fungsi  yang  sudah  ada  di  pustaka, maka akan menghasilkan pemanggilan fungsi call yang sifatnya lokal dan bukan system call. 

2.    Menyediakan API di level kernel yang didukung secara langsung oleh sistem operasi. Pemanggilan fungsi call akan melibatkan system call ke kernel. Ada tiga pustaka thread yang sering digunakan saat ini, yaitu: POSIX Pthreads, Java, dan Win32. Implementasi POSIX standard dapat dengan cara user level dan kernel level, sedangkan Win32 adalah kernel level. Java API thread dapat diimplementasikan oleh Pthreads atau Win32.

e.     Pembatalan Thread

Thread  Cancellation  ialah  pembatalan  thread  sebelum  tugasnya  selesai.  Misalnya  hendak  mematikan  Java  Virtual  Machine  (JVM)  pada  program  Java.  Maka  sebelum  JVM  dimatikan seluruh thread yang berjalan harus dibatalkan terlebih dahulu. Contoh lain adalah pada masalah search.  Apabila  sebuah  thread  mencari  sesuatu  dalam  database  dan  menemukan  serta mengembalikan hasilnya, thread sisanya akan dibatalkan. Thread yang akan diberhentikan biasa disebut target thread. 

Pemberhentian target Thread dapat dilakukan dengan 2 cara:

a. Asynchronous cancellation. Suatu thread seketika itu juga membatalkan target thread.

b. Deferred  cancellation.  Suatu  thread  secara  periodik memeriksa  apakah  ia  harus  batal,  cara ini memperbolehkan target thread untuk membatalkan dirinya secara terurut.

Hal yang sulit dari pembatalan thread ini adalah ketika terjadi situasi dimana sumber daya sudah dialokasikan  untuk  thread  yang  akan  dibatalkan.  Selain  itu  kesulitan  lain  adalah  ketika  thread yang dibatalkan sedang meng-update data yang ia bagi dengan thread lain. Hal ini akan menjadi masalah  yang  sulit  apabila  digunakan  asynchronous  cancellation.  Sistem  operasi  akan mengambil  kembali  sumber  daya  dari  thread  yang  dibatalkan  tetapi  seringkali  sistem  operasi tidak mengambil kembali semua sumber daya dari thread yang dibatalkan. 

Alternatifnya  adalah  dengan  menggunakan  deffered  cancellation.  Cara  kerja  dari  deffered cancellation  adalah  dengan  menggunakan  satu  thread  yang  berfungsi  sebagai  pengindikasi bahwa target thread hendak dibatalkan. Tetapi pembatalan hanya akan terjadi jika target thread memeriksa  apakah  ia  harus  batal  atau  tidak.  Hal  ini  memperbolehkan  thread  untuk  memeriksa apakah ia harus batal pada waktu dimana ia dapat dibatalkan secara aman yang aman. Pthread merujuk sebagai cancellation points.

Pada  umumnya  sistem  operasi  memperbolehkan  proses  atau  thread  untuk  dibatalkan  secara asynchronous.  Tetapi  Pthread  API  menyediakan  deferred  cancellation.  Hal  ini  berarti  sistem operasi yang mengimplementasikan Pthread API akan mengizinkan deferred cancellation.

f.     Thread Pools

Pada web server yang menerapkan multithreading ada dua masalah yang timbul:

-   Ukuran  waktu  yang  diperlukan  untuk  menciptakan  thread  yang  melayani  permintaan  yang diajukan pada kenyataannya thread dibuang seketika sesudah ia menyelesaikan tugasnya.

-   Pembuatan thread yang tidak terbatas jumlahnya dapat menurunkan performa dari sistem.

Solusinya  adalah  dengan  penggunaan  Thread  Pools,  yaitu  sekumpulan  thread  yang  mengantri untuk mengerjakan tugas  Cara kerjanya adalah dengan membuat beberapa thread pada proses  startup  dan  menempatkan  mereka  ke  pools,  dimana  mereka  duduk  diam  dan  menunggu  untuk bekerja. Jadi, ketika server menerima permintaan, ia akan membangunkan thread dari pool dan jika thread tersedia maka permintaan tersebut akan dilayani. Ketika  thread  sudah  selesai  mengerjakan  tugasnya  maka  ia  kembali  ke  pool  dan  menunggu pekerjaan  lainnya.  Bila  tidak  ada  thread  yang  tersedia  pada  saat  dibutuhkan  maka  server menunggu sampai ada satu thread yang bebas. 

Keuntungan thread pool adalah:

-  Biasanya  lebih  cepat  untuk  melayani  permintaan  dengan  thread  yang  ada  dibandingkan menunggu thread baru dibuat.

-  Thread pool membatasi jumlah thread yang ada pada suatu waktu. Hal ini penting pada sistem yang  tidak  dapat  mendukung  banyak  thread  yang  berjalan  secara  concurrent.  Jumlah  thread dalam  pool  dapat  tergantung  dari  jumlah  CPU  dalam  sistem,  jumlah  memori  fisik,  dan  jumlah permintaan klien yang concurrent.

-   Pembuatan  jumlah  thread  yang  tepat  dapat  meningkatkan  performa  serta  sistem  yang  lebih stabil

g.    Penjadwalan Thread

Begitu  dibuat,  thread  baru  dapat  dijalankan  dengan  berbagai  macam  penjadwalan.  Kebijakan penjadwalanlah  yang  menentukan  setiap  proses,  di  mana  proses  tersebut  akan  ditaruh  dalam daftar proses sesuai proritasnya dan bagaimana ia bergerak dalam daftar proses tersebut.

Untuk  menjadwalkan  thread,  sistem  dengan  model  multithreading  many  to  many  atau  many  to one menggunakan:

-   Process  Contention  Scope  (PCS).  Pustaka  thread  menjadwalkan  thread  pengguna  untuk berjalan pada LWP (lightweight process) yang tersedia.

-   System  Contention  Scope  (SCS).  SCS  berfungsi  untuk  memilih  satu  dari  banyak  thread, kemudian menjadwalkannya ke satu thread tertentu (CPU / Kernel).

Penjadwalan Thread