Transcript Análise de Requisitos

Análise ou Especificação de
Requisitos
Silvia Regina Vergilio - UFPR
1) Objetivos

O escopo do projeto é refinado em detalhe e
será produzida uma especialização de
requisitos.

Objetivos
Fornecer
informação
representações
traduzida

para
Projeto, dados
procedimentos,
arquitetura
1) Objetivos – Aspecto
Fundamental

Comunicação com o Uusário
“Eu sei que você acredita ter entendido o que
você pensa que eu disse, mas não estou certo se você
está ciente de que o que você ouviu não é o que eu
queria dizer.”
Cliente anônimo.
1) Objetivos - Documentos
Gerados

Especificação de Requisitos de Software

Manual Preliminar do Usuário

Plano de Projeto do Software (revisto).
2) Extração de Requisitos


Requisito: condição necessária para a
obtenção de certo objetivo ou para o
preenchimento de certo fim
Requisito de software: requisitos que o
produto a ser desenvolvido deve possuir
2) Extração de Requisitos



Requisitos funcionais: funcionalidade, o que o
software deve fazer
Requisitos não funcionais: confiabilidade
(disponibilidade, integridade, segurança),
acurácia, desempenho, interface HM,
portabilidade, etc.
Requisitos de desenvolvimento e
manutenção, procedimentos de controle e
qualidade
2) Extração de Requisitos –
Engenharia de Requisitos
Processo de transformação das idéias
que estão na mente do usuário
(entradas) em um documento formal
(saída).
2) Extração de Requisitos –
Dificuldades



Para conseguir informação pertinente.
Para lidar com a complexidade. (Tornar o
problema manipulável; detectar omissões,
inconsistências )
Para acomodar mudanças. (Coordenar,
avaliar impacto; corrigir defeitos sem gerar
erros)
2) Extração de Requisitos –
Principais Causas



1. Deficiências na comunicação
2. Técnicas e ferramentas inadequadas
3. Desconsideração de alternativas.
É necessário aplicar:
-princípios fundamentais de análise
-métodos sistemáticos de análise
2) Extração de Requisitos –
O Analista




Absorver fatos a partir de fontes
conflitantes ou confusas.
Entender os ambientes do usuário/cliente.
Comunicamos bem na forma verbal e
escrita.
“ Enxergar a floresta apesar das árvores”
2) Extração de Requisitos –
Engenharia de Requisitos




Passos:
Entendimento do domínio de aplicação
Extração e análise de requisitos:
classificação e organização
Especificação dos requisitos – modelos
Validação – necessidades do usuário
2) Extração de Requisitos –
Tarefas




1. Reconhecimento (identificação do
problema )
2. Avaliação do problema e síntese de
soluções gerais + critérios de validação.
3. Representação dos requisitos => software
4. Revisão da especificação reexame do
Plano de Projeto de Software.
2) Extração de Requisitos –
Quem participa

desenvolvedor

pessoal de apoio e documentação

usuários ou potenciais usuários

outras fontes de informações: pessoas e
documentos
2) Extração de Requisitos –
Procedimentos Genéricos





Perguntar – identificar o usuário
Observar e inferir – comportamento do
usuário, inferir suas necessidades
Negociar a partir de um conjunto padrão de
requisitos
Estudar e identificar problemas
Supor – se o produto é novo comparar com
existentes
3) Técnicas de Extração de
Requisitos - Entrevistas

Identificar candidatos

Preparação para entrevista



agendar
preparar questões
Condução da entrevista
3) Técnicas de Extração de
Requisitos - Entrevistas

Condução da entrevista






apresentação e objetivos
esperar respostas incompletas
repetir frases do entrevistado com suas
próprias palavras
perguntas do tipo sim/não – dúvidas
não se perder em detalhes
o entrevistado precisa ter o contexto
3) Técnicas de Extração de
Requisitos - Entrevistas


Finalização
tempo, resposta à todas as perguntas
consolidar informações (5min),
agradecimentos
Geração de um documento escrito,
planejar próximos passos
3) Técnicas de Extração de
Requisitos - Braimstorming






Técnica para geração de idéias
Reuniões entre desenvolvedores e
usuários
Um líder é necessário
Geração e consolidação das idéias
Ausência de crítica e julgamento
Elimina dificuldades de comunicação
3) Técnicas de Extração de
Requisitos - PIECES


