'Domain Model'에 해당되는 글 1건

  1. 2006.10.22 About UML #04 - Domain Modeling 1.
UML2006. 10. 22. 00:25
우선 강좌가 늦어진것 죄송합니다. 그동안 여러가지로 일들이 조금 바빠지는 바람에 낮에는 전혀 블로그 관리를 할 수 없었습니다. 저녁에도 개인적으로 중요한 일들이 많아서 시간이 좀 나지 않았었습니다. 하지만 한번 하기로 맘먹은 이상 만족할만한 결과물이 나올때 까지 한번 해 보겠습니다.

1. Domain Modeling이란
본격적인 개발단계에 들어가기 전까지 개발자들은 고객과의 긴밀한 협조를 하게 되는데 그 과정을 통해서 개발자가 얻고자 하는것은 대상 시스템에 대한 명확한 이해라고 할 수 있습니다. 도메인 모델링이란 유스케이스와 더불어 시스템에서 명확히 존재함이 들어나는 비지니스로직상의 객체들의 개념적 설계혹은 정의라고 할 수 있습니다.
쉽게 이야기 하면 도메인 모델링이란 개발 대상이 되는 시스템혹은 업무처리에서 사용되어지는 "어떤 것"들을 구체화시키는 작업이라 할 수 있습니다.

(설명이 잘 이해가 되지 않은것 같아서 예를 들어 설명해 보겠습니다.)

예1) DVD 대여점 시스템의 창고 관리.
보통 쉽게 생각해 봤을때 창고 관리 시스템은 DVD를 관리합니다. 즉 DVD가 우선 제일 간단히 생각해 낼 수 있는 비지니스 로직상의 개념입니다.
DVD는 여러가지 속성을 가지는데 제목이라던지 출연배우, 감독, 영화장르, 대여가격, 최근대여상태(누가 빌려갔는지, 창고에 있는지, 다른 문제가 있는지)등등이 있을것입니다.
이러한 점들을 정리하고 UML로 표현하면 도메인 모델링의 시작인것입니다.

예2) 흔히들 웹프로그래밍을 공부할때 관문처럼 되어버린 게시판 프로그램
게시판 그 자체가 비지니스 객체가 될수 있겠네요, 그리고 글, 리플들이 있을수 있고,
작성자 제목, 작성날짜 등등이 속성이 될수 있겠습니다.

2. Domain Modeling을 수행하는 방법
우선 명확한 비지니스 객체들을 파악하여 클래스 다이어그램이나 기타 다이어그램을 사용하여 설계할 수 있을것입니다. 그 다음에 해야 할 일은 객체들 사이의 관계들을 정의하는 것입니다. 구체적일 필요는 없으나 구체적이면 구체적일 수록 다음 단계가 수월해 질 것입니다.

그리고 반복되는 이터레이션을 통해서 좀더 자세하고 구체적인 점들을 명시합니다.

예를들어 간단한 DVD대여점의 창고 관리 시스템들 개발한다고 해봅시다.
우선 웹상에서 회원들이 가입을 하면 DB에 회원들의 정보가 저장이 되고,웹에서 자신이 대여하고 싶어하는 DVD들을 조회할 수 있으며, 대여가 가능한 DVD들을 신청할 수 있다고 합시다.
창고에서는 신청이 들어온 DVD들을 창고의 지정된 위치에서 꺼내와서 신청자의 주소로 물건을 발송한다고 합시다.
그리고 사용자가 DVD를 시청한 다음 반환하면 창고에서는 우선 DVD를 검사하여 고장이나 파손유무를 확인하고 창고의 적정위치를 검색하여 DVD를 창고에 입고시킵니다.

