universidade federal fluminense bruno edeildes … · ficha catalográfica elaborada pela...

UNIVERSIDADE FEDERAL FLUMINENSE

BRUNO EDEILDES LIMA

GERENCIADOR DE CONDOMÍNIO

Niterói

2016

BRUNO EDEILDES LIMA


Trabalho de Conclusão de Curso subme-

tido ao Curso de Tecnologia em Sistemas

de Computação da Universidade Federal

Fluminense como requisito parcial para

obtenção do título de Tecnólogo em Sis-

temas de Computação.

Orientador:

Rafael Burlamaqui Amaral

NITERÓI

2016

Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

L732g Lima, Bruno Edeildes

Gerenciador de condomínio / Bruno Edeildes Lima. – Niterói, RJ

: [s.n.], 2016.

97 f.

Projeto Final (Tecnólogo em Sistemas de Computação) –

Universidade Federal Fluminense, 2016.

Orientador: Rafael Burlamaqui Amaral.

1. Desenvolvimento de software. 2. Administração condominial.

I. Título.

CDD 005.71

BRUNO EDEILDES LIMA


Trabalho de Conclusão de Curso subme-

tido ao Curso de Tecnologia em Sistemas

de Computação da Universidade Federal

Fluminense como requisito parcial para

obtenção do título de Tecnólogo em Sis-

temas de Computação.

Niterói, 20 de junho de 2016.

Banca Examinadora:

_________________________________________

Prof. Rafael Burlamaqui Amaral, Msc. – Orientador

CEFET/RJ - Centro Federal de Educação Tecnológica Celso Suckow da Fonseca

_________________________________________

Prof. Ubiratam Carvalho de Paula Junior, Dr. – Avaliador

UFRRJ - Universidade Federal Rural do Rio de Janeiro

Dedico este trabalho a minha noiva Yvie e

aos meus pais.

AGRADECIMENTOS

A professora Isabel Cristina Mello Rosseti,

Pelo estímulo a estudar programação orienta-

ção a objeto, pelo qual fiz o programa deste

trabalho em linguagem Java.

Ao meu Orientador Rafael Burlamaqui Amaral,

pelo estímulo e atenção que me concedeu du-

rante este trabalho acadêmico.

Aos Colegas de curso pelo incentivo e troca de

experiências.

A todos os meus familiares e amigos pelo

apoio e colaboração.

“Quem abandona a luta não poderá nunca sa-

borear o gosto de uma vitória”.

Textos Judaicos

http://pensador.uol.com.br/autor/textos_judaicos/

RESUMO

Administrar um condomínio se torna cada vez mais complexo. Cada vez mais é co-mum nos centros urbanos este tipo de moradia e tão comuns são os problemas roti-neiros que se apresentam no dia-a-dia. Problemas como, por exemplo, o controle de pagamentos da taxa de condomínio, agilidade em obter dados relacionados a estes ou outros cadastros. É delegado ao síndico o poder de gerir e encontrar a melhor forma para conduzir esta demanda. Mas, nem sempre este profissional está apto para isto, pois faltam conhecimentos do setor burocrático, administrativo e habilidades com a informática. A contratação de uma empresa especializada pode ajudar na parte ju-rídica e administrativa, que traz uma dependência e um novo custo para o condomínio. Pois é necessário um tratamento especial com os dados produzidos, como: Cadastro de pagamentos e outros cadastros. A elaboração de um software conciso para atender esta demanda é cada vez mais evidente nos setores de administração e pode-se as-sim, deixá-lo a disposição do síndico. O mesmo poderia obter uma lista dos moradores inadimplentes, os dados pessoais de um morador, produzir informativo para os mu-rais, entre outros relatórios. E desta forma o síndico, se tornar independente na admi-nistração de seu condomínio. Reduzido custos com outros profissionais e empresas especializadas. Este trabalho apresenta o processo de criação de um software voltado especificamente para administração de um condomínio.

Palavras-chaves: Condomínio, Administração, Software, moradores.

ABSTRACT

To manage a condominium has become increasingly complex. These urban areas

have become more common for living in a community, with such way of life, routine

issues come up daily. Such as problems with condominium fees and payments and

keeping record of all of it. The power to manage and conduct such demands is dele-

gated to the syndic. This trustee is not always prepared to act in different areas such

as the bureaucracy of the laws involved, the business administration and abilities with

information technology. It might be helpful to hire a professional in the area to deal with

all the specific needs of the condominium management, this would bring an extra cost

to the overall fee to be paid by the residents. It is important to take care of the data,

such as log of payments and other registry. The development of a concise software to

attend these demands is extremely evident in business administration, and could be

available for the syndic usage. This way, one would be able to obtain a list of residents

that are overdue, as well as their personal information, and would be able to make

bulletins for the bulletin board and other records. Therefore, one would become inde-

pendent to manage the condominium reducing costs and optimizing results. This pro-

ject presents the process of creating a software that is made for the specific demands

of the administration of condominiums.

Key words: Condominium, management, Software and residents.

LISTA DE ILUSTRAÇÕES

Figura 1: Portal do aplicativo Acolweb ...................................................................... 20

Figura 2: Portal do aplicativo Seu Condomínio ......................................................... 21

Figura 3: Software Adcond Basic .............................................................................. 22

Figura 4: Classe condomínio ..................................................................................... 25

Figura 5: Herança de classe ...................................................................................... 27

Figura 6: IDE Eclipse ................................................................................................. 30

Figura 7: IDE Jcreator ............................................................................................... 31

Figura 8: IDE Netbeans ............................................................................................. 32

Figura 9: IDE Microsoft Office Access ....................................................................... 33

Figura 10: IDE MSACCESS com três tabelas relacionada. ...................................... 34

Figura 11: IDE do MSAccess com a tabela imóvel. ................................................... 35

Figura 12: IDE DO MSACCESS com a tabela Proprietário. ...................................... 35

Figura 13: IDE DO MSAccess com os comandos SQL. ............................................ 36

Figura 14: IDE DO MSAccess com resultado de consulta. ....................................... 37

Figura 15: Tabelas de banco de Dados .................................................................... 38

Figura 16: IDE StarUML ............................................................................................ 40

Figura 17: Diagrama de classe .................................................................................. 41

Figura 18: Diagrama de objeto .................................................................................. 42

Figura 19: Diagrama de Componentes ..................................................................... 43

Figura 20: Diagrama de Implantação ........................................................................ 43

Figura 21: Diagrama de pacote ................................................................................. 44

Figura 22: Diagrama de Estrutura ............................................................................. 45

Figura 23: Diagrama de Caso de Uso (Use Case) .................................................... 46

Figura 24: Diagrama de Estados ............................................................................... 46

Figura 25: Diagrama de Sequência ........................................................................... 47

Figura 26: Diagrama de caso de uso da classe Pagamento. .................................... 50

Figura 27: Diagrama de caso de uso da classe Proprietário. .................................... 50

Figura 28: Diagrama de caso de uso da classe Morador. ......................................... 51

Figura 29: Diagrama de caso de uso da classe Negociação ................................... 51

Figura 30: Diagrama de caso de uso da classe Solicitação. ..................................... 52

Figura 31: Diagrama de caso de uso da classe Veículo. .......................................... 52

Figura 32: Diagrama Conceitual ER .......................................................................... 63

Figura 33: Diagrama de Classes ............................................................................... 65

Figura 34: Diagrama de fases do sistema ................................................................. 66

Figura 35: Interface gráfica do Access com as Tabelas do programa ....................... 67

Figura 36: Tela de cadastro de pagamento ............................................................... 78

Figura 37: Tela de cadastro de proprietário .............................................................. 82

Figura 38: Tela de cadastro de morador ................................................................... 82

Figura 39: Tela de cadastro de solicitação ................................................................ 83

Figura 40: Tela de cadastro de negociação .............................................................. 83

Figura 41: Tela de cadastro de veículo ..................................................................... 84

Figura 42: Tela de cadastro de funcionário ............................................................... 84

Figura 43: Tela de pagamentos ................................................................................. 92

Figura 44: Tela de cadastro de proprietário .............................................................. 94

Figura 45: Tela de Cadastro de Morador .................................................................. 95

Figura 46: Cadastro de solicitação ............................................................................ 96

Figura 47: Cadastro de negociação .......................................................................... 97

Figura 48: Cadastro de veículo ................................................................................. 97

Figura 49: Cadastro de funcionário ........................................................................... 98

LISTA DE TABELAS

Tabela 1: Algumas regras de negócio .............................................................. 48

Tabela 2: caso uso 01 ...................................................................................... 53

Tabela 3: caso uso 02 ...................................................................................... 54

Tabela 4: caso uso 03 ...................................................................................... 55

Tabela 5: caso uso 04 ...................................................................................... 56

Tabela 6: caso uso 05 ...................................................................................... 57

Tabela 7: Requisitos Funcionais ...................................................................... 59

Tabela 8: Requisitos Não Funcionais ............................................................... 60

Tabela 9: Tabela Pagamento ........................................................................... 68

Tabela 10: Tabela Proprietario ......................................................................... 69

Tabela 11: Tabela Morador .............................................................................. 71

Tabela 12: Tabela Solicitacao .......................................................................... 72

Tabela 13: Tabela Negociacao ......................................................................... 73

Tabela 14: Tabela Veiculo ................................................................................ 74

Tabela 15: Tabela Funcionario ......................................................................... 75

Tabela 16: HistoricoDeAlteracoes .................................................................... 76

LISTA DE GRÁFICOS

Gráfico 1: Erros e custo de correção ................................................................ 91

LISTA DE ABREVIATURAS E SIGLAS

APIs - Application Programming Interface.

CASE - Aided Software Engineering.

ER – Entidade de Relacionamento.

GPL- General Public License.

IDE - Integrated Development Environment.

J2ME - Java Plataform, Micro Edition.

JEE ou Java EE-Enterprise Edition.

JME ou Java ME - Micro Edition.

JSE ou Java SE - Java Standard Edition.

JVM - Java Virtual Machine.

MSAccess – Microsoft Access.

NF – Nao functional

OMG - Object Management Group.

OOSE - Object-oriented software engineering.

PDAs - Personal digital assistants.

PK – Primary Key.

POO – Programação Orientada a Objeto.

RN – Regra de negócio.

SGBD – Sistema de Gerenciamento de Banco de Dados.

SO – Sistema Operacional.

SQL - Structured Query Language.

UML - Unified Modeling Language.

UC –Use Case.

VBA - Visual Basic for Application.

SUMÁRIO

RESUMO..................................................................................................................... 7

ABSTRACT ................................................................................................................. 8

LISTA DE ILUSTRAÇÕES .......................................................................................... 9

LISTA DE TABELAS ................................................................................................. 11

LISTA DE GRÁFICOS ............................................................................................... 12

LISTA DE ABREVIATURAS E SIGLAS .................................................................... 13

1. INTRODUÇÃO ................................................................................................... 16

2. TRABALHOS RELACIONADOS ........................................................................ 19

3. REVISÃO BIBLIOGRÁFICA: CONCEITOS ........................................................ 24

3.1 JAVA SE ..................................................................................................... 24

3.2 MICROSOFT OFFICE ACCESS ................................................................. 32

3.3 UML ............................................................................................................ 38

3.3.1 DIAGRAMAS ESTRUTURAIS ........................................................ 40

3.3.2 DIAGRAMAS COMPORTAMENTAIS ............................................. 45

4. CASOS DE USO ................................................................................................ 48

4.1 REGRAS DE NEGÓCIO ............................................................................. 48

4.2 DIAGRAMA DE CASOS DE USO DO “GERENCIADOR DE CONDOMÍNIO” ...... 49

4.3 DESCRIÇÃO DOS CASOS DE USO .......................................................... 53

4.4 REQUISITOS .............................................................................................. 58

4.4.1 REQUISITOS FUNCIONAIS ........................................................... 58

4.4.2 REQUISITOS NÃO FUNCIONAIS .................................................. 60

5. MODELAGEM DO “GERENCIADOR DE CONDOMÍNIO” ................................. 62

5.1 DIAGRAMA ENTIDADE DE RELACIONAMENTO ..................................... 62

5.2 FASES DO SISTEMA PARA O CASO DE USO PAGAMENTO ................. 65

6. PROJETO “GERENCIADOR DE CONDOMÍNIO” .............................................. 67

6.1 MODELAGEM DO BANCO DE DADOS ..................................................... 67

6.2 INTERFACE GRÁFICA DO “GERENCIADOR DE CONDOMÍNIO”. ........... 77

7. CONCLUSÃO E TRABALHOS FUTUROS ........................................................ 85

REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 87

APÊNDICE ................................................................................................................ 90

APÊNDICE A - GRÁFICO DE ERRO DE CUSTO DE CORREÇÃO. ....................... 90

APÊNDICE B – GUIA RÁPIDO DO USUÁRIO .......................................................... 91

TELA DE CADASTRO DE PAGAMENTO ................................................................. 91

TELA DE CADASTRO DE PROPRIETÁRIO ............................................................. 93

TELA DE CADASTRO DE MORADORES ................................................................ 95

16

1. INTRODUÇÃO

Ao longo dos anos, a sociedade moldou um tipo de habitação, chamada

condomínio. Este tipo de moradia vem se tornado mais importante para a sociedade

