tugas client server jdbc

JDBC

Apa itu JDBC?

JDBC (Java database connectivity) adalah spesifikasi standar dari JavaSoft  API (Aplication Programming Interface) yang memungkinkan program Java untuk mengakses sistem database manajemen. JDBC API terdiri dari satu set interface dan kelas yang ditulis dalam bahasa pemrograman Java. JDBC API Menggunakan interface standar dan kelas, programmer dapat menulis aplikasi yang terhubung ke database, mengirimkan pertanyaan ditulis SQL (Structured Query Language), dan memproses hasilnya.

JDBC API ini konsisten dengan gaya inti interface Java dan kelas, seperti java.lang dan java.awt. Tabel berikut ini menjelaskan antarmuka, kelas, dan pengecualian (kelas dilempar sebagai pengecualian) yang membentuk API JDBC. Pada tabel, interface milik paket javax.sql adalah ekstensi untuk antarmuka JDBC standar dan yang terkandung dalam Java 2 SDK, Enterprise Edition.

Interface/class/exception	Deskripsi
Interfaces:
java.sql.Connection	Interface yang digunakan untuk membuat koneksi ke database. pernyataan SQL dijalankan dalam konteks koneksi.
java.sql.DatabaseMetaData	Interface yang digunakan untuk mengembalikan informasi tentang database.
java.sql.Driver	Interface yang digunakan untuk menemukan driver untuk sistem manajemen database tertentu.
java.sql.PreparedStatement	Interface  yang digunakan untuk mengirim kompilasi pernyataan SQL ke server database dan memperoleh hasilnya.
java.sql.ResultSet	Interface  yang digunakan untuk memproses dan mengembalikan hasil  dari  pernyataan SQL yang di jalankan.
java.sql.ResultSetMetaData	Interface yang digunakan untuk mengembalikan kolom dalam sebuah Object ResultSet.
java.sql.Statement	Interface  digunakan untuk mengirim laporan statis SQL ke server database dan memperoleh hasilnya.
javax.sql.ConnectionEventListener	Menerima event atau kejadian bahwa obyek PooledConnection digeneralisasi.
javax.sql.ConnectionPoolDataSource	Pabrik untuk suatu PooledConnection. Sebuah objek ConnectionPoolDataSource biasanya terdaftar dengan layanan JNDI.
javax.sql.DataSource	Sebuah pabrik untuk objek Connection. Sebuah objek DataSource biasanya terdaftar dengan penyedia layanan JNDI.
javax.sql.PooledConnection	PooledConnection mewakili koneksi fisik ke sumber data.
Classes:
java.sql.Date	Subclass dari java.util.Date digunakan untuk tipe data SQL DATE.
java.lang.DriverManager	Class yang digunakan untuk mengelola satu set JDBC drivers.
java.sql.DriverPropertyInfo	Class yang digunakan untuk menutupi dan memasok properti untuk koneksi
java.sql.Time	Subclass dari java.util.Date digunakan untuk tipedata SQL TIME.
java.sql.TimeStamp	Subclass dari java.util.Date digunakan untuk tipedata SQL TIMESTAMP.
java.sql.Types	Class yang digunakan untuk mendefinisikan konstanta yang digunakan untuk mengidentifikasi tipe data standart  SQL seperti CHAR, INTEGER dan DECIMAL.
java.sql.String	Class yang digunakan untuk mengidentifikasi jenis data teks seperti CHAR.
Exception classes:
java.sql.SQLException	Eksepsi yang menyediakan informasi tentang Database error

               

                               

                .

               

               

                               

               

Karena JDBC adalah spesifikasi standar, sebuah program Java yang menggunakan API JDBC dapat terhubung ke sistem manajemen database (DBMS) yang ada driver JDBC-nya.

Apakah driver JDBC?

JDBC API mendefinisikan interface Java dan kelas yang programmer gunakan untuk menghubungkan ke database dan mengirim pertanyaan. Driver JDBC mengimplementasikan interface ini dan kelas untuk vendor DBMS tertentu.

Sebuah program Java yang menggunakan API JDBC driver beban yang ditetapkan untuk sebuah DBMS tertentu sebelum benar-benar terhubung ke database. Kelas JDBC DriverManager kemudian mengirimkan semua panggilan ke API JDBC driver dimuat.

Empat jenis driver JDBC adalah:

• JDBC-ODBC bridge plus driver ODBC, juga disebut Tipe 1.

Menerjemahkan JDBC API panggilan menjadi Microsoft Open Database Connectivity (ODBC) panggilan yang kemudian diteruskan ke driver ODBC. Kode ODBC biner harus dimuat pada setiap komputer klien yang menggunakan jenis driver.

• Native-API, sebagian Java driver, juga disebut Tipe 2.

Mengubah JDBC API API panggilan menjadi klien DBMS khusus panggilan. Seperti driver jembatan, jenis driver mensyaratkan bahwa beberapa kode biner akan dimuat pada setiap komputer klien.

• JDBC-Net, Java driver murni, juga disebut Tipe 3.

JDBC API Mengirim panggilan ke server  tingkat menengah yang menerjemahkan panggilan tersebut dalam protokol jaringan DBMS spesifik. Panggilan yang telah diterjemahkan tersebut kemudian dikirim ke sebuah DBMS tertentu.

• Native-protokol, Java Driver murni, juga disebut Tipe 4.

Mengubah JDBC API melalui panggilan langsung ke protokol jaringan DBMS-spesifik tanpa tingkat tengah. Hal ini memungkinkan aplikasi client untuk terhubung langsung ke server database.

The Red Brick Driver JDBC adalah Java murni Tipe-4 driver berdasarkan Versi 2.0 dari API JDBC.

tugas client server sekilas tentang corba

Common Object Request Broker Architecture (CORBA) adalah teknologi yang dipergunakan untuk heterogeneous computing (sistem komputer dengan berbagai macam
lingkungan). CORBA pada dasarnya menggunakan arsitektur client-server dimana klien dan server berupa objek. CORBA mendukung apa yang disebut interoperabilitas, yaitu kemampuan saling bekerjasama antar sistem computer.

CORBA berbeda dengan RMI, berikut perbedaan CORBA dengan RMI:

1. CORBA adalah dapat diimplementasikan dengan sembarang bahasa pemrograman.
2. CORBA terdiri dari beberapa mekanisme dimana RMI dapat termasuk di dalamnya.
3. Pada RMI tidak menggunakan ORB (Object Request Broker).

Kenapa ada CORBA?

• Dapat menangani keberagaman lingkungan antara klien dan server (dapat diimplementasikan pada bahasa pemrograman yang berbeda). Hal ini karena CORBA menggunakan apa yang disebut antarmuka (interface) untuk menjembatani dua buah lingkungan yang berbeda.

Object Request Broker (ORB) merupakan inti dari CORBA dan bertanggung jawab untuk menjalankan semua mekanisme yang dibutuhkan, yaitu:

1. Menemukan implementasi objek untuk memenuhi suatu request
2. Menyiapkan implementasi objek untuk menerima suatu request
3. Melakukan komunkasi data untuk memenuhi suatu request

