UML mendukung pengembangan aplikasi Kelas application partitioning Objek-objek Business Relationships Business Process Objek-objek Use Cases Sistem untuk skala yang luas Skenario Komponen Microsoft ActiveX/COM Microsoft ORDBMS Oracle CORBA OMG

USE CASE DIAGRAM Sebuah Use Case menggambarkan suatu urutan interaksi antara satu atau lebih aktor dan sistem. Menekankan pada “apa” yang diperbuat sistem, bukan “bagaimana”. Model elements : Use Case dan Actor. 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 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. 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 dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana” system mengerjakannya Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor. Use case dinotasikan dengan gambar (horizontal ellipse) Use case biasanya menggunakan verb Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama Sebuah use case bisa mempunyai dokumentasi Gunakan dengan lambang dibawah ini dan ditarik dengan garis putus tanpa panah Use Case - Use Case Diagram

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.

Actor memiliki karakteristik seperti 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

Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system Actor memberi input atau menerima informasi dari system Actor biasanya menggunakan Noun Actor digambarkan dengan gambar stick figure atau dengan gambar visual atauataudll Tidak boleh ada komunikasi langsung antar actor (Actors don’t interact with one another ) Indikasi > untuk sebuah actor yang merupakan sebuah system Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan) Actor - Use Case Diagram

Primary actor (aktor utama) memprakarsai sebuah use case. Jadi, suatu primary aktor memegang peran sebagai proaktif dan yang memulai aksi dalam sistem. Aktor lainnya yang berperan sebagai secondary aktor bisa saja terlibat dalam use case dengan menerima output dan memberikan input. Setidaknya satu actor harus mendapatkan nilai dari use case. Biasanya adalah primary aktor (actor utama). Berikut adalah gambar yang menjelaskan primary actor dan secondary actor:

Terdapat beberapa hal penting yang harus diperhatikan dalam penulisan actor dalam sebuah use case. Perhatikan gambar berikut :

Ketika menuliskan actor dalam sebuah use case, primary actor selalu ditempatkan di sebelah kiri dan secondary actor selalu ditempatkan di sebelah kanan. Hal ini berkaitan dengan bagaimana cara kita membaca sebuah use case (Budaya Barat cenderung membaca dari kiri ke kanan dan dari atas ke bawah). Pada gambar tersebut kita dapat melihat perbedaan bahwa aktivitas membeli dan membayar barang merupakan aktivitas utama konsumen (primary actor). Sedangkan kasir (secondary actor) adalah pelaku yang dilibatkan dalam aktivitas primary actor. Selain itu, setiap actor minimalkan dilibatkan oleh satu use case dan setiap use case minimal dilibatkan oleh satu actor.Actor biasanya menggunakan kata benda (noun)

Tidak boleh ada komunikasi langsung antar actor, seperti:

Aktor tidak boleh digambarkan di tengah-tengah use case, seperti:

Actor menggambarkan sebuah tugas/peran dan bukannya sebuah posisi atau jabatan. Contoh: Teller adalah menggunakan peran/tugas sedangkan Teller senior dan Teller Junior adalah menggunakan jabatan.

Komunikasi Sebuah garis komunikasi menghubungkan actor dan Use Case untuk memperlihatkan peran serta actor dalam Use Case. Terkadang diagram UML memiliki komunikasi dengan navigability (arah); sebagai contoh : 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.

Relasi dalam Use Case Ada 4 jenis relasi yang bisa digunakan pada Use Case Diagram: 1. Association antara Use Case dan actor Ujung panah pada association antara Use Case dan actor mengindikasikan siapa/apa yang meminta interkasi dan bukannya yang mengindikasikan aliran data. Sebaiknya gunakan garis tanpa panah untuk association antara Use Case dan actor.

Associaton antara Use Case dan actor yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan sistem anda.

2. Association antar Use Case > Ketika sebuah Use Case memerlukan /membutuhkan pemakaian fungsionalitas lain di dalam sistem, maka hubungan antara Use case tersebut dapat dikatakan sebagai include relationship. Untuk mengidentifikasi include relationship maka dalam penulisannya adalah “ >”.

a. Termasuk di dalam Use Case lain (required/diharuskan) b. Pemanggilan Use Case oleh Use Case lain c. Contonya adalah pemanggilan sebuah fungsi program d. Gambarkan association > secara horizontal e. Tanda panah terbuka harus terarah ke sub Use Case f. Tidak boleh actor dihubungkan pada Use Case >

> Extend relationship pada Use Case adalah suatu hubungan sebab akibat. Jika fungsi induk mempunyai extend relationship maka dapat diartikan bahwa fungsi Use Case induk tersebut dapat dilakukan jika fungsi extend dilakukan terlebih dahulu. Bentuk penulisan extend relationship adalah “ >”.

a. Perluasan dari Use Case lain jika kondisi atau syarat terpenuhi b. Kurangi penggunaan association Extend ini, terlalu banyak penggunaan association ini membuat diagram sulit dipahami c. Tanda panah terbuka harus terarah ke parent/base Use Case d. Gambarkan association extend secara vertikal (picture extending Use Case below than base/parent Use case) e. Tidak boleh actor dihubungkan pada Use Case >

3. Generalization/Inheritance antara Use Case Dibuat ketika ada sebuah keadaan yang lain/perlakuan khusus

4. Generalization/Inheritance antara actors Dibuat ketika ada sebuah aktor baru terbentuk dan mempunyai atribut dan metode yang sama dengan aktor yang sudah ada Inheriting actor di bawah parent/base actor