76559025 Modul Penggunaan Rational Rose

Modul Penggunaan Rational Rose Program Studi Sistem Informasi, Fakultas Teknik, Universitas Muria Kudus

Modul Praktikum Rekayasa Perangkat Lunak 1

MODUL I PENGENALAN TOOL RATIONAL ROSE 2000

1. Tujuan Praktikum o Praktikan mengenal tentang Unified Modelling Language (UML) o Praktikan mengenal Rational Rose 2000 sebagai perangkat lunak untuk

pemodelan UML.

2. Dasar Teori 2.1. Pengenalan UML

UML (Unified Modeling Language) merupakan pengganti dari metode analisis berorientasi object dan design berorientasi object (OOA&D) yang dimunculkan sekitar akhir tahun 80-an dan awal tahun 90-an. UML merupakan gabungan dari metode Booch, Rumbaugh (OMT) dan Jacobson. Tetapi UML ini akan mencakup lebih luas daripada OOA&D. Pada pertengahan pengembangan UML dilakukan standarisasi proses dengan OMG (Object Management Group) dengan harapan UML akan menjadi bahasa standar pemodelan pada masa yang akan datang. UML disebut sebagai bahasa pemodelan bukan metode. Kebanyakan metode terdiri paling sedikit prinsip, bahasa pemodelan dan proses. Bahasa pemodelan (sebagian besar grafik) merupakan notasi dari metode yang digunakan untuk mendesain secara cepat.

Bahasa pemodelan merupakan bagian terpenting dari metode. Ini merupakan bagian kunci tertentu untuk komunikasi. Jika anda ingin berdiskusi tentang desain dengan seseorang, maka Anda hanya membutuhkan bahasa pemodelan bukan proses yang digunakan untuk mendapatkan desain. UML merupakan bahasa standar untuk penulisan blueprint software yang digunakan untuk visualisasi, spesifikasi, pembentukan dan pendokumentasi-an alat-alat dari sistem perangkat lunak.

2.2. Pengertian UML UML adalah bahasa untuk menspesifikasi, memvisualisasi, membangun

dan mendokumentasikan artifacts (bagian dari informasi yang digunakan atau dihasilkan oleh proses pembuatan perangkat lunak, artifact tersebut dapat berupa model, deskripsi atau perangkat lunak) dari sistem perangkat lunak, seperti pada pemodelan bisnis dan sistem non perangkat lunak lainnya.

Selain itu UML adalah bahasa pemodelan yang menggunakan konsep orientasi object. UML dibuat oleh Grady Booch, James Rumbaugh, dan Ivar Jacobson di bawah bendera Rational Software Corp. UML menyediakan notasi-notasi yang membantu memodelkan sistem dari berbagai perspektif. UML tidak hanya digunakan dalam pemodelan perangkat lunak, namun hampir dalam semua bidang yang membutuhkan pemodelan.

2.3. Bagian-Bagian UML Bagian-bagian utama dari UML adalah view, diagram, model element, dan

general mechanism.



A. View View digunakan untuk melihat sistem yang dimodelkan dari beberapa

aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram. Beberapa jenis view dalam UML antara lain:

a. Use case view Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya. View ini digambarkan dalam use case diagrams dan kadang-kadang dengan activity diagrams. View ini digunakan terutama untuk pelanggan, perancang (designer), pengembang (developer), dan penguji sistem (tester).

b. Logical view Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object, dan relationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu. View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence, collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk perancang (designer) dan pengembang (developer).

c. Component view Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administrative lainnya. View ini digambarkan dalam component view dan digunakan untuk pengembang (developer).

d. Concurrency view Membagi sistem ke dalam proses dan prosesor. View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

e. Deployment view Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana hubungannya dengan lainnya. View ini digambarkan dalam deployment diagrams dan digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

B. Diagram Diagram berbentuk grafik yang menunjukkan simbol elemen model yang

disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. Adapun jenis diagram antara lain :

a. Use Case Diagram Menggambarkan sejumlah external actors dan hubungannya ke use case yang diberikan oleh sistem. Use case adalah deskripsi fungsi yang



disediakan oleh system dalam bentuk teks sebagai dokumentasi dari use case symbol namun dapat juga dilakukan dalam activity diagrams. Use case digambarkan hanya yang dilihat dari luar oleh actor (keadaan lingkungan sistem yang dilihat user) dan bukan bagaimana fungsi yang ada di dalam sistem.

b. Class Diagram Menggambarkan struktur statis class di dalam sistem. Class merepresentasikan sesuatu yang ditangani oleh sistem. Class dapat berhubungan dengan yang lain melalui berbagai cara: associated (terhubung satu sama lain), dependent (satu class tergantung/menggunakan class yang lain), specialed (satu class merupakan spesialisasi dari class lainnya), atau package (grup bersama sebagai satu unit). Sebuah sistem biasanya mempunyai beberapa class diagram.

c. State Diagram Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa object lain yang mengirim pesan. State class tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh state yang berbeda.

d. Sequence Diagram Menggambarkan kolaborasi dinamis antara sejumlah object. Kegunaanya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antara object, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem.

e. Collaboration Diagram Menggambarkan kolaborasi dinamis seperti sequence diagrams. Dalam menunjukkan pertukaran pesan, collaboration diagrams menggambarkan object dan hubungannya (mengacu ke konteks). Jika penekannya pada waktu atau urutan gunakan sequence diagrams, tapi jika penekanannya pada konteks gunakan collaboration diagram.

f. Activity Diagram Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use case atau interaksi.

g. Component Diagram Menggambarkan struktur fisik kode dari komponent. Komponent dapat berupa source code, komponen biner, atau executable component. Sebuah komponent berisi informasi tentang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view.

h. Deployment Diagram Menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak sistem, menunjukkan hubungan komputer dengan perangkat (nodes) satu



sama lain dan jenis hubungannya. Di dalam nodes, executeable component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.

