BLOG main image
분류 전체보기 (643)
소프트웨어 개발 (273)
크리스찬 (32)
일반 (299)
자녀교육 (15)
문서, 팁 (3)
나의책읽기 (18)
171,224 Visitors up to today!
Today 3 hit, Yesterday 215 hit
daisy rss
2017.10.03 18:09

모멘텀투자를 하려면 대형 우량주를 강한 시세에서 사야 하고, 가치투자의 경우에는 소외된 중소형 종목을 약한 시세에서 사야 한다. 그런데 많은 투자자들은 그것을 거꾸로 하고 있다. 


거시지표들을 해석하는 것은 시장에 접근할 때 가장 먼저 해야 하는 중요한 절차다. 

우리나라에서 흔히 접할 수 있는 거시지표 중에서 투자에 원용할 수 있는 지표는 소비지표다. 소비지표는 경기를 예측할 수 있는 가장 빠르고 정확한 지표라는 사실을 잊어서는 안 된다. 

소비자평가지수가 놀랍게도 주가지수와 거의 동행하며 소비자기대지수는 그에 약간 후행한다는 사실을 알 수 있다. 소비자평가지수와 소비자기대지수를 합해 소비자동향지수라고 부른다. 소비자동향지수가 100이라고 하는 것은 긍정적으로 보는 가구와 부정적으로 보는 가구가 같다는 뜻이며, 100 이하는 다수가 부정적으로 100 이상은 다수가 긍정적으로 보기 시작했다는 의미가 된다. 

소비자 기대지수는 현재와 비교하여 6개월 후의 경기, 생활 형편, 소비 지출에 대한 소비자들의 기대를 나타내는 지표이므로 소비자들이 예측하는 미래경기라는 의미가 강하다. 소비자평가지수는 6개월 전과 비교하여 현재의 경기, 생활 형편에 대한 소비자들의 평가를 나타내므로 과거에 비해 지금 상대적으로 어떻게 느끼는가 하는 현재의 경기상황에 주안점을 두고 있다. 

경기종합지수는 국민경제 전체의 경기동향을 쉽게 파악하기 위하여 경제 부분별로 경기에 민감하게 반영하는 주요 경제지표들을 선정한 후 이 지표들의 전월 대비 증감률을 합성하여 작성한 지수다. 이것은 특히 개별 구성지표들의 증감률 크기에 의해 경기 변동의 진폭까지도 알 수 있음으로 경기 변동의 방향, 국면 및 전환점은 물론 속도까지도 동시에 분석할 수 있다. 

경기종합지수에는 선행, 동향, 후행 종합지수가 있다. 주식시장은 늘 경기에 선행하기 때문에 주식투자자들이 기어코 얻어야 하는 정보는 선행지표 단 하나뿐이다. 

경기 상황을 제대로 반영하기 위해서는 소비자기대지수를 민감한 지표로, 경기선행지수를 잡음을 제거한 합리적인 지표로 활용하는 게 좋다. 

우리가 투자자로서 인플레이션을 판단할 때는 소비자물가지수 보다 선행적인 생산자물가지수의 변동을 유심히 관찰해야 한다. 또한 생산자물가지수는 실제 주식시장이 감내할 수 있는 인플레이션 수준을 미리 짐작하게 해주므로 이를 더욱 염부에 두고 살펴보는 것이 좋다. 

우리가 할 수 있는 최선의 방법은 주식시장이 하락 조정 기조를 보일 때 소비심리가 튼튼하면 주식 시장은 단지 가격 조정일 뿐이라고 판단하고, 주식시장의 조정이 소비심리의 하락과 맞물리면 이것은 단순한 조정이 아니라 침체의 전조라고 판단하는 상대 비교를 하는 것 뿐이다. 


저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2017.10.03 08:56

지식 구조화는 전체상을 표현하고 포함된 지식들을 관련지어 정보기술을 이해하기 쉽고 쓰기 편하게 하는 것이다. 전체상이란 목적에 필요한 지식의 전체구조다. 

책 제목과 목차는 책의 목적과 지식구조를 표현한다. 제목은 목적 표현이고 목차에 나오는 대제목은 책 내용을 개괄적으로 표현한 것이다. 

부감은 실체로 보는 부감과 모델로 보는 부감으로 나누어 볼 수 있다. 모델은 어느 시점에서 본 실체를 재현한 것이다. 모델로 보는 부감은 실체를 추가, 삭제, 변경, 확대, 축소해서 특정 목적과 시점에 집중하도록 하는 장점이 있다. 

부분상을 다루는 방법에 따라 부감되는 전체상이 바뀐다. 예를 들어 어떤 부분상을 확대하고 축소하느냐에 따라 전체 인상이 바뀌며, 부분상 간의 연산도 가중치에 의존한다. 부분상 집합은 부분상을 모으는 방법에 따라 달라진다. 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2017.09.06 08:47

이 책의 1판은 '실시간 임베디드 퀀텀 프로그래밍'이라는 책으로 국내에서도 번역되어 출판되었다. 이 책을 읽는 것은 놀라움의 연속이고 짜릿함이었다.  

1판이 나오고 5년 정도의 시간 후에 2판이 쓰여졌다. 저자는 그 동안 많은 경험을 했다. 2판을 통해 저자가 얻은 새로운 통찰력을 전수받아 보자. 

