GESTAO DE CONDOMINIO

UNIMIN

AS

1

UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria nº 577/2000 – MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO

Marco Aurélio Silva Rodrigues

Maria Margaret de Vasconcellos Lemos

Orlando Alves de Oliveira

SISTEMA PARA GESTÃO DE CONDOMÍNIO

Uberlândia 2009

UNIMIN

AS

2


Maria Margaret de Vasconcelos Lemos



Trabalho de Final de curso submetido à

UNIMINAS como parte dos requisitos para a

obtenção do grau de Bacharel em Sistemas

de Informação.

Orientador: Prof. Msc. Edson Angoti Júnior

Uberlândia 2009

UNIMIN

AS

3

Marcos Aurélio Silva Rodrigues

Maria Margaret de Vasconcelos Lemos



Banca Examinadora:

Uberlândia, 9 de julho de 2009.

________________________________________________________________

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

________________________________________________________________

Profa. Dra. Kátia Lopes Silva

_________________________________________________________________

Prof. Dr. Mauro Hemerly Gazzani

Uberlândia

2009

UNIMIN

AS

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

Isaac Newton

UNIMIN

AS

AGRADECIMENTOS

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

UNIMINAS que durante nossa estada nesta casa nos acompanharam e auxiliaram

na construção de nosso conhecimento. Em especial aos professores Ana Maria

Ferreira Árabe, Edson Angoti Jr. e Kátia Lopes Silva que estiveram sempre presente

na elaboração deste trabalho.

Dividir com vocês essa autoria foi um privilégio que poucos de nós

tiveram!

UNIMIN

AS

RESUMO

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

desencadeou o processo de urbanização, que trouxe em si questões a serem

resolvidas. Como consequência, a moradia se tornou um problema a ser

equacionado. A solução que se apresentou foi a verticalização, trazendo resposta à

necessidade de espaço. Com a difusão dessa forma de associação, foram criadas

leis que regulamentaram a sua administração, que atualmente, tende à

profissionalização, tanto que há no mercado vários sistemas de informação voltados

à administração de condomínios, porém alguns clientes preferem softwares

customizados, sendo essa a escolha do Condomínio do Edifício Porto Seguro,

localizado em Uberlândia, MG. Assim, desenvolveu-se um sistema de fácil operação,

para apoiar a sua administração, possibilitando o registro de moradores e

proprietários, mantendo o histórico dessas informações. Foi feita a análise, definidos

os casos de uso e elaborados os diagramas de sequência documentados com o

emprego da UML. O modelo escolhido foi o MVC, implementado com o uso do

Eclipse e dos frameworks Struts e Hibernate. O mapeamento objeto relacional foi

realizado pelo JDBC juntamente com a utilização do framewok Hibernate. Para o

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

para se conectar ao MySQL, o SGBD escolhido para a persistência dos dados. O

servidor web selecionado foi o TomCat, que implementa as especificações servlet e

JSP. A interface com o usuário foi construída com páginas JSP de cor azul

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

ferramentas empregadas para a codificação do sistema permitiram a simplificação

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

das classes de entidades, garantindo a correlação entre as classes e as tabelas do

banco de dados. As annottations realizaram com facilidade o mapeamento objeto-

relacional e o padrão de projeto DAO proporcionou a persistência dos dados de

forma simples, no banco de dados MySQL que apresentou boa performance,

comprovando que foi uma escolha adequada à aplicação. Embora, não tenham sido

implementados todos os casos de uso, o sistema pode ser concluído, pois o número

de condomínios está crescendo e a relação entre a gerência e os condôminos tem

UNIMIN

AS

evoluído. Aliado a isso, as características do sistema e a documentação para apoiar

a expansão do projeto está disponível, o que facilitará a realização dessa tarefa.

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

software.

UNIMIN

AS

ABSTRACT

The Industrial Revolution, one of the landmarks of the Modern Age actually triggered

the process of urbanization, which in itself has brought issues to be resolved. As a

result, housing became a problem to be solved. The solution that presented itself

was the verticalisation, bringing answers to the need for space. With the spread of

this form of association, have created laws governing its administration, which

currently tends to professionalism, so that there is more market information systems

focused on management of condominiums, but some customers prefer customized

software, and this is the choice the condominium building of Porto Seguro, located in

Uberlândia, MG. Therefore, has developed a system to support its a system to

support its administration, easy operation, allowing the registration of residents and

owners, while maintaining the historical information. Was the analysis, the set of use

cases and developed the sequence of diagrams that have been documented with the

use of UML. The model chosen was the MVC, implemented using the Eclipse and

the frameworks Hibernate and Struts. The object relational mapping was performed

by JDBC with the use of Hibernate framewok. To access the database was used the

design pattern DAO, configured to connect to MySQL, the DBMS chosen for the

persistence of data. The web server selected was the Tomcat, which implements the

servlet and JSP specifications. The user interface was developed with JSP pages

with color blue as the most peaceful of all, suggesting space and depth. The tools

used for coding the system allowed the simplification of the code. Reverse

engineering performed by the Hibernate facilitating the implementation of entities

classes, ensuring correlation between classes and tables in the database. The

annottations made the object-relational mapping easy and the design pattern DAO

has been the persistence of data in a simple way, the MySQL, choosing database,

had good performance, proving that it was appropriated for the application. Although

whole use cases have not been implemented, the system can be completed because

the number of condominiums is growing and the relationship between management

and owners have changed. In addition, the system features and documentation to

support the expansion of the project is available, these will help the realization of this

task.

UNIMIN

AS

Keywords: condominium management, information system, implementation of

software.

UNIMIN

AS

LISTA DE ABREVIATURAS

API Application Programming Interface

CPF Cadastro de Pessoa Física

CPU Central Processing Unit

CRUD Create, Retrieve, Updade Delete

CSS Cascading Style Sheets

DAO Data Access Object

GPL General Public License

GNU Gnu not Unix

GoF Gang of Four

HQL Hibernate Query Language

HTML Hipertext Modelling Language

HTTP Hipertext Transfer Protocol

FK Foreign key

IBGE Instituto Brasileiro de Geografia e Estatística

IDE Integrated Development Environment

IP Internet Protocol

J2EE Java Enterprise Edition

JDBC Java Database Conectivity

JDK Java Development Kit

JEE Java Enterprise Edition

JPC Java Community Process

JSP Java Server Pages

JVM Java Virtual Machine

LGPL Lesser GNU Public License

MVC Model View Control

OBDC Open-DataBase-Connectivity

OO Orientado a Objeto

ORM Object Role Modeling

PK Primary Key

RAM Random Access Memory

SGBD Sistema de Gerenciamento de Banco de Dados

SQL Structured Query Language

TCP Transmission Control Protocol

XML eXtensible Markup Language

UNIMIN

AS

Lista de Tabelas

Página

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

1970, 1980, 1991 e contagem de 1996. ........................................................................... 18

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

Lista de Quadros

Página

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

Quadro 1 – Regras de Negócio............................................................................................................ 31

Quadro 3 – Especificação do caso de uso: Fazer Login. .................................................................... 37

Quadro 4 – Especificação do caso de uso: Cadastrar Dados. ............................................................ 39

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

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

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

Quadro 8 – Especificação do caso de uso: Atualizar Histórico. .......................................................... 49

Quadro 9 – Especificação do caso de uso: Pesquisar Histórico. ........................................................ 51

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

Quadro 11 – Especificação do caso de uso: Registrar Pagamento de Contas................................... 55

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

Quadro 13 – Especificação do caso de uso: Receber Taxa de Condomínio. ..................................... 61

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

Quadro 15 – Especificação do caso de uso: Gerar Balancete. ........................................................... 67

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

Lista de Figuras

Página

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

Figura 2 – Fachada do edifício Porto Seguro. ..................................................................................... 26

Figura 3 – Diagrama de classes de negócio........................................................................................ 35

Figura 4 – Diagrama de casos de uso. ................................................................................................ 36

Figura 5 – Diagrama de sequência do caso de uso: Fazer Login. ...................................................... 38

Figura 6 – Diagrama de sequência do caso de uso: Cadastrar Dados. .............................................. 40

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

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

UNIMIN

AS

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

Figura 10 – Diagrama de sequência do caso de uso: Atualizar Histórico. .......................................... 50

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

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

Figura 13 – Diagrama de sequência do caso de uso: Registrar pagamento de Contas. .................... 56

Figura 14 – Diagrama de sequência do caso de uso: Gerar Taxa de Condomínio............................. 59

Figura 15 – Diagrama de sequência do caso de uso: Receber Taxa de Condomínio. ....................... 62

Figura 16 – Diagrama de sequência do caso de uso: Gerar Recibo. .................................................. 65

Figura 17 – Diagrama de sequência do caso de uso: Gerar Balancete. ............................................. 68

Figura 18 – Diagrama de sequência do caso de uso: Gerar Balancete. ............................................. 71

Figura 19 – Classes do pacote entidades............................................................................................ 73

Figura 20 – Classes do pacote bo. ...................................................................................................... 74

Figura 21 – Classes do pacote persistência. ....................................................................................... 74

Figura 22 – Classes do pacote action.................................................................................................. 75

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

Login. ................................................................................................................................ 77

Figura 24 – Diagrama de sequência com as classes de projeto do caso de uso:

Cadastrar Dados............................................................................................................... 79

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

Pessoas. ........................................................................................................................... 81


Consultar Pessoa.............................................................................................................. 83


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

Figura 28 – Diagrama de sequência com as classes de projeto do caso de uso: Atualizar

Histórico. ........................................................................................................................... 87

Figura 29 – Modelo Arquitetura MVC................................................................................................... 90

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

Figura 31 – Ciclo de vida do servlet. .................................................................................................... 94

Figura 32 – Código da página consultarPessoaForm.jsp. ................................................................... 95

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

Figura 34 – Modelo em camadas......................................................................................................... 97

Figura 35 – Front Controller ................................................................................................................. 98

Figura 36 – Arquivo struts.xml.............................................................................................................. 99

Figura 37 – Método consultaUnidade. ............................................................................................... 100

Figura 38 – Diagrama de pacotes...................................................................................................... 100

Figura 39 – Classes do pacote entidades.......................................................................................... 101

Figura 40 – Classes do pacote bo ..................................................................................................... 101

Figura 41 – Classes do pacote persistência. ..................................................................................... 102

Figura 42 – Classes do pacote action................................................................................................ 102

UNIMIN

AS

Figura 43 – Página Principal .............................................................................................................. 103

Figura 44 – Action setUpForInsertOrUpdate mapeada no arquivo struts.xml. .................................. 104

Figura 45 – Método setUpForInsertOrUpdate() implementado na classe

CadastrarPessoaAction. ................................................................................................. 104

Figura 46 – Tela de Cadastro de Dados ............................................................................................ 104

Figura 47 – Action InsertOrUpdate implementado no arquivo struts.xml. ......................................... 105

Figura 48 – Método InsertOrUpdate implementado na classe CadastrarPessoaAction. .................. 105

Figura 49 – Método gravaPropAquisicao() implementado na classe


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()


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


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


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


implementado na classe CadastrarPessoaAction, quando não há histórico da

unidade. .......................................................................................................................... 112

Figura 64 – Comando declarado no método insertHistorico() implementado na classe

HistoricoBO..................................................................................................................... 113

UNIMIN

AS

Figura 65 – Código do método insert() implementado na classe HistoricoHibernateDAO............... 113

Figura 66 – Mensagem de sucesso gerada pelo método gravaPropAquisicao()


Figura 67 – Código do método isertOrUpdate() implementado na classe


Figura 68 – Action insertOrUpdate mapeada no arquivo struts.xml. ................................................. 114

Figura 69 – Tela de confirmação de cadastro.................................................................................... 115

Figura 70 – Diagrama de Navegabilidade.......................................................................................... 120

Figura 71 – Tela de Login. ................................................................................................................. 122

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

Figura 73 – Menu inicial. .................................................................................................................... 123

Figura 74 – Tela de Cadastro de Dados. ........................................................................................... 123

Figura 75 – Tela com mensagem de erro de CPF............................................................................. 124

Figura 76 – Tela com mensagem de erro, CPF cadastrado como morador em outra

unidade. .......................................................................................................................... 124

Figura 77 – Tela com mensagem de sucesso ao cadastrar os dados. ............................................. 125

Figura 78 – Tela que apresenta a lista das pessoas cadastradas..................................................... 125

Figura 79 – Tela para solicitar a pesquisa dos dados de uma pessoa.............................................. 126

Figura 80 – Tela que apresenta os dados da pessoa pesquisada. ................................................... 126

Figura 81 – Tela para solicitar a pesquisa dos dados de uma unidade. ........................................... 127

Figura 82 – Tela que apresenta os dados da unidade pesquisada. .................................................. 127

Figura 83 – Sistema simplificado de Banco de Dados. ..................................................................... 131

Figura 84 – Arquitetura de Modelo de Banco de Dados. ................................................................... 134

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

Figura 86– Modelo Lógico de Banco de Dados ................................................................................. 136

Figura 87 - Estrutura Padrão DAO. .................................................................................................... 140

Figura 88 – Arquitetura Hibernate. ..................................................................................................... 143

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

Figura 90 – Classe Hibernate Útil. ..................................................................................................... 146

Figura 91 – Classe de persistência HistoricoHibernateDAO. ............................................................ 148

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

UNIMIN

AS

SUMÁRIO

Página

1. INTRODUÇÃO 17

1.1. UM BREVE HISTÓRICO............................................................................................ 17

1.2. CENÁRIO ATUAL..................................................................................................... 20

1.3. IDENTIFICAÇÃO DO PROBLEMA ................................................................................ 22

1.4. OBJETIVOS ............................................................................................................ 23

1.4.1. Geral....................................................................................................... 23

1.4.2. Específicos ............................................................................................. 23

1.5. JUSTIFICATIVA........................................................................................................ 23

1.6. ORGANIZAÇÃO DO TRABALHO ................................................................................. 24

2. ESPECIFICAÇÃO DO PROBLEMA 26

3. ANÁLISE E PROJETO 28

3.1. UNIFIED MODELLING LANGUAGE – UML .................................................................. 28

3.2. ETAPAS DA ANÁLISE DE SISTEMA ............................................................................ 29

3.3. REQUISITOS........................................................................................................... 30

3.4. REGRAS DE NEGÓCIO............................................................................................. 31

3.5. CLASSES ............................................................................................................... 33

3.6. CASOS DE USO ...................................................................................................... 36

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

3.6.2. Caso de Uso 02: Cadastrar Dados ......................................................... 39

3.6.3. Caso de Uso 03: Listar Pessoas ............................................................. 42

3.6.4. Caso de Uso 04: Consultar Pessoa ........................................................ 44

3.6.5. Caso de Uso 05: Consultar Unidade ....................................................... 46

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

3.6.7. Caso de Uso 07: Pesquisar Histórico...................................................... 51

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

3.6.9. Caso de Uso 09: Registrar Pagamento de Contas.................................. 55

3.6.10. Caso de Uso 10: Gerar Taxa de Condomínio ......................................... 58

3.6.11. Caso de Uso 11: Receber Taxa de Condomínio ..................................... 61

3.6.12. Caso de Uso 12: Gerar Recibo ............................................................... 64

3.6.13. Caso de Uso 13: Gerar Balancete .......................................................... 67

3.6.14. Caso de Uso 14: Gerar Histórico ............................................................ 70

3.7. PROJETO............................................................................................................... 72

3.7.1. Diagramas de Sequência de Projeto....................................................... 76

4. ARQUITETURA E CÓDIGO 88

UNIMIN

AS

4.1. JAVA ..................................................................................................................... 88

4.2. ARQUITETURA MVC ............................................................................................... 89

4.3. PADRÕES DE PROJETO ........................................................................................... 90

4.3.1. DAO........................................................................................................ 91

4.3.2. Business Object ...................................................................................... 91

4.3.3. Front Controller ....................................................................................... 92

4.3.4. Application Controller .............................................................................. 93

4.4. TECNOLOGIAS UTILIZADAS...................................................................................... 93

4.4.1. Servlet .................................................................................................... 93

4.4.2. Páginas JSP ........................................................................................... 94

4.4.3. JDBC ...................................................................................................... 96

4.5. J2EE .................................................................................................................... 96

4.6. TOMCAT ................................................................................................................ 97

4.7. IMPLEMENTAÇÃO.................................................................................................... 98

4.7.1. Struts ...................................................................................................... 98

4.7.2. Diagrama de Pacotes ........................................................................... 100

4.7.3. Implementação do Caso de Uso Cadastrar Dados ............................... 103

5. INTERFACE 116

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

6. PERSISTÊNCIA DE DADOS 128

6.1. CONCEITOS DE BANCO DE DADOS......................................................................... 129

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

6.3. MODELAGEM DE BANCO DE DADOS ....................................................................... 134

6.3.1. Modelos ................................................................................................ 134

6.3.2. Compreendendo o Modelo.................................................................... 139

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

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

6.5.1. Características Hibernate...................................................................... 142

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

6.5.3. Mapeamento Objeto Relacional ............................................................ 143

6.6. MECANISMOS DE PERSISTÊNCIA ........................................................................... 148

7. CONCLUSÃO 151

REFERÊNCIAS BIBLIOGRÁFICAS 154

APÊNDICE 158

UNIMIN

AS

17

1. INTRODUÇÃO

1.1. UM BREVE HISTÓRICO

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

na tentativa de se protegerem dos instintos predatórios de outros homens e de

outros animais. A sociedade constituiu-se como forma de proteção contra abusos e

excessos, sendo um mecanismo de defesa contra a “lei do mais forte”. Assim, foram

estabelecidas normas de conduta que tornassem possível a convivência entre os

homens. Buscou-se domar a agressividade natural do ser humano, para que todos

pudessem conviver de forma próxima e participativa. Com isso, estabeleceu-se,

então, um conflito entre a necessidade de proteção e a repressão dos instintos

(FREUD, 2002). Nasceu, assim, a civilização.

Na Grécia antiga, pequenas comunidades se agrupavam em um centro,

na tentativa de se protegerem de ataques externos. Denomina-se tal fenômeno de

sinecismo, que significa coabitação. Assim, originaram-se as “Polis” gregas, que

deram origem às cidades ocidentais (WIKIPEDIA, 2009).

Ainda dentro do processo histórico, na Idade Média, embora

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

protegida dos abusos dos mais fortes. Como exemplo clássico, é possível observar

as relações nos feudos. Os senhores feudais – os mais fortes tinham direitos totais

sobre a vida de seus servos e camponeses. Nesse momento histórico, a lei do mais

forte era, por assim dizer, institucionalizada.

Na passagem do século X para o século XI se observa o crescimento

populacional, com o conseqüente aumento da demanda por alimentos. O

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

população. Se em determinadas áreas, a produção era excedente, em outros locais

se mostrava insuficiente. A solução encontrada foi o comércio. Ocorreu nesse

período o êxodo rural, representado pelo deslocamento significativo da população

rural para as cidades, sendo que muitas delas se desenvolveram junto a castelos e

mosteiros, para se protegerem dentro de seus muros (ABREU, 2009).

Foi a Revolução Industrial, um dos marcos da Idade Moderna, que

efetivamente desencadeou o processo de urbanização, definida como o aumento da

UNIMIN

AS

18

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

urbanizar foi a Inglaterra. Já em 1850, cinqüenta por cento de sua população morava

nas cidades. A aceleração da urbanização dos países desenvolvidos se deu a partir

da segunda metade do século XIX (URBANIZAÇÃO DO mundo, 2009).

No Brasil, o processo de urbanização foi mais acelerado que nos

países da Europa e na América do Norte, embora tenha ocorrido mais tardiamente,

na segunda metade do século XX. Como nos demais países, também a

industrialização foi o fator desencadeante do êxodo rural (MIRANDA, 2009). A

industrialização se intensificou a partir dos governos de Getúlio Vargas (1930 –

1945), se firmando na administração de Juscelino Kubistchek (1955 – 1960), com a

implantação da indústria automobilística (URBANIZAÇÃO DO Brasil, 2009).

De acordo com o Instituto Brasileiro de Geografia e Estatística – IBGE

até a década de 1960, a maioria da população residia nas áreas rurais. A partir de

1970 houve a inversão, com o predomínio da população urbana (55,92%), como

mostra a tabela 1 (BRASIL, 2009b).

Tabela 1 – População brasileira, segundo os censos demográficos de 1940, 1950, 1960, 1970, 1980, 1991 e contagem de 1996.

ÁREA URBANA ÁREA RURAL TOTAL ANOS

HABITANTES % HABITANTES % HABITANTES

