manual - projudi 1

Projudi

Manual - Projudi 1.9

Versão 2.0

Histórico de Revisões

Data Versão Descrição Autor

10/06/09 2.0 Registro inicial Paulo Eduardo Menon

Confidencial CNJ- Conselho Nacional de Justiça, 2009 Página 2 de 30

Sumário

1. Introdução ao Manual Técnico .............................................................................................................. 6

1.1 Propósito ...................................................................................................................................... 6

1.2 Referências .................................................................................................................................. 6

1.3 Visão Geral do Manual Técnico .................................................................................................. 6

1.4 Tecnologia e Linguagens do Projudi ........................................................................................... 7

1.5 Representação das Camadas de desenvolvimento ....................................................................... 7

2. Tecnologia e Linguagens do Projudi ..................................................................................................... 7

2.1 Beans ........................................................................................................................................... 8

2.2 Controle e gerenciamento de permissões .................................................................................... 8

2.3 Execuções automáticas ................................................................................................................ 9

2.4 Geração de certificados ............................................................................................................... 9

2.5 Upload de arquivos ...................................................................................................................... 9

2.6 Verificação de Assinatura ........................................................................................................... 9

2.7 Verificação de Vírus .................................................................................................................. 10

2.8 JusSigner ................................................................................................................................... 10

2.9 Envio de e-mails ........................................................................................................................ 10

2.10 Sistema de arquivos ................................................................................................................. 10

2.11 Integração. .............................................................................................................................. 11

2.11.1 Siscom 11

2.11.2 WebService 11

2.12 Framework Torque .................................................................................................................. 11

3. Ambiante de Desenvolvimento e Produção ......................................................................................... 12

3.1 Ambiente de Produção .............................................................................................................. 12

3.2 Ambiente de Desenvolvimento ................................................................................................. 12

3.3 Infra-Estrutura/Configuração ................................................................................................... 12


4. Camada de Apresentação ..................................................................................................................... 12

5. Camada de Controle ............................................................................................................................. 13

6. Camada de Negócio ............................................................................................................................. 13

7. Camada de Mapeamento Objeto-Relacional ........................................................................................ 13

8. Camada de Persistencia ........................................................................................................................ 13

9. Novas Funcionalidades do Projudi 1.9 ................................................................................................ 14

10. Casos de Uso - Fluxo da aplicação .................................................................................................... 24

10.1 Registrar Enquadramento ........................................................................................................ 24

10.2 Turma Recursal ....................................................................................................................... 27

11. Erros Freqüentes ................................................................................................................................ 32

11.1 O sistema não desenha toda a tela de resumo de dados do processo: ..................................... 32

11.2 Ao tentar abrir um arquivo é exibida a mensagem “Error decoding byte source”: ................. 32

11.3 Lentidão na rede: ..................................................................................................................... 33

11.4 Problemas de máquina, instalação, configuração, vírus: ......................................................... 33

11.5 Problemas ao assinar no Mozilla/Firefox: ............................................................................... 33

11.6 Problemas ao assinar utilizando o Windows Vista: ................................................................ 33

11.7 Erro ao movimentar processo com solicitação de expedição de cumprimento: ...................... 33

11.8 Erro ao expedir citação, cumprimento, intimação, notificação: .............................................. 34

11.9 Não é possível arquivar um processo sem documentos: ......................................................... 34

11.10 Não é possível gerar uma identidade digital para um usuário: .............................................. 34

11.11 Mensagem de sítio não recomendado: .................................................................................. 34

11.12 Lentidão ao abrir um processo: ............................................................................................. 34

11.13 Reconhecimento de certificados A3: ..................................................................................... 34

11.14 Para os demais casos: ............................................................................................................ 35

12. Próximas Leituras .............................................................................................................................. 35


Projudi Versão 2.0

Manual Técnico do Projudi 1.9 Data: 17/06/09

Manual - Projudi1.9.doc

Manual - Projudi 1.9

1. Introdução ao Manual Técnico

O manual técnico tem como objetivo alem de trazer as novas funcionalidades e de demostrar as camadas implementadas na aplicação dando uma melhor diretriz para auxiliar no desenvolvimento e manutenção do Projudi versão 1.9 mostrar o padrão de desenvolvimento utilizando o framework torque altamente utilizado no sistema.

Poderemos ver nas seções desde documento, que esta dividido em apresentação das camadas de desenvolvimento e seus papeis no aplicativo, tecnologias e linguagem usada no projeto, utilizando o torque e como esta a implementação dos objetos e artefatos do Projudi fazendo uma varredura no fluxo de chamadas de classes.

1.1 Propósito

O propósito do documento é fornecer um modelo de implementação baseada na utilização do framework torque e a capacitação para a manutenção do mesmo sem prejudicar a arquitetura atualmente utilizada pelo sistema.

1.2 Referências

1. Using the RUP to evolve a legacy system [PK]

2. http://db.apache.org/torque/ [TR]

3. Design Patterns [GA]

4. Core J2EE Patterns [DA]

1.3 Visão Geral do Manual Técnico

Serão representados, nas seções seguintes os detalhes significativos da tecnologia e linguagem assim como a implementação utilizadas tendo o Projudi um padrão de desenvolvimento será suficiente demostrarmos o caso de uso Registra Enquadramento da vara criminal e o Turma Recursal.


