• Tidak ada hasil yang ditemukan

Modul User Manajemen E-Waste “Ada Sampah ?”

N/A
N/A
Muhammad Alfarozi

Academic year: 2023

Membagikan "Modul User Manajemen E-Waste “Ada Sampah ?”"

Copied!
21
0
0

Teks penuh

(1)

P

RAKTIKUM

S

ISTEM

B

ERORIENTASI

O

BJEK

Modul User Manajemen E-Waste

“Ada Sampah ?”

Dipersiapkan Oleh :

Kelas A/ Kelompok: 3 / G-Tech

Muhammad Alfarozi - 213040003

Syifa Rizki Mutia - 213040005 Risma Rahmana Fitri - 213050010 Barra Alkhasyani Permana - 213040013 Faqih Firdaus Kemal Pangestu - 213040033

Widya Dwi Indrianti - 213040034 Asisten Pembimbing :

PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS TEKNIK

UNIVERSITAS PASUNDAN BANDUNG

2023

(2)

D

AFTAR

I

SI

Daftar Isi... i

Daftar Tabel...i

Daftar Gambar...ii

1 Pendahuluan... 1

1.1 Tujuan Penulisan Dokumen... 1

1.2 Lingkup Masalah... 1

1.3 Pembagian Kerja Tim... 1

1.4 Definisi dan Istilah... 2

1.5 Aturan Penamaan dan Penomoran...2

1.6 Referensi... 2

1.7 Ikhtisar Dokumen... 2

2 Requirement Gathering... 4

2.1 Proses Bisnis... 4

2.1.1 Tahapan Registrasi User Manajemen... 4

2.1.2 Diagram Use Case Bisnis... 4

2.1.3 Aktor Bisnis... 4

2.1.4 Use-Case Bisnis... 5

2.1.5 Diagram Aktivitas...5

2.2 Identifikasi User Requirement...6

2.3 Identifikasi Software Requirement... 6

2.4 Identifikasi Software Requirement - Use Case - Actor...6

2.5 Diagram Use-case...7

2.5.1 Deskripsi Aktor...7

2.5.2 Deskripsi Use-Case...7

3 Pemodelan Analisis...8

3.1 Skenario Use Case...8

3.1.1 UC-01 - Tamu... 8

3.1.2 UC-01 – Petugas Reservasi... 9

3.1.3 UC-02 - Tamu... 10

3.1.4 UC-02 – Petugas Reservasi...11

3.1.5 UC-03 - Tamu... 12

3.1.6 UC-03 – Petugas Reservasi... 13

3.1.7 UC-04 – Petugas Reservasi... 14

3.2 Diagram Sekuens... 15

3.2.1 UC-01 - Melihat Kamar...15

3.2.2 UC-02 - Membuat Reservasi... 15

3.2.3 UC-03 - Melihat Reservasi... 15

3.2.4 UC-04 - Mengubah Reservasi... 15

3.3 Diagram Kelas Analisis... 15

3.3.1 UC-01 - Melihat Kamar...15

3.3.2 UC-02 - Membuat Reservasi... 17

3.3.3 UC-03 - Melihat Reservasi... 17

3.3.4 UC-04 - Mengubah Reservasi... 18

3.4 Deskripsi Kelas Analisis... 18

3.5 Relasi Antar Kelas Analis... 18

(3)

3.6 Diagram Kelas Analisis Lengkap... 19

D

AFTAR

T

ABEL

Tabel 1 Daftar User Requirement 6

Tabel 2 Daftar User Requirement – Software Requirement 6

Tabel 3 Functional Requirement – Use Case – Actor 6

Tabel 4 Deskripsi Kelas Analisis 17

Tabel 5 Relationship antar kelas analis 17

D

AFTAR

G

AMBAR

Gambar 1 Model Proses pembangunan perangkat lunak 1

Gambar 2 Diagram Use-case bisnis <> 4

Gambar 3 Diagram Aktivitas <> 5

Gambar 4 Diagram Use-case 7

Gambar 5 Diagram kelas analisis melihat kamar 15

Gambar 6 Diagram kelas analisis membuat reservasi 16

