[정보처리기사] 04. 서버 프로그램 구현

(1)  개발 환경 구축

개발 환경 구축

• 응용 소프트웨어 개발을 위해 개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것
• 개발 환경은 응용 소프트웨어가 운영될 환경과 유사한 구조로 구축한다
• 분석 단계의 산출물을 바탕으로 개발에 필요한 하드웨어와 소프트웨어를 선정한다
• 하드웨어와 소프트웨어의 성능, 편의성, 라이선스 등의 비지니스 환경에 적합한 제품들을 최종적으로 결정하여 구축한다

하드웨어 환경

• 사용자의 인터페이스 역할을 하는 클라이언트(Client) 그리고 클라이언트와 통신하여 서비스를 제공하는 서버(Server)로 구성된다
• 클라이언트의 종류 : 개인용 컴퓨터(PC), 스마트폰 등
• 서버의 종류

 

소프트웨어 환경

• 클라이언트 서버 운영을 위한 시스템 소프트웨어와 개발에 사용되는 개발 소프트웨어로 구성된다
• 시스템 소프트웨어의 종류 : 운영체제(OS), 웹 서버 및 WAS 운용을 위한 서버 프로그램, DBMS 등
• 개발 소프트웨어의 종류

 

웹 서버(Web Server)의 기능

 

개발 언어의 선정 기준

 

(2) 소프트웨어 아키텍처

소프트웨어 아키텍처

• 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
• 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정한다
• 소프트웨어 아키텍처 설계에 기본 원리에는 모듈화, 추상화, 단계적 분해, 정보 은닉이 있다

모듈화(Modularity)

• 소프트웨어의 성능 향상, 시스템의 수정 및 재샤용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것
• 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈 간의 통합 비용이 많이 든다
• 모듈의 크기를 너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만, 모듈 하나의 개발 비용이 많이 든다

추상화(Abstraction)

• 문제의 전체적이고 포괄적인 개념을 설계한 후, 차례로 세분화하여 구체화시켜 나가는 것
• 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테스트할 수 있다
• 추상화의 유형

 

단계적 분해(Stepwise Refinement)

• 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
• Nikalus Wirth에 의해 제안된 하향식 설계 전략
• 소프트웨어의 포괄적인 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료 구조 등 상세한 내역은 가능한 한 뒤로 미루어 진행한다

정보 은닉(Information Hiding)

• 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
• 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있다
• 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이하다

상위 설계와 하위 설계

 

소프트웨어 아키텍처의 품질 속성

• 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지 확인하기 위해 품질 평가 요소들을 구체화 시켜 놓은 것
• 품질 평가 요소의 종류

 

소프트웨어 아키텍처의 설계 과정

 

협약(Contract)에 의한 설계

• 컴포넌트를 설계할 때 클래스에 대한 여러 가정을 공유할 수 있도록 명세한 것
• 컴포넌트에 대한 정확한 인터페이스를 명시한다
• 명세에 포함될 조건

 

(3) 아키텍처 패턴

아키텍처 패턴(Patterns)

• 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
• 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시한다
• 아키텍처 패턴에는 서브 시스템들과 그 역할이 정의되어 있다
• 서브 시스템 사이의 관계와 여러 규칙·지침 등이 포함되어 있다
• 주요 아키텍처 패턴의 종류
  • 레이어 패턴
  • 클라이언트-서버 패턴
  • 파이프-필터 패턴
  • 모델-뷰-컨트롤러 패턴

레이어 패턴(Layer Pattern)

• 시스템을 계층으로 구분하여 구성하는 고전적인 방법의 패턴
• 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 사위 계층의 클라이언트가 된다
• 서로 마주보는 2개의 계층 사이에서만 상호작용이 이루어진다
• 대표적으로 OSI 참조 모델이 있다

 

클라이언트-서버 패턴(Client-Server Pattern)

• 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
• 사용자 클라이언트를 통해 서버에 요청하면 클라이언트가 응답을 받아 사용자에게 제공하는 방식

 

파이프-필터 패턴(Pipe-Filter Pattern)

• 데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프를 통해 전송하는 패턴
• 앞 시스템의 처리 결과물을 파이프를 통해 전닯다아 처리한 후, 그 결과물을 다시 파이프를 통해 다음 시스템으로 넘겨주는 패턴을 반복한다
• 데이터 변환, 버퍼링, 동기화 등에 주로 사용된다
• 대표적으로 UNIX의 쉘(Shell)에 있다

 

모델-뷰-컨트롤러(Model-View-Controller Pattern)

