Broker project - Three Tier에 대한 이해

Three Tier에 대한 이해.

Three Tier는 Client, Server, DBTier가 있는 구조입니다.

우리는 DBTier를 MySQL로 구성했고 mybroker스키마에 customerRec, StockRec 테이블을 만들었습니다.
그리고 CustomerRec과 StockRec테이블간의 M:N관계를 해소하기 위해 중간에 Association table을 만들었습니다.

VO클래스들과 예외, business logic을 작성했습니다.

클라이언트에는 GUI와
Client는 요청을 하고 Server를 거쳐 DBServer로 요청이 도달한 다음. 다시 응답이 Server를 거쳐 Client로 돌아오게 됩니다.

Client는 요청을 하고 출력도 담당하게 됩니다. 그렇게 때문에 통신에서 마지막 지점이 DB라고 착각하지 말아야 합니다.

Client사이드에서는 business logic과 똑같은 메소드의 선언형식을 같는 Protocol이라는 메소드를 추가했습니다. 그러나 구현부는 조금 달라지게 됩니다.

그리고 물리적으로 Server와 분리되어 있기 때문에 Socket통신을 위한 알고리즘을 추가해야 합니다.

Server side에서 Protocol Handler라는 통신담당 클래스를 만들었습니다. 해당 클래스는 ServerSocket를 가지며 무한 루프를 돌면서 클라이언트가 보내는 socket을 보낼 때까지 기다립니다.

클라이언트는 소켓을 가지고 ServerSocket과 연결을 하고 Server는 이 소켓으로 JuryThread라는 스레드를 가지게 됩니다.

이 JuryThread가 Server의 비즈니스 로직을 사용하고 이 비즈니스 로직에 와서야 비로소 DBServer에 접속하게 되는 것입니다.

Stream은 소켓으로부터 나오게 됩니다. 스트림에서는 어떤 메소드가 호출되고 어떤 값이 담기게 될까요?

스트림에서는 가는 것 오는 것 전부 생각해야 합니다. 객체를 보내는 것과 받는 것 두개를 따로 만들 필요는 없습니다.

하나로 만들 수도 있는데 갈 때 정보를 담는 공간을 만들고 결과 값을 담는 정보를 담는 공간도 동시에 만들어주면 됩니다.

client에서 Protocol클래스에서 add메소드가 호출된다고 합시다.

사용자적 입장에서 기능 정의하기
- 시나리오를 작성해야합니다.
- 시나리오를 가장 쉽게 작성할 수 있는 초기 단계가 Use Case Diagram입니다.
- SRS(요구사항 명세서)는 가장 나중에 나오게 됩니다.
- SRS이후에는 작업이 방사형으로 이루어집니다. 각자가 맡은 역할에 따라 DBModeling을 할 수도 있고 UI를 만들 수도 있습니다.
DBModeling은
1. 개념설계
2. 논리설계
3. 물리설계
  로 이루어져 있습니다.
  
  개념설계에서는 Entity 추출이 가장 중요합니다. 그리고 추가로 기본키를 설정하는 작업이 진행됩니다.
  
  논리설계에서는 기본키외의 나머지 속성들을 정의하는 것이 가장 중요합니다. 속성을 상시 수정하며 촘촘하고 디테일하게 설정하는 것이 중요합니다. 실제 업무에서는 굉장히 정교하고 방대합니다.
  
  논리설계가 촘촘하고 정확하게 이루어지려면 사용자의 입장에서 기능이 눈에 보이듯이 정말 잘 나와야 합니다.
VO작성
Business logic 작성