UML Mini Series Part 4: Sequence Diagram

1. What is a Sequence Diagram?

A Sequence Diagram is a behaviour diagram that models the interactions between objects over time. It shows who calls whom, in what order, and with what data: all arranged on a timeline that reads from top to bottom.

While the Activity Diagram (Part 3) shows the business process flow, the Sequence Diagram shows the technical object-level interactions that implement that flow. Together, they answer two different questions:

Key Elements of a Sequence Diagram

1. Apa Itu Sequence Diagram?

Sequence Diagram adalah diagram perilaku yang memodelkan interaksi antar objek sepanjang waktu. Diagram ini menunjukkan siapa memanggil siapa, dalam urutan apa, dan dengan data apa: semuanya disusun pada timeline yang dibaca dari atas ke bawah.

Sementara Activity Diagram (Bagian 3) menunjukkan alur proses bisnis, Sequence Diagram menunjukkan interaksi teknis pada level objek yang mengimplementasikan alur tersebut. Bersama-sama, keduanya menjawab dua pertanyaan berbeda:

Elemen Kunci Sequence Diagram

2. Why Use Sequence Diagrams?

What is it?

A sequence diagram captures the dynamic interactions between objects in a specific scenario. It focuses on time-ordered messages: method calls, HTTP requests, database queries, and their responses.

Why does it matter?

• Design precision. A sequence diagram forces you to name every method, parameter, and important response before coding. You cannot hand-wave “then the system processes the payment”: you must specify PaymentGateway::charge($amount, $studentId, $courseId) and the response data it returns.
• Discover hidden dependencies. Drawing lifelines reveals when an object depends on another object it should not know about (violating the Law of Demeter or layered architecture).
• Concurrency visualisation. Activation boxes show which operations happen in parallel and which block, making it easy to spot deadlock risks.
• Code generation. Many IDEs can generate skeleton code from sequence diagrams. Even without tooling, a sequence diagram is an exact specification for what methods to implement.

When do you use it?

Create a sequence diagram during the design phase, after the activity diagram and use case scenario are complete. It is the last behavioural diagram before implementation.

Where does it fit?

Sequence diagrams live in technical design documents and API specifications. They are especially useful for complex operations involving multiple services or components.

How do you create one?

1. Identify the objects (participants) involved in the scenario.
2. Place them as lifelines at the top of the diagram, arranged left to right.
3. Trace the main flow from the use case scenario, converting each step into a message between objects.
4. Add activation boxes to show when each object is busy.
5. Add alt fragments for conditional branches and loop fragments for repeated interactions.
6. Annotate return messages where the response data matters.

2. Mengapa Menggunakan Sequence Diagram?

Apa itu?

Sequence diagram menangkap interaksi dinamis antar objek dalam skenario tertentu. Diagram ini berfokus pada pesan terurut waktu: pemanggilan method, HTTP request, query database, dan responsnya.

Mengapa penting?

• Presisi desain. Sequence diagram memaksa Anda menamai setiap method, parameter, dan respons penting sebelum coding. Anda tidak bisa melewatkan begitu saja “lalu sistem memproses pembayaran”: Anda harus menspesifikasikan PaymentGateway::charge($amount, $studentId, $courseId) dan data respons yang dikembalikan.
• Temukan dependensi tersembunyi. Menggambar lifelines mengungkapkan ketika sebuah objek bergantung pada objek lain yang seharusnya tidak diketahuinya (melanggar Law of Demeter atau arsitektur berlapis).
• Visualisasi konkurensi. Activation box menunjukkan operasi mana yang terjadi secara paralel dan mana yang memblokir, memudahkan untuk menemukan risiko deadlock.
• Code generation. Banyak IDE dapat menghasilkan kode kerangka dari sequence diagram. Bahkan tanpa tooling, sequence diagram adalah spesifikasi tepat untuk method apa yang harus diimplementasikan.

Kapan digunakan?

Buat sequence diagram selama fase desain, setelah activity diagram dan use case scenario selesai. Ini adalah diagram perilaku terakhir sebelum implementasi.

Di mana tempatnya?

Sequence diagram berada di dokumen desain teknis dan spesifikasi API. Diagram ini sangat berguna untuk operasi kompleks yang melibatkan beberapa layanan atau komponen.

Bagaimana membuatnya?

1. Identifikasi objek (partisipan) yang terlibat dalam skenario.
2. Tempatkan mereka sebagai lifelines di bagian atas diagram, disusun dari kiri ke kanan.
3. Telusuri alur utama dari use case scenario, lalu konversikan setiap langkah menjadi pesan antar objek.
4. Tambahkan activation box untuk menunjukkan kapan setiap objek sibuk.
5. Tambahkan fragmen alt untuk cabang kondisional dan fragmen loop untuk interaksi berulang.
6. Beri anotasi return message ketika data respons penting.

3. Participants in the Enrolment Sequence

