기능·정적·동적 모델

취소 버튼 하나에도 서로 다른 질문이 숨어 있다

앞 절의 공방은 누가 언제 어떤 예약을 취소할 수 있는지 정했다. 이제 개발자가 그 약속을 만들 차례다. “고객이 예약을 취소한다”만 그림으로 옮기면 충분할까? 취소할 예약이 누구의 것인지, 같은 수업의 예약마다 다른 정책을 어떻게 기억할지, 이미 취소한 예약에 같은 요청이 다시 오면 무엇을 할지가 아직 남는다.

한 그림에 모두 욱여넣지 않는다. 무엇을 제공하는가, 어떤 정보와 관계를 유지하는가, 어떤 순서와 조건으로 바뀌는가를 나눠 본 다음 같은 예약번호로 다시 맞춘다. 그림을 많이 그리는 것이 목적이 아니라, 한 관점에서는 보이지 않던 모순을 다른 관점에서 발견하는 것이 목적이다.

모델은 목적에 필요한 성질을 남긴 표현이고, 관점은 누구의 어떤 질문을 어떤 규칙으로 볼지 정하는 방법이었다(모델·관점·아키텍처 결정). 같은 시스템의 여러 표현은 공통 이름·경계·사실이 일치해야 했다. 이제 그 원칙을 공방의 실제 기능과 정보, 시간에 따른 행동에 적용한다.

요구공학은 요구의 근거를 찾고 분석·명세·확인하며 추적과 변경을 관리하는 활동이었다(요구 도출·분석·명세·검증·추적). 공방에서는 소유자·취소 기한·반복 요청·정책 버전을 구별했고, 작성한 시험 연결과 실제 시험 통과도 구별했다. 이번 모델은 그 요구를 바꾸는 새 약속이 아니라, 실현할 구조와 행동을 검토하는 설계 표현이다.

상태는 같은 다음 입력에 대한 행동을 달라지게 할 수 있는 현재의 기억이었다(입력·처리·출력·상태·피드백). 이미 취소되었는지에 따라 같은 요청의 결과가 달라지는 공방도 이 원리를 따른다. 뒤에서는 이 기억과 변화 조건을 따로 읽을 수 있게 나타낸다.

기능·구조·행동을 나누되 같은 시스템을 설명한다

기능·정적·동적 모델링은 시스템이 제공할 기능, 유지할 요소와 관계, 시간과 사건에 따른 행동을 목적에 맞는 표현으로 나누고 서로 일관되게 설계하는 활동이다. 기능을 보는 질문은 “고객이 무엇을 얻는가”이고, 정적인 구조를 보는 질문은 “어떤 대상이 어떤 관계로 존재하는가”이며, 동적인 행동을 보는 질문은 “어떤 사건 뒤에 누가 무엇을 하고 상태가 어떻게 달라지는가”다.

이 구분은 모든 표준 그림을 서로 겹치지 않는 세 상자에 넣는 공식 분류표가 아니다. 예를 들어 활동의 흐름은 기능이 수행되는 과정을 상세히 보여 주면서 동적 행동도 표현한다. 여기서는 질문을 나누는 학습 틀로 사용하며, 특정 표준의 그림 분류와 혼동하지 않는다.

쉽게 말하면: 같은 예약에 세 번 질문한다

먼저 고객에게 “무엇을 할 수 있나요?”라고 묻는다. 다음에는 장부를 펼쳐 “어떤 예약이 어느 고객·수업·취소 정책과 연결되나요?”라고 묻는다. 마지막에는 시간을 따라 “취소 요청이 왔을 때 지금 상태와 기한에 따라 어떤 결과를 내나요?”라고 묻는다.

예약번호 R501은 세 질문에서 같은 예약이어야 한다. 기능 설명에서는 취소를 허용하면서 행동 설명에서는 무조건 거부하거나, 구조 설명에서는 필요한 정책 버전을 기억하지 않는다면 세 표현을 모두 작성했어도 설계는 맞지 않는다.

한 약속에서 나와 다시 한 결과로 만난다

화살표의 방향과 조건을 따라 연결을 읽습니다.

화살표는 설계의 추적·대조 관계다. 실제 자료 전송이나 실행 순서를 뜻하지 않는다. 기능·관계·행동이 같은 예약과 정책 버전을 설명해야 한다.

위 도식의 선은 모델 사이에 데이터가 실제 전송된다는 뜻이 아니다. 같은 요구를 서로 다른 질문으로 검토하고 결과를 맞추는 관계다. 어느 모델에서 새 정보가 필요해지면 다른 모델에도 그 정보의 위치와 의미가 있는지 확인한다.

계속 사용할 두 예약과 변하지 않는 가정

앞 절의 가상 정책을 그대로 사용한다. 모든 시각은 한국 표준시이며 수업 W101은 9월 20일 14시에 시작한다. v1은 시작 24시간 전까지, v2는 시작 12시간 전까지 일반 취소를 허용하고 경계 시각 자체를 포함한다. v2는 9월 15일 00시 이상에 새로 확정한 예약에만 적용한다.

두 예약은 같은 수업을 가리키지만 같은 예약은 아니다. 이 절의 작은 자료에서만 R501의 고객을 C01, R502의 고객을 C02로 정한다. 이는 관계를 보여 주기 위한 새 가상 식별자이지, 앞 절에 없던 개인정보나 실제 고객 정보가 아니다. 예약 취소와 외부 결제의 환불 완료는 여전히 별개이며, 환불·좌석 복구의 상세 구현을 이 모델만으로 완료했다고 하지 않는다.

1. 어떤 기능을 제공할지부터 보인다

UML(Unified Modeling Language, 통합 모델링 언어)은 시스템의 구조와 행동을 일정한 의미와 표기 규칙으로 표현하는 모델링 언어다. OMG(Object Management Group)는 UML 등의 모델링 명세를 발행하는 표준화 단체다. 이 절은 OMG의 UML 2.5.1에서 필요한 부분을 표기 기준으로 삼는다. UML 자체가 개발 일정·역할·검토 절차를 모두 정해 주는 개발 방법론은 아니다.

공방의 설계를 읽기 위해 모든 UML 그림을 한 번에 배울 필요는 없다. 먼저 고객과 시스템 사이의 기능을 보고, 이어 대상 사이 관계와 요청 처리의 순서를 읽는다. 이 교재의 그림은 의미를 읽기 위한 자체 구성이다. 유스케이스·클래스·시퀀스·상태의 필요한 기호를 구별하되, 생략한 동작까지 완전한 UML 모델로 검증했다고 주장하지 않는다. 실제 표준 기호는 등장하는 곳에서 뜻과 함께 설명한다.

액터는 사람이 아니라 역할이고, 유스케이스는 버튼이 아니다

액터(actor)는 모델링 대상과 상호작용하는 외부 참여자의 역할이다. 고객처럼 사람이 맡을 수도 있고 다른 시스템이 맡을 수도 있다. 한 사람이 고객과 운영자 역할을 모두 맡더라도 역할별 책임은 구분하며, 시스템 내부의 예약 저장 기능을 외부 액터로 그리지 않는다.

유스케이스(use case)는 대상 시스템이 수행하여 액터나 다른 이해관계자에게 가치 있는 관찰 가능한 결과를 제공하는 행동의 명세다. 공방의 “내 예약 취소”는 유스케이스 후보지만 “파란 버튼 누르기”는 화면 조작이다. 결과가 무엇인지 모르면 버튼 위치를 바꿀 때 기능의 뜻도 함께 흔들린다. 유스케이스는 정상 결과뿐 아니라 기한 경과·반복·권한 오류 같은 변형과 실패 행동도 포함할 수 있다.

시스템 밖의 역할과 안의 제공 기능을 나눈다

화살표의 방향과 조건을 따라 연결을 읽습니다.

고객 역할은 하나다. 두 실선은 참여 관계이며 조회 다음에 취소한다는 순서가 아니다. 외부 환불은 이 좁은 모델의 범위에 포함하지 않았다.

타원은 유스케이스이며, 사각 경계는 모델링하는 대상을 나타낸다. 액터와 유스케이스를 잇는 실선은 참여 관계이지, “조회 다음에 취소한다”는 실행 순서가 아니다. 표준에서는 액터를 사람 모양 기호 또는 «actor»를 붙인 사각형 등으로 나타낼 수 있다. 여기서는 고객 역할을 한 번 표시하고 두 기능에 연결했다. 같은 역할의 두 참여 관계이지 두 종류의 고객을 만든 것이 아니다.

환불까지 함께 모델링한다면 외부 결제 시스템과 상호작용하는 기능도 별도로 보아야 한다. 지금 그림은 예약 조회·취소 범위만 보인 것이므로, 그림에 환불 액터가 없다는 이유로 실제 환불 요구가 사라진 것은 아니다.

타원 안의 이름을 읽을 수 있는 행동으로 펼친다

“내 예약 취소”라는 이름 옆에 다음 설명을 붙인다. 대상은 공방 예약 시스템, 시작 입력은 고객의 예약번호와 취소 요청, 판단 시각은 서버가 요청을 받은 시각이다. 고객의 신원은 확인되어 있다고 가정하되, 그 고객이 해당 예약의 소유자인지는 매번 검사한다.

1. 예약과 소유자를 확인한다. 본인 소유가 아니면 상태를 바꾸지 않고 접근을 거부한다.
2. 본인의 이미 취소된 예약이면 다시 상태를 바꾸지 않고 기존 결과를 돌려준다.
3. 본인의 확정 예약이면 그 예약의 정책 버전에서 취소 마감을 구한다.
4. 요청 시각이 마감 이하이면 예약을 취소로 바꾸고 결과를 돌려준다. 마감을 지났으면 확정을 유지하고 기한 경과와 운영자 연락 경로를 알린다.

이 순서에서는 이미 취소된 예약의 재요청을 새 취소로 판정하지 않는다. 그래서 R501을 기한 안에 취소한 뒤 마감 후 같은 요청을 보내도 “새 취소 기한 초과”가 아니라 기존 결과를 받는다. 요청 설명을 이 정도로 펼쳐야 뒤에서 만들 구조·시간 모델과 대조할 판단이 생긴다.

이 예시는 조회가 성공한 기존 예약 중 상태가 확정·취소인 경우만 다룬다. 없는 예약번호, 저장소 조회 실패, 그 밖의 예약 상태는 이 예시에서 다루지 않지만, 실제 시스템에서는 결과·안내·상태 보존을 추가로 정해야 한다. 확인되지 않은 경우에 성공을 돌려주거나 취소로 바꾸는 행동은 이 모델에 넣지 않는다.

시작 가정과 끝의 약속을 분리한다

