Gestao de Condominio

UNIO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CINCIAS APLICADAS DE MINAS Autorizada pela Portaria n 577/2000 MEC,
, de 03/05/2000
BACHARELADO EM SISTEMAS DE INFORMAO
Marco Aurlio Silva Rodrigues Maria Margaret de Vasconcellos Lemos Orlando Alves de Oliveira
SISTEMA PARA GESTO DE CONDOMNIO
U N
Uberlndia 2009
IM
IN
1
Marco Aurlio Silva Rodrigues Maria Margaret de Vasconcelos Lemos Orlando Alves de Oliveira
U N
IM
IN
Uberlndia 2009
Trabalho de Final de curso submetido UNIMINAS como parte dos requisitos para a obteno do grau de Bacharel em Sistemas de Informao.
Orientador: Prof. Msc. Edson Angoti Jnior
S
2
Marcos Aurlio Silva Rodrigues Maria Margaret de Vasconcelos Lemos Orlando Alves de Oliveira
Banca Examinadora: Uberlndia, 9 de julho de 2009.
________________________________________________________________ Professor. Msc.Edson Angoti Jnior (Orientador)
________________________________________________________________
U N
Profa. Dra. Ktia Lopes Silva
_________________________________________________________________ Prof. Dr. Mauro Hemerly Gazzani
IM
IN
Uberlndia 2009
A
3
U N
Se enxerguei longe, foi porque me apoiei nos ombros de gigantes. Isaac Newton
IM
IN
AGRADECIMENTOS
A todos os professores do Curso de Sistema de Informao da UNIMINAS que durante nossa estada nesta casa nos acompanharam e auxiliaram na construo de nosso conhecimento. Em especial aos professores Ana Maria na elaborao deste trabalho. tiveram! Ferreira rabe, Edson Angoti Jr. e Ktia Lopes Silva que estiveram sempre presente Dividir com vocs essa autoria foi um privilgio que poucos de ns
U N
IM
IN
RESUMO A Revoluo Industrial, um dos marcos da Idade Moderna efetivamente desencadeou o processo de urbanizao, que trouxe em si questes a serem resolvidas. Como consequncia, a moradia se tornou um problema a ser equacionado. A soluo que se apresentou foi a verticalizao, trazendo resposta necessidade de espao. Com a difuso dessa forma de associao, foram criadas leis que regulamentaram a sua administrao, que atualmente, tende profissionalizao, tanto que h no mercado vrios sistemas de informao voltados customizados, sendo essa a escolha do Condomnio do Edifcio Porto Seguro, para apoiar a sua administrao, possibilitando o registro de moradores e proprietrios, mantendo o histrico dessas informaes. Foi feita a anlise, definidos os casos de uso e elaborados os diagramas de sequncia 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 acesso ao banco de dados foi empregado o padro de projeto DAO, configurado para se conectar ao MySQL, o SGBD escolhido para a persistncia dos dados. O servidor web selecionado foi o TomCat, que implementa as especificaes servlet e JSP. A interface com o usurio foi construda com pginas JSP de cor azul considerada a mais tranqila de todas, que sugere espao e profundidade. As ferramentas empregadas para a codificao do sistema permitiram a simplificao do cdigo. A engenharia reversa realizada pelo Hibernate facilitou a implementao das classes de entidades, garantindo a correlao entre as classes e as tabelas do banco de dados. As annottations realizaram com facilidade o mapeamento objetorelacional e o padro de projeto DAO proporcionou a persistncia dos dados de forma simples, no banco de dados MySQL que apresentou boa performance, comprovando que foi uma escolha adequada aplicao. Embora, no tenham sido implementados todos os casos de uso, o sistema pode ser concludo, pois o nmero de condomnios est crescendo e a relao entre a gerncia e os condminos tem realizado pelo JDBC juntamente com a utilizao do framewok Hibernate. Para o
U N
IM
IN
localizado em Uberlndia, MG. Assim, desenvolveu-se um sistema de fcil operao,
administrao de condomnios, porm alguns clientes preferem softwares
evoludo. Aliado a isso, as caractersticas do sistema e a documentao para apoiar a expanso do projeto est disponvel, o que facilitar a realizao dessa tarefa.
Palavras chave: gesto de condomnio; sistema de informao; implementao de software.
U N
IM
IN
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 Uberlndia, 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 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. use of UML. The model chosen was the MVC, implemented using the Eclipse and software, and this is the choice the condominium building of Porto Seguro, located in
U N
IM
IN
Keywords: condominium management, information system, implementation of software.
U N
IM
IN
LISTA DE ABREVIATURAS API CPF CPU CRUD CSS DAO GPL GNU GoF HQL HTML HTTP FK IBGE IDE IP J2EE JDBC JDK JEE JPC JSP JVM LGPL MVC OO PK Application Programming Interface Cadastro de Pessoa Fsica Central Processing Unit Create, Retrieve, Updade Delete Cascading Style Sheets Data Access Object General Public License Gnu not Unix Gang of Four Hipertext Modelling Language Hipertext Transfer Protocol Foreign key Hibernate Query Language
Instituto Brasileiro de Geografia e Estatstica Integrated Development Environment Internet Protocol Java Enterprise Edition Java Development Kit
Java Database Conectivity
U N
OBDC ORM RAM SQL TCP XML SGBD
IM
Java Enterprise Edition Java Server Pages Java Virtual Machine Model View Control Orientado a Objeto Object Role Modeling Primary Key
Java Community Process
Lesser GNU Public License Open-DataBase-Connectivity
Random Access Memory Sistema de Gerenciamento de Banco de Dados Structured Query Language Transmission Control Protocol eXtensible Markup Language
IN
Lista de Tabelas Pgina

