모듈화: 소프트웨어 시스템을 부분부분 쪼개어 개발하는 것 - 연관되는 것들을 class(= 하나의 모듈)로 묶어 모듈화를 진행함.
독립적인 기능이 있는 논리적 묶음에 해당되는 모듈로 시스템을 구성하도록 개발함.
모듈화의 장점
- 이해가 쉬움: 해당 기능의 의미만으로 모듈이 어떤 일을 수행할지 이해할 수 있음
- 팀 단위 개발 작업이 쉬워짐: 모듈을 기준으로 쪼개어 할당
- 변경에 의한 수정 사항 반영이 쉬움: 쪼개어져 있기 때문에 영향을 받는 모듈도 적기 때문
- 재사용 가능성이 높음: 독립적으로 존재하기 때문
- 추적성 높음: 수정을 진행하여도 일관성을 높게 유지 가능 & 체계적 모듈 간 연결성 높음
좋은 설계를 수행한 소프트웨어 특성
1. 설계가 계층적 구조를 나타냄 - 시스템은 서브 시스템으로 구성되고, 각 서브 시스템은 하위의 기능 영역인 모듈로 구성됨
2. 설계 결과가 모듈로 구성되어야 함 - 소웨 아키텍처 설계에 의해 나타나는 구성 요소는 모듈 개념이 있는 독립적인 컴포넌트로 구성돼야 함
3. 데이터와 처리 절차가 구분 가능하고, 분리된 표현으로 나타나야 함 - 유저 인터페이스/처리/데이터 계층을 구분하여 표현하도록 유도
4. 설계 결과는 독립적인 특성이 있는 기능 단위로 구현해야 함 - 모듈 간, 그리고 소웨와 외부의 상호작용을 최소화해야 함
좋은 모듈화 구조를 가지는 소프트웨어
- 모듈 간 연관 관계가 적을수록 모듈화가 잘 된 설계
- 가능하면 간단한 형태로 구성되어야 함
결합도: 연결된 선 간 코드의 연관성
응집력: 모듈(class) 내 코드의 관련성 - 모듈 내에서는 관련성이 높아야 좋고, 모듈 밖에서는 관련성이 낮아야 좋음
=> 낮은 결합도 & 높은 응집력이 좋은 모듈화 구조
결합도: 모듈 간 의존성 관계
결합력이 낮을수록 좋은 설계 - 독립적인 기능을 가지도록 설계해야 함 (상호작용이 없도록)
결합력을 최소화할 시
- 구성 요소 간 결합력이 느슨해짐
- 변경에 의한 파동 효과 줄어듦
- 소웨에 대한 이해도 높아짐
- 인터페이스 단순해짐
좋은 결합력 순서대로
메시지 > 데이터 > 스탬프 > 제어 > 외부 > 공유 > 내용
메시지 결합력
- 클래스 개념을 사용함
- Public & Private을 통해 캡슐화
- 서로 다른 상태를 가지는 객체는 서로 다른 모듈로 간주될 수 있음
- 객체 간 상호작용을 최소화함
- 객체 간 상호 작용이 메시지 전달에 의해서만 이뤄짐
메시지 전달: 객체가 객체로 보내는 함수 호출 ex. Net에서, 클라이언트 - 서버 간 메시지 통신
데이터 결합력
- 2개의 모듈이 정수형, 문자형 등 단순한 기본 데이터 타입을 가지는 변수들에 의해 상호작용됨
- 각각의 모듈이 존재하고, 이것들을 A에서 토큰으로 쪼개어 B로 전달함 -> A와 B는 데이터 포맷만 맞춰 주면 됨
스탬프 결합력
- 두 모듈이 구조체와 같은 복합 데이터를 이용하여 상호작용함
- 구조체 정의 시, 의미상 상호 관련성이 있는 데이터들을 묶음으로 정의함
- 전달되는 구조체의 멤버 정보가 상호작용에 활용될 수 있도록 정의함
이때 관련성이 적은 데이터를 의미 없이 묶지 않도록 주의해야 함 -> 그럴 바엔 구조체를 두 개로 분리하여 선언하는 게 나음
제어 결합력
- A에서 B로 매개변수 전달 시, 매개변수가 호출되는 함수의 내부 행위를 제어함 (플래그 전달)
외부 결합력
- 외부에 존재하는 다른 정보를 공유함
외부 정보: 파일, 디바이스 인터페이스, 프로토콜 등 한 모듈과 외부에서 제공하는 도구 및 장치들 간의 상호작용
- 다른 모듈의 변수 변경이나 동시 접근으로 인해 데드락 발생할 수 있음
ex. 공유 메모리
공유 결합력
- 광연 변수를 공유하는 상태
- 공유 결합력 관계에 있다는 것은, 외부 결합력과 비슷하게 한 모듈의 공유 변수에 대한 수정이 다른 모듈에 영향을 줄 수 있음을 의미함
- 때문에 모듈 간 의존성을 높이는 문제 발생할 수 있음
- 그러나 메모리 사용량 줄이기 가능, 프로그램 간단히 작성 가능하다는 장점도 존재
=> 독립성을 보장하기 위해서는 꼭 필요한 변수만 광역 변수로 선언해야 함
=> 공유하는 부분이 있다면 구분하여 개발해야 함 (ppt ch_09 p.19)
응집력: 모듈을 구성하는 내적 요소 간 기능적 관련성의 강도를 측정하는 척도
내적 요소에는 명령어, 변수 정의, 함수 호출 등이 있음.
소프트웨어 설계 과정에서는 독립적인 기능을 갖춘 모듈을 식별하는 것이 중요하고, 모듈의 응집력을 최대화하는 것이 목표임.
좋은 응집력부터 순서대로
기능 > 순차 > 교환 > 절차 > 시간 > 논리 > 우연
기능 응집력: 모듈을 구성하는 모든 요소가 하나의 기능을 구현하기 위해 구성됨
ex. 수학에서 cos 각 계산, 문장의 알파벳 오류 체크, 미사일의 타격 지점 계산, 승객의 좌석 배정
순차 응집력: 한 문장의 실행 결과가 다음 문장의 입력으로 사용됨
ex. A 실행 시 결과가 B 실행 -> C -> D -> ...
서로 입출력 관계에 있는 문장으로 굿어되었다 해도, 마지막 문장이 기능 응집력을 충족하지 못하면 응집력의 효과는 저하됨
떄문에 순차 응집력을 구성하는 모든 문장이 기능 응집력을 만족하도록 정의하는 것이 중요함
교환 응집력: 모듈을 구성하는 모든 요소가 동일한 입출력을 사용함
그러나 의미 없는 부가 연산을 하게 될 수 있음 (ppt ch_09 p.27)
이를 방지하기 위해 모듈을 분리하여 return 값을 한 모듈에 몰아 넣는 게 아니라 각 모듈에 두어야 함 (p. 28)
절차 응집력: 모듈을 구성하는 문장들이 의미상으로는 서로 관련이 없지만, 제어 흐름의 순서가 있는 경우
ex. 과목별 성적 읽기 -> 성적 총점 구하기 -> 지난 학기 총점과 비교 -> 총점 이용해 평균 산출 -> 석차 부여
위 흐름은 의미상 관련은 없지만 제어 흐름에 순서가 있기 때문에 절차 응집력의 예시로 볼 수 있음
시간 응집력: 특정 시간과 관련되어 있는 경우
ex. 데이터 사용 전 모든 변수를 처음에 초기화, 파일 사용 전 모든 파일 오픈, 사용자에게 알림 정보 제공하기 위해 모든 메시지를 처리
위 기능들은 의미상 관련은 없지만, 시간 흐름상 모두 사전에 수행되어야 하는 기능들이므로 모듈화되어 있음을 알 수 있음 -> 때문에 시간 응집력의 예시
논리 응집력: 논리적으로 같은 유형의 외부 동작들로 구성된 경우
개발 시에는 편하지만 좋은 응집력은 아님.
우연 응집력: 모듈을 구성하는 모든 요소가 아무런 관련성이 없는 것들로 묶인 경우
절대 작성되어서는 안 되는 최악의 모듈 구성
!!! 결합력이 낮고 응집력은 높은 모듈 구성으로 이루어진 설계가 좋은 설계임 !!!