O objeto que rege o preço do ingresso não requer um diagrama de máquina de estados. Por outro lado, o objeto que regulamenta o ciclo de vida de um assento justifica a criação de um diagrama de máquina de estados.

Quando você revir os diagramas de sequência que tratam da venda de assentos você não conseguirá identificar facilmente naqueles diagramas o estado de cada objeto relacionado aos assentos do cinema. Ainda, é possível que cada estado de um determinado objeto possa estar documentado em diagramas de sequência separados, ou seja, um diagrama para cada cenário. É nesse momento que um diagrama de máquina de estados pode ajudar. Nos diagramas de sequência pode ser provável que você identifique mensagens chegando ao objeto, mas qual mudança comportamental cada mensagem efetua no objeto? A resposta a esta pergunta deve ser modelada em um diagrama de máquina de estados.

Exemplo hipotético: suponha que você tenha um objeto com 5 métodos, denominados: “a(), b(), c(), d(), e()”. Todos os métodos são públicos, mas há uma regra de negócio que define que o método “b()” só pode ser executado depois que o método “a()” for chamado, e que o método “c()” só pode ser chamado depois do método “b()”. Muito embora os três métodos estejam públicos e disponíveis, é necessário criar um controle (via programação) que regulamente esta regra. Esse controle deve impedir a execução dos métodos em outra ordem que não seja a pré-estabelecida. E para isso, o diagrama de máquina de estados será o ponto inicial para modelarmos essa questão.

Uma regra de negócio rege a sequência (ciclo de vida) de um objeto.