잡다한 배똥월드

1. 정의

• 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어를 의미
• 초기에는 단순 상호작용에 국한. 최근에는 정보 전달을 위한 표현 방법으로 변경
• 분야 : 물리적 제어에 관한 분야, 상세적 표현과 전체 구성에 관한 분야, 기능에 관한 분야
• 기본 원칙 : 직관성, 유효성, 학습성, 유연성
• 유연성 : 사요아의 요구사항을 최대한 수용하고 실수를 최소화해야 함

2.사용자 인터페이스의 특징

• 사용자의 만족도에 가장 큰 영향을 미치는 중요한 요소 => 소프트웨어 중 변경이 가장 많이 발생
• 편리성, 가독성 높임 => 작업 시간 단축, 업무 이해도 상승
• 최소한의 노력으로 원하는 결과를 얻을 수 있음
• 사용자 중심의 상호 작용이 되도록 함
• 수행 결과의 오류를 줄임
• 막연한 작업 기능에 대한 구체적인 방법을 제시해 줌
• 정보 제공자와 공급자 간의 매게 역할을 수행
• 설계하기 위해서 소프트웨어 아키텍처를 반드시 숙지해야 함

3. UX(User Experience)

• 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적인 경험을 말함
• 사용자가 참여, 사용, 관찰하고, 상호 교감을 통해서 알수 있는 가치 있는 경험을 말함
• 사용자의 삶의 질을 향상시키는 하나의 방향
• UI는 사용성, 접근성, 편의성 중시 / UX는 UI를 통해 사용자가 느끼는 만족이나 감정 중시
• 특징 : 주관성(Subjectivity), 정황성(Contextuality), 총체성(Holistic)

4. 구분

상호작용의 수단 및 방식에 따라 구분

• CLI(Command Line Interfase) : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스
• GUI(Graphical User Interfase) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스
• NUI(Natural Use Interfase) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
• VUI(Voice User Interfase) : 사람의 음성으로 기기를 조작하는 인터페이스
• OUI(Organic User Interfase) : 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

5. 설계 지침

• 사용자 중심 : 사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경을 제공하며, 실사용자에 대한 이해가 바탕이 되어야 함
• 일관성 : 사용자가 쉽게 기억하고 습득할 수 있게 설계해야 함
• 단순성 : 조작 방법을 단순화시켜 인지적 부담을 감소시켜야 함
• 결과 예측 기능 : 기능만 보고 미리 결과를 예측 가능하도록 설계해야 함
• 가시성 : 메인 화면에 주요 기능을 노출시켜 최대한 조작이 쉽도록 설계해야 함
• 표준화 : 기능 구조와 디자인을 표준화하여 한 번 학습한 이후에는 쉽게 사용할 수 있도록 설계해야 함
• 접근성 : 사용자의 연령 성별, 인종 등 다양한 계층이 사용할 수 있도록 설계해야 함
• 명확성 : 사용자가 개념적으로 쉽게 인지할 수 있도록 설계해야 함
• 오류 발생 해결 : 오류가 발생하면 사용자가 쉽게 인지할 수 있도록 설계해야 함

6. 사용자 인터페이스 개발 시스템의 기능

• 사용자의 입력을 검증할 수 있어야 함
• 에러 처리와 그와 관련된 에러 메세지를 표시할 수 있어야 함
• 도움과 프롬프트(Prompt)를 제공해야 함

1. 정의

• 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
• 종류 : 비점진적 통합 방식, 점진적 통합 방식

2. 비점진적 통합 방식

• 단계적으로 통합하는 절차 없이 결합된 프로그램 전체를 테스트하는 방법
• 규모가 작은 소프트웨어에 유리
• 단시간 내에 테스트가 가능
• 오류 발견 및 장애 위치 파악 및 수정이 어려움

3. 점진적 통합 방식

• 모듈 단위로 단계적으로 통합하면서 테스트하는 방법
• 오류 수정이 용이
• 인터페이스와 연관된 오류를 완전히 테스트할 가능성이 높음
• 종류 : 하향식 통합 방식, 상향식 통합 방식, 혼합 통합 방식

