▶ 023 모듈
모듈
모듈화를 통해 분리된 시스템의 각 기능
- 서브루틴, 서브시스템, 작업단위 등과 같은 의미
- 단독으로 컴파일 가능, 재사용 가능
- 모듈의 독립성은 결합도와 응집도에 의해 측정 됨
- 독립성을 높이려면 모듈의 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 함
- 독립성이 높을 수록 모듈 수정 시 다른 모듈들에게 영향을 미치지 않고, 오류가 발생해도 쉽게 발견하고 해결할 수 있음
결합도(Coupling)
모듈 간에 상호 의존하는 정도, 두 모듈 사이의 연관 관계
- 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮음
- 결합도가 강하면 유지보수 작업이 어려움
- 자료 결합도, 스탬프 결합도, 제어 결합도, 외부 결합도, 공통 결합도, 내용 결합도 순으로 결합도가 강해짐
자료 결합도(Data Coupling) |
모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도 - 다른 모듈 호출 시 매개 변수나 인수로 테이터를 넘겨주고, 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 방식 |
스탬프 결합도(Stamp Coupling) |
모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도 |
제어 결합도(Control Coupling) |
어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용해 통신하거나 제어 요소를 전달하는 결합도 |
외부 결합도(External Coupling) |
어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때의 결합도 |
공통 결합도(Common Coupling) |
공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도 |
내용 결합도(Content Coupling) |
한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정 할 때의 결합도 |
응집도(Cohesion)
정보 은닉 개념을 확장한 것, 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 모듈이 독립적인 기능으로 정의되어 있는 정도
- 응집도가 강할수록 품질이 높고, 약할 수록 품질이 낮다
- 기능적 응집도, 순차적 응집도, 교환적 응집도, 절차적 응집도, 시간적 응집도, 논리적 응집도, 우연적 응집도 순으로 응집도가 약해짐
기능적 응집도 (Functional Cohesion) | 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우 |
순차적 응집도 (Sequential Cohesion) | 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도 |
교환(통신)적 응집도 (Communication Cohesion) | 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도 |
절차적 응집도 (Procedural Cohesion) | 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도 |
시간적 응집도 (Temporal Cohesion) | 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도 |
논리적 응집도 (Logical Cohesion) | 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도 |
우연적 응집도 (Coincidental Cohesion) | 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도 |
팬인(Fan-In) / 팬아웃(Fan-Out)
- 팬인 : 자신을 사용하는 모듈의 수
- 팬아웃 : 자신이 호출하는 모듈의 수
- 팬인과 팬아웃을 분석해 시스템의 복잡도를 알 수 있음
- 팬인이 높다 = 재사용 측면에서 설계가 잘되었으나, 단일 장애점이 발생할 수 있으므로 중점적인 관리 및 테스트가 필요하다
- 팬아웃이 높다 = 불필요한 호출을 하고 있는지 검토하고, 단순화 시킬 수 있는지 여부에 대한 검토가 필요하다
- 시스템의 복잡도를 최적화하기 위해선 팬인은 높게, 팬아웃은 낮게 설계해야 함
B의 팬인 : A
B의 팬아웃 : E, F
▶ 024 공통 모듈
공통 모듈
여러 프로그램에서 공통적으로 사용할 수 있는 모듈
- 자주 사용되는 계산식, 매번 필요한 사용자 인증과 같은 기능들이 공통 모듈로 구성될 수 있음
- 공통 모듈 구현 시 다음의 명세 기법을 준수해야 함
정확성(Correctness) |
시스템 구현 시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성 |
명확성(Clarity) |
해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확하게 작성 |
완전성(Completeness) |
시스템 구현을 위해 필요한 모든 것을 기술 |
일관성(Consistency) |
공통 기능들 간 상호 충돌이 발생하지 않도록 작성 |
추적성(Traceability) |
기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성 |
재사용(Reuse)
비용과 개발 시간을 절약하기 위해 이미 개발된 기능들을 파악하고 재구성하여 새로운 시스템 또는 기능 개발에 사용하기 적합하도록 최적화 시키는 작업
- 재사용되는 대상은 외부 모듈과의 결합도는 낮고 응집도는 높아야 함
효과적인 모듈 설계 방안
- 결합도는 줄이고 응집도는 높여 모듈의 독립성과 재사용성을 높임
- 복잡도와 중복성을 줄이고 일관성 유지
- 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안됨
- 유지보수가 용이해야 함
- 하나의 입구와 하나의 출구를 갖도록 해야 함
- 모듈 인터페이스를 설계해야 함
▶ 025 코드
코드
컴퓨터를 이용해 자료를 처리하는 과정에서 분류, 조합 및 집계를 용이하게 하고, 특정 자료의 추출을 쉽게 하기 위해 사용하는 기호
- 일정한 규칙에 따라 작성, 정보 처리의 효율과 처리된 정보의 가치에 영향을 미침
- 코드의 주요 기능 : 식별 기능, 분류 기능, 배열 기능
코드의 종류
순차 코드 (Sequence Code) |
자료의 발생 순서, 크기 순서 등 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여하는 방법 ex) 1, 2, 3, 4 ... |
블록 코드 (Block Code) |
코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 방법 ex) 1001~1100 : 총무부, 1101~1200 : 영업부 |
10진 코드 (Decimal Code) |
코드화 대상 항목을 0~9까지 10진 분할하고, 다시 그 각각에 대하여 10진 분할 하는 방법을 필요한 만큼 반복하는 방법 ex) 1000: 공학, 1100 : 소프트웨어 공학, 1110 : 소프트웨어 설계 |
그룹 분류 코드 (Group Classification Code) |
코드화 대상 항목을 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고, 각 그룹 안에서 일련번호를 부여하는 방법 ex) 1-01-001 : 본사-총무부-인사계, 2-01-001 : 지사-총무부-인사계 |
연상 코드 (Mnemonic Code) |
코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용해 코드를 부여하는 방법 ex) TV-40 : 40인치 TV |
표의 숫자 코드 (Significant Digit Code) |
코드화 대상 항목의 성질의 물리적 수치를 그대로 코드에 적용시키는 방법 ex) 120-720-1500 : 두께*폭*길이가 120*720*1500인 강판 |
합성 코드 (Combined Code) |
필요한 기능을 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 만드는 방법 |
코드 부여 체계
이름만으로 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식
- 각 개체에 유일한 코드를 부여해 개체들의 식별 및 추출을 용이하게 함
- 코드를 부여하기 전에 각 단위 시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야 함
- 코드 부여 체계를 담당하는 자는 코드의 자릿수와 구분자, 구조 등을 상세하게 명시해야 함
▶ 026 디자인 패턴
디자인 패턴
각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식, 예제
- 디자인 패턴은 GoF(Gang of Four, 에릭 감마, 리차드 헬름, 랄프 존슨, 존 블리시디스)가 처음으로 구체화 및 체계화 함
- GoF의 디자인 패턴은 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성됨
☞ 아키텍처 패턴 vs 디자인 패턴
- 아키텍처 패턴은 디자인 패턴보다 상위 수준의 설계에 사용됨
- 아키텍처 패턴 : 전체 시스템의 구조를 설계하기 위한 참조 모델
- 디자인 패턴 : 서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델
- 몇몇 디자인 패턴은 특정 아키텍처 패턴을 구현하는데 유용하게 사용됨
생성 패턴(Creational Pattern)
객체의 생성과 참조 과정을 캡슐화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 해 프로그램의 유연성 더해줌
- 추상 팩토리(Abstract Factory) : 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹으로 생성해 추상적으로 표현
- 빌더(Builder) : 작게 분리된 인스턴스를 건축 하듯이 조합하여 객체 생성
- 팩토리 메소드(Factory Method) : 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
- 프로토타입(Prototype) : 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
- 싱글톤(Singleton) : 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수 없음
구조 패턴(Structural Pattern)
클래스나 객체들을 조합해 더 큰 구조로 만들 수 있게 해주는 패턴
- 어댑터(Adapter) : 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
- 브리지(Bridge) : 구현부에서 추상층을 분리해 서로가 독립적으로 확장할 수 있도록 구성한 패턴
- 컴포지트(Composite) : 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
- 데코레이터(Decorator) : 객체 간의 결합을 통해 능동적 기능들을 확장할 수 있는 패턴
- 퍼싸드(Facade) : 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
- 플라이웨이트(Flyweight) : 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴
- 프록시(Proxy) : 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할 수행하는 패턴
행위 패턴(Behavioral Pattern)
하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와주는 패턴
- 책임 연쇄(Chain of Responsibility) : 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
- 커멘드(Command) : 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
- 인터프리터(Interpreter) : 언어에 문법 표현을 정의하는 패턴
- 반복자(lterator) : 자료 구조와 같이 접근이 잦은 객체 대해 동일한 인터페이스를 사용하도록 하는 패턴
- 중재자(Mediator) : 수많은 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴
- 메멘토(Memento) : 특정 시점에서의 객체 내부 상태를 객체화하므로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
- 옵서버(Observer) : 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
- 상태(State) : 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할때 사용하는 패턴
- 전략(Strategy) : 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
- 템플릿 메소드 : 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
- 방문자(Visitor) : 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
