Tag Archives: software design

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)로 구분지을 수도 있다.

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

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


Can you develop in an object-oriented way in c?(c에서 객체지향적 방법으로 개발할 수 있을까?)

Korean version is below. 한국어 버전은 아래에 있음

First of all, it is a domain that does not allow dynamic memory in the field of embedded sw.



Developing in an object-oriented way in c …

  1. Why are you going to be object-oriented? It is better than procedure – oriented because the expression system is diverse and expressive in terms of design. So I will try.

  2. Do I have to? This is not because it makes the design more intuitive and greatly improves the readability of the code.

  3. Is object-oriented imitation possible? It is possible. You can do this without using dynamic memory. There may be some limitations


Apart from the reason for object-oriented development, it is possible to create object-free objects by defining well structured function pointers in c’s structure.

By the way, if malloc is not allowed in the sense that you should not use the heap … how ??

In fact, I was worried about whether I could develop in an object-oriented way in C for 2 or 3 years ago. It’s not necessarily the case, but it was because of the vague idea that it would be nice and nice to do so.

A-SPICE also comes with the concept of a component, which can be interpreted as a set of objects (although it can be interpreted in other ways as well)

Recently, I heard that UML class diagram could be a very powerful design tool in KOSTA by listening to use case and object-oriented modeling nighttime curriculum and wanted to solve the problem even more.

In the meantime, I’ve heard about two UML tutorials, and I have been thinking about something like this because I designed it in AUTOSAR anyway with the concept of object oriented.

However, there was a considerable difficulty in applying it to the past. C is so opaque than object-oriented language …

Through last night’s education, I have come to think again about the application of the class diagram to the automobile domain, and after a reckless attempt to move the class diagram to c … Two solutions were obtained.

One thing was okay with the way of writing the heap area. Of course not in the MISRA-c perspective.

The other is a way to write a static area, which is more restrictive than the first, but it seems to be possible to implement it objectively.

Personally, I think that the approach to design and implement using UML’s class diagram is superior to the approach to design with simulink / stateflow alone.

<Simulink / Stateflow only approach criticism>

The excellence of the class diagram enhances the flexibility and maintainability of the design by elegantly grouping the data and related actions into a single object. Simulink / stateflow only, on the other hand, is reusable because it is itself a chunk of code.

People who do not know (executives or senior managers) think like this. Simply drawing with a picture will make it more intuitive, reusable and excellent … Sorry, but you’re being scammed (or mistaken) … And the in-house Simulink / Stateflow SW developers know it’s a bad idea. However, it is merely a marketing point and a fantasy of the executives, so I do not want to make it inconvenient, so I do not tell the truth.

Obviously, simulink / stateflow is a nice and great tool, but it means that a well-trained and educated elite can draw nicely, doing the wrong thing to convert messy code into simulink / stateflow, Can not be done.

</ Simulink / Stateflow only Approach criticism>

Anyway It can be a way of designing as well as a way to put data into a huge data pool and use it whenever you need it. On the SI side, I put a lot of data in the DB and implement it in a way that I draw out when I need it. I do not know about your industry, but you can create a bunch of DB tables and process all the data with a query. It’s not a design. I heard your instructor at night, and I put a bunch of data in the automotive global variable I figured out how to put it out when you need it.

I agree with the teaching of the instructor. The way in which data is put into the data pool is not clear in the R & R of the data, and because it does not usually define the data dictionary, it is common for similar duplicate data to be entered, and the maintenance is the same. I’ll go back and reuse it later, but the code will not die and live forever, harassing new developers.




우선 임베디드 sw의 분야에서의 dynamic memory를 허용하지 않는 domain임을 미리 말해둔다.

객체지향적으로 개발을 해야 할 필요가 있는지에 대한 이유를 떠나서, c의 구조체에 함수포인터를 잘 정의해서 구조적으로 잘 정의만 하면 객체 비스므리한 것을 만들어 낼 수는 있다.

그런데, heap을 쓰지 않아야 한다는 점에서 malloc이 허용되지 않는다면…어떻게 ??

사실 c에서 객체지향적인 방법으로 개발할 수 있을까에 대한 고민은 2~3년 전부터 해왔었다. 반드시 그래야 하는 것은 아니지만, 웬지 그렇게 하면 멋있을 것 같고 좋을것 같은 막연한 생각때문이었다.

A-SPICE에서도 component라는 개념이 나오는데, 사실상 그게 객체의 집합으로 해석될 수도 있고 (다른 의미로도 해석될 수 있지만..)

최근에 KOSTA에서 유즈케이스와 객체지향 모델링 야간 교육과정을 듣고 UML의 class diagram이 매우 강력한 설계 도구가 될 수 있음을 알게 되고 더욱 그 문제에 대한 해결을 하고 싶었다.

그간 UML에 대한 교육도 2개 듣고, AUTOSAR에서도 어쨌거나 object oriented개념이 들어간 방법으로 설계를 하니 뭔가 그런 트렌드를 따라가줘야 하는게 아닌가 생각도 들었다.

그런데, 막상 적용하기에는 상당한 고민이 따랐다.. c가 워낙 객체지향 언어에 비해서는 미개한지라…

지난 야간 교육을 통해서 class diagram에 대한 자동차 domain으로의 적용 가능성을 다시금 생각해보게 되었고, class diagram을 c로 옮기려는 무모한 시도를 한 끝에… 2가지 solution을 얻게 되었다.

