Search
Duplicate
🤖

Coffee Order Design with OOP

1. 유스케이스

주문 이벤트 요구사항
주문 완료 요구사
UseCase

2. 도메인 모델

본 실습의 경우 도메인 모델의 틀은 멘탈 모델에 기반하지 않고 요구사항에 언급된 핵심 객체를 기반으로 함

3. 책임-주도 설계

가. 시스템 기능

주문 받은 음료의 제작 과정 및 완성 여부를 출력하라
→ 음료의 제작은 비동기적으로 이루어질 것

나. 시스템 기능 → 객체의 책임

주문 받은 음료의 제작 과정 및 완성 여부를 출력하라
→ 메세지가 너무 커서 책임질 객체를 찾기가 어려움

다. 메세지 분할

메세지 1: 음료 주문을 받아라
→ 메세지 수신 객체: Cashier
→ 객체 책임: WaitingQueue에 Order 추가
메세지 2: 음료를 제작하라
→ 메세지 수신 객체: Barista
→ 객체 책임: Order에 따라 음료 제작(한 바리스타는 동시에 2개의 음료 제작 가능)
메세지 3: 음료의 제작 과정을 출력하라
→ 메세지 수신 객체: Log
→ 객체 책임: Order 객체를 받아서, 음료 제작을 시작할 때와 완성할 때 관련 로그를 출력함
메세지 4: 고객별로 음료의 제작상태를 출력하라
→ 메세지 수신 객체: DashBoard
→ 객체 책임: 고객별로 음료 주문상태를 주기적(1초)으로 출력한다
→ 협력 객체: Oder
→ 객체 책임: DashBoard에 특정 고객의 Order의 상태에 대해 전달
ex) A고객님의 음료는주문 대기중입니다
메세지 4-1: 주문 상태를 업데이트하라
→ 메세지 수신 객체: Order
→ 객체 책임: Order의 상태가 대기중/제작중/완료인지 구분하여 상태를 갱신한다
→ WaitingQueue에 있으면 대기, Barista가 제작 시작하면 제작 중, 완료하면 완료
메세지 5: 주문 대기표를 확인하라
→ 메세지 수신 객체: Manager
→ 객체 책임: 주문 대기표에 주문이 있는지 확인
메세지 6: 주문을 할당하라
→ 메세지 수신 객체: Manager
→ 객체 책임: 주문 대기표에 주문이 있다면, 비어있는 바리스타에게 주문을 할당

4. 인터페이스 설계