사전조건(precondition)은 해당 행동을 시작할 때 성립한다고 요구하는 조건이다. 이 설명의 “고객 신원 확인 완료”가 그 예다. 사전조건으로 가정한 신원 확인의 내부 절차는 생략할 수 있지만, 그 사실만으로 임의 예약에 대한 소유권까지 보장되지는 않는다.

사후조건(postcondition)은 해당 행동이 끝날 때 성립하도록 명세한 조건이다. 정상 취소의 사후조건은 대상 예약이 취소 상태이고 결과가 제공되는 것이다. 거부 경로는 예약 상태를 바꾸지 않는다는 별도의 결과 조건을 갖는다. 사전조건·사후조건을 적는 것은 약속을 명확히 하는 일이며, 구현이 약속을 지킨다는 실행 증거는 아니다.

include와 extend는 다음 순서를 그리는 화살표가 아니다

포함 관계(include)는 포함하는 유스케이스의 행동 안에 별도로 정의한 유스케이스의 행동을 삽입하는 관계다. 여러 기능에 공통된 행동을 따로 묶어 재사용할 때 쓴다. 표준의 점선 열린 화살표는 포함하는 쪽에서 포함되는 쪽으로 향하고 «include»라고 적는다. 단순히 앞뒤로 실행한다는 뜻이 아니며, 기본 유스케이스의 특정 삽입 위치에서 필요한 행동을 나타낸다.

확장 관계(extend)는 기본 유스케이스의 지정된 위치에 추가 행동을 넣는 관계다. 확장점(extension point)은 그 추가 행동을 넣을 수 있도록 기본 유스케이스 안에 지정한 위치다. 기본 유스케이스는 확장 없이도 의미가 완결되어야 한다. 확장의 점선 열린 화살표는 추가하는 쪽에서 기본 쪽으로 향하고 «extend»라고 적으며, 추가할 조건과 확장점을 함께 확인한다.

공방에서 여러 조회 기능이 같은 “조회 가능 예약 확인” 행동을 사용하도록 따로 설계했다면 포함 후보가 된다. “내 예약 취소”의 안내 단계에서 고객이 추가 도움말을 요청할 때만 별도 도움말을 끼우도록 설계했다면 확장 후보가 된다. 두 경우 모두 이 관계 설명을 위한 가상 설계 대안이며, 앞 절의 요구가 두 유스케이스를 새로 승인했다는 뜻은 아니다.

정상은 include, 오류는 extend라고 외우면 틀린다

기한 초과 거부는 “내 예약 취소”의 오류 흐름으로 본문에 직접 적을 수 있다. 모든 오류를 별도 확장 유스케이스로 만들 필요가 없다. 확장을 선택하려면 기본 기능이 혼자 의미를 갖는지, 어디에서 어떤 조건으로 추가 행동을 넣는지 설명해야 한다.

반대로 신원 확인을 사전조건으로 둔 모델에서 같은 신원 확인을 무조건 포함 유스케이스로 다시 그리면 시작 가정과 내부 행동이 어긋날 수 있다. 이 모델에서 실행할 일인지, 이미 성립한다고 가정한 일인지 먼저 정한다. 포함·확장 관계 자체를 그리지 않고 읽기 쉬운 기본·예외 흐름으로 충분히 설명하는 선택도 가능하다.

정보가 들어와 바뀌는 길은 자료흐름도로 본다

자료흐름도(DFD, Data Flow Diagram)는 자료가 어디에서 들어와 어떤 처리를 거쳐 어디로 가는지 나타내는 모델이다. 유스케이스가 외부 역할이 얻을 결과를 중심으로 보면, 자료흐름도는 그 결과를 만들 정보의 이동·변환을 중심으로 본다. UML 유스케이스의 다른 표기법이 아니라 구조적 분석에서 사용하는 별도의 표현이다.

자료흐름도의 프로세스(process)는 입력 자료를 처리하여 출력 자료를 만드는 기능 단위다. 이 뜻은 운영체제가 실행하는 프로세스와 구별한다. 자료흐름(data flow)은 프로세스·저장소·외부 개체 사이에 전달되는 자료를 나타내는 방향 있는 연결이다. 예를 들어 취소 요청을 받아 취소 판정을 만드는 프로세스에는 그 두 자료 이름을 화살표에 적는다. 1, 2 같은 프로세스 번호는 구별할 이름이며 실행 우선순위가 아니다.

네 종류의 요소를 먼저 구별한다

자료저장소(data store)는 프로세스가 나중에 읽거나 갱신할 자료를 보관하는 논리적 장소다. 지금은 예약·수업·정책 자료를 함께 가리킬 수 있으며 특정 데이터베이스 제품이나 테이블 하나를 확정한 뜻이 아니다. 외부 개체(external entity)는 선택한 모델의 경계 밖에서 자료를 보내거나 받는 사람·조직·시스템 등의 요소다. 회사 밖이어야 하는 것은 아니며, 같은 시스템의 다른 부분도 이번에 선택한 경계 밖이면 외부 개체가 된다.

자료흐름도에는 여러 도형 표기 계열이 있으므로 위 문자 범례를 어느 한 표준의 정확한 도형이라고 하지 않는다. 어떤 도형을 선택해도 기능·자료·보관·외부 역할의 뜻을 섞지 않아야 한다. 고객이 저장소의 값을 곧바로 바꾸는 선 대신, 변경 자료를 검사·처리하는 프로세스를 드러내야 책임이 보인다.

맥락도에서는 선택한 전체 기능을 하나로 둔다

자료흐름도의 맥락도(context diagram)는 모델링할 전체 범위를 프로세스 하나로 나타내고 경계 밖과 주고받는 자료를 보이는 그림이다. 아래에서는 전체 공방 시스템이 아니라 그 안의 예약 취소 처리부만 모델링한다. 앞에서 신원을 확인한 요청 접수부가 이 경계 밖에서 자료를 보낸다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

선 이름은 이동 자료다. 입력은 예약번호·확인한 고객번호·서버 접수시각을 포함한다. 전체 공방 시스템이 아닌 취소 처리부의 맥락도이며 내부 예약·수업·정책 자료는 숨겨져 있다.

확인된 취소 요청은 예약번호, 확인한 고객번호, 서버 접수시각의 묶음이다. 고객이 임의로 보낸 고객번호를 신원 확인의 증거로 믿는다는 뜻이 아니다. 취소 처리 결과는 요청한 예약의 취소·거부·기존 결과 중 해당 결과다. 예약·수업·정책 자료는 이번 처리부 안에 이미 준비되어 있고, 그 자료를 처음 등록하는 다른 업무는 이 좁은 그림의 범위 밖이라고 가정한다.

안을 펼쳐도 밖과 약속한 자료는 같아야 한다

자료흐름도의 수준 분해는 상위 프로세스가 하는 일을 더 작은 프로세스와 그 사이 자료흐름으로 펼치는 것이다. 같은 취소 처리부를 아래 두 기능으로 나눴다. 여기서는 필요한 자료의 읽기와 허용된 변경의 저장이 성공한 유한 예이며, 저장 실패의 결과를 새로 확정한 모델은 아니다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

프로세스 번호는 실행 우선순위가 아니다. 분해 전후 외부 자료는 같은 확인된 요청과 처리 결과다. 허용된 새 취소만 변경 자료를 내며 거부·이미 취소는 새 상태 변경을 내지 않는다. 읽기·저장의 성공을 가정한 부분 모델이다.

결과안에는 예약번호, 판정한 결과 종류, 변경이 필요한지와 변경할 상태를 담는다. 1번은 소유자·현재 상태·예약별 정책·접수시각을 사용하고, 2번은 허용된 새 취소일 때만 상태를 바꾼 뒤 결과를 구성한다. 거부와 이미 취소된 예약에는 새 취소 변경 자료를 내지 않는다. 같은 이름을 반복한 저장소와 접수부는 서로 다른 대상이 아니다.

번호가 1·2라는 사실만으로 선후가 정해지는 것은 아니다. 2번이 사용할 결과안을 1번이 만든다는 자료 의존은 보이지만, 분기 선택·동시 실행·대기 규칙을 모두 읽을 수 있는 제어 순서도는 아니다. 그런 판단은 뒤의 활동·상태 모델로 보완한다.

균형은 화살표 수뿐 아니라 자료의 뜻을 맞추는 일이다

자료흐름도의 균형(balancing)은 상위 프로세스와 그것을 분해한 하위 그림이 경계 밖과 주고받는 입력·출력 자료를 일치시키는 원칙이다. 안에서 새 중간 자료와 저장소가 드러날 수 있지만, 밖과의 약속이 몰래 바뀌어서는 안 된다.

두 그림 모두 입력 선이 하나라도 하위 그림에서 접수시각을 빼면 기한을 판정할 수 없고 의미의 균형이 깨진다. 하위 그림에만 고객의 환불계좌 입력이 추가되어도 상위 경계에 없던 약속이 생긴다. 정말 필요한 새 입력이면 상위 요구·경계부터 확인하여 관련 수준을 함께 고친다. 선 개수만 같게 맞추는 것은 이 검사를 대신하지 못한다.

출력의 근거를 뒤로 따라가면 빠진 입력이 드러난다

처리 기능에 들어오는 자료가 있는데 아무 결과나 갱신도 없으면 무엇을 했는지 빠진 것이다. 반대로 읽는 자료나 입력 없이 취소 가능 여부를 내면 판정의 근거가 없다. 선은 있어도 고객 소유자나 적용 정책이 빠져 있으면 이 공방의 정당한 판정 자료가 되지 못한다.

특히 현재 그림의 출력에 환불 완료를 넣으면 결제·환불 결과를 읽거나 처리하지 않았는데 완료를 약속하게 된다. 예약 취소 결과와 외부 환불 완료는 다르므로 그 출력을 추가하지 않는다. 자료흐름도에서 발견한 입력 누락은 정보 관계 모델의 빠진 속성과 연결하고, 시간·분기 오류는 활동·상태 모델과 연결한다. 그림별 검토가 서로 다른 결함을 찾는 이유다.

기능모델 설계: 요구를 관찰 가능한 결과로 끝까지 연결한다

기능모델은 시스템이 제공할 행동과 결과를 드러내는 표현이다. 설계할 때에는 먼저 대상 시스템의 경계와 외부 역할을 정하고, 요구별로 시작 입력·정상 결과·거부 결과를 적는다. 공방에서는 예약 취소 요구 R-CAN-01부터 R-CAN-04까지를 “내 예약 취소”의 소유권 검사, 정상 취소, 기한 초과, 반복 결과로 연결한다.

그다음 읽는 사람이 판단할 수 있을 만큼 흐름과 조건을 펼친다. 타원의 개수를 늘리는 대신 마감의 포함 여부, 기존 취소의 재요청, 상태 불변 조건을 실제 예약으로 대조한다. 공통 행동을 재사용할 이유가 있을 때만 포함을, 기본 행동의 특정 위치에 독립적인 추가 행동을 넣을 이유가 있을 때만 확장을 선택한다.