Geralmente é aplicada na análise de
produtos já existentes, mas pode ser
adaptada
Fornece um conjunto de categorias de
questões e de problemas para o
desenvolvedor extrair os requisitos
3) Técnicas de Extração de
Requisitos - PIECES
Seis categorias:
P - desempenho
I - informação
E - economia
C - controle
E - eficiência
S - serviços
3) Técnicas de Extração de
Requisitos - JAD
JAD – Joint Application Design
 Princípios básicos:





dinâmica de grupo
uso de técnicas visuais
manutenção do processo organizado e
racional
utilização de documentação padrão
Etapas: planejamento e projeto
3) Técnicas de Extração de
Requisitos - JAD
Seis tipos de participantes
 líder
 engenheiro de requisitos
 executor
 representantes do usuário
 representantes de produtos de sw
 especialista
3) Técnicas de Extração de
Requisitos - JAD
Adaptação
Sessão
Finalização
Preparar
Organizar
Equipe e
Material
Um ou mais
Encontros
requisitos
desenvolvidos e
documentados
Converte a
informação
final em um
documento
3) Técnicas de Extração de
Requisitos - Prototipação
1. Determinar se o software é um bom candidato



Áreas de aplicação : interface, . . .
Complexidade : desenvolvimento de muito código
inviabiliza a prototipação (particionável)
Característica do cliente e gerente
2. Representação Resumida de Requisitos
particionamento .
3. Um projeto rápido ( arquitetura e dados ).
=>
3) Técnicas de Extração de
Requisitos - Prototipação
4. Protótipo é criado e testado.




Técnicas de quarta geração
Reutilização de Software
Ferramentas de Videoconferência
Especialização formal + ambientes interativos.
5. Teste pelo usuário - sugestões (+importante).
6. Repetição de 4 e 5 até que todos os requisitos
sejam formalizados; ou que o protótipo tenha
evoluído.
4) Modelos para Especificação




Representam a realidade
Ajudam a organização e especificação
mas não na extração
Utilizam os princípios de abstração e
decomposição – lidar com complexidade
Existem diferentes tipos de
especificação ao longo do
desenvolvimento e em vários níveis.
4) Modelos para Especificação
– Especificação pode ser



Especificação dos requisitos – cliente e
desenvolvedor
Especificação de projeto geral –
projetista e implementador
Especificação de módulos –
programadores que utilizam e
implementam os módulos
4) Modelos para Especificação
Princípios - Boa Especificação





Separar funcionalidade de
implementação
Deve abranger o sistema do qual o sw é
um componente
Deve ser operacional (utilizável)
Tolerante a incompleteza
Consistente
4) Modelos para Especificação
Princípios - Boa Especificação

Realista

Fracamente acoplada e localizada


localizada: para que um único elemento
tenha que ser modificado
fracamente acoplada: permitir que adições
e remoções sejam feitas facilmente
4) Modelos para Especificação


Permitem a aplicação dos princípios de
ES.
Geralmente cobrem três dimensões do
sistema



dados (que dados ele mantém)
funções (o que o sistema faz)
comportamento (como ele se comporta –
estados e eventos)
5) Diagrama de Fluxo de
Dados – Modelo de Função
5) Diagrama de Fluxo de
Dados – Modelo de Função
O DFD é um modelo que nos permite
mostrar como a informação (dados) flui
através de um sistema (ou seja, como
ela vai sendo transformada ou
organizada)




são recebidos
podem ser armazenados
podem fluir de um processo a outro
podem ser transferidos para o ambiente externo
5) Diagrama de Fluxo de
Dados – Modelo de Função
______
5) Diagrama de Fluxo de
Dados (DFD) - Exemplo
Agente
de
Viagem
Horário, dia,
destino
Dados
do vôo
Informação
sem vôos
Preparação
de
Bilhete
Bilhete
Sistema
de
Reserva
Custo
Sistema
de
Cobrança
Diretórios de vôo
Dados contábeis
Arquivo de
Contabilidade
Conta
Cliente
5) Diagrama de Fluxo de
Dados (DFD) – Como construir
5) Diagrama de Fluxo de
Dados (DFD) – Como construir
5) Diagrama de Fluxo de
Dados (DFD) – Como construir




