Arquitetura de software

 

Padrões de projetos (design patterns)

 

  • Conceitos
    • descreve um problema de projeto genérico que ocorre repetidas vezes, e;
    • expressa sua relação com um contexto específico (requisitos e situações específicos), e;
    • com a ideia central (núcleo, aspectos chave) da solução;
    • refletem a experiência e conhecimento dos desenvolvedores que utilização com sucesso;
    • não são soluções específicas ou prontas, mas expressam grandes soluções sucintamente;
  • Subclassificação por escopo
    • Padrões com escopo de classe → relacionamentos de herança e em tempo de compilação;
    • Padrões com escopo de objeto → relacionamento entre os objetos e em tempo de execução, mais flexíveis;
  • Classificação por propósito

    • Padrões de criação → propõe formas de abstrair o processo de criação (instanciação) de objetos;
      • Factory Method, Abstract Factory, Builder, Prototype, Singleton;
    • Padrões estruturais → propõe formas de organizar e associar classes e objetos;
      • Adapter (de classe), Adapter (de objeto), Bridge, Composite, Decorator, Façade, Flyweight, Proxy;
    • Padrões comportamentais → propõe formas de interações e divisões de responsabilidade dos objetos;
      • Interpreter, Template Method, Chain of Responsability, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor;
  • Padrões de criação (construção, instanciação)

    • Factory Method
      • permite que uma superclasse delegue responsabilidades para subclasses auxiliares para que decidam quais objetos criar;
      • a classe FactoryMethod retorna a instância de uma das subclasses e a retorna com o tipo da superclasse (polimorfismo);
      • o cliente não conhece a subclasse do objeto concreto, apenas a superclasse;
      • métodos públicos das subclasses não são acessíveis ao cliente, pois o tipo retornado é da superclasse;
    • Abstract Factory
      • permite instanciar um conjunto de objetos relacionados (família, domínio, etc) que implementam interfaces definidas;
      • havendo um conjunto de interfaces em que cada uma é implementada para Windows e Linux (família, domínio, etc);
      • cada fábrica instancia as classes da respectiva família para cada interface;
      • o cliente recebe o objeto do tipo da interface (polimorfismo) e não conhece os objetos concretos, apenas a interface;
    • Builder
      • permite instanciar um objeto complexo (customizado, mudança do valor de atributos) a partir de uma sequência de passos comuns;
      • retira o código de customização de dentro da entidade (separa a construção do objeto de sua representação);
      • é criada uma classe abstrata (Builder Abstrato) para cada entidade customizável com métodos abstratos (padroniza a criação);
      • é criada um classe concreta (Builders Concretos) para cada customização de criação da entidade (instancia e modifica a entidade);
      • utiliza uma classe Director para centralizar a chamada dos Builders implementados e para ordenar os passos de criação de cada um;
      • o cliente instancia o Director e os Builders Concretos, passando ao Director o Builder Concreto que deseja utilizar;
    • Prototype
      • permite instanciar um novo objeto por meio de cópia (clone);
      • em Java, o processo de cópia é implementado dentro do objeto ao implementar a interface Clonable;
    • Singleton
      • permite que determinada classe tenha somente uma instância acessada por um ponto de acesso único;
      • utiliza-se uma instância estática e privada e um método estático para retornar essa instância;
      • um construtor privado impede uma nova instância da classe;
      • em Java, pode usar a anotação @Singleton;
  • Padrões estruturais
    • Adapter
      • permite compatibilizar interfaces ao adaptar uma implementação de interface para acessar métodos de outra interface;
      • intermedeia a chamada a métodos de uma interface que precisa ser acessada em uma implementação de interface já utilizada;
    • Bridge
      • permite separar a implementação da abstração de modo que possam variar independentemente;
      • utiliza interfaces como parâmetro do método, permitindo a alteração do comportamento por meio de implementações dessa interface;
    • Composite
      • permite que uma composição de objetos seja manipulada como um objeto individualizado por meio de uma superclasse comum;
      • normalmente utilizado na representação de árvores, em que objetos similares (nó e folha) são tratados por uma superclasse comum;
    • Decorator
      • intermedeia a chamada ao objeto para atribuir dinamicamente responsabilidades e comportamentos adicionais a um objeto;
      • adiciona chamadas a serem executadas antes e/ou depois do método original;
      • em Java, pode-se exemplificar com a anotação @Transactional, que inicia a transação antes do método e realiza o commit após o método;
    • Façade
      • permite substituir um conjunto de interfaces por uma interface simplificada e unificada;
      • intermedeia a chamada de métodos de diversas interfaces em uma interface e desacopla os clientes das diversas interfaces;
    • Flyweight
      • intermedeia o reuso de objetos; os objetos são desenhados para favorecer seu reuso/cache e são controlados por uma Factory;
      • atributos intrínsecos → são comuns e compartilhados entre os objetos de determinado tipo;
      • atributos extrínsecos → são distintos entre os objetos de determinado tipo e são recebidos como parâmetros de métodos;
    • Proxy
      • intermedeia a chamada ao objeto para provê controle ao acesso;
      • adiciona chamadas executadas antes e/ou depois do método original;
  • Padrões comportamentais
    • Interpreter
      • permite construir um interpretador para linguagens baseadas em árvores sintáticas abstratas;
    • Template Method
      • permite que subclasses implementem passos de um algoritmo;
      • utiliza um classe abstrata com a lógica de processamento e métodos abstratos com etapas do algoritmo a serem implementados;
    • Chain of Responsability
      • permite que uma cadeia de objetos receptores possam processar uma solicitação;
      • permite o desacoplamento (evita o acoplamento) entre o emissor e o receptor da solicitação;
      • havendo objetos receptores organizados em árvore, uma solicitação é analisada por cada objeto superior até ser processada;
    • Command
      • permite encapsular a requisição de um comando como objeto;
      • promove o fraco acoplamento ao utilizar uma interface comum para definir um comando;
      • utiliza uma classe Invoker para agrupar e intermedeiar a chamadas as requisições;
    • Iterator
      • permite acessar sequencialmente os elementos de uma coleção sem expor sua implementação (ordenação, hash, etc);
      • em Java as classe baseada em Collection implementam .iterator(), que retorna objeto que suporta .hasNext() e .next();
    • Mediator
      • permite que um conjunto de objetos interajam de maneira bem definida e utiliza um objeto para encapsular a comunicação;
      • permite o fraco acoplamento ao intermedeiar a comunicação entre o emissor e o receptor;
      • utiliza a interface Mediator para padronizar a comunicação entre objetos;
      • utiliza uma classe abstrata Colleague para padronizar o envio e recebimento de mensagens;
    • Memento
      • permite gerar cópias do objeto após mudanças nos atributos (instantâneo) sem violar o encapsulamento;
      • o objeto deve implementar método para gerar sua cópia e restaurar os valores (estado anterior) a partir de uma cópia;
      • utiliza uma classe Caretaker para armazenar cópia do objeto após mudanças nos atributos;
    • Observer
      • permite associar objetos observados a observadores para que esses sejam notificados sobre a mudança de estado;
      • o objeto observado possui uma lista de interface para que outras classes subscrevam;
      • o objeto observado é passado no construtor do observador, que se inclui na lista dentro do objeto observado;
      • ao mudar de estado, o objeto observado executa o método padrão da interface de todas as classes dessa lista;
    • State
      • permite que o objeto tenha comportamento diferente a partir de seu estado;
      • utiliza uma interface para declarar os métodos que possuem comportamento diferente em algum estado;
      • há uma implementação dessa interface para cada estado;
      • as chamadas desses métodos são encaminhadas para a implementação do estado atual;
    • Strategy
      • permite a criação de uma família de algoritmos encapsulados, selecionáveis e substituídos dinamicamente;
      • desacopla uma lógica de processamento tornando-a intercambiável e implementadas em forma de estratégia;
      • a família de algoritmos tem sua relação definida por uma interface (fixa os tipos de entrada e saída das estratégias);
      • a estratégia é representada por cada classe que implementa um algoritmo e a interface;
      • a classe de contexto recebe do cliente a instância da estratégia e os atributos definidos na interface;
    • Visitor
      • permite desacoplar uma estrutura de objetos (subclasses de uma superclasse) dos algoritmos aplicados a ela;
      • utilizado para selecionar os tipos de objetos de uma estrutura em que determinado algoritmo será executado;
      • os tipos de objetos devem implementar uma interface que especifica o método que recebe uma interface de visitor;
      • cada implementação da interface de visitor reflete uma lógica de processamento distinta;

 

