KATA PENGANTAR. Analisa & Desain Berorientasi Obyek

Transkripsi

1

2 KATA PENGANTAR Puji syukur kami panjatkan ke hadirat Allah SWT atas segala limpahan kekuatan-nya sehingga dengan segala keterbatasan waktu, tenaga dan pikiran yang dimiliki penulis, akhirnya modul praktikum edisi ketiga ini dapat terselesaikandengan beberapa revisi dari edisi sebelumnya. Praktikum Analisa dan Desain Beorientasi Obyek (ADBO) ini adalah mata kuliah wajib di jurusan Sistem Informasi. Praktikum ini mensyaratkan pengambilan mata kuliah Analisa dan Desain Beorientasi Obyek (ADBO) terlebih dahulu. Beban praktikum ini sebesar satu sks dan pelaksanaannya kurang lebih 2 jam aktivitas di laboratorium. Modul praktikum ini dibuat dengan tujuan untuk mempermudah pelaksanaan praktikum. Dan lebih dari itu, diharapkan mampu menjadi media akselerasi pemahaman serta ketrampilan (skill) praktikan sesuai dengan kompetensi yang diharapkan. Penulis sadar bahwa modul ini masih memiliki kekurangan. Oleh karena itu saran dan masukan sangatlah diharapkan demi semakin baiknya kualitas. Tak lupa penulis ucapkan terima kasih banyak atas bantuan tim asisten dalam menyiapkan materi praktikum. Surabaya, Oktober 2016 Penulis Modul Praktikum 1

3 DAFTAR ISI KATA PENGANTAR... 1 PENGANTAR BERORIENTASI OBYEK... 3 MODUL 1 BUSINESS USE CASE DIAGRAM... 7 MODUL 2 USE CASE DIAGRAM MODUL 3 ACTIVITY DIAGRAM MODUL 4 SEQUENCE & COLLABORATION DIAGRAM MODUL 5 CLASS DIAGRAM MODUL 6 STATECHART DIAGRAM MODUL 7 COMPONENT DIAGRAM MODUL 8 DEPLOYMENT DIAGRAM Modul Praktikum 2

4 PENGANTAR BERORIENTASI OBYEK 1. Pengantar Berorientasi obyek atau object oriented merupakan paradigma baru dalam rekayasa perangkat lunak yang memandang sistem adalah kumpulan obyek-obyek yang saling berinteraksi. Yang dimaksud dengan berorientasi obyek adalah bahwa mengorganisasikan perangkat lunak sebagai kumpulan obyek-obyek diskrit yang bekerja sama antara data structure dan behaviour. Obyek adalah segala sesuatu yang ada disekitar kita, dan obyek-obyek yang menyusun dunia ini. Sebagai contoh: mobil, truk, motor, becak, sepeda dan lain-lain adalah contoh obyek kendaraan. Setiap obyek mempunyai data structure atau atribut dan behaviour atau operasi. Atribut dari obyek di atas adalah jumlah roda, warna, berat, dsb. Sedangkan operasi dari obyek di atas adalah berjalan, belok kanan, belok kiri, naikkan kecepetan, dll. Paradigma berorientasi obyek mempunyai bidang aplikasi yang sangat luas dalam bidang rekayasa perangkat lunak, antara lain: pemrograman, pemodelan sistem informasi, manajemen proyek, perangkar keras, dan sebagainya. Dalam hal pemrograman, berorientasi obyek adalah suatu cara membuat program, mempunyai beberapa keuntungan. Ia menggunakan pendekatan component-based untuk pengembangan perangkat lunak, sehingga pertama kali dengan membuat sebuah sistem yang merupakan kumpulan obyek-obyek. Kemudian saat mengembangkan sistem dengan menambahkan kapasitas ke komponen-komponen baru. Pada akhirnya, jika membangun sistem baru akan cukup dengan menggunakan kembali obyek-obyek yang telah dibuat ke sistem baru yang sedang dibangun. 2. UML (Unified Modelling Language) Unified Modeling Language (UML) merupakan sistem arsitektur yang bekerja dalam OOAD dengan atau bahasa yang konsisten untuk menentukan, visualisasi, mengkonstruksi, dan mendokumentasikan artifact yang terdapat dalam system software. UML merupakan bahasa pemodelan yang paling sukses dari tiga metode OO yang telah ada sebelumnya, yaitu Booch, OMT, dan OOSE. Modul Praktikum 3

5 UML merupakan kesatuan dari ketiga metode pemodelan tersebut dan ditambah kemampuan lebih karena mengandung metode tambahan untuk mengatasi masalah pemodelan yang tidak dapat ditangani ketiga metode tersebut. 3. Rational Rose Rational Rose merupakan salah satu software yang paling banyak digunakan untuk melakukan design software melalui pendekatan UML (Unified Modelling Language). Rational Rose merupakan software yang menyediakan banyak fungsi - fungsi seperti : design proses, generate code, reverse engineering, serta banyak fungsifungsi yang lain. Rational Rose merupakan tool yang sangat mudah karena sudah menyediakan contoh-contoh design dari beberapa software. 4. Menggunakan Rational Rose Untuk membuat file Rational Rose, buka aplikasi Rational Rose sehingga anda akan dihadapkan pada beberapa pilihan seperti jdk-12,jdk-116, jenterprise, jfc-11, Oracle Database, Rational Unified Process (RUP), VB6 Standard serta model-model yang lain. Model-model ini merupakan pilihan apakah ingin membuat file Rational Rose yang mengandung komponen Java, Visual Basic atau Visual C++. Hal ini dibutuhkan ketika nanti akan melakukan generate code (membuat contoh code) dari design yang telah dibuat. Dapat dilihat pada gambar1 : Gambar 1.1 Create New Model Modul Praktikum 4

6 Rational Unified Process (RUP) merupakan pilihan yang tepat untuk membuat suatu design yang lengkap dengan cara mudah karena model ini merupakan template, sehingga kita dapat langsung melakukan perubahan dengan mengganti use case, actors, class diagram yang telah ada pada template RUP. Namun jika anda tidak ingin memilih salah satu dari model-model diatas ada dapat menekan tombol cancel. Gambar 1.2. Editor Rational Rose 5. Pengenalan Diagram diagram dalam UML UML membantu memahami sistem dengan menggunakan beberapa diagram visual yang menunjukkan bermacam aspek dalam sistem. Ada beberapa diagram yang disediakan dalam UML, antara lain : a. Diagram Use Case Bisnis (Bussiness Use Case Diagram) b. Diagram Use Case (Use Case Diagram) c. Diagram Aktivitas (Activity Diagram) d. Diagram Sekuensial (Sequence Diagram) e. Diagram Kolaborasi (Collaboration Diagram) Modul Praktikum 5

7 f. Diagram Kelas (Class Diagram) g. Diagram Keadaan (Statechart Diagram) h. Diagram Komponen (Component Diagram) i. Diagram Penyebaran (Deployment Diagram) 6. Model Dalam Rekayasa Software Agar model yang kita buat memenuhi kriteria sebagai model yang bagus, model yang kita buat harus mampu: 1. Mengidentifikasi persyaratan (requirements) dan dapat menyampaikan informasi dengan jelas 2. Berfokus pada bagaimana komponen-komponen sistem berinteraksi 3. Membantu kita untuk melihat hubungan antar komponen 4. Meningkatkan komunikasi antar anggota tim dengan menggunakan bahasa yang mudah dipahami dalam hal ini adalah bahasa grafis. Modul Praktikum 6

