이번에는 지난 강좌에 이어서 완성된 Domain Model을 가지고 시스템의 설계를 검증하는 방법에 대해서 한번 알아 보겠습니다.
1. Story of Usecase
이전 Usecase 단계에서 우리는 시스템의 전체적인 동작 시나리오를 작성했었습니다. 주로 액터와 시스템의 액션에 주목했었습니다. 이 스토리는 추상화 레벨이 아주 높으며 시스템 내부의 동작은 거의 블랙박스입니다. 하지만 이제 우리는 시스템 내부의 핵심 Domain Object들을 추출하였고 스토리에서 시스템 내부로 이어지는 부분에 대한 연결고리를 추출해 낼수 있게 됩니다.
2. System Realization
바로 시스템 내부로 이어지는 부분에 대한 설계를 Realization이라는 영어를 써가며 표현하고 있지만, 사실은 머 확인이나 검증 정도로 생각해도 되겠습니다. Usecase에서 설명한 시스템의 스토리와 그 스토리를 Domain Object를 사용해서 표현할 경우 어느정도의 싱크로율을 보이는가에 따라서 지금까지의 설계가 어느정도 빈틈없이 튼튼하게 이루어졌는지 확인 할 수 있을 것입니다.
사용되는 다이어그램은 주로 Sequence Diagram입니다.
아래의 예를 한번 보도록 하죠.
<이전의 도메인 모델에서 설계한 DVD 대여점의 시나리오 일부분입니다>
1. DVD의 대여신청
1.1 액터가 시스템에 로그인한다.
1.2 액터가 시스템에 대여하기를 원하는 DVD를 검색한다.
1.3 시스템은 검색된 DVD를 화면에 표시한다.
1.4 액터는 대여가 가능한 DVD를 선택하여 대여를 신청한다.
1.5 시스템은 대여와 관련된 필요한 정보를 입력하는 화면을 표시한다.
1.6 액터는 필요한 정보를 입력하고 최종적으로 대여를 신청한다.
1.7 시스템은 입력된 정보들의 타당성을 검증하고
결제시스템을 사용하여 결제한다음, 창고쪽에 새로 대여가 신청된 DVD의 출고 데이터를
생성하여 전송한다.
1.8 창고 관리 직원은 전송된 데이터에 따라 DVD를 포장하여 출고한다음
출고가 최종적으로 완료되었음을 시스템에 입력한다.
1.9 시스템은 출고된 DVD의 상태를 변경한다.
1. DVD의 대여신청
1.1 액터가 시스템에 로그인한다.
1.2 액터가 시스템에 대여하기를 원하는 DVD를 검색한다.
1.3 시스템은 검색된 DVD를 화면에 표시한다.
1.4 액터는 대여가 가능한 DVD를 선택하여 대여를 신청한다.
1.5 시스템은 대여와 관련된 필요한 정보를 입력하는 화면을 표시한다.
1.6 액터는 필요한 정보를 입력하고 최종적으로 대여를 신청한다.
1.7 시스템은 입력된 정보들의 타당성을 검증하고
결제시스템을 사용하여 결제한다음, 창고쪽에 새로 대여가 신청된 DVD의 출고 데이터를
생성하여 전송한다.
1.8 창고 관리 직원은 전송된 데이터에 따라 DVD를 포장하여 출고한다음
출고가 최종적으로 완료되었음을 시스템에 입력한다.
1.9 시스템은 출고된 DVD의 상태를 변경한다.
아주 간단하게 표시한것이지만, 대체적으로 Usecase의 시나리오는 이러한 형식을 크게 벗어나지 않습니다. 다만 각각의 단계에서 발생 할수 있는 예외상황에서 어떻게 일을 처리할 것인지를 명확히 표시하는것에서 차이가 있을 수 있겠습니다.
대부분 아주 중요한 스토리보드에서의 예외처리에만 집중을 하면 될것입니다. 예를 들어 잘못된 결제정보입력이라던지, 창고에서 신청된 DVD가 파손되었음을 뒤늦게 확인하였거나 분실되었음이 확인될 경우 등등이 되겠죠. 대신에 로그인에 실패할 경우 어떻게 하라등등 아주 일반적이고 상식적인 부분까지 설명할 필요는 상대적으로 적을것입니다.
자 그럼, 위의 시나리오를 우리가 설계한 Domain Object를 사용해서 한번 표현해 보도록 합시다.
그런데 이전의 강좌에서 산출한 최종결과물로는 위의 시나리오를 그대로 표현하기에 무리가 있습니다. 즉, Domain Object모델의 설계가 불완전하다는 이야기로 직결되죠.
그래서 Domain Object를 조금 더 추가하겠습니다. 렌탈시스템과 창고시스템을 추가하겠습니다.
이 두 시스템은 DVD대여 시스템의 서브 시스템들이며 충분히 Domain Object적인 성격을가지고 있습니다. 각각 시스템에서 이루어지는 자세한 usecase는 생략하기로 하고 전체적인 시스템 스토리 상에서의 역할은 대략 상식수준에서 가늠할 수 있는 그것이라 정의하겠습니다.
(사실 여기서 귀차니즘이 발생했거든요, 그려놓은 파일을 날려먹어서 다시 그리기 귀찮아졌습니다.)
그럼 이제 Sequence다이어그램을 그려 보도록 하겠습니다. 하지만 시퀀스 다이어그램이 옆으로 길어지는 경향이 있어서 화면에 딱 맞에 표시가 되지 않더라구요. 그래서 나누어서 단계별로 한번 그려보겠습니다.
창고시스템은 전달된 대여신청건에 대해서 창고에 적재된 위치를 검색하여 창고관리자에게 화면이나 기타 수단을 사용하여 알리게 됩니다. 그럼 창고 관리자는 지정된 위치에서 해당 DVD를 꺼내온다음 입력된 주소정보나 기타 정보를 사용해서 택배를 보내게 되겠죠. 그리고 최종 정보를 시스템에 입력하게 되면 창고시스템은 그 정보를 렌탈시스템에게 전달하고 렌탈시스템은 택배정보를 회원에게 메일이나 웹을 통해서 확인할 수 있게 합니다.
창고관리자가 또 다른 액터로 등장해야 정상이지만 그림이 너무 복잡해지고 귀차니즘이 발생하였기 때문에 생략하였습니다.
예외상황의 처리는 여러분께서 한번 해 보시기 바랍니다.
다음 강좌에서는 지금까지 진행된 강좌에서 부족하다고 생각된 부분에 대해서 다시 다루겠습니다.
'UML' 카테고리의 다른 글
| About UML #06 - 쉬어가는 페이지, 좋은 문서화란.. (0) | 2006.11.22 |
|---|---|
| About UML #05 - MDA (Model Driven Architecture) (0) | 2006.10.31 |
| About UML #04 - Domain Modeling 1. (0) | 2006.10.22 |
| About UML #03 - Usecase (0) | 2006.10.10 |
| About UML #02 Overview - 전체적인 구성 첫번째 (0) | 2006.10.06 |
