Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Monografia eng soft1_halan

1,400 views

Published on

Software Engineering

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Monografia eng soft1_halan

  1. 1. HALAN RIDOLPHI ALVES Fundamentos De Framework de Software CT/POLI 2006MBA - Engenharia de Software MonografiaPós-Graduação Lato-Sensu ENGSOFT1
  2. 2. iFundamentos de Framework de Software: Estudo de Caso do Uso doParadigma 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
  3. 3. ii Alves, Halan Ridolphi. Fundamentos de Framework de Software: Estudo de Caso do Uso do Paradigma deOrientação a Objetos na Construção de Aplicações de Software / Halan Ridolphi Alves. – Riode Janeiro, 2006. xi, 54 f.: il. Monografia (Pós-Graduação em Engenharia de Software) – Universidade Federal do Riode 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.
  4. 4. iii AGRADECIMENTOS Ressaltamos nossos sinceros agradecimentos à equipe de professoresdo curso de pós-graduação em Engenharia de Software ministrado pela EscolaPolitécnica da UFRJ. Nestes quase dois anos de parceria e convivênciaobservamos que a troca de informações e experiências com a equipe deprofessores da POLI, pôde proporcionar-nos muito maior sensatez, acurácia,percepção, destreza e habilidades profissionais. Agradecemos a todos quecooperaram e interagiram conosco durante este período possibilitando nossoaperfeiçoamento profissional e pessoal. Ademais, acreditamos que tambémtenhamos transmitido alguma boa mensagem a cada um dos professoresdurante esta nossa convivência. Expressamos também nossa gratidão aopessoal da secretaria do curso, o qual sempre nos atendeu com consideração,profissionalismo e solidariedade. Portanto, desde já, temos somente boaslembranças deste período de cooperação, estudo e intercâmbio deconhecimentos.
  5. 5. iv RESUMOALVES, Halan Ridolphi. Fundamentos de Framework de Software: estudo decaso do uso do paradigma de orientação a objetos na construção de aplicaçõesde 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, apresentarfundamentos da construção um framework de software, relatando problemas esoluções explorados no projeto. Um framework de software pode ser definidocomo uma infra-estrutura de software composta de um conjunto deprocedimentos e funções encapsulados sob forma de classes de objetos,objetivando o desenvolvimento de aplicação com base em reuso e o paradigmade orientação a objetos, na visão de Fayad (1999). O trabalho apresenta avisão do autor em seu papel de engenheiro de software, focando os aspectosde projeto (arquitetura, classes de objetos, padrões) e de implementação deestruturas de dados e algoritmos (atributos e métodos de classes) naconstrução do framework de software. Demonstra-se através de exemploscomo a reutilização dessa infra-estrutura de software acelera odesenvolvimento de aplicações corporativas baseadas em software visando àautomação de processos de negócios.
  6. 6. v LISTA DE SIGLASCT - Centro de TecnologiaPOLI - Escola PolitécnicaUFRJ - Universidade Federal do Rio de JaneiroHSBC - HSBC BankURL - Uniform Resource LocatorHTTP - Hiper Text Transfer ProtocolOO - Orientação a ObjetosPOO - Programação Orientada a ObjetosESOO - Engenharia de Software Orientada a ObjetosDBC - Desenvolvimento Baseado em ComponentesCASE - Computer-Aided Software EngineeringAPI - Application Programming InterfaceSOA - Service-Oriented ArchitectureMVC - Model-View-ControllerINI - initialization file or INI fileIPC - Inter-Process CommunicationXML - Extensible Markup LanguageUML - Unified Modeling LanguageRPC - Remote Procedure CallACE - Adaptive Communication EnvironmentMFC - Microsoft Foundation ClassesDCOM - Distributed Component Object Model.NET - Microsoft .NET FrameworkJava RMI - Java Remote Method InvocationCORBA - Common Object Request Broker ArchitectureJ2EE - Java 2 Platform, Enterprise EditionVCL - Visual Component LibraryCLX - Component Library for Cross PlatformET++ - Editor Toolkit, an OO application framework in C++JUnit - Java Unit testing frameworkFMWLOS - Framework de software Losango
  7. 7. vi SUMÁRIO1 INTRODUÇÃO ........................................................................................ 1 1.1 Escopo ............................................................................................. 1 1.2 Notação Sintática ............................................................................. 22 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 ............................................................................ 173 METODOLOGIA.................................................................................... 20 3.1 Premissas....................................................................................... 20 3.2 Ferramentas ................................................................................... 21 3.3 Base Técnica.................................................................................. 22 3.4 Processos....................................................................................... 244 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 ........................... 425 CONCLUSÕES ..................................................................................... 466 REFERÊNCIAS ..................................................................................... 497 ANEXOS................................................................................................ 50 7.1 Glossário de OO............................................................................. 50
  8. 8. 11 INTRODUÇÃO1.1 Escopo Este trabalho focaliza um projeto de software prático real, maisnotadamente, apresenta fundamentos da construção de um framework desoftware, relatando problemas e soluções explorados em seu projeto técnico. A necessidade de uma solução baseada em framework de softwareoriginou-se do desafio de fornecer a infra-estrutura que possibilitasse odesenvolvimento rápido de aplicações corporativas baseadas em software, noambiente de tecnologia da informação da financeira Losango pertencente aogrupo HSBC. Esta infra-estrutura de software foi nomeada pela sigla FMWLOS.Em suma, o FMWLOS seria utilizado como plataforma de desenvolvimento porvários fornecedores de soluções baseadas de software do HSBC/Losango parao desenvolvimento de aplicações cujos propósitos incluem processamentobatch, daemons e serviços hospedados em sistemas Unix e Windows, visandoà automação de processos de negócios relacionados à avaliação de propostasde créditos ao consumidor. O estudo objetiva apresentar a visão do autor em sua atuaçãoprofissional como engenheiro de software integrante de equipe de fornecedoresdo HSBC/Losango, focando os aspectos básicos de projeto (arquitetura,modelo de classes, padrões, componentes) e de implementação de estruturasde dados e algoritmos (atributos e métodos de classes), visando à construçãode uma solução de framework de software. As classes de objetos que compõem a organização estrutural, osalgoritmos e estruturas de dados que orientam o modelo dinâmico foramprojetados e codificados com vistas a prover as funcionalidades desejadas noframework 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
  9. 9. 2utilizado como fonte de informação neste estudo e as restrições de escopodeste 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 decodificação adota conceitos de C++. A tabela abaixo apresenta um comparativoentre os métodos de construção e destruição de objetos em código C++ versuscódigo equivalente utilizando no framework FMWLOS.Elementos de Sintaxe em C++ Sintaxe em FMWLOSLinguagemClasseEm FMWLOS CLASS_TYPE (THttpException);utilizam-se as class CHttpExceptionmacros : public CException CLASS (THttpException) {CLASS_TYPE, EXTENDS (TException) …CLASS e { }; …EXTENDS para a };definição declasses.Construtores eDestrutores void f()Em FMWLOS, void f() { { Tx* pX;utilizam-se os X *pX = new X[5];métodos de delete [] pX; pX = TX_CreateInstance();alocação dinâmica } …CreateInstance e TX_ReleaseInstance (pX);ReleaseInstance. } void f() void f()Alocação na Stack { {Em FMWLOS CX X; Tx* pX;utilizam-se os …
  10. 10. 3métodos return; pX = TX_CreateLocal(); } …CreateLocal e TX_ReleaseLocal (pX);ReleaseLocal. Não }se devem utilizarestes métodosdentro de um loop,a menos que aschamadas estejamem uma funçãointerna a este loop.Tabela 1: Sintaxe de Elementos de Linguagem
  11. 11. 42 REVISÃO DE LITERATURA2.1 Definições Frequentemente nos referimos aos termos biblioteca de classes OO,frameworks, padrões e componentes. Estes termos referem-se às ferramentasque são usadas para construir sistemas de software reusáveis. Uma bibliotecade classe OO é uma coleção de implementações de objetos de software queprovêem funcionalidade reutilizável através de chamadas do programador aosmétodos de objetos. Bibliotecas de classes OO provêem os insumosnecessários para construir aplicações de software, porém, não provêm asdiretrizes de como juntar as peças de software para gerar uma aplicaçãoconcreta e amplamente funcional, conforme relata Pfleeger (2003). Portanto,cabe ao desenvolvedor de software tomar as decisões necessárias para coletare acoplar componentes disponíveis em um repositório de software reutilizávelvisando montar um sistema de software específico. Abaixo, a figura 1 ilustra anatureza passiva desta solução de desenvolvimento, representando comopadrões de projeto podem direcionar o projeto e a implementação da aplicaçãoe, o uso de componentes das bibliotecas de classes.Figura 1: Desenvolvimento de Aplicação com Bibliotecas de Classes.
  12. 12. 5 Framework de software é uma tecnologia muito importante para indústriade software, bem como para academia, ao considerarmos que demandasatuais por soluções de software estão requerendo, cada vez mais, sistemas desoftware com crescente complexidade, tamanho e funcionalidade. O advento doparadigma OO, incluindo tanto técnicas para programação e engenharia desoftware orientada a objetos, e a definição de frameworks possibilitaramreutilização de componentes de software em larga amplitude, inclusivepossibilitando a construção de geradores de modelos de aplicação em váriosdomínios de negócio. Dentre as vantagens da adoção da tecnologia deframeworks de software destacam-se o incremento da reutilização, comconseqüente ganho de produtividade pelos programadores, e a redução dotempo de lançamento ao mercado para aplicações de software. Quandoutilizados em conjunção com padrões, componentes e bibliotecas de classes,os frameworks podem significativamente incrementar a qualidade de software ereduzir esforço de desenvolvimento. Um padrão representa uma solução recorrente para um problema dedesenvolvimento de software dentro de um contexto particular. Padrões deprojeto são abstrações de alto nível que refletem a experiência de profissionaishábeis e descrevem, de acordo com formato definido, o contexto, problemas,soluções e conseqüências de compor decisões de projeto específicas, segundodescreve Erich Gamma (1995). Padrões são menos especializados queframeworks. Frameworks são úteis em um domínio de aplicação particular,enquanto que padrões são aplicáveis mais genericamente. Um frameworktipicamente contém vários padrões, entretanto, padrões não contêmframeworks, conforme relata Johnson (1997). Frameworks são construídos detal modo que aplicações similares geradas, dentro do mesmo domínio denegócio, se beneficiem das potencialidades providas por mesmas estruturas,padrões, algoritmos e demais abstrações de software embutidas em umframework. Framework de software são, portanto, como geradores deaplicação. Um componente refere-se a um objeto concreto que dispõe de umainterface de serviços bem definida e deve ser auto-contido em termos das
  13. 13. 6funcionalidades que provê. Tanto bibliotecas de classes OO e frameworks sãocoleções de componentes que transformam projeto abstrato em produtoconcreto por via da instanciação e especialização, conforme relatado porDouglas Schmidt (1994). Na visão de Mohamed E. Fayad (1999), um framework de software podeser definido como uma estrutura de software composta de um conjunto deprocedimentos e funções encapsulados sob forma de classes de objetos,objetivando o desenvolvimento de aplicação com base em reuso e o paradigmade orientação a objetos. De acordo com Ralph E. Johnson (1997) entende-sepor framework como sendo um conjunto de componentes de software queformam uma aplicação semi-completa e reutilizável em um domínio de negócioespecífico, que pode ser especializada e fornece a infra-estrutura necessária esuficiente para desenvolvimento de novas aplicações de software. Frameworkde software é uma tecnologia promissora na transformação de soluçõesabstratas expressas em projetos de software em implementações de produtostangíveis e funcionais, possibilitando tal transformação com redução de custose melhoria da qualidade do produto de software. Um framework existe para serreutilizado e agilizar o desenvolvimento de software.2.2 Características Um framework de software descreve a arquitetura de um softwareorientado a objetos incluindo os tipos de objetos e como eles colaboraram nofornecimento de serviços entre si, conforme visão de Bushmann (1996).Frameworks utilizam intensamente as características que distinguem aslinguagens 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çospela quais as implementações (especializações) podem se orientar visando àconcretização das funcionalidades. Polimorfismo é a habilidade para umavariável ou parâmetro de um procedimento assumir valores de vários tipos(Pfleeger, 2003).
  14. 14. 7 Polimorfismo possibilita aos objetos mudarem seus mecanismos decolaboração com demais objetos em tempo de execução e, portanto, viabilizaampla versatilidade no comportamento da aplicação de software. Herança viabiliza a geração de novas linhagens de objetos a partir deobjetos preexistentes, por via da inclusão de novas responsabilidades oumesmo 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 algumainformação (atributo), na visão de Ambler (2001). Um framework é um projeto reutilizável de um software que descreve suadecomposição em grupos de objetos de interação, conforme mencionado porFayad (1999). O framework descreve objetos componentes e como estesobjetos interagem entre si. Descreve a interface de serviços de cada objeto e ofluxo de controle entre os mesmos. Comumente, um framework é codificadocom emprego de uma linguagem de programação orientada a objetos, ondealguns dos objetos constituintes do núcleo do framework são especificados porclasses abstratas. Uma classe abstrata é uma classe sem instâncias, temcaráter de compor superclasses de alta ordem numa hierarquia de classes deobjetos e, são empregadas como modelos para formação de novas subclasses(Pfleeger, 2003). Frameworks utilizam classes abstratas no projeto de seusobjetos componentes, pois elas especificam a interface de serviços dosmesmos e provêem um esqueleto que pode ser especializado para implementaros componentes funcionais das aplicações finais geradas (Fayad, 1999). Frequentemente, um framework se utiliza de biblioteca de classes quecontém subclasses concretas derivadas de classes que compõem o núcleo doframework. Estes conjuntos de subclasses adicionais agregam aimplementação de serviços especializados identificados e necessários nodomínio de negócio no qual estão inseridas as aplicações a serem geradas viaframework. Alguns destes serviços englobam funções para gerenciamento dememória, gerenciamento de arquivos, tratamento de exceções, controle deacesso 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
  15. 15. 8seja um recurso crucial para apoiar um framework de software em sua missãogeradora de novas aplicações de software, a essência de um framework nãoestá na biblioteca de classes em si, mas sim, no modelo de colaboração e fluxode 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 programaprincipal é reutilizado pelo programador que decide o que é anexado aomesmo. Também, conforme necessidades da lógica de aplicação a serimplementada, o programador pode inclusive criar novos componentes desoftware a serem anexados e invocados pela estrutura padrão de programa.Neste caso, o código gerado pelo programador é chamado pelo código donúcleo ou máquina do framework. Portanto, o framework determina a estruturageral e fluxo de controle do programa principal a ser executado pela aplicação. O desenvolvimento de frameworks de software eficientes, reutilizáveis erobustos requer equipes de profissionais com ampla capacitação emtecnologias de engenharia de software. Para concretizar tal produto de softwarenecessita-se de projetistas, analistas, testadores e programadores com domíniode padrões, arquiteturas de software, protocolos, idiomas de programação, OO,DBC, algoritmos e estruturas de dados, linguagens de especificação demodelos de software (UML), ferramentas de teste automatizado (JUnit),linguagens de programação (C++, Java), ambientes de desenvolvimento desoftware (C++ Builder, Delphi, Eclipse, MS Visual Studio), ferramentas CASE(IBM Rational Rose, System Architect, ERWIN, Enterprise Architect) e dentreoutras 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 deobjetos abstratas e concretas referentes ao domínio de negócio para o contextode aplicação desta tecnologia, conforme comentado por Fayad (1999). Oprojeto do núcleo do framework especifica a arquitetura de software típica paraaplicação de software a ser gerada no domínio de negócio particular. Também
  16. 16. 9associado à construção deste tipo de produto de software ressaltamosnecessidade do projeto dos incrementos internos do framework, o qual consistena especificação de classes adicionais que capturam implementações comunse especializadas do núcleo do framework e contribuem para agregar maisutilidade, funcionalidade e aplicabilidade ao conjunto do framework (núcleo,incrementos internos). Tais incrementos internos formam um grupo debibliotecas de classes que oferecem distintos serviços especializados e desuporte ao framework, na visão de Fayad (1999). Frameworks compreendem um tipo de software complexo, pois contémprojetos abstratos, são aplicáveis genericamente e, detêm característicaspeculiares em dois níveis: domínio de negócio e estruturais. As característicasrelevantes do domínio são úteis em aplicações de negócio. Já ascaracterí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 aimplementação do framework compreendem a interface corrente utilizada pelosusuários do framework (desenvolvedores de aplicação, programadores),conforme esclarece Johnson (1997). Framework não deve ser interpretado com sendo uma aplicação, poisnecessariamente 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çõesparciais, pois não descrevem todos os aspectos funcionais de uma aplicação.Uma framework não é uma biblioteca de classes. Aplicações de software queutilizam classes de uma biblioteca invocam métodos predefinidos, enquantoframeworks contêm componentes que invocam métodos fornecidos pelousuário. Esta inversão de controle é característica peculiar. Frameworks sãoconjuntos interconectados e complexos, enquanto que bibliotecas consistem depeças compatíveis, na visão de Fayad (1999). Frameworks devem gerar famílias de aplicações para o domínio denegócio no qual se insere. Para tal, devem existir em sua estrutura pontos deflexibilidade que possam ser customizados de modo a adaptá-lo a aplicação
  17. 17. 10que se deseja construir. Os pontos de flexibilidade de um framework sãochamados de hot spots. Hot spots são classes abstratas ou métodos virtuaisque devem ser implementados pela aplicação alvo. A geração de um programaexecutável inclui sua instanciação via framework com a implementação decódigo específico da aplicação preenchendo cada hot spot. Uma vez os hotspots são instanciados, o framework utilizará estas classes por via de ummecanismo específico como o callback. Pelo callback, o código do usuário doserviço declara que ele quer ser chamado quando da ocorrência dedeterminado evento. Então, o código do provedor do serviço realiza o callbackno código do usuário do serviço quando o evento ocorre, conforme relataLucena (2001). Algumas estruturas do framework não são mutáveis e não pode serfacilmente alteradas. Estes pontos de imutabilidade constituem o núcleo de umframework, também chamados de frozen spots. Os frozen spots,diferentemente dos hot spots, são peças de código já implementadas dentro doframework que pode chamar um ou mais hot spots fornecidos pelo usuário doframework. 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 motorrequer energia. Diferente de um motor tradicional, um motor de framework temmuitas tomadas de energia. Cada tomada de energia é um hot spot doframework. Cada hot spot deve ser energizado (implementado) para o motor(framework) trabalhar. Os geradores de energia são os códigos específicos daaplicação que deve ser plugados nos hot spots. O código de aplicaçãoadicionado será usado pelo código do núcleo do framework. O motor nãofuncionará enquanto todas as tomadas estiverem desconectadas. Estacomparação é ilustrada pela figura 2, extraída de Lucena (2001).
  18. 18. 11Figura 2: Framework versus Aplicação.2.4 Problemas Comuns Frameworks de software são referenciados como a pedra fundamentalda engenharia de software contemporânea. Frameworks são geradores deaplicação que estão diretamente relacionados a um domínio de negócioespecífico, ou seja, uma família de problemas relacionados. A despeito de suaspotencialidades, a prática tem revelado alguns problemas e desafios a superarassociados ao emprego da tecnologia de frameworks de software. Frameworks são considerados ferramentas grandes, poderosas ecomplexas e, portanto, difíceis de entender. Isto implica que é necessáriadocumentação mais apurada, precisa e completa que outros produtos desoftware e, além disso, requer longo treinamento. Um framework deveria serfornecido com diferentes aplicações protótipos que reutilizassem os várioscomponentes do framework em distintos modos de montagem dessasaplicações. Este recurso acompanhado ao framework apoiara sobremaneirausuários do framework na compreensão dos mecanismos de programação ecomo a solução do framework em si pode ser usada. Em resumo, adocumentação de framework deve focar no uso de exemplos de modo a tornaro projeto abstrato das estruturas internas do framework mais concreto,
  19. 19. 12palpável, manejável e compreensível para seus usuários finais, de acordo comvisão de Fayad (1999). Ademais, frameworks são difíceis de construir por conta de seussofisticados algoritmos de controle de fluxo de execução, mecanismos paraviabilizar flexibilidade, reutilização, extensibilidade e modularidade, incidindo emcustos maiores de aquisição e requerem equipes de desenvolvedoresexperientes e com elevada capacitação técnica. Como frameworks são descritos em termos de linguagens deprogramação, ou seja, é software implementado, torna-se difícil paradesenvolvedores compreender seus padrões comportamentais apenas por viada leitura do código fonte, o qual se configura em tarefa muito pouco viável, porconta das centenas de milhares de linhas de instrução que compõe seumaterial constituinte. Portanto, programadores dependem de boadocumentação, incluindo exemplos de programação de aplicações com uso doframework, ou obter suporte de especialistas na solução, conforme relatado emestudos por Fayad (1999). Decidir quando lançar um framework para viabilizar desenvolvimento deaplicação não é tarefa fácil, pois o problema é definir e assegurar algum critériode lançamento. O framework dever ser reutilizável, razoavelmente estáveldentro do domínio de negócio e bem documentado. Pesquisas recentes acercade abordagens para reuso indicam que ainda não existem métricas gerais paramensurar este processo da engenharia de software. Quanto à estabilidade, odomínio de negócio onde framework está inserido não é estável por si só, masevolui constantemente. Decidir se o framework está suficientemente bemdocumentado é complicado, pois não existe método de documentaçãogenericamente aceito que cobre todos os aspectos do framework, mas tambémporque é difícil determinar se a documentação está compreensível para osusuários do framework (desenvolvedores de aplicação, programadores). Olançamento de um framework imaturo pode ter severas conseqüências namanutenção e utilização do framework e para aplicações instanciadas emprodução, conforme aponta Johnson (1997).
  20. 20. 132.5 Adoção A adoção da tecnologia de frameworks pode ser motivada por váriosfatores. Dentre eles, a necessidade de economizar tempo e dinheiro durante odesenvolvimento de aplicações de software. A redução do tempo delançamento ao mercado de determinado produto de software configura-se emfator primordial em muitas empresas, sob pena de não se viabilizarem asmudanças no ambiente de negócios ou mesmo perda de clientela para aconcorrê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çõesde 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 podemover-se do desenvolvimento de uma aplicação para próxima sem ter quecompreender novos padrões de projeto, conforme defende Fayad (1999). Outra motivação para uso de frameworks é possibilitar aosdesenvolvedores a construção de sistemas de software pela combinação decomponentes de distintos fornecedores. Ademais, frameworks permitemdoutrinar e melhorar as habilidades dos programadores no sentido deconduzirem à construção de um produto de software balizado pelos melhorespreceitos 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 dedesenvolvimento orientada ao reuso de soluções de software, objetivandoganhos de produtividade, redução do tempo de criação de novos produtos,maior lançamento de novidades ao mercado consumidor em curtos períodos detempo, melhoria da qualidade de software, minimização de esforço e custos dedesenvolvimento.
  21. 21. 142.6 Avaliação Não é fácil dizer o quão confiável um framework é, se o fornecedoroferecerá bom suporte ao produto e, se a aplicação final construída com baseno framework é suficientemente eficiente, conforme apregoa Fayad (1999). As questões difíceis são se um framework é adequado para o domínio doproblema e se contempla o correto balanceamento entre poder e simplicidade.Nenhum framework é bom para qualquer tipo de aplicação, e pode ser difícildizer se uma solução particular é bem adaptada para um domínio de problemaespecífico. A abordagem padrão para avaliação de framework é tomar uma lista deverificaçã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 defuncionalidades desejadas para aplicação final. Neste sentido, é maisimportante que um framework seja fácil de estender do que ter todas asfuncionalidades desejadas para um domínio de problema, conforme Fayad(1999). Entretanto, é mais fácil dizer se um framework provê uma determinadafuncionalidade do que dizer se é extensível. Um especialista na solução deframework pode usualmente dizer o quão complicado é adicionar algumacaracterística faltante, mas é bastante difícil tal diagnóstico por parte de novatosna solução. Portanto, uma alternativa razoável de conduzir a avaliação desoluções é utilizar alguns frameworks, possivelmente em alguns projetos-pilotos, e desenvolver alguma experiência e capacitação com eles antes deescolher uma solução como padrão da empresa. Como frameworks sãograndes e custosos, então também é caro testá-los e, não existe outra escolhaexceto confiar no parecer dos especialistas, defende Fayad (1999). Todo framework tende balancear simplicidade com poder. Simplicidadetorna o framework mais fácil de compreender, portanto um framework simples émelhor para desenvolvedores novatos. Especialistas apreciam poder eflexibilidade. Se a pretensão de usar framework é por somente uma vez, entãoo tempo consumido para entendê-lo provavelmente excederá o tempo gastopara usá-lo, assim simplicidade deve ser mais importante que poder. Se o
  22. 22. 15objetivo é utilizar framework muitas vezes então poder e flexibilidade sãoprovavelmente mais importantes para balizar o investimento na tecnologia, deacordo com visão de Fayad (1999). O valor primordial de uma solução de framework é se ela melhora omodo de desenvolver software e, como também, o produto de software em si.Muitos fatores influem neste sentido: a qualidade do framework, ferramentas desuporte ao framework, a qualidade da documentação e comunidade deespecialistas que prove treinamento e consultoria na aplicação da tecnologia.Um framework deve preencher a cultura da empresa. Se a empresa tem altarotatividade de pessoal e pequeno orçamento para treinamento então oframework deve ser simples e fácil de usar. O valor de um framework dependemuito 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êscomponentes de software: o framework, as subclasses concretas derivadas declasses do núcleo do framework (reutilizadas das bibliotecas de classes) equalquer outro componente de implementação (lógica especializada denegócio). Este última parte, também referenciada por incremento específico daaplicação, especifica quais as demais classes concretas serão usadas e comoelas serão interconectadas para compor o código referente à lógica específicada aplicação. Este incremento específico pode também incluir objetos que nãotem relacionamento direto com framework ou utilizar objetos da biblioteca declasses que acompanha o framework, mas que não são invocados viamecanismo de inversão de controle e, portanto, não são participantes domodelo 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 oucustomizações no framework ou criação de qualquer nova subclasse deobjetos. Outro modelo de uso do framework define novas subclasses concretasderivadas ou não de classes internas do framework e usa-las para implementarlógica de aplicação. Neste caso, as subclasses derivadas do framework devem
  23. 23. 16reunir a especificação estabelecida pelas superclasses, assim sendo, oprogramador deve compreender em detalhes as interfaces de serviços providaspelo framework. O desenvolvimento de frameworks está rapidamente ganhandoaceitação na comunidade de software devido a sua habilidade de promoverreuso de código fonte e projeto. A figura 3 abaixo ilustra a natureza ativa destasolução de desenvolvimento, representando como padrões, componentes ebibliotecas de classes do framework podem guiar a construção de umaaplicaçã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 eproporcionar benefícios primários para construção de produtos de software, taiscomo modularidade, reutilização, extensibilidade e inversão de controle, comimpactos diretos no exercício profissional de desenvolvedores de aplicação,conforme defende Fayad (1999). Frameworks melhoram a modularidade encapsulando detalhes deimplementação volátil através de interfaces de serviços estáveis. Modularidadedo framework ajuda melhorar qualidade do software pela localização do
  24. 24. 17impacto ocasionado por alterações no projeto e implementação. Estalocalização reduz o esforço requerido para compreender e manter o softwareexistente. As interfaces de serviços estáveis providas por frameworks aperfeiçoamo reuso pela definição de componentes genéricos que podem ser reaplicadospara criar novas aplicações. Reutilização de framework otimiza o esforço dedesenvolvedores experientes para evitar recriação e revalidação de soluçõescomuns para recorrentes requisitos de aplicação e desafios de projeto desoftware. O reuso pode melhorar substancialmente a produtividade doprogramador, bem como aperfeiçoar a qualidade, desempenho, confiabilidade einteroperabilidade do software, na visão de Pfleeger (2003). Um framework aperfeiçoa a extensibilidade do software pela provisão demétodos virtuais e níveis de indireção (dynamic binding) que permitem aosdesenvolvedores de aplicações estenderem as interfaces de serviços estáveis.Métodos virtuais desacoplam as interfaces estáveis e as variantescomportamentais requeridos no domínio de aplicação. Extensibilidade éfundamental para assegurar customização rápida de novos serviços ehabilidades para aplicações geradas. A arquitetura de tempo de execução de um framework é caracterizadapelo mecanismo de inversão de controle. Esta arquitetura possibilita quepassos do processamento da aplicação canônica serem customizados porobjetos manipuladores de eventos que são invocados pelo mecanismo dedespachamento reativo do framework, conforme explica Fayad (1999). Inversãode controle permite ao framework determinar qual conjunto de métodosespecí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, BorlandCLX e implementações de CORBA demonstram importante avanço esofisticação da indústria de software no sentido de estabelecer e disponibilizarpadrões, ferramentas e técnicas de construção do software contemporâneo. A
  25. 25. 18seguir, mencionamos algumas aplicações reais construídas por via da utilizaçãode 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;
  26. 26. 19• Sistemas de imagem médica na Kodak;• Sistema de bordo para gerenciamento de combate na Marinha Turca.
  27. 27. 203 METODOLOGIA3.1 Premissas Por definição da divisão de suporte de software básico doHSBC/Losango o escopo do framework FMWLOS seria principalmente proverrecursos para geração de aplicações de negócio a serem hospedadas emsistema operacional HP-UX 11. Além disso, o desempenho das aplicaçõesconsistia em requisito de projeto essencial, tendo em vista o volume depropostas de créditos encaminhadas pelos lojistas em períodos críticos demovimentos de vendas do comércio varejista, notadamente, os feriados paradia das mães e natal. Por conta deste requisito, a linguagem de programaçãopadrão adotada para desenvolvimento seria linguagem C. Para as ferramentasde compilação envolveriam o uso de GNU C Compiler e GNU Makecompatíveis para plataforma HP-UX. A linguagem de programação C++ foi preterida como meio deimplementação das aplicações em relação a linguagem C, por conta da menoreficiência, conseqüente principalmente da característica de ligação dinâmica(binding dynamic), essencial para viabilizar o polimorfismo da OO na linguagemC++. A menor eficiência da linguagem C++, ao nível de implementação, podeser explicada pelo incremento do layout de armazenamento em memória(devido aos ponteiros necessários para tabelas virtuais), degradação dodesempenho de execução (devido ao overhead adicional para invocar métodovirtual dinamicamente) e os níveis de indireção (classes abstratas) utilizadaspara permitir desenvolvedores estender as interfaces de serviços existentes,conforme relata Lippman (1996). Em resumo, a generalidade e flexibilidadeprovidas pela linguagem C++ implicam na contrapartida da redução daeficiência quanto confrontada com a linguagem C. Relativo a vantagens do usoda linguagem C afirma-se que se pode obter melhor eficiência pelo suporte aCDTs (tipos de dados concretos), os quais são freqüentemente requeridos parasoftware de tempo crítico, ou seja, com severos requisitos de desempenho deexecução, conforme estudos de Fayad (1999).
  28. 28. 21 A linguagem C permitia a geração de código objeto nativo paraplataforma HP-UX, sem necessidade de qualquer nível de interpretaçãointermediária para execução das aplicações de negócio, assim, a linguagemJava também não seria boa escolha de implementação. Ademais, portabilidadenão era necessariamente requisito do projeto FMWLOS, visto que a plataformaalvo 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 devida de projeto do FMWLOS, as quais foram organizadas por área de aplicaçãoe 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
  29. 29. 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 eavaliaçã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 queimpedia a utilização de uma linguagem orientada a objetos, tal como C++ ouJava. A despeito disso, a equipe de projetistas do FMWLOS desejava usar oparadigma OO na implementação do FMWLOS. Para tanto, os projetistasbuscaram informações na literatura acerca de como proceder à implementaçãode técnicas da OO presentes na linguagem C++ com uso da linguagem C. Osprojetistas do FMWLOS encontram a descrição de tais técnicas OOamplamente detalhadas em Loudon (2000) e Lippman (1996), os quaissão referências recomendadas acerca de tecnologia OO. Em Loudon (2000)estão disponíveis explanações para todos os algoritmos e estruturas de dadosfundamentais utilizadas na implementação do núcleo e principais bibliotecas de“classes” do framework FMWLOS. Em Lippman (1996) estão concentradas asorientaçõ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 osprojetistas partiram para a organização estrutural do FMWLOS e iniciaram ostrabalhos de codificação de “classes” para o núcleo e os incrementos internospropriamente ditos. Como plataforma alvo de operação das aplicações de negócio seria osistema HP-UX 11i, tal requisito não-funcional do projeto FMWLOS exigiu dosseus projetistas o domínio de bons conhecimentos de teoria de sistemasoperacionais, notadamente, assuntos tais como processos, sistema dearquivos, gerenciamento de memória. Além disso, houve a necessidade deobtenção de conhecimento para recursos de programação de aplicativos dosistema operacional HP-UX, destacando API de 64 bits para manipulação de
  30. 30. 23arquivos com tamanho superior a 2 GBytes, estruturas de makefiles, extensõesda API de sockets do protocolo TCP/IP. O modelo de colaboração de “classes” do FMWLOS demandou dos seusdesenvolvedores a implementação de padrões de projeto tais como MétodoFábrica, Bridge, Singleton, Adapter e, para tal a referência da literatura técnicaconsultada para exemplos de codificação foi Gamma (1995). Por exemplo, afigura 4 abaixo demonstra como a especificação do modelo de classes para APIde Memória Compartilhada do FMWLOS estabelece uma interface de serviçosuniforme, porém culminando em diversas implementações regidas pelo padrãode projeto Bridge Pattern. cd Visão Geral do Pacote (Applib) TSharedMemory TSharedMemoryImp TSVSharedMemory TMMSharedMemory TNilSharedMemoryFigura 4: Exemplo modelo de classes da API Shared Memory de FMWLOS. Para especificação dos modelos de software do FMWLOS seusprojetistas utilizaram a notação da UML com suporte de ferramentas CASE taiscomo Microsoft Modeler e Enterprise Architect. Ainda para representação dosmodelos de software, a notação de grafo de dependência entre “classes”FMWLOS foi utilizada com suporte das ferramentas Graphviz (geração degrafos de “classes”) e Doxygen (documentação de “classes” estilo Javadoc). Alguns conhecimentos específicos da API do sistema operacionalWindows também foram necessários aos projetistas e programadores doFMWLOS com vistas a tornar sua implementação utilizável num contextomultiplataforma (Windows, Unix).
  31. 31. 243.4 Processos O desenvolvimento do framework FMWLOS foi orientado por processositerativos e incrementais. Iterativo devido não ser possível o conhecimentopelos projetistas de todas as nuances, particulares e necessidades do domíniode negócio, num primeiro estágio de criação do produto framework. Outra razãopara abordagem iterativa é que o framework torna explícito partes de seuprojeto abstrato que são passíveis de mudanças, tais como componentes oubibliotecas de classes que são relativamente mais fáceis de alterar ereorganizar. Quanto às interfaces de serviços e algoritmos do kernel são difíceisde mudar e não desejáveis por conta da manutenção de compatibilidade comaplicações existentes no ambiente de produção. Ressalta-se que, a cadaiteração completa de análise e projeto do framework FMWLOS contempla-se aatividade de teste, a qual é realizada usando componentes do próprio FMWLOSpara implementar novos protótipos de aplicações exemplo, utilizadas paraavaliar a usabilidade do framework e decidir se o FMWLOS estásuficientemente confiável e maduro para lançamento em produção. Adocumentação em cada iteração do projeto FMWLOS também ocupaimportante esforço de realização do produto visando descrever como utilizar oFMWLOS, atualizar os manuais de treinamento e, especificar o projeto abstratodo FMWLOS para demonstrar como o framework trabalha. Todo lançamento denova versão do FMWLOS incluía obrigatoriamente a devida atualização epublicação para toda documentação associada ao produto. A abordagem incremental torna-se necessária, pois o framework requerprofundo conhecimento do domínio de aplicação e é difícil construí-lo sob ocontexto de um planejamento de um projeto de mais amplitude, conformeesclarece Fayad (1999). Assim, projeto de framework de software nunca deveestar no caminho crítico de um produto ou serviço mais importante daorganização, ou seja, com impactos diretos no modelo de negócio. Além disso,organizar o desenvolvimento do produto em releases intermediários emcontraposição a um release “big-bang” reduz riscos do projeto pela obtenção defeedback dos desenvolvedores de aplicação logo nos releases iniciais doframework, de acordo com Ambler (2001). A abordagem de desenvolvimento
  32. 32. 25incremental também possibilita o lançamento de aplicações de negócio emambiente de produção montadas com distintas versões do frameworkFMWLOS, cada qual com avanços de funcionalidades diferentes, enquantopossibilita desenvolver o FMWLOS em paralelo com o desenvolvimento devá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ênciasde funcionalidades nos distintos releases do framework FMWLOS. Em resumo,a norma geral para documentar os registros de mudanças no produtoestabelecia que as alterações em artefatos de software (código edocumentação) devem ser registradas em documento específico de Controle deMudanças, o qual deve contemplar descrições detalhadas das mudançasincluídas em novas revisões desses artefatos. As mudanças devem comentar anecessidade, a solução, a questão ou incidente de produção associado que
  33. 33. 26originou 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ãocorrente compilada, o que permite a uma aplicação de negócio em ambiente deprodução saber exatamente com qual versão do FMWLOS foi empregada emsua construção. Essencialmente, quando a aplicação de negócio invoca ocomando de ajuda para se obter informação acerca de sua própria versão,automaticamente, a versão do FMWLOS é apresentada, conformeexemplificado a seguir:/home/halan/desenv/middleware/debug/Consulta_Generica/ > Consulta_Generica -??20050304,200952,Consulta_Generica 1.24 - Feb 11 2005 19:26:3020050304,200952,Framework FMWLOS 1.55 - Dec 6 2004 17:58:54
  34. 34. 274 ESTUDO DE CASO4.1 Breve Histórico No início do ano de 2001, a divisão de suporte de software básico doHSBC/Losango observou que o ambiente de desenvolvimento de aplicações desoftware para suporte ao negócio estava bastante desordenado, nãouniformidade, com crescente incidência de falhas de software na operação comconseqüentes interrupções no fornecimento dos serviços de TI, incidindo emprejuízos ao modelo de negócio. A falta de definição para padrões dedesenvolvimento (frameworks, design patterns, DBC, bibliotecas de códigosreusáveis, APIs), padrões de programação (refactoring, POO) e padrões dearquitetura (SOA, Pipelines, Orientada a Eventos, Cliente-Servidor, Repositório,MVC) tornavam os projetos de soluções baseadas em software muito maisdemorados e consequentemente mais caros. Os requisitos de negócio noâmbito do mercado financeiro quase sempre requerem o desenvolvimentorápido de soluções de automação, pois do contrário, incorrem-se riscos de nãose viabilizar a tempo as demandas do negócio ou mesmo perda de clientelapara concorrência. Também, havia necessidade de evolução para o middleware deaplicativos presente na arquitetura de informação de suporte ao modelo denegócio, no sentido de torná-la facilmente extensível, customizável, maisrobusta, de melhor desempenho e de manutenção operacional simples. Omiddleware essencialmente envolvia a integração dos canais front-end deinterfaces diretas com o usuário (lojistas) com serviços back-end hospedadosem plataformas Unix e MainFrame, responsáveis pela execução de workflowsautomáticos de avaliação e autorização de propostas de crédito, incluindoconsulta a dados disponibilizados por sistemas de informação de parceiroscomo SERASA/SPC/TELECHEQUE. Neste caso, novas demandas dedesenvolvimento conseqüentes de necessidades de expansão do middleware,por conta de mudanças no ambiente de negócio, deveriam ser suportadas porum framework de software capaz de acelerar a construção de novos produtos eserviços e, com maior confiabilidade.
  35. 35. 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 novosprodutos de software, com envolvimento de todas as equipes dedesenvolvedores disponibilizados pelos fornecedores do HSBC/Losango. Osbenefícios tangíveis deste empreendimento consistiam basicamente nosseguintes: • 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 desoftware padrão, documentada e com suporte técnico de especialistas paratreinamento e capacitação de novas equipes de desenvolvedores, a divisão desuporte de software básico do HSBC/Losango decidiu pela contratação deserviços profissionais especializados para construção de solução de frameworkde software sob encomenda. No caso, os serviços prestados por algumfornecedor de software deveriam contemplar suporte técnico a evolução doproduto, incluir o destacamento de equipe de especialistas para o processo dedesenvolvimento (engenheiros, programadores, documentadores) e fornecertodos os artefatos associadas à criação do novo produto (código fonte, planosde teste, projeto técnico, manuais de treinamento, cronogramas).4.2 Descrição do Caso O framework de software neste estudo de caso, vulgo FMWLOS, foidesenvolvido com propósito de possibilitar principalmente a construção deaplicações de software transacionais (webservice) e de processamento dedados em lote (batch) a serem hospedadas em plataforma Unix, notadamente,
  36. 36. 29sistemas HP-UX. Entretanto, não há impedimento técnico para seu uso nodesenvolvimento de aplicações orientadas a plataforma Microsoft Windows,pois as classes de objetos implementadas agregam recursos da API nativa dosistema operacional Windows e, além disso, existem recursos de configuraçãoe compilação condicional no código fonte do framework FMWLOS visandoproporcionar desenvolvimento de aplicações com caráter multi-plataforma. O projeto do framework FMWLOS deveria atender aos requisitos desoftware 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 debibliotecas de classes de objetos categorizadas por grandes grupos defuncionalidades, a saber:
  37. 37. 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.
  38. 38. 31 O framework de software FMWLOS provê um esqueleto arquiteturalcustomizável por herança e instanciação de componentes reutilizáveis visandoà montagem de uma família de aplicações relacionadas. A arquitetura doframework FMWLOS é ilustrada na figura 6 abaixo.Figura 6: Arquitetura de Componentes do Framework FMWLOS.
  39. 39. 324.3 Análise da Situação4.3.1 Modelo de Classes no Núcleo (Kernel) cd Classes Kernel FMWLOS x Aplicação AppLib::TApp + TApp(void) -m_pApp + ~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 AppLib::TMain + PrintOut(char*) : void +Hot Spots execute +Kernel + PrintErr(char*) : void + TMain(void) : void + PrintLog(char*, char*) : void 1..* 1 + ~TMain(void) : void + Print(char*, FILE*, char*, va_list) : void + main(int, char*) : int + 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* generate MyApplication::TMyApp + TMyApp(void) + ~TMyApp(void) + Init(int, char*) : BOOL + Run(void) : void + Exit(void) : void + DisplayHelp(void) : void + DisplayVersion(void) : voidFigura 7: Modelo de Classes Kernel Framework FMWLOS e Aplicação. Resumidamente, no modelo abstrato de classes da figura 7, a classeTApp publica os métodos virtuais TApp_Init, TApp_Run, TApp_ExitTApp_DisplayHelp e TApp_DisplayVersion, que representam os hot spotscustomizáveis do framework FMWLOS, a serem estendidos pela subclasse delógica da aplicação do negócio, no exemplo, classe TMyApp. A classe TApppublica outros métodos públicos de propósito geral para todas aplicações,incluindo serviços para registros das atividades de processamento em log dastrilhas de auditoria e dentre outras utilidades. A classe TMain representa osalgoritmos e estruturas de dados do kernel do FMWLOS, ou seja, os frozen
  40. 40. 33spots imutáveis e presentes em todas as aplicações de negócio construídascom uso do framework. A classe TMain encapsula os detalhes necessáriospara execução da aplicação de negócio do usuário, incluindo tratamento desinais do sistema operacional, manipulação de callbacks e dentre os controlesde fluxo de execução. Observe que este modelo é uma representaçãoilustrativa da implementação em código fonte, pois a construção do FMWLOSutiliza linguagem de programação C para viabilizar seu projeto abstrato por viado paradigma OO.4.3.2 Modelo de Algoritmo do Kernel (Frozen Spots) Descreve estrutura padrão de arquivos de código fonte para algoritmobásico do núcleo do framework FMWLOS. Representa detalhes deimplementação da classe TMain, incluindo os comentários de demonstração decomo frozen spots procedem a invocação do código fonte dos hot spots daaplicaçã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 asaplicaçõ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.
  41. 41. 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 */
  42. 42. 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);
  43. 43. 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)
  44. 44. 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 WIN32static 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 ofmemory block type identifiers. */ nFlags |= _CRTDBG_CHECK_ALWAYS_DF; /* Call _CrtCheckMemory at every allocationand deallocation request. */
  45. 45. 38 nFlags |= _CRTDBG_LEAK_CHECK_DF; /* Perform automatic leak checking atprogram exit via a call to _CrtDumpMemoryLeaksand generate an error report if theapplication failed to free all the memory itallocated. */ nFlags |= _CRTDBG_DELAY_FREE_MEM_DF; /* Keep freed memory blocks in the heap’slinked 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 leakdetection 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);
  46. 46. 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 esqueletode aplicação do tipo processamento em lote e dependências com frameworkFMWLOS. Inclui comentários de orientação acerca de como proceder com acustomização ou preenchimento de código fonte pelo programador sob os hotspots disponibilizados pelo framework FMWLOS. Observe que aplicaçãocanônica foi customizada para invocar a lógica específica de negócioimplementada na aplicação exemplo, demonstrada adiante. Relembrando que,os hot spots representam os pontos de flexibilidade que podem sercustomizados para adaptar o esqueleto provido pelo framework a aplicação denegócio a ser gerada pelo usuário do FMWLOS (programador, desenvolvedorde 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
  47. 47. 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
  48. 48. 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 arqcfgn"); TApp_PrintErr (" arqcfg - Nome do arquivo de configuraçãon"); } else TApp_PrintErr ("%sn", pszMessage);}/*! * Mostra versão da aplicação. */void TApp_DisplayVersion (void){ TApp_PrintErr ("Exemplo 1.00 - %s %sn", __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); }
  49. 49. 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: %sn", 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: %sn", 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 oshot spots na aplicação canônica foram customizados para invocar as rotinasnos módulos da aplicação exemplo, as quais efetivamente respondem pela
  50. 50. 43execução da lógica de negócio implementada pelo usuário do frameworkFMWLOS. • 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"
  51. 51. 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 = %dn", m_nTraceLevel);}
  52. 52. 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 traceTraceFileName = $MSDIR/log/Exemplo.trace # Nome do arquivo de saída de trace
  53. 53. 465 CONCLUSÕES Acreditamos que a abordagem de framework de software deve serconsiderada frente às necessidades de produção de software em larga escala epara o qual os requisitos de negócio se alteram rapidamente. Ademais, atecnologia de frameworks de software provê alto grau de reutilização dasolução, incluindo modelos abstratos de domínio, padrões de projeto eimplementação em código fonte. Portanto, frameworks reduzem o montante decódigo específico da aplicação por conta da fatoração de processamento deinformação específica do domínio em componentes genéricos, disponibilizandoao programador uma aplicação quase completa. Esta abordagem dedesenvolvimento vem alavancar o conhecimento de um desenvolvedor deframework, pois possibilita ao mesmo ter pré-determinado quais bibliotecas ecomponentes utilizar, quais padrões de projeto seguir e como entidadestécnicas da solução devem interagir. Particularmente, participar como integrante ativo da equipe dedesenvolvedores do framework FMWLOS foi uma experiência enriquecedora,pois proporcionou o desafio de buscar, assimilar e colocar em prática umaampla base técnica e ferramental da engenharia de software contemporânea.Contribuir para concepção, elaboração, certificação e realização do produto doprojeto FMWLOS, proporcionou a confrontação com desafios técnicos,pressões de cronograma, liderança e motivação de pessoal, planejamento deprojeto, definição de padrões doutrinadores para várias equipes deprogramadores e reuniões para entendimento de necessidades dos usuários.Todas estas atividades forçaram o exercício da profissional de engenharia desoftware, incluindo uma preocupação constante com a qualidade do produto aser construído, o cumprimento de requisitos do projeto e a superação dasexpectativas dos usuários. Pela nossa percepção prática adquirida no projetodo FMWLOS, o experimento e desafio da construção de uma solução deframework de software realmente proporcionam aos seus criadores umasatisfação plena e compensatória ao ver um produto fornecendo serviços dequalidade em determinado modelo de negócio e, como também, o feedbackpositivo da alta gerência, as críticas e sugestões dos usuários. A experiência

×