Statecharts: 계층적 상태 기계

3 hours ago 2

복잡한 시스템의 행동을 시각적으로 구조화하는 형식으로, 기본 state machine을 확장해 state explosion 문제를 다루도록 보강됨
행동과 컴포넌트의 분리가 가능해져 동작 변경과 코드 추론이 쉬워지고, 컴포넌트와 독립적인 테스트와 예외 상황 탐색에도 잘 맞음
statechart를 만드는 과정에서 가능한 상태를 전부 탐색하게 되며, statechart 기반 코드는 전통적인 코드보다 버그 수가 더 낮았던 연구 결과도 있음
SCXML 표준과 여러 언어의 도구·라이브러리를 통해 모델을 읽고 작성하고 실행할 수 있으며, entry/exit action 같은 동작 순서를 올바르게 처리하는 데 도움을 줌
실행 가능한 machine format을 쓰면 하나의 정의를 single source of truth로 삼아 런타임 동작과 다이어그램을 함께 유지할 수 있어, 구현과 설계의 동기화 유지가 중요해짐

Statecharts 개요

새로운 학습 비용이 필요함
- 기반 개념인 state machine 자체는 많은 프로그래머에게 익숙할 수 있음
기존 코딩 방식과 꽤 달라서 낯선 패러다임으로 느껴질 수 있음
- 팀 차원에서 거부감이 생길 수 있음
작은 statechart에서는 동작을 분리하는 과정 때문에 코드 줄 수가 늘어날 수 있음
널리 쓰이지 않는 이유로는 인지 부족과 YAGNI가 함께 작용함
흔한 반대 논리로는 굳이 필요하지 않다는 점, 특정 기술 흐름에 맞지 않는다는 점, 라이브러리 수가 늘어난다는 점이 꼽힘
- 웹 애플리케이션에서는 로드 시간이 늘 수 있음
이런 장단점을 함께 보더라도 도입 효과는 전반적으로 순이익에 가까움

SCXML은 2005년부터 2015년까지 W3C에서 표준화한 형식으로, statechart의 다양한 의미 규칙과 엣지 케이스 처리를 정의함
여러 언어에서 SCXML을 읽고 작성하고 실행하는 도구가 있음
같은 모델을 유지하면서 문법만 다른 파생 형식도 있음
다양한 플랫폼용 statechart 라이브러리가 있으며, SCXML 의미 규칙을 각기 다른 수준으로 지원함
이런 라이브러리를 쓰면 entry/exit action 같은 동작 순서를 올바르게 처리하는 데 도움이 됨
추가 사용 가이드는 how to use statecharts에서 이어짐

문서로만 statechart를 쓰는 대신, 실행 가능한 machine format을 설계와 런타임에 함께 쓸 수 있음
하나의 정의를 single source of truth로 삼아 실제 런타임 동작과 시각적 다이어그램을 함께 구동할 수 있음
다이어그램을 코드로 옮기는 작업이 필요 없어짐
손으로 번역하면서 생기는 버그를 줄일 수 있음
다이어그램과 구현이 항상 동기화된 상태를 유지함
다이어그램이 더 정밀해짐
반대로 다이어그램은 꽤 복잡해질 수 있음
실행 가능한 statechart를 위한 포맷과 도구 선택지는 제한적임
statechart와 컴포넌트 사이의 타입 안전성을 강하게 보장하기는 어려움
코드 안에 statechart 정의가 있다면 그 표현을 이용해 시각적 statechart를 자동 생성할 수 있음
- 정의가 JSON이나 XML 같은 별도 파일에 있을 때 더 단순해짐