UML 을 사용하여 설계를 시작한 것은 대략 2001년경부터인데... 당시 객체지향 프로그래밍(OOP), GoF의 디자인 패턴과 더불어 나의 3대 과제 중 하나였다. 인터넷뿐만 아니라 관련 서적을 통해 공부하였으며 2004년 3판까지 나온 "초보자를 위한 UML 객체지향 설계"의 1판을 최소 5회 이상 읽었던 것으로 기억한다. 그리고 지금도 객체지향 설계와 관련한 책추천을 받으면 반드시 이 책을 소개하곤한다.
처음 실무 적용은 그야말로 혼돈이었다. 어떤 상황에 어떤 다이어그램을 그려야하는지? 혹은, 클래스를 추출하기 위한 명사, 동사 테이블에 분류할 명사의 기준(영어엔 동명사가 존재하니까)은 무엇인지? 하지만 계속된 시도의 결과였는지... 다행히 지금은 UML 을 사용하는데 큰 어려움을 느끼지 않는다.
일단, UML 이라는 단어를 잘 살펴보자. 처음 머릿속에 박힌 단어는 모델링이었다. 학부시절 기계공학을 전공하였던 터라 모델링(Modeling)이라는 단어가 남다를 수 밖에 없었다. 만약, 오프로드를 달리는 자동차에 대한 승차감을 연구한다고 치자. 이 자동차를 질량의 덩어리 및 스프링과 뎀퍼로 상정하고 집중적으로 살펴볼 수 있을 것이다. 그 외 디테일한 요소는 큰 의미가 없거나 실험에 있어 복잡함을 가중시킬 뿐이다.(오차 범위내에서 무시해버린다.)
아무튼 이렇게 자동차를 스프링-뎀퍼 시스템으로 모델링할 수 있다. 그렇다면 단어의 의미를 보았을 때, UML 은 어떤 대상을 모델링할 수 있는 일반적인 언어(표현법)라는 것인데... 그럼 이 모델링의 대상은 무엇일까? Unified 즉 어떤 경우라도 사용할 수 있어보인다. 하지만, 프로그래머라면 그 대상은 의뢰자의 도메인(Domain) 영역 혹은 나의 도메인 영역으로 한정할 수 있다. 어이쿠 도메인이라는 단어가 어렵게 느껴진다. 나 또한 그랬으니까. 좀 더 쉬운 말로 바꿔볼까? 프로그래머라면 그 대상은 의뢰자의 전문 영역 혹은 나의 전문 영역이 되는 것이다.
만약, 의류 쇼핑몰의 재고관리 프로그램을 의뢰 받았다면 UML 의 모델링 대상은~ 의뢰자의 도메인 영역 즉, 의류 쇼핑몰의 재고관리와 나의 도메인 영역, 프로그래밍이 되는 것이다. 이때 의뢰자의 도메인 영역을 UML 로 모델링하는 것을 개념(Conceptual) 설계라고 부르고... 나의 도메인 영역을 모델링하는 것을 물리(Physical) 설계라고 부른다면 100% 까지는 아니지만 얼추 비숫하다고 할 수 있다.^^
UML 에서 사용되는 다이어그램으로 UseCase, Class, Activity, Sequence, Component, Deployment 등이 있는데 이 모든 다이어그램을 각 설계 단계에서 모두 사용할 필요는 없다. 상황에 따라 차이는 있겠지만 지금까지(대략 10년 정도?) 작업해본 결과 다음과 같이 활용해왔다.
물론, Conceptual Class Diagram, Physical Class Diagram 모두 가능하다. 다만 개인적인 관점에서 중간 결과물로 각 설계 단계에서 상기와 같이 작업하면 무난할 것으로 판단된다. 뭐라해도 설계란건 정답이 없는 것이니 설계자의 개성에 따라 각 다이어그램의 비중이 달라질 것이며 지금 기술한 내용은 나의 설계 개성으로 파악하면 좋다. 그리고 다이어그램의 사용 빈도를 보았을 때 UseCase > Activity > Class > Deployment > Sequence 순으로 활용해왔다.
UML 설계에 있어 난점은 처음부터 끝까지 모든 다이어그램으로 모든 것을 그리려하는 잘못된 태도에 있다. 그것은 모델링이 아닌 그저 옮겨쓰는 행위일 뿐이다. 모델링 대상인 도메인 영역에 적합한 다이어그램을 선정하고, 궁금하고 필요한 것들에 대해서만 표기하면 되는 것이다. 너무 명백한 것에 대하여 다이어그램을 도출하는 것은 그야말로 쓸모없는 짓이다. 소위 "내가 해봤는데... 실무에 적합하지 않아." 라고 하는 사람이 있다면 후자에 해당될 것이다.
다음 글엔 개념 설계에 있어 도메인 영역 분석에 대한 중요성과 사례에 대해 써볼까한다.(기분 내킬때..;;)
 |