4. 하향식 통합 테스트(Top Down Integration Test)

• 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
• 아래 단계로 이동하면서 통합
• 깊이 우선 통합법이나 넓이 우선 통합법 사용
• 테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있음
• 상위 모듈에서는 테스트 케이스를 사용하기 어려움
• 모듈이 통합될 때마다 테스트하며 새로운 오류가 발생하지 않았음을 보증하기 위해 회귀 테스트를 실시함
• 스텁(Stub) : 상위 모듈은 있지만 하위 모듈이 없는 경우 하위 모듈을 대체하는 것 (임시 제공의 가짜 모듈 역할)

5. 상향식 통합 테스트(Bottom Up Integration Test)

• 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법
• 클러스터(Cluste) :  종속 모듈의 그룹
• 드라이버(Driver) : 상위 모듈 없이 하위 모듈이 있는 경우 상위 모듈 대체 (하위 모듈과 상위 모듈 간의 인터페이스 역할)
• 하위 모듈들을 클러스터로 결합
• 통합된 클러스터 단위로 테스트함
• 테스트가 완료되면 클러스터는 상위로 이동하여 결합하고, 드라이버는 실제 모듈로 대체

6. 혼합식 통합 테스트

• 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식
• 샌드위치(Sandwich)식 통합 테스트 방법이라고도 함

7. 회귀 테스팅(Regression Testing)

• 이미 테스트된 프로그램의 테스팅을 반복하는 것
• 새로운 오류가 있는지 확인하는 테스트
• 시간과 비용이 많이 필요하므로 변경된 부분을 테스트할 수 있는 테스트 케이스만을 선정하여 수행
• 선정 방법 : 대표적인 테스트 케이스 선정, 파습 효과가 높은 부분이 포함된 것으로 선정, 실제 수정이 발생한 위치에서 시행하는 것으로 선정

1. 화이트박스 테스트(White Box Test)

• 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
• 설계된 절차에 초점을 둔 구조적 테스트로 프로시저 설계의 제어 구조를 사용하여 테스트 케이스를 설계하며, 테스트 과정의 초기에 적용됨
• 모듈 안의 작동을 직접 관찰함
• 원시 코드(모듈)의 모든 문장을 한 번 이상 실행함으로써 수행됨
• 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어함
• 종류 : 기초 경로 검사, 제어 구조 검사 등

2. 기초 경로 검사(Base Path Testing)

• 기초 경로(Base Path = Basis Path) : 수행 가능한 모든 경로를 의미
• 대표적인 화이트박스 테스트 기법
• 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
• 테스트 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용됨

3. 제어 구조 검사(Control Structure Testing)

• 조건 검사(Condition Testing) : 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법
• 루프 검사(Loop Testing) : 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
• 데이터 흐름 검사(Data Flow Testing) : 프로그램에서 변수의 정의와 변수의 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

4. 화이트박스 테스트의 검증 기준

• 테스트 케이스들 테스트에 얼마나 적정한지를 판단하는 기준
• 문장 검증 기준(Statement Coverage) : 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계
• 분기 검증 기준(Branch Coverage) : 결정 검증 기준(Decision Coverage)라고도 불리며, 소스 코드의 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
• 조건 검증 기준(Condition Coverage) : 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
• 분기/조건 기준(Branch/Condition Coverage) : 분기 검증과 조건 검증 기준을 모두 만족하는 설계로 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스 설계

5. 검증 기준(Coverae)의 종류

• 기능 기반 커버리지 : 실제 테스트가 수행된 기능의 수 / 전체 기능의 수
• 라인 커버리지 : 테스트 시나리오가 수생한 소스 코드의 라인 수 / 전체 소스 코드의 라인 수
• 코드 커버리지 : 소스 코드의 구문, 분기, 조건 등의 구조 코드 자체가 얼마나 테스트 되었는지를 측정하는 방법

6. 블랙박스 테스트(Black Box Test) = 기능 테스트

