공부를 하다보니 하도 헷깔려서 정리 할 겸 작성함.

 


(물론 다른 언어들에게도 존재하지만) C 계열 언어에는 const라는 키워드가 존재한다.

 

간단히, '상수화 키워드' 로 알려져 있는 이 키워드는, 말 그대로 해당 키워드가 붙는 모든것을 상수화 (고정값 화) 시켜버린다.

 

여기서 알아두어야 할 것이, 모든 것이라는 점인데, 단순히 변수는 물론이고, 함수 삽입값(파라미터), 함수 리턴값, 심지어는 클래스/객체에도 사용이 가능하다.

 

근데 이게 어디 붙여도 다 상수화.... 되는건 맞는거 같은데, 좀 헷깔리는 감이 없잖아 있어서 정리를 좀 해보고자 한다.

 

일단 알아두어야 할 점은, const 키워드는 const 키워드 바로 다음에 오는것을 상수화 시킨다.

 

1. 변수의 상수화

const int A = 10;

 

int 형의 A 라는 이름을 가진 변수에 10을 넣고, 이를 상수화 시켜 사용하겠다는 의미이다.

 

이렇게 사용 시, A는 10이라는 값으로 고정되어 버리고, 어떤 방식으로든 수정이 불가능해진다. (상수 값이 되었으니..)

 

근데 이런 경우에, 만일 같은 이름 같은 타입의 변수를 다시 상수가 아닌 변수로 쓰고 싶다고 하면...

 

그냥 새로 선언해주면 끝이다.

 

이따구로 쓸 일이 있냐만은...

+ 특이 케이스 :

만일 const 멤버 상수에 레퍼런스를 붙인다고 하면, 레퍼런스 변수 또한 const로 선언해주어야 한다.

 

이유는 레퍼런스 접근을 통한 데이터 수정 방지.

 

애초에 굳이 const 선언해둔걸 억지로 애써서 수정할 필요가...?

 

하지말라면 하지말자.

 

 

 

2. 함수의 상수화 A

const int foo ();

 

함수의 리턴 타입에 상수 키워드가 붙는 경우이다.

 

이 경우는 사실 하나하나 따져보면 이해하기 쉬운게, "리턴 타입" 에 "상수 키워드", 즉 "리턴 값이 상수화" 된다는 의미와 동일하다.

 

즉, 함수가 실행되고 나온 결과값이 상수값이 되어 수정이 불가능한 값으로 얻어진다는 의미다.

 

어디다 써멱냐 싶지만, 생각보다 자주 보인다. 특히 문자열쪽이라던가.

간단히 이런식으로.

그럼 대입은 어떻게 하느냐?

 

그냥 쓰면 된다.

 

아무 문제 없음.

 

단지 가지고 있는 값이 현재 상수화 되어 보호되어 있다는것이지, 값을 누군가 대입받은 이후에는 그걸 어떻게 쓰던지 까지는 통제하지 않는다.

 

 

 

 

그냥 리턴값이 상수라는것만 기억하면 딱히 겁 먹을 필요 없음.

 

3. 함수의 상수화 B ; Const 멤버 함수

 

int foo() const;

 

이 케이스는 좀 특이 케이스인데, 함수 정의부가 상수화되어버린다.

 

무슨 얘기나면, 함수 내부에서는 값 변경이 불가능해진다 라는 의미이다.

 

더 정확히는, 함수 내부에서는 '지역변수를 제외한 모든 값에 대해 상수성을 보장한다' 라는 의미에 더 가까운데, 예를들어 함수 내에 값을 임시로 저장하기 위해 사용하는 temp 변수 등과 같은 케이스를 제외한 모든 경우에, 외부에서 진입된 값을 변할 수 없다는 의미이다.

 

이런 형태를 쓰는 케이스는 다양한 경우가 있는데, 가장 주의해야하는 케이스가 바로 포인터/레퍼런스 타입을 인자로 받는 경우이다. 

 

값을 복사하지 않고 원본을 사용하기 위해 가져 왔는데, 이를 시스템상에서 보장을 하기 위해 내부를 상수화 시켜버리는 것이다.

 

정리하면

 

1) Const 멤버 함수를 호출할 경우 멤버들의 값 변경을 허용하지 않음.

2) 하지만, Const 멤버 함수의 지역 변수는 값 변경이 가능함.

3) Const 멤버 함수를 일반 멤버 함수에서 호출하는것은 문제가 없으나 역은 불가능함. (상수성 파괴 위험)

 

* 여기서 3번은 테스트가 좀 필요해 보인다. 실제로 저런 케이스를 접해본적이 없고 테스트를 어떻게 해봐야할지 감이 잘 안잡히기도 하고...

 

 

 

4. 객체의 상수화

여러가지 케이스가 있는데 여기선 1번과 유사한 경우로 설명한다.

 

리턴값이 객체거나, 혹은 객체를 멤버로 가지는 클래스 / 자료구조에 대한 경우, 혹은 객체를 보호하고 싶은 경우에 객체 앞에 const를 붙여서 값을 리턴시킨다.

 

당연하겠지만 값을 사용하는것엔 문제가 없으나... 값 자체를 수정하려는 경우 (ex : 리턴 된 값이 객체인 경우)에는 수정이 불가능함에 유의.

* Roomlist는 STL::Set 자료구조를 이용한 컨테이너 입니다.

위의 경우는 실제로 겪은 케이스인데, map / set 등과 같이 자동 정렬이 되는 자료구조 등을 사용할 경우, 구조상으로 정렬 상태를 외부에서 깨트리지 않게 하기 위해 내부 자료를 const 형으로 리턴해서 돌려준다.

 

즉, 리턴된 객체 전체가 const로 이루어져서 레퍼런스 접근임에도 불구하고 데이터 읽기만 가능하고 쓰기/수정이 전혀 불가능해지는 문제 아닌 문제가 발생한다.

 

 

5. const_cast

 

왠만하면 쓰지말자

 

객체/상수화 변수의 상수성을 깨트리는 역할을 한다.

 

4번의 경우와 유사하게, 내부 규칙을 깨트리진 않으나 값을 수정하려고 할때 const로 리턴받아질때 (문자열을 받는다거나 등) 상수성을 깨트리고 값을 사용하게 해주는 C++ 캐스트인데...

 

굳이 상수화 시킨 이유를 생각해보며 왠만하면 피해보도록 하자.

 

 

 

'프로그래밍 > C/C++' 카테고리의 다른 글

짧은 기록  (0) 2021.06.18
포인터 변수 사용시 데이터 오염 문제  (0) 2020.11.28
오늘의 실수.  (0) 2020.03.29
Visual C++에서 C++ 버전확인하는 방법.  (3) 2020.02.27
기록 #1  (0) 2020.01.18

오랫만입니다.

 

짧게나마 근황이라도 남겨드리려구요.

 

 

1. 정보처리기사 취득

길고 긴 고난의 시간을 지나 드디어 정보처리기사 취득했습니다.

이번에 합격률 5%였다는데... 용캐도 그걸 뚫었네요 ㅎㅎ;

 

2. 올해 취업 포기.

음... 상반기 싹 다 조지고 나니까 이젠 혼자서 붙잡고 할 시기는 지난거 같아서요.

학원이나 다른 도움을 좀 받으면서 1년쯤 다시 공부하고 재도전 할 생각입니다.

리프레시 기간이라고 볼 수 있겠네요.

 

3. 스위치 구입.

닌텐도 스위치 동숲에디션을 구했습니다.

덤으로 링피트도 사서 열심히 온몸을 조지는 중입니다 허헛허

 

 

 

