FACULDADE PITGORAS DE UBERLNDIA

COLOCAR O TTULO DO PROJETO

Nome do integrante 1, Nome do integrante 2, Nome do integrante 3,
Nome do integrante 4, Nome do integrante 5, Nome do integrante 6
Faculdade Pitgoras de Uberlndia, Curso Sistemas de Informao

RESUMO
Deve conter uma introduo ao documento e principalmente ao sistema que est em
desenvolvimento. Deve ser escrito em pargrafo nico.
Palavras-chave: Coloque aqui as palavras chave do seu tema. Por exemplo: estrutura de
dados, redes, Java language, Struts, UML...

ABSTRACT
O contedo do resumo traduzido em ingls.
Key-Words:
1. INTRODUO
Descreva a finalidade a que se prope este documento e seu pblico alvo. O texto a seguir
serve de exemplo. Inclua uma breve descrio sobre a aplicao deste documento; o que ser
afetado ou influenciado por este documento.Exemplo:
Este documento apresenta a modelagem do sistema <nome do sistema>. O pblico alvo deste
documento inclui pessoas envolvidas com o desenvolvimento (analistas de sistemas e
programadores) e avaliadores do projeto.
1.1 Descrio do negcio e da empresa
Neste sub-tpico devem ser inseridas informaes da empresa, abordando seu histrico e
informaes do negcio. O grupo tambm pode incluir foto da empresa ou mesmo print de
algum documento importante. Exemplo:
A <nome da empresa>, localizada na cidade de Uberlndia, atua no segmento de <identificar
a rea de atuao da empresa>. Desde sua fundao, a empresa trabalha vendendo produtos e
servios populao.
A empresa adquire produtos de vrios fornecedores, mas cada produto fornecido somente

FACULDADE PITGORAS DE UBERLNDIA

por um fornecedor. As informaes dos fornecedores de interesse da empresa so: a razo

social, o nome fantasia, o nmero no cadastro nacional de pessoa jurdica (CNPJ), a pessoa
de contato, a inscrio estadual e um nmero de telefone.
Cada produto possui uma classificao fiscal de acordo com a receita federal. A classificao
serve para determinar os tributos envolvidos nas diversas operaes. As informaes da
classificao fiscal importantes so o cdigo e a descrio. O mix de produtos com os quais a
empresa trabalha no diversificado. composto basicamente por perfis em alumnios. Cada
produto possui um cdigo interno, diferente do cdigo do fabricante, e um cdigo de barras.
Alm disso, possui descrio, preo da ltima compra, preo para venda e unidade (barra).
Normalmente a empresa mantm em suas dependncias certa quantidade de cada produto que
ela denomina de estoque. Cada estoque possui informaes sobre custo mdio, estoque
mximo, estoque mnimo, ponto de pedido e quantidade.
Alm do departamento de vendas a empresa possui tambm o departamento de compras.
Todos os dias esse departamento verifica o ponto de pedido e o estoque mnimo de cada
produto. Se a quantidade estocada do produto estiver entre o estoque mnimo e o ponto de
pedido o departamento de compras providencia pedido do produto para reposio do estoque.
No entanto, a quantidade pedida somada quantidade ainda em estoque nunca deve
ultrapassar ao estoque mximo.
A empresa possui vrios funcionrios. Dentre eles um e exerce o papel de supervisor geral,
alguns so vendedores, um atua no departamento de compras e um exerce o papel de
estoquista. Este ltimo a pessoa responsvel por conferir as notas de entrega dos produtos,
oriundos dos fornecedores, com os pedidos. Se no for detectada nenhuma no-conformidade
entre a quantidade que est sendo entregue com a que foi pedida de cada produto, o
estoquista valida a entrega e repe o estoque. As informaes importantes de cada
funcionrio so o nome, a data de nascimento, o endereo e o telefone para contato.
Devido aos longos anos vendendo produtos de qualidade e prestando servios especializados,
a empresa possui vrios clientes em Uberlndia e regio. Todos os clientes so pessoas fsicas
ou jurdicas. As informaes dos clientes que a empresa mantm em seus registros so o
nome/razo social, telefone para contato, a pessoa para contato
1.2 Requisitos Funcionais e No-funcionais
Para Sommerville (2007), requisitos so descries dos servios fornecidos pelo sistema e as
suas restries operacionais. Refletem as necessidades do cliente em termos de um software.
Neste sub-tpico dever ser descrito cada requisito funcional do sistema. Exemplos:

