[소프트웨어공학] 모듈화(Modularity)

소프트웨어 디자인

sw 디자인의 중요성?

• 디자인은 품질이 강화되는 곳이다.
• 디자인은 품질을 평가할 수 있는 sw표현을 제공한다.

좋은 설계의 특징

• 설계는 계층 구조를 나타내야 한다.
• 설계는 모듈식이어야 한다.
• 설계는 데이터와 절차에 대한 뚜렷하고 분리 가능한 표현을 포함해야 한다.
• 설계는 독립적인 기능적 특성을 나타내는 모듈로 이어져야 한다.
• 설계는 모듈과 외부 환경 간의 연결 복잡성을 줄이는 인터페이스로 이어져야 한다.
• 설계는 변화를 수용하기 쉬워야 한다.

모듈화 ⬆️ -> 개발비용 ⬆️ -> 유지보수 비용 ⬇️

효과적인 모듈화 설계

• 기능적 독립 : 각각의 모듈이 독립적인 기능을 해야한다.
• 추상화 및 정보 은닉 개념을 기반으로 설계
• 각 모듈에는 요구사항의 특정 기능이 있다.
• 각 모듈은 외부에서 볼 때 간단한 인터페이스여야 한다.
• 2가지 척도로 측정가능하다.
  • coupling : 어떤 모듈이 다른 모듈에 의존하는 정도
  • cohesion : 내적 요소들이 얼마나 관련성 높게 묶여있는지

---

Coupling

: 두 모듈간의 상호의존성 정도
낮은 커플링 시스템

• ripple effect를 예방 - 모듈의 한 포인트를 수정했을 때, 다른 모듈이 영향을 받지 않게.
• 이해성 강화

목적 : 커플링 최소화하기

• 독립적인 모듈로 만든다.
• 잘 파티션된 시스템 나타낸다.

낮은 커플링을 달성하는법

• 불필요한 관계 제거하기
• 필요한 관계도 최소한으로 하기

커플링 척도

: 위로 갈수록 best임

1. Message Coupling
2. Data Coupling
3. Stamp Coupling
4. Control Coupling
5. External Coupling
6. Common Coupling
7. Content Coupling

---

1. Message Coupling

: 모듈 간의 커플링이 가장 낮음
- 가장 느슨한 유형의 커플링이다.
- 상태 분산을 통해 달성할 수 있으며, 컴포넌트 통신은 매개변수 또는 메시지 전달을 통해 수행된다.
- 모듈은 서로 종속되지 않고 공용 인터페이스를 사용하여 매개변수가 없는 메시지를 교환한다.

2. Data Coupling

: 데이터에 의해 커플링 되어져 있음
- 매개변수로 통신하는 경우, 두 모듈은 데이터에 의해 커플링된다. 각 매개변수는 데이터의 기본 조각이다.
- 모듈은 통신해야 하기 때문에 데이터 커플링은 불가피하며 최소한으로 유지되는 한 무해하다.

※경고※

• 넓은 인터페이스를 피하고, 최대한 좁게 유지해라

• 권장사항 : 복합 데이터 정의 및 사용

• Tramp 데이터 피하기
  • 구조체를 쓸 때 보내지 않아도 될 데이터도 같이 보내지는 것을 피하기
  • 트램프 데이터 조각이 더 많은 모듈을 통과할수록 실수로 변경되거나 결함이 퍼질 가능성이 높아진다.
• 권장사항
  • 재구조화 필요(보낼 필요 있는 것만)

3. Stamp Coupling

: 하나의 모듈이 다른 하나의 복합 데이터 조각으로 전달되면 두 개의 모듈이 스탬프 결합된다.
- 스탬프 결합 모듈은 데이터 구조가 애플리케이션에 자연스럽고 불필요한 모호성이 없는 경우에만 괜찮다.

: 모듈 전체가 전달됨

※경고※

• 많은 필드가 포함된 레코드를 필드의 일부가 필요한 모듈에 전달하지 마라.
  • 관련 없는 모듈 간의 종속성을 생성함.
  • 모호성을 도입하고 유연성을 감소시키며, 불필요한 데이터를 포함한다.

• 권장사항 :  데이터 구조에서 실제로 사용되는 부분만 호출된 모듈로 전달되도록 모듈의 인터페이스를 좁힌다.
  • int ValidatePhoneNumber(char* phone)

