Gestao de Condominio

UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA
FACULDADE DE CIÊNCIAS APLICADAS DE MINAS

Autorizada pela Portaria nº 577/2000 – MEC, de 03/05/2000
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Marco Aurélio Silva Rodrigues

Maria Margaret de Vasconcellos Lemos
Orlando Alves de Oliveira
S
A
SISTEMA PARA GESTÃO DE CONDOMÍNIO
IN
IM
N
U
Uberlândia
2009
1
Maria Margaret de Vasconcelos Lemos
S
A
IN
Trabalho de Final de curso submetido à
IM
UNIMINAS como parte dos requisitos para a

obtenção do grau de Bacharel em Sistemas
de Informação.
N
Orientador: Prof. Msc. Edson Angoti Júnior

U
Uberlândia
2009
2
Marcos Aurélio Silva Rodrigues
Maria Margaret de Vasconcelos Lemos
S
Banca Examinadora:
Uberlândia, 9 de julho de 2009.
A
IN
________________________________________________________________
IM
Professor. Msc.Edson Angoti Júnior (Orientador)
________________________________________________________________
N
Profa. Dra. Kátia Lopes Silva

U
_________________________________________________________________
Prof. Dr. Mauro Hemerly Gazzani
Uberlândia
2009
3
S
A
IN
IM
N
U
Se enxerguei longe, foi porque me apoiei nos ombros de gigantes.
Isaac Newton
AGRADECIMENTOS
A todos os professores do Curso de Sistema de Informação da

UNIMINAS que durante nossa estada nesta casa nos acompanharam e auxiliaram
na construção de nosso conhecimento. Em especial aos professores Ana Maria
Ferreira Árabe, Edson Angoti Jr. e Kátia Lopes Silva que estiveram sempre presente
S
na elaboração deste trabalho.
Dividir com vocês essa autoria foi um privilégio que poucos de nós
tiveram!
A
IN
IM
N
U
RESUMO
A Revolução Industrial, um dos marcos da Idade Moderna efetivamente

desencadeou o processo de urbanização, que trouxe em si questões a serem
resolvidas. Como consequência, a moradia se tornou um problema a ser
equacionado. A solução que se apresentou foi a verticalização, trazendo resposta à
necessidade de espaço. Com a difusão dessa forma de associação, foram criadas
leis que regulamentaram a sua administração, que atualmente, tende à
profissionalização, tanto que há no mercado vários sistemas de informação voltados
à administração de condomínios, porém alguns clientes preferem softwares
S
customizados, sendo essa a escolha do Condomínio do Edifício Porto Seguro,
localizado em Uberlândia, MG. Assim, desenvolveu-se um sistema de fácil operação,
A
para apoiar a sua administração, possibilitando o registro de moradores e
proprietários, mantendo o histórico dessas informações. Foi feita a análise, definidos
IN
os casos de uso e elaborados os diagramas de sequência documentados com o
emprego da UML. O modelo escolhido foi o MVC, implementado com o uso do
Eclipse e dos frameworks Struts e Hibernate. O mapeamento objeto relacional foi
realizado pelo JDBC juntamente com a utilização do framewok Hibernate. Para o
IM
acesso ao banco de dados foi empregado o padrão de projeto DAO, configurado

para se conectar ao MySQL, o SGBD escolhido para a persistência dos dados. O
servidor web selecionado foi o TomCat, que implementa as especificações servlet e
JSP. A interface com o usuário foi construída com páginas JSP de cor azul
N
considerada a mais tranqüila de todas, que sugere espaço e profundidade. As

ferramentas empregadas para a codificação do sistema permitiram a simplificação
U
do código. A engenharia reversa realizada pelo Hibernate facilitou a implementação

das classes de entidades, garantindo a correlação entre as classes e as tabelas do
banco de dados. As annottations realizaram com facilidade o mapeamento objeto-
relacional e o padrão de projeto DAO proporcionou a persistência dos dados de
forma simples, no banco de dados MySQL que apresentou boa performance,
comprovando que foi uma escolha adequada à aplicação. Embora, não tenham sido
implementados todos os casos de uso, o sistema pode ser concluído, pois o número
de condomínios está crescendo e a relação entre a gerência e os condôminos tem
evoluído. Aliado a isso, as características do sistema e a documentação para apoiar
a expansão do projeto está disponível, o que facilitará a realização dessa tarefa.
Palavras chave: gestão de condomínio; sistema de informação; implementação de

software.
S
A
IN
IM
N
U
ABSTRACT
The Industrial Revolution, one of the landmarks of the Modern Age actually triggered
the process of urbanization, which in itself has brought issues to be resolved. As a
result, housing became a problem to be solved. The solution that presented itself
was the verticalisation, bringing answers to the need for space. With the spread of
this form of association, have created laws governing its administration, which
currently tends to professionalism, so that there is more market information systems
focused on management of condominiums, but some customers prefer customized
software, and this is the choice the condominium building of Porto Seguro, located in
S
Uberlândia, MG. Therefore, has developed a system to support its a system to
support its administration, easy operation, allowing the registration of residents and
A
owners, while maintaining the historical information. Was the analysis, the set of use
cases and developed the sequence of diagrams that have been documented with the
use of UML. The model chosen was the MVC, implemented using the Eclipse and
IN
the frameworks Hibernate and Struts. The object relational mapping was performed
by JDBC with the use of Hibernate framewok. To access the database was used the
design pattern DAO, configured to connect to MySQL, the DBMS chosen for the
IM
persistence of data. The web server selected was the Tomcat, which implements the
servlet and JSP specifications. The user interface was developed with JSP pages
with color blue as the most peaceful of all, suggesting space and depth. The tools
used for coding the system allowed the simplification of the code. Reverse
N
engineering performed by the Hibernate facilitating the implementation of entities

classes, ensuring correlation between classes and tables in the database. The
annottations made the object-relational mapping easy and the design pattern DAO
U
has been the persistence of data in a simple way, the MySQL, choosing database,
had good performance, proving that it was appropriated for the application. Although
whole use cases have not been implemented, the system can be completed because
the number of condominiums is growing and the relationship between management
and owners have changed. In addition, the system features and documentation to
support the expansion of the project is available, these will help the realization of this
task.
Keywords: condominium management, information system, implementation of
software.
S
A
IN
IM
N
U
LISTA DE ABREVIATURAS
API Application Programming Interface

CPF Cadastro de Pessoa Física
CPU Central Processing Unit
CRUD Create, Retrieve, Updade Delete
CSS Cascading Style Sheets
DAO Data Access Object
GPL General Public License
GNU Gnu not Unix
GoF Gang of Four
HQL Hibernate Query Language
S
HTML Hipertext Modelling Language
HTTP Hipertext Transfer Protocol
FK Foreign key
IBGE
IDE
IP A
Instituto Brasileiro de Geografia e Estatística
Integrated Development Environment
Internet Protocol
IN
J2EE Java Enterprise Edition
JDBC Java Database Conectivity
JDK Java Development Kit
JEE
IM
Java Enterprise Edition

JPC Java Community Process
JSP Java Server Pages
JVM Java Virtual Machine
LGPL Lesser GNU Public License
N
MVC Model View Control

OBDC Open-DataBase-Connectivity
OO Orientado a Objeto
U
ORM Object Role Modeling

PK Primary Key
RAM Random Access Memory
SGBD Sistema de Gerenciamento de Banco de Dados
SQL Structured Query Language
TCP Transmission Control Protocol
XML eXtensible Markup Language
Lista de Tabelas
Página
Tabela 1 – População brasileira, segundo os censos demográficos de 1940, 1950, 1960,

1970, 1980, 1991 e contagem de 1996. ........................................................................... 18
Tabela 2 – População de Uberlândia, MG, 1996 a 2006..................................................................... 19
Lista de Quadros
Página
Quadro 2 – Requisitos do sistema. ...................................................................................................... 30
S
Quadro 1 – Regras de Negócio............................................................................................................ 31
Quadro 3 – Especificação do caso de uso: Fazer Login. .................................................................... 37
Quadro 4 – Especificação do caso de uso: Cadastrar Dados. ............................................................ 39
A
Quadro 5 – Especificação do caso de uso: Listar Pessoas. ................................................................ 42
Quadro 6 – Especificação do caso de uso: Consultar Pessoa. ........................................................... 44
Quadro 7 – Especificação do caso de uso: Consultar Unidade........................................................... 46
IN
Quadro 8 – Especificação do caso de uso: Atualizar Histórico. .......................................................... 49
Quadro 9 – Especificação do caso de uso: Pesquisar Histórico. ........................................................ 51
Quadro 10 – Especificação do caso de uso: Registrar Conta a Pagar. .............................................. 53
Quadro 11 – Especificação do caso de uso: Registrar Pagamento de Contas................................... 55
IM
Quadro 12 – Especificação do caso de uso: Gerar Taxa de Condomínio........................................... 58

Quadro 13 – Especificação do caso de uso: Receber Taxa de Condomínio. ..................................... 61
Quadro 14 – Especificação do caso de uso: Gerar Recibo. ................................................................ 64
Quadro 15 – Especificação do caso de uso: Gerar Balancete. ........................................................... 67
Quadro 16 – Especificação do caso de uso: Gerar Histórico. ............................................................. 70
N
Lista de Figuras
U
Página
Figura 1 – Grau de Urbanização, Brasil, 2000..................................................................................... 19

Figura 2 – Fachada do edifício Porto Seguro. ..................................................................................... 26
Figura 3 – Diagrama de classes de negócio........................................................................................ 35
Figura 4 – Diagrama de casos de uso. ................................................................................................ 36
Figura 5 – Diagrama de sequência do caso de uso: Fazer Login. ...................................................... 38
Figura 6 – Diagrama de sequência do caso de uso: Cadastrar Dados. .............................................. 40
Figura 7 – Diagrama de sequência do caso de uso: Listar Pessoas................................................... 43
Figura 8 – Diagrama de sequência do caso de uso: Consultar Pessoa. ............................................. 45
Figura 9 – Diagrama de sequência do caso de uso: Consultar Unidade. ........................................... 47
Figura 10 – Diagrama de sequência do caso de uso: Atualizar Histórico. .......................................... 50
Figura 11 – Diagrama de sequência do caso de uso: Pesquisar Histórico. ........................................ 52
Figura 12 – Diagrama de sequência do caso de uso: Registrar Contas a Pagar................................ 54
Figura 13 – Diagrama de sequência do caso de uso: Registrar pagamento de Contas. .................... 56
Figura 14 – Diagrama de sequência do caso de uso: Gerar Taxa de Condomínio............................. 59
Figura 15 – Diagrama de sequência do caso de uso: Receber Taxa de Condomínio. ....................... 62
Figura 16 – Diagrama de sequência do caso de uso: Gerar Recibo. .................................................. 65
Figura 17 – Diagrama de sequência do caso de uso: Gerar Balancete. ............................................. 68
Figura 18 – Diagrama de sequência do caso de uso: Gerar Balancete. ............................................. 71
Figura 19 – Classes do pacote entidades............................................................................................ 73
Figura 20 – Classes do pacote bo. ...................................................................................................... 74
Figura 21 – Classes do pacote persistência. ....................................................................................... 74
S
Figura 22 – Classes do pacote action.................................................................................................. 75
Figura 23 – Diagrama de sequência com as classes de projeto do caso de uso: Fazer
A
Login. ................................................................................................................................ 77
Figura 24 – Diagrama de sequência com as classes de projeto do caso de uso:
Cadastrar Dados............................................................................................................... 79
IN
Figura 25 – Diagrama de sequência com as classes de projeto do caso de uso: Listar
Pessoas. ........................................................................................................................... 81
Consultar Pessoa.............................................................................................................. 83
IM
Consultar Unidade. ........................................................................................................... 85

Figura 28 – Diagrama de sequência com as classes de projeto do caso de uso: Atualizar
Histórico. ........................................................................................................................... 87
Figura 29 – Modelo Arquitetura MVC................................................................................................... 90
N
Figura 30 – Classe PessoaBO. ............................................................................................................ 92

Figura 31 – Ciclo de vida do servlet. .................................................................................................... 94
Figura 32 – Código da página consultarPessoaForm.jsp. ................................................................... 95
U
Figura 33 – Página pesquisarPessoa.jsp............................................................................................. 96

Figura 34 – Modelo em camadas......................................................................................................... 97
Figura 35 – Front Controller ................................................................................................................. 98
Figura 36 – Arquivo struts.xml.............................................................................................................. 99
Figura 37 – Método consultaUnidade. ............................................................................................... 100
Figura 38 – Diagrama de pacotes ...................................................................................................... 100
Figura 39 – Classes do pacote entidades.......................................................................................... 101
Figura 40 – Classes do pacote bo ..................................................................................................... 101
Figura 41 – Classes do pacote persistência. ..................................................................................... 102
Figura 42 – Classes do pacote action................................................................................................ 102
Figura 43 – Página Principal .............................................................................................................. 103
Figura 44 – Action setUpForInsertOrUpdate mapeada no arquivo struts.xml. .................................. 104
Figura 45 – Método setUpForInsertOrUpdate() implementado na classe
CadastrarPessoaAction. ................................................................................................. 104
Figura 46 – Tela de Cadastro de Dados ............................................................................................ 104
Figura 47 – Action InsertOrUpdate implementado no arquivo struts.xml. ......................................... 105
Figura 48 – Método InsertOrUpdate implementado na classe CadastrarPessoaAction. .................. 105
Figura 49 – Método gravaPropAquisicao() implementado na classe
Figura 50 – Mensagem de erro gerada pelo método gravaPropAquisicao()
implementado na classe CadastrarPessoaAction. ......................................................... 107
Figura 51 – Comando de persistência declarado no método gravaPropAquisicao()
S
Figura 52 – Comando geração do objeto pessoaDAO declarado no construtor da classe
PessoaBO....................................................................................................................... 107
A
Figura 53 – Chamada do método insert() através do método insertPessoa()
implementado na classe PessoaBO............................................................................... 108
Figura 54 – Código do método insert() implementado pela classe PessoaHibernateDAO. .............. 108
IN
Figura 55 – Comandos do método gravaPropAquisicao() implementado pela classe
Figura 56 – Comandos de criação do objeto UnidadeHibernateDAO declarado no
construtor da classe UnidadeBO. ................................................................................... 109
Figura 57 – Comandos do método updateUnidade() implementado pela classe
IM
UnidadeBO. .................................................................................................................... 109

Figura 58 – Código do método updateUnidade() implementado pela classe
UnidadeHibernateDAO. .................................................................................................. 110
N
implementado na classe CadastrarPessoaAction, quando já há histórico da

unidade. .......................................................................................................................... 111
Figura 60 – Comandos de criação do objeto HistoricoHibernateDAO declarado no
U
construtor da classe HistoricoBO. .................................................................................. 111

Figura 61 – Comandos do método updateHistorico() implementado pela classe
HistoricoBO..................................................................................................................... 111
Figura 62 – Código do método updateHistorico() implementado pela classe
HistoricoHibernateDAO. ................................................................................................. 112
implementado na classe CadastrarPessoaAction, quando não há histórico da
unidade. .......................................................................................................................... 112
Figura 64 – Comando declarado no método insertHistorico() implementado na classe
HistoricoBO..................................................................................................................... 113
Figura 65 – Código do método insert() implementado na classe HistoricoHibernateDAO............... 113
Figura 66 – Mensagem de sucesso gerada pelo método gravaPropAquisicao()
Figura 67 – Código do método isertOrUpdate() implementado na classe
Figura 68 – Action insertOrUpdate mapeada no arquivo struts.xml. ................................................. 114
Figura 69 – Tela de confirmação de cadastro.................................................................................... 115
Figura 70 – Diagrama de Navegabilidade.......................................................................................... 120
Figura 71 – Tela de Login. ................................................................................................................. 122
Figura 72 – Tela de mensagem de erro no Login. ............................................................................. 122
Figura 73 – Menu inicial. .................................................................................................................... 123
Figura 74 – Tela de Cadastro de Dados. ........................................................................................... 123
Figura 75 – Tela com mensagem de erro de CPF............................................................................. 124
S
Figura 76 – Tela com mensagem de erro, CPF cadastrado como morador em outra
unidade. .......................................................................................................................... 124
A
Figura 77 – Tela com mensagem de sucesso ao cadastrar os dados. ............................................. 125
Figura 78 – Tela que apresenta a lista das pessoas cadastradas..................................................... 125
Figura 79 – Tela para solicitar a pesquisa dos dados de uma pessoa.............................................. 126
IN
Figura 80 – Tela que apresenta os dados da pessoa pesquisada. ................................................... 126
Figura 81 – Tela para solicitar a pesquisa dos dados de uma unidade. ........................................... 127
Figura 82 – Tela que apresenta os dados da unidade pesquisada. .................................................. 127
Figura 83 – Sistema simplificado de Banco de Dados. ..................................................................... 131
Figura 84 – Arquitetura de Modelo de Banco de Dados. ................................................................... 134
IM
Figura 85 – Modelo Físico de Banco de Dados ................................................................................. 137

Figura 86– Modelo Lógico de Banco de Dados ................................................................................. 136
Figura 87 - Estrutura Padrão DAO. .................................................................................................... 140
Figura 88 – Arquitetura Hibernate. ..................................................................................................... 143
N
Figura 89 - Arquivo "hibernate.cfg.xml".............................................................................................. 146

Figura 90 – Classe Hibernate Útil. ..................................................................................................... 146
Figura 91 – Classe de persistência HistoricoHibernateDAO. ............................................................ 148
U
Figura 92 – Classe de entidade Historico .......................................................................................... 150

SUMÁRIO
Página
1. INTRODUÇÃO 17
1.1. UM BREVE HISTÓRICO............................................................................................ 17
1.2. CENÁRIO ATUAL ..................................................................................................... 20
1.3. IDENTIFICAÇÃO DO PROBLEMA ................................................................................ 22
1.4. OBJETIVOS ............................................................................................................ 23
1.4.1. Geral....................................................................................................... 23
1.4.2. Específicos ............................................................................................. 23
1.5. JUSTIFICATIVA........................................................................................................ 23
S
1.6. ORGANIZAÇÃO DO TRABALHO ................................................................................. 24
2. ESPECIFICAÇÃO DO PROBLEMA 26
3. ANÁLISE E PROJETO 28
3.1.
3.2.
3.3. A
UNIFIED MODELLING LANGUAGE – UML .................................................................. 28
ETAPAS DA ANÁLISE DE SISTEMA ............................................................................ 29
REQUISITOS........................................................................................................... 30
IN
3.4. REGRAS DE NEGÓCIO............................................................................................. 31
3.5. CLASSES ............................................................................................................... 33
3.6. CASOS DE USO ...................................................................................................... 36
IM
3.6.1. Caso de Uso 01: Fazer Login.................................................................. 37

3.6.2. Caso de Uso 02: Cadastrar Dados ......................................................... 39
3.6.3. Caso de Uso 03: Listar Pessoas ............................................................. 42
3.6.4. Caso de Uso 04: Consultar Pessoa ........................................................ 44
3.6.5. Caso de Uso 05: Consultar Unidade ....................................................... 46
N
3.6.6. Caso de Uso 06: Atualizar Histórico........................................................ 49

3.6.7. Caso de Uso 07: Pesquisar Histórico...................................................... 51
U
3.6.8. Caso de Uso 08: Registrar Conta a Pagar .............................................. 53

3.6.9. Caso de Uso 09: Registrar Pagamento de Contas.................................. 55
3.6.10. Caso de Uso 10: Gerar Taxa de Condomínio ......................................... 58
3.6.11. Caso de Uso 11: Receber Taxa de Condomínio ..................................... 61
3.6.12. Caso de Uso 12: Gerar Recibo ............................................................... 64
3.6.13. Caso de Uso 13: Gerar Balancete .......................................................... 67
3.6.14. Caso de Uso 14: Gerar Histórico ............................................................ 70
3.7. PROJETO ............................................................................................................... 72
3.7.1. Diagramas de Sequência de Projeto....................................................... 76
4. ARQUITETURA E CÓDIGO 88
4.1. JAVA ..................................................................................................................... 88
4.2. ARQUITETURA MVC ............................................................................................... 89
4.3. PADRÕES DE PROJETO ........................................................................................... 90
4.3.1. DAO........................................................................................................ 91
4.3.2. Business Object ...................................................................................... 91
4.3.3. Front Controller ....................................................................................... 92
4.3.4. Application Controller .............................................................................. 93
4.4. TECNOLOGIAS UTILIZADAS ...................................................................................... 93
4.4.1. Servlet .................................................................................................... 93
4.4.2. Páginas JSP ........................................................................................... 94
4.4.3. JDBC ...................................................................................................... 96
4.5. J2EE .................................................................................................................... 96
S
4.6. TOMCAT ................................................................................................................ 97
4.7. IMPLEMENTAÇÃO .................................................................................................... 98
4.7.1.
4.7.2.
4.7.3. A
Struts ...................................................................................................... 98
Diagrama de Pacotes ........................................................................... 100
Implementação do Caso de Uso Cadastrar Dados ............................... 103
IN
5. INTERFACE 116
5.1. DIAGRAMA DE NAVEGABILIDADE ............................................................................ 119
6. PERSISTÊNCIA DE DADOS 128
6.1. CONCEITOS DE BANCO DE DADOS......................................................................... 129
IM
6.2. MYSQL ............................................................................................................... 131

6.3. MODELAGEM DE BANCO DE DADOS ....................................................................... 134
6.3.1. Modelos ................................................................................................ 134
6.3.2. Compreendendo o Modelo.................................................................... 139
N
6.4. PADRÃO DE PROJETOS DAO ................................................................................ 139

6.5. FRAMEWORK HIBERNATE...................................................................................... 141
6.5.1. Características Hibernate...................................................................... 142
U
6.5.2. Arquitetura do Hibernate ....................................................................... 142

6.5.3. Mapeamento Objeto Relacional ............................................................ 143
6.6. MECANISMOS DE PERSISTÊNCIA ........................................................................... 148
7. CONCLUSÃO 151
REFERÊNCIAS BIBLIOGRÁFICAS 154
APÊNDICE 158
17
1. INTRODUÇÃO
1.1. UM BREVE HISTÓRICO
A instituição da sociedade ocorreu como um movimento dos homens

na tentativa de se protegerem dos instintos predatórios de outros homens e de
outros animais. A sociedade constituiu-se como forma de proteção contra abusos e
excessos, sendo um mecanismo de defesa contra a “lei do mais forte”. Assim, foram
estabelecidas normas de conduta que tornassem possível a convivência entre os
homens. Buscou-se domar a agressividade natural do ser humano, para que todos
S
pudessem conviver de forma próxima e participativa. Com isso, estabeleceu-se,
então, um conflito entre a necessidade de proteção e a repressão dos instintos
A
(FREUD, 2002). Nasceu, assim, a civilização.
Na Grécia antiga, pequenas comunidades se agrupavam em um centro,
na tentativa de se protegerem de ataques externos. Denomina-se tal fenômeno de
IN
sinecismo, que significa coabitação. Assim, originaram-se as “Polis” gregas, que
deram origem às cidades ocidentais (WIKIPEDIA, 2009).
Ainda dentro do processo histórico, na Idade Média, embora
IM
“organizada” a sociedade, a população não se encontrava necessariamente

