Statecharts – 소프트웨어 구조 설계 작업


요즘은 Harel의 Statecharts라는 말보다는 Mathworks의 Stateflow라는 용어를 많이 쓰기는 하지만, 시조는 Statecharts이다. 대학원때 첨보고 클 놈이라고 확신을 했었고 난 그쪽에 대한 업무를 하면서 열혈 신자가 되었으며, 결국 Harel이 Statecharts를 세상에 내놓은지 30여년만에 Statecharts는 세계를 정복했다.

최근에 소스코드를 분석하여 소프트웨어의 구조를 재구성하는 과제를 진행하고 있었다. 설계 개념을 제대로 도입하지 않은터라 설계 저자의 직강을 듣지 않고는 이해하기 어려운 것들이 많았고, 전역변수의 사용으로 인해 데이터의 흐름은 이미 어지러웠으며, 심오한 코딩 기법을 몇 개 적용함으로 인해, 그 코드는 깊이를 알 수 없는 심오한 대상이 되었다.

지금까지 설계 저자와 3차 미팅을 했다. Statecharts 신봉자인 나는 Staetcharts의 교리를 전파하고 열심히 포교활동을 한 끝에 그들을 Statecharts 교도가 되도록 하고 그런 사상으로 시스템을 바라보도록 하는데 성공했다.

2시간 정도의 짧은 순간이었지만, 지금까지 이해한 시스템을 바탕으로 하이브리드 시스템의 뼈대를 세우는 작업을 실시했다. 두 명의 도메인 전문가와 한명의 독실한Statecharts 교도가 합작하여 드디어 과거와는 다른 이상적이고 깔끔하고 심지어 아름답기까지 한 하이브리드 시스템을 설계했다.

이상하게 Arts에 대해서는 문외한이지만, Statecharts의 그림은 아름답게 보이고 예술적으로 보이는 것은 나만 그런 것은 아닐 것이라 생각한다. 모두들 나의 그림 실력에 만족감을 보이고, 그 그림을 보니 모든 하이브리드 시스템의 체계가 정리되었다고 뿌듯해했다.

아침에 갑자기 이 일이 생각났다. 도대체 내가 한 이 그림 그리기는 소프트웨어 개발의 어떤 단계에 해당하느냐고… 곰곰히 생각해보니 요구사항 분석 및 설계 활동이다. 일반적인 ISO26262나 DO-178C/278A, IEC 6508에서 흔히 이야기 하는 development life cycle하고는 차이가 있긴 하다. 하지만 조금 넓게 시야를 가지면 그게 그거긴 한데, 좁은 시야에서는 완전 다르다고 볼 수도 있다.

어쨌거나 what을 알고 있는 domain expert입장에서 how를 정리하는 것은 어려운 수수께끼를 드디어 해결한 것과 같은 쾌감을 선사했고, what을 모르지만 how로 단번에 문제의 본질을 정리한 것은 statecharts 교도 입장에서 역시 statecharts에 대한 믿음을 더욱 강화하게 한 계기가 되었다.

Statecharts로 시스템을 모델링하는 것은 그런 의미에서 What과 How가 mix된 형태의 표현 방식이라고 생각된다. 그 그림에는 문제의 본질과 그 문제를 해결하기 위한 방법이 둘 다 들어가 있다. 그 그림을 보면 어떻게 문제를 표현했는지가 기술되어 있고 그 그림은 아름답기 까지 하다. (모든 게 아름답진 않겠으나)

예술작품을 공개하고 싶은 마음이 굴뚝같으나, 비 공개할 수밖에 없는 것이 안타깝긴 하다. 역시 난 그림 그리는 일에 소질이 있는 것 같다.

 

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중