Condo master

1
PROJETO INTEGRADO MULTIDISCIPLINAR
CONDOMASTER – ADMINISTRAÇÃO DE CONDOMÍNIOS
SÃO PAULO
2017

2
BRUNA ALVARES
CARLOS HENRIQUE SANTANA ESCOUTO
DANILO NICOLAS DE MELO
JULIANA RUIZ DA SILVA
MATHEUS DIAS DA SILVA FERREIRA
Trabalho apresentado como
exigência para a avaliação do 3°
semestre, do curso de Análise e
Desenvolvimento de Sistemas
da Universidade Paulista, sob
orientação do professor Salatiel
Marinho.
SÃO PAULO
2017

3
BRUNA ALVARES
CARLOS HENRIQUE SANTANA ESCOUTO
DANILO NICOLAS DE MELO
JULIANA RUIZ DA SILVA
MATHEUS DIAS DA SILVA FERREIRA
Trabalho apresentado como
exigência para a avaliação do 3°
semestre, do curso de Análise e
Desenvolvimento de Sistemas
da Universidade Paulista, sob
orientação do professor Salatiel
Marinho.
Aprovado em:
BANCA EXAMINADORA
_____________________ __/__/__
Prof. Salatiel Marinho
Universidade Paulista – UNIP
SÃO PAULO
2017

4
“Erre cedo, para acertar cedo.”
(Demian Borba)

5
RESUMO
Este projeto tem como objetivo desenvolver um sistema voltado para o
gerenciamento de condomínios.
Foi utilizado o modelo ágil Scrum para o desenvolvimento deste projeto, onde por
meio de reuniões foram definidos requisitos e funcionalidades do software.
A pesquisa de campo foi útil para ter a visão de como os moradores de condomínio
enxergam a administração e como é feita a comunicação entre morador e síndico,
porteiro etc. Foram também identificadas dificuldades nesta comunicação. Foi feita
também uma entrevista com um síndico, que ajudou a identificar as dificuldades ao
gerenciar um condomínio e facilidades que ele gostaria que um sistema possuísse.
Com as informações adquiridas o projeto foi estruturado fazendo uso de métodos e
conhecimentos adquiridos em sala de aula.
PALAVRAS-CHAVE: Condomínio. Sistema. Porteiro.

6
ABSTRACT
This project aims to develop a system for condominiums’ management.
The agile Scrum model was used to develop this project, where meetings were used
to define requirements and funcionalities of the software.
The field research was useful to get the vision of how the condominium residents see
the administration and how the communication between resident and trustee is made.
Difficulties also were identificated. An enterview with a trustee was made, it helped to
see those difficulties about a condominium’s management and the facilities that he
woud like a system to have.
With the information acquired, the project was structured using methods and
knowledge acquired during the classes.
KEYWORDS: Condominium. System. Concierge.

7
LISTA DE ILUSTRAÇÕES
Figura 1 - Há uma boa comunicação entre a administração e os moradores? .......... 19
Figura 2 - Como são feitos os comunicados para reuniões, eventos, obras ou
quaisquer outros avisos do condomínio?.......................................................................... 20
Figura 3 - Sugestões para a administração ...................................................................... 20
Figura 4 - Sugestões para a administração ...................................................................... 21
Figura 5 - Opiniões sobre aplicativo ou site...................................................................... 21
Figura 6 - Funcionalidade .................................................................................................... 28
Figura 7 - Requisitos Solicitados ........................................................................................ 28
Figura 8 - Requisitos Não Funcionais................................................................................ 28
Figura 9 - Total de Requisitos............................................................................................. 29
Figura 10 - Funcionalidade para Morador......................................................................... 29
Figura 11 - Requisitos Solicitados do Morador ................................................................ 29
Figura 12 - Não Funcionais - Morador............................................................................... 30
Figura 13 - Funcionalidade - Administrador...................................................................... 30
Figura 14 - Requisitos de Administrador ........................................................................... 31
Figura 15 - Funcionalidades - Desenvolvedor.................................................................. 31
Figura 16 - Requisitos - Desenvolvedor ............................................................................ 32
Figura 17 - Qualidade........................................................................................................... 33
Figura 18 - Atributos de Qualidade .................................................................................... 33
Figura 19 - Atributos de Qualidade do Morador............................................................... 34
Figura 20 - Atributos de Qualidade - Administrador ........................................................ 35
Figura 21 - Atributos de Qualidade - Administrador ........................................................ 36
Figura 22 - Confiabilidade.................................................................................................... 38
Figura 23 - Confiabilidade - Níveis de Acesso ................................................................. 41
Figura 24 - Usabilidade ........................................................................................................ 43
Figura 25 - Usabilidade - Satisfação do usuário .............................................................. 45
Figura 26 - Eficiência............................................................................................................ 47
Figura 27 - Bugs em tempo de execução ......................................................................... 49
Figura 28 - Informações do Log.......................................................................................... 51
Figura 29 - Portabilidade em resoluções de tela diferentes ........................................... 53
Figura 30 - Portabilidade em dispositivos diferentes....................................................... 55
Figura 31 - Caso de Uso - Morador.................................................................................... 56
Figura 32 - Caso de uso - Funcionário .............................................................................. 57
Figura 33 - Caso de uso - Síndico...................................................................................... 58
Figura 34 - Modelo ER referente a entidade Pessoa com todas suas relações e
entidades vinculadas............................................................................................................ 73
Figura 35 - Entidades Voto e Funcionário com suas respectivas relações ................. 74
Figura 36 - Entidade Unidade com suas respectivas relações...................................... 75
Figura 37 - Entidade Obra com suas respectivas relações............................................ 76
Figura 38 - Entidade Condomínio com suas respectivas relações............................... 77
Figura 39 - Diagrama ER – Pessoa e suas respectivas relações ................................. 78
Figura 40 - Entidade Pessoa e suas especializações..................................................... 79
Figura 41 - Diagrama ER – Reclamação e Sugestão e suas respectivas relações... 80
Figura 42 - Diagrama ER - Unidade e suas respectivas relações ................................ 80

8
Figura 43 - Protótipo do Menu Principal............................................................................ 81
Figura 44 - Protótipo - Pessoas Físicas/Jurídicas - Dados ............................................ 83
Figura 45 - Protótipos - Pessoas Físicas/Jurídicas - Pesquisa ..................................... 85
Figura 46 - Protótipos - Reclamações e Sugestões........................................................ 87
Figura 47 - Diagrama de Classes - Pessoa...................................................................... 90
Figura 48 - Diagrama de Sequência - Cadastrar Pessoa............................................... 91
Figura 49 - Diagrama de Sequência - Buscar Pessoa.................................................... 92
Figura 50 - Diagrama de Classes - Visita.......................................................................... 93
Figura 51 - Diagrama de sequência evidenciando o caso de uso Cadastrar Visita... 94
Figura 52 - Diagrama de Classes - Reclamações e Sugestões.................................... 95
Figura 53 - Diagrama de sequência evidenciando o caso de uso Cadastrar Sugestão
e Cadastrar Reclamação..................................................................................................... 96
Figura 54 - Diagrama de Pacotes....................................................................................... 97
Figura 55 - Diagrama de Atividade – Cadastrar Pessoa ................................................ 98
Figura 56 - Diagrama Atividade – Buscar Pessoa........................................................... 99
Figura 57 - Diagrama de Atividade – Cadastro de Visita..............................................100
Figura 58 - Diagrama de Atividade – Cadastra Reclamações e Sugestões .............101
Figura 59 - Menu Principal.................................................................................................105
Figura 60 - Cadastro do Condomínio...............................................................................105
Figura 61 - Cadastro de Blocos ........................................................................................106
Figura 62 - Cadastro de Blocos ........................................................................................106
Figura 63 – Unidades - Dados ..........................................................................................107
Figura 64 - Unidades - Pesquisa ......................................................................................107
Figura 65 - Veículos - Dados.............................................................................................108
Figura 66 - Veículos - Pesquisa........................................................................................108
Figura 67 - Pessoas Físicas/Jurídicas - Dados..............................................................109
Figura 68 - Pessoas Físicas/Jurídicas - Pesquisa.........................................................109
Figura 69 - Pessoas Físicas/Jurídicas - Telefones........................................................110
Figura 70 - Pessoas Físicas/Jurídicas - Endereços ......................................................110
Figura 71 - Votar Enquetes - Dados ................................................................................111
Figura 72 - Votar Enquetes - Pesquisa............................................................................111
Figura 73 - Enquetes - Dados...........................................................................................112
Figura 74 - Enquetes - Pesquisa ......................................................................................112
Figura 75 - Contas a Pagar - Dados ................................................................................113
Figura 76 - Contas a Pagar - Pesquisa ...........................................................................113
Figura 77 - Contas a Receber - Dados............................................................................114
Figura 78 - Contas a Receber - Pesquisa.......................................................................114
Figura 79 - Obras - Dados.................................................................................................115
Figura 80 - Obras - Pesquisa ............................................................................................115
Figura 81 - Terceiros - Dados ...........................................................................................116
Figura 82 - Terceiros - Pesquisa ......................................................................................116
Figura 83 - Reclamações e Sugestões - Dados ............................................................117
Figura 84 - Reclamações e Sugestões - Pesquisa........................................................117
Figura 85 - Funcionários - Dados.....................................................................................118
Figura 86 - Funcionários - Pesquisa ................................................................................118
Figura 87 - Eventos - Dados..............................................................................................119
Figura 88 - Eventos - Pesquisa.........................................................................................119

