Diagramas de Atividade e Diagramas de Estado

Ricardo R. Gudwin DCA-FEEC-UNICAMP

Introduo
Neste texto, apresentamos um sumrios de dois tipos de diagramas UML: o diagrama de atividades e o diagrama de estados.

Diagrama de Atividades
O diagrama de atividades um diagrama UML utilizado para modelar o aspecto comportamental de processos. um dos diagramas que mais sofreu mudanas em seu meta-modelo, desde seu surgimento no UML 1.0. Neste diagrama, uma atividade modelada como uma sequncia estruturada de aes, controladas potencialmente por ns de deciso e sincronismo. Em seu aspecto mais simples, um diagrama de atividades pode ser confundido com um fluxograma. Entretanto, ao contrrio de fluxogramas, os diagramas de atividades UML suportam diversos outros recursos, tais como as parties e os ns do tipo fork e merge, alm da definio de regies de interrupo, que permitem uma modelagem bem mais rica do que simplesmente um fluxograma. Um exemplo de um diagramas de atividade simples mostrado na figura 1 a seguir.

Figura 1: Exemplo de um Diagrama de Atividades Simples Neste diagrama, o ponto preto esquerda indica o incio da atividade, as caixas com cantos arredondados representam aes, os pequenos losangos so ns de deciso e a barra vertical preta um n de sincronizao do tipo fork. Os arcos conectando as aes representam a sequncia em que as aes devem ser executadas, sendo que nos arcos que saem dos ns de deciso existem condies de guarda, que decidem qual ser a prximo ao a ser executada. Essas condies de guarda devem ser proposies mutuamente exclusivas, de tal forma que para n arcos saindo de um n de deciso, somente um deles pode ser verdadeiro a cada instante de tempo. Por fim, no canto direito do diagrama encontra-se um n de finalizao, que denota o final da atividade.

A figura 2 a seguir mostra um diagrama de atividades com parties. Diagramas com parties permitem que processos onde mltiplos agentes atuam, potencialmente em paralelo, possam ser representados.

Figura 2: Diagrama de Atividades com Parties

Ao
Uma ao representa um passo elementar de uma atividade, ou seja, um passo que no pode ser decomposto dentro de uma atividade. Uma atividade representa um comportamento que pode ser composto por aes ou outras sub-atividades. Uma ao pode ter um conjunto de arcos de entrada e de sada, que especificam o fluxo de controle e de dados para outros ns. Uma ao no inicia sua execuo at que todas as suas condies de entrada sejam satisfeitas. Somente quando uma ao terminada que a ao subsequente fica habilitada. Uma ao representada conforme a figura 3 a seguir:

Figura 3: Exemplos de Aes Alternativamente, aes podem ser definidas com pr-condies, que definem as condies necessrias para que a ao possa ser executada, e ps-condies, que definem o estado depois que a ao executada. Exemplos de situaes com essa podem ser vistos na figura 4 a seguir.

Figura 4: Aes definidas com Pr-condies e Ps-condies

Atividades
Atividades podem ser representadas por sequncias de aes e tambm de sub-atividades. Dessa forma, para representar uma sub-atividade dentro de uma atividade (ou seja, todo um conjunto de aes ou sub-atividades), utiliza-se uma representao semelhante a de uma ao, com um pequeno cone no canto direito inferior. A notao para uma atividade pode ser vista na figura 5 a seguir.

Figura 5: Exemplo de Atividade Do ponto de vista formal, uma atividade conforme representada na figura 5 no exatamente uma atividade, mas uma ao especial, chamada de CallBehaviorAction, que de maneira atmica invoca a execuo de toda uma atividade. Entretanto, para efeitos prticos, podemos entend-la como uma atividade de-per-si.

Eventos
Outros elementos que podem aparecer em um diagrama de atividades correspondem a eventos. Eventos so mudanas de estado instantneas que propiciam o incio de uma outra ao. Existem basicamente trs representaes para eventos. Para representar um evento nico que, caso acontea, propicia o incio de uma ao subsequente, utiliza-se a ao especial AcceptEventAction, representada pela notao indicada na figura 6.

Figura 6: Evento que Propicia o incio de uma Ao subsequente Para representar um evento peridico, que acontece de tempos em tempos, e a cada vez que acontea favorea o incio de uma ao subsequente, utiliza-se a notao apresentada na figura 7 a seguir.

Figura 7: Evento Temporizado Para representar a gerao de um evento deliberado, ao final de uma ao, utiliza-se a notao indicada na figura 8 a seguir.

Figura 8: Gerao de um Evento As figuras 9, 10 e 11 a seguir ilustram o uso de eventos junto com aes.

Figura 9: Evento e Ao correspondente

Figura 10: Gerao e Recepo de Evento

Figura 11: Exemplo de Evento Temporizado e Ao

