[정보처리기사 실기] 5장 요약 키워드 정리 _ 서버 프로그램 구현

[5] 서버 프로그램 구현

 

5.1 개발 환경 구축

 

개발 환경 구축의 개요

- 응용 소프트웨어 개발을 위해 개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것. 

- 개발 환경은 응용 소프트웨어가 운영될 환경과 유사한 구조로 구축. 

- 개발 프로젝트의 분석 단계의 산출물을 바탕으로 개발에 필요한 하드웨어와 소프트웨어를 선정. 

- 하드웨어와 소프트웨어의 성능, 편의성, 라이선스 등의 비즈니스 환경에 적합한 제품들을 최종적으로 결정하여 구축

 

하드웨어 환경

- 사용자와의 인터페이스 역할을 하는 클라이언트 그리고 클라이언트와 통신하여 서비스를 제공하는 서버로 구성됨. 

- 클라이언트: PC, 스마트폰 등

- 서버: 사용 목적에 따라 웹서버, 웹어플리케이션 서버, 데이터베이스 서버, 파일 서버 등으로 나뉨. 

- 웹서버

• 클라이언트로 부터 직접 요청을 받아 처리하는 서버, 저용량의 정적 파일(HTML, CSS 등)들을 제공함.
• 기능: HTTP/HTTPS 지원(브라우저로부터 요청을 받아 응답할 때 사용되는 프로토콜), 통신 기록(처리한 요정들을 로그 파일로 기록하는 기능), 정적 파일 관리(HTML, CSS, 이미지 등의 정적 파일을 저장하고 관리하는 기능), 대역폭 제한(네트워크 트래픽의 포화를 방지하기 위해 응답 속도를 제한하는 기능), 가상 호스팅(하나의 서버로 여러개의 도메인 이름을 연결하는 기능), 인증(사용자가 합법적인 사용자인기 확인하는 기능)
• (예) Apache HTTP Server, Microsoft Internet Information Service, Google Web Server 등

- 웹 어플리케이션 서버(WAS)

• 사용자에게 동적 서비스(사용자의 입력에 따라 다른 결과를 보여주는 서비스)를 제공하기 위해 웹 서버로부터 요청을 받아 데이터 가공 작업을 수행하거나, 웹 서버와 데이터베이스 서버 또는 웹 서버와 파일 서버 사이에서 인터페이스 역할을 수행하는 서버. 
• (예) Apache Tomcat, IBM WebSphere, Oracle Weblogic 등

- 데이터베이스 서버

• 데이터베이스와 이를 관리하는 DBMS를 운영하는 서버
• (예) MySQL Server, Oracle Server, Microsoft Server 등

- 파일 서버

• 데이터베이스에 저장하기에는 비효율적이거나 서비스 제공을 목적으로 유지하는 파일들을 저장하는 서버
• (예) AWS S3 등

 

소프트웨어 환경

- 클라이언트와 서버 운영을 위한 시스템 소프트웨어와 개발에 사용되는 개발 소프트웨어로 구성. 

- 시스템 소프트웨어 종류: 운영체제, 웹서버 및 WAS 운용을 위한 서버 프로그램, DBMS 등

- 개발 소프트웨어 종류: 요구사항 관리 도구, 설계/모델링 도구, 구현 도구, 빌드 도구, 테스트 도구, 형상 관리 도구 등

- 요구사항 관리 도구

• 요구사항의 수집과 분석, 추적 등을 편하게 도와주는 소프트웨어
• (예) JIRA, IBM DOORS, inteGREAT, Reqtify, Trello 등

- 설계/모델링 도구

• UML(통합 모델링 언어)을 지원하며, 개발의 전 과정에서 설계 및 모델링을 도와주는 소프트웨어
• (예) DB Designer, PlantUML, ArgoUML 등

- 구현 도구

• 개발 언어를 통해 애플리케이션의 실제 구현을 지원하는 소프트웨어
• (예) Eclipse, IntelliJ IDEA, Visual Studio, Node.js, Netbeans

- 빌드 도구

• 구현 도구를 통해 작성된 소스의 빌드 및 배포, 라이브러리 관리를 지원하는 소프트웨어
• (예) Ant, Gradle, Maven, Jenkins

