UNIMINAS SISTEMA PARA GESTÃO DE CONDOMÍNIO. Marco Aurélio Silva Rodrigues Maria Margaret de Vasconcellos Lemos Orlando Alves de Oliveira

UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria nº 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO Marco Aurélio Silva Rodrigues Maria Margaret de Vasconcellos Lemos Orlando Alves de Oliveira SISTEMA PARA GESTÃO DE CONDOMÍNIO Uberlândia 2009 1

Marco Aurélio Silva Rodrigues Maria Margaret de Vasconcelos Lemos Orlando Alves de Oliveira SISTEMA PARA GESTÃO DE CONDOMÍNIO Trabalho de Final de curso submetido à como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Msc. Edson Angoti Júnior Uberlândia 2009 2

Marcos Aurélio Silva Rodrigues Maria Margaret de Vasconcelos Lemos Orlando Alves de Oliveira SISTEMA PARA GESTÃO DE CONDOMÍNIO Banca Examinadora: Uberlândia, 9 de julho de 2009. Professor. Msc.Edson Angoti Júnior (Orientador) Profa. Dra. Kátia Lopes Silva Prof. Dr. Mauro Hemerly Gazzani Uberlândia 2009 3

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

AGRADECIMENTOS A todos os professores do Curso de Sistema de Informação da que durante nossa estada nesta casa nos acompanharam e auxiliaram na construção de nosso conhecimento. Em especial aos professores Ana Maria Ferreira Árabe, Edson Angoti Jr. e Kátia Lopes Silva que estiveram sempre presente na elaboração deste trabalho. Dividir com vocês essa autoria foi um privilégio que poucos de nós tiveram!

RESUMO A Revolução Industrial, um dos marcos da Idade Moderna efetivamente desencadeou o processo de urbanização, que trouxe em si questões a serem resolvidas. Como consequência, a moradia se tornou um problema a ser equacionado. A solução que se apresentou foi a verticalização, trazendo resposta à necessidade de espaço. Com a difusão dessa forma de associação, foram criadas leis que regulamentaram a sua administração, que atualmente, tende à profissionalização, tanto que há no mercado vários sistemas de informação voltados à administração de condomínios, porém alguns clientes preferem softwares customizados, sendo essa a escolha do Condomínio do Edifício Porto Seguro, localizado em Uberlândia, MG. Assim, desenvolveu-se um sistema de fácil operação, para apoiar a sua administração, possibilitando o registro de moradores e proprietários, mantendo o histórico dessas informações. Foi feita a análise, definidos os casos de uso e elaborados os diagramas de sequência documentados com o emprego da UML. O modelo escolhido foi o MVC, implementado com o uso do Eclipse e dos frameworks Struts e Hibernate. O mapeamento objeto relacional foi realizado pelo JDBC juntamente com a utilização do framewok Hibernate. Para o acesso ao banco de dados foi empregado o padrão de projeto DAO, configurado para se conectar ao MySQL, o SGBD escolhido para a persistência dos dados. O servidor web selecionado foi o TomCat, que implementa as especificações servlet e JSP. A interface com o usuário foi construída com páginas JSP de cor azul considerada a mais tranqüila de todas, que sugere espaço e profundidade. As ferramentas empregadas para a codificação do sistema permitiram a simplificação do código. A engenharia reversa realizada pelo Hibernate facilitou a implementação das classes de entidades, garantindo a correlação entre as classes e as tabelas do banco de dados. As annottations realizaram com facilidade o mapeamento objetorelacional e o padrão de projeto DAO proporcionou a persistência dos dados de forma simples, no banco de dados MySQL que apresentou boa performance, comprovando que foi uma escolha adequada à aplicação. Embora, não tenham sido implementados todos os casos de uso, o sistema pode ser concluído, pois o número de condomínios está crescendo e a relação entre a gerência e os condôminos tem

evoluído. Aliado a isso, as características do sistema e a documentação para apoiar a expansão do projeto está disponível, o que facilitará a realização dessa tarefa. Palavras chave: gestão de condomínio; sistema de informação; implementação de software.

ABSTRACT The Industrial Revolution, one of the landmarks of the Modern Age actually triggered the process of urbanization, which in itself has brought issues to be resolved. As a result, housing became a problem to be solved. The solution that presented itself was the verticalisation, bringing answers to the need for space. With the spread of this form of association, have created laws governing its administration, which currently tends to professionalism, so that there is more market information systems focused on management of condominiums, but some customers prefer customized software, and this is the choice the condominium building of Porto Seguro, located in Uberlândia, MG. Therefore, has developed a system to support its a system to support its administration, easy operation, allowing the registration of residents and owners, while maintaining the historical information. Was the analysis, the set of use cases and developed the sequence of diagrams that have been documented with the use of UML. The model chosen was the MVC, implemented using the Eclipse and the frameworks Hibernate and Struts. The object relational mapping was performed by JDBC with the use of Hibernate framewok. To access the database was used the design pattern DAO, configured to connect to MySQL, the DBMS chosen for the persistence of data. The web server selected was the Tomcat, which implements the servlet and JSP specifications. The user interface was developed with JSP pages with color blue as the most peaceful of all, suggesting space and depth. The tools used for coding the system allowed the simplification of the code. Reverse engineering performed by the Hibernate facilitating the implementation of entities classes, ensuring correlation between classes and tables in the database. The annottations made the object-relational mapping easy and the design pattern DAO has been the persistence of data in a simple way, the MySQL, choosing database, had good performance, proving that it was appropriated for the application. Although whole use cases have not been implemented, the system can be completed because the number of condominiums is growing and the relationship between management and owners have changed. In addition, the system features and documentation to support the expansion of the project is available, these will help the realization of this task.

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

LISTA DE ABREVIATURAS API Application Programming Interface CPF Cadastro de Pessoa Física CPU Central Processing Unit CRUD Create, Retrieve, Updade Delete CSS Cascading Style Sheets DAO Data Access Object GPL General Public License GNU GoF HQL HTML HTTP FK IBGE IDE IP J2EE JDBC JDK JEE JPC JSP JVM LGPL MVC Gnu not Unix Gang of Four Hibernate Query Language Hipertext Modelling Language Hipertext Transfer Protocol Foreign key Instituto Brasileiro de Geografia e Estatística Integrated Development Environment Internet Protocol Java Enterprise Edition Java Database Conectivity Java Development Kit Java Enterprise Edition Java Community Process Java Server Pages Java Virtual Machine Lesser GNU Public License Model View Control OBDC Open-DataBase-Connectivity OO ORM PK RAM Orientado a Objeto Object Role Modeling Primary Key Random Access Memory SGBD Sistema de Gerenciamento de Banco de Dados SQL Structured Query Language TCP Transmission Control Protocol XML extensible Markup Language

Lista de Tabelas Página Tabela 1 População brasileira, segundo os censos demográficos de 1940, 1950, 1960, 1970, 1980, 1991 e contagem de 1996... 18 Tabela 2 População de Uberlândia, MG, 1996 a 2006... 19 Lista de Quadros Página Quadro 2 Requisitos do sistema.... 30 Quadro 1 Regras de Negócio... 31 Quadro 3 Especificação do caso de uso: Fazer Login.... 37 Quadro 4 Especificação do caso de uso: Cadastrar Dados.... 39 Quadro 5 Especificação do caso de uso: Listar Pessoas... 42 Quadro 6 Especificação do caso de uso: Consultar Pessoa.... 44 Quadro 7 Especificação do caso de uso: Consultar Unidade... 46 Quadro 8 Especificação do caso de uso: Atualizar Histórico.... 49 Quadro 9 Especificação do caso de uso: Pesquisar Histórico.... 51 Quadro 10 Especificação do caso de uso: Registrar Conta a Pagar.... 53 Quadro 11 Especificação do caso de uso: Registrar Pagamento de Contas... 55 Quadro 12 Especificação do caso de uso: Gerar Taxa de Condomínio... 58 Quadro 13 Especificação do caso de uso: Receber Taxa de Condomínio.... 61 Quadro 14 Especificação do caso de uso: Gerar Recibo.... 64 Quadro 15 Especificação do caso de uso: Gerar Balancete.... 67 Quadro 16 Especificação do caso de uso: Gerar Histórico.... 70 Lista de Figuras Página Figura 1 Grau de Urbanização, Brasil, 2000... 19 Figura 2 Fachada do edifício Porto Seguro.... 26 Figura 3 Diagrama de classes de negócio... 35 Figura 4 Diagrama de casos de uso.... 36 Figura 5 Diagrama de sequência do caso de uso: Fazer Login.... 38 Figura 6 Diagrama de sequência do caso de uso: Cadastrar Dados.... 40 Figura 7 Diagrama de sequência do caso de uso: Listar Pessoas... 43 Figura 8 Diagrama de sequência do caso de uso: Consultar Pessoa... 45

Figura 9 Diagrama de sequência do caso de uso: Consultar Unidade.... 47 Figura 10 Diagrama de sequência do caso de uso: Atualizar Histórico.... 50 Figura 11 Diagrama de sequência do caso de uso: Pesquisar Histórico.... 52 Figura 12 Diagrama de sequência do caso de uso: Registrar Contas a Pagar... 54 Figura 13 Diagrama de sequência do caso de uso: Registrar pagamento de Contas.... 56 Figura 14 Diagrama de sequência do caso de uso: Gerar Taxa de Condomínio... 59 Figura 15 Diagrama de sequência do caso de uso: Receber Taxa de Condomínio.... 62 Figura 16 Diagrama de sequência do caso de uso: Gerar Recibo... 65 Figura 17 Diagrama de sequência do caso de uso: Gerar Balancete.... 68 Figura 18 Diagrama de sequência do caso de uso: Gerar Balancete.... 71 Figura 19 Classes do pacote entidades... 73 Figura 20 Classes do pacote bo.... 74 Figura 21 Classes do pacote persistência.... 74 Figura 22 Classes do pacote action... 75 Figura 23 Diagrama de sequência com as classes de projeto do caso de uso: Fazer Login.... 77 Figura 24 Diagrama de sequência com as classes de projeto do caso de uso: Cadastrar Dados... 79 Figura 25 Diagrama de sequência com as classes de projeto do caso de uso: Listar Pessoas.... 81 Figura 26 Diagrama de sequência com as classes de projeto do caso de uso: Consultar Pessoa... 83 Figura 27 Diagrama de sequência com as classes de projeto do caso de uso: Consultar Unidade.... 85 Figura 28 Diagrama de sequência com as classes de projeto do caso de uso: Atualizar Histórico.... 87 Figura 29 Modelo Arquitetura MVC... 90 Figura 30 Classe PessoaBO... 92 Figura 31 Ciclo de vida do servlet... 94 Figura 32 Código da página consultarpessoaform.jsp.... 95 Figura 33 Página pesquisarpessoa.jsp... 96 Figura 34 Modelo em camadas... 97 Figura 35 Front Controller... 98 Figura 36 Arquivo struts.xml... 99 Figura 37 Método consultaunidade.... 100 Figura 38 Diagrama de pacotes... 100 Figura 39 Classes do pacote entidades... 101 Figura 40 Classes do pacote bo... 101 Figura 41 Classes do pacote persistência.... 102 Figura 42 Classes do pacote action... 102

Figura 43 Página Principal... 103 Figura 44 Action setupforinsertorupdate mapeada no arquivo struts.xml.... 104 Figura 45 Método setupforinsertorupdate() implementado na classe CadastrarPessoaAction.... 104 Figura 46 Tela de Cadastro de Dados... 104 Figura 47 Action InsertOrUpdate implementado no arquivo struts.xml.... 105 Figura 48 Método InsertOrUpdate implementado na classe CadastrarPessoaAction.... 105 Figura 49 Método gravapropaquisicao() implementado na classe CadastrarPessoaAction.... 106 Figura 50 Mensagem de erro gerada pelo método gravapropaquisicao() implementado na classe CadastrarPessoaAction.... 107 Figura 51 Comando de persistência declarado no método gravapropaquisicao() implementado na classe CadastrarPessoaAction.... 107 Figura 52 Comando geração do objeto pessoadao declarado no construtor da classe PessoaBO... 107 Figura 53 Chamada do método insert() através do método insertpessoa() implementado na classe PessoaBO... 108 Figura 54 Código do método insert() implementado pela classe PessoaHibernateDAO... 108 Figura 55 Comandos do método gravapropaquisicao() implementado pela classe CadastrarPessoaAction.... 109 Figura 56 Comandos de criação do objeto UnidadeHibernateDAO declarado no construtor da classe UnidadeBO... 109 Figura 57 Comandos do método updateunidade() implementado pela classe UnidadeBO.... 109 Figura 58 Código do método updateunidade() implementado pela classe UnidadeHibernateDAO.... 110 Figura 59 Comando de persistência declarado no método gravapropaquisicao() implementado na classe CadastrarPessoaAction, quando já há histórico da unidade.... 111 Figura 60 Comandos de criação do objeto HistoricoHibernateDAO declarado no construtor da classe HistoricoBO.... 111 Figura 61 Comandos do método updatehistorico() implementado pela classe HistoricoBO... 111 Figura 62 Código do método updatehistorico() implementado pela classe HistoricoHibernateDAO.... 112 Figura 63 Comando de persistência declarado no método gravapropaquisicao() implementado na classe CadastrarPessoaAction, quando não há histórico da unidade.... 112 Figura 64 Comando declarado no método inserthistorico() implementado na classe HistoricoBO... 113

Figura 65 Código do método insert() implementado na classe HistoricoHibernateDAO... 113 Figura 66 Mensagem de sucesso gerada pelo método gravapropaquisicao() implementado na classe CadastrarPessoaAction.... 114 Figura 67 Código do método isertorupdate() implementado na classe CadastrarPessoaAction.... 114 Figura 68 Action insertorupdate mapeada no arquivo struts.xml.... 114 Figura 69 Tela de confirmação de cadastro... 115 Figura 70 Diagrama de Navegabilidade... 120 Figura 71 Tela de Login.... 122 Figura 72 Tela de mensagem de erro no Login... 122 Figura 73 Menu inicial.... 123 Figura 74 Tela de Cadastro de Dados.... 123 Figura 75 Tela com mensagem de erro de CPF... 124 Figura 76 Tela com mensagem de erro, CPF cadastrado como morador em outra unidade.... 124 Figura 77 Tela com mensagem de sucesso ao cadastrar os dados.... 125 Figura 78 Tela que apresenta a lista das pessoas cadastradas... 125 Figura 79 Tela para solicitar a pesquisa dos dados de uma pessoa... 126 Figura 80 Tela que apresenta os dados da pessoa pesquisada.... 126 Figura 81 Tela para solicitar a pesquisa dos dados de uma unidade.... 127 Figura 82 Tela que apresenta os dados da unidade pesquisada... 127 Figura 83 Sistema simplificado de Banco de Dados.... 131 Figura 84 Arquitetura de Modelo de Banco de Dados... 134 Figura 85 Modelo Físico de Banco de Dados... 137 Figura 86 Modelo Lógico de Banco de Dados... 136 Figura 87 - Estrutura Padrão DAO... 140 Figura 88 Arquitetura Hibernate... 143 Figura 89 - Arquivo "hibernate.cfg.xml"... 146 Figura 90 Classe Hibernate Útil.... 146 Figura 91 Classe de persistência HistoricoHibernateDAO.... 148 Figura 92 Classe de entidade Historico... 150

