Documento de

Especificação de
Projeto

Projeto de Software
Disciplina Análise e Projeto Orientado à Objetos – Terceiro Semestre
Bacharelado em Ciência da Computação
Professor Lucio
UTFPR – Universidade Tecnológica Federal do Paraná – Campus Campo Mourão

Projeto: Sistema de Controle de estoque de

cosméticos
Equipe:
Walancy Ferreira walancysantos@alunos.utfpr.edu.br

Milena Churata milenachurata@alunos.utfpr.edu.br

HISTÓRICO DE REVISÕES

Nome da alteração Responsável Data

 Orientação para uso do template:
Instruções de preenchimento estão espalhadas pelas várias
seções deste template, em cor azul e envoltas por tags (“<” e “>”).
Após ler uma instrução de preenchimento e entender que
informação deve ser fornecida, delete a instrução de
preenchimento e substitua-a por texto de sua própria autoria,
relacionado à seção. A cor vermelha é utilizado como comentário
e deverá ser apagada do documento.
Ao fim da elaboração do documento, atualize seu índice clicando
com o botão direito do mouse no mesmo e depois em Atualizar
Campo (Update Field).

Este documento foi estendido da proposta de documentação de

especificação funcional elaborada pelo Centro de Inovação de Recife /
Qualiti Software Processes / Centro de Estudos e Sistemas Avançados do
Recife (C.E.S.A.R) de 2007.

Índice
1. INTRODUÇÃO
..... 5
1.1 DESCRIÇÃO DO SISTEMA
..... 5
1.2 OBJETIVO DO SISTEMA
..... 5
1.3 CONVENÇÕES, TERMOS E ABREVIAÇÕES
..... 5
1.3.1 Identificação dos casos de uso .................................................................................. 5
1.3.2 Prioridades dos casos de uso ..................................................................................... 5
2. LISTA DE REQUISITOS
..... 6
3. ATORES
..... 6
4. CASOS DE USO
..... 6
Diagrama de Caso de Uso - < HYPERLINK "#__RefHeading__27_117254275"
HYPERLINK "#__RefHeading__27_117254275" HYPERLINK
"#__RefHeading__27_117254275"< HYPERLINK "#__RefHeading__27_117254275"
HYPERLINK "#__RefHeading__27_117254275" HYPERLINK
"#__RefHeading__27_117254275"nome do projeto HYPERLINK
"#__RefHeading__27_117254275" HYPERLINK "#__RefHeading__27_117254275"
HYPERLINK "#__RefHeading__27_117254275"> HYPERLINK
"#__RefHeading__27_117254275" HYPERLINK "#__RefHeading__27_117254275"
HYPERLINK "#__RefHeading__27_117254275"> ............................................................... 7
[UC01] HYPERLINK "#__RefHeading__29_117254275" HYPERLINK
"#__RefHeading__29_117254275" HYPERLINK "#__RefHeading__29_117254275"<
HYPERLINK "#__RefHeading__29_117254275" HYPERLINK
"#__RefHeading__29_117254275" HYPERLINK "#__RefHeading__29_117254275"Incluir
ao lado do identificador um nome para o caso de uso HYPERLINK
"#__RefHeading__29_117254275" HYPERLINK "#__RefHeading__29_117254275"
HYPERLINK "#__RefHeading__29_117254275"> ............................................................... 7
4.1 ANÁLISE TEXTUAL.
..... 8
5. PACOTES
..... 8
Diagrama de Pacote - HYPERLINK "#__RefHeading__35_117254275" HYPERLINK
"#__RefHeading__35_117254275" HYPERLINK "#__RefHeading__35_117254275"<
HYPERLINK "#__RefHeading__35_117254275" HYPERLINK
"#__RefHeading__35_117254275" HYPERLINK "#__RefHeading__35_117254275"<
HYPERLINK "#__RefHeading__35_117254275" HYPERLINK
"#__RefHeading__35_117254275" HYPERLINK "#__RefHeading__35_117254275"nome
do projeto HYPERLINK "#__RefHeading__35_117254275" HYPERLINK
"#__RefHeading__35_117254275" HYPERLINK "#__RefHeading__35_117254275">
HYPERLINK "#__RefHeading__35_117254275" HYPERLINK
"#__RefHeading__35_117254275" HYPERLINK "#__RefHeading__35_117254275"> ...... 8
< HYPERLINK "#__RefHeading__37_117254275" HYPERLINK
"#__RefHeading__37_117254275" HYPERLINK "#__RefHeading__37_117254275"Nome
do Pacote 1 HYPERLINK "#__RefHeading__37_117254275" HYPERLINK
"#__RefHeading__37_117254275" HYPERLINK "#__RefHeading__37_117254275"> ...... 9
6. CLASSES
..... 9
Diagrama de Classes - HYPERLINK "#__RefHeading__41_117254275" HYPERLINK
"#__RefHeading__41_117254275" HYPERLINK "#__RefHeading__41_117254275"<
HYPERLINK "#__RefHeading__41_117254275" HYPERLINK
"#__RefHeading__41_117254275" HYPERLINK "#__RefHeading__41_117254275"<
 HYPERLINK "#__RefHeading__41_117254275" HYPERLINK