Arquitetura cliente-servidor

 

  • Conceitos
    • Os servidores possuem interfaces do serviços providos;
    • Os servidores não tem a identidade ou número de clientes;
    • Os cliente iniciam as ações a partir da identidade do servidor;
    • A interação entre os processos cliente e servidor é cooperativa e o processamento equilibrado;
  • Análise
    • Determinar se os servidores são capazes de prover os serviços (capacidade);
    • Determinar se os clientes usam os serviços de forma apropriada;
    • Entender se um sistema consegue se recuperar em caso de falhas (continuidade);
    • Verificar se a informação é limitada (confidencialidade)
  • Desvantagens
    • O cliente faz um pedido de serviço e aguarda resposta (depende da capacidade do servidor)
    • O cliente precisa conhecer que tipo de serviço é oferecido;
    • O cliente precisa saber como contatar o serviço;
    • Os serviços podem atuar como clientes de outros serviços;

 

Arquitetura em camadas

 

  • …

 

Arquitetura de microserviços

 

  • …

 

Arquitetura de integração

 

Arquitetura orientada a serviços (SOA)

 

  • O que é um serviço?
    • É um mecanismo independente (de estado, de tecnologia ou de outros processos), sem estado (stateless) e interoperável por meio de interfaces para o acesso à recursos;
    • As interfaces devem ser bem definidas, bem como, descritas e exercitadas consistentemente de acordo com restrições e políticas especificadas pela descrição do serviço.
    • É oferecido por um provedor para consumidores, sem a necessidade da formalização de uma relação entre estes (agnóstico), podendo ser consumido para fins e escopos diversos daquele originalmente concebido;
    • Uma representação lógica do negócio que produz um resultado específico para cada solicitação feita;
    • Uma composição de diferentes elementos relacionados ao negócio;
      • entradas → informações enviadas pelo consumidor do serviço;
      • saídas → informações para o consumidor;
      • objetivos → regras de negócio;
      • transformações → aplicação das regras de negócio;
      • recursos → elementos utilizados pelo serviço durante a execução;
      • sensores → elementos do sistema para monitorar, detectar mudanças;
  • Arquitetura orientada a serviços (Service-oriented architecture)
    • É um paradigma (um conceito) para organização e utilização de recursos (competências) distribuídos que estão sob controle de diferentes domínios proprietários (OASIS);
    • É um modelo de arquitetura corporativa de software, eficiente, ágil e produtiva para interligar vários serviços (interoperabilidade de sistemas) por meio de componentes e interfaces fracamente acoplados;
    • É baseado nos princípios da computação distribuída e no paradigma de requisição (request)→resposta (reply) para o estabelecer a comunicação cliente-provedor, e preserva o padrão de conexão;
    • Informações, aplicações e recursos por ser vistos como serviços, e podem ser combinados para atender a novos e flexíveis processos de negócio;
    • Fornece flexibilidade para representação lógica de um processo de negócio e em sua infraestrutura;
    • Fim do conceito tradicional de aplicações monolíticas em virtude da composição de serviços;
    • Fim da necessidade de integração entre aplicações em virtude da interoperabilidade intrínseca;
  • Abordagens → representam coisas e ações do mundo real para construção de aplicações;
    • Orientação a objetos
      • foco no empacotamento de dados e operações integrados ao objeto, bem como suas implementações;
    • Orientação a serviços 
      • foco na tarefa ou função do processo de negócio;
      • restringe-se ao meio de acesso as operações e seus parâmetros, e não refere-se a sua implementação;
      • expõe a semântica de forma mais clara;
      • abstração mais adequada às atividades humanas por meio de delegação;
  • Benefícios
    • agilidade e eficiência frente as necessidades de mudanças;
    • processo de desenvolvimento eficiente;
    • reuso da infraestrutura tecnológica e do negócio;
    • redução de custos;
    • redução da dependência tecnológica;
    • mitigação de riscos do processo de desenvolvimento em virtude da reutilização de serviços;
    • integração e sobrevida à sistemas legados;
  • Desafios
    • maior complexidade de design;
    • necessidade de padrões de design;
    • requer governança apropriada;
  • Classificação
    • Categorias de serviços (perspectiva técnica)
      • Serviço básico ou autônomo →integração com backends (sem estado) para acesso a dados ou regras do negócio;
      • Serviço composto ou intermediários → integração com vários backends (sem estado);
      • Serviço de processo → integração com vários backends (com estado) para acesso a regras de negócio;
    • Modelos de serviços primários (perspectiva do negócio)
      • Serviço utilitário (funcional, de infraestrutura) → está associada a tecnologia ou plataforma específica (registro de logs, tratamento de exceções), e não diretamente ao negócio (há reuso);
      • Serviço de entidade → representa as entidades do negócio (há reuso);
      • Serviço-tarefa → contexto funcional é definido por processo específico (pouco reutilizável);
  • Princípios básicos
    • Fraco acoplamento → utilização de forma independente o serviço;
    • Contrato de serviço → descreve como o serviço vai funcionar;
    • Autonomia → o serviço tem controle sobre a lógica encapsulada;
    • Abstração → observação a itens implícitos ao contrato;
    • Reusabilidade → divisão em pequenos serviços com intenção de reutilizar em composição diferentes;
    • Composição → vários serviços pequenos podem formar um serviço complexo/composto;
    • Descoberta → projetados para serem descobertos, com descrição apropriada, entre elas, as pessoas de contato, fornecedores, restrições de segurança, nível de serviço acordo;
    • Heterogeneidade → implementação independente de linguagem ou plataforma;
    • Stateless → minimizam a retenção da informação tornando-o mais reutilizáveis;
  • Definições
    • Orquestração → processo de sequenciar serviços, prover lógica adicional e não incluir uma representação de dados;
    • Stateless → não depende de condição pré-existente;
    • Provedor → responde a requisição enviada pelo consumir;
    • Consumidor → solicita o resultado do serviço fornecido pelo provedor;
    • Descoberta → capacidade de identificar os serviços a partir de um diretório que cataloga o serviços de um domínio;
    • Binding → relação dinâmica, conexão, entre provedor e consumidor estabelecida em tempo de execução;
  • Conceitos
    • Dinâmica do serviço → conceitos que descrevem o paradigma SOA e permitem o entendimento da interação com serviços;
      • Visibilidade → consequência adequada descrição do serviço, e representa a capacidade de visualização recíproca (comunicação) entre provedor/consumidor;
      • Interação → trata-se da troca de mensagens (informações) para invocação de ação e execução de operações no provedor; cada interação possui contexto próprio de execução;
      • Efeito no mundo real → resultado provido pela interação, como a resposta da execução ou a mudança em estado compartilhado (informação de entidade que o consumidor e provedor possuem em comum);
    • Intrínsecos ao serviço → conceitos que descrevem o serviço;
      • Descrição do serviço → informações essenciais para a interação (utilização do serviço) e à visibilidade, como as funcionalidades, interfaces, formas de acesso, etc;
      • Contrato e políticas → restrições ou condições impostas ao serviço, como o nível de qualidade, acordo de nível de serviço, regras de segurança;
      • Contexto de execução → instância própria de execução a cada interação (troca de mensagens, instâncias das entidades de processo, aplicação dos contratos e políticas);
  • Componentes (elementos chave)

    • Aplicação front-end
      • elementos ativos, iniciam e controlam o processo de negócio;
    • Serviço
      • encapsula funcionalidade, baixo acoplamento, independência de serviços, definição do contrato com restrições de acesso e uso do serviço;
      • disponibiliza interface das operações disponíveis, regras de negócio, os dados, os subprogramas, configurações e banco de dados contidos na implementação;
      • elementos → contrato, interface, implementação, lógica de negócio e dados;
    • Repositório de serviços
      • facilita a descoberta de serviços, com a descrição adequada de cada serviço (localização física, pessoas de contato, fornecedores, restrições de segurança, nível de serviço acordo) – informações que podem variar em cada organização;
      • não é obrigatório para o funcionamento da arquitetura, mas sempre contribui para eficiência e benefícios a longo prazo;
      • geralmente está associado a um escopo, que agrega um conjunto de serviços;
    • Barramento de serviços
      • infraestrutura necessária para a comunicação entre duas aplicações (front end → barramento → serviço);
      • conectividade → canal de comunicação que interconecta todos os elementos da arquitetura SOA;
      • facilita o compartilhamento de serviços entre tecnologia heterogêneas;
      • fornece serviços técnicos integrados → auditoria, segurança, transformação de mensagens, transações.
  • Modelos de arquitetura

    • Operacional triangular → baseado em webservices de 1º geração;
      • Provedor (prestador do serviço) → fornecer a infraestrutura necessária para o serviço ser acessado;
        • provedor ⇒ publica e descreve o serviço (WSDL) ⇒ registro;
      • Registro (broker ou repositório)→ meios de publicação e busca dos serviços (UDDI/ebXML define o formato do repositório), gerenciar os repositórios com serviços e fornecedores de serviços;
        • consumidor ⇔ descobre e obtém WSDL ⇔ registro;
      • Consumidor (solicitante do serviço) → pessoa, organização, máquina, componente de software; SOAP define o formato das mensagens;
        • consumidor ⇔ interação ⇔ provedor;
    • Modelo SOA primitivo → não possui o registro de serviços como componente;
      • Provedor (prestador do serviço);
      • Cliente (solicitante do serviço);
        • consumidor ⇔ interação ⇔ provedor;
  • Camadas de abstração
    • Camada de objetos → objetos, atributos, classes, relacionamentos;
    • Camada de componentes → blocos de construção de serviços;
    • Camada de serviços → mapeamento dos serviços por funcionalidade básicas e de negócios;
    • Camada de processos → modelagem e implementação dos processos como serviços;
    • Camada corporativa → descreve as operações empresarias de determinada empresa;
  • Modelo de maturidade
    • ↓ Nível 1 → Desenvolvimento tradicional
    • ↓ Nível 2 → Desenvolvimento orientado a serviços (soluções simples)
    • ↓ Nível 3 → Desenvolvimento orientado a serviços (soluções compostas)
    • ↓ Nível 4 → Automação de processos de negócio
  • Ciclo de vida
    • Estratégia (fase 1) → diretrizes para o uso da arquitetura, levantar todas as atividades para definição do escopo, definição das medidas estratégicas para adoção da arquitetura;
    • Modelagem (fase 2) → conjunto de tarefas que descreve todos os aspectos dos processos negócio, principais pontos de decisão;
    • Implementação (fase 3) → desenvolvimento do serviço a partir de todas as decisões das fases de estratégia e modelagem;
    • Monitoramento (fase 4) → bussines activity monitoring, análise em tempo real para disponibilização de informações gerenciais;

 