Gambar 7 Diagram kelas analisis melihat reservasi 16

Gambar 8 Diagram kelas analisis mengubah reservasi 17

Gambar 9 Diagram kelas analisis 18

1 P

ENDAHULUAN

1.1 Tujuan Penulisan Dokumen

Dokumen ini berupa Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau SRS (Software Requirements Specification) untuk <Nama Software> dilengkapi dengan dokumen Pemodelan Analisis dan Desain untuk <Nama Software> . Tujuan penulisan dokumen ini adalah memberikan penjelasan mengenai tahapan dalam pembangunan software dimulai dengan model proses yang digunakan, requirement gathering serta analysis dan design modeling.

Pengguna dari dokumen ini adalah pengembang perangkat lunak <> dan pengguna dari perangkat lunak personil-personil yang terlibat dalam system. Dokumen ini akan digunakan sebagai pemandu atau acuan dalam pengembangan perangkat lunak serta sebagai bahan evaluasi baik pada saat proses maupun akhir dalam pengembanganya. Diharapkan dengan disusunnya dokumen ini, pengembangan perangkat lunak akan lebih terarah dan terfokus, sehingga hasil dari pengembangan perangkat lunak akan menghasil perangkat lunak yang lebih baik dan terhindar dari ambiguitas maupun kekurangan lainnya.

1.2 Lingkup Masalah

Berikut lingkup dari pengerjaan dokumen ini:

1. Perangkat lunak yang dibangun adalah <>, yaitu merupakan perangkat lunak berupa sebuah aplikasi manajemen pembuangan sampah elektronik..

2. Perangkat lunak ini dibangun dengan menggunakan pendekatan model proses Linier Sequential sebagai berikut, dengan fokus kepada: Requirement Gathering dan Modeling (Analysis dan Design).

(4)

Gambar 1 Model Proses pembangunan perangkat lunak

3. Pemodelan akan menggunakan notasi Unified Modeling Language (UML).

4. Perangkat lunak <> ini ditujukan untuk user manajemen agar supaya <user tersebut dapat melakukan:

User manajemen ingin dapat melakukan registrasi ke system dan mendapatkan approval dari admin (atau mendapatkan OTP dari system)

Usermanajemeningin dapat login ke dalam system dan mengubah password

Usermanajemeningin dapat fasilitas lupa password

Usermanajemeningin dapat melengkapi profil diri dengan foto, data alamat, data tanggal lahir

Usermanajemeningin dapat melihat jenis dan kategori sampah elektronik yang dapat dijemput

1.3 Pembagian Kerja Tim

Tim terdiri dari 3 - 5 (tiga sampai 5 orang tenaga ahli), Ahli analis sistem, ahli desain sistem yang masing-masing dibantu oleh asisten tenaga Ahli dan tim teknis.

Tabel I.1 Pembagian Kerja Tim

No. Pembagian Kerja Tenaga Ahli

1. Team leader Muhammad Alfarozi (213040003)

2. Sistem Analis - Barra Alkhasyani Permana (213040013) - Faqih Firdaus Kemal Pangestu ( 213040033) - Widya Dwi Indrianti (213040034)

3. Sistem Desainer - Syifa Rizki Mutia (213040005) - Risma Rahmana Fitri (213040010)

1.4 Definisi dan Istilah

Berikut adalah daftar definisi dan istilah penting yang digunakan dalam dokumen SKPL ini:

● SRS : Software Requirements Specification, atau

● SKPL : Spesifikasi Kebutuhan Perangkat Lunak Dokumen hasil analisis yang berisi spesifikasi kebutuhan perangkat lunak.

● IEEE : Institute of Electrical and Electronics Engineering: Standar internasional untuk pengembangan dan perancangan produk.

● ANSI : American National Standard Institute: Lembaga Standardisasi Amerika.

● SKKNI : Standar Kompetensi Kerja Nasional Indonesia (SKKNI)

(5)

1.5 Aturan Penamaan dan Penomoran

Penulisan dokumen ini menggunakan berbagai macam aturan penamaan dan penomoran yang berbeda-beda untuk beberapa bagian tertentu. Aturan penamaan dan penomoran yang digunakan berdasarkan hal/bagian tersebut adalah seperti yang tercantum pada Tabel 1 berikut ini.

