CONTOH KASUS USE CASE DAN PENYELESAIANNYA

Dalam contoh kasus ini akan dimodelkan Sistem ATM Bank.

A.  Batasan Masalah
          Sistem ATM yang akan dibuat modelnya adalah sistem ATM sederhana dan umum dengan fungsi mendasar yaitu: mengambil uang tunai, melakukan transfer ke rekening tertentu pada bank yang sama dan memeriksa saldo.
          Sistem yang akan dimodelkan tidak mencakup beberapa fungsi ATM yang bergantung fasilitas tambahan dari bank misalnya membayar kartu kredit, membayar telpon, membayar tagihan kartu seluler, mengisi pulsa, membayar PBB, ATM bersama yang menerima berbagai kartu, dan lain-lain, karena layanan-layanan tersebut berbeda-beda tergantung dari operator/bank yang mengeluarkan ATM tersebut.

PEMODELAN ANALISIS (Elemen Model Analisis)

Model analisis harus dapat mencapai tiga sasaran utama yakni untuk :
• Menggambarkan apa yang dibutuhkan untuk pelanggan
• Membangun dasar bagi pembuatan desain perangkat lunak
• Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.

PEMODELAN ANALISIS (Pemodelan Data)

Pemodelan data menjawab serangkaian pertanyaan spesifik yang relevan dengan aplikasi pemrosesan data. Apakah objek data utama yang akan diproses oleh system ? Bagaimana komposisi dari masing-masing objek data dan atribut apa yang menggambarkan objek tersebut? Dimana objek saat ini berada? Bagaimana hubungan antara masing-masing objek data dan objek yang lainnya? Bagaimana hubungan objek dengan proses yang mentransformasikannya? 

PEMODELAN ANALISIS (Metode Analisis Klasik)

        

            Data Structure System Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur data..

Ken Orr memperluas kerja Warnier untuk mencakup pandangan yang lebih luas mengenai domain informasi yang telah dikembangkan kedalam DSSD.

PEMODELANANALISIS (Kamus Data)

         Kamus data telah diusulkan sebagai sebuah tata bahasa quasi-formal untuk menggambarkan kandungan dari objek yang didefinisikan selama analisis terstruktur. Notasi pemodelan yang penting ini telah didefinisikan sebagai berikut : Kamus data merupakan sebuah daftar  yang teroganisasi  dari elemen data yang berhubungan dengan system, dengan definisi yang tegar dan teliti sehingga pemakai dan analisis system akan memiliki pemahaman yang umum mengenai input, output, komponen penyimpan , dan bahkan kalkulasi inter-mediate.

PEMODELAN ANALISIS (Mekanik dari Analisis Terstruktur)

 1.  Membuat sebuah diagram hubungan Entitas

Diagram hubungan  entitas memungkinkan seorang perekayasa perangkat lunak untuk secara penuh menspesifikasikan objek data yang merupakan input dan output dari system. Pendekatan berikut ini perlu diketahui dalam membuat diagram Entitas :

ü  Selama pengumpulan persyaratan, pelanggan diminta untuk mendaftar ‘hal-hal’ yang akan dituju oleh proses bisnis dan aplikasi. ‘Hal-hal’ ini dimasukkan kedalam sebuah daftar objek data input dan output dan entitas eksternal yang menghasilkan atau mengkonsumsi informasi.

PEMODELAN ANALISIS (Pemodelan Tingkah Laku)

            Pemodelan tingkah laku merupakan suatu prinsip operasional untuk semua metode analisis persyaratan tetapi hanya versi analisis terstruktur yang luas yang memberikan suatu notasi bagi tipe pemodelan ini.

PEMODELAN ANALISIS (Pemodelan Fungsional&Aliran Informasi)

Analisis terstruktur dimulai sebagai sebuah teknik pemodelan aliran informasi. Sebuah sistem berbasis komputer direpresentasikan sebagai sebuah transformasi informasi. Sebagai contoh terlihat pada gambar 4.0 keseluruhan fungsi dari sistem tersebut diwakilkan sebagai transformasi informasi tunggal, yang ditulis sebagai gelembung didalam gambar. Satu input atau lebih diperlihatkan oleh anak panah yang diberi label , berasal dari entitas eksternal. Yang direpresentasikan sebagai sebuah kotak. Input mengendalikan transformasi tersebut untuk memproduksi informasi Output yang dilewatkan ke entitas eksternal.

USE CASE DIAGRAM

A.    Sejarah Use Case

Use Case diperkenalkan sebagai bagian dari metodologi pengembangan berorientasi obyek oleh Ivar Jacobson pada tahun 1992. Namun begitu, Larry Constantine, dkk, telah mengembangkan Use Case ini bukan hanya untuk penggunaan di pemrograman berorientasi obyek melainkan untuk keperluan pendefinisian kebutuhan dan desain User Interface. Setiap Use Case menggambarkan sebuah skenario di mana seorang user berinteraksi dengan sistem yang sedang dibuat untuk menyelesaikan satu tugas tertentu.