Particionar as funções em sub-funções:
uma bolha deve ser particionada por
vez
rótulos dos fluxos, bolhas e arquivos
devem ser significativos
a continuidade da informação deve ser
mantida
5) Diagrama de Fluxo de
Dados (DFD) – Como construir
A
B
F
x
A
f4
z
B
y
x
z
y
5) Diagrama de Fluxo de
Dados (DFD) – Quando parar




O DFD mostra as transformações de
todas as entrada em saídas
Os sub-processos não particionados
podem ser considerados elementares
Cada bolha está conectada
corretamente ao resto da rede
As conexões foram minimizadas
5) Diagrama de Fluxo de
Dados (DFD)
O DFD não mostra:
 descrição dos fluxos
 nem mecanismos de sincoronização
 comportamento
5) Diagrama de Fluxo de
Dados – Extensão Tempo Real
Fluxo de dados que não é contínuo
temp - max  temp - medida.
Transforma controle ou eventos.
Representa eventos.
Armazena itens de controle ou eventos.
5) Diagrama de Fluxo de
Dados – Extensão Tempo Real
Monitora
ph
ph no nível desejado
Processo
de
Controle
Ativa/Desativa
Muda
ph
ph
ativa
Controle da Válvula
de entrada
Ativa/Desativa
Mantém
ph
constante
Inicia
Pára
6) Modelo Entidade
Relacionamento (MER)




Dados descrevem coisas do mundo real.
Itens de dados relacionados devem ser
agrupados
Ex: nome, endereço, RG são informações
do sistema relacionados a uma entidade
do mundo real que é o cliente.
Ainda podemos ter relacionamentos entre
entidades
6) Modelo Entidade
Relacionamento (MER)
DER – Diagrama Entidade Relacionamento
6) Modelo Entidade
Relacionamento (MER)
DER – Diagrama Entidade Relacionamento
Exemplo
6) Modelo Entidade
Relacionamento (MER)




Existem muitas ferramentas
Fácil de entender
Não diz como se forma o atributo CIC
Não fica claro
7) Máquina de Estados Finitos
(MEF)


Os modelos de comportamento do
sistema devem mostrar estados eventos
que alteram esses estados
Eventos são condições e ações para se
mudar de estado.
7) Máquina de Estados Finitos
(MEF)
Uma MEF é dada por: (S, s0, I, ),
S – conjunto finito e não vazio de
estados
S0S – estado inicial
I – conjunto finito de entradas (A (ações)
e C (condições)) que podem ser nulas
:SxI  S - função de transição de
estados
7) Máquina de Estados Finitos
Diagrama de Estados (DTE)
7) Máquina de Estados Finitos
Diagrama de Estados (DTE)
7) Máquina de Estados Finitos
Diagrama de Estados (UML)
8) Dicionário de Dados (DD)



Repositório de descrições de tudo que é
utilizado em um modelo
Vantagens: organização, resolução de
ambigüidades e inconsistências,
documentação, facilidade para
relatórios, para alteração, etc
Integração com outros modelos –
ferramenta automatizada
8) Dicionário de Dados (DD)
Elemento Fluxo de Dados





nome
sinônimo
origem: referência do processo
destino: referência do processo
descrição


informal
formal
8) Dicionário de Dados (DD)
Elemento Fluxo de Dados
Uma descrição mais formal representa o
fluxo com a seguinte notação:
= é composto de
+ seqüência (e)
( ) opcional(pode ou não estarpresente)
{ } iteração – { }n n repetições
[ | ] ou exclusivo
* comentários
8) Dicionário de Dados (DD)
Elemento Fluxo de Dados
Ex1)
n
nome = sobrenome + {int} 0
+
primeiro
sobrenome = string[30]
int = string[60], primeiro = string[30]
Ex2)
dados_pessoais = nome +endereço +
estado civil +(dependentes)
8) Dicionário de Dados (DD)
Elemento Fluxo de Dados
Ex3)
exemplares = {exemplar}
exemplar = n_item+estado+nome_titulo
n_item = cod_biblioteca+n_exemplar
itens elementares de dados:
cod_biblioteca = string[2]
n_exemplar = inteiro
nome_titulo = string[60]
8) Dicionário de Dados (DD)
Elemento Depósito de Dados




referência
descrição
fluxos de entrada e saída
conteúdo
8) Dicionário de Dados (DD)
Elemento Processo (Bolhas)




