01 개발환경 구축
▶ 개발 도구의 분류
=> 빌구테형 (개발환경 구축은 개발 도구의 분류가 중요!!)
- 빌드 도구: 작성한 코드의 빌드 및 배포를 수행하는 도구/각각의 구성요소와 모듈에 대한 의존성 관리를 지원
- EX) Ant, Maven, Gradle
- 구현 도구: 개발자의 코드 작성과 디버깅, 수정 등과 같은 작업을 지원하는 도구
- EX) Eclipse, IntelliJ, Spring Tool Suite, NetBeans, Visual Stdio
- 테스트 도구: 코드의 기능 검증과 전체의 품질을 높이기 위해 사용하는 도구
- EX) xUnit, PMD, Cppchek, Sonar, Findbugs
- 형상관리 도구(산출물에 대한 버전 관리 도구) EX) CVS, Git
▶ 서버 하드웨어 개발 환경
- 웹 서버: HTTP를 이용한 요청/응답 처리, 웹 상의 정적 콘텐츠 처리, Apache 웹서버
- 웹 어플리케이션 서버: 동적 콘텐츠(Servlet, JSP)를 처리, Tomcat
- WAS(Web Application Server): 사용자 요청 스레드를 처리하고 데이터베이스에 접속하여 SQL 쿼리 문에 대한 결괏값을 반환하는 역할을 수행하는 서버/서버 계층에서 애플리케이션이 동작할 수 있는 환경 제공, 안정적인 트랜잭션 처리와 관리, 다른 이기종 간 연동 지원 서버
- 데이터베이스 서버
- 파일 서버
▶ 소프트웨어 개발 환경
(미들웨어가 약술형 혹은 단답형을으로 나올 가능성 있음)
- 운영체제: 서버의 하드웨어를 사용자의 관점에서 편리하고 유용하게 사용할 수 있도록 인터페이스 제공해 주는 소프트웨어/컴퓨터 사용자와 하드웨어 간의 인터페이스 제공 역할
- 미들웨어: 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어, 운영체제와 소프트웨어 애플리케이션 사이에 위치하는 프로그램
- DBMS: 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리해주는 소프트웨어
▶ 형상 관리(Configuration Management)
소프트웨어 개발을 위한 전체 과정에서 발생하는 모든 항목의 변경사항을 관리하기 위한 활동
▶ 형상관리 절차
=> 식통감기
- 형상 식별: 형상 관리 대상 정의 및 식별
- 형상 통제: 형상 항목 버전 관리를 위한 형상통제위원회(CCB) 운영, 변경 여부와 변경 활동 통제
- 형상 감사: 소프트웨어 베이스라인의 무결성 평가, 베이스라인 변경 시 요구사항과 일치하는지 검토
- 형상 기록: 형상 및 변경관리에 대한 각종 수행결과 기록
*베이스라인: 개발 과정의 각 단계의 산출물을 검토, 평가, 조정, 처리 등 변화를 통제하는 시점의 기준
▶ 소프트웨어 형상 관리 도구
- 공유 폴더 방식(RCS, SCCS): 매일 개발이 완료된 파일은 약속된 위치의 공유 폴더에 복사하는 방식
- 클라이언트/서버 방식(CVS, SVN): 중앙에 버전 관리 시스템을 항시 동작시키는 방식/서로 다른 개발자가 같은 파일 작업했을 때 경고 메시지 출력
- 분산 저장소 방식(Git): 로컬 저장소와 원격 저장소로 분리되어 분산 저장하는 방식/개발 완료한 파일을 수정한 다음에 로컬 저장소에 우선적으로 커밋(Commit)한 이후, 다시 원격 저장소에 반영(Push)하는 방식
- CVS: 서버와 클라이언트로 구성, 다수의 인원이 동시에 운영체제로 접근가능
- SVN(Subversion): 하나의 서버에서 소스를 쉽고 유용하게 관리할 수 있게 도와줌
- RCS: 소스 파일의 수정을 한 사람만으로 제한
- Bitkeeper: SVN과 비슷, 대규모 프로젝트에서 빠른 속도 내도록 개발된 형상 관리 도구
* git init: 저장소 생성
* git clone: 저장소 복제
* git commit: 커밋
* git merge: 병합
* git push: 원격 저장소 반영
02 공통 모듈 구현
▶ 모듈(Module)
하나의 완전한 기능을 수행할 수 있는 독립된 실체
▶ 모듈화(Modularity)
소프트웨어의 성능을 향상시키거나 시스템의 디버깅, 시험, 통합 및 수정을 용이하도록 시스템을 분해하고 추상화하는 기법
▶ 모듈화 기법
- 루틴: 소프트웨어에서 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임
- 메인루틴, 서브루틴
▶ 응집도
모듈의 독립성을 나타내는 정도, 모듈 내부 구성요소 간 연관 정도
▶ 응집도 유형
=> 우논시절 통순기(우측으로 갈수록 응집도가 높음 -> 품질 좋음)
- Coincidental Cohesion(우연적 응집도): 모듈 내부의 각 구성요소가 연관이 없을 경우
- Logical Cohesion(논리적 응집도): 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우
- Temporal(시간적 응집도): 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우
- Procedural Cohesion(절차적 응집도): 모듈이 다수의 관련 기능을 갖고, 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우
- Communication Cohesion(통신적 응집도): 동일한 입력과 출력을 사용해 다른 기능을 수행하는 활동들이 모임
- Sequential Cohesion(순차적 응집도): 모듈 내 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우
- Functional Cohesion(기능적 응집도): 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우
▶ 결합도
모듈 내부가 아닌 외부의 모듈과의 연관도, 모듈 간의 상호 의존성, 모듈 간의 관련성
▶ 결합도 유형
=> 내공 외제 스자(우측으로 갈수록 결합도가 낮음 -> 품질 좋음)
- Content Coupling(내용 결합도): 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우
- Common Coupling(공통 결합도): 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 갱신하는 식으로 상호작용하는 경우
- External Coupling(외부 결합도): 두 개의 모듈이 외부에서 도입된 데이터 포맷, 통신 프로토콜, 또는 디바이스 인터페이스를 공유할 경우
- Control Coupling(제어 결합도): 어떤 모듈이 다른 모듈의 내부 논리 조직을 제어하기 위한 목적으로 제어 신호를 이용하여 통신하는 경우
- Stamp Coupling(스탬프 결합도): 모듈 간의 인터페이스로 배열이나 객체, 구조 등이 전달되는 경우
- Data Coupling(자료 결합도): 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우
▶ 공통 모듈(또는 서버 프로그램)의 구현 절차
DTO/VO -> SQL -> DAO -> Service -> Controller -> View=> 디스 다써클
(디스 당해서 다크써클이 생김)
*DTO(Data Transfer Object): 프로세스 사이에서 데이터를 전송하는 객체
*VO: 간단한 엔터티를 의미하는 작은 객체 가변 클래스인 DTO와 달리 고정 클래스를 가지는 객체*DAO: 특정 타입의 데이터베이스에 추상 인터페이스를 제공하는 객체
- 공통 모듈의 구현을 위한 공통 모듈 구현 절차에 MVC 패턴을 사용한다.
- Model(모델): 애플리케이션이 무엇을 할 것인지를 정의/내부 비즈니스 로직을 처리하기 위한 역할
- View(뷰): 화면에 무엇인가를 보여주기 위한 역할/화면에 처리
- Controller(컨트롤러): 모델이 어떻게 처리할지를 알려주는 역할/뷰에 명령을 보내어 화면 요청 결과를 전달
▶ 팬인(Fan-In)/팬 아웃(Fan-Out)
모듈을 계층적으로 분석하기 위해 활용, 팬인과 팬아웃 분석 통해 시스템 복잡도 측정 가능
- 팬인: 모듈 자신을 기준으로 들어오면 팬인/어떤 모듈을 제어(호출)하는 모듈의 수
- 팬아웃: 모듈 자신을 기준으로 나가면 팬아웃/어떤 모듈에 의해 제어(호출)되는 모듈의 수
▶ jUnit
자바 프로그래밍 언어용 단위 테스트 도구
▶ 공통 모듈 테스트 종류
- 화이트박스 테스트: 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방식
- 메서드 기반 테스트: 공통 모듈의 외부에 공개된 메서드 기반의 테스트/메서드에 서로 다른 파라미터 값을 호출하면서 다양한 테스트를 수행
- 화면 기반 테스트: 사용자 화면이 있는 경우 각각의 화면 단위로 단위 모듈을 개발 후에 화면에 직접 데이터를 입력하여 수행하는 테스트로서 사용자 시나리오에 기반한 테스트 가능
- 테스트 드라이버/테스트 스텁 활용 테스트: 기능을 테스트 할 수 있는 화면 또는 하위 모듈이 구현되지 않을 경우 테스트 드라이버나 테스트 스텁을 통해 테스트를 수행
- 공통 모듈 테스트를 위해 IDE 도구를 활용하여 개별 공통 모듈에 대한 디버깅을 수행한다.
- 공통 모듈 테스트는 화이트박스 테스트 기법을 활용한다.
- 대표적인 단위 테스트 도구인 jUnit을 활용하여 테스트 코드를 구현한다.
04 배치 프로그램 구현
▶ 배치 프로그램
사용자와의 상호작용 없이 일련의 작업들을 작업 단위로 묶어 정기적으로 반복 수행하거나, 정해진 규칙에 따라 일괄 처리하는 방법
▶ 배치 프로그램 유형
=> 이온정
- 이벤트 배치: (조건 충족됐을 때) 사전에 정의해 둔 조건 충족시 자동으로 실행
- 온디맨드 배치: (사용자의 요구가 있을 때) 사용자의 명시적 요구가 있을 때마다 실행
- 정기 배치: (정해진 시점에~) 정해진 시점(주로 야간)에 정기적으로 실행
▶ 배치 스케줄러
일괄 처리(Batch Proccessing)를 위해 주기적으로 발생하거나 반복적으로 발생하는 작업을 지원하는 도구
- 배치 스케줄러 종류: 스프링 배치(스프링 프레임워크의 3대 요소 모두 사용 가능한 대용량 처리 제공 스케줄러 배치 애플리케이션), 쿼츠 스케줄러(쿼츠 -> 대용량 데이터 배치 처리 기능 지원 X)
▶ Corn 표현식
스케줄러를 실행시키기 위해 작업이 실행되는 시간 및 주기 등을 설정함. 크론 표현식을 통해 배치 수행시간 설정.
- 리눅스/유닉스 크론 표현식: 분시일 월요연
- 쿼즈 크론 표현식: 초분시일 월요연
- 초, 분, 시간, 일, 월, 요일, 연도
- * : 모든 수
- ? : 해당 항목을 미사용
- - : 기간 설정
- , : 특정 기간 설정
- / : 시작시간과 반복간격 설정
- L: 마지막 기간에 동작
- W: 가장 가까운 평일에 동작
- #: 몇 번째 주, 요일 설정
쿼츠 크론 표현식
0 0 12 * * ?
초 분 시 월 일 요 연
=> 매일 12시에 실행
0 0 7 ? * MON-SAT
초 분 시 월 일 요 연
매 월요일부터 토요일까지 7시 0분 0초에 실행
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 L * ?
매달 마지막 날 10시 15분에 실행
2020년부터 2021년 매달 마지막 토요일 10시 15분에 실행
초 분 시 일 월 요 연
0 15 10 ? * 6L 2020-2021
'알아두면쓸데있는신기한잡학사전 > 정보처리기사' 카테고리의 다른 글
2022 정보처리기사 실기 Chapter 10 애플리케이션 테스트 관리 (0) | 2022.05.06 |
---|---|
2022 정보처리기사 실기 Chapter 09 소프트웨어 개발 보안 구축 (0) | 2022.05.06 |
2022 정보처리기사 실기 Chapter 05 인터페이스 구현 (0) | 2022.05.05 |
2022 정보처리기사 실기 Chapter 04 통합구현 (0) | 2022.05.05 |
2022 정보처리기사 실기 Chapter 03 데이터 입출력 구현 (0) | 2022.05.05 |