내용 정리는 1판의 정리내용을 2판의 내용에 맞추어 재정리하는 방식을 사용한다. 필자의 언어로 내용을 재정리하거나 필자의 생각은 보라색과 녹색으로 구분한다. 녹색이 보라색보다는 더 중요하다. 정리 내용도 그 중요도에 따라 파란색과 빨간색을 사용한다. 

다음 사이트를 방문해 보자. www.quantum-leaps.com/psicc2


역자 서문
일상생활에서 어떤 제품의 원리를 아는 사람이 그것을 더 잘 활용한다는 사실을 의심할 수는 없다. UML을 더 잘 활용하기 위해서 UML Specification을 보아야 하는 이유
이 책을 읽어나가면서, 지금까지 보지 못한 또 다른 가능성을 발견할 것이다. 역자가 그랬듯이 평소에 무시하고 지나쳤던 작은 음식점에서 최고의 음식을 찾은 것과 같은 기분을 느끼리라 생각한다.

서문
20년쯤 전, David Harel은 복잡한 반응형(이벤트 구동형) 시스템을 기술하는 강력한 방식으로써 상태차트를 개발했다. 동시에 상태차트는 뛰어난 형식으로써 프로그래머들로부터 거의 절대적인 지지를 얻었으며, 많은 소프트웨어 방법론의 컴포넌트로 채택되었다. 특히 이 중에서 가장 주목할 만한 것은 UML이다.

많은 개발자에 있어 툴은 제 몫을 해내지 못할뿐 아니라 복잡한 소프트웨어나 드로잉 툴이 될 뿐이다. 이런 소프트웨어가 되지 않도록

이 책의 목표
복잡한 설계 자동화 툴에 대한 대안으로 간단하고 가벼운 상태차트 구현을 소개함으로 C C++에 익숙한 사람이라면 며칠 내로 상태차트의 구현을 시도할 수 있게끔 하는 것이다.

이 책을 정리하는 목표
- UML
상태머신을 설명하는데 도움을 받을 내용을 정리
-
이 책에서 제시된 상태머신에 대한 구현 방법은 내가 알고 있는 한 가장 좋은 방법. 현재 개발중인 모델링 툴에 적용하려 함. 모델링 도구에서 UML 다이어그램 작성 기능과 모델 실행 및 검증 기능 구현에 상태머신을 사용. 개발언어가 C#임으로 이 책에서 제시한 내용에 따라 C#으로 상태머신 구현
-
정리와 개발된 내용을 공개함으로 상태머신의 대한 지식과 구현기술에 대한 보편화에 공헌
-
모델링과 모델 실행과 검증의 중요성을 알림
-
개발된 모델링 도구를 소개하고, 자동화 도구의 중요성을 알림

왜 퀀텀 프로그래밍(Quantum Programming; QP)인가?
저자는 양자역학과 반응형 소프트웨어 시스템의 유사성을 발견하고 중요한 메타포로 양자를 사용하고 있다. 1판 독자들은 이에 대해 부정적 반응을 했나 보다. 1판 독자들의 피드백을 받아 2판에서는 양자역학 메타포를 모두 제거했다고 한다.

QP를 사용하기 시작하면서 더 이상 복잡한 if문이나 switch문과 씨름할 필요가 없으며, 어떻게 상태패턴을 적용할 것이고 어떻게 문제를 능동객체로 분할할 것인지를 생각하는데 시간을 더 할애할 것이다.

독자를 위한 지침

1부에서는 상태머신을 설명
2
부에서는 퀀텀프레임워크를 설명, 퀀텀프레임워크는 임베디드 리얼타임 시스템을 대상으로 설계된 소프트웨어 아키텍처이다.
새로운 기법을 배우는데 있어 실제로 예제 코드를 실행해보는 것보다 자신감을 주는 것은 없다고 믿는다.

상태머신은 GUI와 임베디드 시스템과 같은 반응형 시스템들을 모델링하는 가장 우수한 방법임에는 틀림없다. 하지만 상태머신을 모델링하는 절차나 구현방법이 잘 알려지지 않은 상황에서 상태머신은 그림의 떡이 될 수 밖에 없다.
필자가 단연코 현재 시점에서 이 책에서 제시하는 방법보다 상태머신을 더 빠르고 쉽게 구현으로 적용하는 방법을 제시하는 것은 없을 것이다. 고가의 자동화 도구는 상태머신의 구현을 이해하는 것이 아니라 도구를 사용할 뿐이라는 점에서 논외로 한다.

This book discusses event-driven programming problems, why they are problems, and how state machines and active object computing model can help.


1. 간략히 살펴보는 퀀텀 프로그래밍 중에서

반응형 시스템(reactive system)이란 이벤트를 교환하면서 자신을 둘러싼 환경과 끊임없이 상호작용하는 시스템이다. 이벤트에 의해 작동이 구동된다고 해서 이벤트 구동(event driven)방식이라고 한다. 대표적인 것이 그래픽 사용자 인터페이스(Graphic User Interface; GUI)와 리얼타임 시스템들이다.

