응집도를 측정할 수 있는 방법

응집 (cohesion) #

응집은 소프트웨어 개발에서 중요한 개념 중 하나로, 모듈 내의 구성 요소들이 서로 얼마나 연관되어 있는지를 나타낸다. 컴퓨터 과학자들은 응집도의 측정 범위를 정의했는데, 가장 좋은 것부터 나쁜 것 순으로 나열하면 다음과 같다.

기능적 응집 (functional cohesion) #

모듈의 각 파트는 다른 파트와 연관되어 있고 기능상 꼭 필요한 모든 것이 모듈에 들어있다.

순차적 응집 (sequential cohesion) #

한 모듈이 데이터를 출력하면 다른 한 모듈이 그것을 입력받는 형태로 상호작용한다.

소통적 응집 (communication cohesion) #

두 모듈이, 각자의 정보에 따라 작동하고(거나) 어떤 출력을 내는 형태로 통신 체인 (communication chain) 을 형성한다. 예를 들어, 데이터베이스에 레코드를 추가하면 그 정보에 따라 이메일이 만들어지는 형식이다.

절차적 응집 (procedural cohesion) #

두 모듈은 정해진 순서대로 실행되어야 한다.

일시적 응집 (temporal cohesion) #

모듈은 시점 의존성 (timing dependency) 에 따라 연관된다. 예를 들어, 시스템들이 시동할 때 그대지 관련이 없어 보이는 것들을 초기화 하는 경우가 많은데, 이런 작업들이 일시적으로 응집되었다고 할 수 있다.

논리적 응집 (logical cohesion) #

모듈의 내부 데이터는 기능적이 아니라, 논리적으로 연관되어 있다. 예를 들어 자바의 StringUtils 패키지는 각기 다른 작업을 수행하는 정적 메서드가 많이 있지만 서로 연관성은 없다.

동시적 응집 (coincidental cohesion) #

같은 소스 파일에 모듈 구성 요소가 들어 있지만 그 외에는 아무 연관성도 없다. 이는 가장 좋지 않은 형태의 응집이다.

LCOM (Lack of Cohesion in Methods) #

코드의 응집도를 평가하기 위해서는 LCOM(응집 결여도, Lack of Cohesion in Methods) 메트릭을 사용할 수 있다. LCOM의 공식이 있지만 하나씩 말로 풀이하는 게 더 쉽게 때문에 공식을 따로 적지는 않겠다. LCOM의 공식을 말로 풀면, 공유 필드를 통해 공유되지 않는 메서드의 총 개수를 뜻한다.

예를 들어, private field a, b 가 있는 클래스가 있다고 하자. 이 클래스 안에는 a 만 엑세스 하는 메서드가 있고, b 만 엑세스하는 메서드도 있다. 공유 필드 (a와 b) 를 통해 공유되지 않는 메서드도 많이 존재한다. 그렇다면 이 클래스의 LCOM 점수는 높다고 할 수 있다. 즉 메서드의 응집 결여도가 높은 것이다. 좀 더 확실히 이해하기 위해 다음 그림을 보자.

(필드는 육각형, 메서드는 사각형으로 표시)

클래스 X는 LCOM 점수가 낮고 구조적 응집이 우수하다. 반면, 클래스 Y는 응집이 결여되어 있고, 필드/메서드 세 쌍을 각자 자기의 클래스에 두어도 별로 상관이 없을 듯 하다. 클래스 Z는 응집이 조함된 모양새로, 세 번째 필드/메서드 쌍은 자체 클래스로 빼내어도 될 것 같다.

이처럼 LCOM 메트릭은 코드베이스를 분석하는데 매우 유용하다. 하지만 소프트웨어 메트릭은 거의 대부분 한두가지 중요한 결함이 있는데, LCOM도 예외가 아니다. LCOM 메트릭이 찾아내는 것은 ‘구조적’ 응집 결여도 일 뿐, 이 메트릭만으로는 어떤 조각들이 서로 잘 맞는지 논리적으로 판단할 수는 없다.

이후에 보면 좋은 포스트: 메인 시퀀스로부터의 거리