영화관 예약 시스템의 개념 모델링

개요

개념 모델링의 연습으로 모 영화관의 표 예약 시스템의 개념 모델을 만들어 보았다

생성 방법

입장권 발행 시 사이트의 흐름도에 따라 순서대로 모델링을 진행하다

사이트 흐름도

영화관 선택

작품 선택과 일정

좌석 선택

구매자 정보 입력

선택표의 종류

구매수속

릴리즈 번호

1단계: 영화관 선택

체인점이 같은 시스템을 사용하는 전제에서 각자의 영화관이라는 개념이 필요하다.

plantuml

@startuml

hide circle
hide methods
skinparam shadowing false

class 映画館_theater{
  名前
}

@enduml

2단계: 작품 선택과 일정

시간표 화면에서 보고 싶은 작품과 일정을 고르다.화면에서.

작품명

극장호

시작 시간

상영 시간

대화 상자.극장은 극장이 여러 개 있기 때문에 어느 극장에서 상영할지를 선택하기도 한다.
여기서 고민하는 포인트는 다음과 같다.

여기서 선택한'대상'은 무엇입니까

극장이라는 개념은 영화관이나 방에 분배해야 한다
첫 번째로 선택한 대상, 여기는 사건입니다.시간 계획 중 하나를 어떻게 말해야 할지 고민 중입니다. 결론은 Google 달력의 영어 버전에서 각 계획이 이벤트로 간주되는 곳에서 나온 것입니다.(겸사겸사 일본어 버전에서는 예약이라고 부른다.)
두 번째 극장의 개념은 영화관은 극장이고 영화관 안의 각 방은 방이다.원래 나는 지역 전문가에게 물어보면서 이 방면의 토론을 추진하는 것이 가장 좋다고 생각한다.

plantuml

@startuml

hide circle
hide methods
skinparam shadowing false

class 映画館_theater{
  名前
}
class プログラム_program{
  名前
  時間
}
class ルーム_room{
  名前
}
class イベント_event{
  開始時刻
}
class 予約_reservation{}

映画館_theater "1"--"1..*" ルーム_room
ルーム_room "1"--"*" イベント_event
プログラム_program "1"--"*" イベント_event
イベント_event "1"--"*" 予約_reservation

@enduml

이 작품과 관련해서는 영화관에서 생중계되는 등 영화 이외의 활동도 있어 프로그램의 일부로 바라본다.
또 주문한 단위는 예약이라고 한다.

3단계: 좌석 선택

선택한 방의 좌석표를 표시합니다. 상한선까지 선택할 수 있습니다.
여기 자리는요.

고급 의자(선택비용 필요)

2인용 좌석(여러 사람이 앉을 수 있음)

의 종류.좌석이 최대 인원(용량)인 셈이다.

plantuml

@startuml

hide circle
hide methods
skinparam shadowing false

class 映画館_theater{
  名前
}
class ルーム_room{
  名前
}
class プログラム_program{
  名前
  時間
}
class 座席型_seatType{
  名前
  最大人数
  追加料金
}
class 座席_seat{
  座標
}
class イベント_event{
  開始時刻
}
class 予約_reservation{}

class 知識 {
  1予約あたりの最大席数
}

映画館_theater "1"--"1..*" ルーム_room
ルーム_room "1"--"*" イベント_event
座席_seat "*"-"1" ルーム_room
プログラム_program "1"--"*" イベント_event
イベント_event "1"--"*" 予約_reservation
座席型_seatType "1"--"*" 座席_seat
座席_seat "*"--"*" 予約_reservation

note "[制約] 1予約あたりの座席数は\n「1予約あたりの最大席数」以下" as N1

プログラム_program -[hidden]l ルーム_room

@enduml

좌석의 좌표는 화면의 어디에 표시해야 하는지에 대한 정보로서 어떤 형태로 들어가는지 알 수 없다.

4단계: 구매자의 정보 입력

구매자 이름 등을 입력하는 화면입니다.참고한 사이트라면 다음과 같은 두 가지 경로가 있다. ① 로그인 후 가입한 사용자 정보를 사용하고 ② 계좌를 발행하지 않고 주문한다. 그러나 이러한 처리는 통용되고 흥미가 없기 때문에 생략한다.

plantuml

@startuml

hide circle
hide methods
skinparam shadowing false

class 映画館_theater{
  名前
}
class ルーム_room{
  名前
}
class プログラム_program{
  名前
  時間
}
class 座席型_seatType{
  名前
  最大人数
  追加料金
}
class 座席_seat{
  座標
}
class イベント_event{
  開始時刻
}
class 予約_reservation{}

