What do we mean by state?
We commonly think of the states of matter as solid, liquid, and gaseous, and we know that these are dependent on temperature. For water at — atmospheric pressure — we refer to these states as ice, liquid water, and steam, but every substance can assume the same states, even though they may do so at very different temperatures (and pressures). If we know the temperature, pressure, and specific volume of a substance, we also know (something about) its specific energy, and that uniquely defines the state of the substance.
Other states of matter are possible, with plasma being probably the best known. You can think of plasma as the next hottest state above gaseous, but where the electrons have too much energy to remain in orbit around their nuclei. You can think of the Bose-Einstein condensate as a “fifth state,” the next coldest below solid, where none of the particles have enoough energy to hold together as atoms. These states and many others are described in this Wikipedia article.
The behavior of the substance depends on its state, and the state of the substance depends on other characteristics, which are not themselves states.
States in Object Models
If we think of water as an object, it can have many characteristics. It can have the properties of temperature, pressure, specific volume, and specific energy (define three and the other item is defined as well, with some complications we won’t go into, mostly having to do with quantities of substance existing in multiple states simultaneously in various conditions of saturation). We specify a mass or particular volume of water to instantiate a particular object, as opposed to describing something abstract.
From these pieces of information we know what state (or sometimes states) the water is in, and then we know how it will behave. In object oriented programming, an attribute is a variable defined within an object that can take on different values. Most of the attributes in this example of a particular volume of water are independent. The state of the water is dependent on other attributes of the water. Other actions, then, are allowed, disallowed, or otherwise governed by the derived state.
State for Systems and Business Analysts
Entities can move through, move within, or remain stationary within a process, and they can change states in any of those situations. A state is a variable condition an entity can be in that affects its behavior. An entity (or object) can have multiple attributes that each reflect different possible states. Let’s look at some examples.
Here I use the term “entity” in a more general sense than what is labeled in the diagram above. For this discussion, an entity can enter, move through, and exit from a system. Think of documents being handled in a business process. An entity can also move within the system but never enter or leave, as in the case of an airport shuttle car. Stations, facilities, queues (and bags) all remain stationary, but can be entities in this sense as well. All can have different characteristics that can define states.
States of entities are defined to determine what actions can and should be performed and what decisions can be made. States of entities in systems can be defined in as many ways as your imagination can dream up — as long as everyone understands them. Here are some examples of states and how they can be defined:
- A customer’s monthly payment status can be defined by whether payment has been received by a due date or, if payment is late, how long overdue the payment is. Different actions will be taken depending on the time of full payment, partial payment, passing defined thresholds of lateness, and so on.
- Multiple pieces of information might be required to make certain decisions or take certain actions. States can be defined to describe the ability to make the decision or take the action based on the disposition of all of the required data items.
- Different actions may only be supported when operations are open. Operating hours can determine open/closed states, thermostat settings, availability of certain resources, and so on.
- States can be defined by quantities. Stocked items may need to be reordered or replenished when quantities fall to or below defined levels. A vending machine must know when it has received enough cash, coinage, or electronic payment to complete the sale and dispense product, and also give change or cancel the interaction and reassume a waiting state if appropriate.
State Models
A state model defines:
- The possible states an entity can be in: Any attribute can be a state that can have multiple values, all of which must be defined. An entity can have many different attributes that each define multiple states.
- The sequence of states the entity can be in: An entity (or attribute of an entity) in a given state may not be able to arbitrarily transition into every other state. Rules for defining what is possible must be defined. This can be done using tables, diagrams (see below), or other means.
- How the entity changes states: All actions associated with transitioning into and out of each state must be defined.
- The events and conditions that cause the entity to change states: The mechanism(s) causing states to change must be defined. Sometime an event will change a state directly, and at other times an event must scan other information to determine whether a state change has occurred.
- The actions permitted or required by an entity in each state: Some actions may not be allowed if an entity is in certain states. Other actions must be performed if an entity is in certain states. The latter may happen when the state transition happens, while the entity is in the state, or before the entity is allowed to transition out of that state.
The figure below is a kind of state transition diagram that shows which states can be transitioned into from which prior states, and also the relative probability of each transition’s occurrence. Many types of state transition diagrams, tables, and other descriptions are possible.
It’s Tricky (h/t Run DMC)
A system as complicated as an aircraft can have many different attributes which each define a state. States can be defined in relation to other variables, and even based on other states. The diagram above shows just a small subset of attributes which may describe an aircraft and the states it may assume. What questions does the figure bring up in your mind?
These states and actions can become very, very complicated, and great care may need to be taken with language and definitions. The analysts, customers, implementers, testers, and reviewers may need to work very closely together. Analysts should be keenly aware of this complexity and ensure that the right conversations are had and the right questions are asked and answered.