sw아키텍처 참조모델 -...

SW 아키텍처 참조모델

소프트웨어 구조의 평가 및 개선을 위한

소프트웨어 아키텍처 분석

[Version 1.0 20140324]

SW공학센터

SW공학기술팀

SW아키텍처 실무자 포럼 모바일 분과

SEC-2014-RM005

Copyright(c)2014 by SW공학센터

p

소프트웨어 아키텍처 참조모델(아키텍처분석 분과)

3

본 문서는 국내 기업의 소프트웨어 품질 및 생산성 향상을 지원하기 위하여 작성되었

습니다.

본 문서는

미래창조과학부 산하

정보통신산업진흥원 부설

SW공학센터

SW아키텍처 실무자 포럼

에서 작성되었습니다.

SW공학센터는 SW제품 생산능력 향상, SW공학기술 산업현장 적용 등을 위해 대학 및

전문 연구기관과 기업 현장을 연결하는 중심 허브가 되어 SW개발 중소기업들에게 전문

컨설팅을 제공하고 있습니다. 이 같은 역할을 충실히 수행하기 위해 산업과 기업의 SW

공학기술 관련 요구사항에 전문적이고 신속한 대응을 할 수 있는 핵심 기능 연구와 SW

개발 프로젝트의 성공 여부와 문제점을 미리 예측하여 SW품질과 생산성, 제품결함 등을

총체적으로 진단 할 수 있는 SW공학 컨설팅 등도 추진하고 있습니다. 이와 더불어 SW

품질과 생산성, 비용 등을 체계적으로 추적 평가할 수 있는 데이터 수집체계도 강화하여

SW기업들이 이를 손쉽게 활용하게 함으로써 전체적인 국가 SW품질을 향상시키는 업무

도 수행중입니다.

본 문서의 모든 권리는 SW공학센터가 가지고 있습니다. 문서의 내용을 이용하거나 활

용할 시에는 반드시 SW공학센터의 출처를 밝히고 사용하여야 합니다. 본 문서의 내용을

공공의 증진이나 내부의 품질 향상을 위한 용도 이외의 상업적 목적으로 사용할 시에는

필히 사전에 SW공학센터의 허가를 받아야 합니다.

사전에 SW공학센터의 허가를 받거나 논의하지 않은 모든 형태의 책임에 대하여 SW공학

센터에서는 보증하지 않습니다.

본 지침에 대한 더 많은 정보와 SW공학에 대한 추가 정보를 얻고 싶다면, SW공학센터

홈페이지(www.software.kr)를 방문하여 주십시오.

담당자 강승준 책임 [[email protected], 02-2132-1344]


4 SEC-2014-RM005

이름 경력 비고

손영수 분과장

NHNNEXT 교수

[email protected]

소프트웨어 공학과 아키텍팅을 국내

개발자들에게 널리 알리기 위해 노력하고

있으며, NHNNEXT 에서 소프트웨어

아키텍팅과 모바일을 가르키고 있다.

국내 최초의 패턴 전문가 Hillside 그룹의

이사회 위원이며, 아시아 패턴 학회인

AsianPLoP 의 공동 의장이다..

- 소프트웨어 마에스트로 멘토를 포함한

다양한 멘토링 경험과 다수의 공모전 수상.

- 한국 공개 SW 포럼 인력양성 분과장

- AsianPLoP 공동의장.

- PLoP 이사회 Hillside Group Board

Member

- PLoP (소프트웨어 패턴학회) 인증 소프트웨어

패턴 저자 활동 및 다수의 패턴 발표.

- 소프트웨어 공학 커뮤니티 EVA 10 년간

운영.

양현철

URQA Committer

[email protected]

2013 대한민국 소프트웨어 마에스트로

(NIPA)로 인정받았으며 패턴학회 PLOP에서

아키텍처 시각화 패턴 논문을 기고하였다.

현재 UrQA 커미터로 활동 중이다.

-2013 소프트웨어 마에스트로

-소프트웨어 아키텍쳐 분석기 STANly 제작

-모바일 버그 리포트 서비스 UrQA 커미터

-현 KAIST 석사과정

정승수

드래곤 플라이

[email protected]

소프트웨어 마에스트로 3 기 연수생으로

활동하면서 PLOP 에 아키텍처 시각화 패턴

논문을 기고하였다.

아키텍처와 관련하여 관심이 많으며 현재는

게임회사에 재직중이다.

-소프트웨어 마에스트로 3 기 연수생

-마이크로 소프트웨어 패턴 관련 기고

Plop2013 아키텍처 시각화 논문 기고

드래곤 플라이 재직

오혜성

이스트 시큐리티

[email protected]

소프트웨어 마에스트로 3 기 연수생으로

활동하면서 PLOP 에 아키텍처 시각화

패턴 논문 기고하였다.

서버 및 웹 프로그래밍 분야에 관심이

많다.

현재는 IT 기업에 재직중이다.

-소프트웨어 마에스트로 3 기 연수생

-마이크로 소프트웨어 패턴 관련 기고

Plop2013 아키텍처 시각화 논문 기고

이스트 소프트 재직

분과원 소개

p


5

목 차

제 1 장 소프트웨어 아키텍처 분석 ·························································································· 7

제 1 절 소프트웨어 아키텍처 개요 ·································································································· 7

제 2 절 소프트웨어 아키텍처 분석 목적 및 배경 ········································································· 9

제 3 절 소프트웨어 아키텍처 분석의 장점 ·················································································· 12

제 2 장 소프트웨어 아키텍처 정방향 분석 ·········································································· 15

제 1 절 소프트웨어 아키텍처 정방향 분석 개요 ········································································· 15

제 2 절 소프트웨어 아키텍처 정방향 분석의 목적 ····································································· 16

제 3 절 소프트웨어 아키텍처 평가/분석(ATAM) ······································································· 16

제 3 장 소프트웨어 아키텍처 역방향 분석 ·········································································· 22

제 1 절 소프트웨어 아키텍처 역방향 분석 개요 ········································································· 22

제 2 절 소프트웨어 아키텍처 역방향 분석의 특징 ····································································· 25

제 3 절 도메인 분석을 활용한 소프트웨어 아키텍처 분석 ······················································· 27

제 4 절 지표를 이용한 소프트웨어 아키텍처 분석 ····································································· 35

제 5 절 시각화를 활용한 소프트웨어 아키텍처 분석 ································································· 70

제 6 절 소프트웨어 아키텍처 역방향 분석 정리 ···································································· 112

제 4 장 도구를 활용한 소프트웨어 아키텍처 분석 ··························································· 113

제 1 절 STAN4J ····························································································································· 113

제 2 절 Metrics ····························································································································· 130

제 3 절 CodePro Analytix ··········································································································· 136

제 4 절 CppDepend ····················································································································· 154


6 SEC-2014-RM005

제 5 장 소프트웨어 아키텍처 분석 결과의 활용 ······························································· 164

제 1 절 아키텍처 분석 결과 활용을 위한 대상 선정 ······························································· 164

제 2 절 공개 소프트웨어 아키텍처 분석 결과의 활용 ····························································· 165

제 3 절 공개 소프트웨어 아키텍처 분석 후 개선 활동 ··························································· 170

제 6 장 소프트웨어 아키텍처 분석의 결론 ········································································ 174

제 1 절 소프트웨어 시각화 지표별 특성 및 범위 ·································································· 174

제 2 절 소프트웨어 아키텍처 분석 제품들의 분류 ··································································· 175

제 3 절 맺음 ··································································································································· 176

p


7

제 1 장 소프트웨어 아키텍처 분석

제 1절 소프트웨어 아키텍처 개요

소프트웨어 아키텍처에 대한 정의는 매우 많이 이뤄지고 있지만, 소프트웨어 아키텍처에

관한 연구를 주도하고 있는 미국 카네기멜론 대학의 SEI(Software Engineering Institute)에서는

일반적으로 다음과 같이 정의한다.

"Software architecture for a system is the structure or structures of the system, which

compromise elements, their externally-visible properties, and the relationship among them."

"한 시스템의 소프트웨어 아키텍처란 그 시스템의 한 구조나 구조들로 각 요소들과 외부에

보이는 특성들 그리고 그들 간의 관계를 절충한다. "

소프트웨어 아키텍처는 소프트웨어를 구성하는 컴포넌트와 컴포넌트의 관계를 추상적인 수준에서

정의한다. 소프트웨어 전체 구조를 한눈에 볼 수 있게 해주면, 각 컴포넌트와 컴포넌트 사이의

관계에 대한 이론적 근거를 판단할 수 있다. 소프트웨어 아키텍처는 소프트웨어에 대한 이해를

돕고 시스템 수준의 설계 모델을 재사용할 수 있게 해주며, 품질 요구사항을 반영할 수 있게

해주며, 소프트웨어 상세 설계 및 구현 이전 초기 설계 단계에서 소프트웨어가 가질 품질 요구사항을

예측할 수 있게 해준다.

소프트웨어 아키텍처가 중요한 이유는

첫째, 이해 관계자와의 커뮤니케이션을 위하여 정의된 형상이자 표현의 수단이다. 소프트웨어

아키텍처를 통해 이해 관계자들(프로젝트 관리자, 품질 담당자, 개발자, 테스터, 고객등)은

보다 원활한 커뮤니케이션을 할 수 있다.

둘째, 소프트웨어 아키텍처는 설계 방향의 가이드가 된다. 전체적인 관점에서 품질 속성을

고려하여 목표 시스템의 설계 방향을 조기에 결정할 수 있도록 지원하고, 향후 발생할 수

있는 위험요소를 감소시킬 수 있다.

셋째, 재사용 가능한 시스템의 추상화를 제공함으로써 소프트웨어 아키텍처가 시스템을

구성하는 요소와 이들간의 관계를 간략하고 명확하게 나타낼 수 있다. 따라서, 비슷한 기능과


8 SEC-2014-RM005

품질 요소를 가지는 다음 시스템에서의 큰 규모의 재사용이 가능하고, 소프트웨어 조직의

자산(asset)으로써 재사용 또한 용이해진다.

소프트웨어 아키텍처는 요구사항을 제대로 구현하기 위해 도움을 줄 수 있는 커뮤니케이션

툴이자 개발 초기의 요구사항과 실제 솔루션간의 간극을 좁혀줄 수 있는 휼륭한 도구이기도

하다.

[그림 1-1] 소프트웨어 아키텍처의 역할]

1) 소프트웨어 아키텍처는 소프트웨어 요소를 정의한다.

소프트웨어 아키텍처는 소프트웨어를 구성하는 기본적인 요소들 간의 관계 정보를 담고 있다.

이때 기본 요소들은 개발 단계에 따라 상세화의 수준이 달라질 수 있다. 즉, 초기 아키텍처링

단계에서는 추상적 수준의 요소들이었다가, 이후 개발 단계가 진행됨에 따라 상세화될 수 있다.

이러한 속성을 “아키텍처 추상화(Architecture Abstraction)”이라고 한다. 다시 말해 아키텍처는

특정 목적과 관련이 없는 요소의 자세한 정보를 생략할 수 있다. 또한 아키텍처 요소들 간의

관계는 인터페이스(interface)를 통해 상호작용을 표현할 수 있다. 일반적으로 인터페이스는

“공개 인터페이스”와 “비공개 인터페이스”로 구분할 수 있는데, 보통 공개 인터페이스만을 고려하고,

내부 소통을 위한 비공개 인터페이스는 아키텍처에 꼭 표시할 필요는 없다.

2) 시스템은 하나 이상의 소프트웨어 아키텍처로 구성될 수 있다.

시스템은 한개 이상의 소프트웨어 아키텍처를 포함할 수 있으므로, 어느 한 소프트웨어 아키텍처만을

소프트웨어 아키텍처라고 말할 수 없다. 예를 들어 구성단위와 실행 단위와 한 가지 이상의 연관

관계가 표시될 수 있고 (연관 관계, 병렬 프로세스를 동기화하는 연관관계 등), 한가지 이상의

시점이 존재할 수 있다.

p


9

3) 소프트웨어가 들어간 컴퓨팅 시스템에는 전부 소프트웨어 아키텍처가 있다.

매우 단순한 시스템인 경우에는 시스템 자체를 하나의 단일 요소로 볼 수 있다. 이것을

일반론적인 관점에서 소프트웨어 아키텍처라고 보긴 어렵지만, 그래도 소프트웨어 아키텍처라고

볼 수 있다.

4) 시스템 요소의 행위를 다른 요소에서 인식 할 수 있다면, 이는 소프트웨어 아키텍처로 표현될

수 있다. 외부에 드러나는 시스템 요소의 행위는 다른 시스템 요소와의 상호 작용 방법을

제시하므로 분명히 소프트웨어 아키텍처라고 할 수 있다

제 2절 소프트웨어 아키텍처 분석 목적 및 배경

1. 소프트웨어 아키텍처 분석 목적

시스템의 아키텍처에 대한 가장 중요한 사실 중 하나는, 비록 소프트웨어가 아직 개발이 되어

있지 않는 상황에서도 소프트웨어 아키텍처는 시스템의 중요한 요소에 대해서 표현하고 있다는

것이다. 소프트웨어 아키텍처를 바탕으로 이해관계자 및 아키텍트는 중요한 의사결정을 할 수

있게 될 뿐만 아니라 예상되는 사이드 이펙트(side effect), 위험요소 및 시스템 구성에 대한

예측을 할 수 있게 된다. 만약 소프트웨어 아키텍처가 없다면 이해관계자나 아키텍트, 혹은

관리자들이 쉽게 파악할 수 없는 소프트웨어에 대해서 특별한 해결책 없이 의사결정을 해야만

하고 그로 인한 위험이나 불확실성은 시스템의 규모가 크고 복잡해질수록 기하급수적으로

커지게 된다.

아키텍트가 소프트웨어 아키텍처를 파악할 수 있게 되면, 정교한 의사결정이 가능하게 되고,

우선순위화도 쉽게 결정할 수 있게 된다. 또한, 다양한 아키텍처의 팁 및 패턴의 적용이 가능

하여, 소프트웨어 시스템이 더욱 견고해지고 개발과 유지보수가 용이해 지게 된다. 이러한

이유로 소프트웨어 아키텍처는 “분석 가능한” 상태이어야 한다. 다시 말해, 소프트웨어 아키텍처가

분석 가능하면 이해관계자 및 아키텍트는 중요한 의사결정을 내릴 수 있을 뿐만 아니라, 성공하는

소프트웨어를 위한 다양한 전략 및 패턴의 적용이 가능하고, 개발자와 테스터들도 분석된 소프트웨어

아키텍처를 기반으로 개발 및 검증이 가능하여 보다 견고한 소프트웨어 시스템을 개발 및

배포할 수 있게 된다. 또한, 소프트웨어의 지속성 및 업데이트를 고려하여 다양한 소프트웨어

아키텍처의 발전 및 유지 보수가 가능하게 된다. 이러한 소프트웨어 아키텍처의 분석은 심지어

아직 개발이 완료되지 않은 소프트웨어에 대해서도 충분히 적용이 가능하다.


10 SEC-2014-RM005

[그림 1-2] 소프트웨어 아키텍처 분석]

정교한 의사결정 및 더욱 견고한 소프트웨어 시스템 개발을 위한 소프트웨어 아키텍처 분석의

목적은 아래와 같다.

소프트웨어 프로젝트에서 문제를 찾아내는 시기가 빠를수록, 더 나은 소프트웨어의 개발이

가능하고, 더 나은 소프트웨어 아키텍처의 설계가 가능하다.

만약 적합하거나 분석할 수 없는 소프트웨어 아키텍처를 설계하게 되면, 소프트웨어 시스템의

결과는 예측할 수 없을 정도로 망가졌거나 품질 불량을 가져오게 될 것 이다.

소프트웨어 시스템의 품질 불량에 대한 가장 큰 원인은 소프트웨어 아키텍처의 부재나 혹은 불량한

소프트웨어 아키텍처이고, 품질 불량은 소프트웨어 프로젝트 전체의 실패로 이어지게 된다.

소프트웨어 아키텍처 분석은 이러한 소프트웨어 프로젝트의 실패를 사전에 방지하기 위한

중요한 활동 중에 하나이며, 가장 비용이 적게 드는 활동이기도 하다.

2. 소프트웨어 아키텍처 분석 시점

일반적으로 가능한 이른 시점에 소프트웨어 아키텍처를 분석하면 할수록 비용절감의 효과를

크게 노릴 수 있다. 즉, 문제를 빨리 발견할수록 고치기가 쉬워지며 요구사항이나 스펙, 특징,

기능 등 필요한 부분에 쉽게 적용시킬 수 있다. 소프트웨어 품질은 프로젝트의 마지막 부분에

점검하는 것이 아니고, 가능한 시작점으로부터 시작되고 그 품질 검증이 프로젝트의 마지막까지,

테스트 마지막 시점까지 연결되고 상속되어야 한다.

소프트웨어 아키텍처를 분석하는 시기에 대해서는 특별히 정해진 단계나 프로세스는 없으나,

p


11

일반적으로 소프트웨어 아키텍처를 분석하기 위한 최적의 시점은 디자인 단계로 이야기된다.

그러나 소프트웨어 아키텍처 분석은 많은 단계에서 수행되면 다양한 문제점 분석 및 소프트웨어

아키텍처의 개선을 가져올 수 있기 때문에, 전체 소프트웨어 프로젝트 라이프 사이클 단계에서

몇 개의 지점을 선택하는 것이 좋다. 만약 소프트웨어 아키텍처가 아직 정해져 있지 않고 많은

의견이 오가는 단계이면, 여러 가지 의사 결정을 위해 소프트웨어 아키텍처 분석을 실시할 수

있고, 이미 소프트웨어 아키텍처가 정해지고 개발을 진행하는 단계라면, 개발이 소프트웨어 아키텍처를

잘 참조하여 개발하고 있는지 혹은 개발에 문제가 있거나 다시 고려해야 할 아키텍처 요소가

없는지, 아니면 소프트웨어 아키텍처를 재설계할 필요가 있는지를 파악하기 위해서 분석을 실시

할 수 있다. 이미 개발되고 완료된 소프트웨어 프로젝트나 레거시 코드라면 소프트웨어 아키텍처를

분석을 통해서 기존 아키텍처를 쉽게 파악하면서, 개선이나 유지보수가 필요한 점을 찾을 수도

있고, 재활용한 컴포넌트나 구조에 대해서 자산화(asset)을 할 수 있다. 그리고 다른 시스템이나

다른 구조로 적용(porting)을 위한 레거시 시스템의 분석 기준으로도 삼을 수 있다.

결국, 소프트웨어 아키텍처 분석은 소프트웨어 시스템이 품질 속성이나 시스템의 요구사항을

어떻게 잘 만족시키고 있냐를 다수의 사람들이 쉽게 이해하고 파악할 수 있는 최고의 발굴 행동

이라고 할 수 있다.

더군다나, 만약에 매우 크고 긴 개발기간을 가진 소프트웨어 시스템이라면, 개발팀이 소프트웨어

아키텍처 분석을 통해서 전체적인 큰 그림과 디자인을 파악하고, 후보 아키텍처와 트레이드

오프에 대해서 상호 토론을 통해서 발전시켜 나가는 것이 매우 중요하다. 이러한 것을 통해서

개발팀은 중요한 품질(속성)에 대한 팀의 의견을 통일 시키고 지속성장 가능한 소프트웨어

아키텍처를 유지, 발전 시켜나갈 수 있게 된다.

3. 주요 소프트웨어 아키텍처 분석 방법

소프트웨어 아키텍처를 분석하는 방법은 크게 정방향 분석 방법과 역방향 분석 방법, 두 개의

분류로 나눌 수 있다. 정방향 분석 방법으로는 미국 카네기 멜론 대학의 SEI 에서 제세한 소프트웨어

아키텍처 평가 방법(예. ATAM, CBAM 등)이 가장 많이 그리고 활발히 사용된다. 역방향 분석

방법으로는 PMD 나 reverse engineering 툴 등 시스템 개발 환경에 맞춘 다양한 툴을 활용하여

소스 코드로부터 소프트웨어 아키텍처를 분석하는 방법이 있다.

일반적으로 기존 소스 코드 없이 요구사항 등을 가지고 프로젝트 초반에 소프트웨어 아키텍처

분석을 실시할 때는 정방향 분석을 주로 실시하고, 레거시 코드나 기존 시스템이 있는 경우에는

역방향 분석을 통해서 기본 아키텍처를 분석/도출한 후에 소프트웨어 아키텍처 분석을 수행한다.

각 방법 및 사례에 대해서는 제 2 장 ~ 3 장에서 자세히 다루도록 하겠다.


12 SEC-2014-RM005

제 3절 소프트웨어 아키텍처 분석의 장점

소프트웨어 아키텍처 분석을 수행하게 되면 얻을 수 있는 일반적인 장점들은 아래와 같다.

1. 비용 절감 측면

초기에 소프트웨어 아키텍처 분석을 수행하게 되면 가장 먼저 얻을 수 있는 장점이 비용

절감이다. 특히 고객과 이해관계자가 참석하여 소프트웨어 아키텍처 분석을 수행하게 되면 고객들이

생각하는 가치나 사용자의 가치에 대해서 충분히 토론을 하게 되면서, 해당 품질 속성이나

소프트웨어의 가치가 아키텍처에 반영될 수 있게 된다.

만약 프로젝트 중/후반에 소프트웨어 아키텍처 분석을 하게 되어 그때 고객이나 사용자의 추가

요구사항이나 가치들이 반영이 되여야 하게 되면, 변경에 따른 비용적인 부담이 만만치 않게

일어나게 되기 때문에, 비용절감의 장점을 최대한 누리기 위해서는 프로젝트 초반에 소프트웨어

아키텍처 분석을 수행하여 아키텍처 변경에 따른 여러 가지 사이드 이펙트나 추가 고려사항도

점검을 하도록 하는 것이 좋다.

2. 프로젝트 참여자들의 이해도 향상

소프트웨어 아키텍처 분석 절차를 통해서 얻을 수 있는 두 번째 장점은 이해관계자 및 개발팀이

아키텍처에 대해서 반강제적으로 리뷰를 할 수 있게 된다는 점이다. 아직도 많은 소프트웨어

시스템들은 개발자들이 소프트웨어 아키텍처 설계에 참여하지 않을 뿐만 아니라, 본인이

개발하고 있는 소프트웨어 시스템의 아키텍처에 대해서 제대로 이해하지 않고 있다. 소프트웨어

아키텍처 분석 절차를 통해서 이러한 개발자들이 참여를 해서 소프트웨어 아키텍처 설계를 같이

리뷰하고 의사결정 포인트에 대해서 토론을 하며, 더 나은 대안을 찾으려 하기 때문에 해당

소프트웨어 아키텍처에 대한 이해도가 높이 올라가는 효과를 볼 수 있다. 또한, 개발 중이나

레거시 시스템의 역방향 분석을 통해서 개발하는 소프트웨어에 대한 구조적인 문제가 없는지, 더

나은 대안은 없는지 빠르게 파악할 수 있으며, 개발 중인 소프트웨어가 소스 코드에 대한 잠재적인

위험 요소와 문제에 대해서 쉽게 파악할 수 있어서, 더 견고하고 안정적인 소프트웨어의 개발이

가능하게 된다. 더불어 개발자들과 아키텍트 사이, 그리고 이해관계자 및 고객과 아키텍트

사이의 커뮤니케이션 오류도 많이 줄어드는 효과를 볼 수 있다.

3. 논리적인 소프트웨어 아키텍처 설계

소프트웨어 아키텍처 분석은 매우 특별한 질문에 대답하기 위한 특별한 분야에 집중이 된다.

p


13

다시 말해서, 이러한 특별한 질문에 대답하기 위해서는 논리적인 설계 및 디자인의 근거가

있어야 하고, 그 의사결정이나 디자인이 최선의 선택이어야 한다. 실제로 소프트웨어 아키텍처

설계를 할 때는 많은 트레이드 오프가 발생을 하게 되는데, 그때의 의사 결정에 대한 논리적이고

합당한 근거가 필요하게 된다. 이러한 논리적이고 합당한 아키텍처의 근거는 추후 설계나 디자인

변경이 발생할 경우, 혹은 요구사항이 급변하여 소프트웨어 아키텍처에 대한 재검토가 이뤄졌을

경우 매우 효과적으로 활용할 수 있게 된다.

4. 문제점의 빠른 발견 및 해결

위에서 언급한 것처럼, 초기에 소프트웨어 아키텍처 분석을 통해서 문제점을 발견하고 그것을

고친 경우 비용절감은 프로젝트 후반부에 문제점을 발견하고 수정한 것에 비해서 몇 배나 비용

절감의 효과를 가져 온다.

소프트웨어 아키텍처 분석을 수행하게 되면 논리적이지 않은 요구사항, 소프트웨어 퍼포먼스

등 품질 속성에 대한 문제, 잠재적인 위험 요소에 대한 문제들을 발견할 수 있게 되는데, 이러한

것들 통해서 아키텍트나 개발자들은 해당 소프트웨어 시스템이 가지고 있는 잠재적인 문제나

제약사항 등에 대해서 조기에 발견하고 대응할 수 있게 된다. 또한, 소프트웨어 아키텍처 분석을

통해서 해당 소프트웨어 시스템의 성능/역량등에 대해서 파악이 가능하므로 구현이나 예외처리

관련 디자인에 더 좋은 힌트를 얻을 수 있게 된다.

5. 요구사항 검증

소프트웨어 아키텍처 분석 절차를 통해 아키텍처가 얼마나 요구사항을 잘 만족 시키고 있는지에

대한 활발하고 열린 토론이 일어난다. 어떤 설계와 디자인이 요구사항에 대한 명확한 이해를

바탕으로 하고 있는지 파악할 수 있고, 우선순위가 잘 설정이 된 것인지 파악할 수 있다.

일반적으로 프로젝트 초반에 대화나 토론 없이 진행되는 요구사항의 아키텍처에 대한 반영은

다른 디자인과 충돌을 일으키는 경우가 종종 있기 때문에, 소프트웨어 아키텍처 분석을 통해서

해당 요구사항에 대한 객관성을 명확히 할 필요가 있다. 소프트웨어 아키텍처 분석을 통해서

다양한 요구사항을 자연스럽게 검증할 수 있고, 그것에 따른 디자인적인 충돌, 트레이드 오프

등을 파악 및 결정할 수 있다.

6. 소프트웨어 아키텍처 설계 품질 향상

소프트웨어 아키텍처 분석을 통해서 도출한 잠재적인 위험 요소, 성능 향상을 위한 요소 등의

개선을 통해 전체적인 소프트웨어 아키텍처 설계의 품질을 향상시킬 수 있다. 이해관계자와


14 SEC-2014-RM005

개발자들의 참여를 통해서 여러 가지 이슈나 요구사항에 대한 즉각적인 토론이 이뤄지며, 그러한

문제들의 해결과 결과를 통해서 소프트웨어 시스템의 성능/역량 향상으로 연결이 된다. 더불어,

이러한 개발문화를 통해서 개발 초기 단계뿐만 아니라 개발 중간 단계에서도 다양한 분석, 개선

및 입력을 통해서 시스템 전체의 품질 향상을 가져올 수 있다.

p


15

제 2 장 소프트웨어 아키텍처 정방향 분석

제 1절 소프트웨어 아키텍처 정방향 분석 개요

제 1 장에서 짧게 언급한 것처럼 소프트웨어 아키텍처를 분석하는 방법은 크게 정방향 분석

방법과 역방향 분석 방법으로 나눌 수 있다. 정방향 분석은 아키텍쳐 평가 방법을 활용하여

소프트웨어 아키텍처를 분석하거나 소프트웨어 아키텍처 뷰를 활용하여 설계된 아키텍처를

분석하기도 한다.

가장 널리 알려진 정방향 분석 방법으로는 미국 카네기 멜론 대학의 SEI 에서 제세한

소프트웨어 아키텍처 평가 방법(예. ATAM, CBAM 등)이 있다. 전 세계적으로 가장 많이

그리고 활발히 사용되는 중이고, QAW 및 다른 방법론과 병행하여서 소프트웨어 아키텍처를

분석 및 평가하는데 사용되기도 한다.

소프트웨어 아키텍처의 정방향 분석 후 결과는 의사 결정에 중요한 포인트가 되며, 트레이드

오프를 통해서 해당 소프트웨어 시스템의 디자인을 결정하는데 사용된다. 일반적으로 기존 소스

코드 없이 요구사항 등을 가지고 프로젝트 초반에 소프트웨어 아키텍처 분석을 실시할 때는

정방향 분석을 주로 실시 하고, 레거시 코드나 기존 시스템이 있는 경우에는 역방향 분석을

통해서 기본 아키텍처를 분석/도출한 후에 소프트웨어 아키텍처 분석을 수행한다.

정방향 분석 방법은 주로 소프트웨어 아키텍처를 평가하는 방법을 기반으로 분석을 한다.

소프트웨어 아키텍처 평가는 소프트웨어 아키텍처의 잠재적인 위험요소나 품질 요소, 비기능

요구사항등을 인지하고 분석하여서 해당 소프트웨어 시스템에 적합한 디자인을 가능하게 한다.

[그림 2-1] 다양한 아키텍처 뷰


16 SEC-2014-RM005

제 2절 소프트웨어 아키텍처 정방향 분석의 목적

일반적으로 소프트웨어 아키텍처 정방향 분석을 하는 목적은 크게 해당 아키텍처의 완결성과