Sebuah permintaan (request) yang dikirimkan suatu client ke suatu object implementation akan melewati ORB. Dengan ORB, yang terdiri dari interface, suatu client dapat berkomunikasi dengan object implementation tanpa adanya batasan platform, teknologi jaringan, bahasa pemrograman, dan letak objek. Dengan menggunakan ORB, objek client bisa meminta sebuah method pada sebuah object server yang bisa saja terdapat dalam satu mesin maupun jaringan yang berbeda. ORB menerima panggilan dan menemukan objek yang bisa mengimplementasikan permintaan, mengirim parameter, invoke method, dan mengembalikan hasil yang diperoleh.

Objek-objek CORBA dispesifikasikan menggunakan interface, yang merupakan penghubung anatara client dan server. Interface Definition Language (IDL) digunakan untuk mendefinisikan interface tersebut. IDL menentukan tipe-tipe suatu objek dengan mendefinisikan interface-interface objek tersebut. Sebuah interface terdiri dari kumpulan operasi dan parameter operasi tersebut. IDL hanya mendeskripsikan interface, tidak mengimplementasikannya. Meskipun sintaks yang dimiliki oleh IDL menyerupai sintaks bahasa pemrograman C++ dan Java., perlu diingat, IDL bukan bahasa pemrograman.

CORBA mendefinisikan IIOP (Internet Inter-ORB Protocol) untuk mengatur bagaimana objek berkomunikasi melalui jaringan. IIOP merupakan open protocol yang berjalan diatas TCP/IP.

Pada Java, CORBA merupakan pelengkap untuk menyediakan framework distribusi objek, services pendukung framework itu, dan kemampuan antar operasi dengan bahasa pemrograman lainnya. CORBA untuk client-server menggunakan protokol IIOP (Internet InterORB Protocol) untuk komunikasi antara server dan klien.

Arsitektur CORBA adalah sebagai berikut:

Skeletons adalah bagian kode yang dibangin pada kode implementasi server pada antarmuka (interface). Stub adalah bagian kode yang membuat antarmuka (interface) dapat diakse (available) oleh klien.

Java menyediakan ORB (Object Request Broker) yang mendukung teknologi CORBA. ORB adalah komponen runtime yang dapat digunakan untuk distributed computing menggunakan komunikasi IIOP. OMG (Object Management Group) adalah industri yang membuat spesifikasi dan mempublikasikan CORBA.

Java IDL (Interface Definition Langauge) merupakan sebuah teknologi untuk distribusi
objek yang berinteraksi antar platform. CORBA menggunakan IDL untuk membuat antarmuka (interface). Java IDL adalah implementasi dari teknologi antarmuka pada CORBA. Model pemrograman IDL atau biasa disebut Java IDL terdiri dari ORB CORBA dan kompiler idlj yang memetakan OMG IDL ke Java dengan menggunakan Java CORBA ORB. Aplikasi CORBA dibuat dengan menggunakan IDL untuk mendefinisikan antarmuka objek agar dapat diakses oleh klien maupun server.

tugas client server pembahasan probilitas

Sebelum Anda melakukan trading yang sebenarnya, ada baiknya bila kita membahas masalah probabilitas secara lebih mendalam sekali lagi guna memaksimalkan teknik Anda di dalam melakukan trading.

Pada bab sebelumnya telah diberikan illustrasi kasus mengenai probabilitas dengan pelemparan koin secara acak untuk mendapatkan suatu data statistik tentang kemungkinan muka koin yang akan muncul di tangan kita. Apakah kita akan mendapatkan sisi koin yang bergambar atau sisi koin yang menunjukkan angka.

Pada pelemparan koin, kita hanya akan mendapatkan 2 kemungkinan atas apa yang kita lakukan terhadap koin tersebut, yaitu gambar atau angka.

Di dalam pendekatan statistik, probabilitas yang akan kita dapatkan adalah sama. Bila Anda melempar koin tersebut, Anda dapat mencatat berapa kali muncul gambar dan berapa kali muncul angka. Dari catatan yang Anda dapatkan mungkin Anda akan merasa bahwa eksperimen yang Anda lakukan merupakan suatu bentuk perjudian sederhana. Namun demikian apa yang Anda lakukan tersebut merupakan suatu eksperimen yang baik tentang probabilitas.

Jika Anda melakukan eksperimen pelemparan koin, misalkan saja, sebanyak 10 kali, maka berikut adalah kemungkinan data berapa kali sisi gambar akan muncul dan berapa kali sisi angka akan muncul:

Gambar	Angka
10	0
9	1
8	2
7	3
6	4
5	5
4	6
3	7
2	8
1	9
0	10

Dari tabel di atas, menurut Anda. manakah sisi koin yang paling berpeluang muncul dari pelemparan koin sebanyak 10 kali? Sekarang coba Anda amati tibel di atas. Di situ nampak bahwa kita akan mendapatkan suatu kombinasi probabilitas yang sama antara peluang munculnya sisi gambar dan sisi angka.

Jika Anda ingin menguji sekali lagi apa yang telah Anda lakukan dengan meminta tolong orang lain untuk melakukan hal yang sama seperti yang Anda lakukan, cobalah Anda bandingkan antara data yang Anda dapatkan dengan data yang didapatkan orang tersebut. Apakah Anda mendapatkan hasii yang sama?

Pertanyaan di atas adalah harus Anda kemukakan ketika Anda ingin mempelajari lebih lanjut tentang probabilitas. Kita akan membahas bersama untuk mengkaji lebih lanjut tentang probabilitas ini.

Ketika Anda melakukan pelemparan koin tersebut sebanyak 1 kali, atau sebanyak 10 kali, maka jawaban yang akan kita dapatkan tentang probabilitas adalah sama, karena masing-masing sisi koin memiliki peluang yang sama, untuk muncul. Dengan kondisi ini kita telah mendapatkan suatu prediksi tentang probabilitas sisi koin mana yang akan muncul. Jika misalnya koin tersebut cacat sehingga pada saat kita lemparkan ternyata sisi tertentu dari koin menjadi lebih sering muncul maka kita akan kesulitan untuk melakukan prediksi. Sekilas hal ini tampak aneh dan kontradiktif, karena dengan adanya cacat pada koin maka kita harus mempelajari perilaku atau karakter dari koin yang cacat itu. Jika kita melemparkan koin cacat tersebut sebanyak 1000 kali, misalnya, maka bisa jadi kita akan mendapatkan sisi gambar muncul sebanyak 700 kali dibanding sisi angka sebanyak 300 kali. Jika hal itu yang terjadi maka biasanya kita akan segera berkesimpulan bahwa kita dengan mudah dapat memprediksikan hasil pelemparan koin cacat tersebut, meskipun kenyataan tidaklah demikian. Sekali lagi kita harus mengerti dan memahami karakter dari koin cacat tersebut sebelum kita melakukan prediksi dan itu tidak semudah jika kita melakukannya terhadap koin yang tidak cacat.

