개발노트

* 테스트 오라클 Test Oracle: 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법.

* 테스트 오라클의 특징:

- 제한된 검증

- 수학적 기법

- 자동화 가능

* 테스트 오라클의 종류:

- 참True 오라클

- 샘플링Sampling 오라클

- 추정 Heuristic 오라클

- 일관성 검사 Consistent 오라클

* 테스트 자동화 도구: 테스트 도구를 활동하여 반복적인 테스트 작업을 스크립트 형태로 구현

* 테스트 자동화 도구 유형:

- 정적 분석 도구 Static Analysis Tools

• 프로그램을 실행하지 않고 분석하는 도구

- 테스트 실행 도구 Test Execution Tools

• 스크립트 언어를 사용하여 테스트를 실행하는 도구
• - 데이터 주도 접근방식
• - 키워드 주도 접근방식

- 성능 테스트 도구 Performance Test Tools

• 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인하는 도구

- 테스트 통제 도구 Test Control Tools

• 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구

* 테스트 하네스  Test Harness

• 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구

* 테스트 하네스의 구성요소:

- 테스트 드라이버 Test Driver: 테스트 대상의 하위 모듈 호출, 파라미터 전달, 모듈 테스트 후의 결과를 도출하는 도구

- 테스트 스텁 Test Stub: 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구

- 테스트 슈트 Test Suites: 테스트 대상 컴포넌트, 모듈, 시스템에 사용되는 테스트 케이스의 집합

- 테스트 케이스 Test Case: 입력값, 실행 조건, 기대 결과 등의 집합

- 테스트 스크립트 Test Script: 자동화된 테스트 실행 절차에 대한 명세

- 목 오브젝트 Mock Object: 사용자의 행위를 조건부로 입력해 두면 그 상황에 맞는 예정된 행위를 수행하는 객체

* 테스트 리포팅:

 - 테스트 결과 정리 - 테스트 요약문서 - 품질 상태 - 테스트 결과서 - 테스트 실행 절차 및  평가

* 결함 관리

* 결함 Fault: 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것

* 결함 관리 측정 지표:

- 결함 분포: 모듈, 컴포넌트의 특정 속성에 해당하는 결함 수 측정

- 결함 추세: 테스트 진행 시간에 따른 결함 수의 추이 분석

- 결함 에이징: 특정 결함 상태로 지속되는 시간 측정

* 결함 분류:

- 시스템 결함: 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함

- 기능 결함: 애플리케이션의 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함

- GUI 결함: 사용자 화면 설계에서 발생된 결함

- 문서 결함: 기획자, 사용자, 개발자 간의 의사소통 및 기록이 원활하지 않아 발생된 결함

* 결함 관리 도구:

- Mantis

- Trac

- Redmine

- Bugzilla

* 테스트 커버리지 Test Coverage

: 테스트 범위를 측정하는 테스트 춤질 측정 기준

* 테스트 커버리지 유형:

- 기능 기반 커버리지: 실제 테스트가 수행된 기능의 수를 측정. 100% 달성을 목표

- 라인 커버리지: 소스 코드의 라인 수를 모수로 테스트 시나리오가 수행한 소스 코드의 라인 수 측정

- 코드 커버리지: 코드 자체가 얼마나 테스트되었는지를 측정

* 코드 커버리지 유형:

- 구문 커버리지

- 결정 커버리지

- 조건 커버리지

- 조건/결정 커버리지

- 변경 조건/결정 커버리지

- 다중 조건/결정 커버리지

* 애플리케이션 성능 분석

* 애플리케이션 성능: 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도

* 애플리케이션 성능 측정 지표:

- 처리량 Throughput: 일정 시간 내에 애플리케이션이 처리하는 일의 양

- 응답 시간 Response Time: 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간

- 경과 시간 Turn Around Time: 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간

- 자원 사용률 Resource Usage: 애플리켜이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률

* 성능 테스트 도구: 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검

* 성능 테스트 도구 종류:

- JMeter: HTTP, FTP 등 다양한 프로토콜 지원

- LoadUI: UI를 통해 HTTP, JDBC등 주로 웹 서비스를 대상으로 서버 모니터링을 지원

- OpenSTA: HTTP, HTTPS 지원하는 부하 테스트 및 생산품 모니터링 도구

* 시스템 모니터링 도구: 애플리케이션이 실행 되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구.

* 시스템 모니터링 도구 종류:

- Scouter: 단일 뷰 통합/ 실시간 모니터링, 튜닝에 최적화된 인프라 통합 모니터링 도구

- Zabbix : 웹기반 서버, 서비스, 애플리케이션 등의 모니터링 도구

* 복잡도 Complexity :

- 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말.

- 소프트웨어를 어느 정도의 수준까지 테스트해야 하는지 또는 개발하는 데 어느 정도의 자원이 소요되는지 예측하는 데 사용

* 시간 복잡도:

- 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화 한것

- 시간 복잡도가 낮을수록 알고리즘의 실행시간이 짧고, 높을수록 실행 시간이 길어진다.

* 점근 표기법의 종류:

- 빅오 표기법 Big-O : 알고리즘 실행시간이 최악인 경우 표기

- 세타 표기법 Big-θ : 알고리즘 실행시간이 평균일 때를 표기

- 오메가 표기법 Big-Ω : 알고리즘 실행시간이 최상을 때 표기

* 빅오 표기법으로 표현한 최악의 알고리즘 시간복잡도:

• O(1) : 입력값에 관계없이 일정하게 하나의 단계만을 거침. ex) 스택의 삽입 Push, 삭제 Pop 
• O(log n) : 문제해결에 필요한 단계가 입력값 또는 조건에 의해 감소 ex) 이진트리 Binary Tree, 이진 검색 Binary Search
• O(n) : 문제 해결에 필요한 단계가 입력값과 1:1의 관계를 가짐. ex) for문
• O(n log n): 문제 해결에 필요한 단계가 n(logn)번만큼 수행 ex) 힙정렬, 2-way 합병 정렬 (Merge Sort)
• O(n^2): 문제 해결에 필요한 단계가 입력값의 제곱만큼 수행 ex) 삽입정렬, 쉘정렬, 선택 정렬, 버블 정렬, 퀵 정렬
• O(2^n): 문제 해결에 필요한 단계가 2의 입력값 제곱만큼 수행 ex) 피보나치 수열

* 순환 복잡도 Cyclomatic Complexity:

- 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도

- 맥케이브 순환도 또는 맥케이브 복잡도 매트릭 으로도 표기.

- 순환 복잡도 = 화살표의 수 - 노드의 수 + 2

* 애플리케이션 성능 개선: 나쁜 코드를 배제하고 클린 코드로 작성하는 것.

* 클린코드: 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순 명료한 코드.

* 나쁜코드: 프로그램의 로직이 복잡하고 이해하기 어려운코드

- 스파게티 코드: 로직이 서로 복잡하게 얽혀있는 코드

- 외계인 코드: 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드

* 클린 코드 작성 원칙:

- 가독성

- 단순성

- 의존성 배제

- 중복성 최소화

- 추상화 

* 소스코드 최적화 유형:

- 클래스 분할 배치: 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고 크기를 작게 작성.

- 느슨한 결합 Loosely Coupled: 인터페이스 클래스를 이용하여 추상화된 자료구조와 메소드를 구현함으로써 클래스간의 의존성을 최소화함

* 소스 코드 품질 분석 도구:

