개발환경 구축
- 개발도구는 구현 도구, 테스트 도구, 형상관리 도구, 빌드 도구로 나뉜다.
구분
- 구현 도구
- 개발자의 코드 작성, 디버깅을 지원
- Eclipse, IntelliJ
- 테스트 도구
- 코드의 기능 검증과 전체 품질을 높이기 위해 사용하는 도구
- xUnit, PMD, FireBugs, Cppcheck
- 형상관리 도구
- 코드와 리소스 등 산출물에 대한 버전 관리 도구
- CVS, Subversion, Git
- 빌드 도구
- 작성 코드의 빌드 및 배포를 수행하는 도구
- Ant, Maven, Gradle
개발환경 구성요소
서버 하드웨어 개발환경
- 프로젝트 구성에 따라 웹 서버, 웹 애플리케이션 서버, 데이터베이스 서버, 파일 서버로 구분
구분
- 웹 서버
- HTTP를 이용한 요청/응답 처리
- 웹상 정적 콘텐츠(CSS, Javascript, Image) 처리
- 웹 애플리케이션 서버
- 동적 콘텐츠(Servlet, JSP)를 처리하기 위해 사용
- Tomcat, Weblogic, Jeus, Resin
- 데이터베이스 서버
- 데이터의 수집, 저장을 위한 용도로 사용
- MySql, Oracle, MS-SQL
- 파일 서버
- 파일 저장 하드웨어로 물리 저장장치를 활용한 서버
- 대용량 HDD, SSD 등 장치 존재
소프트웨어 개발환경
- 운영체제
- 미들웨어
- DBMS
형상관리
- 소프트웨어 개발을 위한 전체 과정에서 발생하는 모든 항목의 변경사항을 관리하기 위한 활동
형상관리 절차
- 형상 식별
- 형상관리 대상을 정의 및 식별
- 형상 통제
- 형상항목의 버전 관리를 위한 형상통제위원회 운영
- 형상 감사
- 소프트웨어 베이스라인의 무결성 평가
- 형상 기록
- 소프트웨어 형상 및 변경관리에 대한 각종 수행결과 기록
형상관리 도구 유형
- 공유폴더 방식(RCS, SCCS)
- 매일 개발완료한 파일을 공유폴더에 복사하는 방식
- 클라이언트/서버 방식(CVS, SVN)
- 중앙에 버전관리 시스템을 항상 동작시키는 방식
- 분산 저장소 방식(Git 등)
- 로컬 저장소와 원격 저장소로 분리하여 저장
- 개발 완료한 파일을 수정할 때 로컬 저장소에 commit한 뒤 원격 저장소에 push하는 방식
공통모듈 구현
- 모듈은 그것만으로 완전한 기능을 수행할 수 있는 독립적 개체이다.
모듈 특징
- 모듈의 독립성은 결합도와 응집도에 의해 측정되고, 독립성을 높이기 위해선 모듈의 결합도는 낮게, 응집도는 높게, 모듈 크기는 작게 만들어야 한다.
모듈화 기법
- 루틴(Routine)
- 소프트웨어에서 특정 동작을 수행하는 일련의 코드로 기능을 지닌 명령의 모임
- 메인 루틴(Main Routine)
- 프로그램의 주요한 부분이며 전체의 개략적인 동작 절차를 표시하도록 만들어진 루틴
- 메인 루틴은 서브 루틴을 호출한다.
- 서브 루틴(Subroutine)
- 메인 루틴에 의해 필요한 경우 호출되는 루틴
공통 모듈 구현
- 소프트웨어를 개발하면서 기능을 분할하고 추상화하여 성능을 향상시키고 유지보수를 용이하게 만드는 공통 컴포넌트 구현 기법
- 인터페이스 모듈, 데이터베이스 접근 모듈 등 필요한 공통 모듈을 구현한다.
- 모듈 간 결합도는 줄이고, 응집도는 높인 공통 모듈 구현이 권장된다.
응집도
- 모듈의 독립성을 나타내며 모듈 내부 구성요소 간 연관 정도이다.
- 하나의 모듈은 하나의 기능을 수행할수록 응집도가 높다.
- 우연적 응집도에서 기능적 응집도로 향할수록 높은 응집도를 지닌다.
- 응집도가 높을수록 품질이 높다.
응집도의 유형
- 우연적 응집도(Conincidental Cohesion)
- 모듈 내부의 각 구성요소가 연관이 없을 경우의 응집도
- 논리적 응집도(Logical Cohesion)
- 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우의 응집도
- 시간적 응집도(Temporal Cohesion)
- 특정 시간에 처리돼야 하는 활동을 한 모듈에서 처리하는 경우의 응집도
- 절차적 응집도(Procedural Cohesion)
- 모듈이 다수의 관련 기능을 지닐 때 모듈 내 구성요소들이 그 기능을 순차적으로 수행하는 경우의 응집도
- 통신적 응집도(Communication Cohesion)
- 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동이 모여 있을 경우의 응집도
- 순차적 응집도(Sequential Cohesion)
- 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우의 응집도
- 기능적 응집도(Functional Cohesion)
- 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우의 응집도
결합도
- 모듈 내부가 아닌 외부 모듈과의 연관도 또는 모듈 간 상호의존성이다.
- 소프트웨어 구조에서 모듈 간 관련성을 측정하는 척도이다.
- 내용 결합도에서 자료 결합도로 갈수록 낮은 결합도를 지닌다.
- 결합도가 낮을수록 품질이 높다.
결합도의 유형
- 내용 결합도(Content Coupling)
- 한 모듈이 다른 모듈의 내부 기능 및 자료를 직접 참조하거나 수정할 때의 결합도
- 공통 결합도(Common Coupling)
- 파라미터가 아닌 모듈 밖에 선언된 전역 변수를 참조하고, 전역 변수를 갱신하는 식으로 상호작용하는 경우의 결합도
- 외부 결합도(External Coupling)
- 두 개의 모듈이 외부에서 비롯된 데이터 포맷, 통신 프로토콜 혹은 디바이스 인터페이스를 공유할 때의 결합도
- 제어 결합도(Control Coupling)
- 처리할 대상인 값 이외 처리하는 방식에 대한 제어 요소가 전달되는 결합도
- 스탬프 결합도(Stamp Coupling)
- 모듈 간 인터페이스로 배열, 객체, 구조 등이 전달되는 결합도
- 자료 결합도(Data Coupling)
- 모듈 간 인터페이스로 전달되는 파라미터를 통해서만 모듈 간 상호작용이 나타나는 결합도
MVC 패턴
- MVC(모델-뷰-컨트롤러)는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 쓰이는 소프트웨어 디자인 패턴이다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 둔다.
MVC 패턴 역할
- 모델(Model)
- 데이터와 비즈니스 로직 관리
- 뷰(View)
- 레이아웃과 화면 처리
- 컨트롤러(Controller)
- 명령을 모델과 뷰로 라우팅
팬인(Fan-In) 및 팬아웃(Fan-Out)
- 팬인
- 모듈을 호출하는 다른 모듈의 수
- 팬인이 높으면 재사용 측면에서 좋은 설계지만 단일 장애가 발생할 위험이 큼
- 팬아웃
- 모듈에 의해 호출되는 타 모듈의 수
- 팬아웃이 높다면 불필요한 모듈을 호출하고 있을 수 있음
공통 모듈 테스트
- 화이트박스 테스트
- 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방식
- 메서드 기반 테스트
- 공통 모듈의 외부에 공개된 메서드 기반의 테스트
- 메서드에 서로 다른 파라미터를 넣으며 여러 방식으로 테스트
- 화면 기반 테스트
- 사용자용 화면이 있다면 각 화면단위로 단위모듈을 개발하고 화면에 직접 데이터를 입력하여 테스트 수행
- 화면기반 테스트는 화면과 연계된 서비스, 비즈니스 컴포넌트 및 공통 컴포넌트를 한번에 단위 테스트 할 수 있는 장점을 지님
- 사용자 시나리오에 기반한 공통 모듈 테스트 가능
- 테스트 드라이버(Driver) / 테스트 스텁(Stub)
- 기능을 테스트할 수 있는 화면 또는 하위 모듈이 구현되지 않은 경우 테스트 드라이버, 테스트 스텁을 통해 테스트 수행
- 테스트 드라이버는 하위 모듈은 있지만 상위 모듈은 없는 경우 사용
- 테스트 스텁은 상위 모듈은 있지만 하위 모듈은 없는 경우 사용
서버 프로그램 구현
- 업무 프로세스를 기반으로 개발언어와 도구를 이용해 서버에서 서비스 제공에 필요한 기능을 구현
- 백엔드와 프론트엔드를 구분하여 구현
- DTO(Data Transfer Object), VO(Value Object)
- 화면에서 전달받은 정보로 데이터베이스에 저장하는 객체 구현
- SQL
- VO에서 정의한 객체 정보에 맞춰 정보가 저장될 테이블 정보 생성
- DAO(Data Access Object)
- DAO를 통해 SQL을 구현한 XML id를 호출하여 조작 수행
- Service 클래스 구현
- DAO를 호출하는 Service를 구현
- Controller 클래스 구현
- 컨트롤러에서 기능을 수행하는 단위 모듈의 메인 로직 구현
- 검증(Validation) 로직 구현
- 기능 실행의 성공/실패시 다른 메시지를 호출하는 검증 로직 구현
배치 프로그램 구현
- 배치 프로그램은 사용자와의 상호작용 없이 일련의 작업을 작업 단위로 묶어 정기적으로 반복 수행하거나 정해진 규칙에 따라 일괄 처리하는 방법이다.
배치 프로그램 유형
- 이벤트 배치
- 사전에 정의한 조건충족시 자동 실행
- 온디맨드 배치
- 사용자의 명시적 요구가 있을시 실행
- 정기 배치
- 정해진 시점(주로 야간)에 정기적으로 실행
배치 스케줄러
- 배치 스케줄러는 일괄 처리(Batch Processing)를 위해 주기적으로 발생하거나 반복적으로 발생하는 작업을 지원하는 도구이다.
배치 스케줄러 종류
- 스프링 배치(Spring Batch)
- 스프링 프레임워크의 DI, AOP, 서비스 추상화 등 스프링 프레임워크의 3대 요소를 모두 사용할 수 있는 대용량 처리를 제공하는 스케줄러 배치 애플리케이션
- 쿼츠 스케줄러(Quartz Scheduler)
- 스프링 프레임워크에 플러그인되어 수행하는 작업(Job)과 실행 수케줄을 정의하는 트리거를 분리하여 유연성을 제공하는 오픈 소스 기반 스케줄러
Cron 표현식
- 스케줄러를 실행하기 위해 작업이 실행되는 시간 및 주기 등을 설정하는데 이때 크론 표현식으로 배치 수행시간을 설정한다.
- 크론 표현식은 리눅스(Linux)/유닉스(Unix)/쿼츠(Quartz)로 구분된다.
리눅스/유닉스 크론 표현식
| 순서 | 필드 이름 | 허용 값 |
|---|---|---|
| 1 | 분(Minutes) | 0~59, 특수문자 |
| 2 | 시간(Hours) | 0~23, 특수문자 |
| 3 | 일(Day) | 1~31, 특수문자 |
| 4 | 월(Months) | 1~12, JAN~DEC, 특수문자 |
| 5 | 요일(Week) | 1~7, SUN-SAT, 특수문자 |
| 6 | 연도(Year, 생략 가능) | 1970~2099, 특수문자 |
쿼츠 크론 표현식
| 순서 | 필드 이름 | 허용 값 |
|---|---|---|
| 1 | 초(Seconds) | 0~59, 특수문자 |
| 2 | 분(Minutes) | 0~59, 특수문자 |
| 3 | 시간(Hours) | 0~23, 특수문자 |
| 4 | 일(Day) | 1~31, 특수문자 |
| 5 | 월(Months) | 1~12, JAN~DEC, 특수문자 |
| 6 | 요일(Week) | 1~7, SUN-SAT, 특수문자 |
| 7 | 연도(Year, 생략 가능) | 1970~2099, 특수문자 |
Cron 표현식 특수문자 의미
| 기호 | 의미 |
|---|---|
| * | 모든 수 |
| ? | 해당 항목을 미사용 |
| - | 기간 설정 |
| , | 특정 기간 설정 |
| / | 시작시간과 반복간격 설정 |
| L | 마지막 기간에 동작 |
| W | 가장 가까운 평일에 동작 |
| # | 몇 번째 주, 요일 설정 |
Cron 표현식 특수문자(쿼츠)
| 예시 | 의미 |
|---|---|
| 0 0 12 * * ? | 매일 12시에 실행 |
| 0 15 10 * * ? | 매일 오전 10시 15분에 실행 |
| 0 14 * ? | 오후 14시에서 15시 사이에 매분 실행 |
| 0 0/5 14,20 * * ? | 매일 14시에 시작하여 14시 55분까지 5분마다 실행, 20시 정각부터 20시 55분까지 5분마다 실행 |
| 0 0 20 ? * MON-FRI | 매주 월요일과 금요일 사이 20시에 실행 |
| 0 15 10 15 * ? | 매달 15일 10시 15분에 실행 |
| 0 15 10 L * ? | 매달 마지막 날 10시 15분에 실행 |
| 0 11 11 1 1 ? | 1월 1일 11시 11분마다 실행 |
- 초, 분, 시간, 일, 월, 요일, 연도로 읽으면 된다.
- 언제 배치 스케줄러가 실행되는지 나타내는 표현식이다.
- *는 주기적으로 등작하는 날짜에 대한 반복실행을 뜻한다.