1940 12.880.182 31,24 28.356.133 68,76 41.236.315

1950 18.782.891 36,16 33.161.506 63,84 51.944.397

1960 31.303.034 44,67 38.767.423 55,33 70.070.457

1970 52.084.984 55,92 41.054.053 44,08 93.139.037

1980 80.436.409 67,59 38.566.297 32,41 119.002.706

1991 110.990.990 75,59 35.834.485 24,41 146.825.475

1996 123.076.831 78,36 33.993.332 21,64 157.070.163

Fonte: IBGE (BRASIL, 2009a).

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

no país. Em 2000, apresentava-se mais acentuada nas regiões Sul, Sudeste e

Centro-Oeste. Na região Nordeste as áreas litorâneas apresentavam aglomerados

mais urbanizados. Em poucas áreas a taxa de urbanização era inferior a 25 por

UNIMIN

AS

19

cento, sendo que a região Sudeste apresenta taxa acima de 75 por cento na maioria

dos municípios, como mostra a figura 1.

Figura 1 – Grau de Urbanização, Brasil, 2000. Fonte: IBGE (BRASIL, 2001).

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

Mineiro, Uberlândia é considerada a maior cidade do interior do estado e em 2006, a

população era estimada em 600.358 habitantes (Tabela 2). Como observado na

região Sudeste, sua taxa de urbanização é alta, da ordem de 97,56 por cento, ao

considerar-se o censo de 2000.

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

ANOS ÁREA

1996 2000 2001 2002 2003 2004 2005 2006

Urbana 431.744 488.982 505.167 521.888 539.162 556.133 570.982 585.719

Rural 7.242 12.232 12.637 13.055 13.487 13.909 14.280 14.649

Total 438.986 501.214 517.804 534.943 552.649 570.042 585.262 600.368

Fonte: Prefeitura de Uberlândia (2007).

UNIMIN

AS

20

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

dificuldades para atender às necessidades básicas dos migrantes. Nascem, assim,

vários problemas sociais, notadamente o desemprego, a criminalidade e a

favelização (MIRANDA, 2009). Consequentemente a moradia se torna um problema

a ser equacionado. Dois aspectos tornam-se relevantes para a solução. O primeiro

diz respeito ao espaço propriamente dito, não havendo “solo” suficiente quer seja

para a moradia, quer seja para uso comercial, nas áreas mais centrais, enquanto

que o segundo ponto se trata de segurança. A solução que se apresenta é a

verticalização, ou seja, edificações de vários andares que abrigassem mais de uma

propriedade, trazendo resposta à necessidade de espaço, e aumentando a

segurança, uma vez que a cotização permite estabelecer mecanismos de proteção,

com custo mais acessível.

1.2. CENÁRIO ATUAL

Ao se considerar o município de Uberlândia, o número de condomínios

tem crescido, embora não se conheça estatística oficial sobre o assunto. Se

inicialmente, na década de 1960 os condomínios eram constituídos na área central

da cidade em edificações de vários andares, no final da década de 1980 até meados

da década de 1990, iniciou-se a construção de pequenas edificações, não mais na

região central da cidade. Um dos locais, que nesse período apresentou um grande

crescimento desse tipo de condomínio, foi o bairro Santa Maria. Nesse bairro,

localiza-se o condomínio do Edifício Porto Seguro, prédio estritamente residencial,

composto por três andares, sendo que cada andar abriga duas unidades

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

Com a difusão dessa forma de associação, foram criadas leis que

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

reconhecidas como condôminos, uma vez que passaram a dividir o domínio da

edificação. Inicialmente, a lei 4.591 de 16 de dezembro de 1964 dispunha sobre o

condomínio em edificações e as incorporações imobiliárias. Em seu artigo quinto

delega ao Código Civil a sua regulamentação: “o condomínio por meação de parede,

soalhos e tetos das unidades isoladas regular-se-á pelo disposto no Código Civil, no

que lhe for aplicável” (BRASIL, 1964). Assim, a determinação legal dos condomínios

UNIMIN

AS

21

edílicos está no Código Civil Brasileiro, notadamente no Livro III, em seus artigos

1.331 a 1.358.

De acordo com a legislação, o síndico seria a pessoa responsável pela

administração do condomínio. Embora o papel do síndico se mantenha o mesmo,

esse não precisa necessariamente ser um morador, sendo cada vez mais comum a

figura de um administrador profissional ou até mesmo uma empresa que assuma as

funções administrativas. Também, é comum a existência de empresas de

administração que apóiam as atividades do síndico.

A profissionalização dessas administrações é uma tendência, pois há

condomínios com grande número de unidades, que requerem uma abordagem mais

direcionada com embasamento legal. Também, pequenos condomínios estão

fazendo uso desses serviços, de modo que os direitos e deveres passam a ser

respeitados e exigidos de forma mais conveniente. Há, no mercado várias empresas

de administração de condomínio, inclusive sindicatos e associações de empresas,

apóiam a gestão de condomínios.

Se a revolução industrial imprimiu mudanças profundas na sociedade,

respondendo inclusive pela urbanização, a era da informação, também, tem

provocado alterações significativas na sociedade. A valorização do capital material

tem-se deslocado para a valorização do capital intelectual. A competitividade está

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

administração de um condomínio, sob o ponto de vista do condomínio, não implique

em competição com terceiros, a excelência dessa gestão traz ganhos aos

condôminos, sejam financeiros ou subjetivos ao se efetivar a possibilidade de

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

imóvel.

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

gestão, automatizando rotinas, padronizando atividades e armazenado informações

se tornam ferramentas importantes no processo de administração de condomínios.

Existem no mercado vários softwares voltados para administração de

condomínios. Alguns são disponíveis para venda outros de uso exclusivo da

administradora, sendo condicionado à contratação de serviços da empresa. A

maioria é acessada via Web, tanto pelo síndico, como pelos condôminos que têm

acesso às informações de despesa e, exclusivamente, às transações de sua

unidade. Algumas empresas apresentam vídeos demonstrativos do software, outras

UNIMIN

AS

22

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

freqüentes oferecidas são:

- cadastros gerais;

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

- mapas demonstrativos;

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

- taxas a receber;

- contas a pagar;

- tesouraria e fluxo de caixa;

- receitas e despesas regulares;

- balancetes;

- relatórios diversos.

Fazer uso de sistemas padronizados ou buscar softwares

customizados é uma decisão importante. As duas possibilidades apresentam

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

apresentar mais funcionalidades, na medida em que são aprimorados mediante

solicitações dos vários clientes. Já softwares desenvolvidos para um cliente

específico podem atender às necessidades de forma mais objetiva.

1.3. IDENTIFICAÇÃO DO PROBLEMA

Optou-se pelo desenvolvimento de um sistema de informação

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

deverá atender, sejam eles funcionais ou não funcionais. Obter junto ao cliente de

forma clara as suas necessidades é fundamental para o desenho e implementação

do sistema.

O sistema desenvolvido nesse trabalho para um pequeno condomínio

demandará uma atenção maior, uma vez que esse cliente realiza as atividades de

forma intuitiva, sem o registro de processos.

UNIMIN

AS

23

1.4. OBJETIVOS

1.4.1. Geral

Desenvolver um aplicativo Web que apóie a gestão de pequenos

condomínios habitacionais, no que tange ao gerenciamento, a administração e o

armazenamento dos dados de moradores e proprietários, assim como das

operações financeiras.

1.4.2. Específicos

- Levantar os requisitos do sistema;

- documentar os casos de uso;

- elaborar o diagrama conceitual (diagrama de classe de negócio)

- elaborar os diagramas de seqüência de análise

- implementar o sistema utilizando a linguagem de programação Java;

- utilizar o Desing Patterns J2EE;

- implementar o aplicativo em três camadas de acordo com o modelo MVC;

- implementar o diagrama de classes no nível de projeto;

- implementar a camada de apresentação através de Front Controller;

- implementar a camada de negócio através do Business Object;

- implementar a camada de integração utilizando DAO – Data Access Object;

- utilizar o Hibernate com annottations para o mapeamento objeto-relacional;

- utilizar o Struts2 com annottations e

- utilizar o MySQL como banco de dados.

1.5. JUSTIFICATIVA

Embora as atividades de gestão de um condomínio sejam em princípio

semelhantes, a abordagem pode ser diferente. Condomínios com muitas unidades se

tornam mais complexos, em função da quantidade de pessoas e consequentemente a

sua gestão implicará em atividades e rotinas diferentes das executadas naqueles com

UNIMIN

AS

24

poucas unidades. Há casos em que os moradores fazem uso de cartão de

identificação e não raro há catracas eletrônicas na portaria. Também é comum em

grandes condomínios a exigência de identificação, com registro de documento de

identidade dos visitantes.

Outros condomínios possuem uma administração mais informal, o que

não significa que não deva ter caráter legal. Ao se propor o desenvolvimento de um

sistema de informação para um condomínio com poucas unidades habitacionais, tem-

se a possibilidade de manter uma administração mais próxima e acolhedora. Assim,

alia-se o profissionalismo ao sentimento de proximidade, próprio de pequenos grupos

de pessoas, pois as relações tendem a ser mais próximas e pessoais.

Assim, desenvolver um software simplificado para a gestão de pequenos

condomínios traz o desafio de associar a tecnologia a uma gestão personalizada de

pequenos espaços residenciais, quando o mercado parece ofertar propostas mais

complexas. Esse diferencial por si só justifica o desenvolvimento de uma nova

ferramenta, para atender a essa clientela.

1.6. ORGANIZAÇÃO DO TRABALHO

Este foi um trabalho realizado em grupo, sendo que os membros se

envolveram em todas as etapas para a realização deste relatório. Os capítulos

iniciais, Introdução e Especificação do Problema e, também, o capítulo final,

Conclusão foram escritos em conjunto, não havendo uma responsabilidade maior

por parte de algum integrante do grupo. Já, os demais capítulos que correspondem

às etapas de desenvolvimento do sistema tiveram cada um, um líder que assumiu o

direcionamento de sua elaboração. Assim, os demais seis capítulos abordam os

seguintes temas:

Capítulo 2: Especificação do problema

Traz as informações sobre o condomínio e apresenta de forma sucinta

o sumário executivo.

Capítulo 3: Análise e projeto do sistema

Apresenta o referencial teórico sobre análise de projeto, traz, ainda, os

diagramas classe, de casos de uso, de sequências, tanto sob a ótica da análise,

quanto sob o ponto de vista do projeto.

Capítulo 4: Arquitetura e código

UNIMIN

AS

25

Além discorrer sobre os conceitos nos quais se apoiou o

desenvolvimento da solução, este capítulo apresenta, ainda, a arquitetura

empregada e o código da implementação.

Capítulo 5: Interface

Nesse capítulo são apresentadas as interfaces para comunicação entre

o sistema e os usuários. Cita, ainda, referencial teórico, sobretudo em relação ao

uso de cores. Diferente dos demais capítulos, esse, em especial, não teve uma

autoria definida. Porém, os autores consideram a sua apresentação como mínima,

mas importante para a visão integral do sistema, mesmo que a abordagem da

interface seja superficial.

Capítulo 6: Persistência de dados

Apresenta o processo de armazenagem e recuperação dos dados.

Resgata os conceitos e tecnologias que foram empregados durante o

desenvolvimento do sistema.

Capítulo 7: Conclusões

Nesta parte são apresentadas as conclusões observadas pelo grupo

considerando-se os objetivos que nortearam a realização deste trabalho.

UNIMIN

AS

26

2. ESPECIFICAÇÃO DO PROBLEMA

O condomínio do Edifício Porto Seguro (Figura 2) foi criado em 17 de

março de 1997, com função estritamente residencial. É formado por seis unidades

habitacionais, distribuídas em três andares e uma área térrea. A área comum é

composta pelo saguão, as escadas, corredores internos e externos e a garagem. A

construção é simétrica, sendo a parte anterior igual à parte posterior. As unidades

são iguais, apenas as do primeiro pavimento possuem uma pequena área

descoberta, que não está presente nas unidades dos demais pavimentos. Para cada

apartamento existem duas vagas de garagem que foram definidas por sorteio

realizado pelos proprietários no momento do estabelecimento do condomínio.

Figura 2 – Fachada do edifício Porto Seguro.

UNIMIN

AS

27

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

administração do imóvel vem sendo realizada por um dos condôminos que assume

a função de síndico. O valor da manutenção mensal é calculado a partir do rateio

das despesas, de modo que é pago após a realização das despesas. Dada a

proximidade e o pequeno número de moradores, a administração do imóvel é

realizada de forma bastante intuitiva e pouco formal. Assim, observam-se algumas

dificuldades no recebimento da taxa de condomínio e consequentemente o atraso no

pagamento de tarifas públicas, penalizando o conjunto dos moradores, uma vez que

não há a cobrança de multas ou juros dos moradores que pagam a sua parte do

rateio das despesas além do prazo.

Propõem-se, então o desenvolvimento de um sistema de informação

que apóie a administração do condomínio, que seja de fácil operação. Esse sistema

deverá registrar os moradores e proprietários das unidades, mantendo, inclusive o

histórico dessas informações, permitindo resgatá-las quando necessário. O software

deverá, ainda, registrar todas as contas a serem pagas para, então, gerar a taxa de

condomínio, que é dada pelo rateio das despesas mensais. O recebimento da taxa

de condomínio será realizado até o 10º dia do mês subseqüente. Após essa data

incidiram juros e multa.

Será importante que o sistema registre todos os recebimentos da taxa

de condomínio e também, o pagamento de todas as despesas do imóvel, o que

possibilitará gerar os recibos e a prestação de conta de forma automatizada.

UNIMIN

AS

28

3. ANÁLISE E PROJETO

Maria Margaret de Vasconcellos Lemos

Análise consiste em um método para se conhecer um problema ou

situação, em que se divide o objeto do estudo em partes para o exame minucioso de

cada componente. Voltada para desenvolvimento de software, a análise é o

processo através do qual se busca conhecer o negócio do cliente, para produzir um

modelo que espelhe a realidade.

O principal objetivo da análise de sistemas é realizar um mapeamento

prévio do comportamento requerido para os elementos de modelagem que serão

implementados posteriormente na fase de construção (SILVA, 2009).

Assim, modelagem é a concepção de sistemas de informações, antes

que sejam codificados. É, ainda, parte essencial do desenvolvimento de grandes

projetos, sendo, também, importante para aqueles de médio e pequeno porte. Trata-

se de uma forma de visualizar o projeto e verificar se os requisitos estão sendo

atendidos antes da implementação (OBJECT MANEGEMMENT GROUP, 2009).

Dada a importância da elaboração de projetos de softwares, foi definida uma

linguagem padrão para a sua execução, a Unified Modeling Language, UML.

3.1. UNIFIED MODELLING LANGUAGE – UML

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

das regras de interação entre seus vocábulos. Assim, a UML indica como criar e ler

modelos bem formados. Um modelo escrito empregando-se a UML poderá ser

interpretado sem ambigüidades por outro desenvolvedor ou outra ferramenta.

Os blocos de construção da UML são os itens, os relacionamentos e os

diagramas. Os itens são as abstrações identificadas e podem ser de quatro tipos. Os

itens estruturais representam elementos conceituais ou físicos. São as partes

estáticas do modelo, enquanto que os itens comportamentais são as partes

dinâmicas, definidos pelos verbos, uma vez que representam o comportamento no

tempo e espaço. Os itens de agrupamento são as partes organizacionais.

Correspondem aos pacotes que são meramente conceituais e agregam os itens

UNIMIN

AS

29

estruturais, comportamentais e ainda outros itens de grupo, quando necessário. Já,

os itens anotacionais são aqueles que explicam o modelo.

Os relacionamentos definem a interação entre os elementos podendo

ser de quatro tipos. Dependência, acontece quando a alteração do item

independente implica na alteração semântica do item dependente. A associação

descreve a conexão entre os objetos, podendo ser uma agregação que define um

relacionamento estrutural entre o todo e suas partes. O relacionamento de

generalização implica em objetos especializados, os filhos, que podem ser

substituídos por objetos generalizados, os pais. O quarto tipo de relacionamento, a

saber, a realização, trata-se de um contrato em que um classificador especifica o

que outro classificador garante executar, como os métodos definidos pela interface

que a classe deve implementar.

Os diagramas são representações gráficas que oferecem vários

ângulos de visualização de um sistema. São nove os diagramas definidos pela UML,

sendo que cada um tem função bem definida. O diagrama de classes exibe o

conjunto de classes, interfaces, colaborações e os relacionamentos, enquanto que o

diagrama de objeto apresenta os objetos e seus relacionamentos. Já, o diagrama de

casos de uso representa o conjunto de caos de uso e atores, sendo importante para

organização e modelagem de comportamento do sistema. Para registrar a interação

há o diagrama de seqüência cujo foco principal é a ordem temporal das mensagens

e o diagrama de colaboração que privilegia a organização estrutural entre os

objetos. Outro diagrama, o de estado, exibe o estado, transição, eventos e

atividades. Traz, portanto, uma visão dinâmica do sistema, sendo o diagrama de

atividade um tipo especial de diagrama de estado, pois apresenta o fluxo de uma

atividade para outra. A visão estática da implementação do sistema pode ser

representada pelo diagrama de componentes que apresenta as organizações e de

pendências entre um conjunto de componentes. Já a visão estática de uma

arquitetura é oferecida pelo diagrama de implantação (BOOCH, RUMBAUGH &

JACOBSON, 2000).

3.2. ETAPAS DA ANÁLISE DE SISTEMA

A primeira etapa da análise de um sistema consiste na descoberta de

informações sobre o domínio da aplicação, quais as funcionalidades requeridas, qual

UNIMIN

AS

30

o desempenho que o sistema deve apresentar as restrições de hardware, dentre

outras questões. Responder a essas e outras perguntas envolvem grande número

de pessoas de diferentes áreas da empresa contratante. Essa fase é muito

importante, pois quanto mais claras as especificações, mais fiel à realidade será o

modelo.

Nesta fase são empregadas técnicas de elucidação de requisitos, com

o intuito de aumentar o comprometimento do cliente e desenvolvedores, com a

solução que se deseja construir. É muito importante que os requisitos sejam

extraídos de maneira correta e objetiva.

Nessa etapa são identificadas as regras de negócio e os requisitos do

sistema, que podem ser de dois tipos, os funcionais e os não funcionais.

3.3. REQUISITOS

Os requisitos descrevem de modo claro, sem ambigüidades, conciso e

consistente todos os aspectos significativos do sistema proposto. Eles devem

permitir que os desenvolvedores construam um sistema que satisfaça os clientes.

Um requisito é considerado como funcional quando descreve um

serviço ou função a ser realizada. Já requisitos não funcionais coincidem com

restrições ou condições impostas ao sistema ou ao seu desenvolvimento (SILVA,

BONIN & PALUDO, 2007).

O quadro 1 apresenta a relação dos requisitos funcionais e não

funcionais levantados para o desenvolvimento do sistema em questão.

Com o levantamento dos requisitos é possível identificar as classes

que estarão envolvidas no desenvolvimento do software e o reconhecimento dos

principais processos da empresa que definirão os casos de uso do sistema. Uma

vez estabelecidos e documentados os casos de uso, passa-se à etapa seguinte que

descreve as interações ocorridas no sistema, muito bem representadas pelos

diagramas de sequência.

UNIMIN

AS

31

Requisitos funcionais

1. Cadastrar proprietários;

2. cadastrar moradores;

3. registrar contas a pagar;

4. calcular o valor da taxa de condomínio;

5. registrar recebimento mensal da taxa de condomínio;

6. registrar pagamentos;

7. emitir recibos;

8. gerar prestação de contas.

Requisitos não-funcionais

1. Ser compatível com o Windows XP;

2. permitir o acesso via Web;

3. usar a linguagem Java;

4. usar o contêiner web apache;

5. usar banco de dados MySQL

Quadro 1 – Requisitos do sistema.

3.4. REGRAS DE NEGÓCIO

As regras de negócio dizem respeito às operações, definições e

restrições de uma organização para alcançar seus objetivos. São usadas para

alcançar os objetivos de uma empresa, a comunicação entre ela e terceiros e,

também, demonstrar as obrigações legais, operar mais eficientemente, automatizar

operações, dentre outras (ARAUJO, 2009). As regras de negócio podem ter origens

variadas. Há aquelas que são definidas por dispositivos legais, como o percentual a

ser pago a título de imposto ou o valor permitido para o cálculo de juros ou multas.

Outras definem as pessoas responsáveis por determinadas operações no sistema.

Existem, ainda, regras para cálculos internos, a obrigatoriedade de validação de

