Suponha que você tenha uma atividade no seu sistema que se chama “efetuar pagamento do boleto bancário no site homebanking do banco” e que você queira detalhar todas as ações pertinentes a esta atividade. Em primeiro lugar, vamos determinar quantas piscinas existirão:
- uma para a aplicação da empresa,
- outra para o sistema bancário e
- outra para as atividades manuais do operador do sistema.
Como essas informações tratam de ambientes distintos (dois sistemas distintos e um conjunto de operações manuais), o correto é utilizar piscinas (e não raias).
Feito isso, precisamos detalhar todas as operações necessárias (as ações):
- Acessar o site homebanking do banco;
- Localizar no menu de opções a funcionalidade “efetuar pagamento de boleto”;
- Clicar na funcionalidade;
- Preencher os dados de pagamento: data de vencimento, código de barras, valor, desconto (se houver);
- Digitar a senha de pagamento;
- Confirmar a operação;
- Digitar o código da operação bancária no sistema da empresa.
- Imprimir o comprovante de pagamento;
- Grampear o comprovante ao boleto físico;
- Guardar o comprovante e o boleto na pasta de contas pagas da empresa.
Veja como seria a representação do cenário acima com três piscinas (uma, para o sistema da empresa, outra, para o homebanking e outro, para as operações manuais).
Nesse caso, observe que a documentação extrapola o sistema de informação e detalha o próprio trabalho manual que é feito na empresa para efetuar o pagamento da conta. Observe que a documentação UML pode ter sua fronteira definida não só no sistema que estamos programando, mas percorrendo todas as ações que as pessoas têm de fazer para tudo funcionar a contento.