signum

 

위 내용들을 다음 예제를 통해서 좀 더 쉽게 접근해 보도록 한다.

다음은 보험사의 고객에 대한 간단한 유즈케이스 이다.

보험계약은 계약자, 피보험자, 수익자로 이루어 진다. 계약은 보험 모집인이 계약자와 계약을 성사 시켜 회사에 계약서를 제출하고 회사는 이를 승인하여야만 계약이 이루어 진다. 계약자는 보험을 계약하고 유지 하기 위해서 보험료를 납부해야 하며 매달 보험료 납부 정보를 우편으로 전달 받는다. 피 보험자는 보험의 대상이 되는 것으로 건강 상태 정보를 기입을 해야 한다. 보험 모집인은 보험 회사 소속으로 보험이 계약이 될 때 특정 금액을 회사로 부 터 지급받으며 지점의 소속으로 보험 모집인이 계약한 보험계약은 지점의 수익으로 처리한다.

 

위 유즈케이스 구문에서 제일 첫 번째 문장인 "보험계약은 계약자,피보험자,수익자로 이루어 진다. 계약은 보험 모집인이 계약자와 계약을 성사 시켜

회사에 계약서를 제출하고 회사는 이를 승인하여야만 계약이 이루어 진다." 만 볼 때 계약자,피보험자,수익자,보험모집인은 엔티티 중 사람 타입으로 식별을 할 수 있다.

때문에 다음과 같이 사람의 타입을 가지고 있는 attribute를 두어서 표현을 할 수 있을 것이다.

 

 

그림 1

 

그런데 다음 문장에서 이들 보험계약에 참여하는 사람들의 특성을 표현하고 있다.

계약자는 보험 계약을 유지 하기 위해서 보험료 입금에 필요한 정보를 추가적으로 가질 수 도 있을 것이고 피 보험자는 자신의 건강상태 정보를 가져야 한다.

즉 사람들 마다 각각 자신의 역할 마다 추가되는 정보 및 특성을 가지고 있다는 것을 알 수 있는 것이다.

때문에 단순히 attribute를 두어서 사람들을 표현하기가 어려울 수도 있다. 예를 들어 보험료 납부를 자동이체로 처리 한다면 자동이체에 대한 계좌 정보가 필요할 것이다.

이는 보험계약자만 필요한 정보이지 피보험자,수익자,보험모집인의 경우는 필요하지 않을 것이다.

그래서 각각의 사람들을 전혀 공통적인 특성을 가지고 있지 않는 개별적인 존재로 분석을 하면

다음과 같이 표현을 할 수 도 있다.

그림 2

 

솔직히 그림 2에서 표현된 것처럼 표현하지는 않을 것이다. 왜냐하면 이들 모두는 공통된 특성을 가진다.

여기서 말하는 공통된 특성은 이들 모두 사람을 표현하고 있고 사람은 기본적으로 공통된 데이터를 가진다. 나이,이름,성별,연락처 등등.

이렇게 공통적인 테이터가 있는 경우 상위 타입을 두어서 공통된 특성을 모아 놓은 다음 각각의 특성을 표현할 수 있는 하위 타입을

두면 된다. 결과적으로 다음과 같이 정리 될 수 있을 것이다.

그림 3

 

이렇게만 된다면 여기서 고객에 대한 분석이 끝나고 얼마나 행복할까?

고객과 업무 분석 도중 고객이 이런 말은 하였다고 가정해 보자

"보험계약의 계약자는 사람도 되고 법인 기업체도 가능합니다.",하나의 보험 계약에는 여러 명의 수익자가 발생할 수 있습니다.” 등등 추가 적인 요인이 발생할 수 있다.이러한 추가적인 요건에 좀더 빠르게 대응하기 위해서는 무엇보다 정리와 도메인을 적절히 표현하는 것이 필요하며 Analysis Patten이라는 것은 그러한 것을 정리하고 시스템을 분석해 줄  수 있는 방법을 제시하고 있는 것이다.

 