SUMÁRIO Página 1. INTRODUÇÃO 17 1.1. UM BREVE HISTÓRICO... 17 1.2. CENÁRIO ATUAL... 20 1.3. IDENTIFICAÇÃO DO PROBLEMA... 22 1.4. OBJETIVOS... 23 1.4.1. Geral... 23 1.4.2. Específicos... 23 1.5. JUSTIFICATIVA... 23 1.6. ORGANIZAÇÃO DO TRABALHO... 24 2. ESPECIFICAÇÃO DO PROBLEMA 26 3. ANÁLISE E PROJETO 28 3.1. UNIFIED MODELLING LANGUAGE UML... 28 3.2. ETAPAS DA ANÁLISE DE SISTEMA... 29 3.3. REQUISITOS... 30 3.4. REGRAS DE NEGÓCIO... 31 3.5. CLASSES... 33 3.6. CASOS DE USO... 36 3.6.1. Caso de Uso 01: Fazer Login... 37 3.6.2. Caso de Uso 02: Cadastrar Dados... 39 3.6.3. Caso de Uso 03: Listar Pessoas... 42 3.6.4. Caso de Uso 04: Consultar Pessoa... 44 3.6.5. Caso de Uso 05: Consultar Unidade... 46 3.6.6. Caso de Uso 06: Atualizar Histórico... 49 3.6.7. Caso de Uso 07: Pesquisar Histórico... 51 3.6.8. Caso de Uso 08: Registrar Conta a Pagar... 53 3.6.9. Caso de Uso 09: Registrar Pagamento de Contas... 55 3.6.10. Caso de Uso 10: Gerar Taxa de Condomínio... 58 3.6.11. Caso de Uso 11: Receber Taxa de Condomínio... 61 3.6.12. Caso de Uso 12: Gerar Recibo... 64 3.6.13. Caso de Uso 13: Gerar Balancete... 67 3.6.14. Caso de Uso 14: Gerar Histórico... 70 3.7. PROJETO... 72 3.7.1. Diagramas de Sequência de Projeto... 76 4. ARQUITETURA E CÓDIGO 88

4.1. JAVA... 88 4.2. ARQUITETURA MVC... 89 4.3. PADRÕES DE PROJETO... 90 4.3.1. DAO... 91 4.3.2. Business Object... 91 4.3.3. Front Controller... 92 4.3.4. Application Controller... 93 4.4. TECNOLOGIAS UTILIZADAS... 93 4.4.1. Servlet... 93 4.4.2. Páginas JSP... 94 4.4.3. JDBC... 96 4.5. J2EE... 96 4.6. TOMCAT... 97 4.7. IMPLEMENTAÇÃO... 98 4.7.1. Struts... 98 4.7.2. Diagrama de Pacotes... 100 4.7.3. Implementação do Caso de Uso Cadastrar Dados... 103 5. INTERFACE 116 5.1. DIAGRAMA DE NAVEGABILIDADE... 119 6. PERSISTÊNCIA DE DADOS 128 6.1. CONCEITOS DE BANCO DE DADOS... 129 6.2. MYSQL... 131 6.3. MODELAGEM DE BANCO DE DADOS... 134 6.3.1. Modelos... 134 6.3.2. Compreendendo o Modelo... 139 6.4. PADRÃO DE PROJETOS DAO... 139 6.5. FRAMEWORK HIBERNATE... 141 6.5.1. Características Hibernate... 142 6.5.2. Arquitetura do Hibernate... 142 6.5.3. Mapeamento Objeto Relacional... 143 6.6. MECANISMOS DE PERSISTÊNCIA... 148 7. CONCLUSÃO 151 REFERÊNCIAS BIBLIOGRÁFICAS 154 APÊNDICE 158

17 1. INTRODUÇÃO 1.1. UM BREVE HISTÓRICO A instituição da sociedade ocorreu como um movimento dos homens na tentativa de se protegerem dos instintos predatórios de outros homens e de outros animais. A sociedade constituiu-se como forma de proteção contra abusos e excessos, sendo um mecanismo de defesa contra a lei do mais forte. Assim, foram estabelecidas normas de conduta que tornassem possível a convivência entre os homens. Buscou-se domar a agressividade natural do ser humano, para que todos pudessem conviver de forma próxima e participativa. Com isso, estabeleceu-se, então, um conflito entre a necessidade de proteção e a repressão dos instintos (FREUD, 2002). Nasceu, assim, a civilização. Na Grécia antiga, pequenas comunidades se agrupavam em um centro, na tentativa de se protegerem de ataques externos. Denomina-se tal fenômeno de sinecismo, que significa coabitação. Assim, originaram-se as Polis gregas, que deram origem às cidades ocidentais (WIKIPEDIA, 2009). Ainda dentro do processo histórico, na Idade Média, embora organizada a sociedade, a população não se encontrava necessariamente protegida dos abusos dos mais fortes. Como exemplo clássico, é possível observar as relações nos feudos. Os senhores feudais os mais fortes tinham direitos totais sobre a vida de seus servos e camponeses. Nesse momento histórico, a lei do mais forte era, por assim dizer, institucionalizada. Na passagem do século X para o século XI se observa o crescimento populacional, com o conseqüente aumento da demanda por alimentos. O desenvolvimento agrícola não foi suficiente para responder às necessidades da população. Se em determinadas áreas, a produção era excedente, em outros locais se mostrava insuficiente. A solução encontrada foi o comércio. Ocorreu nesse período o êxodo rural, representado pelo deslocamento significativo da população rural para as cidades, sendo que muitas delas se desenvolveram junto a castelos e mosteiros, para se protegerem dentro de seus muros (ABREU, 2009). Foi a Revolução Industrial, um dos marcos da Idade Moderna, que efetivamente desencadeou o processo de urbanização, definida como o aumento da

18 população urbana em relação à rural. Assim, o primeiro país da Europa a se urbanizar foi a Inglaterra. Já em 1850, cinqüenta por cento de sua população morava nas cidades. A aceleração da urbanização dos países desenvolvidos se deu a partir da segunda metade do século XIX (URBANIZAÇÃO DO mundo, 2009). No Brasil, o processo de urbanização foi mais acelerado que nos países da Europa e na América do Norte, embora tenha ocorrido mais tardiamente, na segunda metade do século XX. Como nos demais países, também a industrialização foi o fator desencadeante do êxodo rural (MIRANDA, 2009). A industrialização se intensificou a partir dos governos de Getúlio Vargas (1930 1945), se firmando na administração de Juscelino Kubistchek (1955 1960), com a implantação da indústria automobilística (URBANIZAÇÃO DO Brasil, 2009). De acordo com o Instituto Brasileiro de Geografia e Estatística IBGE até a década de 1960, a maioria da população residia nas áreas rurais. A partir de 1970 houve a inversão, com o predomínio da população urbana (55,92%), como mostra a tabela 1 (BRASIL, 2009b). Tabela 1 População brasileira, segundo os censos demográficos de 1940, 1950, 1960, 1970, 1980, 1991 e contagem de 1996. ANOS ÁREA URBANA ÁREA RURAL TOTAL HABITANTES % HABITANTES % HABITANTES 1940 12.880.182 31,24 28.356.133 68,76 41.236.315 1950 18.782.891 36,16 33.161.506 63,84 51.944.397 1960 31.303.034 44,67 38.767.423 55,33 70.070.457 1970 52.084.984 55,92 41.054.053 44,08 93.139.037 1980 80.436.409 67,59 38.566.297 32,41 119.002.706 1991 110.990.990 75,59 35.834.485 24,41 146.825.475 1996 123.076.831 78,36 33.993.332 21,64 157.070.163 Fonte: IBGE (BRASIL, 2009a). Observa-se ainda, que a urbanização não se deu de forma homogênea no país. Em 2000, apresentava-se mais acentuada nas regiões Sul, Sudeste e Centro-Oeste. Na região Nordeste as áreas litorâneas apresentavam aglomerados mais urbanizados. Em poucas áreas a taxa de urbanização era inferior a 25 por

19 cento, sendo que a região Sudeste apresenta taxa acima de 75 por cento na maioria dos municípios, como mostra a figura 1. Figura 1 Grau de Urbanização, Brasil, 2000. Fonte: IBGE (BRASIL, 2001). Localizada na região sudeste, no estado de Minas Gerais, no Triângulo Mineiro, Uberlândia é considerada a maior cidade do interior do estado e em 2006, a população era estimada em 600.358 habitantes (Tabela 2). Como observado na região Sudeste, sua taxa de urbanização é alta, da ordem de 97,56 por cento, ao considerar-se o censo de 2000. ÁREA Tabela 2 População de Uberlândia, MG, 1996 a 2006. ANOS 1996 2000 2001 2002 2003 2004 2005 2006 Urbana 431.744 488.982 505.167 521.888 539.162 556.133 570.982 585.719 Rural 7.242 12.232 12.637 13.055 13.487 13.909 14.280 14.649 Total 438.986 501.214 517.804 534.943 552.649 570.042 585.262 600.368 Fonte: Prefeitura de Uberlândia (2007).

20 De maneira geral no país, a urbanização desordenada trouxe em si dificuldades para atender às necessidades básicas dos migrantes. Nascem, assim, vários problemas sociais, notadamente o desemprego, a criminalidade e a favelização (MIRANDA, 2009). Consequentemente a moradia se torna um problema a ser equacionado. Dois aspectos tornam-se relevantes para a solução. O primeiro diz respeito ao espaço propriamente dito, não havendo solo suficiente quer seja para a moradia, quer seja para uso comercial, nas áreas mais centrais, enquanto que o segundo ponto se trata de segurança. A solução que se apresenta é a verticalização, ou seja, edificações de vários andares que abrigassem mais de uma propriedade, trazendo resposta à necessidade de espaço, e aumentando a segurança, uma vez que a cotização permite estabelecer mecanismos de proteção, com custo mais acessível. 1.2. CENÁRIO ATUAL Ao se considerar o município de Uberlândia, o número de condomínios tem crescido, embora não se conheça estatística oficial sobre o assunto. Se inicialmente, na década de 1960 os condomínios eram constituídos na área central da cidade em edificações de vários andares, no final da década de 1980 até meados da década de 1990, iniciou-se a construção de pequenas edificações, não mais na região central da cidade. Um dos locais, que nesse período apresentou um grande crescimento desse tipo de condomínio, foi o bairro Santa Maria. Nesse bairro, localiza-se o condomínio do Edifício Porto Seguro, prédio estritamente residencial, composto por três andares, sendo que cada andar abriga duas unidades habitacionais. O síndico do condomínio é um dos proprietários que reside no edifício. Com a difusão dessa forma de associação, foram criadas leis que regulamentam a criação, administração e o convívio entre as pessoas, que foram reconhecidas como condôminos, uma vez que passaram a dividir o domínio da edificação. Inicialmente, a lei 4.591 de 16 de dezembro de 1964 dispunha sobre o condomínio em edificações e as incorporações imobiliárias. Em seu artigo quinto delega ao Código Civil a sua regulamentação: o condomínio por meação de parede, soalhos e tetos das unidades isoladas regular-se-á pelo disposto no Código Civil, no que lhe for aplicável (BRASIL, 1964). Assim, a determinação legal dos condomínios

21 edílicos está no Código Civil Brasileiro, notadamente no Livro III, em seus artigos 1.331 a 1.358. De acordo com a legislação, o síndico seria a pessoa responsável pela administração do condomínio. Embora o papel do síndico se mantenha o mesmo, esse não precisa necessariamente ser um morador, sendo cada vez mais comum a figura de um administrador profissional ou até mesmo uma empresa que assuma as funções administrativas. Também, é comum a existência de empresas de administração que apóiam as atividades do síndico. A profissionalização dessas administrações é uma tendência, pois há condomínios com grande número de unidades, que requerem uma abordagem mais direcionada com embasamento legal. Também, pequenos condomínios estão fazendo uso desses serviços, de modo que os direitos e deveres passam a ser respeitados e exigidos de forma mais conveniente. Há, no mercado várias empresas de administração de condomínio, inclusive sindicatos e associações de empresas, apóiam a gestão de condomínios. Se a revolução industrial imprimiu mudanças profundas na sociedade, respondendo inclusive pela urbanização, a era da informação, também, tem provocado alterações significativas na sociedade. A valorização do capital material tem-se deslocado para a valorização do capital intelectual. A competitividade está diretamente relacionada à gestão e à aplicação do conhecimento. Embora, a administração de um condomínio, sob o ponto de vista do condomínio, não implique em competição com terceiros, a excelência dessa gestão traz ganhos aos condôminos, sejam financeiros ou subjetivos ao se efetivar a possibilidade de desfrutar de forma conveniente o investimento feito na aquisição ou locação do imóvel. Na busca dessa excelência, sistemas de informação que apóiem a gestão, automatizando rotinas, padronizando atividades e armazenado informações se tornam ferramentas importantes no processo de administração de condomínios. Existem no mercado vários softwares voltados para administração de condomínios. Alguns são disponíveis para venda outros de uso exclusivo da administradora, sendo condicionado à contratação de serviços da empresa. A maioria é acessada via Web, tanto pelo síndico, como pelos condôminos que têm acesso às informações de despesa e, exclusivamente, às transações de sua unidade. Algumas empresas apresentam vídeos demonstrativos do software, outras

22 permitem, inclusive, o uso de uma versão para teste. As funcionalidades mais freqüentes oferecidas são: - cadastros gerais; - cálculos automáticos: rateios de despesas; - mapas demonstrativos; - emissão de boletos bancários e demonstrativos de despesas; - taxas a receber; - contas a pagar; - tesouraria e fluxo de caixa; - receitas e despesas regulares; - balancetes; - relatórios diversos. Fazer uso de sistemas padronizados ou buscar softwares customizados é uma decisão importante. As duas possibilidades apresentam vantagens e desvantagens. Sistemas já desenvolvidos podem ter menor custo e apresentar mais funcionalidades, na medida em que são aprimorados mediante solicitações dos vários clientes. Já softwares desenvolvidos para um cliente específico podem atender às necessidades de forma mais objetiva. 1.3. IDENTIFICAÇÃO DO PROBLEMA Optou-se pelo desenvolvimento de um sistema de informação customizado, implicando em uma análise correta dos requisitos que o software deverá atender, sejam eles funcionais ou não funcionais. Obter junto ao cliente de forma clara as suas necessidades é fundamental para o desenho e implementação do sistema. O sistema desenvolvido nesse trabalho para um pequeno condomínio demandará uma atenção maior, uma vez que esse cliente realiza as atividades de forma intuitiva, sem o registro de processos.

23 1.4. OBJETIVOS 1.4.1. Geral Desenvolver um aplicativo Web que apóie a gestão de pequenos condomínios habitacionais, no que tange ao gerenciamento, a administração e o armazenamento dos dados de moradores e proprietários, assim como das operações financeiras. 1.4.2. Específicos - Levantar os requisitos do sistema; - documentar os casos de uso; - elaborar o diagrama conceitual (diagrama de classe de negócio) - elaborar os diagramas de seqüência de análise - implementar o sistema utilizando a linguagem de programação Java; - utilizar o Desing Patterns J2EE; - implementar o aplicativo em três camadas de acordo com o modelo MVC; - implementar o diagrama de classes no nível de projeto; - implementar a camada de apresentação através de Front Controller; - implementar a camada de negócio através do Business Object; - implementar a camada de integração utilizando DAO Data Access Object; - utilizar o Hibernate com annottations para o mapeamento objeto-relacional; - utilizar o Struts2 com annottations e - utilizar o MySQL como banco de dados. 1.5. JUSTIFICATIVA Embora as atividades de gestão de um condomínio sejam em princípio semelhantes, a abordagem pode ser diferente. Condomínios com muitas unidades se tornam mais complexos, em função da quantidade de pessoas e consequentemente a sua gestão implicará em atividades e rotinas diferentes das executadas naqueles com