"#__RefHeading__41_117254275" HYPERLINK "#__RefHeading__41_117254275"nome
do projeto HYPERLINK "#__RefHeading__41_117254275" HYPERLINK
"#__RefHeading__41_117254275" HYPERLINK "#__RefHeading__41_117254275">
HYPERLINK "#__RefHeading__41_117254275" HYPERLINK
"#__RefHeading__41_117254275" HYPERLINK "#__RefHeading__41_117254275"> ...... 9
7. SEQUÊNCIA
..... 9
Diagrama de Sequência - HYPERLINK "#__RefHeading__45_117254275" HYPERLINK
"#__RefHeading__45_117254275" HYPERLINK "#__RefHeading__45_117254275"<
HYPERLINK "#__RefHeading__45_117254275" HYPERLINK
"#__RefHeading__45_117254275" HYPERLINK "#__RefHeading__45_117254275"<
HYPERLINK "#__RefHeading__45_117254275" HYPERLINK
"#__RefHeading__45_117254275" HYPERLINK "#__RefHeading__45_117254275"código
do caso de uso HYPERLINK "#__RefHeading__45_117254275" HYPERLINK
"#__RefHeading__45_117254275" HYPERLINK "#__RefHeading__45_117254275">
HYPERLINK "#__RefHeading__45_117254275" HYPERLINK
"#__RefHeading__45_117254275" HYPERLINK "#__RefHeading__45_117254275"> ...... 9
8. DECISÕES DE PROJETO
... 10
9. REFERÊNCIAS
... 10

Introdução
Este documento especifica os casos de uso e requisitos não-funcionais (RNFs)
do projeto intitulado Sistema de controle de estoque de cosméticos, referente ao projeto
final da disciplina de Análise e Projeto Orientado à Objetos, contida no terceiro semestre
da matriz curricular do curso de Bacharelado em Ciência da Computação, ministrada
pelo professor Ms. Igor Scaliante Wiese. O objetivo do documento é apresentar as
soluções elaboradas e discutidas durante o semestre para a construção da análise e do
projeto de um software fundamentado nas ideias do paradigma orientado à objetos.

Descrição do sistema
O sistema possui como objetivo a organização de estoque de uma empresa de
cosméticos. O sistema irá possuir um número de quantidade em estoque, a informação
de estoque vazio, valor do produto, nome, marca, homecare ou profissional. Também
terá o cadastro de clientes no qual irão possuir dados (nome, telefone, endereço, CPF),
quantidade de produtos comprados e histórico de compras.

Objetivo do sistema
O sistema deverá possuir controle de produtos, clientes e valores, onde o produto irá
chegar da transportadora, será feita uma listagem de quantos e quais produtos
chegaram, após isso será inserido os valores dentro do sistema (quantidade e preço)
com opção para alteração do mesmo.

No momento da venda, o cliente será cadastrado, caso já esteja cadastrado, será

apenas colocado os produtos da venda, subtraindo a quantidade existente no estoque,
tendo assim, uma maior organização do que entra e sai da empresa entre produtos,
venda e clientes.