FACULDADE PITGORAS DE UBERLNDIA

O quadro 1 apresenta os requisitos funcionais identificados por meio de entrevistas com o

cliente.
RF01
RF02
RF03
RF04
RF05
RF06
RF07
RF08

O administrador do sistema deve ser capaz de realizar manuteno dos

usurios do sistema e de conceder acessos a funcionalidades especficas.
O sistema deve permitir ao administrador cadastrar a classificao fiscal
dos produtos.
O sistema deve permitir ao administrador e ao vendedor realizar
manuteno dos produtos.
O vendedor deve ser capaz de registrar venda.
O sistema deve permitir ao vendedor fazer manuteno dos fornecedores.
O sistema deve permitir ao departamento de compras registrar pedidos de
compras com base no ponto de pedido de cada produto em estoque.
O estoquista deve ser capaz de registrar entrega de produtos dos
fornecedores.
O estoque deve ser atualizado a cada nova venda e a cada compra
recebida.
Quadro 1 - Requisitos funcionais do sistema

De acordo com Sommerville (2007,p.82) Requisitos no funcionais so aqueles

no

diretamente relacionados s funes especficas do sistema. Relacionam-se a outras

propriedades do sistema como confiabilidade, performance, facilidade de uso, portabilidade,
escalabilidade etc.
Neste sub-tpico tambm dever ser descrito de forma detalhada cada requisito
no funcional do sistema. Exemplo:
O quadro dois mostra os requisitos no-funcionais.
RNF01
RNF02

Usabilidade: Funcionrios inexperientes devem ser capazes de utilizar

todas as funcionalidades do sistema aps treinamento.
Escalabilidade: O sistema deve permitir manuteno fcil.
Quadro 2 - Requisitos no funcionais do sistema

1.3 Regras de Negcio

Regras de negcio so polticas, condies ou restries que devem ser consideradas na
execuo dos processos de negcio de uma organizao. Descrevem a maneira a como a
organizao funciona. (BEZERRA, 2007, p. 85) Regras de negcio no dependem da

FACULDADE PITGORAS DE UBERLNDIA

existncia de um sistema. No entanto, aquelas que podem ser implementadas em um sistema

devem ser capturadas por influenciarem o comportamento de alguns casos de uso.
Neste sub-tpico devem ser descritas as regras de negcio. Exemplo:
O quadro 3 lista todas as regras de negocio que devero ser implementadas no sistema.
RN-01
RN-02
RN-03
RN-04
RN-05
RN-06
RN-07
RN-08

O sistema deve rejeitar o cadastro decliente ou de fornecedor caso o

CPF ou o CGC no seja vlido.
O cdigo de barras de cada produto deve ser gerado com base padro
EAN.
O quantidade em estoque do produto, de forma online, quando ocorrer
venda ou entrega pelos fornecedores.
Pedido de compra s poder feito para fornecedor cadastrado e com
status de ativo.
Todo produto deve estar associado a um fornecedor.
O sistema deve rejeitar a venda de produto cuja quantidade vendida
exceder a do estoque.
O usurio deve ser bloqueado caso erre o nome de usurio ou a senha
por 3 vezes.
Venda s realizada para cliente ativo.
Quadro 3 - Regras de negocio do sistema

FUNDAMENTAO TERICA

Redigir um pargrafo resumindo o que ser encontrado neste captulo. Exemplo:

