04 Statechart Diagram

Statechart Diagram에 대해서 공부겸, 이력서및 자소서 작성 때문에 포스팅 작성에 지체가 되버렸네요;_; 세상에서 자소서 쓰는게 제일 힘든 듯 ㅠㅠ)… 무튼! 포스팅을 시작 할게요 :)

• 상태 다이어그램(Statechart Diagra)
  
  사용되는 요소 보기
  
  
  
  
  상태 다이어그램(Statechart Diagram)은 상태 기계(State machine)를 나타내는 거에요. 주체는 객체가 되는 거구요. 거의 액티비티(Activity) 다이어그램과 유사 하지만, 액티비티(Activity) 다이어그램은 (보통) 사용자가 주체가 되서 시스템이 하는 일(Usecase)을 순서에 맞게 표현해 주는 거에요. 상태 다이어그램(Statechart Diagram)은 객체가 하는 일을 순서에 맞게 표현해 주는 거구요.
  
  현재 까지 진행되었던 예시의 객체 중 "CAMERA" 클래스에 대해서 진행 하도록 할게요.
  • 상태 다이어그램(Statechart Diagra) 생성
    
    
    
    
    
    생성하는 것은 기존에 만든거 처럼 아주 간단해요. 혹시나 까먹으신 분이 계실 까봐 한번 더 올려주는 센스 :)ㅋㅋ
    
  • 시작, 끝 요소(InitialState, FinalState) 삽입
    
    어디에서나 시작과 끝이 중요 하죠! 시작, 끝 요소에 대해서는 먼저 다 만들어 놓고 하는 버릇이 있으니까요.(취향입니다 존중 해 주시죠? ㄱ-ㅋㅋ)
    
    
    
    
    
    클릭, 클릭으로 간단히 아래 처럼 만들었어요:)
    
    
    
    
  • 상태(State) 요소 삽입
    
    상태(State) 요소를 삽입하기 전에 일단 "CAMERA" 객체가 하는 일에 대해서 알아야 겠죠? 보기 좋게 나열해 볼게요.
    • 대기(Idle) 한다.
    • 상태가 변경 될 수 있다.(ChangeViewMode, Resize, Move, Rotate)
    • 그래픽 카드로 보낼 화면을 처리한다.
    • 그래픽 카드로 화면을 보낸다.
      
      
    
    간단 하군요! :D 보통은 "CAMERA"가 가지고 있는 함수들을 보면 알 수 있어요. 나중에 이것 저것 기능이 추가 될 수 있지만, 아직까지는 복잡하지 않으니까 쉬이 보이는 거죠.
    
    일단 나열된 상태들을 한번에 주욱 넣어 볼게요.
    
    
    
    
    마찮가지 방법으로 모든 상태들을 만들면, 아래와 같은 모양새가 된답니다:)
    
    
    
    
    속성이 변하는 것은 별도의 처리를 했어요. 같은 범주에 있는 거는 표현 할 때 묶어 두어야 보기에 좋기도 하구요. 물론 구현은 프로그래머가 하기 나름이겠죠. 문서화 내용을 너무 파괴하지 않는 한도 내에서요 :)
    
    
  • 상태 이력(ShallowHistory, DeepHistory), 분기(JunctionPoint), 선택(Choice) 요소 삽입
    
    사실 제가 가지고 있는 예시에서는 별로 중요 하지 않기는 해요. 중간에 인터럽트가 걸린다거나 하는 일이 없거든요. 이력(History)에 관해서는 별도의 예시를 사용 할 게요.
    
    객체가 특정한 상태에서 잠시 사용이 중단이 되었다가 다시 자신이 하던 일을 계속 해야 하는데, 어디 까지 했는지 기억하지 못한다면 처음 부터 다시 해야겠죠? 객체 생성부터ㅋ
    
    가령, 프로그램을 인스톨 하는데 재시작을 한 후에 인스톨이 되는 프로그램 이라면? 을 아주 간단히 표현해 본다면 아래와 같이 될 거에요.
    
    
    
    
    
    저 같은 경우에는 화면보호기가 아닌 윈도우 잠금 설정을 해놓는데, 비슷한 맥락 이겠지만 화면 보호기 상태에서 다시 움직였을 때 윈도우를 처음 부터 다시 시작 하지 않고 화면보호기가 켜지기 바로 전에 화면이 보이잖아요? 그런것도 비슷하게 그려낼 수 있겠죠?
    
    
    
    
    
    사실 암묵적으로 화면보호기 갔다가 다시 마우스나 키보드 입력을 주게 되면 자동으로 프로그램 A의 "키입력을 기다린다" 로 돌아올 테지만 명시를 해 놓는 거 정도라고 저는 해석 했어요.
    
    위와 같이 단일 State에 대해서는 얕은 이력(ShallowHistory)를 사용 하고, 만약에 여러 개의 State로 쌓여있는 곳에서 이력을 확인해야 할 때는 깊은 이력(DeepHistory)를 사용 하는데 옆에 * 표시가 되어 있어요. 화면보호기 예시로 든다면, 아래와 같이 될 거에요.
    
    
    
    
    
    
    후후.. 겸사겸사 다른 쓰잡대기 없는 거까지 한번에 처리해 버렸군요 -_,-ㅋㅋ
    
    
    StarUML에서의 JunctionPoint는 그 모양이 InitialState와 비슷한데 크기가 작은 거네요 :) fork나 join (≒Synchronization)처럼 모두 들어오거나 한번에 나간다거나 하는 건 아니고, 여러 개의 선이 엇갈리는거 보다 하나에서 처리하려고 있는 거 같아요.
    
    ChoicePoint가 (제가 생각했을 때) 엄밀한 의미로 "분기" 같은데 상태에 따라서 하나의 Transition으로 가게 되는 거죠. 액티비티(Activity) 다이어그램에서의 Decision과 같은 의미로 보시면 되요.
    
  • 전이(Transition), 자가 전이(SelfTransition)
    
    말 그대로 상태가 바뀌는 거에요. 상태기계라 함은 여러가지 상태가 있는데, 그 중에 특정한 조건(Trigger)이 발생(Fire)하면 상태가 바뀌는 거거든요. 물론, 현재는 아주 프로그램에 관련된 내용이니까 상태가 보통은 처리하는 일(함수)로 표현이 되는 거 뿐이죠.
    
    이미 위의 단락에서 그려진 예시를 보였지만, 실제로 어떤 조건이 들어가야 하는지를 적어줘야 확실해 지겠죠?
    
    형식은 아래와 같아요.
    
    
    
    
    일반적인 관계 형성과는 다르게, StarUML에서는 "조건"과 "보호"를 입력하는 부분이 다소 짜증나게 구성되어 있더군요 :) 조건을 생성하는 방법은 아래와 같아요.
    
    
    
    
    보호를 생성하는 방법은 아래와 같아요.
    
    
    
    
    
    어찌보면 보호도 조건안에 포함 되는 것이지만, 조건은 "설명"의 느낌이 있다면, 보호는 "수치화"/"부연설명"의 느낌이 있어서 그런 거 같아요:)
    
    
    (포스팅을 위해 약간의 변화가 생겼어요 :D)일단 하고 있었던 예제에 대해서 표현 하자면 아래와 같이 되요.
    
    
    
    저 정도의 영어를 모르시는 분들은 안 계시겠죠? :) 특별히, Idle 상태에서 UpdateScene으로 전이(Transition)되는 부분은 Timer로 진행 되는 거에요. 대기상태에서 (보통은) 일정한 시간마다 화면을 갱신 시켜 줘야 거의 비슷하게 디스플레이가 된다고 느끼니까요.
    
    ChangeProperties로 가는 부분은 변경되는 신호를 받았을 때 넘어가게 되요.(프로그램이니까 함수 콜이겠죠? :D)
    
    각각의 State는 해당 처리를 완료(Completed)하면 다시 대기 상태로 돌아오는 거고, 프로그램이 종료 되기 전까지 화면 갱신은 쉬지 않고 일어나야 하니까 계속 대기->화면갱신->대기->신호받으면 속성변화->반복…. 이 되는 거에요.
    
    조건에 대해 보호되는 거는 ChangeProperties에서 표현해 봤어요.
    
    
    
    
    화면이 작아서 글이 좀 삐져나오고 겹쳐지고 하지만, ChangeProperties의 상태에서는 받은 신호가 뭐냐에 따라서 분기가 일어나기 때문에 위에 처럼 표현 했어요.
    받은 신호 중 Resize면 특별히 가로와 세로의 수치를 필요로 한다고 표현 했어요.
    바로 옆에 Move는 너무 칸이 작아서 Need는 빼고, 방향과 거리 수치가 필요하다고 표현 했구요ㅋㅋ 그럼 나머지도 그에 합당한 필요한 수치가 있겠죠~?ㅎ
    
  • Fork, Join(Synchronization) 요소 삽입
    
    객체지향 적 으로다가 설계/구현 하는 이유는 객체마다 정해진 일만 할 수 있게 하고, 그렇게 함으로써 유지/보수의 효율을 높이는데 의의가 있어요.
    
    "CAMERA"라는 객체는 전체적인 세계에서 자신이 보고 있는 것만을 계산해서 모니터로 뿌려주면 되는 거죠. (추후 구현 예정이지만)하지만 이때에 단순히 보이는 것만 모니터에 뿌려준다고 하면 큰일이 하나 발생 할 수 있어요. 가령 카메라 바로 앞에 특정 오브젝트가 가려서 안보인다고 했을 때, 사용자 입장에서는 실질적으로 봐야 할 것을 보지 못하는 경우가 발생하니까 그 부분에 대해서 그리지 말라고 "Display"객체에게 요청해야 해요.
    
    물론 그렇게 복잡한 건 내부적으로 있는 걸로 가정하고 하나의 State로만 표현 했어요.
    
    그리고 이 과정은 (거의) 동시에 진행 되야 하고, 둘 다 마쳤을 때 UpdateScene이라는 상태가 완료가 되는 것이죠.
    
    그게 바로 Fork와 Join의 의미에요.
    
    
    단어는 동기화(Synchronization)라고 표현 되있네요. 맥락적으로는 같으니까 특별히 신경써야 할 부분은 아니에요 :)
    
    
    
    
    
    
    해당 상태(State)가 끝나면 바로바로 진행 되는 부분이라 별도의 조건(Trigger)는 표현 하지 않았어요.
    

은근히 UML이나 Diagram에 대해서 사람들이 많이 찾아 오시더라구요. 제가 포스팅이 본업이 아닌지라, 여기에 모든 시간을 투자하지는 못해서 그나마 찾아오시는 분들께는 좀 죄송하네요 ;_;

저도 공부하면서 올리는 거라서 직접적인 의견이 아닌 이런 간접적인 의견도 반영해서 포스팅 하는 중이니까 댓글로, 방명록으로 "뭐에 대해서 했으면 좋겠다"고 직접적인 의견 제시 해주세요 :D

다른 사람들이 원한 다는 건 그게 어디에서든 간에 사용이 되고 있다는 소리니까 공부 한다고 해서 나쁠건 없으니까요ㅎ