1 DIAGRAMA DE ATIVIDADES

Prévia do material em texto

1 DIAGRAMA DE ATIVIDADES
Na UML, temos a divisão dos diagramas estáticos (estrutural) e dinâmicos (comportamentais). Na Unidade 1, abordamos os diagramas de caso de uso, sequência que são dinâmicos, e os diagramas de classe e objeto, que são estáticos. E nesta Unidade 2, vamos abordar os diagramas de atividade e estado, os quais também são dinâmicos.
 
“O diagrama de atividade é um tipo especial de diagrama de estados, em que são representados os estados de uma atividade, em vez dos estados de um objeto. Ao contrário dos diagramas de estado, que são orientados a eventos, diagramas de atividade são orientados a fluxos de controle” (BEZERRA, 2007, p. 307).
 
O diagrama de atividade tem como objetivo modelar o comportamento do software, ou seja, suas funcionalidades, apresentando como o sistema deverá se comportar, dando uma visão mais clara ao cliente e à equipe de desenvolvimento. Ele pode ser utilizado também na modelagem organizacional para a engenharia de processo de negócio e workflow.
 
Segundo Booch, Rumbaugh e Jacobson (2006), os diagramas da UML se completam numa análise de sistemas. Eles também podem ser anexados em documentações específicas de outros diagramas, tais como: diagrama de classe, componente e casos de uso.
 
Saiba mais
Vejam algumas dicas de quando usar e quando não usar o diagrama de atividade. Disponível em: <  >.
O diagrama de atividade é muito confundido com o antigo fluxograma, utilizado para modelar a lógica de programação e determinar o fluxo de controle de um algoritmo, mas o que os difere é que apenas com o diagrama de atividade podemos representar ações concorrentes (paralelas) junto à sua sincronização (BEZERRA, 2007).
 
Na Tabela 2.1, vamos conhecer alguns componentes básicos que fazem parte de sua notação e serão utilizados nos diagramas de exemplo e no estudo de caso.
 
Tabela 2.1 | Notação do Diagrama de Atividades
* Nota: Dados trabalhados pelo autor.
Fonte: < https://www.visual-paradigm.com/VPGallery/diagrams/Activity.html >. Acesso em: 13 abr. 2017.
Saiba mais
Para visualizar a notação na íntegra, acesse:
< https://www.visual-paradigm.com/VPGallery/diagrams/Activity.html >. Acesso em: 27 maio 2017.
Estudo de caso: “Controle de Cabeleireiro”
O salão de beleza “Spazio Coiffeur” está no mercado de cabeleireiro há 15 anos e, devido ao bom serviço realizado, sua clientela tem aumentado exponencialmente e, consequentemente, o número de funcionários e parceiros. Nos últimos anos, conquistaram algumas certificações e prêmios devido à busca constante pela qualidade no serviço prestado.
 
Recentemente, o proprietário, o Sr. Francisco, realizou uma pesquisa no mercado para encontrar uma fábrica de software que pudesse lhe atender, seja com um sistema vendido em pacote, seja com um produto construído sob demanda. Mediante algumas indicações, contatou a empresa TopSystem, uma fábrica de software muito conhecida na cidade e que possui muitos clientes na região e em diversas cidades do Brasil. Em sua busca, o Sr. Francisco observou também que essa fábrica tem investido muito em qualidade em seus processos e produto, possuindo algumas certificações, como MPS.Br SW e CMMi. Apesar de não conhecer do segmento, essas informações proporcionaram ao Sr. Francisco mais confiança na empresa a ser contratada.
 
Entretanto, a empresa TopSystem informou não possuir um software pronto para atender ao “Spazio”, porém poderia construir um software sob demanda, atendendo as particularidades do salão. Como proposta inicial, a TopSystem enviaria um analista na empresa do Sr. Francisco para conhecer sua rotina e de sua equipe. Na sequência, agendaria algumas entrevistas com os envolvidos para levantar os requisitos e, posteriormente, marcaria um workshop com todos os entrevistados para apresentar uma proposta do software a ser construído. Após entendimento obtido entre as partes, um orçamento seria apresentado junto a um cronograma para realização das tarefas, com pequenas entregas até a obtenção do aceite final.
 
O Sr. Francisco gostou da proposta da TopSystem e realizaram o agendamento das visitas.
 