Este captulo destina-se ao referencial terico do projeto. No sub-tpico 2.1 ser apresentada a
anlise do sistema; o sub-tpico 2.2 detalha a arquitetura e cdigo do projeto; j o sub-tpico
2.3 traz o Diagrama Entidade Relacionamento (DER), alm de abordar toda a parte de
persistncia de dados; por fim o ltimo sub-item descreve o projeto de interface.

2.1 Anlise do Sistema

Neste sub-tpico deve ser feita uma introduo sobre a anlise de sistemas, sua importncia
para o desenvolvimento de software e a necessidade de se criar modelos.
Diagrama de Casos de Uso
Nesta seo deve ser includo o diagrama de casos de uso construdo a partir da ferramenta

FACULDADE PITGORAS DE UBERLNDIA

de modelagem. Destaque os casos de uso que foram implementados at esta fase do

desenvolvimento do projeto.
A figura 1 apresenta o diagrama de casos de uso do sistema xxxx... nele... [explique
textualmente o diagrama apresentado].
uc Casos de uso Aluminio
Sistema

Manter usurio

Administrador
Cadastrar classificao
fiscal

Manter produto

include

Atualizar estoque

Registrar v enda

include
extend

Manter cliente

Registrar entrega de
produto
Conferencista

Vendedor
include

Consultar pedido
de compra

Departamento de compra
Manter fornecedor
extend

Registrar pedido de
compra

Figura 1 - Diagrama de casos de uso do sistema...

Descrio dos atores

Nesta seo identifique e faa uma breve descrio de como cada ator interage com o
sistema. Exemplo:
Administrador - Este ator responsvel por: incluir, alterar e excluir usurios do
sistema;atribuir nvel de acesso a funes especficas para todos os usurios; incluir produto e
manter suas informaes atualizadas e por cadastrar as classificaes fiscais.O administrador
tem acesso irrestrito ao sistema.
Vendedor - Este ator tem acesso restrito ao sistema. o responsvel por incluir fornecedores
e clientes, e por manter informaes destes atualizadas. Pode realizarconsulta de pedidos de
compras e opera o sistema para registrar vendas.
Estoquista - Este ator tem acesso restrito ao sistema. o responsvel pela conferncia de
todas as entregas que chegam de fornecedores. Conforme verifica a quantidade de cada item
constante na nota fiscal de compra com a quantidade entregue, ele confirma o recebimento do
produto no sistema, que atualiza a quantidade do produto no estoque.

FACULDADE PITGORAS DE UBERLNDIA

Departamento de compra - Este ator tem acesso restritoao sistema. responsvel pelo
registro de todas as compras realizadas junto aos fornecedores da empresa.

Especificao de casos de uso

Nesta seo deve ser especificado apenas um caso de uso. As demais descries podem ser
includasno final do documento na seoAPNDICE B.

Nome: Manter Cliente

Descrio: Caso de uso que descreve as etapas para manuteno de cliente
Ator primrio: Vendedor
Ator secundrio: Cliente
Pr-condio: Vendedorlogado no sistema
Ps-condio: Cliente alterado, excludo ou includo.
FLUXO PRINCIPAL_______________________________________________
1. O caso de uso inicia quando o vendedor seleciona a opo Manter cliente
2. O sistema apresenta as opes: Consultar,Incluir
3. De acordo com a seleo executado o fluxo alternativo Consultar Cliente ou Incluir
Cliente
FLUXO ALTERNATIVO: Consultar Cliente_____________________________
1.
2.
3.
4.
5.

O vendedor identifica o cliente

O sistema consulta o cliente
O sistema apresenta informaes do cliente
O vendedor seleciona alterar ou excluir
De acordo com a seleo executado o fluxo alternativo Alterar ou Excluir.

FLUXO ALTERNATIVO: Alterar Cliente________________________________

1.
2.
3.
4.

O sistema habilita a edio das informaes

O vendedor altera e submete informao
O sistema solicita confirmao da operao
O sistema grava a operao e retorna mensagem de sucesso

FLUXO ALTERNATIVO: Excluir Cliente________________________________