David Harel은 복잡한 반응형 시스템을 표현하는 강력한 방법인 상태차트(statechart)를 고안했다. 기존의 유한상태머신에 비해 상태차트가 이뤄낸 혁신은 계층형 상태(hierarchical state)의 도입이었다.
Harel
은 상태차트에 도입한 상태계층의 타당성을 다음과 같이 설명했다.
밝혀진대로, 아주 복잡한 비헤비어는 단일계층의(flat) 간단한 상태전이 다이어그램으로 쉽게 표현될 수 없다. 그 이유는 관리가 불가능할 정도로 상태가 많기 때문이다. 너무 상태의 수가 많기 때문에 결국 다이어그램은 체계가 없고 무질서해진다.
계층형상태 프로그래밍 또한 차이점을 이용한 프로그래밍(programming by difference)의 한 예이다. 하위 상태에서의 행위 구현은 상위 상태에서의 행위 구현과의 다른점만을 코딩하면 된다.
계층형 상태 도입의 타당성에 대한 Harel의 설명은 눈에 보이는 면에 국한된 설명이다. 계층형 상태는 모든 실체들이 전체와 부분의 계층과 일반화와 구체화의 계층을 형성하기 때문에 발생하는 자연적인 것이다.

상태차트가 반응형 시스템을 설계하고 구현하는데 강력한 방법임에도 불구하고 실제 현장에서 많이 사용되지 않는 이유는 무엇인가? 상태차트가 설계의 한 형식임을 모른다.
위의 이유도 있겠지만 사실 상태차트로 반응형 시스템을 설계/구현하는 정확한 방법이 잘 알려져 있지 않아서이다(실제 있는지 조차도 의심스럽다). 이 책에서 제시한 구현방법은 훌륭하다. 그러나 아직 이벤트, 상태, 전이, 액션등의 식별의 문제가 남아 있다. 식별의 문제는 어디에서나 그렇듯 가장 어려운 문제이다. 항상 그렇지만 남아있는 것은 가장 어려운 문제다.
1.2.2
계산기 상태차트 또한 문제가 있다. 어떤 문제가 있는지는 계산기 상태차트를 구체적으로 거론하는 장에서 다시 정리하겠다.
객체지향과의 유사성에 대한 부분은 상태차트의 설명과 관계가 되므로 2장에서 함께 정리한다.
[Objects, Components, And Frameworks with UML] 3장은 상태행위를 이해하는 데 많은 도움을 준다. 기회가 되면 이 내용을 정리해서 이해를 돕도록 하겠다.


2
. 상태 차트
반응형 시스템의 코드를 보면 중첩된 if-else문이나 switch-case문들이 많이 보인다.
왜 그럴까? 반응형 시스템은 입력뿐 아니라 시스템의 과거 상태도 고려해서 입력에 응답하기 때문이다.
중첩된 조건분기가 많으면 어떤 문제가 생기는가?
어떻게 중첩된 조건 분기문을 제거할 것인가? 상태머신으로

2.1
유한 상태머신의 핵심
상태행위(state behavior)? 시스템이 각 시점에서 다르게 동작하고, 시스템의 행위를 상태라는 유한의 중복되지 않은 부분으로 나눌 수 있을 때 시스템은 상태행위를 보인다라고 한다.
상태행위를 모델링하는 방법? 유한상태머신(Finite State Machine; FSM)을 이용
FSM
은 시스템 전체 행위의 제약조건을 정의하는데 효과적이다.
모든 시스템이나 그 시스템 컴포넌트가 상태행위를 보이는 것은 아니다.
반응형이 아닌 시스템에서는 주로 상태행위가 아닌 행위를 보인다. 예를 들어 Sin(x)는 시스템이 이전에 어떤 행위를 수행했는지에 상관 없이 항상 입력에 대한 결과를 돌려준다.
연속적인 행위는 입력이력에 의존하지만, 유한개의 상태로 나누기는 힘들다. 이 범주에 드는 시스템 컴포넌트로는 디지털필터가 있다.
시스템이 어떤 상태에 있다는 것은? 시스템이 허용된 입력 중 몇 가지에만 응답하고 가능한 응답 중 몇가지만 만들어내며 특정 상태로만 직접 전이 할 수 있다는 것을 의미한다.

반응형 시스템이 아닌 경우 일반적으로 사용자는 시스템이 수행해야 하는 행위를 직접적으로 구체적으로 요청한다. 반응형 시스템에서는 실제 사용자가 시스템이 어떤 행위를 수행할지를 모르기 때문에(시스템 상태에 따라 다르다) 요청 행위는 일반화 될 수 밖에 없다. 물론 반응형 시스템들은 시스템의 현재 상태를 사용자에게 알려주기 때문에 사용자는 자신의 일반화 된 요청과 시스템이 제공하는 상태를 통해 자신의 구체적인 요청을 알 수는 있다.
반응형 시스템은 외부 입력과 특정 조건에 있을 때 가능한 행위를 수행한다. 시스템이 행위수행을 하고 나면 행위 수행 이력이 바뀌었기 때문에 시스템 상태가 바뀔 수 있다.
반응형이 아닌 시스템에도 상태행위가 존재한다. 그러나 반응형 시스템과는 달리 시스템이 전적으로 상태행위로 모델링 될 수 있는 것이 아니라, 일반행위와 상태행위가 모두 모델링 되어야 한다.

2.1.1 상태
상태란? 시스템이 작동하는 동안의 상황이나 조건
이러한 상황이나 조건은 불변 값을 갖고(대개 암시적으로) 있거나 어떤 시스템 작업을 수행하기도 하며 특정 외부 이벤트를 기다리기도 한다.
행위 수행 없이 외부 이벤트를 기다리는 상태를 Idle, 행위를 수행하고 있는 상태를 Busy라 한다. 완료상태와 진행상태