정보의 변환·입력 누락을 볼 필요가 있으면 자료흐름도로 경계, 처리, 이동 자료와 저장소를 나타낸다. 맥락도를 수준별로 펼칠 때에는 외부 입력·출력의 의미를 유지하고, 산출할 결과에 필요한 자료가 실제 들어오는지 확인한다. 유스케이스의 고객 가치와 자료흐름도의 내부 변환 기능은 서로 보완하는 다른 질문이다.

마지막에는 기능이 읽거나 바꿀 정보가 어디에 있는지, 시간·상태 조건이 다른 모델과 맞는지, 요구와 시험 조건으로 돌아갈 수 있는지 확인한다. 정상 경로만 남기거나 내부 저장 기능을 고객 가치와 같은 수준의 기능으로 섞으면 빠진 책임을 발견하기 어렵다. 결과물은 그림뿐 아니라 조건·예외·범위·근거 요구가 함께 있는 기능 명세이며, 아직 실행하지 않은 시험을 완료로 표시하지 않는다.

객체는 식별 가능한 상태와 그 상태를 다루는 연산을 함께 가졌고, 조합은 다른 객체의 기능을 부품처럼 사용하게 했었다(모듈·캡슐화·객체·인터페이스). “한 종류인가”와 “가지고 사용하는가”도 구별했다. 이제 그 대상들을 같은 종류로 묶고 대상 사이 관계를 그림과 실제 값으로 맞춰 본다.

2. 어떤 대상과 관계를 유지해야 기능을 만들 수 있을까

클래스(class)는 객체들을 공통 구조와 행동의 특징으로 분류하고 그 특징을 명세하는 모델 요소다. 예약은 클래스이고 R501과 R502는 그 분류에 속하는 서로 다른 객체다. W101은 수업 클래스의 객체다. 영어 class에 수업이라는 일상 뜻이 있더라도, 여기서 클래스라는 모델 용어와 공방 수업은 다른 층위다.

클래스 다이어그램(class diagram)은 클래스와 그 특징·관계를 나타내는 구조 그림이다. 예약번호·확정 시각·상태가 필요하다는 구조를 먼저 정하면 각 예약에 실제 값이 무엇이어야 하는지 묻게 된다. 그림이 정적이라는 말은 값이 영원히 변하지 않는다는 뜻이 아니라, 이번 그림의 초점이 실행 순서보다 구조와 관계에 있다는 뜻이다.

이름 아래에는 보관할 값과 제공할 동작을 적는다

클래스의 속성(attribute)은 그 클래스의 객체가 가질 값이나 값의 모음을 명세하는 특징이다. 예약의 확정시각과 상태가 그 예다. 연산(operation)은 호출할 수 있는 행동의 이름·입력·결과 같은 계약을 명세하는 특징이다. 예약의 취소판정(요청시각)은 연산 후보이며, 이름을 적은 것만으로 내부 알고리즘이나 저장 코드를 구현한 것은 아니다.

예약 클래스의 이름·속성·연산 칸은 세 가지 연관 그림에 함께 표시했다. 단독 상자를 반복하지 않고, 그 값과 연산이 어떤 관계와 연결되는지 이어서 읽는다.

아래 예약 상자의 첫 칸은 클래스 이름, 다음 칸은 속성, 마지막 칸은 연산이다. : 뒤는 허용할 값의 종류를 나타내며, 중괄호는 이 예에서 선택할 상태 값을 읽기 쉽게 적은 것이다. 표준은 여러 칸과 생략 표현을 허용하므로 “클래스는 반드시 세 칸을 모두 그린다”는 규칙으로 외우지 않는다. 여기서는 필요한 세 부분만 보여 주고 접근 권한 같은 추가 표기는 쓰지 않는다.

선 끝의 숫자는 반대쪽 하나를 고정하고 읽는다

연관(association)은 정해진 종류의 대상들 사이에 존재할 수 있는 의미 있는 연결을 명세한 관계다. 예약과 고객 사이 선은 예약에 고객이 연결된다는 뜻이다. 다중성(multiplicity)은 관계의 한쪽에서 허용되는 값의 개수를 하한과 상한으로 제한한 것이다. 1은 정확히 하나, 0..1은 없거나 하나, 0..*는 없거나 여러 개, 1..*는 하나 이상을 뜻한다. *는 무한 개를 실제 보관한다는 뜻이 아니라 명세에서 상한을 제한하지 않았다는 뜻이다.

세 가지 연관 그림의 고객–예약 실선에서 고객 쪽은 1, 예약 쪽은 0..*다. 아래 문장처럼 어느 쪽 대상 하나를 고정했는지부터 읽는다.

예약 하나를 고정하고 고객 쪽의 1을 읽으면 고객이 정확히 하나다. 고객 하나를 고정하고 예약 쪽의 0..*를 읽으면 예약이 없어도 되고 여러 개여도 된다. 다중성은 현재 자료의 건수가 아니라 허용 규칙이다. 현재 C01의 예약이 한 건이라고 고객 쪽에서 예약이 항상 한 건뿐이라는 규칙으로 바꾸면 안 된다. 표준 연관 그림에 다중성이 아예 생략되어 있으면 숫자를 임의로 1이라고 채우지 않는다.

두 예약을 실제로 놓아 보면 빠진 정책이 드러난다

이 절의 취소 대상은 확정된 적 있는 예약이다. 각 예약은 고객 하나, 수업 하나, 적용한 정책 버전 하나에 연결한다고 가정한다. 예약하지 않은 고객과 아직 예약이 없는 수업·정책 버전도 존재할 수 있다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

연관 실선은 실행 순서·상속·합성이 아니다. 예약 하나의 반대쪽 값은 각각 1이며 고객·수업·정책 쪽에서 예약은 0..*다. R501과 R502의 실제 정책 v1·v2는 아래 객체 값 표로 대조한다.

예약 클래스는 한 번만 표시하고 세 연관을 연결했다. 예약마다 고객·수업·정책이 각각 하나씩 있다는 뜻이며, 세 연관이 예약 세 종류를 만든 것은 아니다.

이 표는 모델을 검사할 가상 시점의 값이다. 공방의 “한 수업 정원 8명”은 예약 이력을 무조건 8건까지만 보관한다는 뜻이 아니다. 취소 이력을 남기면 같은 수업의 과거 예약은 8건을 넘을 수 있다. 실제 좌석을 차지하는 예약의 수가 정원을 넘지 않아야 한다는 별도 규칙과 보관할 이력 수를 구분해야 한다.

종류의 그림은 실제 값 한 장으로 검사한다

객체 다이어그램(object diagram)은 특정 시점·사례의 객체와 그 값·연결을 보여 주는 구조 그림이다. 클래스의 가능한 구조에 R501·R502라는 구체적인 대상을 놓은 것이 앞 표다. 표준의 객체 표현에서는 R501 : 예약 같은 이름과 분류를 밑줄 친 이름 칸으로 나타낼 수 있고, 값은 이름이 있는 칸에 적는다. 이 교재의 표는 밑줄 도형을 대신한 읽기 자료다.

모델 제약(constraint)은 모델 요소나 연결이 만족해야 할 조건을 명시한 것이다. 다중성만으로 표현하기 어려운 “좌석을 차지하는 예약 수는 정원 이하”나 “예약에 정한 정책 버전을 과거 계약과 다르게 바꾸지 않는다”를 문장으로 덧붙일 수 있다. UML은 제약을 중괄호 안의 설명으로 표시할 수 있다. 특정 수식 언어를 쓰지 않더라도 대상·판정 시점·조건을 분명히 해야 한다.

정책을 수업에만 하나 달면 과거 약속이 바뀐다

잘못된 대안은 W101 → 현재 취소 정책 v2만 두고 모든 예약에 그 값을 적용하는 것이다. 그러면 R501도 12시간 전까지 취소할 수 있다고 판정하여, 앞 절에서 유지하기로 한 v1의 24시간 기한과 달라진다. 예약에 정책 버전 연결이 없으면 기능 설명에 “예약별 정책 적용”을 써 두어도 실제 판단에 필요한 구조가 없다.

반대로 객체마다 마감 시각을 계산해 적었다고 해서 정책 버전 관리가 저절로 끝난 것도 아니다. 수업 시작이 바뀌면 마감을 어떻게 처리할지, 이미 확정한 약속을 어떻게 유지할지는 추가 합의가 필요한 요구다. 이 절에서는 수업 시작 시각이 고정된 예만 계산하며, 미결인 변경 정책을 표준이 정해 준 사실처럼 만들지 않는다.

일반화는 소유 관계가 아니라 종류 관계다

일반화(generalization)는 더 구체적인 분류를 더 일반적인 분류에 연결하는 관계다. 구체적인 분류의 객체는 일반적인 분류에도 속하며 그쪽의 제약도 적용받는다. 표준에서는 실선의 빈 삼각형이 일반적인 쪽을 향한다. 공방에 별도 가정으로 개인 고객과 단체 고객을 고객의 종류로 나눈다면 두 구체 클래스에서 고객 쪽으로 빈 삼각형을 그리는 후보가 된다.

하지만 예약 → 고객은 “예약이 고객의 한 종류”가 아니므로 일반화가 아니다. “고객이 예약을 가진다”는 말을 상속 화살표로 옮기면 관계를 뒤집는다. 또한 UML의 일반화 표기만으로 모든 행동 계약에서 대체 가능하다는 설계 검증까지 완료되는 것은 아니다. 앞에서 배운 상속 선택 원칙처럼, 구체 타입이 일반 타입의 사용 약속을 지킬 수 있는지 별도로 확인한다(모듈·캡슐화·객체·인터페이스).

합성의 검은 마름모에는 존재 책임이 따라온다

공유 집약(shared aggregation)은 여러 대상을 전체와 부분의 묶음으로 나타내는 연관의 한 형태다. 표준의 빈 마름모를 전체 쪽에 붙이지만, 그 세부 의미는 적용 분야와 모델 작성에 따라 달라진다. 빈 마름모 하나만 보고 특정 삭제 규칙을 단정하지 않는다.

합성(composite aggregation 또는 composition)은 전체가 부분 객체의 존재·저장에 책임을 가지며, 부분 객체가 한 시점에 최대 하나의 합성 전체에 속하는 강한 전체·부분 관계다. 전체 쪽의 채운 마름모로 표시한다. 전체 객체를 삭제하면 그때 포함된 부분 객체도 함께 삭제된다. 다만 허용된 설계에서는 삭제 전에 부분을 떼어 낼 수 있으므로 “한번 붙으면 영원히 이동할 수 없다”는 뜻은 아니다.

