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

 


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) 제어의역흐름 : 보통은 애플리케이션에서 프레임워크로 진행되나, 프레임워크가 전체애플리케이션의 처리흐름을

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

1. 취업하기 (3200+)

2. 토익 750 넘기기

3. -25kg

4. BridgeBBCC 대체 플러그인 만들기 (이왕 만드는김에 엑스스플릿이나 OBS 플러그인으로)

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

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

아는분의 제안 겸 조언으로 '투명한 물' 구현을 해보았다.

원래는 '언어나 프로그램 제약없이 할수 있도록' 다이렉트X를 추천받았으나...

하도 진행을 못하는걸 보고는 그냥 다른 엔진 써보고 해서... 원래 잡던 유니티 말고 언리얼엔진 처음 열어서 구현했습니다.

 

 

일단. 뭘 만들었는지는 영상부터 보고 갑시다.

 

(영상은 개선판입니다)

 

투명한 물, 물 표면 표현, 굴절, 반사 가 들어간 기본적인 물 표현입니다.

 

 

 

* 해당 자료 구현시 Pub Games의 영상을 참고하였습니다.


 

전체 구조도입니다.

 

아는건 별로 없지만, 까먹지 않기 위해서라도 하나씩 정리해봅시다.

* 틀린게 많을 수 있습니다. 틀린것이 있다면 지적바랍니다.

 

1. 포지션

 

1) 절대 월드 포지션 (Absolute Absolute world position) :

이 텍스쳐 구현에서 월드 포지션을 사용하는 목적은 텍스쳐가 적용된 오브젝트의 '위치에 무관하게' (=동일한 위치에) 텍스쳐가 적용될 수 있도록 하는 목적으로 사용된다.

즉, 텍스쳐 표현을 절대 월드 좌표로 고정해버림으로써, 오브젝트가 이동하더라도 텍스쳐 표현이 동일한 위치에 적용된다.

 

뭐 이렇게 쓰니 같은말 두번 쓴거같은데요... 표현 기준이 오브젝트 별 이 아니라 오브젝트가 놓인 월드 좌표계 기반이다... 정도면 될거같습니다.

 

(자료 참조)

 

2) Divide? :

값을 나누는 이유는... 자체 그림자 방지 (To provide a fall off to the self shadowing)를 위해서라는데... 아직 잘 이해가 안되는 부분이네요.

여긴 공부가 더 필요할것 같습니다.

나누는 값 자체는 텍스쳐를 적용할 오브젝트의 사이즈 만큼... 이라고 하는거 같네요.

 

3) Mask :

R은 X축, G는 Y축, B는 Z축으로 표현되는 모양이더라구요.

그리고 UE4에서는 Z축이 높이를 의미하기 때문에... 평면 가로/세로의 값만 중요하여 두 값을 추출하기 위해 R,G 마스크를 사용한다... 고 하는것 같습니다. 즉, 'XY 평면에 평행한 텍스쳐를 구현하기 위해 X,Y 값만 추출한다.' 고 볼수 있겠네요.

월드 포지션에는 당연하겠지만 3개의 값이 들어갑니다. X축, Y축, Z축.

사용한것은 ComponentMask였으며, 적당히 축약어로 검색해도 잘 튀어나옵니다.

축약어 사용 예

 

2. 노멀맵

'노멀맵' 자체에 대한 설명은 검색해보시거나 들고계신 책 보는게 빠르고... (사실 이해 덜했음)

이 텍스쳐에서는 어떻게 써먹고 있나 봅시다.

 

 

1) Panner : Panner를 사용하는 이유는 단순하지만 큰 이유입니다. 물이 흐르는것을 표현하기 위해 텍스쳐를 움직여줘야 하기 때문이죠.

텍스쳐의 U (가로) / V (세로) 를 조합한 방향으로 움직여 복잡한 애니메이션이 일어나는것처럼 보이는 목적입니다.

레퍼런스 참조 하시면 더 좋습니다. 넹.

input은 월드 좌표계였습니다.

 

2) Texture Sample : 말할것도 필요없는 노멀맵입니다.

위 아래의 텍스쳐가 조금 다른것처럼 보이는데, 사실 두개 같은거에요. 그냥 복사 - 붙여넣기 한것.

