정보처리기사 - 서버 프로그램 구현 #76~79
2023. 8. 19. 12:15ㆍ자격증/정보처리기사
76. 단위 모듈
76.1 단위 모듈(Unit Module)
소프트웨어 구현에 필요한 여러 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것
- 단위 기능 : 단위 모듈로 구현되는 하나의 기능
- 독립적인 컴파일이 가능하며, 다른 모듈에 호출되거나 삽입되기도 함
76.2 IPC(Inter-Process Communication)
모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합
- 복수의 프로세스를 수행하며 이뤄지는 프로세스 간 통신까지 구현이 가능
- IPC의 대표 메소드 5가지
메소드 | 특징 |
---|---|
Shared Memory | 공유 가능한 메모리를 구성하여 다수의 프로세스가 통신하는 방식 |
Socket | 네트워크 소켓을 이용하여 네트워크를 경유하는 프로세스 간에 통신하는 방식 |
Semaphores | 공유 자원에 대한 접근 제어를 통해 통신하는 방식 |
Pipes&named Pipes | - 'Pipe'라고 불리는 FIFO 형태로 구성된 메모리를 여러 프로세스가 공유하여 통신하는 방식 - Pipe는 하나의 프로세스가 이용 중이라면 다른 프로세스는 접근할 수 없음 |
Message Queueing | 메시지가 발생하면 이를 전달하는 방식으로 통신하는 방식 |
76.3 단위 모듈 테스트
프로그램의 단위 기능으로 구현된 모듈이 정해진 기능을 정확히 수행하는지 검증하는 것
- 단위 테스트(Unit Test)라고 불림
- 단위 모듈 테스트의 기준은 단위 모듈에 대한 코드이므로 시스템 수준의 오류는 잡아낼 수 없음
76.4 테스트 케이스(Test Case)
구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위한 테스트 항목에 대한 명세서
- 테스트 케이스를 이용하지 않은 테스트는 특정 요소에 대한 검증이 누락되거나 불필요한 검증의 반복으로 인해 인력과 시간을 낭비할 수 있음
- ISO/IEC/IEEE 29119-3 표준에 따른 테스트 케이스의 구성 요소
종류 | 내용 |
---|---|
식별자 (Identifier) |
항목 식별자, 일련번호 |
테스트 항목 (Test Item) |
테스트 대상(모듈 또는 기능) |
입력 명세 (Input Specification) |
입력 데이터 또는 테스트 조건 |
출력 명세 (Output Specification) |
테스트 케이스 수행 시 예상되는 출력 결과 |
환경 설정 (Environmental Needs) |
필요한 하드웨어나 소프트웨어의 환경 |
특수 절차 요구 (Special Procedure Requirement) |
테스트 케이스 수행 시 특별히 요구되는 절차 |
의존성 기술 (Inter-case Dependencies) |
테스트 케이스 간의 의존성 |
77. 공통 모듈
77.1 공통 모듈
여러 프로그램에서 공통으로 사용할 수 있는 모듈
- 자주 사용되는 계산식이나 매번 필요한 사용자 인증과 같은 기능들이 공통 모듈로 구성될 수 있음
- 공통 모듈을 구현할 때는 해당 기능을 명확히 이해할 수 있도록 명세 기법을 준수해야 함
77.2 공통 모듈 명세 기법의 종류
명세 기법 | 내용 |
---|---|
정확성 (Correctness) |
시스템 구현 시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성 |
명확성 (Clarity) |
해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확하게 작성 |
완전성 (Completeness) |
시스템 구현을 위해 필요한 모든 것을 기술 |
일관성 (Consistency) |
공통 기능들 간 상호 충돌이 발생하지 않도록 작성 |
추적성 (Traceability) |
기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성 |
77.3 재사용(Reuse)
이미 개발된 기능들을 새로운 시스템이나 기능 개발에 사용하기 적합하도록 최적화하는 작업
- 새로 개발하는데 필요한 비용과 시간을 절약할 수 있음
- 누구나 이해할 수 있고 사용이 가능하도록 사용법을 공개해야 함
- 재사용 규모에 따른 분류
규모 | 내용 |
---|---|
함수와 객체 | 클래스나 메소드 단위의 소스 코드를 재사용 |
컴포넌트 | 컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용 |
애플리케이션 | 공통된 기능들을 제공하는 애플리케이션을 공유하는 방식으로 재사용 |
77.4 효과적인 모듈 설계 방안
- 결합도는 줄이고 응집도는 높여서 모듈의 독립성과 재사용성을 높임
- 복잡도와 중요성은 줄이고 일관성은 유지시킴
- 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안 됨
- 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해
- 효과적인 제어를 위해 모듈 간의 계층적 관계를 정의하는 자료가 제시되어야 함
78. 코드
78.1 코드(Code)
자료의 분류·조합·집계·추출을 용이하게 하기 위해 사용되는 기호
- 정보를 신속·정확·명료하게 전달할 수 있게 함
- 일정한 규칙에 따라 작성
- 정보 처리의 효율과 처리된 정보의 가치에 많은 영향을 미침
78.2 코드의 주요 기능
기능 | 내용 |
---|---|
식별 기능 | 데이터 간의 성격에 따라 구분이 가능 |
분류 기능 | 특정 기준이나 동일한 유형에 해당하는 데이터를 그룹화 할 수 있음 |
배열 기능 | 의미를 부여하여 나열할 수 있음 |
표준화 기능 | 다양한 데이터를 기준에 맞추어 표현할 수 있음 |
간소화 기능 | 복잡한 데이터를 간소화할 수 있음 |
78.3 코드의 종류
종류 | 내용 | 예시 |
---|---|---|
순차 코드 (Sequence Code) |
- 자료의 발생 순서, 크기 순서 등 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여하는 방법 - 순서 코드 또는 일련번호 코드라고도 함 |
1 2 3 4.. |
블록 코드 (Block Code) |
- 코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 방법 - 구분 코드라고도 함 |
1001~1100: 총무부 1101~1200 : 영업부 |
10진 코드 (Demical Code) |
- 코드화 대상 항목을 0~9까지 10진 분할하고, 다시 그 각에 대하여 10진 분할하는 방법을 필요한 만큼 반복하는 방법 - 도서 분류식 코드라고도 함 |
1000 : 공학 1100 : 소프트웨어 공학 1110 : 소프트웨어 설계 |
그룹 분류 코드 (Group Classification Code) |
코드화 대상 항목을 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고, 각 그룹 안에서 일련번호를 부여하는 방법 | 1-01-001 : 본사-총무부-인사계 2-01-001 : 지사-총무부-인사계 |
연상 코드 (Mnemonic Code) |
코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용하여 코드를 부여하는 방법 | TV-40 : 40인치 TVL-15-220 : 15W 220V의 램프 |
표의 숫자 코드 (Significant Digit Code) |
- 코드화 대상 항목의 성질, 즉 길이, 넓이, 부피, 지름, 높이 등의 물리적 수치를 그대로 코드에 적용시키는 방법 - 유효 숫자 코드라고도 함 |
120-720-1500 : 두께×폭×길이가 120×720×1500인 강판 |
합성 코드 (Combined Code) |
필요한 기능을 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 만드는 방법 | 예) 연상 코드 + 순차 코드 KE-711 : 대한항공 711기 AC-253 : 에어캐나다 253기 |
79. 디자인 패턴
79.1 디자인 패턴(Design Pattern)
모듈 간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드 등으로 구성
- '바퀴를 다시 발명하지 마라(Don't reinvent the wheel)'라는 말과 같이, 개발 과정 중에 문제가 발생하면 새로 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적
- 바퀴를 다시 발명하지 마라(Don't reinvent the wheel) : 이미 존재하는 기술이나 제품을 굳이 다시 만들기 위해 시간과 노동력을 소모하지 말라는 의미의 관용구
- GOF의 디자인 패턴은 생성 패턴, 구조 패턴, 행위 패턴으로 구분
79.2 생성 패턴(Creational Pattern)
클래스나 객체의 생성과 참조 과정을 정의하는 패턴
패턴 | 내용 |
---|---|
추상 팩토리 (Abstract Factory) |
- 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관·의존하는 객체들의 그룹으로 생성하여 추상적으로 표현 - 연관된 서브 클래스를 묶어 한 번에 교체하는 것이 가능 |
빌더 (Builder) |
- 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성 - 객체의 생성 과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어낼 수 있음 |
팩토리 메소드 (Factory Method) |
- 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴 - 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당 - 가상 생성자(Virtual Constructor) 패턴이라고도 함 |
프로토타입 (Prototype) |
- 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴 - 일반적인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 이용 |
싱글톤 (Singleton) |
- 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없음 - 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화할 수 있음 |
79.3 구조 패턴(Structural Pattern)
구조가 복잡한 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴
패턴 | 내용 |
---|---|
어댑터 (Adapter) |
- 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴 - 기존의 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 이용 |
브리지 (Bridge) |
- 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴 - 기능과 구현 두 개의 별도 클래스로 구현 |
컴포지트 (Composite) |
- 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴 - 객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함되는 구조를 구현할 수 있음 |
데코레이터 (Decorator) |
- 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴 - 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현 |
퍼싸드 (Facade) |
- 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴 - 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요 |
플라이웨이트 (Flyweight) |
- 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴 - 다수의 유사 객체를 생성하거나 조작할 때 유용하게 사용할 수 있음 |
프록시 (Proxy) |
- 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴 - 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주료 이용 |
79.4 행위 패턴(Behavioral Pattern)
클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
패턴 | 내용 |
---|---|
책임 연쇄 (Chain of Responsibility) |
- 요청을 처리할 수 있는 객체가 둘 이상 존재하며 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴 - 요청을 처리할 수 있는 각 객체들이 고리(Chain)로 묶여 있어 요청이 해결될 때까지 고리를 따라 책임이 넘어감 |
커맨드 (Command) |
- 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴 - 요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화 |
인터프리터 (Interpreter) |
- 언어에 문법 표현을 정의하는 패턴 - SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용 |
반복자 (Iterator) |
- 자료 구조와 같이 접근이 잦은 객체에 대한 동일한 인터페이스를 사용하도록 하는 패턴 - 내부 표현 방법의 노출 없이 순차적인 접근이 가능 |
중재자 (Mediator) |
- 수많은 객체들 간의 복잡한 상호작용(Interface)을 캡슐화하여 객체로 정의하는 패턴 - 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음 |
메멘토 (Memento) |
- 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴 - 'Ctrl+Z'와 같은 되돌리기 기능을 개발할 때 주로 이용 |
옵서버 (Observer) |
- 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴 - 일대다의 의존성을 정의 - 주로 분산된 시스템 간에 이벤트를 생성·발행(Publish)하고, 이를 수신(Subscribe)해야 할 때 이용 |
상태 (State) |
- 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴 - 객체 상태를 캡슐화하고 이를 참조하는 방식으로 처리 |
전략 (Strategy) |
- 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴 - 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘의 변경이 가능 |
템플릿 메소드 (Template Method) |
- 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴 - 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양을 줄이고 유지보수를 용이하게 해줌 |
방문자 (Visitor) |
- 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴 - 분리된 처리 기능은 각 클래스를 방문(Visit)하여 수행 |
79.5 패턴 별 의미 정리
- 생성 패턴(Creational Pattern)
- 구조 패턴(Structural Pattern)
- 행위 패턴(Behavioral Pattern)
'자격증 > 정보처리기사' 카테고리의 다른 글
정보처리기사 - 인터페이스 구현 #85~91 (0) | 2023.08.19 |
---|---|
정보처리기사 - 서버 프로그램 구현 #80~84 (0) | 2023.08.19 |
정보처리기사 - 서버 프로그램 구현 #73~75 (0) | 2023.08.19 |
정보처리기사 - 서버 프로그램 구현 #70~72 (0) | 2023.08.19 |
정보처리기사 - 통합 구현 #64~69 (0) | 2023.08.19 |