Trabalho II. Implementação de Workflow. Processo de Análise de Hipóteses

Transcrição

1 Trabalho II Implementação de Workflow Processo de Análise de Hipóteses Tópicos Especiais em Sistemas de informação Workflow Profs. Marcos Borges e Renata Mendes de Araújo Mestrado NCE/IM Alunos: Fátima Kiffer Marcus Rabello Cavalcanti Vinícius Manhaes Teles

2 Introdução: Este trabalho tentará mostrar as dificuldades que ocorrem quando tentamos modelar um processo que ocorre independente de uma ferramenta de workflow em uma máquina de workflow real. Para isso, iniciaremos apresentando o processo, que foi modelado em uma tese de mestrado utilizando uma ferramenta de modelagem independente de máquina de workflow, mostrando sua representação gráfica assim como a descrição do processo. Após isso mostraremos o processo implementado em um workflow, tentando apresentar suas diferenças e particularidades incluídas devido à ferramenta utilizada assim como as dificuldades passadas no momento da implementação. Para realizar a modelagem foi utilizada durante a elaboração da tese a ferramenta Provision. Neste trabalho estaremos o implementando uma parte do maior processo descrito na tese dentro do software MqSeries Workflow por termos avaliado que este apresentava algumas nuances interessantes para observarmos. Apresentaremos também durante o trabalho as simplificações feitas no processo devido às dificuldades de utilização da ferramenta. O processo Modelado: Processo Análise de Hipótese: Nome: BO2 - Análise de hipótese Objetivo: Analisar uma hipótese por meio de operações OLAP. Contexto: Dada uma hipótese diversas operações OLAP são realizadas para investiga-la. Solução: A análise de hipótese é composta pelos passos: BO2.a) Busca de consulta pronta de acordo com a hipótese, a análise pode começar por uma consulta pronta disponível na aplicação OLAP se já houver alguma consulta relacionada ao que se deseja investigar. A última consulta realizada que ainda está disponível na tela também é considerada uma consulta pronta. BO2.b) Composição de consulta OLAP caso não encontre uma consulta pronta adequada, o analista de informação compõe uma consulta de acordo com os elementos multidimensionais desejados para investigar a hipótese. Esta atividade é descrita pelo bean BO3 - Composição de consulta OLAP. BO2.c) Reflexão sobre o resultado o analista de informação reflete sobre a consulta atual. Se chegar a alguma conclusão segue à atividade BO2.d - Conclusão da análise, caso contrário executa a atividade BO2.e - Estudo da próxima operação. BO2.d) Conclusão da análise o analista de informação documenta as conclusões da hipótese investigada.

3 BO2.e) Estudo da próxima operação o analista de informação escolhe alguma operação OLAP para modificar a consulta atual, representadas pelas atividades de código BO2.f até BO2.o. BO2.f) Roll-up operação OLAP descrita pelo bean BO4 - Roll-up. BO2.g) Drill-down operação OLAP descrita pelo bean BO5 - Drill-down. BO2.h) Rotação simples operação OLAP descrita pelo bean BO6 - Rotação simples. BO2.i) Rotação avançada operação OLAP descrita pelo bean BO7 - Rotação avançada. BO2.j) Aplicação de filtro em dimensão operação OLAP descrita pelo bean BO8 - Aplicação filtro dimensão. BO2.k) Exclusão de filtro em dimensão operação OLAP descrita pelo bean BO9 - Exclusão filtro dimensão. BO2.l) Aplicação de filtro em medida operação OLAP descrita pelo bean BO10 - Aplicação filtro medida. BO2.m) Exclusão de filtro em medida operação OLAP descrita pelo bean BO11 - Exclusão filtro medida. BO2.n) Mudança de função de agregação operação OLAP descrita pelo bean BO12 - Mudança de função de agregação. BO2.o) Mudança de foco operação OLAP descrita pelo bean BO13 - Mudança de foco.

