INSTITUTO FEDERAL DO PARANÁ
MATHEUS ANDRÉ MARQUES DA SILVA
MATHEUS OLIVEIRA SILVA
Sistema de Gerenciamento Imobiliário
PARANAGUÁ
2012
MATHEUS ANDRÉ MARQUES DA SILVA
MATHEUS OLIVEIRA SILVA
Sistema de Gerenciamento Imobiliário
Trabalho
de
Conclusão
de
Curso
apresentado ao Curso Técnico de Informática do
Instituto Federal do Paraná – Campus Paranaguá,
como requisito parcial de avaliação.
Orientador: Gil Eduardo de Andrade.
PARANAGUÁ
2012
“Primeiro a Deus e depois aos nossos pais e avós”
AGRADECIMENTOS
Agradecemos primeiramente a Deus, pois ele é o criador de todo esse
universo, tem todo o poder, e foi ele quem deu toda a força e segurança para
chegarmos até aqui.
Os nossos pais pelo suporte, carinho, apoio, confiança e suprimento de
necessidades básicas desde sempre.
Ao nosso querido orientador Prof. Gil que se manteve sempre disponível,
flexível e disposto a ajudar e apoiar, com criticas muito construtivas e fundamentais.
A todos os professores que passaram por nós desde o ensino primário até o 3º ano
do Ensino Médio, cada uma tem sua parcela de contribuição.
Por fim as amizades que adquirimos no decorrer desses três anos, que
sempre nos deram muito apoio para a conclusão deste projeto.
“A alegria esta na luta, no
sofrimento envolvido e não
na vitória propriamente dita”.
(Mahatma Gandhi)
“Choramos ao nascer
porque chegamos a este
imenso cenário de
dementes.”
(William Shakespeare)
RESUMO
Atualmente é visto nas imobiliárias da região que o controle interno na realização de
suas operações e feito de maneira rudimentar, faltando confiabilidade no
armazenamento de dados e
na garantia de serviços. Contudo verificando uma
escassa eficiência na realização das operações da imobiliária, dando a perceber que
não há controle interno automatizado e/ou informatizado. Então para solucionar
estes problemas surge o software deste projeto, realizado na plataforma Java devido
a sua portabilidade, gerará otimização da produção, confiabilidade de informações,
garantia de serviços e geração de metas de produção.
Palavras-chaves: Rudimentar, informatizado, garantia.
ABSTRACT
It's currently seen in real estates in the region that internal control in
conducting their operations have been done in a rudimentary way, lacking reliability
in data storage and warranty services. But checking a low efficiency in the
transactions, giving the impression that there is no internal control automated and / or
computerized. So, to solve these problems, this software project has been
developed, performed on the Java platform due to its portability, generate production
optimization, reliability of information, assurance services and generation of
production goals.
Keywords: Rudimentary, warranty, automated.
SUMÁRIO
1.
INTRODUÇÃO .................................................................................................................. 12
1.1
MOTIVAÇÃO ................................................................................................................. 12
1.2
DESAFIO ....................................................................................................................... 12
1.3
OBJETIVO ..................................................................................................................... 13
1.4
2.
2.1
2.2
1.3.1
GERAL ................................................................................................................. 13
1.3.2
ESPECÍFICO ....................................................................................................... 13
CONTRIBUIÇÕES ESPERADAS ................................................................................. 13
FUNDAMENTAÇÃO TEÓRICA ........................................................................................ 14
ENGENHARIA DE SOFTWARE ................................................................................... 14
2.1.1
CICLO DE VIDA CLÁSSICO ............................................................................... 14
2.1.2
PROTOTIPAÇÃO ................................................................................................ 16
2.1.3
O MODELO ESPIRAL ......................................................................................... 17
2.1.4
TÉCNICAS DE QUARTA GERAÇÃO ................................................................. 19
2.1.5
ESTUDO DE VIABILIDADE ................................................................................ 20
2.1.6
ANÁLISE DE RISCOS ......................................................................................... 21
2.1.7
PRA QUE REALIZAR A MODELAGEM DO SISTEMA?..................................... 22
UNIFIED MODELING LANGUAGE (UML) .................................................................... 23
2.2.1
HISTÓRIA ............................................................................................................ 23
2.2.2
DIAGRAMA DE CLASSES .................................................................................. 24
2.2.3
DIAGRAMA DE CASOS DE USOS ..................................................................... 24
2.3
ORIENTAÇÃO A OBJETOS ......................................................................................... 26
2.4
JAVA .............................................................................................................................. 28
2.5
BANCO DE DADOS ...................................................................................................... 30
3.
3.1
2.5.1
MODELO CONCEITUAL ..................................................................................... 31
2.5.2
MODELO ENTIDADE-RELACIONAMENTO ....................................................... 32
2.5.3
MODELO RELACIONAL ..................................................................................... 33
METODOLOGIA ............................................................................................................... 34
ESTUDO DE VIABILIDADE .......................................................................................... 34
3.2
REQUISITOS ................................................................................................................ 35
3.3
FUNCIONAMENTO DA IMOBILIARIA .......................................................................... 36
3.4
GERAÇÃO DE RELATÓRIOS PDF .............................................................................. 37
3.4.1
FUNCIONAMENTO DA ITEXPDF 5.1.3 .............................................................. 38
3.4.2
MÉTODOS ........................................................................................................... 38
3.4.3
VISUALIZAÇÃO DE ARQUIVO PDF NO SISTEMA ........................................... 39
3.4.4
CÓDIGO .............................................................................................................. 40
3.5
DIAGRAMA DE CASO DE USO ................................................................................... 41
3.6
DIAGRAMA DE CLASSES ............................................................................................ 43
3.7
MODELO ENTIDADE RELACIONAMENTO ................................................................. 43
3.8
MODELO RELACIONAL ............................................................................................... 45
4.
RESULTADOS OBTIDOS ................................................................................................ 46
5.
CONCLUSÃO ................................................................................................................... 59
6.
REFERÊNCIAS ................................................................................................................. 60
SUMÁRIO DE FIGURAS
Figura 1 Ciclo de vida clássico<engenhariadompedroii. blogspot.com> ................................. 15
Figura 2 Protipação<centraldaengenharia. wordpress.com> .................................................. 17
Figura 3 modelo espiral <centraldaengenharia.wordpress.com> ............................................ 18
Figura 4 Técnicas da quarta geração (4GT)<tec4rup. wordpress.com> ................................. 20
Figura 5 Exemplo de diagrama de classes .............................................................................. 24
Figura 6 Exemplo de diagrama de casos de uso ..................................................................... 25
Figura 7 Ator diagrama de casos de uso ................................................................................. 25
Figura 8 Caso de uso digrama casos de uso ........................................................................... 26
Figura 9 Associação diagrama de casos de uso...................................................................... 26
Figura 10 Exemplo de classe ................................................................................................... 27
Figura 11 Exemplo de código em Java .................................................................................... 30
Figura 12 Entidade do Modelo ER ........................................................................................... 32
Figura 13 Atributo do Modelo ER ............................................................................................. 32
Figura 14 Exemplo de tabelas no MER <renan-m-levy.blogspot.com> ................................... 33
Figura 15 Classes para geração PDF ...................................................................................... 38
Figura 16 Exemplo de código para geração de um documento PDF ...................................... 39
Figura 17 Classes importadas do PDFView ............................................................................. 39
Figura 18 Exemplo de código para visualizar um documento PDF ......................................... 40
Figura 19 Diagrama de casos de uso do SGI .......................................................................... 42
Figura 20 Diagrama de classes do SGI ................................................................................... 43
Figura 21 MER do SGI ............................................................................................................. 44
Figura 22 MR do SGI ................................................................................................................ 45
Figura 23 Tela de Login SGI .................................................................................................... 46
Figura 24 Tela inicial do SGI .................................................................................................... 47
Figura 25 Tela Inserir Imóvel Comercial .................................................................................. 48
Figura 26 Tela Inserir Imóvel Residencial ................................................................................ 49
Figura 27 Tela de busca dos imóveis ....................................................................................... 50
Figura 28 Tela laudo parte Objeto da Avaliação ...................................................................... 51
Figura 29 Tela laudo parte Especificações Técnicas ............................................................... 52
Figura 30 Tela laudo parte Anexo de Arquivos ........................................................................ 53
Figura 31 Tela Inserir Pessoa Física ........................................................................................ 54
Figura 32 Tela Inserir Pessoa Jurídica ..................................................................................... 55
Figura 33 Tela Inserir Corretor ................................................................................................. 56
Figura 34 Tela Operação Venda .............................................................................................. 57
Figura 35 Tela Operação Locação ........................................................................................... 58
12
1. INTRODUÇÃO
1.1
MOTIVAÇÃO
A modernidade trás a ideia que se deve sempre buscar a automação, a
informatização do maior número de processos decorrentes no dia-a-dia, para
garantir praticidade, segurança e eficiência.
Com base nesse paradigma, propõe-se o desenvolvimento de um software
para a imobiliária Família Feliz, situada na cidade de Paranaguá. Atualmente a
imobiliária conta apenas com um simples site para divulgação de imóveis. Não
existe nenhum controle em relação às operações em que esta imobiliária realiza
juntamente com os objetos que participam delas, ou seja, não existe informatização
alguma. Procura-se a maior praticidade, segurança e eficiência dos processos que
nela são realizados, o que torna viável o desenvolvimento do sistema, pelo fato de
solucionar
estes
problemas
(falta
de
praticidade,
segurança,
eficiência),
informatizando a empresa e abrindo horizontes a ela no mercado.
1.2
DESAFIO
Os desafios aqui são dois:
 Atender a todos os requisitos apresentados pelo cliente.
 Apresentar o sistema funcionado e cumprindo com as expectativas do