As visitas foram realizadas, os requisitos foram identificados e, mediante um estudo aprofundado, o analista de sistemas, Marcos, elaborou alguns diagramas da UML e protótipos para obter entendimento com a equipe de desenvolvimento e com o Sr. Francisco e sua equipe. Mediante a proposta do produto a ser desenvolvido, o proprietário identificou que seria necessária uma pessoa para realizar os cadastros e as configurações iniciais, e como ele não dispunha de alguém exclusivo para esse serviço, solicitou que a segunda entrega poderia ser após um mês de alimentação do produto e incumbiria sua atendente de executar esse serviço.
 
Os diagramas realizados foram: de Caso de Uso, Classe, Objeto e Sequência, máquina de estado e atividade. Para o Sr. Francisco, foi apresentado o diagrama de Caso de Uso, e neste registraram o acordo entre as partes, o diagrama de estado e atividade.
 
Com base na análise realizada por Marcos, foram identificadas as seguintes necessidades:
 
· Controle de Cliente.
· Controle de Serviço.
· Controle de Produto.
· Controle de Colaboradores/Profissionais.
· Controle de Comissões.
· Controle de Usuários.
· Controle de Fornecedor.
· Controle de Comanda (Ordem de Serviço).
· Controle de Agendamento.
· Controle de Pagamento.
E alguns relatórios, como:
· Clientes Cadastrados.
· Serviços Cadastrados.
· Pagamentos dos Serviços realizados.
· Comissões dos Funcionários.
· Na Figura 2.1, a seguir, para entender melhor o cenário atual do salão, o Analista de Sistemas Marcos, que faz parte do estudo de caso, modelou um diagrama de atividade do controle das comandas no cenário em que o pagamento será realizado em dinheiro, tudo isso sem a existência de um sistema. 
·  
· Vamos entender as etapas do cenário atual:
·  
· 1) O cliente faz contato com o salão e solicita um agendamento.
· 2) A atendente confere a agenda de papel e confirma com o colaborador sua disponibilidade.
· 3) Quando o cliente chega ao salão, confirma com o atendente os serviços que deseja realizar.
· a.    caso informe outros, mais uma vez é confirmado na agenda do colaborador;
b.    confirmando os serviços a serem realizados, a atendente os registra na comanda;
c.    caso o colaborador tenha vendido algum produto, ele também tem que ser registrado na comanda.
· 4) A atendente faz o cálculo para o cliente e realiza a cobrança.
· a.    caso o cliente precise de recibo, o atendente o preenche manualmente;
b.    confere se o cliente deseja agendar um retorno. Em caso positivo, realiza o agendamento;
c.    Todo esse controle de serviço prestado, produto vendido e pagamento, bem como o comissionamento, são registrados numa planilha no Excel.
·  
· Figura 2.1 | Diagrama de Atividade - Controle de Comanda (pagamento em dinheiro)
· 
· Fonte: elaborada pelo autor.
Na Figura 2.2, Marcos fez um diagrama sugerindo como ficaria a rotina inicial de agendamento e abertura de comanda via sistema. Neste cenário, foram utilizadas as “raias de natação” para definir as responsabilidades dos papéis envolvidos no processo, por exemplo: Cliente, Atendente e Colaborador, que nesse caso são os executores dos serviços específicos do salão, como cortes, pinturas, hidratações etc.
 
Sobre as atividades, foi modelado para representar que o cliente solicitará o agendamento à atendente. Quando o cliente chegar ao salão para realizar os procedimentos, a atendente sempre abrirá a comanda e, automaticamente, os envolvidos na realização dos serviços conseguirão visualizar via sistema a liberação dos serviços a serem executados. Ao finalizar, registrará no sistema. Com os serviços realizados, a atendente realizará a cobrança. Caso o cliente necessite de um recibo, ela apenas “clicará” na opção “Gerar recibo” no sistema, que enviará para a impressão e encerrará a comanda. Ao finalizar o recebimento, verificará se o cliente deseja agendar um retorno e na própria tela de recebimento já buscará a tela de “Agendamento”.
 
Figura 2.2 | Diagrama deatividade do cenário proposto
Fonte: elaborada pelo autor.
Questão para reflexão
Tomando como base a Figura 2.2, complemente o diagrama:
•Como ficaria modelado seu diagrama de atividade caso o cliente pudesse fazer o agendamento online? Apresente as novas atividades e represente o fluxo delas.
•Qual é a utilidade da barra preta na horizontal entre as atividades “Gerar Recibo” e “Fechar Comanda”?
Compartilhe sua abstração com o professor!
2 DIAGRAMA DE MÁQUINA DE ESTADOS
Outro diagrama que vamos estudar para complementar nosso estudo de caso é o diagrama de máquina de estado, que antes da UML 2.0 era conhecido também como diagrama de gráfico de estado ou diagrama de estado.
 
