개발자 끄적끄적

파이썬 기초

햏치 — Wed, 11 Sep 2024 15:33:10 +0900

<파이썬>
- 객체지향 언어

<객체 다루기>
- 객체지향 특성과 강점.
  - 객체 내부에 있는 함수를 멤버함수 혹은 메소드, 변수를 멤버 변수라고 한다
  - 객체는 능동적 : 자신이 소유한 멤버 함수를 능동적으로 호출

<객체 확인하기>
- type : 객체의 클래스를 알려준다
- dir : 사용 가능한 멤버 함수를 알려준다

<OpenCV에서 영상은 numpy.ndarray 클래스 형의 객체>
- numpy는 다차원 배열을 위한 사실상 표준 모듈
  - 이런 이유로 OpenCV는 영상을 numpy.ndarray로 표현
  - OpenCV가 다루는 영상은 numpy가 제공하는 다양한 기능(함수)을 사용할 수 있다

- 영상의 표현
  - 화소(Pixel : Picture Element)의 위치(r,c) 또는 (y,x)
  - 화소값 조사
    - ex) print(img[0,0,0], img[0,0,1], img[0,0,2]) #(0,0) 화소 조사
    - ex) print(img[0,1,0], img[0,1,1], img[0,1,2]) #(0,1) 화소 조사

JDBC Properties 설정 방법

햏치 — Thu, 1 Aug 2024 18:59:19 +0900

<스프링에서 JDBC Properties 설정하는 방법>

1. MySQL
JDBC.Driver=cohttp://m.mysql.jdbc.Driver
JDBC.ConnectionURL=jdbc:mysql://URL주소:포트번호/DB명
JDBC.Username=계정명
JDBC.Password=비밀번호

2. Oracle
JDBC.DriverClassName=oracle.jdbc.driver.OracleDriver
JDBC.url=jdbc:oracle:thin@URL주소:1521:xe
JDBC:Username=계정명
JDBC:password=비밀번호

3. MS-SQL
JDBC.DriverClassName=cohttp://m.microsoft.sqlserver.jdbc.SQLServerDriver
JDBC.url=jdbc:sqlserver://로컬명;DatabaseName="DB명"
JDBC.Usename=계정명
JDBC.password=비밀번호

git hub 연결/해제

햏치 — Fri, 12 Jul 2024 17:03:39 +0900

1. 깃허브 연결 해제
  1) 연결되어 있는 원격 저장소 확인 : git remote -v
  2) 원격 저장소 연결 해제 : git remote remove origin
  3) 해제 상태 확인 : git remote -v

2. 깃허브 레포지토리 연결
  1) 원격 저장소 연결 : git remote add origin http://gitub.com/계정명/레포지토리명.git
  2) main(깃허브 기본 저장소 브랜치명) branch 생성 : git branch -M main
  3) main branch origin에 push : git push -u origin main

<error:failed to push some refs to 'repository 경로' 에러 해결>
git pull
git add .
git commit -m "~~"
git push

보조 저장장치의 관리

햏치 — Tue, 4 Jun 2024 00:24:49 +0900

<파일(File)>
- 사용자나 응용 프로그램의 관점
  - 정보를 저장하고 관리하는 논리적인 단위
  - 저장 형식과 내용은 프로그래머에 의해 결정

- 컴퓨터 시스템의 관점
  - 정보를 저장하는 최소 단위의 컨테이너
  - 바이트의 나열
  - OS에 의해 관리/조작됨

<파일 입출력 주소>
- 응용 프로그램은 파일 내 바이트 주소 사용
  - 파일 내 바이트 위치(offset)

- 운영체제는 논리 블록 주소(LBA, logical block addr.) 사용
  - 저장 매체를 1차원의 연속된 데이터 블록들로 봄
    - 저장 매체의 종류와 무관
  - 파일을 블록 크기로 분할하고, 디스크에 분산 저장

- 디스크 장치는 디스크 물리 주소 사용
  - 디스크의 섹터 위치를 나타내는 주소
    - CHS 물리주소 = (실린더번호, 헤드번호, 섹터번호)
    - 디스크 장치의 펌웨어가 LBA를 CHS로 변환

<하드 디스크 드라이브(HHD)의 구조>

<자기 디스크(Magnetic Disk)구조>

<주소 계층화의 의미>
- 각 계층의 독립적 구현이 용이
  - 응용 프로그램 개발 가능
    - 파일을 바이트 나열로 가정하고 입출력 프로그래밍
    - OS 종류나 저장장치의 종류와 무관하게 파일 입출력 가능

  - 운영체제 개발
    - 저장 매체의 종류와 무관하게 OS 구현 가능
    - 그저 바이트 주소를 LBA로 바꿈으로 장치 독립적으로 처리

  - 저장 장치 개발
    - app, OS와 무관하게 저장 장치 개발

<계층화와 접근 주소의 변환>

<파일 시스템(File System)>
- 저장 매체에 파일을 생성해 저장하고 읽고 쓰는 OS의 기능에 대한 통칭

<파일 시스템의 구성>
- 파일 시스템의 논리 구조
  - 디렉터리 파일로 이루어지는 계층적인 트리 구조

- 저장소에 구축되는 파일 시스템
  - 사용 블록, 빈 블록에 대한 정보 유지

- 커널 내 파일 입출력 기능 구현
  - 파일 생성, 열기, 읽기, 쓰기, 닫기, 삭제
  - 파일 메타 정보 읽기/변경

- app을 위한 시스템 호출 제공
  - open(), close(), read(), write(), seek() 등

<파일 읽기를 통한 입출력 개요>

<보조 저장 장치 접근의 특징>
- 각 계층의 관점과 역할이 잘 구분됨
- OS는 app이 저장장치의 물리적 특성(종류, 구조, 위치 등)과 무관하게 입출력 지원 가능
- 데이터는 여러 단계의 버퍼를 통해 전달됨
  - 시간 오버헤드 발생 가능
  - 동일 내용 반복 접근시 캐시 효과

<파일 시스템 구조>
- 트리 형태의 계층 구조로 구성
  - 파일
  - 디렉터리

<파일 시스템(File System)>

<디렉터리(directory)>
- 자신에게 포함된(논리적으로) 파일에 대한 목록을 담고 있는 특수 파일
  - 단, 파일 블록들이 저장된 디스크 상의 위치는 FAT/i-node라는 특별한 곳에 따로 저장

<파일시스템 관리 위한 메타 정보>
- 파일 시스템 전체에 대한 메타 정보
  - 파일 시스템의 전체 크기
  - 파일 시스템의 현재 사용 크기
  - 파일 시스템의 빈 크기 및 빈 블록 목록

- 각 파일에 대한 메타 정보
  - 파일 이름, 파일 크기
  - 파일 생성, 수정, 최근 접근 시각
  - 생성 사용자 정보 및 접근 권한

<파일 시스템의 종류>
- FAT(File Allocation Table) 파일 시스템
  - MS-DOS에서 사용. 최근에도 사용되고 있음

- UFS(Unix File System)
  - Unix에서 사용

- ext2, ext3, ext4
  - 리눅스에서 사용

- HFS(Hierarchical File System), AFS
  - Mac 운영체제에서 사용

- NTFS(New Technology File System)
  - FAT 개선, 리눅스에서도 지원됨

<파일 시스템 구현 이슈>
- 디스크 장치에 비어 있는 블록들의 리스트를 어떻게 관리할 것인가?
- 파일 블록들을 디스크의 어느 영역에 어떻게 분산 배치할 것인가?
- 파일 블록들이 저장된 디스크 내 위치들을 어떻게 관리할 것인가?

<Unix 파일 시스템의 구조>

*부트블록
- 부팅 때 메모리에 적재
- OS를 적재하는 코드

*수퍼 블록
- 파일 시스템 마테 정보 저장(매우 중요한 영역)