urbana. Os motivos são vários, como por exemplo, a falta de espaço e o grande cres-

cimento populacional das cidades. Em um mesmo local pode se ter dezenas de apar-

tamentos com vários andares. Pode se definir um condomínio, desta forma: “Dá-se o

condomínio quando a mesma coisa pertencer a mais de uma pessoa, cabendo a cada

uma delas igual direito, idealmente, sobre o todo e cada uma das partes” [18].

Segundo dados do último censo em 2010, divulgado pelo IBGE,

Dos 57,3 milhões de domicílios, mais de 1 milhão está em vilas e condomí-

nios. As regiões Sudeste e Nordeste são as que mais apresentam esse tipo

de moradia, somando juntas 170,6 mil unidades. O Rio de Janeiro é o Estado

que concentra o maior número de vilas e condomínios, com 279 mil habita-

ções nesse estilo. São Paulo aparece em segundo lugar, com 182 mil, se-

guido por Paraná, com 72 mil. Já o Acre tem apenas 763 unidades assim [28].

Com dezenas, centenas e até mesmo milhares de moradias em um mesmo

espaço coletivo, direitos e deveres devem ser respeitados e cabe a gestão de uma

Figura muito importante neste cenário que é o sindico.

O sindico é o profissional que vai fazer valer os direitos e deveres dos con-

dôminos respondendo administrativamente [5]. Mas este profissional nem sempre

está atualizado com as normas de condomínio e muita das vezes não tem habilidade

necessária para gerir administrativamente seu condomínio.

O caos pode ser ainda pior quando se trata da parte financeira, quando não

se tem o controle dos pagamentos da taxa de condomínio. Taxa paga pelos condômi-

nos, que são os moradores, a fim de repasse aos serviços e manutenção coletiva do

condomínio, como por exemplo, serviço de segurança, limpeza, abastecimento de

água, entre outros.

O problema supracitado, na maioria das vezes é resolvido com a contrata-

ção de uma empresa para administrar. A contratada, com auxílio da informática e de

17

profissionais, vai solucionar estes problemas. Sendo que desta maneira os condômi-

nos terão mais um novo custo: A contratada.

A elaboração de um software conciso para atender esta questão gerencial,

é cada vez mais evidente nos setores de administração. Dessa forma, deixa-lo à dis-

posição do síndico. O mesmo poderia obter uma lista dos moradores inadimplentes,

os dados pessoais de um morador, produzir relatórios informativos para os murais,

entre outros. E assim o síndico, se tornar independente na administração de seu con-

domínio. Reduzindo o custo com outros profissionais e empresas especializadas.

Este trabalho apresenta o processo de criação de um software voltado es-

pecificamente para administração de um condomínio. O objetivo geral do aplicativo,

denominado “Gerenciador de condomínio”, será uma ferramenta fundamental para o

cadastro de pagamentos e outros tipos de cadastros. Com base nestes dados serão

gerados relatórios que o administrador do condomínio, denominado síndico, poderá

usar nas suas atividades diárias e nas futuras decisões importantes.

O “Gerenciador de condomínio” será um programa portátil, feito na lingua-

gem Java SE, com banco de dados em Microsoft Office Access e com interfaces para

entrada e saída de dados.

Este trabalho acadêmico terá como finalidade mostrar as fases de confec-

ção de um software, que vai da análise de pré-requisito até a implantação na máquina

do cliente. Com as fases bem definidas de análise, modelagem e projeto, utilizando

técnicas de engenharia de software e elementos da notação UML.

No Capítulo 2, serão abordados alguns trabalhos relacionados ao problema

apresentado na administração de condomínios, possíveis soluções encontradas nesta

pesquisa e se satisfazem a problemática que é tema deste TCC.

No Capítulo 3, serão descritos conceitos importantes para a compreensão

deste trabalho como: A linguagem adotada, Java SE; O sistema gerenciador de banco

de dados, Microsoft Access e conceitos sobre UML, com exemplo da modelagem do

programa “gerenciador de condomínio”.

No Capítulo 4, encontram-se os casos de uso do “Gerenciador de condo-

mínio” dentro dos conceitos da UML.

No capítulo 5, é apresentada a fase de modelagem, onde são identificados e modelados entidades e relacionamentos, juntamente com as fases do sistema.

18

No Capítulo 6, será mencionado um pouco sobre o projeto, também sobre as tabelas necessárias para o banco de dados e também será mencionado sobre o protótipo da interface gráfica.

No Capítulo 7, será o fechamento do trabalho acadêmico com a conclusão.

Serão avaliados os efeitos e resultados do sistema, e projetando as estimativas de

trabalhos futuros.

19

2. TRABALHOS RELACIONADOS

Encontrar uma solução para um problema e transformar esta solução em

software requer muitas análises sobre os serviços que serão oferecidos por um apli-

cativo. Um software pode oferecer muitas utilidades e nem sempre pode atender o

que um cliente espera. Por isto faz-se necessário uma boa pesquisa sobre o que esta

disponível no mercado.

Para o software que será desenvolvido neste trabalho, “o gerenciador de

condomínio”, foram feitas pesquisas sobre empresas desenvolvedoras de software

para gerenciamento de condomínio e todos tinham características parecidas. A ques-

tão de administrar um condomínio é muito importante e estudada por estas empresas,

conforme será apresentado neste capítulo. Os desenvolvedores deste tipo de aplica-

ção descrevem funções muito parecidas como: Agilidades em obter relatórios com

dados consistentes; Cadastro de pagamento da taxa de condomínio; Consultas de

débitos; Consultas de gastos do condomínio; Cadastro de reclamações, entre outras.

O que também é muito parecido é a forma da prestação de serviços; todos

online e com custo mensal. Algumas empresas prometem cursos de informática para

os funcionários do condomínio, o que é relevante, pois muitos destes não têm o co-

nhecimento mínimo de informática. Estas informações são dos sites das empresas de

administração de condomínio e empresas de desenvolvedoras de software.

Para conhecer melhor cada um destes aplicativos são mencionados pelos

seus representantes que agendem com um consultor comercial (funcionário destas

empresas) um contato informal; que pode ser por telefone, pessoalmente, vídeo con-

ferencia (estes contatos são oferecidos por estas empresas de diversas formas). Se-

guem algumas aplicações prontas para o gerenciamento de condomínios:

O Acolweb: É um Software Online, com a finalidade de administrar Condomí-

nios. A empresa desenvolvedora oferece o serviço por um período gratuito.

Esta empresa tem o mesmo nome da aplicação, Acolweb. O acesso ao aplica-

tivo é pela internet através de usuário e senha. Este acesso é tanto para o

síndico quanto para os condôminos (cada um dentro de um perfil). Oferece

20

também serviço de cadastro de carros dos moradores, cadastro de funcioná-

rios, cadastro de animais dos moradores, cadastro de fornecedores, serviço de

agendamento de controle para pagamento de contas do condômino, gera reci-

bos e de carta de cobrança, negocia acordos com os inadimplentes, fecha-

mento mensal de contas, registro de ocorrência e todo tipo de relatório dos

serviços mencionado. O aplicativo também conta com o serviço de envio de e-

mails informativos para os condôminos. Segue abaixo, a Figura 1, o portal de

acesso do Acolweb [25];

Figura 1: Portal do aplicativo Acolweb

O software “Seu Condomínio”: É também outro Software online para

administração de condomínio, desenvolvidos pelos irmãos Rodrigo e Ro-

gério Evangelista. Esta empresa, do estado de Goiás, também tem o

nome do aplicativo. Oferece o serviço de cadastro de fornecedores para

que o síndico possa fazer solicitações de compras online e assim obter a

melhor proposta de seus fornecedores. Um grande diferencial deste apli-

cativo é que ele pode ser acessado e controlado via mobile. O síndico

recebe e envia e-mail para os moradores, autoriza pagamento e envia

prestações de contas para o contador, pelo celular. Segue abaixo a tela

inicial, a Figura 2, do “Seu Condomínio” [24].

21

Figura 2: Portal do aplicativo Seu Condomínio

O software Adcond: Da empresa Assist Software & Serviços, que atua

no mercado desde 1993. Este programa é usado para gerenciamento de

condomínios, que contempla versões on-line e também off-line. Este sof-

tware possui tipos para atender demandas diferentes para cada tipo de

condomínio:

o Adcond Basic - Esta versão é gratuita deste 2002 e seu suporte

também. Mesmo sendo uma versão gratuita ela permanece com

as características básicas das versões pagas. Esta versão permite

o controle das contas a receber e contas a pagar e disponibiliza os

relatórios operacionais e gerenciais básicos, necessários para o

controle financeiro. Segue abaixo a figura 3 desta versão:

22

Figura 3: Software Adcond Basic

o Adcond Essencial - Este tipo de versão cadastra de 50 a 500 uni-

dades de moradia, sendo que o preço varia de acordo com a quan-

tidade de moradias e funções solicitadas (os valores estão dispo-

níveis no site). Esta versão possibilita fazer tudo da versão básica

e além disso faz balancetes e possui, como opcional, o módulo de

emissão de boletos com código de barras e baixa automática.

o Adcond Controle - Este tipo de versão cadastra até 100 unidades

de moradias e possui todas as características das versões anteri-

ores. Além destas, suas outras funções são:

- Controle de moradores: veículos e garagens, lista de permissões

e bloqueios definidos pelos moradores;

- Controle de portaria: com registro de visitantes, agendamentos,

correspondência e encomendas;

- Controle de manutenção: de maquinas e equipamentos, com o

registro de prestadores de serviço e principais fornecedores.

23

o AdcOperacionalWeb - Esta é a versão on-line. O acesso pela in-

ternet pode ser feito em Smartphones, Tablets, Notebo-

oks e Desktop. A licença de uso é adequada às necessidades de

cada usuário, com taxa mensal ou taxa única. Esta versão contem-

pla todas as funcionalidades das versões anteriores, entre outras.

A empresa tem servidor próprio e exclusivo para este serviço.

Outros como: O software “Sousindico” seu desenvolvedor é a empresa Ah-

era soluções web Ltda.[26]; O software “SIN - Sistema de Gestão de Condomínios”,

da empresa Icondev [23]; O software Scond a empresa desenvolvedora é a Publichess

Tecnologia. São programas com características parecidas com os dois exemplos

mencionadas acima.

Quase todas as aplicações apresentadas acima são soluções online, em

que o síndico terá que acessar as informações pela internet e os dados produzidos

serão armazenados nos servidores da empresa do software escolhido. Dependem de

acesso à internet e um custo mensal ao condomínio. A este trabalho acadêmico é

dada uma importância em ter os dados armazenados em computadores da adminis-

tração do condomínio. Sem a dependência de uma empresa para isto. Para a neces-

sidade que propõe este trabalho faz-se necessário desenvolver um novo software com

as condições e soluções que serão relatadas nos próximos capítulos.

24

3. REVISÃO BIBLIOGRÁFICA: CONCEITOS

Neste capítulo serão abordados conceitos fundamentais para a compreen-

são do projeto do software “Gerenciador de condomínio”. Serão descritos conceitos

da linguagem utilizada, o banco de dados escolhido e de uma linguagem de modela-

gem. São eles: Java SE, Microsoft Office Access, UML respectivamente.

3.1 JAVA SE

Java é uma linguagem de programação orientada a objeto, de multiplata-

forma de código aberto e gratuito. A linguagem foi desenvolvida pela antiga empresa

de software chamada Sun Microsystems em 1992, e que mais tarde a Sun Microsys-

tems veio a ser vendida para Oracle em 2009. Atualmente a linguagem Java está

disponível, para download, no site da empresa de software Oracle [9][27]

No que se refere à Programação Orientação a Objeto (POO), seguem algumas

definições básicas para a compreensão de termos que seguirão nos próximos

capítulos [8][26]:

Package (Pacote): São pacotes, espaços lógicos, como se fossem pastas

que servem para guardar conjuntos de classes semelhantes ou de afini-

dades.

Objeto: É um elemento concreto e instanciado a partir de uma classe, a

isto se trás o conceito de que Java é orientado a objeto. Um objeto é ca-

racterizado por atributos, que são variáveis de memorias que guardam

características do objeto e métodos são funções que determina ações

para o objeto. Um exemplo de um objeto do mundo real pode ser: Um

proprietário de um apartamento, que na modelagem do objeto “Proprietá-

rio” é construído por atributos, que podem ser, por exemplo: Nome do

Proprietário; data de nascimento do proprietário; endereço do proprietário;

Site da Oracle: www.oracle.com/technetwork/java/index.html

25

profissão do proprietário; situação de pagamentos proprietário. Exemplos

de método para este objeto poderia ser: Inserir nome do proprietário; obter

nome do proprietário; salvar pagamento do proprietário; salvar reclama-

ção do proprietário; localizar proprietário, alterar cadastro do proprietário,

entre outros.

Classes: É um modelo ou projeto de um objeto que define um tipo de

objeto, ou seja, um modelo abstrato que dá forma a um objeto. Uma

classe é conjunto de objetos com a mesma estrutura de dado caracteri-

zada pelos seus atributos e métodos. Um exemplo seria uma classe cha-

mada “Condomínio”, ela daria forma a vários condomínios. Com seus

atributos e métodos constroem objetos do mundo real como: O condomí-