• 서브 시스템을 모델, 뷰, 컨트롤러로 구조화하는 패턴
• 컨트롤러가 사용자의 요청을 받으면 핵심 기능과 데이터를 보관하는 모델을 이용하여 뷰에 정보를 출력하는 구조
• 여러 개의 뷰를 만들 수 있다
• 한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합하다

 

기타 패턴

 

(4) 객체 지향(Object-Oriented)

객체 지향

• 소프트웨어의 각 요소들을 객체(Object)로 만든 후, 객체들을 조립해서 소프트웨어를 개발하는 기법
• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용되고 있다
• 소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게개발할 수 있고, 유지보수가 쉽다
• 객체 지향의 구성 요소
  • 객체(Object)
  • 클래스(Class)
  • 메시지(Message)
• 객체 지향의 특징
  • 캡슐화(Encapsulation)
  • 상속(Inheritance)
  • 다형성(Polymorphism)
  • 연관성(Relationship)

객체(Object)

• 데이터와 이를 처리하기 위한 함수를 묶어 놓은 소프트웨어 모듈

 

클래스(Class)

• 공통된 속성과 연산을 갖는 객체의 집합
• 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 툴
• 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 한다

메시지(Message)

• 객체들 간의 상호작요에 사용되는 수단으로, 객체의 동작이나 연산을 일으키는 외부의 요구 사항
• 메시지를 받은 객체는 대응하는 연산을 수행하여 예상된 결과를 반환한다

캡슐화(Encapsulation)

• 외부에서 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것
• 캡슐화된 객체는 외부 모듈의 변경으로 인한 파급 효과가 적다
• 객체들 간에 메시지를 주고 받을 때, 상대 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고, 객체 간의 결합도가 낮아진다

상속(Inheritance)

• 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
• 하위 클래스는 물려받은 속성과 연산을 다시 정의하지 않아도 즉시 자신의 속성으로 사용할 수 있다
• 하위 클래스는 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있다

다형성(Polymorphism)

• 하나의 메세지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
• 객체들은 동일한 메소드명을 사용하며, 같은 의미의 응답을 한다
• 예) '+' 연산자의 경우, 숫자 클래스에서는 덧셈, 문자 클래스에서는 문자열의 연결 기능으로 사용된다

연관성(Relationship)

• 두 개 이상의 객체들이 상호 참조하는 관계
• 연관성의 종류

 

(5) 객체 지향 분석 및 설계

객체 지향 분석(OOA; Object Oriented Analysis)

• 사용자의 요구사항과 관련된 객체, 속성, 연산, 관계 등을 정의하여 모델링하는 작업
• 개발을 위한 업무를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석한다
• 클래스를 식별하는 것이 객체 지향 분석의 주요 목적이다

객체 지향 분석의 방법론

 

럼바우(Rumbaugh)의 분석 기법

• 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법
• 객체 모델링 기법(OMT; Object-Modeling Technique)이라고도 한다
• 분석 활동은 '객체 모델링 → 동적 모델링 → 기능 모델링' 순으로 이러우 진다

※ 객동기

 

객체 지향 설계 원칙

• 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야 할 원칙
• SRP, OCP, LSP, ISP, DIP의 다섯가지 원칙의 앞 글자를 따 SOLID 원칙 이라고 부른다
• 객체 지향 설계 원칙의 종류

 

(6) 모듈

모듈(Module)

• 모듈화를 통해 분리된 시스템의 각 기능으로, 서브루틴, 서브 시스템, 소프트웨어 내의 프로그램, 작업 단위 등을 의미한다
• 모듈의 기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 서로 독립적임을 의미한다
• 모듈의 독립성은 결합도(Coupling)와 응집도(Cohesion)에 의해 측정된다

모듈의 독립성

• 모듈의 독립성은 모듈이 다른 모듈과의 과도한 상호작용을 배제하고, 하나의 기능만을 수행함으로써 이루어진다
• 독립성을 높이려면 모듈의 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 한다

결합도(Coupling)

• 모듈 간의 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계
• 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮다
• 결합도의 종류와 강도

 

결합도의 종류

 

응집도(Cohesion)

• 모듈의 내부 요소들이 서로 연관되어 있는 정도
• 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮다
• 응집도의 종류와 강도

 

응집도의 종류

 

팬인(Fan-In) / 팬아웃(Fan-Out)

