1 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Format untuk menyusun secara visual perilaku sistem yang kompleks, yang memperluas state machine dasar agar lebih mampu menangani masalah state explosion
  • Memungkinkan pemisahan perilaku dan komponen, sehingga perubahan perilaku dan penalaran kode menjadi lebih mudah, serta cocok untuk pengujian yang independen dari komponen dan eksplorasi kondisi pengecualian
  • Dalam proses membuat statechart, semua kemungkinan status akan dieksplorasi, dan ada pula hasil riset yang menunjukkan jumlah bug lebih rendah pada kode berbasis statechart dibandingkan kode tradisional
  • Melalui standar SCXML dan alat serta pustaka di berbagai bahasa, model dapat dibaca, ditulis, dan dijalankan, serta membantu menangani urutan perilaku seperti entry/exit action dengan benar
  • Jika menggunakan machine format yang dapat dieksekusi, satu definisi dapat dijadikan single source of truth untuk menjaga perilaku runtime dan diagram tetap selaras, sehingga menjaga sinkronisasi antara implementasi dan desain menjadi penting

Gambaran Umum Statecharts

  • Statechart adalah format visual untuk menangani sistem yang kompleks, berupa perluasan dari state machine dasar
  • Ini diperkuat untuk menangani masalah state explosion yang muncul saat state machine membesar
  • Perilaku bisa dinyatakan dalam bentuk gambar, tetapi dalam rekayasa perangkat lunak, ini lebih dekat ke pemodelan perilaku dan penyusunan struktur daripada visualisasi itu sendiri
  • Penjelasan dasar terkait dilanjutkan di What is a state machine?, What is a statechart?

Mengapa Menggunakan Statecharts

  • Memiliki struktur yang mudah dipahami, sehingga lebih mudah dimengerti dibanding banyak bentuk kode lainnya
  • Memungkinkan pemisahan perilaku dan komponen
    • Perubahan perilaku menjadi lebih mudah
    • Penalaran terhadap kode menjadi lebih mudah
    • Perilaku dapat diuji secara independen dari komponen
  • Dalam proses membuat statechart, kita akan mengeksplorasi semua status yang mungkin
  • Ada hasil riset yang menunjukkan jumlah bug lebih rendah pada kode berbasis statechart dibandingkan kode tradisional
  • Cocok untuk menangani kondisi pengecualian yang mudah terlewat
  • Semakin besar kompleksitasnya, semakin baik skalabilitasnya
  • Mudah dipahami bahkan oleh orang non-developer, dan QA dapat memanfaatkannya sebagai alat eksplorasi
  • Banyak kode sebenarnya sudah memuat state machine secara implisit, dan statechart bekerja sebagai cara untuk menampakkannya secara eksplisit

Beban dan Faktor Penolakan terhadap Statecharts

  • Membutuhkan biaya pembelajaran baru
    • Meski konsep dasarnya, yaitu state machine, mungkin sudah akrab bagi banyak programmer
  • Cukup berbeda dari cara menulis kode yang ada, sehingga bisa terasa sebagai paradigma yang asing
    • Hal ini bisa menimbulkan penolakan di tingkat tim
  • Pada statechart kecil, proses memisahkan perilaku bisa membuat jumlah baris kode bertambah
  • Alasan mengapa ini belum digunakan secara luas antara lain kurangnya kesadaran dan YAGNI yang bekerja bersamaan
  • Argumen penolakan yang umum adalah merasa ini tidak terlalu perlu, tidak sesuai dengan arus teknologi tertentu, dan menambah jumlah pustaka
    • Pada aplikasi web, waktu muat bisa bertambah
  • Meski melihat kelebihan dan kekurangan ini secara bersamaan, efek adopsinya secara umum tetap lebih dekat ke keuntungan bersih

Cara Penggunaan dan SCXML

  • SCXML adalah format yang distandardisasi oleh W3C dari 2005 hingga 2015, yang mendefinisikan berbagai aturan semantik statechart dan penanganan edge case
  • Ada alat di berbagai bahasa untuk membaca, menulis, dan menjalankan SCXML
  • Ada juga format turunan dengan sintaks berbeda sambil mempertahankan model yang sama
  • Tersedia pustaka statechart untuk berbagai platform, dengan tingkat dukungan berbeda-beda terhadap aturan semantik SCXML
  • Menggunakan pustaka-pustaka ini membantu menangani urutan perilaku seperti entry/exit action dengan benar
  • Panduan penggunaan tambahan dilanjutkan di how to use statecharts