가상 견적 초안이 자기 견적 항목을 독점하고, 초안을 없앨 때 그때 포함된 항목도 없애는 별도 설계라면 합성 후보가 된다. 공방의 고객·예약 관계는 고객 화면에서 예약을 보여 준다는 이유만으로 합성이 되지 않는다. 특히 취소 상태 변경은 객체 자체를 삭제하는 것과 다르며, 공방 예약 이력을 지우는 동작을 암묵적으로 끼우면 안 된다. 앞 절의 객체 조합이라는 일반 설계 방법이 언제나 UML 합성의 삭제·소유 조건까지 뜻하는 것도 아니다.

선을 고를 때에는 모양보다 문장을 먼저 읽는다

마지막 줄의 의존(dependency)은 한 요소의 명세나 구현이 다른 요소에 의존하여 상대의 변경이 영향을 줄 수 있음을 나타내는 관계다. 예를 들어 취소 처리기가 정책의 판정 계약을 사용하는 것은 사용 의존으로 설명할 수 있다. 연관은 대상 사이 가능한 연결을, 의존은 사용·변경 영향을 강조하므로 점선과 실선을 무조건 장기 저장·임시 변수라는 코드 규칙 하나로 치환하지 않는다.

정적모델 설계: 기능이 필요로 하는 정보와 관계를 빠뜨리지 않는다

정적모델은 대상의 종류·특징·관계와 그 제약을 드러내는 구조 표현이다. 설계는 요구에 등장한 명사를 무조건 클래스로 만드는 작업이 아니다. 기능이 구별해 기억해야 하는 대상과 책임을 먼저 찾고, 같은 대상의 이름을 통일한 뒤 필요한 값·연산·연관·다중성을 정한다. 공방에서는 고객, 예약, 수업, 취소정책버전을 나누고 예약에 확정시각·상태와 정책 연결을 둔다.

이어 종류 관계와 소유 관계를 구별하고 존재·삭제 책임이 명확할 때만 합성을 선택한다. 관계의 개수 제약과 시각·상태 조건은 필요한 문장 제약으로 보완한다. 마지막에는 R501과 R502의 실제 값을 놓아 각 예약의 고객·수업·정책이 하나로 정해지고, 같은 수업이라도 다른 마감이 계산되는지 확인한다.

기능의 “예약별 정책”에 해당하는 연결이 없거나 취소 이력을 정원 숫자로 제한하면 구조가 요구를 실현하지 못한다. 수업의 현재 정책 하나로 모든 과거 예약을 덮거나 삭제 책임을 잘못 붙이는 실패도 실제 값과 반례로 잡는다. 결과는 예쁜 상자 목록이 아니라 기능과 행동 모델이 사용할 구조·관계·제약이며, 데이터베이스의 테이블·키·정규화·물리 배치는 앞서 배운 별도 설계 단계의 규칙에 따라 옮긴다(개념·논리 모델과 정규화: 뜻을 잃지 않고 표를 나눈다, 물리 DB 설계·인덱스·파티션).

3. 흐름에서는 선택과 기다림을 구별한다

활동 다이어그램(activity diagram)은 수행할 행동들과 그 사이의 제어·데이터 흐름을 나타내는 행동 그림이다. 액션(action)은 그 활동 안에서 수행하는 개별 행동 단위다. “예약 확인”, “정책별 기한 계산”, “결과 제공”처럼 동사로 읽히는 것이 액션 후보이며, “확정”처럼 현재 기억의 이름과 구별한다.

제어 흐름(control flow)은 어느 행동 뒤에 다른 행동이 진행할 수 있는지를 연결하는 흐름이다. 도식의 선이 예약 정보 자체를 운반하는지, 다음 행동의 진행을 정하는지를 구별한다. UML 활동은 두 종류 모두 표현할 수 있지만 아래 예는 제어 흐름만 간단히 보인다. 이름을 적은 상자는 액션, 선의 방향은 다음 진행 방향이다.

조건으로 하나를 고르고, 선택된 길만 모은다

결정 노드(decision node)는 들어온 진행을 조건에 따라 나가는 경로 중 최대 하나로 보내는 지점이다. 가드(guard)는 해당 경로를 진행할 수 있는지 판정하는 참·거짓 조건이다. 표준에서는 결정 지점을 마름모, 경로의 조건을 [조건]처럼 대괄호로 표시한다. 공방에서는 [요청시각 ≤ 마감]과 [요청시각 > 마감]을 나누면 정확한 경계 시각이 어느 쪽인지 분명하다.

병합 노드(merge node)는 여러 대안 경로를 다른 경로의 도착을 기다리지 않고 한 흐름으로 모으는 지점이다. 표준에서 결정과 병합은 같은 마름모를 쓰지만 들어오고 나가는 선의 수와 역할을 함께 읽는다. 정상·거부 중 선택된 하나가 결과 제공으로 이어질 때 병합을 쓸 수 있다. 그림상 위에 그린 조건을 먼저 검사한다는 우선순위는 UML이 자동으로 보장하지 않는다.

본인의 확정 예약이라는 한 범위에서 기한을 펼친다

아래는 타원 안의 이름을 읽을 수 있는 행동으로 펼친다에서 설명한 전체 흐름 중 소유권과 현재 상태를 확인한 뒤, 본인의 확정 예약을 처리하는 부분이다. 앞에서 처리한 타인 예약과 이미 취소한 예약의 경로를 없앤 전체 모델이 아니다.

취소 기한의 배타적 분기와 선택 병합 · 상태 따라가기

C01의 본인 예약 R501과 현재 확정 상태·정책을 확인한다. 모든 단계에서 R501·요청·마감 조건의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

본인·현재 상태·적용 정책을 확인한 흐름에서 요청 시각을 마감과 비교한다. ≤와 >는 동시에 선택되지 않는다. 선택 병합은 도착한 한 흐름을 전달하며 두 흐름을 기다리는 병렬 합류가 아니다.

이 예의 조건

• 본인·현재 상태·적용 정책을 확인한 흐름에서 요청 시각을 마감과 비교한다. ≤와 >는 동시에 선택되지 않는다. 선택 병합은 도착한 한 흐름을 전달하며 두 흐름을 기다리는 병렬 합류가 아니다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상적용 정책으로 마감	원 설명요청 시각과 같은 기준
대상기한 비교	원 설명요청 ≤ 마감?
대상취소·결과 기록	원 설명기한 이내
대상확정 유지	원 설명기한 초과·거부
대상선택 병합	원 설명원그림의 대상
대상처리 결과 응답	원 설명취소 결과 또는 거부

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결적용 정책으로 마감 → 기한 비교	원 라벨·방향비교값 / 정방향 / 실선
연결기한 비교 → 취소·결과 기록	원 라벨·방향≤ 마감 / 정방향 / 실선
연결기한 비교 → 확정 유지	원 라벨·방향> 마감 / 정방향 / 실선
연결취소·결과 기록 → 선택 병합	원 라벨·방향선택된 결과 / 정방향 / 실선
연결확정 유지 → 선택 병합	원 라벨·방향선택된 결과 / 정방향 / 실선
연결선택 병합 → 처리 결과 응답	원 라벨·방향선택된 흐름 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
현재 예약 확인 C01의 본인 예약 R501과 현재 확정 상태·정책을 확인한다.	값·보충 정보 R501: R501·확정 요청·마감 조건: 본인·적용 정책	변화·이유 대상 없이 취소 명령을 통과시키지 않는다.
마감 대조 요청 시각이 v1 마감 이내인지 대조한다.	값·보충 정보 R501: 판정 전 상태 유지 요청·마감 조건: 요청≤마감 / 초과	변화·이유 조건 판정은 실제 상태 변경과 다르다.
허용 취소·불허 유지 허용이면 취소로 바꾸고 기한이 지났으면 상태를 유지한다.	값·보충 정보 R501: 취소 / 확정 유지 요청·마감 조건: 허용 / 불허	변화·이유 취소가 허용되지 않은 요청으로 확정 예약을 취소하지 않는다.

취소 기한의 배타적 분기와 선택 병합 · 상태 따라가기

C01의 본인 예약 R501과 현재 확정 상태·정책을 확인한다. 모든 단계에서 R501·요청·마감 조건의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

본인·현재 상태·적용 정책을 확인한 흐름에서 요청 시각을 마감과 비교한다. ≤와 >는 동시에 선택되지 않는다. 선택 병합은 도착한 한 흐름을 전달하며 두 흐름을 기다리는 병렬 합류가 아니다.

이 예의 조건

• 본인·현재 상태·적용 정책을 확인한 흐름에서 요청 시각을 마감과 비교한다. ≤와 >는 동시에 선택되지 않는다. 선택 병합은 도착한 한 흐름을 전달하며 두 흐름을 기다리는 병렬 합류가 아니다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상적용 정책으로 마감	원 설명요청 시각과 같은 기준
대상기한 비교	원 설명요청 ≤ 마감?
대상취소·결과 기록	원 설명기한 이내
대상확정 유지	원 설명기한 초과·거부
대상선택 병합	원 설명원그림의 대상
대상처리 결과 응답	원 설명취소 결과 또는 거부

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결적용 정책으로 마감 → 기한 비교	원 라벨·방향비교값 / 정방향 / 실선
연결기한 비교 → 취소·결과 기록	원 라벨·방향≤ 마감 / 정방향 / 실선
연결기한 비교 → 확정 유지	원 라벨·방향> 마감 / 정방향 / 실선
연결취소·결과 기록 → 선택 병합	원 라벨·방향선택된 결과 / 정방향 / 실선
연결확정 유지 → 선택 병합	원 라벨·방향선택된 결과 / 정방향 / 실선
연결선택 병합 → 처리 결과 응답	원 라벨·방향선택된 흐름 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
현재 예약 확인 C01의 본인 예약 R501과 현재 확정 상태·정책을 확인한다.	값·보충 정보 R501: R501·확정 요청·마감 조건: 본인·적용 정책	변화·이유 대상 없이 취소 명령을 통과시키지 않는다.
마감 대조 요청 시각이 v1 마감 이내인지 대조한다.	값·보충 정보 R501: 판정 전 상태 유지 요청·마감 조건: 요청≤마감 / 초과	변화·이유 조건 판정은 실제 상태 변경과 다르다.
허용 취소·불허 유지 허용이면 취소로 바꾸고 기한이 지났으면 상태를 유지한다.	값·보충 정보 R501: 취소 / 확정 유지 요청·마감 조건: 허용 / 불허	변화·이유 취소가 허용되지 않은 요청으로 확정 예약을 취소하지 않는다.

선택된 경로를 말로 다시 확인하기

