sistema de administraÇÃo financeira condominial · antonio pereira de souza sistema de...

FACULDADES INTEGRADAS “CAMPOS SALLES”

SISTEMA DE ADMINISTRAÇÃO FINANCEIRA CONDOMINIAL

São Paulo 2014

ANTONIO PEREIRA DE SOUZA


Trabalho de Conclusão de Curso apresentado nas Faculdades Integradas “Campos Salles”, como pré-requisito para grau de Bacharel em Sistemas de Informação.

São Paulo 2014

ANTONIO PEREIRA DE SOUZA


Trabalho de Conclusão de Curso apresentado nas Faculdades Integradas “Campos Salles”, como pré-requisito para grau de Bacharel em Sistemas de Informação.

Aprovado em ___/____/_____ BANCA EXAMINADORA ____________________________________________________ Prof. MS. ____________________________________________________ Prof. MS. ___________________________________________________ Prof. MS.

DEDICATÓRIA

A minha esposa e filha, pela paciência e compreensão pelos

momentos em que estive ausente para conclusão deste

trabalho.

AGRADECIMENTOS

Em primeiro lugar, agradeço a Deus, o Grande Criador do Universo e a Jesus

Cristo, nosso Líder e nosso Mestre.

Aos meus amigos da Empresa Brasileira Correios e Telégrafos que sempre

me deram apoio e incentivo para conclusão deste curso.

À Empresa Brasileira de Correios e Telégrafos, empresa de grande prestígio,

pelo incentivo financeiro a mim concedido, ao qual retribuirei contribuindo com os

conhecimentos adquiridos para manter-se forte e competitiva no mercado com o uso

da TI.

Aos professores do curso de Sistemas de Informação, pelo esforço e

dedicação que tiveram para nos repassar o conhecimento.

RESUMO

Este trabalho apresenta uma solução de gerenciamento e controle das atividades financeiras de condomínios, com foco na melhoria dos processos sob a responsabilidade do síndico. A ferramenta gerencial visa praticidade, confiabilidade e flexibilidade na gestão financeira condominial. A metodologia utilizada é baseada em pesquisas bibliográficas que envolvem o desenvolvimento de software.O presente trabalho, ainda que, de caráter acadêmico, proporciona uma oportunidade de negócio no fornecimento de soluções e serviços de Tecnologia de Informação.

Palavras-Chaves : Gestão financeira condominial. Negócio. Tecnologia de

Informação.

- Palavras em outras linguas usar itálico

Verificar o recuo no paragrafos e alinhamento do te xto (justificado)

- Titulo de tabelas e figura arial 12

-

- VALIDAR OS DIAGRAMAS DE CASO DE USO E CLASSE COM A MAIRA

EMILIAABSTRACT

This work presents a solution for managing and controlling the financial activities of condominiums, focusing on improving processes under the responsibility of the receiver. A management tool aimed at practicality, reliability and flexibility in financial management condominium. The methodology is based on bibliographic research involving the development of this software. The work, though, the academic nature provides a business opportunity in providing solutions and services for Information Technology.

Key Words : Condominium Financial Management. Business. Information Technology

LISTA DE FIGURAS

Figura 01 - Exemplo de diagrama de caso de uso.....................................................26

Figura 02 - Um diagrama de classes de um sistema de controle de estoque...........26

Figura 03 - Exemplo de um diagrama de sequência para um cadastro de cliente...27

Figura 04 - Representação de uma arquitetura 3 Camadas......................................29

Figura 05 - Estrutura de um provedor de acesso ADO.NET para MySQL................30

Figura 06 - Diagrama de casos de uso do SAFIC......................................................32

Figura 07 - Diagrama de caso de uso “Manter Categorias de Acesso”.....................33

Figura 08 - Diagrama de caso de uso “Manter Grupos”.............................................34

Figura 09 - Diagrama de caso de uso “Manter Usuários”..........................................35

Figura 10 - Diagrama de caso de uso “Manter Condomínios”...................................36

Figura 11 - Diagrama de caso de uso “Manter Contas”.............................................37

Figura 12 - Diagrama de caso de uso “Manter Parecer”............................................38

Figura 13 - Diagrama de caso de uso “Efetuar Log in”..............................................39

Figura 14 - Diagrama de caso de uso “Consultar Contas..........................................39

Figura 15 - Diagrama de classes parcial....................................................................70

Figura 16 - Diagrama de sequência “Incluir condomínio”...........................................71

Figura 17 - Diagrama de sequência “Alterar Condomínio”.........................................72

Figura 18 - Diagrama de sequência “Excluir Condomínio”.........................................73

Figura 19 - Diagrama de sequência “Incluir Categoria”..............................................74

Figura 20 - Diagrama de sequência “Alterar Categoria”.............................................75

Figura 21 - Diagrama de sequência “Excluir Categoria”............................................76

Figura 22 - Diagrama de sequência “Incluir Grupo”...................................................77

Figura 23 - Diagrama de sequência “Alterar Grupo”..................................................78

Figura 24 - Diagrama de sequência “Excluir Grupo”..................................................79

Figura 25 - Diagrama de sequência “Incluir Usuário”.................................................80

Figura 26 - Diagrama de sequência “Alterar Usuário”................................................81

Figura 27 - Diagrama de sequência “Excluir Usuário”................................................82

Figura 28 - Diagrama de sequência “Incluir Contas”..................................................83

Figura 29 - Diagrama de sequência “Alterar Contas..................................................84

Figura 30- Diagrama de sequência “Excluir Contas”..................................................85

Figura 31 - Diagrama de sequência “Incluir Parecer”................................................86

Figura 32 - Diagrama de sequência “Alterar Parecer”...............................................87

Figura 33 - Diagrama de sequência “Excluir Parecer”...............................................88

Figura 34 - Diagrama de sequência “Consultar Contas.............................................89

Figura 35 - Diagrama de sequência “Efetuar Log in”.................................................90

Figura 36 - Diagrama de classes completo................................................................91

Figura 37 - Modelo Entidade Relacionamento do SAFIC...........................................95

LISTA DE TABELAS

Tabela 01 - Etapas de desenvolvimento adotando o modelo cascata.......................16

Tabela 02 - Etapas de desenvolvimento adotando o modelo iterativo.......................17

Tabela 03 - Etapas de desenvolvimento adotando o modelo incremental................18

Tabela 04 - Classes e atributos do sistema SAFIC....................................................68

LISTA DE SIGLAS

SAFIC Sistema de Administração Financeira Condominial

PU Processo Unificado

UML Unified Modeling Language

USDP Unified Software Development Process

RUP Rational Unified Process

POO Programação Orientada a Objetos

SQL Strutured Query Language

DML Data Manipulation Language

TI Tecnologia da Informação

SGBD Sistema de Gerenciamento de Banco de Dados

COLLOCAR EM ORDEM ALFABÉTICA

Sumário

1. INTRODUÇÃO ...................................................................................................... 13

1.1 MOTIVAÇÃO ....................................................................................................... 13

1.2 JUSTIFICATIVA .................................................................................................... 13

1.3 OBJETIVO .......................................................................................................... 13

1.4 ABRANGÊNCIA E RESTRIÇÕES ............................................................................. 14

1.4.1 Abrangência .............................................................................................. 14

1.4.2 Restrições ................................................................................................. 14

1.5 METODOLOGIA ............................................................................................... 1415

1.5.1 Ciclo de Vida de Desenvolvimento de Software ........................................ 15

1.6 AMBIENTES DE USO ............................................................................................ 19

1.7 FERRAMENTAS UTILIZADAS ................................................................................. 20

2. REFERENCIAL TEÓRICO ........................... ....................................................... 21

2.1 ANÁLISE DE REQUISITOS ..................................................................................... 21

2.2 ORIENTAÇÃO A OBJETOS .................................................................................... 23

2.2.1 CLASSES E OBJETOS.................................................................................... 23

2.2.2 ATRIBUTOS E MÉTODOS ........................................................................... 2423

2.2.3 HERANÇA E POLIMORFISMO .......................................................................... 24

2.3 UML ............................................................................................................. 2524

2.3.1 DIAGRAMAS ................................................................................................. 25

2.4 ARQUITETURA DE SOFTWARE ............................................................................................................................. 28

2.4.1 3 CAMADAS ................................................................................................. 2928

