본문 바로가기

기타/객체지향 토막글

UML로 객체지향 세계를 그리다. - 수필 객체지향

사람은 소통한다. 살기위해 소통하고 얻기위해 소통한다. 사람들이 얼굴보고 소통할때는 말뿐만 아니라 손짓, 발짓, 표정 그리고 알수 없는 미묘한 감성까지 힙을 합쳐 소통 한다. 그래서 사람들이 얼굴보고 소통할때는 자신이 전하고자 하는 뜻을 대부분 누수없이 전달한다. 그러나 과학 기술 영역에서는 소통의 어긋남이 조금이라도 발생하면 전체가 어긋날 수 있다. 섬세한 기록이 요구되는 과학 기술 영역에서 사람의 언어는 불완전한 소통 수단으로 전락한다. 그래서 과학 기술 영역에서는 사람의 불완전한 언어를 보완할 간결하고 명확한 언어를 쓴다.

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

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


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

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

[그림]

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

[그림]

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

[그림]

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

[그림]

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

[그림]

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

[그림]

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

[그림]

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

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


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

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

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

[그림]

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

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

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


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

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


1.3.1    클래스, 인터페이스
클래스와 인터페이스는 클래스다이어그램의 몸체에 해당한다. 상단에 이름을 적고, 중간에 속성을 적고, 하단에 메소드를 적는다. 보통 속성과 메소드를 넣을 필요가 없으면 넣지 않아도 된다.

[그림]

1.3.2    상속
화살표는 마치 자식이 엄마에게 용돈 달라고 손내미는 모습과 같다. 화살표 방향의 클래스를 자신이 상속받는 다는 뜻이다.

[그림]

1.3.3    연관, 의존
연관과 의존은 마치 나는 너를 알고 있어라고 손가락질 하는 모습과 같다. 화살표 방향의 클래스를 자신이 알고 있다는 뜻이다.

[그림]

1.3.4    구성, 집합
구성과 집합의 마름모꼴은 마치 둘이 강하게 악수한 모습과 같다.  마름모 꼴로 연결된 두 객체 패밀리 그룹은 한쪽이 다른 한쪽의 구성요소, 부속품의 요소로서 존재한다. 보통 악수할때 팔을 거의 내밀지 않는 쪽이 주인이고 팔을 길게 내민쪽이 부속품이다. 악수할때 팔 뻗는 모습처럼 주인과 부속품 객체 그룹은 불공평하게 존재한다.

[그림]


덧) 아직 고쳐쓰기가 덜 되었습니다. 예를 들면 도입부는 그럴듯하게 쓰다가 실제 설명부분에서는 풀어쓰는 부분이 덜 되었습니다. 어려운 용어의 풀어쓰기가 안되었습니다. 기타 삽화가 부족함을 이해해 주시길 바라며, 향후 책에 쓰일 원천 자료이기 때문에 펌은 불허, 링크 환영 합니다. 조언 부탁드립니다. ^ ^;