뭔가 프로그래밍 자체는 계속할거지만, 뭔가 좀 허망한 기분이 들긴 하네요.

 

이게 끝이 아니면 좋으련만. 

'신변잡기 > 일상' 카테고리의 다른 글

올해의 목표  (0) 2021.01.03
근황 2  (0) 2020.10.15
올해 목표  (0) 2020.05.18
오랫만에 책을 펴보았습니다.  (0) 2020.01.01
2020년 할일  (0) 2019.12.19

(진짜루)

(전부 다 를 다루는것이 아닌, "아마 회사 입사 테스트에서 봤던거 같은" 애들 위주로 정리합니다.)

 

1. 자료구조

1) 분류

(1) 선형 구조 : 선형 리스트(=배열), 연결리스트, 스택, 큐, 덱

(2) 비선형 구조 : 트리 (및 트리를 기반으로 한 자료구조), 그래프

 

2) 요약

(1) 연결리스트 : 각 노드의 포인터 부분을 이용하여 서로 연결시킨 자료구조.

(2) 스택 : 리스트의 한쪽 끝에서만 Input/Output이 가능. "LIFO" 구조의 자료형

(3) 큐 : 선형 리스트의 한쪽에선 Input, 다른 쪽에선 Output만 진행. "FIFO"구조의 자료형

(4) 덱 (Deque) : Input, Output이 양쪽에서 발생가능. 단 입/출력이 모두 양쪽에서 발생하진 않음.

(5) 트리 : Node (정점)과 가지 (Branch)를 이용하여 사이클을 이루지 않게 구현된 그래프.

Root Node에서 시작.

트리의 깊이 (Depth) : 트리 노드의 최대 길이.

트리의 차수 (Degree) : 각 노드에서 뻗어나온 가지의 수

단말 노드 (Terminal Node, Leaf Node) : 자식이 하나도 없는 (= Degree Zero) 노드

 

3) 이진 트리 운행

(1) Pre order (전위) : Root -> Left -> Right 순으로 진입.

(2) In Order (중위) : Left -> Root -> Right 순으로 진입.

(3) Post Order (후위) : Left -> Right -> Root 순으로 진입.

 

2. 정렬 / 탐색 알고리즘 기본

1) 기본

(1) 오름차순 : 다음 차수로 갈수록 값이 올라감. 1,2,3,4,5...

(2) 내림차순 : 다음 차수로 갈수록 값이 내려감. 5,4,3,2,1...

 

2) 종류 1 (오름 차순 기준)

(1) 삽입 정렬 : i값과 i+1 값을 비교 후, i > i+1 일 시 i+1을 i 이전에 삽입. 앞 부터 정렬됨

(2) 버블 정렬 : i값과 i+1 값을 비교 후, i > i+1 일 시 서로 맞바꿈. 뒤 부터 정렬됨

(3) 선택 정렬 : i값과 i+a 값을 비교, i > i+a 일 시 위치를 바꿔줌. i 값을 점진적으로 증가시킴 (i+a<=N)

 

3) 종류 2

(1) 이진 탐색 : 전체 리스트를 2개의 서브 리스트로 분리하여 탐색함.

찾고자 하는 값을 값의 중간값과 비교하며 검색.

중간 레코드 값은 ((첫번째 레코드 번호 + 마지막 레코드 번호)/2) 로 계산

(2) 해싱 : 해시 함수를 이용하여 리스트에 대한 Hash Table의 위치를 계산후 값을 저장하거나 검색함.

 

3. 파일 처리 / 파일 구조

1) 순차 파일 처리 : 입력되는 데이터를 논리적인 순서에 따라 물리적 연속공간에 저장.

기록 속도는 빠르나 삽입 / 수정 / 삭제, 검색은 매우 느림.

2) 색인 순차 파일 : 순차 & 랜덤 처리가 가능하도록 레코드를 정렬시켜 기록, 키 항목만을 모은 색인을 구성.

 

4. 논리 게이트 (시나공 2017 요약본 참조)

자세한것은 진리표 참조

 

5. 기초 표현

1) 2진법 / 8진법 / 16진법

(1) 2진법 : 0,1로만 값을 표현. 2의 배수 만큼 올라감

(2) 8진법 : 0~7까지의 값으로 표현, 2진법으로 변환 시 값 3개를 묶음 (000~111)

(3) 16진법 : 0~9,A~F (10~15) 까지의 16개 값으로 표현, 2진법으로 변환 시 값 4개를 묶음 (0000~1111)

 

2) 보수 (2진법 한정)

(1) 1의 보수 : 0과 1의 값을 뒤집음.

(2) 2의 보수 : 0과 1의 값을 뒤집고 1의 자리에 +1

 

3) 부동 소수점 표현 1 (float)

0bit : 부호

1~7 bit : 지수부

8~31 bit : 가수부

 

4) 자료 표현 코드

(1) BCD 코드 : 10진수 1자리를 2진수 4bit로 표현

(2) Excess-3 (3초과 코드) : BCD +3

(3) Gray 코드 : BCD 인접 코드를 XOR 연산을 이용하여 만듬

(4) 패리티 검사 코드 : 데이터 비트에 1bit의 패리티 비트 추가 (Odd : 1 Bit의 수가 홀수 / Even : 1Bit의 수가 짝수)

 

6. 컴퓨터 구조

1) CPU

(1) 제어 장치 : 장치들의 동작을 지시 / 제어. 주기억 장치에서 읽어들인 명령어를 해독, 제어 신호를 보냄

(2) 연산 장치 : 산술, 논리, 관계, Shift 연산 등을 수행. (ALU 등)

(3) 레지스터 : CPU 내부의 임시 기억 장소

 

2) BUS

: CPU, 메모리, I/O 장치 등과 상호 필요한 정보를 교환하기 위한 공동 전송선.

(CPU 연산 처리 체제에도 영향을 많이 받음 (32bit / 64bit 등))

 

3) CPU 상태

Fetch, Indirect, Execute, Interrupt의 4가지.

(1) Fecth : 명령어를 주기억 장치에서 CPU의 명령 레지스터로 가져와 해독

(2) Indirect : Fetch 단계에서 해석된 명령의 주소부가 간접 주소인 경우. 명령의 유효주소를 계산.

(3) Execute : 명령어를 수행하는 단계

(4) Interrupt : 문제 (Interrupt)가 발생할 시 복귀 주소 (Program Counter ; PC)를 저장시키고, 제어 순서를 인터럽트 처리의 첫번째 명령으로 이동.

인터럽트 이후 정상적인 과정에서는 Fatch로 복귀함.

 

4) 하드디스크

(2) Access Time

= Seek Time + Latency Time + Transmission Time

(Seek Time = 탐색 시간 : Head 이동 시간) / (Latency Time = Search Time = 회전 지연 시간, 특정 섹터 데이터가 Head까지 가는 시간) / (TransMission Time = 전송 시간 : Head Access Data 와 주기억 장치간의 데이터가 전달되는 시간)

 

5) Cache Memory

(L1, L2 캐시라고 불리던 그거)

CPU와 메모리 간의 속도차이를 줄이기 위해 사용하는 Buffer Memory.

 

Cache Hit Percent (캐시 적중률) = 적중 횟수 / 총 접근 횟수

 

6) 가상 메모리

(1) 이론 : MMU (Memory Management Unit)을 이용, CPU의 연산 비트수에 매치되는 메모리 사이즈를 실제 존재하는것처럼 인지시켜 컨트롤 시키는 공간.

각 프로세스는 자신만의 가상 주소 공간을 가지고 있으며, 프로그램에서 메모리 주소에 접근시 'logical memory' 주소에 접근하도록 유도한다.

