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