8 MODUL 1 BUSINESS USE CASE DIAGRAM Business Use Case Diagram digunakan untuk menyajikan fungsi yang disediakan oleh keseluruhan organisasi. Diagram ini menjawab pertanyaan sebagai berikut: Apa yang bisnis dilakukan dan mengapa harus membangun sistem. Diagram ini digunakan selama pemodelan aktifitas bisnis berlangsung dan mengatur konteks sistem untuk membentuk pondasi dalam pembentukan use case. Business Use Case Diagram adalah penggambaran tujuan suatu organisasi. Diagram ini tidak membedakan antara proses manual atau proses komputerisasi. Langkah langkah : 1. Expand Use Case View dan Business Use Case Model. Double klik on Global View of Business Actors and Business Use Case Gambar 1.3. Global View of Business Actors and Business Use Cases 2. Untuk memulai membuat Business Use Case, gunakan Diagram Toolbox untuk Business Use case dan Actors. Lalu tambahkan Relasi diantara business use case dengan actor. Modul Praktikum 7

9 Gambar 1.4. Business Use Case Diagram 3. Rational Rose menyediakan stereotype tertentu untuk model elemen berbeda dalam business use case. Stereotype menunjukkan sub klasifikasi dari model element. Untuk mengetahuinya, double klik pada entity, lalu akan muncul Class Specification. Gambar 1.5. Class Specification Modul Praktikum 8

10 3. a. Business Actor Business Actor adalah seseorang atau sesuatu yang ada diluar organisasi dan berinteraksi dengan organisasi. Misalkan : pelanggan, kreditor, investor, supplier atau peminjam. Para actor ini, masing-masing mempunyai ketertarikan pada kegiatan-kegiatan perusahaan. Dalam UML, business actor dimodelkan dengan menggunakan ikon : Gambar 1.6. Ikon Business Actor Walaupun ikon tersebut terlihat seperti orang, sebuah business actor biss berarti kelompok orang atau perusahaan. Pemodelan business actor untuk memahami siapa dan dalam rangka apa mereka berinteraksi dengan bisnis serta bagaimana mereka berinteraksi dengan bisnis. 3. b. Business Worker Business worker adalah suatu peranan di dalam organisasi, bukan posisi. Seseorang boleh memainkan banyak peranan tapi memegang hanya satu posisi. Keuntungan berbasiskan peranan dibanding berbasiskan posisi adalah bahwa posisi cenderung berubah, sementara peranan cenderung tetap. Dalam UML, business worker dimodelkan dengan menggunakan ikon : Gambar 1.7. Ikon Business Worker Pemodelan business worker untuk memahami peranan di dalam bisnis dan bagaimana peranan tersebut berinteraksi. Dengan menguraikan masing-masing business worker, dapat dipahami apa yang menjadi tanggung jawab masingmasing peranan, keterampilan apa saja yang diperlukan untuk peranan itu, dll. Modul Praktikum 9

11 3. c. Business Use Case Business Use Case adalah suatu himpunan aliran kerja dalam organisasi yang mempunyai nilai terhadap business actor. Dengan kata lain, business use case menceritakan tentang apa yang dilakukan oleh organisasi. Dalam UML, business use case dimodelkan dengan menggunakan ikon : Gambar 1.8. Ikon Business Use Case Business Use Case memiliki format penulisan nama <kata kerja><kata benda>, seperti pada kata Sirkulasi Perpus. 3. d. Business Entity Business Entity adalah obyek yang digunakan oleh organisasi untuk melakukan aktifitas bisnis atau yang organisasi hasilkan saat melakukan aktifitas bisnis. Entitas meliputi sesuatu pekerja bisnis hadapi sehari-hari. Setiap entity harus diberi nama yang unik, menggambarkan tanggung jawabnya, berbentuk kata benda atau frase kata benda, dan harus jelas. Dalam UML, business entity dimodelkan dengan menggunakan ikon : Gambar 1.9. Ikon Business Entity Business Entity dapat ditambahkan beberapa attribute, dimana atribut adalah informasi yang menjelaskan entity tersebut. LATIHAN MODUL 1 1. Buatlah Business Use Case Diagram dari skenario yang diberikan! Modul Praktikum 10

12 MODUL 2 USE CASE DIAGRAM Use Case Diagram menyajikan interaksi antara use case dan aktor. Dimana aktor dapat berupa orang, peralatan atau sistem lain yang berinteraksi dengan sistem yang dibangun. Use case menggambarkan fungsionalitas sistem atau persyaratanpersyaratan yang harus dipenuhi sistem dari pandangan pemakai. Jika Business Use Case Diagram tidak memperhatikan apakah proses dilakukan secara otomasi terkomputerisasi, maka Use Case Diagram berfokus hanya pada proses otomatisasi saja. Dalam bagian ini akan membahas tentang konsep dasar pemodelan use case meliputi : use case, actor dan relasi. Jika sudah memahami pemodelan bisnis, ada kemiripan antara pemodelan bisnis dan pemodelan use case. Perbedaanya adalah jika pada pemodelan bisnis memfokuskan pada organisasi, sedangkan pemodelan sistem berfokus pada sistem yang sedang dibangun. Perbedaan antara pemodelan bisnis dan pemodelan sistem : Tabel 2.1. Perbedaan Pemodelan Bisnis dengan Pemodelan Sistem Item Pemodelan Bisnis (Business Use Case) Pemodelan Sistem (Use Case) Use Case Menjelaskan apa yang bisnis Menjelaskan apa yang kerjakan sistem lakukan di bisnis Aktor Eksternal terhadap organisasi Eksternal terhadap sistem (mungkin internal terhadap sistem) Pekerja Bisnis Internal terhadap organisasi Tidak digunakan 2.1. Use Case Use Case adalah bagian tingkat tinggi dari fungsionalitas yang disediakan oleh sistem. Dengan kata lain, use case menggambarkan bagaimana seseoarang menggunakan sistem. Untuk mengidentifikasi use case, kita menjawab pertanyaan : apa yang sistem lakuakan terhadap dunia sekelilingnya?. Dalam UML, use case dimodelkan dengan menggunakan ikon pada gambar 2.1: Modul Praktikum 11

13 Gambar 2.1. Notasi Use Case Use case merupakan independen terhadap implementasinya dan pandangan tingkat tinggi apa yang pemakai harapkan dari sistem. Dengan penjelasan sebagai berikut: 1. Use case adalah independen terhadap implementasinya. Selama membuat use case, asumsikan bahwa anda sedang membangun sebuah sistem manual. Use case anada harus mampu dibangun dalam Java, Visual Basic, C++, atau kertas. Use case berkonsentrasi pada apa yang system harus kerjakan, bukan bagaimana sistem mengerjakannya. 2. Use case adalah pandangan tingkat tinggi apa yang pemakai harapkan dari sistem. Use case yang sudah dikelompokkan memudahkan pelanggan memahaminya, pada level yang sangat tinggi dari sustu sistem. 3. Use case difokuskan pada apa yang pengguna dapatkan dari sistem. Masingmasing use case mempresentasikan transaksi lengkap antara pemakai dan sistem yang menghasilkan manfaat terhadap pemakai. Use case diberikan nama dalam termoniologi pemakai, bukan terminologi teknikal, dan harus bermakna terhadap pelanggan. Nama sebuah use case adalah kata kerja atau frase kata kerja dengan format <kata kerja><kata benda>, dan menjelaskan apa yang pelanggan perhatikan sebagai hasil akhir Actor Actor adalah seseorang atau apa saja yang berhubungan dengan sistem yang sedang dibangun. Use Case menggambarkan semua yang ada dalam ruang lingkup sistem. Actor merupakan semua yang ada di luar ruang lingkup sistem. Dalam UML, actor dimodelkan dengan menggunakan ikon : Modul Praktikum 12