2.4. Tujuan Penggunaan UML - Memodelkan suatu sistem (bukan hanya perangkat lunak) yang

menggunakan konsep berorientasi object. - Menciptakan suatu bahasa pemodelan yang dapat digunakan baik oleh

manusia maupun mesin.

Pemakaian UML dalam bidang-bidang kehidupan antara lain: - Sistem Informasi Perusahaan - Sistem Perbankan dan Perekonomian - Bidang Telekomunikasi - Bidang Transportasi - Bidang Penerbangan - Bidang Perdagangan - Bidang Pelayanan Elekronik - Bidang Pengetahuan - Bidang Pelayanan Berbasis Web Terdistribusi

2.5. Pengenalan Rational Rose Rational Rose merupakan salah satu software yang digunakan untuk

pemodelan UML atau pemodelan visual untuk pengembangan sistem berbasis objek. Rational Rose digunakan untuk melakukan pemodelan sistem sebelum pengembang menulis kode-kode dalam bahasa pemrograman.



2.6. Penjelasan Rational Rose

Jendela Browser Menu-Menu Jendela Diagram

Jendela Dokumentasi Toolbar Jendela Log

Penjelasan: - Jendela Browser berfungsi untuk secara cepat bergerak dalam model

dimana segala sesuatu (aktor, use case, kelas, objek, komponen) dapat ditambahkan dalam model dan ditampilkan dalam jendela browser. Selain itu didalam jendela browser dapat dilihat ada 4 tampilan (view), yaitu Use Case View, Logical View, Component View, dan Deployment View. Didalam setiap view terdapat unsur-unsur sebagai berikut: 1. Use Case View

Aktor-aktor Use Case Asosiasi



Diagram Use Case Dokumentasi Use Case Activity Diagram Sequence Diagram Collaboration Diagram Realization Diagram Paket (Package)

2. Logical View Kelas-kelas Diagram Class Asosiasi Antarmuka (interface) Sequence Diagram Collaboration Diagram Statechart Diagram Paket (Package)

3. Component View Komponen-komponen Antarmuka (interface) Component Diagram Paket (Package)

4. Deployment View Proses-proses Prosesor-prosesor Penghubung (conectors) Piranti-piranti (devices) Deployment Diagram

- Jendela Diagram berfungsi untuk membuat, menampilkan (display), serta meng-edit satu atau lebih diagram UML.

Gambar 1.2. Contoh tampilan Jendela Diagram



- Jendela Dokumentasi berguna untuk melihat atau meperbaharui (update) dokumentasi unsur-unsur model. Didalam jendela ini juga dapat dituliskan definisi singkat untuk masing-masing aktor serta use case yang digunakan. Jika unsur-unsur dalam jendela browser dipilih maka jendela dokumentasi akan secara otomatis diperbaharui untuk menampilkan dokumentasi tentang unsur-unsur yang dipilih.

- Jendela Log berfungsi untuk melihat kesalahan-kesalahan (error) dan melaporkan (report) hasil-hasil dari berbagai perintah yang diberikan pada Rational Rose.

- Menu-menu berfungsi untuk mengaktifkan perintah-perintah tertentu. - Toolbar berfungsi untuk mengakses perintah-perintah yang sering

digunakan. Diantaranya sebagai berikut:

Ikon Nama Button Fungsi

Create New Model Menciptakan model baru (berkas .mdl)

Open Existing Model Membuka berkas model yang telah disimpan

Save Model or Log Menyimpan berkas model atau berkas log

Print Diagram Mencetak satu atau lebih diagram

View Documentation Menampilkan jendela dokumentasi Browse Class

Diagram Melokalisasi dan membuka diagram class

Browse Interaction Diagram

Melokalisasi dan membuka sequence atau collaboration diagram

Browse Component Diagram

Melokalisasi dan membuka component diagram

Browse State Machine Diagram

Melokalisasi dan membuka statechart diagram

Browse Deployment Diagram

Melokalisasi dan membuka deployment diagram

Browse Parent Membuka diagram induk Browse Previous

Diagram Membuka diagram sebelumnya

3. Langkah Praktikum 3.1. Membuat File Baru

1. Jalankan software Rational Rose 2000 Enterprise Edition. 2. Klik File New, maka akan muncul jendela seperti dibawah ini:



Gambar 1.3. Framework Wizard

Gambar diatas ini menunjukkan beberapa pilihan jika diinginkan untuk membuat model yang kelak akan menghasilkan kode-kode program dalam bahasa tertentu seperti Visual Basic, C++ atau Java. Tetapi jika hanya ingin membuat model yang sifatnya umum maka pilih Cancel.

3.2. Menyimpan File 1. Kemudian simpan file yang baru ini dengan nama Latihan1.mdl di

folder directory anda. 2. Perlu diperhatikan!!! Setiap kali anda membuat file dalam praktikum

ini harap disimpan dalam

3.3. Mempublikasikan File melalui Internet 1. Apabila diinginkan untuk berbagi berkas diagram-diagram yang telah

dibuat, Anda juga dapat mempublikasikan diagram-diagram tersebut melalui sarana internet. Dengan cara:

2. Klik Tool Web Publisher, maka akan muncul jendela seperti dibawah ini:



Gambar 1.4. Tampilan untuk publish diagram

3. Kemudian Klik tombol browse pada HTML Root File Name, kemudian simpan file dengan nama Latihan1 didalam folder Modul 1 (Tetapi sebelumnya buatlah folder Modul 1 dalam folder directory anda).

4. Kemudian klik tombol Publish, secara otomatis akan terbuat file tipe html dalam folder Modul 1. Data yang tersimpan terdiri dari 5 buah folder dan 7 file.

5. Buka windows eksplorer untuk melihat hasil publish, klik double pada file Latihan1.htm.

3.4. Menambah File atau URL pada Model dan Menghapusnya 1. Untuk menggabungkan sebuah file misalnya file dari Microsoft Word atau

