Java 소스 코드 영향 분석 도구를 이용한 소스변경오류 발생 방지

오늘은 Java 소스 코드 영향 분석 도구에 대해서 알아보도록 하겠습니다.

 

사이트가 만들어지고 운용됨에 따라 점차 기능이 추가되어 , 향후에는 걷잡을 수 없을 정도록 복잡한 소스가 되는 경우가 많습니다. 이러한 경우에 운영을 위해서는 필수적으로 소스변경에 따른 영향도 분석이 꼭 필요한 상황이 됩니다.

해당 사이트에 오래 근무한 인력이 있어도 새로운 인력이 계속들어오고 교체됨에 따라서 사이트에 대하여 깊이 있게 아는 사람은 점점 줄어들게 됩니다. 이런 경우 소스 변경시의 오류가 증가하게 됩니다.

 

이런 상황을 맞이하였을때,  다음을 포함하여 여러 가지 Java 소스 코드 영향 분석 도구를 사용할 수 있습니다.

 

---

아래는 Java 소스 코드 영향 분석 도구입니다. 

이러한 도구 중 다수는 영향 분석만을 위한 것이 아니라 영향 분석 기능이 있다는 점에 유의해야 합니다. 또한 특정 사용 사례에 따라 최상의 결과를 얻기 위해 둘 이상의 도구가 필요할 수 있습니다.

 

다음은  Java 소스 코드 영향 분석 도구의 웹 사이트입니다.

1. SonarQube: 코드 품질을 지속적으로 검사하기 위한 오픈 소스 플랫폼입니다. 유명한 툴이니 언급하지 않도록 하겠습니다. 주로 소스품질분석에 사용합니다.

https://www.sonarqube.org/

Self-managed | SonarQube

 

 

 

2. J아키텍트: https://www.jarchitect.com/

JArchitect :: Achieve Higher Java code quality

 

 

의존성 매트릭스도 보여줍니다.

 

 

가격은 $600 정도 듭니다.(한화 80만원정도)

 

 

 

3.스트럭처101: https://structure101.com/

Structure101 – Software Architecture Development Environment (ADE)

아래 그림과 같이 영향도를 도식화하여 표시해줍니다. 

다만 가격이 착하지는 않습니다. 

 

개발자용은 자신이 개발하고 있는 소스에 대하여 구조적으로 볼수 있도록 해주는 기능을 가지고 있습니다.

 

 

4.자바NCSS: 

http://www.kclee.de/clemens/java/javancss/

JavaNCSS - A Source Measurement Suite for Java

 

5. JDepend: 클래스 간의 종속성을 분석하여 Java 애플리케이션의 디자인 품질을 측정하는 도구입니다.

https://github.com/clarkware/jdepend

 

JDepend는 Java 클래스 파일 디렉토리를 탐색하고 각 Java 패키지에 대한 디자인 품질 메트릭을 생성합니다. JDepend를 사용하면 확장성, 재사용성 및 유지 관리 측면에서 설계 품질을 자동으로 측정하여 패키지 종속성을 효과적으로 관리할 수 있습니다.

 

 

 

JDepend는 깃허브에 소스가 올라져 있으며, 무료입니다.

특정소스에 영향을 주는 소스와, 또 특정소스의 영향을 받는 소스를 확인할 수 있으며, 이에 따라서 소스의 종속성과 추상성을 확인할 수 있습니다.

 

깃허브에서 내려받아서, 설치작업이 필요합니다.

자바환경, 그리고 ANT 설치 등의 작업이 필요합니다. https://ant.apache.org/bindownload.cgi  ㅅ

Apache Ant - Binary Distributions

시간이 되면 설치과정을 올려보려 합니다.

 

위 그림에 있는 것처럼 , JDepend는 Java 클래스 파일 디렉토리를 순회하고 다음을 포함하여 각 Java 패키지에 대한 디자인 품질 메트릭을 생성하여 제공합니다.

