Domain Models

• Visual representation of conceptual classes or real-world objects in a domain of interest

Domain Models must have

• Object(객체)
• attribute(속성)
• relationship(관계)

👌 model : 일상생활에서 모델은 무언가 "특징"을 보여주는 것 -> 항상 **강조하고 싶은 것**이 있다. 
-> 개발에서의 model은 고객이 풀고 싶어하는 강조 요소 

---

객체란 ? 책임의 문제 ( 문제를 해결하는데에서의 책임 )
따라서 객체를 찾을 때는 Role(역할)을 찾아야 함

Rich picture -> Domain Model

Domain model이 필요한 이유

어떤 것을 원하는지 제대로 표현

Domain model 그리는 방법

• 네모 박스 그리기
• 박스를 두 칸 or 세 칸으로 나누기
• 협력 관계 그리기

---> 상세한 표기 기법을 알고 있어야 하지만, 확실하게 쓰면 안된다.
첫 번째 상세한 것 : ROLE
두 번째 상세한 것 : Association Multiplicity

Role

객체와 객체가 만났을 때 역할은 계속 유동적으로 변화
따라서 특별히 역할을 지정할 필요가 없을 때는 지정 안함

Association Multiplicity

개수를 표현

Line 2개 이상을 그리기 위해서는 Point 여러 개가 필요하다
여러 사람이 여러 파일을 접근할 수 있다.

No Attributes as Foreign Keys

Model Attribute Quantities and Units

• 화폐 단위 같은 단위는 통일해야 함

Anaysis

Use case

domain model이 domain 분석이라고 한다면 객체 지향에서의 분석 결과 use case 이다.
요구사항 분석 -> domain 분석 ->
객체지향이라면 -> Use case 분석

Definition

• Stories of using a system to meet goals
• A mechanism to help keep the goal simple and understand for all stakeholdes(권한을 가진 사람)
• Used to describe functional requirements
  non functional requirements : 품질 요구사항, 프로그램적으로 구현할 수 없는 것

최종 !!
목표를 달성하기 위해서 액터가 어떻게 시스탬을 사용해야 하는지 묘사하는 성공과 실패 이야기를 모아둔 것이다.

우리가 만들어둔 system으로 고객의 목적을 달성하기 위한 story가 Use case
이름 뿐만 아니라 관리 번호가 붙기 시작

Use case는 Use diagram과 다르다. Use case는 글이다. !! not 그림

Elementary Buiness Process

비지니스 이벤트에 대한 응답으로 한 사람에 의해서 한 장소에서 한 순간에 수행된 업무

• 측정 가능한비지니스 가치를 더하고 데이터를 일관된 상태로 유지
• Use task와 유사한 용어로도 사용 but 좀 더 쪼개진 의미

Actor, Goal, and Use case(유즈 케이스를 만드는 단위)

• Actor : Something with behavior( action을 일으킬 수 있는 사람, 동작 유발자)
• Actor는 자신의 Goal/Need를 이루기 위해 시스템을 사용하며 이들 각 경우가 Use case이다.
  1) 사용자의 절차를 찾는다.
  2) 각 목표에 대한 사용 사례를 정의하다.
• Senario : A specific sequence(Usecase 끼리의 시퀀스가 아니라 유즈 케이스 내에서의 sequence) of actions and interaction between acttors and the system under discusion
  Ex ) Dealer의 Goal ? 거래 기록을 남기고 보고하고 싶겠지 ?
  기록 적는 것, 기록 보고하는 것으로 두 개의 Usecase를 만들 수 있음

How to

1) actor 찾기 + system boundary(커다란 네모)를 선정
actor는 system 밖에 있음 (사람만을 의미하는 것이 아님, system 밖에서 뭔가를 유발시킨다면 actor)
ex) 시스템 밖에 있는 시계가 시간을 system에 알리면 system이 동작을 함(동작 유발) 그러면 시계는 actor
BUT
system 안에 시계를 구현하게 된다면 이거는 actor가 아님
DB도 시스템 밖에 있다면 actor이다.

2) 시스템을 사용하여 사용자의 목적을 달성하는 Primary Actor를 알아낸다.

3) 각 Primary Actor의 사용자 목적을 알아내고, 이를 EBP Guide line에 따라 가장 높은 수준(좀 더 포괄적인 개념)의 User Goal/Need로 도출한다.

4) User Goal/Need를 만족하는 Use case를 도출