Too many global variables


출처는 아래와 같다.

http://users.ece.cmu.edu/~koopman/pubs/koopman11_escsv_handouts.pdf

43개를 어떤 근거로 뽑은 것인지는 잘 모르겠지만, Engineering적인 측면에서 관심있는 것 중에서 하나를 선택해서 글을 쓰고자 한다.

8. Too many global variables

–> 전역변수를 어떻게 관리하느냐에 따라서 소프트웨어의 구조 형태가 많이 달라질 수 있다.

  • 모든 task(혹은 function)이 storage(혹은 pool)에 접근하여 모든 resource에 접근할 수 있는 아키텍처가 있을 수 있다. 가져다 쓰기는 쉽다. 다만 이 경우 전역변수에 의한 dataflow를 면밀히 관리해야 할 필요가 있다. safety시스템에 이런 아키텍처를 사용하는 것이 바람직한지에 대해서 개인적으로는 회의적이다. safety meachnism을 구현해야 하는 관점에서 봤을 때, 구현하기가 만만치 않을 것이기 때문이다. storage의 무결성을 확보해야 하는 것이 필요하고 unintended use/define을 보장해야 하는데,  이것을 구현하는 것이 만만하진 않을 것이다. 모니터링해야 하는 포인트가 너무 많고 이에 대한 오버헤드가 장난 아닐 것이다.
  • 개인적으로 선호하는 스타일인데, component라는 function의 set을 만들고 function에서 사용하는 data들은 component내에 정의하여 component에서만 사용할 수 있도록 한다. component와 component끼리의 data전달은 외부 interface를 통해서 전달할 수 있도록 한다. 이 경우 component내에 정의된 변수가 global변수이냐 아니냐에 대해 argue가 있을 수 있다고 생각하는데, global변수라고 하기에는 reduced scope으로 정의하고 restricted access가 가능하도록 지원하고 관리할 수 있기 때문에 위의 architecture보다는 훨씬 safe하다고 생각한다. monitoring overhead도 보다 적을 것이다.

소프트웨어의 architecture 설계에서 fault tolerant할 수 있도록(or safety mechanism할 수 있도록) 구현한다면, testing관점에서도 그 비용이 feasible한지를 판단할 수 있어야 한다.

아래의 link가 도움이 될 것이다.

http://betterembsw.blogspot.kr/2014/09/fail-safe-mechanisms-must-be-tested.html

 

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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