텍스쳐에서 '질감'을 표현해주는 노멀맵을 가져와서 적용시킨것입니다.

두개인 이유는 물 흐르는 표현을 2개로 겹쳐서 그런것이고... 사방에서 퍼지는걸 하고싶으시다면 Panner를 포함해서 4개를 넣으시면 되겠습니다.

 

3) Add? : 말도 필요없이 그냥 만들어진 Panner - Texture 세트를 합치는 목적입니다.

그래야 한번에 출력되죠.

 

4) Constant 3 Vector : 솔직히 얘가 제일 이해가 안갑니다.

기능 자체는 '3채널 상수값'을 벡터 형식으로 출력해주는것이 전부입니다.

3채널을 사용하는 텍스쳐 좌표 변경시 사용하는것이 좋다는데...

잠깐 찾아보니 실행 직전에 한번 계산되고, 플레이 도중에는 변경이 불가능한 마테리얼 인스턴스. 라고 하네요. 

근데 만일, 물이 튀기는 표현등을 넣는다면... Dynamic 값을 이용해야하지않을까 싶네요.

이것도 레퍼런스 참조해보시면 더 도움이 될것 같습니다.

 

5) Multiply : 움직임이 구현된 Texture 와 인스턴스 값을 곱해서 적용시키는 목적입니다.

더하면 단순히 수치만 고정되는것이고, 곱하게 되면 각 R/G/B값에 해당되는 수치가 곱해져 계산이 되겠네요.

 

여기까지 붙은것을 마테리얼 파라미터의 Normal에 고정시켜줍니다.

 

이러면 물 표면 표현이 완성됩니다.

 

 

3. Opacity (투명도)

1) Depth Fade : 말그대로 '깊이별 Fade' 입니다. 인자로는 투명도 값과, Fade가 시작되는 월드좌표 수치를 받네요.

2) Fresnel (프레넬) : 실제로는 '관찰자가 바라보는 각도에 따라 반사되는 빛의 세기가 달라지는 현상을 설명하는 데 사용되는 용어', 즉 반사와 관련된 값인데요...

물의 투명도는 Fresnel값 계산과 반대로, 수직으로 보면 투명하고, 평행하게 될수록 덜 투명하게 보여야 합니다.

그래서 Fresnel값에 1-X를 해줘서 값을 뒤집는것이구요.

이를 곱해서 Fresnel에 따라 Fade가 일어나도록 구현이 됩니다.

 

4. Reflection (반사)

사실 구현하면서 제일 골치아프게 했던 부분인데요...

구현 자체는 금방했으나, 반사값을 너무 크게 하는 바람에 카메라 사이즈(= 스크린 사이즈)만큼의 사각형 격자처럼 반사가 일어나는 참사가 일어나기도 했습니다.

 

구현자체는 2시간만 걸렸으나 이거 원인 찾는데 3시간 넘게 써버려서 총 작업시간이 6시간 언저리로 만든 원흉...

대충 이렇게 말이죠.

 

뭐. 지금은 수정이 되었습니다.

 

 

 

 

반사값 파라미터는 딱히 뭐 더 없습니다.

Depth Fade 값에 반사 수치 인자를 곱해줘서 그걸 Reflection 파라미터에 넣어주면 끝입니다.

그냥 값 조절 잘 하십시오. 말고는 할말이 없네요. 넹

 

5. Base Color

 

 

Fresnel에 붙어있는 Normal Map 값은 아까 만들었던 그 Normal Map 값입니다.

 

1) Color : 말그대로, 밝은 면 / 어두운 면의 컬러링입니다. 큰 차이는 없지만, 색상이 변경되면 차이가 있긴 하더라구요.

원하신다면 저 값을 녹색이나 보라색 등으로 바꾸면 독물이 되어버리는 진기한 현상을 목격하실 수 있습니다.

 

2) Lerp (Linearly interpolate, 선형 보간) :

네. 선형대수 시간에 나오던 그 선형보간입니다. 단순히 선형보간 짧게 설명하자면 A / B 점을 가지고 중간의 임의의 값을 뽑아내기 위한 방법인데요. 왜 갑자기 여기서 쓰이느냐.

컬러가 2개밖에 없잖아요? 근데 자연스러운 컬러링을 위해서라면 범위에 따라 색상이 자유롭게 바뀌어야하니... 그때 적용이 되어서 들어가는 셈입니다.