URL yang berhubungan dengan model yang dibuat dengan cara: 2. Klik kanan pada unsur yang ada di jendela browser. 3. Pilih New File atau New URL. 4. Pilih file atau URL yang akan digabungkan. 5. Setelah file atau URL dilampirkan, klik ganda pada browser untuk

membukanya. 6. Untuk menghapus file atau URL yang dilampirkan, klik kanan file atau

URL yang akan dihapus pada browser dan pilih Delete.

3.5. Menambah atau Menghapus Diagram 1. Untuk menambah diagram yang baru, klik kanan pada browser.

Misalnya use case view.



2. Kemudian pilih New Pilih Diagram yang baru (misalnya Class Diagram).

3. Untuk menghapus diagram, klik kanan pada diagram yang akan dihapus pada jendela browser, pilih Delete.

3.6. Kasus yang akan dipelajari dalam Praktikum Berikut ini adalah contoh dari sebuah studi kasus yang menangani Aplikasi

Belanja Online bebasis Web dengan skenario sebagai berikut:

Sebuah toko buku mempunyai website yang digunakan untuk pembelian buku secara online lewat internet. Pelanggan dapat membeli buku lewat halaman web tersebut.

Pelanggan harus terdaftar terlebih dahulu sebelum bisa memasuki halaman pemesanan. Setelah terdaftar pelanggan melakukan proses login dan kemudian dapat memilih buku-buku yang diinginkan beserta daftar harga dan stok yang tersisa.

Ketika sudah memilih buku yang akan dipesan secara otomatis akan terhitung jumlah harga yang harus dibayar. Setelah pelanggan yakin dengan pesanannya maka pelanggan melakukan proses persetujuan pembelian. Persetujuan meliputi batas pembayaran 1 x 24 jam dan nomor pesanan serta info pembayaran. Ketika setuju secara otomatis sistem akan mengirimkan email kepada pelanggan tersebut yang berisi daftar detail barang yang dipesan dan nomor pesanan dan info pembayaran meliputi nomor rekening untuk transfer uang sesuai harga total. Dan status pemesanan akan diset menjadi PESAN.

Dalam batas 1 x 24 jam pelanggan harus transfer uang sesuai total harga pemesanan untuk setiap nomor order, dan mengirim konfirmasi lewat SMS dengan format NO_ORDER NO_SLIP_TRANSFER. Jika dalam batas 1 x 24 jam belum mentransfer uang maka pemesanan otomatis dibatalkan dan data dikembalikan ke dalam stok.

Setelah konfirmasi dari pelanggan sampai serta uang sudah ditransfer, maka toko akan mengirimkan barang ke alamat pelanggan dan merubah status pemesanan menjadi KIRIM serta sistem secara otomatis mengirimkan email sebagai tanda pengiriman barang sudah dilakukan.



MODUL II USE CASE DIAGRAM

1. Tujuan Praktikum o Praktikan mengenal tentang Use Case Diagram o Praktikan dapat membuat Use Case Diagram o Praktikan mengimplementasikan Use Case Diagram pada kasus pada

modul sebelumnya

2. Dasar Teori 2.1. Pengertian Use Case Diagram

Use case Diagram adalah Diagram deskripsi fungsi dari sebuah sistem dari perspektif pengguna. Use case Diagram bekerja dengan cara mendeskripsikan tipikal interaksi antara user (pengguna) sebuah sistem dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai. Urutan langkah-langkah yang menerangkan antar pengguna dan sistem disebut skenario. Setiap skenario mendeskripsikan urutan kejadian. Setiap urutan diinisialisasi oleh orang, sistem yang lain, perangkat keras atau urutan waktu. Selain itu Use Case juga diartikan sebagai abstraksi dari interaksi antara system dan actor.

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah apa yang diperbuat sistem, dan bukan bagaimana. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.

2.2. Kebutuhan Dasar / Fungsi Sistem Kebutuhan dasar /fungsi sistem adalah fungsionalitas apa yang mesti

disediakan oleh sistem, yang mana akan didokumentasikan sebagai use case yang menggambarkan fungsi sistem yang diharapkan. Atau yang lebih dikenal dengan Use Case Rule. Use Case Rule ini terdiri dari beberapa aktifitas yang dapat dijalankan sistem.

Sebagai contoh proses pemesanan barang oleh pelanggan dalam kasus dimodul sebelumnya, sebelum memesan pelanggan harus sudah terdaftar sebagai anggota.

2.3. Tujuan Penggunaan Use Case Diagram Digunakan sebagai alat bantu terbaik guna menstimulasi pengguna

potensial untuk mengatakan tentang sistem dari sudut pandangnya. Use Case mewakili pandangan di luar sistem.

Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem.



2.4. Komponen-komponen yang terlibat dalam use case diagram a. Notasi Use Case

Diagram Use Case menunjukkan 3 aspek dari sistem yaitu: actor, use case, dan sistem/sub sistem boundary. Aktor mewakili peran orang, sistem yang lain atau alat ketika berkomunikasi dengan use case.

Gambar 2.1. Notasi Aktor Gambar 2.2. Notasi Use case

Gambar 2.3. Notasi Kelas Boundary

b. Actor Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.

Gambar 2.4. Actor

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



Aktor Use case

Association

Toko (Pemilik)(f rom Use Case View)

Pelanggan(f rom Use Case View)

Gambar 2.5. Actor

Ada beberapa kemungkinan yang menyebabkan actor tersebut terkait dengan sistem antara lain: Yang berkepentingan terhadap sistem dimana adanya arus informasi

baik yang diterimanya maupun yang dia inputkan ke sistem. Orang ataupun pihak yang akan mengelola sistem tersebut. Sistem lain yang berinteraksi dengan sistem yang akan dibuat.

c. Cara menentukan Use Case dalam suatu sistem: Pola perilaku perangkat lunak aplikasi. Gambaran tugas dari sebuah actor. Sistem atau benda yang memberikan sesuatu yang bernilai kepada