상태는 시스템 이력에 관련된 사항을 매우 효과적으로 표현: 키보드에서 Caps lock 키를 눌린 상태에서 글자 키를 누르면 대문자로 작성
시스템이 이전 수행이력에 따라 반응하기 때문에 사용자가 현재 시스템 상태를 알아야 어떤 일이 일어날 지 예측할 수 있다. 왜 키보드에서 Caps lock키를 누르면, 그 키가 눌렸는지를 알리기 위해 점멸등이 켜지는지를 생각해 보자.
Caps lock키가 활성화되었는지에 영향을 받지만 이전에 어떤 문자가 눌렸는지에 대해서는 영향을 받지 않는다. 이 처럼 상태는 모든 이벤트 중 필요 없는 것을 걸려내도록 돕는다.

상태라는 개념은 시스템 이력의 매우 유용한 추상화이며, 관련된 외부자극만을 반영하고 관련되지 않은 것은 모두 무시한다.

2.1.2
확장 상태
상태는 변화에 대한 것으로 객체의 변화는 특성 값으로 표현된다.
그러나 모든 특성 값의 변화가 상태머신과 관련되는 것은 아니다.
상태머신은 상태와 관련되기 보다는 상태행위에 관련되어 있기 때문이다. 행위에 영향을 주지 않는 상태는 의미가 없다.
) 커피자판기에서 커피를 뽑기 위한 행위와 물 온도와의 관계, 성인이 되면 할 수 있는 행위와 사람 나이와의 관계

변수가 변한다고 해서 반드시 시스템 행위의 질적인 면이 바뀌는 것은 아니다.
확장상태머신(메모리가 있는 상태머신)에서 상태는 시스템 비헤비어의 질적인 면에 해당하고, 확장상태변수(프로그램 메모리)는 양적인 면에 해당한다.

2.1.3
가드(Guard);
전이 조건
가드는 상태전이 같은 어떤 작업을 허용하거나 금지하는 방식을 통해 상태머신의 행위에 영향을 미친다. 가드라는 것은 조건 분기에 해당하므로 조건분기를 없애려는 상태머신의 취지와 충돌한다. 상태머신기반 설계에서 가드 남용은 구조적 붕고를 유발 할 수 있다. 상태머신에 생소한 프로그래머들은 관련 행위를 시스템의 질적인면(상태)로 분하기 보다 확장상태변수와 가드를 별도로 집어 넣고 싶다는 유혹을 받을 것이다. 실용적 상태머신의 구현에 있어 가장 중요한 조건이라면 아마도 상태 추가/제거의 용이함일 것이다. 상태 추가/제거가 용이하지 않다면 구조적 붕괴의 가능성에 대해 의심해볼 필요가 있다.

2.1.4
이벤트(Event);
사건
흔히 이벤트란 시스템에 있어 중요한 사건이 어떤 시간과 공간에서 발생한다는 것을 뜻한다.
이벤트가 발생했을 때 어떤 사건이 발생했다는 사실뿐 아니라 이 사건에 관한 양적정보의 전달도 중요하다. 양적정보는 이벤트의 매개변수로 전달된다.
) 키 눌린 사건 - 어떤 키가 눌렸는가에 대한 정보 요구

이벤트가 발생하고 나면 이벤트는 다음과 같이 처리된다.
이벤트 대기열(queue)에 위치 -> 상태머신에 보내짐(current event로 다루어짐) -> 상태머신이 처리한 후 소멸

2.1.5
액션과 전이
이벤트 인스턴스가 넘어오면 상태머신은 액션을 수행함으로 응답한다.
액션을 상태머신이 수행하는 것이라고 말할 수 있는 것인가? 시스템이 수행하는 것 아닌가?
이 액션은 변수 값 수, I/O수행, 함수호출, 다른 이벤트 발생, 다른 상태로의 전이 등이다.
한 상태에서 다른 상태로 넘어가는 것을 상태전이라고 한다.
전이를 일으킨 이벤트를 트리거라 한다.
전이에 가드가 있을 수 있는데, 가드가 있는 전이는 가드 조건이 참일 때 전이가 된다.
동일 사건과 상태에서 전이 될 수 있는 대상 상태를 여럿 가질 수 있다. 이런 경우 가드를 사용하는데, 이때 특정 전이의 가드에 대한 평가나 평가 순서가 다른 전이에 영향을 미쳐서는 안된다.

2.1.6
기존 FSM에서의 두 가지 해석법
Mealy 오토마타: 상태 전이시에 액션 수행, 즉 상태다이어그램의 전이에 액션을 표현할 수 있다.
Moore
오토마타: 상태에 액션을 연결
이 책에서는 Mealy 오토마타와 Moore 오토마다의 장단점에 대해서 설명하고 있지만 사실 Moore 오토마타는 Mealy의 단점을 보완하기 위해 나온 것이다.
UML
에서는 이 두 가지 표현법을 모두 가능하게 하고 있지만, 이 배경을 안다면 상태다이어그램을 작성할 때는 Moore 오토마타와 같이 액션을 상태와 연결하도록 강제하도록 할 것이다. 이를 위해 상태에 추가된 것이 entry, exit 액션이다.