- 정적 분석 도구: 작성한 코드를 실행하지 않고 코등 표준, 코딩 스타일, 결함등을 확인하는 코드 분석 도구

- 동적 분석 도구: 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구

* 소스 코드 품질분석 도구:

- 정적 분석 도구

• pmd
• cppcheck
• SonarQube
• checkstyle
• ccm 
• coberura

- 동적 분석 도구

• Avalanche
• Valgrind

* 애플리케이션 테스트: 개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능, 성능, 사용성, 안정성 등을 만족하는지 확인하고 소프트웨어의 잠재된 결함을 찾아내는 것.

* 애플리케이션 테스트의 기본 원리:

- 완벽한 테스트는 불가능: 완벽하게 테스팅 하려는 시도는 불필요한 시간과 자원낭비. 잠재적 결함은 줄일 수 있지만 결함이 없다고 증명할 수 없음.

- 파레토 법칙: 결함집중. 20%의 모듈에서 80%의 결함이 발견됨

- 살충제 패러독스: 동일한 테스트 케이스를 방복하면 결함이 발견되지 않기 때문에 테스트 케이스의 정기적 개선이 필요.

- 테스팅은 정황에 의존: 소프트웨어의 성격에 맞게 테스트해야함. 소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황에 따라 테스트 결과가 달라질 수 있으므로 고려하여 테스트 실시.

- 오류-부재의 궤변: 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 결함이 없어도 품질이 높다고 할 수 없다.

- 테스트와 위험은 반비례: 테스트를 많이 할수록 미래의 위험을 줄일 수 있다.

- 테스트의 점진적 확대: 테스트는 작은 부분에서 시작하여 점점 확대하며 진행.

- 테스트의 별도 팀 수행: 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함

* 소프트웨어 테스트 프로세스:

- 테스트 계획 - 테스트 분석 및 디자인 - 테스트 케이스 및 시나리오 작성 - 테스트 수행 - 테스트 결과 평가 및 리포팅

* 소프트웨어 테스트 산출물:

- 테스트 계획서:

테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행절차, 테스트 일정, 종료 조건 정의 등 테스트 수행을 계획한 문서

- 테스트 케이스:

테스트를 위한 설계 산출물로 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행조건, 기대 결과로 구성된 테스트 항목의 명세서.

- 테스트 시나리오:

테스트 수행을 위한 여러 개의 테스트 케이스의 집합으로 테스트 케이스의 동작 순서를 기술한 문서이며 테스트 절차를 명세한 문서

- 테스트 결과서:

테스트 결과를 정리한 문서로 테스트 프로세스를 리뷰, 결과 평가, 리포팅 하는 문서

* 프로그램 실행 여부에 따른 테스트

- 정적 테스트: 프로그램을 실행하지 않고 명세서, 소스코드를 대상으로 분석.

• 워크스루 Walk Through: 회의 전 검토 자료를 배포하여 짧은 시간동안 회의를 진행. 리뷰를 통해 오류를 검출, 문서화하는 기법.
• 인스펙션 Inspection: 개발자 외 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적인 기법.
• 동료 검토 Peer Review: 2~3녕이 진행하는 리뷰 형태. 이해관계자들이 설명을 들으면서 결함을 발견하는 방식.

- 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트. 개발의 모든 단계에서 사용.

* 테스트 종류에 따른 분류:

- 명세 기반 테스트: 프로그램 요구사항 명세서를 기반으로 테스트

- 구조 기반 테스트: 소프트웨어 내부 논리 흐름에 따라 테스트

- 경험 기반 테스트: 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로한 직관, 기술 능력을 기반으로 테스트

* 테스트 시각에 따른 분류:

- Verification 검증:

• 개발자의 시각에서 명세서대로 완성됐는지 테스트.
• 생산 과정을 테스트. 

- Validation 확인:

• 사용자의 시각에서 제품이 제대로 동작하는지 테스트
• 결과를 테스트.

* 테스트 기법에 따른 분류:

1. 화이트박스 테스트

: 논리적인 모든 경로를 테스트하여 테스트 케이스 설계. 원시코드(모듈)의 모든 문장을 한 번 이상 수행. 구조 기반 테스트.

- 화이트박스 테스트의 종류:

• 기초 경로 검사 Base Path Testing: 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트.
• 제어 구조 검사 Control Structure Testing: 
• - 조건 검사 : 프로그램 모듈 내에 있는 논리적 조건을 테스트
• - 루프 검사: 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트
• - 데이터 흐름 검사: 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

- 화이트박스 테스트의 검증 기준:

• 문장 검증 기준 Statement Coverage: 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계.
• 분기 검증 기준 Branch Coverage : 결정 검증 기준 Decision Coverage. 소스 코드의 모든 조건문에 대해 조건식의 결과가 true / false 의 경우가 한번 이상 수행되도록 설계
• 조건 검증 기준 Condition Coverage: 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True / False 경우가 한 번 이상 수행되도록 설계
• 분기/조건 기준 Branch/Condition Coverage: 분기 검증 기준, 조건 검증 기준 모두 충족. 조건문이 True / False 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계

2. 블랙박스 테스트

: 각 기능이 작동되는 것을 입증하는 테스트. 기능 테스트. 명세 기반 테스트.

- 블랙박스 테스트의 종류:

• 동치(동등) 분할 테스트 Equivalence Partitioning Testing: 데이터를 그룹핑하여 대표값 테스트 케이스를 도출하여 테스트. 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 나눠 테스트.
• 경계값 분석 테스트 Boundary Value Analusis: 등가 분할 후, 경계값 부분에서 오류 발생 확률이 높기에 경계값을 포함하여 테스트 케이스 설계.
• 결정 테이블 테스트 Decision Table Testing: 요구사항의 논리와 발생조건을 테이블 형태로 나열하여 조건과 행위를 모두 조합하여 테스트하는 기법
• 상태 전이 테스트 State Transition Testing: 테스트 대상,시스템이나 객체의 상태를 구분하여 이벤트에 의해 어떤 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 기법
• 유스케이스 테스트 Use Case Testing: 시스템이 실제 사용되는 유스케이스로 모델링되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행
• 분류 트리 테스트 Classification Tree Method Testing: SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 수행
• 페어와이즈 테스트 Pairwise Testing: 테스트 데이터값 간에 최소한 한 번씩을 조합하는 방식. 기능적 범위를 모든 조합에 비해 상대적으로 적은 양의 테스트 세트를 구성하기 위한 기법
• 원인-효과(결과) 그래프 검사 Cause-Effect Graphing Testing: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석, 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
• 비교 테스트 Comparison Testing: 여러 버전의 프로그램에 동일한 테스트 자료를 제공, 같은 결과가 출력되는지 테스트.
• 오류 예측 테스트 Error Guessing: 과거의 경험이나 확인자의 감각으로 테스트

* 개발 단계에 따른 애플리케이션 테스트: 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것을 V-모델 이라고 한다.

- 소프트웨어 생명 주기의 V-모델:

 요구사항 - 분석 - 설계 - 구현 - 단위테스트 - 통합 테스트 - 시스템 테스트 - 인수 테스트

* 테스트 레벨 종류:

- 단위 테스트 Unit Test: 모듈이나 컴포넌트에 초점을 맞춰 테스트. 주로 구조기반 테스트 시행.

- 통합 테스트 Integraion Test: 단위 테스트가 완료된 모듈들을 통합하여 테스트

