Representação e Validação do projeto transacional mediante Diagramas de Transição de Estados

Novembro, 2004

Jorge Marmion


Há alguns dias, após me acomodar confortavelmente com todos os apetrechos possíveis para assistir um filme no DVD, escolhi, sem querer, a opção "Extras" do menu. Encontrei inúmeras opções, das quais nenhuma me interessava. Depois de tentar inutilmente retornar ao menu anterior apertando vários botões das dezenas de opções do controle remoto, não tive outra opção que me levantar, ejetar o filme e introduzi-lo novamente, para forçar a carga do menu inicial. "Se o programador tivesse planejado o menu com um Diagramas de Transição de Estados", pensei, "tivesse percebido na hora que faltava uma transição". Decidi, então, escrever este artigo.

Diagrama de Transição de Estados

Os Diagramas de Transição de Estados (State-Transition Diagrams) são utilizados há bastante tempo no desenvolvimento de sistemas. Atualmente são amplamente utilizados na metodologia ULM (Unified Modeling Language).

Ben Shneiderman propõe sua utilização no projeto e validação do projeto transacional, apesar de reconhecer que sua manipulação torna-se muito complexa a medida que a complexidade do sistema cresce.

O que é um Diagrama de Transição de Estados?

Um Diagrama de Transição de Estados (DTE) mostra todos os estados possíveis de um objeto, os eventos que mudam seu estado, as condições que devem ser satisfeitas antes que uma transição (mudança de estado) ocorra e as ações (atividades) durante a vida do objeto.

Um estado é qualquer condição na qual um objeto satisfaz uma condição, executa alguma ação ou aguarda por um evento.

Um evento é qualquer acontecimento que provoca uma transição de estados. Pode ser um sinal externo ao sistema ou um sinal emitido pelo sistema por: (a) o transcurso de um período determinado de tempo ou (b) a satisfação de uma condição pré-determinada.

Uma transição é a mudança de estado de um objeto

Uma ação é a resposta de um objeto à mudança de estado.

DSTs aplicados ao projeto transacional

Em uma transação que interage com o usuário há dois estados possíveis: o sistema está aguardado alguma ação por parte do usuário ("wait state"), ou está processando algum comando ("execution state"). Se consideramos o conjunto de estados, eventos, transições e ações de uma transação qualquer, obteremos uma árvore que, dependendo das características da transação, pode se tornar bastante complexa. Mas a análise desta árvore, representada através de um DTE, pode nos dar indícios de erros no fluxo transacional.

Notação

A notação clássica de um Diagrama de Transição de Estados, ou até a notação utilizada na ULM, merece certas adaptações para ser utilizada no projeto transacional. Clique e veja uma versão muito simplificado de um DTE que representa transação de comércio eletrônico (e-commerce).

Utilização

Além de utilizar esta ferramenta para validar o fluxo de um transação, eu a utilizo freqüentemente como meio de comunicação com o usuário, antes inclusive de projetar os protótipos das telas, para discutir diferentes alternativas de implementação transacional, e acho esta uma facilidade notável: fácil de aprender, fácil de ensinar (até para um usuário leigo) e muito efetiva.

Ferramentas

Minhas ferramentas preferidas, particularmente no diálogo com um usuário, são o "flip chart" e uma boa caneta hidrográfica. Com estes dois simples elementos consigo capturar rapidamente o que usuário propõe, ou apresentar minhas próprias propostas de uma forma facilmente compreensível. Particularmente, depois de ter visto inúmeros projetos desenvolvidos em ferramentas automatizadas, nenhum dos quais refletia a realidade, fiquei bastante arredio à documentação estática extra-sistema. Minha proposta é utilizar o DTE como ferramenta de trabalho.

Representação

Não há um consenso quanto à representação de um diagrama transacional através de DTEs. Portanto, permitam-me apresentar as adaptações que desenvolvi durante vários trabalhos e satisfazem plenamente minhas necessidades.

As telas (estado) são representadas com um retângulo (no exemplo, de bordas arredondadas), com um nome representativo do estado correspondente.

A transição é representada por uma seta, na qual geralmente associo alguma descrição. Há transações que transportam dados (por exemplo, os dados de cadastro digitados em uma tela que são novamente apresentados na tela seguinte) e outras que não transportam informação (a transição a uma tela de ajuda provocada por teclar F1, por exemplo).

Quando entre dois estados há uma ação que acho (subjetivamente) importante documentar, a represento mediante um círculo, no qual descrevo sucintamente o objetivo da ação ("validar crédito", "gerar código de reserva", etc).