1. O sistema solicita confirmao da excluso
2. O vendedor confirma
3. O sistema exclui o cliente

FACULDADE PITGORAS DE UBERLNDIA

4. O sistema retorna mensagem de sucesso

FLUXO ALTERNATIVO: Incluir Cliente________________________________
1.
2.
3.
4.
5.

O sistema apresenta interface para incluso

O vendedor informa dados
O sistema solicita confirmao da operao
O vendedor confirma a operao
O sistema inclui o cliente, grava a operao e retorna mensagem de sucesso

FLUXO ALTERNATIVO: Cancelar operao (aplicvel em qualquer momento)_

1. O vendedor cancela operao
FLUXO DE EXCEO_____________________________________________
Origem: Consulta
1. O sistema no encontra o cliente
2. O sistema envia mensagem de erro ao vendedor
3. O sistema retorna ao passo 1 do fluxo alternativo Consultar Cliente
Origem: Alterao
Violao da regra de negcio RN08 e/ou RN13
1. O sistema envia mensagem de erro em campo obrigatrio ou validao de CPF
2. O sistema retorna ao passo 2 do fluxo alternativo Alterar Cliente
Origem: Excluso
Violao da regra de negcio RN14
1. O sistema envia mensagem de movimentao associada ao cliente
2. O sistema no exclui o cliente
Origem: Incluso
Violao da regra RN08 e/ou RN13
1. O sistema envia mensagem de erro em campo obrigatrio ou validao de CPF
2. O caso de uso retorna ao passo 2 do fluxo alternativo Incluir Cliente
Diagrama de Classes de Anlise
Nesta seo deve ser inserido o diagrama de classes construdo a partir da ferramenta de
modelagem. Ele dever ser uma figura do relatrio.
A figura 2 apresenta o diagrama de classes do sistema xxx... [descrever textualmente a
figura].

FACULDADE PITGORAS DE UBERLNDIA

class Exemplo PGI 2013-1

Funcionario
Venda

Item
-

numero
produto: Produto
precoUnitario
quantidade

calcularTotal() : void

possui
1..*

1..*

Relatorio
+
+

relatorioCliente
relatorioFornecedor
relatorioFuncionario
relatorioProduto
relatorioVenda
exibirRelatorio()
exportarRelatorio()

codigo
itens: Item
data
formaPagamento
tipo
status
observacao
responsavel: Funcionario

+
+
+
+

possui
inserirProduto(Produto, qtd)
0..*
removerProduto()
vincularCliente()
1
calcularTotal()

Produto
um 1 -

responsvel 0..*
1 -

Pessoa

0..*

codigo
codigoBarras
descricao
genero
tamanho
preco

atualizado

Estoque

contm
1

0..* +

codigo
ctps
comissao
dataAdmissao
dataDemissao

1
Cliente
-

codigo
dataCadastro

+
+

incluirDependente()
removerDependente()

codigo
nome
genero
dataNascimento
telefone
celular
endereco
endNumero
complemento
cep
cidade
uf

quantidadeItens
produto: Produto
local
atualizarEstoque()

Figura 2 - Diagrama de classes do sistema...

Diagramas de Sequncia
Nesta seo deve ser inserido apenas um Diagrama de Sequncia para um Caso de Uso
implementado at esta fase do desenvolvimento do seu projeto, construdo a partir da
ferramenta de modelagem. Ele dever ser uma figura do relatrio. Os demais diagramas
devero ser includos no final do documento na seo APNDICE A.
A figura 3 mostra o diagrama de sequencia do caso de uso xxxx... [descrever textualmente
este diagrama].

FACULDADE PITGORAS DE UBERLNDIA

sd Alterar Cliente

Funcionario

Interface Menu

Interface Cliente

Altera Cliente

Cliente

opo alterar cliente

alteraCliente
Interface Cliente

informa tipo: nome, cpf

seleciona pesquisar
consulta(nome,cpf)
opt
[nome]

c = consulta(nome)

[cpf]
c = consulta(cpf)

