REQUISITOS: LEVANTAMENTO E MODELAGEM · de requisitos, o modelo de caso de uso considera o sistema...
38
COLÉGIO ESTADUAL ULYSSES GUIMARÃES CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA ERINALDO SANCHES NASCIMENTO REQUISITOS: LEVANTAMENTO E MODELAGEM FOZ DO IGUAÇU 2013
-
Upload
phungtuong -
Category
Documents
-
view
222 -
download
0
Transcript of REQUISITOS: LEVANTAMENTO E MODELAGEM · de requisitos, o modelo de caso de uso considera o sistema...
COLÉGIO ESTADUAL ULYSSES GUIMARÃES
CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA
ERINALDO SANCHES NASCIMENTO
REQUISITOS: LEVANTAMENTO E MODELAGEM
FOZ DO IGUAÇU
2013
ii
LISTA DE FIGURAS
FIGURA 1 – DIAGRAMA DE CASO DE USO. ............................................................. 6 FIGURA 2 – DIAGRAMA DE CASO DE USO PARA CRIAR UM NOVO WIKI
PESSOAL. .......................................................................................................... 11 FIGURA 3 – DIAGRAMA DE CASO DE USO REPRESENTANDO UM
RELACIONAMENTO EXTEND. .......................................................................... 14 FIGURA 4 – DIAGRAMA DE CASO DE USO REPRESENTANDO UM
RELACIONAMENTO DE GENERALIZAÇÃO. .................................................... 15 FIGURA 5 – INTERFACE DO USUÁRIO DO CAIXA ELETRÔNICO. ........................ 30 FIGURA 6 – MENU PRINCIPAL DA ATM. ................................................................. 31 FIGURA 7 – MENU DE SAQUE DA ATM. .................................................................. 32
iii
LISTA DE QUADROS
QUADRO 1 – DESCRIÇÃO DE UM CASO DE USO .................................................... 8 QUADRO 2 – DESCRIÇÃO DO CASO DE USO PARA CRIAR UM NOVO WIKI
PESSOAL ........................................................................................................... 11 QUADRO 3 – DESCRIÇÃO DO CASO DE USO CHECAR IDENTIFICAÇÃO ........... 12 QUADRO 4 – DESCRIÇÃO DO CASO DE USO APRESENTANDO UM
RELACIONAMENTO EXTEND ........................................................................... 13
iv
SUMÁRIO
3 REQUISITOS ........................................................................................................... 1 3.1 ANÁLISE DE REQUISITOS ................................................................................... 1 3.1.1 Requisito Funcional ............................................................................................ 2 3.1.2 Requisito Não Funcional .................................................................................... 2 3.1.3 Requisito de Domínio ......................................................................................... 2 3.1.4 Não-Requisito ..................................................................................................... 3 3.1.5 Analisar os Requisitos ........................................................................................ 3 3.2 MODELAGEM DE REQUISITOS ........................................................................... 3 3.2.1 Casos de Uso ..................................................................................................... 4 3.2.2 Diretrizes para Descrever Casos de Uso ........................................................... 5 3.2.3 Diagramas de Casos de Uso .............................................................................. 6 3.2.3.1 Ator .................................................................................................................. 6 3.2.3.2 Caso de Uso .................................................................................................... 7 3.2.3.3 Linha de Comunicação .................................................................................... 7 3.2.3.4 Fronteira do Sistema ....................................................................................... 7 3.2.3.5 Descrição do Caso de Uso .............................................................................. 8 3.2.4 Relacionamentos de Caso de Uso ..................................................................... 8 3.2.4.1 O Relacionamento de Inclusão ....................................................................... 9 3.2.4.2 O Relacionamento de Extensão ...................................................................... 9 3.2.4.3 Representação de Relacionamentos em Casos de Uso ............................... 10 3.2.4.4 Relacionamento de Generalização ............................................................... 14 3.3 DESCRIÇÕES DE CASOS DE USO E DIAGRAMAS DE CASOS DE USO ......... 14 3.3.1 Identificar os Principais Casos de Uso ............................................................. 15 3.3.2 Expandir os Principais Casos de Uso .............................................................. 16 3.3.3 Confirmar os Principais Casos de Uso ............................................................. 17 3.3.4 Criar o Diagrama de Caso de Uso ................................................................... 17 3.3.5 Especificar Requisitos Não Funcionais ............................................................ 18 3.4 EXERCÍCIOS ...................................................................................................... 18 3.5 PROJETO ............................................................................................................ 29 3.5.1 Examinar o Documento de Requisitos ............................................................. 29 3.5.2 Diagramas de Casos de Uso ............................................................................ 33 3.6 BIBLIOGRAFIA .................................................................................................... 34
1
3 REQUISITOS
Antes de iniciar a codificação é preciso saber o que será construído. Um
bom conjunto de requisitos diz exatamente o que o programa deve fazer. Os
requisitos são uma lista de coisas que tem que ser implementadas, a fim de criar o
programa.
Um desenvolvedor produtivo, que comete poucos erros e chega a um projeto
bom e limpo, precisa detalhar os requisitos, o quanto melhor. O levantamento dos
requisitos obriga a pensar sobre os detalhes do programa e permite ouvir os
usuários para se tenha uma ideia melhor do que eles realmente querem.
A modelagem de requisitos consiste em análise de requisitos e
especificação de requisitos.
3.1 ANÁLISE DE REQUISITOS
Seja o desenvolvimento de um novo sistema ou a substituição de um
sistema existente, é muito importante especificar os requisitos do novo sistema de
forma precisa e sem ambiguidades. Há frequentemente muitos usuários do sistema,
e em uma grande empresa, estes podem ser engenheiros, equipes de marketing e
vendas, gerentes, equipe de TI, pessoal administrativo, etc. As necessidades de
cada grupo de usuários (ou partes interessadas) deve ser entendido e especificada.
Os requisitos de software descrevem a funcionalidade que o sistema deve
fornecer para os usuários. A análise de requisitos envolve:
entrevistar usuários
analisar o sistema existente (s), manual ou automatizado.
Inclui saber dos usuários o seguinte:
o papel do usuário no sistema atual (seja manual ou automatizado);
como ele utiliza o sistema atual;
as vantagens e limitações do sistema atual;
as características que o novo sistema deve fornecer.
2
Após a análise, os requisitos têm de ser especificados através de um
documento que precisa ser acordado entre os analistas e os usuários. É o ponto de
partida para a concepção e desenvolvimento futuro e por isso também deve ser
entendido pelos desenvolvedores.
3.1.1 Requisito Funcional
Descreve uma funcionalidade que o sistema deve ser capaz de fazer, de
modo a cumprir o propósito do sistema. Na definição de um requisito funcional, é
necessário descrever as informações que precisam ser inseridas no sistema a partir
do ambiente externo (como os usuários externos, sistemas externos ou dispositivos
externos), o que o sistema precisa enviar para o ambiente externo, e que
informações o sistema lê, armazena ou atualiza.
3.1.2 Requisito Não Funcional
Um requisito não funcional, por vezes refere-se a um atributo de qualidade
que o sistema tem de cumprir. São exemplos de requisitos não funcionais:
Requisito de desempenho especificando um tempo de resposta do sistema de 2
segundos
Requisito de disponibilidade especificando que o sistema deve estar operacional
para 99% do tempo
Requisito de segurança, como proteção contra a invasão de sistema.
3.1.3 Requisito de Domínio
São impostos aos desenvolvedores pelo domínio de aplicação do programa.
Os requisitos de domínio são, geralmente, considerados "camada intermediária" de
software, porque eles são o coração da aplicação, abaixo da interface do usuário e
3
acima do sistema operacional, redes, ou banco de dados. Vários requisitos de
domínio serão implementados como classes separadas e bibliotecas com suas
próprias APIs.
3.1.4 Não-Requisito
São as coisas que não serão feitas. Uma das partes mais importantes da
especificação funcional: dizer o que não se fará. O desenvolvedor precisa dizer a
todas as partes interessadas em um projeto o que o programa vai fazer e, também,
o que não vai fazer.
3.1.5 Analisar os Requisitos
A análise de requisitos tem três partes básicas:
Categorizar os requisitos e organizá-los em áreas afins.
Priorizá-los com base em informações do cliente.
Analisar cada requisito em relação a todos os outros para se certificar que eles
se encaixam em um todo coerente. O desenvolvedor deve perguntar a si mesmo
uma série de perguntas:
1. Cada requisito está consistente com o objetivo geral do projeto?
2. Este requisito é realmente necessário?
3. Este requisito é testável?
4. Esta exigência é factível no ambiente técnico de trabalho?
5. Este requisito não é ambíguo?
3.2 MODELAGEM DE REQUISITOS
Na modelagem de casos de uso, os requisitos funcionais são descritos em
termos de atores, que são os usuários do sistema, e casos de uso. Um caso de uso
4
define uma sequência de interações entre um ou mais atores e o sistema. Na fase
de requisitos, o modelo de caso de uso considera o sistema como uma caixa preta e
descreve as interações entre o(s) ator(es) e o sistema de uma forma de narrativa
que consiste em entradas do utilizador e respostas do sistema.
Um ator fornece entradas para o sistema e o sistema fornece respostas ao
ator. Um caso de uso típico é composto de diversas interações entre o ator e o
sistema. Casos de uso mais complexos podem envolver mais que um ator.
3.2.1 Casos de Uso
Os casos de uso são muitas vezes a notação inicial no uso da modelagem
UML em um desenvolvimento. Os casos de uso identificam como um sistema será
usado e que agentes externos (os usuários humanos ou outros agentes externos)
podem interagir com o sistema. A notação é bastante simples, usando ovais para
representar os casos de uso e figuras para representar os agentes (conhecidos
como atores em UML).
Um caso de uso é uma situação em que o sistema é usado para preencher
um ou mais dos requisitos do usuário, um caso de uso captura um pedaço de
funcionalidade que o sistema proporciona. Os casos de uso são o coração do
modelo, uma vez que eles afetam e orientam todos os outros elementos dentro da
modelagem do sistema.
Ao criar casos de uso, a equipe do projeto deve trabalhar em estreita
colaboração com os usuários para reunir os requisitos necessários para os casos de
uso. Cada caso de uso está associado com um e apenas um papel que os usuários
têm no sistema. Por exemplo, uma recepcionista em um consultório médico, pode
desempenhar papéis múltiplos: agendar consultas, atender ao telefone, arquivar
registros médicos, receber pacientes, e etc. Além disso, é possível que vários
usuários desempenhem o mesmo papel. Como tal, os casos de uso devem ser
associados aos papéis desempenhados pelos usuários e não com os próprios
usuários.
5
3.2.2 Diretrizes para Descrever Casos de Uso
A essência de um caso de uso é o fluxo de eventos. Escrever o fluxo de
eventos de uma forma útil para as fases posteriores do desenvolvimento.
1. Escrever cada conjunto na forma de sujeito-verbo-objeto direto (e, por vezes,
preposição-objeto indireto).
2. Deixar claro quem ou o que é o iniciador da ação e quem/o que é o receptor da
ação em cada etapa. Normalmente, o iniciador deve ser o sujeito da frase e o
receptor deve ser o objeto direto da sentença.
3. Escrever os passos a partir da perspectiva de um observador independente (o
iniciador e o receptor).
4. Escrever cada passo com o mesmo nível de abstração.
5. Verificar se o caso de uso tem um conjunto razoável de passos. Cada caso de
uso deve incluir quatro partes:
a. O ator primário inicia a execução do caso de uso através do envio de um
pedido (dados) para o sistema.
b. O sistema garante que o pedido (dados) seja válido.
c. O sistema processa o pedido (dados) e, possivelmente, muda o seu próprio
estado interno.
d. O sistema envia ao ator primário o resultado do processamento.
6. Se o caso de uso se tornar muito complexo e/ou muito grande, o mesmo deve
ser decomposto em um conjunto de casos de uso. Além disso, se o fluxo normal
de eventos tornar-se muito complexo deve ser usado subfluxos. No entanto,
deve-se tomar cuidado para evitar decomposição demasiada.
7. Repitir os passos 1 ao 5, isso torna o caso de uso mais legível para pessoas que
não são familiarizadas com programação.
6
3.2.3 Diagramas de Casos de Uso
Um diagrama de casos de uso ilustra de uma forma muito simples as
principais funções do sistema e os diferentes tipos de usuários que irão interagir com
ele.
A figura 1 represente um diagrama de casos de uso para a descrição do
requisito abaixo.
Requisito 1: O sistema de gerenciamento de conteúdo deve permitir que um
administrador crie uma nova conta de blog, fornecidos os dados pessoais do novo
blogueiro são verificados usando o banco de dados do autor credenciais.
Figura 1 – Diagrama de caso de uso.
3.2.3.1 Ator
Um ator não é um usuário específico, mas um papel que um usuário pode
desempenhar ao interagir com o sistema. Um ator também pode representar outro
sistema no qual o sistema atual interage.
É uma pessoa ou sistema que recebe algum benefício e é externo ao sistema.
É descrito como uma figura humana de bastão.
É rotulado com o seu papel.
Pode ser associado a outros atores usando uma associação de
especialização/superclasse, denotada por uma seta com uma ponta de seta oco.
É colocada fora do limite do sistema.
7
3.2.3.2 Caso de Uso
Um caso de uso, ou trabalho, pode ser tão simples como permitir que o
usuário faça login ou tão complexo como a execução de uma transação distribuída
em vários bancos de dados globais. Um caso de uso, pela perspectiva do usuário, é
uma utilização completa do sistema; há alguma interação com o sistema, bem como
alguma saída dessa interação.
Representa uma grande parte da funcionalidade do sistema.
Pode estender outro caso de uso.
Pode incluir um outro caso de uso.
É colocado dentro do limite do sistema.
É marcado com uma frase verbo-descritivo.
3.2.3.3 Linha de Comunicação
A linha de comunicação conecta um ator e um caso de uso para mostrar a
participação do ator no caso de uso.
3.2.3.4 Fronteira do Sistema
Há uma separação implícita entre os atores (externos ao sistema) e os
casos de uso (internos ao sistema), que marca fronteira do sistema.
Para mostrar limite do sistema em um diagrama de caso de uso, desenhe
uma caixa em torno de todos os casos de uso, mas mantenha os atores fora da
caixa. Nomeie a caixa conforme o sistema que está desenvolvendo.
1. Inclui o nome do sistema no interior ou na parte superior.
2. Representa o alcance do sistema.
8
3.2.3.5 Descrição do Caso de Uso
Um diagrama mostrando os casos de uso e os atores é um bom ponto de
partida, mas não fornece detalhes suficientes para os analistas de sistema
realmente entender como os objetivos do sistema serão cumpridos.
A melhor maneira é expressar-se na forma de uma descrição em texto –
cada caso de uso deve ser acompanhado por um.
O quadro 1 representa a descrição do caso de uso ilustrado pela figura 1.
Quadro 1 – Descrição de um caso de uso
Caso de uso Criar uma nova conta de blog
Requisito Requisito 1
Meta Um novo autor ou existente solicita uma nova conta de blog ao
Administrador.
Pré-condição O sistema é limitado a autores reconhecidos e por isso o autor
tem de ter a prova adequada de identidade.
Sucesso Uma nova conta de blog é criada para o autor.
Falha A aplicação para criar uma nova conta de blog é rejeitada.
Ator primário Administrador
Ator secundário Banco de dados de credenciais de autor.
Gatillho O Administrador solicita ao sistema criar uma nova conta de blog.
3.2.4 Relacionamentos de Caso de Uso
Um caso de uso descreve a forma como o sistema se comporta para atender
a uma exigência. Ao preencher as descrições dos casos de uso, nota-se que existe
alguma semelhança entre as etapas em diferentes casos de uso. Também alguns
casos de uso trabalham em vários modos diferentes ou casos especiais. Finalmente,
pode-se encontrar um caso de uso com múltiplos fluxos ao longo da execução, e
que seria bom mostrar esses importantes casos opcionais nos diagramas de casos
de uso.
9
Quando os casos de uso ficam muito complexos, as dependências entre os
casos de uso podem ser definidas usando relacionamentos include e extend. O
objetivo é maximizar a extensibilidade e a reutilização dos casos de uso. Casos de
uso de inclusão estão determinados a identificar sequências comuns de interações
em vários casos de uso, que podem ser extraídos e reutilizados.
Outro relacionamento de caso de uso fornecido pela UML é a generalização
do caso de uso. A generalização do caso de use é semelhante ao relacionamento de
extensão, porque também é usado para tratar variações.
3.2.4.1 O Relacionamento de Inclusão
Os casos de uso de inclusão sempre refletem funcionalidades comuns a
mais de um caso de uso. Quando esta funcionalidade comum é separada em um
caso de uso de inclusão, o caso de uso de inclusão pode ser reutilizado por vários
casos de uso base (executável). Casos de uso de inclusão podem muitas vezes ser
desenvolvidos apenas após uma iteração inicial, na qual vários casos de uso têm
sido desenvolvidos. Somente então poderão ser observadas as sequências de
interações repetidas que formam a base para os casos de uso de inclusão.
Em termos de programação, um caso de uso de inclusão é análogo a uma
rotina de biblioteca, e um caso de uso base é análogo a um programa que chama a
rotina de biblioteca.
Um caso de uso de inclusão pode não ter um ator específico. O ator é, de
fato, o ator do caso de uso base que inclui o caso de uso de inclusão. Como
diferentes casos de uso base usam o caso de uso de inclusão, é possível para o
caso de uso de inclusão ser usado por diferentes atores.
3.2.4.2 O Relacionamento de Extensão
Em determinadas situações, um caso de uso pode ser muito complexo, com
muitas ramificações alternativas. O relacionamento de extensão é usado para
10
modelar caminhos alternativos que um caso de uso pode tomar. Um caso de uso
pode se tornar muito complexo se tiver muitas alternativas, opcional, e sequências
excepcionais de interações. Uma solução é a cisão de uma sequência alternativa ou
opcional de interações em um caso de uso separado. O objetivo deste novo caso de
uso é estender o caso de uso antigo, se mantém a condição adequada. O caso de
uso que é estendido é referido como o caso de uso de base, e novo é referido como
caso de uso de extensão.
O relacionamento de extensão pode ser utilizado como se segue:
Para mostrar uma parte condicional do caso de uso base que é executado
somente sob determinadas circunstâncias ou
Para modelar caminhos complexos ou alternativas.
É importante que o caso de uso base não dependa do caso de uso de
extensão. O caso de uso de extensão, por outro lado, depende do caso de uso base
e executa somente se a condição no caso de uso base que faz com que ele execute
seja verdadeira. Um caso de uso base pode ser estendido por mais de um caso de
uso de extensão.
3.2.4.3 Representação de Relacionamentos em Casos de Uso
Considere a descrição do requisito abaixo.
Requisito 2: O sistema de gerenciamento de conteúdo deve permitir que um
administrador crie um novo Wiki pessoal, fornecido os detalhes pessoais do autor da
aplicação são verificados usando o banco de dados de Credenciais do Autor.
A figura 2 e o quadro 2 representam respectivamente o diagrama de casos
de uso e a descrição do caso de uso para o requisito 2.
11
Figura 2 – Diagrama de caso de uso para criar um novo wiki pessoal.
Quadro 2 – Descrição do caso de uso para criar um novo wiki pessoal
Caso de uso Criar um novo Wiki pessoal.
Requisito Requisito 2
Meta Um novo autor ou existente solicita um novo Wiki pessoal para o
Administrador.
Pré-condição O autor tem a prova adequada de identidade.
Sucesso Um novo Wiki pessoal é criado para o autor.
Falha A aplicação para um novo Wiki pessoal é rejeitada.
Ator primário Administrador.
Ator secundário Nenhum.
Gatillho O Administrador solicita ao sistema criar um novo Wiki pessoal.
Fluxo Principal Passos Ação
1 O Administrador solicita ao sistema criar um novo Wiki
pessoal.
2 O administrador entra com os dados do autor.
3 Os dados do autor são verificados usando o Banco de
Dados de Credenciais de Autor.
4 O novo Wiki pessoal é criado.
5 Um resumo com os detalhes do novo Wiki pessoal é
enviado por e-mail ao autor.
Extensões Passos Ação ramificada
3.1 O banco de dados de credenciais de autor não verifica
12
os dados do autor.
3.2 O novo Wiki pessoal do autor é rejeitado pela
aplicação.
O quadro 3 apresenta a descrição do caso de uso Checar identificação, um
relacionamento include que inclui a funcionalidade de um caso de uso dentro da
outro.
Quadro 3 – Descrição do caso de uso checar identificação
Caso de uso Checar identificação
Requisito Requisito 1, Requisito 2
Meta Os dados de um autor precisam ser checados e comprovados
como exato.
Pré-condição O autor ser checado tendo a prova adequada de identidade.
Sucesso Os dados são comprovados.
Falha Os dados não são comprovados.
Ator primário Banco de dados de credenciais de autores.
Ator secundário Nenhum.
Gatillho Credenciais de um autor são fornecidas ao sistema para
verificação.
Fluxo Principal Passos Ação
1 Os dados são fornecidos ao sistema.
2 O banco de dados de credenciais de autores verifica
os dados.
3 Os dados retornam como comprovados pelo banco de
dados de credenciais de autores.
Extensões Passos Ação ramificada
2.1 O banco de dados de credenciais de autores não
comprova os dados.
2.2 Os dados retornam como inválidos.
13
O caso de uso criar uma nova conta de blog pode querer registrar que um
novo autor solicitou uma conta e foi rejeitado, acrescentando essa informação para o
histórico do autor do aplicativo.
O quadro 4 apresenta a descrição do caso de uso referido, com um
relacionamento extend que inclui os passos desse comportamento opcional. A figura
3 represente a diagrama de caso de uso, nele tem uma seta desenhada a partir do
caso de uso de extensão para o caso de uso base.
Quadro 4 – Descrição do caso de uso apresentando um relacionamento extend
Caso de uso Criar uma nova conta de blog
Requisito Requisito 1
Meta Um novo autor ou existente solicita uma nova conta de blog ao
Administrador.
Pré-condição O autor tem de ter a identidade comprovada.
Sucesso Uma nova conta de blog é criada para o autor.
Falha A aplicação para criar uma nova conta de blog é rejeitada.
Ator primário Administrador
Ator secundário Nenhum
Gatillho O Administrador solicita ao sistema criar uma nova conta de blog.
Fluxo Principal Passo Ação
1 O Administrador solicita ao sistema criar uma nova
conta de blog.
2 O Administrador seleciona um tipo de conta.
3 O Administrador insere os dados do Autor.
4 Os dados do Autor são checados.
include::Checar Identidade
5 A nova conta é criada.
6 Um resumo com os dados da nova conta de blog são
enviados por email ao Autor.
Extensões Passo Ação ramificada
4.1 O Autor não tem permissão para criar um novo blog.
4.2 O aplicativo conta de blog é rejeitada.
4.3 A rejeição da aplicação é registrada como parte do
histórico do Autor.
14
Figura 3 – Diagrama de caso de uso representando um relacionamento extend.
3.2.4.4 Relacionamento de Generalização
Um relacionamento de generalização representa um caso de uso
especializado para um mais generalizado. Tem uma seta desenhada a partir do caso
de uso especializado para o caso de uso base.
A forma mais comum de se referir a generalização é usar o termo herança.
Caso de uso de herança é útil se quer mostrar que um caso de uso é um tipo
especial de outro caso de uso.
Considere a figura 4 que represente o diagrama de caso de uso onde dois
tipos de contas de blog, regular e editorial, podem ser criadas pelo sistema de
gestão.
3.3 DESCRIÇÕES DE CASOS DE USO E DIAGRAMAS DE CASOS DE USO
Os casos de uso descrevem a funcionalidade de um sistema e são um
modelo de diálogo entre os atores e o sistema. São usados para modelar o contexto
do sistema e os requisitos de execução do sistema. O principal objetivo é
documentar os requisitos funcionais do sistema, mas também são utilizados como
uma base para testar o sistema de evolução.
15
Figura 4 – Diagrama de caso de uso representando um relacionamento de generalização.
3.3.1 Identificar os Principais Casos de Uso
1. Reveja o diagrama de atividades.
Ajuda o analista obter uma visão completa do processo de negócio
subjacente que está sendo modelado.
2. Encontrar limites do assunto.
Ajuda o analista identificar o âmbito de aplicação do sistema. No entanto, à
medida do trabalho evolui através de ciclo de vida do desenvolvimento de software,
a fronteira do sistema muda.
3. Identificar os principais atores e seus objetivos.
Os principais atores envolvidos com o sistema virá de uma lista de
interessados (stackholders) e usuários. Para o sistema ser um sucesso os objetivos
representam a funcionalidade que o sistema deve fornecer ao ator. Identificar as
tarefas que cada ator deve realizar pode facilita.
4. Identificar e escrever os resumos dos casos de uso importantes.
Ajuda os analistas descreverem os casos de uso e reduz a chance de
sobreposição entre os casos de uso. É importante neste momento para entender e
16
definir siglas e jargões, de modo que a equipe do projeto e outros de fora do grupo
de usuários possam entender claramente os casos de uso.
5. Analisar cuidadosamente os casos de uso corrente. Rever, conforme necessário.
Pode ser necessário separar alguns casos de uso em vários ou fundir outros
em um único. Além disso, novos casos de uso podem ser identificados.
3.3.2 Expandir os Principais Casos de Uso
6. Escolher um dos principais casos de uso para expandir.
Usar o nível de importância do caso de uso pode ajudar a fazer isso.
7. Começar a preencher os detalhes do caso de uso escolhido.
Listar todos os stackeholders identificados e os seus interesses, o nível de
importância, uma breve descrição, a informação de disparo, e as relações em que o
caso de uso participa.
8. Escrever o fluxo normal de eventos do caso de uso.
Os passos devem ser listados na ordem em que são realizados, da primeira
para a última. O objetivo é descrever como o caso de uso escolhido opera.
9. Se o fluxo normal de eventos é muito complexo ou longo prazo, se decompõem
em sub-fluxos.
Cada etapa deve ser aproximadamente do mesmo tamanho das outras. Se
acabar com mais de sete passos ou etapas que variam muito em tamanho, deve-se
voltar e rever cada passo cuidadosamente e, possivelmente, reescrever as etapas.
Uma boa abordagem para produzir os passos de um caso de uso é ter a
visão dos usuários.
10. Listar os possíveis fluxos alternativos ou excepcionais.
Os fluxos alternativos ou excepcionais representam o comportamento
opcional ou excepcional. Eles ocorrerem raramente ou como resultado da falha de
um fluxo normal. Eles devem ser rotulados de modo que não haja dúvidas sobre a
qual fluxo normal de eventos está relacionado.
11. Para cada fluxo alternativo ou excepcional, listar o ator e/ou sistema que deve
reagir.
17
Se um fluxo alternativo ou excepcional é para ser executado, descrever a
resposta de que o ator ou o sistema deve produzir.
3.3.3 Confirmar os Principais Casos de Uso
12. Examinar cuidadosamente o atual conjunto de casos de uso. Rever, conforme
necessário.
A revisão deve procurar oportunidades para simplificar um caso de uso,
decompondo-o em um conjunto de casos de uso menores, fundindo-o com outros, à
procura de aspectos comuns em semântica e sintaxe dos casos de uso e
identificação de novos casos de uso. Este é também o momento de procurar e
adicionar relacionamentos de include, extend ou generalização entre casos de uso.
13. Começar no topo novamente.
Usuários, muitas vezes, mudam de ideia sobre o que é um caso de uso e o
que inclui. Por isso, o analista deve continuar a iterar os passos até que ele e os
usuários acreditem que um número suficiente de casos de uso foi documentado para
começar a identificar as classes candidatas para o modelo estrutural. O
desenvolvimento de sistemas orientado a objeto é tanto iterativo e incremental.
Como tal, não se preocupar com a identificação de todos os possíveis casos de uso
neste ponto no desenvolvimento do sistema.
3.3.4 Criar o Diagrama de Caso de Uso
1. Desenhar a fronteira do sistema.
O diagrama do caso de uso inicia-se com o limite do sistema. Isto constitui a
fronteira, separando os casos de uso (funcionalidades do sistema) de agentes
(papéis dos usuários externos).
2. Colocar os casos de uso no diagrama.
Os casos de uso são desenhados no diagrama, tomadas diretamente das
descrições detalhadas dos casos de uso. Casos de uso de associações especiais
18
(include, extend ou generalização) também são adicionados ao modelo neste
momento.
3. Colocar os atores no diagrama.
Os atores são tirados diretamente do elemento ator principal na descrição
detalhada do caso de uso.
4. Desenhar as associações.
O último passo é desenhar as linhas que ligam os atores aos casos de uso
com as quais interagem.
3.3.5 Especificar Requisitos Não Funcionais
Requisitos não funcionais podem ser especificados em uma seção separada
da descrição do caso de uso, em muitos a mesma forma que as sequências
alternativas são especificadas. Se os requisitos não funcionais se aplicam a um
conjunto de casos de uso relacionados, eles podem ser documentados como tal.
3.4 EXERCÍCIOS
1. (TRE–CE) A análise de requisitos no desenvolvimento de sistemas especifica as
funcionalidades (requisitos funcionais) e as propriedades (requisitos não-
funcionais). É considerado um requisito não-funcional
a) uma informação na interface de entrada.
b) a notificação de inconsistência de dado na tela.
c) um histograma na interface gráfica do usuário.
d) a emissão de relatórios fiscais.
e) a disponibilidade do sistema.
2. (FINEP) Uma equipe de analistas está entrevistando gerentes de área para
levantar os requisitos do novo sistema de reservas de uma companhia aérea.
Considere as afirmativas sobre os requisitos levantados.
I - O usuário poderá fornecer um roteiro com múltiplos pontos de parada.
19
II - O total a ser pago deverá ser expresso na moeda escolhida pelo usuário.
III - As trocas de informações com os sistemas das empresas coligadas (hotéis,
locadora de veículos, etc.) são feitas através de Web Services.
É (São) requisito(s) funcional(ais) o que é apresentado em
a) I, apenas.
b) III, apenas.
c) I e II, apenas.
d) II e III, apenas.
e) I, II e III.
3. (TCE–PR) Identificar e especificar os requisitos funcionais e os não funcionais
são atividades da Engenharia de Requisitos realizadas nos processos de
a) planejamento de gerenciamento de requisitos e análise do problema.
b) análise do problema e definição dos sistemas.
c) definição dos sistemas e refinamento dos requisitos
d) refinamento dos requisitos e aprovação dos requisitos.
e) aprovação dos requisitos e planejamento de gerenciamento dos requisitos.
4. (TCE–PR) São do tipo não funcionais, relacionado ao produto software,
APENAS os requisitos de
a) desempenho e de portabilidade.
b) desempenho e de entrega.
c) portabilidade e de interoperabilidade.
d) portabilidade e legais.
e) facilidade de uso e legais.
5. (PRODEMGE) Em relação aos tipos de requisitos de software, analise os itens a
seguir e coloque (V) para a assertiva verdadeira e (F) para a assertiva falsa.
( )
Requisitos de sistema são declarações, em uma linguagem natural com
diagramas, de quais serviços são esperados do sistema.
( ) Requisitos funcionais são declarações de serviços que o sistema deve
fornecer, como o sistema deve reagir a entradas específicas e como
deve se comportar em determinadas situações.
( ) Requisitos de usuário definem, detalhadamente, as funções, os
serviços e as restrições operacionais do sistema.
20
( )
Requisitos de domínio são provenientes do domínio da aplicação do
sistema e refetem as características e as restrições desse domínio.
6. (INB) Ao se proceder a Análise de Requisitos Funcionais de um projeto/sistema a
ser desenvolvido, pode-se afirmar que essa é a etapa onde se dá, EXCETO:
a) O entendimento do negócio.
b) O levantamento da situação atual e do que se pretende desenvolver.
c) O planejamento do projeto/sistema.
d) O fechamento de escopo do projeto/sistema.
e) A definição do hardware que será necessário à implantação do
projeto/sistema.
7. (SAD–PE) Um requisito de software expressa as necessidades e restrições
colocadas em um produto de software que contribuem para a solução de algum
problema do mundo real. Acerca desse assunto, assinale a opção correta.
a) Os contratantes ou clientes são os principais colaboradores envolvidos no
fornecimento de informações para o processo de levantamento ou elicitação de
requisitos de software, os demais grupos de pessoas que podem fornecer
informações são considerados de importância secundária.
b) As necessidades dos usuários a serem atendidas por um produto
de software constituem a classe de requisitos funcionais, e as restrições
mencionadas na definição de requisitos constituem a classe de requisitos não
funcionais.
c) Entre as fontes de informação para a elicitação de requisitos, destacam-se,
além dos colaboradores, o conhecimento do domínio de aplicação em que
o software funcionará, o ambiente operacional do software e o ambiente
organizacional.
d) A negociação de requisitos, de forma similar à observação do ambiente
organizacional, é uma atividade típica da fase de elicitação de requisitos.
e) A técnica de casos de uso, empregada em alguns modelos de
desenvolvimento de software atuais, é mais aderente à construção de cenários
durante a construção de protótipos que durante a elicitação de requisitos.
8. (TCE–TO) A respeito de análise de requisitos, julgue os itens a seguir.
I. O usuário deve ser capaz de pesquisar tanto no banco de dados inteiro como
em uma parte dele.
21
II. A interface de usuário para o sistema deve ser implementada em HTML
sem frames ou em applets Java.
III. O sistema deve fornecer visões apropriadas para que o usuário possa ler
documentos.
IV. Cada ordem deve ter um identificador único (OSID), que o usuário deve poder
copiar na área permanente de armazenamento da conta.
V. O processo de desenvolvimento do sistema e os documentos devem ser
realizados conforme o padrão interno da empresa.
São requisitos funcionais apenas os itens
a) I, II e III. b) I, II e V. c) I, III e IV. d) II, IV e V. e) III, IV e V.
9. (MPE–BA) Identifique com V as afirmativas verdadeiras e com F, as falsas.
( )
Os requisitos não funcionais restringem o sistema que está sendo
desenvolvido e o processo de desenvolvimento que deve ser usado e
estão, frequentemente, relacionados às propriedades emergentes do
sistema de modo que se aplicam ao sistema em sua totalidade.
( )
A prototipação não é considerada uma técnica usada para validação de
requisitos, pois ocorre na fase final do processo de desenvolvimento,
representado a entrega do sistema aos usuários finais e clientes.
( ) Pode-se considerar que a entrada para o estudo de viabilidade consiste
em um conjunto preliminar de requisitos de negócios, um esboço da
descrição do sistema e como esse sistema pretende apoiar os processos
de negócios.
( ) A análise de requisitos possibilita que o Engenheiro de Software
especifique a função e o desempenho do software.
( ) Os testes de software são atividades de garantia da qualidade por si
mesmo.
( ) A segurança de software é uma atividade de garantia de qualidade de
software que se concentra na identificação e avaliação de casualidades
em potencial que possam exercer um impacto negativo sobre o software e
fazer com que todo o sistema falhe.
10. (MEC) Requisitos não-funcionais estão diretamente relacionados com a
satisfação dos usuários. Assinale a alternativa que não indique um requisito
não-funcional
22
a) O sistema de arquivos deve ser protegido, para acesso, apenas, de
usuários autorizados.
b) O software deve ser implementado usando os conceitos de orientação a
objetos.
c) O tempo de desenvolvimento do software não deve ultrapassar seis
meses.
d) O software poderá ser executado em plataforma windows e linux.
e) O software deve emitir relatórios de vendas a cada quinze dias.
11. (SEFAZ-SC) Considere a seguinte relação de requisitos estabelecida para
um software hipotético.
1. O software deverá ser implementado em Java.
2. O software deve interagir com o usuário por meio de um navegador
(browser), isto é, deve ser implementado como uma aplicação para Web.
3. O software deve registrar log de todas as operações realizadas.
4. O software deve responder a qualquer solicitação do usuário em, no
máximo, 500 milissegundos.
5. O conjunto de produtos gerados deve incluir especificação de projeto em
UML.
6. O software deve ser desenvolvido na plataforma Eclipse.
Assinale a alternativa que contém apenas números correspondentes a
requisitos classificáveis como não funcionais.
a) 1 - 5 – 6
b) 1 - 2 - 4 - 5 – 6
c) 1 - 2 - 3 - 4 - 5 – 6
d) 2 - 3 – 4
e) 2 - 4
12. (TCE-GO) Para evitar descrever o mesmo fluxo de eventos diversas vezes
quando se tratar de um comportamento comum a vários casos de uso, é
recomendado escrever esse comportamento em um único caso de uso e
relacioná-lo aos demais por meio de um relacionamento de
a) agregação por composição.
b) agregação simples.
c) generalização.
d) extensão.
23
e) inclusão.
13. (CODESP-SP) No emprego da UML utilizam-se diversos diagramas. Nos
Casos de Uso, analise a situação abaixo:
Sejam ALFA e BETA dois casos de uso.
Quando BETA herda de ALFA, as sequências de comportamento de ALFA
valem também para BETA.
Quando for necessário, BETA pode redefinir as sequências de
comportamento de ALFA.
Além disso, BETA, na condição de caso de uso herdeiro, participa em
qualquer relacionamento no qual ALFA participa.
A situação descrita caracteriza um relacionamento denominado
a) de inclusão.
b) de extensão.
c) generalização.
d) associação.
e) agregação.
14. (BDMG-2011) São elementos que podem estar presentes em um Diagrama
de Casos de Uso da UML, EXCETO:
a) Ator.
b) Assunto.
c) Relacionamento de generalização.
d) Objeto.
15. (INFRAERO-2011) Para captar os requisitos funcionais de um sistema
pode- se utilizar a UML. O diagrama mais adequado para essa finalidade é
o diagrama de
a) casos de uso.
b) atividades.
c) colaboração.
d) classes.
e) comunicações.
16. (TJ-ES) Com base no diagrama de caso de uso da UML 2.0, mostrado na
figura abaixo, é correto afirmar que
24
( ) a seta identificada por V indica uma relação de dependência
obrigatória.
( ) a seta identificada por VI indica uma dependência opcional.
( ) a seta identificada por VII está usada de forma incorreta, pois não
há generalização entre casos de uso.
( ) o usuário Registered Customer pode acionar o caso de uso Pay.
( ) o caso de uso Select menu item será acionado todas as vezes que
Order meal também for acionado.
17. (MEC-2009) A figura abaixo ilustra um Diagrama de Casos de Uso e é
utilizada no desenvolvimento de projetos de sistemas, utilizando
ferramentas da Análise Orientada a Objetos.
25
O relacionamento entre o ator Cliente e o caso de uso Comprar um produto,
é denominado e definido como:
a) Associação / uma funcionalidade do sistema do ponto de vista do usuário
b) Generalização / uma funcionalidade do sistema do ponto de vista do
usuário
c) Generalização / uma funcionalidade do sistema do ponto de vista do
usuário
d) Globalização / uma funcionalidade do sistema do ponto de vista do
relacionamento
e) Generalização / uma funcionalidade do sistema do ponto de vista do
relacionamento
18. (TRE-AP) Os casos de uso podem ser organizados pela especificação de
relacionamentos de
a) evento, ramificação e inclusão.
b) composição, inclusão e extensão.
c) agregação, extensão e bifurcação.
d) generalização, inclusão e extensão.
e) herança, composição e autorrelacionamento.
19. (TRE-RN) Na modelagem de Caso de Uso, <<include>> e <<extend>> são
relacionamentos de
a) dependência.
b) agregação.
c) especialização.
d) atores entre si.
e) atores com os casos de uso.
(PRODAM-AM) Sejam as seguintes assertivas sobre o Modelo de Casos de
Uso na UML2.0:
I. O único tipo de relação possível entre um ator e um caso de uso é uma
associação. Ele representa a comunicação entre um ator e um caso de
uso.
II. A relação de generalização entre casos de uso não é permitida. Ela deve
ser substituída pela relação .
III. Atores podem se relacionar através de uma generalização ou de uma
associação.
26
IV. Os componentes mais importantes do modelo de casos de uso são os
diagramas de caso de uso.
V. O modo pelo qual os casos de uso devem ser textualmente descritos
está formalmente definido no documento OMG Unified Modeling Language
(OMG UML) Superstructure.
Dentre as assertivas acima, quantas são verdadeiras?
a) 1 b) 2 c) 3 d) 4 e) 5
20. (SEFAZ-SC) Considere a seguinte modelagem de casos de uso:
Com base nas informações contidas na modelagem de casos de uso acima,
é correto afirmar:
a) Ambos os elementos representados pelos atores AtorA e AtorB têm
participação em todas as ocorrências do caso de uso UC1.
b) Apenas um dos elementos representados pelos atores (AtorA ou AtorB) tem
participação em cada ocorrência do caso de uso UC2.
c) Ambos os elementos representados pelos atores AtorA e AtorB têm
participação em todas as ocorrências do caso de uso UC3.
d) O elemento representado pelo ator AtorA pode ter participação em uma
ocorrência do caso de uso UC1.
e) O elemento representado pelo ator AtorA tem participação em todas as
ocorrências dos casos de uso UC1, UC2 e UC3.
21. Crie um conjunto de casos de uso e um diagrama de casos de uso para os
seguintes processos em um sistema de locação executado pelo serviço de
alojamento do campus. O serviço de alojamento do campus ajuda os estudantes
encontrarem apartamentos. Os proprietários dos apartamentos preenchem
formulários com as informações sobre as unidades para locação disponíveis (por
exemplo, localização, número de quartos, aluguel mensal), que são, então,
armazenadas em um banco de dados. Os alunos podem pesquisar esta base de
dados através da Web para encontrar apartamentos que atendam às suas
27
necessidades (por exemplo, um apartamento de dois quartos por R$ 400 por
mês menos de 1 km do campus). Eles, então, diretamente, entram em contato
com os proprietários e veem o apartamento e, possivelmente, alugam-no. Os
proprietários dos apartamentos chamam o serviço e excluem o nome da lista,
quando alugam o apartamento.
22. Crie um conjunto de descrições detalhado de casos de uso e desenhe um
diagrama de casos de uso para um sistema on-line de registro universidade. O
sistema deve permitir que a equipe de cada departamento acadêmico examine
os cursos oferecidos pelo departamento, adicione e remova cursos, e altere
informações sobre eles (por exemplo, o número máximo de alunos permitido).
Ele deve permitir que os estudantes examinem os cursos atualmente disponíveis,
adicione e descarte cursos de seus calendários, e examinem os cursos para os
quais estão inscritos. A equipe do departamento deve ser capaz de imprimir uma
variedade de relatórios sobre os cursos e os alunos matriculados nos mesmos. O
sistema deve assegurar que nenhum estudante tenha cursos demais e que os
alunos que tenha qualquer taxa não paga não tenha o registro autorizado (supor
que os dados de pagamento de taxa é mantido pelo escritório financeiro da
universidade, no qual o sistema de registro acessa, mas não altera).
23. Crie um conjunto detalhado das descrições de caso de uso e desenhe um
diagrama de caso de uso para o seguinte sistema: Uma loja de vídeo executa
uma série de reservas de vídeo bastante normal. Antes que um vídeo possa ser
colocado na prateleira, deve ser catalogado no banco de dados. Cada cliente
deve ter um cartão de cliente válido, a fim de alugar um vídeo. Clientes alugam
vídeos por três dias em um momento. Cada vez que um cliente aluga um vídeo,
o sistema deve garantir que ele não tem nenhum vídeo em atraso. Se for assim,
os vídeos vencidos devem ser devolvidos e pago uma multa de atraso antes que
o cliente possa alugar novos vídeos. Da mesma forma, se o cliente devolver
vídeos com atraso, mas ainda não pagou a multa por atraso, a multa deve ser
paga antes que novos vídeos possam ser alugados. Todas as manhãs, o gerente
da loja imprime um relatório que lista os vídeos em atraso. Se um vídeo está com
dois ou mais dias de atraso, o gerente chama o cliente para lembrá-lo de
devolver o vídeo. Se um vídeo é devolvido em condições de avaria, o gerente
remove-o do banco de dados de vídeo e às vezes pode cobrar do cliente.
28
24. Criar um conjunto de descrições detalhadas de caso de uso de e desenhe um
diagrama de casos de uso para um sistema de empréstimos de uma biblioteca
universitária (não se preocupe com a pesquisa do catálogo, etc.) O sistema irá
gravar os livros de propriedade da biblioteca e vai gravar quais livros tenha
emprestado. Antes que alguém possa pedir emprestado um livro, ele deve
mostrar um cartão de identificação válido, que é verificado no banco de dados de
estudante mantido pela secretaria (para os empréstimos de estudantes), o banco
de dados de professores/funcionários mantido pelo departamento de pessoal
(para empréstimos de professores/funcionários). O sistema também deve
verificar e garantir que o mutuário não tem nenhum livro em atraso ou multas não
pagas antes que ele possa pedir emprestado um outro livro. Toda segunda-feira,
a biblioteca imprime e envia postais para as pessoas com livros em atraso. Se
um livro está vencido há mais de duas semanas, uma multa será imposta e um
bibliotecário vai telefonar para o mutuário para lembrar-lhe de devolver o(s)
livro(s). Às vezes, os livros são perdidos ou são devolvidos em condições de
avaria. O gerente deve, então, removê-los do banco de dados e, por vezes,
impor uma multa ao devedor.
25. (Petrobrás – 2012) Um restaurante contratou uma equipe para desenvolver um
sistema de informação que auxilie nas tarefas diárias do negócio. Após um
levantamento inicial, a equipe listou os seguintes requisitos:
o caixa será responsável por encerrar uma conta e registrar o pagamento da
mesma;
caso o pagamento seja feito com cheque, será necessário que o sistema do
restaurante se comunique com o sistema de consulta de cheques do Serviço
de Proteção ao Lojista para obter informações sobre o cliente;
caso o pagamento seja feito com cartão de crédito, será necessário que o
sistema do restaurante se comunique com o sistema da administradora do
cartão para obter autorização;
apenas o gerente terá acesso à função de estorno do valor pago. Caso a
despesa tenha sido paga com cartão, será necessário se comunicar com o
sistema da administradora;
tanto o sistema da administradora de cartões como o de consulta de cheques
serão acessados via web service;
o gerente também poderá encerrar uma conta.
29
Desenhe um diagrama de caso de uso que descreva adequadamente os
requisitos acima.
3.5 PROJETO
O objetivo é projetar e implementar um software orientado a objeto de um
sistema de caixa eletrônico (Automatic Teller Machine – ATM, máquina de
autoatendimento).
3.5.1 Examinar o Documento de Requisitos
O documento de requisitos especifica a finalidade e o que deve fazer o
sistema ATM.
Um banco local pretende instalar uma nova máquina de caixa automatizada
(ATM) para permitir que aos usuários (os clientes do banco) efetuar transações
financeiras básicas. Cada usuário pode ter apenas uma conta no banco. Os usuários
ATM devem ser capazes de ver o saldo da conta, retirar dinheiro da conta e os
fundos de depósito. A interface de usuário do caixa automático é ilustrada na figura
5 e contém:
uma tela que exibe mensagens para o usuário,
um teclado que recebe a entrada numérica do usuário,
um terminal que distribui dinheiro para o usuário e
um slot (abertura) de depósito que recebe envelopes de depósito do usuário.
O terminal começa cada dia carregado com 500 notas de R$ 20,00.
O banco quer o desenvolvimento de um software que realize as transações
financeiras iniciadas por clientes do banco através da ATM. O banco vai integrar o
software com o hardware da ATM em um momento posterior. O software deve
encapsular a funcionalidade dos dispositivos de hardware (por exemplo, o terminal,
o slot de depósito) dentro de componentes de software, mas não precisa se
preocupar com a forma como estes dispositivos desempenharão suas funções. O
30
hardware da ATM ainda não foi desenvolvido, então em vez de escrever o software
para rodar no caixa eletrônico, deve-se desenvolver uma primeira versão para rodar
em um computador pessoal. Esta versão deve usar o monitor do computador para
simular a tela do caixa eletrônico, e o teclado do computador para simular o teclado
da ATM.
Figura 5 – Interface do usuário do caixa eletrônico.
Fonte: DEITEL P. e DEITEL H. (2012), p 320.
Uma sessão da ATM consiste em autenticar um usuário (ou seja, provar a
identidade do usuário), com base em um número de conta e o número de
identificação pessoal (CPF), seguido por criar e executar transações financeiras.
Para autenticar um usuário e executar operações, a ATM deve interagir com o banco
de dados para acessar informações da conta. Para cada conta bancária, o banco de
dados armazena um número de conta, um CPF e um balanço indicando o montante
de dinheiro na conta.
No primeiro acesso a ATM, o usuário deve encontrar a seguinte sequência
de eventos:
1. A tela exibe a mensagem “Bem-vindo!” e solicita que o usuário digite um número
de conta.
2. O usuário digita um número de conta de cinco dígitos usando o teclado.
3. A tela solicita que o usuário digite o CPF (número do cadastro de pessoa física)
associado com o número da conta especificada.
4. O usuário digita uma senha de cinco dígitos usando o teclado.
31
5. Se o usuário digitar um número de conta válido e o CPF correto para essa conta,
a tela exibe o menu principal, apresentado na figura 6. Se o usuário digitar um
número de conta ou um CPF inválido, a tela exibe uma mensagem apropriada,
então a ATM retorna para o passo 1, reiniciando o processo de autenticação.
Figura 6 – Menu principal da ATM.
Fonte: DEITEL P. e DEITEL H. (2012), p 321.
Depois que a ATM autentica o usuário, o menu principal deve conter uma
opção numerada para cada um dos três tipos de operações: 1 – consulta de saldo, 2
– retirada e 3 – depósito. E deve conter uma opção para o usuário sair do sistema.
Se o usuário digitar 1 (consultar o saldo), a tela exibe o saldo da conta do
usuário. Para isso, a ATM deve recuperar o saldo a partir do banco de dados.
Os passos abaixo descrevem o que ocorre quando o usuário entra no 2 para
fazer um saque:
1. A tela exibe um menu como a figura 7, contendo as quantidades padrão de
saque: R$ 20,00 (opção 1), R$ 40,00 (opção 2), R$ 60,00 (opção 3), R$ 100,00
(opção 4) e R$ 200 (opção 5). O menu também contém uma opção para permitir
que o usuário cancele a transação (opção 6).
32
Figura 7 – Menu de saque da ATM.
Fonte: DEITEL P. e DEITEL H. (2012), p 321.
2. O usuário entra com uma seleção do menu usando o teclado.
3. Se o valor do saque escolhido for maior do que o saldo da conta do usuário, a
tela exibe uma mensagem informando isso e dizendo que o usuário escolha uma
quantidade menor. A ATM volta para o passo 1. Se a quantidade escolhida para
saque for inferior ou igual ao saldo da conta do usuário, a ATM prossegue para o
passo 4. Se o usuário optar por cancelar a transação (opção 6), a ATM exibe o
menu principal e espera pela entrada do usuário.
4. Se o terminal contém dinheiro suficiente, a ATM prossegue para o passo 5. Caso
contrário, a tela exibe uma mensagem indicando o problema e informando ao
usuário para escolher uma quantidade menor de retirada. A ATM volta para o
passo 1.
5. A ATM debita o valor do saque da conta do usuário no banco de dados do banco
(ou seja, subtrai o valor do saque do saldo da conta do usuário).
6. O terminal dispensa a quantidade desejada de dinheiro para o usuário.
7. A tela exibe uma mensagem lembrando ao usuário para pegar o dinheiro.
Os passos seguintes descrevem as ações que ocorrem quando o usuário
digita 3 para fazer um depósito:
1. A tela solicita que o usuário digite um valor do depósito ou digitar 0 (zero) para
cancelar.
2. O usuário entra com o montante do depósito ou 0 usando o teclado. O teclado
não contém um ponto decimal ou um sinal de cifrão, por isso, o usuário deve
33
digitar um depósito como um número de centavos (por exemplo, 2725). A ATM,
em seguida divide esse número por 100 para obter um número que representa
um valor em reais (por exemplo, 2725 ÷ 100 = 27,25).
3. Se o usuário especificar um valor do depósito, a ATM prossegue para o passo 4.
Se o usuário optar por cancelar a transação (digitando 0), a ATM exibe o menu
principal e espera por uma entrada do usuário.
4. A tela exibe uma mensagem pedindo ao usuário para insirir um envelope de
depósito.
5. Se o slot de depósito recebea um envelope de depósito no prazo de dois
minutos, o ATM credita o valor do depósito para a conta do usuário no banco de
dados do banco. Esse dinheiro não estará imediatamente disponível para saque.
Primeiro, o banco deve verificar fisicamente a quantia de dinheiro no envelope de
depósito, e todos os controles no envelope deve estar transparentes (por
exemplo, o dinheiro deve ser transferido da conta do emitente do cheque para a
conta do destinatário do cheque). Quando um desses eventos ocorre, o banco
adequadamente atualiza saldo do usuário armazenando em seu banco de dados.
Isso ocorre independentemente do sistema ATM. Se o slot de depósito não
receber um envelope de depósito dentro deste período de tempo, a tela exibe
uma mensagem onde o sistema cancela a transação devido à inatividade. A ATM
exibe o menu principal e espera por entrada do usuário.
Depois que o sistema executar uma transação com sucesso, deve retornar
ao menu principal, de modo que o usuário possa executar operações adicionais. Se
o usuário sair do sistema, a tela deve exibir uma mensagem de agradecimento, em
seguida, exibir a mensagem de boas-vindas para o próximo usuário.
3.5.2 Diagramas de Casos de Uso
Crie um diagrama de casos de uso para modelar as interações entre os
clientes do sistema e os casos uso. Mostre os tipos de interações que os usuários
têm com um sistema sem fornecer detalhes. Os diagramas de casos de uso são
muitas vezes acompanhados de um texto informal que dá mais detalhes, como o
texto que aparece no documento de requisitos. São produzidos durante a fase de
34
análise do ciclo de vida do software. Em sistemas maiores, os diagramas de casos
de uso são ferramentas indispensáveis que ajudam os analistas de sistema
permanecerem focados em satisfazer as necessidades dos usuários.
3.6 BIBLIOGRAFIA
DEITEL, Paul; DEITEL, Harvey. Java for programmers. 2nd ed. Boston: Pearson
Education, 2012.
DENNIS, Alan; WIXOM, Barbara; TEGARDEN, David. System Analysis Design
UML Version 2.0. 3rd ed. Hoboken: John Wiley & Sons, 2009.
DOOLEY, John. Software Development and Professional Practice. 1st. ed. New
York: Apress, 2011.
GOMMA, Hassan. Software Modeling and Design. 1st. ed. New York: Cambridge
University Press, 2011.
MILES, Russ; HAMILTON, Kim. Learning UML 2.0. 1st ed. Sebastopol, 2006.
