1. UML 객체지향 세계를 그리다.

사람은 소통한다. 살기위해 소통하고 얻기위해 소통한다. 사람들이 얼굴보고 소통할때는 말뿐만 아니라 손짓, 발짓, 표정 그리고 알수 없는 미묘한 감성까지 힙을 합쳐 소통 한다. 그래서 사람들이 얼굴보고 소통할때는 자신이 전하고자 하는 뜻을 대부분 빠트리지 않고 전달한다.

 

과학 기술 영역에서는 소통의 어긋남이 조금이라도 발생하면 전체가 어긋난다. 섬세한 기록이 요구되는 과학 기술 영역에서 사람의 언어는 불완전한 소통 수단으로 전락한다. 그래서 과학 기술 영역에서는 사람의 불완전한 언어를 보완할 간결하고 명확한 언어를 쓴다.

 

수학은 간결함과 명확함으로 상징되는 과학의 언어이다. 수학은 인류의 발전을 우주로 이끌어 올린 로켓 엔진과 같은 힘을 주었다. 사실 수학은 나에게 어려움의 상징이긴 하지만 결국 수학 덕분에 지금 내가 컴퓨터로 밥벌이 하고 있다는 사실은 잊지 않고 있다.

 

객체지향 프로그래밍도 과학 기술의 한 분야이다. 수학처럼 간결하고 명확한 소통수단이 필요하다. 그래서 만들어진 객체지향 모델링 언어가 UML(Unified Modeling Language)이다.

 

 

세상은 복잡하다. 세상의 복잡함은 수학으로도 증명하기 어려울 것이다. 객체지향 모델링은 복잡한 세상을 분석하는 방법이고, UML은 객체지향 모델링을 시각적으로 나타내는 도구이다. 그래서 UML은 세상의 복잡한 요소를 최대한 잘 그리기 위해, 여러 관점의 다양한 다이어그램이 존재한다.

 

유즈케이스 다이어그램은 책의 목차와 비슷하다. 요구분석단계에서 대상 업무의 전체 시스템 구성을 한눈에 파악하는데 도움을 준다.

 

[인터넷 뱅킹 구성을 예로들면, 사용자는 조회, 이체, 대출, 펀드, 보험등의 기능을 이용할 수 있다.]

 

클래스 다이어그램은 아이돌 그룹의 리더와 같은 존재이다. 모든 같은 그룹 구성원 중에서도 중심이 되는 다이어그램이다. 클래스와 클래스간의 관계를 한눈에 파악하는데 도움을 준다.

 

[보통 실무 개발자들은 클래스 다이어그램을 보고 어플리케이션을 어떻게 개발할지, 어플리케이션이 어떻게 구성되었는지 분석한다.]

 

시퀀스 다이어그램은 전자 회로도와 비슷하다. 전자 회로도가 전자의 흐름을 묘사했듯이 시퀀스 다이어그램은 객체와 객체 사이의 메시지 흐름을 묘사했기 때문이다. 객체와 객체간의 메시지 흐름을 한눈에 파악하는데 도움을 준다.

 

[보통 사용자가 웹브라우저를 이용할 때 일어나는 시간별 메시지 흐름을 한눈에 파악할 수 있다.]

 

협력 다이어그램은 시퀀스 다이어그램과 이란성 쌍둥이이다. 그림 그리는 방법만 틀릴 뿐이지 '메시지'의 흐름을 묘사한다는 면에서 동일하다. 시퀀스 다이어그램과 협력 다이어그램이 동일하기 때문에 일반 UML 툴에서 시퀀스 다이어그램과 협력 다이어그램 중 하나를 작성하면 다른 하나는 자동으로 그려주기도 한다. 시퀀스 다이어그램과는 다른관점에서 객체와 객체간의 메시지 흐름을 한눈에 파악한다.

 

[음료수 자동판매기의 음료수 뽑기 절차를 협력다이어그램을 통해 직관적으로 보여주고 있다.]

 

상태차트 다이어그램은 사람의 정밀한 심리 분석 차트와 비슷하다. 시퀀스와 협력 다이어그램이 객체와 객체간의 메시지 흐름을 그린 것이라면, 상태차트 다이어그램은 객체 내부의 자세한 행동을 그린다. 객체 내부의 이벤트별 상태 변화를 한눈에 파악하는데 도움을 준다.

 

[PC사용 과정을 한눈에 파악할 수 있다.]

 

액티비티 다이어그램은 GW베이직 배울때 같이 배웠던 순서도가 생각난다. 옛날 전산 시간에 배웠던 순서도와 거의 비슷한 다이어그램이다. '객체'들의 '활동 순서'를 한눈에 파악하는데 도움을 준다.

 

[액티비티 다이어그램은 예를들어 사용자, 서버, 통신서버, 호스트의 영역을 둘수도 있고, 작업의 흐름을 한눈에 파악할 수 있게 도와준다. ]

 

컴포넌트 다이어그램은 레고 조립 설명서와 같은 느낌을 준다. 완성된 모듈끼리 서로 어떻게 연결되는지 파악하는 것이 목적이다. 독립적으로 작동가능한 모듈과 모듈간의 관계를 한눈에 파악하는데 도움을 준다.

 

[컴포넌트는 독립적으로 작동가능한 물리적으로 존재하는 모듈이며 워드프로세서 컴포넌트 같은 경우 세부 구성요소가 무엇이 있는지 확인 할 수 있다.]

 