Objetos
Alm do fluxo de controle, que especifica uma sequncia de aes que definem um processo, um diagrama de atividades tambm pode representar o fluxo de dados acontecendo em um processo. Esse fluxo de dados pode ser representado definindo-se explicitamente os objetos necessrios para que uma ao possa ser realizada, bem como os objetos gerados aps a finalizao de uma ao. Um objeto representado da mesma maneira que em um diagrama de classes, entretanto sem a necessidade de estar sublinhado. Alguns exemplos de uso de objetos podem ser vistos na figura 12 a seguir.

Figura 12: Exemplos do Uso de Objetos entre Aes Objetos podem tambm ser passados como parmetros para atividades completas. Veja o exemplo da figura 13.

Figura 13: Objetos como Parmetro para Atividades

Ns de Controle
Alm de aes, atividades, eventos e objetos, os diagramas de atividade admitem um conjunto de assim chamados ns de controle, pois controlam o fluxo do processso. Esses ns podem ser visualizados na figura 14 a seguir.

Figura 14: Ns de Controle O primeiro n de controle o n de deciso. Observe que um losango pode representar tanto um n de deciso como um n do tipo merge. Quando existe um nico arco de entrada no n e diversos arcos de sada, ele representa um n de deciso. Nesse caso, cada arco de sada deve indicar uma condio de guarda, entre colchetes, condio que deve ser satisfeita para caracterizar o respectivo arco como a sequncia de controle. Quando h diversos arcos de entrada e um nico n de sada, tem-se um n do tipo merge. Esse n utilizado para agregar diversos fluxos de controle em um s. O segundo tipo de n de controle o n de sincronizao. Esse n utilizado para representar fluxos de controle que ocorrem em paralelo, ou seja, aes que devem acontecer em paralelo. Ns de sincronizao podem ser de dois tipos diferentes. O primeiro deles um n do tipo fork, que ocorre quando se quer indicar que, a partir daquele instante, as aes subsequentes devem acontecer em paralelo. Um exemplo de um n do tipo fork indicado na figura 15.

Figura 15: Exemplo de N do tipo fork Na figura 16 temos o outro caso de sincronizao, o n do tipo join.

Figura 16: Exemplo de N do tipo join

Os ns do tipo join servem para indicar um ponto de sincronizao entre fluxos de ao que esto acontecendo em paralelo. Somente quando todas as aes que chegam a um join estiverem concludas que a ao consecutiva pode ser executada. O n de incio e de final j foram apresentados anteriormente. importante, entretanto, ressaltar a diferena que existe entre um n do tipo final de atividade e um n do tipo final de fluxo. Quando o final de uma ao alcana um n do tipo final de atividade, isso significa que a atividade como um todo, representada pelo diagrama termina. Quando o final de uma ao alcana um n do tipo final de fluxo, somente o fluxo em questo que termina, mas a atividade continua, em outros fluxos que estejam ainda em funcionamento.

Interrupes e Regies de Interrupo

Em diagramas de atividade UML 2.0, introduziu-se o conceito de interrupo e regies de interrupo. As interrupes (ou excesses) so notacionadas como arcos em forma de raio, conforme pode ser ilustrado na figura 17 a seguir.

Figura 17: Exemplos de Notao para Interrupes Pode ser interessante indicar o conjunto de aes onde as interrupes podem ocorrer. Quando isso for interessante, essas regies podem ser demarcadas por meio de retngulos com linhas tracejadas. Um exemplo desta notao encontra-se na figura 18 a seguir.

Figura 18: Regies de Interrupo Na figura 18 acima, representa-se que o evento de requisio de cancelamento de pedido s pode acontecer na regio demarcada, ou seja, enquanto alguma das aes dentro da regio estiverem sendo executadas. For a da regio de interrupo, o evento no deve ser considerado.

Pontos de Extenso
Para evitar que linhas longas conectando pontos extremos de um diagrama tornem o diagrama muito poludo, podem ser utilizados pontos de extenso. Um exemplo de um ponto de extenso pode ser visto na figura 19 a seguir:

Figura 19: Pontos de Extenso

Parties
Sem o conceito de parties, os diagramas de atividade UML funcionam meramente como extenses de fluxogramas. A introduo do conceito de partio traz toda uma rica gama de representaes para os diagramas UML. As parties podem ser representadas como indicado na figura 20 a seguir.

Figura 20: Exemplos de Parties

As parties servem para indicar que diferentes aes so executadas por diferentes agentes dentro de um processo. O caso mais interessante e que dos mais importantes para ns utilizar diagramas de atividade com parties para representar casos de uso. Nesse caso, uma partio utilizada para representar o usurio e outra para representar o sistema. Um exemplo apresentado na figura 21 a seguir.

