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

 

개발환경 구축은 구현될 시스템 요구사항을 명확하게 이해하고 개발 도구와 서버의 선정, 개발에 사용되는 도구들의 편의성과 성능 라이선스를 확인하는 과정입니다. 개발 도구의 분류는 구현 도구, 테스트 도구, 형성관리, 빌드 도구로 분류할 수 있습니다.

구분	설명
빌드 도구	작성한 코드의 빌드 및 배포를 수행하는 도구 각각의 구성요소와 모듈에 대한 의존성 관리를 지원 - Ant, Maven, Gradle
구현 도구	개발자의 코드 작성과 디버깅, 수정 등과 같은 작업을 지원하는 도구 프로그램을 개발할 때 가장 많이 사용되는 도구 - Eclipse, InteliJ, Spring Tool Suite, NetBeans, Visual Studio
테스트 도구	코드의 기능 검증과 전체의 품질을 높이기 위해 사용하는 도구 - xUnit, PMD, Findbugs, Cppcheck, Sonar
형상 관리 도구	개발자들이 작성한 코드와 리소스 등 산출물에 대한 버전 관리를 위한 도구 - CVS, Subversion, Git

개발환경 구성요소 중 서버 하드웨어 개발 환경에는 프로젝트 구성에 따라 웹 서버, 웹 애플리케이션 서버, 데이터베이스 서버, 파일 서버로 구분할 수 있습니다. 

• 웹 서버

HTTP를 이용한 요청/응답을 처리하며 웹 상의 정적 콘텐츠를 처리합니다. WEB-WAS-DB 3계층 구조를 활용하고 주요 제품으로는 Apache, IIS, Google Web Server, Nginx 등이 있습니다.

☞WAS(Web Application Server) : 사용자 요청 스레드를 처리하고 데이터베이스에 접속하여 SQL 쿼리문에 대한 결과값을 반환하는 역할을 수행합니다.

• 웹 애플리케이션 서버

동적 콘텐츠를 처리하기 위해 사용합니다. 주요 제품으로는 Tomcat, Weblogic, Jeus, Resin 등이 있습니다.

• 데이터베이스 서버

데이터의 수집, 저장을 위한 용도로 사용합니다.

• 파일 서버

파일 저장 하드웨어로 물리 저장장치를 활용한 서버입니다. 

 

클라이언트 하드웨어 개발환경은 설치를 통해 사용자와 커뮤니케이션을 하는 프로그램인 클라이언트 프로그램, 웹 서비스 형태로 제공하는 웹 브라우저, 모바일 디바이스에 설치되어 활용하는 모바일 앱, 웹 브라우저와 동일하지만 모바일에 최적화 되어있느 모바일 웹 이렇게 4가지의 환경으로 구분되어 있습니다.

 

소프트웨어 개발환경 구성에는 요구사항에 맞춰 운영체제, 미들웨어, DBMS를 선택합니다.

구분	설명
운영체제	서버의 하드웨어를 사용자 관점에서 편리하고 유용하게 사용하기 위한 소프트웨어 - Windows, Unix, Linux
미들웨어	컴퓨터와 컴퓨터 간의 연결이 쉽고 안전하게 할 수 있도록 해주고 이에 대한 관리를 도와주는 소프트웨어 - Weblogic, Webspgere, Jeus, Tomcat
DBMS	사용자와 ㄱ데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리해주는 소프트웨어 - Oracle, MySQL, MS-SQL, PostgreSQL

 

형상 관리(Configuration Management)는 소프트웨어 개발을 위한 전체 과정에서 발생하는 모든 항목의 변경 사항을 관리하기 위한 활동입니다. 소프트웨어 생명주기 동안 형상 관리를 통해 산출물을 체계적으로 관리하여 SW의 가시성, 추적성, 무결성 등의 품질 보증을 할 수 있습니다.

• 형상 식별

형상 관리 대상을 정의 및 식별하는 활동으로 추적성 부여를 위해 ID와 관리번호를 부여합니다.

• 형상 통제