실제로는 모든 프로세스가 자신만의 가상 주소 공간을 가지고 있어, 물리적인 메모리 주소로만 접근시 충돌이 일어날 수 있기에 프로세스의 logical memory 와 physcial memory를 분리시키기 위해 만들어진 구조이다.

(2) 'Page' : 가상 메모리를 사용하는 최소 크기 단위. 

(3) Demending Page : 실제로 필요한 Page를 물리 메모리로 로드하는 단계.

(4) Page Fault : 필요한 Page가 물리 메모리에 존재하지 않는 경우. 이 경우 원하는 Page를 물리 메모리로 로드하는 과정이 일어난다.

 

7) 기억장치 배치 전략

(1) First Fit : 프로그램 / 데이터가 들어갈 수 있는 첫번째 공간에 삽입

(2) Best Fit : 프로그램 / 데이터가 들어갈 수 있는 가장 작은 공간에 삽입

(3) Worst Fit : 프로그램 / 데이터가 들어갈 수 있는 가장 큰 공간에 삽입

 

8) 단편화

(1) 내부 단편화 : 내부 분할 영역이 할당될 프로그램의 크기보다 큼으로써, 할당 후 사용되지 않고 남은 공간.

(2) 외부 단편화 : 내부 분할 영역이 할당될 프로그램의 크기보다 작음으로써 할당될 수 없이 남아있는 공간.

 

 

7. 운영체제

2) 프로세스 : 프로세서 (CPU 등)에 의해 처리되는 사용자 프로그램이나 시스템 프로그램을 의미.

3) 스레드 : 하나의 프로세스 내에서 작동하는 스케쥴링의 최소 단위. 서로 독립적인 다중 수행 가능.

(1) 사용자 수준 스레드 : 사용자측 라이브러리를 이용하여 스레드 운용.

(2) 커널 수준 스레드 : 운영체제 커널에서 스레드 운용. 

4) 상호 배제 :

(1) 임계 구역 : 공유 데이터 및 자원. 특정 시점에는 단 한개의 프로세스만 자원을 차지할수 있도록 지정된 공유 자원.

(2) 상호 배제 (Mutual Exclusion) : 특정 프로세스가 공유 자원 사용시 타 프로세스가 사용할 수 없도록 제어.

(3) 세마포어 : 각 프로세스에 제어 신호를 전달, 순서대로 작업을 수행. 프로세스간 동기화 유지 및 상호 배제 보장.

(4) 교착 상태 (Deadlock) : 자원 무한정 대기 상태

교착 상태의 필요 충분 조건

 - 1 : 상호 배제 : 한번에 한개의 프로세스만이 공유 자원 사용

 - 2 : 점유/대기 (Hold & Wait) : 최소 하나의 자원을 점유중에 타 자원을 추가 점유하려고 대기중인 프로세스 존재

 - 3 : 비선점 : 다른 프로세스에 할당된 자원은 끝날때까지 뺏을수 없음

 - 4 : 환형 대기 (Circular Wait) : 프로세스대기가 원형으로 구성되어 자신에게 할당된 자원을 점유하며 앞/뒤의 프로세스 자원을 요구

 

교착상태 해결 기법

 - 1 : 회피 기법 : 교착상태가 발생시 피해나감.

 - 2 : 발견 기법 : 시스템에 교착상태가 발생했는지 점검.

 - 3 : 회복 기법 : 교착상태 프로세스를 종료하거나 자원 선점하여 프로세스 혹은 자원 회복

 

8. 프로세서 스케줄링

(1) 정의 : 시스템의 여러 자원을 필요한 프로세스에게 할당하는 작업

(2) Context Switching (문맥 교환) : A 프로세스에서 B 프로세스로 CPU가 할당되는 과정에서 발생하는 일련의 작업.

현재 CPU가 할당된 프로세스의 상태 정보를 저장 -> 새로운 프로세스의 상태 정보 설정 -> CPU 할당

CPU Overhead의 주 요인중 하나

 

(3) 비 선점형 스케줄링 : 이미 할당된 CPU를 뺏어갈 수 없음, 할당받을시 완료시까지 CPU 사용

1) FCFS (=FIFO) : 도착한 순서에 따라 차례로 CPU를 할당함

2) SJF (Shortest Job First) : 실행시간이 가장 짧은 프로세스부터 CPU 할당

3) HRN (Hightest Response-ratio Next) : SJF 보완, 우선순위에 따른 CPU 할당

우선순위 계산 공식 = (프로세스 대기시간 + 서비스 시간)/서비스 시간

결과값이 높을수록 우선순위가 빨리 부여됨.

 

(4) 선점형 스케줄링 : 준비상태 큐의 프로세스 중에 우선순위가 가장 높은 프로세스에게 먼저 CPU를 할당.

1) SRT (Shortest Remaining Time) : SJF의 선점형, 가장 짧은 시간이 남은 프로세스부터 CPU 할당

2) RR (Round Robin) : 시분할 시스템을 위해 고완, FIFO를 선점형태로 변형.

FIFO 기반이나, '할당 시간' 만큼 CPU를 사용 후, 실행이 완료되지 않으면 다음 프로세스에게 CPU를 넘기고 준비상태 큐의 가장 뒤로 배치됨. 

할당 시간이 클수록 FIFO와의 차이가 사라지고, 할당 시간이 작을수록 Context Switching과 Overhead 가 자주 일어남.

 

 

9. 네트워크

1) 경로 제어 (라우팅 기법)

(1) IGP - RIP : 최대 홉 수를 15로 제한. 특정 시간단위로 라우팅 정보 갱신

(2) IGP - OSPF : 홉 수에 제한이 없음. 라우팅 정보가 갱신될 때 변화정보만 모든 라우터에 알림

(3) EGP : 게이트웨이 간의 라우팅

(4) BGP : EGP의 단점 보완. 처음에는 RIP처럼 전체 경로 제어표 교환, 이후에는 OSPF처럼 변화정보만 교환.

 

2) 망 구조

(1) 성형 (Star) : 중앙 집중형

(2) 순환형(Ring) : 단말기들을 이웃하는것끼리 Point To Point 연결시킨 형태.

(3) 버스형(Bus) : 한개의 통신회선에 여러 단말기가 연결됨.

(4) 계층형(Tree) : 분산처리 구성 방식. 

(5) 망형(Mesh) : 모든 지점의 컴퓨터와 단말기를 서로 연결.

필요 회선 수 = (n(n-1))/2

 

3) 인터넷 주소 체계

(1) IP Class :

Class A : 국가 / 대형 통신망 (2^24)

Class B : 중대형 통신망 (2^16)

Class C : 소규모 통신망 (2^8)

Class D : 멀티 캐스트용

Class E : 실험용 (예비)

 

(2) 서브넷 마스크 : 4바이트의 IP주소 중 네트워크 주소와 호스트 주소를 구분하기 위한 비트

 

(3) IPv6 : 16비트씩 8부분으로 구성됨

 

(4) 도메인 네임 : IP주소와 매치되는, 문자로 구성된 주소

 

(5) DNS : 도메인 네임과 IP 주소를 상호변환해주는 시스템/서버

 

4) OSI 참조 모델

(7) 응용 계층 : 사용자 (응용 프로그램)이 OSI 환경에 접근할 수 있도록 서비스 제공.

(6) 표현 계층 : 응용계층 <> 세션계층 간 데이터 변환. 코드 변환, 데이터 암호화, 구문검색, 문맥관리 등

(5) 세션 계층 : 송 수신측 관련선 유지, 대화 제어

(4) 전송 계층 : 종단 시스템간 데이터 전송을 가능하게 함, 전송 연결 설정, 데이터 전송, 흐름제어 등 <TCP/UDP>