actor. Apa yang dikerjakan oleh suatu perangkat lunak (* bukan bagaimana

cara mengerjakannya.).

Sistem Belanja Onl ine(from Use Case View)

Gambar 2.6. UseCase

d. Relasi dalam Use Case Relationship atau relasi merupakan hubungan antar elemen. Ada beberapa relasi yang terdapat pada use case diagram: 1. Association, menghubungkan link antar element.

Gambar 2.7. Notasi Association Relationship

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



Package2 Package3dependency

Aktor

Aktor A

Aktor B

generalization

generalization

Gambar 2.8. Notasi Generalization Relationship

3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.

Gambar 2.9. Notasi Dependency Relationship

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

Tipe relasi/ stereotype yang mungkin terjadi pada use case diagram: 1. , yaitu kelakuan yang harus terpenuhi agar sebuah

event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.

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

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

3. Langkah Praktikum 3.1. Menganalisa kasus yang ada - Dari kasus yang ada dapat disimpulkan beberapa kebutuhan dasar/fungsi

sistem: 1. Pelanggan melakukan registrasi yang mengisikan profil serta alamat

penagihan, yang kemudian akan mendapatkan kode member. 2. Pelanggan harus melakukan proses login terlebih dahulu untuk masuk

dalam halaman pemesanan, setelah masuk pelanggan memilih buku yang akan dipesan. Setelah yakin dengan pesanannya, pelanggan akan



melakukan proses persetujuan pembelian yang berisi batas pembayaran (1x24 jam) serta info pembayaran dan nomor order pemesanannya dan sistem akan mengurangi stok barang yang dipesan dan status pemesanan menjadi PESAN.

3. Sistem secara otomatis mengirimkan email kepada pelanggan yang berisi daftar detail barang yang dipesan, harga yang harus dibayar info pembayaran dan nomor rekening untuk pembayaran serta batas pembayaran.

4. Dalam batas pembayaran (1x24 jam) pelanggan harus transfer uang ke rekening toko sesuai pesanan setiap nomo order dan mengirim SMS dengan format NO_ORDER NO_SLIP_TRANSFER. Jika dalam batas pembayaran belum transfer maka pesanan akan dibatalkan dan stok dikembalikan.

5. Setelah transfer dan konfimasi sampai maka toko akan mengirimkan barang dan sistem secara otomatis mengirimkan email yang berisi data pengiriman serta mengubah status pemesanan menjadi KIRIM.

- Dari hasil analisa diatas dapat disimpulkan bahwa kasus tersebut terdiri dari dua (2) actor, yaitu: 1. Pelanggan 2. Pemilik (Toko)

- Dari hasil analisa diatas dapat disimpulkan bahwa kasus tersebut terdiri dari use case, yaitu:

No Requirement Actor Use Case 1 Pelanggan melakukan registrasi yang

mengisikan profil serta alamat penagihan, yang kemudian akan mendapatkan kode member.

Pelanggan Registrasi Member

2 Pelanggan harus melakukan proses login terlebih dahulu untuk masuk dalam halaman pemesanan, setelah masuk pelanggan memilih buku yang akan dipesan. Setelah yakin dengan pesanannya, pelanggan akan melakukan proses persetujuan pembelian yang berisi batas pembayaran (1x24 jam) serta info pembayaran dan nomor order pemesanannya dan sistem akan mengurangi stok barang yang dipesan dan status pemesanan menjadi PESAN.

Pelanggan Pemesanan, Login

3 Sistem secara otomatis mengirimkan Pelanggan Pemesanan,



email kepada pelanggan yang berisi daftar detail barang yang dipesan, harga yang harus dibayar info pembayaran dan nomor rekening untuk pembayaran serta batas pembayaran.

Pengiriman Informasi

4 Dalam batas pembayaran (1x24 jam) pelanggan harus transfer uang ke rekening toko sesuai pesanan setiap nomor order dan mengirim SMS dengan format NO_ORDER NO_SLIP_TRANSFER. Jika dalam batas pembayaran belum transfer maka pesanan akan dibatalkan dan stok dikembalikan.

Pelanggan, Toko

Pembayaran, Transfer

5 Setelah transfer dan konfimasi sampai maka toko akan mengirimkan barang dan sistem secara otomatis mengirimkan email yang berisi data pengiriman serta mengubah status pemesanan menjadi KIRIM.

Toko, Pelanggan

Pembayaran, Pengiriman Barang

- Beberapa skenario terkait use case diatas, yaitu: 1. Use Case : Registrasi member

Actor : Pelanggan Tujuan : Pelanggan mendaftar menjadi member

2. Use Case : Pemesanan Actors : Pelanggan Tujuan : Pemesanan barang yang diinginkan

ACTOR SISTEM 1. Pelanggan login menggunakan kode member yang telah dimiliki

2. Sistem menverifikasi proses login pelanggan. 3. Sistem memperbolehkan pelanggan memasuki halaman pemesanan.

ACTOR SISTEM 1. Pelanggan membuka website. 2. Pelanggan memasukkan data pribadi dan alamat penagihan

3. Sistem mengecek keabsahan data pelanggan. 4. Sistem memberikan kode member



4. Setelah login pelanggan dapat memilih barang yang akan dipesan.

5. Sistem mengecek jumlah stok barang yang akan dipesan. 6. Sistem menghitung total harga pembelian.

7. Pelanggan melakukan proses pemesanan dengan menyetujui persetujuan pembelian

8. Sistem memberikan nomor order kepada pelanggan dan mengubah status jadi PESAN 9. Sistem mengurangi stok barang yang telah dipesan pelanggan 10. Sistem secara otomatis mengirim email sebagai informasi pemesanan kepada pelanggan

3. Use Case : Pembayaran Actors : Pelanggan, Toko Tujuan : Pelanggan mentransfer uang untuk pemesanan