protegida dos abusos dos mais fortes. Como exemplo clássico, é possível observar
as relações nos feudos. Os senhores feudais – os mais fortes tinham direitos totais
sobre a vida de seus servos e camponeses. Nesse momento histórico, a lei do mais
N
forte era, por assim dizer, institucionalizada.

Na passagem do século X para o século XI se observa o crescimento
populacional, com o conseqüente aumento da demanda por alimentos. O
U
desenvolvimento agrícola não foi suficiente para responder às necessidades da

população. Se em determinadas áreas, a produção era excedente, em outros locais
se mostrava insuficiente. A solução encontrada foi o comércio. Ocorreu nesse
período o êxodo rural, representado pelo deslocamento significativo da população
rural para as cidades, sendo que muitas delas se desenvolveram junto a castelos e
mosteiros, para se protegerem dentro de seus muros (ABREU, 2009).
Foi a Revolução Industrial, um dos marcos da Idade Moderna, que
efetivamente desencadeou o processo de urbanização, definida como o aumento da
18
população urbana em relação à rural. Assim, o primeiro país da Europa a se

urbanizar foi a Inglaterra. Já em 1850, cinqüenta por cento de sua população morava
nas cidades. A aceleração da urbanização dos países desenvolvidos se deu a partir
da segunda metade do século XIX (URBANIZAÇÃO DO mundo, 2009).
No Brasil, o processo de urbanização foi mais acelerado que nos
países da Europa e na América do Norte, embora tenha ocorrido mais tardiamente,
na segunda metade do século XX. Como nos demais países, também a
industrialização foi o fator desencadeante do êxodo rural (MIRANDA, 2009). A
industrialização se intensificou a partir dos governos de Getúlio Vargas (1930 –
1945), se firmando na administração de Juscelino Kubistchek (1955 – 1960), com a
implantação da indústria automobilística (URBANIZAÇÃO DO Brasil, 2009).
S
De acordo com o Instituto Brasileiro de Geografia e Estatística – IBGE
até a década de 1960, a maioria da população residia nas áreas rurais. A partir de
A
1970 houve a inversão, com o predomínio da população urbana (55,92%), como
mostra a tabela 1 (BRASIL, 2009b).
IN
Tabela 1 – População brasileira, segundo os censos demográficos de 1940, 1950,
1960, 1970, 1980, 1991 e contagem de 1996.
ÁREA URBANA ÁREA RURAL TOTAL
ANOS
IM
HABITANTES % HABITANTES % HABITANTES
1940 12.880.182 31,24 28.356.133 68,76 41.236.315

1950 18.782.891 36,16 33.161.506 63,84 51.944.397
1960 31.303.034 44,67 38.767.423 55,33 70.070.457
N
1970 52.084.984 55,92 41.054.053 44,08 93.139.037

1980 80.436.409 67,59 38.566.297 32,41 119.002.706
1991 110.990.990 75,59 35.834.485 24,41 146.825.475
U
1996 123.076.831 78,36 33.993.332 21,64 157.070.163

Fonte: IBGE (BRASIL, 2009a).
Observa-se ainda, que a urbanização não se deu de forma homogênea

no país. Em 2000, apresentava-se mais acentuada nas regiões Sul, Sudeste e
Centro-Oeste. Na região Nordeste as áreas litorâneas apresentavam aglomerados
mais urbanizados. Em poucas áreas a taxa de urbanização era inferior a 25 por
19
cento, sendo que a região Sudeste apresenta taxa acima de 75 por cento na maioria
dos municípios, como mostra a figura 1.
S
A
IN
Figura 1 – Grau de Urbanização, Brasil, 2000.
Fonte: IBGE (BRASIL, 2001).
IM
Localizada na região sudeste, no estado de Minas Gerais, no Triângulo

Mineiro, Uberlândia é considerada a maior cidade do interior do estado e em 2006, a
população era estimada em 600.358 habitantes (Tabela 2). Como observado na
N
região Sudeste, sua taxa de urbanização é alta, da ordem de 97,56 por cento, ao
considerar-se o censo de 2000.
U
Tabela 2 – População de Uberlândia, MG, 1996 a 2006.

ANOS
ÁREA
1996 2000 2001 2002 2003 2004 2005 2006
Urbana 431.744 488.982 505.167 521.888 539.162 556.133 570.982 585.719
Rural 7.242 12.232 12.637 13.055 13.487 13.909 14.280 14.649
Total 438.986 501.214 517.804 534.943 552.649 570.042 585.262 600.368
Fonte: Prefeitura de Uberlândia (2007).
20
De maneira geral no país, a urbanização desordenada trouxe em si

dificuldades para atender às necessidades básicas dos migrantes. Nascem, assim,
vários problemas sociais, notadamente o desemprego, a criminalidade e a
favelização (MIRANDA, 2009). Consequentemente a moradia se torna um problema
a ser equacionado. Dois aspectos tornam-se relevantes para a solução. O primeiro
diz respeito ao espaço propriamente dito, não havendo “solo” suficiente quer seja
para a moradia, quer seja para uso comercial, nas áreas mais centrais, enquanto
que o segundo ponto se trata de segurança. A solução que se apresenta é a
verticalização, ou seja, edificações de vários andares que abrigassem mais de uma
propriedade, trazendo resposta à necessidade de espaço, e aumentando a
segurança, uma vez que a cotização permite estabelecer mecanismos de proteção,
S
com custo mais acessível.
1.2. CENÁRIO ATUAL
A
Ao se considerar o município de Uberlândia, o número de condomínios
IN
tem crescido, embora não se conheça estatística oficial sobre o assunto. Se
inicialmente, na década de 1960 os condomínios eram constituídos na área central
da cidade em edificações de vários andares, no final da década de 1980 até meados
da década de 1990, iniciou-se a construção de pequenas edificações, não mais na
IM
região central da cidade. Um dos locais, que nesse período apresentou um grande
crescimento desse tipo de condomínio, foi o bairro Santa Maria. Nesse bairro,
localiza-se o condomínio do Edifício Porto Seguro, prédio estritamente residencial,
composto por três andares, sendo que cada andar abriga duas unidades
N
habitacionais. O síndico do condomínio é um dos proprietários que reside no edifício.

Com a difusão dessa forma de associação, foram criadas leis que
U
regulamentam a criação, administração e o convívio entre as pessoas, que foram

reconhecidas como condôminos, uma vez que passaram a dividir o domínio da
edificação. Inicialmente, a lei 4.591 de 16 de dezembro de 1964 dispunha sobre o
condomínio em edificações e as incorporações imobiliárias. Em seu artigo quinto
delega ao Código Civil a sua regulamentação: “o condomínio por meação de parede,
soalhos e tetos das unidades isoladas regular-se-á pelo disposto no Código Civil, no
que lhe for aplicável” (BRASIL, 1964). Assim, a determinação legal dos condomínios
21
edílicos está no Código Civil Brasileiro, notadamente no Livro III, em seus artigos
1.331 a 1.358.
De acordo com a legislação, o síndico seria a pessoa responsável pela
administração do condomínio. Embora o papel do síndico se mantenha o mesmo,
esse não precisa necessariamente ser um morador, sendo cada vez mais comum a
figura de um administrador profissional ou até mesmo uma empresa que assuma as
funções administrativas. Também, é comum a existência de empresas de
administração que apóiam as atividades do síndico.
A profissionalização dessas administrações é uma tendência, pois há
condomínios com grande número de unidades, que requerem uma abordagem mais
direcionada com embasamento legal. Também, pequenos condomínios estão
S
fazendo uso desses serviços, de modo que os direitos e deveres passam a ser
respeitados e exigidos de forma mais conveniente. Há, no mercado várias empresas
A
de administração de condomínio, inclusive sindicatos e associações de empresas,
apóiam a gestão de condomínios.
IN
Se a revolução industrial imprimiu mudanças profundas na sociedade,
respondendo inclusive pela urbanização, a era da informação, também, tem
provocado alterações significativas na sociedade. A valorização do capital material
tem-se deslocado para a valorização do capital intelectual. A competitividade está
IM
diretamente relacionada à gestão e à aplicação do conhecimento. Embora, a

administração de um condomínio, sob o ponto de vista do condomínio, não implique
em competição com terceiros, a excelência dessa gestão traz ganhos aos
condôminos, sejam financeiros ou subjetivos ao se efetivar a possibilidade de
N
desfrutar de forma conveniente o investimento feito na aquisição ou locação do

imóvel.
U
Na busca dessa excelência, sistemas de informação que apóiem a

gestão, automatizando rotinas, padronizando atividades e armazenado informações
se tornam ferramentas importantes no processo de administração de condomínios.
Existem no mercado vários softwares voltados para administração de
condomínios. Alguns são disponíveis para venda outros de uso exclusivo da
administradora, sendo condicionado à contratação de serviços da empresa. A
maioria é acessada via Web, tanto pelo síndico, como pelos condôminos que têm
acesso às informações de despesa e, exclusivamente, às transações de sua
unidade. Algumas empresas apresentam vídeos demonstrativos do software, outras
22
permitem, inclusive, o uso de uma versão para teste. As funcionalidades mais

freqüentes oferecidas são:
- cadastros gerais;
- cálculos automáticos: rateios de despesas;
- mapas demonstrativos;
- emissão de boletos bancários e demonstrativos de despesas;
- taxas a receber;
- contas a pagar;
S
- tesouraria e fluxo de caixa;
- receitas e despesas regulares;
-
balancetes;
relatórios diversos. A
IN
Fazer uso de sistemas padronizados ou buscar softwares
customizados é uma decisão importante. As duas possibilidades apresentam
vantagens e desvantagens. Sistemas já desenvolvidos podem ter menor custo e
IM
apresentar mais funcionalidades, na medida em que são aprimorados mediante

solicitações dos vários clientes. Já softwares desenvolvidos para um cliente
específico podem atender às necessidades de forma mais objetiva.
N
1.3. IDENTIFICAÇÃO DO PROBLEMA
Optou-se pelo desenvolvimento de um sistema de informação

U
customizado, implicando em uma análise correta dos requisitos que o software

deverá atender, sejam eles funcionais ou não funcionais. Obter junto ao cliente de
forma clara as suas necessidades é fundamental para o desenho e implementação
do sistema.
O sistema desenvolvido nesse trabalho para um pequeno condomínio
demandará uma atenção maior, uma vez que esse cliente realiza as atividades de
forma intuitiva, sem o registro de processos.
23
1.4. OBJETIVOS
1.4.1. Geral
Desenvolver um aplicativo Web que apóie a gestão de pequenos

condomínios habitacionais, no que tange ao gerenciamento, a administração e o
armazenamento dos dados de moradores e proprietários, assim como das
operações financeiras.
1.4.2. Específicos
- Levantar os requisitos do sistema;
S
- documentar os casos de uso;
- elaborar o diagrama conceitual (diagrama de classe de negócio)
- A
elaborar os diagramas de seqüência de análise
implementar o sistema utilizando a linguagem de programação Java;

IN
- utilizar o Desing Patterns J2EE;
- implementar o aplicativo em três camadas de acordo com o modelo MVC;

IM
- implementar o diagrama de classes no nível de projeto;
- implementar a camada de apresentação através de Front Controller;
- implementar a camada de negócio através do Business Object;

N
- implementar a camada de integração utilizando DAO – Data Access Object;
- utilizar o Hibernate com annottations para o mapeamento objeto-relacional;

U
- utilizar o Struts2 com annottations e
- utilizar o MySQL como banco de dados.
1.5. JUSTIFICATIVA
Embora as atividades de gestão de um condomínio sejam em princípio

semelhantes, a abordagem pode ser diferente. Condomínios com muitas unidades se
tornam mais complexos, em função da quantidade de pessoas e consequentemente a
sua gestão implicará em atividades e rotinas diferentes das executadas naqueles com
24
poucas unidades. Há casos em que os moradores fazem uso de cartão de

identificação e não raro há catracas eletrônicas na portaria. Também é comum em
grandes condomínios a exigência de identificação, com registro de documento de
identidade dos visitantes.
Outros condomínios possuem uma administração mais informal, o que
não significa que não deva ter caráter legal. Ao se propor o desenvolvimento de um
sistema de informação para um condomínio com poucas unidades habitacionais, tem-
se a possibilidade de manter uma administração mais próxima e acolhedora. Assim,
alia-se o profissionalismo ao sentimento de proximidade, próprio de pequenos grupos
de pessoas, pois as relações tendem a ser mais próximas e pessoais.
Assim, desenvolver um software simplificado para a gestão de pequenos
S
condomínios traz o desafio de associar a tecnologia a uma gestão personalizada de
pequenos espaços residenciais, quando o mercado parece ofertar propostas mais
complexas.
A
Esse diferencial por si só justifica o desenvolvimento de uma nova
ferramenta, para atender a essa clientela.
IN
1.6. ORGANIZAÇÃO DO TRABALHO
Este foi um trabalho realizado em grupo, sendo que os membros se

envolveram em todas as etapas para a realização deste relatório. Os capítulos
IM
iniciais, Introdução e Especificação do Problema e, também, o capítulo final,

Conclusão foram escritos em conjunto, não havendo uma responsabilidade maior
por parte de algum integrante do grupo. Já, os demais capítulos que correspondem
às etapas de desenvolvimento do sistema tiveram cada um, um líder que assumiu o
N
direcionamento de sua elaboração. Assim, os demais seis capítulos abordam os

seguintes temas:
U
Capítulo 2: Especificação do problema

Traz as informações sobre o condomínio e apresenta de forma sucinta
o sumário executivo.
Capítulo 3: Análise e projeto do sistema
Apresenta o referencial teórico sobre análise de projeto, traz, ainda, os
diagramas classe, de casos de uso, de sequências, tanto sob a ótica da análise,
quanto sob o ponto de vista do projeto.
Capítulo 4: Arquitetura e código
25
Além discorrer sobre os conceitos nos quais se apoiou o

desenvolvimento da solução, este capítulo apresenta, ainda, a arquitetura
empregada e o código da implementação.
Capítulo 5: Interface
Nesse capítulo são apresentadas as interfaces para comunicação entre
o sistema e os usuários. Cita, ainda, referencial teórico, sobretudo em relação ao
uso de cores. Diferente dos demais capítulos, esse, em especial, não teve uma
autoria definida. Porém, os autores consideram a sua apresentação como mínima,
mas importante para a visão integral do sistema, mesmo que a abordagem da
interface seja superficial.
Capítulo 6: Persistência de dados
S
Apresenta o processo de armazenagem e recuperação dos dados.
Resgata os conceitos e tecnologias que foram empregados durante o
desenvolvimento do sistema.
Capítulo 7: Conclusões
A
IN
Nesta parte são apresentadas as conclusões observadas pelo grupo
considerando-se os objetivos que nortearam a realização deste trabalho.
IM
N
U
26
2. ESPECIFICAÇÃO DO PROBLEMA
O condomínio do Edifício Porto Seguro (Figura 2) foi criado em 17 de

março de 1997, com função estritamente residencial. É formado por seis unidades
habitacionais, distribuídas em três andares e uma área térrea. A área comum é
composta pelo saguão, as escadas, corredores internos e externos e a garagem. A
construção é simétrica, sendo a parte anterior igual à parte posterior. As unidades
são iguais, apenas as do primeiro pavimento possuem uma pequena área
descoberta, que não está presente nas unidades dos demais pavimentos. Para cada
apartamento existem duas vagas de garagem que foram definidas por sorteio
S
realizado pelos proprietários no momento do estabelecimento do condomínio.
A
IN
IM
N
U
Figura 2 – Fachada do edifício Porto Seguro.

27
Por se tratar de um condomínio com poucos integrantes, a

administração do imóvel vem sendo realizada por um dos condôminos que assume
a função de síndico. O valor da manutenção mensal é calculado a partir do rateio
das despesas, de modo que é pago após a realização das despesas. Dada a
proximidade e o pequeno número de moradores, a administração do imóvel é
realizada de forma bastante intuitiva e pouco formal. Assim, observam-se algumas
dificuldades no recebimento da taxa de condomínio e consequentemente o atraso no
pagamento de tarifas públicas, penalizando o conjunto dos moradores, uma vez que
não há a cobrança de multas ou juros dos moradores que pagam a sua parte do
rateio das despesas além do prazo.
Propõem-se, então o desenvolvimento de um sistema de informação
S
que apóie a administração do condomínio, que seja de fácil operação. Esse sistema
deverá registrar os moradores e proprietários das unidades, mantendo, inclusive o
A
histórico dessas informações, permitindo resgatá-las quando necessário. O software
deverá, ainda, registrar todas as contas a serem pagas para, então, gerar a taxa de
IN
condomínio, que é dada pelo rateio das despesas mensais. O recebimento da taxa
de condomínio será realizado até o 10º dia do mês subseqüente. Após essa data
incidiram juros e multa.
Será importante que o sistema registre todos os recebimentos da taxa
IM
de condomínio e também, o pagamento de todas as despesas do imóvel, o que

possibilitará gerar os recibos e a prestação de conta de forma automatizada.
N
U
28
3. ANÁLISE E PROJETO
Maria Margaret de Vasconcellos Lemos
Análise consiste em um método para se conhecer um problema ou

situação, em que se divide o objeto do estudo em partes para o exame minucioso de
cada componente. Voltada para desenvolvimento de software, a análise é o
processo através do qual se busca conhecer o negócio do cliente, para produzir um
modelo que espelhe a realidade.
S
O principal objetivo da análise de sistemas é realizar um mapeamento
prévio do comportamento requerido para os elementos de modelagem que serão
implementados posteriormente na fase de construção (SILVA, 2009).
A
Assim, modelagem é a concepção de sistemas de informações, antes
que sejam codificados. É, ainda, parte essencial do desenvolvimento de grandes
IN
projetos, sendo, também, importante para aqueles de médio e pequeno porte. Trata-
se de uma forma de visualizar o projeto e verificar se os requisitos estão sendo
atendidos antes da implementação (OBJECT MANEGEMMENT GROUP, 2009).
Dada a importância da elaboração de projetos de softwares, foi definida uma
IM
linguagem padrão para a sua execução, a Unified Modeling Language, UML.
3.1. UNIFIED MODELLING LANGUAGE – UML

N
As linguagens se destinam a comunicar algo através de vocabulários e

das regras de interação entre seus vocábulos. Assim, a UML indica como criar e ler
modelos bem formados. Um modelo escrito empregando-se a UML poderá ser
U
interpretado sem ambigüidades por outro desenvolvedor ou outra ferramenta.

Os blocos de construção da UML são os itens, os relacionamentos e os
diagramas. Os itens são as abstrações identificadas e podem ser de quatro tipos. Os
itens estruturais representam elementos conceituais ou físicos. São as partes
estáticas do modelo, enquanto que os itens comportamentais são as partes
dinâmicas, definidos pelos verbos, uma vez que representam o comportamento no
tempo e espaço. Os itens de agrupamento são as partes organizacionais.
Correspondem aos pacotes que são meramente conceituais e agregam os itens
29
estruturais, comportamentais e ainda outros itens de grupo, quando necessário. Já,

os itens anotacionais são aqueles que explicam o modelo.
Os relacionamentos definem a interação entre os elementos podendo
ser de quatro tipos. Dependência, acontece quando a alteração do item
independente implica na alteração semântica do item dependente. A associação
descreve a conexão entre os objetos, podendo ser uma agregação que define um
relacionamento estrutural entre o todo e suas partes. O relacionamento de
generalização implica em objetos especializados, os filhos, que podem ser
substituídos por objetos generalizados, os pais. O quarto tipo de relacionamento, a
saber, a realização, trata-se de um contrato em que um classificador especifica o
que outro classificador garante executar, como os métodos definidos pela interface
S
que a classe deve implementar.
Os diagramas são representações gráficas que oferecem vários
A
ângulos de visualização de um sistema. São nove os diagramas definidos pela UML,
sendo que cada um tem função bem definida. O diagrama de classes exibe o
IN
conjunto de classes, interfaces, colaborações e os relacionamentos, enquanto que o
diagrama de objeto apresenta os objetos e seus relacionamentos. Já, o diagrama de
casos de uso representa o conjunto de caos de uso e atores, sendo importante para
organização e modelagem de comportamento do sistema. Para registrar a interação
IM
há o diagrama de seqüência cujo foco principal é a ordem temporal das mensagens

e o diagrama de colaboração que privilegia a organização estrutural entre os
objetos. Outro diagrama, o de estado, exibe o estado, transição, eventos e
atividades. Traz, portanto, uma visão dinâmica do sistema, sendo o diagrama de
N
atividade um tipo especial de diagrama de estado, pois apresenta o fluxo de uma

atividade para outra. A visão estática da implementação do sistema pode ser
U
representada pelo diagrama de componentes que apresenta as organizações e de

pendências entre um conjunto de componentes. Já a visão estática de uma
arquitetura é oferecida pelo diagrama de implantação (BOOCH, RUMBAUGH &
JACOBSON, 2000).
3.2. ETAPAS DA ANÁLISE DE SISTEMA
A primeira etapa da análise de um sistema consiste na descoberta de

informações sobre o domínio da aplicação, quais as funcionalidades requeridas, qual
30
o desempenho que o sistema deve apresentar as restrições de hardware, dentre

outras questões. Responder a essas e outras perguntas envolvem grande número
de pessoas de diferentes áreas da empresa contratante. Essa fase é muito
importante, pois quanto mais claras as especificações, mais fiel à realidade será o
modelo.
Nesta fase são empregadas técnicas de elucidação de requisitos, com
o intuito de aumentar o comprometimento do cliente e desenvolvedores, com a
solução que se deseja construir. É muito importante que os requisitos sejam
extraídos de maneira correta e objetiva.
Nessa etapa são identificadas as regras de negócio e os requisitos do
sistema, que podem ser de dois tipos, os funcionais e os não funcionais.
S
3.3. REQUISITOS
A
Os requisitos descrevem de modo claro, sem ambigüidades, conciso e
IN
consistente todos os aspectos significativos do sistema proposto. Eles devem
permitir que os desenvolvedores construam um sistema que satisfaça os clientes.
Um requisito é considerado como funcional quando descreve um
serviço ou função a ser realizada. Já requisitos não funcionais coincidem com
IM
restrições ou condições impostas ao sistema ou ao seu desenvolvimento (SILVA,

BONIN & PALUDO, 2007).
O quadro 1 apresenta a relação dos requisitos funcionais e não
funcionais levantados para o desenvolvimento do sistema em questão.
N
Com o levantamento dos requisitos é possível identificar as classes

que estarão envolvidas no desenvolvimento do software e o reconhecimento dos
U
principais processos da empresa que definirão os casos de uso do sistema. Uma

vez estabelecidos e documentados os casos de uso, passa-se à etapa seguinte que
descreve as interações ocorridas no sistema, muito bem representadas pelos
diagramas de sequência.
31
Requisitos funcionais
1. Cadastrar proprietários;
2. cadastrar moradores;
3. registrar contas a pagar;
4. calcular o valor da taxa de condomínio;
5. registrar recebimento mensal da taxa de condomínio;
6. registrar pagamentos;
7. emitir recibos;
8. gerar prestação de contas.
S
Requisitos não-funcionais
1. Ser compatível com o Windows XP;