9
Figura 89 - Cadastro de Áreas - Dados...........................................................................120
Figura 90 - Cadastro de Áreas - Pesquisa......................................................................120
Figura 91 - Parâmetros - Cargos......................................................................................121
Figura 92 - Parâmetros - Contas ......................................................................................121
Figura 93 - Parâmetros - Obras ........................................................................................122
Figura 94 - Parâmetros - Serviços....................................................................................122
Figura 95 - Morador - Pesquisa ........................................................................................123
Figura 96 - Morador - Dados.............................................................................................123
Figura 97 - Classes Área ...................................................................................................132
Figura 98 - Classe Bloco....................................................................................................133
Figura 99 - Classes Aviso..................................................................................................133
Figura 100 - Classe Condomínio......................................................................................133
Figura 101 - Classe Contas à Pagar................................................................................133
Figura 102 - Classe Conta à Receber .............................................................................133
Figura 103 - Classe Evento – Área ..................................................................................133
Figura 104 - Classe Login..................................................................................................133
Figura 105 - Classe Morador.............................................................................................133
Figura 106 - Classe Obra...................................................................................................133
Figura 107 - Classe Proprietário .......................................................................................133
Figura 108 - Classe Reclamação e Sugestão ................................................................133
Figura 109 - Classe Terceiro.............................................................................................133
Figura 110 - Classe Unidade.............................................................................................133
Figura 111 - Classe Veiculo ..............................................................................................133
Figura 112 - Classe Voto – Enquete................................................................................133
Figura 113 - Classe Visita – Visitante..............................................................................133

10
LISTA DE TABELAS
Tabela 1 - Lançar Avisos ..................................................................................................... 59
Tabela 2 - Lançar contas a receber ................................................................................... 59
Tabela 3 - Visualizar Reclamações.................................................................................... 60
Tabela 4 - Visualizar Sugestões ......................................................................................... 60
Tabela 5 - Excluir Evento..................................................................................................... 61
Tabela 6 - Lançar Contas a Pagar ..................................................................................... 61
Tabela 7 - Lançar Enquetes ................................................................................................ 62
Tabela 8 - Excluir Enquete .................................................................................................. 62
Tabela 9 - Cadastrar Logins Operacionais ....................................................................... 63
Tabela 10 - Excluir Cadastro de Moradores ..................................................................... 64
Tabela 11 - Cadastrar Veículos .......................................................................................... 65
Tabela 12 - Cadastrar Obras............................................................................................... 66
Tabela 13 - Cadastrar Terceiros......................................................................................... 67
Tabela 14 - Cadastrar Blocos.............................................................................................. 68
Tabela 15 - Cadastrar Condomínio .................................................................................... 68
Tabela 16 - Cadastrar Unidade........................................................................................... 69
Tabela 17 - Cadastrar Área ................................................................................................. 69
Tabela 18 - Cadastrar Despesa.......................................................................................... 70
Tabela 19 - Cadastrar Moradores ...................................................................................... 70
Tabela 20 - Cadastrar Tipo de Obra .................................................................................. 71
Tabela 21 - Cadastrar Tipo de Conta ................................................................................ 71
Tabela 22 - Cadastrar Tipo de Serviço.............................................................................. 72
Tabela 23 - Cadastrar Cargo............................................................................................... 72
Tabela 24 - Menu Principal.................................................................................................. 82
Tabela 25 - Cadastro de Pessoa ........................................................................................ 84
Tabela 26 - Pesquisa Pessoa ............................................................................................. 86
Tabela 27 - Reclamações e Sugestões............................................................................. 88

11
SUMÁRIO
INTRODUÇÃO....................................................................................................................... 13
1 SITUAÇÃO PROBLEMA .................................................................................................. 14
1.1 Proposta de Solução...................................................................................................... 14
2 REQUISITOS...................................................................................................................... 15
2.1 Levantamento.................................................................................................................. 15
2.2 Análise de Negócio ........................................................................................................ 22
2.3 Análise de Requisitos .................................................................................................... 23
2.3.1 Requisitos Funcionais ................................................................................................ 24
2.3.2 Requisitos Não Funcionais ........................................................................................ 26
3 ENGENHARIA DE SOFTWARE ..................................................................................... 27
3.1 Qualidade do Produto .................................................................................................... 27
3.1.1 Funcionalidade ............................................................................................................ 27
3.1.2 Qualidade ..................................................................................................................... 32
3.1.3 Confiabilidade .............................................................................................................. 37
3.1.3 Usabilidade................................................................................................................... 42
3.1.4 Eficiência ...................................................................................................................... 46
3.1.5 Manutenabilidade ........................................................................................................ 48
3.1.6 Portabilidade ................................................................................................................ 52
4 DIAGRAMAS DE CASO DE USO................................................................................... 56
4.1 Morador ............................................................................................................................ 56
4.2 Funcionário...................................................................................................................... 57
4.3 Síndico.............................................................................................................................. 58
4.4 Descrições textuais dos casos de uso ........................................................................ 59
5 BANCO DE DADOS.......................................................................................................... 73
5.1 Modelo Entidade-Relacionamento............................................................................... 73
5.2 Diagrama Entidade-Relacionamento .......................................................................... 77
6 PROTOTIPAÇÃO .............................................................................................................. 81
7 ARQUITETURA.................................................................................................................. 89
7.1 Diagrama de Classes e Sequência ............................................................................. 89
7.2 Visão de implementação ............................................................................................... 96
7.3 Representação do Fluxo ............................................................................................... 98
7.3.1 Diagramas de Atividade ............................................................................................. 98
CONCLUSÃO ......................................................................................................................102

12
BIBLIOGRAFIA....................................................................................................................103
APÊNDICE A – PROTÓTIPOS.........................................................................................105
APÊNDICE B – SCRIPT SQL ...........................................................................................124
APÊNDICE C - DIAGRAMA DE CLASSES....................................................................132

13
INTRODUÇÃO
Uma construtora contratou uma fábrica de software para o desenvolvimento de
um sistema de administração de condomínios. O sistema será implantado em todos
os condomínios da construtora e deverá permitir a realização de todas as operações
relacionadas a administração de um condomínio. O sistema deverá ser acessível para
que eventuais usuários portadores de deficiência consigam utilizá-lo.
O sistema foi desenvolvido utilizando um condomínio como objeto de estudo.
Foram feitas entrevistas e pesquisas para conhecer as dificuldades do porteiro,
síndico, zelador e principalmente do morador, pois quem vive no condomínio é quem
realmente sente quando há problemas com a administração.
O software foi feito para sanar essas dificuldades e facilitar ao máximo o
trabalho do usuário, tornando a experiencia de quem trabalha e/ou mora no
condomínio, mais fácil e documentada. Este foi feito com interfaces limpas e
amigáveis ao usuário, para que este possua uma visão clara e objetiva das
informações apresentadas.

14
1 SITUAÇÃO PROBLEMA
Foram utilizados diversos métodos para obtenção de informações pertinentes
ao sistema, sendo eles: entrevista, questionário, pesquisa de campo e observação.
A entrevista foi realizada com o síndico do condomínio de uma das integrantes
do grupo, Juliana Ruiz. A mesma informou sobre os problemas que haviam de acordo
com os moradores, e o síndico, o Sr. Emerson, informou sobre a rotina operacional e
administrativa do prédio.
A pesquisa de campo e a observação foram realizadas graças à Sra. Juliana
Vieira, assistente comercial da empresa GK Administração de Bens S/S Ltda. Esta foi
prestativa em dar uma ideia do sistema utilizado pela empresa e uma noção de qual
é a visão de condomínio da administradora, assim como as funcionalidades mais
utilizadas e a rotina do prédio.
Ainda foi realizada uma pesquisa com o público. Esta foi direcionada a
quaisquer moradores de condomínio e divulgada nas redes sociais. O intuito foi saber
qual é a visão do morador das principais dificuldades de comunicação com a
administração do condomínio, assim como o que poderia ser melhorado.
1.1 Proposta de Solução
Para sanar estas dificuldades foi proposto o sistema CondoMaster. Este
contém tudo que foi solicitado pelos entrevistados, além de outras facilidades que
poderiam ajudar na administração.
O sistema irá dispor de meios de comunicação antes não utilizados pelos
condôminos, como avisos e enquetes. O mesmo também irá dispor de cadastros de
unidades, blocos, eventos, moradores, funcionários internos e terceiros, controle de
obras e áreas do condomínio, entre outras funcionalidades que serão descritas nos
próximos capítulos.

15
2 REQUISITOS
O sistema CondoMaster é responsável por fazer o gerenciamento do
condomínio e ter o controle de todos os processos referentes a ele. É possível inserir
registros e cadastros para ter um controle maior dos dados e informações nele
armazenados. Para tornar o projeto possível, foi feito o levantamento de requisitos
para o início de desenvolvimento do protótipo.
2.1 Levantamento
 Compreensão do Condomínio
O sistema foi projetado para condomínios de pequeno e médio porte, sendo
voltado inicialmente para prédios. Foi idealizado para ser utilizado pelo síndico,
porteiro e, posteriormente, moradores. Desta forma, o grupo fez uso de métodos de
levantamento de informações para auxiliar no desenvolvimento de um software que
consiga suprir as necessidades dos usuários.
 Elicitação
Para o desenvolvimento do projeto foram aplicadas algumas técnicas de
interação com o usuário, com objetivo de traçar os requisitos a serem seguidos pelos
desenvolvedores. Estes fizeram uso de ferramentas para obter maior precisão e
relação ao sistema, sendo possível proporcionar uma experiência satisfatória para o
usuário.

16
- Entrevista
Foi realizada uma entrevista com o síndico do condomínio “Buena Vitta”, o Sr.
Emerson. Esta etapa foi útil para que o grupo pudesse visualizar o ponto de vista de um
usuário em relação ao software, inclusive da parte administrativa do condomínio.
• Bruna Alvares: Quantos funcionários trabalham internamente no
condomínio?
– Emerson: São 2 porteiros noturnos, 1 auxiliar de serviços gerais e
1 de limpeza, todos terceirizados.
• Juliana Ruiz: Emerson, quais as funções principais de um síndico? E
quais tem a maior dificuldade de controle?
• Emerson: Resumindo: o síndico responde civilmente pelo
condomínio. Administra todos os interesses e presta contas ao conselho (que
avalia o síndico) e moradores. E a maior dificuldade seria a interação entre
síndico e moradores.
• Juliana Ruiz: Então a dificuldade maior seria essa má interpretação dos
moradores quanto aos assuntos?
• Emerson: Depende de como é passado pela administração e o
interesse dos condôminos.
• Juliana Ruiz: Nosso projeto tem a ideia de um quadro de comunicados
online, onde cada unidade teria acesso a suas informações e do condomínio. Em sua
opinião seria funcional nesse quesito?
• Emerson: Sensacional! Serviços terceirizados já fazem no
condomínio, porém não é muito utilizado.
• Bruna Alvares: O que nós imaginamos foi um sistema interativo com os
moradores, exemplo: os moradores acessariam o sistema pelo celular ou navegador
e direto por lá já veriam os comunicados, fariam as sugestões e reclamações, haveria