24 poucas unidades. Há casos em que os moradores fazem uso de cartão de identificação e não raro há catracas eletrônicas na portaria. Também é comum em grandes condomínios a exigência de identificação, com registro de documento de identidade dos visitantes. Outros condomínios possuem uma administração mais informal, o que não significa que não deva ter caráter legal. Ao se propor o desenvolvimento de um sistema de informação para um condomínio com poucas unidades habitacionais, temse a possibilidade de manter uma administração mais próxima e acolhedora. Assim, alia-se o profissionalismo ao sentimento de proximidade, próprio de pequenos grupos de pessoas, pois as relações tendem a ser mais próximas e pessoais. Assim, desenvolver um software simplificado para a gestão de pequenos condomínios traz o desafio de associar a tecnologia a uma gestão personalizada de pequenos espaços residenciais, quando o mercado parece ofertar propostas mais complexas. Esse diferencial por si só justifica o desenvolvimento de uma nova ferramenta, para atender a essa clientela. 1.6. ORGANIZAÇÃO DO TRABALHO Este foi um trabalho realizado em grupo, sendo que os membros se envolveram em todas as etapas para a realização deste relatório. Os capítulos iniciais, Introdução e Especificação do Problema e, também, o capítulo final, Conclusão foram escritos em conjunto, não havendo uma responsabilidade maior por parte de algum integrante do grupo. Já, os demais capítulos que correspondem às etapas de desenvolvimento do sistema tiveram cada um, um líder que assumiu o direcionamento de sua elaboração. Assim, os demais seis capítulos abordam os seguintes temas: o sumário executivo. Capítulo 2: Especificação do problema Traz as informações sobre o condomínio e apresenta de forma sucinta Capítulo 3: Análise e projeto do sistema Apresenta o referencial teórico sobre análise de projeto, traz, ainda, os diagramas classe, de casos de uso, de sequências, tanto sob a ótica da análise, quanto sob o ponto de vista do projeto. Capítulo 4: Arquitetura e código

25 Além discorrer sobre os conceitos nos quais se apoiou o desenvolvimento da solução, este capítulo apresenta, ainda, a arquitetura empregada e o código da implementação. Capítulo 5: Interface Nesse capítulo são apresentadas as interfaces para comunicação entre o sistema e os usuários. Cita, ainda, referencial teórico, sobretudo em relação ao uso de cores. Diferente dos demais capítulos, esse, em especial, não teve uma autoria definida. Porém, os autores consideram a sua apresentação como mínima, mas importante para a visão integral do sistema, mesmo que a abordagem da interface seja superficial. Capítulo 6: Persistência de dados Apresenta o processo de armazenagem e recuperação dos dados. Resgata os conceitos e tecnologias que foram empregados durante o desenvolvimento do sistema. Capítulo 7: Conclusões Nesta parte são apresentadas as conclusões observadas pelo grupo considerando-se os objetivos que nortearam a realização deste trabalho.

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

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

28 3. ANÁLISE E PROJETO Maria Margaret de Vasconcellos Lemos Análise consiste em um método para se conhecer um problema ou situação, em que se divide o objeto do estudo em partes para o exame minucioso de cada componente. Voltada para desenvolvimento de software, a análise é o processo através do qual se busca conhecer o negócio do cliente, para produzir um modelo que espelhe a realidade. O principal objetivo da análise de sistemas é realizar um mapeamento prévio do comportamento requerido para os elementos de modelagem que serão implementados posteriormente na fase de construção (SILVA, 2009). Assim, modelagem é a concepção de sistemas de informações, antes que sejam codificados. É, ainda, parte essencial do desenvolvimento de grandes projetos, sendo, também, importante para aqueles de médio e pequeno porte. Tratase de uma forma de visualizar o projeto e verificar se os requisitos estão sendo atendidos antes da implementação (OBJECT MANEGEMMENT GROUP, 2009). Dada a importância da elaboração de projetos de softwares, foi definida uma linguagem padrão para a sua execução, a Unified Modeling Language, UML. 3.1. UNIFIED MODELLING LANGUAGE UML As linguagens se destinam a comunicar algo através de vocabulários e das regras de interação entre seus vocábulos. Assim, a UML indica como criar e ler modelos bem formados. Um modelo escrito empregando-se a UML poderá ser interpretado sem ambigüidades por outro desenvolvedor ou outra ferramenta. Os blocos de construção da UML são os itens, os relacionamentos e os diagramas. Os itens são as abstrações identificadas e podem ser de quatro tipos. Os itens estruturais representam elementos conceituais ou físicos. São as partes estáticas do modelo, enquanto que os itens comportamentais são as partes dinâmicas, definidos pelos verbos, uma vez que representam o comportamento no tempo e espaço. Os itens de agrupamento são as partes organizacionais. Correspondem aos pacotes que são meramente conceituais e agregam os itens

29 estruturais, comportamentais e ainda outros itens de grupo, quando necessário. Já, os itens anotacionais são aqueles que explicam o modelo. Os relacionamentos definem a interação entre os elementos podendo ser de quatro tipos. Dependência, acontece quando a alteração do item independente implica na alteração semântica do item dependente. A associação descreve a conexão entre os objetos, podendo ser uma agregação que define um relacionamento estrutural entre o todo e suas partes. O relacionamento de generalização implica em objetos especializados, os filhos, que podem ser substituídos por objetos generalizados, os pais. O quarto tipo de relacionamento, a saber, a realização, trata-se de um contrato em que um classificador especifica o que outro classificador garante executar, como os métodos definidos pela interface que a classe deve implementar. Os diagramas são representações gráficas que oferecem vários ângulos de visualização de um sistema. São nove os diagramas definidos pela UML, sendo que cada um tem função bem definida. O diagrama de classes exibe o conjunto de classes, interfaces, colaborações e os relacionamentos, enquanto que o diagrama de objeto apresenta os objetos e seus relacionamentos. Já, o diagrama de casos de uso representa o conjunto de caos de uso e atores, sendo importante para organização e modelagem de comportamento do sistema. Para registrar a interação há o diagrama de seqüência cujo foco principal é a ordem temporal das mensagens e o diagrama de colaboração que privilegia a organização estrutural entre os objetos. Outro diagrama, o de estado, exibe o estado, transição, eventos e atividades. Traz, portanto, uma visão dinâmica do sistema, sendo o diagrama de atividade um tipo especial de diagrama de estado, pois apresenta o fluxo de uma atividade para outra. A visão estática da implementação do sistema pode ser representada pelo diagrama de componentes que apresenta as organizações e de pendências entre um conjunto de componentes. Já a visão estática de uma arquitetura é oferecida pelo diagrama de implantação (BOOCH, RUMBAUGH & JACOBSON, 2000). 3.2. ETAPAS DA ANÁLISE DE SISTEMA A primeira etapa da análise de um sistema consiste na descoberta de informações sobre o domínio da aplicação, quais as funcionalidades requeridas, qual

30 o desempenho que o sistema deve apresentar as restrições de hardware, dentre outras questões. Responder a essas e outras perguntas envolvem grande número de pessoas de diferentes áreas da empresa contratante. Essa fase é muito importante, pois quanto mais claras as especificações, mais fiel à realidade será o modelo. Nesta fase são empregadas técnicas de elucidação de requisitos, com o intuito de aumentar o comprometimento do cliente e desenvolvedores, com a solução que se deseja construir. É muito importante que os requisitos sejam extraídos de maneira correta e objetiva. Nessa etapa são identificadas as regras de negócio e os requisitos do sistema, que podem ser de dois tipos, os funcionais e os não funcionais. 3.3. REQUISITOS Os requisitos descrevem de modo claro, sem ambigüidades, conciso e consistente todos os aspectos significativos do sistema proposto. Eles devem permitir que os desenvolvedores construam um sistema que satisfaça os clientes. Um requisito é considerado como funcional quando descreve um serviço ou função a ser realizada. Já requisitos não funcionais coincidem com restrições ou condições impostas ao sistema ou ao seu desenvolvimento (SILVA, BONIN & PALUDO, 2007). O quadro 1 apresenta a relação dos requisitos funcionais e não funcionais levantados para o desenvolvimento do sistema em questão. Com o levantamento dos requisitos é possível identificar as classes que estarão envolvidas no desenvolvimento do software e o reconhecimento dos principais processos da empresa que definirão os casos de uso do sistema. Uma vez estabelecidos e documentados os casos de uso, passa-se à etapa seguinte que descreve as interações ocorridas no sistema, muito bem representadas pelos diagramas de sequência.

31 Requisitos funcionais 1. Cadastrar proprietários; 2. cadastrar moradores; 3. registrar contas a pagar; 4. calcular o valor da taxa de condomínio; 5. registrar recebimento mensal da taxa de condomínio; 6. registrar pagamentos; 7. emitir recibos; 8. gerar prestação de contas. Requisitos não-funcionais 1. Ser compatível com o Windows XP; 2. permitir o acesso via Web; 3. usar a linguagem Java; 4. usar o contêiner web apache; 5. usar banco de dados MySQL Quadro 1 Requisitos do sistema. 3.4. REGRAS DE NEGÓCIO As regras de negócio dizem respeito às operações, definições e restrições de uma organização para alcançar seus objetivos. São usadas para alcançar os objetivos de uma empresa, a comunicação entre ela e terceiros e, também, demonstrar as obrigações legais, operar mais eficientemente, automatizar operações, dentre outras (ARAUJO, 2009). As regras de negócio podem ter origens variadas. Há aquelas que são definidas por dispositivos legais, como o percentual a ser pago a título de imposto ou o valor permitido para o cálculo de juros ou multas. Outras definem as pessoas responsáveis por determinadas operações no sistema. Existem, ainda, regras para cálculos internos, a obrigatoriedade de validação de dados, como por exemplo, no sistema proposto, o CPF a ser cadastrado deverá ser uma sequência numérica válida. Para o sistema de condomínio, foram identificadas e documentadas dez regras de negócio como apresenta o quadro 2 a seguir.

32 Nome Permissão RN - 01 Descrição Somente poderão operar o sistema as pessoas autorizadas. Nome Cadastro de dados pessoais RN - 02 Descrição Somente serão cadastradas as pessoas com CPF válido. Nome Cadastro de moradores RN - 03 Descrição Para cadastrar o morador de uma unidade é preciso ter registrado a mudança do morador anterior. Assim, somente será cadastrado o morador de uma unidade, quando não houver morador já cadastrado. Nome Cadastro de proprietário RN - 04 Descrição Para cadastrar o proprietário de uma unidade é preciso ter registrado a venda realizada pelo proprietário anterior. Assim, somente será cadastrado o proprietário de uma unidade, quando não houver proprietário já cadastrado. Nome Lançamento de contas a pagar RN - 05 Descrição Todas as contas a pagar serão lançadas no sistema. Nome Geração da taxa de condomínio RN 06 Descrição A taxa de condomínio será gerada sempre no dia 1º do mês. Nome Cálculo da taxa de condomínio RN 07 Descrição O valor da taxa de condomínio de cada unidade é calculado pela soma dos pagamentos de contas realizados no mês anterior, dividido por 6. Nome Data para o pagamento da taxa de condomínio RN 08 Descrição A taxa de condomínio deverá ser paga até o dia 10 do mês subseqüente. Caso o dia 10 não seja dia útil, a data do pagamento será automaticamente transferida para o próximo dia útil.

33 Nome Pagamento da taxa de condomínio RN - 09 Descrição Pagamentos realizados após a data estabelecida serão acrescidos de juros de 2% ao mês e multa de 3%. Nome Registro de pagamento da taxa de condomínio RN - 10 Descrição Todos os pagamentos de taxa de condomínio serão registrados no sistema. Quadro 2 Regras de Negócio. 3.5. CLASSES O diagrama de classes é considerado por vários autores como o mais importante e utilizado diagrama da UML. Ele apresenta uma visão estática da organização das classes do sistema, permitindo além da visualização das classes e de seus atributos e métodos, a representação de seus relacionamentos, como estas se complementam e a transmissão da informação dentro do sistema (SILVA, 2007). Durante o processo de análise, ao se delinear o sumário executivo, como regra básica para nortear o analista, considera-se que os substantivos encontrados sugerem as classes de negócios necessárias para o desenvolvimento da aplicação. Da mesma forma, os verbos descreveriam os casos de usos. Na verdade, o levantamento das classes e dos casos de uso de um sistema, muitas vezes, acontece de forma simultânea. A partir dessa visão e da proposta de apresentar o diagrama de casos de uso seguido pelas especificações de cada caso de uso e dos respectivos diagramas de sequência, serão apresentadas inicialmente as classes e os diagrama de classes correspondente. O processo de levantamento das necessidades e requisitos evidenciou a necessidade de implementação de sete classes de negócio para o desenvolvimento do sistema, conforme definidas abaixo: Classe UsuarioEntidade Essa classe registra o nome de usuário e a respectiva senha para permitir a operação do sistema.

34 Classe Pessoa É responsável pelo registro de todas as pessoas que se relacionam com o imóvel, sejam moradores ou proprietários. Os atributos dessa classe são: nome, CPF e telefone. Classe Unidade Registra todas as unidades habitacionais existentes, ou seja, os apartamentos. Mantém o registro do atual morador e atual proprietário. Seus atributos são: número, morador e proprietário. Classe Histórico Essa classe é responsável por manter o registro de todos os moradores e proprietários de cada uma das unidades, registrando inclusive a data inicial e a data do término da relação de cada pessoa com a unidade. Por isso tem como atributos: unidade, proprietário, prodtaquisicao, pro_dtvenda, morador, mor_dtentrada e mor_dtsaida. Classe ContasAPagar Essa classe é responsável pelo registro de todas as contas que o condomínio deverá pagar em função de bens adquiridos ou serviços recebidos. Os atributos dessa classe são: datavencimento, descricaoconta, valorconta e mesref. Classe TaxaCondomínio Essa classe gera e mantém o valor mensal a ser pago pelos condôminos a título de taxa de condomínio. Seus atributos são: mesref, valortaxa, datageracao, datavencimento. Classe LancamentoMes É responsável pelo registro das operações financeiras do condomínio mantendo os dados dos pagamentos e dos recebimentos das taxas de condomínio. Os atributos dessa classe são: data, tipo, descrição, juros, multa e valorfinal. Na etapa de análise foi usado o Enterprise Architect ferramenta desenvolvida para a análise, modelagem e manutenção de softwares, que emprega a UML e gera a documentação do sistema. Como um dos resultados do emprego dessa ferramenta foi o diagrama de classes obtido pela interação das classes descritas anteriormente (Figura 3).

35 Figura 3 Diagrama de classes de negócio.

36 3.6. CASOS DE USO Conceitualmente, casos de uso dizem respeito às principais atividades da empresa ligadas ao sistema a ser implementado, sendo assim, cada caso de uso está ligado a um conjunto de requisitos funcionais do sistema (WAZLAWICK, 2004). A simplicidade de um diagrama de casos de uso permite a observação das funcionalidades, os usuários envolvidos e as possíveis integrações com sistemas externos (YOSHIMA, 2005). Foram identificados quatorze casos de uso, conforme a figura 4. Figura 4 Diagrama de casos de uso. A interação com o sistema é realizada pelo Síndico, pessoa responsável pela gestão do condomínio. Outras pessoas, que por ventura operem o sistema, somente o farão com a autorização do síndico e as permissões e responsabilidades serão idênticas às dele. Por isso, para o desenvolvimento do aplicativo, considerou-se, apenas a existência de um único ator.

