[정처기 필기] 「1」 | 애플리케이션 설계 - (3.3) 모듈, 공통 모듈

[정처기 필기] 「1」 | 애플리케이션 설계 - (3.3) 모듈, 공통 모듈

> 「1」 소프트웨어 설계

- 요구사항 확인, 화면 설계, > 애플리케이션 설계, 인터페이스 설계

「2」 소프트웨어 개발

「3」 데이터베이스 구축

「4」  프로그래밍 언어 활용

「5」  정보시스템 구축 관리

 

1 소프트웨어 아키텍처

2 아키텍처 패턴

3 객체지향(Object-Oriented)

4 객체지향 분석 및 설계

> 5 모듈

> 6 공통 모듈

7 코드

8 디자인 패턴

5. 모듈

모듈(Module)의 개요

 

모듈화를 통해 분리된 시스템의 각 기능들, == 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위

 

- 단독으로 컴파일 가능, 재사용

- 독립되는 기능을 가진 단위(UNIT), 하나의 기능만 수행하고 다른 모듈과 과도한 상호작용 피함

- 독립성이 높을수록 수정 시 영향 미치지 않고, 오류 처리도 쉬움

- 모듈의 결합도(Coupling)는 약하게, 응집도는(Cohesion)는 강하게, 모듈의 크기는 작게

- 유일한 이름을 가져야 함

 

결합도(Coupling)

 

상호 의존하는 정도, 두 모듈 간의 연관 관계

 

- 결합도가 약할수록 품질이 높음

- 결합도가 강하면 시스템 구현, 유지보수 어려움

 

← 결합도 약함					결합도 강함 →
자료 결합도	스탬프 결합도	제어 결합도	외부 결합도	공통 결합도	내용 결합도

 

자료 결합도(Data Coupling)

: 자료 요소로만 구성될 때

: 매개 변수나 인수로 데이터를 넘겨주고, 처리 결과를 다시 돌려주는 방식

: 내용을 알 필요가 없는 상태, 영향을 미치지 않는 가장 바람직한 결합도

 

스탬프(검인) 결합도(Stamp Coupling)

: 자료구조가 전달 될 때

: 동일한 자료구조를 조회하는 경우이며, 자료구조의 변화(포맷, 구조의 변화)는 모듈에 영향을 끼침

 

제어 결합도(Control Coupling)

: 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나, 제어요소를 전달

: 상세한 처리 절차를 알고 있어서 통제하려는데, 처리 기능이 분리되어 설계된 경우

 

외부 결합도(External Coupling)

: 데이터(변수)를 다른 모듈에서 참조할 때

: 데이터의 범위를 각 모듈에서 제한할 수 있음

 

공통(공유) 결합도(Common Coupling)

: 공통 데이터 영역을 여러 모듈이 사용할 때

: 조금만 변경해도 모든 모듈에 영향을 미침, 독립성 약함

 

내용 결합도(Content Coupling)

: 내부 자료를 직접 참조, 수정할 때

: 한 모듈에서 다른 모듈 내부로 제어가 이동하는 경우도 해당

 

응집도(Cohesion)

 

정보 은닉 개념을 확장, 모듈이 독립적인 기능으로 정의되어 있는 정도

 

- 응집도가 강할수록 품질이 높음

 

← 응집도 약함						응집도 강함 →
우연적 응집도	논리적 응집도	시간적 응집도	절차적 응집도	교환적 응집도	순차적 응집도	기능적 응집도

 

우연적 응집도(Coincidental Cohesion)

: 서로 관련 없는 요소를 하나의 모듈로

 

논리적 응집도(Logical Cohesion)

: 유사한 성격, 특정 형태로 분류되는 처리 요소를 하나의 모듈로

 

시간적 응집도(Temporal Cohesion)

: 특정 시간에 처리되는 기능을 모아 하나의 모듈로

 

절차적 응집도(Procedural Cohesion)

: 다수의 관련 기능을 가질 때, 구성 요소들이 순차적으로 수행하는 경우 하나의 모듈로

 

