quartaAulaEngenhariaDeRequisitos

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

terça-feira, 22 de maio de 2012
Quarta Aula
Capítulo 4
 Mastering the Requirement Process
Disciplina
 Engenharia de Requisitos
Prof.: Luiz Loja
1
Agenda da nossa Apresentação
Cronograma
 
 
1
Revisão
 
 
2
Caso de uso dirigido a evento
 
3
Conclusão
 
2
1
Revisão
O que já vimos?
 
 
 
3
Revisão
Necessidade de coleta de requisitos
O que são requisitos
Ciclo de desenvolvimento de software e requisitos
Dificuldades
Tipos de requisitos
Artigo
There is no Silver Bullet
4
Revisão
Processo de levantamento de Requisitos Volore
Ponta pé inicial
Coleta de requisitos
Prototipação de requisitos
Escrever os requisitos
Portal de qualidade
5
Blastoff
Ponta pé inicial
Primeira reunião
Trindade
Escopo
Colaboradores 
Objetivos
Criação do documento de visão
Escopo
Fronteiras do software
Áreas de domínio
O que devemos entender do trabalho
Sistemas adjacentes
Colaboradores
Tipos de colaboradores
Clientes
Consumidores
Usuários 
Especialistas
Consultores
Outros
Objetivo
PAM(Purpose, advantage e mesurement)
Propósito
O que o produto deverá fazer
Vantagem
A vantagem que produto proporcionará
Medição
Como é medida a vantagem
Documento de Visão
Propósito do projeto
O escopo do projeto
Os colaboradores
Restrições
Nomes
Fatos relevantes e suposições
Custo estimado
Os riscos
Primeiro protótipo de baixo custo
Fazer ou não fazer
10
Casos de uso dirigidos a eventos
Capítulo 3
11
Dividir o produto em casos de uso
Definir o melhor produto a se produzir
Blastoff define o escopo do projeto
Muito grande para ser estudado em apenas uma reunião
Dividir para conquistar
		"Não coma nada maior do que sua cabeça"
					Source B. Kliban
Corte em partes
Particionar o trabalho em partes gerenciáveis 
Caso de uso dirigido a evento
12
Casos de Uso
Criador Ivan Jacobson
"documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo".
Um caso de uso é uma técnica de modelagem usada para descrever o que um novo sistema deve fazer.
Descrever o trabalho a ser feito
Quebrar o sistema em partes pequenas
Baseado na visão do usuário do sistema
Estamos na fase de análise e não estamos preocupados com software nem hardware.
Caso de uso
14
Construído através de um processo interativo 
São feitas discussões entre o cliente e os desenvolvedores do sistema 
Estas discussões conduzem a uma especificação do sistema da qual todos estão de acordo.
Caso de uso
15
Os casos de uso tem por objetivo:
Decidir e descrever os requisitos funcionais do sistema.
Fornecer uma descrição clara e consistente do que o sistema deve fazer.
Permitir descobrir os requisitos funcionais das classes e operações do sistema. (Casos de uso NÃO são requisitos)
Entender o trabalho
Apresentar o sistema como uma visão do usuário
Visão geral das funções do sistema
Serviços desejados pelo usuário
Não preocupa com tecnologia ou implementação
Dica
Apresentar o diagrama junto ao protótipo
Caso de uso
16
Podemos dizer que os componentes de um modelo de casos de uso são :
Ator 
É um papel que tipicamente estimula/solicita ações/eventos do sistema e recebe reações. Cada ator pode participar de vários casos de uso
Casos de uso 
É documento narrativo que descreve a sequência de eventos feitos por um ator no uso do sistema.
Sistema 
O sistema a ser modelado
Caso de uso
17
O casos de uso consiste do diagramas de casos de uso 
Atores
Casos de uso 
Relacionamentos.
Caso de uso
18
Atores
Os papéis que os usuários podem assumir
Utilizar serviços e funções do sistema
Pode representar um sistema ou um hardware
Representado pelo menino feito de palitos
Casos de Uso
Serviços, tarefas ou funções utilizadas pelos usuários
Comportamento pretendido
Um caso de uso pode conter
Várias telas e funcionalidades
Relacionamento ou Associações
Interações e relacionamentos
Atores e Casos de Uso
Atores e Atores
Casos de uso e Casos de uso
Atores e Casos de Uso
Utiliza-se da funcionalidade do sistema
Requisição
Resultado
As setas representam a navegabilidade das informações
Do ator para o caso de uso
Do caso de uso para o autor
Ambos
Não representam o fluxo do processo mas sim dos dados.
Pode possuir descrição própria quando necessário
Três perguntas para as quais não existe uma resposta absoluta, são elas:
01. Como identificar atores?
02. Como descrever atores?
03. Como Identificar casos de uso?
Caso de uso
24
Identificar Atores
Para identificar os atores que vão participar do modelo devemos fazer as seguintes perguntas
 Quem usa o sistema?
 Quem inicializa o sistema?
 Quem fornece os dados?
 Quem usa as informações?
