universidade estadual do norte fluminense darcy … · 2017-09-19 · testes automatizados na...
TRANSCRIPT
UNIVERSIDADE ESTADUAL DO NORTE FLUMINENSE DARCY RIBEIRO
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
GABRIEL LIMA DE OLIVEIRA
Testes automatizados na verificação de requisitos de workflows em Sistemas
Integrados de Gestão
CAMPOS DOS GOYTACAZES
2012
GABRIEL LIMA DE OLIVEIRA
Testes automatizados na verificação de requisitos de workflows em Sistemas Integrados de
Gestão
Monografia apresentada junto ao Curso de Ciência
da Computação, da Universidade Estadual do
Norte Fluminense Darcy Ribeiro – Campos / RJ,
como requisito para obtenção do título de Bacharel
em Ciência da Computação.
Orientadora: Prof.ª Dr.ª Annabell Del Real Tamariz
Co-Orientador: Prof. Dr. Rogério Atem de
Carvalho
CAMPOS DOS GOYTACAZES
2012
GABRIEL LIMA DE OLIVEIRA
Testes automatizados na verificação de requisitos de workflows em Sistemas Integrados de
Gestão Empresarial
Monografia apresentada junto ao Curso de Ciência
da Computação, da Universidade Estadual do
Norte Fluminense Darcy Ribeiro – Campos / RJ,
como requisito para obtenção do título de Bacharel
em Ciência da Computação.
Orientadora: Prof.ª Dr.ª Annabell Del Real Tamariz
Co-Orientador: Prof. Dr. Rogério Atem de
Carvalho
Aprovado em 21/03/2012
COMISSÃO EXAMINADORA
_________________________________________________________
Prof.ª Dr.ª Annabell Del Real Tamariz
Orientadora – UENF
_________________________________________________________
Prof. Dr. Rogério Atem de Carvalho
Co-orientador – IFF-Campos
__________________________________________________________
Prof. Dr. Ausberto Silverio Castro Vera
UENF
DEDICATÓRIA
Dedico este trabalho a todos que, por algum motivo direto ou indireto, me fortaleceram, me
ajudaram, me orientaram ou mesmo não me deixaram descansar. Primeiramente a minha família.
Ao meu pai, que tanto me aconselhou, e não me permitiu sequer pensar em desistir. A minha mãe,
equilibrando meus pilares e suportando o stress resultante do esforço no estudo e no trabalho. A
minhas irmãs, aguentando meu despertador em plenas madrugadas e a distância causada pela minha
dedicação. A Muriel, minha namorada, que se manteve sempre companheira, me apoiando em todos
os momentos, e me ajudando muito mais do que devia, suportando minha ausência física. Aos meus
fiéis amigos, praticamente irmãos, me descontraindo e ao mesmo tempo impulsionando-me para
conquistas ainda maiores, e que nunca, nunca me deixaram desistir ou mesmo estagnar em busca
dos meus objetivos.
AGRADECIMENTOS
Aos mestres que tão solicitamente auxiliaram-me no decorrer da elaboração deste Trabalho
de Conclusão de Curso. A minha família, namorada e amigos que me apoiaram com todo o
conhecimento e estímulo para sempre buscar mais.
“Se você realmente deseja algo, você saberá como torná-lo realidade.”
Cher
RESUMO
O objetivo deste trabalho é utilizar um modelo de verificação de requisitos num Sistema Integrado
de Gestão, que visa unir testes automatizados de software à atual linguagem comum de modelagem
empresarial: os modelos de processos de negócio, os quais são instanciados em processos reais
através das máquinas de workflow. Neste estudo de caso será empregado o ERP5, cuja execução
pode ser acompanhada por especialistas de negócio através dos próprios processos. Mais
especificamente, o foco está na implementação de cada requisito definido pelos especialistas de
negócio. Buscou-se estabelecer uma relação entre as funcionalidades descritas pelo usuário e os
testes construídos durante a implementação do requisito. Foi desenvolvido um Módulo de
Funcionalidades, tornando possível a adição de funcionalidades e cenários no ERP5, bem como a
execução desses cenários. Foi implementado um mecanismo para interceptação dos testes
automatizados a fim de correlacioná-los aos cenários descritos, que utilizassem o mesmo workflow.
Por fim, foi agregada à execução dos cenários a capacidade de exibir quais testes utilizaram o
mesmo workflow manipulado pelo cenário. Como contribuição, esse trabalho demonstra como a
descrição e validação dos requisitos pode ser realizada pelos especialistas de negócio.
PALAVRAS-CHAVE: ERP, Testes Automatizados de Software, Workflow, Business Language
Driven Development
ABSTRACT
The goal of this work is to provide a method to verify ERP requirements, aiming to unite automated
testing to the current common language of business modeling: business processes models, which are
instantiated in actual processes through workflow engines, in other words, whose execution may be
accompanied by business experts. Following this scenario, a case study on top of ERP5 – an open
source ERP system, is conducted. The implementation here described provides the connection of
the features described by the user with tests built during the implementation of the requirement. For
doing so, it was developed the Feature Module, making it possible to add features and scenarios to
ERP5, as well as execute this scenarios. Moreover, it was implemented a mechanism for
intercepting the automated tests in order to correlate them to the scenarios described. Finally, it was
added to the execution of the scenarios the ability to view what tests used the same workflow
handled by the scenario. As contribution, this work shows how the description and validation of
requirements can be made by business experts.
KEYWORDS: ERP, Automated Testing Software, Workflow, Business Language Driven
Development
SUMÁRIO
1. INTRODUÇÃO ............................................................................................................... 13
1.1. OBJETIVOS ................................................................................................................... 14
1.1.1. OBJETIVO GERAL .............................................................................................. 14
1.1.2. OBJETIVOS ESPECÍFICOS ................................................................................ 14
1.2. JUSTIFICATIVA E CONSIDERAÇÕES...................................................................... 15
2. FUNDAMENTAÇÃO TEÓRICA ................................................................................. 17
2.1. SISTEMA INTEGRADO DE GESTÃO ........................................................................ 17
2.2. MÁQUINA DE ESTADOS FINITA ............................................................................. 20
2.3. DIAGRAMAS DE ESTADO ......................................................................................... 21
2.4. FLUXO DE TRABALHO .............................................................................................. 22
2.4.1. FLUXOS DE TRABALHO EM SIGs ................................................................... 22
2.5. METODOLOGIAS PARA VERIFICAÇÃO DE SISTEMAS ...................................... 24
2.5.1. TESTES MANUAIS ............................................................................................. 25
2.5.2. TESTES AUTOMATIZADOS ............................................................................. 26
2.5.3. DESENVOLVIMENTO GUIADO POR COMPORTAMENTO ......................... 27
2.5.4. DESENVOLVIMENTO GUIADO POR LINGUAGEM DE NEGÓCIO ............ 30
3. DEFINIÇÃO E ESTRUTURAÇÃO DO ERP5 ........................................................... 31
3.1. ESTRUTURA DOS FLUXOS DE TRABALHO .......................................................... 33
4. MECANISMO PARA VERIFICAÇÃO DE WORKFLOWS NO SIG ....................... 38
4.1. ANÁLISE DE WORKFLOWS EM TESTES AUTOMATIZADOS DO ERP5 ........... 38
4.1.1. TESTES AUTOMATIZADOS NO ZOPE ............................................................ 40
4.1.2. MÉTODOS PARA INTERCEPTAÇÃO DE TRANSIÇÕES .............................. 44
4.1.2.1. INTERCEPTAÇÃO DO DCWORKFLOW COM UMA FUNÇÃO .................... 44
4.1.2.2. INTERCEPTAÇÃO DO DCWORKFLOW COM UMA CLASSE ..................... 45
4.1.2.3. INTERCEPTAÇÃO DO DCWORKFLOW NA INSTALAÇÃO DO PORTAL . 48
4.2. MÓDULO DE ESPECIFICAÇÃO DE REQUISITOS .................................................. 52
5. CONCLUSÕES ............................................................................................................... 61
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 63
LISTA DE FIGURAS
Figura 1: Exemplos de módulos que podem ser integrados a um SIG .............................................. 18
Figura 2: Exemplo de extensão de um SIG com adição de novos módulos ...................................... 19
Figura 3: Transição básica de estado .................................................................................................. 21
Figura 4: Diagrama de estado de um caixa eletrônico ....................................................................... 21
Figura 5: Exemplo de fluxo de estados do workflow de uma falha ................................................... 23
Figura 6: Ilustração de usuários interagindo num mesmo documento ............................................... 24
Figura 7: Modelo Cascata .................................................................................................................. 25
Figura 8: Exemplo de funcionalidade descrita textualmente ............................................................. 29
Figura 9: Bases e módulos no ERP5 .................................................................................................. 33
Figura 10: Workflow “acknowledgement_workflow” do EPR5 ......................................................... 34
Figura 11: Sale Opportunity Workflow .............................................................................................. 36
Figura 12: Cabeçalho e parte da definição do método _executeTransition ....................................... 39
Figura 13: Processo de execução de um teste no ERP5 ..................................................................... 41
Figura 14: Teste "test_SaleOpportunitySold" .................................................................................... 42
Figura 15: Métodos de interceptação dos testes do módulo CRM .................................................... 43
Figura 16: Primeira abordagem para interceptar o portal_workflow ................................................. 45
Figura 17: Segunda abordagem para interceptar o portal_workflow ................................................. 46
Figura 18: Terceira abordagem para interceptação do portal_workflow ........................................... 47
Figura 19: Sobrescrita do portal_workflow na configuração do portal ............................................. 48
Figura 20: Implementação do patch para o portal_workflow ............................................................ 49
Figura 21: Exemplo de análise com sucesso do teste “test_SaleOpportunitySold” ........................... 50
Figura 22: Exemplo de análise com falha do teste “test_SaleOpportunitySold” ............................... 51
Figura 23: Funcionalidade e um possível cenário do documento Oportunidade de Venda ............... 52
Figura 24: Ação para criar nova Funcionalidade ............................................................................... 53
Figura 25: Ação para criar novo Cenário ........................................................................................... 53
Figura 26: Descrição do Cenário ....................................................................................................... 54
Figura 27: Exemplo de uma Funcionalidade completamente descrita .............................................. 55
Figura 28 : Fluxo de estados e transições do cenário Oportunidade de Venda é vendida.................. 56
Figura 29: Descrição do cenário Oportunidade de Venda é submetida ............................................. 57
Figura 30: Ação “Executar passos” do cenário .................................................................................. 57
Figura 31: Parte da implementação do método executeSteps ............................................................ 58
Figura 32: Expressões regulares para identificar passos num cenário ............................................... 59
Figura 33: Resultado da execução dos passos do cenário “Oportunidade de Venda é submetida” ... 59
LISTA DE TABELAS
Tabela 1: Exemplos de ferramentas BDD por linguagem .................................................................. 29
Tabela 2: Estados e transições possíveis do workflow ilustrado na Figura 10 ................................... 34
Tabela 3: Transições e os respectivos papéis de usuário requeridos .................................................. 36
13
1. INTRODUÇÃO
A constante flexibilização das empresas, apresentando a necessidade de integrar as
informações e diminuir ou mesmo eliminar o fluxo de papel, tem ressaltado cada vez mais a
importância da tecnologia de automação dos fluxos de trabalho (workflows), que permite a
substituição dos documentos em papel por formulários eletrônicos que percorrem a empresa por
meio de uma infra-estrutura organizacional de comunicação (FERNANDES JUNIOR, 2003)
caracterizada por fluxos de informação no sistema.
Uma das soluções para integrar toda essa infra-estrutura organizacional num único sistema
de informação é a utilização de um Sistema Integrado de Gestão, SIG (ERP, “Enterprise Resource
Planning”), permitindo assim a união dos diversos departamentos da empresa, possibilitando a
automação e armazenamento de todas as informações de negócios.
Estas informações percorrem o sistema através dos fluxos de informação. Para Barreto
(2002), um fluxo pode ser definido como uma transferência de informação, onde um ou mais
emissores transmitem informação para um ou mais receptores. No âmbito dos SIGs, essa
informação pode representar desde um simples relatório de compras até um planejamento anual
derivado do trabalho de vários segmentos no intuito de atingir um mesmo objetivo dentro da
organização.
O fluxo de informação de cada processo organizacional pode ser representado numa notação
gráfica por meio da Notação de Modelagem de Processos de Negócios (BPMN, “Business Process
Modeling Notation”), fazendo uso de uma série de artefatos padrão, tendo como resultado os
Diagramas de Processos de Negócios (BPD, “Business Process Diagram”), que são baseados numa
técnica de fluxograma semelhante à de Diagramas de Atividades da Unified Modeling Language
(UML).
Outra representação desse fluxo se encontra no Diagrama de Estados, onde são definidos
14
possíveis estados e transições de um documento, constituindo um diagrama que represente todos os
comportamentos possíveis. Além disso, define-se também o ciclo de vida do documento, e como o
mesmo deve responder aos eventos que ocorrerem.
Em se tratando de sistemas informatizados, uma das principais preocupações quanto ao seu
desenvolvimento está na correta implementação de cada requisito identificado pelo usuário. É
necessária atenção na implantação de workflows, para que todas as regras de estados e transições
sejam codificadas corretamente. Kannenberg e Saiedian (2009) afirmam que nem os métodos
manuais de rastreamento de requisitos, nem as ferramentas prontas existentes, são adequadas para
as necessidades atuais da indústria de engenharia de software, pois ainda não foi definida uma
forma de rastreamento confiável.
A implementação destes requisitos é verificada através de testes automatizados que são
construídos ao longo do desenvolvimento e facilitam para o desenvolvedor identificar possíveis
falhas. Seguindo esta metodologia, tem-se o ERP5, um SIG livre e de código aberto, que se utiliza
de testes automatizados para verificar sua implementação. Porém, não há um modo de identificar
quais testes estão verificando quais fluxos de trabalho. Também não existe no sistema um modo de
correlacionar os requisitos dos especialistas de negócio com os testes existentes no sistema.
Assim, faz-se necessário o desenvolvimento de uma ferramenta que possibilite um sistema
informatizado baseado no ERP5 ser validado quanto à correta implementação de seus requisitos de
fluxo de trabalho.
1.1. OBJETIVOS
1.1.1. OBJETIVO GERAL
O objetivo deste trabalho é demonstrar ao usuário que os workflows que correspondem ao
requisito descrito foram implementados no sistema, e que existem testes automatizados para cada
workflow abordado pelo requisito. Para tanto, será usado como estudo de caso o SIG livre ERP5.
1.1.2. OBJETIVOS ESPECÍFICOS
Para atingir o objetivo geral, os seguintes objetivos específicos serão abordados:
1. Utilizar como estudo de caso um workflow real do SIG denominado ERP5, no caso
15
que faz parte do módulo de Gestão de Relacionamento com Clientes (CRM,
Customer Relationship Management), e que possua testes que validem sua
implementação.
2. Interceptar a máquina de estados utilizada pelo ERP5 para implementar seus
workflows, durante a execução de testes unitários
3. Identificar, para cada teste executado, quais transições são acionadas, e salvá-las para
posterior utilização
4. Construir um módulo no ERP5 capaz de gerenciar as funcionalidades descritas
textualmente pelo usuário
5. Transformar as funcionalidades descritas em testes, encontrando e recuperando as
transições salvas que se relacionem com o teste descrito
1.2. JUSTIFICATIVA E CONSIDERAÇÕES
Os conceitos modernos de gestão corporativa iniciaram no fim da década de 50,
caracterizada como década de finalização do período de guerras e o início das revoluções
tecnológicas, porém apenas na década de 80 houve a revolução nas atividades de gerenciamento de
produção e logística, onde o principal marco foi a transição do Planejamento das Requisições de
Materiais (MRP, Material Requirement Planning) para o Planejamento dos Recursos de Manufatura
(MRP II, Manufacturing Resource Planning), agora também controlando outras atividades como
mão de obra e maquinário, e não apenas os materiais estritamente necessários para produção.
Como uma ferramenta de gerenciamento e controle dos processos da empresa, o MRP II já
poderia ser utilizado como um ERP propriamente dito, mas esta definição não foi dada no momento
do surgimento do MRP II. A década de 80 serviu para integrar melhor os departamentos da
organização, trazendo maior comunicação e harmonia entre os mesmos. Esta comunicação gerou a
necessidade de integrar ao ERP novos módulos de gestão para os departamentos que passaram a se
comunicar com os outros já integrantes do sistema. Setores como Finanças, Compras e Vendas
passaram a fazer parte do sistema, ou seja, houve a integração de módulos com atuação
administrativa, gerencial, que passaram a fazer parte da era da automação.
Porém, só na década de 90 a nomenclatura ERP se realçaria, podendo ser citado como uma
das razões a evolução das redes de comunicação entre computadores, a disseminação da arquitetura
cliente/servidor com preços mais competitivos, e a constante adição de “módulos” ao sistema, que
16
possibilitavam uma abrangência crescente dos setores mais diversos da organização.
Segundo Carvalho (2008), uma das mudanças mais relevantes com a implantação de um
Sistema Integrado de Gestão (SIG, ou da sigla em inglês ERP) numa corporação é a maior
confiabilidade dos dados, agora monitorados em tempo real, e a diminuição do retrabalho. Essa
diminuição só é possível de ser atingida com o comprometimento dos funcionários responsáveis por
atualizar os dados que alimentam toda a cadeia de módulos do SIG, possibilitando que a empresa
possa interagir com seus processos organizacionais. Já o aumento da confiabilidade, somente é
possível com a gestão por parte do sistema dos fluxos de informação que transitam no mesmo, e das
atividades que são executadas.
Ainda segundo Carvalho (op. cit.), os sistemas de workflow apareceram para solucionar o
principal problema dos sistemas baseados em processos organizacionais: possibilitar o controle das
atividades que estão sendo executadas, gerenciando quem e quando determinada informação pode
ser ou foi manipulada.
Nesse sentido, torna-se necessário verificar que todas as informações seguem os processos
de execução previamente definidos pelo usuário, sem possibilidade de falha com relação ao
workflow seguido pelo documento, bem como checar que a segurança da informação é
implementada corretamente.
Neste trabalho será apresentada uma ferramenta desenvolvida com o intuito de facilitar a
validação de Sistemas Integrados de Gestão, bem como o material teórico necessário para
compreender a metodologia usada para desenvolvê-la.
A estrutura do trabalho é composta de uma breve introdução, apresentando o estado da arte
atual, contextualizando o problema de validação de requisitos, e definindo o objetivo do trabalho.
No capítulo seguinte é apresentada a fundamentação teórica dos tópicos abordados durante o
desenvolvimento da ferramenta.
Em sequência é apresentada a ferramenta desenvolvida, como pode ser utilizada, como
funciona internamente, e os resultados obtidos com a utilização da mesma.
Por último são apresentadas as conclusões obtidas com o trabalho.
17
2. FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão apresentados fundamentos necessários para o entendimento e discussão
da proposta deste trabalho. Dentre eles, podem ser citados: a) a estrutura de um Sistema Integrado
de Gestão; b) como os documentos fluem pelo sistema; c) como é estruturado o fluxo de trabalho
dos documentos; d) metodologias para validação de sistemas.
2.1. SISTEMA INTEGRADO DE GESTÃO
Um Sistema Integrado de Gestão (SIG) é um software que visa integrar os dados e processos
de uma organização. Dada a dificuldade para atingir esse objetivo, os fabricantes de SIG oferecem
diferentes versões para diferentes segmentos de mercado, como para o segmento mecânico,
automotivo, de óleo e gás, e governamental.
Geralmente, um SIG é desenvolvido como um software modular que integra e automatiza os
processos de negócio, isto é, espelhando as operações existentes na organização. Os módulos mais
comuns são o Financeiro, Planejamento da Produção, Marketing, Pesquisa e Desenvolvimento,
Vendas e Contabilidade. Estes módulos representam, portanto, os setores da organização, e têm
como característica a facilidade de configuração e flexibilidade, visando proporcionar adequação de
seus processos para as organizações e suas próprias necessidades. Por tanto, os sistemas de SIG
precisam desenvolver-se junto com a organização. Por sua estrutura modular, pode-se ilustrar o SIG
como na Figura 1, onde o mesmo tem um núcleo que se integra com todos os módulos existentes no
sistema.
18
Figura 1: Exemplos de módulos que podem ser integrados a um SIG
Essa integração caracterizaria, por exemplo, a interação interdepartamental dos vários
processos da empresa. Em outras palavras, os setores trabalham em conjunto a fim de encontrar a
melhor solução para o lançamento de novos produtos, por exemplo, e as informações relativas a
estes produtos encontram-se presentes no SIG. Assim, os departamentos poderiam acompanham o
estado dos processos.
Sem um sistema de informações gerenciais o fluxo do processo ocorre pela colaboração das
pessoas, na troca de materiais e informações. Ao adotar um SIG, o fluxo passa a ser automatizado,
coordenado pelo próprio sistema, que dispara operações, colhendo informações e disponibilizando-
as à jusante1.
Segundo Nunes, Quintella e Telles (2006), entre as mudanças mais importantes que um
sistema SIG propicia para uma empresa, destacam-se a maior confiabilidade dos dados e a
diminuição do re-trabalho2 e o monitoramento e controle do fluxo de dados e processos. Por
exemplo, uma ordem de compra disparada pelo módulo que representa o setor logístico modifica no
mesmo instante os relatórios do módulo que representa o setor Financeiro. Porém, essas vantagens
só são alcançadas se houver real integração de dados e processos. Ainda segundo os autores:
1 Jusante: Baixa-mar, para onde correm as águas dos rios. Sentido contínuo. Seguindo o fluxo.
2 Re-trabalho: Recuperação de objeto de trabalho que contém inadequação, ou apresenta inconformidade.
19
“Ao desfazer a complexidade do acompanhamento de todo o processo de produção, venda e
faturamento, a empresa tem mais subsídios para planejar-se, diminuir gastos e repensar a
cadeia de produção. Um bom exemplo de como o ERP revoluciona uma empresa é que com
uma melhor administração da produção e investimento, como uma nova infra-estrutura
logística, pode ser repensado ou simplesmente abandonado. Ao controlar e entender melhor
todas as etapas que levam a um produto final, a empresa pode chegar a ponto de produzir de
forma mais inteligente, rápida e melhor, o que, em outras palavras, reduz o tempo que o
produto fica parado no estoque.”
Outro aspecto importante é a extensibilidade do SIG, isto é, sua capacidade em adquirir
novas funcionalidades, aspecto trazido pela modularização. A Figura 2 ilustra a extensão de um SIG
já existente através da junção de novos módulos, aqui definidos como Frota e Análise de riscos,
respectivamente.
Figura 2: Exemplo de extensão de um SIG com adição de novos módulos
Também há melhoria na tomada de decisões. Por exemplo, caso alguma etapa do processo
produtivo precise ser alterada, por requisição do cliente ou mudança de normas, todos os setores
envolvidos no processo são automaticamente informados, possibilitando sinergia nas atitudes e
decisões necessárias. Estes sistemas são responsáveis por estas mudanças, pela aquisição de novas
técnicas disponíveis no SIG e pelo aumento no desempenho dos processos.
Com o SIG, os gastos que antes eram empenhados no controle do complexo processo de
produção, venda e faturamentos podem ser redirecionados para melhoria da própria empresa,
tornando-se investimentos.
Sendo um projeto extenso, que demanda a integração total do software na organização e uma
20
estrutura específica, o SIG gera custos relevantes (SOUZA, 2000). Todavia, a sua implantação
provoca modificações importantes nos hábitos de trabalho da maioria dos funcionários. Sendo
assim, costuma-se considerar que apenas 20% do custo total de instalação do sistema dizem respeito
à sua codificação propriamente dita. Com isso, faz-se necessário ter o máximo de confiança na
correta implementação do sistema, pois como já dito, os erros internos do mesmo podem gerar
custos incalculáveis à organização.
2.2. MÁQUINA DE ESTADOS FINITA
Para melhor entender o que são os estados e transições de um documento em um SIG, faz-se
necessário compreender o que é uma Máquina de Estados Finita (FSM - Finite State Machine).
FSM é um modelo de controle usado para representar comportamentos esperados em um sistema, e
que deve descrever todos os estados possíveis para um documento.
Segundo Wagner et al. (2006), a FSM introduz o conceito de estado como uma informação
sobre o histórico passado. Todos os estados representam as situações possíveis que uma máquina de
estados pode assumir em um dado momento. Além disso, há uma memória: como a máquina de
estados chegou a presente situação. Durante a execução da aplicação, os estados são alterados, e as
saídas do sistema passam a depender não só das entradas, mas também do estado atual do mesmo.
A mudança de um estado anterior para um estado posterior é designada transição. Ainda,
como o número de situações distintas para uma dada máquina de estados é finito, o número de
estados também é finito. Por isso o termo “finita”.
Os fluxos de trabalho, que definem possíveis estados e transições de um documento no SIG,
são modelados através de uma FSM. Além disso, geralmente possuem regras atribuídas a cada ação,
limitando o controle da atividade ou mesmo o acesso ao conteúdo para determinados usuários.
Ainda segundo Wagner et al. (op. cit.), conceitualmente, na modelagem de uma FSM,
existem dois estados, aqui definidos como inicial e de aceitação (ou final). O estado inicial define o
estado do objeto assim que o mesmo é criado. Estados de aceitação são aqueles estados alcançáveis
a partir do estado atual, através de uma transição. Um estado descreve um nó de comportamento do
sistema que está à espera de uma condição para executar uma transição. Essa transição geralmente
ocorre através de uma ação manual, contudo pode também acontecer automaticamente, baseando-se
em condições para tal. Ainda, há diversos modos de descrever os modelos de uma máquina de
estados. Devido aos workflows utilizados pelos SIG serem geralmente descritos através de
21
Diagramas de Estado, apenas estes serão utilizados e explicados no trabalho.
2.3. DIAGRAMAS DE ESTADO
Num diagrama de estados, os estados são representados por círculos e as transições por
arcos direcionados. Transições podem apresentar condições para transição, e estas são escritas ao
longo do arco no diagrama. A Figura 3 ilustra um caso simples de diagrama de estados, onde se
pode visualizar uma transição do estado 1 (anterior) para o estado 2 (posterior), enquanto que a
Figura 4 ilustra um caso mais complexo, relacionado ao caixa eletrônico de um banco.
Figura 3: Transição básica de estado
Figura 4: Diagrama de estado de um caixa eletrônico
22
Neste exemplo, os estados foram propositalmente ilustrados por retângulos, pois esta será a
forma adotada ao longo do trabalho para denotá-los. Existem vários estados possíveis (INATIVO,
AGUARDANDO CARTÃO, AGUARDANDO SENHA, etc.) e as respectivas transições para
atingir os estados (“Inserir senha”, “Exibir saldo”, etc.). O estado INATIVO é o estado inicial, e é
apresentado com um ponto ou uma seta “apontando para ele a partir de qualquer lugar”. A partir
dele, apenas o estado AGUARDANDO CARTÃO é alcançável, a partir da transição “Acessar
sistema”. Porém, todos os outros estados alcançam o estado INATIVO: AGUARDANDO
CARTÃO, AGUARDANDO SENHA, AGUARDANDO ESCOLHA, SALDO e SAQUE.
2.4. FLUXO DE TRABALHO
Caracteriza-se como fluxo de trabalho, ou workflow, o conjunto de interações que devem
ocorrer para se completar determinada tarefa. Os workflows são geralmente utilizados durante a
automação de processos de negócio, com intuito de descrever suas etapas. Um processo de negócio
é uma atividade organizada, parte integrante da estrutura de uma organização, que possui como
objetivo produzir valor para os clientes.
2.4.1. FLUXOS DE TRABALHO EM SIGs
Nos SIGs, existe a necessidade de uma política para a manipulação dos dados inseridos no
sistema, relativos à permissão de visualização e escrita, compartilhamento e acesso aos relatórios
gerados. Fica claro que apenas a descrição em diagramas de estado não supre tal necessidade,
tornando-se necessário um componente que gerencie tais regras, bem como os possíveis estados das
informações contidas no sistema. Para Cardoso, Bostrom e Sheth (2004), essa necessidade é
resolvida com a utilização dos workflows.
Como exemplo, é apresentada na Figura 5 a definição de um workflow utilizado para
correção de falhas de um SIG. Neste sistema existe um módulo que cuida de gerenciar as falhas
encontradas no próprio sistema. Na figura apresentada, observa-se que o estado inicial de uma falha
quando criada é “nova”. Como exemplo de utilização desse workflow, após a criação de uma nova
falha, um desenvolvedor pode acionar a ação de “aceitar”, o que implica na mudança para o estado
“atribuída”, significando que o desenvolvedor está assumindo a responsabilidade de corrigir esta
23
falha. Assim que a mesma for corrigida, o desenvolvedor aciona a ação “resolver”, transitando o
estado para “fechada”.
Figura 5: Exemplo de fluxo de estados do workflow de uma falha
Já na Figura 6 se ilustra uma possível interação em um SIG, onde o sistema opera um
conjunto de documentos relacionados, e vários usuários acessam estes documentos ao mesmo
tempo. No caso apresentado na Figura 6, o usuário da esquerda visualiza o documento sem
permissão para edição, enquanto outros dois outros usuários editam suas partes em paralelo.
24
Figura 6: Ilustração de usuários interagindo num mesmo documento
Nesse sentido, os workflows são utilizados para assegurar a circulação das informações nos
corretos departamentos da empresa, informações estas que podem apresentar diferentes tipos de
dados e formulários de diferentes módulos com baixo acoplamento, demonstrando a relevância da
segurança para todos os documentos armazenados no sistema.
2.5. METODOLOGIAS PARA VERIFICAÇÃO DE SISTEMAS
Diversas são as metodologias para desenvolvimento e verificação de um sistema. Em se
tratando dos testes de verificação, que objetivam encontrar erros ou falhas no sistema, os mesmo
podem ser agrupados em duas categorias: testes manuais, e testes automatizados. Ainda, com
relação as metodologias de desenvolvimento, há as que mesclam as etapas de codificação com a
validação automatizada (NORTH, 2006; MELNIK, 2007; MUGRIDGE, 2008; CRISPIN e
GREGORY, 2009) e verificação automatizada (BECK, 2002), como as metodologias ágeis, por
exemplo o Desenvolvimento Guiado por Comportamento – BDD (NORTH, 2006).
25
2.5.1. TESTES MANUAIS
Segundo Sommerville (2007), testes são essenciais para a verificação da qualidade do
software. Além disso, cada vez que um software é alterado ou expandido, ele precisa ser testado em
toda a sua extensão. Existem diversas formas de verificar que um software foi implementado de
acordo com sua descrição. Uma delas é através de testes manuais, onde um ou mais usuários
utilizam o sistema das mais diversas formas possíveis a fim de encontrar falhas. Esta política deriva
do processo convencional de desenvolvimento de uma funcionalidade: estudar o problema, pensar
em uma solução, implementar essa solução, realizar testes manuais para verificar a correção, para
então validar a adequação da solução.
Para verificar se ainda existem erros não encontrados durante o desenvolvimento, é comum
submeter a aplicação a um processo de avaliação da qualidade antes de colocá-la em produção. Esse
controle de qualidade é realizado por especialistas no domínio do problema, desenvolvedores ou
mesmo equipes construídas unicamente para esse intuito.
Dentre outros modelos de desenvolvimento que se enquadram neste processo, pode-se citar
o Modelo Cascata. Conforme Sommerville (op. cit., p. 43) são consideradas as atividades
fundamentais compreendidas em Especificação, Desenvolvimento, Validação e Evolução, sendo
estas representadas por fases de processo separadas tais como ilustradas na Figura 7.
Figura 7: Modelo Cascata
26
Para Sommerville (op. cit.), o Ciclo de Vida de Desenvolvimento de Software (SDLC,
Software Development Life Cycle) depende que os requisitos sejam completamente levantados no
início do projeto, e que o produto seja entregue no final. Projetos de longo prazo raramente seguem
exatamente o que é proposto no início do projeto, pois durante longos prazos de projeto os
requisitos tendem a se deteriorar, perdendo seu valor ou adequação.
Ainda, este modelo exige demasiado esforço por parte do usuário, que precisa verificar
manualmente o sistema a cada alteração que o mesmo sofra. E este esforço cresce gradualmente
com o desenvolvimento da aplicação.
2.5.2. TESTES AUTOMATIZADOS
Métodos ágeis como Lean (WOMACK, JONES e ROOS, 2007), Scrum (SCHWABER,
2004) e XP (BECK e ANDRES, 2004) recomendam que todos os participantes do projeto trabalhem
com a preocupação de controlar a qualidade do produto todos os dias, buscando assim prevenir ou
corrigir defeitos com maior facilidade e com menor custo. A Programação eXtrema (XP)
recomenda explicitamente que sejam implementados testes automatizados no intuito de monitorar a
qualidade dos sistemas de software.
Testes automatizados são códigos desenvolvidos apenas para verificar o sistema, fazendo
uso de funcionalidades do software, verificando a correção de cada unidade do software, buscando
uma cobertura de testes que monitore a totalidade do software, com o objetivo de identificar
precocemente inconformidades no produto. A principal vantagem dessa abordagem é que todos os
testes podem ser executados a qualquer instante do desenvolvimento, e rapidamente repetidos
quantas vezes forem necessárias com um custo baixo, liberando os desenvolvedores do esforço de
teste, tornando o processo de testes menos propenso a falha humana.
Além disso, devido aos testes automatizados estarem programados em linguagem
executável, pode-se simular a manipulação do sistema por milhares de usuários ao mesmo tempo,
ou mesmo o esforço de milhares de testes simultaneamente. Outras vantagens da automação
tornam-se mais evidentes para os casos de softwares que possuem longa vida no mercado. Ocorre
que projetos de longo prazo apresentam mudanças ao longo de sua existência, e estas mudanças
implicam em risco de criação de novos falhas e defeitos. Mesmo pequenas correções no código de
uma aplicação podem causar a quebra de funcionalidades, sendo, portanto, necessário o
monitoramento de 100% da aplicação por testes automatizados ou testes manuais exaustivos,
realizados por equipes que se responsabilizem pela qualidade ou por futuros prejuízos causados em
27
produção.
A automação envolve testes designados caixa-preta, em que o desenvolvedor não se utiliza
de conhecimento sobre a estrutura interna do sistema; ou caixa-branca, em que há uso pleno do
conhecimento da estrutura interna. Em outras palavras, num teste caixa-preta, caso seja necessária
alguma função interna, não se verifica como ela se comporta internamente. Em um teste caixa-
branca, funções internas são completamente verificadas, incluindo quais métodos e procedimentos
são executados para retornar resultados. A cobertura de testes caixa-preta é determinada pela
experiência do desenvolvedor, enquanto a de testes caixa-branca pela métrica de cobertura de
código.
A automação de testes deve ser implantada desde o início do desenvolvimento, pois é difícil
garantir uma alta cobertura de código por testes, partindo do zero, quando o desenvolvimento já está
num estágio avançado; além desta automação ser usada em conjunto com técnicas manuais. Ainda,
pode cortar custos a longo prazo, especialmente na fase de teste de regressão, onde boa parte das
funcionalidades já estão implementadas, mas nem todas verificadas. Importante ressaltar que os
testes automatizados nem sempre precisam ser desenvolvidos manualmente, pois há formas de gerar
casos de teste automaticamente, como no caso do teste baseado em modelos, em que um modelo do
sistema é usado para a geração de casos de teste.
2.5.3. DESENVOLVIMENTO GUIADO POR COMPORTAMENTO
Em sua maioria, os testes automatizados são escritos programaticamente, necessitando assim
de conhecimento de programação, entretanto nem sempre isso se faz necessário. O método de
Desenvolvimento Guiado por Comportamento (BDD, Behaviour Driven Development) (NORTH,
2006), onde especificações são escritas em forma textual, como uma simples descrição de
funcionalidade e comportamento esperado, e este texto é interpretado e executado, servindo
portanto para validação e verificação do sistema.
O BDD é guiado pelos valores do negócio do cliente, ou seja, os benefícios trazidos para o
negócio no qual a aplicação está sendo desenvolvida. Para o cliente, que não possui os
conhecimentos de um desenvolvedor, um ponto de referência tangível é a interface visual. Assim,
para que o benefício seja percebido, faz-se necessário interagir com as interfaces da aplicação,
comumente denominada interface gráfica do usuário. Para tanto, faz-se necessário uma interação
cíclica entre o desenvolvedor e o usuário, para que as interfaces sejam rapidamente construídas,
mesmo que inicialmente de forma superficial, para validar com o usuário se o resultado esperado
está sendo atingido por aquela implementação, ou mesmo validar se os objetivos buscados são os
28
esperados pelo cliente.
Utilizando-se de princípios de design e refatoração (refactoring) (FOWLER et al., 1999;
SOMMERVILLE, 2007) o desenvolvedor modela o sistema sempre validando com o usuário, para
cada unidade do código. Para cada unidade também são escritos testes textuais, que o próprio
usuário pode descrever, e testes específicos escritos pelo desenvolvedor, a fim de validar e verificar
continuamente o sistema.
No BDD, os requisitos são quebrados em funcionalidades, e estas descritas textualmente em
passos. Uma funcionalidade (Feature) começa com a identificação ou nome do requerimento de
negócio e uma descrição livre desta funcionalidade, utilizando um conjunto pré-definido de
marcações, formando uma simples Linguagem Comum (Ubiquitous Language) (UL). O
requerimento é descrido seguindo o modelo:
Como um Papel
Eu quero uma Funcionalidade
Para obter um benefício
Esse modelo é utilizado basicamente para explicitar o valor de negócio aos usuários e
desenvolvedores. Posteriormente, uma série de cenários possíveis é escrita, utilizando a notação
Dado-Quando-Então (do inglês Given-When-Then), também conhecida como notação GWT, onde
cada frase representa um passo do cenário:
Dado um Contexto (ou um Estado do sistema)
Quando ocorre um Evento (ou uma Ação do usuário)
Então acontece uma Ação (ou Reação do sistema)
Importante ressaltar que a notação GWT também representa uma máquina de estados
(MARTIN, 2008), onde o passo “Dado” (Given) representa o estado atual, o passo “Quando”
(When) representa a ação (transição) que será executada, e o estado “Então” (Then) o resultado
esperado (estado final).
Como exemplo na Figura 8, é apresentado um caso de funcionalidade textual adaptado do
projeto de exemplos do Eis-Patterns (2012)3. Neste cenário escrito hipoteticamente por um analista
de crédito de um banco, sem conhecimento de programação, e que serve como teste de validação
por ser executável (ainda em sua forma textual).
3 https://github.com/ratem/eispatterns-examples/blob/master/bank_system/features/individual_credit_operation.feature
29
Figura 8: Exemplo de funcionalidade descrita textualmente
Nesta funcionalidade está sendo verificado que o sistema é capaz de reconhecer um Analista
de Crédito, bem como criar novos empréstimos para clientes existentes no sistema, e associar esses
empréstimos ao analista que o autorizou.
Para tanto, é utilizado um mecanismo para interpretar estes cenários e transformar as
sequências de texto em chamadas equivalentes na linguagem de programação, enquanto mantendo o
mesmo nível de abstração. Existem várias ferramentas, em diferentes linguagens, capazes de
executar cenários com notação GWT. A Tabela 1 cita algumas delas, agrupando-as de acordo com a
linguagem utilizada para executá-las.
Tabela 1: Exemplos de ferramentas BDD por linguagem
LINGUAGEM FERRAMENTAS
Java Concordion, EasyB, JBehave
Ruby RSpec, Cucumber
Python Pyramid, Pyccuracy, Freshen, Lettuce
Importante ressaltar que ao encapsular a implementação dos testes com uma descrição
textual seguindo a notação GWT, ou seja, possuir testes legíveis no nível do usuário, que não
necessitem de conhecimentos específicos para serem entendidos, consegue-se uma documentação
executável, com a vantagem de fazer todo o sistema verificável a qualquer momento. No entanto,
para Solis e Wang (2011), as características constituintes do BDD não são claramente definidas,
sendo necessária uma extensão da metodologia a fim de atingir seus objetivos finais de forma mais
concisa. É então sugerido, no obstante a adaptação do SIG aos seus requerimentos, um
desenvolvimento guiado com maior proximidade ao negócio. Uma das metodologias capazes de
surtir esse efeito é o Desenvolvimento Guiado por Linguagem de Negócio.
30
2.5.4. DESENVOLVIMENTO GUIADO POR LINGUAGEM DE NEGÓCIO
Ainda que o texto seja a forma mais natural de descrever os requisitos de um sistema
durante o desenvolvimento de SIGs, e apesar do BDD prover uma estrutura para tal, a Modelagem
de Processos de Negócios (do inglês Business Process Modeling) (BPM) (OMG, 2012) se torna
mais útil, provendo modelos em diferentes notações, como Diagramas de Estado em UML ou
diferentes tipos de Petri Nets.
Para Carvalho, Manhaes e Silva (2010), fica claro que a ligação entre modelos de processo
de negócio e o código que o implementa aparenta ser a solução para o problema de obter baixo
custo e alta confiabilidade no rastreamento de requisitos. Ainda, apesar da forma natural de
equacioná-los seja através da própria ferramenta de workflow, geralmente estas ferramentas
dependem de uma notação própria e de uma plataforma específica. Com isso, os autores propõem
uma nova metodologia para desenvolver sistemas de negócio de alta qualidade, o Desenvolvimento
Guiado por Linguagem de Negócio, ou Business Language Driven Development (BLDD).
BLDD pretende utilizar as ferramentas e filosofias propostas pelo BDD, e complementar o
GWT com a notação BPM. Ainda há descrição textual de requisitos, para quando não se faz sentido
utilizar modelos de processo, como em relatórios. Também, condições de aceitação são melhores
descritas textualmente.
Ainda, Carvalho, Manhaes e Silva (op. cit.) apontam que é possível reduzir riscos, custos e
esforços para desenvolver, adaptar e customizar um SIG através da verificação de workflows
utilizando BDD. Também, que se há SIG coberto com BDD, é possível inserir mudanças na BPM
representada por ele e, através dos testes, verificar os pontos exatos onde o SIG necessita ser
modificado para se adaptar aos novos requisitos.
Atualmente, o ERP5 emprega testes unitários, testes de carga e testes de aceitação no
sistema. O BLDD complementa os testes de aceitação, mas essa integração ainda não foi realizada.
Este trabalho representará uma etapa no processo de integração da metodologia BLDD ao ERP5.
31
3. DEFINIÇÃO E ESTRUTURAÇÃO DO ERP5
O ERP5 (SMETS-SOLANES e CARVALHO, 2003), desenvolvido principalmente pela
Nexedi, é uma solução de código aberto, publicada sob licença GPL, para criação de sistemas ERP /
CRM (Customer Relationship Management) / MRP (Material Requirement Planning) / SCM
(Supply Chain Management) / PDM (Product Design Management) para empresas de serviços,
indústrias e órgãos governamentais.
Para entender a proposta deste trabalho cabe entender o histórico do desenvolvimento e
formalização do ERP5, composto por uma série de diferentes abordagens. Seguindo a tendência
dominante da década passada, que utilizava o Desenvolvimento Guiado por Modelos (MDD, Model
Driven Development), a primeira abordagem no intuito de formalizar o processo do ERP5 foi
desenvolver uma arquitetura de modelagem e modelos de referência de alto nível (CAMPOS,
CARVALHO e FERREIRA, 2006), bem como o núcleo do processo de desenvolvimento
(CARVALHO e CAMPOS, 2006). Esse processo evoluiu ao ponto de fornecer um conjunto
completo de atividades integradas, abrangendo os diferentes níveis de abstração envolvidos através
do fornecimento, de acordo com o framework de Geram (IFIP, 1999), de fluxos de trabalho da
Empresa, de Requisitos, de Análise, de Design e de Implementação (MONNERAT, CARVALHO e
CAMPOS, 2008).
Embora o processo de desenvolvimento seja uma etapa importante da tarefa de desenvolver
e customizar um SIG, ele representa apenas uma parte do conhecimento necessário para a tarefa: de
modo a fornecer o conjunto "real", que é o código-fonte que reflete os requisitos de negócio, as
atividades de programação também devem ser cobertas. Assim, Carvalho e Monnerat (2007)
demonstram como desenvolver utilizando uma abordagem centrada no documento utilizada pelo
ERP5, enquanto Carvalho e Monnerat (2009) apresentam os padrões de design específicos
utilizados para derivar os conceitos a partir do núcleo do sistema.
32
Ainda, Carvalho e Monnerat (2008) apresentam dois conjuntos de ferramentas de apoio ao
desenvolvimento do ERP5: a) Ferramentas relacionadas ao produto, que sustentam as etapas de
criação, teste, configuração e gerenciamento de mudanças de código; e b) Ferramentas relacionadas
ao processo, que apoiam as atividades de gestão do projeto e colaboração em equipe. Com isso,
Carvalho, Campos e Monnerat (2009) apresentam uma visão geral de desenvolvimento no ERP5,
demonstrando o uso dessas ferramentas em cada fluxo de trabalho, e definindo seu ambiente de
desenvolvimento de domínio específico (DSDE, Domain-specific development environment).
Embora fosse possível construir um abrangente processo de desenvolvimento baseado em
MDD, o grupo de pesquisa e desenvolvimento responsável por propor este processo estava, ao
mesmo tempo, desenvolvendo uma solução de Gestão de Conteúdo Empresarial (Enterprise Content
Management) (CARVALHO, 2007) e experimentando-o com técnicas ágeis, tanto na gestão do
projeto quanto na construção do sistema. A utilização desses experimentos no desenvolvimento do
SIG levou a customização de uma série de técnicas ágeis para esse tipo de sistema, como
demonstrado em Carvalho, Johansson e Manhaes (2010).
O trabalho com o ERP5 forneceu uma base, tanto na pesquisa quando na prática, suficiente
para identificar os tipos de técnicas relativamente novas de desenvolvimento de software que
poderiam ser usadas em outros projetos de desenvolvimento de SIG: testes automatizados, uso de
um ambiente de desenvolvimento de domínio específico, uma linguagem de domínio específico
para modelar os processos de negócio, o uso de uma linguagem de programação dinâmica, e a
aplicação de padrões de design.
Ainda, a exploração de um complexo sistema real demonstrou que outros avanços poderiam
ser obtidos, através da utilização intensiva das técnicas mencionadas, bem como da utilização de um
framework leve - onde resultados de experimentos pudessem ser obtidos rapidamente, sendo
possível aplicá-los no sistema real.
A Figura 9 ilustra como todos esses módulos, agregados em “business templates” no ERP5
(CARVALHO e MONNERAT, 2007), se inter-relacionam. Nela, é possível observar o núcleo ERP,
bem como os módulos Finance, Payroll, CRM, eCommerce e PDM. Além disso, por ser extensível
e possibilitar a integração de módulos customizados, construídos especificamente para suportar o
modelo de negócio da organização, existe também na ilustração um módulo Custom para
representá-los. Podem-se visualizar ainda as bases nas quais o ERP5 é construído, representadas
respectivamente pelo servidor de aplicações Zope (VON WEITERSHAUSEN e EBY, 2008) como
também por bancos de dados (em especial o MySQL), e um sistema operacional (por padrão,
qualquer derivado Linux).
33
Figura 9: Bases e módulos no ERP5
Fonte: Nexedi SA
Dentre suas características, pode-se ressaltar que o ERP5 é baseado no acesso remoto,
através da internet, possibilitando a utilização de qualquer lugar do mundo; tem uma estrutura
interna inovadora, que prioriza o desempenho e segurança das informações; e atualmente possui sua
arquitetura totalmente baseada em nuvens (cloud architecture), através da utilização do SlapOS,
uma fonte aberta de provisionamento e faturamento de sistemas totalmente em nuvem. Além disso,
busca seguir dois conceitos fundamentais, o SaaS (Software como um Serviço, ou Software as a
Service) e o PaaS (Plataforma como um Serviço, ou Platform as a Service).
Além disso, possui inclusive um projeto para ensino de ERP livre denominado “One
Student, One ERP” (OSOE), que objetiva ensinar a manusear e desenvolver novas ferramentas para
o ERP5. O projeto possui um portal (OSOE, 2012) onde é possível encontrar diversos tutoriais de
instalação, configuração e utilização do ERP5, no intuito de facilitar e absorver um maior número
de utilizadores.
Este trabalho fará uso do ERP5 como prova de conceito, porque além de ser livre de custos,
possui código aberto, possibilitando assim uma facilidade superior em relação ao manuseio de
código e interação com o núcleo do sistema, necessário para executar testes automatizados e
desenvolvimento de ferramentas e métodos que serão importantes na realização dos experimentos.
3.1. ESTRUTURA DOS FLUXOS DE TRABALHO
34
No ERP5, os fluxos de trabalho, ou workflows, são baseados em uma Máquina de Estados
Finita (FSM), sendo utilizada para suportar estas atividades a ferramenta DCWorkflow
(DCWorkflow Documentation, 2012). O DCWorkflow é um software bem simples e sua
implementação também é baseada em uma FSM. A Figura 10 representa graficamente o workflow
de recibos denominado acknowledgment_workflow, disponível no ERP5, que é implementado
através da ferramenta DCWorkflow.
Figura 10: Workflow “acknowledgement_workflow” do EPR5
Na figura acima, observa-se que os estados (representados por quadrados) possuem uma
descrição (Draft – Rascunho, Delivered – Entregue). Também, cada estado possui um identificador,
escrito em parênteses. Para exibição na interface gráfica, é utilizada a descrição do estado, a fim de
facilitar para o usuário identificar em qual estado está o seu documento e quais são as ações
possíveis.
Ainda, toda transição nunca é exibida para o usuário como sua identificação no workflow,
mas sim como sua ação ou sua descrição. Por exemplo, uma transição no workflow denominada
“deliver” (entregar) seria exibida para o usuário como “Deliver Product” (Entregar Produto). Para
esse workflow ilustrado, a Tabela 2 identifica os possíveis estados e transições.
Tabela 2: Estados e transições possíveis do workflow ilustrado na Figura 10
ESTADO TRANSIÇÕES POSSÍVEIS
DRAFT Deliver (Entregar)
DELIVERED –
Após a instalação do Zope e posteriormente do ERP5, é possível criar um portal do ERP5 no
35
Zope. Este portal contém acesso a todos os objetos e ferramentas do Zope. No momento da criação
do portal, a ferramenta DCWorkflow se torna o módulo portal_workflow, e nele são inseridos e
configurados todos os workflows disponíveis no sistema. Vale ressaltar que a ferramenta
DCWorkflow permite que um mesmo documento possua vários workflows simultaneamente, e esta
funcionalidade é utilizada no ERP5, a fim de possibilitar uma diversa gama de comportamentos
para cada documento.
No ERP5, há um padrão para nomeação dos identificadores das transições. Nele, qualquer
transição que tenha seu nome terminado em “_action” acarretará a execução da mesma transição
cujo identificador não possua a terminação “_action”. Por exemplo, para cancelar um documento, o
usuário aciona apenas a transição “cancel_action”, que por sua vez acionará automaticamente a
transição “cancel”. Obviamente, a transição “cancel_action” é exibida para o usuário como
“Cancelar Documento”, pois como dito, uma transição nunca é exibida como seu identificador, e
sim como sua ação ou descrição.
Existem ainda regras que ditam quais usuários podem efetuar quais transições, pois nem
todos os usuários têm permissão suficiente para tal. Estas regras são definidas de acordo com o
papel do usuário, onde um papel significa uma responsabilidade ou característica inerente ao
usuário. Se um usuário possui pelo menos um dos papéis necessários para executar uma transição,
então ele pode executá-la.
Neste trabalho serão utilizados somente documentos, workflows e testes relacionados ao
conjunto de módulos de CRM (para relação com clientes). O conjunto de módulos de CRM é
composto, entre outros, pelos módulos de Campanhas, Eventos, Reuniões, Organizações, Pessoas e
Oportunidades de Venda.
Pode-se exemplificar, por exemplo, o documento do tipo Oportunidade de Venda (Sale
Opportunity), normalmente utilizado quando há uma nova negociação de mercado em andamento.
Este objeto tem seu fluxo de trabalho designado principalmente pelo workflow Sale Opportunity,
parte integrante do ERP5 e estruturado como o diagrama de estados na Figura 11.
36
Figura 11: Sale Opportunity Workflow
Nesta estrutura, o estado inicial do documento é rascunho (‘draft’). A partir deste estado, três
são os possíveis estados consecutivos: submetido (‘submitted’), removido (‘deleted’) e cancelado
(‘cancelled’); os quais se atingem através das transições submeter (‘submit’), remover (‘delete’) e
cancelar (‘cancel’), respectivamente. No Diagrama de Estados, o fluxo de interações pode ser
deduzido através das setas que indicam as transições possíveis de estado do documento (objeto).
Como dito anteriormente, existem regras que regem que papel de usuário pode executar
determinada transição. No caso do workflow Sale Opportunity, a Tabela 3 demonstra as transições e
os respectivos papéis de usuário necessários para executá-las.
Tabela 3: Transições e os respectivos papéis de usuário requeridos
Transição (Transition) Papel de usuário requerido (Required Role)
Cancelar (Cancel) Administrador, Cedente ou Proprietário
Deletar (Delete) Administrador, Cedente ou Proprietário
Averiguar (Enquire) Administrador ou Cedente
Expirar (Expire) Administrador ou Cedente
37
Oferecer (Offer) Administrador ou Cedente
Rejeitar (Reject) Administrador ou Cedente
Vender (Sell) Administrador ou Cedente
Validar (Validate) Administrador, Cedente ou Proprietário
A partir da tabela é possível, por exemplo, identificar que a transição Cancelar somente pode
ser executada por um usuário que possua papel de Administrador, Cedente ou Proprietário.
Qualquer usuário que não possua qualquer um desses papéis automaticamente nem visualizará essa
transição, possivelmente nem saberá da existência da mesma.
38
4. MECANISMO PARA VERIFICAÇÃO DE WORKFLOWS NO SIG
A fim de interligar as funcionalidades descritas pelo usuário no Módulo de Funcionalidades
com testes automatizados unitários que manipulem os mesmos workflows, torna-se imprescindível
implementar um mecanismo que identifique o que cada teste verifica de cada workflow, para
posteriormente encontrar quais testes específicos se relacionam com a Funcionalidade descrita pelo
usuário.
Neste capítulo será apresentado o processo para desenvolvimento do mecanismo, suas
funcionalidades e utilização. A fim de validar os workflows no ERP5, foi preciso implementar um
mecanismo capaz de interceptar, durante a execução dos testes automatizados, quais workflows
estão sendo manipulados por cada teste, e armazená-los para posterior utilização. Também foi
preciso desenvolver um módulo para gerenciar as funcionalidades descritas pelo usuário, para então
encontrar quais testes específicos se relacionam com essas funcionalidades.
4.1. ANÁLISE DE WORKFLOWS EM TESTES AUTOMATIZADOS DO ERP5
Primeiramente foi definido que as informações que precisam ser salvas, para cada teste, são:
tipos de objetos (documentos) manipulados, workflows utilizados, transições acionadas em cada
workflow e estados visitados.
Para isso, primeiramente foi preciso formular um meio para interceptar a execução das
transações. Através de depuração de código do módulo DCWorkflow4, observou-se que toda
4 http://pypi.python.org/pypi/Products.DCWorkflow/2.2.1
39
transação inevitavelmente aciona o método “_executeTransition” (pertencente a classe
DCWorkflowDefinition), sendo passado como parâmetros o objeto no qual a transação ocorrerá
(ob) e a transição (tdef) que deve ser executada no objeto, conforme o cabeçalho do método
ilustrado na Figura 12, em que se pode observar também parte de sua definição.
Figura 12: Cabeçalho e parte da definição do método _executeTransition
Em resumo, este método cuida de identificar qual o estado atual do objeto, qual o estado
futuro ao executar a transição, e acionar os gatilhos necessários para transitar o estado deste objeto.
Após várias execuções do método “_executeTransition”, percebeu-se que nem sempre o
parâmetro tdef (transição) é passado como parâmetro, como no caso da criação de um novo objeto.
Nestes casos de ausência deste parâmetro tdef, o método se encarrega de identificar qual o estado
inicial definido pelo workflow para objeto, e utiliza-o sem que seja necessária uma transição.
Assim, decidiu-se que o método “_executeTransition” era o método ideal para ser
sobrescrito, já que o objetivo é analisar toda transição ocorrida. Este método pode ser interceptado
em dois pontos distintos durante a execução dos testes: No momento da instalação do portal ERP5,
onde a ferramenta DCWorkflow é importada para o sistema; e após a instalação da ferramenta no
portal, onde, conforme já mencionado, a mesma se torna acessível através do módulo
40
“portal_workflow”.
4.1.1. TESTES AUTOMATIZADOS NO ZOPE
O Zope disponibiliza uma suíte de testes para implementação de testes automatizados. Essa
suíte funciona, basicamente, da seguinte forma:
1. Existe uma classe de testes denominada ZopeTestCase
2. Toda classe de teste deve herdar de ZopeTestCase
a. Usualmente, cria-se uma classe base de testes que herde de ZopeTestCase, e esta
classe base é utilizada como herança para os testes
3. Todo método pertencente a uma classe que herde em algum nível da classe
ZopeTestCase, e que iniciar com a palavra “test_”, será considerado teste e executado
Obs.: Durante a execução da suíte de testes, todas as classes de teste e seus respectivos métodos são
identificados, e cada método é executado separadamente, de forma síncrona.
A suíte de testes fornece métodos com o objetivo de facilitar a instalação e configuração de
um novo portal para ser utilizado nos testes que, neste caso, corresponde ao portal ERP5. A classe
ZopeTestCase disponibiliza atributos e funções que visam facilitar o acesso a ferramentas e
manipulação de qualquer objeto existente no portal instalado. Vale ressaltar que essa classe ainda
disponibiliza um atributo denominado “portal”, correspondendo ao portal instalado, e acessível
durante todo o escopo do teste. Ainda, possui métodos pré-definidos de interceptação que, se
declarados, interceptam a execução do(s) teste(s) em algum momento:
O método “setUp”, se declarado, é executado uma única vez, antes da execução da suíte
de testes
O método “afterSetUp”, se declarado, é executado toda vez antes de executar um teste
O método “beforeTearDown”, se declarado, é executado toda vez logo ao fim do teste
O método “tearDown”, se declarado, é executado toda vez logo após a finalização do
teste
A Figura 13 exemplifica o processo de execução de um teste desde a classe base
ZopeTestCase pertencente a suíte de testes do Zope, passando pela classe base de testes do ERP5
denominada ERP5TypeTestCase, chegando até uma classe real de testes denominada TestCRM,
bem como os métodos de interceptação descritos anteriormente. O fluxo de execução segue
verticalmente da parte superior para a inferior, e horizontalmente conforme as setas, começando no
41
método setUp da classe ZopeTestCase e finalizando no método tearDown também da classe
ZopeTestCase.
Figura 13: Processo de execução de um teste no ERP5
Analisando este fluxo de execução de métodos, observou-se que o melhor ponto para
interceptar o portal_workflow era através do método afterSetUp da classe ERP5TypeTestCase, por
ser o último método sempre executado antes de dar-se início ao teste em si.
Como exemplo, tem-se o teste “test_SaleOpportunitySold”, conforme ilustrado na Figura 14,
que verifica que um objeto do tipo Oportunidade de Venda possui as corretas transições de estados
desde sua criação até que seja finalmente colocado como vendido. Essa verificação pode ser
observada, por exemplo, na linha 245 do código exibido, onde o método “assertEquals” certifica
que o estado atual do documento (capturado através do método “getSimulationState”) é rascunho
(“draft”).
42
Figura 14: Teste "test_SaleOpportunitySold"
O teste “test_SaleOpportunitySold” está definido na classe TestCRM5, que agrega
praticamente todos os testes relativos ao módulo CRM. A classe BaseTestCRM possui os métodos
de interceptação descritos na Figura 15. Como se pode ver na linha 65 do código da Figura 15, antes
de cada teste ser executado, é realizada uma limpeza do módulo de emails (MailHost); e após cada
teste, logo após a finalização, todas as transações em andamento são canceladas (por não serem
mais necessárias) (linha 68), e todos os objetos criados são removidos (linhas 70 a 72), limpando o
ambiente a fim de não interferir no próximo teste da suíte.
5 https://svn.erp5.org/repos/public/erp5/trunk/products/ERP5/tests/testCRM.py
43
Figura 15: Métodos de interceptação dos testes do módulo CRM
Antes de descrever as metodologias utilizadas no intuito de sobrescrever o portal_workflow,
é preciso entender como essa sobrescrita será feita. Será utilizada uma técnica de programação
comum na linguagem Python denominada wrapper ou decorator, onde uma função ou classe
previamente definida denominada wrapper toma o lugar da função alvo (que no caso será a
“_executeTransition”), tornando possível executar algoritmos antes e depois da chamada à função
alvo.
Também é preciso definir o que é uma transação no Zope, a fim de entender os erros
encontrados no processo. Uma transação, ou Transaction (ZOPE FOUNDATION, 2012), é a forma
definida pelo banco de dados transacional orientado a objetos utilizado pelo Zope (ZODB) (ZOPE
FOUNDATION, 2011) para acompanhar toda manipulação de dados que estão persistidos, e é
gerenciada através do Gerenciador de Transações (Transaction Manager). Dessa forma, qualquer
dado alterado que seja de interesse do Transaction Manager é atualizado no ZODB no momento
que uma transação é finalizada (commit). Essa finalização pode ser espontânea (encerramento da
transação), ou forçada (onde o método commit é acionado). Para que os dados sejam persistidos no
ZODB, faz-se uso da biblioteca nativa do Python denominada Pickle, capaz de serializar e
desserializar diversos tipos de objetos.
44
4.1.2. MÉTODOS PARA INTERCEPTAÇÃO DE TRANSIÇÕES
Conforme já mencionado, o método ideal a ser interceptado para análise das transições de
estados dos workflows no momento da execução de um teste automatizado é o método
“_executeTransition”, encontrado no módulo portal_workflow, módulo este alcançado através do
atributo “portal”, existente em todo teste. Cabe reafirmar também que o módulo portal_workflow,
corresponde basicamente a uma instância da ferramenta DCWorkflow já instalada e configurada no
portal.
No intuito de alcançar este objetivo, várias metodologias foram desenvolvidas, porém nem
todas obtiveram sucesso. A seguir serão descritos fracassos e conquistas até o alcance do objetivo.
Importante ressaltar que o código, que será apresentado, utilizado para definir a função
“precall” e a classe “PreCaller” tiveram como inspiração uma discussão6 sobre metaprogramação
em Python no que diz respeito ao padrão de projeto decorator (ou mais comumente denominado
wrapper na linguagem Python).
O padrão de projeto decorator visa adicionar um comportamento a uma entidade já existente
de um objeto em tempo de execução. Em suma, acrescentar uma responsabilidade a algo já
existente. Utilizando um wrapper, é possível adicionar um comportamento anterior e posterior a
execução de, por exemplo, um método, como o já abordado “_executeTransition”.
4.1.2.1. INTERCEPTAÇÃO DO DCWORKFLOW COM UMA FUNÇÃO
A primeira metodologia para sobrescrever o portal_workflow foi utilizar o método de
interceptação “afterSetUp”, afinal este método é executado antes de cada teste. Essa primeira
implementação resultou na Figura 16, onde a wrapper denominada “precall” (linha 6) foi
construída para adicionar uma pré-execução da função “analyzer” (linha 16) antes que a função
“_executeTransition” fosse executada. O procedimento de decorar a função “_executeTransition”
pode ser visto na linha 20, onde esta função é substituída pela “precall”.
6 http://stackoverflow.com/questions/258119/python-wrapping-method-invocations-with-pre-and-post-methods
45
Figura 16: Primeira abordagem para interceptar o portal_workflow
O que ainda não se sabia é que qualquer atributo do portal alterado (“self.portal.”) é
serializado e salvo no ZODB assim que um teste força a finalização (commit) de uma transação.
Ocorre que o Pickle não é capaz de serializar funções descritas dessa forma, e portanto o erro
“TypeError: Pickle can’t serialize function objects” foi lançado no momento da execução dos testes,
tornando essa metodologia inapropriada.
4.1.2.2. INTERCEPTAÇÃO DO DCWORKFLOW COM UMA CLASSE
Devido à incapacidade do Pickle de serializar funções descritas conforme a primeira
metodologia, uma segunda maneira foi criada para interceptar o portal_workflow. Ainda fazendo
uso do método de interceptação “afterSetUp”, o portal_workflow foi totalmente encapsulado na
classe wrapper “PreCaller” (linha 44) (armazenado na forma do atributo “other”, como apresentado
na linha 46), a fim de fazer o mesmo que a antiga função “precall”, pré-executar uma função. Ao
contrário da antiga função “precall”, a função que será pré-executada neste caso é a
“show_transition” (linha 48), antes de chamar a função “_executeTransition”. Esta implementação
pode ser vista na Figura 17, onde parte do código desnecessário à ilustração foi substituído por
pontos sequenciais (“............”). O procedimento para decorar todo o portal_workflow pode ser visto
na linha 75.
46
Figura 17: Segunda abordagem para interceptar o portal_workflow
Ainda assim, não foi solucionado o problema com a serialização imposta pelo Pickle, pois
no momento da transação ser finalizada, era requisitado o estado do portal_workflow, e a classe
“PreCaller” não era capaz de fornecer essa informação.
A classe “PreCaller” foi então colocada como herança da classe “pickle.Pickler” (linha 44),
tornando possível disponibilizar o método “__getstate__” (linha 48), a fim de responder ao Pickle o
estado atual do objeto, quando este fosse requisitado, conforme descrito na Figura 18.
47
Figura 18: Terceira abordagem para interceptação do portal_workflow
Essa implementação, a princípio, gerou erro, pois retornava o antigo módulo
portal_workflow (registrado como a classe “WorkflowTool”) encapsulado como função, e como já
foi dito, o Pickle não é capaz de serializar funções. No intuito de resolver o problema, durante a
execução do método “__getstate__” foi implementado um algoritmo a fim de remover a função
encapsulada da lista de objetos retornada, que antes continha a classe encapsulada “WorkflowTool”,
mas então foi encontrado o erro “TypeError: Can't pickle objects in acquisition wrappers”. Em
outras palavras, o encapsulamento (wrap) da classe WorkflowTool na função “_wrap” estava
ocasionando o já mencionado erro, pois o Pickle não consegue lidar com “acquisition wrappers”,
em outras palavras, não suporta requerer objetos salvos como atributos no portal antes da transação
para compará-los com os atributos recuperados após a transação recomeçar.
48
Explicando de uma forma mais detalhada, ao finalizar uma transação (naturalmente ou de
maneira forçada), uma nova transação é imediatamente inicializada, resgatando do ZODB os objetos
persistidos. Nesse resgate, quando uma classe possui um inicializador que requer parâmetros, o
retorno do método “__getstate__” durante a serialização da transação anterior é utilizado para
inicialização da nova instância da classe, através do método “__setstate__”.
Esse é o caso da classe wrapper “PreCaller”, pois o método inicializador (“__init__”)
requer o parâmetro “other”, que representa o portal_workflow. Como o portal_workflow
(WorkflowTool) foi removido no retorno do método “__getstate__”, a inicialização da classe
“PreCaller” estava sendo feita com parâmetros vazios, acarretando erros na recuperação da
transação, pois forçava a comparação de um novo atributo salvo no portal (“self.other”, que
representava o portal_workflow) com um objeto persistido no ZODB que não possui esse atributo.
Contudo, por este atributo estar salvo no portal, a recuperação do mesmo dá-se através de um
processo denominado acquisition (onde a informação requerida, enquanto não encontrada, é
buscada a partir do contexto atual, caminhando até chegar no portal em si), processo este não
suportado pelo Pickle no momento da recuperação da serialização.
4.1.2.3. INTERCEPTAÇÃO DO DCWORKFLOW NA INSTALAÇÃO DO PORTAL
No momento que um portal é configurado e inicializado para testes, várias configurações e
instalações ocorrem, inclusive para adicionar ao portal os vários business templates e objetos
necessários aos testes. A solução final encontrada para sobrescrever o portal_workflow foi realizar
essa modificação antes que o DCWorkflow fosse utilizado pela primeira vez para instalação no
portal.
Para isso, foi utilizado o método “onsetup”, disponibilizado como um método de camada do
ZopeTestCase, e que é executado antes que as configurações do portal comecem a serem feitas. Um
patch foi aplicado diretamente no módulo DCWorkflow, sobrescrevendo a função
“_executeTransition” por uma função wrapper, que por sua vez guardava e chamava a função
original após analisar e registrar qual transição estava ocorrendo. O resultado final da chamada para
sobrescrita pode ser visto na Figura 19, enquanto a implementação do patch pode ser vista na
Figura 20.
Figura 19: Sobrescrita do portal_workflow na configuração do portal
49
Figura 20: Implementação do patch para o portal_workflow
Com essa implementação final, ao fim de cada teste é exibido um log constando:
todos os workflows manipulados pelo teste
quais tipos de objetos foram manipulados em cada workflow
quais transições foram acionadas, com antigo estado e novo estado gerado pela
transição
Executando novamente o teste “test_SaleOpportunitySold” (já abordado na Figura 14),
pode-se visualizar na Figura 21 a análise concluída do teste, indexada pelos workflows
50
manipulados.
Figura 21: Exemplo de análise com sucesso do teste “test_SaleOpportunitySold”
Caso alguma falha fosse encontrada durante a execução da análise no teste
“test_SaleOpportunitySold”, o resultado seria semelhante ao apresentado na Figura 22. Aqui,
observa-se uma falha forçada no momento da checagem do estado atual do objeto após a transição
“enquire”. O teste coloca como estado esperado o “not_enquired”, enquanto pode-se visualizar no
log da análise o verdadeiro estado atual do objeto como sendo “enquired”.
51
Figura 22: Exemplo de análise com falha do teste “test_SaleOpportunitySold”
Com isso, fica claro que mesmo em testes com falha, a análise é efetuada com sucesso,
restando aos desenvolvedores e usuários analisarem o log a fim de verificar e corrigir os testes e
implementação, pois a análise se mantém correta no rastreamento de transições.
Além disso, são armazenados quais workflows estão sendo manipulados por quais testes.
Como no último exemplo com falha, onde o teste “test_SaleOpportunitySold” manipulou os
workflows “edit_workflow” e “sale_opportunity_workflow”.
52
4.2. MÓDULO DE ESPECIFICAÇÃO DE REQUISITOS
Com o intuito de armazenar requisitos descritos pelo usuário no ERP5 conforme preza o
BDD, neste trabalho um módulo foi desenvolvido, e denominado Módulo de Funcionalidades
(Feature Module). O mesmo armazena Funcionalidades, que por sua vez armazenam Cenários,
necessários para descrever os requisitos do usuário.
Para especificar o funcionamento do módulo desenvolvido, será utilizada como exemplo a
funcionalidade ilustrada Figura 23. Na ilustração, é definido que o usuário, como um gerente,
precisa de um módulo para gerenciar suas oportunidades de venda, de modo a obter melhores
relatórios sobre estes processos de negócio.
Figura 23: Funcionalidade e um possível cenário do documento Oportunidade de Venda
Para fazer uso desta funcionalidade, o usuário primeiramente deve criá-la no Módulo de
Funcionalidades, e posteriormente descrever seus possíveis cenários. Para efetuar estes passos, ele
acessa o módulo, e executa a ação de criar uma nova Funcionalidade, como mostrado na Figura 24.
53
Figura 24: Ação para criar nova Funcionalidade
Será então aberta a tela de descrição da Funcionalidade, onde se deve preencher seu Título e
sua descrição. Após descrevê-la, conforme ilustrado na Figura 25, ele aciona a ação de acionar um
novo Cenário à funcionalidade, ação esta também ilustrada na figura.
Figura 25: Ação para criar novo Cenário
Será aberta então a tela de descrição do Cenário, conforme visualizado na Figura 26. Nesta
tela se deve preencher o Título do Cenário, bem como sua descrição; observa-se na figura a
utilização da notação GWT para descrição do Cenário.
54
Figura 26: Descrição do Cenário
O usuário pode adicionar quantos cenários forem precisos para a funcionalidade. Ao fim da
descrição completa dos cenários, pode-se obter uma Funcionalidade como a ilustrada na Figura 27,
onde se observa a funcionalidade Oportunidade de Venda Básica (Basic Sale Opportunity) contendo
quatro possíveis cenários:
Oportunidade de Venda é cancelada – Sale Opportunity is cancelled;
Oportunidade de Venda é vendida – Sale Opportunity is sold;
Oportunidade de Venda expira – Sale Opportunity expires;
Oportunidade de Venda é rejeitada – Sale Opportunity is rejected.
55
Figura 27: Exemplo de uma Funcionalidade completamente descrita
Cada Cenário descrito na Funcionalidade aborda determinadas transições do já ilustrado
workflow Sale Opportunity, portanto cada cenário descreve um possível fluxo do processo de
negócio relativo a uma Oportunidade de Venda.
Como exemplo, para o cenário Oportunidade de Venda é vendida, ocorre o seguinte fluxo de
estados e transições ilustrado na Figura 28, sendo o estado inicial o estado “rascunho”.
56
Figura 28 : Fluxo de estados e transições do cenário Oportunidade de Venda é vendida
Esta sequência de estados alcançados pelo documento Oportunidade de Venda ilustrada na
figura, partindo do estado “rascunho” (draft), até o estado “vendido” (sold), é apenas um dos
possíveis fluxos a serem seguidos no workflow Sale Opportunity.
Tendo um cenário descrito, é possível executar os passos definidos no mesmo a fim de
verificar que estes passos podem ser reproduzidos pela interface do SIG. Como exemplo, tem-se o
cenário “Oportunidade de Venda é submetida” apresentado na Figura 29.
57
Figura 29: Descrição do cenário Oportunidade de Venda é submetida
Este cenário tem como objetivo verificar que é possível criar uma Oportunidade de Venda, e
que posteriormente é possível acionar a transição “submit_action” para transitar o estado atual do
documento para o estado final “submitted”, como mostrado na Figura 28. Foi construída a ação
“Executar Passos” (Execute Steps) ilustrada pela Figura 30, tornando possível executar os passos
descritos no cenário, a fim de realmente comprovar a utilização dos workflows esperados, e
encontrar quais testes automatizados do sistema manipulam os mesmos workflows.
Figura 30: Ação “Executar passos” do cenário
58
Essa ação executa o método executeSteps demonstrado na Figura 31, que cuida de separar o
cenário em passos, onde cada passo é uma linha do cenário, e verificar se esse passo se encaixa
numa expressão regular previamente definida. Há três expressões regulares definidas, que buscam
identificar os passos descritos no cenário conforme ilustrado na Figura 32, onde a expressão:
“create_object_step” cuida de criar um documento do tipo definido, encontrando
primeiro qual módulo cuida deste tipo de documento
“fire_transaction_step” aciona uma transação no documento criado
“check_state_step” certifica que o estado atual do documento é o mesmo que o
estado esperado
Enquanto os passos que não são identificados por uma expressão regular são ignorados.
Figura 31: Parte da implementação do método executeSteps
59
Figura 32: Expressões regulares para identificar passos num cenário
No caso do exemplo, a resposta da execução do cenário é apresentada na Figura 33, onde é
possível observar a criação de um objeto Oportunidade de Venda no Módulo de Oportunidades de
Venda (“sale_opportunity_module”).
Figura 33: Resultado da execução dos passos do cenário “Oportunidade de Venda é submetida”
Também é possível observar que a ferramenta ignorou o passo “When I check that it has all
required fields”, pois este passo não tem relação com a ferramenta em si, serviu apenas para
ambientar melhor o usuário que estiver lendo a funcionalidade, além de não possuir expressão
regular que identifique este passo. Ainda, são exibidas todas as transições acionadas, sendo no
exemplo acionada apenas a transição ‘submit_action’, onde é posteriormente verificado que o
estado final após a transição é “submitted”.
A ferramenta também identifica quais testes automatizados manipulam os mesmos
60
workflows manipulados durante a execução do cenário. No caso do exemplo, apenas o workflow
“sale_opportunity_workflow” foi manipulado, e os testes que também o manipularam estão dentro
da classe teste “TestCRM”, sendo os testes: “test_SaleOpportunityExpired”,
“test_SaleOpportunitySold”, e “test_SaleOpportunityRejected”. Dentre eles, o teste
“test_SaleOpportunitySold” já foi descrito anteriormente.
Assim, demonstra-se a capacidade da ferramenta em executar um cenário textual,
identificando os passos descritos e executando-os no sistema como se fosse um usuário real,
verificando que o resultado esperado foi conseguido, além de fornecer quais testes já existentes
também manipularam os mesmos workflows do cenário executado, alertando caso não sejam
encontrados testes para o workflow manipulado no cenário.
61
5. CONCLUSÕES
Foi desenvolvido um módulo denominado Módulo de Funcionalidades (Feature Module)
que possibilita ao usuário descrever textualmente os requisitos de workflows, em forma de
funcionalidades e cenários. Essa é uma conquista relevante, pois possibilitará a execução
acompanhada dos testes dessas funcionalidades, trazendo um melhor entendimento de quais
transições estão sendo acionadas, facilitando a verificação de que todos os requisitos de workflows
foram corretamente implementados; bem como identificar os testes automatizados que tenham
ligação com estas funcionalidades. Com relação aos testes automatizados, um mecanismo foi
implementado com o intuito de interceptar as transições que ocorressem no EPR5 enquanto os
testes automatizados eram executados, tornando possível analisar melhor o que cada teste realmente
valida no obstante ao fluxo de estados dos documentos. Ainda, foi adicionada uma ação ao Módulo
de Funcionalidades no intuito de executar os cenários como testes, identificando quais workflows
são manipulados durante a execução, posteriormente recuperando quais testes manipularam os
mesmos workflows do cenário executado.
O presente trabalho trouxe como principal contribuição um melhor relacionamento entre os
especialistas de negócio que definem os requisitos e os desenvolvedores, possibilitando que o
próprio especialista descreva os requisitos no sistema e valide sua adequação e correção.
Todo o código utilizado nesse trabalho encontra-se disponível na página
https://github.com/gabriellima/erp5_bldd_feature, onde pode-se obter o business template
erp5_bldd_feature contendo o Módulo de Funcionalidades, os códigos para interceptação dos testes
automatizados e um manual de utilização dos mesmos.
Sugere-se como trabalho futuro, utilizando o Feature Module e a interceptação de transições
durante os testes automatizados, desenvolver uma integração visual, onde os cenários descritos pelo
usuário seguindo a abordagem GWT sejam extendidos por uma notação da Modelagem de
62
Processos de Negócio, seja com Petri-nets ou Diagramas de Atividade UML, na suíte de testes
visuais do ERP5, conforme aborda a metodologia BLDD proposta por Carvalho, Manhaes e Silva
(2010), executando a cada passo os testes automatizados correspondentes que manipulem os
mesmos workflows no passo apresentado. Ainda, que o usuário seja capaz de interceder no
momento da execução da funcionalidade, alterando como desejar os valores utilizados no teste, bem
como qual caminho seguir no fluxo de trabalho do documento, a fim de verificar que realmente
todos os requisitos foram implementados satisfatoriamente. Com isso, o trabalho de checagem da
funcionalidade requisitada será menos trabalhosa, verificando que não há falhas na política de
gestão de transições de estados, bem como nas respostas do sistema aos passos descritos pelo
usuário.
Espera-se com este trabalho que o algoritmo desenvolvido seja reutilizado por outros
projetos, e mesmo por outros módulos do ERP5, no intuito de entender melhor como os testes
automatizados estão validando os workflows implementados, e acoplar melhor os requisitos do
usuário com os testes automatizados, levando em consideração os estados e permissões de transição
requisitadas.
63
REFERÊNCIAS BIBLIOGRÁFICAS
BARRETO, Aldo de Albuquerque. A Transferência da Informação Para o Conhecimento. In: O
campo da Ciência da Informação: gênese, conexões e especificidades. João Pessoa, UFPB,
2002.
BECK, Kent. Test Driven Development by Example. Boston: Addison-Wesley Professional, 2002.
176 p.
BECK, Kent; ANDRES, Cynthia. Extreme Programming Explained: Embrace Change. 2. ed.
Boston: Addison-wesley Professional, 2004. 224 p.
CAMPOS, Renato de; CARVALHO, Rogerio Atem de; FERREIRA, Ailton S. Modeling
Architecture and Reference Models for the ERP5 Project. Confenis, 2006. In: Research
and Practical Issues of Enterprise Information Systems, New York: Springer-Verlag, 2006. pp.
677-682
CARDOSO, Jorge; BOSTROM, Robert P.; SHETH, Amit. Workflow Management Systems and
ERP Systems: Differences, Commonalities, and Applications. In: Information Technology
And Management, Springer Netherlands, p. 319-338. 01 jul. 2004.
CARVALHO, Rogerio Atem de. An Enterprise Content Management Solution Based on Open
Source. In: Research and Practical Issues of Enterprise Information Systems II. v. 1, New
YorK: Springer-Verlag, 2007. pp. 173-184
CARVALHO, Rogerio Atem de. Free/Open Source Enterprise Resources Planning. In: Jatinder
N. D. Gupta, Mohammad Abdur Rashid, Sushil K. Sharma. (Org.). Handbook of Research on
Enterprise Systems. Hershey, USA: Information Science Reference, 2008, p. 32-44.
CARVALHO, Rogerio Atem de; CAMPOS, Renato de. A Development Process Proposal for the
ERP5 System. In: IEEE International Conference on Systems, Man, and Cybernetics, New
York: IEEE Press, 2006.
64
CARVALHO, Rogerio Atem de; CAMPOS, Renato de; MONNERAT, Rafael Manhaes. ERP
System Implementation from the Ground up: The ERP5 Development Process and
Tools. In: Handbook of Research on Software Engineering and Productivity Technologies:
Implications of Globalization. IGI Global, 2009. pp. 423-438
CARVALHO, Rogerio Atem de; JOHANSSON, Björn, MANHAES, Rodrigo Soares. Agile
Software Development for Customizing ERPs. In: Enterprise Information Systems and
Implementing IT Infrastructures: Challenges and Issues. Hershey, PA, USA: Information
Science Reference, IGI Global, 2010. pp. 20-39
CARVALHO, Rogerio Atem de; MANHAES, Rodrigo Soares; SILVA, Fernando Luiz Carvalho e.
Introducing Business Language Driven Development. arXiv:1011.2238 [cs.SE]. 2010.
CARVALHO, Rogerio Atem de; MONNERAT, Rafael Manhaes. Development Support Tools for
Enterprise Resource Planning. IEEE IT Professional, v. 10, 2008. pp. 39-45
CARVALHO, Rogerio Atem de; MONNERAT, Rafael Manhaes. ERP5: Designing for Maximum
Adaptability. In: WILSON, Gregory ; ORAM, Andy (Comp.). Beautiful Code: Leading
Programmers Explain How They Think. Sebastopol: O’Reilly Media, 2007. p. 339-351.
CARVALHO, Rogerio Atem de; MONNERAT, Rafael Manhaes. Using Design Patterns for
Creating Highly Flexible Enterprise Information Systems. In: The III IFIP International
Conference on Research and Practical Issues of Enterprise Information Systems, IFIP Series,
2009.
CRISPIN, Lisa; GREGORY, Janet. Agile testing: A practical guide for testers and agile teams.
Boston: Addison-Wesley Professional, 2009. 576 p.
FERNANDES JÚNIOR, Geraldo Milton. Modelagem de um Sistema Workflow para uma Empresa
de Transporte Rodoviário de Cargas: UFLA, 2003. 58 p. (Dissertação – Graduação em
Ciência da Computação).
FOWLER, Martin et al. Refactoring: Improving the Design of Existing Code. Boston: Addison-
wesley Professional, 1999. 464 p.
HATHAWAY (Comp.). DCWorkflow Documentation. Disponível em:
<http://old.zope.org/Members/hathawsh/DCWorkflow_docs/default/DCWorkflow_doc.pdf>.
Acesso em: 01 fev. 2012.
IFIP – IFAC GERAM: Generalized Enterprise Reference Architecture and Methodology, In:
IFIP – IFAC Task Force on Architectures for Enterprise Integration, 1999.
KANNENBERG, Andrew; SAIEDIAN, Hossein. Why Software Requirements Traceability
Remains a Challenge. Crosstalk, Ogden, v. 22, n. 5, p.14-21, 2009.
MARTIN, Robert Cecil. The Truth About BDD. Disponível em:
65
<http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd>. 2008.
MELNIK, Grigori Igorovych. Empirical Analysis of Executable Acceptance Test Driven
Development. (Tese de Doutoramento) Department of Computer Science, University of
Calgary, Calgary, Alberta, 2007.
MONNERAT, Rafael Manhaes; CARVALHO, Rogerio Atem de; CAMPOS, Renado de.
Enterprise systems modeling: the ERP5 development process. In: Proceedings of 23rd
SYMPOSIUM ON APPLIED COMPUTING, v. II, New York: ACM, 2008. p. 1062-1068.
MUGRIDGE, Rick. Managing agile project requirements with storytest-driven development.
IEEE Software, v. 25, n. 1, 2008, p. 68–75.
NORTH, Dan. Introducing BDD. Better Software Magazine, New York, v. 8, n. 3, mar. 2006.
NUNES, Antonio Carlos; QUINTELLA, Heitor Luiz Murat de Meirelles; TELLES, Marcio S.
Sistemas de Informacoes Gerenciais (SIG) e a Competitividade em um Mercado
Globalizado. In: SIMPEP SIMPÓSIO DE ENGENHARIA DE PRODUÇÃO, XIII, 2006,
Bauru-SP. Anais… Bauru: 2006.
OMG OBJECT MANAGEMENT GROUP (Comp.) – BPMN Information. Disponível em:
<http://www.bpmn.org/Documents/FAQ.htm>. Acesso em: 12 jan. 2012.
OSOE (Comp.) – One Student One ERP. Disponível em: <http://www.osoe-project.org>. Acesso
em: 10 jan. 2012.
SCHWABER, Ken. Agile Project Management with Scrum: Microsoft Professional. Redmond,
Washington: Microsoft Press, 2004. 192 p.
SMETS-SOLANES, Jean Paul; CARVALHO, Rogerio Atem de. ERP5: A Next-Generation, Open-
Source ERP Architecture. It Professional, New York, p. 38-44. jul. 2003.
SOLIS, Carlos; WANG, Xiaofeng. A Study of the Characteristics of Behaviour Driven
Development. 37th Euromicro Conference On Software Engineering And Advanced
Applications, Oulu, Finland, p. 383-387. ago. 2011.
SOMMERVILLE, Ian. Engenharia de Software. 8 ed. São Paulo: Pearson, 2007. 568 p.
SOUZA, Cesar Alexandre de. Sistemas Integrados de Gestão Empresarial: Estudos de Caso de
Implementação de Sistemas ERP. (Mestrado em Administração). São Paulo: Faculdade de
Economia, Administração e Contabilidade/Universidade de São Paulo, 2000. 253 p.
VON WEITERSHAUSEN, Philipp; EBY, Phillip J. Web Component Development with Zope
3. 3. ed. Boston: Springer, 2008. 582 p.
WAGNER, Ferdinand. SCHMUKI, Ruedi. WAGNER, Thomas. WOLSTENHOLME,
Peter. Modeling Software with Finite State Machines: A Practical Approach. New York:
Auerbach Publications, 2006. 392 p.
66
WOMACK, James P.; JONES, Daniel T.; ROOS, Daniel. The Machine That Changed the
World: The Story of Lean Production. New York: Free Press, 2007. 352 p. Toyota's Secret
Weapon in the Global Car Wars That Is Now Revolutionizing World Industry.
ZOPE FOUNDATION. Zope Transactions. Disponível em:
<http://old.zope.org/Members/mcdonc/HowTos/transaction>. Acesso em 12 fev. 2012.
ZOPE FOUNDATION. Zope Object Database. Disponível em: <http://www.zodb.org>. Acesso
em: 10 jan. 2011.