2.
3.
4.
permitir o acesso via Web;
usar a linguagem Java;
usar o contêiner web apache; A
IN
5. usar banco de dados MySQL
Quadro 1 – Requisitos do sistema.

IM
3.4. REGRAS DE NEGÓCIO
As regras de negócio dizem respeito às operações, definições e

restrições de uma organização para alcançar seus objetivos. São usadas para
alcançar os objetivos de uma empresa, a comunicação entre ela e terceiros e,
N
também, demonstrar as obrigações legais, operar mais eficientemente, automatizar

operações, dentre outras (ARAUJO, 2009). As regras de negócio podem ter origens
U
variadas. Há aquelas que são definidas por dispositivos legais, como o percentual a
ser pago a título de imposto ou o valor permitido para o cálculo de juros ou multas.
Outras definem as pessoas responsáveis por determinadas operações no sistema.
Existem, ainda, regras para cálculos internos, a obrigatoriedade de validação de
dados, como por exemplo, no sistema proposto, o CPF a ser cadastrado deverá ser
uma sequência numérica válida.
Para o sistema de condomínio, foram identificadas e documentadas
dez regras de negócio como apresenta o quadro 2 a seguir.
32
Nome Permissão RN - 01
Descrição Somente poderão operar o sistema as pessoas autorizadas.
Nome Cadastro de dados pessoais RN - 02
Descrição Somente serão cadastradas as pessoas com CPF válido.
Nome Cadastro de moradores RN - 03
Para cadastrar o morador de uma unidade é preciso ter registrado a

Descrição mudança do morador anterior. Assim, somente será cadastrado o
morador de uma unidade, quando não houver morador já cadastrado.
S
Nome Cadastro de proprietário RN - 04
Descrição
A
Para cadastrar o proprietário de uma unidade é preciso ter registrado
a venda realizada pelo proprietário anterior. Assim, somente será
cadastrado o proprietário de uma unidade, quando não houver
proprietário já cadastrado.
IN
Nome Lançamento de contas a pagar RN - 05
Descrição Todas as contas a pagar serão lançadas no sistema.

IM
Nome Geração da taxa de condomínio RN – 06
Descrição A taxa de condomínio será gerada sempre no dia 1º do mês.

N
Nome Cálculo da taxa de condomínio RN – 07

U
O valor da taxa de condomínio de cada unidade é calculado pela

Descrição soma dos pagamentos de contas realizados no mês anterior, dividido
por 6.
Nome Data para o pagamento da taxa de condomínio RN – 08
A taxa de condomínio deverá ser paga até o dia 10 do mês

Descrição subseqüente. Caso o dia 10 não seja dia útil, a data do pagamento
será automaticamente transferida para o próximo dia útil.
33
Nome Pagamento da taxa de condomínio RN - 09
Pagamentos realizados após a data estabelecida serão acrescidos

Descrição de juros de 2% ao mês e multa de 3%.
Nome Registro de pagamento da taxa de condomínio RN - 10
Todos os pagamentos de taxa de condomínio serão registrados no

Descrição sistema.
Quadro 2 – Regras de Negócio.
S
3.5. CLASSES
O diagrama de classes é considerado por vários autores como o mais

importante e utilizado diagrama da UML. Ele apresenta uma visão estática da
A
organização das classes do sistema, permitindo além da visualização das classes e
de seus atributos e métodos, a representação de seus relacionamentos, como estas
IN
se complementam e a transmissão da informação dentro do sistema (SILVA, 2007).
Durante o processo de análise, ao se delinear o sumário executivo,
como regra básica para nortear o analista, considera-se que os substantivos
encontrados sugerem as classes de negócios necessárias para o desenvolvimento
IM
da aplicação. Da mesma forma, os verbos descreveriam os casos de usos. Na

verdade, o levantamento das classes e dos casos de uso de um sistema, muitas
vezes, acontece de forma simultânea. A partir dessa visão e da proposta de
N
apresentar o diagrama de casos de uso seguido pelas especificações de cada caso

de uso e dos respectivos diagramas de sequência, serão apresentadas inicialmente
as classes e os diagrama de classes correspondente.
U
O processo de levantamento das necessidades e requisitos evidenciou

a necessidade de implementação de sete classes de negócio para o
desenvolvimento do sistema, conforme definidas abaixo:
Classe UsuarioEntidade
Essa classe registra o nome de usuário e a respectiva senha para
permitir a operação do sistema.
34
Classe Pessoa
É responsável pelo registro de todas as pessoas que se relacionam
com o imóvel, sejam moradores ou proprietários. Os atributos dessa classe são:
nome, CPF e telefone.
Classe Unidade
Registra todas as unidades habitacionais existentes, ou seja, os
apartamentos. Mantém o registro do atual morador e atual proprietário. Seus
atributos são: número, morador e proprietário.
Classe Histórico
Essa classe é responsável por manter o registro de todos os
moradores e proprietários de cada uma das unidades, registrando inclusive a data
S
inicial e a data do término da relação de cada pessoa com a unidade. Por isso tem
como atributos: unidade, proprietário, proDtAquisicao, pro_DtVenda, morador,
mor_DtEntrada e mor_DtSaida.
Classe ContasAPagar
A
IN
Essa classe é responsável pelo registro de todas as contas que o
condomínio deverá pagar em função de bens adquiridos ou serviços recebidos. Os
atributos dessa classe são: dataVencimento, descricaoConta, valorConta e mesRef.
Classe TaxaCondomínio
IM
Essa classe gera e mantém o valor mensal a ser pago pelos

condôminos a título de taxa de condomínio. Seus atributos são: mesRef, valorTaxa,
dataGeracao, datavencimento.
Classe LancamentoMes
N
É responsável pelo registro das operações financeiras do condomínio

mantendo os dados dos pagamentos e dos recebimentos das taxas de condomínio.
U
Os atributos dessa classe são: data, tipo, descrição, juros, multa e valorFinal.
Na etapa de análise foi usado o Enterprise Architect ferramenta
desenvolvida para a análise, modelagem e manutenção de softwares, que emprega
a UML e gera a documentação do sistema. Como um dos resultados do emprego
dessa ferramenta foi o diagrama de classes obtido pela interação das classes
descritas anteriormente (Figura 3).
35
U
N
IM
IN
A
Figura 3 – Diagrama de classes de negócio.
S
36
3.6. CASOS DE USO
Conceitualmente, casos de uso dizem respeito às principais atividades

da empresa ligadas ao sistema a ser implementado, sendo assim, cada caso de uso
está ligado a um conjunto de requisitos funcionais do sistema (WAZLAWICK, 2004).
A simplicidade de um diagrama de casos de uso permite a observação das
funcionalidades, os usuários envolvidos e as possíveis integrações com sistemas
externos (YOSHIMA, 2005). Foram identificados quatorze casos de uso, conforme a
figura 4.
S
A
IN
IM
N
U
Figura 4 – Diagrama de casos de uso.
A interação com o sistema é realizada pelo Síndico, pessoa

responsável pela gestão do condomínio. Outras pessoas, que por ventura operem o
sistema, somente o farão com a autorização do síndico e as permissões e
responsabilidades serão idênticas às dele. Por isso, para o desenvolvimento do
aplicativo, considerou-se, apenas a existência de um único ator.
37
3.6.1. Caso de Uso 01: Fazer Login
Nesse caso de uso, o síndico solicita entrar no sistema e para isso

informa os dados necessários para obter a permissão de operar o sistema, conforme
especificado no quadro 3.
Nome Fazer Login CSU - 01

Este caso de uso descreverá os procedimentos para realizar o login
Sumário
no sistema
Ator primário: Síndico.

Ator(es) secundário(s): Não há.
S
Pré-condição: O usuário estar cadastrado.
Pós-condição: O login foi realizado.
1. O síndico inicia sistema. A

Fluxo Principal
IN
2. O sistema apresenta o formulário para o login.
3. O síndico informa o usuário e a senha.
4. Sistema verifica os dados e encerra o caso de uso
IM
Fluxo Alternativo:
Não há.
Fluxo de Exceção [3]: Dados incorretos
N
a. O sistema informa que os dados estão incorretos e volta ao item 2.

Regras de Negócio Associadas
U
RN01
Quadro 3 – Especificação do caso de uso: Fazer Login.
38
O diagrama de sequência desse caso de uso apresenta o fluxo das

mensagens que são trocadas entre os componentes do sistema para permitir que o
usuário possa operar o sistema, como mostra a figura 5.
S
A
IN
Figura 5 – Diagrama de sequência do caso de uso: Fazer Login.
As classes de análise envolvidas neste caso de uso e os respectivos

IM
papéis são:
a) Interface de Fazer Login: representa a classe de fronteira desse caso de uso.

Permite que o usuário informe os dados para realizar o login no sistema, de
modo que possa operar o sistema.
N
b) Controlador de Fazer Login: representa a classe de controle deste caso de uso.

Sua função é interpretar os comandos realizados entre a interface Fazer Login
U
e a classe Usuários.
c) Usuários: representa a classe de entidade deste caso de uso. Sua função é

armazenar os atributos responsáveis por realizar a autenticação dos dados do
usuário.
d) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.

É apresentada após a autenticação do login.
39
3.6.2. Caso de Uso 02: Cadastrar Dados
Neste caso de uso, o síndico fará o cadastro de uma pessoa que terá
relação com o condomínio de moradia ou de propriedade. O sistema não permitirá o
cadastro de morador ou proprietário de uma unidade se outra pessoa já estiver
cadastrada nessa situação. Para isso é necessário registrar, anteriormente a saída
ou a venda da unidade (Quadro 4) .
Nome Cadastrar Dados CSU - 02

Este caso de uso descreverá os procedimentos realizados para o
S
Sumário cadastro dos dados pessoais de proprietários ou moradores e a
unidade com a qual manterão relação.
A
Pré-condição: Não haver registro de pessoa na unidade, na condição a ser
registrada.
IN
Pós-condição: O cadastro foi realizado.
Fluxo Principal
1. O síndico solicita o cadastro de dados pessoais.
IM
2. O sistema apresenta o formulário para o preenchimento dos dados.

3. O síndico realiza o preenchimento do formulário.
4. O síndico confere os dados inseridos no formulário e confirma.
5. Sistema registra o cadastro e encerra o caso de uso
N
Fluxo Alternativo:
Não há.
U
Fluxo de Exceção [4A]: CPF inválido

a. O sistema informa que o CPF não é válido e volta ao item 3.
Fluxo de Exceção [4B]: Existe morador ou proprietário cadastrado
a. O sistema informa que não é possível cadastrar a pessoa na condição
escolhida e encerra o caso de uso.
RN02, RN03 e RN04
Quadro 4 – Especificação do caso de uso: Cadastrar Dados.
40
O diagrama deste caso de uso exibe o fluxo de interação,

apresentando a sequência das mensagens para a sua execução (Figura 6).
S
A
IN
IM
Figura 6 – Diagrama de sequência do caso de uso: Cadastrar Dados.

N
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o síndico solicita o cadastro de uma pessoa.
U
b) Controlador de Cadastrar Dados: representa a classe de controle deste caso de

uso. Sua função é interpretar os comandos realizados entre as interfaces e as
classes de entidades Pessoa, Unidade e Histórico, responde, ainda, pela
validação do CPF.
c) Interface de Cadastrar Dados: representa a classe de fronteira desse caso de

uso. Permite que o usuário informe os dados para cadastrar uma pessoa no
sistema.
41
d) Pessoa: representa uma das classes de entidade deste caso de uso. Sua
função é armazenar os atributos das pessoas cadastradas, nome; CPF e
telefone.
e) Unidade: representa outra classe de entidade deste caso de uso. Sua função é
armazenar os atributos das unidades, o número da unidade, a pessoa que é
moradora, assim como a pessoa que é proprietária da unidade em questão.
f) Histórico: representa a terceira e última classe de entidade deste caso de uso.

Sua função é armazenar os atributos das relações entre as pessoas e as
unidades. Mantendo os dados mesmo após o término dessa relação. Os
atributos dessa classe são: o número da unidade; a pessoa moradora; a data
S
de entrada e a data de saída do morador; a pessoa que é proprietária; a data
de aquisição e a data de venda relativa a esse proprietário.
A
IN
IM
N
U
42
3.6.3. Caso de Uso 03: Listar Pessoas
Esse caso de uso descreve os procedimentos que serão realizados

para o sistema apresentar a relação das pessoas que já se encontram cadastradas,
como mostra o quadro 5.
Nome Listar Pessoas CSU - 03

Este caso de uso descreve os procedimentos realizados para
Sumário
apresentar os dados de todas as pessoas cadastradas.
S
Pré-condição: Ter pessoas cadastradas no sistema.
A
Pós-condição: A lista com os dados das pessoas cadastradas é apresentada.
Fluxo Principal
1. O síndico solicita listar todas as pessoas cadastradas.
IN
2. O sistema apresenta o cadastro de pessoas com CPF, nome e o telefone
de cada pessoa.
3. O caso de uso é encerrado.
IM
Fluxo Alternativo:
Não há.
Fluxo de Exceção [4]: O cadastro está vazio

a. O sistema emite mensagem informando que o cadastro está vazio.
N
b. O caso de uso é encerrado

U
Quadro 5 – Especificação do caso de uso: Listar Pessoas.

43
S
A
Figura 7 – Diagrama de sequência do caso de uso: Listar Pessoas.

IN
papéis são:
No caso, o síndico solicita a lista das pessoas cadastradas.
IM
b) Controlador de Listar Pessoas: representa a classe de controle deste caso de

uso. Sua função é interpretar os comandos realizados entre o Menu Inicial e a
classe de entidade Pessoa, responde, ainda, pela verificação se a lista não está
vazia.
N
c) Interface de Listar Pessoas: representa a classe de fronteira desse caso de uso,

apresenta a lista das pessoas cadastradas.
U
d) Pessoa: representa a classe de entidade deste caso de uso. Sua função é

armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
44
3.6.4. Caso de Uso 04: Consultar Pessoa

para a consulta dos dados de uma pessoa já cadastrada no sistema, como mostra o
quadro 6.
Nome Consultar Pessoa CSU - 04

Sumário
consultar o cadastro de uma pessoa.

S
Pré-condição: A pessoa estar cadastrada no sistema.
Pós-condição: Os dados da pessoa foram recuperados.
A
Fluxo Principal
1. O síndico solicita consultar o cadastro de uma pessoa.
IN
2. O sistema solicita o CPF da pessoa.
3. O síndico informa o CPF.
4. O sistema apresenta o nome e o telefone da pessoa.
IM
Fluxo Alternativo [4]: A pessoa não está cadastrada

a. O sistema emite mensagem informando que a pessoa não foi cadastrada.
b. O caso de uso é encerrado.
N
Fluxo de Exceção [3]: O CPF informado não é válido

a. O sistema emite mensagem informando que o CPF não é válido.
b. O sistema volta ao item 2.
U
c. O caso de uso é encerrado

RN 02
Quadro 6 – Especificação do caso de uso: Consultar Pessoa.

45
S
A
IN
Figura 8 – Diagrama de sequência do caso de uso: Consultar Pessoa.

papéis são:
IM

No caso, o síndico solicita a consultar cadastro.
b) Controlador de Consultar Pessoa: representa a classe de controle deste caso

de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a
N
interface de Consultar Pessoa e a classe de entidade Pessoa. Responde, ainda,

pela validação do CPF.
U
c) Interface de Consultar Pessoas: representa a classe de fronteira desse caso de

uso. Disponibiliza ao usuário o formulário para obter o CPF da pessoa que
será consultada e apresenta ao síndico o nome e o telefone da pessoa
consultada.
d) Pessoa: representa uma das classes de entidade deste caso de uso. Sua
telefone.
46
3.6.5. Caso de Uso 05: Consultar Unidade

para a consulta dos dados de uma unidade, como mostra o quadro 7.
Nome Consultar Unidade CSU - 05

Sumário
consultar os dados de cadastro de uma unidade.

S
Pré-condição: A unidade estar cadastrada no sistema.
Pós-condição: Os dados da unidade foram recuperados.
A
Fluxo Principal
1. O síndico solicita a consulta de dados de uma unidade.
2. O sistema solicita o número da unidade.
IN
3. O síndico informa o número.
4. O sistema apresenta o morador e o proprietário da unidade.
IM
Fluxo Alternativo:
Não há.
Fluxo de Exceção:
N
Não há.

U
Quadro 7 – Especificação do caso de uso: Consultar Unidade.

47
S
A
IN
Figura 9 – Diagrama de sequência do caso de uso: Consultar Unidade.
IM

papéis são:
No caso, o síndico solicita consultar os dados de uma unidade.
N
b) Controlador de Consultar Unidade: representa a classe de controle deste caso

interface de Consultar Unidade e as classes de entidades Unidade e Pessoa.
U
c) Interface de Consultar Unidade: representa a classe de fronteira desse caso de

uso. Disponibiliza ao síndico o formulário para obter o número da unidade a ser
consultada e como resposta, apresenta o nome do morador e do proprietário da
unidade consultada.
d) Unidade: representa uma das classes de entidade deste caso de uso. Sua
função é armazenar os atributos das unidades, o número da unidade, a pessoa
48
que é moradora, assim como a pessoa que é proprietária da unidade em

questão.
e) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é
S
A
IN
IM
N
U
49
3.6.6. Caso de Uso 06: Atualizar Histórico

para atualizar os dados do histórico de uma unidade. Nesse caso de uso, as regras
de negócio associadas, determinam que o mesmo seja executado e não interferem
no processo de sua realização. Sendo assim, não geram fluxo de exceção, como
mostra o quadro 8.
Nome Atualizar Histórico CSU - 06

Este caso de uso descreverá os procedimentos realizados para
Sumário
atualizar os dados do histórico de determinada unidade.
S
Ator primário: Síndico
Ator(es) secundário(s): Não há
A
Pré-condição: Haver histórico anterior em aberto.
Pós-condição: O histórico foi atualizado.
IN
Fluxo Principal
1. O síndico solicita a atualização o histórico de uma unidade.

2. O sistema apresenta o formulário para a atualização dos dados do histórico
IM
de uma unidade.
3. O síndico realiza o preenchimento do formulário.
4. O síndico confere os dados inseridos no formulário e confirma.
5. Sistema registra a atualização e encerra o caso de uso
N
Fluxo Alternativo [3A]: Cadastro de venda

a. O síndico informa que é registro de venda do imóvel.
U
Fluxo Alternativo [3B]: Cadastro de saída

a. O síndico informa que é registro de saída do imóvel.
Fluxo de Exceção:
Não há.
RN 03 e RN 04
Quadro 8 – Especificação do caso de uso: Atualizar Histórico.
50

S
A
Figura 10 – Diagrama de sequência do caso de uso: Atualizar Histórico.
IN
papéis são:
IM

No caso, o síndico solicita atualizar os dados de histórico de uma unidade.
b) Controlador de Atualizar Histórico: representa a classe de controle deste caso

N
interface de Atualizar Histórico e as classes de entidade Histórico e Unidade.
c) Interface de Atualizar Histórico: representa a classe de fronteira desse caso de

U
uso. Disponibiliza ao usuário o formulário para obter os dados que deverão ser
atualizados.
d) Histórico: representa uma das classes de entidade deste caso de uso. Sua
questão.
e) Unidade: representa uma das classes de entidade deste caso de uso. Sua
51

questão.
3.6.7. Caso de Uso 07: Pesquisar Histórico

para pesquisar os dados de histórico de uma unidade, como mostra o quadro 9.
Nome Pesquisar Histórico CSU - 07

Sumário
pesquisar o histórico de uma dada unidade.
S
Ator(es) secundário(s): Haver histórico registrado anteriormente.
Pré-condição: Não há.
A
Pós-condição: A lista com o histórico da unidade é apresentada.
IN
Fluxo Principal
1. O síndico solicita a pesquisa do histórico.
2. O sistema solicita o número da unidade para a pesquisa.
IM
3. O síndico informa o número da unidade.

4. O sistema exibe os dados.
Fluxo Alternativo [4A]: O cadastro está vazio

N
a. O sistema emite mensagem informando que não há registro de histórico da

unidade.
U
Fluxo de Exceção:
Não há.
Quadro 9 – Especificação do caso de uso: Pesquisar Histórico.

52

S
A
IN
Figura 11 – Diagrama de sequência do caso de uso: Pesquisar Histórico.

papéis são:
IM

No caso, o síndico solicita pesquisar os dados de histórico.
b) Controlador de Pesquisar Histórico: representa a classe de controle deste caso

N

interface de Pesquisar Histórico e a classe de entidade Histórico.
c) Interface de Atualizar Histórico: representa a classe de fronteira desse caso de

U
uso. Disponibiliza ao síndico o formulário para que informe qual unidade

deverá ter o histórico pesquisado.
questão.
53
3.6.8. Caso de Uso 08: Registrar Conta a Pagar

para registrar contas a pagar. Embora haja regra de negócio envolvida na realização
desse caso de uso, esta não interfere em sua execução, apenas determina que deve
ser executado, como mostra o quadro 10.
Nome Registrar Contas a Pagar CSU - 08
Este caso de uso apresenta os passos para o registro das contas a

Sumário
pagar.
S
Pré-condição: Não há.
Pós-condição: A conta foi registrada.
A
Fluxo Principal
IN
1. O sindico solicita o registro de contas a pagar.
2. O sistema apresenta as opções do tipo de conta a ser registrada.
3. O síndico escolhe o tipo de conta.
IM
4. O sistema solicita os dados da conta.

5. O sistema registra as informações no banco de dados.
N
Fluxo Alternativo:
Não há.
U
Fluxo de Exceção:
Não há.

RN 05
Quadro 10 – Especificação do caso de uso: Registrar Conta a Pagar.

54
S
A
IN
Figura 12 – Diagrama de sequência do caso de uso: Registrar Contas a Pagar.

IM
papéis são:
No caso, o síndico solicita registrar uma conta que deverá ser paga
posteriormente.
N
b) Controlador de Registrar Contas a Pagar: representa a classe de controle deste

caso de uso. Sua função é interpretar os comandos realizados entre o Menu
Inicial, a interface de Registrar Contas a Pagar e a classe de entidade Contas a
U
Pagar.
c) Interface de Contas a Pagar: representa a classe de fronteira desse caso de

uso. Disponibiliza ao usuário o formulário para preenchimento dos dados da
conta em questão.
d) Contas a Pagar: representa a classe de entidade deste caso de uso. Sua

função é armazenar os atributos das contas que serão pagas, a data de
vencimento, a descrição e o valor da conta e também, o mês de referência.
55
3.6.9. Caso de Uso 09: Registrar Pagamento de Contas

para registrar o pagamento de contas, como mostra o quadro 11.
Nome Registrar Pagamento de Contas CSU - 09
Este caso de uso apresenta os procedimentos para o registro dos

Sumário
pagamentos realizados pelo condomínio.
Ator(es) secundário(s): não há.
Pré-condição: A conta a pagar ter sido cadastrada anteriormente.
S
Pós-condição: O pagamento da conta foi registrado.
Fluxo Principal
A
1. O síndico solicita o registro do pagamento de contas.
2. O sistema apresenta as contas já cadastradas.
IN
3. O síndico seleciona a conta.
4. O sistema apresenta as informações da conta e solicita o preenchimento
dos dados complementares.
5. O síndico informa os dados.
IM
6. O sistema registra as informações.