2.4.2 PERSISTÊNCIA ............................................................................................. 3029

3. DESENVOLVIMENTO DO SISTEMA .................... .............................................. 31

3.1 ANÁLISE DE REQUISITOS DO SISTEMA .................................................................. 31

3.1.1 OBJETIVO ....................................................................................................... 31

3.1.2 REGRAS DE NEGÓCIO ...................................................................................... 31

3.2 DIAGRAMAS DE CASOS DE USO ........................................................................... 32

3.3 DESCRIÇÃO DOS CASOS DE USO ..................................................................... 4140

3.4 DIAGRAMA DE CLASSES PARCIAL ..................................................................... 6968

3.5 DIAGRAMAS DE SEQUÊNCIA ............................................................................. 7271

3.6 DIAGRAMA DE CLASSES COMPLETO ................................................................. 9291

3.7 MODELAGEM DE DADOS .................................................................................. 9392

3.7.1 TABELAS DO SISTEMA .................................................................................. 9796

4. CONSIDERAÇÕES FINAIS .......................... ................................................. 10197

REFERÊNCIAS BIBLIOGRÁFICAS ........................ ........................................... 10298

13

1 INTRODUÇÃO

A Administração de um condomínio é uma atividade que requer muita

atenção, tanto dos síndicos, como dos condôminos. Diante deste contexto, é

necessário um sistema informatizado que possa realizar todo este processo de

administração e controle. O Sistema de Administração Financeira Condominial

(SAFIC) é um sistema de modelo de gestão que garante a transparência das contas

que são pagas e a parte de cada condômino dentro desse processo. Este sistema

gerencia e controla o pagamento de contas com a finalidade de demonstrar, aos

condôminos, a confiabilidade na atuação do síndico.

1.1 Motivação

A oportunidade de poder demonstrar os conhecimentos adquiridos é um fator

motivador para realização deste trabalho. O aprendizado acadêmico tem sido

satisfatório e, que sem dúvidas, será muito importante e dará uma contribuição

significante para o desenvolvimento do sistema aqui proposto. A realização deste

trabalho estabelecerá um passo importante tanto na vida profissional, quanto

acadêmica, e que trará benefícios e oportunidades de negócios nas próximas etapas

a serem seguidas.

1.2 Justificativa

Para gerenciar financeiramente um condomínio é necessário que, o

administrador disponha de um sistema informatizado, pois é impossível administrar

um conjunto de moradores sem uma ferramenta de controle adequada. A proposta

deste trabalho é oferecer uma solução de gestão condominial online de custo

acessível, onde o cliente não precisará investir em servidores para armazenamento

de dados, uma vez que o acesso ao sistema será via Internet e os recursos

computacionais fornecidos pela empresa prestadora do serviço de hospedagem.

1.3 Objetivo

Desenvolver um sistema que atenda toda a parte de gestão financeira de um

condomínio.

14

1.4 Abrangência e Restrições

1.4.1 Abrangência

O SAFIC abrangerá as seguintes funcionalidades:

� Cadastro de grupos de usuários;

� Cadastro de usuários;

� Cadastro de condomínios;

� Cadastro de contas condominiais;

� Consulta online da movimentação financeira mensal.

O SAFIC oferecerá aos clientes:

� Gestão e controle com conta própria do condomínio;

� Visualização dos documentos em formato PDF;

� Demonstração de contas online sem custos adicionais;

� Balancete mensal disponível online.

� Confiabilidade na gestão do síndico;

� Transparência das atividades;

� Compartilhamento das informações constantemente e em tempo real;

� Agilidade na tomada de decisões;

� Canal de relacionamento.

1.4.2 Restrições

Nesta primeira versão do sistema não contemplará atividades de

contabilização de receitas e despesas do condomínio,bem como a emissão de

boletos bancários das taxas do condomínio.

1.5 Metodologia

O desenvolvimento do sistema SAFIC é baseado na metodologia do Processo

Unificado (Unified Process – UP) de desenvolvimento de software. O PU é um

15

conjunto de atividades necessárias para transformar requisitos do usuário em um

sistema de software. Ele utiliza a Linguagem de Modelagem Unificada (Unified

Modeling Language - UML) no preparo de todos os artefatos do sistema.

Para melhor entender o tópico subsequente que trata especificamente do ciclo de

vida de desenvolvimento de software, é importante conhecer o significado de termos

como ator, cenário e caso de uso, de acordo com (Larman 2007, p. 89):

Um ator , é algo com comportamento, pode ser uma pessoa (identificada por seu papel), um sistema de computador ou até mesmo uma organização. Um cenário é uma sequência específica de ações e interações entre atores e o sistema, também pode ser chamado de instância de caso de uso. Um caso de uso é uma coleção de cenários que descrevem um ator usando um sistema como meio para atingir um objetivo.

1.5.1 Ciclo de Vida de Desenvolvimento de Software

O ciclo de vida de desenvolvimento é mais específico que o ciclo de vida do

software e está relacionado ao processo de desenvolvimento e compreende as

seguintes fases:

a) Iniciação;

b) Fabricação;

c) Implantação.

O modelo de ciclo de vida de desenvolvimento pode ser ajustado de diferentes

formas para cada projeto, de acordo com os modelos abaixo:

a) Modelo Cascata;

b) Modelo Iterativo;

c) Modelo Incremental;

d) Modelo Híbrido.

16

No modelo cascata as atividades do processo de desenvolvimento não se

repetem em diferentes etapas da fase. Não permite versões intermediárias, sendo

apenas a entrega final executável, conforme apresentado na tabela 1.5.

Tabela 1.5 : Etapas de desenvolvimento adotando o modelo cascata.

Fase Iniciação Etapa única (requisitos, todos os Casos de Uso): Atividade: A; Atividade: B; Atividade: C; Fase Fabricação Etapa 1 (projeto, de todos os Casos de Uso, todos os cenários): Atividade: D; Atividade: E; Etapa 2 (implementação, de todos os Casos de uso, todos os cenários): Atividade: F; Atividade: G; Etapa 3 (testes, de todos os Casos de Uso, todos os cenários): Atividade: H; Atividade: I; Atividade: J; Fase Implantação Etapa única

Fonte: JBR (1999) QUEM É JBR????????????????

No modelo iterativo são realizadas entregas intermediárias de executáveis à

medida que as etapas vão sendo executadas. Quando esse modelo é adotado uma

iteração pode ter uma ou mais etapas. O número de iterações e de etapas irá

depender do tamanho do projeto, dos recursos disponíveis e das necessidades do

cliente, conforme observa- se na tabela 1.5.1.

Tabela 1.5.1 : Etapas de desenvolvimento adotando o modelo iterativo.

Fase Iniciação Etapa única (requisitos fundamentais):

Atividade A; Atividade B; Atividade Análise dos Requisitos do Software;

Fase Fabricação/Implantação Iteração 1 (Versão 1) [todos os Casos de Uso, apenas 1 cenário por Caso de Uso]: Etapa 1:

Atividade Análise dos Requisitos do Software (dos cenários desta iteração);

17

Etapa 2: Atividade D; Atividade E;

Etapa 3: Atividade Análise dos Requisitos do Software (dos cenários da próxima

iteração); Atividade F;

Atividade G; Etapa 4: Atividade H; Atividade I; Atividade J; Atividade: Aceitação e instalação no ambiente de produção (Versão1); Iteração 2 (Versão 2) [1/2 (metade) dos Casos de Uso os demais cenários]: Etapa 5: Atividade Análise dos Requisitos do Software (dos cenários da próxima iteração);

Atividade D; Atividade E;

Etapa 6: Atividade H;

Atividade I; Atividade J; Atividade: Aceitação e instalação no ambiente de produção (Versão 2);

Iteração 3 (Versão final) [a outra metade dos Casos de Uso os demais cenários]: Etapa 7: Atividade D;

Atividade E; Etapa 8: Atividade H;

Atividade I; Atividade J; Atividade: Aceitação e instalação no ambiente de produção (Versão final);

Fonte: JBR (1999)

No modelo incremental também há entrega de versões intermediárias à

medida que o desenvolvimento evolui. Cada Incremento é como um mini - projeto,

onde todas as atividades de desenvolvimento são executadas para um subconjunto

dos Casos de Uso, conforme representado na tabela 1.5.2.

