PROPOSTAS PARA O PROCESSO DE DESENVOLVIMENTO DO SISTEMA ERP5

Texto

(1)

(2)

(3)

(4) !"#$" %'&)(*&)+,.- /10.2*&4365879&4/1:.+58;.2*<>=?5.@A2*3B;.- C)D 5.,.5FE)5.G.+&4- (IHJ&?,.+/?<>=)5.KA:.+5MLN&OHJ5F&4E)2*EOHJ&)(IHJ/)G.- D - ;./);.& Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. PROPOSTAS PARA O PROCESSO DE DESENVOLVIMENTO DO SISTEMA ERP5 Rogério Atem de Carvalho (CEFETCampos) ratem@cefetcampos.br Renato de Campos (UNESP) rcampos@feb.unesp.br. Modelar sistemas de ERP significa capturar a informação necessária para suportar o gerenciamento da empresa. Este processo de modelagem passa por diferentes níveis de abstração, da modelagem dos negócios da empresa até a geração de códigos.. Então, ERP é um tipo de sistema onde a engenharia de empresa indubitavelmente tem, ou deveria ter, uma grande influência. Para o caso dos ERP de código aberto, a falta de métodos adequados e ferramentas de modelagem e desenvolvimento podem inviabilizar as vantagens oferecidas pela disponibilidade do código, como no caso do ERP5, um ERP de código aberto. O objetivo principal deste artigo é apresentar algumas propostas para o processo de desenvolvimento do ERP5, que suportem diferentes níveis de abstração, levando em consideração padrões e boas práticas de modelagem de negócios e de engenharia de sistemas. Este processo tem como objetivo embutir todo o conhecimento necessário para tornar o desenvolvimento de uma nova instância do sistema o mais sistemática e automatizada possível. Palavras-chaves: ERP, software livre, desenvolvimento de software, modelagem de empresas.

