Modelagem de Dados

Prévia do material em texto

�PAGE �
UNIVERSIDADE ESTADUAL DE GOIÁS
CÂMPUS GOIANÉSIA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
nome completo do aluno 
Titulo do Trabalho:
Sub-título do trabalho 
Nome do Software
Cidade - UF
Mês (por extenso e sem abreviação), Ano (4 digitos) 
�
UNIVERSIDADE ESTADUAL DE GOIÁS
CÂMPUS GOIANÉSIA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
nome completo do aluno 
Titulo do Trabalho:
Sub-título do trabalho 
[Projeto | Monografia | Trabalho | Trabalho de Curso etc] apresentado ao Departamento de Sistemas de Informação do Câmpus Goianésia da Universidade Estadual de Goiás, [como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação ] ... [para obtenção da nota da primeira VA etc].
Orientador: Prof. [Esp. | Ms. | Dr.] Nome completo do orientador
Cidade
Mês (por extenso e sem abreviação), Ano (4 digitos) 
�
UNIVERSIDADE ESTADUAL DE GOIÁS
CÂMPUS GOIANÉSIA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Titulo do Trabalho:
Sub-título do trabalho sem abreviatura
[Projeto | Monografia | Trabalho | Trabalho de Curso etc] apresentado ao Departamento de Sistemas de Informação do Câmpus Goianésia da Universidade Estadual de Goiás, como requisito para obtenção de nota final do projeto de graduação I em Sistemas de Informação.
Aprovado por:
Nome completo do orientador, [Especialista | Mestre | Doutor], Sigla da universidade que atua
(ORIENTADOR)
Nome completo do examinador, [Especialista | Mestre | Doutor], Sigla da universidade que atua
 (EXAMINADORA )
Cidade, dia de mês de ano. 
(No campo acima colocar a data da apresentação a banca – esta folha deverá ser preenchida e levada impressa para entregar ao orientador no dia da banca)
�
FICHA CATALOGRÁFICA
	ÚLTIMO SOBRENOME DO AUTOR, Nomes do autor. (Ex. SILVA, Ana Maria.) 
Título do trabalho: Subtítulo do trabalho. [Goianésia] Ano.
(UEG / Câmpus Goianésia, Bacharelado em Sistemas de Informação, ano).
Trabalho de Curso. Universidade Estadual de Goiás, Câmpus Goianésia. Departamento de Sistemas de Informação.
1. Palavra chave 2. Palavra chave 
3. Palavra chave 
REFERÊNCIA BIBLIOGRÁFICA
ÚLTIMO SOBRENOME DO AUTOR, Nomes do autor. Título do trabalho: Subtítulo do trabalho. Goianésia, ANO. xx p. Monografia/Trabalho de Curso – Curso de Sistemas de Informação, Câmpus Goianésia, Universidade Estadual de Goiás. 
CESSÃO DE DIREITOS
NOME DO AUTOR: Xxxxxx Xxxxxxx Xxxxxx
TÍTULO DO TRABALHO: Ttttttt Ttttttt Ttttttt.
GRAU/ANO: Graduação /Ano.
É concedida à Universidade Estadual de Goiás permissão para reproduzir cópias deste trabalho, emprestar ou vender tais cópias para propósitos acadêmicos e científicos. O autor reserva outros direitos de publicação e nenhuma parte deste trabalho pode ser reproduzida sem a autorização por escrito do autor.
Nome do Autor
Endereço
CEP XXXXXX – Cidade – GO – Brasil
�
Dedicatória (Exemplo Dedico este trabalho os meus pais etc...).
�
AGRADECIMENTOS
 (Exemplo:) Ao meu orientador Prof. xxxxxx, pelo constante apoio, incentivo, dedicação e amizade essenciais para o desenvolvimento deste trabalho e para o meu desenvolvimento como pesquisador.
Aos meus colegas de turma pelo incentivo.
...
A todos, os meus sinceros agradecimentos.
	
�
LISTA DE ABREVIATURAS E SIGLAS
Siglas		Descrição
SIGLA		Descrição da sigla (deve ser ordenado alfabeticamente pela sigla)
�
RESUMO
(Exemplo:) 
O trabalho descrito neste projeto objetiva .... (Não pode ultrapassar 500 palavras)
Palavras-chave: Palavra chave 1, ...., , palavra chave N.
�
ABSTRACT
(Exemplo:) 
The work described in this …
 
Keywords: Keyword 1, … , keyword n
Prefácio
O prefácio contém uma introdução que deverá abordar:
O propósito deste documento;
O propósito do sistema (isto é, introdução ao domínio do negócio e ao problema que será resolvido pelo sistema);
E como este documento está organizado.
Resumindo, o prefácio deve seguir o estilo de uma introdução usada em artigos científicos.
Tabela de Revisões
Esta tabela contém um histórico das revisões do documento. As entradas na tabela abaixo servem apenas de caráter ilustrativo. As demais entradas deverão ser apagadas até que a revisão a que ela se referir tenha sido criada. 
	Versão
	Principais Autores
	Descrição da Versão
	Data de Término
	V[x.x]
	[nome]
	[descrição da versão]
	[dd/mm/aaaa]
	
	
	
	
	
	
	
	
	V[x.x]
	[nome]
	[descrição da versão]
	[dd/mm/aaaa]
	
	
	
	
	
	
	
	
