Renato Flórido Cameira (UFRJ) Fernanda Challhoub (UFRJ) Leonardo Vicente (UFRJ)

Transcrição

1 Engenharia de Processos e Engenharia de Sistemas: construindo Arquiteturas Integradas de Sistemas Componentizados a partir da concepção dos processos de negócio com uso de UML Renato Flórido Cameira (UFRJ) cameira@gpi.ufrj.br Fernanda Challhoub (UFRJ) fernanda@gpi.ufrj.br Leonardo Vicente (UFRJ) leonardo@gpi.ufrj.br Resumo Com o desenvolvimento e integração dos conceitos e das ferramentas utilizadas pela Engenharia de Processos de Negócios e pela Engenharia de Sistemas, deve-se pensar a concepção, desenvolvimento, implantação, operação e manutenção de uma Arquitetura Integrada de Sistemas, crescentemente baseada em componentes de software, de forma intrinsecamente alinhada aos requerimentos do negócio. Este artigo aborda aspectos metodológicos relacionados à conexão entre a EPN e a Engenharia de Sistemas, destacando a utilização, neste contexto, da UML na integração da visão do negócio, expressa crescentemente em componentes de processo, à construção do sistema, realizado por componentes de software. Aspectos associados aos reflexos desta conexão na flexibilidade e nos tempos de resposta, de (re)adequação, das organizações e das cadeias onde as organizações operam, às variações do ambiente competitivo, são brevemente abordados.. Palavras chave: Engenharia de Processos de Negócio, Componentização de Sistemas, UML 1. Introdução Desde suas primeiras versões, as ferramentas de modelagem que apóiam a Engenharia de Processos de Negócios (EPN), de uma forma ou de outra, buscam a partir da visão do negócio alcançar a efetiva implementação do processo, chegando à construção de sistemas de informação. Ao passo que a EPN e as ferramentas de modelagem de processos foram eficientes em levantar, modelar e redesenhar processos, a implementação efetiva de sistemas de informação, diretamente a partir dos processos, tem apresentado limitações. Por outro lado, as ferramentas CASE (Computer Aided System Engeneering), partindo das visões de modelos de dados como os Diagramas de Entidade e Relacionamento, Diagramas de Fluxos de Dados etc., buscam construir sistemas que suportem os processos. O objetivo principal de um CASE é separar o projeto do programa aplicativo da implementação do código (FISHER, 1990, p. 5). As ferramentas CASE apóiam os desenvolvedores de sistemas justamente nas fases de Análise de Requisitos e Especificação do Projeto do programa (CAMEIRA, et al, 2002). São nestas duas primeiras fases, preliminares ao desenvolvimento dos códigos, gerados em grande parte automaticamente, que a Engenharia de Sistemas toca a EPN. ENEGEP 2003 ABEPRO 1