14 Gambar 2.2. Notasi Actor Ada 3 tipe actor, yaitu : 1. Pengguna sistem Actor secara fisik atau seotang pengguna. Ini adalah gambaran actor secara umum, dan selalu ada pada setiap sistem. Untuk sistem sirkulasi perpustakaan, actor-nya adalah orang-orang yang secara langsung menggunakan sistem. Ketika menamakan actor, gunakan nama peranan dan jangan gunakan nama posisi. Posisi dapat berubah, tetapi peranan dapat digantikan oleh siapa saja dan relatif tetap. 2. Sistem lain yang berhubungan dengan sistem yang dibangun 3. Waktu Waktu dapat menjadi suatu actor ketika melalui sejumlah waktu tertentu memicu beberapa kejadian dalam sistem. Misalnya, bagian promosi memberikan kesempatan pada pelanggan untuk memenangkan tiket gratis. Setiap hari pada pukul dini hari, sistem secara otomatis menyeleksi secara acak pelangganpelanggan untuk mendapatkan tiket gratis tersebut. Sebab waktu adalah di luar kendali kita, maka ia dapat menjadi actor Relasi Kita telah membahas use case dan actor, sekarang akan dibahas relasi antar use case untuk mendapatkan sistem secara utuh. Relasi asosiasi digunakan untuk menunjukkan relasi antara use case dan actor. Ada tiga tipe relasi antara use case : relasi include, relasi extend, dan relasi generalisasi. Sedangkan relasi antara actor hanya digunakan satu relasi yaitu generalisasi. Modul Praktikum 13

15 Relasi Assosiasi Relasi antara actor dan use case adalah relasi assosiasi. Dalam UML, relasi assosiasi digambarkan dengan menggunakan anak panah. Gambar 2.3. Relasi Assosiasi Dalam contoh, use case mengawali komunikasi dengan actor sistem kredit. Selama use case Purchase Ticket berjalan, sistem reservasi mengawali komunikasi dengan sistem kredit untuk mengecek kartu dan melengkapi transaksi. Meskipun aliran informasi terjadi dalam dua arah, dari reservasi sistem ke kartu kredit dan bolak-balik, arah panah mengindikasikan siapa yang mengawali komunikasi. Dengan mengecualikan use case dalam relasi include dan relasi extend, setiap use case harus diinisialisasi oleh actor. Gambar 2.4. Relasi assosiasi dua actor Relasi Include Relasi include memungkinkan satu use case menggunakan fungsionalitas yang disediakan oleh use case lainnya. Relasi ini dapat digunakan dengan alasan salah satu dari dua hal, yaitu : 1. Jika dua atau lebih use case mempunyai bagian besar fungsionalitas yang identik, maka fungsionalitas ini dapat dipecah ke dalam use case tersendiri. Masingmasing use case kemudian menggunakan relasi include terhadap use case baru dibuat tersebut. Modul Praktikum 14

16 2. Relasi include bermanfaat untuk situasi jika sebuah use case mempunyai fungsionalitas besar yang tidak umum. Relasi include digunakan untuk memodelkan dua buah use case yang lebih kecil tersebut. Relasi include meyatakan bahwa satu use case selalu menggunakan fungsionalitas yang disediakan oleh use case lainnya. Gambar 2.5. Relasi include Relasi Extend Relasi extend memungkinkan satu use case secara opsional menggunakan fungsionalitas yang disediakan oleh use case lainnya. Dalam UML, relasi extend digambarkan sebagai berikut : Gambar 2.6. Relasi extend Relasi Extend Relasi generalisasi digunakan untuk menunjukkan bahwa beberapa actor atau use case mempunyai beberapa persamaan. Sebagai contoh, ada dua tipe pelanggan : pelanggan perusahaan dan pelanggan individu. Hal ini dapat dimodelkan dengan relasi ini menggunakan notasi: Modul Praktikum 15

17 Gambar 2.7. Relasi generalisasi Tutorial Use Case Diagram 1. Expand Use Case view. Double klik pada Main. 2. Gunakan toolbar untuk menambahkan Actor, Use Case ke dalam use case diagram. Modul Praktikum 16

18 3. Tambahkan relasi antara use case dan actor. 4. Untuk melihat Class Specification, double klik pada use case. Modul Praktikum 17

19 LATIHAN MODUL 2 1. Buatlah Business Use Case Diagram dari soal yang diberikan! Modul Praktikum 18

20 MODUL 3 ACTIVITY DIAGRAM Activity diagram adalah cara lainnya untuk memodelkan aliran kejadian. Penggunaan teks dapat bermanfaat, tetapi akan kesulitan membaca dan memahami jika logika aliran kejadian sudah komplek. Activity diagram menunjukkan informasi yang sama sebagaimana dalam aliran kejadian dengan teks. Kita menggunakan Activity diagram dalam pemodelan bisnis untuk menggambarkan aliran kerja (workflow) yang ada dalam proses bisnis. Beberapa simbol yang digunakan antara lain : Activity Activity secara sederhana dapat diartikan sebagai langkah dalam proses. Dalam UML, activity digambarkan sebagai berikut : Menampilkan Form Pinjam Buku Gambar 3.1. Activity Kita dapat menambahkan langkah-langkah detil ke dalam activity dengan menggunakan aksi-aksi. Aksi-aksi adalah langkah-langkah lebih kecil dalam activity. Mereka mungkin salah satu dari empat hal berikut ini : 1. Saat sedang memasuki activity. Aksi Entry (entry action) terjadi segera saat activity ini dimulai dan ditandai dengan kata entry. 2. Ketika sedang meninggalkan activity. Aksi exit (exit action) terjadi pada saat meninggalkan activity dan ditandai dengan kata exit. 3. Ketika sedang berada dalam sebuah activity. Aksi ini terjadi saat di dalam activity dan selau terjadi hingga meninggalkan activity. Aksi ini ditandai dengan kata do 4. Kejadian spesifik (specific event). Aksi ini terjadi jika dan hanya jika kejadian spesifik terjadi. Aksi ini ditandai dengan kata event Aksi-aksi tersebut opsional, tapi dapat memberikan informasi rinci yang akan membantu untuk melengkapi rancangan sistem di kegiatan berikutnya. Modul Praktikum 19

21 Start dan End State Start dan End state sebagaimana yang kita ketahui adalah untuk memulai dan mengakhiri flow. Setiap activity diagram harus mempunyai start state dan diakhiri dengan end state. End state adalah opsional dan bisa lebih dari satu dalam satu Activity diagram. Dalam UML, digambarkan sebagai berikut : Start state End state Gambar 3.2. Notasi Start state dan End state Obyek dan Aliran Obyek Obyek adalah entitas yang digunakan dalam aliran. Obyek mungkin digunakan atau dirubah oleh activity dalam aliran. Pada Activity diagram, kita dapat menampilkan obyek dan kondisinya, sehingga kita dapat memahami di mana dan bagaimana kondisi obyek tersebut berubah. Obyek dihubungkan ke activity menggunakan aliran obyek (object flow). Aliran obyek digambarkan dengan garis panah putus-putus. Jika garis panah mempunyai arah dari activity ke obyek berarti ia memperbarui nilai obyek tersebut, dan jika arah panah dari obyek ke activity berarti ia sedang menggunakan obyek. Transisi Transisi menunjukkan bagaimana aliran kontrol bergerak dari satu activity ke activity lainnya. Transisi digambarkan menggunakan anak panah dengan nama transisi menunjukkan nama kejadiannya. Kejadian (event) memicu terjadinya transisi, kondisi (guard condition) mengontrol ada atau tidak ada transisi yang terjadi, sebuah kondisi harus benar agar transisi dapat terjadi. Sinkronisasi Sinkronisasi adalah suatu cara untuk menunjukkan bahwa dua atau lebih cabang dari aliran terjadi secara paralel. Modul Praktikum 20

