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

 

 개발환경 구축

: 개발환경 구성 시 구현될 시스템 요구사항의 명확한 이해 필요. 개발도구와 서버의 선정, 개발에 사용되는 도구의 사용 편의성, 성능, 라이선스 확인

 

1. 개발도구의 분류

1) 구현도구

: 코드작성, 디버깅, 수정 등 작업지원 도구.

: eclipse, intellij, spring tool suite, NetBeans, Visual studio

2) 테스트 도구

: 코드 기능 검증, 전체 품질 높이기 위해 사용하는 도구.

: xUnit, PMD, Findbugs, Cppcheck, Sonar

3) 형상관리 도구

: 코드, 리소스 산출물 버전관리 도구

: CVS, subversion, Git

4) 빌드도구

: 코드 빌드, 배포 수행 도구.

: Ant, Maven, Gradle

 

2. 개발환경 구성요소

1) 하드웨어 개발환경

(1) 웹서버: WEB-WAS-DB 3계층 구조를 실무에서활용

(2) 웹애플리케이션 서버: 동적컨텐츠(SERVLET, JSP)처리 위해 사용. TOMCAT, JEUS 등

(3) DB서버

(4) 파일서버

 

2) 클라이언트 하드웨어 개발환경

: UI제공

(1)클라이언트 프로그램: 설치통해 사용자와 커뮤니케이션하는 프로그램 Visual basic, C#, delphi 등으로 개발되어 사용.

(2)웹브라우저: 브라우저 통해 사용자와 커뮤니케이션.

(3)모바일웹

(4)모바일 앱

 

소프트웨어 개발환경

1) OS: hw를 사용자 관점에서 편리, 유용히 사용하기 위한 sw.

2) 미들웨어

: 컴-컴간 연결을 쉽고 안전하게 함.

: 자바기반 환경에서 JVM을 설치해 컨테이너로의 기능을 주로 이용.

: weblogic, websphere, jeus, tomcat

3) DBMS

: 사용자-DB 사이 사용자요구에 따라 정보를 생성해주고, 데이터베이스를 관리해주는 sw.

형상관리

: sw 개발을 위한 전체 과정에서 발생하는 모든 항목의 변경사항을 관리하기 위한 활동.

SW의 가시성, 추적성, 무결성 등의 품질보증.

: 형상 관리대상 파악, 베이스라인 지정, 형상관리, 접근제어 등.

 

형상관리 절차

절차	설명
형상 식별	형상관리 대상 식별. ID, 관리번호 부여
형상 통제	형상통제위원회 운영. 베이스라인에 대한 관리 및 형상 통제 수행 기능
형상 감사	SW 베이스라인의 무결성 평가 베이스라인 변경 시 요구사항 일치검토
형상 기록	형상결과보고서 작성

소프트웨어 형상관리 도구

형상관리도구유형	설명
공유폴더방식(RCS, SCCS)	개발완료 파일은 약속된 위치에 폴더를 복사하는 방식.
클라이언트/서버방식 (CVS, SVN)	중앙에 버전관리시스템을 항시 동작시킴 개발자들의 현재작업내용과 이전 작업내용 추적에 용이
분산저장소방식(Git)	로컬저장소와 원격저장소가 분리되어 분산저장. 중앙의 저장소에서 로컬파일을 복사(clone)한 순간 개발자 자신만의 로컬 저장소 생성 커밋-push(반영)하는 방식

 

소프트웨어 형상 관리 도구별 특징

1) CVS(concurrent versions system): 서버와 클라이언트로 되어있고, 다수 인원이 동시에 범용적인 운영체제로 접근 가능한 형상관리 도구

2) SVN(subversion): 한 서버에서 소스를 쉽고 유용히 관리 도구.

3) RCS(revision control system): 소스파일 수정을 한사람으로 제한. 동시수정 금지-파일잠금

4) bitkeeper: 중앙통제방식으로 대규모플젝에서 빠른 속도내도록 개발됨

