Stateflow modeling idea

1. modeling의 목표를 가져갈 것인가?

최근에 고객사에서 기술한 변속기 모델에 대한 stateflow모델을 보면서 여러 생각을 하게 되었다. State를 무엇으로 정의할 것인가? 그렇게 정의한 목적이 무엇인가? 그렇게 정의하면 어떤 좋은 점이 있는가? 그렇다면 modeling의 목적은 ….인가?

처음 그 모델링을 접했을 때 상당한 state들과 transition들로 인해 머릿속은 혼란스러웠고, 복잡한 것을 좋아하기는 하지만, 간단하게 표현하고자 싶은 욕망이 강하게 들었었다.

그런데, 그것을 읽다보니, 그림에 대한 이해가 매우 쉬웠고, 오히려 test하기에는 더 괜찮았다..

너무 직관적이었다고나 할까? 다만 광년이 hair와 같은 transition으로 인해 복잡도는 정말 굉장히 높았고, 실제로 code로 추출된 것도 그러할 것으로 추측한다.

그러다보니, 그런 style이 오히려 test case를 만드는데는 매우 효과적일 수 있다는 전혀 예상하지 못한 효과를 깨닫고 정신이 멍해졌다.

분명 시스템의 상태를 있는 그대로 직관적으로 표현하면, 시스템을 있는 그대로 이해하는데는 도움이 되기도 하고, 테스트를 하는데도 나름 직관적이다. (모든 모델링 방식이 다 그런것은 아니라고 생각한다. )

시스템의 상태를 조금만 추상화시키면 시스템에 대한 이해도는 더 높아질 수 있고, 유지보수에도 도움이 된다. 그런데 system의 state space에 대한 size가 직관적이지 않다는 단점이 있다.

(사실 내가 쓴 표현이 어렵다는 것을 나도 안다. 그래서 조금 쉽게 풀어쓰자면,,,)

시스템 A의 state는 11개로 이루어져 있고, 각각의 state에서 다른 state로의 transition이 기술되어있다.

시스템 B의 state는 3개로 이루어져 있고, 각각의 state에서 다른 state로의 transition이 기술되어 있다.

만약 A와 B를 equivalent라고 한다면(쉽게 풀어쓴다고 해놓고 더 어렵게 쓰는 것 같다. ㅋㅋㅋ) test 관점에서는 A가 더 직관적일 수 있다..

시스템 A의 단수가 -5,-4,-3,-2,-1,0,1,2,3,4,5으로 이루어졌다고 가정하자. 마이너스는 후진을 의미한다고 하자

시스템 B의 단수는 전진, 중립, 후진으로 상태를 정의할 수도 있다.

시스템 A같은 경우는 각 단수에서 변속이 되는지를 확인하는 것으로 시험을 할 수 있겠는데, 시스템 B의 경우에는 단순히 전진이 되는지, 후진이 되는지가 확인의 유일한 요소가 아니라는 것이다.

B에서도 A에서 했던 것 만큼의 테스트를 해야 한다면 보다 면밀한 테스트 설계가 필요할 수 있음을 의미한다. 이 경우 coverage에 대한 맹신도 별게 아닌게 되어버린다. (i.e, meaningless)

Simulink vs Stateflow modeling

SCADE를 배울 당시 모델링이 참 어렵다고 강사에게 얘기한 적이 있다.

사실상 combination logic같은 chip design을 schematic으로 설계하는 그런 느낌이었기 때문이다.

Modeling이 전혀 soft하지 않고 hard한..

그러니까 software design이 아니라 hardware design같은..

Simulink의 block diagram으로 software의 logic을 설계할 때도 비슷한 냄새가 난다.

function call을 하거나 if-then-else를 simulink의 block으로 표현하는 것도 참 눈물겹다고나 할까?

인생 편하게 살아도 되는데 누가 시키지도 않는데 고행길을 가는 사람처럼 그냥 안쓰럽다..

Simulink의 block modeling 표현들이 전부 그렇다는 게 아니라,

software의 logic을 쉽게 표현할 수 있는 다른 방법이 있음에도 불구하고(like stateflow) simulink로 디게 어렵게 하려 한다는 것이다. 그렇게 힘들게 하지 않았음 좋겠는데..

어쨌든, 올해 stateflow modeling에 대한 modeling improvement를 하게 되어 영광이고, 관련된 내용을 블로그에 기록할 예정.

Competitive Engineering

Tom Glib가 쓴 책이다. 어느 책에서 알게 된 분인지 기억나지는 않지만 (people ware혹은 professional software development, 아니면 로버트 글래스의 책일 것으로 생각함) 그의 네임 밸류를 믿고 산 책이다.

내용은 요구공학 및 프로젝트 관리 scope을 포함한 내용이다.

plan language라는 것을 만들어서 그 language에 대한 설명을 작성해 놓은 책으로 웬지 매뉴얼을 읽는 느낌이다.

뭔가 형식적이고, 수학적이라서 개인적으로는 상당히 마음에 든다. 아직 다 읽은 것은 아니지만, 이 책을 다 읽고 이 방법을 어디엔가 적용해보고 싶은 생각이 들었다.

그리고 이 책은 현재 내가 가고자 하는 skill tree의 path에도 맞닿아 있다(requirement analyst로서의, 혹은 specification 전문가로서의)

요구사항 분석을 정복하고자 하는 목표가 있는 형식주의자라면 읽어볼 만한 책이라고 생각한다.