Boa tarde,
eu trabalho com análise de requisitos e faço a documentação de caso de uso no EA utilizando o diagrama de caso de uso também.
Cada caso de uso é representado por uma elipse que corresponde a uma funcionalidade ou rotina do sistema. Nosso sistema é um ERP e também fazemos a especificação e diagrama para relatórios do sistema.
Como o diagrama é focado por rotinas/funcionalidade, eu tenho por exemplo a especificação de caso de uso do relatório Imprimir Pedido de Venda e tenho anexado o diagrama de caso de uso ao documento de especificação.
Então tenho Usuário 1 ligado ao caso de uso Imprimir Pedido de Venda. Logo, para extrair os dados e apresentar no relatório, eu preciso do cadastro do pedido de venda UC Incluir Pedido de Venda.
Neste caso eu atribuí o relacionamento de include Imprimir pedido -------include------> Incluir pedido.
Muitas das empresas em que trabalhei, nao havia documentação de caso de uso para relatórios. Aplicávamos métodos simples de documentação onde nao tinha diagrama.
Aqui as pessoas enxergam que não existe relacionamento do imprimir pedido com o incluir pedido. Que o ator está ligado apenas ao imprimir, sendo assim, o relacionamento com a inclusão de pedido nao existe. No meu ponto de vista, isso quebra minhas pernas para visualizar a rastreabilidade dos relacionamentos direitos e indiretos entre as rotinas. Eu teria que ler tooooda a especificação pra saber os relacionamentos obrigatórios e não obrigatórios para execução de um determinado 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!