어떤 사람들은 분석 단계에서 도출된 Entity들을 그대로 설계작업을 거쳐  DB화 시키려고 한다. 이럴 경우 DBA와 충돌이 발생할 수 있다. DBA의 경우는 어떻게 하면 좀 더 구조적으로 명확한 자료 구조를 만드는지가 최우선 과제이기 때문에 그림 3과 같이 각각의 특성에 따라 분리된 entity들을 DB로 생성을 할 수 없다고 할 것이기 때문이다. 왜? 단지 조금씩 특성이 틀리지만 공통된 정보도 있기 때문에 하나의 테이블로 만들어도 무방하다고 볼 것이기 때문이다.

100%로 맞는 말이다. 그림3은 도메인을 분석하기 위한 다이어그램일 뿐이다. 절대로 DB의 모델이 될 수 없으며 되어서도 안 된다.

 

분석이라는 영역은 매우 복잡하고 지식이 많이 필요한 업무라고 생각한다.
불행히도 분석에 대한 교재는 많이 부족한 실정이며 대부분의 엔지니어가 감으로  혹은 경험으로 분석을 하는 경우가 많다(솔직히 패턴도 경험의 다른 얼굴이잖아!)

이 글은 분석영역에서 빠지지 않고 등장하는 Role에 대한 분석을 이야기 하고자 한다.
Role이라을 분석한다는 것이 그렇게 쉬운 일은 아니며 어렵고 항상 딜레마에 빠지게 하는 '괴물'같은 놈이라는 사실이다.
기본 내용은 Martin Flowler의  "Dealing with Roles"을 참고 하였으며
내 경험과 알고있는 도메인을 사용해서 예제 및 여러 내용들을 작성하였다.


Roles Patten

어떠한 도메인이든 업무 분석을 하다 보면 항상 문제를 겪는 것이 사용자의 역활이다.
사용자로 부터 요구사항을 받아 역활들을 죽 나열해 보면 어떤 시스템의 경우 A4지를 넘어가는 경우도 있다.
또한 A라는 역활은 B라는 역활을 포함하기도 하고 B는 C와 D의 역활을 가지기도 한다.

어찌해서 시스템이 필요한 역활들을 사용자로 부터 모두 받아서 정리를 하였다고 해보자
문제는 이것을 어떻게 시스템으로 잘 반영을 할 지 고민을 하게 된다.
왜냐 하면 역활이라는 것은 단순히 시스템의 개발을 위해서 정리된 것이 아니고
오랜 시간동안 업무를 해 오면서 자연스래 역활이 정의된 것이기 때문에 대부분의 도메인은 매우 복잡하고 다양한 Role을 가지고 있다.
일반적으로 개발 하게되는 회사의 에플리케이션은 엔지니어,영업직,사무직,관리직 등 많은 사람들이 사용을 하고 있으며 각각 특화된 역활을을 시스템에서 수행하게 될 것이다.
이러한 시스템을 분석할 때 필요한 분석 패턴이 Role patten으로  일반적인 Role을  모델링하는데 사용될 수 있겠다.

우리는 위와 같이 다양한 사용자를 가지고 있을 때 사용자들은 모두 공통된 행동을 하지 않지만 일반적으로 공통된 행동을 한다는 것을 알 수 있다.(예를 들면 로그인,메일,급여지급 등등..)
때문에 Role 분석 시 가장 먼저 접근하게 되는 방법은 공통된 행위들로 먼저 사용자를 구분 지어 상속으로 각 특성에 맞도록 확장해 나갈 수 있다.
이것은 결국 모든 문제가 해결된 것처럼 보이지만 솔직히 현실의 문제는 좀 더 복잡하다.
왜나면 하나의 사용자가 여러가지의 역활을 수행하는 경우는 매우 일반적인 일이니까.
예를들어 보험업무의 경우 계약자는 피보험자이자 수익자가 될 수 있다.혹은 엔지니어이면서 메니저 혹은 영업담당자의 역활 을 수행할 수도 있기 때문이다.