nio Natura; Condomínio La vista; Condomínio Aloha; Condomínio Puerto;

Condomínio Madero; todos estes são condomínio do bairro chamado Re-

creio dos Bandeirantes da cidade do Rio de Janeiro.

Logo abaixo segue a Figura 4, com um diagrama de classe (exemplo hipo-

tético), com alguns atributos e métodos, para a modelagem dos objetos citados acima:

Figura 4: Classe condomínio

condominio

-nomeDoCondominio: String-CNPJ: String-endereco: String-telefone: String-dataDaContruncao: Calendar-areaMetroDoCondominio: float-qdeDeApartamentos: int-qdeDeBlocos: int

+getTelefone()+setTelefone(telefone: String)+public int getQdeDeBlocos()+setQdeDeBlocos(qdeDeBlocos: int)

26

Atributos ou Variáveis: Representam as características do objeto. Por

exemplo, o objeto “Proprietário” tem os atributos: Nome; idade; número

do apartamento; número do bloco e outros.

Herança: É quando a superclasse, denominada a classe mãe, passa suas

características para a subclasse, denominada a classe filha. Isto evita a

reescritas de códigos tanto para os atributos e métodos. Segue um a Fi-

gura 5, com um exemplo de uma ilustração abaixo, onde a superclasse

chamada “Pessoa” tem os seguintes atributos: CPF; Nome; Data de nas-

cimento. E os seguintes métodos: Obter CPF; obter nome; obter data de

nascimento entre outros. Outras classes como “Morador”, “Funcionário”,

“Proprietário”, poderiam se entender a superclasse “Pessoa”. Sendo as-

sim estas subclasses, terão da superclasse “Pessoa” os mesmos atribu-

tos e métodos (exemplo hipotético). Na linguagem Java a palavra “ex-

tends”, é uma palavra reservada para estender à superclasse a sub-

classe.

27

Figura 5: Herança de classe

Abaixo um exemplo de um objeto “Proprietario” instanciado e que herda da

superclasse “Pessoa” seus atributos e métodos, a palavra reservada em Java “new”

cria o objeto “p” da subclasse “Proprietario”. O objeto “p” recebe o nome pelo método

“setNome”, recebe o CPF pelo método “setCPF” e por último recebe a data de nas-

cimento pelo método “setDataNascimento”:

A referida orientação a objeto se dá ao fato de objetos poderem se comu-

nicar por meio de métodos da linguagem Java. Métodos são funcionalidades ou ações

28

para troca de informação entre os objetos, como por exemplo, a comunicação do ob-

jeto pagamento para obter um nome de um morador ou o próprio objeto pagamento a

obter a data atual para o registro do pagamento da data corrente, por exemplo.

No que se refere à multiplataforma, isto quer dizer que o programa desen-

volvido na linguagem Java, depois de compilado, (transformado da linguagem de pro-

gramação para a linguagem de máquina) é gerado um arquivo chamado bytecode.

Este tipo de arquivo é interpretado pela máquina virtual Java, independente de qual

seja o sistema operacional (SO). Poderá ser executado, sem a necessidade de uma

nova compilação em sistemas operacionais diferentes como: Linux, Windows, Sola-

res, Mac e outros. Isto se dá, graças a “Java Virtual Machine” (JVM), a máquina virtual

do Java que se encarrega de “traduzir” o bytecode para qualquer sistema operacional.

A máquina virtual fica entre a camada de aplicação e o sistema operacional e assim

desempenha a função que permite que o programa, feito em linguagem Java, seja de

multiplataforma.

A linguagem Java atualmente está dividida de três plataformas principais,

são elas: Java SE, Java EE e Java ME [9][27][13]. E são destinadas a tipos de aplica-

ções distintas, aplicações desktop, (no qual a entrada e saída de dados é feita por

uma interface gráfica feita em Java), aplicações Web (no qual a entrada e saída de

dados é feita por componentes gráficos feita em Java, que são visualizados em um

navegador WEB) e aplicações para dispositivos móveis. Seguem abaixo, mais deta-

lhes destas plataformas respectivamente:

Java Standard Edition (Java SE) é a linguagem Java utilizada para o de-

senvolvimento desktop. Esta plataforma contém todo o ambiente necessário para a

criação e execução de aplicações, a máquina virtual (JVM), o compilador, e as Inter-

faces de Programação de Aplicativos (APIs). E é nesta linguagem que o programa

que é título deste trabalho, “Gerenciador de condomínio”, será desenvolvido, desta-

cando-se então neste trabalho os principais pacotes e classe deste tipo de aplicação.

Os principais pacotes da linguagem Java SE, são: Java.lang, java.io, java.math,

java.net, java.util e outros.

Java Enterprise Edition (Edição Empresarial) ou Java EE, este tipo de lin-

guagem Java não será o foco deste trabalho. Em resumo Java EE é a plataforma que

engloba aplicações corporativas, de grande porte. A diferença fundamental em rela-

ção ao Java SE, é que a Edição Empresarial (Java EE) possui bibliotecas especifica

29

(APIs) para implementar este tipo de software em Java. Estas bibliotecas são de ca-

racterísticas Webs que tratam com suas propriedades como: Persistência de dados,

validações (usuário, formulário etc.), transações (conexões com SGBD, por exemplo),

tratamento de requisições HTTP, entre outras. É uma linguagem voltada para aplica-

ções Web, e por assim necessita de servidores para sua execução [10].

Já a linguagem Java EE Micro Edition (Edição Micro), conhecida com Java

ME, ou ainda J2ME, é uma linguagem de programação destinada aos dispositivos

móveis e sistemas embarcados (embedded systems), dispositivos com recursos limi-

tados. Esta edição abrange celulares, PDAs, controles remotos e muitos outros.

Para finalizar este tema, falta a escolha de uma IDE para trabalhar como a

Linguagem. IDE: “do inglês Integrated Development Environment ou Ambiente de De-

senvolvimento Integrado, é um programa de computador que reúne características e

ferramentas de apoio ao desenvolvimento de software com o objetivo de agilizar este

processo” [10].

As IDE’s têm como finalidade agilizar na escrita da construção de um sof-

tware e nelas são introduzidas algumas outras ferramentas, as principais que serão

comentadas neste trabalho são:

Editor – Parte da IDE por onde será possível escrever e editar o código

fonte da linguagem Java;

Compilador (compiler) – É ferramenta fundamental que acompanha as

IDE’s. Ela transforma o código fonte, editado, num código de linguagem

de máquina;

Depurador (debugger) – Ferramenta que auxilia no processo de encontrar

e corrigir defeitos, que podem surgir na escrita do código-fonte do pro-

grama.

As IDE’s mais comuns do mercado para a escrita do código fonte para a

linguagem Java são:

https://pt.wikipedia.org/wiki/Compilador

https://pt.wikipedia.org/wiki/Depurador

30

O Eclipse: Gera código Java (através de plugins, o Eclipse suporta muitas

outras linguagens como Python e C/C++). Logo abaixo a Figura 6, uma imagem da

IDE Eclipse;

Figura 6: IDE Eclipse

O Jcreator: Gera código Java, suporta muitas outras linguagens como Ja-

vaScript, XML, HTML. Logo abaixo, segue uma imagem da IDE Jcreator, a Figura 7;

https://pt.wikipedia.org/wiki/Java_(linguagem_de_programa%C3%A7%C3%A3o)

https://pt.wikipedia.org/wiki/Python

https://pt.wikipedia.org/wiki/Linguagem_de_programa%C3%A7%C3%A3o_C

https://pt.wikipedia.org/wiki/C%2B%2B


31

Figura 7: IDE Jcreator

O Netbeans: Gera código Java (ele suporta muitas outras linguagens

como Python e C/C++). Logo abaixo, segue uma imagem da IDE Netbeans, a Figura

8;


https://pt.wikipedia.org/wiki/Python

https://pt.wikipedia.org/wiki/Linguagem_de_programa%C3%A7%C3%A3o_C

https://pt.wikipedia.org/wiki/C%2B%2B

32

Figura 8: IDE Netbeans

Estas são as principais IDE’s utilizadas no mercado da linguagem Java e

todas são muito parecidas. Sendo que o Netbeans é apontado pela maioria dos pro-

gramadores, como a IDE mais fácil para a construção das interfaces gráficas. Interfa-

ces Gráficas são as telas de programas com os componentes para a entrada e saída

de dados. Por este motivo, o programa “Gerenciador de condomínio”, será escrito em

Java SE com o auxílio da IDE Netbeans.

3.2 MICROSOFT OFFICE ACCESS

O banco de dados utilizado neste trabalho será o banco de dados Microsoft

Access (conhecido também com MSAccess), seu nome completo é Microsoft Office

Access. Sua primeira versão de Sistema de Gerenciador de Banco de dados (SGBD)

foi desenvolvida em 1992 pela empresa de software Microsoft [2][15][16].

A escolha por este Banco de dados, parte da simplicidade e a possibilidade

do usuário final poder visualizar também os dados na interface gráfica dele, caso o

usuário queira. E também para o lado do programador, o MSAccess é compatível

33

com os comandos do SQL. O SQL é uma linguagem padronizada de Consulta Estru-

turada no gerenciamento de dados, que interage com os principais bancos de dados

baseados no modelo relacional, o que trará grande facilidades na programação Java.

Com poucas linhas de comando do SQL e outras de Java podem ser feitas consultas,

atualizações, exclusões e inserção no banco de dados [2].

Ainda sobre a escolha do banco MSAccess, para rodar os aplicativos de-

senvolvidos é necessário que o usuário tenha instalado no mínimo em sua máquina,

seu Runtime que vem a ser uma versão enxuta do MSAccess que servirá apenas para

rodar os aplicativos sem a possibilidade de desenvolvimento[16]. Logo abaixo, segue

uma imagem da IDE do Microsoft Access, a Figura 9.

Figura 9: IDE Microsoft Office Access

Um banco de dados tem por finalidade ser um repositório em que se guar-

dam dados para futuras utilizações. O MSAccess é mais do que um simples banco de

dados, é um Sistema de Gerenciamento de Banco de Dados (SGBD), ou seja, além

de ser um banco de dados relacional, também possui uma coleção de ferramentas e

programas que permitem a criação de dados e a manipulação de seus registros (defi-

nição, construção e manipulação de dados).

O MSAccess é um SGBD relacional, quando se diz que um banco de dados

é relacional, se refere a dados que são guardados em tabelas e que têm uma estrutura

34

que se repete a cada linha, que se relacionam por ter campos comuns com outras

tabelas. São os relacionamentos entre as tabelas que as tornam “relacionais”. Con-

sultas, por exemplo, podem ser feitas em tabelas diferentes, criando uma enorme ta-

bela virtual que existe somente para aquela dada consulta[2]. A ilustração abaixo,

Figura 9, foi construída com três tabelas, exemplifica esta relação (a Figura de 10 até

14, foram produzida no MSAccess):

Figura 10: IDE MSACCESS com três tabelas relacionada.

Na própria IDE do MSAccess é possível simular uma consulta para teste.

A ilustração abaixo, a Figura 11, se refere à tabela “Imóvel” construída para o relacio-

namento do exemplo.

35

Figura 11: IDE do MSAccess com a tabela imóvel.

A ilustração abaixo, a Figura 12, se refere à tabela “Proprietária” construída

para o relacionamento do exemplo.

Figura 12: IDE DO MSACCESS com a tabela Proprietário.

A ilustração abaixo, a Figura 13, mostra o comando SQL para a simulação

do teste.

36

Figura 13: IDE DO MSAccess com os comandos SQL.

O comando “SELECT” seleciona dados relacionados de tabelas com certos

critérios. P.Nome, I.localizacao, I.valorTaxaCondominio são atributos das tabelas

“Proprietário” e “Imovel”. As letras “P” e “I” seguidas de um ponto fazem referência às

tabelas. É um recurso da linguagem SQL para representar as tabelas e assim poder

manipular os dados facilmente. No caso acima foi dado à representação para a tabela

“Proprietario” a letra “P” e a tabela “Imovel” a letra “I”. O comando “FROM” tem o

mesmo sentido da preposição “de” em português. Ou seja, diz a quem pertence os

atributos (Proprietário letra “P”, imóvel letra “I”). O comando “WHERE”, que significa

em português “quando” é o critério para a seleção. O exemplo acima vai selecionar os

a tributos mencionados das duas tabelas quando as chaves I.idProp e P.idProp forem

iguais.

A ilustração abaixo, a Figura 14, mostra o resultado da consulta. É formada

uma nova tabela virtual, como abortado no parágrafo acima, que existe somente para

esta consulta.

37

Figura 14: IDE DO MSAccess com resultado de consulta.

O que uniu as tabelas e deu origem a terceira tabela de consulta, foram

chaves do tipo:

Chave primária ou PRIMARY KEY. (PK): É um campo ou campos

(chaves compostas) de valor único que identificam a linha de registro

no bando de dados. A chave primária de uma tabela poderá ser a

chave estrangeira em outra tabela (a ideia de relacionamento, que

unem as informações dita acima);

Chave estrangeira: São chaves primárias de outras tabelas que vão

se relacionar com registro de sua tabela com a qual ele habita;

Chave candidata: São campos que poderiam ser usados como cha-

ves primárias e não são utilizados, como por exemplo, a tabela de