• 번들링은 관련 없는 데이터 항목을 인공 데이터 구조로 수집하는 것을 의미함.
  • 번들링은 불필요한 모호함을 제공한다. -> 연관성이 없는 것을 번들링 하지마라. 

• 권장사항
  • 관련 없는 데이터 항목을 인공 데이터 구조로 수집하지 말 것.
  • 번들링을 풀고 기본 데이터와 단순 합성 유형을 사용하여 인터페이스를 정의해라.
• 애플리케이션에 의미 있는 데이터 구조를 정의해야 함.
• 즉, 도메인 전문가가 의미를 이해할 수 있는 경우에만 번들링 채택한다.

4. Control Coupling

: 안좋은 커플링임
: 두 모듈이 다른 모듈을 제어할 의도를 가지고 coupling되어 있는 경우이다.
제어방향

• Forward : caller가 callee의 내부 흐름을 제어
• Backward : callee가 caller의 내부 흐름을 제어

Forward Control

- MatchCustomerRecords는 SystemIOControl 모듈의 로직 중 사용할 부분을 명시적으로 결정함.
- caller는 호출된 모듈의 논리가 어떻게 구성되어 있는지 알아야 함.
권장사항

• 독점적으로 실행되는 각 로직에 대해 새로운 모듈을 정의하여 호출된 모듈을 분할한다.

Backward Control

- 호출된 모듈을 호출한 모듈의 일부 기능을 가정한다.
- 이것은 호출된 모듈의 유연성을 감소시킨다.

권장사항

• 제어 플래그 대신 descriptive 플래그 사용 -> 행위를 리턴하지 말고, 상태정보를 리턴하는 것이 좋음

5. External Coupling

: 두 구성 요소는 외부에서 부과된 것을 공유한다.
외부 도구 및 장치와의 통신과 관련됨.

• External file
• Device interface
• Protocol
• Data format

6. Common Coupling

: 두 개의 모듈이 동일한 전역 데이터 영역을 참조하는 경우
common coupling이 나쁜 이유

• Ripple effect
• 전역적으로 결합된 모듈의 유연성 부족
• 시간의 원격성이 도입됨 (언제 변수를 수정해야할 지?)
• 동일한 글로벌 영역을 다용도로 악용하는 행위
• 글로벌 영역의 활용도 파악 및 추적의 어려움

권장사항

• 일부 모듈에 의미 있는 전역 변수를 매개변수로 전환 -> 각각을 파라미터로 전달하는 형식이 더 좋음

• 모듈 범위의 변수로 선언해서 전역 영역에 대한 액세스를 제한한다. -> 같은 전역변수를 사용하는 것끼리 모듈로 쪼개라

• 각 전역 변수에 대한 액세스 함수 정의 -> 전역변수에 액세스 하는 함수를 따로 정의해서 사용해라

7. Content Coupling

: 두 모듈이 어떤 식으로든 다른 모듈의 내부를 참조하는 경우

• 모듈에서 분기되거나 다른 모듈로 넘어감
• 한 모듈은 다른 모듈 내의 데이터를 참조(변경)한다.
• 예) 어셈블리 프로그램, 'goto'문

Cohesion

: 모듈 내 요소의 기능적 관련성의 강도 측정

• 목표 : Cohesion 최대화하기
  • 요소가 서로 강력하고 진정으로 관련되어 있는 모듈을 만든다.
• Coupling과 Cohesion 간의 관계
  • 시스템 분할을 평가하는 2가지 방법
  • 모듈의 Cohesion은 종종 시스템의 다른 모듈과 얼마나 밀접하게 Coupling되는지를 결정한다.

-> 응집력 ⬆️ -> 커플⬇️ (반대는 성립x)

Cohesion 척도

: 위로 갈수록 best

1. Functional Cohesion
2. Sequential Cohesion
3. Communicational Cohesion
4. Procedural Cohesion
5. Temporal Cohesion
6. Logical Cohesion
7. Coincidental Cohesion

1. Functional Cohesion

: 기능적으로 응집력있는 모듈은 하나의 문제 관련 작업 실행에 모두 기여하는 요소를 포함한다.
-> 딱 한가지 일만 하는 모듈로 구성하라

