어디가 꼬여 있는거야? 누가좀 가르켜줘 – Dependency Structure Matrix

11월 2, 2009 — arload

내가 설계한 시스템을 과연 개발자가 잘 만들고 있을까?   제대로 된 방향으로 가고 있을까?   우리 시스템이 어디가 꾜여있진 않을까?  진척율을 짝짝 올라가 양은잘 맞추는거 같은데..?

만약 이런 질문을 하고 있는 Architect나 Senior Software Engineer라면, 중간  상황을 어떻게 파악하시나요? 완벽한 대답은 아니지만 최소한 제대로 Architecting의 흐름이 흘러가는지 파악하는 좋은 툴중 하나인  DSM (Dependency Structure Matrix) 을 소개드리고자 합니다.

일전에 Dependency의 종류를 설명한 Dependency 대한 고찰 과  Dependency를 해결하는 방법을 소개한 Dependency 를 관리하는 방법 사이에 있는 포스트로,  바로 Dependency가 어디에 있는지 분석하자는얘기입니다. 문제 제기와 해결책은 제시했는데, 사실 Dependency를 파악하는 방법에 대한 이야기를 전해드리지 못했습니다.  이제서야 이야기를 꺼내게 되네요.

이 포스트는 2005년 OOPSLA에서 발표된 Paper인 “Using Dependency Models to Manage Complex Software Architecture”의 내용을 약식 정리한 것입니다.

DSM 살펴보기

먼저 간단한 DSM을 하나 살펴보겠습니다.

Task A부터 D까지 있구요. Task는 Namespace가 될수도 있고, Class가 될수도 있습니다. 뭐 서로간에 Depedency를 가질수 있는 거라면 뭐든지 될수 있습니다.

DSM을 읽는 방법은 열을 기준으로 읽으시면 됩니다.   “1번은 3번에 Dependency(의존성)을 가진다 , 3번은 1번, 2번에 의존성을 가진다” 라고 읽으면 됩니다.

그럼 4번은??  다 아시겠죠. 4번(Task D)은 1번(Task A)과 3번(Task C)에 의존성을 가진다는 거죠.   다 아시겠죠!!.  이제 반이 끝났습니다. 이게 다거든요 🙂

자 그럼 여기서 넘어가지 말고 하나를 좀더 자세히 볼게 있습니다. 검은색을 기준으로  포개어 보면 서로 마주보는 것이 하나 있습니다.  바로 1번의  TASK A가 TASK C에 의존성을 가지는 것 과  3번의 Task C가 Task A에 의존성을 가지는 것입니다.

바로 Circular Depdency가 발생했다는 겁니다.  뭔가 구조가 문제가 있다는 거죠. A가 바뀌면 B가 바뀌고 B가 바뀌면A가 바뀌는 돌고 돌면서 변화를 전파하는 구조가 있다는 겁니다.    뭐 해결 방법은 이미 이전에 언급한 것처럼  새로운 패키지를 생성하거나  간접적인 참조인 경우 Interface로 중개자 역할을 하게 하는 방법을 사용하시면 됩니다.

DSM으로 보는 잘 설계된 Layering , 그렇지 못한 Layering

Dependency 문제를 해결하는 방법은 바로  Layering 입니다. 계층화를 시켜서 전파를 국지적으로 만드는 것이지요.

위  그림에서 보는 것과 같이 WPF가 BCL(Base Class Library)를 참조하는 것, 즉 아래 Layer를 참조하는 것은 좋습니다.  하지만 Reflection이 XML을 참조하는 것은 하위 Layer에서 상위 Layer를 참조하기 때문에, Circular Dependency를 발생시킬 가망성이 많습니다. 그러니 이러한 것은 피해야 겠지요.

그리고 WPF가 XML이 같은 동등한 레이어 있다면 이들을 어떻게 관리해야 할까요?   같은 Layer에 있는 녀셕들도 SubNamespace로 만들어 의미적으로 명확하게 그룹화하여 구분하는 것이 좋습니다.

