곰돌이연구실

기타 항목

(웹 접근성 등)

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 페이지 참조) 

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

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

앞에서 간단히 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 등 다른 생산성 높은 언어로 옮겨가는 추세로 보인다.

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

C++ String에 대해서는 이전 글 참고

이번에는 Java다.

Java String은 익히 알려진것처럼 UniCode 사용을 예상하고 작업되어 각 문자 1개가 2바이트씩 차지하고, 문자열을 수정시에는 문자열 자체가 수정되는것이 아니라 수정된 문자열이 새로 생성되는 등의 특징이 있다.

하지만 '체감상' Java String이 C++ String보다 다루기 편했던것으로 기억하는데, 오랫만에 한번 뜯어보도록 하자.

이번 레퍼런스 자료는 Open JDK의 소스코드입니다.

검색하면 금방 찾으실 수 있으니 링크는 딱히 달지 않겠습니다.

2. Java String의 경우

    public String(char value[]) {
        this(value, 0, value.length, null);
    }

Java String 또한 Char형 배열로 이루어져 있으며 (* C++과는 다르게 포인터 개념을 사용할 수 없기에 일반 배열이다), Java에서는 Char형의 바이트 값이 2바이트 이므로, String의 내부 구현또한 2바이트 문자열을 저장하는것으로 이루어진다.

어찌보면 당연한 소리인데... 배열의 각 값이 2바이트면 전체가 2바이트 데이터의 배열 구조인것은 당연한 소리 아니겠는가..

여기서 바로 차이점이 나타난다.

Java String의 경우 처음 값이 정해져버리기 때문에, 사이즈 변환에 좀 심한 에로사항이 생기게 된다. C++의 경우에는 (아무튼) 배열 포인터로 구현이 되어있으니, 값을 늘리는것 만큼은 (메모리 침범이 일어나지 않는다는 전제하에) 쉽게 늘릴 수 있으나...

그리고 또한, Java String은 기본적으로 'UTF-16' 인코딩을 사용하고 있다.

참고중인 Open JDK의 String.java 파일에 보면...

A {@code String} represents a string in the UTF-16 format in which supplementary characters are represented by surrogate pairs. 

(see the section Character.html#unicode">Unicode haracter Representations in the {@code Character} class for
more information).

(Surrogate pairs 에 대해서는 나중에 따로 다루도록 하겠습니다. 저도 조금 이해할 필요가 있어보이네요)

아무튼 UTF-16 포멧으로 표현된다고 나타나있다.

UTF-8과 다른점은, 뭐 당연히 표현 비트 수가 8비트 / 16비트라는 차이점이라는것... 정도겠다.

아래부터는 String str = "Hello World";  라는 String을 선언해둔것으로 가정하고 시작한다.

* 또한, 기본적으로 세부 자료형은 StringUTF16임을 명시해둔다.

1) 접근법

(1) charAt(N);

C++ String의 at과 기능상 동일하다. N의 위치에 존재하는 값을 리턴해주는 메소드로, 내부적으로는 String Data Array(= byte 배열) 과 int N 값을 인자로 받고, 이를 getChar() 메소드에서 탐색하고 리턴해주는 방식이다.

그래서 getChar()는 어떻게 되어있느냐...

    static char getChar(byte[] val, int index) {
        assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
        index <<= 1;
        return (char)(((val[index++] & 0xff) << HI_BYTE_SHIFT) |
                      ((val[index]   & 0xff) << LO_BYTE_SHIFT));
    }

이런식으로, byte배열에서 index에 맞는 위치의 값을 bit shift를 통해 리턴해주는 모습을 보여준다.

Java에서는 Char형도 2바이트로 표현하니, 바이트 값이 2개가 올라가는것을 볼 수 있다.

(2)str.indexof(temp);

temp 라는 문자가 어디에 존재하는지 탐색해주는 메소드이다.