Figura 21: Uso de Diagrama de Atividades para Representar Casos de Uso

Diagramas de atividade como os da figura 21 so utilizados para detalhar os casos de uso levantados durante a especificao do sistema. Nesses diagramas, assume-se que o usurio do sistema realiza certas aes e o sistema, em resposta, reage realizando certas tarefas. Com isso, o comportamento do sistema pode ser especificado.

Outros Recursos em Diagramas de Atividades

Os diagramas de atividades possuem ainda, de acordo com a verso 2.3 da norma UML, outros recursos no apresentados aqui neste texto, que podem elevar sobremaneira a complexidade do diagrama. Dentre eles, o recurso de regies de expanso, os pinos de entrada e sada, os ns estruturados, os conjuntos de parmetros e outros, podem ser consultados diretamente no texto da norma.

Diagramas de Estado (Mquinas de Estado)

Os diagramas de estado (ou mquinas de estado, como aparecem na verso 2.3 da norma UML) so utilizadas para modelar um comportamento discreto em sistemas de transio entre estados finitos. Existem basicamente dois usos para mquinas de estado: mquinas de estado comportamentais e mquinas de estado para protocolos. Mquinas de estado comportamentais podem ser utilizadas para especificar o comportamento de vrios tipos de elementos. Por exemplo, podem ser utilizadas para modelar o comportamento de entidades individuais (objetos), por meio da modificao dos valores de seus atributos. O formalismo de mquina de estados neste caso uma variante orientada a objetos dos Statecharts de Harel. Mquinas de estado para representar protocolos expressam as transies legais que um objeto pode desenvolver. Com seu uso, pode-se definir o ciclo de vida de objetos, ou uma determina ordem na invocao de suas operaes. Para este tipo de mquina de estado, interfaces e portas podem estar associados. Os diagramas de estado UML possuem diversos detalhes que o tornam uma poderosa ferramenta para a modelagem de transio entre estados. Entretanto, neste texto, no iremos tratar de todos seus recursos, nos limitando a abordar suas caractersticas bsicas. Leitores interessados nos detalhes mais sofisticados devem se remeter diretamente norma.

Estado
Um estado modela uma situao durante a qual alguma condio (usualmente implcita) se mantm. Essa invarincia tanto pode representar uma situao esttica, como um objeto aguardando que um evento externo ocorra, como condies dinmicas, como um processo apresentando um determinado comportamento. A notao para um estado pode ser visualizada na figura 22 abaixo.

Figura 22: Representao para um Estado Alternativamente, um estado pode ter seu espao interno subdividido em compartimentos, conforme ilustra a figura 23.

Figura 23: Exemplo de Estado com Compartimento Interno O compartimento interno pode abrigar uma lista de aes ou atividades que podem ser realizadas quando se entra (entry), sai (exit) ou permanece (do) no estado. Outros tipos de comportamentos podem tambm ser definidos. A figura 24 mostra um exemplo de um pequeno diagrama de estados que usa esses recursos.

Figura 24: Exemplo de um Diagrama de Estado

A notao para os arcos que ligam os estados pode assumir a seguinte sintaxe, visualizada na figura 25.

Figura 25: Notao para os Arcos entre Estados Os estados no necessariamente precisam utilizar os compartimentos internos. O diagrama mostrado a seguir na figura 26 tambm um diagrama de estados.

Figura 26: Estados sem Compartimentos Internos Os diagramas de estado UML podem adquirir nveis bastante sofisticados de complexidade. A figura 27 a seguir ilustra um pouco da complexidade possvel

Figura 27: Diagrama de Estados mais Complexo Como os estados de um diagrama de estados no demandam o uso dos compartimentos internos, observa-se que a notao bastante semelhante notao de uma ao em um diagrama

de atividades. necessrio, entretanto, deixar claro que os dois diagramas tm uma semntica bastante diferente entre si. Nos diagramas de atividades, o comportamento est expresso fundamentalmente nos ns do diagrama. Cada n representa um pedao de comportamento. No diagrama de estados, ao contrrio, todo o comportamento se encontra nos arcos do diagrama, sendo que os ns do diagrama de estados representa o que est nos arcos do diagrama de atividades, e os ns dos diagramas de atividades representam o que est nos arcos dos diagramas de estado. Assim, apesar de visualmente bastante similares, do ponto de vista semntico, o que representado em cada diagrama exatamente o oposto um do outro. Em termos notacionais, j houve uma grande mudana nos diagramas de atividades e diagramas de estado, passando-se da norma UML 1 para o UML 2. As aes do diagrama de atividades no UML 1 tinha uma notao ligeiramente diferente da atual, que se faz muito mais prxima dos estados do diagrama de estados. Este autor supe que no futuro, novas modificaes podero ocorrer nestes diagramas, para evitar ambiguidades.