dados, como por exemplo, no sistema proposto, o CPF a ser cadastrado deverá ser

uma sequência numérica válida.

Para o sistema de condomínio, foram identificadas e documentadas

dez regras de negócio como apresenta o quadro 2 a seguir.

UNIMIN

AS

32

Nome Permissão RN - 01

Descrição Somente poderão operar o sistema as pessoas autorizadas.

Nome Cadastro de dados pessoais RN - 02

Descrição Somente serão cadastradas as pessoas com CPF válido.

Nome Cadastro de moradores RN - 03

Descrição Para cadastrar o morador de uma unidade é preciso ter registrado a mudança do morador anterior. Assim, somente será cadastrado o morador de uma unidade, quando não houver morador já cadastrado.

Nome Cadastro de proprietário RN - 04

Descrição

Para cadastrar o proprietário de uma unidade é preciso ter registrado a venda realizada pelo proprietário anterior. Assim, somente será cadastrado o proprietário de uma unidade, quando não houver proprietário já cadastrado.

Nome Lançamento de contas a pagar RN - 05

Descrição Todas as contas a pagar serão lançadas no sistema.

Nome Geração da taxa de condomínio RN – 06

Descrição

A taxa de condomínio será gerada sempre no dia 1º do mês.

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

Descrição

O valor da taxa de condomínio de cada unidade é calculado pela soma dos pagamentos de contas realizados no mês anterior, dividido por 6.

Nome Data para o pagamento da taxa de condomínio RN – 08

Descrição

A taxa de condomínio deverá ser paga até o dia 10 do mês subseqüente. Caso o dia 10 não seja dia útil, a data do pagamento será automaticamente transferida para o próximo dia útil.

UNIMIN

AS

33

Nome Pagamento da taxa de condomínio RN - 09

Descrição

Pagamentos realizados após a data estabelecida serão acrescidos de juros de 2% ao mês e multa de 3%.

Nome Registro de pagamento da taxa de condomínio RN - 10

Descrição

Todos os pagamentos de taxa de condomínio serão registrados no sistema.

Quadro 2 – Regras de Negócio.

3.5. CLASSES

O diagrama de classes é considerado por vários autores como o mais

importante e utilizado diagrama da UML. Ele apresenta uma visão estática da

organização das classes do sistema, permitindo além da visualização das classes e

de seus atributos e métodos, a representação de seus relacionamentos, como estas

se complementam e a transmissão da informação dentro do sistema (SILVA, 2007).

Durante o processo de análise, ao se delinear o sumário executivo,

como regra básica para nortear o analista, considera-se que os substantivos

encontrados sugerem as classes de negócios necessárias para o desenvolvimento

da aplicação. Da mesma forma, os verbos descreveriam os casos de usos. Na

verdade, o levantamento das classes e dos casos de uso de um sistema, muitas

vezes, acontece de forma simultânea. A partir dessa visão e da proposta de

apresentar o diagrama de casos de uso seguido pelas especificações de cada caso

de uso e dos respectivos diagramas de sequência, serão apresentadas inicialmente

as classes e os diagrama de classes correspondente.

O processo de levantamento das necessidades e requisitos evidenciou

a necessidade de implementação de sete classes de negócio para o

desenvolvimento do sistema, conforme definidas abaixo:

Classe UsuarioEntidade

Essa classe registra o nome de usuário e a respectiva senha para

permitir a operação do sistema.

UNIMIN

AS

34

Classe Pessoa

É responsável pelo registro de todas as pessoas que se relacionam

com o imóvel, sejam moradores ou proprietários. Os atributos dessa classe são:

nome, CPF e telefone.

Classe Unidade

Registra todas as unidades habitacionais existentes, ou seja, os

apartamentos. Mantém o registro do atual morador e atual proprietário. Seus

atributos são: número, morador e proprietário.

Classe Histórico

Essa classe é responsável por manter o registro de todos os

moradores e proprietários de cada uma das unidades, registrando inclusive a data

inicial e a data do término da relação de cada pessoa com a unidade. Por isso tem

como atributos: unidade, proprietário, proDtAquisicao, pro_DtVenda, morador,

mor_DtEntrada e mor_DtSaida.

Classe ContasAPagar

Essa classe é responsável pelo registro de todas as contas que o

condomínio deverá pagar em função de bens adquiridos ou serviços recebidos. Os

atributos dessa classe são: dataVencimento, descricaoConta, valorConta e mesRef.

Classe TaxaCondomínio

Essa classe gera e mantém o valor mensal a ser pago pelos

condôminos a título de taxa de condomínio. Seus atributos são: mesRef, valorTaxa,

dataGeracao, datavencimento.

Classe LancamentoMes

É responsável pelo registro das operações financeiras do condomínio

mantendo os dados dos pagamentos e dos recebimentos das taxas de condomínio.

Os atributos dessa classe são: data, tipo, descrição, juros, multa e valorFinal.

Na etapa de análise foi usado o Enterprise Architect ferramenta

desenvolvida para a análise, modelagem e manutenção de softwares, que emprega

a UML e gera a documentação do sistema. Como um dos resultados do emprego

dessa ferramenta foi o diagrama de classes obtido pela interação das classes

descritas anteriormente (Figura 3).

UNIMINAS

35

Figura 3 – Diagrama de classes de negócio.

UNIMIN

AS

36

3.6. CASOS DE USO

Conceitualmente, casos de uso dizem respeito às principais atividades

da empresa ligadas ao sistema a ser implementado, sendo assim, cada caso de uso

está ligado a um conjunto de requisitos funcionais do sistema (WAZLAWICK, 2004).

A simplicidade de um diagrama de casos de uso permite a observação das

funcionalidades, os usuários envolvidos e as possíveis integrações com sistemas

externos (YOSHIMA, 2005). Foram identificados quatorze casos de uso, conforme a

figura 4.

Figura 4 – Diagrama de casos de uso.

A interação com o sistema é realizada pelo Síndico, pessoa

responsável pela gestão do condomínio. Outras pessoas, que por ventura operem o

sistema, somente o farão com a autorização do síndico e as permissões e

responsabilidades serão idênticas às dele. Por isso, para o desenvolvimento do

aplicativo, considerou-se, apenas a existência de um único ator.

UNIMIN

AS

37

3.6.1. Caso de Uso 01: Fazer Login

Nesse caso de uso, o síndico solicita entrar no sistema e para isso

informa os dados necessários para obter a permissão de operar o sistema, conforme

especificado no quadro 3.

Nome Fazer Login CSU - 01

Sumário Este caso de uso descreverá os procedimentos para realizar o login no sistema

Ator primário: Síndico.

Ator(es) secundário(s): Não há.

Pré-condição: O usuário estar cadastrado.

Pós-condição: O login foi realizado.

Fluxo Principal

1. O síndico inicia sistema.

2. O sistema apresenta o formulário para o login.

3. O síndico informa o usuário e a senha.

4. Sistema verifica os dados e encerra o caso de uso

Fluxo Alternativo:

Não há.

Fluxo de Exceção [3]: Dados incorretos

a. O sistema informa que os dados estão incorretos e volta ao item 2.

Regras de Negócio Associadas

RN01

Quadro 3 – Especificação do caso de uso: Fazer Login.

UNIMIN

AS

38

O diagrama de sequência desse caso de uso apresenta o fluxo das

mensagens que são trocadas entre os componentes do sistema para permitir que o

usuário possa operar o sistema, como mostra a figura 5.

Figura 5 – Diagrama de sequência do caso de uso: Fazer Login.

As classes de análise envolvidas neste caso de uso e os respectivos

papéis são:

a) Interface de Fazer Login: representa a classe de fronteira desse caso de uso.

Permite que o usuário informe os dados para realizar o login no sistema, de

modo que possa operar o sistema.

b) Controlador de Fazer Login: representa a classe de controle deste caso de uso.

Sua função é interpretar os comandos realizados entre a interface Fazer Login

e a classe Usuários.

c) Usuários: representa a classe de entidade deste caso de uso. Sua função é

armazenar os atributos responsáveis por realizar a autenticação dos dados do

usuário.

d) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.

É apresentada após a autenticação do login.

UNIMIN

AS

39

3.6.2. Caso de Uso 02: Cadastrar Dados

Neste caso de uso, o síndico fará o cadastro de uma pessoa que terá

relação com o condomínio de moradia ou de propriedade. O sistema não permitirá o

cadastro de morador ou proprietário de uma unidade se outra pessoa já estiver

cadastrada nessa situação. Para isso é necessário registrar, anteriormente a saída

ou a venda da unidade (Quadro 4) .

Quadro 4 – Especificação do caso de uso: Cadastrar Dados.

Nome Cadastrar Dados CSU - 02

Sumário Este caso de uso descreverá os procedimentos realizados para o cadastro dos dados pessoais de proprietários ou moradores e a unidade com a qual manterão relação.



Pré-condição: Não haver registro de pessoa na unidade, na condição a ser

registrada.

Pós-condição: O cadastro foi realizado.

Fluxo Principal

1. O síndico solicita o cadastro de dados pessoais.

2. O sistema apresenta o formulário para o preenchimento dos dados.

3. O síndico realiza o preenchimento do formulário.

4. O síndico confere os dados inseridos no formulário e confirma.

5. Sistema registra o cadastro e encerra o caso de uso

Fluxo Alternativo:

Não há.

Fluxo de Exceção [4A]: CPF inválido

a. O sistema informa que o CPF não é válido e volta ao item 3.

Fluxo de Exceção [4B]: Existe morador ou proprietário cadastrado

a. O sistema informa que não é possível cadastrar a pessoa na condição escolhida e encerra o caso de uso.

Regras de Negócio Associadas RN02, RN03 e RN04

UNIMIN

AS

40

O diagrama deste caso de uso exibe o fluxo de interação,

apresentando a sequência das mensagens para a sua execução (Figura 6).

Figura 6 – Diagrama de sequência do caso de uso: Cadastrar Dados.


papéis são:

a) Menu Inicial: representa a interface de acesso às funcionalidades dos sistema.

No caso, o síndico solicita o cadastro de uma pessoa.

b) Controlador de Cadastrar Dados: representa a classe de controle deste caso de

uso. Sua função é interpretar os comandos realizados entre as interfaces e as

classes de entidades Pessoa, Unidade e Histórico, responde, ainda, pela

validação do CPF.

c) Interface de Cadastrar Dados: representa a classe de fronteira desse caso de

uso. Permite que o usuário informe os dados para cadastrar uma pessoa no

sistema.

UNIMIN

AS

41

d) Pessoa: representa uma das classes de entidade deste caso de uso. Sua

função é armazenar os atributos das pessoas cadastradas, nome; CPF e

telefone.

e) Unidade: representa outra classe de entidade deste caso de uso. Sua função é

armazenar os atributos das unidades, o número da unidade, a pessoa que é

moradora, assim como a pessoa que é proprietária da unidade em questão.

f) Histórico: representa a terceira e última classe de entidade deste caso de uso.

Sua função é armazenar os atributos das relações entre as pessoas e as

unidades. Mantendo os dados mesmo após o término dessa relação. Os

atributos dessa classe são: o número da unidade; a pessoa moradora; a data

de entrada e a data de saída do morador; a pessoa que é proprietária; a data

de aquisição e a data de venda relativa a esse proprietário.

UNIMIN

AS

42

3.6.3. Caso de Uso 03: Listar Pessoas

Esse caso de uso descreve os procedimentos que serão realizados

para o sistema apresentar a relação das pessoas que já se encontram cadastradas,

como mostra o quadro 5.

Nome Listar Pessoas CSU - 03

Sumário Este caso de uso descreve os procedimentos realizados para apresentar os dados de todas as pessoas cadastradas.



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


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



UNIMIN

AS

43

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


papéis são:


No caso, o síndico solicita a lista das pessoas cadastradas.

b) Controlador de Listar Pessoas: representa a classe de controle deste caso de

uso. Sua função é interpretar os comandos realizados entre o Menu Inicial e a

classe de entidade Pessoa, responde, ainda, pela verificação se a lista não está

vazia.

c) Interface de Listar Pessoas: representa a classe de fronteira desse caso de uso,

apresenta a lista das pessoas cadastradas.

d) Pessoa: representa a classe de entidade deste caso de uso. Sua função é

armazenar os atributos das pessoas cadastradas, nome; CPF e telefone.

UNIMIN

AS

44

3.6.4. Caso de Uso 04: Consultar Pessoa


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.



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.


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


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



UNIMIN

AS

45

Figura 8 – Diagrama de sequência do caso de uso: Consultar Pessoa.


papéis são:


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


telefone.

UNIMIN

AS

46

3.6.5. Caso de Uso 05: Consultar Unidade


para a consulta dos dados de uma unidade, como mostra o quadro 7.

Nome Consultar Unidade CSU - 05

Sumário Este caso de uso descreve os procedimentos realizados para consultar os dados de cadastro de uma unidade.



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.


Fluxo Alternativo:

Não há.

Fluxo de Exceção:

Não há.


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



UNIMIN

AS

47

Figura 9 – Diagrama de sequência do caso de uso: Consultar Unidade.


papéis são:


No caso, o síndico solicita consultar os dados de uma unidade.

b) Controlador de Consultar Unidade: representa a classe de controle deste caso


interface de Consultar Unidade e as classes de entidades Unidade e Pessoa.

c) Interface de Consultar Unidade: representa a classe de fronteira desse caso de

uso. Disponibiliza ao síndico o formulário para obter o número da unidade a ser

consultada e como resposta, apresenta o nome do morador e do proprietário da

unidade consultada.

d) Unidade: representa uma das classes de entidade deste caso de uso. Sua

função é armazenar os atributos das unidades, o número da unidade, a pessoa

UNIMIN

AS

48

que é moradora, assim como a pessoa que é proprietária da unidade em

questão.

e) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é


UNIMIN

AS

49

3.6.6. Caso de Uso 06: Atualizar Histórico


para atualizar os dados do histórico de uma unidade. Nesse caso de uso, as regras

de negócio associadas, determinam que o mesmo seja executado e não interferem

no processo de sua realização. Sendo assim, não geram fluxo de exceção, como

mostra o quadro 8.

Nome Atualizar Histórico CSU - 06

Sumário Este caso de uso descreverá os procedimentos realizados para atualizar os dados do histórico de determinada unidade.

Ator primário: Síndico

Ator(es) secundário(s): Não há

Pré-condição: Haver histórico anterior em aberto.

Pós-condição: O histórico foi atualizado.

Fluxo Principal

1. O síndico solicita a atualização o histórico de uma unidade.

2. O sistema apresenta o formulário para a atualização dos dados do histórico

de uma unidade.

3. O síndico realiza o preenchimento do formulário.

4. O síndico confere os dados inseridos no formulário e confirma.

5. Sistema registra a atualização e encerra o caso de uso

Fluxo Alternativo [3A]: Cadastro de venda

a. O síndico informa que é registro de venda do imóvel.

Fluxo Alternativo [3B]: Cadastro de saída

a. O síndico informa que é registro de saída do imóvel.

Fluxo de Exceção: Não há.

Regras de Negócio Associadas RN 03 e RN 04

Quadro 8 – Especificação do caso de uso: Atualizar Histórico.

UNIMIN

AS

50



Figura 10 – Diagrama de sequência do caso de uso: Atualizar Histórico.


papéis são:


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


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



questão.

e) Unidade: representa uma das classes de entidade deste caso de uso. Sua


UNIMIN

AS

51


questão.

3.6.7. Caso de Uso 07: Pesquisar Histórico


para pesquisar os dados de histórico de uma unidade, como mostra o quadro 9.

Nome Pesquisar Histórico CSU - 07

Sumário Este caso de uso descreve os procedimentos realizados para pesquisar o histórico de uma dada unidade.


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.


Fluxo Alternativo [4A]: O cadastro está vazio

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

unidade.


Fluxo de Exceção:

Não há.


Quadro 9 – Especificação do caso de uso: Pesquisar Histórico.

UNIMIN

AS

52



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


papéis são:


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


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.




questão.

UNIMIN

AS

53

3.6.8. Caso de Uso 08: Registrar Conta a Pagar


para registrar contas a pagar. Embora haja regra de negócio envolvida na realização

desse caso de uso, esta não interfere em sua execução, apenas determina que deve

ser executado, como mostra o quadro 10.

Nome Registrar Contas a Pagar CSU - 08

Sumário Este caso de uso apresenta os passos para o registro das contas a pagar.



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.


Fluxo Alternativo:

Não há.

Fluxo de Exceção:

Não há.


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



UNIMIN

AS

54

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


papéis são:


No caso, o síndico solicita registrar uma conta que deverá ser paga

posteriormente.

b) Controlador de Registrar Contas a Pagar: representa a classe de controle deste

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

Inicial, a interface de Registrar Contas a Pagar e a classe de entidade Contas a

Pagar.

c) Interface de Contas a Pagar: representa a classe de fronteira desse caso de

uso. Disponibiliza ao usuário o formulário para preenchimento dos dados da

conta em questão.

d) Contas a Pagar: representa a classe de entidade deste caso de uso. Sua

função é armazenar os atributos das contas que serão pagas, a data de

vencimento, a descrição e o valor da conta e também, o mês de referência.

UNIMIN

AS

55

3.6.9. Caso de Uso 09: Registrar Pagamento de Contas


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(es) secundário(s): não há.

Pré-condição: A conta a pagar ter sido cadastrada anteriormente.

Pós-condição: O pagamento da conta foi registrado.

Fluxo Principal

1. O síndico solicita o registro do pagamento de contas.

2. O sistema apresenta as contas já cadastradas.

3. O síndico seleciona a conta.

4. O sistema apresenta as informações da conta e solicita o preenchimento

dos dados complementares.

5. O síndico informa os dados.

6. O sistema registra as informações.

7. O sistema encerra o caso de uso.

Fluxo Alternativo:

Não há.

Fluxo de Exceção [2]: Não há conta cadastrada.

a) O sistema informa que não há conta cadastrada.

b) O sistema encerra o caso de uso.

Fluxo de Exceção [4]: Não há conta para pagar.

a. O sistema informa que não há conta para pagar.

b. O sistema encerra o caso de uso.


RN 05 Quadro 11 – Especificação do caso de uso: Registrar Pagamento de Contas.

UNIMIN

AS

56



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


papéis são:


No caso, o síndico solicita registrar o pagamento de uma conta.

b) Controlador de Registrar Pagamento de Contas: representa a classe de

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

entre o Menu Inicial, a interface de Registrar Pagamento de Contas, e as

classes de entidade Contas a Pagar e Lançamento Mês.

c) Interface de Registrar Pagamento de Contas: representa a classe de fronteira

desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento

dos dados para o pagamento de uma conta. Na sequência apresenta as contas

que podem ser pagas para que o síndico escolha a que irá pagar e informe os

dados do pagamento.

UNIMIN

AS

57

d) Contas a Pagar: representa uma das classes de entidade deste caso de uso.

Sua função é armazenar os atributos das contas que serão pagas, a data de


e) Lançamento Mês: corresponde a outra classe de entidade envolvida nesse

caso de uso. Sua função é armazenar os atributos dos lançamentos financeiros,

data, tipo, descrição, juros, multa e valor final.

UNIMIN

AS

58

3.6.10. Caso de Uso 10: Gerar Taxa de Condomínio



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.


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.


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

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

UNIMIN

AS

59



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


papéis são:


No caso, o usuário solicita a geração da taxa de condomínio de um

determinado mês.

b) Controlador de Gerar Taxa de Condomínio: representa a classe de controle

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

Menu Inicial, a interface de Gerar Taxa de Condomínio, e as classes de

entidade Contas a Pagar e Taxa de Condomínio.

c) Interface de Gerar Taxa de Condomínio: representa a classe de fronteira desse

caso de uso. Disponibiliza ao síndico o formulário para preenchimento dos

dados para a geração da taxa de condomínio de um determinado mês.

UNIMIN

AS

60

d) Contas a Pagar: representa uma das classes de entidade deste caso de uso.



e) Taxa de Condomínio: corresponde a outra classe de entidade envolvida nesse

caso de uso. Sua função é armazenar os atributos da taxa de condomínio, mês

de referência, o valor da taxa, a data de geração e a data de vencimento da

taxa de condomínio.

UNIMIN

AS

61

3.6.11. Caso de Uso 11: Receber Taxa de Condomínio



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


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.


4. O sistema solicita a confirmação.

5. O síndico confirma os dados.

6. O sistema apresenta o recibo.


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.


RN 08, RN09 e RN 10

Quadro 13 – Especificação do caso de uso: Receber Taxa de Condomínio.

