Este é um resumo de minha dissertação de mestrado, defendida em 2013, para obtenção de MESTRE EM ENGENHARIA DE PRODUÇÃO, na área de concentração de Gestão Industrial, Programa de Pós-Graduação em Engenharia de Produção.

Nela eu construí uma camada de serviços, baseados na tecnologia de Web Services SOAP/WSDL, com o intuito de possibilitar o uso do framework de domínio, chamado Framemk, por sistemas ERP em qualquer tecnologia.

Apesar do ano de conclusão deste trabalho, ainda hoje ao escrever este artigo, ele continua relevante.

Resumo da dissertação

O processo de definição de preços de venda é crítico para o sucesso competitivo das organizações.

A inexistência de sistemas ERP gratuitos que implementem diversos métodos de precificação criam um contexto de deficiência de ferramentas que auxiliem os gestores com esta necessidade.

Assim este trabalho teve por objetivo principal demonstrar o uso de diversos métodos de precificação, por meio do framework de definição de preço de venda - FrameMK em sistemas ERP gratuitos e open source, independentemente da sua plataforma tecnológica, por intermédio de arquitetura de camada de serviços web.

Foram utilizadas ferramentas e métodos de desenvolvimento de software para atingir o objetivo, dentre eles a linguagem de modelagem UML e a linguagem de programação Java.

Realizou-se a descrição dos requisitos de serviços e recursos de alto nı́vel que auxiliaram na etapa de implementação dos serviços Web utilizando as tecnologias SOAP / WSDL e REST.

Resultados obtidos

Os principais resultados obtidos foram:

  • modelos de projeto dos três nı́veis de serviço
  • modelos para implantação do FrameMK
  • casos de uso utilizados como base para a descrição de requisitos para o desenvolvimento das funções do terceiro nı́vel de serviços

Produto

O produto de software resultante:

ERPs utilizados

Os sistemas ERP: webERP, OpenBravo e OpenERP foram trabalhados para demonstração da aplicação dos serviços e resultaram em versões integradas com o framework. Com estas versões os gestores de negócio beneficiam-se com a melhoria do processo de precificação de seus produtos e serviços.

Modelagem da camada de Serviços

Kruchten (2000) e Kruchten, Obbink e Stafford (2006) apontam para a análise da arquitetura do software de forma a melhor projetar as propriedades do sistema.

Neste artigo descvrevo os resultados obtidos com o estudo e análise do produto a ser construído, no formato de modelos propostos para serem utilizados na codificação. Eles são consequência do estudo do FrameMK e dos métodos que este implementa.

Também apresento a modelagem para os requisitos e modelagem para implantação do framework com suas interfaces e camada de serviços.

O formato arquitetural resultante baseia-se nos requisitos a serem atendidos na criação de SI de baixo acoplamento, como proposto por Papazoglou e Heuvel (2007).

Assim a utilização de modelos para construção de uma camada SOA estabelece uma arquitetura que visa aprimorar a eficiência, agilidade e produtividade de uma empresa. Através desta arquitetura será possível criar serviços interoperáveis que facilitam o reuso e compartilhamento de regras de negócio da organização (GARTNER, 2011).

Modelagem dos serviços

Para modelar a camada de serviços foi necessário estudar a arquitetura e caracterı́sticas atuais do FrameMK. Como implementado originalmente, existe a possibilidade de extensão e criação de novos métodos, além dos três já implementados: Sebrae, Custo Pleno e ABC.

Como também da utilização do framework por aplicativos comerciais e ERP existentes, porém desenvolvidos explicitamente na linguagem Java.

A possibilidade de utilização e extensão da atual arquitetura é exemplificada pela figura a seguir.

Arquitetura FramemK
Arquitetura FramemK

Neste exemplo é apresentada a arquitetura dos três métodos já implementados, e um novo método baseado em Valor do Mercado.

Também é demonstrada a possibilidade de utilização do framework por um sistema de ERP desenvolvido na plataforma Java, tendo assim acesso a todos os métodos de definição de preço de venda disponı́veis pelo aplicativo.