Dari uji coba pelemparan koin di atas kita mencatat bahwa hasil dari setiap pelemparan koin merupakan suatu peristiwa independen. Tidak ada faktor apapun yang mempengaruihi hasil dari uji pelemparan koin. Berapa kalipun Anda melakukan uji pelemparan, angka probabilitas sisi koin mana yang akan muncul adalah sama. Koin tersebut tidak akan “mengingat” hasil akhir pelemparan sebelumnya. Juga tidak bisa ditentukan sisi mana yang akan muncul pada pelemparan berikutnya. Ini adalah suatu peristiwa yang benar-benar independen.

Akan lain halnya jika kita mengambil suatu contoh kasus lain tentang peristiwa uji coba yang bersifat tidak independen. Katakanlah kita melakukan uji coba terhadap 20 biji kelereng, 19 kelereng berwarna hijau dan hanya 1 yang berwarna merah, dengan ukuran dan berat yang benar-benar sempurna sama. Ketika kita memasukkan semua kelereng tersebut ke dalam sebuah toples lalu kita mencoba mengambil kelereng berwarna merah dengan mata tertutup, berapakah probabilitas keberhasilan kita untuk mendapatkan kelereng merah tersebut? Ketika Anda mulai mengambil kelereng merah tersebut, angka probabilitas yang kita hadapi adalah 1 banding 20. Pada pengambilan pertama bisa jadi kita akan gagal dan kemudian kita mencoba lagi. Kali ini dengan perbandingan 1 banding 19 kerena jumlah kelereng sudah berkurang satu.

Jika kita terus mencoba untuk mengambil kelerengmerah dengan cara yang sama, dan ketika Anda berhasil mengambil kelereng merah sementara yang masih tersisa hanya beberapa biji kelereng hijau, maka permainan telah berakhir. Namun jika Anda gagal dan Anda tidak mengganti kelereng hijau yang terambil dengan kelereng berwama merah maka probabilitasnya adalah sama. Kecuali jika Anda melanjutkan pengambilan kelereng tersebut hingga jumlah kelereng di dalam toples tersebut terus berkurang hingga akhimya menyisakan satu kelereng saja. Dalam hal demikian bukanlah probabilitas lagi yang berlaku, namun sebuah kepastian.

Contoh kasus ini, jika kita bandingkan dengan uji pelemparan koin, sangatlah berbeda kondisinya. Uji pelemparan koin adalah suatu bentuk uji coba yang bersifat independen event dan tidak didasarkan atas suatu kepastian. Dari pembahasan ini saya berharap Anda sudah mendapatkan gambaran yang jelas tentang probabilitas.

tugas client server Multi Threading dan Multiplexing

Multi Threading dan Multiplexing

Dalam ilmu komputer , sebuah thread eksekusi adalah urutan terkecil instruksi diprogram yang dapat dikelola secara independen oleh sistem operasi scheduler . Sebuah thread adalah proses ringan . Pelaksanaan benang dan proses berbeda dari satu sistem operasi yang lain, tetapi dalam banyak kasus, thread yang terkandung di dalam proses. Beberapa benang bisa ada dalam proses yang sama dan berbagi sumber daya seperti memori , sedangkan berbeda proses tidak berbagi sumber daya tersebut. Secara khusus, benang-benang proses berbagi petunjuk yang terakhir (kode) dan konteksnya (nilai-nilai yang variabel yang referensi pada saat tertentu).
Pada prosesor tunggal, multithreading umumnya terjadi oleh time-division multiplexing (seperti dalam multitasking ): dengan prosesor switch antara benang yang berbeda. Ini switching konteks umumnya terjadi cukup sering bahwa pengguna merasakan benang atau tugas sebagai berjalan pada waktu yang sama. Pada multiprosesor atau multi-core sistem, benang dapat benar-benar bersamaan, dengan setiap prosesor atau inti mengeksekusi thread terpisah secara bersamaan.
Banyak sistem operasi modern langsung mendukung baik waktu-iris dan multiprosesor threading dengan scheduler proses. The kernel dari sistem operasi memungkinkan programmer untuk memanipulasi benang melalui system call interface. Beberapa implementasi yang disebut kernel thread, sedangkan proses ringan (LWP) adalah jenis spesifik kernel thread yang berbagi negara dan informasi yang sama.
Program dapat memiliki benang user-space ketika threading dengan timer, sinyal, atau metode lain untuk menghentikan eksekusi mereka sendiri, melakukan semacam ad-hoc waktu mengiris .




Thread berbeda dari tradisional multitasking proses sistem operasi dalam hal:
proses biasanya independen, sedangkan benang ada sebagai subset dari sebuah proses
proses membawa jauh lebih negara informasi dari benang, sedangkan beberapa thread dalam proses berbagi proses negara serta memori dan lainnya sumber daya
proses memiliki terpisah ruang alamat , sedangkan benang berbagi ruang alamat mereka
proses berinteraksi hanya melalui disediakan sistem komunikasi antar-proses mekanisme
konteks beralih antara benang dalam proses yang sama biasanya lebih cepat daripada konteks beralih antara proses.


Multithreading

Multi-threading adalah pemrograman meluas dan eksekusi model yang memungkinkan beberapa thread untuk tetap eksis dalam konteks sebuah proses tunggal. Benang ini berbagi sumber daya proses, tetapi mampu melakukan secara mandiri. Model threaded menyediakan pengembang dengan abstraksi yang berguna eksekusi konkuren. Namun, mungkin aplikasi yang paling menarik dari teknologi ini bila diterapkan pada proses tunggal untuk memungkinkan eksekusi paralel pada sistem multiprocessing.
Ini keuntungan dari program multithreaded memungkinkan untuk beroperasi lebih cepat pada sistem komputer yang memiliki beberapa CPU , CPU dengan beberapa core, atau melintasi sekelompok mesin - karena benang dari program alami meminjamkan diri untuk benar-benar bersamaan eksekusi . Dalam kasus seperti itu, programmer perlu berhati-hati untuk menghindari kondisi ras , dan perilaku non-intuitif lainnya. Agar data yang akan dimanipulasi dengan benar, benang akan sering perlu untuk pertemuan dalam waktu untuk memproses data dalam urutan yang benar. Thread mungkin juga memerlukan saling eksklusif operasi (sering diimplementasikan menggunakan Semaphore ) untuk mencegah data umum dari yang bersamaan dimodifikasi, atau membaca sementara dalam proses modifikasi. Penggunaan ceroboh primitif tersebut dapat menyebabkan deadlock .
Penggunaan lain multithreading, berlaku bahkan untuk sistem single-CPU, adalah kemampuan untuk sebuah aplikasi untuk tetap responsif terhadap masukan. Dalam program single-threaded, jika blok utama benang eksekusi pada tugas lama berjalan, seluruh aplikasi dapat muncul untuk membekukan. Dengan memindahkan tugas berjalan lama tersebut kepada pekerja thread yang berjalan bersamaan dengan eksekusi thread utama, adalah mungkin untuk aplikasi tetap responsif terhadap input pengguna ketika menjalankan tugas di latar belakang. Di sisi lain, dalam banyak kasus multithreading bukan satu-satunya cara untuk menjaga program responsif, dengan non-blocking I / O dan / atau sinyal Unix yang tersedia untuk mendapatkan hasil yang sama. [1]
Sistem operasi menjadwalkan thread di salah satu dari dua cara:
Preemptive multitasking umumnya dianggap pendekatan unggul, karena memungkinkan sistem operasi untuk menentukan kapan beralih konteks harus terjadi. Kerugian untuk multithreading preemptive adalah bahwa sistem dapat membuat context switch pada waktu yang tepat, menyebabkan kunci konvoi , prioritas inversi atau efek negatif lainnya yang dapat dihindari dengan multithreading koperasi.
Multithreading Koperasi, di sisi lain, bergantung pada benang sendiri untuk melepaskan kontrol setelah mereka berada pada titik berhenti. Hal ini dapat menciptakan masalah jika thread sedang menunggu sumber daya untuk menjadi tersedia.
Sampai akhir 1990-an, CPU dalam komputer desktop tidak memiliki banyak dukungan untuk multithreading, meskipun benang masih digunakan pada komputer tersebut karena beralih antara benang itu umumnya masih lebih cepat daripada proses penuh konteks switch . Prosesor di embedded system , yang memiliki persyaratan yang lebih tinggi untuk real-time perilaku, mungkin mendukung multithreading dengan mengurangi waktu benang-switch, mungkin dengan mengalokasikan dedicated register file untuk setiap thread bukan menyimpan / mengembalikan register file umum. Pada akhir 1990-an, ide melaksanakan instruksi dari beberapa thread secara simultan, yang dikenal sebagai multithreading simultan , telah mencapai desktop dengan Intel 's Pentium 4 prosesor, di bawah nama hiper threading . Telah turun dari Intel Core dan Core 2 arsitektur, tetapi kemudian kembali instated di Core I3 , Core i5 dan i7 arsitektur.

