미친듯이 즐겨보자..

• 특징리스트는 모두 소프트웨어가 무엇을 해야 하는지 이해하는 것에 대한 것입니다.
  
• 유스케이스 다이어그램은 불필요한 세부 항목들 속으로 빠져들지 않고, 소프트퉤어가 어떻게 사용될 것인지에 대해 생각할 수 있도록 합니다.
• 유스케이스는 사용법을 반영하고, 특징은 기능을 반영합니다.
• 시스템의 특징은 시스템의 기능을 나타냅니다. 비록 기능이 항상 어떤 특정 유스케이스의 눈에 드러난 일부는 아니지만, 시스템은 유스케이스가 실제로 작동하기 위해서는 이러한 것들을 해야만 합니다.
• 유스케이스는 어떻게 사람이나 사물(액터)이 시스템과 상호작용하는지에 대한 요구사항이고, 특징은 시스템이 작업해야 할 것들에 대한 요구 사항입니다.
• 디자인 결정은 좋은 객체지향 원리뿐만 아니라 여러분의 시스템이 어떻게 사용될 것인가에 근거하고 있어야함 합니다.
• 고객에게 그들이 원하는 기능을 얻도록 하는 것과 코드가 유연하고 잘 설계되도록 유지하는 것 사이의 균형을 잡는 것이 여러분의 일입니다.
• 때로는 특정 문제의 가장 좋은 코드가 이미 작성되어 있습니다. 만약 누군가가 이미 동작하고 있는 해결책을 가지고 있다면, 여러분 스스로 코드를 작성하는 데 시간을 지체하지 마십시오.

예)

1. 특징 리스트 작성
   주어진 요구사항을 보고 특징 리스트를 작성한다.
2. 유스케이스 다이어 그램
   특징 리스트를 가지고 유스케이스 다이어그램을 작성한다.
3. 문제점 분해하기
   유스케이스 다이어 그램의 각 항목들을 개별 기능별로 크게 분할을 한다.
4. 문제점 이해하기
   해당 기능에 대한 이해가 부족하면 문제 점을 이해하기 위한 분석을 한다.
5. 요구사항 (요구 사항, 2장, 3장 요구 사항 참조)
   큰 문제를 작게 기능별로 나누어 기능 리스트를 작성한다.
   각 기능별로 유스케이스 작성 및 시나리오를 작성한다.
6. 도메인 분석
   본문 분석 및 도메인 분석을 한다.
7. 사전 설계
   본문 분석을 한 내용을 가지고 클래스 다이어그램 및 클래스 간의 관계를 정의 한다.
8. 구현
   객체지향 원리를 사용하여 좋은 디자인으로 코드를 작성한다.
9. 반복
   2번에서 나온 유스케이스 다이어 그램의 모든 기능을 완료 할 때까지 3 ~ 8번 항목을 반복하고 테스트 한다.

여러분은 반복 작업을 통해 위대한 소프트웨어를 작성합니다. 큰 그림을 그리고, 그 다음 애플리에키션이 완성될 때까지 조각조각들에 대해 반복적으로 작업하세요.

반복 심화 작업: 두 가지 기본적인 선택
반복 작업의 두 가지 접근 방식은 잘 작성된 요구 사항에 의해 유도됩니다.

1. 특징 주도 개발(Feature driven development)
애플리케이션의 특정한 특징을 선택하고, 완성될 때까지 그 특징을 계획, 분석, 개발하는 것입니다.
애플리케이션의 특정한 특징들에 집중하는 것을 선택할 수있습니다. 이 접근 방법은 고객이 원하는 기능의 한 조각을 선택하고, 그것이 완성될 때까지 작업하는 것입니다.

한 번에 하나의 특징을 작업하고 그리고 나서 반복하여, 애플리케이션의 기능을 완성할 때까지 한 번에 하니씩 특징들을 구현합니다.

 2. 유스케이스 주도 개발(Use case driven development)
유스케이스의 시나리오를 선택하여 시나리오가 완성될 때까지 코드를 작성하는 것입니다.
애플리케이션의 특정한 흐름에 집중하는 것을 선택할 수 있습니다. 이 접근 방법은 애플리케이션에서 하나의 완전한 경로를, 명확한 시작에서 끝까지 선택하여 코드로 구현하는 것입니다.

