응집도편집자 확인

우연적 응집도는 소프트웨어 공학에서 정의된 응집도의 여러 유형 중 가장 낮은 수준의 응집도를 의미한다. 이는 모듈 내부의 구성 요소들이 서로 아무런 의미 있는 관계 없이 단지 우연적으로 함께 묶여 있는 상태를 가리킨다. 예를 들어, 서로 다른 여러 프로그램에서 자주 사용되는 코드 조각들을 단순히 모아 하나의 루틴으로 만든 경우가 이에 해당한다. 이러한 모듈은 명확한 목적이나 책임이 없기 때문에 이해하기 어렵고, 유지보수와 재사용이 매우 힘들다.

우연적 응집도를 가진 모듈의 전형적인 예로는 "CommonFunctions" 또는 "MiscellaneousUtilities"와 같은 이름의 함수나 클래스를 들 수 있다. 이러한 모듈은 시간이 지남에 따라 서로 무관한 기능들이 계속 추가되기 쉬우며, 이는 소프트웨어 설계의 질을 현저히 떨어뜨린다. 래리 콘스탄틴과 에드워드 요던이 1974년 응집도 개념을 체계화하면서, 우연적 응집도는 개선해야 할 바람직하지 않은 설계의 대표적인 사례로 지목되었다.

따라서 현대의 객체 지향 설계나 구조적 설계 원칙에서는 우연적 응집도를 지양하고, 명확한 단일 책임을 가진 높은 수준의 응집도(예: 기능적 응집도)를 목표로 한다. 이는 결합도를 낮추고 전체 시스템의 모듈화 수준을 높이는 데 기여한다.

논리적 응집도는 여러 구성 요소들이 논리적으로 유사한 범주에 속한다는 이유로 하나의 모듈에 묶인 경우를 가리킨다. 이는 모듈 내부의 요소들이 동일한 유형의 데이터를 처리하거나, 유사한 종류의 연산을 수행하는 등 논리적으로 관련은 있지만, 서로 다른 기능을 수행할 수 있다는 특징이 있다. 예를 들어, 모든 데이터 입력 처리 루틴(키보드 입력, 파일 입력, 네트워크 입력)을 하나의 모듈로 묶거나, 모든 오류 처리 루틴을 하나로 묶는 설계가 이에 해당한다.

이러한 설계는 표면적으로는 관련 요소들을 그룹화한 것으로 보일 수 있으나, 실제로 모듈 내부의 각 구성 요소들은 서로 독립적으로 동작한다. 이로 인해 모듈의 인터페이스가 복잡해지고, 호출하는 측에서 특정 기능을 실행하기 위해 제어 플래그를 전달해야 하는 경우가 빈번히 발생한다. 결과적으로 모듈 간 결합도가 증가하고, 코드의 이해도와 유지보수성이 저하되는 문제점을 낳는다.

소프트웨어 공학에서 논리적 응집도는 우연적 응집도보다는 개선된 형태이지만, 여전히 바람직하지 않은 낮은 수준의 응집도로 분류된다. 이는 구조적 설계나 객체 지향 설계 원칙에서 지향하는 높은 응집도와는 거리가 있다. 설계 품질을 높이기 위해서는 논리적 응집도를 가진 모듈을 보다 세분화하여, 각각이 단일하고 명확한 책임을 가지는 기능적 응집도 수준의 모듈로 재설계하는 것이 권장된다.

시간적 응집도는 모듈 내의 구성 요소들이 특정 시간에 함께 실행되어야 한다는 사실에 의해 그룹화된 경우를 가리킨다. 이는 모듈이 초기화, 종료, 복구, 오류 처리와 같이 특정 시점에 수행되어야 하는 여러 작업들을 하나로 묶을 때 발생한다. 예를 들어, 프로그램 시작 시 필요한 초기화 작업, 메모리 할당, 설정 파일 로딩, 로그 시스템 구동 등을 하나의 모듈에서 처리하는 경우가 이에 해당한다.

이러한 모듈은 논리적 연관성보다는 실행 순서나 시점의 공유에 기반을 두고 설계된다. 따라서 모듈 내부의 각 작업들은 서로 다른 기능을 수행할 수 있으며, 데이터 흐름이나 제어 흐름 측면에서 강한 연관성을 가지지 않을 수 있다. 시간적 응집도를 가진 모듈의 전형적인 이름은 "시작하기", "정리하기", "중단 처리하기" 등 시간과 관련된 동작을 암시하는 경우가 많다.