- 테스트 도구

• 모듈들이 요구사하에 적합하게 구현되었는지 테스트하는 소프트웨어
• (예) CppUnit, JUnit, HttpUnit, NUnit, SpringTest 등

- 형상 관리 도구

• 산출물을 버전별로 관리하여 품질 향상을 지원하는 소프트웨어
• (예) Git, CVS, Subversion, Mercurial

 

개발 언어의 선정 기준

- 적정성: 개발하려는 소프트웨어의 목적에 적합해야 함.

- 효율성: 코드의 작성 및 구현이 효율적이어야 함. 

- 이식성: 다양한 시스템 및 환경에 적용이 가능해야 함. 

- 친밀성: 개발 언어에 대한 개발자들의 이해도와 활용도가 높아야 함. 

- 범용성: 다른 개발 사례가 존재하고 여러 분야에서 활용되고 있어야 함. 

- 개발 언어를 선정할라는디 적이친범효~! 

 

5.2 모듈 

 

모듈의 개요

- 모듈화(시스템 재사용, 유지 관리가 용이하도록 시스템의 기능들을 모듈 단위로 분해하는 것)를 통해 분리된 시스템의 각 기능들로, 서브루틴(메인 루틴에 의해 필요할 때마다 호출되는 루틴), 서브시스템(단위시스템), 소프트웨어 내의 프로그램, 작업 단위 등과 같은 의미로 사용됨. 

- 단독으로 컴파일이 가능하며 재사용 할 수 있음. 

- 모듈의 기능적 독립성: 소프트웨어를 구성하는 각 모듈의 기능이 서로 독립됨을 의미. 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함으로 이루어짐.

- 독립성이 높은 모듈일수록 모듈을 수정하더라도 다른 모듈들에게는 거의 영향을 미치지 않으며, 오류가 발생해도 쉽게 발견하고 해결할 수 있음. 

- 모듈의 독립성은 결합도와 응집도에 의해 측정되며, 독립성을 높이려면 모듈의 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 함. 

 

결합도(Coupling)

- 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계

- 다양한 결합으로 모듈을 구성할 수 있으나 결합도가 약할 수록 품질이 높고, 강할수록 품질이 낮음. 

- 결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움. 

- 결합도의 종류: 자료 결합도, 스탬프 결합도, 제어 결합도, 외부 결합도, 공통 결합도, 내용 결합도

- 자료 결합도

• 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도. 
• 어떤 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨주고, 호출받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 방식. 
• 모듈 간의 내용을 전혀 알 필요가 없는 상태로서 한 모듈의 내용을 변경하더라도 다른 모듈에는 전혀 영향을 미치지 않는 가장 바람직한 결합도. 

- 스탬프 결합도

• 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도. 
• 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도이며, 자료 구조의 어떠한 변화, 즉 포맷이나 구조의 변화는 그것을 조회하는 모든 모듈 및 변화하는 필드를 실제로 조회하지 않는 모듈에까지도 영향을 미치게 됨. 

- 제어 결합도

• 어떤 모듈이 다른 모듈의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소(Function Code, Switch, Tag, Flag)를 전달하는 결합도. 
• 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계된 경우에 발생. 
• 하위 모듈에서 상위 모듈로 제어 신호가 이동하여 하위 모듈이 상위 모듈에게 처리 명령을 내리는 권리 전도 현상이 발생하게 됨. 

- 외부 결합도

• 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
• 참조되는 데이터 범위를 각 모듈에서 제한할 수 있음. 

- 공통 결합도

• 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도. 
• 공통 데이터 영역의 내용을 조금이라도 변경하더라도 이를 사용하는 모든 모듈에 영향을 미치므로 모듈의 독립성을 약하게 만듦. 

- 내용 결합도

• 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도. 
• 한 모듈에서 다른 모듈의 내부로 제어가 이동하는 경우에도 내용 결합도에 해당됨. 

 

응집도(Cohesion)

- 정보 은닉(한 모듈 내부의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법)개념을 확장한 것으로, 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미. 