referência
descrição
fluxos de entrada e saída
resumo lógico
8) Dicionário de Dados (DD)
Elemento Entidade Externa



nome
descrição
outras informações importantes
9) O Modelo de Objetos –
Principais Conceitos
Objeto
 Abstração ou conceito do mundo real
 Encapsulamento de atributos e serviços
Na análise – identificamos objetos no
domínio do problema
No projeto – pensamos em objetos para a
solução
9) O Modelo de Objetos –
Principais Conceitos
Classe
 Uma coleção ou agrupamento de um ou
mais objetos que podem ser descritos
com os mesmos objetos e serviços.
Ex: os objetos mesa e cadeira, podem ser
agrupados na classe mobília
9) O Modelo de Objetos –
Principais Conceitos
Atributo
 Característica, qualidade de um objeto
ou classe.
 Seus valores servem para diferenciar
objetos (Instâncias)
9) O Modelo de Objetos –
Principais Conceitos
Ocultamento da Informação Encapsulamento


Cada componente do programa deve
conter uma única decisão de projeto.
A interface definida de forma a revelar
o mínimo possível sobre o seu
funcionamento interno.
9) O Modelo de Objetos –
Principais Conceitos
Ocultamento da Informação Encapsulamento
 Reduz efeitos colaterais, facilita reuso,
manutenção e testes, entendimento, etc.
 Acessam-se dados de um objeto apenas
com métodos do próprio objeto que
funcionam como interface para outros
objetos.
9) O Modelo de Objetos –
Principais Conceitos
Associações entre classes e objetos


relacionamentos entre as classes que
em geral, representam a utilização de
serviços e/ou a organização entre as
mesmas.
devem refletir o domínio do problema
9) O Modelo de Objetos –
Principais Conceitos
Hierarquia Generalização/Especialização

mostra generalizações de entidades do
mundo real com características comuns e
extensões destas características em casos
especializados

super-classe – mais genérica
sub-classe – mais específica
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Principais Conceitos




Pode-se ter uma hierarquia ou um
entrelaçamento
Pode-se herança múltipla
Atributos e serviços comuns devem
ser colocados no nível superior
Deve satisfazer 100% a regra is-a
9) O Modelo de Objetos –
Principais Conceitos
_________
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Principais Conceitos
Agregação/Decomposição
 representa um composto e suas partes
 um inteiro pode ser decomposto em
diferente partes, ou várias partes
podem ser agregadas em um composto
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Principais Conceitos
Agregação pode ser:


Composição: a parte pertence apenas a
um único composto
Compartilhamento: a parte pode
pertencer a mais de um composto
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Principais Conceitos
Métodos ou Serviços
Processamento realizado por um objeto
que indica o seu comportamento, em
função do recebimento de uma mensagem
Mensagens
Ativação de um método. Um objeto se
utiliza de um serviço ou se comunica com
outro objeto enviando uma mensagem
9) O Modelo de Objetos –
Principais Conceitos
Ligação Dinâmica (late binding)
Mecanismo pelo qual se decide o
destino de uma mensagem em tempo
de execução
Ex: int (*f)();
i =f();

a função só definida
durante a execução
9) O Modelo de Objetos –
Principais Conceitos
Sobrecarga de operadores
(Overloading)
Operações de mesmo nome, mas
implementadas de maneira diferente
Ex: operações de adição, subtração
implementadas diferentemente para real
e inteiro
9) O Modelo de Objetos –
Principais Conceitos
Polimorfismo
Possibilidade de uma função poder
manipular valores com tipos (formas)
diversas
Ex: function comp(L:lista):integer

qualquer tipo de lista (genérico)
mesma implementação
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Principais Conceitos
Construtor/Destrutor
Função para criação/remoção de
instâncias de objetos/classes
Overriding (ou Sobreposição)
Mecanismo para redefinir ou tornar um
atributo não aplicável
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Principais Conceitos
9) O Modelo de Objetos –
Diagrama de Classes
9) O Modelo de Objetos –
Diagrama de Classes Como
Construir


Na fase de análise constrói-se
primeiramente um diagrama de classes
sem se preocupar em definir os
métodos, ao qual chamaremos de
Modelo Conceitual
Na fase de projeto os métodos são
adicionados e o Modelo Conceitual
refinado gerando o Diagrama de
Classes
9) Modelo de Objetos
Modelo Conceitual


