PRAKTIKUM ANALISIS DAN PERANCANGAN SISTEM INFORMASI

Presentasi berjudul: "PRAKTIKUM ANALISIS DAN PERANCANGAN SISTEM INFORMASI"— Transcript presentasi:

1 PRAKTIKUM ANALISIS DAN PERANCANGAN SISTEM INFORMASI
Hendro Gunawan, S.Si., M.T.

2 SASARAN Setelah mempelajari materi ini, mahasiswa mampu
Memahami teknik untuk mendokumentasikan kebutuhan dengan menggunakan use case. Mengerti komponen-komponen use case diagram. Mampu mencari dan menemukan aktor dan use case dari suatu spesifikasi. Mampu membuat deskripsi sebuah use case

3 … pendahuluan … Hasil dari aktivitas requirement gathering perlu didokumentasi untuk selanjutnya diproses dalam menentukan spesifikasi kebutuhan perangkat lunak. Salah satu tool yang sering digunakan saat ini adalah Unified Modeling Language. Komponen diagram yang digunakan untuk dokumentasi kebutuhan adalah use case diagram.

4 UNIFIED MODELLING LANGUAGE
Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

5 UNIFIED MODELLING LANGUAGE
UML mendefinisikan diagram-diagram berikut ini : use case diagram class diagram behaviour diagram : -- statechart diagram -- activity diagram interaction diagram : -- sequence diagram -- collaboration diagram component diagram deployment diagram

6

7 Use case diagram Use case modeling adalah suatu proses untuk membuat model fungsi-fungsi dari sistem dari kejadian-kejadian bisnis, siapa yang melakukannya, dan bagaimana sistem bereaksi terhadap suatu kejadian. Use case modeling mengidentifikasi dan menjelaskan fungsi-fungsi sistem dari perspektif pengguna eksternal dengan menggunakan tools yang disebut use case. Use case adalah serangkaian langkah-langkah yang saling berhubungan (skenario), baik otomatis maupun manual, dengan tujuan untuk menyelesaikan suatu kegiatan bisnis tunggal.

8 Use case Use case menggambarkan fungsi-fungsi sistem dari perspektif pengguna luar. Use case adalah hasil dari dekomposisi lingkup fungsi-fungsi dari sistem menjadi statement-statement yang lebih kecil mengenai fungsional oleh fungsi-fungsi sistem. Pembuatan use case sudah dibuktikan merupakan suatu teknik yang baik untuk mengerti lebih baik dan mendokumentasi kebutuhan sistem. Use case sendiri bukan sebagai kebutuhan fungsional, tetapi ceritanya (skenario) yang diceritakan dari use case menangkap essensi dari satu atau lebih kebutuhan- kebutuhan. Use case diawali atau dipicu oleh pengguna eksternal atau sistem yang disebut actor.

9 Keuntungan Use Case Sebagai dasar untuk membantu mengidentifikasi objek-objek dan hubungan tingkat tinggi dan tanggung jawab masing-masing. Sebagai gambaran dari behavior sistem yang akan dibuat dari sisi pengguna eksternal. Sebagai alat yang efektif untuk memvalidasi kebutuhan. Sebagai alat komunikasi yang efektif Sebagai dasar untuk melakukan perencanaan testing. Sebagai dasar untuk melakukan pembuatan user manual.

10 … komponen use case … Actor: Someone/something outside the system that interacts with the system Use Case: Defines a piece of functionality of the system Communication – Association: Shows the Actor and the Use Case communicate Use Case Specification: Basic flow of events, alternate flows, error flows and sub-flows as appropriate Sumber : IBM software group

11   Lambang Use Case

12 USE CASE 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

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

14 Empat Tipe Aktor Primary business actor
Pihak yang secara utama diuntungkan oleh eksekusi Usecase Cth: karyawan yang menerima pembayaran gaji Primary system actor Pihak yang secara langsung berinteraksi dengan sistem untuk memulai kejadian bisnis atau sistem Cth: Teller bank menginput informasi deposit External server actor Pihak yang merespon permintaan dari usecase Cth: lembaga perkreditan mengotorisasi pembuatan kartu kredit External receiver actor PIhak yang bukan aktor utama tetapi menerima suatu nilai dari Usecase Cth: Bagian gudang menerima slip pengepakan No additional notes.