ACTOR SISTEM 1. Pelanggan melakukan transfer uang ke rekening toko 2. Pelanggan mengirim SMS sebagai konfirmasi transfer uang dengan format NO_ORDER NO_SLIP_TRANSFER.

3. Sistem akan menerima konfirmasi dan melakukan pengecekan tentang transfer dengan toko. 4. Sistem merubah status pemesanan menjadi KIRIM dan toko akan mengirimkan barang.

3.2. Membuat Use Case Diagram dari kasus yang ada 3.2.1. Membuat actor pada Rasional Rose 2000 dan Menghapusnya

1. Klik kanan pada Use Case View package di browser. 2. Pilih New Actor pada menu option . Sebuah actor baru bernama New

class ditempatkan di browser.



Pelanggan Pengunjung

3. Pilih actor New class, lalu masukkan nama yg diinginkan untuk actor tersebut Misal :

4. Untuk menghapus Actor klik kanan pada actor yang akan dihapus pilih Delete.

3.2.2. Mendokumentasikan actors 1. Jika documentation window belum terlihat, buka dengan memilih

Documentation menu dari View menu. 2. Klik untuk memilih Actor di browser. 3. Tempatkan cursor di documentation window, lalu ketikkan dokumentasi

yang diinginkan.

3.2.3. Membuat Use Case dan Menghapus Use Case 1. Klik kanan Use Case View pada browser. 2. Pada menu option pilih New Use Case. Sebuah Use Case ditempatkan

pada browser. 3. Klik Use Case tersebut, lalu masukkan nama yang diinginkan.

Toko



Pemesanan

Pembayaran

Pengiriman Barang

Pengiriman Informasi

TransferRegistrasi Member

Login

4. Untuk menghapus Use Case, klik kanan pada Use Case yang akan duhapus lalu pilih Delete.

3.2.4. Membuat Use Case Diagram Utama 1. Klik kanan Main diagram pada Use Case View di browser untuk membuka

diagram. 2. Klik actor di browser dan tarik actor ke dalam diagram. 3. Ulangi langkah 2 untuk menambahkan actor yang diperlukan dalam

diagram. 4. Klik untuk memilih sebuah use case di browser dan tarik use case ke

dalam diagram. 5. Ulangi langkah 4 untuk menambahkan use case yang diperlukan dalam

diagram.

Pengiriman InformasiPengiriman Barang

Pelanggan

Transfer

Toko

Pemesanan

PembayaranLogin

6. Jangan lupa simpan file ini dalam directory anda.

Catatan: actor dan use cases dapat juga langsung diciptakan dalam sebuah use case diagram dengan menggunakan toolbar.



NewClassname

opname()

MODUL III CLASS DIAGRAM

1. Tujuan Praktikum o Praktikan mengenal tentang Class Diagram o Praktikan dapat membuat Class Diagram o Praktikan mengimplementasikan Class Diagram pada kasus yang ada

2. Dasar Teori 2.1. Pengertian Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metode/fungsi).

Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

Class memiliki tiga area pokok : o Nama (dan stereotype) o Atribut o Metode

Atribut dan metoda dapat memiliki salah satu sifat berikut : o Private, tidak dapat dipanggil dari luar class yang bersangkutan o Protected, hanya dapat dipanggil oleh class yang bersangkutan dan

anak-anak yang mewarisinya o Public, dapat dipanggil oleh siapa saja

Gambar 3.1 Class

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.

2.2. Hubungan Antar Class Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan

class yang memiliki atribut berupa class lain, atau class yang harus



mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. (Direpresentasikan dalam bentuk garis penghubung)

Agregasi, yaitu hubungan yang menyatakan bagian (terdiri atas..). Digambarkan dengan garis dan belah ketupat di ujung.

Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya.

Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

Ketergantungan bentuk lemah yang menunjukkan relasi antara klien dan supplier dimana klien tidak memiliki pengetahuan semantik dari supplier. Sebuah ketergantungan akan mengatakan Aku butuh servis darimu, tapi aku tidak tahu kalau kamu ada. (Direpresentasikan dalam garis putus-putus yang diberi panah)

3. Langkah Praktikum 3.1. Membuat Class Diagram dan Menghapus Class Diagram

1. Klik kanan pada browser Logical View pilih New Class Diagram dan beri nama BookClass.

2. Klik ganda pada diagram baru yang telah dibuat untuk membukanya. 3. Klik toolbar Class pada menu toolbar lalu taruh klik pada jendela

diagram. 4. Buatlah empat (4) buah Class baru dan beri nama dengan cara klik

pada namanya : Pelanggan (Actor) Barang Pemesanan Pembayaran

BarangPelanggan (Actor)

Pemesanan

Pembayaran

5. Untuk menghapus Class Diagram klik kanan pada Class Diagram yang akan dihapus lalu pilih Delete.



3.2. Menambahkan atribut pada Class Diagram dan Menghapusnya 1. Ubah pada class Pelanggan (Actor) untuk menambahkan atribut dengan

cara klik kanan pada class tersebut pilih New Attribute. 2. Ubah nama atribut seperti dibawah ini:

Pelanggan (Actor)kode member : stringnama : stringalamat : stringtelpon : numberemail : string

3. Kemudian ubah visibility pada atribut dengan cara klik pada ikon atribut dan pilih jenisnya. Dan hasilnya seperti dibawah ini:


4. Untuk menghapus Atribute pada Class Diagram blok atribut yang akan dihapus, kemudian klik kanan pilih Delete lalu klik di sembarang tempat diluar class yang bersangkutan, maka akan muncul dialog untuk menghapus atau tidak, kemudian pilih Yes.

3.3. Menambahkan operasi pada Class Diagram dan Menghapusnya 1. Kemudian tambahkan operasi pada class Pelanggan (Actor) dengan

cara klik kanan pada class tersebut pilih New Operation. 2. Lalu ubah nama operasi seperti dibawah ini:


registrasi()