교환(통신)적 응집도(Communication Cohesion)

: 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 경우

 

순차적 응집도(Sequential Cohesion)

: 모듈 내 하나의 활동으로부터 나온 출력 데이터를 입력 데이터로 사용할 경우

 

기능적 응집도(Functional Cohesion)

: 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우

 

팬인(Fan-In) / 팬아웃(Fan-Out)

 

- 팬인 : 제어(호출)하는 모듈의 수

- 팬아웃 : 제어(호출)되는 모듈의 수

- 분석하여 시스템의 복잡도 알 수 있음

- 팬인이 높다는 것은 재사용 측면 설계가 잘 돼있지만, 단일 장애점이 발생할 수 있음

- 팬아웃이 높다는 것은 불필요하게 호출하는지 검토, 단순화할 수 있는지 검토

- 시스템 복잡도를 최적화하려면 팬인은 높게, 팬아웃은 낮게

 

↘	↓	↙		↓	↙
A			B
	↓

 

A > 팬인 : 3, 팬아웃 : 1

B > 팬인 : 2, 팬아웃 : 0

 

>N-S 차트(Nassi-Schneiderman Chart)<

 

논리의 기술에 중점을 둔 도형을 이용, == 박스 다이어그램, Chapin Chart

 

- 제어 논리 구조를 표현

- GOTO, 화살표 사용 안 함

- 조건이 복잡한 곳의 처리를 시각적으로 표현

- 선택과 반복 구조를 시각적으로 표현

- 이해하기 쉽고, 코드 변환 용이

- 읽기는 쉽지만 작성하기 어려움, 제어를 전이하는 것이 불가능

- 총체적인 구조 표현, 인터페이스를 나타내기 어려움

- 단일 입구, 단일 출구로 표현

6. 공통 모듈

공통 모듈의 개요

 

공통적으로 사용할 수 있는 모듈

 

- 같은 기능들이 공통 모듈로 구성

- 모듈의 재사용성 확보, 중복 개발 회피를 위해 공통부분을 식별하고 명세화

- 다른 개발자들도 명확히 이해할 수 있도록 명세 기법 준수

: 정확성(Correctness) - 해당 기능의 필요성을 정확히 작성

: 명확성(Clarity) - 중이적으로 해석되지 않도록 명확히 작성

: 완전성(Completeness) - 필요한 모든 것을 작성

: 일관성(Consistency) - 공통 기능들 간 상호 충돌이 발생하지 않도록 작성

: 추적성(Tranceability) - 기능에 대한 요구사항의 출처, 관련 시스템 등 관계를 파악할 수 있도록 작성

 

재사용(Reuse)

 

이미 개발된 기능들을 파악하고 재구성, 최적화 시키는 작업

 

- 사용법을 공개

- 외부 모듈과의 결합도는 낮고, 응집도는 높아야 함

 

재사용 규모에 따른 분류

- 함수와 객체 : 클래스나 메서드 단위의 소스 코드를 재사용

- 컴포넌트 : 독립적인 업무 또는 기능을 수행하는 실행 코드 기반으로 작성된 모듈, 자체 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용

- 애플리케이션 : 공통된 기능들을 제공하는 애플리케이션을 공유하는 방식으로 재사용

 

효과적인 모듈 설계 방안

 

- 결합도는 줄이고, 응집도는 높여서 독립성과 재사용성 높임

- 모듈 제어 영역 안에서 영향 영역을 유지시킴

- 복잡도, 중복성 줄이고 일관성 유지

- 예측 가능해야 하며, 지나치게 제한적이면 안 됨

- 유지보수 용이해야 함

- 모듈의 크기는 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해

- 하나의 입구, 하나의 출구

- 인덱스 번호, 기능 코드들이 처리 논리 구조에 영향 끼치지 않도록 모듈 인터페이스 설계

- 효과적인 제어를 위해 모듈 간 계층적 관계를 정의하는 자료가 제시되어야 함

 

 

 

 

 

 

출처 | <시나공> 정보처리기사 필기 2024 기본서 (길벗알앤디)