Um dos diagramas comportamentais definidos na UML 2.5.1 é o Diagrama de Máquina de Estados. Em um Diagrama de Máquina de Estados, os(as):
- A)transições entre estados geram eventos;
Errada: em UML, eventos disparam transições, e não o contrário.
- B)estados podem ser utilizados para descrever o cenário de um Caso de Uso;
Errada: cenário de Caso de Uso é descrito em texto, fluxos ou outros diagramas, não por estados.
- C)transições internas entre estados podem ser descritas em diagramas de Casos de Uso;
Errada: transições internas são próprias de Máquina de Estados, não de Diagramas de Casos de Uso.
- D)comportamentos associados com um estado podem ser expressos por meio de Diagramas de Atividades;
Certa: comportamentos associados a um estado, como atividades do estado, podem ser modelados por Diagramas de Atividades.
- E)estados são comportamentos especificados como sequenciamentos de unidades subordinadas, usando um modelo de controle e fluxo de dados.
Errada: essa descrição se aproxima de atividades ou comportamento estruturado, não da noção de estado na Máquina de Estados.
Gabarito: D
O Diagrama de Máquina de Estados serve para mostrar como um objeto muda de estado ao longo do tempo, reagindo a eventos. Pense nele como a vida do objeto em cena: ele recebe um evento, muda de estado e pode executar alguma ação nessa passagem. Ele é muito usado quando o comportamento depende fortemente do estado atual, como em sistemas de venda, pedidos, máquinas, fluxo de aprovação e outros casos em que "estar em um estado" faz toda a diferença. Na UML, cada estado pode ter comportamentos associados, como entrada, saída e atividade do estado. E aqui mora o ponto da questão: esses comportamentos podem ser detalhados por meio de Diagrama de Atividades, que ajuda a descrever o fluxo interno de trabalho executado enquanto o estado está ativo. Em outras palavras, o estado não fica "parado" esperando o próximo evento; ele pode ter uma lógica interna que a UML permite representar com mais clareza em atividades. Por isso, o item D está correto. A própria UML 2.5.1 admite que o comportamento de um estado, especialmente o comportamento de atividade do tipo doActivity, pode ser especificado por uma atividade. Isso é bem útil quando você quer complementar a Máquina de Estados sem sobrecarregá-la com detalhes operacionais demais. As demais alternativas misturam conceitos. Máquina de Estados não é diagrama de Caso de Uso, nem evento nasce de transição. E a definição da alternativa E parece mais a descrição de atividade ou ação estruturada, não de estado. Em prova, a banca adora essa troca de roupa entre diagramas parecidos: parece parecido, mas não é o mesmo personagem.