17
as votações para pequenas mudanças, isso evitaria bagunça e não precisaria mais
do grupo do WhatsApp, na nossa visão. Acha que seria interessante?
• Emerson: Sensacional! Hoje é feito pelo WhatsApp, e como é livre
acaba dispersando alguns assuntos importantes. Com esse objetivo, ficaria
mais objetivo.
• Bruna Alvares: A respeito da prestação de contas ao conselho,
pensamos em colocar um controle de contas a pagar e receber, um controle simples.
Como é feita essa prestação de contas? É um relatório de movimentação de caixa?
Ou as contas em si são enviadas com comprovantes e eles fazem os cálculos?
• Emerson: A segunda opção com CNPJ conforme a lei.
• Bruna Alvares: E essas contas posteriormente são apresentadas para
os moradores também?
• Emerson: Sim, junto aos comprovantes de documentos. Pena que
os moradores não se interessam em analisá-los.
• Bruna Alvares: - Como é feito o procedimento de reservas de áreas do
prédio? Como isso é controlado?
• Emerson: É feito uma reserva com o valor estipulado em
assembleia com regras e entra em um saldo separado para futuros
investimentos no condomínio.
• Bruna Alvares: Na questão de controle de visitantes, como é controlado?
O porteiro liga para a unidade e o visitante sobe?
• Emerson: Aos visitantes que tem autorização, são liberados! Fora
isso, é anunciado pelo porteiro e o acesso é autorizado pelo morador.
• JulianaRuiz: O que seria interessante em um software para o seu cargo?
– Emerson: - Um mural eletrônico com notícias e sugestões, seria
mais opção de comunicação.

18
• Danilo Melo: Quando se realiza uma manutenção no condomínio, por
exemplo: Uma empresa faz a manutenção da parte elétrica do salão de festa, você
tem os registros dos serviços realizados no condomínio?
– Emerson: São sempre anexadosno balancete. Exceto a construtora
que ainda realiza correções.
• Danilo Melo: – E os boletos do condomínio de cada morador como eles
tem acesso, correio?
– Emerson: – São emitidos pelo banco, a administradora imprime e
repassa para o condomínio. O condôminoretira na portaria ou o zeladorentrega.
Aos proprietários que não residem no condomínio é enviado via correio
conforme solicitado.
• Danilo Melo: – Você acharia interessante ter um ambiente onde o
síndico, conseguiria visualizar o boleto de cada morador ou até mesmo pendência do
mesmo e o morador tivesse acesso ao boleto referente a sua unidade?
– Emerson: – Claro, já temos isso! Mas é terceirizado pela
administradora.
- Pesquisa de Campo
Para auxiliar na definição dos requisitos foi feita uma pesquisa de campo no dia
19/03, com a Sra. Juliana Vieira, assistente comercial da empresa GK Administração de
Bens S/S Ltda. Esta teve como objetivo ajudar o grupo a obter visão do dia a dia de um
condomínio da perspectiva da administradora, assim auxiliando o grupo na idealização das
funções que poderiam se tornar úteis no sistema para satisfazer os requisitos do usuário.
Foram obtidas informações cruciais para o desenvolvimento do projeto. O sistema
deverá ter as funções de cadastro do condomínio, proprietários, blocos, unidades,
moradores, codificação para cada um facilitando a localização de um registro específico.
Posteriormente haverá um ambiente de acesso web voltado para o morador, onde ele

19
poderá verificar datas de eventos no condomínio, avisos referentes aos moradores em
geral, entre outros.
O software deverá fornecer ferramentas específicas para o síndico do condomínio,
no qual o mesmo será responsável por fazer o gerenciamento. Ele será a ponte da relação
entre condomínio e morador, terá acesso a todos os cadastros do sistema, da
movimentação dentro do prédio, reservas, inadimplências, contas referentes ao condomínio
etc.
- Pesquisa com o público
Foi feita uma pesquisa via web direcionada a moradores de condomínios, para
entender o que para eles seria útil tendo um software com esta finalidade.
Este questionário teve como objetivo reforçar se seria útil implementar no
sistema avisos referentes ao condomínio que seriam visualizados por todos com
acesso ao sistema como também o que mais de ferramentas ele poderia dispor ao
usuário.
Figura 1 - Há uma boa comunicação entre a administração e os moradores?
Fonte: Elaboração própria.

20
Figura 2 - Como são feitos os comunicados para reuniões, eventos, obras ou quaisquer outros avisos
do condomínio?
Figura 3 - Sugestões para a administração

21
Figura 4 - Sugestões para a administração
Figura 5 - Opiniões sobre aplicativo ou site

22
2.2 Análise de Negócio
Para o avanço do projeto, etapas foram passadas e em cada uma destas
etapas o grupo, por meio de reuniões, traçou os requisitos baseados nas informações
adquiridas com as pesquisas. Em cada uma das sprint meetings realizadas foi
abordada uma parte do trabalho na qual foram identificadas dificuldades e soluções.
É importante ressaltar que todas as decisões referentes ao sistema foram tomadas
em grupo por meio de argumentação dos envolvidos no projeto.
Os condomínios em geral possuem suas diferenças em dimensões, áreas,
estrutura etc., mas o que é básico e comum para todos é a necessidade de um síndico,
porteiro e moradores. Alguns podem até ter outros cargos a mais como seguranças,
zeladores etc., mas, em outras palavras, precisarão de funcionários que serão
encarregados de cuidar do condomínio; também precisarão de pessoas para usufruir
destes serviços. Desta forma o sistema foi idealizado pensando em beneficiar e
automatizar as possíveis tarefas desenvolvidas por estes indivíduos.
Para alcançar os objetivos impostos, foi idealizado um sistema voltado para a
experiência do usuário, fazendo com que este consiga atingir seus objetivos da forma
mais eficaz possível.
Contudo, a obtenção de dados por meio de entrevistas e pesquisas foi útil
para a definição das funcionalidades do sistema, onde, por meio de reuniões e
análises, as dificuldades foram surgindo. Uma delas foi projetar o sistema de acordo
com as necessidades dos moradores também, em vez de focar apenas na parte
operacional, como é feito na maioria dos sistemas do mercado.
Outro ponto que surgiu de dificuldade em relação ao condomínio foi o acesso
ao sistema, por exemplo: o morador não pode ter acesso às mesmas funcionalidades
que o porteiro ou o síndico. Ambos devem ter acesso ao sistema, porém, cada um
com seu nível de acesso para evitar operações não autorizadas e inconsistência de
dados.

23
2.3 Análise de Requisitos
O usuário deverá cadastrar o condomínio a ser trabalhado. No cadastro do
condomínio deverá ser especificado o nome deste e a data de inauguração. Após
realizar esta operação, devem ser cadastrados os blocos. No cadastro dos blocos
deverá ser colocada a identificação (nome) do bloco e quantidade de andares.
Qualquer conta a pagar e a receber que seja pertinente ao condomínio deve ser
cadastrada em sua respectiva tela. Avisos referentes ao condomínio assim como
qualquer aviso destinado aos moradores e funcionários deve ser registrado.
Qualquer obra que for realizada dentro das áreas comuns deverá ser inserida
na tela de Obras, onde serão inseridos também os dados dos terceiros que serão os
responsáveis por realizá-las. Isto é necessário para que os terceiros tenham sua
entrada liberada no condomínio.
Em seguida, pode ser feito o cadastro das unidades. Devem ser informados a
identificação da unidade, a do bloco e a do proprietário. Os veículos pertencentes às
unidades deverão ser cadastrados na tela Cadastro de Veículos.
Qualquer evento pertinente às áreas do condomínio deverá ser cadastrado por
meio da opção Cadastro de Eventos. Sugestões e reclamações deverão ser
efetivadas identificando a pessoa responsável, selecionando se será feita uma
reclamação ou sugestão, colocando seu título e descrição.
Pessoas serão cadastradas no sistema pelo nome, razão social, número do
documento (CPF ou CNPJ), RG/Inscrição Estadual, data de nascimento e
selecionando se a mesma é física ou jurídica. Na aba Endereços pode ser inserido o
logradouro, número, complemento, bairro, CEP, cidade e estado. Para telefones, só
inserir o número.
Para o morador o usuário deve informar a unidade onde este reside e
selecionar quem é no cadastro de pessoa. No funcionário deverá ser informado o
cargo que este ocupa e os dados de pessoa.

24
2.3.1 Requisitos Funcionais
• RF01 – Fazer Login: Todo usuário deverá fazer o login no sistema para
validar seu acesso;
• RF02 – Cadastro de terceiros: O usuário visualizará e realizará
cadastros de terceiros que tiveram que prestar serviços ao condomínio;
• RF03 - Cadastro de Morador – O usuário deverá visualizar e cadastrar o
morador selecionando quem é a pessoa e selecionando a unidade.
• RF04 - Cadastro de Unidade – O usuário deverá visualizar e inserir o
número de identificação da unidade e o bloco ao qual ela pertence.
• RF05 - Cadastro de Obra – O usuário deverá visualizar e cadastrar
informações referentes a obras a serem realizadas no condomínio, onde a obra será
realizada (área) e o terceiro que irá realizar a obra.
• RF06 - Cadastro de contas a pagar – O usuário deverá visualizar e
cadastrar todas as contas referentes ao condomínio, como água, luz, gás entre outros;
• RF07 - Cadastro de contas a receber - O usuário deverá visualizar e
cadastrar todas as contas recebidas pelo condomínio, como aluguel de áreas comuns,
taxa de condomínio etc.;
• RF08 - Reserva de áreas comuns - O usuário deverá visualizar e efetuar
a reserva de áreas comuns, para algum evento, será inserida a unidade que irá
promover o evento, a data e o qual área será reservada;
• RF09 - Registro de reclamações/sugestões - O usuário deverá visualizar
e inserir as reclamações e sugestões dos moradores do condomínio, será inserido a
unidade, o título e a descrição;
• RF10 – Cadastro de blocos – O usuário deverá visualizar e cadastrar os
blocos. Estes deverão ser cadastrados por sua identificação e quantidade de andares;
• RF11 – Cadastro de veículos - O usuário deverá visualizar e cadastrar
os veículos por sua placa e modelo, além da unidade a que eles pertencem;