유스케이스 내에서 하나의 시나리오를 완성하는 작업을 합니다. 그 다음 또 다른 시나리오를 선택하여 작업하며, 유스케이스의 모든 시나리오가 완성될 때까지 반복합니다. 모든 유스케이스가 작동할 때까지 반복합니다.

특징 주도 개발과 유스케이스 주도 개발이의 차이점 

* 실제 대부분의 좋은 소프트웨어 분석 설계는 다양한 접근 방식을 혼용하여 사용합니다. 여러분은 유스케이스로 시작할지도 모릅니다. 그 다음 작업을 시작하기 위해 유스케이스에서 작은 특징 하나를 선택할 수 있습니다. 마지막으로 이 특징을 어떻게 구현할지 이해하기 위해 테스트를 사용할 수도 있습니다.(테스트 주도개발)

특징 주도 개발 방법 사용 예

1. 특징 리스트 중 하나를 선택하여 그것을 끝낼 때까지 작업할 수 있습니다.
2. 하나의 특징을 결정했다면, 본문 분석을 그 특징에 대해서 다시 하여 특징에 대한 새로운 특징 리스트를 작성한다.
3. 특징들에 대한 자세한 클래스 다이어그램을 작성한다.
4. 테스트 시나리오를 작성한다.
1. 테스트는 간단하고 한 번에 기능의 작은 부분 하나만을 테스트 해야 합니다.
2. 테스트 주도 개발은 클래스의 기능을 올바르게 만드는데 집중합니다.
5. 클래스들에 대해 다시 분석하기(공통점 분석 정제하기)
   좋은 소프트웨어는 반복 작업을 통해 완성됩니다. 애플리케이션의 매우 작은 부분을 작업하면서, 분석과 설계를 하고, 다시 이를 되풀이 하세요. 반복해서 작업할 때마다, 설계 결정들을 재평가하고, 여러분의 설계에 도움이 되면 무언가 변경하는 것을 두려우워하지 마세요.
6. 클래스 작성

좋은 테스트를 만드는 방법

1. 각 테스트 케이스는 아이디와 이름을 가지고 있어야 합니다.
   테스트 케이스의 이름에 무엇이 테스트되는지 나타나야 합니다.
2. 각 테스트 케이스는 그것이 테스트하는 특정한 것 하나를 테스트 해야 합니다.
   각 테스트 케이스는 한 번에 한 가지 기능만을 테스트해야 합니다.
3. 각 테스트 케이스는 여러분이 제공하는 입력 값을 가지고 있어야 합니다.
4. 각 테스트 케이스는 예상되는 출력 값을 가지고 있어야 합니다.
5. 대부분의 테스트 케이스는 초기 상태를 가지고 있습니다.

OOA&D 도구 상자

요구사항

분석과 설계

• 잘 디자인된 소프트웨어는 변경과 확장이 쉽다.
• 기본적인 캡슐화와 상속 같은 객체지향 원리를 사용하여 소프트웨어를 좀 더 유연하게 만드세요.
• 디자인이 유연하지 않으면, 변경하세요. 변경해야 하는 것이 여러분의 디자인이더라도, 결코 나쁜 디자인을 고수하지는 마세요.
• 여러분의 각 클래스의 응집도를 높게 하세요. 여러분의 클래스 각각은 하나의 일을 정말 잘하는 것에 중점을 두어야 합니다.
• 소프트웨어 디자인을 진행하면서, 항상 높은 응집도를 위해 노력하세요.

큰 문제들 해결하기 정리

1. 고객의 말에 귀 기울여, 여러분이 만들어 주길 바라는 것이 무엇인지 알아낸다.
2. 특징 리스트를 고객이 이해하는 용어를 사용하여 작성한다.
3. 작성한 특징 리스트가 고객이 실제로 원하는 것인지 확인한다.
4. 유스케이스 다이어그램을 사용하여 시스템의 청사진을 만든다.
5. 큰 시스템을 여러 개의 작은 섹션으로 나눈다.
6. 디자인 패턴을 시스템의 작은 섹션에 적용한다.