3. Untuk menghapus operasi lakukan langkah yang sama ketika akan menghapus atribut.

4. Kemudian buat class-class yang lain seperti dibawah ini: Barang

kode barang : stringnama barang : stringharga : numberpenerbi t : stringpengarang : stringjumlah : number

tambahbarang()ubahbarang()hapusbarang()caribynama(nama barang)

Pemesananno order : stringtglorder : datekode member : stringkode barang : stringjumlah barang : numbertotal harga : numberstatus : string

tambahpesan()listpesan()batalpesan()ubahstatus(status)

Pembayaranno order : stringtglbayar : date

listpembayaran(no order)

3.4. Membuat relasi antar Class 1. Kemudian buatlah relasi antar class dengan cara pilih toolbar

Undirectional Associate. 2. Klik pada salah satu class dan drag ke class yang lain.




registrasi()

3. Kemudian ubah tipe relasi antar class dengan cara klik relasinya, klik kanan pada relasi yang dekat dengan class Pelanggan.

4. Pilih Multiplicity 1 5. Dan klik kanan relasi yang dekat dengan class Pemesanan pilih

Multiplicity Zero or More.



0..*1




registrasi()

6. Dan buatlah relasi antar class-class yang lain seperti dibawah ini: Barang

kode barang : stringnama barang : stringharga : numberpenerbit : stringpengarang : stringjumlah : number

tambahbarang()ubahbarang()hapusbarang()caribynama(nama barang)


registrasi()



0..*1

0..*1

0..* 10..* 1

Pembayaranno order : stringtglbayar : date

listpembayaran(no order)

1

11

1

7. Jangan lupa simpan hasil praktikum ini ke dalam file yang lama.



MODUL IV SEQUENCE DIAGRAM

1. Tujuan Praktikum o Praktikan mengenal tentang Sequence Diagram o Praktikan dapat membuat Sequence Diagram o Praktikan mengimplementasikan Sequence Diagram pada kasus modul 1

2. Dasar Teori 2.1. Pengertian Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri antara dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.

Dalam diagram sequence, setiap object hanya memiliki garis yang digambarkan garis putus-putus ke bawah. Pesan antar object digambarkan dengan anak panah dari object yang mengirimkan pesan ke object yang menerima pesan.

2.2. Tujuan Penggunaan Sequence Diagram Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara

object juga interaksi antar object yang terjadi pada titik tertentu dalam eksekusi sistem.

2.3. Bagian-Bagian Sequence Diagram Aturan pembuatan diagram sequende.

Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek

lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class.

Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message.

Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity.

3. Langkah Praktikum 3.1. Membuat sequence diagram dan Menghapusnya

1. Klik kanan use case pada browser.



2. Pilih New Sequence pada menu bar. Sebuah sequence diagram ditambahkan ke browser.

3. Ketika sequence diagram masih disorot, masukkan nama untuk sequence diagram tersebut dengan Pemesanan.

4. Untuk menghapus Sequence Diagram, klik kanan pada Sequence Diagram yang akan dihapus pilih Delete.

3.2. Membuat Objects dan Messages dalam Sequence Diagram 1. Klik ganda sequence diagram Pemesanan pada browser. 2. Klik actor Pelanggan pada browser dan drag ke dalam jendela diagram

sequence. 3. Klik kanan logical view pada browser, kemudian pilih New Class 4. Ubah nama class tersebut menjadi Login 5. Kemudian klik kanan pada class tersebut pilih Open Specification 6. Lalu pilih sterotype menjadi boundary.

7. Klik OK 8. Kemudian drag class Login ke dalam sequence diagram



9. Kemudian tambahkan class yang sudah ada pada browser pilih logical view kemudian drag class Pelanggan ke dalam diagram sequence.

10. Kemudian tambahkan class yang sudah ada pada browser pilih logical view kemudian drag class Barang ke dalam diagram sequence.

11. Kemudian tambahkan class yang sudah ada pada browser pilih logical view kemudian drag class Pemesanan ke dalam diagram sequence.

12. Lalu tambahkan class baru seperti langkah 3 dengan nama Persetujuan Pembelian.

13. Kemudian tambahkan class yang sudah ada pada browser pilih logical view kemudian drag class Pembayaran ke dalam diagram sequence.

14. Kemudian tambahkan actor Toko yang sudah ada dalam browser pada Use Case View dengan cara didrag.

15. Sehingga hasil akhir akan seperti ini:



16. Klik ikon object message dari toolbar. 17. Klik actor atau class atau object yang lain lalu tarik garis message ke

actor atau object yang menerima message. 18. Ketika message masih disorot, masukkan nama Masukkan kode

member pada message tersebut.

19. Kemudian buat message yang lain sehingga tampilan seperti dibawah ini:



:

Pe

rse

tuju

an

P

em

be

lia

n :

Pe

lan

gg

an

Pe

me

sa

na

n

:

To

ko

Pe

lan

gg

an

: L

og

inB

ara

ng

: P

em

ba

yara

n

Ma

sukk

an

ko

de

m

em

be

r

Em

ail

Info

rma

si P

es

an

an

Tra

ns

fer

Ua

ng

Tra

nsf

er

dit

eri

ma

Ko

nfir

ma

si S

MS

"N

O_

OR

DE

R N

O_

SLIP

_T

RA

NS

FE

R"

Pe

ng

irim

an

B

ara

ng

va

lid

asi

p

ela

ng

ga

n

ca

ribyn

am

a (n

am

a ba

ran

g)

va

lida

si s

uks

es

list b

ara

ng

Pili

h B

ara

ng

Pe

me

san

an

B

ara

ng

Pe

rse

tuju

an

P

em

be

lia

n



3.3. Menghapus Object dan Message dalam Sequence Diagram 1. Klik Object atau message yang akan dihapus. 2. Kemudian tekan Control + D secara bersamaan yang tujuannya

menghapus dari model.

