UNIVERSIDADE FEDERAL DO PIAUÍ – UFPI

UNIVERSIDADE ABERTA DO PIAUÍ – UAPI

BACHARELADO DE SISTEMAS DE INFORMAÇÃO

MONOGRAFIA

DESENVOLVIMENTO DE SOFTWARE

DESENVOLVIMENTO DE UM SISTEMA DE CADERNETA ONLINE PARA

UNIVERSIDADE ABERTA DO PIAUÍ – UAPI

Lucier Ferreira Lima

URUÇUÍ – PIAUÍ
2012
 LUCIER FERREIRA LIMA

DESENVOLVIMENTO DE SOFTWARE

DESENVOLVIMENTO DE UM SISTEMA DE CADERNETA ONLINE PARA

UNIVERSIDADE ABERTA DO PIAUÍ – UAPI

Monografia submetida ao Curso de Bacharelado de

Sistemas de Informação como requisito parcial para
obtenção de grau de Bacharel em Sistemas de
Informação.

Orientador: Prof. Msc. Jefferson Fontinele da Silva

URUÇUÍ – PIAUÍ
2012
 Desenvolvimento de software

Desenvolvimento de um sistema de caderneta online para a Universidade Aberta do

Piauí – UAPI

Lucier Ferreira Lima

Monografia ____________________________________como exigência parcial para

a obtenção do grau de Bacharel em Sistemas de Informação.

Uruçuí – PI, 10 de Janeiro de 2012

________________________________

Prof,

________________________________

Prof,

________________________________

Prof,
Dedico este trabalho a minha família,
primeiramente, pelo grande apoio, aos meus
professores pelo grande conhecimento que
me passaram durante estes anos e a todos
os meus amigos que sempre me
incentivaram ao estudo.
AGRADECIMENTOS

Este trabalho não poderia ter sido elaborado e escrito sem as contribuições valiosas
de muitas pessoas deixo aqui meus agradecimentos.

Ao meu orientador Prof. Msc. Jefferson Fontinele da Silva, pela paciência e

confiança, mesmo nos momentos em que não correspondi as suas
expectativas. A sua orientação foi fundamental para que os obstáculos da
distância e falta de tempo fossem vencidos, ao orientador Juan Morysson pela ajuda
com o desenvolvimento do software e a todos os tutores do curso de sistemas de
Informação pelo conhecimento transmitido ao longo do curso.

Especilamente ao tutor Thiego Ramos por ter despertado meu interesse em propor
um sistema de diário de classe online para a instituição a qual faço parte, agradeço
também por seu tempo, paciência, confiança, ensinamentos transmitidos e
principlamente por sua orientação na área de programação de softwares.
“Se o mestre for verdadeiramente sábio, não convidará o
aluno a entrar na mansão de seu saber, e sim, estimulará
o aluno a encontrar o limiar da própria mente.”
(Khalil Gibran - poeta libanês)
 RESUMO

Este trabalho tem por objetivo o desenvolvimento de um sistema de

Caderneta Online para a Universidade Aberta do Piauí – UAPI. Foi proposto o
desenvolvimento de um software que utilize a plataforma web, para o
desenvolvimento deste, utilizaram-se os conceitos da Engenharia de Software e
do paradigma de orientação a objetos. Faz parte deste trabalho o
levantamento e análise de requisitos, a definição da arquitetura do software, a
implementação e a abordagem relativa ao uso de tecnologias atuais como
Struts2, Hibernate, Java, JSPs, entre outras. A Unified Modeling Language
(UML) foi fundamental para documentar o desenvolvimento do software e mostrar de
maneira clara e consistente o funcionamento do sistema através de seus principais
diagramas, como o diagrama de casos de uso, o diagrama de classes e o diagrama
de seqüência. O sistema foi desenvolvido seguindo o modelo de software em
três camadas. Utilizou-se o framework Struts2 para implementação do padrão
Model-View-Controller (MVC). Padrões de projeto também foram aplicados. O
mapeamento objeto-relacional foi implementado com o uso do framework
Hibernate. Este trabalho utilizou padrões e tecnologias amplamente empregados
em um ambiente de desenvolvimento de software. O sistema foi desenvolvido
parcialmente. Foram implementados vários diagramas UML, evidenciando a
potencialidade desse projeto. Desta forma, este trabalho mostra que é viavel a
construção de sistemas de diário de classe online por meio dos artefatos
apresentados.

Palavras Chave: caderneta online, UAPI, sistema web, UML, emgenharia de

software, JSP, Java, Struts, Hibernate.
 ABSTRACT

This work aims at developing a system for the Online Handbook to Universidade
Aberta do Piaui -UAPI. It was proposed to develop software that uses a web
platform for the development of this, it used the concepts of software
engineering and object-oriented paradigm. Part of this work a survey and analysis of
requirements, definition of software architecture, implementation and approach to
the use of current technologies like Struts2, Hibernate,Java, JSPs, among
others. The Unified Modeling Language (UML) was essential to document the
development of software and show with clearness and consistency operation of the
system through its main diagrams, such as the Usecase diagram, Class diagram and
Sequence diagram. The system was developed following the model of software into
three layers. It used the Struts2 framework for implementing the Model-View-
Controller (MVC). Design standards were also applied. The object-relational
mapping was implemented using the Hibernate framework. This study
used standards and technologies widely used in a software development
environment. The system was developed in part. It implemented a number of UML
diagrams, showing the potential of this project. Thus, this work shows that it
is viable to build systems gradebook online through the displayed artifacts.

Keywords: Online Handbook, UAPI, web system, UML, software emgenharia, JSP,
Java, Struts, Hibernate
LISTA DE ILUSTRAÇÕES

Figura 1 – Evolução do processo PSP ................................................................. 23

Figura 2 – Especificações da linguagem java ...................................................... 28

Figura 3 – Componentes java EE......................................................................... 29

Figura 4 – Ciclo de vida de um servlet ................................................................. 30

Figura 5 – Ciclo de vida de um JSP ..................................................................... 31

Figura 6 – Framework Struts2 .............................................................................. 36

Figura 7 – Implementação do padrão fachada ..................................................... 41

Figura 8 – Estrutura de diretórios do projeto ........................................................ 46

Figura 9 – Arquivo web.xml .................................................................................. 47

Figura 10 – struts.xml ........................................................................................... 48

Figura 11 – LoginAction.java ................................................................................ 49

Figura 12 – Tela inicial do sistema ....................................................................... 50

Figura 13 – Tela principal do sistema................................................................... 51

Figura 14 – Tela para manutenção dos dados do usuário ................................... 51

Figura 15 – Diagrama de classes ......................................................................... 57

Figura 16 – Diagrama de caso de uso ................................................................. 58

Figura 17 – Caso de uso cadastrar usuário ......................................................... 59

Figura 18 – Diagrama de atividade manter usuário.............................................. 60

Figura 19 – Diagrama de sequência cadastrar usuário ........................................ 61

Figura 20 – Diagrama de sequência consultar de usuário ................................... 62

Figura 21 – Diagrama de sequência alterar usuário............................................. 63

Figura 22 – Caso de uso excluir usuário .............................................................. 64

Figura 23 – Consulta de usuário .......................................................................... 67

Figura 24 – Resultado consulta usuário ............................................................... 68

Figura 25 – Visualização dos dados do usuário ................................................... 69

Figura 26 – Alterar dados do usuário ................................................................... 70

LISTA DE TABELAS

Tabela 1 – Limmites do postgre ........................................................................... 33

Tabela 2 - Requisitos funcionais ......................................................................... 44

Tabela 3 – Requisitos não funcionais................................................................... 45

Tabela 4 – Regras de negocios............................................................................ 45

Tabela 5 – Caso de uso realizar login .................................................................. 65

Tabela 6 – Caso de uso manter dados do usuário ............................................... 66

LISTA DE ABREVIATURAS E SIGLAS

JSP Java Server Pages

JDBC Java Database Connectivity

MVC Model-view-controller

IDE Integreted Development Environment

PSP Personal Software Process

JEE Java Enterprise Edition

JSE Java Standard Edition

EJB Enterprise Java Beans

JNDI Java Naming and Directory Interface

XML Extensible Markup Language

ORM Mapeamento objeto-relacional

LGPL Lesser General Public License

SGBD Sistema Gerenciador de Banco de dados

SQL Structured Query Language

API Application Programming Interface

JTA Java Transaction API

HQL Hibernate Query Language

UML Unified Modeling Language

CASE Computer-Aided Software Engineering

 SUMÁRIO