15 Sample Use-Case Model Diagram

16 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

17 Association antara actor dan use case
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

18 Association - Use Case Diagram
<<include>> termasuk didalam use case lain (required) / (diharuskan) Pemanggilan use case oleh use case lain contohnya adalah Pemanggilan sebuah fungsi program Gambarkan association <<include>> secara horizontal Tanda panah terbuka harus terarah ke sub use case Tidak boleh actor dihubungkan pada use case <<include>> <<include>>

19 Association - Use Case Diagram
<<extend>> Perluasan dari use case lain jika kondisi atau syarat terpenuhi (Optional Behaviour) 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 (picture extending use case below than base/parent use case) Tidak boleh actor dihubungkan pada use case <<extend>> <<extend>>

20 Association - Use Case Diagram
Generalization/inheritance Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum Ketika beberapa aktor, sebagai bagian dari peranannya, memainkan peranan yang lebih general, maka dapat dibuat relasi antar aktor, relasi generalization Generalization/inheritance antara use case Dibuat ketika ada sebuah keadaan yang lain/perlakuan khusus Inheriting use case dibawah base/parent use case Generalization/inheritance antara actor Dibuat ketika ada sebuah actor baru terbentuk dan mempunyai atribut dan methode yang sama dengan actor yang sudah ada Inheriting actor dibawah base/parent actor

21

22 System Boundary Boxes - Use Case Diagram
Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of of your system). Sebagai bagian dari pemodelan, batasan sistem (boundaries of the system) harus didefinisikan. Penetapan batasan menentukan mana yang berada dalam sistem dan mana yang berada di luar sistem. Contoh:

23 Airport Check-In and Security Screening

24 Online Shopping

25

26

27 DESKRIPSI USE CASE

28 … deskripsi use case … A use case description is a specification of the interaction between a system and the actors in a use case.

29 … deskripsi use case … Setiap use case harus mencakupkan rincian apa yang harus dilakukan untuk memenuhi fungsionalitas. Rincian fungsionalitas mencakup Fungsionalitas dasar Fungsionalitas Alternatif Kondisi error Keadaan atau kondisi yang harus dipenuhi sebelum use case dijalankan dan setelah use case selesai dijalankan.

30 … template deskripsi use case
Nama Use Case Actor Deskripsi Singkat Pre Condition Flow of Event Post Condition

31 … pre condition … Pre condition (pra kondisi) menyatakan (pra syarat) apa yang harus ada sebelum use case dijalankan. Pre condition harus benar atau terpenuhi supaya fungsionalitas yang dinyatakan dalam use case bisa terpenuhi.

32 … post condition … Post condition menyatakan apa yang didapat atau terjadi setelah use case dijalankan. Post condition merupakan kondisi yang akan benar atau terpenuhi setelah fungsionalitas dijalankan.

33 … flow of event … Menyatakan langkah-langkah dalam use case.
deklaratif, time-ordered Dari sudut pandang aktor Dimulai atau diinisiasi oleh aktor yang memicu berjalannya use case. Good way to start … Use case dimulai ketika <aktor> <aktivitas> Misal : Use case dimulai ketika pelanggan memesan produk

34 … flow of event … Langkah-langkah harus jelas dan tidak menimbulkan ambiguitas … Contoh : Detil pelanggan dimasukkan. Mengapa langkah di atas dianggap tidak jelas … ?

35 … flow of event … Langkah-langkah harus jelas dan tidak menimbulkan ambiguitas … Contoh : Detil pelanggan dimasukkan. Siapa yang memasukkan detil pelanggan ? Informasi apa saja yang dimasukkan sebagai “detil pelanggan”

36 … basic flow … Menyatakan langkah-langkah yang terjadi di mana semuanya berjalan dengan baik happy day scenario Harus ada satu basic flow untuk setiap use case. Berisi sederatan langkah tanpa ada percabangan (if) atau alternatif. Pada setiap langkah, asumsikan semua berjalan dengan benar.

37 … alternative flow … Berisi langkah-langkah yang dipandang bukan sebagai normal flow Memungkinkan flow yang berbeda terjadi. Termasuk dokumentasi langkah yang dilakukan jika terjadi error.

