패턴 저자 : 손영수, 오혜성, 양현철, 정승수

10년전에 발표한 아키텍처 시각화 패턴의 마무리 글을 올립니다.

패턴 I 회에서는  아키텍처 시각화 패턴의 전체적인 구조와 구성되는 패턴들의 종류들을 간단히 소개하고, 아키텍처 시각화를 하기 전에 소프트웨어 시스템을 분석하기 위한 기본 요소들인 Domain Level Classifier Pattern과 Class Dependency Classifier Pattern에 대해서 살펴보았다.

2회에서는 시간에는 소프트웨어 시스템의 아키텍처 분석에 기본이 되는 다양한 Metric에 대한 설명을 올렸다.

이번 3회에서는 의존성을 관리하는 시각화 지표를 설명한다.

Dependency Visualization(Chart) Pattern

Context

소프트웨어 시스템의 속하는 다양한 도메인들의 의존성(상속, 참조 등)은 소프트웨어 시스템의 심각한 아키텍처적인 문제점이나 전체적인 그림을 그려볼 수 있도록 도와주는 아키텍처 분석에 있어서 중요한 정보이다. 그렇기 때문에 앞서 소개하였던 클래스 다이어그램을 통한 분석이나 소스 코드를 통한 분석에서도 이러한 도메인들 간의 의존성을 파악하는 부분에  많은 비중을 두고 분석하게 된다. 그 중에서도 특히 클래스 다이어그램을 통한 분석은 대부분이 이러한 의존성을 중심으로 아키텍처를 파악한다고 할 수 있다. 

하지만 클래스 다이어그램을 통한 분석은 너무 넓게 바라보기 때문에 분석으로 얻을 수 있는 정보가 너무 적으며, 소스 코드를 통한 분석은 너무 깊게 바라보기 때문에 분석에 많은 시간이 걸리며 전반적인 아키텍처에 대한 큰 그림을 그리는 것이 힘들어 아키텍처를 파악하는데 있어서 부적합하다. 

Problem

• 아키텍처적인 문제점을 발견하기에 많은 시간이 필요한 클래스 다이어그램과 코드 분석 방법

클래스 다이어그램과 코드를 바탕으로 도메인간의 의존성을 분석하게 되면 소프트웨어 시스템에 내제 되어있는 상호 참조와 같은 다양한 아키텍처적인 문제점들이 바로 코드나 클래스 다이어그램에는 들어나지 않아 문제를 발견하기가 매우 어렵다. 

• 소프트웨어 시스템의 아키텍처를 가늠하기 힘든 클래스 다이어그램과 코드 분석 방법

이러한 분석 방법으로는 소프트웨어 시스템의 전체적인 흐름과 아키텍처를 파악하기에는 무리가 있다. 이는 클래스 다이어그램의 경우에는 단순히 의존성만이 나타나고, 그 의존성이 발생하는 부분이나 발생 정도에 대한 내용들을 제공해주지 않으며, 코드 수준에서는 아무런 기본 정보를 제공해주지 않기 때문에 분석자가 스스로 파악해야만 한다. 

Force

• 소프트웨어 시스템의 아키텍처적인 문제점을 직관적으로 확인할 수 있어야만 한다.
• 클래스 다이어그램이 제공해주지 않는 보다 자세한 정보들을 제공해주어야만 한다.
• 코드 수준의 분석보다는 요약된 정보를 제공해야만 한다.
• 소프트웨어 시스템의 의존성에 의한 전체적인 아키텍처를 가늠할 수 있어야만 한다.

Solution

소프트웨어 시스템 내의 의존성 정보들을 이용하여 시각화하면 분석자에게 보다 많은 정보를 줄 수 있게 된다. 의존성을 바탕으로 시각화를 하계 되면 우선 클래스 다이어그램의 기본적인 상속이나 추상화 수준 등에 정보는 기본적으로 포함하게 된다, 이 외에도 현재 소프트웨어 시스템의 전체적인 흐름을 파악할 수 있게 되고, 소프트웨어 시스템이 내부적으로 가지고 있는 크기 문제나 상호 참조와 같은  아키텍처적인 문제점을 매우 쉽게 발견 할 수 있다.