alteraCliente(c)
getNome
getCpf
getEndereco

altera nome
altera Cpf
altera endereco
alteraNome(nome)
[nome alterado]: setNome(nome)
alteraCpf(cpf)
[cpf alterado]: alteraCpf(Cpf)
altera endereco(endereco)
[endereco alterado]: setEndereco(endereco)

submete alterao
alterao solicitada
obter confirmao
confirma alterao
gravaAlterao
exibeMsg("Alterao realizada")

Figura 3 - Diagrama de sequencia do caso de uso xxxxx...

2.2 Arquitetura e Cdigo

Neste sub-tpico deve ser feita uma introduo ao conceito de arquitetura e o planejamento
da arquitetura no processo de desenvolvimento de software e aos aspectos importantes para a
escrita de cdigo limpo.

FACULDADE PITGORAS DE UBERLNDIA

10

Aplicaes em Camadas
Ao desenvolver sistemas utilizando uma arquitetura em camadas reduzida sua
complexidade, onde componentes so agrupados assim simplificam a comunicao entre eles,
a regra de comunicao evita dependncias diretas entre componentes de Camadas diferentes.
um padro arquitetural conhecido, facilitando a comunicao e entendimento entre
desenvolvedores.
Nesta seo deve ser feita uma abordagem ao desenvolvimento de software em camadas.

Modelo MVC e Frameworks da Camada de Apresentao

Faa uma especificao do modelo MVC descrevendo os elementos arquiteturais existentes
em cada modelo adotado, de acordo com o seu perodo, conforme tecnologias e recursos
escolhidos para o projeto. Abordar neste tpico o framework (Struts, JSF,etc) utilizado para
implementar o MVC.
As figuras 4 e 5 detalham a arquitetura do sistema. Nela ... [descrever a figura textualmente]
[No precisa ser como nos exemplos abaixo. Faa o desenho da sua prpria arquitetura e
substitua estes].

Figura 4 - Exemplo 1: Arquitetura do sistema xxxxxx

FACULDADE PITGORAS DE UBERLNDIA

11

Figura 5 - Exemplo 2: Arquitetura do sistema xxxxxx

Padres de Projeto
Nesta seo listar os padres de projeto utilizados na implementao (Business Object BO,
Data Access ObjectDAO, etc) Observao: o DAO pode ser listado aqui, mas o
detalhamento deve ser feito no sub-tpico seguinte (2.3).

Diagrama de Pacotes[somente para o 6 perodo]

Apresentar este diagrama.
Diagramas de Classes de Projeto[somente para o 6 perodo]
Apresentar o diagrama de classes de projeto de um caso de uso. O restante pode ser
disponibilizado nos apndices, ao final do documento.
Diagramas de Sequncia de Projeto[somente para o 6 perodo]
Apresentar o diagrama de sequncia de projeto de um caso de uso. O restante pode ser
disponibilizado nos apndices, ao final do documento.
Recursos e Tecnologias utilizadas na Camada de Negcio
Apresentar nesta seo todos os recursos, linguagens, tecnologias e ferramentas utilizadas
para a arquitetura e codificao do sistema.

2.3 Persistncia de Dados

Neste sub-tpico deve ser feita uma introduo banco de dados e persistncia de dados.
Banco de dados um conjunto de requisitos dispostos em estrutura regular que possibilita a
reorganizao dos mesmos e produo de informao.Agrupa registros utilizveis para um mesmo
fim. So utilizados em diversas aplicaes, abrangendo praticamente todo o campo dos programas de
computador.

FACULDADE PITGORAS DE UBERLNDIA

12

Persistncia de dados a gravao de dados em um dispositivo fsico, onde os dados no sero

perdidos e podem ser recuperados em qualquer momento.
Para persistir os dados em um banco de dados relacional utilizada a linguagem SQL, que a
linguagem padro nos sistemas gerenciadores de banco de dados. Outro jeito de persistir os dados
utilizando um banco de dados orientado a objetos, que tem seus pilares em herana, polimorfismo e
encapsulamento, com maior flexibilidade na manipulao de seus objetos. Nesse tipo no utilizada a
linguagem padro SQL.