http://db.apache.org/torque/

http://www-106.ibm.com/developerworks/rational/library/389.html

Projudi Versão 2.0



1.4 Tecnologia e Linguagens do Projudi

O projeto engloba tecnologia de implementação com uso das IDEs software livre Eclipse ou Netbeans, servidor de aplicação Tomcat, banco de dados MySQL ou Oracle, repositório de códigos SVN, para relatórios Ireport com o Jasper e linguagem de programação JAVA, linguagem SQL ANSI para integração com o banco relacional, tecnologia web do Java Servlet 2.4 e scriptless JSP 2.0 no front end junto com HTML e Javascript, ANT que se utiliza de linguagem XML e certificado digital, criptografia e HTTPS.

1.5 Representação das Camadas de desenvolvimento

O sistema está dividido em camadas distintas onde cada uma tem sua responsabilidade definidas em sua forma arquitetural é deve ser seguindo esse padrão de construção de qualquer novo caso de uso para mantermos consistente e com qualidade de desenvolvimento a estrutura da aplicação.

As camadas estão dispostas em Camada de Apresentação, Camada de Controle, Camada de Negócio, Camada de Mapeamento Objeto-Relacional, Camada de Persistência. Veremos na seção que se segue a descrição da importância de cada camada do Projudi.

2. Tecnologia e Linguagens do Projudi

O Projudi é uma aplicação web feita com os paradigmas do software livre se utiliza de linguagem de programação Java, que é uma linguagem de programação robusta madura e com os conceitos de orientação a objeto. A maior vantagem do Projudi em usar a linguagem Java é o fato da portabilidade de plataforma e principalmente a segurança. Também se agrega ao Projudi a tecnologia web do Java 1.6.x no Servlet 2.4 e JSP 2.0 alem das paginas criadas com HTML e Javascript para uso de dinamismo nas telas. A Interface de desenvolvimento padrão é o Eclipse com servidor de aplicação Jakarta Tomcat 5.5.x e o banco de dados MySQL 5.x.

Usado o Apache Torque para inter facear a camada lógica com a camada de dados. A camada lógica pode ser dividida em três partes:

1. Modelo lógico: contém os beans que representam as entidades mapeadas pelo Torque e responsáveis pela abstração das peças manuseadas pelo Projudi. Podem ser entendidas como os objetos persistentes.

2. Certificação: contém as funcionalidades necessárias ao esquema de certificação, atuando como autoridade registradora e ou certificadora e oferecendo métodos para a checagem de assinaturas e geração de identidades digitais implementadas com o padrão Creator.

3. Controle: pode ser dividido em duas partes. A primeira corresponde à porção inteligente do Projudi que, seguindo alguns padrões de projeto como o Template Method, Expert, Façade e Singleton, implementam a manipulação das tramitações nos processos, desde a verificação de permissão à gravação no banco. A segunda, corresponde ao controle de acesso às páginas, implementadas pelos servlets segunda a especificação Java Servlet, sendo portanto, através dos JSPs, a interface com o usuário. Além disso, dispõe do módulo de upload de arquivo do Projudi.


Projudi Versão 2.0



A camada de apresentação é implementada pelos JSPs segundo a especificação Java Server Pages. O sistema de upload de arquivos do Projudi é praticamente um módulo a parte pois realiza todo o processo de verificação de assinatura e de checagem de anti-vírus. Através desse módulo, o Projudi se comunica com o anti-vírus ClamAV.

Como todo o tráfego WEB no Projudi é criptografado, um servidor WEB com suporte a criptografia SSL (HTTPS) se faz necessário, sendo então usado o Apache HTTP. O requisito de criptografia é mandatório, portanto o usuário deve ter um navegador que suporte o protocolo HTTPS e deve aceitar confiar no certificado raiz do Projudi (no caso em que o Projudi atuará como própria autoridade certificadora SSL), ou no certificado raiz da autoridade certificadora que emitiu o certificado SSL para o Projudi. Além do suporte à criptografia SSL, o navegador do usuário deve suportar HTTP 4.1 e JavaScript 1.2 e é recomendável que se tenha uma máquina virtual Java instalado caso se queira usar o Applet Jus Signer para assinaturas on-line(versão mínima Java JRE 1.4.2).

O Projudi pode ser entendido como um sistema construído sobre um pequeno framework que provê algumas estruturas básicas. Sua funcionalidade principal é fornecer o subsistema de autenticação e gerenciamento de permissões. A autenticação atua junto ao gerenciamento de permissões e é baseada em grupos. As permissões incluem restrições de horário ou de acesso do grupo ao sistema ou parte dele determinada pela política de acesso. Um exemplo de uma política de acesso é não permitir que um advogado (usuário que pertence ao grupo advogado) faça uma sentença (atividade restrita ao grupo Juiz Togado). Essas políticas de acesso são hardcoded e se dá através de métodos sobre o Servlet que implementa a atividade e são chamados pelo gerenciador de permissões do framework. Para tanto, o framework define uma classe ProjudiServlet que deve ser herdada por todos os servlets do sistema.

O restante da implementação do Projudi é realizada através do acréscimo dos seguintes módulos a esse subsistema inicial mencionado anteriormente:

2.1 Beans

Os beans são gerados automaticamente pelo Apache Torque seguindo o esquema de banco de dados especificado em XML. Sobre esses beans são acrescentados parte do business logic do sistema seguindo o modelo orientado a objetos.

2.2 Controle e gerenciamento de permissões

Contém o business logic do Projudi, sendo responsável pelo gerenciamento de toda a tramitação processual. Este módulo é o responsável por, atuando em conjunto com o gerenciador de permissões, traduzir as requisições dos usuários em eventos sobre o processo, desde a sua criação através da petição inicial até a fase recursal e arquivamento. Além dos eventos sobre o processo, pode iniciar as ações de integração com o SISCOM, disparar o envio de e-mail ou receber as requisições do módulo de execuções automáticas. O Controle também gera os logs do sistema.


Projudi Versão 2.0



2.3 Execuções automáticas

Determinadas atividades processuais são executadas automaticamente pelo Projudi, como por exemplo a checagem de um decurso de prazo, o cumprimento automático de intimações ou de citações, a geração da lista de revogação de certificados e etc. Para esse fim, o módulo de execuções automáticas contém uma thread que executa em intervalos de tempo configurado nas propriedades do sistema. No intervalo de tempo especificado, é disparado um evento para se iniciar todos os processos que necessitam de execução automática. Em caso de erro, um e-mail de aviso é enviado a todos os administradores.

2.4 Geração de certificados

O Projudi implementa uma autoridade certificadora. Contém as funcionalidades que tratam desde a geração de certificados raízes e SSLs, autenticação de certificados e atua como autoridade registradora, gerando e gerenciando as identidades digitais e a lista de revogação de certificados (CRLs).

2.5 Upload de arquivos

Devido à complexidade da inserção de arquivos num processo judicial digital, houve a necessidade de criação de um módulo à parte. Esta complexidade decorre do fato de que todo arquivo inserido num processo deve estar assinado e certificado por uma autoridade seguindo as políticas de segurança definidas pela mesma. Por isso, o módulo de controle delega ao módulo de upload as atividades de manter os arquivos em local temporário até que sejam submetidas as transações, checar a assinatura digital do arquivo e verificar a existência de vírus. O módulo de upload detecta automaticamente os arquivos assinados pelo applet Jus Signer de forma on-line. A verificação de assinatura inclui a validação da identidade junta à lista de revogação de certificados da autoridade que a emitiu.

2.6 Verificação de Assinatura

Como o sistema exige a certificação com assinatura digital dos documentos inseridos, é necessário o uso de um software adicional que é disponibilizado na página inicial para assinar os documentos, ou outro software que gere arquivos com assinaturas anexadas padrão PKCS#7. Há ainda a possibilidade de que esses documentos sejam assinados com o uso do Applet Java Jus Signer que é carregado automaticamente sempre que há a possibilidade de se inserir arquivos. O requisito para executar esse applet é que o navegador tenha instalado uma máquina virtual Java 1.4.2 ou superior. Os conteúdos editados on-line por parte dos juízes e servidores devem obrigatoriamente ser assinados via o Applet.


Projudi Versão 2.0



2.7 Verificação de Vírus

Embora o Projudi não abra ou execute qualquer arquivo inserido nos processos, tornando impossível a contaminação do mesmo, há o risco em potencial para os usuários do sistema. Cabe aos usuários manterem seus programas anti-vírus atualizados, entretanto o Projudi realiza uma checagem adicional com a finalidade de evitar a encubação de vírus dentro do sistema possibilitando a contaminação a posteriori de outros usuários que venham a fazer uso dele. O módulo de verificação de vírus se comunica com o anti-vírus ClamAV através de uma conexão ou através do protocolo JNI (disponível apenas caso o Projudi seja instalado num sistema Linux®).

2.8 JusSigner

Executa no cliente. É um programa fornecido gratuitamente aos usuários do Projudi sob a forma de um applet ou standalone. Ambos requerem que esteja instalada na máquina do usuário uma máquina virtual Java 1.4.2 ou superior. Sua finalidade é anexar aos documentos uma assinatura digital no padrão PKCS#7.

2.9 Envio de e-mails

O Projudi tem internamente um MTA(Mail Transfer Agent), que possibilita o uso de qualquer servidor STMP configurado com o nome do domínio, e uma série de métodos para criação e envio de e-mails quando da ocorrência de nova intimação, citação ou para notificar os administradores sobre a ocorrência de erros fatais.

2.10 Sistema de arquivos

A gravação das peças processuais quando submetidas as transações se dá em duas partes. Na primeira, os beans gerados são gravados no Banco de Dados relacional (tarefa delegada ao Torque). Na segunda os arquivos assinados são gravados no sistema de arquivos do servidor nos diretórios definidos no arquivo de propriedades do Projudi. Além dos arquivos processuais, os certificados, as identidades, os arquivos temporários e os logs residem no sistema de arquivos. Nas propriedades do Projudi devem ser definidos:

• O diretório das âncoras de confiança, formadas pelos certificados raízes das ICPs que são aceitas pelo sistema.

• O diretório raiz dos processos. O Projudi utilizará este diretório e criará um hierarquia de subdiretórios para guardar os processos. A finalidade desses subdiretórios é diminuir a latência na busca por arquivos à medida que o número de processos aumentar e evitar se atingir o limite de número de arquivos abertos (por diretório) no sistema durante seu funcionamento.