Table 1 Aturan Penamaan dan Penomoran

Hal/Bagian Aturan Penomoran/Penamaan

Kebutuhan User UR- XX : Menunjukkan kebutuhan user ke-XX Kebutuhan Fungsional SR-XX : Menunjukkan kebutuhan fungsional ke-XX Kebutuhan Non Fungsional SNFR-XX : Menunjukkan kebutuhan non fungsional ke-XX Bisnis Use-case BUC-xx : menunjukkan bisnis use-case ke-xx

Use-case UC-xx : menunjukkan use-case ke-xx Aktor Bisnis BAC-xx : menunjukkan aktor bisnis ke-xx

Aktor AC-xx : menunjukkan aktor ke-xx

1.6 Referensi

Dokumen-dokumen yang digunakan sebagai referensi dalam pembuatan SKPL ini adalah sebagai berikut :

1) ISO/IEC/IEEE 29148:2011 Systems and software engineering — Life cycle processes — Requirements engineerings.

2) SKKNI Software Development - Software Requirement Analysis and Design No 44 tahun 2017

3) Panduan Penggunaan dan Pengisian Spesifikasi Perangkat Lunak (SKPL), Program Studi Teknik Informatika, Universitas Pasundan.

1.7 Ikhtisar Dokumen

Dokumen ini secara garis besar terdiri dari tiga bab dengan perincian sebagai berikut:

● Bab 1 Pendahuluan, merupakan pengantar dokumen SKPL ini yang berisi tujuan penulisan dokumen, lingkup masalah, juga memuat definisi dan istilah yang digunakan serta deskripsi umum dokumen yang merupakan ikhtisar dokumen SKPL.

● Bab 2 Requirement Gathering, menjelaskan tahapan-tahapan dalam mendapatkan spesifikasi kebutuhan perangkat lunak.

● Bab 3 Pemodelan Analisis dan Desain, mendeskripsikan model analisis dan desain yang didapatkan berdasarkan requirement yang sudah ditetapkan. Pemodelan dari diagram kelas analisis dan diagram kelas desain.

● Bab 4 Detail desain yang terdiri dari Coding Standar dan Naming Convention, perancangan data dengan Object Relational Mapping (ORM), deskripsi algoritma dan query, rancangan antarmuka dan arsitektur aplikasi

● Bab 5 Penutup berisi kesimpulan dan tindak lanjut yang akan diarahkan kepada para pemrogram

(6)

2 R

EQUIREMENT

G

ATHERING

Pada bagian ini akan dijelaskan tahapan dalam melakukan requirement gathering untuk mendapatkan spesifikasi kebutuhan perangkat lunak. Diawali dengan penjelasan proses bisnis dan pemodelan proses bisnis, daftar user dan software requirement dan diakhiri dengan skenario dan paper prototipe.

2.1 Proses Bisnis

Pada bagian ini akan dijelaskan sistem <> yang akan dibangun memiliki tahapan aktivitas, aktor bisnis yang terlibat dalam proses bisnis tersebut dan diagram proses bisnis.

2.1.1 Tahapan Registrasi User Manajemen

Tahapan Registrasi

1. User manajemen mengisi form registrasi ke sistem 2. User manajemen mengirim form registrasi ke sistem 3. Admin melakukan konfirmasi akun user manajemen

4. Jika admin tidak menyetujui user harus mengisi Kembali form registrasi dan jika admin menyetujui user akan menerima notifikasi status konfirmasi akun

5. User manajemen melakukan login ke system 6. User manajemen memiliki opsi lupa password

7. Jika user lupa password user harus mengubah password dan jika tidak user dapat melengkapi profil

8. Jika tidak melengkapi profil user harus melengkapi profil Kembali 9. Jika profil sudah lengkap user dapat melihat data jenis kategori sampah

Dari tahapan tersebut, dapat ditetapkan aktor bisnis yang terlibat dalam proses bisnis yaitu: user manajemen dan admin. Sedangkan proses bisnis adalah registrasi manajemen..

2.1.2 Diagram Use Case Bisnis