Para fazermos uma analogia e compreender o que são estados, podemos pensar em objetos do dia a dia, como:
 
· Um cliente em uma loja pode estar: Adimplente ou Inadimplente.
· Um carro numa locadora de veículos: Alugado, Reservado, Disponível, Manutenção e Indisponível.
· Um aluno numa instituição de ensino: Aprovado, Reprovado e Dependência.
· Uma pessoa pode estar: Alegre, Triste, Cansada, Animada etc.
O diagrama de máquina de estados “demonstra o comportamento de um elemento por meio de um conjunto finito de transições de estado, ou seja, uma máquina de estados” (GUEDES, 2011, p. 243). Esses elementos podem ser uma instância de uma classe e é possível modelar casos de uso também. Veja na Tabela 2.2 sua notação.
 
Tabela 2.2 | Notação do Diagrama de Máquina de Estados
*Nota: Dados trabalhados pelo autor.
Fonte: < https://www.visual-paradigm.com/VPGallery/diagrams/State.html >. Acesso em: 13 abr. 2017.
 
Saiba mais
Para visualizar a notação na íntegra, acesse:
<  >. Acesso em: 27 maio 2017.
Na Figura 2.3, modelamos o diagrama de máquina de estado para representar os possíveis estados de um carro numa empresa de locação de veículo. Temos o pseudoestado inicial que, assim como no diagrama de atividade, podemos incluir apenas um e vários estados finais. Para cada mudança de estado, temos uma seta de transição, unidirecional, que sai do emissor para o receptor, contendo um evento ocasionando uma mudança no estado. Esse evento pode ser apenas a seta, ou também conter a descrição, conforme modelamos, no intuito de facilitar a leitura dos envolvidos.
 
Figura 2.3 | Diagrama de máquina de estado - Locação de Carros
Fonte: elaborada pelo autor.
 
Saiba mais
Condição de Guarda, subestados concorrentes.
Disponível em: < https://web.fe.up.pt/~jpf/teach/POO/estados.pdf >. Acesso em: 27 maio 2017.
 
Para nosso estudo de caso, modelamos os possíveis estados de uma comanda, conforme Figura 2.4, e o diagrama de atividade, que consta na Figura 2.2, na qual a “Atendente”, que é um dos atores do sistema, abre a comanda apenas quando o cliente chega ao salão, e finaliza ao ser concluído todo serviço e realizada a cobrança com ou sem recibo.
 
Figura 2.4 | Diagrama de máquina de estado - Comanda
Fonte: elaborada pelo autor.
RESUMO DA UNIDADE
Nesta unidade, demos sequência ao estudo de caso “Spazio Coiffeur” e, com base nele, foi possível modelarmos os diagramas de atividade e máquina de estado, abordando o conceito, a notação, os modelos de diagramas e a construção de alguns cenários baseados no estudo de caso. Os diagramas trabalhados, assim como os que foram apresentados na Unidade 1, são formas de apoiar a todos envolvidos (clientes, analistas de negócio, sistemas, gerentes de projetos, programadores e testadores) a obterem melhor conhecimento da ideia solicitada pelo cliente, da análise realizada pelos analistas de sistemas e negócio, que serve como ponte entre o cliente e a equipe de desenvolvimento. Ao conseguir codificar algo por meio de todas essas informações, temos o papel dos testadores, os quais, com base no escopo do produto acordado entre os analistas e o cliente, fazem os testes para verificar se o que foi solicitado foi de fato implementado. Após esses testes, é possível liberar para o cliente uma versão na qual sua equipe possa fazer suas validações e apresentar o aceite. O fluxo de como essas entregas são realizadas dependerá do processo adotado pela organização, o qual definirá os envolvidos em cada etapa, os diagramas e as ferramentas que serão utilizados e quais são as entregas esperadas.
 
Para discutir
BEZERRA, E. UML - Princípios de Análise e Projeto de Sistemas. 3.ed. Rio de Janeiro: Campus, 2015.
FOWLER, Martin; SCOTT, Kendal. UML essencial. Porto Alegre: Bookman, 2000.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. Ed. São Paulo: Novatec, 2008.
JACOBSON, Ivar; NG, Pan-Wei. Aspect-oriented software development with use cases. Addison-Wesley Object Technology Series, 2004.
LARMAN, Craig. Utilizando UML e padrões. 3. ed. Porto Alegre: Bookman, 2007.
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de Janeiro: Editora Campus, 1994.
 