Tabela 1 Populao brasileira, segundo os censos demogrficos de 1940, 1950, 1960, 1970, 1980, 1991 e contagem de 1996. ........................................................................... 18 Tabela 2 Populao de Uberlndia, MG, 1996 a 2006..................................................................... 19
Lista de Quadros Pgina
Quadro 1 Regras de Negcio............................................................................................................ 31 Quadro 3 Especificao do caso de uso: Fazer Login. .................................................................... 37 Quadro 5 Especificao do caso de uso: Listar Pessoas. ................................................................ 42 Quadro 6 Especificao do caso de uso: Consultar Pessoa. ........................................................... 44 Quadro 8 Especificao do caso de uso: Atualizar Histrico. .......................................................... 49 Quadro 9 Especificao do caso de uso: Pesquisar Histrico. ........................................................ 51 Quadro 10 Especificao do caso de uso: Registrar Conta a Pagar. .............................................. 53 Quadro 12 Especificao do caso de uso: Gerar Taxa de Condomnio........................................... 58 Quadro 13 Especificao do caso de uso: Receber Taxa de Condomnio. ..................................... 61 Quadro 14 Especificao do caso de uso: Gerar Recibo. ................................................................ 64 Quadro 15 Especificao do caso de uso: Gerar Balancete. ........................................................... 67 Quadro 16 Especificao do caso de uso: Gerar Histrico. ............................................................. 70 Quadro 11 Especificao do caso de uso: Registrar Pagamento de Contas................................... 55 Quadro 7 Especificao do caso de uso: Consultar Unidade........................................................... 46 Quadro 4 Especificao do caso de uso: Cadastrar Dados. ............................................................ 39
U N
Lista de Figuras
IM
IN
Quadro 2 Requisitos do sistema. ...................................................................................................... 30
Pgina
Figura 1 Grau de Urbanizao, Brasil, 2000..................................................................................... 19 Figura 2 Fachada do edifcio Porto Seguro. ..................................................................................... 26 Figura 3 Diagrama de classes de negcio........................................................................................ 35 Figura 4 Diagrama de casos de uso. ................................................................................................ 36 Figura 5 Diagrama de sequncia do caso de uso: Fazer Login. ...................................................... 38 Figura 6 Diagrama de sequncia do caso de uso: Cadastrar Dados. .............................................. 40 Figura 7 Diagrama de sequncia do caso de uso: Listar Pessoas................................................... 43 Figura 8 Diagrama de sequncia do caso de uso: Consultar Pessoa. ............................................. 45
Figura 9 Diagrama de sequncia do caso de uso: Consultar Unidade. ........................................... 47 Figura 10 Diagrama de sequncia do caso de uso: Atualizar Histrico. .......................................... 50 Figura 11 Diagrama de sequncia do caso de uso: Pesquisar Histrico. ........................................ 52 Figura 12 Diagrama de sequncia do caso de uso: Registrar Contas a Pagar................................ 54 Figura 13 Diagrama de sequncia do caso de uso: Registrar pagamento de Contas. .................... 56 Figura 14 Diagrama de sequncia do caso de uso: Gerar Taxa de Condomnio............................. 59 Figura 15 Diagrama de sequncia do caso de uso: Receber Taxa de Condomnio. ....................... 62 Figura 16 Diagrama de sequncia do caso de uso: Gerar Recibo. .................................................. 65 Figura 17 Diagrama de sequncia do caso de uso: Gerar Balancete. ............................................. 68 Figura 18 Diagrama de sequncia do caso de uso: Gerar Balancete. ............................................. 71 Figura 19 Classes do pacote entidades............................................................................................ 73 Figura 20 Classes do pacote bo. ...................................................................................................... 74 Figura 22 Classes do pacote action.................................................................................................. 75 Figura 23 Diagrama de sequncia com as classes de projeto do caso de uso: Fazer Login. ................................................................................................................................ 77 Figura 24 Diagrama de sequncia com as classes de projeto do caso de uso: Cadastrar Dados............................................................................................................... 79 Figura 25 Diagrama de sequncia com as classes de projeto do caso de uso: Listar Pessoas. ........................................................................................................................... 81 Figura 26 Diagrama de sequncia com as classes de projeto do caso de uso: Consultar Pessoa.............................................................................................................. 83 Figura 27 Diagrama de sequncia com as classes de projeto do caso de uso: Figura 28 Diagrama de sequncia com as classes de projeto do caso de uso: Atualizar Histrico. ........................................................................................................................... 87 Figura 29 Modelo Arquitetura MVC................................................................................................... 90 Figura 21 Classes do pacote persistncia. ....................................................................................... 74
U N
Figura 30 Classe PessoaBO. ............................................................................................................ 92 Figura 31 Ciclo de vida do servlet. .................................................................................................... 94 Figura 32 Cdigo da pgina consultarPessoaForm.jsp. ................................................................... 95 Figura 33 Pgina pesquisarPessoa.jsp............................................................................................. 96 Figura 34 Modelo em camadas......................................................................................................... 97 Figura 35 Front Controller ................................................................................................................. 98 Figura 36 Arquivo struts.xml.............................................................................................................. 99 Figura 37 Mtodo 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 persistncia. ..................................................................................... 102 Figura 42 Classes do pacote action................................................................................................ 102
IM
Consultar Unidade. ........................................................................................................... 85
IN
Figura 43 Pgina Principal .............................................................................................................. 103 Figura 44 Action setUpForInsertOrUpdate mapeada no arquivo struts.xml. .................................. 104 Figura 45 Mtodo 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 Mtodo InsertOrUpdate implementado na classe CadastrarPessoaAction. .................. 105 Figura 49 Mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction. ................................................................................................. 106 Figura 50 Mensagem de erro gerada pelo mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction. ......................................................... 107 Figura 51 Comando de persistncia declarado no mtodo gravaPropAquisicao() Figura 52 Comando gerao do objeto pessoaDAO declarado no construtor da classe PessoaBO....................................................................................................................... 107 Figura 53 Chamada do mtodo insert() atravs do mtodo insertPessoa() implementado na classe PessoaBO............................................................................... 108 Figura 54 Cdigo do mtodo insert() implementado pela classe PessoaHibernateDAO. .............. 108 Figura 55 Comandos do mtodo gravaPropAquisicao() implementado pela classe CadastrarPessoaAction. ................................................................................................. 109 Figura 56 Comandos de criao do objeto UnidadeHibernateDAO declarado no construtor da classe UnidadeBO. ................................................................................... 109 Figura 57 Comandos do mtodo updateUnidade() implementado pela classe Figura 58 Cdigo do mtodo updateUnidade() implementado pela classe UnidadeHibernateDAO. .................................................................................................. 110 implementado na classe CadastrarPessoaAction, quando j h histrico da Figura 59 Comando de persistncia declarado no mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction. ......................................................... 107
U N
Figura 60 Comandos de criao do objeto HistoricoHibernateDAO declarado no construtor da classe HistoricoBO. .................................................................................. 111 HistoricoBO..................................................................................................................... 111 Figura 61 Comandos do mtodo updateHistorico() implementado pela classe Figura 62 Cdigo do mtodo updateHistorico() implementado pela classe HistoricoHibernateDAO. ................................................................................................. 112 Figura 63 Comando de persistncia declarado no mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction, quando no h histrico da unidade. .......................................................................................................................... 112 Figura 64 Comando declarado no mtodo insertHistorico() implementado na classe HistoricoBO..................................................................................................................... 113
IM
UnidadeBO. .................................................................................................................... 109
unidade. .......................................................................................................................... 111
IN
Figura 65 Cdigo do mtodo insert() implementado na classe HistoricoHibernateDAO............... 113 Figura 66 Mensagem de sucesso gerada pelo mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction. ......................................................... 114 Figura 67 Cdigo do mtodo isertOrUpdate() implementado na classe CadastrarPessoaAction. ................................................................................................. 114 Figura 68 Action insertOrUpdate mapeada no arquivo struts.xml. ................................................. 114 Figura 69 Tela de confirmao 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 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 85 Modelo Fsico de Banco de Dados ................................................................................. 137 Figura 86 Modelo Lgico de Banco de Dados ................................................................................. 136 Figura 87 - Estrutura Padro DAO. .................................................................................................... 140 Figura 88 Arquitetura Hibernate. ..................................................................................................... 143 Figura 84 Arquitetura de Modelo de Banco de Dados. ................................................................... 134 Figura 75 Tela com mensagem de erro de CPF............................................................................. 124
U N
Figura 89 - Arquivo "hibernate.cfg.xml".............................................................................................. 146 Figura 90 Classe Hibernate til. ..................................................................................................... 146 Figura 91 Classe de persistncia HistoricoHibernateDAO. ............................................................ 148 Figura 92 Classe de entidade Historico .......................................................................................... 150
IM
IN
SUMRIO Pgina
1. INTRODUO 1.1. 1.2. 1.3. 1.4. 17
UM BREVE HISTRICO............................................................................................ 17 CENRIO ATUAL ..................................................................................................... 20 IDENTIFICAO DO PROBLEMA ................................................................................ 22 OBJETIVOS ............................................................................................................ 23 1.4.1. 1.4.2. Geral....................................................................................................... 23 Especficos ............................................................................................. 23
1.5. 1.6.
JUSTIFICATIVA........................................................................................................ 23 ORGANIZAO DO TRABALHO ................................................................................. 24 26 28
2. ESPECIFICAO DO PROBLEMA 3. ANLISE E PROJETO 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.
UNIFIED MODELLING LANGUAGE UML .................................................................. 28 ETAPAS DA ANLISE DE SISTEMA ............................................................................ 29 REGRAS DE NEGCIO............................................................................................. 31 CLASSES ............................................................................................................... 33 CASOS DE USO ...................................................................................................... 36 REQUISITOS........................................................................................................... 30
U N
3.6.6. 3.6.7. 3.6.8. 3.6.9. 3.6.10. 3.6.11. 3.6.12. 3.6.13. 3.6.14. 3.7. 3.7.1.
4. ARQUITETURA E CDIGO
IM
3.6.1. 3.6.2. 3.6.3. 3.6.4. 3.6.5.
Caso de Uso 01: Fazer Login.................................................................. 37 Caso de Uso 02: Cadastrar Dados ......................................................... 39 Caso de Uso 03: Listar Pessoas ............................................................. 42 Caso de Uso 04: Consultar Pessoa ........................................................ 44 Caso de Uso 05: Consultar Unidade ....................................................... 46 Caso de Uso 06: Atualizar Histrico........................................................ 49 Caso de Uso 07: Pesquisar Histrico...................................................... 51 Caso de Uso 08: Registrar Conta a Pagar .............................................. 53 Caso de Uso 09: Registrar Pagamento de Contas.................................. 55
Caso de Uso 10: Gerar Taxa de Condomnio ......................................... 58 Caso de Uso 11: Receber Taxa de Condomnio ..................................... 61 Caso de Uso 12: Gerar Recibo ............................................................... 64 Caso de Uso 13: Gerar Balancete .......................................................... 67 Caso de Uso 14: Gerar Histrico ............................................................ 70 Diagramas de Sequncia de Projeto....................................................... 76 88
PROJETO ............................................................................................................... 72
IN
4.1. 4.2. 4.3.
JAVA ..................................................................................................................... 88 ARQUITETURA MVC ............................................................................................... 89 PADRES DE PROJETO ........................................................................................... 90 4.3.1. 4.3.2. 4.3.3. 4.3.4. DAO........................................................................................................ 91 Business Object ...................................................................................... 91 Front Controller ....................................................................................... 92 Application Controller .............................................................................. 93 Servlet .................................................................................................... 93 Pginas JSP ........................................................................................... 94 JDBC ...................................................................................................... 96
4.4.
TECNOLOGIAS UTILIZADAS ...................................................................................... 93 4.4.1. 4.4.2. 4.4.3.
4.6. 4.7.
TOMCAT ................................................................................................................ 97 4.7.1. 4.7.2. 4.7.3. Struts ...................................................................................................... 98 Diagrama de Pacotes ........................................................................... 100 Implementao do Caso de Uso Cadastrar Dados ............................... 103
5. INTERFACE 5.1. 6.1. 6.2. 6.3.
IN
IMPLEMENTAO .................................................................................................... 98
4.5.
J2EE .................................................................................................................... 96
116 128
DIAGRAMA DE NAVEGABILIDADE ............................................................................ 119
6. PERSISTNCIA DE DADOS
U N
6.4. 6.5. 6.5.1. 6.5.2. 6.5.3. 6.6. 7. CONCLUSO
IM
6.3.1. 6.3.2.
CONCEITOS DE BANCO DE DADOS......................................................................... 129 MYSQL ............................................................................................................... 131 Modelos ................................................................................................ 134
MODELAGEM DE BANCO DE DADOS ....................................................................... 134 Compreendendo o Modelo.................................................................... 139
PADRO DE PROJETOS DAO ................................................................................ 139 Caractersticas Hibernate...................................................................... 142 Arquitetura do Hibernate ....................................................................... 142 Mapeamento Objeto Relacional ............................................................ 143 151 154 158
FRAMEWORK HIBERNATE...................................................................................... 141
MECANISMOS DE PERSISTNCIA ........................................................................... 148
REFERNCIAS BIBLIOGRFICAS APNDICE
17
1. 1.1.
INTRODUO
UM BREVE HISTRICO
A instituio da sociedade ocorreu como um movimento dos homens
na tentativa de se protegerem dos instintos predatrios de outros homens e de outros animais. A sociedade constituiu-se como forma de proteo contra abusos e excessos, sendo um mecanismo de defesa contra a lei do mais forte. Assim, foram estabelecidas normas de conduta que tornassem possvel a convivncia entre os pudessem conviver de forma prxima e participativa. Com isso, estabeleceu-se, ento, um conflito entre a necessidade de proteo e a represso dos instintos (FREUD, 2002). Nasceu, assim, a civilizao. Na Grcia antiga, pequenas comunidades se agrupavam em um centro, sinecismo, que significa coabitao. Assim, originaram-se as Polis gregas, que deram origem s cidades ocidentais (WIKIPEDIA, 2009). Ainda dentro do processo histrico, na Idade Mdia, embora organizada a sociedade, a populao no se encontrava necessariamente protegida dos abusos dos mais fortes. Como exemplo clssico, possvel observar as relaes nos feudos. Os senhores feudais os mais fortes tinham direitos totais sobre a vida de seus servos e camponeses. Nesse momento histrico, a lei do mais homens. Buscou-se domar a agressividade natural do ser humano, para que todos
U N
forte era, por assim dizer, institucionalizada. Na passagem do sculo X para o sculo XI se observa o crescimento populacional, com o conseqente aumento da demanda por alimentos. O desenvolvimento agrcola no foi suficiente para responder s necessidades da populao. Se em determinadas reas, a produo era excedente, em outros locais se mostrava insuficiente. A soluo encontrada foi o comrcio. Ocorreu nesse perodo o xodo rural, representado pelo deslocamento significativo da populao 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 Revoluo Industrial, um dos marcos da Idade Moderna, que
efetivamente desencadeou o processo de urbanizao, definida como o aumento da
IM
IN
na tentativa de se protegerem de ataques externos. Denomina-se tal fenmeno de
18
populao urbana em relao rural. Assim, o primeiro pas da Europa a se urbanizar foi a Inglaterra. J em 1850, cinqenta por cento de sua populao morava nas cidades. A acelerao da urbanizao dos pases desenvolvidos se deu a partir da segunda metade do sculo XIX (URBANIZAO DO mundo, 2009). No Brasil, o processo de urbanizao foi mais acelerado que nos pases da Europa e na Amrica do Norte, embora tenha ocorrido mais tardiamente, na segunda metade do sculo XX. Como nos demais pases, tambm a industrializao foi o fator desencadeante do xodo rural (MIRANDA, 2009). A industrializao se intensificou a partir dos governos de Getlio Vargas (1930 1945), se firmando na administrao de Juscelino Kubistchek (1955 1960), com a De acordo com o Instituto Brasileiro de Geografia e Estatstica IBGE 1970 houve a inverso, com o predomnio da populao urbana (55,92%), como mostra a tabela 1 (BRASIL, 2009b).
Tabela 1 Populao brasileira, segundo os censos demogrficos de 1940, 1950, 1960, 1970, 1980, 1991 e contagem de 1996.
IM
HABITANTES % 12.880.182 18.782.891 31.303.034 52.084.984 80.436.409 110.990.990 123.076.831
ANOS 1940 1950 1960 1970 1980 1991 1996
REA URBANA
IN
31,24 36,16 44,67 55,92 67,59 75,59 78,36
A
HABITANTES 28.356.133 33.161.506 38.767.423 41.054.053 38.566.297 35.834.485 33.993.332
at a dcada de 1960, a maioria da populao residia nas reas rurais. A partir de
S
REA RURAL % 68,76 63,84 55,33 44,08 32,41 24,41 21,64
implantao da indstria automobilstica (URBANIZAO DO Brasil, 2009).
TOTAL HABITANTES 41.236.315 51.944.397 70.070.457 93.139.037 119.002.706 146.825.475 157.070.163
U N
Fonte: IBGE (BRASIL, 2009a).
Observa-se ainda, que a urbanizao no se deu de forma homognea no pas. Em 2000, apresentava-se mais acentuada nas regies Sul, Sudeste e Centro-Oeste. Na regio Nordeste as reas litorneas apresentavam aglomerados mais urbanizados. Em poucas reas a taxa de urbanizao era inferior a 25 por
19
cento, sendo que a regio Sudeste apresenta taxa acima de 75 por cento na maioria dos municpios, como mostra a figura 1.
Figura 1 Grau de Urbanizao, Brasil, 2000.
Mineiro, Uberlndia considerada a maior cidade do interior do estado e em 2006, a
U N
REA 1996 431.744 7.242 438.986
populao era estimada em 600.358 habitantes (Tabela 2). Como observado na regio Sudeste, sua taxa de urbanizao alta, da ordem de 97,56 por cento, ao considerar-se o censo de 2000.
Tabela 2 Populao de Uberlndia, MG, 1996 a 2006.
ANOS 2001 505.167 12.637 517.804 2002 521.888 13.055 534.943 2003 539.162 13.487 552.649 2004 556.133 13.909 570.042 2005 570.982 14.280 585.262 2006 585.719 14.649 600.368 2000 488.982 12.232 501.214
Urbana Rural Total
Fonte: Prefeitura de Uberlndia (2007).
IM
Fonte: IBGE (BRASIL, 2001).
Localizada na regio sudeste, no estado de Minas Gerais, no Tringulo
IN
20
De maneira geral no pas, a urbanizao desordenada trouxe em si dificuldades para atender s necessidades bsicas dos migrantes. Nascem, assim, vrios problemas sociais, notadamente o desemprego, a criminalidade e a favelizao (MIRANDA, 2009). Consequentemente a moradia se torna um problema a ser equacionado. Dois aspectos tornam-se relevantes para a soluo. O primeiro diz respeito ao espao propriamente dito, no 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 segurana. A soluo que se apresenta a verticalizao, ou seja, edificaes de vrios andares que abrigassem mais de uma propriedade, trazendo resposta necessidade de espao, e aumentando a com custo mais acessvel. 1.2.
CENRIO ATUAL
Ao se considerar o municpio de Uberlndia, o nmero de condomnios tem crescido, embora no se conhea estatstica oficial sobre o assunto. Se inicialmente, na dcada de 1960 os condomnios eram constitudos na rea central da cidade em edificaes de vrios andares, no final da dcada de 1980 at meados regio central da cidade. Um dos locais, que nesse perodo apresentou um grande crescimento desse tipo de condomnio, foi o bairro Santa Maria. Nesse bairro, localiza-se o condomnio do Edifcio Porto Seguro, prdio estritamente residencial, composto por trs andares, sendo que cada andar abriga duas unidades habitacionais. O sndico do condomnio um dos proprietrios que reside no edifcio. Com a difuso dessa forma de associao, foram criadas leis que regulamentam a criao, administrao e o convvio entre as pessoas, que foram reconhecidas como condminos, uma vez que passaram a dividir o domnio da edificao. Inicialmente, a lei 4.591 de 16 de dezembro de 1964 dispunha sobre o condomnio em edificaes e as incorporaes imobilirias. Em seu artigo quinto delega ao Cdigo Civil a sua regulamentao: o condomnio por meao de parede, soalhos e tetos das unidades isoladas regular-se- pelo disposto no Cdigo Civil, no que lhe for aplicvel (BRASIL, 1964). Assim, a determinao legal dos condomnios da dcada de 1990, iniciou-se a construo de pequenas edificaes, no mais na
U N
IM
IN
segurana, uma vez que a cotizao permite estabelecer mecanismos de proteo,
21
edlicos est no Cdigo Civil Brasileiro, notadamente no Livro III, em seus artigos 1.331 a 1.358. De acordo com a legislao, o sndico seria a pessoa responsvel pela administrao do condomnio. Embora o papel do sndico se mantenha o mesmo, esse no precisa necessariamente ser um morador, sendo cada vez mais comum a figura de um administrador profissional ou at mesmo uma empresa que assuma as funes administrativas. Tambm, comum a existncia de empresas de administrao que apiam as atividades do sndico. A profissionalizao dessas administraes uma tendncia, pois h condomnios com grande nmero de unidades, que requerem uma abordagem mais fazendo uso desses servios, de modo que os direitos e deveres passam a ser de administrao de condomnio, inclusive sindicatos e associaes de empresas, apiam a gesto de condomnios. Se a revoluo industrial imprimiu mudanas profundas na sociedade, respondendo inclusive pela urbanizao, a era da informao, tambm, tem provocado alteraes significativas na sociedade. A valorizao do capital material diretamente relacionada gesto e aplicao do conhecimento. Embora, a administrao de um condomnio, sob o ponto de vista do condomnio, no implique em competio com terceiros, a excelncia dessa gesto traz ganhos aos condminos, sejam financeiros ou subjetivos ao se efetivar a possibilidade de desfrutar de forma conveniente o investimento feito na aquisio ou locao do imvel. Na busca dessa excelncia, sistemas de informao que apiem a tem-se deslocado para a valorizao do capital intelectual. A competitividade est
U N
gesto, automatizando rotinas, padronizando atividades e armazenado informaes se tornam ferramentas importantes no processo de administrao de condomnios. Existem no mercado vrios softwares voltados para administrao de
condomnios. Alguns so disponveis para venda outros de uso exclusivo da administradora, sendo condicionado contratao de servios da empresa. A maioria acessada via Web, tanto pelo sndico, como pelos condminos que tm acesso s informaes de despesa e, exclusivamente, s transaes de sua unidade. Algumas empresas apresentam vdeos demonstrativos do software, outras
IM
IN
respeitados e exigidos de forma mais conveniente. H, no mercado vrias empresas
direcionada com embasamento legal. Tambm, pequenos condomnios esto
22
permitem, inclusive, o uso de uma verso para teste. As funcionalidades mais freqentes oferecidas so: cadastros gerais; clculos automticos: rateios de despesas; mapas demonstrativos; emisso de boletos bancrios e demonstrativos de despesas; taxas a receber;
tesouraria e fluxo de caixa; receitas e despesas regulares; balancetes; relatrios diversos. Fazer
uso
IN
de sistemas
A
padronizados ou buscar softwares
customizados uma deciso importante. As duas possibilidades apresentam apresentar mais funcionalidades, na medida em que so aprimorados mediante solicitaes dos vrios clientes. J softwares desenvolvidos para um cliente especfico podem atender s necessidades de forma mais objetiva.
U N
1.3. do sistema.
customizado, implicando em uma anlise correta dos requisitos que o software
dever atender, sejam eles funcionais ou no funcionais. Obter junto ao cliente de forma clara as suas necessidades fundamental para o desenho e implementao O sistema desenvolvido nesse trabalho para um pequeno condomnio demandar uma ateno maior, uma vez que esse cliente realiza as atividades de forma intuitiva, sem o registro de processos.
IM
vantagens e desvantagens. Sistemas j desenvolvidos podem ter menor custo e
IDENTIFICAO DO PROBLEMA
Optou-se pelo desenvolvimento de um sistema de informao
contas a pagar;
23
1.4. 1.4.1.
OBJETIVOS
Geral Desenvolver um aplicativo Web que apie a gesto de pequenos
condomnios habitacionais, no que tange ao gerenciamento, a administrao e o armazenamento dos dados de moradores e proprietrios, assim como das operaes financeiras.
1.4.2. -
Especficos
documentar os casos de uso;
elaborar os diagramas de seqncia de anlise
utilizar o Desing Patterns J2EE;
implementar o aplicativo em trs camadas de acordo com o modelo MVC; implementar o diagrama de classes no nvel de projeto; implementar a camada de apresentao atravs de Front Controller; implementar a camada de negcio atravs do Business Object; implementar a camada de integrao utilizando DAO Data Access Object; utilizar o Hibernate com annottations para o mapeamento objeto-relacional; utilizar o Struts2 com annottations e
U N
1.5.
utilizar o MySQL como banco de dados.
semelhantes, a abordagem pode ser diferente. Condomnios com muitas unidades se tornam mais complexos, em funo da quantidade de pessoas e consequentemente a sua gesto implicar em atividades e rotinas diferentes das executadas naqueles com
IM
JUSTIFICATIVA
Embora as atividades de gesto de um condomnio sejam em princpio
IN
implementar o sistema utilizando a linguagem de programao Java;
elaborar o diagrama conceitual (diagrama de classe de negcio)
Levantar os requisitos do sistema;
24
poucas unidades. H casos em que os moradores fazem uso de carto de identificao e no raro h catracas eletrnicas na portaria. Tambm comum em grandes condomnios a exigncia de identificao, com registro de documento de identidade dos visitantes. Outros condomnios possuem uma administrao mais informal, o que no significa que no deva ter carter legal. Ao se propor o desenvolvimento de um sistema de informao para um condomnio com poucas unidades habitacionais, temse a possibilidade de manter uma administrao mais prxima e acolhedora. Assim, alia-se o profissionalismo ao sentimento de proximidade, prprio de pequenos grupos de pessoas, pois as relaes tendem a ser mais prximas e pessoais. condomnios traz o desafio de associar a tecnologia a uma gesto personalizada de complexas. Esse diferencial por si s justifica o desenvolvimento de uma nova
ferramenta, para atender a essa clientela. 1.6.
ORGANIZAO DO TRABALHO
Este foi um trabalho realizado em grupo, sendo que os membros se iniciais, Introduo e Especificao do Problema e, tambm, o captulo final, Concluso foram escritos em conjunto, no havendo uma responsabilidade maior por parte de algum integrante do grupo. J, os demais captulos que correspondem s etapas de desenvolvimento do sistema tiveram cada um, um lder que assumiu o direcionamento de sua elaborao. Assim, os demais seis captulos abordam os seguintes temas: Captulo 2: Especificao do problema Traz as informaes sobre o condomnio e apresenta de forma sucinta Captulo 3: Anlise e projeto do sistema Apresenta o referencial terico sobre anlise de projeto, traz, ainda, os diagramas classe, de casos de uso, de sequncias, tanto sob a tica da anlise, quanto sob o ponto de vista do projeto. Captulo 4: Arquitetura e cdigo
U N
o sumrio executivo.
IM
envolveram em todas as etapas para a realizao deste relatrio. Os captulos
IN
pequenos espaos residenciais, quando o mercado parece ofertar propostas mais
Assim, desenvolver um software simplificado para a gesto de pequenos
25
Alm
discorrer
sobre
os
conceitos
nos
quais
se
apoiou
desenvolvimento da soluo, este captulo apresenta, ainda, a arquitetura empregada e o cdigo da implementao. Captulo 5: Interface Nesse captulo so apresentadas as interfaces para comunicao entre o sistema e os usurios. Cita, ainda, referencial terico, sobretudo em relao ao uso de cores. Diferente dos demais captulos, esse, em especial, no teve uma autoria definida. Porm, os autores consideram a sua apresentao como mnima, mas importante para a viso integral do sistema, mesmo que a abordagem da interface seja superficial. Apresenta o processo de armazenagem e recuperao dos dados. desenvolvimento do sistema.
Captulo 7: Concluses
Nesta parte so apresentadas as concluses observadas pelo grupo considerando-se os objetivos que nortearam a realizao deste trabalho.
U N
IM
IN
Resgata
os
conceitos
tecnologias
que
S
foram
Captulo 6: Persistncia de dados
empregados
durante
26
2.
ESPECIFICAO DO PROBLEMA O condomnio do Edifcio Porto Seguro (Figura 2) foi criado em 17 de
maro de 1997, com funo estritamente residencial. formado por seis unidades habitacionais, distribudas em trs andares e uma rea trrea. A rea comum composta pelo saguo, as escadas, corredores internos e externos e a garagem. A construo simtrica, sendo a parte anterior igual parte posterior. As unidades so iguais, apenas as do primeiro pavimento possuem uma pequena rea descoberta, que no est presente nas unidades dos demais pavimentos. Para cada realizado pelos proprietrios no momento do estabelecimento do condomnio. apartamento existem duas vagas de garagem que foram definidas por sorteio
U N
Figura 2 Fachada do edifcio Porto Seguro.
IM
IN
27
Por se tratar de um condomnio com poucos integrantes, a administrao do imvel vem sendo realizada por um dos condminos que assume a funo de sndico. O valor da manuteno mensal calculado a partir do rateio das despesas, de modo que pago aps a realizao das despesas. Dada a proximidade e o pequeno nmero de moradores, a administrao do imvel realizada de forma bastante intuitiva e pouco formal. Assim, observam-se algumas dificuldades no recebimento da taxa de condomnio e consequentemente o atraso no pagamento de tarifas pblicas, penalizando o conjunto dos moradores, uma vez que no h a cobrana de multas ou juros dos moradores que pagam a sua parte do rateio das despesas alm do prazo. que apie a administrao do condomnio, que seja de fcil operao. Esse sistema histrico dessas informaes, permitindo resgat-las quando necessrio. O software dever, ainda, registrar todas as contas a serem pagas para, ento, gerar a taxa de condomnio, que dada pelo rateio das despesas mensais. O recebimento da taxa de condomnio ser realizado at o 10 dia do ms subseqente. Aps essa data incidiram juros e multa. Ser importante que o sistema registre todos os recebimentos da taxa
de condomnio e tambm, o pagamento de todas as despesas do imvel, o que possibilitar gerar os recibos e a prestao de conta de forma automatizada.
U N
IM
IN
dever registrar os moradores e proprietrios das unidades, mantendo, inclusive o
Propem-se, ento o desenvolvimento de um sistema de informao
28
3.
ANLISE E PROJETO
Maria Margaret de Vasconcellos Lemos
Anlise consiste em um mtodo para se conhecer um problema ou situao, em que se divide o objeto do estudo em partes para o exame minucioso de cada componente. Voltada para desenvolvimento de software, a anlise o processo atravs do qual se busca conhecer o negcio do cliente, para produzir um modelo que espelhe a realidade. O principal objetivo da anlise de sistemas realizar um mapeamento prvio do comportamento requerido para os elementos de modelagem que sero Assim, modelagem a concepo de sistemas de informaes, antes projetos, sendo, tambm, importante para aqueles de mdio e pequeno porte. Tratase de uma forma de visualizar o projeto e verificar se os requisitos esto sendo atendidos antes da implementao (OBJECT MANEGEMMENT GROUP, 2009). linguagem padro para a sua execuo, a Unified Modeling Language, UML. 3.1.
U N
das regras de interao entre seus vocbulos. Assim, a UML indica como criar e ler modelos bem formados. Um modelo escrito empregando-se a UML poder ser interpretado sem ambigidades por outro desenvolvedor ou outra ferramenta. Os blocos de construo da UML so os itens, os relacionamentos e os diagramas. Os itens so as abstraes identificadas e podem ser de quatro tipos. Os itens estruturais representam elementos conceituais ou fsicos. So as partes estticas do modelo, enquanto que os itens comportamentais so as partes dinmicas, definidos pelos verbos, uma vez que representam o comportamento no tempo e espao. Os itens de agrupamento so as partes organizacionais. Correspondem aos pacotes que so meramente conceituais e agregam os itens
IM
Dada a importncia da elaborao de projetos de softwares, foi definida uma
UNIFIED MODELLING LANGUAGE UML

As linguagens se destinam a comunicar algo atravs de vocabulrios e
IN
que sejam codificados. , ainda, parte essencial do desenvolvimento de grandes
implementados posteriormente na fase de construo (SILVA, 2009).
29
estruturais, comportamentais e ainda outros itens de grupo, quando necessrio. J, os itens anotacionais so aqueles que explicam o modelo. Os relacionamentos definem a interao entre os elementos podendo ser de quatro tipos. Dependncia, acontece quando a alterao do item independente implica na alterao semntica do item dependente. A associao descreve a conexo entre os objetos, podendo ser uma agregao que define um relacionamento estrutural entre o todo e suas partes. O relacionamento de generalizao implica em objetos especializados, os filhos, que podem ser substitudos por objetos generalizados, os pais. O quarto tipo de relacionamento, a saber, a realizao, trata-se de um contrato em que um classificador especifica o que a classe deve implementar.
ngulos de visualizao de um sistema. So nove os diagramas definidos pela UML, sendo que cada um tem funo bem definida. O diagrama de classes exibe o conjunto de classes, interfaces, colaboraes 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 h o diagrama de seqncia cujo foco principal a ordem temporal das mensagens e o diagrama de colaborao que privilegia a organizao estrutural entre os objetos. Outro diagrama, o de estado, exibe o estado, transio, eventos e atividades. Traz, portanto, uma viso dinmica do sistema, sendo o diagrama de atividade um tipo especial de diagrama de estado, pois apresenta o fluxo de uma atividade para outra. A viso esttica da implementao do sistema pode ser representada pelo diagrama de componentes que apresenta as organizaes e de pendncias entre um conjunto de componentes. J a viso esttica de uma arquitetura oferecida pelo diagrama de implantao (BOOCH, RUMBAUGH & JACOBSON, 2000). 3.2. organizao e modelagem de comportamento do sistema. Para registrar a interao
U N
informaes sobre o domnio da aplicao, quais as funcionalidades requeridas, qual
IM
ETAPAS DA ANLISE DE SISTEMA

