Modul Penggunaan Rational Rose

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

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 notasinotasi 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.

1

Modul Praktikum Rekayasa Perangkat Lunak


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).

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

B.

2



b.

c.

d.

e.

f.

g.

h.

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. 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. 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. 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. 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. 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. 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. Deployment Diagram Menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak sistem, menunjukkan hubungan komputer dengan perangkat (nodes) satu Modul Praktikum Rekayasa Perangkat Lunak

3


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.

4



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 Modul Praktikum Rekayasa Perangkat Lunak

5


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

6



-

-

-

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 Create New Model Open Existing Model Save Model or Log Print Diagram View Documentation Browse Class Diagram Browse Interaction Diagram Browse Component Diagram Browse State Machine Diagram Browse Deployment Diagram Browse Parent Browse Previous Diagram Fungsi Menciptakan model baru (berkas .mdl) Membuka berkas model yang telah disimpan Menyimpan berkas model atau berkas log Mencetak satu atau lebih diagram Menampilkan jendela dokumentasi Melokalisasi dan membuka diagram class Melokalisasi dan membuka sequence atau collaboration diagram Melokalisasi dan membuka component diagram Melokalisasi dan membuka statechart diagram Melokalisasi dan membuka deployment diagram Membuka diagram induk 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:

7



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:

8



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.

9



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.

10



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 potensial untuk mengatakan tentang sistem dari sudut pandangnya. mewakili pandangan di luar sistem. Use case diagram dapat sangat membantu bila kita sedang requirement sebuah sistem, mengkomunikasikan rancangan dengan merancang test case untuk semua feature yang ada pada sistem.

pengguna Use Case menyusun klien, dan

11



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 :

