Applying the Responsibility-Driven Method in the Development of a
Subframework to Syntactic and Semantic Analysis of Formulas
Rodolfo Adamshuk Silva (Universidade Tecnológica Federal do Paraná, Paraná,
Brasil) – [email protected]
Simone Nasser Matos (Universidade Tecnológica federa do Paraná, Paraná,
Brasil) – [email protected]
Clovis Torres Fernandes (Instituto Tecnológico de Aeronáutica, São Paulo, Brasil)
– [email protected]
Abstract: This work provides an analytical study about framework development
approaches pointing out its main features. As a result of this applies a
responsibility-driven approach in developing of the subframework to formula
syntactic and semantic analysis. This study’s main goal is to show a practical
application of the responsibility-based approach to the creation of a subframework.
Also relates the differences in the subframework proposed with others similar
applications in the literature.
Keywords: Syntactic analysis, Semantic analysis, Subframework, Domain
framework, Responsibility.
Aplicando a Abordagem Dirigida por Responsabilidades no
Desenvolvimento de um Subframework de Análise Sintática e Semântica de
Fórmulas
Resumo: Este trabalho fornece um estudo analítico entre as abordagens para
desenvolvimento de frameworks, para as quais se buscou ressaltar suas
principais características, em especial o desenvolvimento de subframework.
Como resultado, aplicou-se a abordagem apontada como a mais apropriada para
essa tarefa, a saber, a abordagem dirigida por responsabilidades, para o
desenvolvimento do subframework de análise sintática e semântica de fórmulas.
O objetivo principal deste trabalho é mostrar o uso da abordagem dirigida por
responsabilidades na criação de subframework, relatando sua diferença com
relação aos outros aplicativos da literatura.
Palavras-Chave: Análise sintática, Análise semântica, Subframework, Framework
de domínio, Responsabilidade.
Agradecimentos
À UTFPR Campus Ponta Grossa pelo apoio financeiro destinado ao projeto desde
2007.
1. Introdução
Fayad et al. (1999) afirmam que a utilização de framework tem provado ser
especialmente eficiente quanto ao fator custo de desenvolvimento, porque
possibilitam o reúso tanto de funcionalidade quanto de arquitetura. A descrição de
sua arquitetura facilita o entendimento de seu comportamento, bem como seu
reúso, pois representa o relacionamento entre as classes e os seus algoritmos
implementados (VILJAMAA, 2003).
A arquitetura de um framework pode ser composta por subsistemas,
subframeworks e componentes. Um subsistema representa um conjunto de
classes interagindo e colaborando para executar uma função (WIRFS-BROCK;
MCKEAN, 2003). Um subframework é uma parte de um framework que
representa por si só um sistema generalizado e reutilizável, composto por um
conjunto de requisitos funcionais e não funcionais próprios (MATTSON, 2000).
Por fim, um componente representa uma parte independente e substituível de um
sistema que possui uma função clara, trabalhando no contexto de uma arquitetura
bem definida e comunicando-se com outros componentes por meio de suas
interfaces (BROWN; WALLNAU, 1998).
Segundo Kirk et al. (2005), existem problemas fundamentais a respeito do
reúso de frameworks, podendo-se destacar dentre eles a questão arquitetural,
que está relacionada com a dificuldade em se produzir modificações dentro do
framework sem levar em conta a qualidade arquitetural de alto nível. Várias
abordagens da literatura têm o objetivo de auxiliar a criação do projeto arquitetural
de um framework. Dentre elas, podem-se citar as seguintes, entre outras:
Johnson (1993), Fayad et al. (1999), Braga (2002) e Matos e Fernandes (2008).
Essas abordagens usualmente contemplam atividades em que o projeto
arquitetural do framework deve ser desenvolvido utilizando subsistemas,
subframeworks e componentes, mas algumas não especificam o processo de
como determinar e separar nos subframeworks os frozen e hot spots (PREE,
1999) com o objetivo de facilitar o reúso. Segundo Land (2002), a determinação
dos hot spots de um framework pode ser grande o que dificulta a tarefa de criá-lo,
compreendê-lo e testá-lo.
Neste trabalho analisaram-se qualitativamente as abordagens e decidiu-se
pela aplicação da abordagem dirigida por responsabilidades (MATOS;
FERNANDES, 2008) na criação do projeto do subframework de análise sintática e
semântica de fórmulas matemáticas. Foi escolhida tal abordagem, pois por meio
desta abordagem foi possível reusar grande parte dos artefatos tirados da
documentação das aplicações-exemplo, as quais representam aplicativos de
software típicos de um dado domínio usado por um processo na definição de um
framework de domínio, o que contribui para diminuir o tempo de desenvolvimento
do subframework. Além disso, relata as diferenças do subframework proposto
com outros softwares da literatura.
Este artigo tem a seguinte organização. A Seção 2 relata conceitos
fundamentais sobre frameworks, subframeworks, subsistemas e componentes. A
Seção 3 descreve um estudo analítico sobre como as abordagens da literatura
tratam o projeto arquitetural de framework e subframework. A Seção 4 descreve a
aplicação da abordagem dirigida por responsabilidades durante a criação do
modelo dos subframeworks. A Seção 5 apresenta um breve relato sobre os
resultados obtidos. A última seção descreve as conclusões finais deste trabalho.
2. Sobre Subsistemas, Subframeworks e Componentes
Antes de mostrar o desenvolvimento dos subframeworks, os conceitos de
framework, subsistema, subframework e componente são definidos no contexto
deste trabalho. Um framework é um conjunto eventual de subsistemas,
subframework e componentes, interagindo e colaborando de forma a produzir um
projeto geral para um domínio particular (MATOS; FERNANDES, 2006). Um
subframework representa um subsistema ou conjunto de subsistemas que foram
modelados a partir dos requisitos do framework, separando-se os frozen e hot
spots, de forma a facilitar o reúso. A Figura 1 ilustra um subframework para
validação sintática de fórmulas matemáticas. As classes que estão no
SubframeworkBase representam os frozen spots e as que estão no
SubframeworkAplicação são os hot spots. Esse subframework surgiu durante a
análise do desenvolvimento de um framework de domínio na formação de preço
de venda em que se constatou, nas aplicações-exemplo estudadas, que para
estabelecer o preço de venda de um produto se utiliza como entrada uma fórmula
matemática. Por isso, o subframework permite que cada aplicação-exemplo,
ApplicationN e Application1, seja instanciada a partir de sua definição,
funcionando como um caixa-preta. Desta forma, um subframework é uma parte de
um framework que representa por si só um sistema generalizado e reutilizável
(MATTSON, 2000).
Figura 1. Subframework para análise sintática (HORNUNG et al., 2008).
Um subsistema é um conjunto de classes interagindo e colaborando para
executar uma função (WIRFS-BROCK; MCKEAN, 2003). Por exemplo, para um
subsistema de Cálculo do Preço de Venda da aplicação-exemplo ABC (COGAN,
1999), têm-se as classes TelaCalculo e CalculoRN, ilustradas na Figura 2,
interagindo com outras classes contidas nos subsistemas Gerenciar Linha de
Produção e Gerenciar Produto com o objetivo de fornecer ao usuário final o valor
do preço de venda de um produto.
Figura 2. Diagrama de classes do subsistema de Cálculo do Preço de Venda
(CRAZUSKI et al., 2008).
Um componente é a transformação de uma parte independente de um
subsistema, framework ou subframework, que irá executar uma função bem
definida, em um projeto executável, permitindo ao desenvolvedor alterar somente
o que é flexível. Por exemplo, por meio do subframework de Análise Sintática
ilustrado na Figura 1, pode-se gerar um componente para ser usado em outras
aplicações-exemplos, como ilustra a Figura 3, onde mostra o resultado da
execução do subframework dentro do um ambiente de programação.
Figura 3. Componente de análise sintática – Fórmula do Custo de Transação
de uma Atividade do método ABC (HORNUNG et al., 2008).
3. Estudo Analítico de Trabalhos Relacionados
Para a realização deste estudo, levantaram-se na literatura as abordagens que
contemplavam um processo de definição arquitetural para o desenvolvimento de
frameworks e subframeworks. Dentre elas, destacam-se as seguintes: Johnson
(1993), Taligent (1994), Landin e Niklasson (1995), Pree (1999), Fayad et al.
(1999), Mattson (2000), Butler e Xu (2001), Braga (2002), e por fim, Matos e
Fernandes (2008).
Após o estudo das abordagens, realizou-se uma análise qualitativa entre
elas, considerando-se os seguintes critérios: Criação de subsistemas (SU),
subframeworks (SF) e componentes (C) – Possibilita a definição de uma
arquitetura que facilita o entendimento do funcionamento do sistema, bem como
seu reúso; Aplicação de padrões de projeto e metapadrões – Permite aumentar a
reusabilidade na fase de projeto; Análise arquitetural – É um processo iterativo
que permite que sejam feitos refinamentos no modelo arquitetural, que
inicialmente foi escolhido de forma a contribuir para a criação de uma arquitetura
que contemple algumas características julgadas interessantes, tais como:
integridade, reusabilidade e flexibilidade. Para Butler e Xu (2001), esse processo
é denominado de refatoração arquitetural; Estilo Arquitetural – Reduz o esforço
para compreender o sistema desenvolvido por outra pessoa e, portanto, diminui a
quantidade de informações que serão assimiladas num novo projeto permitindo,
desta forma, facilitar o reúso em um novo (BASS et al., 2003); Reúso Arquitetural
– Traz benefícios que incluem redução de custo de construção e do tempo de
produção; Definição dos Hot Spots nos subframeworks – Representam os pontos
que são específicos para uma aplicação-exemplo e constituem a parte central do
projeto de framework (PREE, 1999).
Na Tabela 1, relacionam-se as abordagens citadas e os critérios. As linhas
onde aparecem o “X” significa a presença do critério, caso contrário, a sua
ausência. Observou-se que todas as abordagens contemplam a utilização de
padrões de projeto e metapadrões durante a definição da arquitetura de
framework. Com relação à Criação de Subsistemas, Subframeworks e
Componentes verificou-se que somente a abordagem de Matos e Fernandes
(2008) abrange mais detalhadamente seu processo de identificação e construção.
Além disso, essa abordagem explica como a definição dos hot spots deve ser
feita durante a construção dos subframeworks na fase inicial do seu processo de
construção. Isso, de acordo com Tang et al. (2004), pode contribuir para a
confecção de um sistema com um maior grau de flexibilidade e portabilidade,
impactando sob os seus aspectos de desempenho, custo e escalabilidade.
Tabela 1. Critérios contemplados pelas abordagens da literatura.
Constatou-se também que o critério de Análise Arquitetural é contemplado
na maioria das abordagens e é considerado um fator importante no processo de
definição da arquitetura do framework. Menos da metade das abordagens não
contemplam a definição de um estilo arquitetural e que, segundo Paris (2004), a
sua escolha implica em um aumento de flexibilidade do sistema, sendo assim um
critério importante na definição da arquitetura. Por fim, o Reúso Arquitetural é
contemplado por mais da metade das abordagens possibilitando o reúso de
requisitos, projeto, métodos e de componentes de software.
Após a análise das abordagens, verificou-se que a de Matos e Fernandes
(2008) era a ideal para ser aplicada no desenvolvimento do subframework de
análise sintática e semântica de fórmulas, pois traz o processo detalhado para
sua construção. Além disso, contempla também os benefícios trazidos pelas
outras abordagens, dentre eles, podem-se citar os seguintes, entre outros: estilo
arquitetural, aplicação de padrões de projeto e metapadrões.
4. Aplicação da Abordagem Dirigida por Responsabilidades
O processo de desenvolvimento de frameworks de domínio corresponde a uma
evolução iterativa de sua estrutura de classes, que envolve atividades como
identificação de classes, modelagem de cenários e identificação de estados de
objetos, entre outros.
Uma abordagem que pode ser utilizada para o desenvolvimento de
frameworks é a abordagem PDR-DFD (Processo Dirigido a Responsabilidade
aplicado ao Desenvolvimento de Framework de Domínio). Na PDR-DFD as
responsabilidades são declarações gerais sobre as ações que um objeto executa
e mantém, e sobre as decisões principais produzidas por um objeto que afeta os
outros (MATOS; FERNANDES 2006).
Essas responsabilidades são encontradas a partir das ações que um
sistema deverá executar e nas informações que necessitam ser mantidas ou
criadas (WIRFS-BROCK; MCKEAN, 2003). Além disso, a PDR-DFD foi construída
com o objetivo de dar um contexto adequado de aplicação do método de
identificação antecipada de pontos de estabilidade e de flexibilidade proposto por
Matos e Fernandes (2008).
Para aplicação da abordagem dirigida por responsabilidades,
selecionaram-se métodos no domínio de formação de preço de venda, tais como
os seguintes: ABC (COGAN, 1999; SILVESTRE, 2002), Custo Pleno (MARTINS,
2003) e SEBRAE (SEBRAE, 2008). Esses métodos representam as aplicaçõesexemplo para o desenvolvimento de framework e todos possuem uma fórmula de
preço de venda a ser calculada.
Depois de realizada a análise de cada método descrita em Crazuski et al.
(2008), do subsistema Cálculo do Preço de Venda, e a partir de cada Modelo de
Requisitos e de Classes gerado para cada aplicação-exemplo analisada, pode-se
levantar os subframeworks executando os passos descritos a seguir (MATOS;
FERNANDES, 2006).
4.1. PASSO 1 – Identificar os Frozen e Hot Spots a Partir dos Requisitos dos
Subsistemas
A entrada para esse passo é o Modelo de Requisitos gerado para cada
perspectiva (WIRFS-BROCK; MCKEAN, 2003; CRAZUSKI et al., 2008) de cada
aplicação-exemplo. O modelo de requisitos possui um diagrama de caso de uso
UML, bem como sua descrição textual, separados por perspectiva. Para criar
esse modelo foi necessário realizar um estudo sobre o domínio de cada
aplicação-exemplo. O cálculo do preço de venda de produtos ou serviços deve se
refletir sobre os custos decorrentes da produção do produto e também sobre a
concorrência.
Cada vez mais, os clientes estão pesquisando preços e procurando
qualidade, tanto dos produtos quanto do atendimento. Assim, os preços
calculados através de cada método de formação de preço de venda servirão
como um referencial para a comparação com os preços praticados no mercado
(SEBRAE, 2008).
Durante a análise das aplicações-exemplo, identificaram-se vários
subsistemas, dentre eles todas as aplicações-exemplo possuíam o de Cálculo do
Preço de Venda, que deve realizar o processamento da fórmula do preço de
venda baseando-se no Modelo de Requisitos para cada método. Também se
identificam na análise os frozen e hot spots. O processo de identificação destes
pontos está descrito em (MATOS; FERNANDES, 2008). Logo após a
classificação dos requisitos do framework, constrói-se o diagrama de caso de uso
no formato UML-F (FONTOURA et al., 2000) para o subsistema que estava sendo
analisado, neste caso, para o Cálculo do Preço de Venda ilustrado na Figura 4.
Figura 4. Diagrama de Caso de Uso UML-F do SCF.
Os casos de uso Verificar token e Exponenciar são hot spots e os outros
são frozen spots. O Verificar token foi classificado como hot spot, porque cada
aplicação-exemplo analisada possuía diferentes tipos de token em sua fórmula e
o Exponenciar somente aparecia na aplicação-exemplo ABC. Desta forma, a
abordagem utilizada permite a identificação dos frozen e hot spots em fase inicial
do processo de construção dos subframeworks.
4.2. PASSO 2 – Elaborar o diagrama de classes que satisfaz os requisitos do
framework
A entrada para esta fase é o Modelo de Classes, composto de um conjunto
de classes e seus relacionamentos, de cada aplicação-exemplo e o(s)
diagrama(s) de casos de uso UML-F gerados no Passo 1. Como nos diagramas
de casos de uso UML-F já foram definidos de forma antecipada quais casos de
uso são frozen spots e quais são hot spots, analisa-se neste momento para cada
caso de uso do framework as possíveis classes, a partir do Modelo de Classes de
cada aplicação-exemplo, que venham a atendê-los. Depois se cria o diagrama de
classes para cada requisito, levando-se em consideração os casos de uso
identificados como frozen e hot spots. A integração desses diagramas representa
o Modelo de Classes para o Subsistema que está sendo analisado no momento.
Antes de explicar este passo, ressalta-se que se utilizou o estilo
arquitetural em camadas (BASS et al., 2003), o qual atendeu os requisitos de
flexibilidade, manutenibilidade e reusabilidade, importantes para seu
desenvolvimento. Optou-se por este estilo porque o framework de formação de
preço de venda é um software do tipo cliente-servidor para web implementado na
plataforma J2EE.
Considerando o diagrama UML-F, ilustrado na Figura 4, verifica-se que
possui os seguintes requisitos: Verificar sintaxe, Verificar semântica, Verificar
token que engloba Somar, Subtrair e Exponenciar, entre outros. Esses requisitos
foram satisfeitos pelas seguintes classes do Modelo de Classe das aplicaçõesexemplo: ExpressaoAlgebrica, Variavel, Soma, Subtracao, Multiplicacao, Divisao,
Exponenciacao, entre outras. O processo de identificação foi baseado em Matos e
Fernandes (2008). Por isso, foram reusadas das aplicações-exemplo. Parte do
diagrama de classes para o caso de uso Verificar semântica está ilustrado na
Figura 5. A ExpressaoAlgebrica é uma classe abstrata, a classe que representa a
expressão terminal é a Variavel e as classes Soma, Subtracao, Multiplicacao,
Divisao, Exponenciacao representam as expressões não terminais.
Figura 5. Parte do diagrama de classe para o requisito Verificar Semântica.
Repete-se este processo até que todos os requisitos para o subsistema
analisado possuam seu(s) diagrama(s) de classes. No final desse passo, para
cada requisito analisado tem-se um diagrama de classes correspondente. A
integração desses diagramas representa o Modelo de Classes para o Subsistema
Cálculo do Preço de Venda que é base para o Passo 4.
4.3. PASSO 3 – Identificar os possíveis subframeworks
Como no Passo 1 foram levantados os requisitos do framework, neste
passo identificam-se quais deles podem ser usados em outras aplicações,
verificando os possíveis hot spots que a ele estão associados. Assim, um
subframework pode ser utilizado como possível framework em outro contexto.
Neste trabalho, por exemplo, os requisitos Verificarsemantica e
Verificarsintaxe podem ser utilizados separadamente em outros contextos como
na utilização de compiladores e na validação de linguagem natural,
respectivamente. Por isso, foram considerados como subframework distintos.
4.4. PASSO 4 – Criar o diagrama de classes UML-F para os subframeworks
Considerando que todos os subframework tenham sido identificados no
Passo 3, cria-se um pacote para cada um deles, que deve conter um ou mais
diagramas de classes. No caso do subframework Verificar semântica, obteve-se o
pacote validacaoSemantica ilustrado na Figura 6; no caso do Verificar sintaxe,
obteve-se o subframework ilustrado na Figura 1. Na Figura 6, o pacote
validacaoSemantica é o responsável pelo cálculo das variáveis, o estrutura
contém as estruturas de dados utilizadas para a transformação de uma fórmula
infixa para a pósfixa, além de realizar uma pesquisa no banco de dados e assim
conseguir o valor semântico de cada variável.
Figura 6. SubframeworkVerificarsemântica.
O pacote persistencia possui as classes que realizam a conexão e
manipulação do banco de dados. Por exemplo, ao se utilizar o cálculo do preço de
venda do método do SEBRAE, tem-se o seguinte:
Custo da mercadoria = Valor da Mercadoria + IPI + Frete - Valor de crédito a título
de ICMS no Frete + Substituição Tributária - Valor de crédito a título de ICMS –
Desconto
Inicialmente, executa-se a validação sintática da fórmula e logo após sua
validação semântica. Na semântica, a classe Posfixa utilizando a classe Pilha
transforma a fórmula em pósfixa. Em seguida a classe Arvore, utilizando a classe
Nodo, monta uma árvore semântica e então realiza o acesso ao banco de dados
para a procura dos valores das variáveis. Se alguma destas variáveis não possuir
valor no banco de dados, a fórmula não é semanticamente válida. Em seguida,
realizam-se os cálculos nas classes não terminais para que o resultado seja
fornecido ao usuário. Utilizando os seguintes valores como exemplo:
ValordaMercadoria = 10; IPI = 5; Frete = 1; ValordecreditoatitulodeICMSnoFrete =
0,5; SubstituicaoTributaria = 7; ValordecreditoatitulodeICMS = 8 e Desconto = 0,2.
O resultado fornecido pela execução do componente do subframework é ilustrado
na Figura 7.
Figura 7. Componente de análise semântica – Fórmula de Preço de venda do
método SEBRAE (2008).
Neste passo também se reusam as classes obtidas no Passo 2 que
venham a satisfazer o objetivo do subframework. O diagrama de classes da
Figura 6 deixa explícito quais são classes hot spots para o projetista, pois
apresentam o estereótipo <<Hot spot>>.
4.5. PASSO 5 – Voltar ao passo 1, considerando neste momento um outro
subsistema.
Ressalte-se que os passos descritos acima foram repetidos para todos os
três subsistemas sob análise. Com isso, puderam-se identificar os subframeworks
para o framework no domínio de formação de preço de venda.
5. Breve Análise dos Resultados
O objetivo principal para a criação do subframework proposto foi a necessidade
de criar um sistema que realizasse a Análise Sintática e Semântica de Fórmulas,
sendo executado em ambiente web e desenvolvido em uma linguagem de
programação que permita a portabilidade. O subframework difere tanto do
compilador Lex quanto do Yacc, pois suas rotinas foram desenvolvidas em java,
linguagem que permite a portabilidade e a criação de aplicativos web.
O analisador léxico e sintático foi desenvolvido usando JFlex (versão 1.4.1)
e CUP (versão 0.10j). O JFlex é um gerador de Analisadores Léxicos para Java e
implementado em Java. O seu objetivo é gerar uma rotina em Java, ou seja, uma
classe que contenha as especificações léxicas válidas para a linguagem. Essa
classe é gerada a partir de um arquivo, criado pelo usuário, que contém as
especificações léxicas válidas para a linguagem que se deseja criar. O CUP
(Constructor of Useful Parsers) é um gerador de Analisadores Sintáticos LALR
(LookAhead Left-Right) para Java. O seu objetivo, assim como o JFlex, é gerar
uma rotina em Java a partir de um arquivo que contenha a gramática para o qual
o analisador sintático será utilizado.
O subframework proposto também difere de alguns softwares tais como:
Axiom, Yacas, Maxima, Eigenmath, entre outros, pois além de ser um aplicativo
para web, aperfeiçoa a interpretação das mensagens retornadas ao usuário. Isso
foi um requisito considerado importante na criação do subframework, pois os
aplicativos analisados apresentam mensagens incompletas, dificultando a sua
interpretação e posterior correção por parte do usuário. Além disso, os aplicativos
não podem ser reusados em uma nova aplicação que necessita de análise
sintática, pois são ferramentas específicas. Outro ponto a ser levado em
consideração é que ao usar o subframework em outro contexto as classes com
frozen e hot spots já estão identificados, facilitando o trabalho do desenvolvedor
ao reusá-lo.
Para o analisador semântico, utilizou-se como referência o padrão de
projeto Interpreter. A aplicabilidade do padrão é definida quando a gramática a ser
interpretada é simples, como é o caso do analisador semântico. A estrutura do
padrão Interpreter está baseada em uma classe com a expressão abstrata e a
partir dela a geração de classes de expressões terminais como é o caso da classe
Variavel e de expressões não terminas como o caso da classe Soma ambas
vistas na Figura 6.
Este subframework difere aos outros geradores de parse que possuem
validação semântica como o JavaCC (Java Compiler-Compiler), pois está
interligado a um banco de dados, deixando a semântica dinâmica, uma vez que
uma variável poderá ter um significado diferente dependendo do contexto, além
de ser um aplicativo web.
Escolheu-se criar um framework, pois cada usuário possui um contexto
diferente, e com a utilização de frameworks pode-se utilizar somente a parte que
mais lhe interessa além de poder realizar modificações para melhor adaptação do
subframework ao seu contexto.
Para a realização deste experimento foi necessário realizar uma pesquisa
na literatura sobre frameworks e como identificar, analisar e desenvolver os
requisitos de um framework. Após a pesquisa, determinou-se que a melhor
abordagem é a descrita por Matos e Fernandes (2006), pois propõe um modo de
se identificar e de se criar os subframeworks a partir da análise do diagrama UMLF e da identificação dos hot spots a eles associados. Após esse refinamento,
selecionam-se as classes do subsistema que atendem sua finalidade, facilitando
desta forma em fases posteriores à identificação detalhada de colaboração entre
eles. Aborda também as vantagens do desenvolvimento em paralelo de
aplicações, escolha de um estilo arquitetural, e demais vantagens oferecidas
pelos trabalhos dos autores estudados.
O reúso é dado por meio do Modelo de Requisitos e de Classes de cada
aplicação-exemplo, que haviam sido gerados na subfase anterior, proposta pela
abordagem baseada em responsabilidades (MATOS; FERNANDES, 2006), para
criar o Modelo de Classes do Subsistema Cálculo do Preço de Venda. Para a
criação do subframework, reusam-se as classes do Modelo de Classes de cada
aplicação-exemplo.
Além do reúso de artefatos gerados durante a análise, esta abordagem
permitiu o reúso arquitetural através dos subframeworks que podem ser reusados
como frameworks em outras aplicações. Por isso, para aplicação da abordagem
tanto o Modelo de Requisitos, com diagramas de casos de uso na forma gráfica e
textual, e o Modelo de Classes, com diagramas de classes, de cada subsistema
de cada aplicação-exemplo já devem estar prontas antes. Saliente-se, nesse
sentido, que cada pessoa ou grupo poderá realizar a análise de subsistemas
diferentes.
A maneira de determinar os subframeworks, que constituíram a arquitetura
do framework, mostrada neste trabalho é realizada analisando os requisitos do
framework. A partir destes e da estrutura de classes criada para o subsistema,
Cálculo do Preço de Venda, procura-se determinar quais são as classes que irão
satisfazê-lo. Primeiramente foi desenvolvido o analisador sintático de fórmulas
descrito por Hornung et al. (2008). E então, criou-se o avaliador semântico de
fórmulas, onde se optou por estudar e utilizar um padrão de projeto e, neste caso,
utilizou-se o Interpreter para o desenvolvimento. Após isso foi feita a unificação
dos dois subframeworks, para que eles possam ser utilizados juntos.
6. Conclusões
Neste trabalho apresentou-se a utilização da abordagem dirigida por
responsabilidades durante a criação do subframework de análise sintática e
semântica de fórmulas matemáticas a partir dos casos de uso definidos como hot
spots e obtidos na etapa de análise do processo de desenvolvimento de
framework.
Como resultado do processo proposto, criou-se um subframework que
pode ser utilizado em outra aplicação, pois suas classes frozen e hot spots já
estão identificadas. Contudo, alguns testes no subframework estão sendo feitos
para identificar sua aplicação em outros domínios.
7. Referências
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice,
Addison Wesley, 2003.
BRAGA, R. T. V.; Masiero, P. C. A Process for Framework Construction Based
on a Pattern Language. In: Annual International CSAC, 26., 2002. Oxford:
IEEE, 2002. p. 615-620.
BROWN, A. W.; WALLNAU, C. The Current State of CBSE, IEEE Software, vol.
155, sept-oct, p. 37-38, 1998.
BUTLER, G.; XU, L. Cascaded Refactoring for Framework Evolution, In: Proc.
SSR’01, May, Toronto, Ontario, Canada. ACM 1-58113-358-8/01/0005, p. 5157, 2001.
CRAZUSKI, A.; FEITOSA, L. B.; CORDEIRO, T, L. Identificação dos pontos de
estabilidade e de flexibilidade dos métodos para o estabelecimento de
preço de venda. 135f. 2008. Trabalho de Conclusão de Curso – Universidade
Tecnológica Federal do Paraná, Ponta Grossa.
COGAN, S. Custos e preços: formação e análise. São Paulo: Pioneira, 1999.
FAYAD, M.; SCHMIDT, D.; JOHNSON, R. Building Application Frameworks –
Object-Oriented Foundations of Framework Design, Wiley, p.688, 1999.
FONTOURA, M.; PREE, W.; RUMPE, B. UML-F:A modeling language for
object-oriented frameworks, In ECOOP. LNCS, 1850.Springer-Verlag, 63-82,
2000.
HORNUNG, R.; MATOS, S. N.; FERNANDES, C. T. Aplicando o processo
dirigido por responsabilidades para a criação de um subframework para
validação de sintática de fórmulas. In: 5nd CONTECSI, 5., 2005, São Paulo.
FEA/USP, 2008.
JOHNSON, R. E. How to design frameworks, In: Object-Oriented Programming
Systems, Languages and Applications Conference – OOPSLA, Washington
Proceedings, 1993.
KIRK, D.; ROPER, M.; WOOD, M. Identifying and Addressing Problems in
Framework Reuse, In: Proceedings of the 13th IWPC´05, 2005.
LAND, R. How can frameworks facilitate component reuse?, Extended Report
for I. Crnkovic and M. Larsson (editors), “Building Reliable Component-Based
Systems”, Artech House, 2002.
LANDIN, N.; NIKLASSON, A., Development of Object-Oriented Frameworks,
Department of Communication System.Lund Institute of Technology, Lund
University. Lund, Sweden, 1995.
MARTINS, E. Contabilidade de Custo. 6ª ed., São Paulo: Atlas, 2003. p.220.
MATOS, S. N.; FERNANDES, C. T. Using Responsibilities for Early
Identification of Hot Spot Reused in Framework Modeling. In: IEEE
International Workshop on Security, Trust, and Privacy for Software
Applications. 3. Turku: IEEE Computer Society Press, 2008.
MATOS, S. N.; FERNANDES, C. T. Defining the architectural design of
frameworks through a group of subframeworks created from frozen and
hot spots. In: International Conference on Software Engineering Advances,
2006, Tahiti: IEEE Computer Society Press, 2006.
MATTSSON, M. Evolution and composition of object-oriented frameworks.
224f. 2000. PhD Thesis– University of Karlskrona/Ronneby, Sweden.
PARIS, M. Reuse-based Layering: a Strategy for Architectural Framework for
Learning Technologies, In: IEEE Conferece on Advanced Learning
Technologies (ICALT’04), 2004.
PREE, W. Hot-spot-driven development. In: FAYAD, M.; JOHNSON, R.;
SCHMIDT, D. Building application frameworks: object-oriented
foundations of framework design. NY: John Wiley and Sons, 1999. p. 379393.
SEBRAE.
Cálculo
do
preço
de
venda.
<http://www.sebraepr.com.br>. Acesso: 11 nov de 2008.
Disponível
em
SILVESTRE, W. C. Sistema de custos ABC: uma visão avançada para
tecnologia de informação e avaliação de desempenho. São Paulo: Atlas,
2002.
TALIGENT, Building object-oriented frameworks, Taligent Inc.white paper,
1994.
TANG, A.; HAN, J.; Chen, P. A Comparative Analysis of Architecture
Frameworks, In: Proceedings of the 11th Asia-Pacific Software Engineering
Conference (APSEC´04), 2004.
VILJAMAA, J. Reverse Engineering Framework Reuse Interfaces, In
Proceeding: ESEC/FSE’03, September 1-5, Helsinki, Finland, 2003.
WIRFS-BROCK, R.; MCKEAN, A. Object Design: Roles, Responsabilities, and
Collaborations, Addison Wesley, 2003.