내부 구현은, indexof가 호출시, 호출된 String의 구조가 latin1 (잠깐 찾아보니 그냥 아스키코드값하고 동일하다.) 인가, 아닌가로 비교를 실시한다.

만일 latin1 형식이 아닌경우, StringUTF16라는 클래스의 indexof 메소드로 넘어가게되는데, 일반 구조의 경우에는 'getChar()' 를 호출하여, 문자열의 위치를 탐색하고 값을 리턴해주는 방식으로 이루어진다.

그런데 재밌는것이...

해당 메소드의 구현 밑바닥까지 가면

    @HotSpotIntrinsicCandidate
    private static int indexOfChar(byte[] value, int ch, int fromIndex, int max) {
        checkBoundsBeginEnd(fromIndex, max, value);
        return indexOfCharUnsafe(value, ch, fromIndex, max);
    }

    private static int indexOfCharUnsafe(byte[] value, int ch, int fromIndex, int max) {
        for (int i = fromIndex; i < max; i++) {
            if (getChar(value, i) == ch) {
                return i;
            }
        }
        return -1;
    }

'Unsafe' 라는 문구가 붙어있는것을 확인 할 수 있다.

범위 침범을 할 수 있어서 그런건지, 아니면 다른 이유가 있는건지는 모르겠지만 구현시에 '사실 좀 위험하긴한데...' 라는 생각을 했던건 아닌가 싶다.

2) 길이 파악

length(); 라는 메소드가 존재한다.

근데 구현이... 내가 잘못본게 아니라면

    public static int length(byte[] value) {
        return value.length >> 1;
    }

이게 끝이다.

배열값을 input으로 받고, 배열의 길이를 1 shift (뒤의 '\0' 문자 제거용으로 추정)하여 리턴해준다.

더 찾아봐도 저거 외에는 제대로 된 메소드를 찾을수가 없었다...

3) 비교

Java String에서는 '==' 를 쓰면 안된다는 사실을 알것이다.

==를 사용하게 되면, 값 자체를 비교하는것이 아니라 값의 위치, "객체"가 동일한지 아닌지를 비교하기 때문에 무조건 false가 날 수 밖에 없다.

그래서 사용하는것이 equals인데...

    public static boolean equals(byte[] value, byte[] other) {
        if (value.length == other.length) {
            int len = value.length >> 1;
            for (int i = 0; i < len; i++) {
                if (getChar(value, i) != getChar(other, i)) {
                    return false;
                }
            }
            return true;
        }
        return false;
    }

구조는 다음과 같다.

1)) 길이를 비교한다.

2)) 길이가 같다면 -> 동일한 위치의 문자를 1개씩 비교한다

3)) 이 중 하나라도 틀린다면 -> false

4)) 모든 비교를 통과했다면 true 

이런 식으로 구현이 되어있다.

아직 주제인 'C++ String 과 Java String의 차이' 에 대해서는 언급을 하지 않았는데, 이는 다음장에서 언급하도록 하겠다.

모 회사 면접 준비중에 예전에 당했던 문제가 생각나서 정리하려다, 문득 제대로 조사해본적이 없는거같아 기록용으로 작성한다.

사실, 검색해보다가 내가 시원하게 이해할만한 자료가 없었던것도 있고...

C에서 Char 형 배열 / 포인터로 겨우겨우 만들던 String에서 벗어나, 관리 함수등을 추가한 C++ String Class로 되면서, '어느정도는' 타 언어의 String 사용법과 비슷하게 이루어지기 시작했다. 물론, 문자열 다루는거는 Java 보다는 불편하긴한데, 이전 면접에서 '왜 불편한가요?' 라는 질문에 좀 어영부영 대답한 감이 없잖아 있는것같다.

따라서 포인터 개념이 살아있는 OOP인 C++과, 전부 GC로 관리되는 Java와 비교를 해보고자 한다.

1. C++ String의 경우 (wstring은 포함시키지 않음)