*i-node
- 파일 메타 정보 저장
- 파일당 1개의 i-node 필요
  - ex) 파일 타입과 접근 권한
        파일 소유자 ID
        파일 그룹 ID(파일 접근 권한을 가진 그룹ID)
        파일 크기
        마지막 파일 접근 시각
        마지막 파일 수정 시각
        마지막 i-node 수정 시작
        파일 블록들에 대한 인덱스 등

*i-node 리스트(i-node들이 나열된 일련의 목록)
- i-node 리스트의 크기는 디스크 포맷 시 결정, 포맷 후 i-node의 개수는 고정
- 파일이 생성될 때마다 빈 i-node 할당, 메타 정보 기록
- i-node의 번호는 0부터 시작
- 루트 디렉터리의 i-node 번호는 수퍼 블록에 기록, 리눅스의 경우2, 유닉스의 경우1
- 0번 i-node는 오류 처리를 위해 예약

*데이터 블록들
- 파일과 디렉터리가 저장되는 공간

<디렉터리 블록>

<수퍼 블럭(super block)>
- 파일 시스템 유지 관리를 위해 중요한 정보인 파일 시스템 메타 정보 기록
  - 파일 시스템의 크기와 상태 정보
  - 자유 블록들의 리스트와 그 수
  - inode 리스트의 크기
  - 자유 inode들의 리스트와 그 수
  - 자유 inode 리스트에서 다음 자유 inode 인덱스
  - 루트 디렉터리의 i-node 번호
  - 수퍼 블록이 갱신된 최근 시간

<파일 블록 할당(File Allocation)_Unix>
- i-node의 15개 인덱스로 블록들의 위치 저장
  - 12개의 직접 인덱스
    - 12개의 파일 블록 번호 : 12 x 4KB = 48KB

  - 1개의 간접 인덱스
    - 한 블록이 4KB이고, 블록 번호가 32비트(4바이트) 일 때
      - 4KB/4B = 1024 블록
      - 파일 크기 : 1024 x 4KB = 4 x (2^20B) = 4MB

  - 1개의 2중 간접 인덱스
    - 1024 x 1024 블록
     - 파일 크기 : 1024 x 1024 x 4KB = 4 x 2^30 바이트 = 4GB

  - 1개의 3중 간접 인덱스
    - 1024 x 1024 x 1024 블록
     - 파일 크기 : 1024 x 1024 x 1024 x 4KB = 4 x 2^40 바이트 = 4TB

*바이트(byte) : 1byte = 8bit
킬로 바이트(KB) = 1KB = 1024byte, 1KB = 1024 x 8
메가 바이트(MB) = 1MB = 1024KB
기가 바이트(GB) = 1GB = 1024MB
테라 바이트(TB) = 1TB = 1024GB

<파일 블록의 할당>

</usr/source/main.c>

<파일의 i-node 찾기>
- 파일을 읽고 쓰기 위해 파일 블록들의 위치 파악 필요
  - 파일블록들의 위치는 i-node의 15개 인덱스로 유지

- ex) /urs/source/main.c
  1. 수퍼 블록에서 루트(/)의 i-node 번호 알아내기
  2. 루브 디렉터리(/)의 i-node 읽기
  3. 루트 디렉터리에서 /usr의 i-node 알아내기
  4. /usr 디렉터리를 읽고 /usr/source 파일의 i-node 번호 알아내기
  5. /usr/source 디렉터리 읽고 /usr/source/main.c 파일의 i-node 번호 알아내기
  6. /usr/source/main.c 파일 읽기

<파일 입출력 연산>
- 커널의 파일 시스템은 파일 입출력을 위한 시스템 호출 함수 제공
  - open()
  - read()
  - write()
  - close()
  - chmod()
  - create()
  - mount()
  - unmount()
  - 등

<파일 열기 : open()>
- 왜 파일을 열어야 하나?
  - 파일이 존재하는지 확인
  - 파일에 대한 현재 프로세스의 접근 권한 확인
  - 파일을 읽고 쓰기 위한 커널 내 자료 구조 형성
    - 메모리 i-node 테이블
    - 오픈 파일 테이블
    - 프로세스별 오픈 파일 테이블
    - 버퍼 캐시

<파일 열기 후 형성되는 커널 자료 구조>

<파일 입출력을 위한 커널 내 자료 구조(1/2)>
- 메모리 i-node 테이블
  - 현재 열린 파일의 디스크 상의 i-node를 읽어 메모리 내에 저장한 테이블
  - 파일 블록 위치 등 i-node를 액세스할 때 빠른 처리를 위해 메모리에 적재

- 오픈 파일 테이블(open file table)
  - 시스템 내의 모든 열린 파일들에 대한 정보 기록
    - 파일 열기 모드, 파일 옵셋(file offset), 메모리에 적재된 inode 주소
  - 모드 프로세스에 의해 공유

*오프셋(offset)
- 배열이나 자료구조 오브젝트 내의 오프셋(offset)은 일반적으로 동일 프로젝트 안에서 오브젝트 처음부터 주어진 요소나 지점까지의 변위차를 나타내는 정수형이다
  이를테면, 문자 A의 배열이 'abcdef'를 포함한다면 'c'문자는 A시작점에서 2의 오프셋을 지닌다고 할 수 있다
  - ex) 문자 C는 100번지의 주소를 가리키고 있다. 'C+7' 위와 같은 수식이 있을 때, '7'이 오프셋(offset)을 의미한다
         또한, 이 수식의 결과는 107번지를 의미한다. 오프셋을 이용하여 주소를 나타내는 '상대주소 지정방식' 이라고도 표현한다

<파일 입출력을 위한 커널 내 자료 구조(2/2)>
- 프로세스별 오픈 파일 테이블
  - 현재 프로세스가 연 파일에 대해 오픈 파일 테이블 항목 주소를 가짐
    - 프로세스 마다 하나씩 있음(스레드간 공유)
    - 프로세스가 파일을 열 때마다 항목 할당, 닫으면 소멸시킴

  - 각 항목 번호는 open()의 반환값(파일 디스크립터)
    - 운영체제는 프로세스를 실행시킬 때 표준 입력, 표준 출력, 표준 오류용으로 3개의 항목을 열어놓음, 각각 0,1,2 항목

  - 이 테이블은 PCB에 저장

- 버퍼 캐시(buffer cache)
  - 읽혀지거나 쓰여지는 파일 블록들이 일시적으로 저장
  - 디스크 블록 번호로만 관리

<파일 열기 과정>
1. 파일 이름으로 i-node 번호를 알아내기
2. 디스크 i-node를 커널 메모리의 i-node 테이블에 적재
3. 오픈 파일 테이블에 새 항목 만들기
4. 프로세스별 오픈 파일 테이블에 새 항목 만들기
5. open()은 프로세스별 오픈 파일 테이블 항목 번호 반환

<파일 읽기 과정>
1. read()는 fd번의 프로세스별 오픈 파일 테이블 참조
2. 오픈 파일 테이블 참조
  - R 모드(읽기 허용)가 아닌 경우 오류로 리턴
3. i-node 참조
  - i-node에서 파일 블록들의 리스트 확보
  - 해당 테이블 항목에서 offset 확인 후 파일 블록 번호로 변환
4. 해당 블록이 버퍼 캐시에 있는 지 확인
  - 해당 블록이 버퍼 캐시에 없으면, 버퍼 캐시를 할당받고 디스크에서 버퍼 캐시로 읽기
    - 할당 받은 버퍼 캐시가 dirty이면 버퍼 캐시에 있는 블록을 디스크에 쓰기
5. 버퍼 캐시로부터 사용자 영역으로 블록 복사

<파일 쓰기 과정>
1. write()는 fd번호의 프로세스별 파일 테이블을 참조
2. 파일 테이블 참조
  - W 모드(쓰기 허용)가 아니면 오류로 리턴
3. i-node 참조
  - i-node에서 파일 블록들의 리스트 확보
  - 파일 테이블 항목에서 offset 확인 후 파일 블록 번호로 변환