Índice
Este índice foi criado de forma automática. Caso você tenha alterado, criado ou retirado algum item do corpo deste documento, atualize este índice posicionando o cursor em qualquer lugar do índice e pressione a tecla F9. Se você deseja que este documento seja fácil de ser mantido, nunca altere o conteúdo deste índice de forma manual.
161.	Lista de Figuras	
2.	Lista de Tabelas	17
3.	modelagem do negócio	18
3.1	Atas de Reunião	18
3.2	Descrição do Negócio	19
3.3	Dificuldades Existentes no Negócio e Propostas de Solução	20
3.4	Definição do Problema	20
3.5	Finalidade do Sistema	20
3.5.1	Objetivo	20
3.5.2	Clientes Alvo	20
3.5.3	Escopo	20
3.5.4	Glossário do Negócio	21
3.5.5	Detalhes do Sistema	21
4.	Requisitos	22
4.1	Especificação dos Requisitos	22
4.1.1	ER[f|a][F|D|I|N]N.v {versão do requisito}	22
Regras de negócio associadas	22
4.2	Modelo de Casos de Uso	23
4.2.1 Casos de Uso	23
4.2.2 Descrição dos Atores	23
[Nome do Ator N]	23
4.2.3 Diagrama Geral de Casos de Uso	23
4.2.4 Detalhamento dos Casos de Uso	24
Caso de Uso [Nome do Caso de Uso N]	24
Diagrama de Atividades do [nome do Caso de Uso]	24
Diagrama de Sequência do Sistema (DSS) para o [nome do Caso de Uso]	25
Contratos de Operações do Sistema para o [nome do Caso de Uso]	25
4.2.5 Priorização de Casos de Uso	25
5.	Modelo de domínio	26
5.1	Diagrama Geral de Classes Conceitual	26
5.2	Glossário	26
6.	Arquitetura do Sistema	27
6.1.1	Diagrama de Camadas	27
6.1.2	Camada [Nome da Camada]	27
7.	Projeto	28
7.1	CRC	28
Descreva os cartões CRC (Class-Responsibility-Collaborator Cards) que foram elaborados para descobrir colaborações e responsabilidades das classes que constam no Modelo do Domínio.	28
7.2	Realizações de Casos de Uso	28
7.2.1	[Nome do Caso de Uso]	29
Diagrama de Sequência (DS) do método [nome do Método]	29
Diagrama de Sequência (DS) do método [nome do Método]	30
Diagrama de Sequência (DS) do método [nome do Método]	31
7.3	Diagrama Geral de Classes de Projeto	33
7.4	Projeto Arquitetural (Pacotes)	34
7.4.1	Diagrama de Pacotes	34
Pacote [Nome do Pacote]	34
7.5	Modelo de Dados	35
7.5.1	Projeto Conceitual do Banco de Dados	35
7.5.2	Projeto Lógico do Banco de Dados	36
Leiaute da Tabela [Nome da Tabela]	36
8.	Testes	38
8.1	Teste de Stress	38
8.2	Teste de Funcionalidade	39
8.2.1	Teste de funcionalidade do Fluxo de Evento Principal	39
8.2.2	Teste de funcionalidade do Fluxo de Evento Alternativo [N]	39
8.2.3	Teste de funcionalidade do Fluxo de Evento de Exceção [N]	40
9.	CONCLUSÃO / RECOMENDAÇÕES	42
10.	REFERÊNCIAS	44
11.	APÊNDICES	46
12.	ANEXOS	49
�
Lista de Figuras
Sempre que for inserida uma nova figura ao documento, ela deverá possuir uma legenda do tipo figura, para que este índice possa ser atualizado corretamente. Para atualizar este índice de figuras, coloque o cursor em qualquer lugar da mesma e pressione a tecla F9. Se você deseja que este índice seja fácil de ser mantido, nunca o altere manualmente.
27Figura 1 - Interface para o(s) Caso(s) de Uso	
�
Lista de Tabelas
Sempre que for inseridauma nova tabela ao documento, ela deverá possuir uma legenda do tipo tabela, para que este índice possa ser atualizado corretamente. Para atualizar este índice de tabelas, coloque o cursor em qualquer lugar da mesma e pressione a tecla F9. Se você deseja que este índice seja fácil de ser mantido, nunca o altere manualmente.
Esta seção pode ser excluída se o documento não contiver tabelas.
17Tabela 1 – Tabela de Especificação do Requisito ER[f|a][F|D|I|N].N	
Tabela 2 - Fluxo de Eventos do Caso de Uso [nome do Caso de Uso]	19
Tabela 3 – Requisitos relacionadas com a interface gráfica	27
Tabela 4 – Leiaute da tabela N	31
Tabela 5 - Teste de funcionalidade do Fluxo de Evento Principal	34
Tabela 6 - Teste de funcionalidade do Fluxo de Evento Alternativo [N]	35
Tabela 7 - Teste de funcionalidade do Fluxo de Evento Exceção [N]	35
�
modelagem do negócio
Atas de Reunião
Descreva uma redação para cada ata de reunião realizada com os usuários do sistema, conforme modelo abaixo.
	ATA da Reunião Nrº 99
	Data:
	Horário:
	Local:
	dd/mm/aaaa
	Das 99h99m às 99h99m
	Informar o local onde foi realizada a reunião.
	Equipe técnica:
	Informar os nomes das pessoas da equipe técnica que participaram da reunião.
	Equipe usuária:
	Informar os nomes das pessoas da equipe usuária que participaram da reunião.
	Teor desta reunião:
	<Descrever aqui a redação da reunião. As linhas deverão ser numeradas. Veja exemplo>
