Statecharts: Hiyerarşik durum makineleri

 (statecharts.dev)
1 puan yazan GN⁺ 3 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Karmaşık sistemlerin davranışını görsel olarak yapılandıran bir biçimdir; temel state machine kavramını genişleterek state explosion sorununu ele alacak şekilde güçlendirilmiştir
  • Davranış ile bileşenlerin ayrılması mümkün hale gelir; böylece davranışı değiştirmek ve kod üzerinde akıl yürütmek kolaylaşır, ayrıca bileşenden bağımsız test ve istisna durumlarını keşfetme için de uygundur
  • Statechart oluşturma sürecinde olası durumların tamamı incelenir; ayrıca statechart tabanlı kodun geleneksel koda göre daha az hata içerdiğini gösteren araştırma sonuçları da vardır
  • SCXML standardı ile çeşitli dillerdeki araç ve kütüphaneler sayesinde modeli okuyabilir, yazabilir ve çalıştırabilirsiniz; bu da entry/exit action gibi işlem sıralarının doğru ele alınmasına yardımcı olur
  • Çalıştırılabilir machine format kullanılırsa tek bir tanım single source of truth olarak alınabilir; böylece çalışma zamanı davranışı ile diyagram birlikte korunur ve uygulama ile tasarımın senkron kalması önemli hale gelir

Statecharts genel bakış

  • Statechart, karmaşık sistemleri ele almak için kullanılan görsel bir biçimdir ve temel state machine yapısının genişletilmiş halidir
  • State machine büyüdükçe ortaya çıkan state explosion sorununu ele alacak şekilde güçlendirilmiştir
  • Davranış diyagramla ifade edilebilir, ancak yazılım mühendisliğinde bu yaklaşım görselleştirmenin kendisinden çok davranış modelleme ve yapılandırmaya yakındır
  • İlgili temel açıklamalar What is a state machine? ve What is a statechart? sayfalarında devam ediyor

Neden Statecharts kullanılır?

  • Kolay anlaşılır bir yapı sunduğu için birçok başka kod biçimine göre kavraması daha kolaydır
  • Davranış ile bileşenlerin ayrılması mümkündür
    • Davranışı değiştirmek kolaylaşır
    • Kod üzerinde akıl yürütmek kolaylaşır
    • Davranış, bileşenden bağımsız olarak test edilebilir
  • Statechart oluşturma sürecinde olası durumların tamamı incelenir
  • Statechart tabanlı kodun geleneksel koda göre daha az hata içerdiğini gösteren araştırmalar vardır
  • Gözden kaçması kolay istisna durumlarını ele almak için uygundur
  • Karmaşıklık arttıkça ölçeklenebilirliği daha iyi olur
  • Geliştirici olmayan kişilerin de anlaması kolaydır; QA ise bunu bir keşif aracı olarak kullanabilir
  • Zaten birçok kod tabanı örtük olarak state machine içerir; statechart ise bunu açıkça görünür kılan bir yaklaşım olarak çalışır

Statecharts'un yükü ve itiraz nedenleri

  • Yeni bir öğrenme maliyeti gerektirir
    • Temel kavram olan state machine birçok programcıya zaten tanıdık olabilir
  • Mevcut kodlama biçimlerinden oldukça farklı olduğu için alışılmadık bir paradigma gibi gelebilir
    • Takım düzeyinde direnç oluşabilir
  • Küçük statechart'larda davranışı ayırma süreci nedeniyle kod satırı sayısı artabilir
  • Yaygın kullanılmamasının nedenleri arasında farkındalık eksikliği ve YAGNI birlikte etkili olur
  • Yaygın karşı argümanlar arasında buna gerçekten gerek olmaması, belirli teknoloji akışlarına uymaması ve kütüphane sayısını artırması sayılır
    • Web uygulamalarında yükleme süresi artabilir
  • Bu artı ve eksiler birlikte değerlendirildiğinde bile benimsemenin etkisi genel olarak net pozitif olmaya yakındır

Kullanım şekli ve SCXML

  • SCXML, 2005'ten 2015'e kadar W3C tarafından standartlaştırılmış bir biçimdir; statechart'ın çeşitli anlam kurallarını ve edge case işleme davranışlarını tanımlar
  • Farklı dillerde SCXML okuyup yazabilen ve çalıştırabilen araçlar vardır
  • Aynı modeli koruyup yalnızca sözdizimi farklı olan türev biçimler de bulunur
  • Farklı platformlar için statechart kütüphaneleri vardır ve bunlar SCXML anlam kurallarını farklı düzeylerde destekler
  • Bu tür kütüphaneler, entry/exit action gibi işlem sıralarının doğru ele alınmasına yardımcı olur
  • Ek kullanım rehberi how to use statecharts sayfasında devam ediyor

