use case diagram

UKDWPemodelan Sistem PL

Use Case Diagram

budi susanto


Tujuan● Mengenal pemodelan dengan pendekatan

Rational● Mengenal pemodelan dengan pendekatan 4+1● Memahami actor, use case dan komunikasi


Pendekatan Rational View

4


Pendekatan Rational View● Ada empat view yang masing-masing ditujukan

untuk tujuan dan pemakai yang berbeda– Use Case view– Logical View– Component View– Deployment View

5


Use Case View (1)● Use Case view : fokus pada gambaran level tinggi dari

apa yang akan sistem kerjakan, tanpa peduli tentang bagaimana sistem akan melakukannya secara detil.

● Ketika proyek dimulai, tim menghasilkan model bisnis dalam Use Case view (optional).

● Jika dikerjakan, anggota tim yang dibutuhkan: pelanggan, manajer proyek, dan analis yang berpusat pada proses bisnis

● Sekali model bisnis diselesaikan, tim pindah ke model use case. Pelanggan, analis, dan manager proyek akan bekerja dengan Use Case Diagram, dan menggunakan dokumentasi use case untuk menyetujui definisi level tinggi dari sistem.

6


Use Case View (2)Business Use Case workflow dalam organisasi

Business Actor Entitas diluar organisasi yang berinteraksi dengan bisnis

Business Worker Peran dalam organisasi

Organizationl Unit Kelompok business case / business worker.

Actor Entitas eksternal yang berinteraksi dengan sistem

Use Case Fungsionalitas sistem level tinggi yang akan disediakan

Activity Diagram

Use Case Diagram Memperlihatkan actor, use case dan interaksi antar mereka

Use Case Documentation Aliran detail dari suatu use case, termasuk penanganan error

Interaction diagram

Package Kelompok use case, actor atau elemen pemodelan lain

Untuk menggambarkan workflow dalam suatu business use case atau aliran kejadian melalui use case

Menampilkan objek/clas yang terlibat dalam satu aliran dalam suatu use case

7


Logical View (1)

● Fokus pada bagaimana sistem akan menerapkan perilaku dalam use cases.

● Menyediakan gambaran detil dari sebagian sistem, dan menjelaskan bagaimana antar bagian sistem tersebut berhubungan.

● Logical view berisi penentuan class yang akan digunakan, Class diagram, dan Statechart diagram.

8


Logical View (2)● Tim menempuh pendekatan dua langkah ke Logical

View. – Pertama, menganalisa class-class. Analisa class

tidak tergantung pada bahasa yang digunakan. Analisa class mungkin juga muncul pada Interaction diagram dalam Use Case view.

– Kedua, merancang class-class. Perancangan class sudah merupakan detil yang tergantung pada bahasa yang akan digunakan

9


Logical View (5)● Entity Class

– Suatu class yang diperlukan ole sistem untuk memenuhi beberapa tanggung jawab

– Kata benda yang digunakan untuk menjelaskan tanggungjawab, mungkin sebagai awal yang baik

● Boundary Class– Class yang menangani komunikasi antara lingkungan

diluar sistem dan di dalam sistem● Control Class

– Mempresentasikan use case secara dinamis (menjalankan use case)

– Pada fase awal, control class bertanggung jawab untuk aliran kejadian dalam use case

10


Logical View (3)

● Pemakai utama dari Logical view adalah pengembang dan arsitek sistem. – Pengembang berkepentingan terhadap class apa

saja yang akan dibuat, atribut dan perilaku setiap class, dan hubungan antar class

– Arsitek sistem, yang memperhatikan struktur sistem keseluruhan, bertanggung jawab untuk memastikan bahwa sistem memiliki arsitektur yang stabil

● Analis mengamai Class diagram untuk memastikan bahwa kebutuhan bisnis akan diterapkan dalam program.

11


Logical View (4)

● Staf penjamin kualitas (QA) akan melihat class, package dan Class diagram untuk mengetahui bagian sistem yang ada dan perlu diuji. – Diagram Statechart juga dilihat untuk mengetahui

bagaimana seharusnya suatu class. ● Manajer proyek akan melihat Class diagram

untuk memperkirakan seberapa komplek sistem.

12


Logical View (5)Class Blok pembangun aplikasi sistem

Class Diagram

Interaction diagram

Statechart Diagram Menampilkan perilaku dinamis suatu objek

Package Kelompok class-class yang berelasi atau elemen pemodelan lainnya

Untuk melihat class-class dalam aplikasi sistem, atribut dan operasinya, dan juga hubungan masing-masing

Menampilkan objek/clas yang terlibat dalam satu aliran dalam suatu use case (Sequence dan Collaboration)