일관성을 유지시키고, 사전에 문제점 및 잠재 위험요소를 파악하는 것에 있으며, 이해관계자와

아키텍트, 개발자와 테스트등 프로젝트 참여자들간의 커뮤니케이션을 향상시키고 공감대를 끌어

내는 것에 그 목적이 있다.

소프트웨어 아키텍처를 분석함에 있어서, 해당 소프트웨어 시스템의 외적 완결성과 내적

완결성을 추구하게 되는데, 외적인 완결성은 시스템의 요구사항과 관련된 것으로써, 거대한

소프트웨어 시스템의 요구사항이나 아키텍처의 복잡성을 해결하기 위한 노력이고, 아키텍처뿐만

아니라 복잡한 요구사항을 기록하고 추적하기 위한 많은 범례 및 기호들을 해결하려는 노력이다.

내적인 완결성은 소프트웨어 아키텍처의 경향이나 잠재적인 의도에 관한 것인데, 각 소프트웨어

아키텍처의 관련된 기호나 연결이 제대로 표현되고 모델화 되었냐를 해결하기 위한 노력이고

주요 의사 결정사항에 대한 기록이나 근거가 소프트웨어 아키텍처에 제대로 표현이 되었냐를

확인하기 일련의 행위이다. 소프트웨어 아키텍처의 내부 요소에 대한 일관성을 유지하는 것은 각

모델이나 디자인, 아키텍처의 요소가 충돌이나 혼란을 가져오기 않게 하기 위함인데, 특히 이름,

인터페이스, 행위, 상호교류 등에 대해서 전체 소프트웨어 아키텍처의 일관성을 유지하는 것이

매우 중요하다.

프로젝트 초반이나 개발 초기 단계에서 소프트웨어 아키텍처 평가 방법을 활용하여 소프트웨어

아키텍처를 분석함으로써 소프트웨어가 구체적으로 실체화/구현화/테스트 되기 이전에, 현재의

소프트웨어 아키텍처의 적합성 여부를 분석해 수정/보완함으로써 차후의 적합하지 않은

소프트웨어 아키텍처를 채택함으로 인해 생길 수 있는 위험을 최소화하는 것이 소프트웨어

아키텍처 정방향 분석의 가장 주요한 목적이라고 할 수 있다.

제 3절 소프트웨어 아키텍처 평가/분석(ATAM)

1. 개요

Architecture Tradeoff Analysis Method(이하 ATAM)은 미국 카네기 멜론 대학의 SEI

연구소에서 제시한 소프트웨어 아키텍처 분석을 위한 방법으로 아키텍처가 특정 품질 목표를

만족하는지 여부와 품질 목표들간에 발생하는 충돌에 대해서 분석하는 평가 기법이다.

아키텍처가 처음에 의도했던 방향대로 제대로 설계되었는지를 검증하는 분석 방법이며 설계된

p


17

아키텍처가 시스템 성능, 가용성, 확장성 등과 같은 비기능 요구사항에 대한 항목에 대해 초기에

의도했던 품질 목표를 만족시키고 있는지 분석하고, 여러 가지 품질 목표가 상호간에 어떻게

작용하는지 파악하는 것이 주요 역할이다.

• ATAM 은 일반적인 아키텍처 분석 방법과 유사하지만, 특히 다음과 같은 점이 중요하다.

• 이해 당사자의 능동적이고 적극적인 참여

• 핵심 이해 당사자의 충분한 준비

• 아키텍처디자인 이슈와 분석 모델에 대한 이해

• 비기능 요구사항에 대한 명확한 정리

품질 목표들간에 충돌을 프로젝트 초기(요구사항 정의 또는 설계 단계)에 알아냄으로써 비교적

경제적인 방법으로 문제를 해결할 수 있고 변경, 다른 시스템과의 통합, 업그레이드 등이 필요한

레거시 시스템을 분석하는데도 사용할 수 있다.

[그림 2-2] ATAM 개념도

2. ATAM 수행 목적

아키텍처 평가의 목적은 설계된 아키텍처의 결함을 확인하고, 비기능 요구사항의 관점에서

평가하는 것이 목적이며 아키텍처의 잠재적인 위험 요소를 감지하는 도구 역할을 한다. 또한

아키텍처의 중요성을 일깨우고 아키텍처와 관련된 산출물의 수준을 높이는 것과 함께 아키텍처

분석 시 위험요소, Trade-off 요소 등에 대해 파악하고 향후 개선안을 도출하는 것이 이 평가의

중요한 목표이다.

• ATAM 을 통해서 아래의 질문에 대한 대답을 얻을 수 있다.


18 SEC-2014-RM005

• 현재 소프트웨어 아키텍처가 요구사항, 특히 비기능적 요구사항(Architectural Requirement,

Quality Attribute)을 만족하도록 설계되었는가?

• 현재 소프트웨어 아키텍처가 내포하고 있는 위험(Risk)는 무엇인가?

• 여러 개의 소프트웨어 아키텍처 대안이 있을 경우, 어느 것이 가장 적합한가?

즉, ATAM 을 통해 비기능 요구사항에 대한 자세한 분석, 아키텍처의 결정사항에 대한 이해,

그리고 그 결정사항이 요구사항을 만족시킬 수 있는지를 분석할 수 있다.

3. ATAM 의 주요 장점

ATAM 을 수행함으로써 얻을 수 있는 주요 이점은 다음과 같다.

• 품질 속성 요구사항을 명확히 할 수 있다

• 아키텍처 문서화를 향상 시킬 수 있다

• 아키텍처 의사 결정의 주요한 기준을 도출해 낼 수 있다

• 프로젝트 초반 혹은 제품의 전체 라이프 사이클의 초기에 위험 요소를 파악 할 수 있다

• 이해관계자들 간의 커뮤니케이션을 원할 히 하는데 도움이 된다.

즉, ATAM 은 소프트웨어 개발 주기의 초기 단계에서 수행할 수 있으며, 구현이 아닌 설계된

디자인을 평가하기 때문에 상대적으로 비용이 저렴하고 빠르다는 것이 장점이다.

4. ATAM 주요 절차

[그림 2-3] ATAM 수행 절차

p


19

가. Present the ATAM

평가팀이 모든 이해 관계자에게 평가 절차에 대해서 설명하는 단계이다. 평가 자체에 대한

설명 및 평가를 진행하는 동안 지켜야 할 여러 가지 규칙에 대해서 설명한다. 참여자에게 평가를

통해 얻을 수 있는 기대사항 등을 질의하며, 평가팀 멤버의 역할 및 다른 참여자의 역할에 대해

설명한다. 평가가 진행되는 동안 생성되는 유틸리티 트리, 시나리오, 아키텍쳐 접근 방법, 아키텍쳐

분석을 위한 기술 및 위험요소, Trade-off 목록에 대해서 자세히 설명하여 적극적인 참여를 유도

한다.

나. Present the Business Drivers

프로젝트의 PM 이 비즈니스 관점에서 평가팀에게 시스템에 대해서 설명하는 단계이며 다음의

사항을 위주로 설명한다.

• 가장 중요한 기능적 요구사항

• 기술적, 관리적, 정치적 제약사항

• 비즈니스 목표

• 중요한 이해관계자

품질 목표를 만족시키기 위한 아키텍쳐의 중요사항 평가팀은 비즈니스 드라이버 소개를 듣고

난 후 평가될 시스템의 범위를 정하고, 언급된 이해 관계자, 중요 품질 목표, 제약사항 등을

이해하고 목록을 작성한다.

다. Present the Architecture

아키텍트가 평가팀에게 아키텍쳐에 관해서 가능한 자세하게 설명하는 단계이다.

• OS, 하드웨어, 미들웨어 등 이미 결정된 기술적인 제약사항

• 연동해서 사용해야 하는 다른 시스템

• 품질 요소를 만족시키기 위해 사용한 아키텍쳐 접근 방법

절차 기록자는 아키텍트가 설명할 때 중요 부분을 기록한다.

평가팀은 소개된 아키텍쳐 접근 방법, 잠재 위험요소, 추가적인 이해 관계자의 역할 등을

이해한다.


20 SEC-2014-RM005

라. Identity the Architectural Approaches

‘가. Present the Architecture’에서 소개된 아키텍쳐 고유의 접근 방법과 아키텍쳐 스타일을

파악하는 단계이다.

아키텍쳐 접근방법을 확인하는 방법으로는 S/W 아키텍트에게 질의할 수도 있으며 각각의

평가팀 멤버에게서 투표로써 접근방법을 조사할 수도 있다. 시나리오 기록자는 파악된 아키텍쳐

접근 방법을 기록한다.

마. Generate the Quality Attribute Utility Tree

평가팀, 아키텍쳐 팀, 프로젝트 매니저 등이 협력하여 유틸리티 트리를 작성하는 단계이다.

[그림 2-4] 유틸리티 트리의 예

이 단계에서 만들어진 유틸리티 트리는 이후의 평가 스텝에서 가이드 역할을 하며 분석의

목표를 구체화하는 효과를 기대할 수 있다.

유틸리티 트리를 통해 평가팀이 아키텍쳐의 어느 부분에 집중해야 할지 등을 파악하고 평가의

범위를 결정하는 데 도움이 된다.

바. Analyze the Architectural Approaches

유틸리티 트리를 통해 평가 범위를 결정한 후, 아키텍쳐 접근 방법과 결정사항을 평가하는

단계로 아키텍쳐의 중요한 부분을 알아낸다.

p


21

이 단계의 가장 중요한 결과물은 Risk, Sensitivity point, Trade-off 등이며, 이들을 유틸리티

트리의 시나리오와 연계하여 품질요소에 대해 평가한다.

[그림 2-5] 유틸리티 트리 작성

사. Brainstorm and Prioritize Scenarios

전체 이해 관계자로부터 시나리오를 생성하는 단계이다. 이 시나리오는 전체 이해관계자가

참여하는 투표 프로세스를 통해 우선순위가 정해진다.

유틸리티 트리는 시나리오를 생성하기 위한 하향식 메커니즘을 제공하는 반면에, 시나리오

Brainstorming 은 상향식 접근법으로 시나리오를 생성하는 것이다.

평가 리더는 이해 관계자가 차례로 시나리오에 대해 말할 수 있도록 라운드로빈 방식으로

진행시킨다. 시나리오 기록자는 Brainstorming 결과를 기록하여 전 참여자가 볼 수 있도록

게시한다. 참여자는 게시된 시나리오 결과에 대해 토론하여 합치거나 삭제하여 시나리오를 정제

한다. 시나리오가 결정된 후 투표를 실시한다. 결정된 시나리오의 수의 30%의 투표권을 할당

한다.

아. Analyze the Architectural Approaches

테스크 2 에서 선정된 높은 우선순위의 시나리오를 분석한다. 부가적인 아키텍처 접근 방법,

위험 요소, 민감 요소 등을 찾아낸다.

자. Present the Results

스텝 1~2 를 통해 수행한 평가 결과에 대해 최종 보고서를 작성 한다.


22 SEC-2014-RM005

제 3 장 소프트웨어 아키텍처 역방향 분석

제 1절 소프트웨어 아키텍처 역방향 분석 개요

아키텍처 정방향 분석 방법들을 이용하여 개발할 프로젝트의 아키텍처를 정립 후 실제 개발을

하게 되면 처음 의도와는 다른 방향으로 바뀔 가능성이 존재하며, 이에 따라서 원치 않았던

잠재적인 아키텍처의 문제들이 발생하거나 추후 확장 가능한 유연한 아키텍처에서 멀어지는

상황이 발생하게 된다. 이러한 상황을 방지하려면 개발을 진행하고 있는 소프트웨어 시스템의

아키텍처를 자주 살펴보고 문제가 발생될 수 있는 부분들을 개선해 나가야만 한다. 이러한 소프트웨어

시스템의 아키텍처를 파악하기 위한 방법들은 일반적으로 클래스 다이어그램을 분석하거나 소스

코드를 분석하여 파악하는 방법들이 존재한다.

소프트웨어 시스템의 아키텍처를 파악하기 위한 방법 중 가장 단순한 방법은 바로 소스

코드를 모두 살펴보는 방법을 사용할 수 있다. 하지만 코드 전체를 살펴보는 방법은 소프트웨어

시스템을 자세하게 분석하기 때문에 세부적인 내용에 대해서 확실하게 파악할 수 있지만, 분석에

매우 많은 시간이 걸리기 때문에 빠르게 아키텍처를 파악하기 위한 방법으로는 매우 부적절하며,

또한 소프트웨어 시스템을 너무 세부적으로 바라보기 때문에 전체적인 아키텍처를 그리기가

힘들어져서 아키텍처의 문제점과 문제를 발견하지 못할 가능성도 높아진다.

p


23

[그림 3-1] 개발 중 클래스 다이어그램을 통해서 분석하는 것에는 한계 존재

소스 코드 리뷰 말고 또 다른 분석 방법으로는 클래스 다이어그램을 이용할 수 있다. 이 방법은

앞서 소개한 코드 분석에 비해서 큰 시점에서 바라보기 때문에 소프트웨어 시스템의 아키텍처의

큰 그림을 그리기에 비교적 용이하며, 비교적 빠르게 분석할 수 있다. 하지만 너무 큰 시점에서

분석하기 때문에 한정적인 정보(상속, 포함)만 얻을 수 있어, 좀 더 자세한 소프트웨어 시스템의

아키텍처적인 문제점과 문제들을 파악하기에는 무리가 있다.

위에서 제기 하였던 아키텍처 분석 방법들은 소프트웨어 시스템을 너무 넓은 범위에서 보거나,

너무 좁은 범위에서만 보아서 생기는 것이다. 그렇기 때문에 적절한 수준에서 소프트웨어

시스템을 바라보게 되면, 앞서 이야기했던 방법들에서는 찾을 수 없었던 문제점들을 바로 확인할

수 있게 된다. 그렇기 때문에 실제 프로젝트를 개발하는 중에는 아키텍처를 분석하기 위해서는

위에서 설명한 방법들을 적용하는 것보다는 실제 프로젝트의 산출물인 코드를 이용하여 분석하여

가공된 정보들을 추출하여 소프트웨어 시스템의 아키텍처를 분석하게 되면 앞서 이야기 했던

분석 방법들보다 좀 더 적절하게 문제에 대응할 수 있게 된다. 그리고 이렇게 실제 소스 코드에서


24 SEC-2014-RM005

정보를 추출하여 아키텍처를 분석하는 방법을 아키텍처 역방향 분석 방법이라고 한다.

아키텍처 역방향 분석 방법은 앞서 이야기 한 것처럼 실제 결과물에서 정보들을 추출하여

분석하는 방법으로 코드의 일정한 기준을 정하여 특정 요소에 대하여 수치를 부여하여 이를

분석하는 지표 분석 방법과 실제 결과물내의 존재하는 다양한 컴포넌트간의 관계들을 추출하여

관계적 문제점(상호참조, 영향력 등)을 분석하는 관계 분석 방법, 그리고 지표 분석 방법과 관계

분석 방법에서 나온 결과들을 이용하여 복합적으로 분석할 수 있는 시각화 자료를 생성하여

다각도적으로 아키텍처를 분석할 수 있게 해주는 시각화 분석 방법이 존재한다.

[그림 3-2] 아키텍처 역방향 분석 방법의 구성

이번 장에서는 이러한 아키텍처 역방향 분석 방법들의 장단점과 지표 분석과 관계 분석, 그리고

시각화 분석 방법들이 구성되는 원리들과 이렇게 구성된 정보를 바탕으로 현재 프로젝트가

당면하고 있는 문제가 어떠한 것인지 분석할 수 있는 방법들에 대하여 구체적으로 소개하겠다.

p


25

제 2절 소프트웨어 아키텍처 역방향 분석의 특징

1. 소프트웨어 아키텍처 역방향 분석의 주요 특징 및 장점

아키텍처 역방향 분석을 프로젝트 진행 중에 이용하게 된다면, 우선 코드를 직접 분석하지 않고

프로젝트가 가지고 있는 잠재적인 문제들, 즉 컴포넌트간의 의존성이나 복잡성들을 최소한으로

줄일 수 있게 해주며, 더 나아가서는 코드의 품질 수준을 높여 프로젝트의 유지 보수를 보다

쉽게 만들어 준다. 그리고 실제 개발을 담당하는 프로그래머가 아닌 기획자나 다른 관리자들도

현재 프로젝트가 당면한 현 상황의 문제를 손쉽게 파악할 수 있도록 도와줘서 프로젝트의 진행

상황을 모두와 공유할 수 있게 도와준다.

또한 아키텍처 역방향 분석은 앞서 이야기한 것처럼 프로젝트의 품질을 관리하는 기능뿐만

아니라 구성에 대한 시각화 정보들과 다른 정보들을 참고하여 자신이 관여하지 않은 다른

프로젝트의 구성에 대한 이해하는데 도움을 줄 수 있다.

[그림 3-3] 소스코드에서 보기 힘든 문제를 적절한 뷰를 통해 가공하여 보여 준다


26 SEC-2014-RM005

2. 소프트웨어 아키텍처 역방향 분석의 단점

여러 장점을 가지고 있는 아키텍처 역방향 분석에도 몇 가지 단점을 가지고 있는데, 아키텍처

역 방향 분석 방법이 기본적으로 실제 프로젝트의 소스 코드를 기반으로 아키텍처를 분석하는

만큼 분석의 범위가 프로젝트의 소스 코드로 한정되어지기 때문에 프로젝트에 영향을 주는 다양한

요소들, 즉 DataBase 의 구성이나 데이터 통신 방법등 소스코드에서 얻기 힘든 코드 외적인

요소들에 대한 내용들은 파악하는데 무리가 있다. 그렇기 때문에 소스 코드에서 얻을 수 없는

다른 정보들은 다른 분석 방법들을 통하여 문제점을 파악해야할 필요성이 있다.

또한 아키텍처 역방향 분석은 일반적인 문제들에 대하여 분석결과를 제공하기 때문에 실제

현장에서 일어날 수 있는 다양한 트레이드 off 를 제대로 반영하지 못한다는 단점이 있다. 그렇기

때문에 아키텍처 역방향 분석으로 나온 결과를 해석할 때, 분석한 프로젝트의 성격과 특성들을

고려하여 내용을 이해해야 분석으로 인한 문제 해결의 효율을 극대화 시킬 수 있을 것이다.

장점 단점

- 코드를 직접 분석하지 않고 문제를 파악할 수 있다.

- 의존성이 적은 코드를 구성할 수 있다.

- 코드의 품질이 올라가 유지 보수가 쉬워진다.

- 정량적으로 문제들이 표시되어 프로그래머가

아닌 사람들도 문제를 파악할 수 있다.

- 코드의 이해도를 높일 수 있다.

- 소스 코드에 한정된 단편적인 뷰만을 제공한다.

- 실제 현장에서 발생하는 다양한 트레이드 off 들을

제대로 반영하지 못할 수 있다.

[그림 3-4] 아키텍처 역방향 분석의 장점과 단점]

p


27

제 3절 도메인 분석을 활용한 소프트웨어 아키텍처 분석

1. 도메인 개요

소프트웨어 시스템의 소스코드는 MECE(Mutually Exclusive and Collectively Exhaustive)이라는

대 전제 하에 기반으로 작성되어있다. MECE 란, 항목들이 상호배타적이면서 모였을 때는 완전한

전체를 이루는 것을 의미한다. 이를테면, 자바 소스코드에서 필드와 메서드가 서로 겹치지 않고,

모였을 때는 클래스를 이루고, 또한 클래스들은 서로 겹치지 않고 모였을 때 패키지를 이룬다. 이처럼

도메인이란 소프트웨어 시스템이 가진 기본속성 MECE 를 기반으로 사람이 인식하기 쉽게 적절한

레벨링을 하는 것을 의미한다.

소프트웨어 시스템의 아키텍처를 분석하고자 할 때 객체지향언어로 작성된 코드를 세분화시켜

(매서드, 필드로만) 분석하게 되면, 의존성, 지표를 계산 하더라도 그 결과는 사용자가 보기에

너무 복잡하다. 예를 들면 아래 그림과 같다.

[그림 3-5] 복잡한 아키텍처 분석도


28 SEC-2014-RM005

또한 세분화 시키지 않고 분석하게 되면, 사용자에게 보여줄 수 있는 정보가 매우 적어진다.

그렇기 때문에 사람들이 인지할 수 있는 적절한 레벨로 도메인을 나누어야 한다.

이때 소스코드의 도메인을 잡는 기준은 누구나 보아도 쉽게 이해 할 수 있는 단위어야 한다.

소프트웨어 시스템의 소스코드는 MECE 원칙을 기본으로하여 구분되는 단위로 작성되어있기 때문에

도메인의 기준은 소스코드에 내포되어있다. 이러한 소스코드에 내포된 도메인 기준을 사람들이

이해할 수 있는 단위로 그대로 사용한다. 객체지향언어의 한 종류인 JAVA 를 예로 들면 Method,

Class, Package, Package Set, Project, Workspace 6 개의 도메인으로 나누도록 한다. 또한

나눠진 각각의 도메인들은 Tree 구조로 나타낼 수 있다.

Method & Field : Class 를 이루는 구성 요소들이다. Field 는 Class 내에서 사용 되는

변수들이고 Method 는 클래스에서 사용하는 함수들이다.

Class : 의존성 분석에 있어서 가장 기본이 되는 단위로 Method 와 Field 가 모여서

SRP(Single Responsibility Principle)의 원칙을 따르는 하나의 일을 하는 단위이다.

Package : 연관된 Class 들이 모여서 서로 상호 작용하여 복합적인 요구사항을 처리한다.

Package Set : 연관된 Package 들 끼리 모여 작은 서브 시스템을 이룬다.

Project : Workspace 의 일부로 소프트웨어 시스템에서 각각의 역할을 맡은 컴파일 되는

단위의 서브 시스템이다.

Workspace : 소프트웨어 시스템으로 완전한 하나의 소프트웨어를 뜻한다.

[그림 3-6] 도메인 트리 구조도

p


29

이렇게 도메인을 나누면 코드를 단계별로 분석할 수 있게 되며, 사용자는 적절한 단계의 분석

결과를 볼 수 있어 직관적인 이해가 가능하게 된다. 그렇기 때문에 소프트웨어 아키텍처 역방향

분석을 하기위해서 가장 먼저 해야 할 작업은 소프트웨어의 도메인을 구분하는 것이다. 앞으로

설명할 용어를 설명하기위해 도메인 나누기를 통해 나눠진 각각의 Method, Class, Package 등을

엘리먼트 또는 노드라고 지칭하겠다.

2. 도메인 나누기 구현

도메인 나누기를 구현하기위해 JAVA 를 기준으로 설명하도록 하겠다.

￭ 기본 절차

1 단계: 소스코드를 의미단위로 나누기 위해 추상구문트리(AST)로 변환한다.

2 단계: Top-down 방식으로 클래스, 메소드 도메인을 구한다.

3 단계: 반면 패키지묶음, Project, Workspace 도메인은 Bottom-up 방식으로 구한다.

예제 소스 코드

package ABC;

class A{

int B;

void C(void){

int D;

}

}

￭ 절차 설명

- 1 단계: 소스코드를 의미단위로 나누기 위해 추상구문트리(AST)로 변환한다. 추상구문트리는

소스 코드 의미 단위로 나누어 노드로 나타낸 트리이다. 앞에서 언급하였던 예제 소스

코드를 추상 구문 트리로 변환한다면 다음의 그림과 같다.


30 SEC-2014-RM005

[그림 3-7] 변환된 추상 구문 트리

- 2 단계: Top-down 방식으로 클래스, 메소드 도메인을 구한다. 코드파일을 추상구문트리로

변환하였기 때문에 클래스가 추상구문트리의 상위노드에 해당 한다. 따라서 트리구조상

패키지 도메인이 가장 먼저 구해지며 다음으로 클래스, 메소드 도메인을 구한다.

[그림 3-8] TopDown 방식으로 도메인을 분류

p


31

- 3 단계: 반면 패키지묶음, Project, WorkSpace 도메인은 Bottom-up 방식으로 구한다.

하나의 추상구문트리 탐색이 끝날때마다 클래스 도메인의 패키지 정보, 서브 시스템 정보를

이용하여, 부모 도메인을 구한다. 이러한 방식으로 도메인이 구해지는 이유는, 추상구문트리가

코드파일을 단위로 만들어지기 때문이다.

3. 소프트웨어 의존성 분석

가. 소프트웨어 의존성 개요

각각의 도메인들은 서로 간의 확실한 경계를 가지고 상호 배타적이다. 도메인끼리 서로 아무

의존성이 없으면 소프트웨어 시스템을 구성하는 것은 불가능하다. 그래서 도메인끼리 서로 간의

의존성을 가지고 있고 이러한 의존성과 도메인이 모여서 하나의 서브시스템을 이룬다. 이처럼

도메인 사이의 의존성은 서로 다른 경계를 가진 도메인을 이어 하나의 서브시스템이 되게

해준다.

아키텍처를 파악하기 위해서는 도메인들 사이의 정확한 의존성을 파악해야 한다.

도메인을 나누기는 소프트웨어 내의 의존성을 분석하기위한 기본 수단이었다. 따라서 단순

도메인 나누기로는 각각의 도메인들의 의존성과 관련된 정보들을 포함되지 않아 정확한 아키텍처를

분석하는데 어려움이 있다.

그렇기 때문에 도메인 사이의 모든 종류의 의존성을 정의해야 한다. 의존성을 가진 두

도메인의 레벨 및 정확한 이름을 파악해야 한다. 이를 위해 각 도메인 간의 모든 의존성을 파악

하고 정의한다. 소프트웨어 시스템 안에서 발생하는 서로 간의 상속, 포함 등을 모두 정확히 파악

해야 한다. Class 도메인의 하위 도메인 사이의 의존성을 정의하면 상위 도메인들은 하위 도메인들의

의존성을 기반으로 구성되기 때문에 모든 의존성을 파악 할 수 있다. 또한 명확한 의존성을

파악하기 위해서는 도메인 사이의 의존성 사이에서 Source 와 Target 을 정확히 알아야 하고 어느

레벨의 도메인인지 정확히 파악해야 의존성을 제대로 정의 할 수 있다. 대략적으로 소프트웨어

시스템의 의존성은 다음과 같은 기본 분류 기준에 따라서 분류된다.

의존성은 Source 도메인에서 Target 도메인 사이에서 정의된다.

객체 지향 언어에서 사용되는 다양한 관계(상속, 참조 등)를 기반으로 분류한다.

상위 도메인은 하위 도메인의 의존성을 기반으로 구축되어야 한다.


32 SEC-2014-RM005

Source Dependency Kind Target Description

Class Extends Class The source type extends/implements

the target type

Class Contains Class The source type contains a nested

class whose type is the target type

Class Contains Field The source type contains the target

field

Method Returns Class The source method declares a

return type based on the target type

Method Has param Class The source method declares a

parameter based on the target type

나. 소프트웨어 의존성 구분

소프트웨어 시스템이 가지고 있는 의존성은 대상이 되는 객체 지향 언어에 따라 매우 다양하다.

이 문서에서는 앞에서 제시한 내용처럼 JAVA 언어를 기반으로 가정하여 다음의 구분, 구현

절차를 설명하겠다.

￭ 기본 절차

1 단계: 대상 소프트웨어의 분석단위가될 도메인을 나눈다.

2 단계: Class 도메인 및 하위 도메인 사이의 모든 의존성을 정의한다.

3 단계: 소스코드 및 목적코드에서 2 번에서 정의한 의존성을 추출 한다.

4 단계: 추출한 의존성을 표에서 정했던 템플릿으로 기록한다.

￭ 절차 설명

- 1 단계: 대상 소프트웨어의 분석 단위가 될 도메인을 나눈다. 도메인간의 의존성을 정의

하는 과정이다. 우선적으로 모든 도메인들이 정의되어 있어야 각각의 의존성을 명확히

구현 할 수 있다.

- 2 단계: Class 도메인 및 하위 도메인 사이의 모든 의존성을 정의 한다. 여러 가지 언어에서

모든 종류의 의존성을 정의할 수 있지만 객체 지향 언어 중 JAVA 에서 어떻게 의존성들을

정의 했는지 아래의 표와 같이 정의하였다.

[표- Java 의 의존성의 종류]

p


33

Source Dependency Kind Target Description

Method Throws Class The source method declares the

target type in its throws clause

Method Calls Method The source method code invokes

the target method

Method Accesses Field The source method code accesses

the target field

Field is of type Class The source field's type is based on

the target type

Any References Class Any relation not covered by one of

the others, e.g.

- generic type parameters/bounds

- parameter/return types of called

methods

- local variable types

- types declared in catch blocks

- types used in an instanceof operator

- 3 단계: 소스코드 및 목적코드에서 2 번에서 정의한 의존성을 추출 한다.

A) 이미 한번 컴파일 된 목적 코드가 있는 경우

이미 한번 컴파일 된 목적코드로 손쉽게 구현하는 방법이 있다. 이는 모든 도메인 이름이

정확히 목적 코드 안에 명시 되어있으므로 매우 손쉽게 도메인들이 어떤 의존성을 이루고

있는지 알 수 있다. 하지만 한번 컴파일 된 코드를 가지고 구현하는 것이기 때문에 구현하고

나서 사용하기에 IDE 와 연계되어서 사용하거나 JAR 처럼 라이브러리 형태만 분석할 수 있는

단점이 있다.

B) 소스코드만 존재하는 경우

소스코드에서 의존성을 구하는 것이다. 소스코드에서 구현되기 때문에 목적코드 분석보다

