skyjump's blog

소프트웨어 개발

1. 특징리스트

2. 유스케이스 다이어그램

3. 문제점 분해하기
코드에 관한 것으로 어떻게 기능을 분해할지에 대한 것.
4. 요구사항
고객이 소프트웨어를 어떻게 사용할지에 대한 것.
5. 도메인 분석

6. 사전 설계

7. 구현

8. 4~7 반복

9. 완성

시스템에서 특징은 시스템이 해야 하는 것이며, 시스템이 어떻게 사용되어야 하는지 보여 주는 유스케이스에 항상 반영되지는 않는다. 간접적으로 사용된다.

문제점을 분해하고 유스케이스를 요구사항으로 바꿀 때, '문제 이해하기' 단계가 들어갈 수 있다.

 

반복작업을 통해 소프트웨어를 만든다.
큰 그림에서부터 거기서 나눠진 조각들에 대해 반복적으로 작업한다.

특징주도개발(Feature driven development)
고객이 원하는 기능의 한 조각을 선택하고 그것이 완성될 때까지 작업하는 것

유스케이스 주도 개발(Use case driven development)
하나의 완전한 경로를 시작에서 끝까지 코드로 구현.

두가지 방법 모두 고객이 원하는 것을 개발하는 데 초점을 맞추고 있다.

특징 주도 개발
하나의 특징을 결정했다면, 다시 그 특징에대한 분석을 한다.
반복적인 분석. 트리처럼 깊히 분석할수록 세부적인 기능들이 나오는 것을 상상.

고객을 만족시키기 위해 테스트 시나리오를 만든다.
모든 가능한 사용 방법으로 테스트한다.
잘못된 사용 방법에 대해서도 테스트 한다. 이는 초기에 오류를 잡도록 해줄 것이다.

테스트 주도 개발
테스트를 먼저 작성하고 이 테스트를 통과할 수 있도록 소프트웨어를 개발한다.

실제 대부분의 소프트웨어 분석 설계는 다양한 접근 방식을 혼용하여 사용한다. 예) 유스케이스 주도 개발로 시작하여 다음 작업은 유스케이스에서 작은 특징 하나를 선택(특징 주도 개발)해서 개발. 이 특징을 어떻게 구현할지 확인하기 위해 테스트 주도 개발 사용.

각 테스트는 기능의 한 부분에 초점을 맞춘다.

설계방식을 결정할 때( 예) 공통점과 캡슐화 중에서 하나 선택해야 할 때.) 어느 방법이든 항상 트레이드오프(trade off)가 있다. 장점이 있지만 단점도 있는.

반복해서 작업할 때마다 기존의 설계방식을 재평가하고 더 나은 방향으로 변경하는 것을 두려워하지 마라.

약정에 의한 프로그래밍(contract), 방어적 프로그래밍(defensive)
약정에 의한 프로그래밍을 할 때, 문제 상황을 어떻게 다룰 지 합의하기 위해 고객의 코드와 같이 작업하는 것.
방어적 프로그래밍을 한다면, 고객이 어떠한 일이 발생되기를 원하건 간에, 고객이 안전한 응답을 얻도록 확인할 것.
 

디자인원리는 코드를 좀 더 유지보수하기 쉽고 유연하고 확장하기 쉽게 만들어준다.
이전에 배웠던 디자인원리
캡슐화, 구현에 의존하기 보다 인터페이스에 의존하도록 코딩, 각 클래스는 변경요인이 하나여야 한다, 클래스는 행동과 기능에 관한 것이다.

Open-Closed principle, OCP 
클래스는 확장에는 열려있고, 수정에는 닫혀있어야 한다.

OCP의 예

 
CRT와 LCD는 Monitor를 상속한다. Monitor 클래스는 수정에는 닫혀 있다. display 메소드는 변경되지 않는다.
하지만 서브클래스들이 오버라이드를 통해 display의 행동을 변경할 수 있기 때문에 확장에는 열려있다.