Projudi Versão 2.0



• O diretório temporário, que será usado pelo módulo de upload para guardar os arquivos até que sejam submetidas as transações.

• O diretório de identidades, que contém as identidades digitais dos usuários do sistema. É recomendado o uso do sistema de arquivos ReiserFS para guardar as identidades a fim de se evitar latência caso o número de usuários cresça.

2.11 Integração.

O Projudi faz integração com o Siscom e na versão 1.9 foi implementado um webservice para fazer a integração com o sistema que roda nas delegacias e no MPU.

2.11.1 Siscom

Tem a função de inserir os dados na tabela de integração com o Sistema de Comarcas Informatizadas (SISCOM). Atua como um tradutor dos eventos gerados pelo módulo de controle após uma transação bem sucedida.

2.11.2 WebService

Tem como função gerar uma integração entre sistemas e na comunicação de aplicativos diferentes. No caso do Projudi o aplicativo tem um webservice para integrar com o sistema de delegacias e o do MPU. Com está integração o usuário se beneficia de não ter que cadastrar os dados duas vezes, ele faz o a inserção normal dos dados no software que ele já esta acostumado a usar e o webservice trata de transferir os dados para dentro do Projudi.

2.12 Framework Torque

Torque é um framework de persistência para Java, onde os objetos são armazenados através do mapeamento objeto-relacional. O projeto Torque é mantido pela Apache Software Foundation e distribuído pela licença Apache 2.

Diferente de outras ferramentas que também fazem uso do mapeamento objeto-relacional, o Torque não faz uso de reflexão para acessar as propriedades das classes Java e então gerar um banco de dados que atenda um mapeamento. No Torque as classes a serem persistidas são geradas a partir de um esquema XML que descreve, além do mapeamento objeto-relacional, o projeto do banco de dados. Assim, as classes Java a serem persistidas não precisam ser programadas visto que elas são geradas a partir do que foi modelado no esquema XML.

O principal objetivo do Torque é o uso de Java para manipulação de um banco de dados. Isso facilita as operações com informações visto que a linguagem de consulta própria do banco de dados é substituída


Projudi Versão 2.0



por métodos Java. Assim, o modelo de persistência acaba perdendo um pouco de sua transparência, visto que nesse caso o modelo relacional tem reflexo direto no modelo de classes e não o contrário. Desse modo, como o projeto Torque foca diretamente na criação de um conjunto de classes a partir de um modelo relacional, o esforço em realizar esse mapeamento quando já se tem um modelo de classes bem definido pode acabar gerando um esforço consideravelmente maior frente a abordagens mais transparentes.

3. Ambiante de Desenvolvimento e Produção

Vamos fazer uma breve apresentação de como estão atualmente a confiuguração dos ambientes de desenvlvimento e de produção para analize de o que o programador do sistema vai ter que configurar e o que está configurado no ambiente de homologação e de Produção respequitivamente, pois assim podemos ter uma melhor visão das ocorrencia para correção no ambiente de produção

3.1 Ambiente de Produção

Na infra de Produção temos uma Plataforma de captação das operações das estações dos usuários que executa o servidor de aplicações do Projudi (atualmente o Tomcat 5.5 em sistema operacional Red Hat 5) instalados em uma maquina IBM.

3.2 Ambiente de Desenvolvimento

O ambiante de desenvolvimento está configurado com o sistema operacional Windows XP, IDE Eclipse ou NetBeans com servidor de aplicação Tomcat 5.x e banco de dados MySQL 5.x ou Oracle 9. Toda a codificação e os artefatos e documentos do Projudi estão em um repositório de código utilizando o SVN(SubVersion). Para a configuração do ambiente de desenvolvimento temos um documento auxiliar de configuração do ambiente, onde mostra os passos necessários para a instalação dos Softwares para o inicio da codificação.

3.3 Infra-Estrutura/Configuração

A camada de infra-estrutura contém a base de classes e serviços para ser usada na camada de casos de uso. Essa camada contém configurações especificas de cada estado, layout da pagina principal, o contex.xml com as configurações de conexão com o banco de dados e os torque.properties e projudi.properties com as configurações de link, email e parâmetros do sistema.


4. Camada de Apresentação

A camada de apresentação consiste na interface do sistema com o usuário como o Projudi é um sistema WEB sua tela de apresentação e montada com HTML, javascript e JSP disponivel nos browsers Firefox e Internet Explore. O autor do caso de uso faz a chamada de alguma tela do sistema para preenchimento e envio dos dados, nesse momento a camanda de apresentação faz as validações no momento antes do envio para verificar campos obrigatorios e parametros que devem ter a devida formatação, posteriormente manda os dados, via método POST, para a camada de controle.

Os applets também fazem parte da camada de apresentação tendo o Projudi o seu pricipal componente em applet o assinador digital, que faz a configuração e validação da assinatura eletrônica.

Importante lembrar que todos os dados que trafegam via Projudi, seja na intranet ou internet, estão sendo feitos devidamente criptografados e sempre com a solicitação do certificado digital para o protocolo de segurança o HTTPS

5. Camada de Controle