- 시스템 테스트 System Test: 통합된 단위 시스템의 기능이 완벽하게 수행되는지 확인

- 인수 테스트 Acceptance Test: 요구사항을 만족시키는지 확인 테스트

• 알파 테스트: 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법. 통제된 환경.
• 베타 테스트: 선정된 사용자가 여러명의 사용자 앞에서 행하는 테스트. 실업무를 갖고 사용자가 직접 테스트.

* 통합 테스트 Integration Test: 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트

- 비점진적 통합 방식: 단계적 절차 없이 모든 컴포넌트 통합. ex) 빅뱅 통합 테스트

- 점진적 통합 방식: 모듈 단위로 단계적으로 통합하며 테스트. ex) 상향식 통합, 하향식 통합

* 점진적 통합 방식의 종류:

1. 하향식 통합 테스트 Top Down Integration Test: 상위 모듈에서 하위모듈 방향으로 통합 테스트.

- 주요 제어 모듈의 종속 모듈들은 스텁Stub으로 대체한다.

- 깊이 우선방식 또는 넓이 우선 방식에 따라 하위 모듈인 스텁들이 한번씩 실제 모듈로 교체된다.

- 모듈이 통합될때마다 테스트 실시.

- 새 오류가 발생하지 않음을 보증하기 위한 회귀 테스트 실시.

• 스텁Stub: 제어 모듈이 호출하는 더미 모듈. 일시적으로 필요한 조건만을 갖고 있는 시험용 모듈.

2. 상향식 통합 테스트 Bottom Up Integration Test: 하위 모듈에서 상위 모듈 방향으로 통합.

- 하위 모듈들을 클러스터로 결합.

- 상위 모듈에서 데이터 입출력을 확인하기 위한 드라이버 작성

- 통합된 클러스터 단위로 테스트

- 테스트 완료시 클러스터는 프로그램 구조의 상위로 이동하여 결합하고 드라이버는 실제 모듈로 대체

• 클러스터 Cluster: 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹
• 테스트 드라이버 Test Driver: 테스트 대상의 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행 후 결과를 도출하는 도구.

* 애플리케이션 테스트 프로세스:

- 테스트 계획 - 테스트 분석 빛 디자인 - 테스트 케이스 및 시나리오 작성 - 테스트 수행 - 테스트 결과 평가 및 리포팅 - 결함 추적 및 관리

* 결함 관리 프로세스:

- 에러 발견 - 에러 등록 - 에러 분석 - 결함 확정 - 결함 할당 - 결함 조치 - 결함 조치 검토 및 승인

* 사용자 인터페이스 (UI, User Interface): 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어.

* 사용자 인터페이스의 구분:

- CLI (Command Line Interface): 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스

- GUI (Graphical User Interface): 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스

- NUI (Natural User Interface): 사용자의 말이나 행동으로 기기를 조작하는 인터페이스

* 사용자 인터페이스의 기본원칙:

- 직관성: 누구나 쉽게 이해하고 사용할 수 있어야함

- 유효성: 사용자의 목적을 정확하고 완벽하게 전달해야함

- 학습성: 초보자, 숙련자 모두 누구나 쉽게 배우고 익힐 수 있어야함

- 유연성: 사용자의 요구사항을 최대한 숭용하고 실수를 최소화해야함

* UI 설계 도구:

- 와이어 프레임: 페이지에 대한 개략적인 레이아웃, 뼈대를 설계하는 도구

- 목업(Mockup): 실제 화면과 유사하게 만든 정적인 형태의 모형

- 스토리보드: 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서

- 프로토타입: 실제 구현된 것처럼 텍스트가 가능한 동적인 형태의 모형. 페이퍼 프로토타입 / 디지털 프로토타입

- 유스케이스: 사용자의 요구사항을 기능 단위로 표현한 것

* UI 요구사항 확인:

- 목표정의 - 활동 사항 정의 - UI 요구사항 작성

* 요구사항 요소:

- 데이터요구

- 기능 요구

- 제품/서비스의 품질

- 제약 사항

* 품질 요구사항

- ISO/IEC 9126: 소프트웨어의 품질 특성과 평가를 위한 국제 표준

- ISO/IEC 25010: ISO/IEC9126에 호환성과 보안성을 강화하여 개정한 소프트웨어 제품에 대한 국제 표준

- ISO/IEC 12119: 패키지 소프트웨어의 일반적인 제품 품질 요구사항 및 테스트를 위한 국제 표준

- ISO/IEC 14598: 소프트웨어 품질의 측정과 평가에 필요 절차를 규정한 표준

* ISO/IEC 9126의 소프트웨어 품질 특성:

- 기능성 Functionality

• 소프트웨어가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부
• 하위특성: 적절성/적합성, 정밀성/정확성, 상호 운용성, 보안성, 준수성

- 신뢰성 Reliability

• 주어진 시간동안 주어진 기능을 오류 없이 수행할 수 있는 정도를 나타냄
• 하위 특성: 성숙성, 고장 허용성, 회복성

- 사용성 Usability

• 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 정확하게 이해하고 사용하며, 향후 다시 사용하고 싶은 정도를 나타냄
• 하위 특성: 이해성, 학습성, 운용성, 친밀성

- 효율성 Efficiency

• 사용자가 요구하는 기능을 얼마나 빠르게 처리할 수 있는지 정도를 나타냄
• 하위 특성: 시간 효율성, 자원 효율성

- 유지 보수성 Maintainability

• 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도를 나타냄
• 하위 특성: 분석성, 변경성, 안정성, 시험성

- 이식성 Portability

• 소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도를 나타냄
• 하위 특성: 적용성, 설치성, 대체성, 공존성

* UI설계서: 사용자의 요구사항을 바탕으로 UI설계를 구체화하여 작성하는 문서. 기획자, 개발자, 디자이너 등과의 원활한 의사소통을 위해 작성한다.

* UI 설계서 작성 순서:

- UI 설계서 표지 작성

- UI 설계서 개정 이력 작성

- UI 요구사항 정의서 작성

- 시스템 구조 작성

- 사이트 맵 작성

- 프로세스 정의서 작성

- 화면 설계

* UI 흐름 설계

- 기능 작성

- 입력 요소 확인

- 유스케이스 설계

- 기능 및 양식 확인

* UI 상세 설계

- 요구사항 확인

- UI설계서 표지 및 개정 이력 작성

- UI 구조 설계

- 메뉴 구조 설계

- 화면 설계

* UI 시나리오 문서: 사용자 인터페이스의 기능 구조, 대표화면, 화면 간 인터랙션의 흐름, 다양한 상황에서의 예외처리 등을 정리한 문서

* UI 시나리오 문서의 요건

- 완전성 Complete: 누락되지 않도록 최대한 상세히 기술

- 일관성 Consistent: 서비스 목표, 시스템 및 사용자의 요구사항, UI 스타일 등 모두 일관성을 유지해야함

- 이해성 Understandable: 누구나 쉽게 이해할 수 있도록 설명

- 가독성 Readable: 표준화된 템플릿 등을 활용하여 문서를 쉽게 읽을 수 있도록 해야함

- 수정 용이성 Modifiable: 시나리오의 수정, 개선이 쉬워야함

- 추적 용이성 Traceable: 변경 사항은 언제, 어떤 부분, 어째서 발생했는지 추적이 쉬워야함