• 클래스 및 인터페이스 수(CC)패키지의 구체적인 클래스와 추상 클래스(및 인터페이스)의 수는 패키지의 확장성을 나타내는 지표입니다.
• 구심성 커플링(Ca)패키지 내의 클래스에 의존하는 다른 패키지의 수는 패키지의 책임을 나타냅니다.
• 원심성 커플링(Ce)패키지의 클래스가 의존하는 다른 패키지의 수는 패키지의 독립성을 나타냅니다.
• 추상성(A)분석된 패키지의 총 클래스 수에 대한 분석된 패키지의 추상 클래스(및 인터페이스) 수의 비율입니다.
• 이 메트릭의 범위는 0~1이며 A=0은 완전히 구체적인 패키지를 나타내고 A=1은 완전히 추상적인 패키지를 나타냅니다.
• 불안정성(I)I = Ce / (Ce + Ca)가 되는 전체 결합(Ce + Ca)에 대한 원심성 결합(Ce)의 비율. 이 메트릭은 변경에 대한 패키지의 복원력을 나타내는 지표입니다.
• 이 메트릭의 범위는 0~1이며 I=0은 완전히 안정적인 패키지를 나타내고 I=1은 완전히 불안정한 패키지를 나타냅니다.
• 주계열로부터의 거리(D)이상적인 선 A + I = 1에서 패키지까지의 수직 거리입니다. 이 메트릭은 추상성과 안정성 사이의 패키지 균형을 나타내는 지표입니다.이 메트릭의 범위는 0에서 1까지이며, D=0은 기본 시퀀스와 일치하는 패키지를 나타내고 D=1은 기본 시퀀스에서 최대한 멀리 있는 패키지를 나타냅니다.
• 메인 시퀀스에 있는 패키지는 추상성과 안정성 측면에서 최적의 균형을 이룹니다. 이상적인 패키지는 완전히 추상적이고 안정적이거나(x=0, y=1) 완전히 구체적이고 불안정합니다(x=1, y=0).
• 패키지 종속성 주기(V)패키지 종속성 주기는 패키지 종속성 주기에 참여하는 패키지의 계층 경로와 함께 보고됩니다.

 

텍스트 기반 정보도 제공합니다. XML로도 정보를 제공합니다. 추가적인 분석은 사용자의 몫입니다.

 

JDepend 사용 이유

 

JDepend를 사용하기 전에 "좋은" 디자인 품질 메트릭이 반드시 좋은 디자인을 나타내는 것은 아니라는 점을 이해하는 것이 중요합니다. 마찬가지로 "나쁜" 디자인 품질 지표가 반드시 나쁜 디자인을 나타내는 것은 아닙니다. JDepend에서 생성한 설계 품질 지표를 모든 설계를 측정하는 기준으로 사용해서는 안 됩니다.

JDepend에서 생성한 디자인 품질 지표는 디자이너가 자신이 만든 디자인을 측정하고, 해당 디자인을 이해하고, 지속적인 리팩토링을 진행하는 동안 디자인이 예상 품질을 나타내는지 자동으로 확인하는 데 사용하기 위한 것입니다. 리팩토링은 의심할 여지 없이 설계의 형태가 변경됨에 따라 이러한 메트릭을 일부 조정하게 됩니다.

 

설계 품질 측정

설계의 품질은 확장성, 재사용성 및 유지보수성 정도를 정량화하여 부분적으로 측정할 수 있습니다. 이러한 품질은 모두 디자인의 패키지 간 종속성에 의해 영향을 받습니다. 디자인은 구현 세부 사항과 독립적일 때 더 확장 가능하므로 내부 수정이나 기존 계약 위반 없이 새로운 구현에 적응할 수 있습니다. 이와 같은 독립성은 설계 부분의 재사용 가능성을 높이는 경향이 있습니다. 높은 수준의 추상화를 포함하는 디자인의 독립적인 부분은 구현 세부 사항을 포함하는 부분에서 추출할 수 있습니다.

시스템의 다른 부분으로 전파하지 않고 변경을 쉽게 수행할 수 있을 때 설계의 유지 관리 용이성이 향상됩니다. JDepend를 사용하면 확장성, 재사용성 및 유지 관리 측면에서 디자인의 품질을 자동으로 측정하여 패키지 종속성을 효과적으로 관리하고 제어할 수 있습니다.

 

종속성 반전

JDepend를 사용하는 목적은 낮은 추상화 패키지가 높은 추상화 패키지에 의존하도록 궁극적으로 패키지 종속성을 반전시키는 것입니다. 이러한 종속성 반전을 통해 높은 추상화 패키지를 독립적으로 재사용하는 동시에 개방형 구현 집합으로 확장할 수 있습니다. 일반적으로 안정적인 패키지에 대한 종속성은 바람직하지만 불안정한 패키지에 대한 종속성은 바람직하지 않습니다. JDepend를 사용하면 종속성을 반복적으로 검사하고 소프트웨어 설계 및 개발의 필수 부분으로 리팩토링할 수 있습니다.

 