• 팬인(Fan-In) : 어떤 모듈을 제외하는 모듈의 수
• 팬아웃(Fan-Out) : 어떤 모듈에 의해 제어되는 모듈의 수
• 팬인이 높다는 것은 재사용 측면에서 설계가 잘 되어있다고 볼 수 있다
• 팬인이 높은 경우, 단일 장애점이 발생할 수 있으므로 중점적인 관리 및 테스트가 필요하다
  • 단일 장애점(SPOF, Single Point Of Failure) : 시스템의 구성 요소 중 동작하지 않으면 전체 시스템이 중단되어 버리는 요소를 의미하며, 단일 실패점이라고도 한다

예제 : 다음의 시스템 구조도에서 각 모듈의 팬인(Fan-In)과 팬아웃(Fan-Out)을 구하시오

• 팬인(Fan-In)
  • A : 0
  • B · C · D · E · G : 1
  • F · H · I : 2
• 팬아웃(Fan-Out)
  • H · I : 0
  • C · E · F · G : 1
  • B · D : 2
  • A : 3

※ 모듈에 들어오면(In) 팬인, 모듈에서 나가면(Out) 팬아웃

 

N-S 차트(Nassi-Schneiderman Chart)

• 논리의 기술에 중점을 두고 도형을 이용해 표현하는 방법
• 박스 다이어그램, Chapin Chart라고도 한다
• GOTO나 화살표를 사용하지 않는다
• 연속, 선택 및 다중 선택, 반복의 3가지 제어 논리 구조로 표현한다
• 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합하다

(7) 단위 모듈

단위 모듈(Unit Module)

• 소프트웨어 구현에 필요한 여러 동작 중, 한 가지 동작을 수행하는 기능을 모듈로 구현한 것
• 단위 모듈로 구현되는 하나의 기능을 단위 기능이라고 부른다
• 독립적인 컴파일이 가능하며, 다른 모듈에 호출되거나 삽입되기도 한다
• 단위 모듈의 구현 과정

 

IPC(Inter-Process Communication)

• 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합
• 복수의 프로세스를 수행하며 이뤄지는 프로세스 간 통신까지 구현이 가능하다
• IPC의 대표 메소드 5가지

 

단위 모듈 테스트

• 프로그램의 단위 기능으로 구현된 모듈이 정해진 기능을 정확히 수행하는지 검증하는 것
• 단위 테스트(Unit Test)라고도 불린다
• 단위 모듈 테스트의 기준은 단위 모듈에 대한 코드이므로, 시스템 수준의 오류는 잡아낼 수 없다

테스트 케이스(TestCase)

• 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위한 테스트 항목에 대한 명세서
• 테스트 케이스를 이용하지 않은 테스트는 특정 요소에 대한 검증이 누락되거나 불필요한 검증의 반복으로 인해 인력과 시간을 낭비할 수 있다
• ISO/IEC/IEEE 29119-3 표준에 따른 테스트 케이스의 구성 요소

 

(8) 공통 모듈

공통 모듈

• 여러 프로그램에서 공통으로 사용할 수 있는 모듈
• 자주 사용되는 계산식이나 매번 필요한 사용자 인증과 같은 기능들이 공통 모듈로 구성될 수 있다
• 공통 모듈을 구현할 때는 해당 기능을 명확히 이해할 수 있도록 명세 기법을 준수해야 한다

공통 모듈 명세 기법의 종류

 

재사용(Reuse)

• 이미 개발된 기능들을 새로운 시스템이나 기능 개발에 사용하기 적합하도록 최적화하는 작업
• 새로 개발하는데 필요한 비용과 시간을 절약할 수 있다
• 누구나 이해할 수 있고, 사용이 가능하도록 사용법을 공개해야 한다
• 재사용 규모에 따른 분류

 

효과적인 모듈 설계 방안

• 결합도는 줄이고, 응집도는 높여서 모듈의 독립성과 재사용을 높인다
• 복잡도와 중복성을 줄이고, 일관성을 유지시킨다
• 모듈의 기능은 예측이 가능해야 하며, 지나치게 제한적이어서는 안된다
• 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해한다
• 효과적인 제어를 위해 모듈 간의 계층 관계를 정의하는 자료가 제시되어야 한다

(9) 코드

코드(Code)

• 자료의 분류 · 조합 · 집계 · 추출을 용이하게 하기 위해 사용하는 기호
• 정보를 신속 · 정확 · 명료하게 전달할 수 있게 한다
• 일정한 규칙에 따라 작성된다
• 정보 처리의 효율과 처리된 정보의 가치에 많은 영향을 미친다

코드의 주요 기능

 

코드의 종류

