• Nenhum resultado encontrado

Uso do processo dirigido a responsabilidades no desenvolvimento da arquitetura e modelagem do framework de preço de venda

N/A
N/A
Protected

Academic year: 2023

Share "Uso do processo dirigido a responsabilidades no desenvolvimento da arquitetura e modelagem do framework de preço de venda"

Copied!
172
0
0

Texto

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.

Figura 1 - Representação gráfica de um framework  Fonte: Matos (2008, p.43).
Figura 1 - Representação gráfica de um framework Fonte: Matos (2008, p.43).

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.

Figura 2 - Modelo de ciclo produtivo agrícola  Fonte: Adaptado de Crazuski et al. (2008)
Figura 2 - Modelo de ciclo produtivo agrícola Fonte: Adaptado de Crazuski et al. (2008)

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.

Figura 3 – Subfases da fase “Projetar Framework de Domínio”
Figura 3 – Subfases da fase “Projetar Framework de Domínio”

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.

Figura 5 - Arquitetura Inicial para o Framework  Fonte: Autoria Própria.
Figura 5 - Arquitetura Inicial para o Framework Fonte: Autoria Própria.

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.

Figura 6 – Tabela de Caso de Uso UML de cada aplicação-exemplo  Fonte: Autoria Própria
Figura 6 – Tabela de Caso de Uso UML de cada aplicação-exemplo Fonte: Autoria Própria

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.

Figura 11 – Aplicação dos Padrões no Subsistema Attributes  Fonte: Autoria Própria.
Figura 11 – Aplicação dos Padrões no Subsistema Attributes Fonte: Autoria Própria.

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 <> que é comum entre aplicativos de exemplo, como classes identificadas pela cor branca.

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.

Figura 34 – Pacote Base  Fonte: Autoria Própria.
Figura 34 – Pacote Base Fonte: Autoria Própria.

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".

Figura 51 – Tela de Busca do Método ABC  Fonte: Autoria Própria.
Figura 51 – Tela de Busca do Método ABC Fonte: Autoria Própria.

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 <> representa onde inserir uma nova classe, e no pacote DAO.FIREBIRD, a classe Adaptable2 com o estereótipo <> representa a inserção que deve existir no a classe FBDAOFactory.

A Figura 79 mostra a classe Adaptable1 com o estereótipo <>, a classe necessária no pacote View para inserir um novo método nas subestruturas FoodSystem. A Figura 80 ilustra a classe Adaptable1 destacada em cinza no modelo. Essa classe no pacote VO especifica onde adicionar uma nova classe, caso outro método seja adicionado. A Figura 81 mostra onde inserir novas classes no pacote BusinessRule à medida que novos métodos são adicionados, são as classes: Adaptable1 e Adaptable2, representadas pelo estereótipo <>.

As classes a serem inseridas no pacote Persistence no subframe Food System estão presentes na Figura 82 com o estereótipo <> e na cor cinza são: Adaptable1 e Adaptable2. A Figura 83 mostra a classe Adaptable1 com o estereótipo <> que é a classe necessária no pacote View para inserir um novo método no Subframework de Cálculo. A Figura 85 mostra a classe Adaptable1 que deve ser inserida no pacote BusinessRule para inserir um novo método.

No pacote DAO é representado pela classe Adaptable1 que possui o estereótipo <> e no pacote DAO.FIREBIRD é representado pela classe Adaptable2 com o estereótipo <> que está conectado à classe FBDAOFactory.

Figura 75 – Classes necessárias no pacote View do Subframework Attributes para a inclusão  de um novo método
Figura 75 – Classes necessárias no pacote View do Subframework Attributes para a inclusão de um novo método

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

Imagem

Figura 16 – Pacote Persistence.DAO do Subsistema Attributes  Fonte: Autoria Própria.
Figura 31 – Pacote Persistence.DAO do Subsistema Calculation  Fonte: Autoria Própria.
Figura 39 – Pacote BusinessRule pertencente ao Subframework Attributes  Fonte: Autoria Própria
Figura 40 – Pacote Persistence pertencente ao Subframework Attributes  Fonte: Autoria Própria
+7

Referências

Documentos relacionados

 o vetor de interrupções fica na memória do processador a partir do endereço 0.  basta armazenar a tabela com os endereços das ISRs nesta região