1.A reunião foi realizada no local e na hora agendada. Dado início à reunião, Sr. Fulano de 2.Tal, condutor da reunião, se apresenta e inicia as entrevistas com o usuário. O usuário quer 3.um sistema de controle de entrada e saída de 3.funcionários, um controle para o pagamento 4.de horas extras, descontos por faltas e atrasos, e um controle das convocações. 
	Observação Importante:
	[opcional] Descrever aqui:
Informar qual a técnica usada durante a reunião (por exemplo: JAD, brainstorming, entrevista informal, seminário, etc.);
Divergências encontradas no contexto do projeto;
 Dúvidas a serem esclarecidas;
Assuntos a serem abordados em futuras reuniões;
Contatos (telefones, e-mails, ect) das equipes que participaram desta reunião;
Outros detalhes de julgarem importantes.
Descrição do Negócio
Seguir modelo abaixo:
	Descrição do Negócio
	
Descreva uma redação detalhando o domínio do negócio. 
Incluir explicações das regras de negócio, políticas relacionadas ao negócio, leis, restrições, citar exemplos, etc.
[opcional] Inserir aqui artefatos gráficos, ou seja, para melhor clareza, você pode-se usar também a linguagem gráfica (workflow ou diagramas de atividades do negócio) para explicar algo relacionado ao negócio.
Na tabela abaixo você deverá listar objetivamente cada regra de negócio extraída da redação que foi descrita em “Descrição do Negócio”. Veja exemplo:
	Regras de Negócio
	Identificação
	Regras de Negócio
	RN01
	Funcionário deve cumprir 8 horas diárias.
	RN02
	Horário de almoço fixo, no período de 12:00 às 14:00h.
	RN99
	A prestação de conta do ponto é feita no primeiro dia útil do mês subseqüente.
Dificuldades Existentes no Negócio e Propostas de Solução
[opcional] Descreva as dificuldades atuais que por ventura já existam no negócio, e para cada uma delas proponha uma solução, conforme tabela abaixo. Veja um exemplo fictício descrito na tabela:
	Dificuldades
	Propostas de Soluções
	1. “A maioria dos usuários não sabem utilizar computador, e a empresa não tem previsão quando irá realizar o treinamento”.
	“Criar as interfaces gráficas fáceis de serem utilizadas; criar rotinas automáticas que deverão ser acionadas sem intervenção do usuário”.
	2.
	
	3.
	
	N.
	
Definição do Problema
Descreva textualmente o problema que deve ser solucionado pelo sistema.
Finalidade do Sistema
Objetivo
Descreva textualmente as finalidades do sistema, ou seja, o que ele exatamente se propõe a solucionar do problema, e para melhor clareza, acrescentar também, o que o sistema não se propõe a solucionar. 
Clientes Alvo
Descrever o público alvo do sistema, conforme tabela abaixo. 
	Nome
	Definição
	Nome do cliente
	Explicar o papel do cliente no sistema, suas responsabilidades, etc.
	
	
Escopo
Equivale ao Diagrama de Contexto da Análise Estruturada, porém usa-se uma linguagem textual, mais informal.
Glossário do Negócio
Defina todos os termos, acrônimos e abreviações a serem utilizadas neste documento a respeito do negócio. Caso não tenha nenhum termo, escreva a palavra "Inexistente" neste item. 
	Termo
	Definição
	Sinônimo
	
	
	
	
	
	
Detalhes do Sistema
 [opcional] Neste tópico você deve colocar detalhes do sistema como o nome comercial, o ícone que será usado, ou seja, detalhes que não essenciais.