Convenções, termos e abreviações

A correta interpretação deste documento exige o conhecimento de algumas
convenções, termos específicos e abreviações, que são descritos a seguir.

Identificação dos casos de uso

Os casos de uso devem ser identificados com um identificador único. A
numeração inicia com o identificador [UC01] e prossegue sendo incrementada à medida
que forem surgindo novos casos de uso.
A nomenclatura dos fluxos secundários dos casos de uso é dada por uma sigla
e por um número. A sigla deve ser FA para fluxos alternativos e FE para fluxos de erro.
O número é um seqüencial que inicia de 01. Um exemplo de fluxo alternativo é [FA01]
e um exemplo de fluxo de erro é [FE01]. O número do identificador reinicia a cada caso
de uso.
Para referenciar casos de uso em qualquer local do documento, o identificador
do caso de uso é utilizado. Por exemplo, a pré-condição de um caso de uso poderia
conter o seguinte texto: “Este caso de uso demanda que o usuário da aplicação esteja
logado, como descrito em [UC12]”. Para referenciar um fluxo secundário fora do caso
de uso que o define, é necessário utilizar o identificador do caso de uso concatenado
com um ponto e com e o identificador do fluxo. Por exemplo, a descrição de um caso de
uso poderia conter o seguinte texto: “Este caso de uso permite que o usuário edite
informações avançadas do seu perfil e é disparado quando o usuário clica no botão
Informações Avançadas durante seu cadastro, conforme descrito no fluxo alternativo
[UC01].[FA02]”.

Prioridades dos casos de uso

A prioridade de cada caso de uso, informada nas seções 3 e 4, pode ser classificada
como “essencial”, “importante” e “desejável”, de acordo com a descrição abaixo:
• Um caso de uso essencial, se não for atendido, impede que a aplicação entre em
funcionamento. Casos de uso essenciais são imprescindíveis, isto é, têm de ser
implementados impreterivelmente.
• Se um caso de uso importante não for atendido, a aplicação pode até entrar em
funcionamento, mas de forma não-satisfatória. Casos de uso importantes deveriam
ser implementados, mas, se não forem, não impedirão a implantação e utilização da
aplicação.
• Um caso de desejável, por fim, é aquele cuja ausência de implementação não
compromete a operacionalização da aplicação, isto é, a aplicação pode funcionar de
forma satisfatória mesmo sem sua implementação. Esses casos de uso podem ser
deixados para versões posteriores da solução, caso não haja tempo hábil para
implementá-los na versão que está sendo especificada.

Lista de Requisitos
Abaixo encontra-se a lista de requisitos do projeto.
1RF: O sistema deve realizar cadastro de novos produtos;
2RF: O sistema deve adicionar produtos no estoque;
3RF: O sistema precisa cadastrar novos clientes;
4RF: O sistema deve ter a função de venda dos produtos;
5RF: O sistema permite desativar e ativar clientes;
6RF: O sistema deve ter a função de remover produto;
7RF: O sistema deve ter a função de adicionar o preço nos produtos, e alterar
dados.
8RF: Os clientes devem possuir historico de compras passadas.
 9RF: O sistema deve ter a opçao de alterar dado dos clientes.

Atores
A tabela abaixo descreve brevemente cada ator da aplicação.

Ator Descrição
1. Coletor 1. Quem irá receber o produto do entregador e
cadastrar o produto no sistema de estoque, o
coletor terá acesso ao sistema.
2. Entregador 2. Quem irá entregar o produto para o coletor.

3. Cliente 3. Quem irá comprar o produto com o vendedor

4. Vendedor 4. Quem irá retirar um produto do estoque tendo

acesso ao sistema, no caso dessa empresa, será
a mesma pessoa que o Coletor.

Casos de Uso
"casos de uso podem ser usados para representar requisitos de sistema, entre outras
coisas. Atualmente, eles são uma das abordagens mais importantes para requisitos
porque permitem a construção de uma estrutura que é mais fácil de entender, comunicar
e gerenciar do que as abordagens anteriores.

• Um modelo de casos de uso é uma imagem que permite à equipe descrever um

