본문에 오류가 있을 수 있음을 감안하고 봐주시길 바랍니다.
# 문제 풀이 중 오답노트 하면서 나온 내용을 정리한 것
객체 지향(Object-oriented): 소프트웨어의 각 요소들을 객체로 만든 후 객체들을 조립해서 소프트웨어를 개발하는 기법이다. 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용되고 있다. 소프트웨어의 재사용 및 확장이 용이하고 고품질의 소프트웨어를 빠르게 개발할 수 있고 유지보수가 쉽다.
- 캡슐화(Encapsulation): 외부에서 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것이다. 캡슐화된 객체는 외부 모듈의 변경으로 인한 파급 효과가 적고 인터페이스가 단순해지고 객체 간의 결합도가 낮아진다. # 속성과 관련된 연산을 클래스 안에 묶어서 하나로 취급하는 것
- 상속(Inheritance): 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것이다. 하위 클래스는 물려받은 속성과 연산을 다시 정의하지 않아도 즉시 자신의 속성으로 사용할 수 있고 새로운 속성과 연산을 첨가하여 사용할 수도 있다.
- 다형성(Polymorphism): 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력이다. 객체들은 동일한 메서드명을 사용하며 같은 의미의 응답을 한다.
- 메소드 오버라이딩(Overriding): 상위 클래스에서 정읳나 일반 메소드의 구현을 하위 클래스에서 무시하고 재정의
- 메소드 오버로딩(Overloading): 메소드명은 같지만 매개 변수의 개수나 타입을 다르게 함으로써 구현 및 구분
- 추상화(Abstraction): 복잡한 시스템으로부터 핵심적인 개념이나 기능을 간추려내는 것이다. 불필요한 세부 사항은 숨기고 중요한 특징만 모델화하여 복잡도를 낮추는 역할을 한다.
- 연관성(Relationship): 두 개 이상의 객체들이 상호 참조하는 관계를 의미한다.
| 종류 | 의미 | 특징 |
| is member of | 연관화(Association) | 2개 이상의 객체가 상호 관련되어 있음을 의미함 |
| is instance of | 분류화(Classfication) | 동일한 형의 특성을 갖는 객체들을 모아 구성하는 것 |
| is part of | 집단화(Aggregation) | 관련 있는 객체들을 묶어 하나의 상위 객체를 구성하는 것 # 부분-전체(Part-Whole) 관계 또는 부분(is-a-part-of)의 관계로 설명되는 연관성 |
| is a | 일반화(Generalization) | 공통적인 성질들로 추상화한 상위 객체를 구성하는 것 |
| 특수화/상세화(Specialization) | 상위 객체를 구체화하여 하위 객체를 구성하는 것 |
객체지향 분석(OOA): 사용자의 요구사항과 관련된 객체·속성·연산·관계 등을 정의하여 모델링하는 작업이다. 클래스를 식별하는 것이 객체지향 분석의 주요 목적이다. 소프트웨어를 개발하기 위한 비즈니스(업무)를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석해 내는 기법이다.
| 종류 | 내용 |
| Rumbaugh(럼바우) 방법 | 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행함 |
| Booch(부치) 방법 | · 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용함 · 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의함 |
| Jacobson 방법 | 유스케이스(Use Case)를 강조하여 사용함 |
| Coad와 Yourdon 방법 | · E-R 다이어그램을 사용하여 객체의 행위를 모델링함 · 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성 |
| Wirfs-Brock 방법 | 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행함 |
럼바우(Rumbaugh)의 분석 기법: 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법이다. 객체 모델링 기법(OMT)라고도 한다. 분석 활동은 '객체 모델링 → 동적 모델링 → 기능 모델링' 순으로 이루어진다.
- 객체 모델링(Object Modeling): 정보 모델링(Information Modeling)이라고도 하며 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것 # E-R 다이어그램
- 동적 모델링(Dynamic Modeling): 상태 다이어그램을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링 # 상태변화도(STD), 사건추적도
- 기능 모델링(Functional Modeling): 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링
객체지향 설계 원칙(SOLID 원칙): 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜져야 할 원칙이다.
| 종류 | 내용 |
| 단일 책임 원칙(SRP) | 객체는 단 하나의 책임만 가져야 한다는 원칙 |
| 개방-폐쇄 원칙(OCP) | 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙 |
| 리스코프 치환 원칙(LSP) | 자식 클래스는 최소한 부모 클래스의 기능은 수행할 수 있어야 한다는 원칙 |
| 인터페이스 분리 원칙(ISP) | 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙 |
| 의존 역전 원칙(DIP) | 의존 관계 성립 시 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙 |
모듈(Module): 모듈화를 통해 분리된 시스템의 각 기능(Unit)으로 서브루틴 ·서브시스템 ·소프트웨어 내의 프로그램·작업 단위 등을 의미한다. 모듈의 독립성은 결합도(Coupling)와 응집도(Cohesion)에 의해 측정된다. 독립적인 컴파일이 가능하며 유일한 이름을 가져야 한다.
- 결합도(Coupling): 모듈 간의 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계이다. 결합도가 약할수록 품질이 높다.