(5) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. 1. Introdução ERPs de código aberto vêm ganhando aceitação cada vez maior pelo fato de não imporem pagamento de licenças. Outra razão é que, sendo a customização uma atividade inevitável no emprego desses sistemas, por que não adotar uma solução que expõe o seu código para que a empresa possa adaptar livremente o sistema a suas necessidades? Assumindo que melhorias e mudanças nos processo de negócios são constantes, são também as mudanças nos códigos dos ERP, de forma a não comprometer as vantagens competitivas. Em resumo, duas vantagens atraem empresas para os ERP de código aberto: diminuição de custos e total acesso ao código de aplicativos (DREILING et al., 2005). O objetivo final no desenvolvimento de um sistema ERP é, partindo do mais alto nível de abstração considerado através da modelagem dos processos de negócios da empresa, atingir a geração de códigos correspondentes. Em outras palavras, a situação ideal é garantir que o software esteja em completa conformidade com os requisitos do negócio (CAULLIRAUX et al., 2000; KOSANKE; NELL, 1999). Para isto, uma arquitetura de referência para a definição de uma metodologia de desenvolvimento, aliada a adequadas técnicas de documentação dos requisitos de negócios e de software por meio de modelos, são essenciais para os ERP de código aberto, já que os usuários deverão se basear nessa metodologia e nesses documentos para a customização/adaptação do sistema. Para conseguir isto, é necessário definir métodos e ferramentas para facilitar a modelagem e garantir qualidade em cada nível de abstração do processo de desenvolvimento . Neste sentido, uma arquitetura de referência que contemple de forma adequada todos os aspectos dos processos de negócio, incluindo aspectos relacionados ao desenvolvimento de software, facilita o reuso, melhor funcionamento, melhor performance, e um melhor entendimento do sistema, evitando perda de tempo e recursos (ERIKSSON; PENKER, 2000). O ERP5 é um projeto de ERP de código aberto que visa oferecer uma solução de alta tecnologia e baixo custo (http://www.erp5.org), sendo desenvolvido atualmente por um grupo de empresas e instituições de ensino e pesquisa da Europa – notadamente da França, onde surgiu - e Brasil. Este sistema utiliza a plataforma Zope e é totalmente baseado em objetos, workflows e tecnologias Web. Seu principal objetivo é desenvolver e projetar um grupo compreensível de componentes de software para ERP e fornecer informações suficientes para permitir que, incluindo pequenas e médias empresas, as organizações tenham liberdade para alterar a forma de funcionar do sistema da maneira que melhor lhe convier. Em conseqüência oferece uma solução de baixo custo e cuja tecnologia se manterá atual por vários anos (SMETS-SOLANES; CARVALHO, 2002; 2003). O ERP5 usa o Zope (www.zope.org) como núcleo de seus desenvolvimentos. Zope é um servidor de aplicações e sistema de gerenciamento de conteúdo Open Source baseado em Python. Zope roda sobre a maioria dos sistemas operacionais (Linux, FreeBSD, Unix, MacOS X, Windows, etc.). Esta plataforma possui as seguintes características tais como:Banco de dados orientado a Objeto; Publicação de Objetos; e Listas de Controle de Acesso O objetivo deste artigo é descrever proposas para o processo de desenvolvimento para o ERP5, que é baseado no ciclo de vida da arquitetura de GERAM. Então, nas próximas seções apresentam-se brevemente a metodologia e a arquitetura GERAM, e os métodos e ferramentas propostos para o processo de desenvolvimento, seguido por algumas considerações finais.. 2.

(6) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. 2. A Metodologia e Arquitetura GERAM A arquitetura GERAM – Generalized Enterprise Reference Architecture and Methodology é uma generalização da GIM, da PERA e da CIMOSA, e se utiliza das melhores partes dessas arquiteturas com o intuito de servir como referência para todos os envolvidos na área de engenharia e integração de empresa (IFIP-IFAC, 1999). Ela visa fornecer um conjunto de conhecimentos e componentes necessários para a engenharia de sistemas de empresa. GERAM fornece uma descrição de todos os elementos recomendados na engenharia e integração de empresas e assim prepara o padrão para a coleção de ferramentas e métodos da qual qualquer empresa se beneficiaria com mais sucesso ao cuidar do projeto de integração. Ela não impõe uma coleção de ferramentas ou métodos em particular, mas define critérios a serem satisfeitos por qualquer coleção de ferramentas e métodos selecionados. GERAM considera modelos de empresas como um componente essencial para a integração e engenharia de empresas; isto inclui várias técnicas formais de descrição de projetos – como modelos computacionais, textuais e gráficos para representações do projeto. A estrutura GERAM identifica em seu componente mais importante a Arquitetura de Referência de Empresas Generalizada (GERA - Generic Enterprise Reference Architecture) os conceitos básicos a serem usados na integração e engenharia de empresas (por exemplo, entidades de empresa, ciclos-de-vida e histórias de vida de entidades de empresa). GERA provê uma estrutura de análise e modelagem que é baseada no conceito de ciclo-de-vida conforme a Figura 1. 9\\ISOS** *S kS)SI YI*~I\ SS¡¢S YI*~I\AI S£k. YM>u. 9¡¢k S¡¢U* ¤ I* SMk. Figura 1 – Ciclo de vida de GERAM (Fonte: IFIP-IFAC, 1999).. GERAM faz distinção entre as metodologias para engenharia de empresas (EEMs – Enterprise Engineering Methodology) e as linguagens de modelagem (EMLs – Enterprise Modeling Languages) que são usadas pelas metodologias para descrever e modelar, a estrutura, conteúdo e comportamento das entidades de empresas em questão. Estas linguagens permitirão a modelagem da parte humana na operação da empresa assim como partes dos processos da empresa e suas tecnologias de suporte. O processo de modelagem produz modelos de empresas (EMs – Enterprise Models) que representam todas ou parte das operações da empresa, incluindo suas tarefas de produção ou de serviço, sua organização e seu gerenciamento, e seu controle e sistemas de informação. Estes modelos podem ser usados para guiar a implementação de sistemas operacionais da empresa (EOSs – Enterprise. 3.

(7) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. Operational Systems) assim como melhorar a habilidade da empresa para avaliar alternativas operacionais ou organizacionais (por exemplo, por simulação), e assim aumentar seu desempenho atual e futuro. A metodologia e as linguagens usadas para a modelagem de empresas são apoiadas por ferramentas de engenharia de empresas (EETs – Enterprise Engineering Tools). A semântica das linguagens de modelagem pode ser definida através de ontologias, meta modelos e vocabulários que são coletivamente chamados conceitos de modelagem de empresas genéricos (GEMCs – Generic Enterprise Modelling Concepts). O processo de modelagem é aprimorado pela utilização de modelos parciais (PEMs – Partial Enterprise Models) que são modelos reutilizáveis de funções humanas, processos e tecnologias. O uso operacional de modelos de empresa é apoiado através de módulos específicos (EMOS – Enterprise Modules) que fornecem produtos pré-fabricados como perfis de habilidades humanas para profissões específicas, procedimentos empresariais comuns (por exemplo, regras de imposto e de contabilidade) ou seus serviços de infra-estrutura, ou qualquer outro produto que pode ser usado como um componente na implementação do sistema operacional (EOSs – Enterprise Operational Systems) (IFIP-IFAC, 1999). No projeto ERP5 é proposto que a metodologia, ou processo, de desenvolvimento seja estruturada conforme a arquitetura de referência GERA. E para detalhar as atividades em cada fase do ciclo de vida da metodologia, devem ser usadas como base as atividades do Processo Unificado (Unified Process - UP) (JACOBSON, et al., 1999; KRUCHTEN, 2003; OMG, 2005) que são focadas no desenvolvimento de software, complementadas com técnicas de modelagem de processos de negócios de empresas, além de técnicas e ferramentas específicas para o ERP5. Estas propostas são detalhadas nas seções seguintes, e são referentes principalmente às fases de Requisitos, Projeto e Implementação do ciclo de vida de GERA. 3. Propostas para a fase de Requisitos No caso de um software de gestão de empresas, é interessante incluir na metodologia de desenvolvimento, conceitos e métodos de modelagem de empresas para melhor capturar aspectos e requisitos da organização, como os relacionados a sua estrutura, aos processos e os recursos de manufatura. Assim, junto às atividades dos worflows do UP (Processo Unificado), propõe-se um workflow específico para a modelagem de negócios, que se concentra na modelagem das vistas de função, informação, recursos e organização da empresa, de acordo com a estrutura de modelagem GERAM, e a ser empregada basicamente na fase de Requisitos. O Workflow de Negócios (Figura 2), adaptado de CIMOSA (KOSANKE et al., 1999) e de Eriksson e Penker (2000), consiste das seguintes atividades: - Modelagem dos objetivos da empresa (aspectos estratégicos): a modelagem dos objetivos deve identificar os principais objetivos e sub-objetivos do negócio numa estrutura hierárquica que permita a visualização de dependência entre tais objetivos. Este modelo servirá de base para a definição dos processos de negócio. A modelagem dos objetivos do negócio deve ser feita com base em entrevistas realizadas com os conhecedores do negócio. - Modelagem dos processos da empresa (aspectos comportamentais): Os processos de negócio devem ser definidos buscando a realização dos objetivos identificados no Modelo de Objetivos do Negócio. Porém, não é necessário haver uma relação 1 para 1 entre processos de negócios e objetivos do negócio pois muitos processos auxiliares não estarão necessariamente relacionados a um objetivo do Modelo de Objetivos do Negócio. Entrevistas com os envolvidos no negócio também devem ser realizadas para fornecer subsídios à definição dos processos de negócio.. 4.