범용성이 늘어난다. 소스코드만 제공하면 분석이 가능하기 때문에 IDE 와 연계할 필요가

없어서 제약사항이 줄어들게 된다. 하지만 단점으로 소스코드에서 의존성을 뽑아내는것 자체가

이미 컴파일된 목적코드에서 뽑아내는 것보다 힘들고 외부 라이브러리가 포함된 프로젝트는

완벽한 분석이 불가능 하다.


34 SEC-2014-RM005

구현 할 때 단순히 코드를 파싱하는 형태로 구현하면 이름이 중복되거나 줄줄이 호출하는

형태의 소스 코드는 정확한 의존성을 표현하기가 힘들다. 그래서 소스 코드를 추상 구문

트리(Abstract Syntax Tree)로 변경하여 구현하는 편이 훨씬 편리하게 도메인들의 의존성을

구할 수 있다. 추상 구문 트리(이하 AST)는 각 구문에 따라서 Tree 의 형태로 표현하는

것이다.

예를 들어 아래의 그림은 자바의 소스코드를 AST 의 형태로 표현한 것이다.

[그림 3-9] 예제 소스 코드

[그림 3-10] AST

위의 그림과 같이 AST 로 소스코드를 변환하게 된다면 void PrintLog() 함수 내부에서

m_LogManager 의 타입을 찾아 어떤 함수를 호출 하였는지 쉽게 파악 할 수 있다. 그리고

처리 속도도 늘어나게 된다. 분석할 필요가 없는 것들을 가지를 쳐내게 된다면 모든 소스코드를

분석해야 하는 것보다 훨씬 빠른 속도로 처리할 수 있다.

p


35

- 4 단계: 추출한 의존성을 표에서 정했던 템플릿으로 기록 한다

위에서 추출한 의존성을 Source - Relationship - Target 의 형태로 기록한다. 여러가지

방법이 존재하는데 일단 도메인 사이를 이어주는 Edge 의 형태로 기록하여도 되고 따로

List 를 생성해서 기록하여도 상관 없다. 하지만 각 Source 와 Target 의 도메인은 정확히

분별 할 수 있도록 기록하여야 한다.

제 4절 지표를 이용한 소프트웨어 아키텍처 분석

1. 소프트웨어 지표 개요

소프트웨어 지표는 소프트웨어 사양 또는 속성을 측정하기위한 방법 중에 하나다. 정량적 측정은

모든 분야에서 필수적이기 때문에, 소프트웨어를 정량적으로 측정하기위한 소프트웨어 공학의

실무자와 이론가에 의해 지속적인 연구가 되어왔다. 소프트웨어 지표의 목표는 일정 및 예산

계획, 비용 추정, 품질 보증 테스트, 소프트웨어 디버깅, 소프트웨어 성능 최적화 및 최적의 인력

작업 할당에서 수많은 중요한 응용 프로그램이 있을 수 있다.

소프트웨어 지표를 이용할 경우에는, 다양한 문제점들을 단순히 나열하는 수준에서 해결 방법을

찾는 것이 아니라, 다양한 문제점들을 정의하고 관련된 기초 데이터를 수집하고, 문제점들을

객관적이고 과학적인 수치에 의해 분석하여 다양한 문제점들의 연관 관계 및 해결 방법을 찾을

수 있게 된다. 가장 큰 효과는 문제점을 단편적으로 해결하는 것이 아니라, 다양한 문제점들을

종합적으로 해결할 수 있는 프로세스 및 능력을 갖게 된다는 것 이다.

가. 측정(Measurement)의 정의

측정은 숫자 또는 심볼을 실세계에 존재하는 엔티티(Entity)의 애트리뷰트(Attribute)에 해당하는

프로세스로서, 명확하게 정의된 규칙에 따라서 이 애트리뷰트들을 묘사하기 위한 것이다.

측정은 엔티티의 에트리뷰트에 대한 정보를 포착하는 것에 중점을 둔다. 엔티티는 실세계의

객체로서, 사람, 방(root), 여행과 같은 이벤트, 또는 소프트웨어 프로젝트의 테스팅 단계 등의

예가 있다. 애트리뷰트는 우리가 관심을 갖는 엔티티의 특징(feature) 또는 특성(property)으로서,


36 SEC-2014-RM005

사람의 키 또는 혈압, 방의 면적 또는 색상, 여행의 경비, 테스팅 단계의 기간 등의 예가 있다.

애트리뷰트의 직접적인 측정(Direct measurement)은 다른 애트리뷰트의 측정에 종속되지 않고

측정하는 것이다.

애트리뷰트의 간접적인 측정(Indirect measurement)는 하나 이상의 애트리뷰트의 측정 결과에

의해 측정하는 것이다. 측정 결과는 현재 상황의 평가 또는 미래 상황에 대한 예측 활동에 활용되게

된다. 측정에 관한 다음과 같은 어구들이 있다. 측정하지 못하는 것은 제어 할 수 없다. 측정하지

못하는 것은 예측할 수 없다. 그렇기 때문에 측정은 어떠한 일을 제어하고 예측하기위해선

필수적인 일이다.

소프트웨어 측정에 대한 그래프를 아래와 같이 나타낼 수 있다.

[그림 3-11] Software Enginnering Measurement - the METKIT View[Fenton, 1991]

p


37

나. 소프트웨어 지표(Metrics)의 정의

소프트웨어 지표 기술은 소프트웨어의 측정 기술을 기반으로 소프트웨어 생명 주기 동안에

소프트웨어의 특징 또는 특성을 과학적인 수치로 정량화 할 수 있도록 하는 기술이다. 또한, 다양한

문제점들을 정의하고, 관련된 기초 데이터를 수집하고, 문제점들을 객관적이고 과학적인 수치에

의해 분석하여 다양한 문제점들의 연관 관계 및 해결 방법을 탐색하며, 다양한 문제점들을 종합적으로

해결할 수 있는 문제 분석 프로세스 및 시스템에 대한 기술이다.

지표는 소프트웨어 공학 분야에서 다양하게 정의되어 있고 소프트웨어 지표는 크게 Products,

Processes, Resource 로 나눌 수 있다. 본 문서에서는 소프트웨어의 아키텍처의 정방향 분석법을

다루기 위해 Products 에 관련된 지표에 대해서만 다루도록 한다. 다음은 Products 와 관련하여

USE, FACTOR, CRITERIA 와 지표와의 관계를 도식화한 그래프 이다.

[그림 3-12] 소프트웨어 품질 모델[Fenton, 1991

위의 그래프로 알 수 있듯이 메트릭을 통해 소프트웨어의 다양한 항목들을 객관적으로 평가

할 수 있게 된다.


38 SEC-2014-RM005

2. 소프트웨어 지표(Metrics)의 한계

가. 프로그래머의 인간성을 배제한 관리

개인의 능력을 수치화하고 이를 모두 확인하는 방법은 매우 어렵다. 관리자는 가장 재능 있는

프로그래머에게 가장 어려운 부분시킨다. 즉, 그 부분의 작업이 가장 시간이 오래 걸리고 버그도

많아 질 것으로 예상되고 있기 때문이다.

나. 편향

개발자는 팀의 능력을 잘 보이려고 하는 경향이 있기 때문에, 결과적으로 정량화시 일종의

편향이 작용한다. 예를 들어, 코드 행 수 능력을 측정하고자하는 경우, 프로그래머는 가능한 한

행 수가 많아보이도록 코드를 작성 할 수 있다.

다. 부정확

의미가 있고, 정확한 측정 방법은 알려져 있지 않다. 코드 행수는 정확하게 요구되지만, 문제의

어려움의 정도는 정확하게 수치화 할 수 없다. 기능 점수는 코드나 사양의 복잡성을 보다 정확하게

측정하는 방법으로 개발되었지만 잘 운영하려면 개인의 판단이 필요하다. 추정 방법이 다르면

결과도 달라진다. 때문에 함수 포인트를 만 명이 공정하게 이용하는 것은 어렵다.

이러한 소프트웨어 지표에 한계가 있는 것을 인지하고 사람이 아닌 소프트웨어를 평가하는

객관적 지표로 사용할 때 소프트웨어 지표 측정의 정확한 의의를 실현할 수 있다.

3. 소프트웨어 지표 종류

소프트웨어 지표의 앞서 설명했듯이 Products, Process, Resource 로 나눌 수 있고 여기서

집중할 Products 에 관한 지표는 Count, Complexity, Coupling, Object Oriented 등으로 나눌

수 있다.

가. Count Metrics

a) Number of Component

Number of Component 는 문자 그대로 Component 의 갯수를 의미한다. 여기서 Component 란

p


39

Library, Package, Class, Method, Function, Variable 등 소프트웨어 코드의 각각의 도메인

개채에 해당한다. Number of Component 지표를 통해서 소프트웨어의 크기 정도를 가늠한다.

￭ 측정방법

도메인 나누기에서 하였던 방법을 그대로 응용하여 구할 수 있다.

1 단계: 소스코드를 의미단위로 나누기 위해 추상구문트리(AST)로 변환한다.

2 단계: Top-down 방식으로 클래스, 메소드, 변수의 갯수를 구한다.

3 단계: 반면 패키지묶음, Project, Workspace 도메인은 Bottom-up 방식으로 각각의

컴포넌트 갯수를 구한다.

b) Source Lines of Code (SLOC)

Source lines of code (SLOC) 은 프로그램의 소스코드 라인수를 나타내는 값이다. SLOC 는

일반적으로 프로그램을 개발하는데 필요한 노력의 양을 예측하는데 사용된다. 또한 프로그래밍의

생산성과 유지보수성을 측정하는데 사용되기도 한다.

￭ 측정방법

많은 유용한 비교는 프로젝트의 코드 라인의 크기의 순서만을 포함한다. 각각의 소프트웨어

프로젝트는 1 부터 100,000,000 라인 이상으로 다를 수 있다. 20,000 줄 프로젝트와 21,000 줄

프로젝트를 비교하는 것보다 10,000 줄 프로젝트와 100,000 줄 프로젝트를 비교하는 것이 유용하다.

어떻게 코드 라인 수를 측정하는 지에는 논쟁의 여지가 있다. 소스코드의 라인수의 차이는

소프트웨어의 복잡성을 평가하거나 인력 투입의 지표가 될 수 있다.

SLOC 를 측정하는 방법에는 물리적인 SLOC 와 논리적인 SLOC 로 나눌 수 있다. 이 두가지

방법의 구체적인 정의는 다양하다. 그러나 실제 SLOC 의 일반적인 정의는 주석 행을 포함하여

프로그램의 소스 코드의 텍스트 라인수 이다. 섹션의 코드 라인이 25%이하의 빈행으로 된 줄도

포함 할 수 있다. 만약 섹션에 25%를 초과하여 빈 줄이 있을 경우 계산에 제외할 수 있다. 논리적인

SLOC 는 실행되는 “statements”의 수를 측정한다. 그러나 논리적 SLOC 는 특정언어마다 다르게

계산되어 질 수 있다. (예를 들어 논리적 SLOC 측정법 중 간단히 C 와 같은 프로그래밍 언어는

세미콜론’;’의 수로 라인수를 측정할 수 있다.) 논리적 SLOC 보다 물리적 SLOC 의 경우 보다.


40 SEC-2014-RM005

쉽게 툴을 통해 측정 가능하며 정의 설명도 쉽다. 하지만 물리적 SLOC 는 논리적으로 무관한

형식과 스타일 규칙에 민감하다. 반면에 논리적 SLOC 는 형식과 스타일 규칙에 덜 민감하다.

대부분의 SLOC 측정들은 측정방법이 논리적인지, 물리적인지 명시해 놓지 않은것이 많다. 논리적

SLOC 와 물리적 SLOC 는 크게 다를 수 있으므로 SLOC 지표를 읽을때 어떤 것인지 구분하는

것이 중요하다.

SLOC 를 측정의 모호성을 보이기 위해 C 코드의 SLOC 를 측정하는 의 예제를 보도록 하겠다.

for (i = 0; i < 100; i++) printf("hello"); /* 다음의 경우 이 코드는 몇줄인가? */

이 예제에서 우리는

물리적 SLOC 의 경우 1 줄.

논리적 SLOC 의 경우 2 줄. (for 문, printf 문)

주석 1 줄로 측정할 할 수 있다.

또한 프로그래머, 코딩 스타일에 따라 위 1 줄의 코드는 여러 줄로 나뉘어 쓸 수 도 있다.

/* 다음의 경우 이 코드는 몇줄인가? */

for (i = 0; i < 100; i++)

{

printf("hello");

}

이 예제에서는

물리적 SLOC 의 경우 5 줄

논리적 SLOC 의 경우 2 줄

주석 1 줄로 측정할 수 있다.

논리적”, “물리적” SLOC 값은 큰 숫자를 가질 수 있다. Robert E. Park(소프트웨어 엔지니어

학회)는 SLOC 값을 정의하기 위해 프레임 워크를 개발했다. 덕분에 사람들은 소프트웨어 프로젝트의

SLOC 측정 방법에 대해 자세하게 설명할 수 있게 되었다. 예를 들어, 대부분의 소프트웨어

p


41

시스템은 코드를 재사용하고 결정하는 측정 값을보고 할 때 재사용 코드를 포함 할 수 (있는

경우)하는 것이 중요하다.

SLOC 를 지표로서 처음 사용하게 되었을 때는 대부분 포트란, 어샘블리어와 같이 Line-oriented

언어였다. 이러한 언어는 주로 천공 카드로 프로그래밍을 하던 시절에 개발되었다. 하나의 천공카드가

일반적으로 하나의 줄을 나타낸다. 이것은 쉽게 샐 수 있는 하나의 개체였다. 그리고 눈에 보이는

프로그래머의 결과물이었기 때문에 메니저가 프로그래머의 생산성을 쉽게 측정할 수 있는

수단이었다. 당시 이 지표를 “Card Images”로 표현되기도하였다. 오늘날은 컴퓨터 언어는 형식제약

사항이 없다. 텍스트 라인은 어디성 높이 80, 폭 96 자가 아니며 하나의 라인에 하나의 코드만

들어갈 필요도 없다.

￭ SLOC 측정의 사용법

SLOC 측정법은 때때로 논란의 여지가 있다. SLOC 가 클수록 소프트웨어 개발에 많은 시간과

노력이 드는것은 누구나 동의 할 수 있는 사실이다. 하지만 SLOC 가 기능성과는 그리 많은 관계가

있지는 않다. 숙련된 개발자는 같은 기능을 하는 코드를 더 적은 줄로 코딩이 가능하다. 그렇기

때문에 동일한 기능을 하는 적은 SLOC 로 작성된 프로그램이 더 기능적이라고 할 수 있다. 특히나

SLOC 는 개개인의 생산성을 측정하는 대는 적합하지 않다. 기능성 측면에서 개발자는 적은 수의

줄로 코딩을 할수록 그렇지 못한 개발자보다 생산성이 높다고 볼 수 있다. 좋은 개발자는 여러

줄의 코드 모듈을 한 줄의 모듈로 합친다. 이처럼 코드 줄을 줄이게 될 수록 쓸데없는 코드에서

생기는 버그의 발생률 또한 줄 게 된다. 특히 숙련된 개발자는 가장 어려운 작업을 할당받게

되는 경향이 있으며, 따라서 때때로 SLOC 측정법에 의해 평가한다면 숙련된 개발자는 낮은

생산성을 나타나게 된다. 게다가 초보 개발자는 중복코드를 자주 발생한다. 이러한 중복코드는

많은 버그와 높은 유지보수 비용을 야기한다. 하지만 SLOC 값은 높게 나타나게 된다.

SLOC 는 다른 언어로 작성된 프로그램을 비교할 때는 부적합 하다. 다양한 컴퓨터 언어는

간결성과 명확성을 다른 방법으로 나타낸다. 극단적인 예를 들어보면, 어샘블리언어는 다른

언어로 몇 줄이면 되는 것을 구현하기위해 몇백 줄을 요하기도 한다.

아래 예제는 C 언어로 작성된 “Hello world” 프로그램을 COBOL 로 다시 작성한 예제 이다.

(COBOL 은 잘 알려진 3 세대 프로그래밍 언어이다)


42 SEC-2014-RM005

Year Operating System SLOC (Million)

1993 Windows NT 3.1 4-5

1994 Windows NT 3.5 7-8

1996 Windows NT 4.0 11-12

2000 Windows 2000 more than 29

2001 Windows XP 45

2003 Windows Server 2003 50

최근의 소프트웨어는 자동으로 생성되는 코드의 양이 많아져 SLOC 를 비교하는데 또 다른

문제점이 생기기도 한다. GUI 기반의 소프트웨어는 기본적으로 많은 줄의 소스코드가 필요하고

이를 구현하기위해 템플릿형식으로 프로그래밍 툴에서 제공한다. 한 예로, GUI 자동생성기는

수십줄의 라인을 간단하게 마우스를 아이콘에 드레깅하여 생성하기도 한다.

그렇기 때문에 디바이스 드라이버와 같이 항상 사람의 손으로 작성하는 코드와 GUI 와 같이

자동 생성되는 코드의 SLOC 를 비교하는 것은 적합하지 않다.

비용, 스케줄, 노력을 산출하기위해 SLO 를 파라미터로 하는 추정 모델이 있다. 널리 쓰이는

Berry Boehm이 고안안 COCOMO(Constructive Cost Model), 시스템의 가격을 추산하는 Galorath의

SEER-SEM 등이 이 중 하나이다. 이 모델은 좋은 예측을 할 수 있게 해준다.

Vincent Maraia 에 따르면 마이크로소프트의 Windows 제품의 SLOC 는 다음과 같다.

p


43

David A. Wheeler 는 리눅스 운영체제의 레드햇 버전 7.1 의 경우 3 천만 이상의 물리적

SLOC 를 가졌다고 발표했다. 또한 이 작업은 약 8,000 man-year 가 소요되었으며 노력의 산물로

조 단위 이상의 가치를 가지고 있다고 발표했다.

비슷한 작업으로 데비안 GUN/Linux 버전 2.2 는 5 천 5 백만 줄 이상의 SLOC 를 가지고 있으며,

이것은 14,000 man-year 와 1 조 9 천억의 개발비용이 들었다고 측정하였다. 최근 자동화된 툴에

의해 데비안 리눅스의 SLOC 를 측정해본결과 2005 년에 1 억 줄, 최근에는 2 억줄의 SLOC 로

측정되었다.

나. Complexity Metrics

a) Cyclomatic Complexity (CC)

Cyclomatic complexity 는 Thomas J. McCabe 가 1976 년도에 고안한 지표로써, 소프트웨어의

복잡도를 나타내는 지표이다. 일반적으로 Cyclomatic complexity 는 V(G)로 알려져있다. 소프트웨어

메트릭에서 일반적으로 많이 사용되는 지표중 하나이다. 이 지표는 복잡성을 나타내는 다른

지표들에 비해 이해하기 쉬우며 직접 계산하기도 어렵지 않다. 또한 이 지표는 소스 코드내의

조건의 갯수를 컨트롤 할 수 있도록 해준다. Cyclomatic complexity 값을 적게하는 것이 소프트웨어의

복잡도를 줄이는 방법 중 하나이다.

Cyclomatic complexity 지표는 소프트웨어 코드의 분기점의 개수를 나타내기 때문에 다음과

같이 테스트케이스와 함께 생각하면 이해가 쉽다. Cyclomatic complexity 지표는 소프트웨어

테스트 케이스의 갯수와 비례한다. 따라서 Cyclomatic complexity 의 값이 작을수록 소프트웨어를

테스트할 경우의 수가 줄고 소프트웨어의 품질을 높이기 쉽다고 할 수 있다.

Cyclomatic Complexity(CC)계산법은 다음과 같다.

CC = Number of Decisions point + 1

Cyclomatic Complexity 는 소프트웨어 코드의 결정 포인트에서 1 을 더한 값과 간다. 여기서

말하는 결정 포인트는 조건문에 의해서 생기는 코드의 분기점이다. 일반적인 예로 If..else if..else,

case, for ..next, until, while, catch 등이 있다. CC 를 구하는 간단한 방법은 이러한 조건문의

갯수를 세는 것이다. 또한 다중 결정포인트의 경우 CC 를 계산하는 몇가지 규칙이 있다. 다중


44 SEC-2014-RM005

Construct Decisions Reasoning

If..Then +1 An If statement is a single decision.

ElseIf..Then +1 ElseIf adds a new decision.

Else 0 Else does not cause a new decision. The decision is

at the If.

#If..#ElseIf..#Else 0 Conditional compilation adds no run-time decisions.

Select Case 0 Select Case initiates the following Case branches,

but does not add a decision alone.

Case +1 Each Case branch adds a new decision.

Case Else 0 Case Else does not cause a new decision. The

decisions were made at the other Cases.

For [Each] .. Next +1 There is a decision at the For statement.

Do While|Until +1 There is a decision at the start of the Do..Loop.

Loop While|Until +1 There is a decision at the end of the Do..Loop.

Do..Loop alone 0 There is no decision in an unconditional Do..Loop

without While or Until.

While +1 There is a decision at the start of the While..Wend

or While..End While loop.

Catch +1 Each Catch branch adds a new conditional path of

execution. Even though a Catch can be either

conditional (catches specific exceptions) or

unconditional (catches all exceptions), we treat all of

them the same way. *

Catch..When +2 The When condition adds a second decision. *

결정포인트란 if..else..else..else, switch..case..case..case 등과 같이 다양한 분기점이 생성되는

포인트를 말한다. 이때 계산규칙은 아래 표와 같다.

객체지향언어 마다 문법이 다를 수 있긴 하지만 기본은 위 표의 값을 따르면 된다. Cyclomatic

complexity 의 최소값은 1 이다. CC 값이 1 이라는 것은 소스코드에 어떠한 분기점도 없다는

말이다. 그리고 CC 값의 최대값은 지정되어 있지 않다. 소스코드 내에 분기점이 많으면 많을수록

p


45

CC 값이 커질 수 있다.

이 지표를 고안한 McCabe 는 Cyclomatic complexity 값을 10 이하로 유지하라고 권고하였다.

하지만 그때는 이미 30 년이 지났기 때문에 그 동안 프로그래밍 환경이 많이 변했다. 최근에는

많은 코딩표준이나 정적분석도구에서 10 이하로 유지하라고 하지는 않는다. C++ 코딩 표준 중

한가지인 JSF Air Vehicle C++ Coding Standard 의 경우 Cyclomatic Complexity 의 값을 20

이하로 유지하라고 명시해 두었다.

￭ Cyclomatic Complexity 의 특징

실제로 소프트웨어가 동작할 때 소스코드에 있는 모든 분기문이 동작하는 것은 아니다. 하지만

CC 값은 Run-time 시에 실제로 코드가 진행되는 분기점의 갯수를 측정하는 것이 아닌, 소스코드

상에서 나타난 분기점의 갯수를 측정하는 것이다.

Exit, Return 과 같이 함수 종료, 프로세스 종료를 의미하는 소스코드는 Cyclomatic Complexity 값을

증가 시키지 않는다.


46 SEC-2014-RM005

Metric Name Boolean operators Select CaseAlternative

name

CC Cyclomatic

complexity

Not counted +1 for each

Case branch

Regular

cyclomatic

complexity

CC2 Cyclomatic

complexity

with Booleans

+1 for each

Boolean

+1 for each

Case branch

Extended or

strict

cyclomatic

complexity

CC3 Cyclomatic

complexity

without Cases

Not counted +1 for an entire

Select Case

Modified

cyclomatic

complexity

Cyclomatic Complexity 의 변형: Cyclomatic Complexity 를 약간 변형한 CC2(Cyclomatic

complexity with Booleans or extended cyclomatic complexity)와 CC3(Cyclomatic complexity

without cases or modified cyclomatic complexity)가 있다.

CC2 : Cyclomatic complexity with Booleans(“extended cyclomatic complexity”)

CC2 = CC + Boolean operators

CC2 는 CC 에 Booleans 연산자의 갯수를 더한 값이다. Booleans 연산자는 조건문에서 사용되는

And, Or, Xor, Eqv, AndAlso, OrElse 등이 있다. CC2 는 이러한 조건문내의 Booleans 연산자의

값을 더하게 된다. 하나의 조건문안에 여러 Booleans 연산자가 들어갈 수 있다. 예를 들어 if(x =

1 or y=2) 와 같은 조건문은 if(x=1) then, if(y=2) then 과 같이 2 개의 조건문으로 나눌 수 있다.

조건문 내에 다양한 Booleans 연산자를 사용하면 코드의 Readability 가 줄어든게 된다. CC 값은

이러한 문제를 반영할 수 없기 때문에 CC2 라는 변형된 지표를 사용하기도 한다.]

CC2의 또다른 이름은 ECC(Extended cyclomatic complexity) 또는 Strict cyclomatic complexity 라고

하기도 한다.

￭ CC3 : CC Where each Select block counts as one

http://www.aivosto.com/project/help/pm-complexity.html

p


47

￭ Cyclomatic Complexity 의 중요성

Cyclomatic Complexity 수치가 높다는 것은 코드가 복잡하고 에러가 발생할 확률이 높다는

것을 의미한다. 또한 Cyclomatic Complexity 값만큼 테스트 케이스의 경우의 수를 만들어야

한다는 것이다. 그렇기 때문에 Cyclomatic Complexity 의 값을 줄이기 위해 많은 노력을 하여야

한다. 아래 표는 기존의 버그를 고치려다가 의도치 않게 또 다른 오류가 발생할 확률을 다타내는

자료이다.

Cyclomatic Complexity 또 다른오류가생길확률

1~10 5%

20~30 20%

50 이상 40%

거의 100 60%

표에서 보듯이 Cyclomatic complexity 지표의 값이 높으면 유지보수성에 아주 안 좋은 영향을

끼친다.

￭ Cyclomatic Complexity 의 장점

소프트웨어의 몇 안되는 정량적인 수치. 정수 하나로 된 숫자값 이기 때문에 이해가 쉽다.

정량적이기 때문에 여러 설계를 수치적으로 직접 비교가 가능하다.

개발자가 설계 단계에서 사용하기 쉽다.

￭ Cyclomatic Complexity 의 단점

switch ~ case 문에서 지표의 값이 너무 높게 나타난다. 이 경우 Modified Cyclomatic

complexity 지표를 사용하면 된다.

코드복잡도가 아닌 데이터 복잡도를 알기 힘들다.

이 지표는 버그 발생 경향과 상관관계가 있지만, 25 이하에서는 강한 상관관계를 보이지

않는다.


48 SEC-2014-RM005

￭ Cyclomatic Complexity 예제

아래 소스코드를 보자.

public void testMethod(){

int a = 1;

boolean flag = false;

if(a == 1){

;

}else if(flag == true){

;

}

if(a != 1){

;

}

}

if~else, if 문이 있어 3 의 값을 가지고 여기에 1 을 더하게 되어 4 의 값을 가지게 된다.

또 다른 소스코드 예제를 살펴보자.

public void testMethod2(){

int a = 1;

boolean flag = false;

int b = 2;

if(a == 1 && flag == true || b == 2){

; //Do something

}

else{

; //Do something

}

a = 2;

p


49

}

if 조건문안에 boolean 조건 연산이 3 개가 있다. 일반적으로 Cyclomatic Complexity 수치는 2

지만, Strict cyclomatic complexity(Extended cyclomatic complexity)수치는 4 이다.

b) Total Cyclomatic Complexity

Total Cyclomatic Complexity 는 단어 그대로 Cyclomatic complexity 의 전체 값을 의미한다.

Total Cyclomatic Complexity 는 하위 도메인들의 Cyclomatic Complexity 의 값의 합과 간다.

[그림 3-13] 도메인 트리

JAVA 를 예로, 위 도메인 그림을 보면 Method 의 CC 값을 더하면 Class 의 CC 값이 나오며

Class 의 CC 값을 더하면 Package 의 CC 값을 구할 수 있다. 이 하위도메인의 Total Cyclomatic

Complexity 값은 상위도메인의 Cyclomatic Complexity 가 된다.

c) Fat

Fat 지표는 하위 도메인간의 참조 그래프에서 엣지의 갯수를 의미한다. Fat 지표는 다양한

도메인에서 구해질 수 있다.


50 SEC-2014-RM005

[그림 3-14] 코드 분석도

위 예제에서 urqa 라는 어플리케이션 도메인 내에서 많은 패키지 도메인 간의 참조관계를 볼

수 있다. 여기서 Fat 지표를 구하면 그래프의 엣지의 갯수에 해당하는 15 가 된다.

[그림 3-15] 클래스간 참조 관계

위 예제는 urqa.Collector 패키지 도메인 내에서 클래스간의 참조관계를 살펴볼 것이다.

p


51

여기서 Fat 지표를 구하면 그래프의 엣지의 갯수에 해당하는 5 가 된다.

이처럼 Fat 지표는 다양한 도메인 내에서 구할 수 있다. Fat 지표를 통해서 자식 도메인에서

서로간의 의존횟수를 파악 할 수 있다. Fat 지표는 그 차제만으로 의미를 갖기보다 “Number of

component(Library, Package, Class, etc…)”와 함께 하여 도메인의 복잡성을 파악할 수 있다.

Fat 지표와 “Number of component”지표를 함께 사용하여 ACD(Average Component Dependency)

지표를 구해낸다. ACD 에 관한 내용은 아래 설명하므로 여기서는 생략하겠다.

d) Tangled