Requisitos
Especificação dos Requisitos
Este tópico deverá especificar todos os requisitos do software em um nível de detalhe suficiente para que os especialistas possam desenvolver o sistema satisfazendo os requisitos do cliente, os responsáveis pelo teste possam verificar se o sistema satisfaz a esses requisitos e os clientes possam avaliar se suas necessidades estão representadas nestes requisitos.
Todos os requisitos deverão ser identificáveis de forma única, seguindo o modelo apresentado neste documento.
Nenhum texto é necessário entre este item e o próximo, a menos que desejado. Consulte o capítulo 3 do livro para saber mais detalhes sobre levantamento e especificação de requisitos.
ER[f|a][F|D|I|N]N.v {versão do requisito}
Preencha a tabela de Especificação para cada requisito levantado junto ao cliente do sistema. Consulte o Livro para tirar dúvidas de como preencher as tabelas.
	ERfF.N
	Nome da Especificação de Requisito
	Descrição
	Descreva detalhadamente o requisito do sistema, exemplificando sempre que possível
	Regras de negócio associadas
	Listar as identificações das regras de negócio associadas a este requisito. Ex.: RN01, RN02.
	Descrição do risco
	Risco
	Prioridade
	Descreva o risco associado ao requisito colocando o máximo de informação possível para a mitigação
	Dê um qualificador para o risco.
p.ex. Altíssimo
	Dê um qualificador para a prioridade.
p.ex. Altíssima
	O porque da não implementação do requisito (Somente para Requisitos futuros)
	Descreva neste campo o porque da não implementação do requisito e quando e em que versão se deseja implementá-lo. Caso o requisito seja atual estas duas últimas linhas da tabela devem ser excluídas
Tabela 1 – Tabela de Especificação do Requisito ER[f|a][F|D|I|N].N 
Modelo de Casos de Uso
4.2.1 Casos de Uso
Listar todos os casos de uso do sistema referentes aos requisitos funcionais, conforme tabela abaixo. 
	Caso de Uso
	Colocar aqui o Nome do Caso de Uso 1.
	Colocar aqui o Nome do Caso de Uso 2.
	Colocar aqui o Nome do Caso de Uso n.
4.2.2 Descrição dos Atores
[Nome do Ator N]
Faça uma breve descrição de como este ator interage com o sistema. O texto abaixo pode ser utilizado como orientação. 
Este ator é uma [pessoa ou um sistema ou um dispositivo] que atua no sistema para...
4.2.3 Diagrama Geral de Casos de Uso
Inclua aqui o diagrama principal de casos de uso, construído a partir da ferramenta de modelagem. O diagrama principal deve incluir todos os casos de uso já identificados que irão implementar os requisitos do sistema e os respectivos atores.
Figura X – Diagrama Geral de Casos de Usos
4.2.4 Detalhamento dos Casos de Uso
Caso de Uso [Nome do Caso de Uso N]
Descrever detalhadamente o Caso de Uso. 
	Nome do Caso de Uso
	Coloque um nome adequado para o Caso de Uso.
	Descrição
	Descreva detalhadamente o propósito do Caso de Uso.
	Requisitos Associados
	Liste os requisitos que estão sendo atendidos por esteCaso de Uso.
	Pré Condições
	Se existir uma ou mais pré-condições, descreva-as aqui.
	Pós Condições
	Se existir uma ou mais pós-condições, descreva-as aqui.
	Atores
	Liste os atores que se relacionam com este Caso de Uso.
	Fluxo Principal
	Ações Recebidas
	Ações Realizadas
	O ator X inicia a fluxo principal (ou fluxo ótimo). 
	O processo recebe a entrada, avalia e envia ao controle.
O controle trata a informação.
Após tratar a informação os dados são apresentados ao ator.
	Fluxo Alternativo N
	Ações Recebidas
	Ações Realizadas
	O ator X inicia a fluxo alternativo N
 ( ou fluxo de erro, ou fluxo opcional, etc).
	O processo recebe a entrada, avalia e envia ao controle.
O controle trata a informação.
Após tratar a informação os dados são apresentados ao ator.
Tabela 2 - Fluxo de Eventos do Caso de Uso [nome do Caso de Uso]
Diagrama de Atividades do [nome do Caso de Uso]
Explicar todos os fluxos do Caso de Uso através de um diagrama de atividades.
Figura X – Diagrama de Atividade do [nome do Caso de Uso]
Diagrama de Sequência do Sistema (DSS) para o [nome do Caso de Uso]
[opcional] Mostrar a seqüência específica de eventos dentro de um caso de uso, os atores externos que interagem diretamente com o sistema, o sistema (como uma caixa-preta) e os eventos do sistema que os atores geram. Para maiores explicações
Figura X – DSS do [nome do Caso de Uso]
Contratos de Operações do Sistema para o [nome do Caso de Uso]
[opcional] Através de contratos, descrever os resultados da execução de operações do sistema em termos de mudança de estado nos objetos do domínio. Para maiores explicações, consulte capítulo 13 do livro do Larman. 
	Operação:
	Nome da operação e parâmetros
	Referências Cruzadas:
	(opcional) Casos de uso nos quais esta operação pode ocorrer.
	Pré-Condições
	Se existir uma ou mais pré-condições, descreva-as aqui.
	Pós-Condições
	Se existir uma ou mais pós-condições, descreva-as aqui.