(8) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. Modelagem das Informações. Modelagem dos Objetivos. Modelagem dos Processos. Modelagem das Atividades. Modelagem dos Recursos. Modelagem da Organização. Figura 2 - Workflow de Negócios. - Modelagem das atividades da empresa (aspectos funcionais): refere-se a descrição detalhada das atividades da empresa levantadas no passo anterior. A análise das atividades possibilita a identificação das informações (documentos) e recursos materiais ou humanos (incluindo suas capabilidades) necessários e utilizados na operação da empresa. Isto permite a identificação de todas as fontes e pontos de consumo de objetos. A derivação de objetivos e restrições para a atividade de empresa orienta a identificação do conjunto de capabilidades necessárias para a transformação dos objetos de entradas em objetos de saídas. Entradas e saídas de recursos e entradas e saídas de controle complementam a descrição da atividade de empresa fornecendo informação para a sua execução ou identificando informação criada no curso de seu processamento. Inicialmente, pode se identificar apenas as capabilidades de recursos, as quais identificam as características e necessidades funcionais, e em numa fase posterior, os recursos, que possuem as capabilidades levantadas, são definidos. A definição de estados finais fornece informações sobre o término da atividade de empresa para o processamento do conjunto de regras de comportamento, as quais controlam a continuidade de processos. - Modelagem de Informações, Recursos e Organização: as unidades organizacionais, os recursos e as informações identificadas nas atividades de modelagem anteriores devem ser modelados, em detalhes através de gabaritos, e em suas respectivas estruturas através dos diagramas de estrutura. A modelagem destes elementos deve ser feita de forma paralela, após a atividade de modelagem de processos e de atividades a fim de se ter um melhor entendimento dos termos relacionados ao negócio e conseqüentemente uma maior consistência na modelagem do mesmo. Os objetos (de entradas e saídas das atividades de empresas) relevantes são descritos através de seus atributos. Objetos de empresas e seus relacionamentos são definidos e arranjados em estruturas hierárquicas de objetos. Seguindo uma análise similar, são estabelecidas ambas as vista de recursos (descrição de capabilidades e recursos) e vista de organização (responsabilidades e autoridades para unidades de organização e células de organização). Nestas duas vistas, estruturas hierárquicas podem ser projetadas tanto para os recursos como para a organização da empresa. As informações relativas aos vários aspectos da empresas levantadas com o workflow de Negócios são consolidadas em termos de requisitos para o sistema de informação e implementadas (neste caso no ERP5) através das atividades seguintes da metodologia. 4. Propostas para a fase de Projeto Dentro da fase de Projeto, é necessário definir um método para transformar modelos em código fonte. Em outras palavras, definir um conjunto de atividades que se encarregaram de transformar modelos estruturais e comportamentais em código fonte que refletirá os requisitos do negócio. Este método deve ser empregado pelos workflows de Elaboração do UP, sendo,. 5.