그림에서 마감 이하 경로만 도착하면 취소 결과가, 초과 경로만 도착하면 거부 결과가 선택 병합으로 이어진다. 두 경로의 도착을 함께 기다리지 않는다.

결정과 선택 병합은 마름모로 표시했다. 왼쪽과 오른쪽은 동시에 할 일이 아니다. R501의 9월 19일 14시 요청은 왼쪽, 14시 00분 01초 요청은 오른쪽이다. 기한 초과를 [요청시각 ≥ 마감]으로 쓰면 정확히 마감일 때 두 조건이 모두 참이 되므로, 그림이 있어도 요구의 경계는 틀린 것이다.

둘 다 해야 하는 일은 나누고 필요한 도착을 기다린다

포크(fork)는 하나의 흐름을 여러 개의 병행 흐름으로 나누는 지점이다. 조인(join)은 여러 흐름을 정한 조건에 맞춰 동기화하는 지점이다. 표준에서는 둘 다 막대 모양을 쓰되, 포크는 하나가 들어와 여러 개로 나가고 조인은 여러 개가 들어와 하나로 나간다. 별도 결합 조건을 정하지 않은 조인은 모든 입력 흐름의 도착이 필요하다. 병행은 같은 순간에 반드시 시작하거나 끝난다는 보장이 아니다.

흐름의 실행 의미를 읽을 때 쓰는 토큰(token)은 활동의 진행이나 운반되는 값을 설명하기 위한 의미상의 단위다. 이 말은 암호화된 인증 토큰이나 돈을 뜻하지 않는다. 제어 토큰은 진행을 설명하고, 값을 지닌 객체 토큰은 데이터 흐름을 설명한다. 그림마다 작은 토큰을 실제로 그려 넣어야 한다는 뜻도 아니다.

예를 들어 가상 “취소 안내 준비”에서 화면용 문구와 운영 기록 문구를 모두 준비한 뒤 결과를 만들기로 설계했다면 포크·조인 후보가 된다. 양쪽이 각각 1회 준비되면 기본 조인이 1회 다음 진행을 내보낼 수 있다. 한쪽만 끝났다면 아직 조건을 만족하지 못한다. 이 대안이 취소 상태 변경·좌석 복구·외부 환불을 하나의 원자적 처리로 보장한다는 뜻은 아니다.

하나만 선택한 두 길을 “둘 다 기다리기”로 모으면 끝나지 않는다

기한 이내·초과 중 하나만 선택하는 본인의 확정 예약이라는 한 범위에서 기한을 펼친다에서 제시한 흐름의 끝을 기본 조인으로 바꿔 보자. 이내 경로로 1개가 도착해도 초과 경로에는 0개다. 기본 조인은 두 입력을 모두 필요로 하므로 계속 기다린다. 선택하지 않은 경로가 느린 것이 아니라, 해당 실행에서는 아예 오지 않는 것이다.

반대로 두 작업이 모두 끝나야 하는 곳을 병합으로 바꾸면 첫 도착만으로 다음 행동이 진행할 수 있다. 선택을 모으는 병합과 필요한 병행 작업의 완료를 맞추는 조인은 같은 “합쳐지는 선”이 아니다.

시작과 끝도 구별한다. 활동의 초기 노드(initial node)는 활동 시작 시 흐름이 출발하는 지점이다. 검은 원으로 표시한다. 활동 최종 노드(activity final node)는 도착하면 해당 활동의 흐름 전체를 끝내는 지점이다. 검은 원을 바깥 원으로 둘러싼 기호를 쓴다. 흐름 최종 노드(flow final node)는 도착한 그 흐름만 끝내는 지점이다. 원 안의 X로 표시한다. 다른 작업을 남겨야 하는데 활동 전체 종료를 쓰면 남은 흐름까지 끝내므로 종료 범위를 확인한다.

4. 순서 그림은 누가 누구에게 무엇을 요청하는지 보인다

시퀀스 다이어그램(sequence diagram)은 참여자들이 주고받는 메시지와 그 발생 순서를 중심으로 상호작용을 나타내는 그림이다. 생명선(lifeline)은 상호작용에 참여하는 하나의 개별 참여자를 나타내는 모델 요소다. 위의 이름 칸에서 아래로 세로 선을 내리고, 이 절의 단순한 예에서는 위에서 아래로 그 참여자의 사건 순서를 읽는다. 이름 칸의 처리기 : 취소처리는 “취소처리라는 종류의 처리기 역할”이라는 뜻이지 모든 취소처리 클래스 전체가 동시에 실행된다는 뜻이 아니다.

메시지(message)는 참여자 사이의 호출·신호·응답 같은 통신을 모델로 나타낸 것이다. 선이 보내는 쪽에서 받는 쪽으로 향한다. 송신이 수신보다 먼저라는 관계와 각 생명선의 순서를 읽되, 아무 선으로 연결되지 않은 다른 참여자의 사건까지 그림의 세로 높이만으로 모두 선후를 결정하지 않는다. 선 사이 간격이 두 배라고 실제 지연시간도 두 배인 것은 아니다.

기다리는 호출과 조건별 대안을 표시한다

동기 메시지(synchronous message)는 호출한 행동의 완료를 기다리는 호출을 나타내는 메시지다. 비동기 메시지(asynchronous message)는 호출이나 신호를 보낸 뒤 그 완료를 기다리는 동기 호출로 묶이지 않는 메시지다. 표준에서 동기 호출은 채운 화살촉, 비동기는 열린 화살촉을 쓰고, 응답은 점선으로 표시한다. 비동기 화살표 하나가 수신 성공·처리 성공·재전송 안전을 보장하지는 않는다.

alt 결합 조각은 조건별 행동 대안 중 최대 하나를 선택하는 상호작용 영역이다. alt는 alternatives의 약식 표기이며, 프레임 안에서 [조건]별 영역을 나눠 읽는다. 예를 들어 마감 이내이면 상태를 바꾸고, 초과이면 바꾸지 않는 두 대안을 표시한다. 가능한 입력에 필요한 대안이 빠지거나 조건이 겹치지 않는지 확인해야 하며, 위쪽 영역이 항상 우선이라고 가정하지 않는다.

정상 요청의 내부 협력과 생략한 부분을 구별한다

다음은 이미 신원을 확인한 C01이 R501을 9월 19일 13시에 취소하는 가상 설계다. 취소처리는 여러 대상 사이 순서를 맡는 내부 역할이고, 예약은 자신의 연결·상태를 제공하며, 취소정책버전은 그 버전의 허용 기한을 제공한다고 책임을 나눴다. 이 이름들은 배포 서비스나 실제 파일 이름을 확정한 것이 아니다.

정상 취소에서 정책 조회 뒤 상태를 바꾼다 · 상태 따라가기

C01이 R501 취소를 요청하고 소유자·상태를 확인한다. 모든 단계에서 C01·요청·R501·정책 v1의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

C01·R501·9월 19일 13시 정상 요청의 부분 상호작용이다. W101 시작시각 조회 생명선은 생략했으며 예약–수업 관계에서 얻는다. 세로 간격은 실제 경과시간이 아니고 저장·응답 성공의 실행 증거도 아니다.

이 예의 조건

• C01의 R501 취소 요청에서 처리기가 예약의 소유자와 상태를 확인하고 v1 마감을 받은 뒤 조건을 충족한 상태 변경과 결과 응답을 진행한다.
• 같은 C01 고객, 취소처리, R501 예약, v1 취소정책버전의 정상 취소를 읽을 수 있게 협력 구간으로 나눈다. 참여자는 같은 대상이며 위에서 아래로 1 취소 R501 요청, 2 상태·소유자 확인, 3 C01·확정·v1 응답, 4 W101 시작시각으로 기한 요청, 5 마감 9월 19일 14시 응답, OPT 요청시각 마감 이하에서 6 취소로 변경과 7 취소 결과 응답, 8 고객 처리 결과 응답의 순서다. 실선은 동기 호출, 점선은 응답이며 모두 채운 화살촉이다. 세로 점선 생명선과 좁은 활성 구간을 표시하고 메시지 간 거리를 실제 시간으로 보지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
취소 요청 C01이 R501 취소를 요청하고 소유자·상태를 확인한다.	값·보충 정보 C01·요청: 취소 R501 R501·정책 v1: C01·확정·v1	변화·이유 타인의 예약이나 확정이 아닌 상태를 정상 취소 경로로 보내지 않는다.
정책 기한 조회 W101 시작 시각에 맞는 v1 마감 9/19 14시를 받는다.	값·보충 정보 C01·요청: 요청 시각 고정 R501·정책 v1: 마감 9/19 14시	변화·이유 최신 정책을 과거 예약에 임의 대입하지 않는다.
OPT 조건 요청 시각≤마감인 경우만 취소 변경을 진행한다.	값·보충 정보 C01·요청: 조건 충족 요청 R501·정책 v1: R501 취소로 변경	변화·이유 조건이 거짓이면 이 변경은 실행되지 않는다.
결과 응답 저장한 취소 결과를 C01에게 돌려준다.	값·보충 정보 C01·요청: 처리 결과 수신 R501·정책 v1: 취소 결과 확인	변화·이유 메시지 줄 간격은 실제 경과 시간을 뜻하지 않는다. 취소 결과 응답도 환불 완료를 뜻하지 않는다.

정상 취소에서 정책 조회 뒤 상태를 바꾼다 · 상태 따라가기

C01이 R501 취소를 요청하고 소유자·상태를 확인한다. 모든 단계에서 C01·요청·R501·정책 v1의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

C01·R501·9월 19일 13시 정상 요청의 부분 상호작용이다. W101 시작시각 조회 생명선은 생략했으며 예약–수업 관계에서 얻는다. 세로 간격은 실제 경과시간이 아니고 저장·응답 성공의 실행 증거도 아니다.

이 예의 조건

