모듈화, 결합도/응집도
태그 :
- 개념
- - SW 개발에 있어 기능을 분할하고 추상화하여 소프트웨어의 성능을 향상시키고 유지보수를 효과적으로 하기 위한 SW 설계 및 구현 기법
1. 효율적인 프로그램 구성을 지원하는 모듈화의 개요
가.모듈화(Modularity)의 정의
SW 개발에 있어 기능을 분할하고 추상화하여 소프트웨어의 성능을 향상시키고 유지보수를 효과적으로 하기 위한 SW 설계 및 구현 기법
나. 모듈화의 원리
구분 |
설명 |
분할과 지배 (Divide & Conquer) |
복잡한 문제를 분해, 모듈 단위로 문제 해결 |
정보 은폐 |
어렵거나 변경 가능성이 있는 모듈을 타모듈로부터 은폐 |
자료 추상화 |
각 모듈 자료구조를 액세스하고 수정하는 함수내에 자료 구조의 표현 내역을 은폐 |
모듈의 독립성 |
낮은 결합도와 높은 응집도를 가짐 |
다. 모듈화의 특징
구분 |
설명 |
효과 |
비즈니스 측면 |
비즈니스 집중화 및 확장성 증가 |
비즈니스 변경사항에 대한 반영을 효율적으로 대처 |
관리적 측면 |
비즈니스 구현 기능이 구조적, 체계적으로 존재함으로 관리 수월 |
소프트웨어 개선, 유지보수등에 소요되는 시간 및 비용 절감 |
기술적 측면 |
중복 기능 방지 및 재사용성 효율 증대 |
모듈의 컴포넌트화 |
라. 모듈화의 필요성
구분 |
설명 |
개발 측면 |
- 복잡도 감소로 프로그램 개발의 용이성, 시험, 통합 용이성 요구 |
유지보수 측면 |
- 프로그램 재사용을 통한 유지보수 용이성 요구 |
성능/비용 측면 |
- 오류 파급효과 최소화, 단위당 프로그램 개발 노력/비용 최소화 요구 |
마. 모듈화의 장점
프로그램의 효율적인 관리 및 성능향상
전체적인 소프트웨어 이해의 용이성 증대 및 복잡성 감소
소프트웨어 시험, 통합, 수정시 용이성 제공
기능의 분리가 가능하고 인터페이스가 단순
오류 파급효과 감소
모듈의 재사용성 증대로 개발 및 유지보수 용이
바. 모듈화 기법의 종류 및 개념
구분 |
모듈화 기법 |
내용 및 개념 |
설계 |
Module (Function) |
설계시 관련이 있는 기능을 모아 한 부분에 모아놓고 library 형태로 사용 |
컴포넌트 |
바이너리형태의 재사용 가능한 형태로 인터페이스에 의해 로직을 수행 할 수 있는 모듈단위 |
|
서비스 |
기존 컴포넌트 보다는 Loosely –coupled 한 형태의 기능을 제공하는 모듈단위 |
|
구현 |
Macro |
프로그램 구현 시 반복되는 부분을 특정 이름을 부여하고 이름을 호출하여 실행할 수 있도록 하는 프로그래밍 기법. 단, 전처리기는 macro가 사용된 모든 곳에 코드를 대체해 놓음 |
Function |
프로그램 구현시 커다란 프로그램의 일부코드로 특정한 작업을 수행하고 상대적으로 다른 코드에 비해 독립적인 모듈 |
|
Inline |
프로그램 구현 시 반복되는 부분을 특정 이름을 부여해 놓고 이름을 호출하여 실행 할 수 있도록 하는 프로그램 기법.단, 컴파일러는 이 inline이 사용된 모든 곳에 코드를 복사해 놓음 |
2. 모듈화의 개념도 및 주요특성
가. 모듈화의 개념도
소프트웨어의 문제영역에서 시스템의 독립적인 부분으로 분활
복잡한 문제를 작고 간결한 문제로 나누어 해결
문제가 내포하는 특성을 고려하여 각 기능단위로 분할처리
나. 모듈화의 주요 특성
구분 |
설명 |
비고 |
모듈성 (Modularity) |
- 프로그램을 효율적으로 관리할 수 있도록 하는 소프트웨어의 특성으로 시스템 분해 및 추상화를 통해 소프트웨어 선응 향상을 위한 적합한 프로그램 단위 |
|
응집도 (Cohesion) |
- 모듈의 독립성을 나타내는 개념으로 하나의 모듈 내부 처리 요소들간에 기능적 연관도를 측정하는 척도 |
높을수록 좋음 |
결합도 (Coupling) |
- 소프트웨어 구조에서 모듈간 연관성을 측정하는 척도 |
낮을수록 좋음 |
3. 모듈화와 개발 비용과의 관계
가. 소프트웨어 개발 단계별 모듈화과 개발 비용의 관계
프로세스 |
모듈성 |
비용 요소와의 관계 |
분석 |
요구기능과 프로세스 모델링의 추상화 수준 |
요구도출, 검증 비용, 설계단계 생산성의 기반 |
설계 |
아키텍처 구성요소 정의수준과 관계의 복잡성 |
설계의 복잡성, 인터페이스 유연성, 구현 용이성 |
개발 |
프로시저, 객체, 컴포넌트, 서비스, 분리 기준 |
개발영역 분할과 개발자간 의사소통 노력 |
테스트 |
시스템, 서브 시스템, 모듈, 인터페이스 |
시스템 통합 및 테스트 비용 |
유지보수 |
모듈간 자료공유도, 모듈내의 응집도 |
SW의 이해와 변경의 노력 |
나. 소프트웨어의 모듈성과 개발 비용간의 상관관계 그래프
모듈의 세분도가 증가 할수록 모듈당 비용은 감소하지만 인터페이스 비용은 증가하게 되므로 적정 수준의 모듈성 유지
4. 모듈화의 주요특성, 응집도(Cohesion) 및 결합도(Coupling)
가. 소프트웨어 응집도(Cohesion)의 정의
정보은닉 개념의 확장개념으로, 하나의 모듈은 하나의 기능을 수행하는 집적성을 지칭함
모듈의 독립성을 나타내는 개념으로 모듈내부 구성원간의 연관도
나. 소프트웨어 응집도(Cohesion)의 단계
응집도 |
설명 |
낮음 높음 응집도는 높을수록 좋음 |
우연적 |
아무 관련성 없는 작업을 한 모듈에서 모음 |
|
논리적 |
유사한 성격의 작업들을 모음 |
|
시간적 |
같은 시간대에 처리되어야 하는 것들을 모음 |
|
절차적 |
모듈진행 요소들이 서로 관계되어지고 순서대로 진행 |
|
통신적 |
동일한 입,출력 자료를 이용하여 서로다른 기능을 수행하는 기능 |
|
순차적 |
작업의 결과가 다른 모듈의 입력자료로 사용 |
|
기능적 |
하나의 기능만 수행하는 모듈 |
다. 소프트웨어 결합도(Coupling)의 정의
모듈내부가 아닌 외부의 모듈과의 연관도(모듈간의 상호연관도)
소프트웨어 구조에서 모듈간의 관련성을 측정하는 척도
라. 소프트웨어 결합도(Coupling)의 단계
결합도 |
단계 |
낮음
높음 결합도는 낮을수록 좋음 |
자료 |
모듈들이 간단히 변수를 파라메터로 교환 |
|
스템프 |
모듈 사이에 자료구조 교환 |
|
제어 |
제어용 신호를 주고 받음 |
|
외부 |
모듈들이 소프트웨어의 외부환경과 연관 되는 경우 |
|
공통 |
많은 모듈들이 전역변수를 참조할 때 발생 |
|
내용 |
한 모듈이 다른 모듈의 내부자료나 제어정보를 사용 |
마. 결합도의 특징
서로 다른 상위 모듈에 의해 호출되어 처리 상 연관성이 없는 서로 다른 기능수행
자료전달이 인터페이스를 통과하므로 인터페이스복잡성에 의존적임
가능한 낮은 결합도가 복잡성을 감소시킴 (loosely coupled)
에러발생시 오류가 전파되어 다른 오류의 원인이 되는 리플효과 (Ripple)를 최소화 해야함.
5. 모듈화 기법, macro, function, inline 의 특징 및 공통점, 차이점, 장단점
가. macro, function, inline의 특징 및 사용 사례
구분 |
특징 |
사용사례 |
macro |
- 임의의 문자열에 이름을 정의했다가 필요한 곳에서 정의된 이름으로 문자열을 치환 - 프리프로세서(preprocessor)에 의하여 정의된 문자열로 치환되었다가 번역시간에 내부코드를 생성 - 프로그램 실행 중에 값이 변하지 않는 상수 또는 복잡한 문자열을 간단하게 이해하기 쉽도록 표현하기 위하여 사용 - 매크로의 매개변수는 주로 수식이나 문 함수(statement function)와 같은 성질의 문자열을 치환할 때 사용 |
#define MAX_SIZE 100 #define MIN(a, b) (a<b) ? a : b |
Function |
- 특정한 작업을 수행하는 프로그램의 부분단위로 Call을 위한 이름을 갖음 - 매개변수를 통하여 함수에서 처리할 데이터를 다양한 방법 (Call by Value, Call by Reference 등)으로 전달할 수 있음 - 정해진 처리를 한 후 결과 값을 반환할 수 있음 - 함수의 실행을 완료하면 그 함수를 호출한 곳으로 복귀 |
void func( arg1, arg2, …) |
inline |
- 함수 호출 위치에 함수의 처리 문장이 삽입되어 컴파일되는 함수 - 함수를 사용함으로써 얻을 수 있는 모듈화의 장점을 살리면서, 함수 호출과정에서 소비되는 부수적인 처리시간을 줄일 수 있음 - 매우 빈번히 호출되어 빠른 실행이 요구되는 함수를 inline 함수로 지정 - 컴파일러에 의해 다음과 같은 경우라면 일반함수로 번역 1. 함수가 너무 큰 경우 2. 순환 호출하는 경우 3. 프로그램 내에서 그 함수에 대한 포인터를 사용하는 경우 |
Inline int max (arg1, arg2) { .. } |
나. macro, function, inline의 공통점, 차이점, 장단점
구분 |
macro |
function |
inline |
||
공통점 |
- 반복되는 작업을 독립시켜 하나의 모듈로 작성하여 놓은 것 |
||||
차이점 |
- 매크로의 호출문은 전처리기(프리프로세서)에 의해 정의된 문자열로 치환됨 |
- 함수의 호출문은 컴파일러에 의해 번역시간에 모두 내부코드로 전환 |
- 기존 C언어의 Macro 대신 쓰고자 허용 (type checking, no side effect의 장점을 가짐) - 매크로는 전처리기에 의해 처리 되지만 인라인 함수는 컴파일러에 의해 처리됨 - 함수 자체가 메모리로 들어감. |
||
장점 |
- 번역시간에 내부코드를 생성하기 때문에 함수에 비하여 프로그램 실행시간이 빠름 -> 간단한 문자열 치환에 사용하는 것이 효율적 |
- 프로그램의 여러 곳에서 반복적으로 사용되는 기능을 함수로 정의하면 동일한 코드를 중복하여 작성하지 않아도 됨 (저장공간 절약) - 의미 있는 작업 단위로 모듈화하여 프로그램을 분할 작성함으로써, 간결하고 이해하기 쉬운 프로그램 작성 가능 |
- 속도 향상 (일반 함수보다 빠름) - MACRO와 같은 efficiency를 보여주지만 컴파일러에 의해서 수행됨. 따라서 디버깅이 쉽고 그냥 함수처럼 정의하면 되기 때문에 구현이 쉬우면서 type을 정의할 수 있음. |
||
단점 |
- 계속된 호출은 코드를 반복하여 치환하기 때문에 프로그램의 크기가 확장됨 - 메모리 사용이 많아질 수 있음 |
- 함수 호출 및 복귀 과정에서 처리 시간이 추가됨 - 실행이 느림 |
- 함수가 너무 크거나 복잡한 경우 인라인으로 정의하면 일반함수로 취급 - 프로그램 내에서 그 함수의 포인터를 사용하지 못함 (컴파일 타임 고려) |
6. 모듈화 개념의 진화 및 모듈과 컴포넌트의 차이
가. 모듈화 개념의 진화
응집도(우연적,논리적,시간적,절차적,통신적,순차적,기능적),결합도(자료,스템프,제어,외부,공통,내용) |
|
실세계의 객체를 속성과 매소드가 결합된 형태의 객체로 표현하는 개념(캡슐화,추상화,다형성,정보은닉,상속) |
|
독립적인 업무 또는 기능을 수행하는 소프트웨어 모듈인 컴포넌트를 개발하고 이를 기반으로 컴포넌트를 조립하여 새로운 어플리케이션을 구현 |
|
기존 어플리케이션의 서비스를 조합함으로써, 새로운 어플리케이션을 구현할 수 있도록 한 통합기술 및 아키텍쳐 모델(WebService,SOAP) |
- 모듈화는 기존 소스 코드 부터 비즈니스 서비스를 제공하는 SOA의 서비스 레벨까지 진화했으며, 재사용 단위 및 규모가 증가하고있음
나. 모듈과 컴포넌트의 차이
구분 |
컴포넌트 |
모듈 |
정의 |
특정 기능 수행을 위한 독립적, 조립적 수행 가능한 SW 단위 |
시스템을 분해하고 추상화하여 SW성능을 향상 시키고, 시스템 의 디버깅, 시험, 수정등을 용이 하게 하는 SW 설계기법 - SW 유지보수 시에 편리 |
사용성 |
독자적으로 사용자에게 특정 서비스를 제공할 수 있음 |
다른 모듈과의 통합 및 연계에 의해서만 가치있는 서비스 가능 모듈 + 모듈 |
서비스 |
다른 컴포넌트와의 인터페이 스를 이루면서 하나의 독립 어플케이션으로 서비스 가능 |
여러 개의 모듈이 조합하여 어플리케이션을 구성하여 서비스 가능한 형태 |
이기종 호환 |
플랫폼 혹은 구현 기능에 독립적 |
플랫폼 및 구현기술에 종속적 |
응용형태 |
분산 어플리케이션 |
단일 어플리케이션 |
재사용방식 |
실행 코드 기반 |
주로 Source 기반 |
접근 방식 |
모든 언어 대상 |
객체 지향 언어 |
개발방식 |
객체지향, CBD 개발방법론 |
모듈화를 프로그래밍 기법 적용 정보공학, 구조적 개발방법론이 해당됨 |
7. 임베디드 S/W 개발환경에서의 모듈화 기법 적용 및 활용지침
가. 임베디드 S/W 개발환경에서의 모듈화 기법 적용 전략
- 자원의 한계 및 도메인 요구사항에 맞는 모듈화 기법 적용이 필요
나. 임베디드 S/W 개발환경에서의 모듈화 기법 활용 지침
구분 |
기법 |
활용지침 |
실행시간 최적화 |
인라인 함수 사용 |
- C++에서는 모든 함수에 inline 키워드를 선언할 수 있다. - 일반적인 함수 호출에는 리턴 어드레스와 파라미터들이스택에 푸시되고 팝되는 과정이 수반되지만 - 인라인 함수가 사용되면 호출에 따른 이런 부수적인 처리들이 생략된다. - 그러나 인라인 함수는 사용(호출)되는 회수에 비례해서실행 파일의 크기가 늘어난다 |
간접 함수 호출 (참조테이블 최적화) |
- Switch Case 문에서 Case 문의 빈도를 알기 어려울 경우 Switch 문 자체를 간접함수 호출 형태로 변경 |
|
적절한 전역변수 사용 |
- 함수에 파라미터를 전달하는 것보다 전역 변수를 사용하는 것이 함수 호출에 따른 오버헤드를 줄일 수 있어 효율적이다. - 그러나 전역 변수의 사용은 일반적인 소프트웨어 개발론에서 극단적으로 피해야 될 방법이다. 함수 단위의 모듈화를 불가능하게 만들며 재진입 가능한 함수의 구현 역시 불가능해진다. - 절충안은 클래스의 구현을 통해 전역 변수의 효과를 얻는 방법이다. 공유되는 데이터를 클래스 안으로 숨기고 이 데이터에 접근해야 되는 관련 함수들을 클래스 메소드로 구현한다. |
|
코드 크기 최적화 |
표준라이브러리 미사용 |
- 모듈의 대명사인 표준 C/C++ 라이브러리를 사용하지 않는 것이다. - 무겁고 쓸데없는 라이브러리가 포함되기 때문에 포함시키지 않고 스몰 라이브러리 형태로 사용 |
스택 사용 줄이기 |
- 함수 사용을 통해 중복된 코드 또는 기능을 수행하여 스택 (메모리) 사용량 줄이기 |
- 임베디드 시스템 개발에서는 크기 최적화를 통해 작은 크기의 실행 파일을 생성하는 것이 더 유리
- 인라인 함수의 적절한 사용 및 함수 구현을 통한 중복코드 제거를 통해 임베디드 S/W 개발을 좀 더 효율적으로 진행 할 수 있음.
다. 임베디드 SW 품질 향상을 위한 전략
소비자 대상의 평가를 토대로 기능을 표준화하고 뚜렷한 성과를 보일 수 있는 SW기능 개발에 초점을 맞추어야 함
자동차 산업의 경우 매년 추가되는 새로운 기능으로 인한 비용과 복잡성이 점차 높아지고 있음
보다 성숙화ㆍ모듈화ㆍ표준화된 SW아키텍쳐 개발을 통해 콤포넌트의 재사용률을 높이고 인터페이스수를 줄일 수 있도록 해야 함
각각의 부품을 조립하는 HW중심의 접근법에서 벗어나 SW시스템을 통합하고 개발하는 기술을 향상시켜야 함
CMM, function point 등 SW개발 방법들은 많이 발전되어 있으나 임베디드 시스템 개발을 위한 툴이 부족하므로 이를 발전시킬 필요가 있음
8. 효율적인 모듈화 추진 방안 및 고려사항
가. 모듈화 향상을 위한 비용 효율적인 프로젝트 추진 방안
단계 |
주요 활동 |
기법 |
기획 |
수학적 및 경험적 기반의 소프트웨어 규모 산정 프로젝트 수행 방법론 및 모듈성 평가 방법 정의 |
Function Point,Delphi Method, Matrix 기법, Spreadsheet |
분석 |
기능적으로 세분화된 Use Case 도출 |
UML, Interview, Quality Matrix |
설계 |
초기 SW 구조 평가, 모듈성 개선 인터페이스 복잡성, 중복성 절감, 일관성 확보 |
Fan-out 최소화, Fan-in 최대화, 추상화,캡슐화,다형성 |
구현 |
모듈 내 분기의 적절성, 코드 크기의 적합성 평가 |
MDA, SCA 등 |
시험 |
모듈 중심의 테스트케이스 설계 및 테스트 수행 |
Test Harness, Mutation Test |
운용 |
비효율적 모듈의 재구성 및 완전성 확보 |
재구조화, 재공학, 순공학 |
나. 모듈화의 고려사항
초기 프로그램의 구조를 평가하여 결합도를 줄이고 응집도를 개선
높은 Fan-out를 가진 구조를 최소화하고 깊이가 증가할수록 Fan-in 노력
모듈의 제어영역 안에서 그 모듈의 영향영역을 유지함
모듈 인터페이스를 평가하여 복잡성과 중복성을 줄이고 일관성을 개선
기능이 예측 가능한 모듈을 정의하되 지나치게 제한적인 모듈은 피함
Modularity:
Software is divided into separately named and addressed components, or Modules, that are integrated to satisfy problem requirements.
The single attribute of software that allows a program to be intellectually manageable.
Modularity: Trade-offs
What is the "right" number of modules
for a specific software design?
Type |
Desirability |
Description |
Functional |
Acceptable |
One task |
Sequential |
Acceptable |
Common data, order important |
Communicational |
Acceptable |
Common data, order not important |
Procedural |
Occasionally Acceptable |
No common data, done at same time |
Temporal |
Not acceptable |
No common data, done at same time |
Logical |
Not acceptable |
Parallel but mutually exclusive tasks |
coincidental |
Not acceptable |
Activities with no relationship |
COHESION
Functional cohesion exists whenever a module carries out exactly one function.
COHESION |
개념도 |
Functional Cohesion (Acceptable)
|
Functional cohesion exists whenever a module carries out exactly one function. |
Sequential Cohesion (Acceptable)
|
The output of one task immediately serves as the input to the next. GET VALID TRANSACTION has sequential cohesion, and both of its subordinates have functional cohesion. |
Communicational Cohesion (Acceptable)
|
Several modules use the same inputs, but their order of execution is irrelevant. |
Procedural Cohesion (Not Acceptable)
|
Procedural cohesion is present when control, rather than data, is passed from one module to the next. Order is important but there are no shared or passed data. |
TEMPORAL COHESION |
Activities are traditionally done at the same time but have no other meaningful relationship; there are no data in common, and order is not important. |
Logical Cohesion (Not Acceptable)
|
Several related but mutually exclusive functions are in the same module, with a downward-flowing flag that notifies that module of which function to perform. On any given call, only the selected portion of code is executed. |
Coincidental Cohesion ( not Acceptable)
|
Coincidental cohesion exists when a module consists of totally unrelated activities. Modules with coincidental cohesion turn out to be “garbage routines”; they have no place in a carefully designed system. |
COUPLING
Coupling is an indication of the types of couples passed between two modules and of how dependent the modules are on each other
Type |
Desirability |
Description |
Data |
Acceptable |
Simple or single-field parameter |
Stamp |
Acceptable |
Multiple fields in one data structure |
Control |
Not acceptable |
Control flag |
Common |
Not acceptable |
Common area |
Content |
Not acceptable |
Internal change to a module |
COUPLING
|
개념도 |
Data Coupling |
Data coupling involves couples that consist of single-field parameters
Data Coupling on Left (Acceptable) and Stamp Coupling on Right (Acceptable) |
Stamp Coupling |
Stamp coupling involves a data structure, or composite data, such as a customer record or a payment transaction. |
Control Coupling |
Control coupling occurs when one module is made to control the internal logic of another, usually by means of a flag. |
Common Coupling |
When two or more modules refer to the same common or global area, common coupling exists between those modules. |
CONTENT COUPLING |
Content coupling occurs when one module directly refers to the inside of another module in any way. Unstructured branching into another module and using the COBOL verb ALTER are examples of content coupling. |