Tips of Requirements and design using statecharts formalism(Statecharts formalism를 이용한 요구사항 및 설계 작성 tip)

korean version is below. 한국어버전은 아래로

This was introduced at the DO-178C certification consulting meeting, and I hope that this will probably be helpful to others. In DO-178C, there is no clear separation criterion for the requirements and design description steps. Also, the human brain does not think separately of requirements and design explanations. Quite capable programmers often think about the logic of the code while writing requirements. I consider the possibility of verifying the test environment, test method, test case, etc. of this requirement while reviewing the requirements.

My client decided to express the requirements as statecharts in the project for DO-178C certification. The diagram that the customer expressed has various problems in my judgment. Although it was one of the main research fields at the graduate school, it described the specification method even though it was a long time.

Statecharts is a visual formalism devised by David Harel as an extended version of the FSM (Finite state machine). Statecharts has since been incorporated into UML, and has been transformed from Simulink in Mathworks into the notation Stateflow.

(For another moment, statecharts has a non-determinism attribute, a troublesome issue in AI, so to develop a fatalistic system, Mathworks invented a deterministic version of statecharts, Stateflow.)

(Of course, the diagram you are trying to express is meant to be deterministic.)

Components of Statecharts

Statecharts = {S, s0, I, O, T}.

S = set of states
S0 = initial state
I = set of input variables
O = set of output variables
T = S x Cond1 x Cond2 x S The set of state transitions,
Where Cond1 = state transition condition, Cond2 = state transition behavior
Although the mathematical definition of transition is a bit old, it is not perfect, but let’s skip this once.

With all the elements defined above, the above Statecharts can be implemented, executable, and can generate test cases.

For example, suppose you have the following Statecharts

S = {s0, S1, s2}
I = {i1, i2}
O = {o1, o2}
T = {t1, t2}
T1: = {s0, ‘i1 = 1’, ‘o1 = 1’, s1}

T2: = {s1, ‘i2 = 0’, ‘o1 = 0, o2 = 1’, s2}

For developers, this can be done directly in code. In the past, when I participated in the model review and refactoring of projects that automatically generated auto code in stateflow (remember that time). With a few frameworks, it is possible to generate code mechanically without using expensive tools . The following code can be different from the behavior of the actual statecharts when run instead of applying the framework. I just want to understand it as a concept.

State = s0;
While (1)
Switch (State)
If (i1 == 1) {o1 = 1; State = s1; Break;}

For tester making test procedure, you can make test procedure by making the following table.

Test prefix for state reachability

S0: null
S1: null. “I1 = 1”
S2: null. “I1 = 1”. “I2 = 0”
The meaning of the above notation means that it is necessary to keep it in the initial state to reach s0. In order to reach s1, 1 is inputted to i1 in the initial state. In case of s2, i1 = 1 is inputted in the initial state And then enter 0 in i2.

I think the test procedure for the transition in each state is understandable enough without saying a word.

So, let’s take the eternal questions of DO-178C beginners.

Drawing with Statecharts, I think I draw requirements and designs together, how do I separate them?

I do not know if it needs to be separated, but if you split it off and decide that you need to write some in the Software Requirement Data (SRD) and some in the DD (Design Description), you can hierarchically represent the statecharts, Slice. It is a purely personal judgment to which level to slice, and I do not think DER will blame it for being wrong.

Note that even if you do not express requirements and designs with statecharts, you can still use vertical logical slicing to represent your requirements in a hierarchical way, even if they are expressed in natural language. Therefore, the upper level can be classified into HLR (high level requirement) and the lower level can be divided into LLR (low level requirement).

If I explained this, I think I got enough sense. I hope to use it in practice now.

What if you still do not know? You need to get consulting services, so please contact me. In the meantime, there have been a lot of examples that have impressed customers with the high-quality expression of experts, so if you have difficulty in expressing it, you may be assisted by a consultant, like me.

DO-178C 인증 컨설팅 회의때 있었던 일인데, 다른 사람들에게 도움이 될 듯 하여 소개를 해볼까 한다. DO-178C에서 요구사항과 설계 설명 단계는 칼로 무 자르듯이 명쾌한 분리기준이 존재하지 않는다. 또한 인간의 뇌는 요구사항과 설계 설명 단계를 별도로 분리하여 생각하지 않는다. 꽤 유능한 개발자들은 대부분 요구사항을 작성하면서 코드의 로직까지 생각한다. 나같은 경우는 요구사항을 검토하면서 이 요구사항의 시험 환경, 시험 방법, 시험 케이스 등의 검증 가능성을 생각하지만..

고객은 요구사항을 statecharts로 표현하기로 했다. 고객이 표현한 diagram은 내가 볼때 여러가지 문제가 있었다. 대학원 박사과정때 주 연구분야중의 하나였기 때문에 오래되긴 했지만, specification방법에 대해서 기술했다.