A primeira etapa da anlise de um sistema consiste na descoberta de
IN
Os diagramas so representaes grficas que oferecem vrios
que outro classificador garante executar, como os mtodos definidos pela interface
30
o desempenho que o sistema deve apresentar as restries de hardware, dentre outras questes. Responder a essas e outras perguntas envolvem grande nmero de pessoas de diferentes reas da empresa contratante. Essa fase muito importante, pois quanto mais claras as especificaes, mais fiel realidade ser o modelo. Nesta fase so empregadas tcnicas de elucidao de requisitos, com o intuito de aumentar o comprometimento do cliente e desenvolvedores, com a soluo que se deseja construir. muito importante que os requisitos sejam extrados de maneira correta e objetiva. Nessa etapa so identificadas as regras de negcio e os requisitos do
Os requisitos descrevem de modo claro, sem ambigidades, conciso e consistente todos os aspectos significativos do sistema proposto. Eles devem permitir que os desenvolvedores construam um sistema que satisfaa os clientes. Um requisito considerado como funcional quando descreve um restries ou condies impostas ao sistema ou ao seu desenvolvimento (SILVA, BONIN & PALUDO, 2007). O quadro 1 apresenta a relao dos requisitos funcionais e no Com o levantamento dos requisitos possvel identificar as classes servio ou funo a ser realizada. J requisitos no funcionais coincidem com
U N
funcionais levantados para o desenvolvimento do sistema em questo. que estaro envolvidas no desenvolvimento do software e o reconhecimento dos principais processos da empresa que definiro os casos de uso do sistema. Uma vez estabelecidos e documentados os casos de uso, passa-se etapa seguinte que descreve as interaes ocorridas no sistema, muito bem representadas pelos diagramas de sequncia.
IM
IN
3.3.
REQUISITOS
sistema, que podem ser de dois tipos, os funcionais e os no funcionais.
31
Requisitos funcionais 1. 2. 3. 4. 5. 6. 7. 8. Cadastrar proprietrios; cadastrar moradores; registrar contas a pagar; calcular o valor da taxa de condomnio; registrar recebimento mensal da taxa de condomnio; registrar pagamentos; emitir recibos; gerar prestao de contas. Requisitos no-funcionais 1. 2. 3. 4. 5. Ser compatvel com o Windows XP; permitir o acesso via Web; usar a linguagem Java; usar o continer web apache; usar banco de dados MySQL
Quadro 1 Requisitos do sistema.
3.4.
restries de uma organizao para alcanar seus objetivos. So usadas para
U N
alcanar os objetivos de uma empresa, a comunicao entre ela e terceiros e, tambm, demonstrar as obrigaes legais, operar mais eficientemente, automatizar operaes, dentre outras (ARAUJO, 2009). As regras de negcio podem ter origens variadas. H aquelas que so definidas por dispositivos legais, como o percentual a ser pago a ttulo de imposto ou o valor permitido para o clculo de juros ou multas. Outras definem as pessoas responsveis por determinadas operaes no sistema. Existem, ainda, regras para clculos internos, a obrigatoriedade de validao de dados, como por exemplo, no sistema proposto, o CPF a ser cadastrado dever ser uma sequncia numrica vlida. Para o sistema de condomnio, foram identificadas e documentadas dez regras de negcio como apresenta o quadro 2 a seguir.
IM
REGRAS DE NEGCIO
As regras de negcio dizem respeito s operaes, definies e
IN
32
Nome
Permisso
RN - 01
Descrio Somente podero operar o sistema as pessoas autorizadas. Nome Cadastro de dados pessoais RN - 02
Descrio Somente sero cadastradas as pessoas com CPF vlido. Nome Cadastro de moradores RN - 03
Nome
Cadastro de proprietrio
Para cadastrar o morador de uma unidade preciso ter registrado a Descrio mudana do morador anterior. Assim, somente ser cadastrado o morador de uma unidade, quando no houver morador j cadastrado. RN - 04
Nome
IN
Para cadastrar o proprietrio de uma unidade preciso ter registrado a venda realizada pelo proprietrio anterior. Assim, somente ser Descrio cadastrado o proprietrio de uma unidade, quando no houver proprietrio j cadastrado. Lanamento de contas a pagar RN - 05
Nome
IM
Descrio Todas as contas a pagar sero lanadas no sistema. Gerao da taxa de condomnio RN 06
Descrio A taxa de condomnio ser gerada sempre no dia 1 do ms.
U N
Nome
Clculo da taxa de condomnio
RN 07
O valor da taxa de condomnio de cada unidade calculado pela Descrio soma dos pagamentos de contas realizados no ms anterior, dividido por 6. Nome Data para o pagamento da taxa de condomnio RN 08
A taxa de condomnio dever ser paga at o dia 10 do ms Descrio subseqente. Caso o dia 10 no seja dia til, a data do pagamento ser automaticamente transferida para o prximo dia til.
33
Nome
Pagamento da taxa de condomnio
RN - 09
Pagamentos realizados aps a data estabelecida sero acrescidos Descrio de juros de 2% ao ms e multa de 3%. Nome Registro de pagamento da taxa de condomnio RN - 10
Todos os pagamentos de taxa de condomnio sero registrados no Descrio sistema.