Berikut adalah diagram proses bisnis dalam bentuk diagram use case bisnis:

Gambar 2 Diagram Use-case bisnis Registrasi Manajemen

2.1.3 Aktor Bisnis

Berikut adalah daftar aktor dan deskripsinya:

Kode Aktor bisnis Deskripsi

BAC-01 admin orang yang melakukan konfirmasi akun user manajemen waktu registrasi

2.1.4 Use-Case Bisnis

Berikut adalah daftar aktor dan deskripsinya:

(7)

Kode Aktor bisnis Deskripsi

BUC-01 User Manajemen Orang yang mengelola registrasi

2.1.5 Diagram Aktivitas

Berikut adalah aktivitas dalam proses bisnis yang dituangkan dalam bentuk diagram aktivitas sebagai berikut:

Gambar 3 Diagram Aktivitas Registrasi Manajemen

(8)

2.2 Identifikasi User Requirement

Berdasarkan diagram aktivitas di atas, dapat dilihat terdapat peluang otomatisasi pada aktivitas pengisian form reservasi kamar. Dengan demikian, didapatkan daftar use-requirement sebagai berikut:

Tabel 1 Daftar User Requirement Kode User Requirement

UR-01 User manajemen ingin dapat melakukan registrasi ke system dan mendapatkan approval dari admin (atau mendapatkan OTP dari system)

UR-02 Usermanajemeningin dapat login ke dalam system dan mengubah password UR-03 Usermanajemeningin dapat fasilitas lupa password

UR-04 User manajemen ingin dapat melengkapi profil diri dengan foto, data alamat, data tanggal lahir

UR--05 Usermanajemeningin dapat melihat jenis dan kategori sampah elektronik yang dapat dijemput

2.3 Identifikasi Software Requirement

Berdasarkan daftar user requirement tersebut, disusun daftar software requirement untuk memenuhi keinginan / requirement dari user tersebut:

Tabel 2 Daftar User Requirement – Software Requirement

Kode User Requirement Kode Software Requirement

UR-01 User manajemen ingin dapat melakukan registrasi ke system dan mendapatkan approval dari admin (atau mendapatkan OTP dari system)

SR-01 Perangkat lunak harus menyediakan formulir registrasi untuk user manajemen dan memberi OTP (One Time Password) dan approval dari admin

UR-02 User manajemen ingin dapat login ke dalam system dan mengubah password

SR -02 Perangkat lunak harus mampu menyediakan fungsi login dan mengubah password untuk user manajemen

UR-03 User manajemen ingin dapat fasilitas lupa password

SR -03 Perangkat lunak harus menyediakan mekanisme untuk user manajemen yang lupa password

UR-04 User manajemen ingin dapat melengkapi profil diri dengan foto, data alamat, data tanggal lahir

SR -04 Perangkat lunak harus menyediakan antarmuka yang intuitif untuk memasukkan dan memperbarui informasi profil

UR_05 User manajemen ingin dapat melihat jenis dan kategori sampah elektronik yang dapat dijemput

SR -05 Perangkat lunak harus mampu memberikan informasi tentang jenis dan kategori sampah elektronik yang dapat dijemput

SR-01 Perangkat lunak harus menyediakan formulir registrasi untuk user manajemen dan memberi OTP (One Time Password) dan approval dari admin

Penjelasan: Ada SR yang sama, tidak perlu diberi kode baris. Kode Requirement dapat SR-no_req, atau SR-no_kelompok-no_req

(9)

2.4 Identifikasi Software Requirement - Use Case - Actor

Berdasarkan daftar software requirement di atas, maka akan ditetapkan use-case yang terkait (yaitu functional requirement). Untuk setiap use-case, dipastikan ada actor yang berinteraksi dengan use-case tersebut. Berikut tabel rangkuman pemetaan antara Functional Requirement – Use Case – Actor:

Tabel 3 Functional Requirement – Use Case – Actor

Kode Software Requirement Kode Nama Use case Actor

SR-01 Perangkat lunak harus menyediakan formulir registrasi untuk user manajemen dan memberi OTP (One Time Password) dan approval dari admin

UC-01 Melakukan Registrasi

