Embed Size (px)
Citation preview
CURSO DE SISTEMAS DE INFORMAÇÃO
A ARQUITETURA MULTICAMADAS NA ESTRUTURAÇÃO DE MÓDULOS DE SISTEMAS
ORIENTADOR: HUGO XAVIER DA ROCHA
ORIENTANDO: ALYSSON DIAS DA SILVA
Dezembro
2006
ii
CURSO DE SISTEMAS DE INFORMAÇÃO
A ARQUITETURA MULTICAMADAS NA ESTRUTURAÇÃO DE MÓDULOS DE SISTEMAS
Itumbiara, 12 de Dezembro de 2006.
Monografia apresentada por Alysson Dias da Silva ao Curso de Sistemas de Informação do Instituto Luterano de Ensino Superior de Itumbiara para a Obtenção de Bacharel em Sistemas de Informação. Professor Hugo Xavier da Rocha (Orientador)
iii
Monografia defendida e aprovada, em 12 de dezembro de 2006, pela banca examinadora:
Professor Mestre Hugo Xavier Rocha
Orientador
Professor Mestre Jucélio Costa Araújo
Professor do curso de Sistemas de Informação
Professor Especialista Wender Antonio da Silva
Professor do curso de Sistemas de Informação
iv
DEDICATÓRIA
Dedico este a Deus, que diante das adversidades me
encheu de forças, ajudando-me a enfrentar todas as
barreiras e dificuldades, pois nenhuma delas foi tão
grande perante seu poder. Dedico também a todas as
pessoas que eu amo, aos meus amigos e professores.
v
AGRADECIMENTOS
Este caminho cheio de dificuldades e adversidades por nós percorridas nos tornou mais
maduros e experientes. O resultado de tanto esforço e dedicação se faz agora, em realidade.
Afinal, o Homem é como uma árvore frutífera, e seus frutos devem ser compartilhados para
saciar a fome de saber do mundo.
Primeiramente, lembro-me e agradeço aos meus familiares que no calor de seus braços
me acolheram e me deram forças para crescer e lutar por um ideal. O lar sempre esteve em
minha vida como um refúgio caloroso perante todos os momentos difíceis. Meu pai, já não
está presente para ver a realização deste sonho acontecer, porém ele me ensinou o que mais me
influenciou todo este tempo, me ensinou a perseverar diante dos obstáculos, juntamente com a
minha mãe; eles e as outras pessoas que eu amo são meus alicerces.
E por fim, aos amigos que ao longo da caminhada andaram sempre em passos firmes ao
meu lado, trocando experiências e vivenciando todos os momentos juntos a mim, mostrando-
me que a amizade é sem dúvida o que de mais temos de valioso nesta vida. Que deus possa
dar-lhes todo o apoio que um dia vocês me prestaram.
vi
RESUMO
Atualmente, variados tipos de empresas têm problemas em tratar as informações e regras de negócio a
fim de manter a sua integridade. Este tratamento deve estar aliado ao bom desempenho dos sistemas a
esta tarefa envolvidos. A tecnologia do desenvolvimento em múltiplas camadas pode entrar como um
diferencial na elaboração e esquematização destes sistemas, tornando mais correta a utilização das
regras de negócio existentes na Organização e oferecendo vantagens, principalmente para organizações
em expansão, que a cada dia necessitam gerir uma gama maior de informações e seu fluxo incessante.
Sabe-se que a competitividade de uma Empresa no atual patamar de evolução tecnológica está
intimamente ligada à busca de melhores condições para orientar as idéias e os processos, tornando-os
viáveis. Como fruto deste modelo de raciocínio, é primordial a valorização dos sistemas que realizam a
gestão das informações, visando sob todos os aspectos possíveis o ganho em termos de acessibilidade,
praticidade e velocidade de acesso aos dados, conseqüentemente tratando falhas que geram dispêndio
de recursos e mão-de–obra. O fato de as regras de negócio (de alta importância para os processos
organizacionais) e os dados não possuírem tratamento especial e estar emparelhados, gera problemas
como a depreciação destas regras e velocidade decrescente de processamento e acesso de usuário.
Outra questão não menos relevante está no fato de que os sistemas sofrem constantes modificações, e
sua substituição precisa ser feita em cada estação cliente ao se utilizar uma arquitetura de duas
camadas, tornando o processo dispendioso e custoso. Além disso, muitos usuários têm o hábito de
trabalhar com várias aplicações executando simultaneamente, o que torna ainda mais problemático o
uso deste tipo de arquitetura de software, a qual permite o surgimento do famoso “gargalo de rede”. O
principal objetivo deste, portanto, será identificar as vantagens de se utilizar a Arquitetura
Multicamadas na estruturação de módulos de um Sistema Empresarial, visando obter o melhor
tratamento das regras de negócio e melhorias no acesso aos dados. Os resultados esperados serão os
ganhos em desempenho, escalabilidade e manutenibilidade, além da valorização do tratamento das
informações e processos, utilizando as vantagens proporcionadas ao se utilizar múltiplas camadas na
esquematização e desenvolvimento de um software. A Metodologia de pesquisa se fundamenta na
pesquisa de campo e a observação direta dos processos relacionados com a origem do fluxo de
informações (entrada e encaminhamento dos dados) estendendo-se até ao Centro de Processamento de
Dados (principal local de gerência dos processos do sistema).
Palavras-chave: multicamadas, arquitetura, sistemas.
vii
ABSTRACT
Currently, varied types of companies they have problems in dealing with the information and rules
business in order to keep its integrity. This treatment must be ally to the good performance of the
involved systems to this task. The technology of the development in multiple layers can enter as a
differential in the elaboration and development of these systems, becoming more correct the use of the
existing rules of business in the Organization and offering advantages, mainly for organizations in
expansion, that to each day need to manage a bigger gamma of information and its incessant flow. It
knows that the competitiveness of a Company in the current platform of technological evolution is
directly on to the search of better conditions to guide the ideas and the processes, becoming them
viable. As fruit of this model of reasoning, the valuation of the systems is essential that carry through
the management of the information, aiming at under all the possible aspects the profit in terms of
accessibility, rapidity and speed of access to the data, consequently treating imperfections that
generate great expense of resources and man power. The fact of the business rules (of high importance
for the organization processes) and the data not to possess special treatment and to be paired, generate
problems as the depreciation of these rules and decreasing speed of processing and access of user.
Another less excellent question is not in the fact from that the systems suffer to constants
modifications, and its necessary substitution to be made in each station customer to if using an
architecture of two layers, becoming the process loser and expensive. Moreover, many users have the
habit simultaneously to work with some applications executing, what he still more becomes
problematic the use of this type of software architecture, which allow the sprouting of the famous
“pass of net”. The main objective of this, therefore, will be to identify the advantages of if using the
Multi-tiers Architecture in the development of modules of an Enterprise System, aiming at to get
optimum treatment of the business rules and improvements in the access to the data. The waited
results will be the profits in performance, scalability and maintenance, beyond the valuation of the
treatment of the information and processes, using the proportionate advantages to if using multiple
layers in the projection and development of a software. The Methodology of research if bases on the
research of field and the direct comment of the processes related with the origin of the flow of
information (entered and guiding of the data) extending until the o Data processing center (main place
of management of the processes of the system).
Keywords: multi-tiers, architecture, systems.
viii
PUBLICAÇÃO
SILVA, Alysson Dias da. A Arquitetura Multicamadas na Estruturação de Módulos
de Sistemas. VII Encontro de Pesquisa e V Encontro de Iniciação Científica, Itumbiara – Go,
Novembro/2006 – publicado.
ix
SUMÁRIO
Resumo.................................................................................................................................... vi Abstract.................................................................................................................................... vii Lista de Figuras........................................................................................................................ xi Lista de Tabelas....................................................................................................................... xiii Lista de Abreviações................................................................................................................ xiv 1. INTRODUÇÃO..................................................................................................................15 1.1 Motivação .....................................................................................................................16 1.2 Justificativas .................................................................................................................16 1.3 Objetivo do Trabalho....................................................................................................17 1.4 Metodologia de Pesquisa ..............................................................................................18 1.5 Organização do trabalho...............................................................................................19
2. CAPITULO I – DEFINIÇÕES...........................................................................................20 2.1 Introdução.....................................................................................................................20 2.2 Qualidade de Software..................................................................................................20 2.3 A Arquitetura de Software............................................................................................21 2.3.1 Arquitetura Monolítica ...........................................................................................23 2.3.2 Arquitetura em Duas Camadas ...............................................................................24 2.3.3 A Arquitetura Multicamadas (n-tier)......................................................................24
2.4 Trabalhos relacionados ao uso da Arquitetura Multicamadas......................................29 2.5 O Tratamento das Regras e Informações......................................................................34 2.6 Considerações Finais ....................................................................................................36
3. CAPÍTULO II – A Modelagem de Desenvolvimento........................................................37 3.1 Introdução.....................................................................................................................37 3.2 A modelagem UML.....................................................................................................37 3.2.1 Análise de Requisitos para o Modelo .....................................................................37 3.2.2 Diagrama de Contexto. ...........................................................................................38 3.2.3 Diagrama de Casos de Uso.....................................................................................39 3.2.4 Diagramas de Seqüência.........................................................................................40 3.2.5 Especificação de Processos ....................................................................................41
3.3 Diagrama de Entidades e Relacionamentos DER.........................................................46 3.4 Considerações Finais ....................................................................................................46
4. CAPITULO III – A CONSTRUÇÃO DO MODELO .......................................................47 4.1 Introdução.....................................................................................................................47 4.2 O SERVIDOR COM+..................................................................................................47 4.3 O CLIENTE COM+ .....................................................................................................52 4.4 CONTINUANDO O DESENVOLVIMENTO – ALTERNANDO ENTRE SERVIDOR E CLIENTE .....................................................................................................57 4.5 FINALIZANDO: O CLIENTE COM+ E AS REGRAS..............................................66 4.6 Considerações Finais ....................................................................................................76
5. CAPÍTULO IV - A DISTRIBUIÇÃO DOS SISTEMAS DESENVOLVIDOS COM+....78 5.1 Introdução.....................................................................................................................78 5.2 Sistema Operacional Windows 95................................................................................78 5.3 Windows 98, NT, 2000 e XP........................................................................................78 5.4 Exportação do Servidor COM+....................................................................................79
x
5.5 Exportação com Proxies (Cliente COM+) ...................................................................81 5.6 A Instalação em outros terminais – Os Clientes Magros .............................................82 5.7 Considerações Finais ....................................................................................................83
6. CAPÍTULO V – CONCLUSÕES E TRABALHOS FUTUROS.......................................84 6.1 Introdução.....................................................................................................................84 6.2 Conclusões....................................................................................................................84 6.3 Trabalhos Futuros .........................................................................................................85
Bibliografia ...............................................................................................................................87
xi
LISTA DE FIGURAS
Figura 1: Aplicação monolítica (PEDRON, 2003)...................................................................23 Figura 2: Arquitetura Cliente/Servidor (PEDRON, 2003). ......................................................24 Figura 3: Arquitetura com três camadas (PEDRON, 2003). ....................................................25 Figura 4 – Modelo Cliente-Servidor e Modelo de Camadas (FOX, 1999). .............................26 Figura 5 – Estrutura lógica da Arquitetura Multicamadas. (RODRIGUES, 2002)..................27 Figura 6: Diagrama de Contexto do Módulo Proposto ............................................................38 Figura 7: Diagrama de Casos de Uso do Módulo.....................................................................39 Figura 8: Diagrama de seqüência do Login..............................................................................40 Figura 9: Diagrama de seqüência: Validação dos dados pessoais e Financeiros. ....................40 Figura 10: Diagrama de seqüência: Impressão dos relatórios. .................................................41 Figura 11: Representação gráfica do processo 1. .....................................................................42 Figura 12: Representação gráfica do processo 2. .....................................................................43 Figura 13: Representação gráfica do processo 3. .....................................................................44 Figura 14: Representação gráfica do processo 4. .....................................................................45 Figura 15: Diagrama DER contendo as principais tabelas da Base de Dados. ........................46 Figura 16: O Diálogo da opção Multitier no Delphi. ...............................................................48 Figura 17: A Type Library........................................................................................................48 Figura 18: Fontes do arquivo DPR. ..........................................................................................49 Figura 19: O Data Module com o ADOConection. ..................................................................50 Figura 20: Object Inspector do Delphi mostrando a Conexão realizada com sucesso.............50 Figura 21: Evento Oncreate( ) do RDM...................................................................................51 Figura 22: Instalando o Servidor COM+..................................................................................51 Figura 23: Servidor COM+ nos Serviços de Componente do Windows..................................52 Figura 24: Visão do Project Manager do Delphi. ....................................................................53 Figura 25: Criando o novo projeto no Project Manager. .........................................................53 Figura 26: Project Manager com os dois Projetos. ..................................................................54 Figura 27: Data module com os componentes de conexão. .....................................................54 Figura 28: DCOM Cliente conectado com suas propriedades. ................................................55 Figura 29: O Formulário de Login............................................................................................55 Figura 30: Opções do Projeto Cliente. .....................................................................................56 Figura 31: Código fonte do arquivo DPR.................................................................................57 Figura 32: Método Login_BD na Type Library. ......................................................................58 Figura 33: A implementação do Método Login_BD................................................................59 Figura 34: Tirando o Serviço COM+ do ar usando o recurso Component Services. ...............60 Figura 35: Códigos do formulário de Login. ............................................................................61 Figura 36: Login não confirmado no Formulário de acesso.....................................................62 Figura 37: Login efetuado com sucesso. ..................................................................................62 Figura 38: A nova Interface e as propriedades Read e Write...................................................64 Figura 39: Nova Função e Procedimento declaradas em RDMTabelas...................................64 Figura 40: Nova Variável que apoiará a Class Factory (Fábrica de Classe). ..........................65 Figura 41: Implementação da função GET e procedimento SET.............................................65 Figura 42: O uso da variável RDM_TabelasFactory que irá receber as informações da Interface e da CoClasse do TRDMTabelas. .............................................................................65 Figura 43: A implementação da função Get_RDMTabelas. ....................................................66 Figura 44: Confirmação do Registro do Servidor COM+. .......................................................66 Figura 45: Layout do formulário principal. ..............................................................................67 Figura 46: O componente CBrokerDados. ...............................................................................68
xii
Figura 47: O código da função Busca_cartao...........................................................................69 Figura 48: Usando a função Busca_cartao. ..............................................................................70 Figura 49: O layout da TLB, com os métodos da Interface IServer_COMPlus.......................71 Figura 50: O layout do Formulário principal da Aplicação Cliente. ........................................72 Figura 51: A implementação da função Busca_saldo. .............................................................72 Figura 52: A implementação da função Busca_meses_atraso..................................................73 Figura 53: A implementação da função Busca_cpf..................................................................73 Figura 54: A implementação da função calcula_parcela..........................................................74 Figura 55: A Representação do Modelo Implementado...........................................................76 Figura 56: A opção exportar do Objeto COM+........................................................................79 Figura 57: A tela inicial do Assistente de Exportação do Objeto COM+. ...............................80 Figura 58: Exportando o arquivo MSI do Servidor da Aplicação............................................80 Figura 59: A tela de exportação do Cliente COM+..................................................................81 Figura 60: Utilizando a Aplicação Cliente. ..............................................................................83
xiii
LISTA DE TABELAS
Tabela 1: Dados da Aplicação de Facunte -projeto de TimeSheet (RODRIGUES, 2002).......29 Tabela 2: Prós e Contras relatados por Roberto Capra Neto – Sistema de Controle de Logística (RODRIGUES, 2002)...............................................................................................31
xiv
LISTA DE ABREVIAÇÕES
ADO (ActiveX Data Objects)
BD (Banco de Dados)
BDE (Borland Database Engine)
COM (Component Object Model)
COM+ (Component Object Model Plus)
CORBA (Common Object Request Broker Architecture)
CPD (Centro de Processamento de Dados)
DCOM (Distributed Computing Object Model)
DER (Diagrama de Entidades e Relacionamentos)
DLL (Dynamically Linked Library)
DM (Data Module)
EJB (Entity Java Beans)
GUID (Globally Unique Identifier)
MTS (Microsoft Transaction Server)
OLE (Object Linking and Embedding)
OO (Orientação a Objetos, Orientado a Objetos)
POO (Programação Orientada a Objetos)
RDM (Remote Data Module)
SGBD (Sistema de Gerenciamento de Banco de Dados)
SOAP (Simple Object Access Protocol)
TI (Tecnologia da Informação)
TLB (Type Library)
UML (Unified Modeling Language)
15
1. INTRODUÇÃO
Este trabalho tem como proposta apresentar a viabilidade de se utilizar a técnica
conhecida como n-tier (multicamadas) na estrutura de um software empresarial. Atualmente,
determinados tipos de empresas têm problemas em tratar as informações devido ao
crescimento de seu fluxo, e a falta de planejamento de seus Sistemas de Gestão. A tecnologia
do desenvolvimento em múltiplas camadas pode entrar como um diferencial na elaboração e
esquematização destes sistemas, tornando mais correta a utilização das regras de negócio
existentes na Organização e oferecendo vantagens, principalmente para organizações em
expansão, que a cada dia necessitam gerir uma gama maior de informações e seu fluxo
incessante. Sabe-se que a competitividade de uma Empresa no atual patamar de evolução
tecnológica está intimamente ligada à busca de melhores condições para orientar as idéias e os
processos, tornando-os viáveis. Como fruto deste modelo de raciocínio, é primordial a
valorização dos sistemas que realizam a gestão das informações, visando sob todos os aspectos
possíveis o ganho em termos de acessibilidade, praticidade e velocidade de acesso aos dados,
conseqüentemente tratando falhas que geram dispêndio de recursos e mão-de–obra. À medida
que as regras e as informações (de alta importância para os processos organizacionais) estão
emparelhadas com o armazenamento dos dados, sem ter um tratamento especial e sem maiores
cuidados, surgem problemas como a depreciação de algumas destas regras e problemas com
acesso de usuário. Outra questão não menos relevante está no fato de que os sistemas gestores
de uma empresa sofrem constantes modificações, necessitando mudar de versão
frequentemente. Quando a arquitetura de um software é baseada no modelo cliente/servidor a
distribuição e substituição do executável e arquivos pertinentes precisam ser feitas em cada
estação cliente, tornando o processo dispendioso e custoso. Além disso, muitos usuários
costumam trabalhar com várias aplicações executando simultaneamente, o que torna ainda
mais problemático o uso da arquitetura de duas camadas acima citada.
16
1.1 Motivação
De acordo com Pressman1 (PRESSMAN, 1995), “o software tornou-se o elemento-chave
da evolução dos sistemas e produtos baseados em computador”. Isso é a e evolução de um
simples processador de dados a um produtor de valiosas informações que proporcionam o
diferencial competitivo das organizações modernas. Com tantas evoluções a capacidade de
lidar com o constante crescimento da complexidade (e quantidade) das informações fica
comprometida, pois muitos sistemas não foram projetados para tal. Na empresa estagiada, uma
Organização do ramo Financeiro em franca expansão, o número de usuários e aplicações
modulares aumentam de forma progressiva; cuidar das Regras de Negócio e do desempenho,
portanto, é algo primordial nesta Organização, que como muitas outras, lida com uma gama
maior de informações a cada dia. Tais aplicações modulares, funcionam em paralelo com o
sistema de gestão principal, o que contribui muito para a queda de performance de acessos aos
dados. Outro fator importante é o papel do usuário, que não possui todo o conhecimento
necessário para lidar com os sistemas de forma a extrair seu potencial máximo.
Portanto, identificados os problemas, a arquitetura multicamadas se mostrou como um
método para se aplicar aos módulos de sistemas gestores a fim de trazer benefícios para a
empresa. A escolha da Tecnologia COM+ (Component Object Model Plus) foi feita por ser a
tecnologia que se ajusta aos padrões de sistema da organização onde se deu a pesquisa, e pelos
diversos “recursos como a escalabilidade, fácil distribuição e gerenciamento, suporte a
transações, além de muitos outros benefícios” (RODRIGUES, 2002).
1.2 Justificativas
Pode ser que no início muitos se perguntaram o porquê do surgimento da tecnologia
multicamadas, abandonando o tradicional método cliente/servidor. A questão é que um
aplicativo simples pode ser utilizado em ambientes de rede de forma eficiente em duas
camadas, porém segundo (RODRIGUES, 2002 p.11) “todas as desvantagens da arquitetura
Cliente/Servidor podem ser transformadas em vantagens quando usamos multicamadas”.
Através da aplicação da tecnologia, é possível contornar diversos problemas que acontecem na
estrutura tradicional, como a Dispersão das Regras, a Dificuldade de Distribuição (sempre que
1 Autor responsável por brilhantes estudos sobre a Engenharia de Software na década de noventa, com conceitos mencionados até a presente data em diversos trabalhos científicos.
17
se altera uma regra o aplicativo necessita ser redistribuído) e queda de performance. Outro
agravante destes problemas é a constante interação com outras tecnologias (principalmente a
internet), o que torna o processo mais exigente em termos de processamento de troca de
informações. Com o uso da Arquitetura Multicamadas, estes problemas tornam-se vantagens,
valorizando assim o acesso às informações pertinentes, com ganho em manutenibilidade,
desempenho, escalabilidade e valorização das regras de negócio da Organização, esperando
como resultado sanar a dificuldade em lidar com o processo acima descrito.
Na Organização onde se deu a pesquisa, foi notado o cenário onde há no centro o
Sistema de Gestão Principal, e alguns módulos deste sistema que funcionam a parte. Tais
módulos têm a finalidade de desempenhar funções que não são comuns e pertinentes ao
sistema principal, como por exemplo: Análise de Perfil de Pessoas Físicas, Simulação de
Propostas de Parcelamentos para clientes sem telefone cadastrado, Relação e atualização de
Pesquisa de clientes em atraso, Sistema de Score de Crédito, e vários processos de extração de
informações. Dado este cenário, foi constatado que um problema como a queda de
desempenho dos sistemas seria eminente, já que inúmeros usuários costumam trabalhar com
várias janelas processando ao mesmo tempo e que os módulos externos são em grande parte,
responsáveis por estes acessos inúmeros. Então com o uso da Arquitetura Multicamadas nestes
módulos, busca-se alcançar a melhoria no desempenho destes sistemas e, consequentemente
do Sistema Principal. Este projeto então trabalhará nesta linha, mostrando o desenvolvimento
de um modelo adequável aos módulos do sistema empresarial passo a passo, utilizando a
tecnologia COM+2 e chegando a duas aplicações finais, um Servidor COM+ e seus Clientes.
1.3 Objetivo do Trabalho
Apresentar as especificações para construção de um modelo adequável ao crescimento de
um Sistema de Gestão de Informações e seus módulos externos, através da aplicação da
tecnologia n-tier (multicamadas), valorizando assim o acesso às informações pertinentes, com
ganho em manutenibilidade e valorização das regras de negócio da Organização, além de
outros benefícios agregados, mostrando para a empresa todos estes benefícios, para que no
futuro (caso seja necessário), todo o sistema possa ser estruturado com a Arquitetura
Multicamadas.
2 Component Object Model Plus, tecnologia que representa a evolução do DCOM (Distributed Computing Object Model) de acordo com (RODRIGUES, 2002).
18
1.4 Metodologia de Pesquisa
A Empresa utilizada como ambiente de coleta de dados, é um ambiente formado por
setores distintos que são: Atendimento, Central de Processamento de Dados, Financeiro,
Recuperação de Crédito, Departamento Pessoal e Diretoria. Ë uma empresa que possui um
banco de dados de porte considerável, com informações dos processos utilizados por ela desde
sua fundação em 2001. Atualmente, conta também com Franquias em diferentes pontos do
país (Frutal, Cuiabá, Guaratinguetá e Goiânia), compreendendo um total de 25 funcionários
empregados diretamente e outras dezenas indiretamente. Devido a este patamar, a empresa lida
diariamente com uma alta gama de informações de transações envolvendo milhares de cartões
por todo o Brasil. Sua missão é se tornar uma empresa referência no ramo de Administradora
de Cartões de Crédito e Serviços no País, contando com o auxilio da Tecnologia da
Informação e dos Sistemas de Informação para gerenciar todos os processos que compõe o
negócio.
A pesquisa inicial foi realizada na empresa estagiada durante o primeiro semestre de
2006, Super Card Administradora de Cartões e Serviços Ltda. foi um estudo de caso que levou
à identificação dos problemas relacionados ao tratamento das regras de negócio e do fluxo de
informações, levando à proposição da adoção da Arquitetura Multicamadas como possível
solução para estas questões que desde o princípio da criação da Organização (2001) existem.
Toda a Empresa foi utilizada como universo da pesquisa, pois os problemas constatados
encontravam-se na dissipação das regras e informações que aconteciam a partir da Franquia de
Itumbiara, a base central da organização. Foram observados todos os setores da Organização:
atendimento, financeiro, recuperação de crédito, CPD, e diretoria. O CPD foi o setor que mais
contribuiu para a realização da coleta de dados, pois é o setor que lida diretamente com o
tratamento das regras do negócio e com o sistema de gestão da informação utilizado pela
empresa; Foi neste setor onde a possibilidade de investigação e estudo se deu com maior
expressão, pois nele todos os problemas que ocorrem no gerenciamento da Organização
(principalmente os que estão relacionados com o fluxo de informações) tornam-se evidentes.
Portanto, devido ao fato de que os setores observados forneceram as bases investigativas
da pesquisa, a principal ferramenta utilizada foi a pesquisa de campo e a observação direta dos
19
processos relacionados com a origem do fluxo de informações (atendimento) estendendo-se
até ao Centro de Processamento de Dados.
1.5 Organização do trabalho
Este trabalho a partir daqui está dividido em cinco Capítulos da seguinte maneira:
CAPITULO I – DEFINIÇÕES: Aborda a conceituação de termos como Qualidade e
Arquitetura de Software, mostrando diferentes tipos de Arquiteturas com suas respectivas
características. Também identifica como é o Tratamento das Regras e Informações de um
sistema, além de mostrar trabalhos e depoimentos de profissionais do Ramo de Tecnologia da
Informação que adotaram a Tecnologia Multicamadas com sucesso em seus projetos.
CAPÍTULO II – A Modelagem de Desenvolvimento: Aborda de forma resumida a
modelagem da Aplicação a ser implementada, identificando os processos e a representação
gráfica da seqüência de procedimentos.
CAPITULO III – A CONSTRUÇÃO DO MODELO: Capítulo que denota sucintamente e
de forma clara a construção do modelo, utilizando os recursos da ferramenta Delphi e da
Tecnologia COM+, para estruturar a Aplicação Servidora e a Aplicação Cliente.
CAPÍTULO IV - A DISTRIBUIÇÃO DOS SISTEMAS DESENVOLVIDOS COM+:
Tópico que relata a distribuição da Aplicação COM+ desenvolvida, nas amplitudes Servidor e
Clientes, citando alguns fatores que influenciam neste processo, como o Sistema Operacional
utilizado.
CAPÍTULO V – CONCLUSÕES E TRABALHOS FUTUROS: apresenta os resultados a
ser alcançados com a aplicação do modelo proposto, bem como a contribuição e as conclusões
alcançadas.
Por fim são apresentadas as Referências Bibliográficas utilizadas para o desenvolvimento e
embasamento teórico deste trabalho, e em seqüência os anexos.
20
2. CAPITULO I – DEFINIÇÕES
2.1 Introdução
Este capítulo aborda algumas definições importantes, conceitos de Qualidade de
Software, Arquitetura de Software e suas classificações, os principais meios de Tratamento
das Regras de uma Organização, além de ilustrar trabalhos relacionados ao tema.
2.2 Qualidade de Software
Quando se fala em qualidade de software, muitos entendem que é algo com que se deve
começar a se preocupar depois que o código é gerado. Isto está errado. “A preocupação coma
qualidade de software deve existir durante todo o processo de Engenharia de Software”
(PRESSMAN, 1995).
Outro ponto importante a se esclarecer é que, no caso de software, a produtividade não
pode ser analisada isoladamente. “Sem o devido acompanhamento em paralelo da qualidade
do produto, a velocidade de produção é pouco significativa” (FENTON, 1997).
Segundo Pressman, a qualidade de software é:
A conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo sistema profissionalmente desenvolvido (PRESSMAN, 1995).
A qualidade de software é uma combinação complexa de fatores que variarão de acordo
com diferentes aplicações e clientes que as solicitam. A definição acima apresentada enfatiza
três importantes pontos:
• Os requisitos de software são a base a partir da qual a qualidade é medida. A falta e
conformidade aos requisitos significam falta de qualidade;
21
• Padrões especificados definem um conjunto de critérios de desenvolvimento do
software. Se os critérios não forem seguidos, o resultado será quase com certeza a falta de
qualidade;
• Mesmo que o software esteja adequado aos seus requisitos explícitos, se deixar de
cumprir seus requisitos implícitos (boa manutenibilidade, por exemplo), a qualidade será
suspeita.
2.3 A Arquitetura de Software
A formalização da arquitetura como importante recurso para o desenvolvimento de
software começou com Mary Shaw e David Garlan com a publicação do livro “Software
Architecture. Perspectives on an Emerging Discipline”, em 1996 (SHAW, 1996). A
necessidade de várias visões e vários níveis de abstração na modelagem dos requisitos que
serão implementados era percebida pelos projetistas, mas não registradas até então. Com esta
formalização, surge também o papel do arquiteto de software.
A definição clássica de arquitetura apresentada por Shaw (SHAW, 1996) diz que
“arquitetura de software define o que é o sistema em termos de componentes computacionais e
os relacionamentos entre estes componentes”.
Semelhante a esta definição, Bass (BASS, 1998) diz que arquitetura de software “é a
estrutura que inclui componentes, suas propriedades externas e os relacionamentos entre eles,
constituindo uma abstração do sistema”. Esta abstração suprime detalhes de componentes que
não afetam a forma como eles são usados ou como eles usam outros componentes, auxiliando
o gerenciamento da complexidade.
Para Jazayeri (JAZAYERI, 2000), a arquitetura de software é colocada como uma
ferramenta para lidar com a complexidade do software e enfatizam que “arquitetura deve
satisfazer os requisitos funcionais e não funcionais do sistema, incrementando a definição de
que arquitetura de software é o conjunto de componentes e seus relacionamentos”. Portanto, é
possível notar que a arquitetura é mais do que a descrição dos componentes que a compõem e
do relacionamento entre eles. “A arquitetura é a interface entre duas partes distintas: o
problema de negócio e a solução técnica” (ASTUDILLO, 1998).
Mesmo com a execução rigorosa das fases de engenharia de requisitos e de análise,
segundo Pressman (PRESSMAN, 2001) a experiência na construção de sistemas mostra que
22
ainda existe uma lacuna de informações a serem especificadas para prosseguir com a fase de
projeto. Isto significa que especificar e modelar o que o sistema deve fazer não é suficiente
para saber como o sistema deve ser estruturado e organizado para satisfazer os requisitos
funcionais e os atributos de qualidade.
Em uma definição mais formal, uma arquitetura de software é a principal parte do
projeto de uma aplicação, mostrando como as partes que compõem o sistema interagem; onde
ocorrem essas interações e quais são as principais propriedades destas partes, dando assim uma
descrição que serve para a análise e avaliação do sistema. Uma arquitetura pode ser descrita
como sendo a “configuração dos componentes que constituem um sistema e das conexões que
coordenam as atividades entre estes componentes” (ABOWD, 1996). A arquitetura de
software é considerada uma ponte entre a análise de requisitos e a codificação.
Além das responsabilidades citadas, a arquitetura provê uma visão global do sistema,
permitindo assim ter-se a idéia se o sistema satisfaz certos requisitos e sugerir um modelo para
a construção e composição do mesmo.
A arquitetura tem vários papéis dentro do processo de desenvolvimento de sistemas
(ABOWD, 1996), entre eles: “o entendimento, o reuso, a construção e evolução, a análise e
administração”.
• Entendimento: facilita e simplifica a compreensão do sistema, pois exibe uma
abstração de alto nível do mesmo.
• Reuso: pode-se fazer o reuso em vários níveis, desde simples componentes a
frameworks, nos quais os componentes estão integrados.
• Construção: fornece um esqueleto inicial para o desenvolvimento, mostrando os
principais componentes e as dependências entre eles.
• Evolução: a arquitetura pode expor de forma mais clara a dimensão do sistema,
separando os conceitos de funcionalidade dos meios pelos quais os componentes estão
conectados, distinguindo explicitamente componentes e mecanismos. Esta clara separação
concebe uma evolução fácil, pois permite mudanças em mecanismos de conexão, sem perda
de performance, interoperabilidade, etc.
• Análise: permite checagem de consistência, conformidade das restrições impostas
pelo estilo arquitetural, conformidade da qualidade dos atributos, análise de dependência e
análise de domínio.
• Administração: no processo de desenvolvimento de software, a arquitetura da uma
idéia clara dos requisitos, estratégias de implantação e riscos em potencial.
23
O desenvolvimento de uma arquitetura de software é um fator determinante para o
sucesso de um sistema, porém na maioria das vezes não são utilizados métodos apropriados
para a construção das arquiteturas. Recentemente, as arquiteturas de software começaram a
surgir como um importante campo de estudo, onde é abordada a pesquisa em linguagens de
descrição arquitetural, reuso de arquiteturas, padronização, ambientes de desenvolvimento
arquitetural, entre outros. Uma comunidade crescente de pesquisadores está focando seus
estudos nas arquiteturas, alguns em estilos particulares como o orientado a objetos, “pipelines”
ou sistemas cliente servidor, outros abordando o tópico de uma forma mais ampla (SHAW,
1996).
2.3.1 Arquitetura Monolítica
Com a promessa de que a Internet iria revolucionar o mundo da tecnologia de
informação, surgiu uma visão de que todo aplicativo deveria ser centrado na Web. Isso
impulsionou a utilização do modelo de três camadas, onde a apresentação, as regras de
negócio e o armazenamento dos dados estão divididos em três partes com suas funcionalidades
bem definidas. “Para conseguir maior flexibilidade as três camadas podem ser ainda mais
segregadas, dando origem à arquitetura multicamada” (PEDRON, 2003).
Uma aplicação desenvolvida utilizando essa arquitetura é dividida em componentes de
acordo com sua funcionalidade que podem, ou não, estar em máquinas separadas. Segundo
(BOND, 2003) “Aplicativos monolíticos são softwares que possuem toda sua funcionalidade
em um único módulo, grande e normalmente de difícil manutenção”. São encontrados
normalmente em computadores de grande porte ou em um computador pessoal independente,
onde toda a entrada do usuário, verificação, lógica do negócio e acesso a dados encontra-se em
um mesmo local. Neste tipo de arquitetura, alterações em alguma parte do código poderão
produzir erros em alguma outra parte da aplicação que, aparentemente, não está relacionada.
Esse tipo de arquitetura pode ser melhor visualizado na Figura 1.
Figura 1: Aplicação monolítica (PEDRON, 2003).
24
2.3.2 Arquitetura em Duas Camadas
Em arquiteturas do tipo cliente/servidor ou arquiteturas de duas camadas (Figura 2), a
idéia é fornecer para múltiplos usuários o acesso aos mesmos dados sendo que em uma das
camadas ficariam a lógica da apresentação e a de negócios enquanto que na outra ficaria o
acesso a dados (PEDRON, 2003). Para que esse tipo de estrutura pudesse ser montado, surgiu
a necessidade de se converter sistemas legados em sistemas gerenciados por bancos de dados,
por isso houve a necessidade de se ter uma máquina gerenciadora de banco de dados separada,
pois a idéia era de que vários usuários pudessem ter acesso aos mesmos dados.
Figura 2: Arquitetura Cliente/Servidor (PEDRON, 2003).
Essa arquitetura proporciona certa escalabilidade3 e flexibilidade uma vez que o acesso a
dados é realizado de forma independente. Porém, devido ao fato de que o cliente é quem
possui a lógica de negócio e da apresentação, qualquer mudança em alguma destas camadas
obrigará que a alteração seja feita em todos os clientes. Outra desvantagem é que uma
aplicação Web e uma desktop, não podem utilizar à mesma regra de negócio fazendo com que
ocorram duplicações de regras.
2.3.3 A Arquitetura Multicamadas (n-tier)
3 De acordo com (RODRIGUES, 2002) a Escalabilidade permite que muitos usuários ou estações clientes sejam adicionados ao sistema sem que haja perda de desempenho significativa, tornando o sistema capaz de suportar um número infinitamente maior de computadores em rede.
25
Para resolver os problemas da arquitetura cliente/servidor, é possível separar a regra de
negócio da regra da apresentação, criando assim mais uma camada. Este modelo divide o
aplicativo em três camadas distintas: lógica de apresentação, lógica de negócios e lógica de
acesso a dados - conforme Figura 3.
Figura 3: Arquitetura com três camadas (PEDRON, 2003).
Esta arquitetura permite que cada uma das partes possa ser alterada independentemente.
Segundo Pedron:
A separação das regras de negócio da apresentação, através da introdução de mais camadas físicas, torna possível criar interfaces com o usuário com base em HTML, interfaces gráficas ou até mesmo para dispositivos móveis, podendo acessar a mesma lógica de negócio na camada física intermediária. A lógica de apresentação poderá ter mais camadas lógicas para atender a diferentes tipos de usuários. Estas camadas normalmente são chamadas de camada Web e aplicação, estendendo este modelo para n camadas (PEDRON, 2003).
Para Thomas e Fox (FOX, 1999), a idéia de programar em camadas é fundamentalmente
uma idéia de separação; “diferentes serviços disponibilizados pelo programa, classificados por
sua função, são desenvolvidos separadamente”. Integrados que estão no mesmo corpo, e
organicamente dispostos, nivelados pela distância a que se encontram dos dois extremos – o
usuário de um programa de computador e as informações que este último pretende acessar –
tais serviços recebem o nome de camadas.
Segundo Jorge A. Espinosa (ESPINOSA, 2000) a idéia de programar em camadas
consiste em “utilizar um método de desenvolvimento para os sistemas que permite aos
desenvolvedores separa-los em camadas distintas”.
Para Espinosa (ESPINOSA, 2000) na arquitetura three-tier (três camadas) as camadas
recomendadas são: A interface com o usuário, as regras de negócio e a base de dados.
Segundo Jacques Philippe Sauvé (SAUVÉ, 2000) nesta arquitetura tem-se a camada de
apresentação (interface gráfica), a camada de aplicação (business logic) e a camada de dados.
26
Este autor ainda sustenta que os problemas de manutenção foram reduzidos, pois mudanças
nas camadas de aplicação e de dados não necessitam de novas instalações no desktop. Ele
ainda deixa bem claro que as camadas são lógicas, portanto, fisicamente, várias camadas
podem executar na mesma máquina e normalmente há separação física das máquinas.
Um exemplo bastante claro e de aplicação comum em nossos dias, são as chamadas lojas
virtuais, sites onde se pode escolher e comprar produtos. Trata-se de um tipo de programa que
pode ser dividido nas seguintes partes (camadas): as páginas em que há interação com o
usuário (interface); os algoritmos de cálculo e procedimentos de programação (regras do
negócio) e o armazenamento das informações (banco de dados).
A Figura 4, ao mesmo tempo em que ilustra o conceito de programação em camadas, da
a possibilidade de comparação com a famosa arquitetura cliente/servidor (Client-Server), onde
apenas os dados eram concentrados num servidor, permanecendo instaladas nas estações de
trabalho (clientes) as regras de negócio e a interface com o usuário que, neste modelo, são uma
só coisa.
No modelo de camadas vê-se claramente a segregação, aqui representada até por mais
um elemento de hardware, mas que na verdade simboliza apenas a abstração lógica de
funcionalidades.
Figura 4 – Modelo Cliente-Servidor e Modelo de Camadas (FOX, 1999).
27
Vale destacar que o cliente simbolizado na figura pode ser tanto um programa desktop
(instalado na máquina do usuário) quanto um site da Internet, hospedado em qualquer
provedor.
De acordo com o Portal N-tier (endereço eletrônico bastante referenciado por
desenvolvedores em: <http://n-tier.com>), Programas particionados em camadas permitem ao
desenvolvedor gerenciar, programar e melhorar cada parte de forma totalmente independente.
Uma Arquitetura de Sistemas Aplicativos Multicamadas organiza o software em camadas,
onde cada camada é construída acima de outra camada mais geral. Uma camada pode ser
definida como sendo um conjunto de sistemas com o mesmo grau de generalidade. Quanto
mais baixa a camada, mais gerais são os componentes. O número de camadas, seus nomes e
seus conteúdos não são fixos, mas variam caso a caso. Costuma-se chamar a camada mais alta
de Camada do Sistema Aplicativo de camada de Apresentação (Presentation). A camada
seguinte contém aqueles componentes utilizados para construir os Sistemas Aplicativos e é
denominada de Camada das Regras de Negócio (Business Logic), a qual implementa os passos
individuais que definem os maiores processos de negócios que conduzem a organização. Por
fim, temos a Camada de Gerenciamento do Banco de Dados (Data) que é responsável por
manter informações consistentes e seguras com um bom desempenho, conforme mostra a
Figura 5, a seguir.
Figura 5 – Estrutura lógica da Arquitetura Multicamadas. (RODRIGUES, 2002).
28
A abordagem da Arquitetura Multicamadas, segundo Elmanova (ELMANOVA, 2000),
“dá-nos uma capacidade de abstração e encapsulamento das regras de negócio impossível na
tradicional estrutura Cliente-Servidor”. De fato, a abstração é uma técnica analítica para
dividir um sistema em vários níveis de detalhe. Por outro lado, o encapsulamento é o processo
de combinar informação e comportamento em uma nova entidade chamada de objeto. Assim, a
programação orientada a objetos insere-se nesse tipo de abordagem como ferramenta básica
para implementar as regras de negócio em componentes.
De acordo com a revista on-line da Unicamp (Encontrada em:
http://www.revista.unicamp.br) “O advento de arquiteturas three-tier e n-tier revolucionou a
computação distribuída”. Isso porque os objetos encapsulam os atributos, que podem ser
manipulados e examinados, e o comportamento, composto por operações e métodos, e que é
definido pela tipologia do objeto. Os tipos possuem relacionamentos de um para outro, que são
mostrados por diferentes tipos de generalizações, associações e dependências. Uma classe é a
realização ou implementação de um tipo. Um componente é um tipo ou classe desenhado,
documentado e empacotado para ser reutilizado por todos os sistemas da corporação.
Desta forma, de acordo com Ana Paula B. Costa (COSTA, ?), “uma aplicação de
negócio, por mais simples que seja, divide-se tradicionalmente em quatro camadas:
Apresentação, Aplicação, Negócio e Dados“.
� Apresentação: lida com a interface entre a aplicação e os usuários ou entre a
aplicação e outros sistemas. Trata-se de uma aplicação comum desenvolvida utilizando
qualquer plataforma de desenvolvimento (Ex.: Browser – Navegador de Internet) que seja
capaz de acessar a camada de Regras;
� Aplicação: lida com o processamento específico de um sistema;
� Negócio: também chamada de Camada de Regra de Negócio ou Camada
Intermediária, é responsável por encapsular a complexidade do ambiente coorporativo,
fornecendo de forma simples recursos para a construção da camada cliente e integração com
Sistemas Legados. Os componentes dessa camada são hospedados no lado servidor,
necessitando de um servidor de aplicações para a execução dos mesmos.
� Dados: lida com o armazenamento e a recuperação das informações de uma empresa.
O aprendizado obtido com este trabalho indica que a arquitetura de software propõe
várias atividades que tentam suprir esta distância entre as fases de análise e projeto, dentre elas
a elaboração de um modelo multicamadas com o objetivo de ressaltar o tratamento das regras
29
de negócio e da informação, a identificação das dependências de construção e o mapeamento
dos requisitos que o sistema deve atender.
2.4 Trabalhos relacionados ao uso da Arquitetura Multicamadas
Segundo Anderson Haertel Rodrigues (RODRIGUES, 2002 p.304), no Brasil existem
muitos casos onde a tecnologia Multicamadas foi usada obtendo sucesso. Isso é mostrado
através de depoimentos onde os autores são profissionais destaque de suas respectivas áreas
(Analistas, Desenvolvedores ou Consultores), e dão seu relato pessoal da produção e utilização
de Sistemas profissionais.
Dentre estes relatos, está o de Emerson Facunte (RODRIGUES, 2002 p.306) que conta
como foi o desenvolvimento de um projeto de TimeSheet realizado em 2001 a pedido do
Diretor Administrativo e Financeiro do grupo DE Rosa Vitório de Rosa. Neste projeto foram
adotados de inicio o Banco de Dados SQL Server7, Delphi5 como ferramenta de
desenvolvimento, e BDE como tecnologia de acesso a dados. Era um Sistema onde os
Advogados e Consultores do grupo debitavam suas horas, enquanto o setor financeiro emitia a
fatura. O Sistema Operacional na época da implantação era o Windows NT, e a camada de
negócios foi desenvolvida utilizando a tecnologia DCOM. Posteriormente o negócio da
empresa foi tomando grandes dimensões, então foi adotada a integração com o Sistema
Operacional Linux, recompilando a camada de Apresentação. A camada de negócios foi
melhorada com a tecnologia CORBA4 dando uma possível integração com EJB (Entity Java
Beans), uma espécie de objeto de objeto de negócios. O projeto foi finalizado em Maio de
2002, com os seguintes módulos de distribuições:
Tabela 1: Dados da Aplicação de Facunte - um projeto de TimeSheet (RODRIGUES, 2002).
Banco de Dados FireBird (O SQL Server saiu dos planos) Servidores Três servidores configurados com Linux Conectiva,
comportando o Banco de Dados, camada de negócios e camada de Apresentação. Um servidor Microsoft Windows 2000 Server para o Exchange.
Softwares Utilizados Apache Server 1.3 MTORB (http://www.millennium-group.ru/) OpenORB (openorb.sourceforge.net) para testes JDK 1.3.1(java.sun.com) para o ORB
4 Common Object Request Broker Architecture (RODRIGUES, 2002).
30
Delphi 5 Software proprietário para testes remotos.
Registros no Banco 2 milhões em Maio 2002 (com a migração de informações desde 1987)
Registros / Dia 16000 a 20000 Usuários / Dia 7000 – entre consultores, advogados e clientes
Média de Usuários
Concorrentes
500 e pico de 1200
Facunte ainda finaliza seu relato dizendo que utilizar a aplicação distribuída foi ótimo
devido à excelente desempenho, permitindo ainda escalar em dois servidores diferentes.
Foram realizados diversos teste de performance nos servidores, todos com resultados muito
bons.
Segundo Rodrigues (RODRIGUES, 2002 p.309) outro importante uso da Tecnologia de
Desenvolvimento Multicamadas, relatada por Roberto Capra Neto (Analista de Sistemas
especialista em projetos multicamadas) que foi implantado em uma companhia de gás. A
principio existia a necessidade de criar o sistema coorporativo e de controle de logística. Eles
deveriam ser integrados de forma que sua manutenção fosse relativamente simples para ser
possível acompanhar as constantes mudanças nas regras de negócio. Dessa forma, a terceira
camada poderia trazer a vantagem de modular a atualização destas regras apenas no servidor
da aplicação, sem precisar trocar os executáveis de cada cliente. Para obter este patamar, foi
solicitada a ajuda de um consultor da Borland para que fosse feita a adaptação do processo de
desenvolvimento à tecnologia COM plus. Foi adotado o modelo Borland Socket Server para
gerenciar as portas e threads de usuários no servidor de aplicação, e nas máquinas clientes foi
instalada uma DLL para finalizar a arquitetura de acesso. Como banco de dados, a Aplicação
Principal utiliza o Oracle, mas também existem algumas que rodam no Banco de dados SQL
Server.
Segundo Roberto Capra Neto com o passar do tempo, as camadas foram projetadas
melhor onde as regras e suas definições foram definidas, assim como os Objetos de interação e
as Interfaces de usuário. O resultado, de acordo com ele foi bom, e ele ainda acrescenta que
em sua opinião a melhor opção para aplicações executáveis em ambientes corporativos é a
utilização de multicamadas. Os prós e contras estão relacionados na Tabela 2:
31
Tabela 2: Prós e Contras relatados por Roberto Capra Neto – Sistema de Controle de Logística (RODRIGUES, 2002).
Prós Contras
Portabilidade: A portabilidade de uma
aplicação comum para COM é bastante
simples. Foi possível modificar aproveitando
métodos e Interfaces.
Facilidade de lidar com pacotes de registros,
pois é possível definir o ClientDataSet e o
número de registros carregados de cada vez,
fazendo uma espécie de paginação dos
registros.
Ganho em performance, visto que o
problema de congestionamento de “gargalo
de rede” é extinto com o uso de clientes
magros.
Algumas vezes foi necessário reiniciar o
Socket Server, por causa não identificada
(rodando no serviço NT/2000).
Menor requisições ao banco de dados, pois
apenas a aplicação Server se comunica com
o Banco, fazendo com que seja possível o
controle de requisições.
Muitas versões até que se encontrou a
estabilidade desejada.
Estes dois importantes relatos dão prova necessária (com aplicações reais) da eficácia de
um software desenvolvido com a tecnologia Multicamadas, e finalizando a análise,
(RODRIGUES, 2002 p.311) ainda publica uma terceira opinião, de Guinter de Bitencourt
Pauli (Profissional certificado Borland Delphi e Kylix) que ilustra com clareza as vantagens do
desenvolvimento Multitier, por ele descritas como sendo: Modularização, Thin–Clients,
Economia com licenças, Escalabilidade, Independência de Linguagens e Balanceamento de
cargas no servidor. Desta forma, podem ser estas vantagens identificadas da seguinte maneira:
- Modularização da Aplicação em Três Camadas (separando a lógica dos negócios das
regras de acesso ao Banco de Dados e de Interface de usuário) possibilitando regras
encapsuladas e dinâmicas em acesso comum a todos os clientes.
- Clientes Magros (Thin-Clients) já que os clientes não processam diretamente as
informações do Banco de Dados, o que torna o processamento bastante leve e a necessidade de
capacidade de processamento relativamente pequena.
32
- Economia de Licenças de Acesso a Bancos de Dados, já que o acesso aos dados em
uma aplicação Cliente/Servidor é feito através das bibliotecas Clientes, e geralmente os
Fabricantes de Bancos cobram por distribuição destas, o que torna o valor bem mais em conta
já que em multitier estas devem ser instaladas apenas na camada intermediária.
- Escalabilidade, pois com multicamadas o software não perde desempenho de acesso
mesmo que aumente o número de clientes acessando.
- Independência de Linguagens – Uma camada de negócios construída no padrão COM+,
por exemplo, pode ser acessada por diversos clientes utilizando diversas linguagens que
possuam suporte COM+, utilizando o mecanismo de Interfaces. Um servidor COM+ pode ser
acessado por aplicações em Delphi, VB, ASP, C, etc.
- Balanceamento de cargas – Um servidor de aplicação pode ser configurado para
automaticamente distribuir as conexões Clientes para outros servidores da Aplicação, tornando
a arquitetura ainda mais escalável.
Outro trabalho interessante, desenvolvido pelo conceituado profissional Julio Battisti
(BATTISTI, 2003) foi o que ele chama de “Portal Corporativo” publicado em 30/05/2003.
Primeiramente ele ilustra com clareza que muitas empresas já deram importantes passos na
busca de maior eficiência, através do uso adequado da TI5. Estas são empresas que já possuem
certo grau de conscientização em relação ao papel da TI e da importância do alinhamento da
equipe de TI em relação aos objetivos e ao negócio da empresa. Normalmente estas empresas
já informatizaram alguns sistemas, normalmente usando o modelo Cliente/Servidor de duas
camadas. Porém alguns erros, por Battisti citados como "graves" são identificados nesta etapa:
a) O modelo Cliente/Servidor é de difícil manutenção, pois as funções de interface e da lógica do negócio são responsabilidades do programa instalado em cada estação de trabalho. Uma simples mudança na interface ou em uma regra da lógica do negócio faz com que seja necessária uma atualização do programa cliente em todas as estações de trabalho da rede da empresa. b) Muitos sistemas foram criados para atender necessidades departamentais e os diversos sistemas existentes não estão integrados. Pior ainda, os vários sistemas utilizam modelos de dados diferentes e, muitas vezes, tecnologias diferentes. Aí, por exemplo, um cliente tem o seu endereço alterado no sistema de contabilidade e a seção de relacionamento com o cliente continua enviando uma mala direta para o endereço antigo. c) Antes de iniciar o processo de informatização não foi feito uma análise e reestruturação dos processos internos. Só existe uma coisa pior do que não usar adequadamente a Tecnologia da Informação: usá-la para informatizar a burocracia de processos mal planejados. Neste caso você somente será capaz de "fazer a besteira" de uma maneira mais rápida (BATTISTI, 2003).
5 Tecnologia da Informação.
33
Para Battisti (BATTISTI, 2003) as tecnologias Web oferecem uma solução satisfatória,
pois são muitos os benefícios da utilização do modelo de desenvolvimento Web. Inicia pela
facilidade na integração dos aplicativos internos da empresa, passando pela possibilidade de
integração com os sistemas dos clientes e fornecedores, através da criação de uma “Extranet”
(Para ele uma rede externa que se comunica com a rede interna). Isso seria possível, então,
evoluindo o modelo antiquado de duas camadas (cliente/servidor) para um modelo
multicamadas. No caso deste artigo, ele fez esta evolução até quatro camadas, para trazer a
tecnologia e o modelo de desenvolvimento Web para dentro da empresa. A partir do uso desse
modelo de desenvolvimento, as empresas conseguem implementar aplicações robustas e
seguras, e ao mesmo tempo fáceis de instalar e manter atualizadas. Porém não podemos
esquecer que existem dezenas, muitas vezes centenas de sistemas baseados em modelos mais
antigos como o Mainframe ou o tradicional modelo Cliente/Servidor. A idéia dos portais
corporativos surgiu a partir da criação dos portais da Internet, tais como o Yahoo, UOL, Terra,
etc. Se estes portais facilitam o acesso do usuário às informações da Internet, porque não
facilitariam o acesso às informações internas da empresa? Julio Battisti ainda acrescenta que à
medida que o Portal Corporativo começa a ter maior aceitação, com o conseqüente aumento
no número de acessos, é possível começar a pensar na migração dos sistemas legados para a o
modelo Web de três camadas. Em muitos casos nem é necessário a migração das aplicações,
apenas fornecer o acesso através do Portal. Um dos principais objetivos do Portal Corporativo
é facilitar o trabalho dos funcionários, disponibilizando as informações e ferramentas que eles
necessitam. Uma expressão que ficou muito famosa, encontrada em muitos artigos, é a
seguinte: "A informação certa, para a pessoa certa no momento certo." Portais bem projetados
e focados nas reais necessidades dos usuários, são capazes de vencer o desafio de fornecer as
informações corretas, quando necessárias, para quem delas precisar.
De fato, o projeto descrito no artigo acima por Battisti (BATTISTI, 2003) identifica que
as possibilidades de ganho com a adoção da tecnologia multicamadas estendem-se além dos
benefícios de performance. Um projeto da amplitude de um portal corporativo pode mudar o
fluxo de informações na organização, de acordo com o livro “Portais Corporativos” (TERRA,
2002), que elabora melhor a idéia e identifica todos os benefícios da adoção desta tecnologia.
34
2.5 O Tratamento das Regras e Informações
Nos sistemas cliente/servidor tradicionais (ou duas camadas) existem três opções com
relação às regras de negócio: colocar junto da interface do usuário, junto do banco de dados ou
mesclar as duas opções. “Nenhuma dessas opções é 100 % boa” (RODRIGUES, 2002). Nesta
arquitetura, de acordo com Rodrigues “A queda de performance no servidor pode ser
facilmente conseguida com o acúmulo de regras ou Constraints, que devem verificar ou
processar."
No caso das Regras junto da interface (que é o mais comum) a possibilidade de se ligar
um componente visual (TDBEdit) diretamente a um campo de uma tabela em um banco de
dados (TTable), é excelente no que diz respeito à velocidade de programação e apresentação
de resultados. Essa é uma técnica muito boa para prototipação e desenvolvimento de pequenos
sistemas, mas traz incômodos enormes quando de trata de sistemas de grande porte. Rodrigues
(RODRIGUES, 2002) afirma ainda que “um trabalho com componentes visuais pode tornar
maior a facilidade de dispersão das regras”, como por exemplo, associar a consistência de
campo ao evento OnExit() de um componente TDBEdit em um momento, e ao evento
OnValidate() do TField em outro momento.
O autor (RODRIGUES, 2002) ainda afirma que entre os maiores problemas que essa
forma de programar acarreta estão ”Dificuldades de manutenção, quedas de performance,
replicação de regras e dificuldade de distribuição”.
� Dificuldades de manutenção – quando trabalhamos com os eventos de
componentes visuais é fácil dispersarmos as regras, tais como associarmos consistência de
campo ao evento OnExit() do TDBEdit em um momento e ao OnValidate() do TField em outro
momento. Obviamente isso causa dores de cabeça no momento da manutenção, e compulsão
ao suicídio caso a manutenção seja feita por outro programador.
� Problemas de performance (aplicação, banco e rede) – é público e notório que a
visão das tabelas de um banco de dados relacional de forma flat, mimetizando um banco não
relacional causa, por si só, um impacto considerável no banco de dados e na rede como um
todo, devido ao grande número de comandos executados e dados retornados. De fato, basta
montarmos uma pequena aplicação, com um TDBGrid ligado a uma tabela no InterBase, por
exemplo, e observarmos o log gerado pelo SQL Monitor após algumas inserções e edições, é
assustador !
35
� Replicação das regras – todas as aplicações que atualizam os dados de uma
determinada tabela terão que replicar as mesmas regras e restrições que se aplicam a esta
tabela.
� Dificuldade de distribuição – sempre que uma regra é alterada o programa tem
que ser redistribuído, trazendo problemas de controle de versão e distribuição física do
aplicativo e seus complementos.
Como exemplo desse último item, imagine um ambiente com 300 usuários. Acabamos
de desenvolver uma aplicação que vai ser distribuída para esses 300 usuários (com BDE e
etc.). Após uma duas semanas de instalações foi descoberto erro grave no código que nos
obriga a redistribuir tudo. Mais duas semanas e é lançada uma nova versão do BDE ou do
transporte nativo do banco que melhora a performance de nossa aplicação consideravelmente...
Enfim, podemos cair em situações tão inadmissíveis quanto inevitáveis.
No caso das regras junto dos dados, segundo (RODRIGUES, 2002), colocamos as regras
dentro do banco de dados, usando os recursos nativos do banco de dados (triggers, stored
procedures e constraints), “estamos automaticamente ligando nossa aplicação ao banco de
dados que estiver sendo usado, aumentando muito o re-trabalho caso a aplicação venha a ser
convertida para ser usada com outro banco de dados”.
Tipicamente isso não é um problema considerável para a maioria das empresas, uma vez
que a mudança de um banco de dados é uma operação complexa por si só, e que não pode
ocorrer frequentemente. No entanto, quem desenvolve em ambiente cliente/servidor enfrenta
esse problema em maior ou menor grau, dependendo da complexidade e da forma de projetar
os programas.
Ainda em relação a essa forma de programar, pesa o estigma das restrições impostas
pelas linguagens nativas dos bancos, que geralmente são direcionadas e otimizadas para a
manipulação de dados, e não para situações genéricas e algoritmos complexos, obrigando o
programador a “costurar” para superar as deficiências, em particular no que se refere à
depuração do código e tratamento de exceções. Como pontos positivos, restam questões
relativas ao ganho de desempenho na manipulação dos dados e a centralização do código que
facilita a atualização após a manutenção, e garante a segurança do modelo de dados.
36
Ainda existe o caso onde parte das regras está na interface e parte junto dos dados.
Rodrigues afirma que:
Este é o modelo mais facilmente encontrado atualmente e é uma tendência natural. Quando bem aplicado é um modelo eficaz e pode atender a várias situações e ambientes. No entanto carrega os estigmas da dificuldade de manutenção, dificuldade de distribuição e falta de portabilidade (RODRIGUES, 2002).
2.6 Considerações Finais
Este capítulo veio abordar e ilustrar principalmente o conceito e a importância da
Arquitetura de Software, além de mostrar como é importante saber planejar o tratamento das
Regras e Informações em uma Organização, para que os possíveis benefícios sejam
alcançados.
37
3. CAPÍTULO II – A Modelagem de Desenvolvimento
3.1 Introdução
Este capítulo é o início do Estudo de caso, e apresentará a estruturação e representação
lógica do modelo a ser desenvolvido em conjunto ao módulo de sistema que a ele deverá ser
agregado. Este módulo se refere a um sistema de Simulações de Parcelamento, e é utilizado
pela empresa quando não se tem o contato direto com o Cliente Inadimplente (telefone),
havendo a necessidade de contato via correspondência.
3.2 A modelagem UML
A UML6 é uma linguagem de modelagem para o desenvolvimento de sistemas
orientados a objetos. Ela define uma notação que consiste em elementos e gráficos que podem
ser usados em modelos UML, “com ela é possível fazer uma modelagem visual de maneira
que os relacionamentos entre os componentes do sistema sejam mais bem visualizados,
compreendidos e documentados” (BOND, 2003).
Os Diagramas de Seqüência, por exemplo, (BOND, 2003). “são os diagramas que dão
idéia de como as instâncias irão interagir em uma situação real”. Além disso, os diagramas de
seqüência modelam esse tipo de comportamento. Esses diagramas fazem isso mostrando
objetos e as mensagens que passam entre esses objetos. A modelagem visual orientada a
objetos tem um padrão simples e robusto para especificar e descrever a grande maioria das
funções, relacionamentos e técnicas de desenvolvimento orientado a objetos.
3.2.1 Análise de Requisitos para o Modelo
a) Requisitos de Usuário
São requisitos de usuário para o modelo a ser implementado:
6 Unified Modeling Language.
38
• Possibilidade de utilizar múltiplas janelas, sem a perda de performance;
• Necessidade de Interfaces simples na aplicação Cliente, na camada de
apresentação, para melhor interação;
• O Sistema necessita validar os dados do Usuário que está acessando, do Cartão, e
posteriormente os dados Financeiros;
• O Sistema irá calcular as parcelas da simulação automaticamente;
• O Sistema irá emitir o relatório.
b) Requisitos de Software
• Segurança na transação de Informações, caso haja algum imprevisto, como a
queda de energia;
• Escalabilidade para suportar um número crescente de usuários;
• Performance para atender as necessidades de todos nos horários de maior fluxo de
informações;
• Manutebilidade, para as constantes mudanças nas Regras de Negócio.
3.2.2 Diagrama de Contexto.
U M G
S Ó E
U D S
Á U T
R L O
I O R
O
Dados do Cliente(cartão, conta, código)
Dados do usuário e da franquiaDados do usuário e da franquia
Dados do Serviço (parâmetros, funções)Informações solicitadas
Dados complementares( financeiros)
Retorno e cálculo de valores
Parâmetros para extração de informações
Validação
Validação de loginValidaçãode login
Informações de perfis de clientes
Termo de simulação de Parcelamentos
Relatórios impressos
Relatórios impressos
Confirmação para impressão
Confirmação para impressão
Figura 6: Diagrama de Contexto do Módulo Proposto
39
O Diagrama representado pela Figura 6 se trata do modelo que indica as principais
operações desempenhadas na conversação entre as Entidades Externas e o Módulo em si,
identificando também as principais informações e operações que irão sair e entrar no sistema.
3.2.3 Diagrama de Casos de Uso.
Figura 7: Diagrama de Casos de Uso do Módulo
A Figura 7 representa o diagrama de Use-Cases do Módulo, onde um Ator denominado
Usuário insere primeiramente os dados do Login (nome de usuário e senha) para o processo
ACESSAR_SISTEMA, que irá cuidar da validação de seus dados e da permissão de acesso.
Depois o Ator Usuário novamente insere no sistema dados do Cliente, que também serão lidos
e validados. Os dados Financeiros serão buscados automaticamente pelo sistema, que após
esta operação, calcula e retorna na tela o valor das parcelas para a visualização do Usuário.
Após este retorno, o sistema estará pronto para emitir o relatório final para o Usuário.
40
3.2.4 Diagramas de Seqüência
Figura 8: Diagrama de seqüência do Login.
O Diagrama representado pela Figura 8 ilustra como o Ator Usuário se relaciona com o
processo de validação e Login de acesso, procedimento que irá garantir ou não seu acesso no
sistema com base nos dados de entrada e parâmetros de conexão.
Figura 9: Diagrama de seqüência: Validação dos dados pessoais e Financeiros.
41
O Diagrama representado pela Figura 9 mostra como o Ator Usuário, ao inserir a
informação do cliente (cartão), da condições para que o sistema possa validar os dados do
cliente, assim como as informações financeiras, para que no final seja retornado o valor das
parcelas.
Figura 10: Diagrama de seqüência: Impressão dos relatórios.
O Diagrama representado pela Figura 10 deixa evidente como o sistema, ao classificar o
tipo de pessoa a qual pertence o cliente, gera o produto final de seus procedimentos – o
Acordo de Parcelamento impresso na tela.
3.2.5 Especificação de Processos
� Nome do Processo: Validar Login Usuário.
� Processo: 1.
� Entrada: Nome de usuário e senha de usuário.
� Saídas: Confirmação de Login de usuário, exibição formulário principal.
Usuário solicita acesso ao sistema enviando NOME_DE_USUÁRIO e SENHA.
Verificação do sistema:
42
Se NOME_DE_USUÁRIO já estiver cadastrado E SENHA for válida para aquele usuário
Então
Permitir acesso – exibir formulário principal.
Senão
Enviar mensagem de erro: ‘Usuário não tem acesso ao Sistema’.
Figura 11: Representação gráfica do processo 1.
� Nome do Processo: Validar Cartão e Retornar dados do Titular.
� Processo: 2.
� Entrada: Número do Cartão.
� Saídas: Confirmação de existência do Cartão, dados do Titular (Nome, CPF ou
CNPJ, Saldo devedor, Meses de Atraso).
Usuário envia o NÚMERO_DO_CARTÃO.
Verificação do sistema:
Se NÚMERO_DO_CARTÃO já estiver cadastrado na base de dados
Então
Retornar Informações Pessoais (Nome, CPF ou CNPJ, Saldo devedor, Meses de Atraso).
Senão
Enviar mensagem de erro: ‘Cartão não encontrado’.
43
Figura 12: Representação gráfica do processo 2.
� Nome do Processo: Calcular Parcelas.
� Processo: 3.
� Entrada: Dados Financeiros (Número de Parcelas, Saldo a Parcelar e Taxa de Juros).
� Saídas: Validação do número de parcelas, Valor de cada parcela.
O Sistema lê as informações financeiras informadas pelo Usuário:
NÚMERO_DE_PARCELAS, SALDO_A_PARCELAR, TAXA_DE_JUROS.
Verificação do sistema:
Se NÚMERO DE PARCELAS maior que o permitido pela Organização
Então
Enviar mensagem de erro: ‘O número de parcelas é inválido’.
Senão
Retornar Valor de cada Parcela.
44
Figura 13: Representação gráfica do processo 3.
� Nome do Processo: Imprimir Acordo.
� Processo: 4.
� Entrada: Tipo de Pessoa, Remetente, Dados Titular, Dados Financeiros.
� Saídas: Relatório impresso.
O Sistema lê as informações financeiras informadas pelo Usuário: TIPO_PESSOA,
REMETENTE, DADOS_DO_TITULAR, DADOS_FINANCEIROS.
Verificação do sistema:
Se TIPO_PESSOA for igual à FISICA
Então
Imprimir Acordo Pessoa Física.
Senão
Se TIPO_PESSOA for igual à JURIDICA
Então
Imprimir Acordo Pessoa Física.
45
Figura 14: Representação gráfica do processo 4.
A Figura 14 mostra o fluxograma do processo 4, como forma de visualização de seus
passos, até o alcance do Impresso que corresponde ao Acordo de Parcelamento que será
enviado pelos correios para o Cliente, como possível renegociação de sua dívida.
46
3.3 Diagrama de Entidades e Relacionamentos DER
Figura 15: Diagrama DER contendo as principais tabelas da Base de Dados.
O diagrama DER representado na Figura 15 se refere às tabelas acessadas pelo módulo
do estudo de caso deste, construído com programação Orientada a Objetos, que acessará
informações de tabelas como: _cartao, _contrato, _saldo, _cadastro e outras.
3.4 Considerações Finais
Este capítulo abordou a representação dos processos de software, promovendo a
visualização do funcionamento do sistema que será implementado, detalhando-o em processos
e mostrando como será a interação destes procedimentos com o usuário.
47
4. CAPITULO III – A CONSTRUÇÃO DO MODELO
4.1 Introdução Este capítulo irá especificar a construção do modelo de sistema multicamadas proposto,
utilizando a ferramenta Delphi7, os conceitos de Programação Orientada a Objetos e a
Tecnologia COM+. O modelo será composto de uma parte Cliente e outra parte Servidora,
totalizando, portanto, a programação de dois projetos unidos entre si. As especificações serão
passadas de forma minuciosa, para promover o fácil entendimento dos procedimentos de
programação adotados.
4.2 O SERVIDOR COM+
A programação do Servidor será feita com base no protocolo COM+. Antes de iniciar a
construir um Sistema desta categoria, quero deixar evidente que é necessário ler sobre o
arquivo de licenças dos componentes ADO7 no site da Borland (Site da criadora da Ferramenta
Dephi encontrado em: <http://www.borland.com>). No caso do ADO, não é preciso se
preocupar pois se trata de licença livre.
O Servidor da Aplicação será montado no chamado Transactional Data Module, que no
Delphi7 se encontra no menu: file/new/other/multitier.
7 ActiveX Data Objects.
48
Figura 16: O Diálogo da opção Multitier no Delphi.
Após criar o Transactional Data Module (vide Figura 16), a Co-Classe do projeto deverá
ser nomeada e o projeto conterá o DataModule vazio, esperando os componentes que farão
parte do Servidor da Aplicação. Então o projeto deverá ser salvo, com as Units, de preferência
em um diretório separado. Neste momento também é gerado um arquivo com o nome do
projeto acrescido da sigla “TLB.pas” que é onde se encontram as declarações da Type library,
isto é, as Interfaces que o Delphi utilizará. Este arquivo não será manuseado diretamente, para
manter o controle de seu código de programação deverá ser usada a opção: view/type library.
Acessando esta opção teremos o que se pode ver na Figura 17 seguinte:
Figura 17: A Type Library.
49
Nesta Type Library (TLB) poderá ser identificada a Interface e a Co-classe que são
definidas na etapa inicial. Usando esta TBL, o Delphi irá determinar quais os objetos serão
declarados, assim como as Interfaces que poderão ser utilizadas expostas no Servidor da
Aplicação. Parâmetros, métodos, Interfaces e Objetos, serão controlados por aqui. Observando
o arquivo DPR, que se trata do projeto, será possível identificar algo semelhante à Figura 18:
Figura 18: Fontes do arquivo DPR.
Estas quatro declarações que já existem, contém alguns parâmetros essenciais como:
DllGetClassobject que é uma chamada onde através dela será carregado o servidor da aplicação na memória , a DllCanUnloadNow que descobre se é possível que o Sistema operacional seja capaz de descarregar o Servidor para indicar que o sistema está ou não em uso na memória, DllRegisterServer que registra o servidor no Sistema Operacional e a função DllUnregisterServer que procura remover as entradas criada no registro do Windows. (RODRIGUES, 2002).
A Aplicação Servidora terá como função fundamental definir os parâmetros de acesso ao
banco de dados. O componente que será utilizado para iniciar este processo é o
ADOConnection, que será colocado no Remote Data Module (RDM) criado de acordo com a
Figura 19:
50
Figura 19: O Data Module com o ADOConection.
O RDM é u objeto COM em formato de Data Module, que irá utilizar os recursos
necessários para formar as três camadas. Nele poderão ser inseridas as regras de negócio, seja
um cálculo de Juros ou até o controle de acesso à base de dados.
Com um duplo clique no componente ADOConnection, serão acessadas as opções para
definir os parâmetros de conexão, que variam de acordo com o Sistema de Gerenciamento de
Banco de Dados (SGBD), ou simplesmente Banco de Dados (BD) utilizado. Neste caso, o
principal parâmetro a ser configurado é a string de conexão. Feito isso, a propriedade do
ADOConnection chamada “LoginPrompt” deve ser colocada como “false” e a propriedade
“Connected” como “true”. Os parâmetros de acesso, portanto, devem estar conforme a Figura
20:
Figura 20: Object Inspector do Delphi mostrando a Conexão realizada com sucesso.
Agora, no evento Oncreate( ) do RDM, deverá ser escrito o código (Figura 21):
51
Figura 21: Evento Oncreate( ) do RDM.
Aqui os dados já começam a ser controlados de uma forma mais objetiva, pois a string de
conexão poderá ser definida com base em um arquivo INI. O melhor a se fazer é criar um
objeto para ler o arquivo INI e encapsular as regras de acesso no servidor. A opção Pooled,
indica que o nosso Objeto RDM garante que, “quando muitos clientes requisitarem serviços de
forma simultânea, haja ganho em desempenho pois o COM+ guardará algumas instancias dos
objetos para uso posterior, otimizando os recursos” (RODRIGUES, 2002).
Após este processo, a próxima tarefa será registrar o Servidor Com+ no Windows. Para
que isso aconteça deve ser acessada a opção: Run/Install COM+ Objects após a compilação do
projeto (vide Figura 22).
Figura 22: Instalando o Servidor COM+.
52
Escolha a partir daí a guia “Install into new Application”, e em “Applicationa Name”
defina o nome da aplicação. Clicando em ok o servidor estará criado e poderá ser acessado na
ferramenta Administrativa “Serviços de componentes” do Windows, ilustrada na Figura 23.
Figura 23: Servidor COM+ nos Serviços de Componente do Windows.
4.3 O CLIENTE COM+
O módulo do Cliente COM+, se trata de um programa “normal” em Delphi com os
componentes de acesso ao protocolo COM+. Portanto, do lado do Cliente haverá os
componentes de comunicação, que podem ser, por exemplo, DCOMConnection,
ConnectionBroker, SharedConnection e ClientDataSet. O que fica no Servidor da Aplicação
são os componentes ADO e o DatasetProvider. Em primeiro momento, deverá ser
implementado um formulário de login, lembrando que os componentes de conexão agora
fazem parte da camada das regras de negócio, e por não estarem mais do lado do cliente, não
poderão ser acessados de forma direta. É ai que o papel da Interface se torna importante, pois
deverá ser possível passar dois parâmetros (no caso nome e senha) para que o Login seja
validado, onde o método retornará “true” ou “false”, permitindo acessar ou não.
53
Para trabalhar com a implementação do lado Cliente e do lado Servidor
simultaneamente, é necessário utilizar o recurso do Delphi chamado Project Manager,
acessado pelo atalho CTRL+ALT+F11 ou pelo menu View/Project Manager. Após isso,
aparecerá a tela ilustrada na Figura 24 seguinte:
Figura 24: Visão do Project Manager do Delphi.
O Servidor COM+ que representa a camada terciária trata-se de uma DLL (Dynamically
Linked Library) que poderá ser acessada remotamente ou por todas as interfaces de
comunicação. Neste caso, a intenção é criar um Cliente representado por um executável
(“.EXE”). No Project Manager, com o botão auxiliar do mouse (botão direito) é possível
adicionar um novo projeto. Feito isso deverá ser escolhida a opção “Application” para
adicionar a aplicação desejada. Então, será criado o chamado Grupo de Projetos, onde há dois
projetos que poderão ser trabalhados de forma simultânea (observe a Figura 25).
Figura 25: Criando o novo projeto no Project Manager.
54
O projeto novo poderá ser salvo em diretório diferente, e o Grupo de Projetos permitirá
acessar os dois projetos ao mesmo tempo. Sempre que no Project Manager uma opção estiver
em negrito, significa que o projeto está selecionado. Então, sempre que for trabalhar no
projeto, o arquivo que deverá ser reaberto será o Project Group, ou seja, o Grupo de Projetos
que tem a extensão “.BPG” (Ilustrado na Figura 26).
Figura 26: Project Manager com os dois Projetos.
Agora através da Opção File/New/Data Module deverá ser criado um Data module
simples, onde será inserido o componente DCOMConnection e o ConnectionBroker. A
propriedade “connection” do Broker deve apontar para o DCOMConnection. A Figura 27
ilustra a aparência deste Data module.
Figura 27: Data module com os componentes de conexão.
55
Observe que a propriedade “ServerName” deve ser igual ao nome da aplicação
Servidora, que neste caso se chama ServerCOMPlus, além do nome da classe:
Server_COMPlus, resultando na String de conexão: “ServerCOMPlus.Server_COMPlus”.
Para verificar se a comunicação está perfeita, basta alterar a propriedade “Connected” do
ConnectionBroker para verdadeira (vide Figura 28). Se tudo estiver correto, a leitura do
arquivo INI que contém a String de conexão será realizada sem falhas.
Figura 28: DCOM Cliente conectado com suas propriedades.
Feito o teste, o próximo passo é programar os eventos OnCreate e OnDestroy do DM. O
evento OnCreate deve conter o seguinte código: “CBrokerConexao.Connected:=true;”. O
evento OnDestroy deve conter o seguinte código: “CBrokerConexao.Connected:=false;”.
Observe a abstração de conexão existente, pois em nenhum momento foi citado o
DCOMConnection.
O Form de login, que será uma Interface de acesso ao banco de dados, nos indicará como
será controlado o acesso através da passagem dos parâmetros de entrada (Figura 29).
Figura 29: O Formulário de Login.
56
A Unit deve ser salva e os componentes nomeados. Após isso deverá ser criado mais um
Formulário com o nome “FPrincipal.pas”. Estas Units devem estar no diretório do projeto
cliente. Desta maneira no projeto cliente, existirá um DM, o Form login e o Form Principal. O
Form Login não deve ser do tipo “autocreate”, pois sua criação deverá ser chamada em tempo
de execução. Para que isso seja possível, as opções do projeto devem estar conforme a Figura
30:
Figura 30: Opções do Projeto Cliente.
O Formulário de login será criado no próprio projeto. O código pertinente a esta
operação é descrito na Figura 31:
57
Figura 31: Código fonte do arquivo DPR.
Este código mostra a criação do formulário de Login que é chamado com o comando
“ShowModal” para evitar que o usuário acesse uma outra tela enquanto ele estiver aberto.
Agora o Formulário de login está pronto para ser criado, porém ainda não possui a
implementação necessária: a Interface que deve ser criada no Servidor da Aplicação para
permitir ou negar acesso ao sistema.
4.4 CONTINUANDO O DESENVOLVIMENTO – ALTERNANDO ENTRE SERVIDOR E CLIENTE
Sempre que for necessário, haverá inevitavelmente de acontecer a alternância entre os
dois projetos. Isso pode ser feito como dito antes, através do gerenciador de projetos (Project
Manager) do Delphi.
58
Agora na Aplicação do Servidor, um novo método deverá ser criado sobre a interface
IServer_COMplus através do clique com o botão direito do mouse, escolhendo a opção
New/Method. O nome do novo método será “Login_BD”, conforme a Figura 32 a seguir:
Figura 32: Método Login_BD na Type Library.
Após criar, é necessário definir os parâmetros de entrada e saída do método. O de saída
será do tipo WordBool e os parâmetros de entrada, UserName e PassWord serão ambos do tipo
WideString. Nesta parte o Delphi auxilia bastante e o processo de criação de métodos se torna
bastante simples. Após definir os parâmetros, é necessário clicar no botão Refresh
Implementation da Type Library e salvar tudo.
O método que acaba de ser criado está declarado em dois lugares: RDMConexão e
ServerCOMPlus_TLB, ambos no servidor da aplicação. A implementação do método que está
em RDMConexão será conforme a Figura 33:
59
Figura 33: A implementação do Método Login_BD.
Depois, com o projeto já salvo, é necessário registrar a DLL através da opção
Run/Register ActiveX Server. Caso haja algum problema com este processo, significa que é
necessário tirar a DLL do ar, pois não poderá ser registrada se estiver em uso. Para isso deve-
se ir até os Serviços de Componente do Windows, conforme a Figura 34:
60
Figura 34: Tirando o Serviço COM+ do ar usando o recurso Component Services.
Com a DLL devidamente registrada, falta implementar, de maneira convencional, os
botões Ok e Cancelar no formulário de Login. Antes, o formulário precisa ter acesso ao DM de
conexão e ao formulário principal da aplicação, para isso, é preciso incluir estes no uses da
seção Implementation (verificar Figura 35).
61
Figura 35: Códigos do formulário de Login.
O principal código se encontra no if, onde esta sendo usado o conceito de abstração já
mostrado com o componente Connection Broker. Através dele, chama-se o método Login_Bd
os parâmetros são passados, referentes ao nome de usuário e senha, através das propriedades
text dos dois Edits do formulário de login.
O código do botão cancelar, é usado para finalizar a execução da aplicação.
Agora a conexão e a chamada do método podem ser testadas, executando a aplicação
cliente com a DLL devidamente pré-registrada. Caso sejam digitados usuário e senha
incorretos, o resultado será o da Figura 36:
62
Figura 36: Login não confirmado no Formulário de acesso.
Caso seja informado o nome de usuário correto, assim como a senha de acesso, aparecerá
a tela indicada na Figura 37 seguinte:
Figura 37: Login efetuado com sucesso.
63
O código de Login não tem maiores recursos, como número máximo de tentativas de
acesso, porém o objetivo foi alcançado: mostrar a criação do método Login_Bd e o acesso
através da Interface no Servidor da Aplicação.
O passo seguinte é criar usando Programação Orientada a Objetos, os demais métodos
que irão compor as regras de negócio e a camada intermediária, para isso será necessário
encapsular estas regras mais uma vez, criando mais um Remote Data Module (RDM). Este
último deve estar conectado no RDM de conexão. Então entra em cena mais um recurso de
programação oferecido pelo Delphi para promover a conversação das camadas. Uma série de
implementações deve ser feita com cuidado. Existem exemplos no Delphi de como funciona
este processo, estes podem ser acessados no diretório (DELPHI)\Demos\Midas\SharedConn.
Até então existe no servidor da Aplicação apenas um RDM: o de conexão com o banco
de dados. Para criar mais um com o objetivo de encapsular as demais regras, será utilizada a
opção File/New/Other/Multitier e a opção escolhida deverá ser o Transactional Data Module.
O novo RDM se chamará DRMTabelas, as propriedades de criação serão:
� CoClass name= RDMTabelas;
� Threading Model=Both;
� Transactional Model=Requires Now.
A propriedade Pooled deve essencialmente ser igual a True. Neste RDm será colocados
os componentes ADODataSet (guia ADO) e um DataSetProvider (guia Data Acess).
Estes componentes devem ser renomeados para ADODtStTabelas e DtStPrvdrTabelas
simultaneamente. Após isso deverá ser iniciada a ligação entre os RDMs. Em File/ Use Unit,
deve ser indicada a opção para usar o RDMConexao. Depois disso o RDMTabelas
“enchergará” a outra Unit. Salvando a nova Unit, agora é a vez de mudar a propriedade Data
Set do DtStPrvdrTabelas para ADODtStTabelas. Também deve ser ligado o RDMConexao ao
RDMTabelas através do Use Unit, para que se comuniquem reciprocamente.
Agora é a vez de trabalhar na Type Library novamente. Neste momento a Interface e a
CoClasse referentes ao RDMTabelas já foram criadas. O que deve ser feito ainda á a Interface
de ligação entre as duas Interfaces (a do RDMConexao e a do RDMTabelas). Clicando em
New Interface, a Interface deverá ser criada e nomeada. Após isso dera criada através da opção
NewProperty/ Read-Write uma propriedade que possui, na verdade duas partes: a de entrada e
a de saída da Interface. O nome destas novas duas propriedades deverá ser exatamente
RDMTabelas (observar Figura 38).
64
Figura 38: A nova Interface e as propriedades Read e Write.
Agora o atributo type de ambas as propriedades deverá ser indicado como
IServer_COMplus. A propriedade Parent Interface da Interface IChildTabelas deve ser igual a
IAppServer.
Após isso é selecionada a interface IServer_COMPlus que se encontra como a primeira
Interface do Type Library e deve ser incluída uma propriedade do tipo Read-Only através de
New property. Seu nome deve ser RDMtabelas e seu Type deve ser indicado para
IRDMTabelas e por último a Interface IRDMTabelas deve ter seu atributo Parent interface
apontado para IChildTabelas. Agora deve ser dado um Refresh Implementation e Salvar tudo.
Após todas as ligações e declarações se olhar a Unit RDMTabelas na seção protected
poderá ser notado a existência de uma nova functions e uma nova procedure com as seguintes
declarações conforme a Figura 39:
Figura 39: Nova Função e Procedimento declaradas em RDMTabelas.
65
Também será necessário criar uma variável na seção private com o nome e tipo:
“FIServer_COMPlus: IServer_COMPlus”, onde IServer_COMPlus é a inteface implementada
no RDMConexao. Esta, portanto é a variável de referência para a Interface.
Após isso, também é necessário na declaração var antes do bloco implementation criar a
variável que será a fábrica de Classe, que armazena o objeto. A Figura 40 ilustra como deverá
ficar o código:
Figura 40: Nova Variável que apoiará a Class Factory (Fábrica de Classe).
Também devem ser implementadas a função e a procedure declaradas na seção protected
(Figura 41).
Figura 41: Implementação da função GET e procedimento SET.
Por último o código da seção initialization deve ser modificado, passando a ser igual à
Figura 42:
Figura 42: O uso da variável RDM_TabelasFactory que irá receber as informações da Interface e da CoClasse do TRDMTabelas.
66
O próximo passo é mudar para a Unit RDMConexao onde falta um detalhe, que é
implementar a função GET_RDMTabelas da seguinte maneira, conforme a Figura 43:
Figura 43: A implementação da função Get_RDMTabelas.
A maior parte do trabalho está feita. As classes estão referenciadas e os RDMs se
comunicam. Está criada a base da camada de negócios que irá abrigar todos os métodos que
representam as Regras de Negócio a encapsular. Após tanto trabalho é consideravelmente
necessário salvar o ProjectGroup e todas as modificações. Após isso, deve ser executado um
Build All no projeto Servidor e, logo após, Run/ Register ActiveX Server. Deve aparecer na tela
a confirmação, de que o Servidor representado por um arquivo com a extensão “.DLL”8 foi
registrado com sucesso.
Figura 44: Confirmação do Registro do Servidor COM+.
Todos os métodos e variáveis criados auxiliam as Interfaces e CoClasse da Type Library.
A idéia é criar referências de Interfaces e apontar o retorno dos Objetos COM para as mesmas.
Cada RDM trata-se, portanto de um Objeto COM.
4.5 FINALIZANDO: O CLIENTE COM+ E AS REGRAS
O formulário da aplicação cliente FPrincipal tem o objetivo de simular, neste caso, uma
proposta para parcelamento de dívida. Na empresa estagiada, trata-se de uma aplicação que 8 Lembrando que a sigla DLL significa “Dinamically Linked Library” de acordo com (CANTU, 2002).
67
não depende do Software de Gestão. Esta pequena aplicação é bastante utilizada todos os dias,
e apesar de ser bastante simples, denota toda a pretensão deste projeto para realizar a operação
acima descrita com a arquitetura multicamadas.
O Layout do formulário deve fica da seguinte maneira, conforme descrito na Figura 45:
Figura 45: Layout do formulário principal.
Neste formulário devem ser adicionados, portanto:
� 1 ConnectionBroker chamado CBrokerDados;
� 3 Buttons chamados BtnCalcular, BtnConfirmar e BtnSair;
� 1 RadioGroup chamado RadioGroup1;
� 1 MaskEdit chamado car_cartao;
� 12 Edits para receber os dados e valores;
� 1 ComboBox chamado cb_dias.
Este formulário deve estar ligado ao DMConexao através da cláusula USES, com o
comando ALT+F11.
O componente CBrokerDados deve estar com as propriedades de acordo com a Figura
46.
68
Figura 46: O componente CBrokerDados.
Para que a aplicação funcione, é necessário ir até à aplicação servidora fazer algumas
modificações. No RDMTabelas, é preciso selecionar o componente DtStPrvdrTabelas e mudar
o calor da propriedade Options de:[], para [poPropagateChanges,poAllowCommandText].
Com isso a instrução sql poderá ser passada para o Data Set Provider sem que ele recuse, caso
contrário poderá haver erros.
Sempre que for necessário acrescentar uma nova regra de negócios, será preciso
adicionar um método no servidor. Como exemplo, será ilustrado a regra Busca_cartao. Em
View/Type Library (O projeto servidor deve estar selecionado). O método Busca_cartao deverá
ser adicionado na Interface IServer_COMPlus, e deve ter o parâmetro de entrada “cartao” do
tipo WideString, e terá retorno também do tipo WideString. Este método servirá para validar o
cartão digitado e ainda pesquisar o nome de seu proprietário no sistema.
Para dar seqüência é preciso acrescentar no RDMConexao um componente ADODataSet
com o nome ADODtStGeral. Sua propriedade Connection deve indicar “ADOConBASE”, que
se encontra no próprio RDM. CommandText deve ter seu valor vazio porque os parâmetros
serão passados em tempo de execução, de forma que, seja possível aproveitar o mesmo
componente ADOConBASE
Por possuir um parâmetro de retorno, Busca_cartao é uma função, e sua implementação
está descrita para visualização na Figura 47 que segue:
69
Figura 47: O código da função Busca_cartao.
Observando o código da função nota-se a presença da variável global ‘aspas’, que é do
tipo String e será usada em vários locais da aplicação para montar instruções sql.
Na aplicação cliente, este método será acionado no evento OnExit() do Maskedit que
recebe o número do cartão. Para chamar a função busca cartão, o evento precisará estar com o
código de acordo com a Figura 48.
70
Figura 48: Usando a função Busca_cartao.
A variável LCartao é uma variável declarada globalmente do tipo String;
Agora já é possível testar o funcionamento da Aplicação, fazendo o login e tentando
informar um número de cartão. Caso o número esteja incorreto, será mostrada a mensagem de
alerta, caso o contrário, a função retornará o nome do titular do cartão informado.
Agora as regras de negócio devem ser adicionadas uma a uma, para promover o total
funcionamento da aplicação. Vale lembrar que as regras variam muito de Organização para
Organização, e que elas são de extrema importância para seu funcionamento.
Neste exemplo, foram adicionados ainda outros métodos de busca e validação de dados
na Interface IServer_COMPlus. São eles:
� Busca_saldo: método com o parâmetro de entrada ‘cartao’ do tipo
WideString que retorna o valor do saldo devedor após a execução de instrução SQL,
dado este, do tipo Currency (moeda).
� Busca_meses_atraso: método para calcular a quantidade de meses em atraso
que o cliente se encontra, pois apenas clientes devedores podem ser passíveis de
simulações de parcelamento. Seu parâmetro de entrada é ‘cartao’ do tipo WideString, e
seu retorno é do tipo Inteiro. Se o cliente deve mais de seis meses de atraso, então o valor
6 deverá ser retornado de acordo com as Regras de Negócio da Organização.
� Busca_CPF: Parâmetro de entrada ‘cartao’ do tipo WideString e retorno
também do tipo citado. Esta função busca no banco de dados as informações referentes
ao CPF ou ao CNPJ, de pessoas físicas ou jurídicas. Lembrando que não faz a validação
destes campos, pois a mesma já é feita no momento da inserção dos dados.
71
� Imprime_proposta: Método onde os dados da impressão são passados para
que o relatório, ou seja, a proposta de parcelamento seja impressa. Lembrando que há
alterações entre as propostas de pessoas físicas e jurídicas, totalizando assim dois
relatórios distintos. Não possui parâmetros de saída, pois sua finalidade é imprimir o
relatório na tela.
O componente utilizado para gerar o relatório-proposta foi o Report Builder, porém
poderia ser qualquer outro, que funcionaria da mesma maneira. A seguir, figuras que listam a
implementação dos novos métodos e os novos layouts da Type Library e do formulário
principal.
Figura 49: O layout da TLB, com os métodos da Interface IServer_COMPlus.
A Figura 49 mostra a aparência da TLB e os métodos que foram adicionados, métodos
estes que representam as regras de negócio, e que possuem a validação dos dados e
informações, além de realizar os procedimentos do sistema.
72
Figura 50: O layout do Formulário principal da Aplicação Cliente.
A Figura 50 mostra como ficou a aparência do formulário principal da aplicação cliente,
ilustrando os componentes que foram adicionados e sua organização.
Figura 51: A implementação da função Busca_saldo.
73
A Figura 51 mostra a implementação da função Busca_Saldo ilustrando o código fonte.
Figura 52: A implementação da função Busca_meses_atraso.
A Figura 52 mostra a programação referente à função Busca_meses_atraso, que
retornará o período de atraso do cliente, para que sejam feitos os cálculos financeiros.
Figura 53: A implementação da função Busca_cpf.
A Figura 53 mostra o código da função Busca_cpf, que retornará o número do CPF da
pessoa física ou o CNPJ da pessoa jurídica.
74
Figura 54: A implementação da função calcula_parcela.
A Figura 54 representa a implementação da função calcula_parcela, que após realizar os
cálculos, retorna o valor das parcelas de acordo com os dados do cliente.
A seguir, o código fonte do procedimento Imprime_proposta:
procedure TServer_COMplus.imprime_proposta(const cartao, nome, cpf_cnpj: WideString;
parc_valor: Currency; num_parc: Integer; desconto, saldo_deb, valor_pagar: Currency; const
remetente: WideString; tipo_pessoa: Integer; Entrada: Currency);
var wDia,wMes,wAno : Word; mesExtenso:String;
begin
DecodeDate(NOW, wAno, wMes, wDia);
if wmes=01 then mesExtenso:='Janeiro';
if wmes=02 then mesExtenso:='Fevereiro';
if wmes=03 then mesExtenso:='Março';
if wmes=04 then mesExtenso:='Abril';
if wmes=05 then mesExtenso:='Maio';
if wmes=06 then mesExtenso:='Junho';
if wmes=07 then mesExtenso:='Julho';
if wmes=08 then mesExtenso:='Agosto';
if wmes=09 then mesExtenso:='Setembro';
if wmes=10 then mesExtenso:='Outubro';
if wmes=11 then mesExtenso:='Novembo';
if wmes=12 then mesExtenso:='Dezembro';
if tipo_pessoa=0 then begin
ppDestinatario.Caption := nome;
ppCartao.Caption := cartao;
75
ppCPF.Caption := cpf_cnpj;
ppDebito.Caption := CurrToStr(saldo_deb);
ppEntrada.Caption := CurrToStr(Entrada);
ppNroParc.Caption := IntToStr(num_parc);
ppVlrParc.Caption := CurrToStr(parc_valor);
ppVlrTotal.Caption := CurrToStr(valor_pagar);
ppDesconto.Caption := CurrToStr(desconto);
ppDia.Caption := IntToStr(wDia);
ppMes.Caption := MesExtenso;
ppAno.Caption := IntToStr(wAno);
ppContato.Caption := remetente;
ppProposta_F.Print;
end;
if tipo_pessoa=1 then begin
ppdestinatario1.Caption := nome;
ppCartao1.Caption := cartao;
ppCNPJ.Caption := cpf_cnpj;
ppSaldodevedor1.Caption := CurrToStr(saldo_deb);
ppEntrada1.Caption := CurrToStr(Entrada);
ppNroParcelas1.Caption := IntToStr(num_parc);
ppVlrParcelas1.Caption := CurrToStr(parc_valor);
ppVlrTotal1.Caption := CurrToStr(valor_pagar);
ppDesconto1.Caption := CurrToStr(desconto);
ppDia1.Caption := IntToStr(wDia);
ppMes1.Caption := MesExtenso;
ppAno1.Caption := IntToStr(wAno);
ppContato1.Caption := remetente;
ppProposta_J.Print;
end;
end;
76
Figura55: A Representação do Modelo Implementado.
A Figura 55 vem ilustrar a disposição lógica das camadas das aplicações desenvolvidas,
para possibilitar maior nível de abstração da Arquitetura e de seus componentes.
4.6 Considerações Finais
Neste caso, o modelo até aqui desenvolvido será utilizado para a simulação de
parcelamentos de dívidas de uma instituição financeira administradora de cartões. Na
realidade, este modelo já existia na empresa onde se deu a coleta de dados, e era utilizado em
paralelo ao Sistema de Gestão Principal por todos os usuários do setor de análise e
recuperação de crédito. Isso pode ser um agravante para o uso de uma arquitetura simples,
77
levando em consideração que o setor possui seis usuários e que cada um destes possui o hábito
de trabalhar com três aplicações de gestão abertas simultaneamente (isso além dos módulos
em paralelo). Surge então a rápida necessidade de promover o escalonamento destes sistemas.
Já que migrar um Sistema de grande porte de duas para três camadas é um processo custoso e
demorado, é sumariamente necessário aplicar uma metodologia de desenvolvimento nos
módulos implementados externamente ao programa principal (como o módulo de simulação
de parcelamentos, módulo de análise de crédito, módulo de extração de perfis de usuário
pessoa física, e outros), visando fugir do “gargalo de rede”. O setor de análise e recuperação
de créditos mostrou-se como um excelente exemplo para este estudo, pois com apenas seis
usuários, é responsável pelo acesso de cerca de 30 aplicações simultâneas no servidor de
dados.
78
5. CAPÍTULO IV - A DISTRIBUIÇÃO DOS SISTEMAS DESENVOLVIDOS COM+
5.1 Introdução
A distribuição das aplicações depende de alguns fatores, como o tipo de sistema
operacional implantado e os recursos nele existentes. Portanto, é necessário discorrer sobre
estes fatores, com a única e exclusiva finalidade de promover a implantação do modelo
apresentado com sucesso, sem complicações.
5.2 Sistema Operacional Windows 95
No Windows 95, existe um pequeno problema. O mesmo “não tem o DCOM instalado,
logo será preciso instalar” (CANTÚ, 2002). Isso pode ser feito executando-se o
DCOM95.EXE que se encontra no site da Microsoft, no CD de Instalação do Delphi ou no
Office 2000. Caso seja necessário, os seguintes arquivos devem ser instalados:
ISTMSIA.EXE: Instala o pacote Windows Installer para o Windows 95, permitindo que
sejam executadas imagens de instalação de aplicativos, imagens estas com a extensão MSI.
TREGSVR.EXE OU REGSVR32.EXE: Usado para registrar uma DLL no Sistema
Operacional. Os arquivos acima citados podem ser encontrados no site da Microsoft
(<http://www.microsoft.com>) ou mesmo serem instalados juntamente com o Delphi.
5.3 Windows 98, NT, 2000 e XP
Nestes Sistemas Operacionais, não é preciso fazer muita coisa já que o pacote DCOM já
vem instalado (RODRIGUES, 2002). Mas pode ser necessária a instalação, caso esteja
79
ausente, na versão 98 do Windows. Lembrando que, também a estação Cliente deve estar com
suporte a DCOM habilitado. O mesmo deve ser habilitado através do DCOMCNFG.EXE.
5.4 Exportação do Servidor COM+
Exportar o Servidor da aplicação COM+, é nada mais que instalar o mesmo na máquina
escolhida. Lembrando que poderá ser instalado no Windows NT, 2000 ou XP, pois “estas
versões têm o conceito de serviços e tecnologia que as versões 9x não têm” (RODRIGUES,
2002).
Para tal, deve ser acessado os Serviços de Componentes, que estão dentro das
Ferramentas Administrativas, no Painel de Controle. Nos Serviços de Componentes, o Objeto
COM+ criado chamado Exemplo_COMPlus deve ser selecionado. Depois de selecioná-lo,
com o botão direito do mouse, deve ser escolhida a opção ‘Export’ ou ‘Exportar’. Assim se
terá a Figura 56:
Figura 56: A opção exportar do Objeto COM+.
Após escolher esta opção, aparecerá a tela indicada na Figura 57:
80
Figura 57: A tela inicial do Assistente de Exportação do Objeto COM+.
Após esta tela principal do assistente, aparecerá uma nova tela onde deverá ser
informado o nome do arquivo Servidor COM+. Deverá ser colocado então o nome, e marcada
a opção ‘Aplicativo para Servidor – Instalar este aplicativo em outras máquinas’ de acordo
com a Figura 58:
Figura 58: Exportando o arquivo MSI do Servidor da Aplicação.
81
Após colocar o nome do pacote a ser gerado, clica-se em ‘Avançar’ para chegar ao final
da exportação.
Clicando em concluir, tem-se o pacote de instalação do servidor gerado.
5.5 Exportação com Proxies (Cliente COM+)
Existem vários usos para a palavra Proxy (RODRGUES, 2002). Em geral, é usada para
descrever algo que servirá como intermediário na comunicação entre dois pontos distintos,
sendo que cada ponto imaginará que estará se comunicando diretamente com o outro, sem
saber da existência da camada intermediária.
O Proxy COM+ é o mecanismo que possibilita uma aplicação Cliente, portanto, utilize
os recursos, objetos e Interfaces da aplicação Servidora do COM+ remotamente. A instalação
Proxy será utilizada para instalar o cliente COM+.
O processo de Exportação do Cliente COM+ será iniciado da mesma forma que foi
iniciado o processo do Servidor. Após escolher a opção ‘Exportar’, no menu suspenso do
Objeto COM+ chamado Exemplo_COMPlus, deve ser clicada a opção ‘Avançar’. Tela já
possui a opção ‘Proxy de aplicativo – Instalar em outras máquinas para ativar o acesso a esta
máquina’ habilitada, e, na caixa de texto, deve ser indicado o caminho e o pacote do Proxy
Cliente (Observe Figura 59).
Figura 59: A tela de exportação do Cliente COM+.
82
Após clicar em ‘Avançar’ e posteriormente em ‘Concluir’, no diretório selecionado será
acrescentado o pacote de exportação do Cliente COM+.
5.6 A Instalação em outros terminais – Os Clientes Magros
Agora que já estão em mãos os arquivos MSI do Servidor COM+ e Cliente COM+, o
executável da aplicação, deve se levar em conta o seguinte:
Na máquina que servirá como servidor de Banco de Dados deve ser instalado o Servidor
SGBD do banco de dados (Neste caso o SQL Server).
Na máquina que servirá como o Servidor da Aplicação, deve ser executado o pacote
gerado anteriormente referente ao Servidor COM+ chamado ‘ServExemplo.MSI’. Dessa
forma, automaticamente esta sendo feita a instalação e registro do Servidor COM+. Este
processo é o mais simples possível. Caso a máquina não reconheça o arquivo MSI como um
arquivo do Windows Installer, volto a mencionar que é preciso instalar o ‘ISTMSIA.EXE’,
disponível no site da Microsoft (Disponível em: <http://www.microsoft.com>).
O arquivo de parametrização INI chamado ‘Param.ini’ no mesmo local da aplicação.
Nas estações clientes, também deve estar presente a MIDAS.DLL no diretório
‘C:\WINDOWS\SYSTEM32’.
A melhor maneira para instalar o pacote cliente, seria através da execução do
‘MSIEXEC.EXE’. Este processo registrará o cliente e poderá também indicar a referência de
localização do servidor conforme a seguinte sintaxe:
msiexec – i CliExemplo.msi
remoteservername=NomedoServidordaAplicacao
No lugar do nome do servidor também poderá ser informado o IP do mesmo.
83
Figura 60: Utilizando a Aplicação Cliente.
A Figura 60 mostra a Aplicação após ser instalada, executando e buscando informações
sobre determinado cliente no banco de dados, além de utilizar os métodos implementados para
validar os dados e calcular o valor das parcelas.
5.7 Considerações Finais
Neste capítulo foi visto como distribuir a aplicação desenvolvida com a Arquitetura
Multicamadas usando o protocolo COM+, tanto do lado Cliente quanto do lado servidor.
Também foi possível identificar a facilidade do processo mencionado.
84
6. CAPÍTULO V – CONCLUSÕES E TRABALHOS FUTUROS
6.1 Introdução
Este capítulo irá ilustrar as conclusões obtidas acerca dos principais pontos discutidos,
ilustrando também os possíveis trabalhos futuros advindos do modelo apresentado, além de
analisar sua contribuição.
6.2 Conclusões
Cada desenvolvedor tem em suas mão um aparato de tecnologias e ferramentas que
devem ser utilizadas da melhor maneira possível para resolver problemas e oferecer melhorias.
A principal meta sempre foi garantir a melhoria no acesso aos dados e promover o melhor
controle das regras de negócio, evitando que estas se tornassem dispersas, e que o sistema se
tornasse lento com o aumento do número de acessos aos dados. Portanto, conclui-se que a
Arquitetura Multicamadas de desenvolvimento de sistemas tem muito mais recursos a
oferecer. O desempenho escalável oferecido pelo Pooling de Objetos e pelo suporte a
transações, ambos recursos existentes na tecnologia COM+, é o que torna esta tecnologia tão
especial. Claro que, tal desempenho não pode ser notado em uma rede onde estão conectadas
vinte estações clientes, parecendo ser semelhante à arquitetura de duas camadas. Porém na
atualidade nos deparamos com dados cada dia mais extensos, complexos e necessários. A
velocidade e necessidade de acesso aos dados, são prioridades nos sistemas de gerenciamento.
O famoso gargalo de rede, que atualmente não é ainda tão reconhecido, possivelmente será um
dos grandes problemas do futuro. E o futuro, precisa de informações cada vez em maiores
gamas, e sempre em tempo real de execução, para garantir o diferencial competitivo de uma
85
organização. É provável que daqui alguns anos, ou meses, os problemas de acesso se tornem
muito mais evidentes. Claro que, o uso de estruturas como as Multicamadas, portanto, se
tornará imprescindível, e o advento dos sistemas distribuídos sem dúvidas será (ou já está
sendo) inevitável. CORBA, COM+, JAVA... Não importa a tecnologia utilizada, é apenas uma
questão de tempo. Com este trabalho foi possível identificar como a Arquitetura de um
software pode ser importante, não só em características de disposição. Multicamadas, uma
forma de dispor a aplicação em três ou mais partes, traz muito benefícios. Outro fator não
obstante, uma tendência dos dias atuais adiante, é a integração dos sistemas, entre si e com a
Internet. A independência de linguagem, portanto é mais um fator extremamente importante,
afinal um Servidor COM escrito em Delphi, por exemplo, pode ser acessado por um Cliente
com camadas de apresentação em variadas linguagens (Visual Basic, ASP, C, etc). Fica
também concluído que, a independência com o banco de dados pode ser também mais um
benefício vantajoso, pois uma aplicação que controla as regras de negócio via gatilhos
diretamente no banco de dados, não permitirá a migração para outro banco com facilidade.
Todos estes benefícios, junto com os demais anteriormente citados, mostram como a
Arquitetura Multicamadas é viável e, se bem implementada, pode ser utilizada como um
modelo a ser seguido e utilizado sempre, trazendo benefícios inclusive em relação a outros
processos que utilizam estruturas similares na arquitetura cliente-servidor.
Portanto, o modelo neste projeto construído, é uma base para a implementação de
grandes projetos que estejam na pretensão de adotar a Arquitetura Multicamadas na
estruturação de um Sistema e de seus módulos. É ainda, uma proposta, como forma de mostrar
inicialmente como pode ser vantajoso utilizar sua metodologia para a construção de um
sistema, ou agregação de suas funcionalidades para uma Organização que se preocupa com o
futuro.
6.3 Trabalhos Futuros
Como trabalhos futuros, é possível propor algumas melhorias para o modelo
implementado, como uma Interface integrada à Web Services, por exemplo, e a utilização do
antes mencionado Load Balance. Ambos os recursos não foram desenvolvidos neste projeto,
pois a empresa onde se deu a pesquisa não utiliza Web Services (ainda) e possui apenas um
86
Servidor exclusivo para abrigar a aplicação principal e seus módulos, separadamente de outras
funções (como servidores de e-mail e de Voz sobre IP).
A proposta de implantar a Arquitetura Multicamadas nos Módulos externos ao Sistema é
uma forma de garantir que tudo o que seja feito de um ponto em diante, seja escalável para os
usuários finais. Com a adoção deste modelo, futuramente caso seja necessário, poderia ser
promovida a migração completa dos Sistemas para Multicamadas, pois implementando os
métodos do módulo externo muitas regras de negócio encontram-se então disponíveis para uso
sem a necessidade de nova implementação. A migração de um sistema Cliente/ Servidor para
um sistema Multicamadas pode ser um processo bastante complicado quando se começa sem
nenhuma estrutura inicial. Implementando o modelo apresentado nos Módulos do Sistema,
acha-se uma forma para possibilitar que isso aconteça, e que se queira que isso aconteça, visto
os benefícios e resultados obtidos ao longo do tempo.
87
Bibliografia
ABOWD , G.; KAZMAN ,R.; BASS, L.; CLEMENTS, P., Scenario-Based Analysis of Software Architecture, IEEE Software Novembro 1996, 47-55. APPLETON, Brad. Patterns and Software: Essential Concepts and Terminology. (2000). Disponível em: <http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html>. Acesso em: 25 nov. 2005. ASTUDILLO, Hernán, HAMMER, Stuart. Understanding the Architect’s Job. Software Architecture Workshop of OOPSLA’98, 1998. BARBOSA, Jorge Cavalheiro. Tecnologias Aplicáveis ao Delphi 7. Publicado no Site comunidade de Desenvolvedores Active Delphi. Disponível em: <http://www.activedelphi.com.br/print.php?sid=66 > BATTISTI, Julio. Criando Aplicações em 3, 4 ou n Camadas. Site pessoal deste profissional que é uma referência em desenvolvimento e banco de dados. Publicado em 2003. Encontrado em: <http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp>. Acesso em: 15 jul. 2006. BRASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Pratice. Addison Wesley, 1998. BOND, Martin. Aprenda J2EE em 21 dias. São Paulo: Editora Makron Books, 2003. BORLAND, Site Oficial. Site da Desenvolvedora do Aplicativo Delphi e de diversas outras plataformas, com artigos, links e material grátis para download, Criado em 1994. Encontrado em: <http://www.borland.com/ >. Acesso em: 12 jul. 2006. CABRAL, Adelino Manuel de Oliveira; ARAÚJO, Lúcia Goretti Gonçalves de. UML Unified Modeling Language. Disponível em: <www.mat.ua.pt/disciplinas/mbd/Tutorias/UML/uml1.htm >. Acesso em: 29 jul. 2006. CLEMENTS, Paul; NORTHROP, Linda. Software Architecture: An Executive Overview, CMU/SEI-96-TR-003, Março de 1996. CANTÚ, Marco. Dominando o Delphi 6 – A Bíblia. São Paulo: Makron B, 2002. COSTA, Ana Paula Bonani. Identificação e Descrição de Produtos com Arquitetura N-Tier. Site das Faculdades Associadas de São Paulo em: < http://www.fasp.br/docente/graduacao/ROCHA/trescamadas.htm> ELMANOVA, Natalia. Creating multi-tier information systems using MIDAS. Publicado em Janeiro de 2000. Disponível por WWW em: <http://community.borland.com/article/0,1410,20568,00.html.>. Acesso: 24 de maio de 2006. ESPINOSA J. A., Desenvolvimento de aplicações multi-camadas com VFP e VB, 2000.
88
FENTON, N. E.; PFLEEGER, S. L. Software Metrics: A Rigorous and Practical Approach. London: PWS, 1997. FOX, D. & THOMAS, M.L. Visual Basic 6 Distributed. Coriolis, 1999. JAZAYERI, Mehdi. Software Architecture for Product Families, Addison Wesley, 2000. MACORATTI, José Carlos. UML - Unified Modeling Language e Visual Modeler. Disponível em: <www.macoratti.net/uml_vb.htm>. Acesso em 23 jul. 2006. MCCALL, James. “Quality Factors”, Encyclopedia of Software Engineering, John Wiley & Sons (pp 959-969), 1994. MICROSOFT. Site Oficial da empresa Desenvolvedora do Sistema operacional Windows, com artigos, links e material atualizado grátis para download. Encontrado em: <http://www.microsoft.com/ > N-TIER INC. Portal N-tier – artigos. 2000. Disponível em: <http://n-tier.com/articles.html >. Acesso em: 10 jun. 2006. PAULI, Guinther. Curso de dbExpress e DataSnap em 20 módulos. Site DevMedia Group – 27 de Outubro de 2005, segundo o endereço: <http://www.devmedia.com.br/visualizacomponente.aspx?comp=1184&site=3 >. Acesso em: 22 jun. 2006. PEDRON, Sérgio Luís. Aplicações WEB empresariais: A utilização da Tecnologia Java 2 Enterprise Edition.Monografia (Bacharelado em Ciência da Computação) – Instituto de Ciências Exatas e Geociências, Universidade de Passo Fundo, Passo Fundo, 2003 PFLEEGER, Shari Lawrence. Software Engineering: Theory and Pratice, Prentice Hall, 1998. PRESSMAN, Roger. Engenharia de Software. São Paulo: McGraw-Hill, 1995. PRESSMAN, Roger. Software Engineering: A Practitioner’s Approach, 5ª Edição, McGraw Hill, 2001. RODRIGUES, Anderson Haertel. Sistemas Multicamadas com Delphi DataSnap e DbExpress. Visual Books, 2002. SANTOS, Luiz Gaspar. Objetos Distribuídos. Publicado no Site Revista TI ano de 2000, na URL: <http://www.ibti.com.br/revista/artigos/main_artigo.asp?codigo=56> SHAW, Mary; GARLAN ,David. Software Architecture. Perspectives on an Emerging Discipline, Prentice Hall, 1996. SAUVÉ, J. P. Introdução e Motivação: Arquiteturas em n camadas, 2000.
89
TERRA, José Claudio Cyrineu; GORDON Cindy. Portais Corporativos, Negócio 2003. UNICAMP. Revista Unicamp – Informativos técnicos, artigo Número 61. Publicado em janeiro de 1999, no link: <http://www.revista.unicamp.br/infotec/informacao/inf61.htm > Acesso em: 23 jun. 2006. VASKEVITCH, David. Estratégias Cliente/Servidor: Um Guia para a Reengenharia da Empresa. Berkeley Brasil Editora, São Paulo, S.P., 1995;
90
Apêndice A
Códigos-Fonte do Sistema Cliente.
===============================ClienteCOMPlus.DPR================================ program ClienteCOMPlus; uses Forms, UFrmLogin in 'UFrmLogin.pas' {FormLogin}, UDMConexao in 'UDMConexao.pas' {DMConexao: TDataModule}, UFrmPrincipal in 'UFrmPrincipal.pas' {FPrincipal}; {$R *.res} begin Application.Initialize; Application.CreateForm(TDMConexao, DMConexao); Application.CreateForm(TFPrincipal, FPrincipal); FormLogin:= TFormLogin.Create(nil); try FormLogin.ShowModal; finally FormLogin.Free; FormLogin := nil; Application.Run; end; end. ===============================UDMConexao.pas================================ unit UDMConexao; interface uses SysUtils, Classes, DBClient, DB, MConnect; type TDMConexao = class(TDataModule) DCOMConexao: TDCOMConnection; CBrokerConexao: TConnectionBroker; procedure DataModuleCreate(Sender: TObject); procedure DataModuleDestroy(Sender: TObject); private { Private declarations } public { Public declarations } end; var DMConexao: TDMConexao; implementation {$R *.dfm} procedure TDMConexao.DataModuleCreate(Sender: TObject); begin CBrokerConexao.Connected:=true; end; procedure TDMConexao.DataModuleDestroy(Sender: TObject); begin
91
CBrokerConexao.Connected:=false; end; end. ===============================UFrmLogin.pas================================ uses UDMConexao, UFrmPrincipal; {$R *.dfm} procedure TFormLogin.bb_okClick(Sender: TObject); begin IF NOT DMConexao.CBrokerConexao.AppServer.Login_Bd(EdtUsuario.Text, EdtSenha.Text) then MessageDlg('Usuário não tem acesso ao Sistema',mterror,[mbOk],0) else begin FormLogin.Hide; FPrincipal.Show; end; end; procedure TFormLogin.bb_cancelaClick(Sender: TObject); begin Application.Terminate; end; end. ===============================UFrmPrincipal.pas================================ unit UFrmPrincipal; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Menus, DB, ADODB, ppModule, raCodMod, ppCtrls, ppBands, ppStrtch, ppRichTx, jpeg, ppPrnabl, ppClass, ppCache, ppComm, ppRelatv, ppProd, ppReport, StdCtrls, ExtCtrls, Buttons, CurrEdit, Mask, wwDialog, wwidlg, DBClient, MConnect, DBCtrls,Math; type TFPrincipal = class(TForm) Panel1: TPanel; Label24: TLabel; Label32: TLabel; Label33: TLabel; Label34: TLabel; Bevel2: TBevel; Label35: TLabel; Label36: TLabel; Label37: TLabel; Label38: TLabel; Label39: TLabel; Label41: TLabel; SaldoAtual: TCurrencyEdit; Desconto: TCurrencyEdit; Apagar: TCurrencyEdit; ac_entrada: TCurrencyEdit;
92
NroParcela: TCurrencyEdit; ValorEmprestimo: TCurrencyEdit; BtnCalcular: TButton; ValorParcela: TCurrencyEdit; BtnConfirmar: TBitBtn; BtnSair: TBitBtn; cb_dias: TComboBox; RadioGroup1: TRadioGroup; Edit1: TEdit; Label17: TLabel; car_cartao: TMaskEdit; CBrokerDados: TConnectionBroker; MesesAtraso: TCurrencyEdit; Edit2: TEdit; Label1: TLabel; Label2: TLabel; Edit3: TEdit; Label3: TLabel; taxa: TCurrencyEdit; procedure BtnSairClick(Sender: TObject); procedure FormKeyPress(Sender: TObject; var Key: Char); procedure car_cartaoExit(Sender: TObject); procedure FormCreate(Sender: TObject); procedure FormClose(Sender: TObject; var Action: TCloseAction); procedure DescontoExit(Sender: TObject); procedure ac_entradaExit(Sender: TObject); procedure cb_diasExit(Sender: TObject); procedure BtnCalcularClick(Sender: TObject); procedure BtnConfirmarClick(Sender: TObject); private public { Public declarations } end; var FPrincipal: TFPrincipal; LCartao: string; implementation uses uDMConexao; {$R *.dfm} procedure TFPrincipal.BtnSairClick(Sender: TObject); begin close; end; procedure TFPrincipal.FormKeyPress(Sender: TObject; var Key: Char); begin if Key = CHR(13) then begin Key := CHR(0); SelectNext(ActiveControl,True,True); end; if Key = CHR(27) then begin
93
Key := CHR(0); SelectNext(ActiveControl,False,True); end; end; procedure TFPrincipal.car_cartaoExit(Sender: TObject); var meses:Integer; begin LCartao := Trim(car_cartao.Text); while Length(LCartao)<16 do LCartao:='0'+LCartao; if DMConexao.CBrokerConexao.AppServer.busca_cartao(LCartao)<>'' then begin Edit2.Text:= CBrokerDados.AppServer.busca_cartao(LCartao); Edit3.Text:= CBrokerDados.AppServer.busca_cpf(LCartao); meses:= CBrokerDados.AppServer.busca_meses_atraso(LCartao); meses:=meses div 30; mesesAtraso.Value := meses; SaldoAtual.Value:=CBrokerDados.AppServer.busca_saldo(LCartao); end; end; procedure TFPrincipal.FormCreate(Sender: TObject); begin CBrokerDados.Open; end; procedure TFPrincipal.FormClose(Sender: TObject; var Action: TCloseAction); begin CBrokerDados.Free; action:=cafree; end; procedure TFPrincipal.DescontoExit(Sender: TObject); begin Apagar.Value := (SaldoAtual.Value * -1) - Desconto.Value; end; procedure TFPrincipal.ac_entradaExit(Sender: TObject); begin ValorEmprestimo.Value := Apagar.Value - ac_entrada.Value; end; procedure TFPrincipal.cb_diasExit(Sender: TObject); var nro_dias:integer; taxav:real; begin nro_dias:=strtoint(cb_dias.Text); taxav:=taxa.Value; if nro_dias > 0 then ValorEmprestimo.Value := (APagar.Value * (1 + ((taxav * (nro_dias) / 30) / 100))) - ac_entrada.Value else
94
begin if ac_entrada.Value > 0 then ValorEmprestimo.Value := APagar.Value - ac_entrada.Value else ValorEmprestimo.Value := APagar.Value; end; btnConfirmar.Enabled := False; end; procedure TFPrincipal.BtnCalcularClick(Sender: TObject); Var SaldoAParcelar, SaldoNaEntrada,taxav: Double; nro_dias:integer; begin if ((NroParcela.Value < 1) or (NroParcela.Value > 12)) then begin MessageDlg('O número de parcelas deve ser entre 1 e 12.', mtConfirmation, [mbOk], 0); exit; end; nro_dias:=strtoint(cb_dias.Text); taxav:=taxa.Value; if nro_dias = 0 then SaldoNaEntrada := APagar.Value else SaldoNaEntrada := APagar.Value * (1 + (taxav * (nro_dias) / 30) / 100); SaldoAParcelar := SaldoNaEntrada - ac_entrada.Value ; ValorEmprestimo.Value := SaldoAParcelar ; ValorParcela.Value:=CBrokerDados.AppServer.calcula_parcela(SaldoAParcelar,taxav,(NroParcela.Value)); btnConfirmar.Enabled := True; ValorEmprestimo.Enabled := False; ValorParcela.Enabled := False; end; procedure TFPrincipal.BtnConfirmarClick(Sender: TObject); begin if (edit1.Text='') then begin showmessage('Informe o nome do remetente'); exit; end; CBrokerDados.AppServer.imprime_proposta(LCartao,Edit2.Text,edit3.Text, ValorParcela.Value,strtoint(NroParcela.Text),Desconto.Value, SaldoAtual.Value,Apagar.Value,Edit1.Text,RadioGroup1.ItemIndex,ac_entrada.Value ); end; end.
95
Apêndice B
Códigos-Fonte do Sistema Servidor.
===============================ServerCOMPlus.DPR================================ library ServerCOMPlus; uses ComServ, ServerCOMPlus_TLB in 'ServerCOMPlus_TLB.pas', RDMConexao in 'RDMConexao.pas' {Server_COMplus: TMtsDataModule} {Server_COMplus: CoClass}, RDM_Tabelas in 'RDM_Tabelas.pas' {RDMTabelas: TMtsDataModule} {RDMTabelas: CoClass}; exports DllGetClassObject, DllCanUnloadNow, DllRegisterServer, DllUnregisterServer; {$R *.TLB} {$R *.RES} begin end. ===============================RDM_Tabelas.pas================================ unit RDM_Tabelas; {$WARN SYMBOL_PLATFORM OFF} interface uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, ComServ, ComObj, VCLCom, StdVcl, bdemts, DataBkr, DBClient, MtsRdm, Mtx, ServerCOMPlus_TLB, Provider, DB, ADODB; type TRDMTabelas = class(TMtsDataModule, IRDMTabelas) ADODtStTabelas: TADODataSet; DtStPrvdrTabelas: TDataSetProvider; procedure DtStPrvdrTabelasBeforeUpdateRecord(Sender: TObject; SourceDS: TDataSet; DeltaDS: TCustomClientDataSet; UpdateKind: TUpdateKind; var Applied: Boolean); private { Private declarations } FIServer_COMPlus: IServer_COMplus; protected class procedure UpdateRegistry(Register: Boolean; const ClassID, ProgID: string); override; function Get_RDMTabelas: IServer_COMplus; safecall; procedure Set_RDMTabelas(const Value: IServer_COMplus); safecall; public { Public declarations }
96
end; var RDMTabelas: TRDMTabelas; RDM_TabelasFactory: TComponentFactory; implementation uses RDMConexao; {$R *.DFM} class procedure TRDMTabelas.UpdateRegistry(Register: Boolean; const ClassID, ProgID: string); begin if Register then begin inherited UpdateRegistry(Register, ClassID, ProgID); EnableSocketTransport(ClassID); EnableWebTransport(ClassID); end else begin DisableSocketTransport(ClassID); DisableWebTransport(ClassID); inherited UpdateRegistry(Register, ClassID, ProgID); end; end; function TRDMTabelas.Get_RDMTabelas: IServer_COMplus; begin Result:=FIServer_COMPlus; end; procedure TRDMTabelas.Set_RDMTabelas(const Value: IServer_COMplus); begin FIserver_Complus :=value; end; procedure TRDMTabelas.DtStPrvdrTabelasBeforeUpdateRecord(Sender: TObject; SourceDS: TDataSet; DeltaDS: TCustomClientDataSet; UpdateKind: TUpdateKind; var Applied: Boolean); begin // aqui nao implementei nada pois nao houve inserção de dados end; initialization // TComponentFactory.Create(ComServer, TRDMTabelas, // Class_RDMTabelas, ciMultiInstance, tmBoth); RDM_TabelasFactory:= TComponentFactory.Create(ComServer, TRDMTabelas,CLASS_RDMTabelas,ciMultiInstance,tmBoth); end. ===============================RDMConexao.pas================================ unit RDMConexao; {$WARN SYMBOL_PLATFORM OFF} interface uses
97
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, ComServ, ComObj, VCLCom, StdVcl, bdemts, DataBkr, DBClient,math, MtsRdm, Mtx, ServerCOMPlus_TLB, DBXpress, DB, SqlExpr, ADODB,inifiles, ppModule, raCodMod, ppCtrls, ppBands, ppStrtch, ppRichTx, jpeg, ppPrnabl, ppClass, ppCache, ppComm, ppRelatv, ppProd, ppReport,ppViewr,DateUtils; type TServer_COMplus = class(TMtsDataModule, IServer_COMplus) ADOConBASE: TADOConnection; ADODtStGeral: TADODataSet; ppProposta_F: TppReport; ppProposta_J: TppReport; ppHeaderBand3: TppHeaderBand; ppLabel3: TppLabel; ppImage7: TppImage; ppDetailBand3: TppDetailBand; ppShape1: TppShape; ppRichText5: TppRichText; ppAno: TppLabel; ppMes: TppLabel; ppCartao: TppLabel; ppNroParc: TppLabel; ppVlrParc: TppLabel; ppDestinatario: TppLabel; ppDia: TppLabel; ppContato: TppLabel; ppDebito: TppLabel; ppDesconto: TppLabel; ppEntrada: TppLabel; ppLabel1: TppLabel; ppCPF: TppLabel; ppLabel8: TppLabel; ppVlrTotal: TppLabel; ppFooterBand3: TppFooterBand; ppLine1: TppLine; ppLabel2: TppLabel; ppLabel4: TppLabel; ppLabel5: TppLabel; raCodeModule3: TraCodeModule; ppHeaderBand4: TppHeaderBand; ppLabel24: TppLabel; ppImage3: TppImage; ppDetailBand4: TppDetailBand; ppShape2: TppShape; ppRichText3: TppRichText; ppAno1: TppLabel; ppMes1: TppLabel; ppCartao1: TppLabel; ppNroParcelas1: TppLabel; ppVlrParcelas1: TppLabel; ppdestinatario1: TppLabel; ppDia1: TppLabel; ppContato1: TppLabel; ppSaldodevedor1: TppLabel; ppDesconto1: TppLabel; ppEntrada1: TppLabel; ppLabel36: TppLabel; ppCNPJ: TppLabel; ppLabel11: TppLabel;
98
ppVlrTotal1: TppLabel; ppFooterBand4: TppFooterBand; ppLine6: TppLine; ppLabel38: TppLabel; ppLabel39: TppLabel; ppLabel40: TppLabel; raCodeModule4: TraCodeModule; procedure MtsDataModuleCreate(Sender: TObject); procedure ppProposta_FPreviewFormCreate(Sender: TObject); procedure ppProposta_JPreviewFormCreate(Sender: TObject); private FBancoConectado : boolean; protected class procedure UpdateRegistry(Register: Boolean; const ClassID, ProgID: string); override; function Login_BD(const UserName, PassWord: WideString): WordBool; safecall; function Get_RDMTabelas: IRDMTabelas; safecall; function busca_cartao(const cartao: WideString): WideString; safecall; function busca_saldo(const cartao: WideString): Currency; safecall; function busca_meses_atraso(const cartao: WideString): Integer; safecall; function busca_cpf(const cartao: WideString): WideString; safecall; procedure imprime_proposta(const cartao, nome, cpf_cnpj: WideString; parc_valor: Currency; num_parc: Integer; desconto, saldo_deb, valor_pagar: Currency; const remetente: WideString; tipo_pessoa: Integer; Entrada: Currency); safecall; function calcula_parcela(saldo_parcelar: Currency; taxav: Double; nroParcelas: Integer): Currency; safecall; public ini:TextFile; FDataMain : TAdoConnection; function LerArquivo(Arquivo: String) : String; property BancoConectado : boolean read FBancoConectado write FBancoConectado; end; var Server_COMplus: TServer_COMplus; aspas:string; implementation //Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Supercard;Data Source=USER\USUARIO //Provider=SQLOLEDB.1;Password=123456;Persist Security Info=True;User ID=acesso;Initial Catalog=Supercard;Data Source=USER\USUARIO uses RDM_Tabelas; {$R *.DFM} class procedure TServer_COMplus.UpdateRegistry(Register: Boolean; const ClassID, ProgID: string); begin if Register then begin inherited UpdateRegistry(Register, ClassID, ProgID); EnableSocketTransport(ClassID); EnableWebTransport(ClassID); end else begin DisableSocketTransport(ClassID);
99
DisableWebTransport(ClassID); inherited UpdateRegistry(Register, ClassID, ProgID); end; end; procedure TServer_COMplus.MtsDataModuleCreate(Sender: TObject); begin LerArquivo('E:\MONO\PARAM.INI'); end; function TServer_COMplus.LerArquivo(Arquivo: String): String; begin if not FileExists(Arquivo) then begin showmessage('O Arquivo de conexões deve estar no diretório E:\MONO\PARAM.INI Verifique.'); exit; end; end; function TServer_COMplus.Login_BD(const UserName,PassWord: WideString): WordBool; var fConfig : TIniFile; sStrBD : string; begin fConfig := TIniFile.Create('E:\MONO\PARAM.INI'); try sStrBD := fConfig.ReadString('AGS','DATASOURCE','USER\USUARIO'); finally fConfig.Free; end; Self.BancoConectado := False; try with ADOConBASE do begin LoginPrompt:=false; Connected :=false; //aqui a string de conexão ------- ADOConBASE.ConnectionString := 'Provider=SQLOLEDB.1;' + 'Password='+PassWord+';' + 'Persist Security Info=True;' + 'User ID='+UserName+';' + 'Initial Catalog=Supercard;' + 'Data Source=' + sStrBD ; //-------------------------------- Connected:=true; Self.BancoConectado := TRUE; Result:=true; end; except Result:=false; // end; end; end; function TServer_COMplus.Get_RDMTabelas: IRDMTabelas; begin Result:= RDM_TabelasFactory.CreateCOMObject(nil) as IRDMTabelas; Result.RDMTabelas:=self;
100
end; function TServer_COMplus.busca_cartao( const cartao: WideString): WideString; begin aspas:=''''; with ADODtStGeral do try ADODtStGeral.close; CommandText:= 'select car_nome_no_cartao from _cartao '+ 'Where car_cartao='+aspas+cartao+aspas; open; if recordCount=0 then begin close; showmessage('Cartao não encontrado!'); Result:=''; exit; end; Result:=Fields[0].AsString; finally close; end; end; function TServer_COMplus.busca_saldo(const cartao: WideString): Currency; begin aspas:=''''; with ADODtStGeral do try ADODtStGeral.close; CommandText:= 'Select sa_saldo_real_fin '+ 'From ( '+ 'Select sa1.sa_cartao, '+ 'sa1.sa_saldo_real_fin, '+ 'sa1.sa_dt_fechamento '+ 'From _Saldo sa1 '+ 'Where sa_cartao like left('+aspas+cartao+aspas+',14) '+ 'and sa1.sa_dt_fechamento=(select max(sa.sa_dt_fechamento) '+ ' from _saldo sa where sa.sa_cartao=sa1.sa_cartao) '+ 'Group by sa1.sa_cartao,sa1.sa_saldo_real_fin,sa1.sa_dt_fechamento '+ ')as rel '+ 'where sa_cartao is not null '; open; if recordCount=0 then begin close; Result:=0.00; exit; end; Result:=Fields[0].AsFloat; finally close; end; end; function TServer_COMplus.busca_meses_atraso(
101
const cartao: WideString): Integer; begin aspas:=''''; with ADODtStGeral do try ADODtStGeral.close; CommandText:=''; CommandText:= ' select tt_dias_atrasados from _xtemp_cartao_atraso '+ ' where tt_cartao like left('+aspas+cartao+aspas+',14)'; open; if recordCount=0 then begin close; Result:=30; exit; end; Result:=Fields[0].AsInteger; finally close; end; end; function TServer_COMplus.busca_cpf(const cartao: WideString): WideString; begin aspas:=''''; with ADODtStGeral do try ADODtStGeral.close; CommandText:=''; CommandText:= ' select ca_dpessoais_cpf_cnpj from _cadastro,_cartao '+ ' where car_cadastro=ca_codigo and car_cartao like '+aspas+cartao+aspas; open; if recordCount=0 then begin close; Result:=''; exit; end; Result:=Fields[0].AsString; finally close; end; end; procedure TServer_COMplus.imprime_proposta(const cartao, nome, cpf_cnpj: WideString; parc_valor: Currency; num_parc: Integer; desconto, saldo_deb, valor_pagar: Currency; const remetente: WideString; tipo_pessoa: Integer; Entrada: Currency); var wDia,wMes,wAno : Word; mesExtenso:string; begin DecodeDate(NOW, wAno, wMes, wDia); if wmes=01 then mesExtenso:='Janeiro'; if wmes=02 then mesExtenso:='Fevereiro'; if wmes=03 then mesExtenso:='Março'; if wmes=04 then mesExtenso:='Abril'; if wmes=05 then mesExtenso:='Maio'; if wmes=06 then mesExtenso:='Junho'; if wmes=07 then mesExtenso:='Julho'; if wmes=08 then mesExtenso:='Agosto';
102
if wmes=09 then mesExtenso:='Setembro'; if wmes=10 then mesExtenso:='Outubro'; if wmes=11 then mesExtenso:='Novembo'; if wmes=12 then mesExtenso:='Dezembro'; if tipo_pessoa=0 then begin ppDestinatario.Caption := nome; ppCartao.Caption := cartao; ppCPF.Caption := cpf_cnpj; ppDebito.Caption := CurrToStr(saldo_deb); ppEntrada.Caption := CurrToStr(Entrada); ppNroParc.Caption := IntToStr(num_parc); ppVlrParc.Caption := CurrToStr(parc_valor); ppVlrTotal.Caption := CurrToStr(valor_pagar); ppDesconto.Caption := CurrToStr(desconto); ppDia.Caption := IntToStr(wDia); ppMes.Caption := MesExtenso; ppAno.Caption := IntToStr(wAno); ppContato.Caption := remetente; ppProposta_F.Print; end; if tipo_pessoa=1 then begin ppdestinatario1.Caption := nome; ppCartao1.Caption := cartao; ppCNPJ.Caption := cpf_cnpj; ppSaldodevedor1.Caption := CurrToStr(saldo_deb); ppEntrada1.Caption := CurrToStr(Entrada); ppNroParcelas1.Caption := IntToStr(num_parc); ppVlrParcelas1.Caption := CurrToStr(parc_valor); ppVlrTotal1.Caption := CurrToStr(valor_pagar); ppDesconto1.Caption := CurrToStr(desconto); ppDia1.Caption := IntToStr(wDia); ppMes1.Caption := MesExtenso; ppAno1.Caption := IntToStr(wAno); ppContato1.Caption := remetente; ppProposta_J.Print; end; end; procedure TServer_COMplus.ppProposta_FPreviewFormCreate(Sender: TObject); begin ppProposta_F.PreviewForm.WindowState := wsMaximized; end; procedure TServer_COMplus.ppProposta_JPreviewFormCreate(Sender: TObject); begin ppProposta_J.PreviewForm.WindowState := wsMaximized; end; function TServer_COMplus.calcula_parcela(saldo_parcelar: Currency; taxav: Double; nroParcelas: Integer): Currency; begin result := saldo_parcelar * (Power((1 + taxav/100),nroParcelas) * taxav / 100) / (Power((1 + taxav/100),nroParcelas) - 1); end; initialization
103
TComponentFactory.Create(ComServer, TServer_COMplus, Class_Server_COMplus, ciMultiInstance, tmBoth); end.
![Cátia Alexandra Estu do de multicamadas finas com ... · Podence Alves Estu do de multicamadas finas com propriedades multiferróicas. ... Nos anos 50 Jonker e van Santen [1] sintetizaram](https://img.document.onl/doc/110x75/5be6e87209d3f23a518d9cdc/catia-alexandra-estu-do-de-multicamadas-finas-com-podence-alves-estu-do.jpg)