* HCI (Human Computer Interaction or Interface): 사람이 시스템을 편리하고 안전하게 사용할 수 있도록 연구하고 개발하는 학문. 최종 목표는 최적의 사용자 경험을 만드는 것.

* 사용자 경험 (UX, User Experience): 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적인 경험.

* UX의 특징:

- 주관성 Subjectivity

- 정황성 Contextuality

- 총체성 Holistic

* 감성공학: 제품이나 작업환경을 사용자의 감성에 맞게 설계 및 제작하는 기술

* 인터페이스 요구사항: 개발할 시스템과 외부 시스템을 연동하는데 필요한 시스템 인터페이스에 대한 요구사항 기술

* 시스템 인터페이스 요구사항 명세서의 구성요소:

- 인터페이스 이름

- 연계 대상 시스템

- 연계 범위 및 내용

- 연계방식

- 송신 데이터

- 인터페이스 주기

- 기타 고려사항

* 인터페이스 요구사항 검증 방법:

- 동료 검토 Pear Review

- 워크스루 Walk Through

- 인스펙션 Inspection

* 인터페이스 요구사항 검증의 주요항목:

- 완전성

- 일관성

- 명확성

- 기능성

- 검증 가능성

- 추적 가능성

- 변경 용이성

* 인터페이스 방법 명세화: 내/외부 시스템이 연계하여 작동할 때 인터페이스별 송/수신 방법, 송/수신 데이터, 오류 식별 및 처리 방안에 대한 내용을 문서로 정리

* 미들웨어: 운영체제와 응용 프로그램, 또는 서버와 클라이언트 사이에서 다양한 서비스를 제공하는 소프트웨어.

* 미들웨어의 종류:

- DB (Data Base)

- RPC (Remote Procedure Call)

- MOM (Message Oriented Middleware)

- TP-Monitor(Transaction Processing Monitor)

- ORB(Object Request Broker)

- WAS (Web Application Server)

* 내/외부 모듈 연계 방법:

- EAI: 기업 내 이기종 플랫폼간의 상호 연동이 가능하게 해주는 솔루션

• Point-to-Point
• Hub & Spoke
• Message Bus
• Hybrid

- EBS: 애플리케이션 간 표준 기반의 인터페이스를 제공하는 솔루션

- 웹서비스: 네트워크의 정보를 표준화된 서비스 형태로 만들어 공유하는 기술

• UDDI: WSDL를 등록하여 서비스, 서비스 제공자를 검색하고 접근하는 데 사용
• WSDL: XML로 구성되어있는 웹 서비스 관련 서식, 프로토콜 등을 표준적인 방법으로 기술, 게시하기 위한 언어
• SOAP: XML기반의 메시지를 네트워크 상에서 교환하는 프로토콜

* 인터페이스 구현: 송/수신 시스템 간의 데이터 교환 및 처리를 실현해 주는 작업 의미

*인터페이스 구현 방법:

- 데이터 통신을 이용한 인터페이스 구현

- 인터페이스 엔티티를 이용한 인터페이스 구현

* 데이터 통신을 이용한 인터페이스 구현: 애플리케이션 영역에서 데이터 포맷을 인터페이스 대상으로 전송하면 이를 수신 측에서 파싱하여 해석하는 방식이다. 주로 JSON, XML 형식의 데이터 포맷을 이용하여 인터페이스 구현

* 인터페이스 엔티티를 이용한 인터페이스 구현: 인터페이스가 필요한 시스템 사이에 별도의 인터페이스 엔티티를 두어 상호 연계하는 것. 인터페이스 테이블을 엔티티로 활용.

* 인터페이스 보안:

- 네트워크 영역

- 애플리케이션 영역

- 데이터베이스 영역

* 인터페이스 구현 검증:

- xUnit

: 자바, C++, .Net 등 다양한 언어를 지우너하는 단위테스트 프레임워크. 소프트웨어의 함수나 클래스 같은 서로 다른 구성 단위를 테스트할 수 있게 해주는 도구

- STAF

: 서비스 호출, 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크. 각 테스트 대상 분산 환경에 데몬을 사용하여 테스트 대상 프로그램을 통해 테스트를 수행, 통합하며 자동화하는 검증도구

- FitNesses

: 웹 기반 테스트 케이스 설계/실행/결과 확인 등을 지원하는 테스트 프레임워크. 사용자가 테스트 케이스 테이블을 작성하면 빠르고 편하게 자동으로 원하는 값에 대해 테스트를 할 수 있음

- Selenium

: 다양한 브라우저 지원 및 개발언어를 지원하는 웹 애플리케이션 테스트 프레임워크. 테스트 스크립트 언어를 학습할 필요 없이 기능 테스트를 만들기 위한 도구를 제공

- Watir

: 루비 기반 웹 애플리케이션 테스트 프레임워크. 모든 언어 기반의 웹 애플리케이션 테스트와 브라우저 호환성 테스트 기능

* 인터페이스 구현 감시 도구: 인터페이스 동작 상태는 APM(어플리케이션 성능 관리)를 사용하여 감시할 수 있다. 

* 인터페이스 APM:

- 스카우터 Scouter : OS 자원에 대한 모니터링 기능 제공

- 제니퍼 Jennifer : 애플리케이션의 개발부터 테스트, 오픈, 운영, 안정화 까지 전 단계에 걸쳐 성능을 모니터링하고 분석해주는 소프트웨어

* APM (Application Performance Management/Monitoring): 애플리케이션의 성능 관리를 위해 다양한 모니터링 기능을 제공하는 도구.

- 리소스 방식: Nagios, Zabbix, Cacti 등

- 엔드투엔드 방식: VisualVM, 스카우터, 제니퍼 등

* 개발환경 구축:

- 개발환경 구성시 구현될 시스템 요구사항의 명확한 이해가 필요

- 개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것

* 개발 도구 분류:

- 구현도구

- 테스트 도구

- 형상관리 도구

- 빌드 도구

* 개발환경 구성요소

- 하드웨어 개발환경:

• 클라이언트: 사용자와의 인터페이스 역할. ex) PC, 스마트폰 등
• 서버: 웹서버 / 웹 애플리케이션 서버 WAS / 데이터베이스 서버 / 파일서버

- 클라이언트 하드웨어 개발환경

• 클라이언트 프로그램
• 웹 브라우저
• 모바일 앱
• 모바일 웹

- 소프트웨어 개발환경

• 운영체제
• 미들웨어
• DBMS

- 형상관리

• Git
• SVN

* 소프트웨어 아키텍처: 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체.

* 소프트웨어 아키텍처 설계의 기본원리:

- 모듈화

- 추상화

- 단계적 분해

- 정보은닉

* 소프트웨어 개발의 설계 단계:

- 상위설계/ 아키텍처 설계/ 예비설계: 시스템의 전체적인 구조. ex) 구조, DB, 인터페이스

- 하위설계/ 모듈설계/ 상세설계: 시스템의 내부 구조 및 행위. ex) 컴포넌트, 자료구조, 알고리즘

* 공통 모듈: 여러 프로그램에서 공통으로 사용할 수 있는 모듈

* 공통 모듈 명세 기법의 종류:

- 정확성

- 명확성

- 완전성

- 일관성

- 추적성

* 재사용: 이미 개발된 기능들을 새로운 시스템이나 기능 개발에 사용하기 적합하도록 최적화 하는 작업

* 재사용 규모에 따른 분류:

- 함수와 객체

- 컴포넌트

- 애플리케이션

* 모듈: 크게 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어.