Tnagle 지표는 소프트웨어 아키텍처를 분석할때 가장 중요한 지표이다. Tangle 지표는 소프트웨어의

역참조의 비율을 나타내는 지표이다. 소프트웨어를 구조적으로 작성하기 위해서는 역참조 관계를

지양해야한다. 역참조는 소프트웨어의 유지보수성을 매우 저하시킨다. 역참조란 도메인간의

참조관계가 순환(Cycle)을 형성하는 것을 의미한다.

Tangle(T)의 값을 구하는 수식은 다음과 같다.

T(%) = R / T * 100

여기서 R 은 역참조 갯수, T 는 전체 참조의 갯수이다.


52 SEC-2014-RM005

[그림 3-16] 패키지 참조

위 그래프에서 패키지간 참조 관계를 살펴보면 PackageA가 PackageB를 참조하면서 순환(Cycle)이

형성되는 것을 확인할 수 있다. 이처럼 도메인간의 순환이 형성되는 것을 역참조라고 하는데,

역참조가 생기면 소프트웨어내의 하나의 코드의 변화가 소프트웨어 전체에 영향을 끼칠 수도

있다. 또한 상위, 하위 Layer 에 대한 구분이 모호해 지기 때문에 소프트웨어의 구조 이해를 저해

시킨다.

위 그래프에서 역참조 갯수는 4, 전체 참조 갯수는 16 이다. 따라서 Tangle = 4 / 16 * 100 이므로

25%가 된다.

Tangle 지표는 이러한 역참조의 비율을 나타내 주어 소프트웨어의 얽힘 정도를 표현해 준다.

Tangle 의 값이 0 에 가까울 수 록 소프트웨어는 구조적으로 안정하다고 할 수 있다. Tangle 지표가

크면 클수록 소프트웨어의 분석이 용이 하지 않게 된다. 다른 지표보다 Tangle 지표가 중요한

이유는 이처럼 소프트웨어의 구조화 정도를 나타내주기 때문이다.

p


53

[그림 3-17] 패키지 관계

다시 한 번 오픈소스 urqa 를 보며 Tangle 값을 구해보도록 하겠다. 여기서 역참조의 갯수는

12(1+1+10), 전체 참조의 갯수는 159 이다. 따라서 Tangle 값은 12 / 159 * 100 = 약 7.55%가

된다.


54 SEC-2014-RM005

오픈소스 Logdog 오픈소스 ACRA

[그림 3-18] 두 오픈 소스의 구조

실제 소프트웨어의 구조를 파악할 때 Tangle 지표의 값이 0 인 소프트웨어와 그렇지 않은

소프트웨어를 비교해보면 그렇지 않은 소프트웨어를 파악하는 것이 매우 난해하다. 위에 보이는

소프트웨어는 안드로이드 클라이언트의 Log를 외부 서버로 전송하는 동일한 기능을 하는 소프트웨어이다.

오른쪽의 acra 는 구조가 매우 복잡하여 소스코드의 변화가 소프트웨어 전체에 어떠한 영향을

끼칠지 예측이 불가능하며, 기능파악에서 어려움이 있다. 반면 왼쪽의 logdog 은 역참조가 나타나지

않아 소프트웨어 구조파악에 용이하며 코드변화에 어떠한 영향을 미칠지 대략 예측이 가능하다.

Tangle 지표를 줄이기 위해서 역참조 관계를 야기하는 소스코드를 변경할 것을 권고하며 역참조

관계를 시각화하기 위해서는 본 문서의 DSM, Composition View 에 관한 내용을 살펴보길

바란다.

e) Average Component Dependency

ACD(Average Component Dependency)지표를 설명하기 위해서는 우선 CD(Component

p


55

Dependency), CCD(Cumulative Component Dependency), Maximum CCD(MCCD)의 의미부터

파악하여야 한다. Component Dependency 지표란 하나의 엘리먼트가 참조하는 동일한

도메인의 모든 엘리먼트의 갯수를 의미한다. 또한 순환 관계의 엘리먼트들은 모두 동일한

Component Dependency 지표 값을 가진다.

위의 그림을 보면 가장 하위 노드는 Dependency 가 없으므로 0 이 되고, 중간의 노드는

Dependency 노드가 2 개, CD 는 2 의 값을 갖는다. 최상위 노드는 Dependency 노드가 5 개

CD 는 5 의 값을 갖는다. 따라서 모든 CD 의 합인 CCD(Cumulative Component Dependency)는

9 가 된다.

또 다른 예를 들어보면 다음과 같다.

왼쪽 그래프의 CCD 는 6, 오른쪽 그래프의 CCD 는 20 이다. 이처럼 CCD 의 값이 크다는 것은

서로의 노드가 의존성이 높다고 할 수 있으며, 각 노드를 수정했을 때 다른 노드로 변화가

전파될 가능성이 크다고 볼 수 있다.


56 SEC-2014-RM005

그리고 ACD 는 다음의 수식으로 나타낸다.

ACD = CCD / MCCD * 100 (%)

여기서 MCCD(Maximum CCD)란 도메인 내에서 가질 수 있는 최대 CCD 를 의미한다.

위 그래프에서 노드의 갯수가 모두 서로를 참조한다고 했을때 CCD 는 30 이고, 이 값이

MCCD 와 같다. 이제 ACD 를 구해보면 ACD = 9 / 30 * 100% = 30 가 된다.

ACD 는 다음과 같은 3 가지의 성질이 있다.

Empty : 만약 노드간에 참조가 없다면 ACD 는 0%이다.

Chain : 만약 모든 노드가 하나의 패스를 형성하면 ACD 는 50%이다.

Cycle : 만약 모든노드가 하나의 순환을 형성하면 ACD 는 100%이다.( 그 역도 참이다)

￭ 기본 절차

- 1 단계: 클래스간의 의존성을 그래프로 표현한다. ACD 의 연산을 쉽게 하기 위해 클래스를

그래프의 Node 로, 의존성을 Edge 로 표현한다.

- 2 단계: 그래프에서 싸이클을 이루는 노드들을 의미상 하나의 노드로 변환한다.

- 3 단계: 트리 그래프에서 Leaf 노드를 구한다.

- 4 단계: 새로 생성된 Leaf 노드의 CD 값은, 노드가 호출하는 이미 제외된 Leaf 노드의

CD 값의 합으로 구한다.

p


57

- 5 단계: 하나의 노드로 묶었던 싸이클을 이루는 노드를 다시 풀어주어 모두 동일한

CD 값을 적용시켜준다.

- 6 단계: 모든 노드의 CD 값의 평균을 구한다.

￭ 절차 설명

- 1 단계: 클래스간의 의존성을 그래프로 표현한다. ACD 의 연산을 쉽게 하기 위해 클래스를

그래프의 Node 로, 의존성을 Edge 로 표현한다.

[그림 3-19] 래프로 표현된 클래스들의 의존성

- 2 단계: 그래프에서 싸이클을 이루는 노드들을 의미상 하나의 노드로 변환한다. 싸이클을

이루는 노드들을 우선적으로 구별해 주어, 추후 계산할 그래프탐색에서 중복탐색을 줄여

속도를 개선시킬 수 있기 때문이다. 이 결과로 그래프는 트리의 형태로 변환 된다.


58 SEC-2014-RM005

[그림 3-20] 싸이클을 구분 한다

- 3 단계: 트리에서 Leaf 노드를 구한다. Leaf 노드는 다른 노드로 가는 Edge 가 없기 때문에

CD(Component Depandancy)값을 0 으로 우선적으로 구할 수 있다. 그 후 Leaf 노드를

그래프에서 제외시켜 새로운 Leaf 노드들을 생성한다.

[그림 3-21] Leaf 노드의 제외

p


59

- 4 단계: 새로 생성된 Leaf 노드의 CD값은, 노드가 호출하는 이미 제외된 Leaf 노드의 CD값의

합으로 구한다. 이 때 자식 중에 2 단계에서 적용했던 싸이클을 이루는 노드들을 호출한다면

CD 값에 싸이클을 이루는 노드의 갯수까지 더 해줘야한다. 그 후 Leaf 노드를 그래프에서

제외시켜 새로운 Leaf 노드들을 생성한다. 이러한 과정을, 모든 노드가 제외 될 때까지

반복한다.

[그림 3-22] Leaf 노드의 제외 반복

- 5 단계: 하나의 노드로 묶었던 싸이클을 이루는 노드를 다시 풀어주어 모두 동일한 CD값을

적용시켜준다.

[그림 3-23] 동일한 CD 값 적용


60 SEC-2014-RM005

- 6 단계: 모든 노드의 CD 값의 평균을 구한다.

[그림 3-24] CD 값 평균

다. Robert C. Martin Metrics

[그림 3-25] Robert C. Martin

p


61

Bob 삼촌이라고도 알려진 Robert Cecil Martin 이 1994 년 논문을 통해 발표한 지표이다. 이

지표들은 객체지향언어의 추상화 정도를 파악하는데 사용하는 지표들이며, Main sequence 로

알려진 차트를 통해 추상화 정도, 소프트웨어 도메인들의 변화의 민감도에 대해 파악할 수 있다.

a) Abstractness (A)

패키지 도메인(클래스 상위 도메인)에서 구할 수 있는 지표로서, 패키지가 얼마나 추상화가

되어있는지를 측정하는 지표이다. 이 지표는 추상화 클래스, 추상화 인터페이스와 동일한 패키지에

잇는 비추상화(non-abstract) 클래스, 비추상화 인터페이스 간의 비율이다. 이 지표의 값이 0 이라면

패키지는 모두 단단한(Concrete) 패키지라고 부른다. Abstractness 는 다음의 수식으로 구할 수

있다.

A = Na / (Nc + Na)

이때 Na 는 패키지 내의 추상화 클래스, 추상화 인터페이스의 갯수이며, Nc 는 패키지 내의

비추상화(Concrete) 클래스, 비추상화 인터페이스의 갯수이다.

Abstractness 지표는 0 에서 0.5 사이가 합리적이다. 하지만 좀 더 합리적인 지표를 알고자

한다면 Instability 지표 값과 비교하여 아키텍처를 분석하여야 한다. Instability 와 Abstractness 를

동시에 볼 수 있는 그래프를 Main sequence(Distance)차트라고 하며, 이 부분에 대한 내용은

Distance 지표를 참조하기 바란다.

b) Afferent Couplings (Ca)

Afferent Coupling 지표는 현재 패키지가 다른 패키지에 의해서 얼마나 사용되고 있는지를

나타내는 지표이다. Afferent Coupling 지표는 또한 Incoming Dependency 의 갯수를 나타내기도

한다.

Afferent Coupling 지표의 값이 클수록 다른 패키지에 많이 영향을 준다는 뜻이기도 하다.

그렇기 때문에 예를 들어 Ca 지표의 값이 500 이 넘는다면, 패키지를 변경할 때 많은 사항을

고려하여야 할 것 이다. 현재 패키지를 참조하는 다른 패키지가 매우 많기 때문이다. Afferent

Coupling 은 Efferent Coupling 과는 정반대의 개념으로 Afferent Coupling, Efferent Coupling 값을


62 SEC-2014-RM005

이용하여 Instability 지표를 구하는데 사용된다.

c) Efferent Couplings (Ce)

Efferent Coupling 지표는 현재 패키지가 다른 패키지를 얼마나 참조하고 있는지를 나타내는

지표이다. Efferent Coupling 지표는 또한 Outgoing Dependency 의 갯수를 나타내기도 한다.

Efferent Coupling 지표의 값이 클수록 다른 패키지들의 영향을 많이 받는다는 뜻이기도 하다.

Efferent coupling 값이 크다는 것은 다른 패키지에 의해 변화될 가능성이 높아 불안정하다고 할

수 있다. 이 지표의 창시자 Martin C. Robert 는 Efferent coupling 을 20 이하로 할 것 을

권고하고 있다. Efferent coupling 지표를 줄이기 위해서 참조하고 있는 클래스를 작은 클래스로

나누어 현재 패키지에 넣는 방법을 사용할 수도 있다. Efferent Coupling 은 Afferent Coupling 과는

정반대의 개념으로 Afferent Coupling, Efferent Coupling 값을 이용하여 Instability 지표를

구하는 데 사용된다.

아래는 Afferent coupling, Efferent coupling 지표의 이해를 돕기 위한 그림이다.

[그림 3-26] Afferent Coupling, Efferent Coupling]

d) Instability (I)

Instability 지표는 Robert C. Martin 이 고안한 측정방법으로 어플리케이션 내의 패키지를

변화시킬 때 다른 패키지에 영향을 주지 않도록 소모되는 노력의 정도를 수치화 한 지표이다.

Instability 는 앞에서 설명한 Efferent coupling, Afferent coupling 지표에 의해서구해지며 그

수식은 다음과 같다

p


63

I = Ce / (Ca + Ce)

이때 Ce = Efferent Coupling, Ca = Afferent Coupling 이다.

들어오는 방향(Incoming, Afferent)의 의존성이 나가는 방향(Outcoming, Efferent)의 의존성보다

많다는 무거움의 정도가 크다고 할 수 있다(Instability 가 적을 경우). 반대로 들어오는 방향의

의존성이 나가는 방향의 의존성보다 적을 경우 무거움의 정도가 작다고 할 수 있다(Instability 가

큰 경우). 어플리케이션에서 Instability 가 적을 경우 이를 참조하는 다른 패키지가 많다는 뜻이므로

변화를 쉽게 할 수 없어 무겁다고 표현할 수 있다. Robert C. Martin 는 적절한 Instability 지표의

값을 Main Sequence 를 도입하여 설명하고 있다. 다음에 나올 Distance(D)지표를 참조하기

바란다.

* (Instability 의 원래 뜻은 불안정을 뜻하는 것이지만 한국 사람의 이해를 돕기 위해 무거움

정도라고 표현하였다.)

e) Distance (D)

Distance 지표는 패키지의 추상화 정도(Abstracness)와 무거움 정도(Instability)를 동시에

비교하여, 현재 패키지가 적절하게 추상화가 되었는지, 아니면 과도하게 추상화가 되었는지 알

수 있게 해준다. 이 지표의 창시자 Robert C. Martin 은 Abstractness 지표의 값과 Instability 지표의

값의 합이 1 이 되도록 하는 것 이 좋다고 강력하게 주장하였다. 따라서 Distance 는 이러한

Abstractness 지표와, Instability 지표의 합에서 1 의 값을 뺀 수치로 정하고, Distance 가 0 이

되는 지점을 그래프에 그린 것이 Main sequence 라 명명하였다.


64 SEC-2014-RM005

[그림 3-27] Distance

Distance 지표를 수식으로 나타내면 다음과 같다.

D = (A + I - 1) / 2

이때 A 는 Abstractness, I 는 Instability 이다.

Distance 가 양수일 경우, 패키지의 추상도가 필요 이상으로 된 것을 의미하며, 반대로 음수일

경우 추상도가 필요 이하로 된 것을 의미한다.

Main sequence 에 가까운 패키지는 현재 구현된 추상화 정도와 실제로 사용되는 정도가

알맞음을 의미한다. Main sequence 와 멀어질 경우에 대한 자세한 설명은 Distance 차트에 대한

설명을 할 때 다루도록 하겠다.

p


65

라. Chidamber & Kemerer 의 Metric

a) Weighted Methods per Class (WMC)

Weighted Methods per Class(WMC) 지표는 Class 내의 모든 Cyclomatic complexity 지표의

값을 모두 더한 값이다. WMC 는 클래스를 변화시키기 위해 소모되는 노력의 양을 나타낸다.

WMC 지표는 Cyclomatic complexity 지표와 동일하므로 자세한 설명은 생략하도록 한다.

b) Depth of Inheritance Tree (DIT)

Depth in Inheritance Tree 지표는 클래스의 상속깊이를 나타낸다. DIT 는 루트(Root) 클래스로부터

상속받은 길이이다. 자바를 예를 들면 java.lang.Object 가 모든 클래스의 Root 클래스에

해당한다. 루트클래스는 Depth in Inheritance Tree 지표의 값이 0 이다. 마찬가지로 루트클래스를

바로 상속받은 클래스는 Depth in Inheritance Tree 지표의 값이 1 이며, 점점 상속 횟수를

더해갈수록 그 값이 증가한다.

Depth in Inheritance Tree 지표는 다음과 같은 특징을 가지고있다.

모든 Interface 타입의 DIT 지표의 값은 1 이다.

루트 클래스의 DIT 지표의 값은 0 이다.

나머지 클래스는 부모클래스(슈퍼클래스)의 DIT 값 더하기 1 을 한 값이다.

상속관계가 깊은 클래스는 클래스내의 변수의 행동을 예측하기가 어렵다. 때문에 Depth in

Inheritance Tree 지표가 너무 크면 시스템을 이해하기 힘들고, 유지보수에 어려움을 갖게 된다.

하지만 적절한 DIT 는 객체지향언어에서 재사용성을 높일 수 있다.

DIT 지표의 값이 0 이면 루트클래스를 의미한다. 만약 DIT 지표의 값이 2 보다 작다면 이는

객체지향언어의 강점인 코드 재사용성이 떨어지는 것 을 의미한다. 이 지표를 1994 년에 소개한

Chidamber 와 Kemerer 는 DIT 지표의 값이 최대 5 를 넘지 않는 것 을 권고 하고 있다.

c) Number of Children in Tree (NOC)

Number of Children in Tree 지표는 클래스의 서브클래스의 갯수를 의미한다. Number of

Children in Tree 지표는 얼마나 클래스가 어플리케이션 내에서 재사용되고 있는 지를 나타내는

지표이다. Number of Children in Tree 지표의 값이 클수록 프로그래머는 클래스를 변경할때


66 SEC-2014-RM005

자식클래스의 행동에게 영향이 가지 않도록 주의하여 변경하여야 한다. 즉 클래스를 변경할때

Number of Children in Tree 지표에 비례하는 테스트를 해야 한다는 뜻이다.

d) Coupling between Objects (CBO)

Coupling between Objects 지표는 클래스가 다른 클래스와 얼마나 연관되어(Coupled)있는지를

나타내는 지표이다. 앞서 설명했던 Efferent Coupling(Ce)지표와 비슷하다.

예를 들어 Class A 가 Class B 의 타입, 데이터, 또는 멤버를 참조한다면 Class A 는 Class B 와

연관되어(Coupled)있는 상태이다.

public class ClassA

{

private ClassB classB = new ClassB();

public void doSomething(){

System.out.println ( "doSomething");

}

public void doSomethingBasedOnClassB(){

System.out.println (classB.toString());

}

}

위 코드에서 Class A 는 Class B 를

ClassB()

classB.toString()

로 호출하므로 CBO 지표의 값은 2 가 된다.

CBO 는 2 개의 클래스 간에서만 생각하는 게 아닌 Class A 가 참조하는 모든 클래스를

생각하여야 한다. Chidamber 와 Kemerer 는 이 지표에 대해 다음과 같이 설명하고 있다.

객체 클래스 간의 과도한 커플링은 아키텍처 설계에 좋지 않은 영향을 끼치며, 재사용성을

떨어뜨린다.

p


67

- 객체간의 커플링은 최소한으로 유지하여야 한다.

- 객체간의 커플링이 높을수록 많은 테스트가 필요하다.

e) Response for a Class (RFC)

Response for a Class 는 클래스내의 중복되지 않는 메서드, 생성자를 호출하는 횟수이다.

Response for a Class 지표의 값이 크다는 것은 클래스의 복잡도가 높다고 할 수 있다. 예를

들어 매우 다양한 클래스를 호출하게 되면 프로그램의 잠재적 행동을 이해하는데 어려움이

생긴다. 따라서 Chidamber 와 Kemerer 는 적절한 RFC 의 값을 50 이하로 권고 하고 있다.

아래 소스코드의 RFC 를 구해보자.

public class ClassA

{

private ClassB classB = new ClassB();

public void doSomething(){

System.out.println ( "doSomething");

}

public void doSomethingBasedOnClassB(){

System.out.println (classB.toString());

}

}

위 예제에서 호출되는 메서드를 중복을 제외하고 보면

new ClassB();

doSomething()

System.out.println()

doSomethingBasedOnClassB()

ClassB.toString()


68 SEC-2014-RM005

이 있다.

또한 보이지 않는 ClassA()생성자까지 합하여

위 예제의 RFC 지표의 값은 6 이 된다.

f) Lack of Cohesion in Methods (LCOM)

Lack of Cohesion in Methods 지표는 Chidamber 와 Kemerer 가 소개한 객체지향언어의

지표로서 클래스의 응집성을 나타내는 지표이다. Lack of Cohesion in Methods 지표의 값이

크다는 것은 클래스의 응집성이 낮다는 것을 의미하고, 이는 하나의 클래스를 2 개의 클래스로

나누는 것이 바람직함을 의미한다. 또한 LCOM 은 클래스 디자인의 결함정도를 식별하는데

도움을 준다. LCOM 의 값이 크면 프로그램의 복잡성을 증가시킴을 의미하고 프로그램내의

에러의 가능성이 높다는 것을 의미한다.

LCOM 의 수식은 다음과 같다.

[그림 3-28] LCOM 수식

다음의 예제를 통해 LCOM 을 구해보도록 하겠다.

p


69

C 는 클래스를 뜻하고, 위에서부터 메서드 순서대로 M1, M2, M3, M4 가 된다. 그리고 각각의

메서드가 필드를 액세스하는 집합 {I1} = {∅},{I2} = {aaa},{I3} = {street, city, zipCode},{I4} =

{zipCode}이다.

여기서 P 와 Q 를 구하면

(I1∩I2) = {∅}

(I1∩I3) = {∅}

(I1∩I4) = {∅}

(I2∩I3) = {∅}

(I2∩I4) = {∅}공집합 이므로 P 이다

(I3∩I4) = {zipCode} 공집합이 아니므로 Q 이다.

따라서 |P| = 5, |Q| = 1 이다.

LCOM 을 구하면

LCOM = |P] - |Q] = 5 - 1 = 4

따라서 위 예제에서 LCOM 의 값은 4 가 된다.


70 SEC-2014-RM005

의존성 시각화 차트

마틴 C 차트

제 5절 시각화를 활용한 소프트웨어 아키텍처 분석

1. 개요

지금까지 아키텍처 역방향 분석의 기본이 되는 도메인 분석과 지표 분석에 대한 내용들에

대하여 집중적으로 이야기 하였다. 여기서 추출되는 도메인간의 관계 정보와 지표 정보들은 추출된

상태만으로도 충분히 의미 있는 정보들을 가지고 있지만 적절한 가공이 되어 있지 않기 때문에

아키텍처 분석에 사용하기에 조금 어려움이 존재 한다. 그렇기 때문에 이렇게 추출된 정보들은

적절한 차트나 뷰의 형태로 사용자가 쉽게 이해할 수 있도록 구성하여 제공하면 분석의 효율을 극대화

시킬 수 있다.

그래서 이번 장에서는 분석된 도메인들 간의 관계 정보와 다양한 지표 정보들을 기반으로

하여 사용자가 분석한 프로젝트의 아키텍처를 쉽게 파악할 수 있는 다양한 시각화 방법론들 중에서

가장 많이 사용되는 모듈간의 의존성을 시각화해주는 의존성 시각화 차트, 구성요소들의 전체적인

크기 구조를 시각화여 크기와 관련된 문제를 해결하는데 사용되는 크기 시각화 차트, 구성 요소들이

적절하게 추상화가 되었는지 알려주는 로버트 마틴 C의 차트, 그리고 프로젝트안에 존재하는 오염도들을

표시해주는 오염도 시각화 차트까지 크게 4 가지의 시각화 방법들의 기본적인 원리와 이러한

시각화 차트들을 이용하여 아키텍처를 이해하는 방법들에 대하여 간단히 설명하겠다.

p


71

크기 시각화 차트오염도 시각화 차트

[그림 3-29] 아키텍처 역방향 분석에 가장 대표적인 4 가지 시각화 분석 방법

2. 의존성 시각화 차트

가. 개요

의존성 시각화 차트는 아키텍처 역방향 분석에 존재하는 다양한 시각화 방법들 중에서 가장

대표적인 시각화 방법으로 분석하고자 하는 프로젝트 소스 코드 안에 존재하는 각각의 노드(패키지,

클래스 등의 단위)간의 다양한 의존 관계들을 추출하여 이를 사용자가 보다 쉽게 파악할 수

있도록 도와주는 차트로 구축하여 보여준다. 이러한 의존성 시각화 차트들은 아키텍처 구성에

있어서 중요한 요소인 의존성(Dependecy)에 대한 정보를 주기 때문에 각 모듈간의 의존관계를

파악하고, 과한 의존성들을 제거하기 위해서 많이 사용되는 차트이다. 의존성 시각화 차트는

차트의 구성 방식이나 표현 범위에 따라서 시각화 차트의 모습이 다르게 나타나게 된다.

우선 차트의 구성 방식의 경에는 크게 2 가지 형태의 차트가 존재하는데, 첫 번째는 행렬의

모습으로 의존관계를 표현하는 DSM 계열과 그래프의 성질을 이용하여 의존 관계를 표현한 방향

그래프 방식으로 나누어 지게 된다. 그리고 표현 범위에 따라서는 전체 컴포넌트의 의존성을

표시하는 기본적인 방법과 직접적으로 관련을 가지고 있는 요소들간의 의존성을 보는 커플링

방식, 그리고 사용자가 선택한 요소들간의 의존성을 분석하는 샌드 박스 방법이 존재한다.

이렇게 다양하게 존재하는 의존성 시각화 차트들은 각각 형태에 따라서 각각이 다양한 특징들을

가지고 있어 자신이 분석하고자 하는 프로젝트의 성향에 알맞게 적절한 선택이 필요하다. 그래서

여기에서는 의존성 시각화 차트의 표현 방식에 따른 차트들을 먼저 소개한 후 표현 범위에 따른

의존성 시각화 차트들의 특징들을 소개하겠다.


72 SEC-2014-RM005

DSM 방식 방향 그래프 방식

[그림 3-30] 표현 방식에 따른 의존성 시각화 차트의 종류

일반커플링

샌드 박스

[그림 3-31] 표현 범위에 따른 의존성 시각화 차트의 종류

나. 표현 방식에 따른 의존성 시각화 차트

a) DSM (Dependency Structure Matrix)

￭ 개요

소프트웨어 시스템에 존재하는 다양한 요소(패키지, 클래스, 메소드 등)들과 이러한 요소들 간의

여러 의존성들이 존재한다. 이러한 정보들은 하나의 소프트웨어 시스템에서도 매우 방대한 양을

가지고 있기 때문에 무엇보다도 이를 요약해줄 수 있어야 하며, 또한 이 내용들을 토대로 소프트웨어

시스템을 분석하고자 하는 사람은 최대한 쉽고 빠르게 소프트웨어 시스템 전체의 구성을 파악하고

문제점을 찾을 수 있어야 한다. 그중에서 DSM은 의존성 시각화를 행렬(표) 형태로 표시하여 쉽게

시각화할 수 있게 해주는 대표적인 의존성 시각화 방식이다.

p


73

Source Relationship Target

PackageA.ElementA Contain PackageB.ElementB

PackageA.ElementA.b Is of Type PackageB.ElementB

PackageA.ElementA.getElementB() returns PackageB.ElementB

PackageB.ElementB Contain PackageC.ElementC

PackageB.ElementB.c Is of Type PackageC.ElementC

￭ 주요 특징

DSM은 소프트웨어 시스템에 존재하는 다양한 요소들 간의 관계를 표 형태로 시각화하여 소프트웨어

시스템에 내제된 상호 참조(circular dependency) 문제를 발견하여. 파도 효과 (Ripple Effect -

하나의 변화가 다른 클래스, 패키지에 연쇄적으로 변화를 전파하)를 사전에 제거할 수 있는

방법이다. 이러한 DSM 의 생성은 기본적으로 소스코드 내에 존재하는 다양한 의존성들을 모두

추출하는 것부터 시작하게 된다.

파일 A 파일 B 파일 C

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();

}

}

[ 참고용 테스트 소스 코드(자바 기반) ]

위처럼 3 개의 파일에 3 개의 클래스가 서로 의존성을 가지고 있을 때 이들의 의존성들을 모두

추출한다. 추출하게 되면 아래와 같이 8 개의 의존 관계를 확인할 수 있다. 이렇게 추출된 의존성

정보들의 시작요소와 도착요소의 도메인(클래스, 패키지 등) 수준을, 분석하고자 하는 기준 도메인의

시점으로 변경한다. 간단히 예를 들자면 시각화 하려는 기준이 “패키지” 단위라면 “PackageC.ElementC.

getElementA" 와 같은 “패키지”단위 보다 하위에 속하는 “메소드" 단위의 정보를 기준점인

패키지 단위의 정보, 즉 “PacakageC”로 변경하여 의존성을 계산한다.


74 SEC-2014-RM005

Source Relationship Target

PackageB.ElementB.getElementC() returns PackageC.ElementC

PackageC.ElementC.getElementA Contain PackageA.ElementA

PackageC.ElementC.getElementA() returns PackageA.ElementA

[테스트 코드에서 추출된 의존성들의 예제]

그 후 변경된 정보를 바탕으로 실제 DSM 을 시각화 하게 된다. 이때 의존성의 수는 변경된

의존성 정보 안에서 시작 요소와 도착 요소가 모두 같은 경우의 수를 기입하는 형태로 DSM 을

표현하게 된다.

1 2 3

PackageA: 1 X 2

PackageB: 2 3 X

PackageC: 3 3 X

[완성된 DSM 예제 ]

￭ 장단점