25
• RF12 – Cadastro de Áreas – O usuário deverá visualizar e cadastrar as
áreas do condomínio, inserindo a identificação e se é uma área alugável ou não.
• RF13 – Cadastro de Visitas - O usuário deverá visualizar e cadastrar os
visitantes por nome e RG, assim como a data, hora e unidade que ele foi visitar.
• RF14 – Cadastro de Avisos - O usuário deverá visualizar e cadastrar os
avisos pertinentes aos moradores do condomínio. Deve conter a descrição do aviso.
• RF15 – Cadastro de Enquetes - O usuário administrador deverá
visualizar e cadastrar as enquetes a serem exibidas aos outros usuários. Deve conter
a pergunta.
• RF16 – Votar nas Enquetes - O usuário poderá visualizar e votar nas
enquetes pendentes. Deve selecionar se sua resposta é sim ou não.
• RF17 – Cadastrar Login - O usuário administrador deverá visualizar e
cadastrar os logins dos usuários, selecionando a qual pessoa pertence, o usuário e a
senha.
• RF18 – Cadastrar parâmetros – O usuário administrador deverá
visualizar e cadastrar os parâmetros do sistema, como tipo de Obras, tipo de Contas,
tipo de Serviços e Cargos, cada um por sua descrição.
• RF19 – Cadastrar Eventos - O usuário administrador poderá visualizar e
cadastrar os eventos a serem realizados, selecionando a unidade responsável, data
do evento, descrição e áreas que participarão.

26
2.3.2 Requisitos Não Funcionais
• RNF01 – Uma pessoa não pode ter acesso ao login de outra;
• RNF02 – Cada usuário deve ter acesso exclusivamente às suas informações;
• RNF03 – Cada consulta não deve demorar mais do que 2 segundos;
• RNF04 – Os dados devem ser criptografados;
• RNF05 – Deve haver uma rotina de backup;
• RNF06 – Somente o login do administrador terá acesso às informações de
todos.

27
3 ENGENHARIA DE SOFTWARE
O modelo ágil Scrum foi utilizado para o desenvolvimento do projeto. Cada uma
das sprint meetings foi útil para auxiliar no entendimento dos integrantes quanto aos
prazos e métodos utilizados na elaboração do sistema.
3.1 Qualidade do Produto
Para medir a qualidade do produto, o grupo baseou-se nas normas da ISO
9126, reconhecida mundialmente pelos seus padrões estabelecidos. Como o projeto
é de caráter teórico, não é possível executar métodos de testes práticos em alguns
dos requisitos de qualidade. Primeiramente, foram listados os requisitos de qualidade
que identificamos como necessários para atender os atributos de qualidade da ISO.
Para cada atributo existem 2 tipos de requisitos, e cada requisito há uma métrica e
um nível de qualidade. Apresentamos também qual tipo de usuário pode realizar os
testes de qualidade.
3.1.1 Funcionalidade
• Requisito de qualidade: apresentar todos os requisitos que o usuário
necessita.
• Métrica de qualidade: Número de requisitos que o software oferece
dividido pelo número de requisitos solicitados pelo cliente.
• Nível de pontuação: Porcentagem.
• Usuário de teste: Morador; Síndico e Porteiro.
Foram listados os requisitos levantados e serão avaliados se eles
correspondem ao que o software está processando.

28
Figura 6 - Funcionalidade
Figura 7 - Requisitos Solicitados
Figura 8 - Requisitos Não Funcionais

29
Figura 9 - Total de Requisitos
Figura 10 - Funcionalidade para Morador
Figura 11 - Requisitos Solicitados do Morador

30
Figura 12 - Não Funcionais - Morador
Figura 13 - Funcionalidade - Administrador
Fonte: elaboração própria.

31
Figura 14 - Requisitos de Administrador
Figura 15 - Funcionalidades - Desenvolvedor

32
Figura 16 - Requisitos - Desenvolvedor
3.1.2 Qualidade
 Requisito de qualidade: Requisitos devem executar todos os atributos
necessários.
 Métrica de qualidade: Número de atributos que o software apresenta
dividido pelo número de atributos que o usuário necessita.
 Nível de pontuação: Porcentagem.
 Usuário de teste: Morador; Síndico e Porteiro.

33
 Listamos os atributos dos requisitos e analisaremos se estes estão
sendo executados de forma correta pelo software.
Figura 17 - Qualidade
Figura 18 - Atributos de Qualidade

34
Figura 19 - Atributos de Qualidade do Morador

35
Figura 20 - Atributos de Qualidade - Administrador

36
Figura 21 - Atributos de Qualidade - Administrador

37
3.1.3 Confiabilidade
 Requisito de qualidade: Tempo que leva para o software executar os
processos, quando sistema está sobrecarregado.
 Métrica de qualidade: Cronometrar tempo.
 Nível de pontuação: Unidade de tempo.
 Usuário de teste: Desenvolvedor. O desenvolvedor acionará as
funcionalidades do software, enquanto o desktop e o mobile estiverem acionando
outros recursos ao mesmo tempo. O tempo em que a solicitação da funcionalidade
for realizada até o momento em que a funcionalidade execute o que foi solicitado.

38
Figura 22 - Confiabilidade

39
 Requisito de qualidade: Acesso dos usuários as funcionalidades do software.
 Métrica de qualidade: Nível de acessibilidade.
 Nível de pontuação: Níveis 1, 2 e 3.
 Usuário de teste: Desenvolvedor. De acordo com as regras de negócio, alguns
usuários do software não poderão realizar algumas funções, para que não haja conflito
hierárquico de permissões. Dessa forma, foram definidos níveis de acessibilidadepara
os usuários.
 Nível 1: Menor nível de acessibilidade para as funcionalidades básicas do
software. Limita-se à visualização e cadastro de assuntos comuns dos condôminos.
o Acesso às Funcionalidades: Acessar Boleto; Exibir Avisos; Registrar
Reclamações; Registrar Sugestões; Visualizar Eventos na Agenda; Agendar Eventos;
Visualizar Contas do Condomínio; Visualizar Enquetes Pendentes; Votar nas
Enquetes e Fazer Login.
o Usuário de teste: Morador.
 Nível 2: Nível intermediário de acessibilidade. Realiza as mesmas funções do
Nível 1, visualiza informações dos blocos do condomínio e cadastra a movimentação
rotineira do prédio.
o Acesso às Funcionalidades: Visualizar Cadastro de Terceiros; Visualizar
Cadastro de Veículos; Visualizar Cadastro de Obras; Visualizar Cadastro de Obras;
Visualizar Cadastro dos Blocos; Visualizar Cadastro de Unidades; Visualizar Cadastro
de Eventos; Visualizar Cadastro de Áreas; Visualizar Cadastro de Visitantes;
Cadastras Visitantes; Visualizar Cadastro de Moradores; Consultar Visitas; Cadastrar
Visitas.
o Usuário de teste: Porteiro.

40
 Nível 3: Nível avançado de acessibilidade. Realiza todas as funções dos níveis
1 e 2, além de cadastrar e administrar informações sobre os blocos do condomínio.
o Acesso as Funcionalidades: Lançar Contas a Receber; Lançar Avisos;
Visualizar Reclamações; Visualizar Sugestões; Excluir Eventos; Lançar Contas a
Pagar; Lançar Enquetes; Excluir Enquetes; Cadastrar Logins; Excluir Cadastro de
Moradores; Cadastrar Veículos; Cadastrar Obras; Cadastrar Terceiros; Cadastrar
Blocos; Cadastrar Condomínios; Cadastrar Unidades; Cadastrar Áreas; Cadastrar
Telefones; Cadastrar Endereço; Cadastrar Despesa; Cadastrar Tipo de Serviço;
Cadastrar Tipo de Unidade; Cadastrar Tipo de Obra.
o Usuário de teste: Síndico.

41
Figura 23 - Confiabilidade - Níveis de Acesso

42
3.1.3 Usabilidade
 Requisito de Qualidade: Tempo que leva para usuário identificar as funções da
interface.
 Métrica de Qualidade: Cronometrar Tempo.
 Nível de Pontuação: Unidade de Tempo.
 Usuário de teste: Morador; Síndico; Porteiro. Será solicitado aos usuários que
identifiquem as funções das interfaces, e o tempo que levará para isso será
cronometrado. Quanto menor for o tempo, maior será considerado o índice de
qualidade. Levaremos em consideração os recursos do hardware como memória
RAM, Processador e Sistema Operacional, recursos do software como espaço de
memória utilizado, nível de escolaridade do usuário.

43
Figura 24 - Usabilidade

44
 Requisito de Qualidade: Nível de afinidade do usuário com o design da
interface.
 Métrica de Qualidade: Satisfação.
 Nível de Pontuação: Qualitativa.
 Usuário de teste: Morador; Síndico; Porteiro. Após o usuário navegar no
software, solicitaremos a opinião do usuário sobre o quanto o usuário ficou satisfeito
com o design das interfaces. Será levado em consideração o nível de escolaridade do
usuário e experiências anteriores com softwares de condomínios.

45
Figura 25 - Usabilidade - Satisfação do usuário

46
3.1.4 Eficiência
 Requisito de Qualidade: Tempo de resposta para carregar a interface.
 Métrica de Software: Cronometrar Tempo.
 Nível de Pontuação: Unidade de Tempo.
 Usuário de teste: Desenvolvedor. Assim que a função for acionada, esta abrirá
uma nova interface, será cronometrado o tempo que levará para a tela ser
completamente carregada. Será levado em consideração os recursos do hardware
como memória RAM, Processador e Sistema Operacional, recursos do software como
espaço de memória utilizado, o número de linhas de código da interface.
 Requisito de Qualidade: Quanto de memória utilizado da máquina para rodar o
software.
 Métrica de Software: Quantidade de memória utilizada.
 Nível de Pontuação: Memória RAM.
 Usuário de teste: Desenvolvedor. Será medida a utilização da memória da