37 3.6.1. Caso de Uso 01: Fazer Login Nesse caso de uso, o síndico solicita entrar no sistema e para isso informa os dados necessários para obter a permissão de operar o sistema, conforme especificado no quadro 3. Nome Fazer Login CSU - 01 Sumário Este caso de uso descreverá os procedimentos para realizar o login no sistema Ator primário: Síndico. Ator(es) secundário(s): Não há. Pré-condição: O usuário estar cadastrado. Pós-condição: O login foi realizado. 1. O síndico inicia sistema. Fluxo Principal 2. O sistema apresenta o formulário para o login. 3. O síndico informa o usuário e a senha. 4. Sistema verifica os dados e encerra o caso de uso Fluxo Alternativo: Não há. Fluxo de Exceção [3]: Dados incorretos a. O sistema informa que os dados estão incorretos e volta ao item 2. RN01 Regras de Negócio Associadas Quadro 3 Especificação do caso de uso: Fazer Login.

38 O diagrama de sequência desse caso de uso apresenta o fluxo das mensagens que são trocadas entre os componentes do sistema para permitir que o usuário possa operar o sistema, como mostra a figura 5. Figura 5 Diagrama de sequência do caso de uso: Fazer Login. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Interface de Fazer Login: representa a classe de fronteira desse caso de uso. Permite que o usuário informe os dados para realizar o login no sistema, de modo que possa operar o sistema. b) Controlador de Fazer Login: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre a interface Fazer Login e a classe Usuários. c) Usuários: representa a classe de entidade deste caso de uso. Sua função é armazenar os atributos responsáveis por realizar a autenticação dos dados do usuário. d) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. É apresentada após a autenticação do login.

39 3.6.2. Caso de Uso 02: Cadastrar Dados Neste caso de uso, o síndico fará o cadastro de uma pessoa que terá relação com o condomínio de moradia ou de propriedade. O sistema não permitirá o cadastro de morador ou proprietário de uma unidade se outra pessoa já estiver cadastrada nessa situação. Para isso é necessário registrar, anteriormente a saída ou a venda da unidade (Quadro 4). Nome Cadastrar Dados CSU - 02 Sumário Este caso de uso descreverá os procedimentos realizados para o cadastro dos dados pessoais de proprietários ou moradores e a unidade com a qual manterão relação. Ator primário: Síndico. Ator(es) secundário(s): Não há. Pré-condição: Não haver registro de pessoa na unidade, na condição a ser registrada. Pós-condição: O cadastro foi realizado. Fluxo Principal 1. O síndico solicita o cadastro de dados pessoais. 2. O sistema apresenta o formulário para o preenchimento dos dados. 3. O síndico realiza o preenchimento do formulário. 4. O síndico confere os dados inseridos no formulário e confirma. 5. Sistema registra o cadastro e encerra o caso de uso Fluxo Alternativo: Não há. Fluxo de Exceção [4A]: CPF inválido a. O sistema informa que o CPF não é válido e volta ao item 3. Fluxo de Exceção [4B]: Existe morador ou proprietário cadastrado a. O sistema informa que não é possível cadastrar a pessoa na condição escolhida e encerra o caso de uso. Regras de Negócio Associadas RN02, RN03 e RN04 Quadro 4 Especificação do caso de uso: Cadastrar Dados.

40 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 6). Figura 6 Diagrama de sequência do caso de uso: Cadastrar Dados. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita o cadastro de uma pessoa. b) Controlador de Cadastrar Dados: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre as interfaces e as classes de entidades Pessoa, Unidade e Histórico, responde, ainda, pela validação do CPF. c) Interface de Cadastrar Dados: representa a classe de fronteira desse caso de uso. Permite que o usuário informe os dados para cadastrar uma pessoa no sistema.

41 d) Pessoa: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das pessoas cadastradas, nome; CPF e telefone. e) Unidade: representa outra classe de entidade deste caso de uso. Sua função é armazenar os atributos das unidades, o número da unidade, a pessoa que é moradora, assim como a pessoa que é proprietária da unidade em questão. f) Histórico: representa a terceira e última classe de entidade deste caso de uso. Sua função é armazenar os atributos das relações entre as pessoas e as unidades. Mantendo os dados mesmo após o término dessa relação. Os atributos dessa classe são: o número da unidade; a pessoa moradora; a data de entrada e a data de saída do morador; a pessoa que é proprietária; a data de aquisição e a data de venda relativa a esse proprietário.

42 3.6.3. Caso de Uso 03: Listar Pessoas Esse caso de uso descreve os procedimentos que serão realizados para o sistema apresentar a relação das pessoas que já se encontram cadastradas, como mostra o quadro 5. Nome Listar Pessoas CSU - 03 Sumário Este caso de uso descreve os procedimentos realizados para apresentar os dados de todas as pessoas cadastradas. Ator primário: Síndico. Ator(es) secundário(s): Não há. Pré-condição: Ter pessoas cadastradas no sistema. Pós-condição: A lista com os dados das pessoas cadastradas é apresentada. Fluxo Principal 1. O síndico solicita listar todas as pessoas cadastradas. 2. O sistema apresenta o cadastro de pessoas com CPF, nome e o telefone de cada pessoa. 3. O caso de uso é encerrado. Fluxo Alternativo: Não há. Fluxo de Exceção [4]: O cadastro está vazio a. O sistema emite mensagem informando que o cadastro está vazio. b. O caso de uso é encerrado Regras de Negócio Associadas Quadro 5 Especificação do caso de uso: Listar Pessoas. O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 7).

43 Figura 7 Diagrama de sequência do caso de uso: Listar Pessoas. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita a lista das pessoas cadastradas. b) Controlador de Listar Pessoas: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial e a classe de entidade Pessoa, responde, ainda, pela verificação se a lista não está vazia. c) Interface de Listar Pessoas: representa a classe de fronteira desse caso de uso, apresenta a lista das pessoas cadastradas. d) Pessoa: representa a classe de entidade deste caso de uso. Sua função é armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.

44 3.6.4. Caso de Uso 04: Consultar Pessoa Esse caso de uso descreve os procedimentos que serão realizados para a consulta dos dados de uma pessoa já cadastrada no sistema, como mostra o quadro 6. Nome Consultar Pessoa CSU - 04 Sumário Este caso de uso descreve os procedimentos realizados para consultar o cadastro de uma pessoa. Ator primário: Síndico. Ator(es) secundário(s): Não há. Pré-condição: A pessoa estar cadastrada no sistema. Pós-condição: Os dados da pessoa foram recuperados. Fluxo Principal 1. O síndico solicita consultar o cadastro de uma pessoa. 2. O sistema solicita o CPF da pessoa. 3. O síndico informa o CPF. 4. O sistema apresenta o nome e o telefone da pessoa. 5. O caso de uso é encerrado. Fluxo Alternativo [4]: A pessoa não está cadastrada a. O sistema emite mensagem informando que a pessoa não foi cadastrada. b. O caso de uso é encerrado. Fluxo de Exceção [3]: O CPF informado não é válido a. O sistema emite mensagem informando que o CPF não é válido. b. O sistema volta ao item 2. c. O caso de uso é encerrado Regras de Negócio Associadas RN 02 Quadro 6 Especificação do caso de uso: Consultar Pessoa. O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 8).

45 Figura 8 Diagrama de sequência do caso de uso: Consultar Pessoa. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita a consultar cadastro. b) Controlador de Consultar Pessoa: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Consultar Pessoa e a classe de entidade Pessoa. Responde, ainda, pela validação do CPF. c) Interface de Consultar Pessoas: representa a classe de fronteira desse caso de uso. Disponibiliza ao usuário o formulário para obter o CPF da pessoa que será consultada e apresenta ao síndico o nome e o telefone da pessoa consultada. d) Pessoa: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.

46 3.6.5. Caso de Uso 05: Consultar Unidade Esse caso de uso descreve os procedimentos que serão realizados para a consulta dos dados de uma unidade, como mostra o quadro 7. Nome Consultar Unidade CSU - 05 Sumário Este caso de uso descreve os procedimentos realizados para consultar os dados de cadastro de uma unidade. Ator primário: Síndico. Ator(es) secundário(s): Não há. Pré-condição: A unidade estar cadastrada no sistema. Pós-condição: Os dados da unidade foram recuperados. Fluxo Principal 1. O síndico solicita a consulta de dados de uma unidade. 2. O sistema solicita o número da unidade. 3. O síndico informa o número. 4. O sistema apresenta o morador e o proprietário da unidade. 5. O caso de uso é encerrado. Fluxo Alternativo: Não há. Fluxo de Exceção: Não há. Regras de Negócio Associadas Quadro 7 Especificação do caso de uso: Consultar Unidade. O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 9).

47 Figura 9 Diagrama de sequência do caso de uso: Consultar Unidade. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita consultar os dados de uma unidade. b) Controlador de Consultar Unidade: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Consultar Unidade e as classes de entidades Unidade e Pessoa. c) Interface de Consultar Unidade: representa a classe de fronteira desse caso de uso. Disponibiliza ao síndico o formulário para obter o número da unidade a ser consultada e como resposta, apresenta o nome do morador e do proprietário da unidade consultada. d) Unidade: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das unidades, o número da unidade, a pessoa

48 que é moradora, assim como a pessoa que é proprietária da unidade em questão. e) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.

49 3.6.6. Caso de Uso 06: Atualizar Histórico Esse caso de uso descreve os procedimentos que serão realizados para atualizar os dados do histórico de uma unidade. Nesse caso de uso, as regras de negócio associadas, determinam que o mesmo seja executado e não interferem no processo de sua realização. Sendo assim, não geram fluxo de exceção, como mostra o quadro 8. Nome Atualizar Histórico CSU - 06 Este caso de uso descreverá os procedimentos realizados para Sumário atualizar os dados do histórico de determinada unidade. Ator primário: Síndico Ator(es) secundário(s): Não há Pré-condição: Haver histórico anterior em aberto. Pós-condição: O histórico foi atualizado. Fluxo Principal 1. O síndico solicita a atualização o histórico de uma unidade. 2. O sistema apresenta o formulário para a atualização dos dados do histórico de uma unidade. 3. O síndico realiza o preenchimento do formulário. 4. O síndico confere os dados inseridos no formulário e confirma. 5. Sistema registra a atualização e encerra o caso de uso Fluxo Alternativo [3A]: Cadastro de venda a. O síndico informa que é registro de venda do imóvel. Fluxo Alternativo [3B]: Cadastro de saída a. O síndico informa que é registro de saída do imóvel. Fluxo de Exceção: Não há. Regras de Negócio Associadas RN 03 e RN 04 Quadro 8 Especificação do caso de uso: Atualizar Histórico.

50 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 10). Figura 10 Diagrama de sequência do caso de uso: Atualizar Histórico. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita atualizar os dados de histórico de uma unidade. b) Controlador de Atualizar Histórico: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Atualizar Histórico e as classes de entidade Histórico e Unidade. c) Interface de Atualizar Histórico: representa a classe de fronteira desse caso de uso. Disponibiliza ao usuário o formulário para obter os dados que deverão ser atualizados. d) Histórico: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das unidades, o número da unidade, a pessoa que é moradora, assim como a pessoa que é proprietária da unidade em questão. e) Unidade: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das unidades, o número da unidade, a pessoa

51 que é moradora, assim como a pessoa que é proprietária da unidade em questão. 3.6.7. Caso de Uso 07: Pesquisar Histórico Esse caso de uso descreve os procedimentos que serão realizados para pesquisar os dados de histórico de uma unidade, como mostra o quadro 9. Nome Pesquisar Histórico CSU - 07 Sumário Este caso de uso descreve os procedimentos realizados para pesquisar o histórico de uma dada unidade. Ator primário: Síndico. Ator(es) secundário(s): Haver histórico registrado anteriormente. Pré-condição: Não há. Pós-condição: A lista com o histórico da unidade é apresentada. Fluxo Principal 1. O síndico solicita a pesquisa do histórico. 2. O sistema solicita o número da unidade para a pesquisa. 3. O síndico informa o número da unidade. 4. O sistema exibe os dados. 5. O caso de uso é encerrado. Fluxo Alternativo [4A]: O cadastro está vazio a. O sistema emite mensagem informando que não há registro de histórico da unidade. b. O caso de uso é encerrado. Fluxo de Exceção: Não há. Regras de Negócio Associadas Quadro 9 Especificação do caso de uso: Pesquisar Histórico.

52 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 11). Figura 11 Diagrama de sequência do caso de uso: Pesquisar Histórico. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita pesquisar os dados de histórico. b) Controlador de Pesquisar Histórico: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Pesquisar Histórico e a classe de entidade Histórico. c) Interface de Atualizar Histórico: representa a classe de fronteira desse caso de uso. Disponibiliza ao síndico o formulário para que informe qual unidade deverá ter o histórico pesquisado. d) Histórico: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das unidades, o número da unidade, a pessoa que é moradora, assim como a pessoa que é proprietária da unidade em questão.

53 3.6.8. Caso de Uso 08: Registrar Conta a Pagar Esse caso de uso descreve os procedimentos que serão realizados para registrar contas a pagar. Embora haja regra de negócio envolvida na realização desse caso de uso, esta não interfere em sua execução, apenas determina que deve ser executado, como mostra o quadro 10. Nome Registrar Contas a Pagar CSU - 08 Sumário Este caso de uso apresenta os passos para o registro das contas a pagar. Ator primário: Síndico. Ator(es) secundário(s): Não há. Pré-condição: Não há. Pós-condição: A conta foi registrada. Fluxo Principal 1. O sindico solicita o registro de contas a pagar. 2. O sistema apresenta as opções do tipo de conta a ser registrada. 3. O síndico escolhe o tipo de conta. 4. O sistema solicita os dados da conta. 5. O sistema registra as informações no banco de dados. 6. O caso de uso é encerrado. Fluxo Alternativo: Não há. Fluxo de Exceção: Não há. Regras de Negócio Associadas RN 05 Quadro 10 Especificação do caso de uso: Registrar Conta a Pagar. O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 12).

54 Figura 12 Diagrama de sequência do caso de uso: Registrar Contas a Pagar. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita registrar uma conta que deverá ser paga posteriormente. b) Controlador de Registrar Contas a Pagar: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Registrar Contas a Pagar e a classe de entidade Contas a Pagar. c) Interface de Contas a Pagar: representa a classe de fronteira desse caso de uso. Disponibiliza ao usuário o formulário para preenchimento dos dados da conta em questão. d) Contas a Pagar: representa a classe de entidade deste caso de uso. Sua função é armazenar os atributos das contas que serão pagas, a data de vencimento, a descrição e o valor da conta e também, o mês de referência.