이러한 DSM 을 활용하여 소프트웨어 시스템을 분석하게 되면 DSM 이 기본적으로 시스템내에

존재하는 의존관계수를 계산하여 시각화해주는 것이기 때문에 무엇보다 시스템 내에 존재하는

의존성들을 비교적 쉽게 분석할 수 있게 된다. 그렇기 때문에 에러의 전파 경로를 분석하거나

시스템 내에 포함된 상호 참조와 같은 의존성과 관련된 아키텍처적인 문제들을 쉽게 발견할 수

있게 된다.

그렇지만 이러한 DMS 에도 단점이 존재한다. 바로 표를 기반으로 의존성 정보들을 시각화하기

때문에 분석하고자 하는 소프트웨어 시스템의 규모가 커지게 되면 표 자체가 매우 커져서

분석이 힘들어 지게 된다. 또한 DSM에서는 단순히 소프트웨어 시스템에 포함된 의존성의 갯수만을

표시해주고 어떠한 의존 관계(참조, 호출 등)인지는 알려주지 않기 때문에 정확한 분석이 힘들 수

있으며, 표로서 전체 의존성을 보여주기 때문에 오랜 시간을 들여 DSM 을 분석하지 않는한

p


75

전체적인 시스템의 아키텍처를 생각하기에는 힘들 수 있다.

장점

- 소프트웨어 시스템의 의존성에 의한 아키텍처를 분석하기 쉬워진다.

- 소프트웨어 시스템 내부의 아키텍처적인 문제점들을 발견하기 쉽다.

단점

- 소프트웨어 시스템의 규모가 커지면 분석하기 힘들어진다.

- 의존성의 정확한 종류를 파악하는 것이 불가능하다.

- 소프트웨어 시스템의 전체적인 아키텍처를 생각하기가 힘들다.

￭ 기초 분석 방법

기본적으로 DSM 을 해석하는 방식은 매우 간단하다. 우선 다음과 같은 DSM 이 존재한다고

하면, DSM 의 열을 기준으로 내용을 해석하면 된다. 예를 들자면 “Task A(1 번)는 Task C(3 번)이

의존성을 가지며, Task C(3 번)은 Task A(1 번)과 Task B(2 번)에 의존성을 가진다”라고 의미를

해석하면 된다.

[그림 3-32] DSM 예제(X 는 임의의 숫자)

이렇게 DSM을 해석하는 방법은 매우 간단하게 의미를 파악할 수 있다. 조금 더 내용을 설명하면

Task A 와 Task C 가 상호 의존성을 가지고 있는 것을 확인할 수 있는데, 이것은 바로 해당

Task 들이 Circular Dependency(상호 참조)를 가지고 있다는 의미가 된다. 여기서 Circular

Dependency 가 어떠한 것인지 소개하자면, Circular Dependency 는 Component A 가 B 를

의존하고 B 가 다시 A 를 의존하는 경우를 말한다. 몇 단계를 거쳐 간접적으로 발생하는 것도


76 SEC-2014-RM005

당연히 포함된다. 이러한 Circular Dependency 가 존재하게 되면 하나의 Component 에 수정이

발생하게 된다면 이와 연관된 Component 에도 영향을 받아 수정이 필요하게 되고, 이러한

상황이 Circular Dependency 로 인하여 무한히 영향을 받게 된다. 그렇기 때문에 이러한

Circular Dependency 는 최대한 제거하는 것이 좋다.

즉, 위의 예제는 Task A 와 Task C 가 서로 Circular Dependency 를 가지고 있기 때문에 해당

요소의 결합을 줄여야 하는데, 이는 아키텍처의 대가인 Robert C. Martin 는 완충작용을 해줄

새로운 Package 생성하여 Circular Dependency 를 없애거나 Interface 를 이용하여 갑작스러운

변화를 상쇄시킬 수 있는 방법을 권하고 있는데 경우에 따라서 적당한 방법들을 선택하여

의존성을 제거하면 된다.

￭ 응용 분석 방법

다양한 의존성 문제를 해결하는 대표적인 방법은 Layering을 이용하는 것으로 각각의 Component 를

계층화를 시켜서 전파를 국지적으로 만들어서 변화에 강인하게 만드는 방법을 말한다.

[그림 3-33] Layer 참조 예

위 그림에서 보는 것과 같이 WPF 가 BCL(Base Class Library)를 참조하는 것, 즉 아래 Layer 를

p


77

참조하는 것이 가장 좋은 상태이다. 하지만 Reflection 이 XML 을 참조하는 것은 하위 Layer 에서

상위 Layer 를 참조하기 때문에, Circular Dependency 를 발생시킬 가망성이 많기 때문에 이러한

구조는 최대한으로 피하는 것이 좋은 상태이다.

그렇다면 그림에서처럼 WPF 가 XML 이 같은 동등한 레이어 있다면 이들을 어떻게 관리해야

되는 것일지 의문이 들수 도 있다. 이와 같이 같은 Layer 에 있는 Component 들은 최대한으로

Sub Namespace 로 만들어 의미적으로 명확하게 그룹화 하여 구분하는 것이 가장 좋다고 할 수

있다. 특히, 여기서 Namespace 의 주 목적은 같은 이름을 가진 타입들의 충돌을 해결하고자

하는 것이 아니고, Namespace 의 주 목적은 응집력 있고, 쉽게 찾을 수 있으며, 쉽게 이해할 수

있는 계층구조로 타입들을 구성하는 것이 가장 큰 목적이라고 할 수 있다.

이제부터 본격적으로 의존성 시각화 차트인 DSM 을 이용하여 Layering 을 처리하는 방법들에

대하여 내용을 설명하겠다. 우선 application, model, domain, framework, util 순으로 layer 구조로

설계된 시스템이 있다고 가정하고, 이를 DSM 으로 분석을 하니 아래와 같은 형태로 Metrix 가

나왔다고 가정해보자.

[그림 3-34] Layering 분석을 위한 DSM

우선 이 소프트웨어 시스템은 기본적으로 Layer 구조가 잘 지켜진 시스템이라고 할 수 있다.

application 은 자신의 하위 Layer 인 model, domain, framework, util 를 참조하는 것을 알 수

있으며, model 역시 자신의 하위 레이어를 다 참조하고 있는 것을 볼 수 있다. 물론 util 과 같은

공용 라이브러리가 변경된다면 다른 Component 들에 영향을 미치게 되지만, 최소한 Circular

Dependency 가 없기 때문에 적절하게 Layering 이 되었다고 볼 수 있다. 하지만 좀더 엄격하게

N 번째 Layer 는 N-1 번째 Layer 만 접근할 수 있게 Architecture 를 잡았다면, 해당 시스템은

다음과 같은 구조로 나와야 완벽하게 이루어진 것이라고 볼 수 있다.


78 SEC-2014-RM005

[그림 3-35] 완벽하게 Layering 이 이루어진 DSM

위의 DSM 을 보면 application 은 model 만 참조하고, model 은 domain 만 참조하는 형태로

만듦으로써, 변화를 국지화할 수 있는 좋은 장점을 얻을 수 있게 된다. 또한 공용 library 성향이

강한 util 이 바뀌더라도, 그 변화를 framework 가 모두 흡수할 수 있기 때문에, 최적의 좋은

구조라고 할 수 있다. 하지만 프로젝트를 진행할 때 실제로 이렇게 완벽한 Layering 을 구현하는

것은 그리 쉬운 작업이 아니다. 가장 대표적인 문제로 설계 중에서는 예측하지 못한 기능을

application 에 구현하려고 하는데, 만약 필요한 기능이 util 에서만 존재하고 있다면, 결국 framework,

domain, model 을 거쳐서 그 기능을 제공해야 하기 때문에 이러한 구조는 쉽게 구축하기 어렵다.

위의 두 DSM 만 봐도 전형적인 Layer 구조를 가진 것을 알 수 있고, 잘 구조가 잡혀서 개발

된 것을 알 수 있다. 그리고 위의 소프트웨어 시스템을 개발하면서 주기적으로 DSM을 체크하면서

보는데 어느 날 아래와 같은 DSM 를 보게 되었다고 가정해보자.

[그림 3-36] 문제가 발생한 DSM

util 에서 application 과 model 을 쓰는 즉 하위 레이어에서 상위레이어를 참조하는 상황이

p


79

발견된 것이다. 이러한 문제가 발생한 경우 해당 부분을 누가 util 쪽 라이브러리를 변경하여,

application, model 에 영향을 미쳤는지 파악하여야 하며, 형상 관리 시스템을 통해 담당자를

알아낸 후 왜 이럴 수 밖에 없었는지 자세히 애기를 나누어서 문제를 해결해 두어야 한다. 그리고

직접적인 순환 참조인 경우 새로운 패키지를 생성하고, 간접적인 참조인 경우 Interface 로

중개자 역할을 하게 하는 방법을 제시하여 문제를 풀어 나가야 한다.

이외에도 주의해야 될 상황으로 change propagator 를 주의 깊게 다루어야 할 필요성이 있다.

우선 아래의 DSM 이 있다고 가정해보자.

[그림 3-37] change propagator 와 관련된 DSM]

위의 DSM을 확인해보면 project namespace 에는 다양한 class 들이 존재하는 것을 확인할 수

있다. 여기에서 project namespace 를 자세히 보면 모든 class 가 Project 라는 class 를 참조하고

있다. 그리고 문제를 쉽게 해결하기 어렵게 Project 역시 다른 class 를 다 참조하고 있는 Circular

Dependency 가 발생한 것을 알 수 있다. 그런데 해당 DSM 을 좀더 자세히 보면 더 큰 문제가

숨겨져 있는 것을 알 수 있다. DSM에 6 번 ProjectLoader 을 확인해보면, ProjectLoader 는 다른

sub namespace 인 services 를 참조하고 있는 것을 알 수 있다. 즉 이것의 의미는 services 에서

어떠한 변화가 발생하여 ProjectLoader 에 영향을 미치면, ProjectLoader 는 다시 Project Class 에

영향을 미치게 되고, Project Class 를 참조하고 있는 다른 모든 Class 에게도 영향을 미치게 된다.

결국 하나의 변화가 파문을 일으키며 변화는 Ripple Effect 가 발생하게 된다는 것을 알 수 있다.

그렇기 때문에 이러한 일이 발생하지 않게 최소한 ProjectLoader 가 Services 의 모듈을 참조하지

않게 만들든 또는 Project 가 ProjectLoader 를 참조하지 않게 만들어야 한다.


80 SEC-2014-RM005

b) Composition View (계층 구조 기반의 의존성 그래프)

￭ 개요

DSM 을 기반으로 소프트웨어 시스템의 의존성을 분석하게 되면 클래스 다이어그램이나 소스

코드 분석에 비해 아키텍처를 보다 쉽게 파악할 수 있게 되며, 해당 소프트웨어 시스템이 가지고

있는 아키텍처적인 문제들을 비교적 발견하기 쉬워 진다. 그렇지만 DSM 은 분석하고자 하는

대상의 규모가 커지면 분석하기가 매우 힘들어지며 표에 나타나있는 의존성에 정확한 종류도

파악하기 힘들다. 거기다가 표를 기반으로 데이터를 시각화하기 때문에 분석가가 이를 기반으로

소프트웨어 시스템에 대한 전체적인 아키텍처를 직관적으로 바로 생각하기가 힘들다는 단점이

존재한다. 그래서 이러한 DSM의 단점들을 극복하기 위하여 소프트웨어 시스템의 의존성을 가중치를

가지는 방향 그래프 형태로 시각화하여 보여주는 방법을 활용하여 시각화하게 된다면 이러한

단점을 개선할 수 있다. 이는 DSM 이 기본적으로는 그래프 이론의 그래프를 표시하는 방법 중에

하나인 인접 행렬에서 파생되었다는 점을 고려하여, 이를 반대로 그래프로 그리게 되면 행렬을

표로서 표현하여 발생하는 시각화와 관련된 단점들을 개선할 수 있게 된다. 그리고 이러한 가중치를

가지는 방향 그래프를 시각화 할 때, 각 Vertex간의 참조에 따라서 계층 구조로 표현하여 제공한다면,

각각의 요소들의 의존성을 한눈에 확인할 수 있게 된다.

DSM Composition View

[그림 3-38] DSM 과 Composition View]

p


81

￭ 주요 특징

Composition View 도 DSM 과 마찬가지로 소프트웨어 시스템에 존재하는 다양한 요소들간

관계를 표 형태로 시각화하여 소프트웨어 시스템에 내제된 상호 참조(circular dependency) 문제를

발견하여. 파도 효과 (Ripple Effect - 하나의 변화가 다른 클래스, 패키지에 연쇄적으로 변화를

전파)를 사전에 제거할 수 있도록 도와준다. 그렇기 때문에 Composition View 를 구축하기 위한

기본 단계는 DSM 과 동일하게 진행된다. Composition View 는 우선 기본적으로 구성된 DSM 의

인접행렬 정보를 가지고 그래프를 생성하기 때문에, 우선적으로 DSM 을 생성한다. 그 다음 DSM

정보들을 그래프를 나타내는 인접 행렬로 생각하고 가중치를 가지는 방향 그래프를 구성하게

된다.

DSM 방향 그래프 구축

[그림 3-39] DSM 을 기반으로 방향 그래프를 구축

생성된 방향 그래프는 기본적으로 계층 정보를 가지고 있지 않을 것이다. 그렇기 때문에 소프트웨어에

포함된 계층 관계 구조를 파악할 수 없어 의존 정보를 파악하는데 여러모로 불편함이 존재한다.

그래서 Composition View 를 시각화할 때에는 이를 계층 구조 형태의 그래프로 표시할 수 있도록

계층 레이아웃을 생성하는 작업을 진행해야 한다. 일반적으로 방향 그래프를 계층 레이아웃을

만들기 위해서는 스기야마 알고리즘을 이용하여 레이아웃을 계산해야 한다. 그런데 스기야마

알고리즘의 경우 작업의 몇 가지 요소들이 NP-Hard 문제로 그리디 알고리즘을 기반으로 계산

해야만 한다. 그렇기 때문에 계산되는 계층 레이아웃은 항상 최적해를 가지지 않는다는 것에 유의해야

한다. 이렇게 생성된 레이아웃을 바탕으로 방향 그래프를 시각화하면 Composition View 가


82 SEC-2014-RM005

만들어지게 된다. 그리고 이 때 그래프의 Edge 를 그릴 때 대표적인 의존성(상속이나 참조 등)은

클래스 다이어그램에서 정의된 기호들을 사용하여 구성하게 되면 더욱 자세한 분석을 할 수

있게 된다.

￭ 장단점

Composition view는 DSM의 문제를 개량하기 위하여 나온 시각화 방법이기 때문에 기본적으로

소프트웨어 시스템의 의존성과 관련된 문제들을 발견하기 쉬운 것은 기본이며, 계층 구조 형태로

의존성을 시각화하기 때문에 소프트웨어의 의존 관계를 빠르게 파악할 수 있다. 또한 의존성의

종류를 표시해주지 않던 DSM 과는 다르게 대표적인 의존성으로 연결하는 방향 그래프의 선의

모양을 클래스 다이어그램 기호로 표시하여 보다 직관적으로 분석할 수 있게 도와준다. 또한 표

구조가 아닌 그래프 기반의 시각화이기 때문에 분석하고자 하는 소프트웨어 시스템의 크기가

매우 커도 충분히 분석할 수 있다.

장점

- 소프트웨어 시스템이 가지고 있는 아키텍처적인 문제들을 발견하기 매우 쉽다.

- 계층 구조를 이루고 있어 도메인들의 의존성을 파악하기 쉽다.

- 대표적인 의존성일 경우, Edge 의 모양을 해당 클래스 다이어그램 기호로 표시하여

직관적으로 파악할 수 있다.

- 소프트웨어 시스템의 전체적인 아키텍처를 파악하기가 쉽다.

- 소프트웨어 시스템의 규모가 커져도 충분히 분석 가능하다.

단점

- 시각화를 표시하기 위한 레이아웃 등을 계산할 때 많은 시간이 소모된다.

- 정형화 된 Chart 타입이 아니기 때문에 시각화 구현 시 어려움이 따른다.

￭ 기초 분석 방법

기본적으로 Composition View 또한 아주 간단하게 분석을 할 수 있다. 우선 다음과 같은

Composition View 가 있다고 가정해보자.

p


83

[그림 3-40] Composition View 예제

Composition View 는 기본적으로 각각의 정점(Vertex)들은 컴포넌트(클래스 or 패키지 등)을

의미하며 정점들은 연결하는 간선들은 컴포넌트간의 의존관계를 표시하게 된다. 그러므로 위의

Composition View 를 본다면 PackageA 는 PackageB, PackageD 와 의존 관계가 있으며

PackageD 는 PackageA 와 PackageC 와 의존관계가 있다는 것을 확인할 수 있다.

그리고 DSM 과 마찬가지로 Composition View 에서도 Circular Dependency 가 존재하는 것을

쉽게 확인할 수 있다. 위의 Composition View에서 보면 PackageA 와 PackageD 사이에 상호간을

연결하는 간선이 존재하거나 Composition View 안에 사이클(시작 노드에서 간선들을 지나서

다시 시작노드로 돌아오는 경로가 존재하는 경우)이 존재한다면 분석한 소프트웨어 시스템에는

Circular Dependency 가 있다고 할 수 있다.


84 SEC-2014-RM005

[그림 3-41] Composition View 안에 사이클이 존재하면 Circular Dependency 가 존재

이렇게 Composition View 를 이용하여 의존성을 분석하게 되면 테이블 형태로 표현되어서

개수가 늘어나면 알아보기 힘들어지는 DSM 에 비하여 매우 알아보기 쉽기 때문에 의존성

문제들을 찾는데 보다 효율적으로 처리할 수 있게 된다.

￭ 응용 분석 방법

앞서 이야기 했던 것처럼 의존성에 대한 문제들은 해결하는 가정 대표적인 방법들은 Layering 을

이용한 방법이라고 소개하며 이를 DSM 을 통하여 적용하는 방법들에 대하여 소개하였다.

이번에는 DSM 이 아닌 Composition View 를 이용하여 이를 처리하는 방법에 대하여 소개

하겠다. 우선 앞에서와 똑같은 application, model, domain, framework, util 순으로 layer 구조로

설계된 시스템이 있다고 가정하고, 이를 분석하니 아래와 같은 Composition View 가 나왔다고

하자.

보는 것과 같이 Composition View 에서는 의존성을 방향을 가지는 화살표 형태로 표시해주기

때문에 직관적으로 컴포넌트간의 관계를 파악하는데 도움이 된다. 또한 DSM 에서는 데이터간의

Layering 관계를 파악하기 위해서는 데이터를 한번 더 가공해야 하는 과정이 필요하지만(예제

DSM 은 이해를 돕기 위해 구성한 예제) Composition View 에서는 계층화된 형태로 시각화를

p


85

진행하기 때문에 시스템의 Layer 구조를 바로 파악할 수 있으며, 거기다가 추가적으로 전체적인

구조와 흐름 또한 한 눈에 파악할 수 있다. 그렇기 때문에 Composition View 를 이용하면

DSM 보다 더 쉽게 Layering 을 구축할 수 있게 된다.

DSM 의 모습 Composition View 의 모습

[그림 3-42] 일반적인 DSM 과 Composition View 의 모습

그렇다면 완벽하게 Layer 를 이루고 있는 시스템의 경우 DSM 에서는 대각선으로만 숫자들이

몰려있던 모습이었는데, Composition View 에서는 어떠한 형태를 이루고 있는지 확인해보면

아래의 그림과 같이 선형 리스트와 같은 형태로 그래프가 그려지게 된다. 즉 바로 하위 레이어를

통해서만 기능에 접근하는 전형적으로 잘 구축된 Layer 시스템의 모습을 반영하여 보여주게

된다.


86 SEC-2014-RM005


[그림 3-43] Layer 가 잘 구축된 시스템의 DSM 과 Composition View 의 모습

지금까지 Composition view 를 이용하여 소프트웨어 시스템의 Layering 을 체크하는 방법들에

대하여 이야기 하였다. 그렇다면 Composition View 에서는 Circular Dependency 와 같은 의존성

문제를 어떠한 식으로 확인할 수 있는지 살펴보겠다.


[그림 3-44] 의존성 문제가 있는 시스템의 DSM 과 Composition View 의 모습

p


87

DSM 의 경우 대각선을 기준으로 위의 참조가 있음을 보여주는 형태로 의존성 문제를 알려

주는데, Composition View 에서는 바로 시각적으로 화살표가 아래 방향이 아닌 역으로 올라가고

있는 요소들이 역 참조, 즉 의존성 문제를 일으키는 원인으로 표시해준다. 물론 위와 같이

단순한 문제의 경우에는 DSM이나 Composition View 둘 다 문제를 쉽게 발견할 수 있다. 그러나

복잡도가 높은 경우나 위와 같은 직접적인 Circular Dependency 가 아닌 간접적으로 발생하는

Circular Dependency 들은 DSM 으로 문제를 바로 파악하기에는 힘든 담점이 있다. 그러나

Composition View 는 의존성 구조를 그래프 형태로 시각화하여 보여주기 때문에 복잡한 구조나

간접적으로 얽혀있는 의존성 문제들도 쉽게 파악할 수 있다. 특히 간접적으로 얽혀있는 의존성

문제들은 표시되는 그래프의 특성 중 사이클(시작점에서 간선들을 걸쳐 다시 시작점으로 돌아오는

경우)이 발생되는 부분을 파악하면 해당 부분이 의존성 문제가 되는 곳을 바로 파악할 수 있다.

지금까지 Composition View 를 이용하여 문제를 분석하는 방법에 대하여 소개하였다. Composition

View 는 DSM 에 문제를 파악하기 힘들다는 문제를 개선하여 보다 파악하기 쉬운 뷰를 제공하기

때문에 시스템에 존재하는 의존성을 분석할 때 많은 도움이 된다.

다. 분석 범위에 따른 의존성 시각화 차트

a) 개요

의존성 시각화 차트는 소프트웨어 시스템에 존재하는 다양한 의존성들을 분석하는 용도로

사용되는 시각화 방법이기 때문에 무엇보다 분석하고자 하는 범위가 중요한 요소이다. 그렇기

때문에 의존성 시각화 차트는 크게 3 가지의 분석 범위를 가지고 있다. 그중에서도 일반적으로

가장 많이 사용되는 요소가 바로 시스템 전체를 분석하는 전체 분석이 있으며, 이 외에 컴포넌트를

중심으로 연관된 요소들을 분석하는 커플링 분석 방식, 그리고 사용자가 원하는 컴포넌트들간의

관계를 분석하는 샌드박스 분석 방식이 존재한다.


88 SEC-2014-RM005

전체 분석 샌드박스 분석

커플링 분석

b) 전체 분석

전체분석은 의존성 시각화 방법에서 가장 일반적으로 사용되는 방법으로 분석하고자 하는 시스템의

전체를 분석하는 분석법을 이야기 한다. 이 분석 방법은 시스템 전체를 분석하기 때문에 전체적인

의존성 문제를 파악할 수 있다는 장점이 있지만 시스템의 규모가 매우 커지게 되면 아무리

시각화된 요소라고 할지라도 전체 구조를 분석하기에 매우 많은 시간이 필요하게 되며, 오히려

사용자가 집중하고자 하는 문제에 집중하지 못하게 되는 단점이 발생하게 된다. 그렇기 때문에

p


89

장점 단점

- 시스템 전체 구조를 보여주기 때문에 모든 문제들을

확인할 수 있다.

- 전체 구조를 통해 의존성의 흐름을 알 수 있다.

- 시스템의 적절한 Layering 을 체크할 수 있다.

- 시스템의 규모가 매우 커지면 분석에 오랜 시간이

걸린다.

- 전체 구조를 보여주기 때문에 집중하고자 하는

부분을 놓칠 수 있다.

전체분석은 시스템의 전체적인 큰 흐름을 파악하거나 가장 대표적인 의존성 문제들을 찾을 때

이용하거나 작은 문제들의 원인을 추정할 때 이용하는 것이 가장 적당하다.

[그림 3-45] 오픈소스 PMD 패키지의 일부

c) 커플링 분석

커플링 분석은 전체분석이 사용자가 집중하고자 하는 문제를 집중할 수 없다는 단점을 개선하기

위하여 자신이 집중적으로 보고자하는 컴포넌트의 의존성을 In 방향(해당 컴포넌트를 의존하는

요소)과 out 방향(해당 컴포넌트가 의존하는 요소)으로 나누어서 하나의 컴포넌트와 관련된 모든

의존성을 보여주는 분석 방식이다. 이 방식은 기본적으로 개발자가 보고 싶어하는 컴포넌트를


90 SEC-2014-RM005

중심으로 의존성을 보여주기 때문에 자신이 분석 하고자 하는 부분을 확실하게 파악할 수 있다.

하지만 커플링 분석은 자신과 직접적으로 연관된 컴포넌트들만을 보여주기 때문에 간접적으로

연결된 컴포넌트들은 표시해주지 않는다. 그렇기 때문에 커플링 분석 방법으로는 직접적으로

발생하는 Circular dependency 를 파악할 수는 있지만 간접적으로 연결되는 Circular dependency 를

파악할 수 없다는 단점을 가지고 있다.

[그림 3-46] 오픈소스 PMD 의 커플링 분석]

장점 단점

- 하나의 컴포넌트만을 중심으로 분석할 수 있다.

- 자신이 분석하고자 하는 컴포넌트에 집중하여

분석할 수 있다.

- 의존성을 컴포넌트가 의존하는 요소와 의존 당하는

요소로 분류하여 표시해준다.

- 컴포넌트와 직접적인 의존이 있는 요소만 보여

주어서 간접적인 의존성은 파악할 수 없다.

- Layer 구조를 파악할 수 없다.

p


91

c) 샌드박스 분석

샌드박스 분석은 전체 분석의 장점과 커플링 분석의 장점을 합친 방법으로 자신이 선택한

컴포넌트간의 의존성을 분석하는 방법으로 커플링 분석 방법에서 사용자가 관심이 있는 컴포넌트를

집중해서 보여주는 것을 확장하여 자신이 관심이 있는 컴포넌트들 간의 의존성을 보여주는 분석

방식이다. 그렇기 때문에 커플링이 가지고 있던 간접적인 의존성을 분석할 수 없다는 점이 개선되었으며

전체 분석 방법이 가지고 있는 문제 요소의 집중할 수 없다는 점도 개선되었다. 하지만 샌드박스

분석 또한 자신이 선택한 컴포넌트들 간의 의존성만을 보여주기 때문에 미처 선택하지 못한

컴포넌트들이 가지고 있는 문제는 표시되지 않는다. 그렇기 때문에 실제 의존성 문제를 파악할

때에는 각 분석 범위의 특징을 활용하여 3 가지 범위를 섞어서 사용해야한다.

장점 단점

- 사용자가 원하는 여러 컴포넌트를 선택하여 분석할

수 있다.

- 자신이 분석하고자 하는 컴포넌트에 집중하여

분석할 수 있다.

- 선택한 컴포넌트간의 의존성의 흐름을 알 수

있다.

- 선택하지 않은 컴포넌트의 의존성은 파악할 수

없다.


92 SEC-2014-RM005

3. 크기 시각화 차트

가. 개요

소프트웨어 시스템이 거대해지게 되면 아키텍처적인 문제점을 가질 수 있게 되며, 너무 작은

객체들은 기능이 분산되어 관리하기가 힘들어지게 된다. 그렇기 때문에 소프트웨어 시스템의

구성 요소들을 적절한 수준의 크기로 유지 시키는 작업은 아키텍처를 관리하는데 있어서 매우

중요한 요소이다. 그렇기 때문에 소프트웨어 시스템의 안정적인 아키텍처를 유지하기 위해서는,

아키텍쳐의 가장 기본이 되는 개념 중 하나인 Level of Scale 을 지키기 위해서 도메인 레벨 별로

크기를 볼 수 있어야 한다. 패키지면 패키지 레벨에서 크기를 볼 수 있어야 하고 클래스면 클래스

레벨에서 크기를 볼 수 있는 시각화 기법이 필요한데, 그 대안으로 바로 소프트웨어 시스템의

크기를 시각화해주는 크기 시각화(Size of Component) 방법이 존재한다.

크기 시각화 차트 방법은 시각화 방식에 따라 크게 두 가지의 방법이 존재하는데, 같은 수준의

범위에서만 소프트웨어의 크기를 시각화하는 동급 크기 시각화 방식과, 모든 범위에서 소프트웨어의

크기를 시각화 해주는 전체 크기 시각화 방식까지 총 2 가지로 나누어진다. 지금부터는 이러한

크기 시각화 차트들의 특성과 분석 방법에 대하여 중점적으로 소개하겠다.

동급 크기 시각화 방식 전체 크기 시각화 방식

[그림 3-47] 크기 시각화 차트의 구성

p


93

나. 크기 시각화에서의 크기의 결정

크기 시각화 방식에서 일반적으로 각각의 컴포넌트간의 크기를 결정하는 방식은 다양하게

존재할 수 있지만 일반적으로는 Class 나 메소드와 같은 컴포넌트들의 크기는 다양한 Metric 수치

증, 실제로 의미 있는 코드의 라인 수를 나타내주는 ELOC(Estimated Line of Code)를 이용하는

것이 일반적이다(물론 경우에 따라서 다른 요소를 기준으로 사용할 수 있다). 그래서 이를 확장하여