- 응집도가 강할 수록 품질이 높고, 약할수록 품질이 낮음. 

- 응집도의 종류: 기능적 응집도, 순차적 응집도, 교환적 응집도, 절차적 응집도, 시간적 응집도, 논리적 응집도, 우연적 응집도

- 기능적 응집도

• 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도. 

- 순차적 응집도

• 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도. 

- 교환적 응집도

• 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도. 

- 절차적 응집도

• 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도

- 시간적 응집도

• 특정 시간에 처리되는 몇개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도. 

- 논리적 응집도

• 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도

- 우연적 응집도

• 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

 

팬인/팬아웃

- 팬인: 어떤 모듈을 제어(호출)하는 모듈의 수

- 팬아웃: 어떤 모듈에 의해 제어(호출)되는 모듈의 수

- 팬인과 팬 아웃을 분석하여 시스템 복잡도를 알 수 있음. 

- 팬인이 높다는 것은 재사용 측면에서 설계가 잘 되어 있다고 볼 수 있으나 단일 장애점(시스템 구성 요소중 동작하지 않으면 전체 시스템이 중된되어 버리는 요소)이 발생할 수 있으므로 중점적인 관리 및 테스트가 필요함. 

- 팬아웃이 높은 경우 불필요하게 다른 모듈을 호출하고 있는지를 검토하고, 단순화 시킬 수 있는지 여부에 대한 검토가 필요. 

- 시스템 복잡도를 최적화하려면 팬인은 높게, 팬아웃은 낮게 설계해야함. 

 

5.3 공통 모듈

 

공통 모듈의 개요

- 여러 프로그램에서 공통적으로 사용할 수 있는 모듈을 의미

- 자주 사용되는 계산식이나 매번 필요한 사용자 인증과 같은 기능들이 공통 모듈로 구성될 수 있음. 

- 모듈의 재사용성 확보와 중복 개발 회피를 위해 설계 과정에서 공통 부분을 식별하고 명세를 작성할 필요가 있음. 

- 공통 모듈 구현 시 준수해야할 명세 기법

• 정확성: 시스템 구현 시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성.
• 명확성: 해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확히 작성. 
• 완전성: 시스템 구현을 위해 필요한 모든 것을 기술.
• 일관성: 공통 기능들 간 상호 충돌이 발생하지 않도록 작성. 
• 추적성: 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성. 
• 정확하고 명확하고 완전하고 일관되게 추적하기.

 

재사용(Reuse)

- 비용과 개발 시간을 절약하기 위해 이미 개발된 기능을 파악하고 재구성하여 새로운 시스템 또는 기능 개발에 사용하기 적합하도록 최적화시키는 작업. 

- 재사용을 위해서는 누구나 이해할 수 있고 사용이 가능하도록 사용법을 공개해야 함. 

- 재사용이 되는 대상은 외부 모듈과의 결합도가 낮고, 응집도는 높아야 함. 

- 재사용 규모에 따른 분류

• 함수와 객체: 클래스나 메소드 단위의 소스 코드를 재사용. 
• 컴포넌트: 컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용. 
• 애플리케이션: 공통된 기능들을 제공하는 애플리케이션을 공유하는 방식으로 재사용.

 

효과적인 모듈 설계 방안

- 결합도는 줄이고 응집도는 높여서 모듈의 독립성과 재사용성을 높인다. 

- 모듈의 제어 영역(프로그램의 계층 구조 내에서 어떤 특정 모듈이 제어하는 하위 모듈) 안에서 그 모듈의 영향 영역(특정 모듈이 다른 모듈들에게 미치게 되는 영향의 범위)을 유지시킴. 

- 복잡도와 중복성을 줄이고 일관성을 유지시킴. 

- 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안됨. 

- 유지보수가 용이해야 함

- 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해함. 

- 하나의 입구와 하나의 출구를 갖도록 해야함. 

- 인덱스 번호나 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스를 설계해야 함. 

 

5.4 DBMS 접속 (Connection)

 

DBMS 접속의 개요

- 사용자가 데이터를 사용하기 위해 응용 시스템을 이용하여 DBMS에 접근하는 것. 

