객체, 상태와 화면으로 솔루션 설계하기
기능 요구사항을 구현 가능한 구성 요소로 나누면 무엇을 제공해야 하는지와 각 부분의 선택지를 비교할 수 있습니다. 일반적으로 객체 모델, 상태 전이, 데이터 보강과 화면의 의도를 정리합니다.
경고 분류 요구의 분해
노선 경고 업무를 예로 들면 운영 분석가는 담당 경고를 보고 재배정, 해결 또는 이관 여부를 판단합니다.
| 요구의 부분 | 필요한 구성 |
|---|---|
| Alert inbox | 새 경고를 검토하는 독립 화면 |
| 담당 노선 | 노선, 사용자 및 그 관계를 나타내는 데이터 |
| 경고 분류 | 현재 담당자와 상태를 가진 경고 객체 및 경고 생성 로직 |
| 우선순위, 항공편과 노선 및 조직 영향 | 항공사, 항공기 등 관련 정보와 우선순위 및 영향의 계산 |
| 재배정, 해결, 이관 | 경고의 상태 전이를 구현하는 액션 |
다른 사용자 요구에도 같은 분석을 적용해 빠진 정보와 업무 결과를 확인합니다.
객체 모델
객체 유형은 다음 범주로 나누어 생각할 수 있습니다.
- Core 객체는 원천 시스템의 기준 데이터와 같은 세분 수준을 가집니다. Flights, Aircraft, Airlines와 Airports가 예입니다.
- Derived 객체는 원천에 직접 존재하지 않아 계산으로 만드는 개념입니다. 노선별 한 행을 만드는 Route가 예입니다.
- Use case 객체는 운영 업무에서 편집하고 판단 결과를 기록합니다. Route Alert Ticket, Comment와 File 등이 해당합니다.
Team과 Employee는 내부 운영 조직을 표현하고 담당 노선 및 경고에 연결합니다. Alert Report처럼 조사 결과를 기록하는 산출물도 모델에 포함할 수 있습니다.
각 객체의 기본 키와 링크의 카디널리티를 함께 정합니다. 관계는 1:1, 1:N 또는 N:N일 수 있으며, 데이터 행의 세분 수준과 링크의 의미가 일치해야 합니다.
상태와 액션
그림의 경고는 Status 속성으로 생애주기를 기록합니다.
| 현재 상태 | 액션 | 다음 상태 |
|---|---|---|
| Pending Review | Assign | Assigned |
| Assigned | Open Investigation | Under Investigation |
| Assigned | Close with Comment | Closed |
| Under Investigation | Close with Comment | Closed |
업무가 구체화되면 액션마다 남길 메타데이터, 사용할 수 있는 조건과 실행할 사용자도 정합니다. 화면에 버튼이 있다는 사실과 액션의 제출 자격은 별도로 구성해야 합니다.
데이터 보강
객체 수준 보강은 원천에 직접 없는 개념을 만듭니다. Route처럼 외부 세계의 개념을 계산해 만들 수도 있고 Alert Ticket처럼 운영 업무 자체의 개념을 만들 수도 있습니다.
속성 수준 보강은 기존 객체에 값을 추가합니다. 업무 규칙, 더 세부적인 데이터의 집계나 모델 결과를 사용해 경고 우선순위와 조직 영향을 계산하는 것이 예입니다.
화면의 의도
| 사용자 | 기대하는 화면과 의도 |
|---|---|
| 운영 담당자 | 필요한 경고와 관련 정보를 바로 볼 수 있고 판단 절차를 안내하는 독립 화면에서 직접 조치합니다. |
| 분석가 | Assigned 및 Under Investigation 경고를 모아 보고 자유 탐색과 분석으로 이동하며 조사 내용을 기록합니다. |
| 경영진 | 운영 절차의 효과와 시간에 따른 변화를 요약해서 이해합니다. |
독립 경고함에는 Workshop을 사용할 수 있습니다. 개별 티켓의 Object View에는 판단 맥락과 적절한 액션을 함께 둡니다. 경영 대시보드는 Quiver 템플릿으로 시작하고, 정기 검토 및 승인이 구체화되면 별도 Workshop 모듈과 그 업무를 기록할 객체 유형으로 확장할 수 있습니다.
Carbon 작업 공간은 관련 객체의 검색과 탐색 및 맞춤 화면을 한 진입점으로 모으는 데 사용할 수 있습니다.
데이터 수집은 Data Connection, 정제 및 결합은 코드 변환, 보강은 모델, 규칙이나 시계열 계산 등으로 구성할 수 있습니다. 객체 및 링크와 액션 및 함수는 업무 데이터와 상호작용을 구조화하고, 내부 화면이나 외부 API가 이를 사용합니다.
보강 계산을 둘 위치
Route마다 평균 비행 시간, 30분을 넘는 도착 지연 횟수와 비행 시간 변동성을 계산한다고 가정합니다. Flights를 출발 및 도착 공항으로 묶은 피벗에서 평균을 구하거나, 30분 초과 지연으로 먼저 필터한 뒤 노선별 건수를 표시할 수 있습니다.
화면에서 계산하면 액션으로 값이 바뀐 결과를 즉시 반영할 수 있습니다. 대신 계산이 특정 화면에 묶여 재사용하기 어렵고 페이지를 열 때 평가하므로 느려질 수 있습니다. 일시적인 지표는 다른 필터나 후속 분석의 입력으로 사용하기도 어렵습니다.
사용자의 액션으로 바뀌는 데이터에 의존하지 않는 보강은 데이터 계층에서 미리 만드는 것을 우선 검토할 수 있습니다. 즉시 반영이 필요한 경우에는 그 요구와 계산 비용 및 재사용 범위를 비교해 위치를 정합니다. 이 기준은 간단한 판단 지침이며 모든 보강을 한 계층에 고정하는 규칙은 아닙니다.