2 2. Engenharia de Processos e Engenharia de Sistemas Pensando-se de forma integrada poderíamos descrever um modelo de desenvolvimento de software a partir do desenvolvimento dos processos que visam realizar os objetivos derivados da estratégia segundo a Figura 1: Conceitos do Negócio, Alinhados à estratégia Definição dos Requerimentos Fonte: (Adaptado de Cameira, 2003, p.320) Análise dos Requisitos Especifi cação do Projeto Concepção (conceitual) dos Sistemas de Informação Implementação (desenv. Automático de código) Integração e Teste Operação e Manutenção Figura 1: Desenvolvimento de Sistemas Norteado por Processos A EPN procura conceber o sistema a partir do entendimento e concepção do negócio. A Engenharia de Sistemas procura entender o negócio para aprimorar a análise de requisitos, preliminar à especificação do projeto. Há, hoje, desenvolvimento das capacidades das ferramentas de modelagem de processos e o desenvolvimento da tecnologia de Engenharia de Sistemas. Uma metodologia que vise a construção de uma Arquitetura Integrada de Sistemas (AIS) deve considerar o entendimento e a (re)construção de processos a partir da EPN. Antes, deve estar sintonizada com os objetivos do negócio, com a estratégia da organização. Deve estar atrelada à estrutura de indicadores que deverão estar associados a esta estratégia, para monitorar o desenvolvimento dela, até o nível de processos. Particularmente, deve-se pensar a reestruturação completa do design de sistemas de uma organização de forma a facilitar sua transição para um e-business, aqui entendido como a organização apoiada, em sua realização, através de processos crescentemente (hiper)integrados baseados na Tecnologia da Informação (TI). Várias são as vantagens da utilização de ferramentas de apoio à modelagem de processos. No caso particular da modelagem de processos com vistas à uma AIS componentizada, destacamse aquelas ferramentas com capacidade de modelar dados através de UML. Uma ferramenta de modelagem deverá auxiliar em vários aspectos a construção de uma AIS: Formalização e padronização da modelagem de processos; Armazenamento de representações reutilizáveis de processos; Apoio à melhoria dos processos e do desenvolvimento de sistemas de suporte à operação; Maior facilidade para o gerenciamento dos processos; Aceleração da capacidade de desenvolvimento e de adequação dos sistemas que suportam os produtos e serviços; Aumento da flexibilidade frente às variações da demanda; Melhoria das interfaces processuais (BASTOS & CAMEIRA, 2000; CAMEIRA & CAULLIRAUX, 2000; CAULLIRAUX & CAMEIRA, 2000; CAULLIRAUX, PROENÇA & PRADO, 2000; SANTOS, 2002; SANTOS & CAMEIRA, 2001; SCHEER, 1998 e KIRCHMER, 1998). Entendidos estes aspectos, é necessário claramente compreender o que significa a componentização de processos e como construir sistemas componentizados a partir de uma representação de processos, de forma facilitada pelo uso de ferramentas específicas. 3. Componentização de Processos Construir sistemas componentizados apoiado por ferramentas de representação de processos requer o entendimento componentizado dos processos. Ao se componentizar as representações de processos, pode-se observar que algumas atividades, ou alguns pedaços de processos que compõem um sub-processo ou um processo menor são com certeza semelhantes; algumas atividades ou sub-processos, com certeza idênticos e outras atividades ou sub-processos são parcialmente semelhantes ou potencialmente iguais (ou diferentes). Estas atividades, isoladamente ou em processos bem definidos, ao se conceber um sistema componentizado (por exemplo, de monitoração da produção), deverão gerar componentes ENEGEP 2003 ABEPRO 2