7. O sistema encerra o caso de uso.
Fluxo Alternativo:
N
Não há.
Fluxo de Exceção [2]: Não há conta cadastrada.
a) O sistema informa que não há conta cadastrada.
U
b) O sistema encerra o caso de uso.

Fluxo de Exceção [4]: Não há conta para pagar.
a. O sistema informa que não há conta para pagar.
b. O sistema encerra o caso de uso.
RN 05
Quadro 11 – Especificação do caso de uso: Registrar Pagamento de Contas.
56

S
A
IN
IM
Figura 13 – Diagrama de sequência do caso de uso: Registrar pagamento de Contas.

papéis são:
N

No caso, o síndico solicita registrar o pagamento de uma conta.
b) Controlador de Registrar Pagamento de Contas: representa a classe de

U
controle deste caso de uso. Sua função é interpretar os comandos realizados

entre o Menu Inicial, a interface de Registrar Pagamento de Contas, e as
classes de entidade Contas a Pagar e Lançamento Mês.
c) Interface de Registrar Pagamento de Contas: representa a classe de fronteira

desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento
dos dados para o pagamento de uma conta. Na sequência apresenta as contas
que podem ser pagas para que o síndico escolha a que irá pagar e informe os
dados do pagamento.
57
d) Contas a Pagar: representa uma das classes de entidade deste caso de uso.
Sua função é armazenar os atributos das contas que serão pagas, a data de
e) Lançamento Mês: corresponde a outra classe de entidade envolvida nesse

caso de uso. Sua função é armazenar os atributos dos lançamentos financeiros,
data, tipo, descrição, juros, multa e valor final.
S
A
IN
IM
N
U
58
3.6.10. Caso de Uso 10: Gerar Taxa de Condomínio

Nome Gerar Taxa de Condomínio CSU - 10

Este caso de uso descreve as etapas para gerar as taxas mensais
Sumário de condomínio.
Pré-condição: Haver contas a pagar cadastradas anteriormente.
S
Pós-condição: O valor da taxa ter sido calculado.
Fluxo Principal
1.
2.
3. A
O síndico solicita a geração da taxa mensal de condomínio.
O sistema solicita o período de referência da taxa a ser gerada.
O síndico informa o período.
IN
4. O sistema gera e apresenta a taxa de condomínio do período solicitado.
Fluxo Alternativo:
IM
Não há.
Fluxo de Exceção [4]: Não há conta cadastrada.
a. O sistema informa que não há contas cadastradas e retorna ao item 4.
N
RN05, RN06 e RN 07
Quadro 12 – Especificação do caso de uso: Gerar Taxa de Condomínio.
U
59

S
A
IN
IM
Figura 14 – Diagrama de sequência do caso de uso: Gerar Taxa de Condomínio.

papéis são:
N

No caso, o usuário solicita a geração da taxa de condomínio de um
determinado mês.
U
b) Controlador de Gerar Taxa de Condomínio: representa a classe de controle

deste caso de uso. Sua função é interpretar os comandos realizados entre o
Menu Inicial, a interface de Gerar Taxa de Condomínio, e as classes de
entidade Contas a Pagar e Taxa de Condomínio.
c) Interface de Gerar Taxa de Condomínio: representa a classe de fronteira desse

caso de uso. Disponibiliza ao síndico o formulário para preenchimento dos
dados para a geração da taxa de condomínio de um determinado mês.
60
d) Contas a Pagar: representa uma das classes de entidade deste caso de uso.
e) Taxa de Condomínio: corresponde a outra classe de entidade envolvida nesse

caso de uso. Sua função é armazenar os atributos da taxa de condomínio, mês
de referência, o valor da taxa, a data de geração e a data de vencimento da
taxa de condomínio.
S
A
IN
IM
N
U
61
3.6.11. Caso de Uso 11: Receber Taxa de Condomínio

Nome Receber Taxa de Condomínio CSU - 11

Este caso de uso descreve as etapas para realizar o registro do
Sumário recebimento de taxas do condomínio.
Pré-condição: O valor da taxa ter sido calculado anteriormente.
S
Pós-condição: O pagamento da taxa é registrado.
Fluxo Principal
A
1. O síndico solicita o registro de pagamento da taxa.
2. O sistema solicita os dados para registrar o recebimento da taxa de
IN
condomínio.
4. O sistema solicita a confirmação.
5. O síndico confirma os dados.
IM
6. O sistema apresenta o recibo.

Fluxo de Alternativo [3]: O pagamento está sendo realizado fora do prazo

N
a. O sistema calcula e apresenta os juros e a multa.
Fluxo de Exceção [3]: A taxa não foi gerada.

U
a. O sistema informa que a taxa não foi gerada e encerra o caso de uso.
RN 08, RN09 e RN 10
Quadro 13 – Especificação do caso de uso: Receber Taxa de Condomínio.
62

S
A
IN
IM
Figura 15 – Diagrama de sequência do caso de uso: Receber Taxa de Condomínio.

papéis são:
N

No caso, o síndico solicita a registrar o recebimento de taxa de condomínio.
b) Controlador de Receber Taxa de Condomínio: representa a classe de controle

U
deste caso de uso. Sua função é interpretar os comandos realizados entre o

Menu Inicial, a interface de Receber Taxa de Condomínio, e as classes de
entidade Taxa de Condomínio, Lançamento Mês, Unidade e Pessoa.
c) Interface de Receber Taxa de Condomínio: representa a classe de fronteira

desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento
dos dados para o registro do recebimento da taxa de condomínio referente a
uma unidade e determinado mês.
63
d) Taxa de Condomínio: corresponde a uma das classes de entidade envolvida

nesse caso de uso. Sua função é armazenar os atributos da taxa de
condomínio, mês de referência, o valor da taxa, a data de geração e a data de
vencimento da taxa de condomínio.
e) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse

f) Unidade: representa uma das classes de entidade deste caso de uso. Sua
S
questão.
g) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é
A
IN
IM
N
U
64
3.6.12. Caso de Uso 12: Gerar Recibo

Nome Gerar Recibo CSU - 12

Este caso de uso descreve as etapas para gerar o recibo de
Sumário pagamento da taxa de condomínio.

S
Pré-condição: A taxa ter sido paga.
Pós-condição: O recibo foi gerado.
A
Fluxo Principal
1. O síndico solicita a geração de recibo.

IN
2. O sistema solicita os dados para a geração do recibo.
4. O sistema solicita confirmação.
IM
6. O sistema gera o recibo.

Fluxo de Alternativo:
N
Não há.
U
Fluxo de Exceção: Não há registro de pagamento da taxa.
a. O sistema informa que não há pagamento da taxa.

Quadro 14 – Especificação do caso de uso: Gerar Recibo.

65

S
A
IN
Figura 16 – Diagrama de sequência do caso de uso: Gerar Recibo.
IM

papéis são:
No caso, o síndico solicita a geração de recibo.
N
b) Controlador de Gerar Recibo: representa a classe de controle deste caso de

uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a
U
interface de Gerar Recibo, e as classes de entidade, Lançamento Mês,

Histórico e Pessoa.
c) Interface de Gerar Recibo: representa a classe de fronteira desse caso de uso.

Disponibiliza ao síndico o formulário para preenchimento dos dados para a
geração do recibo da taxa de condomínio referente a uma unidade em
determinado mês.
66

questão.
e) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é
f) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse

S
A
IN
IM
N
U
67
3.6.13. Caso de Uso 13: Gerar Balancete

Nome Gerar Balancete CSU - 13

Este caso de uso descreve as etapas para gerar o balancete de
Sumário determinado período.

S
Pré-condição: Haver registro de movimento no período solicitado.
Pós-condição: O balancete foi gerado.
A
Fluxo Principal
1. O síndico solicita a geração de balancete.
IN
2. O sistema solicita os dados para a geração do balancete.
IM
6. O sistema gera o balancete.

N
Não há.
Fluxo de Exceção: Não há registro de movimentação financeira no período

U
a. O sistema informa que não há movimentação financeira no período.

RN 08, RN09 e RN 10
Quadro 15 – Especificação do caso de uso: Gerar Balancete.
68

S
A
IN
IM
Figura 17 – Diagrama de sequência do caso de uso: Gerar Balancete.

papéis são:
N

No caso, o síndico solicita a geração de balancete.
b) Controlador de Gerar Balancete: representa a classe de controle deste caso de

U

interface de Gerar Balancete, e as classes de entidade Contas a Pagar e
Lançamento Mês.
c) Interface de Gerar Balancete: representa a classe de fronteira desse caso de

uso. Disponibiliza ao síndico o formulário para preenchimento dos dados para
a geração de um balancete de determinado período.
69
d) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse

e) Contas a Pagar: representa uma das classes de entidade deste caso de uso.
S
A
IN
IM
N
U
70
3.6.14. Caso de Uso 14: Gerar Histórico

Nome Gerar Histórico CSU - 14

Este caso de uso descreve as etapas para gerar o histórico de
Sumário determinada unidade.
Pré-condição: Haver histórico cadastrado anteriormente.
S
Pós-condição: O Histórico foi gerado.
Fluxo Principal
A
1. O síndico solicita a geração de histórico.
2. O sistema solicita os dados para a geração do histórico.
IN
6. O sistema gera o histórico.
IM
Não há.
N
Fluxo de Exceção: Não há registro de histórico para a unidade

U
a. O sistema informa que não há histórico para a unidade.

Quadro 16 – Especificação do caso de uso: Gerar Histórico.

71

S
A
IN
Figura 18 – Diagrama de sequência do caso de uso: Gerar Balancete.
IM

papéis são:
No caso, o síndico solicita a geração de histórico.
N
b) Controlador de Gerar Histórico: representa a classe de controle deste caso de

U
interface de Gerar Histórico, e as classes de entidade Histórico e Pessoa.
c) Interface de Gerar Histórico: representa a classe de fronteira desse caso de uso.

Disponibiliza ao síndico o formulário para preenchimento dos dados para a
geração do Histórico de determinada unidade.
d) Histórico: representa a terceira e última classe de entidade deste caso de uso.

Sua função é armazenar os atributos das relações entre as pessoas e as
unidades. Mantendo os dados mesmo após o término dessa relação. Os
atributos dessa classe são: o número da unidade; a pessoa moradora; a data
72
de entrada e a data de saída do morador; a pessoa que é proprietária; a data

de aquisição e a data de venda relativa a esse proprietário.
e) Pessoa: representa uma das classes de entidade deste caso de uso. Sua
telefone.
3.7. PROJETO
Após a análise, há a definição da tecnologia e arquitetura empregadas

no desenvolvimento do sistema. Nesse trabalho, foram definidos o emprego do
business object, de classes action e do data access object, esses componentes
S
serão apresentados com mais detalhes no capítulo 4 “Arquitetura e Código” e
capítulo 6 “Persistência de Dados” ficando limitado ao capítulo atual a apresentação
entre as classes.
A
das classes de projeto e dos diagramas de sequência gerados a partir da interação
Desta forma, após definidos os requisitos; os casos de uso;

IN
estabelecidas as classes de negócio e as suas interações através dos diagramas de
seqüência, o processo de elaboração do projeto definiu a existência de outras
classes. De modo que, além das classes já apresentadas, foram incluídas no
IM
projeto as seguintes classes:
− UsuarioEntidade; − UnidadeBO;
− HibernateUtil; − UnidadeDAO;
− LoginBO; − UnidadeHibernateDAO;
N
− LoginCO; − HistoricoBO;
− LoginDAO; − HistoricoDAO.
U
− Login2; − HistoricoHibernateDAO;
− PessoaBO; − CadastrarPessoaAction e
− PessoaDAO; − PesquisarAction.
− PessoaHibernateDAO;
A documentação apresentada a seguir foi gerada por engenharia

reversa se utilizando a ferramenta MDG que integra o Eclipse ao Enterprise Architect.
73
Assim,, a partir do código foram elaborados os diagramas estáticos, respeitando os

pacotes com os quais a aplicação foi organizada.
As classes de negócio e a classe UsuarioEntidade foram agrupadas no

pacote entidade como mostra a figura 19.
S
A
IN
IM
N
U
Figura 19 – Classes do pacote entidades.

74
No pacote bo se concentraram as seguintes classes: LoginBO;

PessoaBO; UnidadeBO e HistoricoBO (Figura 20).
S
A
Figura 20 – Classes do pacote bo.
IN
As classes de persistência, aquelas com terminação “DAO” e, ainda, a
IM
classe HibernateUtil, estão presentes no pacote DAO, como representado pela

figura 21.
N
U
Figura 21 – Classes do pacote persistência.

75
E finalmente, as classes Login2; CadastrarPessoaAction e

PesquisarAction estão localizadas em um mesmo pacote como apresentado na
figura 22.
S
A
IN
IM
N
U
Figura 22 – Classes do pacote action.

76
3.7.1. Diagramas de Sequência de Projeto
Os diagramas de sequência em nível de projeto envolvem as classes

de negócio e, também, as classes criadas para o desenvolvimento, considerando a
tecnologia escolhida para a implementação do aplicativo.
3.7.1.1 Caso de Uso 01: Fazer Login
Esse diagrama ilustra os passos do sistema para realizar o login do

usuário ao sistema, como mostra a figura 23.
S
A
IN
IM
N
U
77
U
N
IM
IN
A
S
Figura 23 – Diagrama de sequência com as classes de projeto do caso de uso: Fazer Login.
78
3.7.1.2 Caso de Uso 02: Cadastrar Dados
Esse diagrama apresenta a sequência e a comunicação entre as

classes de projeto do sistema para cadastrar os dados dos moradores e
proprietários de unidades do condomínio, como apresentado na figura 24.
S
A
IN
IM
N
U
79
U
N
IM
IN
A
S
Figura 24 – Diagrama de sequência com as classes de projeto do caso de uso: Cadastrar Dados.
80
3.7.1.3 Caso de Uso 03: Listar Pessoas
A sequência realizada pelo sistema para listar as pessoas cadastradas

no sistema está ilustrada na figura 25.
S
A
IN
IM
N
U
81
U
N
IM
IN
A
S
Figura 25 – Diagrama de sequência com as classes de projeto do caso de uso: Listar Pessoas.
82
3.7.1.4 Caso de Uso 04: Consultar Pessoa
O comportamento do sistema e as classes envolvidas na realização do

caso de uso Consultar Pessoa estão representados na figura 26.
S
A
IN
IM
N
U
83
U
N
IM
IN
A
S
Figura 26 – Diagrama de sequência com as classes de projeto do caso de uso: Consultar Pessoa.
84
3.7.1.5 Caso de Uso 05: Consultar Unidade
Esse diagrama apresenta as classes envolvidas e a relação entre elas

para a realização do caso de uso Consultar Unidade (Figura 27).
S
A
IN
IM
N
U
85
U
N
IM
IN
A
S
Figura 27 – Diagrama de sequência com as classes de projeto do caso de uso: Consultar Unidade.
86
3.7.1.6 Caso de Uso 06: Atualizar Histórico
Esse diagrama representa o comportamento do sistema para realizar o

caso de uso Atualizar Histórico (Figura 28).
S
A
IN
IM
N
U
87
U
N
IM
IN
A
S
Figura 28 – Diagrama de sequência com as classes de projeto do caso de uso: Atualizar Histórico.
88
4. ARQUITETURA E CÓDIGO
Com a crescente necessidade de automação de processos para

melhor desempenho na execução das tarefas se aumentou, também, a utilização de
software dentro de vários setores de uma organização para apoiar as rotinas diárias,
Diante desse cenário foi desenvolvida uma aplicação específica para o
Condomínio do Edifício Porto Seguro com o objetivo de apoiar a administração deste
S
condomínio, permitindo o acompanhamento de sua ocupação bem como gestão
financeira da manutenção mensal do imóvel. Para essa aplicação o padrão de
utilizado foi de desenvolvimento em camadas para que fique separado por módulos
A
de apresentação, negócios e integração.
A arquitetura de software é a maneira como está estruturado o sistema,
IN
ou seja, quais os componentes estão presentes e as relações entre esses
componentes (AHMED & UMRYSH, 2002).
Através do modelo de arquitetura o desenvolvedor visualiza com mais
facilidade o funcionamento do sistema, como serão dispostos os seus componentes,
IM
facilitando, assim, o entendimento e a manutenção do mesmo. Por isso é muito

importante que a arquitetura seja bem definida para que o sistema atenda todas as
necessidades definidas nos requisitos de forma bem estruturada.
É um grande desafio construir uma aplicação bem estruturada e de
N
fácil manutenção. Portanto no desenvolvimento do sistema do Edifício Porto Seguro

foi utilizada a linguagem de programação Java, aplicando-se a programação
U
orientada a objetos além do uso da arquitetura em três camadas MVC (Model, View,
Controller), plataforma J2EE, através do Eclipse e com os framewoks Struts e
Hibernate.
4.1. JAVA
É uma linguagem de programação de alto nível orientada a objetos

desenvolvida por uma equipe comandada por James Gosling na Sun Microsystens
na década de 90.
89
Essa linguagem foi projetada para ser pequena, simples e portável a

todas as plataformas e sistemas operacionais e, ainda, integrada à Internet, Java,
também, é uma excelente linguagem para desenvolvimento de aplicações em geral
(APOSTILA, 2009). Por se tratar de uma linguagem orientada a objeto, é necessário
o conhecimento desse paradigma para usá-la adequadamente. É compilada para
bytecode que é executado pela JVM (Java Virtual Machine) responsável por
administrar a memória e possui um coletor de lixo automático. O compilador e a JVM
estão disponíveis no JDK (Java Development Kit) kit de desenvolvimento Java.
De acordo com Wikipedia (2009a):
Java ainda é um standard de fato, que é controlada através da JCP Java
Community Process. Em 13 de Novembro de 2006, a Sun lançou a maior
S
parte do Java como Software Livre sob os termos da GNU General Public
License (GPL). Em 8 de Maio de 2007 a Sun finalizou o processo, tornando
praticamente todo o código Java como software de código aberto, menos
uma pequena porção da qual a Sun não possui copyright.
4.2. ARQUITETURA MVC
A
O aumento do uso de aplicações distribuídas provê mudanças nos
IN
projetos de software. Sendo assim no sistema do Edifício Porto Seguro foi utilizada a
arquitetura MVC que é um modelo de aplicação em três camadas, nesse modelo as
responsabilidades ficam divididas.
IM
A arquitetura MVC (Model-View-Controller) separa em camadas a

aplicação, mas não deixando de integrá-las. Segundo Alur, Crupi e Malks (2004,
p.102):
Uma camada equivale a um dos particionamentos lógicos dos diversos
aspectos tratados em um sistema. A cada camada é atribuída sua
N
responsabilidade distinta, ou única, no sistema. Visualizamos cada camada

como separadas logicamente entre si. Cada camada não está estritamente
acoplada com a camada adjacente.
U
Sendo assim, as camadas trabalham juntas e a manutenção do código

é facilitada. Este modelo descreve a organização de uma aplicação em três
módulos:
- Model (Modelo): compreende o modelo de aplicação, contendo a
representação de dados e de lógica de negócios, onde ficam as classes de
persistência, business object, entidades e DAO (Data Access Objetct);
- View (Apresentação): trata aspectos relacionados à apresentação e
formulários entrada de dados de usuário que são as páginas de visualização
JSP (Java Server Pages);
90
- Controller (Controle): é responsável por despachar requisições e controlar

os seus fluxos, é onde é implementado o Front Controller através do
framewok Struts na classe action e no arquivo struts.xml.
Com o emprego do modelo MVC foi possível centralizar a lógica de
despachar requisições em uma classe action, simplificando a implementação do
controle de segurança e acesso ao sistema.
Para facilitar o uso do Modelo MVC, foi utilizado o framework Struts,
cujo código aberto fornece componentes de controle, e Hibernate que é responsável
pelo mapeamento objeto relacional com o banco de dados. A figura 29 apresenta o
modelo dessa arquitetura:
S
A
IN
IM
N
Figura 29 – Modelo Arquitetura MVC.
4.3. PADRÕES DE PROJETO

U
Padrões de projeto são soluções que podem ser reutilizadas para

problemas recorrentes no desenvolvimento de aplicativos. Representam um
conjunto de descrições de problemas que são encontrados durante o processo do
desenvolvimento das aplicações com as suas respectivas soluções para esses
problemas. (ALUR, CRUPI & MALKS, 2004).
A utilização de padrões em softwares popularizou-se com o livro
Design Patterns: Elements of Reusable Object-Oriented Software cujos autores são
conhecidos como a Gangue dos Quatro (Gang of Four - GoF). Trata-se de um
91
catálogo com desenhos de padrões que podem ser agregados ao software

(MARTINS, 2006).
Os padrões de projeto são responsáveis por apresentar como será o
funcionamento entre os componentes do sistema, definindo-se através do padrão
quais são as responsabilidades e como se relacionam as entidades do projeto.
A definição de como será o funcionamento entre os componentes do
sistema, ao se considerar as responsabilidades e o relacionamento entre as
entidades do projeto é dada pelos padrões de projeto. No software em questão
foram empregados os seguintes padrões: Business Object, Data Access Object e
Front Controller implementado pelo framework Struts.
S
4.3.1. DAO
O DAO é utilizado para persistência de objetos Java fazendo com que
A
o código de acesso aos dados fique separado da lógica de negócios.
Esse padrão abstrai e encapsula o acesso ao armazenamento
IN
persistente gerenciando a conexão com o banco de dados para armazenar e
consultar dados.
Geralmente se tornam objetos leves porque são implementados como objetos sem
informações de estado e também não armazenam em cachê os resultados de
IM
nenhuma execução de consulta. Com o uso desse padrão os detalhes de

implementação do banco de dados ficam ocultos, por isso pode haver alteração de
banco de dados sem que implique em grandes mudanças na estrutura do sistema.
N
(ALUR, CRUPI & MALKS, 2004).
Na construção de software com utilização de mapeamento objeto

relacional e DAO, a linguagem do banco de dados torna-se transparente para o
U
desenvolvedor, pois operações do banco são assumidas pelo framework. Assim,

toda a manipulação de dados é feita através dos objetos instanciados, o que propicia
maior facilidade no caso de necessidade de troca do banco de dados. Esse padrão
será descrito com mais detalhes no capítulo 6.
4.3.2. Business Object
São objetos Java que contêm dados de negócios, ou seja, um objeto

Java se comunica com o DAO o padrão eleito para fazer a persistência com o banco
92
de dados. Esse padrão permite que a lógica de negócios fique separada da lógica
de persistência, usando-se um objeto. A figura 30 mostra o código da classe
PessoaBO.
package br.uniminas.bo;
import java.util.List;
import br.uniminas.entidades.Pessoa;
import br.uniminas.persistencia.PessoaDAO;
import br.uniminas.persistencia.PessoaHibernateDAO;
public class PessoaBO {
private PessoaDAO dao;
public PessoaBO() {
this.dao = new PessoaHibernateDAO();}
public List getAllPessoas() {
S
return dao.getAllPessoas();}
public void deletePessoa(String string) {
dao.delete(string);}
A
public Pessoa getPessoa(String string) {
return dao.getPessoa(string); }
public void insertPessoa(Pessoa pes) {
dao.insert(pes);}
IN
}
Figura 30 – Classe PessoaBO.
Na classe pessoaBO é criado um objeto do tipo PessoaDAO e a partir

