Sobre framework
Um framework ou arcabouço é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. Ele visa direcionar o desenvolvedor aos problemas relacionados às regras de negócio do cliente e à apresentação das informações. Um framework reduz o esforço utilizado para resolver detalhes de baixo nível como segurança, acesso a dados, comunicação com outros ambientes, etc.
Em suma, os resultados que pretendemos alcançar com a utilização de um framework são:
- Padronização;
- Redução da curva de aprendizagem;
- Aumento da produtividade;
- Simplificação do processo;
- Reutilização de artefatos;
- Manutenção simplificada.
As premissas de um framework são as de ele deve ser:
- Baseado em interfaces;
- Extensível;
- Fácil de usar;
- Estável;
- Configurável;
- Confiável;
- Ter documentação publicada.
O Framework SERPRO implementa o conceito de framework integrador. Seu objetivo é facilitar a construção de aplicações sem o investimento de tempo em escolha e integração de frameworks especialistas, o que resulta no aumento da produtividade e garante a manutenibilidade dos sistemas.
Histórico ^
Em 2005, a CELEPAR, Companhia de Informática do Paraná, criou a Plataforma de Desenvolvimento Pinhão Paraná. O objetivo era organizar o processo de desenvolvimento de sistemas de informação pela empresa.
Em 2007 teve início uma parceria entre CELEPAR e SERPRO. O objetivo do SERPRO era avaliar o framework Java utilizado pela CELEPAR com foco nas necessidades internas da empresa. Em outubro do mesmo ano o SERPRO deu início à evolução desse framework.
Essa evolução se fez necessária diante do alto volume de demandas e atividades intrínsecas ao SERPRO. Também foi iniciado um projeto piloto com o framework no SIEF, Sistema Integrado de Informações Econômico-Fiscais , que integra diversos outros sistemas da Secretaria da Receita Federal.
A ordem de grandeza das necessidades do SERPRO terminou por produzir um novo framework, mais alinhado e mais adequado ao escopo da empresa. Esse novo framework foi denominado como Framework SERPRO, e em março de 2008 teve liberada sua versão 0.1. Em abril do mesmo ano foi criada a equipe de gestão do Framework SERPRO - CETEC/PGJEE - atualmente denominada CETEC/CTJEE.
Arquitetura ^
A figura abaixo representa a estrutura geral do Framework SERPRO e suas dependências estruturais. A primeira camada, denominada como Architectural Framework constitui o framework integrador. Doravante, o foco desta documentação é essa camada, que trata-se mais especificamente de um framework arquitetural de aplicações web não distribuídas. Além disso, há uma restrição quanto ao ambiente de produção, onde necessariamente deve haver um servidor JBoss 4.2.x ou Tomcat 6.x.
Framework Arquitetural ^
O framework arquitetural provê essencialmente uma biblioteca central de módulos que atende às necessidades de infra-estrutura básica de uma aplicação web não distribuída. A idéia é que ele seja o mais fracamente acoplado quanto possível, de forma que através do desenvolvimento orientado a componentes, as aplicações possam ser criadas e modificadas com substituição ou acoplamento de novos módulos, sem que o núcleo central precise ser modificado.
Essa arquitetura flexível junto com uma base de código extensível e bem testada permite aplicar ao processo de desenvolvimento de sistemas a metáfora das montadoras de veículos. No princípio, haviam fábricas de carros, que construíam todas as peças do veículo e o montavam. Esse modelo já foi superado pelo conceito de montadora. As antigas fábricas pararam de construir todas as peças e hoje montam os veículos a partir de componentes fabricados por terceiros.
O framework arquitetural permite fazer uma analogia com as montadoras. Os sistemas não precisam ser fabricados, desde o zero. Eles podem ser montados, a partir de uma infra-estrutura genérica (o framework arquitetural) a qual são acoplados componentes que constituem a parte específica de cada sistema.
Os objetivos traçados para o framework arquitetural e as respectivas decisões de projeto tomadas para alcançá-los são as seguintes:
| Objetivo 1 | Extensibilidade |
| Decisão de Projeto | A arquitetura possui pontos de extensão seja por meio de interfaces, abstrações ou pela utilização de padrões de projetos tais como Inversão de Controle e Abstract Factory. Também possibilita a aplicação do padrão Bridge em futuros projetos. Segue abaixo as principais interfaces da arquitetura. * IDAO: Representa o objeto da camada de persistência, responsável pelo acesso aos dados. Classes do tipo IDAO não acessam outras camadas do framework, apenas a de persistência; * IFacade: Representa camada de comunicação entre módulos ou sistemas; * IBusinessController: Representa o objeto da camada de negócio e acessa a camada de persistência através de classes que implementam a interface IDAO Poderá acessar funcionalidades de outros sistemas ou módulos através de implementações da interface IFacade; * IViewController: Representa o objeto da camada de visão que terá acesso somente as classes que implementam as interfaces IFacade e IBusinessController; |
| Objetivo 2 | Reusabilidade |
| Decisão de Projeto: | A arquitetura favorece o reuso a partir da especificação de artefatos comuns em diversos projetos. Os principais artefatos de reuso são a arquitetura de referência e os componentes do framework listados abaixo: * Reports * Cryptography * Certificate |
| Objetivo 3 | Manutenibilidade |
| Decisão de Projeto: | A arquitetura divide responsabilidades entre módulos lógicos para garantir o menor impacto no todo, diminuindo o acoplamento e focando a manutenção em pontos específicos. |
| Objetivo 4 | Desempenho |
| Decisão de Projeto: | A arquitetura proposta minimiza os riscos de desempenho nas aplicações instanciadas por implementar os pontos críticos de performance, tais como, a integração entre camadas e controle de transações. |
| Objetivo 5 | Estabilidade/Confiabilidade |
| Decisão de Projeto: | A arquitetura é fundamentada em especificações (Foundation Framework) reconhecidas pelo mercado que garantem a estabilidade para o desenvolvimento de aplicações baseadas nela. |
Componentes ^
Este módulo em especial contém componentes auto-contidos utilizados conforme necessidade de cada projeto instanciado a partir do framework. Os componentes tem um ciclo de vida próprio, cada um deles é desenvolvido com um objetivo específico e podem ser utilizados junto com o framework de acordo com a necessidade da aplicação. Os componentes do pacote padrão incluem:
Implementações de módulos de autenticação baseados na especificação JAAS utilizados pelas aplicações.
Implementação de mecanismos de criptografia baseados na especificação JCE.
Implementação de mecanismos para manuseio de informações baseado em certificado digital X.509.
Conjunto de componentes JSF para interface gráfica.
Mecanismo para geração de relatório.
Gerenciador de tarefas agendadas.
Mecanismo de geração de consultas Hibernate baseado em filtros.
Mecanismo para envio de email.
Estrutura inicial de um projeto para aplicações Web baseadas no framework.
Visão de Implantação ^
Os componentes do framework podem ser utilizados pela aplicação de duas formas.
A primeira é através do processo manual, onde os artefatos são copiados diretamente para o projeto da aplicação, nesse caso o responsável pela aplicação deve estar atento ao controle de versão de cada componente e também deve copiar os frameworks de base utilizados por cada componente, ou seja, deve garantir que todas a dependências entre o framework e frameworks de base sejam atendidas. A figura abaixo ilustra essa relação. O processo manual é trabalhoso e sujeito a falhas pois exige que o desenvolvedor esteja atento a qualquer mudança com relação as dependências entre os componentes do framework e frameworks de base.
Na segunda forma o desenvolvedor estabelece as dependências entre o framework e a aplicação através do Maven, nesse caso essa ferramenta auxilia o processo de controle de dependência de forma automatizada, facilitando o trabalho e diminuindo a possibilidade de falhas.
Visão de Implementação ^
O framework está dividido em dois módulos principais, o primeiro é o framework arquitetural (core, util, web, persistence e view) e o segundo é um conjunto de componentes. O framework arquitetural promove a padronização na construção das aplicações. Os componentes são complementares ao framework e possuem ciclo de vida próprio, desta forma podem ser utilizados individualmente de acordo com a necessidade da aplicação. Novos componentes podem ser adicionados a cada release.
Funcionalidades ^
Funcionalidades críticas identificadas no documento de visão do projeto (DVP).
| ID | Descrição da Funcionalidade |
| F1.01 | Especificar definição de camadas |
| F1.02 | Especificar abstração de componentes para cada camada |
| F1.03 | Prover projeto mínimo baseado em arquétipos |
| F1.04 | Especificar regras de PMD |
| F2.01 | Criar injeção de dependência entre componentes das camadas |
| F3.01 | Implementar especificação padrão para controle transacional. |
| F3.02 | Prover controle transparente de transação às aplicações |
| F3.03 | Prover um contexto de transação. |
| F4.01 | Implementar controle de autenticação e autorização |
| F4.02 | Prover acesso ao contexto de segurança a partir das camadas |
| F4.03 | Prover mecanismo para criptografia |
| F4.04 | Prover API padrão de certificado digital |
| F4.05 | Prover um contexto de segurança. |
| F5.01 | Prover acesso a dados por meio de Hibernate, JDBC e SQLADA |
| F5.02 | Prover mecanismos de busca simplificados |