1. INTRODUÇÃO .................................................................................................... 14
2. JUSTIFICATIVA .................................................................................................. 19
3. METODOLOGIA ................................................................................................. 19
4. REVISÃO LITERÁRIA ......................................................................................... 20
4.1 DESENVOLVIMENTO DE SOFTWARE ........................................................ 20
4.2 LEVANTAMENTO DE REQUISITOS............................................................. 20
4.3 METODOLOGIA DE DESENVOLVIMENTO.................................................. 22
4.3.1 METODOLOGIA PSP ........................................................................ 22
4.3.2 EVOLUÇÃO DO PSP......................................................................... 23
4.4 TESTE DE SOFTWARE ................................................................................ 24
4.4.1 TESTE DE UNIDADE ........................................................................ 26
5. FERRAMENTAS DE DESENVOLVIMENTO DE SOFTWARE ............................ 27
5.1 JAVA ............................................................................................................. 27
5.1.1 JAVA EE ............................................................................................ 28
5.1.2 SERVLETS ........................................................................................ 29
5.1.3 JSP .................................................................................................... 30
5.1.4 JSP EXPRESSION LANGUAGE ....................................................... 31
5.2 BANCO DE DADOS RELACIONAL ............................................................... 32
5.2.1 APLICABILIDADE E ATUALIDADE DO POSTGRE ........................... 33
5.2.2 TIPOS DE DADOS DO POSTGRE .................................................... 33
5.2.2.1 TIPO DE DADOS: CARACTERE ................................................. 33
5.2.2.2 TIPO DE DADOS: NUMÉRICOS.................................................. 34
5.2.2.3 INTEIROS .................................................................................... 34
5.2.2.4 NÚMEROS DE PRECISÃO FIXA ................................................. 34
5.2.2.5 TIPOS DE PONTO FLUTUANTE ................................................. 34
5.2.2.6 PSEUDOS TIPOS SERIAIS ......................................................... 35
5.3 TOMCAT ....................................................................................................... 35
5.4 STRUTS 2 ..................................................................................................... 36
5.5 HIBERNATE .................................................................................................. 38
5.6 ECLIPSE ....................................................................................................... 39
5.7 ASTAH UML .................................................................................................. 39
5.8 PADRÃO DE PROJETO................................................................................ 40
5.8.1 PADRÕES ESTRUTURAIS ............................................................... 40
5.8.1.1 FACHADA .................................................................................... 40
5.9 ANÁLISE DO SISTEMA ................................................................................ 42
6. APRESENTAÇÃO DO SISTEMA ........................................................................ 46
7. CONCLUSÃO ..................................................................................................... 52
8. REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 54

ANEXOS ................................................................................................................... 56
 14

1 INTRODUÇÃO

Historicamente o desenvolvimento de aplicações tem se mostrado uma tarefa

bastante desafiadora e grande parte dos esforços da ciência da computação
destinou-se a resolver problemas encontrados nesta área. Em termos de
tecnologia, muita coisa mudou desde o tempo em que a programação era feita
exclusivamente em linguagem de máquina, onde o desenvolvedor necessitava
de conhecimentos relativos até mesmo sobre a arquitetura do processador utilizado
e os recursos oferecidos para a programação eram bastante limitados.

A primeira grande mudança foi a criação das linguagens de programação,

onde a forma de escrever a solução a ser executada pela máquina teve seu nível de
abstração elevado, trazendo as soluções para um formato mais próximo da
linguagem humana. Com a utilização de uma linguagem de programação, a
implementação de aplicações passou a contar com recursos de níveis mais altos
e a tarefa de transformação dessa solução em algo que o computador
pudesse executar passou a ser uma tarefa automatizada através de ferramentas de
tradução.

As primeiras linguagens de programação eram bastante limitadas, tanto

em nível de abstração como em recursos oferecidos, mas ainda assim,
mostravam-se extremamente mais amigáveis que a programação em linguagem
de máquina.

A programação de computadores passou a ser mais popularizada,

permitindo que pessoas sem maiores conhecimentos sobre o funcionamento de
computadores pudessem construir soluções computacionais. Mesmo com as
linguagens de programação tendo atingido níveis elevados em relação à facilidade
de uso, aumentando bem mais a produtividade na construção de soluções
computacionais; a construção de software continuou sendo uma tarefa altamente
desafiadora e problemática, o que direcionou a evolução das linguagens de
programação para outro rumo, ou seja, foram propostas mudanças no
paradigma utilizado nas linguagens de programação.
 15

Agora as evoluções estavam voltadas para a forma conceitual como os

programadores modelavam as soluções de problemas do mundo real. Assim
nasceu o paradigma da programação estruturada e tal modelo consite na técnica
de otimização da concepção lógica de um programa. Esse método parte do principio
que qualquer programa, ainda que complexo, possa ser composto por pequenas
estruturas padrão, de fácil concepção e análise, e posteriormente o paradigma
orientado a objetos, onde implementa-se um conjunto de classes que definem os
objetos presentes no sistema. Cada classe define um comportamento(definido nos
métodos) e estados possíveis(atributos) de seus objetos, assim como o
relacionamento com outros objetos. Com a orientação a objetos, ficou mais
natural a modelagem de soluções do mundo real no mundo computacional,
pois este paradigma representa uma forma mais natural de implementar
componentes de software.

Com a utilização de linguagens orientadas a objetos alcançamos níveis

de abstração bem elevados nas linguagens de programação, mas outras evoluções
foram necessárias, a fim de ajustar os recursos oferecidos pelas tecnologias de
desenvolvimento de software às necessidades do mercado com o surgimento
das redes de computadores e principalmente com a Internet.

Num primeiro momento, podemos imaginar antes do uso em larga

escala da Internet como ferramenta de integração comercial, as organizações
preocupavam-se apenas com seus controles internos, assim foram desenvolvidas
diversas aplicações para atender tais necessidades. Diante dessa situação foi criada
a arquitetura de aplicações denominada de Cliente/Servidor, onde a solução de
software foi dividida em duas camadas. Ttipicamente, uma camada
desempenhava a tarefa de interagir com o usuário da aplicação e executar regras de
negócios e a outra era responsável pelo gerenciamento dos dados.

A arquitetura cliente servidor mostrou-se bastante adequada para a

solução de problemas dentro do escopo das organizações. Assim, diversas
ferramentas surgiram baseadas em tecnologias que implementavam a arquitetura
Cliente/Servidor e algumas delas atingiram grande maturidade e facilidade de
 16

uso. Os requisitos para o desenvolvimento de aplicações internas às

organizações eram adequadamente atendidos por tais ferramentas.

Recentemente, com a crescente utilização da Internet como ferramenta na

realização de transações comerciais, as necessidades computacionais das
organizações, mais uma vez, foram expandidas; pois na era da Internet e da
economia da informação as organizações tiveram que implementar soluções
que ultrapassavam suas fronteiras, permitindo interação com o meio externo.
Assim, as tecnologias de desenvolvimento de software tiveram que novamente
evoluir a fim de atender a dimensão atingida dos requisitos de soluções
computacionais exigidos pelas organizações nessa nova economia.

Ficou evidente que a arquitetura Cliente/Servidor, a qual era

perfeitamente adequada para a solução de problemas internos à organização, não
era adequada para esse novo ambiente, a Internet, o qual possui características e
requisitos bastante diferenciados. Diante dessas novas necessidades: interligar-se
em rede, interação eficiente (com clientes, funcionários, fornecedores e
parceiros), integração com sistemas legados, regras de negócios mais
complexas e integração com diversos tipos de software clientes, as
tecnologias de desenvolvimento de aplicações evoluíram da arquitetura
Cliente/Servidor para a arquitetura Multicamadas .

Na arquitetura Multicamadas os componentes de software são divididos

em camadas, tipicamente tendo-se três camadas denominadas: Camada Cliente
(responsável pela interface com o cliente), Camada de Regra de Negócio (executa a
lógica das transações) e a Camada de Dados (realiza a persistência e gerência dos
dados).

A arquitetura Multicamadas foi evoluindo e diversos fabricantes de

soluções criaram ferramentas com o objetivo de facilitar o desenvolvimento de
aplicações nessa arquitetura. A complexidade das aplicações distribuídas,
aplicações as quais rodam em vários sistemas de computador ao mesmo tempo,
geralmente como processos ou filas, aumentou em relação à arquitetura
Cliente/Servidor.
 17

Esse aumento da complexidade se deu principalmente pela própria

natureza das aplicações distribuídas. As aplicações distribuídas utilizam processos
executados em máquinas distintas que colaboram na resolução de um problema
comum.

Assim nasceu a necessidade de uma padronização da tecnologia,

utilizada na implementação de aplicações multicamadas/distribuídas. Inserido em
tal cenário as tecnologias de desenvolvimento de software mais uma vez tivram que
evoluir, assim nasceu a plataforma de desenvolvimento Java 2 Enterprise Edition –
J2EE, sob a forma de um conjunto de padrões, serviços e uma plataforma de
desenvolvimento, com a finalidade de padronizar o desenvolvimento e a
distribuição de aplicações multicamadas/distribuídas.

Quanto mais uma organização puder usar padrões para se conectar de

modo eficaz, maior a eficácia com que poderá participar no mercado e mais
competitiva ela será na economia em rede. A adoção em grande escala de
uma plataforma para o desenvolvimento de aplicações ajudará a criar um mercado
grande e diversificado para bens e serviços relacionados.

O objetivo deste trabalho é desenvolver para a UNIVERSIDADE ABERTA DO

PIAUI - UAPI, utilizando a plataforma J2EE um sistema de diário de classe online
que tente se aproximar ao máximo da realidade da universidade.

A hipótese deste trabalho é que utilizando a plataforma Java J2EE,