Tabela 1.5.2 : Etapas de desenvolvimento adotando o modelo incremental.

Fase Iniciação Etapa única (requisitos): Atividade A; Atividade B Atividade: Análise dos requisitos do software (geral preliminar);

18

Atividade: Análise dos requisitos do software (Casos de Uso do incremento 1) Fase Fabricação/implantação Incremento 1 (Versão 1) [1/3 dos Casos de Uso, todos os cenários]:

Etapa 1: Atividade D; Atividade E; Atividade: Análise dos requisitos do software (Casos de Uso do incremento 2)

Etapa 2: Atividade F;

Atividade G; Etapa 3: Atividade H;

Atividade I Atividade J; Atividade: Aceitação e instalação no ambiente de produção da Versão 1;

Incremento 2 (Versão 2) [o segundo 1/3 dos Casos de Uso, todos os cenários]: Etapa 4:

Atividade D; Atividade E; Atividade: Análise dos requisitos do software (Casos de Uso do incremento 3)

Etapa 5: Atividade H; Atividade I; Atividade J; Atividade: Aceitação e instalação no ambiente de produção da Versão 2;

Incremento 3 (Versão final) [os últimos 1/3 dos Casos de Uso, todos os cenários]: Etapa 6:

Atividade D; Atividade E;

Etapa 7: Atividade H; Atividade I; Atividade J; Atividade: Aceitação e instalação no ambiente de produção da Versão final;

Fonte: JBR (1999)

Nos modelos híbridos, não é necessário utilizar os modelos anteriormente

descritos na sua forma “pura”, –pode-se fazer combinações das características

destes 3 modelos apresentados.

• Combinar o iterativo com o incremental com versões intermediárias.

Fazer alguns cenários, de alguns Casos de Uso em cada etapa – é

o modelo que mais se assemelha ao descrito no Unified Software

Development Process (USDP) e também utilizado no Rational

Unified Process (RUP);

19

• Combinar o iterativo com o incremental sem versões intermediárias;

• Estilo cascata até determinado ponto (por exemplo, duas etapas) depois fazer iterativo ou incremental, com ou sem versões intermediárias.

Na fase de Iniciação do ciclo de vida do software decide-se pelo modelo de

ciclo de vida de desenvolvimento a ser adotado. Esta decisão deve levar em

consideração aspectos do sistema (tamanho, complexidade, novas tecnologias),

prazos, custos e necessidades do cliente, não havendo uma decisão única para

todos os projetos. Portanto cabe ao responsável pelo projeto decidir qual modelo de

ciclo de vida de desenvolvimento será adotado.

Milleto e Bertagnolli (2014) afirmam que, o modelo iterativo e incremental é

um dos processos recomendados no desenvolvimento de aplicações Web, uma vez

que permite incorporar segurança e qualidade à medida que o software é construído.

Este modelo ainda possibilita a divisão das funcionalidades em partes menores ou

iterações. Portanto, em consonância com os autores, o processo de

desenvolvimento do SAFIC será baseado no modelo de desenvolvimento iterativo e

incremental.

SE VC SÓ VAI USAR O INTERATIVO E O INCREMENTAL, NÃO PRECISA FALAR

DOS OUTROS. TODA ESSA PARTES DE CONCEITO DA METODOLOGIA PODE

IR PARA O REFERENCIAL TEORICO

1.6 Ambientes de Uso

A utilização deste sistema será feita principalmente pelo ator principal, o

síndico do condomínio, que será o responsável pela atualização do cadastro das

informações do condomínio ao qual pertence.

Os proprietários de imóveis, moradores do residencial também são partes

interessadas no projeto, uma vez que acompanharão toda a movimentação

financeira do condomínio disponibilizada em tempo real.

Os recursos de hardware e software serão disponibilizados pela empresa

provedora de hospedagem do site conforme contrato de prestação de serviços.

20

1.7 Ferramentas Utilizadas

O sistema vai ser desenvolvido com o auxílio das seguintes ferramentas:

1. Astah Community - é uma ferramenta gratuita de modelagem de

software que utiliza os diagramas da UML. Os diagramas do sistema

vão ser desenhados com o apoio desta ferramenta.

21

2. REFERENCIAL TEÓRICO

Este capítulo apresenta os elementos considerados essenciais, com base na

literatura pesquisada para o desenvolvimento do sistema. A seguir, serão

apresentados conceitos importantes para melhor compreensão e entendimento do

processo de construção do software.

• Análise de Requisitos

• Orientação a Objetos

• UML

• Arquitetura de Software.

2.1 Análise de Requisitos

Para Pressman (2011; p.151):

A análise de requisitos resulta na especificação de características operacionais do software, indica a interface do software com outros elementos do sistema e estabelece restrições que o software deve atender. Permite ainda que você (independentemente de ser chamado de engenheiro de software, analista ou modelador) elabore mais as necessidades básicas estabelecidas durante as tarefas de concepção, levantamento e negociação, que são parte da engenharia de requisitos.

Baseado neste conceito, a análise de requisitos, também chamada de

elicitação1 de requisitos, é uma tarefa da engenharia de software que permite aos

envolvidos no projeto:

� Especificar a função e desempenho do software;

� Identificar interface do software com outros elementos do sistema;

� Estabelecer as restrições de projeto que o software deve enfrentar;

� Desenvolver os modelos comportamentais do software;

� Possibilita ao cliente e desenvolvedor a identificação dos critérios para

avaliar a qualidade do software.

Dentre as atividades na análise de requisitos, podemos destacar:

1 Técnica de obtenção de dados junto aos usuários detentores das informações, principalmente para a construção de um sistema ou um produto ou, ainda para melhorar um processo de trabalho. Ver: http://www.dicionarioinformal.com.br/elicitação/ ,acesso: 24/10/2014.

http://www.dicionarioinformal.com.br/elicita

22

� Reconhecimento do problema – nesta atividade o analista deve

estabelecer contatos em todo ambiente do usuário com as áreas

envolvidas no problema.

� Avaliação do problema e síntese da solução – nesta atividade o

analista deve:

a. Avaliar o fluxo e o conteúdo das informações;

b. Definir e elaborar todas as funções do software;

c. Entender o funcionamento do software dentro do contexto dos

eventos que afetam o sistema;

d. Entender o funcionamento do software dentro do contexto dos

eventos que afetam o sistema.

Os requisitos podem ser classificados conforme a sua finalidade:

1. Funcionais : Estão diretamente relacionados com as funcionalidades

que o software deve oferecer. Exemplo: Cadastro de usuários.

2. Não funcionais : Estão relacionados com os requisitos de qualidade e

de segurança, que se caracterizam por impor limitações no software.

São exemplos de requisitos não funcionais:

• Confiabilidade : probabilidade de não haver falhas num sistema

durante um determinado tempo sob condições específicas;

• Desempenho : mede interação existente entre os componentes com

relação a tempo e espaço;

• Manutenibilidade : processo de reparos, alterações e evoluções de um

sistema após a implantação;

• Segurança : integridade ao sistema quanto aos acessos não

autorizados e a dados não permitidos;

• Reusabilidade : reutilização de componentes desenvolvidos e estados.

23

2.2 Orientação a Objetos

A Programação Orientada a Objetos (POO) será utilizada como base na

implementação do sistema.

A POO é um padrão de desenvolvimento de software baseado em classes. A

partir destas classes são criados os objetos que são utilizados para realizar ações

na memória do computador.

O software desenvolvido nos conceitos da POO é representado por meio de

modelos normalmente criados com o objetivo de representar o sistema de forma

rápida e objetiva. Estes modelos são criados antes da codificação e são construídos

utilizando a UML, que será vista mais adiante.

2.2.1 Classes e Objetos

APUD É UTILIZADO QUANDO NÃO CONSEGUIMOS ENCONTRAR O ARTIGO OU

LIVRO DE DETERMINADO AUTOR. NESTE, CASO, VC ESTÁ FALANDO SOBRE

UML, CUJA LITERATURA ESTÁ DISPONIVEL EM VÁRIOS LUGARES, INCLUSIVE

NA BIBLIOTECA DA FACULDADE. É MELHOR VC MUDAR ESSA REFERENCIA,

AINDA MAIS SENDO UMA REFERENCIA EM OUTRA LINGUA.

BOOCH (1994) apud SEABRA (2013; p.14) definiu uma classe como “um