4. 해당 블록이 버퍼 캐시에 있는 지 확인
  - 해당 블록이 버퍼 캐시에 없으면, 버퍼 캐시를 할당 받고 디스크 블록을 버퍼 캐시로 읽어 들이기
5. 사용자 공간의 버퍼에서 버퍼 캐시로 쓰기
6. 추후 버퍼 캐시가 교체되거나 플러시 될 때, 버퍼 캐시의 내용이 저장 장치에 기록
*버퍼 플러시(buffer flush) : 버퍼가 꽉 차지 않았어도 즉시 출력을 하여 버퍼를 비워버리는 것

<파일 닫기 : close()>
- open()에서 구성한 자료 구조를 해제 하는 괒어
1. 프로세스 별 파일 테이블로부터 오픈 파일 테이블 항목을 찾음
2. 버퍼 캐시에 있는 이 파일의 블록들이 수정되었거나 새로 만든 블록인 경우 디스크에 기록
- 캐시 내용은 남겨둠
3. 메모리 i-node의 사용 해제
4. 오픈 파일 테이블의 항목을 (지우고) 반환하기
5. 프로세스의 오픈 파일 테이블 항목에 기록된 내용 삭제

<디스크 스케줄링>
- 프로세스들의 디스크 I/O 요청들이 큐에 대기, 이 중 하나를 선택해 처리
  - 효율적인 디스크 접근 스케줄링 필요
  - 큐에 저장된 입출력 오청들의 목표 실린더 위치 고려
  - 평균 탐색 시간/평균 디스크 접근 시간 최소화

<디스크 스케줄링 알고리즘>
- 디스크 헤드 이동을 최소화
  - FCFS
  - SSTF(Shortest Seek Time First)
  - SCAN
  - C-SCAN(Circular SCAN)
  - LOOK
  - C-LOOK(Circular LOOK)

- 평가 기준
  - 평균 탐색 거리

<FCFS(First-Come-First-Serve) Scheduling>
- 디스크 큐 검색 불필요. 구현이 쉽고 기아 없음
- 일반적으로 빠른 서비스를 제공하지 못함

<SSTF(Shortest Seek Time First) Scheduling)>
- 최소 탐색 시간 우선
- 현재 디스크 헤드 위치에서 가장 가까운 요청을 먼저 처리
  - 현재 헤더에서 멀리 있는 요청은 기아 상태 발생 가능
  - seek time이 최소이긴 하지만 가장 최적이라고 할 수는 없음
  - 대화식 처리 시스템의 경우 불확실한 예측 가능시간 때문에 부적당
    - 바깥쪽 실린더에 대한 요청들은 오래 대기할 수 있음 -> 응답 편차가 큼
    - 배치 처리 시스템의 경우 적용 가능

<SCAN Scheduling>
- =엘리베이터 알고리즘(Elevator algorithm)
- 디스크 헤드가 한쪽 끝에서 다른 끝으로 이동해가며 요청을 처리
  - 끝에 도달하면 반대 방향으로 이동
  - 새 요청이,
    - 헤드 진행 방향에 생기면 즉시 처리
    - 헤드 진행 방향 뒤에 생기면 되돌아 올 때 처리

  - SSTF에 비해 균등한 입출력 서비스
    - 단, 양끝쪽 실린더 요청들은 중간보다 선택될 확률이 낮음

<Look Scheduling>
- 진행 방향에 요청이 없으면 바로 방향전환
- SCAN의 변형
- 한쪽 방향 마지막 요청에 도달하면 반대로 이동
- 맨 끝 실린더로 이동하면 SCAN의 단점 보완

<C-SCAN(Circular-SCAN) Scheduling>
- 순환 스캔
- SCAN보다 좀 더 균등한 요청 시간을 제공
- 디스크 헤드가 한쪽 끝에서 다른 끝으로 이동해가며 요청을 처리
- 끝에 도달하면 즉시 시작 위치로 돌아감
- 방금 처리가 끝난쪽보다는 반대쪽 끝에 처리될 요청들이 대기중일 확률이 높으므로

<C-LOOK Scheduling>
- 진행 방향에 요청이 없으면 바로 방향전환
- C-SCAN의 변형
- 한쪽 방향 마지막 요청에 도달하면, 다른쪽 끝방향 마지막 요청으로 이동

<디스크 스케줄링 알고리즘 특성 비교>

<Disk Scheduling Algorith의 선택>
- 성능은 요청의 형태와 회수에 좌우됨
  - 디스크 요청은 파일 할당에 영향 받음
    - 연속 할당된 파일 <=> 산재되어 할당된 파일
  - 디렉터리와 인덱스 블록의 위치가 중요
    - 빈번한 접근이 발생하기에

- 일반적으로 SSTF나 LOOK이 무난함
- SCAN/C-SCAN은 디스크를 많이 사용하는 시스템에 적합

<Disk Scheduling의 책임>
- OS와 분리된 모듈로 구현되어야 더 나은 알고리즘으로 대체될 수 있다
- 디스크 I/O 성능만 본다면, 스케줄링에 관한 책임을 하드웨어에게 일임이 바람직
- 하지만, 성능 이외의 몇가지 고려사항 때문에 OS가 간섭해야 한다
  - I/O 작업 간의 우선순위
    - 페이징 관련 입출력 > 일반 입출력
    - 디렉터리 정보 갱신 > 파일 내용 입출력

구조 기반 테스트

햏치 — Mon, 3 Jun 2024 22:22:13 +0900

