Extremely Agile/UML2007. 10. 27. 00:19

I. UML 컴포넌트

UML 컴포넌트 다이어그램을 구성하는 하나의 컴포넌트는 컴포넌트와 거기에 붙은 여러개의 인터페이스로 그릴 수 있습니다. 인터페이스는 provided interface와 required interface의 두 종류로 나뉘는데, 전자는 그 컴포넌트가 제공하는 인터페이스이고, 후자는 다른 컴포넌트가 제공하는 인터페이스를 사용한다는 의미입니다. 그러니까 어떤 컴포넌트 입장에서 봤을 때 제일 중요한 인터페이스는 provided 인터페이스인 셈입니다. 컴포넌트 다이어그램을 그리는 사람 입장에서도 그렇습니다. 그 다이어그램을 그리는 사람은 어떤 인터페이스가 어떤 컴포넌트에 속해야 하는지가 가장 뚜렷이 드러나도록 다이어그램을 그리려고 할 테니 말이죠.

사용자 삽입 이미지
 

이렇게 달랑 컴포넌트 하나만 놓고 설명하는 건 좀 심심하니까, 이번에는 컴포넌트가 여러개 등장하는 컴포넌트 다이어그램을 보도록 하겠습니다. 보시다시피 컴포넌트의 인터페이스 간에는 의존성 관계가 있습니다. 그 방향은 언제나 일정하죠. provided interface 쪽으로 화살표가 가게 되어 있습니다. (뭐 당연한 일이겠죠?)

컴포넌트 다이어그램

컴포넌트 다이어그램 - 누르면 커집니다



II. UML 컴포넌트의 인터페이스

그런에 위의 그림을 잘 보면, 인터페이스의 이름이 마치 자바 클래스나 자바 인터페이스의 이름과 비슷하게 만들어져 있다는 것을 보실 수 있을 겁니다. 그렇다면 저 동그라미 하나는 하나의 자바 인터페이스에 대응되어야 하나요?

흔히 컴포넌트 인터페이스를 정의할 때, 그 인터페이스가 가지는 역할을 중심으로 인터페이스 이름을 결정합니다. 해당 인터페이스를 호출하면 해당 컴포넌트가 어떤 종류의 역할을 수행하게 되는지를 중심으로 인터페이스 이름을 결정한다, 뭐 그렇게 생각해도 되겠죠.

그런데 문제는 그런 식으로 정해진 인터페이스가 꼭 자바 인터페이스 하나에 대응되는 것은 아닐 수도 있다는 것이죠. 자바의 인터페이스/클래스를 어떻게 나눌 것이냐 하는 문제는 단순히 '역할'이라는 하나의 관점만 사용해서는 풀기가 좀 힘듭니다. "UML, 실전에서는 이것만 쓴다"라는 책의 클래스 다이어그램 부분을 읽어보면 짐작할 수 있는 사항입니다만,  클래스들을 나눌 때에는 "의존도를 최소화해야"하고 "변경을 국지화해야 한다"는 등의 원칙들이 강하게 작용하거든요. 그러니 위의 그림에서 볼 수 있는 RequestAdmissionInterface 같은 것은 사실 그 인터페이스를 사용하는 외부 컴포넌트가 두 개 이상일 경우에는 역시 두 개 이상의 자바 인터페이스에 의해 모델링 될 수가 있습니다. 그렇다면 이렇게 정리하면 되겠군요.

하나의 컴포넌트 인터페이스는 하나 이상의 자바 인터페이스에 대응될 수 있다 



이 말이 어쩐지 좀 이상하게 들린다는 분들은 Enterprise Architect같은 UML 툴을 한 번 써 보시기 바랍니다. 실제로 저 동그라미 하나에 하나 이상의 자바 인터페이스 (혹은 C++ Abstract 클래스) 에 대한 '링크'를 만들어 넣을 수가 있습니다.

이런 관점은 애자일 적으로 봐도 유효합니다. 컴포넌트 다이어그램을 그리는 단계에서는 컴포넌트 안에 무슨 클래스들이 만들어질지 모르는 경우가 허다한데, 인터페이스 클래스의 이름까지 고정적으로 붙여버린다는 것은 솔직히 너무한 일 아니겠어요?

그렇게 본다면 위의 컴포넌트 다이어그램에서 RequestAdmissionInterface같은 이름은 어쩐지 이상하군요. 꼭 자바 인터페이스 같은 뉘앙스를 풍기니 말이죠. 그냥 Request Admission Interface같이 띄어쓰기를 해 주는 편이 더 낫겠어요.


참고문헌

"UML, 실전에서는 이것만 쓴다" (인사이트)

이 글은 스프링노트에서 작성되었습니다.


Posted by 이병준

소중한 의견, 감사합니다. ^^