2021년 8월 12일 - 정보처리기사 실기 4장 서버 프로그램 구현

● 본 기록은 '코딩하는 핑가님'의 허락을 받고 블로그에 정리된 글을 그대로 필사했음을 밝힙니다.

→ https://ss-o.tistory.com/110?category=1013699

정보처리기사 실기 목차 - 정리, 예상문제, 문제 복원 수록

 

 

---

 

1. 서버 프로그램 구현

 

1) 개발 환경 구축

* 개발 도구 분류  빌구테형

- 빌드 도구 : 코드의 빌드와 배포 수행 - Gradle, Maven, Ant

- 구현 도구 : 코드 작성과 디버깅 및 수정 작업

- 테스트 도구 : 코드의 기능과 품질 향상 - xUnit, PMD, Findbugs, Cppcheck, Sonar

- 형상관리 도구 : 코드의 산출에 대한 버전 관리

 

 

* 서버 하드웨어 개발 환경  클엡와디

Client	Web Server	WAS	DB(데이터 베이스)
Client 하드웨어 개발 환경	웹상의 정적 콘텐츠 HTTP를 이용한 요청/응답	동적 콘텐츠	데이터 수집 및 관리

 

 

* 소프트웨어 개발 환경  운미디

운영체제	미들웨어	DBMS
하드웨어와 사용자 인터페이스	컴퓨터와 컴퓨터를 연결 쉽고 안전하게 프로그램 사용	사용자 DB 사이 위치

 

* JVM : 시스템 메모리를 관리하고, 자바 기반 Application을 위해 실행 환경 제공

 

 

* 형상 관리(SCM : Software Configuration Management) (2020실기 2회 기출문제 - 단답형)

- 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동

- 소프트웨어 변경의 원인을 알아내고 제어하며, 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보

- 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지보수 단계에서도 수행

- 형상 관리는 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 함

 

* 형상 관리 기능의 종류 : 버전 제어, 형상 식별, 형상 통제, 형상 감사, 형상 기록  버식통감기

- 버전 제어

: 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구(Tool)를 결합시키는 작업

 

- 형상 식별

: 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이하도록 함

 

- 형상 통제 (변경 관리)

: 식별된 형상 항목에 대한 변경 요구를 검토하여, 현재의 기준선(Base Line)이 잘 반영될 수 있도록 조정하는 작업

 

- 형상 감사

: 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업

 

- 형상 기록 (상태 보고)

: 형상의 식별, 통제, 감사 작업의 결과를 기록 관리하고 보고서를 작성하는 작업

 

 

* 베이스라인 (단답형)

- 개발 과정의 각 단계에서 나온 산출물들의 변화를 통제하는 시점

 

 

2) 공통 모듈 구현

* 모듈 (서술형) : 하나의 소프트웨어 또는 하드웨어 단위

- 소프트웨어 설계에서 기능 단위로 분해하여, 추상화되어 재사용 및 공유가 가능한 단위

 

* 모듈화 (서술형) : 모듈을 통해 소프트웨어의 성능을 향상시키고 디버깅, 수정, 통합을 용이하게 하는 설계 기법

- 모듈화 기법 : 루틴, 메인 루틴, 서브 루틴

* 루틴 : 소프트웨어의 특정 동작을 수행하는 코드

 

 

* 공통모듈

- 기능을 분할하고 추상화하여, 성능 향상 및 유지 보수를 효과적으로 하기 위한 공통 컴포넌트 구현 기법

- 공통 모듈 구현 비용

: 모듈 개수 ↑ >> 통합 비용 ↑

: 모듈 개수↓ >> 개발 비용 ↑

* 공장에서 모듈(부품) 생산할 때, 모듈 개수가 많다면 인프라 구축으로 인해 개발 비용은 별로 들지 않지만, 통합적인 비용이 많이 들 수 있다. 반대로 공장에서 적은 모듈의 개수를 생산한다면 각각의 모듈에 대한 개발 비용이 들 수 있다.

 

 

* 결합도와 응집도

- 결합도 : 상호의존의 정도, 결합도가 약해야 품질이 상승

