| | 1 | = Propostas para o Módulo Workflow = |
| | 2 | |
| | 3 | * Definir uma nova árvore de diretórios para o módulo que contemple: |
| | 4 | * Isolar o código acessível pelo Expresso (inc); |
| | 5 | * Separar o código interno do módulo (lib); |
| | 6 | * Separar o código de terceiros (php e js); |
| | 7 | * Prever local (custom) para o código das organizações: hooks, plugins, especializações de classes, templates. |
| | 8 | |
| | 9 | * Revisar o código do engine |
| | 10 | * Remover métodos desnecessários; |
| | 11 | * Encapsular as classes e atributos, segundo orientação por objetos (private, public, protected); |
| | 12 | * Remover o design pattern Observer; |
| | 13 | * 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; |
| | 14 | * Eliminar a sobrecarga de métodos do engine que está sendo feita na pasta inc do workflow. Por exemplo a classe workflow_processomanager; |
| | 15 | * Eliminar o parâmetro link do banco de dados passado na construção da classe; |
| | 16 | * Documentar o engine com um diagrama de classes e um diagrama entidade-relacionamento; |
| | 17 | * Verificar se é possível documentar o engine com algum diagrama comportamental. |
| | 18 | |
| | 19 | * Criar uma nova factory estática para o workflow |
| | 20 | * Fazer o registro das classes que podem ser utilizadas; |
| | 21 | * Avaliar o design pattern registry e ver como pode ser aproveitado; |
| | 22 | * Encapsular objetos do array $Globals; |
| | 23 | * Criar um cache na factory; |
| | 24 | * Avaliar como pode ser feito um cache de objetos que perdure após um recarregamento da página, por exemplo utilizando sessão ou memcache; |
| | 25 | * Definir um hook para implementar o cache personalizado de um organização. Se inexistente, usa o padrão do workflow; |
| | 26 | * Aproveitar esta factory também para os processos, e prover uma forma de isolar as classes que são do módulo. Uma possibilidade seria criar uma factory abstrata e uma especialização para o workflow e outra para os processos; |
| | 27 | * Verificar se é possível utilizar o autoload para identicar a localização dos arquivos fontes; |
| | 28 | |
| | 29 | * Reorganizar o código do workflow utilizando plugins |
| | 30 | * Definir uma estrutura de plugins que possibilite a separação do núcleo do workflow e suas funcionalidades periféricas; |
| | 31 | * Entende-se por núcleo do workflow toda a estrutura responsável pela execução de atividades, controle do fluxo dos processos, controle de plugins e segurança; |
| | 32 | * Cada plugin deve ter um identificador único que será cadastrado no banco de dados e que possibilite a sua habilitação ou desabilitação; |
| | 33 | * No banco de dados devem ser inseridos dados como: o identificador, localização do arquivo da controller, nome da classe e status; |
| | 34 | * Os plugins devem estender uma classe geral que defina métodos padrão para registro, instanciação e execução daqueles; |
| | 35 | * Em determinados lugares dentro do módulo devem ser definidos hooks. Ex. Menu lateral de administração, aba na interface de usuário, etc.; |
| | 36 | * Deve-se criar uma estrutura padrão para os plugins que siga o design pattern MVC; |
| | 37 | * Deve existir algum controle de acesso para liberar os plugins para usuários; |
| | 38 | * Possibilitar aninhamento de plugins; |
| | 39 | * Possibilitar a criação de plugin na área custom da organização. |
| | 40 | |
| | 41 | * Pesquisar e implantar uma ferramenta para design dos fluxos dos processos |
| | 42 | * 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; |
| | 43 | * 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; |
| | 44 | * Impedir que modificações sejam feitas no fluxo quando existirem instâncias dependentes das atividades. |
| | 45 | |
| | 46 | * Implantar um gerador de código |
| | 47 | * 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. |
| | 48 | |
| | 49 | * Criar um mecanismo autenticado para inclusão de instâncias |
| | 50 | * Com esta funcionalidade, sistemas externos poderão iniciar instâncias no workflow, sem passar pelas atividades Start dos processos; |
| | 51 | * Considerar o uso de web-service autenticado; |
| | 52 | * Considerar a possibilidade de uso de certificado. |
| | 53 | |
| | 54 | * Criar boletins para processos |
| | 55 | * 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. |
| | 56 | |
| | 57 | * Avaliar as bibliotedas de javascript utilizadas no Expresso e escolher aquelas que serão as oficiais |
| | 58 | * Dentre as bibliotecas existentes, que sejam de mesma natureza, optar por uma delas e modificar o código do módulo. |
| | 59 | |
| | 60 | * Substituir o conector Ajax |
| | 61 | * 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. |
| | 62 | |
| | 63 | * Criar um controle de tempo de execução para atividades |
| | 64 | * 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; |
| | 65 | * 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; |
| | 66 | * Se ficar inviável criar o job, porque o atual modelo exige configuração do cron do servidor, criar ao menos um página que mostre o resultado das pesquisas com opção de envio de email; |
| | 67 | * Verificar a possibilidade de gravar buscas no monitoramento por processo, e efetuar envio de email automático a partir do resultado da busca. |
| | 68 | |
| | 69 | * Prover uma auditoria de queries executadas nas tabelas do módulo Workflow. |
| | 70 | * 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 configuração, inclusão/exclusão de elementos, etc; |
| | 71 | * 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; |
| | 72 | * Outra abordagem pode ser inserção de código nos principais eventos administrativos, para logar as modificações; |
| | 73 | |
| | 74 | * Pensar em uma maneira de fazer um acompanhamento por processo, onde um usuário possa visualizar qualquer instância, e não somente as que detém a posse; |
| | 75 | * Uma solução pode ser a criação de um perfil especial [Leitor] e associar os usuários que podem visualizar instâncias do processo; |
| | 76 | |
| | 77 | * No menu 'mais ações' da instância, criar hooks para possibilitar inclusão de código a ser executado quando a ação for acionada; |
| | 78 | * Por exemplo, ao abortar uma instância, realizar também alguma manutenção no banco de dados do processo; |
| | 79 | |
| | 80 | * Modificar o template padrão de processos para: |
| | 81 | * Definir um hook para personilizar o template de processos por organização; |
| | 82 | * Criar parâmetros para incluir as bibliotecas de javascript. |
| | 83 | |
| | 84 | * Implantar uma ferramenta de automação de testes e deploy |
| | 85 | * Considerar a experiência do Serpro-BA com os softwares phpunit, phpdocumentor, codesniffer, ant, hudson (integração contínua); |
| | 86 | * Verificar a possibilidade de expandir as funcionalidades do Processo de Transferência; |
| | 87 | * Estudar uma maneira de realizar o deploy completo do processo, envolvendo o código fonte e a estrutura de atividades, transições e perfis. |
| | 88 | |
| | 89 | * Executar o código do módulo sob tratamento de exceções (try/catch); |