기본적으로 C++ String은 'Basic String' 이라는 자체 클래스를 내부에 구현한 상태로 되어있으며, Basic String의 생성자는 크게 'const Char *' 를 input으로 받는 경우, 자체 Allocator를 input으로 받는 경우(= 타 value_Type 배열포인터를 input으로 받는 경우), basic_string 참조값을 input으로 받는 경우로 나뉘어진다.

즉, 실제 구현에서는 '일단 모든 데이터형을 받을수 있도록' 구현이 되어있긴 하나, 문자열 자체를 받는경우는 여전히 Char 형 배열 포인터를 값으로 받는다... 고 설명할 수 있다.

그리고, String Class가 되면서, 각종 접근법 / 용량 체크 / 복사 / equal 등의 함수가 가능해졌다.

아래부터는 String str = "Hello World";  라는 String을 선언해둔것으로 가정하고 시작한다.

1) 접근법

str.at(N) = N번 자리의 문자열을 리턴해준다.

str.at(1) 을 사용시, 1번째 값인 e를 리턴해주게 된다.

str[N] = N번 자리의 문자열을 리턴해준다.

str.at(N)과 다른게 뭐냐고 한다면, 둘다 결국엔 str[N]으로 귀결되는건 동일하나,

basic_string<_CharT, _Traits, _Allocator>::at(size_type __n) const
{
    if (__n >= size())
        this->__throw_out_of_range();
    return (*this)[__n];
}

at()의 경우에는 잘못된 값 삽입 시 out of range() 경고를 리턴해주는 차이가 있다.

속도 자체는 자체 함수로 이동하지 않는 str[N]이 빠르긴 하나, 내가 짠 코드를 100% 믿을 수 있는게 아니라면 at()을 쓰는것을 추천한다...

2) 길이 파악

size() 함수와 length() 함수가 존재하는데...

    _LIBCPP_INLINE_VISIBILITY size_type size() const _NOEXCEPT
        {return __is_long() ? __get_long_size() : __get_short_size();}
    
    _LIBCPP_INLINE_VISIBILITY size_type length() const _NOEXCEPT {return size();}
    

그냥 length 함수 호출해도, size를 호출해도 결국엔 size() 함수가 호출되는거니까 아무거나 써도 된다 (...)

3) 비교

str.compare() 이라는 함수가 있다.

str.compare("ABC") 와 같은 방식으로 사용이 가능한데...

일반적으로, '같으면 0', '함수를 호출한 String이 사전순으로 빠를때 -1', '사전순으로 느릴때 1' 의 값을 리턴하는것으로 알고 있을것이다.

이는 또 재밌게도, 

basic_string<_CharT, _Traits, _Allocator>::compare(const _Tp& __t) const
{
    __self_view __sv = __t;
    size_t __lhs_sz = size();
    size_t __rhs_sz = __sv.size();
    int __result = traits_type::compare(data(), __sv.data(),
                                        _VSTD::min(__lhs_sz, __rhs_sz));
    if (__result != 0)
        return __result;
    if (__lhs_sz < __rhs_sz)
        return -1;
    if (__lhs_sz > __rhs_sz)
        return 1;
    return 0;
}

'일단' 두 String을 가져와 min 비교를 걸친 후 (String 별 호출순서 비교), 만일 min() 비교가 동일한것으로 나오면, 길이 비교를 진행, 이후 해당 값을 리턴해주는 식으로 진행된다.

즉, 만일 str.compare("Hello"); 를 넣어줬다면

Hello World / Hello 두 문자열의 비교 자체는 4번째 값인 o까지 비교를 하고, 그 이상은 비교가 불가능하니 if문으로 넘어가게 된다.

근데 여기서 좌측값 (= 함수를 호출한 String)의 길이가 더 길기때문에, 1을 리턴해주는것으로 결과가 종료되는것이다.