[결합도가 강한 순서 → 내공외제스자] (뒤로 갈수록 좋음)

* 내용 - 직접참조, 다른 모듈에서 사용

* 공통 - 공유되는

* 외부 - 참조

* 제어 - 다른 모듈에서 흐름 파악

* 스탬프 - 자료구조

* 자료 - 데이터

content - common - external - control - stamp - data

- 내용 : 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때 (다른 모듈에서 사용하는 경우)

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

- 외부 : 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때

- 제어 : 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나, 처리 기능이 두 모듈에 분산되어 설계된 경우, 다른 모듈에서 흐름을 제어

- 스탬프 : 두 모듈이 동일한 자료 구조를 조회하는 경우 

- 자료 : 어떤 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨주고, 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 방식

 

 

- 응집도 : 정보은닉 개념 확장, 응집도가 강할수록 품질이 상승

[응집도가 강한 순서 → 우논시절통순기] (뒤로 갈수록 좋음)

* 우연 - 서로 관련 없는 요소

* 논리 - 유사한 성격

* 시간 - 특정시간

* 절차 - 다수의 관련기능 순차 수행

* 통신 - 동일한 입출력 다른 기능 수행

* 순차 - 나온것 입력

* 기능 - 단일

concidential - logical - temporal - procedural - communication - sequential - functional

- 우연적 : 모듈 내부의 각 구성요소들이 서로 관련없는 요소로만 구성된 경우

- 논리적 : 유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들이 하나의 모듈이 되는 경우

- 시간적 : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성한 경우

- 절차적 : 모듈이 다수의 관련 기능을 가질 때, 모둘 안의 구성요소들이 그 기능을 순차적으로 수행할 경우

- 통신적 : 동일한 입출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우

- 순차적 : 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음활동의 입력 데이터로 사용할 경우

- 기능적 : 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우

 

 

3) 공통 모듈 구현 절차

DTO/VO → SQL → DAO → Service → Controller → View  DSDSCV

* DTO(Data Access Object) : 프로세스 사이에서 데이터 전송

* VO(Value Object) : 고정 클래스가 가지는 Object

* DAO(Data Transfer Object) : 특정 타입의 DB의 추상 인터페이스를 제공하는 객체

 

 

* MVC 패턴 : Model, View, Controller로 이루어진 패턴  행구생

행위 패턴 (Behavioral Pattern)	구조 패턴  퍼플컴프브데어 (Structural Pattern)	생성 패턴  BP-FAS (Creational Pattern)
클래스나 객체들이 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴	클래스나 객체들을 조합하여 더 큰 쿠조로 만들 수 있게 해주는 패턴	객체의 생성과 관련된 패턴
- 책임 연쇄(Chain of Responsibility) - 커맨드(Command) - 인터프리터(Interpreter) - 반복자(Iterator) - 중개자(Mediator) - 메멘토(Memento) - 옵서버(Observer) - 상태(State) - 전략(Strategy) - 템플릿 메서드(Template Method) - 방문자(Vistor)	- 퍼싸드(Facade) - 플라이웨이트(Flyweight) - 컴포지트(Composite) - 프록시(Proxy) - 브리지(Bridge) - 데코레이터(Decorator) - 어댑터(Adapter)	- 추상 팩토리(Abstract Factory) - 빌더(Builder) - 팩토리 메서드(Factory Method) - 프로토타입(Prototype) - 싱글톤(Singleton)

 

 

* 디자인 패턴 종류 설명

 

<행위 패턴>

- 커맨드

→ 위의 명령어를 각각 구현하는 것보다는, 하나의 추상 클래스에 메서드를 하나 만들고, 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행하는 것

→ 실현될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴

 

- Observer 패턴 (2020 실기 1회 기출문제)

→ 어떤 클래스에 변화가 일어났을 때, 이를 감지하여 다른 클래스에 통보해주는 것

→ 한 객체의 상태가 바뀌면, 그 객체에 의존하는 다른 객체들에게 연락이 가고 자동으로 내용이 갱신되는 패턴

 

- 템플릿 메소드

→ 상위 클래스에서는 추상적으로 표현하고, 그 구체적인 내용은 하위 클래스에서 결정되는 디자인 패턴

