Software-Engineering

Sequence Diagram 설명

• 위 사진의 시퀀스 다이어그램은 카페 키오스크 시스템에서 손님이 메뉴를 선택하고 결제하는 과정을 자동화한 시스템입니다. 결제 완료 후 주방 모니터에 주문 정보를 전달하여 준비 상태를 확인할 수 있습니다.

구성요소

• 액터(Actor) : 시스템과 상호작용하는 외부 요소로 손님이 해당됩니다.
• 객체(Object) : 시스템 내부의 컴포넌트로, 키오스크, 결제 시스템, 주방 모니터가 객체로 표현됩니다.
• 활성박스(Activation Box) : 객체가 활성 상태에서 실행 중임을 나타내는 직사각형 박스입니다.
• 생명주기(Lifeline) : 객체의 존재와 상호작용이 시간에 따라 어떻게 이어지는지를 나타내는 수직적점선으로 객체의 생명주기를 표현하며 위에서 아래로 시간이 흐릅니다.
• 메시지(Message) : 서로 다른 객체간의 상호작용 혹은 의사소통 통신을 정의하는 요소로 여기서는 메뉴 선택, 결제 요청, 주문 정보 전달 등이 있습니다.

단계적 설명

1. 메뉴 선택 및 주문 생성 : 손님이 키오스크에서 메뉴를 선택하고 주문을 생성합니다.
2. 주문 내역 확인 및 결제 요청 : 키오스크가 주문 내역을 손님에게 보여주고 결제 요청을 진행합니다.
3. 결제 진행 : 키오스크가 결제 대행사와 통신하여 결제를 시도합니다.
4. 결제 승인 결과 전달 : 이때 결제 대행사와 통신하여 결제가 성공했는지 실패했는지 여부에 따라 나뉩니다. 이때 결제가 성공했을 경우 키오스크는 주방 모니터에 주문 정보를 출력하고, 손님에게 영수증을 출력해줍니다. 하지만 실패했을 경우 키오스크는 손님에게 결제가 실패했다는 알림을 출력해줍니다.

Sequence Diagram을 기반으로 구현 설명

Entity

1. Menu Entity

• 메뉴 정보를 담고 있는 엔티티로 메뉴 이름, 가격, 기본키(Id)를 포함하고 있습니다.

2. Order Entity

• 주문 정보를 담고 있는 엔티티로 여러 메뉴에 하나의 주문 정보가 선택될 수 있기 때문에 ManyToOne의 관계를 맺고 있습니다.(하나의 메뉴만 선택 가능함)
• 주문 시간, 수량, 총 가격, 주문상태를 포함하고 있습니다.
• 이때 주문이 생성되었을때 초기에는 음료를 만들어야하기 때문에 준비상태로 만들기위한 생성자를 생성하였다.

3. Kitchen Entity

• 주방 모니터 정보를 담고 있는 엔티티로 하나의 주문에는 주방 모니터의 하나의 주문만 매핑될 수 있어 OneToOne 관계를 맺습니다. (한 주문은 하나의 모니터에만 출력가능)
• 현재 주문상태에 대한 정보를 포함하고 있습니다.
• Order과 마찬가지로 초기에 바로 주문자에게 제공할 수 없기 때문에 결제완료 상태로 만들기 위한 생성자를 생성하였습니다.

4. OrderStatus

• 주문상태 정보에 값으로 두개의 상태만 해당이 가능하기때문에(Paid(결제완료), Completed(준비완료)) 열거형(Enum)으로 선언하였습니다.

5. KitchenStatus

• 주방상태 정보에 대한 값으로 두개의 상태만 해당이 가능하기때문에(Waiting(준비중), Ready(준비완료)) 열거형(Enum)으로 선언하였습니다.

Service

1. MenuService

• Menu 테이블에 저장된 모든 객체를 다 조회하는 기능으로 메뉴 엔티티의 기본 키, 메뉴 이름, 메뉴 가격 총 3개의 대한 정보를 출력합니다.

2. OrderService

