0394M-LN7

0394M – Analisa dan Perancangan Sistem Informasi

LECTURE NOTES

Use Case Modeling and Detailed Requirements (1)

Vina Georgiana, S.Kom., MM

[email protected]


LEARNING OUTCOMES

Mahasiswa mampu merancang Use Case Diagram dan membuat Use Case Description.

OUTLINE MATERI :

- Detailed Object-Oriented Requirements Definitions

- System Processes – A Use Case/Scenario View (Use Case and Actor)

- Automation Boundary and Organization

- <<includes>> Relationship

- Developing Use Case Diagram

- Use Case Detailed Description (Brief, Intermediate, dan Fully Develop)

- Activity Diagram Description


ISI

Detailed Object-Oriented Requirements Definition

Salah satu manfaat menggunakan model dalam mendokumentasikan user requirement

adalah untuk membantu sistem analist untuk berpikir lebih jelas dan hati-hati mengenai rincian

kebutuhan informasi dari stakeholder dalam perusahaan.

Pada gambar 7.1 dibawah ini, menggambarkan seorang sistem analist menggunakan

sekumpulan model berbasis Use Case dengan pendekatan berorientasi objek untuk

mengumpulkan user requirement. Setiap model menggambarkan aspek yang berbeda dari sebuah

sistem, tetapi tidak semua aspek perlu dikerjakan pada waktu yang bersamaan, mungkin pada

satu kondisi dan waktu tertentu, hanya perlu berfokus pada satu aspek saja, baru kondisi dan

waktu selanjutnya berfokus pada aspek lainnya. Walaupun tidak semua aspek akan dikerjakan

pada waktu dan kondisi yang bersamaan, tetapi seorang sistem analist perlu untuk memahami

semua aspek, karena pada akhirnya semua itu harus diselaraskan dan memberikan gambaran

akan isi dari sistem functional requirement. Sebenarnya, strategi umum dalam pemecahan

masalah hanya memecah masalah yang komplek menjadi lebih sederhana agar lebih mudah

untuk memahami dan mengatasinya.

Ada empat model yang digunakan untuk menggambarkan dan menjelaskan system use

case. Keempat model tersebut adalah :

- Use Case Diagram

- Use Case Description

- Activity Diagram

- System Sequence Diagram

Keempat model diatas, digunakan untuk menjelaskan sistem Use Case dari berbagai sudut

pandang.

Salah satu pendekatan untuk menentukan sistem requirement adalah menggunakan Use

Case driven. Dimana pendekatan ini merupakan pendekatan dasar dengan cara mengambil setiap

Use Case yang ada, satu persatu dan menjabarkan requirement-nya menjadi lebih terperinci,

dimana:


- Use Case diagram merupakan sebuah diagram yang menggambarkan berbagai peran user

dan cara para user berinteraksi dengan sistem. Use Case diagram juga berfungsi sebagai

semacam daftar isi untuk kegiatan–kegiatan bisnis yang harus didukung oleh sistem. Hal ini

digunakan untuk mengidentifikasi Use Case dari sistem baru. Dimana Use Case tersebut

menggambarkan bagaimana sistem tersebut akan digunakan dan actor mana yang akan

terlibat dalam kasus yang ada. Use Case Diagram dapat diturunkan dari event table (lihat

pertemuan yang lalu), dan ambil dari kolom berjudul "Use Case".

- Setiap Use Case harus dijelaskan secara rinci. Salah satunya adalah dengan menjabarkan dan

menulis deskripsinya dengan menggunakan narasi tentang langkah-langkah yang user dan

sistem lakukan secara bersama-sama untuk menyelesaikan Use Case. Masing-masing Use

Case juga dapat didefinisikan atau dijelaskan dengan menggunakan diagram, seperti activity

diagram.

- System Sequence Diagram (SSD) adalah diagram yang menunjukkan urutan pesan antara

actor eksternal dan sistem (skenario) didalam Use Case tersebut. SSD digunakan untuk

mendefinisikan input dan output beserta urutan sekuensial dari input dan output tersebut.

Selain menggunakan SSD, bisa juga menggunakan activity diagram untuk menunjukkan

langkah-langkah pengolahan dan interaksi antara actor dan sistem.


Gambar 7.1 Requirements Diagrams With UML Models

Sumber : Satzinger et. Al. (2005, p213)