Diagrama Entidade Relacionamento (DER)

Inclua neste item o diagrama de entidade e relacionamento construdo a partir da ferramenta
de modelagem. Indique tambm, alm das entidades, vises e ndices.
A figura 6 apresenta o DER do sistema. Nele ... [descrever textualmente a figura].
ITEM
PED_NUMERO (FK)
PRO_CODIGO (FK)
ITE_QUANTIDADE
ITE_PRECOUNITARIO

CIDADE
CID_SEQUENCIA
CID_NOME

PEDIDO
PED_NUMERO

PRODUTO

PES_FUNCIONARIO (FK)
PES_CLIENTE (FK)
PED_DATA

PRO_CODIGO
PRO_DESCRICAO
PRO_PRECO
PRO_QUANTIDADEESTOQUE
PRO_CUSTOESTOQUE

FUNCIONARIO
PES_CODIGO (FK)
FUN_NOME

CEP
CEP_NUMERO
CID_SEQUENCIA (FK)

ESTADO

CLIENTE

EST_SIGLA

PES_CODIGO (FK)

CEP_NUMERO (FK)
EST_NOME

CLI_NOME
CLI_CPF

ENDERECO
PESSOA
PES_CODIGO
PES_TIPO

PES_CODIGO (FK)
END_SEQUENCIA
END_TIPO
EST_SIGLA (FK)
LOGRADOURO

Figura 6 - Diagrama de entidade e relacionamento

Mapemaento Objeto Relacional com Framework Hibernate [somente para o 6 perodo]

Nesta seo deve ser feita uma abordagem ao padro de projeto DAO para persistncia de
dados.

FACULDADE PITGORAS DE UBERLNDIA

13

Padro de Projeto Data Access Object (DAO)

A camada, ou layer, de persistncia ou de acesso aos dados a parte da aplicao responsvel
por se comunicar com o banco de dados, ou com o framework de persistncia. Sendo um
pado conhecido o DAO. Numa aplicao orientada a objetos, temos a boa separao entre as
responsabilidades de cada parte da aplicao. A parte de acesso ao banco de dados
responsvel por se conectar ao banco de dados e extrair, inserir e atualizar as informaes.
responsvel tambm por transformar modelos de Objetos em modelos Relacionais. As classes
DAO representam uma camada prpria, e formam um pacote de acesso de dados, algumas
vezes sob o pacote do modelo, algumas vezes um pacote independente e outras vezes parte
do pacote de controladores. Assim temos uma separao e relativa independncia da camada
de acesso de dados e do Domnio. Ento o DAO passa a programar mtodos como Select,
Delete, Insert, Update. O DAO pode ser usado tambm como camada entre a aplicao e o
modelo, ou entre diferentes aplicaes. Passa-se a no acessar o modelo diretamente (com
new) e usar os mtodos do DAO para tal. Assim, sempre que quiser uma instncia de um
Modelo, usa-se o DAO.
Nesta seo deve ser feita uma abordagem ao padro de projeto DAO para persistncia de
dados.
2.4 Projeto de Interface
O projeto de interface se define pelo uso das boas praticas para criao de uma interface,
disponibilizando assim uma boa interao com o usurio. A interface deve enderear as
necessidades e limitaes dos usurios, mas no apenas as necessidades funcionais. Sendo
assim se estabelece o fator primordial para o sucesso do sistema.
Fazer uma introduo ao assunto abordando o que o projeto de interface, sua importncia e
do que se trata o item.
Design, Usabilidade e Acessibilidade
Design o desenvolvimento de projetos a partir da aplicao de conceitos construdos com
base na observao das experincias e de testes com usurios. Sua aplicao visa a melhoria
da relao homem-mquina, j que o sucesso de um produto no mercado depende muito da
experincia interativa que ele pode proporcionar. So criados produtos e servios de maior
(usabilidade) sob o conceito do Design Centrado no Usurio, levando em conta os objetivos,
funes, experincias, necessidades e desejos destes, visando o equilbrio entre os anseios

