Chapter 02. 공통 모듈 구현

1. 모듈의 특징

• 각각의 모듈은 상대적으로 독립성을 가짐
• 모듈 내부에는 그 모듈을 하나로 통합하는 수많은 조합이 존재할 수 있음
• 모듈은 단독으로 컴파일 할 수 있으며, 재사용 가능
• 독립성이 높은 모듈 일수록 모듈 수정 시에도 다른 모듈들에는 영향을 거의 미치지 않고, 오류 발생 시에도 쉽게 해결 가능
• 모듈의 독립성은 결합도와 응집도에 의해 측정되며, 독립성을 높이려면 도율의 결합도는 약학ㅔ, 응집도는 강하게, 모듈의 크기는 작게 만들어야 함

2. 모듈화 기법

• 루틴 (Routine) : 소프트웨어에서 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임
• 메인 루틴 (Main Routine) : 전체의 개략적인 동작 절차를 표시하도록 만들어진 루틴, 서브루틴 호출
• 서브 루틴(Subroutine) : 메인 루틴에 이해 필요할 때마다 호출되는 루틴

3. 응집도

• 모듈의 독립성을 나타내는 정도로, 모듈 내부 구성요소 간 연관 정도
• 하나의 모듈이 하나의 기능을 수행할 수록 응집도가 높음
• 응집도는 높을 수록 좋은 품질

4. 응집도 유형 (우논시절 통순기)

• 우연적 응집도 (Coincidental Cohesion)
  • 모듈 내부의 각 구성요소가 연관이 없을 경우의 응집도
• 논리적 응집도 (Logical Cohesion)
  • 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우의 응집도
• 시간적 응집도 (Temporal Cohesion)
  • 연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우의 응집도
• 절차적 응집도 (Procedural Cohesion)
  • 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
• 통신적 응집도 (Communication Cohesion)
  • 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여있을 경우의 응집도
• 순차적 응집도 (Sequential Cohesion)
  • 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우의 응집도
• 기능적 응집도 (Functional Cohesion)
  • 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우의 응집도

• 우연적 < 논리적 < 시간적 < 절차적 < 통신적 < 순차적 < 기능적

5. 결합도

• 모듈 내부가 아닌 외부 모듈과의 연관도 또는 모듈 간의 상호 의존성
• 소프트웨어 구조에서 모듈 간의 관련성을 측정하는 척도
• 결합도가 낮을 수록 좋은 품질

6. 결합도 유형 (내공 외제 스자)

• 내용 결합도 (Content Coupling)
  • 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우의 결합도
• 공통 결합도 (Common Coupling)
  • 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호작용하는 경우의 결합도
• 외부 결합도 (External Coupling)
  • 두 개의 모듈이 외부에서 도입된 데이터 포맷, 통신 프로토콜, 또는 디바이스 인터페이스를 공유할 경우의 결합도
• 제어 결합도 (Control Coupling)
  • 단순 처리할 대상인 값만 전달되는게 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우의 결합도
• 스탬프 결합도 (Stamp Coupling)
  • 모듈 간의 인터페이스로 배열이나 객체, 구조 등이 전달되는 경우의 결합도
• 자료 결합도 (Data Coupling)
  • 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호작용이 일어나는 경우의 결합도

• 자료 < 스탬프 < 제어 < 외부< 공통 < 내용

7. MVC 패턴

• Model
  • 애플리케이션이 무엇을 할 것인지 정의
  • 내부 비즈니스 로직을 처리하기 위한 역할
• View
  • 화면에 무엇인가를 보여주기 위한 역할
  • 모델, 컨트롤러가 보여주려고 하는 것들을 화면에 처리
• Controller
  • 모델이 어떻게 처리할지를 알려주는 역할
  • 뷰에 명령을 보내어 화면 요청 결과를 전달

8. 팬인(Fan-In), 팬아웃(Fan-Out)

• 팬인과 팬아웃 분석을 통해 시스템 복잡도 측정
• 팬인
  • 어떤 모듈을 제어(호출)하는 모듈의 수
  • 모듈 자신을 기준으로 모듈에 들어오면 팬인
  • 팬인이 높으면 재사용 측면에서 설계가 잘 되었지만 잔일 장애점 발생 가능
  • 팬인이 높으면 관리 비용 및 테스트비용 증가
• 팬아웃
  • 어떤 모듈에 의해 제어(호출)되는 모듈의 수
  • 모듈 자신을 기준으로 모듈에서 나가면 팬아웃
  • 팬아웃이 높을 경우 불필요한 모듈 호출 여부 검토 필요
  • 팬아웃이 높을 경우는 단순화 여부 검토 필요

9. 공통모듈 테스트 종류

• 화이트박스 테스트
  • 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방식
  • 소스 코드를 보면서 테스트 케이스를 다양하게 만들어 테스트를 수행
• 메서드 기반 테스트
  • 공통 모듈의 외부에 공개된 메서드 기반의 테스트
  • 메서드에 서로 다른 파라미터 값을 호추하면서 다양한 테스트 수행
• 화면 기반 테스트
  • 사용자용 화면이 있는 경우, 각각의 화면단위로 단위모듈을 개발 후에 화면에 직접 데이터를 입력하여 테스트 수행
  • 화면 기반 테스트는 화면과 연계된 서비스, 비즈니스 컴포넌트 및 공통 컴포넌트를 한꺼번에 단위 테스트에 참여
  • 사용자 시나리오에 기반한 공통 모듈 테스트를 할 수 있는 장점
• 테스트 드라이버(Driver) / 테스트 스텁(Stub)
  • 기능을 테스트할 수 있는 화면 또는 하위 모듈이 구현되지 않은 경우 테스트 드라이버, 테스트 스텁을 통해 테스트 수행
  • 테스트 드라이버는 하위 모듈은 있지만 상위 모듈은 없는 경우 사용
  • 테스트 스텁은 상위 모듈은 있지만 하위 모듈은 없는 경우 사용