22 Tutorial Activity diagram 1. Untuk membuat activity diagram, ditempatkan pada Use Case View. Klik kanan pada Use Case View folder, pilih yang New / Activity diagram. 2. Atau juga bisa melalui, klik kanan pada Use Case, pilih yang Sub Diagram / New Activity diagram. Modul Praktikum 21

23 3. Untuk menambahkan Guard Condition. Double klik pada Transisi, pilih tab detail dan inputkan kondisinya. LATIHAN MODUL 3 1. Buatlah Activity Diagram dari soal yang diberikan! Modul Praktikum 22

24 MODUL 4 SEQUENCE & COLLABORATION DIAGRAM Dua tipe diagram interaksi yang akan dibahas dalam modul ini, yaitu sequence diagram dan collaboration diagram. Kedua diagram tersebut menunjukkan partisipasi obyek-obyek dalam aliran yang melalui use case dan pesan tersebut akan dikirim antar obyek-obyek. Dua tipe diagram interaksi yang dikenal dengan nama sequence diagram dan collaboration diagram. Sequence diagram disusun berdasarkan urutan waktu, sedangkan collaboration diagram diorganisasikan seputar obyek itu sendiri. Sequence Diagram Sequence diagram adalah diagram interaksi yang disusun berdasarkan urutan waktu. Kita membaca Sequence diagram dari atas ke bawah. Setiap use case memiliki sebuah aliran alternafit. Setiap sequence diagram mepresentasikan satu aliran dari beberapa aliran di dalam use case. Kita dapat membaca diagram ini dengan memperhatikan obyek-obyek dan pesan-pesan yang ada di diagram. Obyek yang terlibat dalam aliran ditunjukkan dengan bujur sangkar yang ada diatas diagram. Collaboration Diagram Sebagaimana Sequence diagram, collaboration diagram digunakan untuk menampilkan aliran skenario tertentu dalam use case. Jika Sequence diagram disusun berdasarkan waktu, collaboration diagram lebih konsentrasi pada hubungan antara obyek-obyek. Untuk alasan tertentu, kita dapat membuat Sequence diagram dan collaboration diagram untuk sebuah skenario. Maskipun mereka mempunyai maksud dan menampilkan informasi yang sama, masing-masing memberikan sedikit perbedaan dalam penampilannya. Dalam tool Rational Rose, kedua diagram ini dapat saling dibangkitkan. Langkah-langkah yang dilakukan untuk membuat sequence diagram dan collaboration diagram adalah: a) Menemukan obyek-obyek Modul Praktikum 23

25 b) Menemukan aktor a. Menemukan obyek-obyek Sebuah cara untuk menemukan obyek adalah dengan memeriksa kata benda dalam aliran kejadian. Cara lainnya adalah dengan melihat dokumen skenario. Kebanyakan use case memiliki sejumlah sequence diagram atau collaboration diagram, satu untuk masing-masing skenario pada aliran kejadian. Diagram ini dapat dibangun dengan abstraksi level tinggi, untuk menampilkan bagaimana sistem berkomunikasi, atau pada level tinggi, untuk menampilkan bagaimana sistem berkomunikasi, atau pada level yang sangat rinci, untuk menunjukkan kelas-kelas apa saja yang berpartisipasi salam skenario tertentu. Tidak semua obyek didapatkan dari aliran kejadian. Form misalnya, mungkin tidak nampak dalam aliran kejadian, tapi akan nampak dalam diagram yang memungkinkan aktor dapat memsukkan atau menampilkan informasi ke/dari sistem. Obyek lain yang mungkin tidak nampak dalam aliran kejadian adalah obyek-obyek kontrol. Obyek-obyek dapat dikategorikan sebagai berikut: Obyek Entitas. Obyek Entitas menangai informasi yang disimpan dalam peyimpanan tetap. Entitas biasanya ditemukan dalam aliran kejadian (flow of event) pada diagram interaksi. Mereka adalah obyek yang sebagian besar bermakna terhadap pemakai dan secara tipikal diberikan nama menggunakan termonologi domain bisnisnya. Perhatikan kata benda dalam aliran kejadian. Beberapa kata benda akan menjadi kelas entitas dalam sistem. Cara lainnya adalah dengan memperhatikan struktur basis data. Jika rancangan basis data telah dibuat, perhatikan nama-nama tabel. Tabel-tabel menangani beberapa record informasi secara permanen, sementara kelas entitas, menangani informasi di dalam memori komputer saat komputer sedang dihidupkan. Dalam UML, notasi entitas digambarkan sebagai berikut: Entity Class Gambar 4.1. Notasi Entitas Modul Praktikum 24

26 Obyek Pembatas (Boundary). Obyek yang terletak dalam sebuah pembatas antara sistem dan lingkungannya. Semua form, laporan-laporan, antar muka (interfaces) ke perangkat lunak seperti printer atau scanner, dan antar muka (interfaces) ke sistem lainnya adalah termasuk dalam kategori ini. UML mepresentasikan kelas pembatas sebagai berikut: BoundaryClass Gambar 4.2. Notasi Pembatas Untuk menemukan dan mengidentifikasi kelas-kelas pembatas dapat dilakukan dengan menguji diagram use case. Minimal harus ada satu kelas pembatas untuk setiap interaksi antara actor-use case. Kelas pembatas adalah apa saja yang memungkinkan aktor berinteraksi dengan sistem. Tidak perlu membuat obyek pembatas untuk setiap pasangan actor-use case. Sebagai contoh, bila mempunyai dua aktor yang sama-sama menginisialisasi use case yang sama untuk berkomunikasi dengan sistem. Obyek kontrol. Obyek kontrol bertanggung jawab untuk mengkoordinasikan kegiatan-kegiatan terhadap obyek lainnya. Obyek ini bersifat opsional, tetapi jika digunakan, maka secara tipikal satu obyek kontrol untuk satu use case tersebut. Ada obyek-obyek kontrol yang digunakan bersama oleh beberapa use case. Dalam UML, notasi obyek kontrol digambarkan sebagai berikut: ControlClass Gambar 4.3. Notasi Kontrol Setiap obyek mengirimkan pesan kepada obyek yang lain maupun kepada obyek itu sendiri. Dalam UML, simbol yang menggambarkan pesan atau hubungan antar objek dan menunjukkan urutan kejadian yang terjadi disebut object message. Sedangkan simbol yang menggambarkan pesan atau hubungan objek itu sendiri disebut message to self. Kedua simbol tersebut digambarkan sebagai berikut: Modul Praktikum 25

27 Gambar 4.4. Object Message Gambar 4.4. Message to Self b. Menemukan aktor Satu aktor dalam diagram interaksi adalah sebuah pemicu luar yang memulai aliran kerja untuk aliran kejadian. Kita dapat mengidentifikasi sebuah aktor dengan melihat pada aliran kejadian dan menentukan siapa atau apa yang memulai proses. Tutorial Sequence Diagram 1. Klik kanan pada Package pilih New / Sequence Diagram Tutorial Collaboration diagram 1. Untuk membuat collaboration diagram dapat secara otomatis dibuat jika sudah ada Sequence diagram-nya. Klik Browse pada Menu kemudian Create collaboration diagram atau dengan menekan tombol F5 dari keyboard. Modul Praktikum 26

28 LATIHAN MODUL 4 1. Buatlah Sequence Diagram dari soal yang diberikan! Modul Praktikum 27