Dari gambar 7.1 diatas, dapat dilihat bahwa model lain untuk menggambarkan model

adalah Statechart diagram. Statechart diagram bukan menggunakan Use Case driven tetapi

menggunakan pendekatan object driven. Dalam pandangan sistem yang berorientasi objek,

semua yang tercakup dalam sistem dianggap sebagai objek, dimana :

- Class Diagram digunakan untuk mengidentifikasi benda–benda yang dapat dilihat dalam

dunia nyata dan menentukan struktur class pemrogramannya, termasuk juga struktur

database-nya. Objek mengidentifikasikan problem domain class. Class ini bisa berupa benda

yang sifatnya konkret / terlihat (seperti pelanggan, produk, dll) dan hal-hal yang sifatnya

lebih abstrak (seperti order, airplane flight, dll). Membangun sebuah class diagram


membantu mengidentifikasi informasi tentang obyek dunia nyata yang akan menjadi bagian

dari sistem baru.

- Statechart diagram adalah diagram yang menunjukkan daur hidup dari objek dalam states

dan transisinya. Statechart diagram menggambarkan kumpulan status dari setiap objek.

Dengan kata lain, sebuah Statechart diagram mengidentifikasi kondisi status dan proses yang

terjadi dalam sebuah objek, oleh sebab itu setiap objek harus dibuatkan Statechart

diagramnya. Dalam fase perancangan, Statechart diagram juga digunakan untuk

mengidentifikasi berbagai states dan event-event yang dapat diproses dari sistem itu sendiri.

Jadi, Statecharts dapat digunakan sebagai alat analisis atau alat desain.

System Processes – A Use Case/Scenario View

Sistem analist mendefinisikan Use Case pada dua level, yaitu level overview dan level

rinci. Event table dan Use Case diagram memberikan gambaran umum (overview) dari semua

Use Case dalam sistem. Informasi rinci tentang setiap Use Case digambarkan dengan Use Case

description, activity diagram, dan SSD, atau kombinasi dari ketiga model tersebut.

1. Use Cases dan Actor

Actor dan source memiliki definisi yang sedikit berbeda, dimana;

• Source merupakan orang atau benda yang menginisiasi kejadian bisnis. Source ini

bisa berupa pelanggan, dan selalu merupakan eksternal yang masuk ke sistem,

termasuk sistem manual.

• Actor merupakan orang atau benda (bisa juga sistem lain) yang berinteraksi langsung

dengan sistem. Actor selalu di luar batas automation boundary tetapi dapat menjadi

bagian dari sistem manual. Kita harus memastikan bahwa actor harus memiliki

kontak langsung dengan sistem otomatis.

Salah satu cara untuk membantu mengidentifikasi actor pada tingkat yang detail adalah

dengan mengasumsikan bahwa actor (bahkan untuk actor yang berjenis bukan manusia) harus

memiliki fungsi atau tugasnya. Cara lain untuk menentukan actor adalah melihat peran actor

tersebut dalam sistem. Misalnya, dalam kasus RMO (baca kasusnya di buku Satzinger et. al.),


Use Case ‘Create new order’ mungkin melibatkan order clerk yang menerima pesanan

pelanggan melalui telepon. Dengan demikian, actor-nya adalah order clerk karena order clerk

yang langsung berhubungan dengan sistem (aplikasi Create new order), atau, pelanggan dapat

menjadi actor jika pelanggan melakukan pesanan langsung melalui sistem, misalkan si

pelanggan memesan melalui Internet. Sedangkan cara terakhir untuk mengidentifikasikan actor

dan use case dengan melihat bahwa use case merupakan tujuan akhir yang ingin dicapai oleh

actor. Misalnya, Order clerk menggunakan system untuk membuat surat order. Dengan

pernyataan tersebut dapat diidentifikasikan bahwa, order clerk adalah actor, dan membuat surat

order adalah Use Casenya.

2. Use Case Diagram

Gambar 7.2 dibawah ini merupakan bentuk/contoh sederhana dari use case diagram.

Simple stick figure (bentuk orang) digunakan untuk mewakili actor yang biasanya berupa

manusia dan gambar tangan menunjukkan bahwa actor bisa mengakses sistem secara langsung.

Use Case sendiri dilambangkan dengan sebuah lingkaran oval dengan diberi nama di dalamnya.

Garis penghubung antara actor dan use case menunjukkan actor yang menggunakan atau

