 |
|||||||
|
|||||||
|
Representação e Validação do projeto transacional mediante
Diagramas de Transição de Estados 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. 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.
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:
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 Qual é sua avaliação deste artigo? |
|||||||
|
| |||||||
|
[ Entre em contato ] com o(a) autor(a) deste artigo [ Convide um amigo ] ou colega a ler este artigo [ Imprima ] este artigo
| |||||||
As
telas (estado) são representadas com um retângulo (no exemplo, de bordas
arredondadas), com um nome representativo do estado correspondente.
(c) 2003-2006 IBRAU - Instituto Brasileiro de Amigabilidade e Usabilidade. Todos os direitos reservados.