1. 개념모델
1.1 구현보단 인터페이스와 관계가 깊다.
1.2 도메인 모델 : NOT 데이터 모델. UP. 목표는 실세계의 표기이다.
1.3 역할 별로 객체를 분류시킬 수 있다.
1.4 유비쿼터스 = 어디서든지 통용될 수 있다 = 비즈니스 기반.
1.5 정적 다이어그램 :
1.5.1 클래스 다이어그램 - 클래스간의 관계, 인터페이스와 클래스와의 관계 등.
구성 = Property(분석단계 추출) + Operation(설계단계 추출)
!!.좋은 클래스? 1)책임 2)역할 3)협력
Property : attribute(컬럼) + association(연결선. 비즈니스 or 시스템적으로 가치가 있을
때 사용)
CRC : 담당자A를 찾아서 담당자A가 요구하는 업무의 담당자B를 다시 찾는 방식의 반복.
NOTE : 일관성을 위해, 일관성에 문제가 생긴경우 주석다는 것처럼 사용하자.
의존성 : 설계시점에서 표현하기 힘들다. A->B이고, B->C이더라도 A->C라고 볼 수 없
다.(이행관계없음)
집합과 복합의 차이는 결합도의 차이. public A a(B b) 이런게 강결합.
의존성과 위임의 차이. 위임은 추상클래스(즉 다형성)
Provides(제공자 인터페이스. List등) VS Required(요청자 인터페이스. Order 등)
연관관계에서 연관보단 역할이 중요하다. 연관은 너무 복잡해 질 우려가 있다.
용어 : 리얼라이제이션(언어의 임플리먼트)
!!. 되도록이면 사람은 나누지 않는다.
1.5.2 객체 다이어그램 - 클래스 다이어그램 설명용(=예제 = 스냅샷).
파티복합구조 : 트리를 재귀적으로 표현한다.
UML과 소프트웨어개발(3일차)_1.0.pdf
1차UseCase분석.txt
경기정보관리시스템.zip
Test.eap