→ 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해, 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴

 

 

<구조 패턴>

- 어뎁터

→ 인터페이스가 호환되지 않는 클래스를 함께 이용할 수 있도록, 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움

 

- 브리지

→ 추상화와 구현을 분리해 둘을 각각 따로 발전시킬 수 있음

 

- 컴포지트

→ 0개, 1개 혹은 그 이상의 객체를 묶어 하나의 객체로 이용할 수 있음

→ 여러 개의 객체들로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별없이 다루게 해주는 패턴

 

- 데코레이터

→ 기존 객체의 메서드에 새로운 행동을 추가하거나 오버라이드 할 수 있음

 

- 퍼싸드

→ 많은 분량의 코드에 접근할 수 있는 단순한 인터페이스를 제공

 

- 플라이웨이트

→ 다수의 유사한 객체를 생성, 조작하는 비용을 절감할 수 있음

 

- 프록시

→ 접근 조절, 비용 절감, 복잡도 감소를 위해 접근이 힘든 객체에 대한 대역을 제공함

 

 

<생성 패턴>

- 추상 팩토리

→ 동일한 주체의 다른 팩토리를 묶어줌

→ 구체적인 클래스에 의지하지 않고, 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴

 

- 빌더

→ 생성과 표기를 분리해 복잡한 객체를 생성

 

- 팩토리 메서드

→ 생성할 객체의 클래스를 국한하지 않고 객체 생성

→ 객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴

→ 자식(하위) 클래스가 어떤 객체를 생성할지를 결정하도록 하는 패턴이기도 하다.

 

- 프로토타입

→ 기존 객체를 복제함으로써 객체 생성

 

- 싱글톤

→ 한 클래스에 한 객체만 존재하도록 제한

→ 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든 참조할 수 있도록하는 패턴

 

 

4) 팬 인 팬 아웃 (2020 실기 1회 기출문제)

- 소프트웨어의 구성 요소인 모듈을 계층적으로 분석하기 위해 팬 인, 팬 아웃 활용

- 팬 인 : 어떤 모듈을 제어하는 수, 해당 모듈로 들어오는 모듈의 수

- 팬 아웃 : 어떤 모듈에 의해 제어되는 수, 해당 모듈에서 나가는 모듈의 수

 

 

* 공통 모듈 테스트 : 화이트 박스 테스트// IDE 도구를 활용하여 디버깅 진행

- 화이트박스 검사

: 내부 소스코드를 확인하며, 의도한 설계 흐름에 따라 코드가 실행되는지, 실행 흐름에서 벗어나 불필요한 코드는 없는지 살펴본다. + 프로그램 로직을 이해하고, 내부 구조와 동작을 검사하는 테스트 기법

 

- 블랙박스 검사

: (내부코드를 보지 않고) 사용자 요구사항 시점에서 기능이 잘 작동하는지 살펴봄 + 인터페이스 오류, 입력값에 목표 결과값이 나오는지 등을 봄

- JUnit : 자바 프로그래밍 언어용 단위 테스트 도구

- 어노테이션 : 주석을 달아 특별한 의미를 부여하는 메타데이터

 

 

* Assert 메소드

- JUnit에서 가장 많이 이용되는 단정(Assert) 메소드

- assertEquals(a,b) : 객체 a와 b가 일치함을 확인 (객체의 내용)

- assertSame(a,b) : 객체 a와 b가 같은 객체임을 확인 (객체 자체)

 

 

5) 배치 프로그램

* 배치 프로그램 : 사용자와 상호작용 없이 일련의 작업을 작업 단위로 묶어 정기적으로 반복 수행하는 일괄 처리 방법

* 배치 스케줄러 : 일괄 처리를 위해 주기적으로 발생시키는 작업 지원 도구

 

- 스프링 배치 : 대용량 처리를 제공하는 스케줄러

- 쿼츠 스케줄링 : 플러그인을 통해 유연성을 제공하는 오픈 소스 기반 스케줄러

- Cron 표현식 : 스케줄러를 실행시키기 위해 작업이 실행되는 주기를 설정하는 표현식