Webservices

 

  • …

 

REST

 

  • …

 

Arquitetura orientada a domínio (domain-driven design)

 

  • Benefícios
    • Alinhamento com o negócio → interação entre desenvolvedores e especialistas do negócio;
    • Favorece a reutilização → os blocos de construção contribuem para reutilização de conceito de domínio ou código;
    • Mínimo de acoplamento → interação entre as partes do sistema com pouca dependência entre módulos ou classes de objetos;
    • Independência da Tecnologia → foco nas regras de negócio (o problema que se propõe a resolver) e sua tradução em códigos e no modelo de domínio;
  • Conceitos
    • Projeto orientado a domínio → desenvolvimento de sistema dirigido pelas regras de negócio do domínio;
    • Linguagem Ubíqua → linguagem comum, sem ambiguidade, compreendidos por todos, utilizada com o cliente e refletida no código;
    • Projeto dirigido pelo modelo (MDD) → conceito para representação exata do seu domínio;
    • Blocos de construção do domínio → usados para elaborar um modelo que reflete o domínio;
    • Contexto delimitado → divisão das partes do sistema para priorizar o foco no negócio;
    • Destilação do domínio → processo para definição do núcleo do domínio (refatoração, divisão em módulos, etc);
    • Núcleo do Domínio → os conceitos centrais do negócio, resultado da destilação do domínio;
    • Sentença da Visão do Domínio → documento que apresenta a visão resumida do núcleo do domínio em 1 página;
    • Núcleo destacado → documento que detalha os elementos do núcleo e suas interações em até 7 páginas;
  • Projeto Dirigido pelo Modelo (MDD)
    • Conceito de modelo
      • é abstrato e deve ser uma representação exata do seu domínio;
      • deve possuir tudo e somente o que está no negócio;
      • deve ser criado em conjunto, por especialistas de negócio, desenvolvedores e arquitetos;
      • guiará a criação do código e o código ajuda a aperfeiçoar o modelo;
      • deve ser refatorado e aperfeiçoado em conjunto com a maior compreensão de conceitos domínio;
    • As camadas do projeto → isolam o modelo de domínio das demais partes do sistema;
      • Interface de Usuário → informações do sistema e interpretação de comandos do usuário;
      • Aplicação → interliga a Interface de Usuário às camadas inferiores (não possui lógica de negócio);
      • Domínio → representa os conceitos, regras e lógicas de negócio;
      • Infraestrutura → fornece recursos técnicos às camadas superiores. Componentes de persistência de dados, conexão com bancos de dados, envio de mensagens, gravação e leitura de discos, etc.
  • Blocos de construção do domínio
    • Entidades → classes de objetos que representam identidade. Normalmente são elementos do domínio que possuem ciclo de vida (um Produto, é cadastrado, faz parte do estoque, é descontinuado, é excluído, etc);
    • Objetos de valores → classe que carregam somente valores, e não possuem distinção de identidade. As instâncias são imutáveis, uma vez criados, seus atributos internos não poderão ser modificados;
    • Agregados → classe que encapsula entidades ou objetos de valores e mantém a integridade do modelo;
    • Fábricas → classes responsáveis pela criação de agregados ou objetos de valores.
    • Serviços → classes que contém lógica de negócio, mas não pertencem a nenhuma entidade ou objetos de valores e não possuem estado;
    • Repositórios → classes que administram o ciclo de vida dos outros objetos e centralizam operações de criação, alteração e remoção de objetos;
    • Módulos → agrupam classes por um conceito do domínio (do negócio);
  • Aperfeiçoamento contínuo do modelo → identifica conceitos implícitos e os torna explícitos;
    • Interface de Intenção Revelada → os nomes de métodos e classes devem expressar exatamente “o que” fazem e não “como” fazem ou usar nomes genéricos;
    • Funções sem Efeitos-Colaterais → os métodos que alteram o estado dos objetos devem ser agrupados em Comandos; devendo o código maximizar o uso de métodos que não alterem estados;
    • Asserções → os Comandos (alteram estados) devem possuir testes de unidade que executem automaticamente, ou deve possuir asserções de validação após a chamada dos comandos;
  • Contexto delimitado → padrões de divisão das partes do sistema entre equipes para priorizar o foco no negócio;
    • Mapa de Contextos → descreve os vários componentes do software, a integração com as equipes, e um mapa de tradução entre contextos para facilitar a comunicação. Define termos comuns entre distintos contextos que devem ser usados entre equipes;
    • Produtor-Consumidor → produtor é a equipe que fornece o software, que assumirá compromissos de entregas para o consumidor. Esse compromisso de entrega embasará decisões do consumidor. Ambos os times podem elaborar testes automatizados que devem ser executados pelo Produtor a cada alteração na interface entre eles.
    • Conformista → não há solicitação de funcionalidades entre as equipes. Deve-se adequar o sistema ao que já é oferecido pelo outro sistema.
    • Núcleo Compartilhado → distintas equipes alteram código comum; essa parte do código deve ser bem definida e possuir testes automatizados executados por qualquer equipe que fizer alteração. Deve haver a comunicação de todas as alterações e os testes precisam fazer parte de um processo de Integração Contínua. Alterações do núcleo do código requerem a aceitação de todas as equipes.
    • Camada Anti-corrupção → utilização de uma camada para comunicação, que traduz e adapta as chamadas usando uma fachada interna,  entre um sistema legado, que utiliza outro padrão em desuso ou sem padrão, e um novo sistema, desenvolvido em padrões atuais;
    • Caminhos Separados → não há integração entre equipes ou dependência entre sistemas, decorrente de alto custo e/ou reduzidos benefícios;
    • Serviço Aberto de Funcionalidades e Linguagem Publicada → serviços que possuem API pública para interação com novos sistemas, cuja linguagem é a documentação desta API que poderá ser usada por distintos clientes. Utilizada para evitar customização, para determinado cliente, em sistemas utilizados por diversos clientes;

 