3 capazes, pelas características das aplicações e padrões de integração, de facilmente se conectarem, independentemente do fornecedor de software ou de linguagem de programação, por exemplo. As atividades ou os sub-processos iguais gerarão apenas um componente que será reutilizado nos diversos processos. Por exemplo, um componente afeto ao controle do acionamento da envasadora. As atividades ou sub-processos diferentes, com atributos diferentes, gerarão em um primeiro momento um componente utilizado em apenas um dos processos, mas, pelas características de construção, quando traduzidos em componentes de software, potencialmente reutilizáveis. As atividades ou sub-processos parcialmente semelhantes ou potencialmente iguais (ou potencialmente diferentes) na verdade podem representar, ao analisar diversos processos, a necessidade de ajuste no grau de agregação dos processos. Este grau de agregação será limitado pela capacidade de, em certo nível, uma atividade ou conjunto de atividades formando um sub-processo de conter todos os atributos que plenamente o definem, com vistas à construção de um sistema, no caso, de um componente de um sistema. 4. Componentização de Processos e de Sistemas e a UML Portanto, ao se componentizar processos, facilita-se fortemente a aplicação das técnicas de componentização de sistemas. Em uma visão simplificada, significa dizer que cada componente de processo terá relação com o componente (ou conjunto de componentes) de sistema que viabilizam o (uma parte do) sistema que apóia a realização daquele processo componentizado. As aplicações desdobradas da EPN estão crescentemente ligadas ao uso da TI, destacando o apoio à implantação de SIGs e o projeto de Sistemas de Informação, de maneira ampla. Conforme a EPN e a Engenharia de Sistemas se aproximam em objetivos, o uso das ferramentas de modelagem crescentemente reflete isto, incorporando e inter-relacionando modelos associados originalmente à EPN e às ferramentas de especificação e construção de sistemas. A representação da passagem processos-sistema é realizada, crescentemente, pelos modelos da UML, que fazem o link entre os processos que representam as regras de negócio (no passado trabalhadas de forma desatrelada ou mal atrelada à concepção do modelo de negócio da organização) e a análise de sistemas e seus códigos fontes derivados. UML é uma notação: um modo de documentar especificações de sistemas (KULAK & GUINEY, 2000). A UML em uma definição completa de seus criadores (RUMBAUGH, JACOBSEN & BOOCH, 1999, p. 3) é: UML é uma linguagem de modelagem de propósito geral que é usada para especificar, visualizar, construir e documentar os artefatos de um sistema de software. Ela captura decisões e entendimentos sobre sistemas que devem ser construídos. É usada para entender, desenhar, pesquisar, configurar, manter e controlar a informação sobre certo sistema. Objetiva ser utilizada por todos os métodos de desenvolvimento, estágios do ciclo de vida e domínios de aplicações e mídias. É uma linguagem de modelagem que objetiva unificar a experiência passada sobre técnicas de modelagem e incorporar as atuais melhores práticas em uma abordagem padrão. UML inclui conceitos de semântica, notação e linhas mestras. Possui partes estática, dinâmica, ambiental e organizacional. Objetiva ser suportada por ferramentas de modelagem visuais que possuam geradores de código e de relatórios. A UML não define um processo padrão mas objetiva ser útil em um processo interativo de desenvolvimento. Busca suportar a maioria dos processos de desenvolvimento orientados a objetos. ENEGEP 2003 ABEPRO 3

4 E acrescentam: A UML captura informação sobre a estrutura estática e o comportamento dinâmico de um sistema. O sistema é modelado como uma coleção de objetos discretos que interagem de forma a realizar trabalho que em última instância beneficia um usuário externo. A estrutura estática define os tipos de objetos importantes para um sistema e para sua implementação, bem como as relações através dos objetos. O comportamento dinâmico define a história de um objeto no tempo e a comunicação entre objetos de forma a alcançar suas metas. Modelar um sistema de diversos e relacionados pontos de vista permite seu entendimento para diferentes propósitos. Desta definição deve-se destacar que ela informa a utilidade da UML à componentização de sistemas, trabalhando objetos e suas relações e observa que deve ser apoiada por ferramentas de modelagem. Diversos são os modelos da UML. O Quadro 1 apresenta brevemente os principais, classificando segundo suas grandes áreas, vistas e diagramas/ modelos (que realizam estas vistas). Grande Área Casos e Uso, Ator, Associação, Extensão, Inclusão, Generalização Estrutural Dinâmica Vista Diagramas Principais Conceitos Vista Estática - Esta visão é dita estática, pois não descreve a relação de comportamento do sistema no tempo. Vista de Casos e Uso - Modela as funcionalidades do sistema percebidas pelos seus usuários externos, chamados atores. Vista de Implementação - Modela os componentes em um sistema, bem como as dependências entre componentes. Vista de Alocação - Representa o arranjo das instâncias de um componente nos nós, durante a run-time Vista de Máquina Estática - Modela as possíveis histórias de vida de um objeto. Vista de Atividades - Descreve os grupos de atividades seqüenciais e concorrentes ao mesmo tempo. Vista de Interação - Descreve as seqüências de mensagens trocadas através das regras que implementam o Diagrama de Classe - Descreve os vários níveis de precisão e solidez do design dos modelos. Diagrama de Casos e Uso - Permite associar os atores aos sistemas que utilizam. Diagrama de Componente - Mostra os tipos de componentes em um sistema. Diagrama de Alocação - Mostra os nós (um computador, uma memória, um dispositivo) individuais e seus links em uma dada versão particular do sistema. Diagrama de Estados - Descreve os estados conectados por transições. Pode ser utilizado para descrever as interfaces, os dispositivos de controle e outros sistemas reativos. Diagrama de Atividades - Modela principalmente os workflows do mundo real de uma organização humana. Pode ser utilizado para modelar as atividades de software, representando os passos de execução de uma operação (computacional). Diagrama de Seqüência - Mostra o conjunto de mensagens arrumadas em seqüência temporal. A seqüência temporal é uma dimensão geométrica, as relações entre as regras são implícitas. Classe, Associação, Generalização, Dependência, Realização, Interface Componente, Interface, Dependência, Alocação Nó, Componente, Dependência, Alocação Estado, Evento, Transição, Ação Estado, Atividade, Inteireza da Transição, Bifurcação/Deci são, Ligação Interação, Objeto, Mensagem, Ativação ENEGEP 2003 ABEPRO 4