5) Git: 속도에 중점을 둔 분산형 버전관리 시스템이며, 대형 플젝에서 효과적이고 유용. 로컬저장소에서 작업이 이루어져 매우 빠른 응답을 받을 수 있음.

6) Clear case: 복수서버, 복수 클라이언트 구조. 서버가 부족할 때 필요서버를 하나씩 추가하며 확장성.

 

소프트웨어 형상 관리 도구 사용 시 유의사항

1) 버전에 대한 쉬운 정보 접근성

2) 불필요한 사용자에 대한 접근 제어

3) 동일 프로젝트에 대한 동시 사용성

4) 빠른 오류복구

 

3. 개발환경 구축절차

1) 통합 개발 환경 설치

2) 형상 관리 도구 설치

3) 빌드 도구 설치

 

형상관리도구 (Git, SVN) 주요 명령어

실행동작	git	SVN
저장소생성	git init	svn import
저장소 복제	git clone	svn checkout
커밋	git commit	svn commit
변경내용 확인	git diff	svn diff
추가	git add	svn add
이동	git mv	svn mv
삭제	git rm	svn rm
브랜치 생성	git branch	svn copy
병합	git merge	svn merge
원격저장소반영	git push	svn commit
설정확인	git config	svn info

 

공통 모듈 구현

: 모듈은 그 자체로 하나의 완전한 기능을 수행할 수 있는 독립된 실체임. 모듈화를 통해 분리된 시스템의 각 기능들로 서브프로그램, 서브 루틴, SW 내 단위 프로그램, 작업 단위 등과 같은 의미로 사용됨.

: 모듈은 상대적으로 독립성을 가지고 있음.

: 모듈은 단독으로 컴파일 가능하며, 재사용할수 있음.

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

: 모듈화는 SW 성능향상, 복잡한 시스템의 수정, 재사용, 유지관리가 용이하도록 기능단위 모듈로 분해하는 설계, 구현기법임.

1) 루틴: SW에서 특정동작 수행하는 일련의 코드로 기능을 가진 명령들의 모임.

2) 메인루틴: 전체 개략적인 동작 절차를 표시하도록 만들어진 루틴. 메인 루틴은 서브루틴을 호출

3) 서브루틴: 메인루틴에의해 필요마다 호출됨.

 

공통 모듈 구현의 개념

:SW 개발에 있어 기능 분할하고 추상화하여 성능향상시키고 유지보수 효과적으로 하기위한 공통 컴포넌트 구현방법.

: 모듈간 결합도는 줄이고, 응집도는 높임.

 

-SW 모듈 응집도

: 응집도는 모듈 독립성을 나타내는 정도. 모듈 내부 구성요소간 연관 정도임. 하나의 모듈은 하나의 기능을 수행할수록 응집도가 높음.

-응집도 유형

(응집도낮음(나쁜품질)-> 응집도높음(좋은품질) 순)

1) 우연적 응집도: 연관이 없을정도의 응집도

2) 논리적 응집도: 유사/특정 형태로 분류되는 요소들이 한 모듈에서 처리되는 경우의 응집도

3) 시간적 응집도: 특정시간에 처리되어야하는 활동들을 한모듈에서 처리할 경우의 응집도

4) 절차적 응집도: 모듈이 다수 기능을 가질 때 구성요소들이 순차적으로 수행할 경우의 응집도

5) 통신적 응집도: 동일한 입출력을 사용해 타기능을 수행하는 활동들이 모여있는 경우의 응집도

6) 순차적 응집도: 모듈 내 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우의 응집도

7) 기능적 응집도: 모듈 내부 모든 기능이 단일목적을 위해 수행되는 응집도

 

-SW 모듈 결합도

: 외부 모듈과의 연관도, 모듈간 상호의존성. SW구조에서 모듈간 관련성 측정하는 척도.

결합도높은순(낮은품질)-> 결합도낮은순(높은품질)