<표 6 –  각 분석 방법의 비교>

Consequences

• 소프트웨어 시스템을 적절한 범위 내에서 분석할 수 있게 된다.
• 소프트웨어 시스템의 아키텍처를 보다 빠른 시간 안에 파악할 수 있게 된다.
• 소프트웨어 시스템의 아키텍처적인 문제점들을 파악하기 쉬워진다.

Side-effects

• 소프트웨어 시스템의 의존성들이 매우 복잡해질수록 시각화를 하기 위해 많은 시간이 필요하게 된다.
• CC와 같은 복잡도나 크기 등과 같은 의존성 이외의 정보들은 분석할 수 없어 분석에 한계가 존재한다. 

Knows Uses

• CodePro AnalytiX:  구글에서 제공하는 정적 분석기인 AnalytiX에서는 각 소프트웨어 시스템의 도메인들간의 의존성을 원 형태로 배치하여 사용자의 분석을 돕는다.
• Structure 101: 아키텍처 시각화 툴인 Structure 101에서는 소프트웨어 시스템의 도메인들 간의 의존성을 바탕으로 DSM으로 표현하여 사용자의 분석을 돕는다.
• STAN4J: 아키텍처 시각화 툴인  STAN4J에서는 소프트웨어 시스템의 도메인들 간의 의존성들을 바탕으로 Digraph 형태로 표현하여 사용자의 분석을 돕는다.

Related Patterns

• Dependency Structure Matrix Pattern: Dependency 패턴을 시각화 하기 위한 서브 패턴의 하나
• Dependency Composition Digraph Pattern: Dependency 패턴을 시각화 하기 위한 서브 패턴의 하나
• Class Dependecy Classifier Pattern : 각 도메인 간의 모든 의존성에 대한 기본 데이터

5.1 Dependency Structure Matrix(DSM) Pattern

Context

소프트웨어 시스템에 존재하는 도메인(패키지, 클래스, 메소드 등)들과 이러한 요소들간의 여러 의존성들이 존재한다. 이러한 정보들은 하나의 소프트웨어 시스템에서도 매우 방대한 양을 가지고 있기 때문에 무엇보다도 이를 요약해줄 수 있어야 하며, 또한 이 내용들을 토대로 소프트웨어 시스템을 분석하고자 하는 사람은 최대한 쉽고 빠르게 소프트웨어 시스템 전체의 구성을 파악하고 문제점을 찾을 수 있어야 하므로,  이 정보들을 시각화 할 수 있는 기법이 필요하다.

Problem

• Dependency Chart 패턴을 적절하게 시각화 할 수 있는 방법이 필요하다.

앞서 Dependecy Chart 패턴을 기반으로 소프트웨어 시스템 내부의 다양한 도메인들의 의존성들을 소프트웨어 시스템을 분석하고자 하는 사람이 보다 쉽고 빠르고, 그리고 직관적으로 이해할 수 있어야 하는 방법이 필요하다.  

Force

• 소프트웨어 시스템의 도메인들의 의존성을 쉽게 파악할 수 있어야 한다.
• 소프트웨어 시스템의 아키텍처적인 문제점을 발견하기 쉬워야 한다.
• 소프트웨어 시스템의 전체적인 아키텍처를 파악하기 쉬워야 한다.

Solution

일반적으로 의존성을 시각화 하는 가장 기본적인 방법으로는 Dependency Structure Matrix (Design Structure Matrix, DSM)이 존재한다(Neeraj05). DSM은 행렬의 형태로 의존성을 시각화하여 보여주는 방법으로, 이는 기본적으로 그래프 이론에서의 그래프를 표현하는 방법 중에 인접 행렬 방식과 동일한 방식으로 시각화가 이루어진다.

<표 6 –  DSM의 예>