- 응용 시스템은 사용자로부터 매개 변수를 전달받아 SQL을 실행하고 DBMS로부터 전달받은 결과를 사용자에게 전달해주는 매개체 역할을 수행. 

- 인터넷을 통해 구동되는 웹 응용 프로그램은 웹 응용 시스템을 통해 DBMS에 접근함. 

- 웹 응용 시스템은 웹 서버와 웹 어플리케이션 서버(WAS)로 구성되며, 서비스 규모가 작은 경우 웹 서버와 WAS를 통합하여 하나의 서버로 운용할 수 있음. 

- 웹 응용 시스템: 웹 브라우저 = 웹 응용 프로그램, 웹 페이지 내용 = 웹 서버에서 송출되는 것. 받은 이메일을 클릭하면 웹 서버는 받은 이메일 목록에 대한 요청을 WAS에 보내고, WAS는 DBMS로부터 데이터를 가져와 웹 서버에 전달함. 

- 웹 응용 시스템의 구조

• 사용자는 웹 응용 프로그램을 통해  웹 서버에 접속하여 데이터를 주고 받음. 
• 웹 서버는 많은 수의 서비스 요청을 처리하기 때문에 사용자가 대용량의 데이터를 요청하면 직접 처리하지 않고 WAS에게 해당 요청을 전달함. 
• WAS는 수신한 요청을 트랜잭션 언어로 변환한 후 DBMS에 전달하여 데이터를 받음. 이렇게 받은 데이터를 웹 서버로 다시 전달하여 사용자에게 도달 함. 

 

DBMS 접속 기술

- DBMS 접속 기술: DBMS에 접근하기 위해 사용되는 API 또는 API(운영체제나 DBMS를 사용할 수 있도록 규칙 등에 대해 정의해 놓은 인터페이스)의 사용을 편리하게 도와주는 프레임워크(소프트웨어에서 특정 기능을 수행하기 위해 필요한 클래스나 인터페이스를 모아둔 집합체) 등을 의미

- JDBC (Java DataBase Connectivity)

• JAVA 언어로 다양한 종류의 데이터베이스에 접속하고  SQL문을 수행할 때 사용되는 표준 API
• 1997년 2월 썬마이크로시스템 에서 출시. 
• Java SE(Java의 문법과 기능들을 정의하는 표준 명세서. 개발 도구인 JDK에 포함되어 사용)에 포함되어 있으며, JDBC 클래스는 java.sql, javax.sql에 포함되어 있음.
• 접속하려는 DBMS에 대한 드라이버가 필요함. 

- ODBC (Open DataBase Connectivity)

• 데이터베이스에 접근하기 위한 표준 개방형 API로 개발 언어에 관계 없이 사용할 수 있음. 
• 1992년 9월 마이크로소프트에서 출시.
• 프로그램 내 ODBC 문장을 사용하여 MS-Access, DBase, DB2, Excel, Text 등 다양한 데이터베이스에 접근할 수 있음.
• ODBC도 접속하려는 DBMS에 맞는 드라이버가 필요하지만, 접속하려는 DBMS의 인터페이스를 알지 못하더라도 ODBC 문장을 사용하여 SQL을 작성하면 ODBC에 포함된 드라이버 관리자가 해당 DBMS의 인터페이스에 맞게 연결해주므로 DBMS 종류를 몰라도 됨.  

- MyBatis

• JDBC 코드를 단순화 하여 사용할 수 있는 SQL Mapping(SQL로 호출되는 테이블이나 열 데이터를 개발하려는 언어의 객체에 맞도록 변환하여 연결하는 것) 기반 오픈 소스 접속 프레임워크
• JDBC로 데이터베이스에 접속하려면 다양한 메소드를 호출하고 해제해야 하는데, MyBatis는 이를 간소화했고 접속 기능을 더욱 강화함. 
• SQL 문장을 분리하여 XML파일을 만들고, Mapping을 통해  SQL을 실행함. 
• SQL을 거의 그대로 사용할 수 있어  SQL 친화적인 국내 환경에 적합하여 많이 사용됨. 

 

동적 SQL(Dynamic SQL)