(3) 네트워크 계층 : 개방 시스템간의 네트워크 연결관리, 데이터의 교환 및 중계, 경로설정, 트래픽 제어 등 <IP>

(2) 데이터 링크 계층 : 두개의 인접한 개방 시스템간의 신뢰성 있는 정보전송을 위함. 흐름제어, 오류제어 등 <LLC>

(1) 물리 계층 : 장치간 실제 접속관 절단 등에 필요한 기계적, 전기적, 기능적, 절차적 특성 <RS-232C>

 

5) TCP/IP 계층 모델

(4) 응용 계층

(3) 전송 계층 

(2) 인터넷 (=네트워크) 계층

(1) 네트워크 엑세스 계층 : 실제 데이터 송/수신

 

6) 주요 프로토콜

(1) TCP : 전송계층, 신뢰성 있는 연결형 서비스 제공. FTP, SMTP (메일), HTTP 등

(2) UDP : 전송계층, 빠른 비연결형 서비스 제공, 동시에 여러 사용자에게 데이터 전달할 경우. 실시간 전송에 유리.

(3) IP : 네트워크 계층, 데이터그램을 기반으로 한 비연결형 서비스 제공. 패킷 분해/조립, 주소 지정, 경로 선택 등

(4) ICMP : IP와 조합, 통신중에 발생하는 오류 처리, 전송 경로 변경 등을 위한 제어메시지 관리

(5) ARP : IP주소에서 물리주소 (MAC Address) 로 변환

(6) RARP : 물리주소에서 IP주소로 변환

 

10. 보안

1) 암호화 기법

(1) 비밀키 시스템 : 동일한 키로 데이터 암호/복호화. 대칭 암호화 기법

(2) 공개키 시스템 : 서로 다른 키로 데이터 암호화 / 해독하는 비대칭 암호화 방식. 키의 분배 용이.

(해당 문서는 https://swifter22.tistory.com/17, UE4 Docu, 2BBear 님의 글을 참고하였습니다.)

 

 

언리얼엔진을 거의 처음 접해보면서, 유니티에서 처럼 폴더로 스크립트 관리를 하고자 하니...

처음부터 벽에 막히기 시작했다.

 

콘텐츠 브라우저의 C++ 클래스 항목을 가서 폴더를 만들겠다고 우클릭을 하면 생성할 수 없다고 나온다.

응 안돼 안돼

 

이는, 사실 언리얼에서 소스코드 등을 "모듈" 로 관리하기 때문에 발생하는 문제로, 관리의 용이성 / 실수 방지를 위해서.... 인지는 모르겠으나, 아무튼 에디터에서만으로는 바로 생성이 불가능하다.

 

해서 찾아본 결과.

 

수정할게 좀 많다.

 

일단 모듈을 하나 추가하겠다! 고 한다면...

 

1. Source 폴더 하위에 원하는 모듈명의 폴더를 추가.

PMG라는 폴더가 방금 추가한 폴더이다.

2. 모듈명 폴더 아래에 '모듈명.Build.cs' , '모듈명.cpp', '모듈명.h' 3가지 파일을 추가해준다.

반드시 모듈 폴더와 이름이 동일해야한다는점 잊지말자.

이런식으로.

이 파일들은 에디터에다 '이런 모듈이 있습니다' 하고 인지 시켜주는 목적으로, 설정을 안해주면 빌드할때 빼먹기만 하면 다행이고, 그냥 에러가 터져버린다.

 

잘 설정해주자.

 

1) Build.cs

솔직히 아직 Build.cs 파일의 특성을 덜 이해했습니다.

근데 명칭만 바꾸고 가져다 써도 되긴 하니, 일단 쓰시고 나중에 꼭 이해하시는거로. 나도 꼭 해놓고

 

// Copyright 1998-2019 Epic Games, Inc. All Rights Reserved.

using UnrealBuildTool;

public class PMG : ModuleRules
{
	public PMG(ReadOnlyTargetRules Target) : base(Target)
	{
		PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;

		PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine"});
		PrivateDependencyModuleNames.AddRange(new string[] { });
		
	}
}

이렇게만 해두면 일단 에러는 안난다.

 

2) 모듈명.h

얘는 (당장은) 정말 별거 없다.

모든 엔진의 정보가 담긴 Engine.h 헤더를 추가해주거나, 속성만 요약된 CoreMinimal.h 헤더를 추가해주면 된다.

상황에 따라 다르겠지만, 그걸 알 정도면 이런 글은 안 보고 있을테니 그냥 CoreMinimal.h 헤더 추가해주자.

 

// Copyright 1998-2019 Epic Games, Inc. All Rights Reserved.

#pragma once
#include "CoreMinimal.h"

 

3) 모듈명.cpp

이친구는...

일단 당연히 자신의 헤더파일을 추가해주고, 그 다음 모듈 매니저를 추가해줘야 한다.

그래야 얘가 어떤 모듈타입인지 인식을 하고, 어떤 이름의 모듈인지 에디터에서 알 수 있게 된다.

 

뭐 레퍼런스 문서에 보면 필요에 따라 (혹은 최초 모듈은) IMPLEMENT_PRIMARY_GAME_MODULE( ) 을 사용하여 모듈을 등록해주라고 하는데, 이건 사용할 일이 생기면 추가로 설명하는게 더 나을것같다.

 

#include "PMG.h"
#include "Modules/ModuleManager.h"

IMPLEMENT_MODULE(FDefaultModuleImpl, PMG);

(앞은 모듈 매니저의 기본 모듈 인터페이스, 뒤는 추가할 모듈 명)

 

일단 이렇게 하면 파일 생성해줄것은 끝났다.

 

이게 끝이냐? 에이 설마요.

 

3. Source 폴더의 .Target.cs 파일들을 열어봅시다.

모듈 타겟 설정해주고... 하다가 맨 마지막에 모듈 이름을 추가해주는 항목이 있습니다.

네. 추가해주시면 됩니다.

 

// Copyright 1998-2019 Epic Games, Inc. All Rights Reserved.

using UnrealBuildTool;
using System.Collections.Generic;

public class FindRandomMapTarget : TargetRules
{
	public FindRandomMapTarget(TargetInfo Target) : base(Target)
	{
		Type = TargetType.Game;
		DefaultBuildSettings = BuildSettingsVersion.V2;
		ExtraModuleNames.Add("FindRandomMap");
		ExtraModuleNames.Add("PMG");		//추가
	}
}

 

두 파일 모두에 추가해주시면 됩니다.

 

4. 프로젝트 루트의 '.uproject' 

해당 파일을 열면, (실행 말고 코드를 보면...)

JSON 양식으로 되어있는 내용물이 나옵니다.

양식에 맞게 항목을 추가해줍시다.

 

