Objetos, Modelos e base de dados de lógica jurídica

Abstract: Essa é uma especificação de alto nível de ideias e recursos para evolução da plataforma Looplex. O escopo desse documento é (1) explicar o que são Objetos Gerenciados; e (2) explicar o que são Modelos de Dados e Modelos Lógicos de Dados para o mundo jurídico

O que são Objetos

Em engenharia jurídica, os Legal Objects são as coisas que você precisa pensar primeiro para poder criar conteúdo e aplicativos ou serviços jurídicos que irão rodar na Plataforma Looplex.

Quando um Legal Object serve de modelo ou para instanciar outros, ele é um Legal Data Model e quando ele é instanciado, ou seja, ele representa efetivamente algo em uma situação concreta, ele é um Legal Data Object.

Cada objeto tem suas propriedades e métodos. Ele pode ser transformado em uma “classe genérica” de objeto, sendo que classes ainda mais genéricas podem ser definidas para que os objetos possam compartilhar modelos e reutilizar as definições em seu código.

Um objeto é o que realmente funciona no computador. Todos os objetos individualmente possuem três características básicas: identidade, estado e comportamento.

1. Identidade significa que cada objeto tem seu próprio identificador e pode ser diferenciado de todos os outros objetos. O nome de cada objeto, ou identidade, é único e distinto de outros objetos.

2. Estado refere-se às propriedades de um objeto. Por exemplo, os valores das variáveis no objeto contêm dados que podem ser adicionados, alterados ou excluídos.

3. O comportamento refere-se a ações que o objeto pode tomar. Por exemplo, um objeto pode responder a outro objeto para executar funções de software.

Algumas das coisas em programação que podem ser definidas como objetos incluem o seguinte:

• variáveis, que possuem valores que podem ser alterados;

• estruturas de dados, que são formatos especializados utilizados para organizar e processar dados;

• funções, que são nomeados procedimentos que realizam uma tarefa definida;

• métodos, que são procedimentos programados, definidos como componentes de uma classe parental e são incluídos em qualquer instância dessa classe.

Objetos fazem coisas. Por exemplo, uma função ou método do objeto pode ser programado para modificar o conteúdo de uma estrutura de dados ou objeto variável de acordo com a ocorrência de eventos.

O Looplex Dataverse contém modelos de estruturas de dados (data structures) que são os Legal Data Models, as operações de lógica jurídica associadas ao conteúdo (Operations), e modelos de operações de acordo com eventos, que são os Legal Service Models¹.

Modelos de Objetos

Uma representação de objetos, eventos e suas associações do mundo real é chamada de modelo. O modelo ajuda o engenheiro jurídico a entender as complexidades de um domínio do mundo jurídico e mesmo do Direito como um todo.

Uma coleção de conceitos para descrever e manipular dados, relações entre dados e restrições aos dados é chamada de modelo de dados. Esses são os Legal Data Models.

Legal Data Models

Um modelo de objeto de dados permite definir a estrutura de “dados de negócios” (business data) ou um “objeto de negócios” (business object). Por exemplo, um objeto pode representar um “cliente”, uma “parte”, uma cláusula ou mesmo um “caso”, com, por exemplo, nome, endereço e/ou outras informações relevantes.

A partir de um modelo de objeto de dados, instâncias de objetos de dados ou mais simplesmente os ditos objetos de dados podem ser criados, atualizados, consultados em Documentos, Fluxos, Dashboards, Casos etc. na plataforma, e todos terão sua estrutura modelada e padronizada.

Os modelos de dados são conceitualmente bastante simples: eles definem uma estrutura (também chamada de esquema ou schema) de um objeto de negócio. Isso significa que tal modelo descreve os campos que compõem o objeto e o tipo de cada campo, agindo como uma espécie de “contêiner” para esses campos.

Legal Service Models e Ações

Não são os próprios Legal Data Models e seus respectivos Data Objects que definem como eles devem ser lidos, criados, atualizados, processados, excluídos ou consultados. Essas ações são chamadas de Operations (operações) nas diferentes engines utilizadas pela Looplex, e são elas que definem como os campos e os valores desses campos devem ser usados para implementar a lógica de construção daquele objeto.

Operations podem ser assim qualquer método ou função associada à criação de conteúdo executado na plataforma Looplex, ou seja, que operam conteúdo de objetos de dados dentro do próprio template, seja para executar uma entrevista dinâmica, determinar campos de impressão, calcular variáveis ocultas etc.