OCP는 단순히 상속에 대한 내용은 아니고 유연성에 대한 내용이다. 또 다른 예 : private 가 있는 클래스.
OCP는 잘 동작하여 고객을 만족시키고 있는 코드를 건드리지 않고도 부모 클래스의 행동을 추가 확장할 수 있다.
OCP는 캡슐화와 추상화의 조합. 변하지 않는 클래스의 기능을 찾아 부모 클래스에 추상화하여 변경하지 못하게 한다. 새롭거나 다른 기능이 필요할 때, 부모 클래스를 확장하여 변경을 해결한다.

DRY (Don't Repeat Yourself)
공통되는 부분을 추출하여 추상화하고 한 곳에 두어 중복 코드를 피하기.
하나의 요구 사항은 한 곳에 두어야 한다는 원리.(시스템의 정보와 기능이 한 곳에 있어야 한다)
코딩할 때 뿐만아니라 요구사항 수집때부터 요구사항이나 유스케이스가 겹치지 않도록 해야 한다.

 SRP (Single Responsibility Principle)
 한가지 일만 잘하게 하자. (클래스 변경의 요인이 한가지여야 한다.)
응집도와 같은 의미
SRP인지 테스트 하는 방법.
(클래스이름)가 자신을 (클래스의 각 메소드)한다.
이게 말이 되면 SRP.

리스코프 치환 원리(LSP)
상속에 대한 내용. 부모클래스가 사용되는 곳은 아무 문제없이 자식 클래스도 사용될 수 있어야 한다.

위임(Delegation)
특정 일의 책임을 다른 클래스나 메소드에 맡길 때
다른 클래스의 기능을 사용해야 하지만 그 기능을 변경하고 싶지 않을때 사용.
예) 악기 인벤토리 클래스에서 사용자가 악기를 검색할 때, 검색기능을 악기스펙 클래스에게 맡기는 것.

구성(Composition)
비슷한 여러 종류의 기능을 참조하는 경우.
예 ) 병사가 여러 무기를 사용하고 싶을 때 무기 인터페이스를 참조해서 실행중에 특정무기 클래스로 바꿀 수 있도록 할 때.
구성되어 있는 객체들은 그것들을 참조하는 객체에 속한 거라 그 객체가 없어지면 구성 객체들도 없어지는 특징이 있다.
하지만 안 사라지게 하고 싶을땐? 즉, 클래스 외부에서도 존재하도록 하고 싶을 때는 어떻게 할까? 집합(Aggregation)을 사용한다.

집합(Aggregation)
한 클래스가 다른 클래스의 부분으로 사용되지만 다른 클래스의 외부에서도 여전히 존재하는 경우.

리스코프 치환 원리(LSP)는 언제 상속을 사용할 것인가에 대한 원리. LSP가 성립하지 않는 다면, 즉 부모클래스가 사용된 곳에 자식클래스가 대체되어 사용될 수 없으면, 집합이나 구성, 위임등 다른 객체지향 방법을 찾아봐야 한다.
 

큰 조각을 작은 조각으로 나누었고 아키텍쳐는 이러한 조각들이 어떻게 연결되는지 그리고 어떤 조각들이 더 중요한지를 알게 해준다. 즉, 무엇부터 시작해야 될지 알려준다.
아키텍쳐 (architecture)
아키텍쳐는 디자인 구조이고 프로그램의 가장 중요한 부분들과 그들 사이의 관계를 명확히 보여준다.
중요한 구성요소들의 관계를 파악하기 위해서는 구성 요소를 알아야 한다.
그래서 그 구성요소부터 파악한다. 가장 중요한 기능에 초점을 맞춘다.

중요한 기능을 정하는 기준.
1. 시스템의 본질이 되는 부분인지. 가장 기본적인 요소.
2. 그 기능이 무슨 의미인지 모를 때.
3. 그 기능을 도대체 어떻게 해결해야될지 감이 안올 때.