cliente.
13
1.3
OBJETIVO
1.3.1 GERAL
Construir um sistema capaz de gerenciar as principais funções realizadas por
uma imobiliária na atualidade.
1.3.2 ESPECÍFICO
O sistema possuirá:

Cadastro de pessoas (clientes, funcionários, corretores);

Cadastro de imóveis;

Cadastro de operações;

Cadastro de laudos feitos por corretores

Geração de relatórios pdf referente as operações e objetos nelas
envolvidos (pessoas e imóveis);
1.4
CONTRIBUIÇÕES ESPERADAS
Verifica-se atualmente grande informatização em diversas áreas no mundo
real. E observa-se a falta desta informatização nas imobiliárias do litoral do Paraná,
resultando em ineficiência, falta de segurança e pouca garantia em funções básicas
como uma locação ou venda imobiliária. Entretanto o Sistema de Gerenciamento
Imobiliário(SGI) tem como premissa, auxiliar de forma eficiente a gestão interna de
uma imobiliária, pois irá contribuir com a garantia dos serviços básicos, dando
respaldo para que haja segurança e eficiência nos serviços prestados.
14
2. FUNDAMENTAÇÃO TEÓRICA
2.1
ENGENHARIA DE SOFTWARE
A engenharia de software é o estabelecimento e uso de sólidos princípios de
engenharia para que se possa obter economicamente um software que seja
confiável e que funcione eficientemente em máquinas reais. (Bauer1, 1969, citado
por PRESSMAN, 1995).
A engenharia de software é uma semente da Engenharia de hardware e
sistemas. Nela observam-se três essenciais elementos: métodos, ferramentas e
procedimentos.
Sobre estes elementos (Pressman, 1995, p.31-32)
Os métodos de engenharia de software proporcionam os detalhes de “como
fazer” para construir o software(...). As ferramentas de engenharia de
software proporcionam apoio automatizado ou semi-automatizado aos
métodos (...). Os procedimentos de engenharia de software constituem elo
que mantém juntos os métodos e as ferramentas e possibilita o
desenvolvimento racional e oportuno do software de computador.·.
A engenharia de software contempla diversas etapas que são o envolvimento
destes métodos, ferramentas e procedimentos. Estas diversas etapas que podem
ser chamadas de paradigmas da engenharia de software. O paradigma a ser
seguido é escolhido de acordo com os aspectos que estão presentes no projeto do
software como um todo. A seguir quatro paradigmas principais serão abordados.
2.1.1 CICLO DE VIDA CLÁSSICO
Na Figura 1 observa-se o ciclo de vida clássico da engenharia de software.
Em alguns momentos é chamado de modelo cascata, deve ser abordado de modo
sistemático, sequencial de acordo com o desenvolvimento do software. A seguir as
atividades que contém nele.
1
BAUER, F. Conferência NATO Science Committee. 1969.
15
Figura 1 Ciclo de vida clássico<engenhariadompedroii. blogspot.com>
1. Análise e engenharia de sistemas
Há o estabelecimento dos requisitos para todos os elementos do sistema,
depois se faz a atribuição de algum subconjunto desses requisitos ao software. É
uma visão fundamental do sistema, já que o software comunica-se com outros
elementos(hardware, pessoas, banco de dados). Há uma pequena intensidade de
coleta de requisitos.
2. Análise de requisitos de software
É intensificado o processo de coletas de requisitos e concentra-se
basicamente no software. Para entender qual será o tipo de sistema a ser construído
deve-se, dominar as informações, funções, desempenho e interface requisitados
pelo software.
3. Projeto
Processo que constitui vários passos, e concentra-se em quatro diferentes
atributos do programa: estrutura de dados, arquitetura de software, detalhes
procedimentais e caracterização de interface.
4. Codificação
16
O projeto é traduzido de uma forma que a máquina compreenda. Conhecida
como etapa de implementação, em o desenvolvedor escreve linhas de código.
5. Testes
Após o sistema ser codificado, existe a etapa de testes, em que se faz a
verificação das funções do sistema, observado se estão de acordo com o planejado
ou caso não esteja o porque isso não ocorre.
6. Manutenção
Etapa em que é feita a alteração do sistema, seja pelo fato de erros que
foram encontrados na etapa de testes, ou devido a uma nova necessidade do cliente
ou do meio onde o software está inserido.
Sobre o ciclo de vida clássico (Pressman, 1995, p.34)
O ciclo de vida clássico é o paradigma mais antigo e o mais amplamente
usado da engenharia de software. Porém, no decorrer da última década, as
críticas ao paradigma fizeram com que até mesmo seus defensores
questionassem sua aplicabilidade em todas as situações.
2.1.2 PROTOTIPAÇÃO
Quando o cliente define corretamente os objetivos gerais para o software,
mas não identifica os requisitos, ou quando o desenvolvedor não tem a certeza da
eficiência do software, a melhor forma é realizar o paradigma de prototipação.
Este processo da permissão ao desenvolvedor a criação de um modelo do
software que será implementado. Há três formas possíveis que o modelo pode
assumir:
1. Protótipo revelando as relações do homem com a máquina, dando grande
respaldo para se entender quantas e quais serão as relações no sistema.
2. Protótipo revelando as funções requisitadas pelo software.
3. Um software já existente que desempenha as mesmas funções, ou parte
delas, que serão melhoradas neste novo software.
A sequência de eventos que ocorre neste paradigma é descrita na Figura 2.
17
Figura 2 Protipação<centraldaengenharia. wordpress.com>
Sobre a prototipação (Pressman, 1995, p.37):
Idealmente, o protótipo serve como um mecanismo para identificar os
requisitos de software. Se um protótipo de trabalho for construído, o
desenvolvedor tentará usar fragmentos de programas existentes ou aplicará
ferramentas (por exemplo, geradores de relatórios, gerenciadores de
janelas etc.) que possibilitem que programas de trabalho sejam gerados
rapidamente.
2.1.3 O MODELO ESPIRAL
O modelo espiral é uma junção dos melhores aspectos dos outros dois
paradigmas citados acima (ciclo de vida clássico e prototipação), com o acréscimo
da análise de riscos que não contém nestes outros dois paradigmas. Nos quatro
quadrantes da Figura 3, há a abordagem das quatro fundamentais atividades do
modelo espiral, que são:
1 Planejamento: formalização de objetivos, opções e restrições.
2 Análise de riscos: análise de opções e revelação/resolução dos riscos.
3 Engenharia: construção do produto no “próximo nível”.
4 Avaliação do cliente: julgamento dos resultados da engenharia.
18
Figura 3 modelo espiral <centraldaengenharia.wordpress.com>
Sobre o modelo espiral (Pressman, 1995, p.40):
“O paradigma de modelo espiral para a engenharia de software atualmente
é a abordagem mais realística para o desenvolvimento de sistemas e de
software em grande escala. Ele usa uma abordagem “evolucionária” à
engenharia de software, capacitando o desenvolvedor e o cliente a entender
e reagir aos riscos em cada etapa evolutiva. O modelo espiral usa a
prototipação como um mecanismo de redução de riscos, mas, o que é mais
importante, possibilita que o desenvolvedor aplique a abordagem de
prototipação em qualquer etapa da evolução do produto. Ele mantém a
abordagem de passos sistemáticos sugerida pelo ciclo de vida clássico,
mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o
mundo real. O modelo espiral exige uma consideração direta dos riscos
técnicos em todas as etapas do projeto e, se adequadamente aplicado,
deve reduzir os riscos antes que eles se tornem problemáticos.”
Por fim observa-se que este paradigma requer grande experiência e
conhecimento por parte do(s) desenvolvedor(es). Vê-se também a dificuldade de
convencer o cliente do fato da abordagem ser evolutiva e controlável.
19
2.1.4 TÉCNICAS DE QUARTA GERAÇÃO
São várias ferramentas de software que dão possibilidade para o
desenvolvedor especificar certo atributo do software em alto nível e, com esta
especificação por parte do desenvolvedor a ferramenta constrói automaticamente
um código-fonte. Observa-se que quanto mais alto o nível de especificação mais
rápido será obtido o software. Este paradigma é a capacidade de se especificar
certo código a uma máquina de uma forma que este código esteja o mais perto
possível da linguagem natural.
Este paradigma tem inicio igual a dos outros paradigmas, que é a coleta de
requisitos. O cliente revela quais são os requisitos e estes são transformados em
modelos operacionais. Mais isto é muito complicado, pois o cliente pode não
conseguir descrever de maneira real o que ele quer, ou haver duplo sentido no que
ele diz e por fim não haja como especificar de modo que uma ferramenta 4GT
compreenda.
Em pequenas aplicações existe a possibilidade de passar da etapa que há
coleta de exigências, utilizando uma ferramenta 4GT para implementação, fazendo o
uso da linguagem de quarta geração(4GL). Mas para maiores aplicações é
necessário o desenvolvimento de um projeto, mesmo que seja feita a utilização de
uma 4GL. A utilização da 4GL em grandes aplicações sem planejamento resulta nos
mesmos
problemas
daqueles
de
desenvolvedores
usando
abordagens
convencionais.
A seguir na Figura 4 observa-se o modelo das técnicas de quarta geração:
20
Figura 4 Técnicas da quarta geração (4GT)<tec4rup. wordpress.com>
Sobre as técnicas da quarta geração(Pressman, 1995, p.42):
A implementação usando uma 4GL possibilita que o desenvolvedor de
software represente os resultados desejados de uma forma que resulte em
geração automática de código para produzir esses resultados. Obviamente
prontamente acessível pela 4GL.
Por fim observa-se que o desenvolvedor, para transformar a 4GL em um
produto deve realizar testes cuidados e minuciosos, bem como uma documentação
completa e significativa. Realizar também todas as etapas existentes nos outros
paradigmas da engenharia de software.
Escolhendo um paradigma para seguir, parte-se para o estudo de viabilidade
do sistema.
2.1.5 ESTUDO DE VIABILIDADE
Todos os projetos são viáveis (PRESSMAN, 1995, p.200), se for analisado de
forma coerente desde o seu início: as datas de entrega de certas funções do
sistema, o pessoal necessário, o material utilizado, o custo, entre outros fatores. Isso
é fundamental e necessário para o desenvolvimento de um software, pois meses,
anos, recursos financeiros, podem ser desperdiçados caso o software não seja
analisado antes de seu inicio.
21
Existe grande relação entre o estudo de viabilidade e análise de riscos (seção
2.1.6), pois havendo grandes riscos para o desenvolvimento do sistema, resultará
em uma viabilidade baixa de se produzir um software qualificado. Existem quatro
áreas de grande importância:
Viabilidade econômica: Uma análise dos custos do sistema com os
lucros/benefícios que o mesmo resultará.
Viabilidade técnica: Análise das restrições que possam acarretar em falhas
nas etapas de desenvolvimento do sistema.
Viabilidade
responsabilidade
legal:
legal
Análise
que
de
possam
possíveis
acarretar
violações,
em
falhas
restrições
nas
etapas
ou
de
desenvolvimento do sistema.
Alternativas: Análise de diversas maneiras de se desenvolver o sistema.
Sobre o estudo de viabilidade(Pressman, 1995, p.200):
“Um estudo de viabilidade não tem razão de ser para sistemas em que a
justificação econômica seja óbvia, os riscos técnicos sejam baixos, poucos
problemas jurídicos sejam esperados e não exista nenhuma alternativa
razoável. Entretanto, se faltar qualquer uma das condições precedentes, o
estudo deve ser realizado.“
Juntamente com o estudo de viabilidade deve-se realizar a parte de análise
de riscos.
2.1.6 ANÁLISE DE RISCOS
Para (Pressman, 1995, p.58):
Sempre que um programa de computador for construído haverá áreas
de incerteza.
As necessidades do computador são de fato atendidas? As
funções que devem ser implementadas podem ser antes do prazo final do
projeto? Surgirão problemas técnicos difíceis que atualmente estão fora de
nossa visão? As mudanças que invariavelmente ocorrem durante qualquer
projeto farão com que a programação se desvie muito do curso?
Para que haja um gerenciamento de qualidade e futuramente se conclua um
software de excelência é necessário o conhecimento de todos os riscos de um
projeto como um todo. Para finalmente saber se a junção de todos os riscos torna
22
viável a construção do software e assim partir para a etapa de realizar a modelagem
deste software.
2.1.7 PRA QUE REALIZAR A MODELAGEM DO SISTEMA?
A modelagem é uma cópia do sistema que pode ser verificada antes da
implementação ser iniciada, com isso pode-se notar os problemas e riscos possíveis.
Basicamente é a modelagem que vai dizer tudo sobre o que se deve fazer; qual o
caminho mais eficiente, visando a maior otimização possível do sistema (poupando
recursos), o pessoal necessário, o real foco do sistema, as ferramentas necessárias
e adequadas, e o tempo necessário para a contemplação do sistema.
A capacidade humana é limitada para entender coisas complexas como
sistemas de alto desempenho. Com a modelagem, faz-se uma síntese do projeto,
assim observando que os problemas grandes são divididos em menores, para focar
e conquistar(resolver) um por vez.
Muitas vezes programadores, que de uma maneira informal fazem a sua
modelagem, com rabiscos, desenhos e outros recursos próprios. Isso pode vir a
funcionar, mas o grande problema disto é que esta modelagem só será conhecida
por ele ou por sua equipe. Se futuramente, outros forem fazer manutenção ou
expansão no sistema, será incompreensível a modelagem, logo, como realmente o
software funciona. Por isso a utilização da linguagem padronizada e internacional
UML, que é conhecida por grande parte do grupo de desenvolvedores do mundo.
Para se representar o sistema na UML existem diagramas que são uma
apresentação gráfica de uma serie de elementos utilizados na linguagem UML, que
são
para
representar,
através
de
gráficos
de
vértices(itens)
e
arcos(relacionamentos).
Sobre a modelagem UML (Booch, Rumbaugh, Jacobson, 1999, p. 6):
Com a modelagem, alcançamos quatro objetivos.
1.
Os modelos ajudam a visualizar o sistema como ele é ou como
desejamos que seja.
2.
Os modelos permitem especificar a estrutura ou o comportamento de
um sistema.
23
3.
Os modelos proporcionam um guia para a construção do sistema.
4.
Os modelos documentam as decisões tomadas.
A seguir fala-se sobre as representações gráficas da UML, ou seja, os
diagramas para representar diversos aspectos do sistema.
2.2
UNIFIED MODELING LANGUAGE (UML)
O estilo dos diagramas que o projeto refletirá e da UML, que é um padrão de
para se construir e elaborar projetos de softwares. Pode ser usada na parte visual,
especificação, a construção e documentação.
2.2.1 HISTÓRIA
Na década de 90 existiam várias maneiras de se projetar um sistema, ou seja,
diversos métodos que eram utilizados para os projetos de softwares como: Booch,
OOSE, OMT entre outros. Cada um deles tinham suas especificidades, certo método
era bom para certo tipo de sistema, tinham suas vantagens e desvantagens. Na
metade de 1990 os líderes de cada empresa responsável pelos métodos Booch,
OOSE, OMT, começaram a inserir as ideias de orientação a objetos em seus
métodos. Então eles se sentiram motivados a criar uma linguagem unificada, que
fosse única utilizada por todos, pois seus métodos estavam se unindo
independentemente, ou seja, um estava completando o outro. Então não havia
motivo para ficarem separados. A grande vantagem seria um maior entendimento
por parte dos usuários e o fortalecimento do mercado orientado a objetos.
Sobre a unificação (Booch,Rumbaugh, Jacobson, 1999, p. XVII):
Ao iniciar a unificação, estabelecemos três objetivos para o nosso trabalho:
1. Fazer a modelagem de sistemas, do conceito ao artefato executável,
com a utilização de técnicas orientadas a objetos.
2. Incluir questões de escala, inerentes a sistemas complexos e de tarefas
críticas.
3. Criar uma linguagem de modelagem a ser utilizada por seres humanos
e por máquinas.
24
Esse novo método seria a UML que se iniciou oficialmente em outubro de
1994, e em 1995 saiu a primeira versão. Daí por diante surgiram outras versões da
UML.
2.2.2 DIAGRAMA DE CLASSES
Diagrama de classes(Figura 5) segundo (Booch, Rumbaugh, Jacobson, 1999,
p. 104):
Os diagramas de classes são os diagramas encontrados com maior
frequência na modelagem de sistemas orientados a objetos. Um diagrama
de classes mostra um conjunto de classes, interfaces e colaborações e seus
relacionamentos.
Figura 5 Exemplo de diagrama de classes
2.2.3 DIAGRAMA DE CASOS DE USOS
Os diagramas de casos de uso têm um papel central para a modelagem do
comportamento de um sistema, de um subsistema ou de uma classe. Cada um
25
mostra um conjunto de casos de uso e atores e seus relacionamentos. (Booch,
Rumbaugh, Jacobson, 1999, p. 231).
Figura 6 Exemplo de diagrama de casos de uso
O diagrama de casos de uso tem como objetivo relatar, quais são as
funcionalidades do sistema.
Observa-se na Figura 6 um exemplo do diagrama de casos de uso, que
contem:
 Atores