• C01의 R501 취소 요청에서 처리기가 예약의 소유자와 상태를 확인하고 v1 마감을 받은 뒤 조건을 충족한 상태 변경과 결과 응답을 진행한다.
• 같은 C01 고객, 취소처리, R501 예약, v1 취소정책버전의 정상 취소를 읽을 수 있게 협력 구간으로 나눈다. 참여자는 같은 대상이며 위에서 아래로 1 취소 R501 요청, 2 상태·소유자 확인, 3 C01·확정·v1 응답, 4 W101 시작시각으로 기한 요청, 5 마감 9월 19일 14시 응답, OPT 요청시각 마감 이하에서 6 취소로 변경과 7 취소 결과 응답, 8 고객 처리 결과 응답의 순서다. 실선은 동기 호출, 점선은 응답이며 모두 채운 화살촉이다. 세로 점선 생명선과 좁은 활성 구간을 표시하고 메시지 간 거리를 실제 시간으로 보지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
취소 요청 C01이 R501 취소를 요청하고 소유자·상태를 확인한다.	값·보충 정보 C01·요청: 취소 R501 R501·정책 v1: C01·확정·v1	변화·이유 타인의 예약이나 확정이 아닌 상태를 정상 취소 경로로 보내지 않는다.
정책 기한 조회 W101 시작 시각에 맞는 v1 마감 9/19 14시를 받는다.	값·보충 정보 C01·요청: 요청 시각 고정 R501·정책 v1: 마감 9/19 14시	변화·이유 최신 정책을 과거 예약에 임의 대입하지 않는다.
OPT 조건 요청 시각≤마감인 경우만 취소 변경을 진행한다.	값·보충 정보 C01·요청: 조건 충족 요청 R501·정책 v1: R501 취소로 변경	변화·이유 조건이 거짓이면 이 변경은 실행되지 않는다.
결과 응답 저장한 취소 결과를 C01에게 돌려준다.	값·보충 정보 C01·요청: 처리 결과 수신 R501·정책 v1: 취소 결과 확인	변화·이유 메시지 줄 간격은 실제 경과 시간을 뜻하지 않는다. 취소 결과 응답도 환불 완료를 뜻하지 않는다.

실선·채운 화살촉은 기다리는 호출, 점선·채운 화살촉은 그 응답이라는 이 그림의 범례다. W101 시작시각은 예약에 연결된 수업에서 얻는 값이며, 좁은 그림에서는 그 조회 생명선을 생략했다. 필요한 정보의 출처 자체가 사라진 것은 아니므로 두 예약을 실제로 놓아 보면 빠진 정책이 드러난다에서 설명한 구조와 함께 읽는다. 전체 설계로 펼칠 때에는 타원 안의 이름을 읽을 수 있는 행동으로 펼친다에서 설명한 타인 예약·이미 취소·기한 초과 대안도 alt 영역이나 별도 그림으로 연결해야 한다.

응답 한 줄이 구현의 성공 증거가 되지는 않는다

예약의 상태를 취소로 바꾸기 전에 고객에게 성공을 보내는 그림이면 약속한 결과와 순서가 맞지 않는다. 정책 조회를 생략했는데 어디서나 24시간을 빼거나, 구조에 없는 최신정책만 갑자기 요청하는 것도 모순이다. 각 메시지의 수신자가 그 책임과 필요한 입력을 실제로 갖는지 먼저 확인한다.

상태 변경 뒤 응답 전달이 실패하면 고객은 같은 요청을 다시 보낼 수 있다. 이때 기존 취소 결과를 돌려주는 경로가 필요하며, “응답 없음”을 “취소되지 않음”과 같다고 해석하지 않는다. 이 절의 그림은 허용할 행동 명세다. 동시 요청·저장 실패·통신 실패에서도 그 명세를 지킬 구현 통제와 시험은 별도로 필요하며, 시퀀스 그림이 존재한다는 사실만으로 그 통제가 구현되었다고 하지 않는다.

5. 상태 그림은 “지금 가능한가”를 따로 확인한다

상태기계 다이어그램(state machine diagram)은 대상의 상태와 사건에 반응하는 전이·조건·행동을 나타내는 그림이다. 전이(transition)는 출발점에서 도착점으로 이어지는 허용된 행동 변화를 나타내는 방향 있는 연결이다. 여기서는 이벤트라는 영어 대신 사건이라고 읽으며, 취소 요청이 도착한 것이 사건의 예다. 가드의 뜻은 앞 활동에서 배운 것처럼 참·거짓으로 판정할 조건이다.

단순한 상태는 둥근 모서리 사각형으로, 전이는 방향 있는 선으로 나타내고 선의 설명을 사건 [가드] / 수행할 효과 순서로 읽을 수 있다. 상태 이름은 “확정”, 전이의 행동은 “취소 요청에 따라 취소로 바꾸기”다. 상태를 동사 목록으로 만들거나 모든 선에 조건을 빼면 같은 입력이 언제 다른 결과를 내는지 보이지 않는다.

예약 하나의 허용 변화와 그대로 남는 경우

화살표의 방향과 조건을 따라 연결을 읽습니다.

이미 존재하는 예약의 두 상태만 보이는 부분 상태 모델이다. 취소를 최종 상태로 닫지 않았다. 거부·기존 결과·타인 요청의 상태 유지와 내부 전이는 아래 표와 설명에서 읽는다.

이 선은 이미 존재하는 예약의 두 상태 사이 변화를 보인 부분 그림이다. 예약 생성·결제·수업 종료의 생애 전체가 아니므로 시작·최종 기호로 전체 생애를 완료한 듯 닫지 않았다. 또한 취소 후에도 재요청을 처리해야 하므로 취소를 “이제 아무 요청도 받지 않는 최종 상태”와 같다고 하지 않는다.

표의 유지 행은 아무 일도 하지 않는다는 뜻이 아니다. 상태는 그대로여도 결과를 돌려주는 행동이 있다. 타인 요청에서는 기한이나 기존 결과를 알려 주기 전에 소유권을 확인한다는 타원 안의 이름을 읽을 수 있는 행동으로 펼친다에서 제시한 순서도 유지한다. 이 모델의 두 상태 밖에 있는 예약은 표의 성공 행으로 억지로 분류하지 않고 추가 요구를 확인한다.

같은 상태로 돌아오는 화살표도 반복 효과를 만들 수 있다

내부 전이(internal transition)는 현재 상태를 나갔다 다시 들어오지 않고 그 안에서 효과를 수행하는 전이다. UML의 외부 자기 전이는 같은 상태로 돌아오더라도 나갈 때와 들어올 때의 행동을 실행할 수 있어 내부 전이와 다르다. 아직 배치하지 않은 출입 행동이 나중에 추가되면 두 표기의 차이가 실제 결과를 바꿀 수 있다.

공방의 취소 상태 안에 본인 재요청 / 기존 결과 제공을 내부 전이로 적으면, 취소 상태로 다시 진입하는 행동을 반복하는 것으로 읽히지 않는다. 반면 취소 상태에 들어올 때 좌석 반환을 실행하도록 가정해 놓고 재요청을 외부 자기 전이로 그리면 같은 진입 효과를 다시 실행하는 설계가 될 수 있다. 좌석 반환의 실제 구현을 여기서 확정하지 않아도, 상태 유지라는 요구와 모델의 반복 효과가 충돌할 가능성은 발견할 수 있다.

활동·시퀀스·상태는 같은 그림의 다른 이름이 아니다

질문이 하나인데 모든 그림을 의무적으로 그릴 필요는 없다. 그러나 그림을 줄였다는 이유로 필요한 관계·조건·예외를 없애지는 않는다. 선택한 표현과 짧은 문장·표를 합쳤을 때 필요한 판단이 모두 남아야 한다. 또 모든 기능·상태 그림이 같은 이름과 버전의 예약을 말하는지 확인해야 각각 옳은 그림이 함께 틀리는 일을 막을 수 있다.

6. 같은 자료로 모델 사이 모순을 찾는다

다음 표의 각 행은 서로 독립적인 시작 상황이다. 앞 행이 뒤 행의 예약을 실제로 취소한 것으로 이어 읽지 않는다. 시작 상태를 다르게 두는 재요청 행만 취소 상태로 시작한다.

세 번째 행은 v1 마감보다 6시간 뒤지만 v2 마감보다 6시간 앞이다. 모든 예약에 현재 정책 하나를 적용하는 잘못된 구조는 첫째·둘째 행의 경계부터 흐트러뜨린다. 넷째 행에서 마감부터 검사하는 흐름은 기존 결과를 줘야 하는 요구와 충돌한다. 다섯째 행에서 기한만 검사하면 다른 고객의 예약을 취소하는 권한 오류가 된다.

표를 그대로 외우지 않도록 세 번째 행의 요청시각만 9월 20일 02시 00분 01초로 바꾸어 다음 상태를 예상해 보자. 고객 C02는 R502의 소유자이고 현재 상태는 확정이므로 앞의 두 검사를 통과한다. 구조에서 v2 마감을 읽은 뒤 시각을 비교하면 1초 초과다. 따라서 활동은 거부 경로를 고르고 시퀀스에는 취소 상태 변경 호출이 없어야 하며 상태기계에서는 확정을 유지하고 기한 경과를 안내한다. 같은 수업의 v1을 읽어 거부했다는 답은 결과만 우연히 맞고 근거는 틀렸다. 두 예약을 실제로 놓아 보면 빠진 정책이 드러난다에서 설명한 예약별 정책 연결과 타원 안의 이름을 읽을 수 있는 행동으로 펼친다에서 제시한 검사 순서로 돌아가 원인을 고친다. 이어 현재 상태만 취소로 바꾸면 기한 비교 전에 기존 결과를 제공해야 한다는 것도 확인한다. 이런 일부 조건 변경을 설명할 수 있어야 뒤 설계 문제에서 각 모델을 따로 그린 뒤 같은 결과로 맞출 수 있다.

검사는 이름·입력·상태·경계를 같은 방향으로 따라간다

먼저 요구의 특정 버전과 모델의 범위를 고정한다. 그다음 각 기능의 입력과 결과에 필요한 클래스·속성·관계를 찾고, 메시지 수신자가 그 행동의 책임과 입력을 가졌는지 확인한다. 상태 모델에서 허용하지 않는 변화가 시퀀스 안에 들어오지 않았는지, 활동의 조건이 요구의 기한·권한과 같은지 실제 값으로 대조한다.

마지막에는 요구별 정상·경계·예외 사례에 어떤 모델 요소가 답하는지 연결한다. R-CAN-03의 반복 결과는 유스케이스의 두 번째 단계, 예약의 취소 상태, 기존 결과를 제공하는 내부 전이, 재요청의 응답 경로로 이어진다. 새 버전이 오면 이 연결로 영향 범위를 찾고, 그림의 선만 고치지 말고 관련 문장·조건·값·시험 기대 결과를 함께 수정한다.

연결표가 채워졌다는 사실은 정합성을 검토할 길이 생겼다는 뜻이다. 실제 구현이 모델대로 동작한다는 시험 완료, 사람의 인수, 기술사 답안의 적정성 승인과 같지 않다. 모델의 모순을 없애는 검토와 실제 동작을 확인하는 검증 상태를 따로 남긴다.

표현은 답해야 할 질문으로 선택한다

고객과 약속한 결과를 확인하려면 유스케이스와 행동 설명부터 읽는다. 정보의 출처·변환이 빠졌는지 확인하려면 자료흐름도를, 유지할 관계와 수량 규칙이 쟁점이면 클래스·객체 모델을 고른다. 갈림길·병행의 오류는 활동, 내부 책임·응답 순서는 시퀀스, 같은 요청에 다른 결과를 내는 현재 기억은 상태 모델로 드러낸다.