55 3.6.9. Caso de Uso 09: Registrar Pagamento de Contas Esse caso de uso descreve os procedimentos que serão realizados para registrar o pagamento de contas, como mostra o quadro 11. Nome Registrar Pagamento de Contas CSU - 09 Sumário Este caso de uso apresenta os procedimentos para o registro dos pagamentos realizados pelo condomínio. Ator primário: Síndico. Ator(es) secundário(s): não há. Pré-condição: A conta a pagar ter sido cadastrada anteriormente. Pós-condição: O pagamento da conta foi registrado. Fluxo Principal 1. O síndico solicita o registro do pagamento de contas. 2. O sistema apresenta as contas já cadastradas. 3. O síndico seleciona a conta. 4. O sistema apresenta as informações da conta e solicita o preenchimento dos dados complementares. 5. O síndico informa os dados. 6. O sistema registra as informações. 7. O sistema encerra o caso de uso. Não há. Fluxo Alternativo: Fluxo de Exceção [2]: Não há conta cadastrada. a) O sistema informa que não há conta cadastrada. b) O sistema encerra o caso de uso. Fluxo de Exceção [4]: Não há conta para pagar. a. O sistema informa que não há conta para pagar. b. O sistema encerra o caso de uso. Regras de Negócio Associadas RN 05 Quadro 11 Especificação do caso de uso: Registrar Pagamento de Contas.

56 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 13). Figura 13 Diagrama de sequência do caso de uso: Registrar pagamento de Contas. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita registrar o pagamento de uma conta. b) Controlador de Registrar Pagamento de Contas: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Registrar Pagamento de Contas, e as classes de entidade Contas a Pagar e Lançamento Mês. c) Interface de Registrar Pagamento de Contas: representa a classe de fronteira desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento dos dados para o pagamento de uma conta. Na sequência apresenta as contas que podem ser pagas para que o síndico escolha a que irá pagar e informe os dados do pagamento.

57 d) Contas a Pagar: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das contas que serão pagas, a data de vencimento, a descrição e o valor da conta e também, o mês de referência. e) Lançamento Mês: corresponde a outra classe de entidade envolvida nesse caso de uso. Sua função é armazenar os atributos dos lançamentos financeiros, data, tipo, descrição, juros, multa e valor final.

58 3.6.10. Caso de Uso 10: Gerar Taxa de Condomínio Esse caso de uso descreve os procedimentos que serão realizados para registrar o pagamento de contas, como mostra o quadro 12. Nome Gerar Taxa de Condomínio CSU - 10 Sumário Este caso de uso descreve as etapas para gerar as taxas mensais de condomínio. Ator primário: Síndico. Ator(es) secundário(s): Não há. Pré-condição: Haver contas a pagar cadastradas anteriormente. Pós-condição: O valor da taxa ter sido calculado. Fluxo Principal 1. O síndico solicita a geração da taxa mensal de condomínio. 2. O sistema solicita o período de referência da taxa a ser gerada. 3. O síndico informa o período. 4. O sistema gera e apresenta a taxa de condomínio do período solicitado. 5. O caso de uso é encerrado. Fluxo Alternativo: Não há. Fluxo de Exceção [4]: Não há conta cadastrada. a. O sistema informa que não há contas cadastradas e retorna ao item 4. RN05, RN06 e RN 07 Regras de Negócio Associadas Quadro 12 Especificação do caso de uso: Gerar Taxa de Condomínio.

59 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 14). Figura 14 Diagrama de sequência do caso de uso: Gerar Taxa de Condomínio. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o usuário solicita a geração da taxa de condomínio de um determinado mês. b) Controlador de Gerar Taxa de Condomínio: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Gerar Taxa de Condomínio, e as classes de entidade Contas a Pagar e Taxa de Condomínio. c) Interface de Gerar Taxa de Condomínio: representa a classe de fronteira desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento dos dados para a geração da taxa de condomínio de um determinado mês.

60 d) Contas a Pagar: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das contas que serão pagas, a data de vencimento, a descrição e o valor da conta e também, o mês de referência. e) Taxa de Condomínio: corresponde a outra classe de entidade envolvida nesse caso de uso. Sua função é armazenar os atributos da taxa de condomínio, mês de referência, o valor da taxa, a data de geração e a data de vencimento da taxa de condomínio.

61 3.6.11. Caso de Uso 11: Receber Taxa de Condomínio Esse caso de uso descreve os procedimentos que serão realizados para registrar o pagamento de contas, como mostra o quadro 13. Nome Receber Taxa de Condomínio CSU - 11 Sumário Este caso de uso descreve as etapas para realizar o registro do recebimento de taxas do condomínio. Ator primário: Síndico Ator(es) secundário(s): Não há Pré-condição: O valor da taxa ter sido calculado anteriormente. Pós-condição: O pagamento da taxa é registrado. Fluxo Principal 1. O síndico solicita o registro de pagamento da taxa. 2. O sistema solicita os dados para registrar o recebimento da taxa de condomínio. 3. O síndico informa os dados. 4. O sistema solicita a confirmação. 5. O síndico confirma os dados. 6. O sistema apresenta o recibo. 7. O caso de uso é encerrado. Fluxo de Alternativo [3]: O pagamento está sendo realizado fora do prazo a. O sistema calcula e apresenta os juros e a multa. Fluxo de Exceção [3]: A taxa não foi gerada. a. O sistema informa que a taxa não foi gerada e encerra o caso de uso. Regras de Negócio Associadas RN 08, RN09 e RN 10 Quadro 13 Especificação do caso de uso: Receber Taxa de Condomínio.

62 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 15). Figura 15 Diagrama de sequência do caso de uso: Receber Taxa de Condomínio. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita a registrar o recebimento de taxa de condomínio. b) Controlador de Receber Taxa de Condomínio: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Receber Taxa de Condomínio, e as classes de entidade Taxa de Condomínio, Lançamento Mês, Unidade e Pessoa. c) Interface de Receber Taxa de Condomínio: representa a classe de fronteira desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento dos dados para o registro do recebimento da taxa de condomínio referente a uma unidade e determinado mês.

63 d) Taxa de Condomínio: corresponde a uma das classes de entidade envolvida nesse caso de uso. Sua função é armazenar os atributos da taxa de condomínio, mês de referência, o valor da taxa, a data de geração e a data de vencimento da taxa de condomínio. e) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse caso de uso. Sua função é armazenar os atributos dos lançamentos financeiros, data, tipo, descrição, juros, multa e valor final. f) Unidade: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das unidades, o número da unidade, a pessoa que é moradora, assim como a pessoa que é proprietária da unidade em questão. g) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.

64 3.6.12. Caso de Uso 12: Gerar Recibo Esse caso de uso descreve os procedimentos que serão realizados para registrar o pagamento de contas, como mostra o quadro 14. Nome Gerar Recibo CSU - 12 Sumário Este caso de uso descreve as etapas para gerar o recibo de pagamento da taxa de condomínio. Ator primário: Síndico Ator(es) secundário(s): Não há Pré-condição: A taxa ter sido paga. Pós-condição: O recibo foi gerado. Fluxo Principal 1. O síndico solicita a geração de recibo. 2. O sistema solicita os dados para a geração do recibo. 3. O síndico informa os dados. 4. O sistema solicita confirmação. 5. O síndico confirma os dados. 6. O sistema gera o recibo. 7. O caso de uso é encerrado. Fluxo de Alternativo: Não há. Fluxo de Exceção: Não há registro de pagamento da taxa. a. O sistema informa que não há pagamento da taxa. b. O caso de uso é encerrado. Regras de Negócio Associadas Quadro 14 Especificação do caso de uso: Gerar Recibo.

65 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 16). Figura 16 Diagrama de sequência do caso de uso: Gerar Recibo. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita a geração de recibo. b) Controlador de Gerar Recibo: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Gerar Recibo, e as classes de entidade, Lançamento Mês, Histórico e Pessoa. c) Interface de Gerar Recibo: representa a classe de fronteira desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento dos dados para a geração do recibo da taxa de condomínio referente a uma unidade em determinado mês. d) Histórico: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das unidades, o número da unidade, a pessoa

66 que é moradora, assim como a pessoa que é proprietária da unidade em questão. e) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é armazenar os atributos das pessoas cadastradas, nome; CPF e telefone. f) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse caso de uso. Sua função é armazenar os atributos dos lançamentos financeiros, data, tipo, descrição, juros, multa e valor final.

67 3.6.13. Caso de Uso 13: Gerar Balancete Esse caso de uso descreve os procedimentos que serão realizados para registrar o pagamento de contas, como mostra o quadro 15. Nome Gerar Balancete CSU - 13 Sumário Este caso de uso descreve as etapas para gerar o balancete de determinado período. Ator primário: Síndico Ator(es) secundário(s): Não há Pré-condição: Haver registro de movimento no período solicitado. Pós-condição: O balancete foi gerado. Fluxo Principal 1. O síndico solicita a geração de balancete. 2. O sistema solicita os dados para a geração do balancete. 3. O síndico informa os dados. 4. O sistema solicita confirmação. 5. O síndico confirma os dados. 6. O sistema gera o balancete. 7. O caso de uso é encerrado. Fluxo de Alternativo: Não há. Fluxo de Exceção: Não há registro de movimentação financeira no período a. O sistema informa que não há movimentação financeira no período. b. O caso de uso é encerrado. RN 08, RN09 e RN 10 Regras de Negócio Associadas Quadro 15 Especificação do caso de uso: Gerar Balancete.

68 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 17). Figura 17 Diagrama de sequência do caso de uso: Gerar Balancete. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita a geração de balancete. b) Controlador de Gerar Balancete: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Gerar Balancete, e as classes de entidade Contas a Pagar e Lançamento Mês. c) Interface de Gerar Balancete: representa a classe de fronteira desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento dos dados para a geração de um balancete de determinado período.

69 d) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse caso de uso. Sua função é armazenar os atributos dos lançamentos financeiros, data, tipo, descrição, juros, multa e valor final. e) Contas a Pagar: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das contas que serão pagas, a data de vencimento, a descrição e o valor da conta e também, o mês de referência.

70 3.6.14. Caso de Uso 14: Gerar Histórico Esse caso de uso descreve os procedimentos que serão realizados para registrar o pagamento de contas, como mostra o quadro 16. Nome Gerar Histórico CSU - 14 Sumário Este caso de uso descreve as etapas para gerar o histórico de determinada unidade. Ator primário: Síndico Ator(es) secundário(s): Não há Pré-condição: Haver histórico cadastrado anteriormente. Pós-condição: O Histórico foi gerado. Fluxo Principal 1. O síndico solicita a geração de histórico. 2. O sistema solicita os dados para a geração do histórico. 3. O síndico informa os dados. 4. O sistema solicita confirmação. 5. O síndico confirma os dados. 6. O sistema gera o histórico. 7. O caso de uso é encerrado. Fluxo de Alternativo: Não há. Fluxo de Exceção: Não há registro de histórico para a unidade a. O sistema informa que não há histórico para a unidade. b. O caso de uso é encerrado. Regras de Negócio Associadas Quadro 16 Especificação do caso de uso: Gerar Histórico.

71 O diagrama deste caso de uso exibe o fluxo de interação, apresentando a sequência das mensagens para a sua execução (Figura 18). Figura 18 Diagrama de sequência do caso de uso: Gerar Balancete. As classes de análise envolvidas neste caso de uso e os respectivos papéis são: a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema. No caso, o síndico solicita a geração de histórico. b) Controlador de Gerar Histórico: representa a classe de controle deste caso de uso. Sua função é interpretar os comandos realizados entre o Menu Inicial, a interface de Gerar Histórico, e as classes de entidade Histórico e Pessoa. c) Interface de Gerar Histórico: representa a classe de fronteira desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento dos dados para a geração do Histórico de determinada unidade. d) Histórico: representa a terceira e última classe de entidade deste caso de uso. Sua função é armazenar os atributos das relações entre as pessoas e as unidades. Mantendo os dados mesmo após o término dessa relação. Os atributos dessa classe são: o número da unidade; a pessoa moradora; a data

72 de entrada e a data de saída do morador; a pessoa que é proprietária; a data de aquisição e a data de venda relativa a esse proprietário. e) Pessoa: representa uma das classes de entidade deste caso de uso. Sua função é armazenar os atributos das pessoas cadastradas, nome; CPF e telefone. 3.7. PROJETO Após a análise, há a definição da tecnologia e arquitetura empregadas no desenvolvimento do sistema. Nesse trabalho, foram definidos o emprego do business object, de classes action e do data access object, esses componentes serão apresentados com mais detalhes no capítulo 4 Arquitetura e Código e capítulo 6 Persistência de Dados ficando limitado ao capítulo atual a apresentação das classes de projeto e dos diagramas de sequência gerados a partir da interação entre as classes. Desta forma, após definidos os requisitos; os casos de uso; estabelecidas as classes de negócio e as suas interações através dos diagramas de seqüência, o processo de elaboração do projeto definiu a existência de outras classes. De modo que, além das classes já apresentadas, foram incluídas no projeto as seguintes classes: UsuarioEntidade; HibernateUtil; LoginBO; LoginCO; LoginDAO; Login2; PessoaBO; PessoaDAO; PessoaHibernateDAO; UnidadeBO; UnidadeDAO; UnidadeHibernateDAO; HistoricoBO; HistoricoDAO. HistoricoHibernateDAO; CadastrarPessoaAction e PesquisarAction. A documentação apresentada a seguir foi gerada por engenharia reversa se utilizando a ferramenta MDG que integra o Eclipse ao Enterprise Architect.

73 Assim,, a partir do código foram elaborados os diagramas estáticos, respeitando os pacotes com os quais a aplicação foi organizada. As classes de negócio e a classe UsuarioEntidade foram agrupadas no pacote entidade como mostra a figura 19. Figura 19 Classes do pacote entidades.

74 No pacote bo se concentraram as seguintes classes: LoginBO; PessoaBO; UnidadeBO e HistoricoBO (Figura 20). Figura 20 Classes do pacote bo. As classes de persistência, aquelas com terminação DAO e, ainda, a classe HibernateUtil, estão presentes no pacote DAO, como representado pela figura 21. Figura 21 Classes do pacote persistência.

75 E finalmente, as classes Login2; CadastrarPessoaAction e PesquisarAction estão localizadas em um mesmo pacote como apresentado na figura 22. Figura 22 Classes do pacote action.

76 3.7.1. Diagramas de Sequência de Projeto Os diagramas de sequência em nível de projeto envolvem as classes de negócio e, também, as classes criadas para o desenvolvimento, considerando a tecnologia escolhida para a implementação do aplicativo. 3.7.1.1 Caso de Uso 01: Fazer Login Esse diagrama ilustra os passos do sistema para realizar o login do usuário ao sistema, como mostra a figura 23.

77 Figura 23 Diagrama de sequência com as classes de projeto do caso de uso: Fazer Login.

78 3.7.1.2 Caso de Uso 02: Cadastrar Dados Esse diagrama apresenta a sequência e a comunicação entre as classes de projeto do sistema para cadastrar os dados dos moradores e proprietários de unidades do condomínio, como apresentado na figura 24.

79 Figura 24 Diagrama de sequência com as classes de projeto do caso de uso: Cadastrar Dados.

80 3.7.1.3 Caso de Uso 03: Listar Pessoas A sequência realizada pelo sistema para listar as pessoas cadastradas no sistema está ilustrada na figura 25.

81 Figura 25 Diagrama de sequência com as classes de projeto do caso de uso: Listar Pessoas.

82 3.7.1.4 Caso de Uso 04: Consultar Pessoa O comportamento do sistema e as classes envolvidas na realização do caso de uso Consultar Pessoa estão representados na figura 26.

83 Figura 26 Diagrama de sequência com as classes de projeto do caso de uso: Consultar Pessoa.

84 3.7.1.5 Caso de Uso 05: Consultar Unidade Esse diagrama apresenta as classes envolvidas e a relação entre elas para a realização do caso de uso Consultar Unidade (Figura 27).