4.2.5 Priorização de Casos de Uso
De acordo com as prioridades dos requisitos, listar os casos de uso por ordem de prioridade, dividindo-os em iterações.
 
	Incremento
	Data de Entrega
	Nome do Caso de Uso
	1º Iteração
	Informar a data prevista para entrega da implementação dos casos de uso do 1º Iteração. Usar o formato: dd/mm/aaaa
	Listar os nomes dos casos de uso que serão implementados no 1º Iteração.
	2º Iteração
	
	
	Nº Iteração
	
	
Modelo de domínio
Diagrama Geral de Classes Conceitual
Criar um diagrama de classes contendo classes conceituais, seus atributos e associações. Este diagrama é uma visualização dos conceitos do domínio do negócio. É similar a um modelo estático de informação das entidades do domínio. Foca classes conceituais provenientes do mundo real, não classes de software. Para maiores explicações, consulte capítulos 10, 11, 12, 26 e 27 do livro do Larman.
Figura X – Modelo de Domínio
Glossário
Descrever o significado de todos os conceitos identificados no Modelo de Domínio.
	Nome da Classe
	Informar o nome da classe.
	Definição
	Descrever o significado da classe no contexto no negócio.
	Atributos
	Nome
	Definição
	Restrições
	Informar o nome do atributo.
	Descrever o significado do atributo.
	Descrever tipo, tamanho, e outras restrições do atributo.
	
	
	
	Nome da Associação
	Informar o nome da associação.
	Definição
	Descrever o significado da associação no contexto no negócio.
	Classes Associadas
	Informar as classes que fazem parte desta associação.
	Restrições
	Descrever as restrições desta associação. Por exemplo: multiplicidade entre as classes associadas, etc.
	Atributos
	Nome
	Definição
	Restrições
	Informar o nome do atributo.
	Descrever o significado do atributo.
	Descrever tipo, tamanho, e outras restrições do atributo.
	
	
	
Arquitetura do Sistema
Descrever a arquitetura do sistema em camadas. Deve-se utilizar o Diagrama de Implantação para representar a parte física do sistema bem como as suas interações. Quais são, onde se localizam e como se relacionam as camadas do sistema, são as questões que devem ser respondidas aqui. 
Este tópico encerra a visão total do sistema, a partir do próximo item o desenvolvimento passa a ser totalmente incremental.
Diagrama de Camadas 
Faça um diagrama das camadas determinadas para o sistema mostrando o relacionamento entre elas e explicando o funcionamento.
Camada [Nome da Camada]
Descreva a responsabilidade da camada e como é realizada a interface entre esta e as camadas relacionadas. Faça um para cada camada definida para o sistema.
 
Projeto
CRC 
Descreva os cartões CRC (Class-Responsibility-Collaborator Cards) que foram elaborados para descobrir colaborações e responsabilidades das classes que constam no Modelo do Domínio.
{Acrescentar Template}
Realizações de Casos de Uso
Esta seção é responsável pela realização dos casos de uso, ou seja, como serão implementados.
Você deverá detalhar todas as classes de projeto necessárias para realizar um Caso de Uso. 
Caso um Caso de Uso utilize uma classe de outra descrita antes, deve-se relacioná-la da seguinte forma:
“Classe de [Tipo da Classe] [Nome da Classe] descrita no Caso de Uso [Nome do Caso de Uso]”.
[Nome do Caso de Uso]
Classe de Fronteira N [Nome da Classe]
Para descrever cada classe, usar modelo abaixo.
N significa o número da classe caso existam mais de uma, caso contrário, não é necessário.
 
	Nome da Classe
	Informar o nome da classe.
	Definição
	Descrever o significado da classe no contexto de realização do caso de uso da fase de projeto.
Descreva também as responsabilidades da classe (o que ela se compromete a fazer; qual seu papel).
Se for o caso, descrever quais interfaces esta classe está relacionada. Se esta classe se relaciona com outros sistemas através de um protocolo descreva o mais detalhado possível este protocolo.
	Atributos
	Nome
	Definição
	Restrições
	Informar o nome do atributo.
	Descrever o significado do atributo.
	Descrever tipo, tamanho, visibilidade e outras restrições do atributo.
	
	
	
	Métodos
	Nome
	Definição
	Assinatura
	Informar o nome do método.
	Descreva as responsabilidades do método (o que ele se compromete a fazer; qual seu papel).
	Informar a descrição completa da assinatura do método. Incluir: nome do método, visibilidade, descrição dos parâmetros de entrada e saída.
	
	
	