(9) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. portanto, conceitualmente parte da fase de Design do GERAM. Para esta tarefa é sugerido o emprego do Workflow, Object Oriented Method (WOOM) (CARVALHO, 2005). Este método leva em consideração que a plataforma de software em consideração suporta uma linguagem orientada a objetos e uma máquina de workflow baseada em estados. Embora o método tenha sido criado para uso genérico, se encaixa perfeitamente no ambiente Zope sobre o qual o ERP5 se baseia. WOOM emprega um conjunto mínimo de artefatos UML e introduz um novo artefato denominado Tabela WARC, que significa Workflow – Action/Reaction – Responsible – Collaborators. Este artefato é empregado para associar estrutura (atributos e associações das classes) a comportamento (operações e métodos). Um conjunto mínimo de artefatos é considerado como um grupo de artefatos de modelagem suficiente para modelar ambos estrutura e comportamento do sistema, tendo exatamente um único artefato para modelar cada nível de abstração do sistema de informação. A Figura 3 mostra os passos gerais de modelagem para um processo de negócio, coerentemente representado por um Diagrama de Estados UML, descrito a seguir.. Identificando Documentos do Processo. Identificando Classes do Processo. Escrevendo Use Case de Duas Colunas. Escrevendo Contratos. Preparando Tabela WARC. Projetando Diagrama de Estados. Figura 3 - Diagrama de Estados do WOOM. 4.1 Identificando documentos do processo Documento é o termo geral empregado para descrever a interface entre usuários e sistema. Podem ser então documentos de papel, ou telas de um protótipo do sistema. Utilizando estes documentos, os dados manipulados pelo processo de negócio são identificados. 4.2 Identificando classes do processo Os dados definidos no estado anterior são associados às entidades de negócio ou, na terminologia da orientação a objetos, classes, que participam do processo. É importante notar que este estado e o anterior podem ser suprimidos dependendo do nível de detalhamento que foi empregado na modelagem de negócio. Neste ponto, um Diagrama de Classes começa a ser definido para o processo, ou então o Diagrama de Classes do sistema é alterado para refletir as novas classes, relações ou atributos. 4.3 Escrevendo use cases de duas colunas Da modelagem de negócios e/ou de entrevistas com os usuários especialistas, um Use Case (UC) é construído. Este UC emprega uma coluna para descrever as ações do(s) ator (es) e outra coluna para definir as reações do sistema. 4.4 Projetando diagrama de estados No diagrama de estados, os nomes dos estados correspondem ao estado do processo em um momento particular. Do UC, verbos na coluna de ação identificam transições de estados, na coluna de reação, ações internas dos estados. A Figura 4 mostra um exemplo de uma linha de UC e sua representação no diagrama de estados.. 6.