O controle e feito pelo tecnologia de utilização da servlet. Todas as requisições vindas da camda de apresentação passam pelo servlet principal que é o ProjudiServlet que faz o controle das requisições e repassa para a camada de negócio. Também possue a responsabilidade de fazer a checagem das assinaturas, o controle de acesso as funcionalidade do Projudi e a verificação de virus e é nessa camada é implementado o padrao de projeto Template Method.

6. Camada de Negócio

Camada responsavel pela validação da regra de negócio fazendo o controle das regras recebendo da camada de controle a requisição com destino certo a classe que vai operar a verificação da regra disposta nesse requisito funcional podendo retornar para a aplicação caso tenha feito uma validação que não deve passar para a camada de persistencia.

Módulo responsavel pelas execuções automaticas do sistema, possue classes Beans para representação dos objetos de negócio e fazem o envio de emails. Nessa camada foi implementado o padrão de projeto Facade.

7. Camada de Mapeamento Objeto-Relacional

Responsavel pela criação do mapeamento do banco de dados com o objeto relacional gerados pelo framework Torque e será utilizado na camada de persistencia. O torque faz nesse módulo criação de beans que contemplo a parte do básico que uma classe de persistencia precisa.

8. Camada de Persistencia

Depois de toda a validação realizada na camada de negócio for realizada com sucesso esta camada recebe o objeto no qual ira trabalhar a persistencia dos dados em um SGBD.

A classe tem a denominação do caso de uso e com a terminação Peer, essa classe tem o seu esqueleto gerado pelo framework Torque compreendendo os metodos básico para uma classe de persistencia, incluir, excluir, pesquisar e alterar, sendo é claro possivel de incluir novos metodos que atendam ao caso de uso.

O torque tem sua propria maneira de lidar com persistencia de dados é na maioria das vezes não se utiliza da liguagem convencional SQL para realizar as querys no banco de dados. Todas as classes geradas automaticamente herdam de BasePeer.java que é onde são montados os parametros básicos de


persistencia de dados. A figura a seguir exemplifica o fluxo de requisição entre as camadas.

9. Novas Funcionalidades do Projudi 1.9

O Projudi começou como um projeto final de curso de dois estudantes por isso foi natural ele sofrer diversas modificações e melhorias que ajudaram na evolução do software recebendo a contribuição de vários tribunais estaduais. Atualmente todos vem trabalhando junto ao CNJ no aperfeiçoamento do Projudi que chega ao lançamento da verção 1.9 que contempla varias novas funcionalidades que veremos a seguir.

• Links de acesso rápido as atividades a serem executadas através da página inicial de cada perfil (solução do TJBA).


• Melhoria na navegabilidade da paginação das principais telas do sistema, permitindo acessar a listagem através de uma página específica e ordenar por alguns campos chaves.

• Exibir na consulta pública somente o nome da parte, semelhante ao que acontece hoje com a do Portal.

• Ao invalidar uma movimentação de “Autos Conclusos” e “Expeça-se”, cancelar, respectivamente, a conclusão aberta para o juiz e a solicitação de expedição de intimação, citação, cumprimento ou notificação.

• Permitir redistribuir processos de um juiz desabilitado ou suplente.

• Permitir a movimentação em lote para o “Diretor de Turma Recursal”.

• Inclusão do filtro por número do recurso, número do processo, juiz relator (magistrado) e sessão de julgamento. O nome do juiz relator passa a ser exibido abaixo do número do recurso.

• Na tela de cadastro de ação de 2º grau só poderão ser selecionadas classes de competência originária da Turma Recursal.

• Incluído o acesso ao “Diretor de Turma Recursal” e os “Técnicos de Turma Recursal” à tela de cadastro de ação originária de Turma Recursal.


• Criada validação para quando se tentar retornar os autos da Turma Recursal para a vara de origem, verificar se há alguma conclusão aberta para juiz relator ou presidente.

• Ao subir os autos à Turma Recursal, se já houver um recurso para o processo, esse recurso será vinculado à mesma Turma Recursal e ao mesmo Juiz Relator.

• Criada a variável de modelos $seedTurma que adequa o SEED à Turma Recursal.

•Permitir eliminar da listagem os processos paralisados que se encontram em pelo menos uma das situações:

▪ Processos na Turma Recursal.

▪ Processos aguardando audiência.

▪ Processos conclusos para juiz.

▪ Processos em algum órgão externo ou contador.

▪ Processos com cumprimento aguardando prazo.

▪ Processos com movimentação aguardando prazo.

• Permitir haver mais de uma parte com o mesmo CPF/CNPJ, carteira de identidade, carteira profissional


de trabalho e título de eleitor.

• Permitir selecionar uma parte no cadastro da ação através de uma pesquisa prévia.

• Permitir selecionar uma parte no cadastro da ação através de uma pesquisa prévia.


Cadastrar nova parte através de um novo CPF/CNPJ ou sem informar este documento.

Cadastrar autoridades ou entidades como parte de um processo.

Cadastrar parte a partir de uma pesquisa.

• Incluída aba para visualização das alterações executadas sobre a parte (auditoria).

• O endereço deixa de ser uma informação obrigatória.

• “Distribuidor” e “Técnico Judiciário” passam a poder alterar também os dados da parte.