시간적 응집도는 우연적 응집도나 논리적 응집도보다는 높은 수준으로 평가되지만, 기능적 응집도나 순차적 응집도보다는 낮다. 그 이유는 모듈이 단일한 목적이나 명확한 데이터 흐름을 갖기보다는, 단지 동일한 시간대에 실행된다는 이유로 결합되어 있기 때문이다. 이는 모듈화와 재사용성 측면에서 제한을 가져올 수 있으며, 향후 유지보수 시 특정 시점 작업만을 수정하려 할 때 불필요한 모듈 전체의 변경을 초래할 수 있다.

절차적 응집도는 모듈 내의 작업들이 특정 순서나 절차에 따라 실행되어야 한다는 공통점으로 묶인 경우를 가리킨다. 이는 모듈이 단일한 작업을 수행하는 기능적 응집도보다는 낮은 수준의 응집도로 평가된다. 모듈 내부의 구성 요소들은 특정 제어 흐름이나 알고리즘의 단계를 공유하며, 이는 종종 프로그램의 실행 순서나 프로세스의 흐름을 반영한다.

예를 들어, "사용자 로그인 처리"라는 모듈이 사용자 입력 검증, 데이터베이스 조회, 세션 생성, 로그 기록이라는 네 가지 작업을 순차적으로 수행한다면, 이 모듈은 절차적 응집도를 가진다. 각 작업은 서로 다른 기능을 수행하지만, 로그인이라는 하나의 절차적 맥락 안에서 순서대로 실행되어야 하기 때문이다. 이러한 설계는 구조적 프로그래밍에서 흔히 발견될 수 있다.

절차적 응집도는 논리적 응집도나 시간적 응집도보다는 강한 연관성을 보이지만, 모듈 내 요소들이 데이터를 공유하여 함께 작동하는 통신적 응집도나, 한 요소의 출력이 다른 요소의 입력이 되는 순차적 응집도보다는 약한 결합을 나타낸다. 따라서 모듈화와 재사용성 측면에서는 기능적 응집도에 비해 다소 불리할 수 있다.

이러한 유형의 모듈은 특정 절차나 시나리오에 밀접하게 연결되어 있어, 해당 절차의 변경이 모듈 전체에 영향을 미칠 가능성이 있다. 따라서 소프트웨어 유지보수를 고려할 때, 모듈의 응집도 수준을 평가하고 가능하면 더 높은 수준의 응집도를 갖도록 리팩토링하는 것이 바람직하다.

교환적 응집도는 통신적 응집도라고도 불리며, 모듈 내의 여러 구성 요소들이 동일한 입력 데이터나 출력 데이터를 공유하여 수행되는 경우를 가리킨다. 이 모듈들은 서로 다른 기능을 수행하지만, 동일한 데이터 구조나 데이터 집합을 조작한다는 공통점을 가진다. 예를 들어, 특정 고객 데이터베이스 레코드를 읽어서 화면에 표시하고, 동시에 그 데이터를 파일로 기록하는 모듈은 교환적 응집도를 가진다. 이 모듈은 데이터 표시와 데이터 기록이라는 두 가지 서로 다른 작업을 수행하지만, 둘 다 동일한 고객 데이터를 입력으로 사용한다.

교환적 응집도는 순차적 응집도나 기능적 응집도보다는 낮지만, 절차적 응집도나 시간적 응집도보다는 높은 수준으로 평가된다. 이는 모듈 내 작업들이 데이터 흐름에 의해 연결되어 있기 때문이다. 이러한 설계는 데이터 중심의 프로그래밍 접근 방식과 잘 맞으며, 특정 데이터 집합에 대한 다양한 연산을 하나의 모듈로 그룹화할 때 자주 나타난다. 그러나 모듈이 단일한 명확한 책임을 가지지 않고 여러 작업을 수행하게 되어, 모듈화의 원칙에 완벽히 부합하지는 않는다.

교환적 응집도를 가진 모듈은 데이터의 일관성을 유지하는 데 유리할 수 있다. 동일한 데이터를 처리하는 여러 프로시저가 한곳에 모여 있으면, 데이터 형식이 변경되었을 때 해당 모듈만 수정하면 되므로 유지보수가 비교적 용이해진다. 하지만 모듈이 지나치게 복잡해지거나, 공유 데이터에 대한 의존도가 과도하게 높아져 다른 모듈과의 결합도가 증가할 위험도 존재한다. 따라서 설계 시 이러한 장단점을 고려하여 모듈의 경계를 적절히 설정해야 한다.

