0394MAnalisadanPerancanganSistemInformasi

LECTURE NOTES

Use Case Modeling and Detailed Requirements (1)

Vina Georgiana, S.Kom., MM vinageorgiana@yahoo.com

0394MAnalisadanPerancanganSistemInformasi

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

0394MAnalisadanPerancanganSistemInformasi

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:

0394MAnalisadanPerancanganSistemInformasi

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

0394MAnalisadanPerancanganSistemInformasi

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 bendabenda 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

0394MAnalisadanPerancanganSistemInformasi

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.),

0394MAnalisadanPerancanganSistemInformasi

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.

0394MAnalisadanPerancanganSistemInformasi

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.

0394MAnalisadanPerancanganSistemInformasi

Gambar 7.3 A Use Case Diagram of the Order-entry Subsystem for RMO, showing a system boundary Sumber : Satzinger et. Al. (2005, p216)

0394MAnalisadanPerancanganSistemInformasi

Gambar 7.4 A Use Case Diagram of the Customer support System (By Subsystem) Sumber : Satzinger et. Al. (2005, p217)

0394MAnalisadanPerancanganSistemInformasi

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

0394MAnalisadanPerancanganSistemInformasi

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.

0394MAnalisadanPerancanganSistemInformasi

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 :

0394MAnalisadanPerancanganSistemInformasi

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.

0394MAnalisadanPerancanganSistemInformasi

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.

0394MAnalisadanPerancanganSistemInformasi

Gambar 7.8 Fully Developed Description of The Telephone Order Scenario for Create New Order Sumber : Satzinger et. Al. (2005, p223)

0394MAnalisadanPerancanganSistemInformasi

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.

0394MAnalisadanPerancanganSistemInformasi

Gambar 7.9 Fully Developed Description of The Web Order Scenario for Create New Order Sumber : Satzinger et. Al. (2005, p224)

0394MAnalisadanPerancanganSistemInformasi

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)

0394MAnalisadanPerancanganSistemInformasi

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.

0394MAnalisadanPerancanganSistemInformasi

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

0394MAnalisadanPerancanganSistemInformasi

DAFTAR PUSTAKA

Satzinger, J. W., Jackson, R., & Burd, S. D. (2005). Object-Oriented Analysis and Design with the Unified Process. Boston: Course Technology.