[RESOLVIDO] Diagrama de Caso de Uso

Olá Celia, como vai?

Acho que entendi sua linha de raciocínio para criar o relacionamento abaixo:

Imprimir pedido -------include------> Incluir pedido

Você o criou para se referir a necessidade de haver dados do pedido previamente cadastrado antes da impressão, certo?

Mas ao ler ela desta forma, minha interpretação é: toda vez que o caso de uso “Imprimir pedido” for executado, então OBRIGATORIAMENTE (include) o caso de uso “Incluir Pedido” também será executado.
Creio que não teria necessidade desse include, porque veja só, vamos imaginar que o sistema já está pronto e em operação segundo essa definição: toda vez que o usuário acessar a funcionalidade para impressão de pedido ele será obrigado a cadastrar um pedido. Está correto? Essa é realmente a necessidade exigida pela área de negócio?

No meu ponto de vista, a necessidade de haver dados do pedido cadastrados para realizar a impressão poderia ser expressa na seção “pré-condições” da especificação do caso de uso “Imprimir Pedido”. Aí sim seria detalhado os cenários principais e alternativos, pré e pós-condições e exceções desse caso de uso.

Aos demais colegas que trabalham levantando requisitos, deem suas opiniões também.

Abraços!

Olá Douglas, td bem?
Nas pré-condições eu cito as rotinas ou cadastros que a tela que está sendo especificada depende. Logo por se tratar de uma tela, esta pre-condição é um outro caso de uso q tem suas particularidades. Desta forma eu represento o caso de uso ligado ao caso de uso que está sendo especificado para poder rastrear depois pelos diagramas as dependências. Quando faço uma busca por caso de uso, a ferramenta mostra uma relação dos casos de uso envolvidos. Quando eu não faço essa conexão, a informação fica solta, tendo que ler toda a especificação e as regras pra enxergar os casos de uso envolvidos com a tela.
Porque eu vejo assim, caso de uso considerando a base sem cadastros, se eu for gerar um relatório de pedido de vendas, haverá um tratamento de mensagem de que não há dados a serem impressos, efetue tal cadastro. Logo existe a dependência da tela de cadastro, eu não tenho dados pra gerar no relatório se eu não cadastrar um pedido. Se a extração dos dados é por período de datas, a mesma coisa… se não houver cadastro durante o período, nao tenho dados no relatório.
Eu nunca considero um caso de uso como se a informação já existisse na tela, a não ser que seja um processamento interno. Nesses casos eu cito na regra de negócio que ocorre um processamento interno para geração de tal registro.

Olá Celia.
Tudo joia!

Entendi. Eu já usei o EA e realmente esse tipo de associação ajuda na rastreabilidade.

Lendo o cenário que você descreveu, mais especificamente essa parte:

“(…)considerando a base sem cadastros, se eu for gerar um relatório de pedido de vendas, haverá um tratamento de mensagem de que não há dados a serem impressos, efetue tal cadastro. Logo existe a dependência da tela de cadastro, eu não tenho dados pra gerar no relatório se eu não cadastrar um pedido.”

No seu ponto de vista, o que você acha da relação entre os dois casos de uso (IMPRIMIR PEDIDO e INCLUIR PEDIDO) ser tratada como EXTEND ao invés de INCLUDE?

Assumindo que através da funcionalidade de impressão o usuário PODE eventualmente realizar o acesso à funcionalidade de cadastro, o extend representaria melhor essa associação que deseja criar no EA para manter de modo mais fácil a rastreabilidade na ferramenta.

Abs!

Eu enxergaria como extend se eu tratasse a rotina de impressão de relatório como secundário. Como algo que eu posso ou não utilizar para consulta, ou seja, a impressão faz parte de um contexto mais importante que impressão, nesse caso eu faria a conexão como extend.

Considerando que o diagrama é FOCADO sempre pra uma rotina, independente da funcionalidade, eu vejo como uma dependência da geração dos dados que foram processados no cadastro. Porque isso?
Porque toda rotina do sistema é configurada por usuário, eu Célia faço pedido. O joão não faz pedido mas imprime o relatório de pedidos que é enviado ao estoque para separação dos produtos. Então o joão só vê a opção de imprimir e, se não houver cadastro, não imprime nada.
É difícil explicar, cada rotina tem seu diagrama de caso de uso com especificação e eles são tratados de forma isolada e não visto como um contexto de fluxos dos processos.

Você está pensando da forma errada. O relatório não depende do UC Incluir Pedido. Ele nem mesmo depende da existência de dados de Pedidos. É erro o relatório retornar vazio? Acredito que não. Você precisa desenvolver o UC Incluir Pedido para desenvolver o relatório? Também não. Onde existe essa dependência?

Essa ferramenta está te atrapalhando em vez de te ajudar.

Obrigada por sua contribuição!