1. UML : 관계 정리
- 연관 관계 ( Association ) - 2개 이상의 사물이 서로 관련되어 있는 관계
- 집합 관계 ( Aggregation ) - 하나의 사물이 다른 사물에 포함되어 있는 관계
- 포함 관계 ( Composition ) - 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
- 일반화 관계 ( Generalization ) - 하나의 사물이 다른 물에 비해 더 일반적이거나 구체적인 관계
- 의존 관계 ( Dependency ) - 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
- 실체화 관계 ( Realization ) - 할 수 있거나 해야하는 기능으로 서로를 그룹할 수 있는 관계
2. UML : 다이어그램
1. 구조 다이어그램
| 구분 | 설명 |
| 클래스 다이어그램 | 시스템을 구성하는 클래스들 사이의 관계를 표현한다. |
| 패키지 다이어그램 | 클래스나 유스케이스 등을 포함한 여러 모델 요소들을 그룹화 하여 패키지를 구성하고 패키지들사이의 관계를 표현한다. |
| 복합체 구조 다이어그램 | 복합 구조의 클래스와 컴포넌트 내부 구조를 표현한다. |
| 객체 다이어그램 | 객체 정보를 보여준다. |
| 컴포넌트 다이어그램 | 컴포넌트 구조 사이의 관계를 표현한다. |
| 배치 다이어그램 | 소프트웨어, 하드웨어, 네트워크를 포함한 실행 시스템의 물리 구조를 표현한다. |
2. 행위 다이어그램
| 구분 | 설명 |
| 유스케이스 다이어그램 | 사용자 관점에서 시스템 행위를 표현한다. |
| 활동 다이어그램 | 업무 처리 과정이나 연산이 수행되는 과정을 표현한다. |
| 콜라보레이션 다이어그램 | 순차 다이어그램과 같으며 모델을 고간에 제약이 없어 구조적인 면을 중시한다. |
| 상태 머신 다이어그램 | 객체의 생명주기를 표현한다. |
| 순차 다이어그램 | 시간 흐름에 따른 객체 사이의 상호적인 표현을 한다. |
| 통신 다이어 그램 | 객체 사이의 관계를 중심으로 상호작용을 표현한다. |
| 상호작용 개요 다이어그램 | 여러 상호작용 다이어그램 사이의 제어 흐름을 표현한다. |
| 타이밍 다이어그램 | 객체 상태 변화와 시간 제약을 명시적으로 표현한다. |
3. 직유학유 ( UI 의 기본원칙 )
사용자 인터페이스 UI의 기본 원칙
- 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 함
- 유효성 : 사용자의 목적을 정확하고 완벽하게 달성 해야 함
- 학습성 : 누구나 쉽게 배우고 익힐 수 있어야함
- 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화 해야함
4. 디자인패턴
1. 생성, 구조, 행위
| 생성(Creational) 패턴 | 구조(Structural) 패턴 | 행위 (Behavioal) 패턴 |
| - Abstract Factory - Builder - Factory Method - Prototype - Singleton |
- Adapter - Bridge - Composite - Decorator - Facade - Flyweight - Proxy |
- Chain of Responsibility - Command - Interpreter - Iterator - Mediator - Memento - Observer - State - Strategy - Template Method - Visitor |
2. 생성 패턴 상세 설명
| 패턴 명 | 설명 |
| Abstract Factory | 동일한 주제의 다른 팩토리를 묶어준다. |
| Builder | 생성과 표기를 분리해 복잡한 객체를 생성한다. |
| Factory Method | 생성할 객체의 클래스를 국한하지 않고 객체를 생성한다. |
| Prototype | 기존 객체를 복제함으로써 객체를 생성한다. |
| Singleton | 한 클래스에 한 객체만 존재하도록 제한한다. |
3. 구조 패턴 상세 설명
| 패턴 명 | 설명 |
| Adapter | 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록, 타 클래스의 인터페이스를 기존 인터페이스에 덧씌운다. |
| Bridge | 구현뿐만 아니라, 추상회된 부분까지 변경해야되는 경우 활용 |
| Composite | 복합 객체와 단일 객체를 동일하게 취급 |
| Decorator | 객체의 결합을 통해 기능을 동적으로 유연하게 확장 |
| Facade | 통합된 인터페이스 제공 |
| Flyweight | 여러 개의 '가상 인스턴스'를 제공하여 메모리 절감 |
| Proxy | 특정 객체로의 접근을 제어하기 위한 용도로 사용 |
4. 행위 패턴 상세 설명
| 패턴 명 | 설명 |
| Chain of Responsibility | 한 요청을 2개 이상의 객체에서 처리 |
| Command | 요구사항을 객체로 캡슐화 |
| Interpreter | 문법 자체를 캡술화 하여 사용 |
| Iterator | 내부구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능하게 해주는 행위패턴 |
| Mediator | 상호 작용의 유연한 변경을 지원 |
| Memento | 객체를 이전 상태로 복구시켜야 하는 경우, 작업취소'Undo' 요청 가능 |
| Observer | 객체의 상태 변화에 따라 다른 객체의 상태도 연동, 일대다 의존 |
| State | 객체의 상태에 따라 행위 내용을 변경 |
| Strategy | 행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 변환 |
| Template Method | 상위작업의 구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행 |
| Visitor | 특정 구조를 이루는 복합 객체의 원소 특성에 따라 동작을 수행할 수 있도록 지원하는 행위 패턴 |
5. 결합도 Coupling
| 명칭 | 설명 |
| 내용 결합도 ( Content Coupling ) |
한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조 하거나 수정할 때의 결합도 |
| 공통(공유) 결합도 ( Common Coupling ) |
파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우의 결합도 |
| 외부 결합도 ( External Coupling ) |
어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도 |
| 제어 결합도 ( Control Coupling ) |
어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호나 제어 요소를 전달하는 결합도 |
| 스탬프 결합도 ( Stamp Coupling ) |
모듈 간의 인터페이스로 배열이나 레코드 등의 자료구조가 전달될 때의 결합도 |
| 자료 결합도 ( Data Coupling ) |
모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도 |
6. 응집도 Cohesion
| 명칭 | 설명 |
| 기능적 응집도 ( Funtional Cohesion ) |
모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우이다. 구조도 최하위 모듈에서 많이 발견된다. |
| 순차적 응집도 ( Sequential Cohesion ) |
모듈 내부에서 한 활동으로부터 출력값을 다른 활동의 입력값으로 사용하는 경우이다. |
| 통신적 응집도 ( Coummunication Cohesion ) |
동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우이다. |
| 절차적 응집도 ( Procedural Cohesion ) |
모듈이 다수의 관련 기능을 가질 때 모듈 안의 요소들이 그 기능을 순차적으로 수행할 경우이다. |
| 시간적 응집도 ( Temporal Cohesion ) |
연관된 기능이라기 보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리하는 경우이다. |
| 논리적 응집도 ( Logical Cohesion ) |
유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우이다. |
| 우연적 응집도 ( Coincidental Cohesion ) |
모듈 내부의 각 구성 요소들이 연관이 없는 경우이다. 모듈화 장점이 없다. 유지보수가 어렵다. |
7. 암호화 (대칭/비대칭/일방향) 정리
대칭키 암호 방식 - 블록 암호화 방식
| 명칭 | 설명 |
| DES | 구 미국 표준 개인 키 암호화 알고리즘 56 비트 키 사용 Feistel 암호 방식을 사용한다. |
| SEED | 한국 인터넷 진흥원 (KISA)에서 개발한 블록 암호화 알고리즘 |
| AES | 미국 표준 기술 연구에서 발표한 개인키 암호화 알고리즘 SPN 방식을 사용한다. |
| ARIA | SEED 이후로 나온 국가 정보원에서 개발한 개인키 암호화 알고리즘 |
| IDEA | 1990년 스위스에서 만들어진 PES를 개량하여 만들어진 블록 암호 알고리즘 키 길이가 128bit, 블록 길이가 64bit, 8Round Feistel 방식과 SPN의 중간 형태 구조 |
| SKIPJACK | 미국의 NSA에서 개발한 CIpper 칩에 내장된 블록 알고리즘 |
대칭키 암호 방식 - 스트림 암호화 방식
| 명칭 | 설명 |
| LFSR | LFSR은 현재 상태에서 선형 연산을 통해 다음 상태를 생성하는 레지스터 |
| RC4 | 각 단계에서 키스트림 한 바이트를 생성한다. |
| A5 | 시프트 레지스터를 기반으로 사용 GSM 휴대폰 체계에 사용 |
비대칭키 암호 방식 - 비대칭키 알고리즘
| 구분 | 설명 | |
| 소인수 분해 기반 | RSA | 대표적인 공개키 암호 알고리즘 |
| Robin | 1979년 Robin이 개발, RSA보다 빠르다. | |
| 이산대수 기반 | Diffie-Hellman | 키관리 센터 없이 공개키 전달 가능 |
| DSA | 미국의 전자서명 표준 | |
| ELGamal | 같은 평문에서 다른 암호문의 생성이 가능 | |
| KCDSA | KISA에서 개발한 인증서 기반 부가형 전자서명 알고리즘 | |
| 타원 곡선 | ECC | 타원 곡선상의 이산대를 이용 |
해시 함수 알고리즘
MD5 SHA HAS-160
8. 테스트 관련 정리
1. 프로그램 실행 여부
- 정적 테스트 : 소프트웨어의 실행 없이 구조를 분석하여 논리적으로 검증하는 테스트 ( 실행X )
- 동적 테스트 : 소프트웨어를 실행하여 실제 발생하는 오류를 발견하여 해결하는 분석 기법 ( 실행O )
2. 테스트 기법
- 화이트박스 테스트
화이트 박스 테스트의 종류
| 기법 | 설명 |
| 기초 경로 검사(Base Path Testing) | 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해줌 → 대표적인 화이트박스 테스트 기법 |
| 제어 구조 검사(Control Structure Testing) |
|
화이트 박스 테스트의 검증 기준
| 기법 | 설명 |
| 문장 검증 기준 (Statement Coverage) |
프로그램의 모든 문장을 한 번 수행하여 검증 |
| 분기 검증 기준 (Branch Coverage ) |
모든 조건문이 한 번 이상 수행되도록 |
| 조건 검증 기준 (Condition Coverage) |
모든 조건문의 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 |
| 분기/조건 검증 기준 (Branch/Condition Coverage) |
모든 조건문과 각 조건문에 포함된 개별 조건식의 경우가 True인 경우와 Fasle인 경우가 한번 이상 수행되도록 |
- 블랙박스 테스트 종류
| 기법 | 설명 |
| 동등 분할 기법 (Equivalence Partitioning Testing) |
입력 자료에 초점을 맞춰 테스트 케이스를 만들어 검사하는 방법 |
| 경계값 분석 (Boundary Value Analysis) |
입력값의 중간값보다 경계값에서 오류가 발생할 확률이 높다는 점을 이용해 입력 조건의 경계값을 테스트 케이스로 선정한다. 예) 80~ 90의 입력 조건이 있을때, 79,80,81,89,90,91을 테스트 값으로 선정한다. |
| 원인-효과 그래프 검사 (Cause-Effect Graphing Testing) |
입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법 |
| 오류 예측 검사 (Error Guessing) |
과거의 경험이나 테스터의 감각으로 테스트하는 기법 |
| 비교 검사 (Comparison Testing |
여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법이다. |
3. 테스트에 대한 시각
- 검증 - Verification ( 개발자 시각 ) : 소프트웨어의 개발 과정을 테스트
- 확인 - Validation ( 사용자의 시각 ) : 완성된 소프트웨어의 결과를 테스트
4. 테스트에 목적
| 목적 | 설명 |
| 회복 (Recovery) |
시스템에 고의로 실패를 유도하고 시스템이 정상적으로 복귀하는지 테스트 |
| 안전 (Security) |
불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스코드 내의 보안적인 결함을 미리 점검하는 테스트 |
| 강도 (Stress) |
시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정상적으로 작동하는지를 검증하는 테스트 |
| 성능 (Performance) |
시스템의 응답하는 시간, 처리량, 반응속도 등을 테스트 |
| 구조 (Structure) |
시스템의 내부 논리 경로, 소스코드의 복잡도를 평가하는 테스트 |
| 회귀 (Regression) |
변경 또는 수정된 코드에 대하여 새로운 결함 발견 여부를 평가하는 테스트 |
| 병행 (Parallel) |
변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트 |
| A/B 테스트 | 기존 서비스 와 새로 적용하고 싶은 서비스 를 통계적인 방법으로 비교하여 새로운 A B 서비스가 기존 서비스에 비해 정말 효과가 있는지 알아보는 테스트 |
| 스모크 테스트 (Smoke) |
본격적인 테스트 수행에 앞서 테스트 환경의 테스트가 가능한지 여부를 판단하기 위 해 간단하게 테스트 |
5. 테스트에 종류
- 명세 기반 테스트 : 주어진 명세를 빠짐없이 테스트 케이스로 구현하고 있는지 확인하는 테스트
- 구조 기반 테스트 : 소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
- 경험 기반 테스트 : 경험이 많은 테스터의 직관과 기술 능력을 기반으로 수행하는 테스트
