나의, UML 객체지향 설계 - 3 -

UML 은 모델링 도구이며 개념설계에 있어 편리한 다이어그램으로 UseCase 와 Activity 를 설명하였다. 그러나 이것은 어디까지나 개인적인 경험에 의한 판단이고 만약, 그외 다른 UML 다이어그램으로 우리가 애초 하고자한 목적인, 의뢰자와의 커뮤니케이션을 원할하게 풀어갈 수 있다면 그것만으로 충분하다.

의뢰자의 도메인영역에 대한 이해가 어느정도 이뤄지게되고 도입하려는 프로그램에 대한 역제안이 발생하는 단계에까지 이르면 전체적인 시스템 구성을 확립하게된다. 이 단계에 적합한 다이어그램은 Deployment(배치) 이다.

사례1
2010년경 모 이동통신 회사의 동기화 프로그램의 Deployment 다이어그램이다. 노란색은 이미 존재하고있는 외부 모듈이고 파란색은 개발하여야할 부분이다. 이와 같은 색상별 표기는 별도 규칙이 있는 것은 아니고 그저 개발하고자하는 시스템의 구성을 설명하기에 적합하기만 하면 된다.

 
사례2
이전 글에서 설명하였던 웹에이전시 회사의 인트라넷 구축 관련 Deployment 다이어그램은 여러 서버군으로 구성되어 다소 복잡한데 반드시 모든 시스템을 설명할 필요는 없다. 간단하게 살펴보자면 전체 시스템이 메인 홈페이지와 인트라넷 서버, 인트라넷 클라이언트, PDS 서버, Framework 서버로 구성되어있으며 각 서버간 통신 수단으로 SOAP 와 FTP 등이 사용됨을 알 수 있다.

이러한 전체 시스템 구성에 대한 논의가 이뤄지면서 해당 시스템의 구축 하드웨어 및 소프트웨어 등이 결정된다. 즉, 서버 사양은 어떻게 할 것이며 서버 OS 는 무엇으로 할 것인가? 그리고 결정된 OS 의 웹서비스는 어떻게 개발할 것인가? 등등... 또한 이 과정에서 핵심적 기술사항에 대한 테스트 개발 및 서드파티 라이브러리 구매에 대한 결정이 이뤄지게 된다. 물론 Python 과 같은 동적 스크립트 언어를 활용하여 프로토타입 개발도 진행된다면 금상첨화다.

여기까지가 의뢰자와의 개념 설계 구간이자 물리 설계의 초기 단계라고 할 수 있다. 이후 지금까지의 산출물과 함께 본격적인 물리 설계 구간으로 접어들게 되며 개발자는 물리 설계가 진행되는 기간 동안 UI 디자인 등을 의뢰자에게 중간 결과물로 제출할 수 있다. 또한 Deployment 다이어그램의 각 노드를 세분화하여 Component 다이어그램을 그려나갈 수 있다. 끝으로 개발팀의 개발환경 구축 및 적용될 개발방법론에 대한 리뷰 절차도 이 무렵 이뤄지게된다.