ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB
LATO SENSU EM ENGENHARIA DE SISTEMAS
RUTIMAR GONZAGA CHAVES MARTINS
MODELAGEM ORIENTADA A OBJETOS
Modelo de Classes
VITÓRIA – ES
2009
RUTIMAR GONZAGA CHAVES MARTINS
MODELAGEM ORIENTADA A OBJETOS
Modelo de Classes
Monografia apresentada à ESAB – Escola
Superior Aberta do Brasil, sob orientação
da Prof ª Beatriz Christo Gobbi.
VITÓRIA – ES
2009
RUTIMAR GONZAGA CHAVES MARTINS
MODELAGEM ORIENTADA A OBJETOS
Modelo de Classes
Aprovada em .........de ...................de 2009
__________________________________________
__________________________________________
__________________________________________
VITÓRIA – ES
2009
À DEUS por permitir mais esta realização...
À meu marido por estar ao meu lado como
colega de curso, incentivando e motivando.
AGRADECIMENTOS
Aos colegas da Empresa onde trabalho por suas
contribuições com idéias e opiniões ao conteúdo
deste estudo.
“As grandes idéias são aquelas nas quais a única
coisa que nos surpreende é que não nos tivessem
ocorrido antes.”
(Noel Clarasó, escritor espanhol)
RESUMO
O estudo teve como objetivo descrever os conceitos básicos da orientação a objetos
aplicados na fase de modelagem, especificamente com foco no modelo de classes.
Para tal, foram realizadas pesquisas exploratórias através de livros, sites da internet
e trabalhos científicos sobre a modelagem orientada a objetos e sua aplicabilidade
na definição de modelos do problema. Com a finalidade de apresentar de forma
prática a utilização da modelagem orientada a objetos, optou-se por realizar o
estudo de caso “Alerta cadastral na Concessão de Crédito”, onde são descritos,
passo a passo, os procedimentos necessários para o surgimento e o progresso do
modelo de classes. Com o desenrolar da pesquisa, pode-se identificar as principais
vantagens da utilização da metodologia orientada a objetos, tais como a
estruturação da informação de uma forma lógica e um melhor gerenciamento da
complexidade.
LISTA DE FIGURAS
Figura 1 – Classe Concreta.......................................................................................27
Figura 2 - Classe Abstrata.........................................................................................27
Figura 3 - Relacionamento entre classes ..................................................................27
Figura 4 – Associação entre classes.........................................................................30
Figura 5 - Classe de Associação...............................................................................30
Figura 6 - Multiplicidade um ou mais (1..*) ................................................................31
Figura 7 - Representação gráfica para Generalização..............................................32
Figura 8 - Exemplo de Generalização entre classes .................................................32
Figura 9 - Herança entre classes ..............................................................................34
Figura 10 – Relacionamento entre classes - Agregação ...........................................35
Figura 11 - Relacionamento entre classes – Composição ........................................36
Figura 12 -Composição e Associação.......................................................................36
Figura 13 - Fluxo do processo de Alerta Cadastral ...................................................40
Figura 14 – Classes do sistema ................................................................................48
Figura 15 - Relacionamento entre Proponente e Proposta de negócio.....................49
Figura 16 - Relacionamento entre Proposta de negócio e verificação ......................49
Figura 17 - Diagrama de Classes (Estruturas e Relacionamentos)...........................51
Figura 18 - Atributos de Proponente e Proposta de negócio.....................................52
Figura 19 - Diagrama de Classes - atributos .............................................................53
Figura 20 - Diagrama de Classes (métodos).............................................................54
Figura 21 - Novos objetos do relacionamento: Proposta de negócio e Verificação...55
Figura 22 - Novo objeto da generalização de Proponente e Cliente .........................56
Figura 23 - Diagrama de Classes (completo) ............................................................57
LISTA DE SIGLAS
OO
Orientação a Objetos
IF
Instituições Financeiras
UML
Unified Modeling Language
BDC
Base de dados de clientes
OMG
Object Management Group
OMT
Object ModelingTechnology
OOSE
Oriented Software Engineering
SUMÁRIO
INTRODUÇÃO ..................................................................................... 12
I
CONCEITOS BÁSICOS DA ORIENTAÇÃO A OBJETOS ............. 15
I.1
ABSTRAÇÃO ............................................................................ 15
I.2
OBJETOS E CLASSES............................................................. 16
I.2.1 Classes................................................................................... 18
I.2.2 Atributos ................................................................................. 20
I.2.3 Métodos.................................................................................. 21
I.2.4 Hierarquia............................................................................... 22
I.3
ENCAPSULAMENTO................................................................ 22
I.4
UML - Unified Modeling Language ............................................ 24
I.5
DIAGRAMA DE CLASSES ........................................................ 25
I.6
RELACIONAMENTO ENTRE CLASSES .................................. 28
I.6.1 Associação ............................................................................. 29
I.6.2 Multiplicidade.......................................................................... 30
I.6.3 Generalização/especialização e Herança .............................. 31
I.6.4 Agregação .............................................................................. 34
I.6.5 Composição............................................................................ 35
II
O “ALERTA CADASTRAL NA CONCESSÃO DE CRÉDITO” ...... 37
II.1 CONSIDERAÇÕES INICIAIS .................................................... 37
II.2 OBJETIVOS .............................................................................. 39
II.3 REQUISITOS ............................................................................ 39
II.3.1 Proposta de negócio ............................................................ 41
II.3.2 Fontes internas .................................................................... 42
II.3.3 Verificação de dados ........................................................... 42
II.3.4 Alerta de fraude ................................................................... 44
II.4 PREMISSAS ............................................................................. 44
II.5 FUNCIONALIDADES ................................................................ 45
III DESENVOLVIMENTO DO MODELO DE CLASSES ...................... 46
III.1 IDENTIFICAR AS CLASSES E OS OBJETOS.......................... 47
III.2 IDENTIFICAR AS ESTRUTURAS E OS RELACIONAMENTOS 49
III.3 IDENTIFICAR OS ATRIBUTOS IMPORTANTES ...................... 52
III.4 IDENTIFICAR MÉTODOS ......................................................... 53
III.5 NOVOS OBJETOS.................................................................... 54
III.6 O MODELO COMPLETO .......................................................... 57
REFERÊNCIAS BIBLIOGRÁFICAS .................................................... 60
12
INTRODUÇÃO
Palavras chave: Modelagem orientada a objetos, Modelo de classes, Diagrama de
Classes.
A característica cada vez mais complexa da construção de sistemas de informação
vem requerendo a utilização de metodologias capazes de estruturar a informação de
uma forma lógica, permitindo um mapeamento direto da semântica do domínio do
problema para o modelo a ser desenvolvido. Sistemas de alta complexidade pedem
por ferramentas de desenvolvimento drasticamente diferentes de 20 anos atrás. Os
principais objetivos que se tem buscado são um melhor gerenciamento da
complexidade, melhor qualidade, desenvolvimento mais rápido e facilidade de
manutenção, adaptação e ampliação. A metodologia que tem se firmado no mercado
e tem demonstrado atender às necessidades almejadas, é a orientação a objetos
(OO).
Orientação a objetos é um termo que descreve uma série de técnicas para estruturar
soluções para problemas computacionais. A OO, de maneira simples, é uma
abordagem para o desenvolvimento de sistemas, que traduz o problema no mundo
real como um conjunto de objetos, possuindo princípios e conceitos específicos bem
diferentes das tradicionais metodologias. Estes princípios e conceitos são capazes
de subsidiar todo o processo de desenvolvimento da aplicação, desde a concepção,
a análise, até a implementação.
Existe
uma
tendência
para
o
desenvolvimento
de
sistemas
focados
na
implementação, no entanto vêm-se constatando as recompensas com o tempo gasto
com a fase de modelagem, como também a importância dos modelos para
representação do problema. Os modelos são considerados abstrações elaboradas
para entender o problema, antes de implementar uma solução. A representação do
problema em modelos orientados a objetos permite uma compreensão mais clara do
mesmo, e é muito útil para comunicação com os especialistas da aplicação e
13
desenvolvedores, sendo o modelo de classes considerado o principal modelo a ser
desenvolvido. Este trabalho apresenta um estudo de caso sobre o problema do
“Alerta cadastral na concessão de crédito”, descrito no capítulo II. Onde foi
considerado como adequado para sua a modelagem a utilização da metodologia
orientada a objetos.
O “Alerta cadastral na concessão de crédito” foi escolhido como estudo de caso por
se tratar de um problema real apresentado na empresa onde trabalho. A
necessidade de obter uma aplicação de melhor qualidade foi o que motivou a busca
dos conhecimentos da orientação a objeto e ao desenvolvimento deste trabalho.
Objetivando apresentar de forma prática a utilização da modelagem sobre a visão de
objetos e com isso demonstrando a importância desta abordagem. Especificamente
descreve-se o processo de desenvolvimento de um modelo de classes, não se
preocupando em citar os outros modelos que compõe a abordagem OO.
No capítulo I são apresentados os principais conceitos da orientação a objetos
relacionados à fase de modelagem de classes. É utilizada como linguagem de
notação gráfica a UML (Unified Modeling Language), que é considerada uma
padronização dos métodos de desenvolvimento de sistemas baseados na orientação
a objetos. A UML incorpora as noções do desenvolvimento de software totalmente
visual.
Após apresentação dos conceitos da orientação a objetos, é descrito no capítulo II o
contexto, requisitos e funcionalidades do problema do “Alerta cadastral na
concessão de crédito”. No terceiro e último capítulo descreve-se o desenvolvimento
do modelo de classes.
Para desenvolvimento do estudo foi utilizada a metodologia de pesquisa exploratória
através de livros, sites da internet e trabalhos científicos relacionados ao tema
“modelagem orientada a objetos”. E para embasamento sobre o problema do “Alerta
cadastral na concessão de crédito” foram utilizadas informações adquiridas em
reuniões e entrevistas com os analistas da IF (Instituição Financeira), assim como
14
documentos preparados pelos mesmos com informações sobre o contexto do
problema.
15
I
CONCEITOS BÁSICOS DA ORIENTAÇÃO A OBJETOS
Segundo Blaha e Rumbaugh (2006), um modelo de classes representa a estrutura
estática de um sistema, pois caracteriza os objetos no sistema, os relacionamentos
entre eles, os atributos e as operações para cada classe dos objetos. O modelo de
classe é representado graficamente de uma forma intuitiva, sendo de extrema
importância para comunicação com os usuários solicitantes do sistema.
Encontramos nomenclaturas e definições diferenciadas em cada autor estudado,
portanto o que será apresentado é que foi considerado de mais importante para o
trabalho em questão.
Nas seções seguintes será descrito cada um dos conceitos da orientação a objeto.
Os
conceitos
abordados
serão
os
especificamente
necessários
para
o
desenvolvimento de um modelo de classes OO.
I.1
ABSTRAÇÃO
A abstração baseia-se em voltar a atenção às questões essenciais inerentes a
determinada problemática e ignorar propriedades “acidentais.'' Em se tratando de
desenvolvimento de sistemas, isto significa concentrar-se no que um elemento do
projeto é e faz antes de se decidir como ele será implementado. O uso de abstração
permite a liberdade para tomar decisões de desenvolvimento ou de implementação
apenas quando há um melhor entendimento do problema a ser resolvido. O uso
apropriado de abstração permite que um mesmo modelo conceitual desenvolvido
utilizando o paradigma da orientação a objetos seja utilizado para todas as fases de
desenvolvimento de um sistema, desde sua análise até sua documentação
(RICARTE, 2001).
16
Portanto, no processo de abstração, devem-se ignorar os detalhes, para concentrarse nas características indispensáveis. Ignorar aspectos não relevantes é a
capacidade de focalizar o essencial e ignorar pequenas questões não relacionadas
com o objetivo estabelecido, portanto ajuda lidar com a complexidade. A abstração
nos leva a representar o problema de acordo com o ponto de vista e interesse de
quem os representa.
Na verificação de uma casa, um observador externo, pode descrevê-la identificando
a cor da mesma, o número de portas e janelas e o tipo do telhado. Quando
identificamos a casa apenas a partir destas características externas estamos
fazendo um exercício de abstração, pois uma série de detalhes internos não está
sendo descrita.
Outra exemplificação seria ao analisarmos um avião no contexto de um sistema de
marcação de passagens aéreas, não vai nos interessar a característica “número de
turbinas do avião”, mas irá nos interessar a característica “número de assentos
disponíveis”. Ao ignorarmos algumas características não relevantes em um
determinado contexto, estamos fazendo uma abstração.
I.2
OBJETOS E CLASSES
Na abordagem OO, elementos de um determinado contexto, como os citados no
conceito de abstração na seção anterior, tais como um avião ou uma casa, podem
ser entendidos como um objeto.
Conforme Castro (2009), objeto pode ser físico, como uma cadeira, uma mesa, um
cachorro. Contudo um objeto pode também ser uma “algo” que não existe em forma
física: uma fórmula matemática, saldo bancário. É tudo que pode ser nomeado e que
possui características, atributos e comportamento próprios. Exemplos: cheque,
janela, campo de texto, gráfico, linha, círculo, forma(s), lista, pilha, fila, matriz, tabela,
filtros, função-geradora, gerador aleatório, caixa de cereal, fábrica, lista de compras,
17
calendário, data, dia, cor, compromisso, empregado, departamento, registro pessoal,
botão.
A partir dessas definições, é possível concluir que objetos computacionais são
considerados estruturas que contém as informações e os comportamentos que
representam um objeto dentro do sistema. Objetos que se encontram dentro dos
sistemas de computador são abstrações do mundo real.
Outros Exemplos:
•
Funções: Diretor, Funcionário, Professor, Cliente;
•
Eventos: uma Festa, um Congresso, uma Aula;
•
Lugares: uma Cidade, uma Sala, um País;
•
Processos: uma Operação, um Procedimento.
Portanto, um objeto é qualquer conceito que seja aplicável ao problema: pessoa,
lugar, evento, coisa, tela, relatório. São elementos reais ou abstratos (de
pensamento) que sofrem ou executam ações. É uma entidade capaz de reter um
estado (informação) e que oferece uma séria de operações (comportamentos) ou
para examinar ou para afetar este estado.
•
Apresenta características (Estado).
•
Executa e sofre ações (Comportamento).
•
Podem ser classificados por categorias ou classes.
•
Interagem e agrupam-se formando sistemas que podem ser considerados
como objetos.
Não existe uma maneira correta de decompor um problema em objetos; esta
decomposição depende do julgamento do projetista e da natureza do problema.
Todos os objetos têm identidade própria e são distinguíveis, possuindo dois
propósitos principais: promover o entendimento do mundo real e suportar uma base
prática para uma implementação computacional.
18
I.2.1 Classes
Segundo Blaha e Rumbaugh (2006), classe é uma abstração que descreve
propriedades e comportamentos partilhados por um grupo de objetos. Todo objeto
será definido como componente de alguma classe. São agrupamentos de objetos
(computacionais) que têm propriedades em comum e podem realizar as mesmas
ações. Naturalmente, este agrupamento deve refletir a classificação natural dos
objetos reais. Uma INSTÂNCIA de uma classe é uma ocorrência individual de um
objeto.
Uma classe de objetos descreve um grupo de objetos com propriedades e
comportamentos similares, relacionamentos comuns com outros objetos e uma
semântica comum. Por exemplo, Pessoa e Companhia são classes de objetos. Cada
pessoa tem um nome e uma idade; estes seriam os atributos comuns da classe.
Companhias também podem ter as mesmas propriedades (nome e idade) definidas.
Entretanto, devido à distinção semântica elas provavelmente estariam agrupadas em
outra classe que não Pessoa. Como se pode observar, o agrupamento em classes
não leva em conta apenas o compartilhamento de propriedades (CASTRO, 2009).
A Wikipédia (2009) define classe como:
Uma classe é uma estrutura que abstrai um conjunto de objetos com
características similares. Uma classe define o comportamento de seus
objetos através de métodos e os estados possíveis destes objetos através
de atributos. Em outros termos, uma classe descreve os serviços providos
por
seus objetos e quais informações eles podem armazenar. Classes
não são diretamente suportadas em todas as linguagens, e são necessárias
para que uma linguagem seja orientada a objetos. Classes são os
elementos primordiais de um Diagrama de Classes.
Pode-se entender então que uma classe é uma abstração que enfatiza
características relevantes e abstrai outras características. Uma classe deveria
capturar uma e somente uma abstração chave.
•
Abstração ruim: classe "Aluno" que conhece a informação do aluno e as
disciplinas que aquele aluno está matriculado.
19
•
Boa abstração: separar em uma classe para Aluno e uma classe para
Disciplina.
Nomeando Classes:
- Uma classe deveria ser um substantivo singular que melhor caracteriza a
abstração;
- Dificuldades na nomeação das classes podem indicar abstrações mal definidas;
- Nomes deveriam surgir diretamente do domínio do problema.
I.2.1.1 Classes abstratas e concretas
A classe abstrata é uma classe que não possui objetos criados a partir dela,
enquanto a classe concreta possui objetos criados (instanciados) a partir dela
(MACORATTI, 2009).
Exemplo: No mundo real, existem automóveis e aviões, mas nada que seja
simplesmente um veículo (em outras palavras, se não for um carro ou avião, não é
de nosso interesse). Isso significa que podemos instanciar objetos como carros e
aviões, mas nunca iremos criar objetos veículos. As classes abstratas são criadas
quando necessitamos de uma classe que implemente recursos comuns a duas ou
mais classes.
Uma classe abstrata é utilizada para representar entidades e conceitos abstratos. A
classe abstrata é sempre uma superclasse que não possui instâncias (objetos
criados). Ela define um modelo para uma funcionalidade e fornece uma
implementação incompleta - a parte genérica dessa funcionalidade - que é
compartilhada por um grupo de classes derivadas. Cada uma das classes derivadas
completa a funcionalidade da classe abstrata adicionando um comportamento
específico (BLAHA E RUMBAUGH, 2006).
20
Uma classe abstrata normalmente possui comportamentos abstratos. Esses
comportamentos (serviços) são implementados nas suas classes derivadas
concretas com o objetivo de definir o comportamento específico.
Por outro lado, as classes concretas implementam todos os seus serviços e
permitem a criação de instâncias. Uma classe concreta não possui comportamentos
abstratos e, geralmente, quando utilizadas neste contexto, são classes derivadas de
uma classe abstrata.
I.2.2 Atributos
Os atributos, também chamados de campos, indicam as possíveis informações
armazenadas por um objeto de uma classe, representando o estado de cada objeto.
Ricarte (2001) define um atributo como um valor de dado assumido pelos objetos de
uma classe. Nome, idade e peso são exemplos de atributos de objetos Pessoa. Cor,
peso e modelo são possíveis atributos de objetos Carro. Cada atributo tem um valor
para cada instância de objeto. Por exemplo, o atributo altura tem valor “1,80” no
objeto Marcelo. Em outras palavras, Marcelo tem “1,80m” de altura. Diferentes
instâncias de objetos podem ter o mesmo valor para um dado atributo.
Objetos computacionais são caracterizados por atributos ou propriedades. Portanto,
atributo é o conjunto de características que compõe objetos de uma classe.
•
Atributos de um Cliente: nome, CPF, data de nascimento, estado civil, sexo;
•
Atributos de uma conta corrente: correntista, saldo, data de abertura;
Cada nome de atributo é único para uma dada classe, mas não necessariamente
único entre todas as classes. Por exemplo, ambos Pessoa e Companhia podem ter
um atributo chamado telefone.
21
O estado de um objeto é dado por valores de atributos e por ligações que tem com
outros objetos. Todos os objetos de uma classe são caracterizados pelos mesmos
atributos, ou variáveis de instâncias. O mesmo atributo pode ter valores diferentes
de objeto para objeto (CASTRO, 2009).
Atributos são definidos ao nível da classe, enquanto que os valores dos atributos
dos atributos são definidos ao nível do objeto. Exemplos:
•
Uma pessoa (classe) tem os atributos nome, idade e estado civil;
•
Márcia é uma pessoa (objeto da classe pessoa) com nome "Márcia Morais",
idade 34 anos e estado civil casada.
I.2.3 Métodos
Métodos podem ser chamados também de operações, funções ou serviços. “O
comportamento invocável de objetos são os métodos. Um método é algo que se
pode pedir para um objeto de uma classe fazer” (CASTRO, 2009). Portanto,
métodos são determinados ao nível de classe. Enquanto que ao nível de objeto
temos a invocação de uma operação. Objetos de uma mesma classe têm os
mesmos métodos.
Já que o método tem um sentido subentendido de ação, este pode ser comparado a
uma função definida por uma linguagem de programação estruturada. Ou seja,
método representa um conjunto de instruções que são executadas quando
determinado serviço é invocado a partir da instância da classe (objeto).
Em outras palavras, métodos definem as habilidades dos objetos. Totó é uma
instância da classe Cachorro, portanto tem habilidade para latir, implementada
através do método de UmLatido(). Um método em uma classe é apenas uma
definição. A ação só ocorre quando o método é invocado através do objeto, no caso
Totó.
22
I.2.4 Hierarquia
Dentre as várias fontes pesquisadas, encontrou-se a definição de hierarquia de
classes. Correia e Tafner (2006) dizem que quando vamos trabalhar com um grande
conjunto
de
classes
de
objetos,
torna-se
interessante
identificar
classes
hierarquicamente relacionadas. É necessário organizar estas classes de maneira
ordenada de modo que tenhamos uma hierarquia. Em uma hierarquia de classes
teremos as classes mais genéricas no topo, e as mais específicas na base.
Na classe automóvel, como classe mais genérica, existe a seguinte possibilidade de
classes hierarquicamente interligadas:
•
Utilitário (camionetes leves): - utilitário urbano; - utilitário off-road.
•
Passeio: - passeio família; - passeio esportivo.
•
Carga: - carga inflamável; - carga com frigorífico.
Já na classe dos mamíferos, como exemplo, pode-se representar a seguinte
hierarquia:
•
Primata: - ser humano; - chipanzé.
•
Felino: - gato; - leão; - onça.
I.3
ENCAPSULAMENTO
O conceito de encapsulamento está estritamente relacionado ao conceito de
abstração e método. Num dado objeto somente interessa ao usuário as funções que
ele executa e não como estas funções estão implementadas internamente. Ou seja,
o usuário tem acesso sempre a descrição das operações que o objeto executa, a
implementação de tais operações fica encapsulada e só é visível ao próprio objeto.
23
Para exemplificar, podemos pensar em uma dona de casa (usuário) utilizando um
liquidificador
(sistema).
O
usuário
não
necessita
conhecer
detalhes
do
funcionamento interno do sistema para poder utilizá-lo, precisa apenas conhecer a
interface, no caso, os botões que controlam o liquidificador (WIKIPÉDIA, 2009).
A palavra encapsular (ocultar) é mais um termo técnico dentro dos conceitos OO e é
bastante aplicado em linguagens orientadas a objeto. Outro exemplo de
encapsulamento seria um disco rígido. A interface do disco rígido deixa acessível ao
computador suas funções de leitura e escrita, os dispositivos mecânicos e
eletromagnéticos que o HD utiliza para realizar tais operações não ficam acessíveis
ao seu usuário, estando assim encapsulados.
Desta forma, todos os dados e operações necessários para a existência de um
objeto e para realização das funções especificadas para o sistema devem estar
armazenados no próprio objeto. É possível dizer que o comportamento e os dados
estão encapsulados no objeto, ou seja, dados do objeto e funções não se encontram
mais isolados, ao contrário, caminham juntos.
Segundo Deboni (2003), o princípio do encapsulamento dá uma idéia de
independência por parte do objeto, pois o mesmo passa a ter todos os dados e as
funções necessários para sua existência. Da mesma forma, o encapsulamento
protege os dados de um objeto do acesso descontrolado por outros objetos. O
acesso é realizado por intermédio de mensagens trocadas entre objetos. Tais
mensagens correspondem às chamadas das funções, ou métodos, dos objetos.
Somente a interface do objeto, constituída pelas funções nele definidas, é exposta
de forma que ele possa ser acessível pelo mundo exterior. Os dados dos objetos são
protegidos já que as mensagens passam por uma função do objeto antes de acessar
os dados, controlando, assim, a forma de acesso.
As informações do objeto e a forma de implementação dos serviços internos são
mantidos ocultos. Este conceito é conhecido como ocultação de informações e é
outra decorrência importante do encapsulamento de dados.
24
O encapsulamento implica em outra característica própria da orientação a objeto,
que é a colaboração entre os objetos pela troca de mensagens. A integração dos
dois componentes ocorre interligando a saída de um objeto com a entrada do outro.
Dessa forma, um objeto pode acionar as funções do outro objeto.
O encapsulamento também permite e facilita a reutilização, o que representa uma
grande vantagem, pois provoca redução no custo do desenvolvimento de novos
sistemas, além de facilitar na manutenção, que é simplificada, e na expansão que
passa a ter maior controle.
A orientação a objeto permite a separação entre o ato da criação do objeto e a
integração do mesmo no sistema. Sendo assim, um objeto bem projetado, testado e
confiável pode ser utilizado em diversas situações, diluindo seu custo em diversos
sistemas.
Para que um encapsulamento seja eficiente, a interface dos objetos deve ser
definida com precisão. A interface é a lista dos serviços que o objeto oferece. Porém
a forma como tais serviços são implementados é ocultada. Muitas interfaces já estão
padronizadas e existe grande esforço geral no sentido desta padronização, pois ela
torna mais fácil e simplificado o acesso aos objetos.
I.4
UML - Unified Modeling Language
Com o surgimento dos conceitos OO, e da diversidade com se apresentavam por
cada autor, Grady Booch, James Rumbaugh e Ivar Jacobson (os famosos três
amigos) decidiram criar uma Linguagem de Modelagem Unificada. Como
mencionado por Guedes (2004), eles deixaram disponíveis inúmeras versões
preliminares da UML para a comunidade de desenvolvedores e as respostas
acrescentaram novas idéias, as quais melhoraram ainda mais a linguagem.
25
A UML surgiu da junção de três metodologistas de modelagem: o método Booch, o
método OMT de Jacobson e o método OOSE de Rumbaugh. Até meados da década
de 1990 estas eram as três metodologias de modelagem orientada a objetos mais
populares entre os profissionais da área de desenvolvimento de software (GUEDES,
2004).
A junção dessas metodologias teve vasto apoio da Rational Software, que, por sua
vez incentivou e financiou a união das três metodologias. Inicialmente, o projeto
constou da união do método de Booch com o método do OMT de Jacobson
resultando no lançamento do Método Unificado no fim de 1995. Em seguida,
Rumbaugh juntou-se a Booch e Jacobson na Rational Software incorporando seu
método OOSE à nova metodologia. O trabalho de Booch, Jacobson e Rumbaugh,
conhecidos popularmente como “Os três amigos”, resultou em 1996 no lançamento
da primeira versão da UML propriamente dita (GUEDES, 2004).
Inúmeras
grandes
empresas
com
atividades
na
área
de
modelagem
e
desenvolvimento de software passaram a contribuir com o projeto, dando sugestões
a fim de melhorar e ampliar a linguagem. Por fim, a UML foi adotada pela OMG
(Object Management Group) em 1997, tornando-se uma linguagem padrão de
modelagem. Até a pouco tempo, a UML estava na versão 1.5 e, recentemente, foi
substituída pela versão 2.0.
A UML é composta por diversos diagramas que fornecem múltiplas visões do
sistema a ser modelado, sob diversos aspectos e de forma complementar, sendo o
Diagrama de Classes um destes diagramas. Será alvo deste trabalho apenas o
Diagrama de Classes, descrito na seção seguinte.
I.5
DIAGRAMA DE CLASSES
Conforme Guedes (2004), as classes são matrizes de objetos e descrevem um
conceito abstrato do domínio do problema enquanto um objeto representa um
elemento desse conceito, que é utilizado no sistema, de forma concreta. Ao criar um
26
objeto baseado em uma classe, ele assume valores para os atributos, definindo um
estado e herdando um comportamento das classes que permite alterar esse estado.
Os estados e os comportamentos são compartilhados por todos os objetos da
mesma classe e são definidos na fase de análise.
O objetivo de um Diagrama de Classes é descrever os vários tipos de objetos no
sistema e o relacionamento entre eles.
Um Diagrama de Classes pode oferecer três perspectivas, cada uma para um tipo
de observador diferente. São elas:
•
•
Conceitual a)
Representa os conceitos do domínio em estudo.
b)
Perspectiva destinada ao cliente.
Especificação a)
Tem foco nas principais interfaces da arquitetura, nos principais
métodos, e não como eles irão ser implementados.
b)
Perspectiva destinada as pessoas que não precisam saber detalhes de
desenvolvimento, tais como gerentes de projeto.
•
Implementação - a mais utilizada de todas
a)
Aborda vários detalhes de implementação, tais como navegabilidade,
tipo dos atributos, etc.
b)
Perspectiva destinada ao time de desenvolvimento.
Segundo Guedes (2004), o Diagrama de Classes define a estrutura das classes
utilizadas pelo sistema, determinando os atributos e os métodos possuídos por cada
classe, além de estabelecer como as classes se relacionam, complementam e
transmitem informações entre si. Também serve de base para a maioria dos outros
tipos de diagramas.
27
O Diagrama de Classes contém, essencialmente, classes e relacionamentos.
•
Classe – representada na forma de um retângulo, contendo duas linhas que
separam três partes. A primeira contém o nome da classe, a segunda os
atributos da classe e a última os métodos da mesma. Representação gráfica:
Figura 1 – Classe Concreta
Figura 2 - Classe Abstrata
A representação de uma classe abstrata em UML é quase igual à representação de
uma classe concreta, a única diferença é o estilo da fonte do nome da classe, que,
neste caso, está em itálico.
•
Relacionamentos
Figura 3 - Relacionamento entre classes
28
I.6
RELACIONAMENTO ENTRE CLASSES
Normalmente as classes não estão sós e se relacionam entre si. Os objetos têm
relações entre eles: um professor ministra uma disciplina para alunos numa sala, um
cliente faz uma reserva de alguns lugares para uma data, etc. Essas relações são
representadas também no diagrama de classe (MACORATTI, 2009).
De acordo com Guedes (2004), os relacionamentos entre as classes podem ser
definidos como:
• Dependência
• Associação
• Agregação
• Herança
A dependência é considerada o relacionamento mais fraco entre duas classes. É
representada por uma seta tracejada ligando as classes e partindo da classe
dependente para a classe independente. A dependência serve para indicar que
essas classes devem participar juntas do sistema, mas não indica como ocorre essa
dependência.
As associações surgem quando há um nível maior de envolvimento, e bem mais
definido que na dependência entre as classes. Na associação, as classes estão
ligadas semanticamente umas às outras, ou seja, as classes são independentes,
mas guardam algum tipo de significado na sua relação. Essa relação permite a troca
de mensagens entre as classes na ajuda para o cumprimento de suas
responsabilidades. A representação da associação é uma linha que interliga as
classes, onde a linha pode possuir uma seta indicando a direção da associação
(GUEDES, 2004).
Alguns tipos de associação podem exigir um aumento no grau de envolvimento entre
as classes, o que cria a agregação. A agregação é equivalente à associação, mas
29
indica que as classes possuem uma dependência existencial, ou seja, uma classe só
existe em conjunto com suas agregadas. A classe todo é composta pela(s) classe(s)
parte(s). A agregação é representada por uma seta unindo as classes com um
losango indicando a classe todo.
Pode-se considerar a agregação como um caso especial da associação devido ao
maior vínculo entre as classes. O vínculo pode existir de tal forma que se a classe
todo deixar de existir, as classes partes deixam de ser relevantes para o sistema. Na
associação, as classes se mantêm independentes, isto é, elas podem participar de
outras associações no projeto que não exista essa dependência e podem ser
instanciadas isoladamente.
A herança caracteriza-se por criar uma hierarquia entre as classes do sistema.
Nessa hierarquia, as superclasses servem de matrizes para a criação de outras
classes, as subclasses, que especializam as superclasses originais. Ao se
especificarem, as subclasses aproveitam tudo das superclasses, o que inclui
atributos, operações e relacionamentos da classe mãe, mas podem modificar o
material herdado, sobrescrevendo os atributos e as operações ou criando novos
atributos e operações.
I.6.1 Associação
Associações são formas para estabelecer relacionamentos entre objetos e classes.
Uma associação representa o fato de que objetos podem se relacionar uns com os
outros. Por exemplo, Pedro trabalha-para um Companhia. Uma associação descreve
um grupo de ligações com estrutura e semântica comuns, tal como ``uma pessoa
trabalha-para uma companhia.'' Uma associação descreve um conjunto de ligações
potenciais da mesma forma que uma classe descreve um conjunto de objetos
potenciais (PIRES, 2002).
A notação de diagramas UML para associação é uma linha conectando duas
classes. Se entre um par de classes só existe uma única associação cujo sentido
deva ser óbvio, então o sentido da associação pode ser omitido.
30
Figura 4 – Associação entre classes
Quando uma associação possui propriedades importantes que necessitam estar
representadas surge o conceito de Classe de Associação. A figura 5 apresenta o
relacionamento entre as classes Empregado, Empresa e a classe Trabalho
resultante da associação.
Figura 5 - Classe de Associação
I.6.2 Multiplicidade
No relacionamento entre classes torna-se necessário adicionar mais informação na
busca de uma completa comunicação. A multiplicidade é a especificação do número
de elementos de uma classe que podem de relacionar a único elemento de uma
classe associada. A multiplicidade delimita o número de objetos relacionados.
(BLAHA E RUMBAUGH, 2006)
A linguagem UML admite os seguintes indicadores de multiplicidade:
Indicador
Multiplicidade
0..1
zero ou um
1
um
31
0..* ou apenas *
zero ou mais
1..*
um ou mais
n..*
n ou mais (com n > 1)
n
apenas n (com n >1)
0..n
zero a n (com n >1)
1..n
um a n (com n >1)
n..m
n a m (com n >1, m >1 e n <m)
As letras n e m representam números inteiros. Por exemplo, 1..n significa que são
permitidas todas as seguintes especificações: 1..1, 1..2, 1..3, etc.. Note que 1..1 é
igual a 1 e que o valor após o .. tem de ser maior ou igual do que está antes de ...
Por exemplo, 3..2 não é permitido.
A figura 6 ilustra a multiplicidade um ou mais (1..*). Em uma clínica média onde
existem médicos de várias especialidades, um paciente pode ser tratado por um ou
vários médico(s), assim como um médico poder cuidar de um ou vários paciente(s).
Figura 6 - Multiplicidade um ou mais (1..*)
I.6.3 Generalização/especialização e Herança
Quando organizamos classes em hierarquias automaticamente é possível empregar
os conceitos de generalização, especialização e herança. Estes três conceitos são
abstrações poderosas para compartilhar similaridades entre classes e ao mesmo
tempo preservar suas diferenças. Generalização, especialização e herança referemse a características de uma mesma idéia (BLAHA E RUMBAUGH, 2006).
32
Segundo Castro (2009), em uma hierarquia de classes semelhantes podemos dizer
que as classes mais específicas herdam as características das mais genéricas, ou
seja, todo Mamífero é um Ser vivo. A classe de nível superior na associação de
herança é chamada de super-classe e a inferior de sub-classe. Portanto Mamífero é
uma sub-classe de Ser vivo.
Generalização/especialização é o relacionamento entre uma classe e um ou mais
especialidades desta classe. A classe sendo refinada é chamada de superclasse ou
classe base, enquanto que a versão refinada da classe é chamada uma subclasse
ou classe derivada.
Representação gráfica:
Figura 7 - Representação gráfica para Generalização
A figura 8 ilustra a generalização entre as classes Cheque, Cartão e Dinheiro através
da classe Pagamento.
Figura 8 - Exemplo de Generalização entre classes
33
Uma classe derivada pode sobrepor uma característica de sua classe base definindo
uma característica própria com o mesmo nome. A característica local (da classe
derivada) irá refinar e substituir a característica da classe base. Uma característica
pode ser sobreposta, por exemplo, por questões de refinamento de especificação ou
por questões de desempenho.
Herança é um mecanismo que permite que características comuns a diversas
classes sejam agrupadas em uma classe base, ou superclasse. A partir de uma
classe base, outras classes podem ser especificadas. Cada classe derivada ou
subclasse apresenta as características (estrutura e métodos) da classe base e
acrescenta a elas o que for definido de particularidade para ela.
Blaha e Rumbaugh (2006) explicam que a herança é identificada quando existe o
relacionamento “é um” entre as classes. Por exemplo, no caso de termos a classe
Pessoa e a classe Cliente, podemos dizer que Cliente é uma Pessoa. Assim
identificamos que Cliente é subclasse de Pessoa, herdando todas as características
de Pessoa e que Pessoa é superclasse de cliente.
Quando uma classe (subclasse) herda características de uma única classe
(superclasse)
dizemos
que
ocorre
uma
herança
simples.
Quando
herda
características de mais de uma classe dizemos que ocorre uma herança múltipla.
A figura 8 apresenta um exemplo de Herança envolvendo as classes Meio de
Transporte, Carro, Carro Esporte e Navio.
Atributos e operações comuns ao grupo de classes derivadas (Carro, Carro Esporte
e Navio) são colocados como atributos e operações da classe base (Meio de
Transporte), sendo compartilhados por cada classe derivada. Diz-se que cada classe
derivada herda as características de sua classe base.
34
Figura 9 - Herança entre classes
I.6.4 Agregação
Castro (2009) classifica agregação como o princípio que permite o desenvolvedor
considerar algo muito grande através do enfoque TODO-PARTE. Se a instância do
todo for removida, suas partes não necessariamente deverão ser removidas. Este
conceito torna-se útil para definir regras de negócio. A agregação define uma
"dependência fraca" entre o todo e suas partes. Se o todo for removido, as suas
partes poderão continuar existindo. É um mecanismo que permite a construção de
uma classe agregada a partir de outras classes componentes. Usa-se dizer que um
objeto da classe agregada (Todo) tem objetos das classes componentes (Parte).
Desta forma, a agregação pode ser aplicada quando um objeto é constituído de
outros objetos, por exemplo, um avião é composto de fuselagem, asas, motores,
35
trem de pouso, flaps e assim por diante. Uma pessoa é composta de membros,
tronco e cabeça. Estes são exemplos do conceito de agregação, que representa
relacionamentos do tipo “faz parte de”. Um motor faz parte de um avião e uma
cabeça faz parte de uma pessoa. A agregação nos permite modelar os
relacionamentos do tipo “parte de” ou “é composto de”.
Um Carro C possui um Motor M. Se o carro for removido do sistema, o motor que
estava sendo desenvolvido pode ser reaproveitado em outro carro.
A notação para a agregação é um pequeno losango ao lado da classe principal.
Representação Gráfica:
Figura 10 – Relacionamento entre classes - Agregação
I.6.5 Composição
Também baseado na relação todo-parte, porém define uma "dependência forte"
entre o todo e suas partes. Se o todo deixar de existir, as suas partes também
deixam de existir. Neste caso, se o objeto maior for removido, as suas partes filhas
serão removidas também (CASTRO, 2009).
Composição significa, “O todo contém as partes (e não referências para as partes).
Quando o todo desaparece, todas as partes também desaparecem” (ROCHA NETO,
2002).
36
Imagine o caso de um Carro C que possui uma Placa P registrada. Se o carro deixa
de existir, a placa não tem mais utilidade dentro do sistema. A notação para a
composição é um pequeno losango sólido ao lado da classe principal.
Representação Gráfica:
Figura 11 - Relacionamento entre classes – Composição
Na figura 12 temos uma ilustração de composição e associação. Uma empresa é
composta por divisões, que por sua vez consistem em departamentos; uma empresa
é indiretamente uma composição de departamentos. Uma empresa não é uma
composição
de
seus
funcionários,
pois
empresa
e
pessoa
são
objetos
independentes, de igual valor (BLAHA E RUMBAUGH, 2006).
Figura 12 - Composição e Associação
Fonte: BLAHA E RUMBAUGH, 2006, p.71
Neste ponto apresentamos então toda a fundamentação necessária para descrever
o desenvolvimento de um modelo de classe. No próximo capítulo teremos a
contextualização sobre o estudo de caso que será utilizado no desenvolvimento do
modelo.
37
II
As
O “ALERTA CADASTRAL NA CONCESSÃO DE CRÉDITO”
informações
descritas
neste
capítulo
foram
obtidas
em
documentos
disponibilizados por uma IF (Instituição Financeira), onde foi possível obter
informações sobre o contexto geral do problema. Demais informações, tais como
requisitos e funcionalidades foram levantados através de reuniões com os gestores
da área de crédito da mesma IF (agosto, 2008).
O problema do “Alerta cadastral na concessão de crédito” refere-se à verificação de
dados do proponente de crédito com intuito de identificar prováveis tentativas de
fraudes cadastrais no ato da obtenção do crédito em Instituições Financeiras.
Podemos caracterizar alguns tipos mais comuns de fraudes: roubo de identidade (o
autor utiliza a identidade de outra pessoa para obter crédito), identidade sintética
(cria-se uma identidade, com componentes de identidades reais de várias pessoas
para obter crédito), calote do primeiro pagamento (intencional), fraude de agente (o
agente do credor entra com informações incorretas para assegurar a aprovação do
crédito, comum quando esse agente recebe comissão por venda) e fraude
transacional (uma pessoa utiliza informações da conta de outra pessoa para obter
crédito, sem conhecimento de seu titular).
II.1
CONSIDERAÇÕES INICIAIS
O texto abaixo foi extraído de documentos fornecidos pela IF (agosto, 2008), e
servem de embasamento para o entendimento do problema do “Alerta cadastral na
concessão de crédito”:
As fraudes de crédito ocorrem através de roubo, furto, perda, extravio ou
falsificação de documentos pessoais e sua utilização para falsidade
ideológica. A preocupação com o combate às fraudes pode ser mais bem
entendida pela necessidade de diminuição de perdas, principalmente em um
38
cenário de aumento de concorrência. As perdas decorrentes de fraudes se
tornam um custo adicionado ao preço do produto vendido, tornando-o
menos competitivo.
As Instituições Financeiras, na busca por incremento de sua Carteira de
Crédito, estrategicamente, adentraram ao um ambiente de negócios
externo. Consequentemente, estas passaram a arcar com maiores riscos
operacionais e de crédito, principalmente em decorrência de fraudes.
O crescimento econômico e o aumento da oferta de crédito têm feito com
que as IF busquem outras formas para incremento de suas carteiras e
alavancagem de negócios, como parcerias firmadas com grandes redes de
varejo ou concessionárias/revendas de veículos. Tais parcerias apresentam
vantagens para os envolvidos, na medida em que permite:
a) às empresas parceiras, o aumento de suas vendas pela possibilidade de
financiamento de bens de consumo a seus clientes;
b) às Instituições Financeiras, o aumento de seus ganhos com a intermediação
financeira, pelo financiamento do comprador final e por conseguir atingir
potenciais tomadores de crédito, mesmo fora de suas agências, ampliando a
base de clientes;
c) aos consumidores finais, terem acesso mais rápido a bens, por meio do
financiamento de suas necessidades de consumo.
Todavia, se a realização de operações de crédito pelas instituições
financeiras por meio de parceiros traz maior oportunidade de negócios e
outros canais de contato com potenciais tomadores de crédito (clientes ou
não), carrega também maiores riscos operacionais e de crédito,
principalmente decorrentes de fraudes, visto que os mesmos são realizados
fora do ambiente das agências e por empregados de lojas muitas vezes sem
expertise ou qualificação necessária para verificação de documentos e
outras referências. Como forma de mitigar tais ocorrências, as Instituições
Financeiras oferecem treinamento para que os empregados dos parceiros
possam identificar e prevenir fraudes documentais. Todavia, tal medida tem
apresentado efeitos limitados, considerando o porte dos parceiros, seu
número de empregados, a diversidade cultural e de formação existente
entre estes e a rotatividade de mão-de-obra, além dos custos envolvidos.
No caso dos cadastramentos efetuados pelas agências, dentro de um
ambiente bancário, por exemplo, essa sistemática apresenta-se satisfatória,
visto que as informações são registradas e conferidas por funcionário do
banco treinado para verificar a exatidão dos dados, o que imprime maior
qualidade ao procedimento e diminui a possibilidade de ocorrência de erros.
Contudo, operações feitas no ambiente do parceiro são contratadas fora dos
canais próprios de distribuição da IF, de forma que a análise documental
dos proponentes, via de regra, não passa pelo crivo de segurança apontado
como necessário segundo às exigências anti-fraudes do mercado. Como
resultado, perdas provenientes de fraudes acabam por agregar-se ao preço
dos produtos e serviços bancários, na contramão do que propõe um cenário
concorrencial cada vez maior. Soma-se a isto a responsabilidade
institucional e social dos bancos na inibição da atuação do crime
organizado, dificultando o seu fortalecimento econômico.
A preocupação das IF com a questão da fraude tem provocado, no âmbito
de suas ações estratégicas, a implementação de processos de validação de
dados cadastrais, mediante cruzamento de dados de fontes internas e
externas, para prevenção e detecção de indícios de fraudes.
39
II.2
OBJETIVOS
Diante do exposto na seção anterior, resultou-se a necessidade de desenvolver uma
ferramenta automatizada para verificação de dados, com vistas à melhoria da
qualidade dos dados e a evitar eventuais fraudes, atuando como alerta à entrada de
dados na base de cadastro da IF. Isso se daria por meio do cruzamento de dados da
proposta de negócio com dados existentes em bases internas e externas,
relacionados em três blocos de informação: a) dados de identificação; b) dados de
localização; c) dados profissionais.
O cruzamento automatizado terá o objetivo de diminuir o tempo de resposta aos
clientes, quando comparado ao trabalho realizado de forma manual pelos analistas
de operações, que precisam acessar diversos sistemas para a verificação dos
dados.
A utilização de dados internos já existentes para verificação com os dados da
proposta de negócio trará também a vantagem de proteger os atuais clientes,
podendo evitar a possível perda do próprio cliente por desgaste no relacionamento,
além de possíveis ações judiciais e indenizações por inclusão indevida em órgãos de
proteção ao crédito.
No caso de a proposta se referir ao um proponente que não exista na base de
cadastro da IF, deverão ser obtidos os dados para verificação em fontes externas
(Outras Fontes), tais como: Base da receita federal; RAIS; e base de telefones;
II.3
REQUISITOS
A ferramenta de alerta cadastral na concessão de crédito deve receber a proposta
de negócio enviada por parceiros da IF, e efetuar as verificações dos dados da
proposta de negócio, em uma primeira fase, com informações de fontes internas da
40
própria IF. Verificações com fontes externas serão alvo de uma segunda fase de
desenvolvimento da ferramenta.
As verificações deverão se basear em regras especificadas pelo usuário gestor do
sistema a qualquer momento. Cada regra de verificação deve receber uma
pontuação de acordo com o grau de importância para geração do alerta de fraude,
que será emitido quando a somatória das ocorrências de verificações verdadeiras
ultrapassar parâmetro especificado pelo usuário do aplicativo.
Assim, o processo de “Alerta Cadastral” pode ser representado na forma da figura 13
abaixo:
Figura 13 - Fluxo do processo de Alerta Cadastral
Fonte: Documento fornecido pela IF (Modificado)
Fluxo do processo de Alerta Cadastral
1. Entrada de dados da Proposta de negócio: Parcerias externas;
2. Proposta de negócio é enviada para verificação no aplicativo Alerta cadastral;
41
3. Troca de informações entre o Alerta cadastral e as fontes de informações.
4. Proposta de negócio aprovada é registrada na Base de Clientes;
5. Proposta de negócio é enviada à análise Anti-Fraude;
6. Proposta de negócio é recusada pelo Alerta cadastral;
7. Proposta de negócio recusada é avaliada pela análise Anti-Fraude;
8. Análise anti-Fraude solicita nova verificação da proposta no aplicativo Alerta
cadastral.
Diante do exposto, temos os seguintes requisitos:
II.3.1 Proposta de negócio
A proposta de negócio é preenchida com os dados do proponente do crédito e
enviada pelo parceiro da IF. Esta possui três blocos de informações: identificação,
endereço e ocupação. Cada bloco de informação apresenta o seguinte
detalhamento:
Identificação (nome, CPF, data de nascimento, documento de identidade,
data de emissão do documento, órgão emissor, naturalidade,
nome do Pai, nome da mãe, estado civil e escolaridade);
Endereço (logradouro, complemento, bairro, município e CEP);
Ocupação (cargo, CGC empregador, nome do empregador, data de início na
empresa, valor da renda, data de referência da renda).
42
II.3.2 Fontes internas
As fontes de dados internas da IF são fontes de informação consideradas valiosas
para verificação das informações prestadas pelo proponente de crédito.
A IF possui base de dados com informações de seus clientes, que compreende além
dos dados de identificação, endereço e ocupação, os dados relativos à escolaridade.
São consideradas fontes internas:
1.
Base de dados de clientes da IF;
2.
Lista Negra – Torna-se útil esse auxílio com o intuito de restringir todos os
conteúdos de dados que inspiram desconfiança.
Desejos de, no futuro, sejam feitas também verificações com fontes externas. São
consideradas fontes externas:
1. RAIS - A gestão governamental do setor do trabalho conta com o importante
instrumento de coleta de dados denominado de Relação Anual de Informações
Sociais - RAIS;
2. Base de Telefonia;
II.3.3 Verificação de dados
A verificação dos dados da proposta de negócio com as fontes internas ocorrem
através de vários formas: verificação de conteúdo, cruzada, verificação com a lista
negra e verificação com propostas de negócios anteriores do mesmo proponente. A
ocorrência de uma de verificação que foi atendida (verdadeira) recebe uma
pontuação, que soma-se ao resultado final das verificações.
a) Verificação de conteúdo – objetiva comparar o conteúdo do dado recebido na
proposta de negócio com o mesmo dado existente na base de clientes da IF.
43
Exemplos:
Proposta de negócio X
Comparação
Base de clientes
Data de nascimento
diferente
Nome da mãe
diferente
Valor da renda
diferente 20%
Estado civil
diferente
b) A verificação cruzada busca verificar a coerência da informação, confrontando o
dado da proposta de negócio com outro dado da base de clientes, de base
auxiliar ou da própria proposta de negócio. Para verificação de coerência entre a
ocupação e o valor da renda informados na proposta de negócio, utiliza-se a
tabela auxiliar Faixa de valor de renda X Ocupação.
Outros exemplos de verificação cruzada:
− Data de nascimento na proposta x data de inicio na empresa;
− CEP do endereço residencial da proposta x CEP do endereço de trabalho
na base de clientes;
− CEP do endereço de trabalho na proposta x CEP do endereço residencial
na base de clientes;
− código DDD do telefone residencial x CEP do endereço residencial na
base de clientes;
− código DDD do telefone de trabalho x CEP do endereço profissional na
base de clientes
c) A Lista Negra contem dados informados pelo mercado que estão sendo ou foram
utilizados em fraudes, podem ocorrer por um dos seguintes motivos: utilização
em fraude, titular falecido e empresa de fachada - fraude. As propostas que
contêm estes dados terão a respectiva pontuação somada à pontuação das
outras ocorrências. A lista negra pode se referenciar a quaisquer campos de um
dos três blocos de informações que compõe a proposta de negócio.
44
A perspectiva é a de que possam ser incluídos e pesquisados tanto dados
isolados, como em conjunto de informações. Ou seja, caso seja descoberto um
telefone utilizado para ilícitos que não esteja relacionado a qualquer CPF ou
endereço diretamente, ele poderá ser incluído isoladamente no cadastro, não
dependendo de estar vinculado a um CPF, Identidade ou endereço.
A verificação poderá ser realizada a partir de um conjunto de dados ou somente
um dado específico.
II.3.4 Alerta de fraude
O alerta de fraude ocorre quando, após todas as verificações realizadas na proposta
de negócio, é constatado que o resultado da somatória das pontuações de cada
ocorrência encontrada ultrapassou parâmetro indicador de alerta de fraude. A
existência de alerta indica que a proposta de negócio não pode prosseguir para
atualização na base de clientes e consequentemente fica impedida da contratação
da operação de crédito, devendo ser disponibilizada para análise por analista de
crédito da IF ou simplesmente recusada.
II.4
PREMISSAS
1. A proposta de negócio é submetida à verificações e poderá ser novamente
verificada caso seja colocada em análise ou recusada;
2. Em uma regra de verificação poderá existir uma ou mais comparações entre
campos;
3. Uma comparação é feita com um campo da proposta de negócio versus as fontes
de informação.
45
II.5
FUNCIONALIDADES
A ferramenta do Alerta cadastral na concessão de crédito deverá possuir como
funcionalidade a possibilidade do usuário criar regras de verificações com base no
especificado no item II.3.3 Verificação
de
dados,
podendo
também
receber
atribuição de valor (pontuação) para o parâmetro que indica alerta de fraude. É
necessário que os filtros e parâmetros sejam calibrados inicialmente e recalibrados
de forma a manter sua atualidade de poder de prevenção. A incorporação de novas
regras de confrontações e alteração de parâmetros, será uma atividade constante,
conforme a mudança das táticas dos fraudadores.
A proposta de negócio, enviada por parceiro da IF, deverá ser recebida e registrada
no aplicativo e submetida ao processo de verificação dos dados com fontes de
informação (em uma primeira implementação apenas fontes internas, posteriormente
as fontes externas à IF também serão utilizadas como fonte de informação), sendo
esta a principal funcionalidade da ferramenta. Após as verificações realizadas,
deverá ser feita a somatória das pontuações das ocorrências verdadeiras de
verificações. O total das pontuações deverá ser comparado com o parâmetro
indicador de alerta de fraude, que indicará se a proposta deve ser aprovada,
reprovada ou colada em análise. Caso uma proposta colocada “em análise”
permaneça por mais de 10 dias (prazo parametrizável) sem alteração, ela será
recusada por “falta de análise”.
A proposta colocada “em análise” poderá ser recusada ou ter os dados modificados,
por usuário da ferramenta, e, após nova validação, ser aprovada por área
encarregada de verificação, desde que tenha pontuação de ocorrências abaixo de
valor a ser parametrizado. Sempre que houver alteração de dados, é necessária
nova validação. A proposta “recusada” ficará registrada no aplicativo para futuras
utilizações. Esta proposta poderá ter a situação modificada para “em análise” por
funcionário com acesso específico, seguindo posteriormente o previsto para este
nova situação.
46
III DESENVOLVIMENTO DO MODELO DE CLASSES
Conforme Blaha e Rumbaugh (2006, p.51 e p.84), na construção de um modelo para
uma aplicação, as seguintes sugestões devem ser observadas a fim de se obter
resultados claros e consistentes:
Não comece a construir um modelo de objetos simplesmente definindo
classes, associações e heranças. A primeira coisa a se fazer é entender
o problema a ser resolvido;
Tente manter seu modelo simples. Evite complicações desnecessárias;
Escolha nomes cuidadosamente. Nomes são importantes e carregam
conotações poderosas. Nomes devem ser descritivos, claros e não
deixar ambiguidades. A escolha de bons nomes é um dos aspectos
mais difíceis da modelagem;
Não ``enterre'' apontadores ou outras referências a objetos dentro de
objetos como atributos. Ao invés disto, modele estas referências como
associações. Isto torna o modelo mais claro e independente da
implementação;
Tente evitar associações que envolvam três ou mais classes de objetos.
Muitas vezes, estes tipos de associações podem ser decompostos em
termos de associações binárias, tornando o modelo mais claro;
Limite seu uso de herança múltipla ao que for essencial para um
modelo;
Tente evitar hierarquias de generalização muito profundas;
Não se surpreenda se o seu modelo necessitar várias revisões; isto é o
normal;
Você deve estar apto a reestruturar um modelo de classes para
melhorar a clareza e capturar restrições adicionais;
Sempre documente seus modelos de objetos. O diagrama pode
especificar a estrutura do modelo, mas nem sempre é suficiente para
descrever as razões por trás da definição do modelo. Uma explicação
escrita pode clarificar pontos tais como significado de nomes e explicar
a razão para cada classe e relacionamento.
47
III.1 IDENTIFICAR AS CLASSES E OS OBJETOS
Quando Blaha e Rumbaugh (2006) sugerem manter o modelo simples e evitar
complicações desnecessárias, implicitamente eles estão sugerindo utilizar a
abstração. Ou seja, voltar à atenção às questões essenciais inerentes a
problemática e ignorar os detalhes, para concentrar-se nas características
indispensáveis. A abstração será utilizada em todo o processo de desenvolvimento
do modelo de classes.
Nesse ponto, temos conhecimento de todos os requisitos do contexto do Alerta
cadastral na concessão de crédito. Sabe-se o que o aplicativo deverá fazer, ou seja,
quais funcionalidades deverão ser desenvolvidas. Agora é possível identificar os
objetos e classes que serão necessários para que essas funcionalidades possam ser
implementadas. Num primeiro momento é importante manter a atenção na
identificação das classes sem preocupar-se com detalhes de atributos ou métodos
(iremos nos preocupar com esses elementos posteriormente). Isso irá tornar o
projeto simplificado, pois iremos nos concentrar em um problema de cada vez, ao
invés de tentarmos pensar em tudo ao mesmo tempo. Iremos utilizar como base as
funcionalidades descritas no capítulo anterior.
Iniciando a análise com a funcionalidade criar regras de verificações, identificamos
que, de acordo com os requisitos especificados, uma regra de verificação é a
comparação de um campo da proposta de negócio com um ou mais campos de uma
fonte de informação. A comparação dos campos pode ocorrer de várias formas. Com
isso, sendo possível identificar os objetos: Regra de verificação e Comparação.
Prosseguindo com a análise, parte-se para a funcionalidade: verificação da proposta
de negócio. Para fazer o registro da entrada de uma proposta de negócio, o
proponente do crédito deverá preencher a proposta com os dados solicitados.
Utilizando-se dos conceitos expostos no capítulo I, podemos então identificar objetos
e consequentemente as classes, pois a classe é a representação de um objeto.
Diante deste posicionamento precisamos de objetos como: Proposta de negócio e
Proponente.
48
Uma proposta de negócio será submetida à verificação, que se baseia em regras de
verificação dos campos da proposta de negócio, que se dá a partir de várias formas
de comparação com uma fonte de informação. A partir disto, Identificam-se os
objetos: Fonte de informação e Verificação. Sabendo que a proposta de negócio
contém campos preenchidos com os dados do proponente, podemos relacionar o
objeto Campo.
A partir dos objetos relacionados resultam-se as seguintes classes:
Figura 14 – Classes do sistema
A partir do conceito de que a classe é um conjunto de objetos com as mesmas
características e comportamentos, chegou-se a conclusão das classes acima para a
modelagem do problema do alerta cadastral na concessão de crédito.
Na seção seguinte será identificado como essas classes se relacionam e o
surgimento de estruturas entre elas.
49
III.2 IDENTIFICAR AS ESTRUTURAS E OS RELACIONAMENTOS
O proponente preenche a proposta de negócio, que será submetida a verificações
com fontes de informação da IF. Pode-se identificar um relacionamento de
dependência entre Proponente e Proposta de negócio, pois um proponente passa a
existir a partir do preenchimento da proposta de negócio.
Figura 15 - Relacionamento entre Proponente e Proposta de negócio
A proposta de negócio é submetida à verificação. A partir deste requisito identifica-se
o relacionamento de associação entre as classes Proposta de negócio e Verificação.
Uma proposta de negócio poderá ser submetida a uma ou mais verificações e uma
verificação poderá ser aplicada a n propostas de negócio. Note aí a utilização do
conceito de multiplicidade, que especifica o número de elementos entre as classes
de uma associação.
Figura 16 - Relacionamento entre Proposta de negócio e verificação
Ainda analisando a classe Proposta de negócio, esta está relacionada à classe
Campo, pois a proposta é composta por campos. Agora sendo um relacionamento
de agregação, que pode ser aplicado quando um objeto é constituído de outros
objetos. A multiplicidade é definida como:
50
•
Uma proposta de negócio é composta por vários (n) campos. E um campo
consta em várias (n) propostas de negócio. Multiplicidade então * para *
O processo de verificação da proposta de negócio deve ser baseado em regras de
verificação, a partir disto podemos incluir o relacionamento de associação entre as
classes Verificação e Regra de verificação. A multiplicidade agora deverá ser a
seguinte:
•
Uma verificação está baseada em uma (1) ou n regras de verificações. Já
uma regra de verificação está relacionada a apenas uma (1) verificação,
gerando a multiplicidade 1 para 1..*.
Para cada regra de verificação poderá ser definido uma ou mais comparações. A
partir daí devemos relacionar a classe Regra de Verificação à classe Comparação,
desta vez num relacionamento de composição. A composição está sendo usada
neste caso, pois a classe Comparação possui uma dependência forte com a classe
Regra de verificação. Ou seja, se um objeto da Regra de verificação deixar de
existir, também deixará de existir o objeto relacionado à sua comparação.
A classe Comparação está relacionada também com a classe Campo, similarmente
à classe Proposta de negócio. A comparação também é composta por campos, e um
campo pode está relacionado a uma ou mais comparações. Analogamente, a classe
Fonte de Informação se relaciona com a Classe campo. Uma fonte de informação é
composta por um (1) ou mais campos.
A classe Comparação se relaciona ainda com a classe Fonte de informação num
relacionamento de associação. Uma comparação é realizada com uma fonte de
informação. E uma fonte de informação poderá estar sendo usada em uma ou mais
comparações.
Para modelagem adequada da classe Fonte de informação, utiliza-se o conceito de
classes abstratas e concretas. Para tal, é feito a especialização da classe Fonte de
informação, resultando nas classes Interna e Externa. Estas duas classes são
consideradas classes abstratas, assim com a classe Fonte de informação.
51
Especializando ainda mais com objetivo de chegar a classes concretas, podemos
fazer a decomposição da classe Interna. Resultando assim as classes Cliente e Lista
Negra. Tudo isso conforme o especificado na descrição de requisitos.
Os relacionamentos completos entre as classes são ilustrados na figura 16:
Figura 17 - Diagrama de Classes (Estruturas e Relacionamentos)
52
III.3 IDENTIFICAR OS ATRIBUTOS IMPORTANTES
Através da descrição dos requisitos é possível identificar os atributos considerados
importantes em cada classe, porém ocorre, após a fase de estabelecer os
relacionamentos e estruturas, o surgimento de outros atributos para dar suporte aos
novos relacionamentos.
O proponente possui atributos como: CPF, Nome e Data de Nascimento. A proposta
de negócio poderá possuir um número, que identificará unicamente cada proposta
recebida. Torna-se importante também a data e hora que a proposta é recebida.
Figura 18 - Atributos de Proponente e Proposta de negócio
O diagrama de classes da UML contendo todos os atributos das classes é
apresentado na figura 19. A identificação e o objetivo de cada atributo presente no
diagrama podem ser realizados fazendo-se uma co-relação com o levantamento de
requisitos.
53
Figura 19 - Diagrama de Classes - atributos
III.4 IDENTIFICAR MÉTODOS
Métodos ou operações representam o comportamento do objeto, ou seja, indicam os
serviços realizados pelos objetos de uma mesma classe. É possível identificar os
métodos necessários para cada classe a partir das funcionalidades já descritas no
capítulo II.
Com isso partimos, para identificação dos principais métodos. A classe proponente
apresenta um único método, consultar(), pois para a aplicação, será necessário
54
apenas saber se o proponente existe. Registrar() e verificar() são os métodos
(operações) encapsulados pela classe proposta de negócio. Já os objetos da classe
campo e da classe verificação possuem como características os métodos incluir() e
excluir(). Fazendo o levantamento para as demais classes tomando por base o
levantamento de requisitos e as funcionalidades, podemos encontrar o seguinte
modelo:
Figura 20 - Diagrama de Classes (métodos)
III.5 NOVOS OBJETOS
É muito comum, no processo de análise e modelagem do problema, o surgimento de
novos objetos após o primeiro levantamento, objetivando tornar o modelo ainda mais
coerente com a realidade.
55
Com isto, surgem vinculados à classe Proposta de negócio as classes Identificação,
Endereço e Ocupação com intuito de modelar as informações que compõem a
proposta nestas três categorias.
Recorrendo ao conceito de classe de associação, onde é definido que quando uma
associação possui propriedades importantes que necessitam estar representadas,
torna-se primordial a modelagem de mais uma classe, resultante do relacionamento
entre Proposta de negócio e Verificação. A nova classe, Proposta verificada, possui
atributos importantes como: data, hora, pontuação da verificação e situação da
proposta (aprovada, em análise ou reprovada).
Ainda refinando um pouco mais a modelagem com a análise da funcionalidade “O
total das pontuações deverá ser comparado com o parâmetro indicador de alerta de
fraude, sendo a proposta aprovada, reprovada ou colocada em análise de acordo
com a pontuação obtida”, surge no modelo a classe “Pontuação de alerta”.
Figura 21 - Novos objetos do relacionamento: Proposta de negócio e Verificação
Quando analisamos mais atentamente as classes Cliente e Proponente é possível
identificar que os objetos destas classes possuem atributos e métodos comuns.
56
Com isso torna-se importante aplicar o conceito de generalização, surgindo a classe
Pessoa (classe abstrata) para agrupar Proponente e Cliente (classes concreta).
Figura 22 - Novo objeto da generalização de Proponente e Cliente
57
III.6 O MODELO COMPLETO
O modelo de classes completo do problema do alerta cadastral na concessão de
crédito é apresentado na figura abaixo:
Figura 23 - Diagrama de Classes (completo)
Blaha e Rumbaug (2006) mencionam que não deve haver nenhuma surpresa se o
modelo necessitar de várias revisões, sendo normal que isto ocorra. Portanto, não
devemos pensar que este seria o modelo final, podendo o mesmo sofrer ainda
alguma reestruturação para melhorar a clareza e capturar restrições adicionais.
58
CONCLUSÃO
Quando bem aplicada, a OO traz diversas vantagens: melhora a captura e validação
de requisitos, permite um modelo de sistema mais realístico, proporciona facilidade
de interoperabilidade e de manutenção. A OO é um paradigma que pode ser
aplicado ao longo de todo o processo de construção da aplicação.
Apesar de todas as vantagens que a OO oferece, no decorrer do trabalho surgiram
algumas barreiras a serem vencidas. Uma das principais dificuldades encontradas
no desenvolvimento do modelo de classes foi a percepção e compreensão dos
requisitos do problema “Alerta cadastral na concessão de crédito”, para possibilitar a
transcrição numa linguagem clara e objetiva. Com isto, foi possível constatar a
grande importância do levantamento de requisitos para a qualidade efetiva da
aplicação, e também que ele deve estar bem escrito para servir de documento para
outras pessoas que não são conhecedores do problema.
Outro obstáculo encontrado foi mudar da cultura da análise estruturada para visão
de objetos. No início, existiu muita dificuldade em romper o cordão umbilical de
ligação à análise estruturada, e se desvincular de alguns paradigmas que tinha
sobre programação e desenvolvimento de sistemas.
As dificuldades em fazer com que os conceitos de OO fossem assimilados, foram
constantes. Surgiram muitas dúvidas sobre quais comportamentos e informações
deveriam estar ou não em uma determinada classe e também como é que uma
classe se relacionaria com outra. Somente com muita leitura e estudo foi possível
romper esta barreira e deixar para trás as dúvidas, mas foi principalmente
observando e estudando soluções que outras pessoas conceberam, analisando
problemas e modelos resolvidos, é que adquiriu-se melhor compreensão de como
tudo funciona em OO.
59
Diante disto, destaca-se como experiência bastante positiva, a realização de um
estudo de caso, que possibilitou a consolidação e transmissão dos conhecimentos,
sem dúvida fazendo diferenças significantes frente a um trabalho apenas teórico.
60
REFERÊNCIAS BIBLIOGRÁFICAS
CASTRO, MAURÍCIO DE. Orientação a Objetos. Disponível em:
<http://www.jack.eti.br/www/arquivos/apostilas/java/logicapoo.pdf>. Acesso em
09/01/2009.
CORREIA, CARLOS HENRIQUE; TAFNER, MALCON ANDERSON – Análise
orientada a objetos. 2ª. Edição. Florianópolis: Visual Books, 2006.
BLAHA, MICHAEL; RUMBAUGH, JAMES; tradução Daniel Vieira. Modelagem e
projetos baseados em objetos com UML2. 2ª. Edição. Rio de janeiro: Elsevier,
2006.
DEBONI, JOSÉ EDUARDO ZINDEL. Modelagem orientada a objetos com a UML.
São Paulo: Futura, 2003.
GUEDES, GILEANES T. A. UML, Uma abordagem prática. São Paulo: Novatec,
2004.
MACORATTI, JOSÉ CARLOS. Orientação a objetos: Conceitos Básicos.
Disponível em: <http://www.macoratti.net/net_oocb.htm>. Acesso em 26/01/2009.
MACORATTI, JOSÉ CARLOS. UML – Diagrama de Classes e objetos. Disponível
em: <http://www.macoratti.net/net_uml1.htm>. Acesso em 17/01/2009.
Métodos de orientação a objetos. Disponível em:
<http://www.lcs.poli.usp.br/~jra/PROMINP/disciplina_OO_pdf/aula_V_Metodos_OO.p
df>. Acesso em 09/01/2009.
Orientação a Objetos. Disponível em:
<http://sites.facensa.com.br/daniel/files/es2/OO.pdf>. Acesso em 09/01/2009.
PIRES, PAULO F. Modelagem Conceitual Orientação a objetos. 2002. Disponível
em: <http://www.dimap.ufrn.br/~paulo.pires/cursos/bd/uml.pdf>. Acesso em
13/01/2009.
RICARTE, IVAN LUIZ MARQUES. Introdução a orientação a objetos. 2001.
Disponível em: <http://www.dca.fee.unicamp.br/cursos/POOCPP/node3.html>.
Acesso em 09/01/2009.
ROCHA NETO, ELOI. Diagrama de Classes. Disponível em:
<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/classes/class
es1.htm>. Acesso em 10/01/2009.
61
WIKIPÉDIA. Orientação a Objetos. Disponível em:
<http://pt.wikipedia.org/wiki/Orienta%C3%A7%C3%A3o_a_objetos> . Acesso em
10/01/2009.