• “Distribuidor”, “Técnico Judiciário”, “Assessores de Magistrado”, “Advogado”, “Promotores”, “Autoridades Policiais” e “Usuários de Cartório Extrajudicial” passam a poder cadastrar partes avulsas.

• Os mandados passam a ser assinados pelo “Diretor de Secretaria”, conforme dispositivo legal, art. 225, VI, do CPC e regulamentado pela Corregedoria-Geral de Justiça do Estado. O “Técnico Judiciário” poderá expedir o documento, para assinatura do “Diretor de Secretaria”.

• Os cumprimentos poderá ser assinados em lote pelo juiz.

• Os mandados passam a exibir um seqüencial de acordo com o número da ocorrência deste cumprimento no processo. Opcionalmente, será possível visualizar o “apelido” do juiz do processo nesse identificador.

• Definido um novo fluxo para o alvará através de movimentações:

▪ Expedição de alvará – quando a expedição de alvará for solicitada.

▪ Alvará expedido(a) pela secretaria e enviado(a) ao juiz – quando a secretaria redige o texto do alvará e o encaminha ao juiz para que ele assine.

▪ Alvará assinado – quando o juiz assina o alvará.

▪ Alvará à disposição – quando o alvará retorna à secretaria para que ele possa intimar a parte para vir buscá-lo.


Para informar que uma alvará está à disposição (voltou à secretaria), deve-se movimentar o processo.

Quando o juiz assina o alvará.

Quando o escrivão redige o alvará.

Ao solicitar a expedição do

• O modelo de alvará passa a retornar dados do beneficiário ou de seu procurador.

• Permitir pesquisar na tela de “Buscar por Movimentações” por processos cuja a última movimentação for a selecionada.

• Agrupar as funcionalidades da tela de movimentação para que o usuário controle a visualização somente daquilo que ele queira executar.

• Eliminada a tela intermediária de inclusão de arquivos, quando for possível dispensar arquivo. Se for necessário inseri-lo, deverá ser feito diretamente da tela de movimentação.

• Foi incluída na tela de movimentação processual, para o perfil de “Juiz Togado”, a facilidade de delegar à secretaria a movimentação processual.


Se o beneficiário não tiver

Se o beneficiário tiver

• Relatório de audiências marcadas para hoje e pendentes.

• Inclusão do filtro por urgência na tela de “Análise de Juntada”.

• Inclusão do filtro por urgência na tela de “Expedição de Cumprimentos”.

Varias outras funcionalidades ainda estão sendo desenvolvidas para a nova release do Projudi e outras que não foram contempladas ainda podem ser melhor estudadas em questão de regras de negócio em documento auxiliar.

Nas novas funcionalidades foi criado uma tag lib <PAG> que implementa a ordenação com método genérico GenericPaginationPeer.java. Faz paginação indo direto na pagina requirida e pode ordenar pela coluna disposta na pagina , classe responsável pela tag lib é a PaginadorTag.java que herda de BodyTagSupport.

Código de importação da tag lib:

<%@ taglib prefix="pag" uri="http://tjmg.jus.br/projudi/paginador" %>

A padronização de nomenclatura dos .jsp que apresentam listagem de pesquisa é de iniciar com Lista<nome do caso de uso>.jsp em todos esses arquivos estão exemplos de utilização do componente de paginação.

Funcionalidades de pesquisa que tiveram alterações com inclusão de novos foram somente incluindo


novos parâmetros de pesquisa “CRITERIA” no método de pesquisa do torque. Em alguns casos a pesquisa deve alterações devido a complexidade e foi necessário montar um sub-select de pesquisa do torque como vemos no exemplo a seguir:

sub-select na cláusula from:Cria-se uma tabela que será a nossa sub-select, e adiciona-se um “alias” dessa tabela ao torque. Após adicionar a tabela com o “alias”, é possível referenciá-la normalmente como os Peers mapeados.

Criteria criterioBusca = new Criteria();

String subSelect = "(SELECT * FROM Recurso R WHERE R.NUMEROPROCESSO="+this.getNumeroprocesso()+" AND EHACAODE2GRAU=0)";

criterioBusca.addAlias("Rec", subSelect);

criterioBusca.addJoin(MovimentacaoPeer.CODRECURSO, "Rec.CODRECURSO", Criteria.LEFT_JOIN);

criterioBusca.add(MovimentacaoPeer.NUMEROPROCESSO, this.getNumeroprocesso());

MovimentacaoPeer.doSelect(criterioBusca);

Resultado da Query:

SELECT Movimentacao.CODDOCUMENTO, ...

FROM Movimentacao

LEFT JOIN (SELECT * FROM Recurso R WHERE R.NUMEROPROCESSO=xxxxxxx AND EHACAODE2GRAU=0) Rec

ON Movimentacao.CODRECURSO=Rec.CODRECURSO WHERE Movimentacao.NUMEROPROCESSO=xxxxxxxx

sub-select na clausula “WHERE”

Cria-se a consulta sql como ela deve ser feita em uma variável String e use-a como parâmetro para o método add do Criteria, sendo “Criteria.CUSTOM”, o parâmetro de comparação utilizado.

Criteria criterioBusca = new Criteria();

criterioBusca.add(RecusoPeer.NUMEROPROCESSO, numeroProcesso);