1가지는 heap영역을 쓰는 방법으로 나름 괜찮았다. 물론 MISRA-c관점에선 안된다.

다른 한가지는 static영역을 쓰는 방법으로 첫번째보다는 제약이 좀 있기는 하지만, 나름 object스러운 방법으로 구현이 가능할 듯 싶다.

개인적인 생각이지만, UML의 class diagram을 사용해서 설계 및 구현하는 접근법이 simulink/stateflow만으로 설계하는 접근법보다는 우수하다고 생각한다.

<Simulink/Stateflow only접근법 비판>

class diagram의 우수성은 데이터 및 그와 관련된 행동을 우아하게 묶어서 하나의 객체로 표현함으로써 설계의 유연성과 유지보수성을 높여준다고 볼 수 있다. 그에 비해 simulink/stateflow only는 그 자체가 하나의 덩어리코드이기 때문에 재사용성이 떨어진다.

잘 모르는 사람들(임원들이나 고위 관리자)은 이렇게 생각한다. 단순히 그림으로 그리면 보다 직관적이고 재사용 가능하고 우수할 것이라고,… 미안하지만 당신은 사기당한거다(혹은 착각을 한것이다.)… 그리고 사내 Simulink/Stateflow SW개발자들도 그것이 잘못된 생각이라는 것을 다 알고 있다. 다만 그것이 마케팅 포인트이고 임원진들의 환상이고 하니까 불편하게 하고 싶지 않아서 진실을 말하지 않는 것일 뿐이다.

물론 simulink/stateflow가 멋지고 훌륭한 도구는 분명하지만, 잘 훈련되고 교육받은 엘리트가 멋지게 그릴 수 있다는 의미이지, 엉망진창인 코드를 simulink/stateflow로 변환하는 한참 잘못된 일을 하고 이제 코드가 좋아졌다고 생각하고 좋아해서는 안된다.


Anyway 거대한 data pool에 데이터를 엄청 집어넣고 필요할 때마다 사용하는 방식이 물론 설계의 한 방법일 수는 있다. SI쪽에서는 DB에 데이터를 잔뜩 넣고 필요할때 꺼내쓰는 방식으로 많이 구현한다고 한다. 그쪽 업계를 잘은 모르지만, DB 테이블을 잔뜩 만들고 쿼리로 모든 데이터를 처리한다고.. 그건 설계가 아니니라..라고 야간 교육때 말씀하신 강사님의 말씀을 듣고 난 automotive쪽의 전역변수에 데이터를 잔뜩 넣고 필요할때 꺼내쓰는 방식을 떠올렸다.

나도 고수 강사님의 그 가르침에 동의한다. 데이터 pool에 데이터를 집어넣는 방식은 데이터의 R&R로 명확하지 않고, 일반적으로 data dictionary를 정의하지도 않기 때문에 유사한 중복데이터가 들어가는 경우가 흔하고, 유지보수는 물건너간거와 같다. 돌아가기는 하니까 나중에 재사용하기는 하지만, 그 코드는 죽지 않고 영원히 살아서 신입 개발자를 괴롭힐 것이다.


c에서 객체지향적 방법으로 개발하기…

  1. 왜 객체지향적으로 하려고 하는가? 설계관점에서 표현방식이 다양하고 표현능력이 더 우수하기 때문에 절차지향적보다는 낫다. 그래서 하려고 하는 것이다.

  2. 꼭 그렇게 해야하는가? 그런건 아닌데, 설계를 보다 직관적으로 할 수 있고, 코드의 가독성이 비약적으로 향상되기 때문이다.

  3. 그럼 객체지향적인 흉내내기는 가능한 것인가? 가능하다. dynamic memory를 쓰지 않고도 할 수 있다. 약간의 제약은 있겠으나




real-time 소프트웨어에서 dynamic 설계의 핵심은 스케줄링이다.

실시간 소프트웨어 시스템에서 dynamic 설계의 핵심은 스케줄링이다.

안타까운 일이지만, 내가 지금껏 경험했던 고객사의 스케줄링 알고리즘은 너무 초라할 정도로 단순했다.

Rate monotonic정도는 되어야 하는게 아닌가 싶지만, 그 정도도 구현할 기술이 부족했었다.

그런 상황에서 ASIL-D로 개발한다는 것은 상상할 수도 없는 일이라고 생각한다.

Anyway 스케줄링에 대한 좋은 article이 있어서 이를 소개한다.

고객사 기술지원 및 내부직원 교육용으로 적당한 듯 싶어서 번역을 하고 있는 중이긴 한데…

원문 link를 달아놓겠다.

deadline monotonic analysis

최소한 가장 원초적인 기법에서 보다 진화된 rate monotonic의 세계로 진입할 수 있는 좋은 article이라고 생각함.

ISO26262에서 multi criticality system(한 시스템 내에 ASIL-C, ASIL-B로 개발하는 경우)을 개발한다면, 이것으로는 턱도 없지만, single criticality system을 개발하는 경우라면 RMS로도 충분할 것으로 생각한다.

RMS를 적용하는 어려움은 1) 귀찮아서, 2) RMS를 위한 전문적 기술이 없어서

좀 귀찮고 어려울 수 있지만, 이 정도는 해야 소프트웨어 개발좀 한다고 할 수 있지 않겠나(라고 생각하는데..)
물론 hard real time system에서만 필요할 수 있는 내용임..