PROBLEMA
Os softwares de cálculo de preço de venda geralmente implementam um único método de custeio, o que dificulta a análise do gestor, pois para comparar preços, ele tem que usar sistemas diferentes, ou seja, não existe um framework nessa área. Permite ao administrador analisar o preço ideal de venda dos produtos ou serviços com apenas um software.
OBJETIVOS
- Objetivo Geral
- Objetivos Específicos
ORGANIZAÇÃO DO TRABALHO
Este capítulo fornece uma visão geral das estruturas de domínio e métodos na literatura para determinar os preços de venda.
FRAMEWORKS: UMA VISÃO GERAL
- Classificação
Segundo Matos (2008), “um framework é um conjunto de subsistemas, subframes e componentes que interagem e cooperam para produzir um projeto global para um determinado domínio”. Um subsistema “representa uma parte reutilizável de um subsistema ou um conjunto deles que pode ser reutilizado em um novo aplicativo de exemplo” (MATOS, 2008). Neste trabalho é tratado o enquadramento do domínio, uma vez que os métodos estudados pertencem ao mesmo contexto, portanto apesar dos métodos terem diferenças entre si, todos têm como principal função a fixação do preço de venda.
ANÁLISE DE DOMÍNIO DO FRAMEWORK DE DOMÍNIO PROPOSTO
- Métodos de Preço de Venda
- Método de Custeio Baseado em Atividades (Activity-Based Costing)
- Método Sebrae-PR
- Método Baseado no Custo Pleno
Para uma melhor compreensão do método ABC, o exemplo a seguir é aplicado em uma atividade agrícola (CRAZUSKI et al., 2008). Sua operação consiste na soma de todos os custos e despesas do produto ou serviço, que incluem matérias-primas, mão de obra direta, custos indiretos de produção, custos de transformação, custos de produção e despesas comerciais e administrativas. Inicialmente, são definidos os custos envolvidos com matérias-primas, mão de obra direta e custos indiretos de produção, que posteriormente são somados para gerar o valor do Custo de Produção.
ABORDAGENS PARA O DESENVOLVIMENTO DE FRAMEWORK DE
- Processo Dirigido por Responsabilidades Aplicado ao Desenvolvimento
- Descrição das fases da abordagem PDR-DFD
- Fase Projetar Framework de Domínio
Design Domain Framework: O próprio framework é desenvolvido, ou seja, os frameworks base e de aplicação são gerados. A etapa "Design Domain Framework" (Figura 3) consiste em duas sub-etapas: "Entender a aplicação de amostra" e "Definir a estrutura básica e de aplicação". As classes geradas anteriormente separam as classes que farão parte do Framework Base e Application Framework.
CONCEPÇÃO DA ARQUITETURA DO FRAMEWORK
A Seção 3.2 relata o uso da subfase Define Framework Architecture no domínio do preço de venda.
SUBFASE 1 - DEFINIR A ARQUITETURA DO FRAMEWORK
O módulo de Cálculo é equivalente aos módulos: Cálculo do Preço de Venda (ABC), Cálculo do Preço de Venda (Zebrae) e Cálculo do Preço de Venda (Custo Total). Finalmente, o módulo Connection não é colocado nesta arquitetura porque é implementado na camada de persistência. Neste trabalho, optou-se pelo desenvolvimento do Subframework Food System, Atributos e Cálculo, pois foi verificado que os mesmos possuem funcionalidades comuns entre os métodos de preço de venda estudados.
SUBFASE 2 – SELECIONAR E MODELAR REQUISITOS DAS
- Modelo de Requisitos
A planilha na íntegra é apresentada no Quadro 13, Apêndice D. Figura 6 – Tabela de Casos de Uso UML para cada aplicativo de exemplo Fonte: Autoria. Com os requisitos já definidos, foi criado um diagrama de casos de uso UML-F para o subsistema Propriedades, ilustrado na Figura 8. As notações utilizadas seguem o mesmo padrão dos diagramas de casos de uso UML-F para os subsistemas Propriedades e Sistema Alimentar.
SUBFASE 3 – REFINAR OS REQUISITOS
- Refinamento de Requisitos para o Subsistema Attributes
- Refinamento de Requisitos para o Subsistema FoodSystem
- Refinamento de Requisitos para o Subsistema Calculation
A Figura 10 ilustra a descrição textual do caso de uso "Tela Open Food System", referente ao Diagrama de Casos de Uso UML-F para o Subsistema FoodSystem (Figura 9). As demais descrições textuais do diagrama de caso de uso do subsistema FoodSystem podem ser encontradas no apêndice F. A Tabela 11 ilustra a descrição textual do caso de uso "Acessar tela de cálculo", referente ao diagrama de caso de uso UML-F para o subsistema de cálculo (figura 10 ).
SUBFASE 4 – REFINAR CLASSES E DEFINIR SUBFRAMEWORKS
- Refinamento de Classes para o Subframework Attributes
- Refinamento de Classes para o Subframework FoodSystem
- Refinamento de Classes para o Subframework Calculation
As descrições textuais do Diagrama de Casos de Uso do Subsistema de Cálculo podem ser encontradas na íntegra no Apêndice G. Analisando o subsistema Gerenciar Atributos, notou-se que ele necessita de atributos para realizar o cálculo dos custos fixos e variáveis. A Figura 14 ilustra o pacote View do subsistema de atributos, no qual as interfaces são identificadas por seus estereótipos, conforme já mencionado nas Figuras 12 e 13. A classe DAOFactory está localizada no pacote Persistence.DAO, que é responsável por instanciar a classe correta para cada método requerido.
O pacote Persistence.DAO.Firebird, ilustrado na Figura 18, contém a classe FBDAOFactory, responsável pela conexão com o banco de dados. Assim como no Subsistema de Atributos, a parte lógica do Subsistema FoodSystem foi desenvolvida seguindo o padrão de projeto MVC (Model-view-controller), que separa a lógica de negócios da lógica de apresentação. A Figura 23 ilustra o pacote Persistence.DAO no subsistema FoodSystem, que possui as interfaces AbcAttributeDAO, SebraeAttributeDAO, FullCostAttributeDAO, LogValuesDAO, FullCostItem, AbcProductDAO e AbcProductionLineDAO, todas identificadas por seu estereótipo.
Essas classes têm a função de conectar a interação do usuário com o banco de dados, ou seja, tratam da regra de negócio que faz parte do Subsistema FoodSystem. O diagrama de classes ilustrado pela Figura 25 ilustra o pacote Persistence.DAO.Firebird, que contém as classes AbcActivityDAOFirebird, AbcAttributeDAOFirebird, AbcProductDAOFirebird, AbcProductionLineDAOFirebird, FullCostAttributeDAOFirebirdDAOFireDAbird, FullCostItAbirde, Log OFirebird e, a mais importante delas, FBDAOFactory, responsável por conectando-se a o banco de dados. Para refinar as classes no subsistema computacional, os diagramas de classe UML do trabalho de Crazuski et al. 2008) e constatou-se que o subsistema de cálculo do preço de venda (ABC) é formado por 2 (duas) classes, o subsistema de cálculo do preço de venda (Sebrae-PR) é formado por 4 (quatro) classes e o preço de venda (Custo Pleno) O subsistema de cálculo de preços é composto por 2 (duas) classes.
A classe FB DAO Firebird encontrada no pacote Persistence.DAO.Firebird é responsável pela conexão com o banco de dados.
SUBFASE 5 – DEFINIR FRAMEWORK BASE E DE APLICAÇÃO
O pacote View contém as classes que fornecem as interfaces do sistema por meio das quais o usuário irá interagir com o software. Nas classes VO e BusinessRule, existem as classes que definem como as interfaces de usuário respondem às entradas do usuário, ou seja, ambos os pacotes são responsáveis por gerenciar a interação entre os pacotes View e Persistence. Por outro lado, as classes específicas, hot spots, estão localizadas dentro do pacote features na parte específica do framework (Figura 35).
Como todos os diagramas seguem um padrão, as classes gerais são identificadas por classes cinzas, enquanto as classes específicas são identificadas por brancas. Contém também o pacote Firebird, que é composto pela classe FBDAOFirebird, responsável pela conexão com o banco de dados e pelas classes referentes a cada método de determinação de preço de venda que implementa as interfaces do pacote DAO. O pacote View contém as classes com as quais o usuário irá interagir com o sistema, ou seja, neste pacote encontram-se as classes que se referem às interfaces do software.
E por fim, os pacotes VO e BusinessRule são todas as classes responsáveis por gerenciar a interação entre os pacotes View e Persistence. Neste pacote são apresentadas as classes gerais e específicas, representadas pelas classes de cor branca e cinza e pelos estereótipos correspondentes. Uma interface é encontrada neste pacote, que é identificada pelo estereótipo <
A conexão com o banco de dados é realizada pela classe FBDAOFirebird que está dentro do pacote Firebird, juntamente com as classes que implementam as interfaces.
PROTÓTIPOS DOS SUBFRAMEWORKS
- Subframework Attributes
- Subframework FoodSystem
- Subframework Calculation
Se o atributo que você está registrando for do método de custo integral, é necessário selecionar a variável que pertence a este atributo. Se algo na verificação estiver errado, uma mensagem de erro é exibida (Figura 58) e o processo de registro não é concluído. Se o botão Salvar for pressionado, o sistema simplesmente atualiza os valores do produto, retornando uma mensagem de sucesso ou falha na operação, ilustrada nas Figuras 61 e 62, respectivamente.
Apesar da semelhança desta tela com a tela de alimentação do sistema do método ABC (Figura 60), o método ABC requer os campos: linha de produção e atributos, e não possui campo RadioButton. Este campo é necessário para calcular o preço de venda usando o método de custo total, que varia de acordo com a fórmula. A Tela de Alimentação do Sistema do Método Sebrae é semelhante à Tela de Alimentação do Sistema dos outros métodos já citados, porém possui algumas funcionalidades.
O processo de cálculo na tela Cálculo do método de custo total (Figura 69) é muito mais simples, pois você só precisa inserir o percentual da margem de lucro que deseja obter no preço final. Na parte central da tela existe um campo onde é necessário informar a margem de lucro e um botão "Calcular" que realiza o cálculo do Método de Custo Total. Se o valor digitado não for válido, uma mensagem de erro é exibida impedindo que o processo seja concluído (Figura 70).
A tela de cálculo do método Sebrae, ilustrada na Figura 73, mostra as fórmulas para determinação do preço de venda na parte superior e o resultado final na parte inferior, que podem ser salvas pressionando o botão "Salvar".
EXTENSÃO DOS MODELOS
- Subframework Attributes
- Pacote View
- Pacote VO
- Pacote BusinessRule
- Pacote Persistence
- Subframework FoodSystem
- Pacote View
- Pacote VO
- Pacote BusinessRule
- Pacote Persistence
- Subframework Calculation
- Pacote View
- Pacote VO
- Pacote BusinessRule
- Pacote Persistence
A Figura 77 ilustra as classes Adaptable3 e Adaptable4 que devem ser inseridas no pacote BusinessRule para inserir um novo método. A Figura 78 mostra as classes necessárias, tanto no pacote DAO quanto no subpacote DAO.FIREBIRD, para adicionar um novo método. No pacote DAO, a classe Adaptable1 com o estereótipo <
A Figura 79 mostra a classe Adaptable1 com o estereótipo <
As classes a serem inseridas no pacote Persistence no subframe Food System estão presentes na Figura 82 com o estereótipo <
No pacote DAO é representado pela classe Adaptable1 que possui o estereótipo <
VANTAGENS E DESVANTAGENS DO DESENVOLVIMENTO DE
A estrutura proposta atende aos requisitos no domínio do preço de venda, pois é construída considerando três métodos de custeio. Considera também as necessidades do ponto de vista do gestor, uma vez que o framework contém diversos métodos de formação do preço de venda, para utilizar o sistema para calcular o preço de venda de um serviço ou produto em diferentes métodos. A arquitetura geral do framework foi desenvolvida para tentar separar os pontos de estabilidade e flexibilidade, que estão agrupados na base - pontos comuns entre os métodos - e os específicos - características específicas de cada método.
Essa separação foi possível porque foi aplicado o Processo Orientado por Responsabilidades para o Desenvolvimento da Estrutura de Domínio (PDR-DFD). Também foi demonstrado que, pelo fato de a modelagem ter sido desenvolvida com base nos critérios do framework, a extensão do modelo para um novo método é facilitada, pois os elementos a serem adicionados, implementados ou alterados são explicados nos diagramas, conforme relatado no capítulo 4.
TRABALHOS FUTUROS