배치 다이어그램은 가장 간단한 네트워크 다이어그램과 비슷하다. 오히려 더 간단하여 어플리케이션과 서버가 어떻게 배치가 되었는지 바로 알 수 있다. 어플리케이션과 서버간의 배치 상태를 한눈에 파악하는데 도움을 준다.

 

[배포 다이어그램은 서버 구성도, 네트워크 구성도 등의 시스템 배치 여부 확인에 많이 쓰인다.]

 

이렇게 UML의 다양한 다이어그램은 객체지향으로 구현할 어플리케이션 개발 전 과정에서 저마다 유익한 다이어그램으로 활약한다.

 

 

UML을 쓰기전에 나는 몇가지 이슈에 대해 고민해야 했다. 하나는 UML을 얼마나 표준에 맞게 그릴 것인가 이고, 하나는 여러가지 UML 다이어그램중 무엇을, 얼마나 쓸 것인가였다.

 

UML을 얼마나 표준에 맞게 그릴 것인가에 대한 고민은 UML을 쓰게된 계기가 무엇인지 먼저 생각해보면 타협점을 찾을 수 있다.

 

UML을 쓰게된 계기는 '개발할 어플리케이션과 관계된 요소'들을 글과 코드와 기호만 가지고, '고객, 개발자, PM, 아키텍트'등의 당사자끼리 의사 소통 하기가 답답하고 힘들기 때문에 쓰게 됐다. 이때 UML이란 그림을 통해서 당사자간 의사소통이 쉽게 이루어진다. UML은 '당사자간 의사소통을 돕는다.' 라는 사명감을 가지고 있다. 그래서 UML을 그릴때는 '얼마나 의사 소통에 도움 되게 그릴 것인가'를 우선순위로 해야 한다.

 

'의사 소통'을 최우선 순위로 그리면 UML 표준에 어긋날 수 있다. 예를 들어 클래스 다이어그램의 '속성'과 '메소드'와 '그들끼리의 관계'를 정확하게 그리자면, 클래스 기호들은 자신들의 속성과 메소드를 담느라 거대해 질것이고, 그들끼리의 관계를 정확하게 그리다보니 마치 실 뭉텅이가 엉킨 것 같다. 클래스 다이어그램이 미로처럼 복잡해지고 비대해져서, UML 본래 목적인 '의사 소통에 도움' 이 되지도 못하고 오히려 의사소통을 방해하는 그림으로 전락한다.

 

[위의 클래스 구성도를 통해 클래스의 존재와 클래스들이 어떻게 관계하는지를 알려주고 싶은 의도가 있다면, 만약 속성과, 메소드와 관계를 하나하나 정확하게 기술했을 경우는 그림이 더 복잡해서 본래 의도를 전달하는데 방해되기도 한다.]

 

내 책의 UML 다이어그램은 UML이 아니라 일반 그림이라 말할정도로 '변형'된 UML을 그릴지도 모른다. 나는 무엇보다 UML은 '당사자간 의사소통에 기여한다.' 라는 사명감을 가지고 있음을 잘 알고 있다. 의사소통에 도움이 된다면 다소 표준을 벗어나는 것을 감수한다.

 

UML 표준을 지켜야 할 때도 있을 것이다. 권위있는 기관에 정식으로 산출물을 제출할 때나, 학교 시험이나 논문을 쓸때는 UML 표준을 지켜야 한다.

 

나는 내 책이 객체지향을 최대한 알기 쉽게 설명하고 쉽고, 내가 그린 UML 그림이 최대한 내 설명을 뒷 받침 해주길 바라고 있으므로 나는 '표준' 보다는 '의사 소통'을 우선하여 UML을 그릴 것이다. 그렇다고 표준을 무시하는 것은 아니다. 다만 나는 프로젝트를 위한 문서가 아닌 경직된 관료조직의 상급자를 만족시키기 위한 문서 작성을 하면서 비효율적인 '표준'을 싫어했던 경험을 하곤 했다.

 

 

여러가지 UML 다이어그램중 무엇을, 얼마나 쓸 것인가에 대한 고민은 역시 '당사자간 의사소통에 기여한다.'를 의식해서 결정해야 한다. 그림이 그럴 듯 해보인다고 여러 다이어그램을 무조건 사용한다면 역시 혼란스러운 그림들로 인해 '의사소통'에 방해만 줄 수 있다.

 

내 책같은 경우는 객체와 클래스의 관계에 대한 설명이 대부분이다. 거의 클래스 다이어그램 하나만 있어도 만족스럽게 설명한다. 그래서 내 책은 클래스 다이어그램만 사용한다.

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다. 특별한 일 없으면 매주 월수 발행 예정입니다.

신고
Posted by 산골
산골 블로그 소개 저는 하얀머리 개발자와 작가를 꿈꾸는 블로거 산골 입니다. 프로그램 개발자로서 저의 관심사는 개발자의 숨통을 트여준 아이폰 개발, 철학과 같은 깊이가 있는 객체지향 방법론입니다. 글쓰기와 수영을 좋아합니다. 블로그를 통해 관심사를 공유합니다. 제 블로그에 관심 있으시면 아래 RSS나 즐겨찾기로 편하게 구독하세요.

rss Bookmark and Share

댓글을 달아 주세요