HowToFish

• 뮤테이션 테스트(Mutation Test)
• 의도적인 변경(Mutant)를 가하여 테스트 케이스의 적합성을 판단하기 위함
• 뮤턴트(돌연변이)를 생성
• 테스트 결과의 신뢰성 확보가 목적임
• 비버깅
• 의도적인 오류코드를 삽입하고 테스트를 통해 잔존 오류를 도출하는 기법
• 의도적 오류코드 삽입
• 잔존 오류 추정 및 배포시기 결정을 위한 목적

• 커서리 테스트(Cursory Test)
• 개발자가 테스트의 주체가 되어 문서화된 테스트 케이스 없이 주요 모듈 단위로 진행하는 즉흥적인 테스트
• 새너티 테스트 이전에 실시함
• 스모그 테스트
• 빌드 초기에 테스트 대상이 테스트가 가능한 상태인지 점검하기 위해 주요한 부분을 확인하는 테스트.
• 개발자나 테스터가 수행
• 본격적인 테스트에 앞서, 대상의 안정성을 테스트 하기 위함
• 보통 문서화 된 테스트 케이스 사용
• 회귀 테스트의 부분 집합
• 전체 시스템을 대상으로 함
• 새너티 테스트(Sanity Test)
• 여러번의 빌드과정 진행된 안정빌드에서 새로운 기능이 오류가 없는지 확인
• 테스터가 수행
• 본격적인 테스트에 앞서, 대상의 합리성을 테스트 하기 위함
• 보통 문서화 되지 않고, 즉흥적인 테스트 
• 인수 테스트의 부분 집합
• 시스템의 일부를 대상으로 함

• 회귀 테스트(Regression Test)
• 테스트된 시스템에 기능을 추가/수정한 다음 Side-effect, Ripple-effect가 없는지 확인하는 반복점진적 테스트 방법

• 결함 주입 (Fault Injection)
• 시스템이 정상적으로 동작되는 동안 결함을 강제로 발생시켜 시스템의 반응(강건성: Robustness)를 확인. 
• 시스템의 신뢰성을 평가하는 방법. 

 Java GC (Garbage Collection)

• GC : 
• GC는 Heap memory에 상주하는 인스턴스중에 Reference counter = 0 인 것을 메모리에서 제거하는 행위. 
• GC가 종료될때까지 모든 서비스 스레드가 정지
• Reference counter = 0인 인스턴스가 곧바로 메모리에서 삭제되는 것은 아니며, GC가 동작하면 삭제됨.
• 동작
• 모든 인스턴스는 최초 Eden영역에 존재
• GC에 의해서 제거되지 않은, 즉 Reference counter > 0 인 인스턴스는 Young(Eden, Survivor)를 거쳐 Old(Tenured)로 이동
• Minor GC
• Eden이 Full일 경우에 발생
• Young 영역에 Counter가 0인 모든 인스턴스 제거
• Eden 영역에 Counter가 0보다 큰 인스턴스는 Survivor로 이동
• Major GC
• Young(Eden+Survivor)이 Full일 경우 발생함
• Old영역의 Counter가 0인 인스턴스 모두 제거
• Survivor영역의 Counter가 0보다 큰 인스턴스를 Old영역으로 이동
• GC와 Heap 크기의 역학관계?
• Heap의 크기가 커질지면
• 처리량 증가(Full GC가 덜 발생함)
• But, Pause time도 따라서 증가(Full GC 수행시 시간이 길어짐)

• Configuration vs Profile
• Configuration : 
• JVM(자바 가상머신)과 코어 API에 대한 명세
• 특정 장치 그룹에 맞게 최적화 시키기 위함
• 동일한 그룹의 장치에서 사용할 수 있음.

• Profile :
• Configuration을 기반으로 특정한 시장 및 장치에 대한 API를 추가 정의
• 따라서, H/W마다 각각의 Profile이 존재함
• 제조사가 Spec결정

[관련블로그]

https://blog.naver.com/free2824/60056175518

XML 작성규칙

• 모든 시작태그는 끝 태그와 쌍을 이루어야 한다.  예 <a /a>
• 태그는 겹쳐 쓸 수 없다 예) <a <b a/> b/> 
• 반드시 하나의 ROOT요소를 가져야한다. 
• 요소는 다음 규칙을 따라야 한다. 
• 이름은 문자( _포함 )로 시작할 수 있다. 
• 숫자로 시작할 수 없다. 
• 이름에 공백을 포함할 수 없다.
• "." 을 사용할 수 있다. 단 첫문자 제외
• xml, XmL 등 xml이라는 단어로 시작할 수 없다.
• 대/소 문자를 구별한다. 
• 속성(Attribute)는 반드시 "값"을 가져야하며, 따옴표("" 또는 '')로 둘러싸야 한다. 

객체지향 개발 5대 원칙 (SOLID)

• SRP(Single Responsibility Principle) : 단일 책임의 원칙

• 작성된 클래스는 하나의 기능만 갖는다.

• 적용방법 :

1. 여러 원인에 의한 변경 (Divergent change):

• Extract Class를 통해 혼재된 각 책임을 각각의 개별 클래스로 분할하여 클래스 당 하나의 책임만을 맡도록 하는 것. 비슷한 책임을 중복해서 갖고 있다면 Extract Superclass를 사용하여 부모 클래스에 위임, 남은 책임들은 각자에게 정의 한다.