class 知識 {
  1予約あたりの最大席数
}

class ユーザー_user {
  氏名
  電話番号
  メールアドレス
}

映画館_theater "1"--"1..*" ルーム_room
ルーム_room "1"--"*" イベント_event
座席_seat "*"-"1" ルーム_room
プログラム_program "1"--"*" イベント_event
イベント_event "1"--"*" 予約_reservation
座席型_seatType "1"--"*" 座席_seat
座席_seat "*"--"*" 予約_reservation
予約_reservation "*"-"1" ユーザー_user

note "[制約] 1予約あたりの座席数は\n「1予約あたりの最大席数」以下" as N1

プログラム_program -[hidden]l ルーム_room

@enduml

5단계:선택표의 종류

선택표의 종류(어른, 아이, 노인 등).선택할 수 있는 것은 지정된 좌석에 대응하는 선택 방법뿐이다.

plantuml

@startuml

hide circle
hide methods
skinparam shadowing false

class 映画館_theater{
  名前
}
class ルーム_room{
  名前
}
class プログラム_program{
  名前
  時間
}
class 座席型_seatType{
  名前
  最大人数
}
class 座席_seat{
  座標
}
class イベント_event{
  開始時刻
}
class 予約_reservation{}

class 知識 {
  1予約あたりの最大席数
}

class ユーザー_user {
  氏名
  電話番号
  メールアドレス
}

class チケット型_ticketType{
  料金
}

note "[制約] 1予約あたりの座席数は\n「1予約あたりの最大席数」以下" as N1
note "[制約] 予約と紐づく座席の型に\n対応したチケットのみ紐付け可能" as N2

チケット型_ticketType "*"-"*" 座席型_seatType
映画館_theater "1"--"1..*" ルーム_room
ルーム_room "1"--"*" イベント_event
座席_seat "*"-"1" ルーム_room
プログラム_program "1"--"*" イベント_event
イベント_event "1"--"*" 予約_reservation
座席型_seatType "1"--"*" 座席_seat
座席_seat "*"--"*" 予約_reservation
予約_reservation "*"-"1" ユーザー_user
チケット型_ticketType "1"--"*" チケット_ticket
チケット_ticket "*"--"1" 予約_reservation
座席_seat "*"--"1" チケット_ticket
座席_seat..N1
チケット_ticket..N2

プログラム_program -[hidden]l ルーム_room

@enduml

좌석에 추가 요금을 설정했지만 좌석형을

추가 설정을 하고 싶은데 자세한 상황을 모르면 간단히 하는 게 좋을 것 같아서 비용을 취합

6단계: 구매 수속

각종 결제 방법으로 비용을 지불하다.여기도 통용되기 때문에 간소화하여 모델링을 진행한다.

plantuml

@startuml

hide circle
hide methods
skinparam shadowing false

class 映画館_theater{
  名前
}
class ルーム_room{
  名前
}
class プログラム_program{
  名前
  時間
}
class 座席型_seatType{
  名前
  最大人数
}
class 座席_seat{
  座標
}
class イベント_event{
  開始時刻
}
class 予約_reservation{
  /支払済
}

class 知識 {
  1予約あたりの最大席数
}

class ユーザー_user {
  氏名
  電話番号
  メールアドレス
}

class チケット型_ticketType{
  料金
}

class 決済{
}

note "[制約] 1予約あたりの座席数は\n「1予約あたりの最大席数」以下" as N1
note "[制約] 予約と紐づく座席の型に\n対応したチケットのみ紐付け可能" as N2

チケット型_ticketType "*"-"*" 座席型_seatType
映画館_theater "1"--"1..*" ルーム_room
ルーム_room "1"--"*" イベント_event
座席_seat "*"-"1" ルーム_room
プログラム_program "1"--"*" イベント_event
イベント_event "1"--"*" 予約_reservation
座席型_seatType "1"--"*" 座席_seat
座席_seat "*"--"*" 予約_reservation
予約_reservation "*"-"1" ユーザー_user
チケット型_ticketType "1"--"*" チケット_ticket
チケット_ticket "*"--"1" 予約_reservation
座席_seat "*"--"1" チケット_ticket
座席_seat..N1
チケット_ticket..N2

予約_reservation "0..1"--"1" 決済

プログラム_program -[hidden]l ルーム_room

@enduml

간소화하기 어려워 예약에 결제 완료라는 도출 속성을 표시하는 표지

단계 7: 발행 발행 번호

결제가 끝나면 발행번호가 나옵니다.

plantuml

@startuml

