3
여기에는 대학을 위해했을 수도있는 유한 상태 기계가 포함되어 있지 않습니다.유한 상태 기계를 만들어야합니까?
누구를 만들고 왜 만들어야하는지 알고 싶습니다. 왜 그런가요?
기계를 만드는 가장 어려운 점은 무엇입니까?
A
답변
8
네, 그 중 다수입니다. 기본적으로 성능상의 이유로 수동으로 어휘 분석기를 구현해야했습니다. FSA가 사용자와의 상호 작용의 흐름을 제어하는 GUI 설계에서 다른 개인 용도로 사용되었습니다.
이러한 시스템을 만드는 것은 전혀 어렵지 않습니다. 을 변경하는 것은 FSA의 구조 중 적어도 일부가 코드에 엄격하게 포함되어 있기 때문입니다. state pattern은 일부 전환을 완화하는 데 도움이됩니다.
1
위와 같이 FSA의 목적은 단계별로 단계별로 진행되므로 모든 처리 (및 상태 변경)가 하나의 루프에서 처리된다는 것입니다. 그리고 프로세스에서 무언가가 바뀌면 다음 논리적 인 단계로 넘어 가기는 쉽습니다.
예, 쉽게 할 수 있습니다. 나는 25 년 이상 자주 사용했습니다.
5
여러 번!
통신 시스템에 사용되는 대부분의 프로토콜 스택은 상태 시스템으로 구현됩니다. 하나의 좋은 예가 CSTA 호출 모델입니다.
또한 대부분의 임베디드 시스템은 기본적으로 상태 시스템입니다.
현실 세계에서 이벤트에 반응해야하는 시스템은 기본적으로 상태 시스템으로 구현하기에 적합합니다.
상태 시스템에 대한 가장 어려운 점은 최신 문서가없는 상태에서 수행하는 작업을 이해하는 것입니다. 그들은 인식을 넘어 버그를 고치는 경향이 있습니다.
2
확실히 작은 터빈, 펌프 및 모터를 제어하는 터빈 조정기를 설계하고 제작했습니다. DSP 칩이 내장 된 임베디드 장치입니다. 그것은 정지, 시동, 주행, 과속도 시험과 같은 상태를 가지며, 다른 제어 가능성을 다루기 위해 주행 상태 내의 여러 상태가 있습니다.
필자의 경우 상태 머신 관리에 대해 가장 어려운 부분은 상태가 하위 상태를 가질 수있는 경우 특히 깨끗한 전환을 디자인하는 것이 었습니다. 터빈 거버너의 경우 이것은 속도 출력 (액추에이터)이 전환 사이에서 부드럽게 조정되어야한다는 것을 의미했습니다. 다른 도전 과제는 사용자 인터페이스 (푸시 버튼 및 7 세그먼트 LED 디스플레이)와 이들이 상태 시스템과 상호 작용하는 방법과 관련되어있었습니다. 따라서 마스터 제어 상태 머신, 관련 사용자 인터페이스 상태 머신 및 관련 통신 상태 머신이되었습니다 (터빈이 실행되는 동안 특정 값을 쓰는 것은 허용되지 않았습니다).
저는 다양한 다른 프로젝트에서 상태 머신을 사용했으며 일부는 임베디드 및 일부 표준 소프트웨어뿐만 아니라 통신에서 사용자 인터페이스 소프트웨어까지 사용했습니다.
1
나는 또한 가지고있다. 나는 더 큰 것들이 유지 보수의 악몽이되기 때문에 보통은 작은 FSM을 (몇 개 상태로) 만들지 만 때로는 FSM이 주어진 작업을위한 매우 단순하고 우아한 디자인이기도합니다.
현실적인 예로서, 특정 유형의 파일을 한 번 복구하기위한 약간의 유틸리티를 만들었습니다.
- 보여 약간 메시지, 파일 선택 (아마 취소하고 처음부터 다시 시작),
- 수리 파일 (어쩌면 취소하고 오류 메시지와 함께 종료), : 사용자 만 3 ~ 4 가능한 상호 작용 경로가 있었다
- 확인 메시지가 표시됩니다.
상태 시스템을 만들면 이러한 경로가 명백하고 쉽게 구현할 수 있습니다.