<구조 기반 테스트란?>
-  화이트박스 테스트 케이스 설계
- 프로그램 결함 식별을 목적으로 프로그램  코드로부터 생성 되는 여러 정보(제어흐름정보, 자료흐름정보, 조건등을 이용하여 테스트 케이스를 설계하는 방법

<구조 기반 테스트/구조 커버리지 분석의 종류>
- Statement Testing(문장 테스팅)
- Branch Testing(분기 테스팅)
- Decision Testing(결정 테스팅)
- Condition Testing(조건 테스팅)
- Branch Condition Testing(분기 조건 테스팅)
- Multiple Condition Testing(다중조건 테스팅)
- MC/DC(Modified Condition/Decision Coverage)
- 기본 경로 테스트(Basis path test)

<문장 테스팅>
- 테스트하려는 프로그램 내의 모든  문장들을 '적어도 한번 이상' 실행하도록 요구하는 테스트 케이스 설계 방법
-  가장 기본적인 구조기반/화이트 박스 테스트
- 100%의 문장 커버리지: 프로그램 내의 모든 문장들을 적어도 한번씩 접근하여 테스트
- 제어 흐름 그래프의 모든 블록이 수행되면 당연히 프로그램의 모든 문장들이 수행되었음을 의미
- 테스트 커버리지 아이템: 문장
  - 문장 커버리지 = # of executed statements/# of total statements

<절차>
(1) 테스트 대상 프로그램에 해당하는 제어 흐름 그래프를 작성한다
(2) 모든 실행 가능한 기본 블록들을 지나가는 프로그램 경로 집합을 식별한다
(3) 프로그램 경로 집합에 있는 각 프로그램 경로에 대해 다음을 수행한다
  A. 경로를 실행하는 입력 데이터를 식별한다
  B. 명세 등으로부터 해당 입력에 대한 기대 출력(expected output)을 식별한다

<예제>

<생각해봅시다>

<문장 테스팅 문제>

<분기(Branch) 테스팅>
- 분기 테스팅은 프로그램을 제어 흐름 그래프로 변환했을 때 '제어 흐름 그래프의 모든 간선을 최소한 한 번은 실행'하는 테스트 케이스가 테스트 케이스 집합에 포함되도록 요구
- 테스트 커버리지 아이템: 분기 또는 간선

<생각해봅시다>
- 문장 커버리지를 만족하면 분기 커버리지를 만족하는가? X, 모든 노드들이 실행됐다고해서 모든 간선들이 실행되는것이 아니다
- 분기 커버리지를 만족하면 문장 커버리지를 만족하는가? O, 분기 커버리지를 만족하면 문장 커버리지를 만족한다

<결정(Decision) 테스팅>
- 프로그램의 모든 결정들에 대해 모든 가능한 결과를 가져올 수 있도록 테스트 케이스 집합을 설계한다.
- 각 결정이 가질 수 있는 경우는 ‘true’와 ‘false’이므로 프로그램의 각 결정 에 대해  ‘true’와 ‘false’가 산출될 수 있도록 하는 테스트 케이스가 최소한 1개 포함되어 있어야 한다.
- 테스트 커버리지 아이템: 결정이 가질 수 있는 모든 값(true/false)
  즉 하나의 결정에 두개의 테스트 커버리지 아이템(true가 되는 경우와 false가 되는 경우)이 있다.

<결정과 조건>
- 조건: NOT을 제외한 AND, OR 등의 논리 연산자가 없는 조건
         기본 조건식을 그냥 조건 또는 ‘clause’라고도 한다.
- 결정 : 조건이나 조건이 AND, OR등의 논리 연산자로 관계 되어 있음

<Decision Testing vs. Branch Testing>
- ISTQB에서는 결정 테스팅과 분기 테스팅을 구별하지 않지만
- ISO/IEC/IEEE 29119에서는 결정 테스팅과 분기 테스팅을 달리 정의한다.
- ISO/IEC/IEEE 29119에서 정의한 '분기 테스팅'은 프로그램을 제어 흐름 그래프로 표현했을 때 제어 흐름 그래프상의 분기(또는 간선)들을 최소한 한 번은 실행되기를 요구

<Decision Testing = Branch Testing?>
- 결정문이 분기를 가지지 않은 경우에는 분기 테스팅(Branch Testing)의 테스트케이스 집합과 결정 테스팅(Decision Testing)의 테스트 케이스 집합이 동일하지 않을 수 있다

1. 분기 테스팅을 만족?

2. 결정 테스팅을 만족?

<결정 테스팅>

가상메모리(2)

햏치 — Thu, 30 May 2024 23:22:23 +0900

<요구 페이징의 필수 알고리즘>
- 성능에 크게 영향을 미침
  - 프레임 할당 알고리즘
    - 프로세스 당 할당할 frame의 개수를 결정
      - 프로세스의 작업 집합에 포함될 page들을 수용할만한 개수의 frame을 할당하여 페이지 부재를 줄일 수 있도록

  - 페이지 교체 알고리즘
    - 페이지 부재가 발생했으나 빈 frame이 없는 경우 비울 frame을 결정
      - 작업 집합에 속하지 않은 page가 담긴 frame을 선택해서 미래에 사용될 page가 교체되지 않도록 유지

<최소 page frame의 수>
- 각 프로세스 마다 실행에 필요한 최소 page frame수가 확보되어야 한다
  - Frame수 감소시 page fault rate 증가
  - Page fault 발생 시 instruction cycle의 재실행 필요

- 한 instruction이 참조하는 모든 page는 동시에 메모리에 적재되어 있어야 한다
  - 여러 page에 걸쳐있는 instruction/data
  - 메모리 간접참조

<할당할 적정 프레임 개수>
- 작업 집합을 약간 넘나드는 크기 정도 할당

<프레임의 할당(Allocation of Frame)>
- 프로세스 당 frame 수
  - 최소 frame 수
    - 컴퓨터(instruction set)구조에 좌우됨
    - 한 명령어 수행위해 참조하는 모든 페이지를 수용할 수 있는 충분한 수의 프레임 존재 필요

  - 최대 frame 수
    - 가용 메모리 용량에 의해 좌우됨

<할당 알고리즘(Allocation Algorithm)>
- 균등 할당(Equal allocation)
  - 모든 프로세스들에게 같은 수의 frame을 할당
  - 작은 size의 프로세스에게는 과할당 발생가능

- 비례 할당(Proportional allocation)
  - 각 프로세스의 크기에 비례하여 할당

- 우선순위 할당(Priority Allocation)
  - 각 프로세스의 우선순위에 따라 할당
  - 더 높은 우선순위의 프로세스가 더 빨리 수행토록

<참고 : 할당해야 할 최소 프레임의 수>
- 한 명령이 처리되는데 필요한 페이지수
  - CPU 명령어의 주소 모드(addressing mode)에 좌우

<참고 : MS-윈도의 프레임 할당 예>
- 작업 집합의 이동으로 프로세스의 작업 집합 크기를 정확히 파악하기는 어려움
- 윈도는 프로세스 생성시 최소/최대 할당 프레임 수를 정함
  - 윈도 7에서는 최소 50개, 최대 345개
    - 워킹셋(working set)이라 부름

- 프로세스 생성 시
  - 최소/최대 워킹셋 수가 예약됨
  - 프로세스가 실행되면, 페이지 폴트 시 최수 수까지 메모리 할당할 수 있도록 노력
  - 기본적으로는 최대 수를 넘어서는 메모리 할당은 불허
    - 가용 메모리가 충분한 경우 큰 프로세스의 최대치를 증가

- 주기적으로
  - 워킹셋 트리밍 알고리즘(working set trimming algorithm)으로 시스템 메모리 사용량 스캔
  - 일정 수준 이상 메모리가 사용되면 프로세스들의 워킹셋을 줄임(스왑-아웃 시킴)
    - 가용 메모리를 확보할 때까지 계속됨

<윈도의 작업 관리자>
- 메모리에 적재된 페이지의 크기를 나타냄
  - 현재 프로세스의 워킹셋이라 부름
    - 프로세스의 전체 크기가 아님
    - 프로세스의 모든 페이지가 적재된 것도 아님

<가용 frame이 부족하다면?>
- 프로세스의 일부 page를 디스크로부터 가져올 때 free frame이 없다면?

- 메모리에 적재된 page들 중 일부를 swap area로 swap out 해야함
  - Page fault 서비스 루틴에 페이지 교체 알고리즘을 포함시켜 메모리의 과할당 방지
    - Page fault를 최소화 할 수 있는 알고리즘은?!
  - Modify-bit(혹은 dirty-bit)를 사용하여 변경된 page만 swap-out

<페이지 교체(Page Replacement)>
- 메모리 frame 중 하나를 선택해 비우고, 이곳에 요청된 page를 적재하는 과정
  - 페이지 폴트 핸들러에서 실행되는 작업
  - 희생 페이지는 스왑-아웃, 요청 페이지는 스왑-인
    - 희생 프레임(victim frame) : 비우기로 선택된 frame
    - 희생 페이지(victim page) : 희생 frame에 들어 있는 page

  - 현재 작업 집합에 포함되지 않거나 가까운 미래에 참조되지 않을 page를 희생 page로 선택
    - 페이지 부재 횟수를 줄임

<기본적인 페이지 교체>
1. 디스크에서 필요한 page의 위치를 파악
2. Free frame을 찾음
  - Free frame이 있으면 그곳을 사용
  - 없으면 페이지 교체 알고리즘으로 희생될 frame(victim frame)선정
  - (필요시)Victim frame을 디스크에 기록

3. Page를 디스크로부터 읽어 frame에 저장
  - page/frame table 수정

4. 프로세스 재실행

<지역 교체와 전역 교체>
- 지역 교체(Local replacement)
  - 각 프로세스는 자신이 사용중인 frame들 중에서만 교체 대상 frame을 선정
  - 각 프로세스는 할당된 frame수 불변
    - 잘 안쓰는 frame이 낭비

- 전역 교체(Global replacement)
  - 전체 frame 중에서 교체 대상 frame을 선정
  - 각 프로세스에 할당된 frame수가 변할 수 있음
    - 다른 프로세스의 frame을 뺏어올 수도 있음
  - 각 프로세스는 자신이 page fault rate 조절 불가
    - 같이 수행되는 다른 프로세스에 의해 영향받음

<페이지 교체 알고리즘>
- 낮은 page fault rate이 요구됨

- 성능 평가
  - 임의의 메모리 참조열(reference string)에 대해 알고리즘을 적용하여 page fault 회수 계산
    - reference string
      - 난수를 통한 임의 생성하거나 메모리 접근 기록을 로깅
  - 가정
    - frame 수 : 3개
    - reference string
      - 7 0 1 2 0 3 0 4 2 3 0 3 2 1 2 0 1 7 0 1

<Page fault 횟수 vs. frame 수>

<페이지 교체 알고리즘의 종류>
- FIFO
- Optimal Algorithm(MIN)
- LRU(Least Recently Used) Algorithm
- LRU Approximation Algorithm
- CLOCK(FINUFO : First-In-Not-Used-First-Out)
- Counting Algorithm
  - LFU(Least Frequently Used) Algorithm
  - MFU(Maximal Frequently Used) Algorithm
- LIFO(Last-In-First-Out) Algorithm
- Random Algorithm

<FIFO 페이지 교체>
- First-In-First-Out
- 가장 오래된 page frame을 교체
  - 각 frame은 메모리에 적재되는 순서(시간)에 따라 순번이 매겨짐
  - FIFO 큐 이용
- 가장 간단하며 구현이 용이

<FIFO Illustrating Belady's Anomaly>

<Optimal Algorithm(MIN Algorithm)>
- 최적 페이지 교체 알고리즘
- Belady에 의해 제안
- 앞으로 가장 오랫동안 사용되지 않을 page frame을 교체
- page fault 횟수를 최소화 함
- 비현실적
- 향후 프로그램 수행 예측은 불가능하기에
- 다른 교체 알고리즘들의 성능 비교를 위한 기준으로 사용

<Optimal Algorithm의 예>

<최근 최소사용 알고리즘, LRU(Least Recently Used) Algorithm)>
- 가장 오랫동안 상되지 않은 page frame을 교체
  - 오랫동안 미사용 = 앞으로도 미사용