{
	"FileVersion": 3,
	"EngineAssociation": "4.24",
	"Category": "",
	"Description": "",
	"Modules": [
		{
			"Name": "FindRandomMap",
			"Type": "Runtime",
			"LoadingPhase": "Default"
		},
		{
			"Name": "PMG",
			"Type": "Runtime"			
		}
	]

 

일단 이러면 파일 세팅은 끝났습니다.

 

5. Visual Studio에서 솔루션 빌드 1회

성공이 떠야 됩니다.

뭔가 잘못되어있다면 바로 에러밭을 마주칠 수 있으니 주의하시길.

 

6. .uproject 파일에서 Generate

해당 기능을 수행해주면 VS 프로젝트에서 모듈이 폴더로 추가됩니다.

 

자 여기까지 정상적으로 수행되었다면...

에디터로 돌아와서 C++ 클래스 추가를 수행합니다.

 

 

그럼 이런식으로 내가 추가한 모듈이 보이면 성공입니다.

 

 

 

 

Extra :

 

사실 이렇게 해도 여전히 모듈이 에디터에 안뜨는 경우가 있다.

없어!

이 경우, 침착하게 더미 액터 등을 추가해보면...

그런데 짜잔

뭔가 실패했다고 경고가 뜬다.

 

요 상태에서 VS로 들어가면...

 

 

이런 경고가 발생한다.

 

자 이건 또 뭐냐... 그러게요

별거 없다. 결론만 따지면 재 빌드 돌리면 된다.

 

침착하게 에디터를 끄고, 재 빌드를 해주자.

(저는 분명 건든게 없습니다)

성공한다.

 

이후 다시 에디터를 켜주면 

드디어 추가 모듈이 생성되었다.

 

이제부터 모듈 작업을 하시면 됩니다. 네.

 

 

기타 항목

(웹 접근성 등)


1. 저작권 관리 요소

 

2. 웹 접근성 4대 지침

  1) 인식의 용이성 : 모든 컨텐츠는 사용자가 인식할 수 있어야 한다.

  2) 운용의 용이성 : 사용자 인터페이스 요소는 조작 가능하고 네비게이션 가능해야 함.

  3) 이해의 용이성 : 컨텐츠는 이해 할 수 있어야 한다

  4) 견고성 : 웹 컨텐츠는 미래 기술로도 접근 가능하도록 견고하게 만들어야 한다.

 

3. 클라우드 서비스 3가지 타입

  1) IaaS : 인프라 관련 클라우드 서비스 - AWS (EC2 등)

  2) PaaS : 플랫폼 관련 클라우드 서비스 - Windows Azure, Google Cloud Platform / Naver Cloud Platform 등

  3) SaaS : 소프트웨어 관련 클라우드 서비스 - 클라우드 저장소 등

소프트웨어 설계 / 구현 / 소프트웨어 테스트

 


1. UI 설계 원칙

  1) 직관성 : 누구나 큰 노력없이 쉽게 이해하고 사용 가능해야 함

  2) 유효성 : 사용자의 목적이 정확하고 완벽하게 달성될 수 있어야 함

  3) 학습성 : 초보와 숙력자 모두 쉽게 배우고 익힐 수 있어야 함

  4) 유연성 : 사용자의 요구사항을 최대한 수용하고 오류를 최소화할 수 있어야 함

 

2. UI 품질 요구사항 (ISO/ISE 9126)

  1) 기능성 : 실제 수행 결과와 품질요구사항간의 차이를 분석, 정확하지 않은 결과 발생율 등과 관련한 동작 관찰.

  2) 신뢰성 : 시스템이 일정 시간 또는 작동되는 시간 동안 의도하는 기능을 수행하는것을 보장

  3) 사용성 : 사용자와 컴퓨터 사이에 발생하는 행위를 정확하고 쉽게 인지 가능

  4) 효율성 : 할당된 시간에 한정된 자원으로 얼마나 빨리 처리하는가

  5) 유지보수성 : 요구사항을 개선하고 확장하는 데 있어 얼마나 용이한가

  6) 이식성 : 다른 플랫폼에서도 많은 추가 작업 없이 얼마나 쉽게 적용이 가능한가.

 

3. UI 요구사항

  1) 기능적 요구사항

    (1) 시스템의 입력 / 출력으로 무엇이 포함되어야 하는가

    (2) 시스템이 어떤 데이터를 저장해야하는가

    (3) 시스템이 어떤 연산을 수행해야 하는가

 

  2) 비기능적 요구사항

    (1) 기능적인 부분 이외의 요구사항

    (2) 사용성, 효율성, 신뢰성, 유지보수성, 재사용 성 등 품질에 관한 요구사항

    (3) 플랫폼, 사용 기술 등 시스템 환경에 관한 요구사항

    (4) 비용 일정 등 프로젝트 계획에 관한 요구사항

 

4. 네트워크 : OSI 7계층

  7) 응용 계층 : HTTP, FTP 등

  6) 표현 계층 :

  5) 세션 계층 :

  4) 전송 계층 : TCP, UDP

  3) 네트워크 계층 : IP

  2) 데이터링크 계층

  1) 물리 계층 : RS232C

 

5. TCP/IP 4계층

  4) 응용 계층 (5~7) : TCP/UDP 기반의 응용 프로그램 구축.

  3) 전송 계층 (= 4) : 연결 제어, 데이터 전송, TCP, UDP

  2) 인터넷 계층 (= 3)  : 통신 노드간의 패킷 전송, 라우팅, IP, ARP, RARP 등

  1) 네트워크 엑세스 (1~2) : 물리적 주소, MAC 등, LAN 패킷망 등에 사용

 

6. 라우팅 프로토콜

  1) RIP : 최초의 라우팅 프로토콜, 거리 벡터 알고리즘 활용, 30초 주기 갱신, 라우팅 루프 발생 가능.

  2) IGRP : RIP 개선, 네트워크 상태 고려

  3) OSPF : 링크 상태 알고리즘 사용, 변경 정보에 대해 RIP보다 빠른 업데이트. 토폴로지 정보가 전체 라우터에 동일하게 유지

  4) BGP : 규모가 큰 네트워크 (ISP 등)의 상호연결

 

7. 소프트웨어 테스트 프로세스

  1) 테스트 계획 : 목적 범위 정의, 대상시스템 구조 파악, 테스트 일정 / 종료 조건 정의 등

  2) 테스트 분석 및 디자인 : 테스트 목적 / 원칙 검토, 요구사항 분석, 데이터 및 환경 준비

  3) 테스트 케이스 및 시나리오 작성 : 테스트케이스 작성 및 검토, 테스트 시나리오 작성

  4) 테스트 수행

  5) 테스트 결과 평가 및 리포팅 : 테스트 결과 정리, 결과 평가, 리포팅

 

8. 소프트웨어 테스트 산출물

  1) 테스트 계획서 : 테스트 활동의 범위, 접근법, 자원, 일정, 업무 배정, 환경, 리스크 식별

  2) 테스트 케이스 : 테스트를 위한 설계 산출물, 테스트 케이스의 집합을 명세화.

  3) 테스트 시나리오 : 테스트 실행을 위한 동작 순서 기술

  4) 테스트 결과서 : 테스트 결과를 정리한 문서. 결과 평가 및 리포팅

 

9. 소프트웨어 테스트 원리 및 특성

  1) 테스팅은 결함이 존재함을 밝히는 활동 : 결함이 발견되지 않더라도 결함이 없다는것을 증명할 수 없음.

    따라서 소프트웨어 테스팅은 시스템에 결함이 존재함을 증명하는 것.  

  2) 완벽한 테스팅은 불가능하다. : 모든 것을 테스팅하는것은 불가능. (무한 경로/입력값/타이밍 이슈 존재)

    리스크 분석과 우선순위를 토대로 한 테스트에 노력을 집중하는것이 좋음.

  3) 조기 테스팅 (Early Testing)으로 시간 절약 가능 :

    수명 초기부터 테스팅을 함으로써 나중에 큰 비용이 동반되는 수정을 줄이거나 없엘 수 있음.

  4) 결함 집중 : 대부분의 결함은 소수의 모듈에 집중되어 발생된다. 80 / 20 법칙

  5) 살충제 페러독스 : 같은 테스트 연속 반복시에는 추가적인 결함 발견이 불가능하다.

  6) 테스트는 정황 (Context)에 의존한다. : 테스트는 환경 및 구조에 따라 다르게 진행해야한다.

  + 오류-부재의 궤변 : 개발된 시스템이 요구사항을 만족시키지 못하거나 사용성이 낮다면 오류를 발견하고 제거해도 품질이 높다고 할 수 없음.

 