frameworks MVC como Struts2, banco de dados relacional é possível desenvolver
um sistema baseado em objetos distribuidos e multicamada, a plataforma permite ao
desenvolvedor focar na lógica de negócios deixando os detalhes de infra-estrutura
para o ambiente de execução que dá suporte a J2EE, também apresenta vantagens
importantes como independência de plataforma (Sistema Operacional e Hardware),
característica inerente da linguagem Java, independência de implementação, isto é,
uma característica da especificação que garante o desenvolvimento e implantação
em qualquer ambiente que forneça suporte e esteja certificado à plataforma,
sistemas escaláveis. A arquitetura da plataforma J2EE permite o desenvolvimento
de aplicações divididas em camadas com funcionalidades específicas. Uma
 18

aplicação Web típica seria composta por uma camada de apresentação, geralmente
baseada em Servlets ou JSP, que por sua vez obtém e fornece dados para a
camada de negócios, persistindo dados através de objetos de persistência. Esta
camada intermediária acessa a camada de informação, composta por bases de
dados relacionais, aplicações legadas, sistemas ERP, entre outros.`
 19

2 JUSTIFICATIVA

Como justificativa para o projeto de Desenvolvimento de um Sistema de diário

de classe web para a Universidade Aberta do Piauí – UAPI temos:

• Desenvolvimento de um sistema que fará parte do projeto UAPI;

• Proporcionar um modelo de sistema que possa ser modificado,

distribuído e implementado de acordo com a necessidade da instituição;

• Proporcionar o acesso ao sistema de Caderneta Online através da

web.

3 METODOLOGIA

Para o desenvolvimento deste sistema realizou-se o levantamento de

requisitos junto aos tutores para se definir as tarefas que o sistema irá desenpenhar.

A implementação do projeto será feita utilizando a plataforma java, mais

especificamente J2EE - Java 2 Enterprise Edition (JSP, Servlets e JDBC).
Java é uma linguagem de programação orientada a objetos, diferentemente das
linguagens convencionais, que são compiladas para código nativo, a linguagem Java
é compilada para um bytecode que é executado por uma máquina virtual, o que faz
com que ela seja multiplataforma.

Aplicando o modelo MVC para separar o tratamento dos dados de sua

apresentação. Para implementar o modelo MVC serão utilizado os frameworks
Struts2 e hibernate3. Um framework é um artefato de código que provê
componentes prontos(ex.: classes) que podem ser reutilizadas mediante
configuração, composição ou herança.
 20

A construção do código será feita utilizando o IDE eclipse 3.7.1. O eclipse é

um IDE gratuito, totalmente desenvolvido usando tecnologia java, esta IDE de
desenvolvimento foi escolhida pela sua facilidade de uso e no seu desenvolvimento.

As ferrmanetas a serem utilizadas no desenvolvimento do projeto seguem

listadas abaixo:
• IDE eclipse indigo JEE
• postgreSQL 9.0
• Astha UML community
• iReport 4.0
• java sdk 6

4 REVISÃO LITERÁRIA

4.1 Desenvolvimento de software

Na computação, o desenvolvimento de software é o ato de elaborar e

implementar um sistema computacional, isto é, transformar a necessidade de um
utilizador ou de um mercado em um produto de software. Também é entendido
como a aplicação dos processos da engenharia de software combinados com a
pesquisa das necessidades do produto para desenvolver software.

4.2 Levantamento de requisitos

A Análise de Requisitos é a primeira atividade técnica no desenvolvimento do

software, e pode ser entendida como responsável por definir os serviços que um
sistema deve realizar, sua interface com os demais elementos e sob quais restrições
o sistema deve operar. Os requisitos dos sistemas devem estabelecer o que o
sistema deve fazer ao invés de como isto será feito.

O termo Análise de Requisitos ou Engenharia de Requisitos, segundo Stokes

(2003 apud FISCHER, 2001, p.74), refere-se a uma coleção dos processos de
extração, especificação, verificação e validação, apresentados na seqüência:
 21

• A extração de requisitos é o exercício de agrupar as informações afim de

verificar exatamente o que o cliente ou usuário está requerendo.

• A especificação refere-se tanto ao processo como ao resultado deste

processo. Resulta em um documento denominado Especificação dos Requisitos, em
que toda a informação obtida sobre o processo está reunida. É quando ocorre o
maior esforço de análise, o fluxo dos dados é avaliado, as funções definidas e
detalhadas, o comportamento do software entendido no contexto do ambiente e as
restrições do projeto são incluídos.

• A verificação é feita para assegurar que este documento não contém

inconsistências, uma vez que os requisitos não devem ser conflitantes entre si.

• A validação preocupa-se em assegurar que o documento descreve com

precisão o sistema que o cliente deseja, incluindo todas as funcionalidades e
restrições impostas por ele.

Segundo Sommerville (2003, p. 82), o termo definição de requisitos serve

para a fase inicial do processo, quando os requisitos são estabelecidos ao cliente e
correspondem a macro especificações de serviços que o sistema deve realizar.
Deve estar descrito em um documento em linguagem natural, acrescido de alguns
diagramas. Já o termo especificação de requisitos é usado no outro extremo do
processo, quando os requisitos estão detalhadamente definidos e um documento
preciso é gerado, também conhecido por Especificação Funcional. No final de uma
especificação um Documento de Requisitos de software é montando. Esse
documento une a definição e a especificação dos requisitos.

No desenvolvimento do processo alguns papéis estão envolvidos: os

requerentes, os facilitadores e os implementadores. Os requerentes são os clientes
e usuários, e representam as pessoas que precisam do sistema. Os facilitadores são
analistas e seu papel é o de desenvolver, ao longo do processo, as técnicas de
extração, especificação, verificação e validação, numa descrição precisa do sistema
que o requerente quer. Já os implementadores são engenheiros, projetistas e
gerentes de projeto, que elaboram o sistema base do processo que efetivamente
constroem os sistemas com base no documento de requisitos e no processo do
software.
 22

4.3 Metodologia de desenvolvimento

As metodologias de desenvolvimento de software servem para não tornar a

tarefa complexa por natureza, um verdadeiro caos. O problema é que, dependendo
do projeto, os métodos tradicionais podem deixar os desenvolvedores amarrados a
requisitos desatualizados, que não correspondem às reais necessidades do cliente.
Em mercados altamente competitivos, ou em momentos de crise econômica, a
flexibilidade e a facilidade de mudar o rumo são qualidades muito valiosas para
serem deixadas de lado.

4.3.1 Metodologia PSP

O PSP (Personal Software Process) é um modelo de melhoria evolutiva

desenvolvido por Humphrey (1995) para o nível individual, de modo a fornecer um
mecanismo de auto-aprendizagem através da experiência, medida e feedback. Este
mecanismo habilita os engenheiros de software a entenderem as suas fraquezas e
potencialidades bem como a melhorar a sua capacidade e desempenho.

O PSP pode ser aplicado à maioria das tarefas de engenharia de software

dado que a sua estrutura é simples e independente da tecnologia - não prescreve
linguagens, ferramentas ou métodos de concepção específicos.

Os conceitos de processo do PSP são apresentados numa série de passos.

Cada passo do PSP, como ilustrado na figura 1, inclui todos os elementos dos
passos anteriores mais os adicionados. A introdução destes conceitos ajuda os
engenheiros a aprenderem métodos de disciplina pessoal.

PSP0 - Processo "Baseline" Pessoal. Estabelece uma "baseline" que inclui

algumas medidas básicas. Esta "baseline" fornece uma base consistente para medir
o progresso e uma fundação sobre o que melhorar. O PSP0 corresponde ao
processo usado correntemente para escrever software, mas engrandecido de modo
a fornecer medidas de tempo e defeitos. O PSP0.1 introduz a codificação
standard, a medida de tamanho e uma proposta de melhoria do processo. Esta
proposta é uma forma de fornecer um caminho estruturado para registar problemas,
experiências e sugestões de melhoria do processo.
 23

Figura 1.: Figura.: Evolução do processo PSP [adaptado de Humphrey (1995, 1996, 2000)].

4.3.2 Evolução do PSP

PSP1 - Processo de Planejamento Pessoal. O PSP1 adiciona passos de

planejamento ao PSP0. O incremento inicial adiciona um relatório de teste e
estimativa de dimensão e recursos. No PSP1.1, é introduzido o planejamento de
tarefas e de calendarização.

PSP2 - Gestão da Qualidade Pessoal. O PSP2 adiciona técnicas de revisão

ao PSP1 para ajudar a encontrar defeitos precocemente, ou seja, quando a sua
correção é menos despendiosa. O PSP2.1 estabelece critérios de perfeição da
concepção e examina várias verificações destas e técnicas de conformidade.

PSP3 - Processo Cíclico Pessoal. Até aqui, o PSP concentra-se num

processo linear simples para construção de programas pequenos. Enquanto isso
funciona bem para tais projetos, não acontece o mesmo para projetos grandes. O
PSP3 efetiva a escala para programas grandes pela divisão destes em módulos
pequenos, programados de um modo cíclico de acordo com o PSP2.1, e com
posterior ligação e integração.

Uma das razões que levou Humphrey a desenvolver o modelo PSP deve-se
ao fato da aplicação dos princípios do modelo SW-CMM ter encontrado muitas
dificuldades ao nível de pequenos grupos de engenheiros de software. O SW-CMM
 24

é um modelo de melhoria do processo focado na organização que potencia e facilita

o bom trabalho, mas não o garante.

Portanto, os engenheiros têm de usar práticas pessoais efetivas [Humphrey

1996]. O modelo PSP apresenta princípios de melhoria do processo, ao nível dos
engenheiros individuais, associados à produção eficiente de produtos de qualidade.
Para terem um bom desempenho, os engenheiros necessitam do suporte de um
ambiente disciplinado, o que significará que o PSP será mais efetivo em
organizações próximas ou acima do estágio 2 do modelo SW-CMM.

O PSP e o SW-CMM suportam-se mutuamente. O SW-CMM proporciona o

suporte de ambiente ordenado que os engenheiros necessitam para realizarem
trabalho superior; e o PSP equipa os engenheiros de forma a realizarem trabalho de
alta qualidade e participa na melhoria organizacional do processo. Por conseguinte,
um dos objetivos do PSP é expandir a grandes programas a produtividade dos
engenheiros tipicamente experientes no desenvolvimento de pequenos programas.

4.4 Teste de software

“Engenharia de Software é uma disciplina que se ocupa com todos os
aspectos da produção de software, desde o início da especificação dos
requisitos, até a fase de manutenção desse sistema” (SOMMERVILLE, 2003). A
Engenharia de Software contém várias etapas, cada uma delas abrange
métodos, ferramentas e procedimentos para o desenvolvimento do software.
Dentre estas etapas, segundo Pressman (2002), encontra-se o ciclo de vida de um
software, que consiste em atividades realizadas durante todo o desenvolvimento do
sistema. Dentre estas atividades, está a atividade de teste.

A qualidade de produtos de software está fortemente relacionada à

qualidade do processo de software, ou seja, para se obter um produto final com
uma boa qualidade, “é necessário garantir esta qualidade desde a primeira atividade
do ciclo de vida, até a fase de manutenção do sistema” (ROCHA, 2001).
Qualidade de software, segundo Rezende (2002), “é a conformidade com os
requisitos, ou a adaptabilidade ao uso, adequação ao cliente e/ou usuário”. É
ainda, atendimento perfeito de forma confiável (sem defeitos), acessível (baixo
 25

custo), segura e no tempo certo, às necessidades do cliente. Para Rocha (2001),

qualidade de software pode ser definida como um conjunto de características
que devem ser alcançadas em um determinado grau para que o produto
atenda às necessidades de seus usuários.

A qualidade do software está fortemente ligada à qualidade dos testes.

“De todo o esforço gasto para a realização de um projeto, 50% é gasto nesta
atividade” (PRESSMAN, 2006). “Por esse motivo, a preocupação com os testes deve
ocorrer ainda nas fases iniciais do projeto, partindo de um bom planejamento
e controle, a fim de evitar perdas de recursos e atrasos no cronograma”
(DIAS NETO e TRAVASSOS, 2005). Além disso, o teste é uma fonte importante
de feedback e fornece uma base para a interação com os participantes de todo o
projeto do software.

Teste, segundo Pressman (2006), “é um conjunto de atividades que

podem ser antecipadamente planejadas e conduzidas sistematicamente, com o
objetivo de encontrar erros, defeitos e/ou falhas no sistema”. “É importante
diferenciar os conceitos de defeito, erro e falha” (MALDONADO, 2004).

Defeito: incapacidade de algum componente em realizar a função à qual foi

projetado.

Falha: é a incapacidade de o sistema executar suas funções requeridas

dentro das exigências especificadas. Não existe falha se o programa não tem
defeito.

Erro: é a manifestação de uma falha no sistema, causando diferenças das

respostas apresentadas com as esperadas. Nem todas as falhas causarão erros no
programa.

Os testes de software são planejados e executados durante todo o

desenvolvimento do software. Sendo assim, os componentes individuais do
sistema devem ser testados, bem como a sua integração. Após executar
esses testes, é preciso realizar testes de sistema e aceitação. As estratégias de
 26

teste é o passo a passo da atividade de teste. Para cada estratégia de teste,

podem ser empregadas diversas técnicas.

A essência da atividade de teste consiste em projetar casos de testes

onde sejam descobertos diferentes tipos de erros em pouco tempo e esforço.
Um caso de teste é composto por um conjunto de entradas possíveis em um
programa que gera um conjunto esperado de saídas.

4.4.1 Teste de unidade

O teste de unidade é o teste que verifica o módulo, ou seja, a menor

unidade de projeto de software. A vantagem deste teste é a “possibilidade de
uma análise mais profunda e específica de uma função independente do resto do
código” (LEWIS, 2000). Os caminhos de controle são testados, possibilitando
descobrir erros nos limites dos módulos. Esta estratégia tem como base o teste de
caixa branca. As unidades testadas no sistema compreendem desde a
interface, a estrutura de dados, as condições limites, os caminhos básicos e
finalmente os caminhos de tratamento.

As atividades de testes de unidade são realizadas após ser desenvolvido,

revisado e verificado o código-fonte, com o objetivo de identificar erros e analisar a
sintaxe mais adequada para o sistema.

“No teste de unidade, os casos de testes devem ser projetados para

descobrir erros devido a computações errôneas, comparações incorretas ou fluxo
de controle impróprio” (PRESSMAN, 2002).
 27

5 FERRAMENTAS DE DESENVOLVIMENTO DE SOFTWARE

5.1 Java

Java é uma linguagem de programação orientada a objetos criada pela

Sun Microsystems. Esta linguagem trouxe muitas novidades e foi encabeçada pela
promessa da portabilidade de seus códigos. Com a afirmativa: “Write Once, Run
Anywhere” (Escreva uma vez, execute em qualquer lugar), Java entrou no
mercado prometendo algo nunca atingido por outras linguagens de
programação. Isto fez com que a mesma estivesse sobre muitos olhares de
desconfiança. Em pouco tempo, essa desconfiança foi dizimada, e o uso da
linguagem foi se popularizando.

Com uma sintaxe baseada nas linguagens C e C++, Java dispõe de diversos
recursos que a fazem ser uma linguagem de programação de alto nível.
Dentre os recursos, destacam-se a máquina virtual Java (Java Virtual Machine)
que torna possível a portabilidade do código entre diversos sistemas, e o
coletor de lixo (Garbage Coletor) que facilita a tarefa do programador com
relação à alocação de memória para os objetos.

A linguagem Java se expandiu, e deu vida à novas especificações. Em nível

de desenvolvimento, foram criadas três plataformas da linguagem que agrupam
diferentes focos de utilização. A figura 2 ilustra as especificações das plataformas de
desenvolvimento de Java.
 28

Figura 2.: Especificações da linguagem java. Fonte: luizgustavoss.wordpress.com

5.1.1 Java EE

É a plataforma de desenvolvimento Java para aplicações de ambiente

coorporativo. O J2EE (Java 2 Enterprise Edition) contém todos os elementos
presentes no J2SE, mais algumas APIs específicas.

Toda aplicação que segue o padrão J2EE roda sob um container e obedece a
um conjunto de regras da plataforma. Estas regras são importantes, pois os
containers devem saber como tratar os componentes
componentes das aplicações J2EE.

A especificação da plataforma J2EE apresenta uma arquitetura multi-

multi
camadas que envolvem componentes Web (Servlets e JSP), componentes
comp de
negócio (EJBs), componentes de mensagem (componentes JMS),
J entre outros.
A figura 3 apresenta alguns desses componentes em suas respectivas camadas.
 29

Figura 3.: Componentes java EE. Fonte.: docs.oracle.com

5.1.2 Servlets

Trata-se de uma classe Java capaz de estender a capacidade de servidores

que armazenam aplicações acessadas através do modelo de programação baseado
na arquitetura Cliente/Servidor. Apesar de um Servlet poder responder qualquer tipo
de requisição, seu principal uso está em servidores Web. Para tais
aplicações, a tecnologia de Servlets define classes específicas para tratamento de
requisições http.

Um Servlet é executado e tem seu ciclo de vida gerenciado por um container

Web. Este tipo de container deve implementar um contrato para componentes Web
definidos pela plataforma J2EE. Estas especificações indicam que o container deva
prover suporte à concorrência, segurança e gerência do ciclo de vida dos
componentes Web da plataforma (Servlets e JSPs). Sendo assim, existem
várias implementações de containers Web, como o Apache Tomcat, JBoss e Jetty.

Dependendo da implementação do container, os servlets das aplicações

gerenciadas por ele podem ser instanciados ou não. Muitos containers instanciam os
 30

servlets de suas aplicações apenas quando recebem alguma requisição para estes
servlets. Ao receber uma requisição para um determinado recurso, uma thread
é alocada para tratamento desta requisição. Caso esta requisição seja para
um recurso gerenciado por um servlet, o container envia a requisição para o
servlet específico. Após processamento da requisição, este servlet poderá
responder ou repassar a requisição a um outro componente Web. A figura 4 ilustra
o ciclo de vida de um servlet.

Figura 4.: Ciclo de vidad de um servlete. Fonte.: dcc.uchile.cl

5.1.3 JSP

É a tecnologia desenvolvida pela Sun para suportar a exibição e criação

dinâmica de conteúdo HTML e XML, em resposta à requisição de um cliente
Web. Os JSPs (JavaServer Pages) são compilados e transformados em Servlets
durante uma requisição. A figura 5 ilustra o ciclo de vida de um documento JSP.
 31

Figura 5.: Ciclo de vida de um jsp. Fonte.: casteyo.wordpress.com

A sintaxe de JSP inclui:

• Elementos de scripting: permite a inserção de código Java dentro do próprio corpo

do documento JSP

• Diretivas: permite o controle de como o compilador JSP irá gerar o servlet.

• Ações: permite a invocação de recursos relacionados ao servidor web.

É possível estender as ações pré-definidas para JSPs. Através da JSP

Tag Extension API é possível criar tags personalizadas a serem utilizadas em
documentos JSP, incrementando a capacidade de processamento dos mesmos. Isto
possibilita a criação de ações personalizadas de cada lógica de negócio. A
Sun possui uma biblioteca de tags já prontas para uso, denominada Java Standard
Tag Library (JSTL). Esta biblioteca contém tags de formatação, conversão,
estrutura condicional, estrutura de repetição.

5.1.4 JSP Expression Language

Advinda com a especificação JSP 2.0, a JSP Expression Language tem como
objetivo eliminar ao máximo o uso de elementos de scripting dentro de um
documento JSP, permitindo a inserção dinâmica de valores. Ela torna mais
fácil a integração de objetos e suas propriedades com os elementos da interface
gráfica de uma aplicação Web. Além disso, a JSP Expression Language é mais
intuitiva para o aprendizado por outros profissionais que não possuem conhecimento
da linguagem Java. Webdesigners que trabalham com aplicações desenvolvidas
 32

em Java e que utilizam JSP não necessitam aprender a sintaxe de Java para
acessar os objetos da aplicação, bastando simplesmente conhecer a sintaxe e os
conceitos da linguagem de expressões do JSP.

5.2 Banco de dados relacional

O PostgreSQL é um poderoso sistema gerenciador de banco de dados

objeto-relacional de código aberto. Tem mais de 15 anos de desenvolvimento ativo
e uma arquitetura que comprovadamente ganhou forte reputação de confiabilidade,
integridade de dados e conformidade a padrões. Roda em todos os grandes
sistemas operacionais, incluindo GNU/Linux, Unix (AIX, BSD, HP-UX, SGI IRIX, Mac
OS X, Solaris, Tru64), e MS Windows. É totalmente compatível com ACID, tem
suporte completo a chaves estrangeiras, junções (JOINs), visões, gatilhos e
procedimentos armazenados (em múltiplas linguagens). Inclui a maior parte dos
tipos de dados do ISO SQL:1999, incluindo INTEGER, NUMERIC, BOOLEAN,
CHAR, VARCHAR, DATE, INTERVAL, e TIMESTAMP. Suporta também o
armazenamento de objetos binários, incluindo figuras, sons ou vídeos. Possui
interfaces nativas de programação para C/C++, Java, .Net, Perl, Python, Ruby, Tcl,
ODBC, entre outros, e uma excepcional documentação.

Como um banco de dados de nível corporativo, o PostgreSQL possui

funcionalidades sofisticadas como o controle de concorrência multiversionado
(MVCC, em inglês), recuperação em um ponto no tempo (PITR em inglês),
tablespaces, replicação assíncrona, transações agrupadas (savepoints), cópias de
segurança a quente (online/hot backup), um sofisticado planejador de consultas
(otimizador) e registrador de transações sequencial (WAL) para tolerância a falhas.
Suporta conjuntos de caracteres internacionais, codificação de caracteres multibyte,
Unicode e sua ordenação por localização, sensibilidade a caixa (maiúsculas e
minúsculas) e formatação. É altamente escalável, tanto na quantidade enorme de
dados que pode gerenciar, quanto no número de usuários concorrentes que pode
acomodar. Existem sistemas ativos com o PostgreSQL em ambiente de produção
que gerenciam mais de 4TB de dados. Alguns limites do PostgreSQL estão
incluídos na tabela abaixo.
 33

5.2.1 Aplicabilidade e atualidade do postgre

O PostgreSQL é hoje um sistema muito poderoso, sofisticado, estável, com alta

performance, implementando praticamente todas as funcionalidades requeridas
pelos clientes. Este sistema suporta bases de dados bastante extensas, adequadas
ao uso de uma grande empresa. No quadro seguinte podemos observar as
capacidades do PostgreSQL, percebendo assim que não existe qualquer tipo de
limitação para grandes bases de dados:

Tamanho máximo d base de dados *Ilimitado

Tamnho máximo de uma tabela 64TB
Tamanho máximo de uma linha de uma tabela 1.6TB
Número máximo de index por tabela *Ilimitado
Tabela 1.: Limites do postgreSQL

* - Note-se que “ilimitado” significa que não há qualquer restrição por parte do PostgreSQL ou seja,
tendo apenas as limitações do espaço livre em disco.

5.2.2 Tipo de dados do postgre

5.2.2.1 Tipos de dados: Caracteres

No PostgreSQL, existem três tipos básicos que podem comportar caracteres

alfanuméricos: char, varchar e text. A diferença entre eles está nos limites e
estrutura de armazenamento dos dados.

O tipo char(n) armazena uma cadeia de caracteres com tamanho fixo, tendo
como n o seu tamanho máximo. Ocupa 4+n bytes em disco (se a cadeia de
caracteres for menor que n, o campo é preenchido com espaços em branco à
direita). Esses 4 bytes fixos são utilizados pelo PostgreSQL para armazenar
informações referentes ao tipo e tamanho do campo.

O tipo varchar(n) tem como diferença possuir tamanho de armazenamento

variável, limitado a ncaracteres. Ocupa 4 + m bytes, onde m é o número de
caracteres efetivamente usados.
 34

O terceiro tipo, denominado text, possui tamanho variável e um limite muito

grande de armazenamento. Equivale a um varchar(4000000000) e pode ser utilizado
para armazenar campos BLOB do tipo texto.

5.2.2.2 Tipos de dados: Numéricos

Os tipos numéricos se subdividem em números inteiros, de precisão fixa, de

ponto flutuante e os pseudo tipos seriais.

5.2.2.3 Inteiros

Esse tipo armazena números sem componentes fracionais. Números inteiros

possuem limites máximos e mínimos, e qualquer tentativa de se armazenar valores
fora dessa faixa irá gerar um erro. Existem os seguintes tipos inteiros:

smallint ou int2 2 bytes (16 bits)

int, integer ou int4 4 bytes (32 bits)

int8, bigint 8 bytes (64 bits)

Na maior parte dos casos, o tipo integer oferece a melhor relação

performance versus capacidade de armazenamento. O tipo bigint, por ser mais
pesado e conseqüentemente mais lento, deve ser usado somente quando a faixa de
armazenamento do integer realmente não for suficiente.

5.2.2.4 Números de precisão fixa

Os números de precisão fixa são criados com o tipo numeric. Seu uso é
recomendado para armazenar valores monetários e outras quantias nas quais a
exatidão é necessária.

5.2.2.5 Tipos de ponto flutuante

Os tipos de dado real e double precision são tipos numéricos não exatos de
precisão variável. Na prática, estes tipos são geralmente implementações do
"Padrão IEEE 754 para Aritmética Binária de Ponto Flutuante" (de precisão simples
e dupla, respectivamente), conforme suportado pelo processador, sistema
operacional e compilador utilizados.
 35

Não exato significa que alguns valores não podem ser convertidos
exatamente para o formato interno, sendo armazenados como aproximações.
Portanto, ao se armazenar e posteriormente imprimir um valor podem ocorrer
pequenas discrepâncias.

A gerência destes erros, e como se propagam através dos cálculos como, por
exemplo: Se for necessário armazenamento e cálculos exatos (como em quantias
monetárias), em vez de tipos de ponto flutuante deve ser utilizado o tipo numeric.

Se for desejado efetuar cálculos complicados usando tipos de ponto flutuante

para algo importante, especialmente dependendo de certos comportamentos em
situações limites (infinito ou muito próximo de zero), a implementação deve ser
avaliada cuidadosamente.

A comparação de igualdade de dois valores de ponto flutuante pode

funcionar conforme o esperado, ou não.

5.2.2.6 Pseudo tipos seriais

Os tipos de dado serial e bigserial não são tipos verdadeiros, mas

meramente uma notação conveniente para definir colunas identificadoras únicas
(semelhante à propriedade AUTO_INCREMENTO existente em alguns outros
bancos de dados).

5.3 Tomcat

O software Tomcat, desenvolvido pela Fundação Apache, permite a execução

de aplicações web. Sua principla caracteristica tecnica é esta centrada na linguagem
de progemação java, mais especificamente nas tecnologia Servlet e JSP. Esta
abordagem rivaliza, por exemplo, com a usada pela Microsoft com ASP(baseada na
linguagem Visual Basic).

O Tomcat é escrito em java e, por isso, necessita da versão Java 2 Standard

Edition (J2SE) esteja instalado no mesmo computador onde ele sera executado. No
 36

entanto não basta ter a versão runtime do Java instalado, pois o Tomcat necessita
compilar(e não apenas executar) programas escritos em java.

Tecnicamente o Tomcat é um container Web, cobrindo parte da especificação

J2EE com tecnologias como Servlet e JSP, e tecnologias de apoio relacionadas
como Realms e segurança, JNDI Resources e JDBC DataSources. O Tomcat tem a
capacidade de atuar também como servidor web/HTTP, ou pode funcionar integrado
a um servidor web dedicado como o Apache httpd ou o Microsoft IIS.

5.4 Struts 2

O Struts2 é baseado na arquitetura MVC, por isso permite a separação entre

as camadas da aplicação, sendo perfeitamente adequado às aplicações web. É um
framework pertencente à categoria de suporte e é implementado utilizando a
linguagem Java. Como é largamente utilizado por desenvolvedores, possui uma
grande quantidade de livros publicados e tutoriais disponíveis na internet, o que
acaba facilitando o seu aprendizado e uso. A figura 6 a seguir mostra a maneira
simplificada do funcionamento do Struts2.

Figura 6.: Framework Struts2. (Fonte: Roughley, 2006)

 37

A sua principal característica é prover uma camada de controle exível

baseada em padrões de tecnologia já bem estabelecidos. Entre as tecnologias
usadas pelo framework, estão: Servlets, JavaBeans e XML (eXtensible Markup
Language - Linguagem de Marcação Extensível).

O Struts2 provê a sua própria camada de controle, bastando que as classes

da aplicação estendam a classe org.apache.struts.action.Action para que elas
executem o processamento desejado. Para a configuração do uso da aplicação,
deve-se construir um arquivo (struts.xml) no formato XML definindo quais ações
devem ser mapeadas para os objetos responsáveis.

Essa facilidade permite que todo o uso do sistema permaneça separado do

código-fonte.

A camada de visão pode ser desenvolvida a modo de que se torne totalmente

internacionalizável. Todas as páginas podem ser construídas de modo a permitir que
elas assumam o idioma do país do visitante. Tal funcionalidade é provida por tags
disponibilizadas juntamente com o framework.

Para auxiliar na criação das páginas JSP, existe a taglib que faz parte da
distribuição do framework. As tags que compõem essa taglib possuem funções que
permitem desde a criação de formulários até a renderização de erros provenientes
da camada de controle.

Para a camada do modelo pode-se escolher entre várias tecnologias, dentre

as quais: (JDBC , EJB) ou ferramentas ORM. A escolha por qual tecnologia utilizar
depende da arquitetura que o desenvolvedor possui previamente. A construção
dessa camada se mostra bastante exível, pois permite que padrões já bastante
conhecidos possam ser utilizados, o que traz um alto grau de portabilidade entre os
servidores de aplicação.
 38

5.5 Hibernate

O Hibernate é um framework para o mapeamento objeto-relacional

escrito na linguagem Java, mas também é disponível em .Net como o nome
NHibernate. Este programa facilita o mapeamento dos atributos entre uma base
tradicional de dados relacionais e o modelo objeto de uma aplicação, mediante o
uso de arquivos (XML) ou anotações para estabelecer esta relação. Hibernate é um
software livre de código aberto distribuído com a licença LGPL.

O objetivo do Hibernate é diminuir a complexidade entre os programas

Java, baseado no modelo orientado a objeto, que precisam trabalhar com um banco
de dados do modelo relacional (presente na maioria dos SGDBs). Em especial, no
desenvolvimento de consultas e atualizações dos dados.

Sua principal característica é a transformação das classes em Java para

tabelas de dados (e dos tipos de dados Java para os da SQL). O Hibernate gera as
chamadas SQL e libera o desenvolvedor do trabalho manual da conversão dos
dados resultante, mantendo o programa portável para quaisquer bancos de
dados SQL, porém causando um pequeno aumento no tempo de execução.

Nas questões relacionadas para o gerenciamento de transações e na

tecnologia de acesso à base de dados são de responsabilidade de outros
elementos na infraestrutura do programa. Apesar de existirem API no
Hibernate para possuir operações de controle transacional, ele simplesmente
delegará estas funções para a infraestrutura na qual foi instalada.

No caso de aplicações construídas para serem executadas em

servidores de aplicação, o gerenciamento das transações é realizado segundo
o padrão JTA. Já nas aplicações standalone, o programa delega o tratamento
transacional ao driver JDBC.

Hibernate pode ser utilizado em aplicações Java standalone ou em aplicações

Java EE, utilizando servlet ou sessões Enterprise Java Beans.

A HQL (Hibernate Query Language) é um dialeto SQL para o Hibernate. Ela é

uma poderosa linguagem de consulta que se parece muito com a SQL, mas
 39

a HQL é totalmente orientada a objeto, incluindo os paradigmas de herança,

polimorfismo e encapsulamento.

No Hibernate, você pode escolher tanto usar a SQL quanto a HQL.

Escolhendo a HQL, você poderá executar os pedidos SQL sobre as classes de
persistência do Java ao invés de tabelas no banco de dados, aumentando, assim, a
distância entre o desenvolvimento da regras de negócio e o banco de dados.

5.6 Eclipse

O eclipse é um IDE de desenvolvimento, seguindo o modelo open source de

desenvolvimento de software, da suporte a algumas das principais linguagens de
programação utilizadas atualmente, como Java, PHP, C e C++, esta disponivel para
Windows, Linux, Mac OS X, nas versões 32 e 64 bits.

O eclipse é completamente personalizavel de acordo com as necessidades do

usuario, você pode utilizar um dos pacotes disponiveis ou pode montar o seu com
com a adição de plugins.

5.7 Astah UML

ASTAH é uma IDE para Modelagem de Dados (UML) criada com Java e de
uso fácil e intuítivo. Com a IDE ASTAH é possível realizar uma modelagem de dados
complexa , apresenta os dados para o usuário de forma clara e ainda possui a
vantagem de seu layout ser bem intuítivo. A IDE possui à sua esquerda uma Árvore
de Estrutura com todos os Dados à disposição do usuário para se criar diagramas,
mapas.

É possível trabalhar com vários diagramas , classes , caso de uso ,

desenvolvimento, são 9 tipos diferentes de diagramas. É possível criar alguns itens
do diagrama de classes apenas clicando com o botão direto do mouse nos ítens dos
diagramas de casos de uso e selecionando a opção desejada. Após feita toda a
modelagem é possível exportar tudo para um arquivo Java , HTML ou exportar cada
diagrama em forma de imagem.
 40

5.8 Padrão de projeto

Padrões de projeto refletem soluções para problemas encontrados por

desenvolvedores durante a fase de projeto de software. A sua utilização
possibilita uma maior coesão e minimização da complexidade e do
acoplamento entre os elementos que integram a aplicação, uma vez que
utilizam eficientemente os conceitos de orientação a objetos. Isso implica que a
correta aplicação de padrões de projeto melhora a qualidade, flexibilidade e
manutenibilidade do software. Além disso, facilitam o trabalho dos
desenvolvedores de software, pois apresentam soluções eficazes para
problemas conhecidos. Os padrões de projeto são classificados em criacionais,
estruturais e comportamentais. Os padrões criacionais estão relacionados com a
criação de objetos, enquanto que os padrões estruturais referem-se a
composição de objetos e classes e, por fim, os padrões comportamentais lidam
com interação e compartilhamento de responsabilidade entre objetos e classes.

5.8.1 Padrões estruturais

Segundo Gamma et al. (2000), os padrões estruturais possuem como objetivo

a definição da composição de objetos e classes na formação de estruturas maiores.

Ainda conforme Gamma et al. (2000), os padrões estruturais podem ser

aplicados a classes ou objetos. Enquanto os padrões estruturais de objetos
demonstram maneiras de complementar objetos para adquirir novas
funcionalidades, os padrões estruturais de classe usam herança para definir
implementações ou interfaces.

5.8.1.1 Fachada

Gamma et al. (2000, p. 179) descrevem que a intenção do padrão

Façade consiste em fornecer uma interface unificada que represente um
conjunto de interfaces em um subsistema, facilitando a sua utilização.

Conforme Shalloway e Trott (2004), a motivação do padrão Façade consiste

na necessidade de diminuir a complexidade de interação com um sistema ou mesmo
quando é necessário interagir com esse sistema de maneira particular, por exemplo,
com um de seus subsistemas. Enfatizando esse aspecto, Gamma et al. (2000),
 41

destaca que a divisão de um sistema em subsistemas diminui a sua complexidade e

a introdução do padrão Façade nesse sistema diminui a dependência entre eles.

O padrão Façade “fornece uma interface única e simplificada para os recursos

e facilidades mais gerais de um sistema.” (GAMMA et al., 2000, p.179). Fica
evidente, portanto, que sua aplicação simplifica a utilização do sistema em que está
sendo implementado.

Para exemplificar sua utilização, a Figura 7 contém um diagrama de classe no

qual a classe denominada Facade se encarrega de divulgar à classe
Aplicacao, todas as operações que o sistema utiliza para realização de uma
compra, criando assim, uma fachada do sistema. Desse modo a classe Facade
conhece as classes responsáveis pela realização de cada operação.

Figura 7.: implementação do padrão fachada. Fonte.: ROCHA, 2003.

 42

Percebe-se que a utilização do padrão Façade possibilita representar

sistemas inteiros em somente um objeto, no contexto representado pela
Figura 7, sem a utilização desse padrão a classe Aplicacao teria que conhecer
todos os objetos do sistema.

Segundo Rocha (2003), “o padrão Façade deve ser aplicado quando for
desejável facilitar o uso de uma aplicação através da criação de uma interface para
um conjunto de objetos, fornecendo assim uma visão mais simples dessa aplicação”.

Segundo Gamma et al. (2000), “o padrão Façade oferece como benefício

a redução do número de objetos com que os clientes lidam, uma vez que ele isola os
clientes dos componentes do subsistema”. Permite variar componentes do
subsistema sem afetar os seus clientes, pois promove um acoplamento fraco entre
os subsistemas e os clientes. Além de deixar disponível a utilização das
classes contidas nos subsistemas para a aplicação.

5.9 Análise do sistema

Deseja-se através do sistema gerênciar as atividades relacionadas ao

controle de diário de classe da UAPI, uma vez que a entidade é carente de tal
recurso. O sistema deve permitir o login de usuário, controle de notas, faltas ou
presenças, controle de pólos, professores, tutores, cidades.

Levando-se em conta a necessidade da universidade foi proposto o sistema

de Caderneta Online, voltado para a plataforma web, de maneira que o usuário
possa utilizá-lo independente do sistema operacional instalado no seu computador.

Para o detalhamento do projeto, foi de fundamental importancia a aplicação

da atividade de levantamento de requisitos da Engenharia de software, pois através
dela é possibilitado que usuário e desenvolvedores, tenha a mesma visão do
problema a ser resolvido. A seguir são descritos os principais atores do sistema.
 43

Coordenador

Uma vez cadastrados, os dados desse coordenador podem ser consultados,

alterados ou excluídos. Os dados relevantes para a inclusão de tal registro no
sistema são nome, matricula, login, senha, status. O coordenador será o ator
responsável pelo manutenção de alunos, turores, professores, categoria, disciplina,
pólo, turma, tambem sera responsável por gerar e fechar as cadernetas.

Professor

Uma vez cadastrados, os dados desse professor podem ser consultados,

alterados ou excluídos. Os dados relevantes para a inclusão de tal registro no
sistema são nome, matrícula, login, senha, status, disciplina. O professor será o ator
responsavel por configurar a caderneta, e tambem poderá consultá-la depois de
lançada no sistema.

Tutor

Uma vez cadastrados, os dados desse tutor podem ser consultados, alterados
ou excluídos. Os dados relevantes para a inclusão de tal registro no sistema são
nome, matrícula, login, senha, status, disciplinas, cadernetas. O tutor será o ator
responsável pelo preenchimento da caderneta lançando notas e faltas.

Aluno

Uma vez cadastrados, os dados desse aluno podem ser consultados,

alterados ou excluídos. Os dados relevantes para a inclusão de tal registro no
sistema são nome, matrícula, login, senha, status.

Estado

Uma vez cadastrados, os dados desse estado podem ser consultados,

alterados ou excluídos. Os dados relevantes para a inclusão de tal registro no
sistema são descirção, sigla.
 44

Municipio

Uma vez cadastrados, os dados desse minicipio podem ser consultados,

alterados ou excluídos. Os dados relevantes para a inclusão de tal registro no
sistema são estado, descirção.

Pólo

Uma vez cadastrados, os dados desse polo podem ser consultados, alterados
ou excluídos. Os dados relevantes para a inclusão de tal registro no sistema são
estado, municipio, descrição.

As reuniões para levantamentos de requisitos resultaram no documento de

requisitos. Estes requisitos são divididos entre “Requisitos funcionais” e
“Requisitos não funcionais”. De acordo com Sommerville (2003), “os requisitos
funcionais são aqueles que definem funções que o sistema deve fornecer, e os não
funcionais podem estar relacionados às restrições que o sistema deve atender”,
como por exemplo, requisitos de qualidade ou desempenho.

ID Requisito Descrição
RF1 Logar no O sistema deve permitir ao usuário realizar login
sistema através de nome de usuário e senha.
RF2 Inserir O sistema deve permitir ao usuário manter os dados de
registros alunos, tutores, professores, catergoria, disciplina polo,
turma.
RF3 Gerar O sistema deve permitir ao usuário gerar, preencher e
documentos fechar cadernetas.
RF4 Consultas O sistema deve permitir ao usuário consultar notas
lançadas nas cadernetas.
Tabela 2: Requisitos funcionais
 45

ID Requisito Descrição
RNF1 Ambiente O sistema deve funcionar em ambiente web sendo
compatível com os principais navegadores do
momento: Internet Explorer, Firefox, Safari, Chrome
RNF2 Linguagem O sistema deve ser desenvolvido utilizando a
linguagem java e as tecnologias Struts2 e
Hibernate3
RNF3 Banco de O sistema deve utilizar o banco de dados postgre
dados
RNF4 Segurança O sistema deve restringir o acesso por meio de
senhas.
RNF5 Usabilidade Um usuário com conhecimento básico em
informática e conhecimento nos conceitos de
requisitos deve ser capaz de operar o sistema com
um curso de 30min
Tabela 3: Requisitos não funcionais

As regras de negocio definem como o sistema deve funcionar, normalmente

são politicas de validações, restrições ou condições especificas.

ID Descrição
RN1 Para efetuar o cadastro de novos usuários os campos obrigatórios
devem ser preenchidos. Campos obrigatórios: nome, matrícula, login,
senha, status
RN2 Para efetuar o cadastro de novos polos os campos obrigatorios
devem ser preenchidos. Campos obrigaórios: estado, municipio.
RN3 Para cada operação com uma caderneta é obrigatório a existencia de
uma turma.
RN4 Para ter acesso ao sistema o usuário deve entrar com usuario e
senha válidos.
RN5 Para exclusão de qualquer registro deve-se fazer uma consulta antes
Tabela 4: Regras de negocios

Para documentação do sistema foram usados diagrmas de caso de uso do

sosftware, tais diagramas encontram-se nos anexos.
 46

6. APRESENTAÇÃO DO SISTEMA

O sistema desenvolvido possui as características de um sistema para controle

de diários de classe, pois permite que se organize todas as informações referentes a
alunos regularmente matrículados, possibilitando assim um melhor
acompanhamento destes alunos. O sistema proporciona fazer o controle de alunos,
notas, professores, tutores, pólos, disciplinas, cidade, municípios e tipo de avaliação.

Para o desenvolvimento do código, utilizou-se a ferramenta IDE eclipse, esta

é uma ferramenta de desenvolvimento bastante flexível, a figura 8 mostra a estrutura
de diretórios definida para implementação do sistema.

Figura 8: Estrutura de diretórios do projeto

 47

A figura 9 mostra o arquivo web.xml, este arquivo é comum a qualquer

aplicação web java, neste projeto ele foi utilizado para a definição do filtro web a ser
utilizado, esse filtro é o struts2 e foi definido pela tag <filter>, em seguida com a tag
<filter-mapping> foram definidas quais páginas o struts deve controlar; “/*”
representa todas as páginas do diretório raiz.

Figura 9: Arquivo web.xml

A figura 10 mostra o parte do código contido no arquivo struts.xml.

Neste arquivo são mapeadas todas as ações da aplicação. É através deste
mapeamento que o controlador central gerencia e executa o roteamento das ações.
Cada funcionalidade do sistema representa uma ação que deve ser mapeada. Tais
ações são disparadas ao controlador através das solicitações do usuário, que
são feitas através de um navegador web. Basicamente, para cada ação mapeada
pela tag “<action>” atribui-se um nome. É necessário especificar a classe relativa à
ação (sempre são as classes Action do projeto). Se a classe Action possuir mais
de um método, é necessário especificar o nome do método que se pretende
 48

utilizar. Dentro da ação, é necessário configurar o(s) resultado(s) da mesma. O

resultado, mapeado pela tag ”<result>” pode ser o direcionamento para uma
página ou mesmo a chamada de outra ação.

Figura 10: struts.xml

A figura 11, representa partes do código da classe LoginAction. Essa é uma

classe extendida da classe ActionSupport do Struts2. Nela constam os métodos
mapeados no arquivo struts.xml e que são chamados nas páginas JSPs. É
importante ressaltar que as variáveis criadas abaixo, possuem métodos get e
set, pois é através deles que Struts2 faz a interação com as páginas JSPs. No
método “validaLogin()” verifica-se se os campos login e senha foram preenchidos
corretamente.
 49

Figura 11: LoginAction.java

A interface gráfica de um sistema é algo com que os desenvolvedores devem

se preocupar, pois é atrves dela que o usuário irá interagir com as funcionalidades
do sistema.

A figura 12 mostra a tela inicial do sistema, a qua todo usuário para ter acesso
as funcionalidade do sistema deve obrigatóriamente fornecer um login e senha
válidos, para que o sistema autentique e libere o seu acesso. Esta autenticação é de
suma importancia, pois restringe o acesso a usuário s não autorizados, já que o
sistema e Web e só fornece acesso as funcionalidades as quais o usuario tem
permissão.
 50

Figura 12: Tela inicial do sistema

A figura 13 apresenta a primeira tela após o usuário ser autenticado pelo

sistema. Somente usuários cadastrados no sistema terão accesso a este ambiente.
Este ambiente fragmenta o sistema em sete subsistemas, como pode ser visto na
barra superior da figura, a saber:

• Manter usuários
• Manter pólos
• Manter Turma
• Manter Disciplina
• Manter caderneta
• Relatórios
• Configurações
 51

Figura 13: Tela principal do sistema

A figura 14 mostra a tela para manutenção dos dados dos usuários, através
dela pode-se consultar um usuário por seu número de matricula, login ou cpf,
tambem pode-se alterar dados dos usuários e realizar seu cadastro no sistema.

Figura 14: Tela para manutenção dos dados do usuário

 52

7 CONCLUSÃO

Este trabalho utilizou padrões e tecnologias amplamente empregados em

um ambiente de desenvolvimento de software. O sistema proposto, apesar de ter
sido desenvolvido parcialmente, mostrou a viabilidade da construção de um
sistema de caderneta online por meio dos artefatos apresentados. No que tange
ao uso da engenharia de software, conclui-se que ela conduziu esse processo de
construção do sistema, desde a especificação, passando pelo projeto e
desenvolvimento, podendo ainda ser utilizada no gerenciamento de modificações
e evolução do software.

O levantamento e a análise dos requisitos foram fundamentais para o

conhecimento das necessidades e compreensão dos processos usados pela
universidade.

O emprego da UML foi fundamental para documentar o desenvolvimento

do software e mostrar de maneira clara e consistente o funcionamento do
sistema através de seus principais diagramas, como o diagrama de casos de
uso, o diagrama de classes e o diagrama de seqüência. A ferramenta CASE, o
Astah community, permitiu a elaboração dos diagramas com facilidade. Trata-se
de um software de operação simples, com inúmeros recursos. O
desenvolvedor considera importante explorá-lo melhor, para conhecer com mais
profundidade as suas funcionalidades.

O emprego da linguagem de programação Java, através do paradigma de

orientação a objeto amplamente utilizado no mercado, permitiu o
desenvolvimento de uma solução dentro de padrões atuais e possibilitou o
uso de recursos tecnológicos, como as ferramentas de desenvolvimento e
frameworks que imprimiram grande produtividade no processo de construção do
software.

O uso do padrão MVC contribuiu para que o sistema fosse projetado, com
uma melhor separação entre os dados do negócio e a interface com usuário.
Durante o desenvolvimento foi possível perceber que essa separação favorece
a independência dos componentes, de modo que as alterações que se fizeram
necessárias durante a implementação foram realizadas de forma simples,
 53

interferindo pouco na codificação de outras classes. Observa-se que a manutenção

do sistema, também, deverá ser facilitada.

O emprego do framework Struts2 foi de grande importância, uma vez

que otimizou a implementação da estrutura MVC. Caso contrário seria necessário a
criação de classes Servlets para atuarem como controlador, o que tornaria
mais complexa a implementação do sistema.

O uso dos padrões de projeto possibilitou a divisão clara das

responsabilidades de cada classe e reforçou o conceito da divisão em
camadas. Implementou-se, com os recursos do Struts2, o padrão Front Controller
garantindo o gerenciamento centralizado das requisições. O emprego do padrão
Business Object possibilitou o isolamento das regras de negócio dos demais
componentes da aplicação. O padrão Data Access Objetct conjugado com o
framework Hibernate3 foi responsável pela manipulação dos dados. Dessa forma,
tornaram-se transparentes para os desenvolvedores as operações junto ao
banco de dados, o postgre, que apresentou boa performance.

Finalmente, este projeto mostra que é possível desenvolver um sistema

de Caderneta Online para UAPI utilizando os conceitos da Engenharia de
Software, juntamente com o paradigma de orientação a objetos e as boas
práticas de programação. Entretanto, de acordo com a proposta deste
trabalho, o projeto não foi implementado completamente. Assim, sugere-se,
como trabalhos futuros, a continuidade da implementação deste projeto, bem
como melhorias na documentação do mesmo.
 54

8 REFERÊNCIAS BIBLIOGRÁFICAS

DEITEL, H. M.; DEITEL, P. J.; Java Como Programar; tradução Carlos Arthur Lang
Lisbôa. - 4ª Edição – Porto Alegre : Bookman, 2003 – Reimpressão 2004.

DIAS NETO, A. C.; TRAVASSOS, G. H. Towards a Computerized

Infrastructure for Software Testing Planning and Control. In: LATW - LATIN
AMERICAN TEST WORKSHOP, 6, 2005, LATW 2005. Salvador, Brasil.
Proceedingsi [S.l.: s.n.], 2005.

FISCHER, M. C. B. O. Estudo de Requisitos para um Software Educativo de Apoio

ao Ensino da Introdução à Computação. Dissertação de Mestrado. Local: USP –
Universidade de São Paulo, 2001

GAMMA, Erich et al. Padrões de Projeto: soluções reutilizáveis de software

orientado a objetos. Porto Alegre: Bookman, 2000.

HUMPHREY, Watts S. Introduction to the Team Software Process, Addison-Wesley,

1999.

LEWIS, W. E. Software Testing Continuous Quality Improvement. Boca Raton,

USA: Auerbach, 2000.

PETERS, J. F.; PEDRYCZ, W. Engenharia de Software: teoria e prática. Rio

de Janeiro, BRA: Campus, 2001.

PRESSMAN, Roger S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill,

2002.

PRESSMAN, Roger. Engenharia de Software. Tradução Rosângela Delloso

Penteado. 6 ed. São Paulo: McGraw-Hill, 2006. 720p.

PRESSMAN, S. Roger, Engenharia de Software São Paulo, Editora Mc Graw Hill

Wesley, 5º edição, 2002.

REZENDE, D. A. Engenharia de Software e Sistemas de Informação. Rio de

Janeiro, BRA: Braspot Livros e Multimídia, 2002.

ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C., Qualidade de Software:

Teoria e Prática , Prentice Hall, 2001.
 55

SHALLOWAY, Alan; TROTT, James R. Explicando padrões de projeto: uma nova

perspectiva em projeto orientado a objeto. Porto Alegre: Bookman, 2004.

SOMMERVILLE, Ian, Engenharia de Software São Paulo, Editora Addison Wesley,

6a edição, 2003.

SOMMERVILLE, Ian. Engenharia de Software. Tradução André Maurício de Andrade

Ribeiro. 6 ed. São Paulo: Addison Wesley, 2003. 592p.
 56

ANEXOS
 57

Figura 15.: Dia grama de classes

 58

Figura 16.: Diagrama de caso de uso

 59

Figura 17.: Caso de uso Cadastrar Usuário

 60

Figura 18.: Diagrama de atividade Manter Usuário

 61

Figura 19.: Diagrama de sequencia cadastrar usuário

 62

Figura 20.: Diagrama de sequencia consultar usuário

 63

Figura 21.: Diagrama de seuqencia alterar usuário

 64

Figura 22.: Caso de uso excluir usuário

 65

Nome Realizar Login CU01

Sumário Este caso de uso descreve o processo para realizar login

Ator primário: Usuário

Ator(es) secundário(os): -
Pré-condição: Possuir nome de usuário e senhas válidos
Pós-condição: Acesso a tela principal do sistema

Fluxo principal

1. O sistema exibe a tela inicial

2. O suário entra com os respectivos dados: usuário e senha
3. O sistema verifica se usuário e senhas são válidos
4. O sistema apresenta a tela principal e o caso de uso é encerrado

Fluxo alternativo[]:
Não há
Fluxo de Exceção: Usuario ou senha inválido

a) usuário informa dados incoretos ou inválidos.

b) O sistema retorna uma mensagem.

Regras de negócio associados

RN-04

Tabela 5.: Caso de uso realizar login

 66

Nome Manter usuário CU02

Este caso de uso descreve as etapas necessárias para a
Sumário manutenção dos dados do usuário(inclesão, açteração,
exclusão)

Ator primário: Usuário

Ator(es) secundário(es):
Pré-condição: Estar “logado” no sistema
Pós-condição: Usuário cadastrado, atualizado ou excluído.

Fluxo principal

1. usuário admin. solicita a manutanção de outros usuários no sistema.

2. O sistema aapresenta as opções(incluir, alterar, ou excluir)
3. O usuário admin. indica a opção desejada.
4. O sistema registra a operação e o caso de uso é encerrado.

Fluxo alternativo[]: Incluir

a) usuário admin. solicita a inclusão de um usuário.

b) O sistema solicita os dados a serem preenchidos.
c) O usuário admin. informa os dados.
d) O usuário admin. confirma a inclusão e o caso de uso retorna o passo 4

Fluxo alternativo[]: Alterar

a) usuário admin. Solicita a alteração dos dados de um usuário.

b) O sistema apresenta o formulário para alteração dos dados.
c) O usuário admin. altera os dados.
d) O usuário admin. confirma a alteração e o caso de uso retorna o passo 4

Fluxo alternativo[]: Excluir

a) usuario admin solicita a exclusão de um usuário

b) O sistema exibe uma mensagem de aleta para confirmar a exclusão
c) O usuario admin confirma a exclusão e o caso de uso retorna o passo 4

Fluxo de exceção[]: Não preenchimento dos dados obrigatórios

a) usuário não informa os dados obbrigatórios

b) O sistema emite uma mensagem

Regra de negócios assiciadas

RN-01
Tabela 6.: Caso de uso manter dados do usuário
 67

Figura 23.: Consulta de usuário

 68

Figura 24.: Resultado consulta usuário

 69

Figura 25.: Visualização dos dados do usuário

 70

Figura 26.: Alterar dados do usuário