SW 아키텍처 모듈화: 객체지향 설계 품질 향상 - CBO(객체 간 결합도) 메트릭 완벽 가이드

결합도 측정

 

<< 소프트웨어 공학 전체글 돌아가기

 

소프트웨어 아키텍처 모듈화 관련글 보기

• SW 아키텍처 모듈화: 왜 필요하고, 언제 고려해야 할까?
• SW 아키텍처 모듈화: 어떻게 할 수 있을까? 고려사항은 무엇일까?
• SW 아키텍처 모듈화: 아키텍처 응집도 측정 기법 (Lack of Cohesion in Methods, LCOM)
• SW 아키텍처 모듈화: 아키텍처 결합도 측정 기법 (Afferent and Efferent Coupling)

---

"Coupling Between Objects (CBO)"는 객체 지향 소프트웨어 설계에서 모듈 간의 의존성을 측정하는 중요한 메트릭입니다. CBO는 클래스가 다른 클래스들과 얼마나 많은 의존성을 가지고 있는지를 정량적으로 평가합니다. 높은 CBO 값은 클래스 간의 결합도가 높다는 것을 의미하며, 이는 시스템의 유지보수성을 저하시킬 수 있습니다. 반대로, 낮은 CBO 값은 클래스 간의 결합도가 낮아 독립적인 변경이 용이함을 나타냅니다.

 

Coupling Between Objects (CBO)의 정의

CBO는 특정 클래스가 다른 클래스와 얼마나 많은 연결 또는 의존성을 가지는지를 측정합니다. 이 의존성은 클래스의 메서드 호출, 클래스 인스턴스 생성, 데이터 필드 접근 등으로부터 발생할 수 있습니다.

 

 

 

의존성의 예

한 클래스가 다른 클래스의 메서드를 호출하거나, 다른 클래스의 객체를 생성하거나, 다른 클래스의 데이터를 직접 참조하는 경우 모두 CBO에 포함됩니다.

 

CBO는 클래스 간의 결합도를 평가하는 데 사용되며, 높은 CBO 값은 한 클래스가 여러 다른 클래스에 강하게 결합되어 있음을 나타냅니다. 이러한 결합은 유지보수와 확장을 어렵게 만들 수 있습니다.

 

CBO의 계산 방법

클래스 A를 기준으로 다른 클래스와의 의존성 수를 계산:

• 클래스 A가 다른 클래스 B의 메서드를 호출하는 경우.
• 클래스 A가 다른 클래스 C의 필드에 접근하는 경우.
• 클래스 A가 다른 클래스 D의 객체를 생성하는 경우.
• 클래스 A가 다른 클래스의 타입을 사용하는 경우 (매개변수 타입, 반환 타입 등).

다른 클래스들과의 의존성 수를 합산:

• 각 의존성을 하나의 결합으로 간주하고, 이러한 결합의 총 수를 계산합니다.

 

 

CBO 계산 예

클래스 OrderProcessor가 PaymentService, InventoryManager, NotificationService라는 세 개의 다른 클래스를 사용하고 있다고 가정합시다.

• OrderProcessor는 PaymentService의 메서드를 호출하고,
• InventoryManager의 객체를 생성하며,
• NotificationService의 필드를 참조한다고 가정할 때,

이 경우 CBO는 3이 됩니다. 즉, OrderProcessor 클래스는 세 개의 다른 클래스에 의존하고 있으므로, CBO(OrderProcessor) = 3입니다.

 

일반적인 CBO 계산식

CBO는 클래스가 의존하는 다른 클래스들의 수를 단순히 합산한 값으로 계산됩니다.

즉, 클래스 A가 직접 참조하고 있는 클래스의 수가 CBO 값이 됩니다.

 

중요한 점

• 상속: 만약 클래스 A가 클래스 B를 상속받고 있다면, 클래스 A의 CBO 계산에 클래스 B가 포함될 수 있습니다.
• 인터페이스: 클래스 A가 특정 인터페이스를 구현하고 있다면, 이 인터페이스 역시 CBO 계산에 포함될 수 있습니다.
• 외부 라이브러리: 외부 라이브러리 클래스에 대한 의존성도 CBO 계산에 포함됩니다.

 

CBO의 의미와 활용

CBO는 소프트웨어 설계의 품질을 평가하는 중요한 지표로, 주로 다음과 같은 목적으로 사용됩니다:

• 설계 품질 평가: 높은 CBO 값은 클래스 간의 의존성이 커서, 시스템의 복잡도가 증가하고 유지보수가 어려워질 가능성을 시사합니다. 반대로, 낮은 CBO 값은 클래스가 독립적으로 설계되어 있어, 시스템의 모듈성이 높고 유지보수가 용이함을 의미합니다.
• 리팩토링 필요성 판단: CBO가 높은 클래스는 리팩토링의 대상이 될 수 있습니다. 예를 들어, 특정 클래스가 여러 다른 클래스에 지나치게 의존하고 있다면, 이를 분리하여 결합도를 낮추는 것이 좋습니다.
• 변경 영향 분석: CBO는 클래스가 변경될 때 다른 클래스에 미치는 영향을 예측하는 데 유용합니다. 높은 CBO 값은 한 클래스의 변경이 여러 다른 클래스에 영향을 미칠 가능성을 시사합니다.

 

CBO의 한계

CBO는 매우 유용한 메트릭이지만, 다음과 같은 한계가 있습니다:

• 양적 측정의 한계: CBO는 클래스 간의 결합도 양을 측정하지만, 결합의 질적 측면은 고려하지 않습니다. 즉, 모든 결합이 동일하게 중요하거나 문제가 되는 것은 아닙니다.
• 디자인 패턴의 영향: 일부 디자인 패턴, 특히 의존성 주입(Dependency Injection) 패턴을 사용하면 CBO 값이 높아질 수 있지만, 이는 오히려 코드의 유연성과 테스트 가능성을 높이는 방향으로 작용할 수 있습니다. 따라서 CBO는 다른 메트릭과 함께 사용하여 종합적으로 평가하는 것이 좋습니다.

---

참고 문헌

1. Chidamber, S. R., & Kemerer, C. F. (1994). “A Metrics Suite for Object Oriented Design.” IEEE Transactions on Software Engineering, 20(6), 476-493.
2. Martin, R. C. (2003). “Agile Software Development: Principles, Patterns, and Practices.” Prentice Hall.
3. Pressman, R. S. (2014). “Software Engineering: A Practitioner’s Approach.” McGraw-Hill.

---

<< 소프트웨어 공학 전체글 돌아가기

 

소프트웨어 아키텍처 모듈화 관련글 보기

• SW 아키텍처 모듈화: 왜 필요하고, 언제 고려해야 할까?
• SW 아키텍처 모듈화: 어떻게 할 수 있을까? 고려사항은 무엇일까?
• SW 아키텍처 모듈화: 아키텍처 응집도 측정 기법 (Lack of Cohesion in Methods, LCOM)
• SW 아키텍처 모듈화: 아키텍처 결합도 측정 기법 (Afferent and Efferent Coupling)