10. 테스트 커버리지

  1) 기능 기반 커버리지 : 테스트 대상의 전체 기능을 모수로 설정, 실제 테스트가 수행된 기능의 수를 측정

    일반적으로 100% 달성을 목표로 하며, UI가 많은 경우 화면 수를 모수로 사용.

  2) 라인 커버리지 : 전체 소스코드의 Line 수를 모수로, 테스트 시나리오가 수행한 Line 수를 측정.

    단위 테스트에서는 라인 커버리지를 척도로 삼는다.

  3) 코드 커버리지 : 프로그램의 소스코드가 얼마나 테스트되었는가를 나타냄.

    소스코드의 구문, 조건, 결정 등의 구조 코드 자체의 테스트 정도를 측정.

    (1) 구문 커버리지 : 코드 구조내의 모든 구문에 대해 한번 이상 수행.

      100% 구문 커버리지 = 모든 구문에 대해 1회 이상 테스트 수행

    (2) 조건 커버리지 : 결정 포인트 내의 모든 개별 조건식에 대해 수행

    (3) 결정 커버리지 : 결정 포인트 내의 모든 분기문에 대해 수행

    (4) 변형 조건/결정 커버리지 : 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고, 독립적으로 영향을 줌.

 

11. 테스트 유형

  1) 프로그램 실행 여부 :

    (1) 정적 테스트 : 소프트웨어의 실행없이 명세 또는 구현, 개발 단계에서 컴포넌트나 시스템 테스트

    (2) 동적 테스트 : 컴포넌트나 소프트웨어를 실행하면서 수행하는 테스트. 블랙박스/화이트박스 등

 

  2) 테스트 기법

    (1) 블랙박스 테스트 : 적절한 테스트 베이스 (공식 요구사항 문서, 명세서, 유스케이스 등)에 대한 분석을 통해

    '구현된 기능'을 위주로 테스트

    (2) 화이트박스 테스트 : 프로그램의 내부구조나 구현을 기반으로 테스트 도출.

      코드, 아키텍쳐, 워크/데이터플로우 분석 

 

  3) 테스트 시각

    (1) 검증 : 명세된 요구사항이 충족되었는지를 조사 혹은 객관적인 증거로 확인. 제품의 생산과정 테스트

    (2) 확인 : 요구사항이 컴포넌트나 시스템을 의도적으로 사용/활용 충족여부. 정상동작 테스트

 

  4) 테스트 목적

    (1) 회복 테스트 : 시스템에 고의로 실패/오류를 유도한 뒤 정상적으로 복귀하는지 여부

    (2) 안전 테스트 : 소프트웨어의 보안 결함 테스트

    (3) 강도 테스트 : 시스템에 과다 정보량을 부과하여 과부화 시킨 뒤 정상 작동 검증

    (4) 성능 테스트 : 응답시간, 업무량, 반응속도 등 테스트

    (5) 구조 테스트 : 시스템 내부의 논리 경로, 소스코드의 복잡도 테스트

    (6) 회귀 테스트 : 이전에 정상 작동중이던 소프트웨어의 변경/수정에 대해 새로운 결함 발견 여부 테스트

    (7) 병행 테스트 : 기존 시스템과 변경된 시스템에 동일한 테스트 케이스를 이용하여 비교

 

  5) 테스트 종류

    (1) 명세 기반 테스트 : 명세를 바탕으로 테스트 케이스를 도출. TC를 통해 결함없음 보장. 블랙박스 테스트

    (2) 구조 기반 테스트 : 소프트웨어나 시스템의 구조, 논리 흐름에 따라 테스트 케이스 작성. 화이트박스 테스트

    (3) 경험 기반 테스트 : 유사 애플리케이션이나 기술에서의 경험,직관,테스터의 기술 능력으로부터 TC 추출

 

 

 

12. 애플리케이션 성능 지표

  1) 처리량 : 주어진 시간에 처리 가능한 트랜젝션의 수 / 시간당 페이지 수

  2) 응답 시간 : 입력이 끝난 후 애플리케이션의 응답 출력까지의 시간

  3) 경과 시간 : 요구를 입력한 시점부터 결과 출력시까지의 시간

  4) 자원 사용률 : CPU/메모리 사용량 등

 

13. 사용자 중심 모듈 패키징 순서

  1) 기능 식별

  2) 모듈화

  3) 빌드 진행

  4) 사용자 환경 분석

  5) 패키징 적용 시험

  6) 패키징 변경 개선

 

14. 제품 릴리즈 노트 작성 수행 순서

  1) 모듈 식별

  2) 릴리즈 정보 확인

  3) 릴리즈 노트 개요 작성

  4) 영향도 체크

  5) 정식 릴리즈 노트 작성

  6) 추가 개선 항목 식별

 

15. 패키징 도구를 활용한 설치 및 배포 수행 순서

  1) 빌드 내용 식별

  2) 패키징 도구 식별

  3) 패키징 수행

  4) 패키징 도구 설치

  5) 배포 작업

  6) 정상 배포 확인

 

DB / SQL 관련

 

작성중


1. DB의 특징

  1) 무결성 : 동일 내용에 대해 서로 다른 데이터가 저장되는것을 허용하지 않음

    (1) 개체 무결성

    (2) 참조 무결성

    (3) 도메인 무결성

  2) 일관성 : 삽입, 삭제, 갱신, 생성 후에도 저장된 데이터가 변함없이 일정

  3) 회복성 : 장애 발생 시 특정 상태로 복구

  4) 보안성 : 불법적인 노출, 변경, 손실로부터 보호

  5) 효율성 : 응답시간, 저장공간 활용 등이 최적화되어 사용자 소프트웨어, 시스템 등의 요구 조건 만족

 

 

2. 정규화

  1) 제 1 정규화 : 도메인 원자값

    반복되는 속성 제거, 결정자 찾기

  2) 제 2 정규화 : 부분적 함수 종속

    부분함수 종속성 제거 (X,Y->Z일때 X->Z or Y->Z인 경우 부분함수 종속)

  3) 제 3 정규화 : 이행적 종속

    이행함수 종속성 제거 (X->Y, Y->Z 일때 X->Z를 만족하는 경우)

  4) BCNF (보이스/코드) : 3차 정규화 + 모든 결정자가 후보키 집합에 속함.

    결정자 함수 종속성 제거 : 결정자에서 FD(조인 종속) 관계가 있다면 테이블 분리

  5) 제 4 정규화 : 다치 종속

    다중값 종속성 제거 : 상호 관계 없는 Entity는 Entity별로 분리

  6) 제 5 정규화 : 조인 종속

    조인 종속 제거 : 후보키를 통하지 않은 조인 종속 제거

  7) 정규화 효과 : 데이터 간 중복성 / 불일치 제거, 이상현상 제거, 데이터 무결성 확보. 

 

3. 명령어

  1) 권한 / Role 부여 - GRNAT <> 회수 - REVOKE

  2) 기본 연산

    (1) Insert : 데이터 추가

    (2) Select : 데이터 불러오기 (선택)

    (3) Update : 저장된 데이터 수정

    (4) Delete : 테이블 내 데이터 삭제

 

  3) 테이블

    (1) Create : 테이블 구성, 기본키 / 외래키 지정

    (2) Alter : 테이블 제약조건, 속성 수정

    (3) Drop : 테이블 삭제

 