형상 항목의 버전 관리를 위한 형상통제위원회(CCB; Configuration Control Board)를 운영하고 변경요구 관리, 변경제어, 형상 관리 등 통제를 지원합니다.

☞형상통제위원회(CCB) : 형상 관리에 대한 주요 방침을 정하고 산출물을 검토하며 단계별 의사결정을 수행하는 조직

• 형상 감사

소프트웨어 베이스라인의 무결성 평가와 베이스라인 변경 시 요구사항과 일치 여부를 검토합니다.

☞베이스라인(Baseline) : 개발 과정의 각 단계의 산출물을 검토, 평가, 조정, 처리 등 변화를 통제하는 시점의 기준

• 형상 기록

소프트웨어 형상 및 변경관리에 대한 각종 수행결과를 기록하고 형상결과 보고서를 작성합니다.

 

소프트웨어 형상 관리 도구에는 공유 폴더방식(RCS,SCCS), 클라이언트/서버 방식(CVS,SVN), 분산 저장소 방싞(Git 등)이 있습니다. 

구분	설명
공유 폴더방식(RCS,SCCS)	매일 개발이 완료된 파일은 약속된 위치의 공유 폴더에 복사하는 방식
클라이언트/서버 방식(CVS,SVN)	중앙에 버전 관리 시스템을 두어 관리하는 방식
분산 저장소 방싞(Git 등)	로컬 저장소와 원격 저장소로 부리되어 분산 저장하는 방식

 

모듈(Module)은 완전한 기능을 수행할 수 있는 독립된 실체를 말합니다. 각각의 모듈은 상대적으로 독립성을 가지고 있고 단독으로 컴파일을 할 수 있으며, 재사용을 할 수 있습니다. 좋은 모듈은 결합도가 낮고 응집도가 높아야 합니다.

모듈화(Modularity)는 소프트웨어 성능을 향상시키거나 복잡한 시스템의 수정, 재사용, 유지 관리 등이 용이하도록 기능 단위의 모듈로 분해하는 설계 및 구현 기법입니다. 이러한 모듈회에는 루틴(Routine), 메인 루틴(Main Routine), 서브 루틴(Subroutine)이 있습니다.

 

• 응집도(Cohesion)

(낮음) 우연적 ➡️ 논리적 ➡️ 시간적 ➡️ 절차적 ➡️ 통신적 ➡️ 순차적 ➡️ 기능적 (강함)

구분	설명
우연적 응집도(Coincidental Cohesion)	모듈 내부의 각 구성 요소가 연관이 없을 경우
논리적 응집도(Logical Cohesion)	유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우
시간적 응집도(Temporal Cohesion)	연관된 기능이라기보다는 특정 시간에 처리되어야하는 활동들을 한 모듈에서 처리하는 경우
절차적 응집도(Procedural Cohesion)	모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우
통신적 응집도(Communication Cohesion)	동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여있는 경우
순차적 응집도(Sequential Cohesion)	모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우
기능적 응집도(Functional Cohesion)	모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우

• 결합도(Coupling) : 모듈 내부가 아닌 외부의 모듈과의 연관도 또는 모듈간의 상호의존성으로 소프트웨어 구조에서 모듈 간의 관련성을 측정하는 척도이다.

(낮음) 자료 ➡️ 스탬프 ➡️ 제어 ➡️ 외부 ➡️ 공통 ➡️ 내용 (강함)