객체지향 원리

• 변하는 것을 캡슐화 하라.
• 구현에 의존하기 보다는 인터페이스에 의존하도록 코딩하라.
• 각 클래스는 변경 요인이 오직 하나이어야 한다.
• 클래스는 행동과 기능에 관한 것입니다.
• 클래스는 확장에는 열려있고, 수정에는 닫현 있어야 한다.(OCP)
• 공통되는 부분을 추출하여 추상화하고 한 곳에 두어 중복 코드를 피하라(DRY원리).
• 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나의 책임을 수행하는 데 집중되어 있어야 한다.(SRP)
• 서브 클래스들은 부모 클래스들이 사용되는 곳에 대체될 수 있어야 한다.(LSP)

개발 접근 방식

• 유스케이스 주도 개발은 시스템에서 하나의 유스케이스를 선정하여, 유스케이스의 모든 시나리오를 포함해서 그 전체를 구현하고 코드 작업을 완성하는데 중점을 두고 있습니다. 그 다음에 애플리케이션의 다른 것으로 넘어갑니다.
• 특징 주도 개발은 하나의 특징에 집중하여 그 특징의 모든 행위 모두를 코드 작업합니다. 그 다음에 애플리케이션의 다른 것으로 넘어갑니다.
• 테스트 주도 개발은 한 가지 기능의 테스트 시나리오를 작성하고, 그 다음에 그 기능에 대한 코드를 작성합니다. 그리고 모든 테스트를 통과할 때까지 소프트웨어를 작성합니다.
• 좋은 소프트웨어 개발 방법이란 대체로 개발 주기의 여러 단계에서 이러한 개발 모델 모두를 혼용합니다.

디자인 원리 정리

디자인 원리는 코드를 좀 더 유지보수하기 쉽고, 유연하고 확장히기 쉽게 만들기 위해, 코드의 작성이나 디자인에 적용되는 기본 도구 또는 기법입니다.

지금까지 배운 디자인 원리(객체지향 원리)

• 변하는 것을 캡슐화하라.
• 구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라.
• 각 클래스는 변경 요인이 오직 하나이어야 한다.
• 클래스는 행동과 기능에 관한 것이다.

원리1. 개방 - 폐쇄의 원리(Open - Closed Principle, OCP)

상속만이 유일한 방법은 아닙니다. 구성(Composition)을 사용 할때도 좋은 방법이 있습니다. 클래스에 private 메소드가 여러개 있고, 그 private 메소드를 여러 방법으로 호출하는 public 메소드를 추가 할 수도 있습니다.