String query = RecursoPeer.CODRECURSO +" = (Select max(codrecurso) from Recurso r where r.numerorecurso = "+RecursoPeer.NUMERORECURSO+" group by r.numerorecurso)";

criterioBusca.add(RecursoPeer.CODRECURSO, (Object) query, Criteria.CUSTOM);

RecursoPeer.doSelect(criterioBusca);

Resultado da Query:


Select Recurso.NUMEROPROCESSO, …

FROM Recurso

WHERE Recurso.NUMEROPROCESSO = xxxx

AND Recurso.CODRECURSO = (Select max(codrecurso) from Recurso r where r.numerorecurso=xxxx group by r.numerorecurso);

10. Casos de Uso - Fluxo da aplicação

Esta seção foi elaborada para abordamos o fluxo de chamada de camadas de dois casos de uso um da vara criminal e outro da turma recursal. Exemplificando o funcionamento interno das suas operações e métodos utilizados. Foram escolhidas esses dois casos porque a arquitetura do Projudi esta montada dentro de padrões de projeto e boas praticas de desenvolvimento junto com o Framework Torque que é a metodologia aplicada, sendo assim podemos seguir pelos casos de usos Registrar Enquadramento, um cenário da vara criminal, e o caso de uso Turma Recursal, pois eles englobando como exemplo para qualquer outro caso de uso que for preciso de manutenção ou nova funcionalidade a ser desenvolvida como parâmetros de desenvolvimento do Projudi.

10.1 Registrar Enquadramento

O caso de uso “Registra Enquadramento” faz parte do módulo de conjuntos de funcionalidades da vara criminal. Ele é responsável pelo registro do enquadramento da parte no processos judiciais criminal do sistema. A figura a seguir mostra o diagrama de caso de uso.

O diagrama a seguir demostra como funciona o fluxo de atividades desse caso de uso e a explicação que se segue vem para mostrar o funcionamento interno desse cenário:


O sistema exibe a tela de busca de processo “ListaProcesso.jsp” depois usuário preenche filtros desejados e executa a requisição que vai no servidor através do método POST, saindo da camada de apresentação e chegando ate a camada de controle na classe ProjudiServlet.java que faz a verificação de permissão de acesso e encaminha a requisição para a respectiva classe de domínio na camada de negócio, classe chamada Enquadramento.java pertencente ao pacote projudi.beans. Uma vez na classe responsável pelo tratamento da regra de negócio tendo validado tudo sem restrições seguindo um fluxo feliz o Enquadramento que herda de BaseEnquadramento.java vai passar o objeto para a a classe EnquadramentoDTO.java que é o arquivo java responsável pela transferência do objeto para a camada de persistência. Já na camada de persistência a classe EnquadramentoPeer.java que faz parte da metodologia do torque framework se utilizara do objeto EnquadramentoMapBuilder.java que é o nosso objeto relacional, fara a persistência do dado se utilizando da escolha do usuário. Caso tenha sido excluir ele executara o método padrão do torque para excluir o registo ou caso, seja incluir ele fara o uso do método de inclusão do torque. O arquivo BaseEnquadramentoPeer.java é gerado automaticamente pelo Torque montando o mapeamento e as operações básicas de persistência, incluir, excluir, alterar e pesquisar. Como podemos ver como foi montada a classe BaseEnquadramento vendo o diagrama de classe:


10.2 Turma Recursal

O “Turma Recursal” representa uma cenário do Projudi para fazer a movimentação do processo para a turma recursal em todo seu fluxo. Antigamente o processo quando voltava para a turma recursal era redistribuído já nesta versão o processo volta para a turma que estava jugando o mesmo.

Inicio do caso de uso:

O sistema faz a apresentação da tela inicial para o usuário que no nosso caso pode ser a tela de Manter Recurso onde o usuário pode dentro de algumas funcionalidades fazer a busca por recursos. Somente pode existir um recurso de um processo cadastrado que ocorre na parte principal do sistema o caso de


uso “Cadastro de Ação ”(ver documento de arquitetura). Uma vez no Manter Turma Recursal o usuário tem como fazer movimentação do recurso para adicionar documentos, cadastrar partes do recurso, listar os recursos assim como podemos ver no diagrama a seguir todos as funcionalidades ligadas ao Manter Turma Recursal:

Os círculos amarelos indicam funcionalidades implementadas nessa versão que fazer parte da Turma Recursal, os círculos verdes são recursos usados de tabelas auxiliares pertinente a todo o sistema e os círculos brancos são as funcionalidades do Manter Turma Recursal.

Na parte do banco de dados foi feita alterações relevantes que podem ser vista no MER da Turma Recursal:


O núcleo das atividades do fluxo da turma recursal podem ser vistar no diagrama geral da Turma Recursal:

A parte das funcionalidades internas não foge do padrão utilizado no caso de uso visto anteriormente da vara criminal “Registrar Enquadramento”, visto que o sistema do Projudi se utiliza de padrão de desenvolvimento solido.