Proses, kernel thread, thread pengguna, dan serat

Artikel utama: Proses (komputasi) dan Serat (ilmu komputer)
Sebuah proses adalah "terberat" unit penjadwalan kernel. Proses sudah memiliki sumber daya yang dialokasikan oleh sistem operasi. Sumber daya termasuk memori, menangani file , soket, perangkat menangani, dan jendela. Proses tidak berbagi ruang alamat atau file sumber daya kecuali melalui metode eksplisit seperti mewarisi menangani file atau segmen memori bersama, atau pemetaan file yang sama dengan cara berbagi. Proses biasanya preemptively multitasked.
Suatu kernel thread adalah "ringan" unit penjadwalan kernel. Setidaknya satu thread kernel ada dalam setiap proses. Jika beberapa thread kernel bisa ada dalam proses, maka mereka berbagi memori yang sama dan sumber daya berkas. Kernel thread yang preemptively multitasked jika sistem operasi proses scheduler adalah preemptive. Kernel thread tidak sumber daya sendiri kecuali tumpukan , salinan register termasuk program counter , dan penyimpanan thread-lokal (jika ada). Kernel dapat menetapkan satu thread untuk masing-masing inti logis dalam sistem (karena setiap prosesor membagi dirinya menjadi beberapa logical core jika mendukung multithreading, atau hanya mendukung satu inti logis per core fisik jika tidak mendukung multithreading), dan dapat menukar benang yang bisa diblokir. Namun, benang kernel memakan waktu lebih lama daripada benang pengguna untuk ditukarkan.
Thread kadang-kadang diimplementasikan dalam userspace perpustakaan, sehingga disebut benang pengguna. Kernel tidak menyadari dari mereka, sehingga mereka dikelola dan dijadwalkan di userspace . Beberapa basis implementasi thread pengguna mereka di atas beberapa thread kernel untuk mendapatkan keuntungan dari multi-prosesor mesin ( M: Model N ). Dalam artikel ini istilah "benang" (tanpa kernel atau petunjuk kualifikasi) defaultnya mengacu pada kernel thread. Benang pengguna seperti yang diterapkan oleh mesin virtual juga disebut benang hijau . Benang Pengguna umumnya cepat untuk membuat dan mengelola, tetapi tidak dapat memanfaatkan multithreading atau multiprocessing dan mendapatkan diblokir jika semua yang terkait thread kernel mereka mendapatkan diblokir bahkan jika ada beberapa thread pengguna yang siap dijalankan.
Serat adalah unit bahkan lebih ringan dari penjadwalan yang kooperatif dijadwalkan : serat berjalan secara eksplisit harus "menyerah" untuk memungkinkan serat lain untuk menjalankan, yang membuat pelaksanaannya jauh lebih mudah daripada kernel atau petunjuk benang. Sebuah serat dapat dijadwalkan untuk berjalan di thread apapun dalam proses yang sama. Hal ini memungkinkan aplikasi untuk mendapatkan peningkatan kinerja dengan mengelola penjadwalan sendiri, bukan mengandalkan pada scheduler kernel (yang mungkin tidak disetel untuk aplikasi). Lingkungan pemrograman paralel seperti OpenMP biasanya menerapkan tugas mereka melalui serat. Terkait erat dengan serat yang coroutines , dengan perbedaan adalah bahwa coroutines adalah membangun bahasa tingkat, sementara serat adalah sistem tingkat membangun.

Thread dan serat isu

Concurrency dan struktur data

Thread dalam proses yang sama berbagi ruang alamat yang sama. Hal ini memungkinkan bersamaan menjalankan kode untuk pasangan erat dan nyaman pertukaran data tanpa overhead atau kompleksitas dari IPC . Bila dibagi antara benang, bagaimanapun, struktur data sederhana bahkan menjadi rentan terhadap bahaya ras jika mereka membutuhkan lebih dari satu instruksi CPU untuk memperbarui: dua benang mungkin berakhir mencoba untuk memperbarui struktur data pada waktu yang sama dan merasa tiba-tiba berubah di bawah kaki. Bugs yang disebabkan oleh bahaya ras bisa sangat sulit untuk mereproduksi dan mengisolasi.
Untuk mencegah hal ini, threading API menawarkan sinkronisasi primitif seperti mutexes untuk mengunci struktur data terhadap akses konkuren. Pada sistem prosesor tunggal, benang berlari ke mutex terkunci harus tidur dan karenanya memicu context switch. Pada sistem multi-prosesor, benang mungkin bukan polling mutex dalam spinlock . Kedua mungkin kinerja getah dan kekuatan prosesor di SMP sistem untuk bersaing untuk bus memori, terutama jika granularity penguncian baik-baik saja.

I / O dan penjadwalan