• functional cohesion의 모듈은 강력하고 단일한 목적을 가지고 있다.
• 예) 
  • 각도의 cosine계산
  • 알파벳 구문 확인
• 다른 활동에 얽매이지 않고 한 가지 일만 수행하여 완료한다.

2. Sequential Cohesion

: 한 활동의 출력 데이터가 다음 활동의 입력 데이터 역할을 하는 경우

• Sequentially cohesive module은 일반적으로 좋은 결합을 가지며 쉽게 유지된다.

권장사항

• functional cohesion 모듈로 변환해라

• Sequential Cohesion vs Functional Cohesion
  • Functional Cohesion 모듈은 응용 영역의 어떤 개념에 해당할 수 있지만 Sequential Cohesion 모듈은 그렇지 않다.
  • Sequential Cohesion은 Functional Cohesion보다 재사용성이 떨어진다.

-> o,x문제 나올 듯

3. Communicational Cohesion

: 동일한 입력 또는 출력 데이터를 사용하는 활동에 기여하는 요소의 모듈

• Communicational Cohesion vs Sequential Cohesion
  • 수용 가능한 cohesion과 수용 가능한 coupling이 있어야 한다.
  • Sequential Cohesion모듈은 반드시 정해진 순서대로 진행되어야 하지만,Communicational Cohesion모듈에서는 실행순서가 중요하지 않다.

※경고※

• 호출자가 반환 값의 일부만 필요한 경우 : 일부 모듈은 고객의 이름을 찾아야 하고 대출 잔액에는 관심이 없다.
  • 모듈은 대출 잔액을 폐기하거나 고객 이름을 찾기 위해 자체 코드가 필요하다.

권장사항

• 각 기본 반환 값에 대해 Functional Cohesion한 모듈을 정의한다.

• 같은 데이터를 사용하는 활동 간의 코드 공유

• 처음 20명의 직원에 대한 급여 보고서만 생성하려면 어떻게 하나?

권장사항

• Functional Cohesion한 모듈로 정의

4. Procedural Cohesion

: Procedural Cohesion한 모듈은 제어가 각 활동에서 다음 활동으로 흐르는 서로 다른, 가능한 관련 없는 활동에 관여하는 요소이다.

• 단일 문제 관련 기능보다는 실행 순서에 따라 관련된다.

권장사항

• 관련 없는 활동을 제거하여 순차적/기능적 응집력으로 전환한다.

• 단일 루프를 사용하여 두 가지의 다른 활동 수행하게 됨

- table-A와 table-B는 각각 100개의 요소가 있는 전혀 관련이 없는 테이블이다.
- table-B의 길이가 120으로 변경되거나 table-B의 원소가 table-A-sum에 의존하게 되면 어떻게 되는가?

권장사항

• 두 개의 함수로 쪼개기

5. Temporal Cohesion

: 요소들이 시간에 관련된 활동에 관여하는 모듈
요소는 처리되는 시점에 따라 그룹화된다.

- 프로그래머는 시간에 의해서만 관련된 활동들 사이에서 코드를 공유하려고 하며, 모듈은 재사용하기 어렵다.
예시)

• 데이터를 저장하기 전에 모든 변수 초기화
• 열려 있는 모든 파일을 닫는다.
• 오류 로그를 작성한다.
• 사용자 알림을 위해 모든 메시지 처리

권장사항

• 초기화 및 종료의 경우, mighty 모듈(모든 걸 다 하는 모듈) 대신 기능 관련 데이터별로 별도의 초기화 및 종료 모듈을 정의

6. Logical Cohesion

: 실행할 활동이 모듈 외부에서 선택되는 동일한 일반 범주의 활동에 기여하는 요소
-> 비슷한 일을 한다고 죄다 모아두는 것

• 동일한 일반 활동을 여러 개 포함
• 활동 중 하나가 주어진 플래그 파라미터에 의해 수행됨
• 일부 파라미터는 비워두기도 함

권장사항

• 기능적 응집력을 가진 여러 모듈로 나눈다.

7. Coincidental Cohesion

: 요소들이 서로 의미 없는 관계의 활동에 기여하는 모듈

• 모듈의 일부분은 소스 코드에서의 위치만 관련이 있다.
• 일부 기능을 수행하는 데 필요한 요소가 시스템 전체에 흩어져 있다.
• 우발적이고 최악의 형태

최종 정리