IM
desse objeto são chamados métodos que fazem operações como inserir, pesquisar
e deletar que são métodos da classe DAO responsável pela persistência no banco
de dados.
Portanto o business object mantém os dados de negócio e implementa
N
comportamentos comuns a toda aplicação, descritos nos métodos da classe

PessoaBO.
U
4.3.3. Front Controller
É um padrão onde a lógica de controle fica centralizada em um ponto

único de entrada, o que permite o gerenciamento das atividades de tratamento das
solicitações.
Com a utilização do Front Controller é possível a reutilização do

código, ou seja, não há necessidade de repetição da lógica de controle a mesma
lógica pode ser usada para várias solicitações.
93
Portanto, em um sistema, o padrão Front Controller é o primeiro

contato, responsável por tratar as solicitações. A partir daí serão delegadas funções
para que seja executado o gerenciamento de ação e visualização.
4.3.4. Application Controller
O Application Controller é um padrão utilizado para centralizar a

recuperação e chamada dos componentes de solicitação que podem ser comandos
ou páginas de visualização.
Esse padrão é responsável pelo gerenciamento da ação e

visualização, onde o gerenciamento da ação está relacionado às rotas que para
S
atendimento de uma solicitação e o gerenciamento de visualização, cuja função é
localizar e distribuir a visualização solicitada.
A
Tanto o padrão Front Controller como o Application Controller são
implementados pelo framework Struts.
IN
4.4. TECNOLOGIAS UTILIZADAS
4.4.1. Servlet
IM
Servlet é uma classe Java que acessa uma API com serviços
específicos do protocolo http. Ele recebe uma requisição e apresenta uma resposta
em seguida. Toda vez que recebe uma requisição é iniciado um método chamado
service().
N
De acordo com Dumoulin, Franciscus e Winterfeldt (2004, p.9):

Um servlet se parece e se comporta como um servidor web miniatura. Ele
recebe uma solicitação e apresenta uma resposta. Mas, diferente dos
U
servidores web convencionais, a interface de programação da aplicação

(API) do servlet é designada especificamente para ajudar os
desenvolvedores Java a criarem aplicações dinâmicas.
No ciclo de vida do servlet na primeira invocação o método init() é

executado quando o servlet é carregado, existem os métodos de serviço que são
chamados pelo web server como service(), doGet(), doPost(), dentre outros. O
método destroy é chamado antes de encerrar a requisição ao servlet. A figura 31 a
seguir mostra o ciclo de vida de um servlet.
94
S
Figura 31 – Ciclo de vida do servlet.
Adaptado de Angoti (2009a).
4.4.2. Páginas JSP A

IN
Java Server Pages (JSP) é uma tecnologia para desenvolvimento de
aplicações que permite a captura de informações através de formulários. Pode ser
facilmente codificado, facilitando o desenvolvimento e também manutenção de uma
IM
aplicação. Quando uma página JSP é requisitada pelo usuário no browser, esta
página é executada pelo servidor, e, então, é gerada uma página HTML, através de
do processo de renderização, e em seguida, essa página é enviada ao browser do
usuário. As páginas JSP contêm código HTML comum e se diferenciam pelo uso
N
das tags que representam instruções Java.

U
Na figura 32 é apresentado o código da página

consultarPessoaForm.jsp.
<%@ page contentType="text/html; charset=UTF-8"%>

<%@ taglib prefix="s" uri="/struts-tags"%>
<html>
<head>
<link href="<s:url value="/css/main2.css"/>" rel="stylesheet"
type="text/css" />
</head>
<body background="/condominio/imagens/fundook.jpg">
<center><s:if test="pessoa==null || pessoa.P_cpf == null">
95
<br>
<br>
<br>
<br>
<div id="menu">
<ul>
<li><a href="principal.action">Principal</a></li>
<li><a href="getAllPessoas.action">Listar Cadastros</a></li>
</ul>
</div>
<br>
<br>
<br>
<br>
<br>
<h1><s:text name="Pesquisar Pessoa" /></h1>
S
</s:if>
<s:form action="consultarPessoa">
<table align="center" class="borderAll">
<tr>
</tr>
</table>
A
<td class="tdLabel"><s:text name="label.P_cpf" /></td>
<td><s:textfield name="cpf" size="11" /></td>
IN
<br />
<table>
<tr>
<td><s:submit action="consultarPessoa"
key="button.label.submit2" cssClass="butStnd" /></td>
IM
<td><s:reset key="button.label.cancel" cssClass="butStnd"

/></td>
<tr>
</table>
</s:form></center>
</body>
N
</html>
Figura 32 – Código da página consultarPessoaForm.jsp.
Assim, a execução da função consultar pessoa que foi apresentado

U
anteriormente, terá como resultado a exibição na tela do browser da página

pesquisarPessoa.jsp (Figura 33).
96
S
Figura 33 – Página pesquisarPessoa.jsp
4.4.3. JDBC
A
Java Database Conectivity (JDBC) é uma API da linguagem Java que
IN
permite o acesso ao sistema de gerenciamento de banco de dados (SGBD) através
de comandos SQL (Structured Query Language).
Essa API está contida no pacote java.sql, com a sua utilização não há
IM
necessidade do uso de um banco específico, ou seja, o sistema desenvolvido fica

independente acessando qualquer banco de dados (TOOD & SZOLKOWSK, 2003).
No sistema do Edifício Porto Seguro foi utilizado o JDBC juntamente
com a utilização do framewok Hibernate para fazer o mapeamento objeto relacional
N
com o banco de dados através do DAO (Data Access Object).
4.5. J2EE
U
J2EE (Java Enterprise Edition) é um padrão de desenvolvimento que

contém especificações sobre implementações de softwares desenvolvidos utilizando
a linguagem de programação Java. É voltado para o desenvolvimento de aplicativos
multicamadas baseando-se em componentes que são executados em um servidor
de aplicação (DIAS e BORBA, 2002).
No J2EE estão contidas API utilizadas na implementação do sistema
do Edifício Porto Seguro que são servlets, JSP (Java Server Pages) e JDBC (Java
Database Connectivity).
97
As aplicações que utilizam o padrão J2EE seguem o modelo

arquitetural em camadas, onde em cada camada está atribuída uma
responsabilidade diferente. Como se pode notar na figura 34 que mostra a divisão
em camadas.
Figura 34 – Modelo em camadas.

Adaptado de Alur, Crupi e Malks (2004)
S
Na camada de apresentação encontra-se a lógica de apresentação dos
A
elementos exibidos ao usuário. Essa camada intercepta as solicitações do usuário e
faz o controle do que será exibido como resposta às requisições. Estão nessa
camada as páginas JSP e os servlets, que embora não sejam a interface
IN
propriamente dita são responsáveis pela criação destas. Também, está presente
nessa camada o Front Controller, implementado pelo framework Struts, que é
responsável por controlar e redirecionar as requisições feitas pelo usuário e delegar
IM
as ações para cada requisição.

Já, na camada de negócios estão presentes os dados e a lógica de
negócios. Ela foi implementada com a utilização de Business Object que tem por
função separar os dados e a lógica de negócios através de um objeto Java.
N
Por fim, a camada de integração é responsável por fazer a

comunicação com o SGBD (Sistema de gerenciamento de banco de dados). Nessa
U
camada foi utilizado o DAO para abstrair o acesso ao banco de dados através do
mapeamento objeto relacional.
4.6. TOMCAT
O Tomcat 5.5 é um container servlet da Apache Software Foundation

que foi utilizado como servidor web no projeto do software do Edifício Porto Seguro.
Ele implementa as especificações servlet e JSP.
Com o uso do Tomcat foi possível obter algumas vantagens dentre elas
se destacam:
98
- Otimização de performance;
- Otimização e redução do coletor de lixo;
- Melhoria no tratamento de taglibs;
- Gerenciamento da aplicação e do servidor.
(ANGOTI JR, 2009c).
4.7. IMPLEMENTAÇÃO
4.7.1. Struts
É um framework mantido pela Apache Software Foundation além de

outros projetos já criados tais como o Tomcat. O código inicial do Struts foi
S
desenvolvido entre o ano de 2000 e 2001 onde mais de 30 desenvolvedores
contribuíram para a sua criação (DUMOULIN, FRANCISCUS, WINTERFELDT,
2004).
A
O Struts é responsável por implementar o Front Controller que faz a
IN
centralização da lógica de controle, promovendo também reutilização de código
porque não será necessário código de controle em várias páginas de visualização.
As responsabilidades ficam bem definidas facilitando a manutenção. Na figura 35 é
possível ver o funcionamento do Front Controler que atua na camada de
IM
apresentação.
N
U
Figura 35 – Front Controller

Adaptado de Angoti (2009b)
99
O controlador é o ponto central de todas as requisições feitas pelo

cliente e a partir dele que vai ser definida qual página view que vai ser exibida. O
Command Helper mostrado na figura acima representa comandos ou métodos que
serão executados de acordo com o nome da ação definida.
No Sistema para Gestão de Condomínio o Command Helper é
representado pelas classes action que possuem métodos que são executados de
acordo com a requisição do cliente.
Para o correto funcionamento do framework Struts é criado um arquivo
chamado struts.xml onde são feitos os mapeamento das ações. A figura 36
S
apresenta um trecho do código desse arquivo.
A
<!DOCTYPE struts PUBLIC "-//Apache Software
Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">
IN
<struts>
<package name="default" extends="struts-default">

...
<action name="consultarUnidade" method="consultaUnidade"
class="br.uniminas.action.PesquisarAction">
IM
<result name="success">/page/unidade.jsp</result>
<result name="erro">/page/erro.jsp</result>
</action>
...
</package>
</struts>
N
Figura 36 – Arquivo struts.xml.

U
Pode-se notar que o mapeamento é feito através do nome da ação, da

classe utilizada e do método. O resultado também é mapeado, no caso da ação
consultarUnidade mostrada na figura 8 caso o resultado seja success será exibida a
página unidade.jsp. Porém, se o resultados for erro a página a ser mostrada será
erro.jsp. O resultado dessa ação está definido no código do método consultaUnidade
da classe PesquisarAction (Figura 37).
100
...
public String consultaUnidade() {
unidade = uniService.getUnidade(numero);
if (unidade != null) {
return "success";
} else {
addActionError("Unidade não existe!");
return "erro";
}
}
...
Figura 37 – Método consultaUnidade.
Assim, o Front Controller implementado através do Struts faz o controle

das ações e resultados que serão exibidos através do direcionamento das ações de
S
acordo com a solicitação feita pelo usuário.
4.7.2. Diagrama de Pacotes
A
Os diagramas de pacotes do sistema foram gerados pelo Omondo
Eclipse UML que é um plugin que auxilia a geração de diagramas UML. Foi utilizado
IN
o processo de engenharia reversa para geração desses diagramas, onde a partir do
código fonte foi possível gera-los.
O diagrama de pacotes exibe a estrutura de classes e pacotes de como
IM
do sistema desenvolvido. A figura 38 mostra todos os pacotes que foram criados no

sistema.
N
U
Figura 38 – Diagrama de pacotes.

101
No pacote entidades estão as classes utilizadas para criar os objetos

que serão manipulados pela aplicação, as classes desse pacote são:
UsuárioEntidade, LoginCO, Pessoa, Unidade e Histórico(Figura 39).
S
A
Figura 39 – Classes do pacote entidades.
IN
No pacote bo estão as classes de negócio da aplicação, ou seja,
através de métodos que estão contidos nas classes do tipo BO são passados os
objetos de entidades para que sejam executadas as operações pelas classes DAO
(Figura 40).
IM
N
U
Figura 40 – Classes do pacote bo.
Já, no pacote persistência estão as interfaces PessoaDAO,

UnidadeDAO, HistoricoDAO, essas interfaces contêm os mesmo métodos que são
implementados nas classes PessoaHibernateDAO, UnidadeHibernateDAO e
Histórico HibernateDAO e também a classe LoginDAO que implementam as
102
operações que serão executadas no banco de dados através do framework

hibernate, já a classe HibernateUtil é criada pelo framework hibernate (Figura 41)
S
A
IN
Figura 41 – Classes do pacote persistência.
IM
E finalmente, no pacote action estão as classes Java que contêm

métodos que são mapeados no struts.xml para realizar determinadas ações. As
classes são: Cadastrar PessoaAction, PesquisarAction e Login2 (Figura 42).
N
U
Figura 42 – Classes do pacote action.

103
Percebe-se que os pacotes retratam a maneira de como estão

dispostas as classes da aplicação, o que deixa o código mais organizado e auxilia
no caso de novas implementações ou alterações no sistema.
4.7.3. Implementação do Caso de Uso Cadastrar Dados
Para apresentar o funcionamento do modelo em camadas e visualizar

a interação entre os padrões utilizados no sistema do Edifício Porto Seguro, será
usado como exemplo o Caso de Uso 02 Cadastrar Dados que utiliza as entidades
S
pessoa, unidade e histórico. Essa demonstração parte das premissas de que a
pessoa em questão não foi cadastrada anteriormente e que não há histórico com
A
pendências para a unidade. A figura 43 mostra a tela principal do sistema do Edifício
Porto Seguro onde é selecionada a opção Cadastrar Dados.
IN
IM
N
U
Figura 43 – Página Principal.

104
Ao ser selecionada a opção cadastrar dados, executa-se uma action

que foi mapeada no arquivo struts.xml com o nome de setUpForInsertOrUpdate, o
trecho de código do mapeamento dessa action é mostrado a seguir na figura 44.
<action name="setUpForInsertOrUpdate"
method="setUpForInsertOrUpdate"
class="br.uniminas.action.CadastrarPessoaAction">
<result name="success">/page/cadastroPessoaForm.jsp</result>
</action>
Figura 44 – Action setUpForInsertOrUpdate mapeada no arquivo struts.xml.
A ação nomeada como setUpForInsertOrUpdate no arquivo struts.xml