UNIMIN

AS

62



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


papéis são:


No caso, o síndico solicita a registrar o recebimento de taxa de condomínio.

b) Controlador de Receber Taxa de Condomínio: representa a classe de controle

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

Menu Inicial, a interface de Receber Taxa de Condomínio, e as classes de

entidade Taxa de Condomínio, Lançamento Mês, Unidade e Pessoa.

c) Interface de Receber Taxa de Condomínio: representa a classe de fronteira

desse caso de uso. Disponibiliza ao síndico o formulário para preenchimento

dos dados para o registro do recebimento da taxa de condomínio referente a

uma unidade e determinado mês.

UNIMIN

AS

63

d) Taxa de Condomínio: corresponde a uma das classes de entidade envolvida

nesse caso de uso. Sua função é armazenar os atributos da taxa de

condomínio, mês de referência, o valor da taxa, a data de geração e a data de

vencimento da taxa de condomínio.

e) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse



f) Unidade: representa uma das classes de entidade deste caso de uso. Sua



questão.

g) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é


UNIMIN

AS

64

3.6.12. Caso de Uso 12: Gerar Recibo



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.



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.


4. O sistema solicita confirmação.


6. O sistema gera o recibo.


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.



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

UNIMIN

AS

65



Figura 16 – Diagrama de sequência do caso de uso: Gerar Recibo.


papéis são:


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.



UNIMIN

AS

66


questão.

e) Pessoa: representa outra classe de entidade deste caso de uso. Sua função é


f) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse



UNIMIN

AS

67

3.6.13. Caso de Uso 13: Gerar Balancete



Nome Gerar Balancete CSU - 13

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



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.




6. O sistema gera o balancete.



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.



RN 08, RN09 e RN 10

Quadro 15 – Especificação do caso de uso: Gerar Balancete.

UNIMIN

AS

68



Figura 17 – Diagrama de sequência do caso de uso: Gerar Balancete.


papéis são:


No caso, o síndico solicita a geração de balancete.

b) Controlador de Gerar Balancete: representa a classe de controle deste caso de


interface de Gerar Balancete, e as classes de entidade Contas a Pagar e

Lançamento Mês.

c) Interface de Gerar Balancete: representa a classe de fronteira desse caso de

uso. Disponibiliza ao síndico o formulário para preenchimento dos dados para

a geração de um balancete de determinado período.

UNIMIN

AS

69

d) Lançamento Mês: corresponde a uma das classes de entidade envolvida nesse



e) Contas a Pagar: representa uma das classes de entidade deste caso de uso.



UNIMIN

AS

70

3.6.14. Caso de Uso 14: Gerar Histórico



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


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.




6. O sistema gera o histórico.



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.



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

UNIMIN

AS

71



Figura 18 – Diagrama de sequência do caso de uso: Gerar Balancete.


papéis são:


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


interface de Gerar Histórico, e as classes de entidade Histórico e Pessoa.

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

Disponibiliza ao síndico o formulário para preenchimento dos dados para a

geração do Histórico de determinada unidade.

d) Histórico: representa a terceira e última classe de entidade deste caso de uso.

Sua função é armazenar os atributos das relações entre as pessoas e as

unidades. Mantendo os dados mesmo após o término dessa relação. Os

atributos dessa classe são: o número da unidade; a pessoa moradora; a data

UNIMIN

AS

72

de entrada e a data de saída do morador; a pessoa que é proprietária; a data

de aquisição e a data de venda relativa a esse proprietário.

e) Pessoa: representa uma das classes de entidade deste caso de uso. Sua


telefone.

3.7. PROJETO

Após a análise, há a definição da tecnologia e arquitetura empregadas

no desenvolvimento do sistema. Nesse trabalho, foram definidos o emprego do

business object, de classes action e do data access object, esses componentes

serão apresentados com mais detalhes no capítulo 4 “Arquitetura e Código” e

capítulo 6 “Persistência de Dados” ficando limitado ao capítulo atual a apresentação

das classes de projeto e dos diagramas de sequência gerados a partir da interação

entre as classes.

Desta forma, após definidos os requisitos; os casos de uso;

estabelecidas as classes de negócio e as suas interações através dos diagramas de

seqüência, o processo de elaboração do projeto definiu a existência de outras

classes. De modo que, além das classes já apresentadas, foram incluídas no

projeto as seguintes classes:

− UsuarioEntidade;

− HibernateUtil;

− LoginBO;

− LoginCO;

− LoginDAO;

− Login2;

− PessoaBO;

− PessoaDAO;

− PessoaHibernateDAO;

− UnidadeBO;

− UnidadeDAO;

− UnidadeHibernateDAO;

− HistoricoBO;

− HistoricoDAO.

− HistoricoHibernateDAO;

− CadastrarPessoaAction e

− PesquisarAction.

A documentação apresentada a seguir foi gerada por engenharia

reversa se utilizando a ferramenta MDG que integra o Eclipse ao Enterprise Architect.

UNIMIN

AS

73

Assim,, a partir do código foram elaborados os diagramas estáticos, respeitando os

pacotes com os quais a aplicação foi organizada.

As classes de negócio e a classe UsuarioEntidade foram agrupadas no

pacote entidade como mostra a figura 19.

Figura 19 – Classes do pacote entidades.

UNIMIN

AS

74

No pacote bo se concentraram as seguintes classes: LoginBO;

PessoaBO; UnidadeBO e HistoricoBO (Figura 20).

Figura 20 – Classes do pacote bo.

As classes de persistência, aquelas com terminação “DAO” e, ainda, a

classe HibernateUtil, estão presentes no pacote DAO, como representado pela

figura 21.

Figura 21 – Classes do pacote persistência.

UNIMIN

AS

75

E finalmente, as classes Login2; CadastrarPessoaAction e

PesquisarAction estão localizadas em um mesmo pacote como apresentado na

figura 22.

Figura 22 – Classes do pacote action.

UNIMIN

AS

76

3.7.1. Diagramas de Sequência de Projeto

Os diagramas de sequência em nível de projeto envolvem as classes

de negócio e, também, as classes criadas para o desenvolvimento, considerando a

tecnologia escolhida para a implementação do aplicativo.

3.7.1.1 Caso de Uso 01: Fazer Login

Esse diagrama ilustra os passos do sistema para realizar o login do

usuário ao sistema, como mostra a figura 23.

UNIMINAS

77

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

UNIMIN

AS

78

3.7.1.2 Caso de Uso 02: Cadastrar Dados

Esse diagrama apresenta a sequência e a comunicação entre as

classes de projeto do sistema para cadastrar os dados dos moradores e

proprietários de unidades do condomínio, como apresentado na figura 24.

UNIMINAS

79

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

UNIMIN

AS

80

3.7.1.3 Caso de Uso 03: Listar Pessoas

A sequência realizada pelo sistema para listar as pessoas cadastradas

no sistema está ilustrada na figura 25.

UNIMINAS

81

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

UNIMIN

AS

82

3.7.1.4 Caso de Uso 04: Consultar Pessoa

O comportamento do sistema e as classes envolvidas na realização do

caso de uso Consultar Pessoa estão representados na figura 26.

UNIMINAS

83

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

UNIMIN

AS

84

3.7.1.5 Caso de Uso 05: Consultar Unidade

Esse diagrama apresenta as classes envolvidas e a relação entre elas

para a realização do caso de uso Consultar Unidade (Figura 27).

UNIMINAS

85

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

UNIMIN

AS

86

3.7.1.6 Caso de Uso 06: Atualizar Histórico

Esse diagrama representa o comportamento do sistema para realizar o

caso de uso Atualizar Histórico (Figura 28).

UNIMINAS

87

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

UNIMIN

AS

88

4. ARQUITETURA E CÓDIGO


Com a crescente necessidade de automação de processos para

melhor desempenho na execução das tarefas se aumentou, também, a utilização de

software dentro de vários setores de uma organização para apoiar as rotinas diárias,

Diante desse cenário foi desenvolvida uma aplicação específica para o

Condomínio do Edifício Porto Seguro com o objetivo de apoiar a administração deste

condomínio, permitindo o acompanhamento de sua ocupação bem como gestão

financeira da manutenção mensal do imóvel. Para essa aplicação o padrão de

utilizado foi de desenvolvimento em camadas para que fique separado por módulos

de apresentação, negócios e integração.

A arquitetura de software é a maneira como está estruturado o sistema,

ou seja, quais os componentes estão presentes e as relações entre esses

componentes (AHMED & UMRYSH, 2002).

Através do modelo de arquitetura o desenvolvedor visualiza com mais

facilidade o funcionamento do sistema, como serão dispostos os seus componentes,

facilitando, assim, o entendimento e a manutenção do mesmo. Por isso é muito

importante que a arquitetura seja bem definida para que o sistema atenda todas as

necessidades definidas nos requisitos de forma bem estruturada.

É um grande desafio construir uma aplicação bem estruturada e de

fácil manutenção. Portanto no desenvolvimento do sistema do Edifício Porto Seguro

foi utilizada a linguagem de programação Java, aplicando-se a programação

orientada a objetos além do uso da arquitetura em três camadas MVC (Model, View,

Controller), plataforma J2EE, através do Eclipse e com os framewoks Struts e

Hibernate.

4.1. JAVA

É uma linguagem de programação de alto nível orientada a objetos

desenvolvida por uma equipe comandada por James Gosling na Sun Microsystens

na década de 90.

UNIMIN

AS

89

Essa linguagem foi projetada para ser pequena, simples e portável a

todas as plataformas e sistemas operacionais e, ainda, integrada à Internet, Java,

também, é uma excelente linguagem para desenvolvimento de aplicações em geral

(APOSTILA, 2009). Por se tratar de uma linguagem orientada a objeto, é necessário

o conhecimento desse paradigma para usá-la adequadamente. É compilada para

bytecode que é executado pela JVM (Java Virtual Machine) responsável por

administrar a memória e possui um coletor de lixo automático. O compilador e a JVM

estão disponíveis no JDK (Java Development Kit) kit de desenvolvimento Java.

De acordo com Wikipedia (2009a):

Java ainda é um standard de fato, que é controlada através da JCP Java Community Process. Em 13 de Novembro de 2006, a Sun lançou a maior parte do Java como Software Livre sob os termos da GNU General Public License (GPL). Em 8 de Maio de 2007 a Sun finalizou o processo, tornando praticamente todo o código Java como software de código aberto, menos uma pequena porção da qual a Sun não possui copyright.

4.2. ARQUITETURA MVC

O aumento do uso de aplicações distribuídas provê mudanças nos

projetos de software. Sendo assim no sistema do Edifício Porto Seguro foi utilizada a

arquitetura MVC que é um modelo de aplicação em três camadas, nesse modelo as

responsabilidades ficam divididas.

A arquitetura MVC (Model-View-Controller) separa em camadas a

aplicação, mas não deixando de integrá-las. Segundo Alur, Crupi e Malks (2004,

p.102):

Uma camada equivale a um dos particionamentos lógicos dos diversos aspectos tratados em um sistema. A cada camada é atribuída sua responsabilidade distinta, ou única, no sistema. Visualizamos cada camada como separadas logicamente entre si. Cada camada não está estritamente acoplada com a camada adjacente.

Sendo assim, as camadas trabalham juntas e a manutenção do código

é facilitada. Este modelo descreve a organização de uma aplicação em três

módulos:

- Model (Modelo): compreende o modelo de aplicação, contendo a

representação de dados e de lógica de negócios, onde ficam as classes de

persistência, business object, entidades e DAO (Data Access Objetct);

- View (Apresentação): trata aspectos relacionados à apresentação e

formulários entrada de dados de usuário que são as páginas de visualização

JSP (Java Server Pages);

UNIMIN

AS

90

- Controller (Controle): é responsável por despachar requisições e controlar

os seus fluxos, é onde é implementado o Front Controller através do

framewok Struts na classe action e no arquivo struts.xml.

Com o emprego do modelo MVC foi possível centralizar a lógica de

despachar requisições em uma classe action, simplificando a implementação do

controle de segurança e acesso ao sistema.

Para facilitar o uso do Modelo MVC, foi utilizado o framework Struts,

cujo código aberto fornece componentes de controle, e Hibernate que é responsável

pelo mapeamento objeto relacional com o banco de dados. A figura 29 apresenta o

modelo dessa arquitetura:

Figura 29 – Modelo Arquitetura MVC.

4.3. PADRÕES DE PROJETO

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

problemas recorrentes no desenvolvimento de aplicativos. Representam um

conjunto de descrições de problemas que são encontrados durante o processo do

desenvolvimento das aplicações com as suas respectivas soluções para esses

problemas. (ALUR, CRUPI & MALKS, 2004).

A utilização de padrões em softwares popularizou-se com o livro

Design Patterns: Elements of Reusable Object-Oriented Software cujos autores são

conhecidos como a Gangue dos Quatro (Gang of Four - GoF). Trata-se de um

UNIMIN

AS

91

catálogo com desenhos de padrões que podem ser agregados ao software

(MARTINS, 2006).

Os padrões de projeto são responsáveis por apresentar como será o

funcionamento entre os componentes do sistema, definindo-se através do padrão

quais são as responsabilidades e como se relacionam as entidades do projeto.

A definição de como será o funcionamento entre os componentes do

sistema, ao se considerar as responsabilidades e o relacionamento entre as

entidades do projeto é dada pelos padrões de projeto. No software em questão

foram empregados os seguintes padrões: Business Object, Data Access Object e

Front Controller implementado pelo framework Struts.

4.3.1. DAO

O DAO é utilizado para persistência de objetos Java fazendo com que

o código de acesso aos dados fique separado da lógica de negócios.

Esse padrão abstrai e encapsula o acesso ao armazenamento

persistente gerenciando a conexão com o banco de dados para armazenar e

consultar dados.

Geralmente se tornam objetos leves porque são implementados como objetos sem

informações de estado e também não armazenam em cachê os resultados de

nenhuma execução de consulta. Com o uso desse padrão os detalhes de

implementação do banco de dados ficam ocultos, por isso pode haver alteração de

banco de dados sem que implique em grandes mudanças na estrutura do sistema.

(ALUR, CRUPI & MALKS, 2004).

Na construção de software com utilização de mapeamento objeto

relacional e DAO, a linguagem do banco de dados torna-se transparente para o

desenvolvedor, pois operações do banco são assumidas pelo framework. Assim,

toda a manipulação de dados é feita através dos objetos instanciados, o que propicia

maior facilidade no caso de necessidade de troca do banco de dados. Esse padrão

será descrito com mais detalhes no capítulo 6.

4.3.2. Business Object

São objetos Java que contêm dados de negócios, ou seja, um objeto

Java se comunica com o DAO o padrão eleito para fazer a persistência com o banco

UNIMIN

AS

92

de dados. Esse padrão permite que a lógica de negócios fique separada da lógica

de persistência, usando-se um objeto. A figura 30 mostra o código da classe

PessoaBO.

package br.uniminas.bo;

import java.util.List;

import br.uniminas.entidades.Pessoa;

import br.uniminas.persistencia.PessoaDAO;

import br.uniminas.persistencia.PessoaHibernateDAO;

public class PessoaBO {

private PessoaDAO dao;

public PessoaBO() {

this.dao = new PessoaHibernateDAO();}

public List getAllPessoas() {

return dao.getAllPessoas();}

public void deletePessoa(String string) {

dao.delete(string);}

public Pessoa getPessoa(String string) {

return dao.getPessoa(string); }

public void insertPessoa(Pessoa pes) {

dao.insert(pes);}

}

Figura 30 – Classe PessoaBO.

Na classe pessoaBO é criado um objeto do tipo PessoaDAO e a partir

desse objeto são chamados métodos que fazem operações como inserir, pesquisar

e deletar que são métodos da classe DAO responsável pela persistência no banco

de dados.

Portanto o business object mantém os dados de negócio e implementa

comportamentos comuns a toda aplicação, descritos nos métodos da classe

PessoaBO.

4.3.3. Front Controller

É um padrão onde a lógica de controle fica centralizada em um ponto

único de entrada, o que permite o gerenciamento das atividades de tratamento das

solicitações.

Com a utilização do Front Controller é possível a reutilização do

código, ou seja, não há necessidade de repetição da lógica de controle a mesma

lógica pode ser usada para várias solicitações.

UNIMIN

AS

93

Portanto, em um sistema, o padrão Front Controller é o primeiro

contato, responsável por tratar as solicitações. A partir daí serão delegadas funções

para que seja executado o gerenciamento de ação e visualização.

4.3.4. Application Controller

O Application Controller é um padrão utilizado para centralizar a

recuperação e chamada dos componentes de solicitação que podem ser comandos

ou páginas de visualização.

Esse padrão é responsável pelo gerenciamento da ação e

visualização, onde o gerenciamento da ação está relacionado às rotas que para

atendimento de uma solicitação e o gerenciamento de visualização, cuja função é

localizar e distribuir a visualização solicitada.

Tanto o padrão Front Controller como o Application Controller são

implementados pelo framework Struts.

4.4. TECNOLOGIAS UTILIZADAS

4.4.1. Servlet

Servlet é uma classe Java que acessa uma API com serviços

específicos do protocolo http. Ele recebe uma requisição e apresenta uma resposta

em seguida. Toda vez que recebe uma requisição é iniciado um método chamado

service().

De acordo com Dumoulin, Franciscus e Winterfeldt (2004, p.9):

Um servlet se parece e se comporta como um servidor web miniatura. Ele recebe uma solicitação e apresenta uma resposta. Mas, diferente dos servidores web convencionais, a interface de programação da aplicação (API) do servlet é designada especificamente para ajudar os desenvolvedores Java a criarem aplicações dinâmicas.

No ciclo de vida do servlet na primeira invocação o método init() é

executado quando o servlet é carregado, existem os métodos de serviço que são

chamados pelo web server como service(), doGet(), doPost(), dentre outros. O

método destroy é chamado antes de encerrar a requisição ao servlet. A figura 31 a

seguir mostra o ciclo de vida de um servlet.

UNIMIN

AS

94

Figura 31 – Ciclo de vida do servlet. Adaptado de Angoti (2009a).

4.4.2. Páginas JSP

Java Server Pages (JSP) é uma tecnologia para desenvolvimento de

aplicações que permite a captura de informações através de formulários. Pode ser

facilmente codificado, facilitando o desenvolvimento e também manutenção de uma

aplicação. Quando uma página JSP é requisitada pelo usuário no browser, esta

página é executada pelo servidor, e, então, é gerada uma página HTML, através de

do processo de renderização, e em seguida, essa página é enviada ao browser do

usuário. As páginas JSP contêm código HTML comum e se diferenciam pelo uso

das tags que representam instruções Java.

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

consultarPessoaForm.jsp.

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

<%@ taglib prefix="s" uri="/struts-tags"%>

<html>

<head>

<link href="<s:url value="/css/main2.css"/>" rel="stylesheet"

type="text/css" />

</head>

<body background="/condominio/imagens/fundook.jpg">

<center><s:if test="pessoa==null || pessoa.P_cpf == null">

UNIMIN

AS

95

<br>

<br>

<br>

<br>

<div id="menu">

<ul>

<li><a href="principal.action">Principal</a></li>

<li><a href="getAllPessoas.action">Listar Cadastros</a></li>

</ul>

</div>

<br>

<br>

<br>

<br>

<br>

<h1><s:text name="Pesquisar Pessoa" /></h1>

</s:if>

<s:form action="consultarPessoa">

<table align="center" class="borderAll">

<tr>

<td class="tdLabel"><s:text name="label.P_cpf" /></td>

<td><s:textfield name="cpf" size="11" /></td>

</tr>

</table>

<br />

<table>

<tr>

<td><s:submit action="consultarPessoa"

key="button.label.submit2" cssClass="butStnd" /></td>

<td><s:reset key="button.label.cancel" cssClass="butStnd" /></td>

<tr>

</table>

</s:form></center>

</body>

</html>

Figura 32 – Código da página consultarPessoaForm.jsp.

Assim, a execução da função consultar pessoa que foi apresentado

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

pesquisarPessoa.jsp (Figura 33).

UNIMIN

AS

96

Figura 33 – Página pesquisarPessoa.jsp

4.4.3. JDBC

Java Database Conectivity (JDBC) é uma API da linguagem Java que

permite o acesso ao sistema de gerenciamento de banco de dados (SGBD) através

de comandos SQL (Structured Query Language).

Essa API está contida no pacote java.sql, com a sua utilização não há

necessidade do uso de um banco específico, ou seja, o sistema desenvolvido fica

independente acessando qualquer banco de dados (TOOD & SZOLKOWSK, 2003).

