결합도(Coupling)와 응집도(Cohesion)

결합도(Coupling)와 응집도(Cohesion)

소프트웨어 개발 수명 주기의 설계 단계의 목적은 SRS(소프트웨어 요구 사항 사양) 문서에 제시된 문제에 대한 해결책을 제시하는 것이다. 설계 단계의 결과는 소프트웨어 설계 문서(SDD)다.

결합도와 응집도는 소프트웨어 시스템 설계의 품질을 측정하는 데 사용되는 소프트웨어 공학의 두 가지 핵심 개념이다.

 

결합도는 소프트웨어 모듈 간의 상호 의존성의 정도를 나타낸다. 높은 결합도는 모듈들이 긴밀하게 연결되어 있으며, 하나의 모듈을 변경하면 다른 모듈에도 영향을 미칠 수 있다. 낮은 결합도는 모듈들이 독립적이며, 하나의 모듈을 변경해도 다른 모듈에는 영향을 미치지 않는다.

 

응집도는 모듈 내 요소들이 하나의 명확한 목적을 달성하기 위해 함께 작동하는 정도를 나타낸다. 높은 응집도는 요소들이 서로 관련되어 있고, 하나의 목적에 집중되어 있는 것을 의미하며, 낮은 응집도는 요소들이 서로 느슨하게 연관되어 있고, 여러 가지 목적을 수행하는 것을 의미한다.

 

결합도와 응집도는 모두 소프트웨어 시스템의 유지보수성, 확장성, 신뢰성을 결정하는 중요한 요소다. 높은 결합도와 낮은 응집도는 시스템을 변경하고 테스트하기 어렵게 만들 수 있으며, 낮은 결합도와 높은 응집도는 시스템을 유지하고 개선하기 쉽게 한다.

 

기본적으로 설계는 두 부분으로 이루어진 반복적인 과정이다. 첫 번째 부분은 개념적 설계로, 시스템이 무엇을 할 것인지 고객에게 알려준다. 두 번째 부분은 기술적 설계로, 시스템 개발팀에게 고객의 문제를 해결하는 데 필요한 실제 하드웨어 및 소프트웨어를 이해할 수 있게 한다.

반응형

시스템의 개념적 설계

시스템의 개념적 설계는 시스템이 무엇을 할 것인지를 이해하고 문제 해결 방법을 도출하는 단계다. 이 단계에서는 고객의 요구사항과 목적을 파악하고, 시스템이 제공해야 할 기능과 특징을 결정한다. 이를 위해 요구사항 분석, 사용자 인터뷰, 프로토타이핑 등의 기술과 방법을 사용한다. 결과물은 개념적 설계 문서로, 시스템의 전반적인 아키텍처와 기능, 인터페이스, 데이터 흐름 등이 정의된다. 이 문서는 고객과 개발자 간의 의사소통 도구로 사용되며, 기술적 설계의 기반을 제공한다.

 

다음과 같은 내용을 포함한다.

• 시스템의 개념 설계는 고객이 쉽게 이해할 수 있는 언어로 작성되어야 한다. 
  이는 기술 전문 용어를 피하고 평이한 언어를 사용하여 시스템의 특성, 기능 및 제한 사항을 설명하는 것을 의미합니다. 목표는 고객이 시스템과 목적을 완전히 이해하고 개발 팀에 피드백을 제공할 수 있도록 하는 것입니다.
• 시스템 특성에 대해 자세히 포함되어야 한다. 
  시스템의 의도된 용도와 사용자가 목표를 달성하는 데 어떻게 도움이 되는지 설명해야 한다. 시스템의 특성은 기술 전문 용어나 불필요한 복잡성을 피하면서 명확하고 간결한 방식으로 설명되어야 한다. 이 정보는 사용자가 시스템 작동 방식, 수행할 수 있는 작업 및 제한 사항을 이해하는 데 도움이 될 수 있다. 또한 개발자가 의도한 사용자의 요구 사항을 충족하는 시스템을 설계하고 구축하는 데 도움이 될 수 있다.
