0394M-LN7
-
Upload
edward-simanungkalit -
Category
Documents
-
view
67 -
download
0
Transcript of 0394M-LN7
0394M – Analisa dan Perancangan Sistem Informasi
LECTURE NOTES
Use Case Modeling and Detailed Requirements (1)
Vina Georgiana, S.Kom., MM
0394M – Analisa dan Perancangan Sistem Informasi
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
0394M – Analisa dan Perancangan Sistem Informasi
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:
0394M – Analisa dan Perancangan Sistem Informasi
- 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.
0394M – Analisa dan Perancangan Sistem Informasi
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
0394M – Analisa dan Perancangan Sistem Informasi
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.),
0394M – Analisa dan Perancangan Sistem Informasi
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.
0394M – Analisa dan Perancangan Sistem Informasi
Gambar 7.2 A Simple Use Case With An Actor
Sumber : Satzinger et. Al. (2005, p215)
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.
0394M – Analisa dan Perancangan Sistem Informasi
Gambar 7.3 A Use Case Diagram of the Order-entry Subsystem for RMO,
showing a system boundary
Sumber : Satzinger et. Al. (2005, p216)
0394M – Analisa dan Perancangan Sistem Informasi
Gambar 7.4 A Use Case Diagram of the Customer support System (By Subsystem)
Sumber : Satzinger et. Al. (2005, p217)
0394M – Analisa dan Perancangan Sistem Informasi
<<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.
0394M – Analisa dan Perancangan Sistem Informasi
Gambar 7.5 An Example of the Order-entry Subsystem with <<includes>> use cases
Sumber : Satzinger et. Al. (2005, p219)
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.
0394M – Analisa dan Perancangan Sistem Informasi
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 :
0394M – Analisa dan Perancangan Sistem Informasi
• 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
Sumber : Satzinger et. Al. (2005, p221)
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.
0394M – Analisa dan Perancangan Sistem Informasi
Gambar 7.7 Intermediate Description of the Telephone Order Scenario for Create New Order
Sumber : Satzinger et. Al. (2005, p221)
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.
0394M – Analisa dan Perancangan Sistem Informasi
Gambar 7.8 Fully Developed Description of The Telephone Order Scenario for Create New
Order
Sumber : Satzinger et. Al. (2005, p223)
0394M – Analisa dan Perancangan Sistem Informasi
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.
0394M – Analisa dan Perancangan Sistem Informasi
Gambar 7.9 Fully Developed Description of The Web Order Scenario for Create New Order
Sumber : Satzinger et. Al. (2005, p224)
0394M – Analisa dan Perancangan Sistem Informasi
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
Sumber : Satzinger et. Al. (2005, p227)
0394M – Analisa dan Perancangan Sistem Informasi
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.
0394M – Analisa dan Perancangan Sistem Informasi
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>>
0394M – Analisa dan Perancangan Sistem Informasi
DAFTAR PUSTAKA
Satzinger, J. W., Jackson, R., & Burd, S. D. (2005). Object-Oriented Analysis and Design with
the Unified Process. Boston: Course Technology.