máquina enquanto o software está em execução. Recursos do hardware como
memória RAM, Processador e Sistema Operacional, recursos do software como
espaço de memória utilizado, o número de linhas de código da interface será levado
em consideração.

47
Figura 26 - Eficiência

48
3.1.5 Manutenabilidade
 Requisito de Qualidade: Quantos bugs são apresentados em qual período de
tempo de execução do software.
 Métrica de Software: Quantidade de bugs dividido pelo tempo de execução.
 Nível de Pontuação: Relação bug x tempo.
 Usuário de teste: Morador; Síndico e Porteiro.
 Os usuários executarão o máximo de funções possíveis, e será estabelecida
uma relação de número de bugs que ocorreram durante o processo pelo tempo que o
software foi executado. Levaremos em consideração os recursos do hardware como
memória RAM, Processador e Sistema Operacional, recursos do software como
espaço de memória utilizado, nível de escolaridade do usuário.

49
Figura 27 - Bugs em tempo de execução

50
 Requisito de Qualidade: Informações que o log apresentará.
 Métrica de Software: Quantas informações relevantes o log apresentará.
 Nível de Pontuação: Quantitativo.
 Usuário de teste: Desenvolvedor.
 Colocaremos um sistema de log, onde um arquivo de extensão .txt exibirá as
informações: Nome do arquivo, Tipo de erro, Horário, linha de código e descrição.
Levaremos em consideração os recursos do hardware como memória RAM,
Processador e Sistema Operacional e recursos do software como espaço de memória
utilizado.

51
Figura 28 - Informações do Log

52
3.1.6 Portabilidade
 Requisito de Qualidade: Comportamento do software em resoluções de tela
diferentes.
 Métrica de Software: Resultados das métricas na resolução de tela N x
Resultados das métricas na resolução de tela M.
 Nível de Pontuação: Comparativo.
 Usuário de teste: Morador; Síndico; Porteiro e Desenvolvedor. Serão
comparadas todas as métricas listadas anteriormente em resoluções de telas
diferentes para que possamos analisar em quais quesitos se saem melhor nas suas
devidas resoluções e fazermos as melhorias necessárias. Consideraremos os
dispositivos utilizados, os recursos do hardware como a memória RAM, Processador
e Sistema Operacional e recursos do software como espaço de memória utilizado.

53
Figura 29 - Portabilidade em resoluções de tela diferentes

54
 Requisito de Qualidade: Comportamento do software em dispositivos
diferentes.
 Métrica de Software: Resultados das métricas no dispositivo N x Resultados
das métricas no dispositivo M.
 Nível de Pontuação: Comparativo.
 Usuário de teste: Morador; Síndico; Porteiro e Desenvolvedor. Serão
comparadas todas as métricas listadas anteriormente em dispositivos diferentes para
que se possa analisar em quais quesitos se saem melhor em seus devidos
dispositivos e sejam feitas as melhorias necessárias. Consideraremos os dispositivos
utilizados, os recursos do hardware como memória RAM, Processador e Sistema
Operacional e recursos do software como espaço de memória utilizado.

55
Figura 30 - Portabilidade em dispositivos diferentes

56
4 DIAGRAMAS DE CASO DE USO
Os diagramas de caso de uso são utilizados para a modelagem de aspectos
dinâmicos do sistema. Possuem um papel central para a modelagem do
comportamento de um software.
4.1 Morador
Figura 31 - Caso de Uso - Morador

57
4.2 Funcionário
Figura 32 - Caso de uso - Funcionário

58
4.3 Síndico
Figura 33 - Caso de uso - Síndico

59
4.4 Descrições textuais dos casos de uso
Tabela 1 - Lançar Avisos
Nome Lançar Avisos
Atores Síndico
Précondições Estar logado no sistema
Pós-Condições Aviso lançado no sistema
Fluxo Principal de Eventos
1. O usuário inicia o caso de uso;
2. O usuário insere o aviso desejado;
3. O caso de uso registra as informações;
4. O caso de uso apresenta a mensagem:
“Registrado com sucesso!”
5. O caso de uso encerra;
Tabela 2 - Lançar contas a receber
Nome Lançar Contas a Receber
Atores Síndico
Pós-Condições Contas a receber lançadas no Sistema
Fluxo Principal de
Eventos
2. O usuário insere os dados da conta a receber como
data do vencimento, valor, unidade, etc.
4. O caso de uso apresenta a mensagem: “Registrado
com sucesso!”

60
Tabela 3 - Visualizar Reclamações
Nome Visualizar Reclamações
Atores Síndico
Précondições
Estar logado no sistema
Existir Reclamações
Pós-Condições Reclamações apresentada ao usuário;
2. O caso de uso verifica se há
reclamações existentes;
3. O caso de uso apresenta as
reclamações ao usuário;
Fluxo Excepcional de Eventos 1
2.1 Se não houver reclamações
existentes:
2.2 O caso de uso apresenta a
mensagem “Não existem
reclamações!”.
Tabela 4 - Visualizar Sugestões
Nome Visualizar Sugestões
Atores Síndico
Précondições
Existir sugestões
Pós-Condições Sugestões apresentada ao usuário;
2. O caso de uso verifica se há sugestões
existentes;
3. O caso de uso apresenta as sugestões
ao usuário;
2.1 Se não houver sugestões existentes:
mensagem: “Não existem sugestões!”.

61
Tabela 5 - Excluir Evento
Nome Excluir Evento
Atores Síndico
Précondições
Existir eventos agendados
Pós-Condições Evento selecionado excluído;
2. O caso de uso verifica se há eventos
agendados;
3. O caso de uso apresenta os eventos
agendados ao usuário;
4. O usuário seleciona os eventos que
deseja excluir;
5. O caso de uso exclui o evento
selecionado;
6. O caso de uso apresenta a
mensagem: “Evento(s) Excluído(s)
com sucesso!".
2.1 Se não houver eventos agendados:
mensagem “Não existem eventos
agendados!";
Tabela 6 - Lançar Contas a Pagar
Nome Lançar Contas a Pagar
Atores Síndico
Pós-Condições Contas a Pagar lançadas no Sistema
2. O usuário insere os dados da conta a
Pagar como data do vencimento, valor,
unidade, etc.
3. O casode uso registraas informações;
4. O casode uso apresenta a mensagem:
“Registrado com sucesso!”.

62
Tabela 7 - Lançar Enquetes
Nome Lançar Enquetes
Atores Síndico
Pós-Condições Enquete lançada no sistema
2. O usuário insere a enquete desejada
e as opções de resposta;
“Registrado com sucesso!".
Tabela 8 - Excluir Enquete
Nome Excluir Enquete
Atores Síndico
Précondições
Existir enquetes registradas
Pós-Condições Enquete selecionada excluída;
2. O caso de uso verifica se há enquetes;
3. Ocasode uso apresenta as enquetes ao
usuário;
4. O usuário seleciona as enquetes que
deseja excluir;
5. O caso de uso exclui a enquete
selecionada;
“Enquete(s) Excluída(s) comsucesso!".
2.1 Se não houver enquetes:
2.2 O casode uso apresenta a mensagem:
“Não existemenquetes!";

63
Tabela 9 - Cadastrar Logins Operacionais
Nome
Cadastrar Logins
Operacionais
Atores Síndico
Précondições
O Funcionário não possuir um Login
cadastrado;
Existir o cadastro do funcionário no
sistema,
Pós-Condições Permissões atribuídas ao Funcionário.
2. O usuário insere as informações do
Login como Funcionário e permissões;
3. O casode uso verificaseo funcionário
informado possui cadastro no sistema;
4. O caso de uso verifica se há um login
existente para o funcionário informado;
5. O caso de uso registra as informações
e atribui as permissões ao Login do
Funcionário;
“Login registrado com Sucesso!”.
3.1 Se não houver cadastro do
Funcionário
3.2 O caso de uso apresentar a
mensagem: “Funcionário informado
não possui cadastro!".
4.1 Se já existir um login para o
funcionário informado:
mensagem: “funcionário informado já
possui um login!”.

64
Tabela 10 - Excluir Cadastro de Moradores
Nome
Excluir Cadastro de
Moradores
Atores Síndico
Précondições
Estar logado no sistema;
Existir o cadastro no sistema;
Pós-Condições Cadastro do morador excluído;
2. O usuário seleciona o cadastro
desejado no sistema;
3. O usuário pressiona o botão para
excluir
4. O caso de uso desativa o cadastro
selecionado.
“Cadastro Excluído com sucesso!”.

65
Tabela 11 - Cadastrar Veículos
Nome Cadastrar Veículos
Atores Síndico
Précondições
Estar logado no sistema;
A unidade Proprietária do veículo estar
cadastrada no sistema;
Pós-Condições Veículo cadastrado no sistema
veículo como placa e modelo;
3. O caso de uso verifica se a placa
informada já foi cadastrada
anteriormente.
4. O caso de uso verifica se a unidade
informada existe;
“Veículo cadastrado com sucesso!".
3.1 Se já existir um cadastro com a placa
informada:
mensagem: “Placa informada já
cadastrada!".
4.1 Se a unidade informada não existir:
mensagem: “Unidade informada não
existe!”.

66
Tabela 12 - Cadastrar Obras
Nome Cadastrar Obras
Atores Síndico
Précondições Estar logado no sistema;
Pós-Condições Obra cadastrada
2. O usuário insere as informações da
Obra como tipo, área e período;
3. Se o período informado estiver
disponível:
4. O caso de uso registra as informações
e reserva o Período na agenda;
5. O caso de uso apresenta a mensagem
“Obra cadastrada com sucesso!";
3.1 Se houver eventos pré-agendados
no período:
3.2 Apresentar a mensagem: “Período
Informado consta eventos agendados!".

67
Tabela 13 - Cadastrar Terceiros
Nome Cadastrar Terceiros
Atores Síndico
Pós-Condições
Funcionário Terceirizado cadastrado no
sistema;
Terceirizado como Tipo de Serviço e
Pessoa;
3. O caso de uso verifica se o
Terceirizado informado não possui um
cadastro;
“Terceirizado cadastrado com
sucesso!";
3.1 Se já houver o cadastro do Terceiro
no sistema:
3.2 Apresentar a mensagem:
“Terceirizado Informado já possui
cadastro!".