Çalıştırılabilir Statecharts

  • Statechart'ları yalnızca belge olarak kullanmak yerine, çalıştırılabilir machine format hem tasarımda hem çalışma zamanında birlikte kullanılabilir
  • Tek bir tanım single source of truth olarak alınabilir; böylece gerçek çalışma zamanı davranışı ile görsel diyagram birlikte işletilebilir
  • Diyagramı koda dönüştürme işi ortadan kalkar
  • Elle çeviriden kaynaklanan hatalar azaltılabilir
  • Diyagram ile uygulama her zaman senkronize durumda kalır
  • Diyagram daha hassas hale gelir
  • Buna karşılık diyagram oldukça karmaşık hale gelebilir
  • Çalıştırılabilir statechart'lar için biçim ve araç seçenekleri sınırlıdır
  • Statechart ile bileşenler arasındaki tip güvenliğini güçlü biçimde garanti etmek zordur
  • Statechart tanımı kodun içindeyse, bu ifade kullanılarak görsel statechart otomatik üretilebilir
    • Tanım JSON veya XML gibi ayrı bir dosyada olduğunda bu daha da basitleşir

Topluluk ve ek kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 3 일 전
Hacker News yorumları

  • statecharts'ın yeniden ilgi görmeye devam ettiğini görmek sevindirici
    JS/TS için durum makineleri ve statecharts yazma/çalıştırma/görselleştirme kütüphanesi XState'i ben yaptım; şurada bulunabilir: https://github.com/statelyai/xstate
    10 yıldan uzun süredir bunun üzerinde çalışırken öğrendiğim en önemli şey, statecharts'ın en büyük değerini onları basit bir doküman olarak değil, çalıştırılabilir davranış olarak ele aldığınızda sunduğudur
    Her yerde kullanmak gerekmiyor; özellikle "sırada ne olacak?" sorusunun hem mevcut duruma hem de olaya bağlı olduğu durumlarda çok güçlü
    Bu tür çizelgeler, "şu an bu durumdayken bu olay gelirse bir sonraki durum nedir ve hangi etkiler çalışır?" sorusunu yanıtlayan bir oracle gibi kullanılabilir
    XState'in bir sonraki büyük sürüm alfası da neredeyse hazır; ergonomics, tip güvenliği, composability ve yeni visualizer/editor üzerine odaklanıyor
    Temel açık kaynak görselleştirme aracı burada: https://sketch.stately.ai
    Biçimsel belirtim tarafında SCXML okumaya değer: https://www.w3.org/TR/scxml
    David Harel'in orijinal makalesi de çok değerli: https://www.weizmann.ac.il/math/harel/sites/math.harel/files/users/user50/Statecharts.pdf

    • Sayende ilk kez state machines ile tanıştım
      Laracon'da state machines ve statecharts hakkındaki düşüncelerimi toparlayıp anlattığım bir konuşma videosu da var
      https://www.youtube.com/watch?v=1A1xFtlDyzU
    • Clojure tarafında https://github.com/fulcrologic/statecharts önerilebilir
      Özellikle çalıştırılabilir içerikte XML zorunluluğunu kaldırırken SCXML'e epey yakın duran, oldukça olgun bir implementasyon
      prior art bölümünde XState de referans örneklerden biri olarak geçiyor
    • XState kullanırken statecharts terimini bilmeden de çok faydasını gördüm
      Bunu lit.js ile birlikte, sayfa genişliğine tepki veren ve çok sayıda props ile iç durum barındıran drawer tarzı bir navigasyon bileşeninde kullandım; XState olmasa ne kadar korkunç olacağını düşünmek bile istemiyorum
    • Eskiden karmaşık şekilde birbirine dolanmış durumları XState ile çok toparladım
      Sonraki sürümü de merakla bekliyorum, gerçekten teşekkürler
    • Karmaşık iç içe geçmiş durum makineleri gerekmiyorsa robot3.js'e de bakılabilir
      Otomatik TS tip çıkarımı oldukça iyi, bu yüzden hafif durum makinesi mantığı gereken yerlerde kullanması rahat

  • Eskiden frontend/UI ecosystem içinde statecharts'ın yavaş yavaş ivme kazandığı hissi vardı; nedense o akışın kaybolmuş olması üzücü
    UI etkileşimlerinde durum makineleri, özellikle de statecharts gibi durum makinesi bileşimleri kullanmak, karmaşık akışları akıl yürütmeyi çok daha kolaylaştırıyor
    Buna yeni başlıyorsanız Ian Horrucks'un "Constructing the user interface with statecharts" kitabını özellikle tavsiye ederim
    1999 tarihli olsa da, bunu pratikte nasıl uygulayıp kullanmanız gerektiğini anlatan giriş düzeyi bir kaynak olarak hâlâ en iyilerden biri
    https://archive.org/details/isbn_9780201342789/mode/2up

    • XState hâlâ gayet yayılmaya devam ediyor
      Haftalık npm indirmeleri 4 milyonu aşıyor; Rive ve LottieFiles gibi animasyon araçları da durum makinesi özelliklerini güçlü biçimde öne çıkarıyor
      LangGraph gibi yapay zeka araçları da durum makinesi tabanlı bir yapı üzerine kurulu
      Bu uygulama ve araçların statecharts'ın potansiyelini tam olarak açığa çıkarması zaman alacaktır ama başlangıç iyi
    • Ben de statecharts'ı şu Godot plugin sayesinde tanıdım
      https://github.com/derkork/godot-statecharts

  • Giriş kaynaklarında sık atlanan konulardan biri history pseudo-states
    H ve H kullanırsanız, dışarıdan bakıldığında statechart biçimsel olarak deterministik olmaktan çıkar
    Genelde "mevcut durum, girdinin saf bir fonksiyonudur" diye anlatılır ama history bu varsayımı bozar
    Üst duruma H üzerinden yeniden girerseniz, en son aktif olan çocuğa dönersiniz; dolayısıyla aynı olay ve aynı dış durum altında farklı iç durumlara girmeniz mümkündür
    Gizli duran o "son aktif çocuk" da aslında bir durumdur ama genelde diyagramda çizilmez
    Harel'in orijinal makalesi de bunu kabul ediyor; SCXML ve XState de bunu uyguluyor ama nedense bu kısım neredeyse hiç konuşulmuyor
    Bu yüzden deep history ile alt ağaç durumunu yeniden girişte koruyorsanız, bookkeeping işini çizelge motoru tarafına taşımış oluyorsunuz
    Bu makul bir tercih ama yalnızca şekle bakarak tüm davranışı açıklayamıyorsunuz; history geçişleri de diğer durum mantıkları gibi ayrıca test edilmeli

    • Burada inputs ifadesini yalnızca mevcut ve gelecekteki girdiler olarak da, bulunduğunuz noktaya gelene kadarki geçmiş girdileri de içeren toplam girdi olarak da yorumlayabilirsiniz
      İkinci yorum benimsenirse makine tamamen deterministiktir ve deep history pointer da sadece durum makinesi durumunun bir parçasıdır
    • Yalnızca tarif edilen senaryoya bakarsak history düğümü yeniden deterministik biçimde modellenebilir gibi görünüyor
      Örneğin H ve H düğümlerini birden fazla düğüme açabilir, H'yi de her düğümün önüne eklenen bir write-ahead log gibi düşünebilirsiniz

  • Temporal, DBOS, Restate gibi durable execution motorlarıyla statecharts'ı birleştirmenin mümkün olup olmayacağını merak ediyorum
    Şirkette onboarding ve payment workflow'larını yönetirken Cloudflare Workflows kullanıyoruz; otomatik üretilen flowchart diyagramları sayesinde workflow davranışını hızlıca anlamak mümkün oluyor
    Bu da sonuçta statecharts'ın hedeflediği değere oldukça benziyor

    • Zindex'i tam da bu "çalıştırılabilir workflow'ların görsel temsili" katmanı için geliştiriyoruz
      https://zindex.ai/
      Yapay zekanın ürettiği diyagramlar çoğunlukla bir kez oluşturulup bırakılan Mermaid/SVG/PNG çıktıları oluyor; yani güncellenebilen, doğrulanabilen, diff alınabilen ve yeniden kullanılabilen kalıcı diyagram durumu bulunmuyor
      Zindex diyagramın kendisini yapılandırılmış bir durum olarak ele alıyor
      Agent'lar Diagram Scene Protocol (DSP) üzerinden node, edge, group, relation, constraint ve revision'ları patch ediyor; Zindex ise validation, layout, rendering, versioning ve storage işlerini üstleniyor
      Böylece bunun Temporal/DBOS/Restate/Cloudflare Workflows yanına eklenebileceğini düşünüyoruz; yürütmenin asıl gerçeğini motor korurken, Zindex koddan veya yürütme geçmişinden türetilen kalıcı ve denetlenebilir görsel modeli yönetebilir
    • Workflow'ların bu kadar öne çıkıp state machines'in görece az değer görmesi bana hep garip gelmiştir
      Aslında durable execution eklendiğinde statecharts da bunu rahatlıkla yapabilir
      Cloudflare bir süre durable object actor modeli yönüne gidiyor gibiydi ama o projeyi kapatıp kapatmadıklarını bilmiyorum
    • "flowchart diyagramları üretiyor" derken tam olarak neyin bunu ürettiğini merak ettim
      Bu Cloudflare Workers içine yerleşik bir özellik mi, yoksa ekip içinde sizin geliştirdiğiniz bir şey mi?

  • XState'i gerçekten çok seviyorum
    Birçok kod tabanında sayısız sorunu çözmeme yardımcı oldu; son dönemde de bankacılık için geliştirdiğimiz bir ses uygulamasının ana omurgası haline geldi
    Buna bu kadar zaman ve emek harcayıp böylesine iyi bir araç çıkardığınız için teşekkürler
    Sonlu durum makineleri deneyimimi ve XState + Mastra ile kurduğumuz mimariyi blogda biraz yazmıştım
    Yayınlandıktan sonra Mastra'dan Pipecat'e geçtik
    https://blog.davemo.com/posts/2026-02-14-deterministic-core-agentic-shell.html

  • Bunu da ekleyeyim
    ETL State Chart ve Hierarchial FSM:
    https://www.etlcpp.com/state_chart.html / https://www.etlcpp.com/hfsm.html
    Quantum Leaps:
    https://www.state-machine.com
    Bunları daha çok safety-critical sistemlerde kullandım; burada karmaşıklık, zamanlama ve davranışın doğrulanabilirliği özellikle önemli
    Karar verme ile eylemi ayırabilmek büyük fayda sağlıyor
    "Şu anda bu durumdayken bu olay gelirse sırada ne yapacağız?" diye kararları sadeleştirme yaklaşımı, alışılmış program yapısından biraz farklı ama iyi bir ayrım sağlıyor ve farklı koşullarda davranışı akıl yürütmeyi kolaylaştırıyor

  • Durum makinelerinin daha yaygın benimsenmesini hep istedim
    Yapay zekanın ürettiği kodu, insanların yazdığı kod kadar derinlemesine anlamadığımız bir dönemde state'in görsel olarak anlaşılması giderek daha önemli hale geliyor
    Yine de frontend framework'lerinde store tabanlı reactive state daha çok tercih ediliyor gibi görünüyor
    Ben de bunu varsayılan olarak kullanma eğilimindeyim; xstate gibi kütüphanelerin sözdizimini öğrenmenin daha zor ve daha ayrıntılı olduğu algısı da var
    Ama yapay zeka ile bu engel neredeyse ortadan kalkıyor; bu yüzden gözden kaçırdığım başka nedenler mi var, yoksa statechart'lar hâlâ zirvesine ulaşmadı mı diye merak ediyorum

    • Bir sonraki XState sürümü çok daha ergonomic olacak
      API yüzeyi küçülecek, öğrenme eğrisi düşecek ve hem geliştiricilerin hem de agent'ların yazması kolaylaşacak
      Aynı zamanda güncel frontier modeller XState kodunu şimdiden epey iyi yazabiliyor

  • https://github.com/xlnfinance/xln projesi üzerinde çalışırken, gerçek ağı deterministik olarak emüle etmenin bir yoluna ihtiyaç duyduğumu fark ettim
    Sonra tüm blockchain'lerin aslında birer replicated state machine olduğunu düşündüm; o halde neden her kullanıcı düğümünü Runtime -> Entity -> Account şeklinde 3 kademeli bir durum makinesi hiyerarşisi içine sarmayalım?
    Dış makine içtekini tamamen kontrol ediyor; yani farklı uzlaşma modlarına sahip bir "blockchain içinde blockchain" resmi gibi
    Sonrasında "hierarchical state machines" diye aratırken statecharts'a rastladım ve iki fikrin oldukça benzer olduğunu düşündüm
    Bence daha fazla yazılım, determinizm eksikliğinin ürettiği en kötü hataları azaltmak için durum makinesi hiyerarşilerini kullanmalı

  • Otomotiv alanında bu yaklaşım uzun zamandır kullanılıyor
    matlab/simulink'e bakarsanız, algoritmaları durum makinesi olarak çizip oradan kod üretmek mümkün
    Yakın zamanda CSS transition'lar üzerinden birden çok görsel durum arasında gidip gelen epey karmaşık bir React bileşenini yönetmek için ben de bir durum makinesi uyguladım
    Durum makinesinin kendisi çok zor değildi ama insanlar buna yeterince aşina değil gibi görünüyor

    • Oyun motorları da muhtemelen bunun bir versiyonunu, hatta daha gelişmişini zaten uygulamıştır

  • Şirkette ben Postgres iç yorumlayıcısını yaptıktan sonra tüm iş süreçlerini statecharts ile yürütmeye başladık
    Deneyim çok iyiydi; süreçler değişime karşı oldukça dayanıklı hale geldi ve birkaç yıl sonra dönüp bakınca bile anlaması kolay kaldı
    Kütüphaneyi de açık kaynak olarak yayımladım
    https://github.com/kronor-io/statecharts