Por que casos de uso não são “funções”

1
UNIVERSIDADE FEDERAL DE SANTA CATARINA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
DISCIPLINA: PROJETOS I
RESUMO: Por que casos de uso não são “funções”
Retirado de http://www106.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/WhyUseCasesAreNot
FunctionsDec00.pdf
ALUNO: RODISON DOS SANTOS FERREIRA
A maior parte das pessoas pegam o caminho errado quando começam a trabalhar
com casos de uso. Talvez isto aconteça devido à similaridade dos diagramas de casos
de uso e os diagramas de fluxo de dados, os quais conduzem as pessoas a definir
casos de uso que são simplesmente funções ou itens de menu.
Os casos de uso deveriam ser na verdade uma história sobre um meio de um
sistema fazer alguma coisa realmente útil. Quando temos casos de uso como “Adicionar
Ordem de Serviço”, “Excluir Ordem de Serviço”, “Alterar Ordem de Serviço”, “Aprovar
Ordem de Serviço” e “Avaliar Ordem de Serviço”, estes casos de uso não representam
coisas úteis independentes uma das outras. Na verdade, eles representam todas as
coisas que um sistema deve fazer, mas também representam uma única coisa que o
cliente quer fazer, que é “Fazer uma Ordem de Serviço”. Este é um exemplo de erro de
casos de uso baseados em opções de menu ou como funções. Este tipo de erro
também é conhecido como “decomposição funcional”.
Todos estes elementos remanescentes são fluxos alternativos de um único caso
de uso. Há passos que devem ser seguidos quando se estabelece uma ordem de
serviço. Quando há somente uma coisa realmente útil, há somente um único caso de
uso. O exemplo acima é um exemplo de decomposição funcional.
Este é um problema muito comum. Mas o que faz as pessoas caírem nesta
armadilha? No caso da decomposição funcional, nós temos uma tendência natural de
2
quebrar um problema em pequenas partes. Isto devido à crença de que quebrando um
problema em unidades cada vez menores nós estaremos simplificando o problema.
Esta percepção é errada; quando nós decompomos casos de uso nós na verdade
estamos misturando o problema.
Os casos de uso descrevem o que o sistema deve fazer em um nível conceitual
para que nós possamos entender o suficiente sobre o sistema para que possamos
decidir se o sistema fará o que deve fazer da maneira correta ou não. Eles nos
permitem formar um modelo conceitual do sistema.
Analisando melhor o exemplo, é necessário perguntar se o cliente pode querer
avaliar uma ordem de serviço se ninguém ainda fez uma ordem de pedido? Ou como
ele poderia querer alterar uma ordem de serviço se nunca a fez? Estas ações só são
necessárias se eu alguém fez uma ordem de serviço primeiro. No entanto, todas estas
ações são necessárias devido à habilidade do sistema em permitir ao cliente fazer uma
ordem de serviço.
Decompor o sistema em pequenos casos de uso na verdade obscurece o real
propósito do sistema. Ao extremo, pode-se acabar com um monte de pedaços isolados
de comportamento. Como resultado disso, não é possível dizer o que o sistema faz. É
como não ver um carro, mas sim todas as peças que compõem um carro. Se todas as
peças que compõem um carro fossem mostradas em separado, sem nenhum ligação,
ficaria muito mais difícil perceber que todas aquelas peças formam um carro.
Quando se trabalha com casos de uso, é preciso lembrar que os casos de uso são
um meio de pensar sobre todo o sistema e um forma de organizá-lo em pedaços de
funcionalidades gerenciáveis, pedaços que façam alguma coisa útil. Para ter um
conjunto correto de casos de uso, é necessário perguntar: “O que os atores estão
realmente tentando fazer com o sistema?”
3
No caso do exemplo, todos aqueles casos de uso poderiam se resumir a um único
caso de uso chamado “Navegar no Site e Fazer uma Ordem de Serviço”. Isto porque
este caso de uso se foca no que o cliente quer do sistema e não em como subdividir e
estruturar a funcionalidade dentro do sistema. Se você separar todas estas funções em
casos de uso separados, você forçará o cliente (que está pagando o sistema) a
reconstruir os casos de uso decompostos em alguma coisa realmente significante para
ele para que ele possa entender se o que o sistema descreve é aquilo que ele quer.
Grandes quantidades de casos de uso são um problema comum. Um problema
com isso é acabar criando um sistema difícil de se entender e de se usar.