cadastro de proprietário tem um código do proprietário e nesta tabela

tem o campo CPF. Como se sabe o CPF é um registro único e desta

forma poderia ser uma chave candidata a chave primária.

Logo abaixo na Figura 15, segue outro exemplo de relacionamento entre

tabelas, são duas tabelas de banco de dados: Tabela “Pessoa” e tabela “Endereço”.

38

O Desenho de uma chave amarela e com a descrição “idPessoa” na tabela “Pessoa”,

é a chave Primaria desta tabela. Assim como “idEndereco” e chave Primária da tabela

“Endereço”. O desenho de um losango vermelho com a descrição “Pessoa_idPessoa”

é chave estrangeira na tabela endereço.

Figura 15: Tabelas de banco de Dados

3.3 UML

A UML é a sigla de Unified Modeling Language, que em português significa

Linguagem Unificada de Modelagem. Esta linguagem de modelagem que será abor-

dada neste tópico tem uma enorme importância para a modelagem da construção do

software “Gerenciador de Condomínio”. Ela permitirá, com o auxílio de suas proprie-

dades, ter o conhecimento necessário para uma análise e desenvolvimento para os

requisitos das questões inerente ao software. Requisitos são condições ou capaci-

dade com a qual o sistema deve estar de acordo. Existem requisitos funcionais que

representam algo que o sistema deve fazer, uma função esperada do sistema que

39

agregue algum valor a seus usuários e os requisitos não funcionais que definem pro-

priedades e restrições do sistema [2][20].

A UML é uma linguagem para o auxílio do analista de sistema. Este é o

profissional responsável por encontrar a melhor forma de processar informações de

um dado sistema. Essa linguagem é uma representação de forma padronizada de

diagramas e documentos, no qual se visualiza a comunicação de objetos e está fun-

dada na orientação a objeto. A mesma tem o propósito de permitir especificações,

visualizações e documentações para os sistemas.

A Linguagem Unificada de Modelagem representa o software através de

modelos orientados a objetos (documentação). Garante uma melhor visualização do

sistema, agilidade na confecção do programa, especifica comportamento do sistema

entre outros. A ideia parte de questionamentos, como: "O que fazer", "Como fazer",

"Quando fazer" e "Por que deve ser feito".

O conceito da UML teve origem dos três maiores métodos de modelagem,

que são eles: do BOOCH, OMT (Object Modelling Technique, em português significa

técnica para modelagem de objeto) e OOSE (Object-oriented software engineering,

que em português quer dizer, a Engenharia de software orientada a objetos) e foi lan-

çada em 1995 [30]. Mas, a linguagem só foi aprovada como padrão pelo OMG (Object

Management Group), que é um consórcio internacional de empresas que ditam pa-

drões na área de Orientação a Objetos, em 1997 [30].

Os Diagramas da UML estão divididos em Estruturais e Comportamentais.

E são usados para documentar e modelar diversos aspectos de um sistema dentre

este cinco são os mais utilizados que são eles: Diagrama de Caso de Uso; Diagrama

de Classe; Diagramas de interação; Diagrama de Atividades e Diagrama de Compo-

nentes. Para a compreensão deste trabalho, serão abordados sucintamente sobre os

tipos de diagramas UML, com ênfase nos cinco citados acima.

Antes da definição dos diagramas da UML, é importante descrever sobre a

ferramenta que vai auxiliar a “desenhar” os diagramas e assim criar toda a documen-

tação necessária. A ferramenta escolhida é a StarUML, que é uma ferramenta CASE

(do inglês Computer-Aided Software Engineering) de código aberto (opensource) e

está sob a licença GPL (General Public. License), que modela vários tipos de diagra-

mas [1]. É uma ferramenta para o sistema operacional Windows, abaixo segue uma

imagem deste aplicativo, a Figura 16.

40

Figura 16: IDE StarUML

3.3.1 Diagramas Estruturais

São notações gráficas que representam a estrutura de um sistema. Se-

guem abaixo os tipos destes diagramas.

Diagrama de Classe: É o principal diagrama da UML e a partir dele são

feitos outros diagramas. Ele identifica a estrutura mínima de informação. É formado

por atributos, métodos e os relacionamentos entre as classes. Segue abaixo uma Fi-

gura com este tipo de diagrama, a Figura 17.

41

Figura 17: Diagrama de classe

Um diagrama de classe é dividido em três partes, como visto na Figura

acima (um exemplo hipotético). A primeira parte é o nome da classe (“Proprietário”,

“Pagamento” e “Reclamação”, alguns autores não gostam de usar caracteres latinos

como acentos e cedilha.), a segunda parte são os atributos e a terceira parte, os mé-

todos, que executam a comunicação com os objetos.

Diagrama de Objeto: Este tipo de diagrama modela instâncias de objetos,

ou seja, o diagrama de objeto mostra um conjunto de objetos e seus relacionamentos

no tempo. Fornece uma visão dos valores armazenados pelos objetos de um Dia-

grama de Classe em um determinado momento da execução do processo do software.

Segue abaixo um exemplo, a Figura 18, com este tipo de diagrama, onde demonstra

os dados armazenados da proprietária “Yvie Maria” com seus dados de CPF, data de

nascimento, bloco e apartamento. E ainda outras duas instâncias de pagamentos e

seus dados.

42

Figura 18: Diagrama de objeto

Diagrama de Componentes: É utilizado para modelar os dados do código

fonte e seus componentes. Tem por finalidade indicar os componentes do software e

seus relacionamentos. Demonstram a estrutura do sistema de software, que descreve

os componentes do software, suas interfaces e suas dependências. É possível utilizar

diagramas de componentes para modelar sistemas de software em um alto nível ou

para mostrar componentes em um nível de pacote mais baixo. Segue abaixo, a Figura

19, com este tipo de diagrama, onde é demonstrado o componente “Tele de cadastro

Pagamento” conectado com o gerenciador de pagamento através da interface “Ipag”

e gerenciador de pagamento conectado com o componente “SGBD” através da inter-

face “IpagBanco”.

43

Figura 19: Diagrama de Componentes

Diagrama de implantação: Demonstra o relacionamento entre os compo-

nentes de software e hardware do sistema e a distribuição física do processamento.

Segue abaixo um exemplo com este tipo de diagrama, a Figura 20, onde o compo-

nente “Navegador” se relaciona com o “servidor web” e com “servidor de banco de

dados”.

.

Figura 20: Diagrama de Implantação

44

Diagrama de Pacotes (Ou diagrama de módulos): Demonstra as partes

de um sistema divididas em agrupamentos lógicos, deforma a demonstrar as depen-

dências que há entre os pacotes. Segue abaixo uma figura com este tipo de diagrama,

a Figura 21, é um exemplo hipotético pois uma definição vai de acordo com a visão

dos desenvolvedores e dada a necessidade do sistema. Uma leitura dos componentes

abaixo seria que o “grupo lógico pagamento” depende do “grupo lógico morador” e

“grupo lógico Serviço” e “este do grupo lógico Condomínio” que por sua vez depende

do “grupo lógico Morador” para desempenhar suas atividades sistêmicas.

Figura 21: Diagrama de pacote

Diagrama de Estrutura: Auxilia na descrição das estruturas internas das

classes, interfaces ou componentes para especificar uma funcionalidade. Segue

abaixo uma Figura com este tipo de diagrama, a Figura 22. Onde explica as partes

envolvidas para o “Diagnostico”, que depende de funções da classe “Médico”, da

classe “Consulta” e da classe “paciente”. É como se fosse um diagrama de classe,

sendo o diagrama de classe é estático, já o diagrama de estrutura demonstra as fun-

cionalidades.

45

Figura 22: Diagrama de Estrutura

3.3.2 Diagramas Comportamentais

São notações gráficas, com conceitos da UML por exemplo, feito por um

analista. Em que os desenvolvedores também conhecidos com programdores, visu-

alizam alteração de comportamento das classes. Seguem abaixo os tipos destes dia-

gramas:

Diagrama de Caso de Uso (Use Case): Demonstra o que o sistema faz

no ponto de vista do usuário, muito importante para as fases de levantamento e aná-

lise de Requisitos do Sistema. Identifica as funções que um sistema deve ter (casos

de uso) e os responsáveis para utilizar estas funções. Num diagrama de caso de uso

temos o Ator, que no caso da Figura 23 (um exemplo hipotético) é o sindico de um

condomínio (um sistema pode ter diversos atores) e as ações realizadas através do

sistema pelo ator (Síndico). O sindico pode executar o caso de uso “cadastro um pro-

prietário”, executar o caso de uso “consulta lista de inadimplentes”, executar o caso

de uso “cadastra reclamações”, executar o caso de uso “cadastrar pagamentos”.

http://www.infoescola.com/engenharia-de-software/analise-de-requisitos/

http://www.infoescola.com/engenharia-de-software/analise-de-requisitos/

46

Figura 23: Diagrama de Caso de Uso (Use Case)

Diagrama de Estados: Demonstra os estados que os objetos podem as-

sumir e os eventos das transições de um estado para outro. Representam a situação

em que um objeto se encontra em um determinado momento durante o período em

que esse participa de um processo. Abaixo, na Figura 24, um exemplo hipotético, onde

se tem o estado inicial cadastrar pagamento seguindo para o efetuar pagamento. Logo

depois existe a possibilidade de um estado de cancelamento do pagamento ou conti-

nua o pagamento e gera um recibo de pagamento.

Figura 24: Diagrama de Estados

47

Diagrama de Atividades: Demonstra os passos a serem percorridos para

a conclusão de uma atividade. É um gráfico de fluxo, que mostra o fluxo de controle

de uma atividade para outra.

Para os diagramas de interação, temos dois tipos:

Diagrama de Sequência: Demonstra a iteração sequencial na ordem

temporal dos processos em que as mensagens são trocadas entre os

objetos. No exemplo hipotético abaixo, Figura 25, o síndico primeiro faz

uma consulta para localizar o proprietário. Depois retorna os dados ne-

cessários para o pagamento da taxa de condomínio. Por último, o ter-

ceiro caso identificado na figura, o sindico confirma o pagamento, que

será cadastrado no banco de dados pelo método cadastraPagamento()

com os seus devidos atributos.

Figura 25: Diagrama de Sequência

48

4. CASOS DE USO

Para falar sobre os casos de uso do software “Gerenciador de condomínio”

é importante conhecer algumas regras de negócio (estas refletem políticas do negó-

cio) que foram afixadas na análise para o programa. Os casos de uso serão importan-

tes para que se obtenha o conhecimento de alguns dos requisitos funcionais e não

funcionais do programa.

4.1 REGRAS DE NEGÓCIO

Serão relacionadas na tabela 1, algumas regras de negócio da seguinte

forma: Cada regra é formada por uma numeração na coluna “identificação” da tabela

1 e uma sentença na coluna “descrição” da tabela 1. Estas regras de negócio dizem

respeito a uma restrição, afirmação e/ou condição sobre o sistema.

Tabela 1: Algumas regras de negócio

Identificação Descrição

RN001 O código do proprietário é composto por número do aparta-mento e o número do bloco.

RN002 Só existirá um responsável por um apartamento, denominado proprietário.

RN003 A data para pagamento da taxa de condomínio é até o 10º dia de cada mês. Após esta data o proprietário é considerado inadimplente.

RN004 Aos moradores que mantiverem mais de um veículo nos esta-cionamentos do condomínio será comprado acrescentado 30% sobre a taxa de condomínio por cada veículo.

RN005 Será cobrado multa no acrescentado a taxa de condomínio no valor de 30% por cada registro de indisciplina de conduta condominial procedente.

RN006 A taxa para o uso do salão de festa é correspondente a 50% do valor da taxa de condomínio, por cada dia de utilização.

49

4.2 DIAGRAMA DE CASOS DE USO DO “GERENCIADOR DE CONDOMÍNIO”

As imagens abaixo são os casos de uso do “Gerenciador de condominio”

das classes: Pagamento; Proprietário; Morador; Solicitação; Negociação; Veículo. Es-

tas classes foram mencionadas anteriormente no diagrama de classe, visto em outro

capitulo.

Todas estas classes têm caso de usos parecidos, como:

Cadastrar (Pagamento, Proprietário, Morador, Solicitação, Negociação e

Veículo): Será permitido ao ator do caso de uso, denominado síndico ou administrador

do condomínio, realizar cadastro pelo programa.

Editar (Pagamento, Proprietário, Morador, Negociação e Veículo): Será

permitido ao ator do caso de uso, denominado síndico ou administrador do condomí-

nio realizar, alterações no cadastro pelo programa.

Consultar (Pagamento, Proprietário, Morador, Solicitação, Negociação e

Veículo): Será permitido ao ator do caso de uso, denominado síndico ou administrador

do condomínio, realizar consultas simples ou avançadas no cadastro pelo programa.

Gerar relatório (Pagamento, Proprietário, Morador, Solicitação, Negocia-

ção e Veículo): Será permitido ao ator do caso de uso, denominado síndico ou admi-

nistrador do condomínio, realizar relatórios com saídas em arquivo Excel e pela inter-

face gráfica do programa.

Excluir (Pagamento, Proprietário, Morador, Negociação e Veículo): Será

permitido ao ator do caso de uso, denominado síndico ou administrador do condomí-