memanfaatkan Use Case.

Perlu dipahami, bahwa Actor juga dapat berupa sistem lain yang berhubungan langsung

dengan sistem yang sedang dikembangkan. Dalam hal ini nama actor harus diberikan dengan

tepat dan harus mencerminkan wujud dari actor tersebut. Actor yang berupa sistem lain yang

berinteraksi dengan sistem yang dikembangkan bisa berupa simple stick figure (bentuk orang)

tetapi harus diberi nama yang jelas akan sistem tersebut. Contohnya, sebuah actor diberi nama

subsistem pembelian apabila actor yang berhubungan tersebut merupakan subsistem pembelian

yang berinteraksi dengan sistem yang sedang dikembangkan. Actor yang berupa subsistem ini

bisa juga (sebaiknya) digambarkan dengan bentuk persegi panjang.


Gambar 7.2 A Simple Use Case With An Actor


Automation Boundary and Organization

Automation boundary merupakan garis yang digambarkan mencakup semua use-cases

yang terdapat di sistem. Hal ini mendefinisikan antarmuka antara lingkungan para actor dengan

komponen internal sistem komputer. Gambar 7.3 merupakan contoh dari use case yang

diperluas. Coba amati gambar 7.2 diatas dan bandingkan dengan gambar 7.3 dibawah ini.

Gambar 7.3 dibawah ini memasukkan use case tambahan kedalam automation boundary dan

actor tambahan. Sehingga, dalam use case tersebut baik order clerk maupun pelanggan dapat

mengakses sistem secara langsung.

Sedangkan garis relationship menunjukkan bahwa masing-masing actor dapat

berinteraksi dengan setiap use case yang ada. Gambar 7.4 menunjukkan berbagai cara untuk

mengatur Use Case untuk menggambarkan interaksi antara use case dan actor.


Gambar 7.3 A Use Case Diagram of the Order-entry Subsystem for RMO,

showing a system boundary



Gambar 7.4 A Use Case Diagram of the Customer support System (By Subsystem)



<<includes>> Relationship

Seiring pengembangan dari sebuah use case diagram, kemungkinan akan muncul sebuah

Use Case yang perlu menggunakan fungsi yang terdapat di service subrutin umum. Dikatakan

subrutin umum, karena subroutine ini banyak digunakan oleh use case-use case yang lain,

sehingga subroutine umum yang melaksanakan fungsi tersebut harus digambarkan menjadi

sebuah use case tambahan. Contoh, Gambar 7.5 menunjukkan adanya Use Case tambahan yaitu

‘Validate customer account’, yang digunakan oleh kedua Use Case lainnya (yaitu Create new

order dan Update order). Hubungan antara Use Case ini dilambangkan oleh garis yang

dihubungkan dengan panah. Arah panah menunjukkan yang menggunakan Use Case

dimasukkan sebagai bagian dari use case utama. Hubungan tersebut dapat dibaca Create new

Order «includes» Validate customer account. Kadang-kadang hubungan ini disebut sebagai

«includes», atau <<uses>>. Perlu diperhatikan bahwa <<includes>> relationship ini hanya

digunakan kalau satu use case (subroutine umum) di akses oleh lebih dari dua use case. Kalau

hanya satu use case yang menggunakan subroutine umum, maka subroutine umum tersebut tidak

perlu digambarkan dengan use case terpisah yang dihubungkan dengan <<includes>>

relationship.


Gambar 7.5 An Example of the Order-entry Subsystem with <<includes>> use cases


3. Developing Use Case Diagram

Bisnis event awalnya digunakan untuk mengidentifikasi Use Case. Use Case tersebut

sering dilakukan revisi oleh sistem analist. Sistem analist membuat penyesuaian dengan

memisahkan, baik peristiwa tunggal ke dalam beberapa Use Case atau menggabungkan beberapa

peristiwa dalam satu Use Case. Use Case tambahan biasanya diidentifikasi dengan cara melihat

apakah mereka mengandung hubungan «includes»? Kalau ada, sebuah use case besar dapat

dikembangkan/dipecah menjadi dua Use Case, atau ketika sebuah Use Case saat didefinisikan

dan dikenali sebagai sebuah subrutin umum.


Ketika sistem analist bergerak dari bisnis event untuk membuat use case diagram, maka

sistem analist tersebut harus bisa membedakan antara temporal event dan state event. Dengan