- 일반적으로 좋은 성능
  - Belady 모순 현상이 나타나지 않음
- 각 page frame마다 마지막 사용 기간 유지
- Age counter 혹은 LRU 스택으로 구현
  - 잦은 메모리 조작 발생
  - TLB 같은 하드웨어 지원 필요

<LRU Algorithm의 구현_1>
- Age Counter 사용
- 각 page frame마다 하나의 counter 설정
- 각 page frame이 참조될 때마다 참조 시간을 해당 pgae frame의 counter에 복사
- 교체 시 각 page frame의 counter를 보고 가장 오래 전에 참조된 frame 선택
- Page table에 접근이 필요
  - LRU 교체 page를 찾기 위해
  - 매 메모리 참조시 마다 counter 갱신 위해

<LRU Algorithm의 예>

<LRU Algorithm의 구현_2>
-  Strack에 page 번호 유지
- 최근에 참조된 page 번호를 스택의 top에 위치 시킴
  - 교체 대상이 되는 page는 스택의 bottom에서 얻음
  - 교체 대상을 찾기 위한 검색 불필요

- 이중 연결 리스트로 스택 구현
  - 스택 중간에서 항목 제거 위해

<스택을 위한 page 참조의 기록>

<LRU 근접 알고리즘(LRU Approximation Algorithm)>
- LRU page 교체 지원을 충분히 할 수 있는 하드웨어는 거의 없음
  -> 일반적으로 reference bit(참조 비트) 형태로 어느 정도만 지원

- Reference bit
  - 각 page 마다 할당, 초기에 OS에 의해 reset
  - 해당 page의 참조가 발생하면 set
=> 정확한 사용 순서는 알 수 없지만, 각 page의 참조 여부는 확인 가능

<부가된 참조 비트 알고리즘(Additional Reference Bit Algorithm)>
- 일정 시간 간격마다 참조 비트를 기록하여 대략적인 선후 관계를 알 수 있게 함
  - 타이머 인터럽트와 우측 쉬프트 레지시터 이용
  - 참조비트가 가장 작은 수의 페이지를 교체

- ex) 각 page마다 8bit의 참조 비트를 할당
  - 0000 0000 : 한 번도 참조 안됨
  - 1111 1111 : 각 간격마다 1번 이상씩 참조됨
  - 1100 0110(최근 사용) > 0111 0111(교체 대상)
    - 교체대상 중 FIFO 적용하여 선택 가능

<2차-기회 알고리즘(Second-Chance Algorithm)>
- Clock Algorithm
- FINUFO(First-In-Not-Used-First-Out) Algorithm
- 기본은 FIFO 알고리즘 + page 선택시 마다 참조 비트 확인
  - 참조 비트 0 : 바로 교체
  - 참조 비트 1 : reset 후 한 번 더 기회 제공
- 순환 큐와 포인터(P)를 이용하여 구현
  - ex)
if USE(*P) = 1 then
  - USE(*P) = 0; P = P+1 until finding USE(*P)=0;
  - REPLACE(*P); P = P+1;
else /*USE(*P)=0*/
  - REPLACE(*P) and P = P+1;

<2차 기회 알고리즘의 예>

<Enhanced Second-Chance Algorithm>
- Second-Chance Algorithm + (참조/변경 비트)
- page 선택시 마다 등급 확인
- 디스크 입출력 회수 고려

<Counting Algorithms>
- 각 page frame의 참조 회수를 counter에 유지
- LFU(Least Frequently Used) Algorithm
  - 가장 작은 count 값을 가진 page 교체
    - 적게 참조한 page는 참조될 가능성이 적다 가정

- MFU(Maximal Frequently Used) Algorithm
  - 가장 큰 count 값을 가진 page를 교체
    - 많이 참조한 page는 충분히 사용했다 가정
    - 가장 작은 count 값을 가진 page는 적재된지 얼마 되지 않아 더 사용할 가능성이 있따 가정

Spring data JPA

햏치 — Wed, 29 May 2024 16:56:39 +0900

<JPA(Java Persistence API)>
- Java 프로그램에서 데이터를 영구적으로 저장할 때 사용하는 인터페이스
- Java 진영에서 ORM(Object-Relaional Mapping)기술 표준으로 사용하는 인터페이스 모음
- 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스
- 인터페이스이기 때문에 Hibernate, Open JPA등이 JPA를 구현

<구조>
- 외부에서 Controller를 호출하면 Repository가 Entity를 가지고 처리를 한 후에 반환하는 구조라고 보면 된다
  - Controller > Java Logic 수행
  - Entity > 테이블 정보 설정
  - Repository > 쿼리 정보 설정

<JPA Annotation>
- @Builder : SQL 사용 시 파라미터에 값을 쉽게 넣어주기 위한 어노테이션
- @ToString : 객체의 값 확인
- @AllArgsConstructor, @NoArgsConstructor : 생성자를 자동 완성시켜준다(Lombok 필요)
- @Entity : 해당 class에 지정할 테이블명 입력

- @ModelAttribute : Form data
  - ex)name=Laptop&brand=Samsung&madeIn=Korea&price=1000.00를 Product 객체
- @RequestBody : HTTP 요청 본문에 포함된
- JSON 데이터
  - ex) {"name": "Laptop", "brand": "Samsung", "madeIn": "Korea", "price": 1000.00}를 Product 객체에 매핑

<CRUD>

조합 테스팅

햏치 — Wed, 29 May 2024 13:32:24 +0900

<조합 테스팅>
- 조합 테스팅은 테스트 대상 프로그램의 동등 분할이나 BVA등을 통해 여러 개의 클래스들로 각 입력 인자를 여러 클래스나 값들로 분할하였을 때 이들을 조합하여 테스트 케이스를 구성하는 방식
- 예제 : 입력 x,y,z를 어떻게 조합하여 테스트 케이스를 만들것인가?

  1. one-to-one : 3+4+2=9개의 test case
  2. minimized : 4개
  3. 모든 입력 인자들 : 3*4*2=24