(10) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. 4.5 Preparando tabela WARC A Tabela WARC garante o encapsulamento ao unir estrutura (atributos) ao comportamento (operações/métodos), através da definição das responsabilidades das classes e suas colaboradoras na execução dessas responsabilidades. Uma Tabela WARC toma cada ação e reação, associa-a a uma classe previamente identificada e define quais classes irão colaborar na realização desta tarefa específica no workflow. Transições se tornarão operações públicas, atividades de estado se tornarão operações privadas ou protegidas, evoluindo o Diagrama de Classes gradativamente. De fato, este diagrama evoluí durante todo o processo. No exemplo da Figura 4, a Tabela WARC teria uma linha com insereNovoItem() com a ação/reação (neste caso específico, reação), a classe Venda como responsável e a classe Item como colaboradora. 4.6 Escrevendo contratos O estado final do processo trata de definir um contrato (MEYER, 1992) para cada ação e reação. Um contrato determina o que cada operação de classe deve fazer, garantindo, no conjunto de operações, que os requisitos funcionais estabelecidos para o workflow sejam seguidos. Normalmente contratos são escritos utilizando pseudo-código, podendo possuir diagramas que auxiliem sua compreensão também. Neste ponto é interessante discutir brevemente sobre o uso de máquinas de estado para descrever workflows, já que há uma tendência de empregar Diagramas de Atividades, que evoluíram de uma derivação dos Diagramas de Estados para uma derivação de Redes de Petri (OMG, 2005), tendência verificada por alguns pesquisadores mesmo antes do lançamento da UML 2.0 (DELATOUR; LAMOTTE, 2003). Por um outro lado, o processo proposto deve usar máquinas de estado porque a plataforma de software o faz. Adicionalmente, é razoável utilizar Diagramas de Atividades para modelar processos de negócio na fase de requisitos e então Diagramas de Estados na fase de projeto. Ação do Ator Reação do S istem a Seleciona um item para ser incluído Obtém o OID do item e insere na na venda atual. lista de itens da Venda.. incluiItem ( ). Incluindo Item entry/ insereNovoItem( ). Figura 4 - Transformação de uma linha do Use Case em uma transição e estado. Finalmente, na maioria das vezes a tradução de máquinas de estados para Redes de Petri é direta (VAN DER AALST, 2004). Deste ponto de vista, é então legítimo considerar que estados e suas atividades internas podem representar a maioria dos workflow patterns. Mais ainda, há uma grande quantidade de ferramentas e métodos para validar matematicamente workflows baseados em estados (KNAPP; MERZ, 2002; LATELLA et al. 1999; LILIUS; PALTOR, 1999), o que reduz enormemente os custos de testes de sistema.. 7.

(11) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. 5. Propostas para a fase de Implementação Para suportar a fase de implementação, um conjunto de ferramentas foi definido. Essas ferramentas visam aumentar a qualidade e produtividade do processo de desenvolvimento, através da automatização de uma série de tarefas, sendo relacionadas simultaneamente ao processo (de desenvolvimento) e ao produto (de software – uma instância ERP5). 5.1 Ferramenta de groupware Em todo projeto duas importantes disciplinas são a comunicação e a gestão da documentação do projeto, que podem ser automatizadas por ambientes de groupware, que integram gestão de documentos, email, forums, mailing lists, calendários e workflow. Uma ferramenta denominada ERP5 Groupware foi criada para funcionar tanto quanto uma base para uma ferramenta de gerência de projetos quanto para uso geral. Ela emprega um poderoso mecanismo de busca full-text, que permite que qualquer usuário autorizado possa buscar e acessar objetos por seu conteúdo e tipo. Adicionalmente, os objetos são gerenciados através de workflows com acesso controlado por um sistema de segurança integrado. 5.2 Ferramenta de gerenciamento de projetos Para suportar as tarefas relacionadas à gerência do processo de customização de uma instância ERP5, uma ferramenta denominada ERP5ProjMan está sendo desenvolvida. Suas principais características são: − Plotagem de Gráficos de Gantt e de Recursos. − Módulos de Métricas de Esforço plugáveis. − Emprego de workflows customizáveis. − Organização de modelos de documentos de acordo com sua área de conhecimento dentro do PMBOK (PMI, 2004) e associação de documentos dependentes, para facilitar o controle de mudanças. − Suporte ao Controle de Mudanças. − Funcionalidades de planejamento de custos e tempos. No momento os três primeiros itens já estão implementados. Esta ferramenta possui um uso dual dentro do ERP5: (i) de forma reflexiva, suportando o processo de criação de uma nova instância ERP5 e (ii) como um módulo de gerenciamento de projetos. 5.3 Ferramenta de geração de código Geração de código é uma das técnicas empregadas para reduzir tempos e custos na construção de sistemas de informação. O ERP5 Generator é uma ferramenta que gera os elementos estrutural (classes), comportamental (workflows) e interfaces gráficas com o usuário empregando como base os Diagramas de Classes e Estados e as Tabelas WARC do Método WOOM. O ERP5 Generator analisa arquivos padrão XMI exportados por ferramentas CASE para gerar código, restando ao programador codificar apenas os algoritmos da aplicação e garantindo que o que foi especificado nos modelos está matematicamente garantido no código. 6. Considerações Finais Este trabalho apresenta uma visão resumida do processo proposto, que, embora ainda em desenvolvimento, já supre os métodos e ferramentas para desenvolvimento no ERP5 baseado em melhores práticas e ferramentas de produtividade. Algumas das técnicas e ferramentas propostas são bem estabelecidas, e outras foram especificamente desenvolvidas ou adaptadas. 8.