85 Figura 27 Diagrama de sequência com as classes de projeto do caso de uso: Consultar Unidade.

86 3.7.1.6 Caso de Uso 06: Atualizar Histórico Esse diagrama representa o comportamento do sistema para realizar o caso de uso Atualizar Histórico (Figura 28).

87 Figura 28 Diagrama de sequência com as classes de projeto do caso de uso: Atualizar Histórico.

88 4. ARQUITETURA E CÓDIGO Orlando Alves de Oliveira Com a crescente necessidade de automação de processos para melhor desempenho na execução das tarefas se aumentou, também, a utilização de software dentro de vários setores de uma organização para apoiar as rotinas diárias, Diante desse cenário foi desenvolvida uma aplicação específica para o Condomínio do Edifício Porto Seguro com o objetivo de apoiar a administração deste condomínio, permitindo o acompanhamento de sua ocupação bem como gestão financeira da manutenção mensal do imóvel. Para essa aplicação o padrão de utilizado foi de desenvolvimento em camadas para que fique separado por módulos de apresentação, negócios e integração. A arquitetura de software é a maneira como está estruturado o sistema, ou seja, quais os componentes estão presentes e as relações entre esses componentes (AHMED & UMRYSH, 2002). Através do modelo de arquitetura o desenvolvedor visualiza com mais facilidade o funcionamento do sistema, como serão dispostos os seus componentes, facilitando, assim, o entendimento e a manutenção do mesmo. Por isso é muito importante que a arquitetura seja bem definida para que o sistema atenda todas as necessidades definidas nos requisitos de forma bem estruturada. É um grande desafio construir uma aplicação bem estruturada e de fácil manutenção. Portanto no desenvolvimento do sistema do Edifício Porto Seguro foi utilizada a linguagem de programação Java, aplicando-se a programação orientada a objetos além do uso da arquitetura em três camadas MVC (Model, View, Controller), plataforma J2EE, através do Eclipse e com os framewoks Struts e Hibernate. 4.1. JAVA É uma linguagem de programação de alto nível orientada a objetos desenvolvida por uma equipe comandada por James Gosling na Sun Microsystens na década de 90.

89 Essa linguagem foi projetada para ser pequena, simples e portável a todas as plataformas e sistemas operacionais e, ainda, integrada à Internet, Java, também, é uma excelente linguagem para desenvolvimento de aplicações em geral (APOSTILA, 2009). Por se tratar de uma linguagem orientada a objeto, é necessário o conhecimento desse paradigma para usá-la adequadamente. É compilada para bytecode que é executado pela JVM (Java Virtual Machine) responsável por administrar a memória e possui um coletor de lixo automático. O compilador e a JVM estão disponíveis no JDK (Java Development Kit) kit de desenvolvimento Java. De acordo com Wikipedia (2009a): 4.2. ARQUITETURA MVC Java ainda é um standard de fato, que é controlada através da JCP Java Community Process. Em 13 de Novembro de 2006, a Sun lançou a maior parte do Java como Software Livre sob os termos da GNU General Public License (GPL). Em 8 de Maio de 2007 a Sun finalizou o processo, tornando praticamente todo o código Java como software de código aberto, menos uma pequena porção da qual a Sun não possui copyright. O aumento do uso de aplicações distribuídas provê mudanças nos projetos de software. Sendo assim no sistema do Edifício Porto Seguro foi utilizada a arquitetura MVC que é um modelo de aplicação em três camadas, nesse modelo as responsabilidades ficam divididas. A arquitetura MVC (Model-View-Controller) separa em camadas a aplicação, mas não deixando de integrá-las. Segundo Alur, Crupi e Malks (2004, p.102): Uma camada equivale a um dos particionamentos lógicos dos diversos aspectos tratados em um sistema. A cada camada é atribuída sua responsabilidade distinta, ou única, no sistema. Visualizamos cada camada como separadas logicamente entre si. Cada camada não está estritamente acoplada com a camada adjacente. Sendo assim, as camadas trabalham juntas e a manutenção do código é facilitada. Este modelo descreve a organização de uma aplicação em três módulos: - Model (Modelo): compreende o modelo de aplicação, contendo a representação de dados e de lógica de negócios, onde ficam as classes de persistência, business object, entidades e DAO (Data Access Objetct); - View (Apresentação): trata aspectos relacionados à apresentação e formulários entrada de dados de usuário que são as páginas de visualização JSP (Java Server Pages);

90 - Controller (Controle): é responsável por despachar requisições e controlar os seus fluxos, é onde é implementado o Front Controller através do framewok Struts na classe action e no arquivo struts.xml. Com o emprego do modelo MVC foi possível centralizar a lógica de despachar requisições em uma classe action, simplificando a implementação do controle de segurança e acesso ao sistema. Para facilitar o uso do Modelo MVC, foi utilizado o framework Struts, cujo código aberto fornece componentes de controle, e Hibernate que é responsável pelo mapeamento objeto relacional com o banco de dados. A figura 29 apresenta o modelo dessa arquitetura: Figura 29 Modelo Arquitetura MVC. 4.3. PADRÕES DE PROJETO Padrões de projeto são soluções que podem ser reutilizadas para problemas recorrentes no desenvolvimento de aplicativos. Representam um conjunto de descrições de problemas que são encontrados durante o processo do desenvolvimento das aplicações com as suas respectivas soluções para esses problemas. (ALUR, CRUPI & MALKS, 2004). A utilização de padrões em softwares popularizou-se com o livro Design Patterns: Elements of Reusable Object-Oriented Software cujos autores são conhecidos como a Gangue dos Quatro (Gang of Four - GoF). Trata-se de um

91 catálogo com desenhos de padrões que podem ser agregados ao software (MARTINS, 2006). Os padrões de projeto são responsáveis por apresentar como será o funcionamento entre os componentes do sistema, definindo-se através do padrão quais são as responsabilidades e como se relacionam as entidades do projeto. A definição de como será o funcionamento entre os componentes do sistema, ao se considerar as responsabilidades e o relacionamento entre as entidades do projeto é dada pelos padrões de projeto. No software em questão foram empregados os seguintes padrões: Business Object, Data Access Object e Front Controller implementado pelo framework Struts. 4.3.1. DAO O DAO é utilizado para persistência de objetos Java fazendo com que o código de acesso aos dados fique separado da lógica de negócios. Esse padrão abstrai e encapsula o acesso ao armazenamento persistente gerenciando a conexão com o banco de dados para armazenar e consultar dados. Geralmente se tornam objetos leves porque são implementados como objetos sem informações de estado e também não armazenam em cachê os resultados de nenhuma execução de consulta. Com o uso desse padrão os detalhes de implementação do banco de dados ficam ocultos, por isso pode haver alteração de banco de dados sem que implique em grandes mudanças na estrutura do sistema. (ALUR, CRUPI & MALKS, 2004). Na construção de software com utilização de mapeamento objeto relacional e DAO, a linguagem do banco de dados torna-se transparente para o desenvolvedor, pois operações do banco são assumidas pelo framework. Assim, toda a manipulação de dados é feita através dos objetos instanciados, o que propicia maior facilidade no caso de necessidade de troca do banco de dados. Esse padrão será descrito com mais detalhes no capítulo 6. 4.3.2. Business Object São objetos Java que contêm dados de negócios, ou seja, um objeto Java se comunica com o DAO o padrão eleito para fazer a persistência com o banco

92 de dados. Esse padrão permite que a lógica de negócios fique separada da lógica de persistência, usando-se um objeto. A figura 30 mostra o código da classe PessoaBO. package br.uniminas.bo; import java.util.list; import br.uniminas.entidades.pessoa; import br.uniminas.persistencia.pessoadao; import br.uniminas.persistencia.pessoahibernatedao; public class PessoaBO { private PessoaDAO dao; public PessoaBO() { this.dao = new PessoaHibernateDAO();} public List getallpessoas() { return dao.getallpessoas();} public void deletepessoa(string string) { dao.delete(string);} public Pessoa getpessoa(string string) { return dao.getpessoa(string); } public void insertpessoa(pessoa pes) { dao.insert(pes);} } Figura 30 Classe PessoaBO. Na classe pessoabo é criado um objeto do tipo PessoaDAO e a partir desse objeto são chamados métodos que fazem operações como inserir, pesquisar e deletar que são métodos da classe DAO responsável pela persistência no banco de dados. Portanto o business object mantém os dados de negócio e implementa comportamentos comuns a toda aplicação, descritos nos métodos da classe PessoaBO. 4.3.3. Front Controller É um padrão onde a lógica de controle fica centralizada em um ponto único de entrada, o que permite o gerenciamento das atividades de tratamento das solicitações. Com a utilização do Front Controller é possível a reutilização do código, ou seja, não há necessidade de repetição da lógica de controle a mesma lógica pode ser usada para várias solicitações.

93 Portanto, em um sistema, o padrão Front Controller é o primeiro contato, responsável por tratar as solicitações. A partir daí serão delegadas funções para que seja executado o gerenciamento de ação e visualização. 4.3.4. Application Controller O Application Controller é um padrão utilizado para centralizar a recuperação e chamada dos componentes de solicitação que podem ser comandos ou páginas de visualização. Esse padrão é responsável pelo gerenciamento da ação e visualização, onde o gerenciamento da ação está relacionado às rotas que para atendimento de uma solicitação e o gerenciamento de visualização, cuja função é localizar e distribuir a visualização solicitada. Tanto o padrão Front Controller como o Application Controller são implementados pelo framework Struts. 4.4. TECNOLOGIAS UTILIZADAS 4.4.1. Servlet Servlet é uma classe Java que acessa uma API com serviços específicos do protocolo http. Ele recebe uma requisição e apresenta uma resposta em seguida. Toda vez que recebe uma requisição é iniciado um método chamado service(). De acordo com Dumoulin, Franciscus e Winterfeldt (2004, p.9): Um servlet se parece e se comporta como um servidor web miniatura. Ele recebe uma solicitação e apresenta uma resposta. Mas, diferente dos servidores web convencionais, a interface de programação da aplicação (API) do servlet é designada especificamente para ajudar os desenvolvedores Java a criarem aplicações dinâmicas. No ciclo de vida do servlet na primeira invocação o método init() é executado quando o servlet é carregado, existem os métodos de serviço que são chamados pelo web server como service(), doget(), dopost(), dentre outros. O método destroy é chamado antes de encerrar a requisição ao servlet. A figura 31 a seguir mostra o ciclo de vida de um servlet.

94 Figura 31 Ciclo de vida do servlet. Adaptado de Angoti (2009a). 4.4.2. Páginas JSP Java Server Pages (JSP) é uma tecnologia para desenvolvimento de aplicações que permite a captura de informações através de formulários. Pode ser facilmente codificado, facilitando o desenvolvimento e também manutenção de uma aplicação. Quando uma página JSP é requisitada pelo usuário no browser, esta página é executada pelo servidor, e, então, é gerada uma página HTML, através de do processo de renderização, e em seguida, essa página é enviada ao browser do usuário. As páginas JSP contêm código HTML comum e se diferenciam pelo uso das tags que representam instruções Java. consultarpessoaform.jsp. Na figura 32 é apresentado o código da página <%@ 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" </head> type="text/css" /> <body background="/condominio/imagens/fundook.jpg"> <center><s:if test="pessoa==null pessoa.p_cpf == null">

95 <br> <br> <br> <br> <div id="menu"> </s:if> </div> <br> <br> <br> <br> <br> <ul> </ul> <li><a href="principal.action">principal</a></li> <li><a href="getallpessoas.action">listar Cadastros</a></li> <h1><s:text name="pesquisar Pessoa" /></h1> <s:form action="consultarpessoa"> /></td> <table align="center" class="borderall"> </table> <br /> <table> </table> <tr> </tr> <tr> <tr> </s:form></center> </body> </html> <td class="tdlabel"><s:text name="label.p_cpf" /></td> <td><s:textfield name="cpf" size="11" /></td> <td><s:submit action="consultarpessoa" key="button.label.submit2" cssclass="butstnd" /></td> <td><s:reset key="button.label.cancel" cssclass="butstnd" Figura 32 Código da página consultarpessoaform.jsp. Assim, a execução da função consultar pessoa que foi apresentado anteriormente, terá como resultado a exibição na tela do browser da página pesquisarpessoa.jsp (Figura 33).

96 Figura 33 Página pesquisarpessoa.jsp 4.4.3. JDBC Java Database Conectivity (JDBC) é uma API da linguagem Java que permite o acesso ao sistema de gerenciamento de banco de dados (SGBD) através de comandos SQL (Structured Query Language). Essa API está contida no pacote java.sql, com a sua utilização não há necessidade do uso de um banco específico, ou seja, o sistema desenvolvido fica independente acessando qualquer banco de dados (TOOD & SZOLKOWSK, 2003). No sistema do Edifício Porto Seguro foi utilizado o JDBC juntamente com a utilização do framewok Hibernate para fazer o mapeamento objeto relacional com o banco de dados através do DAO (Data Access Object). 4.5. J2EE J2EE (Java Enterprise Edition) é um padrão de desenvolvimento que contém especificações sobre implementações de softwares desenvolvidos utilizando a linguagem de programação Java. É voltado para o desenvolvimento de aplicativos multicamadas baseando-se em componentes que são executados em um servidor de aplicação (DIAS e BORBA, 2002). No J2EE estão contidas API utilizadas na implementação do sistema do Edifício Porto Seguro que são servlets, JSP (Java Server Pages) e JDBC (Java Database Connectivity).

97 As aplicações que utilizam o padrão J2EE seguem o modelo arquitetural em camadas, onde em cada camada está atribuída uma responsabilidade diferente. Como se pode notar na figura 34 que mostra a divisão em camadas. Figura 34 Modelo em camadas. Adaptado de Alur, Crupi e Malks (2004) Na camada de apresentação encontra-se a lógica de apresentação dos elementos exibidos ao usuário. Essa camada intercepta as solicitações do usuário e faz o controle do que será exibido como resposta às requisições. Estão nessa camada as páginas JSP e os servlets, que embora não sejam a interface propriamente dita são responsáveis pela criação destas. Também, está presente nessa camada o Front Controller, implementado pelo framework Struts, que é responsável por controlar e redirecionar as requisições feitas pelo usuário e delegar as ações para cada requisição. Já, na camada de negócios estão presentes os dados e a lógica de negócios. Ela foi implementada com a utilização de Business Object que tem por função separar os dados e a lógica de negócios através de um objeto Java. Por fim, a camada de integração é responsável por fazer a comunicação com o SGBD (Sistema de gerenciamento de banco de dados). Nessa camada foi utilizado o DAO para abstrair o acesso ao banco de dados através do mapeamento objeto relacional. 4.6. TOMCAT O Tomcat 5.5 é um container servlet da Apache Software Foundation que foi utilizado como servidor web no projeto do software do Edifício Porto Seguro. Ele implementa as especificações servlet e JSP. Com o uso do Tomcat foi possível obter algumas vantagens dentre elas se destacam:

98 - Otimização de performance; - Otimização e redução do coletor de lixo; - Melhoria no tratamento de taglibs; - Gerenciamento da aplicação e do servidor. (ANGOTI JR, 2009c). 4.7. IMPLEMENTAÇÃO 4.7.1. Struts É um framework mantido pela Apache Software Foundation além de outros projetos já criados tais como o Tomcat. O código inicial do Struts foi desenvolvido entre o ano de 2000 e 2001 onde mais de 30 desenvolvedores contribuíram para a sua criação (DUMOULIN, FRANCISCUS, WINTERFELDT, 2004). O Struts é responsável por implementar o Front Controller que faz a centralização da lógica de controle, promovendo também reutilização de código porque não será necessário código de controle em várias páginas de visualização. As responsabilidades ficam bem definidas facilitando a manutenção. Na figura 35 é possível ver o funcionamento do Front Controler que atua na camada de apresentação. Figura 35 Front Controller Adaptado de Angoti (2009b)