O fluxo segue TurmaRecursal.jsp que é a tela exibida ao usuário faz a chamada a camada de controle via POST a requisição chega na classe do servlet principal ProjudiServlet.java que vai validar a permissão do usuário depois encaminhar o request para a classe de domínio Recurso.java que se dividi em outras classes de negócio para fazer a tarefa de validar toda a regra de negócio que finalizado o processamento com sucesso vai encaminhar para um objeto DTO(Data Transfer Object), que tem o papel de transacionar o objeto para a camada de persistência na classe RecursoPeer.java que herda de BaseRecursoPeer.java, que é o arquivo gerado automaticamente pelo Torque, que então pegara o objeto RecursoMapBuilder.java para fazer a persistência no banco de dados.

Então o que difere de um caso de uso para o outro é o fato de ter mais entidades relacionadas ao seu processamento como é o caso da Turma Recursal, que alem do fluxo básico opera pelo uso de outras classes principalmente da MovimentaçãoPeer.java, ProcessoPeer.java e ConclusaoPeer.java. Toda vez que o caso de uso tiver a necessidade de buscar dados de outras tabelas já mapeadas ele se utilizara dos objetos que estão disponíveis não podendo criar o mapeamento na classe executora do processo e nem pedir para o Torque gerar algo que esta concretizado dentro do Projudi. Na construção de casos de uso novos onde novas tabelas sejam criadas, somente nesse caso o deve se usar a facilidade do Torque de mapear essa nova tabela e criar o arquivo Base<nome do caso de uso>Peer.java.

Diagrama da classe TurmaRecursalPeer.java lembrando que essa classe herda de BaseTurmaRecursalPeer:


11. Erros Freqüentes

O objetivo da visão lógica é representar a estrutura de relacionamento entre os elementos arquiteturais da aplicação, definindo seus padrões e conceitos gerais, enfatizando principalmente o tempo de compilação. Nesta seção, inicialmente apresenta-se a estrutura de camadas arquiteturais do Projudi.

11.1 O sistema não desenha toda a tela de resumo de dados do processo:

• Sistema não registrou o login do usuário que designou uma audiência de instrução e julgamento.

• Cadastrar incidente no sistema de comunicação de erros do CNJ, informando o número do processo e o nome do usuário que movimentou a audiência.

11.2 Ao tentar abrir um arquivo é exibida a mensagem “Error decoding byte source”:

• Arquivo assinado através do JusSigner.

• Se a movimentação for recente, solicitar que o usuários utilize o assinador interno do Sistema CNJ através do Internet Explorer.

• Se a movimentação for antiga (já houve sentença etc), cadastrar incidente no sistema de comunicação de erros do CNJ, informando o número do processo, o número do evento e o nome do arquivo.


11.3 Lentidão na rede:

Problema de infra-estrutura interna do tribunal.

11.4 Problemas de máquina, instalação, configuração, vírus:

Problema de suporte técnico interno do tribunal.

11.5 Problemas ao assinar no Mozilla/Firefox:

• O problema pode ser a versão do navegador.

• Utilizar as versões inferiores a 3.0 do Firefox ou utilizar o Internet Explorer.

11.6 Problemas ao assinar utilizando o Windows Vista:

Instalar o Java em diretório diferente do “Arquivos de Programas”.

11.7 Erro ao movimentar processo com solicitação de expedição de cumprimento:

Verificar se não há “vírgulas” no nome da parte.

11.8 Erro ao expedir citação, cumprimento, intimação, notificação:

Verificar se não há “apóstrofos” no nome da parte.

11.9 Não é possível arquivar um processo sem documentos:

• Não foi criada a pasta onde são salvos os arquivos do processo.

• Cadastrar incidente no sistema de erros do CNJ, informando o número do processo.

11.10 Não é possível gerar uma identidade digital para um usuário:

Verificar se não há “vírgulas” no e-mail ou no nome do usuário.


11.11 Mensagem de sítio não recomendado:

Instalar as cadeias de certificação da Prodemge (vide tela inicial).

11.12 Lentidão ao abrir um processo:

• Ao abrir um processo, é definida a previsão de audiência de “Conciliação” e “Instrução e Julgamento”.

• Irregularidades no cadastro da pauta da vara/juiz dificultam a determinação da data e horário disponíveis para marcação de nova audiência.

• Períodos de indisponibilidade da vara/juiz para marcação de audiência, obriga o sistema a analisar um intervalo muito grande de tempo (solução na 1.9 do TJBA).

11.13 Reconhecimento de certificados A3:

Instalar as cadeias de certificação na pasta onde são salvos os certificados.

11.14 Para os demais casos:

Criar incidente no sistema de erros do CNJ, informando se possível o número do protocolo (caso haja), a mensagem que aparecer, “screenshot” da tela, o número do processo/recurso e o passo-a-passo do que foi feito para dar o erro.

12. Próximas Leituras

Este manual do Projudi 1.9 representa um dos principais documentos para a documentação técnica das definições gerais do projeto. Servindo de apoio para o novo programador/mantenedor do Projudi para de forma mais eficaz e eficiente poder atender as demandas de manutenção de desenvolvimento de novas funcionalidades.

Todos os artefatos incluídos nesse documento estão disponíveis no repositório do SVN para melhor visualização.

Recomenda-se a leitura dos demais volumes, de acordo com a necessidade. São eles:

• Documento de Visão Geral

• Documento de Arquitetura

• Manual de Configuração do Ambiente


manual - projudi 1

Documents