1장. 위대한 소프트웨어는 여기에서 시작된다
쉬운 3단계로 위대한 소프트웨어 만들기
- 여러분의 소프트웨어가 고객이 원하는 기능을 하도록 하세요
- 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 하세요
- 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요
2장. 그들에게 원하는 것을 주세요
요구 사항이 무엇입니까?
요구사항이란 여러분의 시스템이 올바르게 동작하기 위해서 수행하는 특정한 일
좋은 요구사항을 얻는 가장 좋은 방법은 시스템이 무엇을 해야하는지를 이해하는 것
유스케이스를 소개합니다
유스케이스는 시스템이 어떤일을 수행하기 위해 거쳐야하는 단계
유스케이스는 고객의 특정한 목표를 달성하기 위해 여러분의 시스템이 무엇을 하는지를 기술합니다.
유스케이스는 3가지 부분이 피요합니다. (1. 명확한 가치, 2.시작과 종료, 3외부 기동자)
유스케이스를 살펴보고 시스템이 해야할 일을 요구사항이 모두 담고 있는지 알아 봐야합니다.
3장. 당신을 사랑해요. 당신은 완벽해... 그런데 이건 좀 바꿨으면
소프트웨어 분석과 설계에서 변하지 않는 한 가지
변경
요구사항은 항상변합니다.
유스케이스 들이 잘 만들어져 있으면, 새로운 요구사항에 맞추어 소프트웨어를 빠르게 바꿀 수 있습니다.
여러분의 유스케이스를 바꿀때 마다 요구사항으로 다시 돌아가서 확인해야합니다.
변경은 지속적으로 일어나고, 여러분의 시스템은 여러분이 변경할 때마다 항상 개선되어야 합니다.
변하는 것을 캡슐화 하세요.
4장. 여러분의 소프트웨어를 실제 세상으로...
프로그램은 동작 환경이 있습니다
분석을 하면 여러분의 시스템이 실세계에서 잘 동작하게 만들 수 있습니다.
분석을 하는 첫번 째 단계는 잠재된 문제들을 찾는 것
분석하고 다시 변경함
위임은 여러분의 객체들을 다른 객체들의 구현 상의 변화로부터 보호합니다.
유스케이스에서 명사들에 주의를 기울이세요
클래스들와 메소드들을 찾아내기 위해서 유스케이스에서 명사와 동사를 분석하는 것을 본문 분석이라고 합니다.
유스케이스에서 사용되는 명사들이 대개는 시스템에서 작성하고 집중해야 할 클래스들입니다.
유스케이스를 잘 만든 후에 유스케이스의 본문 분석을 통해 시스템에서 필요한 클래스들을 빠르고 쉽게 찾을 수 있습니다.
5장. (part1) 변하지 않는 것은 없다
추상 클래스
추상클래스는 실제 구현 클래스를 위한 저장 장소 입니다.
추상클래스는 기능을 정의하고 그 기능은 서브클래스가 구현합니다.
두 개 이상의 클래스에서 공통된 행동(기능)을 발견할 때 마다, 그 행동을 하나의 클래스로 추상화 하여 그 행동(기능)을 재사용하도록하세요
클래스 다이어그램 분석(다시)
UML 컨닝 페이퍼
<<<이미지 안들어감>>>>
디자인 문제 경고
위대한 소프트웨어로 향하는 3단계(예전에 한 내용)
(막간) 객체 지향 대참사!
인터페이스가 무엇입니까
구현 보다는 인터페이스에 의존하도록 코딩하는 것이 소프트웨어 확장을 용이하게 합니다.
인터페이스에 의존하도록 코딩하면, 여러분의 코드는 인터페이스의 서브클래스 모두와 잘 동작합니다.
(part2) 여러분의 소프트웨어를 운동시켜서 튼튼하게 만드세요
릭 프로그램에서의 "이중 캡슐화”
변경되는 것을 캡슐화하여, 프로그램을 더 유연하고 변경이 용이하게 만듭니다.
객체들 사이에 변하는 속성들이 있을 때, Map 같은 콜랙션을 사용해서 속성들을 동적으로 저장하세요
새로운 속성들이 여러분의 클래스에 추가되어도, 메소드들을 추가하거나 코드를 변경할 필요가 없습니다.
실수하는 것을 두려워하지 마세요
대부분의 좋은 디자인은 나쁜 디자인 분석을 통해 나옵니다.
실수하는 것과 변경하는 것을 절대 두려워하지 마세요
응집된 클래스는 하나의 일을 정말 잘합니다
응집된 클래스는 하나의 일을 정말 잘하고 그 외의 일은 하려고 하지 않습니다.
디자인/응집도 생명 주기
위대한 소프트웨어는 "충분히 좋습니다"
OOA&D 도구 상자
요구사항
좋은 요구사항은
분석과 설계
잘 디자인된 소프트웨어는 변경과 확장이 쉽다.
기본적인 캡슐화와 상속같은 객체지향의 원리를 사용하여 소프트웨어를 좀 더 유연하게 만드세요
디자인이 유연하지 않으면 변경하세요. 변경해야 하는 것이 여러분의 다자인이라도, 결코 나쁜 디자인을 고수하지 마세요
여러분의 각 클래스의 응집도를 높게하세요.: 여러분의 클래스 각각은 하나의 일을 정말 잘하는 것에 중점을 두어야 합니다.
소프트웨어 디자인을 하면 항상 높은 응집도를 위해 노력하세요
객체지향 원리
변하는 것을 캡슐화하라
구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라
각 클래스는 변경요인이 오직 하나여야 한다.
클래스는 행동과 기능에 관한 것이다.
6장. "내 이름은 아트 반델리... 나는 건축가예요"
큰 문제 해결하기
- 여러분의 소프트웨어가 고객이 원하는 기능을 하도록하세요.
- 객체지향의 기본원리를 적용해서 소프트웨어를 유연하게 하세요
- 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요.
큰 문제를 어떻게 바라보는 가에 해답이 있습니다
큰 문제는 여러개의 기능별 조각들로 나누고 각 조각들을 개별적으로 풀어감으로써 해결할 수 있습니다.
변하는 것을 캡슐화하여, 프로그램을 더 유연하고 변경하기 쉽게 만든다.
구현에 맞춰 코딩하는 것 보다 인터페이스에 맞춰 코딩하면 소프트웨어의 확장이 더 쉬워진다.
좋은 요구사항을 얻는 가장 좋은 방법은 시스템이 해야할 일을 이해하는 것이다.
위대한 소프트 웨어는 변경과 확장이 쉽고 고객이 원하는 일을 합니다.
분석은 시스템이 실세계에서 잘 동작하도록 만드는 데 도움이 됩니다.
요구 사항과 유스케이스로 시작하는 것도 좋습니다
더 많은 정보가 필요해요.
고객으로 부터 시스템 특징을 얻어내고나서, 그 특징을 구현하기 위해 필요한 요구사항들을 알아내세요.
고객과의 미팅 ->
시스템이 해야할 일을 알아내야합니다.
비슷한 시스템을 알아내기
시스템과 상관없는 것 알아내기
특징들 찾아내기
특징은 시스템이 해야할 일에 대해 추상적으로 설명한것
하나의특징은 이것을 만족하기 위한 여러개의 요구사항으로 이루어짐
특징과 요구하항의 차이점에 너무 얽매이지 마세요. 같은 뜻으로 사용하는 경우도 있음.
항상 세부 내용은 늦출 수 있을 때까지 최대한 늦추세요.
시스템에 대한 큰 그림이 필요합니다.
시스템이 하는 일을 알아야하지만 세세한 내용까지 다루고 싶지 않을 때 유스케이스 다이어그램이 필요.
유스케이스 다이어그램은 시스템이 해야하는 기본적인 기능을 잊지 않게 도와줍니다.
중요한 것은 큰 그림
다이어그램에 표시된 유스케이스들이 시스템의 모든 특징들을 모두 표현하는지 확인 하세요.
유스케이스 다이어그램을 그려서 필요없는 세부 사항에 얽매이지 않고 여러분이 만들어야할 시스템을 나타내 보세요.
도메인 분석
크게 나누기 -> 만들 필요가 없는 시스템의 부분을 만들지 않는 데 도움이 됩니다.
MVC 패턴
=> 여기까지 하면 큰 문제가 여러개의 작은 문제로 바뀌게 됨.
공통점과 차별성
특징들 찾아 내기
특징 : 다양한 타입의 지형을 지원한다.
요구사항 : 타일은 지형과 관련 있다.
개임 디자이너는 원하는 지형타입을 만들 수 있다.
각 지형은 유닛의 움직임에 영향을 주는 특성이 있다.
유스케이스는 개발 시스템 전체의 큰 그림을 보는 데 항상 도움이
되지는 않습니다
항상 세부 내용은 늦을 수 있을 때 까지 늦추세요
커다란 개념을 다룰 때는, 작은 내용에 너무 얽매이지 마세요
유스케이스 다이어그램
유스케이스 다이어그램은 여러분의 시스템에 대한 청사진 입니다.
특징리스트를 사용해서 유스케이스 다이어그램에 빠진것이 없게 만드세요.
액터들도 사람입니다. (항상 그렇지는 않지만)
게임도 액터임.
특징 또는 요구사항 리스트로 시스템이 해야할 큰 일을 알아냄.
유스케이스 다이어그램을 그려서 필요 없는 세부사항에 얽매이지 않고 여러분이 만들어야할 시스템을 나타내 보세요.
도메인 분석을 좀 해 봅시다
도메인 분석을 통해 디자인을 확인할 수 있고, 고객이 사용하는 용어를 사용할 수 있습니다.
도메인 분석 : 기존 시스템과 개발 이력, 도메인 전문가들로 부터 얻은 지식, 기반이론, 그리고 도메인에서 새로 등장하는 기술을 기반으로 도메인관련 정보를 찾아내고, 모으고, 구조화하고, 나타내는 프로세스
나눠서 정복하기
이것은 모델 뷰 컨트롤러 패턴입니다.
7장. 혼란스러운 세상에 질서를
우리는 아키텍처가 필요합니다
아키텍처는
디자인 구조이고,
프로그램의 가장 중요한 부분들과 그들 사이의 관계를 명확히 보여 줍니다.
아키텍처 : 아키텍처는 시스템의 분할, 나뉜 부분들 사이의 연결과 상호작용 메커니즘 그리고 시스템 디지인에 사용된 원리와 결정사항들을 담고 있는 시스템 구조 입니다.
기능부터 시작합시다
첫번째 단계는 항상 프로그램이 고객이 원하는 일을 하게 하는 것입니다.
여러분 프로그램에서 정말 중요한 일은 아키텍처적으로 중요한 일이며 여러분은 그 일에 먼저 초점을 맞추어야합니다.
무엇이 아키텍처적으로 중요합니까?
아키텍처에 관한 세 가지 질문
- 시스템의 본질이 되는 부분인가?
- 이것은 무슨 의미죠?
- 도대체 어떻게 해야하나요?
무엇이 중요하죠? 왜죠?
시스템의 본질은 가장 기본적인 수준이 완성되었을 때의 시스템 모습입니다.
어떤것을 먼저 할 까요?
위험요소를 줄이는 방향으로 진행해야함.
보드부터 만들기
board -> title, Unit
위험 줄이기
시나리오들이 위험요소를 줄이는 데 도움이 됩니다
한 번에 하나의 특징에 집중하세요
프로젝트에서 위험을 줄이려면, 한 번에 하나의 특징에 집중하세요.
위험을 줄이는 데 도움이 되지 않는 특징들에 너무 신경쓰지 마세요.
가능하면 이미 만들어진 내용을 기초로 만드세요.
아키텍처는 디자인의 구조입니다
공통점 다시 보기
이러한 다양한 타입의 유닛중에 무엇이 공통점인가요? 모든 유닛 타입에 적용되는 기본적인 내용에는 무엇이 있을까요?
-> 없음..
-> 유닛은 타입과 간단한 이름/값으로 이루어진 속성들을 가지고 있는 다는 것이 공통점입니다.
->type: string, property : Map
좋은 디자인은 항상 위험을 줄여줍니다.
공통점 분석:유연한 소프트웨어로의 길
가끔은 위대한 소프트웨어를 작성하는 가장좋은 방법은 가능한 한 코드 작성을 피하는 것일 수 있습니다.
공통점과 아키텍처에 대한 세 가지 질문(?? 이게 뭐지??)과 같은 도구들이 해답에 이르도록 도와줌.
프로젝트의 아키텍처 설계 단계에서 하는 모든일은 프로젝트 실패 위험을 줄여야합니다.
공통점 분석을 사용해서 유연한 소프트웨어 솔루션을 만드세요.
고객은 여러분의 생각에 정말 멋지게 짜여진 코드에 관심이 있기보다는 그들이 원하는 일을 하고, 시간에 맞게 만들어지는 소프트웨어에 관심이 있습니다.
8장. 독창적인 디자인은 정도껏
디자인 원리 정리
객체지향 원리
변하는 것을 캡슐화 하라
구현의 의존하기 보다는 인터페이스에 의존하도록 코딩해라
각 클래스는 변경요인이 오직 하나이어야 한다.
클래스는 행동과 기능에 관한 것이다.
입증된 객체지향 디자인 원리들을 사용하면 좀 더 유지보수하기 쉽고, 유연하고 확장이 쉬운 소프트웨어를 만들 수 있습니다.
개방-폐쇄의 원리(Open-Closed Principle, OCP)
클래스는 확장에는 열려있고, 수정에는 닫혀있어야한다.
ocp 는 유연성에 대한 것이고, 단순히 상속에 대한 내용이 아닙니다.
Q : ocp를 사용하는 유일한 방법이 상속인가요?
아닙니다 여러분의 코드가 수정에는 닫혀있고, 확장에는 열려있으면 OCP를 사용하는 것입니다.
예를들어, 클래스에 private 메소드가 여러개 있다면, 이들은 수정에 닫혀있는 것입니다. 다른 코드들이 건드릴 수 없는 코드입니다. 하지만 그 prvate메소드를 호출하는 public 메소드를 추가할수 있습니다. 이때 여러분은 private메소드의 행동을 변경하지 않지만 확장하고 있는 것입니다. 이것도 OCP가 사용되는 또다른 예 입니다.
반복 금지의 원리(Don"t Repeat Yourself Principle-DRY)
반복하지 마세요. : 공통되는 부분을 추출하여 추상화하고 한곳에 두어 중복 코드를 피하라
- 공통된 코드를 추상화 합니다.
- 이제 다른 부분의 코드를 지웁니다.
- 그리고 단계 1에서 옮긴 코드를 가리키게 합니다.
DRY는 하나의 요구사항은 한 곳에 두어야 한다는 원리입니다.
DRY는 시스템의 각 정보와 기능을 말이 되는 하나의 장소에 두는 것을 의미합니다.
DRY는 특징과 요구사항에도 적용됩니다.
단일 책임의 원리(Single Responsibility Principle, SRP)
SRP : 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나의 책임을 수행하는데 집중되어 있어야한다.
책임이 변하면, 그 변화를 반영하기 위해 어디를 봐야하는지 정확히 할 수 있다.
각 객체가 변화의 요인이 하나 뿐이라면 여러분은 단일 책임의 원리를 정확히 구현한 것입니다.
응집도는 사실 SRP의 다른 이름이라고 할 수 있습니다. 여러분의 응집도가 높은 프로그램을 작성한다면, 이는 곳 SRP를 잘 적용하는 것을 의미합니다.
[클래스이름] 클래스에 대한 SRP 분석
1. [클래스이름] 가 자신을 [메소드] 한다.
~~ 클래스의 메소드마다 이 줄을 반복하세요. 내용이 말이 되지 않으면 아마도 그 메소드에서 SRP를 위반하고 있을 것입니다. 그 메소드는 다른 클래스에 속해야 할 지도 모릅니다. 옮기는 것을 고려해 보세요.
2. [클래스이름] 이 [파라미터]를 [메서드] 한다.
리스코프 치환 원리(LSP)
리스코프 치환원리 : 자식 타입들은 부모 타입들이 사용되는 곳에 대체될 수 있어야한다.
LSP는 잘 디자인된 상속에 관한 내용입니다. 부모클래스를 상속할 때 부모 클래스가 사용되는 곳은 아무 문제 없이 자식 클래스도 사용할 수 있어야합니다. 그렇지 않으면 상속을 잘 못 사용하고 있는 것입니다.
다른클래스의 기능을 사용해야 하는데 그 기능을 변경하고 싶지 않다면, 상속대신 위임을 고려하세요.
구성은 우리가 인터페이스에 정의된 기능을 사용하고, 그래서 컴파일 중이나 실행중에 그 인터페이스의 여러구현 클래스 중에 선택하기를 원할 때 위력을 발휘합니다.
구성에서는 다른 행동들로 구성된 객체는 그 행동을 소유하고 있는 것입니다. 그 객체가 없어지면, 소유하고 있던 모든 행동들도 없어집니다. 구성에 참여한 행동들은 구성의 외부에서는 존재하지 않습니다.
위임은 특정일의 책임을 다른 클래스나 메소드에 맡길 때를 지칭합니다.
구성을 통해 하나의 인터페이스를 구현한 여러클래스들의 기능을 사용할 수 있고, 실행중에 그 클래스를 바꾸어 기능을 변경할 수 있습니다.
비슷한 여러 종류의 기능을 참조하는 경우 구성을 사용하는 것. (Weapon)
소유하고 있는 객체가 없어질 때 구성의 부분인 객체들도 같이 사라집니다.
집합(Aggregation): 구성에 참여한 객체들이 주 객체의 외부에서도 존재해야할 경우
집합은 한 클래스가 다른 클래스의 부분으로 사용되지만 다른 클래스의 외부에서도 존재하는 경우를 지칭합니다.
구상vs 집합
내가 사용하고 싶은 행동을 하는 객체가 그 행동을 사용하는 객체의 외부에서도 존재해야하나?
만약 객체가 독립적으로 존재하는 것도 의미가 있다면 집합을 사용해야합니다. 그렇지 않다면 구성을 사용하세요.
다른 클래스의 행위를 재사용하는 방법 : 상속 , 위임, 구성, 집합
위임, 구성, 집합을 상속보다 선호화면 대개의 경우 여러분의 소프트웨어는 더 유연하고, 유지보수정, 확장성 그리고 재사용성이 좀 더 좋아집니다.
9장. 소프트웨어는 여전히 고객을 위한 것입니다.
여러분의 도구 상자는 채워지고 있습니다
여러분은 반복 작업을 통해 위대한 소프트웨어를 작성합니다
여러분은 반복잡업을 통해 위대한 소프트웨어를 작성합니다. 큰 그림을 그리고, 그 다음 애플리케이션이 완성될 때까지 조각조각들에 대해 반복적으로 작업하세요.
반복 심화 작업: 두 가지 기본적인 선택
작은 조각아라는 말이 어플레이션 관점에서 무엇을 의미하는지 알아내는 기본적인 접근 방식이 있습니다.
특징주도개발 : 어플리케이션의 특정한 특징을 선택하고, 완성될 때 까지 그 특징을 계확, 분석, 개발하는 것입니다.
-> 어플리케이션의 특정한 특징에 집중하는 것을 선택할 수 있습니다. 이 접근 방법은 고객이 원하는 기능의 한 조강을 선택하고, 그것이 완성될 때 까지 작업하는 것입니다.
-> 한 번에 하나의 특징을 작업하고 그리고 나서 반복하여, 애플리케이션 기능을 완성할 때까지 한 번에 하나씩 특징들을 구현합니다.
-> 더 세분화된 모양입니다.
-> 서로 별로 연결되어 있지 않은 특징들이 많을 때 잘 작동합니다.
-> 고객에게 동작하는 코드를 빨리 보여줄 수 있습니다.
-> 매우 기능 주도적입니다. 특징 주도 개발을 하면 어떠한 특징들도 빠트리는 일이 없을 겁니다.
-> 연결되어 있지 않은 기능의 조각들이 많은 시스템에서 특히 잘 동작합니다.
유스테이스 주도 개발 : 유스케이스의 시나리오를 선택하여 완성될 때가지 코드를 작성하는 것입니다.
-> 어플레이션의 특정한 흐름에 집중하는 것을 선택할 수 있습니다. 이 접근 방법은 애플리케이션에서 하나의 완전한 경로를, 명확한 시작에서 끝까지 선택하여 코드로 구현하는 것입니다.
-> 유스케이스 내에서 하나의 시나리오를 완성하는 작업을 합니다. 그 다음 또 다른 시나리오를 선택하여 작업하며, 유스케이스의 모든 시나리오가 완성될 때 까지 반복합니다.
-> 큰 그림의 모양입니다.
-> 독립적인 기능보다는 많은 프로세스와 시나리오를 가지고 있는 어플리케이션의 경우 잘 작동합니다.
-> 고객에게 각 개발단계마다 더 큰 단위의 기능조각을 보여줄 수 있습니다.
-> 매우 사용자 중심적입니다. 유스케이스 주도 개발을 사용하면 사용자가 시스템을 사용하는 여러 방법들을 모두 고려하여 코딩할 것입니다.
-> 길고 복잡한 프로세스를 가진 트랜잭션 시스템에서 특히 잘 동작합니다.
반복작업의 두 가지 접근방식은 잘 작성된 요구사항에 의해 유도됩니다.
요구사항은 고객으로 부터 나오기 때문에 두 가지 접근 방식은 고객이 원하는 것을 개발하는 데 주안점을 두고 있습니다.
특징 주도 개발(Feature driven development)
유스케이스 주도 개발(Use case driven development)
개발의 두 가지 접근 방식
특징 분석
본문분석(textual analysis)
클래스 다이어그램과 비전 기술서를 비교해 보십시요. 클래스 다이어그램에 빠진것이 있습니까?
테스트 주도개발은 클래스의 기능을 올바르게 만드는 데 집중합니다.
테스트 시나리오 작성하기
테스트 케이스가 아주 복잡할 필요는 없습니다. 여러분의 클래스 기능이 정확히 동작하고 있는지를 보여주면 됩니다.
여러분은 여러분의 소프트웨어를 생각할 수 있는 모든 사용가능한 방법으로 테스트해야합니다. 창조적이여야 합니다.
소프트웨어의 잘못된 사용 방법에 대해서도 테스트 하는 것을 잊지맞세요. 여러분은 초기에 오류를 잡아낼 것이며, 여러분의 고객을 기쁘게 할 것입니다.
테스트 주도 개발은 클래스의 기능을 올바르게 만드는 데 집중합니다.
공통점 분석 정제하기
공통점과 차별점
공통적인 요소들을 변수와 메소드를 빼고, 변화하는 속성들은 Map에 남겨두기
-> 중복이 있고, 유지보수에 손이 많이 감.
모든 종류의 유닛속성들 모두 캡슐화하여서 속성 Map에 넣기.
-> 좀더 변화에 잘 대응할 수 있음. 많은 캡슐화
-> 공통점 무시, 형변환 필요
===> 설계 시 결정은 항상 트레이드오프가 있습니다.
좋은 소프트웨어는 반복작업을 통해서 완성됩니다. 어플리 케이션의 매우 작은 부분을 작업하면서, 분석과 설계를 하고, 다시 이를 되풀이 하세요.
반복해서 작업할 때 마다 설계 절정들을 재평가하고 , 여러분의 설계에 도움이 되면 무언가 변경하는 것을 두려워 마세요.
공통점 분석
공통점 강조하기
캡슐화 강조하기
테스트 주도 개발(test driven development)
테스트를 설계에 적용하세요
테스트 케이스 해부…
- 각 테스트 케이스는 아이디와 이름을 가지고 있어야합니다.
- 각 테스트 케이스는 그것이 테스트하는 특정한 것 하나를 테스트 해야합니다.
- 각 테스트케이스는 여러분이 제공하는 입력 값을 가지고 있어야합니다.
- 각 테스트케이스는 예상되는 출력값을 가지고 있어야 합니다.
- 대부분의 테스트케이스는 초기상태를 가지고 있습니다.
ID | 테스트 제목 | 입력값 | 예상출력값 | 초기 상태
여러분 자신을 고객에게 입증해 보이세요
당신이 약정(contract)에 의해 프로그램을 작성할 때, 당신과 당신의 프로그램 사용자는 소프트웨어가 어떤 식으로 동작할 것이라는 것에 동의하고 있는 것입니다.
우리는 지금까지 약정(contract)에 의해 프로그램을 작성했습니다
약정에 의한 프로그래밍이란 정말로 모두 믿음에 관한 것입니다
방어적 프로그래밍(depensive programming)
여러분이 약정에 의한 프로그래밍을 할 때, 문제상황을 어떻게 다룰지 합의하기 위해 고객의 코드와 같이 작업하는 것입니다.
여러분이 방어적 프로그래밍을 한다면, 고객이 어떠한 일이 발생되기를 원하건 간에, 고객이 안전한 응답을 얻도록 할 것입니다.
어플리케이션을 기능의 작은 덩어리도 나누어 보세요
핵심 정리
OOA&D 도구 상자
10장. 종합하기
OOA&D 스타일로 소프트웨어 개발하기
1. 여러분의 소프트웨어가 고객이 원하는 기능을 하도록하세요.
1.1 특징리스트
상위수준에서 어플리케이션이 어떻게 동작하는지 이해하기
특징리스트는 모두 소프트웨어가 무엇을 해야하는지 이해하는 것에 대한 것입니다.
(특징과 요구사항은 비슷한 말 일 수도 있거나 특징에서 요구사항을 뽑아낼 수도 있음.)
(요구사항 : 여러분의 시스템이 올바르게 동작하기 위해서 수행하는 특정한 하나의 일)
1.2 유스케이스다이어그램
애플리케이션이 수행할 프로세스와 관련된 외부영향을 결정하기
유스케이스 다이어 그램은 불피요한 세부항목들속으로 빠져들지 않고 소프트웨어가 어떻게 사용될 것이지에 대해 생각 할 수 있도록 합니다.
유스케이스는 사용법을 반영하고, 특징은 기능을 반영합니다.
시스템에서 특징은 시스템이 해야하는 것이며, 시스템이 어떻게 사용되어야 하는지 보여주는 유스케이스에 항상 반영되지는 않습니다.
특징과 유스케이스는 함께 작업합니다. 그러나 그것들은 같은 것이 아닙니다.
(유스케이스는 고객의 특정한 목표를 달성하기 위해 여러분의 시스템이 무엇을 하는 지를 기술합니다.)
(유스케이스는 기본적으로 3가지 부분이 있습니다. 명확한가치, 시작과 종료, 외부기동자)
1.3문제점분해하기
애플리케이션을 기능단위의 모듈로 분해하여, 각 모듈중 어느 것을 먼저 다룰지 순서를 결정하기
크게 분할하기
1.4 요구사항
각 모듈에 대한 개별적 요구사항을 이해하고 큰 그림에 부합하도록 만들기
유스케이스를 요구사항집합으로 변환
1.5 도메인 분석
어떻게 유스케이스들이 애플리케이션의 객체들로 사상되는지를 이해하고, 고객과 공감대 형성하기
요구사항의 명사(클래스 후보), 동사(오퍼레이션 후보)
2.객체지향 기본원래를 적용해서 소프트웨어를 유연하게 하세요.
2.1 사전설계
객체들에대한 세부내용을 채워넣고, 객체들 사이의 관계를 정의하며, 원리와 패턴을 적용하기
디자인 결정은 좋은 객체지향 원리 뿐만 아니라 여러분의 시스테이 어떻게 사용될 것인가에 근거하고 있어야만 합니다.
2.2 구현
코드를 작성하고 테스트하여, 동작하는 것을 확인하기 완성할 때 까지 각 행위 각특징, 각유스케이스, 각 문제점에 대해 그렇게 하기
여러분은 오직 상호작용할 필요가 있는 클래스만 고객에게 노출시켜야합니다. 고객 코드가 상호작용하지 않는 클래스는 고객 코드에 최소한의 영향만 주고 변경될 수 있습니다.
하나의 유스케이스가 완성되면 다음 유스케이스 시작을 위해 요구사항 단계로 이동.
3. 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요.
3.1 구현
ooad는 많은 선택사항을 가지고 있습니다. 문제를 해결하는 데 한 가지 올바른 방버만 있는 것은 아닙니다. 그래서 여러분이 더 많은 선택사항을 가질 수록, 어떤 문제에 대해서도 좋은 해답을 찾을 더 많은 기회가 있습니다.
반복 작업 #3, 누구든지?
여행은 끝나지 않았습니다...
부록 A. 10개의 핵심 토픽 (우리가 다루지 않았던)
#1. IS-A와 HAS-A
#2. 유스케이스 형식
#3. 안티 패턴
#4. CRC 카드
Class , Responsibility, Collaborator
SRP 분석과 같이 사용됩니다.
| 클래스 Automobile | ||
| 설명 차와 관련된 내용을 나타냅니다. | ||
| 책임들 | ||
| 이름 | 협력클래스 | |
| 타이어를 교체한다. | Mechanic, Tire | |
#5. 메트릭(Metrics)
#6. 시퀀스 다이어그램(Sequence Diagram)
#7. 상태 다이어그램(State Diagram)
uml은 주로 상태 다이어 그램이라고하는 상태머신 다이어그램, 또는 상태 차트 다이어 그램을 포함하고 있습니다.
기호들
시작 : ●
종료 : ⦿
상태 : ☐ (둥근 사각형)
#8. 단위 테스팅(Unit testing)
#9. 코딩 규칙과 읽기 쉬운 코드
#10. 리팩토링(Refactoring)
부록 B. 객체지향 언어로 말하기
UML과 클래스 다이어그램
상속
다형성
캡슐화
핵심 정리