asumsi menggunakan teknologi yang sempurna, maka proses untuk membuat use case diagram

dari bisnis event membutuhkan dua langkah yang dapat dilakukan secara berulang. Kedua

langkah tersebut adalah;

• Identifikasi si actor untuk setiap use case. Ingat bahwa actor (apakah antarmuka manusia

atau sistem) benar-benar menyentuh system (automation) boundary. Beri nama actor

dengan peran yang ia lakukan dalam sistem, bukan nama actor tersebut, misalnya, Order

Entry Clerk (bukan Bob).

• Setelah peran actor telah diidentifikasi, mengambil informasi dari peristiwa bisnis yang

menggambarkan respon sistem terhadap peristiwa bisnis. Use Case mungkin perlu

disesuaikan sedemikian rupa sehingga mereka mewakili tujuan bersama (unit kerja)

bahwa sistem tersebut akan mendukung, misalnya, menganggap tugas seperti "proses

penjualan". Pada penyelesaian tujuan tersebut, data sistem harus stabil untuk beberapa

waktu.

4. Use Case Detailed Description

Didalam sebuah use case berisi urutan langkah-langkah yang perlu dilakukan oleh system

untuk menyelesaikan suatu proses bisnis. Selain berisi urutan langkah proses, didalam sebuah

use case mungkin juga mempunyai beberapa variasi dari langkah-langkah bisnis. Misalkan, dari

gambar 7.5 diatas, use case “Create new order" akan memiliki aliran kegiatan yang berbeda

untuk setiap actor yang memanggil use case tersebut. Lebih jelasnya lagi, use case “Create new

order” melalui telepon akan memiliki proses yang berbeda dengan use case “Create new order”

melalui internet. Setiap aliran kegiatan adalah sebuah urutan untuk use case “Create new order’.

Uraian dari contoh tersebut disebut dengan skenario.

Dengan demikian, skenario adalah kegiatan internal yang unik dalam use case dan

merupakan jalur unik use case. Untuk memperjelas proses bisnis yang ada di use case, seorang

sistem analist harus menggabungkan use case dengan berbagai diagram dan deskripsi. Kalau

menggunakan deskripsi use case, biasanya deskripsi tersebut ditulis pada tiga tingkatan yang

terpisah, yaitu :


• Brief description

• Intermediate description

• Fully developed description.

A. Brief Description

Brief description digunakan untuk menjelaskan aktifitas yang ada didalam use case. Tidak

perlu dengan penjelasan yang detail dan rumit, cukup dideskripsikan dengan sederhana saja.

Gambar 7.6 dibawah ini, merupakan contoh dari brief description untuk Use Case “Create

new order’

Gambar 7.6. Brief Description of Create New Order Use Case


B. Intermediate Description

Penggunaan intermediate description untuk memperluas/mendetailkan penjelasan singkat

yang ada di brief description, dimana deskripsi ini berguna untuk memasukkan aliran

kegiatan internal dari Use Case. Gambar 7.7 menunjukkan intermediate description yang

mendokumentasikan Use Case “Create new order”. Intermediate description yang pertama

melibatkan seorang pegawai menggunakan telepon dan yang kedua melibatkan seorang

pelanggan menggunakan Internet. Dalam banyak hal, penjelasan ini menyerupai jenis tulisan

yang disebut structured English (pada pendekatan terstruktur), yang dapat mencakup urutan,

keputusan, dan blok pengulangan.


Gambar 7.7 Intermediate Description of the Telephone Order Scenario for Create New Order


C. Fully Developed Description

Fully Developed Description menghasilkan pemahaman yang paling lengkap tentang proses

bisnis dan sistem pendukung. Gambar 7.8 adalah contoh Fully Developed Description yang

dikembangkan dari Use Case Create new order melalui telepon. Gambar 7.8 juga dapat

berfungsi sebagai template standar untuk mendokumentasikan Fully Developed Description

untuk Use Case dan skenario lainnya.


Gambar 7.8 Fully Developed Description of The Telephone Order Scenario for Create New

Order



Penjelasan :

• Kotak baris pertama dan kedua digunakan untuk mengidentifikasi Use Case dan

skenario dalam Use Case yang sedang didokumentasikan.

• Kotak baris ketiga mengidentifikasi pemicu yang memulai Use Case.

