What is a DSM?

DSM은 Dependency Structure Matrix 혹은 Design Structure Matrix 를 일컫는 용어로써 사용됩니다. 시스템의 연관관계를 가시적으로 보여주기 위한 하나의 표현방법입니다. 1968년 Donald Steward에 의해 고안된 이래, 메사추세츠 공과대학, 하버드대학, 일리노이대학 등의 많은 대학에서 연구가 계속되어, Boeing, Lockheed Martin, Intel등의 기업에 의해 복잡한 시스템을 이해하기 위한 실용적인 방법으로써 활발하게 사용되었습니다.
Lattix사는 DSM을 소프트웨어 아키텍쳐 분석에 적용한 최초의 회사이며, 소프트웨어 아키텍쳐의 구조분석을 행해, 서브시스템간의 의존관계를 간결한 표 형식(매 트릭스)로 표현합니다.

Initial DSM

아래 그림은 Module A, Module B, Module C, Module D의 4개의 하위 시스템으로 구성된 시스템을 표현하기 위한 DSM 을 나타냅니다. 매트릭스의 X축과 Y축은 순차적으로 열거된 동일한 시스템을 표현합니다.

dsm_01

각각의 하위시스템의 연관관계가 각 행으로부터 표시됩니다. 1번 행에서 보듯이 모듈 A는 모듈 C와 7의 강도로 의존관계를 갖습니다. 또한 그림에서 알 수 있듯이 모듈 A는 모듈 B, 모듈 D는 의존관계가 없으며, 의존관계를 나타내는 셀이 비어있는 형태로 표시됩니다. 편의상 연관관계의 대칭을 기준선은 “.”를 포함하여 표시합니다. DSM의 의존관계는 다음의 항목들을 설명합니다.

  • Module A는 Module C 에 의존하고 있다.
  • Module B는 다른 모듈에 의존하고 있지 않다.
  • Module C는 Module A 및 B에 의존하고 있다.
  • Module D는 Module A 및 C에 의존하고 있다.
Reordering the DSM

우리는 이제 Module A-C 라는 하위시스템을 만들어 Module와 C를 결합할 수 있습니다.

dsm_02

소프트웨어 시스템의 구조를 DSM 을 이용하여 표현하는데 있어서 Lattix의 혁신기술은 대규모의 구조를 관리하고 표현하는데 초점이 맞춰져 있습니다. 우리가 “Module” 이라고 불러왔던 것이 추상적으로 간단하게 표현되는 것에 주목하여 주시기 바랍니다. 그것은 수천개 이상의 class를 가지고 있는 대규모의 시스템을 한 개의 class 혹은 몇 개의 큰 덩어리로 간단하게 표현될 수 있음을 의미합니다.

Top Level View of DSM

우리는 이제 Module A-C 시스템을 축소시킬 수 있습니다. 더 이상 Module A 와 C를 고려할 필요가 없습니다.

dsm_03

Module D는 Module A와 Module C 에 대해 모두 의존관계를 갖고 있으므로, Module A-C인 두 Module의 집합에 대해서도 의존관계를 갖습니다. Lattix LDM은 기본적으로 집합간의 의존관계를 표현하여, 간략하게 보여줍니다.

요약: 이상으로 간단하게 matrix 변환작업을 수행하였습니다. 이러한 변환들은 하위시스템간의 의존관계에 의해 유도됩니다. 처음에 우리는 Module A, B, C 그리고 D의 4개로 이루어진 시스템에서 시작하였으며, Module A 와 C는 Module A-C의 집합으로 재구성 하였습니다. 게다가 특별한 방법을 통해 Module B를 최하위 계층의 구조로 재 정렬하였습니다. Module A-C는 Module D의 종속관게를 이루며 Module D는 의존관계를 갖습니다.

The systems engineering community 의 http://www.dsmweb.org/ 를 통해서 History 와 DSM 사용법에 대해 더 많은 정보를 확인하실 수 있습니다.