2.1.7 실행모델 - RTC 단계
이벤트는 선점형과 비선점형 처리가 있다. 선점형은 우선 순위가 높은 이벤트가 발생할 경우 즉시 낮은 우선순위의 이벤트 처리를 일시정지하고 새 이벤트 처리를 시작한다. 비 선점형은 먼저 발생한 이벤트 처리가 끝나고 나야 다른 이벤트가 처리된다. 비 선점형 처리를 RTC(Run To Completion)이라 한다.
선점형 방식은 적절히 처리하는 것이 어렵고 아주 복잡해서 비실용적이다.
선점형 요건은 RTC에 추가적인 작업으로 충족할 수 있기 때문에 RTC를 사용하는 것이 더 낫다.

2.18
상태전이다이어그램(State Transition Diagram);
상태 다이어그램, 상태머신 다이어그램
상태전이다이어그램이란? 상태머신을 그래픽적으로 표현하는 특별한 형식
자세한 작성법은 생각하며배우는 UML2.0참조

2.1.8 상태전이 다이어그램
UML2.0에서는 상태머신 다이어그램이라고 한다. 상태머신 다이어그램 작성 방법은 '생각하며배우는 UML2.0' 11장을 참조해라.
상태머신 다이어그램은 상태머신을 그림으로 표현한 것(시각적으로 나타낸 것, 도식화 한 것)이다.
초기전이는 색칠한 원(초기상태;initial state)에서 시작하며, 초기전이의 대상이 되는 상태는 시스템이 처음 시작할 때의 시작상태를 나타낸다.
모든 상태 다이어그램에는
한 개의 초기 전이가 있어야 하며, 초기전이는 이벤트가 촉발한 것이 아니기 때문에 레이블이 달려있지 않다. 그러나 초기 전이는 확장상태변수 설정이나 하드웨어 초기화와 같은 작업을 할 수 있다.

2.2 UML
상태차트의 기초
UML 상태차트는 Mealy 오토마타와 Moore 오토마타의 특징 모두를 가지고 있는 확장상태머신이다.
이미 앞에서 언급했듯이 Moore 오토마타가 발전된 형태이고, UML 상태머신 다이어그램을 작성할 때는 이 점을 생각하고, 작성 방법을 어느 정도 제약할 필요가 있다.

2.1.1 계층형 상태
UML 상태머신은 상태의 중첩을 허용하는 계층형 상태머신이다.
중첩된 상태들 사이에 일반화(generalization) 관계와 compostion 관계가 있을 수 있다.
일반화 관계는 2.1.1 - 2.1.2에서 설명하고 있고, composition 관계는 2.1.3에서 설명하고 있다.
일반화 관계는 객체지향 프로그래밍 언어에서는 상속(inheritance)으로 생각할 수 있는데, 상태의 일반화 관계도 마찬가지이다.
중첩 상태를 가능하게 하면서 단순상태만을 사용할 때에 비해 이를 지원하는 개념들이 추가되어야 한다.

다른 상태를 포함하지 않는 상태 - 단순상태(simple state)
다른 상태를 포함하는 상태 - 복합상태(composite state)
상위상태의 바로 아래 계층으로 포함되는 상태 - 직접하위상태(direct substate)
상위상태의 계층으로 포함되기는 하지만 바로 아래 계층에는 포함되지 않는 상태 - 추이적중첩하위상태(transitively nested substate)
최상위 루트 상태 - 최상위상태(top state)
상태형상(state configuration) - 2.2.5에서 설명
깊은이력의사상태(deep-history pseudostate;
깊은이력)

추상화 자체로는 전체 시스템의 복잡함을 줄일 수는 없지만, 어떤 시점에서 처리해야 할 세부사항의 양을 줄여주기 때문에 가치가 있다.
우리가 한번에 이해할 수 있는 것은 여전히 얼마 되지 않는다. 하지만 추상화를 통해 우리는 정보를 놀라울 정도로 명확한 의미로 활용한다. - Grady Booch
아무리 추상화가 가치 있는 것이라도 복합상태 안에 복잡한 것들을 감춰놓은 것 만으로 복잡함이 해결되는 것은 아니다. 복합상태는 복잡함을 감출 뿐 아니라, 행위 재사용을 통해 복잡함을 줄일 수 있다.

2.2.2
비헤비어 상속(Behavioral Inheritance;
행위 상속)

2.2.3
직교영역(Orthogonal Region)
직교영역은 실행의 독립성(병행성의 일종)을 의미하지만, UML 명세는 각 직교영역마다 실행 스레드를 따로 두도록 요구하고 있지는 않다(물론 이런 식으로 구현하는 것은 가능하다). 오히려 직교영역은 같은 스레드에서 수행되는 경우가 많다. UML 명세는 직교영역에 이벤트 인스턴스를 전달할 때 특정 순서에 의존하지 말 것만을 주장하고 있다.

2.2.4
진입액션과 탈출액션
객체지향프로그래밍의 생성자와 소멸자라고 생각할 수 있다.
진입액션과 탈출액션이 클래스 생성자와 소멸자와 매우 비슷하긴 하지만, 중요한 차이점도 있다.
클래스 인스턴스(객체)의 고유성을 수정하려면, 수정하기 전후의 객체가 밀접한 관계에 있더라도(같은 조상을 갖더라도) 일단 완전히 소멸시킨 뒤 다시 생성해야한다. 예를 들어 데이터베이스 애플리케이션에서 Bird 클래스의 인스턴스를 Fish 클래스의 인스턴스로 바꿀 경우를 생각해보자. 두 클래스가 공통조상클래스 Animal을 같이 상속하고 있음에도 bird 객체를 완전히 소멸시킨 뒤 fish객체를 처음부터 다시 생성해야 한다.