Diagrama de Sequência (DS) do método [nome do Método]
[opcional] Mostrar a seqüência específica das operações a serem realizadas por um método desta classe de fronteira neste respectivo caso de uso. Objetiva mostrar o comportamento dinâmico do método.
Figura X – DS do [nome do Método]
Classe de Entidade N [Nome da Classe]
Para descrever cada classe, usar modelo abaixo.
N significa o número da classe caso existam mais de uma, caso contrário, não é necessário.
	Nome da Classe
	Informar o nome da classe.
	Definição
	Descrever o significado da classe no contexto de realização do caso de uso da fase de projeto.
Descreva também as responsabilidades da classe (o que ela se compromete a fazer; qual seu papel).
	Atributos
	Nome
	Definição
	Restrições
	Informar o nome do atributo.
	Descrever o significado do atributo.
	Descrever tipo, tamanho, e outras restrições do atributo.
	
	
	
	Métodos
	Nome
	Definição
	Assinatura
	Informar o nome do método.
	Descreva as responsabilidades do método (o que ele se compromete a fazer; qual seu papel).
	Informar a descrição completa da assinatura do método. Incluir: nome do método, visibilidade, descrição dos parâmetros de entrada e saída.
	
	
	
Diagrama de Sequência (DS) do método[nome do Método]
[opcional] Mostrar a seqüência específica das operações a serem realizadas por um método desta classe de entidade neste respectivo caso de uso. Objetiva mostrar o comportamento dinâmico do método.
Figura X – DS do [nome do Método]
Classe de Controle N [Nome da Classe]
Para descrever cada classe, usar modelo abaixo.
N significa o número da classe caso existam mais de uma, caso contrário, não é necessário.
	Nome da Classe
	Informar o nome da classe.
	Definição
	Descrever o significado da classe no contexto de realização do caso de uso da fase de projeto.
Descreva também as responsabilidades da classe (o que ela se compromete a fazer; qual seu papel) e a seqüência de controle
(se necessário faça um diagrama de atividades) e os comportamentos relacionados ao negócio.
	Atributos
	Nome
	Definição
	Restrições
	Informar o nome do atributo.
	Descrever o significado do atributo.
	Descrever tipo, tamanho, e outras restrições do atributo.
	
	
	
	Métodos
	Nome
	Definição
	Assinatura
	Informar o nome do método.
	Descreva as responsabilidades do método (o que ele se compromete a fazer; qual seu papel).
	Informar a descrição completa da assinatura do método. Incluir: nome do método, visibilidade, descrição dos parâmetros de entrada e saída.
	
	
	
Diagrama de Sequência (DS) do método [nome do Método]
[opcional] Mostrar a seqüência específica das operações a serem realizadas por um método desta classe de controle neste respectivo caso de uso. Objetiva mostrar o comportamento dinâmico do método.
Figura X – DS do [nome do Método]
Interface Gráfica
A interface gráfica é uma descrição lógica e conceitual de como um ou mais casos de uso
são providos pela interface do usuário, se for o caso, incluindo a interação requerida entre o(s) ator(es) e o sistema. 
Em geral, janelas representam as interfaces gráficas necessárias para entender do ponto de vista macro os requisitos da interface do usuário.
	Requisitos relacionados com a interface gráfica
	
