Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- casos_de_uso:conceitos-uc [02/06/2015 20:42] – [Regra Geral] moises.simoes
+++ casos_de_uso:conceitos-uc [31/08/2017 01:11] (atual) – edição externa 127.0.0.1
@@ Linha 1: / Linha 1: @@
+[[:casos_de_uso|{{casos_de_uso:uc-icon.png?nolink&80 |}}]]
+\\ \\ \\
 ====== Premissas para Especificação e Estimativas de UC ======
@@ Linha 4: / Linha 6: @@
  **Casos de Uso:**
-  * Trata-se do tipo mais comum de representação de cenários na na fase de elicitação de requisitos, deve descrever a o comportamento do sistema em termos de sequência de ações.
+  * Trata-se do tipo mais comum de representação de cenários na fase de elicitação de requisitos. Deve descrever o comportamento do sistema em termos de sequência de ações.
-  * documento narrativo que descreve a sequência de eventos de um ator, usuário de um software, que vislumbra completar um processo de negócio.
+  * Documento narrativo que descreve a sequência de eventos de um ator, usuário de um software, que vislumbra completar um processo de negócio.
-  * Um caso de uso representa uma unidade discreta da interação entre um usuário (HOMEM ou DEVICE) e o software.
+  * Um caso de uso representa uma unidade discreta da interação entre um usuário (HOMEM ou DISPOSITIVO) e o software.
-  * Um caso de uso deve ser uma unidade de um trabalho relevante, como: o "autenticação no software", "registrar qualquer informação no software" ou ainda "criar pedidos" são, por definição, todos casos de uso.
+  * Um caso de uso deve ser a unidade de um trabalho relevante, como: "autenticação no software", "registrar qualquer informação no software" ou ainda "criar pedidos" são, por definição, todos casos de uso.
   * Cada caso de uso tem uma descrição da funcionalidade que será construída no sistema proposto.
   * Um caso de uso pode "usar" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio comportamento.
@@ Linha 15: / Linha 17: @@
  **Relatórios:**
-  - Todo o relatório terá seu filtro contido em um único caso de uso, representado como o fluxo principal. O resultado do filtro será representado como os fluxos secundários, alternativos e de exceção conforme cada situação.
+  - **Todo o relatório terá seu filtro contido em um único caso de uso**, representado como o fluxo principal. O resultado do filtro será representado como os fluxos secundários, alternativos e de exceção conforme cada situação.
-  - Em situações de implementação genérica de filtros, onde o filtro pode ser utilizado para mais de um relatório, nesse caso o filtro será tratado como um **caso de uso exclusivo**. Essas situações se justificam para que não haja duplicação de funcionalidades, reduzindo a coesão do sistema. Também para que haja reuso do filtro como caso de uso para novas implementações.
+  - Quando a manutenção evolutiva envolve o controle de uma nova **Entidade**, o **INSERIR**, **MANTER** e **FILTRAR** representam cada um, um novo caso de uso. Neste caso, o FILTRAR é uma ação que retorna os dados exclusivos da Entidade de referência, e pode ser utilizado por qualquer outro caso de uso do sistema, mantendo o paradigma de orientação a objetos, com resultados diretos na manutenibilidade do sistema, bem como, na redução de custos de manutenção evolutiva com o reaproveitamento dessa função.
  **Quantificação:**