1) 내용 결합도: 내부 변수/기능을 다른모듈에서 사용

2) 공통 결합도: 전역변수를 참조하고 갱신하는 상호작용

3) 외부 결합도: 두 모듈이 외부 데이터포맷, 통신프로토콜 등을 공유함

4) 제외 결합도: 처리 제어요소가 전달됨

5) 스탬프 결합도: 모듈간 인터페이스로 배열. 객체 등이 전달됨

6) 자료 결합도: 모듈간 인터페이스로 전달되는 파라미터를 통해서만 모듈간 상호작용이 일어남.

 

-공통 모듈 구현 대상

: 화면모듈, 화면에서 입력받는 데이터처리를 위한 서비스 컴포넌트, 비즈니스 트랜잭션 컴포넌트 등이 있음.

: 통합 구현에서 공통모듈구현은 상세설계된 공통모듈, 환경변수를 실제 프밍언어로 구현함.

-공통 모듈 구현 절차 (MVC 패턴 사용)

: DTO/VO -> SQL -> DAO -> SERVICE -> controller -> 화면 구현 순.

 

*DAO(data access object): 특정 타입의 DB에 추상 인터페이스 제공하는 객체로 세부내용 노출없이 데이터를 조작하는 객체

*VO(value object): 간단한 엔티티. 고정 클래스를 가지는 객체

*DTO(data transfer object): 프로세스 사이에서 데이터전송하는 객체. 데이터 저장/회수 외에 기능없음

*service: 사용자 요청 처리기능 제공위한 로직 구현. DAO클래스를 통해 DB연동 처리.

*MVC 패턴

model: 앱이 뭐할지 정의. 비즈니스 로직 처리 역할

view: 화면에 뭘 보여줄건지 정의.

controller: 모델이 어떻게 처리할지 알려주는 역할.

 

Fan-in Fan-Out

: SW 구성요소인 모듈을 계층적 분석위해 활용. 시스템 복잡도 측정 가능.

구분	팬인	팬아웃
개념	모듈제어(호출)하는 모듈의 수	모듈에 의해 제어(호출)되는 모듈의 수
모듈 숫자 계산	모듈 자신을 기준으로 모듈에 들어오면 팬인	모듈자신을 기준으로 모듈에서 나가면 팬아웃
고려사항	팬인이 높으면 재사용측면에서 설계가 잘되었지만, 단일장애점 발생, 관리/테스트비용 증가	팬아웃이 높으면 불필요한 모듈 호출/단순화 여부 검토 필요.

시스템 복잡도 최적화 위해서는 팬인 높게, 팬아웃은 낮게 설계해야 함.

 

-공통모듈 테스트:

IDE(intergrated development environment) 도구를 활용해 개별 공통 모듈에 디버깅 수행.

:공통 모듈 테스트는 화이트박스 기법을 활용함. (프로그램 로직을 이해하고, 내부 구조와 동작 검사하는 SW 테스트방식)

: 대표적 단위테스트 도구인 JUnit(자바용 단위테스트도구)을 활용해 테스트코드를 구현함.

 

-공통 모듈 테스트 종류

1) 화이트박스 테스트: 내부 구조와 동작 검사하는 SW 테스트 방식. 소스코드를 보며 테스트케이스 다양히만듦.

2) 메서드기반 테스트: 외부 메서드 기반 테스트. 메서드에 서로다른 파라미터 값 호출하며 수행

3) 화면 기반 테스트: 화면과 연계된 서비스, 비즈니스 컴포넌트 및 공통 컴포넌트를 한번에 단위 테스트에참여

4) 테스트 드라이버/테스트 스텁: 테스트화면, 모듈 미구현시 수행. 하위모듈은 있지만 상위 모듈이 없는 경우 테스트 드라이버를. 상위는 있지만 하위모듈이 없는 경우 테스트 스텁을 사용.

 