구분	설명
내용 결합도(Content Coupling)	다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우 하나의 모듈이 직접적으로 다른 모듈의 내용을 참조할 때 두 모듈이 내용적으로 결합되어 있는 경우
공통 결합도(Common Coupling)	파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 경우
외부 결합도(External Coupling)	두 개의 모듈이 외부에서 도입된 데이터 포맷, 통신 프로토콜, 디바이스 인터페이스를 공유하는 경우 외부 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때
제어 결합도(Control Coupling)	어던 모듈이 다른 모듈의 내부 논리 조직을 제어하기 위한 목적으로 제어신호를 이용하여 통신하는 경우 하위 모듈에서 상위 모듈로  제어 신호가 이동하여 상위 모듈에게 처리 명령을 부여하는 권리 전도 현상이 발생하는 경우
스탬프 결합도(Stamp Coupling)	모듈 간의 인터페이스로 배열이나 객체, 구조 등이 전달되는 경우 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도, 자료 구조의 어떠한 변화는 모든 모듈에 영향을 주게된다.
자료 결합도(Data Coupling)	모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우 한 모듈의 내용을 변경하더라도 다른 모듈에는 영향을 미치지 않는 상

 

팬인(Fan-In)과 팬아웃(Fan-Out)은 소프트웨어 구성요소인 모듈을 계층적으로 분석하기 위해서 활용합니다. 팬인과 팬아웃을 이용하면 시스템의 복잡도를 측정할 수 있습니다.

• 팬인(Fan-In)

어떤 모듈을 제어하는 모듈의 수로 자신을 기준으로 들어오면 팬인(Fna-In)입니다. 팬인이 높으면 재사용 측면에서 설계가잘 되었지만 단일 장애점 발생 가능성이 있고 팬인이 높으면 관리 비용 및 테스트 비용이 증가합니다.

• 팬아웃(Fan-Out)

어떤 모듈에 의해 제어되는 모듈의 수로 모듈 자신을 기준으로 나가면 팬아웃(Fan-Out)입니다. 팬아웃이 높으면 불필요한 모듈을 호출하지는 않는지 검사가 필요하며 단순화 여부를 검토해야합니다.

 

시스템 복잡도를 최적화 하고싶다면 팬인(Fan-In)은 높게하고 팬아웃(Fan-Out)은 낮게 해야합니다.

공통 모듈 테스트는 IDE(Integrated Development Environment)도구를 활용하여 디버깅을 수행하는 것으로 화이트박스 기법을 활용합니다. 공통 모듈 테스트의 종류에는 화이트박스, 메서드 기반, 화면 기반, 테스트 드라이버/테스트 스텁 활용 테스트가 있습니다.

• 화이트 박스테스트

응용프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방식으로 소스코드를 보면서 테스트 케이스를 다양하게 만들어 수행합니다.

• 메서드 기반 테스트

공통 모듈의 외부에 공개된 메서드 기반의 테스트로 메서드에 서로 다른 파라미터 값을 호출하면서 다양한 테스틀 수행합니다.

• 화면 기반 테스트

사용자 화면이 있는 경우 각각의 화면단위로 단위 모듈을 개발 후에 화면에 직접 데이터를입력하여 테스트를 수행합니다. 화면 기반 테스트의 경우 사용자 시나리오에 기반한 공통 모듈 테스트를 할 수 있는 장점이 있습니다.

• 테스트 드라이버(Driver) / 테스트 스텁(Stub)

기능을 테스트 할 수 있는 화면 또는 하위 모듈이 구현되지 않는 경우 테스트 드라이버와 테스트 스텁을 통해 수행합니다. 테스트 드라이버(Driver)의 경우 하위 모듈은 있지만 상위 모듈이 없는 경우 사용하고 테스트 스텁(Stub)의 경우 상위 모듈은 있지만 하위 모듈이 없는 경우 사용합니다.

 

서버 프로그램 구현 절차는 다음과 같은 순서로 이루어집니다.

DTO/VO 구현 ➡️ SQL 구현 ➡️ DAO 구현 ➡️ Service 구현 ➡️ Controller 구현 ➡️ 화면 구현

 

배치프로그램은 사용자와의 상호 작용없이 일련의 작업들을 작업 단위로 묶어 정기적으로 반복 수행하거나 규칙에 따라 일괄 처리하는 방법으로 이벤트 배치, 온디맨드 배치, 정기 배치로 구분되어 있습니다. 배치 스케줄러의 경우(Spring Batch), 쿼츠  스케줄러(Quartz Scheduler)로 구분되며 Cron 표현식을 활용합니다.