Benang atau serat pengguna implementasi biasanya sepenuhnya dalam userspace . Akibatnya, konteks beralih antara benang pengguna atau serat dalam proses yang sama ini sangat efisien karena tidak memerlukan interaksi dengan kernel sama sekali: context switch dapat dilakukan dengan lokal menyimpan CPU register yang digunakan oleh thread pengguna yang sedang dijalankan atau serat dan kemudian memuat register yang dibutuhkan oleh thread pengguna atau serat akan dieksekusi. Sejak penjadwalan terjadi di userspace, kebijakan penjadwalan dapat lebih mudah disesuaikan dengan kebutuhan beban kerja program.
Namun, penggunaan sistem memblokir panggilan di thread user (sebagai lawan kernel thread) atau serat dapat menjadi masalah. Jika thread pengguna atau serat melakukan panggilan sistem yang blok, benang pengguna lain dan serat dalam proses tidak dapat berjalan sampai kembali system call. Sebuah contoh khas dari masalah ini adalah ketika melakukan I / O: sebagian besar program yang ditulis untuk melakukan I / O serempak. Ketika operasi I / O dimulai, panggilan sistem dibuat, dan tidak kembali sampai operasi I / O telah selesai. Pada periode intervensi, seluruh proses "diblokir" oleh kernel dan tidak dapat dijalankan, yang kelaparan thread pengguna lain dan serat dalam proses yang sama dari mengeksekusi.
Sebuah solusi umum untuk masalah ini adalah menyediakan I / O API yang mengimplementasikan antarmuka sinkron dengan menggunakan non-blocking I / O internal, dan penjadwalan lain benang pengguna atau serat sementara operasi I / O sedang berlangsung. Solusi serupa dapat disediakan untuk panggilan memblokir sistem lainnya. Atau, program dapat ditulis untuk menghindari penggunaan sinkron I / O atau panggilan memblokir sistem lainnya.
SunOS 4.x diimplementasikan " proses ringan "atau LWPs. NetBSD 2.x +, dan DragonFly BSD menerapkan LWPs sebagai thread kernel (Model 1:1). SunOS 5.2 melalui SunOS 5.8 serta NetBSD NetBSD 2 sampai 4 menerapkan model tingkat dua, multiplexing satu atau lebih benang level pengguna pada setiap thread kernel (M: Model N). SunOS 5.9 dan kemudian, serta NetBSD 5 dieliminasi pengguna dukungan benang, kembali ke model 1:1. [1] FreeBSD 5 diimplementasikan M: Model N. FreeBSD 6 mendukung kedua 1:1 dan M: N, pengguna bisa memilih mana yang harus digunakan dengan program yang diberikan dengan menggunakan / etc / libmap.conf. Dimulai dengan FreeBSD 7, 1:1 menjadi default. FreeBSD 8 tidak lagi mendukung M: Model N.
Penggunaan benang kernel menyederhanakan kode pengguna dengan memindahkan beberapa aspek yang paling kompleks threading ke dalam kernel. Program ini tidak perlu menjadwalkan benang atau eksplisit menghasilkan prosesor. Kode pengguna dapat ditulis dalam gaya prosedural akrab, termasuk panggilan untuk memblokir API, tanpa kelaparan benang lain. Namun, kernel threading mungkin memaksa konteks beralih antara benang setiap saat, dan dengan demikian mengekspos bahaya ras dan concurrency bug yang dinyatakan akan berbohong laten. Pada sistem SMP, ini lebih diperparah karena kernel thread dapat harfiah mengeksekusi secara bersamaan pada prosesor yang terpisah.




Model

01:01 (Kernel-level threading)
Thread yang dibuat oleh pengguna dalam korespondensi 1-1 dengan entitas schedulable di kernel. Ini adalah sederhana kemungkinan pelaksanaan threading. Win32 menggunakan pendekatan ini dari awal. Pada Linux , yang C library yang biasa menerapkan pendekatan ini (melalui NPTL atau lebih LinuxThreads ). Pendekatan yang sama digunakan oleh Solaris , NetBSD dan FreeBSD .
[ sunting ]N: 1 (User-level threading)
Sebuah N: 1 Model menyiratkan bahwa semua benang level aplikasi peta ke level kernel dijadwalkan entitas tunggal, kernel tidak memiliki pengetahuan tentang benang aplikasi. Dengan pendekatan ini, switching konteks dapat dilakukan dengan sangat cepat dan, di samping itu dapat diimplementasikan bahkan pada kernel sederhana yang tidak mendukung threading. Salah satu kelemahan utama bagaimanapun adalah bahwa ia tidak bisa mendapatkan keuntungan dari akselerasi hardware pada multi-threaded prosesor atau multi-prosesor komputer: tidak pernah lebih dari satu thread yang dijadwalkan pada waktu yang sama. Misalnya: Jika salah satu benang perlu mengeksekusi permintaan I / O, seluruh proses akan diblokir dan keuntungan threading tidak dapat dimanfaatkan. The GNU Portabel Thread menggunakan User-level threading, seperti halnya Thread Negara .

M: N (Hybrid threading)

M: N peta beberapa nomor M benang aplikasi ke beberapa nomor N entitas kernel, atau "prosesor virtual." Ini adalah kompromi antara kernel-level ("01:01") dan user-level ("N: 1") threading. Secara umum, "M: N" sistem threading lebih kompleks untuk diterapkan daripada baik kernel atau benang pengguna, karena perubahan baik kernel dan kode user-space yang diperlukan. Dalam M: N pelaksanaan, perpustakaan threading bertanggung jawab untuk penjadwalan thread pengguna pada entitas schedulable tersedia, ini membuat konteks switching benang yang sangat cepat, karena menghindari panggilan sistem. Namun, ini meningkatkan kompleksitas dan kemungkinan inversi prioritas , serta penjadwalan suboptimal tanpa ekstensif (dan mahal) koordinasi antara scheduler userland dan scheduler kernel.




contoh implementasi Hybrid

Scheduler aktivasi yang digunakan oleh NetBSD asli POSIX thread implementasi perpustakaan (sebuah M: Model N sebagai lawan kernel 1:1 atau model implementasi userspace)
Marcel dari PM2 proyek.
OS untuk Tera / Cray MTA
Microsoft Windows 7

contoh implementasi Fiber

Serat dapat dilaksanakan tanpa dukungan sistem operasi, meskipun beberapa sistem operasi atau perpustakaan memberikan dukungan eksplisit untuk mereka.
Win32 API memasok serat [3] (Windows NT 3.51 SP3 dan kemudian)
Ruby sebagai benang Hijau
Netscape Portabel Runtime (termasuk implementasi serat user-space)

Pemrograman dukungan bahasa

Banyak bahasa pemrograman mendukung threading dalam beberapa kapasitas. Banyak implementasi dari C dan C + + memberikan dukungan untuk threading sendiri, tetapi juga memberikan akses ke threading API asli yang disediakan oleh sistem operasi. Beberapa tingkat yang lebih tinggi (dan biasanya lintas platform) bahasa pemrograman seperti Java, Python, dan NET., Mengekspos threading untuk pengembang sedangkan abstrak perbedaan spesifik platform dalam implementasi threading di runtime untuk pengembang. Sejumlah bahasa pemrograman lain juga mencoba abstrak konsep concurrency dan threading dari pengembang sama sekali ( Cilk , OpenMP , MPI ). Beberapa bahasa yang dirancang untuk paralelisme (Ateji PX, CUDA ).
Beberapa bahasa pemrograman ditafsirkan seperti Ruby dan (pelaksanaan CPython dari) Python dukungan threading, tetapi memiliki keterbatasan yang dikenal sebagai Juru Kunci global (GIL). GIL merupakan kunci saling pengecualian diselenggarakan oleh interpreter yang dapat mencegah penafsir dari bersamaan menafsirkan aplikasi kode pada dua atau lebih benang pada saat yang sama, yang secara efektif membatasi concurrency pada beberapa sistem inti (sebagian besar untuk benang prosesor-terikat, dan tidak banyak untuk yang network-bound).
Pemrograman event-driven bahasa deskripsi hardware seperti Verilog memiliki model threading berbeda yang mendukung sangat besar jumlah benang (untuk modeling hardware).