• 시스템의 기능이 포함되어야 한다.
  시스템의 기능은 시스템이 수행할 수 있는 작업과 작업을 수행하는 방법을 나타낸다. 개념 설계 문서는 시스템이 수행할 기능과 해당 기능이 수행되는 방법이 표현되어야 한다. 여기에는 시스템의 입력 및 출력에 대한 설명, 데이터 처리 방법, 사용자 또는 다른 시스템과 상호 작용하는 방법이 포함된다. 기능은 고객과 개발 팀 모두에게 명확하고 이해하기 쉬운 방식으로 표현되어야 한다. 이 정보는 의도한 사용자의 요구 사항을 충족하도록 시스템을 설계하고 구축하는 데 도움이 될 수 있다.
• 시스템의 개념 설계는 구현과 독립적이어야 한다. 
  즉, 시스템 구축 또는 운영 방법에 대한 구체적인 세부 사항보다는 시스템의 목적, 기능 및 특성을 설명하는 데 중점을 두어야 한다. 목표는 특정 기술이나 구현 접근 방식에 얽매이지 않고 시스템의 요구 사항과 기능에 대한 명확하고 완전한 이해를 제공하는 것이다. 이를 통해 개발자는 변화하는 요구 사항이나 기술적 제약에 적응할 수 있는 유연성을 유지하면서 개념 설계를 시스템 구축을 위한 지침으로 사용할 수 있다.
• 시스템의 개념 설계는 요구 사항 문서와 연결되어야 한다. 
  요구 사항 문서는 시스템 사용자 또는 이해 관계자의 특정 요구 사항과 기대치가 설명되어 있다. 개념 설계는 시스템이 요구 사항을 충족하고 목표를 달성하게 하기 위해 요구 사항을 기반으로 해야 한다. 개념 설계를 요구 사항 문서와 연결함으로써 개발 팀은 시스템이 의도한 사용자의 요구 사항을 충족하도록 설계 및 구축되는 동시에 변화하는 요구 사항이나 제약 조건에 적응할 수 있을 만큼 충분히 유연하게 유지되도록 할 수 있다. 이를 통해 최종 시스템이 모든 이해 관계자의 요구를 충족하고 의도한 목적을 성공적으로 달성할 수 있다.

시스템의 기술적 설계

시스템의 기술 설계는 설계 프로세스의 두 번째 부분이며 시스템의 구현 세부 사항에 중점을 둔다. 개념 설계는 시스템이 수행할 작업을 표현하는 반면 기술 설계는 구축 방법과 작동 방식을 표현한다. 여기에는 사용될 하드웨어 및 소프트웨어 구성 요소, 시스템 아키텍처, 데이터 저장 및 처리, 사용자 인터페이스 및 기타 기술 세부 사항에 대한 결정이 포함된다. 기술 설계에서는 구현에 영향을 미칠 수 있는 제약이나 제한 사항뿐 아니라 시스템 요구 사항도 고려해야 한다. 또한 시스템이 개발되고 테스트될 때 수정이나 변경이 가능하도록 충분히 유연해야 한다. 기술 설계의 목표는 시스템 구축을 위한 명확한 로드맵을 제공하여 시스템이 기능적이고 안정적이며 사용자의 요구를 충족하는지 확인하는 것이다.

 

다음과 같은 내용을 포함한다.

• 하드웨어 구성 요소 및 설계
  하드웨어 구성 요소는 시스템이 작동하는 데 필요한 컴퓨터 하드웨어, 주변 장치 및 기타 물리적 구성 요소를 포함하여 시스템의 물리적 구성 요소 및 아키텍처를 말한다. 
  여기에는 시스템 구축에 사용될 컴퓨터, 서버, 저장 장치 및 기타 장비의 유형 및 사양등이 포함된다. 
  하드웨어 설계는 처리할 데이터 양, 사용자 수, 필요한 성능 수준을 포함하여 시스템 요구 사항을 고려해야 하고 전력 소비, 냉각 요구 사항 및 물리적 공간 제한과 같은 요소도 포함해야 한다. 
  하드웨어 설계는 시스템 작동의 기반을 제공하고 안정성, 확장성 및 성능에 영향을 줄 수 있으므로 기술 설계 프로세스의 중요한 구성 요소다.
• 소프트웨어 구성 요소의 기능 및 계층 구조
  시스템의 목표를 달성하기 위해 소프트웨어 모듈 및 구성 요소를 설명한다. 
  여기에는 소프트웨어를 더 작고 관리 가능한 구성 요소 또는 모듈로 나누는 방법과 이러한 구성 요소가 원하는 기능을 달성하기 위해 서로 상호 작용하는 방법이 포함된다. 
  소프트웨어 계층 구조는 시스템 요구 사항, 시스템의 복잡성 및 서로 다른 구성 요소 간의 상호 의존성 수준을 고려해야 한다. 계층 구조는 또한 각 구성 요소가 잘 정의된 목적을 갖고 시스템의 목표를 달성하기 위해 원활하게 함께 작동하는지 확인해야 한다. 
  소프트웨어의 기능은 수행할 수 있는 특정 작업 또는 프로세스와 시스템 요구 사항을 충족하는 데 필요한 모든 기능을 나타낸다. 소프트웨어는 효율적이고 안정적이며 확장 가능하도록 설계되어야 하며 필요에 따라 변경 또는 수정을 수용할 수 있을 만큼 충분히 유연해야 한다. 
• 소프트웨어 아키텍처
  소프트웨어 아키텍처는 전체 구조, 구성 요소 및 이들 간의 상호 작용을 포함하여 소프트웨어 시스템의 상위 수준 설계를 나타낸다. 소프트웨어 개발 및 개선을 안내하는 소프트웨어 시스템의 청사진이다. 
  소프트웨어 아키텍처는 확장성, 유지 보수성, 안정성 및 보안과 같은 중요한 문제를 해결한다.
• 네트워크 아키텍처
  네트워크 아키텍처는 장치를 연결하고 서로 통신할 수 있도록 하는 하드웨어 및 소프트웨어 구성 요소, 프로토콜 및 서비스를 포함하는 컴퓨터 네트워크의 구조를 말한다. 
  네트워크 아키텍처는 네트워크의 전체 구조, 데이터 전송 및 수신 방법, 사용자에게 네트워크 서비스를 제공하는 방법을 결정하므로 네트워크 설계의 중요한 구성 요소다.
• 데이터 구조 및 데이터 흐름
  데이터 구조와 데이터 흐름은 소프트웨어 시스템 설계의 중요한 구성 요소다. 데이터가 시스템 내에서 구성, 저장 및 처리되는 방식을 결정하고 시스템의 성능과 안정성에 상당한 영향을 미칠 수 있다.
• 시스템의 입/출력(I/O) 구성 요소
  시스템이 외부 장치 및 사용자와 상호 작용하는 방식을 나타낸다. 여기에는 모니터, 프린터 및 스피커와 같은 장치로의 출력은 물론 사용자의 입력을 처리하는 하드웨어 및 소프트웨어 구성 요소가 포함된다.
• 인터페이스
  인터페이스는 서로 다른 두 소프트웨어 구성 요소가 서로 상호 작용하는 방식을 정의하는 일련의 메서드 또는 기능을 나타낸다. 인터페이스는 시스템 또는 모듈의 입력 및 출력을 지정하고 서로 다른 구성 요소가 통신하고 데이터를 교환할 수 있는 수단을 제공한다.

모듈화

모듈화는 소프트웨어 시스템을 더 작고 독립적인 모듈 또는 구성 요소로 나누는 소프트웨어 설계 기술이다. 각 모듈은 특정 기능 세트를 담당하며 시스템의 나머지 부분과 별도로 개발 및 테스트할 수 있다.

소프트웨어 공학에는 모듈화의 많은 정점이 있다.

이들 중 일부는 다음과 같다:

• 시스템을 이해하기 쉽게 한다.
• 시스템 유지보수가 용이하다.
• 모듈을 매번 다시 작성할 필요 없이 소프트웨어 시스템에서 여러 번 재사용할 수 있다.

결합도(Coupling)

결합도는 소프트웨어 시스템에서 모듈 간의 상호 의존도를 측정한 것이다. 결합도가 높다는 것은 모듈이 밀접하게 연결되어 있고 한 모듈의 변경 사항이 다른 모듈에 상당한 영향을 미칠 수 있음을 의미한다. 반면 낮은 결합도는 모듈이 상대적으로 독립적이며 한 모듈의 변경 사항이 다른 모듈에 거의 영향을 미치지 않는다.

일반적으로 결합도가 낮은 소프트웨어 시스템은 더 모듈화 되고 유지 관리가 더 쉬우며 버그와 오류가 덜 발생하기 때문에 더 잘 설계된 것으로 간주된다.

결합도 유형

• 데이터 결합도(Data Coupling): 모듈 간의 종속성이 데이터 전달을 통해 통신하는 것에 기반할 경우, 해당 모듈은 데이터 결합이라고 한다. 데이터 결합에서는 구성 요소들이 서로 독립적이며 데이터를 통해 통신한다. 모듈 간 통신에는 중간 데이터가 포함되지 않는다. 예: 고객 청구 시스템.
• 스탬프 결합도(Stamp Coupling): 전체 데이터 구조가 한 모듈에서 다른 모듈로 전달된다. 따라서 이는 트램프 데이터를 포함한다. 이는 효율적인 요소 때문에 필요할 수 있다 - 이 선택은 게으른 프로그래머가 아닌 현명한 설계자에 의해 이루어졌다.
• 제어 결합도(Control Coupling):  모듈들이 서로 제어 정보를 주고받으면서 상호작용하는 경우를 말한다. 
  이러한 결합은 상황에 따라 좋을 수도, 나쁠 수도 있습니다. 
  모듈들이 서로 완전히 다른 동작을 나타내는 제어 정보를 사용하는 경우, 제어 결합은 문제가 될 수 있다. 
  이 경우, 혼란과 오류를 유발하며, 시스템을 이해하고 유지보수하기 어렵게 만들 수 있다.
  그러나, 제어 결합은 인자로 전달되는 제어 정보를 통해 기능을 분리하고 재사용할 수 있는 경우에는 유용합니다. 
  예를 들어, 비교 함수를 인자로 받는 정렬 함수는 정렬 알고리즘을 매번 다시 작성하지 않고도 다양한 데이터 유형을 정렬하는 데 사용할 수 있다. 이 경우, 제어 결합은 소프트웨어 시스템 설계에서 유연성과 효율성을 제공한다.
• 외부 결합도(External Coupling): 소프트웨어 모듈이 개발 중인 소프트웨어나 특정 유형의 하드웨어 외부에 있는 다른 모듈에 의존하는 경우를 말한다. 예를 들면 프로토콜, 외부 파일, 디바이스 포맷 등이 있다.
• 공통 결합도(Common Coupling): 모듈들이 전역 데이터 구조와 같은 데이터를 공유하는 경우를 말한다. 전역 데이터의 변경은 해당 데이터에 접근하는 모든 모듈을 추적하여 변경 사항의 영향도를 평가해야 하기 때문에 모듈 재사용에 어려움이 있으며, 데이터 접근 제어 및 유지보수 능력이 감소하는 단점이 있다.
• 콘텐츠 결합도(Content Coupling): 한 모듈이 다른 모듈의 데이터를 수정하거나, 제어 흐름이 한 모듈에서 다른 모듈로 전달되는 경우를 말한다. 이는 결합의 최악의 형태이므로 피해야 한다.

응집도(Cohesion)

응집도는 모듈의 요소들이 기능적으로 연관되어 있는 정도를 측정하는 것이다. 하나의 작업을 수행하는 모든 요소들이 구성 요소에 포함되어 있는 정도를 말한다. 기본적으로 응집도는 모듈을 함께 유지하는 내부적인 접착제 역할을 한다. 좋은 소프트웨어 설계는 높은 응집력을 가지고 있다.

응집도 유형