A figura acima também identifica a existência das duas interfaces de usuário já criadas, a saber, a interface em ambiente desktop, desenvolvida em plataforma Java com o framework para interfaces denominado Swing. E a interface para ambiente web, também desenvolvida em plataforma Java, com o framework para desenvolvimento chamado Struts.

A partir desta arquitetura a camada de serviços foi modelada em três nı́veis:

  • 1o - Expõe diretamente a interface de programação do framework (API) determinando o nı́vel de mais baixo acesso.
  • 2o - Padroniza a nomenclatura e acesso às funções de um método de definição de preço de venda por um único serviço.
  • 3o - Compõe à partir dos serviços implementados nos nı́veis inferiores, novas funcionalidades não existentes no FrameMK, tais como:
    • retorno dos nomes e identificações dos métodos implementados, cálculo e retorno de todos os preços de venda por método em uma única chamada, comparação de valores de preço de venda por método.

A modelagem resultante da camada de primeiro nı́vel foi realizada para cada método de precificação implementado. Neste nı́vel cada função da API (Application ProgrammingInterface) do framework possui um serviço diretamente ligado e dependente dela.

Esta exposição direta de funções se baseia no conceito do padrão de projeto de desenvolvimento de software denominada Fachada (Facade).

Ao aplicar este padrão garante-se, quando necessário, que o framework seja utilizado como se estivesse inserido no código de uma
aplicação em Java, a qual pode acessar os métodos diretamente sem a necessidade de utilizar os serviços.

Modelagem método SEBRAE

A a seguir mostra a modelagem para o método SEBRAE.

Modelagem de serviços de baixo nı́vel - SEBRAE
Modelagem de serviços de baixo nı́vel - SEBRAE

Cada uma das classes do pacote que implementa as funções de negócio está ligada à uma classe no pacote facade.sebrae
com substituição de nomes no prefixo BR para WS.

As classes de serviço repetem a mesma assinatura dos métodos de classe de negócio, tal como a função getAttributesSebrae() que
retorna um vetor de atributos do tipo SebraeAttribute.

Modelagem método Custo Pleno

O modelo para o método do Custo Pleno é apresentado na próxima figura. Assim como na modelagem para o método Sebrae, as classes de serviço têm uma equivalência direta para as classes de negócio implementadas. As exceções ocorrem para métodos que sofrem sobrescrita em suas assinaturas no framework.

Modelagem de serviços de baixo nı́vel - Custo Pleno
Modelagem de serviços de baixo nı́vel - Custo Pleno

Sobrescrita de métodos de classe é uma caracterı́stica de linguagens de programação orientadas à objeto, que permite a existência de duas funções com o mesmo nome, porém com recebimento de um número ou tipos de parâmetros diferentes.

A classe FullCostItemBR implementa duas funções chamadas getItems que retornam um vetor de FullCostItem, porém para uma delas deve-se passar um código de atributo para filtragem, enquanto a outra sem recebimento de parâmetros retorna os itens sem filtrar.

Nestes casos foi necessário modelar funções de serviço com nomes diferentes pois a implementação de serviços web não possui a caracterı́stica de sobrescrita de métodos. No exemplo citado, a função de serviço com nome alterado chama-se getItemsByAttributeCode, com a mesma assinatura daquela getItems que recebe o código de um atributo para filtragem.

Modelagem método ABC

Para o método ABC também foram modeladas as classes de equivalência direta, de acordo com as descrições já realizadas para os métodos Sebrae e Custo Pleno. A a seguir ilustra o modelo de serviços de primeiro nı́vel do método ABC.

Modelagem de serviços de baixo nı́vel - ABC
Modelagem de serviços de baixo nı́vel - ABC

Outro motivo na modelagem e utilização deste primeiro nı́vel como uma fachada, é o de permitir mais facilmente que novos métodos de FPV sejam implementados sem que os serviços dos nı́veis acima parem de funcionar. Isto se deve ao fato da composição de serviços de segundo e terceiro nı́vel utilizar os serviços de primeiro nı́vel, não tendo assim acesso direto às funcionalidades no framework.