미친듯이 즐겨보자..

Data Type
숫자, 문자열, 블리언, 객체, null, undefined

• null : 보통 객체 없음을 뜻한다.
• undefined
1. 변수를 선언하고 그 변수에 값을 대입하지 않은 경우
2. 객체의 정의되지 않은 프로퍼티에 접근할 경우
3. 함수인자를 정의 했으나 그 인자에 값이 전달되지 않은 경우

불리언 값으로 변환 규칙

1. null 값과 undefined 값은 false가 된다.
2. 숫자 0과 NaN은 false 가 된다.
3. 빈 문자열 ''은 false 가 된다.
4. 그 외의 모든 값은 true가 된다.

변수를 불리언 값으로 변환하는 가장 좋은 방법은 NOT(!) 연산을 두 번 수행사는 것이다.
예) var boolean = !!number;

불리언 연산자의 고급 사용법

불리언 연산자 && 와 || 는 true나 false를 리턴하는 대신 마지막 표현이 평가된 값을 리턴한다.
예1) var x = '2'; var y = '0'; var z = x || y;  --> z 는 true 가 아니라 '2' 이다.
예2) var x = document.createElement && document.createElement('div');
       x 는 true 나 false 가 아니라 객체이다. 위의 예제는 아래와 같다
       var x;
       if (document.createElement)
           x = document.createElement('div');

분석

• 유스케이스와 클래스 다이어그램을 분석을 하면 여러분의 시스템이 실세계에서 잘 동작하게 만들 수 있습니다.
• 분석을 잘하는 첫 번째 단계는 잠재된 문제들을 찾는 것입니다.
• 문제를 찾고 시스템 동작을 수정(유스 케이스를 변경)해야 합니다.
• 유스케이스는 하나의 특정한 사용자 목표를 가지고 있어야 합니다.
• 분석에서 새로운 목표가 발생되면 유스케이스를 새로 작성해야 합니다.
• 유스케이스에서 명사들은 대개는 시스템에서 작성하고 집중해야 할 클래스 이며 동사들은 메소드가 될 수 있습니다.
• 대부분의 경우 시스템 외부에 있는 명사들은 클래스들로 바뀌지 않습니다. 외부의 어떤 것과 연동되어야 할 때는 클래스가 될 수 있습니다.
• 클래스들과 메소드들을 찾아내기 위해 유스케이스에서 명사(와 동사)를 분석 하는 것을 본문분석이라고 합니다.
• 잘 만든 유스케이스는 시스템이 하는 일을 명확히 그리고 정확히, 이해하기 쉬운 언어로 설명 합니다.
• 유스케이스를 잘 만든 후에, 유스케이스의 본문 분석을 통해 시스템에서 필요한클래스들을 빠르고 쉽게 찾을 수 있습니다.

• 분석과 유스케이스들은 고객들, 관리자들 그리고 동료개발자들에게 여러분이 만드는 시스템이 실세계에서 어떻게 동작 할 지를 보여 줍니다.

* 위임은 여러분의 객체들을 다른 객체들의 구현 상의 변화로부터 보호합니다.

핵심 정리

• 분석을 하면 여러분이 만드는 소프트웨어가 여러분의 가상의 세계가 아니라 실세계에서 잘 동작하는지를 확인하는데 도움이 됩니다.
• 유스케이스들은 여러분과 여러분의 상사, 고객, 동료 프로그래머들이 이해하기 쉽게 만들어져야 합니다.
• 유스케이스는 형식에 크게 구애받지 않고 유스케이스의 이용자인 여러분과 상사, 동료 프로그래머들에게 가장 사용하기 쉬운 형식으로 작성해야 합니다.
• 좋은 유스케이스는 시스템이 하는 일을 정확히 설명하지만, 어떻게 그 일을 하는 지는 설명하지 않습니다.
• 각 유스케이스는 고객의 하나의 목표에만 집중해야 합니다. 여러 개의 목표를 가진다면, 여러 개의 유스케이스를 작성해야 합니다.
• 클래스 다이어그램은 시스템과 코드의 구성 요소들을 한 눈에 (마치 3000미터 상공에서 보는 듯이) 볼 수 있게 하는 쉬운 방법입니다.
• 클래스 다이어그램에서의 속성들은 보통 여러분이 만든 클래스의 멤버 변수에 매핑됩니다.
• 클래스 다이어그램에서의 오퍼레이션들은 클래스의 메소드들을 나타냅니다.
• 클래스 다이어그램은 클래스 생성자, 타입정보, 오퍼레이션의 기능 등 많은 세세한 내용을 생략합니다.
• 본문 분석을 통해 유스케이스를 코드 수준의 클래스들, 속성들, 오퍼레이션들로 쉽게 바꿀 수 있습니다.
• 유스케이스의 명사들은 클래스 후보들이고, 동사들은 클래스의 메소드 후보들입니다.

요구사항 변경

1. 고객이 요구사항을 변경 요청
2. 요구 사항에 대해 유스케이스 변경
3. 유스케이스 정리(주 경로, 대체 경로, 서브 경로 등)
4. 유스케이스를 가지고 시나리오 추출
5. 변경된 유스케이스를 가지고 요구사항을 확인(빠진 부분이 있나 체크)

OOA&D 도구 상자

요구사항

• 좋은 요구 사항은 시스템이 고객이 기대한 대로 동작하도록 합니다.
• 여러분의 요구 사항이 시스템의 유스케이스의 모든 단계들을 담고 있는지 확인하세요.
• 유스케이스를 사용해서 고객이 잊고 얘기하지 않았던 것들을 찾아내세요.
• 유스케이스는 시스템에 추가되어야 할 불완전하거나 빠진 요구 사항들을 분명하게 합니다.
• 요구 사항은 항상 끊임없이 변화합니다.(그리고 성장합니다.).

객체 지향 원리

• 변화하는 것을 캡슐화 하세요.

핵심 정리

• 요구 사항은 프로젝트를 진행하는 내내 계속 바뀝니다.
• 요구 사항이 변하면, 시스템은 그 새로운 요구 사항을 해결하기 위해서 변경되어야 합니다.
• 시스템이 새롭게 또는 다른 방식으로 동작해야 할 때, 여러분의 유스케이스를 고치는 것부터 시작하세요.
• 여러분의 유스케이스를 바꿀 때마다, 요구 사항으로 다시 돌아가서 확인해야 합니다. 좋은 유스케이스를 만드는 이유는 좋은 요구 사항을 얻기 위해서라는 것을 기억하세요.
• 시나리오는 유스케이스를 처음부터 끝까지 진행하는 하나의 경로 입니다.
• 각 시나리오가 고객을 위해 같은 목표를 가지고 있기만 하면, 하나의 유스케이스에는 여러 개의 시나리오가 있을 수 있습니다.
• 대체 경로들은 가끔만 일어나는 단계들일 수 있고, 또는 유스케이스에서 부분적으로 완전히 다른 경로를 제공할 수도 있습니다.
• 어떤 단계가 시스템의 동작 방식에서 선택적이거나 또는 시스템을 사용하는 대체 경로를 제공하면, 3.1, 4.1 그리고 5.1이나 2.1.1, 2.2.1 그리고 2.3.1처럼 번호로 매겨진 부 단계를 사용하세요.
• 거의 대부분 중복 코드는 피해야 합니다. 중복 코드는 유지보수 할 때의 골칫거리이며, 보통은 시스템의 설계에 문제가 있다는 의미 입니다.