• 기능적 응집도(Functional Cohesion): 단일 계산을 위한 모든 필수 요소가 모듈에 포함되어 있다는 것을 말한다. 기능적 응집력은 작업과 기능을 수행한다. 
• 순차적 응집도(Sequential Cohesion): 어떤 모듈이 출력 데이터를 생성하고, 그 출력 데이터가 다른 모듈의 입력 데이터로 사용되는 경우를 말한다. 즉, 모듈 간에 데이터 흐름이 발생한다. 이러한 형태의 응집도는 함수형 프로그래밍 언어에서 자연스럽게 발생한다.
• 교환적 응집도(Communicational Cohesion): 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 모듈들이 모여 있을 경우의 응집도를 말한다. 예로 데이터베이스에서 레코드를 업데이트하고 프린터로 보내는 경우다.
• 절차적 응집도(Procedural Cohesion): 모듈이 다수의 관련 기능을 가질 때, 모듈 내 구성요소들이 그 기능을 순차적으로 수행할 경우를 말한다. 이 경우에는 작업이 여전히 약하게 연결되어 있으며 재사용하기 어렵다.
• 시간적 응집도(Temporal Cohesion): 모듈들이 시간적인 관련성을 갖는 경우를 말한다. 시간적 결합으로 연결된 모듈은 모든 작업이 동일한 시간 범위 내에서 실행되어야 한다. 이러한 응집력은 시스템의 모든 부분을 초기화하는 코드를 포함한다. 다양한 활동이 모두 단위 시간에 발생한다.
• 논리적 응집도(Logical Cohesion): 모듈들이 논리적으로 관련되어 있으나 기능적으로는 관련이 없는 경우를 말한다. 예를 들어, 구성 요소가 테이프, 디스크, 및 네트워크로부터 입력을 읽는 경우가 있다. 이런 기능에 대한 모든 코드는 동일한 모듈에 포함되어 있는 경우 이다. 작업은 관련되어 있지만 함수는 크게 다르다.
• 우연적 응집도(Coincidental Cohesion): 모듈들이 관련이 없는 경우를 말한다. 이러한 모듈들은 소스 코드 내에서 위치하는 것 이외에는 개념적인 관련성이 전혀 없다. 이러한 경우는 우연적이며 가장 나쁜 응집 형태다. 

장점과 단점

낮은 결함도의 장점

• 향상된 유지보수성: 낮은 결합도는 한 모듈의 변화가 다른 모듈에 미치는 영향을 줄여 전체 시스템에 영향을 미치지 않고 개별 구성 요소를 쉽게 수정하거나 교체할 수 있도록 한다.
• 향상된 모듈성: 결합도가 낮으면 모듈을 단독으로 개발하고 테스트할 수 있어 코드의 모듈성과 재사용성을 향상시킬 수 있다.
• 확장성 향상: 결합도가 낮으면 새 모듈을 추가하고 기존 모듈을 제거할 수 있어 필요에 따라 시스템을 쉽게 확장할 수 있다.

높은 응집도의 장점

• 가독성 및 이해성 향상: 높은 응집력은 하나의 잘 정의된 목적을 가진 명확하고 집중적인 모듈을 만들어 개발자들이 코드를 이해하고 변경하기 쉽게 만든다.
• 오류 격리 개선: 높은 응집도는 모듈의 한 부분을 변경해도 다른 부분에 영향을 미치는 가능성을 줄여 오류를 격리하고 수정하기 쉽게 만든다.
• 신뢰성 향상: 높은 응집력은 오류가 적고 더 일관적으로 작동하는 모듈을 만들어 시스템의 전반적인 신뢰성을 향상시킨다.

높은 결합도의 단점

• 복잡성 증가: 높은 결합은 모듈 간의 상호 의존성을 증가시켜 시스템을 더 복잡하고 이해하기 어렵게 만든다.
• 유연성 감소: 높은 결합은 시스템에 영향을 미치지 않게 개별 모듈을 수정하거나 교체하는 것을 더 어렵게 만든다.
• 모듈성 감소: 높은 결합은 모듈을 분리하여 개발하고 테스트하는 것을 더 어렵게 만들어 코드의 모듈화와 재사용성을 감소시킨다.

낮은 응집도의 단점

• 코드 중복 증가: 낮은 응집력은 함께 구성되어야 하는 모듈들을 별도 모듈로 분리하기 때문에 코드의 중복을 초래할 수 있다.
• 기능 저하: 낮은 응집력은 모듈이 명확한 목적을 가지지 않고 서로 관련 없는 요소들을 포함하게 되어 기능을 축소시키고 유지 보수를 어렵게 만들 수 있다.
• 모듈 이해 난해함: 응집력이 낮으면 개발자가 모듈의 목적과 동작을 이해하기 어려워져 오류가 발생하고 명확성이 떨어질 수 있다.