É um usuário do sistema, podendo ser um ser humano, ou um sistema
computacional. A seguir na Figura 7 a representação de um ator.
Figura 7 Ator diagrama de casos de uso
 Caso de uso
É representado por uma elipse(Figura 8), e define uma grande função do
sistema. Existe a possibilidade de que uma função seja estruturada em
outras, com isso o caso de uso será estruturado.
26
Figura 8 Caso de uso digrama casos de uso
 Relacionamentos
Descrevem os casos de uso entre:
 Ator e caso de uso(Figura 9)
Figura 9 Associação diagrama de casos de uso
2.3
ORIENTAÇÃO A OBJETOS
De acordo com Pablo Dall’Oglio (2007, p. 86)
A orientação a objetos é um paradigma que representa toda uma filosofia
para construção de sistemas. Em vez de construir um sistema formado por
um conjunto de procedimentos e variáveis nem sempre agrupadas de
acordo com o contexto, como se fazia em linguagens estruturadas (Cobol,
Clipper, Pascal), na orientação a objetos utilizamos uma ótica mais próxima
do mundo real. Lidamos com objetos, estruturas que já conhecemos do
nosso dia-a-dia e sobre as quais possuímos maior compreensão.
Há duas estruturas principais na orientação a objetos, que são as classes e
os objetos. A classe é uma estrutura que define um tipo de informação a ser
trabalhada, existindo a
possibilidade de conter atributos, que são propriedades
dessa classe e métodos que são funções desempenhadas por essa classe. O objeto
é uma classe em instância, ou seja, no momento de execução do sistema a classe
sendo algo dinâmico.
A seguir (Figura 10) um exemplo de uma classe, contendo os atributos: cod,
nome, endereco e telefone. Possui os métodos getNome e setNome, que são
funções que esta classe quando instanciada, se tornando um objeto realizará.
27
Figura 10 Exemplo de classe
Por muitas vezes é complicado se ter uma noção de como se dará a
programação de um software. Sua complexidade faz com que se torne árduo o
trabalho de programar em linguagem estruturada. Uma das soluções para este
problema é utilizar o paradigma orientado a objetos.
A orientação a objetos é um paradigma que visa o desenvolvimento de um
projeto mais enxuto enquanto código e diagramas. Ele foi criado em um determinado
momento no qual o paradigma estruturado não estava mais satisfazendo as
necessidades dos programadores. Os algoritmos começaram a se tornar muito
complexos, sendo que só existia uma maneira de desenvolvimento.
É necessário o entendimento do nosso mundo real para facilitar a
compreensão deste jeito de se programar. Na dimensão em que vivemos somos
apenas objetos que nos relacionamos entre nós mesmos. Esse ambiente por nós
habitado depende das nossas ações e suas respectivas reações, o que é chamado
de cadeia de eventos. Alguns autores representam a orientação a objetos e essas
relações como um mundo, “o mundo OO”. Completamente diferente do “mundo
estruturado”, de onde devemos nos desligar por completo, trazendo apenas a lógica
de programação para o “mundo OO”.
Por serem relações de objetos, não será mais usado o termo programa, mas
sim, classes implementadas. Essas classes são moldes lógicos dos objetos e suas
funções. Por exemplo, a planta de um imóvel é sua classe, a ideia original. Portanto,
a aplicação dessa ideia, ou seja, o imóvel construído, a parte física da relação seria
o objeto.
28
Para a obtenção do sucesso na construção de códigos orientados a objetos é
fundamental que se conheça o conceito de abstração. Essa abstração consiste em
analisar friamente as necessidades do usuário e programar de acordo a supri-las.
Por exemplo, antes de todo projeto existe uma análise de tudo aquilo que o usuário
deseja. Como o usuário não tem o conhecimento suficiente para conseguir
transformar essas informações em classes para implementação. O papel do
desenvolvedor em reuniões com o usuário, onde ele fala das suas necessidades, é
justamente interpretar esses problemas e modelar eles de maneira lógica de forma
que facilite o desenvolvimento do software mais tarde. Essa tradução de
informações do mundo real para o segmento orientado a objetos é chamada de
abstração.
Todos os programadores que começam a trabalhar com o paradigma
Orientado a Objetos tem sempre a mesma dificuldade num primeiro momento. O
objetivo com a utilização deste paradigma para o desenvolvimento deste sistema, é
que com a experiência adquirida em outros momentos do curso se saiba identificar
os momentos onde será viável a programação em objetos, desta maneira diminuindo
os custos de tempo e aprimorando um conhecimento já utilizado.
A partir do momento que se compreende o paradigma(maneira/modo) que
será desenvolvido o sistema, se parte para a linguagem na qual será realizado o
desenvolvimento do sistema.
2.4
JAVA
No início da década de 90, quando a Sun Microsystems projetava
desenvolver uma plataforma que permitisse o controle de computadores e
eletrodomésticos
à
distância,
e
com
o
aumento
das
necessidades
e
consequentemente dos gastos, esse projeto já não estava mais sendo viável. Então,
em 1995, John Cage apresentou ao mundo a plataforma Java como uma linguagem
para aplicações voltadas para Internet.
As características da linguagem Java:
29
 Orientada a Objetos. Há possiblidade da inserção de todos os
