Upload files to "/"

exercise4 zagar.md

@@ -0,0 +1,109 @@
+# Problem Set 1 - Exercise 4: Defining Familiar Concepts
+
+Nama: Zagar Nashrullah
+NRP : 5803025048
+Konsep yang dipilih: 1 (URL Shortener), 4 (Electronic Boarding Pass), 5 (Address Verification)
+
+## 1. URL Shortener
+
+**concept** UrlShortener [User]
+**purpose** membuat URL panjang jadi lebih pendek dan gampang dibagikan
+**principle** user kirim URL asli, bisa pakai suffix sendiri atau biar sistem yang buatin otomatis. Setelah itu sistem simpan pemetaan suffix -> URL asli, jadi kalau ada yang buka short URL-nya nanti diarahkan ke URL asli tadi.
+
+**state**
+a set of ShortUrls with
+  a suffix String
+  a target String
+  an owner User
+  a createdAt DateTime
+
+**actions**
+
+shorten (owner: User, target: String, suffix: String): (shortUrl: ShortUrl)
+**requires** target harus URL yang valid, dan suffix belum dipakai
+**effects** buat ShortUrl baru pakai suffix yang dikasih user
+
+shortenAuto (owner: User, target: String): (shortUrl: ShortUrl)
+**requires** target harus URL yang valid
+**effects** sistem generate suffix random yang belum ada, lalu buat ShortUrl baru
+
+resolve (suffix: String): (target: String)
+**requires** suffix-nya harus ada di data
+**effects** balikin target URL-nya (tidak mengubah apa-apa di state)
+
+delete (shortUrl: ShortUrl)
+**requires** shortUrl-nya masih ada
+**effects** hapus dari data
+
+**notes**
+Saya pisah action shorten dan shortenAuto karena requires-nya beda, kalau digabung jadi satu action nanti precondition-nya jadi rancu (kadang boleh suffix kosong, kadang tidak). Suffix saya buat unik secara global (bukan per user) soalnya kalau tidak begitu, short URL-nya bisa tabrakan pas di-resolve.
+
+---
+
+## 2. Electronic Boarding Pass
+
+**concept** ElectronicBoardingPass [Passenger, Flight]
+**purpose** ngasih bukti digital ke penumpang buat naik pesawat, yang bisa update sendiri kalau ada perubahan gate/jadwal
+**principle** setelah penumpang check-in, boarding pass dibuat dengan gate & jam terbang saat itu. Kalau nanti maskapai ubah gate atau jadwal, boarding pass ini ikut ke-update. Pas mau naik pesawat, boarding pass di-scan dan statusnya jadi used supaya tidak bisa dipakai dua kali.
+
+**state**
+a set of BoardingPasses with
+  a passenger Passenger
+  a flight Flight
+  a seat String
+  a gate String
+  a departureTime DateTime
+  a status Flag (issued/used/cancelled)
+
+**actions**
+
+issue (passenger: Passenger, flight: Flight, seat: String, gate: String, departureTime: DateTime): (pass: BoardingPass)
+**requires** belum ada boarding pass issued lain untuk penumpang & flight yang sama
+**effects** buat boarding pass baru, status issued
+
+updateGate (pass: BoardingPass, gate: String)
+**requires** pass masih berstatus issued
+**effects** ganti gate-nya
+
+updateDepartureTime (pass: BoardingPass, departureTime: DateTime)
+**requires** pass masih berstatus issued
+**effects** ganti jam keberangkatannya
+
+scanForBoarding (pass: BoardingPass)
+**requires** pass masih berstatus issued
+**effects** ubah status jadi used
+
+cancel (pass: BoardingPass)
+**requires** pass masih berstatus issued
+**effects** ubah status jadi cancelled
+
+**notes**
+Gate dan jam terbang saya simpan langsung di boarding pass, bukan ambil dari Flight terus-terusan, karena kalau konsep ini "nempel" ke konsep Flight nanti tidak independent lagi (ini kayak yang dibahas soal generic type di Exercise 1 no. 7, jadi saya coba terapkan prinsip yang sama). Untuk sinkronisasi update gate dari sistem flight ke boarding pass, saya anggap itu bagian dari sync, bukan tanggung jawab konsep ini.
+
+---
+
+## 3. Address Verification
+
+**concept** AddressVerification [User]
+**purpose** verifikasi user pakai alamat rumah/surat mereka
+**principle** user submit alamat, dibandingkan dengan alamat referensi yang udah tersimpan di sistem. Kalau cocok verifikasi berhasil, kalau tidak cocok tetap dicatat sebagai percobaan gagal (beda dari PasswordAuthentication yang percobaan gagalnya tidak disimpan).
+
+**state**
+a set of VerificationAttempts with
+  a user User
+  a submittedAddress String
+  a referenceAddress String
+  a result Flag (success/failure)
+  a timestamp DateTime
+
+**actions**
+
+setReferenceAddress (user: User, address: String)
+**effects** simpan/timpa alamat referensi user
+
+verify (user: User, submittedAddress: String): (result: Flag)
+**requires** user sudah punya alamat referensi
+**effects** cocokkan submittedAddress dengan referensi, simpan hasilnya (berhasil/gagal) sebagai VerificationAttempt baru, terus return hasilnya
+
+**notes**
+Bedanya dari PasswordAuthentication ada di action verify ini, karena di sini setiap percobaan tetap disimpan ke state walaupun gagal - beda sama authenticate yang cuma jadi "guard" doang. Ini sesuai sama yang diminta di soal, katanya harus ada record buat transaksi yang gagal. Untuk cara membandingkan alamatnya (exact match atau bukan) saya tidak masukin ke spek karena itu menurut saya lebih ke detail implementasi.