Min의 내부 구현은 (아스키코드 값의 경우) A값과 B값의 코드 순서로 비교를 수행하게된다.

자세한건 검색을 통해 찾아보시길...

아무튼, 요런 식으로 구현이 되어있는데, 위에 언급했다시피, '배열 포인터' 로 구현이 되어있기에, 문자열을 수정하면 해당 문자열 메모리 자체를 수정하는식으로 값을 수정하게 된다.

이것이 메모리 관리  관점에서 Java String과의 가장 큰 차이점이라고 볼 수 있기도 하다.

나머지는 다음장에... 생각보다 길어질거같아서 쪼개야할것같다.

(기억을 더듬어가며 쓰는거라 설명이 정확하지 않을 수 있습니다. 참고자료들을 봐주세요.)

오랫만에 잡설 하나 적어둔다.

float 등 부동소수점 변수 연산을 하다보면, 처음에는 실수로 var1 == var2를 했다가 틀려먹는 경우가 잦아, 이를 확인해보면 소수점 저 밑 끝자리에 내가 적지도 않은 이상한 값이 묻어있는 경우가 종종 보이곤 한다.

해서, 검색하다보면 비교시에 (var == 0.0f) 가 아니라 (* 이게 되는 언어도 있긴하다) 다른 방법을 쓰라고 하는 경우가 많고, 이 어처구니없는 상태를  해결하고자 찾다보면 'epsilon' 이라는 변수/함수 등이 보이게 된다.

Epsilon Delta, Epsilon은 일반적인 사용으로는 '수치 범위' 를 지정하기 위한 예약변수로 쓰기도 하는데,

보통은 ( var < Epsilon && var > -Epsilon )  와 같은 형식으로 비교하는 모습으로 쓰곤 한다.

이는, 부동소수점 연산의 특이사항때문에 사용하는것으로,

각 부동소수점 표현 포멧에 따라 '안전이 보장되는' 길이가 달라지는것을 인지하고, 이에 피해를 입지 않고자 (해당 증상을 '막는것'은 거의 불가능하다. 그럼 정밀도를 올려야하는데... 정밀도가 올라가면 연산 속도가 주르륵 떨어진다...) 추가하는 일종의 '상대 오차 반올림 값' (relative error unit roundoff, 일반적으로 쓰는 표현은 아닙니다.) 으로, 값을 보장할 수 없는 부분에서 반올림 등으로 근사값 처리를 해주기 위함입니다.

보통은 이를 프로그래머가 직접 만들기도 하지만 (만일 소수점 3번째 자리까지만 쓴다 => 4번째 자리나 5번째 자리에서 반올림 하겠다 등등?) 언어에 따라 이미 해당 값을 리턴해주는 함수가 존재하기도 합니다.

C++의 경우, limits 헤더의 numeric_limits 템플릿 클래스 안에 epsilon() 이라는 함수로 존재하며, 목적에 맞게 '거의 비슷한' 값을 비교 시에 사용하는 예시로 올라와 있습니다.

따라서...

이 값들을 이용함으로써 부동소수점 변수들에 대해 의미없는 오차 및 발생할 수 있는 문제들을 미연에 방지할 수 있게 된다... 는 점이 주요 포인트.

보통 부동소수점 연산이 많은 프로그램들에 경우에는, eplison delta 값을 이용하여 자체적으로 값을 비교해줄 수 있는 함수를 만들어 쓰곤 하는 편이다.

그게, 매번 ( var < Epsilon && var > -Epsilon ) 처럼 지저분하게 쓰는것보다는 좀 더 안전하고, '깔끔하게' 보일 수 있으니까. 

* 참고자료

1) https://en.wikipedia.org/wiki/(%CE%B5,_%CE%B4)-definition_of_limit

2) https://en.wikipedia.org/wiki/Machine_epsilon

3) https://en.cppreference.com/w/cpp/types/numeric_limits/epsilon

4) https://gigglehd.com/gg/hard/5427559