가. 객체지향적 요구사항 분석
1) 유스케이스 기반 객체 정의
•
사용자(O)는 할 일(O)이 있다면 날짜와 시간과 내용을 적어서 전체 목록(O)에 추가함
•
사용자는 할 일을 완료하면 전체 목록에서 할 일을 완료 표시함
•
사용자는 할 일을 완료하지 못하면 할 일을 삭제함
•
사용자는 할 일이 더이상 해야할 일이라고 판단하지 않으면 할 일을 삭제함
•
사용자는 사용하는 할 일에 변경사항이 발생하여 할 일의 날짜와 시간과 내용 중 일부를 수정함
•
사용자는 모든 할 일의 전체 목록을 날짜와 시간을 기준으로 내림차순하여 조회함
•
사용자는 할 일의 카테고리(O)에 따라 할 일의 날짜와 시간을 기준으로 내림차순으로 조회함
2) 객체 간 관계
•
사용자에게는 하나의 전체 목록이 존재함
•
전체 목록에는 하나 또는 다수의 카테고리가 존재함
•
카테고리에는 할 일이 없거나 하나 또는 다수의 할 일이 존재함
3) 타입별 객체 분류
•
타입: 사용자, 전체 목록, 카테고리, 할 일
4) 타입 간 관계
•
포함관계: 사용자 
전체 목록, 전체 목록 카테고리, 카테고리 할 일
전체 목록, 전체 목록 카테고리, 카테고리 할 일•
연관관계: X
5) 요구사항 분석 결과
나. 객체 간 협력 설계
1) 공통
•
메시지: 수행할 작업을 입력 받음
→ 메시지 수신 객체: 콘솔
→ 수신 객체 책임: 수행할 작업(조회, 생성, 수정, 삭제)에 대한 입력값 받기
2) 조회
•
메시지: 특정 사용자의 할 일 중 완료되지 않은 것 출력
→ 메시지 수신 객체: 목록
→ 수신 객체 책임: 목록 내 할 일 중 완료되지 않은 모든 것 출력
→ 도움 요청: 목록에 포함된 카테고리 객체에게 완료되지 않은 할 일 객체의 데이터 요청
•
메세지: 카테고리 내 할 일 객체 중 완료되지 않은 것의 데이터 요청
→ 메세지 수신 객체: 카테고리
→ 수신 객체 책임: 카테고리 내 완료되지 않은 모든 할 일 객체를 목록 객체에 전달
→ 도움 요청: 카테고리에 포함된 할 일 객체에게 완료되지 않은 할 일의 데이터 요청
•
메시지: 완료되지 않은 할 일에 대한 데이터 요청
→ 메시지 수신 객체: 할 일
→ 수신 객체 책임: 완료되지 않은 할 일에 대하여 날짜, 시간, 내용 데이터 전달
3) 생성 등
•
메세지: 새로운 할 일 생성
→ 메세지 수신 객체: 목록
→ 객체 책임: 새로운 할 일의 날짜, 시간, 내용, 카테고리 이름을 토대로 할 일 생성
→ 도움 요청
: 새로운 할 일의 날짜, 시간, 내용에, 카테고리 이름에 대한 데이터 입력을 Console 객체에게 요청
•
메시지: 할 일 데이터 입력
→ 메시지 수신 객체: 콘솔
→ 객체 책임: 새로운 할 일에 대한 날짜, 시간, 내용, 카테고리 이름을 입력
•
메시지: 카테고리 데이터 요청
→ 메시지 수신 객체: 카테고리
→ 객체 책임: 전달 받은 카테고리 이름에 맞는 카테고리 객체의 데이터 전달
•
수정 및 삭제는 생성과 유사하므로 생략
다. Interface
1) Main Idea
•
‘할 일' 객체를 추상화한 표현인 Task로 명명
•
사용자를 한 명으로 전제할 경우, User 객체 및 List 객체는 불필요하므로 제거
•
목록 객체의 역할을 ‘할 일'에 대한 서비스 로직으로 일반화할 수 있으므로 TaskService 객체로 정의
•
‘할 일' 전반에 대해 데이터 관리 객체로 TaskRepository 정의
•
콘솔 객체의 경우 객체 간 협력 관계에서 중요도가 낮다고 판단하여 인터페이스에서 제거
2) Interface with Tables
3) Interface in Code
라. 구현
1) Entities
•
Task: Code in GitHub
•
Category: Code in GitHub