* 모듈의 특징:

- 상대적으로 독립성을 가지고있다.

- 모듈 내부에는 수많은 조합이 존재

- 단독으로 컴파일 할 수 있으며, 재사용 가능

- 모듈의 독립성은 결합도와 응집도에 의해 측정됨. 결합도는 약하게, 응집도는 높게 해야 독립성이 높아진다.

* 결합도: 모듈간 상호 의존하는 강도.

• 내용결합도 Content Coupling: 한 모듈이 다른 모듈 내부에 있는 변수나 기능을 직접 참조하거나 수정
• 공통 결합도 Common Coupling: 전역 변수를 참고하거나 갱신하는 식으로 상호작용 하는 경우
• 외부 결합도 External Coupling: 어떤 모듈에서 선언한 데이터 포맷, 통신 프로토콜, 또는 디바이스 인터페이스를 공유할 경우
• 제어 결합도 Control Coupling: 처리할 대상인 값만 전달되는 것이 아닌 제어 신호나 요소를 이동, 전달하는 결합도.
• 스탬프 결합도 Stamp Coupling: 모듈간의 인터페이스로 배열, 레코드 등의 자료구조가 전달되는 경우
• 자료 결합도 Data Coupling: 모듈간의 인터페이스로 자료 요소로만 구성될 경우의 결합도. 모듈간 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호작용이 일어나는 경우.

- 내용 결합도가 가장 결합도가 높으며 자료 결합도가 가장 결합도가 낮다.

* 응집도: 

• 우연적 응집도 Coincidental Cohesion: 모듈 내부의 구성요소가 연관이 없을 경우
• 논리적 응집도 Logical Cohesion: 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈 형성
• 시간적 응집도 Temporal Cohesion: 특정 시간에 처리되어야하는 기능을 한 모듈에서 처리할 경우
• 절차적 응집도 Procedural Cohesion: 모듈 안의 구성요소들이 순차적으로 수행할 경우
• 통신적 응집도 Communication Cohesion: 동일한 입/출력을 사용하여 서로 다른 기능을 수행하는 구성요소들이 모였을 경우
• 순차적 응집도 Sequential Cohesion: 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동이 사용할 경우
• 기능적 응집도 Functional Cohesion: 모듈 내부의 모든 기능이 단일 목적을 위해 수행되는 경우

- 우연적 응집도가 가장 낮으며, 기능적 응집도가 가장 높다.

* 단위모듈: 소프트웨어 구현에 필요한 여러 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것

* 단위모듈의 구현 과정:

- 단위 기능 명세서 작성

- 입/출력 기능 구현

- 알고리즘 구현

* IPC Inter-Process Communication

: 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합

* 단위 모듈 테스트: 모듈이 정해진 기능을 정확히 수행하는지 검증하는 것

* 테스트 케이스: 소프트웨어가 사용자의 요구사항을 정확히 준수했는지 확인을 위한 테스트 항목에 대한 명세서

- ISO/IEC/IEEE 29119-3 표준에 따른 테스트 케이스 구성요소:

• 식별자
• 테스트 항목
• 입력 명세
• 출력 명세
• 환경 설정
• 특수 절차 요구
• 의존성 기술

* 디자인 패턴: 모듈간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제.

* GOF 디자인패턴:

- 생성 패턴

- 구조 패턴

- 행위 패턴

* 생성 패턴: 클래스나 객체의 생성과 참조 과정을 정의하는 패턴

- 추상 팩토리

- 빌더

- 팩토리 메소드

- 프로토타입

- 싱글톤

* 구조 패턴: 구조가 복잡한 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴

- 어댑터 Adapter

- 브리지 Bridge

- 컴포지트 Composite

- 데코레이터 Decorator

- 퍼싸드 Facade

- 플라이웨이트 Flyweight

- 프록시 Proxy

* 행위 패턴: 클래스나 객체들이 서로 상호작용 하는 방법이나 책임 분배 방법을 정의하는 패턴

- 책임 연쇄 Chain of Responsibility

- 커맨드 Command

- 인터프리터 Interpreter

- 반복자 Iterator

- 중재자 Mediator

- 메멘토 Memento

- 옵저버 Observer

- 상태 Sate

- 전략 Strategy

- 템플릿 메소드 Template Method

- 방문자 Visitor

* 소프트웨어 개발 보안: 보안 취약점을 최소화하여 보안 위협으로부터 안전한 소프트웨어를 개발하기 위한 일련의 보안 활동

- 기밀성

- 무결성

- 가용성

보안요소 충족을 목표로 한다.

* 배치 프로그램 Batch Program: 여러 작업들을 미리 정해진 일련의 순서에 따라 일괄적으로 처리하도록 만든 프로그램

* 배치 프로그램의 필수 요소:

- 대용량 데이터

- 자동화

- 견고성

- 안정성/신뢰성

- 성능

* 배치 스케줄러: 일괄 처리 작업이 설정된 주기에 맞춰 자동으로 수행되도록 지원해주는 도구

- 스프링 배치

- Quartz

- Cron

* 통합구현:

- 송/수신 모듈과 중계 모듈 간의 연계를 구현하는 것.

- 송/수신 방식이나 시스템 아키텍처 구성, 송/수신 모듈 구현 방법 등에 따라 다르므로 사용자의 요구사항과 구축 환경에 적합한 방식 설계

* 구성요소:

- 송신 시스템과 모듈

- 수신 시스템과 모듈

- 중계 시스템

- 연계 데이터

- 네트워크

* 연계 매커니즘: 응용 소프트웨어와 연계 대상 모듈 간의 데이터 연계시 요구사항을 고려한 연계방법과 주기를 설계하기 위한 매커니즘.

* 연계 매커니즘 수행 절차:

- 연계 데이터 생성 및 추출

- 코드 매핑 및 데이터 변환

- 인터페이스 테이블 또는 파일 생성

- 연계 서버 또는 송신 어댑터

-> 실패시 로그 기록

* 로그 기록: 송/수신 시스템에서 수행되는 모든 과정에 관한 결과 및 오류에 대한 정보를 로그 테이블이나 파일에 기록하는 과정

* 연계 방식:

- 직접연계

• DB 링크(DB Link)
• DB 연결(DB Connection)
• API/Open API
• JDBC
• 하이퍼 링크

- 간접연계

• 연계 솔루션(EAI)
• Web Service/ESB
• 소켓(Socket)

* 연계 모듈 구현 환경 구성 및 개발:

- EAI(Enterprise Application Integration)방식은 기업에서 운영되는 이기종간의 정보전달, 연계, 통합을 갖능하게 해주는 솔루션. 각 비즈니스간 통합 및 연계성을 증대시켜 시스템간의 확장성 향상.

- ESB(Enterprise Service Bus)방식은 서로 다른 플랫폼 및 애플리케이션들을 하나의 시스템으로 관리 운영할 수 있도록 서비스 중심의 통합을 지향하는 아키텍처 또는 기술. ESB는 버스를 중심으로 각각 프로토콜이 호환 가능하도록 애플리케이션간의 통합을 느슨한 결합 방식으로 지원하는 방식.

* EAI/ESB 방식 연계 모듈 환경 및 구축 절차:

- 연계 DB 또는 계정 생성

- 연계를 위한 테이블 생성

- 연계 응용 프로그램 구현