B.     Pengenalan Use Case Secara Umum

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  kata kerja. Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama. Secara umum use case adalah: Pola perilaku system dan urutan transaksi yang berhubungan yang dilakukan oleh satu actor.

·         Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”.

·         Menggambarkan kebutuhan system dari sudut pandang user

·         Mengfokuskan pada proses komputerisasi (automated processes)

·         Menggambarkan hubungan antara use case dan actor

·         Use case menggambarkan proses system (kebutuhan system dari sudut pandang user)

C.     Terminologi di dalam Use Case

Sebuah Use Case dapat dibuat dalam bentuk tekstual ataupun berbentuk diagram. Terminologi yang perlu dipahami di dalam Use Case adalah:

1. Aktor: adalah orang, organisasi, atau sistem eksternal yang berinteraksi dengan sistem yang akan dibuat
2. Use Case: menggambarkan serangkaian aksi yang terukur yang dilakukan oleh aktor terhadap sistem dan memberikan nilai tertentu terhadap aktor.
3. Hubungan atau Relasi: menggambarkan jenis interaksi antara aktor dengan use case, antara use case dengan use case, dan antara aktor dengan aktor.

d.      Berikut ini adalah contoh diagram Use Case untuk Sistem Pemesanan Makanan di Kantin Politeknik Telkom.

D.    Mendefinisikan Kebutuhan dengan Use Case

Menggambarkan Use Case hanyalah bagian kecil dari pendefinisian kebutuhan. Deskripsi tekstual yang lebih lengkap diperlukan untuk membantu desainer dan programmer di dalam pekerjaan desain dan kodind, serta diperlukan pula sebagai sarana komunikasi antara pemberi pekerjaan (project sponsor dan project stakeholder) dengan tim pelaksana proyek.

Berikut ini adalah langkah-langkah sederhana untuk mendefinisikan kebutuhan menggunakan Use Case:

a.       Berdasarkan rumusan masalah dan tujuan proyek, tetapkan sebuah sistem yang akan dibuat

Sistem adalah suatu himpunan keadaan yang memetakan serangkaian masukkan ke dalam sistem menjadi serangkaian keluaran dari sistem. Ia adalah himpunan terbatas yang memiliki batas-batas yang jelas yang memisahkannya dari sistem yang lain. Dalam langkah pertama ini, perjelaslah sistemnya, tentukan batas-batasnya, dan sistem apa saja yang berbatasan dengannya.

b.      Menetapkan Aktor

Setelah jelas definisi sistem yang akan dibuat, langkah kedua adalah menetapkan aktor yang terlibat di dalamnya. Aktor bisa berupa orang atau sistem lain di luar sistem yang sedang dibuat. Misalnya, GSM Model adalah sistem di luar sistem software SMS Gateway.

Catatan: bisa jadi banyak sekali aktor yang akan berinteraksi terhadap sistem yang dibuat, namun begitu tidak semua aktor perlu dipertimbangkan. Kadangkala ada faktor tertentu yang mengharuskan kita mengabaikannya. Jadikanlah itu sebagai batasan alih-alih memasukkannya ke dalam dokumen kebutuhan dan menyebabkan kalian menjadi sakit kepala nantinya.

c.       Menetapkan Use Case untuk Setiap Aktor

Untuk setiap aktor, tetapkanlah ‘kerja’ apa yang akan dia lakukan terhadap sistem. Misalnya, untuk aktor Mahasiswa, maka Use Casenya adalah ’memesan makanan’.

d.      Menetapkan skenario untuk setiap Use Case

Untuk setiap Use Case, buatkan sebuah skenario. Skenario yang dibuat dapat mirip sebuah skenario di dalam film. Skenario tersebut harus menyebutkan prekondisi (kondisi aktor dan sistem sebelum aktor melakukan aksi), postkondisi (kondisi aktor dan sistem setelah aktor melakukan aksi), langkah-langkah kejadian normal, langkah-langkah kejadian alternatif (bila langkah normal tidak terpenuhi), skenario pengecualian, prioritas skenario, aturan-aturan yang harus dipenuhi (misalnya rumus-rumus, formula, algoritma, dll), dan frekuensi kejadian dari Use Case ini.

Langkah keempat inilah yang terberat karena kita diminta untuk membayangkan apa yang seharusnya terjadi, apa yang mungkin terjadi, dan apa yang tidak boleh terjadi untuk setiap Use Case. Untuk itu, dalam menyusun skenario ini perlu dilibatkan calon pengguna sistem yang memahami skenario-skenario yang mungkin terjadi.

E.     Contoh Use Case