Recall the Enrol in Course use case from Part 2. For the sequence diagram, we focus on steps 6–13 (from enrolment summary to confirmation) because this is where the most interesting object interactions occur.

Here are the participants (lifelines) in our scenario:

Why These Participants?

In a Laravel application (Part 5), these map directly to:

• EnrolmentController → App\Http\Controllers\EnrolmentController
• CourseService → App\Services\CourseService
• EnrolmentService → App\Services\EnrolmentService
• PaymentGateway → App\Services\PaymentGateway (or a third-party SDK like Midtrans)
• Database → Eloquent models backed by MySQL/PostgreSQL

The separation of CourseService and EnrolmentService follows the Single Responsibility Principle: course logic (quota, schedule) and enrolment logic (conflicts, registration) change for different reasons.

3. Partisipan dalam Sequence Enrolment

Ingat use case Daftar Mata Kuliah dari Bagian 2. Untuk sequence diagram, kita fokus pada langkah 6–13 (dari ringkasan pendaftaran hingga konfirmasi) karena di sinilah interaksi objek yang paling menarik terjadi.

Berikut adalah partisipan (lifelines) dalam skenario kita:

Mengapa Partisipan Ini?

Dalam aplikasi Laravel (Bagian 5), ini dipetakan langsung ke:

• EnrolmentController → App\Http\Controllers\EnrolmentController
• CourseService → App\Services\CourseService
• EnrolmentService → App\Services\EnrolmentService
• PaymentGateway → App\Services\PaymentGateway (atau SDK pihak ketiga seperti Midtrans)
• Database → model Eloquent yang didukung oleh MySQL/PostgreSQL

Pemisahan CourseService dan EnrolmentService mengikuti Single Responsibility Principle: logika mata kuliah (kuota, jadwal) dan logika pendaftaran (konflik, registrasi) berubah karena alasan yang berbeda.

4. Sequence Diagram: Enrol in Course (Payment & Creation Flow)

Reading the Sequence Diagram

Follow the arrows from top to bottom. Each arrow is a message: a method call or an HTTP request. The activation boxes (thin rectangles on the lifelines) show when each object is actively processing.

Key observations:

1. Sequential validation. The controller checks quota and schedule conflicts before asking for payment. This prevents charging the student for a course they cannot join.

2. External system boundary. The PaymentGateway is a separate lifeline: the controller calls it, waits for a response, and only proceeds on success. This is a synchronous boundary with a timeout risk (which we handle in the implementation with try/catch and configurable timeouts).

3. Transactional boundary. The createPaidEnrolment(...) call owns the BEGIN TRANSACTION → create enrolment → record payment → update quota → COMMIT block. If any persistence operation fails, the enrolment insert is rolled back. The updated schedule is then read from enrolment data as a derived view.

4. No direct model access from controller. The controller never talks to the database directly. It delegates to CourseService and EnrolmentService, which encapsulate persistence details. This is the Service Layer pattern: the controller orchestrates, services execute.

4. Sequence Diagram: Daftar Mata Kuliah (Alur Pembayaran & Pembuatan)

Membaca Sequence Diagram

Ikuti panah dari atas ke bawah. Setiap panah adalah pesan: pemanggilan method atau HTTP request. Activation box (persegi panjang tipis pada lifelines) menunjukkan kapan setiap objek sedang aktif memproses.

Observasi kunci:

1. Validasi berurutan. Controller memeriksa kuota dan konflik jadwal sebelum meminta pembayaran. Ini mencegah penagihan kepada mahasiswa untuk mata kuliah yang tidak dapat mereka ikuti.

2. Batas sistem eksternal. PaymentGateway adalah lifeline terpisah: controller memanggilnya, menunggu respons, dan hanya melanjutkan jika berhasil. Ini adalah synchronous boundary dengan risiko timeout (yang kita tangani dalam implementasi dengan try/catch dan timeout yang dapat dikonfigurasi).

3. Batas transaksional. Panggilan createPaidEnrolment(...) memiliki blok BEGIN TRANSACTION → buat pendaftaran → catat pembayaran → perbarui kuota → COMMIT. Jika operasi persistensi mana pun gagal, insert pendaftaran di-rollback. Jadwal terbaru lalu dibaca dari data enrolment sebagai view turunan.

4. Tidak ada akses model langsung dari controller. Controller tidak pernah berbicara langsung ke database. Ia mendelegasikan ke CourseService dan EnrolmentService, yang mengenkapsulasi detail persistensi. Ini adalah pola Service Layer: controller mengorkestrasi, service mengeksekusi.

5. Sequence Diagram vs Activity Diagram: When to Use Which

Now that we have both diagrams for the same workflow, let us compare them:

Rule of thumb: If you are explaining a workflow to a product manager, use an activity diagram. If you are explaining the same workflow to a developer who will implement it, use a sequence diagram. In a complete UML model, you create both: the activity diagram for the business view, the sequence diagram for the technical view.