invoca o método setUpForInsertOrUpdate() que está na classe
S
CadastrarPessoaAction do pacote action, como apresentado no trecho de código
abaixo (Figura 45).
public class CadastrarPessoaAction {

...
A
public String setUpForInsertOrUpdate() {
prep();
IN
return "success";
}
...
Figura 45 – Método setUpForInsertOrUpdate() implementado na classe CadastrarPessoaAction.
IM
Nessa classe existe um método prep() que preenche um componente

do tipo combo box na página onde serão exibidos os números das unidades
existentes no condomínio e retorna success que foi mapeado no arquivo struts.xml
para exibir a página de cadastro de dados, como mostrado na figura 46.
N
U
Figura 46 – Tela de Cadastro de Dados.

105
Depois de preenchidos os dados e pressionada a tecla cadastrar é

executada uma action mapeada no arquivo struts.xml com o nome de
insertOrUpdate, a seguir é mostrado o trecho do arquivo struts.xml (Figura 47).
<action name="insertOrUpdate" method="insertOrUpdate"

<result name="success">/page/sucesso.jsp</result>
</action>
Figura 47 – Action InsertOrUpdate implementado no arquivo struts.xml.
O método insertOrUpdate() está na classe CadastrarPessoaAction que
S
é uma classe Java contendo os objetos e métodos relacionados ao cadastro de
dados, além dos métodos das validações feitas pelo sistema. A seguir é mostrado o

...
A
código do método insertOrUpdate(), como mostra a figura 48.
IN
public String insertOrUpdate() {
if (!validationSuccessful()) {
return "erro";
} else {
if (prop != null && prop.equals("aquisicao")) {
gravaPropAquisicao();
}
IM
if (prop != null && prop.equals("venda")) {

if (!validaDataVenProp()){
return "erro";}
else{
gravaProVenda();}
}
if (mor != null && mor.equals("entrada")) {
if (jaMorador()==true){
N
return "erro";
}
if(jaMorador()==false){
gravaMorEnt();
}
U
}
if (mor != null && mor.equals("saida")) {
if (!validaDataSaiMor())
return "erro";
else
gravaMorSai();
}
return "success";
}
}
...
Figura 48 – Método InsertOrUpdate implementado na classe CadastrarPessoaAction.
106
Primeiramente é feita a verificação dos dados inseridos no formulário

através do método validationSuccessfull() que está na classe
CadastrarPessoaAction, que valida os campos preenchidos no formulário. Se não
houver a validação, uma página de erro é retornada. Caso a validação seja positiva,
será verificada, então, as opções selecionadas através de componente do tipo radio
button, que se encontra na página de cadastro de dados. As opções disponíveis são
proprietário definindo em seguida se aquisição ou venda e, ainda, morador
acompanhado de entrada ou saída de um apartamento.
Será apresentado o processo de cadastro de uma aquisição de um

apartamento, a condição que considera a opção aquisição selecionada. Nesse caso
S
é chamado o método gravaPropAquisicao(). Nesse método, estão envolvidas as
entidades pessoa; unidade e histórico e as variáveis pesAux e pessoa, que são do
tipo Pessoa e pesService é do tipo PessoaBO. A linha de código mostrada abaixo
A
permite verificar se já existe uma pessoa cadastrada com o CPF informado. Caso
exista, grava o objeto pessoa correspondente no objeto pesAux, senão grava valor
IN
nulo nesse objeto (Figura 49).

IM
...
public void gravaPropAquisicao() {
pesAux = pesService.getPessoa(pessoa.getP_cpf());
unidade = uniService.getUnidade(unidade.getU_numero());
histAux = histService.getHistorico(historico.getId());
...
Figura 49 – Método gravaPropAquisicao() implementado na classe CadastrarPessoaAction.
N
U
Esse mesmo procedimento é feito também com os objetos unidade e

histAux que correspondem à objetos do tipo unidade e histórico respectivamente.
Em seguida, é verificado se a unidade já tem proprietário cadastrado, isso é feito
através do método getProprietário() que está na classe Unidade. Se houver
proprietário cadastrado, é retornada uma mensagem como pode ser visto no trecho
de código apresentado na figura 50.
107
public class CadastrarPessoaAction{

...
public void gravaPropAquisicao{
...
if ((pesAux != null || pesAux == null) && unidade.getProprietario() !=
null) {
addActionMessage("A unidade "+unidade.getU_numero()+"já tem
proprietário\n CADASTRO NÃO EFETUADO!");
...
Figura 50 – Mensagem de erro gerada pelo método gravaPropAquisicao() implementado na

classe CadastrarPessoaAction.
Se a pessoa não tiver sido cadastrada anteriormente e a unidade não

possuir proprietário, o registro de pessoa é gravado da seguinte forma, um objeto do
S
tipo PessoaBO chamado pesService já instanciado, passa através do método
insertPessoa(), que pertence a classe PessoaBO, o objeto pessoa criado, quando
submeteu-se os dados do formulário (Figura 51).
A
IN
...
...
if (pesAux == null && unidade.getProprietario() == null) {
// grava pessoa
IM
pesService.insertPessoa(pessoa);
...
implementado na classe CadastrarPessoaAction.
N
Na classe PessoaBO é criada uma variável do tipo PessoaDAO e no

construtor dessa classe o objeto do tipo pessoaDAO é instanciado como mostrado a
seguir (Figura 52).
U

private PessoaDAO dao;
public PessoaBO() {
this.dao = new PessoaHibernateDAO();
}
...
Figura 52 – Comando geração do objeto pessoaDAO declarado no construtor da classe
PessoaBO.
108
Na classe PessoaBO o método insertPessoa() recebe um objeto do

tipo pessoa e passa esse objeto para a classe PessoaHibernateDAO, que contém o
método insert(), como mostra a figura 53.

...
public void insertPessoa(Pessoa pes) {
dao.insert(pes);
}
...
Figura 53 – Chamada do método insert() através do método insertPessoa() implementado
na classe PessoaBO.
S
Esse método recebe o objeto pessoa criado e executa a gravação dos
dados na tabela de pessoas do banco de dados (Figura 54).
public class PessoaHibernatedDAO {

A
IN
...
public void insert(Pessoa pes) {
session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try {
IM
tx = session.beginTransaction();
session.save(pes);
tx.commit();
} catch (RuntimeException e) {
if (tx != null)
tx.rollback();
N
throw e;
} finally {
// session.close();
}
U
}
...
Figura 54 – Código do método insert() implementado pela classe PessoaHibernateDAO.
Depois de gravar a pessoa no método gravaPropAquisicao() a unidade

é atualizada, primeiro é atualizado o campo proprietário da unidade através do
método setProprietário(), que pertence a classe Unidade, e então um objeto do tipo
UnidadeBO chamado uniService passa através do método updateUnidade(), que
109
pertence a classe UnidadeBO, o objeto unidade que foi atualizado. O trecho de

código que faz esta operação é mostrado a seguir (Figura 55).

...
...
// atualiza unidade
unidade.setProprietario(pessoa);
uniService.updateUnidade(unidade);
...
Figura 55 – Comandos do método gravaPropAquisicao() implementado pela classe
CadastrarPessoaAction.
S
Na classe UnidadeBO é criado um objeto do tipo UnidadeDAO e no
construtor dessa classe o objeto do tipo unidadeDAO é instanciado como mostrado
na figura 56 a seguir.
A
IN
public class UnidadeBO {
private UnidadeDAO dao;
public UnidadeBO() {
this.dao = new UnidadeHibernateDAO();
IM
}
...
Figura 56 – Comandos de criação do objeto UnidadeHibernateDAO declarado no construtor
da classe UnidadeBO.
N
O método updateUnidade() da classe UnidadeBO, recebe um objeto do

tipo unidade e passa esse objeto para a classe UnidadeHibernateDAO que contém
um método chamado updateUnidade() apresentado na figura 57.
U
public class UnidadeBO{

...
public void updateUnidade(Unidade u){
dao.updateUnidade(u);
}
...
Figura 57 – Comandos do método updateUnidade() implementado pela classe UnidadeBO.
110
O método updateUnidade() da classe, recebe o objeto do tipo unidade

e executa a atualização dos dados na tabela de unidades do banco de dados (Figura
58).
public class UnidadeHibernatedDAO {

...
public void updateUnidade(Unidade u) {
try {
session.update(u);
tx.commit();
S
if (tx != null)
tx.rollback();
throw e;
}
}
} finally {
A
IN
...
Figura 58 – Código do método updateUnidade() implementado pela classe
UnidadeHibernateDAO.
Por fim, é feita a gravação do histórico, através método

IM
gravaPropAquisicao(). É verificado se há um histórico com o mesmo código que foi

informado no formulário de cadastro. Se já existir, o objeto histórico será atualizado
pelos métodos setters da classe histórico e é repassado ao BO através de uma
objeto do tipo HistoricoBO chamada histService através do método
N
updateHistorico()., como ilustrado pela figura 59.

U

...
...
// se já existir um histórico com o código digitado, atualiza
if (histAux != null) {
historico.setH_proVenda(histAux.getH_proVenda());
historico.setH_proAquiscao(data);
historico.setH_morEntrada(histAux.getH_morEntrada());
historico.setH_morSaida(histAux.getH_morSaida());
historico.setNumero(unidade);
historico.setMorador(histAux.getMorador());
111
historico.setProprietario(unidade.getProprietario());
histService.updateHistorico(historico);
}
...
implementado na classe CadastrarPessoaAction, quando já há histórico da unidade.
Na classe HistoricoBO é criada uma variável do tipo HistoricoDAO e no

construtor dessa classe um objeto do tipo historicoDAO é instanciado como
mostrada na figura 60 a seguir.
S
public class HistoricoBO {
private HistoricoDAO dao;
public HistoricoBO() {
A
this.dao = new HistoricoHibernateDAO();
}
...
Figura 60 – Comandos de criação do objeto HistoricoHibernateDAO declarado no construtor
IN
da classe HistoricoBO.
O método updateHistorico() recebe um objeto do tipo historico e passa

esse objeto para o DAO que contém um método chamado updateHistorico (Figura
IM
61).
public class HistoricoBO{

N
...
public void updateHistorico(Historico hist){
dao.updateHistorico(hist);
}
U
...
Figura 61 – Comandos do método updateHistorico() implementado pela classe HistoricoBO.
O método updateHistorico() da classe HistoricoHibernateDAO recebe

o objeto do tipo histórico e executa a atualização dos dados na tabela de históricos
do banco de dados (Figura 62).
112
public class HistoricoHibernatedDAO {

...
public void updateHistorico(Historico hist) {
try {
session.update(hist);
tx.commit();
if (tx != null)
tx.rollback();
throw e;
} finally {
S
}
}
...
Figura 62 – Código do método updateHistorico() implementado pela classe
HistoricoHibernateDAO.
A
IN
Senão houver histórico criado anteriormente com o código informado
na tela de cadastro de dados um novo objeto do tipo histórico é criado e é repassado
ao BO através de uma variável do tipo HistoricoBO chamada histService pelo
IM
método insertHistorico(), como mostra a figura 63.

N

...
U
...
// se não existir um histórico com o código digitado cria um novo
// registro de histórico no banco
else {
historico.setProprietario(pessoa);
historico.setNumero(unidade);
historico.setH_proAquiscao(data);
histService.insertHistorico(historico);
}
...
implementado na classe CadastrarPessoaAction, quando não há histórico da unidade.
113
O método insertHistorico(), que está na classe Histórico BO, recebe um

objeto do tipo historico e passa esse objeto para o DAO que contém um método
chamado insertHistorico(), como apresentado na figura 64.
public class HistoricoBO{

...
public void insertHistorico(Historico hist) {
dao.insert(hist);
}
...
Figura 64 – Comando declarado no método insertHistorico() implementado na classe
HistoricoBO.
O método insertHistorico() da classe HistoricoHibernateDAO recebe o
S
objeto do tipo Histórico e executa a inserção dos dados na tabela de históricos do
banco com o mapeamento objeto relacional realizado através do framework
Hibernate (Figura 65).
A
IN
public class HistoricoHibernatedDAO {
...
public void insert(Historico his) {
IM
try {
session.save(his);
tx.commit();
if (tx != null)
N
tx.rollback();
throw e;
} finally {
// session.close();
U
}
}
...
Figura 65 – Código do método insert() implementado na classe HistoricoHibernateDAO.
A seguir está apresentado o código para a geração de uma mensagem

que será exibida ao usuário com confirmação de dados gravados. Essa mensagem
é criada através do método addActionMessage(), como apresentado na figura 66.
114

...
...
addActionMessage(pessoa.getP_nome() + " Proprietário da unidade " +
unidade.getU_numero());
...
Figura 66 – Mensagem de sucesso gerada pelo método gravaPropAquisicao()
implementado na classe CadastrarPessoaAction.
Ao término da execução do método gravaPropAquisicao(), o método

insertOrUpdate() retorna uma String que no caso é success, como se pode ver na
figura 67 a seguir.
S
...
public String insertOrUpdate() {
...
}
A
if (prop != null && prop.equals("aquisicao")) {
gravaPropAquisicao();
IN
...
return "success";
}
}
...
Figura 67 – Código do método isertOrUpdate() implementado na classe
IM
CadastrarPessoaAction.
O retorno da String success está mapeado no arquivo struts.xml para

exibir uma página JSP, como mostra a figura 68.
N
...
U

...
...
</action>
...
Figura 68 – Action insertOrUpdate mapeada no arquivo struts.xml.
115
O caso de uso termina com a apresentação da página sucesso.jsp

(Figura 69), que contém a mensagem adicionada pelo método gravaPropAquisição()
através do método addActionMessage().
S
A
Figura 69 – Tela de confirmação de cadastro.
IN
É importante ressaltar que se a pessoa em questão já estiver
cadastrada no sistema, a parte do cadastro de dados da pessoa não será realizada
pelo software. Serão executados, apenas, os comandos de atualização da unidade e
IM
inserção ou atualização do histórico daquela unidade.

N
U
116
5. INTERFACE
Embora seja parte do software, a interface, para o usuário, confunde-se

com o sistema, muito embora seja apenas a parte do sistema que traduz as ações
do usuário em ativações das funcionalidades do sistema. É um componente
fundamental para o usuário que por vezes opta por um sistema considerando mais a
atratividade de sua interface do que as funcionalidades e desempenho propriamente
ditos. Assim, a qualidade da interface tem grande influência no sucesso comercial de
um software.
A interface deve ser invisível e intuitiva, pois o usuário deve concentrar-
S
se no trabalho que deverá executar. Para isso, uma interface deve ser amigável e
apresentar usabilidade. Para atingir esses objetivos, ela deverá apresentar as
A
seguintes características: ser de fácil uso; ser fácil de aprender o seu manuseio;
apresentar taxa mínima de erro; favorecer a recordação rápida; ser atrativa;
apresentar alta velocidade na execução de tarefas; gerar satisfação e retenção do
IN
usuário com o tempo (ASCENIO, 1999).
De acordo com Ferreira (2009), a interface estabelece uma interação
do homem com o sistema através de um meio visual. O indivíduo recebe e interpreta
IM
a informação visual com base no tamanho, forma, cor e outras características. Uma
especificação adequada da comunicação visual é o elemento chave para obtenção
de uma interface amigável. A cor é um componente que merece um estudo especial
quando se trata de comunicação, assim, a escolha das cores de uma interface deve
N
ser feita com cautela.

É natural a associação de cores a diversas situações ou elementos,
tanto que se faz uso de cores para indicar condições diversas: perigo, atenção,
U
qualidade de alimentos, acidez e alcalinidade e outras.

O significado das cores tem forte cunho cultural, como no ocidente, a
cor branca está associada à pureza, muito usada por noivas no dia de seu
casamento. Enquanto que, no oriente, é a cor da morte e dor. Para os orientais, o
vermelho é a cor convencional para o vestido de noiva. A idade, também, é fator
decisivo para a escolha das cores, as crianças mais novas são normalmente
atraídas por cores vibrantes. Desta forma, o design de interfaces deve se beneficiar
dessas informações, selecionando as cores atrativas ao perfil do usuário do sistema.
117
As cores têm indicações relacionadas ao significado cultural e também

às percepções visuais que determinam. Assim a escolha de cores para compor uma
interface gráfica deve considerar alguns fatores, como os descritos a seguir.
Branco
É a cor que possui a maior leveza ao atrair a atenção para um fundo
escuro, de modo que fornece a máxima legibilidade para um texto escuro, embora o
brilho possa causar problemas ao se olhar para ela por um período prolongado. Não
é recomendada para os cantos de interface e como estreita moldura de imagens,
valoriza a figura.
Preto
Atua como estimulante para as demais cores e se harmoniza bem com
S
todas elas. As superfícies pretas se tornam mais negras à medida que o nível de
iluminação aumenta. Contrastes simultâneos fazem com que um contorno preto
A
torne áreas coloridas mais claras e amplas. Torna-se mais legível quando em
contraste com fundos claros, apesar de ser necessário o uso de fontes em “negrito”
IN
quando se usa texto negro em um fundo branco. Linhas pretas são eficientes ao se
separar áreas coloridas através de um aumento da fronteira de contraste. Para uma
boa reprodução de imagens, é desejável ter-se um preto sólido de modo a
estabelecer o limite da variação tonal.
IM
Cinza
Reduz as conotações emocionais. Combina com todas as cores, que
apresentam seu colorido máximo quando contrastando com cinza escuro.
Das cores acromáticas (branco, preto e cinza) o cinza é uma boa cor
N
de fundo para a maioria das interfaces, pois minimiza o contraste entre a cor mais
escura e a mais clara da cena, amortecendo o choque visual ao se passar de uma
U
para outra. Embora seja adequada, não é frequentemente empregada em softwares

de sucesso.
As cores podem ser classificadas em cores quentes (amarelo, laranja e
vermelho) e cores frias (azul, turquesa e violeta). O verde e o magenta são
considerados cores marginais, pois seu caráter está na dependência das cores
adjacentes, se esta for uma cor fria, então aqueles aparentaram quentes. Da mesma
forma, se as cores do em torno forem quentes o verde e o magenta assumirão o
caráter de cores frias.
118
Para a criação de um ambiente harmonioso é necessário haver o

equilíbrio contrastando cores quentes com cores frias, de modo a torná-lo mais
agradável.
Vermelho
Apresenta o maior significado emocional a despeito da cultura,
provavelmente devido à sua associação com o sangue e o fogo, portanto com a
guerra.
É muito eficiente quando usada nas interfaces para sinalizar algum
perigo ou chamar a atenção, como por exemplo, bordas vermelhas de sinais de
advertência são rapidamente percebidas.
Amarelo
S
Apresenta grande qualidade acolhedora. Sua associação imediata com
o sol faz com que ela simbolize a vida e o calor. É um bom indicador de atividade,
A
sendo adequada para indicar a janela. Como cor de texto requer fundo preto ou azul
escuro.
IN
Verde
A idéia de que a plantação significa uma certa estabilidade levou à
associação do verde com o sentimento de segurança.
Ambientes com um tom de verde claro promovam um estado de paz na
IM
mente, enquanto que o verde em excesso resulta em uma aparência doentia. Está
indicada quando se deseja passar rapidamente uma informação, sendo também,
recomendada para informar que está tudo normal.
Azul
N
Sugere espaço e profundidade. É uma cor fria e suave, sendo a mais

tranquila de todas. Fornece um bom fundo para cores vívidas. Simboliza autoridade
U
e espiritualidade, sendo a cor mais amplamente usada nas bandeiras nacionais,

mostrando assim, o desejo de unidade e estabilidade.
É uma das três primárias dos terminais de vídeo. É difícil de ser
focalizada e de se obter um bom contraste. Assim, não deve nunca ser usado para
texto nem detalhes finos. Entretanto, é uma excelente cor para o fundo, dada
sensação gerada por ela, de expansão e profundidade.
Em relação aos significados subjetivos das cores, o quadro 17 ilustra
muito bem a associação das cores com elementos positivos e negativos.
119
Cor Positivas Negativas

Neve Paz Frio Palidez fúnebre
Branco Pureza Leveza Hospital Rendição
Inocência Limpeza Vulnerabilidade Esterilidade
Noite Estabilidade Medo Segredos
Preto Carvão Formalidade Vazio Anonimato
Poder Solidez Morte maldição
Vitória Força Sangue Perigo
Vermelho Paixão Energia Guerra Raiva
Amor Sexualidade Fogo Satã
Sol Ouro Covardia Risco
S
Amarelo Verão Colheita Traição Doença
Serenidade Inovação Ciúmes Loucura
Vegetação Fertilidade Decadência Ganância
Verde Natureza
Primavera
Céu A
Esperança
Segurança
Estabilidade
Inexperiência
Inveja
Frio
Fuga à realidade
Má Sorte
Obscenidade
IN
Azul Mar Paz Depressão Mistério
Espiritualidade Unidade Melancolia Conservadorismo
Quadro 17 – Simbologia de cores.
IM
5.1. DIAGRAMA DE NAVEGABILIDADE
O diagrama de estados de navegação indica quais são as janelas que

compõe o sistema e quais eventos permitem ao usuário navegar de uma para outra.
Permite observar a dinâmica da aplicação, uma vez que ilustra os caminhos
N
possíveis na interação do usuário com o sistema

A seguir, a figura 70 apresenta o diagrama de navegabilidade do
U
sistema.
120
U
N
IM
IN
A
S
Figura 70 – Diagrama de Navegabilidade.
121
A interface com o usuário foi definida através de Java Server Pages,

também conhecida por sua sigla JSP.
As páginas JSP que consistem em páginas HTML com elementos
especiais, que lhes conferem caráter dinâmico. Esses elementos podem tanto
realizar um processamento por si, como podem recuperar o resultado do
processamento realizado em um Servlet e apresentar esse conteúdo dinâmico junto
a página JSP.
Existe também um recurso adicional bastante interessante na utilização
de páginas JSP: a recompilação automática, que permite que alterações feitas no
código da página sejam automaticamente visíveis em sua apresentação.
S
Às páginas JSP associou-se a tecnologia Cascade Style Sheets – CSS
- linguagem de estilo, que provém a apresentação de documentos escritos em uma
A
linguagem de marcação, como o HyperText Markup Language – HTML. O principal
benefício é permitir a separação entre o formato e o conteúdo de um documento,
pois formatação não está incorporada ao documento. Os estilos ficam em uma
IN
página separada ligada às páginas de código, de modo que para alterar a
apresentação das páginas de interface, basta proceder as mudanças na página
onde os estilos estão definidos, que as alterações serão percebidas de forma
IM
idêntica nas demais páginas.

A seguir será simulado os comportamento do sistema, com a
nevegação entre as telas de interface
N
U
122
S
Figura 71 – Tela de Login.
A
IN
IM
N
U
Figura 72 – Tela de mensagem de erro no Login.

123
S
Figura 73 – Menu inicial.
A
IN
IM
N
U
Figura 74 – Tela de Cadastro de Dados.

124
S
A
Figura 75 – Tela com mensagem de erro de CPF.
IN
IM
N
U
Figura 76 – Tela com mensagem de erro, CPF cadastrado como morador

em outra unidade.
125
S
A
Figura 77 – Tela com mensagem de sucesso ao cadastrar os dados.
IN
IM
N
U
Figura 78 – Tela que apresenta a lista das pessoas cadastradas.

126
S
A
Figura 79 – Tela para solicitar a pesquisa dos dados de uma pessoa.
IN
IM
N
U
Figura 80 – Tela que apresenta os dados da pessoa pesquisada.

127
S
A
Figura 81 – Tela para solicitar a pesquisa dos dados de uma unidade.
IN
IM
N
U
Figura 82 – Tela que apresenta os dados da unidade pesquisada.

128
6. PERSISTÊNCIA DE DADOS
A maioria dos aplicativos requer dados persistentes. A persistência é

um dos conceitos fundamentais em desenvolvimento de aplicativos. Se um sistema
de informação não preservasse os dados inseridos pelos usuários quando a
máquina anfitriã fosse desligada, o sistema seria de pequeno uso prático. Quando
falamos sobre persistência em Java, normalmente estamos falando sobre
S
armazenar dados em um bando de dados relacional, usando SQL (Structure Query
Language) (BAUER & KING, 2005).
A persistência de dados, na computação, refere-se ao armazenamento
A
não-volátil de dados, por exemplo em um dispositivo físico de armazenamento como
um disco rígido. De forma muito simples, Persistência de Dados nada mais é do que
IN
armazenar dados em um banco de dados relacional.
Pode-se dizer que de maneira geral, o termo persistência é associado
a uma ação que consiste em manter em meio físico recuperável, como banco de
dados, arquivo, de modo a garantir a permanência das informações de um
IM
determinado estado de um objeto lógico.

Na Orientação a Objetos, chama-se de "objetos persistentes" aqueles
que permanecem existindo mesmo após o término da execução do programa.
Dentras as alternativas existentes, foi-se trabalhado a persistência sob o controle de
N
um banco de dados, pois as aplicações requerem um serviço de banco de dados,

pois assim os dados desses objetos podem ser eternizados e recuperados.
U
Assim persistência de dados consiste no armazenamento confiável e

coerente das informações em um sistema de armazenamento de dados, a
persistência de objetos é o armazenamento consistente de objetos de uma aplicação
orientada a objeto para que estes objetos existam em diferentes execuções de
diferentes aplicações.
129
6.1. CONCEITOS DE BANCO DE DADOS
Os bancos de dados e os sistemas de bancos de dados são

componentes essenciais para a sociedade moderna, na medida em que os sistemas
de informação estão cada vez mais difundidos.
Essa tecnologia tem provocado impacto no crescimento do uso de
computadores, representando, um papel crítico nas áreas em que os computadores
são utilizados, incluindo negócios, comércio eletrônico, engenharia, medicina, direito,
educação e as ciências da informação, para criar apenas algumas delas. A palavra
banco de dados é tão comumente utilizada que, primeiro, devemos defini-la
(ELMASRI & NAVATHE, 2005).
S
De acordo com Elmasri e Navathe (2005, p. 4) “um banco de dados é
uma coleção de dados relacionais. Os dados sãos fatos que podem ser gravados e
que possuem um significado implícito”.
A
Um sistema de banco de dados é um sistema computadorizado de
manutenção de registros, dados. Desse maneira o banco de dados, por si só, pode
IN
ser considerado como o equivalente eletrônico de um armário de arquivamento onde
os usuários do sistema podem realizar diversas operações (DATE, 2004):
• Busca de dados;
Inserção de dados;
IM
•
• Exclusão de dados;
• Alteração de dados;
• Remoção de dados;
N
Segundo Date (2005, p. 10) “um banco de dados é uma coleção de

dados persistentes, usado pelos sistemas de aplicações de uma determinada
U
empresa”.
Os dados armazenados em um banco de dados representam algum
aspecto específico do mundo real — um universo de discurso de onde os dados são
obtidos — e apresentam algum grau de coerência lógica entre seus componentes.
Portanto, uma coleção aleatória de dados não constitui um banco de dados.
Um sistema de banco de dados é constituído por um banco de dados e
por um sistema gerencia-dor de banco de dados, como mostrado na figura 83. Um
sistema de banco de dados é usualmente uma aplicação que serve de suporte a
130
outras aplicações, tais como folha de pagamento, controle de pessoal e informações

bancárias.
Os bancos de dados relacionais modernos fornecem uma
representação estruturada de dados persistentes, permitindo a classificação, busca
e agregação de dados. Os sistemas de gerenciamento de banco de dados (SGBD)
são responsáveis por gerenciar a concorrência e a integridade dos dados. São,
ainda, responsáveis por compartilhar dados entre os múltiplos usuários e os
múltiplos aplicativos. Um sistema de gerenciamento de banco de dados deve,
inclusive, fornecer segurança de alto nível de dados (BAUER & KING, 2005).
Dentre as vantagens da abordagem de banco de dados destacamos
(DATE, 2004):
S
• Armazenamento, organização e obtenção de dados estruturados.
• Compartilhamento dos dados.
• Redução de redundância.
A
• Inconsistência pode ser evitada.
IN
• Fornecimento de suporte a transação.
• Manutenção da Integridade.
• Reforço da segurança.
• Requisitos contraditórios podem ser equilibrados.
IM
• Imposição de padrões.
A figura 83 apresenta esquematicamente, a relação entre usuários,

N
aplicativo, SGBD e o banco de dados.

U
131
S
A
Figura 83 – Sistema simplificado de Banco de Dados.
Adaptado de RICARTE. I. L. M (1998, p.2).
IN
O banco do Sistema Gestão de Condomínio foi usado para oferecer um
armazenamento persistente aos objetos programas e estruturas de dados. Essa é
umas das principais justificativas para o sistema de banco de dados orientados a
IM
objeto. As linguagens de programação têm uma estrutura de dados complexa, como

as definições de classes em Java.
6.2. MYSQL
N
O MySQL é um SGBD (Sistema de Gerenciamento de Banco de

Dados), que utiliza a linguagem SQL (Structured Query Language) como interface.
U
Um sistema gerenciador de banco de dados é o software que permite

criar, manter e manipular bancos de dados para diversas aplicações. A criação e
manutenção de bancos de dados são tarefas de uma pessoa ou grupo de pessoas,
normalmente referenciada como o administrador do banco de dados. A manipulação
do banco de dados, como atualizações e consultas, é realizada direta ou
indiretamente, através de programas aplicativos, pelos usuários do banco de dados.
O sistema gerenciador de banco de dados pode ser de propósito geral ou específico
para alguma aplicação.
132
Para o desenvolvimento do sistema em questão, escolheu-se o MySQL

devido a sua alta performance observada em aplicativos de missão critica, a fácil
operação e manutenção, a sua estabilidade e o baixo custo de aquisição .
Dentre as suas principais características destacamos:
Funciona em diversas plataformas.

API (Application Programming Interface) para C, C++, Eiffel, Java,
Perl, PHP, Python, Ruby e Tcl estão disponíveis.
Suporte total a multi-threads usando threads diretamente no kernel.
Isto significa que se pode facilmente usar múltiplas CPU (Central
Processing Unit), se disponível.
S
Fornece mecanismos de armazenamento transacional e não
transacional.

É relativamente
armazenamento.
A
fácil se adicionar outro
Um sistema de alocação de memória muito rápido e baseado em

mecanismo de
IN
processo(thread).
Joins muito rápidas usando uma multi-join de leitura única otimizada.
Tabelas hash em memória que são usadas como tabelas temporárias.
IM
Funções SQL são implementadas por meio de uma biblioteca de

classes altamente otimizada e com o máximo de performance.
Geralmente não há nenhuma alocação de memória depois da
inicialização da pesquisa.
N
Disponível como versão cliente/servidor ou embutida (ligada).

• Tipos de Coluna
Aceita diversos tipos de campos: tipos inteiros de 1, 2, 3, 4 e 8 bytes
U
com e sem sinal, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB,

DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET e ENUM.
Registros de tamanhos fixos ou variáveis.
• Comandos e Funções
Completo suporte a operadores e funções nas partes SELECT e
WHERE das consultas.
133
Suporte pleno às cláusulas SQL GROUP BY e ORDER BY. Suporte

para funções de agrupamento (COUNT(), COUNT(DISTINCT ...),
AVG(), STD(), SUM(), MAX() e MIN()).
Suporte para LEFT OUTER JOIN e RIGHT OUTER JOIN com as
sintaxes SQL e ODBC.
Alias em tabelas e colunas são disponíveis como definidos no padrão
SQL92.
DELETE, INSERT, REPLACE, e UPDATE retornam o número de
linhas que foram alteradas. É possível retornar o número de linhas
com padrão coincidentes configurando um parâmetro quando estiver
conectando ao servidor.
S
Você pode misturar tabelas de bancos de dados diferentes na mesma
pesquisa.
• Segurança

A
Um sistema de privilégios e senhas que é muito flexível, seguro e que
IN
permite verificação baseada em estações/máquinas. Senhas são
seguras porque todo o tráfico de senhas é criptografado quando você
se conecta ao servidor.
• Escalabilidade
IM
• Conectividade
Os clientes podem se conectar ao servidor MySQL usando sockets
TCP/IP (Transmission Control Protocol/Internet Protocol), em qualquer
plataforma. No sistema Windows na família NT (NT, 2000 ou XP), os
N
clientes podem se conectar usando named pipes. No sistema Unix, os

clientes podem se conectar usando arquivos sockets.
U
A interface Connector/ODBC (Open-DataBase-Connectivity) fornece

ao MySQL suporte a progras clientes que usam conexão ODBC. Os
clientes podem ser executados no Windows ou Unix. O fonte do
Connector/ODBC está disponível. Todas as funções ODBC são
suportadas, assim como muitas outras (MySQL).
134
6.3. MODELAGEM DE BANCO DE DADOS
Modelagem de dados é a atividade de especificação das estruturas de

dados e regras de negócio necessárias para suportar uma área de negócios.
Representa um conjunto de requerimentos de informações de negócio. É uma parte
importante do desenho de um sistema de informação (Wikipédia, 2009b).
A abordagem que se dispensa ao assunto normalmente atende a três
perspectivas: Modelagem Conceitual, Modelagem Lógica e Modelagem Física. A
primeira é usada como representação de alto nível e considera exclusivamente o
ponto de vista do usuário criador do dado, a segunda já agrega alguns detalhes de
implementação e a terceira demonstra como os dados são fisicamente armazenados
S
(Wikipédia, 2009b).
6.3.1. Modelos
A
Um modelo de dados é uma definição abstrata, autônoma e lógica dos
objetos, operadores e outros elementos.
IN
De acordo com a abordagem que utilizada e conforme ilustrado pela
figura 84, os modelos de dados normalmente são classificados da seguinte forma:
IM
N
U
Figura 84 – Arquitetura de Modelo de Banco de Dados.

Adaptado de RICARTE. I. L. M (1998; p.10).
135
• Modelo Conceitual:
o Representação dos conceitos e características observados no
ambiente;
o Ignorar particularidades de implementação.
A modelagem conceitual é uma fase muito importante no
planejamento de uma aplicação de um banco de dados bem-sucedida.
Geralmente, o termo aplicação de um banco de dados refere-se a um banco de
dados particular e aos programas a eles associados, que implementam consultas
e atualizações (ELMASRI & NAVATHE, 2005, p.35).
S
• Modelo Lógico:
o Regras de Derivação:

A
Normalização das estruturas de dados
Derivação de estruturas de agregação e generalização-
IN
especialização
Derivação de relacionamentos
o Regras de Restrição:
Restrição de domínio
IM
Restrição de Integridade
Restrição de Implementação
Figura 86 apresentada o modelo lógico implementado para Sistema de
Gestão de Condomínio.
N
U
136
S
A
IN
IM
Figura 85 – Modelo Lógico de Banco de Dados.

N
Modelo Físico:
U
•
o Inclui a análise das características e recursos necessários para
armazenamento e manipulação das estruturas de dados (estrutura de
armazenamento, endereçamento, acesso e alocação física).
Figura 85 apresenta o modelo físico implementado para o Sistema de
Gestão de Condomínio.
137
S
A
IN
Figura 86 – Modelo Físico de Banco de Dados.
IM
O modelo para o sistema foi implementado atendendo as regras

abaixo:
• Normalização, evitando assim os problemas que podem provocar falhas no
N
projeto do banco de dados, bem como eliminar a mistura de assuntos e as

correspondentes redundâncias dos dados desnecessárias.
• Representação fiel do negócio
U
• Descrição sucinta das entidades, atributos e relacionamentos;

• Contendo os nomes de entidades e atributos, extensos e abreviados,
atribuídos de acordo com algum padrão adotado no projeto e formados por
termos previamente convencionados;
• Contemplando, para cada um dos atributos, o tipo de dado, tamanho e
opcionalidade.
138
O modelo de dados usado no projeto foi o conceitual de alto nível, o

Modelo Entidade–Relacionamento que é um tipo de modelo lógico baseado em
objetos.
Para entendimento do modelo apresentado para o sistema, segue
abaixo a definição de alguns conceitos:
• Entidade: é qualquer coisa, concreta ou abstrata, incluindo associações entre

entidades, abstraídos do mundo real e modelados em forma de tabela que
guardarão informações no banco de dados.
• Relacionamento: nada mais é do que uma associação entre estas entidades.
Segue abaixo tipos de relacionamento:
S
− Relação 1..1 - indica que as tabelas têm relação unívoca entre si. Você
escolhe qual tabela vai receber a chave estrangeira;
A
− Relação 1..n - a chave primária da tabela que tem o lado 1 vai para a
tabela do lado N. No lado N ela é chamada de chave estrangeira;
IN
− Relação n..n - quando tabelas têm entre si relação n..n, é necessário criar
uma nova tabela com as chaves primárias das tabelas envolvidas, ficando
assim uma chave composta, ou seja, formada por diversos campos-chave
de outras tabelas. A relação então se reduz para uma relação 1..n, sendo
IM
que o lado n ficará com a nova tabela criada.
• Atributo: corresponde a alguma propriedade de interesse que ajuda a

descrição de uma entidade.
N
As tabelas, entidades, relacionam-se umas as outras através de

chaves. Uma chave é um conjunto de um ou mais atributos que determinam a
U
unicidade de cada registro.

A unicidade dos registros, determinada por sua chave, também é
fundamental para a criação dos índices.
Temos dois tipos de chaves:
Chave primária: (PK - Primary Key) é a chave que identifica cada registro
dando-lhe unicidade. A chave primária nunca se repetirá.
139
Chave Estrangeira: (FK - Foreign Key) é a chave formada através de um

relacionamento com a chave primária de outra tabela. Define um
relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso a
chave primária seja composta na origem, a chave estrangeira também o será.
6.3.2. Compreendendo o Modelo
Nos modelos lógico e físico apresentados nas figuras 3 e 4, observa-se

a presença das seguintes entidades: TaxaCondominio, ContaMensal,
PagamentoMes, Pessoa, Historico e Unidade.
S
A entidade TaxaCondominio é composta pelos seguintes atributos:
TC_mesRef (PK), CM_id (FK), TC_valorTaxa, TC_dataGeracao,
TC_dataVencimento. A entidade
A
TaxaCondominio é identificada pelo atributo
chave TC_mesRef. A entidade ContaMensal é composta pelos seguintes atributos:
CM_id (PK), CM_tipo, CM_valorConta, CM_mesreferencia, CM_dataVencimento. A
IN
entidade ContaMensal é identificada pelo atributo CM_id. A entidade
LancamentoMes é composta pelos seguintes atributos: LM_id (PK), TC_mesRef
(FK), CM_id (FK), U_numero (FK), LM_data, LM_referencia, LM_tipo, LM_valor,
IM
LM_multa, LM_valorTotal. A entidade LancamentoMes é identificada pelo atributo

chave LM_id. A entidade Unidade é composta pelos seguintes atributos: U_numero
(PK), morador (FK), proprietario (FK). A entidade Unidade é identificada pelo atributo
chave U_numero. A entidade Pessoa é composta pelos seguintes atributos: P_cpf
N
(PK), P_nome, P_telefone. A entidade Pessoa é identificada pelo atributo chave

P_cpf. A entidade Historico é composta pelos seguintes atributos: H_historico (PK),
morador (FK), proprietario (FK), U_numero, H_pro_Venda, H_pro_aquisicao,
U
H_mor_Saida, H_mor_Entrada. A entidade Historico é identificada pelo atributo

chave H_historico. A entidade Usuario é composta pelos seguintes atributos: id
(PK), nome, senha. A entidade Usuario é identificada pelo atributo chave id.
6.4. PADRÃO DE PROJETOS DAO
DAO (Data Access Object) é um padrão para persistência de dados

que permite separar regras de negócio das regras de acesso a banco de dados.
140
Numa aplicação que utilize a arquitetura MVC (Model, View, Controler), todas as
funcionalidades de bancos de dados, tais como obter as conexões, mapear objetos
Java para tipos de dados SQL ou executar comandos SQL, devem ser feitas por
classes de DAO.
Usando-se esse padrão a camada de negócios acessa os dados
persistidos sem ter conhecimento se os dados estão em um banco de dados
relacional ou um arquivo XML (eXtensible Markup Language). O padrão DAO
esconde os detalhes da execução da origem dos dados (SUN, 2009).
Utilizou-se o DAO para abstrair e encapsular todo o acesso à fonte de
dados. O DAO gerencia a conexão com a fonte de dados para obter e armazenar
dados (SUN, 2009).
S
A figura 87 apresenta a estrutura do padrão DAO. A classe
DataAccessObject encapsula o acesso aos dados, que por sua vez é mantido pela
A
classe DataSource que pode ser um arquivo XML, uma base de dados ou
algum serviço remoto, ou seja, a origem dos dados. A classe BusinessObject
IN
representa a aplicação (também conhecida como cliente do padrão), que usa
um objeto DataAccessObject. Ao utilizar esse objeto DataAcessObject, o objeto
cliente recebe ou envia um objeto TransferObject. Esse objeto contém os dados a
serem enviados ou trazidos da origem dos dados, e normalmente referem-se aos
IM
campos de um registro.
N
U
Figura 87 - Estrutura Padrão DAO.

Adaptado de SUN, 2009.
Para o Sistema de Gestão de Condomínio, foram implementadas

classes DAO para acesso aos objetos através do Hibernate. Essas classes buscam
os dados do banco e os converte em objetos para serem usados pela aplicação.
141
Semelhantemente, deve saber como manipular os objetos, converter em instruções

SQL e enviar ao banco de dados.
6.5. FRAMEWORK HIBERNATE
O Hibernate é um framework de mapeamento objeto/relacional para

Java. Possui um conjunto de classes e interfaces e tem como objetivo disponibilizar
objetos para a função de armazenar, persistir os dados.
Tendo em vista que grande parte das aplicações desenvolvidas
mantém suas informações gravadas em um banco de dados relacional, o grande
problema é que, atualmente, as melhores linguagens de programação são
S
orientadas a objeto tornando complicado a integração entre esse tipo de banco de
dados e essas linguagens. Além disso, mesmo em linguagens estruturadas como
Java, trabalhar com banco de dados tornava-se uma tarefa árdua à medida que a
A
aplicação cresce. Um modelo de programação muito usado, mesmo em linguagens
tipicamente orientadas a objeto como Java, é misturar lógica de negócio com código
IN
SQL. Caso o banco de dados de aplicação mude, seria necessário reescrever
praticamente toda a aplicação, para dar suporte ao novo banco.
Assim uma técnica bastante conhecida da orientação a objetos é o
encapsulamento, onde é possível esconder as regras dentro de objetos e definir
IM
alguns métodos nesses objetos que o mundo externo poderá usar para ter acesso
ao resultado dos códigos. Essa idéia foi adaptada à programação com banco de
dados. Os métodos necessários ao acesso e manipulação do banco ficam
escondidos dentro de classes básicas. As outras partes da aplicação usam essas
N
classes e seus objetos, ou seja, a aplicação nunca terá acesso diretamente ao

nosso banco (LEMES, 2007).
U
O Hibernate permite o mapeamento dessas classes Java com tabelas

de banco de dados (e de objetos Java para tabelas de banco de dados) e também
possibilita pesquisas e retorno de dados, podendo reduzir, significativamente, o
tempo de desenvolvimento antes investido em controlar o relacionamento objeto-
relacional.
Uma das funcionalidades do Hibernate é a geração de código através
da engenharia reversa, que possibilita a implementação das classes Java de
142
entidade a partir da estrutura das tabelas criadas no Banco de Dados. Tendo sido
essa a maneira utilizada para iniciar-se a codificação do sistema em questão.
6.5.1. Características Hibernate
Modelo de programação natural: suporta desenvolvimento em

programação orientada a objeto (OO) natural; herança, polimorfismo, agregação e
também a Java Collections framework.
Suporte modelos objetos detalhados: oferece uma grande variedade
de mapeamentos para collections e objetos dependentes.
Sem código extra no momento de compilação dos bytecodes: não
S
existe código extra gerado na compilação dos códigos fontes para bytecode.
Alta escalabilidade: tem alta performance com sua arquitetura com 2
caches e pode ser utilizado em cluster.
A
Query language: soluciona ambos os lados, não somente como enviar
os dados para o banco de dados, como também como buscar os mesmos do banco
IN
de dados.
Suporte a transações a “nível de aplicação”: suporta contextos de
persistência de longa duração, detach/reattach e executa lock otimista
automaticamente;
IM
Free /Open source: é licenciado sobre a licença do tipo LGPL (Lesser

GNU Public License).
Suporte a API JCA: possui compatibilidade com a API Java JCA
N
garantindo que possa se conectar com banco de dados legados de forma

transparente.
U
6.5.2. Arquitetura do Hibernate
O Hibernate tem como objetivo controlar toda a persistência das

aplicações, diminuindo consideravelmente o tempo de desenvolvimento da
aplicação. Para atingir este objetivo, foi criado de forma a ficar entre as aplicações e
o banco de dados, traduzindo as chamadas ao banco de dados e, também,
controlando a persistência dos dados (Figura 88).
143
S
Figura 88 – Arquitetura Hibernate.
Adaptado de Hibernate (2009).
A
IN
• Hibernate.properties: configuração do Hibernate com relação ao SGBD (url,
senha, driver JDBC, etc. ).
• XML mapping - Annotation: associa cada classe a uma tabela no SGBD e

IM
seus campos às colunas.
• Persistence Object: classe derivada da classe mapeada da aplicação, que

contém os métodos para acesso ao SGBD.
N
6.5.3. Mapeamento Objeto Relacional
De acordo com Bauer e King (2005, p. 31-32):

U
O mapeamento objeto relacional é a persistência automatizada de objetos

dentro de um aplicativo Java para as tabelas em um banco de dados
relacional, usando metadados que descrevem o mapeamento entre os
objetos de banco de dados. O ORM (Object Role Modeling),
essencialmente, trabalha transformando dados de modo reversível de uma
representação em outra.
O uso do Hibernate torna a aplicação maleável a mais de um tipo de

banco de dados, isso depende, na maioria das vezes, apenas de poucos minutos de
uma reconfiguração básica do framework. Ele também deixa transparentes as
operações básicas de inserção, recuperação, atualização e remoção de dados.
144
Contudo o principal ponto de destaque está no paradigma de orientação a objetos

para banco de dados, tornado a modelagem e o trabalho de programação muito
mais elegante e compreensível.
A solução do ORM consiste nas quatro peças seguintes:
• Uma API para executar operações CRUD (Create, retrieve, updade, delete)
básicas em objetos de classes persistentes.
• A linguagem ou API para especificar consultas que referenciem classes e
propriedades de classes.
• Um recurso para especificar o mapeamento de metadados.
• Um técnica para a implementação do ORM para interagir com objetos
S
transacionais a fim de executar a verificação suja, buscas de associação
ociosas e outras funções de otimização.
A
Ainda, considerando Bauer e King (2005, p. 32) “o termo ORM é usado
para incluir qualquer camada de persistência onde o SQL seja gerado
automaticamente a partir de uma descrição baseada em metadados”.
IN
O mapeamento é feito utilizando annotations, além disto, é direcionado
para as classes e não para as tabelas diretamente. Uma estrutura específica é
validada, o qual indica as propriedades a serem mapeadas em um objeto, permitindo
IM
a inclusão de relacionamentos, de forma a simular as relações existentes em bancos

de dados relacionados. O Hibernate permite o mapeamento objeto-relacional de
dados permitindo persistência transparente para o desenvolvimento das aplicações
e, por conseqüência, diminuindo a possibilidade de erros nesta etapa e também
N
minimizando o trabalho manual da equipe do projeto no mapeamento destas

relações objeto-relacional. Para atingir este objetivo há a associação de
mapeamentos com classes persistentes criadas especificamente para cada objeto
U
mapeado.
As bibliotecas de Mapeamento Objeto Relacional fazem o mapeamento
de tabelas para classes. Como exemplo o banco de dados desenvolvido para o
sistema possui uma tabela chamada Historico, a aplicação possuirá, uma classe
denominada Historico. Essa classe definirá atributos, que serão usados para receber
e alterar os dados dos campos das tabelas, além de métodos para realizar as
operações.
145
Além disso, as classes que fazem essa interface com as tabelas do

banco de dados, provêem um conjunto de métodos de alto-nível que servem para
realizar operações básicas nas tabelas, como recuperar um registro através de um
id, dentre outros.
A figura 89 abaixo apresenta o arquivo onde os pacotes e as classes
anotadas são declaradas em um arquivo XML regular, geralmente o
"hibernate.cfg.xml". Além disso, as propriedades de acesso ao banco também foram
definidas nesse arquivo.
Nele é possível verificar a tag <session-factory> que delimita as
configurações para a sessão. Dentro dela existem as tags <property> cujos
atributos definem as configurações com o banco de dados e <mapping class> que
S
definem o mapeamento das classes que vão gerar os objetos para serem
persistidos. Todas essas informações ficam dentro da tag <Hibernate-configuration>.
A
Dentre os principais parâmetros destacamos:
• property name="hibernate.connection.url" é utilizado para informar os

IN
parâmetros de localização do SGBD.
• property name="hibernate.dialect" representa o dialeto utilizado pelo SGBD
pois existem diferenças nas implementações dos diferentes fornecedores de
IM
SGBDs.
• property name="hibernate.connection.driver_class" informa qual o driver
JDBC deve ser utilizado para a conexão.
• property name="hibernate.connection.username" informa qual o nome do
N
usuário do SGBD.
• property name="hibernate.connection.password" informa qual a senha de
conexão do SGBD.
U
A figura 89 traz o código do arquivo hibernate.cfg.xml usado na

aplicação.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
<property
name="hibernate.connection.url">jdbc:mysql://localhost:3306/db_condominio</property
>
146
<property name="hibernate.connection.username">root</property>
<property name="hibernate.connection.password"></property>
<property name="hibernate.current_session_context_class">thread</property>
<property
name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>
<property
name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="show_sql">true</property>
<property name="connection.pool_size">1</property>

<mapping class="br.uniminas.entidades.UsuarioEntidade" />
<mapping class="br.uniminas.entidades.Unidade" />
<mapping class="br.uniminas.entidades.Pessoa" />
<mapping class="br.uniminas.entidades.Historico" />
</session-factory>
</hibernate-configuration>
S
Figura 89 - Arquivo "hibernate.cfg.xml".
Para o sistema desenvolvido, foi implementada uma classe estática
criação e recuperação de sessões.

...
A
chamada de "HibernateUtil" (figura 90). A função dessa classe é encapsular a
IN
public class HibernateUtil {
private static final SessionFactory sessionFactory;
static {
try {
// Create the SessionFactory from hibernate.cfg.xml
IM
sessionFactory = new
AnnotationConfiguration().configure().buildSessionFactory();
} catch (Throwable ex) {
// Make sure you log the exception, as it might be swallowed
System.err.println("Initial SessionFactory creation failed." + ex);
throw new ExceptionInInitializerError(ex);
N
}
}
public static SessionFactory getSessionFactory() {
return sessionFactory;}
U
}
Figura 90 – Classe Hibernate Útil.
Na figura 91, é possível verificar o uso de um método da sessão

chamado createQuery, o qual permite usar uma HQL (Hibernate Query Language)
para recuperar registros do banco. HQL consiste em um diatelo SQL para o
Hibernate. É uma poderosa ferramenta de consulta que, apesar de se parecer com o
SQL, é totalmente orientado a objetos, incluindo os paradigmas de herança,
polimorfismo e encapsulamento.
147
Pode-se observar ainda que os métodos para manipulação dos dados,

como por exemplo, o método insert recebe um objeto Historico como parâmetro e o
mesmo é persistido no banco pelo Hibernate.
Compreendendo-se assim o que ocorreu. Primeiramente, a
recuperação da sessão (session) com uso da classe HibernateUtil. Nesse momento,
uma sessão (session) seria mais ou menos como uma unidade de trabalho, uma
transação com o banco de dados, para um melhor entendimento.
Depois, utilizamos a sessão para iniciar uma transação, salvar o objeto
no banco de dados e, por último, "commitar" a transação.
A sessão é iniciada sempre que o método getCurrentSession é
invocado e terminado através de um commit ou rollback.
S
...
private Historico hist;
A
public class HistoricoHibernateDAO implements HistoricoDAO {
private List<Historico> histList;

private Session session = HibernateUtil.getSessionFactory()
IN
.getCurrentSession();
public Historico getHistorico(int i) {
try {
session.beginTransaction();
Query q = session.createQuery("from Historico where
IM
id=:Id_Historico");
q.setInteger("Id_Historico", i);
return (Historico) q.uniqueResult();
} finally {
// session.close();
}
N
}
public List consultaHistorico(String numero){
try {
U
session.beginTransaction();
Query q = (Query) session.createQuery("from Historico where
numero=:U_numero").list();
q.setString("U_numero", numero);
histList=(List<Historico>) q;
return histList;
} finally {
// session.close();
}
}
public void insert(Historico his) {
try { tx = session.beginTransaction();
148
session.save(his);
tx.commit();
if (tx != null)
tx.rollback();
throw e;
} finally {
// session.close();
}
}
public void delete(String id) {
hist = (Historico) session.get(Historico.class, id);
session.delete(hist);
S
tx.commit();
if (tx != null)
tx.rollback();
}
throw e;
} finally {
}
A
IN
public void updateHistorico(Historico hist) {
session.update(hist);
IM
tx.commit();
if (tx != null)
tx.rollback();
throw e;
} finally {
N
}
}
}
Figura 91 – Classe de persistência HistoricoHibernateDAO.
U
6.6. MECANISMOS DE PERSISTÊNCIA
Como a maioria das ferramentas ORM, o Hibernate necessita de

metadados para determinar como deverá ser feita a transformação dos dados entre
classes e tabelas. Como opção, utilizamos um recurso, que veio com o JDK 5.0,
chamado de Annotation.
O mapeamento objeto relacional se estabelece através de anotações
(annottations) colocadas nas classes de entidade. Esse mapeamento determina a
149
correspondência entre as classes Java e as tabelas do banco de dados, de modo

que para cada classe de entidade haverá uma tabela. No processo de mapeamento
é estabelecida, ainda, a correspondência entre os atributos das classes e seus pares
nas respectivas tabelas. É a partir dessa identificação, que o Hibernate, framework
usado para fazer a persistência com o banco de dados, pode persistir no banco de
dados o objeto Java instanciado. Através das anotações é feita uma junção entre o
objeto Java criado e a tabela no banco
Assim os dados são persistidos não mais usando arquivos XML como
anteriormente, e sim com uso de annotations. Anotações são diretivas colocadas no
código Java para associar as classes a tabelas no SGBD, substituindo o arquivo
XML.
S
Para melhor uma compreensão, é possível visualizar na figura 92 a
classe de entidade Histórico, e as anotações usadas como mecanismos de
persistência.
A
IN
...
@Entity
@Table(name = "historico")
public class Historico {
//@GeneratedValue(strategy=GenerationType.AUTO)
@Id
IM
@Column(name = "Id_Historico", unique = true)

int id;
@Column(name = "H_proVenda", unique = true)
Date h_proVenda;
@Column(name = "H_proAquisicao", unique = true)
Date h_proAquiscao;
N
@Column(name = "H_morEntrada", unique = true)

Date h_morEntrada;
@Column(name = "H_morSaida", unique = true)
Date h_morSaida;
U
@ManyToOne
@JoinColumn(name = "U_numero", unique = true)
Unidade numero;
@ManyToOne
@JoinColumn(name = "morador", unique = true)
Pessoa morador;
@ManyToOne
@JoinColumn(name = "proprietario", unique = true)
Pessoa proprietario;
public Historico() {}
public Historico(Date hProVenda, Date hProAqui, Date morEntr,
Date morSaida, Unidade u, Pessoa mor, Pessoa prop) {
this.h_proVenda = hProVenda;
150
this.h_proAquiscao = hProAqui;
this.h_morEntrada = morEntr;
this.h_morSaida = morSaida;
this.numero = u;
this.morador = mor;
this.proprietario = prop;
}
...
Figura 92 – Classe de entidade Histórico.
Quanto à aplicabilidade das anotações implementadas segue:

@Entity: declara a classe como uma classe de entidade (ou uma classe
persistente). Id, todas as classes de entidade (entity classes) persistentes
precisarão de tal atributo se quisermos utilizar todos os recursos do Hibernate.
S
@Table: usada para definir qual tabela será usada para persistir os objetos dessa
classe. Se essa anotação não for usada, o Hibernate irá procurar por uma tabela
com o mesmo nome da classe.
A
@Id: declara qual campo, atributo da classe será usado como identificador. Neste
IN
caso, foi definido o atributo "id".
@Column: usada para definir as propriedades dos atributos.
@ManyToOne: informa que existe um relacionamento de um para muitos.
@JoinColumn: é utilizada para informar que o nome da chave estrangeira
IM
utilizada no relacionamento das entidades relacionais.

O Hibernate não somente fornece uma solução com todas funções que
satisfaçam frontalmente essas exigências, ele é também uma arquitetura flexível e
configurável. Ele foi o projetado com modularidade, conectibilidade, extensibilidade e
N
com a customização do usuário em mente (BAUER & KING, 2005). Isso torna a
interação com o banco de dados transparente, do ponto de vista da programação
U
Java. A principal vantagem é a mudança do paradigma de trabalho Estruturado para

o Orientado a Objeto, eliminado, assim, muito trabalho repetitivo e tedioso. A
desvantagem é a diminuição do desempenho, decorrente da existência de uma
camada intermediária entre o banco de dados e a aplicação, porém ela pode ser
diminuída utilizando configurações avançadas do Hibernate, por exemplo o trabalho
com cache.
151
7. CONCLUSÃO
O levantamento dos requisitos do sistema, a documentação dos casos

de uso e a elaboração do diagrama de classe e dos diagramas de seqüência
permitiram à equipe perceber melhor o desenho do sistema, facilitando, inclusive a
comunicação entre seus membros. Atender os preceitos técnicos da análise de
sistema possibilitou bom entendimento do problema e da aplicação antes de seu
desenvolvimento. Os diagramas de classe e de seqüência elaborados já em nível de
projeto foram considerados importantes documentos após o desenvolvimento do
S
sistema uma vez que serão a base para a manutenção e expansão do mesmo.
O uso da linguagem Java permitiu a implementação do software, pois
A
além de não apresentar custo, opera em qualquer sistema operacional. Essa
característica atendeu, logicamente, a uma das exigências do projeto: o software
IN
deveria operar sobre o sistema operacional Windows XP, uma vez que o
equipamento do cliente possuía esta configuração. Além disso, a linguagem
orientada a objeto permitiu uma modelagem dentro da tendência atual, o que, de
acordo com a literatura, deverá facilitar as alterações e adequações necessárias
IM
para a atualização e expansão do sistema.

A escolha da linguagem orientou a definição da ferramenta IDE
(Integrated Development Environment) de desenvolvimento, cuja escolha recaiu
sobre o Eclipse, que agregado aos frameworks Struts e Hibernate apresentou boa
N
produtividade, permitindo, também, simplificação do código. Observa-se, entretanto,

que durante o processo de desenvolvimento foi necessário usar mais de um
U
equipamento e sob esse aspecto, o Eclipse não se mostrou estável. Por diversas
vezes, as bibliotecas tiveram de ser reinseridas, pois não foram reconhecidas apesar
de estarem no projeto.
O uso do Hibernate facilitou a implementação das classes de entidade,
através da engenharia reversa, que embora seja um processo de muitos passos,
garante a correlação entre as classes e as tabelas do banco de dados. Observa-se,
ainda, que esse procedimento pode ser realizado escalonadamente, facilitando a
implementação por iterações, que muitas vezes se fazem necessárias, quando do
desenvolvimento de grandes projetos. As annottations realizaram com facilidade o
152
mapeamento objeto-relacional e o padrão de projeto DAO permitiu a independência

do banco de dados utilizado, fazendo a persistência dos dados de forma simples. O
MySQL apresentou boa performance, tendo sido adequado à aplicação.
O modelo MVC permitiu independência entre os vários elementos de
modo que as alterações de código que se fizeram necessárias tiveram pouco ou
nenhum impacto nos demais componentes. O padrão Business Object foi
responsável pela camada de negócio respondendo satisfatoriamente às
necessidades da aplicação, trazendo, ainda, a vantagem de ser de fácil
implementação.
Uma vez definido que seria uma aplicação Web, a coerência
determinou o seguimento dos padrões de projeto para J2EE (desing patterns J2EE).
S
Comprovou-se a importância dos padrões, que apresentam soluções claras para
determinados problemas. No caso se percebeu a necessidade de um controle
A
central da aplicação, como elemento organizador das requisições. Assim, o
controlador foi peça chave na aplicação, cujo desenvolvimento foi facilitado pelo
IN
emprego do Struts, que implementa automaticamente o Front Controller, através do
mapeamento das ações no arquivo Struts.xml.
É importante reforçar que o uso dos frameworks facilitou bastante o
desenvolvimento dessa aplicação multicamadas, quer seja pela implementação dos
IM
padrões Front Controller e Application Controller implementados pelo Struts, quer

seja pelo mapeamento objeto relacional que faz a interação com o banco de dados
propiciado pelo Hibernate. Estabeleceu-se, assim, uma seqüência lógica que em
conjunto com os preceitos da orientação a objetos, permitiram o desenvolvimento de
N
um sistema cuja manutenibilidade será bastante facilitada.
Ressalta-se, ainda que o Hibernate não somente fornece uma solução

U
com funções que auxiliam o desenvolvimento, mas também possui arquitetura

flexível e configurável. Isso torna a interação com o banco de dados transparente, do
ponto de vista da programação Java. A literatura cita como desvantagem a
diminuição do desempenho, em função da existência de uma camada intermediária
entre o banco de dados e a aplicação, que pode ser diminuída utilizando
configurações avançadas do Hibernate, como o trabalho com cache.
O sistema foi parcialmente desenvolvido, dos quatorze casos de uso
levantados foram implementados seis. Como o número de condomínios está
153
crescendo e a relação entre a gerência e os condôminos tem evoluído, acredita-se

que seja importante a continuidade desse projeto. Aliado a isso, as características
do sistema e a documentação para apoiar a expansão do projeto está disponível, o
que facilitará a realização dessa tarefa.
S
A
IN
IM
N
U
154
REFERÊNCIAS BIBLIOGRÁFICAS
ABREU, Edriano. Baixa idade média. Disponível em:

<http://www.saberhistoria.hpg.ig.com.br/nova_pagina_35.htm>. Acesso em: 7 mar
2009.
AHMED, Khawar Zaman; UMRYS4H, Cary E. Desenvolvendo aplicações

comerciais em Java com J2EE e UML. Rio de Janeiro: Ciência Moderna, 2002.
302 p.
ALUR, Deepak; CRUPI, John; MALKS, Dan. Core J2EE Patterns: as melhores
práticas e estratégias de design.Tradução de Altair Dias Caldas de Morais. Rio de
Janeiro: Elsevier, 2004. 587 p.
S
ANGOTI JR., Edson. Programação de Aplicações para Internet usando
JSP/SERVLETS. Diponível em: <http://si.uniminas.br/~angoti/arquivos>. Acesso em:
04 jun. 2009a.
A
ANGOTI JR., Edson. Padrões de Projeto JEE. Disponível
em:<http://si.uniminas.br/~angoti/arquivos/PadroesProjetoJEE.pdf> Acesso em: 09
IN
jun. 2009b.
_______ Edson. Apache Tomcat. Disponível

em :<http://si.uniminas.br/~angoti/arquivos/Tomcat.pdf> Acesso em: 16 jun. 2009c.
IM
APOSTILA DE Java. 42 p. Apostila. Disponível em

<http://www.si.uniminas.br/~mauro/SIS07/ApostilaJava.pdf>. Acesso em 13 mai.
2009.
ARAUJO, Vanessa L de. Regras de negócio. Disponível em:

<http://sysreq.incubadora.fapesp.br/portal/down/apr/RegrasNegocio.pdf>. Acesso
N
em 16 maio 2009.
ASCENCIO, Ana Fernanda Gomes. Método Heurístico para Projetar e Analisar

Interfaces Hipermídia Inteligentes. In: IV Semana Acadêmica do Programa de Pós-
U
Graduação da Ciência da Computação, 1999, Porto Alegre. Anais da IV Semana

Acadêmica do Programa de Pós-Graduação da Ciência da Computação, 1999. p.
195-198. Disponível em:
<http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana99/anafernanda/anafernand
a.html>. Acesso em: 17 maio 2009.
BAUER, Christian; KING, Gavin. Hibernate em Ação. Tradução de Cláudio

Rodrigues Pistille, Geane Girotto e Fábio Makoto. Rio de Janeiro: Ciência Moderna,
2005. 532p. Título original: Hibernate in Action.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML, guia do usuário.

Rio de janeiro: Campus, 2000. 472 p.
155
BRASIL, Fundação Instituto Brasileiro de Geografia e Estatística. Dados históricos

dos censos. Disponível em:
<http://www.ibge.com.br/home/estatistica/populacao/censohistorico/1940_1996.shtm
>. Acesso em: 7 mar 2009a.
________, Fundação Instituto Brasileiro de Geografia e Estatística. Disponível em:

<http://www.ibge.com.br/home/>. Acesso em: 7 mar 2009b.
________, Fundação Instituto Brasileiro de Geografia e Estatística. Tendências

demográficas: uma análise dos resultados da sinopse preliminar do censo
demográfico 2000. Rio de Janeiro: IBGE, 2001. 63 p.
_______. Lei 4.591 de 16 de dezembro de 1964. Dispõe sobre o condomínio em

edificações e as incorporações imobiliárias.
S
DATE, C. J. Introdução a Sistemas de Banco de Dados. Tradução de Daniel
Vieira. Rio de Janeiro: Campus, 2004. 865p. Título original: An Introduction to
Database Systems.
A
DEBONI, José Eduardo Zindel. Modelagem orientada a objetos com a UML. São
Paulo: Futura, 2003. 219 p.
IN
DUMOULIN, Cedric; FRANCISCUS, George; WINTERFELDT, David. Struts em
ação. Tradução de Eveline Vieira Machado. Rio de Janeiro: Ciência Moderna, 2004.
604 p.
ELMASRI, R; NAVATHE, Shamkant. B. Sistemas de Banco de Dados. Tradução

IM
de Marília Guimarães Pinheiro, Claudio Cesar Canhette, Glenda Cristina Valim Melo,
Claudia Vicci Amadeu e Rinaldo Macedo de Morais. 4 ed. São Paulo: Person
Addison Wesley, 2005. 724p. Título original: Fundamentals of Database Systems.
FERREIRA, Simone Bacellar Leal ET all . Requisitos Não Funcionais para Interfaces
com o Usuário - O Uso de Cores. In: IDEAS 1999 - Segunda Jornada
N
iberoamericanas de Ingenieria de Requisitos y Ambientes de Software, 1999. Anais

da Conferência IDEAS 99, 1999. Disponível em: <ftp://ftp.inf.puc-
rio.br/pub/docs/techreports/97_28_ferreira.ps.gz>. Acesso em 17 maio 2009.
U
FREUD, Sigmund. O mal estar na civilização. Rio de Janeiro: Imago. 2002. 116 p.
HIBERNATE. Relational Persistence for Java and .NET. Disponível em:

<http://www.hibernate.org> Acesso em: 14 abr. 2009.
INTRODUCTION TO OMG's Unified Modeling Language™ (UML®). Acesso em: 10

maio 2009. Disponível em: <http://www.omg.org/gettingstarted/what_is_uml.htm>.
DIAS, Klissiomara; BORBA, Paulo. Padrões de Projeto para Estruturação de

Aplicações Distribuídas Enterpise JavaBeans. In: Second Latin American
Conference on Pattern Languages Programming, 2002, Itaipava. SugarLoafPLoP
2002. São Carlos: ICMC - Universidade de São Paulo, 2002. p. 55-86. Disponível
156
em: <http://twiki.cin.ufpe.br/twiki/pub/SPG/GenteAreaPublications/PLOP02_dias.pdf>.
Acesso em: 27 mai. 2009.
LEMES, M. V. S; Introdução a Persistência de Dados com Hibernate e

Annotation. Junho 2007. 19p (Mimeo.). Disponível em:
<http://www.marvinlemos.net/download/arquivo/118/hibernate_annotation.pdf>.
Acesso em: 3 jun. 2009.
MARTINS, Júnior Machado. Utilizando o Padrão de Projeto Observable.

Disponível em: <http://www.inf.unisinos.br/~barbosa/pipca/consipro1/a3.pdf>.
MEIRELLES, W. V; PEDEVIRA, G; Hibernate: uma forma simples de trabalhar com

persistência de dados em java. Novembro 2006. 17p. Universidade Federal da
Grande Dourados. Disponível em:
<http://www.unibratec.com.br/sbts/diretorio/NOVOHIB.pdf>. Acesso em: 3 jun. 2009.
S
MIRANDA, Ângelo Tiago. Conseqüências e características das cidades.
Disponível em: <http://educacao.uol.com.br/geografia/ult1701u57.jhtm>. . Acesso
em: 7 mar 2009.
A
MYSQL. The world's most popular open source. Disponível em:
<http://www.mysql.com>. Acesso em: 15 abr. 2009.
IN
PREFEITURA DE UBERLÂNDIA. Secretaria Municipal de Planejamento. Banco de
dados integrados. Uberlândia, 2007. Disponível em:
<http://www.uberlandia.mg.gov.br/midia/documentos/planejamento_urbano/BDI_200
7_vol_1.pdf>. Acesso em: 7 mar 2009.
IM
RICARTE. I. L. M; Sistemas de bancos de dados orientados a objetos. Setembro

1998. 41p. Universidade Estadual de Campinas (Mimeo.). Disponível em: <
ftp://ftp.dca.fee.unicamp.br/pub/docs/ricarte/apostilas/mc_sbdoo.pdf>. Acesso em: 3
jun. 2009.
N
SILVA, Paulo C. Barreto da. Utilizando UML: diagrama de classes. SQL Magazine,
Rio de Janeiro, edição 63, ano 5, p. 10-17, 2007.
SILVA, Sonia Maria Antunes da; BONIN, Marcos Rodrigo; PALUDO, Marco Antônio.
U
Levantamento de requisitos segundo o método volere. Disponível em: <

http://publica.fesppr.br/index.php/rnti/article/viewFile/v1n1ART2/86>. Acesso em: 16
maio 2009.
SILVEIRA, H. M. Comunidade do sistema gene de apoio ao aprendizado de

genética. 2008. 66 f. Trabalho de Graduação Interdisciplinar (Curso superior em
Tecnologia em informática) - Centro Superior de Educação Tecnológica –
Universidade Estadual de Campinas, Limeira, 2008. Disponível em:
<http://www.ceset.unicamp.br/liag/Gene/artigos/monografiaFinalHenrique_v7_.pdf>.
157
SUN, Core J2EE patterns: data access object. Disponível em:

<http://www.sun.com/>. Acesso em: 15 jun. 2009.
TOOD, Nick; SZOLKOWSKI, Mark. Java Server Pages: o guia do desenvolvedor.

Tradução de Edson Furmankiewic. Rio de Janeiro: Elsevier, 2003. 621 p.
UML. Object Management Group - Unified Modeling Language. Disponível

em: <http://www.uml.org>. Acesso em: 15 abr. 2009.
URBANIZAÇÃO DO Brasil. Disponível em:

<http://www.passeiweb.com/na_ponta_lingua/sala_de_aula/geografia/geografia_do_
brasil/quadro_humano/brasil_urbanizacao>. Acesso em: 7 mar. 2009.
URBANIZAÇÃO DO mundo. Disponível em:

<http://www.brasilescola.com/geografia/urbanizacao-mundo.htm>. Acesso em: 7 mar
2009.
S
WAZLAWICK, Raul Sidney. Análise e projetos de sistema orientados a objetos. 2.
Ed. Rio de Janeiro: Elsevier, 2004. 295 p.
A
WIKIPEDIA. Java (linguagem de programação). Disponível em: (Orlando)
<http://pt.wikipedia.org/wiki/Java/linguagem_de_programa%C3%A7%C3%A3o>.
Acesso em 15 maio 2009a.
IN
_______. Modelagem de dados. Disponível em (Marco 2)
<http://pt.wikipedia.org/wiki/Modelagem_de_dados>. Acesso em: 2 jun. 2009b.
_______. Persistência de dados. Disponível em

IM
<http://pt.wikipedia.org/wiki/Persist%C3%AAncia_de_dados >. Acesso em: 4 maio

2009c.
_______. Polis. Disponível em: <http://pt.wikipedia.org/wiki/P%C3%B3lis>. Acesso

em: 7 mar 2009d.
N
YOSHIMA, Rodrigo. Modelando o escopo do sistema com casos de uso. In:

______. Projeto de Software com UML 2.0. ASPERCOM, 2005. p. 9-27. 2009.
Disponível em: <http://www.aspercom.com.br/ead/mod/resource/view.php?id=16>.
Acesso em 23 fev. 2009.
U
158
APÊNDICE
Código do arquivo struts.xml
<!DOCTYPE struts (View Source for full doctype...)>

<struts>
<package name="default" extends="struts-default">
- 
<action name="login" method="execute" class="br.uniminas.action.Login2">
S
<result>/page/login.jsp</result>
<result name="success">/page/principal.jsp</result>
<result name="erro">/page/login.jsp</result>
</action>
<action name="principal">
<result>/page/principal.jsp</result>
A
IN
</action>
<action name="getAllPessoas" method="getAllPessoas"
<result name="success">/page/pessoas.jsp</result>
</action>
IM
<action name="getPessoa" method="getPessoa"

<result name="success">/page/pessoa.jsp</result>
</action>
<action name="setUpForInsertOrUpdate" method="setUpForInsertOrUpdate"
N
<result name="success">/page/cadastroPessoaForm.jsp</result>
</action>
U
</action>
<action name="setUpForInsertOrUpdate2" method="setUpForInsertOrUpdate2"
<result name="success">/page/consultaPessoaForm.jsp</result>
</action>
<result name="success">/page/consultaUnidadeForm.jsp</result>
</action>
159

<result name="success">/page/consultaHistorico.jsp</result>
</action>
<action name="consultarPessoa" method="consultaPessoa"
<result name="success">/page/pessoa.jsp</result>
</action>
<action name="consultarUnidade" method="consultaUnidade"
<result name="success">/page/unidade.jsp</result>
</action>
S
<action name="consultarHistorico" method="consultaHistorico"
<result name="success">/page/historico.jsp</result>
</action>
A
<action name="delete" method="deletePessoa"
IN
<result name="success" type="redirect-action">getAllPessoas</result>
</action>
</package>
</struts>
IM
N
U

Gestao de Condominio

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gestao de Condominio

Enviado por

Direitos autorais:

Formatos disponíveis

UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA

FACULDADE DE CIÊNCIAS APLICADAS DE MINAS

Marco Aurélio Silva Rodrigues

UNIMINAS como parte dos requisitos para a

Orientador: Prof. Msc. Edson Angoti Júnior

SISTEMA PARA GESTÃO DE CONDOMÍNIO

Professor. Msc.Edson Angoti Júnior (Orientador)

Profa. Dra. Kátia Lopes Silva

Prof. Dr. Mauro Hemerly Gazzani

Se enxerguei longe, foi porque me apoiei nos ombros de gigantes.

A todos os professores do Curso de Sistema de Informação da

A Revolução Industrial, um dos marcos da Idade Moderna efetivamente

acesso ao banco de dados foi empregado o padrão de projeto DAO, configurado

considerada a mais tranqüila de todas, que sugere espaço e profundidade. As

do código. A engenharia reversa realizada pelo Hibernate facilitou a implementação

Palavras chave: gestão de condomínio; sistema de informação; implementação de

engineering performed by the Hibernate facilitating the implementation of entities

API Application Programming Interface

Java Enterprise Edition

MVC Model View Control

ORM Object Role Modeling

Tabela 1 – População brasileira, segundo os censos demográficos de 1940, 1950, 1960,

Quadro 2 – Requisitos do sistema. ...................................................................................................... 30

Quadro 12 – Especificação do caso de uso: Gerar Taxa de Condomínio........................................... 58

Figura 1 – Grau de Urbanização, Brasil, 2000..................................................................................... 19

Consultar Unidade. ........................................................................................................... 85

Figura 30 – Classe PessoaBO. ............................................................................................................ 92

Figura 33 – Página pesquisarPessoa.jsp............................................................................................. 96

UnidadeBO. .................................................................................................................... 109

implementado na classe CadastrarPessoaAction, quando já há histórico da

construtor da classe HistoricoBO. .................................................................................. 111

Figura 85 – Modelo Físico de Banco de Dados ................................................................................. 137

Figura 89 - Arquivo "hibernate.cfg.xml".............................................................................................. 146

Figura 92 – Classe de entidade Historico .......................................................................................... 150

3.6.1. Caso de Uso 01: Fazer Login.................................................................. 37

3.6.6. Caso de Uso 06: Atualizar Histórico........................................................ 49

3.6.8. Caso de Uso 08: Registrar Conta a Pagar .............................................. 53

6.2. MYSQL ............................................................................................................... 131

6.4. PADRÃO DE PROJETOS DAO ................................................................................ 139

6.5.2. Arquitetura do Hibernate ....................................................................... 142

1.1. UM BREVE HISTÓRICO

A instituição da sociedade ocorreu como um movimento dos homens

“organizada” a sociedade, a população não se encontrava necessariamente

forte era, por assim dizer, institucionalizada.

desenvolvimento agrícola não foi suficiente para responder às necessidades da

população urbana em relação à rural. Assim, o primeiro país da Europa a se

HABITANTES % HABITANTES % HABITANTES

1940 12.880.182 31,24 28.356.133 68,76 41.236.315

1970 52.084.984 55,92 41.054.053 44,08 93.139.037

1996 123.076.831 78,36 33.993.332 21,64 157.070.163

Observa-se ainda, que a urbanização não se deu de forma homogênea

Localizada na região sudeste, no estado de Minas Gerais, no Triângulo

Tabela 2 – População de Uberlândia, MG, 1996 a 2006.

De maneira geral no país, a urbanização desordenada trouxe em si

1.2. CENÁRIO ATUAL

habitacionais. O síndico do condomínio é um dos proprietários que reside no edifício.

regulamentam a criação, administração e o convívio entre as pessoas, que foram

diretamente relacionada à gestão e à aplicação do conhecimento. Embora, a

desfrutar de forma conveniente o investimento feito na aquisição ou locação do

Na busca dessa excelência, sistemas de informação que apóiem a

permitem, inclusive, o uso de uma versão para teste. As funcionalidades mais

- cálculos automáticos: rateios de despesas;

- emissão de boletos bancários e demonstrativos de despesas;