Arquitetura evolucionária (Emergent design)

 

  • Conceitos
    • entrega de pequenas parte de software com valor para o negócio;
    • entrega de funcionalidades e posterior identificação de padrões e refatoração;
    • ao fim de um ciclo ágil, tem-se o menor conjunto de padrões necessários;
    • resulta em um design simples e menos código, e consequentemente, menos defeitos e mais fácil de entender e manter;
    • depende fortemente de refatoração e de testes de unidade;

 

Gerenciamento Eletrônico de Documentos (GED)

 

  • Conceitos
    • Arcabouço de gestão, organização e operação de documentos (base de informação e conhecimento empresarial) em meio digital (imagens eletrônicas);
    • Torna seguro (evita extravios e falsificações), controlado, bem como agiliza a localização e o acesso a documentos da organização;
    • Automatiza a tramitação (distribuição e roteamento) de documentos por meio de fluxos de trabalho (workflow e processamento de transações);
    • Gerenciamento centralizado de mídias (digitalizados ou criadas em meio digital), como papel, microfilme, imagem, som, vídeo, manuscritos etc;
    • Permite a integração com sistemas corporativos e contribui para a continuidade do negócio com a replicação e salvaguarda efetiva dos documentos;
    • Provê recursos de assinatura digital, criptografia, controle de publicação (aprovação, revisão etc) e versão (data e autor), categorização e colaboração;
    • Utilizado em bibliotecas digitais, processo eletrônico, preservação de acervo histórico, diário oficial, prontuários de hospitais, seguradoras, etc.
  • Definições
    • Metadados → informações sobre os documentos (autor, assunto, data etc.) para pesquisa, roteamento e controle de acesso;
    • Indexação → conjunto de referências a um determinado documento para agilizar a pesquisa (identificador único, palavras do texto ou metadados);
  • Tecnologias
    • Document Imaging (DI) → captação de imagem do documento físico por meio de scanners, com controle de qualidade e indexação;
    • Capture → transforma documentos e formulários (físicos ou não) relacionados a regras de negócio em artefatos gerenciados (confiável e recuperável);
    • Document Management (DM) → gerenciamento de documentos (criação, revisão, descarte) e controle de versão (autoria, data, controle de acesso);
    • Workflow → gerenciamento de processos e fluxo de trabalho, bem como tarefas, prazos definidos, pessoas designadas, trâmites e documentos;
    • Enterprise Report Management (ERM/COLD) → gerenciamento de relatório para a captura, indexação, armazenamento e recuperação;
    • Records and Information Management (RIM) → gerenciamento do ciclo de vida do documento com categorização e controle de temporalidade;
    • Forms Processing (FP) → reconhece dados de formulários para armazenamento em banco de dados por meio de ICR, OCR e OMR;
    • Optical Mark Recognition (OMR) → reconhece campos de formulários, como checkbox, radio, V ou F;
    • Optical Character Recognition (OCR) → reconhece caracteres para tornar um documento digitalizado editável e pesquisável;
    • Handprint Character Recognition (HCR) → reconhece escrita manuscrita;
    • Intelligent Character Recognition (ICR) → provê funcionalidades semânticas para reconhecimento de caracteres;
  • Enterprise Content Managemeant (ECM) – Gestão de Conteúdo
    • Arcabouço de estratégias, métodos e ferramentas para capturar, armazenar, gerir, preservar e disponibilizar conteúdo corporativo (web);
    • Gestão de documentos e informações corporativas não estruturadas (não controladas por software e banco de dados próprio);
    • Provê recursos web avançados para o processo de criação e publicação de documentos, bem como separação do formato de exibição;
  • Workflow (fluxo de trabalho)

    • permite automatizar os processos de negócio, políticas e procedimentos, de forma total ou parcial por meio de um fluxo de trabalho;
    • permite a análise proativa e compreensão de tarefas para definição do fluxo de trabalho coordenado por meio de um conjunto de regras;
    • as regras definem restrições, entradas, notificações, processamento e controles que garantam a obtenção dos resultados do processo;
    • envolvem necessariamente várias pessoas, atividades e sua ordem de execução, entradas e saídas;
    • as pessoas envolvidas ao fluxo de trabalho devem colaborar para o alcance de um objetivo comum (e não objetivos distintos);
    • o WPDL e XPDL são linguagens para troca de informações entre sistemas de workflows;
    • três ‘R’s do Workflow → roles (papéis), rules (regras) e routes (rotas);
    • Gatilho → uma ação (de evento, de atividade ou de participante) que determina o início de uma atividade;
    • Estrutura do workflow
      • Processos, atividades e eventos → passos lógicos para alcance de determinado objetivo;
      • Ocorrências, instâncias ou casos → execução do processo e processamento de uma entrada;
      • Pastas → organização de documentos;
      • Papéis → conjunto fixos de características, de responsabilidade e resultados de um participante para a execução de tarefas;
      • Documentos → artefato de entrada (consumida) e saída (produzida) das atividades do fluxo de trabalho;
    • Classificação das atividades
      • Não-estruturada → atividades que não são possíveis de serem controladas pelo sistemas (não padronizadas, etc);
      • Internas → atividades definidas no fluxo de trabalho, supervisionadas e monitoradas;
      • Externas → atividades executadas fora do sistema, não sendo monitoradas;
      • Batch → atividade que depende da execução em conjunto;
    • Arquitetura do workflow → definida a partir do nível de automatização, da dependência de ações humanas e da complexidade dos processos;
      • Ad Hoc → modelos de processos simples para atividades cujo fluxo não é previsível e dependente de coordenação humana;
      • Administrativo → atividades simples e fracamente estruturada, repetitiva e previsível; parcialmente automatizável;
      • Produção → atividades estruturadas, processos complexos, repetitivos e previsíveis, com integração entre sistemas e pouca intervenção humana;
    • Categorias de componentes de workflow (WfMS)
      • Roteamento → guia o fluxo (caminhos) de informações ou documentos e transfere a informação para a próxima atividade; função passiva a circunstâncias excepcionais;
      • Distribuição → identifica circunstâncias excepcionais e notifica pessoas designadas; controla o balanceamento entre funções com pouco trabalho e sobrecarregadas;
      • Coordenação → coordenada atividades concorrentes a fim de garantir a integridade do processo e  evitar conflitos de recursos ou de prioridades;
      • Trabalhador (agente) → executa automaticamente ações que não necessitam de decisão;
      • Assistente (expert) → estende as funções anteriores com a utilização de inteligência artificial e propõe ajustes para a melhoria dos processos;

 