우선 제일 먼저 생각할 수 있는것은 회원, DVD, 창고 위치등등일 것입니다.
간단하게 Class Diagram으로 표현해 보도록 합시다.
그럼 이제 좀더 구체화를 시켜 보도록 하겠습니다.
여러분은 고객과의 계속되는 회의와 접촉을 통해서 다음과 같은 것들을 알게되었습니다.
회원은 자신의 고유 번호가 있고, 회원 가입을 할때 주소를 입력한다고 합니다.
DVD는 고유 상품번호가 있으며, 제목과 대여가격, 그리고 지금 대여가 가능한 상태인지 알수 있어야 한다고 합니다.창고 위치를 지정하기 위해서는 우선 섹터가 있고 각 섹터에는 5개 씩의 선반이 있으며 5개 씩의 선반은 층과 단으로 나뉘어 져 있다고 합니다.
그럼 이제 이 정보를 가지고 설계를 좀더 진행해 보도록 하겠습니다.
간단하죠 ?
충분히 이해하시리라 생각이 됩니다.
그럼 이제 아주 간단히 비지니스 객체들 사이의 관계를 한번 생각해 봅시다.
처음부터 너무 구체적으로 생각하려 하지 마시고 아주 아주 간단한 관계부터 시작해 봅시다.
우선, DVD는 창고에 저장이 된다고 하였습니다.
그러기 위해서는 DVD가 창고 어디에 있는지 알아야 되는데 어떻게든 그 정보를 가지고 있어야 할 것입니다. 즉 DVD와 창고 위치 사이에는 무언가 관계가 있는것 같습니다.
또한 회원은 DVD를 열람하고 대여를 신청할 수 있습니다. 즉 회원과 DVD사이에도 무언가 관계가 있습니다.
하지만 회원과 창고위치사이에는 지금까지의 스토리만으로는 어떤 관계가 있는지 알기 어렵군요.
지금까지의 분석을 통해서 알게된 사실들을 그림을 통해서 표현해 보도록 합시다.
정말 별것 없습니다. -_-; 제가 죄송할 정도이네요.
자 그럼 이제 조금더 자세히 파고 들어가 보겠습니다.
우선 회원과 DVD사이의 관계를 조금더 파고 들어가 보겠습니다.
앞서 우리가 알게 된것은 회원이 DVD를 대여 할수 있다는 것이었습니다.
"대여"라는 정보는 회원과 DVD가 관계를 가지기 때문에 발생하는 부수적 객체입니다. 애초에 회원이 DVD와 아무런 연관이 없었다면 대여신청을 할 수 없었겠죠.
바로 여기서 우리는 연관클래스라는 개념을 도입해서 다음과 같이 표현 할 수 있습니다.
그림은 금방 이해하시리라 생각이 됩니다. 대여 정보에는 누가 무엇을 대여신청했는지 알려주고 있습니다.
자 그럼 이제 DVD와 창고위치사이의 관계를 한번 살펴보겠습니다.
DVD는 창고에 저장이 됩니다. 그리고 창고를 떠나 회원에게 전달됩니다. 그리고 다시 창고에 들어옵니다. 들어올때에는 새로운 위치를 지정받게 될것입니다.
이는 아주 간단하게 생각하면 DVD의 속성으로 간주할 수 있습니다. 즉 DVD 자신이 어디에 입고될것인지에 대한 정보를 가지게 할 수 있습니다.
또 다른 관점은 앞서서 회원객체와 DVD객체사이에서 연관클래스를 유추해낸것 처럼 창고위치와 DVD사이의 관계도 동일한 관점으로 바라볼 수 있습니다.
이번 강좌에서는 일관성을 유지하기 위해서 다음과 같이 표현하겠습니다.
여기서 창고재고정보 클래스에서 위치 ID를 추가하였는데 이는 편의를 위해서 스토리상에서는 존재하지 않는 속성이지마나 객체들과의 1:1 관계를 보장하기 위해서 임의로 생성한 속성입니다.

이러한 방식으로 조금씩 조금씩 비지니스 클래스들을 추가할 수 있을 것입니다.

자 그럼 이제 어느정도 설계가 완성된 아래의 그림을 보면서 오늘의 강좌를 정리해보도록 하겠습니다.
우선은 회원과 DVD사이의 카테고리를 정의하였습니다. 회원은 여러개의 DVD를 대여할 수 있기 때문에 1:N의 관계로 정의하였습니다. 그리고 DVD는 창고의 어느 한곳에만 입고가 될것이기 때문에 1:1의 관계로 정의하였습니다.
또한 우리는 앞선 스토리에서 고장안 DVD인지 판별한다고 했기 때문에 DVD의 한 종류중에 파손된 DVD라는 객체를 생성하였습니다. (DVD의 또 다른 속성으로 파손유무를 표현하게 할 수도 있습니다.) 그리고 DVD에는 여러장이 시리즈물인 경우가 있기 때문에 DVD가 다음편으로 연결이 되는지 재귀관계로 표현하였습니다.
또한 창고위치정보에 지금 그 위치에 물건이 있는지 없는지를 나타내는 속성을 추가하였고
이 속성과 창고재고 정보는 대여정보에서 영향을 많이 받는관계인데 그 이유를 설명하는 주석을
표시하였습니다.

비지니스 로직에 대해서 알면 알수록 도메인 모델링은 더욱 튼튼해지고 이후의 과정은 수월해 질 것입니다. 한번에 다 알아내려는것 보다는 조금씩 조금씩 이터레이션을 거치는 과정이 중요합니다.

다음 시간에는 이렇게 정의된 Domain Model을 이용해서 어떠한 작업을 추가로 진행해야 하는지 살펴보도록 합시다.

    
Posted by 알 수 없는 사용자