sistema complexo. Ele coloca em termos simples o que o sistema vai fazer pelos seus
usuários.

• Um caso de uso produz valor para um usuário particular e não para uma comunidade
não identificada deles.

• Casos de uso são também casos de teste; quando uma equipe termina de organizar
os requisitos em casos de uso eles também já produziram a estrutura necessária para
os casos de teste.

• Casos de uso são o ponto de partida para projetar experiências de usuário efetivas,
tais como, por exemplo, um web site.

• Casos de uso dirigem o desenvolvimento da análise ao design, do design para o código

e do código ao teste" WAZLAWICK, Raul Sidnei. Análise e projeto de sistemas de
informação orientados a objetos.

Casos de uso do sistema:

COLETAR PRODUTOS

CRUD PRODUTOS; (cadastrar, ler, atualizar e deletar)

ADICIONAR PRODUTOS AO ESTOQUE;

CRUD CLIENTE; (cadastrar, ler, atualizar e deletar)

VENDER PRODUTO;

Diagrama de Caso de Uso - <<nome do projeto>>

Essa seção apresenta todos os requisitos funcionais da aplicação, especificados
como casos de uso.

[UC01] Coletar Produtos

Prioridade: X Essencial Importante Desejável
Ator(es): Coletor, Entregador

Descrição: O ator entregador irá entregar os produtos a serem estocados para o

coletor. O coletor usará o sistema que deverá aumentar e mostrar a quantidade do
produto a ser estocado.
Pré-condições: É necessário que o produto esteja cadastrado.
Pós-condições: Os produtos deverão estar estocados e atualizados.

Fluxo principal
• O entregador irá entregar os produtos
• O coletor irá verificar quais produtos chegaram
• O coletor vai verificar se os produtos estão cadastrados.[UC03] <<include>>
• O coletor deverá alterar a quantidade de estoque do produto.
[UC04]<<include>>
 [UC02] Cadastrar produto

Prioridade: X Essencial Importante Desejável

Ator(es): Coletor

Descrição: O coletor irá verificar se o produto está no sistema, caso não esteja, o
coletor deverá incluir o produto no sistema com nome, foto, quantidade em estoque
e valor.

Pré-condições: Produto não existir no sistema.

Pós-condições: O produto estar cadastrado no sistema.

Fluxo principal
• Verificar se o produto está no sistema [UC03]<<include>>
• Cadastrar o produto.

[UC03] Ler Produtos

Prioridade: Essencial Importante X Desejável
Ator(es): Coletor/Vendedor

Descrição: O ator Coletor/Vendedor irá ler e verificar os dados do produto, tais

como preço, foto, quantidade em estoque e se o produto está cadastrado.
Pré-condições: É necessário que o produto esteja cadastrado.
Pós-condições: Nada mudará.
Fluxo principal
• O ator irá verificar os dados do produto.

[UC04] Adicionar Produtos

Prioridade: Essencial X Importante Desejável

Ator(es): Coletor

Descrição: Quando o produto cadastrado chega é necessário ser adicionado no

estoque. A quantidade do estoque deve aumentar.
Pré-condições: É necessário que o produto esteja cadastrado.
Pós-condições: A quantidade dos produtos deverão ser atualizados.

Fluxo principal
• O Coletor irá aumentar a quantidade desse produto no estoque.
 [UC05] Deletar produto

Prioridade: Essencial Importante X Desejável

Ator(es): Vendedor

Descrição: O vendedor irá verificar se o produto deixou de ser produzido e não

existe mais em estoque, se sim, poderá deletar o produto.

Pré-condições: Produto parou de ser produzido e acabou o estoque.

Pós-condições: O produto deverá deixar de existir no sistema.

Fluxo principal
• O vendedor vai receber a informação que o produto deixou de ser produzido;
• Verificar se o produto zerou no estoque [UC03]<<include>>
• Deletar o produto do sistema;

[UC06] Atualizar Produtos

Prioridade: Essencial X Importante Desejável

Ator(es): Coletor/Vendedor