3.4. Buatlah Diagram Sequence yang menjelaskan setiap skenario yang ada dalam kasus pada modul 1 (karena contoh diatas adalah Diagram Sequence secara global untuk kasus pemesanan), yaitu : 1. Proses Registrasi 2. Proses Pemesanan yang terdiri dari Login dan Informasi Pemesanan

(melalui Email). 3. Proses Pembayaran yang terdiri dari Transfer Uang dan Pengiriman

Barang.



MODUL V ACTIVITY DIAGRAM

1. Tujuan Praktikum o Praktikan mengenal tentang Activity Diagram o Praktikan dapat membuat Activity Diagram o Praktikan mengimplementasikan Activity Diagram pada kasus modul 1

2. Dasar Teori 2.1. Pengertian Activity Diagram

Activity diagram menggambarkan berbagai aliran aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing aliran berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.

Pada umumnya activity diagram tidak menampilkan secara detail urutan proses, namun hanya memberikan gambaran global bagaimana urutan prosesnya. Sehingga seringkali diagram ini digunakan untuk memodelkan aktivitas bisnis dalam level konseptual. Diagram ini sangat mirip dengan sebuah flowchart karena kita dapat memodelkan sebuah alur kerja dari satu aktivitas ke aktivitas lainnya atau dari satu aktivitas ke dalam keadaan sesaat(state), akan tetapi perbedaannya dengan flowchart adalah Activity diagram bisa mendukung perilaku pararel sedangkan flowchart tidak bisa.

Membuat Activity diagram terlebih dahulu dalam memodelkan sebuah proses dapat membantu kita memahami proses secara keseluruhan. Activity diagram juga berguna ketika kita ingin menggambarkan perilaku pararel atau menjelaskan bagaimana perilaku dalam berbagai use case berinteraksi.

Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Activity diagram adalah variasi dari state diagram yang mana "state" merepresentasikan operasi, dan transisinya merepresentasikan aktivitas yang terjadi pada saat operasi sudah selesai. Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas.

Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

2.2. Tujuan Penggunaan Activity Diagram Activity diagram juga bermanfaat untuk menggambarkan parallel behaviour

atau menggambarkan interaksi antara beberapa use case.



X = X - 2 Membuat pola

2.3. Action dan Activity State Pada activity diagram, state adalah aksi atau ekspresi yang terjadi pada

suatu objek. Action state tidak dapat didekomposisi lebih lanjut, pada umumnya bersifat atomik, yang berarti event-event mungkin terjadi, tetapi pekerjaan suatu action state tidak akan terinterupsi. Pekerjaan dari suatu action state secara umum dipertimbangkan mengambil waktu eksekusi yang tidak signifikan dibandingkan waktu kerja sistem secara keseluruhan. Sedangkan activity state dapat didekomposisi lebih lanjut, ia tidak bersifat atomik, yang berarti mereka dapat diinterupsi dan secara umum membutuhkan beberapa waktu dari perjalanan sistem atau perangkat lunak untuk terselesaikan dengan tuntas.

Gambar 4.1 Action State Gambar 4.2 Activity State

2.4. Transition Ketika aksi atau aktifitas dari suatu state diselesaikan, aliran kendali akan

menuju ke aksi/aktifitas berikutnya. Kita dapat menspesifikasikan aliran tersebut menggunakan transisi-transisi untuk memperlihatkan lintasan dari satu aksi ke aksi berikutnya. Transisi seperti ini dinamakan pemicuan(fired atau trigger) karena control dilewatkan dengan segera setelah suatu state diselesaikan. Kita dapat mengeksekusi aksi keluar(exit action) jika ada, setelah suatu state diselesaikan. Selanjutnya control mengikuti transisi dan dilewatkan ke aksi atau aktifitas berikutnya.

Seperti dapat kita lihat pada gambar 4.3 dimana kita mendapatkan gambaran tentang bagaimana langkah-langkah mencuci baju yang kotor. Pertama kita mengumpulkan baju-baju kotor yang akan dicuci terlebih dahulu, kemudian merendamnya, setelah itu baru mencuci baju-baju kotor tersebut.

Gambar 4.3 contoh transisi

E n d S ta te

B e g i n S ta te

Me n g u m p u lk a n B a ju Ko to r

Me r e n da m B a ju Ko to r

Me n c u c i B a ju Ko to r



P e rs ia p an Me m b u a t K u e

Me m b u a t K u e

Me m b e li b a h a n ku e

( b a h a n -b a h a n ku e b e l u m a d a )

( b a h a n -b a h a n ku e su d a h si a p )

2.5. Percabangan(Branching) Umumnya transisi terjadi secara berurutan, tetapi bukan berarti semua

transisi terjadi secara berurutan, namun kita dapat melibatkan percabangan seperti halnya dalam diagram alir(flowchart). Percabangan dilukiskan dalam bentuk jajaran genjang. Seperti pada gambar 4.4 diperlihatkan proses persiapan membuat kue, jika bahan-bahan kue telah tersedia, maka peroses membuat kue dapat dilakukan, tetapi jika bahan-bahannya belum ada, maka kita harus membeli bahan-bahan kuenya terlebih dulu.

Gambar 4.4 contoh percabangan

2.6. Forking dan Joining Dalam UML kita menggunakan garis sinkronisasi untuk menspesifikasikan

forking(satu aliran yang pada tahap tertentu berubah menjadi beberapa aliran) serta joining(beberapa aliran sekaligus yang secara bersamaan masuk menjadi satu titik). Garis sinkronisasi digambarkan dengan garis horisontal tebal.

Seperti diperlihatkan pada gambar 4.5, pada gambar tersebut diperlihatkan forking dan joining sekaligus pada proses menjahit kain, mulai dari persiapan sampai proses menjahit kain. Dimana forking terjadi pada saat mengukur model, yang terbagi menjadi dua aliran yaitu mengukur panjang dan lebar, sedangkan joining terjadi pada saat membuat pola dari aliran mengukur panjang dan lebar tadi.