68
Tabela 14 - Cadastrar Blocos
Nome Cadastrar Blocos
Atores Síndico
Pós-Condições Bloco cadastrado;
bloco como condomínio e nome,
3. O caso de uso verifica se o Bloco
informado já não foi cadastrado;
“Bloco cadastrado com sucesso!";
3.1 Se o bloco informado já existir no
sistema;
3.2 Apresentar a mensagem: "Bloco
informado já cadastrado!".
Tabela 15 - Cadastrar Condomínio
Nome Cadastrar Condomínio
Atores Síndico
Pós-Condições Condomínio cadastrado;
Condomínio como nome,
3. O caso de uso verifica se o
Condomínio informado já não foi
cadastrado;
“Condomínio cadastrado com
sucesso!";
3.1 Se o Condomínio informado já existir
no sistema;
3.2 Apresentar a mensagem:
"Condomínio informado já
cadastrado!".

69
Tabela 16 - Cadastrar Unidade
Nome Cadastrar Unidade
Atores Síndico
Pós-Condições Unidade cadastrada;
unidade como bloco, identificação,
vagas e proprietário;
3. O caso de uso verifica se a Unidade
informada já não foi cadastrada;
“Unidade cadastrada com sucesso!";
3.1 Se a Unidade informada já existir no
sistema;
3.2 Apresentar a mensagem: "Unidade
informada já cadastrada!".
Tabela 17 - Cadastrar Área
Nome Cadastrar Área
Atores Síndico
Pós-Condições Área cadastrada;
Área como nome, etc.
3. O caso de uso verifica se a Área
informada já não foi cadastrada;
“Área cadastrada com sucesso!";
3.1 Se a Área informada já existir no
sistema;
3.2 Apresentar a mensagem: "Área
informada já cadastrada!".

70
Tabela 18 - Cadastrar Despesa
Nome Cadastrar Despesa
Atores Síndico
Pós-Condições Despesa cadastrada;
2. O usuário insere as informações
da Despesa como Tipo, descrição,
valor, etc.
3. O caso de uso registra as
informações;
4. O caso de uso apresenta a
mensagem: “Despesa cadastrada
com sucesso!";
Tabela 19 - Cadastrar Moradores
Nome Cadastrar Moradores
Atores Síndico
Pós-Condições Morador cadastrado no sistema
2. O usuário insere o CPF do morador:
3. O caso de uso verifica se o morador já
possui cadastro no sistema:
4. O caso de uso verifica se a unidade
indicada para o morador existe;
"Morador cadastrado com sucesso!”.
3.1 Se já houver o cadastro do
Morador indicado:
mensagem: "Morador já possui
cadastro!".
4.1 Se não existira unidade informada:
mensagem: "Unidade informada não
existe!”.

71
Tabela 20 - Cadastrar Tipo de Obra
Nome Cadastrar Tipo de Obra
Atores Administrador
Pré-condições Estar logado no sistema;
Pós Condições Tipo de Obra cadastrado no sistema;
Tipo de Obra;
3. O caso de uso verifica se o tipo de obra
já foi cadastrado anteriormente.
“Tipo de Obra cadastrado com sucesso!";
3.1 Se já existir um cadastro com o tipo
informado:
mensagem: “Tipo de Obra informado já
cadastrado!".
Tabela 21 - Cadastrar Tipo de Conta
Nome Cadastrar Tipo de Conta
Pós Condições Tipo de Conta cadastrado no sistema;
Tipo de Conta;
3. O casode uso verifica seo tipo de conta
“Tipo de Conta cadastrado com
sucesso!";
informado:
mensagem: “Tipo de conta informado já
cadastrado!".

72
Tabela 22 - Cadastrar Tipo de Serviço
Nome Cadastrar Tipo de Serviço
Pós Condições Tipo de Serviço cadastrado no sistema;
Tipo de Serviço;
3. O caso de uso verifica se o tipo de
serviço já foi cadastrado anteriormente.
“Tipo de Serviço cadastrado com
sucesso!";
informado:
mensagem: “Tipo de serviço informado já
cadastrado!".
Tabela 23 - Cadastrar Cargo
Nome Cadastrar Cargo
Pós Condições Cargo cadastrado no sistema;
Cargo;
3. O casode uso verifica seo tipo de cargo
“Cargo cadastrado com sucesso!";
informado:
mensagem: “Tipo de cargo informado já
cadastrado!".

73
5 BANCO DE DADOS
O banco de dados modelado para o sistema passou por diversas etapas de
normalização até que a estrutura das tabelas estivesse organizada.
O Modelo Entidade Relacional foi realizado baseando-se nas informações
conseguidas pela análise de sistemas e pelos primeiros diagramas UML realizados, o
de caso de uso. Com isso gerando um desenho do banco de dados, descrevendo as
entidades e relações que foram visualizadas para o sistema, fazendo assim que o
mesmo fique dentro dos padrões de modelagem mais atuais.
5.1 Modelo Entidade-Relacionamento
É definido como um modelo conceitual utilizado na Engenharia de Software
para descrever as entidades envolvidas em um domínio de negócios. Em geral,
representa de forma abstrata a estrutura do banco de dados do sistema.
Fonte: Elaboração Própria
Figura 34 - Modelo ER referente a entidade Pessoa com todas suas relações e entidades vinculadas

74
Figura 35 - Entidades Voto e Funcionário com suas respectivas relações

75
Figura 36 - Entidade Unidade com suas respectivas relações

76
Figura 37 - Entidade Obra com suas respectivas relações

77
Figura 38 - Entidade Condomínio com suas respectivas relações
5.2 Diagrama Entidade-Relacionamento
Enquanto o MER é um modelo conceitual, o DER é uma representação gráfica
do banco de dados. Este facilita a análise e programação de todo o sistema.
Desta forma, não deve existir redundância de dados e nem uma forte
dependência mantendo o sistema com uma acoplação menor, sendo possível realizar
mudanças em partes do software sem que a mesma altere ou gere problemas em
partes, facilitando a manutenção e possíveis updates.

78
Figura 39 - Diagrama ER – Pessoa e suas respectivas relações

79
Figura 40 - Entidade Pessoa e suas especializações.

80
Figura 41 - Diagrama ER – Reclamação e Sugestão e suas respectivas relações
Figura 42 - Diagrama ER - Unidade e suas respectivas relações

81
6 PROTOTIPAÇÃO
Foram selecionadas algumas telas do sistema para demonstrar alguns de
seus componentes. O restante das telas pode ser encontrado no Apêndice A.
Figura 43 - Protótipo do Menu Principal
Esta é a tela principal do sistema. Nela estão contidos os botões de todas as
funcionalidades permitidas ao usuário. Os botões maiores são as mais utilizadas (de
acordo com a entrevista realizada com o síndico do condomínio utilizado como objeto
de estudo), enquanto estas e as demais funções encontram-se na parte superior da
tela.
Vale lembrar que esta tela é a que será exibida ao síndico, com todas as
funcionalidades das quais o sistema dispõe.

82
Tabela 24 - Menu Principal
ID Nome
OBG
S/N
Descrição
1 btn_pessoa sim
Redireciona para a tela de cadastro de
pessoa onde se pode incluir, alterar ou
excluir registros.
2 btn_morad sim
moradores onde se pode incluir, alterar
ou excluir registros.
3 btn_und sim
unidades onde se pode incluir, alterar ou
excluir registros.
4 btn_visitas sim
visitas onde se pode incluir registros.
5 btn_veiculos sim
veículos onde se pode incluir, alterar ou
excluir registros.
6 btn_eventos sim
eventos onde se pode incluir, alterar ou
excluir registros.
7 btn_contrec sim
contas a receber onde se pode incluir,
alterar ou excluir registros.
8 btn_contpag sim
contas a pagar onde se pode incluir,
alterar ou excluir registros.
9 btn_servico sim
serviços onde se pode incluir, alterar ou
excluir registros.
10 mi_moradores sim
Exibe um menu com as funcionalidades
do morador.
11 mi_operacional sim
do funcionário.
12 mi_evento sim
dos eventos.
13 mi_parametros sim
dos tipos de títulos que podemos ter,
como tipo de conta, tipo de obra, tipo de
serviço e cargo.

83
Figura 44 - Protótipo - Pessoas Físicas/Jurídicas - Dados
Esta tela refere-se à busca realizada no cadastro de pessoa. Pode-se filtrar as
informações a serem buscadas, pelo Nome ou Documento da pessoa. Ao clicar no
registro desejado duas vezes ou clicar em Alterar Pessoa, a mesma é direcionada
para a tela de cadastro.

84
Tabela 25 - Cadastro de Pessoa
ID Nome
OBG
S/N
Descrição
1 txt_cod sim Insere o código da pessoa.
2 txt_rzsocial sim Insere a razão social da pessoa.
3 rdb_fisica sim Marca se a pessoa for física.
4 rdb_juridic sim Marca se a pessoa for jurídica.
5 txt_nome sim Insere o nome da pessoa.
6 dtp_datanasc sim Insere a data de nascimento da pessoa.
7 txt_cpfcnpj sim Insere o CPF ou CNPJ da pessoa.
8 txt_rgie sim Insere o RG ou IE da pessoa.
9 btn_nvpessoa sim Salva os dados inseridos no sistema.
10 btn_altera sim Altera o cadastro da pessoa selecionada.
11 btn_exclui sim
Desativa o cadastro da pessoa
selecionada.
12 btn_voltar sim Retorna ao menu principal.
13 tb_pesquisa sim Exibe a tela de pesquisa de pessoas.
14 tb_dados sim Exibe a tela de dados de pessoas.
15 tb_end sim Exibe a tela de endereço de pessoas.
16 tb_tel sim Exibe a tela de telefone da pessoa.
17 lbl_cod sim Informa o Código da pessoa.
18 lbl_rzsocial sim Informa a razão social da pessoa.
19 lbl_fisica sim Informa que a pessoa informada é física.
20 lbl_juridic sim
Informa que a pessoa informada é
jurídica.
21 lbl_nome sim Informa o Nome da pessoa.
22 lbl_datanasc sim Informa a data de nascimento da pessoa.
23 lbl_cpfcnpj sim Informa o CPF ou CNPJ da pessoa.
24 lbl_rgie sim Informa o RG ou IE da pessoa.