User Manajemen SR-02 Perangkat lunak harus mampu menyediakan fungsi login

dan mengubah password untuk user manajemen

UC-02 Melakukan Login User Manajemen SR-03 Perangkat lunak harus menyediakan mekanisme untuk

user manajemen yang lupa password UC-03 Mengubah Password User Manajemen SR-04 Perangkat lunak harus menyediakan antarmuka yang

intuitif untuk memasukkan dan memperbarui informasi profil

UC-04 Mengedit Profil User Manajemen SR-05 Perangkat lunak harus mampu memberikan informasi

tentang jenis dan kategori sampah elektronik yang dapat dijemput

UC-05 Melihat Informasi Sampah

User Manajemen SR-01 Perangkat lunak harus menyediakan formulir registrasi

untuk user manajemen dan memberi OTP (One Time Password) dan approval dari admin

UC-01 Melakukan Registrasi

Admin

2.5 Diagram Use-case

Berdasarkan tabel pemetaan antara Functional Requirement – Use Case – Actor:di atas, maka dapat ditentukan diagram use-case sebagai berikut:

(10)

Gambar 4 Diagram Use-case

2.5.1 Deskripsi Aktor

Berikut adalah daftar aktor dan deskripsinya:

Kode Aktor Deskripsi

AC-01 User Manajemen Orang yang login ke aplikasi

AC-02 Admin Orang yang memberi dan approve kode OTP

2.5.2 Deskripsi Use-Case

Berikut adalah daftar aktor dan deskripsinya:

Kode Use case Deskripsi

UC-01 Melakukan Registrasi user manajemen mengisi informasi akun seperti nama lengkap email,password dan admin melakukan konfirmasi akun

UC-02 Melakukan Login user manajemen mengisi email dan password untuk login ke sistem UC-03 Mengubah Password user manajemen dapat mengubah password jika user lupa password UC-04 Mengedit Profil user manajemen dapat melengkapi data profil seperti nama lengkap,,no

telepon,alamat,tanggal lahir,dan foto profil UC-05 Melihat Informasi

Sampah

user manajemen dapat melihat informasi jenis sampah elektronik yang akan dijemput oleh kurir

3 P

EMODELAN

A

NALISIS

Pemodelan analisis ditujukan untuk mendapatkan kelas-kelas analisis yang diperlukan untuk tahapan perancangan perangkat lunak. Pada pemodelan analisis, didahului dengan skenario use-case dan paper prototipe untuk setiap use-case yang telah didapatkan dilanjutkan identifikasi kelas analisis.

Skenario Use Case terdiri dari 2 area:

1. Identifikasi UC

2. Skenario Utama & Skenario Alternatif

Identifikasi UC terdiri dari kode UC, nama, tujuan, deskripsi, aktor terkait

Skenario Utama terdiri dari kondisi awal, yaitu awal dari tampilan aplikasi; aksi aktor – reaksi sistem, yaitu penjelasan urutan langkah yang dilakukan oleh aktor dan direspon oleh sistem; kondisi akhir, yaitu akhir dari urutan langkah aksi-rekasi. Kondisi akhir haruslah menggambarkan tujuan UC yang ingin dicapai.

Petunjuk penting:

Jika satu UC terdapat 2 aktor yang berinteraksi, maka dibuat menjadi masing-masing skenario dengan prototipe yang mungkin berbeda.

3.1 Skenario Use Case

Berikut ini adalah skenario use-case untuk setiap use-case yang telah diidentifikasi:

3.1.1 UC-01 - Tamu

Identfikasi

Kode UC-01

Nama Melihat Kamar

(11)

Tujuan Melihat informasi kamar

Deskripsi Tamu memilih salah satu kamar, yang

ditampilkan di halaman utama.

Aktor Tamu

Skenario Utama Kondisi Awal : Menampilkan halaman Utama aplikasi

Aksi Aktor Reaksi Sistem

1. Klik salah satu “kamar” yang ditampilkan di halaman Utama

2. Menampilkan halaman Detail Kamar Kondisi Akhir : Menampilkan halaman Detail Kamar

(12)

3.1.2 UC-01 – Petugas Reservasi

