Os Diagramas Comportamentais da UML


Diagramas comportamentais são aqueles onde existe alguma alteração de comportamento das classes. Os principais diagramas comportamentais da UML são: Diagrama de Caso de Uso, Diagrama de Seqüência e Diagrama de Atividade. Este artigo tem o objetivo de descrever as principais características destes diagramas.

A UML permite que os desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados propiciando uma notação gráfica facilmente entendível com a um explicação significativa.

Diagramas de Caso de Uso

É um diagrama utilizado para auxiliar a comunicação entre o os analistas de sistema e o cliente, onde será demonstrada as funcionalidades do sistema de uma maneira simples e direta.

Diagramas de Estado

Esse diagrama demonstra os diferentes estados de um objeto durante seu ciclo, e os eventos (estímulos) que fazem com que o objeto altere seu estado.

O diagrama de estado é aconselhável para sistemas mais complexos, deve ser desenvolvido para objetos que possuam seus estados definidos e onde o comportamento desse objeto possa mudar a partir de um outro estado. Os diagramas de estado começam com um estado inicial e podem ter várias saídas ou fins.

Diagramas de Atividade

O objetivo do diagrama de atividades é demonstrar a seqüência de atividades de um processo através de comportamento paralelo e condicional. O diagrama de atividade assim como o de estado também possuem um estado inicial podendo ter mais de uma saída.

Considerações Finais

Os diagramas comportamentais demonstrados aqui são uma pequena parte do que a linguagem UML pode trazer, apesar disso, esses diagramas são muito úteis para se ter uma melhor visualização do funcionamento (ou comportamento) do sistema.

Individualmente o diagrama de caso de uso auxilia e facilita a comunicação entre o cliente e o analista de sistemas, e os diagramas de estado e atividade podem ser muito úteis para alterações posteriores já que demonstram as funcionalidades do sistema onde é possível visualizar o que pode ser alterado e não ocasionar erros em partes do sistema que estão funcionando.

Por Daniel de Oliveira
Artigo do Seminário de Engenharia de Software
Revisão Thiarlei Macedo | Fonte Micreiros.com

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *