OOAD : 큰 문제 해결하기
큰 프로그램에서 문제를 해결할 때에도 마찬가지로 작은 프로그램에 접근과 마찬가지로 큰문제도 해결한다.
1. 고객의 요구사항을 분석하여 고객이 원하는 기능을 하도록 한다.
2. 객체지향 기본원리를 사용한다.
- 각 객체는 하나의 책임만 진다.
- OCP(Open Closed Principle) : 확장에 대해 열려있고 변경에 대해 닫혀있다.
3. 유지보수와 재사용이 쉬운 디자인을 위해 노력한다.
- 변경이 이루어지는 부분은 Encapculation!
- 공통된 속성 / 오퍼레이션은 추상 부모클래스로 만들어 놓자!
- 인터페이스 적절히 사용, : 구현에 맞추어 코딩하는 것보다 인터페이스에 맞추어 코딩하면 소프트웨어 확장이 더 쉬워진다.
시스템이 할 일을 유스케이스 다이어그램으로 작성한다.(천마디 말보다 한번 보는게 낫다)
유스케이스 다이어그램은 구현의 세세한 내용을 따지기 보다는 어떠한 소프트웨어 시스템이 하는 전체적인 구성(특징 요구사항 : feature requirement)을 시나리오 별로 작성하는 것이다. 즉, 유스케이스 다이어그램은 시스템 전반에 대한 그림일 뿐 세세한 내용을 포함하지는 않는다. 하지만 유스케이스를 그림으로써 시스템이 해야 하는 기본적인 기능을 잊지 않게 한다.
다음 단계로 클래스 다이어그램을 그릴수 있다고 생각 할 수 있겠지만 고객을 이해 시켜 고객이 원하는 특징 요구사항이 제대로 되었나 확인 하거나 디자인을 다시 확인 하기 위해서는 도메인 분석이 필요하다.
도메인 분석은 기존 시스템과 개발 이력, 도메인 전문가 들로부터 얻은 지식, 기반 이론, 그리고 도메인에서 새로 등장하는 기술을 기반으로 도메인 관련 정보를 찾아내고 모으고 구조화하고 나타내는 프로세스를 말한다. 예를 들어 고객은 프로그래머가 아님으로 클래스 다이어그램으로 작성하면 고객이 알아 들을 수가 없기 때문에 고객이 이해하는 언어 유스케이스 시나리오를 분석함으로 고객이 바라는 일을 해 주는지 제대로 알 수 있다.
그리고 프레임웍을 쪼개어 각각의 작은 기능들로 나누어 관리한다. 예를들어 비슷한 기능을 하는 클래스끼리 모듈로 각각 나누어 관리를 하는데 이때 도메인 분석을 함으로써 불필요한 시스템의 부분을 만들지 않게 한다.
1. 고객의 말에 귀를 기울여 요구사항을 파악.
2. 시스템을 이해했는지 맞는지 확인.
3. 유즈케이스 작성하기.
4. 모듈을 나누어 작은 기능의 조각으로 나누기.
5. 작은 문제들의 해결에 디자인 패턴 적용하기
2. 시스템을 이해했는지 맞는지 확인.
3. 유즈케이스 작성하기.
4. 모듈을 나누어 작은 기능의 조각으로 나누기.
5. 작은 문제들의 해결에 디자인 패턴 적용하기
'JAVA' 카테고리의 다른 글
[java] Redis pub/sub을 이용한 IPC (0) | 2017.02.02 |
---|---|
[java] 파일 읽기, 쓰기, nio를 통한 파일 처리 (0) | 2017.02.02 |
STS + Maven Local Repository 참조하기 (0) | 2016.11.29 |
interlock_android/external db (4) | 2011.07.13 |
[JAVA]문자스트림 주고 받기 (0) | 2010.07.22 |