Trabalho acadêmico PIM VI

•

UNIP

Gabriel Souza

19/10/2018

Prévia do material em texto

RESUMO
Para resolver o um problema de vendas de livro pela internet, uma livraria
resolveu contratar uma empresa para construir um sistema para venda de livros numa
loja virtual.
Estando cientes da necessidade de acompanhar o progresso tecnológico e
melhorar o atendimento aos clientes, a Livraria irá utilizar um software para controlar
todo o processo de vendas de livros, buscando maior qualidade, eficiência e
organização.
As pessoas que acessarem o site terão o acervo de livros bem amplo,
podendo ser adicionados no carrinho para uma possível compra. Quando um usuário
for efetuar tal compra na loja pela primeira vez, terá que fazer um cadastro de login e
senha para efetivar a compra de livros, caso já possua um cadastro, apenas digitar
seu login e senha para prosseguir na compra. E no momento da finalização da compra
terá a opção de pagamento somente por cartão de crédito, após a inserção dos dados
do cartão o sistema faz a conexão com a operadora de cartão para validar o crédito,
caso a validação for positiva é finalizado a compra, caso contrário é informado ao
usuário que a compra não foi efetuada porque a operadora não autorizou a compra.
Todo o projeto foi baseado nos conhecimentos obtidos nas disciplinas: Análise
de Sistemas Orientada a Objetos e Banco de Dados.

Palavras chave: Software, Livraria, Livros.

ABSTRACT
To solve your book sales problem on the internet, a bookstore decided to hire
a company to build a system for selling books in a virtual store.
Being aware of the need to monitor technological progress and improve
customer service, the bookstore will use software to control the entire book sales
process, seeking greater quality, efficiency and organization.
People who access the site will have a large collection of books and can be
added to the cart for a possible purchase. When a user makes such a purchase in the
store for the first time, he will have to make a login and password to make the purchase
of books, if you already have a registration is just enter your login and password to
proceed with the purchase. And at the time of the end of the purchase will have the
option of payment only by credit card, after inserting the data of the card the system
makes the connection with the card operator to validate the credit, if the validation is
positive is completed the purchase, otherwise the user is informed that the purchase
was not made because the operator did not authorize the purchase.
The whole project was based on the knowledge obtained in the disciplines:
Object-oriented Systems Analysis and Database.

Keywords: Software, Bookstore, Books.

SUMÁRIO
1. INTRODUÇÃO ............................................................................................... 8
2. MODELO CASOS DE USO E ATORES ...................................................... 10
2.1. Principais atores envolvidos no sistema ....................................................... 10
2.2. Principais objetivos do sistema ..................................................................... 11
2.3. Relação entre Atores e Casos de Uso .......................................................... 11
2.4. Cenários do tipo <<extends>> ou de <<include>> ....................................... 12
3. PROTÓTIPOS DAS TELAS ......................................................................... 14
3.1. Tela de Caso de Uso de Login ..................................................................... 14
3.2. Tela de Caso de Uso de Consultar Acervo ................................................... 14
3.3. Tela de Caso de Uso de Cadastro de Pessoa .............................................. 15
3.4. Tela de Caso de Uso de Finalizar Compra ................................................... 16
4. ESPECIFICAÇÃO DE CASOS DE USO ...................................................... 17
4.1. Consultar Acervo .......................................................................................... 17
4.2. Cadastro do Usuário ..................................................................................... 18
4.3. Fazer Login ................................................................................................... 18
4.4. Pedir Livro .................................................................................................... 19
4.5. Realizar Reserva .......................................................................................... 20
4.6. Pagar por Cartão de Crédito ......................................................................... 20
4.7. Requisitos Funcionais e não Funcionais ...................................................... 21
4.7.1. Requisitos Funcionais .......................................................................... 21
4.7.2. Requisitos não funcionais .................................................................... 21
4.7.3. 3. Regra de Negócio Geral ................................................................... 22
5. DIAGRAMA DE CLASSES E ENTTIDADE RELACIONAMENTO .............. 23
5.1. Diagrama de Classe ..................................................................................... 23
5.2. Modelo Entidade e Relacionamento ............................................................. 24
5.3. Diagrama de Classes de Análise .................................................................. 26