병렬, 익스트림 프로그래밍 촉진

안정적인 패키지는 느슨하게 결합된 애플리케이션의 중심이 되어야 개발 팀의 속도가 소프트웨어 변경 전파로 인해 부정적인 영향을 받지 않습니다. 안정적인 패키지는 다른 하위 시스템에 대한 설계별 외관을 형성하여 팀이 극단적인 속도로 병렬로 개발할 수 있도록 합니다. 또한 소프트웨어 설계 품질을 측정하여 제안된 소프트웨어 변경의 전반적인 영향을 정확하게 예측할 수 있습니다. JDepend를 통해 팀은 시스템에서 바람직한 종속성을 식별 및 사용하고 변경 사항이 시스템 전체에 파급되는 종속성을 피할 수 있습니다.

 

타사 패키지 종속성 분리

타사 패키지 종속성은 해당 패키지에 대한 구심성 결합을 검사하여 쉽게 식별하고 격리할 수 있습니다. 이러한 타사 패키지에 대한 종속성이 JDepend로 측정되면 타사 패키지 구현 세부 정보를 캡슐화하는 추상적이고 안정적인 패키지를 효과적으로 설계하여 종속성을 관리할 수 있습니다.

 

패키지 릴리스 모듈

응집력 있고 독립적인 패키지는 자체 릴리스 일정 및 버전 번호가 있는 자율 모듈로 릴리스될 수 있습니다. 독립 릴리스 후보인 단일 패키지 또는 프레임워크에서 협업하는 관련 패키지 그룹은 JDepend를 사용하여 설계 품질 지표를 평가하여 수집할 수 있습니다.

 

패키지 종속성 주기 식별

패키지 종속성 주기에 참여하는 패키지는 재사용성 및 해당 릴리스 주기와 관련하여 치명적입니다. 종속성 주기의 텍스트 보고서를 검토하여 패키지 종속성 주기를 쉽게 식별할 수 있습니다. 이러한 종속성 주기가 JDepend로 식별되면 다양한 개체 지향 기술을 사용하여 중단할 수 있습니다.

---

Java 소스 코드 영향 분석 프로세스

Java 소스 코드 영향 분석 프로세스에는 일반적으로 다음 단계가 포함됩니다.

1. 분석해야 하는 변경 사항 식별: 여기에는 코드 변경, 라이브러리 또는 종속성에 대한 업데이트 또는 시스템의 전체 아키텍처에 대한 변경이 포함될 수 있습니다.

2. 필요한 정보 수집: 여기에는 소스 코드, 문서 및 분석을 수행하는 데 필요한 관련 아티팩트 또는 데이터가 포함됩니다.

3. 영향 분석 도구 설정: 프로젝트의 특정 요구 사항에 따라 선택한 영향 분석 도구를 구성하고 설치합니다.

4. 분석 실행: 도구를 사용하여 변경 사항을 분석하고 변경 사항이 나머지 코드베이스에 미칠 영향을 식별합니다. 여기에는 영향을 받는 클래스, 메서드 및 변수를 식별하는 것뿐만 아니라 변경으로 인해 발생할 수 있는 잠재적인 버그 또는 오류가 포함될 수 있습니다.

5. 결과 검토: 분석 결과를 검토하고 이를 사용하여 변경 사항이 시스템에 미치는 영향을 이해합니다. 여기에는 잠재적인 문제나 위험뿐만 아니라 추가 테스트 또는 검증이 필요한 코드 영역을 식별하는 것이 포함될 수 있습니다.

6. 결과 전달: 개발자, 프로젝트 관리자 및 QA 팀과 같은 관련 이해 관계자와 분석 결과를 공유하여 모든 사람이 변경 사항의 잠재적 영향을 인식하도록 합니다.

7. 적절한 조치를 취하십시오: 분석 결과에 따라 리팩토링, 테스트 및 문서 업데이트와 같은 적절한 조치를 취하십시오.

 

---

부디 운영사고 없는 2023년을 누리십시오.

 

부끄러운 글이지만 구독과 좋아요를 부탁드립니다. ^^