DSM은 위의 표와 같이 분석하고자 하는 소프트웨어 시스템의 의존성을 쉽게 파악할 수 있도록 행렬의 모습으로 전체적인 의존성을 보여준다. 이러한 DSM은 열을 기준으로 의존성을 분석할 수 있다. 간단히  예를 들자면 A열과 C행이 교차하는 지점에 2라는 값은 A요소가 C를 두번 참조(의존)한다는 의미로 비교적 직관적이고 빠르게 해석할 수 있게 된다.  또한 위의 표와 같이 소프트웨어 시스템 내부의 상호 참조와 같은 아키텍처적인 문제점이 존재할 경우 바로 알아볼 수 있다.

Implementation

DSM을 구현할 수 있는 방법들은 여러 종류가 존재 한다. 여기에서는 그 중 특정 도메인 수준에서 DSM을 시각화 하는 방법에 대해서 이야기하겠다.

• 기본 절차

1 단계: 시각화를 위한 기본 도구를 선택한다.

2 단계: Class Relationship Classifier 패턴을 기반으로 시각화 하려는 프로젝트의 의존성을 추출한다.

3 단계:  추출된 의존성 정보들 도메인 수준을 기준 도메인의 시점으로 변경한다.

4 단계: 변경된 의존성 정보들을 바탕으로 DSM을 시각화 한다.

• 예제 소스 코드(분석 대상) – 예제로 분석하고자 하는 코드는 다음과 같다.

package PackageA;

class ElementA{

ElementB b;

ElementB getElementB(){return b;}

}

package PackageB;

class ElementB{

ElementC c;

ElementC getElementC(){return c;}

}

package PackageC;

class ElementC{

ElementA getElementA(){return new ElementA();}

}

• 절차 설명

1 단계: 시각화를 위한 기본 도구를 선택한다.

제작하고 있는 아키텍처 시각화 툴에 알맞은 차트 또는 그래픽 구현 도구를 선택한다. 간단하게 웹을 이용하여 제작한다면 SVG나 HTML5의 캔버스가 될 수 있다. 시각화을 구현하기 위한 기본 도구들은 개발자가 원하는 요소들을 자율적으로 선택 하면된다. 

2 단계: Class Relationship Classifier 패턴을 기반으로 시각화 하고자 하는 소프트웨어 시스템의 도메인 간의 의존성을 추출한다.

앞서 설명한 Class Relationship Classifier 패턴을 기반으로 시각화 하고자 하는 소프트웨어 시스템 안에 존재하는 10가지의 모든 의존성들을 추출한다.  

<표 7 – 테스트 코드에서 추출된 의존성들의 예제>

3 단계:  추출된 의존성 정보들 도메인 수준을 기준 도메인의 시점으로 변경한다.

추출된 의존성 정보들의 시작요소와 도착요소의 도메인 수준을, 분석하고자 하는 기준 도메인의 시점으로 변경한다. 간단히 예를 들자면  시각화 하려는 기준이 “패키지” 단위라면 “PackageC.ElementC. getElementA” 와 같은 “패키지”단위 보다 하위에 속하는 “메소드” 단위의 정보를 기준점인 패키지 단위의 정보, 즉 “PacakageC”로 변경하여 DSM을 그린다.

4 단계: 변경된 의존성 정보들을 바탕으로 DSM을 시각화 한다.

도메인 시점을 변경한 의존성 정보들을 바탕으로 실제 DSM을 시각화 한다. 이때 의존성의 수는 변경된 의존성 정보 안에서 시작 요소와 도착 요소가 모두 같은 경우의 수를 기입한다.

<표 8 – 완성된 DSM 예제>

Consequences

• 소프트웨어 시스템의 의존성에 의한 아키텍처를 분석하기 쉬워진다.
• 소프트웨어 시스템 내부의 아키텍처적인 문제점들을 발견하기 쉽다.

Side-effects

• 소프트웨어 시스템의 규모가 커지면 분석하기 힘들어진다.
• 의존성의 정확한 종류를 파악하는 것이 불가능하다.
• 소프트웨어 시스템의 전체적인 아키텍처를 생각하기가 힘들다.

Knows Uses