<조합 테스팅 종류>
- Each choice 테스팅(=minimized): 각 입력 인자의 분할된 클래스로부터 최소한 하나의 입력 값이 테스트케이스에 포함
- 페어와이즈 테스팅: 각 인자의 값(또는 클래스)과 다른 인자의 값(또는 클래스)를 최소한 한번은 조합하여 테스트 케이스를 구성
- All combinations 테스팅: 모든 입력 인자의 모든 가능한 클래스의 조합이 테스트 케이스들에 포함되도록 구성
- Base choice 테스팅: 기반이 되는 테스트 조합을 미리 선정한다. 기반 테스트는 사용자의 관점에서 가장 선택될 빈도가 높고, 일반적으로는 정상 동작할 수 있는 것을 선정하고 선정된 기반 테스트에서 하나의 인자에만 변경을 주고 나머지는 기반 테스트의 값으로 고정하여 테스트 케이스들을 생성

<예제>
[명세] 새우 버거와 닭고기 버거는 4000원, 소고기 버거는 5000원이다.
주문할 때 쿠폰을 사용하면 1000원 할인 가능하다. 또한 주문시간에 따라 할인이 가능하다.
피크 타임은 오전11시~오후2시(11:00~13:59)이다. 피크 타임 외의 시간에 주문하면 500원 할인한다.
All combinations : 3*2*2=12개
Each Choice(minimized) : 3개

*테스트 아이템 인자(Test Item Parameter) : 프로그램 행위에 영향을 주는 인자 : 버거 종류, 주문 시간, 쿠폰 적용

<예제_1>
[명세] 새우 버거와 닭고기 버거는 4000원, 소고기 버거는 5000원이다.
주문할 때 쿠폰을 사용하면 1000원 할인 가능하지만 피크 타임외의 시간에만 적용이 가능하다
피크 타임은 오전11시~오후2시(11:00~13:59)이다. 피크 타임 외의 시간에 주문하면 500원 할인한다.
만약 주문시간에 따른 할인과 쿠폰이 동시에 적용되면 쿠폰에 따른 할인만 적용한다

- 예제 프로그램
public class BurgerShop2{
  public int getPrice(BurgerKind burgerType, LocalTime orderTime, boolean couponApplied){
int totalPrice = 0;
if(burgerType == BurgerKind.SHRIMP) totalPrice = 4000;
if(burgerType == BurgerKind.CHICKEN) totalPrice = 4000;
if(burgerType == BurgerKind.BEEP) totalPrice = 5000;

LocalTime startTime = LocalTime.of(hour:11, minute:0, second:0);
LocalTime endTime = LocalTime.of(hour:13, minute:59, second:59);

if(orderTime.isBefore(startTime) || orderTime.isAfter(endTime)){
  if(couponApplied)
    totalPrice -= 2000;
  else totalPrice -= 500;
}
return totalPrice
}
}
Q. Each Choice Testing으로 오류 검출 가능? 검출 안된다(운이 좋으면 검출 가능)

<테스트 조합의 갯수>
Each Choice < Pairwise < All Combination

<예제_2>
[명세] 새우 버거와 닭고기 버거는 4000원, 소고기 버거는 5000원이다.
주문할 때 쿠폰을 사용하면 1000원 할인 가능하지만 피크 타임외의 시간에만 적용이 가능하다. 피크 타임은 오전 11시~오후2시(11:00~13:59)분이다. 피크 타임 외의 시간에 주문하면 500원 할인한다. 소고기 버거는 쿠폰을 사용할 때 300원 더 할인한다. 만약 주문시간에 따른 할인과 쿠폰이 동시에 적용되면 쿠폰에 따른 할인만 적용된다.

LocalTime startTime = LocalTime.of(11,0,0);
LocalTime endTime = LocalTime.of(13,59,59);
if(orderTime.isBefore(startTime) || orderTime.isAfter(endTme)){
if(couponApplied){
  totalPrice -= 1000;
  if(burgerType == BurgerKind.BEEF)
totalPrice -=300; //Nonpeaktime, Coupon True, BEEF 일 때 만족
}else totalPrice -= 500;
}
return totalPrice;
}
-> pairwise에서는 만족하는 커버리지가 없으므로(Nonpeaktime, Coupon True, BEEF), All Combination을 커버리지로 테스트케이스를 만들어야 한다

<Pairwise 테스트>
- Each Choice는 유용한 테스트 케이스가 누락될 수 있다
- All Combinations는 너무 많은 테스트 케이스가 생성된다
- Pairwise 테스트는 모든 가능한 입력 값들의 조합들을 테스트 하는 대신 모든 짝(pair)들의 조합을 테스트하는 방법

<Base Choice 테스팅>
- 기반이 되는 테스트 조합을 미리 선정한다. 기반 테스트는 사용자의 관점에서 가장 선택될 빈도가 높으면서 일반적으로는 정상 동작할 수있는 것을 선택한다. 기반 선정 조합은 우선 기반 조합을 선정하고 선정된 기반 테스트에서 하나의 인자에만 변경을 주고 나머지는 기반 테스트의 값으로 고정하여 생성한다.

<IPO 알고리즘>
- 수평확장(Horizontal Growth) 수직확장(Vertical Growth)의 반복
- 수평확장은 새로운 Factor를 고려하는 과정이고 수직확장은 테스트 케이스를 추가하는 과정이다.
  - 수평확장 : 수평으로 확장하는데 값은 '입력인자, Test item, Parameter'가 있다
  - 수직확장 : 수평확장이 하나의 테스트 케이스(Test Case)가 되는 것
*Test Item Parameter = Factor

1. All Combination : 3*3*2=18개
2. Each Choice = 3개
3. Pairwise : 인자들 중에 가장 많은 값(A, B) = 3*3=9개

가상메모리(1)

햏치 — Wed, 22 May 2024 18:57:54 +0900

<배경>
- "현재 실행되고 있는 코드들은 반드시 물리적 메모리에 존재해야 한다"
  - 앞서 다룬 메모리 관리 기법들의 특징

  - 방법
    - 프로세스 전체를 메모리에 적재
      - 가장 손쉬운 방법
    - Dynamic Loading
      - 프로그래머의 특별한 주의와 추가 작업 필요

  - 단점
    - 프로세스의 크기가 물리적 메모리의 크기로 제한

<주소 공간과 물리 메모리>
- 컴퓨터에 설치 가능한 물리 메모리의 한계
  - CPU의 주소 버스 크기에 좌우
  - 32비트 CPU의 물리 메모리 최대량 : 2^32B = 4GB
  - 64비트 CPU의 물리 메모리 최대량 : 2^64B = 2^24TB

- 실제 설치되는 물리 메모리
  - 현재 대부분 8~32GB정도 장착
    - 비용적인 한계

<물리 메모리의 한계>
- 물리 메모리보다 큰 크기의 프로세스는 실행될 수 없다!
- 동시 수행되는 프로세스들의 크기의 총합은 물리 메모리보다 클 수 없다!

<메모리에 모든 내용이 있어야 하는가?>
- 프로그램의 모든 부분이 동시에 요구되진 않음
  - 순차적 실행

- 항상 모든 코드가 메모리에 적재되어 있어야 하지는 않음
  - 오류 상황을 위한 코드
  - 잘 사용하지 않는 기능에 대한 코드
  - 필요 이상으로 할당된 큰 용량의 배열

<그러면 가능한 대안은?>
- 물리 메모리를 보조저장장치로 확장
  - 프로세스를 메모리와 보조장치에 나누어 저장
  - 프로세스를 실행하기에 충분히 큰 메모리가 있다고 착각하게 만드는 메모리 관리 기법

- 스와핑(Swapping)
  - 메모리가 부족할 때, 실행에 필요하지 않는 부분은 보조저장장치로 이동
  - 실행에 필요할 때 보조저장장치로부터 물리 메모리로 이동

<가상 메모리(Virtual Memory)>
- 물리메모리 영역을 보조저장장치까지 연장
  - 스왑(swap)
  - 무한의 가상적인 메모리 공간