fundamentos presentes no paradigma orientado a objetos.
 Robusta
e
Segura.
simultaneamente(multithreading)
Realiza
diversos
processos
e as classes protegem o SO e o
ambiente em que está sendo executado o software utilizando a linguagem.
 Distribuída e Portátil. Existe a opção de um objeto ser acessado de uma
máquina que não é a que ele se encontra e também a linguagem roda em
mainframes e celulares.
 Arquitetura Neutra. Tem como linguagem-mãe o C++, possuindo mais
simplicidade no código. Em suas classes existe somente uma porta de
entrada.
 Interpretada, mas de Alto Desempenho. Roda sobre uma máquina virtual,
sendo interpretada por Bytecodes.
 Simples. Contém apenas seis comandos(dois de decisão, três de repetição
e um para proteção do código).
A partir dessas características da linguagem Java, ela foi compreendida como
uma evolução.
Conhecendo os conceitos de Orientação a Objetos, é possível definir alguns
fundamentos em Java:
 A classe deverá ter extensão .java e deverá seguir o molde, de definição de
pacote de classes, definição de importação de classes provenientes de
outros pacotes e definição da própria classe.
 A geração do arquivo de classe .class será interpretado pela JVM (Java
Virtual Machine) que interpretará os dados e os executará corretamente.
Assim, uma aplicação Java poderá ser compilada em qualquer máquina
que possua a JVM.
 Deixou de lado a múltipla herança da sua linguagem-mãe C++ facilitando a