conjunto de objetos que possuem uma estrutura e comportamentos comuns”. Daí,

pode – se concluir que uma classe define as características e as ações dos seus

objetos, pois estes são sempre criados a partir de uma classe.

Segundo RUMBAUGH (2005) apud SEABRA (2013; p.14) “um objeto é uma

entidade discreta como uma fronteira definida e uma identidade que encapsula

estado e comportamento”. Daí, conclui-se que:

a) Um objeto é uma entidade abstrata que possui fronteira definida e

significado para a aplicação. As fronteiras são definidas pela sua

classe;

b) Objeto é uma instância de uma classe.

24

2.2.2 Atributos e Métodos

Os atributos definem as características ou dados de um objeto. Estas

características também podem ser chamadas de propriedades do objeto, que

representam a estrutura de dados que o objeto possui.

Coloque um exemplo

Os métodos são responsáveis por executarem as ações de um sistema. Eles

podem receber parâmetros e retornar valores. Os retornos indicam o sucesso da

operação ou valor resultante. Um método pode ser definido também como um

conjunto de instruções que realizam determinadas atividades.

2.2.3 Herança e Polimorfismo

Na POO, pode - se criar classes a partir de outras classes existentes. Quando

isso ocorre, a classe criada receberá, como herança, todos os recursos da classe-

base, isto é, seus métodos e atributos.

Coloque um exemplo

O processo de criação de uma classe a partir de outra é denominado

extensão de classe. A classe estendida, aquela utilizada como base, é chamada de

superclasse ou classe-mãe. A outra classe é chamada de subclasse ou classe-filha.

A classe criada é uma especialização daquela que está sendo utilizada como

base de sua criação e a classe-base é uma generalização da que foi criada. Os

métodos e atributos desta classe-base estarão acessíveis também na classe que

está sendo criada.

Após herdar os métodos da superclasse, estes nem sempre atenderão com

perfeição às necessidades da subclasse. Neste caso, estes métodos devem ser

reescritos para se adequar e atender a demanda solicitada pela subclasse. Este

recurso de modificação de métodos é chamado de polimorfismo. O termo

polimorfismo vem do grego poli (muitos) morfo (formas), ou seja, uma característica

25

assumindo várias formas com o objetivo de atender todas às necessidades da nova

classe.

COLOQUE A REFERENCIA DO TEXTO ACIMA DESCRITO

2.3 UML

UML significa Unified Modeling Language ou Linguagem de Modelagem

Unificada. Ela é composta por diagramas, e cada um desses diagramas representa

uma visão de determinada parte do software ou do próprio software como um todo.

É uma linguagem para modelagem de software orientado a objetos. Ela

permite criar modelos abstratos de qualquer software, permitindo uma grande

flexibilidade por parte de quem a utiliza como ferramenta de modelagem.

A UML oferece recursos suficientes para representar o software por vários

pontos de visão. Modelar software com UML é uma tarefa indispensável no

desenvolvimento de sistemas, uma vez que com ela é possível definir traçar um

objetivo, ou seja, definir o caminho mais adequado no desenvolvimento do software.

Uma das características dessa linguagem é que ela não permite um único

padrão de modelagem, visto que ela dá total liberdade na criação de modelos. A

função da UML é permitir a representação dos objetos de software e a comunicação

entre eles. A sua utilização é muito ampla no mercado de softwares, seja para a

documentação dos requisitos de sistemas ou para a comunicação e posicionamento

de todos os envolvidos no projeto.

2.3.1 Diagramas

A UML é composta por diagramas, entretanto, serão exemplificados apenas

os diagramas mais usuais e os que efetivamente serão utilizados na implementação

do sistema.

Diagrama de Casos de Uso

26

O diagrama de casos de uso representa os requisitos do sistema. Os

analistas utilizam este diagrama para documentar as funcionalidades do sistema. É

representado pelo Ator, ou seja, o usuário do sistema, trocando mensagens com

“bolhas” que representam as funções e recursos do sistema. A figura 2.3 é um

exemplo de caso de uso, no qual o usuário inicia um cadastro de cliente no sistema.

Figura 2.3 : Exemplo de diagrama de caso de uso

Fonte: Elaborado pelo Autor

Diagrama de Casos de Uso

O diagrama de classes é um dos diagramas mais conhecidos da UML. O

diagrama de classes é essencial na criação do modelo, já que sem ele fica

impossível definir os outros diagramas do projeto. Na visualização do diagrama de

classes do sistema, tem – se uma visão de como deverá ser as tabelas do banco de

dados e seus relacionamentos, além de permitir que as operações a serem

executadas pelo sistema sejam facilmente visualizadas, uma vez que cada entidade

apresenta seus atributos e operações disponíveis. A figura 2.3.1 exemplifica um

diagrama de classes de um software para controle de estoque.

Figura 2.3.1 : Um diagrama de classes de um sistema de controle de estoque.

27

Fonte: Elaborado pelo Autor

Diagrama de Sequência

O diagrama de sequência é muito importante na UML, pois ele representa a

troca de mensagens entre os objetos do sistema, em uma ordem de tempo,

permitindo que o desenvolvedor tenha uma visão nítida das tarefas relacionadas no

sistema e do que deve ser programado primeiro. A figura 2.3.2 mostra um diagrama

de sequência de um cadastro de cliente.

Figura 2.3.2 : Exemplo de um diagrama de sequência para um cadastro de cliente.

28

Fonte: Lobo (2007) 2007 OU 2009 ??????????????????

2.4 Arquitetura de Software

Segundo Bauer e King (2007; p.20) “uma arquitetura em camadas define

interfaces entre os códigos que implementam as várias funcionalidades, permitindo

que mudanças sejam feitas sem afetar significativamente o código em outras

camadas”.

Baseado nesta afirmação, conclui – se que a forma como é distribuída as

camadas determina os tipos de dependência que ocorrem entre as camadas. A

comunicação entre elas é feita do topo para a base, ou seja, uma camada é

29

dependente somente da camada abaixo dela. Cada camada não tem conhecimento

de qualquer outra camada, exceto a que está abaixo dela.

2.4.1 3 Camadas

A arquitetura definida para o desenvolvimento deste sistema é a arquitetura

definida como 3 Camadas (figura 2.4.1) , uma vez que esta é, atualmente, a mais

utilizada, além de servir de base para outras arquiteturas. Ela representa uma

evolução da arquitetura cliente-servidor, visto que nela a camada de negócio fica

separada da camada cliente e da camada servidora. A arquitetura em 3 camadas é

composta pelas camadas de apresentação, lógica de negócio e camada de dados

ou persistência.

� Camada de Apresentação - É a camada de interface, interage

diretamente com o usuário. É através dela que são feitas as

requisições.

� Camada de Negócio - Também chamada de Regras de Negócio. È

nela que fica as funções e regras de todo o negócio.

� Camada de Dados ou Persistência - É um grupo de classes e

componentes responsáveis por guardar os dados ou recuperá-los de

um ou mais repositório de dados.

Figura 2.4.1 : Representação de uma arquitetura em 3 Camadas

30

Fonte: flavioaf.wordpress.com ???? FORMA DE REFERENCIA INCORRETA

2.4.2 Persistência

Para Bauer e King (2007; p.5):

Persistência é um dos conceitos fundamentais no desenvolvimento de

aplicações. Se um sistema de informação não preservar os dados quando

ele for desligado, o sistema será de pouco uso prático. Quando falamos de

persistência, normalmente estamos falando sobre como guardar dados em

um banco de dados relacional usando SQL. Em uma aplicação orientada

para objetos, a persistência permite um objeto sobreviver ao processo que o

criou. O estado do objeto pode ser guardado no disco, e um objeto com um

mesmo estado pode ser recriado em algum ponto no futuro.

Entende – se neste sentido que isto não está limitado a objetos isolados,

redes inteiras de objetos interconectados podem ser tornadas persistentes e mais à

frente recriadas em um novo processo. Um objeto transiente tem um tempo de vida

limitado que é delimitado pela vida do processo que o instanciou. Quase todas as

aplicações possuem uma mistura de objetos persistentes e transientes; é por essa

razão, que precisamos de um subsistema que gerencie nossos dados persistentes.

Bancos de dados relacionais modernos fornecem uma representação