순차적 응집도는 모듈 내부의 구성 요소들이 순차적으로 실행되어 한 구성 요소의 출력이 다음 구성 요소의 입력으로 사용되는 경우를 말한다. 이는 절차적 응집도보다 강한 응집도로, 구성 요소들이 동일한 데이터 흐름을 따라 순차적으로 처리되기 때문에 모듈 내부의 연관성이 높다. 예를 들어, 특정 데이터를 읽어서 검증하고, 그 결과를 변환하여 출력하는 일련의 작업을 수행하는 모듈이 여기에 해당한다.

순차적 응집도를 가진 모듈은 단일한 작업 흐름을 명확하게 나타내므로 모듈화 설계의 목표에 부합한다. 각 구성 요소는 독립적인 작업을 수행하지만, 이전 단계의 결과에 의존적이기 때문에 모듈을 분리하기 어려운 경우가 많다. 이러한 특징은 재사용성 측면에서는 제한적일 수 있으나, 모듈 내부의 논리적 결합은 매우 강하다.

소프트웨어 공학에서 순차적 응집도는 바람직한 설계 수준으로 평가받는다. 이는 기능적 응집도 다음으로 높은 응집도 유형에 속하며, 유지보수성을 높이는 데 기여한다. 모듈의 경계가 명확하고 데이터 흐름이 직관적이기 때문에 코드를 이해하고 수정하는 것이 상대적으로 용이하다.

이러한 설계는 특히 구조적 설계 방법론에서 강조되며, 복잡한 시스템을 보다 관리하기 쉬운 단위로 분해하는 데 유용하게 적용된다. 순차적 응집도를 달성함으로써 시스템의 전체적인 결합도를 낮추고 모듈 간의 의존성을 최소화할 수 있다.

기능적 응집도는 소프트웨어 공학에서 정의된 응집도의 여러 유형 중 가장 높은 수준의 응집도를 가리킨다. 이는 모듈이 단 하나의 명확한 작업이나 기능을 수행하도록 설계되었음을 의미한다. 즉, 모듈 내의 모든 구성 요소들이 단일한 목표를 달성하기 위해 협력하며, 그 목표 외에는 다른 부수적인 작업을 포함하지 않는다. 이러한 모듈은 입력을 받아 특정한 출력을 생성하는 하나의 완전한 기능 단위로 동작한다.

기능적 응집도를 가진 모듈의 예로는 두 수를 더하는 함수, 특정 형식으로 데이터를 정렬하는 루틴, 또는 파일을 암호화하는 알고리즘 등을 들 수 있다. 이러한 모듈들은 이름만으로도 그 기능을 명확히 이해할 수 있으며, 내부 로직이 단일 업무에 집중되어 있다. 이는 구조적 설계와 객체 지향 설계 모두에서 이상적인 모듈 설계 원칙으로 간주된다.

높은 수준의 기능적 응집도를 달성하는 것은 소프트웨어 품질을 크게 향상시킨다. 이러한 모듈은 이해하기 쉽고, 디버깅이 용이하며, 유지보수와 재사용성이 매우 높다. 모듈이 오직 하나의 일만 하기 때문에 변경이 필요할 때 해당 모듈만 수정하면 되며, 다른 모듈에 미치는 영향이 최소화된다. 따라서 소프트웨어 설계 시 개발자는 가능한 한 기능적 응집도에 가까운 모듈을 설계하기 위해 노력해야 한다.

기능적 응집도는 래리 콘스탄틴과 에드워드 요던이 1974년에 제안한 응집도 분류 체계의 정점에 위치한다. 이 체계는 우연적, 논리적, 시간적, 절차적, 교환적(통신적), 순차적 응집도를 거쳐 기능적 응집도에 이르는 계층 구조를 형성하며, 상위로 갈수록 바람직한 설계로 평가받는다.

결합도는 소프트웨어 설계에서 한 모듈이 다른 모듈에 얼마나 의존적인지를 나타내는 척도이다. 즉, 모듈 간의 상호 연결성 또는 의존성의 강도를 의미한다. 이 개념은 응집도와 함께 소프트웨어 공학의 중요한 설계 원칙으로, 높은 응집도와 낮은 결합도를 가진 모듈을 설계하는 것이 바람직하다. 결합도가 낮을수록 모듈은 독립적이며, 시스템의 한 부분을 변경했을 때 다른 부분에 미치는 영향이 적어 유지보수와 재사용이 용이해진다.