예전에도 언급한것 처럼  Namespace의 주 목적은 같은 이름을 가진 타입들의 충돌을 해결하고자 하는 것이 아닙니다. Namespace의 주 목적은  응집력 있고, 쉽게 찾을수 있으며, 쉽게 이해할 수 있는 계층구조로 타입들을 구성하는 것입니다.

자  application, model, domain, framework, util 순으로 layer 구조로 설계된 시스템이 있다고 합시다.  DSM으로 분석을 하니 아래와 같은 형태로 Metrix가 나왔다고 합시다.

Layer 구조가 잘 지켜진 시스템이라고 할수 있습니다.  application은 자신의 하위 Layer인 model, domain, framework, util를 참조하는 것을 알수 있습니다.  model 역시 자신의 하위 레이어를 다 참조하고 있죠.    물론 util과 같은 공용 라이브러리가 변경되면 다 영향을 미치지만, 최소한 순한 참조는 없으니깐요.

하지만 여러분이 좀더 엄격하게 N번째 Layer는 N-1 번째 Layer만 접근할수 있게 Architecture를 잡았다면,  여러분의 시스템은 이렇게 나와야 될겁니다.

application은 model만 참조하고, model은 domain만 참조하는 형태로 만듦으로써, 변화를 국지화할수 있는 좋은 장점을 얻었습니다. 공용 libray 성의 util 이 바뀌더라도, 그 변화를 framework가 흡수할 수 있기 때문에, 좋은 구조라고 할수 있습니다. 하지만 실제 이렇게 구현하기가 그리 쉽지 않습니다. 우리가 예측하지 못한 기능을 application에 구현할려고 하는데, 만약 필요한 기능이 util에 있다면, 결국 framework, domain, model을 거쳐서 그 기능을 제공해야 하므로, 그리 쉽게 구축하기 어렵습니다.    물론 잘하시는 분도 있겠지만요. 🙂

여튼 위의 두 DSM만 봐도 전형적인 Layer 구조를 가진 것을 알수 있고, 잘 구조가 잡혀서 개발 된것을 알수 있습니다.  DSM을 주기적으로 체크하면서 보는데 어느날 이런 형태의 Metrix를 보게되었다면, 여러분은 어떻게 해야 할까요?

util에서 application과 model을 쓰는 즉 하위 레이어에서 상위레이어를 참조하는 상황이 발견된겁니다. 여러분은 어서가져서 누가 util 쪽 라이브러리를 변경하여, application, model에 영향을 미쳤는지 파악해서,  형상 관리 시스템을 통해 담당자를 알아낸 후 왜 이럴수 밖에 없었는지 자세히 애기를 나누어야 합니다.  그리고 직접적인 순환 참조인 경우 새로운 패키지를 생성하고, 간접적인 참조인 경우 Interface로 중개자 역할을 하게 하는 방법을 제시해야겠죠.

그리고 또 주의해야 될 상황으로 chagne propagator 를 주의깊게 다루어야 합니다.

project namespace에는 class들이 존재합니다.  project namespace를 자세히 보면 모든 class가 Project라는 class를 참조하고 있습니다.  그리고 골치아프게 Project 역시 다른 class를 다 참조하고 있는 순환 참조가 발생했습니다.

그런데 자세히 보면 더 큰 문제가 숨겨져 있습니다. 6번 ProjectLoader를 보시길 바랍니다. ProjectLoader는 다른 subnamespace인 services를 참조하고 있습니다.

이 말뜻은 services 에서 어떠한 변화가 발생하여 ProjectLoader에 영향을 미치면, ProjectLoader는 다시 Project Class에 영향을 미치게 되고,Project Class를 참조하고 있는 다른 모든 Class에게도 영향을 미치게 됩니다.  결국 하나의 변화가 파문을 일으키며 변화는 Ripple Effect가 발생하게 되지요.