nio, realizar exclusão pelo programa.

A Figura 26 até a Figura 31 estão relacionadas com os casos de uso infor-

mado acima. Esses casos de usos foram separados por classes, conforme descrição

nas legendas de cada figura.

50

Figura 26: Diagrama de caso de uso da classe Pagamento.

Figura 27: Diagrama de caso de uso da classe Proprietário.

51

Figura 28: Diagrama de caso de uso da classe Morador.

Figura 29: Diagrama de caso de uso da classe Negociação

52

Figura 30: Diagrama de caso de uso da classe Solicitação.

Figura 31: Diagrama de caso de uso da classe Veículo.

Os casos de uso das classes são parecidos, mas com condições em alguns

casos diferentes. Esta observância é notada nas descrições de cada caso de uso que

serão abordadas no tópico seguinte.

53

4.3 DESCRIÇÃO DOS CASOS DE USO

Neste tópico serão demonstradas, nas tabelas de 2 até a tabela 6, detalha-

damente as descrições do principal caso de uso mencionado no tópico anterior que é

“cadastrar pagamento”. As descrições de caso de uso contêm os seguintes itens:

• Nome: Nome dado ao caso de uso (Use case com sigla UC);

• Descrição sucinta: Uma breve descrição de seu objetivo;

• Atores: Identificação dos atores;

• Pré-condições: O que é preciso para que o caso de uso seja realizado;

• O trigger ou gatilho: É a ação que dispara o caso de uso;

• O fluxo principal: Conta uma sequência de eventos que descrevem o

caso normal dos acontecimentos;

• Fluxo alternativo: Explica o que pode ocorrer diferentemente do fluxo

principal e o que deve ser feito quando cada variação ocorre;

• As extensões: Apontam outros casos de uso que podem ser realizados

simultaneamente.

• Pós-condições: Descreve a situação final esperada logo depois de con-

cluído o caso de uso;

• Regras de negócio: As regras de negócio envolvidas na sua realização.

Tabela 2: caso uso 01

UC01: Cadastrar pagamento.

Objetivo: Informar os dados do pagamento ao sistema.

Atores: Síndico, denominado administrador de condomínio.

Pré-condições: Para o cadastro do pagamento é necessário o cadastro

do proprietário.

Trigger: Usuário acessa formulário de cadastro de pagamento.

Fluxo Principal: 1 – O usuário seleciona a opção pagamento.

2 – O usuário informa o código imóvel (ou código pro-

prietário), o sistema retorna os dados do proprietário.

54

3- O usuário informa o mês de referência, o ano de re-

ferência, valor e alguma observação.

4 – O usuário confirma o pagamento no botão salvar.

5 - O sistema questiona “Deseja Salvar”.

6 – O Usuário informa “SIM”.

6 – O sistema retorna “Cadastro salvo”.

Fluxo Alternativo: 2a – O proprietário não é cadastrado.

1 – O sistema informa que o proprietário não foi locali-

zado.

2 – Volta ao passo 1

2b – Pagamento já efetuado.

1 – O sistema informa que já existe um pagamento e

questiona se deseja alterar os dados.

2 – O usuário informa que deseja alterar.

3 – O sistema informa “dados alterados”.

2b1 – O usuário informa que não deseja alterar os da-

dos do pagamento.

1 – O sistema informa “Dados não alterados”.

Extensões: Não há.

Pós Condições: O sistema atualiza a lista de pagamento e o valor total

de pagamentos e informa na tela para o usuário.

Regras de negócio: RN001, RN002, RN003, RN004, RN005


UC02: Editar pagamento

Objetivo: Informar alterações de dados do pagamento ao sis-

tema.


Pré-condições: Para alteração dos dados é necessário o existir cadas-

tro do mesmo


55


2 – O usuário faz o filtro no sistema por "Parte do

nome", ou/ e “Andar", ou/e “Nº Apto”, “Mês” e “Ano”, lo-

caliza o pagamento (dá um duplo click na linha dos da-

dos) o sistema retorna os dados do pagamento no for-

mulário.

3- O usuário informa os dados que deseja alterar.

4 – O usuário confirma a alteração no botão salvar.

5 - O sistema questiona “Deseja alterar”.


7 – O sistema retorna “Alteração feita”.

Fluxo Alternativo: 2a – O usuário desiste de alterar.

1 - O sistema questiona “Deseja alterar”.

2 – O Usuário informa “NÃO”.

3 – O sistema retorna “Alteração não realizada”.






UC03: Consultar pagamento

Objetivo: Obter do sistema informação sobre pagamentos reali-

zados.


Pré-condições: É necessário que exista pagamentos registados no

bando de dados.



56


nome", ou/ e “Andar", ou/e “Nº Apto”, ou/e “Mês” e

“Ano”.

Fluxo Alternativo: Não há.


Pós Condições: Com base na consulta o sistema exibe valor total pago.



UC04: Excluir pagamento.

Objetivo: Excluir um pagamento do bando de dados do sistema.


Pré-condições: É necessário que exista o pagamento registado no

bando de dados.




nome", ou/ e “Andar", ou/e “Nº Apto”, “Mês” e “Ano”, lo-

caliza o pagamento (dá um duplo click na linha dos da-

dos) o sistema retorna os dados do pagamento no for-

mulário.

3 – O usuário confirma a exclusão no botão Excluir.

5 - O sistema questiona “Deseja Excluir”.


7 – O sistema retorna “Exclusão feita”.

Fluxo Alternativo: 2a – O usuário desiste da exclusão.

1 - O sistema questiona “Deseja Excluir”.

2 – O Usuário informa “NÃO”.

3 – O sistema retorna “Exclusão não realizada”.




57



UC05: Gerar relatório de pagamento.

Objetivo: Obter do sistema informação sobre pagamentos reali-

zados.


Pré-condições: É necessário que exista pagamentos registados no

bando de dados.



2 – O usuário faz o filtro no sistema por "Parte do nome",

ou/ e “Andar", ou/e “Nº Apto”, ou/e “Mês” e “Ano”.

3 – O usuário clica no botão “Gerar Excel”.

4 – O sistema questiona aonde deve ser salvo o relató-

rio.

5 – O usuário informa caminho para salva o arquivo e

clica em no botão “ok”.

6 - Sistema informa que o arquivo foi salvo e questiona

se deseja abrir o arquivo.

7 – O usuário informa que sim e visualiza a planilha em

Excel.

Fluxo Alternativo: 2a – O usuário desiste de gerar relatório.

4 – O sistema questiona aonde deve ser salvo o relató-

rio.

5 – O Usuário clica em cancelar

2b – O usuário não deseja visualizar o relatório.

1 - Sistema informa que o arquivo foi salvo e questiona

se deseja abrir o arquivo.

2 - O usuário informa que não.


58

Pós Condições: Não há.


4.4 REQUISITOS

Os requisitos do sistema, assim como casos de uso, são fundamentais para

a construção do software, pois identificam o que de fato o sistema deverá fazer, e

como será sua relação com os usuários. Os requisitos são divididos em dois tipos:

funcionais e não funcionais, sendo os requisitos funcionais divididos, ainda, em dois

tipos: requisitos de usuário e requisitos de sistema.

Os requisitos funcionais estão baseados nos casos de uso, onde os requi-

sitos de usuário apontam diretamente para as necessidades do usuário final, e os

requisitos de sistema indicam o que deve ser feito para que essas necessidades sejam

satisfeitas.

Os requisitos não funcionais fazem referência sobre as restrições e espe-

cificações observadas sobre o ambiente de uso e a complexidade do sistema final.

4.4.1 REQUISITOS FUNCIONAIS

Os requisitos funcionais estão relacionados na Tabela 7, onde cada um tem

uma identificação, um título e uma breve descrição. Os requisitos de sistema, identifi-

cados pelo sufixo “S” e os requisitos de usuário, identificados pela letra “U”.

59

Tabela 7: Requisitos Funcionais

Identificação Requisito Descrição

RF01S Gera có-

digo Propri-

etário

O sistema deve permitir ao usuário gerar o código do proprietário, ao cadastrar um proprietário. Com a se-guinte forma: número do apartamento mais o número do bloco.

RF02U Cadastro

proprietário

O sistema deve permitir ao usuário o cadastrar, consul-

tar, atualizar e excluir de um proprietário

RF03U Cadastro

morador

O sistema deve permitir ao usuário o cadastrar, consul-

tar, atualizar e excluir de um morador, sendo uma com-

posição de proprietário.

RF04U Cadastro

pagamento

O sistema deve permitir ao usuário o cadastrar, consul-tar, atualizar e excluir de um pagamento da taxa de condomínio com o código do proprietário.

RF05S Inserir pa-

gamento.

O sistema só fará um cadastro de pagamento se existir

o cadastro do proprietário

RF06U Cadastra

solicitação.

O Sistema deve permitir o cadastrar, consultar uma re-

clamações, sugestões, elogios e solicitações com o có-

digo do proprietário.

RF07S Inserir soli-

citação.

O sistema não permitirá a alteração e nem exclusão uma

reclamações, sugestões, elogios e solicitações

RF08U Cadastro

Veículo.

O sistema deve permitir o cadastrar, consultar, atualizar

e excluir um veículo de proprietário com o código do pro-

prietário.

RF08S Inserir alte-

rações dos

dados.

O sistema deve armazenar em banco de dados os re-gistros de alterações de dados com a data e hora da al-teração com o log de rede do computador.

RF09S Inserir pa-

gamento.

O sistema só permitirá o registro de somente um paga-

mento para um proprietário com mesmo mês e ano.

RF10S Inserir pro-

prietário.

O sistema permitirá somente um registro de um proprie-

tário por apartamento e vários moradores por aparta-

mento.

60

RF11S Inserir data

e hora cor-

rente.

O sistema ao efetuar um pagamento vai registrar a data e hora corrente.

RF12S Informa

salvo deve-

dor.

O sistema deverá informar em tela ou/e impresso, caso

exista, um valor devedor após a confirmação do paga-

mento do mês corrente.

RF13S Gera relató-

rio.

O sistema deve permitir saídas de relatórios em tela e em arquivo no formato Excel com extensão “. xlsx”.

RF14S Gera per-

missão.

O sistema operará somente em computadores com en-

dereço físico registrado no código do programa.

RF15S Gera mon-

tante arre-

cadado.

O sistema deve informar em tempo real o valor já arre-

cadado para o mês e consultas de datas anteriores.

RF16S Registrar

Alteração

O sistema deve registar em uma tabela do banco de da-

dos alterações feitas no cadastro e exclusões dos ca-

dastros.

4.4.2 REQUISITOS NÃO FUNCIONAIS

Abaixo segue uma tabela com alguns dos requisitos não funcionais do pro-

grama “Gerenciador de condomínio” (Tabela 8). Na primeira coluna a identificação do

requisito com uma sequência numérica, na segunda coluna um título para este tipo de

requisito e na última coluna uma breve descrição sobre ele.

Tabela 8: Requisitos Não Funcionais

Identificação Requisito Descrição

NF01 Fácil instalação. O sistema deverá ser de simples instalação, e também em termos de acesso e uso.

NF02 Sempre disponível O sistema deverá estar disponível a qualquer momento.

61

NF03 Totalmente off-line O sistema não poderá conter qualquer depen-dência da Internet nem de recurso de rede, para funcionamento completo ou parcial.

NF04 Multiplataforma operacional

O sistema deverá ter seu funcionamento para qualquer plataforma de sistema operacional para um desktop.

NF05 Monousuário O sistema deverá implementar recursos para um único usuário, o síndico.

O sistema “Gerenciador de condomínio” foi projetado com o fundamento de

ter simplicidade e facilidade de uso, como descrito no requisito NF01. Os arquivos do

programa ficarão numa pasta e será possível criar um atalho na área de trabalho para

chamar o programa. As telas do programa (interfaces gráficas) são de fácil entendi-

mento (auto sugestivo).

O requisito NF02 foi também outra premissa do software, para que possa

funcionar em um acesso local, pois o aplicativo foi projetado para que seja instalado

na máquina do usuário e não tenha dependência de conexão de rede. Não haverá

interação com outro usuário neste programa.

O requisito NF03 pode se dizer que trata de uma possível eventualidade de

minimizar ou anular o risco de falta de disponibilidade, visto que ele sempre vai estar

disponível, pois não depende de nenhum tipo de serviço de rede.

O requisito NF04 diz respeito à multiplataforma em que é possível instalar

o software. O programa foi desenvolvido em linguagem Java, que tem como uma das

suas propriedades de funcionar em vários sistemas operacionais sem a necessidade

de compilar um novo programa.

O requisito NF05 menciona que o programa foi desenvolvido exclusiva-

mente para o administrador do condomínio ou síndico, sendo assim o programa é para

um único usuário.

62

5. MODELAGEM DO “GERENCIADOR DE CONDOMÍNIO”

Na modelagem do sistema, serão construídos os diagramas que devem

ilustrar os componentes, os estágios e o comportamento do programa “Gerenciador

de condomínio”.

5.1 DIAGRAMA ENTIDADE DE RELACIONAMENTO

Aqui serão identificadas as entidades, seus atributos e suas inter-relações.

Através do material até então coletado e analisado, foi possível identificar os dados

que deverão ser armazenados, e as relações entre eles.

