아키텍처 설계(2): 결합도와 응집도

 

 

# 모듈화 품질척도

전 포스팅에서 말한 것처럼 모듈화와 관련된 두개의 개념인 '결합도', '응집도'가 존재한다.

 

교수님은 왜 서술형으로 시험을 내실까

아는 것과 외우는 것은 결이 다르지 않나. 저렇게 나눈 가지들만 봐도 객관식으로 내기에 좋아보이는데

 

# 모듈화 품질척도 - 결합도

 

결합도는 모듈간 상호 의존 정도를 얘기한다. 이러한 결합도가 낮다는 것은 모듈적 독립성이 높다는 뜻이고 잘 설계되엇다는 의미도 된다. 

데이터/스탬프/제어/공유/내용 결합도로 세분화시킬 수 있다.

 

1. 데이터 결합도

가장 바람직한 결합도이며 모듈간 의존도가 가장 낮다 

모듈의 독립성이 높다는 얘기이니 다른 모듈에 변경으로 인한 영향이 적을 것이다.

 

2. 스탬프 결합도

데이터구조를 통해 두 모듈의 매개변수가 전달된다.

호출되는 모듈은 오직 데이터 구조의 일부만 사용할 수 있다

단점으로는, 필요 이상의 데이터를 주고받거나 그 구조를 변경시킨다면 영향 받는 모듈이 점차 많아질 수 있다는 거다.

 

3. 제어 결합도

한 모듈이 다른 모듈의 로직을 제어한다

스탬프에서는 데이터를 매개변수로 하였으나 이번에는 Flag가 매개변수로 사용된다. flag를 쓰는 만큼, 논리적 응집도를 가진 모듈과 연관성을 가지게 된다.

이 제어 결합도의 단점은 '호출하는 모듈(Caller)'은 '호출된 모듈(Callee)'의 내부 로직을 잘 알고 있어야할 것이다. 그래야 어떤 제어를 어떻게 할 것인지 등을 결정할 수 있을테니 말이다.

그러나 이것이 정말 단점인 이유는 로직을 파악한다는 건 '정보 은닉'원칙에 위배되는 사항이며 제어하는 Caller모듈의 독립성이 하락되다보니 유지보수가 좋지않다.

 

4, 공통 결합도

두 모듈들이 공통된 전역 데이터를 사용한다. 전역 데이터라고 하면 C의 외부변수라든지 C++/JAVA의 public 접근제어자를 얘기한다

전역변수라는 말만 들어도 불안한데, 다른 모듈에서의 전역변수가 변경된다면 전역 데이터의 문제가 발생하거나 변경 자체만으로도 데이터를 사용중인 모든 모듈에 영향이 가해지는 단점이 있다.

 

5. 내용 결합도

모듈간 의존도가 가장 높다. 가장 안 좋다는 말이다.

A라는 모듈은 B모듈을 직접적으로 참조하고 있다. 보통 저급 언어 프로그래밍시에 발생하게 되는데 좀 더 구체적인 예는 다음과 같다.

  • 모듈p가 모듈q의 지역데이터를 참조한다
  • 모듈p가 모듈q의 지역레이블로 분기한다

역시나 이렇게 참조/분기하고 있는 모듈q가 변경되면 모듈 p도 영향이 가해지는 위험성이 존재한다.

 

 

# 모듈화 품질척도 - 응집도

결합도는 낮을수록 좋다고 했다. 응집도는? 높을수록 좋다.

모듈 구성요소들의 관련된 정도를 뜻하는 응집도는 응집도가 높을수록 밀접한 관련이 있고 따라서 잘 설계되었다는 거다.

기능적, 순차적, 교환적, 절차적, 시간적, 논리적, 우연적 응집도를 얘기할 수 있다

 

1. 기능적 응집도

모듈이 정확히 하나의 연산 혹은 목적을 달성한 것으로, 재사용성과 이해도가 좋다. 결함 또한 국소화 되었고 이는 결함이 발생한 곳이 연관된 쪽으로 묶인 곳에 찾아가면 되므로 편하다는 얘기다.

 

2. 순차적 응집도

모듈 안에서 한 opration의 출력이 다른 operation의 입력이 되는 경우다. 결국 다른 기능을 하는 아이들이 연관되어 있는 경우라 볼 수 있는데, 이러면 하나의 모듈에 이들 말고도 여러 개가 존재할 때 재사용이 떨어질 것이다. 그러므로 이를 해야할기 위해 모듈을 operation별로 세분화 시키는 방법을 이용하면 좋다. 

 

3. 교환적 응집도

모듈 안에서 모든 operation들이 동일한 자료를 사용하는 작업수행을 한다.

'모든', '동일한 자료' 두 개로 말 다했다. 불안하다.

 

4. 시간적 응집도

입출력을 공유하는 건 아닌데, 모듈 안에서 opration들이 정해진 순서대로 수행되어야만 하는 것이다.

 

5. 논리적 응집도

예시를 먼저 들겠다. 오류를 처리하는 모듈이라거나, 모든 입출력을 수행하는 bios모듈이 존재한다

무언가를 하는 모듈이라 설명은 할 수 있을지언정 제대로 세분화된 건 아니다. 기능적 응집도와 비교하자면 확실히 '정확히 하나의 연산 혹은 목적'을 달성하는 모듈은 아니다.

설명하는 바와 같이 인터페이스 이해(설명)가 어렵고 모듈의 코드들이 분산되었거나 엉켜지면 당연히 유지보수의 문제가 발생한다

 

6. 우연적 응집도

operation들이 관련이 없다. 모듈 안에서 이유없이 묶여져 있다. 

모듈을 이해하기도 어렵고, 재사용도 당연히 어렵고, 유지보수 또한 마찬가지로 문제가 발생하게 된다..

 

 

 

이후는 소프트웨어 아키텍처 스타일에 대한 내용으로 아키텍처를 마무리한다.