85
Figura 45 - Protótipos - Pessoas Físicas/Jurídicas - Pesquisa
Esta tela contém os dados para o cadastro da pessoa. Esta precisa informar o
Nome, Documento e se esta é física ou jurídica. O restante dos campos é opcional:
razão social, data de nascimento e RG/Inscrição Estadual.

86
Tabela 26 - Pesquisa Pessoa
ID Nome
OBG
S/N
Descrição
1 tb_pesquisa sim Exibe a tela de pesquisa de pessoas.
2 tb_dados sim Exibe a tela de dados de pessoas.
3 tb_end sim Exibe a tela de endereço de pessoas.
4 tb_tel sim Exibe a tela de telefone da pessoa.
5 cbx_filtropes sim
Informa qual o dado que será
pesquisado. Nome ou RG por exemplo.
6 txt_filtropes sim
Insere qual o dado que será pesquisado.
Nome ou RG por exemplo.
7 btn_pesqpes sim
Executa a pesquisa de acordo com o
filtro aplicado.
8 dgv_pesq sim Exibe os resultados da pesquisa.
9 btn_nvpessoa sim Redireciona para o cadastro de pessoa.
10 btn_altera sim Altera o cadastro da pessoa selecionada.
11 btn_exclui sim
Desativa o cadastro da pessoa
selecionada.

87
Figura 46 - Protótipos - Reclamações e Sugestões
Nesta tela são cadastradas as reclamações e sugestões informando a Pessoa
que está cadastrando, um título e uma descrição para o mesmo e o tipo. Logo abaixo
tem-se os botões para incluir e excluir e retornar ao menu principal.

88
Tabela 27 - Reclamações e Sugestões
ID Nome
OBG
S/N
Descrição
1 tb_pesquisa sim
Exibe a tela de pesquisa de reclamações
ou sugestões.
2 tb_cadreclsug sim
Exibe a tela de cadastro de reclamações
ou sugestões.
3 txt_codpes sim
Insere o código da pessoa que está
inserindo a reclamação ou sugestão.
4 txt_nome sim
Insere o nome da pessoa que está
inserindo a reclamação ou sugestão.
5 btn_pesquisa sim
Executa a pesquisa de acordo com os
dados informados.
6 rdb_recla sim
Marca se o cadastro for uma
reclamação.
7 rdb_suge sim Marca se o cadastro for uma sugestão.
8 txt_titulo sim
Insere o título da reclamação ou
sugestão.
9 txt_descr sim
Insere a descrição da reclamação ou
sugestão.
10 btn_nvrecla sim Registra a reclamação no sistema.
11 btn_nvsuge sim Registra a sugestão no sistema.
12 btn_exclui sim
Desativa a reclamação ou sugestão
selecionada.
14 lbl_codpes sim
Informa o código da pessoa que irá
registrar a reclamação ou sugestão.
15 lbl_nome sim
Informa o nome da pessoa que irá
registrar a reclamação ou sugestão.
16 lbl_titulo sim
Informa o título da reclamação ou
sugestão.
17 lbl_descr sim
Informa a descrição da reclamação ou
sugestão.
18 lbl_recla sim
Informa que informação inserida é uma
reclamação.
19 lbl_suge sim
Informa que informação inserida é uma
sugestão.

89
7 ARQUITETURA
Foi utilizado para o desenvolvimento do projeto o padrão de arquitetura ECB
(Entity, Controller, Boundary). Este padrão permite realizar a divisão de
responsabilidades dentro das classes. Fazendo uma separação entre classes com
estereótipos diferentes, responsáveis por funções distintas dentro do sistema.
As classes de Entidade ficam responsáveis pela persistência dos dados, tendo
em si apenas os atributos relacionados a entidade e os métodos assessores, getters
e setters, por questão do encapsulamento, um dos pilares da Orientação a Objeto. As
classes de Controle têm como função realizar a parte lógica do sistema, ou seja,
manter as regras de negócio do software. E por fim as classes do estereótipo de
Fronteira realizam a comunicação com tudo além do software, são responsáveis pela
comunicação com o mundo exterior. No caso, acesso ao banco de dados e
comunicação com o usuário.
Dessa forma consegue-se manter o sistema com um baixo acoplamento e alta
coesão. Sendo diferente de um monolítico com atributos e métodos agrupados,
perpetuando classes com responsabilidades que não são suas. Isso torna o software
muito mais flexível, dispondo de um melhor preparo para mudanças e atualizações.
Além de permitir que o mesmo tenha um menor risco de sofrer efeitos colaterais,
provenientes dessas alterações, ou até mesmo de falhas e correções que venham a
surgir. Exatamente pelo fato do mesmo ter uma menor dependência.
7.1 Diagrama de Classes e Sequência
Diagrama de classes correlacionado ao objeto do tipo Pessoa. O mesmo possui
Endereço e Telefone em classes de Entidade separadas para manter a Normalização.
 Diagrama de Classe – Pessoa
O diagrama de sequência foi gerado para mostrar como os casos de uso são
realizados dentro das classes. Existem dois casos relacionados a entidade Pessoa. O

90
cadastro de uma nova Pessoa no sistema e a busca de registros dentro do banco de
dados.
Figura 47 - Diagrama de Classes - Pessoa

91
 Diagrama de sequência – Cadastrar Pessoa
1 – Usuário inicia o cadastro de Pessoa.
1.1 - É instanciado um objeto Pessoa.
1.2 – E instanciado um objeto do tipo Endereço, contendo uma referência a pessoa.
1.3 – É instanciado um objeto do tipo Telefone, contendo uma referência a pessoa.
1.4 – Os objetos são passados para o Controller para que o mesmo realize as
verificações necessárias.
1.4.1 – A PessoaDAO realiza query para salvar o objeto Pessoa no banco de dados.
1.4.2 – A EnderecoDAO realiza uma query para salvar o objeto Endereço no banco
de dados referenciando a Pessoa.
Figura 48 - Diagrama de Sequência - Cadastrar Pessoa

92
1.4.3 – A TelefoneDAO realiza uma query para salvar o objeto Telefone no banco de
dados referenciando a Pessoa.
É retornada uma mensagem para o Usuário.
1-
Usuário inicia o método de Buscar Pessoa na View.
1.1 – O sistema realiza as verificações dentro do Controller e passa a informação para
o DAO.
1.1.1 - A DAO realiza a consulta no banco de dados.
1.1.1.1 - É criado um objeto do tipo Lista contendo as Pessoas que foram trazidas do
banco.
Figura 49 - Diagrama de Sequência - Buscar Pessoa

93
A entidade Visita tem como atributos O Visitante e a Unidade que o mesmo vai visitar.
Figura 50 - Diagrama de Classes - Visita

94
1 – Usuário inicia o método de cadastro da Visitante na View.
1.1 – É instanciado o objeto Visita.
1.2 – A Controller realiza a verificação dos dados.
1.2.1 – A VisitaDAO realiza a query de inserção no banco de dados.
É retornado uma mensagem para o Usuário.
Figura 51 - Diagrama de sequência evidenciando o caso de uso Cadastrar Visita

95
A entidade ReclamSugest tem como atributo Unidade, que identifica quem fez
a reclamação ou sugestão.
Figura 52 - Diagrama de Classes - Reclamações e Sugestões

96
Figura 53 - Diagrama de sequência evidenciando o caso de uso Cadastrar Sugestão e Cadastrar
Reclamação.
1 – Usuário inicia o método de Criar Reclamação e Sugestão na View.
1.1 – Instância o objeto ReclamSugest.
1.2 – Controller realiza as verificações necessárias e chama o método da DAO.
1.2.1 – O ReclamSugestDAO realiza a query para inserção dos dados no banco de
dados.
7.2 Visão de implementação
A modelagem do sistema foi baseada no padrão MVC (Model, View e
Controller).
É um padrão de desenvolvimento realizado em camadas. Fazendo a separação
dos pacotes da seguinte forma: uma camada de Model, onde ficam as classes que
realizam a conexão com o banco de dados e as que realizam a persistência deles
dentro do sistema; a camada de Controller, que mantêm as regras de negócio; e, por
fim, a camada de View, onde ficam as classes que realizam a comunicação com o
usuário.

97
Um dos principais benefícios de se desenhar a arquitetura do sistema com o
padrão MVC é a reutilização de código. Onde é possível realizar uma alteração em
uma camada sem ter problemas com outras, seguindo o restante do fluxo da
arquitetura, sem precisar alterá-la. Além de poder criar novas funcionalidades para o
sistema de forma mais eficientes e sem a necessidade repetir o código. Utilizando as
camadas adjacentes que já realizam o restante das responsabilidades atribuídas.
Figura 54 - Diagrama de Pacotes

98
7.3 Representação do Fluxo
7.3.1 Diagramas de Atividade
Os diagramas foram construídos para representar o fluxo de atividade, assim
trazendo um entendimento melhor da utilização dos casos de uso que foram
representados nessa sessão.
Figura 55 - Diagrama de Atividade – Cadastrar Pessoa

99
Figura 56 - Diagrama Atividade – Buscar Pessoa

100
Figura 57 - Diagrama de Atividade – Cadastro de Visita

101
Figura 58 - Diagrama de Atividade – Cadastra Reclamações e Sugestões

102
CONCLUSÃO
É de extrema importância a necessidade de estabelecer processos coerentes,
para que o funcionamento do software esteja de acordo com as ideiasiniciais. Durante
o processo ocorreram diversas mudanças e tivemos que adaptar as soluções já pré-
estabelecidas para os novos conceitos que foram absorvidos na sala de aula durante
o processo de desenvolvimento do software.
Conclui-se então que a apesar da organização prevista, também é necessário
ter flexibilidade para conciliar novos atributos visando sempre a inovação do produto
final.