5. Sequence Diagram vs Activity Diagram: Kapan Menggunakan yang Mana

Sekarang kita memiliki kedua diagram untuk alur kerja yang sama, mari kita bandingkan:

Aturan praktis: Jika Anda menjelaskan alur kerja kepada product manager, gunakan activity diagram. Jika Anda menjelaskan alur kerja yang sama kepada developer yang akan mengimplementasikannya, gunakan sequence diagram. Dalam model UML yang lengkap, Anda membuat keduanya: activity diagram untuk tampilan bisnis, sequence diagram untuk tampilan teknis.

6. Sequence Diagram Best Practices

Keep Messages at a Consistent Level of Abstraction

Avoid putting raw SQL such as SELECT * FROM courses directly in message labels when the diagram is otherwise written at the HTTP and service-method level. Prefer semantic persistence messages such as findCourse(course_id) or recordPayment(...), and place SQL details in notes or implementation code if they are needed.

Return Messages Matter When Data Flows

If a return message carries data (e.g., gateway response {success, transaction_id}), include it. If it only signals completion (OK), you can omit it for brevity, but always include it when the data is used in subsequent messages.

Use Fragments for Conditional Logic

Do not draw three separate diagrams for the success path, the quota-full path, and the payment-failure path. Use alt fragments to keep all paths in one diagram. This is what makes the sequence diagram a complete specification.

Number Your Messages (Optional)

In formal specifications, messages are numbered (1. getCourseDetails, 2. checkQuota, etc.). This helps when referencing specific interactions in documentation or code comments. PlantUML supports this with the autonumber directive at the top of the diagram.

Avoid God Lifelines

If one lifeline (usually the controller) receives 15+ messages, consider splitting the diagram into smaller interaction diagrams or delegating responsibilities. A controller that orchestrates too many services might benefit from a facade or orchestrator service.

6. Praktik Terbaik Sequence Diagram

Jaga Pesan pada Tingkat Abstraksi yang Konsisten

Hindari menaruh SQL mentah seperti SELECT * FROM courses langsung pada label pesan ketika bagian lain dari diagram ditulis pada level HTTP dan pemanggilan method service. Gunakan pesan persistensi semantik seperti findCourse(course_id) atau recordPayment(...), lalu letakkan detail SQL di catatan atau kode implementasi jika memang diperlukan.

Return Message Penting Ketika Data Mengalir

Jika return message membawa data (misalnya, respons gateway {sukses, transaction_id}), sertakan. Jika hanya menandakan penyelesaian (OK), Anda dapat menghilangkannya untuk keringkasan, tetapi selalu sertakan ketika data digunakan dalam pesan berikutnya.

Gunakan Fragmen untuk Logika Kondisional

Jangan menggambar tiga diagram terpisah untuk jalur sukses, jalur kuota penuh, dan jalur kegagalan pembayaran. Gunakan fragmen alt untuk menyimpan semua jalur dalam satu diagram. Inilah yang membuat sequence diagram menjadi spesifikasi yang lengkap.

Beri Nomor Pesan Anda (Opsional)

Dalam spesifikasi formal, pesan diberi nomor (1. getCourseDetails, 2. checkQuota, dll.). Ini membantu saat mereferensikan interaksi tertentu dalam dokumentasi atau komentar kode. PlantUML mendukung ini dengan direktif autonumber di bagian atas diagram.

Hindari God Lifeline

Jika satu lifeline (biasanya controller) menerima 15+ pesan, pertimbangkan untuk membagi diagram menjadi diagram interaksi yang lebih kecil atau mendelegasikan tanggung jawab. Controller yang mengorkestrasi terlalu banyak service mungkin mendapat manfaat dari service facade atau orchestrator.

7. From Sequence to Class Diagram

The sequence diagram has revealed the methods each object must implement, the parameters they accept, and the data they return. This is the final piece of behavioural specification before we move to structural design.

In Part 5, we will take the domain objects from this sequence diagram (Student, Course, Enrolment, Payment, along with the supporting entities Lecturer, Admin, Schedule) and add the Laravel realization classes that execute the messages: controller, form requests, services, gateway, and API resources. Then we will implement them as familiar Laravel code.

7. Dari Sequence ke Class Diagram

Sequence diagram telah mengungkapkan method yang harus diimplementasikan oleh setiap objek, parameter yang mereka terima, dan data yang mereka kembalikan. Ini adalah bagian terakhir dari spesifikasi perilaku sebelum kita beralih ke desain struktural.

Di Bagian 5, kita akan mengambil objek domain dari sequence diagram ini (Student, Course, Enrolment, Payment, bersama dengan entitas pendukung Lecturer, Admin, Schedule) lalu menambahkan class realisasi Laravel yang mengeksekusi message: controller, form request, service, gateway, dan API resource. Kemudian kita akan mengimplementasikannya sebagai kode Laravel yang familier.