그래야 약간 깊이, 더 깊은곳 등등에서 색이 자연스레 들어가는것이겠죠.

이를 Depth Fade 값과 곱해줌으로써 Depth 값에 따라 적용이 되도록 해줍니다.

 

3) Diffuse (디퓨즈) :

일반적으로 Diffuse Map은 물체의 입체감, 깊이감, 색을 부여해주는 요소인데...

단순하게 설명하자면 텍스쳐의 색감과 질감을 나타내주는 요소라고 할 수 있겠다.

사실 이쪽도 아직 이해가 부족해서... 다른 자료를 찾아보시는걸 추천한다.

 

아무튼 이 값은 마테리얼 파라미터의 베이스 컬러에 고정시켜줍니다.

 

이로써 4가지 항목 (노멀맵, 베이스 컬러(=디퓨즈 맵), 리플렉션, 투명도)를 모두 적용시켰다.

 

그렇게 나오는 마테리얼 결과값은 아래와 같다.

(실제로는 움직입니다)

잘 보면 투명도, 반사등이 적용되어있는걸 볼 수 있다.

 

이걸 물 표면에 적용시켜주면 위 영상과 같은것이 나오게 되는것.

 

단순히 영상 하나를 참고해서 야매로 만든것인데, 다음에는 좀 공부를 해서 물리가 들어간 물 구현도 해봐야 할 듯 싶다.

https://docs.microsoft.com/en-us/windows/win32/api/directxmath/ns-directxmath-xmmatrix

 

XMMATRIX (directxmath.h) - Win32 apps

Describes a 4*4 matrix aligned on a 16-byte boundary that maps to four hardware vector registers.

docs.microsoft.com

 

빙글빙글 

https://www.reddit.com/r/Unity3D/comments/gctq1q/i_made_a_tool_that_bakes_unity_physics_into/?utm_source=share&utm_medium=web2x

 

I made a tool that bakes Unity physics into texture and replays it on GPU with virtually zero cost.

Posted in r/Unity3D by u/Tomek_SC • 3,327 points and 134 comments

www.reddit.com

 

www.reddit.com/r/Unity3D/comments/gbwya1/i_worked_a_lot_on_this_while_in_quarantine_and_in/?utm_source=share&utm_medium=web2x

 

'게임 개발 > Unity' 카테고리의 다른 글

짧은 근황  (0) 2021.06.13
Rect Transform 잠깐 메모  (1) 2020.02.09
분명 자주 쓰는데 자주 까먹는 기능들  (0) 2019.12.27

앞에서 간단히 C++ String과 Java String을 알아봤다.

 

이제 각설하고, 두 String의 구현법 및 내부 구현 함수들을 보며 뭐가 다른지 파악해보자.

(Java에서는 메소드로 읽는게 정석이나, 편의를 위해 전부 함수로 칭하도록 하겠다)

 

(빠지거나 잘못된것이 있다면 덧글로 지적바랍니다.)

(C++의 경우 : C++17까지 / Java의 경우 : Java 8+ 까지 를 기준으로 작성하였습니다.)


1. 절대값

일단 이 방식이 매우 안좋은 방식인건 알지만, 단순히 각 String의 함수 개수를 세어보기로 했다.

1) C++

https://en.cppreference.com/w/cpp/string/basic_string

기준, Operator 연산을 제외하고 31개 (+a)의 함수가 존재한다.

 

2) Java

https://docs.oracle.com/javase/8/docs/api/

기준, 중복을 제외하고 40개 (+a) 메소드가 존재한다.

 

2. 문자열 접근

특정 위치의 문자열에 접근할 수 있는 함수들이다.

1) C++

(1) front / back : 각 String의 맨 앞 / 맨 뒤 값을 리턴해준다.

(2) begin / end : Iterator로, 각각 String의 맨 앞 / 맨 뒤 '위치'에 접근가능하게 해준다. 

(3) data : 맨 앞의 '포인터 값'을 리턴해준다.

(4) at / '[ ]' : 특정 위치의 값을 리턴해준다.

 

2) Java

(1) charAt : 특정 위치의 값을 리턴해준다.

의외로 이거 하나밖에 안보이는것같지만....

 