실제적으로 소스코드가 존재하지 않는 패키지와 패키지 셋은 해당 컴포넌트들의 내부에

존재하는 요소들의 크기의 합으로 결정된다.

[그림 3-48] 크기의 결정 방식

다. 동급 크기 시각화 방식

a) 개요

동급 크기 시각화 방식은 다양한 수준으로 나누어져있는 컴포넌트들을 같은 수준(같은 패키지

안, 또는 같은 클래스 안)인 경우에만 표시해주어서 동등한 수준의 컴포넌트들의 크기를 비교할

수 있도록 도와주는 시각화 방식이다.

이러한 동급 크기 시각화 방식은 컴포넌트가 시스템 전체에서 차지하는 비중이 어느 정도인지

파악하기는 힘들지만 같은 동급 수준에서 얼마큼 비중을 차지하는지 알 수 있기 때문에 시스템에서의

코드 비중이 어느 정도 되는지 파악할 수 있어 적절한 코드 길이 수준을 유지하는데 도움을 줄

수 있다.


94 SEC-2014-RM005

b) 생성 방식

등급 크기 시각화 방식을 구현하는 방법은 우선 분석하고자 하는 수준에서 존재하는 컴포넌트들의

크기를 구하는 것부터 시작한다. 컴포넌트들의 크기는 위에서 설명했던 것처럼 크기의 역할을

하는 Metric 인 ELOC 나 다른 기준이 되는 다른 Metric 수치를 계산하는 것부터 시작하면 된다.

이러한 과정 후 아래와 같이 기준이 되는 Metric 수치들이 추출되었다고 가정하겠다.

컴포넌트 명 크기(ELOC 기준) 비율(%)

Application 608 62.8%

Domain 117 12.2%

Framework 31 3.2%

Model 206 21.2%

Util 6 0.6%

전체 968 100%

[표. 예제 ELOC 수치]

그 후 해당 요소들의 값들을 전부 더하여 분석하고자 하는 범위 내의 전체 ELOC 를 계산한

후, 이를 바탕으로 전체 비율을 계산 한다. 이 비율을 바탕으로 아래와 같이 동급 크기 시각화 차트를

구성하면 된다.

[그림 3-49] 구성된 동급 크기 시각화 차트

p


95

c) 분석 방법

대체적으로 크기 시각화 차트를 분석하는 방법은 매우 간단한 편에 속하는데, 그 중에서도

동급 크기 시각화는 더욱 간단하다. 앞에서 설명한 것처럼 전체 시각화 영역에서 해당 컴포넌트가

차지하고 있는 영역의 크기가 바로 해당 컴포넌트가 분석 수준에서의 차지하고 있는 비율을

의미하게 된다.

그렇다면 이러한 동급 크기 시각화 차트를 이용하여 어떠한 문제를 해결할 수 있는지 알아보면,

우선 아래와 같은 동급 크기 시각화 차트가 존재한다고 생각해보자.

[그림 3-50] 동급 크기 시각화 예제

위의 등급 크기 시각화 차트에서 다른 요소들보다 ast 컴포넌트(패키지)가 차지하는 비중이

다른 요소들에 비하여 큰 것을 확인할 수 있다. 그렇기 때문에 해당 요소 안에는 다양한 처리

로직들이 포함되어 있다는 것을 추정할 수 있다. 그래서 이렇게 거대한 컴포넌트들은 차후의 변화에

적절한 대응을 하기 위해서는 내용을 분리하는 작업을 하여 변화에 여파에 강인하게 만들

필요성이 있다.

이와 반대로 위의 등급 크기 시각화 차트에서 빨간색으로 표시된 컴포넌트같이 지나치게 작게

만들어진 컴포넌트들은 과도한 분할이 된 요소라고 판단할 수 있다. 위에서처럼 지나치게 크기가

커지게 되면 컴포넌트를 관리하기 매우 힘들어지지만 반대로 매우 작아져도 이들을 관리하기가

힘들어진다. 그렇기 때문에 이렇게 작은 컴포넌트들은 다른 요소들과 합쳐서 관리할 필요가 있다.


96 SEC-2014-RM005

라. 전체 크기 시각화 방식

a) 개요

동급 크기 시각화의 경우 지정한 특정 수준에서 존재하는 컴포넌트들의 크기만을 보여주기

때문에 전체 범위에서의 컴포넌트 비중들이 어떻게 되는지 파악하기가 힘들다. 그렇기 때문에

이러한 점을 보완하기 위하여 소프트웨어 시스템 전체의 구성을 보여주는 것이 전체 크기 시각화

방식이다. 이 시각화를 이용하면 시스템 내부에 존재하는 모든 컴포넌트들의 비중을 한눈에

파악할 수 있게 되지만 이는 시스템의 크기가 커지면 커질 수 록 해당 시스템의 구성을 파악하기가

매우 힘들어진다. 그래서 대다수의 경우 전체 크기 시각화는 플립효과나 줌효과를 이용하여 전체

크기 시각화 차트를 부분 적으로 볼 수 있는 기능을 제공해주고 있다.

전체 크기 시각화 차트 부분적으로 확대하여 확인할 수 있다.

b) 분석 방식

기본적으로 전체 크기 시각화의 분석 방식은 동급 시각화 차트와 마찬가지로 각 컴포넌트가

차지하는 해당 크기가 분석한 시스템에서 차지하는 크기 비중을 나타나게 된다. 하지만 동급

크기 시각화에서와는 다르게 분석하고자 하는 범위가 매우 크기 때문에 요소의 크기가 너무

작아서 나타나지 않는 부분들이 있을 수 도 있다. 그렇기 때문에 전체 크기 시각화에서는 대략적인

p


97

시스템의 크기 비율을 확인하고 어떤 부분을 먼저 수정해야할지 전략을 수립하는 목적으로

사용하는 것이 가장 좋다고 할 수 있다. 그러므로 실제 분석을 진행할 때에는 전체 크기 시각화

차트를 이용하여 대략적인 변경 대상들을 선정하고, 동급 크기 시각화 차트를 이용하여 세부적인

컴포넌트들을 확인하면서 수정하는 방식으로 진행하는 것이 가장 좋다고 할 수 있다.

4. 추상화 지표 차트(Robert C. Martin Instability/Abstractness).

가. 개요

아키텍쳐를 수립하고 작업을 진행하면서 각 서브시스템에 대해 얼마나 추상화해야 할 것인지는

매우 중요한 일이다. 추상화해야 할 부분이 추상화 되어 있지 않고 단순 객체들의 나열로 되어

있다면 변화를 흡수 할 수 없어 유연하지 못하고 확장 불가능한 아키텍처를 가지게 되고 그

반대로 추상화 하지 않아도 될 것을 추상화 하게 된다면 변화에 빠르게 대처하기 힘들어 요구사항을

빠르게 대응하기 힘들다. 앞서 이야기했던 Metric 지표들 중에서 컴퓨터 과학계의 대가 Robert

C. Martin 이 제시한 Instability / Abstractness 수치는 소스 코드내에서 각각의 레이어 간의

의존성을 나타내 주어 앞서 설명한 문제점들을 수치적으로 판단할 수 있게 도와주는 역할을 한다.

이번 시각화 방법에서는 바로 이 Instability / Abstractness 수치를 기반으로 구성되는 추상화

지표 차트에 대하여서 구체적으로 설명할 것이다.

나. 기본 설명

기본적으로 추상화 지표 차트는 패키지 수준에서, 패키지가 추상화가 잘되어 있는지 안되어

있는지 쉽게 파악할 수 있게 해준다. 이 추상화 지표 차트는 기본적으로 컴포넌트 내부에서 다른

요소를 얼마나 참조하고 있는지 보여주는 “Afferent Coupling”, 참조를 얼마나 당하고 있는지

보여주는 “Efferent Coupling”, 추상화가 얼마나 되었나 보여주는 “추상화 정도", 이러한 Metric

지표들을 우선적으로 계산하여 이를 기반으로 추상화가 필요한 패키지를 한눈에 볼 수 있는

추상화 지표 차트(Robert C. Martin 차트)를 그릴 수 있도록 해준다.


98 SEC-2014-RM005

[그림 3-51] 추상화 지표 차트의 예

추상화 지표 차트는 Robert C. Martin이 제시한 패키지 이상 수준에서의 추상화 수준을 분석하기

위해 제시한 차트로서, 왜냐하면 Class 도메인 하위 레벨로는 추상화 정도를 전혀 알 수 없기

때문에 Class 도메인들이 모인 하나의 작은 서브 시스템을 구축 할 수 있는 최소 단위인 Pakcage

도메인 수준에서 작성된다.

Instability 는 이 도메인이 변경할 수 있는 여력, 즉 다른 곳에서 얼마나 많이 참조하고 있는지

알 수 있는 지표이다. 값이 0 으로 근접 할수록 다른 패키지 도메인에서 많이 참조하고 있어

지금의 패키지 도메인을 변경할 여력이 적은 것이다. Abstractness 는 Interface, Abstract

Class 들이 패키지 도메인 내부에 포함되어 있는지 나타낸다. 역시 값이 0 으로 근접할수록 전혀

추상화 되어있지 않는 것을 알 수 있다.

p


99

처음으로 Instability 를 구하기 위해서는 일단 기존의 Metric 패턴에서 구했던 정보 중

Afferent Coupling 과 Efferent Coupling 을 알아야 한다. 위의 그림과 같이 Ca 는 다른 곳에서

이 패키지를 얼마나 많이 다른 패키지가 참조하고 있는지 표현한 값이고 반대로 Ce 는 이

패키지가 다른 패키지를 참조하고 있는 값을 나타낸다.

Instability 는 변경할 수 있는 여력이라 설명하였다. 밑의 수식과 같이 Afferent Coupling 즉

Ca 값이 늘어날수록 0 에 근접한다. 다른 패키지 도메인에서 이 패키지 도메인을 많이

참조하는지 알 수 있는 Ca 값을 통해 Instability 의 속성을 알 수 있다.

[Instability 수식]

그리고 얼마나 추상화되었는지 알 수 있는 Abstractness 의 수식은 다음과 같다.

[Abstractness 수식]

이는 지금 패키지 도메인에 얼마나 많은 인터페이스나 추상클래스들의 비율이 높은지 알 수

있도록 해주는 Metric 이 된다.

Instability 와 Abstractness 의 값들을 통해 적절한 추상화 수준을 알 수 있는 기준이 Chart 에서

대각선으로 표시된 Main Sequence 이다. Main Sequence 는 Abstractness 와 Instability 의 값이

1 이 되는 시점이다. 이를 통해 다른 패키지 도메인에서 참조를 많이 당해 Instability 가 낮은

값은 Abstractness 값이 높아야 한다는 것을 알 수 있다. 자세히 설명하면 많이 참조 당할수록

추상화 정도가 늘어나야 한다는 것이고 반대로 보면 적게 참조 당할수록 추상화 정도가 낮아야

한다는 것이다.

[Main Sequence 수식]


100 SEC-2014-RM005

결국 Main Sequence 는 Instability 와 Abstractness 의 값의 합이 1 이 되는 지점을 뜻하고 이

선에 근접한 패키지 도메인은 적절한 추상화를 이루었다고 판단 할 수 있다.

마지막으로 Distance 는 Main Sequence 에서 얼마나 떨어져 있는지 알 수 있는 값이다. Distance

값이 높으면 높을수록 Main Squence 와 멀리 떨어져 있다는 것을 의미한다. 그래서

Distance 값이 높은 패키지 도메인은 추상화 수준을 조정해야 한다는 것을 알 수 있다.

[Distance 수식]

예를 들어 설명하면 아래의 그림에서 A 는 많은 참조를 당해 추상화 해줘야 하는데 추상화

정도가 선에서 많이 떨어져 있기 때문에 매우 부족한 것을 알 수 있다. B 는 선에 근접하여

적절한 추상화가 되어있는 것을 알 수 있다. 마지막으로 C 는 외부에서 C 를 적게 참조하고

있어서 변화를 주어도 큰 문제가 되지 않는다. 그런데 그림에서 보면 선을 넘어 필요 이상으로

추상화 되어 있는 것을 알 수 있다.

[그림 3-52] 추상화 지표 차트 분석 예제

p


101

이와 같이 각 패키지 도메인들의 추상화 정도를 시각화 해줌으로써 한눈에 추상화 정도가

부족하거나 과하여 문제가 될 수 있는 패키지 도메인들을 바로 바로 파악 할 수 있다.

다. 장단점 및 활용

추상화 지표 차트는 사용자가 분석한 시스템에 대하여 내부 컴포넌트(패키지 등)이 적절하게

추상화과 되고 있는지 아니면 너무 과도하게 추상화가 되고 있는지 확인할 수 있는 뷰를 제공해

준다. 하지만 이 차트에 사용되는 Metric 지표들이 약간은 어려운 지표들이기 때문에 사용자가

약간의 학습을 할 필요성이 있다.

그러나 이러한 추상화 지표 차트를 이용하면 문제가 있는 요소들에 적절한 안전장치들 (인터페이스,

레이어, Parameter Object)를 사용해, 변화의 전파를 흡수할 수 있게 구성하게 되며 차후 유지보수를

보다 편하고 쉽게 할 수 있으며, 시스템의 확장성 또한 구축할 수 있을 것이다.

5. Pollution 시각화 차트

가. 개요

소프트웨어 개발을 진행하면서 문제점을 미리 파악하는 것은 품질 향상 및 비용절감에 도움이

된다. 그로 인해 문제점을 미리 파악하는 것이 중요해지고 있다. 하지만 소프트웨어들은 점점 더

거대해 지고 있어 시스템 안에 내제된 아키텍처적인 문제점을 일일이 파악하기 어려운 것이

지금의 현실 상황이다. 그래서 앞서 소개된 다양한 Metric 들을 활용할 필요성이 있지만 이는

Metic 에 대한 정확한 이해가 없는 사용자들에게 아무런 가치 있는 정보들을 제공해주지 못하는

단순히 숫자 나열처럼 느껴지게 된다. 이는 Metric 이 단순히 수치 형태로 표시되기 때문에, 이

수치가 적당한 것인지 아닌지 쉽게 알 수 있는 방법이 필요하다.

이러한 이유에서 만들어진 Pollution 시각화 차트는 사용자에게 어떠한 Metric 에서 문제가

발생했는지 알려주어서 소프트웨어 시스템에 내제된 문제들을 사전에 알려주기 위한 기능을

하는 시각화 차트들이다. 기본적으로 Pollution 시각화 차트는 차트의 생성 방식에 따라 2 종류

차트로 구분 지을 수 있는데 bar 차트를 활용하는 bar pollution 차트와 도넛형 차트를 활용한

도넛형 Pollution 차트가 존재한다. 지금부터는 Pollution 차트들의 특징들에 대해서 구체적으로

설명하겠다.


102 SEC-2014-RM005

Bar 형 Pollution 차트

도넛형 Pollution 차트

p


103

나. Pollution 기준 선정

오염도 시각화 차트에서 오염도의 기준이 되는 요소들은 모두 앞서 설명하였던 다양한 Metric 들이

기준이 된다. 그러나 이러한 Metric 들은 단순히 수치 정보만 가지고 있기 때문에 이 정보만으로는

사용자에게 어느 정도가 위험한 수준이고 적당한 수준인지 알려줄 수 없다. 그러므로 Pollution 을

시각화하기 위해서는 Metric 의 수치들을 적절하게 3 단계(위험, 경고, 정상)과 같은 형태로 분류화

할 수 있어야 한다.

그러나 위에서 소개하였듯이 Metric 들의 종류는 매우 다양하게 존재하며 각각의 수치 정보들도

규격화되어 있지 않아 이 정보들을 통제하기란 매우 어려운 일이다. 더군다나 분석하고자 하는

소프트웨어 시스템의 성격에 따라서 Metric 의 수치가 변동되는 경우도 존재한다. 그렇기 때문에

정확한 기준을 세우기란 매우 어렵다고 할 수 있다. 그래서 대다수의 Pollution 시각화를 해주는

소프트웨어에서는 자신들만의 기준을 만들어 두거나 사용자가 임의로 설정할 수 있게 만들어진다.

그러므로 Pollution 에 완벽한 기준이란 존재하지 않으며 자신이 분석한 소프트웨어 시스템에

100% 적합하지 않은 기준일 수 도 있다. 하지만 Tangled 나 Cyclomatic Complexity 와 같이

일반적으로 통용동되는 Metric 들의 기준은 대다수의 소프트웨어 시스템에서 거의 유사한 기준으로

판단하여도 되기 때문에 Pollution 시각화 차트를 참고할 때에는 일반적으로 통용되는 기준들은

그대로 참고하여도 되며, 그렇지 않은 기준들 자신이 분석한 소프트웨어 시스템의 성향을 고려하여

적절하게 판단해야 한다.

다. 바형 Pollution 차트

a) 개요

바형 Pollution 차트는 분석한 소프트웨어 시스템에 존재하는 모든 오염도(Metric 기준을 초과하는

요소들)의 수를 각 종류별로 카운팅하여 그 요소를 그대로 바 형태의 차트로 표시해주는 시각화

방식이다. 이 방식은 소프트웨어 시스템에서 검출된 모든 오염도의 수를 다른 변화를 주지 않고

그대로 표시해주기 때문에 현재 시스템에 상황을 그대로 파악할 수 있다. 하지만 오염도에는

앞서 이야기한 것처럼 시스템의 성격이나 Metric 의 성격에 따라서 우선순위가 높은 요소들이

존재하는데, 이 바형 Pollution 차트에서는 이러한 우선순위에 대한 고려를 전혀 하지 않는다. 즉

Tangled 와 같이 소프트웨어 시스템의 심각한 문제를 야기할 수 있는 문제가 발생하여도 다른

문제들과 같이 카운팅 숫자로 Bar 차트에 표시되기 때문에 어떤 것이 더 큰 문제 인지 알 수


104 SEC-2014-RM005

없다.

그렇지만 Bar 형 Pollution 차트에서는 시스템에서 발생한 모든 오염도의 수들을 그대로 보여주기

때문에 전체적인 오염도들을 파악하여 문제를 줄여나가는 용도로는 용이하게 사용할 수 있다.

b) 분석 방법

바형 Pollution 시각화 차트를 분석하는 방법은 매우 간단하다. 아래와 같은 Pollution 차트가

있다가 가정해보자.

[그림 3-53] Bar 형 Pollution 시각화 차트

위의 차트를 보았을 때 가장 문제가 있어 보이는 부분은 ELOC(가장 첫 번째 요소)가 가장

심각한 문제인 것처럼 착각할 수 도 있지만, 이 시각화 방법의 특성을 생각해본다면 바의 크기는

단순히 오염도의 개수를 의미하는 것이다. 실제로 ELOC 가 높은 것은 장기적으로 보았을 때

문제가 될 수도 있는 부분이지만 시스템 내에 Tangled와 같은 문제가 발생했다면 가장 최우선적으로

개선해야 할 요소는 바로 Tangled 이다. 위의 차트에서도 Tangled 오염도를 포함하고 있지만

그 오염도의 개수가 단순히 10 개이고, ELOC 오염도가 88 이기 때문에 단순히 수치적으로 작아서

이러한 시각화 차트가 나타나게 되었다.

p


105

그러므로 Bar 형 Pollution 시각화 차트를 이용하게 될 때에는 사용자가 분석한 소프트웨어

시스템에서 가장 중점적으로 보아야할 요소가 어떠한 것인지 결정해서 해당 요소를 우선적으로

오염도를 제거해 나갈 수 있도록 문제를 해결해야 한다.

라. 도넛형 Pollution 차트

a) 개요

앞서 이야기 하였던 Bar 형 Pollution 차트는 오염도의 발생 횟수를 기반으로 시각화를 진행하기

때문에 어떤 부분을 우선적으로 처리해야할 지 알 수 있는 방법이 존재하지 않는다. 그렇기

때문에 도넛형 Pollution 차트에서는 이러한 문제를 개선하여 보편적으로 우선적으로 처리해야할

아키텍처 문제들을 나타내는 지표들에 값들을 보정히여 다른 요소들 보다 더 크게 표현해주어서

Pollution 차트를 보는 사용자에게 차트에서 가장 큰 비유을 차지하는 요소가 우선적으로 처리해야하는

요소라는 것을 직관적으로 받아들 수 있도록 구성된 차트이다.

하지만 반대로 이 도넛형 Pollution 차트의 경우 우선순위 별로 오염도의 비유을 가공하기

때문에 실제로 분석한 소프트웨어 시스템에 오염도들의 수를 파악하기에는 어렵다는 단점이 발생하게

된다. 그렇기 때문에 실제 Pollution 차트를 활용할 때에는 이 두가지 종류의 차트를 복합적으로

활용하면 큰 도움을 얻을 수 있을 것이다.

b) 분석 방법

Bar 형 Pollution 차트와 달리 도넛형 Pollution 차트에서는 가장 심각한 오염도는 차트에서

가장 많은 비율을 차지하고 있는 요소라고 생각하고 차트를 바라보면 된다. 다음 그림과 같은

차트가 있다고 가정해보자.


106 SEC-2014-RM005

[그림 3-54] 도넛형 Pollution 차트 예제

위의 차트를 보면 가장 문제가 되는 Tangled 오염도가 가장 큰 문제로 표시되고 있고, 그

다음으로 Fat 오염도가 큰 문제로 파악된다. 그러므로 이 차트를 사용하는 사용자는 가능 큰

오염도인 Tangled 가 발생한 지점부터 해결해나가면 시스템에서 가장 문제가 되는 부분들을

수정해나가는 것이라고 볼 수 있다.

6. 혼합 시각화 차트

가. 개요

지금까지 의존성 시각화 차트부터, Pollution 시각화 차트까지 다양한 아키텍처 시각화 차트들에

대해서 소개하였는데, 이 차트들은 기본적으로 다른 요소들과 섞이지 않은 단일 차트들이었다.

그러나 실제로 활용할 때에는 이들을 서로 복합적으로 혼합하여 사용하는 경우들도 존재한다.

가장 대표적인 예로는 크기 시각화 차트와 Pollution 차트와의 혼합 차트를 생각해볼 수 있으며,

의존성 시각화 차트와 크기 시각화 차트의 혼합도 생각해볼 수 있다. 이번 장에서는 다양한 혼합

시각화 차트들 중에서 가장 많이 사용되는 두 경우에 대하여 설명하겠다.

p


107

크기 시각화 차트와 Pollution 시각화 차트의 결합

의존성 시각화 차트와 크기 시각 화 차트의 결합

나. 크기 시각화 차트와 Pollution 시각화 차트의 결합

a) 개요

크기 시각화 차트에서는 단순하게 각각의 컴포넌트들의 단순한 크기 정보만을 표시하는

시각화 차트이다. 그렇기 때문에 다른 시각화 차트들에 비하여 제공해주는 정보가 적은 편이라고

할 수 있다. 그래서 크기 시각화 차트에 추가적인 정보를 제공해주기 위하여 다른 차트들과의


108 SEC-2014-RM005

결합을 생각할 수 있다. 그래서 나온 것이 바로 이 크기 시각화 차트와 Pollution 시각화 차트의

결합으로 단순한 크기 시각화 차트에 Pollution 정보들 중에서 하나를 선택하여 크기 시각화 차트에

결합하여 표시하는 바로 이 결합 시각화 차트이다.

이 차트는 기본적으로 크기 시각화 차트에서는 크기 정보를 시각화 요소(사각형이나 동그라미)에서의

크기로 표현하는데, 색과 같은 요소에는 단순히 그룹핑이외에는 아무런 정보를 주지 않는다. 그래서

복합 차트에서는 이 점을 활용하여 Pollution 에서 사용하는 오염도 요소 중 하나를 선택하여 각

컴포넌트들의 해당 오염도의 수준을 색으로 표시해주는 방법을 이용하여 크기 시각화와 Pollution

시각화의 일부 정보까지 표현해줄 수 있도록 구성되어 있다.

[그림 3-55] 크기 시각화 차트는 크기 이외의 정보를 주지 않는다

b) 분석 방법

기본적으로 이 결합 차트의 분석은 크기 시각화 차트와 유사하다. 단지 크기 시각화 차트에서는

존재하지 않던 색에 대한 요소에 Pollution 정보가 추가된 것이므로 이것에 유의하여 내용을

해석하면 된다. 그럼 다음과 같은 복합 차트가 있다고 가정해보자.

p


109

[그림 3-56] 크기 시각화 차트 + Pollution 시각화 차트 예제

기본적으로 크기는 크기 시각화 차트와 동일하게 각각의 컴포넌트의 크기를 나타내게 된다.

여기서 주의 깊게 봐야 할 부분은 바로 각 컴포넌트의 색이다. XWiki Rendering - Macros - Parent

POM 컴포넌트는 짙은 녹색으로 구성되어 있는 것을 볼 수 있다. 이것은 분석 때 선택한 오염도의

오염 수준을 보여주는 것이다. 짙은 녹색은 바로 위험도가 낮은 안전한 상태를 의미하는 것이다. 이와

반대로 XWiki Rendering - XML 컴포넌트와 같이 붉은색으로 표시된 요소는 오염수준이 높은

것이므로 문제 해결을 할 필요성이 있는 요소들을 나타낸다.


110 SEC-2014-RM005

다. 의존성 시각화 차트와 크기 시각화 차트의 결합

a) 개요

의존성 시각화 차트 중에서 Composition View 의 경우를 생각해보면 해당 시각화에서 정보를

전달해주는 요소는 오로지 방향성을 나타내는 화살표(간선)들이다. 컴포넌트의 이름을 표시해주는

정점들은 내부 요소를 계층적으로 표시해주는 용도로 사용되는 경우를 제외하고는 아무런 정보도

주지 않는다. 물론 아래 그림처럼 계층적인 형태로 내무의 의존성 관계를 보여주도록 하는 경우도

많이 존재하지만 위에서 전체 분석에서 설명하였듯이 분석의 범위가 커지게 되면 화면에 그려지는

범위는 한정되어 있는데 시각화할 내용들이 많아지기 때문에 사용자 입장에서는 분석하는데

많은 시간이 걸리게 되고 또한 보기에도 불편해진다.

[그림 3-57] 의존성 시각화 차트의 정점을 계층형태로 표현하는 예

그래서 이러한 단점을 가지지 않고 사용자에게 더 많은 정보를 주기 위하여 다른 차트와의

혼합을 고려하게 되었고, 그 결과로 크기 시각화 차트에 존재하는 크기 요소를 Composition View의

정점에 부여하는 혼합 차트가 구성되게 되었다.

p


111

b) 분석 방법

기본적으로 이 혼합 차트 역시 Composition View 에서 파생된 차트이기 때문에 거의 동일한

방식으로 해석 가능하다. 단지 정점에 크기 요소가 부여되어 있기 때문에 이점만 유의하여

분석하면 된다. 아래 그림과 같이 복합 차트가 나왔다고 가정해보자.

[그림 3-58] 크기 시각화 차트와 Composition View 의 혼합 차트

위의 차트를 확인해보면 기존에 Composition View 에서 정점은 아무런 크기 정보를 가지고

있지 않았지만 위의 차트에서는 크기를 가지고 있다는 것을 확인할 수 있다. 여기서 각 정점들의

크기는 해당 컴포넌트들의 크기를 의미하게 되고 위의 차트에서는 session 컴포넌트가 가장 큰

크기를 가진다고 할 수 있다.


112 SEC-2014-RM005

제 6절 소프트웨어 아키텍처 역방향 분석 정리

지금까지 아키텍처 역방향 분석 방법과 관련된 모든 내용들을 살펴보았다. 역방향 분석을 하기

위해서 가장 기본적인 분석 도메인을 나누는 방법을 시작으로, 각각의 도메인들간의 의존성 관계를

파악하는 방법과, 그리고 이러한 정보들과 실제 소프트웨어 시스템의 소스 코드를 기반으로 아키텍처적인

지표를 파악할 수 있는 다양한 Metric 들에 대하여 소개하였다. 그리고 마지막으로 이러한 정보들을

보다 쉽게 이해할 수 있도록 도와주는 5 가지의 시각화 방법론에 대하여 이야기 하였다.

지금까지 소개한 요소들은 아키텍처 역방향 분석 방법에 있어서 가장 기본이 되는 내용으로

분석하고자 하는 소프트웨어 시스템의 소스코드를 기반으로만 분석하는 방법론이다. 그렇기 때문에

소스 코드 이외에 DB와 데이터 구조 등과 같은 소스코드 내에서는 파악되지 않는 요소들에 대해서도

파악해야할 필요성이 있다.

[그림 3-59] 아키텍처 역방향 분석도]

p


113

제 4 장 도구를 활용한 소프트웨어 아키텍처 분석

제 1절 STAN4J

1. 개요

자바 아키텍처 분석 툴인 STAN4J 는 각 도메인간의 관계를 한눈에 파악 할 수 있는 Composition

View 를 제공하고 각 패키지나 프로젝트 전체에서 어떤 부분이 문제가 되는지 메트릭 지표중

문제가 되는 지표를 뽑아 오염도를 보여주는 그래프와 함께 제공한다. 100 개 이하의 클래스에서

무료로 사용가능하다.

2. 설치 방법

STAN4J 는 2가지의 방법으로 설치하여 사용할 수 있다. 한 가지는 IDE 툴인 Eclipse에 PlugIn으로

설치하여 사용하는 방법이 있고 나머지 한 가지는 소프트웨어로 다운로드 받아 설치할 수 있다.

￭ Eclipse Plugin 설치 방법

1. Eclipse 메뉴에서 “Help > Install New Software…”를 선택한다.