Quadro 2 Regras de Negcio.
3.5.
CLASSES
O diagrama de classes considerado por vrios autores como o mais organizao das classes do sistema, permitindo alm da visualizao das classes e se complementam e a transmisso da informao dentro do sistema (SILVA, 2007). Durante o processo de anlise, ao se delinear o sumrio executivo, como regra bsica para nortear o analista, considera-se que os substantivos da aplicao. 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 simultnea. A partir dessa viso e da proposta de
U N
a necessidade
apresentar o diagrama de casos de uso seguido pelas especificaes de cada caso de uso e dos respectivos diagramas de sequncia, sero apresentadas inicialmente as classes e os diagrama de classes correspondente. O processo de levantamento das necessidades e requisitos evidenciou de implementao de sete classes de negcio para o
desenvolvimento do sistema, conforme definidas abaixo: Classe UsuarioEntidade Essa classe registra o nome de usurio e a respectiva senha para permitir a operao do sistema.
IM
encontrados sugerem as classes de negcios necessrias para o desenvolvimento
IN
de seus atributos e mtodos, a representao de seus relacionamentos, como estas
importante e utilizado diagrama da UML. Ele apresenta uma viso esttica da
34
Classe Pessoa responsvel pelo registro de todas as pessoas que se relacionam com o imvel, sejam moradores ou proprietrios. Os atributos dessa classe so: nome, CPF e telefone. Classe Unidade Registra todas as unidades habitacionais existentes, ou seja, os apartamentos. Mantm o registro do atual morador e atual proprietrio. Seus atributos so: nmero, morador e proprietrio. Classe Histrico Essa classe responsvel por manter o registro de todos os inicial e a data do trmino da relao de cada pessoa com a unidade. Por isso tem mor_DtEntrada e mor_DtSaida.
Classe ContasAPagar
Essa classe responsvel pelo registro de todas as contas que o condomnio dever pagar em funo de bens adquiridos ou servios recebidos. Os atributos dessa classe so: dataVencimento, descricaoConta, valorConta e mesRef. Classe TaxaCondomnio
condminos a ttulo de taxa de condomnio. Seus atributos so: mesRef, valorTaxa, dataGeracao, datavencimento. Classe LancamentoMes responsvel pelo registro das operaes financeiras do condomnio
U N
mantendo os dados dos pagamentos e dos recebimentos das taxas de condomnio. Os atributos dessa classe so: data, tipo, descrio, juros, multa e valorFinal. Na etapa de anlise foi usado o Enterprise Architect ferramenta desenvolvida para a anlise, modelagem e manuteno de softwares, que emprega a UML e gera a documentao do sistema. Como um dos resultados do emprego dessa ferramenta foi o diagrama de classes obtido pela interao das classes descritas anteriormente (Figura 3).
IM
Essa classe gera e mantm o valor mensal a ser pago pelos
IN
como atributos: unidade, proprietrio, proDtAquisicao, pro_DtVenda, morador,
moradores e proprietrios de cada uma das unidades, registrando inclusive a data
35
Figura 3 Diagrama de classes de negcio.
U N IM IN A S
36
3.6.
CASOS DE USO
Conceitualmente, casos de uso dizem respeito s principais atividades
da empresa ligadas ao sistema a ser implementado, sendo assim, cada caso de uso est ligado a um conjunto de requisitos funcionais do sistema (WAZLAWICK, 2004). A simplicidade de um diagrama de casos de uso permite a observao das funcionalidades, os usurios envolvidos e as possveis integraes com sistemas externos (YOSHIMA, 2005). Foram identificados quatorze casos de uso, conforme a figura 4.
U N
Figura 4 Diagrama de casos de uso.
responsvel pela gesto do condomnio. Outras pessoas, que por ventura operem o sistema, somente o faro com a autorizao do sndico e as permisses e responsabilidades sero idnticas s dele. Por isso, para o desenvolvimento do aplicativo, considerou-se, apenas a existncia de um nico ator.
IM
A interao com o sistema realizada pelo Sndico, pessoa
IN
37
3.6.1.
Caso de Uso 01: Fazer Login Nesse caso de uso, o sndico solicita entrar no sistema e para isso
informa os dados necessrios para obter a permisso de operar o sistema, conforme especificado no quadro 3. Nome Sumrio Fazer Login CSU - 01
Este caso de uso descrever os procedimentos para realizar o login no sistema
Ator primrio: Sndico. Pr-condio: O usurio estar cadastrado. Ps-condio: O login foi realizado.
Fluxo Principal
2. 3. 4.
O sistema apresenta o formulrio para o login. O sndico informa o usurio e a senha. Sistema verifica os dados e encerra o caso de uso
Fluxo Alternativo: No h.
U N
RN01
Fluxo de Exceo [3]: Dados incorretos a. O sistema informa que os dados esto incorretos e volta ao item 2. Regras de Negcio Associadas
Quadro 3 Especificao do caso de uso: Fazer Login.
IM
IN
1.
O sndico inicia sistema.
Ator(es) secundrio(s): No h.
38
O diagrama de sequncia desse caso de uso apresenta o fluxo das mensagens que so trocadas entre os componentes do sistema para permitir que o usurio possa operar o sistema, como mostra a figura 5.
Figura 5 Diagrama de sequncia do caso de uso: Fazer Login.
As classes de anlise envolvidas neste caso de uso e os respectivos papis so: a)
Interface de Fazer Login: representa a classe de fronteira desse caso de uso. Permite que o usurio informe os dados para realizar o login no sistema, de modo que possa operar o sistema.
U N
b) c) usurio. d)
Controlador de Fazer Login: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre a interface Fazer Login e a classe Usurios.
Usurios: representa a classe de entidade deste caso de uso. Sua funo armazenar os atributos responsveis por realizar a autenticao dos dados do
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. apresentada aps a autenticao do login.
IM
IN
39
3.6.2.
Caso de Uso 02: Cadastrar Dados Neste caso de uso, o sndico far o cadastro de uma pessoa que ter
relao com o condomnio de moradia ou de propriedade. O sistema no permitir o cadastro de morador ou proprietrio de uma unidade se outra pessoa j estiver cadastrada nessa situao. Para isso necessrio registrar, anteriormente a sada ou a venda da unidade (Quadro 4) .
Nome Sumrio
Ator primrio: Sndico. Ator(es) secundrio(s): No h. registrada.
Pr-condio: No haver registro de pessoa na unidade, na condio a ser Ps-condio: O cadastro foi realizado.
2. 3. 4. 5.
U N
Fluxo Alternativo: No h. Fluxo de Exceo [4A]: CPF invlido a. O sistema informa que o CPF no vlido e volta ao item 3. Fluxo de Exceo [4B]: Existe morador ou proprietrio cadastrado a. O sistema informa que no possvel cadastrar a pessoa na condio escolhida e encerra o caso de uso. Regras de Negcio Associadas RN02, RN03 e RN04
Quadro 4 Especificao do caso de uso: Cadastrar Dados.
IM
1.
O sndico solicita o cadastro de dados pessoais. O sistema apresenta o formulrio para o preenchimento dos dados. O sndico realiza o preenchimento do formulrio. O sndico confere os dados inseridos no formulrio e confirma. Sistema registra o cadastro e encerra o caso de uso
IN
Fluxo Principal
Cadastrar Dados CSU - 02 Este caso de uso descrever os procedimentos realizados para o cadastro dos dados pessoais de proprietrios ou moradores e a unidade com a qual mantero relao.
40
O diagrama deste caso de uso exibe o fluxo de interao, apresentando a sequncia das mensagens para a sua execuo (Figura 6).
Figura 6 Diagrama de sequncia do caso de uso: Cadastrar Dados.
U N
papis so: a) b) c) sistema.
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita o cadastro de uma pessoa.
Controlador de Cadastrar Dados: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre as interfaces e as classes de entidades Pessoa, Unidade e Histrico, responde, ainda, pela validao do CPF.
Interface de Cadastrar Dados: representa a classe de fronteira desse caso de uso. Permite que o usurio informe os dados para cadastrar uma pessoa no
IM
As classes de anlise envolvidas neste caso de uso e os respectivos
IN
41
d)
Pessoa: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
e)
Unidade: representa outra classe de entidade deste caso de uso. Sua funo armazenar os atributos das unidades, o nmero da unidade, a pessoa que moradora, assim como a pessoa que proprietria da unidade em questo.
f)
Histrico: representa a terceira e ltima classe de entidade deste caso de uso. Sua funo armazenar os atributos das relaes entre as pessoas e as unidades. Mantendo os dados mesmo aps o trmino dessa relao. Os de entrada e a data de sada do morador; a pessoa que proprietria; a data de aquisio e a data de venda relativa a esse proprietrio. atributos dessa classe so: o nmero da unidade; a pessoa moradora; a data
U N
IM
IN
42
3.6.3.
Caso de Uso 03: Listar Pessoas Esse caso de uso descreve os procedimentos que sero realizados
para o sistema apresentar a relao das pessoas que j se encontram cadastradas, como mostra o quadro 5. Nome Sumrio Listar Pessoas CSU - 03
Este caso de uso descreve os procedimentos realizados para apresentar os dados de todas as pessoas cadastradas.
Pr-condio: Ter pessoas cadastradas no sistema.
Ps-condio: A lista com os dados das pessoas cadastradas apresentada. Fluxo Principal
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: No h.
U N
Fluxo de Exceo [4]: O cadastro est vazio a. O sistema emite mensagem informando que o cadastro est vazio. b. O caso de uso encerrado Regras de Negcio Associadas
Quadro 5 Especificao do caso de uso: Listar Pessoas.
apresentando a sequncia das mensagens para a sua execuo (Figura 7).
IM
O diagrama deste caso de uso exibe o fluxo de interao,
IN
1. O sndico solicita listar todas as pessoas cadastradas.
Ator primrio: Sndico.
43
Figura 7 Diagrama de sequncia do caso de uso: Listar Pessoas.
As classes de anlise envolvidas neste caso de uso e os respectivos papis so: a) Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita a lista das pessoas cadastradas. b) Controlador de Listar Pessoas: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial e a classe de entidade Pessoa, responde, ainda, pela verificao se a lista no est vazia. c)
U N
d)
Interface de Listar Pessoas: representa a classe de fronteira desse caso de uso, apresenta a lista das pessoas cadastradas.
Pessoa: representa a classe de entidade deste caso de uso. Sua funo armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
IM
IN
44
3.6.4.
Caso de Uso 04: Consultar Pessoa Esse caso de uso descreve os procedimentos que sero realizados
para a consulta dos dados de uma pessoa j cadastrada no sistema, como mostra o quadro 6.
Nome Sumrio
Consultar Pessoa
CSU - 04
Este caso de uso descreve os procedimentos realizados para consultar o cadastro de uma pessoa.
Ator primrio: Sndico. Pr-condio: A pessoa estar cadastrada no sistema.
Ps-condio: Os dados da pessoa foram recuperados. Fluxo Principal 2. O sistema solicita o CPF da pessoa. 3. O sndico informa o CPF.
1. O sndico solicita consultar o cadastro de uma pessoa.
4. O sistema apresenta o nome e o telefone da pessoa.
Fluxo Alternativo [4]: A pessoa no est cadastrada a. O sistema emite mensagem informando que a pessoa no foi cadastrada. b. O caso de uso encerrado.
U N
RN 02
Fluxo de Exceo [3]: O CPF informado no vlido a. O sistema emite mensagem informando que o CPF no vlido. b. O sistema volta ao item 2. c. O caso de uso encerrado Regras de Negcio Associadas
Quadro 6 Especificao do caso de uso: Consultar Pessoa.
IM
5. O caso de uso encerrado.
IN
45
Figura 8 Diagrama de sequncia do caso de uso: Consultar Pessoa.
As classes de anlise envolvidas neste caso de uso e os respectivos papis so: a) Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita a consultar cadastro. b) Controlador de Consultar Pessoa: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Consultar Pessoa e a classe de entidade Pessoa. Responde, ainda, pela validao do CPF.
U N
c) consultada. d) telefone.
Interface de Consultar Pessoas: representa a classe de fronteira desse caso de uso. Disponibiliza ao usurio o formulrio para obter o CPF da pessoa que ser consultada e apresenta ao sndico o nome e o telefone da pessoa
Pessoa: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das pessoas cadastradas, nome; CPF e
IM
IN
46
3.6.5.
Caso de Uso 05: Consultar Unidade Esse caso de uso descreve os procedimentos que sero realizados
para a consulta dos dados de uma unidade, como mostra o quadro 7.
Nome Sumrio
Consultar Unidade
CSU - 05
Este caso de uso descreve os procedimentos realizados para consultar os dados de cadastro de uma unidade.
Ator primrio: Sndico. Ator(es) secundrio(s): No h. Pr-condio: A unidade estar cadastrada no sistema. Ps-condio: Os dados da unidade foram recuperados. Fluxo Principal 2. O sistema solicita o nmero da unidade. 3. O sndico informa o nmero. 5. O caso de uso encerrado. Fluxo Alternativo: No h.
1. O sndico solicita a consulta de dados de uma unidade.
4. O sistema apresenta o morador e o proprietrio da unidade.
U N
No h.
Fluxo de Exceo:
Quadro 7 Especificao do caso de uso: Consultar Unidade.
IM
Regras de Negcio Associadas O diagrama deste caso de uso exibe o fluxo de interao,
IN
47
Figura 9 Diagrama de sequncia do caso de uso: Consultar Unidade.
papis so: a)
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita consultar os dados de uma unidade.
U N
b) c) d)
Controlador de Consultar Unidade: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Consultar Unidade e as classes de entidades Unidade e Pessoa.
Interface de Consultar Unidade: representa a classe de fronteira desse caso de uso. Disponibiliza ao sndico o formulrio para obter o nmero da unidade a ser consultada e como resposta, apresenta o nome do morador e do proprietrio da unidade consultada. Unidade: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das unidades, o nmero da unidade, a pessoa
IM
IN
48
que moradora, assim como a pessoa que proprietria da unidade em questo. e) Pessoa: representa outra classe de entidade deste caso de uso. Sua funo armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
U N
IM
IN
49
3.6.6.
Caso de Uso 06: Atualizar Histrico Esse caso de uso descreve os procedimentos que sero realizados
para atualizar os dados do histrico de uma unidade. Nesse caso de uso, as regras de negcio associadas, determinam que o mesmo seja executado e no interferem no processo de sua realizao. Sendo assim, no geram fluxo de exceo, como mostra o quadro 8. Nome Sumrio Atualizar Histrico CSU - 06 Este caso de uso descrever os procedimentos realizados para atualizar os dados do histrico de determinada unidade.
Ator primrio: Sndico Ator(es) secundrio(s): No h
Pr-condio: Haver histrico anterior em aberto. Ps-condio: O histrico foi atualizado.
1. 2. 3. 4. 5.
O sndico solicita a atualizao o histrico de uma unidade. O sistema apresenta o formulrio para a atualizao dos dados do histrico de uma unidade. O sndico realiza o preenchimento do formulrio. O sndico confere os dados inseridos no formulrio e confirma. Sistema registra a atualizao e encerra o caso de uso
U N
RN 03 e RN 04
Fluxo Alternativo [3A]: Cadastro de venda a. O sndico informa que registro de venda do imvel. Fluxo Alternativo [3B]: Cadastro de sada a. O sndico informa que registro de sada do imvel. Fluxo de Exceo: No h. Regras de Negcio Associadas
Quadro 8 Especificao do caso de uso: Atualizar Histrico.
IM
IN
Fluxo Principal
50
As classes de anlise envolvidas neste caso de uso e os respectivos papis so: a) Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita atualizar os dados de histrico de uma unidade. b) Controlador de Atualizar Histrico: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Atualizar Histrico e as classes de entidade Histrico e Unidade.
U N
c) atualizados. d) questo. e)
Interface de Atualizar Histrico: representa a classe de fronteira desse caso de uso. Disponibiliza ao usurio o formulrio para obter os dados que devero ser
Histrico: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das unidades, o nmero da unidade, a pessoa que moradora, assim como a pessoa que proprietria da unidade em
Unidade: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das unidades, o nmero da unidade, a pessoa
IM
IN
Figura 10 Diagrama de sequncia do caso de uso: Atualizar Histrico.
51
que moradora, assim como a pessoa que proprietria da unidade em questo.
3.6.7.
Caso de Uso 07: Pesquisar Histrico Esse caso de uso descreve os procedimentos que sero realizados
para pesquisar os dados de histrico de uma unidade, como mostra o quadro 9.
Nome Sumrio
Pesquisar Histrico
CSU - 07
Ator primrio: Sndico. Pr-condio: No h.
1. O sndico solicita a pesquisa do histrico. 3. O sndico informa o nmero da unidade. 4. O sistema exibe os dados. 5. O caso de uso encerrado.
2. O sistema solicita o nmero da unidade para a pesquisa.
U N
unidade. No h.
Fluxo Alternativo [4A]: O cadastro est vazio a. O sistema emite mensagem informando que no h registro de histrico da
b. O caso de uso encerrado. Fluxo de Exceo:
Quadro 9 Especificao do caso de uso: Pesquisar Histrico.
IM
IN
Fluxo Principal
Ps-condio: A lista com o histrico da unidade apresentada.
Regras de Negcio Associadas
Ator(es) secundrio(s): Haver histrico registrado anteriormente.
Este caso de uso descreve os procedimentos realizados para pesquisar o histrico de uma dada unidade.
52
Figura 11 Diagrama de sequncia do caso de uso: Pesquisar Histrico.
As classes de anlise envolvidas neste caso de uso e os respectivos a) Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita pesquisar os dados de histrico. b) Controlador de Pesquisar Histrico: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Pesquisar Histrico e a classe de entidade Histrico.
U N
c) uso. d) questo.
Interface de Atualizar Histrico: representa a classe de fronteira desse caso de Disponibiliza ao sndico o formulrio para que informe qual unidade dever ter o histrico pesquisado.
Histrico: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das unidades, o nmero da unidade, a pessoa que moradora, assim como a pessoa que proprietria da unidade em
IM
papis so:
IN
53
3.6.8.
Caso de Uso 08: Registrar Conta a Pagar Esse caso de uso descreve os procedimentos que sero realizados
para registrar contas a pagar. Embora haja regra de negcio envolvida na realizao desse caso de uso, esta no interfere em sua execuo, apenas determina que deve ser executado, como mostra o quadro 10.
Nome Sumrio
Registrar Contas a Pagar
CSU - 08
Este caso de uso apresenta os passos para o registro das contas a pagar.
Ator primrio: Sndico. Ator(es) secundrio(s): No h. Pr-condio: No h. Ps-condio: A conta foi registrada.
1. 2. 3. 4. 5. 6.
O sindico solicita o registro de contas a pagar. O sistema apresenta as opes do tipo de conta a ser registrada. O sistema solicita os dados da conta. O sistema registra as informaes no banco de dados. O caso de uso encerrado. O sndico escolhe o tipo de conta.
U N
Fluxo Alternativo: No h. No h. RN 05
Fluxo de Exceo:
Quadro 10 Especificao do caso de uso: Registrar Conta a Pagar.
IM
IN
Fluxo Principal
54
Figura 12 Diagrama de sequncia do caso de uso: Registrar Contas a Pagar.
As classes de anlise envolvidas neste caso de uso e os respectivos papis so: a) Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita registrar uma conta que dever ser paga posteriormente.
U N
b) Pagar. c) d)
Controlador de Registrar Contas a Pagar: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Registrar Contas a Pagar e a classe de entidade Contas a
Interface de Contas a Pagar: representa a classe de fronteira desse caso de uso. Disponibiliza ao usurio o formulrio para preenchimento dos dados da conta em questo. Contas a Pagar: representa a classe de entidade deste caso de uso. Sua funo armazenar os atributos das contas que sero pagas, a data de vencimento, a descrio e o valor da conta e tambm, o ms de referncia.
IM
IN
55
3.6.9.
Caso de Uso 09: Registrar Pagamento de Contas Esse caso de uso descreve os procedimentos que sero realizados
para registrar o pagamento de contas, como mostra o quadro 11.
Nome Sumrio
Registrar Pagamento de Contas
CSU - 09
Este caso de uso apresenta os procedimentos para o registro dos pagamentos realizados pelo condomnio.
Ator primrio: Sndico. Ator(es) secundrio(s): no h. Ps-condio: O pagamento da conta foi registrado. Fluxo Principal Pr-condio: A conta a pagar ter sido cadastrada anteriormente.
1. O sndico solicita o registro do pagamento de contas. 2. O sistema apresenta as contas j cadastradas. 3. O sndico seleciona a conta. dos dados complementares. 5. O sndico informa os dados.
4. O sistema apresenta as informaes da conta e solicita o preenchimento
6. O sistema registra as informaes. 7. O sistema encerra o caso de uso. Fluxo Alternativo:
U N
No h. RN 05
Fluxo de Exceo [2]: No h conta cadastrada. a) O sistema informa que no h conta cadastrada. b) O sistema encerra o caso de uso. Fluxo de Exceo [4]: No h conta para pagar. a. O sistema informa que no h conta para pagar. b. O sistema encerra o caso de uso. Regras de Negcio Associadas
Quadro 11 Especificao do caso de uso: Registrar Pagamento de Contas.
IM
IN
56
Figura 13 Diagrama de sequncia do caso de uso: Registrar pagamento de Contas.
papis so: a)
U N
b) c)
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita registrar o pagamento de uma conta.
Controlador de Registrar Pagamento de Contas: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Registrar Pagamento de Contas, e as classes de entidade Contas a Pagar e Lanamento Ms.
Interface de Registrar Pagamento de Contas: representa a classe de fronteira desse caso de uso. Disponibiliza ao sndico o formulrio para preenchimento dos dados para o pagamento de uma conta. Na sequncia apresenta as contas que podem ser pagas para que o sndico escolha a que ir pagar e informe os dados do pagamento.
IM
IN
57
d)
Contas a Pagar: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das contas que sero pagas, a data de vencimento, a descrio e o valor da conta e tambm, o ms de referncia.
e)
Lanamento Ms: corresponde a outra classe de entidade envolvida nesse caso de uso. Sua funo armazenar os atributos dos lanamentos financeiros, data, tipo, descrio, juros, multa e valor final.
U N
IM
IN
58
3.6.10. Caso de Uso 10: Gerar Taxa de Condomnio Esse caso de uso descreve os procedimentos que sero realizados para registrar o pagamento de contas, como mostra o quadro 12.
Nome Sumrio
Gerar Taxa de Condomnio
CSU - 10
Este caso de uso descreve as etapas para gerar as taxas mensais de condomnio.
Ator primrio: Sndico. Ator(es) secundrio(s): No h. Ps-condio: O valor da taxa ter sido calculado. 1. 2. 3. 4. 5. Pr-condio: Haver contas a pagar cadastradas anteriormente.
O sistema solicita o perodo de referncia da taxa a ser gerada. O sistema gera e apresenta a taxa de condomnio do perodo solicitado. O caso de uso encerrado.
No h.
Fluxo de Exceo [4]: No h conta cadastrada. a. O sistema informa que no h contas cadastradas e retorna ao item 4.
U N
RN05, RN06 e RN 07
Quadro 12 Especificao do caso de uso: Gerar Taxa de Condomnio.
IM
Fluxo Alternativo:
IN
O sndico informa o perodo.
Fluxo Principal O sndico solicita a gerao da taxa mensal de condomnio.
59
Figura 14 Diagrama de sequncia do caso de uso: Gerar Taxa de Condomnio.
U N
a) b) c)
papis so:
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o usurio solicita a gerao da taxa de condomnio de um determinado ms.
Controlador de Gerar Taxa de Condomnio: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Gerar Taxa de Condomnio, e as classes de entidade Contas a Pagar e Taxa de Condomnio.
Interface de Gerar Taxa de Condomnio: representa a classe de fronteira desse caso de uso. Disponibiliza ao sndico o formulrio para preenchimento dos dados para a gerao da taxa de condomnio de um determinado ms.
IM
IN
60
d)
e)
Taxa de Condomnio: corresponde a outra classe de entidade envolvida nesse caso de uso. Sua funo armazenar os atributos da taxa de condomnio, ms de referncia, o valor da taxa, a data de gerao e a data de vencimento da taxa de condomnio.
U N
IM
IN
61
3.6.11. Caso de Uso 11: Receber Taxa de Condomnio Esse caso de uso descreve os procedimentos que sero realizados para registrar o pagamento de contas, como mostra o quadro 13.
Nome Sumrio
Receber Taxa de Condomnio
CSU - 11
Este caso de uso descreve as etapas para realizar o registro do recebimento de taxas do condomnio.
Ator primrio: Sndico Ator(es) secundrio(s): No h Ps-condio: O pagamento da taxa registrado. Fluxo Principal Pr-condio: O valor da taxa ter sido calculado anteriormente.
1. O sndico solicita o registro de pagamento da taxa. condomnio.
2. O sistema solicita os dados para registrar o recebimento da taxa de 3. O sndico informa os dados.
4. O sistema solicita a confirmao. 6. O sistema apresenta o recibo. 7. O caso de uso encerrado.
U N
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 Exceo [3]: A taxa no foi gerada. a. O sistema informa que a taxa no foi gerada e encerra o caso de uso. Regras de Negcio Associadas
RN 08, RN09 e RN 10
Quadro 13 Especificao do caso de uso: Receber Taxa de Condomnio.
IM
5. O sndico confirma os dados.
IN
62
Figura 15 Diagrama de sequncia do caso de uso: Receber Taxa de Condomnio.
papis so: a)
U N
b) c)
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita a registrar o recebimento de taxa de condomnio.
Controlador de Receber Taxa de Condomnio: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Receber Taxa de Condomnio, e as classes de entidade Taxa de Condomnio, Lanamento Ms, Unidade e Pessoa.
Interface de Receber Taxa de Condomnio: representa a classe de fronteira desse caso de uso. Disponibiliza ao sndico o formulrio para preenchimento dos dados para o registro do recebimento da taxa de condomnio referente a uma unidade e determinado ms.
IM
IN
63
d)
Taxa de Condomnio: corresponde a uma das classes de entidade envolvida nesse caso de uso. Sua funo armazenar os atributos da taxa de condomnio, ms de referncia, o valor da taxa, a data de gerao e a data de vencimento da taxa de condomnio.
e)
Lanamento Ms: corresponde a uma das classes de entidade envolvida nesse caso de uso. Sua funo armazenar os atributos dos lanamentos financeiros, data, tipo, descrio, juros, multa e valor final.
f)
Unidade: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das unidades, o nmero da unidade, a pessoa questo. que moradora, assim como a pessoa que proprietria da unidade em
armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.
U N
IM
IN
g)
Pessoa: representa outra classe de entidade deste caso de uso. Sua funo
64
3.6.12. Caso de Uso 12: Gerar Recibo Esse caso de uso descreve os procedimentos que sero realizados para registrar o pagamento de contas, como mostra o quadro 14.
Nome Sumrio
Gerar Recibo
CSU - 12
Este caso de uso descreve as etapas para gerar o recibo de pagamento da taxa de condomnio.
Ator primrio: Sndico Pr-condio: A taxa ter sido paga. Ps-condio: O recibo foi gerado.
Fluxo Principal 1. O sndico solicita a gerao de recibo. 3. O sndico informa os dados.
2. O sistema solicita os dados para a gerao do recibo. 4. O sistema solicita confirmao. 6. O sistema gera o recibo.
7. O caso de uso encerrado.
U N
No h.
Fluxo de Alternativo:
Fluxo de Exceo: No h registro de pagamento da taxa. a. O sistema informa que no h pagamento da taxa. b. O caso de uso encerrado. Regras de Negcio Associadas
Quadro 14 Especificao do caso de uso: Gerar Recibo.
IM
IN
Ator(es) secundrio(s): No h
65
Figura 16 Diagrama de sequncia do caso de uso: Gerar Recibo.
papis so: a)
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita a gerao de recibo.
U N
b) c) d)
Controlador de Gerar Recibo: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Gerar Recibo, e as classes de entidade, Lanamento Ms, Histrico e Pessoa.
Interface de Gerar Recibo: representa a classe de fronteira desse caso de uso. Disponibiliza ao sndico o formulrio para preenchimento dos dados para a gerao do recibo da taxa de condomnio referente a uma unidade em determinado ms. Histrico: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das unidades, o nmero da unidade, a pessoa
IM
IN
66
que moradora, assim como a pessoa que proprietria da unidade em questo. e) Pessoa: representa outra classe de entidade deste caso de uso. Sua funo armazenar os atributos das pessoas cadastradas, nome; CPF e telefone. f) Lanamento Ms: corresponde a uma das classes de entidade envolvida nesse caso de uso. Sua funo armazenar os atributos dos lanamentos financeiros, data, tipo, descrio, juros, multa e valor final.
U N
IM
IN
67
3.6.13. Caso de Uso 13: Gerar Balancete Esse caso de uso descreve os procedimentos que sero realizados para registrar o pagamento de contas, como mostra o quadro 15.
Nome Sumrio
Gerar Balancete
CSU - 13
Este caso de uso descreve as etapas para gerar o balancete de determinado perodo.
Ator primrio: Sndico Pr-condio: Haver registro de movimento no perodo solicitado. Ps-condio: O balancete foi gerado.
Fluxo Principal 1. O sndico solicita a gerao de balancete. 3. O sndico informa os dados.
2. O sistema solicita os dados para a gerao do balancete. 4. O sistema solicita confirmao. 6. O sistema gera o balancete. 7. O caso de uso encerrado. Fluxo de Alternativo: No h.
U N
Fluxo de Exceo: No h registro de movimentao financeira no perodo a. O sistema informa que no h movimentao financeira no perodo. b. O caso de uso encerrado. Regras de Negcio Associadas RN 08, RN09 e RN 10
Quadro 15 Especificao do caso de uso: Gerar Balancete.
IM
IN
Ator(es) secundrio(s): No h
68
Figura 17 Diagrama de sequncia do caso de uso: Gerar Balancete.
papis so: a)
U N
b) c)
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita a gerao de balancete.
Controlador de Gerar Balancete: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Gerar Balancete, e as classes de entidade Contas a Pagar e Lanamento Ms.
Interface de Gerar Balancete: representa a classe de fronteira desse caso de uso. Disponibiliza ao sndico o formulrio para preenchimento dos dados para a gerao de um balancete de determinado perodo.
IM
IN
69
d)
Lanamento Ms: corresponde a uma das classes de entidade envolvida nesse caso de uso. Sua funo armazenar os atributos dos lanamentos financeiros, data, tipo, descrio, juros, multa e valor final.
e)
U N
IM
IN
70
3.6.14. Caso de Uso 14: Gerar Histrico Esse caso de uso descreve os procedimentos que sero realizados para registrar o pagamento de contas, como mostra o quadro 16.
Nome Sumrio
Gerar Histrico
CSU - 14
Este caso de uso descreve as etapas para gerar o histrico de determinada unidade.
Ator primrio: Sndico Ator(es) secundrio(s): No h Ps-condio: O Histrico foi gerado. Pr-condio: Haver histrico cadastrado anteriormente.
1. O sndico solicita a gerao de histrico. 3. O sndico informa os dados.
2. O sistema solicita os dados para a gerao do histrico. 4. O sistema solicita confirmao. 5. O sndico confirma os dados. 7. O caso de uso encerrado. Fluxo de Alternativo: 6. O sistema gera o histrico.
U N
No h.
Fluxo de Exceo: No h registro de histrico para a unidade a. O sistema informa que no h histrico para a unidade. b. O caso de uso encerrado. Regras de Negcio Associadas
Quadro 16 Especificao do caso de uso: Gerar Histrico.
IM
IN
Fluxo Principal
71
Figura 18 Diagrama de sequncia do caso de uso: Gerar Balancete.
papis so: a)
Menu Inicial: representa a interface de acesso s funcionalidades dos sistema. No caso, o sndico solicita a gerao de histrico.
U N
b) c) d)
Controlador de Gerar Histrico: representa a classe de controle deste caso de uso. Sua funo interpretar os comandos realizados entre o Menu Inicial, a interface de Gerar Histrico, e as classes de entidade Histrico e Pessoa.
Interface de Gerar Histrico: representa a classe de fronteira desse caso de uso. Disponibiliza ao sndico o formulrio para preenchimento dos dados para a gerao do Histrico de determinada unidade. Histrico: representa a terceira e ltima classe de entidade deste caso de uso. Sua funo armazenar os atributos das relaes entre as pessoas e as unidades. Mantendo os dados mesmo aps o trmino dessa relao. Os atributos dessa classe so: o nmero da unidade; a pessoa moradora; a data
IM
IN
72
de entrada e a data de sada do morador; a pessoa que proprietria; a data de aquisio e a data de venda relativa a esse proprietrio. e) Pessoa: representa uma das classes de entidade deste caso de uso. Sua funo armazenar os atributos das pessoas cadastradas, nome; CPF e telefone. 3.7.
PROJETO
Aps a anlise, h a definio da tecnologia e arquitetura empregadas
no desenvolvimento do sistema. Nesse trabalho, foram definidos o emprego do sero apresentados com mais detalhes no captulo 4 Arquitetura e Cdigo e captulo 6 Persistncia de Dados ficando limitado ao captulo atual a apresentao das classes de projeto e dos diagramas de sequncia gerados a partir da interao entre as classes.
estabelecidas as classes de negcio e as suas interaes atravs dos diagramas de seqncia, o processo de elaborao do projeto definiu a existncia de outras classes. De modo que, alm das classes j apresentadas, foram includas no projeto as seguintes classes: UsuarioEntidade; HibernateUtil; LoginBO; LoginCO; Login2;
IM
U N
LoginDAO; PessoaBO; PessoaDAO; PessoaHibernateDAO;
A documentao apresentada a seguir foi gerada por engenharia reversa se utilizando a ferramenta MDG que integra o Eclipse ao Enterprise Architect.
IN
Desta forma, aps definidos os requisitos; os casos de uso;
UnidadeBO; UnidadeDAO; UnidadeHibernateDAO; HistoricoBO; HistoricoDAO. HistoricoHibernateDAO; CadastrarPessoaAction e PesquisarAction.
business object, de classes action e do data access object, esses componentes
73
Assim,, a partir do cdigo foram elaborados os diagramas estticos, respeitando os pacotes com os quais a aplicao foi organizada. As classes de negcio e a classe UsuarioEntidade foram agrupadas no pacote entidade como mostra a figura 19.
U N
Figura 19 Classes do pacote entidades.
IM
IN
74
No pacote bo se concentraram as seguintes classes: LoginBO; PessoaBO; UnidadeBO e HistoricoBO (Figura 20).
Figura 20 Classes do pacote bo.
classe HibernateUtil, esto presentes no pacote DAO, como representado pela figura 21.
U N
Figura 21 Classes do pacote persistncia.
IM
As classes de persistncia, aquelas com terminao DAO e, ainda, a
IN
75
E figura 22.
finalmente,
as
classes
Login2;
CadastrarPessoaAction
PesquisarAction esto localizadas em um mesmo pacote como apresentado na
U N
Figura 22 Classes do pacote action.
IM
IN
76
3.7.1.
Diagramas de Sequncia de Projeto Os diagramas de sequncia em nvel de projeto envolvem as classes
de negcio e, tambm, as classes criadas para o desenvolvimento, considerando a tecnologia escolhida para a implementao do aplicativo.
3.7.1.1
Caso de Uso 01: Fazer Login Esse diagrama ilustra os passos do sistema para realizar o login do
usurio ao sistema, como mostra a figura 23.
U N
IM
IN
77
Figura 23 Diagrama de sequncia com as classes de projeto do caso de uso: Fazer Login.
U N IM IN A S
78
3.7.1.2
Caso de Uso 02: Cadastrar Dados Esse diagrama apresenta a sequncia e a comunicao entre as
classes de projeto do sistema para cadastrar os dados dos moradores e proprietrios de unidades do condomnio, como apresentado na figura 24.
U N
IM
IN
79
Figura 24 Diagrama de sequncia com as classes de projeto do caso de uso: Cadastrar Dados.
U N IM IN A S
80
3.7.1.3
Caso de Uso 03: Listar Pessoas A sequncia realizada pelo sistema para listar as pessoas cadastradas
no sistema est ilustrada na figura 25.
U N
IM
IN
81
Figura 25 Diagrama de sequncia com as classes de projeto do caso de uso: Listar Pessoas.
U N IM IN A S
82
3.7.1.4
Caso de Uso 04: Consultar Pessoa O comportamento do sistema e as classes envolvidas na realizao do
caso de uso Consultar Pessoa esto representados na figura 26.
U N
IM
IN
83
Figura 26 Diagrama de sequncia com as classes de projeto do caso de uso: Consultar Pessoa.
U N IM IN A S
84
3.7.1.5
Caso de Uso 05: Consultar Unidade Esse diagrama apresenta as classes envolvidas e a relao entre elas
para a realizao do caso de uso Consultar Unidade (Figura 27).
U N
IM
IN
85
Figura 27 Diagrama de sequncia com as classes de projeto do caso de uso: Consultar Unidade.
U N IM IN A S
86
3.7.1.6
Caso de Uso 06: Atualizar Histrico Esse diagrama representa o comportamento do sistema para realizar o
caso de uso Atualizar Histrico (Figura 28).
U N
IM
IN
87
Figura 28 Diagrama de sequncia com as classes de projeto do caso de uso: Atualizar Histrico.
U N IM IN A S
88
4.
ARQUITETURA E CDIGO
Orlando Alves de Oliveira
Com a crescente necessidade de automao de processos para melhor desempenho na execuo das tarefas se aumentou, tambm, a utilizao de software dentro de vrios setores de uma organizao para apoiar as rotinas dirias, Diante desse cenrio foi desenvolvida uma aplicao especfica para o Condomnio do Edifcio Porto Seguro com o objetivo de apoiar a administrao deste condomnio, permitindo o acompanhamento de sua ocupao bem como gesto financeira da manuteno mensal do imvel. Para essa aplicao o padro de de apresentao, negcios e integrao. utilizado foi de desenvolvimento em camadas para que fique separado por mdulos A arquitetura de software a maneira como est estruturado o sistema, ou seja, quais os componentes esto presentes e as relaes entre esses componentes (AHMED & UMRYSH, 2002). Atravs do modelo de arquitetura o desenvolvedor visualiza com mais facilitando, assim, o entendimento e a manuteno 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 aplicao bem estruturada e de
U N
Hibernate. 4.1.
fcil manuteno. Portanto no desenvolvimento do sistema do Edifcio Porto Seguro foi utilizada a linguagem de programao Java, aplicando-se a programao orientada a objetos alm do uso da arquitetura em trs camadas MVC (Model, View, Controller), plataforma J2EE, atravs do Eclipse e com os framewoks Struts e
desenvolvida por uma equipe comandada por James Gosling na Sun Microsystens
na dcada de 90.
IM
JAVA
facilidade o funcionamento do sistema, como sero dispostos os seus componentes,
uma linguagem de programao de alto nvel orientada a objetos
IN
89
Essa linguagem foi projetada para ser pequena, simples e portvel a todas as plataformas e sistemas operacionais e, ainda, integrada Internet, Java, tambm, uma excelente linguagem para desenvolvimento de aplicaes em geral (APOSTILA, 2009). Por se tratar de uma linguagem orientada a objeto, necessrio o conhecimento desse paradigma para us-la adequadamente. compilada para bytecode que executado pela JVM (Java Virtual Machine) responsvel por administrar a memria e possui um coletor de lixo automtico. O compilador e a JVM esto disponveis no JDK (Java Development Kit) kit de desenvolvimento Java. De acordo com Wikipedia (2009a):
Java ainda um standard de fato, que controlada atravs da JCP Java Community Process. Em 13 de Novembro de 2006, a Sun lanou 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 cdigo Java como software de cdigo aberto, menos uma pequena poro da qual a Sun no possui copyright.
4.2.
ARQUITETURA MVC
projetos de software. Sendo assim no sistema do Edifcio Porto Seguro foi utilizada a arquitetura MVC que um modelo de aplicao em trs camadas, nesse modelo as responsabilidades ficam divididas.
aplicao, mas no deixando de integr-las. Segundo Alur, Crupi e Malks (2004, p.102):
Uma camada equivale a um dos particionamentos lgicos dos diversos aspectos tratados em um sistema. A cada camada atribuda sua responsabilidade distinta, ou nica, no sistema. Visualizamos cada camada como separadas logicamente entre si. Cada camada no est estritamente acoplada com a camada adjacente.
U N
mdulos:
-
facilitada. Este modelo descreve a organizao de uma aplicao em trs Model (Modelo): compreende o modelo de aplicao, contendo a
representao de dados e de lgica de negcios, onde ficam as classes de persistncia, business object, entidades e DAO (Data Access Objetct);
-
View (Apresentao): trata aspectos relacionados apresentao e formulrios entrada de dados de usurio que so as pginas de visualizao JSP (Java Server Pages);
IM
A arquitetura MVC (Model-View-Controller) separa em camadas a
Sendo assim, as camadas trabalham juntas e a manuteno do cdigo
IN
O aumento do uso de aplicaes distribudas prov mudanas nos
90
Controller (Controle): responsvel por despachar requisies e controlar os seus fluxos, onde implementado o Front Controller atravs do framewok Struts na classe action e no arquivo struts.xml. Com o emprego do modelo MVC foi possvel centralizar a lgica de
despachar requisies em uma classe action, simplificando a implementao do controle de segurana e acesso ao sistema. Para facilitar o uso do Modelo MVC, foi utilizado o framework Struts, cujo cdigo aberto fornece componentes de controle, e Hibernate que responsvel pelo mapeamento objeto relacional com o banco de dados. A figura 29 apresenta o modelo dessa arquitetura:
U N
4.3.
Figura 29 Modelo Arquitetura MVC.
problemas recorrentes no desenvolvimento de aplicativos. Representam um conjunto de descries de problemas que so encontrados durante o processo do desenvolvimento das aplicaes com as suas respectivas solues para esses problemas. (ALUR, CRUPI & MALKS, 2004). A utilizao de padres em softwares popularizou-se com o livro Design Patterns: Elements of Reusable Object-Oriented Software cujos autores so conhecidos como a Gangue dos Quatro (Gang of Four - GoF). Trata-se de um
IM
PADRES DE PROJETO
Padres de projeto so solues que podem ser reutilizadas para
IN
91
catlogo com desenhos de padres que podem ser agregados ao software (MARTINS, 2006). Os padres de projeto so responsveis por apresentar como ser o funcionamento entre os componentes do sistema, definindo-se atravs do padro quais so as responsabilidades e como se relacionam as entidades do projeto. A definio 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 padres de projeto. No software em questo foram empregados os seguintes padres: Business Object, Data Access Object e Front Controller implementado pelo framework Struts.
4.3.1.
DAO
o cdigo de acesso aos dados fique separado da lgica de negcios. persistente gerenciando a conexo com o banco de dados para armazenar e consultar dados. Geralmente se tornam objetos leves porque so implementados como objetos sem nenhuma execuo de consulta. Com o uso desse padro os detalhes de implementao do banco de dados ficam ocultos, por isso pode haver alterao de banco de dados sem que implique em grandes mudanas na estrutura do sistema.
U N
4.3.2.
(ALUR, CRUPI & MALKS, 2004). Na construo de software com utilizao de mapeamento objeto
relacional e DAO, a linguagem do banco de dados torna-se transparente para o desenvolvedor, pois operaes do banco so assumidas pelo framework. Assim, toda a manipulao de dados feita atravs dos objetos instanciados, o que propicia maior facilidade no caso de necessidade de troca do banco de dados. Esse padro ser descrito com mais detalhes no captulo 6.
Java se comunica com o DAO o padro eleito para fazer a persistncia com o banco
IM
Business Object
informaes de estado e tambm no armazenam em cach os resultados de
So objetos Java que contm dados de negcios, ou seja, um objeto
IN
Esse padro abstrai e encapsula o acesso ao armazenamento
O DAO utilizado para persistncia de objetos Java fazendo com que
92
de dados. Esse padro permite que a lgica de negcios fique separada da lgica de persistncia, usando-se um objeto. A figura 30 mostra o cdigo da classe PessoaBO.
dao.insert(pes);} }
Figura 30 Classe PessoaBO.
Na classe pessoaBO criado um objeto do tipo PessoaDAO e a partir desse objeto so chamados mtodos que fazem operaes como inserir, pesquisar e deletar que so mtodos da classe DAO responsvel pela persistncia no banco de dados. Portanto o business object mantm os dados de negcio e implementa
U N
PessoaBO. 4.3.3. solicitaes.
comportamentos comuns a toda aplicao, descritos nos mtodos da classe
nico de entrada, o que permite o gerenciamento das atividades de tratamento das
cdigo, ou seja, no h necessidade de repetio da lgica de controle a mesma lgica pode ser usada para vrias solicitaes.
IM
Front Controller
um padro onde a lgica de controle fica centralizada em um ponto
Com a utilizao do Front Controller possvel a reutilizao do
IN
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) {
93
Portanto, em um sistema, o padro Front Controller o primeiro contato, responsvel por tratar as solicitaes. A partir da sero delegadas funes para que seja executado o gerenciamento de ao e visualizao.
4.3.4.
Application Controller O Application Controller um padro utilizado para centralizar a
recuperao e chamada dos componentes de solicitao que podem ser comandos ou pginas de visualizao. Esse padro responsvel pelo gerenciamento da ao e
atendimento de uma solicitao e o gerenciamento de visualizao, cuja funo localizar e distribuir a visualizao solicitada.
Tanto o padro Front Controller como o Application Controller so implementados pelo framework Struts. 4.4. 4.4.1.
TECNOLOGIAS UTILIZADAS
Servlet
especficos do protocolo http. Ele recebe uma requisio e apresenta uma resposta em seguida. Toda vez que recebe uma requisio iniciado um mtodo chamado service().
U N
executado quando o servlet carregado, existem os mtodos de servio que so chamados pelo web server como service(), doGet(), doPost(), dentre outros. O mtodo destroy chamado antes de encerrar a requisio ao servlet. A figura 31 a seguir mostra o ciclo de vida de um servlet.
IM
Servlet uma classe Java que acessa uma API com servios
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 solicitao e apresenta uma resposta. Mas, diferente dos servidores web convencionais, a interface de programao da aplicao (API) do servlet designada especificamente para ajudar os desenvolvedores Java a criarem aplicaes dinmicas.
No ciclo de vida do servlet na primeira invocao o mtodo init()
IN
visualizao, onde o gerenciamento da ao est relacionado s rotas que para
94
Java Server Pages (JSP) uma tecnologia para desenvolvimento de aplicaes que permite a captura de informaes atravs de formulrios. Pode ser aplicao. Quando uma pgina JSP requisitada pelo usurio no browser, esta pgina executada pelo servidor, e, ento, gerada uma pgina HTML, atravs de do processo de renderizao, e em seguida, essa pgina enviada ao browser do usurio. As pginas JSP contm cdigo HTML comum e se diferenciam pelo uso das tags que representam instrues Java. Na figura 32 apresentado o cdigo da pgina facilmente codificado, facilitando o desenvolvimento e tambm manuteno de uma
U N
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">
IM
IN
4.4.2.
Pginas JSP
Figura 31 Ciclo de vida do servlet. Adaptado de Angoti (2009a).
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>
U N
Figura 32 Cdigo da pgina consultarPessoaForm.jsp.
anteriormente, ter como resultado a exibio na tela do browser da pgina
pesquisarPessoa.jsp (Figura 33).
IM
Assim, a execuo da funo consultar pessoa que foi apresentado
IN
96
Figura 33 Pgina pesquisarPessoa.jsp
4.4.3.
JDBC
permite o acesso ao sistema de gerenciamento de banco de dados (SGBD) atravs de comandos SQL (Structured Query Language). Essa API est contida no pacote java.sql, com a sua utilizao no h necessidade do uso de um banco especfico, ou seja, o sistema desenvolvido fica independente acessando qualquer banco de dados (TOOD & SZOLKOWSK, 2003). No sistema do Edifcio Porto Seguro foi utilizado o JDBC juntamente com a utilizao do framewok Hibernate para fazer o mapeamento objeto relacional com o banco de dados atravs do DAO (Data Access Object). 4.5.
U N
J2EE
contm especificaes sobre implementaes de softwares desenvolvidos utilizando a linguagem de programao Java. voltado para o desenvolvimento de aplicativos multicamadas baseando-se em componentes que so executados em um servidor de aplicao (DIAS e BORBA, 2002). No J2EE esto contidas API utilizadas na implementao do sistema do Edifcio Porto Seguro que so servlets, JSP (Java Server Pages) e JDBC (Java Database Connectivity).
IM
J2EE (Java Enterprise Edition) um padro de desenvolvimento que
IN
Java Database Conectivity (JDBC) uma API da linguagem Java que
97
As aplicaes que utilizam o padro J2EE seguem o modelo arquitetural em camadas. em camadas, onde em cada camada est atribuda uma responsabilidade diferente. Como se pode notar na figura 34 que mostra a diviso
elementos exibidos ao usurio. Essa camada intercepta as solicitaes do usurio e faz o controle do que ser exibido como resposta s requisies. Esto nessa propriamente dita so responsveis pela criao destas. Tambm, est presente nessa camada o Front Controller, implementado pelo framework Struts, que as aes para cada requisio. responsvel por controlar e redirecionar as requisies feitas pelo usurio e delegar
negcios. Ela foi implementada com a utilizao de Business Object que tem por
U N
4.6.
funo separar os dados e a lgica de negcios atravs de um objeto Java. Por fim, a camada de integrao responsvel por fazer a comunicao com o SGBD (Sistema de gerenciamento de banco de dados). Nessa camada foi utilizado o DAO para abstrair o acesso ao banco de dados atravs do mapeamento objeto relacional.
que foi utilizado como servidor web no projeto do software do Edifcio Porto Seguro. Ele implementa as especificaes servlet e JSP. Com o uso do Tomcat foi possvel obter algumas vantagens dentre elas se destacam:
IM
TOMCAT
J, na camada de negcios esto presentes os dados e a lgica de
O Tomcat 5.5 um container servlet da Apache Software Foundation
IN
camada as pginas JSP e os servlets, que embora no sejam a interface
Na camada de apresentao encontra-se a lgica de apresentao dos
Figura 34 Modelo em camadas. Adaptado de Alur, Crupi e Malks (2004)
98
Otimizao de performance; Otimizao e reduo do coletor de lixo; Melhoria no tratamento de taglibs; Gerenciamento da aplicao e do servidor.
(ANGOTI JR, 2009c). 4.7. 4.7.1.
IMPLEMENTAO
Struts um framework mantido pela Apache Software Foundation alm de
desenvolvido entre o ano de 2000 e 2001 onde mais de 30 desenvolvedores 2004).
O Struts responsvel por implementar o Front Controller que faz a centralizao da lgica de controle, promovendo tambm reutilizao de cdigo porque no ser necessrio cdigo de controle em vrias pginas de visualizao. As responsabilidades ficam bem definidas facilitando a manuteno. Na figura 35 apresentao. possvel ver o funcionamento do Front Controler que atua na camada de
U N
Figura 35 Front Controller Adaptado de Angoti (2009b)
IM
IN
contriburam para a sua criao (DUMOULIN, FRANCISCUS, WINTERFELDT,
outros projetos j criados tais como o Tomcat. O cdigo inicial do Struts foi
99
O controlador o ponto central de todas as requisies feitas pelo cliente e a partir dele que vai ser definida qual pgina view que vai ser exibida. O Command Helper mostrado na figura acima representa comandos ou mtodos que sero executados de acordo com o nome da ao definida. No Sistema para Gesto de Condomnio o Command Helper representado pelas classes action que possuem mtodos que so executados de acordo com a requisio do cliente. Para o correto funcionamento do framework Struts criado um arquivo apresenta um trecho do cdigo desse arquivo.
U N
<!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">  ... <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.
classe utilizada e do mtodo. O resultado tambm mapeado, no caso da ao consultarUnidade mostrada na figura 8 caso o resultado seja success ser exibida a
pgina unidade.jsp. Porm, se o resultados for erro a pgina a ser mostrada ser erro.jsp. O resultado dessa ao est definido no cdigo do mtodo consultaUnidade da classe PesquisarAction (Figura 37).
IM
Pode-se notar que o mapeamento feito atravs do nome da ao, da
IN
chamado struts.xml onde so feitos os mapeamento das aes. A figura 36
100
... public String consultaUnidade() { unidade = uniService.getUnidade(numero); if (unidade != null) { return "success"; } else { addActionError("Unidade no existe!"); return "erro"; } } ...
Figura 37 Mtodo consultaUnidade.
Assim, o Front Controller implementado atravs do Struts faz o controle das aes e resultados que sero exibidos atravs do direcionamento das aes de acordo com a solicitao feita pelo usurio.
4.7.2.
Diagrama de Pacotes
Os diagramas de pacotes do sistema foram gerados pelo Omondo o processo de engenharia reversa para gerao desses diagramas, onde a partir do cdigo fonte foi possvel 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.
U N
Figura 38 Diagrama de pacotes.
IM
IN
Eclipse UML que um plugin que auxilia a gerao de diagramas UML. Foi utilizado
101
No pacote entidades esto as classes utilizadas para criar os objetos que sero manipulados pela aplicao, as classes desse pacote so: UsurioEntidade, LoginCO, Pessoa, Unidade e Histrico(Figura 39).
Figura 39 Classes do pacote entidades.
No pacote bo esto as classes de negcio da aplicao, ou seja, atravs de mtodos que esto contidos nas classes do tipo BO so passados os objetos de entidades para que sejam executadas as operaes pelas classes DAO (Figura 40).
U N
J, implementados
IM
Figura 40 Classes do pacote bo.
no nas
IN
pacote classes persistncia
A
esto as interfaces PessoaDAO, e UnidadeHibernateDAO
UnidadeDAO, HistoricoDAO, essas interfaces contm os mesmo mtodos que so PessoaHibernateDAO, Histrico HibernateDAO e tambm a classe LoginDAO que implementam as
102
operaes que sero executadas no banco de dados atravs do framework hibernate, j a classe HibernateUtil criada pelo framework hibernate (Figura 41)
Figura 41 Classes do pacote persistncia.
mtodos que so mapeados no struts.xml para realizar determinadas aes. As classes so: Cadastrar PessoaAction, PesquisarAction e Login2 (Figura 42).
U N
Figura 42 Classes do pacote action.
IM
E finalmente, no pacote action esto as classes Java que contm
IN
103
Percebe-se que os pacotes retratam a maneira de como esto dispostas as classes da aplicao, o que deixa o cdigo mais organizado e auxilia no caso de novas implementaes ou alteraes no sistema.
4.7.3.
Implementao do Caso de Uso Cadastrar Dados Para apresentar o funcionamento do modelo em camadas e visualizar
a interao entre os padres utilizados no sistema do Edifcio Porto Seguro, ser pessoa, unidade e histrico. Essa demonstrao parte das premissas de que a pendncias para a unidade. A figura 43 mostra a tela principal do sistema do Edifcio Porto Seguro onde selecionada a opo Cadastrar Dados.
U N
Figura 43 Pgina Principal.
IM
IN
pessoa em questo no foi cadastrada anteriormente e que no h histrico com
usado como exemplo o Caso de Uso 02 Cadastrar Dados que utiliza as entidades
104
Ao ser selecionada a opo cadastrar dados, executa-se uma action que foi mapeada no arquivo struts.xml com o nome de setUpForInsertOrUpdate, o trecho de cdigo 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 ao nomeada como setUpForInsertOrUpdate no arquivo struts.xml CadastrarPessoaAction do pacote action, como apresentado no trecho de cdigo abaixo (Figura 45).
...
Figura 45 Mtodo setUpForInsertOrUpdate() implementado na classe CadastrarPessoaAction.
do tipo combo box na pgina onde sero exibidos os nmeros das unidades existentes no condomnio e retorna success que foi mapeado no arquivo struts.xml para exibir a pgina de cadastro de dados, como mostrado na figura 46.
U N
IM
Nessa classe existe um mtodo prep() que preenche um componente
Figura 46 Tela de Cadastro de Dados.
IN
public class CadastrarPessoaAction { ... public String setUpForInsertOrUpdate() { prep(); return "success"; }
invoca
mtodo
setUpForInsertOrUpdate()
que
est
na
classe
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.
uma classe Java contendo os objetos e mtodos relacionados ao cadastro de cdigo do mtodo 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(); }
U N
} } ...
Figura 48 Mtodo InsertOrUpdate implementado na classe CadastrarPessoaAction.
IM
return "success";
IN
dados, alm dos mtodos das validaes feitas pelo sistema. A seguir mostrado o
O mtodo insertOrUpdate() est na classe CadastrarPessoaAction que
106
Primeiramente feita a verificao dos dados inseridos no formulrio atravs do mtodo validationSuccessfull() que est na classe CadastrarPessoaAction, que valida os campos preenchidos no formulrio. Se no houver a validao, uma pgina de erro retornada. Caso a validao seja positiva, ser verificada, ento, as opes selecionadas atravs de componente do tipo radio button, que se encontra na pgina de cadastro de dados. As opes disponveis so proprietrio definindo em seguida se aquisio ou venda e, ainda, morador acompanhado de entrada ou sada de um apartamento. Ser apresentado o processo de cadastro de uma aquisio de um apartamento, a condio que considera a opo aquisio selecionada. Nesse caso chamado o mtodo gravaPropAquisicao(). Nesse mtodo, esto envolvidas as entidades pessoa; unidade e histrico e as variveis pesAux e pessoa, que so do permite verificar se j existe uma pessoa cadastrada com o CPF informado. Caso nulo nesse objeto (Figura 49). tipo Pessoa e pesService do tipo PessoaBO. A linha de cdigo mostrada abaixo exista, grava o objeto pessoa correspondente no objeto pesAux, seno grava valor
U N
Figura 49 Mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction.
histAux que correspondem objetos do tipo unidade e histrico respectivamente. Em seguida, verificado se a unidade j tem proprietrio cadastrado, isso feito atravs do mtodo getProprietrio() que est na classe Unidade. Se houver proprietrio cadastrado, retornada uma mensagem como pode ser visto no trecho de cdigo apresentado na figura 50.
IM
public class CadastrarPessoaAction { ... public void gravaPropAquisicao() { pesAux = pesService.getPessoa(pessoa.getP_cpf()); unidade = uniService.getUnidade(unidade.getU_numero()); histAux = histService.getHistorico(historico.getId()); ...
Esse mesmo procedimento feito tambm com os objetos unidade e
IN
107
public class CadastrarPessoaAction{ ... public void gravaPropAquisicao{ ... if ((pesAux != null || pesAux == null) && unidade.getProprietario() != null) { addActionMessage("A unidade "+unidade.getU_numero()+"j proprietrio\n CADASTRO NO EFETUADO!"); ... tem
Figura 50 Mensagem de erro gerada pelo mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction.
Se a pessoa no tiver sido cadastrada anteriormente e a unidade no possuir proprietrio, o registro de pessoa gravado da seguinte forma, um objeto do tipo PessoaBO chamado pesService j instanciado, passa atravs do mtodo insertPessoa(), que pertence a classe PessoaBO, o objeto pessoa criado, quando submeteu-se os dados do formulrio (Figura 51).
Figura 51 Comando de persistncia declarado no mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction.
U N
seguir (Figura 52).
} ...
construtor dessa classe o objeto do tipo pessoaDAO instanciado como mostrado a
public class PessoaBO { private PessoaDAO dao; public PessoaBO() { this.dao = new PessoaHibernateDAO();
Figura 52 Comando gerao do objeto pessoaDAO declarado no construtor da classe PessoaBO.
IM
public class CadastrarPessoaAction{ ... public void gravaPropAquisicao{ ... if (pesAux == null && unidade.getProprietario() == null) { // grava pessoa pesService.insertPessoa(pessoa); ...
Na classe PessoaBO criada uma varivel do tipo PessoaDAO e no
IN
108
Na classe PessoaBO o mtodo insertPessoa() recebe um objeto do tipo pessoa e passa esse objeto para a classe PessoaHibernateDAO, que contm o mtodo insert(), como mostra a figura 53.
public class PessoaBO { ... public void insertPessoa(Pessoa pes) { dao.insert(pes); } ...
Figura 53 Chamada do mtodo insert() atravs do mtodo insertPessoa() implementado na classe PessoaBO.
Esse mtodo recebe o objeto pessoa criado e executa a gravao dos
U N
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 Cdigo do mtodo insert() implementado pela classe PessoaHibernateDAO.
atualizada, primeiro atualizado o campo proprietrio da unidade atravs do mtodo setProprietrio(), que pertence a classe Unidade, e ento um objeto do tipo UnidadeBO chamado uniService passa atravs do mtodo updateUnidade(), que
IM
Depois de gravar a pessoa no mtodo gravaPropAquisicao() a unidade
IN
dados na tabela de pessoas do banco de dados (Figura 54).
109
pertence a classe UnidadeBO, o objeto unidade que foi atualizado. O trecho de cdigo que faz esta operao mostrado a seguir (Figura 55).
public class CadastrarPessoaAction{ ... public void gravaPropAquisicao{ ... // atualiza unidade unidade.setProprietario(pessoa); uniService.updateUnidade(unidade); ...
Na classe UnidadeBO criado um objeto do tipo UnidadeDAO e no na figura 56 a seguir.
Figura 56 Comandos de criao do objeto UnidadeHibernateDAO declarado no construtor da classe UnidadeBO.
U N
} ...
tipo unidade e passa esse objeto para a classe UnidadeHibernateDAO que contm um mtodo chamado updateUnidade() apresentado na figura 57.
public class UnidadeBO{ ... public void updateUnidade(Unidade u){ dao.updateUnidade(u);
Figura 57 Comandos do mtodo updateUnidade() implementado pela classe UnidadeBO.
IM
public class UnidadeBO { private UnidadeDAO dao; public UnidadeBO() { this.dao = new UnidadeHibernateDAO(); } ...
O mtodo updateUnidade() da classe UnidadeBO, recebe um objeto do
IN
construtor dessa classe o objeto do tipo unidadeDAO instanciado como mostrado
Figura 55 Comandos do mtodo gravaPropAquisicao() implementado pela classe CadastrarPessoaAction.
110
O mtodo updateUnidade() da classe, recebe o objeto do tipo unidade e executa a atualizao 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 Cdigo do mtodo updateUnidade() implementado pela classe UnidadeHibernateDAO.
gravaPropAquisicao(). verificado se h um histrico com o mesmo cdigo que foi informado no formulrio de cadastro. Se j existir, o objeto histrico ser atualizado pelos mtodos setters da classe histrico e repassado ao BO atravs de uma objeto do tipo HistoricoBO chamada histService atravs do mtodo
U N
updateHistorico()., como ilustrado pela figura 59.
public class CadastrarPessoaAction{ ... public void gravaPropAquisicao{ ... // se j existir um histrico com o cdigo 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());
IM
Por
fim,
IN
feita a gravao
A
do histrico, atravs mtodo
111
historico.setProprietario(unidade.getProprietario()); histService.updateHistorico(historico); } ...
Figura 59 Comando de persistncia declarado no mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction, quando j h histrico da unidade.
Na classe HistoricoBO criada uma varivel do tipo HistoricoDAO e no construtor dessa classe um objeto do tipo historicoDAO instanciado como mostrada na figura 60 a seguir.
O mtodo updateHistorico() recebe um objeto do tipo historico e passa 61).
U N
public class HistoricoBO{ ... public void updateHistorico(Historico hist){ dao.updateHistorico(hist); } ...
Figura 61 Comandos do mtodo updateHistorico() implementado pela classe HistoricoBO.
o objeto do tipo histrico e executa a atualizao dos dados na tabela de histricos do banco de dados (Figura 62).
IM
esse objeto para o DAO que contm um mtodo chamado updateHistorico (Figura
O mtodo updateHistorico() da classe HistoricoHibernateDAO recebe
IN
Figura 60 Comandos de criao do objeto HistoricoHibernateDAO declarado no construtor da classe HistoricoBO.
public class HistoricoBO { private HistoricoDAO dao; public HistoricoBO() { this.dao = new HistoricoHibernateDAO(); } ...
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 { } } ...
Seno houver histrico criado anteriormente com o cdigo informado na tela de cadastro de dados um novo objeto do tipo histrico criado e repassado mtodo insertHistorico(), como mostra a figura 63. ao BO atravs de uma varivel do tipo HistoricoBO chamada histService pelo
U N
...
public class CadastrarPessoaAction{ ... public void gravaPropAquisicao{ ... // se no existir um histrico com o cdigo digitado cria um novo // registro de histrico no banco else { historico.setProprietario(pessoa); historico.setNumero(unidade); historico.setH_proAquiscao(data); histService.insertHistorico(historico); }
Figura 63 Comando de persistncia declarado no mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction, quando no h histrico da unidade.
IM
IN
Figura 62 Cdigo do mtodo updateHistorico() implementado pela classe HistoricoHibernateDAO.
113
O mtodo insertHistorico(), que est na classe Histrico BO, recebe um objeto do tipo historico e passa esse objeto para o DAO que contm um mtodo chamado insertHistorico(), como apresentado na figura 64.
public class HistoricoBO{ ... public void insertHistorico(Historico hist) { dao.insert(hist); } ...
Figura 64 Comando declarado no mtodo insertHistorico() implementado na classe HistoricoBO.
objeto do tipo Histrico e executa a insero dos dados na tabela de histricos do Hibernate (Figura 65).
public class HistoricoHibernatedDAO { ...
U N
} ...
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)
Figura 65 Cdigo do mtodo insert() implementado na classe HistoricoHibernateDAO.
que ser exibida ao usurio com confirmao de dados gravados. Essa mensagem criada atravs do mtodo addActionMessage(), como apresentado na figura 66.
IM
tx.rollback(); throw e; } finally { // session.close(); }
A seguir est apresentado o cdigo para a gerao de uma mensagem
IN
banco com o mapeamento objeto relacional realizado atravs do framework
O mtodo insertHistorico() da classe HistoricoHibernateDAO recebe o
114
public class CadastrarPessoaAction{ ... public void gravaPropAquisicao{ ... addActionMessage(pessoa.getP_nome() unidade.getU_numero()); ...
"
Proprietrio
da
unidade
"
Figura 66 Mensagem de sucesso gerada pelo mtodo gravaPropAquisicao() implementado na classe CadastrarPessoaAction.
Ao trmino da execuo do mtodo gravaPropAquisicao(), o mtodo 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"; } } ...
U N
... ...
exibir uma pgina JSP, como mostra a figura 68.
Figura 68 Action insertOrUpdate mapeada no arquivo struts.xml.
IM
Figura 67 Cdigo do mtodo isertOrUpdate() implementado na classe CadastrarPessoaAction.
O retorno da String success est mapeado no arquivo struts.xml para
<action name="insertOrUpdate" method="insertOrUpdate" ... <result name="success">/page/sucesso.jsp</result> ... </action>
IN
115
O caso de uso termina com a apresentao da pgina sucesso.jsp (Figura 69), que contm a mensagem adicionada pelo mtodo gravaPropAquisio() atravs do mtodo addActionMessage().
Figura 69 Tela de confirmao de cadastro.
importante ressaltar que se a pessoa em questo j estiver cadastrada no sistema, a parte do cadastro de dados da pessoa no ser realizada pelo software. Sero executados, apenas, os comandos de atualizao da unidade e insero ou atualizao do histrico daquela unidade.
U N
IM
IN
116
5.
INTERFACE Embora seja parte do software, a interface, para o usurio, confunde-se
com o sistema, muito embora seja apenas a parte do sistema que traduz as aes do usurio em ativaes das funcionalidades do sistema. um componente fundamental para o usurio 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 influncia no sucesso comercial de um software. se no trabalho que dever executar. Para isso, uma interface deve ser amigvel e apresentar usabilidade. Para atingir esses objetivos, ela dever apresentar as seguintes caractersticas: ser de fcil uso; ser fcil de aprender o seu manuseio; apresentar taxa mnima de erro; favorecer a recordao rpida; ser atrativa; usurio com o tempo (ASCENIO, 1999). apresentar alta velocidade na execuo de tarefas; gerar satisfao e reteno do De acordo com Ferreira (2009), a interface estabelece uma interao do homem com o sistema atravs de um meio visual. O indivduo recebe e interpreta a informao visual com base no tamanho, forma, cor e outras caractersticas. Uma especificao adequada da comunicao visual o elemento chave para obteno de uma interface amigvel. A cor um componente que merece um estudo especial quando se trata de comunicao, assim, a escolha das cores de uma interface deve ser feita com cautela. natural a associao de cores a diversas situaes ou elementos, tanto que se faz uso de cores para indicar condies diversas: perigo, ateno, 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, tambm, fator decisivo para a escolha das cores, as crianas mais novas so normalmente atradas por cores vibrantes. Desta forma, o design de interfaces deve se beneficiar dessas informaes, selecionando as cores atrativas ao perfil do usurio do sistema. A interface deve ser invisvel e intuitiva, pois o usurio deve concentrar-
U N
IM
IN
117
As cores tm indicaes relacionadas ao significado cultural e tambm s percepes visuais que determinam. Assim a escolha de cores para compor uma interface grfica deve considerar alguns fatores, como os descritos a seguir. Branco a cor que possui a maior leveza ao atrair a ateno para um fundo escuro, de modo que fornece a mxima legibilidade para um texto escuro, embora o brilho possa causar problemas ao se olhar para ela por um perodo prolongado. No recomendada para os cantos de interface e como estreita moldura de imagens, valoriza a figura. Preto todas elas. As superfcies pretas se tornam mais negras medida que o nvel de torne reas coloridas mais claras e amplas. Torna-se mais legvel quando em contraste com fundos claros, apesar de ser necessrio o uso de fontes em negrito quando se usa texto negro em um fundo branco. Linhas pretas so eficientes ao se separar reas coloridas atravs de um aumento da fronteira de contraste. Para uma boa reproduo de imagens, desejvel ter-se um preto slido de modo a estabelecer o limite da variao tonal.
apresentam seu colorido mximo quando contrastando com cinza escuro.
U N
de sucesso.
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, no frequentemente empregada em softwares As cores podem ser classificadas em cores quentes (amarelo, laranja e
vermelho) e cores frias (azul, turquesa e violeta). O verde e o magenta so considerados cores marginais, pois seu carter est na dependncia das cores adjacentes, se esta for uma cor fria, ento aqueles aparentaram quentes. Da mesma forma, se as cores do em torno forem quentes o verde e o magenta assumiro o carter de cores frias.
IM
Cinza
Reduz as conotaes emocionais. Combina com todas as cores, que
Das cores acromticas (branco, preto e cinza) o cinza uma boa cor
IN
iluminao aumenta. Contrastes simultneos fazem com que um contorno preto
Atua como estimulante para as demais cores e se harmoniza bem com
118
Para a criao de um ambiente harmonioso necessrio haver o equilbrio contrastando cores quentes com cores frias, de modo a torn-lo mais agradvel. Vermelho Apresenta o maior significado emocional a despeito da cultura, provavelmente devido sua associao com o sangue e o fogo, portanto com a guerra. muito eficiente quando usada nas interfaces para sinalizar algum perigo ou chamar a ateno, como por exemplo, bordas vermelhas de sinais de advertncia so rapidamente percebidas. Apresenta grande qualidade acolhedora. Sua associao imediata com sendo adequada para indicar a janela. Como cor de texto requer fundo preto ou azul escuro. Verde
A idia de que a plantao significa uma certa estabilidade levou associao do verde com o sentimento de segurana. mente, enquanto que o verde em excesso resulta em uma aparncia doentia. Est indicada quando se deseja passar rapidamente uma informao, sendo tambm, recomendada para informar que est tudo normal. Azul Ambientes com um tom de verde claro promovam um estado de paz na
U N
tranquila de todas. Fornece um bom fundo para cores vvidas. Simboliza autoridade e espiritualidade, sendo a cor mais amplamente usada nas bandeiras nacionais, mostrando assim, o desejo de unidade e estabilidade. uma das trs primrias dos terminais de vdeo. difcil de ser focalizada e de se obter um bom contraste. Assim, no deve nunca ser usado para texto nem detalhes finos. Entretanto, uma excelente cor para o fundo, dada sensao gerada por ela, de expanso e profundidade. Em relao aos significados subjetivos das cores, o quadro 17 ilustra muito bem a associao das cores com elementos positivos e negativos.
IM
Sugere espao e profundidade. uma cor fria e suave, sendo a mais
IN
o sol faz com que ela simbolize a vida e o calor. um bom indicador de atividade,
Amarelo
119
Cor Neve Branco Pureza Inocncia Noite Preto Carvo Poder Vitria Vermelho Paixo Amor Sol Amarelo Vero Serenidade Vegetao Verde Natureza Primavera Cu Azul Mar
Positivas Paz Leveza Limpeza Estabilidade Formalidade Solidez Fora Energia Sexualidade Ouro Colheita Inovao Fertilidade Frio Hospital
Negativas Palidez fnebre Rendio Esterilidade Segredos Anonimato maldio Perigo Raiva Sat Risco Doena
Vulnerabilidade Medo Vazio Morte Sangue Guerra Fogo Covardia Traio
Esperana
A
Inveja Frio Depresso Melancolia
Segurana
IN
Paz Unidade
Estabilidade
Espiritualidade
Quadro 17 Simbologia de cores.
5.1.
compe o sistema e quais eventos permitem ao usurio navegar de uma para outra.
U N
sistema.
Permite observar a dinmica da aplicao, uma vez que ilustra os caminhos possveis na interao do usurio com o sistema A seguir, a figura 70 apresenta o diagrama de navegabilidade do
IM
DIAGRAMA DE NAVEGABILIDADE
O diagrama de estados de navegao indica quais so as janelas que
S
Cimes Decadncia Inexperincia
Loucura
Ganncia
Fuga realidade M Sorte Obscenidade Mistrio Conservadorismo
120
Figura 70 Diagrama de Navegabilidade.
U N IM IN A S
121
A interface com o usurio foi definida atravs de Java Server Pages, tambm conhecida por sua sigla JSP. As pginas JSP que consistem em pginas HTML com elementos especiais, que lhes conferem carter dinmico. Esses elementos podem tanto realizar um processamento por si, como podem recuperar o resultado do processamento realizado em um Servlet e apresentar esse contedo dinmico junto a pgina JSP. Existe tambm um recurso adicional bastante interessante na utilizao de pginas JSP: a recompilao automtica, que permite que alteraes feitas no s pginas JSP associou-se a tecnologia Cascade Style Sheets CSS - linguagem de estilo, que provm a apresentao de documentos escritos em uma linguagem de marcao, como o HyperText Markup Language HTML. O principal benefcio permitir a separao entre o formato e o contedo de um documento, pgina separada ligada s pginas de cdigo, de modo que para alterar a apresentao das pginas de interface, basta proceder as mudanas na pgina onde os estilos esto definidos, que as alteraes sero percebidas de forma idntica nas demais pginas. pois formatao no est incorporada ao documento. Os estilos ficam em uma cdigo da pgina sejam automaticamente visveis em sua apresentao.
nevegao entre as telas de interface
U N
IM
A seguir ser simulado os comportamento do sistema, com a
IN
122
Figura 71 Tela de Login.
U N
Figura 72 Tela de mensagem de erro no Login.
IM
IN
123
Figura 73 Menu inicial.
U N
Figura 74 Tela de Cadastro de Dados.
IM
IN
124
Figura 75 Tela com mensagem de erro de CPF.
U N
Figura 76 Tela com mensagem de erro, CPF cadastrado como morador em outra unidade.
IM
IN
125
Figura 77 Tela com mensagem de sucesso ao cadastrar os dados.
U N
Figura 78 Tela que apresenta a lista das pessoas cadastradas.
IM
IN
126
Figura 79 Tela para solicitar a pesquisa dos dados de uma pessoa.
U N
Figura 80 Tela que apresenta os dados da pessoa pesquisada.
IM
IN
127
U N
Figura 82 Tela que apresenta os dados da unidade pesquisada.
IM
IN
Figura 81 Tela para solicitar a pesquisa dos dados de uma unidade.
128
6.
PERSISTNCIA DE DADOS
Marco Aurlio Silva Rodrigues
A maioria dos aplicativos requer dados persistentes. A persistncia um dos conceitos fundamentais em desenvolvimento de aplicativos. Se um sistema de informao no preservasse os dados inseridos pelos usurios quando a mquina anfitri fosse desligada, o sistema seria de pequeno uso prtico. Quando falamos sobre persistncia em Java, normalmente estamos falando sobre armazenar dados em um bando de dados relacional, usando SQL (Structure Query Language) (BAUER & KING, 2005). A persistncia de dados, na computao, refere-se ao armazenamento no-voltil de dados, por exemplo em um dispositivo fsico de armazenamento como um disco rgido. De forma muito simples, Persistncia de Dados nada mais do que armazenar dados em um banco de dados relacional. Pode-se dizer que de maneira geral, o termo persistncia associado a uma ao que consiste em manter em meio fsico recupervel, como banco de determinado estado de um objeto lgico. Na Orientao a Objetos, chama-se de "objetos persistentes" aqueles que permanecem existindo mesmo aps o trmino da execuo do programa. dados, arquivo, de modo a garantir a permanncia das informaes de um
U N
Dentras as alternativas existentes, foi-se trabalhado a persistncia sob o controle de um banco de dados, pois as aplicaes requerem um servio de banco de dados, pois assim os dados desses objetos podem ser eternizados e recuperados. Assim persistncia de dados consiste no armazenamento confivel e
coerente das informaes em um sistema de armazenamento de dados, a persistncia de objetos o armazenamento consistente de objetos de uma aplicao orientada a objeto para que estes objetos existam em diferentes execues de diferentes aplicaes.
IM
IN
129
6.1.
CONCEITOS DE BANCO DE DADOS

Os bancos de dados e os sistemas de bancos de dados so
componentes essenciais para a sociedade moderna, na medida em que os sistemas de informao esto cada vez mais difundidos. Essa tecnologia tem provocado impacto no crescimento do uso de computadores, representando, um papel crtico nas reas em que os computadores so utilizados, incluindo negcios, comrcio eletrnico, engenharia, medicina, direito, educao e as cincias da informao, para criar apenas algumas delas. A palavra banco de dados to comumente utilizada que, primeiro, devemos defini-la (ELMASRI & NAVATHE, 2005). De acordo com Elmasri e Navathe (2005, p. 4) um banco de dados uma coleo de dados relacionais. Os dados sos fatos que podem ser gravados e Um sistema de banco de dados um sistema computadorizado de ser considerado como o equivalente eletrnico de um armrio de arquivamento onde os usurios do sistema podem realizar diversas operaes (DATE, 2004): Busca de dados; Insero de dados;
Excluso de dados;
Alterao de dados;
Remoo de dados;
U N
empresa.
dados persistentes, usado pelos sistemas de aplicaes de uma determinada Os dados armazenados em um banco de dados representam algum
aspecto especfico do mundo real um universo de discurso de onde os dados so obtidos e apresentam algum grau de coerncia lgica entre seus componentes. Portanto, uma coleo aleatria de dados no constitui um banco de dados. Um sistema de banco de dados constitudo 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 aplicao que serve de suporte a
IM
Segundo Date (2005, p. 10) um banco de dados uma coleo de
IN
manuteno de registros, dados. Desse maneira o banco de dados, por si s, pode
que possuem um significado implcito.
130
outras aplicaes, tais como folha de pagamento, controle de pessoal e informaes bancrias. Os bancos de dados relacionais modernos fornecem uma representao estruturada de dados persistentes, permitindo a classificao, busca e agregao de dados. Os sistemas de gerenciamento de banco de dados (SGBD) so responsveis por gerenciar a concorrncia e a integridade dos dados. So, ainda, responsveis por compartilhar dados entre os mltiplos usurios e os mltiplos aplicativos. Um sistema de gerenciamento de banco de dados deve, inclusive, fornecer segurana de alto nvel de dados (BAUER & KING, 2005). Dentre as vantagens da abordagem de banco de dados destacamos Armazenamento, organizao e obteno de dados estruturados. Reduo de redundncia.
Inconsistncia pode ser evitada. Manuteno da Integridade. Reforo da segurana. Imposio de padres.
Fornecimento de suporte a transao.
U N
aplicativo, SGBD e o banco de dados.
IM
Requisitos contraditrios podem ser equilibrados.
A figura 83 apresenta esquematicamente, a relao entre usurios,
IN
Compartilhamento dos dados.
(DATE, 2004):
131
Figura 83 Sistema simplificado de Banco de Dados.

Adaptado de RICARTE. I. L. M (1998, p.2).
O banco do Sistema Gesto de Condomnio foi usado para oferecer um armazenamento persistente aos objetos programas e estruturas de dados. Essa objeto. As linguagens de programao tm uma estrutura de dados complexa, como as definies de classes em Java. 6.2. umas das principais justificativas para o sistema de banco de dados orientados a
U N
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 aplicaes. A criao e manuteno de bancos de dados so tarefas de uma pessoa ou grupo de pessoas, normalmente referenciada como o administrador do banco de dados. A manipulao do banco de dados, como atualizaes e consultas, realizada direta ou indiretamente, atravs de programas aplicativos, pelos usurios do banco de dados. O sistema gerenciador de banco de dados pode ser de propsito geral ou especfico para alguma aplicao.
IM
MYSQL
O MySQL um SGBD (Sistema de Gerenciamento de Banco de
IN
132
Para o desenvolvimento do sistema em questo, escolheu-se o MySQL devido a sua alta performance observada em aplicativos de misso critica, a fcil operao e manuteno, a sua estabilidade e o baixo custo de aquisio . Dentre as suas principais caractersticas destacamos: Funciona em diversas plataformas. API (Application Programming Interface) para C, C++, Eiffel, Java, Perl, PHP, Python, Ruby e Tcl esto disponveis. Suporte total a multi-threads usando threads diretamente no kernel. Isto significa que se pode facilmente usar mltiplas CPU (Central Fornece mecanismos fcil de armazenamento se adicionar Processing Unit), se disponvel. transacional. relativamente armazenamento. processo(thread).
S
outro
transacional
no de
mecanismo
Joins muito rpidas usando uma multi-join de leitura nica otimizada. Tabelas hash em memria que so usadas como tabelas temporrias.
U N

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 variveis. Comandos e Funes Completo suporte a operadores e funes nas partes SELECT e WHERE das consultas.
IM
Funes SQL so implementadas por meio de uma biblioteca de classes altamente otimizada e com o mximo de performance. Geralmente no h nenhuma alocao de memria depois da inicializao da pesquisa. Disponvel como verso cliente/servidor ou embutida (ligada).
IN
Um sistema de alocao de memria muito rpido e baseado em
133
Suporte pleno s clusulas SQL GROUP BY e ORDER BY. Suporte para funes 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 so disponveis como definidos no padro SQL92. DELETE, INSERT, REPLACE, e UPDATE retornam o nmero de linhas que foram alteradas. possvel retornar o nmero de linhas com padro coincidentes configurando um parmetro quando estiver Voc pode misturar tabelas de bancos de dados diferentes na mesma Segurana
Um sistema de privilgios e senhas que muito flexvel, seguro e que permite verificao baseada em estaes/mquinas. Senhas so seguras porque todo o trfico de senhas criptografado quando voc se conecta ao servidor. Conectividade Escalabilidade
U N
IM
Os clientes podem se conectar ao servidor MySQL usando sockets TCP/IP (Transmission Control Protocol/Internet Protocol), em qualquer plataforma. No sistema Windows na famlia 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 conexo ODBC. Os clientes podem ser executados no Windows ou Unix. O fonte do Connector/ODBC est disponvel. Todas as funes ODBC so suportadas, assim como muitas outras (MySQL).
IN
pesquisa.
conectando ao servidor.
134
6.3.
MODELAGEM DE BANCO DE DADOS

Modelagem de dados a atividade de especificao das estruturas de
dados e regras de negcio necessrias para suportar uma rea de negcios. Representa um conjunto de requerimentos de informaes de negcio. uma parte importante do desenho de um sistema de informao (Wikipdia, 2009b). A abordagem que se dispensa ao assunto normalmente atende a trs perspectivas: Modelagem Conceitual, Modelagem Lgica e Modelagem Fsica. A primeira usada como representao de alto nvel e considera exclusivamente o ponto de vista do usurio criador do dado, a segunda j agrega alguns detalhes de implementao e a terceira demonstra como os dados so fisicamente armazenados (Wikipdia, 2009b).
6.3.1.
Modelos
Um modelo de dados uma definio abstrata, autnoma e lgica dos De acordo com a abordagem que utilizada e conforme ilustrado pela figura 84, os modelos de dados normalmente so classificados da seguinte forma:
U N
Figura 84 Arquitetura de Modelo de Banco de Dados.
Adaptado de RICARTE. I. L. M (1998; p.10).
IM
IN
objetos, operadores e outros elementos.
135
Modelo Conceitual:
o
Representao dos conceitos e caractersticas observados no ambiente; Ignorar particularidades de implementao. A modelagem conceitual uma fase muito importante no
planejamento de uma aplicao de um banco de dados bem-sucedida. Geralmente, o termo aplicao de um banco de dados refere-se a um banco de dados particular e aos programas a eles associados, que implementam consultas e atualizaes (ELMASRI & NAVATHE, 2005, p.35).
Modelo Lgico:
o
Normalizao das estruturas de dados especializao Regras de Restrio:
Derivao de estruturas de agregao e generalizaoDerivao de relacionamentos

o
U N
Gesto de Condomnio.
IM
Restrio de domnio
Restrio de Integridade Restrio de Implementao
Figura 86 apresentada o modelo lgico implementado para Sistema de
IN
Regras de Derivao:
136
Figura 85 Modelo Lgico de Banco de Dados.
U N
o
Modelo Fsico: Inclui a anlise das caractersticas e recursos necessrios para armazenamento e manipulao das estruturas de dados (estrutura de armazenamento, endereamento, acesso e alocao fsica). Figura 85 apresenta o modelo fsico implementado para o Sistema de
Gesto de Condomnio.
IM
IN
137
Figura 86 Modelo Fsico de Banco de Dados.
abaixo:
Normalizao, evitando assim os problemas que podem provocar falhas no projeto do banco de dados, bem como eliminar a mistura de assuntos e as correspondentes redundncias dos dados desnecessrias. Representao fiel do negcio Descrio sucinta das entidades, atributos e relacionamentos; Contendo os nomes de entidades e atributos, extensos e abreviados,
U N

atribudos de acordo com algum padro adotado no projeto e formados por termos previamente convencionados; Contemplando, para cada um dos atributos, o tipo de dado, tamanho e opcionalidade.
IM
O modelo para o sistema foi implementado atendendo as regras
IN
138
O modelo de dados usado no projeto foi o conceitual de alto nvel, o Modelo EntidadeRelacionamento que um tipo de modelo lgico baseado em objetos. Para entendimento do modelo apresentado para o sistema, segue abaixo a definio de alguns conceitos: Entidade: qualquer coisa, concreta ou abstrata, incluindo associaes entre entidades, abstrados do mundo real e modelados em forma de tabela que guardaro informaes no banco de dados. Relacionamento: nada mais do que uma associao entre estas entidades. Segue abaixo tipos de relacionamento:
Relao 1..1 - indica que as tabelas tm relao unvoca entre si. Voc Relao 1..n - a chave primria da tabela que tem o lado 1 vai para a Relao n..n - quando tabelas tm entre si relao n..n, necessrio criar uma nova tabela com as chaves primrias das tabelas envolvidas, ficando assim uma chave composta, ou seja, formada por diversos campos-chave
Atributo: corresponde a alguma propriedade de interesse que ajuda a
U N
descrio de uma entidade. As tabelas, entidades, relacionam-se umas as outras atravs 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, tambm fundamental para a criao dos ndices. Temos dois tipos de chaves: Chave primria: (PK - Primary Key) a chave que identifica cada registro dando-lhe unicidade. A chave primria nunca se repetir.
IM
de outras tabelas. A relao ento se reduz para uma relao 1..n, sendo que o lado n ficar com a nova tabela criada.
IN
tabela do lado N. No lado N ela chamada de chave estrangeira;
escolhe qual tabela vai receber a chave estrangeira;
139
Chave Estrangeira: (FK - Foreign Key) a chave formada atravs de um relacionamento com a chave primria de outra tabela. Define um relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso a chave primria seja composta na origem, a chave estrangeira tambm o ser.
6.3.2.
Compreendendo o Modelo Nos modelos lgico e fsico apresentados nas figuras 3 e 4, observa-se
presena
das
seguintes
entidades:
TaxaCondominio,
ContaMensal,
A entidade TaxaCondominio composta pelos seguintes atributos: TC_mesRef (PK), CM_id (FK), TC_valorTaxa, TC_dataGeracao, TC_dataVencimento. A entidade TaxaCondominio
A
pelo
chave TC_mesRef. A entidade ContaMensal composta pelos seguintes atributos: entidade ContaMensal
IN
identificada
CM_id (PK), CM_tipo, CM_valorConta, CM_mesreferencia, CM_dataVencimento. A 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.
U N
6.4.
que permite separar regras de negcio das regras de acesso a banco de dados.
IM
PADRO DE PROJETOS DAO

DAO (Data Access Object) um padro para persistncia de dados
PagamentoMes, Pessoa, Historico e Unidade.
identificada pelo atributo
140
Numa aplicao que utilize a arquitetura MVC (Model, View, Controler), todas as funcionalidades de bancos de dados, tais como obter as conexes, mapear objetos Java para tipos de dados SQL ou executar comandos SQL, devem ser feitas por classes de DAO. Usando-se esse padro a camada de negcios acessa os dados persistidos sem ter conhecimento se os dados esto em um banco de dados relacional ou um arquivo XML (eXtensible Markup Language). O padro DAO esconde os detalhes da execuo da origem dos dados (SUN, 2009). Utilizou-se o DAO para abstrair e encapsular todo o acesso fonte de dados. O DAO gerencia a conexo com a fonte de dados para obter e armazenar A figura 87 apresenta a estrutura do padro DAO. A classe classe DataSource que pode ser um arquivo XML, uma base de dados ou algum servio remoto, ou seja, a origem dos dados. A classe BusinessObject representa a aplicao (tambm conhecida como cliente do padro), que usa um objeto DataAccessObject. Ao utilizar esse objeto DataAcessObject, o objeto cliente recebe ou envia um objeto TransferObject. Esse objeto contm os dados a campos de um registro. serem enviados ou trazidos da origem dos dados, e normalmente referem-se aos
U N
Figura 87 - Estrutura Padro DAO.
Adaptado de SUN, 2009.
classes DAO para acesso aos objetos atravs do Hibernate. Essas classes buscam os dados do banco e os converte em objetos para serem usados pela aplicao.
IM
Para o Sistema de Gesto de Condomnio, foram implementadas
IN
DataAccessObject encapsula o acesso aos dados, que por sua vez mantido pela
dados (SUN, 2009).
141
Semelhantemente, deve saber como manipular os objetos, converter em instrues 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 funo de armazenar, persistir os dados. Tendo em vista que grande parte das aplicaes desenvolvidas mantm suas informaes gravadas em um banco de dados relacional, o grande problema que, atualmente, as melhores linguagens de programao so orientadas a objeto tornando complicado a integrao entre esse tipo de banco de dados e essas linguagens. Alm disso, mesmo em linguagens estruturadas como aplicao cresce. Um modelo de programao muito usado, mesmo em linguagens tipicamente orientadas a objeto como Java, misturar lgica de negcio com cdigo SQL. Caso o banco de dados de aplicao mude, seria necessrio reescrever praticamente toda a aplicao, para dar suporte ao novo banco. Assim uma tcnica bastante conhecida da orientao a objetos o alguns mtodos nesses objetos que o mundo externo poder usar para ter acesso ao resultado dos cdigos. Essa idia foi adaptada programao com banco de dados. Os mtodos necessrios ao acesso e manipulao do banco ficam escondidos dentro de classes bsicas. As outras partes da aplicao usam essas classes e seus objetos, ou seja, a aplicao 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 tambm possibilita pesquisas e retorno de dados, podendo reduzir, significativamente, o tempo de desenvolvimento antes investido em controlar o relacionamento objetorelacional. Uma das funcionalidades do Hibernate a gerao de cdigo atravs da engenharia reversa, que possibilita a implementao das classes Java de encapsulamento, onde possvel esconder as regras dentro de objetos e definir Java, trabalhar com banco de dados tornava-se uma tarefa rdua medida que a
U N
IM
IN
142
entidade a partir da estrutura das tabelas criadas no Banco de Dados. Tendo sido essa a maneira utilizada para iniciar-se a codificao do sistema em questo.
6.5.1.
Caractersticas Hibernate Modelo de programao natural: suporta desenvolvimento em
programao orientada a objeto (OO) natural; herana, polimorfismo, agregao e tambm a Java Collections framework. Suporte modelos objetos detalhados: oferece uma grande variedade de mapeamentos para collections e objetos dependentes. Sem cdigo extra no momento de compilao dos bytecodes: no existe cdigo extra gerado na compilao dos cdigos fontes para bytecode. Alta escalabilidade: tem alta performance com sua arquitetura com 2 Query language: soluciona ambos os lados, no somente como enviar de dados. persistncia de
Suporte a transaes a nvel de aplicao: suporta contextos de longa durao, detach/reattach e executa lock otimista
GNU Public License).
U N
transparente. 6.5.2.
garantindo que possa se conectar com banco de dados legados de forma
aplicaes, diminuindo consideravelmente o tempo de desenvolvimento da aplicao. Para atingir este objetivo, foi criado de forma a ficar entre as aplicaes e o banco de dados, traduzindo as chamadas ao banco de dados e, tambm, controlando a persistncia dos dados (Figura 88).
IM
automaticamente;
Free /Open source: licenciado sobre a licena do tipo LGPL (Lesser
Suporte a API JCA: possui compatibilidade com a API Java JCA
Arquitetura do Hibernate O Hibernate tem como objetivo controlar toda a persistncia das
IN
os dados para o banco de dados, como tambm como buscar os mesmos do banco
caches e pode ser utilizado em cluster.
143
Figura 88 Arquitetura Hibernate.
Hibernate.properties: configurao do Hibernate com relao ao SGBD (url, senha, driver JDBC, etc. ).
seus campos s colunas.
Persistence Object: classe derivada da classe mapeada da aplicao, que contm os mtodos para acesso ao SGBD.
U N
6.5.3.
banco de dados, isso depende, na maioria das vezes, apenas de poucos minutos de uma reconfigurao bsica do framework. Ele tambm deixa transparentes as operaes bsicas de insero, recuperao, atualizao e remoo de dados.
IM
XML mapping - Annotation: associa cada classe a uma tabela no SGBD e
Mapeamento Objeto Relacional De acordo com Bauer e King (2005, p. 31-32):

O mapeamento objeto relacional a persistncia 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 reversvel de uma representao em outra.
O uso do Hibernate torna a aplicao malevel a mais de um tipo de
IN
Adaptado de Hibernate (2009).
144
Contudo o principal ponto de destaque est no paradigma de orientao a objetos para banco de dados, tornado a modelagem e o trabalho de programao muito mais elegante e compreensvel. A soluo do ORM consiste nas quatro peas seguintes: Uma API para executar operaes CRUD (Create, retrieve, updade, delete) bsicas 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. transacionais a fim de executar a verificao suja, buscas de associao ociosas e outras funes de otimizao. Ainda, considerando Bauer e King (2005, p. 32) o termo ORM usado para incluir qualquer camada de persistncia onde o SQL seja gerado O mapeamento feito utilizando annotations, alm disto, direcionado para as classes e no para as tabelas diretamente. Uma estrutura especfica validada, o qual indica as propriedades a serem mapeadas em um objeto, permitindo a incluso de relacionamentos, de forma a simular as relaes existentes em bancos de dados relacionados. O Hibernate permite o mapeamento objeto-relacional de dados permitindo persistncia transparente para o desenvolvimento das aplicaes e, por conseqncia, diminuindo a possibilidade de erros nesta etapa e tambm minimizando o trabalho manual da equipe do projeto no mapeamento destas relaes objeto-relacional. Para atingir este objetivo h a associao de mapeamentos com classes persistentes criadas especificamente para cada objeto mapeado. As bibliotecas de Mapeamento Objeto Relacional fazem o mapeamento automaticamente a partir de uma descrio baseada em metadados. Um tcnica para a implementao do ORM para interagir com objetos
U N
operaes.
de tabelas para classes. Como exemplo o banco de dados desenvolvido para o sistema possui uma tabela chamada Historico, a aplicao possuir, uma classe denominada Historico. Essa classe definir atributos, que sero usados para receber e alterar os dados dos campos das tabelas, alm de mtodos para realizar as
IM
IN
145
Alm disso, as classes que fazem essa interface com as tabelas do banco de dados, provem um conjunto de mtodos de alto-nvel que servem para realizar operaes bsicas nas tabelas, como recuperar um registro atravs de um id, dentre outros. A figura 89 abaixo apresenta o arquivo onde os pacotes e as classes anotadas so declaradas em um arquivo XML regular, geralmente o "hibernate.cfg.xml". Alm disso, as propriedades de acesso ao banco tambm foram definidas nesse arquivo. Nele possvel verificar a tag <session-factory> que delimita as configuraes para a sesso. Dentro dela existem as tags <property> cujos
definem o mapeamento das classes que vo gerar os objetos para serem Dentre os principais parmetros destacamos:
parmetros de localizao do SGBD.
property name="hibernate.dialect" representa o dialeto utilizado pelo SGBD pois existem diferenas nas implementaes dos diferentes fornecedores de SGBDs. property name="hibernate.connection.driver_class" informa qual o driver JDBC deve ser utilizado para a conexo. property name="hibernate.connection.username" informa qual o nome do usurio do SGBD. informa qual a senha de conexo do SGBD. A figura 89 traz o cdigo do arquivo hibernate.cfg.xml usado na property name="hibernate.connection.password"
U N
aplicao.
<?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 >
IM
IN
property name="hibernate.connection.url" utilizado para informar os
persistidos. Todas essas informaes ficam dentro da tag <Hibernate-configuration>.
atributos definem as configuraes com o banco de dados e <mapping class> que
146
<property name="hibernate.connection.username">root</property> <property name="hibernate.connection.password"></property> <property name="hibernate.current_session_context_class">thread</property> <property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property> <property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property> <property name="show_sql">true</property> <property name="connection.pool_size">1</property>  <mapping class="br.uniminas.entidades.UsuarioEntidade" /> <mapping class="br.uniminas.entidades.Unidade" /> <mapping class="br.uniminas.entidades.Pessoa" /> <mapping class="br.uniminas.entidades.Historico" /> </session-factory> </hibernate-configuration>
Figura 89 - Arquivo "hibernate.cfg.xml".
Para o sistema desenvolvido, foi implementada uma classe esttica chamada de "HibernateUtil" (figura 90). A funo dessa classe encapsular a criao e recuperao de sesses.
U N
}
} } public static SessionFactory getSessionFactory() { return sessionFactory;}
Figura 90 Classe Hibernate til.
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 herana, polimorfismo e encapsulamento.
IM
... 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);
Na figura 91, possvel verificar o uso de um mtodo da sesso
IN
147
Pode-se observar ainda que os mtodos para manipulao dos dados, como por exemplo, o mtodo insert recebe um objeto Historico como parmetro e o mesmo persistido no banco pelo Hibernate. Compreendendo-se assim o que ocorreu. Primeiramente, a recuperao da sesso (session) com uso da classe HibernateUtil. Nesse momento, uma sesso (session) seria mais ou menos como uma unidade de trabalho, uma transao com o banco de dados, para um melhor entendimento. Depois, utilizamos a sesso para iniciar uma transao, salvar o objeto no banco de dados e, por ltimo, "commitar" a transao. A sesso iniciada sempre que o mtodo invocado e terminado atravs de um commit ou rollback. getCurrentSession
U N
} 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();
IM
}
session.beginTransaction(); Query q = session.createQuery("from Historico id=:Id_Historico"); q.setInteger("Id_Historico", i); return (Historico) q.uniqueResult(); } finally { // session.close();
IN
... 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 {
where
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 { }
U N
} } }
Figura 91 Classe de persistncia HistoricoHibernateDAO.
6.6.
metadados para determinar como dever ser feita a transformao dos dados entre classes e tabelas. Como opo, utilizamos um recurso, que veio com o JDK 5.0, chamado de Annotation. O mapeamento objeto relacional se estabelece atravs de anotaes (annottations) colocadas nas classes de entidade. Esse mapeamento determina a
IM
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 {
MECANISMOS DE PERSISTNCIA
Como a maioria das ferramentas ORM, o Hibernate necessita de
IN
} public void updateHistorico(Historico hist) {
149
correspondncia 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 correspondncia entre os atributos das classes e seus pares nas respectivas tabelas. a partir dessa identificao, que o Hibernate, framework usado para fazer a persistncia com o banco de dados, pode persistir no banco de dados o objeto Java instanciado. Atravs das anotaes feita uma juno entre o objeto Java criado e a tabela no banco Assim os dados so persistidos no mais usando arquivos XML como anteriormente, e sim com uso de annotations. Anotaes so diretivas colocadas no cdigo Java para associar as classes a tabelas no SGBD, substituindo o arquivo Para melhor uma compreenso, possvel visualizar na figura 92 a persistncia.
U N
... @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;
IM
IN
classe de entidade Histrico, e as anotaes usadas como mecanismos de
XML.
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 Histrico.
Quanto aplicabilidade das anotaes implementadas segue: @Entity: declara a classe como uma classe de entidade (ou uma classe persistente). Id, todas as classes de entidade (entity classes) persistentes @Table: usada para definir qual tabela ser usada para persistir os objetos dessa com o mesmo nome da classe. caso, foi definido o atributo "id".
@Id: declara qual campo, atributo da classe ser usado como identificador. Neste @Column: usada para definir as propriedades dos atributos. @ManyToOne: informa que existe um relacionamento de um para muitos. utilizada no relacionamento das entidades relacionais. O Hibernate no somente fornece uma soluo com todas funes que satisfaam frontalmente essas exigncias, ele tambm uma arquitetura flexvel e @JoinColumn: utilizada para informar que o nome da chave estrangeira
U N
configurvel. Ele foi o projetado com modularidade, conectibilidade, extensibilidade e com a customizao do usurio em mente (BAUER & KING, 2005). Isso torna a interao com o banco de dados transparente, do ponto de vista da programao Java. A principal vantagem a mudana do paradigma de trabalho Estruturado para o Orientado a Objeto, eliminado, assim, muito trabalho repetitivo e tedioso. A desvantagem a diminuio do desempenho, decorrente da existncia de uma camada intermediria entre o banco de dados e a aplicao, porm ela pode ser diminuda utilizando configuraes avanadas do Hibernate, por exemplo o trabalho com cache.
IM
IN
classe. Se essa anotao no for usada, o Hibernate ir procurar por uma tabela
precisaro de tal atributo se quisermos utilizar todos os recursos do Hibernate.
151
7.
CONCLUSO
O levantamento dos requisitos do sistema, a documentao dos casos de uso e a elaborao do diagrama de classe e dos diagramas de seqncia permitiram equipe perceber melhor o desenho do sistema, facilitando, inclusive a comunicao entre seus membros. Atender os preceitos tcnicos da anlise de sistema possibilitou bom entendimento do problema e da aplicao antes de seu desenvolvimento. Os diagramas de classe e de seqncia elaborados j em nvel de sistema uma vez que sero a base para a manuteno e expanso do mesmo. alm de no apresentar custo, opera em qualquer sistema operacional. Essa caracterstica atendeu, logicamente, a uma das exigncias do projeto: o software deveria operar sobre o sistema operacional Windows XP, uma vez que o equipamento do cliente possua esta configurao. Alm disso, a linguagem orientada a objeto permitiu uma modelagem dentro da tendncia atual, o que, de para a atualizao e expanso do sistema. A escolha da linguagem orientou a definio da ferramenta IDE (Integrated Development Environment) de desenvolvimento, cuja escolha recaiu acordo com a literatura, dever facilitar as alteraes e adequaes necessrias
U N
sobre o Eclipse, que agregado aos frameworks Struts e Hibernate apresentou boa produtividade, permitindo, tambm, simplificao do cdigo. Observa-se, entretanto,
que durante o processo de desenvolvimento foi necessrio usar mais de um equipamento e sob esse aspecto, o Eclipse no se mostrou estvel. Por diversas vezes, as bibliotecas tiveram de ser reinseridas, pois no foram reconhecidas apesar de estarem no projeto. O uso do Hibernate facilitou a implementao das classes de entidade,
atravs da engenharia reversa, que embora seja um processo de muitos passos, garante a correlao entre as classes e as tabelas do banco de dados. Observa-se, ainda, que esse procedimento pode ser realizado escalonadamente, facilitando a implementao por iteraes, que muitas vezes se fazem necessrias, quando do desenvolvimento de grandes projetos. As annottations realizaram com facilidade o
IM
IN
O uso da linguagem Java permitiu a implementao do software, pois
projeto foram considerados importantes documentos aps o desenvolvimento do
152
mapeamento objeto-relacional e o padro de projeto DAO permitiu a independncia do banco de dados utilizado, fazendo a persistncia dos dados de forma simples. O MySQL apresentou boa performance, tendo sido adequado aplicao. O modelo MVC permitiu independncia entre os vrios elementos de modo que as alteraes de cdigo que se fizeram necessrias tiveram pouco ou nenhum impacto nos demais componentes. O padro Business Object foi responsvel pela camada de negcio respondendo satisfatoriamente s necessidades da aplicao, trazendo, ainda, a vantagem de ser de fcil implementao. Uma vez definido que seria uma aplicao Web, a coerncia Comprovou-se a importncia dos padres, que apresentam solues claras para central da aplicao, como elemento organizador das requisies. Assim, o controlador foi pea chave na aplicao, cujo desenvolvimento foi facilitado pelo emprego do Struts, que implementa automaticamente o Front Controller, atravs do mapeamento das aes no arquivo Struts.xml. importante reforar que o uso dos frameworks facilitou bastante o padres Front Controller e Application Controller implementados pelo Struts, quer seja pelo mapeamento objeto relacional que faz a interao com o banco de dados propiciado pelo Hibernate. Estabeleceu-se, assim, uma seqncia lgica que em conjunto com os preceitos da orientao a objetos, permitiram o desenvolvimento de um sistema cuja manutenibilidade ser bastante facilitada. Ressalta-se, ainda que o Hibernate no somente fornece uma soluo
U N
com funes que auxiliam o desenvolvimento, mas tambm possui arquitetura flexvel e configurvel. Isso torna a interao com o banco de dados transparente, do ponto de vista da programao Java. A literatura cita como desvantagem a diminuio do desempenho, em funo da existncia de uma camada intermediria entre o banco de dados e a aplicao, que pode ser diminuda utilizando configuraes avanadas do Hibernate, como o trabalho com cache. O sistema foi parcialmente desenvolvido, dos quatorze casos de uso levantados foram implementados seis. Como o nmero de condomnios est
IM
desenvolvimento dessa aplicao multicamadas, quer seja pela implementao dos
IN
determinados problemas. No caso se percebeu a necessidade de um controle
determinou o seguimento dos padres de projeto para J2EE (desing patterns J2EE).
153
crescendo e a relao entre a gerncia e os condminos tem evoludo, acredita-se que seja importante a continuidade desse projeto. Aliado a isso, as caractersticas do sistema e a documentao para apoiar a expanso do projeto est disponvel, o que facilitar a realizao dessa tarefa.
U N
IM
IN
154
REFERNCIAS BIBLIOGRFICAS ABREU, Edriano. Baixa idade mdia. Disponvel em: <http://www.saberhistoria.hpg.ig.com.br/nova_pagina_35.htm>. Acesso em: 7 mar 2009. AHMED, Khawar Zaman; UMRYS4H, Cary E. Desenvolvendo aplicaes comerciais em Java com J2EE e UML. Rio de Janeiro: Cincia Moderna, 2002. 302 p. ALUR, Deepak; CRUPI, John; MALKS, Dan. Core J2EE Patterns: as melhores prticas e estratgias de design.Traduo de Altair Dias Caldas de Morais. Rio de Janeiro: Elsevier, 2004. 587 p. ANGOTI JR., Edson. Programao de Aplicaes para Internet usando JSP/SERVLETS. Diponvel em: <http://si.uniminas.br/~angoti/arquivos>. Acesso em: 04 jun. 2009a. ANGOTI JR., Edson. Padres de Projeto JEE. Disponvel em:<http://si.uniminas.br/~angoti/arquivos/PadroesProjetoJEE.pdf> Acesso em: 09 jun. 2009b. _______ Edson. Apache Tomcat. Disponvel em :<http://si.uniminas.br/~angoti/arquivos/Tomcat.pdf> Acesso em: 16 jun. 2009c. APOSTILA DE Java. 42 p. Apostila. Disponvel em <http://www.si.uniminas.br/~mauro/SIS07/ApostilaJava.pdf>. Acesso em 13 mai. 2009. ARAUJO, Vanessa L de. Regras de negcio. Disponvel em: <http://sysreq.incubadora.fapesp.br/portal/down/apr/RegrasNegocio.pdf>. Acesso em 16 maio 2009. ASCENCIO, Ana Fernanda Gomes. Mtodo Heurstico para Projetar e Analisar Interfaces Hipermdia Inteligentes. In: IV Semana Acadmica do Programa de PsGraduao da Cincia da Computao, 1999, Porto Alegre. Anais da IV Semana Acadmica do Programa de Ps-Graduao da Cincia da Computao, 1999. p. 195-198. Disponvel em: <http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana99/anafernanda/anafernand a.html>. Acesso em: 17 maio 2009. BAUER, Christian; KING, Gavin. Hibernate em Ao. Traduo de Cludio Rodrigues Pistille, Geane Girotto e Fbio Makoto. Rio de Janeiro: Cincia Moderna, 2005. 532p. Ttulo original: Hibernate in Action. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML, guia do usurio. Rio de janeiro: Campus, 2000. 472 p.
U N
IM
IN
155
BRASIL, Fundao Instituto Brasileiro de Geografia e Estatstica. Dados histricos dos censos. Disponvel em: <http://www.ibge.com.br/home/estatistica/populacao/censohistorico/1940_1996.shtm >. Acesso em: 7 mar 2009a. ________, Fundao Instituto Brasileiro de Geografia e Estatstica. Disponvel em: <http://www.ibge.com.br/home/>. Acesso em: 7 mar 2009b. ________, Fundao Instituto Brasileiro de Geografia e Estatstica. Tendncias demogrficas: uma anlise dos resultados da sinopse preliminar do censo demogrfico 2000. Rio de Janeiro: IBGE, 2001. 63 p. _______. Lei 4.591 de 16 de dezembro de 1964. Dispe sobre o condomnio em edificaes e as incorporaes imobilirias. DATE, C. J. Introduo a Sistemas de Banco de Dados. Traduo de Daniel Vieira. Rio de Janeiro: Campus, 2004. 865p. Ttulo original: An Introduction to Database Systems. DEBONI, Jos Eduardo Zindel. Modelagem orientada a objetos com a UML. So Paulo: Futura, 2003. 219 p. DUMOULIN, Cedric; FRANCISCUS, George; WINTERFELDT, David. Struts em ao. Traduo de Eveline Vieira Machado. Rio de Janeiro: Cincia Moderna, 2004. 604 p.
U N
FERREIRA, Simone Bacellar Leal ET all . Requisitos No Funcionais para Interfaces com o Usurio - O Uso de Cores. In: IDEAS 1999 - Segunda Jornada iberoamericanas de Ingenieria de Requisitos y Ambientes de Software, 1999. Anais da Conferncia IDEAS 99, 1999. Disponvel em: <ftp://ftp.inf.pucrio.br/pub/docs/techreports/97_28_ferreira.ps.gz>. Acesso em 17 maio 2009. FREUD, Sigmund. O mal estar na civilizao. Rio de Janeiro: Imago. 2002. 116 p. HIBERNATE. Relational Persistence for Java and .NET. Disponvel em: <http://www.hibernate.org> Acesso em: 14 abr. 2009. INTRODUCTION TO OMG's Unified Modeling Language (UML). Acesso em: 10 maio 2009. Disponvel em: <http://www.omg.org/gettingstarted/what_is_uml.htm>. DIAS, Klissiomara; BORBA, Paulo. Padres de Projeto para Estruturao de Aplicaes Distribudas Enterpise JavaBeans. In: Second Latin American Conference on Pattern Languages Programming, 2002, Itaipava. SugarLoafPLoP 2002. So Carlos: ICMC - Universidade de So Paulo, 2002. p. 55-86. Disponvel
IM
ELMASRI, R; NAVATHE, Shamkant. B. Sistemas de Banco de Dados. Traduo de Marlia Guimares Pinheiro, Claudio Cesar Canhette, Glenda Cristina Valim Melo, Claudia Vicci Amadeu e Rinaldo Macedo de Morais. 4 ed. So Paulo: Person Addison Wesley, 2005. 724p. Ttulo original: Fundamentals of Database Systems.
IN
156
em: <http://twiki.cin.ufpe.br/twiki/pub/SPG/GenteAreaPublications/PLOP02_dias.pdf>. Acesso em: 27 mai. 2009. LEMES, M. V. S; Introduo a Persistncia de Dados com Hibernate e Annotation. Junho 2007. 19p (Mimeo.). Disponvel em: <http://www.marvinlemos.net/download/arquivo/118/hibernate_annotation.pdf>. Acesso em: 3 jun. 2009. MARTINS, Jnior Machado. Utilizando o Padro de Projeto Observable. Disponvel 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 persistncia de dados em java. Novembro 2006. 17p. Universidade Federal da Grande Dourados. Disponvel em: <http://www.unibratec.com.br/sbts/diretorio/NOVOHIB.pdf>. Acesso em: 3 jun. 2009. MIRANDA, ngelo Tiago. Conseqncias e caractersticas das cidades. Disponvel em: <http://educacao.uol.com.br/geografia/ult1701u57.jhtm>. . Acesso em: 7 mar 2009. MYSQL. The world's most popular open source. Disponvel em: <http://www.mysql.com>. Acesso em: 15 abr. 2009. PREFEITURA DE UBERLNDIA. Secretaria Municipal de Planejamento. Banco de dados integrados. Uberlndia, 2007. Disponvel em: <http://www.uberlandia.mg.gov.br/midia/documentos/planejamento_urbano/BDI_200 7_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.). Disponvel em: < ftp://ftp.dca.fee.unicamp.br/pub/docs/ricarte/apostilas/mc_sbdoo.pdf>. Acesso em: 3 jun. 2009.
U N
SILVA, Paulo C. Barreto da. Utilizando UML: diagrama de classes. SQL Magazine, Rio de Janeiro, edio 63, ano 5, p. 10-17, 2007. SILVA, Sonia Maria Antunes da; BONIN, Marcos Rodrigo; PALUDO, Marco Antnio. Levantamento de requisitos segundo o mtodo volere. Disponvel 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 gentica. 2008. 66 f. Trabalho de Graduao Interdisciplinar (Curso superior em Tecnologia em informtica) - Centro Superior de Educao Tecnolgica Universidade Estadual de Campinas, Limeira, 2008. Disponvel em: <http://www.ceset.unicamp.br/liag/Gene/artigos/monografiaFinalHenrique_v7_.pdf>. Acesso em: 10 mai. 2009.
IM
IN
157
SUN, Core J2EE patterns: data access object. Disponvel em: <http://www.sun.com/>. Acesso em: 15 jun. 2009. TOOD, Nick; SZOLKOWSKI, Mark. Java Server Pages: o guia do desenvolvedor. Traduo de Edson Furmankiewic. Rio de Janeiro: Elsevier, 2003. 621 p. UML. Object Management Group - Unified Modeling Language. Disponvel em: <http://www.uml.org>. Acesso em: 15 abr. 2009. URBANIZAO DO Brasil. Disponvel em: <http://www.passeiweb.com/na_ponta_lingua/sala_de_aula/geografia/geografia_do_ brasil/quadro_humano/brasil_urbanizacao>. Acesso em: 7 mar. 2009. URBANIZAO DO mundo. Disponvel em: <http://www.brasilescola.com/geografia/urbanizacao-mundo.htm>. Acesso em: 7 mar 2009. WAZLAWICK, Raul Sidney. Anlise e projetos de sistema orientados a objetos. 2. Ed. Rio de Janeiro: Elsevier, 2004. 295 p. WIKIPEDIA. Java (linguagem de programao). Disponvel em: (Orlando) <http://pt.wikipedia.org/wiki/Java/linguagem_de_programa%C3%A7%C3%A3o>. Acesso em 15 maio 2009a. _______. Modelagem de dados. Disponvel em (Marco 2) <http://pt.wikipedia.org/wiki/Modelagem_de_dados>. Acesso em: 2 jun. 2009b.
_______. Polis. Disponvel em: <http://pt.wikipedia.org/wiki/P%C3%B3lis>. Acesso em: 7 mar 2009d.
U N
YOSHIMA, Rodrigo. Modelando o escopo do sistema com casos de uso. In: ______. Projeto de Software com UML 2.0. ASPERCOM, 2005. p. 9-27. 2009. Disponvel em: <http://www.aspercom.com.br/ead/mod/resource/view.php?id=16>. Acesso em 23 fev. 2009.
IM
_______. Persistncia de dados. Disponvel em <http://pt.wikipedia.org/wiki/Persist%C3%AAncia_de_dados >. Acesso em: 4 maio 2009c.
IN
158
APNDICE
Cdigo do arquivo struts.xml

<!DOCTYPE struts (View Source for full doctype...)> <struts> <package name="default" extends="struts-default"> - <!-mapeamento das aes --> <result>/page/login.jsp</result> <result name="erro">/page/login.jsp</result> </action> <action name="principal"> <result>/page/principal.jsp</result> </action> <action name="login" method="execute" class="br.uniminas.action.Login2"> <result name="success">/page/principal.jsp</result>
<action name="getAllPessoas" method="getAllPessoas" class="br.uniminas.action.CadastrarPessoaAction"> <result name="success">/page/pessoas.jsp</result> <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>
U N
</action> </action> </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 name="setUpForInsertOrUpdate2" method="setUpForInsertOrUpdate2" class="br.uniminas.action.PesquisarAction"> <result name="success">/page/consultaPessoaForm.jsp</result> <action name="setUpForInsertOrUpdate3" method="setUpForInsertOrUpdate3" class="br.uniminas.action.PesquisarAction"> <result name="success">/page/consultaUnidadeForm.jsp</result>
IM
IN
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>
<result name="success" type="redirect-action">getAllPessoas</result> <result name="erro">/page/erro.jsp</result> </action> </package> </struts>
U N
IM
IN
<action name="delete" method="deletePessoa" class="br.uniminas.action.CadastrarPessoaAction">

Gestao de Condominio

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gestao de Condominio

Enviado por

Direitos autorais:

Formatos disponíveis

UNIO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CINCIAS APLICADAS DE MINAS Autorizada pela Portaria n 577/2000 MEC,

BACHARELADO EM SISTEMAS DE INFORMAO

SISTEMA PARA GESTO DE CONDOMNIO

SISTEMA PARA GESTO DE CONDOMNIO

Orientador: Prof. Msc. Edson Angoti Jnior

SISTEMA PARA GESTO DE CONDOMNIO

Banca Examinadora: Uberlndia, 9 de julho de 2009.

________________________________________________________________ Professor. Msc.Edson Angoti Jnior (Orientador)

Profa. Dra. Ktia Lopes Silva

_________________________________________________________________ Prof. Dr. Mauro Hemerly Gazzani

localizado em Uberlndia, MG. Assim, desenvolveu-se um sistema de fcil operao,

administrao de condomnios, porm alguns clientes preferem softwares

Palavras chave: gesto de condomnio; sistema de informao; implementao de software.

Keywords: condominium management, information system, implementation of software.

Java Database Conectivity

Java Community Process

Lesser GNU Public License Open-DataBase-Connectivity

Lista de Tabelas Pgina

Lista de Quadros Pgina

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

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

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

unidade. .......................................................................................................................... 111

JUSTIFICATIVA........................................................................................................ 23 ORGANIZAO DO TRABALHO ................................................................................. 24 26 28

4.1. 4.2. 4.3.

TECNOLOGIAS UTILIZADAS ...................................................................................... 93 4.4.1. 4.4.2. 4.4.3.

5. INTERFACE 5.1. 6.1. 6.2. 6.3.

DIAGRAMA DE NAVEGABILIDADE ............................................................................ 119

MODELAGEM DE BANCO DE DADOS ....................................................................... 134 Compreendendo o Modelo.................................................................... 139

FRAMEWORK HIBERNATE...................................................................................... 141

MECANISMOS DE PERSISTNCIA ........................................................................... 148

REFERNCIAS BIBLIOGRFICAS APNDICE

efetivamente desencadeou o processo de urbanizao, definida como o aumento da

na tentativa de se protegerem de ataques externos. Denomina-se tal fenmeno de

ANOS 1940 1950 1960 1970 1980 1991 1996

at a dcada de 1960, a maioria da populao residia nas reas rurais. A partir de

implantao da indstria automobilstica (URBANIZAO DO Brasil, 2009).

TOTAL HABITANTES 41.236.315 51.944.397 70.070.457 93.139.037 119.002.706 146.825.475 157.070.163

Fonte: IBGE (BRASIL, 2009a).

Figura 1 Grau de Urbanizao, Brasil, 2000.

Mineiro, Uberlndia considerada a maior cidade do interior do estado e em 2006, a

Urbana Rural Total

Fonte: Prefeitura de Uberlndia (2007).

Fonte: IBGE (BRASIL, 2001).

Localizada na regio sudeste, no estado de Minas Gerais, no Tringulo

segurana, uma vez que a cotizao permite estabelecer mecanismos de proteo,

respeitados e exigidos de forma mais conveniente. H, no mercado vrias empresas

direcionada com embasamento legal. Tambm, pequenos condomnios esto

customizado, implicando em uma anlise correta dos requisitos que o software

vantagens e desvantagens. Sistemas j desenvolvidos podem ter menor custo e

documentar os casos de uso;

elaborar os diagramas de seqncia de anlise

utilizar o Desing Patterns J2EE;

utilizar o MySQL como banco de dados.

Embora as atividades de gesto de um condomnio sejam em princpio

implementar o sistema utilizando a linguagem de programao Java;

elaborar o diagrama conceitual (diagrama de classe de negcio)

Levantar os requisitos do sistema;

ferramenta, para atender a essa clientela. 1.6.

envolveram em todas as etapas para a realizao deste relatrio. Os captulos

pequenos espaos residenciais, quando o mercado parece ofertar propostas mais

Assim, desenvolver um software simplificado para a gesto de pequenos

Captulo 6: Persistncia de dados

ESPECIFICAO DO PROBLEMA O condomnio do Edifcio Porto Seguro (Figura 2) foi criado em 17 de