어떤 그림을 그리지 않기로 했는지도 필요한 판단이 다른 문장·표에 남아 있는지로 설명한다. 공방의 단순한 취소 상태는 두 상태와 표로 충분하지만, 반복 결과를 제거해서 그림을 단순하게 만들 수는 없다. 표기 하나의 정답을 외우기보다 이번 표현에서 보이는 것과 보이지 않는 것을 구별한다.

자세함의 이익과 함께 유지할 비용을 본다

자세한 모델은 빠진 조건·책임·입력을 드러내지만, 바뀔 때 함께 고칠 이름·선·값도 늘어난다. 너무 큰 한 그림은 읽기 어렵고, 지나치게 작은 그림 조각은 전체 약속과 연결이 끊기기 쉽다. 같은 결과를 중복해서 다른 말로 적기보다 기준 요구·용어·버전을 공유하고, 필요한 관점만 펼쳐 연결을 유지한다.

또 논리적 역할을 너무 일찍 제품·파일·물리 테이블과 같게 정하면 구현 선택을 바꿀 때 업무의 뜻까지 흔들릴 수 있다. 반대로 성능·보안·실패 처리까지 그림 밖으로 밀어내면 실현 가능한지 확인할 수 없다. 이 절에서 확정한 기능·관계·행동과 아직 확인할 저장·통신·외부 환불 조건을 나눠 다음 설계·시험으로 넘긴다.

독립 연습 — 두 번의 요청을 하나의 상태 추적으로 읽는다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

C02가 자신의 확정 예약 R502를 9 월 20 일 02 시 정각에 취소한다. 첫 요청은 저장까지 정상 확정되었고 같은 고객이 03 시에 다시 요청한다. 아래 두 요청은 순서대로 이어지는 하나의 사례이며, 첫 요청의 상태 변화를 두 번째 요청의 시작에 반영한다.

• 각 요청의 시작 상태·먼저 적용할 검사·다음 상태·제공 결과를 쓰라.
• 첫 요청의 허용·거부 경로를 모으는 끝에 기본 조인을 쓰면 왜 멈출 수 있는지 설명하라.

풀이와 오답 교정 보기

첫 요청은 확정에서 시작한다. 소유자와 현재 상태를 확인한 뒤 예약에 연결된 v2의 02 시 마감과 비교하여 취소로 바꾸고 결과를 제공한다. 두 번째는 이미 취소된 상태에서 시작하므로 새 기한 판정 전에 본인 예약의 기존 취소 결과를 제공하고 취소를 유지한다. 선택된 허용·거부 중 하나만 도착하므로 둘 다 기다리는 기본 조인으로 모으면 선택되지 않은 경로를 영원히 기다릴 수 있다. 이곳은 대안을 모으는 병합이다.

재요청을 새 기한 초과로 거부했다면 검사 순서, 합쳐지는 선을 모두 조인으로 불렀다면 병합과 조인 반례를 다시 읽는다. 독립 행의 판정표와 이 순차 과제의 초기 상태도 구별한다.

7. 10점 문제: 그림 이름보다 질문과 일관성을 설명한다

기능·정적·동적 모델의 목적을 비교하고, 자료흐름도의 수준 간 균형과 모델 사이 일관성 검토 방법을 설명하시오.

이 문제는 도형 목록을 많이 적으라는 뜻이 아니다. 각 모델의 질문을 먼저 구별하고, 정보의 이동과 실행 순서를 혼동하지 않는지 보여 주어야 한다. 균형은 상하 수준의 외부 자료를, 모델 사이 일관성은 같은 대상·조건·결과를 대조하는 서로 다른 검사다. 아래 네 논점은 앞에서 배운 설명을 짧게 모은 자체 출제 예시이며 실제 기출 원문이 아니다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 기능·정적·동적 모델의 목적과 겹치는 범위
2. 자료흐름도의 네 요소·수준 간 균형과 제어 흐름의 차이
3. 활동·시퀀스·상태 모델의 질문과 한계
4. 같은 예약의 정책·입력·상태·결과를 통한 일관성 검토

10점 답안 도식

한 요구를 나누어 보는 그림을 답안의 개요로 다시 사용한다. 같은 요구·버전에서 기능·자료, 정보 관계, 시간·상태를 각각 확인한 뒤 같은 입력에 대한 같은 약속 결과로 대조한다.

선은 모델의 비교 관계이며 실행 메시지가 아니다. 자료흐름도의 상하 균형은 기능·자료 안의 수준 간 검토이고, 아래의 결과 대조는 서로 다른 모델을 함께 읽는 검토다.

10점 모범답안

1. 목적과 범위

기능 모델은 제공할 행동·결과를, 정적 모델은 유지할 요소·관계를, 동적 모델은 사건과 시간에 따른 행동·변화를 드러낸다. 이는 질문을 나누는 틀이며, 활동 모델처럼 기능 상세와 동적 행동을 함께 표현할 수 있다. UML이라는 모델링 언어 자체를 개발 방법론과 동일시하지 않는다.

2. 자료흐름과 균형

자료흐름도는 프로세스·자료흐름·저장소·외부 개체로 정보의 이동과 변환을 나타낸다. 맥락도의 전체 프로세스를 분해해도 외부 입력·출력의 의미를 유지해야 하며, 화살표 수가 같아도 고객번호나 접수시각이 빠지면 맞지 않는다. 내부 중간 자료는 추가할 수 있지만 상위 경계에 없던 외부 자료를 몰래 넣지 않으며, 자료흐름을 제어 순서·동기화와 혼동하지 않는다.

3. 동적 표현의 선택

활동은 선택·병행·합류, 시퀀스는 참여자 사이 메시지와 순서, 상태기계는 현재 상태에서 사건에 따른 허용 변화를 중심으로 본다. 활동의 병합은 대안을 모으지만 조인은 필요한 병행 경로를 기다리며, 시퀀스의 세로 간격은 실제 경과시간이 아니다. 취소 상태에서도 재요청 결과를 제공해야 하므로 상태 유지와 무응답을 같게 보지 않는다.

4. 모델 사이 일관성

같은 요구 버전과 예약을 고정하고 기능의 입력·결과가 구조의 속성·관계 및 행동의 조건과 일치하는지 대조한다. R501에는 v1, R502에는 v2를 유지하여 마감 경계·1초 초과·반복·타인 요청의 결과를 확인한다. 연결과 가상 사례의 대조는 검토 근거이며 실제 구현 시험·사람의 인수 완료를 뜻하지 않는다.

8. 25점 문제: 한 취소 정책을 여러 설계에서 맞춘다

공방 예약 취소 시스템의 기능모델과 정적모델을 설계하고 동적모델로 검증하는 방안을 설명하시오. W101 수업은 9월 20일 14시 시작이며, R501은 고객 C01의 v1(24시간 전까지), R502는 고객 C02의 v2(12시간 전까지) 예약이다. 경계 시각은 허용하고, 본인 소유 검사·기한 초과 거부·이미 취소된 예약의 기존 결과 제공이 필요하다. 자료흐름의 수준 간 균형, 관계·다중성, 행동·상태의 일관성을 포함하시오.

두 예약의 마감과 소유자는 이미 정해진 입력이다. 먼저 범위와 가정을 밝히고, 고객 기능을 정보의 변환으로 펼친 뒤 그 정보의 관계를 보인다. 이어 흐름·메시지·상태로 같은 결과를 낼지 대조한다. 유스케이스 이름이나 클래스 명사만 나열하면 설계 동작을 설명하지 못하며, 환불·저장 실패까지 임의로 완료하면 범위를 넘는다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 요구·범위·가정과 모델 설계 산출물의 설정
2. 유스케이스의 역할·입력·정상·예외 및 포함·확장 판단
3. 자료흐름의 경계·분해·균형과 출력 근거 검토
4. 클래스·속성·연산·관계·다중성과 제약의 정적 설계
5. 활동·시퀀스의 조건·책임·동기화와 실패 경계
6. 상태 전이·재요청 결과와 반복 효과의 통제
7. 실제 예약의 경계·예외 대조 및 변경·검증 상태 관리

25점 답안의 도식 대조표

세 관점을 나누고 결과로 맞추는 그림을 개요로 삼고, 예약의 세 연관과 기한 분기·선택 병합을 각각 구조와 행동의 근거로 사용한다. 다음 표는 이 실제 그림들의 대조 지점을 정리한다.

추적할 관점	필요한 정보·행동	서로 맞출 결과
취소 요구·버전 → 고객 기능·자료변환	확인된 요청·예약별 정책·처리 결과	소유권·반복·기한을 요구대로 판단
예약–고객·수업·정책 관계 → 조건·메시지 순서	입력 값의 출처와 정책 조회 뒤 상태 변경	같은 예약·버전·접수시각 유지
조건·메시지 순서 → 확정·취소 상태	허용된 변경과 상태 유지·기존 결과	경계·반복·권한 사례의 결과 대조

이 표는 설계 사이 추적 관계를 요약한 것이며 UML 클래스·시퀀스·상태 기호를 한 표준 그림으로 합친 것이 아니다. 답안에는 다중성의 읽는 방향과 분기 조건을 문장이나 작은 표로 덧붙인다.

25점 모범답안

1. 설계의 입력과 범위

기능·정적·동적 모델링은 같은 시스템의 제공 결과, 유지할 관계, 사건별 행동을 나눠 설계하고 일치시키는 활동이다. 공방의 확정·취소 예약을 범위로 하며, 확인된 고객 신원과 서버 접수시각을 사용하되 예약 소유자는 매번 검사한다. 모델의 산출물은 그림과 조건·예외·정보 책임 및 요구·판정 사례의 연결이다. 없는 예약·조회 실패·다른 예약 상태·외부 환불은 확인할 범위로 남겨 임의 성공을 만들지 않는다.

2. 기능의 설계

고객을 외부 역할, 내 예약 취소를 가치 있는 결과를 제공하는 유스케이스로 식별한다. 예약번호를 받아 소유권을 먼저 검사하고, 본인의 이미 취소된 예약은 기존 결과를 제공한다. 본인의 확정 예약은 예약별 정책의 마감 이하이면 취소하고 초과이면 상태를 유지하여 기한 경과와 운영자 연락을 알린다. 공통 행동의 삽입·재사용은 포함으로, 혼자 의미가 완결된 기본 행동의 지정 위치에 조건부 행동을 추가할 때는 확장으로 검토하며 모든 오류를 확장이라고 하지 않는다.

3. 자료 변환과 균형