99 O controlador é o ponto central de todas as requisições feitas pelo cliente e a partir dele que vai ser definida qual página view que vai ser exibida. O Command Helper mostrado na figura acima representa comandos ou métodos que serão executados de acordo com o nome da ação definida. No Sistema para Gestão de Condomínio o Command Helper é representado pelas classes action que possuem métodos que são executados de acordo com a requisição do cliente. Para o correto funcionamento do framework Struts é criado um arquivo chamado struts.xml onde são feitos os mapeamento das ações. A figura 36 apresenta um trecho do código desse arquivo. <!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd"> <struts> </struts> <package name="default" extends="struts-default"> <!-- mapeamento das ações -->... <action name="consultarunidade" method="consultaunidade" </action>... </package> Figura 36 Arquivo struts.xml. class="br.uniminas.action.pesquisaraction"> <result name="success">/page/unidade.jsp</result> <result name="erro">/page/erro.jsp</result> Pode-se notar que o mapeamento é feito através do nome da ação, da classe utilizada e do método. O resultado também é mapeado, no caso da ação consultarunidade mostrada na figura 8 caso o resultado seja success será exibida a página unidade.jsp. Porém, se o resultados for erro a página a ser mostrada será erro.jsp. O resultado dessa ação está definido no código do método consultaunidade da classe PesquisarAction (Figura 37).

100... public String consultaunidade() {... } unidade = uniservice.getunidade(numero); if (unidade!= null) { } else { } return "success"; Figura 37 Método consultaunidade. addactionerror("unidade não existe!"); return "erro"; Assim, o Front Controller implementado através do Struts faz o controle das ações e resultados que serão exibidos através do direcionamento das ações de acordo com a solicitação feita pelo usuário. 4.7.2. Diagrama de Pacotes Os diagramas de pacotes do sistema foram gerados pelo Omondo Eclipse UML que é um plugin que auxilia a geração de diagramas UML. Foi utilizado o processo de engenharia reversa para geração desses diagramas, onde a partir do código fonte foi possível gera-los. O diagrama de pacotes exibe a estrutura de classes e pacotes de como do sistema desenvolvido. A figura 38 mostra todos os pacotes que foram criados no sistema. Figura 38 Diagrama de pacotes.

101 No pacote entidades estão as classes utilizadas para criar os objetos que serão manipulados pela aplicação, as classes desse pacote são: UsuárioEntidade, LoginCO, Pessoa, Unidade e Histórico(Figura 39). Figura 39 Classes do pacote entidades. No pacote bo estão as classes de negócio da aplicação, ou seja, através de métodos que estão contidos nas classes do tipo BO são passados os objetos de entidades para que sejam executadas as operações pelas classes DAO (Figura 40). Figura 40 Classes do pacote bo. Já, no pacote persistência estão as interfaces PessoaDAO, UnidadeDAO, HistoricoDAO, essas interfaces contêm os mesmo métodos que são implementados nas classes PessoaHibernateDAO, UnidadeHibernateDAO e Histórico HibernateDAO e também a classe LoginDAO que implementam as

102 operações que serão executadas no banco de dados através do framework hibernate, já a classe HibernateUtil é criada pelo framework hibernate (Figura 41) Figura 41 Classes do pacote persistência. E finalmente, no pacote action estão as classes Java que contêm métodos que são mapeados no struts.xml para realizar determinadas ações. As classes são: Cadastrar PessoaAction, PesquisarAction e Login2 (Figura 42). Figura 42 Classes do pacote action.

103 Percebe-se que os pacotes retratam a maneira de como estão dispostas as classes da aplicação, o que deixa o código mais organizado e auxilia no caso de novas implementações ou alterações no sistema. 4.7.3. Implementação do Caso de Uso Cadastrar Dados Para apresentar o funcionamento do modelo em camadas e visualizar a interação entre os padrões utilizados no sistema do Edifício Porto Seguro, será usado como exemplo o Caso de Uso 02 Cadastrar Dados que utiliza as entidades pessoa, unidade e histórico. Essa demonstração parte das premissas de que a pessoa em questão não foi cadastrada anteriormente e que não há histórico com pendências para a unidade. A figura 43 mostra a tela principal do sistema do Edifício Porto Seguro onde é selecionada a opção Cadastrar Dados. Figura 43 Página Principal.