tugas mbo RATIONAL ROSE

RATIONAL ROSE

Rational Rose adalah perangkat lunak pemodelan visual yang sangat lengkap untuk membantu dalam analisis dan desain sistem perangkat lunak berorientasi objek. Rational Rose digunakan untuk memodelkan sistem sebelum programer menuliskan kode program dalam suatu bahasa (misalnya visual basic, c++, java dan bahasa lainya). Developer dapat menggunakan model sebagai cetakbiru (blueprint) untuk sistem yang akan dibangun. Pengembangan perangkat lunak tradisional belum menggunakan perangkat lunak untuk memodelkan sistem seperti pada gambar berikut ini.

2.2. Proses Rekayasa Perangkat Lunak dengan Rational Rose.

Pada pengembangan perangkat lunak modern kebutuhan didokumentasikan, dan desain objek dibuat model terlebih dahulu untuk menggambarkan sistem yang akan dibangun. Karena desain objek telah dimodelkan, sehingga kita memperoleh dokumentasi berupa gambaran sistem secara lebih lengkap sehingga tidak ada kekhawatiran jika ada anggota tim yang nonaktif atau mengundurkan diri, karena semua penggambaran sistem telah didokumentasikan secara lengkap.

2.3. Team dalam Rekayasa Perangkat Lunak.

Dalam pengembangan perangkat lunak membutuhkan tim yang terdiri dari orang-orang yang memiliki peran yang berbeda-beda. Masing-masing peran tim memiliki hubungan dengan diagram-diagram yang dihasilkan.

1) Seluruh Anggota Team : menggunakan Bussines Use Case Diagram untuk memperoleh pemahaman tentang ruang lingkup sistem.

2) Pelanggan Dan Manager proyek : menggunakan Use Case Diagram untuk memperoleh gambaran sistem level-tinggi dan sepakat mengenai ruang lingkup proyek.

3) Manager Proyek : menggunakan dokumentasi Use Case Diagram untuk memecah proyek ke dalam bagian agar dapat di kontrol (dikendalikan).

4) Sistem Analis Dan Pelanggan : menggunakan dokumentasi Use Case untuk melihat kemampuan sistem yang akan di fungsikan.

5) Penulis Teknis akan menggunakan dokumentasi Use Case untuk menulis rencana latihan dan manual penggunaanya.

6) Sistem Analis Dan Pengembang : memperhatikan Sequence Diagram dan Collaboration Diagram untuk melihat bagaimana alur logika didalam sistem, object dalam sistem, dan pesan-pesan antar object.

7) Quality Assurrance Staff : menggunakan dokumentasi Use Case, Sequence dan Collaboration Diagram untuk memperoleh informasi skrip untuk pengujian.

Pengembang : menggunakan Class Diagram dan Statechart Diagram untuk mendapatkan gambaran terperinci dari bagian sistem dan bagaimana bagian-bagian tersebut saling terhubung.

9) Staff Deployment : menggunakan Deployment Diagram Dan Komponen Diagram untuk melihat file executable, file DLL, atau komponen lain yang akan diciptakan, dan di mana komponen ini akan disebarkan.

10) Keseluruhan Team : menggunakan seluruh model untuk memastikan kebutuhan dan kode dapat ditelusuri balik sesuai kebutuhan.

Model sistem terdiri dari diagram yang berbeda sehingga tim proyek dapat melihat sistem dari perspektif yang berbeda (customer, designer, project manager, tester, dan lainya). Rational Rose mendukung tipe-tipe diagram UML : Use Case, Activity, Sequence, Collaboration, Class, Statechart, Component, and Deployment.

Bagian-bagian tampilan layar rational rose dapat dibedakan menjadi lima macam bagian.

1. Browser : digunakan untuk menavigasikan secara cepat suatu model.

2. Documentation window : digunakan untuk melihat atau memper- baharui dokumentasi dari elemen-elemen model dalam diagram.

3. Toolbars : digunakan untuk mengakses secara cepat perintah-perintah yang umum digunakan.

4. Diagram window : digunakan untuk menampilkan dan mengedit satu atau lebih diagram UML.

5. Log digunakan untuk melihat error dan report hasil dari perintah-perintah yang diberikan.

Bagian-bagian layar perangkat lunak Rational Rose secara detil dijelaskan sebagai berikut :

a. Browser.

• Browser adalah struktur hirarki yang digunakan untuk menavigasikan dengan mudah model-model rose.

• Didalam browser dapat di gambarkan Aktors, Use cases, Class, Components dan Device.

Aktivitas-aktivitas yang dapat dilakukan didalam jendela browser adalah :

1) Menambahkan elemen model (use case, aktor, class, component dan diagrams).

2) Melihat element model yang ada.

3) Melihat relasi antar element model yang ada.

4) Memindahkan elemen model.

5) Merubah nama elemen model.

6) Menyertakan sebuah file atau URL ke elemen.

7) Mengelompokkan elemen kedalam paket.

Mengakses spesifikasi detail dari elemen.

9) Membuka berbagai macam diagram.

b. Documentation Window.

• Dokomentasi windows digunakan untuk mendokumentasikan elemen-elemen pada model, misalnya memberikan definisi singkat untuk setiap aktor.

• Pada saat menambahkan dokumentasi untuk Class, dokumentasi tersebut akan di ditampilkan sebagai komentar pada kode program.

• Dokumentasi juga akan ditampilkan di dalam laporan (report) yang di dihasilkan oleh rational rose.

c. Toolbars.

Toolbar dibedakan menjadi dua macam, yaitu :

1. Standard toolbar : mengandung pilihan berupa icon yang dapat digunakan pada setiap diagram.

2. Diagram toolbar : disebut sebagai toolbox, mengandung pilihan berupa icon yang dapat digunakan pada diagram yang aktif.

d. Diagram Windows.

Pada jendela diagram ditampilkan diagram UML dari model sistem. Ketika melakukan perubahan elemen dalam suatu diagram, maka Rational Rose akan secara otomatis memperbaharui tampilan browser. Begitu pula sebaliknya jika terjadi perubahan suatu elemen didalam browser, maka Rational Rose akan secara otomatis membaharui diagram yang sesuai.

e. Log Windows.

Setiap aktivitas akan menghasilkan informasi tertentu yang akan di catat pada Log windows, misalnya ketika menghasilkan kode, kesalahan yang terjadi akan di dicatat didalam Log windows. Log Windows ditunjukkan pada gambar berikut :

Ada empat macam view didalam model rose:

a. Use Case View.

b. Logical View.

c. Component View.

d. Deployment View.

Masing-masing view ini ditujukan untuk pengguna yang berbeda dan memiliki tujuan yang berbeda pula. Lebih detil dari masing-masing view disejelaskan sebagai berikut :