• 소프트웨어가 수행할 특정 기능을 알리기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트
• 사용자의 요구사항 명세를 보면서 테스트 하는 것 => 주로 구현된 기능을 테스트
• 소프트웨어 인터페이스에서 실시되는 테스트
• 부정확하거나 누락된 기능, 인터페이스의 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 행위나 성능 오류, 초기화와 종류 오류 등을 발견하기 위해 사용
• 테스트 과정의 후반부에 적용
• 종류 : 동치 분할 검사, 경계값 분석, 원인-효과 그래프 검사, 오류 예측 검사, 비교 검사 등

7. 동치 분할 검사(Equivalence Partitioning Testing, 동치 클래스 분해)

• 입력 자료에 초점을 맞춰 테스트 케이스(동치 클래스)를 만들고 검사하는 방법
• 동등 분할 기법이라고도 함
• 입력 조건에 타당한 자료와 타당하지 않는 자료의 개수를 균등하게 하여 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 기법

8. 경계값 분석(Boundary Value Analysis)

• 입력 조건의 중간값보다 경계값에서 오류가 발생할 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법

9. 원인-효과 그래프 검사(Couse-Effect Graphing Testing)

• 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법

10. 오류 예측 검사(Error Gussing)

• 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는 오류를 찾아내는 일련의 보충적 검사 기법
• 데이터 확인 검사라고도 함

11. 비교 검사(Comparison Testing)

• 여러 버전의 프로글매에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법

1. 정의

• 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미
• 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드 등으로 구성
• 문제 발생 시 새로 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적
• 한 패턴에 변형을 가하거나 특정 요구사항을 반영하면 유사한 형태의 다른 패턴으로 변화되는 특징이 있음
• 1995년 GoF(Gang Of Four)라고 불리는 에릭 감마(Erich Gamma), 리차드 헬름(Richard Helm), 랄프 존스(Ralph Johnson), 존 블리시디스(Hohn Vlissides)가 처음 구체화 및 체계화함
• 아키텍처 패턴은 가이드라인 제시용, 디자인 패턴은 세부사항 정리용

2. GoF의 디자인 패턴

• 가장 일반적인 사례에 적용 가능한 패턴들을 분류하여 정리하여 지금까지도 가장 많이 사용되는 디자인 패턴
• GoF의 디자인 패턴은 유형에 따라 생성 패턴, 구조 패턴, 행위 패턴으로 구성

3. 디자인 패턴 사용의 장/단점

• 범용적인 코딩 스타일 => 구조 파악 용이
• 객체지향 설게 및 구현의 생산성을 높이는 데 적합
• 재사용을 통해 개발 시간과 비용이 절약됨
• 초기 투자 비용이 부담될 수 있음
• 원활한 의사소통이 가능
• 설계 변경 요청에 대한 유연한 대처가 가능
• 다른 기반의 애플리케이션 개발에는 부적합 => 오직 객체지향만

4. 생성 패턴(Creational Pattern)

• 생성과 관련된 패턴으로 총 5가지임
• 객체의 생성과 참조 과정을 캡슐화 하여 프로그램에 유연성을 더해줌
• 종류 : 추상 팩토리(Abstract Factory), 빌더(Builder), 팩토리 메소드(Factory Method), 프로토타입(Prototype), 싱글톤(Singleton)
• 추상 팩토리 : 서로 연관 · 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
• 팩토리 메소드(가상 생성자, Vertual Constructor) : 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴

5. 구조 패턴(Structural Pattern)

• 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴으로 총 7가지임
• 구조가 복잡한 시스템을 개발하기 쉽게 도와줌
• 종류 : 어뎁터(Adapter), 브리지(Bridge), 컴포지트(Composite), 데코레이터(Decorator), 퍼싸드(Facade), 플라이웨이트(Flyweight), 프록시(Proxy)
• 브리지 : 구현부에서 추상층을 분리하여, 서로 독립적으로 확장할 수 있도록 구성한 패턴
• 컴포지트 : 복합 객체와 단일 객체 구분 없이 다루고자 할 때 사용
• 퍼싸드 : 복잡한 서브 클래스들을 피해 더 상위에 구상. Wrapper 객체 필요
• 프록시 : 접근이 어려운 객체와 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴

6. 행위 패턴(Behavioral Pattern)

• 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴으로 총 11가지임
• 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와줌
• 종류 : 책임 연쇄(Chain of Responsibility), 커맨드(Command), 인터프리터(Interpreter), 반복자(Iterator), 중재자(Mediator), 메멘토(Memento), 옵서버(Observer), 상태(State), 전략(Strategy), 템플릿 메소드(Template Method), 방문자(Visitor)
• 반복자 : 내부 표현 방법의 노출 없이 순차적인 접근이 가능
• 메멘토 : 특정 시점에서의 객체 내부 상태를 객체화하여 요청에 따라 해당 시점의 상태로 되돌릴 수 있는 기능을 제공하는 패턴
• 옵서버 : 객체의 사태가 변화하면 객체에 상속되어 있는 다른 객체들에게 상태를 전달하는 패턴
• 전략 : 동일 계열의 알고리즘을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴(클라이언트 영향 없이 알고리즘 변경 가능)

1. 객체지향 분석(OOA: Object Oriented Analysis)

• 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 이와 연관된 속성과 연산, 그들 간의 관계 등을 정의하여 모델링하는 작업
• 소프트웨어를 개발하기 위한 비즈니스(업무)를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석
• 모델링 구성 요소인 클래스, 객체, 속성, 연산들을 표현해서 문제를 모형화할 수 있게 함
• 객체는 클래스로부터 인스턴스화되고, 이 클래스를 식별하는 것이 객체 지향 분석의 주요 목적

2. 객체지향 분석의 방법론

• Rumbaugh(럼바우) 방법 : 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나눠 수행하는 방법 (가장 일반적인 방법)
• Booch(부치) 방법 : 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법. 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의
• Jacobson(제이콥스) 방법 : 유스케이스를 강조하여 사용하는 분석 방법
• Coad와 Yourdon 방법 : ER 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메세지 연결 정의 등의 과정으로 구성하는 기법
• Wirfs-Brock 방법 : 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

3. 럼바우(Rumbaugh)의 분석 기법

• 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법
• 객체 모델링 기법(OMT, Object-Modling Technique)이라고도 함
• 분석 활동 순서 : 객체 모델링 → 동적 모델링 → 기능 모델링 순

4. 객체 모델링(Object Modeling)

• 정보 모델링이라고도 함
• 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것

5. 동적 모델링(Dynamic Modeling)

• 상태 다이어그램(상태도)을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링

6. 기능 모델링(Functional Modeling)

• 자료 흐름도(DFD, Data Flow Diagram)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링

7. 객체지향 설계 원칙 (= SOLID 원칙)

• 시스템 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야 할 다섯 가지 원칙
• 종류 : 단일 책임 원칙, 개방-폐쇄 원칙, 리스코프 치환 원칙, 인터페이스 분리 원칙, 의존 역전 원칙

8. 단일 책임 원칙(SRP, Single Responsibility Principle)

• 객체는 단 하나의 책임만 가져야 한다는 원칙
• 응집도는 높고, 결합도는 낮게 설계하는 것을 의미

9. 개방-폐쇄 원칙(OCP, Open-Closed Principle)

• 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
• 공통 인터페이스를 하나의 인터페이스로 묶어 캡슐화하는 방법이 대표적

10. 리스코프 치환 원칙(LSP, Liskov Substitution Principle)

• 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙
• 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야함

11. 인터페이스 분리 원칙(ISP, Interface Segregation Principle)

• 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
• 인터페이스가 갖는 하나의 책임임

12. 의존 역전 원칙(DIP, Dependency Inversion Principle)

• 각 객체들 간의 의존 관계가 성립될 때, 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙
• 일반적으로 인터페이스를 활용하면 이 원칙은 준수됨