FACULDADES INTEGRADAS “CAMPOS SALLES”
SISTEMA DE ADMINISTRAÇÃO FINANCEIRA CONDOMINIAL
São Paulo 2014
ANTONIO PEREIRA DE SOUZA
SISTEMA DE ADMINISTRAÇÃO FINANCEIRA CONDOMINIAL
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
SISTEMA DE ADMINISTRAÇÃO FINANCEIRA CONDOMINIAL
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.
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
1. O ator seleciona a opção
“Alterar condomínio”.
2. Apresenta página para
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
(Include “Validar dados”).
8. Solicita autorização para
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”;
7.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
44
c. Seção “Excluir condomínio”
Ator Sistema Classe
1. O ator seleciona a opção
“Excluir condomínio”.
2. Apresenta página para
digitar o código do
condomínio.
3. Informa o código do
condomínio.
4. Obter dados do
condomínio.
CONDOMINIOS
5. Solicita autorização para
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
1. O caso de uso começa quando o ator
seleciona a opção “Categorias”.
a) Se for cadastrar, ver seção
“Cadastrar categorias”.
b) Se for alterar, ver seção “Alterar
categorias”.
c) Se for excluir, ver seção “Excluir
categorias” .
46
a. Seção “Cadastrar Categoria” Ator Sistema Classe
1. O ator seleciona a
opção “Cadastrar
categoria”.
2. Apresenta página para
receber os dados da
categoria.
3. Informa os dados da
categoria.
4. Validar os dados (Include
“Validar dados”).
6. Solicita autorização para
incluir no banco de 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
1. O ator seleciona a
opção “Alterar
categorias”.
2. Apresenta página para
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.
6. Validar os novos dados
(Include “Validar dados”).
7. Solicita autorização para
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”;
6.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
48
c. Seção “Excluir Categoria”
Ator Sistema Classe
1. O ator seleciona a
opção “Excluir
categoria”.
2. Apresenta página para
digitar o código da categoria.
3. Informa o código da
categoria.
4. Obter dados da categoria.
CATEGORIAS_ACESSO
5. Solicita autorização para
exclusão no banco de dados.
6. Autoriza exclusão no
banco de dados.
7. Exclui do banco de dados CATEGORIAS_ACESSO
Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”.
49
Caso de Uso: Manter Grupos
Visão Geral:
Este caso uso tem por objetivo permitir consultar, incluir, alterar e excluir o registro
de grupos de usuários 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 “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
“Validar dados”).
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
Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
51
b. Seção “Alterar Grupo”
Ator Sistema Classe
1. O ator seleciona a
opção “Alterar
grupos”.
2. Apresenta página para
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.
7. Validar os novos dados
(Include “Validar dados” ).
8. Solicita autorização para
alteração no banco de dados.
9. Autoriza alteração
no banco de dados.
10. Altera no banco de dados GRUPOS
Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”;
6.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
52
c. Seção “Excluir Grupo”
Ator Sistema Classe
1. O ator seleciona a opção
“Excluir grupo”.
2. Apresenta página para digitar
o código da categoria.
3. Informa o código do
grupo.
4. Obter dados do grupo.
GRUPOS
5. Solicita autorização para
exclusão no banco de dados.
6. Autoriza exclusão no
banco de dados.
7. Exclui do banco de dados GRUPOS
Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”.
53
Caso de Uso: Manter Usuários
Visão Geral:
Este caso uso tem por objetivo permitir consultar, incluir, alterar e excluir o registro
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
1. O caso de uso começa quando o ator
seleciona a opção “ Usuários” .
a) Se for cadastrar, ver seção “Cadastrar
usuários”.
b) Se for alterar, ver seção “Alterar
usuários”.
c) Se for excluir, ver seção “Excluir
usuários”.
54
a. Seção “Cadastrar Usuários”
Ator Sistema Classe
1. O ator seleciona a
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
“Validar dados”).
9. Solicita autorização para incluir no
banco de dados.
10. Autoriza inclusão no
banco de dados.
11. Inclui no banco de dados USUARIOS
Fluxo Alternativo:
5.1 O sistema apresenta a mensagem: “CPF inválido. Favor verificar”.
6.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
55
b. Seção “Alterar Usuário”
Ator Sistema Classe
1. O ator seleciona a
opção “Alterar
usuário”.
2. Apresenta página para
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
6. Listar condomínios CONDOMINIOS
7. Informa os novos
dados.
8. Validar os novos dados
(Include “Validar 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”;
6.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
56
c. Seção “Excluir Usuário”
Ator Sistema Classe
1. O ator seleciona a opção
“Excluir usuário”.
2. Apresenta página para digitar o
código do usuário.
3. Informa o código do
usuário.
4. Obter dados do usuário.
USUARIOS
5. Solicita autorização para exclusão
no banco de dados.
6. Autoriza exclusão no
banco de dados.
7. Exclui do banco de dados USUARIOS
Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”.
57
Caso de Uso: Manter Contas
Visão Geral:
Este caso uso tem por objetivo permitir consultar, incluir, alterar e excluir o registro
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
1. O caso de uso começa quando o ator
seleciona a opção “ Contas Condominiais”.
a) Se for cadastrar, ver seção “Cadastrar
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
1. O ator seleciona a opção
“Cadastrar contas”.
2. Apresenta página para
receber os dados de contas.
3. Listar condomínios CONDOMINIOS
4. Informa os dados de
contas.
5. Validar os dados (include
“Validar dados”).
6. Solicita autorização para
incluir no banco de dados.
7. Autoriza inclusão no banco
de dados.
8. Inclui no banco de dados CONTAS
Fluxo Alternativo: 5.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
59
b. Seção “Alterar Contas”
Ator Sistema Classe
1. O ator seleciona a
opção “Alterar conta” .
2. Apresenta página para digitar
o código da conta.
3. Informa o código da
conta.
4. Obter dados da conta.
CONTAS
6. Listar condomínios CONDOMINIOS
7. Informa os novos
dados.
8. Validar os novos dados
(Include “Validar 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 CONTAS
Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”;
6.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
60
c. Seção “Excluir Conta”
Ator Sistema Classe
1. O ator seleciona a opção
“Excluir conta” .
2. Apresenta página para digitar o
código da conta.
3. Informa o código da
conta.
4. Obter dados da conta.
CONTAS
5. Solicita autorização para
exclusão no banco de dados.
6. Autoriza exclusão no
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:
Este caso uso tem por objetivo permitir consultar, incluir, alterar e excluir o registro
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
1. O caso de uso começa quando o ator
seleciona a opção “Parecer”.
a) Se for cadastrar, ver seção “Cadastrar
parecer”.
b) Se for alterar, ver seção “Alterar
parecer”.
c) Se for excluir, ver seção “Excluir
parecer”.
62
a. Seção “Cadastrar Parecer”
Ator Sistema Classe
1. O ator seleciona a
opção “Cadastrar
parecer”.
2. Apresenta página para receber
os dados do parecer.
3. Listar condomínios CONDOMINIOS
4. Informa os dados de
parecer.
5. Validar os dados (include
“Validar dados”).
6. Solicita autorização para incluir
no banco de dados.
7. Autoriza inclusão no
banco de dados.
8. Inclui no banco de dados PARECER
Fluxo Alternativo: 5.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
63
b. Seção “Alterar Parecer”
Ator Sistema Classe
1. O ator seleciona a opção
“Alterar parecer”.
2. Apresenta página para
pesquisar parecer.
3. Informa os dados para
pesquisar parecer.
4. Obter dados do parecer.
PARECER
5. Listar condomínios CONDOMINIOS
6. Informa os novos dados.
7. Validar os novos dados
(Include “Validar dados”).
8. Solicita autorização para
alteração no banco de dados.
9. Autoriza alteração no
banco de dados.
10. Altera no banco de dados CONTAS
Fluxo Alternativo: 7.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). Favor verificar”.
64
c. Seção “Excluir Parecer”
Ator Sistema Classe
1. O ator seleciona a opção
“ Excluir parecer” .
2. Apresenta página para pesquisa
parecer
3. Informa os dados para
pesquisar parecer.
4. Obter dados do parecer.
PARECER
5. Solicita autorização para
exclusão no banco de dados.
6. Autoriza exclusão no
banco de dados.
7. Exclui do banco de dados PARECER
Fluxo Alternativo: 4.1 O sistema apresenta a mensagem: “Código não cadastrado. Favor verificar”.
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
1. O ator seleciona a opção
“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
1. O caso de uso começa quando o ator
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
1. O ator seleciona a opção
“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
1. O ator seleciona a
opção “Novo usuário”.
2. Apresenta página para receber
os dados do usuário.
3. Listar grupos GRUPOS
4. Listar condomínios CONDOMINIOS
5. Informa os dados.
6. Validar CPF (include “Validar
CPF”).
7. Validar os outros dados
(Include “Validar dados”).
8. Solicita autorização para incluir
no banco de dados.
9. Autoriza inclusão no
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”;
7.1 O sistema apresenta a mensagem: “Dado(s) inválido(s). 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
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
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
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
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
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
Os diagramas das figuras 3.5.12 , 3.5.13 e 3.5.14 representam as operações
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
86
Figura 3.5.13: Diagrama de sequência “Excluir Contas”
Fonte: Autor
Os diagramas das figuras 3.5.14 , 3.5.15 e 3.5.16 representam as operações
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
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
Campo Tipo de Dados Tamanho
codCategoria Numérico inteiro
nomeCategoria Caractere 50
descricao Caractere 150
dtCadastro Data/Hora -
Tabela : Grupos
Chave Primária :codGrupo
Chave(s) Estrangeira(s) : codCategoria
Campo Tipo de Dados Tamanho
codGrupo Numérico inteiro
codCategoria Numérico inteiro
nomeGrupo Caractere 50
descricao Caractere 100
dtCadastro Data/Hora -
99
Tabela : Usuarios
Chave Primária :codUsuario
Chave(s) Estrangeira(s) : codCond, codGrupo
Campo Tipo de Dados Tamanho
codUsuario Numérico inteiro
codCond 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
dtCadastro Data/Hora -
validado Numérico inteiro
100
Tabela : Contas
Chave Primária : id
Chave(s) Estrangeira(s) : codCond
Campo Tipo de Dados Tamanho
id Numérico Duplo
codCond Numérico inteiro
Mes Caractere 2
Ano Caractere 4
tp_lancamento Caractere 1
valor Numérico Decimal
nroNotaFiscal Caractere 10
descricao Caractere 200
documento Caractere 100
dtCadastro Data/Hora -
dtAtualizacao Data/Hora -
login Caractere 15
Tabela : Parecer
Chave Primária : id
Chave(s) Estrangeira(s) : codCond
Campo Tipo de Dados Tamanho
id Numérico inteiro
codCond Numérico inteiro
Mes Caractere 2
Ano Caractere 4
descricao Caractere 500
dtCadastro Data/Hora -
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.
Top Related