Design Rules : The Key to Managing Architecture

DSM 표현법은 소프트웨어 시스템의 architecture 에 대한 “청사진”이라고 할 수 있습니다. DSM의 각 cell은 설계자의 디자인 의도를 나타냅니다. 디자인 규칙이란 간단히 말해서 의존관계를 허용할 것인가? 그렇지 않을 것인가에 대한 결정입니다.

하위시스템이 존재하는 다음의 matrix에서 하위시스템은 서로 독립적이거나, 의존관계를 갖고 있습니다. 이 framework는 이미 이전의 디자인 규칙을 통해 구현할 준비가 되어 있습니다. 잠정적으로 디자인규칙은 하위시스템에 적용되어 있으며, 그것을 포함하는 모든 하위시스템에 의해 상속되어 있습니다. Lattix는 DSM의 각 cell을 click 하는 간단한 동작에 의해 각 시스템에 광범위한 디자인 의도를 정의할 수 있습니다. 이것은 개발자가 의도하지 않게 architectural violation 을 일으킬경우, 고지하거나 강제할 수 있습니다.

dsm_04
아키텍트가 DSM을 사용하는 이유는 다음과 같습니다.
의존관계 Cycle (상호참조) 의 최소화

특히 큰 서브 시스템 간의 의존관계 Cycle을 최소한으로 합니다. 이것은 하위 block 또는 Block Triangular 로 시스템을 구성하려고 하는 DSM으로 볼 수 있습니다.

Build Process를 최적화

현재의 jar파일의 구조를 어떻게 리팩토링 하려면, Module 화를 개선할 수 있는지, 혹은 build performance를 개선할 수 있는지를 파악합니다.

Layered구조를 보수

시스템의 계층은 Block Triangular표현으로 볼 수 있습니다. 아래의 간단한 예제는 4개의 계층이 있습니다. Module E가 제일 위에 있고, Module A와 C가 그 아래 레벨을 형성하며, Module D는 세번째 층을 형성하고, Module B는 아래 Level에 있습니다.

dsm_05
Component의 독립성의 확보

Component, 즉 모듈식의 서브시스템은 Block Diagonal 폼으로 표시됩니다. Component의 독립성은 제품 라인의 Architecture 에서는 매우 중요합니다.

외부 라이브러리의 사용관리

외부 라이브러리의 사용을 추적하여, 적절한 물리적 계층화가 행해지고 있는지 여부를 조사하고, 인가된 라이브러리만이 사용되고 있는지를 확인합니다.

부속 시스템들간의 복잡한 의존, 종속관계의 발견

외부에서 참조하는 미들웨어 (데이타베이스 액세스를 위한 jdbc와 odbc등)의 사용 형태와, 내부에서 사용하는 라이브러리의 사용 형태를 동시에 관찰함으로써 이들 리소스를 사용하고 있는 잠재적인 복잡한 의존관계를 발견합니다. 여러 개로 중첩된 의존, 종속관계가 이러한 복잡한 관계성을 보여줍니다.

DSM을 이용한 디자인규칙의 적용

Lattix를 사용하여 architecture 의 설계를 확인 및 수행하는 디자인규칙을 작성할 수 있습니다. 설계자는 디자인규칙을 작성하기 위해, 부속시스템간의 의존관계의 규칙을 표현할 수 있습니다. 디자인규칙에 위반하는 의존관계에는 자동적으로 플래그가 세워집니다. 시간이 지나면 소프트웨어는 열화하기 시작한 것처럼 보이는데, 이 현상의 가장 일반적인 원인의 하나는 예기치 못한 의존관계와 상호관계입니다. 디자인규칙은 시스템이 상호관계를 바르게 유지하는 것으로 소프트웨어 아키텍트가 열화가 아닌 진화할 수 있도록 도와줍니다.

dsm_06
  • 녹색 플래그 : 의존관계 정상
  • 황색 플래그 : 의존관계가 있어서는 안됨.
  • 적색 플래그 : 디자인규칙 위반