5 Gestão de Modelo Extensíbilidade implementam o comportamento do sistema. Vista de Gestão de Modelo - Modela a organização dos modelos em si. Diagrama de Colaboração - Mostra os parâmetros e as variáveis locais da operação, bem como associações mais permanentes. Quando um comportamento é implementado, a seqüência de mensagens corresponde à estrutura de chamada e sinalização embutida no sistema. Mostra as relações entre as regras geometricamente e associa as mensagens aos relacionamentos, mas a seqüência temporal é menos clara. Neste sentido, este diagrama e o Diagrama de Seqüência são complementares. Diagrama de Classe - Descreve os vários níveis de precisão e solidez do design dos modelos. Colaboração, Interação, Regras de Colaboração, Mensagem Pacote, Subsistema, Modelo Todas Todos Restrições, Estereótipo, Metas Fonte: (Cameira, 2003, baseado em Rumbaugh, Jacobson & Boock, 1999, p ) Quadro 1: Vistas e Diagramas da UML versus Principais Conceitos Estes vários modelos possuem relações entre si, que permitem evoluir da concepção inicial, das regras de negócio identificadas, até a construção dos componentes de software que realizarão o sistema. Estas regras de negócio, se pensada a concepção do sistema atrelada à concepção do processo, podem representar o link com os objetivos do negócio, que emanam das estratégias da empresa. Entre os nove principais modelos associados da UML, destacam-se, na integração com os modelos usualmente utilizados pela EPN o Diagrama de Casos e Uso, associado à visão estática e o Diagrama de Atividades, referente à visão dinâmica. O Use Case Diagram tem em sua representação, talvez, a fronteira mais marcante entre o fim da definição do processo, e o início da construção do sistema, a partir desta definição do processo. Use Cases Diagrams apóiam a análise de requisitos para a especificação do projeto. Eles descrevem a interação entre atores externos e um sistema de informação. Pode ser associado, em uma ferramenta de modelagem, às atividades de um processo modelado. De fato, alguns dos objetos existentes nos modelos usualmente utilizados na EPN e os Casos e Uso são, muitas vezes, comuns. Por exemplo, um ator em um Casos e Uso pode ser o mesmo em um processo detalhado em um eepc ( Event Driven Process Chain Cadeia de Processo Orientada por Eventos ) ou Organograma. O manual de metodologia do ARIS Toolset (IDS SCHEER AG, 2001, p. 5-14) exemplifica algumas relações entre os modelos da EPN e da UML: A relação entre o Diagrama de Classe e o eepc, que se realiza através das conexões (indicando o fluxo de informações, se input ou output) e das funções/atividades comuns; A relação entre o Diagrama de Casos e Uso e o eepc, que pode ocorrer de duas formas principais, além do uso de atores comuns associados às funções (acima exemplificado): a) descrevendo um Casos e Uso e relacionando o mesmo a um processo descrito no EPC ( assign ); b) Especificando a função/atividade no eepc em maior detalhe com o Casos e Uso, linkando o Casos e Uso a esta função/atividade; A relação direta entre Diagrama de Atividades e eepc. Sendo os dois bastante convergentes, sugere-se até que o primeiro seja integralmente substituído pelo segundo, bastando para tal reduzir os objetos disponíveis no eepc (em maior número), dotando de unicidade a modelagem; ENEGEP 2003 ABEPRO 5