* 웹서비스 방식: 네트워크에 분산된 정보를 서비스 형태로 개방하여 표준화된 방식으로 공유하는 기술로써 서비스 지향 하키텍처 개념을 실현하는 대표적인 기술.

* 웹서비스 방식의 유형:

- SOAP 방식

- UDDI 방식

- WSDL 방식

SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 사용하여 XML 기반의 메시지를 네트워크 상태에서 교환하는 프로토콜.

UDDI(Universal Description ,Discovery and Integration)는 웹 서비스를 등록하고 검색하기 위한 저장소로 웹 서비스를 공개적으로 접근, 검색이 가능하도록 공개된 레지스트리.

WSDL(Web Services Description Language)은 웹 서비스가 제공하는 서비스에 대한 정보를 기술한 파일로 XML로 기술

REST 프로토콜: HTTP메소드(POST, GET, PUT, DELETE)를 통해 자원에 대한 생성, 조회, 갱신, 삭제 명령을 적용하는 프로토콜. SOAP 대체가능 

- RESTful 웹 서비스란 REST(Representational State Transfer, 2000년, Roy Fielding) 기반의 웹 서비스를 의미하며 HTTP의 기본 기능만으로 원격 정보에 접근하는 웹 응용 기술.

* 데이터 모델:

- 현실 세계의 정보들을 컴퓨터에 표현하기 위해 단순화, 추상화 하여 체계적으로 표현한 개념적 모형.

- 데이터 모델은 데이터, 데이터의 관계, 데이터의 의미 및 일관성, 제약조건 등을 기술하기 위한 개념적 도구들의 모임.

- 데이터베이스 설계 과정에서 데이터의 구조(Schema)를 논리적으로  표현하기 위해 지능적 도구로 사용.

* 데이터 모델에 표시해야할 요소:

- 구조 Structure : 논리적으로 표현된 개체 타입들 간의 관계로서 데이터 구조 및 정적 성질 표현

- 연산 Operation: 데이터베이스에 저장된 실제 데이터를 처리하는 작업에 대한 명세로서 데이터베이스를 조작하는 기본 도구

- 제약 조건 Constraint: 데이터베이스에 저장될 수 있는 실제 데이터의 논리적인 제약조건

* 데이터 모델의 종류:

- 개념적 데이터 모델

- 논리적 데이터 모델

- 물리적 데이터 모델

* 데이터 모델링 속성:

- Entity 개체: 관리 대상이 되는 실체. 개념이나 정보 단위 같은 현실 세계의 대상체

- Attribute 속성: 관리할 정보의 구체적 항목. 데이터베이스를 구성하는 가장 작은 논리적 단위

- Relationship 관계: 개체 간의 대응 관계. 개체와 개체 사이의 논리적인 연결

* 논리 데이터 모델링: 데이터베이스 설계 프로세스의 기초 설계 단계. 개념 모델로부터 업무 영역의 업무 데이터 및 규칙을 구체적으로 표현한 모델

* 논리 데이터 모델링 특성:

- 정규화

- 포용성

- 완전성

- 독립성

* 개체-관계(E-R) 모델:

- 현실 세계의 데이터와 그 관계를 사람이 이해할 수 있는 형태로 표현하기 위한 모델.

- 모든 이해당사자와 의사소통의 보조 자료로 활용.

- 요구사항으로부터 얻어낸 정보들을 개체, 속성, 관계로 기술한 모델.

* 정규화(Normalization): 관계형 데이터베이스의 설계에서 중복을 최소화하여 데이터를 구조화하는 프로세스

* 이상현상(Abnomaly): 데이터의 중복성으로 인해 릴레이션을 조작할 때 발생하는 비합리적 현상.

- 삽입이상: 정보 저장시 해당 정보의 불필요한 세부정보를 입력해야하는 경우

- 삭제이상: 정보 삭제시 원치 않는 다른 정보가 같이 삭제되는 경우

- 갱신이상: 중복 데이터 중에서 특정 부분만 수정되어 중복된 값이 모순을 일으키는 경우

*정규화의 단계

- 1정규형(1NF): 원자값으로 구성

- 2정규형(2NF): 부분 함수 종속 제거

- 3정규형(3NF): 이행함수 종속 제거

- 보이스-코드 정규형(BCNF): 결정자 함수이면서 후보키가 아닌 것 제거

- 4정규형(4NF): 다치 종속성 제거

- 5정규형(5NF): 조인 종속성 제거

https://github.blog/2022-06-08-sunsetting-atom/

편집기 아톰이 서비스를 종료한다는 기사를 오늘 접하게 되었습니다.

제가 방금 파이썬을 공부하려고 아톰에서 헬로 월드 프린트를 시도하고 있었던 참이었어요.

원래 만남이 있으면 이별이 있다고 하는데, 이별이 좀 빠르네요~

아톰이 사라져도 지금 필요한건..

아톰으로 파이썬 실행하기!!!

아톰을 받으셨는데 아무리 ctrl+shift+b를 눌러도 실행이 안되시나요?

패키지를 받아야 하는데 script 검색을 아무리 해봐도 찾지 못하셨나요?

저는 그랬습니다..

이젠 사라질 아톰에서 파이썬을 실행시키는 방법!!

아래 링크를 클릭해주세요!

https://github.com/atom-community/atom-script

링크에 설명되어있듯이 두가지 방법이 있습니다.

1. 깃헙에서 script 패키지를 다운로드 - C:\Users\[사용자]\.atom\packages 폴더에 넣는다. 끝!

2. apm으로 받는다.

첫번째는 아주 간단하죠!

저는 두번째 방법으로 했기때문에 조금 더 자세히 설명드려볼게요.

apm으로 script 패키지 설치하는 방법:

1. 아톰 - apm 폴더의 경로를 찾습니다.

대부분 하단 경로일거라 생각합니다. [사용자]는 컴퓨터에 맞게 수정해주세요!

C:\Users\[사용자]\.atom\.apm

2. apm 폴더 안에서 cmd를 실행시킵니다.

폴더 상단의 파일탭 - 명령프롬프트 실행

3.  apm install script 입력 엔터. 

기다립니다. 인스톨이 끝나고 done이 찍히면 끝!

22년 12월 15일까지 사용하면 됩니다. ^^ ..

소프트웨어 생명주기

* 소프트웨어 생명주기: 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것.

생명주기 모형의 종류:

- 폭포수 모형

- 프로토타입 모형

- 나선형 모형

- 애자일 모형

요구사항 확인

* 요구사항: 문제의 해결 또는 목적 달성을 위해 고객의 요구사항, 혹은 표준이나 명세를 충족시키기 위해 시스템이 가져야하는 서비스 혹은 제약사항.

* 요구사항 분류:

- 기능적 요구사항: 

 특성: 기능성, 완전성, 일관성

 ex) 온라인 쇼핑을 구현했을 경우 장바구니에서 아이템 삭제가 가능해야함

- 비기능적 요구사항: 

 특성: 신뢰성, 사용성, 효율성, 유지보수성, 이식성

 ex) 시스템은 하루 24시간 가동되어야함

- 사용자 요구사항: 사용자 관점에서 본 시스템이 제공해야할 요구사항

- 시스템 요구사항: 소프트웨어 요구사항. 개발자 관점에서 본 시스템 전체가 제공해야할 요구사항

* 요구사항 개발 프로세스:

요구사항 도출 Elication - 분석 Analysis - 명세 Specification - 확인 Validation

* 요구사항 분석 기법:

- 요구사항 분류

