요즘 소프트웨어가 갈수록 거대해지면서 소프트웨어 통제에 대해 많은 애기를 들을수 있습니다. 그리고 소프트웨어 통제를 들어보신 분이라면, xDepend 라는 툴은 한번쯤 들어보셨을 겁니다.

이번  post는 아키텍쳐 설계시 dependency는 무엇이고 어떠한 종류가 있는지 설명하고, dependency를 관리할때 유용한 Layering과  xdepend 툴에 대해서 소개해 보는 시간을 가지겠습니다.

의존성 (dependency)을 어떻게 관리하느냐에 따라 여러분이 가진 시스템이 쉽게 확장가능한지 (변화에 쉽게 대처 가능한지)를 파악할 수 있으며, 이러한 추세를 반영하여 요즘 쉽게 패키징 할수 있는 단위로 시스템을 구축하는 것에 대해 많은 연구가 진행되어지고 있습니다.

Dependency Managment 관점에서의 Component.

전통적인 CBD 입장에서 보는 재사용 단위로써의 Compoenent가 아닌, 의존성 관리 측면에서 Component라는 단어를 정의할 필요가 있습니다. 위 논문에서나 Dependency를 관리하는 입장에서는 Component를 배포의 단위로 이해하는 것이 좋습니다.

하나의 Unit으로써 배포되어질수 있고, 계속해서 요구사항들을 수용하며 발전할수 있는 타입들의 하나의 집합을 Component라고 보시면 됩니다. 그리고 이러한 타입들을 여러개의 Component들로 구성하는 절차들을 Componentiation (컴포넌트 화) 라고 이해하시면 될듯 합니다.

Dependency의 종류들

• API Dependency (Surface Dependency)

Component A가 Component B 에 의존성을 가지는 경우를 말합니다. 좀더 쉽계 예를 든다면, 컴포넌트 B에 있는 어떤 타입들을 컴포넌트 A의 파라메터나 리턴 값과 같이 표면(surface)에 누구나 접근할 수 있게 노출시킨 경우 API Dependency가 생겼다고 합니다.  다른 것과 구분해 Surface Dependency라고 이해하는 것이 좀더 쉬울듯 합니다.

Interface, Parameter, Return Type, Attribute, Nested Type 이 API Dependency의 좋은 예 입니다.

• Implementation Dependency

이것은 위 API Dependency와 구분해, Implementation에 의존성을 가진 경우입니다. 표면에 다른 컴포넌트의 Type들이 노출된 것은 아니지만, 내부적으로 Type을 사용하거나, 메소드를 이용하 경우를 말합니다.

내부적으로 Hard Dependency와 Soft Dependecy로 나뉘는데 Hard Dependency는 시스템이 동작하기 위해서는 필수적인 요소가 Dependency를 가질때를 , Soft Dependency는 Optional할때를 의미합니다.

• Circular Dependency

Component A가 B를 의존하고 B가 다시 A를 의존하는 경우를 말합니다. 몇 단계를 거쳐 간접적으로 발생하는 것도 당연히 포함됩니다.  꼭 피해야 되는 Dependency입니다.

Dependency를 관리하는  좋은 방법 – Layering

Dependency를 가장 쉽게 관리하는 일반적인 방법은 Layering 입니다.

하나의 Layer로 연관있는 Component를 묶음으로써 응집도를 높일수 있고, Encapsulation 시킴으로써 다른 Layer간에 변화에 대한 충격을 완화함으로써, 효율적으로 Dependency를 관리할 수 있습니다.

그럼 Layering을 하기 위해 가지는 룰들에 대해서 알아보도록 하죠. 가장 중요한 룰은 Circular Dependency 를 피해야 된다는 것입니다.

하나의 컴포넌트안에 있는 타입들끼리는 자유롭게 서로 Dependency을 가져도 됩니다.  종속성이 컴포넌트 안에서만 발생하기 때문에, 어떠한 변화도 Component  내부적으로 처리가 가능하기 때문입니다.

하지만 컴포넌트 간에 Dependency들을 유의깊게 다루어야 합니다.

• 컴포넌트가 하위 레이어에 있는 컴포넌트에 Dependency를 자유롭게 가져도 된다.
• 컴포넌트가 상위 레이어로 Dependency를 가지는 것은 피해야 됩니다.
• 같은 레이어의 컴포넌트간에 Dependency 역시 조심스럽게 관리되어야 합니다.

상위 레이어로 Dependency가 생긴다는 것은 잠정적으로 Circular Dependency가 생길 가망성이  높다는 것을 의미합니다.  당연히 피해야 겠죠

같은 레이어간의 컴포넌트 역시 Circular Dependency 마찬 가지입니다. 이것을 통해 확장성, 유연성을 잃어버릴수 있을뿐만 아니라, 하나의 변화로 인해 모든것에 영향을 미치는 change propagation 을 최소화 시키는 것이 중요합니다.

Circular Dependency에 대해서 자세히 언급한 포스트( Cyclic Dependency )를 찾았습니다.    한번 읽어 보시길 권해드립니다.

Dependency를 검사하기 위한 좋은 툴들

가장 좋은 것은 많은 중복이 발생하지만 않는다면, 의존성 (Dependencies)를 최소화하는 것입니다.  이러한 의존성관계를 잘 파악하기 위해 xDepend(JDepend,NDepend)라는 툴이 나왔습니다.

이러한 툴의 도움으로 의존성을 파악하는 일들이 좀더 수월하게 되었고, Architect는 시스템이 제대로 설계되어 가는지 점검을 할수 있는 유용한 툴입니다.

툴에 대한 자세한 정보는 아래 Post를 통해서 살펴 보시길 바라며,

• JDepend를 통한 의존성 검사
• NDepend에 대한 간략한 소개

JDepend는 무료 이며 http://www.clarkware.com/software/JDepend.html#download 를 통해 다운 받으실수 있으며, NDepend (http://www.ndepend.com)는 상용버젼으로 opensource/academic/trial edtion을 통해서 무료로 사용하실수 있습니다. 물론 약간의 기능적인 제약은 있습니다.

더구나 NDepend는 JDepend의 기능을 기반으로 더 여러가지 확장적인 기능을 제공합니다. 가장 핵심이 CQL이라고 할수 있는데요. SQL과 같은 쿼리로 Dependency를 파악할 수 있는 장점을 가지고 있습니다.

Scott Hanselman 씨가 직접 작성하시고 공개하신 ndepend metrics 도표를 여러분과 같이 나누면서 글을 맺고자 합니다.