Gerenciador de condomínio

(1)

UNIVERSIDADE FEDERAL FLUMINENSE

BRUNO EDEILDES LIMA

GERENCIADOR DE CONDOMÍNIO

Niterói

2016

(2)

BRUNO EDEILDES LIMA

GERENCIADOR DE CONDOMÍNIO

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

(3)

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.

(4)

BRUNO EDEILDES LIMA

GERENCIADOR DE CONDOMÍNIO

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

(5)

Dedico este trabalho a minha noiva Yvie e aos meus pais.

(6)

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.

(7)

“Quem abandona a luta não poderá nunca sa-borear o gosto de uma vitória”.

(8)

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.

(9)

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.

(10)

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

(11)

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

(12)

LISTA DE TABELAS

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

Tabela 2: caso uso 01 ... 53

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

(13)

LISTA DE GRÁFICOS

(14)

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.

(15)

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

(16)

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

(17)

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

(18)

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 implantaconfec-çã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.

(19)

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.

(20)

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

(21)

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].

(22)

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:

(23)

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.

(24)

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.

(25)

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;

(26)

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ícondomí-nio La vista; Condomícondomí-nio Aloha; Condomí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()

(27)

 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.

(28)

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 “setDataNasnas-cimento”:

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

(29)

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 obob-jeto 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, aplicaaplica-çõ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 Edirela-ção Empresarial (Java EE) possui bibliotecas especifica

(30)

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

(31)

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;

(32)

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;

(33)

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

(34)

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

(35)

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.

(36)

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.

(37)

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.

(38)

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”.

(39)

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

(40)

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.

(41)

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 FiFi-gura 17.

(42)

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.

(43)

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”.

(44)

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”.

.

(45)

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.

(46)

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”.

(47)

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.

(48)

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.

(49)

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.

(50)

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.

(51)

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

(52)

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

(53)

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.

(54)

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.

(55)

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

Tabela 3: caso uso 02

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

(56)

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.

(57)

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”.

Fluxo Alternativo: Não há.

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

Regras de negócio: RN001, RN002, RN003, RN004, RN005 Tabela 5: caso uso 04

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.

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 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”.

(58)

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.

(59)

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, identifiidentifi-cados pela letra “U”.

(60)

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.

(61)

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 da-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.

(62)

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.

(63)

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) ”.

(64)

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