29 MODUL 5 CLASS DIAGRAM Class diagram digunakan untuk menampilkan kelas-kelas dan paket-paket di dalam sistem. Class diagram memberikan gambaran sistem secara statis dan relasi anatar mereka. Biasanya, dibuat beberapa class diagram untuk sistem tunggal. Beberapa diagram akan menampilkan subset dari kelas-kelas dan relasinya. Dpaat dibuat beberapa diagram sesuai dengan yang diinginkan untuk mendapatkan gambaran lengkap terhadap sistem yang dibangun. Class diagram adalah alat perancangan terbaik untuk tim pengembang. Diagram tersebut membantu pengembang mendapatkan struktur sistem sebelum kode ditulis, membantu untuk memastikan bahwa sistem adalah desain terbaik. Kelas Kelas adalah sesuatu yang membungkus informasi dan perilaku. Secara tradisional, sistem dibangun dengan ide dasar bahwa akan meyimpan informasi pada sisi basis data dan data perilaku pengolahnya pada sisi aplikasi. Salah satu perbedaan terstruktur dengan pendekatan berorientasi obyek adalah pada berorientasi obyek menggabungkan informasi dan perilaku pengolah informasi dan menyembunyikan semuanya ke dalam sesuatu yang disebut kelas. Dalam UML, kelas ditunjukkan menggunakan notasi sebagai berikut : Gambar 5.1. Notasi Class Bagian paling atas pada notasi Class digunakan sebagai nama kelas, dan secara opsional juga digunakan stereotype-nya. Bagian tengah digunakan untuk menyimpan atribut, dan bagian paling bawah digunakan menyimpan operasi. Modul Praktikum 28

30 Menemukan Kelas Cara yang baik untuk menemukan kelas-kelas adalah dimulai dari memperhatikan aliran kejadian (flow of event) dari suatu use case. Perhatikan kata benda di dalam aliran kejadian, mungkin merupakan salah satu dari empat hal berikut: Aktor Kelas Attribut dari kelas Ekspresi, bukan aktor, bukan kelas, dan bukan attribut. Dengan melakukan seleksi kata benda dalam aliran kejadian, dapat ditemukan kelas-kelas dalam sistem. Alternatif lainnya, dapat diuji obyek-obyek dalam sequence diagram atau collaboration diagram. Ada dua cara yang biasa dilakukan berkaitan dengan urutan pendefinisian antar kelas-kelas dalam class diagram dan sequence diagram atau collaboration diagram. Yang pertama, dengan membuat sequence diagram atau collaboration diagram lebih dulu kemudian melanjutkannya dengan membuat class diagram. Sebaliknya, yang kedua, yaitu dengan menemukan kelas-kelas dan membuat class diagram terlebih dulu, kemudian menggunakan kelas-kelas tersebut sebagai kamus obyek-obyek dan relasinya untuk membuat sequence diagram atau collaboration diagram. Stereotype pada Kelas Stereotype adalah sebuah mekanisme yang digunakan untuk mengkategorikan kelas-kelas. Misalnya, dapat dibuat stereotype form lebih dulu, kemudian menentukan kelas-kelas di langkah selanjutnya. Fitur ini membantu untuk lebih memahami tanggung jawab terhadap masing-masing kelas dalam model. Kelas-kelas dengan stereotype form bertanggung jawab menampilkan informasi ke pemakai dan menerima informasi dari pemakai. Stereotype juga membantu dalam proses pembangkkitan kode. Ketika proses pembangkitan kode, stereotype kelas menentukan tipe kelas yang akan dibawa ke bahasa pemrograman. Beberapa stereotype dapat digunakan sejak pada tahap proses analisis, pada saat belum ditentukan bahasa pemrograman tertentu untuk membangkitkan kode. Modul Praktikum 29

31 Stereotype juga bisa tergantung pada bahasa pemrograman yang dipilih dan digunakan pada tahap proses desain. Penamaan Kelas Masing-masing kelas harus mempunyai nama yang unik. Sebagian besar organisasi mempunyai konvensi penamaan sendiri untuk menamakan kelas-kelas yang dibuatnya.umumnya, kelas-kelas dinamakan menggunakan kata benda tunggal. Nama kelas tidak menggunakan spasi, ini dilakukan karena alasan praktis, dimana beberapa bahasa pemrograman tidak membolehkan adanya spasi. Hal lainnya yang perlu diperhatikan adalah bahwa nama kelas hendaknya pendek, cukup untuk menjelaskan apa yang akan kelas lakukan. Jadi penamaan kelas sangat tergantung pada organisasi kita. Jika kita mempunyai kelas yang digunakan dalam organisasi yang bersangkutan, tetapi yang jelas bahwa hal tersebut harus konsisten digunakan untuk keseluruhan kelas-kelas yang dibuatnya. Visibilitas Kelas Pilihan visibilitas menentukan dapat tidaknya sebuah kelas dilihat dari luar paket. Ada 3 pilihan visibilitas untuk sebuah kelas yaitu : Public Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas lainnya dalam sistem. Protected atau Private Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas majemuk (nested), friends, atau dari kelas itu sendiri. Package atau Implementation Menyatakan bahwa sebuah kelas dapat dilihat hanya oleh kelas yang lain dalam paket yang sama. Multiplicity Kelas Multiplicity memberikan gambaran sejumlah instan yang akan ditampung dalam keas. Misalnya, dalam kelas Pegawai, kita mungkin mempunyai beberapa instan, satu untuk Ani, satu untuk Ina, satu untuk Nana, dan seterusnya. Sehingga multiplicity Modul Praktikum 30

32 untuk kelas Pegawai diset n. Pada kelas kontrol, multiplicity diset 1, karena pada saat aplikasi berjalan hanya satu kelas. Beberapa jenis multiplicity kelas : Tabel 5.1. Notasi multiplicity untuk kelas Multiplicity Arti n (default) Banyak 0..0 Nol 0..1 Nol atau satu 0..n Nol atau banyak 1..1 Tepat satu 1.. n Satu atau banyak Atau dapat digunakan format tertentu sebagai berikut : Tabel 5.2. Notasi multiplicity menggunakan kustomisasi Format <Number> <Number1>.. <Number2> <Numbern>.. <Number1>, <Number2> <Number1>, <Number2>.. <Number3> <Number1>.. <Number2>, <Number3>.. <Number4> Tepat Antara Atau Nol Arti Tepat <Number1> atau antara <Number2> dan <Number3> Antara <Number1> dan <Number2> atau antara <Number1> dan <Number2> Paket Paket digunakan untuk mengelompokkan kelas-kelas yang mempunyai kesamaan. Dalam UML, digambarkan sebagai berikut: Package Gambar 5.2. Notasi Paket Modul Praktikum 31

33 Ada beberapa cara mengelompokkan kelas-kelas dalam paket, tetapi bagaimanapun juga, kelas-kelas dapat dikelompokkan dalam paket yang sama tergantung dari keinginan kita sendiri. Salah satu pendekatan yang dapat digunakan adalah berdasarkan stereotype-nya. Dengan pendekatan ini, dapat dibuat satu paket untuk kelas-kelas entitas, dan satu kelas untuk kelas-kelas kontrol. Pendekatan lainnya yang dapat digunakan adalah dengan fungsionalitasnya. Misalnya, kita punya paket Security untuk kelas-kelas yang digunakan menangani keamanan sistem. Akhirnya, dapat digunakan kombinasi dua pendekatan di atas. Paket dapat dibuat bersarang, dimana satu paket mengandung beberapa paket lainnya. Pada level tertinggi, dapat dikelompokkan berdasarkan fungsionalitasnya, kemudian diikuti dengan sub fungsionalitas lainnya atau dengan stereotype-nya. Tutorial Membuat Class Diagram 1. Expand pada Logical View, double klik pada Main. Lalu tambahkan notasi Class pada toolbar, lalu tuliskan nama Class-nya 2. Untuk menambahkan attribute, klik kanan pada Class, lalu pilih New Attribute Modul Praktikum 32