Martin Flowler의 경우 Role Patten을 적용하는 데 5가지 형태로 분리를 하여서 정리를 하고 있다. 요약 해 보면 다음과 같다.
1.대부분의 객체들이 공통적인 부분이 많으여 일부 틀린 역활을 수행하는 경우(Single Role Type)
2.대부분의 객체들이 공통적인 부분이 없으며 특정한 역활을 수행하는 경우(Separate Role Type)
위 2두 가지의 경우 매우 간단하며 그리고 올바른 분석에 대한 결정을 내리기 쉽지만 다음의 경우는 좀더 복잡해 진다.
3.일부 동일하며 일부 틀린 역활을 수행하는 경우(Role SubType)
4.그리고 역활들이 점차 확장되어 가는 경우
3번 째의 경우는 Role Subtype(상속)을 이용해서 표현을 할 수 있다.
 분석단계에서는 서브타입을 이용하는 경우가 곧바로 구현상의 상속을 의미하지는 않는다. 분석단계는 개념적 단계이지 구현단계처림 구체화 되지 않기 때문이다.
위에서 언급 했듣이 개발자는 공장관련 이야기를 들을 때는 어떻게 구현할 지 를 항상 머리속에 생각을 하기 때문에 구현시 에서는
Flag, Delegate, State Object을 이용해서 구현을 구체화 할 수 있을 것이다. (이 패턴은 직접 찾아 보자)
특히 Flag, Delegate, State Object를 이용해서 구현할 하나의 객체가 여러개의 역활을 수행하게 할 수 있도록 구현이 가능하다.
솔직히 이 방식이 아마 가장 많이 사용하는 방법이 아닐지? 한 두 가지의 역활을 수행하는 경우라면 비교적 쉽게 적용을 할 수 있으며 사용효과도 크다.

그러나 꼭 사용효과가 큰것은 아니다.
가령 역활이 계속 추가 되어야만 하는 경우라 든지 각각의 역활 객체를 분리 하는 경우는 수정의 비용이 결코 작다고 할 수 없다.
때문에 역활을 분리하여 Role Object를 만들고 Host Object에서는 어떠한 Role을 수행할지 판단해서 Client에게 특정 Role Object를 전달하여 사용하게 하는 분석도 있다.
위 경우에 대해서 차분히 살펴 보자

Single Role Type
엔지니어,영업,메니저,창구직원이 회사의 구성원 이라고 가정하고(실제로는 더 복잡하겠지만) 이들 간 역활의 성격이 틀린점이 많이 없다고 가정해 보자.
이들의 공통점은 이들 고용인을 표현하고 있으며 다만 업무의 차이가 있을 뿐이다.
이러한 경우라면 하나의 고용인 객체에 간단하게 직업을 나타내는 atttribute를 이용해서 표현을 할 수 있다.(Single Role Type으로 )
특히 앞으로 역활이 변경될 여지가 없다면 이 방식을 적용하는 것이 가장 적합할 것이다.
 
 그러나 불행이도 고객은 "앞으로 변경되지 않습니다." 라고 하는 경우가 매우 드물 것이다.
OO에서는 늘 변경 가능성을 염두에 두고 분석-설계가 이루여 지며 만약 변경이 이루어 진다면 좀더 쉽게 변경이 가능하도록 설계가 되어야 한다.
그렇다면 이 경우는 OO개념에서는 적절하지 않는가? 이에 대한 질문은 그렇지 않다는 것이다. 왜냐하면 이 패턴은 앞으로 나올 모든 패턴의 기본이 될 것이기 때문이다.
 만약 앞으로 고객의 역활이 계속 바뀌고 거기에 맞추어 가지고 있어야 하는 정보 역시 계속 바뀌게 된다면 개발자는 유지보수에 대한 고민에 빠지게 된다.
특히 데이터를 변경하는 경우 변경하고자 하는 데이터가 공통적인 부분이라면 이 고민이 더욱 커질 것이다.
이러한 경우 각각의 타입별로 역활 객체를 만드는 것을 고려해 볼 수 있다.

Separate Role Type
이 패턴은 각각의 역활 별로 객체를 만듬으로써 각 역활별 관계가 줄어들고 이는 공통적으로 사용할 수 있는 데이터가 없어지는 것을 의미하며 따라서 자신만의 데이터를 가지도록 한다.
이는 개발자가 차후 발생 할 수 있는 수정에 좀더 유연하게 대체를 할 수 있도록 한다.