-JUnit 주요 어노테이션:

@Test: 테스트 메서드 선언

@Before: @Test실행전 실행되는 코드 작성

@After: @Test실행후 실행되는 코드 작성

@BeforeClass: @Test 메서드보다 먼저 1번 수행

@AfterClass: 단위테스트 맨마지막에 수행

@Ignore: 제외할 메서드

-Assert 메서드 설명:

assertEquals(a,b); :객체 a, b가 일치함을 확인

assertEquals(a,b,c); :객체 a, b가 일치함을 확인. a: 예상값, b=결괏값, c=오차범위

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

assertTrue(a): 조건 a가 참인지 확인

assertNotNull(a);

assertArrayEquals(a,b); 배열 a와 b가 일치함을 확인.

 

서버 프로그램 구현

: 업무프로세스를 기반으로 개발언어, 도구 이용해 서비스 제공에 필요한 기능을 구현

VO, SQL문, DAO, Service, Controller 순서대로 구현

1) DTO, VO구현

: DB에 저장하는 객체 구현

2) SQL문 구현

: DB 테이블 정의 및 생성, XML 구현

3) DAO(데이터 접근객체) 구현

: SQL을 구현한 XML ID를 호출해 조작 수행

4) Service 클래스 구현

: DAO를 호출하는 서비스를 선언. 구현함.

5) 컨트롤러 클래스 구현

6) 입출력 검증(Validation) 로직 구현

 

배치 프로그램 구현

: 배치프로그램은 사용자와 상호작용 없이 작업을 작업단위로 묶어 정기 반복 수행하거나 규칙에 따라 일괄처리하는 방법임.

1) 이벤트 배치: 사전 정의해둔 조건 충족 시 자동실행

2) 온디맨드 배치: 사용자 명시적 요구 있을 때 시행

3) 정기배치: 정해진 시점에 정기적 시행

-배치 스케쥴러: 일괄처리를 위해 주기적 발생, 반복발생 작업을 지원하는 도구.

-배치 스케쥴러 종류:

1) 스프링배치: 스프링프레임워크의 DI, AOP, 서비스 추상화 등 3대 요소를 모두 사용할 수 있는 대용량 처리를 제공

2) 쿼츠 스케줄러: 스프링프레임워크에 플러그인되어 수행하는 작업과 실행 스케쥴을 정의하는 트리거를 분리해 유연성을 제공하는 오픈소스기반 스케쥴러.

 

-Cron 표현식: 스케쥴러 실행위해 크론 표현식을 통해 배치 수행시간을 설정함.

순서	리눅스/유닉스 크론표현식 필드명	쿼츠크론표현식 필드명
1	분	초
2	시간	분
3	일	시간
4	월(1~12)	일
5	요일(0=7=일욜, 6=토욜)	월(1~12)
6	연도	요일
7		연도

-Cron 표현식 특수문자 의미:

*: 모든 수

?: 해당항목 미사용

-: 기간 설정

.: 특정기간 설정

/:시작시간과 반복간격 설정

L:마지막 기간에 동작

W: 가장 가까운 평일에 동작

#: 몇 번째 주, 요일 설정

 

0 0 12 * * ?: 매일 12시에 실행

0 * 14 * * ?: 오후 14~15시 사이 매분마다 실행

0 0/5 14,20 * * ?: 매일 14시 시작해 14시55분까지 5분마다 실행, 20시정각부터 20시 55분까지 5분마다 실행

0 15 10 L * ?: 매달 마지막날 10시 15분에 실행

0 15 10 ? * 6L 2020-2021: 2020~2021년 매달 마지막 금요일 10시 15분에 실행

 

-배치프로그램 설계:

1) 배치 프로그램 관리대장 확인

2) 배치설계서 확인

 

-배치프로그램 작성:

1) DTO, VO 구현

2) SQL문 구현

3) DAO 구현

4) 서비스 클래스 구현

5) 스케쥴러 등록