2. 산탄총 수술(Shotgun surgery):

• Move Field와 Move Method를 통해 책임을 기존의 어떤 클래스로 모으거나, 그럴만한 클래스가 없다면 새로운 클래스를 만들어 해결한다. 즉 산발적으로 여러 곳에 분포된 책임들을 한 곳에 모으면서 설계를 깨끗하게 정리하여 응집도를 높인다.

• OCP(Open Close Principle) : 개방 폐쇠의 원칙

• 확장에는 열려있고, 변경 비용은 줄인다

• 적용방법 :

1. 변경될 것과 변경되지 않을 것을 엄격하게 구분

2. 이 두 모듈이 만나는 지점에 인터페이스를 정의

3. 구현에 의존하기 보다, 정의한 인터페이스에 의존하도록 코드 작성

• LSP(Liscov Substitution Principle) : 리스코브 치환 원칙

• 완벽한 상속

• 서브 타입(자식)은 언제나 기반타입(부모)으로 교체할 수 있어야 한다.

• 적용방법

• 두개의 개체가 같은 일을 한다면 하나의 클래스로 합치고, 둘을 구분할 수 있게 만든다.

• 똑같은 연산을 제공하지만 조금씩 다르게 처리한다면 공통의 인터페이스를 만들고 각각 구현한다(인터페이스 상속)

• 공통된 연산이 없다면 2개의 클래스로 만든다.

• 두 개체에 무언가를 추가해야한다면 구현 상속을 사용한다. 

• ISP(Interface Segregation Principle) : 인터페이스 분리의 원칙

• 클래스에서 사용하지 않는 인터페이스는 구현하지 않아야 한다.

• 적용방법

1. 클래스 인터페이스를 통한 분리

• 클래스의 상속을 이용하여 인터페이스를 나눈다.

2. 객체 인터페이스를 통한 분리

• 위임(Delegation)을 이용하여 인터페이스를 나눈다. 

• DIP(Dependecy Inversion Principle) : 의존성 역전의 원칙

• 하위 모듈의 변경이 상위 모듈의 변경을 발생시키지 않도록 한다.

• 적용방법

1. Layering

• 컴포넌트와 모듈 비교

• 컴포넌트 분류
• Off the Shelf Component : 
• 기성 컴포넌트
• 소프트웨어 전문 개발업체에서 제공
• 기존 프로젝트에서 사용한 소프트웨어
• 완전하게 검증된 컴포넌트
• Full Experienced Component :
• 전체적으로 경험한 컴포넌트
• 과거 유사 프로젝트에서 사용한 명세/설계/코드 등의 데이터
• 개발자가 프로그램 전체를 완전히 숙지하고 있음
• Partial Experienced Component :
• 부분적으로 경험한 컴포넌트
• 프로그래머가 프로그램의 일부만 숙지
• 수정시 위험이 큼
• New Component :
• 신규 컴포넌트
• 필요에 의해 새로 작성한 소프트웨어
• 프로그램 작성자만 숙지하고 있음.

• MDD (Model Driven Development)
• 개요 
• 플랫폼 독립적인 SW 모델로부터 플랫폼 종속적인 SW모델로 자동 변환 및 소스코드 자동 생성하여, 원하는 플랫폼에 맞는 SW를 쉽고 빠르게 개발하는 방법론
• MDD모델의 변환 방법
• PIM to PIM : 개발단계 PIM 상세화 (모델 개선)
• PIM to PSM : 기술 종속적인 정보 추가
• PSM to PSM : 실제 구현 정보 추가 (모델 개선)
• PSM ot PIM : 기존 시스템 Re-engineering

• 개발 절차
1. MDA 개발
1. 타겟 플랫폼 식별
2. 메타 모델 식별/정의(CWMs)
3. 매핑 기법 정의/구현(UML Profile)
2. MDA 기반 애플리케이션 개발
1. PIM 모델 작성
2. PSM 모델 생성
3. 애플리케이션 완성

• 4계층 메타 모델
• M0(Run-time instances)
• 모델에서 코드 생성하고 그것을 실행하는 단계
• 런타임 인스턴스 계층
• M1(User model)
• 시스템 분석/설계자의 모델링 
• case 도구활용 도메인 설계
• 사용자 모델을 도식화 하는 모델 계층 
• M2(UML)
• UML기반 설계를 가능하게 하는 모델 요소를 정의하는 메타 모델
• 인스턴스 모델 요소정의
• M3(MOF)
• M2수준 메타모델을 정의하는 메타메타 모델

• OCL (Object Constraint Language)
• 제약조건을 분명하고 표현력 높게 나타내기 위한 명세언어
• 특징
• 제약조건을 통해서 시스템의 행위를 기술
• 사용하기쉽고, 분명하고, 표현력이 높음
• 모델 구성의 적법성 여부 판단 가능
• 종류
• 선행조건 (Pre condition)
• 실행전에 만족해야하는 조건
• 후행조건 (Post Condition)
• 실행후에 만족해야하는 조건
• 불변식 (Invariant)
• 실행하는 동안 항상 만족해야하는 조건