FACULDADE PITGORAS DE UBERLNDIA

14

dos usurios, dos negcios dos clientes e das possibilidades tecnolgicas.

A Usabilidade definida como o grau de facilidade com que o usurio consegue interagir
com determinada interface, esta aborda a forma como o usurio se comunica com a mquina
e como a tecnologia responde interao do usurio, considerando as seguintes
especificaes:

Facilidade de aprendizado: a utilizao do sistema requer pouco treinamento;

Fcil de memorizar: o usurio deve lembrar como utilizar a interface depois de algum
tempo;

Maximizar a produtividade: a interface deve permitir que o usurio realize a tarefa de

forma rpida e eficiente;

Minimizar a taxa de erros: caso aconteam erros, a interface deve avisar o usurio e
permitir a correo de modo fcil;

Maximizar a satisfao do usurio: a interface deve dar-lhe confiana e segurana.

Acessibilidade se define pela flexibilidade que proporciona o acesso informao e

interao, de maneira que usurios com diferentes necessidades possam acessar e usar o
sistema. Pessoas com e sem limitaes possuem igual importncia, sejam limitaes na
capacidade de movimento, de percepo, de cognio ou de aprendizado. Cuidar da
acessibilidade permite que mais pessoas usem o sistema (tanto sem quanto com limitaes), e
no apenas poucas pessoas com caractersticas especficas.
Abordar nesta seoos conceitos de design, navegabilidade, uso das cores, o que
usabilidade e acessibilidade e sua importncia para a interface do sistema.
Arquitetura da Informao
A Arquitetura da informao (AI) a arte de expressar um modelo ou conceito de informao
utilizado em atividades que exigem detalhes explcitos de sistemas complexos. Entre essas
atividades esto sistemas de biblioteca, sistemas de gerenciamento de contedo,
desenvolvimento web, interaes de usurios, desenvolvimento de banco de dados,
programao, artigos tcnicos, arquitetura corporativa e de design de software de sistema
crtico.
Abordar nesta seos conceitos de Arquitetura da Informao e apresentar os wireframes das

FACULDADE PITGORAS DE UBERLNDIA

15

telas principais (login, menu,CRUD, cadastros, venda se for o caso).

Obs. Faa apenas um wireframe detalhando o mximo possvel das informaes, coloque j
os itens no menu, etc.. Os demais wireframes podem ser adicionados como anexo neste
documento.
A figura 7 apresenta o wireframe de uma tela CRUD, na qual possvel incluir, pesquisar,
atualizar ou excluir clientes. [Descrever textualmente a figura]

Figura 7 - Wireframe da tela CRUD do sistema

Diagrama de Estados de Navegao

Nesta seo deve ser inserido o Diagrama de Estados de Navegao dos Casos de Uso. Obs:
Para a construo desse diagrama selecione na Toolbox do Enterprise Architect (lado
esquerdo da IDE) a opo Domain Analyst e, em seguida, selecione a opo User Interface.
Exemplo
A figura 8 apresenta o Diagrama de Estados de Navegao do Caso de Uso Processar Venda.
Nele ... [descrever textualmente a figura]

FACULDADE PITGORAS DE UBERLNDIA

16

ui Processar Venda
Login

Login(senha,nome)

Menu

Novo login

Voltar

Registrar venda

Registro de Vendas

Figura 8 - Diagrama de Estados de Navegao

Tecnologias Utilizadas para o Desenvolvimento de Interfaces

Nesta seo devero ser descritas as tecnologias web (interface) utilizadas para a
implementao das interfaces at esta fase do projeto. Descrever, colocar o referencial
terico das tecnologias e recursos que foram utilizadas para desenvolver a interface do
sistema. Colocar tambm parte do cdigo, explicando como funciona, por exemplo, CSS, se
foi utilizado.
2.5 Teste de Software
Fazer uma introduo ao assunto abordando Teste de Software, sua importncia e o que foi
desenvolvido no PGI no mbito de testes. Apresentar os casos de teste de acordo com a
disciplina Teste de Sistemas.
3