As entidades básicas envolvidas na construção do sistema são: Proprietá-

rio; Pagamento, Solicitação; Morador; Veículo.

A entidade “Proprietário” deve se relacionar com as outras entidades, como

será visto no diagrama de Entidade de Relacionamento abaixo. De acordo com o en-

tendimento das regras de negócio é possível traçar uma descrição sobre as relações

entre as entidades:

Um proprietário possui nenhum ou mais pagamento da taxa do condomínio

registrado.

Um proprietário possui nenhum ou mais solicitação registrada.

Um proprietário possui nenhum ou muitos veículos.

Um proprietário é composto por nenhum ou muitos moradores.

A seguir o diagrama de entidade-relacionamento básico (Figura 32), na ilus-

tração as seguintes grafias: “ (0, *) ” significa “possui/contém nenhum ou um da classe

associada) ” e ou caso (1,1) que significa possui/contém um e um da classe associada)

”.

63

Figura 32: Diagrama Conceitual ER

De acordo com o diagrama conceitual mostrado na Figura acima (Figura

31), as entidades Pagamento, Solicitação, Veículo e Morador tem a cardinalidade (me-

dida de quantos elementos tem no conjunto) 1:1, isto significa que cada Pagamentos,

Solicitação, Veículo e Morador só possui um proprietário, ou seja, elas só existiram se

existir um proprietário.

Abaixo serão relacionados a cada entidade os possíveis dados ou atributos

armazenados nelas, inicialmente teremos:

Proprietário: identificação do proprietário, nome do proprietário, CPF do

proprietário, identidade do proprietário, número do apartamento, número do bloco, te-

lefones de contatos.

Pagamento: identificação do pagamento, CPF do proprietário, identidade

do proprietário, nome do proprietário, data do pagamento.

Solicitação: identificação da solicitação, nome do proprietário, número

apartamento, número do bloco, número de registro, tipo de solicitação.

64

Morador: identificação do morador, nome do morador, CPF do morador,

entidade do morador, número do apartamento, número do bloco, telefones de conta-

tos.

Veículo: identificação do proprietário do veículo, número da placa, marca

do carro, identificação do local para estacionado.

Para satisfazer a análise proposta, será feito o processo de normalização,

que significa: Reorganizando as entidades citadas, os relacionamentos e fazendo uma

redistribuição dos atributos, para preservar a integridade das entidades fundamentais

e preparar a base de dados para o modelo relacional.

Para isso, há a necessidade de se criar novas entidades que chamaremos

de classe, baseadas em relacionamentos, seguem elas:

Classe Pessoa: Será uma classe genérica em que terão alguns atributos

e métodos para as classes Proprietário, classe Morador e classe Funcionário. Servirá

para os benefícios para estas classes, conforme relatado no “capítulo de conceitos”

sobre herança.

Classe Funcionário: Existe a necessidade de ter no projeto um cadastro

de funcionários, como os atributos são os mesmos esta classe vai herdar da classe

Pessoa, evitando assim reescrita de código.

Classe Proprietário: Esta classe também vai herdar da classe Pessoa

seus atributos e métodos, visto que um proprietário é uma pessoa. Esta classe pode

ter nenhum ou vários pagamentos, solicitações, moradores e veículos.

Classe Pagamento: Esta classe será responsável pelos dados do paga-

mento e terá associação com a classe Proprietário, visto que um pagamento tem so-

mente um proprietário.

Classe Solicitação: Esta classe será responsável por registrar os dados

de reclamação, sugestão, elogio ou solicitação de um proprietário. Ela está associada

a classe Proprietário e cada solicitação tem somente um proprietário.

Classe Morador: Esta classe será responsável por registrar dados de um

morador. Ela é uma composição de proprietário e está associada a mesma. Cada

proprietário pode ter nenhum, um ou uma coleção de moradores, porém cada morador

somente terá um proprietário.

65

Classe Veículo: Esta classe será responsável por registrar os dados dos

veículos do proprietário. Ela está associada a classe proprietário e cada veículo tem

somente um proprietário.

As informações das classes acima são ilustradas na Figura 33, logo abaixo

com seus atributos e métodos.

Figura 33: Diagrama de Classes

5.2 FASES DO SISTEMA PARA O CASO DE USO PAGAMENTO

Através da análise do diagrama ER, das regras de negócio e dos requisitos

funcionais foram definidas fases de utilização do sistema para os casos de uso da

classe Pagamento. A ordem em que cada funcionalidade do aplicativo deverá ser exe-

cutada. Cada fase contém um conjunto de pequenas ações centradas no mesmo ob-

jetivo, onde cada fase tem relações diretas ou indiretas umas com as outras formando

um ciclo de utilização. As seis fases essenciais que o sistema deverá implementar são

ilustradas no seguinte diagrama de atividades, ilustrado na Figura 34.

A Figura 33 está dividida em duas colunas. A primeira coluna é a coluna

“Proprietário”, onde se encontram seus subsistemas. A segunda coluna é a coluna

“Pagamento”, onde se encontram os seus subsistemas.

66

Figura 34: Diagrama de fases do sistema

Para o caso de uso cadastrar pagamento dá-se o início pela consulta dos

dados do proprietário. Caso ele não exista pode ser feito o cadastro ou editar o ca-

dastro (ou até mesmo excluir). Depois do retorno com os dados do proprietário são

incluídos no formulário de pagamento outros dados, como: Data do pagamento; Mês

de referência, ano de referência e valor pago. Logo após o pagamento é salvo, a lista

de pagamentos e o valor total dos pagamentos são atualizados.

67

6. PROJETO “GERENCIADOR DE CONDOMÍNIO”

Este capítulo será dedicado à construção das tabelas do banco de dados e

seus tipos de dados. Também será dedicado a interface gráfica do programa “Geren-

ciador de condomínio”, e suas entradas para o sistema.

6.1 MODELAGEM DO BANCO DE DADOS

O banco de dados utilizado no projeto será o Microsoft Access, no formato

de arquivo accdb. Na Figura 35 é representado o modelo de tabelas, com seus cam-

pos e tipos de valores a serem guardados pelo banco de dados da aplicação.

Figura 35: Interface gráfica do Access com as Tabelas do programa

68

Com o propósito de facilmente identificar dados para o usuário do programa

Gerenciador de Condomínio (o síndico) e gerar relatórios também pelo Access facil-

mente dos dados cadastrados, a modelagem do banco de dados do programa não foi

normalizada permanecendo alguns campos redundantes nas tabelas.

Para o projeto “Gerenciador de condomínio” teremos as seguintes tabelas:

Pagamento (Tabela 9), Proprietario (Tabela 10), Morador (Tabela 11), Solicitacao (Ta-

bela 12), Negociacao(Tabela 13), Veiculo(Tabela 14), Funcionario (Tabela 15), e His-

toricoDeAlteracoes (Tabela 16), Cada tabela recebeu sua respectiva chave primária.

A seguir serão demonstrados os tipos e os tamanhos máximos dos dados que serão

mantidos no banco de dados, assim como o valor padrão ou a faixa de valores espe-

rados pelo sistema para cada campo, e uma breve descrição:

Tabela 9: Tabela Pagamento

Tabela Pagamento

Campo Tipo / Tamanho Valor padrão Descrição

Código Inteiro - Numeração Automá-

tica, servirá como um

identificador extra.

codApBloco Inteiro apartProprietario+

blocoProprietario

Para o código do imó-

vel, conforme a RN, o

código do imóvel será a

concatenação do nú-

mero do apartamento

com o número do bloco

do proprietário.

CPFProprietario Caracteres (11) - Para o CPF do proprie-

tário

IdentidadeProprieta-

rio

Caracteres (15) - Para a identidade do

proprietário.

nomeProprietario

Caracteres (40) - Para o nome do propri-

etário.

69

apartProprietario Inteiro [101/102/103/104

/201/202/203/204

/301/302/303/304/

401/402/403/404/

501/502/503/504]

Para a número do apar-

tamento.

blocoProprietario Inteiro [0 - 50] Para a número do

bloco.

mesReferencia Caracteres (10) [Janeiro / Fevereiro / Março / Abril / Maio/

Junho/

Julho/

Agosto/

Setembro/

Outubro/

Novembro/

Dezembro]

Lista para a seleção de

possíveis valores para

o mês de vai correspon-

der ao pagamento.

anoReferencia Caracteres (4) [“AAAA”] Para o ano de referên-

cia de pagamento.

valorPago Decimal - Para o valor pago da

taxa de condomínio.

dataPagamento Caracteres (10) [“DD-MM-AAAA

hh:mm:ss”]

Para a data e hora do

pagamento da taxa de

condomínio.

obsPagamento Caracteres - Para alguma anotação

extra.

Tabela 10: Tabela Proprietario

Tabela Proprietario:


70

Codigo Inteiro - Numeração Automá-



codApBloco Inteiro apartProprieta-

rio+blocoProprie-

tario



código do imóvel será

a concatenação do

número do aparta-

mento com o número

do bloco do proprietá-

rio.

CPFProprietario Caracteres (11) - Para o CPF do propri-

etário

IdentidadeProprietario Caracteres (15) - Para a identidade do

proprietário.

nomeProprietario Caracteres (40) - Para o nome do pro-

prietário.

dataNascProprietario Caracteres (10) [“DD-MM-AAAA”] Para a data do nasci-

mento do proprietário.

apartProprietario Inteiro [101/102/103/104

/201/202/203/204

/301/302/303/304

/

401/402/403/404/

501/502/503/504]

Para a número do

apartamento.

blocoProprietario Inteiro [0 - 50] Para a número do

bloco.

telefone1Proprietario Caracteres (15) Para o primeiro tele-

fone do proprietário

telefone2Proprietario Caracteres (15) - Para o segundo tele-


71

telefone3Proprietario Caracteres (15) - Para o terceiro tele-


obsProprietario Caracteres - Para alguma anota-

ção extra.

Tabela 11: Tabela Morador

Tabela Morador


Codigo Inteiro - Numeração Automática,

servirá como um identifi-

cador extra.

codApBloco Inteiro apartProprieta-

rio+blocoProprieta-

rio

Para o código do imóvel,

conforme a RN, o código

do imóvel será a concate-

nação do número do apar-

tamento com o número do

bloco do proprietário.

CPFMorador Caracteres (11) - Para o CPF do morador

IdentidadeMo-

rador

Caracteres (15) - Para a identidade do mo-

rador.

nomeMorador Caracteres (40) - Para o nome do morador.

dataNascMora-

dor

Caracteres (10) [“DD-MM-AAAA”] Para a data do nasci-

mento do proprietário.

apartamento-

Morador

Inteiro [101/102/103/104

/201/202/203/204

/301/302/303/304/

401/402/403/404/

501/502/503/504]

Para a número do aparta-

mento.

blocoMorador Inteiro [0 - 50] Para a número do bloco.

telefone1Mora-

dor

Caracteres (15) Para o primeiro telefone

do morador.

72

telefone2Mora-

dor

Caracteres (15) - Para o segundo telefone

do morador.

telefone3Mora-

dor

Caracteres (15) - Para o terceiro telefone do

morador.

obsMorado Caracteres - Para alguma anotação ex-

tra.

Tabela 12: Tabela Solicitacao

Tabela Solicitacao


Codigo Inteiro - Numeração Automática,


cador extra.

CodImovel Inteiro apartProprieta-

rio+blocoProprieta-

rio







Proprietario Caracteres (40) - Para o nome do proprietá-

rio.

Morador Caracteres (40) - Para o nome do morador.

Apto Inteiro [101/102/103/104

/201/202/203/204

/301/302/303/304/

401/402/403/404/

501/502/503/504]


mento.

Bloco Inteiro [0 - 50] Para a número do bloco.

DtResgistro Caracteres (10) [“DD-MM-AAAA”] Para a data do registro da

solicitação.

73

NRegistro Inteiro - Para o número do atendi-

mento.

Tipo Caracteres (10) [Solicitação / Reclamação / Elogios]

Lista para a seleção de

possíveis valores para o

tipo de solicitação.

Obs Caracteres - Para alguma anotação ex-

tra.

Tabela 13: Tabela Negociacao

Tabela Negociacao


Código Inteiro - Numeração Automática,


cador extra.


rio+blocoProprieta-

rio







Proprietario Caracteres (40) - Para o nome do proprietá-

rio.

Morador Caracteres (40) - Para o nome do morador.

Apto Inteiro [101/102/103/104

/201/202/203/204

/301/302/303/304/

401/402/403/404/

501/502/503/504]


mento.

Bloco Inteiro [0 - 50] Para a número do bloco.

74

DtResgistro Caracteres (10) [“DD-MM-AAAA”] Para a data do registro da

negociação.

Valorpago Decimal - Para o valor pago de débi-

tos de taxa de condomí-

nio.


tra.

Tabela 14: Tabela Veiculo

Tabela Veiculo


Código Inteiro - Numeração Automá-




rio+blocoProprieta-

rio



código do imóvel será a

concatenação do nú-

mero do apartamento

com o número do bloco

do proprietário.

Proprietario Caracteres (40) - Para o nome do propri-

etário.

Morador Caracteres (40) - Para o nome do mora-

dor.

Apto Inteiro [101/102/103/104

/201/202/203/204

/301/302/303/304/

401/402/403/404/

501/502/503/504]