5. 트랜젝션 4가지 특성

  1) 원자성 : 작업은 더이상 쪼개질 수 없음. 정상적으로 수행되거나 전혀 수행되지 않아야 함.

  2) 일관성 : 트랜젝션 수행이 DB의 일관성을 보존해야 함. 데이터 불일치 발생해서는 안됨

  3) 독립성 : 트랜젝션 수행은 독립적으로 수행되어야 함.

  4) 지속성 : 트랜젝션이 성공한 이후에는 변경전까지 데이터가 보존되어야 함.

 

6. 프로시저

  1) 개념 : 절차형 SQL을 활용, 특정 기능 수행 트랜젝션. 데이터 조작어 (DML) 수행이 일반적.

  2) 구성 

    (1) Declare : 프로시저의 명칭, 변수/인수, 데이터 타입 정의

    (2) Begin/End : 프로시저의 시작과 종료. Begin - End 쌍으로 'Block'을 구성.

    (3) Control : 특정 비교 조건에 따라 조건에 맞는 Block 혹은 문장 실행 (if - else와 유사)

    (4) SQL : Select / Insert / Update / Delete 등을 사용.

    (5) Exception : 예외 처리 부

    (6) Transaction : 수행된 내역의 DBMS 적용/ 취소 (Commit / RollBack) 여부 결정. 완료 처리.

 

7. SQL 사용자 정의 함수

  1) 개념

    (1) 프로시저와 동일하게 절차형 SQL을 사용. 연산 결과를 단일값으로 반환 가능

    (2) DBMS 공통 함수 외의 사용자 직접 정의

    (3) 사용자 정의 함수의 호출을 통해 실행. 반환 단일값을 조회 / 삽입 / 수정 작업에 이용 가능

    (4) 프로시저와 유사하나 '종료 시 단일값 반환' 이 가장 큰 차이점.

 

  2) 명령어

    (1) Create : 사용자 정의 함수 생성

    (1+) Or Replace : 이미 동일 명칭의 함수가 있다면 새로 작성한 함수로 교체

    (2) Return : 결과값 반환

야매임.

 

사실상 혼자보려고 만든거니까 참고정도로만 쓰세여

 

SQL쪽은 따로 정리 예정

 

* 소프트웨어 설계 / 공학 계열


1. 현행 시스템 파악 3단계

  1) 구성/기능/인터페이스 파악 : 시스템 구성 현황, 기능, 인터페이스 현황 파악

    (1) 현행 시스템 구성 현황 : 기간업무와 지원 업무로 구분. 기간 업무 - 주요 업무, 지원 업무 - 기간 업무 지원

    (2) 기능 현황 : 단위 업무 시스템의 현 기능 기술

    (3) 인터페이스 현황 : 데이터의 종류, 형식, 프로토콜, 유형, 주기 등을 명시.

    데이터 타입 (XML )과 통신규약 (TCP/IP )에 대한 현황 파악

  2) 아키텍쳐 및 소프트웨어 구성 파악

  3) 하드웨어 및 네트워크 구성 파악

 

2. 요구사항 보장 프로세스

  1) 상세요구사항

  2) 요구 분석

  3) 분할 발주

  4) 보증 활동

  5) 감리 시행

  6) 요구사항보장

 

2-2. 요구사항 개발 프로세스

  1) 요구사항 도출 : 소프트웨어가 해결해야 할 일을 이해. 요구사항 정보 수집.

  2) 요구사항 분석 : 상충되는 요구사항 해결, 소프트웨어 범위 파악, 환경과의 상호작용 이해

  3) 요구사항 명세 : 검토 / 평가 / 승인 될 수 있는 문서 작성, 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항 작성

  4) 요구사항 확인 (검증) : 분석가가 요구사항을 이해했는지 확인, 일관성과 완전성이 충족되는지 검증.

 

3. 연계 데이터 식별 및 표준화 절차

  1) 연계 범위 및 항목 정의

  2) 연계 코드 매핑 및 정의

  3) 변경된 데이터 구분 방식 정의

  4) 데이터 연계 (표현) 방식 정의

 

4. UML 특성 4가지

  1) 가시화 언어 : 개념 모델 작성, 오류 없이 전달, 의사소통 용이

  2) 구축 언어 : 다양한 프로그램 / 언어와 연결, 왕복 공학 가능, 실행 시스템 예측 가능

  3) 명세화 언어 : 정확한 모델 제시, 완전한 모델 작성, 분석 설계의 결정 표현

  4) 문서화 언어 : 시스템에 대한 통제 / 평가 / 의사소통의 문서화

 

4+. UML 4+1 모델

  : 고객 요구사항 중심, 설계자, 시스템 통합자, 개발자, 시스템 엔지니어의 관점으로 SW Architecture 구축

    다양한 이해 관계자들이 SW Architecture를 바라보는 View의 관점 간 관계 정의

 

5. 웹 서비스 기본 구조

[Web server Consumer] <Bind(SOAP)> [Web server provider [WSDL] [Service] ] <Publish (SOAP)>

<Publish (SOAP)> [UDDI Registry [WSDL] ] <Find(SOAP)> [Web server Consumer]

 

적당히 세가지 항목이 삼각형으로 연결되어있다고 보시면 됩니당.

  1) SOAP 

    (1) 필요한 서비스를 찾을 수 있는 웹 서비스 레지스트리 / 서비스 등록, 검색

    (2) 웹 서비스의 비즈니스 발행 / 검색하기 위한 기술적 스펙

  2) UDDI 

    (1) 웹 서비스를 표현하고 기술하는 언어 (= 서비스 표현)

    (2) 플랫폼 독립적인 단순 XML, 기반 포맷.

 

6. 애플리케이션 통합 솔루션

  1) EAI

    (1) 기업에서 운영하는 서로 다른 애플리케이션을 Backend 소프트웨어에 관계없이 비즈니스 프로세스 차원에서 통합

    (2) 이질적인 정보 시스템들의 데이터 연계 / 통합을 위한 소프트웨어 및 시스템 아키텍쳐 프레임워크

  2) EAI 구축 유형

    (1) Point to Point : 복수 앱 간 1:1 통합, 단순 구조

    (2) Hub & Spoke : 중앙 집중식 방식, 연동 Adapter를 통한 시스템 연계, 확장성 및 유지보수 편리

    (3) Bus : 동적 업무 프로세스 통합, 서비스 중심으로 하나의 업무 프로세스 진행, 데이터 병목 최소화

 

  3) ESB

    (1) 메시징과 웹 서비스, 데이터 변형, 인텔리전트 라우팅을 결합. 다양한 애플리케이션 간 상호작용을

      트랜젝션 무결성으로 연결 및 조절.

 

  5) EAI / ESB (이기적 정보처리기사 실기 1-117 페이지 참조) 

구분 EAI ESB
목적 애플리케이션 통합 앱 및 프로세스 통합
방식 Native Adapter 웹 서비스, JMS 등
표준 대부분 표준 (De facto) 개방형 표준
통합 범위 기업 내 이기종 앱 기업 내외 앱
유지 비용 높음 (연계 시 Adapter 구매 / 개발) 상대적 낮음 (서비스 단위 재사용)
확장성 높음 (지원 Adapter 내 확장 가능) 매우 높음 (서비스 오케스트레이션)
활용 E-Biz 인프라 SOA 인프라 구현 핵심 플랫폼

 

7. 서버 환경 구성

  1) 웹 서버 : 정적 데이터 처리 (HTML, CSS 등)

  2) 웹 애플리케이션 서버 : 동적 웹 서비스, Tomcat 등 WAS과 관련된 애플리케이션이 설치됨

  3) 데이터베이스 서버 : MySQL 등 DBMS 가 설치되는 하드웨어

  4) 파일 서버 : 서비스 제공을 위한 파일들을 저장하는 하드웨어

 