4 Representação Gráfica: Analista de Consultas disponíveis (Aplicação OLAP) Conclusão análise Conclusão de análise Roll-up Drill-down Busca de consulta pronta Achou consulta? Yes N Reflexão sobre resultado Y es Conclui? No Estudo da próxima operação Qual operação? Rotação simples Rotação avançada Hipótese a investigar Composição de Consulta OLAP Metadado multidimensional (Aplicação OLAP) Aplicação filtro dimensão Exclusão filtro dimensão Aplicação filtro medida Exclusão filtro medida Mudança função agregação Mudança foco Documentos: Hipótese a investigar, conclusão da análise. Sub-Processo Composição de consulta OLAP: Nome: BO3 - Composição de Consulta OLAP Objetivo: Por meio da interface gráfica OLAP, construção de uma consulta baseada em um esquema multidimensional Ω. Contexto: É utilizado como ponto de partida em situações onde se deseja responder a uma questão do negócio (por exemplo: Quais lojas oferecem potencial para descontos de produtos eletrônicos? ) ou verificar uma hipótese (por exemplo: Lojas da região centrooeste vendem poucos produtos eletrônicos ). Solução: A composição de consulta OLAP é formada pelos seguintes passos: BO3.a) Escolha da visão multidimensional - (VM) que será utilizada para visualização, por exemplo: tabela ou gráfico.