그러나 이 패턴도 문제는 존재한다.  중복된 특성들이 만들어 질 수 있고 보존성이 사라진다.
사실 엔지니어,영업직,사무식 모두 고용인이며 고용인은 공통된 특성을 많이 가지고 있으므로 이들은 유사한 점이 많다고 볼 수 있다.-이름,우편물 수령지, 급여,개인정보와 같은 정보가 여기에 속한다.

문제는 하나의 역활이 추가 될 때 수정의 여파가 크다는 것이다. 필요하다는 것이다.
만약 우편물 수령지가 변경이 된다고 해보자.
우편물 수령지는 공통된 정보이기 때문에 각 역활 객체마다 복사해서 사용을 하게 될 수도 있을 것다.  이 공통의 특성에 정보가 추가 된다든지 변경이 된다면 각각의 타입 객체들을 일일이 수정을 해 주어야 하는 문제점에 이른다.

또한 홍길동이라는 사람이 엔지니어이자 매니저이라 가정해보자. 우리는 홍길동이 어느 시점에서 각각의 역활을 수행하게 될지 알 수 없다.
때문에 우리는 2개의 객체를 만들어서 이것들을 조합해서 사용을 하거나 전혀 또 다른 역활 타입을 만들어서 사용을 할 수 밖에 없다.
2 개의 객체를 만들어서 사용을 하는 경우 우리는 어느 시점에서 각각의 역활을 수행하는지 판단하기 어렵기 때문에 적절항 역활을 바꿔 주기가 힘들다.
또한 전혀 새로운 타입을 만들어 사용하는 경우는 시스템이 복잡해 지고 시간이 흐르게 되면 수 없이 많은 역활 타입을이 만들어 질 것이다.
이 문제는 비지니스 시스템을 개발하면서 상당히 많이 접하게 되는 문제인 것이다.

이러한 문제가 있어도 만약 공통된 부분이 많이 없다면 아마도 Separate Role Type 패턴이 적합할 것이라 생각이 된다.
OO프로그래밍의 단점은 항상 tread-off 를 고려해야 한다는 것과  올바른 정답이 없다는 것이 단점이자 장점이다.
때문에 각각의 조건에 맞는 가장 적합한 방법을 찾는 것이야 말로 설계에서 가장 중요한 기술이 아닐까 한다. 
다만 이 패턴이 적합한 경우는 위 조건을 만족할 때(공통된 부분이 많이 없고 복합적인 Role type이 발생되지 않는 경우) 사용되어야 할 것이라 본다.
그러나 대부분의 시스템은 역활 별로 적당한 공통 부분과 적당히 틀린 부분이 있을 것이다.
(내 경험상 이 경우가 대부분 이였다.) 이러한 경우 아마도 가장 적합한 패턴이 Role SubType이 아닐까 한다.

Role SubType
이 방식은 상속의 개념을 적용한 것이다.
공통된 부분은 부모가 가지고 있고 각각의 역활별로 틀린 부분들은 각각 자식클래스(Subtyping)로 표현을 할 수 있다.
엔지니어라는 역활을 분석해 보면 고용인을 특성화 시킨 것이라 볼 수 있다. 때문에 엔지니어는 고용인의 또 다른 사례라 볼 수 있으며
고용인의 모든 특징을 가지고 있고 추가적으로 엔지니어만의 특화된 특성을 가지고 있다고 볼수 있는 것이다.
때문에 때문에 엔지니어는 고용인의 특성을 상속받고 추가적으로 자신만의 특화된 정보가 추가 된다면 엔지니어를 표현할 수 있을 것이다.
만약 홍길동이 엔지니어이면서 매니저의 역활을 수행한다면 홍길동은 두가지 역활을 상속받으면 이 정보를 표현 할수 있을 것이다.
이러한 개념으로 시스템은 역활들을 계속해서 확장-추가 할 수 있게 될 것이지만 여기에서 문제는 발생한다.