34 3. Untuk menambahkan attribute, bisa juga dengan membuka Specification, dengan cara klik kanan, Open Specification lalu pilih tab Attributes. Pada tab Attributes, klik kanan, lalu pilih insert. 4. Untuk menambahkan Operation atau method, bisa dilakukan seperti menambahkan Attribute. 5. Untuk menambahkan tipe data dari attribute, double klik pada attribute lalu akan muncul windows Class Attribute Specification. Modul Praktikum 33

35 6. Cara lain untuk memberi tipe data pada attribute. Double klik pada Type pada tab Attributes. 7. Pada operasi atau method, kita juga bisa menambahkan parameter file. Buka Specification untuk Circle, pada tab Operations double klik pada Return Value. Modul Praktikum 34

36 LATIHAN MODUL 6 1. Buatlah Class Diagram dari soal yang diberikan! Modul Praktikum 35

37 MODUL 6 STATECHART DIAGRAM Pembahasan dilanjutkan dengan menguji masa hidup sebuah obyek tunggal dari satu kelas. Sebuah obyek dapat mengalami beberapa kondisi, misalnya seorang karyawan dapat mengalami kondisi baru diangkat, dipecat, berada dalam masa percobaan, cuti, atau masa pensiun. Seorang obyek karyawan dapat mempunyai perilaku berbeda di setiap kondisi tersebut. Statechart diagram menunjukkan siklus hidup dari obyek tunggal, dari saat dibuat sampai obyek tersebut dihapus. Diagram ini adalah cara tepat untuk memodelkan perilaku dinamis sebuah kelas. Statechart diagram tidak dibuat untuk setiap kelas, bahkan kadang-kadang untuk suatu proyek sistem informasi tidak menggunakannya sama sekali. Untuk menentukan apakah sebuah kelas mempunyai perilaku dinamis yang signifikan, dilakukan dengan memperhatikan dua hal, yaitu: Attribut. Jika sebuah kelas mempunyai sebuah attribut yang bernama status atau attribut yang mempunyai nilai yang berbeda yang digunakan menyimpan berbagai macam kondisi yang mungkin, maka inilah cara yang baik mempertimbangkan bahwa obyek-obyek dalam sebuah kelas mempunyai perilaku dinamis. Relasi. Cara berikutnya adalah memerikasi relasi dari kelas. Perhatikan multiplicity dalam sebuah relasi nol. Nol menunjukkan bahwa ada obyek-obyek tertentu yang tidak terlibat dalam relasi. Misalnya, relasi antara Dosen dengan Mata Kuliah. Seorang dosen mungkin tidak mengajar dalam semester itu, hal tersebut mungkin disebabkan ia sedang cuti, pensiun atau sedang studi lanjut. Hal tersebut mengindikasikan bahwa obyek di kelas Dosen mempunyai beberapa kondisi atau mempunyai perilaku dinamis. Keadaan (State) Keadaan adalah kondisi yang mungkin dialami oleh suatu obyek. Sebagaimana disebutkan terdahulu bahwa ada dua cara untuk mengidentifikasi kondisi dari obyek Modul Praktikum 36

38 yaitu dengan memeriksa nilai attribut atau dengan memperhatikan relasi terhadap obyek lain. Pemeriksaan nilai attribut status bisa membantu menentukan apa saja kondisi yang dialami oleh obyek. Dalam UML, notasi keadaan digambarkan sebagai berikut : State Gambar 6.1. Notasi State Pada saat suatu obyek di keadaan tertentu, mungkin ada beberapa aktifitas yang berjalan. Sebuah laporan mungkin dibuat, beberapa perhitungan mungkin dilakukan, atau ada kejadian mungkin dikirim ke obyek lainnya. Ada 5 tipe informasi yang bisa disertakan dalam sebuah state, antara lain : aktivitas (activity), aksi masuk (entry action), aksi keluar (exit action), kejadian (event), atau histori keadaan (state history). a. Aktifitas (Activity) Aktifitas adalah perilaku saat obyek tersebut dalam kondisi tertentu. Misalkan, saat account dalam kondisi tertutup, kartu tanda tangan pemegang account ditarik. Saat penerbangan dalam kondisi batal. Perusahaan akan mencoba mencari alternatif penerbangan untuk para langganannya. Aktifitas adalah termasuk perilaku yang mempunyai kemampuan melakukan interupsi (interruptible). Aktifitas terlihat di dalam kondisi itu sendiri, di tunjukkan oleh kata do dan slash (/). Canceled do/ Alternate flight for customer Gambar 6.2. Kondisi dengan aktifitas b. Aksi Masuk (Entry Action) Aksi masuk atau entry action adalah perilaku yang terjadi dimana suatu obyek sedang bertransisi memasuki sebuah keadaan (state). Misalnya, saat Flight Modul Praktikum 37

39 menjadi Scheduled, maka saat itu juga sistem menempatkan jadwak tersebut pada pada internet. Ini terjadi ketika Flight sedang transisi menjadi keadaan Scheduled. Tidak seperti suatu aktifitas, aksi masuk adalah noninterruptible. Ketika penempatan penjadwalan ke internet dilakukan, ia terjadi sangat cepat dan pemakai tidak dapat membatalkan transaksi dengan mudah ketika terjadi. Oleh karena itu, dapat diperagakan sebagai suatu tindakan, dimana ada batas antara suatu aksi dan suatu aktifitas dengan ada tidaknya kemampuan melakukan interupsi. Suatu aksi masuk ditunjukkan dalam sebuah keadaan yang didahului dengan kata entry dan lambang slash ( / ). Scheduled entry/ Post flight schedule on Internet do/ Check current date Gambar 6.3. Kondisi dengan aktifitas aksi masuk c. Aksi Keluar (Exit Action) Aksi keluar atau exit entry hampir sama dengan aksi masuk, aksi keluar terjadi saat bertransisi keluar dari suatu keadaan tertentu. Misalkan, ketika pesawat mendarat dan transisi keluar dari keadaan In Flight, sistem mencatat waktu pendaratan. Sama seperti aksi masuk, aksi keluar juga noninterruptible. Aksi keluar didahului oleh kata exit dan slash ( / ). Scheduled exit/ Record landing time Gambar 6.4. Kondisi dengan aksi keluar Perilaku yang dimuat sebagai aktifitas, aksi masuk, atau aksi keluar dapat meyertakan pengiriman kejadian (event) ke beberapa obyek lain. Transisi Trasnsisi adalah sebuah pergerakan dari suatu keadaan ke keadaan yang lainnya. Kumpulan transisi-transisi pada sebuah diagram, yang memperlihatkan bagaimana Modul Praktikum 38

40 suatu obyek bergerak dari satu keadaan ke keadaan yang lainnya.pada diagram, transisi digambarkan sebagai anak panah dari keadaan sumber ke keadaan tujuan. In Flight exit/ Record landing time Landed Gambar 6.5. Transisi Transisi dapat pula reflexive (ke dirinya sendiri). Jika hal itu terjadi, menyebabkan suatu obyek bergerak balik ke keadaan itu sendiri. Misalkan, pada obyek suatu flight ketika seseorang penumpang ditambahkan atau dibatalkan maka obyek flight tersebut juga masih tetap dalam kondisi yang Open. Transisi reflexive terlihat sebagai anak panah yang berawal dan berakhir pada keadaan yang sama. Open Gambar 6.6. Transisi reflexive Keadaan spesial Ada 2 keadaan spesial yang dapat ditambahkan ke diagram : keadaan mulai (start state) dan keadaan selesai (stop state). Keadaan mulai adalah obyek pertama yang dibuat. Keadaan mulai ditunjukkan dengan lingkaran yan terisi : Gambar 6.7. Keadaan Mulai Keadaan selesai adalah keadaan dimana obyek ketika dihapus/dihancurkan. Keadaan selesai ditunjukkan pada diagram sebagai bull s eye. Keadaan selesai bersifat optional, dan ditambahkan sebanyak mungkin sesuai dengan kebutuhan. Gambar 6.8. Keadaan Selesai Modul Praktikum 39