estruturada dos dados persistentes, permitindo a manipulação, a classificação, a

31

busca e a agregação dos dados. Os sistemas de gerenciamento de banco de dados

são responsáveis por:

� Armazenamento, organização, e recuperação de dados estruturados;

� Concorrência e integridade dos dados;

� Compartilhamento de dados;

� Segurança.

COLOQUE A REFERENCIA DO TEXTO ACIMA DESCRITO

3. DESENVOLVIMENTO DO SISTEMA

Este capítulo apresenta a documentação do desenvolvimento do sistema

SAFIC, colocando de forma prática os conceitos e as teorias apresentadas nos

capítulos anteriores, e com base no conhecimento adquirido ao longo do curso de

Sistemas de Informação. Ele é composto pela análise de requisitos, diagramas de

casos de uso, descrição dos casos de uso, diagramas de classe, diagramas de

sequência, e finalizando com a modelagem do banco de dados.

3.1 Análise de Requisitos do Sistema

3.1.1 Objetivo

Desenvolver uma aplicação Web para gerenciamento e controle financeiro de

condomínios.

3.1.2 Regras de Negócio

Na reunião com o cliente foram definidas as seguintes regras de negócio:

32

1) O acesso ao sistema deverá der feito pelo site da empresa prestadora

do serviço por meio de link específico;

2) Para entrar no sistema, o usuário deve informar seu código de usuário,

neste caso o número do Cadastro de Pessoa Física (CPF).;

3) O cadastro dos usuários será realizado por auto cadastramento;

4) Será enviado um e-mail automático para que o usuário valide o seu

cadastro no SAFIC, uma vez que o mesmo só terá acesso definitivo ao

sistema quando houver a confirmação dos dados cadastrais;

5) O administrador e o síndico do condomínio podem excluir usuários do

sistema;

6) Os dados do condomínio devem ser preenchidos pelo síndico em

formulário disponível no site do administrador do serviço, que por sua

vez irá inserir estes dados no sistema.

3.2 Diagramas de Casos de Uso

Definidas as regras de negócio, passamos para a etapa de modelagem do

sistema com a UML. A figura 3.2 mostra o diagrama de todos os casos de uso do

sistema.

Figura 3.2: Diagrama de casos de uso do SAFIC

33

Fonte: Elabiorado pelo Autor

O caso de uso Manter Categorias de Acesso é composto pelos casos de

uso:

� Cadastrar categoria;

� Alterar categoria;

� Excluir categoria;

� Pesquisar categoria.

A figura 3.2.1 representa a composição do caso de uso “Manter Categorias

de Acesso”.

Figura 3.2.1: Diagrama de caso de uso “Manter Categorias de Acesso”

34

Fonte: Autor

O caso de uso “Manter Grupos” é composto pelos casos de uso:

� Cadastrar grupo;

� Alterar grupo;

� Excluir grupo;

� Pesquisar grupo.

A figura 3.2.2 representa a composição do caso de uso ”Manter Grupos”.

Figura 3.2.3: Diagrama de caso de uso “Manter Grupos”

35

Fonte: Autor

O caso de uso “Manter Usuários” é composto pelos casos de uso:

� Cadastrar usuário;

� Alterar usuário;

� Excluir usuário;

� Pesquisar usuário.

A figura 3.2.3 representa a composição do caso de uso “Manter Usuários”.

36

Figura 3.2.3: Diagrama de caso de uso “Manter Usuários”

Fonte: Autor

O caso de uso “Manter Condomínios” é composto pelos casos de uso:

� Cadastrar condomínio;

� Alterar condomínio;

� Excluir condomínio;

� Pesquisar condomínio.

A figura 3.2.4 representa a composição do caso de uso “Manter Condomínios”.

37

Figura 3.2.4: Diagrama de caso de uso “Manter Condomínios”

Fonte: Autor

O caso de uso “Manter Contas” é composto pelos casos de uso:

� Cadastrar conta;

� Alterar conta;

� Excluir conta;

� Pesquisar conta.

A figura 3.2.5 representa a composição do caso de uso “Manter Contas”.

38

Figura 3.2.5: Diagrama de caso de uso “Manter Contas”

Fonte: Autor

O caso de uso “Manter Parecer” é composto pelos casos de uso:

� Cadastrar parecer;

� Alterar parecer;

� Excluir parecer;

� Pesquisar parecer.

A figura 3.2.6 representa a composição do caso de uso “Manter Parecer”.

39

Figura 3.2.6: Diagrama de caso de uso “Manter Parecer”

Fonte: Autor

O caso de uso “Efetuar Log in” é representado conforme a figura 3.2.7 .

40

Figura 3.2.7: Diagrama de caso de uso “Efetuar Log in”

Fonte: Autor

O caso de uso “Consultar Contas” é representado conforme a figura 3.2.8 .

Figura 3.2.8: Diagrama de caso de uso “Consultar Contas”

Fonte: Autor

41

3.3 Descrição dos Casos de Uso

Caso de Uso: Manter Condomínios

Visão Geral:

Este caso uso tem por objetivo permitir consultar, incluir, alterar e excluir o

registro de condomínios no sistema SAFIC (Sistema de Administração Financeira

Condominial).

Ator:

Administrador

Fluxo de Eventos:

Fluxo Principal

Ator Sistema Classe

1. O caso de uso começa quando o ator

seleciona a opção “Condomínios”.

a) Se for cadastrar, ver seção

“Cadastrar condomínio”.

b) Se for alterar, ver seção “Alterar

condomínio”.

c) Se for excluir, ver seção “Excluir

condomínio”.

42

a. Seção “Cadastrar Condomínio”

Ator Sistema Classe

1. O ator seleciona a opção

“Cadastrar condomínio”.

2. Apresenta página para

receber os dados do

condomínio.

3. Informa o CNPJ.

4. Validar CNPJ (Include

“Validar CNPJ”).

5. Informa os outros dados

6. Validar os outros dados

(Include “Validar dados”).

7. Solicita autorização para

incluir no banco de dados.

8. Autoriza inclusão no banco

de dados.

9. Inclui no banco de dados CONDOMINIOS

Fluxo Alternativo:

4.1 O sistema apresenta a mensagem: “CNPJ inválido. Favor verificar”;

5.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.

43

b. Seção “Alterar Condomínio”

Ator Sistema Classe


“Alterar condomínio”.


digitar o código do

condomínio.

3. Informa o código do

condomínio.

4. Obter dados do

condomínio.

CONDOMINIOS

5. Informa os novos dados.

6. Validar CNPJ (Include

“Validar CNPJ”).

7. Validar os novos dados



alteração no banco de

dados.

9. Autoriza alteração no banco

de dados.

10. Altera no banco de

dados

CONDOMINIOS

Fluxo Alternativo:

4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”;

6.1 O sistema apresenta a mensagem: “CNPJ inválido. Favor verificar”;


44

c. Seção “Excluir condomínio”

Ator Sistema Classe


“Excluir condomínio”.


digitar o código do

condomínio.


condomínio.

4. Obter dados do

condomínio.

CONDOMINIOS


exclusão no banco de dados.

6. Autoriza exclusão no

banco de dados.

7. Exclui do banco de dados CONDOMINIOS

Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”.

45

Caso de Uso: Manter Categorias de Acesso

Visão Geral:

Este caso uso tem por objetivo permitir consultar, incluir, alterar e excluir o registro

de categorias de acesso no sistema SAFIC (Sistema de Administração Financeira

Condominial).

Ator:

Administrador.

Fluxo de Eventos:

Fluxo Principal

Ator Sistema Classe


seleciona a opção “Categorias”.

a) Se for cadastrar, ver seção

“Cadastrar categorias”.


categorias”.


categorias” .

46

a. Seção “Cadastrar Categoria” Ator Sistema Classe

1. O ator seleciona a

opção “Cadastrar

categoria”.


receber os dados da

categoria.

3. Informa os dados da

categoria.

4. Validar os dados (Include

“Validar dados”).



7. Autoriza inclusão no

banco de dados.

8. Inclui no banco de dados CATEGORIAS_ACESSO

Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.

47

b. Seção “Alterar Categoria”

Ator Sistema Classe


opção “Alterar

categorias”.


digitar o código da categoria.

3. Informa o código da

categoria.

4. Obter dados da categoria. CATEGORIAS_ACESSO

5. Informa os novos