Statecharts yang Dapat Dieksekusi

  • Alih-alih memakai statechart hanya sebagai dokumen, machine format yang dapat dieksekusi dapat digunakan bersama untuk desain dan runtime
  • Satu definisi dapat dijadikan single source of truth untuk menggerakkan perilaku runtime nyata dan diagram visual sekaligus
  • Tidak lagi perlu memindahkan diagram ke dalam kode
  • Dapat mengurangi bug yang muncul saat menerjemahkannya secara manual
  • Diagram dan implementasi selalu menjaga keadaan yang tersinkronisasi
  • Diagram menjadi lebih presisi
  • Sebaliknya, diagram juga bisa menjadi cukup kompleks
  • Pilihan format dan alat untuk statechart yang dapat dieksekusi masih terbatas
  • Sulit untuk menjamin type safety yang kuat antara statechart dan komponen
  • Jika definisi statechart ada di dalam kode, representasi itu dapat dipakai untuk menghasilkan statechart visual secara otomatis
    • Ini menjadi lebih sederhana jika definisinya berada di file terpisah seperti JSON atau XML

Komunitas dan Materi Tambahan

1 komentar

 
GN⁺ 5 jam lalu
Opini Hacker News
  • Senang melihat statecharts terus mendapat perhatian
    Saya membuat XState, library untuk menulis/menjalankan/memvisualisasikan state machine dan statecharts untuk JS/TS, dan bisa dilihat di https://github.com/statelyai/xstate
    Hal terpenting yang saya pelajari selama lebih dari 10 tahun mengerjakannya adalah bahwa statecharts paling bernilai ketika diperlakukan bukan sekadar sebagai dokumentasi, melainkan sebagai perilaku yang dapat dieksekusi
    Tidak perlu dipakai di semua tempat, tetapi sangat kuat terutama ketika "apa yang terjadi berikutnya?" bergantung pada status saat ini dan juga event
    Diagram seperti ini bisa dipakai seperti oracle yang menjawab, "jika event ini datang pada status ini sekarang, status berikutnya apa dan efek apa yang dijalankan?"
    Alpha untuk major version berikutnya dari XState juga hampir siap, dengan fokus pada ergonomics, type safety, composability, dan visualizer/editor baru
    Alat visualisasi open source dasarnya ada di https://sketch.stately.ai
    Untuk sisi spesifikasi formal, SCXML layak dibaca: https://www.w3.org/TR/scxml
    Makalah asli David Harel juga sangat berharga: https://www.weizmann.ac.il/math/harel/sites/math.harel/files/users/user50/Statecharts.pdf

    • Berkat Anda saya jadi mengenal state machines untuk pertama kalinya
      Ada juga video presentasi di Laracon yang merangkum pemikiran tentang state machines dan statecharts
      https://www.youtube.com/watch?v=1A1xFtlDyzU
    • Untuk ekosistem Clojure, https://github.com/fulcrologic/statecharts layak direkomendasikan
      Ini implementasi yang cukup matang, tetap sangat dekat dengan SCXML sambil menghapus kebutuhan XML, terutama untuk konten yang dapat dieksekusi
      XState juga masuk sebagai referensi di bagian prior art
    • Saat memakai XState, saya tetap merasa sangat terbantu meski tidak tahu istilah statecharts
      Saya memakainya bersama lit.js untuk komponen navigasi tipe drawer yang responsif terhadap lebar halaman dan punya banyak props serta state internal; saya bahkan tak bisa membayangkan betapa mengerikannya tanpa XState
    • Dulu saya banyak merapikan situasi rumit yang kusut dengan XState
      Sangat menantikan versi berikutnya, dan terima kasih banyak
    • Kalau tidak butuh nested state machine yang rumit, robot3.js juga layak dilihat
      Inferensi tipe TS otomatisnya cukup bagus, jadi nyaman dipakai saat butuh logika state machine yang ringan
  • Dulu rasanya statecharts mulai mendapat momentum di frontend/UI ecosystem, jadi sayang aliran itu seperti menghilang entah kenapa
    Untuk interaksi UI, memakai state machine, khususnya komposisi state machine seperti statecharts, membuat alur yang kompleks jauh lebih mudah dipahami
    Kalau baru pertama kali mengenalnya, saya sangat merekomendasikan Ian Horrucks, "Constructing the user interface with statecharts"
    Memang buku tahun 1999, tetapi sebagai pengantar yang menjelaskan cara benar-benar menerapkan dan memakainya, ini masih termasuk yang terbaik
    https://archive.org/details/isbn_9780201342789/mode/2up

    • XState masih terus menyebar dengan baik
      Unduhan npm mingguannya sudah melewati 4 juta, dan alat animasi seperti Rive dan LottieFiles juga sangat menonjolkan kemampuan state machine
      Alat AI seperti LangGraph juga dibangun di atas dasar state machine
      Mungkin masih perlu waktu agar aplikasi dan alat ini benar-benar mengeluarkan seluruh potensi statecharts, tetapi awalnya bagus
    • Saya juga mengenal statecharts lewat plugin Godot ini
      https://github.com/derkork/godot-statecharts
  • Bagian yang sering hilang dari buku pengantar adalah history pseudo-states
    Jika memakai H, H, maka dari sudut pandang luar statechart menjadi tidak deterministik secara formal
    Sering dijelaskan bahwa "status saat ini adalah fungsi murni dari input", tetapi history merusak asumsi itu
    Saat masuk kembali ke parent state melalui H, kita kembali ke child terakhir yang aktif, jadi dengan event yang sama dan status luar yang sama pun kita bisa masuk ke status internal yang berbeda
    "Child aktif terakhir" yang tersembunyi itu sendiri adalah state, tetapi biasanya tidak digambar di diagram
    Makalah asli Harel juga mengakui ini, dan SCXML maupun XState juga mengimplementasikannya, tetapi justru bagian ini hampir tidak pernah dibahas
    Jadi jika Anda mempertahankan state subtree saat re-entry dengan deep history, pada dasarnya Anda memindahkan bookkeeping ke sisi chart engine
    Itu pilihan yang wajar, tetapi gambar saja tidak bisa menjelaskan seluruh perilaku, dan transisi history juga perlu diuji terpisah seperti logika state lainnya

    • Di sini inputs bisa dipahami hanya sebagai input saat ini dan masa depan, atau sebagai keseluruhan input termasuk input masa lalu yang membawa kita ke posisi sekarang
      Dengan tafsir kedua, mesinnya sepenuhnya deterministik, dan pointer deep history juga hanya bagian dari state state machine
    • Jika hanya melihat skenario yang dijelaskan, node history tampaknya tetap bisa dimodelkan kembali secara deterministik
      Misalnya, node H, H bisa diurai menjadi beberapa node, dan H' bisa diletakkan di depan tiap node seperti write-ahead log
  • Saya penasaran apakah engine durable execution seperti Temporal, DBOS, Restate bisa digabungkan dengan statecharts
    Di perusahaan, kami memakai Cloudflare Workflows untuk mengelola workflow onboarding dan payment, dan diagram flowchart yang muncul otomatis membantu memahami perilaku workflow dengan cepat
    Ini terasa sangat mirip dengan nilai yang ingin dicapai statecharts

    • Saya sedang membuat Zindex tepat untuk lapisan "representasi visual dari workflow yang dapat dieksekusi" itu
      https://zindex.ai/
      Diagram yang dibuat AI biasanya hanya Mermaid/SVG/PNG sekali jadi, jadi tidak punya state diagram yang persisten yang bisa diperbarui, divalidasi, di-diff, dan dipakai ulang
      Zindex memperlakukan diagram itu sendiri sebagai state terstruktur
      Agent melakukan patch pada node, edge, group, relationship, constraint, dan revision lewat Diagram Scene Protocol (DSP), lalu Zindex menangani validation, layout, rendering, versioning, dan storage
      Jadi saya rasa ini bisa ditempelkan di samping Temporal/DBOS/Restate/Cloudflare Workflows, sehingga sumber kebenaran eksekusi tetap dijaga engine, sementara Zindex mengelola model visual persisten yang bisa diperiksa dan diturunkan dari kode atau riwayat eksekusi
    • Saya selalu merasa sayang karena workflow mendapat sorotan, sementara state machines justru kurang dihargai
      Padahal kalau ditambah durable execution, statecharts sepenuhnya mampu melakukan hal yang sama
      Cloudflare sempat terlihat mengarah ke model actor durable object, tetapi saya tidak tahu apakah proyek itu sudah dihentikan
    • Saya penasaran apa tepatnya yang dimaksud dengan "menghasilkan diagram flowchart"
      Apakah itu fitur bawaan Cloudflare Workers, atau sesuatu yang dibuat sendiri oleh tim?
  • Saya benar-benar suka XState
    Ia telah menyelesaikan banyak sekali masalah di berbagai codebase, dan belakangan menjadi kerangka inti aplikasi suara yang kami bangun untuk sektor perbankan
    Terima kasih sudah mencurahkan waktu dan usaha untuk membuatnya sebaik ini
    Saya juga sempat menulis sedikit di blog tentang pengalaman dengan finite state machines, serta arsitektur yang saya bangun dengan XState + Mastra
    Setelah dipublikasikan, saya beralih dari Mastra ke Pipecat
    https://blog.davemo.com/posts/2026-02-14-deterministic-core-agentic-shell.html

  • Saya lempar ini juga
    ETL State Chart dan Hierarchial FSM:
    https://www.etlcpp.com/state_chart.html / https://www.etlcpp.com/hfsm.html
    Quantum Leaps:
    https://www.state-machine.com
    Saya terutama memakainya di sistem safety-critical; di sana kompleksitas, timing, dan kemampuan verifikasi perilaku sangat penting
    Sangat membantu bahwa pengambilan keputusan bisa dipisahkan dari tindakan
    Cara mereduksi pengambilan keputusan menjadi "dalam state ini sekarang, jika event ini datang, apa yang dilakukan berikutnya" memang agak berbeda dari struktur program biasa, tetapi itu menciptakan pemisahan yang baik dan memudahkan penalaran perilaku di berbagai kondisi

  • Saya selalu berharap adopsi state machine tumbuh lebih besar
    Di era ketika kita tidak memahami kode buatan AI sedalam kode tulisan manusia, pemahaman visual terhadap state menjadi semakin penting
    Meski begitu, framework frontend tampaknya masih lebih menyukai reactive state berbasis store
    Saya sendiri juga menjadikannya default sehingga tidak merasa perlu berubah, dan library seperti xstate juga punya kesan lebih sulit dipelajari serta lebih verbose
    Namun dengan AI, hambatan itu hampir hilang, jadi saya penasaran apakah ada alasan lain yang tidak saya lihat, atau memang statechart belum mencapai puncaknya

    • Versi XState berikutnya akan jauh lebih ergonomic
      Permukaan API juga berkurang, kurva belajar lebih rendah, dan lebih mudah ditulis baik oleh developer maupun agent
      Pada saat yang sama, model frontier modern sudah cukup bagus dalam menulis kode XState
  • Saat mengerjakan proyek https://github.com/xlnfinance/xln, saya sadar butuh cara untuk mengemulasikan jaringan nyata secara deterministik
    Lalu saya berpikir, semua blockchain pada akhirnya adalah replicated state machine, jadi bagaimana kalau setiap node pengguna dibungkus dengan hierarki state machine 3 tingkat berupa Runtime -> Entity -> Account
    Strukturnya membuat mesin luar sepenuhnya mengendalikan mesin di dalam, jadi semacam gambaran "blockchain di dalam blockchain" dengan mode konsensus yang berbeda-beda
    Setelah itu saya mencari "hierarchical state machines" dan menemukan statecharts, dan saya merasa kedua ide itu cukup mirip
    Menurut saya, lebih banyak software seharusnya memakai hierarki state machine untuk mengurangi bug terburuk yang lahir dari non-determinisme

  • Di bidang otomotif, pendekatan seperti ini sudah dipakai sejak lama
    Kalau melihat matlab/simulink, Anda bisa menggambar algoritme sebagai state machine lalu menghasilkan kode darinya
    Belakangan saya juga mengimplementasikan state machine untuk mengelola komponen React yang cukup kompleks, dengan struktur yang melewati CSS transition dan berpindah di antara berbagai state visual
    State machine itu sendiri tidak terlalu sulit, tetapi sepertinya orang belum cukup terbiasa dengannya

    • Game engine mungkin juga sudah mengimplementasikan hal seperti ini, atau versi yang lebih maju
  • Di perusahaan, sejak saya membuat interpreter di dalam Postgres, kami menjalankan semua proses bisnis dengan statecharts
    Pengalamannya sangat baik, prosesnya menjadi sangat tahan terhadap perubahan, dan tetap mudah dipahami bahkan saat dilihat kembali beberapa tahun kemudian
    Library-nya juga sudah saya rilis sebagai open source
    https://github.com/kronor-io/statecharts