No sistema do Edifício Porto Seguro foi utilizado o JDBC juntamente

com a utilização do framewok Hibernate para fazer o mapeamento objeto relacional

com o banco de dados através do DAO (Data Access Object).

4.5. J2EE

J2EE (Java Enterprise Edition) é um padrão de desenvolvimento que

contém especificações sobre implementações de softwares desenvolvidos utilizando

a linguagem de programação Java. É voltado para o desenvolvimento de aplicativos

multicamadas baseando-se em componentes que são executados em um servidor

de aplicação (DIAS e BORBA, 2002).

No J2EE estão contidas API utilizadas na implementação do sistema

do Edifício Porto Seguro que são servlets, JSP (Java Server Pages) e JDBC (Java

Database Connectivity).

UNIMIN

AS

97

As aplicações que utilizam o padrão J2EE seguem o modelo

arquitetural em camadas, onde em cada camada está atribuída uma

responsabilidade diferente. Como se pode notar na figura 34 que mostra a divisão

em camadas.

Figura 34 – Modelo em camadas. Adaptado de Alur, Crupi e Malks (2004)

Na camada de apresentação encontra-se a lógica de apresentação dos

elementos exibidos ao usuário. Essa camada intercepta as solicitações do usuário e

faz o controle do que será exibido como resposta às requisições. Estão nessa

camada as páginas JSP e os servlets, que embora não sejam a interface

propriamente dita são responsáveis pela criação destas. Também, está presente

nessa camada o Front Controller, implementado pelo framework Struts, que é

responsável por controlar e redirecionar as requisições feitas pelo usuário e delegar

as ações para cada requisição.

Já, na camada de negócios estão presentes os dados e a lógica de

negócios. Ela foi implementada com a utilização de Business Object que tem por

função separar os dados e a lógica de negócios através de um objeto Java.

Por fim, a camada de integração é responsável por fazer a

comunicação com o SGBD (Sistema de gerenciamento de banco de dados). Nessa

camada foi utilizado o DAO para abstrair o acesso ao banco de dados através do

mapeamento objeto relacional.

4.6. TOMCAT

O Tomcat 5.5 é um container servlet da Apache Software Foundation

que foi utilizado como servidor web no projeto do software do Edifício Porto Seguro.

Ele implementa as especificações servlet e JSP.

Com o uso do Tomcat foi possível obter algumas vantagens dentre elas

se destacam:

UNIMIN

AS

98

- Otimização de performance;

- Otimização e redução do coletor de lixo;

- Melhoria no tratamento de taglibs;

- Gerenciamento da aplicação e do servidor.

(ANGOTI JR, 2009c).

4.7. IMPLEMENTAÇÃO

4.7.1. Struts

É um framework mantido pela Apache Software Foundation além de

outros projetos já criados tais como o Tomcat. O código inicial do Struts foi

desenvolvido entre o ano de 2000 e 2001 onde mais de 30 desenvolvedores

contribuíram para a sua criação (DUMOULIN, FRANCISCUS, WINTERFELDT,

2004).

O Struts é responsável por implementar o Front Controller que faz a

centralização da lógica de controle, promovendo também reutilização de código

porque não será necessário código de controle em várias páginas de visualização.

As responsabilidades ficam bem definidas facilitando a manutenção. Na figura 35 é

possível ver o funcionamento do Front Controler que atua na camada de

apresentação.

Figura 35 – Front Controller Adaptado de Angoti (2009b)

UNIMIN

AS

99

O controlador é o ponto central de todas as requisições feitas pelo

cliente e a partir dele que vai ser definida qual página view que vai ser exibida. O

Command Helper mostrado na figura acima representa comandos ou métodos que

serão executados de acordo com o nome da ação definida.

No Sistema para Gestão de Condomínio o Command Helper é

representado pelas classes action que possuem métodos que são executados de

acordo com a requisição do cliente.

Para o correto funcionamento do framework Struts é criado um arquivo

chamado struts.xml onde são feitos os mapeamento das ações. A figura 36

apresenta um trecho do código desse arquivo.

<!DOCTYPE struts PUBLIC "-//Apache Software

Foundation//DTD Struts Configuration 2.0//EN"

"http://struts.apache.org/dtds/struts-2.0.dtd">

<struts>

<package name="default" extends="struts-default">



...

<action name="consultarUnidade" method="consultaUnidade"

class="br.uniminas.action.PesquisarAction">

<result name="success">/page/unidade.jsp</result>

<result name="erro">/page/erro.jsp</result>

</action>

...

</package>

</struts>

Figura 36 – Arquivo struts.xml.

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

classe utilizada e do método. O resultado também é mapeado, no caso da ação

consultarUnidade mostrada na figura 8 caso o resultado seja success será exibida a

página unidade.jsp. Porém, se o resultados for erro a página a ser mostrada será

erro.jsp. O resultado dessa ação está definido no código do método consultaUnidade

da classe PesquisarAction (Figura 37).

UNIMIN

AS

100

...

public String consultaUnidade() {

unidade = uniService.getUnidade(numero);

if (unidade != null) {

return "success";

} else {

addActionError("Unidade não existe!");

return "erro";

}

}

...

Figura 37 – Método consultaUnidade.

Assim, o Front Controller implementado através do Struts faz o controle

das ações e resultados que serão exibidos através do direcionamento das ações de

acordo com a solicitação feita pelo usuário.

4.7.2. Diagrama de Pacotes

Os diagramas de pacotes do sistema foram gerados pelo Omondo

Eclipse UML que é um plugin que auxilia a geração de diagramas UML. Foi utilizado

o processo de engenharia reversa para geração desses diagramas, onde a partir do

código fonte foi possível gera-los.

O diagrama de pacotes exibe a estrutura de classes e pacotes de como

do sistema desenvolvido. A figura 38 mostra todos os pacotes que foram criados no

sistema.

Figura 38 – Diagrama de pacotes.

UNIMIN

AS

101

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

que serão manipulados pela aplicação, as classes desse pacote são:

UsuárioEntidade, LoginCO, Pessoa, Unidade e Histórico(Figura 39).

Figura 39 – Classes do pacote entidades.

No pacote bo estão as classes de negócio da aplicação, ou seja,

através de métodos que estão contidos nas classes do tipo BO são passados os

objetos de entidades para que sejam executadas as operações pelas classes DAO

(Figura 40).

Figura 40 – Classes do pacote bo.

Já, no pacote persistência estão as interfaces PessoaDAO,

UnidadeDAO, HistoricoDAO, essas interfaces contêm os mesmo métodos que são

implementados nas classes PessoaHibernateDAO, UnidadeHibernateDAO e

Histórico HibernateDAO e também a classe LoginDAO que implementam as

UNIMIN

AS

102

operações que serão executadas no banco de dados através do framework

hibernate, já a classe HibernateUtil é criada pelo framework hibernate (Figura 41)

Figura 41 – Classes do pacote persistência.

E finalmente, no pacote action estão as classes Java que contêm

métodos que são mapeados no struts.xml para realizar determinadas ações. As

classes são: Cadastrar PessoaAction, PesquisarAction e Login2 (Figura 42).

Figura 42 – Classes do pacote action.

UNIMIN

AS

103

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

dispostas as classes da aplicação, o que deixa o código mais organizado e auxilia

no caso de novas implementações ou alterações no sistema.

4.7.3. Implementação do Caso de Uso Cadastrar Dados

Para apresentar o funcionamento do modelo em camadas e visualizar

a interação entre os padrões utilizados no sistema do Edifício Porto Seguro, será

usado como exemplo o Caso de Uso 02 Cadastrar Dados que utiliza as entidades

pessoa, unidade e histórico. Essa demonstração parte das premissas de que a

pessoa em questão não foi cadastrada anteriormente e que não há histórico com

pendências para a unidade. A figura 43 mostra a tela principal do sistema do Edifício

Porto Seguro onde é selecionada a opção Cadastrar Dados.

Figura 43 – Página Principal.

UNIMIN

AS

104

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

que foi mapeada no arquivo struts.xml com o nome de setUpForInsertOrUpdate, o

trecho de código do mapeamento dessa action é mostrado a seguir na figura 44.

<action name="setUpForInsertOrUpdate"

method="setUpForInsertOrUpdate"

class="br.uniminas.action.CadastrarPessoaAction">

<result name="success">/page/cadastroPessoaForm.jsp</result>

</action>

Figura 44 – Action setUpForInsertOrUpdate mapeada no arquivo struts.xml.

A ação nomeada como setUpForInsertOrUpdate no arquivo struts.xml

invoca o método setUpForInsertOrUpdate() que está na classe

CadastrarPessoaAction do pacote action, como apresentado no trecho de código

abaixo (Figura 45).