REFERÊNCIAS
BEZERRA, E. UML - Princípios de Análise e Projeto de Sistemas. 3.ed. Rio de Janeiro: Campus, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2006.
CHEN, Peter. Active conceptual modeling of learning: Next Generation Learning-Base System Development com Leah Y. Wong (Eds.). Springer. 2007.
GUEDES, G. T. UML 2: Uma abordagem prática. 2. ed. São Paulo: Novatec Editora, 2011.
JACOBSON, Ivar. Object-orientad Software Engineering. Addison Wesley Longman, 1995.
PENDER, Tom. UML: a bíblia. Rio de Janeiro: Campus, 2004.
Resumo geral uml
Entendendo o Diagrama de Atividades da UML
By Plínio Ventura On 29 Oct, 2016 Last updated 10 Feb, 2019  12
 Share
Compartilhe!
· Facebook
· Twitter
· Google+
· Pinterest
O que são atividades? Segundo o site Sinônimos é “funcionamento, operação, atuação, laboração, execução”.
No contexto da UML, o Diagrama de Atividades é um diagrama comportamental (que especifica o comportamento do software), e através dele podemos modelar partes do comportamento de um software.
Em projetos de software utilizamos modelos para representar tanto a estrutura quando o comportamento do sistema e com base neles construir, programar o modelo executável, que é o sistema materializado. Eu costumo falar assim: estrutura representa aquilo que é estático, que não muda com o uso do sistema, não muda de estado, não movimenta. Comportamento é o que é dinâmico no sistema, que se altera a partir de ações do próprio sistema ou do usuário”.
O diagrama de atividades ilustra graficamente como será o funcionamento do software (em nível micro ou macro), como será a execução de alguma de suas partes, como será a atuação do sistema na realidade de negócio na qual ele está inserido.
UML e Agilidade
Agilidade não é produzir software com pressa, é produzir software com velocidade, entregando valor no menor espaço de tempo possível, e melhorando isso continuamente.
Para ser ágil, é fundamental ser eficiente.
Não é plausível falar em agilidade sem eficiência, com desperdício.
Em projetos de software, um dos maiores desafios é a boa comunicação.
Deixar claro o que se quer, o que será entregue, como será produzido etc. Isso não é simples quando produzimos software, devido à complexidade inerente a esta atividade.
Quando se entende um requisito do jeito errado, sempre há o custo de fazer errado, desfazer, e fazer certo. Obviamente, este tipo de desperdício custa 3 vezes mais que se tivéssemos feito certo da primeira vez.
E neste contexto, fica claro que o uso racional de diagramas UML com o objetivo de transmitir ideias entre membros de um mesmo time, é uma ferramenta que favorece muito uma cultura ágil.
Objetivos de utilização
O diagrama de atividades, como citado, tem como objetivo principal a especificação do comportamento do software, do ponto de vista funcional, ou seja, das suas funcionalidades. É muito semelhante a um fluxograma, uma ferramenta utilizada há muitas décadas, principalmente na administração.
Pressupõe-se que, antes de se especificar o funcionamento do software, é necessário especificar “o que é o software, para que serve o software” (veremos isso no item “quando não usar”,mais a seguir).
E ainda, como para qualquer outro modelo que segue a notação UML, o objetivo de um diagrama é especificar o que será posteriormente projetado, ou diretamente construído, diminuindo assim o nível de abstração do escopo, facilitando o entendimento sobre o que tem ser feito pelo programador, por exemplo.
Com isso, programadores, por exemplo, podem entender de uma maneira “mais lógica” e “menos abstrata” o que deverá ser codificado no modelo executável. Entenderemos isso melhor mais à frente.
Quando usar
Na prática, é um diagrama como o bombril: tem mil e uma utilidades. 🙂 Mas não significa que isso é bom.
Usar um faca para apertar um parafuso pode até funcionar, mas pode machucar a mão por não ser a ferramenta apropriada para isso, ou ainda, estragar o parafuso.
O diagrama de atividades apresenta uma simplicidade muito tentadora, e em função disso, muitos analistas utilizam o diagrama para modelagem de processos, modelagem de algorítimos, modelagem de sequência etc., quando na realidade, existem diagramas apropriados para isso na UML ou na BPMN.
É pertinente utilizá-lo quando o propósito é:
· Documentar o aspecto funcional (não estrutural) do software, quando é necessário representar o fluxo da informação que o software trabalhará, e quando existam condições/decisões que precisam detalhadas/descritas.
· Mostrar aspectos específicos de alguma rotina do negócio que será automatizada pelo software, como um “zoom” em parte de alguma funcionalidade, por exemplo. Obs.: muito cuidado ao especificar toda uma funcionalidade (uma tela ou rotina batch por exemplo) num diagrama de atividades. Geralmente isso gera diagramas de atividades super complexos, o que pode gerar efeito inverso (ou seja, “subtrair mais que somar”).
· Mostrar como Funcionalidades vão realizar Requisitos Funcionais (funções executadas pelas funcionalidades), e a relação dos Requisitos Funcionais com as Regras de Negócio.
· Documentar de forma macro como o sistema irá funcionar, mas orientado ao software, não ao processo de negócio. Mostrar como os módulos do sistema interagem entre si, as principais as informações trafegadas durante a execução do software, entradas e saídas principalmente.
Quando me refiro a documentar, é importante deixar claro que a documentação só tem razão de existir quando serve para explicar algo para alguém, e deixar uma memória viva e “útil” do projeto do software. Diferente disso é perda de tempo, dinheiro, e aumento da ineficiência do processo produtivo através do aumento desnecessário da complexidade do projeto.
Quando não usar
Não é pertinente utilizar diagramas de atividades para:
· Elicitação de requisitos, pois o foco do diagrama de atividades é no comportamento, no aspecto “funcional” do software. E antes de se pensar no funcionamento do software é fundamental se pensar no conceito do sistema, focando no problema de negócio, e na solução que será aplicada para resolvê-lo. Para isso, utilize Digramas de Bloco ou Diagramas de Decomposição Funcional, por exemplo.
Um dos maiores problemas do Analista de Sistemas é dar atenção ao “micro” quando ainda não entendeu o “macro”. Antes de pensar no funcionamento do software é necessário pensar no negócio que o software vai automatizar, qual o conceito dessa solução, e o que o software deverá fazer e não como ele deverá fazer. Isso se faz com Engenharia de Requisitos, e depois dos requisitos especificados, estes são “distribuídos” nas funcionalidades do software, que os realizam.
· Quando o assunto é Modelagem de Processos de Negócio. Modelar processos não é modelar software. Software pode ser utilizado para realizar algumas atividades/tarefas do processo de negócio, mas são coisas muito distintas. Existem profissionais que utilizam diagramas de atividades para modelar processos, e diagramas BPMN para modelar software. São notações diferentes, e para quem está acostumado com ambos, pode gerar confusão.
· Modelar o comportamento completo de telas e rotinas batch. Para essas finalidades, diagramas de Caso de Uso ou diagramas de Sequência são opções muito melhores. Utilize o primeiro quando o foco for mais no aspecto funcional da tela ou da rotina e quando usuários ou analistas menos técnicos estiverem envolvidos, e o segundo quando o foco for mais no design (projeto) do software, quando programadores ou arquitetos estiverem envolvidos.
Como usar
Na UML temos dois conceitos importantes de entender: diagramas e elementos. Na imagem que vimos no início do post temos uma relação de todos os diagramas da UML.
As formas gráficas que compoe cada diagrama são chamadas “elementos”. Estes elementos são “o grande lance” da UML, é o que sustenta a ideia de “notação”, é a sintaxe contida nos diagramas.
Cada elemento possui um objetivo específico, e a combinação destes elementos torna-se o diagrama, que gera a semântica do respectivo modelo.
Como tudo na vida, na UML também aplica-se o Princípio de Pareto. Com 20% dos elementos fazemos 80% dos diagramas. Então, vou focar nos elementos mais utilizados do diagrama de atividades.
Activity – É a atividade propriamente dita. Usamos este elemento quando citamos uma atividade no diagrama. Por exemplo: “Processar Pedido” é uma atividade que seria ilustrada com esta forma.
Partition – É comum chamarmos de “Raia”, fazendo uma analogia com as raias de uma piscina. Podem ser representadas na vertical ou na horizontal. Ilustram fronteiras entre módulos, funcionalidades, sistemas ou sub-sistemas, conforme o nível de detalhe e foco do diagrama.
Decision – Representa uma decisão que pode desviar o fluxo ilustrado no diagrama. Utilizado quando lidamos com condições. Por exemplo: “Pagamento aprovado? Se sim, desvia para a atividade Gerar Boleto, se não, vai para atividade “Pagar novamente”.
Initital – É o primeiro elemento do diagrama. Define o início do fluxo. Um diagrama de atividades pode ter mais de um elemento deste, pois seu início pode ser dar em mais de um “local”.
Final – É o último elemento do diagrama. Define o fim do fluxo. Um diagrama de atividades pode ter mais de um elemento deste também, pois o fim do fluxo pode ocorrer em vários partes do diagrama. O ideal é utilizar o elemento “Flow Final”, mas é um conceito mais avançado.
Fork/Join – Na imagem temos dois destes elementos, um na horizontal e outro na vertical. O objetivo é o mesmo para ambas as formas. O Fork tem como finalidade dividir o fluxo em mais de uma direção, e o Join tem finalidade inversa, ou seja, faz a união de várias direções do fluxo em uma única direção.
Exemplo de Uso
Vejamos abaixo um exemplo do uso do Diagrama de Atividades.
O exemplo é simplório, apenas para fins didáticos. Basicamente, temos referências a dois módulos nas duas Partitions (Cadastro de Cliente e E-mail Marketing), e trata-se de um fluxo do sistema, onde um cliente após ser cadastrado sofre uma avaliação, e dependendo do resultado da avaliação (feita através do software) o fluxo pode tomar caminhos diferentes.
Se todo o fluxo completar-se, antes de encerrar-se, o cliente vai para uma situação de “espera”, onde outro fluxo, por exemplo, tratará o envio de uma nova oferta ao cliente que passou em todas as etapas.
Conclusão
O diagrama de atividades é uma excelente opção para especificação de software, desde que empregado da maneira correta, para os fins adequados.
No início processo de produção de software, por possuir um nível de abstração bem próximo do negócio, este diagrama é ideal para especificações que precisam ser compreendidos por profissionais menos técnicos, e até mesmo usuários.
E ainda, auxilia muito na compreensão do escopo do software, servindo tanto para as disciplinas de análise e de projeto.
Se você gostou do conteúdo deste post, deixe seus comentários, para ajudar outras pessoas a encontrarem este material! 🙂
Grande abraço!
Parte superior do formulário
Junte-se a milhares de leitores inteligentes e receba nossas novidades direto no seu e-mail (é grátis)!
Email*
CADASTRAR
Marketing by
Parte inferior do formulário
Related Posts via Categories
· O que é UML (UnifiedModeling Language)
· Entendendo o Diagrama de Instalação da UML
· Entendendo o Diagrama de Sequência da UML
· Entendendo o Diagrama de Classes da UML
· Caso de Uso ou Estória de Usuário?
· Analista de Infraestrutura e Requisito Não Funcional
· FAQ04 – Perguntas e Respostas sobre Engenharia de Software
· FAQ03 – Perguntas e Respostas sobre Engenharia de Software
· O que é Requisito Inverso
· FAQ02 – Perguntas e Respostas sobre Engenharia de Software
	State machine diagram
	The behavior of an entity is not only a direct consequence of its input, but it also depends on its preceding state. The history of an entity can best be modeled by a finite state diagram. State Machine diagram can show the different states of an entity also how an entity responds to various events by changing from one state to another.
	
	Use case diagram | Class diagram | Sequence diagram | Communication diagram | State machine diagram | Activity diagram | Component diagram | Deployment diagram | Package diagram | Object diagram | Composite structure diagram | Timing diagram | Interaction overview diagram
	
	
	
	State machine diagram
	
	
		Notation
	
	 
	Constraint
	
	 
	Choice
	
	
	 
	Deep History
	
	 
	Entry Point
	
	
	 
	Exit Point
	
	 
	Fork
	
	
	 
	Final State
	
	 
	Initial Pseudo State
	
	
	 
	Join
	
	 
	Junction
	
	
	 
	Note
	
	 
	Shallow History
	
	
	 
	State
	
	 
	Submachine State
	
	
	 
	Terminate
	
	 
	Transition
	
	Definition