104 Ao ser selecionada a opção cadastrar dados, executa-se uma action que foi mapeada no arquivo struts.xml com o nome de setupforinsertorupdate, o trecho de código do mapeamento dessa action é mostrado a seguir na figura 44. <action name="setupforinsertorupdate" method="setupforinsertorupdate" class="br.uniminas.action.cadastrarpessoaaction"> <result name="success">/page/cadastropessoaform.jsp</result> </action> Figura 44 Action setupforinsertorupdate mapeada no arquivo struts.xml. A ação nomeada como setupforinsertorupdate no arquivo struts.xml invoca o método setupforinsertorupdate() que está na classe CadastrarPessoaAction do pacote action, como apresentado no trecho de código abaixo (Figura 45). public class CadastrarPessoaAction {... public String setupforinsertorupdate() { prep(); return "success"; }... Figura 45 Método setupforinsertorupdate() implementado na classe CadastrarPessoaAction. Nessa classe existe um método prep() que preenche um componente do tipo combo box na página onde serão exibidos os números das unidades existentes no condomínio e retorna success que foi mapeado no arquivo struts.xml para exibir a página de cadastro de dados, como mostrado na figura 46. Figura 46 Tela de Cadastro de Dados.

105 Depois de preenchidos os dados e pressionada a tecla cadastrar é executada uma action mapeada no arquivo struts.xml com o nome de insertorupdate, a seguir é mostrado o trecho do arquivo struts.xml (Figura 47). <action name="insertorupdate" method="insertorupdate" class="br.uniminas.action.cadastrarpessoaaction"> <result name="success">/page/sucesso.jsp</result> <result name="erro">/page/erro.jsp</result> </action> Figura 47 Action InsertOrUpdate implementado no arquivo struts.xml. O método insertorupdate() está na classe CadastrarPessoaAction que é uma classe Java contendo os objetos e métodos relacionados ao cadastro de dados, além dos métodos das validações feitas pelo sistema. A seguir é mostrado o código do método insertorupdate(), como mostra a figura 48. public class CadastrarPessoaAction {... public String insertorupdate() { if (!validationsuccessful()) { return "erro"; } else { if (prop!= null && prop.equals("aquisicao")) { gravapropaquisicao(); } if (prop!= null && prop.equals("venda")) { if (!validadatavenprop()){ return "erro";} else{ gravaprovenda();} } if (mor!= null && mor.equals("entrada")) { if (jamorador()==true){ return "erro"; } if(jamorador()==false){ gravamorent(); } } if (mor!= null && mor.equals("saida")) { if (!validadatasaimor()) return "erro"; else gravamorsai(); } return "success"; } }... Figura 48 Método InsertOrUpdate implementado na classe CadastrarPessoaAction.

106 Primeiramente é feita a verificação dos dados inseridos no formulário através do método validationsuccessfull() que está na classe CadastrarPessoaAction, que valida os campos preenchidos no formulário. Se não houver a validação, uma página de erro é retornada. Caso a validação seja positiva, será verificada, então, as opções selecionadas através de componente do tipo radio button, que se encontra na página de cadastro de dados. As opções disponíveis são proprietário definindo em seguida se aquisição ou venda e, ainda, morador acompanhado de entrada ou saída de um apartamento. Será apresentado o processo de cadastro de uma aquisição de um apartamento, a condição que considera a opção aquisição selecionada. Nesse caso é chamado o método gravapropaquisicao(). Nesse método, estão envolvidas as entidades pessoa; unidade e histórico e as variáveis pesaux e pessoa, que são do tipo Pessoa e pesservice é do tipo PessoaBO. A linha de código mostrada abaixo permite verificar se já existe uma pessoa cadastrada com o CPF informado. Caso exista, grava o objeto pessoa correspondente no objeto pesaux, senão grava valor nulo nesse objeto (Figura 49). public class CadastrarPessoaAction {... public void gravapropaquisicao() { pesaux = pesservice.getpessoa(pessoa.getp_cpf()); unidade = uniservice.getunidade(unidade.getu_numero()); histaux = histservice.gethistorico(historico.getid());... Figura 49 Método gravapropaquisicao() implementado na classe CadastrarPessoaAction. Esse mesmo procedimento é feito também com os objetos unidade e histaux que correspondem à objetos do tipo unidade e histórico respectivamente. Em seguida, é verificado se a unidade já tem proprietário cadastrado, isso é feito através do método getproprietário() que está na classe Unidade. Se houver proprietário cadastrado, é retornada uma mensagem como pode ser visto no trecho de código apresentado na figura 50.

107 public class CadastrarPessoaAction{......... public void gravapropaquisicao{ if ((pesaux!= null pesaux == null) && unidade.getproprietario()!= null) { addactionmessage("a unidade "+unidade.getu_numero()+"já tem proprietário\n CADASTRO NÃO EFETUADO!"); Figura 50 Mensagem de erro gerada pelo método gravapropaquisicao() implementado na classe CadastrarPessoaAction. Se a pessoa não tiver sido cadastrada anteriormente e a unidade não possuir proprietário, o registro de pessoa é gravado da seguinte forma, um objeto do tipo PessoaBO chamado pesservice já instanciado, passa através do método insertpessoa(), que pertence a classe PessoaBO, o objeto pessoa criado, quando submeteu-se os dados do formulário (Figura 51). public class CadastrarPessoaAction{......... public void gravapropaquisicao{ if (pesaux == null && unidade.getproprietario() == null) { // grava pessoa pesservice.insertpessoa(pessoa); Figura 51 Comando de persistência declarado no método gravapropaquisicao() implementado na classe CadastrarPessoaAction. Na classe PessoaBO é criada uma variável do tipo PessoaDAO e no construtor dessa classe o objeto do tipo pessoadao é instanciado como mostrado a seguir (Figura 52). public class PessoaBO {... private PessoaDAO dao; public PessoaBO() { } this.dao = new PessoaHibernateDAO(); Figura 52 Comando geração do objeto pessoadao declarado no construtor da classe PessoaBO.

108 Na classe PessoaBO o método insertpessoa() recebe um objeto do tipo pessoa e passa esse objeto para a classe PessoaHibernateDAO, que contém o método insert(), como mostra a figura 53. public class PessoaBO {...... public void insertpessoa(pessoa pes) { } dao.insert(pes); Figura 53 Chamada do método insert() através do método insertpessoa() implementado na classe PessoaBO. Esse método recebe o objeto pessoa criado e executa a gravação dos dados na tabela de pessoas do banco de dados (Figura 54). public class PessoaHibernatedDAO {...... public void insert(pessoa pes) { } session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; try { tx = session.begintransaction(); session.save(pes); tx.commit(); } catch (RuntimeException e) { } finally { if (tx!= null) tx.rollback(); throw e; // session.close(); } Figura 54 Código do método insert() implementado pela classe PessoaHibernateDAO. Depois de gravar a pessoa no método gravapropaquisicao() a unidade é atualizada, primeiro é atualizado o campo proprietário da unidade através do método setproprietário(), que pertence a classe Unidade, e então um objeto do tipo UnidadeBO chamado uniservice passa através do método updateunidade(), que

109 pertence a classe UnidadeBO, o objeto unidade que foi atualizado. O trecho de código que faz esta operação é mostrado a seguir (Figura 55). public class CadastrarPessoaAction{......... public void gravapropaquisicao{ // atualiza unidade unidade.setproprietario(pessoa); uniservice.updateunidade(unidade); Figura 55 Comandos do método gravapropaquisicao() implementado pela classe CadastrarPessoaAction. Na classe UnidadeBO é criado um objeto do tipo UnidadeDAO e no construtor dessa classe o objeto do tipo unidadedao é instanciado como mostrado na figura 56 a seguir. public class UnidadeBO {... private UnidadeDAO dao; public UnidadeBO() { } this.dao = new UnidadeHibernateDAO(); Figura 56 Comandos de criação do objeto UnidadeHibernateDAO declarado no construtor da classe UnidadeBO. O método updateunidade() da classe UnidadeBO, recebe um objeto do tipo unidade e passa esse objeto para a classe UnidadeHibernateDAO que contém um método chamado updateunidade() apresentado na figura 57. public class UnidadeBO{...... public void updateunidade(unidade u){ } dao.updateunidade(u); Figura 57 Comandos do método updateunidade() implementado pela classe UnidadeBO.

110 O método updateunidade() da classe, recebe o objeto do tipo unidade e executa a atualização dos dados na tabela de unidades do banco de dados (Figura 58). public class UnidadeHibernatedDAO {...... } public void updateunidade(unidade u) { session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; try { tx = session.begintransaction(); session.update(u); tx.commit(); } catch (RuntimeException e) { } } finally { if (tx!= null) tx.rollback(); throw e; Figura 58 Código do método updateunidade() implementado pela classe UnidadeHibernateDAO. Por fim, é feita a gravação do histórico, através método gravapropaquisicao(). É verificado se há um histórico com o mesmo código que foi informado no formulário de cadastro. Se já existir, o objeto histórico será atualizado pelos métodos setters da classe histórico e é repassado ao BO através de uma objeto do tipo HistoricoBO chamada histservice através do método updatehistorico()., como ilustrado pela figura 59. public class CadastrarPessoaAction{... public void gravapropaquisicao{... // se já existir um histórico com o código digitado, atualiza if (histaux!= null) { historico.seth_provenda(histaux.geth_provenda()); historico.seth_proaquiscao(data); historico.seth_morentrada(histaux.geth_morentrada()); historico.seth_morsaida(histaux.geth_morsaida()); historico.setnumero(unidade); historico.setmorador(histaux.getmorador());

111... } historico.setproprietario(unidade.getproprietario()); histservice.updatehistorico(historico); Figura 59 Comando de persistência declarado no método gravapropaquisicao() implementado na classe CadastrarPessoaAction, quando já há histórico da unidade. Na classe HistoricoBO é criada uma variável do tipo HistoricoDAO e no construtor dessa classe um objeto do tipo historicodao é instanciado como mostrada na figura 60 a seguir. public class HistoricoBO { private HistoricoDAO dao;... public HistoricoBO() { } this.dao = new HistoricoHibernateDAO(); Figura 60 Comandos de criação do objeto HistoricoHibernateDAO declarado no construtor da classe HistoricoBO. O método updatehistorico() recebe um objeto do tipo historico e passa esse objeto para o DAO que contém um método chamado updatehistorico (Figura 61). public class HistoricoBO{...... public void updatehistorico(historico hist){ } dao.updatehistorico(hist); Figura 61 Comandos do método updatehistorico() implementado pela classe HistoricoBO. O método updatehistorico() da classe HistoricoHibernateDAO recebe o objeto do tipo histórico e executa a atualização dos dados na tabela de históricos do banco de dados (Figura 62).

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) { } finally { } if (tx!= null) tx.rollback(); throw e; Figura 62 Código do método updatehistorico() implementado pela classe HistoricoHibernateDAO. Senão houver histórico criado anteriormente com o código informado na tela de cadastro de dados um novo objeto do tipo histórico é criado e é repassado ao BO através de uma variável do tipo HistoricoBO chamada histservice pelo método inserthistorico(), como mostra a figura 63. public class CadastrarPessoaAction{......... public void gravapropaquisicao{ // se não existir um histórico com o código digitado cria um novo // registro de histórico no banco else { } historico.setproprietario(pessoa); historico.setnumero(unidade); historico.seth_proaquiscao(data); histservice.inserthistorico(historico); Figura 63 Comando de persistência declarado no método gravapropaquisicao() implementado na classe CadastrarPessoaAction, quando não há histórico da unidade.

113 O método inserthistorico(), que está na classe Histórico BO, recebe um objeto do tipo historico e passa esse objeto para o DAO que contém um método chamado inserthistorico(), como apresentado na figura 64. public class HistoricoBO{...... public void inserthistorico(historico hist) { } dao.insert(hist); Figura 64 Comando declarado no método inserthistorico() implementado na classe HistoricoBO. O método inserthistorico() da classe HistoricoHibernateDAO recebe o objeto do tipo Histórico e executa a inserção dos dados na tabela de históricos do banco com o mapeamento objeto relacional realizado através do framework Hibernate (Figura 65). public class HistoricoHibernatedDAO {...... public void insert(historico his) { } session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; try { tx = session.begintransaction(); session.save(his); tx.commit(); } catch (RuntimeException e) { } finally { if (tx!= null) tx.rollback(); throw e; } // session.close(); Figura 65 Código do método insert() implementado na classe HistoricoHibernateDAO. A seguir está apresentado o código para a geração de uma mensagem que será exibida ao usuário com confirmação de dados gravados. Essa mensagem é criada através do método addactionmessage(), como apresentado na figura 66.

114 public class CadastrarPessoaAction{......... public void gravapropaquisicao{ addactionmessage(pessoa.getp_nome() + " Proprietário da unidade " + unidade.getu_numero()); Figura 66 Mensagem de sucesso gerada pelo método gravapropaquisicao() implementado na classe CadastrarPessoaAction. Ao término da execução do método gravapropaquisicao(), o método insertorupdate() retorna uma String que no caso é success, como se pode ver na figura 67 a seguir. public class CadastrarPessoaAction{... public String insertorupdate() {... if (prop!= null && prop.equals("aquisicao")) { gravapropaquisicao(); }... return "success"; } }... Figura 67 Código do método isertorupdate() implementado na classe CadastrarPessoaAction. O retorno da String success está mapeado no arquivo struts.xml para exibir uma página JSP, como mostra a figura 68....... <action name="insertorupdate" method="insertorupdate"...... </action> <result name="success">/page/sucesso.jsp</result> Figura 68 Action insertorupdate mapeada no arquivo struts.xml.

115 O caso de uso termina com a apresentação da página sucesso.jsp (Figura 69), que contém a mensagem adicionada pelo método gravapropaquisição() através do método addactionmessage(). Figura 69 Tela de confirmação de cadastro. É importante ressaltar que se a pessoa em questão já estiver cadastrada no sistema, a parte do cadastro de dados da pessoa não será realizada pelo software. Serão executados, apenas, os comandos de atualização da unidade e inserção ou atualização do histórico daquela unidade.

116 5. INTERFACE Embora seja parte do software, a interface, para o usuário, confunde-se com o sistema, muito embora seja apenas a parte do sistema que traduz as ações do usuário em ativações das funcionalidades do sistema. É um componente fundamental para o usuário que por vezes opta por um sistema considerando mais a atratividade de sua interface do que as funcionalidades e desempenho propriamente ditos. Assim, a qualidade da interface tem grande influência no sucesso comercial de um software. A interface deve ser invisível e intuitiva, pois o usuário deve concentrarse no trabalho que deverá executar. Para isso, uma interface deve ser amigável e apresentar usabilidade. Para atingir esses objetivos, ela deverá apresentar as seguintes características: ser de fácil uso; ser fácil de aprender o seu manuseio; apresentar taxa mínima de erro; favorecer a recordação rápida; ser atrativa; apresentar alta velocidade na execução de tarefas; gerar satisfação e retenção do usuário com o tempo (ASCENIO, 1999). De acordo com Ferreira (2009), a interface estabelece uma interação do homem com o sistema através de um meio visual. O indivíduo recebe e interpreta a informação visual com base no tamanho, forma, cor e outras características. Uma especificação adequada da comunicação visual é o elemento chave para obtenção de uma interface amigável. A cor é um componente que merece um estudo especial quando se trata de comunicação, assim, a escolha das cores de uma interface deve ser feita com cautela. É natural a associação de cores a diversas situações ou elementos, tanto que se faz uso de cores para indicar condições diversas: perigo, atenção, qualidade de alimentos, acidez e alcalinidade e outras. O significado das cores tem forte cunho cultural, como no ocidente, a cor branca está associada à pureza, muito usada por noivas no dia de seu casamento. Enquanto que, no oriente, é a cor da morte e dor. Para os orientais, o vermelho é a cor convencional para o vestido de noiva. A idade, também, é fator decisivo para a escolha das cores, as crianças mais novas são normalmente atraídas por cores vibrantes. Desta forma, o design de interfaces deve se beneficiar dessas informações, selecionando as cores atrativas ao perfil do usuário do sistema.

117 As cores têm indicações relacionadas ao significado cultural e também às percepções visuais que determinam. Assim a escolha de cores para compor uma interface gráfica deve considerar alguns fatores, como os descritos a seguir. Branco É a cor que possui a maior leveza ao atrair a atenção para um fundo escuro, de modo que fornece a máxima legibilidade para um texto escuro, embora o brilho possa causar problemas ao se olhar para ela por um período prolongado. Não é recomendada para os cantos de interface e como estreita moldura de imagens, valoriza a figura. Preto Atua como estimulante para as demais cores e se harmoniza bem com todas elas. As superfícies pretas se tornam mais negras à medida que o nível de iluminação aumenta. Contrastes simultâneos fazem com que um contorno preto torne áreas coloridas mais claras e amplas. Torna-se mais legível quando em contraste com fundos claros, apesar de ser necessário o uso de fontes em negrito quando se usa texto negro em um fundo branco. Linhas pretas são eficientes ao se separar áreas coloridas através de um aumento da fronteira de contraste. Para uma boa reprodução de imagens, é desejável ter-se um preto sólido de modo a estabelecer o limite da variação tonal. Cinza Reduz as conotações emocionais. Combina com todas as cores, que apresentam seu colorido máximo quando contrastando com cinza escuro. Das cores acromáticas (branco, preto e cinza) o cinza é uma boa cor de fundo para a maioria das interfaces, pois minimiza o contraste entre a cor mais escura e a mais clara da cena, amortecendo o choque visual ao se passar de uma para outra. Embora seja adequada, não é frequentemente empregada em softwares de sucesso. As cores podem ser classificadas em cores quentes (amarelo, laranja e vermelho) e cores frias (azul, turquesa e violeta). O verde e o magenta são considerados cores marginais, pois seu caráter está na dependência das cores adjacentes, se esta for uma cor fria, então aqueles aparentaram quentes. Da mesma forma, se as cores do em torno forem quentes o verde e o magenta assumirão o caráter de cores frias.

118 Para a criação de um ambiente harmonioso é necessário haver o equilíbrio contrastando cores quentes com cores frias, de modo a torná-lo mais agradável. Vermelho Apresenta o maior significado emocional a despeito da cultura, provavelmente devido à sua associação com o sangue e o fogo, portanto com a guerra. É muito eficiente quando usada nas interfaces para sinalizar algum perigo ou chamar a atenção, como por exemplo, bordas vermelhas de sinais de advertência são rapidamente percebidas. Amarelo Apresenta grande qualidade acolhedora. Sua associação imediata com o sol faz com que ela simbolize a vida e o calor. É um bom indicador de atividade, sendo adequada para indicar a janela. Como cor de texto requer fundo preto ou azul escuro. Verde A idéia de que a plantação significa uma certa estabilidade levou à associação do verde com o sentimento de segurança. Ambientes com um tom de verde claro promovam um estado de paz na mente, enquanto que o verde em excesso resulta em uma aparência doentia. Está indicada quando se deseja passar rapidamente uma informação, sendo também, recomendada para informar que está tudo normal. Azul Sugere espaço e profundidade. É uma cor fria e suave, sendo a mais tranquila de todas. Fornece um bom fundo para cores vívidas. Simboliza autoridade e espiritualidade, sendo a cor mais amplamente usada nas bandeiras nacionais, mostrando assim, o desejo de unidade e estabilidade. É uma das três primárias dos terminais de vídeo. É difícil de ser focalizada e de se obter um bom contraste. Assim, não deve nunca ser usado para texto nem detalhes finos. Entretanto, é uma excelente cor para o fundo, dada sensação gerada por ela, de expansão e profundidade. Em relação aos significados subjetivos das cores, o quadro 17 ilustra muito bem a associação das cores com elementos positivos e negativos.

119 Cor Positivas Negativas Neve Paz Frio Palidez fúnebre Branco Pureza Leveza Hospital Rendição Inocência Limpeza Vulnerabilidade Esterilidade Noite Estabilidade Medo Segredos Preto Carvão Formalidade Vazio Anonimato Poder Solidez Morte maldição Vermelho Amarelo Vitória Força Sangue Perigo Paixão Energia Guerra Raiva Amor Sexualidade Fogo Satã Sol Ouro Covardia Risco Verão Colheita Traição Doença Serenidade Inovação Ciúmes Loucura Vegetação Fertilidade Decadência Ganância Verde Natureza Esperança Inexperiência Fuga à realidade Primavera Segurança Inveja Má Sorte Céu Estabilidade Frio Obscenidade Azul Mar Paz Depressão Mistério Espiritualidade Unidade Melancolia Conservadorismo Quadro 17 Simbologia de cores. 5.1. DIAGRAMA DE NAVEGABILIDADE O diagrama de estados de navegação indica quais são as janelas que compõe o sistema e quais eventos permitem ao usuário navegar de uma para outra. Permite observar a dinâmica da aplicação, uma vez que ilustra os caminhos possíveis na interação do usuário com o sistema A seguir, a figura 70 apresenta o diagrama de navegabilidade do sistema.

120 Figura 70 Diagrama de Navegabilidade.

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

122 Figura 71 Tela de Login. Figura 72 Tela de mensagem de erro no Login.

123 Figura 73 Menu inicial. Figura 74 Tela de Cadastro de Dados.

124 Figura 75 Tela com mensagem de erro de CPF. Figura 76 Tela com mensagem de erro, CPF cadastrado como morador em outra unidade.

125 Figura 77 Tela com mensagem de sucesso ao cadastrar os dados. Figura 78 Tela que apresenta a lista das pessoas cadastradas.

126 Figura 79 Tela para solicitar a pesquisa dos dados de uma pessoa. Figura 80 Tela que apresenta os dados da pessoa pesquisada.

127 Figura 81 Tela para solicitar a pesquisa dos dados de uma unidade. Figura 82 Tela que apresenta os dados da unidade pesquisada.

128 6. PERSISTÊNCIA DE DADOS Marco Aurélio Silva Rodrigues A maioria dos aplicativos requer dados persistentes. A persistência é um dos conceitos fundamentais em desenvolvimento de aplicativos. Se um sistema de informação não preservasse os dados inseridos pelos usuários quando a máquina anfitriã fosse desligada, o sistema seria de pequeno uso prático. Quando falamos sobre persistência em Java, normalmente estamos falando sobre armazenar dados em um bando de dados relacional, usando SQL (Structure Query Language) (BAUER & KING, 2005). A persistência de dados, na computação, refere-se ao armazenamento não-volátil de dados, por exemplo em um dispositivo físico de armazenamento como um disco rígido. De forma muito simples, Persistência de Dados nada mais é do que armazenar dados em um banco de dados relacional. Pode-se dizer que de maneira geral, o termo persistência é associado a uma ação que consiste em manter em meio físico recuperável, como banco de dados, arquivo, de modo a garantir a permanência das informações de um determinado estado de um objeto lógico. Na Orientação a Objetos, chama-se de "objetos persistentes" aqueles que permanecem existindo mesmo após o término da execução do programa. Dentras as alternativas existentes, foi-se trabalhado a persistência sob o controle de um banco de dados, pois as aplicações requerem um serviço de banco de dados, pois assim os dados desses objetos podem ser eternizados e recuperados. Assim persistência de dados consiste no armazenamento confiável e coerente das informações em um sistema de armazenamento de dados, a persistência de objetos é o armazenamento consistente de objetos de uma aplicação orientada a objeto para que estes objetos existam em diferentes execuções de diferentes aplicações.

129 6.1. CONCEITOS DE BANCO DE DADOS Os bancos de dados e os sistemas de bancos de dados são componentes essenciais para a sociedade moderna, na medida em que os sistemas de informação estão cada vez mais difundidos. Essa tecnologia tem provocado impacto no crescimento do uso de computadores, representando, um papel crítico nas áreas em que os computadores são utilizados, incluindo negócios, comércio eletrônico, engenharia, medicina, direito, educação e as ciências da informação, para criar apenas algumas delas. A palavra banco de dados é tão comumente utilizada que, primeiro, devemos defini-la (ELMASRI & NAVATHE, 2005). De acordo com Elmasri e Navathe (2005, p. 4) um banco de dados é uma coleção de dados relacionais. Os dados sãos fatos que podem ser gravados e que possuem um significado implícito. Um sistema de banco de dados é um sistema computadorizado de manutenção de registros, dados. Desse maneira o banco de dados, por si só, pode ser considerado como o equivalente eletrônico de um armário de arquivamento onde os usuários do sistema podem realizar diversas operações (DATE, 2004): Busca de dados; Inserção de dados; Exclusão de dados; Alteração de dados; Remoção de dados; Segundo Date (2005, p. 10) um banco de dados é uma coleção de dados persistentes, usado pelos sistemas de aplicações de uma determinada empresa. Os dados armazenados em um banco de dados representam algum aspecto específico do mundo real um universo de discurso de onde os dados são obtidos e apresentam algum grau de coerência lógica entre seus componentes. Portanto, uma coleção aleatória de dados não constitui um banco de dados. Um sistema de banco de dados é constituído por um banco de dados e por um sistema gerencia-dor de banco de dados, como mostrado na figura 83. Um sistema de banco de dados é usualmente uma aplicação que serve de suporte a

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

131 Figura 83 Sistema simplificado de Banco de Dados. Adaptado de RICARTE. I. L. M (1998, p.2). O banco do Sistema Gestão de Condomínio foi usado para oferecer um armazenamento persistente aos objetos programas e estruturas de dados. Essa é umas das principais justificativas para o sistema de banco de dados orientados a objeto. As linguagens de programação têm uma estrutura de dados complexa, como as definições de classes em Java. 6.2. MYSQL O MySQL é um SGBD (Sistema de Gerenciamento de Banco de Dados), que utiliza a linguagem SQL (Structured Query Language) como interface. Um sistema gerenciador de banco de dados é o software que permite criar, manter e manipular bancos de dados para diversas aplicações. A criação e manutenção de bancos de dados são tarefas de uma pessoa ou grupo de pessoas, normalmente referenciada como o administrador do banco de dados. A manipulação do banco de dados, como atualizações e consultas, é realizada direta ou indiretamente, através de programas aplicativos, pelos usuários do banco de dados. O sistema gerenciador de banco de dados pode ser de propósito geral ou específico para alguma aplicação.