Para a número do apar-

tamento.

75

Bloco Inteiro [0 - 50] Para a número do

bloco.

Tel1 Caracteres (15) Para o primeiro tele-

fone do morador.

Tel2 Caracteres (15) - Para o segundo tele-

fone do morador.

Tel3 Caracteres (15) - Para o terceiro telefone

do morador.

Placa Caracteres (8) - Para a placa do carro.

Marca Caracteres (15) - Para a marca do carro.

LocalDeEscacio-

namento

Caracteres (8) - Para a identificação do

local aonde o carro po-

derá ficar estacionado.

Obs Caracteres - Para alguma anotação

extra.

Tabela 15: Tabela Funcionario

Tabela Funcionario


Código Inteiro - Numeração Automática,

servirá como um identifica-

dor.

CPF Caracteres (11) - Para o CPF do funcionário.

Identidade Caracteres (15) - Para a identidade do funci-

onário.

Nome Caracteres (40) - Para o nome do funcioná-

rio.

DtNasc Caracteres (10) [“DD-MM-AAAA”] Para a data de nascimento

do funcionário.

76

Funcao Caracteres (20) - Para a descrição da função

do funcionário.

Salario Decimal - Para o valor do salário do

funcionário.

Tel1 Caracteres (15) Para o primeiro telefone do

morador.

Tel2 Caracteres (15) - Para o segundo telefone do

morador.

Tel3 Caracteres (15) - Para o terceiro telefone do

morador.


tra.

Tabela 16: HistoricoDeAlteracoes

Tabela HistoricoDeAlteracoes


CódigoAccess Inteiro - Numeração Automática,

servirá como um identifica-

dor extra.

CodImovel Inteiro - Identificação do imóvel no

cadastro.

Campo Caracteres (60) - Nome do campo alterado

ou dos campos excluídos.

ValorAnterior Caracteres (60) - Valor antes da alteração

ou valores antes da exclu-

são.

ValorPosterior Caracteres (60) - Valor após da alteração ou

valores após da exclusão.

DataHora Caracteres (10) [“DD-MM-AAAA”] Para a data da alteração

ou da exclusão.

77

6.2 INTERFACE GRÁFICA DO “GERENCIADOR DE CONDOMÍNIO”.

Neste tópico serão apresentadas imagens das telas gráficas do projeto

“Gerenciador de condomínio”, ou seja, o esboço das telas de interface que serão usa-

das na aplicação pelo usuário, o síndico. Serão especificados os principais compo-

nentes utilizados na interação com o usuário final.

O sistema contará basicamente com sete telas, a primeira será a tela de

pagamento (Figura 36), a segunda tela de cadastro do proprietário (Figura 37), a ter-

ceira tela de cadastro do morador (Figura 38), a quarta tela de cadastro de solicitação

(Figura 39), a quinta tela de cadastro de negociação de débitos (Figura 40), a sexta

tela de cadastro de veículo (Figura 41) e a sétima tela de cadastro de funcionário

(Figura 42).

Os principais componentes de interação serão enumerados e especifica-

dos na figura da “Tela de cadastro de pagamento”, especificados quanto ao tipo, suas

propriedades, a gama de dados aceitáveis, e a qual campo do banco de dados ele se

refere, se for o caso.

Serão especificados os principais componentes da tela de cadastro de pa-

gamento. As outras telas serão demonstradas também, mas sem as identificações,

pois elas têm uma certa semelhança, o que faz ser auto sugestivo a compreensão de

seus componentes, com o que será dito no exemplo da tela de cadastro de paga-

mento.

78

Figura 36: Tela de cadastro de pagamento

1 – Botão “Cadastro de Pagamento”, que aciona a tela de cadastro de pa-

gamento.

2 – Botão “Salvar”, que acionado verifica se o pagamento existe no banco

de dados. Caso sim, atualiza com a confirmação do usuário e cadastra um registro de

alteração na tabela chamada “HistoricoDeAteracoes, mas caso não exista no banco

de dados, cadastra o novo pagamento com a confirmação do usuário.

3 – Botão “Limpar”, que quando acionado limpa as informações do formu-

lário pagamento.

4 – Botão “Excluir”, que quando acionado exclui do banco de dados o pa-

gamento que consta no formulário de pagamento e cadastra um registro de alteração

na tabela chamada “HistoricoDeAteracoes”.

5 – Botão “banco Access”, que quando acionado abre a interface gráfica do

Access com as tabelas do programa “Gerenciador de condomínio”.

79

6 – Botão “Gera relatório em Excel”, que quando acionado gera um relatório

da tabela (26) feita com os filtros das listas de componentes (de 20 a 25), salva em

local desejado pelo usuário e abre logo após a confirmação caso o usuário queira.

7 – Caixa de texto não editável, que informa o valor total de pagamentos

com base nos filtros das listas de componentes (20 a 25). O valor inicial é o valor do

mês e ano corrente.

8 - Caixa de texto não editável, que informa mês e ano da pesquisa feita

com os filtros das listas de componentes (de 20 a 25). Esta informação tem relação

com o número 7. O valor inicial é o valor do mês e ano corrente.

9 – Caixa de texto editável, valores numéricos de 5 dígitos, valor inicial é

vazio. Com o valor digitado após teclado enter é retorna alguns valores para o formu-

lário do proprietário. O valor deste campo está associado a campo [codApBloco] do

banco de dados.

10 – Caixa de texto não editável, para valores alfanuméricos de até 40 dí-

gitos, valor inicial é vazio. Ela recebe o valor [nomeProprietario] do banco de dados,

após a consulta feita no caso 9.

11 – Área de texto editável, para valores alfanuméricos, valor inicial é vazio.

Ela está associada ao campo [obsPagamento] do banco de dados.

12 – Caixa de texto não editável, para valores numéricos, valor inicial é

vazio. Ela recebe o valor [apartProprietario] do banco de dados, após a consulta feita

no caso 9.

13 - Caixa de texto não editável, para valores numéricos, valor inicial é

vazio. Ela recebe o valor [blocoProprietario] do banco de dados, após a consulta feita

no caso 9.

14 - Caixa de texto não editável, para valores numéricos, valor inicial é va-

zio. Ela recebe o valor [CPFProprietario] do banco de dados, após a consulta feita no

caso 9.

80

15 - Caixa de texto não editável, para valores numéricos, valor inicial é va-

zio. Ela recebe o valor [IdentidadeProprietario] do banco de dados, após a consulta

feita no caso 9.

16 – Lista de texto com os meses do ano não editável, valor inicial é o mês

corrente. Ela está associada ao campo [mesReferencia] do banco de dados.

17 – Lista de texto com o período dos quatro últimos anos e ano atual + 1,

ela é editável para o caso de pagamentos fora do período. Valor inicial é o ano cor-

rente. Ela está associada ao campo [anoReferencia] do banco de dados.

18 - Caixa de texto editável, para valores alfanuméricos, valor inicial é a

data e o ano corrente para a confirmação do pagamento. Ela está associada ao campo

[dataPagamento] do banco de dados.

19 – Caixa de texto editável, para valores numéricos, valor inicial é vazio.

Ela está associada com o campo [valorPago] do banco de dados.

20 – Caixa de texto editável, para valores alfanuméricos, valor inicial é va-

zio. Ela está associada a consulta por nome do proprietário ao campo [nomeProprie-

tario] do banco de dados.

21 – Lista de opções não editável, tipo fixo de valores: [“1”, “2”, “3”, ”4”, ”5”].

Ela está associada a consulta pelo primeiro digito do código do imóvel, ao campo

[codApBloco] do banco de dados.

22 – Lista de opções não editável, tipo fixo de valores: [“101”, ”102”, ”103”,

”104”,201”,”202”,”203”,”204”,“301”,”302”,”303”,”304”,”401”,”402”,”403”,”404”,”501”,”50

2”,”503”,”504”]. Ela está associada a consulta por número do apartamento do proprie-

tário, ao campo [apartProprietario] do banco de dados.

23 - Lista de opções não editável, tipo fixo de valores: [“1” até “50”]. Ela está

associada a consulta por número do bloco do apartamento do proprietário, ao campo

[blocoProprietario] do banco de dados.

81

24 - Lista de opções não editável, tipo fixo de valores: [“Janeiro”, “Feve-

reiro”, “Março”, “Abril”, “Maio”, “Junho”, “Julho”, “Agosto”, ”Setembro”, ”Outubro”, ”No-

vembro”, ”Dezembro”]. Ela está associada a consulta por mês de referência do paga-

mento, ao campo [mesReferencia] do banco de dados.

25 - Lista de opções editável, tipo fixo de valores: [com o período dos quatro

últimos anos e ano atual + 1, ela é editável para o caso de pagamentos fora do perí-

odo]. Ela está associada a consulta por ano de referência do pagamento, ao campo

[anoReferencia] do banco de dados.

26 - Tabela de pagamentos não editável, seus valores são formados com

a consulta da tabela Pagamento do banco de dados, consultas feitas com os filtros

dos componentes de 20 a 25. Tabela de pagamentos ainda possui uma outra função,

quando é dado um dublo clique em uma linha da tabela é feita uma consulta no banco

de dados com base no dado da coluna zero da linha clicada. Os dados desta consulta

serão distribuídos nos campos do formulário de pagamento conforme correspondên-

cia já mencionada acima.

Um guia rápido de como utilizar as telas do programa “Gerenciador de con-

domínio” pode ser visto no tópico “Apêndice” deste trabalho. Lá se encontra um ma-

nual de como utilizar o programa. Seguem abaixo as outras seis telas do programa:

82

Figura 37: Tela de cadastro de proprietário

Figura 38: Tela de cadastro de morador

83

Figura 39: Tela de cadastro de solicitação

Figura 40: Tela de cadastro de negociação

84

Figura 41: Tela de cadastro de veículo

Figura 42: Tela de cadastro de funcionário

85

7. CONCLUSÃO E TRABALHOS FUTUROS

Este trabalho apresentou um software de gerenciamento para condomínio,

no qual seu único usuário é o síndico. Através desta simples e prática ferramenta, é

possível que o síndico possa fazer cadastros, gerar vários tipos de relatórios e inúme-

ras consultas. Sendo assim, uma ferramenta muito funcional.

As funcionalidades de consultas e de gerar relatórios são funções impor-

tantes que vão auxiliar na tomada de decisões do síndico e ainda obter informativos

para os murais e e-mails dos condomínios.

As funções construídas atendem aos requisitos de usuário, as regras de

negócio, e a proposta inicial de ser uma ferramenta simples e leve. O visual elaborado

é agradável, intuitivo e auto sugestivo.

O desenvolvimento do software “Gerenciador de Condomínios” vai permitir

o gerenciamento administrativo de um condomínio. Este aplicativo será capaz de man-

ter dados de cada proprietário, seus veículos e seus moradores. O programa é de

simples manuseio, pois tem interfaces amigáveis.

Este projeto partiu da necessidade de um condomínio do bairro do Rio de

Janeiro, que a princípio era só para o cadastro de pagamentos. Logo após uma con-

versa informal com o síndico, que se queixava que os dados de pagamento e dados

pessoais dos condôminos ficavam anotados em blocos de papel e não se tinha um

controle ágil para os mesmos. Tentaram criar planilhas no Excel, sem sucesso.

O Programa “Gerenciador de condomínio” é um software “portátil”, não ne-

cessita de instalação; é só manter alguns arquivos em uma pasta e o usuário cria um

atalho na área de trabalho. Este trabalho de conclusão de curso teve como objetivo

mostrar as fases de construção de um software que vai da análise de pré-requisito até

a implantação na máquina do cliente.

Foi apresentado soluções para as dificuldades de gerenciar os dados de

um condomínio; soluções para se ter com agilidade os dados necessários para cada

ocasião. E assim, o síndico conseguir gerenciar com sucesso o condomínio.

Um programa é um objeto modelado e que pode, ao longo do tempo, ter

outras implementações de melhoria. Assim, o “Gerenciador de condomínio” poderia

ser implementado com o seguinte caso de uso: o desenvolvimento da funcionalidade

86

“Portaria eletrônica”, que funcionaria da seguinte forma: Um visitante de um morador

ao acionar um botão na portaria correspondente a um morador, este receberia uma

mensagem em seu celular e que responderia permitindo ou não a entrada do morador.

Poderia ser implementado também o controle das despesas do condomínio, possibi-

litando a criação de uma tela que informasse um balancete financeiro. E ainda a im-

plementação de um cadastro para os fornecedores.

Essas melhorias poderão ocorrer com o Programa “Gerenciador de condo-

mínio”. Novas “necessidades” e ferramentas de facilidades poderão ser implementa-

das pelo desenvolvedor. Este projeto apresenta uma versão inicial, que deverá ser

continuada, aprimorada e ampliada com mais funcionalidades, implementando even-

tuais mudanças nas regras de negócio, e naturalmente, expandindo o alcance para

outras plataformas computacionais, como sistemas móveis, integração com a web e

compatibilidade com outros sistemas operacionais, para que outros tipos usuários,

como os moradores, se beneficiem das suas aplicações

87

REFERÊNCIAS BIBLIOGRÁFICAS

1. ABOUT StarUML. StarUml. Disponivel em:

<http://staruml.sourceforge.net/v1/about.php>. Acesso em: 16 fevereiro 2016.