| 종류 | 내용 |
| 내용 결합도(Content Coupling) | 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도 |
| 공통(공유) 결합도(Common Coupling) | · 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도 · 파라미터가 아닌 모듈 밖에 선언된 전역변수를 사용하여 전역변수를 갱신하는 방식으로 상호작용하는 때의 결합도 |
| 외부 결합도(External Coupling) | 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도 |
| 제어 결합도(Control Coupling) | · 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호나 제어 요소를 전달하는 결합도 · 하위 모듈에서 상위 모듈로 제어 신호가 이동하여 하위 모듈이 상위 모듈에게 처리 명령을 내리는 권리 전도 현상이 발생하게 됨 |
| 스탬프(검인) 결합도(Stamp Coupling) | 모듈 간의 인터페이스로 배열이나 레코드 등의 자료구조가 전달될 때의 결합도 |
| 자료 결합도(Data Coupling) | 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도 |
- 응집도(Cohesion): 모듈 내부 요소들이 서로 관련되어 있는 정도이다. 응집도가 강할수록 품질이 높다. # 한 모듈 내의 각각의 구성요소들이 공통의 목적을 달성하기 위해 서로 얼마나 관련이 있는지의 기능적 연관의 정도

| 종류 | 내용 |
| 기능적 응집도(Functional Cohesion) | 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도 |
| 순차적 응집도(Sequential Cohesion) | 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도 |
| 교환(통신)적 응집도(Communication Cohesion) | 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도 |
| 절차적 응집도(Procedural Cohesion) | 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도 |
| 시간적 응집도(Temporal Cohesion) | 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도 |
| 논리적 응집도(Logical Cohesion) | 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도 |
| 우연적 응집도(Coincidental Cohesion) | 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도 |
팬인(Fan-In): 해당 모듈을 제어하는 모듈의 수(들어오는 것), 팬인이 높다는 것은 재사용 측면에서 설계가 잘 되어 있다고 볼 수 있으나 단일 장애점(시스템의 구성요소 중 동작하지 않으면 전체 시스템이 종료되는 것)이 발생할 수 있으므로 중점적인 관리 및 테스트가 필요하다.
팬아웃(Fan-Out): 해당 모듈에 의해 제어되는 모듈의 수(나가는 것)

N-S 차트(Nassi-Schneiderman Chart): 논리 기술에 중점을 두고 도형을 이용해 표현하는 방법이다. 박스 다이어그램·Chapin Chart라고도 한다. GOTO나 화살표를 사용하지 않고 연속·선택 및 다중 선택·반복의 3가지 제어 논리 구조로 표현한다. 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는데 적합하다. 이해하기 쉽고 코드 변환이 용이하다.