Operations também são usadas “fora” do contexto de geração de um Documento, por exemplo para executar processos de automação de ciclo de vida destes Documentos (Contract LifeCycle Management), de Casos (Project Lifecycle Management) e de BI (Legal Analytics), como envio de e-mail, sincronização de dados, extração de dados por RPA etc.

Operations também podem ser encapsuladas e abstraídas para outra camada lógica da plataforma, simplificando a criação e manipulação da lógica dos Templates. Chamamos essas funções de Actions.

Na implementação do motor de construção de documentos em Lawtex as Actions eram chamadas de Tubes.

Exemplos de Actions são os Operadores Lógicos e os Tubes do motor em Lawtex (DocAss), as operações do Looplex Code ou as angular expressions de conteúdo do Office Render (Looplex365), os service models do Flowable, as chamadas padronizadas para os nossos SQL endpoints, os nossos Data Pipes (que já executam rotinas pré-setadas de ETL de dados) entre outros.

As Actions, em todos os seus nomes e variações, criam um tipo de modelo lógico de dados (logical data models).

Quando padronizamos e encapsulamos um componente que contém diversas funções já abstraídas e resolvidas em outra camada ou contexto e que podem ser executada conforme uma sequência de passos pré-ordenados (execução de um ciclo de vida de dados associados a uma operação jurídica), chamamos essa agregação de Legal Service Models.

A criação de um Legal Service Model permite criar operações e Actions de forma livre que podem ser usadas em Templates de Documento, de BI, de Processos ou de Casos, ocultando e simplificando a profundidade lógica real para o engenheiro jurídico ou modelador.

Uma Action pode agregar várias funções, inclusive de diferentes service models, como “enviar para assinatura e arquivar” ou outros conceitos compostos. Comercialmente agrupamos todas as Actions e Legal Service Models como “ações inteligentes”.

Implementações suportadas

Um engenheiro jurídico pode acessar e manipular dados vindos de diversas fontes, por exemplo:

• Banco de dados: use esse tipo de Service Model quando ele for ser acessado pelo nosso Common Data Service, para instanciação de objetos de dados em Documentos e outros tipos de Template que estão armazenados em um dos nossos bancos de dados do Looplex Dataverse.

• API: use este tipo de Service Model quando os dados dos objetos que serão instanciados existem em um sistema externo à Looplex. Por exemplo para invocar operações padronizadas de análise extração de um documento externo desconhecido que será submetido ao nosso serviço de Data Extraction.

A potência e flexibilidade dos Legal Data Models e Service Models ficam evidenciados quando pensamos que podemos implementá-los para diferentes tipos de Templates, por exemplo uma operação de cálculo de prazo para criar um parágrafo em um Documento, um alerta em um Dashboard ou e-mail, geração de um andamento na linha de tempo de um Caso ou definição de data de término e tipo de uma tarefa (prazo judicial ou não judicial, fatal ou não etc.), ou ainda um fluxo CMM ou BPM automatizado em nossa camada de BPA.

Modelos “locais” e Common Data Model

Engenheiros jurídicos podem criar modelos de serviço e modelos de objetos de dados localmente para um determinado Projeto ou Programa de Projetos ou globalmente, para uso em qualquer cenário de conteúdo ou gestão na plataforma Looplex.

A criação de modelos locais pode ser muito útil em certos projetos, por exemplo para organizar o acesso comum de diferentes Templates a um mesmo jogo de dados criados em Documentos diversos (o antigo “Documento falando com Documento”), que ficam assim em uma Table SQL especial para consulta.

Mas esse tipo de implementação “local” não tem todo o poder de escalabilidade e fungibilidade de um model que poderia ser usado como um componente universal em qualquer projeto que precise daquele contexto.

Para isso temos o Common Data Model e, por conta disso, só chamamos de Legal Data Model uma entidade cujo modelo foi devidamente normalizado e especificado de acordo com o nosso Common Data Model.

Da mesma forma, a implementação de um service model que possa ser aplicado em qualquer cenário de uso com o mesmo contexto (por exemplo um cálculo de prazo judicial que pode operar um Legal Snippet de “tempestividade” em uma contestação, ou atribuir uma data fatal automaticamente para um prazo judicial no módulo de tarefas) torna-se um Legal Service Model.

O ambiente completo da plataforma Looplex permite assim o consumo de dados de diversas fontes, sejam eles normalizados no Common Data Model, estruturados em modelos “locais” ou projeções limitadas para um composto de templates, salvos de maneira não padronizada em um data lake, ou ainda acessados a partir de fontes externas. Esse consumo de dados passa todo pelo serviço de APIs da Looplex.