associação de classes de um mesmo pacote, assim a troca de informações
de classe para classe será dada através de apenas um ponto de entrada.
30
Abaixo na Figura 11 exemplo de um código simples em Java.
Figura 11 Exemplo de código em Java
Sobre a linguagem Java (Anselmo, 2005, p.18):
Resumidamente, o que isto significa é que, ao criarmos um programa em
linguagem Java e o compilarmos, podemos enviá-lo para qualquer lugar que
tenha uma JVM. Esta então se encarregará de executá-lo no Sistema
Operacional(não importando o qual) que ela estiver instalada.
Definida a linguagem de programação Java, parte-se para o banco de dados,
o qual receberá todas as informações do sistema programado em Java.
2.5
BANCO DE DADOS
O Banco de Dados é uma maneira de transformar informações provenientes
do mundo real em dados virtuais. Esses sistemas de banco de dados são
desenvolvidos para gerir a manipulação de grandes volumes de informação. Para o
gerenciamento desses dados são desenvolvidas SGBDs (Sistemas Gerenciadores
de Banco de Dados), que administram de maneira lógica essa abstração do mundo
real.
Para que se possa interpretar o mundo real como um conceito lógico e virtual,
três modelos foram criados: Modelo Conceitual, o Modelo Entidade-Relacionamento,
e o Modelo Lógico Relacional.
31
Segundo Antônio Ricardo (2004, p. 5):
“De acordo com a intenção do modelador, um banco de dados pode ser
modelado (descrito) há vários níveis de abstração. Um modelo de dados
que servirá para explicar a um usuário qual é a organização de um banco
de dados provavelmente não conterá detalhes sobre a representação em
meio físico das informações. Já um modelo de dados usado por um técnico
para otimizar a performance de acesso ao banco de dados conterá mais
detalhes de como as informações estão organizadas internamente e
portanto será menos abstrato.”
2.5.1 MODELO CONCEITUAL
Segundo Antônio Ricardo (2004, p.5):
“Um modelo conceitual é uma descrição do banco de dados de forma
independente da implementação em um SGBD. O modelo conceitual
registra que dados podem aparecer no banco de dados, mas não registra
como estes dados estão armazenados a nível de SGBD.”
O modelo conceitual é o primeiro passo para o desenvolvimento de um
projeto de banco de dados. Ele visa descrever as interações reais existentes e
transcrevê-las para que se possa implementar o sistema de banco de dados. Pode
ser dividido em três níveis: Físico, Lógico e de Visão.
Físico: Apenas descreve como esses dados estão armazenados.
Estruturas de dados são descritas detalhadamente de forma física, na sua maioria
das vezes em formato de bytes.
Lógico: Descreve os dados de maneira racional e mostra suas interações.
É utilizado pelos desenvolvedores de sistemas de bancos de dados por ser mais
simples que o nível físico, assim conseguindo interpretar o problema e transformá-lo
em uma sequencia de código que relacione essas informações sem distorção de
dados do mundo real.
De visão: É o banco de dados do ponto de vista do usuário. Apenas
descreve as interações e informações de acordo como foi projetada no modelo
lógico. Também abrange a questão de segurança de um banco de dados. Um
usuário não necessita saber todas as informações existentes em um banco de
32
dados. O modelo de visão mostrará somente parte do banco de dados, definindo
assim, o nível de visão para o usuário.
2.5.2 MODELO ENTIDADE-RELACIONAMENTO
O uso desse tipo de modelo é para esboçar o projeto de modo que facilite a
sua implementação mais tarde. A tradução do mundo real para o papel será
realizada nesta fase do desenvolvimento. Será pensado um diagrama que seja o
mais fiel possível àquilo que acontece na realidade. Este diagrama será composto
por: Entidades, Atributos e Relações.
Entidade(Figura 12): É onde se agrupam objetos por semelhança de
estrutura. Uma entidade tem um conjunto de propriedades, que caracterizam esse
grupo. Por exemplo, pessoas são entidades, que tem propriedades como: CPF,
nome, peso, altura, data de nascimento, entre outros.
Figura 12 Entidade do Modelo ER
Atributo(Figura 13): Atributos são propriedades descritivas de um conjunto de
entidades. A designação de atributos para cada conjunto de entidades fará com que
se armazenem dados similares a cada entidade, assim dando o estereótipo para
este conjunto. No entanto cada entidade possuirá seu valor para cada atributo,
assim diferenciando de objeto para objeto. Por exemplo, uma pessoa terá o atributo
data de nascimento, porém não necessariamente todas as entidades do conjunto
pessoas terão a mesma data de nascimento.
Figura 13 Atributo do Modelo ER
Relacionamento: Será a interação entre uma ou várias entidades. Vamos
tomar como exemplo: “Pessoa” poderá se relacionar com “Conta Bancária”. Essas
relações terão um mapeamento em função de suas cardinalidades. A cardinalidade
33
de uma relação é quantos objetos de cada conjunto de entidades se associarão. No
nosso exemplo, a cardinalidade será de um para um, ou seja, uma pessoa poderá
se relacionar no máximo com uma conta. Existem outros tipos de cardinalidade,
como um para muitos, onde, por exemplo, uma pessoa possui vários telefones,
porém esses telefones pertencem apenas a essa pessoa; ou muitos para muitos: por
exemplo, numa empresa uma pessoa trabalha em vários projetos e cada projeto
desses contém várias pessoas trabalhando nele.
2.5.3 MODELO RELACIONAL
O modelo relacional ascende do MER (Modelo Entidade-Relacionamento),
onde eram feitas as interações reais. Consiste em tabelas(Figura 14), cada uma com
um nome único. Essas tabelas foram representadas anteriormente em forma de
entidades. As colunas desta tabela serão seus atributos, e suas linhas conterão os
valores armazenados para cada objeto do conjunto. Esses valores poderão conter
relações entre tabelas, e será dado pelos valores únicos de uma entidade, por
exemplo, o CPF de uma pessoa como atributo único.
Figura 14 Exemplo de tabelas no MER <renan-m-levy.blogspot.com>
34
3. METODOLOGIA
Neste capítulo será discutido como acontecerá o desenvolvimento do
software SGI.
Nele mostra-se como serão aplicados os conhecimentos
aprofundados na fundamentação teórica e como que o projeto se encaixaria numa
implantação real.
Também será uma parte importante do projeto tendo em vista a otimização da
implementação, sendo que aqui serão mostrados diagramas, modelos e formas de
se organizar o progresso do software.
3.1
ESTUDO DE VIABILIDADE
Esse módulo do projeto mostrará como que o SGI irá facilitar no
funcionamento da Imobiliária Família Feliz.
Foi pesquisado na Imobiliária Família Feliz como é feito o controle interno da
imobiliária, como gerenciamento das transações de imóveis e também a gestão
financeira que envolveria percentagens de lucro em cima de imóveis vendidos, etc.
O foco principal na ideia do projeto seria no desenvolvimento de um sistema
de divulgação da imobiliária através da internet. Porém, essa imobiliária já tivera
uma solução para esse problema. A consulta dos clientes interessados em imóveis
pode ser dada através de um website já existente, onde ele pode manter contato
com o dono atual do produto pretendido. Sendo assim, seria uma contradição
desenvolver este tipo de sistema.
Com o passar do tempo, e dos contatos com a empresa para verificar quais
os principais aspectos a serem melhorados no seu gerenciamento, vimos que a
imobiliária sente a falta de um sistema de controle interno. A inviabilidade de não
existir um controle interno é muito grande. Por isso, hoje o escopo do projeto é outro.
 Algumas facilitações que um sistema interno traria:
 Condições de trabalho off-line