CONCLUSÃO ........................................................................................................... 27
REFERÊNCIAS ......................................................................................................... 28

LISTA DE FIGURAS
Figura 1 – Relação entre atores e caso de uso ......................................................... 12
Figura 2 – Cenário do tipo <<include>> .................................................................... 12
Figura 3 – Cenário do tipo <<extends>> ................................................................... 13
Figura 4 – Tela de Login ........................................................................................... 14
Figura 5 – Tela do Acervo ......................................................................................... 14
Figura 6 – Tela de Livro ............................................................................................ 15
Figura 7 – Tela de Cadastro de Pessoa .................................................................... 15
Figura 8 – Tela de Finalizar Compra ......................................................................... 16
Figura 9 – Diagrama de Classes ............................................................................... 24
Figura 10 – Modelo Entidade e Relacionamento (MER) ........................................... 25
Figura 11 – Diagrama de Classes de Análise ........................................................... 26

1. INTRODUÇÃO
Tendo o objetivo de apresentar o conhecimento adquirido com as disciplinas:
“Análise de Sistemas Orientada a Objetos”, “Banco de Dados” e “Gestão Estratégica
de RH”, este projeto está elaborado de acordo com o tema proposto: “Levantamento
e a Análise de Requisitos de um Sistema”, que tem como cenário uma livraria virtual.
Estão apresentados no contexto do projeto as técnicas que serão utilizadas
na análise de requisitos, o desenvolvimento do sistema e o armazenamento de dados
do sistema da loja virtual, que foram adquiridas com o aprendizado das disciplinas
neste bimestre.
Utilizando o conhecimento obtido na disciplina “Análise de Sistemas Orientada
a Objetos” foram identificados os atores que interagem com o sistema, que por sua
vez não foram muitos. Foram identificados os casos de usos, que são os objetivos do
sistema. Cada caso deuso foi descrito passo a passo para mostrar o fluxo do processo,
começo, meio e fim. Identificando os fluxos alternativos e as regras de negócio.
Com base na disciplina “Banco de Dados”, foi pensado na esquematização
da base de dados, ou seja, quais são as informações que desejamos armazenar e a
forma como os dados devem ser agrupados.
A fim de não haver informações redundantes, foi criado um fluxo de alguns
passos que foram adotados, como:
O conteúdo dos campos, dessa forma foi identificado previamente o conteúdo
a ser incluído na base de dados, pensando em possíveis futuras inclusões.
O tipo de informação (metadados), determinando assim se iriam ser números,
textos, datas, etc.
O enquadramento da Base de Dados, criando um padrão para os nomes da
base de dados. Determinando também a ordem em que estes seriam organizados.
O relacionamento das tabelas entre si, pensando sempre se existiria uma
necessidade se relacionar com outras tabelas por meio de um dado comum.
Chave primaria e índices, assim foi gerado uma forma única de identificar um
item específico, facilitando a busca pelo mesmo e uma futura relação com outras
tabelas ‘filho’.
E a disciplina “Gestão Estratégica de RH” não tem um tópico específico, mas
foi utilizada na organização do desenvolvimento do trabalho. As tarefas eram
delegadas a cada membro e depois o grupo discutia sobre o assunto e chegava a
9

uma conclusão sem conflitos. Assim todos os requisitos, pedido para o trabalho, foram
desenvolvidos sem problemas.

2. MODELO CASOS DE USO E ATORES
Caso de uso é a descrição de uma sequência de atividades executadas por
um agente externo ao sistema sem que sejam revelados detalhes do
funcionamento interno ao sistema, por isso dizemos que o caso de uso
mostra a visão comportamental externa ao sistema (Versolatto.,2015, pg 61).
Modelar um Caso de uso é como contar uma história, em ambos os casos
existe um padrão, um conjunto de regras que serve para padronizar o “conto” de
maneira que a pessoa que for utilizá-lo entenda a funcionalidade de modo único que
o sistema oferece, seguindo um padrão específico.
O modelo de casos de uso são os objetivos que o sistema deve executar para
atingir o que precisa, e serve como um contrato estabelecido entre o cliente e os
desenvolvedores. Também é usado como fonte de informações essencial para
atividades de análise, design e teste. E representa uma possível utilização do sistema
por atores, que podem ser pessoas, dispositivo físico, mecanismo ou subsistema que
interage com o sistema alvo, utilizando algum de seus serviços.
Atores são os agentes externos ao sistema que executam uma determinada
ação e que esperam algum resultado, ou seja, interagem diretamente com o
sistema a partir dos casos de uso (Versolatto.,2015, pg 61).
Um caso de uso demonstra a interação entre o sistema e os atores envolvidos,
para atingir um ou mais objetivos. Deve estar relacionado a um processo bem definido,
com começo, meio e fim.
2.1. Principais atores envolvidos no sistema
Ator é qualquer entidade externa que interage com o sistema: usuários,
outros sistemas de software ou até mesmo dispositivos de hardware.
Um ator nunca é um componente interno do sistema, ou mesmo qualquer
detalhe interno ou componente de implementação dele.
Um sistema nunca é um ator de si mesmo (Versolatto.,2015, pg 61).
Na identificação de um ator, é utilizado um substantivo no singular. Evitar tipos
genéricos, como Usuários e Clientes, opte pela descrição, como Usuário e Cliente.
11

Existem dois tipos de atores: principal e secundário. Os atores principais
interagem diretamente com o sistema computacional, já os atores secundários
interagem com outros atores.
Atores principais do sistema: usuário e proprietário da loja.
Atores secundários: sistema da operadora de cartão.
2.2. Principais objetivos do sistema
É muito importante identificar o caso de uso por um nome que o represente,
utilizando frases iniciadas com verbos no infinitivo, seguido pela meta ou tarefa a ser
realizada. Por exemplo: “Efetuar saque de conta‑corrente”.
Considerando que numa loja virtual o usuário abre o site e faz as consultas
desejadas, e somente se for comprar algo que fará o acesso por “Login” e “Senha”,
portanto, vamos considerar que no sistema da livraria será necessário fazer login
antes de acessar o acervo.
Acessar Site por Meio de Login e Senha;
Cadastrar Usuário;
Consultar Acervo de Livros;
Pedir Livro
Realizar Reserva;
Pagar por Cartão de Crédito;
2.3. Relação entre Atores e Casos de Uso
Um relacionamento de associação pode existir entre um ator e um caso de
uso. Esse tipo de associação é normalmente chamado como uma Associação de
Comunicação, desde que ela represente uma comunicação entre um ator e um caso
de uso. Uma associação é representada como uma linha que liga os elementos a
serem relacionados. A navegação em somente uma direção pode ser representada
pela adição de uma seta que indica a direção na linha da associação. Não pode existir
no modelo um caso de uso iniciado por dois atores. Existem somente 3 tipos de
relacionamentos entre os casos de uso: <<include>>, <<extends>> e a generalização,
ilustrado na figura 1.
12

Figura 1 – Relação entre atores e caso de uso

Fonte: Desenvolvido pelos alunos
2.4. Cenários do tipo <<extends>> ou de <<include>>
Quando um caso de uso possui um comportamento parcial comum a vários
outros casos de uso é chamado de <<include>>. Esse tipo de relacionamento é
obrigatório a inclusão do outro caso de uso evitando repetir comportamento, tendo o
reuso de códigos, conforme ilustrado na figura 2.
Figura 2 – Cenário do tipo <<include>>

Fonte: Desenvolvido pelos alunos
Os cenários de includes para o cliente serão: login, autenticação, compra,
pagamento e para os administradores e funcionários serão: configuração, entrada de
livro, saída de livro, ajuste de estoque.
Um relacionamento de <<extends>> é usado para mostrar comportamento
opcional, comportamento que somente é executado sobre determinadas condições,
como o caso de fazer login em uma loja virtual, o cadastro será chamado somente em
caso do usuário não tiver cadastro, conforme ilustrado na imagem 3.

Figura 3 – Cenário do tipo <<extends>>

Fonte: Desenvolvido pelos alunos
O caso de uso de extensão não tem execução obrigatória, mas opcional. No
sistema terá um cenário extends, que é a reserva de livros, que será chamada
somente em caso do livro não tiver disponível no acervo.

3. PROTÓTIPOS DAS TELAS
Nesse capítulo será apresentado um esboço de cada tela do sistema onde o
usurário poderá se cadastrar na loja virtual, acessar o acervo e efetuar a compra do
livro.
3.1. Tela de Caso de Uso de Login
Quando o usuário for comprar o livro terá de acessar o sistema através de
uma tela de “Login”, conforme está ilustrado na imagem 4, inserindo “Login” e “Senha”
e pressionar o botão “Entrar” para ter o acesso. O login será utilizado o e-mail do
usuário cadastrado no sistema.
Figura 4 – Tela de Login
Fonte: Desenvolvido pelos alunos
3.2. Tela de Caso de Uso de Consultar Acervo
Com o acesso autorizado pela tela de “Login”, o usuário terá acesso ao acervo
dos livros cadastrado no sistema. Aparecerá uma tela contendo um campo para
pesquisa dos livros desejados, e logo abaixo uma lista de links por categoria, onde é
possível ser levado a uma lista de livros da categoria que foi escolhida, conforme
ilustrado na figura 5.
Figura 5 – Tela do Acervo
Fonte: Desenvolvido pelos alunos
15

Ao selecionar o livro desejado, o sistema abre uma tela contendo o livro com
algumas informações do mesmo. Logo abaixo existem dicas de outros livros que
foram compradosjuntos, e/ou com o mesmo tema, e no lado direito o botão para
inserir o livro no carrinho, conforme ilustrado na figura 6.
Figura 6 – Tela de Livro
Fonte: Desenvolvido pelos alunos
3.3. Tela de Caso de Uso de Cadastro de Pessoa
Caso for a primeira vez que o usuário está acessando a livraria virtual, então
é necessário se cadastrar. Nesse cadastro é necessário: nome, CPF, RG, Telefone,
E-mail, Senha e Endereço completo e data de nascimento. Esses dados serão
utilizados para acesso ao sistema, a emissão de nota fiscal e para entrega do livro
comprado, conforme ilustrado na figura 7.
Figura 7 – Tela de Cadastro de Pessoa

Fonte: Desenvolvido pelos alunos

3.4. Tela de Caso de Uso de Finalizar Compra
Após o usuário inserir todos os livros desejados no carrinho e clicar para
compra-los, o sistema entra na tela de finalização de compra exibindo o endereço de
entrega do produto, forma de entrega e forma de pagamento, que por sua vez só terá
cartão de crédito como forma única de pagamento.
Nessa tela o sistema permite o usuário editar de endereço ou inserir outro
para entrega, mudar a quantidade do produto na lista, selecionar o tipo de entrega ou
voltar para escolher mais livros, conforme ilustrado na figura 8.
Figura 8 – Tela de Finalizar Compra

Fonte: Desenvolvido pelos alunos

4. ESPECIFICAÇÃO DE CASOS DE USO
[...] é um conjunto de métodos, procedimentos e ferramentas que tem por
objetivo descobrir, analisar, documentar, verificar e validar esses requisitos.
[...] suas principais características e objetivos e uma visão a respeito da
sequência de execução dessas atividades (Versolato, 2015, pg 59).
4.1. Consultar Acervo
Breve descrição: permitir que os usuários realizem consultas ao acervo de
livros do site para verificar sua existência e disponibilidade.
Ator: Usuário.
Pré-condição: os usuários estarem com o site aberto.
Pós-condição: não se aplica.
Fluxo principal:
1 - O sistema exibe a tela de consulta ao acervo;
2 - O usuário informa um parâmetro de busca (autor ou título) (F1, F2, R1);
3 - O sistema exibe a lista de livros com título, autor e local da obra;
4 - O caso de uso é encerrado.
Fluxo alternativo:
F1 - O sistema não encontra o livro procurado:
• O sistema exibe a mensagem “Livro não encontrado”;
• Retorna ao passo 1 do fluxo principal.
F2 - Obra não disponível:
• O sistema exibe um botão para reserva e um para cancelar;
• Pressiona o botão de cancelar;
• Volta ao passo 1 do fluxo principal.
Regra de Negócio:
R1 – Validação do campo
• O sistema só libera o botão de consulta se o campo estiver preenchido
pelo menos 5 letras;
• Volta ao passo 1 do fluxo principal.
18

4.2. Cadastro do Usuário
Breve descrição: o usuário entra no formulário de cadastro e insere todos seus
dados pessoais, endereço, e-mail, senha e salva.
Ator: Usuário.
Pré-condição: ser maior de 18 anos;
Pós-condição: os dados do usuário serão gravados no banco de dados;
Fluxo principal:
1 - Entra na tela de cadastro, e clicar no botão cadastrar usuário;
2 - Preencher todos os campos do formulário: nome completo, cpf, rg, telefone,
data de nascimento, e-mail, senha de acesso, senha de confirmação, nome
da rua, cep, número, cidade, estado, país (R1, R2).
3 - Clicar no botão para salvar os dados (F1);
4 - O caso de uso é finalizado.
Fluxo alternativo:
F1 - Todos os campos não foram preenchidos:
• O sistema exibe uma mensagem “É necessário preencher os campos
obrigatórios” e deixar os campos que estão vazios em vermelho;
• Retorna ao passo 2 do fluxo principal.
Regra de Negócio:
R1 – Idade menor de 18 anos
• O sistema exibe uma mensagem “A idade dever ser maior que 18 anos”.
• Retorna ao passo 2 do fluxo principal.
R2 – A senha não confere nos 2 campos
• O sistema exibe uma mensagem “As senhas não conferem, tente
novamente.”
• Retorna ao passo 2 do fluxo principal.
4.3. Fazer Login
Breve descrição: o usuário entra na tela de login, insere login, senha e
confirma.
Ator: Usuário.
Pré-condição: ser cadastrado no sistema;
Pós-condição: não se aplica;
19

Fluxo principal:
1 - Abrir a tela de login;
2 - Inserir login e senha;
3 - Clicar no botão para logar;
4 - O sistema valida o login (F1);
5 - O caso de uso é finalizado.
Fluxo alternativo:
F1 - Login ou Senha não conferem:
• O sistema exibe uma mensagem “Login ou senha inválida”;
• Volta ao passo 2 do fluxo principal.
4.4. Pedir Livro
Breve descrição: permite o usuário selecionar um livro por vez e inserir no
carrinho, escolher a quantidade de livros, excluir o livro do carrinho, voltar as compras
sem finalizar e finalizar a compra.
Ator: Usuário.
Pré-condição: ser cadastrado no sistema;
Pós-condição: ter um cartão de crédito para efetuar o pagamento;
Fluxo principal:
1 - O usuário filtra o livro (F1);
2 - Insere no carrinho;
3 - Entra no carrinho;
4 - Clica no botão para finalizar;
5 - Sistema verifica se o usuário está logado (F2);
6 - Caso de uso é encerrado.
Fluxo alternativo:
F1 – Livro não está disponível
• sistema exibe uma mensagem “Produto indisponível, quer fazer reserva?”
exibindo botão de “Reservar” e “Cancelar”;
• Volta ao passo 1 do fluxo principal.
F2 – Usuário não está logado:
• Se não está logado o sistema exibe uma mensagem “Necessário fazer
Login”;
20

• Volta ao caso de uso “Fazer Login” passo 2.
4.5. Realizar Reserva
Breve descrição: com a indisponibilidade do livro, o usuário poderá reservar o
livro preenchendo um formulário com o e-mail e o título do livro desejado.
Ator: Usuário.
Pré-condição: livro estar indisponível;
Pós-condição: não se aplica;
Fluxo principal:
1 - Clicar no botão de reserva;
2 - Inserir o e-mail;
3 - Sistema valida e-mail (R1);
4 - Caso de uso é encerrado.
R1 – E-mail inválido:
• O sistema exibe uma mensagem “E-mail inválido”;
• Volta ao passo 2 do fluxo principal.
4.6. Pagar por Cartão de Crédito
Breve descrição: o usuário clica no botão finalizar compra, o sistema abre uma
tela mostrando a opção de cartão de crédito como forma única de pagamento, valor
total e um formulário para preencher os dados do cartão. O usuário preenche os dados
do cartão e confirma o pagamento.
Ator: Usuário.
Pré-condição: deve haver um ou mais livros no pedido;
Pós-condição: transação finalizada com sucesso;
Fluxo principal:
1 - Insere os dados do cartão (R1);
2 - Clica no botão para finalizar;
3 - Sistema da operadora valida transação (F1, R2);
4 - Sistema gera comprovante de transação.
5 - Caso de uso é encerrado.
Fluxo alternativo:
F1 - Operadora nega transação:
21

• Sistema exibe uma mensagem “Desculpe, operadora não autorizou a
transação, entrar em contato com a mesma”;
• Volta ao passo 1 do fluxo principal.
Regra de negócio:
R1 – Data vencimento do cartão é inválida
• Sistema exibe uma mensagem “Data inválido, tente novamente ou
verifique com a operadora.”
• Volta ao passo 1 do fluxo principal.
R2 – Número do cartão é inválido
• Sistema exibe uma mensagem “Dados do cartão estão inválido, tente
novamente.”
• Volta ao passo 1 do fluxo principal.
4.7. Requisitos Funcionais e não Funcionais
O sistema oferecerá o acesso ao acervo de livro da livraria virtual através de
login e senha, onde possibilitará ao usuário realizar pedido, reserva ou apenas
consultar livros.
4.7.1. Requisitos Funcionais
• Consultar livros;
• Cadastrar usuário;
• Logar no sistema;
• Inserir livro no pedido (carrinho);
• Fazer reserva;
• Fazer pagamento do pedido;
• Inserir dados do cartão
• Validar transação da compra;

4.7.2. Requisitos não funcionais
• Linguagem de desenvolvimento do sistema;
• Tipo de Banco de dados a ser utilizado
• Cadastro de históricodo pedido.

4.7.3. 3. Regra de Negócio Geral
• Não poderá existir usuários iguais no sistema com mesmo e-mail;
• Não poderá existir um pedido vazio no pagamento.

5. DIAGRAMA DE CLASSES E ENTTIDADE RELACIONAMENTO
5.1. Diagrama de Classe
[...] diagrama de classes é um diagrama UML que tem como objetivo
representar a estrutura estática das classes de um sistema de software.
Resumindo, um diagrama de classes é a representação das classes, seus
atributos, métodos e o relacionamento entre essas classes [...] (Versolato,
2015, pg. 118).
No diagrama de classes da livraria virtual, temos a classe principal “Pessoa”,
que vai conter todo o cadastro do cliente, e que associa à classe “Endereço”, essas
duas classes têm a cardinalidade 1:1..N. Mas para isso essas duas classes precisam
de uma classe intermediária para poder se relacionar, que é a classe
“PessoaEndereço”, ou seja, uma pessoa pode possuir um endereço ou mais, caso a
pessoa mude de endereço ou queira que o livro seja entregue em outro local, ao
efetuar a compra o usuário pode editar o endereço ou inserir outro. Então a associação
das três classes fica: “Pessoa” associa à “PessoaEndereco” com cadinalidade 1:1..N
e “PessoaEndereco” associa à “Endereco” com cardinalidade 1:1..N.
Depois que foi feita a consulta e o usuário inserir algum livro no carrinho,
poderá ser feito a finalização do pedido, que é a classe “PedidoLivro”, que está
associada à classe “Pessoa”, onde a cardinalidade é 1 : 0..N, ou seja, uma pessoa
pode ou não fazer um pedido e também pode fazer várias pedidos. A classe
“PedidoLivro” está associada ao “ItemPedido” com cardinalidade 1:1..N, onde todos
os itens do pedido que vão ser armazenados, e que se associa à classe “Livro” com
carnicalidade 1:1..N, que fornece as informações dos livros que o usuário selecionou
na consulta.
A classe “Pagamento” associa à classe “HistoricoPagamento” com
cardinalidade 1:1 e a classe “Pagamento” depende da interface “OperadoraCartao”,
que é um ator do sistema. Todos esses processos são ilustrados na figura 10.

Figura 9 – Diagrama de Classes
Fonte: Desenvolvido pelos alunos
5.2. Modelo Entidade e Relacionamento
É um modelo abstrato desenvolvido pelo Prof. Peter Chen, a fim de
representar as estruturas de dados de forma mais natural e mais próxima do
mundo real dos negócios. Seus aspectos estruturais formalizam
matematicamente a maneira como os dados estão organizados no modelo
relacional (Pinto, 2012, pg 36).
No diagrama modelo entidade e relacionamento (MER), a classe “Pessoa”
associa à classe “Endereço”, é necessário ter uma classe intermediária, a classe
“PessoaEndereco”, é responsável de intermediar as classes “Pessoa” e “Endereco”,
portanto, caso o usuário possua mais de um endereço, então esta classe irá identificá-
los pelas chaves primárias “codigoPessoa” e “codigoEndereco” se tornando uma
chave estrangeira na classe “PessoaEndereco”.
Ao efetuar um pedido pela classe “Pessoa”, a classe “PedidoLivro” armazena
a chave primária “codigoPessoa para identificar qual usuário fez o pedido, assim se
tornando uma chave estrangeira. A classe “ItemPedido”, é responsável por armazenar
os itens, as quantidades e os valores de cada pedidos, para que haja o cálculo total
do pedido na classe “PedidoLivro”, nessa classe é armazenado as chaves primárias
“códigoPedido” e “codigoLivro” para identificar o relacionamento dos itens com seu
respectivo pedido. Quando o usuário faz uma reserva o sistema armazena a chaves
25

primárias “codigoLivro” e “codigoPessoa” que passam a ser a chave estrangeira na
classe “ReservaLivro”.
Logo após o pedido ser feito com sucesso, a classe “Pagamento”, que
depende da interface “OperadoraCartao”, armazenará a chave primária
“códigoPedido”, que passa a ser a chave estrangeira nessa classe e logo após irá
gerar o histórico da mesma. A classe “HistoricoPagamento” irá armazenará toda a
informação referente ao pagamento, ou seja, armazenará o “codigoPagamento”,
“dataPedido” e “valorTotal”.
Com isto, cada classe terá a chave estrangeira para identificar o
relacionamento dos dados gravados, diminuindo assim os riscos de algum dado ficar
sem o relacionamento correto no sistema.
Por fim, a interface “OperadoraCartao”, que é um ator do sistema, irá validar
a transação do pagamento ocorrido. Todos esses processos são ilustrados na figura
10.
Figura 10 – Modelo Entidade e Relacionamento (MER)
Fonte: Desenvolvido pelos alunos
26

5.3. Diagrama de Classes de Análise
Classes de análise usadas para capturar os principais "blocos de
responsabilidade" no sistema. Elas representam as classes prototípicas do sistema e
são um 'primeiro passo' nas principais abstrações que o sistema deve tratar.
A forma de organizar essas classes, também chamadas de classes de analise,
vai ao encontro de um dos princípios fundamentais da orientação a objetos:
divisão de responsabilidades. A divisão de responsabilidades e uma das
características fundamentais em uma boa modelagem de sistemas. Objetos
com responsabilidades bem definidas aumentam a sua capacidade de reuso
(Versolato, 2015, pg 126).
Classes de Análise podem ser enquadradas em três estereótipos: Fronteira
(boundary) ; Controle (control) ; Entidade (entity) ;
Fronteira: Usada para modelar a interação entre o sistema e seus atores.
Cada classe de fronteira deve estar relacionada a pelo menos um ator e vice-versa.
Controle: Representa coordenação, sequência, transações e controle de
objetos. Frequentemente utilizada para encapsular controle relacionado a um caso de
uso específico.
Entidade: Utilizada para modelar informações que tem vida longa no sistema
(persistentes).
Figura 11 – Diagrama de Classes de Análise

Fonte: Desenvolvido pelos alunos
27

CONCLUSÃO
Com o intuito de desenvolver um software para uma livraria, capaz de realizar
a venda de livros para usuários registrados, a atividade inicial a ser realizada é o
levantamento e analise de requisitos, identificando as necessidades ou requisitos do
cliente.
Primeiramente os casos de uso e atores foram identificados, e seus
relacionamentos definidos, de modo a ser formado um cenário que mostrasse as
principais funcionalidades do sistema de acordo com a determinação do cliente,
criando assim uma harmonia entre cliente e desenvolvedor de como será o software
quando finalizado. Os Casos de uso foram especificados para uma melhor
compreensão por parte dos desenvolvedores e protótipos de tela foram criados de
modo a facilitar esse processo. Foram descritos tudo o que e como o sistema irá
realizar, desde cadastrar o usuário no sistema, como efetuar o pagamento, efetuar a
reserva do livro, como fazer o login no sistema. As regras do negócio foram elaboradas
mostrando como o processo da organização é executado. O diagrama de classes foi
elaborado de modo a descrever toda a estrutura do sistema.
Embora não estritamente necessárias para o desenvolvimento do software,
essas atividades iniciais tomadas no projeto não devem ser desconsideradas, pois
são de grande importância pois irão garantir menos dificuldades no decorrer da
atividade do desenvolvimento do software, maior qualidade do produto final e maior
facilidade em futuras alterações, devido a maior disponibilidade de documentação.

REFERÊNCIAS

TORRES, Ani Sobral. Gestão Estratégica de Recursos Humanos. São
Paulo, Editora Sol, 2015.
SOBRENOME, Nome. Banco de Dados. São Paulo, Editora Sol, 2015.
AREZI, Fábio. Casos de uso: diferenças entre include, extend
e generalização, 2010. Disponível em:
<https://arezi.wordpress.com/2010/10/20/casos-de-uso-diferencas-entre-include-
extend-e-generalizacao/>. Acesso em: 21/04/2018.
ADMIN. Quando usar includee/ou extends em casos de uso, 2011.
Disponível em: https://javabeginners.wordpress.com/2011/06/15/quando-usar-
include-eou-extends-em-casos-de-uso/. Acesso em: 21/04/2018
VENTURA, Plínio. Caso de Uso – Include, Extend e Generalização, 2014.
Disponível em: <http://www.ateomomento.com.br/caso-de-uso-include-extend-e-
generalizacao/>. Acesso em: 22/04/2018.
AUGUSTO, José, UML – Diagrama de Caso de Uso E Diagrama de Classe,
2016 Disponível em: <https://augustoprogrammer.wordpress.com/2015/03/10/uml-
diagrama-de-caso-de-uso-e-diagrama-de-classe/>. Acesso em: 24/04/2018.
VENTURA, Plínio. Entendendo definitivamente o que é um Caso de Uso,
2016. Disponível em: <http://www.ateomomento.com.br/o-que-e-caso-de-uso/>.
Acesso em: 23/04/2018.
FUNPAR. Diretrizes: Classe de Análise, Disponível em:
<http://www.funpar.ufpr.br:8080/rup/process/modguide/md_acls2.htm>. Acesso em:
23/05/2018.