- 개념 모델링

- 요구사항 할당

- 요구사항 협상

- 정형 분석

* 요구사항 분석: 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동

* 구조적 분석 기법: 자료의 흐름, 처리를 바탕으로 요구사항을 분석 하는 방법. 하향식 방법을 통해 시스템을 세분화 할 수 있다.

* 구조적 분석 기법 도구:

 - 자료흐름도(DFD)

 - 자료 사전(DD)

 - 소단위 명세서(Mini-Spec.)

 - 개체 관계도(ERD)

 - 상태 전이도(STD)

 - 제어 명세서

* 요구사항 분석용 CASE(자동화 도구)

: 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구

*요구사항 분석용 CASE

 - ASDT

 - SREM = RSL/REVS

 - PSL/PSA

 - TAGS

* HIPO (Hierarchy Input Process Output)

: 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것으로 시스템의 분석,설계, 문서화에 사용되는 기법

* UML (Unified Modeling Language)

: 시스템 개발 과정에서 시스템 개발자와 고객, 협업 개발자들 등 상호간의 의사소통이 원할히 이뤄지도록 표준화한 대표적인 객체지향 모델링 언어.

*  UML의 구성요소

- Things 사물

- Relationships 관계

- Diagram 다이어그램

* UML - 다이어그램 : 사물과 관계를 도형으로 표현한 것.

- Structural Diagram (구조적 다이어그램): 정적 모델링에서 주로 사용.

종류:

• Calss Diagram 클래스 다이어그램
• Object Diagram 객체 다이어그램
• Component Diagram 컴포넌트 다이어그램
• Deplyment Diagram 배치 다이어그램
• Composite Structure Diagram 복합체 구조 다이어그램
• Package Diagram 패키지 다이어그램

- Behavioral Diagram (행위 다이어그램): 동적 모델링에서 주로 사용.

종류:

• Use Case Diagram 유스케이스 다이어그램
• Sequence Diagram 시퀀스 다이어그램
• Communication Diagram 커뮤니케이션 다이어그램
• State Diagram 상태 다이어그램
• Activity Diagram 활동 다이어그램
• Interaction Overview Diagram 상호작용 개요 다이어그램
• Timing Diagram 타이밍 다이어그램

* 비용산정 모델: 소프트웨어 규모 파악을 통한 투입 자원과 소요 시간을 통해 실행 가능한 계획을 수립하기 위해 비용을 산정하는 모델

* 비용산정 모델 분류:

- 하향식 산정방법: 전문가 판단, 델파이 기법

- 상향식 산정방법: LoC, Man Month, COCOMO 모형, Putnam 모형, FP(Function Point)모형

* COCOMO 모형의 소프트웨어 개발 유형

 - Organic Mode 조직형: 5만(50KDSI) 라인 이하의 소프트웨어 개발 유형

 - Semi-Detached Mode 반분리형: 30만(300KDSI) 라인 이하의 소프트웨어 개발 유형

 - Embedded Mode 내장형: 30만(300KDSI)라인 이상의 소프트웨어 개발 유형

* Putnam(푸트남) 모형:

소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상.

Rayleigh-Norden 곡선의 노력 분포도를 기초로 함.

* 비용 산정 자동화 추정 도구

- SLIM: Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 개발된 자동화 추정 도구

- ESTIMACS: FP모형을 기초로 개발된 자동화 추정 도구

* 프로젝트 일정 계획: 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 순서와 일정 정리.

- PERT (Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술)

: 전체 작업의 상호 관계를 표시하는 네트워크

- CPM (Critical Path Method, 임계 경로 기법)

: 프로젝트 완성에 필요한 작업을 나열, 필요한 소요기간을 예측하는데 사용하는 기법.

- 간트 차트 / Time-Line 차트

: 프로젝트의 작업 시작, 종료에 대한 작업일정을 막대 도표로 표시하는 프로젝트 일정표.

현행 시스템 분석

* 현행 시스템 파악: 현행 시스템이 어떤 하위 시스템으로 구성되어있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지 파악하는 활동.

* 현행 시스템 파악 절차:

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

2. 아키텍처 및 소프트웨어 구성 파악  - 아키텍처, 소프트웨어 구성 파악

3. 하드웨어 및 네트워크 구성 파악 - 시스템 하드웨어 현황, 네트워크 구성 파악

* 개발 기술 환경 파악

- OS (Operation System) 운영체제: 컴퓨터 시스템이 제공하는 하드웨어, 소프트웨어를 효율적으로 관리하며 편리하게 사용할 수 있도록 지원하는 소프트웨어.

고려사항:

• 품질측면 : 신뢰도, 성능
• 지원측면 : 기술지원, 주변 기기, 구축비용

- DBMS (Data Base Management System) 데이터베이스 관리 시스템: 사용자가 데이터베이스를 생성, 저장, 관리 기능을 도와주는 응용 프로그램.

고려사항:

• 품질측면 : 가용성, 성능, 상호 호환성
• 지원측면 : 기술지원, 주변 기기, 구축비용

- Middleware 미들웨어: 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간 통신을 제어해주는 소프트웨어. 대표적인 미들웨어로 WAS가 있다.

고려사항:

• 성능 측면: 가용성, 성능

   * WAS (Web Application Server) 웹 애플리케이션 서버:  서버 계층에서 app이 동작할 수 있도록 환경 제공. 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버.

- Open Source 오픈소스: 누구나 제한없이 사용할 수 있도록 소스를 공개한 소프트웨어.

• 라이선스의 종류, 사용자 수, 기술의 지속 가능성

안드로이드 마테리얼 데이트 픽커 오류.

앱에서 달력으로 기간을 선택해오는 머티리얼.. 마테리얼... 머테리얼... 그 라이브러리를 적용했을때 볼 수 있는 오류다.

java.lang.IllegalArgumentException: com.google.android.material.datepicker.MaterialDatePicker requires a value for the com.cyd.selllaundryadmin:attr/colorSurface attribute to be set in your app theme. You can either set the attribute in your theme or update your theme to inherit from Theme.MaterialComponents (or a descendant).

적혀있듯이 테마를 넣어달라고 한다. 테마는 필수 ~!

다른 액티비티에는 적용을 시켜뒀는데 새로운 액티비티 생성 후, 적용을 시켜주지 않아서 오류가났다.

해결책은 간단하다. 

maifest - 해당 액티비티에 적용시킬 테마를 명시해주면 끝.

자세히 설명해보자면

1. 달력에 적용시켜줄 테마 생성

res < values < themes < themes.xml 

xml 파일에서 달력에 적용시킬 커스텀 테마를 작성해준다.

<style name="MaterialCustomRoot" parent="Theme.MaterialComponents.Light">
    <item name="windowNoTitle">true</item>
    <item name="windowActionBar">false</item>
    <item name="android:statusBarColor">@color/white</item>
    <item name="android:windowLightStatusBar">true</item>
    
    <item name="colorPrimary">@color/main_red</item>
    <item name="materialCalendarStyle">@style/Widget.MaterialComponents.MaterialCalendar</item>
    <item name="materialCalendarFullscreenTheme">@style/ThemeOverlay.MaterialComponents.MaterialCalendar.Fullscreen</item>
    <item name="materialCalendarTheme">@style/ThemeOverlay.MaterialComponents.MaterialCalendar</item>
</style>

2. manifest에 명시

데이트픽커를 적용한 액티비티에 위에서 작성한 테마를 적어준다.