2. ALVES, W. P. Estudo dirigido de Microsoft Office Access 2010. São Paulo:

Érica, 2010.

3. AMBIENTE de desenvolvimento integrado. Wikipédia. Disponivel em:

<https://pt.wikipedia.org/wiki/Ambiente_de_desenvolvimento_integrado>.

Acesso em: 13 fevereiro 2016.

4. ASSIST SOFTWARE & SERVIÇOS. Assist Software & Serviços. Disponível

em: <http://www.assist.inf.br/solucoes/software-condominio/adcond-basic>.

Acesso em: 15 junho 2016.

5. ATRIBUIÇÕES do Síndico. Sindiconet. Disponivel em:

<http://www.sindiconet.com.br/6825/Informese/Atribuioes-do-Sindico/O-que-

pode-e-o-que-nao-pode>. Acesso em: 13 fevereiro 2016.

6. BARNES, D. J. Programação Orientada a objetos com Java: Uma introdução

prática usando o Bluej. 4ª. ed. São Paulo: Pearson, 2009.

7. BÖCK, H. The definitive guide to NetBeans platform. New York: Apress,

2012.

8. EMPREENDEDORES criam software que ajuda síndico a admi-nistrar

condomínio. Estadão. Disponivel em:

<http://pme.estadao.com.br/noticias/noticias,empreendedores-criam-software-

que-ajuda-sindico-a-administrar-condominio,1832,0.htm>. Acesso em: 23

fevereiro 2016.

9. JAVA e Orientação a Objetos. CAELUM. Disponivel em:

<https://www.caelum.com.br/apostila-java-orientacao-objetos/ >. Acesso em:

12 fevereiro 2016.

10. JAVA ESSENCIAL – PRESENCIAL. 4JAVA. Disponivel em:

<http://4java.com.br/course/java-essencial-2>. Acesso em: 14 fevereiro 2016.

88

11. LINS DE VASCONCELOS, A. M. et al. CIN. Disponivel em:

<http://www.cin.ufpe.br/~if720/downloads/Mod.01.MPS_Engenharia&Qualidad

eSoftware_V.28.09.06.pdf>.

12. LOBO, E. J. R. Curso de engenharia de software - Métodos e pro-cessos

para garantir a qualidade no desenvolvimento de software. São Paulo:

Digerati Books, 2008.

13. MÁQUINA virtual Java. Wikipédia. Disponivel em:

<https://pt.wikipedia.org/wiki/M%C3%A1quina_virtual_Java>. Acesso em: 13

fevereiro 2016.

14. MATOS, A. V. D. ML: prático e descomplicado. 3ª. ed. São Paulo: Erica, 2003.

15. MICROSOFT Access 2013 Runtime. MICROSOFT. Disponivel em:

<https://www.microsoft.com/pt-br/download/details.aspx?id=39358>. Acesso

em: 02 março 2016.

16. MICROSOFT Access. Wikipédia. Disponivel em:

<https://pt.wikipedia.org/wiki/Microsoft_Access>. Acesso em: 13 fevereiro

2016.

17. O que é UML e Diagramas de Caso de Uso: Introdução Prática à UML.

Devmedia. Disponivel em: <http://www.devmedia.com.br/o-que-e-uml-e-

diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408>. Acesso em: 16

fevereiro 2016.

18. PEREIRA, C. M. D. S. Instituições de direito civil. Rio de Janeiro: Forense,

2001.

19. PEREIRA, C. M. D. S. Instituições de direito civil. Rio de Janeiro: Forense,

2001.

20. RAMOS, P.; FARINHA, J. UML: Diagramas de Classes – Dese-nho de Bases

de Dados Relacionais com UML, 2007. Disponivel em: <http://home.iscte-

iul.pt/~ipxa/FBD/fich/DiagClasses.pdf>. Acesso em: 19 fevereiro 2016.

21. SANTOS, R. D. Introdução à Programação Orientada a Objetos usan-do Java,

2001. Disponivel em:

89

<https://hudsoncosta.files.wordpress.com/2011/06/introducao-a-programacao-

orientada-a-objetos-usando-java.pdf>. Acesso em: 26 fevereiro 2016.

22. SCOND. Scond. Disponivel em: <http://www.scond.com.br/>. Acesso em: 23

fevereiro 2016.

23. SIN - Sistema de Gestão de Condomínios. Incodev. Disponivel em:

<http://www.sistemacondominioonline.com.br/ >. Acesso em: 16 fevereiro

2016.

24. SOFTWARE ajuda síndico a administrar condomínio. SeuCondominio.

Disponivel em: <https://www.seucondominio.com.br/midia/software-ajuda-

sindico-a-administrar-condominio-sebrae>. Acesso em: 23 fevereiro 2016.

25. SOFTWARE para Condomínio. ACOLWeb. Disponivel em:

<http://www.acolweb.com.br/funcionalidades.html>. Acesso em: 23 fevereiro

2016.

26. SOUSINDICO. Sousindico. Disponivel em: <http://www.sousindico.com.br/>.


27. THE Java™ Tutorials. ORAGLE. Disponivel em:

<https://docs.oracle.com/javase/tutorial/java>. Acesso em: 12 fevereiro 2016.

28. UCHINAKA, F. Em uma década, número de moradias aumenta mais que o

dobro que o crescimento da população. UOL, 2011. Disponivel em:

<http://noticias.uol.com.br/cotidiano/ultimas-noticias/2011/04/29/em-uma-

decada-numero-de-moradias-aumenta-mais-que-o-dobro-que-o-crescimento-

da-populacao.htm>. Acesso em: 10 fevereiro 2016.

29. VARGAS, C. D. S. A história de UML e seus diagramas. Disponivel em:

<https://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf>.


30. XEXÉO, G. Modelagem de Sistemas de Informação: da análise. California:

Creative Com-mons, 2007.

90

APÊNDICE

Neste tópico será mencionado sobre a importância de ser fazer uma boa

analise de projeto, utilizando boas práticas, com a leitura de um gráfico sobre o as-

sunto. E ainda terá o guia rápido do usuário para o “Gerenciador de condomínio”.

APÊNDICE A - GRÁFICO DE ERRO DE CUSTO DE CORREÇÃO.

O gráfico abaixo ilustra a importância de uma boa análise inicial para

que não ocorra problemas futuros, visto que erros acarretam custos extras para o

projeto. Um erro na "especificação" é mais custoso porque terá de ser refeito parte do

projeto (ou até mesmo todo o projeto e codificação). O referido gráfico apresenta o

custo de corrigir erros associados com cada etapa do processo de desenvolvimento

de software.

Estudos realizados mostram que, cerca de 40% dos erros cometidos, ocor-

rem na etapa de especificação de requisitos do sistema. Como esses erros são os

mais caros de consertar, a correção de problemas oriundos da etapa de especificação

atinge um patamar de 66% do custo total de correção de erros do projeto [11].

91

Gráfico 1: Erros e custo de correção

APÊNDICE B – GUIA RÁPIDO DO USUÁRIO

Este guia foi feito para o síndico. É um pequeno manual simples de como

utilizar o software “Gerenciar de condomínio”. Uma versão com poucas implementa-

ções do programa poderá ser baixada no seguinte link:

https://1drv.ms/u/s!AiGlB31uwiVYhiyWpqXcrOL6WeJl

TELA DE CADASTRO DE PAGAMENTO

A primeira tela do programa é a tela de cadastro de pagamento. Nela será

possível: Cadastrar, consultar, atualizar e excluir dados de pagamento da taxa de con-

domínio. Na Figura 43 logo abaixo, foram enumerados alguns casos importantes para

o guia rápido do programa. Os demais casos são auto sugestivos.

92

Figura 43: Tela de pagamentos

1 – No Menu chamado “Ações”, possui uma função “criar atalho na área de

trabalho” que vai criar um atalho na área de trabalho do computador para o programa

“Gerenciador de condomínio".

2 – Aba “Cadastro de Pagamento” nela será possível: Cadastrar pagamen-

tos da taxa de condomínio, também consultar, alterar, excluir e gerar relatórios refe-

rentes aos dados do pagamento da taxa de condomínio.

3 – Os botões, da esquerda para direita são: Botão Salvar pagamento; Bo-

tão limpar formulário de pagamento; Botão Excluir do banco de dados o pagamento

que está no formulário; botão abrir a interface gráfica do Access do banco de dados;

Botão gerar relatório em Excel da pesquisa feitas com os filtros na opção 8 e vista na

tabela opção 9.

4 – Informação sobre o montante pago, que é gerado com base na pesquisa

dos filtros (identificados no número 7). Como padrão os filtros ficam com o mês e ano

corrente, sendo assim é exibida a pesquisa e o valor total de pagamentos do mês e

ano atual.

5 – Campo para ser digitado o código do imóvel para a consulta e trazer o

cadastro do proprietário para o formulário. Digita-se o código e dá enter.

93

6 e 7 – Campos de mês e ano de referência para o pagamento. Por default

o software deixa mês e ano corrente para facilitar o cadastro. Assim como ocorre nos

filtros (7).

8 – Área de Filtros para pesquisas e, com base neles, é feito o cálculo do

montante e a base para gerar relatórios (botão gerar relatório em Excel). Por default

é feito a pesquisa do mês e ano corrente.

9 – Tabela com os dados da pesquisa, também possui a facilidade de, ao

dar um dublo click em uma linha referente aos dados de um pagamento, estas infor-

mações passam para o formulário, podendo assim serem alteradas.

Obs.: Uma condição inicial é que para se fazer um pagamento é necessário

ter o proprietário cadastrado.

TELA DE CADASTRO DE PROPRIETÁRIO

A segunda tela do programa é a tela de cadastro de proprietário. Nela será

possível: Cadastrar, consultar, atualizar e excluir dados de um proprietário. Na Figura

44 logo abaixo, foram enumerados alguns casos importantes para o guia rápido do

programa. Os demais casos são auto sugestivos.

94

Figura 44: Tela de cadastro de proprietário

1 – Na aba “Cadastro de Proprietário” será possível: Cadastrar os proprie-

tários do condomínio, consultar, alterar, excluir e gerar relatórios referente aos dados

do proprietário.

2 – Os botões, da esquerda para direita são: Botão Salvar cadastro do pro-

prietário; Botão limpar formulário do cadastro do proprietário; Botão Excluir do banco

de dados o cadastro do proprietário que está no formulário; botão abrir a interface

gráfica do Access do banco de dados; Botão gerar relatório em Excel da pesquisa

feitas com os filtros na opção 4 e vista na tabela opção 5.

3 – Campo de Consulta pelo cadastro do proprietário: Digita-se o código do

imóvel e dá enter.

4 – Área de Filtros para pesquisas e com base neles é possível se obter

vários tipos de relatórios.

5 – Tabela com os dados da pesquisa, também possui a facilidade de ao

dar um dublo click em uma linha referente aos dados de um proprietário, estas infor-

mações passam para o formulário, podendo assim serem alteradas.

95

TELA DE CADASTRO DE MORADORES

A terceira tela do programa é a tela de cadastro de moradores. Nela será

possível: Cadastrar, consultar, atualizar e excluir dados de um proprietário. Na Figura

45 logo abaixo, foram enumerados alguns casos importantes para o guia rápido do

programa. Os demais casos são auto sugestivos.

Figura 45: Tela de Cadastro de Morador

1 – Na aba “Cadastro de Morador” será possível: Cadastrar os moradores

do proprietário também consultar, alterar, excluir e gerar relatórios referente ao cadas-

tro de moradores.

2 – Os botões, da esquerda para direita são: Botão Salvar cadastro do mo-

rador; Botão limpar formulário do cadastro do morador; Botão Excluir do banco de

dados o cadastro do morador que está no formulário; botão abrir a interface gráfica do

Access do banco de dados; Botão gerar relatório em Excel da pesquisa feitas com os

filtros na opção 6 e vista na tabela opção 7.

96

3 – Botão que cria uma linha na “tabela de moradores do proprietário” para

que seja possível cadastrar um novo morador. Os dados devem ser inseridos no ce-

lular desta tabela.

4 – Campo de Consulta pelo cadastro do morador: Digita-se o código do

imóvel e dá enter.

5 – Tabela editável de cadastro de moradores do proprietário.

6 – Área de Filtros para pesquisas e com base nela é possível se obter

vários tipos de relatórios dos dados do morador.

7 – Tabela com os dados da pesquisa, também possui a facilidade de ao

dar um dublo click em uma linha referente aos dados de um proprietário, estas infor-

mações passam para o formulário do morador, podendo assim serem alteradas.

Abaixo seguem as seguintes telas do programa: Tela de cadastro de soli-

citação (Figura 46); Tela de cadastro de negociação (Figura 47); Tela de cadastro de

veículo (Figura 48) e Tela de cadastro de funcionário (Figura 49), respectivamente.

Todas possuem as formas de cadastro parecidas com as mencionadas anteriormente

e são altamente sugestivas. Por este motivo não serão descritas em detalhes como

as outras.

Figura 46: Cadastro de solicitação

97

Figura 47: Cadastro de negociação

Figura 48: Cadastro de veículo

98

Figura 49: Cadastro de funcionário

universidade federal fluminense bruno edeildes … · ficha catalográfica elaborada pela...

Documents