Universidade de Brasília
Instituto de Ciências Exatas Departamento de Ciência da Computação
Modelagem de processos do Código de Processo Penal com BPMN
José Antonio Siqueira de Cerqueira
Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação
Orientador
Prof. Dr. Francisco Assis Cartaxo Pinheiro
Brasília
2017
Universidade de Brasília
Instituto de Ciências Exatas Departamento de Ciência da Computação
Modelagem de processos do Código de Processo Penal com BPMN
José Antonio Siqueira de Cerqueira
Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação
Prof. Dr. Francisco Assis Cartaxo Pinheiro (Orientador) CIC/UnB
Prof. Ms. Fernando Antônio de A. C. de Albuquerque Prof. Dr. Marcos Fagundes Caetano
CIC/UnB CIC/UnB
Prof. Dr. Rodrigo Bonifácio de Almeida
Coordenador do Bacharelado em Ciência da Computação
Brasília, 01 de novembro de 2017
Dedicatória
Dedico a meus pais, Teresa Cristina e Aluízio, e minha irmã, Elza Francinet, que sempre me deram suporte e são os maiores exemplos na minha vida. A Juliana Loureiro, cujo carinho me deu força e coragem. A todos meus colegas e amigos, que me apoiaram nesta longa jornada, estavam lá nos momentos mais difíceis e nunca deixaram eu desanimar.
Ao Prof. Dr. Francisco Assis Cartaxo Pinheiro, que me conduziu ao longo deste trabalho com sabedoria, paciência e amorosidade.
Agradecimentos
Agradeço ao apoio recebido pelos meus pais, sem vocês nada disso seria possível. Agradeço aos professores e mestres que me inspiraram. Aos meus amigos, Caio, Flávio e Lucas, pela longa amizade inabalável. Agradeço ao Rene, Fernando, Paulo Ricardo, Patrick, Yuri, Pimenta, João Henrique, Gustavo, Cristoffer e demais companheiros e compan- heiras de curso, os quais compartilhamos obstáculos e alegrias, sempre seguindo em frente.
Agradeço aos professores Fernando Albuquerque e Marcos Caetano por aceitarem par- ticipar da banca de avaliação e contribuirem com suas experiências e conhecimentos.
Resumo
Esta monografia consiste em um estudo sobre a adequação de uma notação de mode- lagem de processos – a BPMN – à área legal. A modelagem de processos jurídicos está em crescimento no campo da informática legal, principalmente, no que concerne a admin- istração pública e e-Government. A maioria dos trabalhos propostos na área possuem um viés administrativo e, como contrapartida, este trabalho surge para abordar um caráter muitas vezes negligenciado: o normativo. Prover uma representação gráfica de processos jurídicos pode ser uma grande vantagem para aqueles que querem entendê-las e analisá- las, como cidadãos e juristas. Neste trabalho, modelamos algumas fases do Código de Processo Penal, fazendo uso somente do texto legal, de forma a propor modelos que relacionam os artigos com os elementos da BPMN. Por meio dos diagramas produzidos, buscamos facilitar o entendimento destas fases e das competências dos envolvidos. Esta monografia contribui apontando a importância da modelagem de processos jurídicos e apresentando possíveis dificuldades. Trabalhos futuros incluem melhorias no uso dos ele- mentos da BPMN, relacionamento aprofundado das leis com estes elementos e execução dos diagramas.
Palavras-chave: BPMN, Código de Processo Penal, Modelo de Negócio
Abstract
This monograph consists of a study on the adequacy of a process modeling notation – BPMN – to the legal area. The modeling of legal processes is growing in the field of legal informatics, mainly in what concerns the public administration and e-Government. Most of the works proposed in the area have an administrative bias and, as a counterpart, this work arises to address a topic often neglected: the normative one. Providing a graphical representation of legal processes can be of great use for those who want to understand and analyze them, such as citizens and jurists. In this work, we model some phases of the Criminal Procedure Code, using only the legal text, in order to propose models that relate the articles to the BPMN elements. Through the diagrams produced, we seek to facilitate the understanding of these phases and the competences of those involved.
This monograph contributes by pointing out the significance of modeling legal processes and to show possible difficulties. Future work includes improvements in the use of BPMN elements, in-depth relationship of laws with these elements, and the execution of diagrams.
Keywords: BPMN, Code of Penal Procedure, Business Model
Sumário
1 Introdução 1
1.1 Contextualização . . . 1
1.2 Motivação . . . 1
1.3 Objetivos . . . 2
1.4 Metodologia e Descrição dos capítulos . . . 2
2 Modelagem de Processos de Negócio 4 2.1 Conceitos e objetivos . . . 5
2.1.1 Processos . . . 5
2.1.2 Metodologias . . . 6
2.1.3 Métodos, Notações e Modelos . . . 6
2.1.4 Modelagem de Processos . . . 6
2.2 Descrição e notações da modelagem de processos . . . 8
2.2.1 BPMN . . . 8
2.2.2 UML . . . 9
2.2.3 EPC . . . 10
2.3 Modelando processos com a BPMN . . . 11
2.3.1 Especificação da BPMN . . . 12
2.3.2 Elementos da BPMN . . . 12
3 Modelagem de Processos Jurídicos 18 3.1 Aspectos Preliminares . . . 18
3.2 Objetivos da modelagem de processos jurídicos . . . 20
3.3 Formas de modelagem de processos judiciais . . . 20
3.3.1 Linguagem/Notação de modelagem de processo . . . 22
3.4 BPMN e a modelagem de processos jurídicos . . . 22
4 Modelando as Fases do Processo Penal com BPMN 24 4.1 Inquérito policial . . . 24
4.1.1 Atividades da Autoridade Policial . . . 27
4.1.2 Atividades do Juiz . . . 30
4.1.3 Atividades do Ministério Público . . . 32
4.1.4 Atividades do Interessado ou Vítima . . . 32
4.2 Denúncia . . . 34
4.2.1 Atividades da Pessoa Pública . . . 36
4.2.2 Atividades do Ministério Público . . . 36
4.2.3 Atividades do Juiz . . . 39
4.2.4 Atividades do Procurador-Geral . . . 40
5 Discussões e Conclusões 41 5.1 Tratamento de tempo e prazos . . . 41
5.2 Inter-relacionamento normativo . . . 42
5.3 Detalhamento do texto legal . . . 44
5.4 Conclusões . . . 45
Referências 47 Apêndice 48 A Exemplo de Dificuldade na Modelagem 49 A.1 Queixa . . . 49
A.1.1 Atividades do Ofendido . . . 50
A.1.2 Atividades do Ministério Público . . . 52
A.1.3 Atividades do Juiz . . . 54
Lista de Figuras
2.1 Atividade . . . 13
2.2 Eventos de Lançamento . . . 14
2.3 Eventos de Captura . . . 15
2.4 Gateways . . . 16
2.5 Fluxos de Sequência . . . 16
2.6 Contêineres . . . 17
2.7 Anotação . . . 17
3.1 Exemplo de modelo de processo de negócio gerado para parte do procedi- mento de aplicação de reunificação familiar pela Lei Italiana de Imigração. Extraído de Ciaghi e Villafiorita [1]. . . 22
3.2 Modelagem do processo de elaboração de defesa. Extraído de Andrade et al [2]. . . 23
4.1 Inquérito Policial . . . 26
4.2 Inquérito Policial - Autoridade Policial . . . 31
4.3 Inquérito Policial - Juiz . . . 31
4.4 Inquérito Policial - Ministério Público . . . 33
4.5 Inquérito Policial - Interessado ou Vítima . . . 34
4.6 Denúncia . . . 35
4.7 Denúncia - Pessoa Pública . . . 36
4.8 Denúncia - Ministério Público . . . 38
4.9 Denúncia - Juiz . . . 40
4.10 Denúncia - Procurador-Geral . . . 40
5.1 Denúncia - Ministério Público . . . 42
5.2 Denúncia . . . 44
5.3 Denúncia - Juiz . . . 44
A.1 Queixa . . . 51
A.2 Queixa - Ofendido . . . 53
A.3 Queixa - Ministério Público . . . 54 A.4 Queixa - Juiz . . . 56
Capítulo 1 Introdução
1.1 Contextualização
O uso de modelos de processo para descrever, organizar e manter os processos organi- zacionais já está consolidado no domínio dos negócios, existindo várias linguagens que possibilitam a criação, verificação e automação dos processos. Esta tecnologia também vem sendo aplicada a outros domínios, como os processos criativos e os processos gover- namentais.
Entretanto, no domínio jurídico, há poucos avanços em relação aos processos judiciais regulados por lei. Até o momento, a maior parte das iniciativas que buscam modelar pro- cessos jurídicos são voltadas para o aspecto administrativo de tais processos: questões de remessa de citações, recebimento de petições, informações sobre o andamento, calendário de julgamentos, etc. Os aspectos relacionados às atividades dos operadores do direito são pouco explorados.
Neste trabalho, apresentamos o uso de uma linguagem de modelagem de processos aplicada à modelagem de tais atividades: atividades estas realizadas pelos juízes, advo- gados e demais operadores de direito.
1.2 Motivação
As administrações públicas continuam enfrentando problemas quanto à complexidade da legislação e à crescente evolução do corpo de leis. As leis são continuadamente adiciona- das, alteradas e revogadas, causando inconsistências as quais podem passar despercebidas por décadas. Isso só reforça a necessidade de se desenvolver uma notação que permita en- tender o que está definido legalmente e, possivelmente, identificar inconsistências e sugerir mudanças.
Não podemos subestimar o fato de que as leis são, principalmente produto de represen- tações políticas, as quais podem ter uma agenda que não inclui facilitar o entendimento.
Isto representa o obstáculo principal à introdução da modelagem de leis como uma ferra- menta para formalizar o projeto de leis. Além disso, é necessário notar que a interpretação de textos legais para um não-jurista é um gargalo.
A motivação do trabalho relaciona-se à importância dos processos jurídicos e ao tra- tamento ainda deficiente que a modelagem de tais processos recebe.
Isso se deve em parte à complexidade dos procesos jurídicos e à sua especificidade;
por serem processos normatizados por lei, não há uma força cogente que os obriga. Por outro lado, na prática, algumas das disposições legais não são cumpridas como estão no texto legal: às vezes porque a lei utiliza conceitos abertos a diferentes interpretações; às vezes porque a interpretação dada pelo juíz em um caso concreto diverge da normalmente esperada por razões de equidade e outras vezes porque simplesmente a realidade ultrapassa o que para ela é prescrita.
Por isso, consideramos que uma utilização que busque modelar alguns desses processos possa ser útil para aclarar os pontos complicados da tarefa genérica de modelar processos jurídicos. Entretanto, não se pretende solucionar o problema da compreensão e dificul- dades dos textos legais – problema esse que talvez nunca venha a ser solucionado, dado os seus aspectos políticos e sociais – o que se procura é demonstrar que os avanços técni- cos em um domínio eminentemente político, são úteis na medida que liberam as pessoas de atividades rotineiras e possibilitam que elas se envolvam na tarefa maior de fazer, interpretar e aplicar as leis, com maior segurança.
1.3 Objetivos
O objetivo do trabalho é verificar a adequação da notação BPMN para a modelagem dos processos jurídicos enquanto procedimentos e atividades reguladas por lei, não abran- gendo os aspectos administrativos ou operacionais. Pretende-se verificar se os conceitos da BPMN são adequados a essa tarefa.
1.4 Metodologia e Descrição dos capítulos
A BPMN foi escolhida como linguagem por ser uma notação de amplo uso na modelagem de processos organizacionais, já existindo várias ferramentas que auxiliam sua utilização.
Para a modelagem propriamente dita, escolheu-se enfocar alguns artigos do Código de Processo Penal tendo em vista que já há trabalho semelhante utilizando a BPMN para a modelagem de processos disciplinados por artigos do Código de Processo Civil. Isso
nos permitirá cotejar nossas observações em relação à modelagem do Código de Processo Penal com as observações realizadas no trabalho que aplicou a mesma notação ao Código de Processo Civil.
O desenvolvimento do trabalho está organizado do seguinte modo:
• No Capítulo 2, discutimos a modelagem de processos de negócios e apresentamos as característicadas da notação BPMN.
• No Capítulo 3, apresentamos as características dos processos jurídicos e fazemos uma discussão sobre o uso da BPMN para modelar esse tipo de processo.
• No Capítulo 4, apresentamos a modelagem dos seguintes processos jurídicos: Inqué- rito Policial e Denúncia. Os dois são disciplinados pelo Código de Processo Penal e nossa modelagem utiliza apenas o texto da lei. Esses processos foram escolhidos por serem os processos iniciais em toda ação penal e por serem mais próximos, e portanto, mais fáceis de serem entendidos pelos cidadãos.
• No Capítulo 5, apresentamos as discussões com as observações relativas aos processos modelados e nossas conclusões.
Capítulo 2
Modelagem de Processos de Negócio
Em 1903 surgia o primeiro trabalho com intenção científica sobre a Administração, escrito por F. W. Taylor, Princípios da Administração Científica. Foi o ponta pé inicial de como compor um modelo de gestão adequado. Desde então houve um crescimento da quantidade de propostas de tal finalidade. A Gestão por Processos é a mais recente. Seu objetivo é contribuir para a sistematização da estrutura de qualquer organização. A diferença é que este modelo conta com softwares que apoiem sua atuação sobre o modelo funcional proposto. É o instrumento de ligação entre o que se faz na organização. Visa facilitar a comunicação e a cooperação. Também serve de elo entre as estratégias e as competências organizacionais e as atividades diárias.
Há um erro fundamental que as empresas, organizações, cometem. Consiste em pri- meiro comprar o software para depois pensar no modelo, quando o inverso é o recomen- dado. Outro erro fundamental é primeiro automatizar os processos sem antes introduzir o modelo de Gestão por Processos na sua cultura organizacional.
Embora trabalhosa, a Análise e Modelagem de Processos dá a base para se avançar com segurança na longa jornada da Gestão por Processos. Não recomenda-se saltar essa etapa.
Em continuação ao contexto histórico, no século XX, a Segunda Guerra Mundial após seu fim trouxe grandes transformações para as práticas gerenciais. A orientação dos mo- delos de organização da produção e das práticas gerenciais das empresas até este momento era de uma abordagem clássica, o comportamento das variáveis eram previamente defini- dos. Estes modelos serviram ao seu papel histórico, pois eram suficientes na época, além de conduzir às transformações seguintes. Ao fim da guerra a necessidade era renovar o processo de producação com tecnologias disponibilizadas pelo esforço bélico e imprimir agilidade ao processo decisório. Após a crise do petróleo nos anos 70 e a queda do Muro de Berlim, levantou-se a complexidade e a instabilidade no cenário mundial. Assim foi dada mais importância a flexibilidade, que passou a ser um imperativo para lidar com a
realidade contemporânea nas organizações.
As abordagens em Gestão da Produção que surgiram após os anos 80 têm como núcleo a visão de processos. É o caso das normas ISO 9000 e 14000, do método de custeio ABC, dos softwares de ERP (Enterprise Resource Planning), da reengenharia etc.
Desde o início do século passado, era comum, ao olhar as organizações, vê-las pela sua estrutura vertical, exibida nos organogramas. O foco foi deslocado para a dimensão horizontal, atualmente. Ou seja, o foco está no encadeamento (processo) das atividades de produção. Antes, olhava-se para a empresa e apenas via-se as funções, agora, enxerga-se também seus processos.
Nos últimos anos houve um crescimento em softwares, ferramentas de TI, que remo- veram passos manuais para aumentar a confiança e eficiência da modelagem de processos.
Controlar a sequência das interações do programa e fluxo de informação, e conhecer o es- tado do fluxo, são fundamentais para as funções de uma empresa. Automatizar, monitorar e otimizar o fluxo é o campo do gerenciamento de processo de negócio.
Neste capítulo será abordado os principais conceitos envolvendo o Gerenciamento por Processos necessários para a finalidade deste trabalho, algumas ferramentas de modelagem de processos mais difundidas, e ao final será apresentado a BPMN e o porquê de ser a ferramenta escolhida para a finalidade deste trabalho.
2.1 Conceitos e objetivos
O Gerenciamento de Processos possui um ciclo próprio – o ciclo do BPM (Business Process Management). A primeira fase deste ciclo é a Análise e Modelagem de Processos, e seu objetivo é, identificar, classificar e mapear os processos chave e críticos. É pela Análise e Modelagem de Process que começa qualquer iniciativa ou projeto de implantação da gestão por processos numa organização.
A seguir são apresentadas algumas terminologias importantes do gerenciamento de processos:
2.1.1 Processos
A ISO 9000 [3] define processo como um conjunto de atividades inter-relacionadas ou interativas, que transformam entradas em saídas.
A BPMN [9] define processo como qualquer atividade desempenhada no interior da organização. No modelo de processos, é retratada como uma rede constituída por outras atividades em fluxo e por seus respectivos controles de sequenciamento (eventos e junções).
Um processo de negócio contém um ou mais processos.
Para Davenport [4], processo é:
simplesmente um conjunto de atividades estruturadas e medidas, destinadas a resul- tar num produto especificado para um determinado cliente ou mercado. Portanto, é uma ordenação específica das atividades de trabalho no tempo e no espaço, com um começo, um fim e inputs e outputs claramente identificados: uma estrutura para a ação. Continuando, os processos são a estrutura pela qual uma organização faz o necessário para produzir valor para os seus clientes. Os processos precisam de donos claramente definidos, que sejam responsáveis pelo projeto e execução e que façam com que as necessidades dos clientes sejam satisfeitas.
Entretanto, não há uma classificação (taxonomia) única de processos. A definição de processos em uma organização depende de uma convenção interna.
2.1.2 Metodologias
Passos ou etapas e critérios a serem seguidos em um projeto ou atividade, por exemplo, nas atividades de análise e modelagem de processos. Alguns exemplos de metodologias na gestão de processos são: o Ciclo da Modelagem, como o Ciclo do BPM.
2.1.3 Métodos, Notações e Modelos
Métodos são procedimentos ou maneiras escolhidas para realizar atividades. A análise e modelagem de processos é um método na gestão de processos.
Práticas ou conjunto de métodos (conjunto de objetos ou símbolos de modelagem de processos) são chamados de notações. Alguns exemplos de notações do gerenciamento de processos são a UML, o EPC, e o BPMN. Estas notações serão exploradas neste capítulo.
Por fim, modelos são formas de representação da realidade ou de objetos reais. São os desenhos, fluxogramas e diagramas. Os DPN (Diagramas de Processos de Negócio) da BPMN são modelos de negócio. Ou seja, é o produto da modelagem de negócios.
Segundo Oliveira [5]:
Os modelos simulam o objeto representado, comportando-se como tal, e um modelo de negócio usa diagramas para a representação lógica da estrutura e funcionalidade do negócio, mostrando a relação entre seus processos, subprocessos e atividades, se- gundo o fluxo natural de execução das atividades, construído a partir da observação e estudo do mundo real. De modo geral, é a identificação dos componentes de um negócio, organizando-os segundo seus relacionamentos.
2.1.4 Modelagem de Processos
Modelagem de processos é dada como uma ferramenta estratégica no campo de desenvol- vimento de processos e controle de processos. É usada para apresentar certos aspectos de um sistema já existente, ou de um sistema a ser desenvolvido, através de modelos. De
acordo com Oliveira [5]: a modelagem visa criar um modelo de processos por meio da construção de diagramas operacionais sobre seu comportamento.
Modelagem de processos é um conjunto de ferramentas e notações. Como uma no- tação ele permite a compreensão e conceitualização de processos complexos em volta de nós – às vezes muito caros ou difíceis de serem testados –, que se transformam na base para discussão, análise, projeto, otimização e documentação. Nos fornece um me- cânismo para decompor processos grande em pedaços pequenos chamados sub-processos.
Os sub-processos são pedaços completos dentro deles mesmos, mas mesmo assim, eles estão relacionados com o processo principal.
A modelagem serve para validar o projeto, testando suas reações sob diversas condi- ções para certificar que seu funcionamento atenderá aos requisitos globais estabelecidos – qualidade, performance, custo, durabilidade etc.
Com o uso dos mapas de processos fica mais fácil identificar e tratar as armadilhas da narrativa/linguagem natural: falta de estruturação, ambiguidade, redundância e omissões.
A modelagem propõe entender e repensar a empresa procurando assegurar a mesma visão entre todos os participantes e setores envolvidos no âmbito do modelo em construção e, mais especificamente, para:
• Entender o negócio através do comportamento dos processos, permitindo a identifi- cação de seus requisitos, retrabalhos, gargalos, ineficiências;
• Padronizar conceitos, compartilhar visões e sistematizar o conhecimento, unificando a linguagem entre a equipe de processos, usuários, área de TI e demais profissionais envolvidos no projeto
• Analisar oportunidades de melhorias e monitoramento dos processos através de si- mulações de seu funcionamento e reengenharia dos mesmos
• Melhorar a qualidade e produtividade dos produtos e serviços, por meio da racio- nalização dos processos
Em suma, a Modelagem de Processos é visto como Análise e Modelagem de Processos no contexto da BPM. Mais precisamente, é a primeira fase do ciclo da BPM (Business Process Management). A Análise e Modelagem de Processos são atividades voltadas ao levantamento, identificação, descrição, desenho e documentação de processos.
A Análise e Modelagem de Processos é o que será feito neste trabalho com auxílio da BPMN e seus Diagramas de Negócio para representar algumas partes do Código de Processo Penal.
2.2 Descrição e notações da modelagem de processos
A finalidade deve estar determinada antes de começar a modelar. Cada propósito requer que se faça um tipo específico de modelagem. E para cada tipo de modelagem é preciso escolher bem que tipo de modelo é mais apropriado.
A seguir, são apresentadas algumas notações utilizadas na modelagem de processos de negócio e alguns fundamentos inerentes a essas notações. As mais difundidas atualmente são a BPMN, UML (Unified Modeling Language), e EPC (Event-driven Process Chain).
2.2.1 BPMN
O BPMN é um padrão para modelagem de processos. Sua criação se deu através de uma fusão entre o BPMI (Business Process Management Initiative) e a OMG (Object Management Group). O BPMN é caracterizado como uma notação especialmente voltada para a definição e documentação de processos de negócio com padrões de linguagem bem definidos. O BPMN é o resultado de um esforço conjunto de empresas, que já possuíam suas próprias notações, a buscar uma ferramenta de modelagem com uma linguagem única e padrão. Com este padrão para a modelagem de processos de negócio diminui-se o custo com treinamento, pois o entendimento é simplificado para o usuário final.
O Business Process Diagram (BPD), ou o Diagrama de Processo de Negócio (DPN) é a saída gráfica de um modelo de processos no BPMN. É o único modelo de diagrama que o BPMN possui. Esse diagrama é capaz de ilustrar diversos tipos de modelagem de processos, onde estão dispostos os diversos elementos que formam um modelo.
É uma das notações mais amplamente aceitas, também por estarem respaldadas pela OMG e BPMI, grupos consolidados e reconhecidos. Ademais, o BPMN possui vários elementos de modelagem, porém, somente quatro são os elementos mais utilizados: ati- vidades, eventos, gateways e sequência de fluxos. O BPMN então é fácil de aprender e simples de utilizar.
Os fornecedores de softwares de análise e modelagem de processos estão cada vez mais introduzindo a BPMN em seus pacotes. Estima-se que está presente em mais de 40 softwares atualmente, dentre estes: WBI Modeler (IBM), ARIS Business Architect (IDS Scheer), Intalio Designer, TIBCO Business Studio, iGrafx, Savvion Process Modeler, BizAgi. Sendo estes exemplos de software que oferecem suporte para o uso do BPMN.
Principais Vantagens do BPMN:
• A OMG faz a padronização e gestão da BPMN
• Oferece um padrão de notação com suporte em várias ferramentas de modelagem, como Activiti [6] e Flowable [7]
• BPMN permite a conversão de seus DPN para a linguagem de execução de processo de negócio BPEL – Business Process Execution Language
• Incopora facilidades de notações como o UML/AD (tal notação explicada a seguir) Principal desvantagem do BPMN:
• Focado apenas em processos, não é destinado ao manuseio de diferentes visões
2.2.2 UML
A notação UML (Unified Modeling Language) foi originada como uma metodologia para suporte ao desenvolvimento de softwares. É uma linguagem de representação gráfica.
É especificada e controlada pelo Object Management Group. Os objetivos da UML [8]
são: visualizar, especificar, construir e documentar softwares orientados a objetos. É uma notação de modelagem de processos que busca a qualidade da identificação dos requisitos funcionais e não funcionais. Os requisitos funcionais são as necessidades do procedimento de negócio em análise, ou seja, o que o procedimento de negócio em análise precisa fazer.
Os requisitos não funcionais são os que oferecem suporte aos requisitos funcionais, como usabilidade, disponibilidade, arquitetura, segurança etc.
Atua como uma notação padrão de modelagem por modelar processos de negócio carac- terizando seus aspectos conceituais e requisitos. O Diagrama de Atividades, ou UML/AD (Activity Diagram), é a ferramenta gráfica da UML, onde está representado o modelo de processo de negócio. O Diagrama de Atividades “descreve o fluxo de um processo, atividade, ou workflow, definindo o controle da sequência das ações que o compõem.” [5].
É usado para modelagem de processos e subprocessos, além, claro, das suas atividades correspondentes.
Por ser apenas uma notação padrão (conjunto de convenções de modelagem), a UML é independente da metodologia de modelagem de processos empregado. A versão da UML (2.0) dispõe de um conjunto de 13 diagramas, sendo mais abrangente que sua versão anterior. Permite a modelagem e criação de 13 diferentes tipos de modelos. Para cada tipo de informação há um modelo diferente.
Categorias que os diagramas da UML estão inseridas:
• Para a modelagem de estruturas: são ao todo seis diagramas: de classe, de com- ponentes, de objetos, de estrutura, de composição, de desdobramento e de pacote (package).
• Para a modelagem de comportamento: são sete diagramas, mas que estão organi- zados em dois conjuntos:
– Para a modelagem de comportamento, propriamente dito: são três diagramas:
de atividade, de caso de uso e estado de máquina;
– Para a modelagem de interação entre componentes ou pessoas: são quatro diagramas: de sequência, de visão global da interação, de comunicação e de controle de tempo.
Há amplas opções quanto ao software ao se utilizar para modelar processos com UML.
Muitas delas são open source. Algumas das ferramentas mais conhecidas são: Rational ROSE, VISIO, Star UML, Visual-Paradigm, MagicDraw, ArgoUML, Eclipse UML2 Tools, entre outros.
Vantagens do uso da UML:
• Tanto o técnico de TI como o analista de negócio podem ter um entendimento fácil da notação
• Pessoas diferentes na organização podem dispor de modelos diferentes, que descre- vem outros tipos de informação
• Grande número de diagramas, permitindo capturar cada aspecto do objeto que está sendo modelado. Ou seja, permite modelagem tanto de funções e processos, como desenho da base de dados, arquitetura de aplicações, entre outros;
• A notação da UML é padronizada e usada por muitas ferramentas de softwares dedicadas ao desenho de processos de software
Desvantagens:
• A UML foi desenvolvida com foco na engenharia de software
2.2.3 EPC
A notação EPC (Event-driven Process Chain) é voltada para a "modelagem de processos essencialmente baseada no controle de fluxos de atividades e eventos e suas relações de dependência" [5]. Esta notação foi desenvolvida pelo Institute for Information Systems e SAP. Faz parte do framework da ferramenta ARIS (ARchitecture for integrated Infor- mation Systems), da IDS Scheer. Algumas ferramentas que utilizam a EPC são: ARIS Business Architect (IDS Scheer AG), VISIO (Microsoft) e EPC-Tools (Open Source). Há uma grande aceitação pelo fato de ser o elemento central de integração da plataforma ARIS.
A EPC é utilizada como “elo central de integração conceitual das visões: organização, função, controle, dados e saída” [5] do ARIS. A EPC é uma linguagem com objetivos
diversificados, além da construção de um modelo, também contempla as ações de análise, simulação e otimização de processos. Isso se deve ao fato da ferramenta ARIS possuir um vasto conjunto de recursos.
O fluxo de trabalho da EPC é constituído de um conjunto básico de objetos:
Funções: correspondem a atividades (processos, subprocessos, atividades ou tarefas), assim como nas outras notações, representam a base de um modelo, uma unidade de trabalho.
Eventos: representam um aspecto anterior ou posterior à execução de uma função. As funções se relacionam utilizando eventos.
Conectores: Definem o controle do fluxo, ou seja, as regras da sequência do fluxo. São de 3 tipos: XOR, AND e OR.
Controles do fluxo: São usados para ligar os eventos, funções e conectores. É o caminho que o fluxo deve seguir.
Vantagens do uso da EPC, segundo Oliveira [5]:
• Notação gráfica simples e intuitiva, capaz de descrever estruturas complexas de processos e atividades
• Capacidade de exportação para vários formatos padrões
• Pode integrar elementos de diferentes visões
A principal desvantagem da EPC é não possuir uma entidade independente para gerir sua padronização.
2.3 Modelando processos com a BPMN
As notações apresentadas anteriormente apresentavam alguns problemas em comum, como: são proprietárias, ou incompletas, ou incompatíveis com outros modelos, espe- cialmente modelos de processos de negócio que demandam recursos de Tecnologia de Informação. Algumas dessas notações somam todos esses problemas. Para este trabalho será utilizado a notação BPMN.
Segundo Oliveira [5], a BPMN é um padrão desenvolvido que visa :
oferecer uma notação mais facilmente compreendida e usada por todos os envolvidos nos processos de negócio: dos estrategistas e analistas de negócio (que criam versões iniciais dos processos) aos técnicos responsáveis pela seleção e implementação das tecnologias que apoiarão o gerenciamento e monitoramento desses processos.
A BPMN é uma notação abrangente. Oferece recursos para a modelagem de distintos tipos de processos, dos mais genéricos aos específicos. Pode ser usada para modelar processos de qualquer tipo de natureza, como: administrativos (compras, vendas, etc), financeiros (empréstimos, controle de capital, etc), operacionais (manutenção, fabricação, etc), desenvolvimento de software, de serviços, etc.
A BPMN continuará sendo a opção mais frequente, por se tratar de um padrão forte e consistente, além de um crescente número de fornecedores de software de modelagem de processos a adotarem como notação padrão.
O propósito principal do BPMN é prover uma notação padrão para modelagem de processos de negócio, para superar as deficiências das outras notações de modelagem.
O BPMN define e usa um único tipo de diagrama, o Diagrama de Processos de Negócio (DPN). Neste diagrama estão dispostos os diversos elementos que compõem o BPMN.
Entretanto, os básicos são apenas quatro: atividades, eventos, gateways (símbolos de decisão) e conectores. Com apenas esses quatro elementos, é possível construir modelos bastante expressivos de processos. Por esses motivos, o BPMN é relativamente fácil de entender, aprender e usar. Também permite a ligação entre o DPN e a implementação desses processos num ambiente operacional. É possível então a automação e execução.
2.3.1 Especificação da BPMN
A BPMN tem suas especificações reguladas pela OMG [9]. A Seção anterior já expressa grande parte do que é esta linguagem. Conquanto, a especificação desta linguagem leva em consideração algumas questões:
Visual: O elemento chave da BPMN é a escolha de formas e ícones utilizados para os elementos gráficos. A intenção é criar uma linguagem com um padrão visual em que todos os que irão modelar os processos a reconhecerão e assimilarão. Todas as implementações que utilizam esta linguagem deverão utilizar os elementos gráficos especificados pela OMG.
Estrutural: O padrão da linguagem é estabelecer conexões e outras relações gráficas entre elementos.
Semântica: Os conceitos usados na definição de processos e associados com os elementos gráficos deverá ter uma interpretação consistente.
2.3.2 Elementos da BPMN
A BPMN é uma notação rica, com muitos detalhes, própria para representar os mais diversos tipos de processos. Nem todos os processos utilizam todos os elementos da BPMN
e nem toda ferramenta implementa todos os elementos. Por conta das atualizações desta notação, os elementos mais que dobraram de 55 para 116, de acordo com White [10]
Nesta seção apresentaremos apenas os elementos utilizados nos diagramas usados no Capítulo 4 para modelar os processos jurídicos.
Como expressado anteriormente na Seção 2.2.1, os elementos da BPMN 2.0 podem ser categorizados em quatro diferentes grupos. Segundo White [10], estes grupos são:
Objetos de Fluxo, Objetos de Conexão, Containers e Artefatos, mostrados a seguir, com a descrição de alguns de seus elementos:
Objetos de Fluxo
São empregados para estabelecer o comportamento de um processo de negócio. Apresen- tamos os três objetos de fluxo:
Atividade(Activity): Tarefa desempenhada e que será executada por um agente/ator.
Pode ser uma tarefa atômica ou um conjunto de tarefas, denominado de subprocesso.
Um subprocesso contêm um outro diagrama de processo, sendo seu evento inicial vazio. A atividade é representado por um retângulo de cantos arredondados.
Figura 2.1: Atividade
Evento(Event): Usado para modelar alguma coisa que acontece durante o curso do pro- cesso de negócio. Estes eventos afetam o fluxo do processo. Sempre visualizados como círculos. Existem duas principais categorias:
1. Eventos de Lançamento(Throwing Event): Disparam um gatilho quando a exe- cução de um processo chega neste evento. O ícone interno deste evento é preenchido com a cor preta. É destacado que Eventos Finais são sempre de lançamento.
• Evento Final Vazio(None End Event): o resultado lançado quando o evento é alcançado não é especificado, e a execução é terminada.
• Evento Final de Erro(Error End Event): ao chegar neste evento, o caminho de execução atual é terminado e um erro é lançado. Poderá ser capturado por um evento de captura de erro correspondente, caso contrário uma exceção será lançada.
• Evento Intermediário de Lançamento de Sinal(Signal Intermediate Th- rowing Event): Primeiramente, o sinal é um evento de escopo global, e é entregue à todos os manipuladores ativos, os que estão esperando para capturar Eventos de Sinais. Este evento lança um Evento de Sinal para um sinal definido.
Figura 2.2: Eventos de Lançamento
2. Eventos de Captura(Catching Event): esperam por um gatilho. O ícone interno não é preenchido, ou seja, é branco. Em particular, os Eventos Iniciais são sempre de captura.
• Evento Inicial Vazio(None Start Event): o gatilho para iniciar o processo não é especificado.
• Evento Inicial de Mensagem(Message Start Event): o gatilho para iniciar o processo é uma mensagem.
• Evento Inicial de Erro(Error Start Event): o gatilho para iniciar o processo é feito a partir de um evento de lançamento de erro.
• Evento Intermediário de Captura de Sinal(Signal Intermediate Catching Event): o gatilho para se continuar no fluxo de sequência deste evento é a captura um sinal.
• Evento Intermediário de Captura de Tempo(Timer Intermediate Catching Event): é um evento que atua como um cronômetro. Quando uma execução chega neste evento, um temporizador é iniciado e sua execução suspensa.
Ao disparar o temporizador, ou seja, após passar o intervalo de tempo especificado, o fluxo de sequência que sai deste evento é seguido.
• Eventos de Fronteira(Boundary Events): são eventos de captura que estão acoplados à uma Tarefa. O gatilho para iniciar a Tarefa é aquele que o evento está ouvindo, e quando o evento é capturado, o curso do processo é interrompido e o fluxo de sequência que sai do evento, acoplado à Tarefa,
é seguido. Dentre os Eventos de Fronteira está o Evento de Sinal de Fron- teira(Signal Boundary Event), que captura um sinal com o mesmo nome de sinal.
Figura 2.3: Eventos de Captura
Gateways: Usados para controlar a divergência e convergência do Fluxo de Sequência.
Irá determinar decisões, bifurcações e uniões de caminhos. O ícone deste objeto de fluxo é visualizado como a forma de um diamante.
• Gateway Exclusivo(Exclusive Gateway): Usado para modelar decisões no pro- cesso. Também chamado de Gateway XOR.
• Gateway Paralelo(Parallel Gateway): Usado para modelar concorrência em um processo. Possibilita a bifurcação em múltiplos caminhos de execução ou a união de um ou mais caminhos entrantes de execução. Ao ter dois ou mais Fluxos de Sequência chegando neste Gateway, este irá esperar, e só avançará com a processo quando todos os fluxos anteriores forem executados antes.
• Gateway Inclusivo(Inclusive Gateway): Usado para unir diversos Fluxos de Sequência. Entretanto, em diferença ao Gateway Paralelo anterior, ao ter dois ou mais Fluxos de Sequência chegando nele, este também irá esperar, porém a execução de um deles será suficiente para avançar a execução. Em seguida da união efetuada pelo Gateway Inclusivo, o processo continuará.
• Gateway Baseado-em-Evento(Event-based Gateway): Usado para permitir uma decisão baseada em eventos. Cada saída deste Gateway é necessariamente conectada a um Evento Intermediário de Captura. Quando a execução de um processo chega em um Gateway Basead-em-evento, a execução é suspensa. É criado uma inscrição aos Eventos Intermediários de Captura. Assim, espera-se qual Evento chegará o seu lançamento correspondente, e o Fluxo de Sequência seguirá deste Evento.
Figura 2.4: Gateways Objetos de Conexão
Estão em um diagrama para criar a estrutura do processo de negócio. Conectam as Atividades, os Eventos e os Gateways.
Fluxo de Sequência(Sequence Flow): é o conector entre elementos de um processo.
A Figura 2.5 ilustra dois Fluxos de Sequência. O primeiro conecta um Evento Inicial Vazio à uma Tarefa, enquanto o segundo conecta a Tarefa à um Evento Final Vazio.
Figura 2.5: Fluxos de Sequência
Contêineres
São mecanismos para organizar as atividades em categorias separadas visualmente, com o intuito de ilustrar diferentes responsabilidades. Os dois tipos de Contêineres são:
Piscina(Pool): Ilustra as responsabilidades de uma Entidade de Negócio. Isso é, cada Piscina representa uma Entidade de Negócio, como visto na Figura 2.6. Os Fluxos de Sequência não poderão cruzar de uma Piscina à outra. Por este motivo, cada modelo criado apresentará apenas uma Piscina.
Raia(Lane): Ilustra as atividades associadas a um ator específico. Os Fluxos de Sequência poderão cruzar de uma Raia à outra. Uma piscina poderá conter uma ou mais Raias.
Figura 2.6: Contêineres Artefatos
Elemento extra que não altera a estrutura básica do processo de negócio, demarcado pelas Atividades, Gateways e Fluxo de Sequência. Ou seja, seu uso no diagrama é dispensável.
Anotação(Annotation): É um mecanismo que contribui para a leitura do diagrama ao inserir informação de texto adicional.
Na Figura 2.7, a Anotação explica ao leitor que há um prazo de 24 horas para a Atividade 2 ser realizada, caso contrário encerra-se o processo.
Figura 2.7: Anotação
Capítulo 3
Modelagem de Processos Jurídicos
A modelagem de processos jurídicos é o tema a ser explorado neste trabalho. Apesar de sua importância, poucas propostas existem com o propósito de automatizar processos judiciais. Neste capítulo apresentaremos:
1. Certos aspectos motivacionais para a modelagem de processos jurídicos.
2. Os objetivos da modelagem de processos jurídicos.
3. Faremos breve análises de alguns trabalhos encontrados neste âmbito, a fim de abordar:
(a) As formas de modelagem de processos jurídicos. Quais as situações que são empregados.
(b) As linguagens adotadas pelos trabalhos encontrados.
(c) Destacar propostas que utilizam a notação BPMN.
3.1 Aspectos Preliminares
Segundo Toscano et al. [11]:
O Direito é um fenômeno que deve ser concebido a partir de sua dinamicidade, graças às intensas transformações sociais, culturais e econômicas que se inserem em cada momento histórico.
Em foco, está o desenvolvimento da tecnologia da informação, o qual engendrou para- digmas únicos para a sociedade contemporânea. Fez-se necessário repensar os institutos jurídicos com o propósito de englobar a realidade do desenvolvimento social e tecnológico.
Nas palavras de Lindoso [12]:
Um aspecto do problema do acesso à informação, dentro da área jurídica, é a ne- cessidade que os advogados possuem de se manterem atualizados de acordo com as constantes modificações pelas quais a legislação passa.
De acordo com Ciaghi e Villafiorita [1], a modelagem semântica de leis está em cres- cimento no campo da informática legal. Modelagem e análise de documentos legais está cada vez mais sendo usado em práticas e-Government. Prover uma representação gráfica de uma lei pode ser uma grande vantagem para aqueles que querem entendê-las e analisá- las, como os cidadãos e juristas. Bem como os que necessitam implementar as leis. Além disso, modelagem de leis desempenha um papel chave na engenharia de software para a automação de Administração Pública e a implementação de sistemas e-Government.
Ao passo que existe extensa literatura sobre ferramentas e metodologias para analisar, modelar e manipular documentos legais, há uma falta de ferramentas que permita uma completa análise de leis em todos seus aspectos. [13]
Dificuldade semelhante, e talvez até mais grave, enfrentam os operadores de direito em relação aos processos legais nos quais estão envolvidos.
A modelagem de leis auxilia na compreensão do objeto com que lidam aqueles da área jurídica, mas pouco auxiliam no entendimento das complexas relações das atividades que devem ser desemepenhadas no dia a dia. Para isso, a modelagem de processos seria mais útil.
A necessidade de entender os processos legais, vai além da necessidade que se tem para ordinariamente entender os processos administrativos. No domínio jurídico, tem-se, por exemplo, que a sequência e encadeamento de atividades não é rígido, permitindo várias alternativas; outras vezes, há rigidez associado a mecanismos que permitem ultrapassá- las, como ocorre com os prazos impróprios (aqueles que são definidos, mas podem não ser atendidos ou sofrer atrasos). Esses e outros aspectos do processo jurídico, que serão ilustrados adiante, fazem com que a compreensão das atividades seja dificultado. Uma boa notação de modelagem de processos auxiliaria.
Além do aspecto da complexidade das próprias atividades, têm-se que o processo juŕidico em si é normatizado, isto é, definido legalmente. No caso deste trabalho, o processo jurídico que utilizaremos encontra-se definido no Código de Processo Penal.
Entender a lei que regula os processos vai além de entender o significado de seus artigos (o que seria auxiliado pela modelagem de leis). É necessário entender o processo, isto é, as atividades que são determinadas em cada artigo, e como elas se relacionam. Isso só a modelagem de processos provê.
3.2 Objetivos da modelagem de processos jurídicos
Em geral, para qualquer pessoa sem experiência com a área juíridica as leis são extre- mamente difíceis de compreender. Principalmente, a complexidade da linguagem legal é o maior obstáculo, além de uma série de dependências que tornam as leis um sistema enredado complicadas.
Além disso, a utilidade das leis está inclinada à interpretação de uma coleção de documentos, à vista disso, em certo grau é subjetivo.
A despeito de que processos são definidos nas leis geralmente escritos para esta fina- lidade, elas sempre dependem de uma coleção de leis que definem princípios e regras à serem seguidas.
Isto requer uma abordagem holística à modelagem de leis.
A modelagem de processos júridicos possui os seguintes objetivos:
• Facilitar a participação de pessoas a edição de regulamentos, mesmo que elas não tenham experiência com jurisprudência.
• Prover meios efetivos para a compreensão da lei e dos processos que elas determinam.
• Prover uma maneira de efetuar mudanças na lei e acompanhar as dependências entre fontes textuais e modelos.
Estes objetivos abordam as necessidades de quatro potenciais usuários:
Cidadãos: que querem entender as leis, procedimentos e documentos legais em geral sem conhecimento técnico ou expertise legal.
Analistas funcionais: que analisam os processos nas Administrações Públicas ou que necessitam entender os requisitos legais para algum sistema.
Legisladores: que estão encarregados no projeto e edição da legislação. Eles devem ser capazes de facilmente visualizar os documentos, e navegar entre eles. Como também ser capazes de rastrear alterações passadas e dependências a outros documentos.
Juristas: encarregados da aplicação da lei nos casos concretos. São os advogados, juízes, promotores.
3.3 Formas de modelagem de processos judiciais
Grande parte dos trabalhos apresentam modelos para racionalizar os processos adminis- trativos ou as atividades de e-Government.
Dos trabalhos que racionalizam os processos administrativos jurídicos temos o exemplo de Lopes e Teixeira [14]. Os autores propõem um Sistema de Gerenciamento de Processos Jurídicos, o SGPJ. Este software realiza suporte às atividades de um dos profissionais da área judicial, o Advogado. Sejam elas: controlar os documentos de seus clientes, gerar valores de honorários de acordo com cada processo, informar os prazos dos processos, gerar relatórios de processos em aberto ou fechado. Esta proposta procura gerenciar e organizar os documentos do advogado, para que este possa exercer suas funções com mais eficiência. Nesta ferramenta, os Processos Jurídicos, na sigla SGPJ, faz referência aos documentos que o advogado tem que lidar. Fazem mão da notação UML.
Outro exemplo, temos Andrade, et al. [2], que em seu trabalho não procura apresentar uma ferramenta de automação judicial nova, mas descrever o uso do BPM em uma organi- zação privada, no caso, um escritório de advocacia no Brasil. Relata que a iniciativa ainda é imatura, porém promissora. É utilizado o BizAgi Studio - um conjunto de ferramentas BPM - para a modelagem dos processos de negócio, gerando diagramas de negócio na notação BPMN. O uso do BPM nesta organização tem como objetivo, de acordo com os mesmos autores:
Realizar o controle interno dos andamentos dos processos judicias com objetivo de cumprir todas as etapas necessárias, prazos e notificações as partes interessadas no processo, mensurando assim o tempo gasto e a produtividade da equipe da Organização em cada fase do processo.
Dos trabalhos que automatizam atividades governamentais, ou seja, da administração pública, temos os exemplo de Ciaghi e Villafiorita [1]. Estes autores propõem um fra- mework de modelagem de leis, denominado VLPM 2.0. A qual consiste de uma tradução dos textos legais para diagramas BPMN, e alternativamente para diagramas UML. São utilizadas técnicas de modelagem de processos de negócio e ontologias, com o fito de mo- delar documentos legais. São elas a BPMN e o OWL DL [15] (Web Ontology Language), respectivamente. O fito do trabalho é modelar o procedimento de aplicação para reuni- ficação familiar na Itália. O trabalho deles conclue que modelos de processo de negócio não são suficientes para representar todos os aspectos das leis. "Documentos legais, de fato, definem complexas restrições que afetam processos e que não podem ser modeladas como sequências de ações." [1]
Outro trabalho encontrado é o de Olbrich e Simon [16]. Estes também apresentam uma proposta para automatizar processos governamentais. Principalmente, a visualização e modelagem semântica de regulamentações legais. Nesta proposta, os atores abordam um conjunto de parágrafos do Direito das Obrigações Suíça, com o intuito de expor modelos de processos através da notação EPC.
Proposta similar é a de Olbrich e Alpar [17]. Também fazem mão da notação EPC para modelar processos governamentais de administração pública, do Instituto Federal
Alemão de Seguro para Funcionários Assalariados. Relatam que a maioria de ferramentas de modelagem no mercado não oferecem suporte a modelagem de processos públicos.
3.3.1 Linguagem/Notação de modelagem de processo
Lopes e Teixeira [14] apresentam diagramas na linguagem UML. Apesar de esta proposta utilizar modelos de processo, esta está sendo utilizada para a criação do software SGPJ.
Ciaghi e Villafiorita além de representarem diagramas de modelos de processo nas notações UML e BPMN, também dispoem de um framework próprio, o VLPM 2.0, que adiciona informação semântica sobre os processos descritos em textos legais.
Outro que apresenta modelos em BPMN é Andrade et al. [2], ao relatar o uso do BPM em um escritório de advocacia.
Os únicos que usam EPC para a visualização de modelos são as propostas de Olbrich, Simon [16] e Alpar [17].
3.4 BPMN e a modelagem de processos jurídicos
Dos trabalhos que apresentam BPMN a que tivemos acesso, salientamos o de Ciaghi e Villafiorita [1], voltado a e-Government. Neste trabalho há um estudo de caso: a lei italiana de reunificação familiar. É o caso de um imigrante desejar ter seu familiar registrado neste país. Através de seu framework, um modelo BPMN é gerado. Os autores apresentam o seguinte diagrama:
Figura 3.1: Exemplo de modelo de processo de negócio gerado para parte do procedimento de aplicação de reunificação familiar pela Lei Italiana de Imigração. Extraído de Ciaghi e Villafiorita [1].
Na Figura 3.1, o interessado deverá requisitar residência, e esta requisição será proces- sada pelos escritórios de administração pública, a fim de que o ator que iniciou o processo venha a obter o registro do seu familiar. Já é possível notar que os elementos da BPMN utilizados não são todos os relatados na Seção 2.3.1. Reforçando o fato de que as diferentes ferramentas BPMN implementam diferentes elementos da BPMN.
Outro trabalho que explora a BPMN é o de Andrade et al. [2], que relata o uso da BPMN em um sistema jurídico privado para modelar processos administrativos. Os autores apresentam o diagrama da Figura 3.2.
A Figura 3.2 mostra uma pequena parte da modelagem de processo da elaboração de defesa. Há atividades de comunicação entre clientes e advogados através de e-mails, os quais foram automatizados.
Figura 3.2: Modelagem do processo de elaboração de defesa. Extraído de Andrade et al [2].
Capítulo 4
Modelando as Fases do Processo Penal com BPMN
Neste capítulo, serão apresentados os modelos propostos para algumas fases do Código de Processo Penal [18] a fim de explicar o uso da BPMN como ferramenta adequada ao domínio jurídico. Os artigos pertinentes a estas fases serão fornecidos para o entendi- mento da interpretação adotada. Esta relação dos artigos do Código de Processo Penal e dos diagramas – ou seja, os modelos propostos – aparecem como resultado de nossa interpretação dos artigos e conhecimento da notação BPMN.
Os diagramas apresentam-se como a confluência da área jurídica – o entendimento técnico dos artigos modelados – e da área tecnológica – o conhecimento da notação BPMN – de forma que o relacionamento entre os artigos e o diagrama seja o mais completo possível.
A organização utilizada para essa modelagem será feita da seguinte maneira:
1. Breve introdução acerca da fase modelada
2. Apresentação geral do modelo proposto utilizando a BPMN 3. Significação pormenorizada das partes
4. Relacionamento dos artigos com o modelo apresentado
4.1 Inquérito policial
Para que o processo penal se inicie, o Inquérito Policial pode-se fazer necessário: esta etapa trata-se de uma fase administrativa do Código de Processo Penal, ou seja, é um procedimento administrativo de caráter inquisitivo que tem por finalidade colher provas da infração e indícios de autoria, viabilizando o exercício da ação penal.
Segundo o Professor Fernando Capez [19]:
O Inquérito Policial é o conjunto de diligências realizadas pela polícia judiciária para a apuração de uma infração penal e de sua autoria, a fim de que o titular da ação penal possa ingressar em juízo.
O propósito crucial do Inquérito é reunir provas da materialidade e da autoria de determinado crime, as quais servirão de fundamento para o oferecimento da denúncia.
A Figura 4.1 representa a modelagem do Inquérito Policial, cujas atividades serão descritas em seguida.
Nesta figura, vemos os cinco atores presentes no processo de Inquérito Policial, a saber:
a Autoridade Policial, o Juiz, o Ministério Público, o Ofendido e a Pessoa Pública. O Inquérito Policial é representado por uma Piscina e cinco Raias para cada um dos atores envolvidos neste processo.
O Inquérito Policial pode ser iniciado por qualquer um dos cinco atores. O Ofendido e a Pessoa Pública poderão requerer inquéritos e comunicar infrações penais, respectivamente, aos órgãos competentes. O Ministério Público e o Juiz poderão requisitar abertura de inquérito à Autoridade Policial. Por último, a Autoridade Policial poderá dar início ao inquérito de ofício, ela mesma. Desta forma, podemos observar nesta modelagem que existem seis distintas maneiras de se instaurar o inquérito policial – estas serão explicadas mais à diante.
A Autoridade Policial – quem preside o Inquérito – estará incubida, principalmente, de realizar as diligências e de escrever os autos. Nesse contexto, o Juiz e o Ministério Público deverão recebê-los. O Juiz – na ocasião da Autoridade Policial não haver requerido devolução nem novas diligências requisitadas, ou a análise do requerimento de devolução da Autoridade Policial for negada – poderá decidir em arquivar o Inquérito ou remetê-lo ao Ministério Público a fim de que este adote as providências que entender pertinentes.
Figura 4.1: Inquérito Policial
4.1.1 Atividades da Autoridade Policial
O art. 5o, reproduzido em seguida, dispõe que o inquérito será instaurado de ofício (i.e.
pela própria Autoridade Policial) mediante requisição judiciária (i.e. a mando do juiz) ou requisição do Ministério Público, ou do ofendido (i.e. da vítima do crime).
Art. 5. Nos crimes de ação pública o inquérito policial será iniciado:
I - de ofício;
II - mediante requisição da autoridade judiciária ou do Ministério Público, ou a requeri- mento do ofendido ou de quem tiver qualidade para representá-lo.
§ 1oO requerimento a que se refere o noII conterá sempre que possível:
a) a narração do fato, com todas as circunstâncias;
b) a individualização do indiciado ou seus sinais característicos e as razões de convicção ou de presunção de ser ele o autor da infração, ou os motivos de impossibilidade de o fazer;
c) a nomeação das testemunhas, com indicação de sua profissão e residência.
§ 2oDo despacho que indeferir o requerimento de abertura de inquérito caberá recurso para o chefe de Polícia.
§ 3o Qualquer pessoa do povo que tiver conhecimento da existência de infração penal em que caiba ação pública poderá, verbalmente ou por escrito, comunicá-la à autoridade policial, e esta, verificada a procedência das informações, mandará instaurar inquérito.
§ 4o O inquérito, nos crimes em que a ação pública depender de representação, não poderá sem ela ser iniciado.
§ 5o Nos crimes de ação privada, a autoridade policial somente poderá proceder a inquérito a requerimento de quem tenha qualidade para intentá-la.
O diagrama da Figura 4.2, na Página 31, mostra a atividade Iniciar de Ofício, a qual é realizada pela Autoridade Policial no momento em que esta inicia o inquérito por conta própria. A atividade Analisar Requerimento representa o início do inquérito quando motivado por queixa do ofendido ou daquele que tiver qualidade para representá- lo. O início a partir da requisição da Autoridade Judiciária ou do Ministério Público é representado pelas setas que provêm da parte inferior do diagrama e terminam no Gateway Inclusivo conectado à atividade Iniciar Inquérito. A origem dessas setas estão nas raias referentes ao Juiz e ao Minitério Público, assim como é mostrado na Figura 4.1.
A atividade Verificar Procedência também pode iniciar o inquérito policial partindo de uma comunicação de infração feita por qualquer pessoa do povo que não seja o ofendido.
Essa possibilidade é disciplinada no § 3odo art. 5o. Esses elementos do diagrama modelam todas as possibilidades de início do inquérito, conforme disciplinadas no art. 5o.
Como disposto nos arts. 6o e 7o, após a instauração do inquérito, a Autoridade Policial deverá realizar diligências e poderá simular a reprodução do fato relatado:
Art. 6. Logo que tiver conhecimento da prática da infração penal, a autoridade policial deverá:
I - dirigir-se ao local, providenciando para que não se alterem o estado e conservação das coisas, até a chegada dos peritos criminais; (Redação dada pela Lei no 8.862, de 28.3.1994)
II - apreender os objetos que tiverem relação com o fato, após liberados pelos peritos criminais; (Redação dada pela Lei no8.862, de 28.3.1994)
III - colher todas as provas que servirem para o esclarecimento do fato e suas circuns- tâncias;
IV - ouvir o ofendido;
V - ouvir o indiciado, com observância, no que for aplicável, do disposto no Capítulo III do Título Vll, deste Livro, devendo o respectivo termo ser assinado por duas testemunhas que Ihe tenham ouvido a leitura;
VI - proceder a reconhecimento de pessoas e coisas e a acareações;
VII - determinar, se for caso, que se proceda a exame de corpo de delito e a quaisquer outras perícias;
VIII - ordenar a identificação do indiciado pelo processo datiloscópico, se possível, e fazer juntar aos autos sua folha de antecedentes;
IX - averiguar a vida pregressa do indiciado, sob o ponto de vista individual, familiar e social, sua condição econômica, sua atitude e estado de ânimo antes e depois do crime e durante ele, e quaisquer outros elementos que contribuírem para a apreciação do seu temperamento e caráter.
X - colher informações sobre a existência de filhos, respectivas idades e se possuem alguma deficiência e o nome e o contato de eventual responsável pelos cuidados dos filhos, indicado pela pessoa presa. (Incluído pela Lei no13.257, de 2016)
Art. 7. Para verificar a possibilidade de haver a infração sido praticada de determinado modo, a autoridade policial poderá proceder à reprodução simulada dos fatos, desde que esta não contrarie a moralidade ou a ordem pública.
A obrigatoriedade de realizar a diligência é indicada no diagrama pela seta que interliga a atividade Iniciar Inquérito à atividade Realizar Diligência. Já a atividade Simular a Reprodução do ocorrido é de cunho opcional, a qual será executada como resultado do Gateway Exclusivo e indicará a possibilidade de, após as diligências, a Autoridade Policial reduzir por escrito suas conclusões e elaborar minucioso relatório, conforme disposto nos arts. 9o e 10:
Art. 9. Todas as peças do inquérito policial serão, num só processado, reduzidas a escrito ou datilografadas e, neste caso, rubricadas pela autoridade.
Art. 10. O inquérito deverá terminar no prazo de 10 dias, se o indiciado tiver sido preso em flagrante, ou estiver preso preventivamente, contado o prazo, nesta hipótese, a partir do dia em que se executar a ordem de prisão, ou no prazo de 30 dias, quando estiver solto, mediante fiança ou sem ela.
§ 1oA autoridade fará minucioso relatório do que tiver sido apurado e enviará autos ao juiz competente.
...
§ 3o Quando o fato for de difícil elucidação, e o indiciado estiver solto, a autoridade poderá requerer ao juiz a devolução dos autos, para ulteriores diligências, que serão realizadas no prazo marcado pelo juiz.
O art. 10 é interessante porque refere-se a prazo de conclusão para a elaboração e envio do relatório à autoridade judicial. Esse prazo não está representado no diagrama.
A dificuldade encontrada aqui é a omissão na lei sobre o que acontece quando a Autoridade Policial não cumpre o prazo.
De qualquer modo, o § 3o do art. 10 descreve a situação em que, após ter remetido o relatório minucioso à Autoridade Policial, novos indícios aparecem ou ainda restam pontos a serem investigados. Nessas situações, a Autoridade Policial pode requerer a devolução dos autos para prosseguir no inquérito. Havendo a requisição ao juiz para devolução dos autos, este poderá deferir indicando novo prazo para a conclusão das diligências.
Neste caso, o retorno é representado por uma das setas que provêm da parte inferior do diagrama e chega no Gateway Inclusivo que se conectada à atividade realizar diligência.
As duas outras setas chegando a este mesmo Gateway representam as situações em que o próprio Juiz ou o Ministério Público requisitam novas diligências. O detalhamento destas requisições pelo Juiz ou pelo Ministério Público será feito por ocasião da discussão das atividades de suas respectivas raias.
A atividade Requisitar Informação de Órgão é iniciada apenas se ocorrem uma das situações previstas no art. 13-A (esta decisão está representada no diagrama por um Gateway Exclusivo):
Art. 13-A. Nos crimes previstos nos arts. 148, 149 e 149-A, no § 3odo art. 158 e no art.
159 do Decreto-Lei no 2.848, de 7 de dezembro de 1940 (Código Penal), e no art. 239 da Lei no 8.069, de 13 de julho de 1990 (Estatuto da Criança e do Adolescente), o membro do Ministério Público ou o delegado de polícia poderá requisitar, de quaisquer órgãos do poder público ou de empresas da iniciativa privada, dados e informações cadastrais da vítima ou de suspeitos. (Incluído pela Lei no13.344, de 2016) (Vigência)
Parágrafo único. A requisição, que será atendida no prazo de 24 (vinte e quatro) horas, conterá:
...
O art. 13-A dispõe que a requisição deverá ser atendida no prazo de 24 horas. Esta situação é modelada por um Gateway Baseado-em-Evento, o qual suspende a execução do processo até que um dos eventos ocorra. No caso, podemos ter a passagem do tempo,
representado por um Evento Intermediário de Captura de Tempo, ou o retorno das infor- mações, representado por um Evento Intermediário de Captura de Sinal. Uma dificuldade para modelar esta situação é que a lei nada diz sobre o que deve ser feito caso expire o prazo sem que as informações sejam fornecidas.
Finalmente, as atividades Arquivar Improcedência, Notificar Indeferimento, Analisar Recurso e Manter Indeferimento são realizadas pela Autoridade Policial quando esta inde- fere o requerimento do ofendido ou decide pela improcedência da comunicação de crime.
Estas situações serão comentadas novamente quando se discutir as atividades das raias relacionadas ao Ofendido e à Pessoa Pública.
A atividade Verificar Procedência representa o início do inquérito quando a notificação do crime é feita por terceiro (isto é, por alguém do povo, outro que não o ofendido).
4.1.2 Atividades do Juiz
Uma das formas de se iniciar o inquérito policial é por meio de uma requisição de ofício pelo Juiz, conforme o inciso II do artigo 5o já mostrado. Este início de inquérito policial aparece modelado como a atividade Requisitar Inquérito, visualizado na Figura 4.3.
Na ocasião em que o Juiz não iniciar o inquérito, ele deverá receber o relatório produ- zido pela Autoridade Policial. Uma vez verificado o requerimento de ulteriores diligências pela Autoridade Policial, o Juiz poderá deferir, marcando um novo prazo, ou não – como pode ser visto no § 3o do artigo 10, anteriormente mencionado. Esta decisão está presente no modelo da Figura 4.3 como as atividades Receber Relatório, Analisar Requerimento de ulteriores diligências e Marcar Novo Prazo. Todas elas encontram-se conectadas através de Gateways Exclusivos – estes últimos elementos representam as decisões que deverão ser tomadas por este ator. A atividade Marcar Novo Prazo seguirá para a atividade Realizar Diligências da raia da Autoridade Policial por meio de um Gateway Inclusivo.
Na ausência de requerimento de ulteriores diligências por parte da Autoridade Policial, ou no caso de seu indeferimento, o próprio Juiz poderá requisitar novas diligências, assim como previsto no inciso II do artigo 13:
Art. 13. Incumbirá ainda à autoridade policial:
I - fornecer às autoridades judiciárias as informações necessárias à instrução e julgamento dos processos;
II - realizar as diligências requisitadas pelo juiz ou pelo Ministério Público;
...
Este artigo está ilustrado na Figura 4.3 pela a atividade Requisitar Novas Diligências, a qual também seguirá até o mesmo Gateway Inclusivo localizado antes da atividade Realizar Diligências da raia da Autoridade Policial.
Figura 4.2: Inquérito Policial - Autoridade Policial
Figura 4.3: Inquérito Policial - Juiz