- 다양한 조건에 따라 SQL 구문을 동적으로 변경하여 처리할 수 있는 SQL 처리 방식. 

- SQL문 문자열 변수에 넣어 처리함. 

- 사용자로부터  SQL문의 일부 또는 전부를 입력받아 실행할 수 있음. 

- 값이 입력되지 않을 경우 사용하는 NVL 함수(NVL(A,B) 형태의 함수로 A가 널일 경우 B를 반환하고 아니면 A를 반환함. )를 사용할 필요가 없음. 동적 SQL은 원하는 조건에 따라 자유롭게 SQL문을 바꿀 수 있으므로 NVL 함수 없이 SQL문을 구성하는 것이 가능함. 

- 응용 프로그램 수행 시  SQL이 변형될 수 있으므로 프리컴파일(고급 언어를 기계어로 번역하는 컴파일 전에 수행하는 작업으로, 필요한 라이브러리를 불러오거나 코드에 삽입된 SQL문을 DB와 연결하는 작업을 수행)할 때 구문 분석, 접근 권한 확인 등을 할 수 없음. 

- 정적  SQL에 비해 속도가 느리지만, 상황에 따라 다양한 조건을 첨가하는 등 유연한 개발이 가능함. 

	정적  SQL	동적  SQL
SQL 구성	커서(SQL 실행 결과로 반환된 복수개의 튜플에 접근할 수 있게 해주는 기능)를 통한 정적 처리	문자열 변수에 담아 동적 처리
개발 패턴	커서의 범위 안에서 반복문을 활용하여 SQL 작성	NVL함수 없이 로직을 통해  SQL작성
실행 속도	빠름	느림
사전 검사	가능	불가능

5.5 서버 개발

 

서버 개발의 개요

- 웹 애플리케이션의 로직을 구현할 서버 프로그램을 제작하여 웹 애플리케이션 서버(WAS)에 탑재하는 것.

- 웹 어플리케이션 서버(WAS)에 구현된 서버 프로그램은 웹 서버로부터 받은 요청을 처리하여 결과를 반환하는 역할을 수행함. 

- 서버 개발에 사용되는 프로그래밍 언어: Java, Javascript, Python, PHP, Ruby 등

- 각 프로그래밍 언어에는 해당 언어로 서버 프로그램을 개발할 수 있도록 지원하는 프레임워크가 있음. 

 

서버 개발 프레임워크

- 서버 프로그램 개발 시 다양한 네트워크 설정, 요청 및 응답 처리, 아키텍처 모델 구현 등을 손쉽게 처리할 수 있도록 클래스나 인터페이스를 제공하는 소프트웨어.

- 서버 개발 프레임워크에 따라 지원하는 프로그래밍 언어가 제한적이므로 선정할 수 있는 프레임워크도 제한적임. 

- 서버 개발 프레임워크의 대부분은 모델-뷰-컨트롤러(MVC) 패턴을 기반으로 개발됨. 

- 대표적인 서버 개발 프레임워크 종류

• Spring: JAVA를 기반으로 만들어진 프레임워크로 전자정부 표준 프레임워크의 기반 기술로 사용되고 있음. 
• Node.js: JavaScript를 기반으로 만들어진 프레임워크로, 비동기 입출력 처리와 이벤트 위주의 높은 처리 성능을 갖고 있어 실시간으로 입, 출력이 빈번한 애플리케이션에 적합함. 
• Django: Python을 기반으로 만들어진 프레임워크, 컴포넌트의 재사용과 플러그인화를 강조하여 신속한 개발이 가능하도록 지원함. 
• Codeigniter: PHP를 기반으로 만들어진 프레임워크. 인터페이스가 간편하며 서버 자원을 적게 사용함. 
• Ruby On Rails: Ruby를 기반으로 만들어진 프레임 워크. 테스트를 위한 웹 서버를 지원하며 데이터베이스 작업을 단순화, 자동화시켜 개발 코드의 길이가 짧아 신속한 개발이 가능함. 

- 프레임워크의 특성