12



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 Online(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.Association

Aktor

Use case

Gambar 2.7. Notasi Association Relationship 2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.

13



generalizationAktor A

generalization Aktor

Aktor B

Gambar 2.8. Notasi Generalization Relationship 3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.Package2 dependency Package3

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

14



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 1 Requirement Pelanggan melakukan registrasi yang mengisikan profil serta alamat penagihan, yang kemudian akan mendapatkan kode member. 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. Sistem secara otomatis mengirimkan Actor Pelanggan Use Case Registrasi Member

-

2

Pelanggan

Pemesanan, Login

3

Pelanggan

Pemesanan,

15



4

5

email kepada pelanggan yang berisi daftar detail barang yang dipesan, harga yang harus dibayar info pembayaran dan nomor rekening untuk pembayaran serta batas pembayaran. 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. 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.

Pengiriman Informasi

Pelanggan, Toko

Pembayaran, Transfer

Toko, Pelanggan

Pembayaran, Pengiriman Barang

-

Beberapa skenario terkait use case diatas, yaitu: 1. Use Case : Registrasi member Actor : Pelanggan Tujuan : Pelanggan mendaftar menjadi member 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 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.

16



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. Modul Praktikum Rekayasa Perangkat Lunak

17


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

Pelanggan

Toko

Pengunj ung

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.

18



Registrasi Member

Pengiriman Barang Pemesanan

Transfer

Login


Pembayaran

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.

Pemesanan Pelanggan

LoginPembayaran

Pengiriman Barang

Transfer


Toko

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.

19



20



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 : Private, tidak dapat dipanggil dari luar class yang bersangkutan Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya o Public, dapat dipanggil oleh siapa saja o oNewClass name opname()

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

21



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 PembayaranPelanggan (Actor) Barang Pemesanan

Pembayaran

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

22



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 : string nama : string alamat : string tel pon : number email : string

3. Kemudian ubah visibility pada atribut dengan cara klik pada ikon atribut dan pilih jenisnya. Dan hasilnya seperti dibawah ini:Pelanggan (Actor)kode member : string nama : string alamat : string tel pon : number email : string

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:Pelanggan (Actor)kode member : string nama : string alamat : string tel pon : number email : string regi strasi ()

23



3. Untuk menghapus operasi lakukan langkah yang sama ketika akan menghapus atribut. 4. Kemudian buat class-class yang lain seperti dibawah ini:Pemesananno order : stri ng tglorder : date kode member : stri ng kode barang : string jumlah barang : number total harga : number status : string tambahpesan() li stpesan() batalpesan() ubahstatus(status)

Barangkode barang : string nama barang : string harga : number penerbi t : stri ng pengarang : string jumlah : number tambahbarang() ubahbarang() hapusbarang() caribynama(nama barang)

Pembayaranno order : string tglbayar : 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.Pelanggan (Actor)kode member : string nama : string alamat : string tel pon : number email : string registrasi()

Pemesananno order : stri ng tgl order : date kode member : string kode barang : string juml ah barang : number total harga : number status : string tambahpesan() li stpesan() batalpesan() ubahstatus(status)

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.

24



Pelanggan (Actor)kode member : string nama : string alamat : string tel pon : number email : string

Pemesananno order : stri ng tgl order : date kode member : string kode barang : string juml ah barang : number total harga : number status : string tambahpesan() li stpesan() batalpesan() ubahstatus(status)

1registrasi()

0..*

6. Dan buatlah relasi antar class-class yang lain seperti dibawah ini:Pelanggan (Actor)kode member : string nama : string alamat : string tel pon : number email : string

Pemesananno order : stri ng tgl order : date kode member : string kode barang : string jumlah barang : number total harga : number status : string

Barangkode barang : string nama barang : string harga : number penerbit : stri ng pengarang : string juml ah : number

1registrasi()

0..*

0..*tambahpesan() li stpesan() batalpesan() ubahstatus(status)

1

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

1 Pembayaranno order : string tglbayar : date li stpembayaran(no order)

1

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

25



26



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.

27



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

28



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:

29



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:

30


31Pelanggan: Persetuj uan Pembeli an

Barang

Pemes anan

: Pembayaran: T oko

: Pel anggan

: Login

Masukkan kode member

val idasi pelanggan

validas i s uks es

caribynama (nama barang)

lis t barang

Pilih BarangPemesanan Barang

Persetuj uan Pembeli an

Email Informas i Pes anan

Trans fer UangT ransfer di terima

Konfirmas i SMS "NO_ORDER NO_SLIP_TRANSFER" Pengiriman Barang




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.

32



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.

33



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.X = X - 2

Membuat pol a

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.B eg i n S ta te

M e n g u m p u lk a n B a ju K o to r

Me r e n d a m B a ju K o to r

Me n c u c i B a ju K o to r

E n d S ta t e

Gambar 4.3 contoh transisi

34



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.P e rs ia p an Me m b u a t K u e

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

M e m b e li bah an kue

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

Me m b u a t Kue

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.

35


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

Merancang Baju

Mengukur Model Forking Panjang Lebar

Joining Membuat Pola

Memotong Pola

Menjahit Kain

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:

36



Ikon

Nama button Select/Deselect an item Text Box Note Anchor Note to item State Activity Start State End State State Transition

Fungsi Mengembalikan pointer mouse ke ikon ini memungkinkan kita memilih item-item tertentu Menambahkan boks teks ke diagram Menambahkan catatan pada diagram Melekatkan catatan pada state atau activity tertentu dalam diagram Menambahkan state untuk suatu objek Menambahkan aktifitas baru pada diagram Memperlihatkan dimana aliran kerja berawal Memperlihatkan dimana aliran kerja berakhir Menambah transisi dari suatu aktifitas ke aktifitas lainnya Menambah transisi rekursif

Transition to Self Horizontal Synchronization Vertical Synchronization Decision Swimlane

Menambahkan sinkronisasi horisontal pada diagram Menambahkan sinkronisasi vertikal pada diagram Menambahkan titik keputusan pada aliran kerja Menambahkan swimlane(umumnya digunakan pada pemodelan bisnis) Tabel 4.1 Toolbar untuk activity diagram

Adapun unsur-unsur utama dari activity diagram meliputi : Swimlane Memperlihatkan siapa yang bertanggungjawab untuk melaksanakan tugastugas 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

37



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 langkahlangkah 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 :

38



9.Mulai

Cari Barang (by Nama Barang)

Pilih Barang yang akan dipesan Pesan Barang

Batal

Persetujuan Pembelian OK Pengiriman Informasi Pesanan via Email Transfer Uang

Konfirmasi SMS

Pengiriman BarangSeles ai

39



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.

40



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.

41


Modul Penggunaan Rational Rose

Documents

Transcript of Modul Penggunaan Rational Rose