Descrição: O ator irá modificar o que deseja do produto: preço, imagem e nome.
Pré-condições: É necessário que o produto esteja cadastrado e precise ser
modificado.
Pós-condições: Os produto terá uma modificação.
Fluxo principal
• O Ator irá mudar algum dado.

[UC07] Cadastrar cliente

Prioridade: X Essencial Importante Desejável

Ator(es): Vendedor

Descrição: O vendedor irá verificar se o cliente não existe no sistema, se não existir,
deverá incluir o cliente com nome, identidade (CPF, RG), foto(opcional), endereço,
telefone, nome fantasia, histórico de compras, data de ultima compra, Se o cliente
está ativo ou não.

Pré-condições: Cliente não existir no sistema.

Pós-condições: Cliente estar incluso com todas informações no sistema.

 Fluxo principal
• Verificar se o cliente não existe no sistema.[UC08]<<include>>
• Cadastrar o cliente no sistema.

[UC08] Ler Cliente

Prioridade: Essencial X Importante Desejável

Ator(es): Vendedor

Descrição: O vendedor irá verificar informações do cadastro do cliente, tais como:

Nome, endereço, CPF, foto(opcional), telefone, nome fantasia e historico de
compras.
Pré-condições: É necessário que o cliente esteja cadastrado.
Pós-condições: Nada mudará.
Fluxo principal
• O vendedor verificará os dados do cliente.

[UC09] Atualizar Cliente

Prioridade: Essencial X Importante Desejável

Ator(es): Vendedor

Descrição: O ator vendedor poderá modificar algum dado do cliente, principal

usado é o historico de compras durante as vendas
Pré-condições: É necessário que o cliente esteja cadastrado.
Pós-condições: Algum dado modificado.
Fluxo principal
• O cliente mudará algum dado ou fará alguma compra
• O vendedor vai atualizar seu cadastro com as novas informações

[UC10] Desativar cliente

Prioridade: Essencial Importante X Desejável
Ator(es): Vendedor

Descrição: O vendedor irá verificar se o cliente está inativo(não realiza compras) a

muito tempo, caso ele esteja inativo, o vendedor poderá escolher desativar o
mesmo.

Pré-condições: Cliente não realizar compras durante um longo período de tempo.

 Pós-condições: Cliente será desativado do sistema.

Fluxo principal
• Verificar se o cliente não realiza compras a muito tempo [UC08]<<include>>
• Modificar o estado do cliente para desativado[UC09]
• Desativar o cliente.

[UC11] Ativar cliente

Prioridade: Essencial Importante X Desejável

Ator(es): Vendedor, Cliente

Descrição: O cliente desejará voltar a fazer compras e o vendedor irá verificar se o

cliente está desativado. O vendedor poderá reativar o cliente.

Pré-condições: Cliente voltou a fazer compras

Pós-condições: Cliente será reativado no sistema.

Fluxo principal
• Verificar se o cliente está desativado [UC08]
• O cliente desejará fazer compras.
• Modificar o estado do cliente para ativo.

[UC12]Vender Produto

Prioridade: X Essencial Importante Desejável

Ator(es): Cliente, Vendedor

Descrição: Vai ser realizada a compra de um produto por um cliente ao vendedos,

diminuindo a quantidade em estoque.
Pré-condições: É necessário que o cliente esteja cadastrado e que os produtos
estejam em estoque.
Pós-condições: O estoque irá diminuir.
Fluxo principal
• O cliente irá pedir os produtos
• O vendedor irá verificar se os produtos estão em estoque
• Caso não esteja em estoque [FE001]<<extend>>
• Caso esteja em estoque os produtos vão ser alterados e a quantidade em
estoque diminuida [UC06]<<include>>
• Os produtos comprados vão ser adicionados no historico de compra do
cliente [UC09]<<include>>
Fluxos de erro
 [FE001]
• Caso o produto não esteja em estoque o vendedor será notificado e o
produto não será modificado.