• Structure 101: 아키텍처 시각화 툴인 Structure 101에서는 각 패키지나 클래스간의 의존성을 바탕으로 DSM으로 표현하여 사용자의 분석을 돕는다.

Related Patterns

• Relation 패턴: 소프트웨어 시스템의 의존성의 종류에 대하여 정의 및 추출 방식에 대한 패턴이다.
• Dependency Composition Digraph 패턴: DSM이 가지는 단점을 해결하기 위한 패턴

5.2 Dependency Composition Digraph Pattern

Context

DSM Pattern을 기반으로 Dependency Graph Pattern의 시각화하면, 우선 클래스 다이어그램이나 소스 코드 분석에 비해 아키텍처를 보다 쉽게 파악할 수 있게 되며, 해당 소프트웨어 시스템이 가지고 있는 아키텍처적인 문제들을 비교적 발견하기 쉬워 진다.

그렇지만 DSM Pattern은 분석하고자 하는 대상의 규모가 커지면 분석하기가 매우 힘들어지며 표에 나타나있는 의존성에 정확한 종류도 파악하기 힘들다.

거기다가 행렬을 기반으로 데이터를 시각화하기 때문에 분석가가 이를 기반으로 소프트웨어 시스템에 대한 전체적인 아키텍처를 직관적으로 바로 생각하기가 힘들다는 단점이 존재한다. 

Problem

• 소프트웨어 시스템의 규모가 커지면 분석하기 힘든 문제

DSM 패턴을 이용한 방법에서는 소프트웨어 시스템의 규모가 커질수록 행렬도 이에 비례하여 커지게 된다. 그렇기 때문에 분석할 도메인들이 많아질수록 살펴봐야 할 요소들이 많아지고 너무 커진 행렬 때문에 분석자체도 힘들어지는 문제를 가지고 있다.  

• 행렬 구조의 복잡함에 의한 전체적인 아키텍처를 파악하기 힘든 문제

DSM 패턴은 행렬의 의존성이 있는 요소에 숫자를 기입하는 형태로 의존성을 나타낸다. 이 방식은 하나의 요소를 중심으로 의존성들을 파악하기에는 편리하지만 소프트웨어 시스템 전체의 의존성을 파악하기에는 매우 힘든 방식이다.  

• 소프트웨어 시스템의 의존성에 대한 정확한 파악 문제

DSM 패턴은 의존성을 단순히 숫자를 통해 나타내기 때문에 의존성의 정도는 추정할 수 있지만, 그 안에 어떠한 의존성을 가지고 있는지는 알 수 있는 방법이 존재하지 않는다.

Force

• 요소(패키지, 클래스 메소드 등)들의 의존성을 쉽게 파악할 수 있어야 한다.
• 소프트웨어 시스템의 아키텍처적인 문제점을 발견하기 쉬워야 한다.
• 소프트웨어 시스템의 아키텍처를 파악하기 직관적이고 명시적이어야 한다.

Solution

소프트웨어 시스템의 의존성을 가중치를 가지는 방향 그래프 형태로 시각화하여 보여주는 방법을 활용하면 이러한 단점을 개선할 수 있다. 이는 DSM이 기본적으로는 그래프 이론의 그래프를 표시하는 방법 중에 하나인 인접 행렬에서 파생되었다는 점을 고려하여, 이를 반대로 그래프로 그리게 되면 행렬이 가지는 시각화와 관련된 단점들을 개선할 수 있게 된다. 

그리고 이러한 가중치를 가지는 방향 그래프를 시각화 할 때, 각 Vertex간의 참조에 따라서 계층 구조로 표현하여 제공한다면, 각각의 요소들의 의존성을 한눈에 확인할 수 있게 된다.

<그림 16 – 계층화 된 방향 그래프 예제>

Implementation

이 패턴을 구현하려면 다음과 같은 단계를 수행하면 된다.

• 기본 절차

1 단계: 시각화를 위한 기본 도구를 선택한다.

2 단계: DSM 패턴을 기반으로 DSM을 생성한 뒤, 그 결과를 바탕으로 가중치를 가지는 방향 그래프를 생성한다.