2. Work with 입력란에 “http://update.stan4j.com/ide”를 입력한다

3. 아래의 그림과 같이 선택한 후 Next 를 눌러 설치를 진행한다.


114 SEC-2014-RM005

[그림 4-1] STAN4J Plugin 설치 화면

￭ 소프트웨어 설치 방법

1. http://stan4j.com/general/download-app.html 에 접속하여 자신의 운영체제에 맞는 파일

다운로드

2. 원하는 폴더에 압축 해제 후 실행

3. 사용 방법

Eclipse Plugin

1. 아키텍처 분석을 원하는 프로젝트를 Eclipse 에서 선택한다.

2. 선택한 프로젝트에서 우클릭 후 아래의 그림과 같이 “Run As > Structure Analysis” 메뉴를

선택한다.

p


115

[그림 4-2] STAN4J 메뉴 선택화면

￭ 소프트웨어 사용 방법

1. 메뉴에서 “File > New”를 선택한다.

2. 프로젝트 이름을 입력한 후 Next 를 누른다.

3. 도메인 레벨을 설정한다. 클래스 내부까지 알고 싶다면 Member 를 선택한다.


116 SEC-2014-RM005

[그림 4-3] 디테일 레벨 설정

4. JAR 파일을 분석하고 싶으면 Add JARs, Eclipse 프로젝트로 구성된 소스를 분석하고 싶으면

Add Folder 를 선택한다.

p


117

4. 주요 특징

￭ Composition

STAN4J 의 주요한 특징으로 도메인들의 관계를 표현 할 때 DSM 으로 보여주는 것이 아닌

Composition 차트로 보여주는 점이다. DSM 은 문제점을 파악하기는 쉽지만 관계가 어떻게

이어져 있는지 시각화하여 판별하기는 매우 어렵다. 그 대신에 Composition 은 도메인들의

관계에 따라 자동으로 계층화 되어서 보여주기 때문에 쉽게 아키텍처를 파악 할 수 있다.

[그림 4-4] Composition View

Composition 차트에서 우측 상단 메뉴 중 6 번째 메뉴인 Partition into Tangles 를 선택하게

되면 아래와 같이 화면이 변경 된다.


118 SEC-2014-RM005

[그림 4-5] Partition into Tangles

도메인간 서로 강하게 결합되어 연결된 도메인들을 한꺼번에 결합하여 보이는 형태이다. 이

기능을 활용하면 아키텍처에서 각 도메인이 계층화 되지 않고 하위 레이어에서 상위 레이어를

참조하거나 서로 간에 매우 강하게 결합되어 있어 변화에 쉽게 대응하지 못하는 부분을 한번에

엮어서 파악할 수 있다.

p


119

￭ Coupling

하나의 패키지를 선택하여, 선택된 패키지를 참조하고 있는 패키지는 왼편에 위치하며 선택한

패키지가 참조하고 있는 패키지들은 오른편에 위치하여 현재 패키지가 어떤 패키지에 참조

당하며 참조하고 있는지 쉽게 파악 할 수 있는 차트이다.

[그림 4-6] Coupling


120 SEC-2014-RM005

￭ Pollution

클래스 레벨 이상의 도메인에서 메트릭 수치상으로 STAN4J 자체의 기준에서 이상이 있다면

Pollution으로 표현하여 보여준다. 아래의 그림과 같이 메트릭 중 어느 문제가 심각한지 원그래프로

표현하여 문제가 되는 부분을 쉽게 파악 할 수 있다.

[그림 4-7] Pollution

p


121

다음과 같은 Pollution 의 종류가 있다. 각 도메인마다 메트릭을 뽑는 기준이 다르기 때문에

도메인 별로 나오며 메트릭이 문제가 되는지 판단하는 기준은 아래의 그림처럼 녹색 구간이면

문제가 없고 노란색 구간이면 경고 빨간색 구간이면 심각한 문제가 있다고 판별한다.

[그림 4-8] STAN4J 의 Pollution 기준


122 SEC-2014-RM005

￭ Distance

Distance 는 Robert C. Martin 이 쓴 논문에 각 패키지들이 추상화 정도가 적절한지 판별 할

수 있는 차트이다. 여기서 가운데 대각선으로 위치한 선에서 멀어질수록 추상화 레벨이 적절히

설정되지 못하다는 것을 알 수 있고 원의 크기는 ELOC(Estimated Line of Code)의 크기로 상대적으로

보여지게 된다. 이 차트를 통해 추상화 레벨에 문제가 있는 패키지를 한번에 파악 할 수 있다.

[그림 4-9] Distance

p


123

￭ 리포팅 기능

STAN4J 는 리포팅 기능을 제공 한다. 이 리포트에서는 종합적으로 프로젝트의 상태를 알려준다.

각 패키지의 사이즈를 보여주는 간단한 트리맵 부터 라이브러리의 상관관계를 알려주는

라이브러리 관계 그래프 그리고 프로젝트의 메트릭 수치를 종합적으로 보여주고 또한 오염도

그래프를 보여주어 한 번에 프로젝트의 모든 상태를 종합적으로 볼 수 있는 리포트를 제공한다.

이 리포트는 웹 형태로 제공되며 이 정보들로 프로젝트의 문제를 한눈에 확인해 볼 수 있다.

[그림 4-10] STAN4J 의 리포트


124 SEC-2014-RM005

5. 장단점

가. 장점

STAN4J 는 시각화가 잘되어 있어 아키텍처를 한눈에 파악하기가 매우 용이 하다. DSM을 채택

하지 않고 Composition을 채택하여 패키지간의 관계를 계층화된 상태로 보여주기 때문에 아키텍처를

쉽게 이해 할 수 있다. 또한 메트릭 수치에 관해 STAN4J 만의 자체적인 기준이 설정되어 있어

문제가 있다고 생각되는 부분을 자체적으로 계산하여 Pollution 에서 원 그래프로 보여준다. 이를

통해 소프트웨어 시스템 내에 어느 것이 문제가 가장 큰지 한번에 알 수 있으며 각 패키지나

클래스에서도 문제가 되는 부분을 바로 파악 할 수 있다. 또한 플러그인을 활용하면 소스와 바로

연결되어 볼 수 있는 장점이 있다.

- Composition 을 통한 시각화로 아키텍처를 쉽게 이해 할 수 있다.

- Pollution 을 통해 가장 큰 문제가 무엇인지 바로 파악 할 수 있다.

- 플러그인을 통해 시각화된 차트와 소스를 바로 연결하여 볼 수 있다.

나. 단점

STAN4J 는 Eclipse 에 종속되어 Eclipse 프로젝트가 아니면 아키텍처 분석을 진행 할 수가 없다.

이는 Eclipse 외에 다른 IDE 툴을 사용하는 사람들은 따로 Eclipse 로 빌드 가능하게 만들어

주거나 JAR 형태로 변형하여 분석을 하여야 하는 문제점이 있다. 또한 STAN4J 자체 내에서

Pollution 의 기준을 정해주긴 하였지만 사용하는 프로젝트 마다 문제가 되는 메트릭의 수준은

분명히 다를 것이다. 하지만 기준이 고정되어 있어 변경이 어렵기 때문에 프로젝트 마다 적절히

맞춰 대응하기는 힘들다. 그리고 Composition 을 제공하고 DSM 을 제공하지 않는다. 각각의

장단점이 확실히 갈리는 차트이므로 DSM 도 같이 제공했으면 Composition 으로 문제를 쉽게

파악하고 DSM 으로 문제의 원인을 빠르게 분석 할 수 있기 때문에 DSM 을 제공하지 않는

아쉬움이 있다. 마지막으로 100 개 이하의 클래스에선 무료이긴 하나 100 개가 넘어가면 기능에

제한이 있어 비용을 지불하여야 한다.

- Eclipse 에서만 사용가능하다

- 기준이 고정되어 있어 프로젝트 마다 대응하기 힘들다

- DSM 을 제공하지 않아 세부적으로 문제를 살펴보기 힘들다

- 100 개 이상의 클래스에서는 유료이다.

p


125

6. 활용방법

￭ Composition 차트

Composition 차트는 Efferent Afferent 값에 따라서 아래쪽으로 내려 갈수록 Util 클래스 및

시스템의 코어적인 부분일 가능성이 높고 위로 갈수록 Application Level 및 UI 그리고 Logic

클래스일 가능성이 높다. 처음에 프로젝트를 접하게 되면 이러한 부분을 문서를 제공하지

않는다면 파악하기가 힘들다. 여기서 Composition 차트를 통하여 이러한 비용을 줄일 수 있다.

[그림 4-11] 오픈소스 Logdog Servert 의 Composition 차트

오픈소스 안드로이드 버그리포팅인 Logdog 를 예를 들어 설명하겠다. 보는 바와 같이

아래쪽으로 갈수록 Core 부분이나 Utility 성향을 가진 부분들이 나오는 것을 알 수 있고 위로

갈수록 ViewPackage 나 Logic 등을 처리 하는 것을 알 수 있다. 이 오픈소스는 비교적 간단한

소스이긴 하나 코드부터 볼 때와 다르게 Composition 차트로 보면 프로젝트의 아키텍처를


126 SEC-2014-RM005

한눈에 파악 하는 것이 가능하다.

Composition 차트를 활용하면서 리팩토링을 진행하면 문제점을 파악하여 훨씬 쉽게 리팩토링을

진행할 수 있으며 강한 커플링을 찾아 해결 할 수 있다.

[그림 4-12] Logdog Client 리팩토링 진행 작업

위에 보이는 그림은 오픈소스인 Logdog Client 의 리팩토링을 진행 하기전의 모습이다. 보는

바와 같이 빨간색으로 역참조가 존재하는 것을 파악 할 수 있다. 이와 같은 문제점을 Composition

차트를 통하여 쉽게 파악 할 수 있다. 그리고 최종적으로 다음과 같이 수정되었다.

p


127

[그림 4-13] 리팩토링이 완료된 Logdog Client

위의 그림과 같이 최종적으로 리팩토링이 완료된 것을 볼 수 있다. 리팩토링 작업을 진행하면서

아키텍처적으로 문제가 있는 부분을 쉽게 파악 할 수 있고 변경되는 모습을 이클립스에서 바로

확인 할 수 있어서 매우 유용하게 사용 할 수 있다. 이 그림에서는 위에 보이는 빨간색화살표인

역참조가 존재하지 않아 강한 커플링을 해제한 것을 확인 할 수 있다.


128 SEC-2014-RM005

￭ Pollution 차트

Pollution 차트는 프로젝트 전체나 각 도메인 단위로 문제가 되는 부분을 원 그래프 형태로

보여주는 차트이다. 이는 한 번에 전체적인 프로젝트의 문제점을 파악 할 수 있어 리팩토링에

사용되면 매우 유용하게 사용할 수 있다. 아래는 안드로이드 버그리포팅 오픈소스인 ACRA 의

폴루션 차트 화면이다.

[그림 4-14] ACRA 의 폴루션 차트

그림에서 보는 바와 같이 다양한 문제점이 프로젝트 전체에서 나오는 것을 알 수 있다. 그중에

Tangled 문제가 가장 심각하게 대두되어 있는 것을 확인 할 수 있다. Pollution 차트를 통해

프로젝트에서 가장 큰 문제를 파악 하여 어느 부분을 먼저 처리해야 하는지 파악하고 리팩토링을

진행하면 빠르게 문제를 해결해 나갈 수 있다.

p


129

[그림 4-15] Pollution 에서 Number of Fields 를 선택한 화면

또한 STAN4J 의 전체적인 화면에서 보면 어느 부분이 문제인지 바로 파악 할 수 있다. 위의

그림은 Pollution 차트에서 Number of Fields 를 선택한 화면인데 아래에 바로 어느 클래스에서

문제가 생겼는지 파악 할 수 있다. 또한 이클립스에서 실행되기 때문에 바로 코드를 보고 고칠

수 있어 빠르게 문제를 파악하고 대응 가능하도록 편의성을 제공한다.


130 SEC-2014-RM005

제 2절 Metrics

1. 개요

Eclipse 플러그인으로 간단한 Metric 수치들과 패키지들의 관계를 볼 수 있는 그래프를 제공한다.

CPL1.0 라이센스로 상용프로젝트 및 소스 공개와 상관없이 사용 가능하다.

2. 설치 방법

기본적으로 Elcipse 3.7 Indigo 버전에는 설치가 되어 있다 하지만 설치가 되어 있지 않은

경우 이클립스 플러그인으로 설치 가능하다.

￭ Eclipse Plugin 설치 방법


2. Work with 입력란에 “http://metrics.sourceforge.net/update”를 입력한다


[그림 4-16] Metrics Plugin 설치 화면

p


131

3. 사용 방법

1. 이클립스에서 분석하고자 하는 프로젝트를 선택하고 우클릭하여 메뉴중 “properties > Metrics”를

선택한다.

2. 아래와 같은 화면에서 “Enable Metrics”를 체크하고 “Apply”를 누르고 확인을 누른다.

[그림 4-17] Metrics 설정 화면

3. 메뉴에서 “Window > Show View > Metrics View”를 선택한다.

4. 다시 프로젝트를 선택한 후 Metrics 화면에서 녹색 화살표를 누른다.


132 SEC-2014-RM005

[그림 4-18] Metrics 실행화면

4. 주요 특징

￭ 메트릭 측정

아래와 같은 메트릭 수치들을 제공한다.

- Number of Classes

- Number of Children

- Number of Interfaces

- Depth of Inheritance Tree (DIT)

- Number of Overridden Methods (NORM)

- Number of Methods (NOM)

- Number of Fields

- Lines of Code

- Specialization Index

- McCabe Cyclomatic Complexity

- Weighted Methods per Class (WMC)

- Lack of Cohesion of Methods (LCOM*)

p


133

- Afferent Coupling (Ca)

- Efferent Coupling (Ce)

- Instability (I)

- Abstractness (A)

- Normalized Distance from Main Sequence (Dn)

이와 같은 메트릭 수치중에 프로젝트에 문제가 있다고 판단되는 메트릭 수치는 빨간색으로

표시되어 나타난다.

[그림 4-19] 문제가 있는 부분은 빨간색으로 강조되어 나타냄

￭ 관계 그래프

Metrics 화면의 오른쪽 끝에 “Open the dependency graph view”를 선택하게 되면 선택한

프로젝트의 패키지간의 관계를 볼 수 있는 그래프를 제공한다. 각 관계가 어디에서 이루어 졌는지

자세히 알 수 없고 단순히 서로 참조하고 있는 정보만 알 수 있다. 그리고 패키지 서로간의

싸이클을 이루는 즉 강하게 엮인 패키지들끼리는 빨간색으로 표시되어 어디가 패키지들이 서로

강하게 엮여 있는지 문제를 쉽게 파악 할 수 있다.


134 SEC-2014-RM005

[그림 4-20] Metrics 의 관계 그래프

5. 장단점

가. 장점

Metrics 는 이클립스와 연동되어 매우 간편하게 사용할 수 있다. 일단 분석에 필요한 기본적인

메트릭 수치들을 바로바로 확인해 볼 수 있다. 또한 어떤 메트릭 수치들이 문제가 되는지 바로

빨간색으로 표시해 알려주어 유저가 빠르게 문제가 되는 메트릭 수치를 파악하고 대응 할 수

있다. 그리고 마지막으로 관계 그래프를 시각화 하여 보여주고 싸이클이 생기는 부분을 표시하여

어디 부분에 환형 참조가 생겼는지 빠르게 파악 할 수 있다.

- 이클립스와 연동되어 매우 편리하다

p


135

- 아키텍처 분석에 필요한 기본적인 메트릭들을 바로바로 확인해 볼 수 있다.

- 문제가 되는 메트릭을 바로 표시해주어 대응하기 쉽다.

- 관계 그래프를 보여주어 환형참조가 생긴 부분이 어디인지 쉽게 파악할 수 있다.

나. 단점

Metrics 는 정말 기본적인 메트릭 수치만 취급한다. 그에 따라 사용자가 더 필요한 메트릭 수치들을

제공하지 않아 아키텍처 분석하기엔 정보가 부족하다. 그리고 전혀 시각화 되어 있지 않고

단순히 표로만 보여주어 한눈에 정보를 파악하기가 쉽지 않다. 일일이 패키지나 클래스를 눌러서

확인해 봐야 한다. 마지막으로 관계 그래프를 제공하기는 하나 이 그래프는 시각화가 잘 되어

있지 않아 패키지의 양이 많아지면 관계를 제대로 파악하기 힘들고 싸이클이 존재하는지 알려주기는

하나 서로간의 관계가 어디서 이루어지는지 코드 상에서 바로 연동되지 않아 일일이 스스로

찾아봐야 하는 단점이 있다.

- 기본적인 메트릭 수치만 제공하여 아키텍처를 분석하기에 정보가 부족하다.

- 전혀 시각화 되어 있지 않고 표로 메트릭 수치들을 제공하여 한눈에 파악하기 힘들다.

- 관계 그래프를 제공하기는 하나 시각화가 제대로 이루어지지 않아 패키지의 양이 많아지면

그래프를 보기가 힘들다.

- 관계 그래프에서 싸이클을 찾아내어도 소스의 어느 부분에서 관계를 이루고 있는지 전혀

알려주지 않아 사용자가 일일이 확인해야 한다.

6. 활용방법

Metrics 는 이클립스에서 기본적으로 무료로 제공되기 때문에 부담 없이 사용 할 수 있는 장점이

있지만 단순한 메트릭 수치를 보는 이상의 기능을 제공하고 있지 않기 때문에 아키텍처를 볼 때

문제점을 한눈에 파악하기가 불가능하다. 그래서 이클립스에 연동하여 가볍게 현재 프로젝트의

메트릭 수치들을 보고 싶을 때 사용하는 게 좋다.


136 SEC-2014-RM005

제 3절 CodePro Analytix

1. 개요

구글에서 제공하는 코드 분석 툴이다. 이 툴은 종합적으로 메트릭 정보를 제공 할 뿐만 아니라

JUnit 과 연동한 테스트, 코딩 룰을 정해 지켜지고 있는지 확인 하는 기능, 코드의 커버리지가

얼마나 되는지 확인 할 수 있는 기능을 모두 갖추고 있다. 하지만 통합 개발 환경인 이클립스의

플러그인으로 제공 되어 이클립스로 진행하지 않는 프로젝트에서는 따로 이클립스에 프로젝트를

적용하여야만 사용 할 수 있는 툴이다. CodePro Analytix의 라이센스는 Creative Commons 라이센스로

상업적으로 이 툴을 사용하는 것은 불가능하나 이용하는 데는 문제없다.

2. 설치방법

기본적으로 이클립스의 플러그인으로만 제공되기 때문에 일단 이클립스를 설치하여야 한다.


2. 홈페이지 중 다운로드(“https://developers.google.com/java-dev-tools/download-codepro”)에

들어가서 현재 사용하고 있는 이클립스의 맞는 버전을 주소를 복사한다.

3. 만약 인디고 버전을 사용 중이라면 Work with 입력란에

“http://dl.google.com/eclipse/inst/codepro/latest/3.7”를 입력한다


p


137

5. 약관에 동의 한 뒤 설치를 완료 한다.

6. 이클립스의 패키지 익스플로러에서 우클릭하여 코드프로가 설치된것을 확인 할 수 있다


138 SEC-2014-RM005

[그림 4-21] 코드 프로 설치 확인

3. 사용방법

1. 분석하고자 하는 프로젝트를 선택한다.

2. 프로젝트를 선택하고 우클릭 하여 메뉴중 “CodePro Tools”를 선택한다.

3. 나오는 메뉴중 원하는 메뉴를 선택하여 사용한다.

[그림 4-22] 코드 프로 메뉴

p


139

4. 주요특징

￭ Audit Code

CodePro Analytix 는 코드를 감사하는 기능을 제공 한다. 이 기능은 코드에서 문제가 되는

점을 바로바로 확인 할 수 있는 기능이다.

프로젝트를 우 클릭하여 코드 프로 메뉴 중 Audit Code 를 선택하면 아래의 그림과 같이 문제가

되는 부분을 바로 확인 할 수 있다.

[그림 4-23] Audit Code 실행 화면


140 SEC-2014-RM005

코드 프로에서는 코드 감사에 대해 다음과 같이 위험도를 구분 하고 있다.

빨간색이면 높은 위험도를 가진다고 나타내고 노란색이나 파란색이면 상대적으로 낮은 위험도를

가진다고 정의하고 있다. 이에 따라서 위험도가 높은 부분부터 우선순위를 정하여 해결 할 수

있게 된다.

감사 규칙은 코드프로에서 기본적으로 몇 가지 정의 하고 있다.

[그림 4-24] 코드 감사 규칙

다음과 같은 감사 규칙을 코드프로에서 기본적으로 제공하고 있다 여기서 사용자가 원하는

규칙을 선택하여 Audit Code 창에서 확인 할 수 있다.

또한 사용자가 자신이 직접 코드 규칙을 추가 할 수 있다. 모든 코드 감사 규칙은 아래의 경로에

XML 형식으로 저장 되어 있다.

p


141

<extension point="com.instantiations.assist.eclipse.audit_rule">

<auditRule

id="com.xyz.audit.myAuditRule"

<CODEPRO>\eclipse\plugins\com.instantiations.assist.eclipse.analysis_X.X.

X\plugin.xml

[그림 4-25] 코드 감사 규칙 정의

여기서 자신이 원하는 감사 규칙을 추가하기 위해선 아래와 같은 절차로 자신이 원하는 룰을

추가 할 수 있다.

- PDE 플러그인 마법사를 사용하여 새 플러그인 프로젝트를 만든다. (파일 | 새로 만들기 |

프로젝트 | 개발 플러그인 | 플러그인 프로젝트).

- 프로젝트의 클래스 경로에 파일이 이클립스의 핵심 런타임 (runtime.jar), JDT 코어

(jdtcore.jar) 및 분석 코어 (CodeProAnalysis.jar)에 대한 클래스 경로 항목이 포함되어

있는지 확인한다.

- plugin.xml 파일에서 "org.eclipse.core.runtime", "org.eclipse.jdt.core"와 "com.instantiations.

assist.eclipse.analysis" 플러그인을 가져온다.

- 구현하는 새 감사 규칙 클래스 만들어야 한다. com.instantiations.assist.eclipse.analysis.

audit.core.AuditRule 는 인터페이스이다. 확장com.instantiations.assist.eclipse.analysis.audit.

core.CompilationUnitAuditRule 의 클래스는 가장 편하게 만들어 줄 수 있는 클래스 이다.

- plugin.xml 파일 내에서 런타임 라이브러리로 참조해야 한다. jar 파일로 감사 규칙을

컴파일한다.

- plugin.xml 파일에서 새 감사 규칙을 정의하는 com.instantiations.assist.eclipse.audit_rule 을

넣는다.

- 플러그인을 구축하고 \ 이클립스 \ 플러그인 디렉토리에 설치한다.

- 종료하고 IDE 를 다시 시작한다.

- 이클립스 Preferences 메뉴에서 CodePro->Audit->Rules 을 들어가 보면 새로운 룰이

추가된 것을 확인 할 수 있다.


142 SEC-2014-RM005

name="%myAuditRuleName"

description="%myAuditRuleDescription"

class="com.xyz.audit.MyAuditRule"

group="com.xyz.audit.myAuditRuleGroup"

editor="com.xyz.audit.MyAuditRuleEditor"/>

<violation

id="com.xyz.audit.myAuditRule.myViolation"

description="%myAuditRule.myViolationDescription"

explanation="%myAuditRule.myViolationExplanation"/>

</auditRule>

</extension>

[그림 4-26] XML 파일에 새로운 감사 룰을 추가하는 예제

마지막으로 코드 감사 결과를 리포팅 형식으로 제공하여 확인 할 수 있다.

[그림 4-27]코드 감사 결과 리포팅 방법

p


143

위의 그림과 같이 나온 결과를 우클릭하면 HTML 방식이나 XML 방식으로 리포트를 생성 할

수가 있다.

리포트를 생성해낸 결과는 아래와 같다.

[그림 4-28] 코드 감사 결과 리포팅 결과

￭ Compute Metrics


144 SEC-2014-RM005

CodePro Analytix 에서 그 프로젝트의 메트릭 수치들을 바로 계산하여 볼 수 있다. 코드프로의

메트릭의 카테고리는 아래와 같이 정의 되어 있다.

- Basics

- Complexity

- Dependency

- Halstead

- Inheritance

- Ratio

코드 프로에서 실제로 Compute Metrics 의 메뉴를 선택해 실행해보면 아래의 그림과 같은 결과로

메트릭 수치들을 확인 할 수 있다.

[그림 4-29] 코드 프로 메트릭 계산 결과

메트릭 수치는 상위 개념으로 한번 그룹화되어 나타난다. 여기서 메트릭 수치상 문제가 있다고

생각되는 부분을 빨간색으로 표시하여 사용자에게 알린다.

p


145

[그림 4-30] 메트릭 수치가 문제가 되는 부분을 빨간색으로 표시

코드 프로에서는 문제가 되는 메트릭 수치를 사용자가 원하는 값으로 조절 할 수 있다. 위의

Average Block Depth 의 문제가 되는 수치의 기본값은 3.0 이다. 이를 사용자가 우클릭하여

“Configure Metric” 메뉴를 선택하게 되면 아래와 같은 창이 실행된다.

[그림 4-31] 하나의 메트릭 설정 화면


146 SEC-2014-RM005

여기서 Maximum average value 에 값을 사용자가 원하는 만큼 설정하게 되면 그 값이 메트릭

수치의 기본이 되는 것이다. 이처럼 사용자가 자신의 프로젝트의 기준에 맞게 가변적으로 기준이

되는 메트릭 수치를 정할 수 있어 각 프로젝트의 내용마다 알맞게 사용 가능 하다.

그리고 메트릭 수치에 관해 어느 정도 시각화가 가능한 메트릭은 차트로 시각화 하여 보여준다.

[그림 4-32] 메트릭 시각화

마지막으로 메트릭 수치들 모두 리포팅 형식으로 제작 할 수 있다. HTML 방식이나 XML 형식으로

가능하다.

p


147

￭ JUNIT 연동

코드 프로에서는 손쉽게 JUnit 과 연동하여 테스트 케이스를 생성 할 수 있다. 단지 현재 프로젝트에서

우클릭 하여 Generate Test Cases 를 선택하는 것만으로 자동으로 테스트 케이스를 생성해 준다.

Generate Test Cases 메뉴를 선택하게 되면 기존의 프로젝트에서 마지막에 Test 란 단어가

추가된 프로젝트가 저절로 생성 되게 된다.

[그림 4-33] 자동으로 생성된 JUnit Test 프로젝트


148 SEC-2014-RM005

￭ Find Similar Code & Find Dead Code

코드 프로는 코드 중복 그리고 쓸모없는 죽은 코드를 찾아내 준다. 위와 같은 메뉴를 선택하면

바로 자신의 프로젝트에서 비슷한 코드가 중복되는지 확인 할 수 있다.

코드 중복은 아래의 그림과 같이 확인 할 수 있다.

[그림 4-34] 비슷한 코드 찾기

p


149

아래의 리스트에는 비슷한 코드가 존재하는 리스트가 나오고 그 리스트를 클릭하게 되면 위에

실제 코드를 비교해서 사용자에게 보여준다. 이와 같은 기능을 활용하면 자신의 코드 중 중복된

코드가 있는지 쉽게 확인 할 수 있다.

그리고 Find Dead Code 를 실행하게 되면 아래의 그림과 같이 사용자가 확인 할 수 있다.

아래의 리스트에 죽은 코드들이 나오고 그 부분을 클릭하게 되면 위에서 실제로 코드를 확인할

수 있다. 이를 통해 사용자가 쉽게 사용되지 않은 코드를 확인하여 수정하기에 용이 하다.

[그림 4-35] Find Dead Code 실행 화면


150 SEC-2014-RM005

￭ Analyze Dependencies

마지막으로 각 도메인간의 의존관계를 분석하여 시각화 해주는 Analyze Dependencies 메뉴가

존재한다. 이 메뉴를 선택하게 되면 새로운 화면이 나오고 화면에서 시각화하여 도메인간의

의존관계를 보여준다.

[그림 4-36] 의존관계를 보여주는 차트

p


151

위와 같은 차트에서 빨간색으로 표시된 부분은 서로가 강하게 연결되어 있는 싸이클을 나타낸다.

이처럼 쉽게 싸이클을 분석할 수 있어 사용자가 빠르게 문제를 파악 하는 것이 가능하다.

하지만 이 차트는 모든 관계를 분석하기엔 문제가 많다. 패키지 내부를 보려면 패키지를 더블

클릭하면 볼 수 있지만 다른 패키지와의 연관관계를 파악하기는 힘들다 그래서 전체적으로 의존관계가

어떻게 구성되어있는지 차트로 확인하면 아래의 그림과 같이 매우 난잡하게 표시된다.

[그림 4-37] 모든 의존관계를 표시]

그래서 부분적으로는 의존관계를 파악하기 쉽지만 전체적으로 구성을 보기에는 무리가 따르는

것을 알 수 있다.


152 SEC-2014-RM005

5. 장단점

가. 장점

구글 프로로 어날리틱스는 이클립스 IDE 와 플러그인 형태로 연동되어 매우 편리하게 사용 할

수 있다. 만약 현재 사용하고 있는 IDE 가 이클립스라면 바로 프로젝트를 분석해 볼 수 있는