Análise textual.
<<colocar uma referência bibliográfica explicando o que é uma análise textual.
Sucinta. Máximo 150 palavras>>
Apresente a análise textual. Esta tabela o ajudará no diagrama de classes.
A tabela abaixo descreve quais cada ator da aplicação.
Identificador Substantivos encontrados Verbos Encontrados
do Caso de Uso
<Indique o código do caso <coloque os substantivos <coloque os verbos encontrados
de uso> encontrados no caso de uso, no caso de uso, separe-os por
separe-os por vírgula> vírgula>

Pacotes
<<colocar uma referência bibliográfica explicando o que é um diagrama de
pacotes. Sucinta. Máximo 150 palavras>>
<Não deixe de apresentar a explicação do que cada pacote contém, deixando claro
quais pacotes oferecem quais serviços. Não se esqueça de verificar as dependências
após o diagrama de classe estar concluído.>

Diagrama de Pacote - <<nome do projeto>>

Nesta seção, será apresentado o diagrama de pacotes da aplicação. Esta visão
em pacotes pretende apresentar somente uma separação “lógica” dos serviços da
aplicação, no esforço de obter o máximo de reuso e flexibilidade de cada serviço. Não
será apresentada uma visão arquitetural em camadas da aplicação.
<Adicionar o diagrama de pacotes (figura) completo da aplicação>
<Repetir a estrutura para cada pacote.>

<Nome do Pacote 1>

<Descrição dos serviços deste pacote. - Ex: Este pacote oferece os serviços de
controle e gerenciamento das informações dos clientes. É possível incluir, alterar, excluir
e consultar clientes. As consultas podem ser realizadas por CPF e/ou parte do nome.
Além disto o usuário poderá consultar os clientes por data de nascimento e enviar uma
mensagem de aniversário.>

Classes
<<colocar uma referência bibliográfica explicando o que é um diagrama de
classes. Sucinta. Máximo 150 palavras>>
<Não esqueça de aplicar os princípios de um grande software. Prime por um projeto de
classes flexível e muito bem encapsulado. Que garanta a facilidade de manutenção e
reuso das classes, podendo atender a novos requisitos do cliente sem muitos
“traumas!”. Lembre-se de manter seu projeto o mais coeso possível, deixando a
aplicação “livremente unida”.>

Diagrama de Classes - <<nome do projeto>>

Nesta seção, será apresentado o diagrama de classes da aplicação. A visão
escolhida para o diagrama de classes é focada na persistência dos objetos, primando
por um projeto flexível e de fácil extensão/manutenção.
<Adicionar o diagrama de classes (figura) completo da aplicação>
<Não esqueça de pintar as classes utilizando cores que identificação a separação de
pacotes. Ex: Todas das classes do pacote Cliente devem estar pintadas de azul. Todas
as classes do pacote Produto devem estar de vermelho. Cuidado para as cores não
atrapalharem a visibilidade do projeto na impressão do documento. NÂO ESQUEÇA DA
LEGENDA!>

Sequência
<<colocar uma referência bibliográfica explicando o que é um diagrama de
seqüência. Sucinta. Máximo 150 palavras>>

<Repetir a estrutura para cada diagrama de sequência. Lembrando que cada operação do
CRUD possui um diagrama diferente.>

Diagrama de Sequência - <<código do caso de uso>>

<Adicionar o diagrama de seqüência (figura) de cada caso de uso>

Decisões de projeto
<Explicar pontos mais complexos do projeto justificando as tomadas de decisão.
Ex: Porque foi utilizado Interface e não classe abstrata e/ou vice e versa. Explicar pontos
onde foram utilizado polimorfismo/herança, princípio de divisão de responsabilidade
(encapsular o que varia), pontos onde por ventura foi necessário utilizar MAP ou outra
estrutura do Java collection Mostrar trechos específicos do diagrama de classes/código.
Separar cada explicação do projeto em Subitens. 6.1, 6.2, 6.3, consecutivamente.)

Referências
Nesta seção, são apresentadas as referências utilizadas para a elaboração
deste documento.
<Pode-se adicionar referências para justificar ações durante o projeto. O mesmo
pode ser utilizado para referenciar “inspirações” na tomada de decisão do projeto ou da
aplicação de conceitos mencionados no projeto. Devem-se seguir as normas da ABNT
para referenciar sites, documentos técnicos, livros, e-books, entre outros>