- Cron 표현식 순서 : 초 분 시 일 월 요일 연도

- 특수문자 의미

(1) * : 모든 값

(2) ? : 특정 값이 없음

(3) - : 범위를 뜻함  (ex) 월요일에서 수요일까지는 MON-WED로 표현

(4) , : 특별한 값일 때만 동작  (ex) 월, 수, 금 MON WED, FRI

(5) / : 시작시간 / 단위  (ex) 0분부터 매 5분  0/5

(6) L : 일에서 사용하면 마지막 일, 요일에서는 마지막 요일 (토요일)

(7) W : 가장 가까운 평일  (ex) 15W는 15일에서 가장 가까운 평일 (월~금)을 찾음

(8) # : 몇째주의 무슨 요일을 표현  (ex) 3#2 : 2번째주 수요일

 

ex)

CRON 표현식	빈도
0 0/5 * * * ?	5분마다
0 0 12 * * ?	매일 낮 12시에
0 15 10 ? * *	매일 오전 10시 15분에
0 15 10 * * ? *	매일 오전 10시 15분에
0 15 10 * * ? 2015	2015년 동안 매일 오전 10시 15분에
0 * 14 * * ?	매일 오후 2시에 시작해서 매 분마다 실행하고 오후 2시 59에 끝남
0 0/5 14,18 * * ?	매일 오후 2시에 시작해서 5분마다 실행되어 오후 2시 55분에 끝나고, 오후 6시에 시작해서 5분마다 실행되어 오후 6시 55분에 끝남
0 0 5 14 * * ?	매일 오후 2시에 시작해서 매 분마다 실행하고 오후 2시 5분에 끝남
0 10,44 14 ? 3 WED	3월 동안 매주 수요일 오후 2시 10분과 2시 44분에
0 15 10 ? * MON-FRI	주중 오전 10시 15분에
0 15 10 15 * ?	매달 15일 오전 10시 15분에
0 15 10 L * ?	매월 말일 오전 10시 15분에
0 15 10 ? * 6L	매월 마지막 금요일 오전 10:15에
0 15 10 ? * 6L 2014-2017	2014년부터 2017년 매월 마지막 금요일 오전 10시 15분에
0 15 10 ? 6 3	매월 세 번째 금요일 오전 10:15에
0 0 12 1/5 * ?	해당 월의 첫날부터 시작하여 매월 5일 마다 평일 정오에
0 11 11 11 11 ?	11월 11일 오전 11시 11분 마다

 

 

- 유형 : 이벤트 배치, 온디멘드 배치, 정기 배치  이온정

- 온디멘드 배치 : 사용자의 명시적 요구가 있을 때마다 실행하는 방법

- 정기 배치 : 정해진 시점(주로 야간)에 실행하는 배치

 

 

* 배치 프로그램이 가지는 필수 요소

>> 배치 프로그램 : 컴퓨터 프로그램 흐름에 따라 순차적으로 자료를 처리하는 방식 

- 초기의 프로그램 방식은 사용자와 상호작용하는 것이 불가능했지만, 운영체제가 발전함에 따라 프로그램 입출력을 통해 상호작용하는 것이 가능해짐

- 즉, 개별적으로 어떤 요청이 있을 때마다 실시간으로 통신하는 것이 아닌, 한꺼번에 일괄적으로 대량 건을 처리하는 것

- 보통 정해진 특정한 시간에 실시함

- 사용하는 이유 : 업무의 효율성과 비효율적인 시스템의 과부하를 줄이기 위해  대자견안성

- 대용량 데이터 : 대용량의 데이터를 처리할 수 있어야 함

- 자동화 : 심각한 오류 상황 외에는 사용자의 개입없이 동작해야 함

- 견고성 : 유효하지 않은 데이터의 경우도 처리해서, 비정상적인 동작 중단이 발생하지 않아야 함.

- 안정성 : 어떤 문제가 생겼는지 언제 발생했는지 등을 추적할 수 있어야 함

- 성능 : 주어진 시간 내에 처리를 완료할 수 있어야 하고, 동시에 동작하고 있는 다른 애플리케이션을 방해하지 말아야 함.