a. Use Case View.

Use Case View menampilkan semua objek Aktor, Use Case, dan Diagram Use Case didalam sistem dan dimungkinkan untuk membuat Sequence dan Collaboration Diagram. Use Case View adalah suatu implementasi bebas dalam melihat sistem. Use Case View memusatkan pada suatu penggambaran level tinggi, apa yang akan di lakukan oleh sistem tanpa melihat detail bagaimana sistem akan melakukannya (digambarkan didalam activity diagram).

rti notasi-notasi di dalam Use Case View :

1) Bisnis use cases, menggambarkan aliran kerja (workflow) didalam suatu organisasi.

2) Bisnis aktors, menggambarkan orang-orang, perusahaan, atau entitas lain di luar organisasi yang berinteraksi dengan lingkungan bisnis didalam sistem.

3) Bisnis worker, menggambarkan pekerja yang memiliki peran dalam organisasi atau perusahaan.

4) Organizational units, menggambarkan kelompok bisnis usecase dan atau bisnis worker.

5) Activity diagrams, digunakan untuk menguraikan aliran kerja (workflow) di dalam suatu bisnis use case atau suatu aliran peristiwa dalam sistem use case.

6) Aktors, mengganbarkan kesatuan eksternal yang memiliki hubungan dengan sistem yang dibangun.

7) Use case, menggambarkan bagian dari fungsionalitas system.

Use Case Documentation, menggambarkan detil aliran kerja didalam use case yang mencakup penanganan kesalahan. Icon ini merepresentasikan suatu file eksternal.

9) Use Case Diagram, menggambarkan para aktor, use case, dan interaksi yang terjadi antara mereka.

10) Interaction Diagram, menggambarkan class atau object yang terlibat dalam satu aliran sepanjang use case. Dimungkinkan ada beberapa Interaction Diagram untuk masing-masing use case. Interaction diagram dapat dibuat di dalam use case view atau logical view.

11) Package, menggambarkan kelompok use case, aktor, atau elemen lain. Suatu paket (package) adalah suatu mekanisme UML yang membantu untuk mengelompokkan objek-objek didalam satu paket.

b. Logical View.

Didalam logical view menggambarkan bagaimana sistem akan menerapkan perilaku atau operasi di dalam use case. Logical view menggambarkan secara detail bagian dari suatu sistem dan hubunganya dengan objek-objek. Logical view meliputi Class, Diagram Class, dan Statechart Diagram. Dengan detail elemen-elemen ini, maka pengembang dapat membangun suatu disain terperinci sebuah sistem.

Class menggambarkan objek yang memiliki atribut dan methoda (operasi). Misalnya Class karyawan menyimpan informasi nip, nama karyawan, alamat, dan memiliki methoda class seperti menerima gaji, lembur, cuti dan sebagainya. Diagram class digunakan untuk melihat class-class, operasi-operasi dan atribut-atribut class, serta hubungan antar class class yang ada didalam sistem. Suatu sistem dapat memiliki beberapa diagram class, masing-masing menunjukkan suatu subset dari class-class secara keseluruhan.

c. Component View.

Didalam component diagram berisi informasi tentang pustaka kode program, file executable, pustaka runtime, dan komponen lainya. Sebuah komponen merupakan modul fisik dari suatu kode. Component dan component diagram dibuat didalam Component View. Component view juga menampilkan hubungan antara modul-modul dari kode program.

Component Diagram, menggambarkan komponen itu sendiri dan hubungan antar component. Hubungan antar component memberikan informasi komponen tersebut saling bergantung yang berfungsi untuk menentukan urutan kompilasi terhadap komponen. Sebuah package merupakan kelompok komponen-komponen yang saling berelasi.

d. Deployment View.

View yang terakhir di dalam Rational Rose adalah Deployment view. Deployment view berkaitan dengan penyebaran secara fisik suatu sistem. Misalnya sistem mungkin menerapkan arsitektur three tier arsitektur atau two tier arsitektur. Interface (antarmuka aplikasi) mungkin ditempatkan pada suatu mesin, sedangkan database ditempatkan pada mesin lain. Isu-isuyang berhubungan dengan toleransi kesalahan, bandwith jaringan, pemulihan dari bencana, dan waktu tanggap sistem ditangani menggunakan Deployment View.

Didalam deployment view terdapat komponen :

1) Processes, merupakan aliran (thread) dari suatu ekesekusi didalam memori proses itu sendiri.

2) Processors, merupakan mesin apapun yang memiliki kemampuan untuk memproses.

3) Setiap proses dapat di jalankan dalam satu atau lebih prosesor.

4) Devices merupakan perangkat keras yang tidak memiliki kemampuan kemampuan pemrosesan, misalnya dumb terminal dan printer.

2.6. Bekerja Dengan Rational Rose.

a. Membuat Model Baru.

Untuk mulai menggunakan rational rose diawali dengan membuat sebuah model sisten, langkah-langkahnyanya adalah :

1) Pilih Menu File => New, atau

2) Klik button new pada standart toolbar.

Selain cara diatas dapat juga menggunakan Framework Wizard ketika aplikasi Rational Rose pertama kali dijalankan. Ada beberapa keuntungan menggunakan framework wizard diantaranya adalah :

1) Tim pengembang perangkat lunak tidak perlu membuat elemen-elemen sendiri, karena telah disediakan elemen-elemen model framework (kerangka kerja) yang dipilih dengan pilihan bahasa yang berbeda.

2) Tim dapat menambahkan objek baru yang belum ada didalam framework atau langsung menggunakan objek yang sudah ada didalam framework.

3) Dengan framework akan membantu meyediakan konsistensi proyek.

4) Konsistensi antar anggota tim atau keseluruhan anggota tim.

5) Tim pengembang dapat menggunakan framework yang sama untuk proyek yang berbeda.

6) Memastikan bahwa apabila tim pengembang terdiri dari dua tim, kedua tim sedang membangun perangkat lunak dengan kerangka yang sama.

b. Menyimpan Model dan Log.

Sebaiknya model yang telah dibuat disimpan secara periodik untuk memastikan tim memperoleh update terakhir dari model. Langkah-langkah untuk menyimpan file rational rose (*.mdl) adalah :

• Pilih Menu File => Save, atau

• Klik Save button pada standart toolbar.

• Ketikkan nama file => NamaFile.Mdl

Sedangkan Langkah-langkah untuk menyimpan Log (*.log) adalah :

• Pilih Menu File => Save Log As

• Ketikkan nama file => Error.Log

c. Export dan Import Model.

Keuntungan utama paradigma berorientasi objek adalah penggunaan kembali (reuse) model yang telah dibuat sebelumnya. Reuse tidak hanya pada kode (dalam pemrograman) tetapi juga pada model. Rational mendukung reuse dengan mekanisme import dan export dari suatu model ke model lainya.

Mengexport model :

• Pilih menu file => Export Model

• Masukan nama file yang di export.

• Ketikkan nama file => namafile.ptl

Mengexport package :

• Pilih package yang akan diexport

• Pilih menu file Export Package

