Pertemuan 18 Aplication Domain Matakuliah : M0086/Analisis dan Perancangan Sistem Informasi Tahun : 2005 Versi : 5 Pertemuan 18 Aplication Domain

Learning Outcomes Pada akhir pertemuan ini, diharapkan mahasiswa akan mampu : Mahasiswa dapat Memisahkan Object dengan Class pada Aplication Domain dan Problem Domain (C4) Mahasiswa dapat Menemukan Actor dan Use Case (C3) Mahasiswa dapat Membuat diagram / skema Use Case (C4)

Outline Materi Menentukan Actor Menentukan Use Case

Dasar Usage Analysis Tentukan application domain dengan use cases. Evaluasi use case bekerja sama dengan users. Perhatikan perubahan organisasi yang dapat mengubah application domain

Menentukan Actors dan Use Cases Berdasarkan pekerjaan dan pembagian pekerja Identifikasikan actors Perhatikan seseorang yang berperan dengan peran yang sama Terapkan pada sistem seperti pada orang atau user Menerangkan actor Masukan tujuan actor, karakteristik dan contoh Jelaskan use cases Gunakan statecharts dan atau dengan kalimat Buatlan sederhana dan tanpa detil yang tidak diperlukan

Analisis Pekerjaan Perlu mengerti hubungan dari sistem pada application domain Pekerjaan apa yang ada didalam application domain? Bagiaman pembagian pekerjanya? Bagaimana pekerjaan yang berbeda dapat dihilangkan ? Jangan terlalu menekankan cara kerja sekarang Hasil utama adalah daftar yang lengkap dari pekerjaan di application domain

Contoh Penjelasan tentang Actor Account Owner Goal: A person who owns an account. The account owner’s basic need is to make payments with their plastic card. Characteristic: The system’s users include many and very different account owners. Examples: Account owner A is insecure in the use of a plastic card as a form of payment. A only withdraws money from the ATM in emergency situations. Account owner B is technologically curious and uses the system often, optimally, and to the limit of its abilities.

Contoh Statechart for ‘Cash Withdrawal’ Use Case Prompt for code Insert card Card inserted Awaiting code Enter code Rejected Code entered Code accepted Cancel Payment Awaiting amount Amount approved Approve amount Choose amount Amount chosen Amount not approved (Mathiassen et al, 2000)

Example Text Description for ‘Cash Withdrawal’ Use Case: cash withdrawal is started by the account owner, when they wish to use their credit card to withdraw cash from an ATM. The account owner inserts their card into the ATM, and are then requested via the screen to type their PIN code. The screen will either show a polite denial, the card will be ejected from the ATM and the process will be canceled; or the screen will show a menu requesting the account owner to choose an amount of money by typing on the ATM’s keyboard. A new screen picture requests the account owner to approve the transaction. If the transaction is not approved the account owner is again requested to type an amount. Otherwise the use case ends by the ejection of the card, and the desired amount of money being paid. Objects: (to be added later) Functions: (to be added later)

Use Case dan Struktur Actor Perlu menghubungkan use case dan actor satu sama lain Dapat dilakukan dengan ‘Actor table’, tetpai hanya untuk associations Dapat juga dilakukan dengan ‘Use Case Diagrams’ Mempunyai actors dan use cases Gunakan structure untuk menghubungkan antara actor seperti pada ‘Class Diagram’

Contoh Actor Table

Groups of Use Cases Bank employee involved in Customer involved in all deposit use cases Deposit Bank employee involved in 2 of 3 deposit use cases Get customer information Deposit Loan Bank Employee Cash withdrawal Establishment Bank employee involved in all loan use cases Customer Maintain Customer involved in only payment loan use case Payments

Explore Use Case Patterns The procedural pattern General pattern for insuring that steps in a process or a sequence of rules are followed The material pattern General pattern when there are few rules to follow, i.e. actions can be taken in any order May possibly have some small action sequences specified as side patterns

Pola Procedural Can’t do action 2 unless action 1 is already done State 1 action 2 State n action n+1

The Material Pattern Actions 1 & 2 can be done in any order start action Material pattern is for ‘artisan like’ materials that can be manipulated in any desired order. E.g. diagrams, text, drawings being constructed. action 1 action 2 General State Process n Process n+1 Processes must be completed before returning to general state final action

Evaluate Systematically Carefully study descriptions for mistakes and inconsistencies. Test use cases to see if true in practice, e.g. using prototypes to experiment. Evaluate the social changes in the application domain.

Evaluation Criteria Use cases should be simple, constitute a coherent whole. The description of actors and use cases should provide understanding and overview. Use cases should be described in enough detail to enable identification of functions and interface elements (our next topic in application domain analysis!).

Experimenting with Prototypes Notation of use cases doesn’t allow successful verification by the users Construct experiments so that Use future users for testing Make environment as realistic as possible Be sure to follow five phases covered earlier: planning, development, preparation, test, and summarising

Principles of Usage Analysis Determine the application domain with use cases. Need cooperation between users and developers. Both an analytical and a creative activity. Evaluate use cases in collaboration with users. Best way is with prototypes. Can be paper and pencil exercises. Assess social changes in the application domain. Rethink the business processes. Avoid work-related problems and unnecessary human adjustments.

Tutorial: Usage Analysis Individually, brainstorm a list of use cases and actors for the Paul’s Pools example. As a class, compare and discuss your lists and agree on a refined list. Identify which use cases are performed by which actors. With the rest of the class, choose one use case and specify it.

Contoh Kasus Menentukan aktor Menentukan use case Kasus Persewaan Video Kasus Toko Bahan Bangunan

Video Rental Store Suatu sistem untuk mengelola pelanggan dan penyewaan video didalam toko persewaan video. Tokonya menawarkan video dalam kategori yang ber-beda-beda. Untuk menjadi member gratis dan terbuka untuk semua orang tetapi diharuskan mendaftar untuk menyewa video. Tokonya melacak aktifitas dari setiap pelanggan dan akan mengirimkan reminder bila video tidak dikembalikan dalam waktu 48 jam. Reminder kedua akan dikirim setelah satu minggu, dan jika tidak mengembalikan video, pelanggan akan diexclude hingga videonya di kembalikan. Untuk setiap video title, ada beberapa tape untuk disewakan, dan member dapat memesan video tertentu untuk di sewa pada tanggal tertentu. Gambarkan Use Case Diagram

USE CASE DIAGRAM Karyawan Pendaftaran Member Sewa Kembali Pesan Kirim Reminder

Terima Kasih