Exit States

Introduction

In BPUA, a use case may reach a state that is final for that use case but not terminal for the application flow as a whole. Such a state marks the completion of the current use case logic and also provides a stable point from which the application may continue with another use case.

This kind of state is referred to here as an Exit State.

Relationship to the State Machine Specification

The concept of an exit state is formally defined in the BPUA State Machine Specification. This page explains the motivation behind the term and how it is used in practice, including diagram conventions and application-level continuation.

Why the Term Exit State Is Needed

Ordinary state-machine terminology often uses the term final state. In a simple workflow, that wording is sufficient. In BPUA, however, a use case may complete and still participate in a larger application flow. A state such as LOGGED_IN or REGISTERED may therefore be final for the Account use case while also serving as a handoff point for application-level continuation.

The term Exit State makes that distinction explicit. It says that the current use case has reached a meaningful end point, while leaving open the possibility that orchestration logic may now transfer control elsewhere.

What an Exit State Means in BPUA

An exit state has three important characteristics:

it belongs to a specific use case,
it represents a completed outcome of that use case,
it may be observed by the application to trigger a cross-use-case transition.

This keeps responsibilities properly separated. The use case defines its own internal process and its own outcomes. The application decides whether one of those outcomes should lead into another use case.

Example

Consider the Account use case. After successful login, the use case may enter the LOGGED_IN state. Inside the Account use case, this is a completed outcome. The authentication process has done its work.

At the application level, however, LOGGED_IN may be associated with a registered cross-use-case transition, for example to the Home use case. In that situation, the use case does not know where execution will continue. It only exposes the outcome. The application-level orchestration decides what happens next.

Exit States and Diagram Notation

Standard state-diagram notation does not provide a special built-in symbol for this BPUA meaning. For that reason, a practical convention may be used: exit states can be drawn on or across the boundary of the use case.

This placement visually communicates two facts at once:

the state still belongs to the current use case,
the state also touches the boundary where application-level continuation may begin.

That notation is not intended to replace formal UML rules. It is a BPUA-oriented extension used to express a distinction that ordinary notation does not capture clearly enough.

Why Exit States Matter

Exit states help preserve the independence of use cases. The Account use case can end in LOGGED_IN or REGISTERED without hard-coding knowledge of Home, Welcome, or any other future destination.

This allows the application to compose larger flows out of smaller business units. A use case can be reused in different applications or different orchestration schemes, while still exposing the same clear outcomes.

Summary

Exit states are final states of a use case that are not necessarily terminal for the application flow. They mark completed outcomes inside the use case and provide well-defined handoff points for cross-use-case transitions managed by the application.

Table of Content BPUA Chapter Previous: Execution Lifecycle Next: Relationship with POCO DataSet

Business Process Programming in .Net
© 2004-2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.