Relatório do GPES UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Relatório referente ao desenvolvimento da arquitetura geral do framework de preço de venda. Realizado no período de 29 de junho de 2010 a 30 de julho de 2010. Arquitetura Geral do Framework Atualmente vários métodos têm sido propostos objetivando melhorar o processo de desenvolvimento software, bem como minimizar os custos de manutenção [1]. A arquitetura de software é um deles, pois permite projetar a estrutura geral do sistema. Questões estruturais envolvem organização e estrutura geral de controle; protocolos de comunicação, sincronização; atribuição de funcionalidade a componentes de projeto; escalabilidade e desempenho; seleção de alternativas de projeto [1]. Essas questões compreendem o projeto de software no nível arquitetural, sendo divididas em quatro. Primeiro é importante ser capaz de reconhecer estruturas comuns de modo que projetistas de software possam compreender as relações existentes entre sistemas e desenvolver sistemas novos com base em variações de sistemas antigos. Segundo, o entendimento de arquitetura de software permite que os engenheiros tomem decisões sobre alternativas de projeto. Terceiro, uma descrição arquitetural do sistema é essencial para analisar e descrever propriedades de um sistema complexo. Quarto, o conhecimento de notações para descrever arquiteturas possibilita que os engenheiros apresentem novos projetos de sistemas a outros membros de uma equipe de desenvolvimento. Numa visão e estratégia de reuso de software, tem-se enfatizado a importância de reuso centrado na arquitetura para o desenvolvimento de software durante todo o seu ciclo de vida. A arquitetura de software serve como uma estrutura que permite o entendimento de componentes de um sistema e seus inter-relacionamentos, especialmente aqueles atributos que são consistentes ao longo do tempo e implementações. 1
Um dos pontos principais no desenvolvimento da arquitetura de um framework é a identificação dos pontos de comuns (frozen spots) e flexíveis (hot spots). Um ponto comum caracteriza-se pelas funcionalidades que são iguais a todas as aplicaçõesexemplo do domínio. Por sua vez, os pontos flexíveis são as funcionalidades específicas de cada aplicação-exemplo. Neste trabalho, as aplicações-exemplo são os métodos da literatura usados para formação de preço de venda tais como: Método de Custeio Baseado em Atividades (Activity-Based Costing); Método SEBRAE-PR; Método Baseado no Custo Pleno. A arquitetura geral do framework, ilustrada na Figura 1, foi dividida em dois pacotes principais: Base e Specific, os quais contêm as classes que são comuns frozen spots e específicas hot spots -, respectivamente. Figura 1 Arquitetura Geral do Framework Há uma relação de dependência entre o pacote Specific e o pacote Base, pois todos os pontos específicos do framework necessitam dos pontos comuns para seu funcionamento. A seguir serão detalhados os pacotes Base e Specific. 2
Pacote Base No interior do pacote Base, verificou-se a necessidade de outros 2 (dois) novos pacotes: Attributes e FoodSystem (figura 2). O pacote Attributes é responsável por todo o gerenciamento dos atributos utilizados nos métodos de custeio e o pacote FoodSystem tem como função gerenciar a entrada de dados que alimenta o sistema afim de efetuar os cálculos necessários para estabelecer o preço de venda do produto. Figura 2 Pacote Base. Para alimentar o sistema, ou seja, atribuir valores aos atributos é necessário haver atributos cadastrados, por este motivo há uma relação de dependência entre o pacote FoodSystem e o pacote Attributes. O pacote Attributes foi modelado e implementado usando o desenvolvimento em camadas View, VO, BusinessRole, Persistence - e dentro destas foram aplicados alguns padrões de projeto, entre eles: Decorator, Abstract Factory, Factory Method, DAOFactory e MVC (Model-view-controller). A arquitetura deste pacote está ilustrado na figura 3. 3
Figura 3 Pacote Attributes Definidas as dependência de cada pacote, as figuras 4, 5, 6, e 7 ilustram respectivamente os pacotes View, VO, BusinessRole e Persistence, contidos no subframework Gerenciar Atributo. Onde no pacote View, encontram-se as classes que provêem as interfaces do sistema por meio das quais os usuários irão interagir com o software. No pacote Persistence encontram-se as classes responsáveis pela conexão ao Banco de Dados. Nas classes VO e BusinessRole, encontram-se as classes que definem o modo como as interfaces do usuário reagem às entradas do mesmo, ou seja, ambos os pacotes são responsáveis pelo gerenciamento da interação entre os pacotes View e Persistence. 4
Figura 4 Pacote View. Figura 5 Pacote VO. Figura 6 Pacote BusinessRule. 5
Figura 7 Pacote Persistence. Devido a aplicação do padrão de projeto DAOFactory, o pacote Persistence possui em seu interior apenas o Pacote DAO. Neste pacote, há uma classe abstrata chamada DAOFactory e outro Pacote chamado Firebird, em que se localiza a classe FBDAOFactory que herda os métodos da classe abstrata do Pacote DAO. As figuras 8 e 9 ilustram o Pacote DAO e o Pacote Firebird, respectivamente. Figura 8 Pacote DAO. 6
Figura 9 Pacote Firebird Pacote Specific As partes específicas, hot spots, de todos os subframeworks que compõem o framework de otimização de Preço de Venda permanecem no interior deste pacote e é ilustrado pela figura 10. Figura 10 Pacote Specific 7
Alguns subframeworks são comuns entre os métodos de formação de preço de venda, como por exemplo, o subframework Attribute e Calculation, porém a implementação de ambos são diferentes para cada método a ser empregado. O subframework Attribute, não contém os mesmos atributos nos 3 (três) métodos estudados, como o Calculation também não possui a mesma fórmula para calcular o preço de venda de um determinado produto. Com exceção do pacote Attribute, todos os outros subframeworks contidos no pacote Specific são em sua totalidade específicos. A relação de dependência existente entre estes subframeworks é simples. O subframework ProductionLine é o único que não depende de nenhum outro, pois para efetuar o cadastro de uma nova linha de produção é necessário apenas o nome desta nova linha. Já o subframework Product, necessita o nome do novo produto e também da linha de produção que ele pertence. O mesmo acontece com o subframework Attribute, que precisa do nome do novo atributo a ser cadastrado juntamente com a linha de produção que este produto esteja relacionado. O subframework Activity além de necessitar do nome da nova atividade, também se relaciona com um atributo e com uma linha de produção. O subframework Calculation é responsável pelo cálculo do preço de venda do produto, porém para obter êxito em sua função, deve estar com todos os atributos e valores disponíveis. Como já mencionado, o subframework Attributes foi modelado e implementado seguindo alguns padrões de projeto já descritos anteriormente. A figura 11 ilustra o pacote Attributes. 8
Figura 11 Pacote Attributes Specific. A estrutura dos pacotes View, VO, BusinessRole e Persistence contidos no subframework Attributes seguem o padrão de projeto MVC. As figuras 12, 13, 14 e 15 ilustram respectivamente cada pacote. 9
Figura 12 Pacote View - Specific 10
Figura 13 Pacote VO Specific 11
Figura 14 Pacote BusinessRole - Specific 12
Figura 15 Pacote Persistence Specific Devido a aplicação do padrão de projeto DAOFactory já citado anteriormente, no interior do pacote Persistence há apenas outro pacote chamado DAO. Neste pacote estão as interfaces de cada método de custeio juntamente com outro pacote chamado Firebird, que por sua vez possui classes de cada método de formação de preço de venda que implementam os métodos das interfaces situadas no pacote DAO. As figuras 16 e 17 ilustram o Pacote DAO e o Pacote Firebird, respectivamente. Figura 16 Pacote DAO Specific 13
Figura 17 Pacote Firebird Specific Referências [1] MENDES, A. Arquitetura de software: desenvolvimento orientado a arquitetura. Rio de Janeiro: Campus, 2002. 212p. [2] SHAW, M.; GARLAN, D. Software Architecture - Perspectives on an Emerging Discipline, Upper Saddle River, NJ, Prentice-Hall, 1996. 14