dados.




alteração no banco de dados.

8. Autoriza alteração no

banco de dados.

9. Altera no banco de dados CATEGORIAS_ACESSO

Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”;


48

c. Seção “Excluir Categoria”

Ator Sistema Classe


opção “Excluir

categoria”.


digitar o código da categoria.


categoria.

4. Obter dados da categoria.

CATEGORIAS_ACESSO




banco de dados.

7. Exclui do banco de dados CATEGORIAS_ACESSO


49

Caso de Uso: Manter Grupos

Visão Geral:


de grupos de usuários no sistema SAFIC (Sistema de Administração Financeira

Condominial).

Ator:

Administrador.

Fluxo de Eventos:

Fluxo Principal

Ator Sistema Classe


seleciona a opção “Grupos”.

a) Se for cadastrar, ver seção “Cadastrar

grupos”.

b) Se for alterar, ver seção “ Alterar grupos”.

c) Se for excluir, ver seção “ Excluir grupos”.

50

a. Seção “Cadastrar Grupos” Ator Sistema Classe

1. O ator seleciona

a opção “Cadastrar

grupo”.

2. Apresenta página para receber

os dados do grupo.

3. Listar categorias CATEGORIAS_ACESSO

4. Informa os dados

do grupo.

5. Validar os dados (Include


6. Solicita autorização para incluir

no banco de dados.

7. Autoriza inclusão

no banco de dados.

8. Inclui no banco de dados GRUPOS


51

b. Seção “Alterar Grupo”

Ator Sistema Classe


opção “Alterar

grupos”.


digitar o código do grupo.

3. Informa o código

do grupo.

4. Obter dados do grupo.

GRUPOS

5. Listar categorias CATEGORIAS_ACESS

O

6. Informa os novos

dados.


(Include “Validar dados” ).



9. Autoriza alteração

no banco de dados.

10. Altera no banco de dados GRUPOS



52

c. Seção “Excluir Grupo”

Ator Sistema Classe


“Excluir grupo”.

2. Apresenta página para digitar

o código da categoria.


grupo.

4. Obter dados do grupo.

GRUPOS




banco de dados.

7. Exclui do banco de dados GRUPOS


53

Caso de Uso: Manter Usuários

Visão Geral:


de usuários no sistema SAFIC (Sistema de Administração Financeira Condominial).

Ator: Administrador, Usuário online (Síndico).

Fluxo de Eventos: Fluxo Principal

Ator Sistema Classe


seleciona a opção “ Usuários” .


usuários”.


usuários”.


usuários”.

54

a. Seção “Cadastrar Usuários”

Ator Sistema Classe


opção “Cadastrar usuário”.

2. Apresenta página para receber os

dados do usuário.

3. Listar grupos GRUPOS

4. Listar condomínios CONDOMINIOS

5. Informa o CPF.

7. Informa os outros dados

8. Validar os outros dados (include


9. Solicita autorização para incluir no

banco de dados.


banco de dados.

11. Inclui no banco de dados USUARIOS

Fluxo Alternativo:

5.1 O sistema apresenta a mensagem: “CPF inválido. Favor verificar”.


55

b. Seção “Alterar Usuário”

Ator Sistema Classe


opção “Alterar

usuário”.


digitar o código do usuário.

3. Informa o código

do usuário.

4. Obter dados do usuário. USUARIOS

5. Listar grupos CATEGORIAS_ACESS

O


7. Informa os novos

dados.



9. Solicita autorização

para alteração no banco

de dados.

10. Autoriza

alteração no banco

de dados.

11. Altera no banco de

dados

USUARIOS

Fluxo Alternativo:

4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”;


56

c. Seção “Excluir Usuário”

Ator Sistema Classe


“Excluir usuário”.

2. Apresenta página para digitar o

código do usuário.


usuário.

4. Obter dados do usuário.

USUARIOS

5. Solicita autorização para exclusão

no banco de dados.


banco de dados.

7. Exclui do banco de dados USUARIOS


57

Caso de Uso: Manter Contas

Visão Geral:


de contas condominiais no sistema SAFIC (Sistema de Administração Financeira

Condominial).

Ator:

Usuário online (Síndico).

Fluxo de Eventos:

Fluxo Principal

Ator Sistema Classe


seleciona a opção “ Contas Condominiais”.


contas”.

b) Se for alterar, ver seção “Alterar contas”.

c) Se for excluir, ver seção “Excluir contas”.

58

a. Seção “Cadastrar Contas”

Ator Sistema Classe


“Cadastrar contas”.


receber os dados de contas.


4. Informa os dados de

contas.

5. Validar os dados (include




7. Autoriza inclusão no banco

de dados.

8. Inclui no banco de dados CONTAS


59

b. Seção “Alterar Contas”

Ator Sistema Classe


opção “Alterar conta” .

2. Apresenta página para digitar

o código da conta.


conta.

4. Obter dados da conta.

CONTAS


7. Informa os novos

dados.


(Include “Validar dados” ).




banco de dados.

11. Altera no banco de dados CONTAS



60

c. Seção “Excluir Conta”

Ator Sistema Classe


“Excluir conta” .

2. Apresenta página para digitar o

código da conta.


conta.

4. Obter dados da conta.

CONTAS




banco de dados.

7. Exclui do banco de dados CONTAS

Fluxo Alternativo:

4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”.

61

Caso de Uso : Manter Parecer

Visão Geral:


de contas condominiais no sistema SAFIC (Sistema de Administração Financeira

Condominial).

Ator:

Usuário online (Síndico)

Fluxo de Eventos:

Fluxo Principal

Ator Sistema Classe


seleciona a opção “Parecer”.


parecer”.


parecer”.


parecer”.

62

a. Seção “Cadastrar Parecer”

Ator Sistema Classe


opção “Cadastrar

parecer”.


os dados do parecer.


4. Informa os dados de

parecer.

5. Validar os dados (include



no banco de dados.


banco de dados.

8. Inclui no banco de dados PARECER


63

b. Seção “Alterar Parecer”

Ator Sistema Classe


“Alterar parecer”.


pesquisar parecer.

3. Informa os dados para

pesquisar parecer.

4. Obter dados do parecer.

PARECER


6. Informa os novos dados.






banco de dados.

10. Altera no banco de dados CONTAS


64

c. Seção “Excluir Parecer”

Ator Sistema Classe


“ Excluir parecer” .

2. Apresenta página para pesquisa

parecer

3. Informa os dados para

pesquisar parecer.

4. Obter dados do parecer.

PARECER




banco de dados.

7. Exclui do banco de dados PARECER


65

Caso de Uso: Consultar Contas

Visão Geral:

Este caso uso tem por objetivo permitir consultar o registro de contas condominiais

no sistema SAFIC (Sistema de Administração Financeira Condominial).

Ator:

Usuário online (Consulta)

Fluxo de Eventos:

Fluxo Principal

Ator Sistema Classe


“Consultar contas” .

2. Apresenta página de consulta.

3. Informa o mês e o ano de

referência

4. Obter dados de contas do

mês/ano.

CONTAS

5. Listar parecer do mês/ano PARECER

Fluxo Alternativo: 5.1 O sistema apresenta a mensagem: “Conta não localizada. Favor verificar”.

Formatado: Português (Brasil)

66

Caso de Uso: Efetuar Log in

Visão Geral:

Este caso uso tem por objetivo descrever a forma como o usuário acessa o sistema

SAFIC (Sistema de Administração Financeira Condominial).

Ator:

Administrador;

Usuário online.

Fluxo de Eventos:

Fluxo Principal

Ator Sistema Classe


seleciona a opção “ SAFIC-Sistema de

Administração Financeira Condominial”.

a) Se for logar no sistema, ver seção “Log

in”.

b) Se for novo usuário ver seção “ Novo

usuário“.

67

a. Seção “Log in”

Ator Sistema Classe


“SAFIC”.

USUARIOS

2. Apresenta página de log in.

3. Informa o nome de

usuário e a senha.

4. Criptografar senha (include

“Criptografar Senha”).

5. Checa usuário e senha.

6. Autentica o usuário no sistema

Fluxo Alternativo:

5.1 O sistema apresenta a mensagem: “Usuário inválido. Favor verificar”.

5.2 O sistema apresenta a mensagem: “Senha inválida. Favor verificar”.

68