에를 들어 자바와 같이 하나의 타입만 상속을 받는 언어의 경우 동시에 두가지(엔지니어,매니저)를 상속 받지 못하게 된다.
많은 개발자들이 분석시점 부터 개발자의 뷰로 시스템을 접근한다는 것이다. 예를 들어 유저와 함께 시스템을 분석할 때 사용자로 부터 요구사항을 듣는 순간 이미 시스템적인 분석과 구현 방향을 머리 속으로
하고 있다는 것이다.
분석시점에서 우리는 개발할 도메인은 개발-구현의 입장에서 바라보는 것이 아니라 도메인 expert의 입장에서 바라보아야 하며 그럴 경우
이 패턴은 분석 시점에서는 상당히 유용할 것이다.
그리고 구현 시점에서는 interface의 개념을 사용한다면 좀 더 쉽게 접근이 가능할 것 이다. '

먼저 결론을 이야기 하자면 글쎄 가격 만큼의 재미는 없었다는 것이였다.
(가격대비라는 것에 주의 하고 상당히 주간적인 평가이다.)
더군다나 바로 지난 주에 점프를 보고 와서 인지 보는 내내 점프와 비교를 하게 되었는데
단점들이 자꾸 눈에 거슬렸던거 같다.



스토리라인의 부재
스토리 라인이 상당히 부족하였다는 점 스토리 구조는 상당히 단순하다. 물론 포퍼먼스 공연들이 대부분 간단한 스토리 라인을 가지고 있지만 20% 정도 관객이 이해 할수 없는 스토리 라인이라면 문제가 아닐까 싶다.
연기력 부재(?)
출연자 대부분이 비보이 출신이라 연기력 면에서 상당히 부족하였다 뮤지컬이나 연극을 많이 본 사람들은 배우들이 무대에서 조금 과장된(TV나 영화와 비교해서)를 한다는 것을 알수 있을 것이다. 즉 많은 사람들을 대상으로 연기를 펼치기 때문에 조금 큰 몸짓이나 행동을 하게 되며 그것을 통해서 관객에게 감정을 전달하게 되는데 이 부분에서 부족하지 않았나 싶다.
이 부분들은 단지 이 공연 뿐만이 아니라 요즘 펼쳐지고 있는 비보이 공연 대부분이 가지고 있는 문제가 아닐까 한다.

그래도 이 공연은 스트레스가 쌓였거나 뭔가 자유스러운 기분을 느끼고자 한다면 나쁘지 않은 선택이다.

대한민국에 살면서 북한 사람들을 볼 수 있는 기회가 몇번이나 있을까?
참으로 우연히 북한 사람들에게 IT 지원 교육의 강사역활이 주어져 5주 정도 가게 되었다. 장소는 단동
신의주 바로 맞은 편에 위치한 중국땅.

압록강을 마주 보고 북한 땅을 볼 수 있다.



카메라를 가지고 다니는 것을 별로 좋아 하지 않는 나로써는 폰카로 찍을 수 밖에 없었는데 아쉬움이...
단동의 분위기는 우리나라 70후반에서 80년대 초 정도


중국 사람들은 우리가 삼겹살에 소주를 마시듯 양고기 꼬치에 고량주를 마신다. 그리고 무엇보다 식사하러 가면 식사 전 맥주 한병 씩 비우고 그때서야 밥을 먹거나 술을 마신다.
울 나라 보다 많은 맥주 종류를 가지고 있는데 단동에 있을 때 싸고 양 많고 맛좋은 맥주를 찾았는데 그것이 압록강 맥주

Banff에 위치한 sunshine vaillage 스키장 뒤편으로 다녀온 Back country.
이곳 스키장 슬로건이 world Best snow! 인데 그 말이 맞는거 같다.
스노우 베이스가 2M나 되며 파우더-물기가 없는 건조한 눈-이기에 한국에서 처럼
넘어져도 팔목이나 허리 부분이 다칠 위험은 없다.





그러나 자칫 하면 눈 속에 파묻혀 몇달이 지난-눈이 다 녹은 다음-뒤에나 찾을 수 있다.