- 실행을 위해 프로세스의 일부만을 메모리에 할당
- 가용 메모리 부족 시 일부 내용을 스왑 영역으로 옮겨 빈 영역 확보
  - 다중 프로그래밍 정도를 높여 CPU 이용률/처리율 향상
  - 스왑-아웃, 스왑-인

- OS 마다 세부 구현 방법은 다름
  - 요구 페이징, 요구 세그멘테이션 등

<일부만 메모리에 적재할 수 있다면?>
- 프로세스의 크기가 물리적 메모리의 크기에 의해 제약 받지 않을 수 있다
  - 프로그래밍 작업이 간단해짐

- 다중 프로그래밍 정도가 늘어남
  - Turnaround time과 response time이 늘어나지 않으면서 CPU utilization과 throughput 향상

- 보다 빠른 실행이 가능
  - 적재 속도의 향상
  - swap을 위한 입출력이 줄어듦

<Process 실행 관련 주요 용어>
- CPU utilization(이용률)
  - CPU가 얼마나 많이 이용되는가

- Throughput(처리량)
  - 단위 시간 동안 수행이 완료된 프로세스 개수

- Turnaround time(총 처리 시간)
  - 임의의 프로세스를 수행하는데 걸리는 시간

- Response time(응답 시간)
  - 요청을 보낸 후 첫 응답이 발생하기 까지 걸린 시간

<Virtual Memory 사용의 기본적인 이점>
- 프로세스간의 메모리 공유를 가능하게 한다
  - 각 프로세스는 각자 자신의 주소 공간을 사용하는 것처럼 보인다
  - 여러 프로세스 간에 시스템 라이브러리를 공유

- 프로그램 실행 중에 사용되는 메모리의 양/배치 방법 등에 대해 신경쓰지 않아도 된다
  - 무한의 메모리라 가정 가능

- 메모리 계층 구조에서 높은 access rate와 비트 당 낮은 저장 비용(low cost per bit)위해

<가상 메모리 시스템의 주요 동작>
- 프로세스의 처리 요구에 따라 서로 다른 레벨의 메모리 간의 정보 블록들의 스와핑

- 주요 결정 사항
  - 인출 정책(Fetch policy) : 언제 가져올 것인가?
  - 배치 정책(Placement policy) : 어디로 가져올 것인가?
  - 교체 정책(Replacement policy) : 어느 frame과 교체할 것인가?

<가상 메모리 관련 문제들>
- 가상 메모리의 페이지 테이블 구성
- 페이지 폴트
- 페이지 할당
- 스왑 영역
- 프레임 할당
- 스레싱
- 작업 집합
- 페이지 교체 알고리즘
- 쓰기 시 복사

<요구 페이징(Demand Paging)>
- 필요한 page들만 물리 메모리에 적재하는 방법
  - 실행중에 page들이 실제 필요할 때에 적재된다
  - 사용되지 않는 page는 적재되지 않음
  - 페이지를 갖는 보조기억장치 영역 : 실행파일 + 스왑

- 장점
  - Less I/O needed
  - Less memory needed
  - Faster response
  - More users

<요구 페이징의 구성>

<스왑(swap) 영역>
- 메모리가 부족할 때, 메모리를 비우고 페이지를 저장해두는 하드 디스크 영역
  - 리눅스 : swap 파티션
  - MS-Windows : C\pagefile.sys 파일

- 스왑-인(swap-in)
  - page-in 이라고도 부르며, 스왑 영역에서 한 page를 메모리 frame으로 읽어들이는 행위

- 스왑-아웃(swap-out)
  - page-out 이라고도 부르며, 메모리 frame에 저장된 page를 스왑 영역에 저장하는 행위

<가상 메모리에서의 페이지 테이블>
- valid/presence bit
  - 해당 page가 물리 메모리에 있는지 여부
    - 1 : 해당 page가 frame 번호의 메모리에 있음
    - 0 : 해당 page가 디스크에 있음

- modified bit(dirty bit)
  - 해당 page가 수정되었는지 여부
    - 1 : 해당 page가 수정되었는지 여부
      - 스왑 아웃될 때 스왑 영역에서 저장 필요

     - 0 : 해당 page는 수정된 적이 없음
      - 스왑 아웃될 때 스왑 영역에 저장 불필요

<페이지 부재(Page Fault)>
- 메모리에 없는 page가 참조할 때 페이징 하드웨어가 OS에게 보내는 trap

- Page fault에 대한 처리 과정
  1. 프로세스에 대한 page table을 통해 해당 참조가 유효한지 검사
    - Invalid reference => abort
    - Just not in memory => 디스크에서 가져와야 함
  2. Free frame을 찾아 디스크로부터 page를 가져옴
  3. Page table 갱신
  4. Page fault에 의해 중단된 intrsuction 재실행

<페이지 부재 처리 과정>

<중단된 Instruction의 재실행>
- Demand paging을 위한 필수적 요구사항

  - 일반적으로 중단된 프로세스의 상태를 나타내는 각종 레지스터들의 값을 저장해두었다가 복원

  - Instruction fetch시 발생된 경우
    - 해당 page를 메모리로 가져온 후 다시 시도

  - Operand fetch/execution시 발생된 경우
    - 해당 page를 메모리로 가져온 후, 해당 instruction을 다시 인출하여 실행
    - 반복 작업이 수반되나 감수할 만함

<가상 메모리에서 새 프로세스 생성>
- fork() 시스템 호출로 생성되는 프로세스
  - 메모리 할당 + 페이지 적재

- fork() 시스템 호출
  - 방법 1 : 완전 복사
  - 방법 2 : 쓰기 시 복사

<방법 1 : 완전 복사>
- 부모 프로세스의 모든 페이지를 온전히 복사
- 많은 경우 fork() 후 바로 exec() 하기에 비효율적
  - ex)
int childPid == fork(); //쉘을 복제한 자식 프로세스 생성
if(childPid == 0){ //자식 프로세스 코드
execlp("/bin/ls", "ls", NULL); // /bin/ls 파일을 적재하여 실행
} // execlp()에 의해 자식 프로세스의 메모리가 모두 반환되고 실행 파일 ls로부터 새로 페이지 적재

<방법 2 : 쓰기 시 복사(Copy-on-Write, COW)>
- 자식 프로세스를 위해 부모의 page table만을 복사
  - 초기에 자식은 부모의 메모리 frame을 온전히 공유

- 자식의 page table 항목에 COW(쓰기시 복사)표시를 해둠

- 부모/자식 중 하나에서 page 수정이 발생하면 새 frame 할당하고 부모 frame복사

<COW의 특징>
- 효율적인 프로세스 생성이 가능
  - 프로세스 생성 시간 절약
    - 전체 page들을 복사하지 않고 단지 변경되거나, 변경 가능한 page들만 복사
    - fork() 후 exec() 발생 시 불필요한 복사 시간의 낭비가 생기지 않음

  - 메모리 절약
    - 수정이 발생되지 않는 page는 새 frame을 할당할 필요 없음
      - 예 : 코드 영역

<요구 페이징 관련 이슈>
- 페이지 부재가 빈번히 발생시 빈번한 입출력으로 시스템 성능이 떨어지지 않을까?
  - 그럴 수 있다 : 스레싱(thrashing)

- 실행 시 페이지 부재가 계속되면 해당 프로세스의 많은 page가 적재되는데, 애초부터 적재하지 않나?
  - 실행 과정에서 참조될 수 있는 page를 미리 알 수 없기에

- 한 프로세스에게 할당 가능한 frame은 무한한가?
  - 물리 메모리 양의 크기로 제한됨

- 한 프로세스에게 할당하는 frame 수와 페이지 부재의 관계
  - 일반적으로 반비례 관계

- 커널 코드와 커널 데이터가 적재된 frame도 스왑-아웃되나?
  - 실행 효율성 때문에 이 둘은 항상 물리 메모리에 적재