13


Component View● Sebuah komponen adalah modul fisik dari kode● Component view berisi informasi tentang pustaka

kode program, pustaka run-time, executable file, dan komponen lain dalam model.

● Component view memperlihatkan hubungan antar modul program

Component Modul fisik kode program

Component Diagram Memperlihatkan komponen-komponen dan hubungan diantaranya

Package Kelompok komponen yang berelasi

14


Deployment View● Fokus dengan sistem deployment, yang

mungkin berbeda dari arsitektur logika sistem.– Contoh: sistem secara logika memiliki arsitektur

three-tier. Sisi antarmuka ditempatkan pada satu mesin, sedangkan lapisan logika bisnis dan database ditempatkan di mesin lain.

Process Thread yang berjalan pada ruang memorinya sendiri

Processors

Device Sembarang perangkat keras tanpa kemampuan pemrosesan

Sembarang mesin dengan kekuatan pemrosesannya. Satu proses dapat dijalan pada satu atau lebih prosesor


Pendekatan 4+1 View


Philippe Kruchten's 4+1 view model

Logical View

Physical View

Process View

Development View

Use Case View


4+1● Logical View

– Deskripsi abstraksi dari bagian-bagian sistem. Digunakan untuk memodelkan apa yang menyusun sistem dan bagaimana antar bagian tersebut berinteraksi satu dengan lainnya. Tipe diagram UML yang digunakan : class, object, state machine, dan interaction diagrams.

● Process View– Menguraikan proses-proses dalam sistem yang ada

dalam sistem. Diagram: activity diagrams.

18


4+1● Development View

– Bagaimana bagian-bagian sistem diorganisasikan ke dalam modul-modul dan komponen.

– Sangat bermanfaat untuk mengatur lapisan-lapisan dalam arsitektur sistem.

– Berisi: package dan component diagram.● Physical View

– Bagaimana rancangan sistem dari 3 view sebelumnya diterapkan. Memperlihatkan peta deploy bagian-bagian abstrak fisik.

– Berisi : deployment diagram.

19


4+1● Use Case View

– Menguraikan fungsionalitas sistem yang sedang dimodelkan dari perspektif dunia luar.

– View ini diperlukan untuk menggambarkan apa yang dikerjakan sistem.

– Semua view lain bergantung pada use case view untuk mengarahkan view lain.

– View ini berisi: use case diagrams, descriptions, dan overview diagrams.


Use Case Diagram


Use Case● Sebuah use case adalah situasi dimana sistem Anda

digunakan untuk memenuhi satu atau lebih kebutuhan pemakai Anda.

● Use case merupakan awal yang sangat baik untuk setiap fase pengembangan berbasis objek, design, testing, dan dokumentasi.

● Use case menggambarkan kebutuhan sistem dari sudut pandang di luar sistem.

● Use case menentukan nilai yang diberikan sistem kepada pemakainya.


Use Case● Use cases hanya menetapkan apa yang seharusnya

dikerjakan oleh sistem, yaitu kebutuhan fungsional sistem.

● Use case tidak untuk menentukan kebutuhan nonfungsional, misalnya: sasaran kinerja, bahasa pemrograman, dsb.


Menangkap Kebutuhan Sistem● Contoh(Req.A.1):

– Weblog content management system akan membolehkan administrator untuk membuat blog account baru, rincian data personal blogger baru diverifikasi menggunakan database penulis.

● Blog Features– Weblog, atau blog, awalnya digunakan oleh pembuat

suatu web untuk menuliskan segala sesuatunya. – Blogger mengirimkan entri baru ke sistem, administrator

mengalokasikan account blog, dan sistem pada umumnya menyediakan ciri lain, seperti RSS feeds.


Actor● Langkah pertama untuk analisa kebutuhan

adalah mencari sesuatu yang berinteraksi dengan sistem Anda.

● Dalam use cases, sesuatu diluar sistem yang berinteraksi dengan sistem disebut actor.

● Actor class digunakan untuk memodelkan dan menyatakan peran untuk “pemakai” dari sistem, termasuk manusia dan sistem lain.


Actor● Actor memiliki karakteristik berikut:

– Actor adalah eksternal terhadap sistem.– Actor berinteraksi dengan sistem.

● Actor memanfaatkan fungsi yang disediakan sistem, termasuk fungsi aplikasi dan pemeliharaan.

● Actors bisa saja menyediakan fungsi ke sistem.● Actors bisa menerima informasi yang disediakan sistem. ● Actors bisa menyediakan informasi ke sistem.

– Actor class memiliki objek actor yang menyatakan actor tertentu.