Statecharts는 David Harel에 의해 고안된 visual formalism으로서 FSM(Finite state machine)의 extended version이라고 볼 수 있다. Statecharts는 이후 UML에도 통합되었고, Mathworks의 Simulink에서 Stateflow라는 표기법으로 변형되기도 했다.

(잠깐 다른 이야기를 하자면, statecharts가 최근 AI에서 핫한 non-determinism 속성을 갖고 있기 때문이다. 그래서 운명론적인 시스템을 개발하기 위해 Mathworks에서는 deterministic version의 statecharts를 창안하게 된 것이고, 그래서 탄생하게 된 것이 Stateflow이다.)

(물론 고객이 표현하려는 diagram에서는 deterministic한 행동을 하도록 표현되어 있다.)

Statecharts의 구성요소

Statecharts = {S , s0, I, O, T} 로 정의된다.

  • S = 상태의 집합
  • S0 = 초기 상태
  • I = 입력 변수의 집합
  • O = 출력 변수의 집합
  • T = S x Cond1 x Cond2 x S 상태 천이의 집합,
    여기서 Cond1 = 상태 전이 조건, Cond2 = 상태 전이 행동

Transition에 대한 수학적 정의가 오래되어서 살짝 완벽하지 않은 감이 있기는 하지만, 일단 이 정도로 하고 넘어가겠음.

위에서 정의한 모든 요소를 갖추면 위 Statecharts는 구현 가능하며, executable하며, test case를 생성할 수 있다.

예를 들어 다음과 같은 Statecharts가 있다고 가정해보자

S = {s0, S1, s2}
I = {i1, i2}
O = {o1, o2}
T = {t1, t2}

t1: = {s0 , ‘i1=1’ , ‘o1=1’, s1}

t2:={s1, ‘i2=0’, ‘o1=0, o2=1’,s2}

개발자 입장에서는 이 것만 보고 코드로 바로 구현이 가능하다. 예전에 stateflow에서 자동으로 auto code를 생성하는 프로젝트의 모델 검토 및 리팩토링에 참여했을 당시 (그 때 쯤이었던 것으로 기억한다.) 약간의 framework만 있으면 비싼 툴을 사용하지 않고도 기계적으로 code 생성하는 것이 가능하다. 아래의 코드에는 그런 framework가 적용된 것이 아니라 실행시켜보면 실제 statecharts의 behavior와 다를 수 있다. 그저 concept정도로만 이해했으면 한다.

State = s0;
if (i1==1) {o1=1; State = s1; break;}

시험 절차를 만드는 tester입장에서는 다음의 table을 만들어서 test procedure를 만들 수 있다.

state reachability를 위한 test prefix

s0: null
s1: null.”i1=1″
s2: null.”i1=1″.”i2=0″

위 표기방식의 의미는 s0에 도달하기 위해서는 초기상태에서 가만히 있으면 된다는 의미고, s1에 도달하기 위해서는 초기상태에서 i1에 1을 입력하면 도달하게 되며, s2의 경우는 초기상태에서 i1=1을 입력하고 그 이후 i2에 0을 입력하면 도달한다.

각 상태에서의 transition에 대한 test procedure는 굳이 말하지 않아도 충분히 이해할 수 있을 것이라고 생각한다.

자, 그렇다면 DO-178C 초심자들의 영원한 질문사항을 받아보도록 하겠다.

Statecharts로 그리면 요구사항 및 설계를 같이 그리는 거 같은데, 어떻게 분리해야 하는가?

딱히 분리를 해야 할 필요가 있을지는 모르겠으나, 굳이 분리를 해서 일부는 SRD(Software Requirement Data)에 기술하고 일부는 DD(Design Description)에 기술해야겠다고 판단한다면, statecharts를 hierarchical하게 표현하고, 그것을 vertical하게 slice한다. 어느 level을 slice하는지는 순수하게 개인적인 판단이며, 그거 잘못했다고 DER이 비난하지는 않을 것이라고 생각한다.

참고로 굳이 statecharts로 요구사항 및 설계를 표현하지 않는다고 하더라도, natural language로 표현한다고 하더라도 철처한 logical thinking process를 적용해서 요구사항을 hierarchical하게 표현하여 마찬가지로 vertical slice를 할 수도 있다. 그래서 상위 level을 HLR(high level requirement), 하위 level을 LLR(Low level requirement)로 구분지을 수도 있다.

이정도 설명했으면 충분히 감을 잡았으리라 생각한다. 이제 실전에서 활용해보기 바란다.

아직도 잘 모르겠다면? 컨설팅 서비스를 받아야 할 필요가 있으므로, 나에게 연락하기 바람. 그동안 전문가의 고급스러운 표현으로 고객을 감동시킨 사례가 많이 있었으므로, 표현하는데 어려움이 있다면 컨설턴트의 도움을 받아도 좋음.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s