• Kotak baris keempat adalah deskripsi singkat dari use case atau skenario.

• Kotak baris kelima mengidentifikasi actor atau pelaku.

• Kotak baris keenam mengidentifikasi Use Case lainnya dan cara mereka berhubungan

dengan Use Case, misalnya, hubungan <<includes>>.

• Kotak baris ‘Stakeholder’ mengidentifikasi pihak yang berkepentingan-selain actor

tertentu.

• Dua kotak baris berikutnya memberikan informasi penting tentang keadaan sistem

sebelum dan sesudah kasus penggunaan mengeksekusi, prasyarat menelepon dan

kondisi pasca. Prasyarat adalah seperangkat kriteria yang harus benar sebelum awal

dari sebuah use case. Prasyarat dapat diidentifikasi dengan pertanyaan-pertanyaan

berikut:

o Objek apa saja yang harus ada dalam sistem (atau database)?

o Bagaimana hubungan spesifik di antara objek - objek, dan hubungan manakah

yang penting?

o Nilai spesifik apakah yang harus diidentifikasi?

Gunakan tiga pedoman yang sama untuk prasyarat untuk menentukan kondisi

posting: berkonsentrasi pada apa objek harus ada, hubungan apakah yang harus ada,

dan nilai – nilai apakah yang penting. Selain itu, pastikan untuk menyertakan satu

elemen lain-mengidentifikasi objek yang diperbarui atau dimodifikasi.

• Dua kotak baris terakhir dalam template menggambarkan aliran rinci kegiatan use

case, dimana rincian kegiatan use case ini harus sesuai dengan lingkup use case

tersebut. Mengidentifikasi lingkup use case merupakan salah satu pertimbangan yang

sangat penting. Ruang lingkup dari use case dimulai ketika sistem berada pada titik

yang stabil dan saat berakhir juga harus mengembalikan ke titik yang stabil.


Gambar 7.9 Fully Developed Description of The Web Order Scenario for Create New Order



5. Activity Diagram Description

Activity diagram adalah jenis diagram UML standar, dimana diagram ini berguna untuk

mendokumentasikan workflow dari proses bisnis, serta aliran kegiatan untuk setiap skenario use

case. Activity diagram juga dapat membentuk dasar dari system sequence diagram (SSD).

Gambar 7.10 adalah gambar activity diagram yang mendokumentasikan skenario Use Case yang

ditunjukkan pada Gambar 7.8.

Gambar 7.10 Activity Diagram of the Telephone Order Scenario



Activity diagram dapat digunakan untuk mendukung setiap tingkat deskripsi use case.

Keunggulan utama dari diagram ini ada pada aspek visual activity-nya. Biasanya cara

memandang sebuah proses bisnis seorang user akan berbeda dengan seorang pengembang.

Dimana seorang user lebih melihat dari sisi proses dan nilai bisnisnya, sedangkan seorang

pengembang lebih melihat dari sisi teknikalnya. Hal tersebut akan menjadi kendala yang sangat

besar, terutama saat implementasi. Oleh sebab itu, persepsi dari pengguna dan pengembang

harus disamakan terlebih dahulu. Dengan Activity diagram, pengetahuan dan pengamatan dari

user dan pengembang akan (mungkin) lebih mudah untuk disamakan, hal ini disebabkan karena

activity diagram mampu menjelaskan aktifitasnya secara visual. Akibat dari semua itu maka

kemungkinan untuk kolaborasi juga meningkat. Kolaborasi tersebut meliputi dokumentasi dari

use case.


SIMPULAN

• Sebuah use case terdiri dari actors, use cases, dan connecting lines. Use case

mengidentifikasi fungsi tunggal yang mendukung sistem. Actor merepresentasikan peran dari

seseorang atau sesuatu yang menggunakan sistem. Connecting lines mengindikasikan actor

mana yang berhubungan dengan use case. Use case dapat juga melibatkan use case lainnya

sebagai subrutin umum, jenis hubungan ini dikenal dengan relasi <<includes>>


DAFTAR PUSTAKA

Satzinger, J. W., Jackson, R., & Burd, S. D. (2005). Object-Oriented Analysis and Design with

the Unified Process. Boston: Course Technology.

0394M-LN7

Documents

use casescenario view

case modeling

activity diagram description

seperti activity diagram

membangun sebuah class

keempat model tersebut

p213 dari gambar

pada gambar