종류	내용
순차 코드 (Sequence Code)	- 자료의 발생 순서, 크기 순서 등을 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여하는 방법 - 순서 코드 또는 일련번호 코드라고도 함 - 예) 1, 2, 3, 4, ...
블록 코드 (Block Code)	- 코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 방법 - 구분 코드라고도 함 - 예) 1001~1100 : 총무부, 1101~1200 : 영업부
10진 코드 (Decimal Code)	- 코드화 대상 항목을 0~9까지 10진 분할하고, 다시 그 각각에 대하여 10진 분할하는 방법을 필요한만큼 반복하는 방법 - 도서 분류식 코드라고도 함 - 예) 1000 : 공항, 1100 : 소프트웨어 공학, 1110 : 소프트웨어 설계
그룹 분류 코드 (Group Classification Code)	- 코드화 대상 항목을 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고, 각 그룹 안에서 일련번호를 부여하는 방법 - 예) 1-01-001 : 본사-총무부-인사계, 2-01-001 : 지사-총무부-인사계
연상 코드 (Mnemonic Code)	- 코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용하여 코드를 부여하는 방법 - 예) TV-40 : 40인치 TV, L-15-220 : 15W 220V의 램프
표의 숫자 코드 (Significant Digit Code)	- 코드화 대상 항목의 성질, 즉 길이, 넓이, 부피, 지름, 높이 등의 물리적 수치를 그대로 코드에 적용시키는 방법 - 유효 숫자 코드라고도 함 - 예) 120-720-1500 : 두께x폭x길이가 120x720x1500인 강판
합성 코드 (Combined Code)	- 필요한 기능을 하나의 코드로 수행하기 어려운 경우, 2개 이상의 코드를 조합하여 만드는 방법 - 예) 연상 코드 + 순차 코드        KE-711 : 대한항공 711기, AC-253 : 에어캐나다 253기

 

(10) 디자인 패턴

디자인 패턴(Design Pattern)

• 모듈 간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
• 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드 등으로 구성되어 있다
• '바퀴를 다시 발명하지 말라(Don't reinvent the wheel)' 라는 말과 같이, 개발 과정 중에 문제가 발생하면 새로 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적이다
• GOF의 디자인 패턴은 생성 패턴, 구조 패턴, 행위 패턴으로 구분된다

생성 패턴(Creational Pattern)

• 클래스나 객체의 생성과 참조 과정을 정의하는 패턴

 

구조 패턴(Structual Pattern)

• 구조가 복잡한 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴

 

행위 패턴(Behavioral Pattern)

• 구조가 복잡하 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴

*추상 클래스(Abstract Class)

- 구체 클래스에서 구현하려는 기능들의 공통점만을 모아 추상화한 클래스

- 인스턴스 생성이 불가능하므로 구체 클래스가 추상 클래스를 상속받아 구체화한 후, 구체 클래스의 인스턴스를 생성하는 방식으로 사용한다

 

*구체 클래스(Concrete Class)

- 인스턴스 생성이 가능한 일반적인 클래스를 의미하는 용어

- 추상 클래스와 구분하기 위해 사용된다

- 구상 클래스 또는 구현 클래스라고도 한다

 

(11) 개발 지원 도구

통합 개발 환경(IDE; Integrated Development Environment)

• 개발에 필요한 환경, 즉 편집기(Editor), 컴파일러(Compiler), 디버거(Debugger) 등의 다양한 툴을 하나의 인터페이스로 통합하여 제공하는 환경
• 통합 개발 환경을 제공하는 소프트웨어를 의미한다
• 코드를 실행하거나 테스트할 때 오류가 발생한 부분을 시각화하므로 수정이 용이하다

통합 개발 환경 도구의 종류

 

빌드 도구

• 빌드 : 소스 코드 파일들을 컴퓨터에서 실행할 수 있는 제품 소프트웨어로 변환하는 과정 또는 결과물
• 빌드 도구는 전처리(Preprocessing), 컴파일(Compile) 등의 작업을 수행한다
  • 전처리(Preprocessing) : 컴파일에 앞서 코드에 삽입된 주석을 제거하거나 매크로들을 처리하는 과정
• 대표적인 빌드 도구

*그루비(Groovy) : 자바를 기반으로 여러 프로그래밍 언어들의 장점을 모아 만든 동적 객체지향 프로그래밍 언어

 

기타 협업 도구

• 협업 도구 : 개발에 참여하는 사람들이 서로 다른 작업 환경에서 원활히 프로젝트를 수행할 수 있도록 도와주는 도구
• 협업 소프트웨어, 그룹웨어(Groupware) 등으로 불린다
• 일정 관리, 업무흐름 관리, 정보 공유, 커뮤니케이션 등의 업무 보조 도구가 포함된다

(12) 서버 개발

서버 개발