6 Relacionando o Diagrama de Estados ao eepc, associando os símbolos de Estado do Objeto e de Produto/Serviço às funções/atividades. Neste caso os Eventos (que podem ser representados por Estados de Objeto ) podem representar uma redundância semântica no modelo (neste caso pode-se usar a conexões de correspondência, ligando os modelos como informação adicional). A relação da UML com a vista de dados, ou de construção de sistema tradicional, pode ser realizada relacionando-se o Diagrama de Classe ao Extended Entity Relationship Management (eerm). O Diagrama de Atividades, ao tentar descrever, sob a ótica de sistemas, o fluxo de trabalho do mundo das organizações humanas pode ser diretamente associado a um eepc. Essa aderência será mais forte quanto mais forte for o uso de sistemas. Em outras palavras, conforme os modelos de negócio forem mais tecnologicamente habilitados, tecnologia esta baseada em AISs orientadas por processos, mais atividades nos processos serão realizadas por sistemas e mais fortemente este vínculo ocorrerá. Em um ambiente hiper-integrado, a informação contida em um eepc e em um Diagrama de Atividades é, grosso modo, idêntica. Por sua vez, neste mundo hiper-integrado, os Casos e Uso representarão, cada vez mais, as interações dos humanos com os sistemas, as aberturas de janelas no fluxo hiper-integrado. Na UML, as informações contidas nos modelos mais associados à visão (estática e dinâmica) do negócio são, por assim dizer, detalhadas ou desagregadas nos demais modelos, modelos estes mais próximos da realização física dos sistemas, notadamente o Diagrama de Implementação e o Diagrama de Alocação. 5. Processos e Sistemas Componentizados e AIS As diversas categorias de sistemas (Enterprise Resource Planning ERP; Customer Relationship Management CRM, etc.) que compõem uma AIS abrangem, apóiam ou viabilizam, cada qual com sua finalidade, com suas funções, a grande maioria dos fluxos de informação (que percorrem os processos) que permeiam uma organização e as cadeias onde as organizações operam. Cabe, portanto, avaliar como a crescente componentização de sistemas, pensada processualmente, impactará estes sistemas componentes de uma AIS. A Figura 2 representa a associação entre os processos componentizados e a representação através de modelos da UML. ENEGEP 2003 ABEPRO 6

7 Fonte: (Cameira, 2003, p.341) Figura 2: Processos Componentizados e Modelos da UML Nesta figura, um banco de dados de processos componentizados supri um processo central com representações de processos reutilizáveis. Por sua vez este processos estão relacionados, conforme visto acima, em diversos níveis aos modelos da UML, aproximando a representação do processo, do negócio, à concepção do sistema. Os tempos de desenvolvimento são, portanto, reduzidos, tanto mais quanto mais completa for ficando a biblioteca de componentes acessíveis. Por exemplo, em processos com grande número de atividades iguais, após o primeiro sistema componentizado, o segundo tem o foco de desenvolvimento de sistemas basicamente no processo central. A Figura 3 busca representar este cenário. Nele as representações do sistema realizadas pela UML e oriundas ou inter-relacionadas à definição dos processos subsidiam a construção de um banco de dados de componentes de software. Banco de Dados de Componentes de Software Fonte: (Cameira, 2003, p.342) Figura 3: Processos Componentizados e Componentes de Sistemas 6. Conclusão Portanto, com a componentização de sistemas, o relacionamento entre os processos de ENEGEP 2003 ABEPRO 7

