정보처리기사 - 서버 프로그램 구현 #70~72
2023. 8. 19. 12:05ㆍ자격증/정보처리기사
70. 개발 환경 구축
70.1 개발 환경 구축
응용 소프트웨어 개발을 위해 개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것
- 개발 환경은 응용 소프트웨어가 운영될 환경과 유사한 구조로 구축
- 분석 단계의 산출물을 바탕으로 개발에 필요한 하드웨어와 소프트웨어를 선정
- 하드웨어와 소프트웨어의 성능, 편리성, 라이선스 등 비즈니스 환경에 적합한 제품들을 최종적으로 결정하여 구축
70.2 하드웨어 환경
사용자와의 인터페이스 역할을 하는 클라이언트(Client) 그리고 클라이언트와 통신하여 서비스를 제공하는 서버(Server)로 구성
- 클라이언트의 종류 : 개인용 컴퓨터(PC), 스마트폰 등
- 서버의 종류
종류 | 특징 |
---|---|
웹 서버 (Web Server) |
- 클라이언트로부터 직접 요청을 받아 처리 - 저용량의 정적 파일들을 제공 |
웹 애플리케이션 서버 (WAS; Web Application Server) |
동적 서비스를 제공하거나, 웹 서버와 데이터베이스 서버 또는 웹 서버와 파일 서버 사이에서 인터페이스 역할을 수행 |
데이터베이스 서버 (DB Server) |
데이터베이스와 이를 관리하는 DBMS를 운영 |
파일 서버 (File Server) |
데이터베이스에 저장하기에는 비효율적이거나, 서비스 제공을 목적으로 유지하는 파일들을 저장 |
- 정적 파일(Static File) : 인터넷 브라우저와 같은 클라이언트에서 별도의 처리 과정 없이 다운로드하여 사용자에게 보여주는 파일로, HTML, CSS, 이미지 파일 등이 존재
- 동적 서비스(Dynamic Service) : 사용자의 입력에 따라 다른 결과를 보여주는 서비스
70.3 소프트웨어 환경
클라이언트와 서버 운영을 위한 시스템 소프트웨어와 개발에 사용되는 개발 소프트웨어로 구성
- 시스템 소프트웨어의 종류 : 운영체제(OS), 웹 서버 및 WAS 운용을 위한 서버 프로그램, DBMS 등
- 개발 소프트웨어의 종류
종류 | 특징 |
---|---|
요구사항 관리 도구 | 요구사항의 수집과 분석, 추적 등을 편리하게 도와주는 소프트웨어 |
설계/모델링 도구 | UML(통합 모델링 언어)을 지원하며, 개발의 전 과정에서 설계 및 모델링을 도와주는 소프트웨어 |
구현 도구 | 개발 언어를 통해 애플리케이션의 실제 구현을 지원하는 소프트웨어 |
빌드 도구 | 구현 도구를 통해 작성된 소스의 빌드 및 배포, 라이브러리 관리를 지원하는 소프트웨어 |
테스트 도구 | 모듈들이 요구사항에 적합하게 구현되었는지 테스트하는 소프트웨어 |
형상 관리 도구 | 산출물들을 버전별로 관리하여 품질 향상을 지원하는 소프트웨어 |
- 형상 관리 도구 : 다른말로 버전 관리 도구라고도 함
70.4 웹 서버(Web Server)의 기능
기능 | 내용 |
---|---|
HTTP/HTTPS 지원 | 브라우저로부터 요청을 받아 응답할 때 사용되는 프로토콜 |
통신 기록 (Communication Log) |
처리한 요청들을 로그 파일로 기록하는 기능 |
정적 파일 관리 (Managing Static Files) |
HTML, CSS, 이미지 등의 정적 파일들을 저장하고 관리하는 기능 |
대역폭 제한 (Bandwidth Throttling) |
네트워크 트래픽의 포화를 방지하기 위해 응답 속도를 제한하는 기능 |
가상 호스팅 (Virtual Hosting) |
하나의 서버로 여러 개의 도메인 이름을 연결하는 기능 |
인증 (Authentication) |
사용자가 합법적인 사용자인지를 확인하는 기능 |
- HTTP/HTTPS(HyperText Transfer Protocol [Secure]) : HTTP는 하이퍼텍스트 문서를 전송하기 위해 사용되는 프로토콜이고, HTTPS는 HTTP에 보안 모듈을 결합시킨 프로토콜
70.5 개발 언어의 선정 기준
기준 | 내용 |
---|---|
적정성 | 개발하려는 소프트웨어의 목적에 적합해야 함 |
효율성 | 코드의 작성 및 구현이 효율적이어야 함 |
이식성 | 다양한 시스템 및 환경에 적용이 가능해야 함 |
친밀성 | 개발 언어에 대한 개발자들의 이해도와 활용도가 높아야 함 |
범용성 | 다른 개발 사례가 존재하고 여러 분야에서 활용되고 있어야 함 |
72. 소프트웨어 아키텍처
72.1 소프트웨어 아키텍처
소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
- 애플리케이션의 분할 방법과 분할된 모듈에 할당된 기능, 모듈 간의 인터페이스 등을 결정
- 소프트웨어 아키텍처 설계의 기본 원리에는 모듈화, 추상화, 단계적 분해, 정보은닉이 존재
71.2 모듈화(Modularity)
소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것을 의미
- 모듈(Module) : 전체 프로그램의 기능 중에서 특정 기능을 처리할 수 있는 소스 코드를 의미
- 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈 간의 통합 비용이 많이 듦
- 모듈의 크기를 너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만 모듈 하나의 개발 비용이 많이 듦
71.3 추상화(Abstraction)
문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것
- 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러가지 요인들을 테스트할 수 있음
- 추상화의 유형
유형 | 내용 |
---|---|
과정 추상화 | 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법 |
데이터 추상화 | 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법 |
제어 추상화 | 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법 |
71.4 단계적 분해(Stepwise Refinement)
문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
- Niklaus Wirth에 의해 제안된 하향식 설계 전략
- 소프트웨어의 포괄적인 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료 구조 등 상세한 내역은 가능한 한 뒤로 미루어 진행
71.5 정보 은닉(Information Hiding)
한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
- 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있음
- 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이
71.6 상위 설계와 하위 설계
소프트웨어 개발의 설계 단계는 크게 상위 설계와 하위 설계로 구분할 수 있음
구분 | 상위 설계 | 하위 설계 |
---|---|---|
별칭 | 아키텍처 설계, 예비 설계 | 모듈 설계, 상세 설계 |
설계 대상 | 시스템의 전체적인 구조 | 시스템의 내부 구조 및 행위 |
세부 목록 | 구조, DB, 인터페이스 | 컴포넌트, 자료 구조, 알고리즘 |
71.7 소프트웨어 아키텍처의 품질 속성
소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지 확인하기 위해 품질 평가 요소들을 구체화시켜 놓은 것
- 품질 평가 요소의 종류
종류 | 내용 |
---|---|
시스템 측면 | 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성 등 |
비즈니스 측면 | 시장 적시성, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정 등 |
아키텍처 측면 | 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 시험성 등 |
71.8 소프트웨어 아키텍처의 설계 과정
71.9 협약(Contract)에 의한 설계
컴포넌트를 설계할 때 클래스에 대한 여러 가정을 공유할 수 있도록 명세한 것
- 컴포넌트에 대한 정확한 인터페이스를 명세
- 명세에 포함될 조건
조건 | 내용 |
---|---|
선행 조건 (Precondition) |
오퍼레이션이 호출되기 전에 참이 되어야 할 조건 |
결과 조건 (Postcondition) |
오퍼레이션이 수행된 후 만족되어야 할 조건 |
불변 조건 (Invariant) |
오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건 |
72. 아키텍처 패턴
72.1 아키텍처 패턴(Patterns)
아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시
- 아키텍처 패턴에는 서브시스템들과 그 역할이 정의되어 있음
- 서브시스템 사이의 관계와 여러 규칙·지침 등이 포함되어 있음
- 주요 아키텍처 패턴의 종류
- 레이어 패턴
- 클라이언트-서버 패턴
- 파이프-필터 패턴
- 모델-뷰-컨트롤러 패턴
72.2 레이어 패턴(Layers Pattern)
시스템을 계층으로 구분하여 구성하는 고전적인 방법의 패턴
- 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 됨
- 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어짐
- 대표적으로 OSI 참조 모델이 존재
72.3 클라이언트-서버 패턴(Client-Server Pattern)
하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
- 사용자가 클라이언트를 통해 서버에 요청하면 클라이언트가 응답을 받아 사용자에게 제공하는 방식
72.4 파이프-필터 패턴(Pipe-Filter Pattern)
데이터 스트림 절차와 각 단계를 필터로 캡슐화하여 파이프를 통해 전송하는 패턴
- 앞 시스템의 처리 결과물을 파이프를 통해 전달받아 처리한 후 그 결과물을 다시 파이프를 통해 다음 시스템으로 넘겨주는 패턴을 반복
- 데이터 변환, 버퍼링, 동기화 등에 주로 사용
- 대표적으로 UNIX의 쉘(Shell) 존재
72.5 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)
서브시스템을 모델, 뷰, 컨트롤러로 구조화하는 패턴
- 컨트롤러가 사용자의 요청을 받으면 핵심 기능과 데이터를 보관하는 모델을 이용하여 뷰에 정보를 출력하는 구조
- 여러 개의 뷰를 만들 수 있음
- 한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합
72.6 기타 패턴
종류 | 내용 |
---|---|
마스터-슬레이브 패턴 (Master-Slave Pattern) |
- 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴 - 예) 장애 허용 시스템, 병렬 컴퓨팅 시스템 |
브로커 패턴 (Broker Pattern) |
- 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결해주는 패턴 - 예) 분산 환경 시스템 |
피어-투-피어 패턴 (Peer-To-Peer Pattern) |
- 피어(Peer)라 불리는 하나의 컴포넌트가 클라이언트가 될 수도, 서버가 될 수도 있는 패턴 - 예) 파일 공유 네트워크 |
이벤트-버스 패턴 (Event-Bus Pattern) |
소스가 특정 채널에 이벤트 메시지를 발행(Publish)하면, 해당 채널을 구독(Subscribe)한 리스너(Listener)들이 메시지를 받아 이벤트를 처리하는 패턴- 예) 알림 서비스 |
블랙보드 패턴 (Blackboard Pattern) |
- 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 패턴 - 예) 음성 인식, 차량 식별, 신호 해석 |
인터프리터 패턴 (Interpreter Pattern) |
- 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성된 패턴 - 예) 번역기, 컴파일러, 인터프리터 |
'자격증 > 정보처리기사' 카테고리의 다른 글
정보처리기사 - 서버 프로그램 구현 #76~79 (0) | 2023.08.19 |
---|---|
정보처리기사 - 서버 프로그램 구현 #73~75 (0) | 2023.08.19 |
정보처리기사 - 통합 구현 #64~69 (0) | 2023.08.19 |
정보처리기사 - 데이터 입출력 구현 #61~63 (0) | 2023.08.19 |
정보처리기사 - 데이터 입출력 구현 #58~60 (0) | 2023.08.19 |