Upload
wanderweiss-margera
View
20
Download
1
Embed Size (px)
Citation preview
UNIMIN
AS
1
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
SISTEMA PARA GESTÃO DE CONDOMÍNIO
Uberlândia 2009
UNIMIN
AS
2
Marco Aurélio Silva Rodrigues
Maria Margaret de Vasconcelos Lemos
Orlando Alves de Oliveira
SISTEMA PARA GESTÃO DE CONDOMÍNIO
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos para a
obtenção do grau de Bacharel em Sistemas
de Informação.
Orientador: Prof. Msc. Edson Angoti Júnior
Uberlândia 2009
UNIMIN
AS
3
Marcos Aurélio Silva Rodrigues
Maria Margaret de Vasconcelos Lemos
Orlando Alves de Oliveira
SISTEMA PARA GESTÃO DE CONDOMÍNIO
Banca Examinadora:
Uberlândia, 9 de julho de 2009.
________________________________________________________________
Professor. Msc.Edson Angoti Júnior (Orientador)
________________________________________________________________
Profa. Dra. Kátia Lopes Silva
_________________________________________________________________
Prof. Dr. Mauro Hemerly Gazzani
Uberlândia
2009
UNIMIN
AS
Se enxerguei longe, foi porque me apoiei nos ombros de gigantes.
Isaac Newton
UNIMIN
AS
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
na elaboração deste trabalho.
Dividir com vocês essa autoria foi um privilégio que poucos de nós
tiveram!
UNIMIN
AS
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
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,
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
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
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
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
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
UNIMIN
AS
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.
UNIMIN
AS
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
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
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
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
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
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
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.
UNIMIN
AS
Keywords: condominium management, information system, implementation of
software.
UNIMIN
AS
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
HTML Hipertext Modelling Language
HTTP Hipertext Transfer Protocol
FK Foreign key
IBGE Instituto Brasileiro de Geografia e Estatística
IDE Integrated Development Environment
IP Internet Protocol
J2EE Java Enterprise Edition
JDBC Java Database Conectivity
JDK Java Development Kit
JEE Java Enterprise Edition
JPC Java Community Process
JSP Java Server Pages
JVM Java Virtual Machine
LGPL Lesser GNU Public License
MVC Model View Control
OBDC Open-DataBase-Connectivity
OO Orientado a Objeto
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
UNIMIN
AS
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
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
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
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
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
Lista de Figuras
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
UNIMIN
AS
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
Figura 22 – Classes do pacote action.................................................................................................. 75
Figura 23 – Diagrama de sequência com as classes de projeto do caso de uso: Fazer
Login. ................................................................................................................................ 77
Figura 24 – Diagrama de sequência com as classes de projeto do caso de uso:
Cadastrar Dados............................................................................................................... 79
Figura 25 – Diagrama de sequência com as classes de projeto do caso de uso: Listar
Pessoas. ........................................................................................................................... 81
Figura 26 – Diagrama de sequência com as classes de projeto do caso de uso:
Consultar Pessoa.............................................................................................................. 83
Figura 27 – Diagrama de sequência com as classes de projeto do caso de uso:
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
Figura 30 – Classe PessoaBO. ............................................................................................................ 92
Figura 31 – Ciclo de vida do servlet. .................................................................................................... 94
Figura 32 – Código da página consultarPessoaForm.jsp. ................................................................... 95
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
UNIMIN
AS
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
CadastrarPessoaAction. ................................................................................................. 106
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()
implementado na classe CadastrarPessoaAction. ......................................................... 107
Figura 52 – Comando geração do objeto pessoaDAO declarado no construtor da classe
PessoaBO....................................................................................................................... 107
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
Figura 55 – Comandos do método gravaPropAquisicao() implementado pela classe
CadastrarPessoaAction. ................................................................................................. 109
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
UnidadeBO. .................................................................................................................... 109
Figura 58 – Código do método updateUnidade() implementado pela classe
UnidadeHibernateDAO. .................................................................................................. 110
Figura 59 – Comando de persistência declarado no método gravaPropAquisicao()
implementado na classe CadastrarPessoaAction, quando já há histórico da
unidade. .......................................................................................................................... 111
Figura 60 – Comandos de criação do objeto HistoricoHibernateDAO declarado no
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
Figura 63 – Comando de persistência declarado no método gravaPropAquisicao()
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
UNIMIN
AS
Figura 65 – Código do método insert() implementado na classe HistoricoHibernateDAO............... 113
Figura 66 – Mensagem de sucesso gerada pelo método gravaPropAquisicao()
implementado na classe CadastrarPessoaAction. ......................................................... 114
Figura 67 – Código do método isertOrUpdate() implementado na classe
CadastrarPessoaAction. ................................................................................................. 114
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
Figura 76 – Tela com mensagem de erro, CPF cadastrado como morador em outra
unidade. .......................................................................................................................... 124
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
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
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
Figura 89 - Arquivo "hibernate.cfg.xml".............................................................................................. 146
Figura 90 – Classe Hibernate Útil. ..................................................................................................... 146
Figura 91 – Classe de persistência HistoricoHibernateDAO. ............................................................ 148
Figura 92 – Classe de entidade Historico .......................................................................................... 150
UNIMIN
AS
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
1.6. ORGANIZAÇÃO DO TRABALHO ................................................................................. 24
2. ESPECIFICAÇÃO DO PROBLEMA 26
3. ANÁLISE E PROJETO 28
3.1. UNIFIED MODELLING LANGUAGE – UML .................................................................. 28
3.2. ETAPAS DA ANÁLISE DE SISTEMA ............................................................................ 29
3.3. REQUISITOS........................................................................................................... 30
3.4. REGRAS DE NEGÓCIO............................................................................................. 31
3.5. CLASSES ............................................................................................................... 33
3.6. CASOS DE USO ...................................................................................................... 36
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
3.6.6. Caso de Uso 06: Atualizar Histórico........................................................ 49
3.6.7. Caso de Uso 07: Pesquisar Histórico...................................................... 51
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
UNIMIN
AS
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
4.6. TOMCAT ................................................................................................................ 97
4.7. IMPLEMENTAÇÃO.................................................................................................... 98
4.7.1. Struts ...................................................................................................... 98
4.7.2. Diagrama de Pacotes ........................................................................... 100
4.7.3. Implementação do Caso de Uso Cadastrar Dados ............................... 103
5. INTERFACE 116
5.1. DIAGRAMA DE NAVEGABILIDADE............................................................................ 119
6. PERSISTÊNCIA DE DADOS 128
6.1. CONCEITOS DE BANCO DE DADOS......................................................................... 129
6.2. MYSQL............................................................................................................... 131
6.3. MODELAGEM DE BANCO DE DADOS ....................................................................... 134
6.3.1. Modelos ................................................................................................ 134
6.3.2. Compreendendo o Modelo.................................................................... 139
6.4. PADRÃO DE PROJETOS DAO ................................................................................ 139
6.5. FRAMEWORK HIBERNATE...................................................................................... 141
6.5.1. Características Hibernate...................................................................... 142
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
UNIMIN
AS
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
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
(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
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
“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
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
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
UNIMIN
AS
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).
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
1970 houve a inversão, com o predomínio da população urbana (55,92%), como
mostra a tabela 1 (BRASIL, 2009b).
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
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
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
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
UNIMIN
AS
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.
Figura 1 – Grau de Urbanização, Brasil, 2000. Fonte: IBGE (BRASIL, 2001).
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
região Sudeste, sua taxa de urbanização é alta, da ordem de 97,56 por cento, ao
considerar-se o censo de 2000.
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).
UNIMIN
AS
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,
com custo mais acessível.
1.2. CENÁRIO ATUAL
Ao se considerar o município de Uberlândia, o número de condomínios
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
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
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
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
UNIMIN
AS
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
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
de administração de condomínio, inclusive sindicatos e associações de empresas,
apóiam a gestão de condomínios.
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á
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
desfrutar de forma conveniente o investimento feito na aquisição ou locação do
imóvel.
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
UNIMIN
AS
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;
- tesouraria e fluxo de caixa;
- receitas e despesas regulares;
- balancetes;
- relatórios diversos.
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
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.
1.3. IDENTIFICAÇÃO DO PROBLEMA
Optou-se pelo desenvolvimento de um sistema de informação
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.
UNIMIN
AS
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;
- documentar os casos de uso;
- elaborar o diagrama conceitual (diagrama de classe de negócio)
- elaborar os diagramas de seqüência de análise
- implementar o sistema utilizando a linguagem de programação Java;
- utilizar o Desing Patterns J2EE;
- implementar o aplicativo em três camadas de acordo com o modelo MVC;
- 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;
- implementar a camada de integração utilizando DAO – Data Access Object;
- utilizar o Hibernate com annottations para o mapeamento objeto-relacional;
- 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
UNIMIN
AS
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
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. Esse diferencial por si só justifica o desenvolvimento de uma nova
ferramenta, para atender a essa clientela.
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
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
direcionamento de sua elaboração. Assim, os demais seis capítulos abordam os
seguintes temas:
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
UNIMIN
AS
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
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
Nesta parte são apresentadas as conclusões observadas pelo grupo
considerando-se os objetivos que nortearam a realização deste trabalho.
UNIMIN
AS
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
realizado pelos proprietários no momento do estabelecimento do condomínio.
Figura 2 – Fachada do edifício Porto Seguro.
UNIMIN
AS
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
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
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
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
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.
UNIMIN
AS
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.
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).
Assim, modelagem é a concepção de sistemas de informações, antes
que sejam codificados. É, ainda, parte essencial do desenvolvimento de grandes
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
linguagem padrão para a sua execução, a Unified Modeling Language, UML.
3.1. UNIFIED MODELLING LANGUAGE – UML
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
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
UNIMIN
AS
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
que a classe deve implementar.
Os diagramas são representações gráficas que oferecem vários
â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
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
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
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
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
UNIMIN
AS
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.
3.3. REQUISITOS
Os requisitos descrevem de modo claro, sem ambigüidades, conciso e
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
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.
Com o levantamento dos requisitos é possível identificar as classes
que estarão envolvidas no desenvolvimento do software e o reconhecimento dos
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.
UNIMIN
AS
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.
Requisitos não-funcionais
1. Ser compatível com o Windows XP;
2. permitir o acesso via Web;
3. usar a linguagem Java;
4. usar o contêiner web apache;
5. usar banco de dados MySQL
Quadro 1 – Requisitos do sistema.
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,
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
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.
UNIMIN
AS
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
Descrição Para cadastrar o morador de uma unidade é preciso ter registrado a mudança do morador anterior. Assim, somente será cadastrado o morador de uma unidade, quando não houver morador já cadastrado.
Nome Cadastro de proprietário RN - 04
Descrição
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.
Nome Lançamento de contas a pagar RN - 05
Descrição Todas as contas a pagar serão lançadas no sistema.
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.
Nome Cálculo da taxa de condomínio RN – 07
Descrição
O valor da taxa de condomínio de cada unidade é calculado pela 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
Descrição
A taxa de condomínio deverá ser paga até o dia 10 do mês subseqüente. Caso o dia 10 não seja dia útil, a data do pagamento será automaticamente transferida para o próximo dia útil.
UNIMIN
AS
33
Nome Pagamento da taxa de condomínio RN - 09
Descrição
Pagamentos realizados após a data estabelecida serão acrescidos de juros de 2% ao mês e multa de 3%.
Nome Registro de pagamento da taxa de condomínio RN - 10
Descrição
Todos os pagamentos de taxa de condomínio serão registrados no sistema.
Quadro 2 – Regras de Negócio.
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
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
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
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
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.
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.
UNIMIN
AS
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
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
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
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
É responsável pelo registro das operações financeiras do condomínio
mantendo os dados dos pagamentos e dos recebimentos das taxas de condomínio.
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).
UNIMINAS
35
Figura 3 – Diagrama de classes de negócio.
UNIMIN
AS
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.
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.
UNIMIN
AS
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
Sumário Este caso de uso descreverá os procedimentos para realizar o login no sistema
Ator primário: Síndico.
Ator(es) secundário(s): Não há.
Pré-condição: O usuário estar cadastrado.
Pós-condição: O login foi realizado.
Fluxo Principal
1. O síndico inicia sistema.
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
Fluxo Alternativo:
Não há.
Fluxo de Exceção [3]: Dados incorretos
a. O sistema informa que os dados estão incorretos e volta ao item 2.
Regras de Negócio Associadas
RN01
Quadro 3 – Especificação do caso de uso: Fazer Login.
UNIMIN
AS
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.
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
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.
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
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.
UNIMIN
AS
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) .
Quadro 4 – Especificação do caso de uso: Cadastrar Dados.
Nome Cadastrar Dados CSU - 02
Sumário Este caso de uso descreverá os procedimentos realizados para o cadastro dos dados pessoais de proprietários ou moradores e a unidade com a qual manterão relação.
Ator primário: Síndico.
Ator(es) secundário(s): Não há.
Pré-condição: Não haver registro de pessoa na unidade, na condição a ser
registrada.
Pós-condição: O cadastro foi realizado.
Fluxo Principal
1. O síndico solicita o cadastro de dados pessoais.
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
Fluxo Alternativo:
Não há.
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.
Regras de Negócio Associadas RN02, RN03 e RN04
UNIMIN
AS
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).
Figura 6 – Diagrama de sequência do caso de uso: Cadastrar Dados.
As classes de análise envolvidas neste caso de uso e os respectivos
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.
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.
UNIMIN
AS
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
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.
UNIMIN
AS
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
Sumário Este caso de uso descreve os procedimentos realizados para apresentar os dados de todas as pessoas cadastradas.
Ator primário: Síndico.
Ator(es) secundário(s): Não há.
Pré-condição: Ter pessoas cadastradas no sistema.
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.
2. O sistema apresenta o cadastro de pessoas com CPF, nome e o telefone
de cada pessoa.
3. O caso de uso é encerrado.
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.
b. O caso de uso é encerrado
Regras de Negócio Associadas
Quadro 5 – Especificação do caso de uso: Listar Pessoas.
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 7).
UNIMIN
AS
43
Figura 7 – Diagrama de sequência do caso de uso: Listar Pessoas.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o síndico solicita a lista das pessoas cadastradas.
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.
c) Interface de Listar Pessoas: representa a classe de fronteira desse caso de uso,
apresenta a lista das pessoas cadastradas.
d) Pessoa: representa a classe de entidade deste caso de uso. Sua função é
armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
UNIMIN
AS
44
3.6.4. Caso de Uso 04: Consultar Pessoa
Esse caso de uso descreve os procedimentos que serão realizados
para a consulta dos dados de uma pessoa já cadastrada no sistema, como mostra o
quadro 6.
Nome Consultar Pessoa CSU - 04
Sumário Este caso de uso descreve os procedimentos realizados para consultar o cadastro de uma pessoa.
Ator primário: Síndico.
Ator(es) secundário(s): Não há.
Pré-condição: A pessoa estar cadastrada no sistema.
Pós-condição: Os dados da pessoa foram recuperados.
Fluxo Principal
1. O síndico solicita consultar o cadastro de uma pessoa.
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.
5. O caso de uso é encerrado.
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.
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.
c. O caso de uso é encerrado
Regras de Negócio Associadas
RN 02 Quadro 6 – Especificação do caso de uso: Consultar Pessoa.
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 8).
UNIMIN
AS
45
Figura 8 – Diagrama de sequência do caso de uso: Consultar Pessoa.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
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
interface de Consultar Pessoa e a classe de entidade Pessoa. Responde, ainda,
pela validação do CPF.
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
função é armazenar os atributos das pessoas cadastradas, nome; CPF e
telefone.
UNIMIN
AS
46
3.6.5. Caso de Uso 05: Consultar Unidade
Esse caso de uso descreve os procedimentos que serão realizados
para a consulta dos dados de uma unidade, como mostra o quadro 7.
Nome Consultar Unidade CSU - 05
Sumário Este caso de uso descreve os procedimentos realizados para consultar os dados de cadastro de uma unidade.
Ator primário: Síndico.
Ator(es) secundário(s): Não há.
Pré-condição: A unidade estar cadastrada no sistema.
Pós-condição: Os dados da unidade foram recuperados.
Fluxo Principal
1. O síndico solicita a consulta de dados de uma unidade.
2. O sistema solicita o número da unidade.
3. O síndico informa o número.
4. O sistema apresenta o morador e o proprietário da unidade.
5. O caso de uso é encerrado.
Fluxo Alternativo:
Não há.
Fluxo de Exceção:
Não há.
Regras de Negócio Associadas
Quadro 7 – Especificação do caso de uso: Consultar Unidade.
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 9).
UNIMIN
AS
47
Figura 9 – Diagrama de sequência do caso de uso: Consultar Unidade.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o síndico solicita consultar os dados de uma unidade.
b) Controlador de Consultar Unidade: representa a classe de controle deste caso
de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a
interface de Consultar Unidade e as classes de entidades Unidade e Pessoa.
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
UNIMIN
AS
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 é
armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
UNIMIN
AS
49
3.6.6. Caso de Uso 06: Atualizar Histórico
Esse caso de uso descreve os procedimentos que serão realizados
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
Sumário Este caso de uso descreverá os procedimentos realizados para atualizar os dados do histórico de determinada unidade.
Ator primário: Síndico
Ator(es) secundário(s): Não há
Pré-condição: Haver histórico anterior em aberto.
Pós-condição: O histórico foi atualizado.
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
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
Fluxo Alternativo [3A]: Cadastro de venda
a. O síndico informa que é registro de venda do imóvel.
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á.
Regras de Negócio Associadas RN 03 e RN 04
Quadro 8 – Especificação do caso de uso: Atualizar Histórico.
UNIMIN
AS
50
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 10).
Figura 10 – Diagrama de sequência do caso de uso: Atualizar Histórico.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
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
de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a
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
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
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.
e) 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
UNIMIN
AS
51
que é moradora, assim como a pessoa que é proprietária da unidade em
questão.
3.6.7. Caso de Uso 07: Pesquisar Histórico
Esse caso de uso descreve os procedimentos que serão realizados
para pesquisar os dados de histórico de uma unidade, como mostra o quadro 9.
Nome Pesquisar Histórico CSU - 07
Sumário Este caso de uso descreve os procedimentos realizados para pesquisar o histórico de uma dada unidade.
Ator primário: Síndico.
Ator(es) secundário(s): Haver histórico registrado anteriormente.
Pré-condição: Não há.
Pós-condição: A lista com o histórico da unidade é apresentada.
Fluxo Principal
1. O síndico solicita a pesquisa do histórico.
2. O sistema solicita o número da unidade para a pesquisa.
3. O síndico informa o número da unidade.
4. O sistema exibe os dados.
5. O caso de uso é encerrado.
Fluxo Alternativo [4A]: O cadastro está vazio
a. O sistema emite mensagem informando que não há registro de histórico da
unidade.
b. O caso de uso é encerrado.
Fluxo de Exceção:
Não há.
Regras de Negócio Associadas
Quadro 9 – Especificação do caso de uso: Pesquisar Histórico.
UNIMIN
AS
52
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 11).
Figura 11 – Diagrama de sequência do caso de uso: Pesquisar Histórico.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
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
de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a
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
uso. Disponibiliza ao síndico o formulário para que informe qual unidade
deverá ter o histórico pesquisado.
d) Histórico: 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
que é moradora, assim como a pessoa que é proprietária da unidade em
questão.
UNIMIN
AS
53
3.6.8. Caso de Uso 08: Registrar Conta a Pagar
Esse caso de uso descreve os procedimentos que serão realizados
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
Sumário Este caso de uso apresenta os passos para o registro das contas a pagar.
Ator primário: Síndico.
Ator(es) secundário(s): Não há.
Pré-condição: Não há.
Pós-condição: A conta foi registrada.
Fluxo Principal
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.
4. O sistema solicita os dados da conta.
5. O sistema registra as informações no banco de dados.
6. O caso de uso é encerrado.
Fluxo Alternativo:
Não há.
Fluxo de Exceção:
Não há.
Regras de Negócio Associadas
RN 05 Quadro 10 – Especificação do caso de uso: Registrar Conta a Pagar.
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 12).
UNIMIN
AS
54
Figura 12 – Diagrama de sequência do caso de uso: Registrar Contas a Pagar.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o síndico solicita registrar uma conta que deverá ser paga
posteriormente.
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
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.
UNIMIN
AS
55
3.6.9. Caso de Uso 09: Registrar Pagamento de Contas
Esse caso de uso descreve os procedimentos que serão realizados
para registrar o pagamento de contas, como mostra o quadro 11.
Nome Registrar Pagamento de Contas CSU - 09
Sumário Este caso de uso apresenta os procedimentos para o registro dos pagamentos realizados pelo condomínio.
Ator primário: Síndico.
Ator(es) secundário(s): não há.
Pré-condição: A conta a pagar ter sido cadastrada anteriormente.
Pós-condição: O pagamento da conta foi registrado.
Fluxo Principal
1. O síndico solicita o registro do pagamento de contas.
2. O sistema apresenta as contas já cadastradas.
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.
6. O sistema registra as informações.
7. O sistema encerra o caso de uso.
Fluxo Alternativo:
Não há.
Fluxo de Exceção [2]: Não há conta cadastrada.
a) O sistema informa que não há conta cadastrada.
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.
Regras de Negócio Associadas
RN 05 Quadro 11 – Especificação do caso de uso: Registrar Pagamento de Contas.
UNIMIN
AS
56
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 13).
Figura 13 – Diagrama de sequência do caso de uso: Registrar pagamento de Contas.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o síndico solicita registrar o pagamento de uma conta.
b) Controlador de Registrar Pagamento de Contas: representa a classe de
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.
UNIMIN
AS
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
vencimento, a descrição e o valor da conta e também, o mês de referência.
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.
UNIMIN
AS
58
3.6.10. Caso de Uso 10: Gerar Taxa de Condomínio
Esse caso de uso descreve os procedimentos que serão realizados
para registrar o pagamento de contas, como mostra o quadro 12.
Nome Gerar Taxa de Condomínio CSU - 10
Sumário Este caso de uso descreve as etapas para gerar as taxas mensais de condomínio. Ator primário: Síndico.
Ator(es) secundário(s): Não há.
Pré-condição: Haver contas a pagar cadastradas anteriormente.
Pós-condição: O valor da taxa ter sido calculado.
Fluxo Principal 1. O síndico solicita a geração da taxa mensal de condomínio.
2. O sistema solicita o período de referência da taxa a ser gerada.
3. O síndico informa o período.
4. O sistema gera e apresenta a taxa de condomínio do período solicitado.
5. O caso de uso é encerrado.
Fluxo Alternativo:
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.
Regras de Negócio Associadas
RN05, RN06 e RN 07
Quadro 12 – Especificação do caso de uso: Gerar Taxa de Condomínio.
UNIMIN
AS
59
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 14).
Figura 14 – Diagrama de sequência do caso de uso: Gerar Taxa de Condomínio.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o usuário solicita a geração da taxa de condomínio de um
determinado mês.
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.
UNIMIN
AS
60
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
vencimento, a descrição e o valor da conta e também, o mês de referência.
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.
UNIMIN
AS
61
3.6.11. Caso de Uso 11: Receber Taxa de Condomínio
Esse caso de uso descreve os procedimentos que serão realizados
para registrar o pagamento de contas, como mostra o quadro 13.
Nome Receber Taxa de Condomínio CSU - 11
Sumário Este caso de uso descreve as etapas para realizar o registro do recebimento de taxas do condomínio. Ator primário: Síndico
Ator(es) secundário(s): Não há
Pré-condição: O valor da taxa ter sido calculado anteriormente.
Pós-condição: O pagamento da taxa é registrado.
Fluxo Principal
1. O síndico solicita o registro de pagamento da taxa.
2. O sistema solicita os dados para registrar o recebimento da taxa de
condomínio.
3. O síndico informa os dados.
4. O sistema solicita a confirmação.
5. O síndico confirma os dados.
6. O sistema apresenta o recibo.
7. O caso de uso é encerrado.
Fluxo de Alternativo [3]: O pagamento está sendo realizado fora do prazo
a. O sistema calcula e apresenta os juros e a multa.
Fluxo de Exceção [3]: A taxa não foi gerada.
a. O sistema informa que a taxa não foi gerada e encerra o caso de uso.
Regras de Negócio Associadas
RN 08, RN09 e RN 10
Quadro 13 – Especificação do caso de uso: Receber Taxa de Condomínio.
UNIMIN
AS
62
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 15).
Figura 15 – Diagrama de sequência do caso de uso: Receber Taxa de Condomínio.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
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
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.
UNIMIN
AS
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
caso de uso. Sua função é armazenar os atributos dos lançamentos financeiros,
data, tipo, descrição, juros, multa e valor final.
f) 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
que é moradora, assim como a pessoa que é proprietária da unidade em
questão.
g) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é
armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
UNIMIN
AS
64
3.6.12. Caso de Uso 12: Gerar Recibo
Esse caso de uso descreve os procedimentos que serão realizados
para registrar o pagamento de contas, como mostra o quadro 14.
Nome Gerar Recibo CSU - 12
Sumário Este caso de uso descreve as etapas para gerar o recibo de pagamento da taxa de condomínio.
Ator primário: Síndico
Ator(es) secundário(s): Não há
Pré-condição: A taxa ter sido paga.
Pós-condição: O recibo foi gerado.
Fluxo Principal
1. O síndico solicita a geração de recibo.
2. O sistema solicita os dados para a geração do recibo.
3. O síndico informa os dados.
4. O sistema solicita confirmação.
5. O síndico confirma os dados.
6. O sistema gera o recibo.
7. O caso de uso é encerrado.
Fluxo de Alternativo:
Não há.
Fluxo de Exceção: Não há registro de pagamento da taxa.
a. O sistema informa que não há pagamento da taxa.
b. O caso de uso é encerrado.
Regras de Negócio Associadas
Quadro 14 – Especificação do caso de uso: Gerar Recibo.
UNIMIN
AS
65
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 16).
Figura 16 – Diagrama de sequência do caso de uso: Gerar Recibo.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o síndico solicita a geração de recibo.
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
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.
d) Histórico: 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
UNIMIN
AS
66
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 é
armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
f) Lançamento Mês: corresponde a uma das classes 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.
UNIMIN
AS
67
3.6.13. Caso de Uso 13: Gerar Balancete
Esse caso de uso descreve os procedimentos que serão realizados
para registrar o pagamento de contas, como mostra o quadro 15.
Nome Gerar Balancete CSU - 13
Sumário Este caso de uso descreve as etapas para gerar o balancete de determinado período.
Ator primário: Síndico
Ator(es) secundário(s): Não há
Pré-condição: Haver registro de movimento no período solicitado.
Pós-condição: O balancete foi gerado.
Fluxo Principal
1. O síndico solicita a geração de balancete.
2. O sistema solicita os dados para a geração do balancete.
3. O síndico informa os dados.
4. O sistema solicita confirmação.
5. O síndico confirma os dados.
6. O sistema gera o balancete.
7. O caso de uso é encerrado.
Fluxo de Alternativo:
Não há.
Fluxo de Exceção: Não há registro de movimentação financeira no período
a. O sistema informa que não há movimentação financeira no período.
b. O caso de uso é encerrado.
Regras de Negócio Associadas
RN 08, RN09 e RN 10
Quadro 15 – Especificação do caso de uso: Gerar Balancete.
UNIMIN
AS
68
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 17).
Figura 17 – Diagrama de sequência do caso de uso: Gerar Balancete.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o síndico solicita a geração de balancete.
b) Controlador de Gerar Balancete: representa a classe de controle deste caso de
uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a
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.
UNIMIN
AS
69
d) Lançamento Mês: corresponde a uma das classes 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.
e) 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
vencimento, a descrição e o valor da conta e também, o mês de referência.
UNIMIN
AS
70
3.6.14. Caso de Uso 14: Gerar Histórico
Esse caso de uso descreve os procedimentos que serão realizados
para registrar o pagamento de contas, como mostra o quadro 16.
Nome Gerar Histórico CSU - 14
Sumário Este caso de uso descreve as etapas para gerar o histórico de determinada unidade. Ator primário: Síndico
Ator(es) secundário(s): Não há
Pré-condição: Haver histórico cadastrado anteriormente.
Pós-condição: O Histórico foi gerado.
Fluxo Principal
1. O síndico solicita a geração de histórico.
2. O sistema solicita os dados para a geração do histórico.
3. O síndico informa os dados.
4. O sistema solicita confirmação.
5. O síndico confirma os dados.
6. O sistema gera o histórico.
7. O caso de uso é encerrado.
Fluxo de Alternativo:
Não há.
Fluxo de Exceção: Não há registro de histórico para a unidade
a. O sistema informa que não há histórico para a unidade.
b. O caso de uso é encerrado.
Regras de Negócio Associadas
Quadro 16 – Especificação do caso de uso: Gerar Histórico.
UNIMIN
AS
71
O diagrama deste caso de uso exibe o fluxo de interação,
apresentando a sequência das mensagens para a sua execução (Figura 18).
Figura 18 – Diagrama de sequência do caso de uso: Gerar Balancete.
As classes de análise envolvidas neste caso de uso e os respectivos
papéis são:
a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.
No caso, o síndico solicita a geração de histórico.
b) Controlador de Gerar Histórico: representa a classe de controle deste caso de
uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a
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
UNIMIN
AS
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
função é armazenar os atributos das pessoas cadastradas, nome; CPF e
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
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
das classes de projeto e dos diagramas de sequência gerados a partir da interação
entre as classes.
Desta forma, após definidos os requisitos; os casos de uso;
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
projeto as seguintes classes:
− UsuarioEntidade;
− HibernateUtil;
− LoginBO;
− LoginCO;
− LoginDAO;
− Login2;
− PessoaBO;
− PessoaDAO;
− PessoaHibernateDAO;
− UnidadeBO;
− UnidadeDAO;
− UnidadeHibernateDAO;
− HistoricoBO;
− HistoricoDAO.
− HistoricoHibernateDAO;
− CadastrarPessoaAction e
− PesquisarAction.
A documentação apresentada a seguir foi gerada por engenharia
reversa se utilizando a ferramenta MDG que integra o Eclipse ao Enterprise Architect.
UNIMIN
AS
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.
Figura 19 – Classes do pacote entidades.
UNIMIN
AS
74
No pacote bo se concentraram as seguintes classes: LoginBO;
PessoaBO; UnidadeBO e HistoricoBO (Figura 20).
Figura 20 – Classes do pacote bo.
As classes de persistência, aquelas com terminação “DAO” e, ainda, a
classe HibernateUtil, estão presentes no pacote DAO, como representado pela
figura 21.
Figura 21 – Classes do pacote persistência.
UNIMIN
AS
75
E finalmente, as classes Login2; CadastrarPessoaAction e
PesquisarAction estão localizadas em um mesmo pacote como apresentado na
figura 22.
Figura 22 – Classes do pacote action.
UNIMIN
AS
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.
UNIMINAS
77
Figura 23 – Diagrama de sequência com as classes de projeto do caso de uso: Fazer Login.
UNIMIN
AS
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.
UNIMINAS
79
Figura 24 – Diagrama de sequência com as classes de projeto do caso de uso: Cadastrar Dados.
UNIMIN
AS
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.
UNIMINAS
81
Figura 25 – Diagrama de sequência com as classes de projeto do caso de uso: Listar Pessoas.
UNIMIN
AS
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.
UNIMINAS
83
Figura 26 – Diagrama de sequência com as classes de projeto do caso de uso: Consultar Pessoa.
UNIMIN
AS
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).
UNIMINAS
85
Figura 27 – Diagrama de sequência com as classes de projeto do caso de uso: Consultar Unidade.
UNIMIN
AS
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).
UNIMINAS
87
Figura 28 – Diagrama de sequência com as classes de projeto do caso de uso: Atualizar Histórico.
UNIMIN
AS
88
4. ARQUITETURA E CÓDIGO
Orlando Alves de Oliveira
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
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
de apresentação, negócios e integração.
A arquitetura de software é a maneira como está estruturado o sistema,
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,
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
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
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.
UNIMIN
AS
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 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
O aumento do uso de aplicações distribuídas provê mudanças nos
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.
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 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.
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);
UNIMIN
AS
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:
Figura 29 – Modelo Arquitetura MVC.
4.3. PADRÕES DE PROJETO
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
UNIMIN
AS
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.
4.3.1. DAO
O DAO é utilizado para persistência de objetos Java fazendo com que
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
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
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.
(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
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
UNIMIN
AS
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() {
return dao.getAllPessoas();}
public void deletePessoa(String string) {
dao.delete(string);}
public Pessoa getPessoa(String string) {
return dao.getPessoa(string); }
public void insertPessoa(Pessoa pes) {
dao.insert(pes);}
}
Figura 30 – Classe PessoaBO.
Na classe pessoaBO é criado um objeto do tipo PessoaDAO e a partir
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
comportamentos comuns a toda aplicação, descritos nos métodos da classe
PessoaBO.
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.
UNIMIN
AS
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
atendimento de uma solicitação e o gerenciamento de visualização, cuja função é
localizar e distribuir a visualização solicitada.
Tanto o padrão Front Controller como o Application Controller são
implementados pelo framework Struts.
4.4. TECNOLOGIAS UTILIZADAS
4.4.1. Servlet
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().
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 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.
UNIMIN
AS
94
Figura 31 – Ciclo de vida do servlet. Adaptado de Angoti (2009a).
4.4.2. Páginas JSP
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
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
das tags que representam instruções Java.
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">
UNIMIN
AS
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:if>
<s:form action="consultarPessoa">
<table align="center" class="borderAll">
<tr>
<td class="tdLabel"><s:text name="label.P_cpf" /></td>
<td><s:textfield name="cpf" size="11" /></td>
</tr>
</table>
<br />
<table>
<tr>
<td><s:submit action="consultarPessoa"
key="button.label.submit2" cssClass="butStnd" /></td>
<td><s:reset key="button.label.cancel" cssClass="butStnd" /></td>
<tr>
</table>
</s:form></center>
</body>
</html>
Figura 32 – Código da página consultarPessoaForm.jsp.
Assim, a execução da função consultar pessoa que foi apresentado
anteriormente, terá como resultado a exibição na tela do browser da página
pesquisarPessoa.jsp (Figura 33).
UNIMIN
AS
96
Figura 33 – Página pesquisarPessoa.jsp
4.4.3. JDBC
Java Database Conectivity (JDBC) é uma API da linguagem Java que
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á
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
com o banco de dados através do DAO (Data Access Object).
4.5. J2EE
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).
UNIMIN
AS
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)
Na camada de apresentação encontra-se a lógica de apresentação dos
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
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
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.
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
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:
UNIMIN
AS
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
desenvolvido entre o ano de 2000 e 2001 onde mais de 30 desenvolvedores
contribuíram para a sua criação (DUMOULIN, FRANCISCUS, WINTERFELDT,
2004).
O Struts é responsável por implementar o Front Controller que faz a
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
apresentação.
Figura 35 – Front Controller Adaptado de Angoti (2009b)
UNIMIN
AS
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
apresenta um trecho do código desse arquivo.
<!DOCTYPE struts PUBLIC "-//Apache Software
Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">
<struts>
<package name="default" extends="struts-default">
<!-- mapeamento das ações -->
...
<action name="consultarUnidade" method="consultaUnidade"
class="br.uniminas.action.PesquisarAction">
<result name="success">/page/unidade.jsp</result>
<result name="erro">/page/erro.jsp</result>
</action>
...
</package>
</struts>
Figura 36 – Arquivo struts.xml.
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).
UNIMIN
AS
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
acordo com a solicitação feita pelo usuário.
4.7.2. Diagrama de Pacotes
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
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
do sistema desenvolvido. A figura 38 mostra todos os pacotes que foram criados no
sistema.
Figura 38 – Diagrama de pacotes.
UNIMIN
AS
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).
Figura 39 – Classes do pacote entidades.
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).
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
UNIMIN
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)
Figura 41 – Classes do pacote persistência.
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).
Figura 42 – Classes do pacote action.
UNIMIN
AS
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
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
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.
Figura 43 – Página Principal.
UNIMIN
AS
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
CadastrarPessoaAction do pacote action, como apresentado no trecho de código
abaixo (Figura 45).
public class CadastrarPessoaAction {
... public String setUpForInsertOrUpdate() {
prep();
return "success";
}
...
Figura 45 – Método setUpForInsertOrUpdate() implementado na classe CadastrarPessoaAction.
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.
Figura 46 – Tela de Cadastro de Dados.
UNIMIN
AS
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"
class="br.uniminas.action.CadastrarPessoaAction">
<result name="success">/page/sucesso.jsp</result>
<result name="erro">/page/erro.jsp</result>
</action>
Figura 47 – Action InsertOrUpdate implementado no arquivo struts.xml.
O método insertOrUpdate() está na classe CadastrarPessoaAction que
é 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
código do método insertOrUpdate(), como mostra a figura 48.
public class CadastrarPessoaAction { ... public String insertOrUpdate() { if (!validationSuccessful()) {
return "erro";
} else {
if (prop != null && prop.equals("aquisicao")) { gravaPropAquisicao();
}
if (prop != null && prop.equals("venda")) {
if (!validaDataVenProp()){
return "erro";}
else{
gravaProVenda();} }
if (mor != null && mor.equals("entrada")) {
if (jaMorador()==true){
return "erro";
}
if(jaMorador()==false){
gravaMorEnt();
}
}
if (mor != null && mor.equals("saida")) { if (!validaDataSaiMor())
return "erro";
else
gravaMorSai();
}
return "success";
}
} ...
Figura 48 – Método InsertOrUpdate implementado na classe CadastrarPessoaAction.
UNIMIN
AS
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
é 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
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
nulo nesse objeto (Figura 49).
public class CadastrarPessoaAction {
... 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.
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.
UNIMIN
AS
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
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).
public class CadastrarPessoaAction{
...
public void gravaPropAquisicao{
...
if (pesAux == null && unidade.getProprietario() == null) {
// grava pessoa
pesService.insertPessoa(pessoa);
...
Figura 51 – Comando de persistência declarado no método gravaPropAquisicao() implementado na classe CadastrarPessoaAction.
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).
public class PessoaBO {
private PessoaDAO dao;
public PessoaBO() {
this.dao = new PessoaHibernateDAO();
}
...
Figura 52 – Comando geração do objeto pessoaDAO declarado no construtor da classe PessoaBO.
UNIMIN
AS
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 class PessoaBO {
...
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.
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 {
...
public void insert(Pessoa pes) {
session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try {
tx = session.beginTransaction();
session.save(pes);
tx.commit();
} catch (RuntimeException e) {
if (tx != null)
tx.rollback();
throw e;
} finally {
// session.close();
}
}
...
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
UNIMIN
AS
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).
public class CadastrarPessoaAction{
...
public void gravaPropAquisicao{
...
// atualiza unidade
unidade.setProprietario(pessoa);
uniService.updateUnidade(unidade);
...
Figura 55 – Comandos do método gravaPropAquisicao() implementado pela classe CadastrarPessoaAction.
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.
public class UnidadeBO {
private UnidadeDAO dao;
public UnidadeBO() {
this.dao = new UnidadeHibernateDAO();
}
...
Figura 56 – Comandos de criação do objeto UnidadeHibernateDAO declarado no construtor da classe UnidadeBO.
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.
public class UnidadeBO{
...
public void updateUnidade(Unidade u){
dao.updateUnidade(u);
}
...
Figura 57 – Comandos do método updateUnidade() implementado pela classe UnidadeBO.
UNIMIN
AS
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) {
session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try {
tx = session.beginTransaction();
session.update(u);
tx.commit();
} catch (RuntimeException e) {
if (tx != null)
tx.rollback();
throw e;
} finally {
}
}
...
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
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
updateHistorico()., como ilustrado pela figura 59.
public class CadastrarPessoaAction{
...
public void gravaPropAquisicao{
...
// 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());
UNIMIN
AS
111
historico.setProprietario(unidade.getProprietario());
histService.updateHistorico(historico);
}
...
Figura 59 – Comando de persistência declarado no método gravaPropAquisicao() 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.
public class HistoricoBO {
private HistoricoDAO dao;
public HistoricoBO() {
this.dao = new HistoricoHibernateDAO();
}
...
Figura 60 – Comandos de criação do objeto HistoricoHibernateDAO declarado no construtor 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
61).
public class HistoricoBO{
...
public void updateHistorico(Historico hist){
dao.updateHistorico(hist);
}
...
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).
UNIMIN
AS
112
public class HistoricoHibernatedDAO {
...
public void updateHistorico(Historico hist) {
session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try {
tx = session.beginTransaction();
session.update(hist);
tx.commit();
} catch (RuntimeException e) {
if (tx != null)
tx.rollback();
throw e;
} finally {
}
}
...
Figura 62 – Código do método updateHistorico() implementado pela classe HistoricoHibernateDAO.
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
método insertHistorico(), como mostra a figura 63.
public class CadastrarPessoaAction{
...
public void gravaPropAquisicao{
...
// 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);
}
...
Figura 63 – Comando de persistência declarado no método gravaPropAquisicao() implementado na classe CadastrarPessoaAction, quando não há histórico da unidade.
UNIMIN
AS
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
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).
public class HistoricoHibernatedDAO {
...
public void insert(Historico his) {
session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try {
tx = session.beginTransaction();
session.save(his);
tx.commit();
} catch (RuntimeException e) {
if (tx != null)
tx.rollback();
throw e;
} finally {
// session.close();
}
}
...
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.
UNIMIN
AS
114
public class CadastrarPessoaAction{
...
public void gravaPropAquisicao{
...
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.
public class CadastrarPessoaAction{
...
public String insertOrUpdate() {
...
if (prop != null && prop.equals("aquisicao")) {
gravaPropAquisicao();
}
...
return "success";
}
}
...
Figura 67 – Código do método isertOrUpdate() implementado na classe CadastrarPessoaAction.
O retorno da String success está mapeado no arquivo struts.xml para
exibir uma página JSP, como mostra a figura 68.
...
<action name="insertOrUpdate" method="insertOrUpdate"
...
<result name="success">/page/sucesso.jsp</result>
...
</action>
...
Figura 68 – Action insertOrUpdate mapeada no arquivo struts.xml.
UNIMIN
AS
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().
Figura 69 – Tela de confirmação de cadastro.
É 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
inserção ou atualização do histórico daquela unidade.
UNIMIN
AS
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-
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
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
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
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
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,
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.
UNIMIN
AS
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
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
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”
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.
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
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
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.
UNIMIN
AS
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
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,
sendo adequada para indicar a janela. Como cor de texto requer fundo preto ou azul
escuro.
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
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
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
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.
UNIMIN
AS
119
Cor Positivas Negativas
Neve Paz Frio Palidez fúnebre
Pureza Leveza Hospital Rendição Branco
Inocência Limpeza Vulnerabilidade Esterilidade
Noite Estabilidade Medo Segredos
Carvão Formalidade Vazio Anonimato Preto
Poder Solidez Morte maldição
Vitória Força Sangue Perigo
Paixão Energia Guerra Raiva Vermelho
Amor Sexualidade Fogo Satã
Sol Ouro Covardia Risco
Verão Colheita Traição Doença Amarelo
Serenidade Inovação Ciúmes Loucura
Vegetação Fertilidade Decadência Ganância
Natureza Esperança Inexperiência Fuga à realidade Verde
Primavera Segurança Inveja Má Sorte
Céu Estabilidade Frio Obscenidade
Mar Paz Depressão Mistério Azul
Espiritualidade Unidade Melancolia Conservadorismo
Quadro 17 – Simbologia de cores.
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
possíveis na interação do usuário com o sistema
A seguir, a figura 70 apresenta o diagrama de navegabilidade do
sistema.
UNIMINAS
120
Figura 70 – Diagrama de Navegabilidade.
UNIMIN
AS
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 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
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
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
idêntica nas demais páginas.
A seguir será simulado os comportamento do sistema, com a
nevegação entre as telas de interface
UNIMIN
AS
122
Figura 71 – Tela de Login.
Figura 72 – Tela de mensagem de erro no Login.
UNIMIN
AS
123
Figura 73 – Menu inicial.
Figura 74 – Tela de Cadastro de Dados.
UNIMIN
AS
124
Figura 75 – Tela com mensagem de erro de CPF.
Figura 76 – Tela com mensagem de erro, CPF cadastrado como morador em outra unidade.
UNIMIN
AS
125
Figura 77 – Tela com mensagem de sucesso ao cadastrar os dados.
Figura 78 – Tela que apresenta a lista das pessoas cadastradas.
UNIMIN
AS
126
Figura 79 – Tela para solicitar a pesquisa dos dados de uma pessoa.
Figura 80 – Tela que apresenta os dados da pessoa pesquisada.
UNIMIN
AS
127
Figura 81 – Tela para solicitar a pesquisa dos dados de uma unidade.
Figura 82 – Tela que apresenta os dados da unidade pesquisada.
UNIMIN
AS
128
6. PERSISTÊNCIA DE DADOS
Marco Aurélio Silva Rodrigues
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
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
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
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
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
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.
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.
UNIMIN
AS
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).
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”.
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
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;
• Exclusão de dados;
• Alteração de dados;
• Remoção de dados;
Segundo Date (2005, p. 10) “um banco de dados é uma coleção de
dados persistentes, usado pelos sistemas de aplicações de uma determinada
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
UNIMIN
AS
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):
• Armazenamento, organização e obtenção de dados estruturados.
• Compartilhamento dos dados.
• Redução de redundância.
• Inconsistência pode ser evitada.
• Fornecimento de suporte a transação.
• Manutenção da Integridade.
• Reforço da segurança.
• Requisitos contraditórios podem ser equilibrados.
• Imposição de padrões.
A figura 83 apresenta esquematicamente, a relação entre usuários,
aplicativo, SGBD e o banco de dados.
UNIMIN
AS
131
Figura 83 – Sistema simplificado de Banco de Dados. Adaptado de RICARTE. I. L. M (1998, p.2).
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
objeto. As linguagens de programação têm uma estrutura de dados complexa, como
as definições de classes em Java.
6.2. MYSQL
O MySQL é um SGBD (Sistema de Gerenciamento de Banco de
Dados), que utiliza a linguagem SQL (Structured Query Language) como interface.
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.
UNIMIN
AS
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.
� Fornece mecanismos de armazenamento transacional e não
transacional.
� É relativamente fácil se adicionar outro mecanismo de
armazenamento.
� Um sistema de alocação de memória muito rápido e baseado em
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.
� 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.
� 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
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.
UNIMIN
AS
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.
� Você pode misturar tabelas de bancos de dados diferentes na mesma
pesquisa.
• Segurança
� Um sistema de privilégios e senhas que é muito flexível, seguro e que
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
• 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
clientes podem se conectar usando named pipes. No sistema Unix, os
clientes podem se conectar usando arquivos sockets.
� 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).
UNIMIN
AS
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
(Wikipédia, 2009b).
6.3.1. Modelos
Um modelo de dados é uma definição abstrata, autônoma e lógica dos
objetos, operadores e outros elementos.
De acordo com a abordagem que utilizada e conforme ilustrado pela
figura 84, os modelos de dados normalmente são classificados da seguinte forma:
Figura 84 – Arquitetura de Modelo de Banco de Dados. Adaptado de RICARTE. I. L. M (1998; p.10).
UNIMIN
AS
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).
• Modelo Lógico:
o Regras de Derivação:
� Normalização das estruturas de dados
� Derivação de estruturas de agregação e generalização-
especialização
� Derivação de relacionamentos
o Regras de Restrição:
� Restrição de domínio
� 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.
UNIMIN
AS
136
Figura 85 – Modelo Lógico de Banco de Dados.
• Modelo Físico:
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.
UNIMIN
AS
137
Figura 86 – Modelo Físico de Banco de Dados.
O modelo para o sistema foi implementado atendendo as regras
abaixo:
• Normalização, evitando assim os problemas que podem provocar falhas no
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
• 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.
UNIMIN
AS
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:
− 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;
− 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;
− 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
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.
As tabelas, entidades, relacionam-se umas as outras através de
chaves. Uma chave é um conjunto de um ou mais atributos que determinam a
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á.
UNIMIN
AS
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.
A entidade TaxaCondominio é composta pelos seguintes atributos:
TC_mesRef (PK), CM_id (FK), TC_valorTaxa, TC_dataGeracao,
TC_dataVencimento. A entidade 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
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,
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
(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,
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.
UNIMIN
AS
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).
A figura 87 apresenta a estrutura do padrão DAO. A classe
DataAccessObject encapsula o acesso aos dados, que por sua vez é mantido pela
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
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
campos de um registro.
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.
UNIMIN
AS
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
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
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
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
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
classes e seus objetos, ou seja, a aplicação nunca terá acesso diretamente ao
nosso banco (LEMES, 2007).
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
UNIMIN
AS
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
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.
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
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;
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
garantindo que possa se conectar com banco de dados legados de forma
transparente.
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).
UNIMIN
AS
143
Figura 88 – Arquitetura Hibernate. Adaptado de Hibernate (2009).
• 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
seus campos às colunas.
• Persistence Object: classe derivada da classe mapeada da aplicação, que
contém os métodos para acesso ao SGBD.
6.5.3. Mapeamento Objeto Relacional
De acordo com Bauer e King (2005, p. 31-32):
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.
UNIMIN
AS
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
transacionais a fim de executar a verificação suja, buscas de associação
ociosas e outras funções de otimização.
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”.
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
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
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
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.
UNIMIN
AS
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
definem o mapeamento das classes que vão gerar os objetos para serem
persistidos. Todas essas informações ficam dentro da tag <Hibernate-configuration>.
Dentre os principais parâmetros destacamos:
• property name="hibernate.connection.url" é utilizado para informar os
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
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
usuário do SGBD.
• property name="hibernate.connection.password" informa qual a senha de
conexão do SGBD.
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>
UNIMIN
AS
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>
<!-- mapeamento das entidades -->
<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>
Figura 89 - Arquivo "hibernate.cfg.xml".
Para o sistema desenvolvido, foi implementada uma classe estática
chamada de "HibernateUtil" (figura 90). A função dessa classe é encapsular a
criação e recuperação de sessões.
...
public class HibernateUtil {
private static final SessionFactory sessionFactory;
static {
try {
// Create the SessionFactory from hibernate.cfg.xml
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);
}
}
public static SessionFactory getSessionFactory() {
return sessionFactory;}
}
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.
UNIMIN
AS
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.
...
public class HistoricoHibernateDAO implements HistoricoDAO {
private Historico hist;
private List<Historico> histList;
private Session session = HibernateUtil.getSessionFactory()
.getCurrentSession();
public Historico getHistorico(int i) {
session = HibernateUtil.getSessionFactory().openSession();
try {
session.beginTransaction();
Query q = session.createQuery("from Historico where id=:Id_Historico");
q.setInteger("Id_Historico", i);
return (Historico) q.uniqueResult();
} finally {
// session.close();
}
}
public List consultaHistorico(String numero){
session = HibernateUtil.getSessionFactory().openSession();
try {
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) {
session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try { tx = session.beginTransaction();
UNIMIN
AS
148
session.save(his);
tx.commit();
} catch (RuntimeException e) {
if (tx != null)
tx.rollback();
throw e;
} finally {
// session.close();
}
}
public void delete(String id) {
session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try { tx = session.beginTransaction();
hist = (Historico) session.get(Historico.class, id);
session.delete(hist);
tx.commit();
} catch (RuntimeException e) {
if (tx != null)
tx.rollback();
throw e;
} finally {
}
}
public void updateHistorico(Historico hist) {
session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try { tx = session.beginTransaction();
session.update(hist);
tx.commit();
} catch (RuntimeException e) {
if (tx != null)
tx.rollback();
throw e;
} finally {
}
}
}
Figura 91 – Classe de persistência HistoricoHibernateDAO.
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
UNIMIN
AS
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.
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.
...
@Entity
@Table(name = "historico")
public class Historico {
//@GeneratedValue(strategy=GenerationType.AUTO)
@Id
@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;
@Column(name = "H_morEntrada", unique = true)
Date h_morEntrada;
@Column(name = "H_morSaida", unique = true)
Date h_morSaida;
@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;
UNIMIN
AS
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.
@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.
@Id: declara qual campo, atributo da classe será usado como identificador. Neste
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
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
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
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.
UNIMIN
AS
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
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
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
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
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
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
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
UNIMIN
AS
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).
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
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
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
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
um sistema cuja manutenibilidade será bastante facilitada.
Ressalta-se, ainda que o Hibernate não somente fornece uma solução
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á
UNIMIN
AS
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.
UNIMIN
AS
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. 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. ANGOTI JR., Edson. Padrões de Projeto JEE. Disponível em:<http://si.uniminas.br/~angoti/arquivos/PadroesProjetoJEE.pdf> Acesso em: 09 jun. 2009b. _______ Edson. Apache Tomcat. Disponível em :<http://si.uniminas.br/~angoti/arquivos/Tomcat.pdf> Acesso em: 16 jun. 2009c. 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 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-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/anafernanda.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.
UNIMIN
AS
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. 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. DEBONI, José Eduardo Zindel. Modelagem orientada a objetos com a UML. São Paulo: Futura, 2003. 219 p. 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 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 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. 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
UNIMIN
AS
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>. Acesso em: 27 mai. 2009. 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. 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. MYSQL. The world's most popular open source. Disponível em: <http://www.mysql.com>. Acesso em: 15 abr. 2009. 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_2007_vol_1.pdf>. Acesso em: 7 mar 2009. 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. 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. 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>. Acesso em: 10 mai. 2009.
UNIMIN
AS
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. WAZLAWICK, Raul Sidney. Análise e projetos de sistema orientados a objetos. 2. Ed. Rio de Janeiro: Elsevier, 2004. 295 p. 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. _______. 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 <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. 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.
UNIMIN
AS
158
APÊNDICE
Código do arquivo struts.xml
<!DOCTYPE struts (View Source for full doctype...)>
<struts>
<package name="default" extends="struts-default">
- <!-- mapeamento das ações
-->
<action name="login" method="execute" class="br.uniminas.action.Login2">
<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>
</action>
<action name="getAllPessoas" method="getAllPessoas" class="br.uniminas.action.CadastrarPessoaAction">
<result name="success">/page/pessoas.jsp</result>
</action>
<action name="getPessoa" method="getPessoa" class="br.uniminas.action.PesquisarAction">
<result name="success">/page/pessoa.jsp</result>
</action>
<action name="setUpForInsertOrUpdate" method="setUpForInsertOrUpdate" class="br.uniminas.action.CadastrarPessoaAction">
<result name="success">/page/cadastroPessoaForm.jsp</result>
</action>
<action name="insertOrUpdate" method="insertOrUpdate" class="br.uniminas.action.CadastrarPessoaAction">
<result name="success">/page/sucesso.jsp</result>
<result name="erro">/page/erro.jsp</result>
</action>
<action name="setUpForInsertOrUpdate2" method="setUpForInsertOrUpdate2" class="br.uniminas.action.PesquisarAction">
<result name="success">/page/consultaPessoaForm.jsp</result>
</action>
<action name="setUpForInsertOrUpdate3" method="setUpForInsertOrUpdate3" class="br.uniminas.action.PesquisarAction">
<result name="success">/page/consultaUnidadeForm.jsp</result>
</action>
UNIMIN
AS
159
<action name="setUpForInsertOrUpdate4" method="setUpForInsertOrUpdate3" class="br.uniminas.action.PesquisarAction">
<result name="success">/page/consultaHistorico.jsp</result>
</action>
<action name="consultarPessoa" method="consultaPessoa" class="br.uniminas.action.PesquisarAction">
<result name="success">/page/pessoa.jsp</result>
<result name="erro">/page/erro.jsp</result>
</action>
<action name="consultarUnidade" method="consultaUnidade" class="br.uniminas.action.PesquisarAction">
<result name="success">/page/unidade.jsp</result>
<result name="erro">/page/erro.jsp</result>
</action>
<action name="consultarHistorico" method="consultaHistorico" class="br.uniminas.action.PesquisarAction">
<result name="success">/page/historico.jsp</result>
<result name="erro">/page/erro.jsp</result>
</action>
<action name="delete" method="deletePessoa" class="br.uniminas.action.CadastrarPessoaAction">
<result name="success" type="redirect-action">getAllPessoas</result>
<result name="erro">/page/erro.jsp</result>
</action>
</package>
</struts>