|
처음 실무 적용은 그야말로 혼돈이었다. 어떤 상황에 어떤 다이어그램을 그려야하는지? 혹은, 클래스를 추출하기 위한 명사, 동사 테이블에 분류할 명사의 기준(영어엔 동명사가 존재하니까)은 무엇인지? 하지만 계속된 시도의 결과였는지... 다행히 지금은 UML 을 사용하는데 큰 어려움을 느끼지 않는다.
UML - Unified Modeling Language
일단, UML 이라는 단어를 잘 살펴보자. 처음 머릿속에 박힌 단어는 모델링이었다. 학부시절 기계공학을 전공하였던 터라 모델링(Modeling)이라는 단어가 남다를 수 밖에 없었다. 만약, 오프로드를 달리는 자동차에 대한 승차감을 연구한다고 치자. 이 자동차를 질량의 덩어리 및 스프링과 뎀퍼로 상정하고 집중적으로 살펴볼 수 있을 것이다. 그 외 디테일한 요소는 큰 의미가 없거나 실험에 있어 복잡함을 가중시킬 뿐이다.(오차 범위내에서 무시해버린다.)
 |
 |
아무튼 이렇게 자동차를 스프링-뎀퍼 시스템으로 모델링할 수 있다. 그렇다면 단어의 의미를 보았을 때, UML 은 어떤 대상을 모델링할 수 있는 일반적인 언어(표현법)라는 것인데... 그럼 이 모델링의 대상은 무엇일까? Unified 즉 어떤 경우라도 사용할 수 있어보인다. 하지만, 프로그래머라면 그 대상은 의뢰자의 도메인(Domain) 영역 혹은 나의 도메인 영역으로 한정할 수 있다. 어이쿠 도메인이라는 단어가 어렵게 느껴진다. 나 또한 그랬으니까. 좀 더 쉬운 말로 바꿔볼까? 프로그래머라면 그 대상은 의뢰자의 전문 영역 혹은 나의 전문 영역이 되는 것이다.
만약, 의류 쇼핑몰의 재고관리 프로그램을 의뢰 받았다면 UML 의 모델링 대상은~ 의뢰자의 도메인 영역 즉, 의류 쇼핑몰의 재고관리와 나의 도메인 영역, 프로그래밍이 되는 것이다. 이때 의뢰자의 도메인 영역을 UML 로 모델링하는 것을 개념(Conceptual) 설계라고 부르고... 나의 도메인 영역을 모델링하는 것을 물리(Physical) 설계라고 부른다면 100% 까지는 아니지만 얼추 비숫하다고 할 수 있다.^^
개념 설계 - 의뢰자의 도메인 영역 분석
물리 설계 - 나의 도메인 영역 분석(적용 패턴 선정 등...)
UML 에서 사용되는 다이어그램으로 UseCase, Class, Activity, Sequence, Component, Deployment 등이 있는데 이 모든 다이어그램을 각 설계 단계에서 모두 사용할 필요는 없다. 상황에 따라 차이는 있겠지만 지금까지(대략 10년 정도?) 작업해본 결과 다음과 같이 활용해왔다.
물론, Conceptual Class Diagram, Physical Class Diagram 모두 가능하다. 다만 개인적인 관점에서 중간 결과물로 각 설계 단계에서 상기와 같이 작업하면 무난할 것으로 판단된다. 뭐라해도 설계란건 정답이 없는 것이니 설계자의 개성에 따라 각 다이어그램의 비중이 달라질 것이며 지금 기술한 내용은 나의 설계 개성으로 파악하면 좋다. 그리고 다이어그램의 사용 빈도를 보았을 때 UseCase > Activity > Class > Deployment > Sequence 순으로 활용해왔다.
UML 설계에 있어 난점은 처음부터 끝까지 모든 다이어그램으로 모든 것을 그리려하는 잘못된 태도에 있다. 그것은 모델링이 아닌 그저 옮겨쓰는 행위일 뿐이다. 모델링 대상인 도메인 영역에 적합한 다이어그램을 선정하고, 궁금하고 필요한 것들에 대해서만 표기하면 되는 것이다. 너무 명백한 것에 대하여 다이어그램을 도출하는 것은 그야말로 쓸모없는 짓이다. 소위 "내가 해봤는데... 실무에 적합하지 않아." 라고 하는 사람이 있다면 후자에 해당될 것이다.
다음 글엔 개념 설계에 있어 도메인 영역 분석에 대한 중요성과 사례에 대해 써볼까한다.(기분 내킬때..;;)
반응형
'개발일지 > 아키텍트' 카테고리의 다른 글
| GoF, Command 패턴 (0) | 2012.02.08 |
|---|---|
| POSA, Forwarder-Receiver 패턴 (0) | 2012.01.31 |
| POSA, Whole-Part 패턴 (0) | 2012.01.30 |
| 나의, UML 객체지향 설계 - 3 - (0) | 2011.12.20 |
| 나의, UML 객체지향 설계 - 2 - (0) | 2011.12.19 |
댓글