Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Bab II Use Case Diagram

13,592 views

Published on

Penjelasan mengenai Use Case serta beberapa contoh diagram penerapan Use Case. Hope you enjoy it..

Published in: Education

Bab II Use Case Diagram

  1. 1. Use Case Diagram Presented By Hari Setiaji
  2. 2. Pengenalan UML <ul><li>Sebuah &quot;bahasa&quot; yang menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem perangkat lunak. </li></ul><ul><li>UML mendefinisikan notasi dan syntax . </li></ul><ul><li>Notasi UML  sekumpulan bentuk khusus yang memiliki makna tertentu untuk menggambarkan berbagai diagram perangkat lunak. </li></ul><ul><li>UML syntax  mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. </li></ul>
  3. 3. Pengenalan UML <ul><li>Notasi UML diturunkan dari 3 notasi yaitu : </li></ul><ul><ul><li>Grady Booch OOD (Object-Oriented Design). </li></ul></ul><ul><ul><li>Jim Rumbaugh OMT (Object Modeling Technique). </li></ul></ul><ul><ul><li>Ivar Jacobson OOSE (Object-Oriented Software Engineering). </li></ul></ul><ul><li>Bentuk diagram yang digunakan untuk merepresentasikan elemen- </li></ul><ul><li>elemen dalam sistem : </li></ul><ul><ul><li>Use-case Diagram </li></ul></ul><ul><ul><li>Class Diagram </li></ul></ul><ul><ul><li>State Diagram </li></ul></ul><ul><ul><li>Sequence diagram </li></ul></ul><ul><ul><li>Collaboration Diagram </li></ul></ul><ul><ul><li>Activity Diagram </li></ul></ul><ul><ul><li>Component Diagram </li></ul></ul><ul><ul><li>Deployment Diagram </li></ul></ul>
  4. 4. Tujuan Penggunaan UML <ul><ul><li>Memberikan bahasa pemodelan yang bebas dari berbagai bahasa pemrograman dan proses rekayasa. </li></ul></ul><ul><ul><li>Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan. </li></ul></ul><ul><ul><li>Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum. </li></ul></ul><ul><ul><li>UML bisa juga berfungsi sebagai sebuah (blue print) cetak biru karena sangat lengkap dan detail. </li></ul></ul>
  5. 5. Use Case Diagram <ul><li>Suatu bentuk diagram yang menggambarkan fungsionalitas yang diharapkan dari sebuah sistem dilihat dari perspektif pengguna di luar sistem. </li></ul><ul><li>Merepresentasikan interaksi yang terjadi antara aktor dengan proses atau sistem yang dibuat. </li></ul>
  6. 6. Tujuan Penggunaan Use Case Diagram <ul><li>M endapatkan pemahaman tentang sistem/perangkat lunak yang akan dikembangkan. </li></ul><ul><li>M emperlihatkan hubungan-hubungan yang terjadi antara aktor (seseorang/sesuatu yang berinteraksi dengan sistem) dengan use case (proses yang terjadi dalam sistem). </li></ul><ul><li>M embantu dalam menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien dan merancang test case untuk semua fitur yang ada pada sistem. </li></ul><ul><li>Dengan melihat aktor-aktor, pengguna akan mengetahui siapa atau apa saja yang akan berinteraksi dengan sistem. </li></ul><ul><li>Dengan melihat kombinasi sejumlah aktor dan use case , pengguna akan mengetahui secara jelas ruang lingkup dari sistem/perangkat lunak yang akan dikembangkan . </li></ul>
  7. 7. Scenario <ul><li>Skenario adalah langkah-langkah yang menerangkan urutan kejadian antar pengguna dengan sistem. </li></ul><ul><li>Contoh : Scenario Peminjaman </li></ul>Aktor Sistem <ul><li>Operator membuka website </li></ul><ul><li>Operator login dengan mengetikkan username dan password </li></ul><ul><li>Sistem memverifikasi proses login operator. </li></ul><ul><li>Jika username dan password sesuai, sistem memperbolehkan operator masuk ke halaman operator </li></ul><ul><li>Setelah login, operator dapat melakukan operasional peminjaman dengan memasukkan no.anggota peminjam dan buku yang akan dipinjam </li></ul>
  8. 8. Software Requirement Spesification (SRS) <ul><li>Suatu uraian lengkap yang menyangkut perilaku dari sistem yang akan dikembangkan. </li></ul><ul><li>SRS biasanya berisi : </li></ul><ul><ul><li>Kebutuhan Fungsional  suatu kebutuhan yang menetapkan perilaku input/output dari suatu sistem. </li></ul></ul><ul><ul><li>Kebutuhan Non-Fungsional  suatu kebutuhan yang menetapkan property sistem, seperti lingkungan dan batasan implementasi, performance, ketergantungan platform, kebutuhan maintainance, extensibility, dan keandalan. </li></ul></ul>
  9. 9. Contoh SRS No Requirement Aktor Use Case 1 User biasa baik yang sudah terdaftar sebagai peminjam ataupun tidak terdaftar hanya dapat melihat buku dan mencari buku berdasarkan judul buku atau berdasarkan penerbit User cari buku berdasarkan judul, cari buku berdasarkan penerbit 2 Operator dapat melihat dan mencari buku di halaman utama website. Sedang untuk masuk ke halaman operator dibutuhkan autentifikasi login. Setelah login, operator dapat mengoperasikan peminjaman perpustakaan, berupa tambah peminjaman, melihat peminjaman, batal peminjaman, menggenerate denda bila terjadi keterlambatan peminjaman, mengubah status pemgembalian dan perpanjangan peminjaman, manambah anggota (peminjam) baru, mengedit profil peminjam, menghapus peminjam, menambah buku baru, mengedit, dan menghapus buku. Operator cari buku berdasarkan judul, cari buku berdasarkan penerbit , peminjaman buku, pengembalian buku, informasi denda, pendataan buku, keanggotaan peminjam
  10. 10. Contoh SRS 3 Admin dapat melihat dan mencari buku di halaman utama website. Sedang untuk masuk ke halaman admin dibutuhkan login. Setelah login, admin dapat menambah operator, dan menghapus operator, menambah, mengedit, dan menghapus buku, manambah anggota (peminjam) baru, mengedit profil peminjam, menghapus peminjam, menambah buku baru, mengedit, dan menghapus buku, admin tidak dapat melakukan operasional peminjaman perpustakaan Admin cari buku berdasarkan judul, cari buku berdasarkan penerbit , pendataan buku, keanggotaan peminjam, keanggotaan operator
  11. 11. Komponen Use Case Diagram <ul><li>Use Case </li></ul><ul><li>Actor </li></ul><ul><li>Relasi </li></ul>
  12. 12. Komponen 1 : Use Case <ul><ul><li>Merupakan proses-proses yang terjadi dalam suatu sistem . </li></ul></ul><ul><ul><li>M enggambarkan bagaimana seseorang akan menggunakan/memanfaatkan sistem . </li></ul></ul>
  13. 13. Komponen 1 : Use Case <ul><li>Use Case Dibedakan menjadi 2, yaitu : </li></ul><ul><ul><ul><li>Use-case konkret  use case yang dibuat langsung karena keperluan aktor. Aktor dapat melihat dan berinisiatif terhadapnya. </li></ul></ul></ul><ul><ul><li>Use-case abstra k  use case yang tidak pernah berdiri sendiri. Use case abstrak senantiasa termasuk di dalam ( include ), diperluas dari ( extend ) atau memperumum ( generalize ) use case lainnya. </li></ul></ul>
  14. 14. Komponen 2 : Actor <ul><ul><li>S eseorang atau sesuatu yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. </li></ul></ul><ul><li>A da 3 jenis a k tor untuk hampir semua sistem/perangkat lunak yang dikembangkan : </li></ul><ul><ul><li>Para pengguna sistem yaitu orang-orang yang hadir secara fisik, atau para pengguna. </li></ul></ul><ul><ul><ul><li>Contoh : Seseorang yang bernama Adi dalam sistem e-learning memainkan peran sebagai seorang mahasiswa. </li></ul></ul></ul><ul><ul><li>Sistem lain yang berinteraksi dengan sistem yang di kembangkan . </li></ul></ul><ul><ul><ul><li>Contoh : S istem I nformasi A kademik yang berinteraksi dengan S istem Perpustakaan U niversitas . </li></ul></ul></ul><ul><ul><li>Waktu sebagai p emicu event-event tertentu bagi sistem yang dikembangkan . </li></ul></ul><ul><ul><ul><li>Contoh : W aktu pengisian KRS bagi mahasiswa akan otomatis dibuka pada waktu-waktu tertentu seusai dengan jadwal masing-masing. </li></ul></ul></ul>
  15. 15. Komponen 3 : Relasi <ul><li>Relasi atau relationship  hubungan antar elemen dalam Use Case Diagram . </li></ul><ul><ul><li>Relasi Asosiasi ( Association )  relasi yang menghubungkan link antar elemen. </li></ul></ul><ul><ul><ul><li>Relasi Asosiasi ( Association )  relasi yang menghubungkan link antar elemen. </li></ul></ul></ul>
  16. 16. Komponen 3 : Relasi <ul><ul><li>Include Relationship  kelakuan yang harus dipenuhi agar sebuah event dapat terjadi. </li></ul></ul><ul><ul><li>Extend Relationship  relasi yang memungkinkan suatu use case memiliki kemungkinan untuk memperluas fungsionalitas yang disediakan oleh use case lainnya. </li></ul></ul>
  17. 17. Komponen 3 : Relasi <ul><ul><li>Generalization </li></ul></ul><ul><ul><ul><li>Sebuah elemen dapat merupakan spesialisasi dari elemen lainnya. </li></ul></ul></ul><ul><ul><ul><li>Memperlihatkan bahwa beberapa actor atau use case memiliki sesuatu yang bersifat umum. </li></ul></ul></ul>
  18. 18. Use Case Diagram Perpustakaan
  19. 19. What’s Next ? <ul><li>Langkah Praktikum </li></ul>
  20. 20. Semoga Bermanfaat Follow Hari Setiaji on Twitter www.harisetiaji.wordpress.com

×