Portais Corporativos

 

  • Evolução (↓) e categorias de componentes
    • Aplicação web → centraliza, integra, consolida e distribui informações estruturadas e não-estruturadas, documentos (relatórios, planilhas, portarias) e sistemas institucionais, bem como provê um ponto referencial e único de acesso a informações, sistemas e serviços corporativos;
    • Taxonomia → uso de metadados de conteúdo, bem como organizar, classificar, indexar, estruturar, otimizar para pesquisas, com ferramentas de busca por relevância do conteúdo e com a capacidade de gestão de conteúdo (com fluxo de revisão, separada da apresentação);
    • Apresentação → personalização do leiaute para o dispositivo, bem como do conteúdo para o público alvo, interno ou externo, como colaboradores, fornecedores, clientes, investidores etc;
    • Interatividade → permite a colaboração (groupware), a comunicação (síncrona ou assíncrona) e a interatividade (agendas, fóruns, gerência de projetos, chats, videoconferência etc);
    • Especialização → especialização para apoio a processos de negócio, com alinhamento organizacional, bem como para gestão eletrônica de documentos, workflow, business intelligence e gestão do conhecimento;
  • Características – avaliações para seleção de plataforma;
    • Portabilidade → acessível por diferentes dispositivos;
    • Escalabilidade e desempenho → capacidade de suportar a demanda, inclusive com serviços distribuídos;
    • Usabilidade → facilidade de uso e de administração;
    • Navegabilidade → permitir a organização do conteúdo para facilitar sua localização;
    • Interatividade → roteamento inteligente a partir da definição de um fluxo de informações para direcionar relatórios e documentos a usuários;
    • Integrabilidade → interagir com sistemas, interfaces externas e fornecer interfaces programáveis (APIs, webservices e SOA);
    • Segurança → implementar controle de acesso flexível, autenticação centralizada (SSO), criptografia e assinatura digital;
    • Manutenabilidade e monitoramento → facilidade para manutenções e monitoramento, e necessidade de conhecimento técnico;
    • Futuro do fornecedor e evolução da plataforma → continuidade do desenvolvimento e do suporte, e maturidade e perpetuidade do fornecedor;
  • Modelos de negócio
    • Business to Business (B2B) → integra as transações entre empresas;
    • Business to Consumer (B2C) → permite transações entre consumidores e empresas (comércio eletrônico);
    • Consumer to Consumer (C2C) → permite transações entre consumidores;
    • Business to Employee (B2E) → integra a comunicação entre colaboradores e a empresa (sistemas corporativos);
    • Business to Government (B2G) → integra as transações entre o governo e as empresas (pregão eletrônico);
  • Classificação
    • Abrangência
      • Portal horizontal → abrange diversos conteúdos, comumente aberto ao público; (decorar: praça é horizontal e pública)
      • Portal vertical → aborda conteúdo específico, pode ser restrito a assinantes; (decorar: edifício é vertical e restrito)
    • Contexto
      • Portal público → fluxo de comunicação unidirecional e busca atrair o público amplo;
      • Portal corporativo → integra informações relacionados ao negócio e de interesse do público da instituição, interno e externo;
    • Processamento de decisão
      • Portal de informação → foco em organizar a informação corporativa;
      • Portal de negócios → foco em disponibilizar informações para subsidiar a tomada de decisão relativa aos processos de negócio;
      • Portal de suporte à decisão → integração de sistemas analíticos (DW/BI) para a análise de negócio a partir da cadeia produtiva de informações de negócio;
    • Processamento colaborativo (cooperativo)
      • Portal de colaboração → apoio a trabalho em equipe (groupware), a colaboração, ao compartilhamento de informação e ao fluxo de trabalho (workflow);
      • Portal de especialistas → apoio a troca de experiências entre especialistas em determinada área do conhecimento, de caráter profissional ou educativo;
    • Suporte a decisão e processamento colaborativo
      • Portal do conhecimento → agrega funções do portal de apoio à decisão e processamento colaborativo;
      • Portal de informações empresarias (EIP) → agrega funções do portal corporativo, cooperativo e suporte à decisão; integra dados estruturados e não-estruturados;
  • Arquitetura da informação
    • não é infraestrutura de tecnologia, não é modelagem da informação, não é arquitetura de sistemas;
    • organiza, categoriza, define o fluxo essencial e estrutura logicamente a informação a partir dos objetivos de negócio e do domínio de interesse;
    • reduz a complexidade de um conjunto de informações, ainda que em grandes volumes;
    • controla a quantidade e qualidade (importância) de informações expostas ao usuário;
    • aumenta a manutenabilidade da informação;
    • conteúdo orientado ao público alvo;
    • Princípios
      • Conteúdo → documentos, formatos, objetos, metadados, estrutura;
      • Contexto → objetivos da organização, política, cultura, tecnologia e recursos humanos;
      • Usuários → audiências, tarefas, necessidades, experiências, busca e padrões de vocabulário;
    • Taxonomia → organização e classificação da informação por meio de regras de alto nível atualizadas periodicamente;
    • Categorização → organização e classificação da informação por meio de categorias;
      • Categorização automática (smart tagging) → categorização dinâmica das informações a partir de regras;
      • Categorização múltipla → as informações podem estar associadas a várias categorias;
      • Metadados → autor, nome, data, tamanho, palavras-chave, etc;
  • RSS – Really Simple Syndication
    • Conceito → permite a distribuição de conteúdo e acompanhamento de atualizações pelos usuários por meio do formato XML;
    • Agregador (Feed reader) → programa para o cadastro e monitoramento de atualizações dos diversos Feeds RSS;
    • Feeds RSS → arquivo XML gerado por fornecedores de conteúdo, com a informação ou resumo com links para a versão completa;
      • <?xml version=”1.0″ encoding=”UTF-8″ ?>
      • <rss version=”2.0″>
        • <channel> <!– tags: <copyright>, <docs>, <generator>, <language>, <lastBuildDate>, <pubDate>, <rating>, <ttl>, <webMaster> –>
          • <title>Compreender a tecnologia…</title>
          • <link>https://reinaldoc.wordpress.com </link>
          • <description>Abordagem simplificada para entender a tecnologia</description>
          • <category>Blog/TI/Concursos</category>                       <!– categorias separadas por barra –>
          • <cloud domain=”example.org” port=”80″ path=”/RPC” registerProcedure=”NotifyMe” protocol=”xml-rpc” />
          • <managingEditor>editor@example.org</managingEditor>
          • <image>
            • <title>Channel logo</title>
            • <link>http://example.org </link>                                    <!– hyperlink da imagem –>
            • <url>http://example.org/logo.png </url>
            • <description>Tecnologia e concursos</description>
            • <height>50</height>                                                       <!– altura padrão=31, máxima=400 –>
            • <width>120</width>                                                        <!– largura padrão=88, máxima=144 –>
          • </image>
          • <skipDays>
            • <day>Saturday</day>
            • <day>Sunday</day>
          • </skipDays>
          • <skipHours>
            • <hour>4</hour>
            • <hour>5</hour>
          • </skipHours>
          • <textInput>
            • <title>Site search</title>
            • <link>http://example.org/search? </link>
            • <description>Search on main site…</description>
            • <name>Input name</name>
          • </textInput>
          • <item> <!– tags: <category>, <comments>, <guid>, <pubDate>, <source> –>
            • <title>RSS</title>
            • <link>http://example.com/n1 </link>
            • <description>Compreender o RSS…</description>        <!– texto completo ou resumo da notícia –>
            • <comments>http://example/n1/cmmts </comments>        <!– hyperlink para comentários da notícia –>
            • <enclosure url=”path/media.mp3″ length=”180″ type=”audio/mpeg” />
            • <author>autor@example.org</author>
          • </item>
          • <item>
          • </item>
        • </channel>
      • </rss>
    • RSS XSD (XML Schema Definition) → salve o XSD: rss-2_0.xsd
      • Validar o RSS → xmllint –valid –noout –schema rss-2_0.xsd MyFeed.rss
  • Portlets Java (JSR-168/286 e JSR-301/329 para integração ao JSF)
    • Conceitos
      • Componentes visuais para a geração dinâmica de fragmentos de página web (não possuem URL própria);
      • Permite a integração do conteúdo de aplicativos (informativos, colaborativos e transacionais) ao portal corporativo;
      • Classe Java que implementa javax.portlet.Portlet (init, processAction, render, destroy), empacotada (.war) e gerenciada por um container de Portlet;
      • Pode estender a classe abstrata javax.portlet.GenericPortlet que evolui as interfaces javax.portlet.Portlet e javax.portlet.EventPortlet;
        • implementa a chamada de método anotados com @ProcessAction, @RenderMode e @ProcessEvent;
        • processEvent() executa método a partir do nome do evento (request.getEvent().getQName().toString()) e anotação @ProcessEvent(name=”e1″);
        • processAction() executa método a partir do parâmetro da requisição ‘javax.portlet.action’ e anotação @ProcessAction(name=”a”);
        • render() → doDispatch() executa método a partir do parâmetro da requisição ‘javax.portlet.action’ e anotação @RenderMode(name=”a”);
          • ou, se este não for especificado na requisição, executa método padrão a partir do modo do portlet (PortletMode);
          • PortletMode.VIEW → doView(); → produz fragmento de página com a funcionalidade do Portlet;
          • PortletMode.EDIT → doEdit(); → produz fragmento de página para configuração do Portlet;
          • PortletMode.HELP → doHelp(); → produz fragmento de página para exibir informações de ajuda;
          • se WindowState.MINIMIZED nenhum fragmento é produzido;
    • Container de Portlet
      • O Apache Pluto não é container de Portlet independente, mas adiciona uma camada ao container de Servlet para prover a interface entre o Portal e os Portlets;
      • Diferente de um Servlet, o Portlet não podem enviar diretamente para o navegador redirecionamentos ou erros, nem encaminhar requisições ou gerar código de marcação arbitrário;
      • O container provê funcionalidades para acesso a informações de perfil do usuário, bem como a uma interface padrão para obter e armazenar configurações de usuário;
      • Gerencia o ciclo de vida do Portlet → provê ambiente para a inicialização, execução e destruição da instância;
        • init(PortletConfig config);
        • processAction(ActionRequest request, ActionResponse response);
          • executado a partir de cada requisição do usuário para processamento da requisição;
          • controla o estado da janela, persistência e prepara a renderização;
        • render(RenderRequest request, RenderResponse response);
          • produz o fragmento da página web;
          • executado em todos os Portlets da tela (ordem específica ou paralelamente);
        • destroy();
          • persistir dados eventualmente em memória (variáveis, sessão, etc);
          • liberar recursos;
    • Configuração
      • WEB-INF/portlet.xml
        • <?xml version=”1.0″ encoding=”UTF-8″?>
        • <portlet-app xmlns=”http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd ” version=”1.0″>
        • <portlet> <!– tags: <init-param>, <supported-locale>, <security-role-ref> –>
          • <portlet-name>PrefPortlet</portlet-name>
          • <portlet-class>examples.PrefPortlet</portlet-class>
          • <display-name>Pref Portlet</display-name>
          • <description>Portlet Preferences</description>
          • <expiration-cache>0</expiration-cache>
          • <supports>
            • <mime-type>text/html</mime-type>
            • <portlet-mode>EDIT</portlet-mode>
            • <portlet-mode>HELP</portlet-mode>
          • </supports>
          • <portlet-info>
            • <title>PrefPortlet</title>
            • <short-title>Pref</short-title>
            • <keywords>Hello, world, test</keywords>
          • </portlet-info>
          • <portlet-preferences> <!– tags: <preferences-validator> –>
            • <preference>
              • <name>name</name>
              • <value>World</value>
            • </preference>
          • </portlet-preferences>
        • </portlet>
        • </portlet-app>
      • WEB-INF/web.xml
        • <?xml version=”1.0″ encoding=”ISO-8859-1″?>
        • <!DOCTYPE web-app PUBLIC “-//Sun Microsystems, Inc.// DTD Web Application 2.3//EN” “http://java.sun.com/dtd/web-app_2_3.dtd “>
        • <web-app>
          • <display-name>Portlet Examples</display-name>
        • </web-app>
    • Web Services for Remote Porlets
      • protocolo para interação com Portlets remotos baseado em mensagens SOAP;
      • fase de inicialização;
        • descoberta do produtor;
        • estabelece-se relação entre consumir e produtor;
        • aprende-se todos os serviços do produtor;
      • fase de serviço;
        • usuário acessa o consumidor;
        • consumidor agrega dos Portlets envia ao usuário;
        • usuário enviar requisição para o consumidor;
        • consumidor encaminha requisição ao produtor;
        • produtor produz fragmento de página e indica o PortletState;
        • consumidor agrega o fragmento na página do portal e envia ao usuário;

 

Padrões Web do Governo Eletrônico (e-PWG)

 

  • …

 

Cartilha de Usabilidade do Governo Eletrônico

 

  • …

 

ISO 9241-11

 

  • …

 

 

Modelo de Acessibilidade do Governo Eletrônico (e-MAG)

 

  • …

 

Padrões de Interoperabilidade do Governo Eletrônico (e-PING)

 

  • …

 


Reinaldo Gil Lima de Carvalho