IMPLEMENTAO DO SISTEMA [colocar nome/sigla do sistema]

Neste captuloescolher um caso de uso e mostrar passo a passo o processo de implementao

abordando os aspectos de anlise, arquitetura, cdigo, banco de dados e interface. Comentar
como o projeto est sendo desenvolvido e mostrar os resultados obtidos at o momento.
Podem ser utilizados prints do prottipo do sistema ou mesmo desenhos das perspectivas das
telas.
4

CONSIDERAES FINAIS

Captulo destinado para expor suas concluses sobre os assuntos abordados, a situao
atuao do projeto e ainda perspectivas de trabalhos futuros a partir do presente projeto.

FACULDADE PITGORAS DE UBERLNDIA

17

REFERNCIAS
Coloque aqui os livros, pginas da Internet, apostilas e outros materiais que voc consultou.
Siga as normas da ABNT (consulte um livro na biblioteca sobre metodologia cientfica).
Exemplo:
LFGREN, I. A usabilidade da cor. Disponvel
em:http://blogdeusabilidade.blogspot.com/2004/11/usabilidade-da-cor.html. Acesso em: 10
de maio 2011.
PRESSMAN, Roger. Engenharia de Software. Traduo Rosngela Delloso Penteado. 6 ed.
So Paulo: McGraw-Hill, 2006. 720p.
REIS, G. O que arquitetura de informao em websites. Disponvel em:
http://webinsider.uol.com.br/index.php/2006/04/15/o-que-e-arquitetura-de-informacao-emwebsites. Acesso em: 7 de maio 2011.
SOMMERVILLE, Ian. Engenharia de Software. Traduo Andr Maurcio de Andrade
Ribeiro. 6 ed. So Paulo: Addison Wesley, 2003. 592p.
SOMMERVILLE, Ian. Engenharia de software. Traduo de Andr Maurcio de Andrade
Ribeiro; reviso tcnica KechiHirama. 6.ed. So Paulo: Addison Wesley, 2003. 592 p. Ttulo
original: Software Engineering.
UTIDA, H. K. Metodologias Tradicionais e Metodologias geis: analise comparativa entre
rationalunifiedprocess e extreme programming.2012. 48f. Monografia (Trabalho de
Concluso de Curso) Faculdade de Tecnologia do Estado de So Paulo. Disponvel em
<http://www.fatecsp.br/dti/tcc/tcc00055.pdf>. Acesso em 20 maio 2014.
VITOR, A. DE. S.; FILHO, E. E. DE L.; JORGE, R. DA. S.; Software para gesto de
academia, 2008. 182 f. Monografia (Trabalho de Concluso do Curso de Sistemas de
Informao) - Faculdade de Cincias Aplicadas de Minas, FASCIMINAS/UNIMINAS,
Uberlndia. Disponvel em
<http://www.si.lopesgazzani.com.br/TFC/monografias/MONOGRAFIA_ALESSANDRO_E
DUARDO_RICARDO.pdf>. Acesso em: 15 mai. 2011.
W3C accessibilityinitiative. Disponvel em: http://www.w3c.org/WAI. Acesso em: 4 de
maio 2011.

FACULDADE PITGORAS DE UBERLNDIA

18

APNDICE A - Diagramas da UML

Voc dever colocar todos os diagramas da UML desenvolvidos para o projeto e que no
constam no interior do documento.

APNDICE B -Descrio dos Casos de Uso

Voc dever colocar aqui a descrio dos demais casos de uso que no foram apresentados no
documento.

APNDICE B - Cdigo Fonte do Programa

Voc dever colocar aqui somente cdigos principais, como os arquivos de configurao
(XML).
APNDICE C - Wireframes do Projeto de Interface
Voc dever colocar aqui os demais wireframes que no constam no interior do projeto.