원리2. 반복 금지의 원리(Don't Repeat Yourself, DRY)

어디서부터 어떻게 무엇을 먼저 시작해야 하나요?
아키텍처는 디자인의 구조이고, 프로그램의 가장 중요한 부분들과 그들 사이의 관계를 명확히 보여줍니다.

* 아키텍처
아키텍처는 시스템의 분할, 나뉜 부분들 사이의 연결과 상호 작용 메커니즘, 그리고 시스템의 디자인에 사용된 원리와 결정 사항들을 담고있는 시스테므이 구조입니다.

1. 첫 번째 단계는 항상 프로그램이 고객이 원하는 일을 하게 하는 것입니다.(기능부터 시작합시다.)
   어떤 것이 아키텍처적인 의미에서 중요한지 알아내려고 할 때, 다음의 세가지 질문을 할 수있습니다.
   
1. 시스템의 본질이 되는 부분인가?
   정말 그 특징이 시스템의 핵심인가? 그 특징이 없는 시스템을 생각할 수 있는가? 아니라면 아마도 시스템의 본질이 되는 특징을 찾은 것입니다.
   

2. 이것은 도대체 무슨 의미죠? 어떤 일인지 확실치 않을 때, 그 일은 시간이 오래 걸리거나 시스템의 나머지 부분에 문제를 야기시킬수 있습니다. 그러한 특징들은 일찌감치 알아봐야 합니다.

3. 도대체 어떻게 해야 하죠?
   구현하기 정말 어려워 보이거나 여러분에게 완전히 새로운 프로그래밍 작업인 경우 입니다. 특정 문제를 어떻게 해결할지 잘 모르겠으면, 처음에 그 특징에 시간을 들여 문제의 발생을 미리 막아야 합니다.

2. 1번의 질문에 대한 핵심 특징 리스트를 작성 합니다. 프로젝트 성공의 위험 요소를 줄이는 방향으로 진행된다면, 어느 것을 먼저 하는지는 상관없습니다. 시나리오들이 위험 요소를 줄이는 데 도움이 됩니다. 간단한 기능을 할 수 있는 시나리오를 작성 합니다.
   
3. 몇 개의 핵심 특징이 되는 부분의 기능을 간단히 구현 합니다. 프로젝트에서 위험을 줄일려면, 한 번에 하나의 특징에 집중하세요. 위험을 줄이는 데 도움이 되지 않는 특징들에 너무 신경쓰지 마세요. 기능 구현을 하면서 필요한 클래스들과의 관계를 정리하면서 클래스들의 기본 설계를 합니다. 위험 요소를 줄이는 일에만 집중을 하세요.
   
4. 어떤 특징이 무엇을 의미하는지 확실치 않을 때, 가장 좋은 방법은 고객에게 질문하는 것입니다.
   고객에게 문의 -> 공통점 분석 -> 구현 계획
   모든 내용은 프로젝트의 위험 요소를 확인 후 해결 하는것에 집중을 합니다.

핵심 정리

• 아키텍처는 모든 다이어그램, 계획, 특징 리스트들을 잘 정돈된 애플리케이션으로 만드는 데 도움을 줍니다.
• 프로젝트에 매우 중요한 시스템의 특징들은 아키텍처적으로 중요합니다.
• 시스템의 본질인 특징, 의미가 명확하지 않은 특징, 또는 처음에 어떻게 구현해야 할지 명확하지 않은 특징에 초점을 맞추세요.
• 프로젝트의 아키텍처 설계 단계에서 하는 모든 일은 프로젝트 실패의 위험을 줄여야 합니다.
• 유스케이스의 세부 사항이 필요하지 않을 경우, 소프트웨어가 어떻게 이용될 수 있는지를 설명하는 시나리오를 작성하면 요구 사항을 빠르게 수집하는데 도움이 됩니다.
• 특징이 무엇인지 확실히 모를 때, 고객에게 묻고, 그런 후 얻ㄴ은 답을 일반화하여 특징을 잘 이해하도록 합니다.
• 공통점 분석을 사용해서 유연한 소프트웨어 솔루션을 만드세요
• 고객은 여러분 생각에 정말 멋지게 짜여진 코드에 관심이 있기보다는 그들이 워ㅓㅜㄴ하는 일을 하고, 시간에 맞게 만들어지는 소프트웨어에 관심이 있습니다.

큰 문제 해결 하기 위한 방법

• 큰 문제는 여러 개의 기능별 조각들로 나누고 각 조각들을 개별적으로 풀어감으로써 해결할 수 있습니다.
• 큰 문제를 바라보는 가장 좋은 방법은 여러 기능의 조각들로 나누어 보는 것입니다.
• 각 조각들을 풀어야 할 개별 문제로 다룰 수 있고, 크기가 작은 개별 문제에는 이미 알고 있는 도구들을 적용할 수 있습니다.

* 도메인 분석
기존 시스템과 개발 이력, 도메인 전문가들로부터 얻은 지식, 기반이론, 그리고 도메인에서 새로 등장하는 기술을 기반으로 도메인 관련 정보를 찾아내고, 모으고, 구조화하고, 나타내는 프로세스.

방법 설명

• 요구 사항과 유스케이스부터 시작하는 것도 좋습니다.
   그런데 우리가 지금까지 시스템에 대해 정말 무엇을 알죠? 시스템에 대해 좀 더 알아낼 수 있는 방법 중의 하나는 비슷한 시스템을 알아내는 것입니다. 또 다른 방법은 시스템과 상관없는 것을 알아내는 것입니다. 이렇게 하면 시스템에서 신경쓰지 않아도 되는 부분을 결정하는데 도움이 됩니다.
  
  
• 특징들을 찾아 내세요.
   특징은 시스템이 해야 할 일에 대해 추상적으로 설명한 것입니다. 고객과 대화를 통해 시스템의 특징들을 얻어냅니다. 대개의 경우, 하나의 특징을 얻고 그 특징을 만족시키기 위한 여러 개의 요구 사항들이 나옵니다. 그래서 시스템의 특징들을 알아내는 것은 요구 사항을 얻는 좋은 방법입니다.
  개발 시스템에 대해 정보가 많지 않고, 어디서부터 시작해야 할지 감이 잡히지 않는 경우, 시스템의 규모가 커다란 프로젝트인 경우에는 시스템의 특징부터 시작하는 것이 정말 도움이 됩니다.
  주의 : 특징과 요구사항의 차이점에 너무 얽매이지 마세요.
  
  
• 유스케이스 다이어 그램을 그리세요.
   가끔 시스템이 하는 일을 알아야 하지만 유스케이스 작성에 필요한 세세한 내용까지 다루고 싶지 않을 때가 있습니다. 이러한 상황에서는 유스케이스 다이어그램을 사용할 수 있습니다. 유스케이스 다이어그램은 여러분의 시스템에 대한 청사진 입니다. 항상 세부 내용은 늦출 수 있을 때까지 최대한 늦추세요.
  특징 리스트를 사용해서 유스케이스 다이어그램에 빠진 것이 없게 만드세요.
  특징 또는 요구 사항 리스트로 시스템이 해야 할 큰 일을 알아내세요.
  
  
• 도메인 분석을 하세요.
   도메인 분석을 통해 디자인을 확인할 수 있고, 고객이 사용하는 용어를 사용할 수 있습니다.
  시스템에 대해 알아 낸 모든 내용을, 우리의 고객이 실제 이해하는 방식으로 모아보고 봅시다. 이것은 도메인 분석이라고 하는 프로세스이고, 고객이 이해하는 용어로 문제를 설명하는 것입니다.
  도메인 분석을 하면 여러분이 만들 필요가 없는 시스템의 부분을 만들지 않는 데 도움이 됩니다.
  
  
• 큰 문제를 기능의 작은 조각들로 나누기.
   이제 큰 문제를 쪼개어 기능의 작은 조각들로 나눌 때입니다. 청사진과 기능 리스트를 가지고 큰 프로그램을 각각의 기능을 가진 여러 개의 작은 조각들로 나눌 수 있습니다.
  
  
• 작은 문제들의 해결에 디자인 패턴을 적용합니다.

OOA&D 도구 상자

요구사항

분석과 설계

• 잘 디자인된 소프트웨어는 변경과 확장이 쉽다.
• 기본적인 캡슐화와 상속 같은 객체지향 원리를 사용하여 소프트웨어를 좀 더 유연하게 만드세요.
• 디자인이 유연하지 않으면, 변경하세요. 변경해야 하는 것이 여러분의 디자인이더라도, 결코 나쁜 디자인을 고수하지는 마세요.
• 여러분의 각 클래스의 응집도를 높게 하세요. 여러분의 클래스 각각은 하나의 일을 정말 잘하는 것에 중점을 두어야 합니다.
• 소프트웨어 디자인을 진행하면서, 항상 높은 응집도를 위해 노력하세요.

객체지향 원리

• 변하는 것을 캡슐화하라.
• 구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라.
• 각 클래스는 변경 요인이 오직 하나이어야 한다.
• 클래스는 행동과 기능에 관한 것이다.

큰 문제들 해결하기 정리

1. 고객의 말에 귀 기울여, 여러분이 만들어 주길 바라는 것이 무엇인지 알아낸다.
2. 특징 리스트를 고객이 이해하는 용어를 사용하여 작성한다.
3. 작성한 특징 리스트가 고객이 실제로 원하는 것인지 확인한다.
4. 유스케이스 다이어그램을 사용하여 시스템의 청사진을 만든다.
5. 큰 시스템을 여러 개의 작은 섹션으로 나눈다.
6. 디자인 패턴을 시스템의 작은 섹션에 적용한다.

핵심 정리

• 큰 문제를 바라보는 가장 좋은 방법은 작은 문제들의 집합으로 보는 것입니다.
• 작은 프로젝트들에서처럼 큰 프로젝트에서도 특징과 요구 사항들을 모으는 것부터 시작합니다.
• 특징은 보통 시스템이 하는 "큰"일이지만 "요구 사항"과 같은 뜻으로도 사용될 수 있습니다.
• 공통점과 차이점은 새로운 시스템을 여러분이 이미 알고 있는 것과 비교하여 바라보는 시각을 제공합니다.
• 유스케이스는 세부 사항에 중점을 두고 있습니다. 유스케이스 다이어그램은 큰 그림에 보다 중점을 두고 잇습니다.
• 유스케이스 다이어그램이 시스템의 모든 특징들을 설명해야 합니다.
• 도메인 분석은 시스템을 고객이 이해하는 용어를 사용하여 표현하는 것입니다.
• 액터는 시스템과 상호작용하지만 시스템의 일부는 아닌 모든 것입니다.

• 잘 디자인된 소프트웨어는 변경과 확장이 쉽다.
• 기본적인 캡슐화와 상속 같은 객체지향 원리를 사용하여 소프트웨어를 좀 더 유연하게 만드세요.
• 디자인이 유연하지 않으면, 변경하세요. 변경해야 하는 것이 여러분의 디자인이더라도, 결코 나쁜 디자인을 고수하지는 마세요.
• 여러분의 각 클래스의 응집도를 높게 하세요. 여러분의 클래스 각각은 하나의 일을 정말 잘하는 것에 중점을 두어야 합니다.
• 소프트웨어 디자인을 진행하면서, 항상 높은 응집도를 위해 노력하세요.

객체지향 원리

• 변하는 것을 캡슐화하라.
• 구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라.
• 각 클래스는 변경 요인이 오직 하나이어야 한다.
• 클래스는 행동과 기능에 관한 것이다.

* 응집도
 응집도는 하나의 모듈, 클래스, 또는 객체들을 이루는 원소들 사이에 연결의 정도를 나타냅니다. 여러분이 작성한 소프트웨어의 응집도가 높을수록, 여러분의 프로그램에서 각 클래스의 역할들이 잘 정의 되어있고 잘 연결되어 있는것입니다. 각 클래스는 밀접하게 연결되어 있는 하나의 매우 특정한 집합의 일들을 수행합니다.

핵심정리

• 보통 서브 클래스를 만드는 이유는 서브 클래스의 행동이 슈퍼 클래스와 다르기 때문입니다.
• 한 번 코딩하고 두 번 이상 보세요. 문제에 봉착할 때 여러분의 디자인을 계속 살펴보세요. 처음에 내린 디자인 결정이 지금은 여러분을 괴롭힐 수 있습니다.
• 자존심은 좋은 디자인에 방해됩니다. 많은 일을 다시 해야 하는 경우가 생길지라도, 여러분 자신이 채택한 디자인 결정 사항을 검토하고 향상시키는 것을 두려우워하지 마세요.
• 변경되는 것을 캡슐화하여, 프로그램을 더 유연하고 변경이 용이하게 만듭니다.
• 객체들 사이에 변하는 속성들이 있을 때, Map 같은 콜렉션을 사용해서 속성들을 동적으로 저장하세요. 새로운 속성들이 여러분의 클래스에 추가되어도, 메소드들을 추가하거나 코드를 변경할 필요가 없습니다.
• 대부분의 좋은 디자인은 나쁜 디자인의 분석을 통해 나옵니다. 실수하는 것과 변경하는 것을 절대 두려워하지 마세요.
• 응집된 클래스는 하나의 일을 정말 잘하고 그 외의 일은 하려고 하지도 않습니다.
• 모든 클래스는 변경에 대해 오직 하나의 이유만 갖도록 해야 합니다.
• 더 응집되어 있을수록, 클래스들간에 더 느슨한 결합을 갖게 됩니다. 기본적으로 프로그램을 수정하면 이미 응집되어 있고 느슨하게 결합되어 있는 설계를 변경해야 합니다.
• 여러분의 소프트웨어를 변경할 때마다 전점 응집도가 올라가는 지 확인하세요.
• 위대한 소프트웨어는 보통 충분히 좋으면 됩니다. 고객이 만족하는지 확인하세요. 디자인이 유연하게 하세요. 두 가지 일을 다 끝냈다면 다음으로 넘어갈 때입니다. 완벽한 소프트웨어를 작성하려고 많은 시간을 보내는 것은 시간 낭비입니다.

인터페이스

이 코드 구성 요소는 여러 타입에 적용되는 행동을 정의하는 역할과 그 여러 타입을 사용하는 클래스들의 관심의 초점을 나타내는 역할의 두 가지 역할이 있습니다.
구현 보다는 인터페이스에 의존하도록 코딩하는 것이 소프트웨어를 확장이 용이하게 합니다.

캡슐화

객체의 행동 변화에 필요한 코드변경을 국한하여, 어떤 객체지향 월리보다도 유지보수에서 생기는 문제를 막는 책임을 지고 있습니다.
캡슐화는 여러분의 클래스를 불필요한 변경으로부터 보호 합니다.
변화의 가능성이 있다고 생각되는 프로그램의 기능이 있을 때, 그 기능을 자주 변하지 않을 부분과 분리해야 합니다. 즉, 변경하는 것을 캡슐화하려는 노력이 항상 필요합니다.

변경이란?

소프트웨어에서 변하지 않는 진리는 소프트웨어는 변한다는 것입니다.
여러분의 소프트웨어를 변경에 잘 견디도록 만드는 가장 쉬운 방법은 각 클래스가 변경의 이유를 하나만 갖도록 하는 것입니다. 클래스 안의 변경 요인을 줄여서 변경 가능성을 최소화하는 것입니다.

객체지향 원리

1. 변하는 것을 캡슐화하라.
2. 구현에 의존하기 보다는 인터페이스에 의존하도록 코딩하라.
3. 각 클래스는 변경 요인이 오직 하나여야 한다.

핵심 정리

• 추상 클래스는 실제 구현 클래스를 위한 저장 장소 입니다.
• 추상 클래스는 기능(behavior)을 정의하고, 그 기능은 서브 클래스가 구현합니다.
• 두 개 이상의 클래스에서 공통된 행동(기능)을 발견할 때마다, 그 행동을 하나의 클래스로 추상화하여 그 행동(기능)을 재사용하도록 하세요.
• 소프트웨어가 잘 설계되었는지 알아보는 가장 좋은 방법 중의 하나는 사용해 보고 수정해 보는 것입니다.

분석

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

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

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

핵심 정리

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

요구사항 변경

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

OOA&D 도구 상자

요구사항

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

객체 지향 원리

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

핵심 정리

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

소프트웨어가 고객이 원하는 기능을 하도록 하세요.

요구사항 수집 순서

1. 고객의 요구사항 리스트 만들기
2. 시스템이 무엇을 해야 하는지, 고객이 그것을 어떻게 사용할 지를 정확히 이해해야 한다.
   -> 시스템을 파악한 후 고객에게 여러가지 질문을 하여 원하는 것을 알아내야 한다.
3. 유스케이스를 작성한다.
4. 유스케이스를 가지고 요구사항 체크하기 (2~4번 반복)
 -> 시스템이 해야 할 일을 모두 담고 있는지 확인을 해야 함.

* 좋은 요구 사항을 얻는 가장 좋은 방법은 시스템이 무엇을 해야 하는지를 이해하는 것입니다.
* 유스케이스는 고객의 특정한 목표를 달성하기 위해 여러분의 시스템이 무엇을 하는지를 기술합니다.

* 요구사항
하나의 요구사항은 특정 상품이나 서비스가 어떤 것이어야 하는지 또는 무엇을 수행해야 하는지를 자세하게 설명하는것입니다. 주로 시스템엔지니어링이나 소프트웨어 엔지니어링 분야에서 공식적으로 자주 사용합니다.