이러한 일이 발생하지 않게 최소한 ProjectLoader가 Services의 모듈을 참조하지 않게 만들든 또는 Project가 ProjectLoader를 참조하지 않게 만들어야 할 것입니다. 이러한 것은 DSM을 보기만 해서 파악하기 힘들 것이고, 역시 아키텍쳐적인 측면을 고려해서 담당자들과 협의하여 결정해야 겠지요.

구현체로 보는 DSM

그럼 실제 구현되어 있는 제품으로 한번 DSM을 바라 보겠습니다.

위 그림은 JUnit의 DSM입니다. 순환 참조도 없고, 아주 깔끔한 구조이네요. runner와 framework이 하위 layer로 사용되고 있으며, 엄격한 layered 구조는 아니지만 아주 잘 만든 구조라고 볼수 있습니다. 사실 엄격하게 N Layer가 N-1 Layer만 접근한다는 것은 쉽지 않거든요.

이 그림은 JEdit 의 모습입니다.  보시다시피 순환 참조가 눈에 뛰게 보입니다.  Ant도 역시  여러분의 기대와는 다르게 실망스러운(?) DSM이 보입니다.

자  그럼 여러분에게 재미난 DSM을 하나 보여 드리겠습니다. 바로 .NET Framework 2.0의 DSM입니다. 이미지를 클릭하시면 좀더 큰 이미지를 보실수 있습니다.

노란색은 순환 참조 (Circular Dependency)를 의미하는 걸로, 상당히 많은 .NET 개발자들이 실망(?)했으리라 생각이 듭니다.    자 그럼 Depedency가 많은 것을 하위로 내리는 Partition을 적용한후 다시 DSM을 보도록 하죠 🙂

Partition을 한후 보면 Web, Media, Drawing과 같은 상위적인 Layer 성격이 강한 Namespace 들이  Colllection, Globarlization, IO, Security등과 같은 Common한 라이브러리 (공용부) 성격이 강한 것을 참조하고 있음을 알수 있습니다.  즉 같은 SubNamespace군으로 여러개를 나누었지만, 내부적으로는 Layer와 같이 Provider 성격이 강한 녀석과 Consumer 성격이 강한 Namespace로 분류될 수 있다는 것입니다.

사실 Framework는 일반 상위 Application과는 전혀 다른 성격을 가지고 있습니다. 예전 포스트(인기있는 Framework를 만들고 싶다면)에서 언급한 것 처럼   프로그래머가 사용하기 쉽고, 학습시간도 짧아야 하고, 직관적이어야 하는 등 다른 요소들도 고려해서 설계되는 것이 Framework의 인기와 직결되기 때문입니다. 특히 .NET Framework와 같은 범용적인 Framework에서는요. 직관적이고, 사용성을 높게 하기 위해,  1.0을 고스란히 버리고 2.0을 처음부터 다시 설계해서 만든 만큼  그리 실망은 하지 않으셔도 될듯 합니다.

제가 추천하는 Dependency를 측정하는 기능으로만 따지면, 가장 강력한 툴로는 NDepend, XDepend (Java용 JDepend보다 훨 좋음. NDepend의 Java 버젼), CppDepend 를 추천해 드립니다.   NDepend 사이트에 들어가셔서 링크만 좀 보셔도 왜 그런지 이해가 가실것 같습니다.

가능하다면 이렇게, 저처럼 DSM과 같이  Code Metrics도 병행해서 사용하시길 권해드립니다.  사실 위 툴에 다 포함되어 있습니다. 전 돈이 없어서 Reflector Add-in으로 만족하고 있습니다.

많은 분들에게  저의 부족한 지식이 도움이 되길 바라며, 다른 기법들을 알고 계신 분들은 지식을 나누어주시길 부탁드립니다. 가능하다면  Trackback (https://arload.wordpress.com/2009/11/02/dependency-structure-matrix/ )걸어주시면 감사하겠습니다. 지식은 나누어야 커지잖아요 🙂