Identfikasi

Kode UC-01

Nama Melihat Kamar

Tujuan Melihat informasi kamar

Deskripsi Petugas Reservasi memilih salah satu kamar,

yang ditampilkan di halaman utama.

Aktor Petugas Reservasi

Skenario Utama Kondisi Awal : Menampilkan halaman Utama aplikasi

Aksi Aktor Reaksi Sistem

1. Klik salah satu “kamar” yang ditampilkan di halaman Utama

2. Menampilkan halaman Detail Kamar Kondisi Akhir : Menampilkan halaman Detail Kamar

(13)

3.1.3 UC-02 - Tamu

Identfikasi

Kode UC-02

Nama Membuat Reservasi

Tujuan Mereservasi Kamar

Deskripsi Tamu memilih salah satu kamar, yang

ditampilkan di halaman utama. Setelah tamu memilih salah satu kamar, yang ditampilkan di halaman utama. Tamu dapat melakukan reservasi kamar.

Aktor Tamu

Skenario Utama Kondisi Awal : Menampilkan halaman utama apl kasi

Aksi Aktor Reaksi Sistem

1. Klik salah satu “kamar” yang ditampilkan di halaman Utama

2. Menampilkan halaman Detail Kamar 3. Klik tombol “Reservasi” 4. Menampilkan halaman Reservasi Baru 5. Isi form pada halaman Reservasi yang

ditampilkan, kemudian klik tombol

“Menuju Pembayaran”

6. Menampilkan halaman Pembayaran Resevasi

7. Klik pilih salah satu metode pembayaran, kemudian klik tombol

“Reservasi Sekarang”

8. Menampilkan halaman Reservasi Berhasil

Kondisi Akhir : Menampilkan halaman Reservasi Berhasil

(14)

3.1.4 UC-02 – Petugas Reservasi

Identfikasi

Kode UC-02

Nama Membuat Reservasi

Tujuan Mereservasi Kamar

Deskripsi Petugas Reservasi membuatkan reservasi untuk

tamu yang datang langsung ke bagian reservasi.

Petugas Reservasi memilih salah satu kamar, yang ditampilkan di halaman utama. Setelah Petugas Reservasi memilih salah satu kamar, yang ditampilkan di halaman utama. Petugas Reservasi dapat melakukan reservasi kamar untuk Tamu.

Aktor Petugas Reservasi

Skenario Utama Kondisi Awal : Menampilkan halaman utama aplikasi

Aksi Aktor Reaksi Sistem

1. Klik salah satu “kamar” yang ditampilkan di halaman Utama

2. Menampilkan halaman Detail Kamar 3. Klik tombol “Reservasi” 4. Menampilkan halaman Reservasi Baru 5. Isi form pada halaman Reservasi yang

ditampilkan, kemudian klik tombol

“Menuju Pembayaran”

6. Menampilkan halaman Pembayaran Resevasi

(15)

7. Klik pilih salah satu metode pembayaran, kemudian klik tombol

“Reservasi Sekarang”

8. Menampilkan halaman Reservasi Berhasil

9. Petugas Reservasi memberikan bukti reservasi kepada Tamu

Kondisi Akhir : Petguas Reservasi memberikan bukti reservasi kepada Tamu

3.1.5 UC-03 - Tamu

Identfikasi

Kode UC-03

Nama Melihat Reservasi

Tujuan Melihat informasi riwayat kamar yang telah

direservasi oleh tamu

Deskripsi Tamu memilih menu riwayat reservasi,

kemudian aplikasi menampilkan riwayat resevasi tamu

Aktor Tamu

Skenario Utama Kondisi Awal : Menampilkan halaman Utama aplikasi

Aksi Aktor Reaksi Sistem

(16)

1. Klik menu “Riwayat Reservasi” 2. Menampilkan halaman Riwayat Reservasi

Kondisi Akhir : Menampilkan halaman Riwayat Reservasi

3.1.6 UC-03 – Petugas Reservasi

Identfikasi

Kode UC-03

Nama Melihat Reservasi

Tujuan Melihat informasi riwayat kamar yang telah

direservasi oleh seluruh tamu