장점을 가지고 있다. 또한 코드의 컨벤션 및 룰을 정할 수 있어 팀프로젝트 단위에서 팀에서

사용하는 룰 및 컨벤션을 어기는 코드를 쉽게 잡아 낼 수 있어 팀 작업에서의 문제점을 쉽게 줄여

줄 수 있다. 그리고 메트릭을 계산해주는데 메트릭 수치가 기본으로 제공하는 기준에서 초과

되면 빨간색으로 잘못된 부분을 알려준다. 그리고 기준 값 또한 사용자가 임의로 설정 할 수

있어 자신의 프로젝트 성격에 맞게 기준을 커스터마이징 할 수 있다. 그리고 JUNIT 과 연동되어

자동으로 코드를 분석하여 기본적인 테스트들을 생성해 준다. 여기서 생성된 코드에 사용자가

몇몇줄만 추가하면 자동적으로 유닛테스트가 완성되어 테스트 케이스를 만드는 시간을 줄일 수

있다. 그리고 각 도메인 간의 관계를 추출해주어 쉽게 아키텍처를 파악 할 수 있는데 여기서

싸이클을 파악하여 빨간색으로 표시하여 문제가 되는 부분을 쉽게 파악 할 수 있다. 마지막으로

모든 결과들을 HTML 및 XML 파일 형태로 자동으로 리포팅 형태로 제공하여 정리된 데이터를

받아 볼 수 있다.

- 이클립스 IDE 와 연동되어 쉽게 사용 할 수 있다.

- Audit Code 기능을 제공하여 기본 룰 및 자신이 제작한 룰에 맞지 않는 코드를 쉽게

파악 할 수 있어 빠르게 수정 가능하다.

- 메트릭 수치를 제공하고 문제가 되는 메트릭을 빨간색으로 표시하여 바로 파악 할 수

있다.

- 메트릭 수치에서 문제가 되는 기준점을 사용자가 정할 수 있어 자신의 프로젝트에 맞게

커스터마이징 가능하다.

- JUNIT 과 연동되어 기본적인 테스트들을 자동으로 생성해 주어 테스트케이스를 만드는

시간을 줄일 수 있다.

- 도메인간의 의존관계를 보여주는 그래프를 제공하여 쉽게 의존관계를 파악할 수 있다.

- 의존관계 그래프에서 싸이클을 빨간색으로 하일라이트 표시해주어 강한 커플링을

유지하여 문제가 될 수 있는 부분을 바로 알 수 있다.

p


153

- 모든 결과를 XML, HTML 파일 포맷형식으로 리포트 형식으로 저장 할 수 있다.

나. 단점

이클립스에만 연동되어 다른 IDE 를 사용하는 사용자는 Code Pro Analytix 를 사용 할 수 없다.

그리고 코드 수준에서 많은 것을 보여주지만 아키텍처를 분석하기에는 의존관계를 표현하는

차트만 제공하여 부족한 면이 있다. 또한 제공하는 의존관계 그래프도 프로젝트의 크기 및

구조가 복잡해질수록 파악하기 어려운 형태의 그래프를 제공한다.

- 이클립스에서 플러그인으로 밖에 제공되지 않아 다른 IDE 에서는 사용할 수 없다.

- 메트릭 수치들을 수치상으로만 제공하고 시각화 된 차트나 그래프들이 부족하여

아키텍처를 한눈에 쉽게 파악하기에 무리가 있다.

- 의존관계 그래프도 시스템 크기가 커질 수록 또는 복잡해 질수록 전혀 알아볼 수 없는

상태가 된다.

6. 활용방법

CodePro Anlytix 는 코드 자체에 집중한 툴이다. Audit Code 기능을 통하여 코드에서 문제가

되는 부분을 빠르게 뽑아서 보여주고 또한 룰을 정하여 위반하면 바로 알 수 있도록 하여 코드

상에서 나오는 문제에 빠르게 대처 할 수 있다.


154 SEC-2014-RM005

제 4절 CppDepend

1. 개요

Cpp 언어 기반으로 분석 가능한 툴이다. Visual Studio 를 기반으로 작성된 프로젝트를 주로

분석하며 82 여 가지의 메트릭 정보를 제공하고 아키텍처 분석을 위해 DSM 과 Dependency

Graph 를 동시에 제공하여 아키텍처 분석을 용이하게 한다. 또한 리포팅 기능까지 제공하여

쉽게 프로젝트의 상태를 체크해 볼 수 있고 마지막으로 Visual Studio 의 플러그인 까지 제공하여

바로 통합하여 사용 할 수 있는 툴이다. 이처럼 기능이 다양하고 많은 만큼 유료로 사용해야

하는 툴이다.

2. 주요특징

￭ 설치 방법

1. 홈페이지 “http://www.cppdepend.com/cppdependdownload.aspx”에서 자신에 OS 에 맞는

버전을 다운로드 한다.

2. 설치파일을 차례에 따라 설치한다.

￭ 사용 방법

1. 새로운 프로젝트를 생성한다.

p


155

2. 아래의 그림에서 “Add Projects from VS Solutions(s)”를 선택한다.

3. 새로운 화면에서 자신이 분석하기 원하는 프로젝트를 선택한다.


156 SEC-2014-RM005

4. 원하는 옵션을 선택하고 저장(Ctrl + S)후 그림에 보이는 녹색 화살표 버튼이나 F5 키를

누른다.

[그림 4-38] CppDepend 로 프로젝트를 분석한 화면

p


157

￭ 트렌드 모니터링

트렌드 차트는 분석시 시간이 지남에 기록 된 지표 값이 만들어진다. 50 개 이상의 트렌드

메트릭을 기본적으로 사용할 수 있다.

다음과 같은 메트릭이나 내용들이 차트로 나타낼 수 있다.

- Lines of code

- Number of Code Rules Violated and number of Code Rules Violations

- Max and Average values for various Code Quality Metrics

- Third-Party Usage

[그림 4-39] 트렌드 모니터링 화면


158 SEC-2014-RM005

￭ DSM 제공

DSM 은 기존의 아키텍처를 분석할 때 문제가 되는 부분 강하게 엮인 Tangle 이나 하위 레이어가

상위 레이어를 참조하는 그런 문제를 쉽게 파악 할 수 있는 강력한 아키텍처 시각화 분석 차트이다.

이는 CppDepend 에서 제공하며 서로간의 관계에서 Cycle 을 이루는 부분을 버튼하나만 누르면 찾아

주어 쉽게 아키텍처의 문제점을 분석 할 수 있다.

[그림 4-40] DSM 의 모습

p


159

￭ Dependency Graph

CppDepend 는 DSM과 같이 도메인 서로간의 관계를 한번에 눈으로 알 수 있는 Dependency

Graph 를 제공한다. 이 그래프는 위에서 설명한 Composition 과는 다르게 Layer 를 형성하지

않고 단순히 서로간의 관계를 화살표로 보여주고 또한 상호 참조 관계만 나타내어 Cycle 관계를

한눈에 파악하기엔 약간 무리가 있으며 Layer 되어 있지 않기 때문에 어느 부분이 하위 레이어인지

파악하기 힘든 단점이 있다.

[그림 4-41] Dependency Graph


160 SEC-2014-RM005

￭ Treemap

Size of Component 의 일종으로 사용자가 원하는 정보를 다음과 같이 크기로 시각화하여 보여주는

차트이다. 각 도메인 레벨에 따라서 보여줄 수 있는 정보가 제각각 다르며 LOC, Cyclomatic

Complexity, Nested Depth 등 여러 가지 정보를 시각화하여 한눈에 보여 줄 수 있다.

[그림 4-42] Treemap 을 이용한 LOC 를 표현

p


161

￭ Abstracness Chart

Abstracness Chart 는 Robert C. Martin 이 쓴 논문에 각 패키지들이 추상화 정도가 적절한지

판별 할 수 있는 차트이다. 여기서 가운데 대각선으로 위치한 선에서 멀어질수록 추상화 레벨이

적절히 설정되지 못하다는 것을 알 수 있다. 이 차트를 통해 추상화 레벨에 문제가 있는 패키지를

한번에 파악 할 수 있다.


162 SEC-2014-RM005

￭ CQLinq Syntax

CppDepend 는 코드 내의 원하는 부분을 검색할 수 있는 Cqlinq Syntax 를 제공한다. 이

문법을 통해 자신의 프로젝트의 원하는 정보를 검색 할 수 있다. 여기서 검색 할 수 있는 도메인들은

Types, Methods, Fields, Namespaces, Projects 에서 아래의 예와 같이 검색 할 수 있다.

위의 내용은 메서드 도메인 수준에서 Line of Code 값 즉 코드의 라인수가 30 줄 이 넘어가는

메서드 도메인을 찾는 내용이다.

위와 같이 단순한 내용을 찾는 것도 가능하지만 그보다 복잡하게 Query 를 구성하여 자신한테

필요한 정보를 검색해서 알아낼 수 있다.

위와 같은 내용은 이름이 “ProductName,FeatureA”인 네임스페이스 내부에 있는 모든 자식

메서드 레벨중에 복잡도를 나타내는 메트릭인 Cyclomatic Complexity 의 값이 10 이 넘어가는

모든 메서드를 찾는 쿼리이다. 이와 같이 정확히 필요한 정보를 검색하여 알아 낼 수 있는

CQlinq Syntax 를 제공한다.

3. 장단점

가. 장점

CppDepend 는 기존의 Visual Studio 프로젝트에서 바로 아키텍처를 분석할 수 있는 장점이

있다. 소스 기반으로 분석하기 때문에 꼭 빌드된 버전이 아니더라도 소스만 가지고 분석 할 수

있다. 또한 VIsual Studio 에 Addin 으로 연동되기 때문에 만약 Visual Studio 를 사용하고

있다면 매우 편리하게 CppDepend 를 활용 할 수 있다. Addin 을 붙이게 되면 기존의 아키텍처

분석 만이 아니라 codediff 기능등 편의적인 기능도 제공하기 때문에 사용성이 매우 좋다. 그리고

DSM과 함께 Dependency 그래프를 보여 주기 때문에 아키텍처를 여러 가지 측면에서 분석하기가

유리하다. TreeMap 을 통해 쉽게 수치에 대한 상대적인 내용을 도메인별로 판별 할 수가 있어서

p


163

쉽게 문제가 되는 부분을 찾아내고 파악 할 수 있다. 마지막으로 Abstractness Chart 를 제공하여

패키지 레벨 이상의 도메인들에서 추상화 레벨이 적절히 적용되었는지 파악 할 수 있다. 많이

참조 당하지만 아직 적절한 추상화를 이루지 못한 패키지를 인터페이스 레벨로 바꿔 줘야 한다는

것을 알 수 있다. 그래야 변화에 전파에 적절하게 대응 할 수 있게되어 유연한 아키텍처를 가져 갈 수

있다. 그리고 마지막으로 자신이 원하는 정보를 찾을 수 있는 Query 기능을 제공 하고 있다.

- VIsual Studio 랑 연동되어 매우 쉽게 아키텍처 분석을 할 수 있다.

- 소스기반으로 분석하기 때문에 소스가 들어가 있는 폴더를 지정해도 분석이 된다.

- DSM 과 함께 Dependency graph 를 제공하기 때문에 다각도로 아키텍처를 파악하기 쉽다.

- Treemap 을 통하여 수치를 쉽게 시각화 하여 볼 수 있다.

- Abstractness Chart 를 통해 추상화 정도에 대해 시각화해서 볼 수 있다.

- Query 기능을 통해 원하는 정보를 쉽게 찾을 수 있다.

- 원하는 RuleSet 을 지정 할 수 있다.

나. 단점

유로 툴로서 라이센스의 개수마다 가격을 지불하고 사용하여야 한다. 그리고 Dependency

Graph 를 제공하지만 내부를 볼 수 있는 확장 축소가 되어 있지 않고 Layer 구조로 구성 되어있지

않아 많이 참조당하는 패키지, 클래스 도메인 들이 Layer 를 이루지 않고 그냥 화면에 흩어져

있어 공통되는 부분이나 프레임워크 부분을 파악하기 힘들다. Query 를 위한 Syntax 를 제공하나

그에 대한 러닝코스트가 존재한다.

- 유로 툴로서 필요한 개수마다 라이센스 가격을 지불하여야 한다.

- Dependency Graph 를 제공하나 확장 축소가 되지 않고 Layer 구조로 구성되어 있지

않아 정확한 정보를 파악하기 위해서는 DSM 을 한번 더 활용해야 한다.

- Query 기능을 제공하나 Syntax 를 익히기 위해서 러닝 코스트가 존재한다.

4. 활용방법

주로 패키지간의 dependency 를 체크하여 coupled 를 뺄 경우 사용한다.


164 SEC-2014-RM005

제 5 장 소프트웨어 아키텍처 분석 결과의 활용

제 1절 아키텍처 분석 결과 활용을 위한 대상 선정

지금까지 매우 다양한 아키텍처 분석 방법들을 살펴보았다. 그렇다면 지금부터는 이러한 분석

정보들을 토대로 실제 오픈 소스 소프트웨어를 점진적으로 개선해 나가는 과정들을 자세히

소개하겠다.

그 전에 우선 안드로이드의 로그 시스템에 대해서 이야기 해보면, 안드로이드 프로젝트를 개발

중일 때에는 대다수 안드로이드 툴에서 기본적으로 제공하는 로그 켓을 이용한다. 하지만 로그

캣은 실제 앱을 배포하였을 때에 발생한 다양한 문제 상황을 담고 있는 로그들을 가지고 올 수

있는 방법이 존재하지 않는다. 물론 기본적으로 구글 플레이에서 어느 정도의 정보를 제공하지만

여기에서 제공하는 정보만으로는 실제 앱의 버그들을 수정할 때 어려움이 존재한다.

그래서 이러한 문제를 해결하기 위해 다양한 오픈소스와 상용 소프트웨어들이 출시되었는데,

그 중에서 오픈소스로 만들어져서 소규모 개발팀이나 개인 개발자가 주로 사용하는 ACRA 라는

오픈소스가 있다. 이번 장에서는 바로 이 ACRA 를 중점적으로 개선해나가는 과정을 중점적으로

소개하겠다.

p


165

[그림 5-1] 안드로이드 버그리포팅 오픈소스 ACRA

제 2절 공개 소프트웨어 아키텍처 분석 결과의 활용

위에서 언급한 데로 소규모 개발팀이나 개인 개발자가 주로 사용하는 ACRA 라는 오픈소스를

중점적으로 개선해나가는 과정에 대해서 기술하고자 한다.

우선 가장 먼저 전체적인 소프트웨어 시스템의 의존성의 모습을 중심적으로 파악해보기 위해

의존성 파악에 있어 가장 알맞은 Composition View 를 기반으로 ACRA 를 분석해보면 아래와

같은 모습을 볼 수 있다. 한눈에 봐도 시스템에 수많은 Circular dependency 가 존재한다는 것을

알 수 있다. 그렇기 때문에 이 상태가 지속적으로 유지된다면 앞서 설명했던 것처럼 점진적으로

큰 문제를 일으킬 수 있다.


166 SEC-2014-RM005

[그림 5-2] ACRA 의 Composition View

또한 위의 Composition View 에서처럼 Util 이나 Log 와 같은 컴포넌트가 상당히 높은 수준까지

올라와 있기 때문에 적절한 Layer 화가 되어있지 않기 때문에 약간의 변화에도 각각의 컴포넌트들이

영향을 받는 변화에 취약한 구조로 되어 있다.

그렇기 때문에 ACRA 프로젝트는 장기적인 안목에서 바라본다면 프로젝트 내부에 존재하는

모든 Circular Dependency 를 제거하고, 시스템의 구조도 점진적으로 Layer 형태의 구조로 변경하여

다양한 변화에 강인하게 구성할 필요성이 있다고 할 수 있다.

일단 ACRA 프로젝트에 존재하는 대표적인 의존성 문제들을 찾아보았다. 그러면 이어서 ACRA

프로젝트에 존재하는 다양한 컴포넌트들은 적절한 컴포넌트의 크기를 유지하고 있을까?

이 문제에 대해서는 위의 Composition View 의 의존성들의 수만을 봐도 어느정도 파악할 수

있다. 대부분의 컴포넌트들이 한자리 수의 의존성을 가지고 있는데 가장 상위 패키지인 acra

패키지만이 2 자리 수의 의존성을 가지고 있기 때문에 상당히 큰 규모의 패키지라는 것을 알 수

있다. 그러나 좀 더 정확하게 파악하기 위해서는 크기 시각화 차트를 이용하여 정확한 규모를

파악해야 한다.

p


167

[그림 5-3] ACRA 의 크기 시각화 차트

위의 크기 시각화 차트를 보게 되면 예상대로 acra 컴포넌트가 가장 큰 규모로 전체 시스템의

절반이나 되는 크기를 차지하고 있는 것을 알고 있다. 이는 ACRA 의 크기가 적절하게 분배되지

않았다는 것을 보여주는 대표적인 요소이다. 그렇기 때문에 시스템의 컴포넌트들에 적절한

재분배가 필요하다는 것을 알 수 있다.

여기서 좀 더 살펴보자면 아래의 크기 시각화 파트는 가장 규모가 큰 acra 패키지의 내부의

모습이다. 내부를 보면 내부 안에서도 ACRAConfiguration 이 절반 이상의 크기를 차지하고

있다는 것을 알 수 있다. 그렇기 때문에 다른 요소들보다 이 ACRAConfiguration 을 중점적으로

크기를 줄여서 분배한단면 이러한 크기 문제를 해결할 수 있을 것이다.

[그림 5-4] acra 패키지 내부의 크기 시각화 차트


168 SEC-2014-RM005

의존성 시각화 차트에서부터, 크기 시각화 차트를 분석하면서 ACRA 프로젝트가 가지고 있는 다양한

문제점들을 파악하였다. 이어서 ACRA 의 추상화 시각화 차트를 파악해 보자.

[그림 5-5] ACRA 의 추상화 시각화 차트

위의 차트를 보면 가운데 중심선에서 매우 멀어져있는 요소는 크게 눈에 보이지 않는다. 단 (0,

0.2)에 존재하는 org.acra.collector 패키지가 문제가 되는 요소라고 할 수 있다. 하지만 무턱대고

해당 요소가 문제가 된다고 판단해서는 안 된다. 단순히 해당 컴포넌트에 DTO나 Domain 객체와 추상화

할 필요성이 적은 단순히 데이터를 저장하는 클래스일 수 도 있다. 그렇기 때문에 해당 요소가 구체적으로

어떠한 작업을 하는지 해당 요소에 대해서 판단해야 할 필요성이 있다.

위에서 문제가 있다고 나타난 요소는 org.acra.collector 패키지로 앱에서 발생한 버그 리포트를

수집하여 Key Value 형태로 저장해두는 클래스들을 모아두는 패키지이다. 이 안에는 다양한 상황에

알맞게 분기 처리된 클래스들이 존재한다.

언듯보기에는 이 패키지안에 Key Value 형태로 데이터들이 저장되기 때문에 DTO나 Domain 으로

착각할 수 도 있지만 안의 내부를 보면 실제적으로 데이터를 수집하는 로직이 해당 패키지 안에

p


169

존재하는 모든 클래스안에 들어가 있다. 그렇기 때문에 이 패키지 내부에 있는 요소들은 DTO 나

Domain 객체가 아니기 때문에 추상화를 해야 할 필요성이 있다. 그러므로 이 패키지의 요소들은

추상화를 해야할 필요성이 있다.

이제 마지막으로 ACRA 의 전제적인 오염도를 분석해보자.

[그림 5-6] ACRA 의 오염도 그래프

전반적으로 앞선 시각화 차트들 분석으로 들어났었던 대표적인 문제들인 Tangled(Circular

dependency)와 사이즈의 문제를 나타내는 Fat, ELOC 등의 문제들을 즉각적으로 발견할 수 있다.

그 외에도 프로젝트 안에 존재하는 DIT(상속의 평균 정도)의 문제나 다른 다양한 문제들을 표시해주는

것을 알 수 있다. 즉 이 ACRA 프로젝트에는 앞서 설명하였던 문제들 말고 다양한 오염 요소들이

존재한다는 것을 알 수 있다.

그렇기 때문에 이들을 모두 개선하기 위해서는 상당히 많은 수정과 개선이 있어야 한다. 그렇다면

이러한 요소들은 어떻게 개선해나갈 수 있을까?

이에 대한 해답은 이를 개선하기 위해 만들어진 관련 오픈소스인 LogDog 의 변화 과정을

통해 그 해답을 알 수 있다.


170 SEC-2014-RM005

제 3절 공개 소프트웨어 아키텍처 분석 후 개선 활동

Logdog 은 ACRA 에서 소개된 단점들을 개선하기 위해 만들어진 오픈소스로 ACRA 의 기능을

강화하고 아키텍처적인 설계도 보강하기 위해 만들어진 오픈소스이다.

우선 의존성에 대한 문제를 해결하는 과정을 살펴보자. 가장 먼저 acra 가 가지고 패키지를

보다 세분화하고, 이를 첫 번째로 레벨링한 모습이다.

[그림 5-7] logdog 첫번째 개선안

하지만 아직까지도 Circular dependency 가 전부 사라지지 않았으며 전체적인 레벨링도 완벽하게

구성되지 않은 모습이다. 더군다나 패키지를 나눈 것까지는 좋았지만 아직까지 전체적인 구성이

잡히지 않아서 의존성이 여기저기로 난잡하게 펴져있는 것을 확인할 수 있다. 그렇기 때문에

p


171

아직까지는 acra 의 단점을 개선했다고 말하기는 힘들다고 할 수 있는 상황이다.

[그림 5-8] logdog 의 두번째 개선안

첫 번째 개선안에서는 acra 에서 너무 적었던 패키지들을 각각의 성향에 맞게 새로 구성하였었다.

하지만 새로 구성한 패키지들의 경우에는 오히려 너무 많은 요소들로 나누어져있다. 가장 큰

예로 일반적인 요소들을 모아둔 logdog.common 패키지와 시스템에 통신으로 로그를 전송하는

logdog.network 를 예로 들수 있다. logdog.network 의 네트워크 관련된 요소들도 생각해보면

이 프로젝트 내부에서 common 하게 사용되는 요소이고, 한번 제대로 구현하고 나면 해당

요소들은 변경할 일이 거의 없는 요소들이다. 그렇기 때문에 logdog.network 의 내용들은 logdog.

common 에 합치는 것이 좋다고 볼 수 있다.

또한 이렇게 패키지들을 재구성함으로 써 첫 번째 개선안에서 나타났던 난잡했던 의존성

관계가 어느 정도 줄어든 것을 확인할 수 있다. 그리고 각각의 Layering 역시 기존보다 많이 개선

되었다는 것을 확인해볼 수 있다.


172 SEC-2014-RM005

[그림 5-9] Logdog 과 acra 의 의존성 그래프

그리고 이렇게 개선된 두번째 결과물을 다시한번 개선하여 위와 같은 최종 구조를 만들게

되었다. 보는 것처럼 acra 에서 난잡하게 존재하던 Circular Dependency 를 전부 없애고, 더나아가

이 구조를 적절한 수준의 Layering 으로 구성하여 acra 가 가지고 있던 잠재적인 의존성

문제들을 모두 해결한 것을 알 수 있다.

그렇다면 이렇게 개선된 logdog 의 다른 요소들은 과연 어떠할까?

다른 문제점들을 확인하기 위해서 크기 시각화 차트나 추상화 시각화 차트들을 이용해서 문제점들을

더욱 분석하여도 아무런 문제 없지만 즉각적으로 개선된 점들을 파악하기 위해서 다양한 문제들을

한번에 볼 수 있도록 도와주는 오염도 시각화 차트를 통해서 전체적인 오염도 분포를 acra 와

한번 비교해보았다.

p


173

[그림 5-10] logdog 의 오염도 시각화 그래프

[그림 5-11] acra 의 오염도 시각화 그래프

위에서 보는 것과 같이 acra 에 비하여 오염도가 매우 줄어들었다는 것을 확인할 수 있으며,

그나마 있는 오염도도 Distance 와 같은 비교적 중요도가 낮은 요소들인 것을 알 수 있다. 그리고

실제적으로 오염도의 차이를 알기 위해서 acra 에서 계산되서 나오는 오염도 수준(프로젝트의

오염수준을 나타내는 값)은 3.70 으로 일반적인 프로젝트가 1.0 대가 나오는 것을 생각하면 매우

높은 수치가 나왔는데, 이에 반하여 logdog 은 일반적인 수치보다 낮은 0.67 이라는 오염수준이

나왔다.

이렇게 오염 수치와 의존성의 변화만 봐도 기존의 acra 보다 매우 개선되었다는 것을 알 수 있다.


174 SEC-2014-RM005

제 6 장 소프트웨어 아키텍처 분석의 결론

제 1절 소프트웨어 시각화 지표별 특성 및 범위

[그림 6-1] 지표별 분류 및 범위]

그림 6-1 을 보면, 4 장에서 다룬 각각의 지표들마다 커버하는 영역들을 다루고 있다. P

(Package), C (Class), M (Method), F(Field)를 의미한다.

해당 요소의 크기(line 의 줄)를 판단하기 위해서는 Line of Code 를 사용하면 되고, 분석 지표

툴을 통해 Package, Class, Method 에서 데이터를 추출할수 있다.

응집성을 판단하기 위해서는 Instability/Abstractness 그래프와 LCOM (Lack of Cohesion of

Method)를 사용하면 된다.

의존성을 판단하기 위해서는 DSM (Dependency Structure Matrix) , Relation Cahrd, Tangled,

Component Dependeyncy, Depth of Inheritance Tree, Number of Childer 을 참고하면 된다.

다양한 분기문(Branch)를 포함하는지 판단하기 위해서는 Cyclomatic Complexity 와 Weight

Method of Class 를 참고하면 된다.

또한 다양한 응답을 가지고 있는지를 판단하기 위해 Response For a Class 를 참고하면 된다.

p


175

제 2절 소프트웨어 아키텍처 분석 제품들의 분류

[그림 6-2] 아키텍처 분석 소프트웨어의 분류

4 장에서 언급한 도구들과 그 이외의 도구들을 Java / C++ 그리고 상용, 무료 버전으로 분류

하였다.

Google Code Pro Analytics - 이클립스 기반의 Java 코드 분석툴로 구글이 제공하고

있는 무료 툴이다. 코드 분석, 매트릭, 유닛 테스트 생성, 코드 커버리지, 유닛 테스트 에디터,

의존성 분석, 비슷한 코드를 찾아주는 기능을 가지고 있다.

Architexa - 코드를 분석하여, UML (Class, Sequence) , 계층 다이어그램을 추출해주는

툴이다. 분석 툴보다 UML 모델링 툴에 가깝다.

SonarCube - 코드를 분석해주는 설치 가능한 Web 서비스로, Java, C#, C/C++, PL/SQL,

Cobol 등 다양한 언어를 지원하는 오픈소스 플랫폼이다. 기능으로는 중복된 코드 검출,

코딩 가이드라인, 유닛 테스트, 코드 커버리지, 잠재적 버그 도출 등을 제공한다.

Stan4j - 이클립스 기반의 도구로, Java 언어의 분석을 지원한다. 핵심 기능으로는 의존

관계 분석, 다양한 지표를 시각화로 도출, 리포트 생성 기능을 제공한다. 500 개의 클래스

내에서는 무료 분석이 되며, 상용 버전은 20 만원대의 저가이다. 가격대 성능비가 매우

높은 툴이다.


176 SEC-2014-RM005

JArchitect, CppDepend, NDepend 등 - 각 언어별로 별도의 분석의 툴을 제공하고

있으며, 가격은 40~50 만원대이다. 오픈소스, 커뮤니티 버전은 무료로 제공하고 있다.

제공하는 기능으로는 82 개의 코드 분석 지표들, 의존성 그래프, 리포트 기능, 중복된 코드

검출등을 제공하며, 세밀하게 각 문제 지표들을 탐색할수 있게 SQL을 변경한 CQL, CQLinq를

제공한다.

Insight - C, C++, Java, C# 언어의 분석을 지원한다. 제공하는 기능으로는 소스 코드

분석, 코드 리뷰, 리포팅 기능, 코드 리펙토링, 아키텍처 분석이 가능하며, 다른 툴과 달리

어플리케이션의 보안적 결함을 발견하는 기능을 가지고 있다

Lattix - C, C++, Java, .NET, Fortran 등 다양한 언어를 지원하며, Dependency Structure

Matrix 를 기본으로 아키텍처를 분석하는 툴이다.

Strucuture 101 - Java, C++, 등 언어마다 별도로 플러그 인을 구입해야 하며, 기능은

Stan4j 보다 빈약하고 제한적이며 부족하다. 가격은 40,50 만원 선이라 추천하지 않는다.

제 3절 맺음

이 백서를 통해 소프트웨어 아키텍처 분석을 위한 다양한 정적 지표와 지원 도구등을 설명

하였다.

이러한 지료를 잘 활용하면, 시장에 출시전 발생할 문제를 조기 발견하여, 많은 비용을 절약

할 수 있고 개발팀의 생산성과 커뮤니케이션 향상에 많은 도움이 될 수 있다.

향후 기회에는 이 백서의 다음 연구로써, 지표와 아키텍처를 결합하여 아키텍처를 리펙토링 하는

방법과 품질의 또 다른 축인 동적 분석을 통해 리소스 관리, 환경적 오류를 도출하는 시각화

기법을 다루도록 하겠다.

sw아키텍처 참조모델 -...

Documents