46 Engenharia de Software Magazine - Diagramas de Atividades

Geraldo Magela Dutra Gonalves

geraldo.magela@ufjf.edu.br
graduado em Engenharia Civil e possui es-
pecializao em Anlise e Desenvolvimento de
Sistemas, ambas pela Universidade Federal de
Juiz de Fora. tcnico em TI da Universidade
Federal de Juiz de Fora onde trabalha com
desenvolvimento de sistemas de informao e
informtica desde 1988. professor do Curso
Superior de Tecnologia em Anlise e Desenvol-
vimento de Sistemas da Fundao Dom Andr
Arcoverde em Valena, RJ.
De que se trata o artigo?
Esse artigo apresenta o Diagrama de Atividades,
modelo disponvel na UML para modelagem de
aes/atividades bem como uxo de controle
entre elas. Essa representao pode se dar em
vrios nveis diferentes demonstrando a versati-
lidade dessa ferramenta. Diagramas de ativida-
des podem ser poderosos aliados no esforo de
documentar de forma eciente um sistema em
construo.
Para que serve?
O artigo pretende estabelecer um guia descom-
plicado para estudantes e prossionais envolvi-
dos em anlise e desenvolvimento de sistemas
de informao. Ao reunir as caractersticas mais
utilizadas da notao, facilita o enquadramento
das diversas situaes de modelagem em busca
de facilidade e clareza.
Em que situao o tema til?
Tanto para equipes de desenvolvimento nas or-
ganizaes onde to preterida a atividade de
documentao, quanto no ambiente acadmico,
pela imensa e generalizada aplicao que se faz
nesses ambientes da UML Linguagem de Mo-
delagem Unicada.
Diagramas de Atividades
Abordagem Prtica Parte 3
A
abordagem prtica apresen-
tada nessa sequncia de ar-
t igos chega aos diagramas
de atividades, ferramenta fecunda de
modelagem, herdeira e sucessora dos
fluxogramas utilizados no passado para
declarao de lgica de programas. Esse
parentesco pode, a princpio, despertar
desconfiana numa parcela da comuni-
dade de desenvolvedores, por indicar
uma ferramenta orientada a processos
e no aderente orientao a objetos.
Mas esse preconceito no se justifica:
alm de trazer consigo a frtil notao
original dos fluxogramas, destinada
representao de estruturas sequencias
de deciso e de repetio, os diagramas
de atividades incorporam notao adi-
cional para representao de fluxos de
controle concorrentes e de fluxos de
controle tempo-dependentes (apesar da
UML oferecer um diagrama especfico
para essa necessidade, o diagrama de
temporizao), duas ocorrncias mui-
to comuns em modernos sistemas de
informaes.
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Edio 31 - Engenharia de Software Magazine 47
PROJETO
Diagramas de atividades modelam aspectos dinmicos dos
sistemas, e nessa caracterstica reside sua maior qualidade:
versatilidade. Como um conjunto de notaes destinado a
representar fluxos de controle, sua utilizao no se restringe
ao mbito computacional, estendendo-se deste ao mbito
organizacional.
Em sntese, diagramas de atividades podem ser emprega-
dos para descrever complexos processos de negcio, fluxos
de controle de casos de uso ou at simplesmente a estrutura
algortmica de funes individuais integrantes de atividades
de um sistema. Quando associados ao escopo de uma classe
ou ao escopo de um conjunto de classes (um pacote, por exem-
plo), podem representar a progresso da passagem de controle
entre mtodos das mesmas, documentando eficientemente as
cadeias de aes desenvolvidas pelo sistema. Um diagrama de
atividades pode referir-se ao script realizado pelos mtodos
de uma classe controladora de um caso de uso, dando nfase
s atividades e aes, e no troca de mensagens. Esse tipo de
representao complementar representao dos diagramas
de interao gerando um conjunto consistente.
Diagramas de atividades trazem tambm alguma herana
de redes PERT (Program Evaluation and Review Technique),
tcnica utilizada em engenharia civil para estabelecer a rede
de atividades a serem desenvolvidas em um canteiro de obras
e determinar, entre outras coisas, em combinao com a tcnica
CPM (Critical Path Method ), o caminho crtico dessa rede de
atividades, ou seja, aquele que determina o tempo total de
durao das atividades.
Definies bsicas e notao
Aparentados com os diagramas de transio de estados, dia-
gramas de atividades compartilham com aqueles uma parte
significativa da notao. Estados de ao e estados de atividade
so representados por um retngulo de cantos arredondados.
De forma coerente com os diagramas de estados, aes so
atmicas e atividades so conjuntos de aes e/ou atividades
encadeadas.
Um diagrama de atividades pode constituir uma grande ati-
vidade (no atmica) formada por diversas aes (atmicas) e/
ou sub-atividades. Entre duas aes e/ou atividades, uma seta
simboliza simplesmente o trmino de uma atividade e o incio
da outra. Em princpio no necessrio rotular esse elemento,
mas uma condio de guarda poder estar eventualmente as-
sociada a ele. Os smbolos de incio e final so idnticos queles
utilizados em diagramas de estados. A Figura 1, abaixo, apre-
senta essa notao.
Os fluxos de controle so tambm chamados transies,
embora no estejam associados com eventos. Representam
passagem de controle de uma atividade para outra. A literatura
tcnica referencia isso como tokens, espcie de sinalizador de
trmino de uma atividade e comeo da seguinte.
Como parte da herana dos fluxogramas, diagramas de ati-
vidades incorporam notao para representao de fluxos de
controle sequenciais, assim como para ramificaes originadas
a partir de decises. Caminhos alternativos so representados
por um pequeno losango que simboliza alternativas possveis
trilhadas atravs da avaliao de expresses de guarda. Adi-
cionalmente, uma expresso de exceo (else) pode ser acres-
centada. A mesma representao utilizada para fundir dois
fluxos de controle. As junes no representam sincronizao,
j que os caminhos da estrutura so mutuamente excludentes.
Nas ramificaes obrigatria a presena de uma expresso
de guarda associada a cada ramo, mas nas junes elas no se
fazem necessrias. A Figura 2 mostra essa notao.
Fluxogramas de sistemas e programas foram desenvolvidos em
harmonia com o paradigma estruturado de desenvolvimento de
sistemas (na verdade j existiam antes mesmo da programao
estruturada), que admitia processar apenas um nico fluxo de
controle por vez. Uma evoluo dos diagramas de atividades
admitir e incentivar a representao de fluxos de controle
concorrentes, caracterstica avanada das linguagens de progra-
mao orientadas a objetos. Uma barra em negrito, horizontal
ou vertical, utilizada para fazer a bifurcao. A partir dela, um
nico fluxo de controle transforma-se em dois ou mais fluxos
que executam simultaneamente. Quando tais fluxos so pro-
cessados, aquele de maior durao determina a durao total
da bifurcao (em semelhana s redes PERT/CPM) e o encerra-
mento dos fluxos concorrentes s se d aps a sincronizao dos
Figura 1. Notao bsica Figura 2. Pamificaoese1unoes
48 Engenharia de Software Magazine - Diagramas de Atividades
mesmos. A mesma barra em negrito sincroniza fluxos paralelos
e os finaliza. A Figura 3 mostra essa notao.
Aplicao no nvel de processos de negcios
Diagramas de atividades so empregados para modelar
desde rotinas isoladas, fluxos de controle de casos de uso at
os fluxos de controle de processos de negcio. Quando apli-
cado ao nvel de negcios, um diagrama de atividades mostra
diversas atividades que se encadeiam atravs da organizao
e, embora constituam um mesmo sistema, so comumente
desempenhadas por agentes diversos. Numa de suas mais
versteis utilidades, os diagramas de atividades separam as
atividades de cada agente envolvido em raias, espcie de com-
partimento que isola as aes exclusivas de um agente sem,
contudo, desconect-las do todo. Quando aplicadas ao escopo
de classes, cada raia pode congregar os mtodos realizveis
por instncias das mesmas, e o fluxo de controle entre elas. A
notao de raias tem o aspecto destacado na Figura 4.
Enquanto o fluxo de atividades realizado, diversas aes/
atividades manipulam objetos do sistema e eventualmente
provocam mudanas em seus estados. Uma caracterstica
interessante dos diagramas de atividades a representao
de fluxos de objetos (ou talvez fosse melhor denominar essa
representao de presena de objetos nos fluxos de controle).
Os objetos envolvidos em determinadas atividades (sejam eles
instanciados naquele momento, sejam materializados desde um
banco de dados ou simplesmente tenham sofrido um transio
de estado) so representados no diagrama de atividades com a
mesma notao de objetos utilizada em diagramas de objetos.
O estado que sofreu transao (se isso ocorreu) representado
dentro do objeto entre colchetes. Um fluxo de controle flui pelo
objeto em questo significando que a ao/atividade onde o flu-
xo se origina manipula o objeto representado, e eventualmente
provoca nele alguma transio de estado. Na Figura 5 esto
representadas as notaes para fluxos de objetos.
Figura 3. 8ifurcaoesesincronizaoes Figura 4. Raias
Aplicao no nvel de fluxos de controle
Para serem aplicados em diferentes escopos de utilizao, os
diagramas de atividades dispem de um rico conjunto de no-
taes. Representando rotinas, o desenvolvedor depara-se com
as situaes comuns do nvel de programao, quais sejam,
estruturas de deciso e estruturas de repetio/iterao.
Embora as estruturas de iterao possam ser representadas
com a notao mais bsica dos fluxogramas, os diagramas
de atividades passaram a contar com notao adicional mais
poderosa. Em determinadas situaes, as aes/atividades de
uma regio de um diagrama de atividades devem ser aplica-
das a um conjunto de elementos. Nessa situao, utilizam-se
regies de expanso nos diagramas.
Tais regies so representadas por uma linha tracejada que
agrega um conjunto de aes/atividades que sero aplicadas
a todos os elementos de um conjunto de entrada e geraro
vrios elementos em um conjunto de sadas. Na entrada dessa
regio de expanso coloca-se um elemento que representa a
coleo de entrada; chamado pino de entrada da regio. De
forma semelhante, na sada da regio de expanso situa-se
um pino de sada, representando a coleo de sada da regio.
Na maioria das vezes, a lista de entrada e a lista de sada tm
tamanhos idnticos, mas isso no constitui uma regra. As ope-
raes internas da regio de expanso podem estar associadas
Figura 5. Fluxos de objetos
Edio 31 - Engenharia de Software Magazine 49
PROJETO
a expresses booleanas que controlam a incluso de objetos na
matriz de sada; a matriz de sada, assim, pode conter menos
elementos do que a matriz de entrada. Nessa situao, preciso
utilizar um smbolo de final de fluxo, indicando que o fluxo
termina ali, para um determinado objeto da coleo de entrada.
A Figura 6 ilustra as notaes discutidas.
Modelando aes/atividades tempo-dependentes
A UML, em sua verso 2.0, disponibilizou um diagrama para
modelagem tempo-dependente, os Diagramas de Temporiza-
o, embora a literatura tcnica ainda no se refira muito a
eles. De qualquer forma, os diagramas de atividades dispem
de um subconjunto de notaes destinado a modelar situaes
onde o tempo um fator preponderante.
Estando sujeito a lapsos de tempo como fatores determinan-
tes de sua lgica, um sistema precisa desenvolver habilidades
para lidar com sinais. Estes entes so comumente gerados por
entidades fora do sistema (embora possa haver sinais gerados
internamente) e precisam ser reconhecidos por ele. Para tanto,
Figura 6.Pegioesdeexpansao
Figura 7. Modelagem de mecanismos tempo-dependentes
dois smbolos de estados especiais so disponibilizados: um
estado especial gerador de sinais e um estado especial reco-
nhecedor de sinais.
Adicionalmente, um smbolo de lapso de tempo est disponvel
(uma pequena ampulheta), permitindo modelar a dependncia
de um objeto, uma coleo de objetos (no caso mais til) ou ainda
de toda uma cadeia de aes/atividades em relao ao tempo. Na
Figura 7 esto representados dois trechos de um diagrama de
atividades com mecanismos tempo-dependentes. No primeiro
deles, a Atividade 2 s ser realizada quando as aes/ativida-
des que a precedem estiverem concludas e sincronizadas. Por
essa razo a barra de juno est direita das aes/atividades
participantes. Se a Atividade 1 se completar antes da chegada
do sinal, a juno aguardar at que ele chegue. Se o estado
reconhecedor receber um sinal e Atividade 1 estiver incompleta,
a juno ainda aguardar, at que ela se complete. No segundo
exemplo, os fluxos de controle paralelos so independentes e
esto em disputa; o primeiro a se completar encerra o fluxo
principal. Por isso, a barra de bifurcao est esquerda das
aes/atividades envolvidas. Em ambos os exemplos, existem
restries de tempo indicadas pela ampulheta.
Notaes complementares
Existe uma regra de ouro para modeladores de sistemas
com UML. Todo diagrama para ser til tem que ser legvel.
Grandes diagramas tornam-se confusos e dificultam o trabalho
de implementao que deveriam simplificar. O cruzamento
de diversas linhas nos diagramas so sempre um foco de
poluio visual que prejudica sua legibilidade. Como auxlio,
para evitar sucessivos cruzamentos, existem os conectores.
Eles servem para conectar aes/atividades que estejam em
regies afastadas do mesmo diagrama, evitando que longas
linhas o cruzem.
Quando usadas para modelar fluxos de trabalho ou opera-
es, as atividades s vezes representam exatamente um mto-
do de determinada classe e nesse sentido possuem parmetros
exatamente como esses. Se um diagrama de atividades usa
atividades representando mtodos que dependam de par-
metros de entrada, assim como necessitem gerar um retorno
de um determinado tipo, eles podem ser representados por
pinos, afixados no smbolo da atividade.
Aplicando as notaes para obter diagramas teis
Para exemplificar o desenvolvimento de diagramas de ati-
vidades claros e teis, o contexto apresentado e trabalhado
nos dois primeiros artigos dessa srie mantido. O escopo
simples e tem a vantagem de possuir regras de negcio bastante
intuitivas, o que simplifica seu entendimento.
Modelando lgica controladora de casos de uso
Uma primeira aplicao, embora no a mais nobre, dos diagra-
mas de atividades na modelagem da lgica controladora de um
caso de uso. Se o desenvolvedor optou por adotar um padro
de desenvolvimento em camadas, tal lgica estar presente em
diversas classes controladoras, cada caso de uso contando com
50 Engenharia de Software Magazine - Diagramas de Atividades
uma ou mais classes dessa categoria, dependendo da quantidade
de cenrios desse caso de uso.
A Figura 8 apresenta uma proposta de representao nesse
nvel. Embora estejam representadas apenas atividades, alguns
nodos do diagrama poderiam ser aes ou sub-atividades.
Alguma argumentao contra esse tipo de emprego apia-se
no fato de que os casos de uso j estaro especificados e que os
diagramas de sequncia j capturaram a abstrao de envio de
mensagens com o rigor necessrio, mas as descries textuais
dos casos de uso so um tanto pobres para representar deci-
ses, iteraes e processamento paralelo, e nesse particular, ao
contrrio, as representaes implementadas pelos diagramas
de atividades so bastante ricas.
Parece adequado concluir que, embora um diagrama de ativi-
dades no deva substituir a especificao textual detalhada de
um caso de uso ele pode ter um carter complementar, sobre-
maneira para fluxos de controle no triviais. Adicionalmente
podem ser mostradas raias, separando as responsabilidades de
diversas classes.
Modelando operaes e regras de negcio
Uma segunda maneira de emprego dos diagramas de ati-
vidades na modelagem da lgica de uma operao ou na
modelagem de uma regra de negcio. Na verdade essas duas
formas de representao so equivalentes, pois uma operao
complexa quase sempre uma operao que implementa uma
ou mais regras de negcio no triviais. Com um ou outro
nome, os diagramas de atividades estaro, nesse caso, repre-
sentando estruturas algortmicas bem prximas do nvel de
programao. Para exemplificar esse emprego, considera-se
um segundo caso de uso no contexto de controle acadmico
descrito no Quadro 1.
A especificao de casos de uso descreve textualmente as
regras de negcio empregadas em suas implementaes, e
essa tarefa, dependendo da complexidade da regra de neg-
cio, pode tornar-se difcil, tediosa e contra producente. Para
regras de negcio mais complexas e destinadas leitura por
uma audincia de tcnicos, muito mais produtivo e eficiente
descrev-las com diagramas de atividades. Mais uma vez, no
se trata de eliminar a descrio textual do caso de uso, mas de
complement-la e at mesmo enriquec-la com diagramas de
atividades. A Figura 9 apresenta um diagrama compacto que
apresenta de forma muito mais clara a RN01 descrita acima.
Modelando processos de negcio
Uma ltima forma de utilizao dos diagramas de atividades
a de representao de processos de negcio. til quando os
processos desenvolvidos pela organizao so de mediana a
grande complexidade e principalmente quando tais processos,
mesmo inseridos em um nico grande fluxo de trabalho, so
desempenhados por numeroso agentes diferentes, em sees
e departamentos diferentes. Nessa situao, os diagramas
de atividades capturam de forma singular as dependncias
existentes entre estes processos e sua sequncia natural,
fornecendo excelente viso do todo. A Figura 10, embora
Figura 8. Modelagem do fluxo de controle do caso de uso CriarMatrcula
AnalisarAprovao (CSU002)
Sumrio: A secretaria dispara esse caso de uso para um aluno ou para um conjunto de alunos,
obedecendo a um calendrio letivo.
Ator Primrio: Secretaria
Pre-condies: A secretria est logada no sistema.
Fluxo Principal: ...
Fluxo Alternativo: ...
Fluxo de exceo: ...
Ps-condies: Relaes com alunos aprovados e reprovados podem ser emitidas.
Regras de Negcio:
RN01: Para obter aprovao em uma determinada disciplina o aluno deve:
1. obter freqncia nas aulas no inferior a 75% do total de aulas ministradas no semestre.
2. perfazer mdia de avaliaes parciais (duas) no inferior a 3,0 pontos numa escala de 0 a
10 pontos.
3. se a mdia de avaliaes parciais for igual ou superior a 7,0 pontos o aluno estar aprovado
na referida disciplina.
4. se a mdia de avaliaes parciais for inferior a 7,0 pontos mas no inferior a 3,0 pontos o
aluno estar habilitado a prestar exames finais.
5. para obter aprovao na disciplina o aluno dever logra nota no exame final que produza
mdia final igual ou superior a 5,0 pontos.
Quadro 1. Especificao do caso de uso AnalisarAprovao
bastante simplificada, ilustra o emprego da ferramenta com
esse escopo.
Resumindo as boas prticas
Existem dezenas de dicas teis para se conseguir gerar bons
diagramas de atividades. Antes de procurar enumer-las, en-
tretanto, existe uma considerao sobre a aplicabilidade dos
diagramas de atividades que vale a pena explorar. Diagramas
de atividades na verdade parecem se situar na fronteira entre
UML como linguagem declarativa e UML como uma lingua-
gem executvel. Isso pode soar fantasioso, mas na verdade,
no . Diagramas de atividades representam atividades e aes
(ao computacional, atmica) o que abre uma possibilidade
real de gerar cdigo til a partir deles. Martin Fowler, em seu
livro UML Essencial, faz consideraes sobre uma UML exe-
cutvel, embora sem demonstrar grande entusiasmo. Mas o
estudo detalhado das possibilidades um assunto no mnimo
muito frtil.
Edio 31 - Engenharia de Software Magazine 51
PROJETO
Figura 9. Diagrama de atividades de uma operao ou regra de negcio
O Guia do Usurio UML, indicado na bibliografia, enumera
dicas valiosas para o emprego dos diagramas em dois nveis:
modelagem de fluxos de trabalho (o mesmo que processos
de negcio) e na modelagem de uma operao no trivial.
Operaes triviais e repetitivas, como operaes bsicas sobre
cadastros, por exemplo, no necessitam modelagem; elas so
demasiadamente triviais para serem facilmente desenvolvi-
das por programadores experientes.
Em relao modelagem de processos de negcio, funda-
mental estabelecer quais processos sero representados e no
procurar incluir todos eles; isso quase sempre impossvel.
Uma boa medida decidir primeiro a importncia de deter-
minados objetos, para depois incluir processos de negcio
relativos aos primeiros.
Cuidados especiais devem ser tomados na determinao
de pr-condies e ps-condies de execuo do diagrama
como um todo; esta uma maneira de, partindo de uma
condio inicial, alcanar um objetivo claro, que mantm
coerente o fluxo de operaes. preciso ter ou obter uma
viso bem clara da sequencialidade entre as aes/atividades
declaradas importantes. Quando certas partes de um diagra-
ma apresentam-se em mais de um lugar dentro do diagrama,
podem ser modeladas em diagramas exclusivos que sero
referenciados no diagrama original.
Uma das potencialidades da UML ser flexvel. Existem as
sintaxes bsicas, mas elas admitem representaes customiza-
das. tudo uma questo de uso racional da metodologia com
anuncia dos membros de uma equipe de projeto. Para usar
de forma no cannica a linguagem necessrio ser criativo
e inovar, e produzir diagramas legveis e teis. Quando o uso
das notaes mais ordinrias comear a produzir diagramas
confusos, hora de procurar substitu-las por notaes alterna-
tivas simplificadoras. Assim, pensam-se os fluxos sequenciais
em primeira instncia, ramificaes, e finalmente, em proces-
samentos paralelos. Esses ltimos so to comuns no mbito
computacional quanto no mbito organizacional.
Como ltima medida deve-se considerar a representao de
objetos no fluxo de trabalho como uma caracterstica muito
Figura 10. Diagrama de atividades modelando processos de negcio
importante. Importante por que promove integrao e exige
consistncia entre diversos modelos desenvolvidos por um
sistema: quando um objeto representado no diagrama de
atividades, ele precisa estar presente no diagrama de classes
desenvolvido priori; quando um estado de determinado
objeto exibido no diagrama de atividades, ele tem que estar
definido no diagrama de transio de estados daquele objeto e
tem que resultar de uma transio vlida declarada l; quando
uma regio de expanso utilizada no diagrama de ativida-
des, a matriz de entrada geralmente uma lista de objetos,
um multi-objeto que dever estar devidamente presente em
algum diagrama de sequncia. Essas dependncias entre os
diagramas os tornam coesos e consistentes.
A modelagem de operaes pode estar associada a qual-
quer elemento participante de qualquer modelo do sistema.
Se uma operao um mtodo de uma classe, um diagrama
de atividades que a modele estar associado a essa classe. Se
uma operao participa de um caso de uso, um diagrama de
atividades estar associado a esse caso de uso. De qualquer
forma, aplicado com esse escopo, os diagramas de ativida-
des estaro representando lgica intrnseca ao elemento ao
qual se associam.
Para representar lgica nesse nvel mais baixo necessrio
estar atento a entidades e comportamentos puramente com-
putacionais, como parmetros e tipos de retorno, assim como
atributos de classes participantes. Pr-condies e ps-con-
dies continuam teis para nortear o rumo das atividades.
Nesse escopo, os nodos do diagrama tendem mais a ser aes
do que atividades. As ramificaes estaro representando
estruturas de deciso. Aes computacionais concorrentes
devem pertencer a classes ativas (admitem threads).
Como considerao final sobre o emprego de diagramas
de atividades, considere que seu uso deve ser complementar
aos diagramas mais objeto-orientados natos, por assim
dizer. Diagramas de sequncia e diagramas de casos de
uso devem ser enriquecidos com diagramas de ativida-
des. O foco a organizao em classes de objetos, no em
funcionalidades.
52 Engenharia de Software Magazine - Diagramas de Atividades
Concluso
Os diagramas de atividades, assim como diagramas de sequ-
ncia e diagramas de estados, so ferramentas poderosas de
modelagem de sistemas. A resistncia demonstrada em adotar
seu uso pela comunidade de desenvolvedores reside muito
mais em uma cultura bem antiga arraigada nessa comunidade
do que em crticas quanto sua eficcia ou aplicabilidade.
Na verdade, desenvolvedores foram e so resistentes em de-
senvolver documentao, tanto de baixo nvel (programas bem
comentados) quanto de alto nvel (documentao de sistema).
Esse fenmeno consequncia de uma cultura voltada para o
imediatismo e pela concluso falaciosa de que sua supresso
abrevia o tempo de entrega do produto.
Embora isso possa at ser verdadeiro numa primeira avalia-
o, as consequncias dessa prtica podem revelar-se extre-
mamente onerosas na mais importante fase do ciclo de vida
dos sistemas: sua manuteno. Documentao de alto nvel
bem estruturada, um auxlio inestimvel na localizao de
artefatos que necessitem manuteno e embora isso seja sabido
h dcadas, nada mudou significativamente de l pra c. Essa
cultura s pode ser combatida na base, na prpria formao
do profissional que atua na rea.
Em relao ao emprego dos diagramas de atividades, a mes-
ma postura pragmtica adotada para diagramas de sequncia e
para diagramas de estados se aplica. A abordagem prtica no
deve tentar justificar documentao pobre. Trata-se de alcanar
um nvel de detalhamento que documente e fornea suporte,
sem se transformar numa tarefa consumidora de recursos de
pessoal e de tempo excessivos. Esse ajuste peculiar, tanto para
projetos quanto para equipes. Para serem teis, diagramas de
atividades devem apenas ser complementares s abstraes
dos outros diagramas do modelo, enriquecendo-os, e nunca
os substituindo.
Como regra geral, o emprego dos diagramas de atividades
deve ser explorado em necessidades especficas de modelagem.
Quando se torna necessrio compreender e modelar casos de
uso no triviais, a representao do fluxo de controle entre
as aes/atividades participantes pode contribuir muito. As
vises complementares fornecem input real para implemen-
taes mais elegantes e mais manutenveis.
Conforme j foi mencionado, operaes triviais no neces-
sitam modelagem. Operaes bsicas sobre cadastros, por
exemplo, costumam produzir diagramas de atividades muito
parecidos, tornando-os desnecessrios. claro que o projetista
confia na capacidade de seus programadores para desenvolv-
las corretamente. Entretanto, algumas operaes assumem
importncia tal, a ponto de tornarem-se fatores crticos para
o sucesso de determinado sistema. Alem destas, algumas
operaes, embora sem apresentar um grau muito elevado
de complexidade, podem empregar uma grande quantidade
de regras de negcio muito especficas de um domnio parti-
cular. Em ambos os casos, faz-se necessrio apresentar uma
especificao da lgica dessas operaes, o que pode ser feito
com facilidade utilizando-se diagramas de atividades. Na
representao de fluxos de controle concorrentes, diagramas
de atividades so insubstituveis.
Em contrapartida, existem situaes em que o emprego dos
diagramas de atividades deve ser evitado. Uma delas quando
se faz necessrio analisar como os objetos em uma colaborao
realizam um caso de uso. Essa abstrao da competncia
dos diagramas de sequncia. A incluso, em um diagrama de
atividades, de todos os objetos que participam da colaborao,
o tornaria extremamente confuso e descaracterizado. Outra
atribuio que no deve ser investigada por diagramas de ati-
vidades como um objeto muda seus estados durante seu ciclo
de vida. Embora os objetos possam figurar entre os elementos
dos diagramas de atividades, e embora seus estados possam ser
representados ali, demonstrar todas as transies a que esto
sujeitos, assim como os estados resultantes, atribuio dos
diagramas de transio de estados. Todavia, a representao de
objetos nos diagramas de atividades conecta-os aos diagramas
de estados, produzindo consistncia.
A sintaxe rigorosa, assim como a interdependncia de notao
e consistncia entre os diagramas de estados, diagramas de
sequncia e os diagramas de atividades, proporcionam uma
base estvel para que desenvolvedores de ferramentas CASE
de modelagem de projetos produzam sutes cada vez mais
teis e confiveis, que explorem com robustez a consistncia
entre modelos, tarefa que pode se tornar impraticvel para
seres humanos, notadamente em projetos de nvel mdio a
alto de complexidade.
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. 2.ed. Rio de Janeiro:
Campus-Elsevier, 2007. 370p.
BOOCH, Grady; RUMBAUGH, James; Jacobson, IVAR. UML: Guia do Usurio. 2.ed. Rio de Janeiro:
Campus-Elsevier, 2006. 474p.
FOWLER, Martin. UML essencial: um breve guia para a linguagem padro de modelagem de
objetos. 3.ed., Porto Alegre: Bookman, 2006. 160p.
BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML
2.2.ed. Rio de Janeiro: Campus-Elsevier, 2006. 496p.
Bibliografia
D seu feedback sobre esta edio!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
D

s
e
u
Feedbac
k
s
o
b
r
e

e
s
t
a
e
d i o