상태차트에서는 이러한 고유성의 변화가 상태전이에 해당한다. 그러나 객체와는 달리 이 변화는 완전한 소멸과 재생성을 요하지는 않는다. 예를 들어 heating 상태에 중첩돼 있는 toasting에서 baking으로 상태를 전이하려면 그냥 toasting의 탈출액션을 수행한 뒤 baking의 진입액션을 수행하게 되고, heating의 탈출액션이나 진입액션을 수행할 필요는 없다. 이런 전이를 거쳐도 절대 heating상태를 벗어나지 않기 때문이다.
이는 속성과 행위의 차이를 생각하면 당연한 것이 된다. 속성은 객체마다 그 값을 설정하지만 행위는 공통적으로 사용한다.

2.2.5 전이 실행 시퀀스
상태중첩이 가능할 경우 '현재 상태'는 좀 복잡해 진다.
일반화 관계에 해당하는 복합상태의 경우 하위상태가 활성화 되었다는 것은 상위상태 또한 활성화되었다는 것을 의미하고, composition에 해당하는 직교영역의 경우, 여러 하위상태가 동시에 활성화될 수 있다.
현재 활성상태는 실제로 루트에 있는 하나의 최상위 상태부터 최하위에 있는 간단한 상태 여럿으로 이뤄진 트리로 표현될 수 있다. UML에서는 이런 상태트리를 상태형상(state configuration)이라고 한다.
상태중첩은 진입액션과 탈출액션 또한 복잡하게 한다.

단순상태들 사이의 전이에서 진입액션과 탈출액션은 다음과 같이 일어난다.
1
단계: 전이의 소스 상태의 탈출액션(소스 소멸)
2
단계: 전이와 연결된 액션(Moore 오토마타 개념을 사용할 경우 불필요)
3
단계: 전이의 타겟 상태의 진입액션(타겟 생성)

복합상태들 사이의 전이에서 진입액션과 탈출액션은 다음과 같이 일어난다.
1
단계: 전이의 소스 상태형상의 탈출액션(계층적으로 형성된 소스 상태들 소멸)
2
단계: 전이와 연결된 액션(Moore 오토마타 개념을 사용할 경우 불필요)
3
단계: 전이의 타겟 상태형상의 진입액션(계층적으로 형성된 타겟 상태들 생성)

2.2.4에서 설명했듯이 같은 상위상태를 갖는 하위상태의 경우, 진입액션과 탈출액션시 상위상태의 진입액션과 탈출액션은 수행하지 않는다. 중첩상태가 복잡할 경우는 상위상태에 더해 최소공통조상(least common ancestor; LCA)라는 개념이 있어야 한다.

상태차트에서 상태전이는 어떠한 상태라도 서로 연결할 수 있다. 다른 중첩수준에 있는 복합상태도 예외는 아니다. 문제는 1단계에서 어떤 상태를 빠져나와야 하는지 알아내는 것이다. UML명세에서 언급한 바에 따르면 1단계에서 현재 활성상태에 중첩된 모든 상태(소스상태의 직접 하위 상태이거나 추이적 하위상태)를 빠져나와야 하지만, 소스상태와 타겟상태의 최소공통조상(least common ancestor; LCA)에서 빠져나와서는 안 된다. 이름에서 알 수 있듯이 LCA는 소스상태와 타겟상태 모두의 상위상태(조상), 가장 낮은 수준의 복합상태다. 앞서 설명했듯이 탈출액션의 실행순서는 항상 가장 낮은 수준의 중첩상태부터 LCA까지다(LCA는 빠져나가지 않는다). 2단계에서 전이와 연결된 액션이 실행된 뒤, 마지막 3단계에서는 타겟상태에 들어가야 한다. 진입액션의 실행은 탈출액션이 끝난 LCA부터 시작해 타겟상태까지 계층을 따라 내려간다. 타겟상태가 복합상태일 경우에는 다시 기본전이나 이력 메커니즘을 통해 그 하위머신에 들어간다.

2.2.6
내부전이
Moore 오토마타에서는 진입액션과 탈출액션이 있기 때문에 자기전이(self-transition)와 내부전이를 구분해주어야 한다.
자기전이와 내부전이는 모두 상태변화를 유발하지는 않는다.
자기전이는 자기 상태를 빠져나갔다가 다시 자기 상태로 들어오는 것이다. 이것의 의미는 단순하게 보면 진입액션과 전이액션과 탈출액션을 수행하고 싶다는 것이 된다. Moore 오토마타 개념에서 보면 진입액션과 전이액션을 수행하고 싶다는 것이 된다.
내부전이는 상태를 빠져나가지 않고, 단순히 액션만을 수행하는 것이다. 진입액션이나 탈출액션을 수행하지 않는다.

2.2.7 의사상태
상태차트는 도식적인 형태로 시작했기 때문에, 다이어그램에서 일반적인 상태 말고도 몇몇 노드를 이용하면 다양한 기능을 구현하거나 축약해서 표기하는데 효과적이라는 사실이 입증됐다. 이런 다양한 노드를 통틀어 의사상태(pseudostate)라 한다. 더 정확히 얘기하면 의사상태란 시스템이 일시적으로 머무르게 되는 상태머신 그래프의여러 노드를 아우르는 추상적 개념이다.

연결의사상태(junction pseudostate; 교차점)는 여러 전이를 연결하는 자유로운 용법을 갖고 있는 점이다. 연결 의사상태는 마치 맥가이버 칼 같아서 다양한 기능을 수행한다. 연결 의사상태는 같은 동시처리 영역에서 들어오는 여러 전이를 병합할 수도 있고, 들어오는 전이를 서로 다른 가드의 나가는 전이로 쪼갤 수도 있다. 후자의 경우는 정적인 조건분기다. 연결 의사상태를 사용한다는 것은, 전이가 발생하기 전에 모든 가드를 정적평가한다는 것을 의미한다.

선택의사상태(choice pseudostate; 선택점)는 동적인 조건분기에 쓰인다. 선택의사상태를 사용하면 전이를 여러 경로로 쪼갤 수 있으므로, 같은 RTC 단계에서 수행된 이전 액션의 결과에 따라 어떤 경로를 따를 것인지 결정할 수 있다.

2.2.8
정교한 이벤트 처리
TimeEvent는 지정한 제한시간의 만료를 모델링
ChangeEvent
는 명시적 불린식이 참일 때 발생, 키워드 when사용

2.2.9
의미와 표기법
상태차트의 많은 요소와 의미가 도식적 표기법에 심각하게 치우쳐있다. 예를 들어 상태다이어그램은 가드의 평가순서, 직교영역으로의 이벤트 전달 순서와 같은 처리순서를 제대로 나타내지 못한다. UML 명세에서는 어떤 특정 순서에 의지하지 않아야 하는 짐을 설계자에게 모두 맡겨서 이 문제를 피하고 있다. 그러나 상태차트를 C C++로 구현할 때 여러분은 실행순서를 마음대로 제어할 수 있으므로, 상태차트에서 내포돼 있는 이 제한사항을 보장할 수는 없다. 또한 상태차트 다이어그램은 제어흐름을 도식적으로 표현하는데 있어 많은 연결장치를 필요로 할 것이다. 이들 요소는 생김새만 달랐지 기존 플로우차트나 마찬가지다. 옛날 구조형 프로그래밍의 출현으로 사용되지 않게 된 그 플로우차트말이다.

이 말은 상태차트의 도식적 표기법을 깍아내리려 함이 아니다. 오히려 앞서 말한 어려움은 소프트웨어 개념을 시각화하는데 따른 어려움에서 생긴것이다.
근본적으로 소프트웨어란 시각화하기 힘든 것이다. 제어흐름, 변수범위의 중첩, 변수의 상호참조, 데이터 흐름, 계층형데이터구조를 비롯한 모든 것을 다이어그램으로 표현하면 아주 복잡하게 얽힌 소프트웨어라는 코끼리의 한 쪽 측면만 바라보게 된다. - Brooks
이 글의 뒷부분에서 그는 Harel에게 다음과 같이 답했다.
소프트웨어 구조는 3차원에 포함되지 않으므로, 2차원에서든, 아니면 그 이상의 차원에서든 개념적인 설계를 다이어그램으로 자연스럽게 매핑하는 방법은 없다. 우리는 여러개의 다이어그래(여러개의 뷰)을 필요로 하며, 각 다이어그램은 트정한 면을 보여줘야 한다. 심지어 어떤 경우에는 다이어그램으로 나타낼 수 없을 때도 있다.

2.2.10
상태차트와 플로우차트
상태차트와 비교해볼 때 플로우차트는 지점과 경로의 개념을 뒤집은 것이다. 상태차트에서는 처리가 경로와 연관돼 있는 반면, 플로우차트애소눈 지점과 연관돼있다.
플로우차트는 공장의 생산라인과 비교할 수 있다. 플로우차트란 어떤 일의 진행과정을 처음부터 끝까지 나타낸 것이기 때문이다.
대개 상태차트는 이런 진행과정의 개념이 아니다. 예를 들어 컴퓨터 키보드에서 capsLocked 상태에 들어가는 것이 default상태보다 한 단계 더 나아간 과정이라고 할 수 없다. 상태머신에서의 상태는 처리 단계가 아닌 시스템 전체 행위의 제약조건을 지정하는데 있어 효과적인 방법이다.

A state captures the relevant aspects of the system's history very efficiently.
A state machine generally has no notion of such a progression. A state in a state machine is an efficient way of specifying a particular behavior, rather than a state of processing.

2.1.11
상태차트와 코드자동생성
코드는 자동생성되어야 한다. 어떻게 할 것인지는 이 책의 진행에 따라 설명하겠다.

2.3 상태모델 예제
이 절에서는 계산기의 상태모델 작성을 예로 들고 있다.
예제에 몇 가지 결함이 있다. 그 결함은 굳이 언급하지는 않겠다. 아래에서 예제를 좀 더 간단히 바꾸어서 사용시나리오 부터 설명하고 있으니 그 예제와 비교해 보고 결함을 찾아봐라.
여기에서 필자는 정규표현식과 상태머신의 관계를 좀 더 깊이 고찰해보고자 한다.
몇 가지 설명은 그것을 자세히 설명할 만한 시간이 없어 간단히 사실만을 언급한다. 하지만 이 몇개의 문장을 통해서 여러분은 많은 것을 깨달을 수 있을 것이다. 그 깨달음은 몫은 우선은 여러분에게 남겨둔다.
설명을 좀 더 간략화 하기 위해 예제를 바꾸었다.