중요한 기능을 발견하고 나서 어떤 기능을 먼저 만들지는 위험요소(양이 많아 시간이 오래 걸린다던가, 고객이 시스템을 맘에 들어 하지 않는다던가, 해결못할 가능성이 있다던가 등등 )를 줄이는 방향으로 진행하기만 하면 순서는 상관없다.

시나리오는 중요한 요구사항을 포함한 유스케이스의 특정 경로.
시나리오는 중요한 기능에 초점을 맞춤으로써 위험요소를 줄이는 데 도움이 된다.
시나리오는 빠르게 문제를 해결할 때, 보편적인 요구 사항을 찾는 데 도움이 된다.
유스케이스는 모든 경로를 다루고 있어서 시간이 오래걸리고 형식적일 수도 있다. 처음부터 너무 세세한 내용에 집착하지 말것.
유스케이스를 사용하든 유스케이스 다이어그램을 사용하든 시나리오를 사용하든 사용목적은 고객의 만족이다.
위험을 줄이려면 한번에 하나의 특징에 집중하고, 위험을 줄이는데 도움이 되지 않는 특징들에 너무 연연해하지 말기.

기능이 무슨 의미 인지 모를 때 먼저 고객들에게 물어본다.
고객들의 이야기를 바탕으로 공통점을 찾고 그 특징을 어떻게 구현할 것인가를 정한다.
좋은 디자인은 위험을 줄여 준다. 이 기능이 무엇인지 파악했고 프로젝트 진행 중에 별다른 변경없이 다른 클래스들과 연결될 수 있다.
공통점분석할 때 차이점이 더 많다면 시스템내에서 그 기능을 처리하지 않는 것이 좋은 방법이 될 수 있다. 

큰 문제는 여러 개의 기능별 조각들로 나누고 각 조각들을 개별적으로 해결.

이제까지 배운것들.
1. 좋은 요구 사항을 얻는 가장 좋은 방법은 시스템이 해야 할 일을 이해하는 것.
2. 변하는 것을 캡슐화해서 프로그램을 더 유연하고 변경하기 쉽게 만든다.
3. 구현보다는 인터페이스에 맞춰서 코딩하면 소프트웨어의 확장이 더 쉬워진다.
4. 좋은 소프트웨어는 변경과 확장이 쉽고 고객이 원하는일을 한다.
5. 분석은 시스템이 실제로 잘 돌아가도록 만드는 데 도움이 된다.

시스템 파악하기
고객과의 대화를 통해 시스템을 파악한다.
좋은 방법 중 하나는 공통점과 차이점을 알아내는 것인데
이는 시스템이 어떤 시스템과 비슷하고, 안비슷한지 얘기하는 것이다.
그리고 나서 대화 정보를 가지고 시스템의 특징을 찾아낸다.
특징을 가지고 요구사항을 알아낸다. 특징과 요구사항은 비슷하다고 보면 된다.
세부내용은 늦출 수 있을 때까지 최대한 늦추기. 세부내용에 신경쓰다가 큰 것을 놓칠 수 있기 때문에
먼저 큰 그림을 봐야 한다.
유스케이스는 큰 그림을 보는 데 도움이 되지 않는다.
그래서 유스케이스 다이어그램을 이용한다.

Use-case 다이어그램
시스템 전체에 대한 큰 그림
특징 리스트 내용이 유스케이스 다이어그램에 빠짐없이 들어가도록 하기.

Actor - 시스템과 상호작용하는 외부객체
Box는 시스템의 경계
각 타원은 유스케이스

도메인 분석
시스템에 대해 알아낸 정보를 고객이 잘 이해할 수 있도록 나타내는 프로세스
특징리스트를 고객이 이해하는 언어로 작성한다.

이제 큰 그림을 그렸으니 작은 기능들로 쪼갠다.
도메인 분석을 하면 만들 필요가 없는 시스템기능을 알 수 있다.