b. Seção “Novo Usuário”

Ator Sistema Classe


opção “Novo usuário”.


os dados do usuário.

3. Listar grupos GRUPOS


5. Informa os dados.

6. Validar CPF (include “Validar

CPF”).

7. Validar os outros dados



no banco de dados.


banco de dados.

10. Inclui no banco de dados USUARIOS

11. Envia e-mail (include “Envia

E-mail”).

Fluxo Alternativo:

6.1 O sistema apresenta a mensagem: “CPF Inválido. Favor verificar”;


69

3.4 Diagrama de Classes Parcial

Finalizada a etapa da descrição dos casos de uso, pode – se definir as

classes do sistema. A tabela abaixo mostra as classes e os atributos do sistema

SAFIC.

Tabela 3.4: Classes e atributos do sistema SAFIC (Continua)

Classe Atributos

CONDOMINIOS

codCont

nomeCond

cnpj

inscMunicipal

dtFinalMandato

qtdeBlocos

qtdeAndares

qtdeAptosPorAndar

valorCondominial

cep

logradouro

nro

complemento

bairro

cidade

uf

CATEGORIAS_ACESSO

codGrupo

nomeGrupo

descricao

dtCadastro

GRUPOS

codGrupo

nomeGrupo

descricao

dtCadastro

Fonte: Autor

70

Tabela 3.4: Classes e atributos do SAFIC

Classe Atributos

USUARIOS

codUsuario

nome

cpf

apto

bloco

telefone

celular

email

senha

validado

dtCadastro

dtAtualizacao

CONTAS

id

mes

ano

tpLancamento

valor

nroNotaFiscal

descricao

documento

dtCadastro

login

PARECER

id

mes

ano

descricao

dtCadastro

Fonte: Autor

71

A figura 3.4 representa o diagrama de classes parcial

Figura 3.4: Diagrama de classes parcial

Fonte: Autor

72

3.5 Diagramas de Sequência

O diagrama de sequência é uma ferramenta poderosa na representação de

troca de mensagens e operações realizadas por objetos do sistema. Este tópico

apresenta a modelagem dos diagramas de sequência do sistema.

Os diagramas das figuras 3.5 , 3.5.1 e 3.5.2 representam as operações de

inclusão, alteração e exclusão da classe Condomínios.

Figura 3.5: Diagrama de sequência “Incluir Condomínio”

Fonte: Autor

73

Figura 3.5.1: Diagrama de sequência “Alterar Condomínio”

Fonte: Autor

74

Figura 3.5.2: Diagrama de sequência “Excluir Condomínio”

Fonte: Autor

75

Os diagramas das figuras 3.5.3 , 3.5.4 e 3.5.5 representam as operações de

inclusão, alteração e exclusão da classe Categorias_Acesso.

Figura 3.5.3: Diagrama de sequência “Incluir Categoria”

Fonte: Autor

76

Figura 3.5.4: Diagrama de sequência “Alterar Categoria”

Fonte: Autor

77

Figura 3.5.5: Diagrama de sequência “Excluir Categoria”

Fonte: Autor

78

Os diagramas das figuras 3.5.6 , 3.5.7 e 3.5.8 representam as operações de

inclusão, alteração e exclusão da classe Grupos

Figura 3.5.6: Diagrama de sequência “Incluir Grupo”

Fonte: Autor

79

Figura 3.5.7: Diagrama de sequência “Alterar Grupo”

Fonte: Autor

80

Figura 3.5.7: Diagrama de sequência “Excluir Grupo”

Fonte: Autor

81

Os diagramas das figuras 3.5.9 , 3.5.10 e 3.5.11 representam as operações

de inclusão, alteração e exclusão da classe Usuários.

Figura 3.5.9: Diagrama de sequência “Incluir Usuário”

Fonte: Autor

82

Figura 3.5.10: Diagrama de sequência “Alterar Usuário”

Fonte: Autor

83

Observações importantes a considerar na operação de alteração do usuário:

1. O administrador visualiza todos os usuários e tem permissão para fazer

alterações no cadastro de usuário;

2. O usuário online (Síndico) visualiza apenas os usuários relacionados ao

seu condomínio e tem permissão para alterações no cadastro destes

usuários;

3. O usuário online (Consulta) visualiza apenas os seus dados cadastrais e

tem permissão de alterar apenas estes.

Figura 3.5.11: Diagrama de sequência “Excluir Usuário”

Fonte: Autor

A operação de exclusão de usuários do sistema é permitida apenas para o

administrador e o usuário online (Síndico).

84


de inclusão, alteração e exclusão da classe Contas. Estas operações são atividades

exclusivas do usuário online (Síndico), uma vez que ele é o responsável por esta

manutenção de dados para que os condôminos visualizem as informações relativas

ao condomínio.

Figura 3.5.12: Diagrama de sequência “Incluir Contas”

Fonte: Autor

85

Figura 3.5.13: Diagrama de sequência “Alterar Contas”

Fonte: Autor

86

Figura 3.5.13: Diagrama de sequência “Excluir Contas”

Fonte: Autor


de inclusão, alteração e exclusão da classe Parecer. Estas operações são atividades

exclusivas do usuário online (Síndico).

87

Parecer, no sistema, é uma observação ou ocorrência com relação às contas

do condomínio que o síndico registra mensalmente no sistema para ciência dos

condôminos.

Figura 3.5.14: Diagrama de sequência “Incluir Parecer”

Fonte: Autor

88

Figura 3.5.15: Diagrama de sequência “Alterar Parecer”

Fonte: Autor

89

Figura 3.5.16: Diagrama de sequência “Excluir Parecer”

Fonte: Autor

90

O diagrama da figura 3.5.17 representa a operação de consultar contas. Esta

é uma atividade específica do usuário online (Consulta).

Figura 3.5.17: Diagrama de sequência “Consultar Contas”

Fonte: Autor

91

A figura 3.5.18 representa o diagrama de sequência de log in do sistema.

Figura 3.5.18: Diagrama de sequência “Efetuar Log in”

Fonte: Autor

Descrição das ações e troca de mensagens deste diagrama.

1. O usuário solicita ao site uma página para efetuar log in no sistema

2. O site retorna uma página de log in ao usuário, que possui uma opção

de cadastrar novo usuário ou efetuar um log in como um usuário já

cadastrado.

3. O usuário insere os seus dados de log in e senha.

4. A página de servidor recebe os dados enviados pelo usuário, efetua

uma criptografia da senha pelo método “Criptografar Senha”. Verifica

se o usuário está cadastrado e se a senha está de acordo com os

dados no banco de dados, através do método “Validar Login”. Caso o

usuário esteja cadastrado e a senha de acordo com a armazenada no

banco, o log in é efetivado.

5. A página de servidor envia uma mensagem para a interface sobre o

resultado da operação.

92

3.6 Diagrama de Classes Completo

Finalizada a etapa de modelagem dos diagramas de sequência, o diagrama

de classes agora está completo, conforme figura 3.6 . Cada uma das classes

possuem as operações básicas de manutenção de dados, que são incluir, alterar,

excluir e pesquisar, além dos outros métodos de controle do sistema.

Figura 3.6: Diagrama de classes completo

Fonte: Autor

93

3.7 Modelagem de Dados

A modelagem de dados é uma área da Tecnologia da Informação (TI) que

estuda e apresenta ferramentas para descrever os dados de forma conceitual, isto é,

utilizando símbolos e gráficos. A simbologia favorece um ganho considerável, em

aspectos como precisão e rapidez na representação dos dados, permitindo, desta

forma, que qualquer banco de dados seja projetado antes da sua criação.

Entretanto, esta não é a primeira ação a ser feita em um processo de

desenvolvimento de software, uma vez que a análise e o projeto do sistema são

definidos antes da criação de um modelo de dados.

Existem vários modelos de dados, porém os mais utilizados atualmente são:

• Modelos Orientados a Objetos;

• Modelos Relacionais.

No modelo orientado a objeto, os dados são representados através de

objetos, ou seja, os valores são armazenados em um conjunto de objetos. Cada

objeto deste modelo contém métodos que operam este objeto, e também pode ter

um agrupamento de objetos em suas classes. O grau de complexidade deste

modelo ainda é muito elevado, o que pode ser um fator relevante que as empresas

consideram quanto a sua utilização.