• 웹 애플리케이션의 로직을 구현할 서버 프로그램을 제작하여 웹 어플리케이션 서버(WAS)에 탑재하는 것
• 서버 개발에 사용되는 프로그래밍 언어는 Java, JavaScript, Python, PHP, Ruby등이 있다
• 각 프로그래밍 언어에는 해당 언어로 서버 프로그램을 개발할 수 있도록 지원하는 프레임워크가 있다

서버 개발 프레임워크

• 서버 프로그램 개발 시 다양한 네트워크 설정, 요청 및 응답 처리, 아키텍처 모델 구현 등을 손쉽게 처리할 수 있도록 클래스나 인터페이스를 제공하는 소프트웨어
• 서버 개발 프레임워크의 대부분은 모델-뷰-컨트롤러(MVC) 패탠을 기반으로 개발되었다
• 서버 개발 프레임워크의 종류

 

서버 개발 과정

• 서버 개발 과정은 DTO/VO, SQL, DAO, Service, Controller를 각각 구현하는 과정이다
  • DTO(Data Transfer  Object) : 데이터의 교환을 위해 생성되는 객체
  • VO(Value Object) : DTO와 동일하지만 읽기만 가능한객체, 변경이 불가능함
  • DAO(Data Access Object) :  데이터베이스에 접근하여 데이터를 조회, 생성, 수정, 삭제 작업을 수행하는 객체
• 구현 순서는 개발자가 임의로 변경할 수 있다
• 개발하려는 서버 프로그램의 목적, 개발 언어, 규모 등의 이유로 통합하거나 세분화할 수 있다
• 구현 과정

예제 : 다음은 서버 개발 과정을 도식화한 것이다. 각 개체 간 메시지 및 자료의 흐름을 확인하시오

 

 

(13) 보안 및 API

소프트웨어 개발 보안

• 소프트웨어 개발 과정에 발생할 수 있는보안취약점을 최소화하여 보안 위협으로부터 안전한 소프트웨어를 개발하기 위한 일련의 보안 활동
• 데이터의 기밀성(Confidentiality), 무결성(Integrity), 가용성(Availability) 등의 보안 요소를 충족시키는 것을 목표로 한다
• 정부에서 제공하는 소프트웨어 개발 보안 가이드를 참고하여 소프트웨어 개발 과정에서 점검해야 할 보안 항목들을 점검한다

소프트웨어 개발 보안 점검 항목

 

API(Application Programming Interface)

• 응용 프로그램 개발 시, 운영체제나 프로그래밍 언어 등에 있는 라이브러리를 이용할 수 있도록 규칙 등을정의해 놓은 인터페이스
• 라이브러리에 있는 다양한 기능들을 손쉽게 이용할 수 있도록 도와주므로 효율적인 개발이 가능하다
• 누구나 무료로 사용할 수 있게 공개된 API를 Open API라고 한다
• API의 종류
  • Windows API
  • 단일 유닉스 규격(SUS)
  • Java API
  • 웹 API

(14) 배치 프로그램

배치 프로그램(Batch Program)

• 사용자와의 상호 작용 없이 여러 작업들을 미리 정해진 일련의 순서에 따라 일괄적으로 처리하도록 만든 프로그램
• 배치 프로그램의 필수 요소

 

배치 스케쥴러(Batch Scheduler)

• 일괄 처리(Batch Processing) 작업이 설정된 주기에 맞춰 자동으로 수행되도록 지원해주는 도구
• 특정 업무(Job)를 원하는 시간에 처리할 수 있도록 지원한다는 특성 때문에 잡 스케쥴러(Job Scheduler)라고도 불린다
• 배치 스케쥴러의 종류

 

crontab 명령어 작성 방법

 

(15) 패키지 소프트웨어

패키지 소프트웨어(Package Software)

• 기업에서 일반적으로 사용하는 여러 기능을 통합하여 제공하는 소프트웨어
• 기업에서는 패키지 소프트웨어를 구입하여 기업 환경에 적합하게 커스터마이징(Customizing)하여 사용한다
• 패키지 소프트웨어를 이용하여 시스템을 구축하는 방식을 패키지 개발 방식이라고 한다
• 기능 요구사항을 70% 이상 충족시키는 패키지 소프트웨어가 있을 때만 사용하는 것이 적합하다
• 업무 특성에 맞게 전용으로 개발되는 소프트웨어와 비교하여 안정성, 라이선스, 생산성 등에서 차이가 있다

패키지 소프트웨어와 전용 개발 소프트웨어의 비교

*전용 개발 소프트웨어 : 패키지 소프트웨어에 대응되는 용어로, 사업 환경에 맞춰 직접 개발한 소프트웨어