2. 소프트웨어 개발
2.1. 자료 구조
2.1.1. 자료 구조의 분류
2.1.1.1. 선형 구조(Linear Structure)
2.1.1.1.1. 배열(Array)
2.1.1.1.1.1. 정적인 자료 구조로 기억장소의 추가가 어렵고, 메모리의 낭비가 발생함.
2.1.1.1.1.2. 첨자를 이용
2.1.1.1.1.3. 반복적인 데이터 처리 작업에 적합한 구조
2.1.1.1.1.4. 데이터마다 동일한 이름의 변수를 사용해 처리가 간편함.
2.1.1.1.2. 스택(Stack)
2.1.1.1.2.1. 리스트의 한쪽 끝으로만 자료의 삽입, 삭제 작업이 이뤄지는 자료 구조.
2.1.1.1.2.2. 후입선출(LIFO : Last In First Out) 방식
2.1.1.1.3. 큐(Queue)
2.1.1.1.3.1. 리스트의 한쪽에서는 삽입 작업, 다른 한쪽에서는 삭제 작업이 이뤄지는 자료 구조.
2.1.1.1.3.2. 선입선출(FIFO: First In First Out) 방식
2.1.1.1.3.3. 시작(F, Front)과 끝(R,Rear) 을 표시하는 두 개의 포인터가 있음.
2.1.1.1.3.4. 운영체제의 작업 스케줄링에 사용함.
2.1.1.1.4. 데크(Deque)
2.1.1.1.4.1. 리스트의 양쪽 끝에서 삽입과 삭제 작업을 할 수 있는 자료 구조.
2.1.1.1.5. 선형 리스트(Linear List) = 연속 리스트(순차적임), 연결 리스트(순차적이지 않음)
2.1.1.1.5.1. 연속 리스트(Contiguoust List)
2.1.1.1.5.1.1. 배열과 같이 연속되는 기억 장소에 저장되는 자료 구조
2.1.1.1.5.1.2. 기억 장소를 연속적으로 배정받아, 기억장소 이용 효율은 밀도가 1로서 가장 좋음.
2.1.1.1.5.1.3. 중간에 데이터를 삽입하기 이해 연속된 빈 공간이 있어야 함.
2.1.1.1.5.1.4. 삽입, 삭제 시 자료의 이동이 필요함.
2.1.1.1.5.2. 연결 리스트(Linked List)
2.1.1.1.5.2.1. 자료들은 반드시 연속적으로 배열시키지 않고 임의의 기억공간을 기억 시킴.
2.1.1.1.5.2.2. 자료 항목의 순서에 따라 노드의 포인터 부분을 이용해 서로 연결 시킨 자료 구조.
2.1.1.1.5.2.3. 노드의 삽입, 삭제 작업이 용이
2.1.1.1.5.2.4. 기억 공간이 연속적으로 놓여 있지 않아도 저장 가능
2.1.1.1.5.2.5. 연결을 위한 포인터가 필요하기 때문에 순차 리스트에 비해 기억 공간의 효율이 좋지 않음.
2.1.1.1.5.2.6. 연결을 위한 포인터를 찾는 시간이 필요하기 때문에 접근 속도가 느림
2.1.1.1.5.2.7. 중간 노드 연결이 끊어지면 그 다음 노드를 찾기 어려움.
2.1.1.2. 비선형 구조(Non-Linear Structure)
2.1.1.2.1. 트리(Tree)
2.1.1.2.1.1. 정점(Node, 노드)과 선분(Branch, 가지) 을 이용해 사이클을 이루지 않도록 구성한 그래프(Graph)
2.1.1.2.1.1.1. 노드(Node) : 트리의 기본 요소, 자료 항목과 다른 항목에 대한 가지(Branch) 를 합친 것.
2.1.1.2.1.1.2. 근 노드(Root Node) : 트리의 맨 위에 있는 노드.
2.1.1.2.1.1.3. 디그리(Degree, 차수) : 각 노드에서 뻗어 나온 가지의 수.
2.1.1.2.1.1.4. 단말 노드(Terminal Node) : 자식이 하나도 없는 노드, Degree 가 0인 노드.
2.1.1.2.1.1.5. 자식 노드(Child, Son Node) : 어떤 노드에 연결 된 다음 레벨의 노드들.
2.1.1.2.1.1.6. 부모 노드(Parent Node) : 어떤 노드에 연결 된 이전 레벨의 노드들.
2.1.1.2.1.1.7. 형제 노드(Sibling Node) : 동일한 부모를 갖는 노드들.
2.1.1.2.1.1.8. 트리의 디그리 : 노드들의 디그리 중에서 가장 많은 수.
2.1.1.2.2. 그래프(Graph)
2.1.1.2.2.1. 방향 그래프
2.1.1.2.2.1.1. 정점을 연결하는 선에 방향이 있는 그래프
2.1.1.2.2.1.2. n개의 정점으로 구성된 방향 그래프의 최대 간선 수 = n(n-1)
2.1.1.2.2.2. 무방향 그래프
2.1.1.2.2.2.1. 정점을 연결하는 선에 방향이 없는 그래프
2.1.1.2.2.2.2. n개의 정점으로 구성된 무방향 그래프의 최대 간선 수 = n(n-1)/2
2.2. 데이터베이스 / DBMS
2.2.1. 데이터베이스 (Database)의 구분 4가지 (공통운저)
2.2.1.1. 공용 데이터 (Shared) : 여러 응용 시스템들이 공동으로 소유하고 유지하는 자료
2.2.1.2. 통합된 데이터 (Integrated) : 자료의 중복을 최대한 배제한 자료
2.2.1.3. 운영 데이터 (Operational) : 고유한 업무를 수행하는데 필수 자료
2.2.1.4. 저장된 데이터 (Stored) : 컴퓨터가 접근할 수 있는 저장 매체에 저장된 자료
2.2.2. DBMS (Database Management System)
2.2.2.1. 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리 해주는 소프트웨어
2.2.2.2. 정의 기능 : 데이터베이스에 저장될 데이터의 타입과 구조에 대한 정의, 이용 방식, 제약 조건 등을 명시 → DDL
2.2.2.3. 조작 기능 : 사용자와 데이터베이스 사이의 인터페이스 수단을 제공하는 기능 → DML
2.2.2.4. 제어 기능 : 무결성, 보안, 권한, 병행 제어 → DCL
2.3. 데이터 입, 출력
2.3.1. SQL (Structured Query Language)
2.3.1.1. SEQUEL (1974, IBM lab) 에서 유래, 관계대수와 관계해석을 기초로 한 혼합 데이터 언어
2.3.1.2. 데이터 정의어 (DDL : Data Define Language) #도스테뷰인
2.3.1.2.1. Domain(도메인), Schema(스키마), Table(테이블), View(뷰), Index(인덱스) 을 정의하거나 변경 또는 삭제할 때 사용 하는 언어
2.3.1.3. 데이타 조작어 (DML : Data Manipulation Language)
2.3.1.3.1. Select(검색), Insert(삽입), Update(갱신), Delete(삭제) 로 저장된 데이터를 실질적으로 처리하는 데 사용하는 언어
2.3.1.4. 데이터 제어어 (DCL : Data Control Language)
2.3.1.4.1. 데이터의 무결성, 보안, 회복, 병행 제어 등을 정의하는 데 사용 되는 언어
2.3.2. 데이터 접속
2.3.2.1. SQL Mapping : 프로그래밍 코드 내 SQL 을 직접 입력 해 DBMS 의 데이터에 접속하는 기술
ex) JDBC, ODBC, MyBatis
2.3.2.2. ORM (Object Relatioal Mapping) : 객체와 관계형데이터베이스(RDB)의 데이터를 연결(Mapping) 하는 기술
ex) JPA, Hibernate, Django
2.3.3. 트랜잭션(Transaction)
2.3.3.1. 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 , 한꺼번에 수행되어야 할 일련의 연산들
2.3.3.2. COMMIT : 트랜잭션 처리가 정상적으로 종료되어 수행한 변경 내용을 DB에 반영하는 명령어
2.3.3.3. ROLLBACK : 트랜잭션 처리가 비정상으로 종료되어 트랜잭션이 행한 모든 변경 작업을 취소하고 이전 상태로 되돌리는 연산
2.3.3.4. SAVEPOINT(=CheckPoint) : 트랜잭션 내에서 RollBack 할 위치인 저장점을 지정하는 명령어, 여러 개의 save point 지정 가능
2.3.3.5. 트랜잭션의 특징 4가지 (=ACID)
2.3.3.5.1. Atomicity(원자성) : 트랜잭션 연산을 데이타베이스 모두에 반영 또는 반영하지 말아야함 (All or Noting)
2.3.3.5.2. Consistency(일관성) : 트랜잭션이 실행을 성공적으로 완료 할 시 일관성 있는 데이타베이스 상태를 유지
2.3.3.5.3. Isolation(독립성, 격리성) : 둘 이상의 트랜잭션 동시 실행 시 한 개의 트랜잭션만 접근 가능하며, 간섭은 불가하다.
2.3.3.5.4. Durability(영속성) : 성공적으로 완료된 트랜잭션의 결과는 영구적으로 반영됨.
2.4. 절차형 SQL
2.4.1. 개요
2.4.1.1. C, Java 등의 프로그래밍 언어와 같이 연속적인 실행이나 분기, 반복 등의 제어가 가능한 SQL
2.4.1.2. 일반적인 프로그래밍 언어에 비해 효율이 떨어짐
2.4.1.3. 연속적인 작업들을 처리하는데 적합
2.4.1.4. Begin ~ End 형식으로 작성되는 블록 (Block) 구조로 기능별 모듈화 가능
2.4.2. 프로시저 (Procedure) : 호출을 통해 실행되어 미리 저장해 놓은 SQL 작업 수행, 처리 결과는 한 개 이상의 값 혹은 반환을 아예 하지 않음
2.4.3. 트리거 (Trigger) : 입력, 갱신, 삭제 등의 이벤트가 발생할 때 마다 관련 작업을 자동 수행
2.4.4. 사용자 정의 함수 : 프로시저와 유사, SQL을 사용해 일련의 작업을 연속적으로 처리함, 종료 시 예약어 Return 을 사용해 단일값으로 반환
2.4.5. 테스트와 디버깅
2.4.5.1. 테스트 전 구문 오류(Syntax Error) 나 참조 오류의 존재 여부 확인
2.4.5.2. 오류 및 경고 메시지가 상세히 출력되지 않으므로 SHOW 명령어를 통해 내용 확인
2.4.5.3. 실제로 DB에 변화를 줄 수 있는 삽입 및 변경 관련 SQL 문을 주석으로 처리하고 디버깅 수행
2.4.6. 쿼리 성능 최적화
2.4.6.1. 데이터 입, 출력 애플리케이션의 성능 향상을 이해 SQL 코드를 최적화 하는 것
2.4.6.2. 성능 측정 도구(APM, Application Performance Management/Monitoring) 을 사용해 최적화 할 쿼리를 선정
2.4.6.3. 최적화할 커리에 대해 옵티마이저(Optimizer)가 수립한 실행 계획을 검토하고 SQL 코드와 인덱스 재구성
2.5. 개발 지원 도구
2.5.1. 통합 개발 환경(IDE: Intergarted Development Environment)
2.5.1.1. 개발에 필요한 환경, 편집기(Editor), 컴파일러(Compiler), 디버거(Debugger) 등의 다양한 툴을 하나의 인터페이스로 통합해 제공
ex) 이클립스(IBM), 비주얼 스튜디오(Microsoft), 엑스 코드(Apple), 안드로이드 스튜디오(Google), IDEA(JetBrain)
2.5.2. 빌드 자동화 도구
2.5.2.1. 개요 : 소스 코드를 소프트웨어로 변환하는 과정에 필요한 전처리(Preprocessing), 컴파일(Compile) 등의 작업들을 수행하는 SW
2.5.2.1. 종류
2.5.2.1.1. Ant(Another Neat Tool)
ㅇ아파치 소프트웨어 재단에서 개발한 SW
ㅇ자바 프로젝트의 공식적인 빌드 자동화 도구
ㅇXML 기반의 빌드 스크립트를 사용
ㅇ정해진 규칙이나 표준없이 개발자가 모든 것을 정의
ㅇ스크립트의 재사용이 어려움
2.5.2.1.2. Maven
ㅇ아파치 소프트웨어 재단에서 Ant의 대안으로 개발
ㅇ규칙이나 표준이 존재해 예외 사항만 기록됨
ㅇ컴파일과 빌드를 동시에 수행할 수 있음
ㅇ의존성(Dependency)을 설정하여 라이브러리를 관리
2.5.2.1.3. Gradle
ㅇ안드로이드 스튜디오의 공식 빌드 도구
ㅇ의존성 활용
ㅇ그루비(Groovy) 기반의 빌드 스크립트 사용
ㅇ플러그인 설정시, Java, C/C++, Python 등의 언어도 빌드 가능
ㅇ실행할 처리 명령들을 모아 태스크(Task)로 만든 후 태스크 단위로 실행
ㅇ이전에 사용했던 태스크를 재사용하거나 다른 시스템의 태스크를 공유 할 수 있는 빌드 캐시 기능 지원 → 빌드의 속도 향상
2.5.2.1.4. Jenkins
ㅇJava 기반의 오픈 소스 형태로 가장 많이 사용되는 빌드 자동화 도구
ㅇ서블릿 컨테이너에서 실행되는 서버 기반 도구
ㅇSvn, Git 등 대부분의 형상 관리 동구와 연동 가능
ㅇ친숙한 Web Gui 제공
ㅇ여러 대의 컴퓨터를 이용한 분산 빌드나 테스트 가능
2.5.3. 기타 협업 도구(Groupware, 그룹웨어)
ㅇ일정관리 도구 : 구글 캘린더 등
ㅇ프로젝트 관리도구 : 트렐로, 지라
ㅇ정보 공유 및 커뮤니케이션 도구 : 슬랙, 잔디, 태스크월드
ㅇ디자인 도구 : 스케치, 제플린
ㅇ아이디어 공유 도구 : 에버노트
ㅇ형상 관리 도구 : 깃허브(Github)
2.6. 소프트웨어 패키징
2.6.1. 개요
ㅇ모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것
ㅇ개발자가 아닌 사용자 중심으로 진행
2.6.2. 고려 사항
ㅇ운영체제(OS), CPU, 메모리 등에 필요한 최소 환경을 정의
ㅇ하드웨어와 함께 관리될 수 있도록 Managed Service 형태로 제공
ㅇ다양한 사용자의요구사항 반영
2.6.3. 패키징 작업 순서 7가지 (식모빌 환패변 배)
ㅇ기능 식별 → 모듈화 → 빌드 진행 → 사용자 환경 분석 → 패키징 및 적용 시험 → 패키징 변경 개선 → 배포
2.6.4. 제품 소프트웨어 패키징 도구 활용시 고려 사항
ㅇ패키징 시 사용자에게 배포되는 SW 이므로 보안 고려
ㅇ사용자 편의성을 위한 복잡성 및 비효율성 문제 고려
ㅇ제품 SW 종류에 적합한 암호화 알고리즘 적용
ㅇ다양한 이기종 연동 고려
2.7. 릴리즈 노트
2.7.1. 개요
ㅇ개발 과정에서 정리된 릴리즈 정보를 SW 고객과 공유하기 위한 문서
ㅇ개선된 작업이 있을 때마다 관련 내용을 릴리즈 노트에 담아 제공
ㅇ개발팀에서 제공하는 SW 사양에 대한 최종 승인을 얻은 후 문서화하여 제공
2.7.2. 초기버전 고려사항
ㅇHeader(머리말) : 릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 릴리즈 노트 날짜, 릴리즈 노트 버전 등
ㅇ개요 : 소프트웨어 및 변경사항 전체에 대한 간략한 내용
ㅇ목적 : 해당 릴리즈 버전에서의 새로운 기능이나 수정된 기능의 목록과 릴리즈 노트의 목적에 대한 간략한 개요
ㅇ문제 요약 : 수정된 버그에 대한 간략한 설명 또는 릴리즈 추가 항목에 대한 요약
ㅇ재현 항목 : 버그 발견에 대한 과정 설명
ㅇ수정/개선 내용 : 버그를 수정 /개선한 내용을 간단히 설명
ㅇ사용자 영향도 : 사용자가 다른 기능들을 사용하는데 있어 해당 릴리즈 버전에서의 기능 변화가 미칠 수 있는 영향에 대한 설명
ㅇSW 지원 영향도 : 해당 릴리즈 버전에서의 기능 변화가 다른 응용 프로그램들을 지원하는 프로세스에 미칠 수 있는 영향에 대한 설명
2.7.3. 추가버전 고려사항
ㅇ베타 버전이 출시되거나 긴급한 버그수정, 업그레이드와 같은 자체 기능 향상, 사용자 요청 등 특수한 상황의 경우 추가로 작성
ㅇ버그 번호를 포함한 모든 수정된 내용을 담아 릴리즈 노트 작성
ㅇ추가나 수정된 경우 자체 기능 향상과는 다른 별도의 릴리즈 버전을 출시하고 릴리즈 노트 작성
2.7.4. 릴리즈 노트 작성 순서 6가지 (식정개 영정추)
ㅇ모듈 식별 → 릴리즈 정보 확인 → 릴리즈 노트 개요 작성 → 영향도 체크 → 정식 릴리즈 노트 작성 → 추가 개선 항목 식별
2.8. 디지털 저작권 관리 (DRM : Digital Right Management)
2.8.1. 개요 : 디지털 콘텐츠의 전 과정에 걸쳐 사용되는 디지털 콘텐츠 관리 및 보호 기술
2.8.2. 디지털 저작권 관리의 흐름 (콘패클 컨보)
2.8.2.1. 콘텐츠(Contents)
2.8.2.1.1. 제공자(Provider) : 콘텐츠를 제공하는 저작권자
2.8.2.1.2. 분배자(Distributor) : 암호화된 콘텐츠를 유통하는 곳이나 사람
2.8.2.1.3. 소비자(Customer) : 콘텐츠를 구매해서 사용하는 주체
2.8.2.2. 패키저(Packager) : 콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화 하는 프로그램
2.8.2.3. 클리어링 하우스(Clearing House) : 저작권에 대한 사용 권한, 라이선스 발급, 사용량에 따른 결제 관리 등을 수행
2.8.2.4. DRM 컨트롤러(DRM Controller) : 배포된 콘텐츠의 이용 권한을 통제하는 프로그램
2.8.2.5. 보안 컨테이너(Security Container) : 콘텐츠의 원본을 안전하게 유통하기 위한 전자적 보안 장치
2.8.3. 디지털 저작권 관리의 기술 요소 8가지 (암키식저 파정크인)
2.8.3.1. 암호화 (Encryption) : 콘텐츠 및 라이선스를 암호화하고 전자서명 할 수 있는 기술
2.8.3.2. 키 관리 (Key management) : 콘텐츠를 암호화 한 키에 대한 저장 및 분배 기술
2.8.3.3. 식별기술 (Idetification) : 콘텐츠에 대한 식별 체계 표현 기술
2.8.3.4. 저작권 표현 (Right Expression) : 라이선스의내용 표현 기술
2.8.3.5. 암호화 파일 생성 (Packager) : 콘텐츠를 암호화 된 콘텐츠로 생성하기 위한 기술
2.8.3.6. 정책 관리 (Policy Management) : 라이선스 발급 및 사용에 대한 정책 표현 및 관리 기술
2.8.3.7. 크랙 방지 (Tamper Resistance) : 크랙에 의한 콘텐츠 사용 방지 기술
2.8.3.8. 인증 (Authentication) : 라이선스 발급 및 사용의 기준이 되는 사용자 인증 기술
2.9. 형상 관리
2.9.1. 소프트웨어 패키징의 형상 관리(SCM: Software Configuration Management)
2.9.1.1. 형상 관리는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동임.
2.9.1.2. 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지보수 단계에서도 수행.
2.9.2. 형상관리의 중요성
2.9.2.1. 소프트웨어의 변경 사항을 체계적으로 추적하고 통제할 수 있음.
2.9.2.2. 제품 소프트웨어에 대한 무절제한 변경 방지
2.9.2.3. 진행 정도를 확인하기 이한 기준으로 사용될 수 있음.
2.9.3. 형상 관리 기능
2.9.3.1. 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층(Tree) 구조로 구분하여 수정 및 추적에 용이하도록 하는 작업
2.9.3.2. 형상 통제(변경 관리) : 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선(베이스 라인)이 잘 반영될 수 있도록 조정하는 작업
2.9.3.3. 형상 감사 : 기준선의 무결성을 평가하기 이해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
2.9.3.4. 형상 기록(상태보고) {식통감기} : 형상의 식별, 통제, 감사 작업의 결과를 기록, 관리하고 보고서를 작성하는 작업
2.9.3.5. 버전 제어 : 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 이를 이해 특정 절차와 도구를 결합
2.9.4. 소프트웨어 버전 등록 과정 주요 용어
2.9.4.1. 저장소(Repository) : 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳
2.9.4.2. 가져오기(import) : 버전 관리가 되고 있지 않은 아무것도 없는 저장소에 처음으로 파일을 복사하는 것
2.9.4.3. 체크아웃(Checkout) : 프로그램을 수정하기 위해 저장소에서 파일을 받아 오는 것
2.9.4.4. 체크인(Checkin) : 체크아웃 한 파일의 수정을 완료한 후, 저장소의 파일을 새로운 버전으로 갱신하는 것
2.9.4.5. 커밋(Commit) : 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우 충돌(Confilct)을 알리고 도구를 이용해 수정한 후, 갱신을 완료함.
2.9.4.6. 동기화(Update) : 저장소에 있는 최신 버전으로 자신의 작업 공간(로컬)을 동기화 하는 것
2.9.5. 소프트웨어 버전 등록 과정 5가지 (임체컴업디)
2.9.5.1. Import(가져오기) → Check Out(인출) → Commit(예치) → Update(동기화) → Diff(차이)
2.9.6. 제품 소프트웨어의 형상 관리 역할
2.9.6.1. 형상 관리를 통해 이전 리버전이나 버전에 대한 정보에 접근 가능하여 배포본 관리에 유용
2.9.6.2. 불필요한 사용자의 소스 수정 제한
2.9.6.3. 동일한 프로젝트에 대해 여러 개발자 동시 개발 가능
2.10. 버전 관리 도구
2.10.1. 공유 폴더 방식
2.10.1.1. 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식
2.10.1.2. 개발자들은 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사함
2.10.1.3. 담당자는 공유 폴더의 파일을 자기 PC 로 복사해 컴파일 한 후 이상 유무 확인
2.10.1.4. 파일의 변경 사항을 데이터베이스에 기록하며 관리
ex) SCCS, RCS, PVCS, QVCS
2.10.2. 클라이언트/서버 방식
2.10.2.1. 버전 관리 자료가 중앙 시스템(서버)에 저장되어 관리되는 방식
2.10.2.2. 서버의 자료를 개발자별로 자신의 PC 로 복사해 작업 한 후 변경된 내용을 중앙 서버에 반영
2.10.2.3. 모든 버전 관리는 서버에서 수행됨
2.10.2.4. 하나의 파일을 서로 다른 개발자가 작업 할 경우 경고 메시지 출력
2.10.2.5. 서버에 문제가 생기면 다른 개발자와의 협업 및 버전 관리 작업은 중단됨
ex) CVS, SVN
2.10.3. 분산 저장소 방식
2.10.3.1. 하나의 원격 저장소와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리되는 방식
2.10.3.2. 개발자 별로 원격 저장소의 자료를 자신의 로컬 저장소로 복사해 작업한 후,
변경 된 내용을 로컬 저장소에서 우선 반영(Commit) 한 다음 이를 원격 저장소에 반영(Push)
2.10.3.3. 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용해 작업 가능
2.10.3.4. 로컬 저장소에서 작업을 수행할 수 있어 처리속도가 빠름
ex) Git, Bitkeeper
2.10.4. SVN(Subversion)
2.10.4.1. CVS 를 개선한 것으로 아파치 소프트웨어 재단에서 2000년 발표
2.10.4.2. 모든 개발 작업은 trunk 디렉터리에서 수행되며, 추가 작업은 branches 디렉터리 안에 별도의 디렉터리를 만들어
작업을 완료한 후, trunk 디렉터리와 병합(merge)
2.10.4.3. 커밋(Comiit) 할 때마다 리비전(Revision) 이 1 씩 증가
2.10.4.4. 서버는 주로 유닉스 (UNIX) 사용
2.10.4.5. 오픈 소스로 무료 사용 가능
2.10.4.6. CVS 의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능
2.10.4.7. 용어
ㅇadd : 새로운 파일이나 디렉터리를 버전 관리 대상으로 등록
ㅇcommit : 버전 관리 대상으로 등록된 클라이언트의 소스 파일을 서버의 소스 파일에 적용
ㅇupdate : 서버의 최신 commit 이력을 클라이언트의 소스 파일에 적용
ㅇcheckout : 버전 관리 정보와 소스 파일을 서버에서 클라이언트로 받아옴
ㅇlock/unlock : 서버의 소스 파일이나 디렉터리를 잠그거나 해제
ㅇimport : 아무것도 없는 서버의 저장소에 맨 처음 소스 파일을 저장하는 명령으로 한 번 사용 후 다시 사용하지 않음
ㅇexport : 버전 관리에 대한 정보를 제외한 순수한 소스 파일만을 서버에서 받아옴
ㅇinfo : 지정한 파일에 대한 이치나 마지막 수정 일자 등에 대한 정보를 표시
ㅇdiff : 지정된 파일이나 경로에 대해 이전 리비전과의 차이를 표시
ㅇmerge : 다른 디렉터리에서 작업된 버전 관리 내역을 기본 개발 작업과 병합
2.10.5. Git(깃)
2.10.5.1. 리누스 토발즈가 2005년 리눅스 커벌 개발에 사용 할 관리 도구로 개발한 이후 주니오 하마노에 의해 유지 보수 되고 있음
2.10.5.2. 원격 저장소는 여러 사람들이 협업을 이해 버전을 공동 관리하는 곳으로, 자신의 버전 관리 내역을 반영(Push) 하거나
다른 개발자들의 변경 내용을 가져올 때(Fetch) 사용
2.10.5.3. 로컬 저장소는 개발자들이 본인의 실제 개발을 진행하는 장소로 버전 관리가 수행됨
2.10.5.4. 브랜치(Branch)를 이용하면 기본 버전 관리 틀에 영향을 주지 않으면서 다양한 형태의 기능 테스팅 가능
2.10.5.5. 파일의 변화를 스냅샷(SnapShot)으로 저장
2.10.5.6. 스냅샷은 이전 스냅샷의 포인터를 가지므로 버전의 흐름 파악 가능
2.10.5.7. 용어
ㅇ add : 작업 내역을 로컬 저장소에 저장하기 위해 스테이징 영역에 추가함 '--all'
ㅇ commit : 작업 내역을 로컬 저장소에 저장
ㅇ branch : 새로운 브랜치 생성, '-d' 브랜치 삭제
ㅇ checkout : 지정한 브랜치로 이동
ㅇ merge : 지정한 브랜치의 변경내역을 현재 HEAD 포인터가 가리키는 브랜치에 반영함으로 두 브랜치를 병합
ㅇ init : 로컬 저장소를 생성
ㅇ remote add : 원격 저장소에 연결
ㅇ push : 로컬 저장소의 변경내역을 원격 저장소에 반영
ㅇ fetch : 원격 저장소의 변경 이력만을 로컬 저장소로 가져와 반영
ㅇ clone : 원격 저장소의 전체 내용을 로컬 저장소로 복제
ㅇ fork : 지정한 원격 저장소의 내용을 자신의 원격 저장소로 복제
2.10.5.8. git init → git remote add → git add -all → git commit → git push
2.11. 애플리케이션 테스트
2.11.1. 애플리케이션 테스트의 개념
2.11.1.1. 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
2.11.1.2. 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인(Validtaion)
2.11.1.3. 소프트웨어가 기능을 정확히 수행하는지 검증(Verification)
2.11.2. 애플리케이션 테스트의 기본 원리 7가지(결완초집 살정오)
2.11.2.1. 테스팅은 결함이 존재함을 밝히는 것 : 결함을 줄일 순 있지만, 결함이 없다고는 증명 할 수 없음.
2.11.2.2. 완벽한 테스팅은 불가능 : 무한 경로, 무한 입력 값으로 인한 어려움.
2.11.2.3. 개발 초기에 테스팅 시작 : 테스팅 기간 단축, 재작업 감소로 개발 기간 단축 및 결함 예방
2.11.2.4. 결합 집중 : 20% 모듈에서 80% 결함 발견, 파레토의 법칙
2.11.2.5. 살충제 패러독스 : 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함.
2.11.2.6. 테스팅은 정황에 의존적 : 소프트웨어 셩격에 맞게 테스트 실시
2.11.2.7. 오류-부재의 궤변 : 요구사항을 충족하지 못하면, 결함이 없어도 품질이 높다고 볼 수 없음.
2.12. 애플리케이션 테스트의 분류
2.12.1. 프로그램 실행 여부에 따른 테스트 2가지
2.12.1.1. 정적 테스트 : 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트
ex) 워크 스루, 인스펙션, 코드 검사
2.12.1.2. 동적 테스트 : 프로그램을 실행하여 오류를 찾는 테스트
ex) 화이스박스 테스트, 블랙박스 테스트
2.12.2. 테스트 기반에 따른 테스트 3가지 (명구경)
2.12.2.1. 명세 기반 테스트 : 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인 하는 테스트
ex) 동등 분할, 경계값 분석(블랙박스 테스트)
2.12.2.2. 구조 기반 테스트 : 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
ex) 구문 기반, 결정 기반, 조건 기반(화이트박스 테스트)
2.12.2.3. 경험 기반 테스트 : 테스터의 경험을 기반으로 수행하는 테스트
ex) 에러 추정, 체크 리스트, 탐색적 테스팅
2.12.3. 시각에 따른 테스트 2가지
2.12.3.1. 검증(Verification) 테스트 : 개발자의 시각에서 제품의 생산 과정을 테스트 하는 것
ex) 단위 테스트, 통합 테스트, 시스템 테스트
2.12.3.2. 확인(Validation) 테스트 : 사용자의 시각에서 생산된 제품의 결과를 테스트 하는 것
ex) 인수 테스트(알파 테스트, 베타 테스트)
2.12.4. 목적에 따른 테스트 7가지 (회안강성 구회병)
2.12.4.1. 회복(Recovery) : 시스템에 여러가지 결함을 주어 실패하도록 한 후 올바르게 복구 되는지를 확인
2.12.4.2. 안전(Security) : 시스템 보후 도구가 불법적인 침입으로부터 시스템을 보호 할 수 있는지를 확인
2.12.4.3. 강도(Stress) : 과부하 시에도 SW 가 정상적으로 실행되는지 확인하는 테스트
2.12.4.4. 성능(Performance) : 실시간 성능이나 전체적인 효율성을 진단하는 테스트
2.12.4.5. 구조(Structure) : SW 냅의 논리적인 경로, 소스 코드의 복잡도 등을 평가
2.12.4.6. 회귀(Regression) : SW 의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인
2.12.4.7. 병행(Parallel) : 변경된 SW 와 기존 SW에 동일한 데이터를 입력하여 결과를 비교하는 테스트
2.12.5. 테스트 커버리지 유형 6가지(구결조 조변다)
2.12.5.1. 구문 : 프로그램 내 모든 문장을 적어도 한 번 이상 실행하는 것을 기준으로 수행
2.12.5.2. 결정 : 결정 조건 내 전체 조건식이 최소한 참/거짓 한 번의 값을 가지도록 측정
2.12.5.3. 조건 : 전체 조건식 결과와 관계 없이 각 개별 조건식이 참/거짓 한 번 모두 갖도록 개별 조건식을 조합
2.12.5.4. 조건/결정 : 전체 조건식이 참/거짓 한 번씩 가지면서, 개별 조건식이 참/거짓 모두 한 번 씩 갖도록 조합
2.12.5.5. 변경/조건 : 각 개별 조건식이 다른 개별 조건식의 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함으로써,
조건/결정 커버리지를 향상 시킨 테스트 커버리지
2.12.5.6. 다중 조건 : 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100% 보장하는 테스트 커버리지
2.13. 화이트 박스 테스트, 블랙 박스 테스트
2.13.1. 화이트 박스 테스트 개요
ㅇ 모듈 안의 내용(작동)을 직접 볼 수 있음.
ㅇ 내부의 논리적인 모든 경로를 테스트해 테스트 케이스를 설계
ㅇ 소스 코드의 모든 문장을 한 번 이상 수행함으로써 진행
ㅇ 선택, 반복 등의 부분들을 수행함으로써 논리적 경로 점검
2.13.2. 화이트 박스 테스트 종류 4가지 (기조루흐)
2.13.2.1. 기초 경로 검사(Base Path Testing) : 대표적인 화이트 박스 기법, 테스트 측정 결과는 실행 경로의 기초를 정지하는 지침으로 사용
2.13.2.2. 제어 구조 검사
ㅇ 조건(Condition) : 논리적 조건을 테스트
ㅇ 루프(Loop) : 반복 구조에 맞춰 테스트
ㅇ 데이터 흐름(Data Flow) : 프로그램에서 변수의 정의와 변수 사용 위치에 초점을 맞춰 테스트
2.13.3. 블랙 박스 테스트 개요
ㅇ 모듈 안의 내용(작동)을 알 수 없음.
ㅇ SW 가 수행할 특정 기능을 알기 위해. 각 기능이 완전히 작동 되는 것을 입증하는 테스트(기능 테스트라고도 함)
ㅇ SW 인터페이스에서 실시 되는 테스트
2.13.4. 블랙 박스 테스트 종류 5가지 (동경원비오)
2.13.4.1. 동치 분할 : 프로그램의 입력 조건에 타당한 입력자료와 타당하지 않은 입력 자료의 개수를 균등하게 TC 작성 (동등 분할 기법)
2.13.4.2. 경계값 : 입력 조건의 경계값을 TC로 선정
2.13.4.3. 원인-효과 : 효용성이 높은 TC를 선정해 검사 (입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석)
2.13.4.4. 비교 : 여러 버전의 프로그램에 동일한 테스트 자료를 제공해 동일한 결과가 출력되는지 테스트
2.13.4.5. 오류 예측 : 다른 블랙박스 기법으로 찾아낼 수 없는 오류를 찾아내는 보충적 검사 기법 (데이터확인 검사)
2.14. 개발 단계에 따른 애플리케이션 테스트 4가지 (단통시인)
2.14.1. 단위 테스트(Unit Test)
ㅇ 코딩 직후 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트
ㅇ 사용자의 욕사항을 기반으로 한 기능성 테스트를 최우선 수행
ㅇ 명세 기반 테스트, 구조 기반 테스트 중 주로 구조 기반 테스트 시행
2.14.2. 통합 테스트(Integration)
ㅇ 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
ㅇ 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류 검사
ex) 빅뱅, 상향식(Cluster, Driver), 하향식(Stub)
2.14.3. 시스템 테스트(System)
ㅇ 개발된 소프트웨어가 컴퓨터 시스템에서 완벽하게 수행되는가를 점검
ㅇ 실제 사용 환경과 유사하게 만든 테스트 환경에서 테스트
ㅇ 기능적 요구사항, 비기능적 요구사항 구분
2.14.4. 인수 테스트(Acceptance)
ㅇ 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두는 테스트
2.14.4.1. 알파 테스트 : 통제된 환경에서 사용자가 개발자와함께 확인하면서 행하는 테스트 기법
2.14.4.2. 베타 테스트 : 통제되지 않은 환경에서 여러 명의 사용자가 행하는 테스트 기법
2.15. 통합 테스트
2.15.1. 상향식 통합 테스트 (Bottom Up Intergration Test)
ㅇ 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
ㅇ 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(Cluster) 필요
2.15.1.1. 상향식 순서
2.15.1.1.1. 하위 모듈들을 클러스터(Cluster)로 결합
2.15.1.1.2. 더미 모듈인 드라이버(Driver) 작성
2.15.1.1.3. 통합된 클라스터 단위로 테스트
2.15.1.1.4. 테스트 완료 후 클러스터는 프로그램 구조의 상위로 이동해 결합하고 드라이버는 실제 모듈로 대체
2.15.2. 하향식 통합 테스트 (Top down Intergration Test)
ㅇ 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트
ㅇ 깊이 우선, 넓이 우선 통합법
ㅇ 테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있음
ㅇ 상위 모듈에서는 테스트 케이스 사용하기 어려움
2.15.2.1. 하향식 순서
2.15.2.1.1. 주요 제어 모듈은 작성된 프로그램을 사용, 주요 제어 모듈의 종속 모듈은 스텁(Stub) 으로 대체
2.15.2.1.2. 깊이 우선 또는 넓이 우선 등 통합 방식에 따라 Stub 들이 한번에 하나씩 실제 모률로 교체됨
2.15.2.1.3. 모듈이 통합될 때 마다 테스트 실시
2.15.2.1.4. 새로운 오류 확인을 위한 회귀 테스트 실시
2.15.3. 혼합식 통합 테스트
ㅇ 하위 수준에서는 상향식, 상위 수준에서는 하향식, 각각 사용하여 최적의 테스트를 지원
ㅇ 샌드위치식
2.16. 테스트 케이스, 테스트 시나리오, 테스트 오라클, 테스트 하네스
2.16.1. 케이스(Case)
ㅇ 구현된 SW 가 사용자의 요구사항을 정확하게 준수했는지 확인하기 위해 설계된 입력값, 실행조건, 기대결과 등으로 구성된 명세서
ㅇ 명세 기반 테스트(블랙박스 테스트)의 설계 산출물에 해당
ㅇ 미리 설계해두면 테스트 오류 방지 및 테스트 수행 자원의 낭비를 막을 수 있음
2.16.2. 시나리오(Scenario)
ㅇ TC 를 적용하는 순서에 따라 여러 개의 TC 들의 집합
ㅇ TC 를 적용하는 구체적인 절차를 명세한 문서
ㅇ 시스템, 모듈, 항복별 등 과 같이 여러 개의 시나리오로 분리해 작성
ㅇ 사용자의 요구 사항과 설계 문서 등을 토대로 작성
2.16.3. 테스트 오라클(Oracle)
ㅇ 테스트 결과가 올바른지 판단하기 이해 사전에 정의된 참 값을 대입해 비교하는 활동
ㅇ 제한된 검증 : 모든 TC 에 적용 할 수 없음.
ㅇ 수학적 기법 : 값을 수학적 기법으로 구할 수 있음.
ㅇ 자동화 기능 : 프로그램 실행, 결과 비교, 커버리지 측정 등을 자동화 할 수 있음.
2.16.3.1. 오라클 종류 4가지 (참샘휴일)
2.16.3.1.1. 오라클 참(true) : 모든 TC 의 입력값에 대해 기대하는 결과를 제공하는 오라클, 발생된 모든 오류를 검출 할 수 있음.
2.16.3.1.2. 오라클 샘플링(sampling) : 특정한 몇몇 테스트 TC의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클
2.16.3.1.3. 오라클 휴리스틱(heuristic, 추정) : 샘플링 오라클을 개선, TC 의 입력값에 대해 결과를 제공하고 나머지들은 추정으로 처리
2.16.3.1.4. 오라클 일관성(Cosistent) : 변경이 있을 때 TC 의 수행전과 후의 결과값이 동일한지 확인
2.16.4. 테스트 하네스(Harness) 종류 6가지 (드스슈 케스목)
2.16.4.1. 테스트 드라이버(Driver) : 컴포넌트, 시스템을 제어하거나 호출하는 컴포넌트를 대체하는 SW 컴포넌트 또는 테스트 툴
2.16.4.2. 테스트 스텁(Stub) : 골격만 있는 또는 특별한 목적의 SW 컴포넌트를 구현, 스텁을 호출하거나 스텁에 의존적인 컴포턴트를 개발,
테스트 할때 사용, 스텁은 호출된 컴포넌트를 대체
2.16.4.3. 테스트 슈트(Suites) : 테스트 대상 컴포넌트나 모듈 등 시스템에 사용되는 TC 의 잡합
2.16.4.4. 테스트 케이스(Case) : 사용자의 요구사항을 준수했는지 확인하기 위한 입력값, 실행 조건, 기대 결과 등으로 만들어진 Test 항목 명세서
2.16.4.5. 테스트 스크립트(Script) : 자동화된 테스트 실행 절차에 대한 명세서
2.16.4.6. 테스트 목 오프젝트(Mock Object) : 사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체
2.17. 결함 관리
2.17.1. 결함 상태 추적 (분추에)
2.17.1.1. 결함 분포 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
2.17.1.2. 결함 추세 : 테스트 진행 시간에 따른 결함 수의 추이 분석
2.17.1.3. 결함 에이징(fault aging) : 특정 결함 상태로 지속되는 시간 측정
ex) 1개의 결함이 30분 동안 지속됨
2.17.2. 결함 추적 순서
2.17.2.1. open(등록) : 테스터와 품질 관리 담장자에 의해 발견된 결함이 등록 됨
2.17.2.2. reviewed(검토) : 등록된 결함을 테스터, 품질 관리 담당자, 프로그램 리더, 담당 모듈 개발자에 의해 검토
2.17.2.3. assigned(할당) : 결함을 수정하기 위해 개발자와 문제 해결 담당자에게 결함이 할당
2.17.2.4. resolved(수정) : 개발자가 결함 수정을 완료한 상태
2.17.2.5. deferred(보류) : 결함의 수정이 불가능해 연기
2.17.2.6. closed(종료) : 결함이 해결되어 테스터와 품질 관리 담당자가 종료를 승인
2.17.2.7. clarified(해제) : 종료 승인한 결함을 검토하여 결함이 아니라고 판명한 상태
2.17.3. 결함 심각도, 결함 우선순위
2.17.3.1. 결함 심각도 : 치명적 > 주요 > 보통 > 경미 > 단순 / critical > major > normal > minor > simple
2.17.3.2. 결함 우선순위 : 치명적 > 높음 > 보통 > 낮음 / Critical > High > medium > low
2.18. 애플리케이션 성능 분석
2.18.1. 애플리케이션 성능 4가지(처응경자)
2.18.1.1. 처리량(throughput) : 일정 시간 내 애플리케이션이 처리하는 일의 양
2.18.1.2. 응답 시간(Response) : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때 까지 걸린 시간
2.18.1.3. 경과 시간(Turn around) : 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때 까지 걸린 시간
2.18.1.4. 자원 사용률(Resource usage) : 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU, 메모리, 네트워크 사용량 등 자원 사용률
2.18.2. 애플리케이션 성능 저하 원인 분석
ㅇ DB 에 필요 이상의 많은 데이터를 요청한 경우
ㅇ 커넥션 풀(Connection Pool) 의 크기를 너무 작거나 크게 설정한 경우
ㅇ JDBC 나 ODBC 같은 미들웨어를 사용한 후 종료하지 않아 연결 누수가 발생한 경우
ㅇ 대량의 파일을 업로드 하거나 다운로드 해 처리 시간이 길어진 경우
2.18.3. 소스 코드 최적화
2.18.3.1. 클린 코드 작성 원칙 4가지(가단의중추)
ㅇ 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화
2.18.4. 소스 코드 품질 분석 도구의 종류
2.18.4.1. 정적 분석 도구 : pmd, cppcheck, checkstyle, SonarQube, ccm, cobertuna
2.18.4.2. 동적 분석 도구 : Avalanche, Valgrind
2.19. 모듈 연계
2.19.1. EAI (Enterprise Application Integration)
: 기업 내 각종 애플리케이션 및 플랫폼 간의 정보 전달, 연계, 통합 등 상호 연동이 가능하게 해주는 솔루션
2.19.1.1. EAI 유형 4가지 (포허메하)
2.19.1.1.1. 포인트 투 포인트(Point to Point)
2.19.1.1.2. 허브앤 스포크(Hub & Spoke)
2.19.1.1.3. 메시지 버스(Message Bus, ESB 방식)
2.19.1.1.4. 하이브리드(Hybrid)
2.19.1. ESB(Enterprise Service Bus)
ㅇ 애플리케이션 간 연계, 데이터 변환, 웹 서비스 지원 등 표준 기반의 인터페이스를 제공하는 솔루션
ㅇ 애플리케이션 통합 측면에서 EAI 와 유사하지만 애플리케이션 보다는 서비스 중심의 통합을 지향
ㅇ 결합도를 약하게 유지함 (Loosely Coupling)
ㅇ 관리 및 보안 유지가 쉽고, 높은 수준의 품질 지원이 가능
2.20. 인터페이스 구현, 보안
2.20.1. 데이터 통신을 이용한 인터페이스 구현
ㅇ 애플리케이션 영역에서 인터페이스 형식에 맞춘 데이터 포맷을 인터페이스 대상으로 전송하고 이를 수신 측에서 파싱(parsing) 해 해석
ㅇ 주로 Json 이나 Xml 형식의 데이터 포맷을 사용해 인터페이스를 구현
2.20.1.1. Json(JavaScript Object Notation)
: 속성-값 쌍(Attribute Value pair) 으로 이뤄진 데이터 객체를 전달 하기 이해 사람이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷
2.20.1.2.XML(eXtensible Markup Language)
ㅇ 특수한 목적을 갖는 마크업 언어를 만드는 데 사용하는 다목적 마크업 언어
ㅇ 웹페이지의 기본 형식인 HTML의 문법이 각 브라우저에서 상호 호환적이지 못하는 것과
ㅇ SGML(Stand generalized markup language) 의 복잡함을 해결하기 위해서 개발
2.20.2. 인터페이스 엔터티를 이용한 인터페이스 구현
ㅇ 인터페이스가 필요한 시스템 사이에 별도의 인터페이스 엔터티로 상호 연계 하는 방식
ㅇ 일반적으로 인터페이스 테이블을 엔터티로 활용
ㅇ 송, 수신 인터페이스 테이블 구조는 상황에 따라 서로 다르게 설계 할 수도 있음.
2.20.3. 인터페이스 보안 기능 적용
ㅇ네트워크, 애플리케이션, 데이터베이스 영역에서 적용
ㅇ스니핑(sniffing): 네트워크의 중간에서 남의 패킷 정보를 도청하는 해킹 유형
ㅇ소프트웨어 개발 보안(시큐어 코딩, Secure Coding) : SW 개발 과정에서 지켜야 할 일련의 보안 활동
ex) 입력 데이터 검증 표현, 보안 기능, 시간 및 상태, 에러 처리, 코드 오류, 캡슐화, API 오용 (입보시 에코캡아)
2.21. 인터페이스 구현 검증, 오류 확인
2.21.1. 인터페이스 구현 검증 도구 6가지 (엑스피 엔셀와)
2.21.1.1. xUnit : 다양한 언어를 지원하는 단위 테스트 프레임 워크
2.21.1.2. STAF : 서비스 호출 및 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임 워크
2.21.1.3. FitNesse : 웹 기반 테스트 케이스 설계, 실행, 결과 확인 등을 지원하는 테스트 프레임 워크
2.21.1.4. NTAF : STAF의 장점인 재사용 및 확장성과 FitNesse 의 장점인 협업 기능을 통합한 NHN(Naver) 의 테스트 자동화 프레임워크
2.21.1.5. Selenium : 다양한 브라우저 및 개발 언어 지언하는 웹 애플리케이션 테스트 프레임워크
2.21.1.6. watir : Ruby 언어를 사용하는 애플리케이션 테스트 프레임워크
2.21.2. 인터페이스 오류 발생 즉시 확인
ㅇ 오류 메시지 알람 표시
ㅇ 오류 SMS 발송
ㅇ 오류 내역 이메일 발송
2.21.3. 인터페이스 오류 발생 주기적인 확인
2.21.3.1. 오류 확인 방법
2.21.3.1.1. 인터페이스 오류 로그 확인 : 오류를 별도의 로그파일로 생성해 보관함, 자세한 오류 원인 및 내역을 확인 할 수 있음.
2.21.3.1.2. 인터페이스 오류 테이블 확인 : 오류사항의 확인이 쉬워 관리가 용이함,오류사항이 구체적이지 않아 별도의 분석이 필요.
2.21.3.1.3. 인터페이스 감시(APM) 도구 사용 : 스카우터(Scouter) 나 제니퍼(Jennifer) 등의 인터페이스 감시 도구를 사용해 주기적 확인.
2.22. 2과목 추가 정리
2.22.1. 트리 순회방법 (Traversal)
2.22.1.1. 전위 순회 (Pre-Order) : Root → left → right
2.22.1.2. 중위 순회 (In-Order) : left → root → right
2.22.1.3. 후위 순회 (Post-Order) : left → right → root
2.22.2. 이진 트리 : 디그리(Degree, 차수) 가 2 이하인 노드로 구성 돼 자식이 둘 이하로 구성 된 트리
2.22.3. 논리 데이터 저장소 3가지 (개속관)
2.22.3.1. 개체(Entity) : 관리할 대상이 되는 실체
2.22.3.2. 속성(Attribute) : 관리할 정보의 구체적 항목
2.22.3.3. 관계(Relationship) : 개체 간 대응 관계
2.22.4. 물리 데이터 저장소
ㅇ 논리 데이터 저장소에서 물리 데이터 저장소 모델로 변환하는 절차
ㅇ 단위 개체를 테이블로 변환 → 속성을 컬럼으로 변환 → UID(Unique Identifier) 를 기본키(Primary)로 변환
→ 관계를 외래키(Foreign)로 변환 → 컬럼 유형(Type)과 길이(Length) 정의 → 반정규화(De-normalization) 수행
2.22.5. 인덱스(Index)
2.22.5.1. 분포도 (Selectivity) 10 ~ 15 % 이내
2.22.5.2. 인덱스 컬럼 선정
2.22.5.2.1. 수정이 빈번하지 않는 컬럼
2.22.5.2.2. order by, group by, union 이 빈번한 컬럼
2.22.5.2.3. 분포도가 좋은 컬럼은 단독 인덱스로 생성
2.22.5.2.4. 인덱스들이 자주 조합되어 사용되는 컬럼은 결합 인덱스로 생성
2.22.5.3. 설계시 고려사항
2.22.5.3.1. 지나치게 많은 인덱스는 오버헤드(Overhead) 발생
2.22.5.3.2. 인덱스만의 추가적인 저장 공간이 필요
2.22.5.3.3. 넓은 범위 인덱스 처리시 오히려 전체 처리보다 많은 오버헤드를 발생시킴
2.22.6. 뷰
ㅇ 기본 테이블로부터 유도된, 이름을 가지는 가상 테이블로 기본 테이블과 같은 형태의 구조 사용, 조작도 기본 테이블과 유사.
ㅇ 가상 테이블이기 때문에 물리적으로 구현되어 있지 않지만 사용자에게는 있는 것 처럼 간주됨.
ㅇ 데이터의 논리적 독립성을 제공할 수 있음.
ㅇ 정의된 뷰로 다른 뷰를 정의할 수 있음.
ㅇ 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블이나 뷰를 기초로 정의된 다른 뷰도 자동으로 삭제됨.
2.22.6.1. 속성
2.22.6.1.1. Replace : 뷰가 이미 존재하는 경우 재생성
2.22.6.1.2. Force : 본 테이블의 존재 여부와 관계 없이 뷰 생성
2.22.6.1.3. NoForce : 기본 테이블이 존재할 때만 뷰 생성
2.22.6.1.4. With Check Option : 서브 쿼리 내의 조건을 만족하는 행만 변경
2.22.6.1.5. With Read Only : 데이터 조작어(DML) 작업 불가
2.22.6.2. 장점
2.22.6.2.1. 논리적 데이터 독립성 제공
2.22.6.2.2. 접근 제어를 통한 자동 보안 제공
2.22.6.3. 단점
2.22.6.3.1. 독립적인 인덱스를 가질 수 없음.
2.22.6.3.2. 뷰의 정의를 Alter 로 변경할 수 없음 → Drop 하고 새로 Create 해야 함.
2.22.6.3.3. 뷰로 구성된 내용에 대한 삽입, 삭제, 갱신, 연산에 제약이 따름
2.22.7. 클러스터
ㅇ 인덱스의 단점을 해결한 기법 → 분포도(Selectivity) 가 넓을 수록 유리하다.
ㅇ 분포도가 넓은 테이블의 클러스터링은 저장 공간의 절약이 가능
ㅇ 대량의 범위를 자주 액세스(조회) 하는 경우 적용
ㅇ 인덱스를 사용한 처리 부담이 되는 넓은 분포도에 활용
2.22.7.1. 클러스터 테이블 선정
2.22.7.1.1. 수정이 빈번하지 않은 테이블
2.22.7.1.2. order by, group by, union 이 빈번한 테이블
2.22.7.1.3. 처리 범위가 넓어 문제가 발생하는 경우 단일 테이블 클러스터링
2.22.7.1.4. 조인이 많아 문제가 발생하는 경우 다중 테이블 클러스터링
2.22.7.2. 설계시 고려 사항 : 조회 속도를 향상 시켜주지만, 입력, 수정, 삭제 시 성능이 저하 됨(부하가 증가)
2.22.8. 파티션(Partition)
2.22.8.1. 파티션의 종류 4가지 (레해리컴)
2.22.8.1.1. 레인지 파티셔닝(Range, 범위 분할) : 지정한 열의 값을 기준으로 분할 (일별, 월별, 분기별)
2.22.8.1.2. 해시 파티셔닝(Hash, 해시 분할) : 해시 함수에 따라 데이터 분할
2.22.8.1.3. 리스트 파티셔닝(List) : 미리 정해진 그룹핑 기준에 따라 분할
2.22.8.1.4. 컴포지트 파티셔닝(Composite, 조합 분할) : 범위 분할 이후 해시 함수를 적용 (범위 분할 + 해시 분할)
2.22.8.2. 파티션의 장점 4가지 (성가백경)
2.22.8.2.1. 성능 향상
2.22.8.2.2. 가용성 향상
2.22.8.2.3. 백업 가능
2.22.8.2.4. 경합 감소
2.22.9. PL/SQL
2.22.9.1. 구성 3가지 (선실예)
2.22.9.1.1. 선언부(Declare) : 실행부에서 참조할 모든 변수, 상수, Cursor, Exception 선언
2.22.9.1.2. 실행부(Begin/End) : Begin과 End 사이에 기술되는 영역, 데이터를 처리할 SQL 문과 PL/SQL 블록을 기술
2.22.9.1.3. 예외부(Exception) : 실행부에서에러가 발생했을 때 문장 기술
2.22.9.2. 장점 4가지 (컴모절에) : 컴파일 불필요, 모듈화 기능, 절차적 언어 사용, 에러 처리
2.22.9.3. PL/SQL 을 활용한 저장형 객체 활용 4가지 (프함패트) : 저장된 프로시저, 저장된 함수, 저장된 패키지, 트리거(Trigger)
2.22.10. 단위 모듈 구현의 원리 4가지 (정분추독)
2.22.10.1. 정보 은닉(information hiding) : 변경 가능성이 있는 모듈을 타 모듈로부터 은폐
2.22.10.2. 분할과 정복(divide & conquer) : 복잡한 문제를 분해, 모듈 단위로 문제 해결
2.22.10.3. 데이터 추상화(data abstraction) : 각 모듈 자료 구조를 액세스 하고 수정하는 함수내에 자료 구조의 표현 내역을 은폐
2.22.10.4. 모듈 독립성(module inpendency) : 낮은 결합도와 높은 응집도
2.22.11. 알고리즘 설계 기법 4가지 (분동탐백)
2.22.11.1. 분할과 정복(Divide and Conquer) : 문제를 나눌 수 없을 때까지 나누고, 각각을 풀면서 다시 병합해 문제의 답을 얻음
2.22.11.2. 동적계획법(Dynamic programming) : 어떤 문제를 풀기위해 그 문제를 더 작은 문제의 연장선으로 생각하고, 과거에 구한 해를 활용
2.22.11.3. 탐욕법(Greedy) : 결정을 해야할 때마다, 그 순간에 가장 좋다고 생각되는 것을 해답으로 선택
2.22.11.4. 백트래킹(Backtracking) : 어떤 노드의 유망성 점검 후, 유망하지 않으면 그 노드의 부모 노드로 되돌아 간 후 다른 자손 노드를 검색
2.22.12. 시간 복잡도에 따른 알고리즘
2.22.12.1. O(1) : 상수형 복잡도, 자료 크기와 무관하게 항상 일정한 속도로 작동 (해시 함수)
2.22.12.2. O(logN) : 로그형 복잡도, 문제를 해결하기 위한 단계의 수가 log2N번 만큼의 수행 시간을 가짐 (이진 탐색)
2.22.12.3. O(n) : 선형 복잡도, 입력 자료를 차례로 모두 처리, 수행 시간이 자료 크기가 정비례 (순차 탐색)
2.22.12.4. O(N logN) : 선형 로그형 복잡도, 문제를 해결하기 위한 단계의 수가 Nlog2N번 만큼 수행 (퀵 정렬, 합병 정렬)
2.22.12.5. O(N2) : 제곱형 주요 처리 루프 구조가 2중 인 경우, N의 크기가 작을 땐 N2 가 N log2N 보다 느릴 수 있다.(선택, 버블, 삽입 정렬)
2.23. 2과목 추가 정리 기출 문제
2.23.1. SW 품질 측정을 위해 개발자 관점에서 고려해야 할 항목
2.23.1.1. 정확성, 무결성, 사용성
2.23.2. 인터페이스 보안을 위해 네트워크 영역에 적용되는 솔루션
2.23.2.1. IPSec, SSL, S-HTTP
2.23.3. 외계인 코드(Ailen Code) : 아주 오래되거나 참고 문서 개발자가 없어 유지보수 작업이 어려운 프로그램
2.23.4. IPC(Inter-Process Communication)
: 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합으로,
복수의 프로세스를 수행하며 이뤄지는 프로세스 간 통신까지 구현 가능
2.23.4.1. 대표적인 메소드 (SSS PM)
2.23.4.1.1. Shared Memory : 다수의 프로세스가 공유 가능한 메모리를 구성하여 프로세스 간 통신 수행
2.23.4.1.2. Socket : 네트워크 소켓을 이용해 네트워크를 경유하는 프로세스들 간 통신 수행
2.23.4.1.3. Semaphores : 공유 자원에 대한 접근 제어를 통해 프로세스 간 통신 수행
2.23.4.1.4. Pipes & named Pipes : Pipe 라고 불리는 FIFO 형태로 구성된 메모리를 여러 프로세스가 공유하여 통신 수행.
하나의 프로세스가 Pipe 이용 중이라면 다른 프로세스는 접근 할 수 없음
2.23.4.1.5. Message Queueing : 메시지가 발생하면 이를 전달하는 형태로 프로세스 간 통신 수행
2.23.5. 정렬 알고리즘
2.23.5.1. 선택 정렬
2.23.5.2. 버블 정렬 (보통 실기 코딩 문제로 나옴)
2.23.5.3. 삽입 정렬
2.23.6. McCabe 의 Cyclomatic 수
: Edge(선) - Node(점) + 2 → 6 - 4 + 2 = 4
2.23.7. 소프트웨어 재공학이 소프트웨어 재개발에 비해 갖는 강점
: 위험 부담 감소, 비용 절감, 시스템 명세의 오류 억제, 개발 시간의 감소
2.23.8. 소프트웨어 품질 모표
2.23.8.1. 소프트웨어 운영 특성
2.23.8.1.1. 정확 : 사용자의 요구 기능을 충족
2.23.8.1.2. 신뢰 : 정확하고 일관된 결과를 얻기 위해 요구된 기능을 오류 없이 수행
2.23.8.1.3. 효율 : 요구되는 기능을 수행하기 위한 필요한 자원의 소요 정도
2.23.8.1.4. 무결 : 허용되지 않은 사용이나 자료의 변경을 제어
2.23.8.1.5. 사용 용이 : 사용에 필요한 노력을 최소화 하고 쉽게 사용할 수 있는 정도
2.23.8.2. 소프트웨어 변경 수용 능력
2.23.8.2.1. 유지보수 : 변경 및 오류 사항의 교정에 대한 노력을 최소화하는 정도
2.23.8.2.2. 유연 : 소프트웨어를 얼마만큼 쉽게 수정할 수 있는가
2.23.8.2.3. 시험 역량 : 의도된 기능이 수행되도록 보장하기 위해 프로그램을 시험할 수 있는 정도
2.23.8.3. 소프트웨어 적용 능력
2.23.8.3.1. 이식 : 다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
2.23.8.3.2. 재사용 : 전체나 일부 소프트웨어를 다른 목적으로 사용할 수 있는가
2.23.8.3.3. 상호 운용 : 다른 소프트웨어와 정보를 교환 할 수 있는 정도
2.23.9. 소프트웨어 공학의 기본 원칙
ㅇ 품질 높은 소프트웨어 상품 개발
ㅇ 지속적인 검증 시행
ㅇ 결과에 대한 명확한 기록 유지
2.23.10. AJAX(Asynchronous JavaScript and XML)
: JavaScript 를 사용한 비동기 통신 기술 클라이언트와 서버 간에 XML 데이터를 주고 받는 기술
2.23.11. 스키마의 종류
2.23.11.1. 외부(external) : 사용자의 관점에서 보여주는 데이터베이스 구조로 전체 데이터베이스의 일부이므로 서브 스키마라고도 함
2.23.11.2. 내부(Internal) : 저장장치의 입장에서 데이터베이스 전체가 저장되는 방법을 명세한 것으로 단 하나만 존재
2.23.11.3. 개념(Conceptual) : 전체 사용자 또는 모든 응용 시스템이 필요한 데이터 베이스 구조로 조직 전체의 데이터 베이스로 단 하나만 존재
2.23.12. 해싱함수
2.23.12.1. 폴딩 : 레코드 키를 여러 부분으로 나누고, 나눈 부분의 각 숫자를 더하거나 XOR 한 값을 홈 주소로 사용하는 방식
2.23.12.2. 제산 : 레코드 키로 해시표의 크기보다 큰 수 중에서 가장 작은 소수로 나눈 나머지를 홈 주소로 삼는 방식
2.23.12.3. 기수변환 : 키 숫자의 진수를 다른 진수로 변환시켜 주소 크기를 초과한 높은 자릿수를 절단하고, 이를 다시 주소 범위에 맞게 조정
2.23.12.4. 숫자분석(계수분석) : 키 값을 이루는 숫자의 분포를 분석, 비교적 고른 자리를 필요한 만큼 택해서 홈 주소로 삼는 방식
'정처기 > 필기' 카테고리의 다른 글
| 정보처리기사 필기 내용 요약 (5과목) (0) | 2023.04.25 |
|---|---|
| 정보처리기사 필기 내용 요약 (4과목) (0) | 2023.04.24 |
| 정보처리기사 필기 내용 요약 (3과목) (1) | 2023.04.23 |
| 정보처리기사 필기 내용 요약 (1과목) (0) | 2023.04.21 |