• 사용자가 결제를 요청했을 때 성공적으로 결제가 완료됬을 경우 사용자가 선택한 메뉴, 개수 정보를 가지고 총합이 얼마인지 계산후 Order 테이블에 저장합니다.
• 이때 주문이 완료된 후 바로 주방 모니터에 출력하기 위해서 Kitchen 테이블에 저장하게 했습니다.

3. KitchenService

• 주방에서 조리되는 시간을 설정하여 주문완료후 2분 뒤에 준비완료된 상태로 만들기 위해 스케쥴러를 사용했습니다.
• 이때 주문테이블도 완료된 상태여야 하기 때문에 같이 갱신을 해주었습니다.

DTO

1. FindByAllMenu

• Menu 테이블에서 따로 필요한 내용만 골라서 출력하기 위해서 DTO를 만들었습니다.

2. OrderRequestDTO

• 결제 요청을 할때 결제 고유번호, 주문 번호, 메뉴 정보가 필요하기 때문에 따로 DTO를 만들었습니다.

Controller

1. MenuController

결과화면

• MenuService 클래스의 findByAllMenu 메서드를 호출하는 api 엔드포인트 구조를 만들었습니다. /api/findByAllMenu 엔드포인트로 Get요청을 보내면 로컬에 저장되어 있는 Menu 테이블의 모든 정보가 출력됩니다.

2. OrderController

• OrderService 클래스의 createOrder 메서드를 호출하는 api 엔드포인트로 사용자가 결제를 하고 성공했을 경우 /api/paymentOrder 엔드포인트에 Post요청을 보내 Order테이블과 Kitchen 테이블에 사용자가 선택한 메뉴의 정보가 저장이됩니다.

3. HomeController

• 결제 페이지를 만들기위해서 localhost:8080 루트 경로에 index.html을 렌더링하기위한 컨트롤러입니다.

  결과화면

  

  

  

config

1. MenuInitializer

• 초기에 메뉴 데이터들을 DB에 넣어주기 위한 클래스로 spring boot를 실행할때 유효성검사를 체크한 후 데이터가 없을경우 넣어준다.

HOW TO USE🚀

1. git Repository 주소를 복사한다.

2. 따로 빈 디렉토리에 origin을 추가하여 pull을 받는다.

git init
git remote add origin https://github.com/KII1ua/Software-Engineering.git
git pull origin main

3. application.yml 수정

• 경로 demo/src/main/resources

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/kiosk
    username: {로컬에 설치되어 있는 mysql username 입력}
    password: {mysql username에 대응하는 password 입력}
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    hibernate:
      ddl-auto: update
    properties:
      hibernate:
        show_sql: true
        format_sql: true
        jdbc:
          time_zone: Asia/Seoul
    #    database-platform:

4. MySql에 접속하여 kiosk 데이터베이스 생성

create database kiosk;

5. demo 폴더로 이동하여 클린 빌드

./gradlew clean build

ㅁ

• 위 사진이 나오면 빌드 완료

6. build/libs 폴더로 이동하여 jar 파일 실행

java -jar demo-0.0.1-SNAPSHOT.jar

• 프로그램이 실행되면 이후 localhost:8080 으로 접속하여 테스트 결제 진행

---

샘플 코드 모듈 평가 결과

• 응집도 평가

  1. MenuService 클래스는 메뉴 엔티티 조회에만 책임을 지고 있기 때문에 MenuService에 대해서는 응집도가 높다고 평가할 수 있다고 생각합니다.
  2. 하지만 OrderService KitchenService 클래스는 서로가 하나씩 일부분의 역할을 수행하기 때문에 MenuService 클래스 만큼의 응집도가 높다고 평가할 수 없다고 생각합니다.

• 결합도 평가

  1. 모델의 결합도를 낮추기 위해서 하나의 파일만 사용하지 않고 여러 파일을 나눠서 각 기능들을 분리하였습니다. 따라서 결합도는 낮다고 평가할 수 있다고 생각합니다.
  2. 응집도와 마찬가지로 Order 객체와 Kitchen 객체의 의존성은 어느정도 있다고 생각합니다. 따라서 이 부분은 적절한 결합도라고 생각합니다.