Gambar 4.5 contoh Forking dan Joining

2.7. Unsur-unsur utama Activity Diagram Sebelum kita membuat activity diagram untuk menjelaskan aliran-aliran

secara rinci dari setiap use case, terlebih dahulu kita akan berkenalan dengan toolbar yang nantinya akan dipergunakan untuk membuat activity diagram, seperti diperlihatkan pada tabel 4.1 di bawah ini:

Membuat Pola

Persiapan Menjahit

Merancang Baju

Memotong Pola

Mengukur Model

Panjang Lebar

Menjahit Kain

Joining

Forking



Tabel 4.1 Toolbar untuk activity diagram

Adapun unsur-unsur utama dari activity diagram meliputi : Swimlane

Memperlihatkan siapa yang bertanggungjawab untuk melaksanakan tugas-tugas tertentu pada activity diagram.

Activity Menggambarkan langkah-langkah dalam aliran kerja

Action Merupakan langkah-langkah dalam activity. Aksi atau action mungkin terjadi saat event tertentu memasuki activity, saat event meninggalkan (exit) activity, terjadi di dalam activity atau setelah event tertentu (spesifik).

Objek Merupakan entitas-entitas yang dipengaruhi aliran kerja

Ikon Nama button Fungsi Select/Deselect

an item Mengembalikan pointer mouse ke ikon ini memungkinkan kita memilih item-item tertentu

Text Box Menambahkan boks teks ke diagram

Note Menambahkan catatan pada diagram Anchor Note to

item Melekatkan catatan pada state atau activity tertentu dalam diagram

State

Menambahkan state untuk suatu objek Activity

Menambahkan aktifitas baru pada diagram Start State

Memperlihatkan dimana aliran kerja berawal End State

Memperlihatkan dimana aliran kerja berakhir State Transition

Menambah transisi dari suatu aktifitas ke aktifitas lainnya

Transition to Self

Menambah transisi rekursif Horizontal

Synchronization Menambahkan sinkronisasi horisontal pada diagram

Vertical Synchronization

Menambahkan sinkronisasi vertikal pada diagram

Decision Menambahkan titik keputusan pada aliran kerja Swimlane Menambahkan swimlane(umumnya digunakan pada pemodelan bisnis)



Transitions Memperlihatkan bagaimana aliran-aliran kerja bergerak dari satu activity ke activity lainnya.

Desicions Points Memperlihatkan dimana keputusan perlu diambil selama terjadi aliran-aliran kerja.

Synchronizations Memperlihatkan bagaimana dua atau lebih langkah pada aliran-aliran kerja terjadi secara simultan.

Start State. End State.

3. Langkah Praktikum 3.1. Membuat Activity Diagram Untuk menambahkan activity diagram pada suatu use case, lakukan langkah-

langkah berikut ini : 1. Klik kanan pada use case tertentu. 2. Pilih New Activity Diagram. 3. Rational Rose akan menambahkan State/Activity Model di dalam use

case. 4. Beri nama activity diagram yang baru dengan BookActivity. 5. Klik ganda activity diagram yang baru untuk membukanya.

3.2. Menambahkan ikon-ikon pada Activity Diagram 1. Klik ikon Start State pada toolbar dan taruh pada diagram kemudian

ubah namanya menjadi Mulai. 2. Klik ikon Activity pada toolbar dan taruh pada diagram kemudian ubah

namanya menjadi Cari Barang (by Nama Barang). 3. Kemudian tambahkan lagi tujuh buah (7) ikon Activity dan ubah

namanya: Pilih barang yang akan dipesan Pesan barang Pengiriman Informasi Pesanan via Email Transfer Uang Konfirmasi SMS Pengiriman barang

4. Tambahkan sebuah ikon Decision dan ubah nama menjadi Persetujuan Pembelian.

5. Tambahkan sebuah ikon End State dan ubah nama menjadi Selesai. 6. Hubungkan antar Start State dengan Activity, Decision dan End State

menggunakan State Transition. 7. Dan tambahkan dua buah (2) ikon Text Box untuk Batal dan OK pada

Decision. 8. Sehingga tampilan seperti dibawah ini :



9.

Mulai

Cari Barang (by Nama Barang)

Pilih Barang yang akan dipesan

Pesan Barang

Pengiriman Informasi Pesanan via Email

Konfirmasi SMS

Pengiriman Barang

Persetujuan Pembelian

Selesai

Transfer Uang

Batal

OK



3.3. Menghapus ikon pada Activity Diagram 1. Klik pada ikon yang akan dihapus kemudian tekan tombol Delete.

3.4. Menghapus Diagram 1. Pilih activity diagram yang akan kita hapus. 2. Klik kanan dan pilih Delete.

3.5. Buatlah Diagram Activity yang menjelaskan setiap skenario yang ada dalam kasus pada modul 1 (karena contoh diatas adalah Diagram Activity secara global untuk kasus pemesanan), yaitu : 1. Proses Registrasi 2. Proses Pemesanan yang terdiri dari Login dan Informasi Pemesanan

(melalui Email). 3. Proses Pembayaran yang terdiri dari Transfer Uang dan Pengiriman

Barang.



DAFTAR PUSTAKA

Erwin, M. AH, Rekayasa Perangkat Lunak, Teknik Informatika, Fakultas Teknologi Industri, Universitas Islam Indonesia, Yogyakarta, 2004.

Nugroho, Adi, Rational Rose untuk Pemodelan Berorientasi Objek, INFORMATIKA, Bandung, 2005.Setiawan, M. Andri, Bahan Kuliah Rekayasa Perangkat Lunak Semester Ganjil 2004/2005, Teknik Informatika, Fakultas Teknologi Industri, Universitas Islam Indonesia, Yogyakarta, 2004.

Modul UML RPL.

76559025 Modul Penggunaan Rational Rose

Documents

Transcript of 76559025 Modul Penggunaan Rational Rose