35
 Aproximação com o que acontece na imobiliária em termos de transações
e especulações.
 Controle financeiro e percentagens em cima dos valores de imóveis
 Viabilização da contratação de funcionários
Hoje, a imobiliária contém apenas dois funcionários, pelo fato de que ela fora
criada apenas alguns meses atrás. Com isso, a avaliação dos terrenos é feita por
corretores autônomos que fazem a interface entre o vendedor e a imobiliária e
ganham comissões em cima da venda e aluguel dos imóveis por ele avaliado.
Também foi discutida a possibilidade de implantação real do sistema no
funcionamento da imobiliária. Seus gerentes concordaram que esse tipo de gerência
aperfeiçoaria o tempo e funcionamento interno da imobiliária. Com isso, pode-se
afirmar que o desenvolvimento deste projeto seria viável, tanto para os alunos que
irão fazê-lo, como para a imobiliária que usufruiria do sistema proposto.
3.2
REQUISITOS
Depois da viabilidade de se construir o projeto ser estudada, passou-se a
tratar, nas conversas com a proprietária da imobiliária sobre o desempenho e
funcionalidades que o sistema traria. Essas funcionalidades chamadas de requisitos
do sistema nos darão uma visão mais detalhada sobre cada um dos módulos que
estarão no software.
Os requisitos serão:
• Acesso Restrito: Consistirá em existir um login e senha para que o
administrador possa controlar o sistema sem que outro funcionário
qualquer possa ter acesso a parte administrativa do sistema.
• Manter Imóveis: Os funcionários poderão cadastrar os imóveis de clientes,
modificar os já existentes no sistema e também fazer a exclusão deles do
banco de dados, caso o cliente decida tirá-lo desta imobiliária.
36
• Manter Funcionários: Com o administrador tendo acesso a módulos que
outros funcionários não têm, só ele poderá fazer a manutenção de
funcionários, como cadastrá-los (admissão) e exclui-los (demissão).
• Manter Clientes: Quando um cliente tem interesse em colocar seu imóvel
disponível para venda ou locação, o funcionário responsável pelo sistema
deverá se utilizar deste módulo do sistema para cadastrá-lo antes de
cadastrar o imóvel. Também fará alterações e definirá clientes inativos.
• Operação: Inserção das operações que realizada a imobiliária, junto com
objetos possivelmente relacionados, acarretando na construção de
diversos relatórios.
• Avaliação: Se utiliza do cadastro dos funcionários e dos imóveis para que
corretores façam a avaliação do imóvel, gerando seus respectivos laudos.
3.3
FUNCIONAMENTO DA IMOBILIARIA
Com o tema principal deste projeto sendo o desenvolvimento de um software
que consiga fazer de maneira eficaz o controle interno de uma imobiliária, foi
necessário que houvesse uma pesquisa minuciosa sobre como, atualmente,
funcionam as imobiliárias quanto ao seu software de gerenciamento.
Para a compreensão do cotidiano de uma imobiliária, foram feitas visitadas a
Imobiliária Família Feliz, situada na cidade de Paranaguá e a partir destas visitas foi
feito este levantamento sobre o funcionamento da mesma por meio de
acompanhamentos no dia-a-dia da empresa.
Escolheu-se esta imobiliária, pois
existe a possibilidade do software ser implantado. Com a colaboração da proprietária
do estabelecimento, conseguimos extrair algumas informações sobre como se dá o
controle de vendas e alugueis de imóveis, como:
1. Corretores não são funcionários contratados. São autônomos e fazem a
angariação de imóveis por conta própria. A imobiliária apenas se aproveita
dos imóveis avaliados por eles para fazer a relação entre comprador e
vendedor.
37
2. Uma parte da percentagem que a imobiliária ganha em cima da venda e
aluguel de imóveis irá para o corretor que fez a avaliação.
3. O corretor ou a imobiliária terão de zelar e cobrar a entrega do imóvel nas
condições em que foram apresentadas na avaliação.
4. Corretor fará a interface entre o cliente-vendedor e a imobiliária interessada
na venda deste imóvel.
Também foi pesquisado quanto à comissão de venda/aluguel que como
bônus, é recomendado pelo CRECI (Conselho Regional de Corretores de Imóveis)
que o primeiro aluguel de uma locação feita pela imobiliária seja inteiramente
direcionado a imobiliária e que os demais sofram um honorário de 10% em relação à
comissão de imobiliária/corretor.
Porém, nem todas as imobiliárias funcionam dessa maneira, e esses
percentuais podem variar de valor durante a vida da imobiliária. Portanto, será
necessária a criação de opções dentro do software que tragam a possibilidade de
mudança quanto a isso.
Outras informações que não de conhecimento especifico de gerencia de
imobiliária sobre como será feito cadastro de clientes, cadastro de corretores, entre
outros, não será abordada nesta seção.
3.4
GERAÇÃO DE RELATÓRIOS PDF
Uma imobiliária necessita da geração de muitos relatórios. Por vezes esses
relatórios precisam ser armazenados em arquivos separados por data, por exemplo.
Nas séries anteriores deste curso, a alternativa para gerar uma amostra de dados
era a criação de tabelas dentro do software que continham informações.
Mas, em uma imobiliária séria, a visualização de informações não pode ser
dada desta maneira. Para isso serão gerados relatórios em formato PDF.
Esses relatórios serão gerados automaticamente no sistema, para isso será
necessário alguns conhecimentos a mais, por exemplo, a biblioteca utilizada para
fazer esta conversão de informação do banco de dados em PDF será a itexpdf-5.1.3.
38
Essa biblioteca contém todas as classes e métodos necessários para a conversão
dos arquivos em PDF.
3.4.1 FUNCIONAMENTO DA ITEXPDF 5.1.3
A API itexpdf tem diversas funcionalidades que não cabem discutir uma a
uma, haja vista que nem todas serão utilizadas no desenvolver do software Para
uma simples geração de relatório serão utilizadas as classes PDFWriter, Document,
DocumentException e Paragraph:
- PDFWriter: Cria um objeto que instancia um escritor de PDF. Sua função é
abrir, alterar, manter informações e salvar arquivos.
- Document: Cria um documento PDF para inserir e alterar dados.
- DocumentException: Trata as exceções que possam vir a ocorrer na
abertura, na modificação ou ao salvar o arquivo.
- Paragraph: Objeto que cria uma string em forma de parágrafo e a converte
para formato PDF.
Na Figura 15 relata-se como ocorre a importação dessas classes para o
projeto.
Figura 15 Classes para geração PDF
Com essas classes importadas, já é possível estudar os métodos e suas
funções.
3.4.2 MÉTODOS
Os métodos(Figura 16) da API itexpdf v5.1.3 são chamados através das
classes já apresentadas. Esses métodos chamam as funções da API que fazem a
manutenção do arquivo. São utilizados:
- getInstance(Document a, FileOutputStream file): Chamado pela classe
PDFWriter,
cria
a
instância
do
documento
formato
PDF
que
será
39
criado/aberto/manipulado e insere as informações do file no documento. A variável
file conterá as informações desse arquivo como nome e diretório.
- document.open(): Método onde document é um objeto da classe Document.
Esse método só será chamado depois da getInstance(), onde document receberá as
informações do arquivo que será modificado. Tem como função abrir o arquivo para
manipulá-lo.
- document.add(Paragraph para): Criação do parágrafo será dada através de
uma string que será o parâmetro do construtor da classe Paragraph. Este método irá
adicionar o parágrafo criado ao arquivo PDF.
- document.close(): Fechamento e salvamento do arquivo dado por esse
método.
Figura 16 Exemplo de código para geração de um documento PDF
3.4.3 VISUALIZAÇÃO DE ARQUIVO PDF NO SISTEMA
Sabendo como se criar e modificar os arquivos PDF no sistema, também se
faz necessário mostrar o relatório gerado dentro do sistema. Para tal tarefa será
utilizada a biblioteca pdfviewer.jar
As classes(Figura 17) da API chamadas para fazer a visualização do relatório
são: PDFFile, PDFPage e PagePanel. Além disso, outras classes da API do Java
são chamadas como a ByteBuffer e a FileChannel.
Figura 17 Classes importadas do PDFView
40
3.4.4 CÓDIGO
Alguns métodos e construtores são chamados para que ocorra o
funcionamento pleno desse módulo do sistema. Sendo eles:
- new RandomAccessFile(file, "r"): Com file sendo o arquivo que será
acessado, a classe RandomAccessFile trará um objeto que servirá de consulta para
acesso do arquivo.
- raf.getChannel(): Traz a posição do canal de ligação com o arquivo. Irá
apontar onde está o arquivo no sistema.
-
channel.map(FileChannel.MapMode.READ_ONLY,
0,
channel.size()):
Aponta o ‘mapa’ do arquivo para o ByteBuffer. Trará todas as informações
necessárias para o acesso do arquivo.
- new PDFFile(buf): Criará um objeto da classe PDFFile, passando por
parâmetro uma instancia de ByteBuffer, que recebera o channel.map(), como
anunciado no item anterior.
- PDFPage page = pdffile.getPage(0): Recebe a pagina em formato PDF do
PDFFile.
- panel.showPage(page): Sendo panel um painel de uma janela, chamará a
instancia page, da classe PDFPage, mostrando este relatório numa janela do
sistema.
Esses métodos(Figura 18) contribuirão para que seja mostrado os relatórios
em uma janela do sistema, sem a necessidade da abertura em outro software como
Adobe Reader.
Figura 18 Exemplo de código para visualizar um documento PDF
41
3.5
DIAGRAMA DE CASO DE USO
Como mencionado na seção 2.2.3, o diagrama de caso de uso servirá de
apoio para a construção das funcionalidades do sistema. Ele mostrará como se dá
as relações entre atores externos ao sistema e seus envolvimentos quanto aos
módulos de serviço do projeto.
Na figura 19 pode-se notar a existência de quatro atores: Imóvel, Funcionário,
Corretor, Cliente. Os casos de uso são baseados na análise de requisitos, feita na
secção anterior a esta.
A diagramação de casos de uso (Figura 19) nos mostra o ator Funcionário
tendo que, necessariamente, realizar um login para que possa executar funções
como Manter Pessoas ou Manter Imóveis, cadastrar operações e avaliações de
imóveis que venham a ser feitas. Outros atores como Imóvel e Cliente apenas
participarão como objetos do sistema. Por exemplo, o Cliente poderá ser cadastrado
pelo Funcionário, ou participar de uma Operação, seja como vendedor, seja como
comprador/locador. O Imóvel participará de quatro ações distintas: Gera Histórico,
armazenando todas as informações de determinado imóvel; Manter Imóveis, sendo
este imóvel cadastrado no banco de dados por um funcionário; Avaliação, onde
serão relatadas as observações do corretor após visita ao imóvel; e Operação,
participando como objeto de negociação entre dois clientes (vendedor e comprador).
Outras
funções
como
GeraContrato
e
GeraRelatorio
serão
apenas
executadas quando forem chamadas por Operação e Avaliação respectivamente.
42
Figura 19 Diagrama de casos de uso do SGI
43
3.6
DIAGRAMA DE CLASSES
A Figura 20 mostra o diagrama de classes do software desenvolvido.
Figura 20 Diagrama de classes do SGI
Neste diagrama podem-se observar todas as classes que existem no SGI,
suas relações e seus atributos, tentando traduzir o que ocorrem na realidade de uma
imobiliária em linguagem orientada a objetos.
3.7
MODELO ENTIDADE RELACIONAMENTO
Este diagrama(Figura 20), criado para facilitar a tradução do que será
armazenado no banco de dados (secção 2.5.2), nos mostra um esboço das tabelas
que serão criadas para armazenar dados.
Sendo a principal função do SGI a operação (venda/locação) de imóveis entre
clientes, é de suma importância que se guarde tudo que pode ocorrer entre eles.
44
O Imóvel, para participar de uma Operação, terá que ser avaliado por um
Corretor, que gerará um Laudo sobre ele, podendo este Imóvel ser Residencial ou
Comercial. A Operação fará a interface entre Clientes e Imóvel para que haja uma
negociação, podendo ela ser Definitiva (Venda/Compra), ou Locação. A Locação
gerará um Contrato, com informações legais sobre o estado da locação, tais como
data de inicio e fim, valor do aluguel, entre outros.
O cadastro dessas informações no sistema só poderá ser dado por um
Funcionário cujo Login é válido. A entidade Pessoa dará origem aos Clientes,
Funcionários e Corretores.
Figura 21 MER do SGI
45
3.8
MODELO RELACIONAL
Como retratou a seção 2.5.3, o modelo relacional derivará do modelo de
entidade-relacionamento. A diferença entre eles é a criação de chaves estrangeiras
(atributos de entidades que existem em outras para caracterizar uma relação) e de
chaves primarias (atributos que dão a identificação de um objeto no banco).
Segue na Figura o modelo relacional do SGI:
Figura 22 MR do SGI
Modelo Relacional designando a existência de chaves primárias e de chaves
estrangeiras.
Este diagrama é o último passo rumo ao desenvolvimento do projeto e da
base de dados.
46
4. RESULTADOS OBTIDOS
O Sistema de Gerenciamento Imobiliário foi desenvolvido base na modelagem
apresentada neste documento, incluindo objetivos, análises e levantamentos de
requisitos.
O sistema foi implementado na plataforma Java, utilizando a IDE Netbeans,
para manipulação e comunicação com o banco de dados utilizou-se a linguagem
SQL, com o sistema gerenciador de banco de dados MySql, utilizando a ferramenta
phpMyAdmin.
A figura 23 apresenta a tela de login do SGI.
Figura 23 Tela de Login SGI
A figura 24 apresenta a tela inicial do SGI, e é a partir dela que o usuário pode
realizar todas as funções previstas neste documento.
47
Figura 24 Tela inicial do SGI
Uma das principais funções deste sistema por se tratar de uma imobiliária, é a
de manutenção e busca dos imóveis. A partir de conversas com o cliente foi definida
a divisão dos imóveis em dois grandes grupos: comercial e residencial. Para o tal
temos as Figuras 25 e 26, representando as janelas de inserção destes imóveis.
48
Figura 25 Tela Inserir Imóvel Comercial
49
Figura 26 Tela Inserir Imóvel Residencial
Outra função de extrema importância no sistema é a busca dos imóveis
(Figura 27), visto que se gera grande praticidade para o dia-a-dia da imobiliária.
Nesta tela existe a possibilidade, através de filtros, de efetuar-se uma pesquisa
refinada, ou seja, em outras palavras, montar um imóvel desejado. Vê-se grande
importância nesta função no momento em que clientes forem visitar a imobiliária a
procura de imóveis, sabendo os requisitos do cliente essa busca será realizada com
eficiência.
50
Figura 27 Tela de busca dos imóveis
Outra função referente aos imóveis é a criação de laudos técnicos por meio
dos corretores para avaliar diversos aspectos dos imóveis, em outras palavras o
imóvel é avaliado de maneira minuciosa por um profissional responsável. Tudo isso
é definido pelo CRECI, a partir desses padrões e de reuniões com o cliente dividiuse o laudo em três principais etapas, essas mostradas nas figuras 28, 29 e 30.
51
Figura 28 Tela laudo parte Objeto da Avaliação
52
Figura 29 Tela laudo parte Especificações Técnicas
53
Figura 30 Tela laudo parte Anexo de Arquivos
Agora tendo feita a manutenção e busca dos imóveis, outro resultado
alcançado é a manutenção das pessoas(Figura 31, 32 e 33) que junto com os
imóveis geram as operações(Figura 34 e 35). Novamente por meio de reuniões com
o
cliente
foi
definida
que
existem
três
grupos
de
pessoas.
54
Figura 31 Tela Inserir Pessoa Física
A figura 31 mostra o painel para que o usuário cadastre pessoas físicas.
55
Figura 32 Tela Inserir Pessoa Jurídica
A figura 32 está no mesmo painel tabulado que o de manter pessoa física,
mas na especificação de pessoa jurídica.
56
Figura 33 Tela Inserir Corretor
A figura 33 mostra o painel tabulado de manutenção de pessoas, direcionado
a inserção de corretores.
57
Figura 34 Tela Operação Venda
A figura 34 mostra como que o usuário poderá cadastrar uma operação no
sistema. Neste caso uma venda.
58
Figura 35 Tela Operação Locação
Na figura 35 está exposto o que o usuário deverá inserir de informações para
a conclusão de uma operação do tipo locação.
59
5. CONCLUSÃO
A imobiliária Família Feliz utilizava para realizar suas atividades diárias
métodos um tanto quanto ultrapassados e inseguros. Simplesmente não havia
controle interno, o que no mercado imobiliário torna-se um grande problema.
A partir de uma analise criteriosa observou-se a oportunidade de resolver
esse problema utilizando a informatização do processo. E foi através de reuniões
com o cliente, discussões e análises, que desenvolvemos esse software. Não
esperamos que ele seja apenas para essa imobiliária mais se torne um software
modelo para área, com isso vemos que há grandes chances de extensão deste
sistema.
60
6.
REFERÊNCIAS
ANSELMO. Fernando. APLICANDO LÓGICA ORIENTADA A OBJETOS EM JAVA.
Florianópolis: VisualBooks Editora, 2005 – 2ª Edição Atualizada e Ampliada.
<http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/Graduacao/SIII/Uml/diagramas/usecases/usecases.htm>Acesso em 29 de abr. 2012.
BOOCH. G.; RUMBAUGH. J.; JACOBSON. I. UML GUIA DO USUÁRIO. 1999
PRESSMAN, S. Roger. ENGENHARIA DE SOFTWARE. São Paulo: Makron Books
do Brasil Editora, 1995 – 3ª Edição.
OLIVEIRA, Antonio Ricardo. MODELAGEM DE DADOS. Rio de Janeiro: Editora
SENAC, 2004 – 3ª Reimpressão.
DALL’OGLIO, Pablo. PHP PROGRAMANDO COM ORIENTAÇÃO A OBJETOS.
São Paulo: Novatec Editora, 2007.