개요
오늘은 소프트웨어의 모듈(Module)에 대해서 알아보고, 모듈을 평가하는 기준, 그리고 소프트웨어 아키텍처 뷰와 프레임워크에 대해서 알아보도록 하겠습니다.
만일 여러분이 개발자가 되어 프로그램을 하나 만들어야 하는데,
그 프로그램을 오로지 하나의 파일로 작성하도록 요구 받았다면 어떨까요?
요구사항 명세서에 C언어로 개발해야 하며, 프로그램의 모든 코드는 메인 함수를 벗어날 수 없고
모든 변수와 기능은 메인 함수의 스코프 안에서 모두 이루어져야 한다면요?
자바(Java)를 예로 들자면, 하나의 .java 파일에서 벗어날 수 없고
궁극적으로는 하나의 클래스 파일 안에서 모든 기능을 구현해야 한다면 어떨까요?
잠시 상상만 하더라도 정말 쉽지 않은 프로그래밍이 될 것 같습니다.
설령 실제로 그러한 프로그램을 만들었다고 하더라도
만일 다른 개발자가 해당 프로그램을 코드를 전달 받아 운영 중에 버그나 이슈가 발생했을 경우 대처해야 한다면요?
아마 해당 업무를 담당한 익명의 개발자는 무척 화가 나서 파업을 선언해버릴지도 모르겠습니다.
모듈(Module)이란?
프로그램을 구성하는 구성 요소로, 관련된 데이터와 함수를 하나로 묶은 단위
모듈(Module)은 앞선 개요에서 설명드렸듯이 하나의 c파일이 될 수도 있고, 여러 개의 클래스(.class) 파일이 될 수도 있습니다.
혹은, 다양한 언어로 개발된 모듈이 합쳐져 하나의 소프트웨어를 구성할 수도 있습니다.
실제로 다양한 프로그래밍 언어로 만들어진 프로그램이 합쳐져 하나의 거대한 소프트웨어를 구성하는 일은 생각보다 흔합니다.
그렇기에 고객에게 좋은 소프트웨어를 제공하기 위해서는
프로그램의 단위(Unit)가 되는 모듈(Module)부터 잘 만드는 것이 중요합니다.
마치, 좋은 재료로 쌓아 올린 집이 견고하고 오래도록 그 자리를 지켜줄 수 있는 것처럼요.
모듈이 되기 위한 주요 특징
또한, 이러한 모듈은 아래의 세 가지 주요한 특징을 가집니다.
⓵ 다른 것들과 구별될 수 있는 독립적인 기능을 가진 단위(Unit)이다.
⓶ 독립적인 컴파일이 가능해야 하고, 유일한 이름을 가져야 한다.
⓷ 다른 모듈에서의 접근이 가능해야 한다.
소프트웨어 모듈의 평가
소프트웨어는 다양한 단위 모듈의 묶음으로 구성됩니다.
따라서, 이러한 모듈을 구성할 때에는 다음의 네 가지 원리를 따라 프로그래밍하는 것이 좋습니다.
단위 모듈의 핵심 원리
| 핵심 원리 | 설명 |
| 정보 은닉(Information Hiding) | 어렵거나 변경 가능성이 있는 모듈을 다른 모듈로부터 은폐 |
| 분할과 정복(Divide & Conquer) | 복잡한 문제를 분해, 모듈 단위로 문제 해결 |
| 데이터 추상화 (Data Abstraction) | 각 모듈 자료구조를 액세스하고 수정하는 함수 내에 자료구조의 표현 내역을 은폐 |
| 모듈 독립성 (Module Independency) | 낮은 결합도와 높은 응집도를 가지도록 개발 |
소프트웨어 모듈의 평가 기준
이러한 핵심 원리에 따라 개발된 모듈은 크게 ‘결합도(Colupling)’ 측면과 ‘응집도(Cohesion)’ 측면에서 평가될 수 있습니다.
1) 결합도(Coupling)
- 모듈 내부가 아닌 외부의 모듈과의 연관도 또는 모듈 간의 상호의존성
- 소프트웨어 구조에서 모듈 간의 관련성을 측정하는 척도
| 결합도 | 설명 |
| 내용 결합도(Content Coupling) | 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우 |
| 공통 결합도 (Common Coupling) | 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호작용하는 경우 |
| 외부 결합도 (External Coupling) | 두 개의 모듈이 외부에서 도입된 데이터 포맷, 통신 프로토콜, 또는 디바이스 인터페이스를 공유할 경우 |
| 제어 결합도 (Control Coupling) | 단순 처리할 대상인 값만 전달되는 게 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우의 결합도 |
| 스탬프 결합도 (Stamp Coupling) | 모듈 간의 인터페이스로 배열이나 객체, 구조 등이 전달되는 경우 |
| 자료 결합도 (Data Coupling) | 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호작용이 일어나는 경우의 결합도 |
2) 응집도(Cohesion)
- 모듈에 포함된 내부 요소들이 하나의 책임/목적을 위해 연결되어 있는 연관된 정도.
- 하위 모듈의 묶음으로 구성된 모듈 군의 구성 요소들이 얼마나 해당 모듈군을 위해 잘 설계되었는지 평가 → 기능적인 응집의 척도
| 응집도 | 설명 |
| 우연적 응집도 (Coincidental Cohesion) | - 서로 간에 어떠한 의미 있는 연관 관계도 없는 기능 요소로 구성될 경우의 응집도 |
| 논리적 응집도 (Logical Cohesion) | - 서로 다른 상위 모듈에 의해 호출되어 처리상의 연관성이 없는 서로 다른 기능을 수행할 경우의 응집도 - 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우의 응집도 |
| 시간적 응집도 (Temporal Cohesion) | - 연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우의 응집도 |
| 절차적 응집도 (Procedural Cohesion) | - 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우의 응집도 |
| 통신적 응집도 (Communication Cohesion) | - 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우의 응집도 |
| 순차적 응집도 (Sequential Cohesion) | - 모듈 내에서 한 활동으로부터 나온 출력 값을 다른 활동이 사용할 경우의 응집도 |
| 기능적 응집도 (Functional Cohesion) | - 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우의 응집도 |
소프트웨어 모듈의 구조도
- 소프트웨어를 구성하는 모듈은 계층적인 구조도를 통해 도식화할 수 있습니다.
- 그리고 이러한 구조도를 그리고 설명하는데 사용되는 대표적인 용어 몇 가지를 소개하겠습니다.
소프트웨어 모듈 구조도에서 사용되는 용어
| 용어 | 설명 |
| Fan-in | 주어진 한 모듈을 제어하는 상위 모듈의 수 |
| Fan-out | 주어진 한 모듈이 제어하는 하위 모듈의 수 |
| Depth | 최상위 모듈에서 주어진 모듈까지의 깊이 |
| Width | 같은 등급(Level)의 모듈 수 |
| Super Ordinate | 다른 모듈을 제어하는 모듈 |
| Sub Ordinate | 다른 모듈에 의해 제어되는 모듈 |
만약 어떤 소프트웨어를 설계한 후, 이 소프트웨어를 구성하는 모듈에 대해서 구조도를 아래와 같이 그렸다고 가정해보겠습니다.
위의 프로그램 구조도에서 모듈 F를 분석 해보면 아래와 같이 평가할 수 있습니다.
Fan-in : 3 | Fain-out : 2
Fan-in이 높은 경우
- 재사용 측면에서 잘 된 설계로 볼 수 있습니다.
- 시스템 구성 요소 중 일부가 동작하지 않으면 시스템이 중단되는 단일 장애 발생 가능성이 있습니다.
- 단일 장애 발생을 방지하기 위해 중점 관리가 필요합니다.
Fan-Out이 높은 경우
- 불필요한 타 모듈의 호출 여부를 확인합니다.
- Fan-out을 단순하게 설계할 수 있는지 검토합니다.
따라서, 이렇게 소프트웨어 모듈에 대해 구조도를 그린 후 모듈에 대한 복잡도를 최적화할 수 있습니다.
그리고 모듈의 복잡도를 최적화 하기 위해서는 Fan-in의 수는 높이고 Fan-out의 수는 낮추는 방향으로 설계해야 합니다.
모듈(Module), 라이브러리(Library), 컴포넌트(Component)의 차이는 무엇인가요?
지금까지는 모듈에 대해서 열심히 알아보았습니다.
하지만 여러 개의 함수와 프로퍼티, 클래스로 구성된 모듈은 그 규모에 따라 또 다른 이름으로 불리기도 합니다.
이들 용어 간에 정확히 구분을 하는 기준은 코드가 모인 ‘규모’에 따라 구분 지을 수 있는데, 정량적으로 정해진 기준은 없습니다.
하지만, 통상적으로 부품처럼 쓰일 수 있는 프로그램 단위는 모듈(Module)이라고 불립니다.
그리고 이러한 모듈이 모여서 또 다른 프로그램 개발에 사용될 수 있을 정도로 거대해지면 라이브러리(Library)라고 부릅니다.
그리고 라이브러리의 구성하는 모듈의 하위 집합을 기능별로 구분하여 사용할 수 있게 한 것을 컴포넌트(Compoent)라고 부릅니다.
라이브러리와 컴포넌트를 구분짓는 가장 큰 차이점은 ‘독립성’이며,
라이브러리는 어떤 기능을 사용하기 위해 전체 모듈군을 사용해야하지만,
컴포넌트는 필요에 따라 때로는 부품처럼 조립하여 사용할 수 있다는 점에서 구분됩니다.
소프트웨어 아키텍처 4+1 뷰
고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
소프트웨어 아키텍처의 4+1 뷰의 구성요소
| 뷰(VIew) | 설명 |
| 유스케이스 뷰 (Usecase View) | - 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰 |
| 논리 뷰 (Logical View) | - 사용자, 설계자, 개발자, 테스트 관점 - 시스템의 기능적인 요구사항이 어떻게 제공되는 지 설명해주는 뷰 |
| 프로세스 뷰 (Process View) | - 설계자, 개발자 관점의 뷰(View) - 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰 |
| 구현 뷰 (Implementation View) | - 개발자, 시스템 통합자 관점 - 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여 주는 뷰 |
| 배포 뷰 (Deployment View) | - 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의 - 컴포넌트가 물리적인 아키텍처에 어떻게 배치 되는 가를 매핑해서 보여 주는 뷰 |
소프트웨어 아키텍처 프레임워크
소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준(IEEE-1471)
소프트웨어 아키텍처 프레임워크 구성요소
| 구성 요소 | 설명 |
| 아키텍처 명세서 (Architectural Description) | - 아키텍처를 기록하기 위한 산출물 - 이해관계자들의 시스템에 대한 관심을 관점에 맞추어 작성한 뷰로 표현 - 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등이 있음 |
| 이해관계자 (Stakeholder) | - 시스템 개발에 관련된 모든 사람과 조직 |
| 관심사 (Concerns) | - 고객, 최종 사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등을 포함 - 시스템에 대해 이해관계자들의 서로 다른 의견과 목표 ⓵ 사용자 입장 : 기본적인 기능, 신뢰성, 보안, 사용성 등의 품질 ⓶ 유지 보수자 입장 : 유지보수의 용이성 ⓷ 개발자 입장 : 적은 비용과 인력으로 개발 |
| 관점 (Viewpoint) | - 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식 - 이해관계자들이 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대해 보고 싶은 관점 |
| 뷰 (View) | - 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현 - 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성 |
| 근거 (Rationale) | - 아키텍처 결정 근거 - 회의결과, 보고 결과 등 |
| 목표 (Mission) | - 환경 안에서 한 명 이상의 이해관계자들이 의도하는 시스템의 목적, 사용, 운영 방법 |
| 환경 (Environment) | - 시스템에 영향을 주는 요인으로 개발, 운영 등의 외부 요인 등으로 시스템에 영향을 주는 요인 |
| 시스템 (System) | - 각 애플리케이션, 서브 시스템, 시스템의 집합, 제품군 등의 구현체 |
참고자료
https://tcpschool.com/c/c_complie_module
코딩교육 티씨피스쿨
4차산업혁명, 코딩교육, 소프트웨어교육, 코딩기초, SW코딩, 기초코딩부터 자바 파이썬 등
tcpschool.com
https://haileyjpark.tistory.com/4
[소프트웨어 공학] 모듈화와 응집도/결합도
모듈화란 모듈이란 프로그램을 구성하는 시스템을 기능 단위로 독립적인 부분으로 분리한 것이다. 단순히 규모가 큰 것을 작게 나눈 조각이 아니라, 하나 이상의 논리적인 기능을 수행하기 위
haileyjpark.tistory.com
'CS BASIC > 소프트웨어 설계와 방법론' 카테고리의 다른 글
| [CS BASIC] COCOMO, 자료흐름도(DFD), 자료 사전(DD), 코드 설계(Code Design) (1) | 2023.12.25 |
|---|---|
| [CS BASIC] 모델(Model)과 UML, 다이어그램(Diagram) (1) | 2023.12.24 |
| [CS BASIC] 소프트웨어의 디자인 패턴 (1) | 2023.12.23 |
| [CS BASIC] 소프트웨어 비즈니스 계획과 연속성 관리 (0) | 2023.12.20 |
| [CS BASIC] 프로그램과 프로그래밍 그리고 프로그램 패러다임 (1) | 2023.12.05 |