단위 모듈(Unit Module): 소프트웨어 구현에 필요한 여러 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것이다. 단위 모듈로 구현되는 하나의 기능을 단위 기능이라고 부르며 독립적인 컴파일이 가능하다. 다른 모듈에 호출되거나 삽입되기도 한다.
- 단위 모듈의 구현 과정: 단위 기능 명세서 작성 → 입·출력 기능 구현 → 알고리즘 구현
공통 모듈: 여러 프로그램에서 공통으로 사용할 수 있는 모듈이다. 자주 사용되는 계산식이나 매번 필요한 사용자 인증과 같은 기능들이 공통 모듈로 구성될 수 있고 공통 모듈은 구현할 때는 해당 기능을 명확히 이해할 수 있도록 명세 기법을 준수해야 한다.
| 명세 기법 | 내용 |
| 정확성(Correctness) | 시스템 구현시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성함 |
| 명확성(Clarity) | 해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확하게 작성함 |
| 완전성(Completeness) | 시스템 구현을 위해 필요한 모든 것을 기술함 |
| 일관성(Consistency) | 공통 기능들 간 상호 충돌이 발생하지 않도록 작성함 |
| 추적성(Traceability) | 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성함 |
IPC(Inter-Process Communication): 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합이다. 복수의 프로세스를 수행하며 이뤄지는 프로세스 간 통신까지 구현이 가능하다.
| 메소드 | 특징 |
| Shared Memory | 공유 가능한 메모리를 구성하여 다수의 프로세스가 통신하는 방식 |
| Socket | · 네트워크 소켓을 이용하여 네트워크를 경유하는 프로세스간에 통신하는 방식 · 통신을 위한 프로그램을 생성하여 포트를 할당하고 클라이언트의 통신 요청 시 클라이언트와 연결하는 내·외부 송·수신 연계 기술 |
| Semaphores(세마포어) | · 공유 자원에 대한 접근 제어를 통해 통신하는 방식 · 신호기·깃발을 뜻하며 각 프로세스에 제어 신호를 전달하여 순서대로 작업을 수행하도록 하는 기법 · 다익스트라가 제안했으며 P와 V라는 두 개의 연산을 사용(예: P(S) : ~; S := ~; V(S) : S := ~;) |
| Pipe&named Pipe | 'Pipe'라고 불리는 선입선출 형태로 구성된 메모리를 여러 프로세스가 공유하여 통신하는 방식 Pipe는 하나의 프로세스가 이용중이라면 다른 프로세스는 접근할 수 없음 |
| Message Queueing | 메시지가 발생하면 이를 전달하는 방식으로 통신하는 방식 |
재사용(Reuse): 이미 개발된 기능들을 새로운 시스템이나 기능 개발에 사용하기 적합하도록 최적화하는 작업이다. 새로 개발하는데 필요한 비용과 시간을 절약할 수 있고, 누구나 이해할 수 있고, 사용이 가능하도록 사용법을 공개해야 한다.
- 함수와 객체: 클래스나 메서드 단위의 소스 코드를 재사용함
- 컴포넌트: 독립적인 업무 또는 기능을 수행하는 실행 코드 기반으로 작성된 모듈, 컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용함
- 애플리케이션: 공통된 기능들을 제공하는 애플리케이션을 공유하는 방식으로 재사용함
효과적인 모듈 설계 방안: 결합도는 줄이고 응집도는 높여서 모듈의 독립성과 재사용성을 높인다. 복잡도와 중복성을 줄이고 일관성을 유지시킨다. 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안 된다. 모듈의 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해한다. 효과적인 제어를 위해 모듈 간의 계층적 관계를 정의하는 자료가 제시되어야 한다.
'정보처리기사' 카테고리의 다른 글
| [정보처리기사 요약 4-4] 서버 개발 프레임워크(Spring, Node.js)와 배치 스케줄러(Batch Scheduler) (0) | 2026.02.26 |
|---|---|
| [정보처리기사 요약 4-3] GoF 디자인 패턴 23가지 총정리 및 코드(Code)의 종류 (0) | 2026.02.26 |
| [정보처리기사 요약 4-1] 소프트웨어 개발 환경 구축 및 아키텍처 패턴 완벽 정리 (0) | 2026.02.25 |
| [정보처리기사 요약 3] 통합 구현 및 연계 메커니즘 정리(시스템 연계 방식부터 오류 관리까지) (0) | 2026.02.25 |
| [정보처리기사 요약 2-7] 자료구조와 정렬 알고리즘 핵심 요약 (0) | 2026.02.25 |