O Modelo Relacional foi proposto por Edgard Frank Cood, um matemático do

Laboratório de Pesquisas da IBM, em seu trabalho “Um Modelo Relacional para

Grandes Bancos de Dados”, publicado em 1970, pelo qual descreve uma álgebra

relacional para dados organizados em tabelas. Este trabalho foi ponto de partida

para que outros começassem estudos para construção de sistemas com base no

modelo relacional. O termo relacional não vem do relacionamento entre as tabelas

de dados, e, sim, do conceito matemático de relação – um subconjunto do produto

cartesiano de uma lista de domínio.

94

O Modelo de Entidades e Relacionamentos (MER) é o modelo relacional que

representa o banco de dados como uma coleção de relações. Informalmente, cada

relação representa uma tabela de valores, onde cada linha da tabela representa uma

coleção de valores de dados relacionais.

De forma simplificada, pode-se dizer que um banco de dados relacional

objetiva implementar os conceitos do modelo relacional com todas as suas

características básicas, ou seja, com entidades, atributos e relacionamentos.

Conceitualmente, um software de banco de dados relacional usa tabelas para

representar as entidades e as colunas para representar os atributos. Os

relacionamentos são mantidos com a utilização de chaves. As operações

relacionais, como união e intersecção, também são realizadas.

As linhas das tabelas são conhecidas como tuplas ou registros. Cada tupla

deve estar associada a uma chave única, que permita identificá-la. Uma chave pode

ser composta por um ou mais atributos, porém deve ser única dentro de sua tabela.

Existem dois tipos de chaves:

1. Chave primária (Primary Key) : é o valor ou conjunto de identificam

uma fila dentro de uma tabela, sendo que este valor nunca pode ser

nulo. Um exemplo de chave primária é o CPF, que é único para cada

pessoa e não pode ser nulo;

2. Chave estrangeira (Foreign Key) : é o valor ou valores de uma tabela

correspondente ao valor de uma chave primária em outra tabela. Esta

chave é a que representa as relações entre as tabelas.

Outros aspectos relevantes a serem considerados na modelagem do banco

de dados relacional são:

1. Integridade Referencial : assegura por meio de um conjunto de regras

que os relacionamentos entre as entidades sejam válidos. (LIMA, 2005)

A título de exemplo, imaginemos as entidades “Cliente” e “Pedido”,

95

caso ocorra uma exclusão de um cliente, isso implicará na exclusão de

todos os pedidos referentes ao cliente eliminado, caso contrário estes

pedidos ficariam “soltos”, ou seja, sem nenhuma referência, pois o

cliente não existe mais. Quando uma ocorrência da entidade-mãe for

eliminada, é possível definir que todas as ocorrências dessa entidade

sejam eliminadas em todas as entidades relacionadas, este é o

processo de eliminação em cascata. Entretanto, o SGBD permite uma

segunda opção: impedir a eliminação de uma ocorrência na entidade-

mãe enquanto não forem eliminadas as ocorrências nas entidades-

filhas. No MER, isso também é previsto antes da implementação física.

2. Normalização : é um conjunto de regras (formas normais)

estabelecidas garantindo a consistência do modelo de dados, cada

forma normal refere - se a um tipo de duplicação de valores em um ou

mais atributos de uma entidade. (LIMA, 2005). As formas normais são:

a) Primeira forma normal : refere-se aos valores repetidos.

Quando isto acontece, a solução é criar uma nova

entidade tendo como chave estrangeira o atributo que é

chave primária da entidade a ser normalizada;

b) Segunda forma normal : uma entidade está na segunda

forma normal quando cada ocorrência possui uma chave

primária, isto é, cada atributo é dependente totalmente

dessa chave, além de satisfazer a primeira forma normal;

c) Terceira forma normal : uma entidade está na terceira

forma normal quando cada atributo depende diretamente

da chave primária, ou seja, não deve existir 2dependência

transitiva, além de satisfazer a segunda forma normal.

2 Dependência transitiva ocorre quando uma coluna, além de depender da chave primária da tabela, depende de outra coluna ou conjunto de colunas da tabela.

96

A figura 3.7 representa a modelagem do MER, baseado no diagrama de

classes do sistema que foi criado anteriormente, com a aplicação de todos os

fundamentos apresentados.

Figura 3.7: Modelo Entidade-Relacionamentos do SAFIC

Fonte: Autor

97

3.7.1 Tabelas do Sistema

A estrutura do banco de dados é composta pelas seguintes tabelas :

Tabela : Condominios

Chave Primária :codCond

Chave(s) Estrangeira(s) : Não tem

Campo Tipo de Dados Tamanho

codCond Numérico inteiro

nomeCond Caractere 150

cnpj Caractere 20

dtFinalMandato Data/Hora -

inscricaoMunicipal Caractere 20

qtdeBlocos Numérico inteiro

qtdeAndares Numerico inteiro

qtdeAptosPorAndar Numérico inteiro

qtdeCasas Numérico

valorCondominial Numérico Decimal

cep Caractere 9

logradouro Caractere 150

nro Caractere 10

complemento Caractere 45

bairro Caractere 50

cidade Caractere 45

uf Caractere 2

98

Tabela : Categorias_Acesso

Chave Primária :codCategoria

Chave(s) Estrangeira(s) : Não tem


codCategoria Numérico inteiro

nomeCategoria Caractere 50

descricao Caractere 150

dtCadastro Data/Hora -

Tabela : Grupos

Chave Primária :codGrupo

Chave(s) Estrangeira(s) : codCategoria


codGrupo Numérico inteiro

codCategoria Numérico inteiro

nomeGrupo Caractere 50



99

Tabela : Usuarios

Chave Primária :codUsuario

Chave(s) Estrangeira(s) : codCond, codGrupo


codUsuario Numérico inteiro


codGrupo Numérico inteiro

nome Caractere 100

cpf Caractere 15

Apto Caractere 5

Bloco Caractere 5

telefone Caractere 15

celular Caractere 15

email Caractere 30

senha Caractere 15


validado Numérico inteiro

100

Tabela : Contas

Chave Primária : id

Chave(s) Estrangeira(s) : codCond


id Numérico Duplo


Mes Caractere 2

Ano Caractere 4

tp_lancamento Caractere 1

valor Numérico Decimal

nroNotaFiscal Caractere 10


documento Caractere 100


dtAtualizacao Data/Hora -

login Caractere 15

Tabela : Parecer

Chave Primária : id

Chave(s) Estrangeira(s) : codCond


id Numérico inteiro


Mes Caractere 2

Ano Caractere 4



101

4. CONSIDERAÇÕES FINAIS

102

REFERÊNCIAS BIBLIOGRÁFICAS

BAUER, C.; KING, G.. Java Persistence com HIBERNATE , Editora Ciência

Modena, 2007.

EMPRESA BRASILEIRA DE CORREIOS E TELÉGRAFOS. Manual de Tecnologia da Informação e Comunicação: Mod.3 Cap. 1, 2012, 4p. . ???? não está no texto

JACOBSON, I.; BOOCH, G.; RUMBAUGH J.. Unified Software Development

Process , Pearson Education, 1999.

LARMAN, C.. Utilizando UML e Padrões: Uma introdução à análise e ao projeto

orientado a objetos e ao desenvolvimento iterativo , 3ª Edição, Bookman, 2007.

LIMA, A.S. Aplicações em Visual Basic 6: Banco de Dados , 7ª Edição, Editora

Érica, 2005.

.

LOBO, E. J. R.. Guia Prático de Engenharia de Software , Digerati Books, 2009.

LUCKOW, D. H. ; MELO, Alexandre Altair de. Programação Java para Web ,

Novatec Editora, 2010. ???? não está no texto

MILLETO, E. M.; BERTAGNOLLI, S. C.. Desenvolvimento de Software II

Introdução ao Desenvolvimento Web com HTML, CSS, JA VASCRIPT e PHP,

Editora Bookman, 2014.

PRESSMAN, R. S.: Engenharia de Software – Uma Abordagem Profissional 7ª

Edição , AMGH Editora Ltda., 2011.

SEABRA, J. M. P.. UML – Unified Modeling Language: Uma Ferramenta Par a o

Design de Software , Editora Ciência Moderna, 2013.

sistema de administraÇÃo financeira condominial · antonio pereira de souza sistema de...

Documents