hide circle
hide methods
skinparam shadowing false

class 映画館_theater{
  名前
}
class ルーム_room{
  名前
}
class プログラム_program{
  名前
  時間
}
class 座席型_seatType{
  名前
  最大人数
}
class 座席_seat{
  座標
}
class イベント_event{
  開始時刻
}
class 予約_reservation{
  /支払済
  /? 発券番号
}

class 知識 {
  1予約あたりの最大席数
}

class ユーザー_user {
  氏名
  電話番号
  メールアドレス
}

class チケット型_ticketType{
  料金
}

class 決済{
}

note "[制約] 1予約あたりの座席数は\n「1予約あたりの最大席数」以下" as N1
note "[制約] 予約と紐づく座席の型に\n対応したチケットのみ紐付け可能" as N2
note "[導出？] 発券番号は予約自体を指す or 新規発行する" as N3

チケット型_ticketType "*"-"*" 座席型_seatType
映画館_theater "1"--"1..*" ルーム_room
ルーム_room "1"--"*" イベント_event
座席_seat "*"-"1" ルーム_room
プログラム_program "1"--"*" イベント_event
イベント_event "1"--"*" 予約_reservation
座席型_seatType "1"--"*" 座席_seat
座席_seat "*"--"*" 予約_reservation
予約_reservation "*"-"1" ユーザー_user
チケット型_ticketType "1"--"*" チケット_ticket
チケット_ticket "*"--"1" 予約_reservation
座席_seat "*"--"1" チケット_ticket
座席_seat..N1
チケット_ticket..N2
予約_reservation..N3

予約_reservation "0..1"--"1" 決済

プログラム_program -[hidden]l ルーム_room

@enduml

발행번호가 새로 발행됐는지 아니면 예약 실체 자체라는 명칭(ID)이 바뀌었는지 판단할 수 없기 때문[導出？].그리고 저는 개념적으로 중요한 역할이 없으면 각 실체의 ID를 생략해서 씁니다.

깨끗이 정리하다

개념을 대충 적어 놓고 좀 정리하다

plantuml

@startuml

hide circle
hide methods
skinparam shadowing false

package 映画館知識レベル <<Cloud>>{
  class 映画館_theater
  class ルーム_room
  class 座席型_seatType
  class 座席_seat
}

package イベント知識レベル <<Cloud>>{
  class イベント_event
  class プログラム_program
}

package チケット販売知識レベル <<Cloud>>{
  class チケット型_ticketType
  class 知識
}


class 映画館_theater{
  名前
}
class ルーム_room{
  名前
}
class プログラム_program{
  名前
  時間
}
class 座席型_seatType{
  名前
  最大人数
}
class 座席_seat{
  座標
}
class イベント_event{
  開始時刻
}
class 予約_reservation{
  /支払済
  /? 発券番号
}

class 知識 {
  1予約あたりの最大席数
}

class ユーザー_user {
  氏名
  電話番号
  メールアドレス
}

class チケット型_ticketType{
  料金
}

class 決済{
}

チケット型_ticketType "*"-"*" 座席型_seatType
映画館_theater "1"--"1..*" ルーム_room
ルーム_room "1"--"*" イベント_event
座席_seat "*"-"1" ルーム_room
プログラム_program "1"--"*" イベント_event
イベント_event "1"--"*" 予約_reservation
座席型_seatType "1"--"*" 座席_seat
座席_seat "*"--"*" 予約_reservation
予約_reservation "*"-"1" ユーザー_user
チケット型_ticketType "1"--"*" チケット_ticket
チケット_ticket "*"--"1" 予約_reservation
座席_seat "*"--"1" チケット_ticket

予約_reservation "0..1"--"1" 決済

@enduml

이용자의 예약을 통해 제작된 실체(운용수준)는 표, 예약, 이용자, 결제 4개로 쉽게 알 수 있다.
물론 완벽한 개념도는 아니다.예컨대

표는 행사와 좌석의 조합으로 정의하는 게 좋을까요?

비용은 표로만 결정할 수 있습니까?

취소·결제 실패 상황도 고려하면 어떻게 될까?

등등, 생각해보면 끝이 없지만, 실제 개발에서는 범위를 나눠 진행하는 경우가 많기 때문에 범위를 끊지 않으면 개념이 계속 확대되기 때문에 끝이 없는 것은 당연하다.

총결산

개념 모델링 연습으로 표 예약 시스템의 개념도를 써 보았다.일본어에서'예정'이라고 많이 부르는 개념을'이벤트'라고 부르는 것은 제 개인적인 가장 큰 수확입니다.