● Actors sebaiknya diberi nama menggunakan kata benda


Pertanyaan pembantu● Siapa yang menggunakan sistem?● Siapa yang memasang sistem?● Siapa yang memulai sistem?● Siapa yang memelihara sistem?● Siapa yang mematikan sistem?● Sistem lain apa yang menggunakan sistem ini?● Siapa yang mengambil informasi dari sistem?● Siapa yang menyediakan informasi ke sistem?● Apakah segala sesuatu terjadi secara otomatis pada

waktu saat ini?


Cara lain...


Use Case● Use case class digunakan untuk memodelkan

dan menyatakan unit fungsi/layanan yang disediakan oleh sistem (or bagian sistem: subsistem atau class) ke pemakai.

● Use case dapat dilingkupi dengan batasan sistem yang diberi label nama sistem.

● Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke pemakai atau sistem eksternal.


Use case● Karakteristik use case:

– Use cases adalah interaksi atau dialog antara sistem dan actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.

– Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor lain. Use cases harus menyediakan nilai minimal kepada satu actor.

– Use cases bisa memiliki perluasan yang mendefinisikan tindakan khusus dalam interaksi atau use case lain mungkin disisipkan.

– Use case class memiliki objek use case yang disebut skenario. Skenario menyatakan urutan pesan dan tindakan tunggal.


Pertanyaan pembantu...● Fungsi apa yang diinginkan actor dari sistem?● Apakah sistem menyimpan informasi? Actor

apa yang akan membuat, membaca, mengubah atau menghapus informasi tersebut?

● Apakah sistem perlu untuk memberitahukan actor tentang perubahan kondisi internal?

● Apakah ada kejadian eksternal yang perlu diketahui sistem? Actor apa yang memberitahukan sistem tentang kejadian tersebut?


Contoh


Komunikasi● Sebuah garis komunikasi menghubungkan

actor dan use case untuk memperlihatkan peran serta actor dalam use case.


Komunikasi● Terkadang diagram UML memiliki komunikasi dengan

navigability (arah); – sebagai contohfor : diagram dengan panah pada satu

sisi menunjukkan aliran informasi antara actor dan use case, atau menunjukkan siapa yang memulai use case.

● Tujuan komunikasi adalah untuk memperllihatkan bahwa sebuah actor terlibat dalam use case, tidak untuk secara tidak langsung menyatakan pertukaran informasi dalam arah tertentu atau actor memulai use case.

● Informasi tersebut sudah tersebutkan dalam deskripsi rinci use case, sehingga tidak perlu menggunakan garis komunikasi navigation.


Batasan Sistem● Untuk memperlihatkan batasan sistem dalam

diagram use case, Anda dapat menggambarkan sebuah kotak yang melingkupi semua use case, namun actor tetap berada di luar kotak.


Tipe informasi Deskripsi Use Case


UseCase Desc


Hubungan Use Case● Hubungan antar use case lebih ditekankan pada

penguraian perilaku sistem kedalam sesuatu yang mudah diatur, daripada menambah baru.

● Contoh (Req.A.2)– CMS harus membolehkan administrator untuk

membuat personal Wiki baru, penyediaan informasi rinci penulis diuji menggunakan database author.

● Dalam blog, CMS punya sejumlah cara untuk bekerja dengan isinya. Satu mekanisme yang populer untuk pemeliharaan dokumen adalah dengan Wiki. Wiki memungkinkan penulis secara online membuat, mengubah dan menyambungkan bersama-sama halaman web (Wiki-web)


Req A.2


Desc Req.A.2


<<include>>● Ada sedikit kesamaan dalam Main Float antara

dua use case, yaitu memasukkan penulis detil dan verifikasi ke database.

● Kita dapat menambahkan use case baru yang dapat digunakan oleh kedua use case lain.

● Hubungan <<include>> mendeklarasikan bahwa use case use case penunjuk memakai secara penuh semua langkah dalam use case yang dimasukkan.


Contoh


Contoh Usecase Desc


Use case Desc


Use Case Desc


Inheritance use case● Dalam contoh kasus ini, bagaimana jika

ternyata CMS mendukung beberapa tipe blog account?

● Dapat menerapkan turunan use case.● Turunan Use case bermanfaat ketika Anda

ingin untuk memperlihatkan bahwa satu use case bertipe khusus dari use case lainnya.


Contoh inheritance


<<extend>>● Pemakaiannya sama seperti <<include>>

hanya saja untuk <<extend>> bersifat optional dan tergantung keputusan saat runtime atau saat penerapan sistem.

● Contoh:


Contoh


Selesai!

Terima kasih!

use case diagram

Documents