| | 1 | = Versão Experimental - Flumen = |
| | 2 | |
| | 3 | Paralelo ao desenvolvimento normal do módulo workflow, encontra-se em desenvolvimento uma nova versão, por enquanto experimental, com o objetivo de reestruturar o módulo e introduzir melhorias significativas. Abaixo segue o levantamento de requisitos desejáveis para esta versão. |
| | 4 | |
| | 5 | O desenvolvimento está sendo feito na área [browser:sandbox/workflow SandBox do Svn], que pode ser visualizada aqui. |
| | 6 | |
| | 7 | A política de trabalho cooperado é a mesma empregada para o Expresso, e pode ser consultada na [wiki:WikiStart página inicial do wiki], link "Padrões de Desenvolvimento e Colaboração". |
| | 8 | |
| | 9 | == Requisitos para o Módulo == |
| | 10 | |
| | 11 | * Definir uma nova árvore de diretórios para o módulo, que separe o código acessível pelo Expresso, código do módulo (lib), e código de terceiros. Prever local para hooks, plugins, especializações de classes, templates por organização; |
| | 12 | |
| | 13 | * Revisar o código do engine |
| | 14 | * Remover métodos desnecessários; |
| | 15 | * Encapsular as classes e atributos, segundo orientação por objetos (private, public, protected); |
| | 16 | * Remover o design pattern Observer; |
| | 17 | |
| | 18 | * Reescrever as interfaces do workflow utilizando plugins |
| | 19 | * Existirá uma super-classe da qual serão especializados os plugins para ações, filtros, conexões com banco, ldap, filesystem, etc; |
| | 20 | * Registrar os plugins disponíveis em cada interface e registrar o controle de acesso dos usuários; |
| | 21 | * Criar uma classe de segurança que verifica se um plugin está disponível para um usuário, antes de rederizar a interface; |
| | 22 | * Pensar um esquema de cache para otimizar as consultas de segurança. |
| | 23 | |
| | 24 | * Implementar um novo modelo de classes para o workflow |
| | 25 | * Considerar o framework de plugins; |
| | 26 | * Transferir para o módulo as classes que são de estrutura dos processos e deixar no engine apenas as funcionalidades relativas ao andamento das instâncias. |
| | 27 | * Documentar o engine com um diagrama de classes. |
| | 28 | |
| | 29 | * Pesquisar e implantar uma ferramenta para design dos fluxos dos processos |
| | 30 | * Atualmente os processos são cadastrados através de formulários, onde o desenvolvedor informa as atividades, transições, perfis, etc. Depois pode exibir um gráfico do processo. A proposta é encontrar uma ferramenta que faça o contrário: desenhe o fluxo e este sirva de entrada para registrar a estrutura do processo. Possivelmente o fluxo será descrito em uma linguagem de definição que pode ser lida pelo módulo workflow, ou então a nova ferramenta poderia acessar diretamente o banco de dados. Reformular a interface administrativa para que as operações possam ser feitas sobre a imagem do processo. Por exemplo, clicando sobre ícone de uma atividade tem-se acesso às suas propriedades e perfis. Impedir que modificações sejam feitas no fluxo quando existirem instâncias dependentes das atividades. |
| | 31 | |
| | 32 | * Implantar um gerador de código |
| | 33 | * Com este novo recurso, quando o gráfico do processo estiver concluído, será gerado o código básico para que o processo funcione. Assim sendo, o desenvolvedor ficaria com a tarefa de preencher lacunas no código, como por exemplo os formulários e métodos associados aos botões. |
| | 34 | |
| | 35 | * Criar um mecanismo autenticado para inclusão de instâncias |
| | 36 | * Com esta funcionalidade, sistemas externos poderão iniciar instâncias no workflow, sem passar pelas atividades Start dos processos. Já temos webservice no módulo (porém somente disponível para a Celepar). Verificar se é possível tornar autenticado. Considerar a possibilidade de uso de certificado. |
| | 37 | |
| | 38 | * Criar boletins para processos |
| | 39 | * Implementar uma área, em cada processo, para divulgar as novidades, melhorias e correções. Isso é útil para os usuários acompanharem a evolução dos processos. |
| | 40 | |
| | 41 | * Substituir o conector Ajax |
| | 42 | * Trocar o atual conector Ajax (connector.js / controller.php) usado na interface do módulo, pelo framework nanoAjax, que já é utilizado nos processos. Substituir todas as chamadas do antigo conector pelo novo. |
| | 43 | |
| | 44 | * Criar um controle de tempo de execução para atividades |
| | 45 | * Implementar uma nova funcionalidade para atividades em que possa ser definido um tempo máximo de permanência da mesma com o usuário que detém a posse. Criar um job genérico que rode diariamente e selecione as atividades que expiraram os prazos, e de alguma forma comunicar o usuário ou um administrador designado. |
| | 46 | |
| | 47 | * Prover uma auditoria de queries executadas nas tabelas do módulo Workflow. |
| | 48 | * Quando alguma alteração nos dados do processo for realizada, na interface de administração, registrar o evento em banco de dados para se ter um histórico dos acontecimentos. Por exemplo, ativação/desativação de processo, alteração de parâmetros, etc; |
| | 49 | * Verificar a possibilidade de executar triggers nas tabelas do módulo Workflow, para logar a atividade sql. Cuidar para não impactar na performance geral do banco; |
| | 50 | * Outra abordagem pode ser inserção de código nos principais eventos administrativos, para logar as modificações; |
| | 51 | |
| | 52 | = Requisitos para o MVC = |
| | 53 | |
| | 54 | * Definir uma nova estrutura de diretórios para os processos. Considerar a experiência do Serpro da Bahia. Analisar a estrutura de outros frameworks como o Cake e Simphony; |
| | 55 | |
| | 56 | * Criar um novo modelo de execução de atividades |
| | 57 | * Criar uma classe base para execução de atividades, contendo métodos básicos como inicialização, finalização, cancelamento, execução, continuação de uma instância, execução de ajax, comunicação com o engine e outros que um estudo mais detalhado venha a revelar; |
| | 58 | * Incluir também objetos para as classes já existentes hoje como regex, factory, validações; |
| | 59 | * O desenvolvedor irá criar uma classe para cada uma de suas atividades, que estenderá a superclasse e que contenha atributos do tipo objeto para as classes controller e model da atividade; |
| | 60 | * Implementar um método run que possa ser executado para iniciar a atividade. Continuarão a existir as classes de controller e model da atividade, em separado. Continuarão a existir as classes basecontroller e basemodel; |
| | 61 | * O desenvolvedor poderá sobrescrever os métodos de evento da superclasse: inicialização, finalização, cancelamento, transição. Em especial a transição pode servir ao desenvolvedor para obter o id da instância, após o encerramento de uma atividade start; |
| | 62 | * Criar uma nova classe run_activity, que será responsável por instanciar a classe da atividade e executá-la. Usar uma função global para obter este objeto, de modo a garantir que somente o código da classe seja carregado; |
| | 63 | * Criar um mecanismo que impeça o código do usuário criar objetos das classes do módulo e do engine. Como sugestão poderia ser uma análise no call_back procurando a origem da instanciação; |
| | 64 | * Acomodar os processamentos pré e pós execução das atividades (agente de correio) em outro local do código; |
| | 65 | |
| | 66 | * Criar uma camada de visualização para encapsular o gerador de templates Smarty |
| | 67 | * Criar componentes para os diversos elementos de formulário, como textarea, inputs, etc; |
| | 68 | * Implementar o conceito de container, que agrega componentes em uma mesma linha do template; |
| | 69 | * Criar componente de ocultação e um array de botões submit; |
| | 70 | * Prever também o encapsulamento dos plugins smarty criados para o workflow (select users, etc); |
| | 71 | * Esta camada será representada pela classe baseview, que terá atributos para os componentes adicionados ao objeto view; |
| | 72 | * O submit fará uma chamada ao dispatch. O dispatch fará a verificação prévia de campos obrigatórios. Caso não tenha erros irá chamar o método de validação em php, via ajax. Caso sem erros, será montado o array request na model; |
| | 73 | * Carregar no template os arquivos javascript indicados pelo desenvolvedor. Possibilitar associar funções javascript aos componentes; |
| | 74 | * O objeto view deverá carregar os dados preparados as outras camadas e mesclar no template; |
| | 75 | * A criação do objeto smarty ficará ao encargo da camada view. |