<스레싱(Thrashing)>
- 프로세스가 실제 실행보다 더 많은 시간을 페이징 처리에 할당하고 있는 상태
  - 과도한 page 교체로 인한 swap in/out에 몰두

- 원인
  - 프로세스가 실행에 필요한 충분한 frame을 할당받지 못하면
    - page fault가 매우 낮아짐
    -> CPU 이용률이 낮아짐
    -> OS는 다중 프로그래밍 정도를 증가시키려 함
  - 악순환 반복으로 심각한 성능 저하 초래

<스레싱 현상>
- 다중 프로그래밍 정도가 높아질수록 CPU 이용률 증가
- 다중 프로그래밍 정도가 임계점(M)을 넘어가면 스레싱 발생

<스레싱 해결 및 예방>
- 감지 방법
  - OS마다 다름
    - MS 윈도 : process explore 등 사용
    - 리눅스 : top, htop, vmstat 명령
  - 작업 부하는 높지만 CPU 이용률이 낮고, 스왑-인/아웃이 모두 높은지 검사

- 해결 및 예방
  - 다중 프로그래밍 정도 줄이기
    - 일부 프로세스 종료
  - 빠른 보조저장장치의 사용
  - 물리 메모리 증가

<참조의 지역성(reference of locality)>
- CPU가 짧은 시간 범위 내에 일정 구간의 메모리 영역을 반복적으로 참조하는 경향
  - locality(지역성), principle of locality(지역성의 원리)
    - 프로그램이 가진 기본적인 실행 특성

  - 짧은 시간 동안에는 메모리에 균일하게 접근하기보다는 특정 부분에 집중 참조하는 경향을 지님
    - 프로세스는 최근에 참조한 데이터와 코드를 다시 참조하는 경향성
    - 참조의 지역성 이동. 프로세스가 실행되는 동안 메모리 영역을 옮겨 다니면서 참조의  지역성이 나타남

  - 경험적 관찰에서 발견된 90/10 규칙
    - "프로그램 코드의 10%에서 실행 시간의 90% 소비"

<참조의 지역성의 형태>
- 시간 지역성(temporal locality)
  - 시간적으로 볼 때,
    - 프로세스에서 현재 참조된 주소(페이지)가 가까운 미레에 다시 참조될 가능성이 큰 특성
    - 코드나 데이터, 자원 등이 짧은 시간 내에 다시 사용되는 특성 : 반복문

- 공간 지역성(spatial locality)
    - 공간적(메모리 주소)으로 볼 때,
      - 현재 참조되는 번지(페이지) 주변의 번지들이 가까운 미래에 참조될 가능성이 큰 특성
      - 순차적 실행, 배열, 순차 읽기/쓰기

<참조의 지역성의 의미>
- 현재 프로세스의 실행 패턴을 관찰하면
  - 가까운 미래에 어떤 페이지에 접근할 것인지 합리적으로 예측 가능

- 메모리 할당과 페이지 교체 전략에 활용

<작업 집합(working set)>
- 일정 시간 범위 내에 프로세스가 참조한 페이지들의 집합
  - 현재 프로세스의 실행에 필요한 페이지들의 집합
    - 작업 집합에 포함된 페이지들이 모두 메모리에 적재되어 있는 것이 프로세스 실행 최고 성능

  - 참조의 지역성으로 작업 집합은 뚜렷이 형성됨
    - OS는 프로세스에게 작업 집합을 적재할 수 있는 정도의 메모리 할당할 필요가 있음
      - 부족 시 잦은 스와핑 발생

<작업 집합과 시간 범위>
- 페이지 부재는 작업 집합을 메모리에 적재하는 과정
  - 참조의 지역성으로 인해 일정 시간 내에 작업 집합 형성
  - 시간 범위가 클수록 작업 집합도 큼
    - 시간 범위를 얼마로 정할 것인가?

<작업 집합 이동(working set shift)>
- 스레싱이 아닌 경우 page fault rate는 시간에 따라 고점과 저점 사이를 오르내림
  - 고점 : 새로운 지역으로 진입

<스레싱과 작업 집합>
- 스레싱 발발 원인 설명에 작업 집합 모델 활용
  - 1968년 Denning의 논문(Thrashing : its causes and prevention)
    - 스레싱의 원인 설명에 '작업 집합' 모델 사용
      - 처음 스레싱 관측
      - 1968년 처음으로 작업 집합 모델로 스레싱 현상을 설명

- 스레싱 예방
  - 스레싱은 작업 집합이 메모리에 올라와 있지 않을 때 발생
  - 1968년 Denning, 실험으로 증명
    - 예방책 제시 - 각 프로세스에게 작업 집합에 포함하는 페이지들을 적재할 충분한 메모리 할당

Spring Boots First Application

햏치 — Wed, 22 May 2024 17:02:30 +0900

<Spring Boot Maven Plugin>
- Spring Boot Maven Plugin은 다음과 같은 Spring Boot 지원을 제공한다
  1. 프로젝트를 실행가능한 jar 파일이나 war 파일로 패키지(package)
  2. Spring Boot 애플리케이션 실행
  3. Build 정보 생성
  4. 통합 테스트를 하기 전에 Spring Boot 애플리케이션을 시작

<Goals>
- Spring Boot Plugin은 다음과 같은 goal들을 가지고 있다
  - spring-boot:build-image : OCI imae로 패키지
  - spring-boot:build-info : build-info.properties 파일 생성
  - spring-boot:repackage : Repackage, Jar 나 War 파일로 재패키지
  - spring-boot:run : 현재 위치에서 애플리케이션을 실행
  - spring-boot:start : Spring 애플리케이션을 시작, "run" goal과 달리 애플리케이션 작동을 block하지 않고 다른 goal들을 허용
  - spring-boot:stop : "start" goal로 시작된 애플리케이션을 종료

<Packaging>
- "repackage" goal로 프로젝트를 실행가능한 jar/war 파일로 패키지한다

<Component Scan>
- 설정 정보(AppConfig.class)없이 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능을 제공한다
- 스프링 빈을 등록할 때는 의존관게를 자바 코드로 직접 등록하는 방법과 컴포넌트 스캔과 자동 의존관계 설정하는 @Autowired를 사용하는 방법이 있다

- ex) @ComponentScan은 탐색 위치에 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다
@SpringBootApplication(
scanBasePackages={”kr.ac.hansung.cse.hellospringboot”,
“com.mypackage.springapp”,
                          “kr.ac.hansung.iot”}  )
public class HelloSpringBootApplication {
    public static void main(String[] args) {
        SpringApplication.run(HelloSpringBootApplication.class, args);
    }
}

<Templates>
- 템플릿(Templates)은 자바 코드를 삽입할 수 있는 HTML형식의 파일이며, 일반적으로 많이 사용하는 방식이다
- 스프링부트에서 사용할 수 있는 템플릿 엔진에는 Thymeleaf, Mustache, Groovy, Freemarker, Velocity등이 있다

<템플릿 엔진>
- 코드 제너레이션 또는 시스템에서 만들어 놓은 이메일 템플릿에 파라미터만 넣어 변경하는 등 여러 가지 상황에 맞게 사용할 수 있다

<Application Properties>
- By default, Spring Boot will load properties from ☆"application.properties"
- ex)
# Can add Spring Boot properties
server.port=9000

# set context path
server.servlet.context-path=/helloSpringBoot  -->http://localhost:9000/helloSpringBoot/customer

# logging.level.<logger-name>=<level>
logging.level.kr.ac.hansung=debug
//logging level : trace, debug, info, warn, error

# add our own custom properties
app.professor=Namyun Kim
app.course=Web Framework
-> custom은 객체에 있는 필드에 바인딩 해준다

ex)
#configure my props

app.professor= Namyun Kim
app.course=Web Framework
일 때, ☆"@Value"라는 Annotation을 사용

@RestController
public class HelloWorldController {

    @Value("${app.professor}")
    private String professorName;

    @Value("${app.course}")
    private String courseName;

    …
}