• 모듈화: 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상시킴.
• 재사용성: 재사용이 가능한 모듈들을 제공함으로써 개발자의 생산성을 향상시킴.
• 확장성: 다형성(메시지에 의해 객체가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유의 방법으로 응답할 수 있는 능력)을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능함. 
• 제어의 역흐름: 개발자가 관리하고 통제해야 하는 객체들의 제어 권한을 프레임워크에 넘김으로써 생산성을 향상시킴.
• 모자황제역 > 모재확제역

 

5.6 서버 개발 과정

 

서버 개발

- 서버 개발은 DTO/VO, SQL, DAO, Service, Controller를 각각 구현하는 과정을 통해 이루어짐.

- 구현 순서는 개발자가 임의로 변경할 수 있음. 

- 개발하려는 서버 프로그램의 목적, 개발 언어, 규모 등의 이유로 통합하거나 세분화될 수 있음. 

- 모든 과정에서 보안 약점이 발생하지 않도록 소프트웨어 개발 보안 가이드(안전한 소프트웨어 개발을 위해 정부에서 제작하여 배포한 지침)를 참고함. 

- 광산 채굴 과정과 비슷

• 광산(Database) 에서 가져올 광석을 일시적으로 보관하기 위한 창고(DTO/VO)를 만들고 그 사이에 레일(SQL)을 설치함. 그 광석을 옮길 인부와 수레(DAO)를 갖추고, 광석을 가공할 기술자(Service)와 기술자들을 통제할 매니저(Controller)를 고용하면 시스템 완성!

 

DTO/VO 구현

- 데이터 교환을 위해 사용할 객체를 만드는 과정

- DTO(Data Transfer Object): 데이터의 교환을 위해 생성되는 객체

- VO(Value Object): DTO와 동일하지만 읽기만 가능한 객체. 변경이 불가능함.  

- 변수 및 객체를 송수신할 데이터의 자료형에 알맞게 생성. 

- 알고리즘 등의 로직은 구현하지 않고 변수와 데이터를 저장하고 반환하는 메소드만 구현함. (getter/setter 함수)

 

SQL 구현

- 데이터의 삽입, 변경, 삭제 등의 작업을 수행할 SQL문을 생성하는 과정.

- SQL문은 소스코드 내에 직접 입력하거나, 별도의 XML 파일로 저장하여 관리함. 

- XML 파일로 SQL문을 관리하는 경우 중복되는 SQL문을 최소화할 수 있고 유지보수가 간편해짐. 

- XML으로 SQL 작성할 때 프로그램 실행 이후 변경될 값을 지정할 때: #{변수명}

 

DAO 구현

- 데이터베이스에 접근하고, SQL을 활용하여 데이터를 실제로 조작하는 코드를 구현하는 과정. (광석을 옮길 수레)

- DAO(Data Access Object): 데이터베이스에 접근하여 데이터를 조회, 생성, 수정, 삭제 작업을 수행하는 객체

 

Service 구현

- 사용자의 요청에 응답하기 위한 로직을 구현하는 과정. 

 

Controller 구현

- 사용자의 요청에 적절한 서비스를 호출하여, 그 결과를 사용자에게 반환하는 코드를 구현하는 과정. 

 

각 구성요소의 진행 과정

1) 웹사이트로부터 사용자의 요청이 Controller 에 전달.

2) Controller는 해당 요청에 맞는 Service 호출

3) Service는 수행을 위한 데이터를 DAO에 요청.

4-6) DAO는 XML을 통해 DB로부터 Service가 요청한 데이터를 가져옴. 

7) 가져온 데이터를 Service 에 반환. 

8) Controller는 수행 결과를 웹사이트에 반환.

## DAO/VO는 1, 5, 9를 제외한 데이터 교환 전 과정에서 요청과 응답시 사용됨. 

 

5.7 배치 프로그램

 

배치 프로그램의 개요

- 사용자와의 상호 작용 없이 여러 작업들을 미리 정해진 일련의 순서에 따라 일괄적으로 처리하는 것. 

- 배치 프로그램이 자동으로 수행되는 주기에 따라 구분

• 정기 배치: 정기적으로 수행됨. 
• 이벤트성 배치: 특정 조건을 설정해두고 조건이 층적될 때만 수행됨.
• On-Demand 배치: 사용자 요청 시 수행. 