Quanto aos eventos são muito difíceis de encontrar em transações comuns. Só para exemplificar, é um evento a aparição de uma nova aeronave no espaço aéreo monitorado por um Centro de Controle de Tráfego, ou o sinal emitido por um sensor quando uma máquina atingiu um nível de pressão crítico. Eu desconsidero eventos tais como "usuário pressionou a tecla Iniciar", mas note que para o estado "Consulta CEP" a tecla PF5 é um evento.

Validação

A grande vantagem de um Diagrama de Transição de Estados, mesmo reconhecendo a dificuldade citada por Shneiderman, é que a detecção de erros ou inconsistências no fluxo transacional torna-se evidente e rapidamente localizável.

O principal aspecto a validar é o próprio fluxo transacional. Veja o DTE parcial do exemplo que citei logo no começo do artigo:

Nota-se imediatamente que não há retorno do estado "Extras" ao estado "Menu Inicial", justamente o caso que citei.

Veja os DTEs de duas implementações diferentes (são casos reais de duas instituições bancárias brasileiras) de uma transação de consulta ao extrato de conta corrente. O DTE começa após a validação do usuário:

Eis a segunda alternativa:

Note que a primeira alternativa é bem mais amigável: requer somente um clique (na opção correspondente) para obter os lançamentos dos últimos dias. A segunda alternativa é (desnecessariamente) mais complexa, e apresenta um ponto bastante criticável: se ao mostrar as contas correntes o usuário clica em "Continuar" mas não seleciona nenhuma conta, uma tela é apresentada com a mensagem "Nenhuma conta selecionada", e o usuário deve retornar à tela anterior para selecionar uma das contas.

Você deve verificar também que atalhos e opções são compatíveis e equivalentes. Para tanto é recomendável sempre documentar as transições com os códigos correspondentes. É inadmissível ter, por exemplo, uma transição ativada com a opção "Saldo Conta Corrente" e outra como "Saldo Conta Corrente". Também é desaconselhável em um estado oferecer a consulta à relação de CEPs clicando F5 e em outro a consulta aos códigos de Estado clicando F3, por exemplo.

Outras verificações a considerar são:

  • Existem retornos aos estados anteriores?
  • Todos os eventos aos quais responde o estado foram contemplados?
  • É possível alcançar todos os estados?
  • Há estados desnecessários?

Conclusão

Depois de um pouco de prática, a utilização de Diagramas de Transição de Estados para elaborar, apresentar e verificar o fluxo transacional torna-se bastante útil e efetiva. Mas lembre: fuja da tentação de documentar; esta é, ao menos parar mim, uma ferramenta de trabalho, que eu acho quase que imprescindível ao definir uma transação junto com o usuário ou ao elaborar alternativas junto com meus colegas.

PS: Quem é Ben Shneiderman?

Ben Shneiderman (Ph.D.) é meu guru, e entre outras muitas coisas, professor do departamento de Ciências da Computação da Universidade de Maryland. É o autor do que considero o livro mais importante na área: "Designing the User Interface: Strategies for Effective Human-Computer Interaction", que consulto regularmente. Se você não tem esse livro, corra e compre-o. O endereço do seu site (bem feijão-com-arroz, mas altamente efetivo) é http://www.cs.umd.edu/~ben/


Gostaríamos de ouvir sua opinião sobre este artigo.

Conteúdo

Utlilidade


Entre em contato com o(a) autor(a) deste artigo

Convide um amigo ou colega para ler este artigo

Imprima este artigo


Topo da página

(c) 2003-2006 IBRAU - Instituto Brasileiro de Amigabilidade e Usabilidade. Todos os direitos reservados.

(c) 2006 IBRAU - Instituto Brasileiro de Amigabilidade e Usabilidade. Todos os direitos reservados.

Fale com o(a) colunista.

Você gostou do artigo Análise da usabilidade de uma aplica o de registro de sorteio?

A seguir os dados são opcionais

Deseja enviar uma mensagem a Jorge Marmion?

Seu nome:

E-mail

A produção do site não comercializará o endereço de e-mail acima, nem enviará correspondência indesejada

Preencha os dados abaixo e enviaremos à pessoa que você indicar um e-mail convidando-a a visitar o site e ler este artigo.

Seus dados:

Seu nome:

E-mail

Os dados da(s) pessoa(s) que você quer convidar:

Seu nome:

E-mail

Caso deseje convidar mais de uma pessoa, digite os endereços de e-mail separados por vírgula, sem espaços em branco
(exemplo: joão@uol.com.br,pedro@aol.com)

Caso deseje, envie uma mensagem junto com o convite

A produção do site não comercializará nenhum dos endereços de e-mail acima informados nem enviará correspondência indesejada aos mesmos.