Deskripsi Petugas Reservasi memilih menu riwayat

reservasi, kemudi an aplikasi menampilkan riwayat resevasi seluruh tamu

Aktor Tamu

Skenario Utama Kondisi Awal : Menampilkan halaman Utama aplikasi

Aksi Aktor Reaksi Sistem

1. Klik menu “Riwayat Reservasi” 2. Menampilkan halaman Riwayat Reservasi

Kondisi Akhir : Menampilkan halaman Riwayat Reservasi

(17)

3.1.7 UC-04 – Petugas Reservasi

Identfikasi

Kode UC-04

Nama Mengubah Reservasi

Tujuan Mengubah data reservasi

Deskripsi Petugas Reservasi memilih salah satu reservasi

Aktor Petugas Reservasi

Skenario Utama Kondisi Awal : Menampilkan halaman Utama apl ikasi

Aksi Aktor Reaksi Sistem

1. Klik Menu “Reservasi” yang ditampilkan di halaman Utama

2. Menampilkan halaman Reservasi 3. Klik salah satu Reservasi yang ingin

dirubah

4. Menampilkan form perubahan

Reservasi berdasarkan Reservasi yang dipilih

5. Ubah data yang akan dirubah pada form perubahan Reservasi dan klik

“Simpan”

6. Menampilkan pop up “Data Berhasil Diubah”

Kondisi Akhir : Menampilkan pop up “Data Berhasil Diubah”

(18)

3.2 Diagram Sekuens

Berikut ini adalah diagram sekuens untuk menjelaskan alur internal dari sistem, berdasarkan skenario dan paper prototipe yang telah diidentifikasi:

3.2.1 UC-01 - Melihat Kamar 3.2.2 UC-02 - Membuat Reservasi 3.2.3 UC-03 - Melihat Reservasi 3.2.4 UC-04 - Mengubah Reservasi

3.3 Diagram Kelas Analisis

Berikut ini adalah kelas analisis untuk setiap use-case yang telah diidentifikasi, berdasarkan skenario dan paper prototipe yang telah diidentifikasi:

3.3.1 UC-01 - Melihat Kamar

Kelas Analisis

Gambar 5 Diagram kelas analisis melihat kamar Penjelasan

(19)

3.3.2 UC-02 - Membuat Reservasi

Kelas Analisis

Gambar 6 Diagram kelas analisis membuat reservasi Penjelasan

3.3.3 UC-03 - Melihat Reservasi

Kelas Analisis

Gambar 7 Diagram kelas analisis melihat reservasi Penjelasan

(20)

3.3.4 UC-04 - Mengubah Reservasi

Kelas Analisis

Gambar 8 Diagram kelas analisis mengubah reservasi Penjelasan

3.4 Deskripsi Kelas Analisis

Pada bagian ini diisi dengan daftar kelas dan deskripsi singkat mengenai kelas – kelas tersebut Lengkapi kelas tersebut dengan atribut dan tanggung jawab (catatan: tanggung jawab = operasi = metode).

Tabel 4 Deskripsi Kelas Analisis

NO Nama Kelas Jenis Kelas Tanggung Jawab Atribut

1 <Nama

Kelas> <Sebutkan Jenis Kelas apakah

Boundary,controller atau entity> <Sebutkan Peran dari masing-masing kelas >

Dapat diisi dengan kandidat metode

<Atribut yang dipakai>

3.5 Relasi Antar Kelas Analis

Jika relasi antar kelas, maka tuliskan relasi tersebut pada tabel berikut ini.

Tabel 5 Relationship antar kelas analis

(21)

3.6 Diagram Kelas Analisis Lengkap

Pada bagian ini, dibuatkan diagram kelas analisis lengkap, yaitu gabungan seluruh kelas analisis yang telah diidentifikasi pada bagian 3.2 dan dilengkapi dengan seluruh tanggung jawab (metode) dan atribut serta relasi antar kelas.

Gambar 9 Diagram kelas analisis

NO Dari kelas Ke kelas Nama relasi Keterangan

1 <Nama kelas>

<Kelas Yang berhubungan> <Contoh Dependency>

Referensi

Dokumen terkait