State machine diagrams specify state machines. This clause outlines the graphic elements that may be shown in state machine diagrams, and provides cross references where detailed information about the semantics and concrete notation for each element can be found. It also furnishes examples that illustrate how the graphic elements can be assembled into diagrams.
	 
		Constraint
	
		
	
			Definition
	A condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.
	
		Properties
	
	Name
	The name of constraint. It is optional and is commonly omitted.
	Expression
	The condition that must be true when evaluated in order for the constraint to be satisfied.
	Documentation
	Description of constraint.
	 
		Choice
	
		
	
			Definition
	choice vertices which, when reached, result in the dynamic evaluation of the guards of the triggers of its outgoing transitions. This realizes a dynamic conditional branch. It allows splitting of transitions into multiple outgoing paths such that the decision on which path to take may be a function of the results of prior actions performed in the same runto-completion step. If more than one of the guards evaluates to true, an arbitrary one is selected. If none of the guards evaluates to true, then the model is considered ill-formed. (To avoid this, it is recommended to define one outgoing transition with the predefined 'else' guard for every choice vertex.) Choice vertices should be distinguished from static branch points that are based on junction points.
	
		Properties
	
	Name
	The name of choice.
	Visibility
	Determines where the choice appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of choice.
	 
		Deep History
	
		
	
			Definition
	deepHistory represents the most recent active configuration of the composite state that directly contains this pseudostate (e.g., the state configuration that was active when the composite state was last exited). A composite state can have at most one deep history vertex. At most one transition may originate from the history connector to the default deep history state. This transition is taken in case the composite state had never been active before. Entry actions of states entered on the path to the state represented by a deep history are performed.
	
		Properties
	
	Name
	The name of deep history.
	Visibility
	Determines where the deep history appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of deep history.
	 
		Entry Point
	
		
	
			Definition
	An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region.
	
		Properties
	
	Name
	The name of entry point.
	Visibility
	Determines where the entry point appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of entry point.
	 
		Exit Point
	
		
	
			Definition
	An exit point pseudostate is an exit point of a state machine or composite state. Entering an exit point within any region of the composite state or state machine referenced by a submachine state implies the exit of this composite state or submachine state and the triggering of the transition that has this exit point as source in the state machine enclosing the submachine or composite state.
	
		Properties
	
	Name
	The name of exit point.
	Visibility
	Determines where the exit point appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of exit point.
	 
		Fork
	
		
	
			Definition
	fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices (i.e., vertices in different regions of a composite state). The segments outgoing from a fork vertex must not have guards or triggers.
	
		Properties
	
	Name
	The name of fork.
	Visibility
	Determines where the fork appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of fork.
	 
		Final State
	
		
	
			Definition
	A special kind of state signifying that the enclosing region is completed. If the enclosing region is directly contained in a state machine and all other regions in the state machine also are completed, then it means that the entire state machine is completed.
	
		Properties
	
	Name
	The name of final state.
	State invariant
	Specifies conditions that are always true when this state is the current state. In protocol state machines, state invariants are additional conditions to the preconditions of the outgoing transitions, and to the postcondition of the incoming transitions.
	Redefined state
	The state of which this state is a redefinition.
	Documentation
	Description of final state.
	Deferrable Triggers
	A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred.
	 
		Initial Pseudo State
	
		
	
			Definition
	An initial pseudostate represents a default vertex that is the source for a single transition to the default state of a composite state. There can be at most one initial vertex in a region. The outgoing transition from the initial vertex may have a behavior, but not a trigger or guard.
	
		Properties
	
	Name
	The name of initial pseudo state.
	Visibility
	Determines where the initial pseudo state appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of initial pseudo state.
	 
		Join
	
		
	
			Definition
	join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions. The transitions entering a join vertex cannot have guards or triggers.
	
		Properties
	
	Name
	The name of join.
	Visibility
	Determines where the join appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of join.
	 
		Junction
	
		
	
			Definition
	junction vertices are semantic-free vertices that are used tochain together multiple transitions. They are used to construct compound transition paths between states. For example, a junction can be used to converge multiple incoming transitions into a single outgoing transition representing a shared transition path (this is known as a merge). Conversely, they can be used to split an incoming transition into multiple outgoing transition segments with different guard conditions. This realizes a static conditional branch. (In the latter case, outgoing transitions whose guard conditions evaluate to false are disabled. A predefined guard denoted "else" may be defined for at most one outgoing transition. This transition is enabled if all the guards labeling the other transitions are false.) Static conditional branches are distinct from dynamic conditional branches that are realized by choice vertices.
	
		Properties
	
	Name
	The name of junction.
	Visibility
	Determines where the junction appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of junction.
	 
		Note
	
		
	
			Definition
	A note (comment) gives the ability to attach various remarks to elements. A comment carries no semantic force, but may contain information that is useful to a modeler.
	
		Properties
	
	Name
	The name of note.
	Documentation
	Specifies a string that is the comment.
	 
		Shallow History
	
		
	
			Definition
	shallowHistory represents the most recent active substate of its containing state (but not the substates of that substate). A composite state can have at most one shallow history vertex. A transition coming into the shallow history vertex is equivalent to a transition coming into the most recent active substate of a state. At most one transition may originate from the history connector to the default shallow history state. This transition is taken in case the composite state had never been active before. Entry actions of states entered on the path to the state represented by a shallow history are performed.
	
		Properties
	
	Name
	The name of shallow history.
	Visibility
	Determines where the shallow history appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of shallow history.
	 
		State
	
		
	
			Definition
	A state models a situation during which some (usually implicit) invariant condition holds. The invariant may represent a static situation such as an object waiting for some external event to occur. However, it can also model dynamic conditions such as the process of performing some behavior (i.e., the model element under consideration enters the state when the behavior commences and leaves it as soon as the behavior is completed).
	
		Properties
	
	Name
	The name of state.
	Entry
	An optional behavior that is executed whenever this state is entered regardless of the transition taken to reach the state. If defined, entry actions are always executed to completion prior to any internal behavior or transitions performed within the state.
	Exit
	An optional behavior that is executed whenever this state is exited regardless of which transition was taken out of the state. If defined, exit actions are always executed to completion only after all internal activities and transition actions have completed execution.
	Do activity
	An optional behavior that is executed while being in the state. The execution starts when this state is entered, and stops either by itself or when the state is exited whichever comes first.
	State invariant
	Specifies conditions that are always true when this state is the current state. In protocol state machines, state invariants are additional conditions to the preconditions of the outgoing transitions, and to the postcondition of the incoming transitions.
	Redefined state
	The state of which this state is a redefinition.
	Documentation
	Description of state.
	Regions
	A region is an orthogonal part of either a composite state or a state machine. It contains states and transitions.
	Deferrable Triggers
	A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred.
	 
		Submachine State
	
		
	
			Definition
	A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine.
