HowToFish

 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)
• 실행하는 동안 항상 만족해야하는 조건

• Structural Diagram
• Class
• 시스템의 클래스를 정적으로 표현
• 객체의 집합이며 속성과 동작으로 구성
• Object
• 실행되는 객체의 관계를 표현
• Component
• 컴포넌트 코드의 물리적 구조 표현
• Deployment
• H/W와 S/W간 물리적 구조 표현
• Package(UML 2.0에서 추가)
• 시스템 계층적인 구조를 표현
• Composite Structure(UML 2.0에서 추가)
• 전체 클래스 안에 각 컴포넌트 클래스 표현
• 클래스 내부 구조 파악에 용이함
• Behavioral Diagram
• Usecase
• 사용자 관점의 시스템 기능 파악
• Activity
• 엑티비티의 순서 흐름을 표시
• State Machine(UML 2.0에서 변경)
• 클래스 객체가 가질 수 있는 모든 상태 표현
• Interaction Diagram
• Sequence
• 시간의 흐름에 따른 객체간 메시지 교환 표현
• Communication(UML 2.0에서 변경)
• Sequence 다이어그램과 같은 내용을 나타내지만, 네트워크 모양으로 표현
• Interaction Overview(UML 2.0에서 추가)
• Activity Diagram과 Sequence Diagram의 혼합
• 상호작용에 대한 개략적 표현
• Timing(UML 2.0에서 추가)
• 시간적 제약을 표현. 임베디드 분야의 특징 반영