Transcript Modelagem de Requisi..

►METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS
Prof. Dr. rer. nat. Daniel D. Abdala
e-mail: [email protected]
1
 Apresentar
técnicas para levantamento
de requisitos;
 Demonstrar como levantar requisitos de
usabilidade usando prototipação de
interfaces;
 Discutir a decomposição de requisitos
 Apresentar como levantar requisitos de
interação por meio de casos de uso.
2
 Problemas
relacionados ao levantamento
de requisitos
 Documento de descrição do projeto
 Decomposição de requisitos
 Classificação de requisitos
 Especificação de interfaces do usuário
 Diagrama de Casos de Uso
3
 Em que pé estamos?
• Sabemos quais os tipos de requisitos existentes
• Sabemos que requisitos podem ser definidos em
vários níveis de detalhamento
• Sabemos como descrever os requisitos usando
diagramas e tabelas
 E agora?
• Ao tentarmos especificar os requisitos nos
deparamos com problemas e incertezas.
• Solução – Precisamos de uma metodologia para
levantamento de requisitos!
4
 Um
bom ponto de partida para a
identificação dos elementos que comporão
o sistema
• Texto escrito pelo cliente e/ou usuário descrevendo
como eles imaginam o sistema;
• Precisa ser minerado para a extração de requisitos
• A extração de requisitos via a descrição textual do
sistema fornece uma maneira prática de levantar
muitos requisitos. No entanto aspectos dinâmicos
da execução do sistema podem não ser capturados
corretamente.
5
O sistema consiste em um programa que permite 1
ou 2 pessoas jogar damas. Uma interface gráfica
representado o tabuleiro é apresentada em estado
inicial com as peças dispostas a cada início de
partida. O jogador pode clicar na peça que deseja
mover e em seguida na casa para a qual a peça
deve ser movida. O sistema testará se o movimento
é válido e se este for o caso, a peça será
movimentada. O jogador pode também disputar
uma partida contra o computador. O computador
poderá jogar no modo “fácil”, “normal”,
“avançado”,“impossível”.
6

O sistema consiste em um programa que permite
1 ou 2 pessoas jogar damas. Uma interface
gráfica representado o tabuleiro é apresentada
em estado inicial com as peças dispostas a cada
início de partida. O jogador pode clicar na peça
que deseja mover e em seguida na casa para a
qual a peça deve ser movida. O sistema testará
se o movimento é válido e se este for o caso, a
peça será movimentada.
O jogador pode
também disputar uma partida contra o
computador. O computador poderá jogar no
modo
“fácil”,
“normal”,
“avançado”,
“impossível”.
7
 Permite
a identificação de funcionalidades,
restrições e entidades do sistema;
 Ótimo ponto de partida para a especificação inicial dos requisitos
 Problemas para a identificação de requisitos dinâmicos
 Serve como base para “entender” o
objetivo do sistema e planejar as entrevistas subseqüentes de levantamento de
requisitos
8
 Maneira
útil de definir requisitos de
interação com o usuário
 Fornece uma base para discussão de
funcionalidades com o usuário
 Parte visível do sistema, geralmente mais
suscetível a críticas e pedidos de
alteração
9
10
 Muitas
vezes a descrição inicial de um
requisito pode ser muito extensa
englobando diversas funcionalidades;
 Requisitos Funcionais e Não Funcionais
tendem a se misturar, principalmente na
etapa de elaboração de requisitos do
usuário;
Decompor requisitos significa dividir
requisitos complexos em dois ou mais
requisitos.
11
Registrar Cliente
O Sistema deve ser capaz de registrar Contas para Clientes,
recolhendo seus dados pessoais, de modo a identificá-los.
Ele deve exigir do Cliente um Login único e uma Senha,
para que ele possa ter uma Conta.
Registrar Cliente
O Sistema deve ser capaz de registrar Contas para Clientes,
recolhendo seus dados pessoais, de modo a identificá-los
Cadastrar Conta
O Sistema deve exigir do Cliente um Login único e uma Senha,
para que ele possa ter uma Conta.
12
 Requisitos