5 BO3.b) Escolha de medida de resultado - escolha da fórmula da medida de resultado mrk a ser analisada e, se desejado, definição do filtro associado fmrk. Repetir este passo para cada medida de resultado, até completar o conjunto Mr. BO3.c) Escolha de dimensão de resultado bem como de seu nível lr que será utilizado para visualizar as medidas. Se for o caso, definição do filtro associado flk. Definição da dimensão visual que apresentará esta dimensão, bem como sua posição na ordem de aninhamento. Repetir este passo para cada dimensão de resultado, até completar o conjunto Lr. BO3.d) Arrumação das dimensões de seleção - escolha do nível ls de cada dimensão restante, as quais são obrigatoriamente dimensões de seleção conjunto Ls. Se for o caso, definição do filtro associado flk. Para toda dimensão de seleção, se o nível não for do tipo <nome_dimensão>.todos então deverá ter obrigatoriamente um filtro, restringindo-o a um único valor. Representação Gráfica: Analista de informação Yes Escolha da visão multidimensional Escolha de medida de resultado Outra medida? No Escolha de dimensão de resultado Interface Aplicação OLAP Metadad multidimension (Aplicação Outra dimensão dresultado? No Yes Consulta (Aplicação OLAP) Arrumação das dimensões de seleção

6 A implementação no MQSeries: Inicialmente, antes de modelarmos o processo em si, tivemos que criar um Process Model como sendo um container dos processos que iríamos criar. Esses Process Model servem para criar categorias de processos dentro do Build Time, organizando melhor os processos. No nosso caso foi utilizado para separar o nosso conjunto de processos, o qual passaremos a denominar de Ampa, de outros processos existentes na base da ferramenta. Em seguida foi necessário criar os papéis e usuários que fariam parte do processo. Criamos então o papel Analista de Informação e o usuário João da Silva, necessário para execução do processo no módulo de Run Time. Ainda precisamos criar uma organização, a qual demos o mesmo nome do modelo de processos, Ampa. Neste momento passamos pela primeira dificuldade, porque quando tentamos partir para modelar o processo na ferramenta, observamos que precisaríamos definir os programas inicialmente. Ocorre que para o MQSeries toda atividade real do usuário tem que ser representada por um programa real, fato não muito intuitivo. Desta forma tivemos que partir para a criação de programas para cada uma das atividades. Inicialmente procuramos somente utilizar programas de qualquer natureza, pois estávamos interessados em entender como seria possível modelar o fluxo antes de entrar em detalhes das aplicações. Ao iniciarmos a modelagem do primeiro processos, deparamos com mais uma diferença; não era permitido, simplesmente com os recursos do Build-time, definir um roteamento do fluxo. Precisamos fazer uso de aplicações externas ao MQSeries, que manipulem dados do workflow para podermos direcionar o fluxo de acordo com esses dados. Apesar de não termos essa funcionalidade diretamente no Workflow, a IBM disponibiliza alguns aplicativos que conseguem manipular dados de dentro do workflow. Tivemos então que criar aplicações para o redirecionamento de cada fluxo. Além disso, não era permitida a criação de ciclos em um único diagrama. Para criar um ciclo temos que utilizar um tipo de atividade especial, um sub-processo que é executado repetidamente até que uma condição de saída seja verdadeira. Essa atividade especial é denominada Block Activity. Observe na figura abaixo como ficou o processo inicial. Em azul estão representadas as condições de transição determinadas pelo Return Code (RC) apresentado por cada aplicação. Em verde está representada a condição de saída da atividade de bloco.

7 Figura 1- Diagrama principal do processo de Análise de Hipótese Após modelarmos esse processo inicial, fomos modelar o sub-processo, não existente na modelagem inicial, que foi criado para fazer os ciclos. Neste momento, por ter sido preciso quebrar o processo em dois, foi necessário que de alguma forma as atividades do processo interno se comunicasse com a atividade Reflexão sobre o Resultado determinando a condição de saída da atividade. Este tratamento não nos pareceu bastante confuso. Esta comunicação foi feita através de um nó container de informações apontado por uma seta pontilhada(representa a transferência de dados), representado pela gaveta com uma seta em cima. Outra simplificação que foi necessário foi à redução das dez possíveis operações OLAP disponíveis para apenas duas. Isso ocorreu porque a única aplicação capaz de manipular dados do workflow disponível para fazermos esta implementação somente era capaz de retornar dois valores diferentes para o workflow. Para solucionarmos este problema teríamos que desenvolver alguma aplicação que fizesse esse tratamento, o que demandaria muito tempo, inviabilizando a realização deste trabalho a tempo. Observe na figura abaixo como ficou o processo inicial. Da mesma maneira que na figura anterior estão representadas em azul as condições de cada transição.

8 Figura 2 Sub processo cíclico pertencente ao processo de Análise de Hipótese Em seguida fomos modelar o sub-processo Composição de uma consulta OLAP conforme definido originalmente. Após implementarmos os dois diagramas anteriores fomos capazes de modelar este sub-processo de maneira mais rápida, devido a familiaridade com a técnica adquirida nos exemplos anteriores. Só o que vale observar neste caso, onde novamente foi necessário criar as Block Activities para realizar ciclos, é a falta de expressividade gráfica que tem essa solução. Observe na figura abaixo os diagrama do sub-processo. Figura 3- Diagrama do sub-processo Composição de consulta OLAP

9 Observe na figura 4 como o ciclo fica completamente sem representatividade gráfica. Figura4 Atividade de bloco Escolha de medida de resultado Conclusão: Durante esse trabalho pudemos observar algumas questões interessantes na implementação real de um processo de workflow. Primeiramente observamos que existe uma diferença considerável entre as técnicas de modelagem utilizadas nas duas ferramentas que utilizamos. Isso aparentemente denota um alto grau de imaturidade na implementação destas ferramentas. Normalmente estamos acostumados a modelar dados, e até comportamento, onde a técnica varia de acordo com a metodologia de desenvolvimento de software utilizada, porém a forma de representar o mundo, utilizando uma mesma técnica, pouco muda de acordo com a ferramenta. Outro fato observado, agora referente à ferramenta utilizada, é o fato dela ainda ser muito nova em relação às funcionalidades e facilidades disponíveis. Pudemos observar que foram disponibilizadas maneiras de implementar as diferentes situações, porém as interfaces ainda são pouco amigáveis ou intuitivas. Isso acaba se tornando um entrave para a utilização em maior escala da ferramenta uma vez que o custo de desenvolvimento acaba ficando muito alto. Ainda foi possível analisar, que os mecanismos para tratamento do desvio de fluxo ainda são bastante ineficientes em relação as reais necessidades de processos. Um mecanismo para modelagem de um processo tradicional de desenvolvimento de software em cascata, no qual em cada atividade podemos voltar a quaisquer atividades anteriores, seria bastante complexo de modelar utilizando os mecanismos disponibilizados ma ferramenta utilizada para desenvolver este trabalho, o que denota ainda uma baixa flexibilidade para atender aos diferentes tipos de processos. Mecanismos mais evoluídos para tratamento de exceção em workflow podem vir, no futuro, colaborar na solução de problemas como este.

10 Bibliografia: IBM, IBM MQSeries Workflow for Windows NT Beginners; Acessível em Março IBM, IBM MQSeries Workflow Adminstrator Guide; Acessível em Março IBM, Business Process Management using MQSeries and Partner Agreement Manager. Acessível em Março IBM, IBM MQSeries Workflow Installation Guide. Acessível em Março 2001.