<activity android:name=".Main.MyActivity"
    android:theme="@style/MaterialCustomRoot"
    />

오늘은 힘든 일요일이었으니 쉽고빠른 자동로그인을 해봅시다.

준비물은 로그인이 가능한 환경입니다...

서버와 로그인 api, 유저 데이터가 존재함을 바탕으로 SharedPreference 사용 방법만을 적었습니다.

java 언어를 기반으로 작성되었습니다.

0. SharedPreferences 간단 설명

안드로이드에서 사용 가능한 데이터베이스 관리 시스템(DBMS) 중 하나입니다. 

key - value 형태로 관리가 가능해서 간단한 데이터를 저장할 때 주로 쓰입니다. 전 자동로그인 할 때 가장 자주  사용하고 있습니다. 

더 자세한 내용을 알고싶다면 하단 링크를 참조해주세요.

https://developer.android.com/reference/android/content/SharedPreferences

핵심 명령어

https://www.tutorialspoint.com/android/android_shared_preferences.htm

설명 및 사용예제

https://www.geeksforgeeks.org/shared-preferences-in-android-with-examples/

1. SharedPreferences를 위한 클래스 생성

SharedPreferences를 손쉽게 사용하도록 도와줄 클래스를 만들어줍니다.

public class SharedPreferencesManager {
    
}

그리고 SharedPreferences를 불러오기 위해 매번 사용해야하는 코드를 편리하게 사용할 수 있도록 메소드로 만들어줍니다.

private static final String PREFERENCES_NAME = "my_preferences";

public static SharedPreferences getPreferences(Context mContext){
    return mContext.getSharedPreferences(PREFERENCES_NAME, Context.MODE_PRIVATE);
}

왜 고작 한줄의 코드를 메소드로 빼두냐면, SharedPreferences는 불러오는 이름에 따라 저장할 수 있는 값이 달라집니다. 키 - 값 형태로 관리를 한다고 했으니, 다른 이름으로 getSharedPreferences 메소드를 사용하면 또 다른 값이 저장이 되겠죠?

따라서 저는 getPreferences라는 메소드로 자동로그인을 할 데이터만 저장할 예정이라 따로 만들었습니다. 

그리고 MODE_PRIVATE는 현재 사용하는 앱에서만 접근을 허락하도록 지정해놓은 것입니다. 여기에 관련된 자세한 항목은 상단 링크를 읽어보시면 더 자세히 알 수 있습니다.

이걸로 기본 준비는 끝났습니다.

2. 저장, 불러올 데이터 메소드 생성

로그인 정보를 저장, 불러오는 메소드를 만들어줍니다.

로그인의 가장 기본적인 데이터 email, password를 예시로 적었습니다.

필요한 정보를 저장해두면 됩니다!

public static void setLoginInfo(Context context, String email, String password){
    SharedPreferences prefs = getPreferences(context);
    SharedPreferences.Editor editor = prefs.edit();
    editor.putString("email", email);
    editor.putString("password", password);

    editor.apply();
}

public static Map<String, String> getLoginInfo(Context context){
    SharedPreferences prefs = getPreferences(context);
    Map<String, String> LoginInfo = new HashMap<>();
    String email = prefs.getString("email", "");
    String password = prefs.getString("password", "");
        
    LoginInfo.put("email", email);
    LoginInfo.put("password", password);

    return LoginInfo;
}

해당 값이 null일 수 있으므로 defaultValue또한 공백문자로 처리했습니다. 이렇게 해두면 nullPointException 에러를 막을 수 있습니다. 

3. 사용과 활용

이제 SharedPreference를 어디서든 부를 수 있게 되었습니다.

따라서 사용자가 로그인 화면의 행동을 모두 끝마쳤을때.

즉, 유효한 데이터로 서버와 통신을 마치고 메인 화면으로 넘어갈 때

SharedPreferencesManager.setLoginInfo(this, email ,password);

이렇게 데이터를 저장해줍니다.

그 후, 한번 유효한 데이터로 로그인을 했던 사용자가 앱을 종료하고 다시 실행했을 때 SharedPreference에서 데이터를 가져옵시다.

Map<String, String> loginInfo = SharedPreferencesManager.getLoginInfo(this);
if (!loginInfo.isEmpty()){
    String email    = loginInfo.get("email");
    String password = loginInfo.get("password");
    }

이렇게 데이터를 가져오고 서버에 로그인 리퀘스트를 해주면 자동로그인이 완성됩니다.

만약 로그인 데이터가 잘못되었다면 로그인화면으로 넘겨야겠죠!

+ 이 외에도 아이디만 저장하기 기능도 SharedPreference를 활용할 수 있습니다. 보통 로그인 화면에서 체크박스로 확인하니, 로그인 할 때 해당 체크박스를 bool로 저장해두면 됩니다.

4. 삭제

가장 중요한부분!!!

바로 데이터 삭제입니다. 로그아웃을 했는데 다시 로그인이 되면 큰일나므로...

로그아웃, 회원탈퇴 시 꼭! 반드시!! sharedPreference를 삭제해야합니다.

삭제 코드는 다음과 같습니다.

public static void clearPreferences(Context context){
    SharedPreferences prefs = getPreferences(context);
    SharedPreferences.Editor editor = prefs.edit();
    editor.clear();
    editor.apply();
}

이제 로그아웃시 해당 메소드를 호출하면 됩니다.

SharedPreferences 전문입니다.

public class SharedPreferencesManager {

    private static final String PREFERENCES_NAME = "my_preferences";

    public static SharedPreferences getPreferences(Context mContext){
        return mContext.getSharedPreferences(PREFERENCES_NAME, Context.MODE_PRIVATE);
    }
    
    public static void clearPreferences(Context context){
        SharedPreferences prefs = getPreferences(context);
        SharedPreferences.Editor editor = prefs.edit();
        editor.clear();
        editor.apply();
    }

    public static void setLoginInfo(Context context, String email, String password){
        SharedPreferences prefs = getPreferences(context);
        SharedPreferences.Editor editor = prefs.edit();
        editor.putString("email", email);
        editor.putString("password", password);

        editor.apply();
    }

    public static Map<String, String> getLoginInfo(Context context){
        SharedPreferences prefs = getPreferences(context);
        Map<String, String> LoginInfo = new HashMap<>();
        String email = prefs.getString("email", "");
        String password = prefs.getString("password", "");
        
        LoginInfo.put("email", email);
        LoginInfo.put("password", password);

        return LoginInfo;
    }
    
}

+ apply와 commit의 차이점!

commit()은 동기, apply()는 비동기 처리 됩니다.

오늘 라이브러리 Gson을 사용하다가 마주한 에러.

com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 331

다른 곳에서 사용한 Gson parsing 코드를 그대로 복사붙여넣기했는데 특정 activity에서만 에러가 떠서 여기저기 뜯어보다가 알게됐다.

gson.fromjson(); 이 부분에서 터지는데, 결론적으로는 받아온 json의 값이 내가 준비해둔 class와 달라서. 

원인을 찾아내면 해결책은 생각보다 간단하다.

1. 서버에서 Class를 수정한다.

2. 클라이언트에서 Class를 수정한다.

내 경우에는 1번이 정답이었다. JSONObject를 갖고있는 JSONArray를 넘겨주고 있었는데, 받아온 배열 중 JSONObject가 아닌 스트링을 보내고 있어서 자꾸 에러가 터졌다.