Tabela 3 – Requisitos relacionadas com a interface gráfica
Faça o desenho das interfaces gráficas referenciando os campos com etiquetas como no exemplo abaixo.
Figura 1 - Interface para o(s) Caso(s) de Uso
Diagrama de Classes (DC) de Projeto
Mostrar o comportamento estático através de um diagrama de classes de projeto, contendo todas as classes que realizam este caso de uso. Para melhor visualização do diagrama, poderá suprimir os atributos e métodos de cada classe, porém as associações e multiplicidades devem ser mantidas.
Figura X – DC de Projeto do [nome do Caso de Uso]
Diagrama Geral de Classes de Projeto
Mostrar o comportamento estático através de um diagrama geral de classes de projeto, contendo todas as classes de projeto do sistema. Para melhor visualização do diagrama, poderá suprimir os atributos e métodos de cada classe, porém as associações e multiplicidades devem ser mantidas.
Figura X – Diagrama Geral de Classes de Projeto
Projeto Arquitetural (Pacotes)
[opcional] Este tópico deverá apresentar os pacotes do sistema e o relacionamento entre eles, caso não exista o tópico deve ser suprimido.
Para maiores explicações, consulte: capítulos 30 a 32 do livro do Larman.
Diagrama de Pacotes 
Faça um diagrama dos pacotes do sistema, mostrando o relacionamento entre eles e explicando o funcionamento. Utiliza-se o diagrama de pacotes da UML.
Pacote [Nome do Pacote]
Descreva a responsabilidade do pacote e como é realizada a interface entre este pacote e os pacotes relacionados. Faça um para cada pacote definido para o sistema. Indique qual o Teste será utilizado para validar o pacote.
Modelo de Dados
Esta seção descreve o esquema completo do banco de dados que armazenará os dados do sistema.
Projeto Conceitual do Banco de Dados
[opcional] Deverá criar o Diagrama de Entidade Relacionamento (DER) Normalizado (até a 3FN) e usar modelo ER original de Peter Chen [1]. Este diagrama, na grande maioria das vezes, reflete os mesmos conceitos do mundo real modelados no artefato Modelo de Domínio, portanto, a criação deste diagrama é opcional. 
Referências:
[1] CHEN, Peter P. The Entity-Relationship Model - Toward a Unified View of Data. March 1976. Disponível em: <http://www.csc.lsu.edu/˜chen, acessado em março de 2005.>.
[2] ELMASRI, R; NAVATHE, S. B. Sistemas de Banco de Dados. Addison Wesley, 4a.
edition, 2005.
[3] HEUSER, C. A. Projeto de Bancos de Dados. Editora Sagra Luzzato, 4a. edition, 2001.
[4] KORTH, H. F; SILBERSCHATZ, A. Sistema de Banco de Dados. Makron Books, 2a.
edition, 1995.
[5] SETZER, V. W. Projeto Lógico e Projeto Físico de Bancos de Dados. Editora Gráfica
Formato Ltda, 1986.
Figura X – Projeto Conceitual do Banco de Dados
Projeto Lógico do Banco de Dados
Consiste no mapeamento OO (Modelo de Domínio) para o Modelo Relacional, isto é, produz como artefato o esquema de banco de dados no modelo de dados de implementação do SGBD Relacional. Deverá criar um diagrama contendo as tabelas, seus campos, suas chaves primárias e estrangeiras, índices, etc.
Figura X – Projeto Lógico do Banco de Dados
Dicionário de Dados (Leiaute das Tabelas)
Descrever todas as tabelas que constam no Projeto Lógico.
Leiaute da Tabela [Nome da Tabela]
A notação para descrever o leiaute deve ser a mesma da análise estruturada.
	Nome do campo
	Tipo
	Tamanho
	Indicador de chave
	Comentário
	
	
	
	
	
Tabela 4 – Leiaute da tabela N
Script do Projeto Lógico
Consiste em descrever a DDL, em SQL-2, que será usada para criar o esquema completo do banco de dados do sistema. As palavras-chave da linguagem SQL devem ser escritas em letra maiúscula. Veja exemplo:
/* Criação do Esquema do BD: */
CREATE SCHEMA ER;
/* Criação dos Domínios */
CREATE DOMAIN DomCriterio AS CHAR(1) CHECK
 (DomCriterio = 'P' OR DomCriterio = 'U');
/* Criação da tabela DominioValor */
CREATE TABLE DominioValor 
( 
 Descricao VARCHAR(50) NOT NULL,
 Nome VARCHAR(20) NOT NULL,
 CONSTRAINT PK_DomValor PRIMARY KEY(Nome) 
);
/* Criação da tabela EsquemaBD */
CREATE TABLE EsquemaBD 
( 
 Descricao VARCHAR(50) NOT NULL,
 NomeEsquema VARCHAR(20) NOT NULL,
 CONSTRAINT PK_EsquemaBD PRIMARY KEY(NomeEsquema)
);
/* Criação da tabela PropriedadesEsquema */
CREATE TABLE PropriedadesEsquema 
( 
 Autor VARCHAR(50) NOT NULL,
 DtAtualizacao DATE NOT NULL,
 DtCriacao DATE NOT NULL,
 NomeEsquema VARCHAR(20) NOT NULL,
 Versao VARCHAR(20) NOT NULL,
 CONSTRAINT PK_PropEsquema PRIMARY KEY(NomeEsquema,Versao),
 CONSTRAINT FK_PropEsquema FOREIGN KEY(NomeEsquema) REFERENCES EsquemaBD ON DELETE CASCADE ON UPDATE CASCADE
);
/* Criação da tabela Relacionamento */
CREATE TABLE Relacionamento 
( 
 NomeConjunto VARCHAR(20) NOT NULL,
 NomeEsquema VARCHAR(20) NOT NULL,
 TipoRelacionamento DomTipoRelac NOT NULL,
 CONSTRAINT PK_Relacionamento PRIMARY KEY(NomeConjunto,NomeEsquema),CONSTRAINT FK_RelacConjunto FOREIGN KEY(NomeEsquema,NomeConjunto) 
 REFERENCES Conjunto ON DELETE RESTRICT ON UPDATE CASCADE,
 CHECK (NOT EXISTS (SELECT * FROM PAPEL 
 GROUP BY NomeEsquema, NomeRelacionamento
 HAVING COUNT(*) < 2)
 ) 
);
Testes
Este tópico deverá apresentar os tipos de testes a serem aplicados, os recursos e os procedimentos necessários para a execução do teste do componente em questão.
Teste de Stress
Um tipo de teste da confiabilidade. Seu foco é assegurar que o sistema funciona como pretendido quando circunstâncias anormais são encontradas. O teste de stress pode incluir memória insuficiente, serviços não disponíveis ou recursos compartilhados escassos. Tipicamente, estes testes são executados para determinar quando falhas e m um grande volume e/ou dados.
Inclua se necessário uma breve descrição sobre a aplicação do teste; o que será afetado ou influenciado por este documento.
Inclua uma tabela para cada teste a ser realizado.
	Responsável: 
