키큰개발자

요구사항 변경

소프트웨어 개발에서는 변경이 불가피하고 이로인해 유스케이스 시나리오가 충분히 달라질 수 있음을 알자.

변경을 하더라도 유스케이스를 잘 만들도록하자 -> 명확한 목표, 시작, 종료 가 분명히 들어나있으면 된다.

요구사항 분석

유스케이스를 만들고나서 반드시 분석의 과정을 밟자.  why? 문제에 대한 해결방법을 냈는데 이게 실세계에서는 맞는 방법이 아닐 수 있기 때문

 - 실세계에서 다양한 경우가 존재하는데 이까지 해결할 수 있는 좋은 프로그램을 만들기 위해서 유스케이스 분석을 해봐야한다.'

 - 분석이라는 것은 막 대단한 것은 아니고 내가 구성한 시나리오가 말이 맞고 예외의 경우가 더 있지 않을까 하고 한번 더 생각해보자는 말이다.

• 요구 사항 수집의 핵심 

 고객이 원하는 것을 제대로 알아내기 위해서 시나리오를 작성해본다.

      - 따라서 요구사항 수집 부분에서는 요구사항 리스트와 유스케이스 시나리오를 만든다.

UML과 클래스 다이어그램 

 - 코드에 대한 간편한 의사소통 방법

상속 

 - 중복되는 코드를 피하는 방법 중 하나 

다형성  

 - 서브 클래스로 쉽게 쉽게 변경이 가능하다. 

 - 슈퍼클래스를 대신해서 다양하게 서브클래스로 사용되는 예

캡슐화

 - 분리 시키는 작업

   1. 논리적 그룹으로 나누는 분리

     - 중복된 코드가 있을 때 따로 그룹을 나눠서 한 곳으로 몰아서 나누는 형태, 클래스를 별도로 만들어서 분리함.

     - 일반적으로 우리가 데이터 영역과 기능 영역을 나누는 것

   2. 보호할 영역과 아닌 영역의 분리

     - private로 인해 직접적으로 수정, 액세스를 막음으로써 프로그램의 예기치 못한 변경을 막는다.

객체지향 분석 설계 (Objet-Oriented Analysis & Design)

- 고객이 원하는 것을 하고 잘 설계되었다라는 것을 보장하는 소프트웨어 개발 방법

- 다음 순서로 개발하면 잘 만든 소프트웨어라고 말할 수 있다고 한다.

1. 원하는 것을 충분히 잘 들어준다. -> 요구사항 (잘)만들기

2. 유연하게 만든다. -> 객체지향 원리 적용

3. 좀 더 유연하고, 좀 더 확장성있고, 좀 더 유지보수하기 쉽게 바꾼다. -> 객체지향 원리 적용 + 디자인 패턴