A submachine state is semantically equivalent to a composite state. The regions of the submachine state machine are the regions of the composite state. The entry, exit, and behavior actions and internal transitions are defined as part of the state. Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse.
	
		Properties
	
	Name
	The name of state.
	Submachine
	The state machine that is to be inserted in place of the (submachine) state.
	Entry
	An optional behavior that is executed whenever this state is entered regardless of the transition taken to reach the state. If defined, entry actions are always executed to completion prior to any internal behavior or transitions performed within the state.
	Exit
	An optional behavior that is executed whenever this state is exited regardless of which transition was taken out of the state. If defined, exit actions are always executed to completion only after all internal activities and transition actions have completed execution.
	Do activity
	An optional behavior that is executed while being in the state. The execution starts when this state is entered, and stops either by itself or when the state is exited whichever comes first.
	State invariant
	Specifies conditions that are always true when this state is the current state. In protocol state machines, state invariants are additional conditions to the preconditions of the outgoing transitions, and to the postcondition of the incoming transitions.
	Redefined state
	The state of which this state is a redefinition.
	Documentation
	Description of submachine state.
	Deferrable Triggers
	A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred.
	 
		Terminate
	
		
	
			Definition
	Entering a terminate pseudostate implies that the execution of this state machine by means of its context object is terminated. The state machine does not exit any states nor does it perform any exit actions other than those associated with the transition leading to the terminate pseudostate. Entering a terminate pseudostate is equivalent to invoking a DestroyObjectAction.
	
		Properties
	
	Name
	The name of terminate.
	Visibility
	Determines where the terminate appears within different Namespaces within the overall model, and its accessibility.
	Documentation
	Description of terminate.
	 
		Transition
	
		
	
			Definition
	A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to an occurrence of an event of a particular type.
	
		Properties
	
	Name
	The name of transition.
	Source
	Designates the originating vertex (state or pseudostate) of the transition.
	Target
	Designates the target vertex that is reached when the transition is taken.
	Kind
	TransitionKind is an enumeration of the following literal values: external, internal, local.
	Effect
	Specifies an optional behavior to beperformed when the transition fires.
	Redefined transition
	The transition of which this is a replacement.
	Guard
	A guard is a constraint that provides a fine-grained control over the firing of the transition. The guard is evaluated when an event occurrence is dispatched by the state machine. If the guard is true at that time, the transition may be enabled; otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed.
	Documentation
	Description of transition.
	Triggers
	Specifies the triggers that may fire the transition.