8 negócios e a realização dos sistemas que os viabilizam é direta. Observe-se que se pode componentizar sistemas, construir componentes de software, diretamente, construindo-se os componentes a partir de uma análise de requisitos, como no método tradicional de Engenharia de Sistemas. Componentizar sistemas segundo uma visão de componentização de processos é, contudo, o que mais facilmente permitirá a plena potencialização do uso da tecnologia disponível; o entendimento do funcionamento da nova AIS, construída pela soma de componentes; o redesenho desta AIS, com a conexão entre sistemas diversos, na cadeia; a conexão entre a visão do negócio e a visão da TI; a seleção de um componente adequado à organização. Em outras palavras, os diversos componentes potencializam a construção de uma AIS afinada com a visão processual, diretamente relacionada aos processos de negócios que os sistemas suportam, enxergando os fluxos de informação em amplo enfoque, dentro da organização, entre suas diversas áreas; na cadeia, integrando as diversas organizações; e entre cadeias, em um estágio de amplas economias de escala e escopo. Referências BASTOS, A. & CAMEIRA, R. (2000) - Ferramentas de apoio à engenharia de processos de negócios: critérios de classificação e método de análise de adequação a um projeto. In: ENEGEP, 20., São Paulo. Anais Eletrônicos... ABEPRO. 1 CD. Rio de Janeiro. CAMEIRA, R. (2003) - Hiper-Integração: Engenharia de Processos, Arquitetura Integrada de Sistemas Componentizados com Agentes e Modelos de Negócios Tecnologicamente Habilitados. 432 p. Tese (Doutorado em Engenharia de Produção) COPPE, UFRJ. Rio de Janeiro. CAMEIRA, R.; CAULLIRAUX, H.; PROENÇA, A. & SANTOS, R. (2002) - Componentized integrated systems architecture and business process engeneering: methodological aspects. In: INTERNAT. CONF. ON INDUSTRIAL ENG. AND OPERATIONS MANAG., 8, Curitiba, PR. Anais ABEPRO. Porto Alegre. CAMEIRA, R. & CAULLIRAUX, H. (2000) - Engenharia de processos de negócios: considerações metodológicas com vistas à análise e integração de processos. In: SIMPOI, 3., São Paulo. Anais Eletrônicos... FGV. 1CD. São Paulo. CAULLIRAUX, H. & CAMEIRA, R. (2000) - A consolidação da visão por processos na engenharia de produção e possíveis desdobramentos. In: ENEGEP, São Paulo. Anais Eletrônicos...ABEPRO. 1 CD. São Paulo. CAULLIRAUX, H.; PROENÇA, A. & PRADO, C. (2000) - Enterprise resource planning systems from a strategic perspective: its evolving scope and related technical issues. In: V ICIE, Brasil. Anais Eletrônicos... Grupo de Produção Integrada/COPPE-EE/UFRJ. Rio de Janeiro. FISHER, A. (1990) - CASE utilização de ferramentas para desenvolvimento de software. Campus. 1ª Ed. Rio de Janeiro. IDS SCHEER AG (2001) - Aris Methods v6. IDS SCHEER AG, Set. Saarbrücken, Alemanha. KIRCHMER, M. (1998) - Business process oriented implementation of standard software: how to achieve competitive advantage quickly and efficiently. Springer-Verlag Berlin. 242 p.. Heidelberg. KULAK; GUINEY (2000) - Use Cases Requirements in Context. Addison-Wesley. 1 st Ed. Boston, MA. RUMBAUGH, J., JACOBSON, I. & BOOCH, G. (1999) - The Unified Modeling Language Reference Manual. Massachusetts. Addison Wesley Longman, Inc.. 1st. Ed., 550p. Boston, MA. SANTOS, R. (2002) - Engenharia de Processos: análise do referencial teórico conceitual, instrumentos, aplicações e casos com a finalidade de síntese sobre sua estrutura, conhecimentos, falhas e resultados. 317 p. Dissertação (Mestrado em Engenharia de Produção) COPPE, UFRJ. Rio de Janeiro. SANTOS, R. & CAMEIRA, R. (2001) - Process: the high performance enabling technology. In: SIMPOI, 4., São Paulo. Anais Eletrônicos... FGV. 1CD. São Paulo. SCHEER, A.-W. (1998) - ARIS business process frameworks. Springer Verlag-Berlin. 2 st Ed. Heidelberg. ENEGEP 2003 ABEPRO 8