41 Keadaan Majemuk(Nested History) dan History Keadaan (State History) Untuk mengurangi kerumitan pada diagram, atau karena sebuah keputusan perancangan, kita dapat menggabungkan satu atau beberapa keadaan ke dalam keadaan yang lain. Beberapa keadaan majemuk disebut sebagai substate, sementara keadaan yang lebih besar disebut sebagai superstate. Jika dua atau lebih keadaan memiliki transisi yang identik, maka mereka dapat dikelompokkan bersama-sama ke dalam superstate. Menggunakan state history untuk mengingat dimana obyek berada. Jika opsi History digunakan, sebuah obyek dapat meninggalkan superstate dan kembali lagi, kemudian berada pada posisi yang ditinggalkannya. History option ditunjukkan dengan H kecil dalam lingkaran di sudut diagram. H Gambar 6.9. State History Tutorial Statechart Diagram 1. Untuk membuat Statechart Diagram. Klik kanan pada Logical View folder, pilih yang New / Statechart Diagram. Modul Praktikum 40

42 2. Atau juga bisa melalui, klik kanan pada Class, pilih yang Sub Diagram / New Statechart Diagram. 3. Untuk menambahkan Guard Condition. Double klik pada Transisi, pilih tab detail dan inputkan kondisinya. LATIHAN MODUL 7 1. Buatlah Statechart Diagram dari soal yang diberikan! Modul Praktikum 41

43 MODUL 7 COMPONENT DIAGRAM Component Diagram adalah diagram UML yang menampilkan komponen dalam sistem dan hubungan antara mereka. Pada component view, akan difokuskan pada orgasnisasi fisik sistem. Pertama, diputuskan bagaimana kelas-kelas akan diorganisasikan menjadi kode pustaka. Kemudian akan dilihat bagaimana perbedaan antara berkas eksekusi, berkas dynamic link library (DDL), dan berkas runtime lainnya dalam sistem Tipe-tipe komponen Komponen adalah modul fisik dari kode. Komponen bisa mencantumkan pustaka kode program dan berkas-berkas runtime sekaligus. Misalnya, jika kita menggunakan C++, setiap berkas.cpp dan.h adalah komponen yang berbeda. Berkasberkas.exe yang anda ciptakan setelah kode program di-compile juga termasuk komponen. Sebelum men-generate code, petakan setiap berkas kepada komponen yang tepat. Pada C++, setiap kelas dipetakan ke dua komponen. Satu mewakili berkas.cpp untuk kelas tersebut dan yang lainnya mewakilkan berkas.h. Pada Java, kita petakan setiap kelas ke komponen tunggal, mewakili berkas.java untuk kelas tersebut. Ketika kita membangkitkan kode, rational rose akan menggunakan komponen informasi untuk menciptakan berkas-berkas kode pustaka yang tepat. Ketika komponen sudah tercipta, akan ditambahkan ke diagram komponen dan hubungan yang terjadi antar mereka. Stau-satunya tipe hubungan antar komponen adalah dependensi. Dependensi menyatakan bahwa satu komponen haru s di-compile sebelum yang lainnya. Beberapa tipe komponen sebagai berikut : c. Komponen Notasi-notasi komponen mepresentasikan module perangkat lunak dengan sebuah antar muka yang didefinisikan dengan baik. Pada spesifikasi komponen, kita bisa menspesifikasi tipe komponen pada kolom stereotype (ActiveX, Applet, Aplikasi, DLL, Executable). Dalam UML, notasi keadaan digambarkan sebagai berikut : Modul Praktikum 42

44 Generic Component Gambar 7.1. Notasi Komponen d. Subprogram Specification and Body Notasi ini mempresentasikan spesifikasi subprogram yang terlihat dan bagian implementasi. Subprogram secara tipikal adalah kumpulan beberapa subroutine. Subprogram tidak berisi definisi kelas. NewSubprogSpec NewSubprogBody Gambar 7.2. Notasi subprogram specification dan subprogram body e. Main Program Notasi ini mepresentasikan program utama. Program utama adalah berkas yang berisi root program. Contoh, pada Power Builder, ada berkas yang berisi obyek aplikasi. MainProgram Gambar 7.3. Notasi Mainprogram f. Package Specification and Body Sebuah paket atau package adalah implementasi kelas. Sebuah paket spesifikasi adalah berkas header, yang berisi informasi fungsi prototype untuk kelas. Di C++, spesifikasi paket adalah berkas.h. Di Java, kita menggunakan notasi paket spesifikasi untuk mepresentasikan berkas.java. Sebuah package Modul Praktikum 43

45 body berissi kode untuk operasi-operasi dari kelas. Di C++, package body adalah berkas.cpp. PackageSpec PackageBody Gambar 7.4. Notasi package specification dan package body Ada notasi tambahan yang digunakan untuk komponen runtime termasuk berkas-berksa executable, berkas DLL, dan beberapa berkas task lainnya. g. Task Specification and Body Notasi-notasi ini mempresentasikan paket yang memiliki thread kontrol yang berdiri sendiri. Berkas executable biasanya mempresentasikan spesifikasi task dengan ekstensi.exe. TaskSpecification TaskBody Gambar 7.5. Notasi Task Specification dan Task body h. Database Notasi ini mempresentasikan sebuah basis data, yang berisi satu atau beberapa skema. Pada komponen diagram, basis data ditunjukkan seperti : 7.2. Detail Komponen Ada sejumlah detail spesifikasi yang bisa ditambahkan ke setiap komponen. Ini termasuk stereotype, bahasa, deklarasi, dan kelas-kelas. Stereotype Stereotype mengatur notasi yang akan digunakan untuk mempresentasikan komponen. Stereotype adalah <none> (yang menggunakan notasi komponen), Modul Praktikum 44

46 spesifikasi subprogram, subprogram body, program utama, paket spesifikasi, package body, executable, DLL, spesifikasi task, dan task body. Rose memasukkan sejumlah stereotype yang lain untuk bahasa pemrograman yang berneda. Stereotype bahasa pemrograman lainnya, dapat dilihat pada tabel : Tabel 7.1. Stereotype beberapa bahasa pemrograman Bahasa Pemrograman Stereotype Java EJBDeploymentDescriptor, EJB JAR, ServletDeploymentDescriptor, dan WAR Oracle 8 Database, Schema Visual Basic ActiveX Control Kita dapat menambahkan stereotype tambahan jika ingin mempresentasikan tipe komponen baru pada bahasa pemrograman yang akan digunakan. Bahasa Pemrograman Kita dapat menandai bahasa pemrograman pada komponen-komponen dasar. Jadi, dapat dibangkitkan satu bagian model di C++, bagian lainnya di Java, bagian lainnya di Visual Basic dan sebagainya. Rose Enterprise berisi tambahan untuk ANSI C++, Ada 83, Ada 95, CORBA, C++, Java, Visual Basic, Visual C++, Web Modeler, XML/DTD, dan Oracle 8. Ada banyak lagi tambahan tersedia dari beberapa vendor untuk memperluas kemampuan Rose. Untuk bahasa pemrograman lain (Power Builder, Forte, Visual Age for Java, etc) mungkin akan dipesan juga. Deklarasi Ada bagian untuk mencantumkan dekalarasi pelengkap yang akan ditambahkan pada saat generate code untuk setiap komponen. Deklarasi termasuk bahasa pemrograman pernyataan spesifik yang digunakan untuk mendeklarasikan variabel, kelas-kelas, dan sebagainya. Pernyataan #include pada C++ juga termasuk deklarasi ini. Modul Praktikum 45