작은 기능들로 나누면 디자인 패턴을 시스템에 적용할 수 있다. 
모델-뷰-컨트롤러
모델 - 시스템에서 실제 일어나는일을 모델링
컨트롤러 - 모델을 관리
뷰 - 모델을 나타내는 것

 

추상클래스
실제 구현 클래스를 위한 저장장소
추상클래스는 기능을 정의하고 서브클래스는 기능을 구현한다.

클래스의 공통적인 요소를 묶기 위해 추상클래스를 사용할 수 있다.

UML


객체지향의 원리

분석을 통해서 시스템이 실세계에서 잘 동작하도록.
시스템에서 문제를 찾고 해결방안을 찾는다.
유스케이스는 고객, 관리자, 동료개발자들에게 시스템을 설명하는데 쓰인다. 그래서 쉬운방식으로 작성되어야 하고
이런 유스케이스들과 분석을 통해서 실세계에서 어떻게 동작하는지 그들에게 보여준다.
분석을 통해서 문제를 발견하면 유스케이스에서 필요한 부분을 수정한다.

다시한번 위임 설명.
위임을 통해 프로그램을 느슨하게 결합시킬 수 있다. 객체들이 독립적으로 동작함을 의미. 객체의 변화가 다른 객체들에게 영향을 미치지 않도록 해준다.
 
분석을 통해 유스케이스를 잘 만든 다음 본문 분석을 통해 무엇을 클래스로 할 것인지에 대해 대략적인 방향을 잡는다. 본문 분석할 때 명사들은 대개 클래스이고 동사는 객체의 메소드이다. 대개 시스템 외부에 있는 명사들은 클래스가 되지 않는다.

클래스다이어그램
연관 - 한 클래스가 다른 클래스와 참조, 확장, 상속 등에 의해 연관되어 있음을 의미. 연관에 이용되는 속성은 목적클래스쪽 화살표위에 표시하며 클래스다이어그램에서 클래서 속성 넣는 곳에는 표시 안한다.
다중도 - 속성이 목적클래스 객체를 몇개까지 가질 수 있는지. '*' 라고 표시하면 무제한

클래스다이어그램는 시스템의 개요을 다른 프로그래머들에게 보여주기 위한 것이다. 타입정보를 정확히 알려주지 않고 메소드를 어떻게 작성해야하는지도 알려주지 않는다. 시스템의 전체 그림을 한눈에 보여준다. 

요구사항은 항상 변한다.

시나리오 : 유스케이스의 시작부터 끝의 경로. 유스케이스에는 몇 개의 다른 시나리오가 있고 주경로, 대체경로로 표시한다. 대체경로는 가끔만 일어나는 단계일수도 있고, 부분적으로 완전히 다른 경로를 제공할 수도 있다.
각 시나리오는 같은 목표를 가지고 있다.
 

소프트웨어는 고객이 원하는 기능을 하도록 해야 한다.
 

위대한 소프트웨어 만들기 3단계
1. 소프트웨어가 고객이 원하는 기능을 하도록 하기
2. 객체지향 기본 원리를 통해 소프트웨어를 유연하게
3. 유지보수와 재사용이 쉬운 디자인 만들기

캡슐화
프로그램을 논리적인 그룹으로 나누기.
일반적으로 변화 가능성이 높은 부분을 그렇지 않은 부분으로부터 분리하여 캡슐화
중복 코드를 볼 때마다 캡슐화 할 수 있는지 찾아보기.
1. 클래스의 데이터를 private로 보호
2. 속성들 전체를 캡슐화
3. 행위를 캡슐화
프로그램을 쪼개서 다른 부분의 수정 없이 특정 부분을 변경할 수 있다.

위임 (Delegation)
객체가 어떤 일을 직접하지 않고 다른 객체에게 그 일을 하도록 맡기는 것
코드의 재사용성이 좋아진다. (각 객체가 자기 자신의 기능만 하면 됨.)
객체가 독립적이고 느슨하게 결합되도록 함. 이로 인해 재사용이 쉬움.