정교화는 다음과 같은 초기 일련의 반복이다.
대부분의 요구사항이 발견되고 안정화
대부분의 사용 사례 및 기타 요구사항을 일련의 작업장을 통해 상세하게 작성
주요 위험(기술이나 비즈니스 가치)의 경감이나 퇴직
코어 아키텍쳐 요소가 구현되고 입증
정교화 단계
elaboration을 한문장으로 하자면:
핵심 아키텍처를 구축하고, 고위험 요소를 해결하며, 대부분의 요구사항을 정의하고, 전체 일정과 리소스를 추정합니다.
정교화는 두 번에서 네 번의 반복으로 구성된다. 각 반복은 팀 규모가 큰 경우를 제외하고는 두 번에서 여섯 번의 반복으로 구성하는 것이 좋다.
각 iteration은 종료 날짜가 고정된 타임박스입니다.
각 iteration이 끝나면 최종 시스템의 안정적이고 테스트된 제품 품질 부분이 출시되어야 합니다.
정교화 과정에서 architecturally 중요한 것은?
"wide and shallow"한 디자인과 구현
기존 구성요소를 통합하는 것
Planning the Next Iteration
요구사항 및 반복사항을 risk, coverage 및 criticality로 구성합니다.
risk
기술적 복잡성과 노력 또는 가용성의 불확실성과 같은 기타 요인을 모두 포함한다.
coverage
이는 시스템의 모든 주요 부분이 초기 반복에서 적어도 관리된다는 것을 의미합니다.
즉, 많은 구성 요소에 걸쳐 "넓고 얕은" 구현이 가능할 수 있습니다.
criticality
비즈니스 가치가 높은 기능을 말합니다.
정교화 과정 속 산출물
도메인 모델 :
도메인 개념의 시각화이며, 도메인 엔터티의 정적 정보 모델과 유사
디자인 모델 :
논리적 설계를 설명하는 일련의 도표
소프트웨어 클래스 다이어그램, 개체 상호 작용 다이어그램, 패키지 다이어그램 등이 포함
소프트웨어 아키텍쳐 다큐먼트 :
설계에서 주요 아키텍처 문제와 해결 방법을 요약한 학습 보조 도구
data model
test model
implementation model
use-case storyboards
ui prototypes
System Sequence Diagrams
시스템 동작은 시스템이 어떻게 하는지는 설명하지 않고 무엇을 하는지 묘사하는 것이다.
시스템 시퀀스 다이어그램은 외부 행위자가 SuD에 생성하는 이벤트, 순서 및 시스템 간 이벤트를 설명하여 유스케이스의 특정 시나리오에 대한 시스템 동작을 포착한다.
(SSD는 우리가 시스템을 마치 블랙박스처럼 다루게 해준다)
SSD 외부액터와 시스템간의 상호작용을 강조한다.
Stimulus(자극)
=> 시스템 이벤트는 시스템에 대한 외부 행위자에 의해 생성된 외부 이벤트입니다.
Response(반응)
=> 시스템 작동은 시스템 이벤트에 응답하여 실행되는 시스템의 작동입니다.
위 두가지는 같은 이름으로 표현된다.
uml class icon
함수를 설명한다.
+ 는 public
# 은 protected
- 는 private
도메인 모델은 problem 도메인의 현실 객체를 개념적인 클래스로 시각화하는 것이다.
Conceptual 모델, 도메인 객체 모델, 분석 객체 모델이라고 불린다.
현실을 우리가 이해할 수 있는 모습으로 묘사한느거지 디자인(설계)이 아니다.
객체지향 분석에서 가장 중요한 산출물이다.
UP(통합 프로세스)에서 도메인 모델은 함수가 정의되지 않은 클래스다이어그램으로 표현된다.
- domain objects 또는 conceptual classes
- conceptual classes 사이에 relationship
- conceptual classes의 attributes
conceptual classes(도메인 모델이라고도 함)
3가지 구성요소
Symbol - conceptual class의 단어나 이미지
Intention - conceptual class 정의
Extension - conceptual class가 적용되는 일련의 예
개념 클래스 찾는 방법
1. 개념 클래스 카테고리 리스트 활용
2. 명사 어구 찾기
이게 개념클래스가 맞는지 잘모르겠으면 그냥 세분화 하는 방향으로
(개념 클래스 카테고리 리스트)
(명사 구문 찾는 방식)
도메인 모델 그릴 때 기억할 점
개념 클래스 및 속성 이름을 지정할 때 problem 도메인의 어휘를 사용합니다.
관련 없는 기능은 제외합니다.
개념 클래스와 속성을 혼동하지 마십시오.
(기준은 무엇일까? -> 아이덴티티 ex>ID 이다. 아이덴티티가 있어 유니크하면 클래스 없으면 속성이다. 예시로 공항은 클래스일까? 속성일까 ID로 구분되기 때문에 클래스이다.)
항목이나 용역에 대한 설명은 그러한 항목이나 용역의 예가 현재 존재하는 것과는 무관해야 한다.
이들이 설명하는 항목의 인스턴스를 삭제하면 삭제된 항목과 정보의 잘못된 연결로 인해 유지관리해야 할 정보가 손실됩니다.
예시> 공책 안에 공책의 가격 정보가 속성으로 있다고 하자 공책이 상점에서 다 팔리면 공책의 가격 정보는 어디서 찾는가?