Representação de conceitos no domínio
do problema
Deve mostrar: conceitos, associações
entre conceitos e atributos de conceitos
(na fase de análise, não se preocupa
ainda em representar métodos os
serviços)
9) Modelo de Objetos
Modelo Conceitual - Exemplo
9) Modelo de Objetos
Modelo Conceitual - Conceitos


É uma idéia, coisa ou objeto do mundo real.
Um bom modelo conceitual deve superestimar
o número de conceitos.
Para identificar conceitos:
a) Buscar por nomes em descrições textuais:
A descrição e o preço de cada item são
apresentados.
Cuidado: Imprecisão da linguagem natural

9) Modelo de Objetos
Modelo Conceitual - Conceitos
b) Relatórios, recibos, etc não devem aparecer
no modelo conceitual a menos que sejam
derivados de outras fontes.
c) Lista de Categorias de Conceitos
 objetos físicos: avião
 especificações, descrição de coisas:
especificação do produto, descrição do produto
 lugares: loja, aeroporto
 transações: reserva, pagamento
 função de pessoas: caixa, piloto
9) Modelo de Objetos
Modelo Conceitual - Conceitos







recipiente de coisas: estoque, avião
coisas em recipientes: itens, passageiros
outros sistemas: autorização de cartao de
crédito, controle de tráfico aéreo
conceitos abstratos: fome
organizações: cia aéreas, departamento de
vendas
eventos: voo, acidentes, venda, roubo
processos (podem ser): vendendo um
produto, reservando um assento
9) Modelo de Objetos
Modelo Conceitual - Conceitos





regras e políticas: retorno de mercadoria,
cancelamento
catálogo: produtos de catálogo, partes
de catálogo
contratos legais, de finanças: contrato de
trabalho
serviços: linha de crédito
manuais, livros: manual do empregado,
manual de reparo
9) Modelo de Objetos
Modelo Conceitual - Conceitos
d) Se você não descreve X com um número ou texto
no mundo real, X provavelmente será um conceito
9) Modelo de Objetos
Modelo Conceitual - Conceitos
e) Um conceito pode não estar incorreto, pode
apenas não ser útil
9) Modelo de Objetos
Modelo Conceitual - Conceitos
f) Conceitos do tipo especificação/descrição de
coisas: adicioná-los para reduzir redundância
e informação duplicada ou quando
informação é perdida se a coisa descrita for
removida
9) Modelo de Objetos
Modelo Conceitual - Conceitos
9) Modelo de Objetos
Modelo Conceitual - Conceitos
9) Modelo de Objetos
Modelo Conceitual -Atributos

O atributo é um valor lógico para o
objeto
________________
9) Modelo de Objetos
Modelo Conceitual -Atributos
Critérios para escolha de atributos
a) aqueles que sugerem ou implicam
necessidade de lembrança.
b) devem ser simples ou valores puros
(primitivos)
c) não represente um atributo como
chave estrageira
9) Modelo de Objetos
Modelo Conceitual -Atributos
9) Modelo de Objetos
Modelo Conceitual -Atributos
9) Modelo de Objetos
Modelo Conceitual -Atributos
9) Modelo de Objetos
Modelo Conceitual -Atributos
d) representar atributos primitivos como
não primitivos se:




são compostos: nome de pessoa, número
de telefone
sobre eles ocorrerem operações de
validação: CPF
eles têm outros atributos: preços
promocionais com data de início e término
representam quantidade com uma
unidade: pagamento e moeda corrente
9) Modelo de Objetos
Modelo Conceitual -Atributos
9) Modelo de Objetos
Modelo Conceitual,Associações
Critério para escolha das associações
a) o conhecimento de um relacionamento
precisa ser preservado (regra necessidade de
saber)
b) são importantes para compreender conceitos
importantes do domínio
c) é melhor identificar conceitos que
associações. Muitas delas podem tornar o
modelo conceitual confuso. Evite associações
redundantes e deriváveis

9) Modelo de Objetos
Modelo Conceitual,Associações
9) Modelo de Objetos
Modelo Conceitual,Associações
d) através de uma lista de associações
 A é parte física de B: asa - avião
 A é parte lógica de B: itens de venda venda
 A está fisicamente contida em B:
passageiro - avião
 A está logicamente contida em B:
descrição de item - cátalogo
9) Modelo de Objetos
Modelo Conceitual,Associações