3 단계: 생성된 방향 그래프를 그릴 수 있는 계층화된 레이아웃을 생성한다.

4 단계: 레이아웃을 바탕으로 그래프를 그린다.

• 예제 소스 코드(분석 대상): DSM패턴의 예제 소스와 동일하다.
• 절차 설명

1 단계: 시각화를 위한 기본 도구를 선택한다.

제작하고 있는 아키텍처 시각화 툴에 알맞은 차트 또는 그래픽 구현 도구를 선택한다. 간단하게 웹을 이용하여 제작한다면 SVG나 HTML5의 캔버스가 될 수 있다. 시각화를 구현하기 위한 기본 도구들은 개발자가 원하는 요소들을 자율적으로 선택 하면 된다. 

2 단계: DSM 패턴을 기반으로 DSM을 생성한 뒤, 그 결과를 바탕으로 가중치를 가지는 방향 그래프를 생성한다.

이 패턴은 기본적으로 DSM 패턴으로 생성된 결과물인 DSM을 가지고 그래프를 생성하기 때문에, 우선적으로 DSM을 생성한다. 그 다음 DSM 정보들을 그래프를 나타내는 인접 행렬로 생각하고 가중치를 가지는 방향 그래프를 구성한다.

<그림 17: DSM을 그래프로 변경한다>

3 단계: 생성된 방향 그래프를 그릴 수 있는 계층 레이아웃을 생성한다.

생성된 방향 그래프에 대한 정보들을 바탕으로 계층 레이아웃을 생성하는 작업을 진행해야 한다. 일반적으로 방향 그래프를 계층 레이아웃을 만들기 위해서는 스기야마 알고리즘([Bastert+01])을 이용하여 레이아웃을 계산해야 한다. 그런데 스기야마 알고리즘의 경우 작업의 몇 가지 요소들이 NP-Hard 문제로 그리디 알고리즘을 기반으로 계산해야만 한다. 그렇기 때문에 계산되는 계층 레이아웃은 항상 최적해를 가지지 않는다는 것에 유의해야 한다.

4단계: 레이아웃을 바탕으로 그래프를 그린다.

생성된 레이아웃을 바탕으로 선택한 시각화 도구를 이용하여 방향 그래프를 그린다. 이 때 그래프의 Edge를 그릴 때 대표적인 의존성(상속이나 참조 등)은 클래스 다이어그램에서 정의된 기호들을 사용하여 구성한다. 

 <그림 18: 완성된 방향 그래프의 모습> 

Consequences

• 소프트웨어 시스템이 가지고 있는 아키텍처적인 문제들을 발견하기 매우 쉽다.
• 계층 구조를 이루고 있어 도메인들의 의존성을 파악하기 쉽다. 
• 대표적인 의존성일 경우, Edge의 모양을 해당 클레스 다이어그램 기호로 표시하여 직관적으로 파악할 수 있다. 
• 소프트웨어 시스템의 전체적인 아키텍처를 파악하기가 쉽다.
• 소프트웨어 시스템의 규모가 커져도 충분히 분석 가능하다.

Side-effects

• 시각화를 표시하기 위한 레이아웃 등을 계산할 때 많은 시간이 소모된다.
• 정형화 된 Chart 타입이 아니기 때문에 시각화 구현 시 어려움이 따른다.

Knows Uses

• STAN4J: STAN4J이라는 아키텍처 시각화 툴에서 Composition 이라는 뷰에서  소프트웨어 시스템의 요소들(패키지, 클래스 등)을 방향 그래프를의 형태로 소프트웨어 시스템의 의존성을 표현해주고 있다.

Related Patterns

• Class Relationship Classifier 패턴: 소프트웨어 시스템의 의존성 종류에 대하여 정의 및 추출 방식에 대한 패턴이다.

맺음

소프트웨어 구조를 시각화하는 패턴들을 설명하였다. 이 패턴을 만들기 위해서, 다양한 시각화 도구들을 분석하였으며, 제품들간의 시각화 하는 지표들의 장단점을 파악하는 계기가 되길 바란다.