Use Case ID:	1
Nama Use Case:	Memesan Makanan
Created By:			Rachmat Gunawan
Date Created:			01/01/2009
Aktor:	Mahasiswa
Deskripsi:	Mahasiswa mengaksis Sistem Pemesanan Makanan dari intranet Politeknik Telkom, melihat menu untuk tanggal tertentu, memilih makanan, dan melakukan pemesanan untuk makanan untuk diantarkan ke alamat tertentu dalam rentang waktu 30 menit.
Preconditions:	1.      Mahasiswa Log In ke Sistem Pemesanan Makanan. 2.      Mahasiswa terdaftar di sistem pemesanan makanan untuk pembayaran
Postconditions:	1.      Pesanan tersimpan di dalam sistem dengan status ‘Diterima’. 2.      Data Keberadaan makanan dimutakhirkan sesuai dengan makanan yang dipesan.
Normal Course/ Skenario Normal	1.0 Pesan Satu Jenis Makanan 1.      Mahasiswa melihat menu untuk tanggal tertentu 2.      Sistem menampilkan menu yang tersedia untuk tanggal tersebut dan penawaran khusus di hari itu. 3.      Mahasiswa memilih satu atau lebih makanan dari menu. 4.      Mahasiswa menyatakan bahwa pemesanan telah selesai dan lengkap. 5.      Sistem menampilkan makanan yang dipesan, harga satuannya, dan harga keseluruhannya, termasuk pajak dan biaya pengantaran. 6.      Mahasiswa menyetujui persetujuan tersebut, bila tidak setuju atau ingin merubah, kembali ke nomor 3. 7.      Mahasiswa memilih cara pembayaran 8.      Sistem menerima cara pembayaran tersebut. 9.      Sistem mengirim email ke mahasiswa tersebut untuk konfirmasi menyangkuit detail pemesanan, harga, dan cara pembayaran. 10.  Sistem menyimpan pemesanan tersebut dalam database, mengirim email ke staf kafetaria, mengirimkan informasi stok makanan ke sistem inventory kafetaria.
Alternative Courses/ Skenario Lain	1.1 Memesan banyak makanan (mencabang setelah langkah ke 4) 1.      Mahasiswa ditanya untuk memesan makanan lain. 2.      kembali ke langkah nomor 2. 1.2 Memesan banyak makanan sejenis (setelah langkah ke 3) 1.      Mahasiswa diminta memasukkan jumlah makanan sejenis yang dipesan 2.      kembali ke langkah 4. 1.3. Memesan pesanan khusus hari itu (setelah langkah ke 2) 1.      Mahasiswa memesan makanan khusus hari itu. 2.      Kembali ke langkah 5.
Exceptions/ Pengecualian:	1.0.E.1 Sekarang sudah lewat waktu pemesanan (di langkah 1) 1. Sistem memberi tahu mahasiswa bahwa waktu pemesanan sudah habis untuk hari ini. 2a. Mahasiswa membatalkan pemesanan 2b. Sistem membatalkan Use Case. 3a. Mahasiswa meminta tanggal yang lain 3b. Sistem mengulangi Use Case. 1.2.E.1 Tidak dapat memenuhi pesanan banyak untuk makanan sejenis (langkah 1) 1.      Sistem memberi tahu mahasiswa bahwa makanan sejenis yang dapat dipesan telah mencapai maksimum 2.      Mahasiswa mengubah jumlah makanan sejenis yang dipesan atau membatalkan pemesanan makanan.
Includes:	None
Priority:	High
Frequency of Use:	Kira-kira 400 pelanggan, biasanya 1 kali pesan per hati
Aturan yang harus dipenuhi:
Kebutuhan khusus:	1.      Mahasiswa harus dapat membatalkan pemesanan makanan kapanpun sebelum mengkonfirmasi pemesanan. 2.      Mahasiswa harus dapat melihat seluruh makanan yang dia pesan dalam 6 bulan ke belakang. (Prioritas = medium)
Asumsi:	Asumsi bahwa 30% mahasiswa akan memesan makanan tiap hari.
Catatan:

 

F.      Actor

Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system. Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan. Actor memberi input atau menerima informasi dari system. Actor biasanya menggunakan Kata benda. Tidak boleh ada komunikasi langsung antar actor. Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system. Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan). Letakkan actor utama anda pada pojok kiri atas dari diagram.

G.    Association

·         Associations bukan menggambarkan aliran data/informasi

·         Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case

·         Ada 4 jenis relasi yang bisa timbul pada use case diagram

Ø  Association antara actor dan use case

Ø  Association antara use case

Ø  Generalization/Inheritance antara use case

Ø  Generalization/Inheritance antara actors

·         Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data

·         Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case

 

·         Association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda

 

H.    Association antara use case

1.      <<include>>         termasuk didalam use case lain (required) / (diharuskan)      

·         Pemanggilan use case oleh use case lain, contohnya adalah  pemanggilan sebuah fungsi program

·         Tanda panah terbuka harus terarah ke sub use case

·         Gambarkan association include secara horizontal

2.      <<extend>> perluasan dari use case lain jika kondisi atau syarat terpenuhi

·         Kurangi penggunaan association Extend ini, terlalu banyak  pemakaian association ini membuat diagram sulit dipahami.

·         Tanda panah terbuka harus terarah ke parent/base use case

·         Gambarkan association extend secara vertical

 

I.       Generalization/inheritance antara use case

Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case. Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition)