6 PROJETO PIMVI

•

UNIP

Cleuton Arruda Fernandes

23/04/2018

E aí, curtiu este material?

Ajude a incentivar outros estudantes a melhorar o conteúdo

Gostou desse material? Compartilhe! 🧡

Projeto Multidisciplinar

270 Materiais compartilhados

Baixe o app para aproveitar ainda mais

Leia os materiais offline, sem usar a internet. Além de vários outros recursos!

Prévia do material em texto

UNIP INTERATIVA
PROJETO INTEGRADO MULTIDISCIPLINAR
CURSO ANÁLISE E DESENVOLVIMENTO DE
SISTEMA

PROJETO INTEGRADO MULTIDISCIPLINAR
PIM VI

DESENVOLVIMENTO DE UM SISTEMA PARA
LOJA DE AUTOPEÇAS

UNIP INTERATIVA – POLO COARI
2015

UNIP INTERATIVA
PROJETO INTEGRADO MULTIDISCIPLINAR
CURSO ANÁLISE E DESENVOLVIMENTO DE
SISTEMA

DESENVOLVIMENTO DE UM SISTEMA PARA
LOJA DE AUTOPEÇAS

Nome: Ericlis Erikson Caetano Coelho RA: 1413662
Erifran Elias Pereira RA: 1406152
Gilder Gonçalves de Vasque RA:1404505
Idelbrando Davila Pereira RA: 1406382
Leandro da Silva Monteiro RA: 1420275
Myrla Cordeiro de Oliveira RA: 1434239
Neila de Assunção Vilena RA: 1407686

UNIP INTERATIVA – POLO COARI
2015

RESUMO
O objetivo deste projeto é a modelagem e desenvolvimento de um sistema para uma
loja de autopeças, localizada no Rio de Janeiro. De acordo com o levantamento das
necessidades proposta pelo gerente da loja para criar um sistema para organizar seu
estabelecimento.
O software escolhido de modelagem UML dentre vários software livres existentes,
escolhemos Astah para perpetrarmos os diagramas de caso de uso e outras funções
necessárias para este trabalho, pois ele possui ferramentas básicas e importantes para
elaboração deste projeto.
Atreves deste programa podemos criar os casos de uso, elaborar o modelo de casos
de uso, fazer relacionamentos de include, generalização, descrição dos casos de uso e
seu comportamento, os fluxos principais, descrever os requisitos não funcionais e os
requisitos de usabilidade, diagrama de classes. Além desses requisitos do Astah o
cliente solicitou outros requisitos com alternativos de exceção pré e pós-condições
identificação e descrição do contexto de uso de análise e protótipo das telas principais,
com a intenção de demonstrar a capacidade de atender as demandas, utilizando as
teorias necessárias.
Este projeto o qual foi desenvolvido de acordo com as exigências do cliente, dando-
lhe um programa com uma interface dinâmica, de fácil entendimento e clareza para os
usuários, desta forma o projeto realizado permitira a organização e gerenciar da loja de
autopeças.

.
Palavra chave: Caso de uso, Modelagem, Análise, atributos e classes.

ABSTRACT

The objective of this project is the modeling and development of a system for an auto
parts store, located in Rio de Janeiro. According to the needs assessment proposed by
the store manager to create a system for organizing your establishment.
The chosen UML modeling software of several existing free software, we chose to
Astah perpetrarmos the use case diagrams and other functions necessary for this work,
because it has basic and important tools for the development of this project.
We dare this program we can create use cases, draw up the model use cases, to include
relationships, generalization, description of use cases and their behavior, the main
flows, describe non-functional requirements and usability requirements, diagram
classes. In addition to these requirements Astah the client requested other requirements
with the exception of alternative pre and post-conditions Identification and description
of the context of use analysis and prototype of the main screens, with the intention to
demonstrate the ability to meet the demands, using the theories necessary.
This project which was developed according to customer requirements, giving you a
program with a dynamic interface, easy to understand and clear to users, so the project
undertaken allowed the organization and manage the auto parts store.

Keyword: Use case, Modeling, Analysis, attributes and classes

SUMÁRIO
1. INTRODUÇÃO........................................................................................ 06
2. DESENVOLVIMENTO............................................................................ 07
2.1 CASOS DE USO....................................................................................... 07
2.2 DIAGRAMA DE CASO DE USO............................................................ 08
2.3 DESCRIÇÃO DOS ATORE..................................................................... 09
3. LOGIN DE USUÁRIO.............................................................................. 10
3.1 CADASTRO DE CLIENTE...................................................................... 11
3.2 CADASTRO DE FORNECEDOR............................................................ 12
3.3 CADASTRO DE PRODUTOS................................................................. 13
3.4 REGISTRAR COMPRA.......................................................................... 14
3.5 REGISTRAR VENDA............................................................................. 15
3.6 CADASTRAR FUNCIONARIO............................................................. 16
4. REQUISITOS............................................................................................ 17
4.1 REGRA DE NEGÓCIO........................................................................... 18
4.2 DIAGRAMA DE CLASSE DE ANÁLISE.............................................. 19
5. PROTÓTIPOS DAS TELAS PRINCIPAIS.............................................. 20
6. CONCLUSÃO........................................................................................... 26
REFERÊNCIAS........................................................................................ 27

1. INTODUÇÃO
Os casos de uso descrevem como os usuários interagem com o sistema as
funcionalidades do sistema dão uma visão externa do sistema o conjunto de casos de
uso deve ser capaz de comunicar a funcionalidade e o comportamento do sistema para o
Cliente e descrevem o que o sistema faz, mas não especificam como isso deve ser feito
a modelagem da análise usa uma combinação de formas textuais e diagramáticas para
mostrar os requisitos de dados, função e comportamento, de modo que seja
relativamente fácil de entender e, mais importante, mais direto de revisar o modelo.
A análise de requisitos resulta na especificação das características operacionais
do software, indica a interface do mesmo com outros elementos do sistema e estabelece
restrições a que o software deve satisfazer. Ou seja, a análise de sistemas é importante,
pois, representa os requisitos em várias “dimensões”, aumentando consequentemente a
probabilidade de acertos, pois força que sejam encontrados erros, apareçam
inconsistências e que omissões sejam descobertas.
Os requisitos de informações, funcionais e comportamentais são modelados
usando vários formatos diagramáticos diferentes. Dentre as diferentes modelagens da
análise de sistema, seguem algumas com suas especificações básicas. A modelagem
baseada em cenário representa o sistema sob o ponto de vista do usuário; A modelagem
orientada a fluxo fornece indicação de como os objetos de dados são transformados
pelas funções de processamento; A modelagem baseada em classes define objetos,
atributos e relacionamentos.
A modelagem comportamental mostra os estados do sistema e de
suas classes, e o impacto que os eventos têm nesses estados. Uma vez criados
os modelos preliminares, eles são refinados e analisados para avaliar sua
clareza, completeza e consistência. Ou seja, os produtos do trabalho da
modelagem da análise precisam refletir as necessidades de todos os
interessados e estabelecer um fundamento com base no qual o projetopossa
ser conduzido, logo o modelo final de análise é então validado por todos os
interessados. (SOMMERVILLE, 2003).

2. DENSENVOLVIMENTO
Este projeto tem como base os conhecimentos adquiridos nas disciplinas de
Orientada a Objetos, Projeto de Interface com o Usuário, Gestão Estratégica de
Recursos Humanos. Nessa fase foi de extrema importância o uso da UML (Unified
7

Modeling Language), para mostrar de maneira clara e consistente como será
implementado o sistema, através de seus principais diagramas.

2.1 CASOS DE USO
Os casos de uso podem ser aplicados a todo o sistema, incluindo interfaces e classes
individuais. Para identificar esses casos, são levantadas questões como: quem serão as
pessoas que implementarão o sistema, patrocinadoras, suas funções, a capacidade de
cada uma, quem seria responsável por determinada operação, as regras estabelecidas
para cada um, se o software precisa se comunicar com sistemas externos, fazer
validações em outros sites ou programas, e outras questões também importantes para
determinação desses casos.
Os casos de uso podem ser representados por documentos de texto, e os mesmos
podem exemplificar o desenvolvimento que será feito no sistema, os subsistemas e as
classes que serão criadas, ajudando assim os analistas no desenvolvimento do projeto e,
posteriormente, os desenvolvedores que precisam de toda essa documentação para
moldar o sistema de acordo com as necessidades dos usuários. É importante ter toda
essa documentação para evitar erros e deixar um escopo bem definido com o cliente os
casos de uso são usados para definir o que deve ser realizado pelo Sistema e o que
existe fora dele, sendo assim cada caso de uso está ligado a um requisito funcional.
Identificando os casos de usos:
 Efetuar Login
 Cadastra Cliente
 Manutenção de Cliente
 Cadastra Fornecedor
 Manutenção de Fornecedor
 Cadastra Produtor
 Manutenção de Produto
 Registra Compra
 Devolver Peça
 Atualizar Estoque
 Registra venda
 Conceder desconto
8

 Manutenção de Funcionário

2.2 DIAGRAMA DE CASO DE USO
O diagrama de casos de uso mostra as interações entre os atores e o sistema
em seu cenário específico.

Figura1: Diagrama de Caso de Uso
Conforme o diagrama de casos de uso do sistema de autopeça, a iteração com o
sistema será feita por funcionários, vendedores e gerente, e não haverá integração com
outro sistema. Os casos de uso podem ter relacionamentos de inclusão (quando um caso
de uso inclui obrigatoriamente outro) e extensão (quando um caso de uso opcionalmente
inclui outro). De acordo com o sistema de autopeça o caso de uso devolver peça
obrigatoriamente inclui o atualizar estoque, ou seja, se devolver uma determinada peça
irá atualizar o estoque da mesma, e o caso de uso registrar venda opcionalmente incluirá
o caso de uso conceder desconto, pois no momento da venda o cliente pode ou não ter
desconto da peça.
9

Pode-se verificar com o diagrama de casos de uso qual a utilidade e o contexto
do sistema, os processos da empresa que serão influenciados e as pessoas que estarão
envolvidas em seus determinados processos, ou, as responsabilidades de cada ator.

2.3 DESCRIÇÃO DOS ATORE
Funcionário - responsável por algumas manutenções do sistema. Ele pode
realizar a manutenção de clientes e fornecedores, como cadastro e consulta de clientes,
cadastro e consulta de fornecedores, e manutenção de produtos.
Vendedor - pessoa responsável pela devolução de peças (e consequentemente a
atualização do estoque), e registro de vendas (à vista, à prazo ou com desconto).
Gerente - responsável pelos requisitos dos atores funcionário e vendedor,
podendo realizar a manutenção de clientes, fornecedores e produtos, registrar venda e
devolver peça. Alguns casos de uso só o gerente tem permissão para realizar, como por
exemplo, o cadastro de utilização de peça e a manutenção de funcionários. Logo o
gerente tem permissão para realizar todos os casos de uso.
Os elementos chave de um diagrama de casos de uso são: Ator: agentes externos
que interagem com o sistema, podem ser pessoas ou hardware. Os atores estão ligados
diretamente com o seu respectivo caso de uso, cada um com suas funcionalidades.
Sendo que um ator também pode ter os mesmos casos de uso de outro ator e mais as
suas funcionalidades. No caso da autopeça, os autores serão os funcionários da loja,
aquelas pessoas que ficam internas na empresa administrando o negócio, os vendedores,
que ficam no balcão ou na rua, e o próprio gerente da loja. Caso de uso: descreve o
relacionamento do sistema e do ator, e as operações entre os mesmos. Descreve cada
funcionalidade do sistema, os requisitos funcionais que serão implementados.
Interações: comunicação do sistema com os seus respectivos atores, ou seja,
qual ator tem ligação com o determinado caso de uso. Na autopeça, por exemplo, um
funcionário da empresa irá interagir com a manutenção de produtos, clientes, dentre
outros.
Sistema: conjunto de casos de uso dentro da fronteira, com seus objetivos
específicos. Todos os requisitos funcionais avaliados pelos analistas que serão
desenvolvidos.
Os casos de uso que na fase de concepção do projeto foram descritos, agora
devem ser detalhados em uma sequência de passos. A descrição em alto nível explica o
10

objetivo e funcionamento do caso. Primeiro deve-se identificar o fluxo principal e as
sequência alternativas associadas às suas possíveis exceções. Todos os requisitos devem
ser bem documentados para que se tenha um bom projeto.

3. LOGIN DE USUÁRIO

A documentação do caso de uso “Login de Usuário”, conforme o Quadro 1
descreve o fluxo de funções que o ator deve aplicar para efetuar login no sistema. O
caso de uso verifica se o usuário e senha estão corretos, se a senha estiver errada volta
para a tela de login.
Nome Login de usuário
Sumário Caso de Uso que descreve os passos para o usuário do sistema efetuar
login.
Ator primário: Funcionário
Ator (es) secundário(s): -
Pré-condição: -
Pós-condição: O funcionário é logado.
Fluxo Principal
1. O funcionário inicia o sistema;
2. O sistema solicita como campos (nome do usuário, e senha);
3. O funcionário informa os dados e efetua o login;
4. O sistema verifica se o nome do usuário e a senha estão corretos e o sistema é
logado.
Fluxo de Exceção: Usuário ou senha inválidos.
4.1. O sistema emite uma mensagem informando que o usuário ou senha estão
inválidos
4.2. O sistema retorna ao passo 2.

Regras de Negócio Associadas
Quadro 1: Caso de Uso

3.1 CADASTRO DE CLIENTE
A documentação do caso de uso “Cadastro de cliente”, conforme o
Quadro 2, descreve o fluxo para o cadastro de clientes no sistema e identifica se um
cliente já está cadastrado ou não.
Nome Cadastro de Cliente
Sumário Caso de Uso que descreve os passos para o cadastro de cliente.
Ator primário: Funcionário
Ator (es) secundário(s): -
Pré-condição: O funcionário deve estar logado no sistema.
Pós-condição: O cliente é cadastrado.
Fluxo Principal
1. O funcionário solicita ao sistema o cadastro do cliente;
2. O sistema solicita como campos (CPF, nome do cliente, telefone, sexo, endereço,
número do endereço, complemento, bairro, CEP, estado e cidade do cliente);
3. O funcionário informa os dados e confirma o cadastro do cliente;
4. O sistema valida o CPF e retorna uma mensagem informando que o cliente foi
cadastrado com sucesso e encerra o caso de uso.
Fluxo Alternativo[1]: Busca de cliente.
1.1. O funcionário clica no botãobuscar para localizar o cliente;
1.2. O sistema solicita o CPF/CNPJ do cliente;
1.3. O funcionário insere o CPF/CNPJ;
1.4. O sistema exibe os dados do cliente na tela e retorna ao passo 2.
Fluxo de Exceção: Violação da Regra de Negócio
4.1. O sistema emite uma mensagem informando que o cliente já está cadastrado;
4.2. O sistema retorna ao passo 2.
Fluxo de Exceção: Cliente com CPF inválido.
4.1. O sistema emite uma mensagem informando que oCPF/CNPJ do cliente é
inválido;
4.2. O sistema retorna ao passo 2.
Regras de Negócio Associadas
Quadro 2: Caso de Uso
12

3.2 CADASTRO DE FORNECEDOR
A documentação do caso de uso “Cadastro de fornecedor”, conforme o Quadro
3, descreve o fluxo para o cadastro de fornecedores no sistema e identifica se já está
cadastrado ou não.
Nome Cadastro de Fornecedor
Sumário Caso de Uso que descreve os passos para o cadastro de fornecedor.
Ator primário: Funcionário
Ator (es) secundário(s): -
Pré-condição: O funcionário deve estar logado no sistema.
Pós-condição: O fornecedor é cadastrado.
Fluxo Principal
1. O funcionário solicita ao sistema o cadastro do fornecedor;
2. O sistema solicita como campos (CPF/CNPJ), nome do fornecedor, telefone, sexo,
endereço, número do endereço, complemento, bairro, CEP, estado e cidade do
fornecedor);
3. O funcionário informa os dados e confirma o cadastro do fornecedor;
4. O sistema valida o CPF/CNPJ e retorna uma mensagem informando que o
fornecedor foi cadastrado com sucesso e encerra o caso de uso.
Fluxo Alternativo[1]: Busca de cliente.
1.1. O funcionário clica no botão buscar para localizar o fornecedor;
1.2. O sistema solicita o CPF/CNPJ do fornecedor;
1.3. O funcionário insere o CPF/CNPJ;
1.4. O sistema exibe os dados do fornecedor na tela e retorna ao passo 2.
Fluxo de Exceção: Fornecedor já possui cadastro.
4.1. O sistema emite uma mensagem informando que o fornecedor já está cadastrado;
4.2. O sistema retorna ao passo 2.
Fluxo de Exceção: Violação da Regra de Negócio.
4.1. O sistema emite uma mensagem informando que o CPF/CNPJ do fornecedor
é inválido;
4.2. O sistema retorna ao passo 2.
Regras de Negócio Associadas
Quadro 3: Caso de Uso
13

3.3 CADASTRO DE PRODUTOS
A documentação do caso de uso “Cadastro de produtos”, conforme o Quadro 4,
descreve o fluxo para o cadastro de produtos no sistema e identifica os produtos
cadastrados.
Nome Cadastro de Produtos
Sumário Caso de Uso que descreve os passos para o cadastro de Produto.
Ator primário: Funcionário
Ator (es) secundário(s): -
Pré-condição: O funcionário deve estar logado no sistema.
Pós-condição: O Produto é cadastrado.
Fluxo Principal
1. O funcionário solicita ao sistema o cadastro do produto;
2. O sistema solicita como campos (código, nome do produto, grupo de produto,
preço de custo, preço de venda e utilização da peça);
3. O funcionário informa os dados e confirma o cadastro do produto;
4. O sistema retorna uma mensagem informando que o produto foi cadastrado com
sucesso e encerra o caso de uso.
Fluxo Alternativo[1]: Busca de Produto.
1.1. O funcionário clica no botão buscar para localizar o produto;
1.2. O sistema solicita o código/nome do produto;
1.3. O funcionário insere o código/nome do produto;
1.4. O sistema exibe os dados do produto na tela e retorna ao passo 2.
Fluxo de Exceção: Produto já possui cadastro.
4.1. O sistema emite uma mensagem informando que o produto já está cadastrado;
4.2. O sistema retorna ao passo 2.
Regras de Negócio Associadas
Quadro 4: Caso de Uso

3.4 REGISTRAR COMPRA
No Quadro 05 estão descritas as funções para o ator “Registrar Compra”. Nesse
caso de uso, o funcionário informa os dados necessários para o registro, o sistema
adiciona os dados e atualiza o estoque da peça comprada.
Nome Registrar compra
Sumário Caso de Uso que descreve os passos para o funcionário registrar uma
compra feita.
Ator primário: Funcionário
Ator (es) secundário(s): -
Pré-condição: O funcionário deve estar logado no sistema.
Pós-condição: O funcionário registra a compra.
Fluxo Principal
1. O funcionário seleciona a opção desejada;
2. O sistema solicita como campos (código do produto, quantidade, preço de compra,
preço de venda, data da compra;
3. O funcionário informa os dados e registra a compra.
4. O sistema adiciona os dados no banco e atualiza o estoque da peça comprada.
Fluxo de Exceção: Violação da Regra de Negócio
2.1. O sistema emite uma mensagem informando que o preço de venda está menor
que o preço de compra.
2.2. O sistema retorna ao passo 2, solicitando os campos novamente.
Regras de Negócio Associadas
Quadro 5: Caso de Uso

3.5 REGISTRAR VENDA
No Quadro 06 estão descritas as funções para o ator “Registrar Venda”. Nesse
caso de uso, o funcionário informa os dados necessários para o registro, o sistema
adiciona os dados e atualiza o estoque da peça vendida.
Nome Registrar Venda
Sumário Caso de Uso que descreve os passos para o funcionário registrar uma
Venda feita.
Ator primário: Vendedor
Ator (es) secundário(s): -
Pré-condição: O Vendedor deve estar logado no sistema.
Pós-condição: O Vendedor registra a Venda.
Fluxo Principal
1. O funcionário seleciona a opção desejada;
2. O sistema solicita como campos (nome do cliente, nome ou código da peça e a
quantidade);
3. O funcionário informa os dados e registra a venda.
4. O sistema registra a venda e encerra o caso de uso.
Fluxo de Exceção: Nome do cliente inválido
2.1. O sistema emite uma mensagem informando que o nome do cliente é inválido.
2.2. O sistema retorna ao passo 2.
Regras de Negócio Associadas
Quadro 6: Caso de Uso

3.6 CADASTRAR FUNCIONÁRIO
A documentação do caso de uso “Cadastro de funcionário”, conforme o Quadro
07, descreve o fluxo para o cadastro de funcionários no sistema e identifica se os
mesmos já está cadastrado ou não.
Nome Cadastro de Funcionário
Sumário Caso de Uso que descreve os passos para o cadastro de Funcionário.
Ator primário: Gerente
Ator (es) secundário(s): -
Pré-condição: O Gerente deve estar logado no sistema.
Pós-condição: O Funcionário é cadastrado.
Fluxo Principal
1. O gerente solicita ao sistema o cadastro do funcionário;
2. O sistema solicita como campos (CPF, nome do funcionário, telefone, sexo,
endereço, número do endereço, complemento, bairro, CEP, estado e cidade do
funcionário);
3. O gerente informa os dados e confirma o cadastro do funcionário;
4. O sistema valida o CPF e retorna uma mensagem informando que o funcionário
foi cadastrado com sucesso e encerra o caso de uso.
Fluxo Alternativo[1]: Busca de funcionário.
1.1. O gerente clica no botão buscar para localizar o funcionário;
1.2. O sistema solicita o CPF do funcionário;
1.3. O gerente insere o CPF;
1.4. O sistema exibe os dados do funcionário na tela e retorna ao passo 2.
Fluxo de Exceção: Funcionário já possui cadastro.
4.1. O sistema emite uma mensagem informando que o funcionário já está
cadastrado;
4.2. O sistema retorna ao passo 2.
Fluxo de Exceção: Violação da Regra de Negócio
4.1. O sistema emite uma mensagem informando que o CPF do funcionário é
inválido;
4.2. O sistema retorna ao passo 2.
Regras de Negócio Associadas
Quadro 7: Caso de Uso

4. REQUISITOS
A análise de requisitos é fundamental para o desenvolvimento de sistemas, pois
exemplifica as operações que o sistema deve fazer e também assuas restrições. Os
requisitos podem ser funcionais ou não funcionais.
O sistema de autopeça a ser desenvolvido apresenta os requisitos funcionais e
não funcionais. Esses requisitos que descrevem o comportamento do sistema e se
relacionam ao desempenho do mesmo, para estabelecer esses requisitos, temos que
colocar todas as reais necessidades do cliente, para serem avaliadas pelos
desenvolvedores e as conformidades e não conformidades serão passadas para o cliente,
até chegar a um consenso comum. O processo de autopeças em questão é simples, ela
trabalha com os determinados cadastros, registros de compra e venda de peças
automotivas, os requisitos citados abaixo atendem as necessidades e permitirão o
entendimento dos usuários do sistema.

REQUISITOS FUNCIONAIS
• O sistema deve permitir a manutenção de clientes.
• O sistema deve permitir a manutenção de fornecedores.
• O sistema deve permitir a manutenção de produtos.
• O sistema deve permitir a manutenção de funcionários.
• O sistema deve permitir o login.
• O sistema deve permitir o registro de compra.
• O sistema deve permitir a atualização de estoque.
• O sistema deve permitir a concessão de desconto.
• O sistema deve permitir registro de vendas.
• O sistema deve permitir a devolução de peças.
REQUISITOS NÃO FUNCIONAIS
• Usabilidade: os funcionários inexperientes devem ser capazes de
utilizar todas as funcionalidades do sistema após treinamento.
• O sistema deve ser confiável.
• Desempenho: o sistema deve ter um bom desempenho, ser eficiente e
exato.
Quadro 8: Caso de Uso
18

4.1 REGRA DE NEGÓCIO
As regras de negócio determinam o comportamento do sistema e são usadas para
alcançar os objetivos de uma empresa. Podem ser as operações, definições, validações,
restrições ou condições da empresa, podem abranger diversos assuntos seguindo a
definição do negócio.
Para especificar as particularidades do sistema a ser desenvolvido para a
autopeça, o cliente determina as regras descritas nas tabelas abaixo. A definição das
mesmas ajuda os desenvolvedores na hora da programação dos métodos do sistema, por
isso é importante que essas regras sejam definidas logo no início do projeto, ou seja, o
método a ser implementado pelo desenvolvedor deve seguir as restrições das regras de
negócio definidas, todas elas devem ser tratadas dentro do sistema, caso contrário cada
uma pode ter um impacto negativo em outra parte do programa futuramente, e tratar um
código que já está programado é mais difícil do que prever antes e já desenvolver.
Nome Descontos
Descrição O vendedor pode conceder descontos de até 20% para
clientes que efetuam compras acima de R$500,00.

Nome Validação de CPF e CNPJ
Descrição Para cadastrar um cliente ou fornecedor deverá ser verificado se o
CPF/CNPJ são válidos.

Nome Preço de venda menor que preço de compra
Descrição Ao cadastrar uma compra, o preço de venda não pode ser menor
que o preço de compra mesmo com os descontos.

4.2 DIAGRAMA DE CLASSE DE ANÁLISE
O diagrama de classes é considerado por vários autores como o mais importante
e utilizado diagrama da UML. Ele apresenta uma visão estática da organização das
classes do sistema, permitindo além da visualização das classes e de seus atributos e
métodos, a representação de seus relacionamentos, como estas se complementam e a
transmissão da informação dentro do sistema (SILVA, 2007)
19

Seguindo o levantamento das necessidades e requisitos para implementação foi desenvolvido o diagrama de classes do sistema autopeça que é
apresentado na Figura abaixo, com suas respectivas classes e relacionamentos.

As classes levantadas no projeto do sistema de autopeça e que fazem parte do
diagrama, seguem abaixo com suas respectivas funcionalidades:
Fornecedor: responsável pela manutenção de fornecedores, cadastro e consulta,
e pelas relações dessa classe com as outras.
Funcionário: responsável pelo cadastro de novos funcionários e pelas
associações do mesmo.
Cliente: mantém o cadastro e consulta de clientes.
Produto: responsável pela manutenção de produtos, associações e
relacionamentos do mesmo.
Item: mantém as funções relacionadas as associações do item.
Compra: responsável pelo registro de compras e as suas associações.
Venda: responsável pelo registro de venda e suas associações.
Operação: responsável pelo registro de uma operação, verificação do tipo de
operação, e mantém as suas associações e os seus relacionamentos.

5. PROTÓTIPOS DAS TELAS PRINCIPAIS
A prototipação é um processo que tem como objetivo facilitar o entendimento
dos requisitos, apresentar conceitos e funcionalidades do software. Desta forma,
podemos propor uma solução adequada para o problema do cliente, aumentando sua
percepção de valor. Os protótipos também são grandes aliados das metodologias ágeis
de desenvolvimento, uma vez que garantem maior alinhamento entre a equipe e o
cliente. Eles podem ser desenvolvidos em diferentes níveis de fidelidade: quanto maior
ela for, mais o protótipo se assemelhará ao resultado entregue. No entanto, um protótipo
de alta fidelidade leva mais tempo para ser criado ou modificado. A escolha do
protótipo ideal varia de acordo com o nível de entendimento do negócio, a
complexidade dos requisitos, prazo e orçamento para elaboração. São protótipos
completos e representativos. Além da parte visual, englobam uma série de detalhes de
estética e efeitos de interação, proporcionando uma experiência rica e realista. Também
ajudam a equipe a identificar novos requisitos, oportunidades e futuros problemas. As
consequências disso para o software são lucros maiores a longo prazo e riscos menores
durante o desenvolvimento. Em contrapartida, protótipos interativos demandam uma
equipe de maior conhecimento técnico e demoram mais tempo para serem criados.
21

Tela principal
A tela principal o usuário poderá logar no sistema para usufruir das tarefas
disponíveis para seu per fil.
O sistema solicita como campos (nome do usuário, e senha), o funcionário
informa os dados e efetua o login, o sistema verifica se o nome do usuário e a senha
estão corretos e o sistema é logado.

Figura2: Tela principal
No menu cliente o funcionário poderá pesquisar cliente ou cadastrar cliente e
assim nos demais menus.

Figura3: Tela principal

Tela de Cadastro de Cliente
O funcionário solicita ao sistema o cadastro do cliente, o sistema solicita como
campos (CPF, nome do cliente, telefone, sexo, endereço, número do endereço,
complemento, bairro, CEP, estado e cidade do cliente), o funcionário informa os dados,
e salva o cadastro do cliente, o sistema valida o CPF e retorna uma mensagem
informando que o cliente foi cadastrado com sucesso.

Figura 4: Tela principal

Tela de Cadastro de Fornecedor
. O funcionário solicita ao sistema o cadastro do fornecedor, o sistema solicita
como campos (CPF/CNPJ), nome do fornecedor, telefone, sexo, endereço, número do
endereço, complemento, bairro, CEP, estado e cidade do fornecedor), o funcionário
informa os dados e salva o cadastro do fornecedor, o sistema valida o CPF/CNPJ e
retorna uma mensagem informando que o fornecedor foi cadastrado com sucesso.

Figura 5: Tela principal

Tela de Cadastro de Produtos
O funcionário solicita ao sistema o cadastro do produto, o sistema solicita como
campos (código, nome do produto, grupo de produto, preço de custo,preço de venda e
utilização da peça), o funcionário informa os dados e salva o cadastro do produto, o
sistema retorna uma mensagem informando que o produto foi cadastrado com sucesso.

Figura 6: Tela principal

Tela de Cadastro de Funcionário
O gerente solicita ao sistema o cadastro do funcionário, o sistema solicita como
campos (CPF, nome do funcionário, telefone, sexo, endereço, número do endereço,
complemento, bairro, CEP, estado e cidade do funcionário), o gerente informa os dados
e salva o cadastro do funcionário, o sistema valida o CPF e retorna uma mensagem
informando que o funcionário foi cadastrado com sucesso.

Figura2: Tela principal

CONCLUSÃO
O desenvolvimento desse projeto foi importante para compreendermos o quanto
cada assunto abordado nas disciplinas de Análise de Sistemas Orientada a Objetos,
Projeto de Interface com o Usuário, Gestão Estratégica de Recursos Humanos, é
necessário para o desenvolvimento de um sistema.
O sistema implementado também comprova que é possível desenvolvermos um
sistema para uma autopeça seja ela de grande ou pequeno porte. E não importa o
tamanho do projeto, os requisitos devem ser seguido a risca. As ferramentas UML
vieram de encontro com nossos objetivos fazendo com que o sistema de autopeça fosse
bem diagramado de forma concisa e objetiva através de seus vários diagramas e análises
criteriosas. Com a linguagem UML, podemos mostrar os diferentes aspectos de um
sistema, sejam eles funcionais informacionais ou comportamentais. Além disso, a
linguagem ainda auxilia na criação de diversos diagramas. Com as ferramentas de
criação dos documentos de análise, tivemos um grande apoio na obtenção, gestão,
modelagem dos requisitos do sistema.
Por tanto o análise de um projeto depende muito de uma adequada construção
dos casos de uso com seus atributos, classes, relacionamentos e diagramas para ter
clareza e compreensão de um sistema. A qualidade do produto final depende muito de
das ferramentas acima citadas, pois, este projeto o qual foi desenvolvido de acordo com
as exigências do cliente, dando-lhe um programa com uma interface dinâmica, de fácil
entendimento e clareza para os usuários, desta forma o projeto realizado permitira a
organização e gerenciar da loja de autopeças.

REFERÊNCIAS
Livro de Análise de Sistemas Orientada a Objetos
Livro de Projeto de Interface com o Usuário
Livro de Gestão Estratégica de Recursos Humanos
http://epf.eclipse.org/wikis/openuppt/openup_basic/guidances/guidelines/find_and_outli
ne_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html Acessado em 12/05/2015
http://imasters.com.br/artigo/2753/uml/modelando-sistemas-em-uml-casos-de-
uso/Acessado em 12/05/2015
http://www.devmedia.com.br/desenvolvimento-de-software-dirigido-por-caso-de-
uso/9148 Acessado em 12/05/2015
http://pt.slideshare.net/ranieritrecha/ps1-t-aula4casosuso acessado em 13/05/2015
http://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso Acessado em 13/05/2015
http://www.dextra.com.br/prototipacao-e-sua-importancia-no-desenvolvimento-de-
software/ Acessado em 15/05/2015