8. 형상 관리 4단계

  1) 형상 식별 : 이름, 관리번호 부여, 계층 구조로 구분하여 수정 및 추적이 용이하도록 작업

  2) 형상 통제 : 형상 항목의 변경 요구를 적절히 통제.

  3) 형상 감사 : 베이스라인의 무결성을 평가하기 위해 확인, 검증 과정을 통해 공식적 승인

  4) 형상 기록 (보고) : 베이스라인 현재 상태 및 변경사항 반영 여부 보고.

    형상의 식별, 통제, 감사 결과를 기록 및 관리, 보고서 작성.

 

9. 산업 범용 소프트웨어

  1) 시스템 소프트웨어 : 응용 소프트웨어를 실행하기 위한 플랫폼 제공. 운영체제, DBMS 등

  2) 미들 웨어 : 응용 소프트웨어가 운영체제로부터 제공받는 서비스 외의 서비스를 제공.

    WAS, 네트워크 관리, 시스템 관리, 클라우드 서비스 등

  3) 응용 소프트웨어 : 그 외 운영체제에서 실행되는 모든 소프트웨어. 일반적인 소프트웨어 해당.

 

10. 서비스 제공 소프트웨어

  1) 신규 개발 소프트웨어 : 새로운 서비스 제공을 목적으로 개발

  2) 기능 개선 소프트웨어 : 기존 서비스 기능에서 사용자 편의성, UI 개선, 업무 프로세스 개선 등

  3) 추가 개발 소프트웨어 : 기존 서비스 제공  시스템에 새로운 기능을 추가 개발

  4) 시스템 통합 소프트웨어 : 별도의 시스템들을 One-Stop 서비스를 위해 기능 및 데이터 통합개발

 

 

11. 정보보안 세가지 요소

  1) 기밀성 : 인가된 사용자만 필요성에 근거하여 접근

  2) 무결성 : 송수신되는 정보고 불법적으로 생성,변경,삭제되지 않아야 함

  3) 가용성 : 시스템의 지체없는 동작, 합법적 사용자가 사용을 거절당하지 않도록 함.

 

12. 주요 보안 약점

  1) 입력 데이터 검증

    (1) SQL Injection (삽입)

    (2) 경로 조작 / 자원 삽입

    (3) 크로스사이트 스크립트 : 입력값 검증없이 동적웹페이지 생성에 활용시 악성스크립트가 클라이언트에서 실행가능

    (4) 운영체제 명령어 삽입

    (5) 위험한 형식 파일 업로드

    (6) 신뢰되지 않는 URL 주소로 Redirection

    (7) XQuery Injection

    (8) XPath Injection

    (9) LDAP Injection : 외부 입력을 통한 의도되지 않은 Lightweigth Directory Access Protocol 명령어 수행

    (10) 크로스사이트 요청 위조

    (11) HTTP 응답 분할

    (12) 정수형 오버플로우

    (13) 메모리 버퍼 오버플로우

    (14) 부적절한 입력값 입력을 통한 보호매커니즘 우회

    (15) Format String Injection

 

  2) 보안 기능

    (1) 적절한 인증 없는 중요 기능 허용

    (2) 부적절한 인가

    (3) 중요 자원 권한 설정 오류

    (4) 취약한 암호화 알고리즘 사용

    (5) 중요 정보 평문 저장 / 전송

    (6) 하드코딩 된 비밀번호

    (7) 취약한 비밀번호 허용

    (8) 쿠키를 통한 정보 노출

    (9) 주석문 안에 포함된 시스템 주요 정보

    (10) 솔트 없는 일방향 해시함수 사용

    (11) 무결성 검사 없는 코드 다운로드

    (12) 반복된 인정서 제한 기능 부재

 

  3) 코드 오류

    (1) Null Pointer 역참조

    (2) 부적절한 자원 해제

    (3) 해제된 자원 사용

    (4) 초기화되지 않은 변수 사용

 

  4) 캡슐화

    (1) 잘못된 세션에 대한 데이터 노출

    (2) 제거되지 않고 남은 디버그 코드

    (3) 시스템 데이터 정보 노출

    (4) Public 메소드로부터 반환된 Private 배열

    (5) Private 배열에 Public 데이터 할당

 

  5) API 오용

    (1) DNS lookup에 의존한 보안 결정

    (2) 취약한 API 사용  

 

13. 소프트웨어 개발보안 계획 수립 단계

  1) 시작 단계 : 개발 목적, 계획, 전략 수렴, 보안 정책 검토, 보안 계획 수립

  2) 분석 단계 : 사용자 요구사항 정의, 보안 요구사항 정의

  3) 설계 단계 : 상세 요구사항 명세서 작성, 보안 요구사항 반영 -> 상세 기능 정의

  4) 구현 단계 : 환경 / 개발 보안 요건

  5) 시험 단계 : 프로그램 통합 시험. 보안성 평가, 보안 인증

  

 

14. 응집도 (위 -> 아래순으로 높아짐)

  1) 우연적 응집도 : 관련 없는 작업을 한 모듈에 모은 경우

  2) 논리적 응집도 : 유사한 성격을 같거나 특정 형태로 분류되는 처리요소들의 모임 (오류 / 출력 처리 등)

  3) 시간적 응집도 : 같은 시 간대에 처리되어야 하는 활동들의 모임

  4) 절차적 응집도 : 모듈 안의 기능들이 순차적으로 수행될 경우

  5) 통신적 응집도 : 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모인 경우

  6) 순차적 응집도 : 모듈 내에서 한 활동으로 나온 결과물이 다른 모듈의 입력값으로 사용

  7) 기능적 응집도 : 하나의 기능만 수행하는 모듈.

 

15. 결합도 (위 -> 아래 순으로 높아짐)

  1) 자료 결합도 : 모듈들이 변수 파라미터를 교환하여 모듈간의 상호작용이 일어남

  2) 스탬프 결합도 : 모듈간의 인터페이스로 배열이나 오브젝트, 스트럭쳐 등을 교환

  3) 제어 결합도 : 단순 처리 값 뿐만 아니라 제어 신호를 주고받는 경우

  4) 외부 결합도 : 다수의 모듈이 밖에서 도입된 데이터, 프로토콜, 인터페이스 등을 공유

  5) 공통 결합도 : 모듈 밖의 전역변수를 참조 / 갱신하는 식으로 상호작용

  6) 내용 결합도 : 모듈 내부의 변수나 제어정보를 다른 모듈에서 사용

 

 * 결합도는 최대한 낮게, 응집도는 높게 될 수록 유지보수성이 좋음.

 

16. 소프트웨어 프레임워크

  1) 프레임워크의 정의 : 기능구현에 집중하여 빠르게 개발할 수 있도록 기본적으로 필요한 기능을 갖춤

    ex : Java - Spring / Python - Django 등

  2) 프레임워크의 특징

    (1) 모듈화 : 구현을 인터페이스 뒤에 감추는 캡슐화를 통해 모듈화를 강화, 설계 / 구현 변화 영향 최소화

    (2) 재사용성 : 프레임워크 인터페이스는 반복적으로 사용할 수 있는 컴포넌트를 정의하여 재사용성을 높임

    (3) 확장성 : 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 확장할 수 있게 함

      애플리케이션 서비스와 특성을 커스터마이징 하는것을 보장하는데 필수적인 사항. 재사용성의 이점을 얻음

    (4) 제어의역흐름 : 보통은 애플리케이션에서 프레임워크로 진행되나, 프레임워크가 전체애플리케이션의 처리흐름을

      제어하여 특정 이벤트시 애플리케이션이 확장한 메소드를 호출, 제어가 프레임워크에서 애플리케이션으로 거꾸로        진행하게 함

+ Recent posts