• Ketikkan nama file => namafile.ptl

Mengimport model :

• Pilih menu file => Import Model

• Pilih nama file yang di import.

d. Mempublikasi Model Ke Web.

Model yang telah dibuat dapat dipublikasi ke website secara keseluruhan atau sebagian. Untuk mempublikasi ke web langkah-langkahnya adalah :

• Pilih menu Tools => Web Publisher

• Pada bagian selection pilih view yang akan di publish ke web.

• Pilih level of detail => Documentation only, Intermediate atau Full.

1) Documentation Only : Informasi, properti dari element model tidak ditampilkan.

2) Intermediate : Menampilkan properti yang ada di tab general pada elemen model.

3) Full : Semua properti, termasuk tab detail pada model elemen spesification.

• Pilih notasi : Booch, OMT atau UML.

• Pilih Include inherited item (ya/tdk).

• Pilih Include propertis (ya/tdk).

• Pilih Association in browser (ya/tdk).

• Pilih Document wraping on browser (ya/tidak).

• Ketikan nama pada HTML root filename.

• Misalnya Index.html

• Setelah proses publish selesai, halaman web dapat di tampilkan dengan mengklik tombol preview.

e. Controlled Unit.

Rational Rose mendukung banyak pemakai (multiuser), dan pengembangan secara paralel termasuk juga pengontrolan terhadap unit atau bagian dari model sistem sehingga model dapat dibuka oleh pemakai lain. Controled unit dapat berupa paket yang ada pada empat view. Jika unit telah dikontrol, maka elemen dari model di simpan didalam file yang berbeda sebagai sub unit.

Membuat Controlled Unit

• Klik kanan package => pilih Unit.

• Pilih Control <package>.

• Ketikkan nama Controlled Unit kemudian klik => Save.

• Perhatikan Icon Package telah berubah berubah.

• Pada lingkungan pengembangan paralel (multiuser), agar user lain dapat menggunakan package maka package harus diunload.

• Klik kanan Package=> pilih Units kemudian klik => Unload <package>

• Package akan di hapus dari browser.

Unload Controlled Unit dari View.

• Klik kanan view => Pilih Unit

• Pilih Unload Subunit of <view>

Reload Package, status package telah diupdate oleh team pengembang lain.

• Klik kanan package => Pilih Units

• Pilih Reloaded <package>

Uncontrolled Unit.

• Pastikan Controlled Unit telah di panggil (Loaded)

• Klik kanan package => Pilih Unit

• Pilih Uncontrolled Package

Catatan : Controlled Unit tidak dihapus, hanya tidak ditampakan dibrowser.

Write Protect Controlled Unit.

• Klik kanan package => Pilih Unit

• Pilih Write Protect <package>

Write Enabled Controled Unit.

• Klik kanan package => Pilih Unit => Pilih write enable <package>

Gambar 2.14. Unload Controled Unit

f. Model Integrator

1) Model integrator didalam Rational Rose digunakan untuk mengkomparasi atau membandingkan dan menggabungkan model.

2) Fitur ini digunakan khusus jika terdiri dari banyak desainer.

3) Setiap desainer dapat bekerja secara individu, lalu semua model dapat diintegrasikan menjadi satu.

4) Pada saat mengkomparasi model, rational rose akan menampilkan perbedaan model yang dibandingkan.

5) Pilih Tools => Model Integrator, akan ditampilkan jendela berikut :

Langkah-langkah mengkomparasi Model-model.

1) Klik menu File => Pilih Contributors.

2) Tekan tombol […] untuk memilih model pertama => Klik Open.

3) Tekan tombol new untuk memilih model kedua dan seterusnya.

4) Tekan button Compare, maka rational rose akan membandingkan model-model yang memberi kontribusi pada sistem, atau

5) Tekan button Merge maka rational rose akan menggabungkan dua model yang dibandingkan.

g. Menambahkan catatan (notes) pada model sistem.

Notes adalah kotak teks kecil yang ditambahkan didalam diagram untuk menuliskan catatan singkat elemen atau diagram. Menambahkan Notes :

• Pilih “note” icon dari toollbar

• Pilih posisi didalam diagram untuk menempatkan note

• Pilih “anchor note to item” button dari toolbar =>

• Drag and drop dari note ke item.

h. Bekerja dengan Package.

Package berfungsi untuk mengelompokkan elemen model sistem dalam sebuah wadah. Pengembang dapat membuat package yang berisi use case, aktor, class atau elemen-elemen model lainya. Package juga berguna untuk mengorganisasikan model sistem. Didalam use case view, package menyederhanakan kelompok use case dan aktor agar mudah untuk dikelola. Sedangkan didalam logical view, package digunakan untuk :

a. Mengelompokkan class dan elemen model lainya secara logikal.

b. Menampilkan dekonstruksi fisikal dari suatu sistem menjadi lapisan arsitektural sistem.

c. Analisa terhadap ketergantungan antara package menunjukkan bagaimana tim menggunakan ulang bagian-bagian dari package.

d. Mungkin pada suatu saat package mengalami perubahan, maka hal ini akan berpengaruh pada package lain dan juga lapisan arsitektural sistem.

e. Dependensi package mengindikasikan class didalam package memiliki relasi dengan class lain sehingga terdapat saling ketergantungan.

1) Pada komponen view, package digunakan dalam layer atau lapisan yang berbeda didalam asitektur sistem.

2) Pada kasus ini package difokuskan pada komponen bukan pada class.

3) Pada deployment view, package dapat digunakan untuk memisahkan kategori perangkat yang berbeda (misalnya processor atau devices).

4) Package dapat dibuat dari package lain untuk mengorganisasikan model, hal ini dilakukan apabila :

• Pemodelan sistem sangat besar dan kompleks.

• Model sistem suatu aplikasi memiliki relasi dengan aplikasi lain.

5) Menambah dan Menghapus Package.

Menambahkan package :

• Klik kanan pada browser => pilih satu dari empat view atau

• Klik kanan pada package yang sudah ada => pilih new => package.

Menghapus package :

• Klik kanan package => pilih delete.

i. Menambah dan Menghapus File dan URL.

Menambah File atau URL :

• Klik kanan elemen model, Pilih new => File or URL, Pilih URL, maka URL ditambahkan. Klik 2 kali untuk melihat URL di Browser Internet Explorer.

j. Menambah dan Menghapus Diagram.

Menambah Diagram :

• Klik kanan pada browser => pilih new

• Pilih <Tipe Diagram>

• Ketikkan nama diagram.

• Klik 2 kali untuk membukanya.

Menghapus diagram :

• Klik kanan diagram => pilih delete

• Diagram akan dihapus

k. Seting Pilihan Global.

Mengatur jenis huruf dan warna untuk semua model objek.

• Pilih menu Tools => options.

• Setiap objek model juga dapat memiliki jenis huruf dan warna yang berbeda.

• Untuk mengatur objek.

• Klik kanan objek => Format Font.

• Pilih jenis font, style, size.

TUGAS USE CASE DIAGRAM

TUGAS USE CASE DIAGRAM

 

 

USE CASE SISTEM PERINGATAN BANJIR