103
BIBLIOGRAFIA
LARMAN, CRAIG. Diagrama de classes UML: Aplicação de UML: notação comum de
diagrama de classes. In:_____. Utilizando UML e Padrões. Porto Alegre:
BOOKMAN, 2007.cap. 16.1.
BOOCH, GRADY. Diagramas. In:_____. UML: Guia do usuário. Rio de Janeiro:
ELSERVIER. 2012. cap. 7.
SINTES, ANTHONY. Padrões avançados de projeto. In:_____. Aprenda
Programação Orientada a Objeto em 21 dias. São Paulo: PEARSON EDUCATION
DO BRASIL, 2002. Cap. 12.
BEZERRA, EDUARDO. Modelagem de atividades. In:____. Princípios de Análise e
Projeto de Sistema com UML. Rio de Janeiro. ELSEVIER, 2015. cap. 10.
REVISTABW. Introdução ao banco de dados. Revista Brasileira de Web:
Tecnologia. Disponível em http://www.revistabw.com.br/revistabw/uml-diagrama-de-
pacotes/. Criado em: 02/01/2013. Última atualização: 24/07/2015. Visitado em:
12/04/2017.
TIBEL, DOUGLAS. Orientações básicas na elaboração de um diagrama de classes.
Devmedia. Disponível em: http://www.devmedia.com.br/orientacoes-
basicas-na-elaboracao-de-um-diagrama-de-classes/37224. Acesso em:
02/03/2017.

104
Wagner, Jean. Padrões de Projeto de Software Baseado em Componentes Aplicados
a um Sistema Java para Academia de Musculação. Devmedia. Disponível em:
http://www.devmedia.com.br/padroes-de-projeto-de-software-baseado-em-
componentes-aplicados-a-um-sistema-java-para-academia-de-musculacao/19138.
Acesso em: 17/03/2017.
RODRIGUES, Joel. Modelo Entidade Relacionamento (MER) e Diagrama Entidade-
Relacionamento (DER). Devmedia. Disponível em:
http://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-
entidade-relacionamento-der/14332 . Acesso em: 17/03/2017.

105
APÊNDICE A – PROTÓTIPOS
Figura 59 - Menu Principal
Figura 60 - Cadastro do Condomínio

106
Figura 61 - Cadastro de Blocos
Figura 62 - Cadastro de Blocos

107
Figura 63 – Unidades - Dados
Figura 64 - Unidades - Pesquisa

108
Figura 65 - Veículos - Dados
Figura 66 - Veículos - Pesquisa

109
Figura 67 - Pessoas Físicas/Jurídicas - Dados
Figura 68 - Pessoas Físicas/Jurídicas - Pesquisa

110
Figura 69 - Pessoas Físicas/Jurídicas - Telefones
Figura 70 - Pessoas Físicas/Jurídicas - Endereços

111
Figura 71 - Votar Enquetes - Dados
Figura 72 - Votar Enquetes - Pesquisa

112
Figura 73 - Enquetes - Dados
Figura 74 - Enquetes - Pesquisa

113
Figura 75 - Contas a Pagar - Dados
Figura 76 - Contas a Pagar - Pesquisa

114
Figura 77 - Contas a Receber - Dados
Figura 78 - Contas a Receber - Pesquisa

115
Figura 79 - Obras - Dados
Figura 80 - Obras - Pesquisa

116
Figura 81 - Terceiros - Dados
Figura 82 - Terceiros - Pesquisa

117
Figura 83 - Reclamações e Sugestões - Dados
Figura 84 - Reclamações e Sugestões - Pesquisa

118
Figura 85 - Funcionários - Dados
Figura 86 - Funcionários - Pesquisa

119
Figura 87 - Eventos - Dados
Figura 88 - Eventos - Pesquisa

120
Figura 89 - Cadastro de Áreas - Dados
Figura 90 - Cadastro de Áreas - Pesquisa

121
Figura 91 - Parâmetros - Cargos
Figura 92 - Parâmetros - Contas

122
Figura 93 - Parâmetros - Obras
Figura 94 - Parâmetros - Serviços

123
Figura 95 - Morador - Pesquisa
Figura 96 - Morador - Dados

124
APÊNDICE B – SCRIPT SQL
create database bdcondominio;
use bdcondominio;
create table Pessoa
(
ID_PESSOA int PRIMARY KEY auto_increment,
RAZAOSOCIAL varchar(50) NOT NULL,
NOME varchar(40) NOT NULL,
DATANASC datetime,
DOCUMENTO varchar(14) UNIQUE NOT NULL,
RG_IE varchar(12),
TIPOPESSOA char(1)
);
create table Telefone
(
ID_TELEFONE int PRIMARY KEY auto_increment,
TELEFONE varchar(15) NOT NULL,
ID_PESSOA INT NOT NULL,
foreign key (ID_PESSOA) references Pessoa(ID_PESSOA)
);
create table Endereco
(
id_endereco int primary key auto_increment,
logradouro varchar(60) not null,
numero int not null,
complemento varchar(20),
bairro varchar(30),
cidade varchar(30) not null,

125
estado char(2) not null,
id_pessoa int not null,
foreign key (id_pessoa) references Pessoa(id_pessoa)
);
create table Condominio
(
id_condominio int primary key auto_increment,
nome varchar(50) not null,
dtinauguracao date
);
create table Bloco
(
id_bloco int primary key auto_increment,
identificacao varchar(20) not null,
qtdandares int,
id_condominio int not null,
foreign key (id_condominio) references Condominio(id_condominio)
);
create table Proprietario
(
id_proprietario int primary key auto_increment,
foreign key (id_Pessoa) references Pessoa(id_pessoa)
);
create table Unidade
(
id_unidade int primary key auto_increment,
identificacao varchar(10) not null,
area int,
id_bloco int not null,
id_proprietario int not null,
foreign key (id_bloco) references Bloco(id_bloco),

126
foreign key (id_proprietario) references Proprietario (id_proprietario)
);
create table ReclamSugest
(
id_rs int primary key auto_increment,
titulo varchar(30),
descricao varchar(100),
foreign key (id_pessoa) references Pessoa (id_pessoa)
);
create table Login
(
id_login int primary key auto_increment,
usuario varchar(10),
senha varchar(8),
);
create table Morador
(
id_morador int primary key auto_increment,
id_unidade int not null,
foreign key (id_pessoa) references Pessoa(id_pessoa),
foreign key (id_unidade) references Unidade(id_unidade)
);
create table Veiculo
(
id_veiculo int primary key auto_increment,
placa varchar(7) not null,
modelo varchar(30),

127
);
create table Enquete
(
id_enquete int primary key auto_increment,
pergunta varchar(60) not null,
resposta1 char(1) not null,
resposta2 char(1) not null
);
create table Voto
(
id_voto int primary key auto_increment,
id_enquete int not null,
resposta char(1) not null,
foreign key (id_pessoa) references Pessoa(id_pessoa),
foreign key (id_enquete) references Enquete(id_enquete)
);
create table Cargo
(
id_cargo int primary key auto_increment,
descricao varchar(30) not null
);
create table Funcionario
(
id_funcionario int primary key auto_increment,
id_cargo int not null,
foreign key (id_cargo) references Cargo(id_cargo),
);

128
create table TipoServ
(
id_tiposerv int primary key auto_increment,
);
create table Terceiro
(
id_terceiro int primary key auto_increment,
id_tiposerv int not null,
foreign key (id_tiposerv) references TipoServ(id_tiposerv),
);
create table Evento
(
id_evento int primary key auto_increment,
titulo varchar(30),
dtevento date,
);
create table Area
(
id_area int primary key auto_increment,
descricao varchar(20) not null,
reserva boolean
);
create table AreaEvento
(
id_areaevento int primary key auto_increment,
id_evento int not null,
id_area int not null,

129
foreign key (id_evento) references Evento(id_evento)
);
create table TipoObra
(
id_tipoobra int primary key auto_increment,
descricao varchar(50)
);
create table Obra
(
id_obra int primary key auto_increment,
id_area int not null,
id_tipoobra int not null,
foreign key (id_area) references Area(id_area),
foreign key (id_tipoobra) references Obra(id_tipoobra)
);
create table TerceiroObra
(
id_terceiroobra int primary key auto_increment,
id_terceiro int not null,
id_obra int not null,
foreign key (id_terceiro) references Terceiro(id_terceiro),
foreign key (id_obra) references Obra(id_obra)
);
create table TipoConta
(
id_tipoconta int primary key auto_increment,
);
create table ContaPagar
(

130
id_contapagar int primary key auto_increment,
valor double,
valorpago double,
datapagto datetime,
id_terceiro int not null,
id_tipoconta int not null,
foreign key (id_terceiro) references Terceiro(id_terceiro),
foreign key (id_condominio) references Condominio(id_condominio),
foreign key (id_tipoconta) references TipoConta(id_tipoconta)
);
create table ContaReceber
(
id_contareceber int primary key auto_increment,
valor double,
foreign key (id_condominio) references Condominio(id_condominio),
);
create table Visitante
(
id_visitante int primary key auto_increment,
nome varchar(40),
rg varchar(10) unique
);
create table Visita
(
id_visita int primary key auto_increment,
id_unidade int primary key,
data datetime,
id_visitante int primary key,

131
foreign key (id_unidade) references Unidade(id_unidade),
foreign key (id_visitante) references Visitante(id_visitante)
);

132
APÊNDICE C - DIAGRAMA DE CLASSES
O diagrama de classes foi fragmentado para que pudesse ser melhor entendido
no trabalho escrito.
Mostrando as relações tidas pelas classes em suas diferentes camadas de
responsabilidade.
Foi utilizada como base da fragmentação as classes de persistência de dados,
Entity.
Figura 97 - Classes Área

133
Figura 99 - Classes Aviso
Figura 98 - Classe Bloco

134
Figura 100 - Classe Condomínio

135
Figura 101 - Classe Contas à Pagar

136
Figura 102 - Classe Conta à Receber

137
Figura 103 - Classe Evento – Área

138
Fonte: Elaboração própria
Fonte: Elaboração própria
Figura 104 - Classe Login
Figura 105 - Classe Morador

139
Figura 106 - Classe Obra
Figura 107 - Classe Proprietário

140
Figura 108 - Classe Reclamação e Sugestão

141
Figura 109 - Classe Terceiro

142
Figura 110 - Classe Unidade
Figura 111 - Classe Veiculo

143
Figura 113 - Classe Visita – Visitante
Figura 112 - Classe Voto – Enquete

Condo master

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Semelhante a Condo master

Semelhante a Condo master (20)

Condo master