public class CadastrarPessoaAction {

... public String setUpForInsertOrUpdate() {

prep();

return "success";

}

...

Figura 45 – Método setUpForInsertOrUpdate() implementado na classe CadastrarPessoaAction.

Nessa classe existe um método prep() que preenche um componente

do tipo combo box na página onde serão exibidos os números das unidades

existentes no condomínio e retorna success que foi mapeado no arquivo struts.xml

para exibir a página de cadastro de dados, como mostrado na figura 46.

Figura 46 – Tela de Cadastro de Dados.

UNIMIN

AS

105

Depois de preenchidos os dados e pressionada a tecla cadastrar é

executada uma action mapeada no arquivo struts.xml com o nome de

insertOrUpdate, a seguir é mostrado o trecho do arquivo struts.xml (Figura 47).

<action name="insertOrUpdate" method="insertOrUpdate"

class="br.uniminas.action.CadastrarPessoaAction">

<result name="success">/page/sucesso.jsp</result>


</action>

Figura 47 – Action InsertOrUpdate implementado no arquivo struts.xml.

O método insertOrUpdate() está na classe CadastrarPessoaAction que

é uma classe Java contendo os objetos e métodos relacionados ao cadastro de

dados, além dos métodos das validações feitas pelo sistema. A seguir é mostrado o

código do método insertOrUpdate(), como mostra a figura 48.

public class CadastrarPessoaAction { ... public String insertOrUpdate() { if (!validationSuccessful()) {

return "erro";

} else {

if (prop != null && prop.equals("aquisicao")) { gravaPropAquisicao();

}

if (prop != null && prop.equals("venda")) {

if (!validaDataVenProp()){

return "erro";}

else{

gravaProVenda();} }

if (mor != null && mor.equals("entrada")) {

if (jaMorador()==true){

return "erro";

}

if(jaMorador()==false){

gravaMorEnt();

}

}

if (mor != null && mor.equals("saida")) { if (!validaDataSaiMor())

return "erro";

else

gravaMorSai();

}

return "success";

}

} ...

Figura 48 – Método InsertOrUpdate implementado na classe CadastrarPessoaAction.

UNIMIN

AS

106

Primeiramente é feita a verificação dos dados inseridos no formulário

através do método validationSuccessfull() que está na classe

CadastrarPessoaAction, que valida os campos preenchidos no formulário. Se não

houver a validação, uma página de erro é retornada. Caso a validação seja positiva,

será verificada, então, as opções selecionadas através de componente do tipo radio

button, que se encontra na página de cadastro de dados. As opções disponíveis são

proprietário definindo em seguida se aquisição ou venda e, ainda, morador

acompanhado de entrada ou saída de um apartamento.

Será apresentado o processo de cadastro de uma aquisição de um

apartamento, a condição que considera a opção aquisição selecionada. Nesse caso

é chamado o método gravaPropAquisicao(). Nesse método, estão envolvidas as

entidades pessoa; unidade e histórico e as variáveis pesAux e pessoa, que são do

tipo Pessoa e pesService é do tipo PessoaBO. A linha de código mostrada abaixo

permite verificar se já existe uma pessoa cadastrada com o CPF informado. Caso

exista, grava o objeto pessoa correspondente no objeto pesAux, senão grava valor

nulo nesse objeto (Figura 49).

public class CadastrarPessoaAction {

... public void gravaPropAquisicao() {

pesAux = pesService.getPessoa(pessoa.getP_cpf());

unidade = uniService.getUnidade(unidade.getU_numero());

histAux = histService.getHistorico(historico.getId());

... Figura 49 – Método gravaPropAquisicao() implementado na classe CadastrarPessoaAction.

Esse mesmo procedimento é feito também com os objetos unidade e

histAux que correspondem à objetos do tipo unidade e histórico respectivamente.

Em seguida, é verificado se a unidade já tem proprietário cadastrado, isso é feito

através do método getProprietário() que está na classe Unidade. Se houver

proprietário cadastrado, é retornada uma mensagem como pode ser visto no trecho

de código apresentado na figura 50.

UNIMIN

AS

107

public class CadastrarPessoaAction{

...

public void gravaPropAquisicao{

...

if ((pesAux != null || pesAux == null) && unidade.getProprietario() != null) {

addActionMessage("A unidade "+unidade.getU_numero()+"já tem proprietário\n CADASTRO NÃO EFETUADO!");

...

Figura 50 – Mensagem de erro gerada pelo método gravaPropAquisicao() implementado na classe CadastrarPessoaAction.

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

possuir proprietário, o registro de pessoa é gravado da seguinte forma, um objeto do

tipo PessoaBO chamado pesService já instanciado, passa através do método

insertPessoa(), que pertence a classe PessoaBO, o objeto pessoa criado, quando

submeteu-se os dados do formulário (Figura 51).


...


...

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).


private PessoaDAO dao;

public PessoaBO() {

this.dao = new PessoaHibernateDAO();

}

...

Figura 52 – Comando geração do objeto pessoaDAO declarado no construtor da classe PessoaBO.

UNIMIN

AS

108

Na classe PessoaBO o método insertPessoa() recebe um objeto do

tipo pessoa e passa esse objeto para a classe PessoaHibernateDAO, que contém o

método insert(), como mostra a figura 53.


...

public void insertPessoa(Pessoa pes) {

dao.insert(pes);

}

...

Figura 53 – Chamada do método insert() através do método insertPessoa() implementado na classe PessoaBO.

Esse método recebe o objeto pessoa criado e executa a gravação dos

dados na tabela de pessoas do banco de dados (Figura 54).

public class PessoaHibernatedDAO {

...

public void insert(Pessoa pes) {

session = HibernateUtil.getSessionFactory().openSession();

Transaction tx = null;

try {

tx = session.beginTransaction();

session.save(pes);

tx.commit();

} catch (RuntimeException e) {

if (tx != null)

tx.rollback();

throw e;

} finally {

// session.close();

}

}

...

Figura 54 – Código do método insert() implementado pela classe PessoaHibernateDAO.

Depois de gravar a pessoa no método gravaPropAquisicao() a unidade

é atualizada, primeiro é atualizado o campo proprietário da unidade através do

método setProprietário(), que pertence a classe Unidade, e então um objeto do tipo

UnidadeBO chamado uniService passa através do método updateUnidade(), que

UNIMIN

AS

109

pertence a classe UnidadeBO, o objeto unidade que foi atualizado. O trecho de

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


...


...

// atualiza unidade

unidade.setProprietario(pessoa);

uniService.updateUnidade(unidade);

...

Figura 55 – Comandos do método gravaPropAquisicao() implementado pela classe CadastrarPessoaAction.

Na classe UnidadeBO é criado um objeto do tipo UnidadeDAO e no

construtor dessa classe o objeto do tipo unidadeDAO é instanciado como mostrado

na figura 56 a seguir.

public class UnidadeBO {

private UnidadeDAO dao;

public UnidadeBO() {

this.dao = new UnidadeHibernateDAO();

}

...

Figura 56 – Comandos de criação do objeto UnidadeHibernateDAO declarado no construtor da classe UnidadeBO.

O método updateUnidade() da classe UnidadeBO, recebe um objeto do

tipo unidade e passa esse objeto para a classe UnidadeHibernateDAO que contém

um método chamado updateUnidade() apresentado na figura 57.

public class UnidadeBO{

...

public void updateUnidade(Unidade u){

dao.updateUnidade(u);

}

...

Figura 57 – Comandos do método updateUnidade() implementado pela classe UnidadeBO.

UNIMIN

AS

110

O método updateUnidade() da classe, recebe o objeto do tipo unidade

e executa a atualização dos dados na tabela de unidades do banco de dados (Figura

58).

public class UnidadeHibernatedDAO {

...

public void updateUnidade(Unidade u) {



try {


session.update(u);

tx.commit();


if (tx != null)

tx.rollback();

throw e;

} finally {

}

}

...

Figura 58 – Código do método updateUnidade() implementado pela classe UnidadeHibernateDAO.

Por fim, é feita a gravação do histórico, através método

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

informado no formulário de cadastro. Se já existir, o objeto histórico será atualizado

pelos métodos setters da classe histórico e é repassado ao BO através de uma

objeto do tipo HistoricoBO chamada histService através do método

updateHistorico()., como ilustrado pela figura 59.


...


...

// se já existir um histórico com o código digitado, atualiza

if (histAux != null) {

historico.setH_proVenda(histAux.getH_proVenda());

historico.setH_proAquiscao(data);

historico.setH_morEntrada(histAux.getH_morEntrada());

historico.setH_morSaida(histAux.getH_morSaida());

historico.setNumero(unidade);

historico.setMorador(histAux.getMorador());

UNIMIN

AS

111

historico.setProprietario(unidade.getProprietario());

histService.updateHistorico(historico);

}

...

Figura 59 – Comando de persistência declarado no método gravaPropAquisicao() implementado na classe CadastrarPessoaAction, quando já há histórico da unidade.

Na classe HistoricoBO é criada uma variável do tipo HistoricoDAO e no

construtor dessa classe um objeto do tipo historicoDAO é instanciado como

mostrada na figura 60 a seguir.

public class HistoricoBO {

private HistoricoDAO dao;

public HistoricoBO() {

this.dao = new HistoricoHibernateDAO();

}

...

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

O método updateHistorico() recebe um objeto do tipo historico e passa

esse objeto para o DAO que contém um método chamado updateHistorico (Figura

61).

public class HistoricoBO{

...

public void updateHistorico(Historico hist){

dao.updateHistorico(hist);

}

...

Figura 61 – Comandos do método updateHistorico() implementado pela classe HistoricoBO.

O método updateHistorico() da classe HistoricoHibernateDAO recebe

o objeto do tipo histórico e executa a atualização dos dados na tabela de históricos

do banco de dados (Figura 62).

UNIMIN

AS

112

public class HistoricoHibernatedDAO {

...

public void updateHistorico(Historico hist) {



try {


session.update(hist);

tx.commit();


if (tx != null)

tx.rollback();

throw e;

} finally {

}

}

...

Figura 62 – Código do método updateHistorico() implementado pela classe HistoricoHibernateDAO.

Senão houver histórico criado anteriormente com o código informado

na tela de cadastro de dados um novo objeto do tipo histórico é criado e é repassado

ao BO através de uma variável do tipo HistoricoBO chamada histService pelo

método insertHistorico(), como mostra a figura 63.


...


...

// se não existir um histórico com o código digitado cria um novo

// registro de histórico no banco

else {

historico.setProprietario(pessoa);

historico.setNumero(unidade);

historico.setH_proAquiscao(data);

histService.insertHistorico(historico);

}

...

Figura 63 – Comando de persistência declarado no método gravaPropAquisicao() implementado na classe CadastrarPessoaAction, quando não há histórico da unidade.

UNIMIN

AS

113

O método insertHistorico(), que está na classe Histórico BO, recebe um

objeto do tipo historico e passa esse objeto para o DAO que contém um método

chamado insertHistorico(), como apresentado na figura 64.

public class HistoricoBO{

...

public void insertHistorico(Historico hist) {

dao.insert(hist);

}

...

Figura 64 – Comando declarado no método insertHistorico() implementado na classe HistoricoBO.

O método insertHistorico() da classe HistoricoHibernateDAO recebe o

objeto do tipo Histórico e executa a inserção dos dados na tabela de históricos do

banco com o mapeamento objeto relacional realizado através do framework

Hibernate (Figura 65).

public class HistoricoHibernatedDAO {

...

public void insert(Historico his) {



try {


session.save(his);

tx.commit();


if (tx != null)

tx.rollback();

throw e;

} finally {

// session.close();

}

}

...

Figura 65 – Código do método insert() implementado na classe HistoricoHibernateDAO.

A seguir está apresentado o código para a geração de uma mensagem

que será exibida ao usuário com confirmação de dados gravados. Essa mensagem

é criada através do método addActionMessage(), como apresentado na figura 66.

UNIMIN

AS

114


...


...

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 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>

...

Figura 68 – Action insertOrUpdate mapeada no arquivo struts.xml.

UNIMIN

AS

115

O caso de uso termina com a apresentação da página sucesso.jsp

(Figura 69), que contém a mensagem adicionada pelo método gravaPropAquisição()

através do método addActionMessage().

Figura 69 – Tela de confirmação de cadastro.

É importante ressaltar que se a pessoa em questão já estiver

cadastrada no sistema, a parte do cadastro de dados da pessoa não será realizada

pelo software. Serão executados, apenas, os comandos de atualização da unidade e

inserção ou atualização do histórico daquela unidade.

UNIMIN

AS

116

5. INTERFACE

Embora seja parte do software, a interface, para o usuário, confunde-se

com o sistema, muito embora seja apenas a parte do sistema que traduz as ações

do usuário em ativações das funcionalidades do sistema. É um componente

fundamental para o usuário que por vezes opta por um sistema considerando mais a

atratividade de sua interface do que as funcionalidades e desempenho propriamente

ditos. Assim, a qualidade da interface tem grande influência no sucesso comercial de

um software.

A interface deve ser invisível e intuitiva, pois o usuário deve concentrar-

se no trabalho que deverá executar. Para isso, uma interface deve ser amigável e

apresentar usabilidade. Para atingir esses objetivos, ela deverá apresentar as

seguintes características: ser de fácil uso; ser fácil de aprender o seu manuseio;

apresentar taxa mínima de erro; favorecer a recordação rápida; ser atrativa;

apresentar alta velocidade na execução de tarefas; gerar satisfação e retenção do

usuário com o tempo (ASCENIO, 1999).

De acordo com Ferreira (2009), a interface estabelece uma interação

do homem com o sistema através de um meio visual. O indivíduo recebe e interpreta

a informação visual com base no tamanho, forma, cor e outras características. Uma

especificação adequada da comunicação visual é o elemento chave para obtenção

de uma interface amigável. A cor é um componente que merece um estudo especial

quando se trata de comunicação, assim, a escolha das cores de uma interface deve

ser feita com cautela.

É natural a associação de cores a diversas situações ou elementos,

tanto que se faz uso de cores para indicar condições diversas: perigo, atenção,

qualidade de alimentos, acidez e alcalinidade e outras.

O significado das cores tem forte cunho cultural, como no ocidente, a

cor branca está associada à pureza, muito usada por noivas no dia de seu

casamento. Enquanto que, no oriente, é a cor da morte e dor. Para os orientais, o

vermelho é a cor convencional para o vestido de noiva. A idade, também, é fator

decisivo para a escolha das cores, as crianças mais novas são normalmente

atraídas por cores vibrantes. Desta forma, o design de interfaces deve se beneficiar

dessas informações, selecionando as cores atrativas ao perfil do usuário do sistema.

UNIMIN

AS

117

As cores têm indicações relacionadas ao significado cultural e também

às percepções visuais que determinam. Assim a escolha de cores para compor uma

interface gráfica deve considerar alguns fatores, como os descritos a seguir.

Branco

É a cor que possui a maior leveza ao atrair a atenção para um fundo

escuro, de modo que fornece a máxima legibilidade para um texto escuro, embora o

brilho possa causar problemas ao se olhar para ela por um período prolongado. Não

é recomendada para os cantos de interface e como estreita moldura de imagens,

valoriza a figura.

Preto

Atua como estimulante para as demais cores e se harmoniza bem com

todas elas. As superfícies pretas se tornam mais negras à medida que o nível de

iluminação aumenta. Contrastes simultâneos fazem com que um contorno preto

torne áreas coloridas mais claras e amplas. Torna-se mais legível quando em

contraste com fundos claros, apesar de ser necessário o uso de fontes em “negrito”

quando se usa texto negro em um fundo branco. Linhas pretas são eficientes ao se

separar áreas coloridas através de um aumento da fronteira de contraste. Para uma

boa reprodução de imagens, é desejável ter-se um preto sólido de modo a

estabelecer o limite da variação tonal.

Cinza

Reduz as conotações emocionais. Combina com todas as cores, que

apresentam seu colorido máximo quando contrastando com cinza escuro.

Das cores acromáticas (branco, preto e cinza) o cinza é uma boa cor

de fundo para a maioria das interfaces, pois minimiza o contraste entre a cor mais

escura e a mais clara da cena, amortecendo o choque visual ao se passar de uma

para outra. Embora seja adequada, não é frequentemente empregada em softwares

de sucesso.

As cores podem ser classificadas em cores quentes (amarelo, laranja e

vermelho) e cores frias (azul, turquesa e violeta). O verde e o magenta são

considerados cores marginais, pois seu caráter está na dependência das cores

adjacentes, se esta for uma cor fria, então aqueles aparentaram quentes. Da mesma

forma, se as cores do em torno forem quentes o verde e o magenta assumirão o

caráter de cores frias.

UNIMIN

AS

118

Para a criação de um ambiente harmonioso é necessário haver o

equilíbrio contrastando cores quentes com cores frias, de modo a torná-lo mais

agradável.

Vermelho

Apresenta o maior significado emocional a despeito da cultura,

provavelmente devido à sua associação com o sangue e o fogo, portanto com a

guerra.

É muito eficiente quando usada nas interfaces para sinalizar algum

perigo ou chamar a atenção, como por exemplo, bordas vermelhas de sinais de

advertência são rapidamente percebidas.

Amarelo

Apresenta grande qualidade acolhedora. Sua associação imediata com

o sol faz com que ela simbolize a vida e o calor. É um bom indicador de atividade,

sendo adequada para indicar a janela. Como cor de texto requer fundo preto ou azul

escuro.

Verde

A idéia de que a plantação significa uma certa estabilidade levou à

associação do verde com o sentimento de segurança.

Ambientes com um tom de verde claro promovam um estado de paz na

mente, enquanto que o verde em excesso resulta em uma aparência doentia. Está

indicada quando se deseja passar rapidamente uma informação, sendo também,

recomendada para informar que está tudo normal.

Azul

Sugere espaço e profundidade. É uma cor fria e suave, sendo a mais

tranquila de todas. Fornece um bom fundo para cores vívidas. Simboliza autoridade

e espiritualidade, sendo a cor mais amplamente usada nas bandeiras nacionais,

mostrando assim, o desejo de unidade e estabilidade.

É uma das três primárias dos terminais de vídeo. É difícil de ser

focalizada e de se obter um bom contraste. Assim, não deve nunca ser usado para

texto nem detalhes finos. Entretanto, é uma excelente cor para o fundo, dada

sensação gerada por ela, de expansão e profundidade.

Em relação aos significados subjetivos das cores, o quadro 17 ilustra

muito bem a associação das cores com elementos positivos e negativos.

UNIMIN

AS

119

Cor Positivas Negativas

Neve Paz Frio Palidez fúnebre

Pureza Leveza Hospital Rendição Branco

Inocência Limpeza Vulnerabilidade Esterilidade

Noite Estabilidade Medo Segredos

Carvão Formalidade Vazio Anonimato Preto

Poder Solidez Morte maldição

Vitória Força Sangue Perigo

Paixão Energia Guerra Raiva Vermelho

Amor Sexualidade Fogo Satã

Sol Ouro Covardia Risco

Verão Colheita Traição Doença Amarelo

Serenidade Inovação Ciúmes Loucura

Vegetação Fertilidade Decadência Ganância

Natureza Esperança Inexperiência Fuga à realidade Verde

Primavera Segurança Inveja Má Sorte

Céu Estabilidade Frio Obscenidade

Mar Paz Depressão Mistério Azul

Espiritualidade Unidade Melancolia Conservadorismo

Quadro 17 – Simbologia de cores.

5.1. DIAGRAMA DE NAVEGABILIDADE

O diagrama de estados de navegação indica quais são as janelas que

compõe o sistema e quais eventos permitem ao usuário navegar de uma para outra.

Permite observar a dinâmica da aplicação, uma vez que ilustra os caminhos

possíveis na interação do usuário com o sistema

A seguir, a figura 70 apresenta o diagrama de navegabilidade do

sistema.

UNIMINAS

120

Figura 70 – Diagrama de Navegabilidade.

UNIMIN

AS

121

A interface com o usuário foi definida através de Java Server Pages,

também conhecida por sua sigla JSP.

As páginas JSP que consistem em páginas HTML com elementos

especiais, que lhes conferem caráter dinâmico. Esses elementos podem tanto

realizar um processamento por si, como podem recuperar o resultado do

processamento realizado em um Servlet e apresentar esse conteúdo dinâmico junto

a página JSP.

Existe também um recurso adicional bastante interessante na utilização

de páginas JSP: a recompilação automática, que permite que alterações feitas no

código da página sejam automaticamente visíveis em sua apresentação.

Às páginas JSP associou-se a tecnologia Cascade Style Sheets – CSS

- linguagem de estilo, que provém a apresentação de documentos escritos em uma

linguagem de marcação, como o HyperText Markup Language – HTML. O principal

benefício é permitir a separação entre o formato e o conteúdo de um documento,

pois formatação não está incorporada ao documento. Os estilos ficam em uma

página separada ligada às páginas de código, de modo que para alterar a

apresentação das páginas de interface, basta proceder as mudanças na página

onde os estilos estão definidos, que as alterações serão percebidas de forma

idêntica nas demais páginas.

A seguir será simulado os comportamento do sistema, com a

nevegação entre as telas de interface

UNIMIN

AS

122

Figura 71 – Tela de Login.

Figura 72 – Tela de mensagem de erro no Login.

UNIMIN

AS

123

Figura 73 – Menu inicial.

Figura 74 – Tela de Cadastro de Dados.

UNIMIN

AS

124

Figura 75 – Tela com mensagem de erro de CPF.

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

UNIMIN

AS

125

Figura 77 – Tela com mensagem de sucesso ao cadastrar os dados.

Figura 78 – Tela que apresenta a lista das pessoas cadastradas.

UNIMIN

AS

126

Figura 79 – Tela para solicitar a pesquisa dos dados de uma pessoa.

Figura 80 – Tela que apresenta os dados da pessoa pesquisada.

UNIMIN

AS

127

Figura 81 – Tela para solicitar a pesquisa dos dados de uma unidade.

Figura 82 – Tela que apresenta os dados da unidade pesquisada.

UNIMIN

AS

128

6. PERSISTÊNCIA DE DADOS


A maioria dos aplicativos requer dados persistentes. A persistência é

um dos conceitos fundamentais em desenvolvimento de aplicativos. Se um sistema

de informação não preservasse os dados inseridos pelos usuários quando a

máquina anfitriã fosse desligada, o sistema seria de pequeno uso prático. Quando

falamos sobre persistência em Java, normalmente estamos falando sobre

armazenar dados em um bando de dados relacional, usando SQL (Structure Query

Language) (BAUER & KING, 2005).

A persistência de dados, na computação, refere-se ao armazenamento

não-volátil de dados, por exemplo em um dispositivo físico de armazenamento como

um disco rígido. De forma muito simples, Persistência de Dados nada mais é do que

armazenar dados em um banco de dados relacional.

Pode-se dizer que de maneira geral, o termo persistência é associado

a uma ação que consiste em manter em meio físico recuperável, como banco de

dados, arquivo, de modo a garantir a permanência das informações de um

determinado estado de um objeto lógico.

Na Orientação a Objetos, chama-se de "objetos persistentes" aqueles

que permanecem existindo mesmo após o término da execução do programa.

Dentras as alternativas existentes, foi-se trabalhado a persistência sob o controle de

um banco de dados, pois as aplicações requerem um serviço de banco de dados,

pois assim os dados desses objetos podem ser eternizados e recuperados.

Assim persistência de dados consiste no armazenamento confiável e

coerente das informações em um sistema de armazenamento de dados, a

persistência de objetos é o armazenamento consistente de objetos de uma aplicação

orientada a objeto para que estes objetos existam em diferentes execuções de

diferentes aplicações.

UNIMIN

AS

129

6.1. CONCEITOS DE BANCO DE DADOS

Os bancos de dados e os sistemas de bancos de dados são

componentes essenciais para a sociedade moderna, na medida em que os sistemas

de informação estão cada vez mais difundidos.

Essa tecnologia tem provocado impacto no crescimento do uso de

computadores, representando, um papel crítico nas áreas em que os computadores

são utilizados, incluindo negócios, comércio eletrônico, engenharia, medicina, direito,

educação e as ciências da informação, para criar apenas algumas delas. A palavra

banco de dados é tão comumente utilizada que, primeiro, devemos defini-la

(ELMASRI & NAVATHE, 2005).

De acordo com Elmasri e Navathe (2005, p. 4) “um banco de dados é

uma coleção de dados relacionais. Os dados sãos fatos que podem ser gravados e

que possuem um significado implícito”.

Um sistema de banco de dados é um sistema computadorizado de

manutenção de registros, dados. Desse maneira o banco de dados, por si só, pode

ser considerado como o equivalente eletrônico de um armário de arquivamento onde

os usuários do sistema podem realizar diversas operações (DATE, 2004):

• Busca de dados;

• Inserção de dados;

• Exclusão de dados;

• Alteração de dados;

• Remoção de dados;

Segundo Date (2005, p. 10) “um banco de dados é uma coleção de

dados persistentes, usado pelos sistemas de aplicações de uma determinada

empresa”.

Os dados armazenados em um banco de dados representam algum

aspecto específico do mundo real — um universo de discurso de onde os dados são

obtidos — e apresentam algum grau de coerência lógica entre seus componentes.

Portanto, uma coleção aleatória de dados não constitui um banco de dados.

Um sistema de banco de dados é constituído por um banco de dados e

por um sistema gerencia-dor de banco de dados, como mostrado na figura 83. Um

sistema de banco de dados é usualmente uma aplicação que serve de suporte a

UNIMIN

AS

130

outras aplicações, tais como folha de pagamento, controle de pessoal e informações

bancárias.

Os bancos de dados relacionais modernos fornecem uma

representação estruturada de dados persistentes, permitindo a classificação, busca

e agregação de dados. Os sistemas de gerenciamento de banco de dados (SGBD)

são responsáveis por gerenciar a concorrência e a integridade dos dados. São,

ainda, responsáveis por compartilhar dados entre os múltiplos usuários e os

múltiplos aplicativos. Um sistema de gerenciamento de banco de dados deve,

inclusive, fornecer segurança de alto nível de dados (BAUER & KING, 2005).

Dentre as vantagens da abordagem de banco de dados destacamos

(DATE, 2004):

• Armazenamento, organização e obtenção de dados estruturados.

• Compartilhamento dos dados.

• Redução de redundância.

• Inconsistência pode ser evitada.

• Fornecimento de suporte a transação.

• Manutenção da Integridade.

• Reforço da segurança.

• Requisitos contraditórios podem ser equilibrados.

• Imposição de padrões.

A figura 83 apresenta esquematicamente, a relação entre usuários,

aplicativo, SGBD e o banco de dados.

UNIMIN

AS

131

Figura 83 – Sistema simplificado de Banco de Dados. Adaptado de RICARTE. I. L. M (1998, p.2).

O banco do Sistema Gestão de Condomínio foi usado para oferecer um

armazenamento persistente aos objetos programas e estruturas de dados. Essa é

umas das principais justificativas para o sistema de banco de dados orientados a

objeto. As linguagens de programação têm uma estrutura de dados complexa, como

as definições de classes em Java.

6.2. MYSQL

O MySQL é um SGBD (Sistema de Gerenciamento de Banco de

Dados), que utiliza a linguagem SQL (Structured Query Language) como interface.

Um sistema gerenciador de banco de dados é o software que permite

criar, manter e manipular bancos de dados para diversas aplicações. A criação e

manutenção de bancos de dados são tarefas de uma pessoa ou grupo de pessoas,

normalmente referenciada como o administrador do banco de dados. A manipulação

do banco de dados, como atualizações e consultas, é realizada direta ou

indiretamente, através de programas aplicativos, pelos usuários do banco de dados.

O sistema gerenciador de banco de dados pode ser de propósito geral ou específico

para alguma aplicação.

UNIMIN

AS

132

Para o desenvolvimento do sistema em questão, escolheu-se o MySQL

devido a sua alta performance observada em aplicativos de missão critica, a fácil

operação e manutenção, a sua estabilidade e o baixo custo de aquisição .

Dentre as suas principais características destacamos:

� Funciona em diversas plataformas.

� API (Application Programming Interface) para C, C++, Eiffel, Java,

Perl, PHP, Python, Ruby e Tcl estão disponíveis.

� Suporte total a multi-threads usando threads diretamente no kernel.

Isto significa que se pode facilmente usar múltiplas CPU (Central

Processing Unit), se disponível.

� Fornece mecanismos de armazenamento transacional e não

transacional.

� É relativamente fácil se adicionar outro mecanismo de

armazenamento.

� Um sistema de alocação de memória muito rápido e baseado em

processo(thread).

� Joins muito rápidas usando uma multi-join de leitura única otimizada.

� Tabelas hash em memória que são usadas como tabelas temporárias.

� Funções SQL são implementadas por meio de uma biblioteca de

classes altamente otimizada e com o máximo de performance.

Geralmente não há nenhuma alocação de memória depois da

inicialização da pesquisa.

� Disponível como versão cliente/servidor ou embutida (ligada).

• Tipos de Coluna

� Aceita diversos tipos de campos: tipos inteiros de 1, 2, 3, 4 e 8 bytes

com e sem sinal, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB,

DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET e ENUM.

� Registros de tamanhos fixos ou variáveis.

• Comandos e Funções

� Completo suporte a operadores e funções nas partes SELECT e

WHERE das consultas.

UNIMIN

AS

133

� Suporte pleno às cláusulas SQL GROUP BY e ORDER BY. Suporte

para funções de agrupamento (COUNT(), COUNT(DISTINCT ...),

AVG(), STD(), SUM(), MAX() e MIN()).

� Suporte para LEFT OUTER JOIN e RIGHT OUTER JOIN com as

sintaxes SQL e ODBC.

� Alias em tabelas e colunas são disponíveis como definidos no padrão

SQL92.

� DELETE, INSERT, REPLACE, e UPDATE retornam o número de

linhas que foram alteradas. É possível retornar o número de linhas

com padrão coincidentes configurando um parâmetro quando estiver

conectando ao servidor.

� Você pode misturar tabelas de bancos de dados diferentes na mesma

pesquisa.

• Segurança

� Um sistema de privilégios e senhas que é muito flexível, seguro e que

permite verificação baseada em estações/máquinas. Senhas são

seguras porque todo o tráfico de senhas é criptografado quando você

se conecta ao servidor.

• Escalabilidade

• Conectividade

� Os clientes podem se conectar ao servidor MySQL usando sockets

TCP/IP (Transmission Control Protocol/Internet Protocol), em qualquer

plataforma. No sistema Windows na família NT (NT, 2000 ou XP), os

clientes podem se conectar usando named pipes. No sistema Unix, os

clientes podem se conectar usando arquivos sockets.

� A interface Connector/ODBC (Open-DataBase-Connectivity) fornece

ao MySQL suporte a progras clientes que usam conexão ODBC. Os

clientes podem ser executados no Windows ou Unix. O fonte do

Connector/ODBC está disponível. Todas as funções ODBC são

suportadas, assim como muitas outras (MySQL).

UNIMIN

AS

134

6.3. MODELAGEM DE BANCO DE DADOS

Modelagem de dados é a atividade de especificação das estruturas de

dados e regras de negócio necessárias para suportar uma área de negócios.

Representa um conjunto de requerimentos de informações de negócio. É uma parte

importante do desenho de um sistema de informação (Wikipédia, 2009b).

A abordagem que se dispensa ao assunto normalmente atende a três

perspectivas: Modelagem Conceitual, Modelagem Lógica e Modelagem Física. A

primeira é usada como representação de alto nível e considera exclusivamente o

ponto de vista do usuário criador do dado, a segunda já agrega alguns detalhes de

implementação e a terceira demonstra como os dados são fisicamente armazenados

(Wikipédia, 2009b).

6.3.1. Modelos

Um modelo de dados é uma definição abstrata, autônoma e lógica dos

objetos, operadores e outros elementos.

De acordo com a abordagem que utilizada e conforme ilustrado pela

figura 84, os modelos de dados normalmente são classificados da seguinte forma:

Figura 84 – Arquitetura de Modelo de Banco de Dados. Adaptado de RICARTE. I. L. M (1998; p.10).

UNIMIN

AS

135

• Modelo Conceitual:

o Representação dos conceitos e características observados no

ambiente;

o Ignorar particularidades de implementação.

A modelagem conceitual é uma fase muito importante no

planejamento de uma aplicação de um banco de dados bem-sucedida.

Geralmente, o termo aplicação de um banco de dados refere-se a um banco de

dados particular e aos programas a eles associados, que implementam consultas

e atualizações (ELMASRI & NAVATHE, 2005, p.35).

• Modelo Lógico:

o Regras de Derivação:

� Normalização das estruturas de dados

� Derivação de estruturas de agregação e generalização-

especialização

� Derivação de relacionamentos

o Regras de Restrição:

� Restrição de domínio

� Restrição de Integridade

� Restrição de Implementação

Figura 86 apresentada o modelo lógico implementado para Sistema de

Gestão de Condomínio.

UNIMIN

AS

136

Figura 85 – Modelo Lógico de Banco de Dados.

• Modelo Físico:

o Inclui a análise das características e recursos necessários para

armazenamento e manipulação das estruturas de dados (estrutura de

armazenamento, endereçamento, acesso e alocação física).

Figura 85 apresenta o modelo físico implementado para o Sistema de

Gestão de Condomínio.

UNIMIN

AS

137

Figura 86 – Modelo Físico de Banco de Dados.

O modelo para o sistema foi implementado atendendo as regras

abaixo:

• Normalização, evitando assim os problemas que podem provocar falhas no

projeto do banco de dados, bem como eliminar a mistura de assuntos e as

correspondentes redundâncias dos dados desnecessárias.

• Representação fiel do negócio

• Descrição sucinta das entidades, atributos e relacionamentos;

• Contendo os nomes de entidades e atributos, extensos e abreviados,

atribuídos de acordo com algum padrão adotado no projeto e formados por

termos previamente convencionados;

• Contemplando, para cada um dos atributos, o tipo de dado, tamanho e

opcionalidade.

UNIMIN

AS

138

O modelo de dados usado no projeto foi o conceitual de alto nível, o

Modelo Entidade–Relacionamento que é um tipo de modelo lógico baseado em

objetos.

Para entendimento do modelo apresentado para o sistema, segue

abaixo a definição de alguns conceitos:

• Entidade: é qualquer coisa, concreta ou abstrata, incluindo associações entre

entidades, abstraídos do mundo real e modelados em forma de tabela que

guardarão informações no banco de dados.

• Relacionamento: nada mais é do que uma associação entre estas entidades.

Segue abaixo tipos de relacionamento:

− Relação 1..1 - indica que as tabelas têm relação unívoca entre si. Você

escolhe qual tabela vai receber a chave estrangeira;

− Relação 1..n - a chave primária da tabela que tem o lado 1 vai para a

tabela do lado N. No lado N ela é chamada de chave estrangeira;

− Relação n..n - quando tabelas têm entre si relação n..n, é necessário criar

uma nova tabela com as chaves primárias das tabelas envolvidas, ficando

assim uma chave composta, ou seja, formada por diversos campos-chave

de outras tabelas. A relação então se reduz para uma relação 1..n, sendo

que o lado n ficará com a nova tabela criada.

• Atributo: corresponde a alguma propriedade de interesse que ajuda a

descrição de uma entidade.

As tabelas, entidades, relacionam-se umas as outras através de

chaves. Uma chave é um conjunto de um ou mais atributos que determinam a

unicidade de cada registro.

A unicidade dos registros, determinada por sua chave, também é

fundamental para a criação dos índices.

Temos dois tipos de chaves:

Chave primária: (PK - Primary Key) é a chave que identifica cada registro

dando-lhe unicidade. A chave primária nunca se repetirá.

UNIMIN

AS

139

Chave Estrangeira: (FK - Foreign Key) é a chave formada através de um

relacionamento com a chave primária de outra tabela. Define um

relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso a

chave primária seja composta na origem, a chave estrangeira também o será.

6.3.2. Compreendendo o Modelo

Nos modelos lógico e físico apresentados nas figuras 3 e 4, observa-se

a presença das seguintes entidades: TaxaCondominio, ContaMensal,

PagamentoMes, Pessoa, Historico e Unidade.

A entidade TaxaCondominio é composta pelos seguintes atributos:

TC_mesRef (PK), CM_id (FK), TC_valorTaxa, TC_dataGeracao,

TC_dataVencimento. A entidade TaxaCondominio é identificada pelo atributo

chave TC_mesRef. A entidade ContaMensal é composta pelos seguintes atributos:

CM_id (PK), CM_tipo, CM_valorConta, CM_mesreferencia, CM_dataVencimento. A

entidade ContaMensal é identificada pelo atributo CM_id. A entidade

LancamentoMes é composta pelos seguintes atributos: LM_id (PK), TC_mesRef

(FK), CM_id (FK), U_numero (FK), LM_data, LM_referencia, LM_tipo, LM_valor,

LM_multa, LM_valorTotal. A entidade LancamentoMes é identificada pelo atributo

chave LM_id. A entidade Unidade é composta pelos seguintes atributos: U_numero

(PK), morador (FK), proprietario (FK). A entidade Unidade é identificada pelo atributo

chave U_numero. A entidade Pessoa é composta pelos seguintes atributos: P_cpf

(PK), P_nome, P_telefone. A entidade Pessoa é identificada pelo atributo chave

P_cpf. A entidade Historico é composta pelos seguintes atributos: H_historico (PK),

morador (FK), proprietario (FK), U_numero, H_pro_Venda, H_pro_aquisicao,

H_mor_Saida, H_mor_Entrada. A entidade Historico é identificada pelo atributo

chave H_historico. A entidade Usuario é composta pelos seguintes atributos: id

(PK), nome, senha. A entidade Usuario é identificada pelo atributo chave id.

6.4. PADRÃO DE PROJETOS DAO

DAO (Data Access Object) é um padrão para persistência de dados

que permite separar regras de negócio das regras de acesso a banco de dados.

UNIMIN

AS

140

Numa aplicação que utilize a arquitetura MVC (Model, View, Controler), todas as

funcionalidades de bancos de dados, tais como obter as conexões, mapear objetos

Java para tipos de dados SQL ou executar comandos SQL, devem ser feitas por

classes de DAO.

Usando-se esse padrão a camada de negócios acessa os dados

persistidos sem ter conhecimento se os dados estão em um banco de dados

relacional ou um arquivo XML (eXtensible Markup Language). O padrão DAO

esconde os detalhes da execução da origem dos dados (SUN, 2009).

Utilizou-se o DAO para abstrair e encapsular todo o acesso à fonte de

dados. O DAO gerencia a conexão com a fonte de dados para obter e armazenar

dados (SUN, 2009).

A figura 87 apresenta a estrutura do padrão DAO. A classe

DataAccessObject encapsula o acesso aos dados, que por sua vez é mantido pela

classe DataSource que pode ser um arquivo XML, uma base de dados ou

algum serviço remoto, ou seja, a origem dos dados. A classe BusinessObject

representa a aplicação (também conhecida como cliente do padrão), que usa

um objeto DataAccessObject. Ao utilizar esse objeto DataAcessObject, o objeto

cliente recebe ou envia um objeto TransferObject. Esse objeto contém os dados a

serem enviados ou trazidos da origem dos dados, e normalmente referem-se aos

campos de um registro.

Figura 87 - Estrutura Padrão DAO. Adaptado de SUN, 2009.

Para o Sistema de Gestão de Condomínio, foram implementadas

classes DAO para acesso aos objetos através do Hibernate. Essas classes buscam

os dados do banco e os converte em objetos para serem usados pela aplicação.

UNIMIN

AS

141

Semelhantemente, deve saber como manipular os objetos, converter em instruções

SQL e enviar ao banco de dados.

6.5. FRAMEWORK HIBERNATE

O Hibernate é um framework de mapeamento objeto/relacional para

Java. Possui um conjunto de classes e interfaces e tem como objetivo disponibilizar

objetos para a função de armazenar, persistir os dados.

Tendo em vista que grande parte das aplicações desenvolvidas

mantém suas informações gravadas em um banco de dados relacional, o grande

problema é que, atualmente, as melhores linguagens de programação são

orientadas a objeto tornando complicado a integração entre esse tipo de banco de

dados e essas linguagens. Além disso, mesmo em linguagens estruturadas como

Java, trabalhar com banco de dados tornava-se uma tarefa árdua à medida que a

aplicação cresce. Um modelo de programação muito usado, mesmo em linguagens

tipicamente orientadas a objeto como Java, é misturar lógica de negócio com código

SQL. Caso o banco de dados de aplicação mude, seria necessário reescrever

praticamente toda a aplicação, para dar suporte ao novo banco.

Assim uma técnica bastante conhecida da orientação a objetos é o

encapsulamento, onde é possível esconder as regras dentro de objetos e definir

alguns métodos nesses objetos que o mundo externo poderá usar para ter acesso

ao resultado dos códigos. Essa idéia foi adaptada à programação com banco de

dados. Os métodos necessários ao acesso e manipulação do banco ficam

escondidos dentro de classes básicas. As outras partes da aplicação usam essas

classes e seus objetos, ou seja, a aplicação nunca terá acesso diretamente ao

nosso banco (LEMES, 2007).

O Hibernate permite o mapeamento dessas classes Java com tabelas

de banco de dados (e de objetos Java para tabelas de banco de dados) e também

possibilita pesquisas e retorno de dados, podendo reduzir, significativamente, o

tempo de desenvolvimento antes investido em controlar o relacionamento objeto-

relacional.

Uma das funcionalidades do Hibernate é a geração de código através

da engenharia reversa, que possibilita a implementação das classes Java de

UNIMIN

AS

142

entidade a partir da estrutura das tabelas criadas no Banco de Dados. Tendo sido

essa a maneira utilizada para iniciar-se a codificação do sistema em questão.

6.5.1. Características Hibernate

Modelo de programação natural: suporta desenvolvimento em

programação orientada a objeto (OO) natural; herança, polimorfismo, agregação e

também a Java Collections framework.

Suporte modelos objetos detalhados: oferece uma grande variedade

de mapeamentos para collections e objetos dependentes.

Sem código extra no momento de compilação dos bytecodes: não

existe código extra gerado na compilação dos códigos fontes para bytecode.

Alta escalabilidade: tem alta performance com sua arquitetura com 2

caches e pode ser utilizado em cluster.

Query language: soluciona ambos os lados, não somente como enviar

os dados para o banco de dados, como também como buscar os mesmos do banco

de dados.

Suporte a transações a “nível de aplicação”: suporta contextos de

persistência de longa duração, detach/reattach e executa lock otimista

automaticamente;

Free /Open source: é licenciado sobre a licença do tipo LGPL (Lesser

GNU Public License).

Suporte a API JCA: possui compatibilidade com a API Java JCA

garantindo que possa se conectar com banco de dados legados de forma

transparente.

6.5.2. Arquitetura do Hibernate

O Hibernate tem como objetivo controlar toda a persistência das

aplicações, diminuindo consideravelmente o tempo de desenvolvimento da

aplicação. Para atingir este objetivo, foi criado de forma a ficar entre as aplicações e

o banco de dados, traduzindo as chamadas ao banco de dados e, também,

controlando a persistência dos dados (Figura 88).

UNIMIN

AS

143

Figura 88 – Arquitetura Hibernate. Adaptado de Hibernate (2009).

• Hibernate.properties: configuração do Hibernate com relação ao SGBD (url,

senha, driver JDBC, etc. ).

• XML mapping - Annotation: associa cada classe a uma tabela no SGBD e

seus campos às colunas.

• Persistence Object: classe derivada da classe mapeada da aplicação, que

contém os métodos para acesso ao SGBD.

6.5.3. Mapeamento Objeto Relacional

De acordo com Bauer e King (2005, p. 31-32):

O mapeamento objeto relacional é a persistência automatizada de objetos dentro de um aplicativo Java para as tabelas em um banco de dados relacional, usando metadados que descrevem o mapeamento entre os objetos de banco de dados. O ORM (Object Role Modeling), essencialmente, trabalha transformando dados de modo reversível de uma representação em outra.

O uso do Hibernate torna a aplicação maleável a mais de um tipo de

banco de dados, isso depende, na maioria das vezes, apenas de poucos minutos de

uma reconfiguração básica do framework. Ele também deixa transparentes as

operações básicas de inserção, recuperação, atualização e remoção de dados.

UNIMIN

AS

144

Contudo o principal ponto de destaque está no paradigma de orientação a objetos

para banco de dados, tornado a modelagem e o trabalho de programação muito

mais elegante e compreensível.

A solução do ORM consiste nas quatro peças seguintes:

• Uma API para executar operações CRUD (Create, retrieve, updade, delete)

básicas em objetos de classes persistentes.

• A linguagem ou API para especificar consultas que referenciem classes e

propriedades de classes.

• Um recurso para especificar o mapeamento de metadados.

• Um técnica para a implementação do ORM para interagir com objetos

transacionais a fim de executar a verificação suja, buscas de associação

ociosas e outras funções de otimização.

Ainda, considerando Bauer e King (2005, p. 32) “o termo ORM é usado

para incluir qualquer camada de persistência onde o SQL seja gerado

automaticamente a partir de uma descrição baseada em metadados”.

O mapeamento é feito utilizando annotations, além disto, é direcionado

para as classes e não para as tabelas diretamente. Uma estrutura específica é

validada, o qual indica as propriedades a serem mapeadas em um objeto, permitindo

a inclusão de relacionamentos, de forma a simular as relações existentes em bancos

de dados relacionados. O Hibernate permite o mapeamento objeto-relacional de

dados permitindo persistência transparente para o desenvolvimento das aplicações

e, por conseqüência, diminuindo a possibilidade de erros nesta etapa e também

minimizando o trabalho manual da equipe do projeto no mapeamento destas

relações objeto-relacional. Para atingir este objetivo há a associação de

mapeamentos com classes persistentes criadas especificamente para cada objeto

mapeado.

As bibliotecas de Mapeamento Objeto Relacional fazem o mapeamento

de tabelas para classes. Como exemplo o banco de dados desenvolvido para o

sistema possui uma tabela chamada Historico, a aplicação possuirá, uma classe

denominada Historico. Essa classe definirá atributos, que serão usados para receber

e alterar os dados dos campos das tabelas, além de métodos para realizar as

operações.

UNIMIN

AS

145

Além disso, as classes que fazem essa interface com as tabelas do

banco de dados, provêem um conjunto de métodos de alto-nível que servem para

realizar operações básicas nas tabelas, como recuperar um registro através de um

id, dentre outros.

A figura 89 abaixo apresenta o arquivo onde os pacotes e as classes

anotadas são declaradas em um arquivo XML regular, geralmente o

"hibernate.cfg.xml". Além disso, as propriedades de acesso ao banco também foram

definidas nesse arquivo.

Nele é possível verificar a tag <session-factory> que delimita as

configurações para a sessão. Dentro dela existem as tags <property> cujos

atributos definem as configurações com o banco de dados e <mapping class> que

definem o mapeamento das classes que vão gerar os objetos para serem

persistidos. Todas essas informações ficam dentro da tag <Hibernate-configuration>.

Dentre os principais parâmetros destacamos:

• property name="hibernate.connection.url" é utilizado para informar os

parâmetros de localização do SGBD.

• property name="hibernate.dialect" representa o dialeto utilizado pelo SGBD

pois existem diferenças nas implementações dos diferentes fornecedores de

SGBDs.

• property name="hibernate.connection.driver_class" informa qual o driver

JDBC deve ser utilizado para a conexão.

• property name="hibernate.connection.username" informa qual o nome do

usuário do SGBD.

• property name="hibernate.connection.password" informa qual a senha de

conexão do SGBD.

A figura 89 traz o código do arquivo hibernate.cfg.xml usado na

aplicação.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE hibernate-configuration PUBLIC

"-//Hibernate/Hibernate Configuration DTD 3.0//EN"

"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>

<session-factory>

<property name="hibernate.connection.url">jdbc:mysql://localhost:3306/db_condominio</property>

UNIMIN

AS

146

<property name="hibernate.connection.username">root</property>

<property name="hibernate.connection.password"></property>

<property name="hibernate.current_session_context_class">thread</property>

<property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>

<property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>

<property name="show_sql">true</property>

<property name="connection.pool_size">1</property>



<mapping class="br.uniminas.entidades.UsuarioEntidade" />

<mapping class="br.uniminas.entidades.Unidade" />

<mapping class="br.uniminas.entidades.Pessoa" />

<mapping class="br.uniminas.entidades.Historico" />

</session-factory>

</hibernate-configuration>

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

Para o sistema desenvolvido, foi implementada uma classe estática

chamada de "HibernateUtil" (figura 90). A função dessa classe é encapsular a

criação e recuperação de sessões.

...

public class HibernateUtil {

private static final SessionFactory sessionFactory;

static {

try {

// Create the SessionFactory from hibernate.cfg.xml

sessionFactory = new AnnotationConfiguration().configure().buildSessionFactory();

} catch (Throwable ex) {

// Make sure you log the exception, as it might be swallowed

System.err.println("Initial SessionFactory creation failed." + ex);

throw new ExceptionInInitializerError(ex);

}

}

public static SessionFactory getSessionFactory() {

return sessionFactory;}

}

Figura 90 – Classe Hibernate Útil.

Na figura 91, é possível verificar o uso de um método da sessão

chamado createQuery, o qual permite usar uma HQL (Hibernate Query Language)

para recuperar registros do banco. HQL consiste em um diatelo SQL para o

Hibernate. É uma poderosa ferramenta de consulta que, apesar de se parecer com o

SQL, é totalmente orientado a objetos, incluindo os paradigmas de herança,

polimorfismo e encapsulamento.

UNIMIN

AS

147

Pode-se observar ainda que os métodos para manipulação dos dados,

como por exemplo, o método insert recebe um objeto Historico como parâmetro e o

mesmo é persistido no banco pelo Hibernate.

Compreendendo-se assim o que ocorreu. Primeiramente, a

recuperação da sessão (session) com uso da classe HibernateUtil. Nesse momento,

uma sessão (session) seria mais ou menos como uma unidade de trabalho, uma

transação com o banco de dados, para um melhor entendimento.

Depois, utilizamos a sessão para iniciar uma transação, salvar o objeto

no banco de dados e, por último, "commitar" a transação.

A sessão é iniciada sempre que o método getCurrentSession é

invocado e terminado através de um commit ou rollback.

...

public class HistoricoHibernateDAO implements HistoricoDAO {

private Historico hist;

private List<Historico> histList;

private Session session = HibernateUtil.getSessionFactory()

.getCurrentSession();

public Historico getHistorico(int i) {


try {

session.beginTransaction();

Query q = session.createQuery("from Historico where id=:Id_Historico");

q.setInteger("Id_Historico", i);

return (Historico) q.uniqueResult();

} finally {

// session.close();

}

}

public List consultaHistorico(String numero){


try {

session.beginTransaction();

Query q = (Query) session.createQuery("from Historico where numero=:U_numero").list();

q.setString("U_numero", numero);

histList=(List<Historico>) q;

return histList;

} finally {

// session.close();

}

}

public void insert(Historico his) {



try { tx = session.beginTransaction();

UNIMIN

AS

148

session.save(his);

tx.commit();


if (tx != null)

tx.rollback();

throw e;

} finally {

// session.close();

}

}

public void delete(String id) {




hist = (Historico) session.get(Historico.class, id);

session.delete(hist);

tx.commit();


if (tx != null)

tx.rollback();

throw e;

} finally {

}

}

public void updateHistorico(Historico hist) {




session.update(hist);

tx.commit();


if (tx != null)

tx.rollback();

throw e;

} finally {

}

}

}

Figura 91 – Classe de persistência HistoricoHibernateDAO.

6.6. MECANISMOS DE PERSISTÊNCIA

Como a maioria das ferramentas ORM, o Hibernate necessita de

metadados para determinar como deverá ser feita a transformação dos dados entre

classes e tabelas. Como opção, utilizamos um recurso, que veio com o JDK 5.0,

chamado de Annotation.

O mapeamento objeto relacional se estabelece através de anotações

(annottations) colocadas nas classes de entidade. Esse mapeamento determina a

UNIMIN

AS

149

correspondência entre as classes Java e as tabelas do banco de dados, de modo

que para cada classe de entidade haverá uma tabela. No processo de mapeamento

é estabelecida, ainda, a correspondência entre os atributos das classes e seus pares

nas respectivas tabelas. É a partir dessa identificação, que o Hibernate, framework

usado para fazer a persistência com o banco de dados, pode persistir no banco de

dados o objeto Java instanciado. Através das anotações é feita uma junção entre o

objeto Java criado e a tabela no banco

Assim os dados são persistidos não mais usando arquivos XML como

anteriormente, e sim com uso de annotations. Anotações são diretivas colocadas no

código Java para associar as classes a tabelas no SGBD, substituindo o arquivo

XML.

Para melhor uma compreensão, é possível visualizar na figura 92 a

classe de entidade Histórico, e as anotações usadas como mecanismos de

persistência.

...

@Entity

@Table(name = "historico")

public class Historico {

//@GeneratedValue(strategy=GenerationType.AUTO)

@Id

@Column(name = "Id_Historico", unique = true)

int id;

@Column(name = "H_proVenda", unique = true)

Date h_proVenda;

@Column(name = "H_proAquisicao", unique = true)

Date h_proAquiscao;

@Column(name = "H_morEntrada", unique = true)

Date h_morEntrada;

@Column(name = "H_morSaida", unique = true)

Date h_morSaida;

@ManyToOne

@JoinColumn(name = "U_numero", unique = true)

Unidade numero;

@ManyToOne

@JoinColumn(name = "morador", unique = true)

Pessoa morador;

@ManyToOne

@JoinColumn(name = "proprietario", unique = true)

Pessoa proprietario;

public Historico() {}

public Historico(Date hProVenda, Date hProAqui, Date morEntr,

Date morSaida, Unidade u, Pessoa mor, Pessoa prop) {

this.h_proVenda = hProVenda;

UNIMIN

AS

150

this.h_proAquiscao = hProAqui;

this.h_morEntrada = morEntr;

this.h_morSaida = morSaida;

this.numero = u;

this.morador = mor;

this.proprietario = prop;

}

...

Figura 92 – Classe de entidade Histórico.

Quanto à aplicabilidade das anotações implementadas segue:

@Entity: declara a classe como uma classe de entidade (ou uma classe

persistente). Id, todas as classes de entidade (entity classes) persistentes

precisarão de tal atributo se quisermos utilizar todos os recursos do Hibernate.

@Table: usada para definir qual tabela será usada para persistir os objetos dessa

classe. Se essa anotação não for usada, o Hibernate irá procurar por uma tabela

com o mesmo nome da classe.

@Id: declara qual campo, atributo da classe será usado como identificador. Neste

caso, foi definido o atributo "id".

@Column: usada para definir as propriedades dos atributos.

@ManyToOne: informa que existe um relacionamento de um para muitos.

@JoinColumn: é utilizada para informar que o nome da chave estrangeira

utilizada no relacionamento das entidades relacionais.

O Hibernate não somente fornece uma solução com todas funções que

satisfaçam frontalmente essas exigências, ele é também uma arquitetura flexível e

configurável. Ele foi o projetado com modularidade, conectibilidade, extensibilidade e

com a customização do usuário em mente (BAUER & KING, 2005). Isso torna a

interação com o banco de dados transparente, do ponto de vista da programação

Java. A principal vantagem é a mudança do paradigma de trabalho Estruturado para

o Orientado a Objeto, eliminado, assim, muito trabalho repetitivo e tedioso. A

desvantagem é a diminuição do desempenho, decorrente da existência de uma

camada intermediária entre o banco de dados e a aplicação, porém ela pode ser

diminuída utilizando configurações avançadas do Hibernate, por exemplo o trabalho

com cache.

UNIMIN

AS

151

7. CONCLUSÃO

O levantamento dos requisitos do sistema, a documentação dos casos

de uso e a elaboração do diagrama de classe e dos diagramas de seqüência

permitiram à equipe perceber melhor o desenho do sistema, facilitando, inclusive a

comunicação entre seus membros. Atender os preceitos técnicos da análise de

sistema possibilitou bom entendimento do problema e da aplicação antes de seu

desenvolvimento. Os diagramas de classe e de seqüência elaborados já em nível de

projeto foram considerados importantes documentos após o desenvolvimento do

sistema uma vez que serão a base para a manutenção e expansão do mesmo.

O uso da linguagem Java permitiu a implementação do software, pois

além de não apresentar custo, opera em qualquer sistema operacional. Essa

característica atendeu, logicamente, a uma das exigências do projeto: o software

deveria operar sobre o sistema operacional Windows XP, uma vez que o

equipamento do cliente possuía esta configuração. Além disso, a linguagem

orientada a objeto permitiu uma modelagem dentro da tendência atual, o que, de

acordo com a literatura, deverá facilitar as alterações e adequações necessárias

para a atualização e expansão do sistema.

A escolha da linguagem orientou a definição da ferramenta IDE

(Integrated Development Environment) de desenvolvimento, cuja escolha recaiu

sobre o Eclipse, que agregado aos frameworks Struts e Hibernate apresentou boa

produtividade, permitindo, também, simplificação do código. Observa-se, entretanto,

que durante o processo de desenvolvimento foi necessário usar mais de um

equipamento e sob esse aspecto, o Eclipse não se mostrou estável. Por diversas

vezes, as bibliotecas tiveram de ser reinseridas, pois não foram reconhecidas apesar

de estarem no projeto.

O uso do Hibernate facilitou a implementação das classes de entidade,

através da engenharia reversa, que embora seja um processo de muitos passos,

garante a correlação entre as classes e as tabelas do banco de dados. Observa-se,

ainda, que esse procedimento pode ser realizado escalonadamente, facilitando a

implementação por iterações, que muitas vezes se fazem necessárias, quando do

desenvolvimento de grandes projetos. As annottations realizaram com facilidade o

UNIMIN

AS

152

mapeamento objeto-relacional e o padrão de projeto DAO permitiu a independência

do banco de dados utilizado, fazendo a persistência dos dados de forma simples. O

MySQL apresentou boa performance, tendo sido adequado à aplicação.

O modelo MVC permitiu independência entre os vários elementos de

modo que as alterações de código que se fizeram necessárias tiveram pouco ou

nenhum impacto nos demais componentes. O padrão Business Object foi

responsável pela camada de negócio respondendo satisfatoriamente às

necessidades da aplicação, trazendo, ainda, a vantagem de ser de fácil

implementação.

Uma vez definido que seria uma aplicação Web, a coerência

determinou o seguimento dos padrões de projeto para J2EE (desing patterns J2EE).

Comprovou-se a importância dos padrões, que apresentam soluções claras para

determinados problemas. No caso se percebeu a necessidade de um controle

central da aplicação, como elemento organizador das requisições. Assim, o

controlador foi peça chave na aplicação, cujo desenvolvimento foi facilitado pelo

emprego do Struts, que implementa automaticamente o Front Controller, através do

mapeamento das ações no arquivo Struts.xml.

É importante reforçar que o uso dos frameworks facilitou bastante o

desenvolvimento dessa aplicação multicamadas, quer seja pela implementação dos

padrões Front Controller e Application Controller implementados pelo Struts, quer

seja pelo mapeamento objeto relacional que faz a interação com o banco de dados

propiciado pelo Hibernate. Estabeleceu-se, assim, uma seqüência lógica que em

conjunto com os preceitos da orientação a objetos, permitiram o desenvolvimento de

um sistema cuja manutenibilidade será bastante facilitada.

Ressalta-se, ainda que o Hibernate não somente fornece uma solução

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

flexível e configurável. Isso torna a interação com o banco de dados transparente, do

ponto de vista da programação Java. A literatura cita como desvantagem a

diminuição do desempenho, em função da existência de uma camada intermediária

entre o banco de dados e a aplicação, que pode ser diminuída utilizando

configurações avançadas do Hibernate, como o trabalho com cache.

O sistema foi parcialmente desenvolvido, dos quatorze casos de uso

levantados foram implementados seis. Como o número de condomínios está

UNIMIN

AS

153

crescendo e a relação entre a gerência e os condôminos tem evoluído, acredita-se

que seja importante a continuidade desse projeto. Aliado a isso, as características

do sistema e a documentação para apoiar a expansão do projeto está disponível, o

que facilitará a realização dessa tarefa.

UNIMIN

AS

154

REFERÊNCIAS BIBLIOGRÁFICAS

ABREU, Edriano. Baixa idade média. Disponível em: <http://www.saberhistoria.hpg.ig.com.br/nova_pagina_35.htm>. Acesso em: 7 mar 2009. AHMED, Khawar Zaman; UMRYS4H, Cary E. Desenvolvendo aplicações comerciais em Java com J2EE e UML. Rio de Janeiro: Ciência Moderna, 2002. 302 p. ALUR, Deepak; CRUPI, John; MALKS, Dan. Core J2EE Patterns: as melhores práticas e estratégias de design.Tradução de Altair Dias Caldas de Morais. Rio de Janeiro: Elsevier, 2004. 587 p. ANGOTI JR., Edson. Programação de Aplicações para Internet usando JSP/SERVLETS. Diponível em: <http://si.uniminas.br/~angoti/arquivos>. Acesso em: 04 jun. 2009a. ANGOTI JR., Edson. Padrões de Projeto JEE. Disponível em:<http://si.uniminas.br/~angoti/arquivos/PadroesProjetoJEE.pdf> Acesso em: 09 jun. 2009b. _______ Edson. Apache Tomcat. Disponível em :<http://si.uniminas.br/~angoti/arquivos/Tomcat.pdf> Acesso em: 16 jun. 2009c. APOSTILA DE Java. 42 p. Apostila. Disponível em <http://www.si.uniminas.br/~mauro/SIS07/ApostilaJava.pdf>. Acesso em 13 mai. 2009. ARAUJO, Vanessa L de. Regras de negócio. Disponível em: <http://sysreq.incubadora.fapesp.br/portal/down/apr/RegrasNegocio.pdf>. Acesso em 16 maio 2009. ASCENCIO, Ana Fernanda Gomes. Método Heurístico para Projetar e Analisar Interfaces Hipermídia Inteligentes. In: IV Semana Acadêmica do Programa de Pós-Graduação da Ciência da Computação, 1999, Porto Alegre. Anais da IV Semana Acadêmica do Programa de Pós-Graduação da Ciência da Computação, 1999. p. 195-198. Disponível em: <http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana99/anafernanda/anafernanda.html>. Acesso em: 17 maio 2009. BAUER, Christian; KING, Gavin. Hibernate em Ação. Tradução de Cláudio Rodrigues Pistille, Geane Girotto e Fábio Makoto. Rio de Janeiro: Ciência Moderna, 2005. 532p. Título original: Hibernate in Action. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML, guia do usuário. Rio de janeiro: Campus, 2000. 472 p.

UNIMIN

AS

155

BRASIL, Fundação Instituto Brasileiro de Geografia e Estatística. Dados históricos dos censos. Disponível em: <http://www.ibge.com.br/home/estatistica/populacao/censohistorico/1940_1996.shtm>. Acesso em: 7 mar 2009a. ________, Fundação Instituto Brasileiro de Geografia e Estatística. Disponível em: <http://www.ibge.com.br/home/>. Acesso em: 7 mar 2009b. ________, Fundação Instituto Brasileiro de Geografia e Estatística. Tendências demográficas: uma análise dos resultados da sinopse preliminar do censo demográfico 2000. Rio de Janeiro: IBGE, 2001. 63 p. _______. Lei 4.591 de 16 de dezembro de 1964. Dispõe sobre o condomínio em edificações e as incorporações imobiliárias. DATE, C. J. Introdução a Sistemas de Banco de Dados. Tradução de Daniel Vieira. Rio de Janeiro: Campus, 2004. 865p. Título original: An Introduction to Database Systems. DEBONI, José Eduardo Zindel. Modelagem orientada a objetos com a UML. São Paulo: Futura, 2003. 219 p. DUMOULIN, Cedric; FRANCISCUS, George; WINTERFELDT, David. Struts em ação. Tradução de Eveline Vieira Machado. Rio de Janeiro: Ciência Moderna, 2004. 604 p. ELMASRI, R; NAVATHE, Shamkant. B. Sistemas de Banco de Dados. Tradução de Marília Guimarães Pinheiro, Claudio Cesar Canhette, Glenda Cristina Valim Melo, Claudia Vicci Amadeu e Rinaldo Macedo de Morais. 4 ed. São Paulo: Person Addison Wesley, 2005. 724p. Título original: Fundamentals of Database Systems. FERREIRA, Simone Bacellar Leal ET all . Requisitos Não Funcionais para Interfaces com o Usuário - O Uso de Cores. In: IDEAS 1999 - Segunda Jornada iberoamericanas de Ingenieria de Requisitos y Ambientes de Software, 1999. Anais da Conferência IDEAS 99, 1999. Disponível em: <ftp://ftp.inf.puc-rio.br/pub/docs/techreports/97_28_ferreira.ps.gz>. Acesso em 17 maio 2009. FREUD, Sigmund. O mal estar na civilização. Rio de Janeiro: Imago. 2002. 116 p. HIBERNATE. Relational Persistence for Java and .NET. Disponível em: <http://www.hibernate.org> Acesso em: 14 abr. 2009. INTRODUCTION TO OMG's Unified Modeling Language™ (UML®). Acesso em: 10 maio 2009. Disponível em: <http://www.omg.org/gettingstarted/what_is_uml.htm>. DIAS, Klissiomara; BORBA, Paulo. Padrões de Projeto para Estruturação de Aplicações Distribuídas Enterpise JavaBeans. In: Second Latin American Conference on Pattern Languages Programming, 2002, Itaipava. SugarLoafPLoP 2002. São Carlos: ICMC - Universidade de São Paulo, 2002. p. 55-86. Disponível

UNIMIN

AS

156

em: <http://twiki.cin.ufpe.br/twiki/pub/SPG/GenteAreaPublications/PLOP02_dias.pdf>. Acesso em: 27 mai. 2009. LEMES, M. V. S; Introdução a Persistência de Dados com Hibernate e Annotation. Junho 2007. 19p (Mimeo.). Disponível em: <http://www.marvinlemos.net/download/arquivo/118/hibernate_annotation.pdf>. Acesso em: 3 jun. 2009. MARTINS, Júnior Machado. Utilizando o Padrão de Projeto Observable. Disponível em: <http://www.inf.unisinos.br/~barbosa/pipca/consipro1/a3.pdf>. Acesso em: 27 mai. 2009. MEIRELLES, W. V; PEDEVIRA, G; Hibernate: uma forma simples de trabalhar com persistência de dados em java. Novembro 2006. 17p. Universidade Federal da Grande Dourados. Disponível em: <http://www.unibratec.com.br/sbts/diretorio/NOVOHIB.pdf>. Acesso em: 3 jun. 2009. MIRANDA, Ângelo Tiago. Conseqüências e características das cidades. Disponível em: <http://educacao.uol.com.br/geografia/ult1701u57.jhtm>. . Acesso em: 7 mar 2009. MYSQL. The world's most popular open source. Disponível em: <http://www.mysql.com>. Acesso em: 15 abr. 2009. PREFEITURA DE UBERLÂNDIA. Secretaria Municipal de Planejamento. Banco de dados integrados. Uberlândia, 2007. Disponível em: <http://www.uberlandia.mg.gov.br/midia/documentos/planejamento_urbano/BDI_2007_vol_1.pdf>. Acesso em: 7 mar 2009. RICARTE. I. L. M; Sistemas de bancos de dados orientados a objetos. Setembro 1998. 41p. Universidade Estadual de Campinas (Mimeo.). Disponível em: < ftp://ftp.dca.fee.unicamp.br/pub/docs/ricarte/apostilas/mc_sbdoo.pdf>. Acesso em: 3 jun. 2009. SILVA, Paulo C. Barreto da. Utilizando UML: diagrama de classes. SQL Magazine, Rio de Janeiro, edição 63, ano 5, p. 10-17, 2007. SILVA, Sonia Maria Antunes da; BONIN, Marcos Rodrigo; PALUDO, Marco Antônio. Levantamento de requisitos segundo o método volere. Disponível em: < http://publica.fesppr.br/index.php/rnti/article/viewFile/v1n1ART2/86>. Acesso em: 16 maio 2009. SILVEIRA, H. M. Comunidade do sistema gene de apoio ao aprendizado de genética. 2008. 66 f. Trabalho de Graduação Interdisciplinar (Curso superior em Tecnologia em informática) - Centro Superior de Educação Tecnológica – Universidade Estadual de Campinas, Limeira, 2008. Disponível em: <http://www.ceset.unicamp.br/liag/Gene/artigos/monografiaFinalHenrique_v7_.pdf>. Acesso em: 10 mai. 2009.

UNIMIN

AS

157

SUN, Core J2EE patterns: data access object. Disponível em: <http://www.sun.com/>. Acesso em: 15 jun. 2009. TOOD, Nick; SZOLKOWSKI, Mark. Java Server Pages: o guia do desenvolvedor. Tradução de Edson Furmankiewic. Rio de Janeiro: Elsevier, 2003. 621 p. UML. Object Management Group - Unified Modeling Language. Disponível em: <http://www.uml.org>. Acesso em: 15 abr. 2009. URBANIZAÇÃO DO Brasil. Disponível em: <http://www.passeiweb.com/na_ponta_lingua/sala_de_aula/geografia/geografia_do_brasil/quadro_humano/brasil_urbanizacao>. Acesso em: 7 mar. 2009. URBANIZAÇÃO DO mundo. Disponível em: <http://www.brasilescola.com/geografia/urbanizacao-mundo.htm>. Acesso em: 7 mar 2009. WAZLAWICK, Raul Sidney. Análise e projetos de sistema orientados a objetos. 2. Ed. Rio de Janeiro: Elsevier, 2004. 295 p. WIKIPEDIA. Java (linguagem de programação). Disponível em: (Orlando) <http://pt.wikipedia.org/wiki/Java/linguagem_de_programa%C3%A7%C3%A3o>. Acesso em 15 maio 2009a. _______. Modelagem de dados. Disponível em (Marco 2) <http://pt.wikipedia.org/wiki/Modelagem_de_dados>. Acesso em: 2 jun. 2009b. _______. Persistência de dados. Disponível em <http://pt.wikipedia.org/wiki/Persist%C3%AAncia_de_dados >. Acesso em: 4 maio 2009c. _______. Polis. Disponível em: <http://pt.wikipedia.org/wiki/P%C3%B3lis>. Acesso em: 7 mar 2009d. YOSHIMA, Rodrigo. Modelando o escopo do sistema com casos de uso. In: ______. Projeto de Software com UML 2.0. ASPERCOM, 2005. p. 9-27. 2009. Disponível em: <http://www.aspercom.com.br/ead/mod/resource/view.php?id=16>. Acesso em 23 fev. 2009.

UNIMIN

AS

158

APÊNDICE

Código do arquivo struts.xml

<!DOCTYPE struts (View Source for full doctype...)>

<struts>

<package name="default" extends="struts-default">

- 

<action name="login" method="execute" class="br.uniminas.action.Login2">

<result>/page/login.jsp</result>

<result name="success">/page/principal.jsp</result>

<result name="erro">/page/login.jsp</result>

</action>

<action name="principal">

<result>/page/principal.jsp</result>

</action>

<action name="getAllPessoas" method="getAllPessoas" class="br.uniminas.action.CadastrarPessoaAction">

<result name="success">/page/pessoas.jsp</result>

</action>

<action name="getPessoa" method="getPessoa" class="br.uniminas.action.PesquisarAction">

<result name="success">/page/pessoa.jsp</result>

</action>

<action name="setUpForInsertOrUpdate" method="setUpForInsertOrUpdate" class="br.uniminas.action.CadastrarPessoaAction">

<result name="success">/page/cadastroPessoaForm.jsp</result>

</action>

<action name="insertOrUpdate" method="insertOrUpdate" class="br.uniminas.action.CadastrarPessoaAction">



</action>

<action name="setUpForInsertOrUpdate2" method="setUpForInsertOrUpdate2" class="br.uniminas.action.PesquisarAction">

<result name="success">/page/consultaPessoaForm.jsp</result>

</action>


<result name="success">/page/consultaUnidadeForm.jsp</result>

</action>

UNIMIN

AS

159


<result name="success">/page/consultaHistorico.jsp</result>

</action>

<action name="consultarPessoa" method="consultaPessoa" class="br.uniminas.action.PesquisarAction">

<result name="success">/page/pessoa.jsp</result>


</action>

<action name="consultarUnidade" method="consultaUnidade" class="br.uniminas.action.PesquisarAction">

<result name="success">/page/unidade.jsp</result>


</action>

<action name="consultarHistorico" method="consultaHistorico" class="br.uniminas.action.PesquisarAction">

<result name="success">/page/historico.jsp</result>


</action>

<action name="delete" method="deletePessoa" class="br.uniminas.action.CadastrarPessoaAction">

<result name="success" type="redirect-action">getAllPessoas</result>


</action>

</package>

</struts>

GESTAO DE CONDOMINIO

Documents

Transcript of GESTAO DE CONDOMINIO