3. 문자열 삽입

문자열에 값을 삽입하는 함수들이다. 생성 및 수정 제외.

 

1) C++

(1) push_back / pop_back : 문자열의 맨 뒤/맨 앞에 문자를 추가한다.

push_back와 append, '+=' 는 모두 같은 결과를 보여준다.

 

2) Java

(1) concat(string) : 호출한 String의 뒤에 concat에 인자로 삽입된 문자열을 덧붙인다.

 

 

4. 문자열 관리

문자열의 특정 값을 수정하거나, Case를 변경해주는 등의 함수들이다.

1) C++

(1) replace() : 특정 위치의 값을 변경해준다. (C++11부터 가능)

(2) swap(string) : 두 String의 값을 변환해준다. 

 

2) Java

(1) replace(A, B) : A 문자열을 B 문자열로 일괄 변환한다.

(2) toLower/UpperCase() : 각각 전체 문자열을 소문자/대문자로 변환한다.

(3) trim() : 문자열 앞 뒤의 '공백'을 제거한다.

(4) valueOf(Type) : 인자로 주어진 값을 문자열로 변환한다. 모든 기본형(PrimitiveType)에 대응.

 

 

5. 문자열 추출

특정 문자열을 자르는 함수들이다.

1) C++

(1) copy(char* arr, size_t length, size_t index) : arr에 index부터 length까지의 문자열을 복사해준다.

(2) substr(size_t index, size_t length(기본값 : Underflow -> INT_MAX)) : 문자열을 index부터 length만큼 리턴한다.

(3) find_last_of() : 인자로 받은 문자열이 '마지막으로 나타난 위치' 이후를 리턴해준다.

 

2) Java

(1) split(string) : 인자로 들어온 정규 표현식에 따라 문자열을 나누어 리턴

(2) substring(int(, int)) : 인자로 들어온 인덱스부터 새로운 문자열로 리턴

 

 

6. 문자열 비교

문자열을 찾거나, 비교에 사용되는 함수들이다

1) C++

(1) find(string) : 인자로 받은 문자열이 '어디에 있는지'를 찾아준다.

 

2) Java

+ 가 붙은 함수는 'Case'를 구분하지 않는 함수가 존재하는 경우이다.

(1) indexOF(string) : 인자로 받은 문자열이 '어디에 있는지'를 찾아준다.

(2) contains(char) : 인자로 받은 문자열이 존재하는지 아닌지를 찾아준다.

(3) compareTo(string)+ : 인자로 받은 문자열과의 사전식 비교를 실시한다.

(4) equals(string)+ : 인자로 받은 문자열과 동일한 문자열인지 비교한다.

(5) LastIndexOf(string) : 인자로 받은 문자열이 '마지막으로 나타난 위치'를 찾아준다.

(6) matches(string) : 정규 표현식인지 아닌지 체크.

 

 

7. 기타 기본사항

1) C++

(1) C++ string은 char* 문자열 배열로 이루어져 있어, 각 항목이 1바이트로 처리된다.

ASCII가 아닌 타 문자 (CP949 등)에 대해서는, 내부적으로 항목 2개를 1개로 치환해서 비교하게 되어, 단순 순차접근을 실시하게 될 시 "깨진 값"을 얻게 된다.

 

2) Java

(1) Java에서는 char 형 또한 2바이트로 이루어져 있어, UTF-16 데이터를 한 묶음으로 처리가 가능하다.

C++ 에서처럼 순차접근 했다고 깨지는 불상사는 안 일어난다 (...)

 

 


뭔가 단순 비교를 했을때, Java의 경우 변환, 비교 함수 등이 많이 갖춰져 있었고, C++의 경우엔 의외로 삽입쪽이 Java보다 풍성하게 되었음을 알 수 있었다.

 

실제로는 7번 항목의 문자열 처리방식때문에 문자열을 많이 다룰시 C++보다는 Java를 선택하게 되고, 요즘은 단순 문자열 비교 등에 경우엔 Python 등 다른 생산성 높은 언어로 옮겨가는 추세로 보인다.

 

간단히 레퍼런스 자료만 보며 작성한것이므로, 다른 점이나 문제가 있다면 알려주시면 반영하겠습니다. 

+ Recent posts