47 Kelas kelas Sebelum men-generate code untku sebuah kelas, maka harus dipetakan dulu ke komponen. Pemetaan ini membantu rose mengetahui kelas-kelas mana saja yang akan dipetakan dalam berkas fisik kode. Gambar 7.6. Kelas-kelas yang sudah dipetakan ke komponen Mhs Kita dapat memetakan satu atau beberapa kelas untuk tiap-tiap komponen. Setelah dilakukan pemetaan satu atau beberapa kelas ke komponen, maka nama komponen akan tampil setelah nama kelas dengan tanda [ ] di logical view Dependensi Komponen Hanya ada satu tipe relasi antar komponen yaitu dependensi. Dependensi menyatakan bahwa satu komponen bergantung pada lainnya. Sebuah dependensi komponen digambarkan seperti panah putus-putus antara 2 komponen. Component A Component B Gambar 7.7. Dependensi komponen Pada contoh ini, komponen A bergantung pada komponen B. Dengan kata lain, ada satu atau beberapa kelas di A yang bergantung pada satu atau beberapa kelas di B. Dependensi memiliki implikasi kompilasi, dimana komponen A tergantung pada komponen B, A tidak bisa di-compile sampai B telah selesai di-compile. Seseorang Modul Praktikum 46

48 yang membaca diagram ini akan mengetahui bahwa B harus di-compile terlebih dahulu, dilanjutkan dengan A. Bagaimana jika terjadi dependensi memutar (circular dependency)?. Jika terjadi hal tersebut, komponen A bergantung pada komponen B, dan komponen B bergantung pada komponen A, maka komponen A atau B tidak dapat di-compile sampai salah satu di-compile. Salah satu penyelesaian yang tepat untuk hal tersebut adalah menjadikan keduanya komponen yang lebih besar. Cara lain yang dianjurkan adalah memecah salah satu komponen yang leabih besar. Cara lain yang dianjurkan adalah memecah salah satu komponen menjadi dua komponen dimana dependensi memutar dihapuskan. Apapun solusi yang diambil, yang jelas adalah bahwa semua dependensi memutar harus dihapuskan sebelum generate code dilakukan. Tutorial Component Diagram 1. Expand Component view. Double klik pada Main. Gunakan tolbar untuk menambahkan paket-paket yang didalamnya terdapat komponen-komponen sistem. Modul Praktikum 47

49 2. Untuk melihat Component Specification, double klik pada use case. 3. Tab Realizes, untuk melihat detil dari paket pada Logical View LATIHAN MODUL 7 1. Buatlah Component Diagram dari soal yang diberikan! Modul Praktikum 48

50 MODUL 8 DEPLOYMENT DIAGRAM Deployment View adalah pandangan yang berkait dengan penyebaran fisik aplikasi. Hal ini termasuk persoalan layout jaringan dan lokasi komponen-komponen dalam jaringan. Deployment View berisikan prosesor-prosesor, peralatan-peralatan, proses-proses dan hubungan antar prosesor dan antar peralatan. Semua informasi ini digambarkan dalam suatu Deployment Diagram. Hanya ada satu Deployment Diagram dalam setiap sistem, sehingga hanya satu Deployment Diagram dalam setiap model. Suatu Deployment Diagram menampilkan semua titik (node) dalam suatu jaringan,hubungan antar mereka, dan proses-proses yang dijalankan pada masingmasing node. Prosesor Prosesor adalah suatu mesin yang mempunyai kekuatan pemrosesan. Server, workstation, dan mesin-mesin lainnya yang digunakan pemrosesan semuanya masuk dalam kategori ini. Dalam UML, notasi prosesor digambarkan sebagai berikut : Processor Gambar 8.1. Notasi Prosesor Pada spesifikasi prosesor, dapat ditambahkan informasi tentang stereotype prosesor, karakteristik, dan penjadwalan. Stereotype, sebagaimana dalam elemen model lainnya, dapat digunakan mengklasifikasikan prosesor. Misalnya, kita memiliki beberapa mesin UNIX dan beberapa mesin PC. Dan jika diinginkan untuk mengelompokkan antara keduanya, maka digunakan stereotype. Karakteristik prosesor adalah deskripsi secara fisik dari sebuah prosesor. Misalnya kita ingin meyertakan kecepatan prosesor atau jumlah memori yang digunakan. Modul Praktikum 49

51 Bagian penjadwalan mendokumentasikan tipe proses penjadwalan yang digunakan oleh sebuah prosesor. Beberapa pilihan adalah sebagai berikut : Preemptive. Menunjukkan bahwa sebuah prosesor yang mempunyai prioritas lebih tinggi dapat menduduki sebuah proses yang mempunyai prioritas yang lebih rendah. Non-Preemptive. Menunjukkan bahwa sebuah prosesor tidak memiliki prioritas. Proses aktif mengeksekusi hingga selesai, dan proses berikutnya dilakukan. Cyclic. Menunjukkan pengaturan berputar antar proses, dimana setiap proses mendapatkan alokasi waktu untuk dieksekusi, dan kemudian ke proses berikutnya secara bergantian. Executive. Menunjukkan ada beberapa urutan algoritma komputasi untuk mengontrol penjadwalan. Maual. Menunjukkan proses yang telah dijadwalkan oleh pemakai. Peralatan (device) Peralatan (device) adalah perangkat keras dengan tujuan tunggal atau maksud yang tertentu. Yang termasuk dalam kategori ini antara lain : dumb terminal, printer, dan scanner. Kedua-duanya yaitu prosessor-prosessor dan peralatan-peralatan dapat dianggap sebagai tiitk (node) dalam suatu jaringan. Pada UML, notasi peralatan digambarkan sebagai berikut : Device Gambar 8.2. Notasi Peralatan Sebagaimana prosessor, detail juga dapat ditambahkan pada suatu peralatan. Pertama adalah stereotype, yang digunakan untuk membagi peralatan ke dalam kelompok-kelompok tertentu. Kedua adalah, karakteristik, adalah penjelasan secara fisik mengenai sebuah peralatan, sebagaimana karakteristik pada prosesor. Koneksi Modul Praktikum 50

52 Koneksi adalah suatu hubungan (link) secara fisik antara dua prosessor, dua peralatan, atau antara prosessor dan peralatan. Umumnya, hubungan-hubungan tersebut memacu pada hubungan jaringan fisik (the physical network connection) antara titik-titik pada jaringan. Koneksi juga bisa berarti hubungan internet antara dua buah titik. Koneksi dapat ditandai dengan beberapa stereotype. Koneksi dapat diberikan karakteristik-karakteristik, yang menjelaskan detail fisik sebuah koneksi. Contoh, suatu koneksi bisa ditandai dengan TI line. Proses Sebuah proses adalah thread tunggal dari eksekusi yang berjalan pada sebuah prosessor, berkas executable adalah sebuah contoh proses. Ketika menambahkan proses ke dalam diagram, berfokus hanya pada proses yang berhubungan ke sistem yang sedang dibuat. Proses-proses bisa ditampilkan pada Deployment Diagram atau tersembunyi dari tampilan. Jika ia ditampilkan, maka didaftar langsung dibawah prosesor di mana ia dijalankan. Proses-proses bisa ditentukan prioritasnya. Jika prosesor yang dijalankan menggunakan penjadwalan preemptive, prioritas dari proses akan menentukan ketika sedang berjalan. Tutorial Deployment Diagram 1. Double klik pada Deployment View, lalu tambahkan prosesor, peralatan dan relasi diantaranya. Modul Praktikum 51