계산기의 범위를 다음과 같이 정의한다.
-
자연수에 대한 사칙연산만 지원하는 것으로 한다.
-
수식 계산결과는 피연산자로 사용되지 않는다.

간단한 사용시나리오를 작성해 보면 다음과 같다.
1.
액터는 수식을 작성하고, 작성된 수식의 계산 결과가 제공되도록 요청한다.
2.
시스템은 요청된 수식의 계산 결과를 제공한다.

예제에서 다루는 대부분은 수식 작성 부분이다.
이 부분은 시스템 구성요소 중 스토리보드(화면)의 책임에 해당한다.
수식 작성은 대화식으로 작성해야 하기 때문에 GUI로 작성한다. p7과 같은 화면으로 작성된다.
수식은 피연자, 연산자, 피연산자 순으로 작성된다.
수식 계산 결과 제공 요청은 '=' 버튼을 눌러 가능하게 한다.
수식을 정규표현식으로 나타내면 아래와 같다.
Expression ::= Operand Operator Operand
Operand ::= {1..9}{1..9}*
Operator ::= '+'|'-'|'*'|'/'

정규표현식은 상태머신 다이어그램으로 작성가능하다. 이것이 가능한 이유는 무엇일까?
'Expression ::= Operand Operator Operand'의 의미를 좀 더 풀어보면
"
수식은 첫 번째 피연산자가 작성된 후에 연산자가 작성될 수 있고, 연산자가 작성된 후에 두 번째 피연산자가 작성될 수 있다."와 같이 된다.
, 수식 작성 중에 어떤 행위를 하기 위해서는 이 행위 이전에 어떤 행위들이 수행되었는지가 영향을 미친다는 것이다. 따라서 행위수행이력이 관리되어야 한다.
다시 말하면 수식 작성은 상태행위라는 것이다.
정규표현식은 상태머신으로 작성될 수 있다. 이때 정규표현식의 항목은 상태가 된다.
위의 내용은 정규표현식 작성이 한 번에 끝나는 것이 아니라 작성과정이 있다는 것 또한 알려준다.
, 진행상태라는 것이다.
'
수식 작성기'라는 시스템 구성요소를 고안한다면, 수식 작성기는 수식 작성중 상태를 갖는것이다.
수식 장성중 상태의 하위 상태로 첫 번째 피연산자 작성중, 연산자 작성완료, 두 번째 피연산자 작성중 상태를 가질 것이다.
수식 작성기는 생성되고 난 후에는 소멸 되기까지, 수식을 작성중이거나 수식 작성을 완료하고 대기 상태에 있을 것이다.
정규 표현식에서 말단 구성요소(terminal node)는 완료 상태를 나타낸다.
진행상태를 나타내는 정규표현식 항목은 진행이 중단되는 사건을 식별해야 한다.
처음 상태가 진행중이 가능한 경우는 진입사건을 식별해야 한다.

* 고찰 내용이 직접적으로 사용될 수 있는 것은 컴파일러 제작에서이다.
아직 UML 상태머신을 이용해 작성되는 컴파일러들은 없다. 필자가 개발하고 있는 모델링 도구의 컴파일러는 상태머신을 이용해 개발된다.

 

 

저작자 표시 비영리 변경 금지
신고
| 2016.02.12 02:34 | PERMALINK | EDIT/DEL | REPLY
비밀댓글입니다
Justine | 2016.02.19 23:37 신고 | PERMALINK | EDIT/DEL
상태머신에 대한 엔진을 구현한다는 것은 쉬운 일이 아닙니다. 구현기술도 뛰어나야 하지만 상태머신에 대해서도 잘 알아야 하기 때문입니다. 퀀텀프로그래밍은 상태머신도 잘 이해하고 대단히 뛰어난 구현능력을 가진 저자에 의해 잘 만들어진 상태머신엔진입니다.
상태머신을 실제 적용하는 것은 엔진만 있다고 되는 것이 아닙니다. 상태머신을 모델링해야 하는 문제가 있습니다.
상태머신은 모델링기술 중에서도 매우 어려운 기술에 속합니다.

개인적으로 만나서 이야기하는 것은 쉽지 않고, 저희 회사에서 소프트웨어모델링을 교육하고 있는데 상태머신 모델링에 대한 부분도 심도있게 다루고 있습니다. 이 교육을 들어보시길 권해 드립니다. 자세한 사항은 다음 링크를 참조하시면 됩니다.
http://www.umlcert.com/lecture/rsm/
mogle | 2016.02.26 20:30 신고 | PERMALINK | EDIT/DEL | REPLY
네 감사합니다~ 기업의 대표님이신줄도 모르고 댓글을 남겼네요..
교육도 하고 계신다니 대단하십니다.
좋은 정보들에 참 감사합니다. 큰 도전을 받았어요.
교육을 통해 꼭 뵐 수 있도록 노력해 봐야겠어요. 감사합니다.
Name
Password
Homepage
Secret