Inclua o nome da pessoa responsável pela execução do teste
	Início: 
Inclua a data e a hora de início do teste no formato dd/mm/aa – hh:mm
	Final:
Inclua a data e a hora final do teste no formato dd/mm/aa – hh:mm
	Recursos necessários:
Inclua a especificação de hardware e software da(s) máquina(s) envolvida(s) no teste. É interessante desenvolver um programa de teste especialmente para este fim, o nome do programa poderá ser o mesmo do componente a ser testado acrescido da palavra “Tester”. 
	Hardware
	Configuração
	Software
	
	
	
	
	
	
	Procedimentos:
Descreva os procedimentos para a execução do teste.
	Resultados:
Descreva os resultados obtidos ao final do teste.
Teste de Funcionalidade
Seu foco é verificar se o componente funciona como pretendido. 
Inclua se necessário uma breve descrição sobre a aplicação do teste; o que será afetado ou influenciado por este documento.
Teste de funcionalidade do Fluxo de Evento Principal
Para executar o teste utiliza-se o fluxo de evento principal, completando a tabela abaixo:
	Responsável:
Inclua o nome da pessoa responsável pela execução do teste
	Data:
Inclua a data de execução do teste no formato dd/mm/aa
	Recursos necessários:
Inclua a especificação de hardware e software da(s) máquina(s) envolvida(s) no teste. 
O programa de teste deve ser incluído na coluna relacionada ao Software.
	Hardware
	Configuração
	Software
	
	
	
	
	
	
	Procedimentos:
Descreva os procedimentos para a execução do teste. 
	Resultados:
Descreva os resultados obtidos ao final do teste.
Tabela 5 - Teste de funcionalidade do Fluxo de Evento Principal
Teste de funcionalidade do Fluxo de Evento Alternativo [N]
Para executar o teste utiliza-se o fluxo de evento alternativo [1 a n], onde para cada fluxo alternativo cria-se uma nova tabela:
	Responsável:
Inclua o nome da pessoa responsável pela execução do teste
	Data:
Inclua a data de execução do teste no formato dd/mm/aa
	Recursos necessários:
Inclua a especificação de hardware e software da(s) máquina(s) envolvida(s) no teste. 
O programa de teste deve ser incluído na coluna relacionada ao Software.
	Hardware
	Configuração
	Software
	
	
	
	
	
	
	Procedimentos:
Descreva os procedimentos para a execução do teste. 
	Resultados:
Descreva os resultados obtidos ao final do teste.
Tabela 6 - Teste de funcionalidade do Fluxo de Evento Alternativo [N]
Teste de funcionalidade do Fluxo de Evento de Exceção [N]
Para executar o teste utiliza-se o fluxo de evento exceção [1 a n], onde para cada fluxo exceção cria-se uma nova tabela:
	Responsável:
Inclua o nome da pessoa responsável pela execução do teste
	Data:
Inclua a data de execução do teste no formato dd/mm/aa
	Recursos necessários:
Inclua a especificação de hardware e software da(s) máquina(s) envolvida(s) no teste. 
O programa de teste deve ser incluído na coluna relacionada ao Software.
	Hardware
	Configuração
	Software
	
	
	
	
	
	
	Procedimentos:
Descreva os procedimentos para a execução do teste. 
	Resultados:
Descreva os resultados obtidos ao final do teste.
Tabela 7 - Teste de funcionalidade do Fluxo de Evento Exceção [N]
CONCLUSÃO / RECOMENDAÇÕES
Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla.
Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla Blablabla.
�
REFERÊNCIAS
SOBRENOME, Nome do autor. Título da obra. Disponível em: <http://www.enderecoeletronico.com.br>. Acesso em: data do acesso.
SOBRENOME, Nome do autor. Título da obra. Cidade: Editora, ano.
SOBRENOME, Nome do autor. Título da obra. Disponível em: <http://www.enderecoeletronico.com.br>. Acesso em: data do acesso.
...
SOBRENOME, Nome do autor. Título da obra. Cidade: Editora, ano.
(Deverá ser colocado seguindo as normas da ABNT e ordenado lfabeticamente).
�
APÊNDICES
Apêndice A – Título do Apêndice
�
Apêndice B – Título do Apêndice
�
ANEXOS
Anexo A – Título do Anexo
�
Anexo B – Título do Anexo