Use Case

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



a. Use Case View
● 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 berpusatpada 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.

b. Logical View
● 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.

Logical View
● 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 classsudah merupakan detil yang tergantung pada bahasa yang akan digunakan

● 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

● 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 system keseluruhan, bertanggung jawab untuk memastikan bahwa sistem memiliki arsitektur yang stabil
● Analis mengamai Class diagram untuk memastikan bahwa kebutuhan bisnis akan diterapkan dalam program.
● 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.
c. 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
d. 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.