- 배치 프로그램이 갖추어야 하는 필수 요소

• 대용량 데이터: 대량의 데이터를 가져오거나, 전달하거나, 계산하는 등의 처리가 가능해야 함.
• 자동화: 심각한 오류가 발생하는 상황을 제외하고는 사용자의 개입 없이 수행되어야 함. 
• 견고성: 잘못된 데이터나 데이터 중복 등의 상황으로 중단되는 일 없이 수행되어야 함. 
• 안전성/신뢰성: 오류가 발생하면 오류의 발생 위치, 시간 등을 추적할 수 있어야 함.
• 성능: 다른 응용 프로그램의 수행을 방해하지 않고, 지정된 시간 내에 처리가 완료되어야 함
• 대용량 데이터를 자동적으로 견고하고 오류를 (안전하게 처리할수 있는 신뢰)가는 성능이 필요해~

배치 스케쥴러

- 일괄 처리 작업이 설정된 주기에 맞춰 자동으로 수행되도록 지원해주는 도구. 

- 배치 스케줄러는 특정 업무를 원하는 시간에 처리할 수 있도록 지원한다는 특성 때문에 잡 스케줄러라고도 불림.

- 주로 사용되는 배치 스케쥴러: 스프링 배치, Quartz, Cron

- 스프링 배치

• Spring Source사와 Accenture 사가 2007년 공동 개발한 오픈 소스 프레임워크
• 스프링 프레임워크의 특성을 그대로 가져와 스프링이 가지고 있는 다양한 기능들을 모두 사용할 수 있음. 
• 데이터베이스나 파일의 데이터를 교환하는 데 필요한 컴포넌트들을 제공함. 
• 로그 관리, 추적, 트랜잭션 관리, 작업 처리 통계, 작업 재시작 등 다양한 기능을 제공. 
• 스프링 배치의 주요 구성 요소와 역할
• Job: 수행할 작업 정의
• Job Launcher: 실행을 위한 인터페이스
• Step: Job 처리를 위한 제어 정보
• Job Repository: Step의 제어 정보를 포함하여 작업 실행을 위한 모든 정보 저장.

- Quartz

• 스프링 프레임워크로 개발되는 응용 프로그램들의 일괄 처리를 위한 다양한 기능을 제공하는 오픈소스 라이브러리
• 수행할 작업과 수행 시간을 관리하는 요소들을 분리하여 일괄 처리 작업에 유연성을 제공함. 
• Quartz의 주요 구성 요소와 역할
• Scheduler: 실행 환경 관리
• Job: 수행할 작업 정의
• JobDetail: Job의 상세 정보
• Trigger: Job의 실행 스케줄 정의

- Cron

• 리눅스의 스케줄러 도구로 crontab 명령어를 통해 작업을 예약할 수 있음. 
• 편집기(Editor)에서 요일, 월, 일, 시 분을 기준으로 수행할 명령어를 지정함. 
• 옵션
• -e : 편집기를 호출하여 작업 추가 및 수정
• -l : 작업 목록 출력
• -r : 작업 삭제

• 작업 예약 형식

- 분, 시, 일, 월, 요일에 “*”를 입력하면 매 시기마다 수행 

(예) 30 1 * * * / root /com1.sh → 매일 1시 30분에 com_1.sh를 실행

- 시기 우측에 ‘/[단위]’를 입력하면 시기를 단위로 나눈 나머지가 0일 때마다 명령어를 수행. 

(예) 30 */3 * * * /root/com_1.sh → 매월 매일 0:30 부터 3시간마다 com_1.sh 실행

- ‘[시작 시기] - [종료 시기]’를 통해 특정 구간에만 반복하여 명령어를 실행할 수 있음. 

(예) * 18-23 20 * * /root/com_1.sh → 매월 20일에 18시부터 23시 사이에 매 분마다 실행

- 시기는 [시기1], [시기2], [시기3], ... 을 통해 특정 시기에 명령어를 실행할 수 있음. 

(예) 30 23 25 4,9,11 * /root/com_1.sh →  4월, 9월, 11월 25일 23시 30분 마다 실행