Monografia eng soft1_halan
61
HALAN RIDOLPHI ALVES Fundamentos De Framework de Software CT/POLI 2006 MBA - Engenharia de Software Monografia Pós-Graduação Lato-Sensu ENGSOFT1
-
Upload
halan-ridolphi -
Category
Technology
-
view
989 -
download
0
description
Software Engineering
Transcript of Monografia eng soft1_halan
HALAN RIDOLPHI ALVES
Fundamentos
De
Framework de Software
CT/POLI 2006
MBA - Engenharia de Software Monografia Pós-Graduação Lato-Sensu ENGSOFT1
i
Fundamentos de Framework de Software: Estudo de Caso do Uso do
Paradigma de Orientação a Objetos na Construção de Aplicações de Software
Halan Ridolphi Alves
Universidade Federal do Rio de Janeiro
Curso de Pós-Graduação em Engenharia de Software
Orientador: Geraldo Bonorino Xexéo, D.Sc.
Rio de Janeiro 2006
ii
Alves, Halan Ridolphi. Fundamentos de Framework de Software: Estudo de Caso do Uso do Paradigma de Orientação a Objetos na Construção de Aplicações de Software / Halan Ridolphi Alves. – Rio de Janeiro, 2006. xi, 54 f.: il. Monografia (Pós-Graduação em Engenharia de Software) – Universidade Federal do Rio de Janeiro - UFRJ, Escola Politécnica, 2006. Orientador: Geraldo Bonorino Xexéo
1. Reutilização de Software. 2. Orientação a Objetos. 3. Engenharia de Software - Teses. I. Xexéo, Geraldo Bonorino (Orient.). II. Universidade Federal do Rio de Janeiro. Escola Politécnica. III. Título.
iii
AGRADECIMENTOS
Ressaltamos nossos sinceros agradecimentos à equipe de professores
do curso de pós-graduação em Engenharia de Software ministrado pela Escola
Politécnica da UFRJ. Nestes quase dois anos de parceria e convivência
observamos que a troca de informações e experiências com a equipe de
professores da POLI, pôde proporcionar-nos muito maior sensatez, acurácia,
percepção, destreza e habilidades profissionais. Agradecemos a todos que
cooperaram e interagiram conosco durante este período possibilitando nosso
aperfeiçoamento profissional e pessoal. Ademais, acreditamos que também
tenhamos transmitido alguma boa mensagem a cada um dos professores
durante esta nossa convivência. Expressamos também nossa gratidão ao
pessoal da secretaria do curso, o qual sempre nos atendeu com consideração,
profissionalismo e solidariedade. Portanto, desde já, temos somente boas
lembranças deste período de cooperação, estudo e intercâmbio de
conhecimentos.
iv
RESUMO
ALVES, Halan Ridolphi. Fundamentos de Framework de Software: estudo de
caso do uso do paradigma de orientação a objetos na construção de aplicações
de software. Orientador: Geraldo Bonorino Xexéo. Rio de Janeiro: UFRJ/POLI;
2006. Monografía (Pós-Graduação em Engenharia de Software).
O estudo focaliza em projeto prático real, mais notadamente, apresentar
fundamentos da construção um framework de software, relatando problemas e
soluções explorados no projeto. Um framework de software pode ser definido
como uma infra-estrutura de software composta de um conjunto de
procedimentos e funções encapsulados sob forma de classes de objetos,
objetivando o desenvolvimento de aplicação com base em reuso e o paradigma
de orientação a objetos, na visão de Fayad (1999). O trabalho apresenta a
visão do autor em seu papel de engenheiro de software, focando os aspectos
de projeto (arquitetura, classes de objetos, padrões) e de implementação de
estruturas de dados e algoritmos (atributos e métodos de classes) na
construção do framework de software. Demonstra-se através de exemplos
como a reutilização dessa infra-estrutura de software acelera o
desenvolvimento de aplicações corporativas baseadas em software visando à
automação de processos de negócios.
v
LISTA DE SIGLAS CT - Centro de Tecnologia
POLI - Escola Politécnica
UFRJ - Universidade Federal do Rio de Janeiro
HSBC - HSBC Bank
URL - Uniform Resource Locator
HTTP - Hiper Text Transfer Protocol
OO - Orientação a Objetos
POO - Programação Orientada a Objetos
ESOO - Engenharia de Software Orientada a Objetos
DBC - Desenvolvimento Baseado em Componentes
CASE - Computer-Aided Software Engineering
API - Application Programming Interface
SOA - Service-Oriented Architecture
MVC - Model-View-Controller
INI - initialization file or INI file
IPC - Inter-Process Communication
XML - Extensible Markup Language
UML - Unified Modeling Language
RPC - Remote Procedure Call
ACE - Adaptive Communication Environment
MFC - Microsoft Foundation Classes
DCOM - Distributed Component Object Model
.NET - Microsoft .NET Framework
Java RMI - Java Remote Method Invocation
CORBA - Common Object Request Broker Architecture
J2EE - Java 2 Platform, Enterprise Edition
VCL - Visual Component Library
CLX - Component Library for Cross Platform
ET++ - Editor Toolkit, an OO application framework in C++
JUnit - Java Unit testing framework
FMWLOS - Framework de software Losango
vi
SUMÁRIO
1 INTRODUÇÃO ........................................................................................ 1
1.1 Escopo ............................................................................................. 1
1.2 Notação Sintática ............................................................................. 2
2 REVISÃO DE LITERATURA ................................................................... 4
2.1 Definições......................................................................................... 4
2.2 Características.................................................................................. 6
2.3 Estruturas ......................................................................................... 8
2.4 Problemas Comuns ........................................................................ 11
2.5 Adoção ........................................................................................... 13
2.6 Avaliação........................................................................................ 14
2.7 Utilização........................................................................................ 15
2.8 Benefícios Técnicos ....................................................................... 16
2.9 Aplicações Reais ............................................................................ 17
3 METODOLOGIA.................................................................................... 20
3.1 Premissas....................................................................................... 20
3.2 Ferramentas ................................................................................... 21
3.3 Base Técnica.................................................................................. 22
3.4 Processos....................................................................................... 24
4 ESTUDO DE CASO............................................................................... 27
4.1 Breve Histórico ............................................................................... 27
4.2 Descrição do Caso ......................................................................... 28
4.3 Análise da Situação........................................................................ 32
4.3.1 Modelo de Classes no Núcleo (Kernel) ................................... 32
4.3.2 Modelo de Algoritmo do Kernel (Frozen Spots)....................... 33
4.3.3 Modelo de Aplicação Canônica (Hot Spots) ............................ 39
4.3.4 Exemplo de Lógica Específica de Aplicação........................... 42
5 CONCLUSÕES ..................................................................................... 46
6 REFERÊNCIAS ..................................................................................... 49
7 ANEXOS................................................................................................ 50
7.1 Glossário de OO............................................................................. 50
1
1 INTRODUÇÃO
1.1 Escopo
Este trabalho focaliza um projeto de software prático real, mais
notadamente, apresenta fundamentos da construção de um framework de
software, relatando problemas e soluções explorados em seu projeto técnico.
A necessidade de uma solução baseada em framework de software
originou-se do desafio de fornecer a infra-estrutura que possibilitasse o
desenvolvimento rápido de aplicações corporativas baseadas em software, no
ambiente de tecnologia da informação da financeira Losango pertencente ao
grupo HSBC. Esta infra-estrutura de software foi nomeada pela sigla FMWLOS.
Em suma, o FMWLOS seria utilizado como plataforma de desenvolvimento por
vários fornecedores de soluções baseadas de software do HSBC/Losango para
o desenvolvimento de aplicações cujos propósitos incluem processamento
batch, daemons e serviços hospedados em sistemas Unix e Windows, visando
à automação de processos de negócios relacionados à avaliação de propostas
de créditos ao consumidor.
O estudo objetiva apresentar a visão do autor em sua atuação
profissional como engenheiro de software integrante de equipe de fornecedores
do HSBC/Losango, focando os aspectos básicos de projeto (arquitetura,
modelo de classes, padrões, componentes) e de implementação de estruturas
de dados e algoritmos (atributos e métodos de classes), visando à construção
de uma solução de framework de software.
As classes de objetos que compõem a organização estrutural, os
algoritmos e estruturas de dados que orientam o modelo dinâmico foram
projetados e codificados com vistas a prover as funcionalidades desejadas no
framework de software, tais como: processamento de cadeias de caracteres,
manipulação de arquivos de configuração (INI), processamento arquivos XML,
controle de concorrência e sincronismo, comunicação inter-processos (IPC),
acesso a dados em bancos de dados relacionais, gerenciamento de arquivos,
gerenciamento de memória, processamento concorrente e outros recursos.
Considerando a ampla dimensão de capacidades do framework de software
2
utilizado como fonte de informação neste estudo e as restrições de escopo
deste trabalho, exploraremos apenas um subconjunto de suas capacidades.
1.2 Notação Sintática
Embora o framework de software neste estudo de caso, vulgo FMWLOS,
seja codificado com uso da linguagem de programação C, o padrão de
codificação adota conceitos de C++. A tabela abaixo apresenta um comparativo
entre os métodos de construção e destruição de objetos em código C++ versus
código equivalente utilizando no framework FMWLOS.
Elementos de Linguagem
Sintaxe em C++ Sintaxe em FMWLOS
Classe Em FMWLOS
utilizam-se as
macros
CLASS_TYPE,
CLASS e
EXTENDS para a
definição de
classes.
class CHttpException
: public CException
{
…
};
CLASS_TYPE (THttpException);
CLASS (THttpException)
EXTENDS (TException)
{
…
};
Construtores e Destrutores Em FMWLOS,
utilizam-se os
métodos de
alocação dinâmica
CreateInstance e
ReleaseInstance.
void f()
{
X *pX = new X[5];
delete [] pX;
}
void f()
{
Tx* pX;
pX = TX_CreateInstance();
…
TX_ReleaseInstance (pX);
}
Alocação na Stack Em FMWLOS
utilizam-se os
void f()
{
CX X;
…
void f()
{
Tx* pX;
3
métodos
CreateLocal e
ReleaseLocal. Não
se devem utilizar
estes métodos
dentro de um loop,
a menos que as
chamadas estejam
em uma função
interna a este loop.
return;
}
pX = TX_CreateLocal();
…
TX_ReleaseLocal (pX);
}
Tabela 1: Sintaxe de Elementos de Linguagem
4
2 REVISÃO DE LITERATURA
2.1 Definições
Frequentemente nos referimos aos termos biblioteca de classes OO,
frameworks, padrões e componentes. Estes termos referem-se às ferramentas
que são usadas para construir sistemas de software reusáveis. Uma biblioteca
de classe OO é uma coleção de implementações de objetos de software que
provêem funcionalidade reutilizável através de chamadas do programador aos
métodos de objetos. Bibliotecas de classes OO provêem os insumos
necessários para construir aplicações de software, porém, não provêm as
diretrizes de como juntar as peças de software para gerar uma aplicação
concreta e amplamente funcional, conforme relata Pfleeger (2003). Portanto,
cabe ao desenvolvedor de software tomar as decisões necessárias para coletar
e acoplar componentes disponíveis em um repositório de software reutilizável
visando montar um sistema de software específico. Abaixo, a figura 1 ilustra a
natureza passiva desta solução de desenvolvimento, representando como
padrões de projeto podem direcionar o projeto e a implementação da aplicação
e, o uso de componentes das bibliotecas de classes.
Figura 1: Desenvolvimento de Aplicação com Bibliotecas de Classes.
5
Framework de software é uma tecnologia muito importante para indústria
de software, bem como para academia, ao considerarmos que demandas
atuais por soluções de software estão requerendo, cada vez mais, sistemas de
software com crescente complexidade, tamanho e funcionalidade. O advento do
paradigma OO, incluindo tanto técnicas para programação e engenharia de
software orientada a objetos, e a definição de frameworks possibilitaram
reutilização de componentes de software em larga amplitude, inclusive
possibilitando a construção de geradores de modelos de aplicação em vários
domínios de negócio. Dentre as vantagens da adoção da tecnologia de
frameworks de software destacam-se o incremento da reutilização, com
conseqüente ganho de produtividade pelos programadores, e a redução do
tempo de lançamento ao mercado para aplicações de software. Quando
utilizados em conjunção com padrões, componentes e bibliotecas de classes,
os frameworks podem significativamente incrementar a qualidade de software e
reduzir esforço de desenvolvimento.
Um padrão representa uma solução recorrente para um problema de
desenvolvimento de software dentro de um contexto particular. Padrões de
projeto são abstrações de alto nível que refletem a experiência de profissionais
hábeis e descrevem, de acordo com formato definido, o contexto, problemas,
soluções e conseqüências de compor decisões de projeto específicas, segundo
descreve Erich Gamma (1995). Padrões são menos especializados que
frameworks. Frameworks são úteis em um domínio de aplicação particular,
enquanto que padrões são aplicáveis mais genericamente. Um framework
tipicamente contém vários padrões, entretanto, padrões não contêm
frameworks, conforme relata Johnson (1997). Frameworks são construídos de
tal modo que aplicações similares geradas, dentro do mesmo domínio de
negócio, se beneficiem das potencialidades providas por mesmas estruturas,
padrões, algoritmos e demais abstrações de software embutidas em um
framework. Framework de software são, portanto, como geradores de
aplicação.
Um componente refere-se a um objeto concreto que dispõe de uma
interface de serviços bem definida e deve ser auto-contido em termos das
6
funcionalidades que provê. Tanto bibliotecas de classes OO e frameworks são
coleções de componentes que transformam projeto abstrato em produto
concreto por via da instanciação e especialização, conforme relatado por
Douglas Schmidt (1994).
Na visão de Mohamed E. Fayad (1999), um framework de software pode
ser definido como uma estrutura de software composta de um conjunto de
procedimentos e funções encapsulados sob forma de classes de objetos,
objetivando o desenvolvimento de aplicação com base em reuso e o paradigma
de orientação a objetos. De acordo com Ralph E. Johnson (1997) entende-se
por framework como sendo um conjunto de componentes de software que
formam uma aplicação semi-completa e reutilizável em um domínio de negócio
específico, que pode ser especializada e fornece a infra-estrutura necessária e
suficiente para desenvolvimento de novas aplicações de software. Framework
de software é uma tecnologia promissora na transformação de soluções
abstratas expressas em projetos de software em implementações de produtos
tangíveis e funcionais, possibilitando tal transformação com redução de custos
e melhoria da qualidade do produto de software. Um framework existe para ser
reutilizado e agilizar o desenvolvimento de software.
2.2 Características
Um framework de software descreve a arquitetura de um software
orientado a objetos incluindo os tipos de objetos e como eles colaboraram no
fornecimento de serviços entre si, conforme visão de Bushmann (1996).
Frameworks utilizam intensamente as características que distinguem as
linguagens de programação orientadas a objetos, a saber: abstração de dados,
polimorfismo e herança.
Uma classe abstrata representa a especificação da interface de serviços
pela quais as implementações (especializações) podem se orientar visando à
concretização das funcionalidades. Polimorfismo é a habilidade para uma
variável ou parâmetro de um procedimento assumir valores de vários tipos
(Pfleeger, 2003).
7
Polimorfismo possibilita aos objetos mudarem seus mecanismos de
colaboração com demais objetos em tempo de execução e, portanto, viabiliza
ampla versatilidade no comportamento da aplicação de software.
Herança viabiliza a geração de novas linhagens de objetos a partir de
objetos preexistentes, por via da inclusão de novas responsabilidades ou
mesmo alteração de responsabilidades existentes dos objetos originais.
Responsabilidades representam obrigações que os objetos devem cumprir e,
incluem a realização de alguma tarefa (método) ou o conhecimento de alguma
informação (atributo), na visão de Ambler (2001).
Um framework é um projeto reutilizável de um software que descreve sua
decomposição em grupos de objetos de interação, conforme mencionado por
Fayad (1999). O framework descreve objetos componentes e como estes
objetos interagem entre si. Descreve a interface de serviços de cada objeto e o
fluxo de controle entre os mesmos. Comumente, um framework é codificado
com emprego de uma linguagem de programação orientada a objetos, onde
alguns dos objetos constituintes do núcleo do framework são especificados por
classes abstratas. Uma classe abstrata é uma classe sem instâncias, tem
caráter de compor superclasses de alta ordem numa hierarquia de classes de
objetos e, são empregadas como modelos para formação de novas subclasses
(Pfleeger, 2003). Frameworks utilizam classes abstratas no projeto de seus
objetos componentes, pois elas especificam a interface de serviços dos
mesmos e provêem um esqueleto que pode ser especializado para implementar
os componentes funcionais das aplicações finais geradas (Fayad, 1999).
Frequentemente, um framework se utiliza de biblioteca de classes que
contém subclasses concretas derivadas de classes que compõem o núcleo do
framework. Estes conjuntos de subclasses adicionais agregam a
implementação de serviços especializados identificados e necessários no
domínio de negócio no qual estão inseridas as aplicações a serem geradas via
framework. Alguns destes serviços englobam funções para gerenciamento de
memória, gerenciamento de arquivos, tratamento de exceções, controle de
acesso e segurança da informação, interface do usuário, acesso a dados,
comunicação de dados. Embora uma ampla e funcional biblioteca de classes
8
seja um recurso crucial para apoiar um framework de software em sua missão
geradora de novas aplicações de software, a essência de um framework não
está na biblioteca de classes em si, mas sim, no modelo de colaboração e fluxo
de controle presentes entre seus objetos, conforme comentado em Fayad
(1999).
Comumente, um framework apresenta a técnica de inversão de controle,
que consiste em um mecanismo pelo qual o esqueleto do módulo de programa
principal é reutilizado pelo programador que decide o que é anexado ao
mesmo. Também, conforme necessidades da lógica de aplicação a ser
implementada, o programador pode inclusive criar novos componentes de
software a serem anexados e invocados pela estrutura padrão de programa.
Neste caso, o código gerado pelo programador é chamado pelo código do
núcleo ou máquina do framework. Portanto, o framework determina a estrutura
geral e fluxo de controle do programa principal a ser executado pela aplicação.
O desenvolvimento de frameworks de software eficientes, reutilizáveis e
robustos requer equipes de profissionais com ampla capacitação em
tecnologias de engenharia de software. Para concretizar tal produto de software
necessita-se de projetistas, analistas, testadores e programadores com domínio
de padrões, arquiteturas de software, protocolos, idiomas de programação, OO,
DBC, algoritmos e estruturas de dados, linguagens de especificação de
modelos de software (UML), ferramentas de teste automatizado (JUnit),
linguagens de programação (C++, Java), ambientes de desenvolvimento de
software (C++ Builder, Delphi, Eclipse, MS Visual Studio), ferramentas CASE
(IBM Rational Rose, System Architect, ERWIN, Enterprise Architect) e dentre
outras tecnologias de construção de software.
2.3 Estruturas
A construção de um framework de software engloba o projeto do núcleo
(kernel) do framework, o qual compreende a especificação de classes de
objetos abstratas e concretas referentes ao domínio de negócio para o contexto
de aplicação desta tecnologia, conforme comentado por Fayad (1999). O
projeto do núcleo do framework especifica a arquitetura de software típica para
aplicação de software a ser gerada no domínio de negócio particular. Também
9
associado à construção deste tipo de produto de software ressaltamos
necessidade do projeto dos incrementos internos do framework, o qual consiste
na especificação de classes adicionais que capturam implementações comuns
e especializadas do núcleo do framework e contribuem para agregar mais
utilidade, funcionalidade e aplicabilidade ao conjunto do framework (núcleo,
incrementos internos). Tais incrementos internos formam um grupo de
bibliotecas de classes que oferecem distintos serviços especializados e de
suporte ao framework, na visão de Fayad (1999).
Frameworks compreendem um tipo de software complexo, pois contém
projetos abstratos, são aplicáveis genericamente e, detêm características
peculiares em dois níveis: domínio de negócio e estruturais. As características
relevantes do domínio são úteis em aplicações de negócio. Já as
características estruturais são constituídas de estruturas lógica (projeto) e física
(módulos de programa) que viabilizam a adaptação e evolução do framework.
Essas características têm importância especial, pois o projeto e a
implementação do framework compreendem a interface corrente utilizada pelos
usuários do framework (desenvolvedores de aplicação, programadores),
conforme esclarece Johnson (1997).
Framework não deve ser interpretado com sendo uma aplicação, pois
necessariamente não provê comportamento padrão desejável para aplicação e,
portanto, frameworks não são programas executáveis, conforme relata Fayad
(1999). Frameworks podem ser percebidos como projetos e implementações
parciais, pois não descrevem todos os aspectos funcionais de uma aplicação.
Uma framework não é uma biblioteca de classes. Aplicações de software que
utilizam classes de uma biblioteca invocam métodos predefinidos, enquanto
frameworks contêm componentes que invocam métodos fornecidos pelo
usuário. Esta inversão de controle é característica peculiar. Frameworks são
conjuntos interconectados e complexos, enquanto que bibliotecas consistem de
peças compatíveis, na visão de Fayad (1999).
Frameworks devem gerar famílias de aplicações para o domínio de
negócio no qual se insere. Para tal, devem existir em sua estrutura pontos de
flexibilidade que possam ser customizados de modo a adaptá-lo a aplicação
10
que se deseja construir. Os pontos de flexibilidade de um framework são
chamados de hot spots. Hot spots são classes abstratas ou métodos virtuais
que devem ser implementados pela aplicação alvo. A geração de um programa
executável inclui sua instanciação via framework com a implementação de
código específico da aplicação preenchendo cada hot spot. Uma vez os hot
spots são instanciados, o framework utilizará estas classes por via de um
mecanismo específico como o callback. Pelo callback, o código do usuário do
serviço declara que ele quer ser chamado quando da ocorrência de
determinado evento. Então, o código do provedor do serviço realiza o callback
no código do usuário do serviço quando o evento ocorre, conforme relata
Lucena (2001).
Algumas estruturas do framework não são mutáveis e não pode ser
facilmente alteradas. Estes pontos de imutabilidade constituem o núcleo de um
framework, também chamados de frozen spots. Os frozen spots,
diferentemente dos hot spots, são peças de código já implementadas dentro do
framework que pode chamar um ou mais hot spots fornecidos pelo usuário do
framework. O núcleo será constante e parte sempre presente de cada instancia
(aplicação de software) do framework, conforme menciona Lucena (2001).
Podemos imaginar um framework com sendo um motor. Um motor
requer energia. Diferente de um motor tradicional, um motor de framework tem
muitas tomadas de energia. Cada tomada de energia é um hot spot do
framework. Cada hot spot deve ser energizado (implementado) para o motor
(framework) trabalhar. Os geradores de energia são os códigos específicos da
aplicação que deve ser plugados nos hot spots. O código de aplicação
adicionado será usado pelo código do núcleo do framework. O motor não
funcionará enquanto todas as tomadas estiverem desconectadas. Esta
comparação é ilustrada pela figura 2, extraída de Lucena (2001).
11
Figura 2: Framework versus Aplicação.
2.4 Problemas Comuns
Frameworks de software são referenciados como a pedra fundamental
da engenharia de software contemporânea. Frameworks são geradores de
aplicação que estão diretamente relacionados a um domínio de negócio
específico, ou seja, uma família de problemas relacionados. A despeito de suas
potencialidades, a prática tem revelado alguns problemas e desafios a superar
associados ao emprego da tecnologia de frameworks de software.
Frameworks são considerados ferramentas grandes, poderosas e
complexas e, portanto, difíceis de entender. Isto implica que é necessária
documentação mais apurada, precisa e completa que outros produtos de
software e, além disso, requer longo treinamento. Um framework deveria ser
fornecido com diferentes aplicações protótipos que reutilizassem os vários
componentes do framework em distintos modos de montagem dessas
aplicações. Este recurso acompanhado ao framework apoiara sobremaneira
usuários do framework na compreensão dos mecanismos de programação e
como a solução do framework em si pode ser usada. Em resumo, a
documentação de framework deve focar no uso de exemplos de modo a tornar
o projeto abstrato das estruturas internas do framework mais concreto,
12
palpável, manejável e compreensível para seus usuários finais, de acordo com
visão de Fayad (1999).
Ademais, frameworks são difíceis de construir por conta de seus
sofisticados algoritmos de controle de fluxo de execução, mecanismos para
viabilizar flexibilidade, reutilização, extensibilidade e modularidade, incidindo em
custos maiores de aquisição e requerem equipes de desenvolvedores
experientes e com elevada capacitação técnica.
Como frameworks são descritos em termos de linguagens de
programação, ou seja, é software implementado, torna-se difícil para
desenvolvedores compreender seus padrões comportamentais apenas por via
da leitura do código fonte, o qual se configura em tarefa muito pouco viável, por
conta das centenas de milhares de linhas de instrução que compõe seu
material constituinte. Portanto, programadores dependem de boa
documentação, incluindo exemplos de programação de aplicações com uso do
framework, ou obter suporte de especialistas na solução, conforme relatado em
estudos por Fayad (1999).
Decidir quando lançar um framework para viabilizar desenvolvimento de
aplicação não é tarefa fácil, pois o problema é definir e assegurar algum critério
de lançamento. O framework dever ser reutilizável, razoavelmente estável
dentro do domínio de negócio e bem documentado. Pesquisas recentes acerca
de abordagens para reuso indicam que ainda não existem métricas gerais para
mensurar este processo da engenharia de software. Quanto à estabilidade, o
domínio de negócio onde framework está inserido não é estável por si só, mas
evolui constantemente. Decidir se o framework está suficientemente bem
documentado é complicado, pois não existe método de documentação
genericamente aceito que cobre todos os aspectos do framework, mas também
porque é difícil determinar se a documentação está compreensível para os
usuários do framework (desenvolvedores de aplicação, programadores). O
lançamento de um framework imaturo pode ter severas conseqüências na
manutenção e utilização do framework e para aplicações instanciadas em
produção, conforme aponta Johnson (1997).
13
2.5 Adoção
A adoção da tecnologia de frameworks pode ser motivada por vários
fatores. Dentre eles, a necessidade de economizar tempo e dinheiro durante o
desenvolvimento de aplicações de software. A redução do tempo de
lançamento ao mercado de determinado produto de software configura-se em
fator primordial em muitas empresas, sob pena de não se viabilizarem as
mudanças no ambiente de negócios ou mesmo perda de clientela para a
concorrência.
Uniformidade no desenvolvimento de produtos de software também é
uma diretriz tangível pela utilização de frameworks de software. Por exemplo,
frameworks de interface do usuário gráfica possibilitam a geração de aplicações
de software com similar aparência e metáfora de operação com usuário final.
Uniformidade reduz custos de manutenção, pois um novo programador pode
mover-se do desenvolvimento de uma aplicação para próxima sem ter que
compreender novos padrões de projeto, conforme defende Fayad (1999).
Outra motivação para uso de frameworks é possibilitar aos
desenvolvedores a construção de sistemas de software pela combinação de
componentes de distintos fornecedores. Ademais, frameworks permitem
doutrinar e melhorar as habilidades dos programadores no sentido de
conduzirem à construção de um produto de software balizado pelos melhores
preceitos da engenharia de software, incluindo modularidade, reutilização,
extensibilidade, escalabilidade, robustez e controle de fluxo de execução.
Portanto, frameworks propagam na corporação uma cultura de
desenvolvimento orientada ao reuso de soluções de software, objetivando
ganhos de produtividade, redução do tempo de criação de novos produtos,
maior lançamento de novidades ao mercado consumidor em curtos períodos de
tempo, melhoria da qualidade de software, minimização de esforço e custos de
desenvolvimento.
14
2.6 Avaliação
Não é fácil dizer o quão confiável um framework é, se o fornecedor
oferecerá bom suporte ao produto e, se a aplicação final construída com base
no framework é suficientemente eficiente, conforme apregoa Fayad (1999).
As questões difíceis são se um framework é adequado para o domínio do
problema e se contempla o correto balanceamento entre poder e simplicidade.
Nenhum framework é bom para qualquer tipo de aplicação, e pode ser difícil
dizer se uma solução particular é bem adaptada para um domínio de problema
específico.
A abordagem padrão para avaliação de framework é tomar uma lista de
verificação das características que a solução de framework deve suportar.
Comumente frameworks são projetados para serem extensíveis e,
provavelmente são supostos prover somente um subconjunto de
funcionalidades desejadas para aplicação final. Neste sentido, é mais
importante que um framework seja fácil de estender do que ter todas as
funcionalidades desejadas para um domínio de problema, conforme Fayad
(1999). Entretanto, é mais fácil dizer se um framework provê uma determinada
funcionalidade do que dizer se é extensível. Um especialista na solução de
framework pode usualmente dizer o quão complicado é adicionar alguma
característica faltante, mas é bastante difícil tal diagnóstico por parte de novatos
na solução. Portanto, uma alternativa razoável de conduzir a avaliação de
soluções é utilizar alguns frameworks, possivelmente em alguns projetos-
pilotos, e desenvolver alguma experiência e capacitação com eles antes de
escolher uma solução como padrão da empresa. Como frameworks são
grandes e custosos, então também é caro testá-los e, não existe outra escolha
exceto confiar no parecer dos especialistas, defende Fayad (1999).
Todo framework tende balancear simplicidade com poder. Simplicidade
torna o framework mais fácil de compreender, portanto um framework simples é
melhor para desenvolvedores novatos. Especialistas apreciam poder e
flexibilidade. Se a pretensão de usar framework é por somente uma vez, então
o tempo consumido para entendê-lo provavelmente excederá o tempo gasto
para usá-lo, assim simplicidade deve ser mais importante que poder. Se o
15
objetivo é utilizar framework muitas vezes então poder e flexibilidade são
provavelmente mais importantes para balizar o investimento na tecnologia, de
acordo com visão de Fayad (1999).
O valor primordial de uma solução de framework é se ela melhora o
modo de desenvolver software e, como também, o produto de software em si.
Muitos fatores influem neste sentido: a qualidade do framework, ferramentas de
suporte ao framework, a qualidade da documentação e comunidade de
especialistas que prove treinamento e consultoria na aplicação da tecnologia.
Um framework deve preencher a cultura da empresa. Se a empresa tem alta
rotatividade de pessoal e pequeno orçamento para treinamento então o
framework deve ser simples e fácil de usar. O valor de um framework depende
muito mais de seu contexto de utilização do que na sua solução proposta em si,
defende Fayad (1999).
2.7 Utilização
Uma aplicação desenvolvida com uso de framework é composta por três
componentes de software: o framework, as subclasses concretas derivadas de
classes do núcleo do framework (reutilizadas das bibliotecas de classes) e
qualquer outro componente de implementação (lógica especializada de
negócio). Este última parte, também referenciada por incremento específico da
aplicação, especifica quais as demais classes concretas serão usadas e como
elas serão interconectadas para compor o código referente à lógica específica
da aplicação. Este incremento específico pode também incluir objetos que não
tem relacionamento direto com framework ou utilizar objetos da biblioteca de
classes que acompanha o framework, mas que não são invocados via
mecanismo de inversão de controle e, portanto, não são participantes do
modelo de colaboração presente na máquina do framework.
O caminho mais suave e rápido para utilizar um framework na prática é
conectando componentes existentes, não incidindo em alterações ou
customizações no framework ou criação de qualquer nova subclasse de
objetos. Outro modelo de uso do framework define novas subclasses concretas
derivadas ou não de classes internas do framework e usa-las para implementar
lógica de aplicação. Neste caso, as subclasses derivadas do framework devem
16
reunir a especificação estabelecida pelas superclasses, assim sendo, o
programador deve compreender em detalhes as interfaces de serviços providas
pelo framework.
O desenvolvimento de frameworks está rapidamente ganhando
aceitação na comunidade de software devido a sua habilidade de promover
reuso de código fonte e projeto. A figura 3 abaixo ilustra a natureza ativa desta
solução de desenvolvimento, representando como padrões, componentes e
bibliotecas de classes do framework podem guiar a construção de uma
aplicação de software.
Figura 3: Desenvolvimento de Aplicação com Framework.
2.8 Benefícios Técnicos
A utilização de tecnologia de frameworks de software vem impulsionar e
proporcionar benefícios primários para construção de produtos de software, tais
como modularidade, reutilização, extensibilidade e inversão de controle, com
impactos diretos no exercício profissional de desenvolvedores de aplicação,
conforme defende Fayad (1999).
Frameworks melhoram a modularidade encapsulando detalhes de
implementação volátil através de interfaces de serviços estáveis. Modularidade
do framework ajuda melhorar qualidade do software pela localização do
17
impacto ocasionado por alterações no projeto e implementação. Esta
localização reduz o esforço requerido para compreender e manter o software
existente.
As interfaces de serviços estáveis providas por frameworks aperfeiçoam
o reuso pela definição de componentes genéricos que podem ser reaplicados
para criar novas aplicações. Reutilização de framework otimiza o esforço de
desenvolvedores experientes para evitar recriação e revalidação de soluções
comuns para recorrentes requisitos de aplicação e desafios de projeto de
software. O reuso pode melhorar substancialmente a produtividade do
programador, bem como aperfeiçoar a qualidade, desempenho, confiabilidade e
interoperabilidade do software, na visão de Pfleeger (2003).
Um framework aperfeiçoa a extensibilidade do software pela provisão de
métodos virtuais e níveis de indireção (dynamic binding) que permitem aos
desenvolvedores de aplicações estenderem as interfaces de serviços estáveis.
Métodos virtuais desacoplam as interfaces estáveis e as variantes
comportamentais requeridos no domínio de aplicação. Extensibilidade é
fundamental para assegurar customização rápida de novos serviços e
habilidades para aplicações geradas.
A arquitetura de tempo de execução de um framework é caracterizada
pelo mecanismo de inversão de controle. Esta arquitetura possibilita que
passos do processamento da aplicação canônica serem customizados por
objetos manipuladores de eventos que são invocados pelo mecanismo de
despachamento reativo do framework, conforme explica Fayad (1999). Inversão
de controle permite ao framework determinar qual conjunto de métodos
específicos da aplicação a serem invocados em resposta aos eventos externos.
2.9 Aplicações Reais
Frameworks de software comerciais tais como MacApp, ET++,
InterViews, ACE, MFC, .NET, J2EE, DCOM, Java RMI, Borland VCL, Borland
CLX e implementações de CORBA demonstram importante avanço e
sofisticação da indústria de software no sentido de estabelecer e disponibilizar
padrões, ferramentas e técnicas de construção do software contemporâneo. A
18
seguir, mencionamos algumas aplicações reais construídas por via da utilização
de tais ferramentas:
• Sistemas embutidos de aviação em tempo real na Boeing/McDonnell
Douglas;
• Infra-estrutura para sistema de ambiente de simulação interativa
distribuída na DMSO (Defense Modeling and Simulation Organization);
• Software médico para a Siemens Medical Engineerig;
• Gerenciamento de redes e processamento de chamadas para Siemens
ICN;
• Telecomunicações e data networking na Lucent Technologies e
Motorola;
• Interface do usuário gráfica na plataforma Macintosh da Apple Computer;
• Infra-estrutura distribuída e gateway de comunicações móveis na
Motorola;
• Gerencia de redes na ARINC;
• Infra-estrutura de computação distribuída na Envision;
• Sistema operacional embarcado em estações móveis de 3ª. geração da
Siemens AG;
• Distribuição de dados para Siemens Power Systems Control;
• Interface do usuário gráfica do sistema operacional Windows da
Microsoft;
• Sistema de controle da produção de aço na Siemens ATD;
• Middleware para avaliação de propostas de créditos ao consumidor no
HSBC/Losango;
• Middleware para tarifação de serviços de assinantes pré-pagos no Claro
Telecom;
• Controle de engarrafamento de cerveja na Krones;
• Monitoração de PBX na Ericsson;
• Processamento distribuído de seguros na CCC, Chicago, Illinois;
• Sistema de limites globais no Credit Suisse;
• Sistema de publicação de conteúdo pela internet na Cacheflow;
19
• Sistemas de imagem médica na Kodak;
• Sistema de bordo para gerenciamento de combate na Marinha Turca.
20
3 METODOLOGIA
3.1 Premissas
Por definição da divisão de suporte de software básico do
HSBC/Losango o escopo do framework FMWLOS seria principalmente prover
recursos para geração de aplicações de negócio a serem hospedadas em
sistema operacional HP-UX 11. Além disso, o desempenho das aplicações
consistia em requisito de projeto essencial, tendo em vista o volume de
propostas de créditos encaminhadas pelos lojistas em períodos críticos de
movimentos de vendas do comércio varejista, notadamente, os feriados para
dia das mães e natal. Por conta deste requisito, a linguagem de programação
padrão adotada para desenvolvimento seria linguagem C. Para as ferramentas
de compilação envolveriam o uso de GNU C Compiler e GNU Make
compatíveis para plataforma HP-UX.
A linguagem de programação C++ foi preterida como meio de
implementação das aplicações em relação a linguagem C, por conta da menor
eficiência, conseqüente principalmente da característica de ligação dinâmica
(binding dynamic), essencial para viabilizar o polimorfismo da OO na linguagem
C++. A menor eficiência da linguagem C++, ao nível de implementação, pode
ser explicada pelo incremento do layout de armazenamento em memória
(devido aos ponteiros necessários para tabelas virtuais), degradação do
desempenho de execução (devido ao overhead adicional para invocar método
virtual dinamicamente) e os níveis de indireção (classes abstratas) utilizadas
para permitir desenvolvedores estender as interfaces de serviços existentes,
conforme relata Lippman (1996). Em resumo, a generalidade e flexibilidade
providas pela linguagem C++ implicam na contrapartida da redução da
eficiência quanto confrontada com a linguagem C. Relativo a vantagens do uso
da linguagem C afirma-se que se pode obter melhor eficiência pelo suporte a
CDTs (tipos de dados concretos), os quais são freqüentemente requeridos para
software de tempo crítico, ou seja, com severos requisitos de desempenho de
execução, conforme estudos de Fayad (1999).
21
A linguagem C permitia a geração de código objeto nativo para
plataforma HP-UX, sem necessidade de qualquer nível de interpretação
intermediária para execução das aplicações de negócio, assim, a linguagem
Java também não seria boa escolha de implementação. Ademais, portabilidade
não era necessariamente requisito do projeto FMWLOS, visto que a plataforma
alvo hospedeira das aplicações seria o sistema operacional HP-UX.
3.2 Ferramentas
Algumas ferramentas de software, tais como compiladores,
processadores de texto e CASE foram utilizadas visando suportar o ciclo de
vida de projeto do FMWLOS, as quais foram organizadas por área de aplicação
e com menção aos artefatos de software manipulados com as mesmas,
conforme descrição a seguir:
• Especificação de Requisitos e de Modelos de Software
Microsoft Office 2003 (manuais do usuário, plano de projeto,
especificação técnica, plano de teste);
Microsoft Modeler 1.0 (modelo de classes);
Enterprise Architect 4.0 (arquitetura, modelo de classes, casos de
uso);
Microsoft Visio 2003 (timeline, arquitetura, fluxo de dados);
Graphviz 1.12 (documentação);
Doxygen 1.3.6 (documentação);
• Codificação
Microsoft Visual C++ 6.0 (edição, compilação de código fonte);
GNU C Compiler 3.3.2 for HP-UX 11i (compilação de código fonte
C);
GNU Make 3.80 for HP-UX 11i (compilação de código fonte para
makefiles);
• Gerência de Configuração
Microsoft SharePoint 2005 (repositório de documentação);
Microsoft SourceSafe 6.0 (repositório de código fonte);
• Gerência das Comunicações
22
Microsoft Report Server 1.0 (relatórios gerenciais);
Microsoft Outlook 2003 (e-mails, agendamento de reuniões);
IBM Lotus Notes 5.0 (e-mails, agendamento de reuniões).
• Planejamento de Releases
Microsoft Project 2000 (cronograma).
3.3 Base Técnica
Para construção do framework FMWLOS foi necessário o estudo e
avaliação crítica de variados métodos e técnicas da engenharia de software.
Uma restrição tecnológica do projeto implicava no uso da linguagem C, o que
impedia a utilização de uma linguagem orientada a objetos, tal como C++ ou
Java. A despeito disso, a equipe de projetistas do FMWLOS desejava usar o
paradigma OO na implementação do FMWLOS. Para tanto, os projetistas
buscaram informações na literatura acerca de como proceder à implementação
de técnicas da OO presentes na linguagem C++ com uso da linguagem C. Os
projetistas do FMWLOS encontram a descrição de tais técnicas OO
amplamente detalhadas em Loudon (2000) e Lippman (1996), os quais
são referências recomendadas acerca de tecnologia OO. Em Loudon (2000)
estão disponíveis explanações para todos os algoritmos e estruturas de dados
fundamentais utilizadas na implementação do núcleo e principais bibliotecas de
“classes” do framework FMWLOS. Em Lippman (1996) estão concentradas as
orientações de como reproduzir o modelo OO de C++ com uso de linguagem C.
Depois de capacitados nestas técnicas para implementação da OO os
projetistas partiram para a organização estrutural do FMWLOS e iniciaram os
trabalhos de codificação de “classes” para o núcleo e os incrementos internos
propriamente ditos.
Como plataforma alvo de operação das aplicações de negócio seria o
sistema HP-UX 11i, tal requisito não-funcional do projeto FMWLOS exigiu dos
seus projetistas o domínio de bons conhecimentos de teoria de sistemas
operacionais, notadamente, assuntos tais como processos, sistema de
arquivos, gerenciamento de memória. Além disso, houve a necessidade de
obtenção de conhecimento para recursos de programação de aplicativos do
sistema operacional HP-UX, destacando API de 64 bits para manipulação de
23
arquivos com tamanho superior a 2 GBytes, estruturas de makefiles, extensões
da API de sockets do protocolo TCP/IP.
O modelo de colaboração de “classes” do FMWLOS demandou dos seus
desenvolvedores a implementação de padrões de projeto tais como Método
Fábrica, Bridge, Singleton, Adapter e, para tal a referência da literatura técnica
consultada para exemplos de codificação foi Gamma (1995). Por exemplo, a
figura 4 abaixo demonstra como a especificação do modelo de classes para API
de Memória Compartilhada do FMWLOS estabelece uma interface de serviços
uniforme, porém culminando em diversas implementações regidas pelo padrão
de projeto Bridge Pattern.
cd Visão Geral do Pacote (Applib)
TSharedMemory TSharedMemoryImp
TSVSharedMemory TMMSharedMemory TNilSharedMemory
Figura 4: Exemplo modelo de classes da API Shared Memory de FMWLOS.
Para especificação dos modelos de software do FMWLOS seus
projetistas utilizaram a notação da UML com suporte de ferramentas CASE tais
como Microsoft Modeler e Enterprise Architect. Ainda para representação dos
modelos de software, a notação de grafo de dependência entre “classes”
FMWLOS foi utilizada com suporte das ferramentas Graphviz (geração de
grafos de “classes”) e Doxygen (documentação de “classes” estilo Javadoc).
Alguns conhecimentos específicos da API do sistema operacional
Windows também foram necessários aos projetistas e programadores do
FMWLOS com vistas a tornar sua implementação utilizável num contexto
multiplataforma (Windows, Unix).
24
3.4 Processos
O desenvolvimento do framework FMWLOS foi orientado por processos
iterativos e incrementais. Iterativo devido não ser possível o conhecimento
pelos projetistas de todas as nuances, particulares e necessidades do domínio
de negócio, num primeiro estágio de criação do produto framework. Outra razão
para abordagem iterativa é que o framework torna explícito partes de seu
projeto abstrato que são passíveis de mudanças, tais como componentes ou
bibliotecas de classes que são relativamente mais fáceis de alterar e
reorganizar. Quanto às interfaces de serviços e algoritmos do kernel são difíceis
de mudar e não desejáveis por conta da manutenção de compatibilidade com
aplicações existentes no ambiente de produção. Ressalta-se que, a cada
iteração completa de análise e projeto do framework FMWLOS contempla-se a
atividade de teste, a qual é realizada usando componentes do próprio FMWLOS
para implementar novos protótipos de aplicações exemplo, utilizadas para
avaliar a usabilidade do framework e decidir se o FMWLOS está
suficientemente confiável e maduro para lançamento em produção. A
documentação em cada iteração do projeto FMWLOS também ocupa
importante esforço de realização do produto visando descrever como utilizar o
FMWLOS, atualizar os manuais de treinamento e, especificar o projeto abstrato
do FMWLOS para demonstrar como o framework trabalha. Todo lançamento de
nova versão do FMWLOS incluía obrigatoriamente a devida atualização e
publicação para toda documentação associada ao produto.
A abordagem incremental torna-se necessária, pois o framework requer
profundo conhecimento do domínio de aplicação e é difícil construí-lo sob o
contexto de um planejamento de um projeto de mais amplitude, conforme
esclarece Fayad (1999). Assim, projeto de framework de software nunca deve
estar no caminho crítico de um produto ou serviço mais importante da
organização, ou seja, com impactos diretos no modelo de negócio. Além disso,
organizar o desenvolvimento do produto em releases intermediários em
contraposição a um release “big-bang” reduz riscos do projeto pela obtenção de
feedback dos desenvolvedores de aplicação logo nos releases iniciais do
framework, de acordo com Ambler (2001). A abordagem de desenvolvimento
25
incremental também possibilita o lançamento de aplicações de negócio em
ambiente de produção montadas com distintas versões do framework
FMWLOS, cada qual com avanços de funcionalidades diferentes, enquanto
possibilita desenvolver o FMWLOS em paralelo com o desenvolvimento de
várias aplicações de negócio que o utilizam, conforme ratifica Pfleeger (2003).
Figura 5: Modelo de Desenvolvimento por Fases do Framework FMWLOS.
Ressalta-se a importância do processo de controle de mudanças,
destinado a documentar e manter registros dos avanços e das obsolescências
de funcionalidades nos distintos releases do framework FMWLOS. Em resumo,
a norma geral para documentar os registros de mudanças no produto
estabelecia que as alterações em artefatos de software (código e
documentação) devem ser registradas em documento específico de Controle de
Mudanças, o qual deve contemplar descrições detalhadas das mudanças
incluídas em novas revisões desses artefatos. As mudanças devem comentar a
necessidade, a solução, a questão ou incidente de produção associado que
26
originou a manutenção, a data de liberação da nova revisão do artefato.
Ademais, o núcleo do FMWLOS congrega serviço de identificação de versão
corrente compilada, o que permite a uma aplicação de negócio em ambiente de
produção saber exatamente com qual versão do FMWLOS foi empregada em
sua construção. Essencialmente, quando a aplicação de negócio invoca o
comando de ajuda para se obter informação acerca de sua própria versão,
automaticamente, a versão do FMWLOS é apresentada, conforme
exemplificado a seguir: /home/halan/desenv/middleware/debug/Consulta_Generica/ > Consulta_Generica -?? 20050304,200952,Consulta_Generica 1.24 - Feb 11 2005 19:26:30 20050304,200952,Framework FMWLOS 1.55 - Dec 6 2004 17:58:54
27
4 ESTUDO DE CASO
4.1 Breve Histórico
No início do ano de 2001, a divisão de suporte de software básico do
HSBC/Losango observou que o ambiente de desenvolvimento de aplicações de
software para suporte ao negócio estava bastante desordenado, não
uniformidade, com crescente incidência de falhas de software na operação com
conseqüentes interrupções no fornecimento dos serviços de TI, incidindo em
prejuízos ao modelo de negócio. A falta de definição para padrões de
desenvolvimento (frameworks, design patterns, DBC, bibliotecas de códigos
reusáveis, APIs), padrões de programação (refactoring, POO) e padrões de
arquitetura (SOA, Pipelines, Orientada a Eventos, Cliente-Servidor, Repositório,
MVC) tornavam os projetos de soluções baseadas em software muito mais
demorados e consequentemente mais caros. Os requisitos de negócio no
âmbito do mercado financeiro quase sempre requerem o desenvolvimento
rápido de soluções de automação, pois do contrário, incorrem-se riscos de não
se viabilizar a tempo as demandas do negócio ou mesmo perda de clientela
para concorrência.
Também, havia necessidade de evolução para o middleware de
aplicativos presente na arquitetura de informação de suporte ao modelo de
negócio, no sentido de torná-la facilmente extensível, customizável, mais
robusta, de melhor desempenho e de manutenção operacional simples. O
middleware essencialmente envolvia a integração dos canais front-end de
interfaces diretas com o usuário (lojistas) com serviços back-end hospedados
em plataformas Unix e MainFrame, responsáveis pela execução de workflows
automáticos de avaliação e autorização de propostas de crédito, incluindo
consulta a dados disponibilizados por sistemas de informação de parceiros
como SERASA/SPC/TELECHEQUE. Neste caso, novas demandas de
desenvolvimento conseqüentes de necessidades de expansão do middleware,
por conta de mudanças no ambiente de negócio, deveriam ser suportadas por
um framework de software capaz de acelerar a construção de novos produtos e
serviços e, com maior confiabilidade.
28
O desenvolvimento de uma infra-estrutura de software uniforme tornou-
se imperativa visando estabelecer padrões de construção, documentação,
certificação e possibilitar maior agilidade no desenvolvimento de novos
produtos de software, com envolvimento de todas as equipes de
desenvolvedores disponibilizados pelos fornecedores do HSBC/Losango. Os
benefícios tangíveis deste empreendimento consistiam basicamente nos
seguintes:
• Melhores índices de produtividade das equipes de desenvolvedores;
• Produtos de melhor qualidade, mais confiáveis e padronizados;
• Redução dos custos e tempo envolvidos no desenvolvimento de
software;
• Maior flexibilidade na estrutura do software produzido, facilitando sua
manutenção corretiva e evolutiva;
• Melhorias de performance e confiabilidade;
• Documentação abrangente.
Devido à carência por uma infra-estrutura de desenvolvimento de
software padrão, documentada e com suporte técnico de especialistas para
treinamento e capacitação de novas equipes de desenvolvedores, a divisão de
suporte de software básico do HSBC/Losango decidiu pela contratação de
serviços profissionais especializados para construção de solução de framework
de software sob encomenda. No caso, os serviços prestados por algum
fornecedor de software deveriam contemplar suporte técnico a evolução do
produto, incluir o destacamento de equipe de especialistas para o processo de
desenvolvimento (engenheiros, programadores, documentadores) e fornecer
todos os artefatos associadas à criação do novo produto (código fonte, planos
de teste, projeto técnico, manuais de treinamento, cronogramas).
4.2 Descrição do Caso
O framework de software neste estudo de caso, vulgo FMWLOS, foi
desenvolvido com propósito de possibilitar principalmente a construção de
aplicações de software transacionais (webservice) e de processamento de
dados em lote (batch) a serem hospedadas em plataforma Unix, notadamente,
29
sistemas HP-UX. Entretanto, não há impedimento técnico para seu uso no
desenvolvimento de aplicações orientadas a plataforma Microsoft Windows,
pois as classes de objetos implementadas agregam recursos da API nativa do
sistema operacional Windows e, além disso, existem recursos de configuração
e compilação condicional no código fonte do framework FMWLOS visando
proporcionar desenvolvimento de aplicações com caráter multi-plataforma.
O projeto do framework FMWLOS deveria atender aos requisitos de
software que especificavam as seguintes necessidades:
• Disponibilizar um modelo de aplicação canônica, a qual deveria
comportar de forma estruturada e simples a lógica específica de
aplicação a ser desenvolvida pelo usuário do framework (programador);
• Publicar um idioma de programação no sentido de uniformizar o padrão
de codificação de novas aplicações, incluindo normas para inclusão de
comentários, endentação do código fonte, nomeação de métodos,
variáveis, constantes, especificação de expressões lógicas, relacionais e
aritméticas, enfim, um manual prático com diretrizes de boas práticas de
desenvolvimento;
• Dispor de biblioteca reutilizável de recursos de programação ampla, de
interface bem definida e de fácil incorporação às novas aplicações, no
sentido de maximizar a reutilização de software evitando o “reinventar a
roda”. A construção de novas aplicações de software deveria ser focada
na implementação de lógica de negócio. Portanto, algumas
funcionalidades comuns a uma ampla família de aplicações incluem:
processamento de cadeias de caracteres, manipulação de arquivos de
configuração (INI), processamento documentos XML, controle de
concorrência e sincronização, comunicação inter-processos,
processamento concorrente (multithreading), coleções de objetos,
acesso a dados em bancos de dados relacionais, gerenciamento de
arquivos em disco e dentre outros recursos.
A organização estrutural do projeto do framework FMWLOS consiste de
bibliotecas de classes de objetos categorizadas por grandes grupos de
funcionalidades, a saber:
30
• Núcleo (kernel):
APPLIB
Classes de Lógica de Aplicação Canônica;
Classes de Algoritmo do Kernel;
• Incrementos internos (bibliotecas de classes):
APPLIB
Classes de Coleção;
Classes de Gerenciamento de Memória;
Classes de Manipulação Arquivos de Configuração (INI);
Classes de Gerenciamento de Arquivos em Disco;
Classes de Tratamento de Exceções;
Classes de Controle de Concorrência e Sincronismo;
Classes de Processamento de Cadeias de Caracteres
(Strings);
MQLIB
Classes de Gerenciamento de Filas de Mensagens;
SQL2LIB
Classes de Acesso a Dados;
ORALIB
• Classes de Acesso a Dados em Bancos Oracle;
SYBLIB
• Classes de Acesso a Dados em Bancos Sybase;
SDWLIB
• Classes de Acesso a Dados em Bancos DB2;
XMLLIB
Classes de Manipulação Documentos XML;
STHLIB
Classes de Multiprocessamento;
MSVLIB
Classes de Protocolos de Serviços Web;
NETLIB
Classes de Comunicação de Dados.
31
O framework de software FMWLOS provê um esqueleto arquitetural
customizável por herança e instanciação de componentes reutilizáveis visando
à montagem de uma família de aplicações relacionadas. A arquitetura do
framework FMWLOS é ilustrada na figura 6 abaixo.
Figura 6: Arquitetura de Componentes do Framework FMWLOS.
32
4.3 Análise da Situação
4.3.1 Modelo de Classes no Núcleo (Kernel)
cd Classes Kernel FMWLOS x Aplicação
AppLib::TApp
+ TApp(void)+ ~TApp(void)+ Init(int, char*) : BOOL+ Run(void) : void+ Exit(void) : void+ DisplayHelp(void) : void+ DisplayVersion(void) : void+ TraceOut(char*) : void+ TraceErr(char*) : void+ TraceLog(char*, char*) : void+ PrintOut(char*) : void+ PrintErr(char*) : void+ PrintLog(char*, char*) : void+ Print(char*, FILE*, char*, va_list) : void+ Puts(char*, FILE*, char*) : void+ SetOutFileName(char*, char*) : void+ GetOutFileName(void) : char*+ SetErrFileName(char*, char*) : void+ GetErrFileName(void) : char*+ SetAbortFlag(BOOL) : void+ GetAbortFlag(void) : BOOL+ GetNullFileName(void) : char*
MyApplication::TMyApp
+ TMyApp(void)+ ~TMyApp(void)+ Init(int, char*) : BOOL+ Run(void) : void+ Exit(void) : void+ DisplayHelp(void) : void+ DisplayVersion(void) : void
AppLib::TMain
+ TMain(void) : void+ ~TMain(void) : void+ main(int, char*) : int
1
+Kernelexecute
1..*
+Hot Spots
-m_pApp
generate
Figura 7: Modelo de Classes Kernel Framework FMWLOS e Aplicação.
Resumidamente, no modelo abstrato de classes da figura 7, a classe
TApp publica os métodos virtuais TApp_Init, TApp_Run, TApp_Exit
TApp_DisplayHelp e TApp_DisplayVersion, que representam os hot spots
customizáveis do framework FMWLOS, a serem estendidos pela subclasse de
lógica da aplicação do negócio, no exemplo, classe TMyApp. A classe TApp
publica outros métodos públicos de propósito geral para todas aplicações,
incluindo serviços para registros das atividades de processamento em log das
trilhas de auditoria e dentre outras utilidades. A classe TMain representa os
algoritmos e estruturas de dados do kernel do FMWLOS, ou seja, os frozen
33
spots imutáveis e presentes em todas as aplicações de negócio construídas
com uso do framework. A classe TMain encapsula os detalhes necessários
para execução da aplicação de negócio do usuário, incluindo tratamento de
sinais do sistema operacional, manipulação de callbacks e dentre os controles
de fluxo de execução. Observe que este modelo é uma representação
ilustrativa da implementação em código fonte, pois a construção do FMWLOS
utiliza linguagem de programação C para viabilizar seu projeto abstrato por via
do paradigma OO.
4.3.2 Modelo de Algoritmo do Kernel (Frozen Spots)
Descreve estrutura padrão de arquivos de código fonte para algoritmo
básico do núcleo do framework FMWLOS. Representa detalhes de
implementação da classe TMain, incluindo os comentários de demonstração de
como frozen spots procedem a invocação do código fonte dos hot spots da
aplicação desenvolvida pela usuário do framework FMWLOS. Ressalta-se que,
o núcleo do FMWLOS, o qual controle o fluxo de execução para todas as
aplicações de negócio, é essencialmente representado pelo método main (int,
char*) especificado na classe TMain.
• Módulo Main.h // ======================================================================== /*! * @file Main.h * @ingroup Applib * * @brief Módulo principal da aplicação. * * @remarks HSBC/Losango - Framework FMWLOS. * @remarks Algoritmo Básico do Kernel, inclui os frozen spots imutáveis. * * @version 1.0.0.0 - 22/04/2001 - Halan Alves. * @version Versão inicial. */ // ======================================================================== #ifndef _Main_H_3D5F9590_D3BF_4C82_B676_7CD9C333A96F_ #define _Main_H_3D5F9590_D3BF_4C82_B676_7CD9C333A96F_ #ifdef _MSC_VER #pragma once #endif /////////////////////////////////////////////////////////////////////////// #include "ApplibDefs.h" /////////////////////////////////////////////////////////////////////////// /* * Constantes.
34
*/ // ------------------------------------------------------------------------ /* * Interface. */ // ------------------------------------------------------------------------ int main (int argc, char* argv []); int GetSignalValue (int nSignal); void SetSignalValue (int nSignal, int nValue); void IncSignalValue (int nSignal); /////////////////////////////////////////////////////////////////////////// #endif // ========================================================================
• Módulo Main.c // ======================================================================== /*! * @file Main.c * @ingroup Applib * * @brief Módulo principal da aplicação. * * @remarks HSBC/Losango - Framework FMWLOS. * @remarks Algoritmo Básico do Kernel, inclui os frozen spots imutáveis. * * @version 1.0.0.0 - 22/04/2001 - Halan Alves. * @version Versão inicial. */ // ======================================================================== #include "Applib.h" // ------------------------------------------------------------------------ /* * Controle de mensagens de TRACE. */ // ------------------------------------------------------------------------ #define TRACEX TRACE #define TRACEXIF TRACEIF #define TRACEXIN TRACEIN #define TRACEXOUT TRACEOUT #undef _FILE_ static const char _FILE_ [] = __FILE__; // ------------------------------------------------------------------------ /* * Atributos estáticos. */ // ------------------------------------------------------------------------ /*! * Array de Signals */ static int aSignals [] = { 0, /* SIGINT */ 0, /* SIGTERM */ 0, /* SIGPIPE */ 0, /* SIGALRM */ 0, /* SIGSEGV */
35
0 /* SIGHUP */ }; /*! * Obtém o índice do sinal no array. * * @return Índice do sinal no array. */ static UINT GetSignalArrayIndex (int nSignal) { UINT nIndex; switch (nSignal) { case SIGINT: nIndex = 0; break; case SIGTERM: nIndex = 1; break; case SIGPIPE: nIndex = 2; break; case SIGALRM: nIndex = 3; break; case SIGSEGV: nIndex = 4; break; case SIGHUP: nIndex = 5; break; default: { BUGCHECK_STATIC (); /* Valor inválido. */ nIndex = 0; } } return nIndex; } /*! * Obtém o nome do sinal. * * @return Nome do sinal. */ static const char* GetSignalName (int nSignal) { const char* pszSignal; switch (nSignal) { case SIGINT: pszSignal = "SIGINT"; break; case SIGTERM: pszSignal = "SIGTERM"; break; case SIGPIPE: pszSignal = "SIGPIPE"; break; case SIGALRM: pszSignal = "SIGALRM"; break; case SIGSEGV: pszSignal = "SIGSEGV"; break; case SIGHUP: pszSignal = "SIGHUP"; break; default: { pszSignal = "UNKNOWN"; } } return pszSignal; } /*! * Obtém o valor do sinal. O sinal representa uma interrupção do sistema operacional. * * @param nSignal Código do sinal. * * @return Status do sinal. */ int GetSignalValue (int nSignal) { UINT nIndex = GetSignalArrayIndex (nSignal);
36
ASSERT (nIndex < countof (aSignals)); NOTRACE ("GetSignalValue; %s nValue=%d.\n", GetSignalName (nSignal), aSignals [nIndex]); return aSignals [nIndex]; } /*! * Define o valor do sinal. * * @param nSignal Código do sinal. * * @param nValue Valor do contador. */ void SetSignalValue (int nSignal, int nValue) { UINT nIndex = GetSignalArrayIndex (nSignal); ASSERT (nIndex < countof (aSignals)); NOTRACE ("SetSignalValue; %s nValue=%d.\n", GetSignalName (nSignal), nValue); aSignals [nIndex] = nValue; } /*! * Incrementa o valor de um sinal. * * @param nSignal Código do sinal. */ void IncSignalValue (int nSignal) { UINT nIndex = GetSignalArrayIndex (nSignal); ASSERT (nIndex < countof (aSignals)); NOTRACE ("IncSignalValue; %s nValue=%d.\n", GetSignalName (nSignal), aSignals [nIndex]); aSignals [nIndex]++; } /*! * Tratador de sinais do sistema operacional. * * @param nSignal Código do sinal. */ static void SignalHandler (int nSignal) { /* ATENÇÃO: NUNCA habilite o TRACE a seguir em produção! */ #ifdef _DEBUG TRACE ("SignalHandler - sig=%d (%s)\n", nSignal, GetSignalName (nSignal)); #endif IncSignalValue (nSignal); signal (nSignal, SignalHandler); } /*! * Tratador de sinais específico para SIGSEGV (Segmentation fault). * * @param nSignal Código do sinal. */ static void SigsevHandler (int nSignal)
37
{ /* ATENÇÃO: NUNCA habilite o TRACE a seguir em produção! */ #ifdef _DEBUG TRACE ("SigsevHandler - sig=%d (%s)\n", nSignal, GetSignalName (nSignal)); #endif IncSignalValue (nSignal); signal (nSignal, SigsevHandler); BUGCHECK_STATIC (); } /*! * Tratador de exceções do sistema operacional. * * @param nExceptionCode Valor do código de exceção. * @param pExceptionInfo Valor do código de informação. * * @return Filtragem da exceção. */ #ifdef WIN32 static int ExceptionFilter (DWORD nExceptionCode, PEXCEPTION_POINTERS pExceptionInfo) { if (nExceptionCode == EXCEPTION_BREAKPOINT) { /* Ignora se breakpoint */ if (*((byte*) pExceptionInfo->ContextRecord->Eip) == 0xCC) { pExceptionInfo->ContextRecord->Eip++; /* Salta BPT */ return EXCEPTION_CONTINUE_EXECUTION; } return EXCEPTION_EXECUTE_HANDLER; } return EXCEPTION_CONTINUE_SEARCH; } #endif /*! * Rotina principal. * * @param argc Número inteiro. * @param argv String * * @return Ponto de entrada da aplicação. */ int main (int argc, char* argv []) { int nStatus; /* Status de retorno */ #ifdef WIN32 #ifdef _DEBUG int nFlags = _CrtSetDbgFlag (_CRTDBG_REPORT_FLAG); nFlags |= _CRTDBG_ALLOC_MEM_DF; /* Enable debug heap allocations and use of memory block type identifiers. */ nFlags |= _CRTDBG_CHECK_ALWAYS_DF; /* Call _CrtCheckMemory at every allocation and deallocation request. */
38
nFlags |= _CRTDBG_LEAK_CHECK_DF; /* Perform automatic leak checking at program exit via a call to _CrtDumpMemoryLeaks and generate an error report if the application failed to free all the memory it allocated. */ nFlags |= _CRTDBG_DELAY_FREE_MEM_DF; /* Keep freed memory blocks in the heap’s linked list, assign them the _FREE_BLOCK type, and fill them with the byte value 0xDD. */ nFlags &= ~_CRTDBG_CHECK_CRT_DF; /* Include _CRT_BLOCK types in leak detection and memory state difference operations. */ _CrtSetDbgFlag (nFlags); #endif #else long nCpuVersion = sysconf (_SC_CPU_VERSION); if (! CPU_IS_PA_RISC (nCpuVersion)) { fprintf (stderr, "CPU incompatível (%lX)\n", nCpuVersion); return TApp_EXIT_FAIL; } #ifdef _PA_RISC2_0 if (nCpuVersion < CPU_PA_RISC2_0) { fprintf (stderr, "PA-RISC não é 2.0 (%lX)\n", nCpuVersion); return TApp_EXIT_FAIL; } #endif #endif if (! TApp_Initialize ()) { TApp_Terminate (); EXIT (TApp_EXIT_FAIL); } TRY { #ifdef WIN32 __try { #endif SIGNALPROC pSignal; /* Tratador de signal original */ #ifdef WIN32 pSignal = signal (SIGTERM, SignalHandler); VERIFY (pSignal == SIG_DFL || pSignal == SIG_IGN); #else pSignal = signal (SIGINT , SignalHandler); VERIFY (pSignal == SIG_DFL || pSignal == SIG_IGN); pSignal = signal (SIGTERM, SignalHandler); VERIFY (pSignal == SIG_DFL || pSignal == SIG_IGN); pSignal = signal (SIGPIPE, SignalHandler); VERIFY (pSignal == SIG_DFL || pSignal == SIG_IGN); pSignal = signal (SIGALRM, SignalHandler); VERIFY (pSignal == SIG_DFL || pSignal == SIG_IGN); pSignal = signal (SIGHUP , SignalHandler); VERIFY (pSignal == SIG_DFL || pSignal == SIG_IGN);
39
#endif #ifndef _DEBUG pSignal = signal (SIGSEGV, SigsevHandler); VERIFY (pSignal == SIG_DFL || pSignal == SIG_IGN); #endif if (TApp_Init (argc, argv)) { TApp_Run (); } TApp_Exit (); nStatus = TApp_GetExitStatus (); #ifdef WIN32 } __except (ExceptionFilter (GetExceptionCode (), GetExceptionInformation ())) { ThrowUserException (FORMAT ("Exceção win32 desconhecida: %lX"), GetExceptionCode ()); } #endif } CATCH_ALL (e) { TException_ReportError (e, NULL); TException_Delete (e); nStatus = TApp_EXIT_FAIL; } END_CATCH TApp_Terminate (); EXIT (nStatus); return nStatus; // Não deve chegar aqui! }
4.3.3 Modelo de Aplicação Canônica (Hot Spots)
Descreve estrutura padrão de arquivos de código fonte para esqueleto
de aplicação do tipo processamento em lote e dependências com framework
FMWLOS. Inclui comentários de orientação acerca de como proceder com a
customização ou preenchimento de código fonte pelo programador sob os hot
spots disponibilizados pelo framework FMWLOS. Observe que aplicação
canônica foi customizada para invocar a lógica específica de negócio
implementada na aplicação exemplo, demonstrada adiante. Relembrando que,
os hot spots representam os pontos de flexibilidade que podem ser
customizados para adaptar o esqueleto provido pelo framework a aplicação de
negócio a ser gerada pelo usuário do FMWLOS (programador, desenvolvedor
de aplicação). Para dúvidas quanto à sintaxe expressa em código fonte sugere-
se rever a seção Notação Sintática.
• Módulo MyApplication.h
40
// ======================================================================== /*! * @file MyApplication.h * @ingroup Exemplo * * @brief Módulo de Interface com Kernel, inclui hot spots customizáveis. * * @remarks HSBC/Losango – Framework FMWLOS. * @remarks Modelo de Aplicação Canônica. * * @version 1.0.0.0 - 15/02/2002 - Halan Alves. * @version Versão inicial. */ // ======================================================================== #ifndef _MyApplication_H_10EDB5A0_75C1_4182_8214_080D7FFD8FD9_ #define _MyApplication_H_10EDB5A0_75C1_4182_8214_080D7FFD8FD9_ #ifdef _MSC_VER #pragma once #endif // ------------------------------------------------------------------------ /* * Interface. */ // ------------------------------------------------------------------------ void TApp_DisplayHelp (const char* pszMessage); void TApp_DisplayVersion (void); BOOL TApp_Init (int nArgs, char* pszArgs []); void TApp_Run (void); void TApp_Exit (void); /////////////////////////////////////////////////////////////////////////// #endif // ========================================================================
• Módulo MyApplication.c // ======================================================================== /*! * @file MyApplication.c * @ingroup Exemplo * * @brief Módulo de Interface com Kernel, inclui hot spots customizáveis. * * @remarks HSBC/Losango – Framework FMWLOS. * @remarks Modelo de Aplicação Canônica. * * @version 1.0.0.0 - 15/02/2002 - Halan Alves. * @version Versão inicial. */ // ======================================================================== #include "Applib.h" #include "Netlib.h" #include "Exemplo.h" // ------------------------------------------------------------------------ /* * Controle de mensagens de TRACE. */ // ------------------------------------------------------------------------ #define TRACEX TRACE #define TRACEXIF TRACEIF
41
#define TRACEXIN TRACEIN #define TRACEXOUT TRACEOUT #undef _FILE_ static const char _FILE_ [] = __FILE__; // ------------------------------------------------------------------------ /* * Atributos estáticos. */ // ------------------------------------------------------------------------ static TIniFile* m_pIniFile; /*!< Arquivo de configuração */ /*! * Mostra mensagem de ajuda. * * @param pszMessage String que armazena a mensagem de ajuda. */ void TApp_DisplayHelp (const char* pszMessage) { if (pszMessage == NULL) { TApp_PrintErr ("Uso: Exemplo arqcfg\n"); TApp_PrintErr (" arqcfg - Nome do arquivo de configuração\n"); } else TApp_PrintErr ("%s\n", pszMessage); } /*! * Mostra versão da aplicação. */ void TApp_DisplayVersion (void) { TApp_PrintErr ("Exemplo 1.00 - %s %s\n", __DATE__, __TIME__); } /*! * Inicializa aplicação. * * @param nArgs Quantidade de argumentos no arquivo de configuração. * @param pszArgs Descrição dos argumentos em texto. * * @return Resultado da chamada dos argumentos dispostos no arquivo de * configuração, e chamada do arquivo de saída de trace. */ BOOL TApp_Init (int nArgs, char* pszArgs []) { TStr* strTraceFileName; /* Arquivo de saída de trace */ /* Inicializa globais */ m_pIniFile = NULL; /* Analisa linha de comando */ TApp_HelpDefault (nArgs, pszArgs); if (nArgs == 2) { m_pIniFile = TIniFile_CreateInstance (pszArgs [1]); } else { TApp_HelpExit (TApp_HELP_ERROR); }
42
/* Estabelece arquivo de saída de trace */ strTraceFileName = TIniFile_GetStringEx (m_pIniFile, m_szAppGlobalSettings, "TraceFileName"); #ifdef WIN32 #ifdef _DEBUG TStr_ReleaseBuffer (strTraceFileName, strlen (StripPath (TStr_GetBuffer (strTraceFileName, 0)))); #endif #endif SetTraceFileName (TStr_GetText (strTraceFileName), NULL); TStr_ReleaseInstance (strTraceFileName); /* Retorna informando sucesso */ return TRUE; } /*! * Executa aplicação. */ void TApp_Run (void) { char szDateTime [64]; /* Data e hora atual */ TApp_PrintOut ("Exemplo ativado: %s\n", FormatDateTime (szDateTime, countof (szDateTime), NULL, NULL)); TRY { Exemplo (m_pIniFile); } CATCH_ALL (e) { TException_ReportError (e, "TApp_Run"); TException_Delete (e); TApp_SetExitStatus (TApp_EXIT_FAIL); } END_CATCH TApp_PrintOut ("Exemplo desativado: %s\n", FormatDateTime (szDateTime, countof (szDateTime), NULL, NULL)); } /*! * Finaliza aplicação. */ void TApp_Exit (void) { TIniFile_ReleaseInstance (m_pIniFile); }
4.3.4 Exemplo de Lógica Específica de Aplicação
Descreve exemplo simples para orientação de como proceder à
implementação da lógica específica de aplicação de negócio. Observe que os
hot spots na aplicação canônica foram customizados para invocar as rotinas
nos módulos da aplicação exemplo, as quais efetivamente respondem pela
43
execução da lógica de negócio implementada pelo usuário do framework
FMWLOS.
• Módulo Exemplo.h // ======================================================================== /*! * @file Exemplo.h * @ingroup Exemplo * * @brief Aplicação exemplo do uso de classes do Framework. * * @remarks HSBC/Losango – Framework FMWLOS. * @remarks Exemplo de Aplicação. * * @version 1.0.0.0 - 15/02/2002 - Halan Alves. * @version Versão inicial. */ // ======================================================================== #ifndef _Exemplo_H_53A977F6_2BCF_4E98_A027_08A0C77AAFA1_ #define _Exemplo_H_53A977F6_2BCF_4E98_A027_08A0C77AAFA1_ #ifdef _MSC_VER #pragma once #endif /* * Constantes. */ /* * Atributos globais. */ extern char m_szAppGlobalSettings []; /*!< Nome da seção de parâmetros globais */ // ------------------------------------------------------------------------ /* * Interface. */ // ------------------------------------------------------------------------ void Exemplo (TIniFile* pIniFile); /////////////////////////////////////////////////////////////////////////// #endif // ========================================================================
• Módulo Exemplo.c // ======================================================================== /*! * @file Exemplo.c * @ingroup Exemplo * * @brief Aplicação exemplo do uso das classes do Framework. * * @remarks HSBC/Losango – Framework FMWLOS. * @remarks Exemplo de Aplicação. * * @version 1.0.0.0 - 15/02/2002 - Halan Alves. * @version Versão inicial. */ // ======================================================================== #include "Applib.h"
44
#include "Netlib.h" #include "Exemplo.h" // ------------------------------------------------------------------------ /* * Controle de mensagens de TRACE. */ // ------------------------------------------------------------------------ #define TRACEX TRACE #define TRACEXIF TRACEIF #define TRACEXIN TRACEIN #define TRACEXOUT TRACEOUT #undef _FILE_ static const char _FILE_ [] = __FILE__; /* * Constantes. */ // ------------------------------------------------------------------------ /* * Atributos globais. */ // ------------------------------------------------------------------------ /*! * Nome da seção de parâmetros globais no arquivo de configuração */ char m_szAppGlobalSettings [] = "AppGlobalSettings"; // ------------------------------------------------------------------------ /* * Atributos estáticos. */ // ------------------------------------------------------------------------ // ------------------------------------------------------------------------ /* * Parâmetros de configuração */ // ------------------------------------------------------------------------ int m_nTraceLevel; /*!< 0-sem trace; 1-com trace */ /* * Uso geral */ /*! * Pré-inicializa parâmetros de execução do programa. */ void PreLoadParam (void) { } /*! * Carrega parâmetros de execução do programa. */ void LoadParam (TIniFile* pIniFile) { m_nTraceLevel = TIniFile_GetInteger (pIniFile, m_szAppGlobalSettings, "TraceLevel"); TRACE ("m_nTraceLevel = %d\n", m_nTraceLevel); }
45
/*! * Libera parâmetros de execução do programa. */ void UnloadParam (void) { } /*! * Exemplo da aplicação. */ void Exemplo (TIniFile* pIniFile) { /* Inicializa parâmetros */ PreLoadParam (); /* Bloco de trabalho */ TRY { /* Carrega parâmetros do arquivo de configuração */ LoadParam (pIniFile); /* Implementa funções do negócio (neste exemplo não faz nada) */ TRACE ("Exemplo funcionando...\n"); /* Estabelece status de sucesso */ TApp_SetExitStatus (TApp_EXIT_SUCCESS); } CATCH_ALL (e) { TException_ReportError (e, "Exemplo"); TException_Delete (e); TApp_SetExitStatus (TApp_EXIT_FAIL); } END_CATCH /* Destrói parâmetros */ UnloadParam (); }
• Arquivo de Configuração Exemplo.ini #* ================================================================ *# #* Empresa: HSBC/Losango. *# #* Projeto: FMWLOS. *# #* Módulo: Exemplo de Aplicação. *# #* Descrição: Arquivo de inicialização. *# #* Arquivo: Exemplo.ini *# #* ---------------------------------------------------------------- *# #* Versão: 1.0.0.0 - 15/02/2002 *# #* Descrição: Versão inicial. *# #* Autor: Halan Alves. *# #* ================================================================ *# [AppGlobalSettings] TraceLevel = 0 # 0-sem trace; 1-com trace TraceFileName = $MSDIR/log/Exemplo.trace # Nome do arquivo de saída de trace
46
5 CONCLUSÕES
Acreditamos que a abordagem de framework de software deve ser
considerada frente às necessidades de produção de software em larga escala e
para o qual os requisitos de negócio se alteram rapidamente. Ademais, a
tecnologia de frameworks de software provê alto grau de reutilização da
solução, incluindo modelos abstratos de domínio, padrões de projeto e
implementação em código fonte. Portanto, frameworks reduzem o montante de
código específico da aplicação por conta da fatoração de processamento de
informação específica do domínio em componentes genéricos, disponibilizando
ao programador uma aplicação quase completa. Esta abordagem de
desenvolvimento vem alavancar o conhecimento de um desenvolvedor de
framework, pois possibilita ao mesmo ter pré-determinado quais bibliotecas e
componentes utilizar, quais padrões de projeto seguir e como entidades
técnicas da solução devem interagir.
Particularmente, participar como integrante ativo da equipe de
desenvolvedores do framework FMWLOS foi uma experiência enriquecedora,
pois proporcionou o desafio de buscar, assimilar e colocar em prática uma
ampla base técnica e ferramental da engenharia de software contemporânea.
Contribuir para concepção, elaboração, certificação e realização do produto do
projeto FMWLOS, proporcionou a confrontação com desafios técnicos,
pressões de cronograma, liderança e motivação de pessoal, planejamento de
projeto, definição de padrões doutrinadores para várias equipes de
programadores e reuniões para entendimento de necessidades dos usuários.
Todas estas atividades forçaram o exercício da profissional de engenharia de
software, incluindo uma preocupação constante com a qualidade do produto a
ser construído, o cumprimento de requisitos do projeto e a superação das
expectativas dos usuários. Pela nossa percepção prática adquirida no projeto
do FMWLOS, o experimento e desafio da construção de uma solução de
framework de software realmente proporcionam aos seus criadores uma
satisfação plena e compensatória ao ver um produto fornecendo serviços de
qualidade em determinado modelo de negócio e, como também, o feedback
positivo da alta gerência, as críticas e sugestões dos usuários. A experiência
47
com o projeto FMWLOS é uma prova real que a engenharia de software
profissional, balizada em ética e responsabilidade, pode proporcionar bons
benefícios às demais atividades humanas, incluindo economia de tempo,
esforço, custo e possibilitando produtos e serviços mais confiáveis, flexíveis e
robustos.
Para a divisão de suporte de software básico do HSBC/Losango, mesmo
ainda não contando com métricas formais comprobatórias acerca do retorno do
investimento, a percepção obtida com feedback das áreas usuárias da
corporação, corrobora a afirmação que a solução tecnológica provida por um
framework de software realmente concede benefícios técnicos e econômicos.
Para este departamento da empresa, é possível afirmar com boa aproximação
que a adoção de um framework de software está viabilizando a realização de
projetos para novos produtos e serviços em muito menor tempo, esforço e
custo. No caso, o incremento de produtividade atual é comparado aos tempos
que o modelo de desenvolvimento estava regido independentemente por cada
fornecedor particular e comumente alicerçado em bibliotecas de componentes
de software de propósito geral e linguagens de programação diversas, em
alguns casos incompatíveis entre si quando examinados para fins de integração
de aplicações de negócio. Com o uso do produto FMWLOS, o departamento
alavancou os resultados do processo de desenvolvimento de novos produtos,
estabelecendo e publicando diretrizes uniformes para a realização dos
trabalhos das diversas equipes de desenvolvedores, propagando na corporação
uma cultura orientada ao reuso de software, suportando a entrega de mais
novidades em serviços para o modelo de negócio em menores intervalos de
tempo. A despeito deste incremento na melhoria da qualidade de software e
minimização de esforço e custos de desenvolvimento, para o departamento, o
desafio prossegue convergindo para as iniciativas de aperfeiçoamento da
documentação do produto, a criação de melhoras ferramentas de treinamento
no FMWLOS. Os avanços possíveis também incluem construção de novas
aplicações de teste com vistas a refinar o processo de certificação e liberação
de novos releases do framework FMWLOS, a extensão de novos grupos de
funcionalidades (criptografia, compactação, GUI), o refinamento das
48
ferramentas para inspeção de código balizada em boas práticas de
programação. E finalizando com o conjunto de iniciativas possíveis para
melhorias futuras da solução, a sofisticação das ferramentas (wizards)
geradoras de modelos de aplicação com uso do framework FMWLOS por via da
inclusão de extensões visando minimizar progressivamente o código a ser
escrito pelo programador na criação de uma nova aplicação de negócio
específica e completa.
49
6 REFERÊNCIAS
Fontes de artigos e livros consultados acerca de construção de
framework de software e assuntos correlatos:
• FAYAD, Mohamed E. et al. Building Application Frameworks: Object-
Oriented Foundations of Framework Design. New York: John Wiley &
Sons, 1999. p. 1 – 83.
• GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de
software orientado a objetos. Rio de Janeiro: Bookman, 2000. p. 1 – 50.
• PFLEEGER, Shari Lawrence Engenharia de Software: Teoria e Prática.
São Paulo: Prentice Hall, 2003. Cap. 6, p. 100 – 130.
• LOUDON, Kyle Dominando Algoritmos com C. Rio de Janeiro: Ciência
Moderna. 2000. p. 1 – 100.
• LIPPMAN, Stanley B. Inside The C++ Object Model. New York: Addison
Wesley, 1996. p. 1 – 75.
• AMBLER, Scott W. The Object Primer: Application Developer’s Guide to
Object Orientation. Second Edition. New York: Cambridge University
Press, 2001. p. 1 – 220.
• BUSCHMANN, Frank et al. Pattern-Oriented Software Architecture: A
System of Patterns. New York: John Wiley & Sons, 1996. p. 383 – 411.
• JOHNSON, Ralph E. Frameworks = (Components + Patterns).
Communications of the ACM, v. 40, n. 10, Oct. 1997. Disponível em:
http://www.idi.ntnu.no/grupper/su/courses/dif8901/papers2003/P-r22-
johnson97.pdf. Acesso em: 21 abr. 2006.
• LUCENA, Carlos J.P.; MARKIEWICZ, Marcus E. Object Oriented
Framework Development. Communications of the ACM, Apr. 2001.
Disponível em: http://www.acm.org/crossroads/xrds7-4/frameworks.html.
Acesso em: 21 abr. 2006.
50
7 ANEXOS
7.1 Glossário de OO
A tabela 2 abaixo descreve conceitos básicos acerca do paradigma de
desenvolvimento de software orientado a objetos, incluindo também termos
correlatos à tecnologia de framework de software, coletados nas referências
consultadas:
TERMO CONCEITO
OO Um acrônimo que é usado intercalável para referir-se a
dois termos: orientado a objetos e orientação a objetos.
Orientação a
Objetos
Um paradigma de software baseado no conceito que
software deve ser construído a partir de objetos que
exibem estado (dado) e comportamento (processo).
Objeto
Uma pessoa, lugar, coisa, concerto, evento, tela ou
relatório que é relevante para um sistema de software.
Objetos conhecem coisas (isto é, eles têm dados) e
realizam coisas (isto é, eles têm funcionalidades).
Classe Um modelo a partir do qual objetos são criados
(instanciados). Uma classe representa uma coleção de
objetos similares.
Responsabilidade
Uma obrigação que uma classe deve cumprir, tal como o
conhecimento de alguma coisa ou a realização de
alguma coisa.
Atributo
Alguma coisa que uma classe ou objeto conhece. Um
atributo é basicamente uma peça única de dado ou
informação.
Método
Alguma coisa que uma classe ou objeto faz. Um método
é similar a uma função ou procedimento em
programação estruturada e é frequentemente referido
51
como operação ou função membro de uma classe.
Atributo Estático
Um atributo cujo valor é aplicável para todas as
instâncias de uma classe. Cada instância de uma classe
compartilha o valor único de um atributo estático.
Método Estático
Um método que opera ao nível da classe,
potencialmente sobre todas as instâncias daquela
classe.
Assinatura
Uma combinação do nome, nomes de parâmetros (em
ordem) e tipo do valor de retorno (se houver) de um
método.
Mensagem
Um pedido de um objeto, o transmissor, a outro, o alvo.
Mensagens são implementadas como uma invocação de
métodos sobre o objeto alvo. Uma mensagem é um
pedido por informação ou para realização de uma ação.
Classe Abstrata Uma classe que não tem objetos instanciados a partir
dela.
Classe Concreta Uma classe que tem objetos instanciados a partir dela.
Superclasse Se uma classe B herda da classe A então dizemos que
A é uma superclasse de B.
Subclasse Se uma classe B herda da classe A então dizemos que
B é uma subclasse de A.
Construtor Um método, tipicamente estático, cujo propósito é
instanciar ou opcionalmente inicializar um objeto.
Destrutor Um método cujo propósito é remover um objeto
completamente da memória.
Polimorfismo
Objetos diferentes podem responder a mesma
mensagem de diferentes maneiras, habilitando objetos
interagirem com um outro objeto sem conhecimento de
52
seu tipo exato.
Herança
A representação de um relacionamento entre duas
classes do tipo “é um”, “é como” ou “é tipo de”. Herança
promove reuso habilitando um subclasse beneficiar-se
automaticamente de comportamento completo que ela
herda de sua superclasse(s).
Associação
Representa os relacionamentos entre objetos os quais
são importantes, pois auxiliam na identificação de como
objetos interagem entre si.
Agregação A representação de associações tipo “é parte de”.
Composição
Uma forma forte de agregação na qual o “todo” é
completamente responsável pelas suas partes e cada
objeto “parte” está somente associado com um objeto
“todo”.
Abstração A característica essencial de um item, tal como uma
classe ou uma operação.
Encapsulamento O agrupamento de conceitos relacionados dentro de
algum item, tal como uma classe ou um componente.
Coesão O grau de conexão dentro de uma unidade encapsulada
(tal como uma classe ou um componente).
Acoplamento O grau de dependência entre dois itens. Em geral, o
melhor é reduzir o acoplamento sempre que possível.
Ocultação da
Informação A restrição de acesso externo para atributos.
Interface
A definição de uma coleção de um ou mais assinaturas
de operações, e opcionalmente definições de atributo,
que compreende um conjunto coesivo de
comportamentos.
53
Componente
Uma unidade coesa de funcionalidade que pode ser
independentemente desenvolvida, disponibilizada e
combinada com outros componentes para construir uma
unidade mais ampla.
Transição
A progressão de um estado para outro. Uma transição é
ativada por um evento (que pode ser interno ou externo
ao objeto).
Wrapper
Uma coleção de uma ou mais classes que encapsula
acesso à tecnologia não OO para torná-la
aparentemente como se fosse OO.
Reuso
É o processo de incorporar em um novo produto de
software artefatos tais como código, especificações de
requisitos, padrões de projeto, planos de teste ou
qualquer outro artefato gerado em desenvolvimentos de
soluções anteriores.
Paradigma Uma estratégia geral ou ponto de vista para fazer as
coisas.
Padrão de Projeto Um padrão que descreve uma solução para um
problema de projeto de software comum.
Padrão de Análise Um padrão que descreve uma solução para um
problema de modelagem de negócio comum.
Arquitetura de
Software
O conjunto de decisões significantes acerca da
organização de um sistema de software, a seleção de
elementos estruturais do sistema e suas interfaces. A
definição do comportamento, estrutura, associações e
interações para estes elementos.
Análise de Domínio
Atividade que objetiva a descrição do domínio que está
para ser coberto por um framework. Para capturar os
requisitos e identificação de conceitos, o desenvolvedor
54
pode recorrer às aplicações desenvolvidas previamente
no domínio, aos especialistas do domínio e aos padrões
existentes para o domínio. O resultado desta atividade é
um modelo de análise do domínio, contendo os
requisitos do domínio, os conceitos do domínio e
relações entre estes conceitos.
Framework de
Software
Um conjunto reutilizável de blocos de construção de
software pré-fabricado que programadores podem usar,
estender ou customizar para geração de uma família de
aplicações similares dentro de um domínio de problema
particular.
Hot Spot
Representam aquelas partes do framework de software
onde adaptações para funcionalidade específica devem
ser feitas visando originar um sistema de software
individual.
Frozen Spot
Representam as partes imutáveis ou que não podem ser
alteradas facilmente em um framework de software.
Estas partes de imutabilidade constituem o núcleo de um
framework. São peças de código já implementado dentro
do framework que podem chamar um ou mais hot spots
fornecidos pelo programador. O núcleo será parte
constante e sempre presente em cada instância do
framework (aplicação).
Callback
Uma abordagem onde um objeto indica que ele quer ser
notificado por uma mensagem uma vez seu pedido
tenha o processamento finalizado. Com efeito, o objeto
quer ser “called back”.
Tabela 2: Conceitos de Orientação a Objetos e Framework de Software