자료흐름도에서 취소 처리부의 외부 입력은 예약번호·확인한 고객번호·서버 접수시각이고 출력은 취소 처리 결과다. 내부는 결과 판정과 변경 반영·결과 구성으로 나누고, 예약·수업·정책 자료를 읽어 결과안을 만든다. 허용된 새 취소만 변경 자료를 저장소에 전달한다. 분해 전후 외부 입력·출력의 의미를 같게 유지하고 내부 결과안은 내부 자료로 구분한다. 고객번호나 시각 누락을 검사하며 결제·환불 처리 없이 환불 완료를 출력하지 않는다.

4. 정보 구조와 관계

예약·고객·수업·취소정책버전 클래스를 두고 예약번호·확정시각·상태와 취소판정 연산의 입력·결과를 명세한다. 각 예약은 고객·수업·정책 버전 각각 하나와 연결되고 반대쪽은 예약 0건 이상을 허용한다. R501과 R502가 같은 W101을 가리켜도 각각 v1·v2를 유지해야 한다. 정원 8명과 누적 예약 이력 8건을 동일시하지 않고 점유 중인 예약 수의 별도 제약으로 구별한다. 일반화는 더 일반적인 종류와의 관계이고, 합성은 배타적 부분 소유와 생애 책임을 동반하므로 고객·예약을 삭제 종속의 합성으로 임의 결정하지 않는다.

5. 활동과 참여자의 협력

활동에는 소유권·기존 취소·기한의 조건과 결과를 두고, 마감 이하와 초과가 겹치거나 빠지지 않게 한다. 배타적 대안은 병합으로 모으고 반드시 함께 완료할 병행 경로에만 조인을 사용한다. 시퀀스에서는 취소처리·예약·정책 역할의 입력과 메시지를 연결하여 정책 조회와 상태 변경 뒤 결과를 응답한다. 비동기 메시지나 그림의 존재만으로 저장 성공·통신 성공·재전송 안전이 확보되었다고 하지 않는다.

6. 상태와 반복 요청

확정 예약의 본인·기한 이내 요청은 취소로 바뀌고, 기한 초과·타인 요청은 기존 상태를 유지한다. 이미 취소된 본인 예약에는 현재 마감으로 다시 거부하지 않고 기존 결과를 제공한다. 이를 취소 상태의 내부 전이로 표현하면 상태를 나갔다 들어오는 진입 효과와 구분할 수 있다. 외부 자기 전이에 좌석 반환 같은 진입 행동을 결합해 재요청마다 효과가 반복되지 않도록 요구와 대조한다.

7. 경계 대조와 변경 관리

R501의 9월 19일 14시 요청은 허용, 1초 뒤는 거부이고, R502의 같은 날 20시 요청은 9월 20일 02시 마감 전이므로 허용한다. 취소 상태에서의 재요청과 타인 요청도 독립된 초기 상태로 대조한다. 요구 버전·이름·관계·메시지 책임·상태 조건·예상 결과를 함께 추적하여 변경 시 관련 표현을 동시에 고친다. 연결 완료와 가상 사례 검토는 실제 구현 시험·인수·답안 적정성 승인의 대체물이 아니므로 검증 상태를 구별한다.

출처와 적용 범위

표기와 의미는 OMG UML 2.5.1의 공식 PDF에서 확인한 범위를 사용했다. 클래스·속성·관계는 7·9·11장, 상태는 14장, 활동은 15장, 상호작용은 17장, 유스케이스는 18장이 중심이다. 전체 796쪽을 모두 검토한 것이 아니라 주장별 절·인쇄 쪽을 확인했으며, 표준 그림·표를 복제하지 않고 이 교재의 공방 HTML/SVG 도식과 자료를 직접 구성했다.

자료흐름도는 케이프타운대학교 컴퓨터과학과의 공개 교재 6장에서 네 요소, 맥락도, 수준 분해, 균형, 검사를 대조했다. 2011년 기관 발행 교육자료의 안정 이론을 참고한 것이며 국제 표준이나 현행 개발 도구 추천으로 바꾸어 인용하지 않는다. 여러 표기 계열의 기호를 하나의 공식 표준이라고 합치지 않았다.

목적별 모델의 보완 관계는 IREB의 CPRE Foundation Level Syllabus 3.3.0 3.4절에서 확인했다. 조회 기준일은 2026년 9월 5일이며, 표준 판본의 발행일과 조회일을 구별한다. 공방 정책·시각·관계·답안은 교육용 가상 구성이고 실제 기출 원문·법률상 취소 권리·구현 시험 결과가 아니다. 출처 보존·권리·외부 검토의 승인 상태는 별도 장부에서 관리한다.

다시 읽을 때 남길 핵심

기능은 제공 결과, 구조는 유지할 관계, 동적 행동은 사건에 따른 변화에 질문한다. 자료흐름도는 정보의 이동·변환을 보이며 분해 전후 외부 자료의 의미를 맞춘다. 클래스의 다중성은 현재 건수가 아니라 허용 규칙이고, 같은 수업의 예약도 서로 다른 정책을 유지할 수 있다. 활동·시퀀스·상태는 서로 다른 오류를 찾으며 병합과 조인, 상태 유지와 무응답을 혼동하지 않는다. 마지막에는 같은 예약·버전·입력으로 허용·경계·반복·권한 결과가 모든 모델에서 맞는지 읽는다.

직접 연습: 자료의 건수, 기다릴 경로, 상태에 다시 들어갈 효과를 추적한다.

아래는 모델의 뜻을 확인하기 위한 자체 조건이다. 그림의 모양만 고르지 말고 초기 값에서 결과까지 계산한 뒤, 어떤 요구·관계·행동이 판단의 근거인지 적는다.

1. MM-S. 정원 8명인 수업에 예약 이력 10건이 있고 그중 확정 6건·취소 4건이다. 이 문제에서는 확정 예약만 좌석을 점유하고, 새 예약은 빈 좌석이 있을 때 확정되며 기존 이력은 보존한다고 정한다. 저장 실패·동시 요청 없이 새 예약 세 건을 순서대로 처리하면 각 허용 여부, 마지막 전체 이력 수, 마지막 점유 수는 얼마인가? 예약 쪽 0..*를 0..8로 바꾸거나 전체 이력 건수만으로 만석을 판단하면 어떤 약속이 달라지는가?
2. MM-J. 하나의 안내 준비에서 화면 문구 A와 운영 기록 문구 B가 모두 준비된 뒤 결과를 구성해야 한다. 각각 한 번 시작하여 시작 후 3초·5초에 완료되고, 다른 종료·실패는 없다. 기본 조인에서는 언제 다음 행동으로 갈 수 있는가? 같은 자리를 병합으로 바꾸면 최초 진행은 언제 가능하며 왜 요구를 보장하지 못하는가? 별도 사례로 배타적 조건이 A만 선택하여 3초에 완료하고 B는 시작하지 않는다면 어떤 합류가 맞는가?
3. MM-I. 별도 설계 가정으로 취소 상태의 진입 행동에 취소 처리 기록 생성 횟수+1을 둔다. 횟수는 0에서 시작하고, 본인 예약의 허용된 첫 취소 뒤 본인이 같은 취소를 두 번 재요청한다. 요구는 동일 취소의 처리 기록은 한 번만 만들고 재요청에는 기존 결과를 제공하는 것이다. 재요청을 내부 전이로 처리한 모델과, 취소에서 취소로 가는 외부 자기 전이로 처리한 모델의 마지막 상태와 기록 생성 횟수를 각각 구하라. 상태 이름이 같다는 이유로 두 모델의 효과도 같다고 해도 되는가?

이력·점유 수, 병합·조인 시점, 내부·외부 자기 전이 풀이

1. MM-S — 허용할 연결 수와 지금 점유한 수는 서로 다른 검사다. 처음 빈 좌석은 8−6=2명분이다. 첫 예약과 두 번째 예약은 순서대로 확정되고, 세 번째는 점유가 8명이 되어 거부된다. 마지막 이력은 10+2=12건, 점유는 6+2=8건이다. 취소된 이력 4건을 지우지 않아도 점유 제약을 만족한다. 0..*는 한 수업과 연결될 예약 이력의 상한을 이 연관에서 제한하지 않은 것이지, 좌석을 무한히 허용한다는 뜻이 아니다.

0..8로 바꾸면 현재의 이력 10건부터 구조 규칙을 어기므로 보존할 과거 자료의 약속이 달라진다. 전체 이력 10건만 보고 만석으로 판단하면 실제 빈 좌석 2명분을 놓친다. 따라서 예약–수업의 연관·허용 다중성과 그 수업에서 확정 상태인 예약 수 ≤ 정원이라는 별도 제약을 함께 둔다. 이 계산은 순차 성공이라는 가정 아래의 결과이며 동시 예약의 정원 보장이나 저장 통제를 구현한 증거는 아니다.

2. MM-J — 모두 필요한 완료와 대안 중 하나의 완료를 구별한다. 기본 조인은 두 입력의 도착을 요구하므로 A가 끝난 3초에는 B를 기다리고, B도 끝난 5초에 다음 행동으로 갈 수 있다. 병합은 다른 경로를 기다리지 않아 A가 도착한 3초부터 진행할 수 있다. 그때 B는 미완료이므로 두 문구가 모두 준비되었다는 요구가 보장되지 않는다. 뒤의 B 도착까지 하나의 동기화 결과로 묶어 준다고 가정해서도 안 된다.

A만 선택한 별도 사례에는 병합이 맞다. 3초에 선택된 경로를 넘기면 된다. 기본 조인을 쓰면 시작조차 하지 않은 B의 입력을 기다리게 된다. 이 세 시점은 문제에서 준 완료시간이며 원래 그림의 선 길이·세로 간격에서 측정한 시간이 아니다. 기본 조인의 동기화가 취소 상태 변경·좌석·외부 환불을 함께 성공시키는 트랜잭션 보장으로 바뀌는 것도 아니다.

3. MM-I — 상태가 유지되어도 진입 효과는 반복될 수 있다. 첫 취소는 확정에서 취소로 들어가므로 기록 생성 횟수가 1이 된다. 내부 전이는 취소를 나갔다 다시 들어오지 않고 기존 결과를 제공하므로 두 재요청 뒤에도 취소 상태·횟수 1이다. 외부 자기 전이는 취소를 나갔다 다시 들어오며 진입 행동을 다시 실행하므로, 같은 취소 상태를 유지하더라도 횟수는 1+2=3이 된다. 후자는 이 문제의 한 번만 생성하라는 요구와 맞지 않는다.

상태 이름만 비교하면 두 모델 모두 취소여서 이 차이를 놓친다. 각 사건의 결과 제공, 출입 행동, 반복 효과를 함께 대조해야 한다. 그렇다고 내부 전이 하나만으로 실제 저장·동시 재요청까지 한 번만 처리됨이 증명되는 것은 아니다. 이 가정의 의미를 구현에서 지키는 기록 식별·중복 처리와 실패 시 결과를 따로 설계하고 확인한다.