기말4. 코딩, 리팩토링, 테스팅

1. Coding UML Diagram

• Class Diagram
  - 속성, 함수에 대해 +는 public, -는 private, #는 protected를 나타내고, :(콜론)뒤의 타입은 반환형, 밑줄은 static을 나타낸다.
  public void run() // +run()
  private int calc(int a, int b) // -calc(a:int, b:int):int
  public static void main() // +main()
  - Inheritance ( 상속관계, extends )
  Child class -----▷ Parent class
   - Association ( 연계 관계, 전역변수 타입 ), [ 1대1, 1대다, 다대다 관계 ]
  VarType class -----> Main class
  만약, 자기 자신의 클래스를 재사용하면 Prerequisite관계로 표시한다.
  - Aggregation ( 포함 관계, 생성자의 인자 타입으로 사용, 종속 X )
  Argument class -----◇ Body class
  - Composition ( 합성 관계, 객체를 생성, 종속 O )
  Object class -----◆ Body class
  - Dependence ( 의존 관계, 함수에서 사용한다 )
  Body class - - - - -> Object class
• Sequence Diagram
  - 사용되는 객체 클래스들이 가로로 배열되고, 각 객체의 Lifetime이 세로 점선으로 표시된다.
  - 각 객체의 이름은 [Name]:Object로 나타나며, 객체의 이름이 있을경우 Name에 작성한다.
   Sequence 객체의 변수명을 seq로 할경우, seq:Sequence 와 같이 표기한다.
  - Alt 박스 : 박스 내의 조건이 만족하면, 해당 박스 내의 Sequence가 실행된다. 각 조건은 점선으로 구분한다.
  - 화살표로 함수를 호출할 때, [returnVar]=[funcName] 형식으로 작성한다.
  Controller -----> DBMSgr
  d:=getDocument(callNo:String):Document
  이렇게 작성된 다이어그램은, DBMSgr.getDocument(String callNo) 함수를 실행하고, Document 객체를 반환 받은 뒤, d라는 변수에 저장한다는 의미이다.
• State Diagram
  - 각 상태는 상수, 이벤트는 함수, 조건은 If , 액션.
  state_i == event [condition] / action ==> state_i
  // insert coin [amount + coinValue < price] /add coin value to amount
  -> insert_coin()을 실행 한 후, []내의 조건이 true일경우, 화살표가 가리키는 곳으로 오면서 / 뒤의 상태가 됬다는 의미.\

---

2. 리팩토링 ( Refactoring )

• 리팩토링을 하는 이유
  1. Collapse Hierarchy : 상위 클래스와 하위 클래스가 사실상 수행하는 기능이 유사해서 병합한다.
  2. Consolidate Conditional : if-expr을 명확하게 하기 위해, id문의 조건 부분을 함수화한다.
  3. Decompose Conditional : 변수 선언에서 길게 적힌걸 함수화한다.
  4. Extract Class : 한 클래스가 너무 많은 일을 하면 분리한다.
  5. Inline Class : 한 클래스가 너무 적은 일을 하면 병합한다.
  6. Extract Method : 메소드 안의 코드가 길거나, 하는 일이 많으면 분리한다.
• 리팩토링의 위험 : 리팩토링을 한 후 새로운 오류가 발생할 수 있다.
• 리팩토링의 비용 : 새로운 테스트 케이스를 만들어서 테스팅해야한다.
• 데드라인이 가까울 때, 단순히 코드에 오류가 있어서 혹은 아무 이유 없이 리팩토링하는 것은 좋지 않다.

---

3. 테스팅 ( Testing )

• 코드 퀄리티 향상을 위해...
  - 정적 분석 : 코드의 의미를 기반으로 점검
  - 동적 분석 : 테스팅, 디버깅 등...
  - Code inspection : 구문을 기반으로 코드패턴을 점검. ( 정적분석으로 분류될 수 있다. )
• 테스팅이란, 프로그램이 원하는대로 작동하는지 확인 하는 것
• 테스팅 기법
  - Testing ( 가짜 오류가 발견되지는 않지만, 모든 오류를 찾지 못할 수 있다. )
  - Static Verification ( 모든 Input case를 준비하고 입력한다. 모든 상황에 대응되지만, 가짜 오류가 발생할 수 있다. )
  - Inspection ( 여러 사람이 모여 코드를 읽으면서 검사한다. 조직적이고 철저하지만, 비공식적이고 주관적이다. )
  - Formal proofs of correctness ( 수학적 명세로 검증한다. 제일 확실하지만, 복잡하고 비싸다. )
• Testing
  - Test case : 입력값(Input)과 그 입력값에 대해 예상되는 출력값(Expected Output)
  - Test suite : Test case를 모아둔 집합
  - Implementation Under Test (IUT) : Input를 받는 프로그램 부분
  - Test Environment (Test Harness) : IUT의 동작을 위해 준비되는 외부의 환경 ( Driver and stub )
  - Test Procedure : 위의 모든 과정을 문서적으로 정리한 것.
  예시) 입력값들의 평균값을 구하는 코드.
  IUT : float getAvg(int... values) { int sum = getSum(values); return sum / (float) values.length; }|
  Test Environment : [Driver] getAvg(2, 3, 5, 8); [Stub] int getSum(int... values) { return values의 합; }
  Test case : {2,3,5,8} -> 4.5
  Test suite : {{{2,3,5,8}, 4.5}, {{2,3,a,8}, error}, .... }
  Test data : {2,3,5,8}, {2,3,a,8}, ...
• 테스트 케이스 디자인
  - 결함 발견의 목적으로, 완전하게 코드를 검사할 수 있어야 하며, 케이스의 수는 최소화되어야 한다.
  Objective, Criteria, Effort & Time
  - 정상적인 데이터, 비 정상적인 데이터를 모두 넣어 오류 상황에 오류가 제대로 발생되는지도 테스트.
  - 한 번 오류가 발견된 곳에서, 또 오류가 발생할 상황이 높다.
• 테스팅과 디버깅의 차이
  - 테스팅 : 결함이 발생한다는 사실만 확인 가능.
  - 디버깅 : 결함이 발생하면, 그 위치를 확인할 수 있음.
• Testing의 종류
  1. 테스팅하는 범위에 따라 분류 ( Granularity Levels )
  - Unit test : 프로그램 내 한 클래스만 검사
  - Integration test : 한 클래스와, 그와 연관된 클래스에 대해 검사
  - System test : 프로그램 전체 검사
  - Acceptance test : 프로그램 전체에 대해 사용자 입장에서 검사
  - Regression test : 이전에 검사했던 케이스에 대해 다시 검사, 회귀적 검사
  2. 테스트 참가자의 성향에 따라 분류
  - Alpha test : 프로젝트 내부자 테스트
  - Beta test : 프로젝트 외부자 테스트
  Alpha test의 경우 Beta test보다 오류에 대해 관대하다.