A é descrição de B: descrição de voo - voo
A é uma linha de transação ou relatório de B:
trabalho de manutenção - relatório de
manutenção
A é conhecido, registrado, relatado em B:
venda - posto comercial
A é um membro de B: piloto - cia aérea
A é uma sub-unidade operacional de B :
departamento - loja
A usa ou gerencia B: piloto - avião
9) Modelo de Objetos
Modelo Conceitual,Associações





A se comunica com B: cliente - caixa
A está relacionado a uma transação de
B: passageiro - ticket
A é uma transação relacionada a uma
outra transação B: pagamento - venda
A está proximo a B: cidade - cidade
A é posse de B: avião - cia aérea
9) Modelo de Objetos
Modelo Conceitual,Associações
Multiplicidade da Associação:
Define quantas instâncias de um tipo A
podem ser associadas a uma instância
de um tipo B
9) Modelo de Objetos
Modelo Conceitual,Associações
9) Modelo de Objetos
Modelo Conceitual,Associações
9) Modelo de Objetos
Modelo Conceitual,Associações
9) Modelo de Objetos
Modelo Conceitual,Associações
9) Modelo de Objetos
Modelo Conceitual
Como fazer:
 Listar conceitos candidatos - lista de
conceitos e identificação de nomes nas frases
que descreve os requisitos
 Desenhar o modelo conceitual
 Adicionar as associações necessárias para
relacionamentos que são necessários
preservar
 Adicionar os atributos necessários para
preencher informações sobre os requisitos
9) Modelo de Objetos
Modelo Conceitual
Quando particionar em Sub-Classes
 a sub-classe tem atributos adicionais de
interesse
 a sub-classe tem associações adicionais de
interesse
 a sub-classe será manipulada ou usada de
maneira diferente da super-classe ou das
outras sub-classes
 a sub-classe se comporta diferente da superclasse ou das outras sub-classes
9) Modelo de Objetos
Modelo Conceitual
Quando criar uma Super-Classe
 as potenciais sub-classes representam
variações de um conceito similar
 as sub-classes satisfazem 100% a regra
``is-a''
 todas as sub-classes possuem um atributo
comum que poderá ser expresso na superclasse
 todas as sub-classes possuem uma
associação comum que poderá ser
relacionada à super-classe
9) Modelo de Objetos
Modelo Conceitual
10) Modelo de Casos de Uso
É composto de Casos de Uso e
Diagrama de Casos de Uso
Caso de Uso: é uma narrativa que
descreve a sequência de enventos de
um ator (agente externo) usando o
sistema para completar um processo.
São estórias de usos de um sistema.
10) Modelo de Casos de Uso
Caso de Uso : Comprar Itens
Atores: Cliente, Caixa
Tipo: principal
Descrição: Um Cliente chega com itens
para compra. O Caixa registra os itens
de compra e recebe o pagamento. Ao
final o Cliente vai embora com os itens
10) Modelo de Casos de Uso
Casos de Uso podem ser


Alto Nível: descrição breve
Estendido: descrição detalhada passo a
passo dos eventos
10) Modelo de Casos de Uso
Casos de Uso podem ser



Principal: comum e bastante
importante. Ex. comprar itens
Secundário: ocorre mais raramente. Ex:
cadastrar um produto
Opcional: pode ou não acontecer. Ex:
pagamento com cartão
10) Modelo de Casos de Uso
Casos de Uso podem ser


Essencial: livre de detalhes de
tecnologia e implementação, decisões
de projeto não estão presentes.
Real: descrições em termos do projeto.
10) Modelo de Casos de Uso
Casos de Uso Estendido
Caso de Uso : nome do caso de uso
Atores: lista de atores que iniciam o caso de uso
agentes externos
Propósito: objetivo geral
Descrição:resumo
Tipo: 1. principal, secundário ou opcional
2. real ou essencial
Referências: funções do sistema relacionadas
Sequência de Eventos
Ações de Atores
Respostas do Sistema
Sequências Não Típicas de Eventos
10) Modelo de Casos de Uso
Casos de Uso Estendido –Ex.
Caso de Uso : Comprar Itens à Vista
Atores: Cliente, Caixa
Propósito: Registrar uma Venda
Descrição: Um Cliente chega com itens
para compra. O Caixa registra os itens
de compra e recebe o pagamento. Ao
final o Cliente vai embora com os itens
Tipo: principal e essencial
Referências: Funções: R1.1, R1.2, R2.1
10) Modelo de Casos de Uso
Casos de Uso Estendido –Ex.
Sequência de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso
comeca quando um
cliente chega ao caixa
com itens de compra
2. O caixa registra cada
item
3. Determina o preco
do item e adiciona o
item a venda.
.......
........
10) Modelo de Casos de Uso
Casos de Uso Estendido –Ex.
Sequência não típicas
Ação do Ator
.............
Resposta do Sistema
3. O produto não está
cadastrado no
sistema
........
10) Modelo de Casos de Uso
Casos de Uso Estendido –Ex.
Sequências alternativas
Ação do Ator
4.1 O cliente realiza
o pagamento a vista
Resposta do Sistema
.............
..............
4.2 O cliente realiza
o pagamento com cheque
........
.............
........
10) Modelo de Casos de Uso
Casos de Uso Real –Ex.
10) Modelo de Casos de Uso
Casos de Uso Real –Ex.
10) Modelo de Casos de Uso
Diagrama de Casos de Uso
10) Modelo de Casos de Uso
Identificando um Caso de Uso

Primeiro Método: baseado em atores



identificar atores
para cada ator, identificar os processos que ele
inicia ou participa
Segundo Método: baseado em eventos


identificar eventos externos aos quais o
sistema deve responder
relacionar os eventos a atores e casos de usos
10) Modelo de Casos de Uso
Identificando um Caso de Uso
 Um processo descreve do início ao fim,
uma sequência de eventos, ações ou
transações necessárias para produzir ou
completar alguma coisa para a organização
ou ator.
 Um caso de uso é uma descrição de um
processo, e inclui muitos passos. Não
utilizá-lo para descrever um passo ou
atividade de um processo. Ex. Imprimir
recibo é um passo de comprar itens.
11) Diagrama de Sequência –
Traços de Eventos


Representa cenários - como o sistema
irá trabalhar quando ele estiver em
operação.
Composto de


traços verticais – elementos que disparam,
recebem ou respondem eventos
horizontais – eventos e informações que são
trocadas pelos elementos (mensagens)
11) Diagrama de Sequência de
Eventos do Sistema



Na fase de análise usaremos apenas
diagramas de sequência de eventos do
sistema
Representa a sequência de eventos dos
casos de uso estendidos.
É um dado cenário (instância ou
caminho percorrido no mundo real) de
um caso de uso. Mostra os eventos que
os atores externos geram, a ordem que
ocorrem e eventos entre sistemas
11) Diagrama de Sequência de
Eventos do Sistema
Eventos do Sistema: é um evento de
entrada externa gerado por um ator
para o sistema. Ele inicia uma
operação como uma resposta
Operação do Sistema: operação
executada como resposta a um
evento do sistema
11) Diagrama de Sequência de
Eventos do Sistema
11) Diagrama de Sequência de
Eventos do Sistema
________________
11) Diagrama de Sequência de
Eventos do Sistema
11) Diagrama de Sequência de
Eventos do Sistema
11) Diagrama de Sequência de
Eventos do Sistema
Como fazer um diagrama de sequências
do sistema
 fazer um diagrama para uma sequência
típica de eventos para um caso de uso:
 desenhe uma linha representando o
sistema como uma caixa preta
 identifique cada ator que diretamente
opera o sistema. Desenhe uma linha a
partir de cada ator.
11) Diagrama de Sequência de
Eventos do Sistema


do texto de eventos típicos (caso de uso
estendido) identifique eventos que são
gerados por cada um dos atores.
Ilustre-os no diagrama.
opcionalmente, inclua o texto do caso
de uso ao lado do diagrama.
12) Modelo de Contratos


Contratos descrevem o efeito das
operações do sistema e ajudam a
definir o seu comportamento.
É declarativo, porque o interesse está
no que acontecerá e não como isso será
realizado. São expressos em termos de
pré e pós condições
12) Modelo de Contratos
Nome : nome da operação e parâmetros
Responsabilidades: responsabiliades a
serem cumpridas
Tipo: nome do tipo (conceito, classe de
software, interface)
Referências: funções dos sistema, casos de
usos etc
Notas: notas de projeto, algoritmos, detalhes
de implementação
Excessões : casos excepcionais
12) Modelo de Contratos
Saída: mensagens e registros enviados
para fora do sistema (outros sistemas)
Pré-Condições: suposições sobre o
estado sistema antes da execução da
operação
Pós-Condições: o estado do sistema
após o término da operação.
12) Modelo de Contratos - Ex
Contrato - Um Exemplo
Nome :
entrar item(upc:number;quantidade:inteiro)
Responsabilidades: registrar um item de venda
e adicioná-lo à venda; mostrar preço e
descrição do item
Tipo: sistema
Referências: funções: R1.1, R1.3, R1.9 casos de
usos: Comprar Itens
12) Modelo de Contratos - Ex
Notas: acesso a uma base de dados
Excessões : se UPC não for válida mostrar
msg de erro Saída
Pré-Condições: deve-se conhecer valor de
UPC
12) Modelo de Contratos - Ex
Pós-Condições:
1. se a compra é nova, uma nova Venda
(instância) foi criada
2. se a compra é nova, a nova Venda foi
associada com o Posto comercial (uma
associação foi estabelecida)
3. um Item da linha de Venda foi criado
(instância criada)
12) Modelo de Contratos - Ex
Pós-Condições:
4. Item da linha de Venda foi associado com
Compra (asossiação estabelecida)
5. O atributo Item da linha de
Venda.quantidade recebe um valor
(modificação de um atributo)
6. Um Item da linha de Venda foi associado
com uma Especificação de Produto,
baseado no valor da UPC (asossiação
estabelecida)
12) Modelo de Contratos –
Como fazer




identificar as operações do sistema do
diagrama de sequências do sistema
para cada operação encontrada, construir
um contrato
comece escrevendo a seção de
responsabilidades, o propósito da
operação
complete a seção de pós-condições,
descrevendo mudanças de estado em
objetos no modelo conceitual
12) Modelo de Contratos –
Como fazer




descreva pós-condições nas seguintes
categorias: criação e remoção de
instâncias, modificação de atributos,
associações estabelecidas e rompidas.
pós-condições são declarações do estado
do sistema; não são ações a tomar, devem
estar no passado.
descreva pré-condições 2#2 pré-condições
são fatos importantes que precisam ser
testados.
além de criar instâncias é importante
estabelecer associações.
Relacionamento entre os
Modelos
13) O Modelo Formal


Utilizam notações matemáticas e podem
ser empregados em qualquer estágio da
especificação de um sistema
Utilizam




operadores relacionais: >, <,= ...
operadores lógicos: ^, ~ ...
quantificadores: ,  (para todo, existe)
teoria dos conjuntos: ,,,, ...
13) O Modelo Formal
Especifica-se uma função em termos de:
 Pré-condições: para a função ser
executada
 Pós-condições: para a função terminar
Predicados sobre entradas e saídas das
funções, geralmente parâmetros, dados
13) O Modelo Formal
Passos
 Estabelecer restrições para os valores
de entrada
 Estabelecer restrições para os valores
de saída
 Combinar esses predicados em pré e
pós-condições
13) O Modelo Formal
Ex1) especificar que o código digitado é um
código cadastrado na base da biblioteca
 b  biblioteca/ (b.código=código_biblioteca)
Ex2) especificar que todo exemplar identificado
por n_item (número do item) pertence a
alguma biblioteca
 e  exemplar/ pertence(b.código, e.n_item)
13) O Modelo Formal
Ex3) especificar função
localiza_exemplar(exemplar_disponível:string):string
Pré-condição
 b  biblioteca/
pertence(b.código, exemplar_disponível)
Pós-condição
 b  biblioteca/
(b.nome=localiza_exemplar(exemplar_diponível)
^ pertence(b.código, exemplar_disponível)
13) O Modelo Formal
Ex4) especificar que um exemplar está
disponível em apenas uma biblioteca e
reservado apenas para disciplinas de sua
área
 e  exemplar
( b1,b2  biblioteca (disponível (b1,e) ^
disponível (b2,e)) b1=b2))
^
( d  disciplina (reservado(d,e))  area (d,e))
13) O Modelo Formal –
Linguagem Z


Baseada em teoria dos conjuntos e lógica de
primeira ordem
Constrói-se um esquema que agrupa declarações
de variáveis e predicados que restrigem os
valores dessas variáveis.
Ex: ______ x ________
declarações
________________
predicados
Inível: F N
decl. var.
______________
Inível
predicado