Usar abordagem dirigida a eventos 
Veremos mais tarde
Como descrever atores
Nome do ator (papel)
Descrição de seu papel no sistema
Como identificar os casos de uso
São interações entre usuários
Dividem-se em 
Ações do Ator
Atores sempre iniciam as ações
Ações do Sistema
Exemplo
Modelagem
Compra de item em um a loja com um terminal de ponto de venda
Exemplo
Quais são os atores?
Quem usa o sistema é o cliente e ele usa um terminal de caixa.
Como podemos identificar o caso de uso?
Podemos chamar este caso de uso de : Comprar Item.
Agora vamos a um descrição textual do caso de uso Comprar Item onde atuam os atores cliente e caixa.
Exemplo
Caso de Uso - Comprar Item
Atores - Cliente, Caixa
Descrição - Este caso de uso começa quando um cliente chega ao terminal com itens que deseja comprar. O caixa registra os itens , recebe o pagamento e emite uma nota fiscal. O Cliente recebe os itens comprados.
Documento textual
Descreve função do caso de uso
Etapas devem ser executadas
Atores
Sistema
Quais restrições e validações
Não existe formato específico
Utilizar linguagem simples
Documentação
Nome
Caso de uso geral
Ator principal
Ator secundário
Resumo
Pré-condições
Pós-condições
Sequência de ações
Restrições e validações
Fluxos alternativos
Exemplo
Considerações
Algumas considerações :
 Nomeie um caso de uso começando com um verbo, para enfatizar que ele é um processo.Ex: Cadastrar Cliente, Comprar Item, etc.
 Para identificar claramente um ator iniciador e um evento, comece a descrição da sequência de um caso de uso usando o seguinte esquema:
 Este caso de uso começa quando o <Ator>  <Evento que inicia o caso de uso>
Ex: Este caso de uso começa quando um cliente chega com vários itens para comprar
Exercício
			Suponha que você tenha um almoxarifado de peças onde clientes façam pedido e onde um operador receba tarefas do sistema para buscar peças para os pedidos dos clientes e distribuir peças do setor de compras para o almoxarifado. 
Resposta
Vamos identificar os atores.  
Cliente
Operador
Sistema 
Setor de Compras
Certo ou errado? Pq?
Resposta
Errado! Sistema não pode ser um ator pois ele não se ajusta ao conceito dado a um ator : 
Um agente externo ao sistema.
Um ator é um papel que interage com o sistema 
No lugar de Sistema poderíamos sugerir:
Administrador 
Gerente
Resposta
Cliente,  Operador, Administrador e Compras
Resposta
E os casos de usos, quais seriam?
solicita peças (ator Cliente)
entrega peças (ator Compras)
buscar pedidos (ator operador)
distribuir pedidos (ator operador)
cadastrar Tarefas (administrador)
Certo ou errado?
Resposta
Errado! No caso do ator operador ele não atua sobre o sistema 
Casos de uso buscar pedidos e distribuir pedidos , ele atua sobre o sistema realizando Tarefa;
Portanto, o certo seria: 
solicita peças (ator Cliente)
entrega peças (ator Compras)
realiza Tarefa (ator operador)
cadastrar Tarefas (administrador)
Reposta utilizando UML
Resposta
Próxima etapa: 
Refinamento do modelo 
Obter o relacionamento entre os casos de uso 
Generalização, 
Inclusão 
Extensão
Inclusão
Inclusão
Usada existe um serviço,situação ou rotina comum
Casos de uso utilizam-se deste serviço
Evita descrever a mesma rotina várias vezes
Se um caso de uso inicia ou inclui o comportamento de outro, dizemos que ele usa o outro caso de uso.
Inclusão indica obrigatoriedade 
Execução do primeiro obriga a execução do segundo
Comparado a chamada de uma subrotina
Inclusão	
Ex: No caso de uso Solicitar Pedidos de Peça  podemos incluir  Entregar Peças.
O relacionamento de inclusão em UML é ilustrado com uma linha de generalização com o rótulo <<include>>.
O relacionamento de inclusão em UML é ilustrado com uma linha de generalização com o rótulo <<include>>.
Inclusão
Sempre que o caso de uso Solicitar Pedido de Peças for acionado o caso de uso Entregar Peças também o será.
Inclusão
Inclusão
As propriedades básicas da inclusão são :
realizar um decomposição funcional;
reduzir a complexidade de um caso de uso;
O caso de uso básico não pode executar sem a inclusão;
Comportamento comum.
Reutilização do caso de uso
Extensão
Extensão
Eventos que não ocorrem sempre
Casos de uso que só ocorreram caso ocorra uma condição específica
Um teste para determinar se deve ser executado
Define pontos de extensão que adicionam comportamento a um caso de uso base descrevendo uma variação do comportamento normal. 
O caso de uso base pode ser executado mesmo sem a extensão.
Ex: O caso de uso Comprar Produto pode apresentar a extensão Compra por um Cliente Regular. Abaixo temos o diagrama UML.
Extensão
Extensão
Especialização ou Generalização
52
Especialização ou Generalização
Indica um caso de base que possui diferentes especializações e inclui comportamento ou sobrescreve o caso de uso base.
Existem dois ou mais casos 
 Possuem características semelhantes
Apresentam pequenas diferenças
Define-se um caso de uso geral 
Características compartilhadas
Define-se os casos de uso específicos
Características peculiares
Vantagens
Diminui a documentação
Herdam os outros tipos de associações
Especialização ou Generalização
O caso de uso Pagar fatura apresenta as generalizações: Pagamento com cartão  e Pagamento com Cheque, conforme o diagrama abaixo:
Generalização
Generalização
Além disto temos também os relacionamentos entre atores onde um ator especializado pode acessar os casos de uso de um Ator base.
O Ator gerente acessa os casos de uso do ator funcionário
Gerenralizando atores
Fronteira do Sistema
Fronteira
Retângulo que envolve os casos de uso
Separar atores das funcionalidades do sistema
Representa o ambiente que o sistema será executado
Contexto do sistema
Opcional
Estereótipos
Estereótipos
Permite extensibilidade
Marcar um componente com determinada característica
Notas
Notas
Registrar alguma observação
Ferramentas
Ferramentas
Jude -> Hasta 
Posseidon 
Dia
Rational Rose
 
 
3
Estou fazendo a coisa certa?
Conclusão
 
 
 
66
Luiz Fernando Batista Loja
Luizloja@gmail.com
 
Perguntas?
67