O comprador tem compras cadastradas em seu nome.

1.4.2a.1 O sistema informa que é impossível excluir o

comprador, pois ele já tem compras em seu nome.

1.4.2a.2 O caso de uso é abortado.

Nota-se na fi gura 5.16 que a exceção “CPF já cadastrado” serve a dois passos: 1.1.1 e 1.3.2.

5.9. Outras Seções de um Caso de Uso Expandido

Desde que Jacobson (1992) criou o conceito de casos de uso, várias versões de formato têm sido apresentadas. Cada uma das propostas apresen- ta diferentes elementos. Pode-se considerar que as seções “fl uxo principal” e “fl uxos alternativos” são fundamentais em qualquer descrição de caso de uso expandido. Porém, outras seções podem ser incluídas se o analista sentir necessidade: atores, interessados, precondições, pós-condições de sucesso, re- quisitos correlacionados, variações tecnológicas e questões em aberto, apenas para citar alguns exemplos.

5.9.1. Atores

A seção “atores” lista quais os tipos de entidades do mundo real que interagem com o sistema através do caso de uso. Atores podem ser tipos de pessoas como compradores, fornecedores, vendedores, operadores etc.

Atores também podem ser classes de sistemas externos ao sistema sen- do desenvolvido, mas que interagem com ele. Por exemplo, se for necessário autorizar pagamento com cartão de crédito através do sistema da empresa emissora do cartão, esse sistema externo poderá ser considerado como um ator.

Atores humanos ou sistemas externos interferem no sistema e recebem informações dele através de uma interface.

No caso de atores humanos, as informações são passadas para o sistema através de dispositivos de entrada de dados, como teclado, mouse ou leitores especiais. O recebimento de informações do sistema pode se dar através de interfaces, como monitor de vídeo, impressora ou outros dispositivos espe- cializados.

A comunicação com atores que são sistemas externos se dá usualmente através da rede. Nesse caso, a interface de comunicação é a rede, através da qual o sistema envia informações aos atores e aguarda que esses atores res- pondam à comunicação, o que corresponde à ativação de alguma operação de sistema no sistema original.

Não se deve confundir a ideia de sistemas externos (atores) com siste- mas internos usados como módulos na implementação do sistema de infor- mação. Um sistema gerenciador de banco de dados, usado para implementar a persistência das classes do sistema sendo desenvolvido, por exemplo, não é um ator, mas um módulo dentro da arquitetura interna do sistema. As regras a seguir podem ajudar a identifi car apropriadamente os sistemas externos que seriam efetivamente atores:

a) sistemas atores são sistemas de informação completos e não apenas bi- bliotecas de classes ou módulos de programas, como sistemas geren- ciadores de banco de dados ou bibliotecas de classes de interface. Esses sistemas detêm algum tipo de informação que pode ser trocada com o sistema sendo desenvolvido;

b) sistemas atores estão fora do escopo de desenvolvimento do sistema atual, ou seja, o analista e sua equipe não terão necessariamente acesso ao pro- jeto interno desses sistemas nem a possibilidade de alterar suas funções, devendo adequar a comunicação entre o sistema em desenvolvimento e o sistema ator às características do sistema ator, visto que este não pode, a princípio, ser modifi cado.

5.9.2. Interessados

Nem sempre apenas os atores são interessados em um caso de uso. Ou- tros setores da empresa poderão ter interesse nos resultados produzidos pelo caso de uso. Por exemplo, em um caso de uso de venda de livros, os atores são o comprador e a operadora de cartão. Mas os resultados desse caso de uso po- derão interessar ao departamento de estoque e ao departamento de contabili- dade da empresa, pois os resultados de uma venda afetam tanto a quantidade de livros em estoque quanto a quantidade de dinheiro em caixa ou a receber. Assim, mesmo que esses departamentos não sejam participantes diretos no caso de uso, podem ser listados como interessados.

A utilidade de listar tais elementos em um caso de uso reside no fato de que um caso de uso deve procurar satisfazer todos os interessados. Assim, essa documentação poderá ser útil para lembrar ao analista algumas informações que precisam ser armazenadas, processadas ou transmitidas, para que essas expectativas possam ser satisfeitas.

5.9.3. Precondições

Por defi nição, precondições são fatos considerados verdadeiros antes do início do caso de uso. Não se deve confundir as precondições com as exceções, visto que estas últimas não são necessariamente verdadeiras antes do início do caso de uso. As exceções podem ocorrer durante a execução justamente por- que não se pode garantir que elas não ocorram. Não é possível, por exemplo, garantir que o comprador terá dinheiro para pagar a dívida antes de iniciar o caso de uso. Portanto, isso é uma exceção. Entretanto, é possível assumir que um comprador não poderá em hipótese alguma comprar um livro que a livraria não tenha disponibilizado no catálogo. Essa disponibilização pode ser então considerada como uma precondição.

Como as pre-condições são dadas como verdadeiras antes do início do caso de uso, resulta que elas não serão testadas durante a execução do caso de uso. Ou seja, as precondições, dessa forma, não gerariam exceções. Simples- mente seria impossível iniciar o caso de uso se a precondição fosse falsa. 5.9.4. Pós-condições de Sucesso

As pós-condições estabelecem normalmente os resultados do caso de uso, ou seja, o que será verdadeiro após sua execução. Por exemplo, o caso de uso “Comprar livros” pode ter como pós-condições os seguintes resultados: “foi criado um registro da venda dos livros para o comprador” e “o setor de entregas foi notifi cado da venda”.

Os resultados de um caso de uso podem ser bem variados em sua na- tureza, o que difere bastante das pós-condições de operações de sistema, que serão estudadas no Capítulo 7, e que são bem mais formais.

5.9.5. Requisitos Correlacionados

Quando a análise produz um documento estruturado de requisitos (ini- ciado normalmente na fase de concepção e incrementado ao longo da fase de elaboração), pode ser útil correlacionar esses requisitos aos casos de uso.

A correlação entre requisitos e casos de uso permite ao analista perceber se ainda existem requisitos não abordados.

Para simplifi car o processo de associar um requisito a um caso de uso, usualmente coloca-se o código alfanumérico de cada requisito na seção cor-

respondente do caso de uso ou usam-se relações de rastreabilidade (setas tra- cejadas com o estereótipo <<trace>>).

5.9.6. Variações Tecnológicas

Um caso de uso de análise deve ser descrito no nível essencial e, portan- to, não deve tratar de aspectos tecnológicos. Porém, algumas vezes, pode ser interessante registrar, para a atividade de projeto, possíveis variações tecnoló- gicas que poderiam ser utilizadas para realizar o caso de uso.

Por exemplo, o passo do caso de uso Comprar livros, que corresponde à identifi cação do comprador, pode ter como variações tecnológicas a digita- ção do CPF ou do nome do comprador em um campo apropriado ou outro código qualquer. Se essas possibilidades estiverem sendo consideradas para o desenvolvimento do sistema, então podem ser listadas na seção “variações tecnológicas”.

5.9.7. Questões em Aberto

Muitas vezes, o analista, trabalhando sem a presença do cliente, não sabe como decidir sobre determinado assunto que pode depender de políti- cas da empresa. Por exemplo, se o usuário pode pagar a dívida a prazo ou se existem promoções para usuários que compram certa quantidade de livros, e assim por diante.

Essas dúvidas devem ser documentadas na seção “questões em aberto” para serem resolvidas no momento em que o cliente estiver disponível. No fi - nal da atividade de análise, espera-se que todas as questões em aberto tenham sido resolvidas e incorporadas à descrição do caso de uso expandido.

6