정보처리기사 Note-Taking [3]
정보처리기사 요약 노트 정리 3편
정보처리기사 Note-Taking [3]
해당 포스트는 학습 목적으로 작성되었으며 «2025 시나공 정보처리기사 실기 기본서»을 참고하여 작성하였음을 알려드립니다.
3장 - 통합구현
060 XML(eXtensible Markup Language)
XML
- 특수한 목적을 갖는 마크업 언어를 만드는 데 사용되는 다목적 마크업 언어
4장 - 서버 프로그램 구현
062 개발 환경 구축
하드웨어 환경
| 종류 | 특징 |
|---|---|
| 웹 서버(Web Server) | - 클라이언트로부터 직접 요청을 받아 처리함 - 저용량의 정적 파일들을 제공함 |
| 웹 애플리케이션 서버(Web Application Server) | - 동적 서비스를 제공하거나, 웹 서버와 데이터베이스 서버 또는 웹 서버와 파일 서버 사이에서 인터페이스 역할을 수행함 |
| 데이터베이스 서버(DB Server) | - 데이터베이스와 이를 관리하는 DBMS를 운영함 |
| 파일 서버(File Server) | - 데이터베이스에 저장하기에는 비효율적이거나, 서비스 제공을 목적으로 유지하는 파일들을 저장함 |
063 소프트웨어 아키텍쳐
소프트웨어 아키텍쳐
- 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
모듈화(Modularity)
- 시스템의 기능들을 모듈1 단위로 나누는 것
추상화(Abstraction)
- 전체적이고 포괄적인 개념을 설계한 후 구체화시켜 나가는 것
단계적 분해(Stepwise Refinement)
- 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
정보 은닉(Information Hiding)
- 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
상위 설계와 하위 설계
| 상위 설계 | 하위 설계 | |
|---|---|---|
| 별칭 | 아키텍처 설계, 예비 설계 | 모듈 설계, 상세 설계 |
| 설계 대상 | 시스템의 전체적인 구조 | 시스템의 내부 구조 및 행위 |
| 세부 목록 | 구조, DB, 인테페이스 | 컴포넌트, 자료 구조, 알고리즘 |
062 아키텍처 패턴
아키텍처 패턴(Patterns)
아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
주요 아키텍처 패턴의 종류
- 레이어 패턴
- 클라이언트-서버 패턴
- 파이프-필터 패턴
- 모델-뷰-컨트롤러 패턴
레이어 패턴(Layers Pattern)
- 시스템을 계층으로 구분하여 구성하는 패턴
- 대표적으로 OSI 참조 모델이 있다.
클라이언트-서버 패턴(Client-Server Pattern)
- 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
- 사용자가 클라이언트를 통해 서버에 요청하면 클라이언트가 응답을 받아 사용자에게 제공하는 방식이다.
파이프-필터 패턴(Pipe-Filter Pattern)
- 데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프를 통해 전송하는 패턴
- 데이터 변환, 버퍼링, 동기화 등에 주로 사용된다.
- 대표적으로 UNIX의 쉘(Shell)이 있다.
모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)
- 서브 시스템을 모델, 뷰, 컨트롤러로 구조화하는 패턴
기타 패턴
| 종류 | 내용 |
|---|---|
| 마스터-슬레이브 패턴(Master-Slave Pattern) | 장애 허용 시스템, 병렬 컴퓨팅 시스템 |
| 브로커 패턴(Broker Pattern) | 분산 환경 시스템 |
| 피어-투-피어 패턴(Peer-To-Peer Pattern) | 파일 공유 네트워크 |
| 이벤트-버스 패턴(Event-Bus Patttern) | 알림 서비스 |
| 블랙보드 패턴(Blackboard Pattern) | 음성 인식, 차량 식별, 신호 해석 |
065 객체지향(Object - Oriented)
객체지향
각 요소들을 객체(Object)로 만든 후, 객체들을 조립해서 소프트웨어를 개발하는 기법
- 객체지향의 구성 요소
- 객체(Object)
- 클래스(Class)
- 메시지(Message)
- 객체지향의 특징
- 캡슐화(Encapsulation)
- 상속(Inheritance)
- 다형성(Polymorphism)
- 연관성(Relationship)
객체(Object)
- 데이터와 이를 처리하기 위한 함수를 묶어 놓은 소프트웨어 모듈이다.
| 데이터 | 객체가 가지고 있는 정보로, 속성이나 상태, 분류 등 |
| 함수 | - 객체가 수행하는 기능을 객체가 갖는 데이터를 처리하는 알고리즘 - 객체의 상태를 참조하거나 변경하는 수단 |
클래스(Class)
- 공통된 속성과 연산을 갖는 객체의 집합
- 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 힌다.
메세지(Message)
- 객체들 간의 상호작용을 하는데 사용되는 수단으로, 객체에게 어떤 행위를 하도록 자시하는 명령 또는 요구사항이다.
캡슐화(Encapsulation)
- 외부에서 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것
상속(Inheritance)
- 상위클래스의 모든 속성과 연산을 하위클래스가 물려받는 것
다형성(Polymorphism)
- 하나의 메세지에 대해 각각의 객체가 고유한 방법으로 응답할 수 있는 능력
연관성(Relationship)
- 두 개 이상의 객ㅔ들이 상호 참조하는 관계를 의미
066 객체지향 분석 및 설계
객체지향 분석의 방법론
| 종류 | 내용 |
|---|---|
| Rumbaugh(럼바우) 방법 | - 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행 |
| Booch(부치) 방법 | - 미지석(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 수행 - 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의함 |
| Jacobson 방법 | - 유스케이스(Use Case)를 강조하여 사용함 |
| Coad와 Yourdon 방법 | - E-R 다이어그램을 사용하여 객체의 행위를 모델링함 |
| Wirfs-Brock 방법 | - 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행 |
럼바우(Rumbaugh)의 분석 기법
- 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법
객체 모델링->동적 모델링->기능 모델링
| 객체 모델링(Object Modeling) | 정보 모델링이라고 함, 시스템에서 요구되는 객체를 찾아내서 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시 |
| 동적 모델링(Dynamic Modeling) | 상태 다이어그램 을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링 |
| 기능 모델링(Functianal Modeling) | 자료 흐름도(DFD)를 이용하여 다수의 프로세스 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링 |
객체지향 설계 원칙
- 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜져야 할 원칙
| 종류 | 내용 |
|---|---|
| 단일 책임 원칙(SRP) | 객체는 단 하나의 책임만 가져야 한다는 원칙 |
| 개방-폐쇄 원칙(OCP) | 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙 |
| 리스코프 치환 원칙(LSP) | 자식 클래스는 최소한 부모 클래스의 기능은 수행할 수 있어야 한다는 원칙 |
| 인터페이스 분리 원칙(ISP) | 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙 |
| 의존 역전 원칙(DIP) | 의존 관계 성립 시 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙 |
067 모듈
결합도(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) | 모듈 내부의 각 구성요소 들이 서로 관련 없는 요소들로 만 구성된 경우의 응집도 |
071 디자인 패턴
디자인 패턴(Design Pattern)
- 모듈 간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- GOF의 디자인 패턴은 생성, 구조, 행위 으로 구분된다.
생성 패턴(Creational Pattern)
- 클래스나 객체의 생성과 참조 과정을 정의하는 패턴
| 추상 팩토리(Abstract Factory) | - 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관 / 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현함 - 연관된 서브 클래스로 묶어 한 번에 교체하는 것이 가능함 |
| 빌더(Builder) | - 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성함 - 객체의 생성 과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있음 |
| 팩토리 메서드(Factory Method) | - 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡술화한 패턴 - 상위 클래스에서 인터페이스만 정의하고 실제 생성을 서브 클래스가 담당함 - 가상 생성자(Virtual Constructor) 패턴이라고도 함 |
| 프로토타입(Prototype) | - 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴 - 일반적인 방법으로 객체를 생성하며. 비용이 큰 경우 주로 이용함 |
| 싱글톤(Singleton) | - 하나의 객체를 생성하면 생성된 객체 어디서든 참조할 수 있지만, 여러 프로세서가 동시에 참조할 수는 없음 - 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화 할 수 있음 |
구조 패턴(Structural Pattern)
- 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴
| 어댑터(Adapter) | - 호환성이 없는 클래스들의 인터페이스르 다른 클래스가 이용할 수 있도록 변환해 주는 패턴 - 기존의 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 이용함 |
| 브리지(Bridge) | - 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴 - 기능과 구현을 두 개의 별도 클래스로 구현함 |
| 컴포지트(Composite) | - 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴 - 객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함된는 구조를 구현 할 수 있음 |
| 데코레이터(Decorator) | - 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴 - 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현 |
| 퍼사트(Facade) | - 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴 - 서브 클래스들 사이에 통합 인터페이스를 제공하는 Wapper 객체가 필요함 |
| 플라이웨이트(Flyweight) | - 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴 - 다수의 유사 객체를 생성하거나 조작할 떄 유용하게 사용할 수 있음 |
| 프록시(Proxy) | - 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴으로, 대리자라고도 불림 - 내부에서는 객체 간의 복잡한 관계를 단순하게 정리하고 외부에서는 객체의 세부적인 내용을 숨김 |
행위 패턴(Behavioral Pattern)
- 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
| 책임연쇄(Chain of Responsibility) | - 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴 - 요청을 처리할 수 있는 객체들이 고리(Chain)로 묶여 있어 요청이 해결될 때까지 고리를 따라 책임이 넘어감 |
| 커맨드(Command) | - 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴 - 요청애 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화 함 |
| 인터프리터(Interpreter) | - 언어에 문법 표현을 정의하는 패턴 -SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용 |
| 반복자(Iterator) | - 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴 - 내부 표현 방법의 노출 없이 순차적인 접근이 가능함 |
| 중재자(Mediator) | - 수많은 객체들 간의 복잡한 상호작용(interface)를 캡술화하여 객체로 정의하는 패턴 - 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음 |
| 메멘토(Memento) | - 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태롤 돌리 수 있는 기능을 제공하는 패턴 - Ctrl + Z 와 같은 되돌리기 기능을 개발할 때 주로 이용 |
| 옵서버(Observer) | - 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화한 상태를 전달하는 패턴 - 일대다의 의존성의 정의함 - 주로 분산된 시스템 간에 이벤트를 생성 / 발행(Publish)하고, 이를 수신(Subscribe)해야 할 때 사용함 |
| 상태(State) | - 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴 - 객체 상태를 캡슐화하고 이를 참조하는 방식으로 처리함 |
| 전략(Strategy) | - 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴 - 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향없이 알고리즘의 변경이 가능함 |
| 템플릿 메서드(Template Method) | - 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부처리를 구체화하는 구조의 패턴 - 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양을 줄이고 유지보수를 용이하게 해줌 |
| 방문자(Visitor) | - 각 클래스들의 데이터 구조에서 처리기능을 분리하여 별도의 클래스로 구성하는 패턴 - 분리된 처리 기능은 각 클래스를 방문하여 수행 |
Related Posts
References
전체 프로그램의 기능 중에서 특정 기능을 처리할 수 있는 소스 코드를 의미 ↩︎
This post is licensed under CC BY 4.0 by the author.