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

만약 이런 질문을 하고 있는 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”의 내용을 약식 정리한 것입니다.

계속 읽기

일전에 Dependency에 대한 고찰이라는 글로, Dependency의 종류와 xDepend 툴들을 소개한 적이 있습니다.

이번 POST는 윗 글의 연장선상으로 Dependency 를 해결하기 위한 올바른 설계 방법 몇가지를 소개하고자 합니다.

물론 재미난(?) 그래프로 여러분의 시스템의 Depedency를 파악하는 것을 보여드리고 싶지만..  모든 일에는 순서가 있는 법.  여러분이 와 닿는 그림과 코드로 간단히 설명드리도록 하겠습니다.

Dependency가 없는 상태로 시스템을 구축한다는 것은 불가능합니다. 재사용의 미덕이 바로 Dependency의 또다른 이름이기도 하죠.

어떻게 하면 Dependency를 잘 관리할수 있을까?  그 해답을 제시해주신  아키텍트를 소개하고자 합니다.

그 분은 바로 Object Mentor의 Robert C. Martin 입니다.  Clean Code의 저자로써 알려져 있지만, 사실 이것보다  이름을 더 크게 알리게 한 주역은 패턴의 5가지 법칙(OCP, DIP, LIP, ISP, SRP)입니다.

그런데 이 5원칙의 빛에 가려 숨겨진 Principle이 하나 있는데요.  이름하여 패키지 구조의 원칙들 (Principles of Package Architecture) 입니다.

이 논문에서 Dependency를 깨거나 완화하는 방법들을 여러분에게 소개하고자 합니다.

계속 읽기

depend (출처 - farm2.static.flicker.com)

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

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

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

계속 읽기