결합도는 그 강도에 따라 여러 유형으로 분류된다. 가장 바람직하지 않은 형태는 내용 결합도로, 한 모듈이 다른 모듈의 내부 데이터나 로직을 직접 참조하거나 수정하는 경우이다. 그 다음으로 공통 결합도는 여러 모듈이 전역 데이터를 공유하는 형태이며, 외부 결합도는 모듈들이 외부 장치나 포맷 등에 공동으로 의존하는 경우이다. 제어 결합도는 한 모듈이 다른 모듈의 실행 흐름을 제어하는 정보를 매개변수로 전달할 때 발생한다.

보다 바람직한 형태로는 스탬프 결합도와 자료 결합도가 있다. 스탬프 결합도는 모듈 간에 필요한 데이터 이상의 복합 자료 구조 전체가 전달될 때 나타난다. 가장 이상적인 형태는 자료 결합도로, 모듈들이 매개변수를 통해 필요한 데이터만을 주고받으며, 다른 모듈의 내부 작동에 대해 아무런 가정을 하지 않는 상태를 말한다. 객체 지향 설계의 캡슐화와 정보 은닉 원칙은 이러한 낮은 결합도를 달성하는 데 핵심적인 역할을 한다.

결합도를 낮추기 위해서는 인터페이스를 명확히 정의하고, 모듈 간의 데이터 교환은 필요한 최소한의 정보로 제한해야 한다. 또한 의존성 주입과 같은 디자인 패턴을 활용하거나, 이벤트 기반의 비동기 통신 방식을 사용하여 모듈 간의 직접적인 연결을 줄이는 방법이 있다. 낮은 결합도는 시스템의 복잡도를 낮추고, 단위 테스트를 쉽게 하며, 궁극적으로 소프트웨어의 품질과 수명을 높이는 데 기여한다.

모듈화는 소프트웨어 설계의 핵심 원리로, 복잡한 시스템을 기능적 또는 논리적으로 독립된 작은 단위인 모듈로 분해하는 과정을 의미한다. 이는 시스템의 복잡성을 관리하고, 각 부분의 개발, 테스트, 유지보수를 용이하게 만드는 데 목적이 있다. 모듈화의 성공 여부는 각 모듈의 독립성, 즉 높은 응집도와 낮은 결합도에 크게 좌우된다.

모듈화를 통해 소프트웨어의 재사용성과 유지보수성이 크게 향상된다. 잘 정의된 인터페이스를 가진 독립적인 모듈은 새로운 시스템이나 다른 부분에서 쉽게 재사용될 수 있으며, 한 모듈의 변경이 다른 모듈에 미치는 영향을 최소화할 수 있다. 이는 소프트웨어 공학에서 장기적인 개발 비용을 절감하고 시스템의 품질을 높이는 데 필수적이다.

구조적 설계와 객체 지향 설계 모두 모듈화를 기본 원칙으로 삼고 있다. 구조적 설계는 프로시저나 함수를 중심으로 모듈을 구성하는 반면, 객체 지향 설계는 데이터와 이를 처리하는 메서드를 하나의 캡슐화된 단위인 객체로 모듈화한다. 두 방법론 모두 모듈 간의 명확한 책임 분리와 인터페이스 설계를 강조한다.

객체 지향 설계는 응집도를 높은 수준으로 유지하는 것을 핵심 원칙 중 하나로 삼는다. 이 설계 패러다임은 데이터와 그 데이터를 처리하는 메서드를 하나의 단위인 객체로 묶어, 자연스럽게 높은 기능적 응집도를 달성하도록 유도한다. 각 객체는 명확한 책임을 가지며, 관련된 작업만을 수행함으로써 모듈 내부의 요소들이 단일한 목적을 위해 강하게 결속되게 한다.

객체 지향의 주요 개념인 캡슐화는 높은 응집도를 실현하는 데 직접적으로 기여한다. 캡슐화는 객체의 내부 데이터와 구현 세부 사항을 외부로부터 숨기고, 공개된 인터페이스를 통해서만 상호작용하도록 한다. 이는 객체가 자신의 상태를 관리하는 모든 로직을 내부에 응집시켜, 변경이 필요할 때 해당 객체 내부만 수정하면 되도록 만들어 유지보수성을 크게 향상시킨다.

또한, 다형성과 상속 같은 객체 지향의 다른 원리들도 응집도 높은 설계를 지원한다. 다형성을 통해 인터페이스는 일관되게 유지하면서 구체적인 구현은 각 클래스에 응집시킬 수 있으며, 상속을 통한 계층 구조는 공통된 기능을 부모 클래스에 응집시켜 코드 중복을 줄인다. 결과적으로, 높은 응집도와 낮은 결합도를 추구하는 객체 지향 설계는 보다 이해하기 쉽고, 확장 가능하며, 재사용성이 높은 소프트웨어 시스템을 구축하는 토대가 된다.