38 … alternative flow … Menemukan alternatif flow
Untuk setiap langkah dalam basic flow …. Apakah ada aksi lain yang dapat dilakukan ? Apakah ada kemungkinan terjadinya kesalahan ? Apakah ada perilaku lain yang bisa terjadi kapan saja ?

39 … alternative flow … Beberapa contoh yang mengakibatkan alternative flow .. Aktor membatalkan operasi atau aktivitas Aktor meminta bantuan (help) Aktor memberikan data tidak lengkap atau data yang salah. Sistem crash Aktor memilih alternative lain

40 … guideline menulis deskripsi uc
Tuliskan setiap langkah dalam SVD[PI] – Subject Predicate Direct object Proposition Indirect object.* Nyatakan dengan jelas siapa/apa inisiator aksi dan siapa yang terkena atau penerima aksi (receiver) Biasanya inisiator adalah subject dan receiver adalah direct object. Tuliskan setiap langkah dalam perspektif independen (bukan inisiator atau receiver) * tidak semua langkah mungkin bisa menggunakan bentuk ini, akan tetapi jika memungkinkan gunakan bentuk ini.

41 … guideline menulis deskripsi uc
Tuliskan setiap langkah dalam level abstraksi yang sama. Pastikan bahwa use case berisi sederatan aksi. Setiap use case pada dasarnya melakukan sebuah transaksi, sehingga terdiri atas 4 bagian : Aktor menginisiasi use case dengan mengirimkan request ke sistem. Sistem memastikan request valid. Sistem memproses request Sistem mengirimkan pada aktor hasil proses

42 … guideline menulis deskripsi uc
KISS – Keep It So Simple

43

44 Sample Expanded Version of a Use-Case Narrative
Teaching Notes Precondition – A constraint on the state of the system before the use case can be executed. Trigger – The event that initiates the use case. Typical course of events – The normal sequence of activities performed by the actor(s) and the system to satisfy the goal of the use case. Alternate courses – The behaviors of the use case if an exception or variation to the typical course occurs. Conclusion – When the use case successfully ends. Postcondition – A constraint on the state of the system after the use case has successfully executed. Business rules – Policies and procedures of the business that the system must abide by. Implementation constraints and specifications – Any nonfunctional requirements that may impact the realization of the use case. Assumptions – Assumptions made by the author. Open issues – Issues that need to be resolved before the use case can be finalized. continued

45 Sample Expanded Version of a Use-Case Narrative (cont)
Teaching Notes Precondition – A constraint on the state of the system before the use case can be executed. Trigger – The event that initiates the use case. Typical course of events – The normal sequence of activities performed by the actor(s) and the system to satisfy the goal of the use case. Alternate courses – The behaviors of the use case if an exception or variation to the typical course occurs. Conclusion – When the use case successfully ends. Postcondition – A constraint on the state of the system after the use case has successfully executed. Business rules – Policies and procedures of the business that the system must abide by. Implementation constraints and specifications – Any nonfunctional requirements that may impact the realization of the use case. Assumptions – Assumptions made by the author. Open issues – Issues that need to be resolved before the use case can be finalized. continued

46 Sample Expanded Version of a Use-Case Narrative (cont)
Teaching Notes Precondition – A constraint on the state of the system before the use case can be executed. Trigger – The event that initiates the use case. Typical course of events – The normal sequence of activities performed by the actor(s) and the system to satisfy the goal of the use case. Alternate courses – The behaviors of the use case if an exception or variation to the typical course occurs. Conclusion – When the use case successfully ends. Postcondition – A constraint on the state of the system after the use case has successfully executed. Business rules – Policies and procedures of the business that the system must abide by. Implementation constraints and specifications – Any nonfunctional requirements that may impact the realization of the use case. Assumptions – Assumptions made by the author. Open issues – Issues that need to be resolved before the use case can be finalized.

47 ACTIVITY DIAGRAM

48 ACTIVITY DIAGRAM Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram

49 Simbol Activity Diagram

50 CONTOH ACTIVITY DIAGRAM

51 … your turn … Pada ATM Bank A, seorang nasabah dapat melakukan penarikan, penyetoran, menampilkan jumlah saldo, melakukan transfer dana, mengubah PIN ATM ke bank, dan melakukan pembayaran tagihan/kredit ke system credit bank. Gambarkan Use Case Diagram dan deskripsi use case dari skenario diatas !

52 Terima kasih...