Plannin the Next Iteration
- 계획과 프로젝트 관리 매우 중요
- 요구 사항과 반복의 구성 기준
- 위험
- 기술적 복잡도와 그 외 요소(ex. 사용 편의성의 불확실성)를 포함
- 범위
- 초기 반복시 시스템의 주요 부분을 모두 검토해야 함(많은 컴포넌트에 대해 넓고 얕은 구현)
- 중대성
- 높은 비즈니스 가치를 지닌 기능을 언급
- 위험
- 각 반복 전에 순위 결정
- 새로운 요구사항이나 통찰력 반영 -> 계획이란 변경 가능!
Iteration 1 Requirements
Emphasis on Fundamental OOA/D 기술인 Assigning Resposibility에 중점 -> 설계가 들어가기 때문에 누구에게 책임을 할당할지!!
-
반복 1 요구사항 범위
- "판매 처리" 구현
- "시스템 시작" 구현: 초기화
- 대단하거나 복잡한 것이 아니라 단순한 happy path 시나리오 위주로 설계, 구현
-
지원할 UI도 설계, 구현
Domain Model
- 읽는 순서: 큰 것 부터 차례대로
- 작성 순서 == 읽는 순서
- 도메인 모델은?
- 한 문제 영역에서 의미있고 개념적인 클래스들을 표현한 것
- 소프트웨어 요소가 아닌 실세계 개념의 표현
- 도메인 모델은 중요한 인공물
- 개발에는 풍부한 개념적 클래스 집합을 식별하는 작업이 수반되고 객체지향 분석의 중심이 됨
- 도메인을 개별적 개념 클래스 또는 객체로 분해하는 시각적 표현임
- 주목할만한 추상화의 시각적 사전
Domain Model: UML Notation
- 메서드가 없는 클래스 다이어그램 집합을 사용해 표현함
- 포함하는 것
- 도메인 객체 또는 개념 클래스
- 개념 클래스 간 연관관계
- 개념 클래스의 속성
What is the difference between ERD and DM?
ERD와는 90%이상 동일하며 DM과는 메서드를 제외한 것과 동일함
A Domain Model is not a Software Artifact
도메인 모델을 생성하는 이유
- 적용 업무를 잘 몰라서 (세부적으로 애매한 것을 확실하게 만들어줌)
- 도메인 계층을 생성하기 위해
- 도메인 계층: 소프트웨어 객체들 중 비즈니스 로직에 관련된 객체들만 모아놓을 계층
- 시각적인 용어 정리
- 소프트웨어 객체의 이름을 업무 영역의 용어와 유사하게 작명
- 나중에 어떻게 사용되는가?
객체 지향적 모델링의 표현상의 차이 줄이기
- 현실에서 사용하는 이름 그대로 사용
개념적 클래스 식별 방법
방법1. 기존 모델을 재사용하거나 수정
- 예) analysis pattern
- 검색해보면 엄청 나옴
- 검색 능력
- 어떤 모델이 좋은가를 판단할 수 있는 능력
- 본인이 작성할 능력이 있는 사람만이 판단 가능
- 검색한다 사용한다가 나오면 무조건 거를 것 (GIGO)
- 이를 수정 및 개선할 수 있는 능력
- 본인이 작성할 능력이 있는 사람만이 판단 가능
- 고수준의 지식은 타인의 결과를 통해 획득
방법2. 분류 리스트의 사용
- 우선순위대로 나열
방법3. 명사구의 식별
- usecase에서 명사 또는 명사구를 식별
- 기계적 작업 아님
- 개념적 클래스를 정답이 없다. 사람마다 다를 수 있다!
속성과 클래스의 구별 방법
- 규칙
- 실세계에서 숫자나 텍스트로 생각할 수 없는 것이라면 아마 개념적 클래스일 것임 (단순x -> domain class)
- 만약 공간을 차지한다면 거의 개념적 클래스일 것임 (domain class)
- 만약 의심된다면? 그것도 또한 도메인(concept, domain)임
- Store는 조직, 공간을 차지하는 무언가
- Destination은 공간을 차지함
명세 클래스
- 개념 클래스를 설명
- 아이템에 대한 정보를 기록한 클래스
- 아이템의 모든 인스턴스가 품절되었을 때, 그 설명은 남아있음
- 아이템의 각 인스턴스에서 기술적인 정보를 기록하는 것의 중복을 피해라
- 도메인 모델은 고려중인 이전 및 현재의 시나리오에 제한됨 -> 반복
- 이후에 도메인을 발견하면 그것을 추가함
- 도메인을 과도하게 지정하는 것이 좋음
- 과소 지정된 것보단 많은 세분화된 개념 클래스를!
- 데이터 모델링(ERD)와 달리 아래와 같은 개념이 포함되는 것이 유효함
- 속성이 존재하지 않음
- 또는 정보 제공 역할 보다는 순전히 행위 역할을 함 (정보성이 있는 것, ERD에 그려질만한 것)