são a posteriori mapeados em
artefatos de software
 Requisitos bem definidos com escopo
específico são:
• mais simples de serem implementados
• Pertencerão a mesma unidade lógica
• Permitirão a adoção de uma arquitetura sólida
para o sistema
13
 Sistemas
reais tendem a ter centenas ou até
mesmo milhares de requisitos
 Classificar os requisitos auxilia a:
• Organizar os requisitos em subsistemas (pacotes)
• Executar o rastreamento de alterações
 Geralmente
apenas requisitos nãofuncionais são classificados, no entanto
também é possível aplicar algum tipo de
classificação aos requisitos funcionais
14
15
Casos de Uso (CdU) incluem tipicamente um ou
mais cenários que descrevem as interações que
ocorrem entre os atores e o sistema. CdUs também
documentam as exceções que ocorrem do ponto
de vista do usuário
 Cada CdU representa uma única interação
repetível que um usuário ou ator vivencia ao
utilizar o sistema
 Casos de uso podem incluir outros casos de uso
como parte de um padrão de interação mais
complexo.
 Eles também podem ser utilizados por outros casos
de uso para lidar com situações excepcionais
 Diagrama UML (Unified Modeling Language)
16

 Casos
de uso
 Atores
 Relacionamentos
envolvendo esses elementos
17
18
 Modelar
as funcionalidades do software
(os casos de uso)
• O que o software faz (e não como faz)
 Modelar
os elementos externos que
interagem com o software (atores)
19
 Uma
funcionalidade do software
 Atômica, completa (não uma fração)
 Externamente perceptível
 EX: cada uma das opções do menu de um
caixa eletrônico de banco
• emissão de extrato de conta corrente
20
 Associado
à noção de que um software
interage com o meio externo
 Representa uma entidade externa que
interage com o software sob modelagem
• Pessoa
• Equipamento (hardware)
• Outro software
 Função de um ator
• Representa a interação com um elemento externo
• Faz parte do sistema (elemento interno)
• Modela a interface com cada elemento externo
21
 Apenas
a identificação de uma funcionalidade, sem qualquer referência a como ela
é executada
22
 UML
prevê três tipos de relacionamentos
• Extensão
• Inclusão
• generalização
23
 Estabelece
uma relação em que um dos casos de
uso ou atores tem seu comportamento estendido
através do comportamento definido em outro caso
de uso.
 Freqüentemente expressa um fluxo alternativo
24
 Estabelece
que parte do comportamento
inerente a um caso de uso está definida em
outro caso de uso
• Um caso de uso contém o comportamento definido
em outro caso de uso
• Permite evitar repetições na modelagem
25
 Estabelece
uma relação de especialização entre dois casos de uso, onde
• Um corresponde a um comportamento genérico
• O outro, a uma especialização deste para alguma
situação específica
26
Utilização – indica que um elemento requer
o outro para ser utilizado. Relacionamento
básico dos CdUs;

Associação – representa uma associação
entre dois elementos do diagrama;

Implementação – o elemento origem
implementa o elemento destino ;

Invocação – CdU A em algum ponto faz com
que CdU B seja executado;

Precedência – CdU A deve ser executado
antes que CdU B o seja.

27
 Diagrama
de CdU fornece um resumo da
interação
 Detalhamento da interação deve existir
em forma textual em um documento
associado ao CdU
28
 Documento
de descrição auxilia na identificação de requisitos;
 Prototipação de Interfaces auxilia na identificação de requisitos de usabilidade;
 Requisitos devem ser decompostos para
que representem apenas funcionalidades ou
restrições atômicas;
 Requisitos dinâmicos podem ser melhor
levantados por meio de casos de uso.
29
 R. S. Pressman, Engenharia
de Software,
McGraw Hill, 6a Ed., 2002. Chap. 12.
 I. Sommerville. Software Engineering. 7th Ed.
Addison-Wesley, 2004. Chap. 7,16.
30