(12) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. para o ERP5. Este processo tem como objetivo embutir todo o conhecimento necessário para tornar o desenvolvimento de uma nova instância do sistema o mais sistemática e automatizada possível. É importante notar que o processo proposto pode ser empregado no desenvolvimento de outros softwares e além disso não é um imperativo para os desenvolvedores do ERP5, dado que alguns preferem empregar métodos ágeis ou particulares. Referências CAULLIRAUX, H. M.; PROENÇA A.; PRADO, C. S., ERP Systems from a Strategic Perspective, in Proc. 6th International Conference on Industrial Engineering and Operations Management, Niterói, Brasil, 2000. CARVALHO R. A. Dispositivo e Método para Modelagem de Sistemas de Informação, Patente Pendente INPI PI0501998-2, 2005. DELATOUR, J.; DELAMOTTE, F. ArgoPN: A CASE Tool Merging UML and Petri Nets, in Proc. 1st International Workshop on Validation and Verification of Software for Enterprise Information Systems, Angers, France, 2003, pp. 94-102. DREILING, A.; KLAUS, H.; ROSEMANN, M.; WYSSUSEK, B. Open Source Enterprise Systems: Towards a Viable Alternative, in Proc. 38th Annual Hawaii Inter. Conference on System Sciences, Hawaii 2005. ERIKSSON, H. E.; PENKER, M. Business Modeling with UML. New York: John Wiley & Sons, 2000. IFIP – IFAC. GERAM: Generalized Enterprise Reference Architecture and Methodology, IFIP – IFAC Task Force on Architectures for Enterprise Integration, 1999. JACOBSON, I., BOOCH, G., RUMBAUGH, J.. The Unified Software Development Process. Addison Wesley, 1999. KNAPP, A.; MERZ, S. Model Checking and Code Generation for UML State Machines and Collaborations, in Proc. 5th Workshop on Tools for System Design and Verification, Augsburg, 2002. KOSANKE, K.; VERNADAT, F.; ZELM M. CIMOSA: Enterprise Engineering and Integration, Computers in Industry, vol.40, n. 2, pp. 83-97, 1999. KOSANKE, K.; NELL, J. G. Standardisation in ISO for Enterprise Engineering and Integration, Computers in Industry, vol. 40, n. 2, pp. 311-319, 1999. KRUCHTEN, P. Introdução ao RUP – Rational Unified Process, Rio de Janeiro: Editora Ciência Moderna Ltda., 2003. LATELLA, D.; MAJZIK, I.; MASSINK, M. Automatic Verification of a Behavioral Subset of UML Statechart Diagrams Using the SPIN Model-Checker, Formal Aspects in Computing, vol. 11, n. 6, pp. 637–664, 1999. LILIUS, J.; PALTOR, I. P. Formalizing UML State Machines for Model Checking, in Proc. 2nd Int. Conf. in UML, Berlin, 1999. MEYER B. Applying Design by Contracts, IEEE Computer, vol. 25, n. 10, 1992. OMG UML 2.0 Superstructure Specification, OMG Standard, 2005. PMI Guide to The Project Management Body of Knowledge – PMBOK, PMI, 2004. SMETS-SOLANES J-P.; CARVALHO R. A. ERP5: A Next-Generation, Open-Source ERP Architecture, IEEE IT Professional, vol. 5, pp. 38-44, Jul. 2003. SMETS-SOLANES J-P.; CARVALHO R. A. An Abstract Model for An Open Source ERP System: The ERP5 Proposal, in Proc. 8th International Conference on Industrial Engineering and Operations Management, Curitiba, Brasil, 2002. VAN DER AALST, W.; VAN HEE, K. Workflow Management, Cambridge: MIT Press, 2004.. 9.

(13)