Injeção de dependência (dependency injection - ou DI) é uma técnica de programação na qual objetos ou funções recebem outros objetos e funções que eles necessitam, ao invés de construí-los internamente. Abaixo segue uma forma simples de injeção de dependência:

// Definindo as classes
class MinhaClasse {
	constructor(minhaDependencia: MinhaDependencia) {}
}

class MinhaDependencia {
}

// Construindo objetos
const meuObjeto = new MinhaClasse(new MinhaDependencia());

Imagine, no entanto, que meuObjeto dependa de vários outros objetos, e cada um desses objetos dependa de mais alguns e assim por diante... Com o passar do tempo a construção de um objeto simples como meuObjeto poderia se tornar muito verbosa e de difícil manutenção, vamos a um exemplo:

// Definindo classes

class MinhaClasse {
	constructor(minhaDependencia1: MinhaDependencia1, minhaDependencia2: MinhaDependencia2) {}
}

class MinhaDependencia1 {
	constructor(outraDependencia: OutraDependencia1) {}
}

class MinhaDependencia2 {
	constructor(outraDependencia: OutraDependencia2) {}
}

class OutraDependencia1 {
}

class OutraDependencia2 {
}

// Construindo objetos
const dependencia1 = new MinhaDependencia1(new OutraDependencia1());
const dependencia2 = new MinhaDependencia2(new OutraDependencia2());
const meuObjeto = new MinhaClasse(dependencia1, dependencia2);
// ...

Para esses tipos de situação um container de injeção de dependência (dependency injection container - ou DI container) pode ser útil principalmente para facilitar a leitura e, algumas vezes, ajudando a evitar duplicação de código.

Um container de injeção de dependência, de forma resumida, é uma classe - normalmente global - capaz de criar e configurar objetos. Sendo assim, ele deve ter pelo menos duas funcionalidades bem simples: registrar e injetar dependências.

Ao decorrer desse artigo iremos construir e utilizar um container de injeção de dependência simples utilizando alguns padrões de projeto. O código desenvolvido foi baseado em uma implementação realizada em uma das aulas do curso de Clean Code e Clean Architecture do Rodrigo Branas e desse artigo em seu blog.

Conhecendo o padrão Registry

Martin Fowler, em seu livro Patterns of Enterprise Application Architecture, descreve o padrão Registry como "um objeto [global] bem conhecido que outros objetos podem utilizar para encontrar serviços e objetos comuns" (tradução livre).

Diante das características de um container de injeção de dependência e levando em conta a função de um Registry, precisamos garantir que todos os objetos da aplicação acessem a mesma instância de Registry - e considerando que estamos trabalhando com uma aplicação single-threaded - outro padrão pode nos ajudar com essa tarefa. Estamos falando do...

Singleton

Conforme descrito no livro Padrões de Projeto (Gang of Four), o padrão singleton é um padrão de criação cujo objetivo é "garantir que uma classe tenha somente uma instância e fornecer um ponto global de acesso para a mesma".

Anatomia de um singleton

Em geral um singleton possui algumas características que permitem identificá-lo de uma maneira rápida e direta, são elas:

• Propriedade estática que armazena a instância da classe
• Construtor privado
• Método estático para recuperar a instância do objeto ou instanciá-lo caso não exista.

// Definindo singleton
class MeuSingleton {
	static instance: MeuSingleton;
    
    private constructor() {
    	// ...
    }
    
    static getInstance() {
    	if (!MeuSingleton.instance) {
			MeuSingleton.instance = new MeuSingleton();
		}
		return MeuSingleton.instance;
    }
}

// utilizando singleton
const singleton = MeuSingleton.getInstance();

Dessa forma, sempre que invocarmos o método getInstance() estaremos recebendo a mesma instância de MeuSingleton independente de onde o chamarmos (desde que esteja executando no mesmo processo).

Criando o Container

O container de injeção de dependência deve possuir, pelo menos duas funcionalidades: registrar dependências e injetar dependências.

Combinando o Registry com o Singleton, conseguimos garantir que todas as dependências registradas no container estarão sempre na mesma instância, independente de onde ele for chamado:

// Definindo registry (DI container)
class Registry {
	dependencies: {[name: string]: any}
	static instance: Registry;
    
    private constructor() {
    	this.dependencies = {};
    }
    
    register(name: string, dependency: any) {
    	this.dependencies[name] = dependency
    }
    
    inject(name: string) {
    	if(!this.dependencies[name]) throw new Error("Dependency not found");
    	return this.dependencies[name];
    }
    
    static getInstance() {
    	if (!Registry.instance) {
			Registry.instance = new MeuSingleton();
		}
		return Registry.instance;
    }
}

Com o que temos até aqui já é possível termos os benefícios de um container de injeção de dependência em nossa aplicação, podemos construir o container e passá-lo por injeção às nossas classes, por exemplo:

// main.ts
const registry = Registry.getInstance();
registry.register("minhaDependencia", new MinhaDependencia);
const meuObjeto = new MinhaClasse(registry);

// MinhaClasse.ts
class MinhaClasse() {

	private dependency: MinhaDependencia;

	constructor(registry: Registry) {
    	this.dependency = registry.inject("minhaDependencia");
    }
}

Essa forma de implementação já é suficiente para simplificar nosso problema inicial, porém ainda exige que todas as nossas classes recebam uma instância de registry para serem capazes de injetar a dependência correspondente para sua  correta execução.

Porém ainda podemos simplificar. Algumas linguagens, como o typescript, implementam, um recurso chamado decorator (ou annotations) que de maneira bem resumida e superficial, podemos definir como, atalhos (açúcar sintático - sugar syntax) de implementação do padrão de projeto de mesmo nome.

Decorator

Decorator é um padrão estrutural descrito no livro Padrões de Projeto (Gang of Four) cujo objetivo é "dinamicamente, agregar responsabilidades adicionais a um objeto".

Em essência o decorator define a mesma interface do componente que será decorado (Component) e matém uma referência ao mesmo. Quando invocado, ele repassa solicitações para objeto podendo executar operações adicionais antes e depois de repassar a solicitação.

Anatomia de um decorator

Vamos ver uma maneira de implementar o padrão decorator:

// definindo o componente que será decorado
interface Component {
	meuMetodo();
}

// Decorator Base
class Decorator implements Component{
	private _component: Component

	constructor(component: Component){
    	this._component = component;
    }	
    
    meuMetodo() {
    	this._component.meuMetodo();
    }
}

// Decorator específico
class MeuSuperDecorator extends Decorator {
	private _param: string;

	constructor(component: Component, param: string) {
    	super(component);
        this._param = param;
    }
    
    meuMetodo() {
    	console.log(this.param);
        super.meuMetodo();
    }
}

No typescript, de maneira nativa, utilizamos decorators na forma de "função que retorna outra função" e podemos decorar classes, métodos, propriedades, acessores e parâmetros.

Fazendo uma ponte entre a implementação de decorators do typescript com o que é definido pelo padrão Decorator podemos dizer que a função mais interna é o método do componente, enquanto a externa é a chamada do decorator.

// definindo o decorator
function meuDecorator(parametro: string) {
	return (target: any, propertyKey: string) => {
    	// faz alguma coisa
    }
}

// Utilizando decorator
class MinhaClasse {
	@meuDecorator("blabla")
	minhaProp: string
}

Existe, porém, um detalhe quando utilizamos os decorators do typescript no que diz respeito à sua inicialização: os decorators são executados assim que a classe é importada.

Esse comportamento nos traz alguns problemas pois podemos ter uma classe sendo importada antes do nosso register ser construido e, consequentemente, quando nossa classe for instanciada não termos dependência nenhuma injetada para utilizar. Para contornar esse problema podemos utilizar um outro padrão de projeto que é implementado de forma nativa pelo typescript. Estamos falando do Proxy.

Proxy

Outro padrão estrutural presente no livro Padrões de Projeto (Gang of Four) e seu objetivo é "Fornecer um substituto ou marcador da localização de outro objeto para controlar o acesso a esse objeto". A ideia por trás de controlar o acesso a um objeto é adiar sua inicialização até o momento que realmente precisamos utilizá-lo.

A implementação do padrão é semelhante à implementação do decorator, o que muda nesse caso é a intenção de cada um.

Finalizando implementação

Agora que já entendemos um pouco sobre os padrões envolvidos na construção do nosso container, vamos implementar o decorator que utilizaremos nas nossas propriedades:

// registry.ts

export function inject(name: string) {
	return (target: any, propertyKey: string) => {
    	target[propertyKey] = new Proxy({}, {
        	get(target: any, propertyKey: string, receiver: any) {
            	const dependency = Registry.getInstance().inject(name);
				return dependency[propertyKey];
            }
        })
    }
}

No código acima estamos exportando uma função inject que utilizaremos da seguinte forma: @inject("nomeDaDependencia") nas classes que terão a dependência injetada.

Essa função retorna uma outra função (que respeita a assinatura de decorators de propriedades) onde:

• target é o objeto e
• propertyKey é a propriedade que está sendo decorada.

Quando invocada, essa função irá sobrescrever a propriedade da classe com um proxy que, quando chamado retornará a instância da dependência que registramos e injetamos.

Considerando o seguinte cenário:

class MinhaClasse {
	@inject("minhaDependencia")
    dep: Dependencia
}

Quando a classe for importada, dep será um proxy que, quando chamada resolverá a dependência que foi previamente injetada.

Conclusão

A implementação final do container ficou da seguinte maneira:

// Registry.ts
export class Registry {
	dependencies: {[name: string]: any}
	static instance: Registry;
    
    private constructor() {
    	this.dependencies = {};
    }
    
    register(name: string, dependency: any) {
    	this.dependencies[name] = dependency
    }
    
    inject(name: string) {
    	if(!this.dependencies[name]) throw new Error("Dependency not found");
    	return this.dependencies[name];
    }
    
    static getInstance() {
    	if (!Registry.instance) {
			Registry.instance = new MeuSingleton();
		}
		return Registry.instance;
    }
}

export function inject(name: string) {
	return (target: any, propertyKey: string) => {
    	target[propertyKey] = new Proxy({}, {
        	get(target: any, propertyKey: string, receiver: any) {
            	const dependency = Registry.getInstance().inject(name);
				return dependency[propertyKey];
            }
        })
    }
}

Declaramos então as dependências que serão injetadas na classe desejada:

// MinhaClasse.ts
export class MinhaClasse {
	@inject("minhaDependencia")
    dependencia: Dependencia
    
    execute() {
		this.dependencia.fazAlgo();
        console.log("chamou minha classe");
    }
}

// Dependencia.ts
export class Dependencia {

	fazAlgo() {
    	console.log("chamou dependencia");
    }
}

E, no ponto de entrada (main.ts) da aplicação basta construir as dependências e registrar no container que elas estarão disponíveis:

// main.ts
const registry = Registry.getInstance();
registry.register("minhaDependencia", new Dependencia());
new MinhaClasse();

Apesar de precisar de mais código e aumentar ligeiramente a complexidade a implementação de um container de injeção de dependência também traz vantagens como:

1. A substituição das dependências fica mais simples, pois precisamos alterar um único ponto (e não precisamos procurar em diversos arquivos quais classes que utilizam aquela dependência);
2. Código fica mais fácil de ser lido e entendido, uma vez que não temos mais classes com vários parâmetros sendo passados no construtor.
3. Garantimos que sempre haverá uma única instância de cada dependência em todo o processo de execução da aplicação.

Mensageria ou messaging é uma forma de comunicação presente em sistemas distribuídos realizada através da troca de mensagens (eventos), sendo essas mensagens gerenciadas por um message broker.

Mas... o que é um message broker?

De forma resumida, message broker é um intermediador: um componente que responsável por intermediar a troca de mensagens entre produtores (producers) e consumidores (consumers).

Producers e consumers, resumidamente, são sistemas de software que, respectivamente, enviam e recebem mensagens para/do message broker

Fazendo uma analogia, um carteiro (message broker) é responsável por garantir que uma carta saia do remetente (producer) e chegue até o destinatário (consumer).

Componentes básicos do message broker

Existem diversos message brokers disponíveis no mercado, dentre eles, podemos citar como mais populares: RabbitMQ, Apache Kafka, Amazon SQS, Google Cloud Pub/Sub, dentre outros. No entanto, independente do fornecedor, normalmente encontraremos os seguintes elementos:

• Producer - sistema que irá enviar (produzir) uma mensagemm
• Consumer - sistema que irá consumir mensagens de uma fila
• Queue ou topic - fila (ou tópico) para a qual a mensagem será enviada e armazenada
• Exchange - Componente responsável por rotear as mensagens para suas respectivas filas e garantir uma distribuição uniforme entre os consumidores
• Message ou event - A mensagem que está sendo transmitida entre produtor e consumidor.

Vantagens e Desvantagens em utilizar mensageria

Vantagens

• A troca de mensagens entre produtor e consumidor pode ocorrer independente se o um ou outro estiver online, o message broker se encarregará de entregar a mensagem assim que o consumidor ficar ativo novamente.
• Message brokers são capazes de garantir a entrega da mensagem, tornando o sistema mais confiável.
• O processamento assíncrono ajuda a melhorar a performance da aplicação e experiência do usuário.
• Message brokers são capazes de reenviar mensagens não entregues além de manter um registro das falhas para análise futura.

Desvantagens

• A consistência entre os sistemas (produtor e consumidor) é eventual, ou seja, em determinado momento poderá haver inconsistência nos dados entre os sistemas.

Tá na hora do Código

Nota: Todos os exemplos a seguir utilizarão Rabbit MQ como message broker e typescript como linguagem de programação.

Nota2: Focaremos na implementação dos producers e consumers, portanto não entraremos em detalhes sobre a implementação das demais dependências nem a organização do código.

O que iremos fazer?

Para nosso exemplo iremos construir uma API que atuará como producer e consumer de mensagens. Iremos explorar todos os tipos de exchange disponíveis no RabbitMQ, sendo elas:

• direct: a mensagem é enviada diretamente para a fila conectada à exchange, cuja chave é exatamente igual à informada;
• fanout: a mensagem é enviada para todas as filas conectadas à exchange;
• topic: a mensagem é enviada para todas as filas conectadas à exchange, cuja chave respeita o padrão configurado.

Producer

Para produzir a mensagem iremos expor 3 endpoints para que possamos criar nossas mensagens, sendo eles:

1. POST /messages/direct?name=nome_da_fila
2. POST /messages/topic?name=pattern_da_fila
3. POST /messages/fanout

De modo a conseguirmos personalizar a fila para qual vamos enviar as mensagens no caso das 2 primeiras, receberemos o nome via query param.

O conteúdo da mensagem deverá ser enviado no corpo da requisição respeitando o seguinte contrato:

{
	"content": "conteúdo da mensagem",
    "date": "2023-01-01T10:00:00"
}

Consumer

Teremos 2 consumidores que irão receber a mensagem e salvar num arquivo texto, cada consumidor irá mostrar um log com a seguinte estrutura: consumer-1|data_envio|data_erecebimento|tipo|conteudo

Setup

Para uma melhor organização foi criada um adaptador para a biblioteca amqplib, essa classe tem como objetivo adapter a interface da amqplib para nossa interface Queue, que contém apenas os métodos necessários para enviar e consumir mensagens.

import { Queue } from "./Queue";
import amqp from "amqplib";

export class RabbitMQQueueAdapter implements Queue {

    connection: amqp.Connection | undefined;

    constructor(private exchange: string) {

    }

    async connect(): Promise<void> {
        this.connection = await amqp.connect("amqp://rabbitmq:rabbitmq@rabbit");
    }


    async close(): Promise<void> {
        if (!this.connection) {
            throw new Error("connection closed");
        }
        this.connection.close();
    }

    async publish(exchangeName: string, queue: string, payload: any): Promise<void> {
        if (!this.connection) throw new Error("connection closed");
        const channel = await this.connection.createChannel();
        await channel.checkExchange(this.exchange);
        channel.publish(exchangeName, queue, Buffer.from(JSON.stringify(payload)));
    }

    async sendToQueue(queue: string, payload: any): Promise<void> {
        if (!this.connection) throw new Error("connection closed");
        const channel = await this.connection.createChannel();
        await channel.assertQueue(queue, { durable: true });
        channel.sendToQueue(queue, Buffer.from(JSON.stringify(payload)));
    }

    async consume(queueName: string, callback: any): Promise<void> {
        if (!this.connection) throw new Error("connection closed");
        const channel = await this.connection.createChannel();
        await channel.assertQueue(queueName, { durable: true });
        await channel.consume(queueName, async function (msg: any) {
            await callback(JSON.parse(msg.content.toString()));
        }, {
            noAck: true
        });
    }
}

Destaco aqui os métodos publish e consume, iremos utilizar o primeiro para enviar mensagens à nossa exchange e o segundo para consumir mensagens existentes na fila selecionada.

O método sendToQueue é utilizado para ignorar o roteamento da exchange e enviar uma mensagem diretamente à fila desejada. Não utilizaremos ele nesse exemplo.

Producer

Em nosso exemplo, a classe responsável por montar a mensagem e chamar o método publish é a ProduceMessageUseCase:

import { Message } from "../domain/entity/Message";
import { Queue } from "../infra/queue/Queue";

export class ProduceMessageUseCase {

    types = {
        direct: "directExchange",
        topic: "topicExchange",
        fanout: "fanoutExchange"
    }

    constructor(private queue: Queue) {

    }

    async execute(input: ProduceMessageInputDto): Promise<void> {
        const message = new Message(input.origin, input.content, input.date);
        const exchangeName = this.types[input.origin] ?? this.types.fanout;
        await this.queue.publish(exchangeName, input.name, message.getContent());
    }
}

export type ProduceMessageInputDto = {
    origin: "topic" | "direct" | "fanout";
    name: string;
    content: string;
    date: Date;
}

A mágica acontece nesse trecho await this.queue.publish(exchangeName, input.name, message.getContent()); onde estamos efetivamente enviando a mensagem para nosso message broker especificando o exchange desejado.

Consumer

Por fim os consumidores das mensagens que separamos em 2  arquivos simples: controller - que contém os comandos para ler da fila - e handler - que contém efetivamente a lógica do que faremos com a mensagem:

// Consumer1Controller
import { Consumer1Handler } from "../handler/Consumer1Handler";
import { Queue } from "../queue/Queue";

export class Consumer1Controller {
    constructor(queue: Queue) {
        queue.consume("fila1", async function (msg: any) {
            const handler = new Consumer1Handler();
            await handler.handle(msg);
        })
    }
}


// Consumer1Handler
export class Consumer1Handler {
    async handle(message: any) {
        console.log(`consumer-1|${message.sentAt}|${(new Date()).toISOString()}|${message.origin}|${message.content}`);
    }
}

O método consume será chamado cada vez que uma nova mensagem chegar à fila1 e chamará o método handle que poderá fazer o que for necessário com ela, nesse caso, ele apenas organiza e mostra as informações em tela com o prefixo consumer-1

Resultados

Após tudo configurado e, com a aplicação rodando fizemos os seguintes experimentos:

1. Requisição ao endpoint http://localhost:3001/messages/direct?name=fila1

2. Requisição ao endpoint http://localhost:3001/messages/topic?name=fila.logs

3. Requisição ao endpoint http://localhost:3001/messages/fanout

Conclusão

Message brokers, e sistemas de mensageria em geral, possuem uma estrutura robusta e são ferramentas excelentes para comunicação em sistemas distribuídos, principalmente onde resiliência e garantia de entrega são características importantes.

No entanto vale ressaltar que, apesar da implementação parecer simples, é importante lembrar que não existe bala de prata e sempre considerar os trade-offs antes de implementar esse tipo de solução, uma vez que acrescenta uma complexidade que, muitas vezes é desnecessária.

Confira o projeto na íntegra em https://github.com/virb30/rabbitmq-ts

Com a quantidade de frameworks fullstack e de opinião forte - como Laravel, Yii, CodeIgniter e Symfony uma ressalva para esse último - no universo PHP, às vezes parece impossível que consigamos desacoplar o framework de nossa aplicação.

Por sorte, temos os chamados micro-frameworks - como Slim, Lumen, Phalcon e podemos considerar, também o Symfony nessa lista - o que torna essa tarefa um pouco menos árdua.

Nesse artigo iremos desacoplar a utilização de um framework utilizando o Padrão de Projeto Adapter e ainda, "chavear" entre três frameworks diferentes - Slim, Symfony e Lumen - com pouquíssima alteração no código. Não perca!

O que é um padrão de projeto?

Em resumo um padrão de projeto (ou design pattern) é uma solução conhecida, validada e reutilizável para um problema comum.

O Padrão Adapter

O Design Pattern Adapter é um dos 23 padrões de projeto presentes no livro  "Design Patterns: Elements of Reusable Object-Oriented Software" - Gang Of Four que se enquadra na categoria de padrões de Estrutura.

O objetivo principal do padrão adapter é converter a interface de uma classe em outra, permitindo que classes com interfaces incompatíveis trabalhem em conjunto. Veremos esse padrão em ação mais adiante.

Tá na hora do código!

Sobre o código: código de exemplo consiste em uma API que retorna uma listagem fixa de 3 livros. Utilizaremos PHP como linguagem de programação, porém é possível aplicar as técnicas em qualquer linguagem.

Nosso desafio: desacoplar o framework da aplicação possibilitando a substituição do mesmo com pouca ou nenhuma alteração significativa no código.

Conhecendo as implementações

Antes de utilizarmos o padrão adapter, vamos conhecer as diferentes implementações afim de identificarmos os pontos em comum entre elas. Vamos começar com a implementação do Slim criando a classe SlimHttp.

Nos exemplos iremos suprimir alguns trechos do código para facilitar a leitura

<?php declare(strict_types=1);
...
class SlimHttp
{
  public App $app;

  public function __construct()
  {
    $this->app = AppFactory::create();
    $this->app->addErrorMiddleware(true, false, false);
    $this->app->get('/books', function(ServerRequestInterface $request, ResponseInterface $response) {
      $books = [
        (object) ['title' => 'Clean Code'],
        (object) ['title' => 'Refactoring'],
        (object) ['title' => 'Implementing Domain-Driven Design'],
      ];
      $response->getBody()->write(json_encode($books));
      return $response->withHeader('Content-Type', 'application/json');
    });
    $this->app->run();
  }
}

O que estamos fazendo nesse código:

1. Construindo a aplicação Slim
2. Criando uma rota /books que retorna uma lista de livros em formato JSON
3. Iniciando a aplicação

Vamos criar uma nova implementação, semelhante ao Slim, mas utilizando o Lumen, essa é nossa classe LumenHttp:

<?php declare(strict_types=1);
...
class LumenHttp
{
  public Application $app;

  public function __construct()
  {
    $this->app = new Application();
    $this->app->router->addRoute('GET', '/books', function (Request $request, Response $response) {
      $books = [
        (object) ['title' => 'Clean Code'],
        (object) ['title' => 'Refactoring'],
        (object) ['title' => 'Implementing Domain-Driven Design'],
      ];
      $response->setContent(json_encode($books));
      $response->header('Content-Type', 'application/json');
      $response->send();
    });
    $this->app->run(); 
  }
}

Conseguimos identificar alguns padrões entre elas, os principais são:

1. Precisamos definir as rotas
2. Precisamos executar a aplicação para que as rotas sejam processadas

Poderíamos utilizar ambas as classes normalmente em nossa aplicação simplesmente instanciando o framework desejado, nosso public/index.php seria mais ou menos assim:

<?php declare(strict_types=1);
...
require __DIR__ . '/../vendor/autoload.php';
...
new SlimHttp();
// OU
// new LumenHttp();

Nossa aplicação funcionaria normalmente sem grandes alterações, atingimos nosso objetivo, certo? Errado!

Alguns problemas de implementar dessa maneira:

1. Precisaríamos definir todas as rotas novamente a cada novo framework;
2. Precisaríamos replicar as configurações de uma rota nova para todas as implementações dos framework

Tudo isso seria insustentável no longo prazo, portanto vamos construir e implementar o padrão adapter.

Construindo o padrão

Agora que já temos características em comum entre elas, vamos definir a interface do nosso adaptador, que chamaremos de Http:

<?php declare(strict_types=1);
...
interface Http
{
  public function route(string $method, string $url, callable $callback);
  public function run();
}

Nossa interface é bem simples e define apenas dois métodos:

1. route que recebe o método, a url e uma função de callback e é responsável pela definição das rotas
2. run que é responsável por executar a aplicação

Lembrando que o nome, assinatura e quantidade de métodos pode variar conforme a necessidade.

Implementando o Padrão Adapter

Para que possamos utilizar efetivamente o padrão Adapter precisamos fazer alguns ajustes em nossas implementações iniciais, vamos começar alterando a classe SlimHttp

<?php declare(strict_types=1);
...
class SlimHttp implements Http
{
  public App $app;

  public function __construct()
  {
    $this->app = AppFactory::create();
    $this->app->addErrorMiddleware(true, false, false);
  }

  public function route(string $method, string $url, callable $callback)
  {
    $method = strtolower($method);
    $this->app->$method($url, function(ServerRequestInterface $request, ResponseInterface $response) use($callback) {
      $result = $callback($request->getQueryParams(), $request->getParsedBody());
      $response->getBody()->write(json_encode($result));
      return $response->withHeader('Content-Type', 'application/json');
    });
  }

  public function run()
  {
    $this->app->run();
  }
}

Agora que implementamos uma interface, precisamos definir as funções conforme o contrato estabelecido, nesse caso, somos obrigados a definir os métodos route e run.

Além disse fizemos algumas alterações na implementação do método route para que a construção da rota pelo framework ficasse genérica.

Vamos repetir esse procedimento em nossa classe LumenHttp:

<?php declare(strict_types=1);
...
class LumenHttp implements Http
{
  public Application $app;

  public function __construct()
  {
    $this->app = new Application();
  }

  public function route(string $method, string $url, callable $callback)
  {
    $this->app->router->addRoute(strtoupper($method), $url, function (Request $request, Response $response) use($callback) {
      $result = $callback($request->query->all(), $request->request->all());
      $response->setContent(json_encode($result));
      $response->header('Content-Type', 'application/json');
      $response->send();
    });
  }

  public function run()
  {
    $this->app->run(); 
  }
}

Com exceção de alguns detalhes de implementação que são características do Lumen, a implementação dos métodos route e run são bem semelhantes.

Agora vamos atualizar nosso entrypoint public/index.php para utilizar o padrão adapter que acabamos de construir.

<?php declare(strict_types=1);
...
require __DIR__ . '/../vendor/autoload.php';
...
$http = new SlimHttp();

$http->route('get', '/books', function($params, $body) {
  $books = [
    (object) ['title' => 'Clean Code'],
    (object) ['title' => 'Refactoring'],
    (object) ['title' => 'Implementing Domain-Driven Design'],
  ];
  return $books;
});

$http->run();

O que estamos fazendo:

1. Construindo um objeto $http correspondente ao framework que queremos utilizar
2. Definindo as rotas
3. Executando a aplicação

Com isso se quisermos utilizar o Lumen, só precisamos alterar a construção do $http para $http = new LumenHttp() e todo o resto funciona normalmente.

Mas e se eu quiser utilizar um terceiro framework?

Utilizando o padrão adapter precisamos apenas seguir os mesmos passos para os dois primeiros:

1. Criar uma classe que implementa a interface Http
2. Trocar a implementação no public/index.php

Vamos ver na prática o que teríamos que fazer no nosso código para utilizar o Symfony:

1. Começamos criando a classe SymfonyHttp que implementa a interface Http

<?php declare(strict_types=1);
...
class SymfonyHttp implements Http
{
  public $routes;
  public RequestContext $context;

  public function __construct()
  {
    $this->routes = new RouteCollection();
    $this->context = new RequestContext();
  }

  public function route(string $method, string $url, callable $callback)
  {
    $this->routes->add('books', new Route(
      '/books',
      ['handler' => function(Request $request) use($callback) {
        $result = $callback($request->query->all(), $request->request->all());
        $response = new Response(json_encode($result));
        $headers = new ResponseHeaderBag(['Content-Type' => 'application/json']);
        $response->headers = $headers;
        $response->send();
      }],
      [],
      [],
      '',
      [],
      [strtoupper($method)]
    ));
  }

  public function run()
  {
    $request = Request::createFromGlobals();
    $this->context->fromRequest($request);
    $matcher = new UrlMatcher($this->routes, $this->context);
    $parameters = $matcher->match($this->context->getPathInfo());
    $parameters['handler']($request);
  }
}

2. Trocar a implementação no public/index.php

<?php declare(strict_types=1);
...
require __DIR__ . '/../vendor/autoload.php';
...
$http = new SymfonyHttp();

$http->route('get', '/books', function($params, $body) {
  $books = [
    (object) ['title' => 'Clean Code'],
    (object) ['title' => 'Refactoring'],
    (object) ['title' => 'Implementing Domain-Driven Design'],
  ];
  return $books;
});

$http->run();

E pronto nossa aplicação deve estar funcionando conforme o esperado mas utilizando o Symfony.

Conclusão

Vimos nesse artigo como o Padrão de Projeto Adapter pode nos ajudar quando precisamos variar implementações de diferentes bibliotecas ou frameworks que servem a um mesmo propósito (e são relativamente semelhantes entre si).

No entanto para frameworks mais opinativos (como Laravel ou Yii) esse tipo de troca é inviável uma vez que eles possuem diversas dependências e estruturas exclusivas do framework e que servem justamente para estabelecer um padrão entre todos os usuário daquele framework.

O código na íntegra está disponível no github e é parte de um projeto pessoal de um mini e-commerce utilizando Clean Code e Clean Architecture e que está ainda se encontra desenvolvimento:

GitHub - virb30/cc-ca-php

Contribute to virb30/cc-ca-php development by creating an account on GitHub.

GitHubvirb30

Dando continuidade na nossa série sobre testes automatizados e TDD falaremos um pouco sobre os dublês de teste, seus tipos e quando utilizar cada um.

E caso você ainda não tenha visto as partes anteriores dessa série, recomendo dar uma olhada:

• Parte 1 - Conceitos iniciais
• Parte 2 - Anatomia de um teste e exemplos

FIRST

Antes de avançarmos nos dublês de teste é importante ressaltar as características que um (bom) teste deve possuir, para isso utilizamos a sigla FIRST:

1. Fast - Os testes devem ser rápidos
2. Independent - Um teste não deve depender de outro, eles devem poder ser executados de maneira isolada
3. Repeatable - Os testes devem poder serem executados inúmeras vezes sem que haja alteração no seu resultado
4. Self-validating - O próprio teste deve ter uma saída bem definida e ser capaz de indicar se passou ou falhou
5. Timely - Os testes devem ser escritos antes do código-fonte (aplicável ao TDD)

Dublê de teste

Test double ou dublê de teste é um padrão de teste (test pattern) que tem como objetivo substituir uma implementação por motivos de performance ou segurança. Podemos dividir os test patterns em: dummy, stubs, spies, mocks e fake. Não se preocupe, mostraremos cada um deles a seguir.

Muitas bibliotecas tratam os tests patterns como Mock, portanto é comum encontrar bibliotecas do tipo Mockery no PHP, ou mesmo métodos no PHPUnit como createMock sendo utilizado para criar um Spy, mas lembre-se cada padrão desempenha um papel diferente.

Dummy

Podemos dizer que Dummy é o test pattern mais simples: dummies são objetos que criamos apenas para completar a lista de parâmetros necessários para invocar determinado método.

Dando sequência a nossa aplicação de catálogo de filmes, vamos agora criar a classe MovieCatalog que será nosso catálogo de filmes. Essa classe terá um método addMovie que receberá um objeto do tipo Movie e irá inseri-lo na lista.

Vamos ver como fica o teste:

<?php declare(strict_types=1);
class MovieCatalogTest extends TestCase
{
  public function testShouldAddMovieToCatalog()
  {
    $catalog = new MovieCatalog();
    $movie = new Movie(
   	  id:'1',
      name: 'Movie 1',
      summary: ''
    );
    
    $catalog->addMovie($movie);
    $this->assertNotEmpty($catalog->getMovies());
  }
}

Nesse exemplo estamos criando um objeto do tipo Movie com quaisquer informações apenas para passarmos para o método addMovie uma vez que as informações contidas no objeto não são relevantes para a validação do nosso teste.

Stubs

Diferente dos dummies que são objetos sem comportamento, que servem apenas para completar os parâmetros necessários, os stubs são objetos que retornam respostas prontas para um determinado teste por questões de performance ou segurança.

Vamos supor que, quando um filme for inserido no catálogo iremos fazer uma requisição a uma API externa para obter a nota média da avaliação dos usuários para esse filme.

Para ilustrar criamos uma classe chamada MovieApi que retorna um número aleatório a cada execução.

<?php declare(strict_types=1);

namespace App;

class MovieApi
{
  public function getMovieRate(Movie $movie)
  {
    return rand(0, 5);
  }
}

Cada vez que um filme é adicionado no catálogo, uma requisição à API é feita e a nota média do filme é incluída no catálogo. Incluímos aqui a MovieApi como injeção de dependência, para facilitar nossos testes:

 ...
 
 public function __construct(?MovieApi $movieApi = null)
 {
   $this->movieApi = $movieApi;
 }
 
 ...
 
 public function addMovie(Movie $movie)
  {
    $movieApi = new MovieApi;
    $this->sumMovieRates += $movieApi->getMovieRate($movie);
    array_push($this->movies, $movie);
  }

Nosso teste quer validar que que a nota média dos filmes no catálogo é 4:

public function testShouldUpdateAvgRate()
  {
    $catalog = new MovieCatalog();

    $movie = new Movie(
      id: '1',
      name: 'Movie 1',
      summary: ''
    );

    $catalog->addMovie($movie);

    $this->assertEquals(4, $catalog->getAvgRate());
  }

Nesse caso se mantivermos a comunicação com uma API real estaremos ferindo o R do FIRST, uma vez que a cada execução obteremos um resultado diferente. Vamos ver como é possível resolver esse problema utilizando um Stub :

 public function testShouldUpdateAvgRate()
  {
    $stub = $this->createStub(MovieApi::class);
    $stub->method('getMovieRate')
      ->willReturn(4);

    $catalog = new MovieCatalog($stub);

    $movie = new Movie(
      id: '1',
      name: 'Movie 1',
      summary: ''
    );

    $catalog->addMovie($movie);

    $this->assertEquals(4, $catalog->getAvgRate());
  }

Após a alteração estamos indicando à nossa classe MovieCatalog para utilizar um dublê da MovieApi cujo método getMovieRate sempre retornará o valor 4.

Até o momento da escrita desse artigo, o PHPUnit não possuía uma forma nativa para criar stubs de hard dependencies ou seja classes que são instanciadas diretamente na implementação. Para esses casos recomendamos a utilização da biblioteca Mockery que fornece alguns poderes a mais ao PHPUnit.

Spies

Spies são objetos que espionam a execução do método armazenando seus resultados e alguns meta-dados como: quantas vezes foi chamado ou quais parâmetros foram passados.

Vamos duplicar nosso teste anterior para garantir que o método getMovieRate da nossa API tenha sido chamado apenas uma vez.

NOTA: O PHPUnit não possui um método nativo para criação de spies para isso utilizaremos o método createMock que nos dá a possibilidade de espionar a execução do método.

public function testShouldCallGetMovieRateOnce()
  {
    $spy = $this->createMock(MovieApi::class);
    $spy->expects($this->once())
    ->method('getMovieRate');

    $catalog = new MovieCatalog($spy);

    $movie = new Movie(
      id: '1',
      name: 'Movie 1',
      summary: ''
    );

    $catalog->addMovie($movie);
  }

Nesse exemplo se inserirmos uma chamada adicional ao método addMovie o teste falhará pois o método getMovieRate terá sido chamado mais de uma vez.

Mocks

Mocks são objetos similares a stubs e spies que permitem que você diga exatamente o que quer que ele faça.

Poderíamos evoluir o teste acima adicionando o comportamento que incluímos no exemplo do stub, vamos ver como fica:

public function testShouldCallGetMovieRateOnce()
  {
    $mock = $this->createMock(MovieApi::class);
    $mock->expects($this->once())
      ->method('getMovieRate')
      ->will($this->returnValue(4));

    $catalog = new MovieCatalog($mock);

    $movie = new Movie(
      id: '1',
      name: 'Movie 1',
      summary: ''
    );

    $catalog->addMovie($movie);
    $this->assertEquals(4, $catalog->getAvgRate());
  }

Nesse exemplo combinamos o comportamento do stub ao retornar um valor fixo e do spy ao verificar a quantidade de vezes que o método foi chamado.

Fake

Fakes são objetos cuja implementação simula o funcionamento da instância real que seria utilizada em produção. Como exemplo podemos citar um banco de dados em memória, ou mesmo a implementação da nossa API em nossos exemplos que retorna um número randômico simulando um possível retorno de uma API real.

Conclusão

Conhecemos o conceito de FIRST e tests patterns - padrões para escrever tests de maneira performática e segura e que não ferem o FIRST.

Apesar das limitações dos métodos nativos do PHPUnit é possível atingirmos o objetivo principal dos dublês de teste que é simular o comportamento da implementação real, sem correr riscos desnecessários de performance ou segurança.

Citamos também algumas bibliotecas (do PHP) que podem auxiliar nossos testes como Mockery e prophecy. Caso queira experimentar um pouco mais os tests patterns, recomendamos a utilização da bilioteca sinon do JavaScript pois ela segue a nomenclatura e os conceitos das técnicas citadas nesse artigo.

Na próxima e última parte dessa série entraremos nos conceitos do TDD e como essa técnica pode nos ajudar a desenvolver códigos melhores. Nos vemos lá!

Na segunda parte da nossa série sobre testes automatizados e TDD mostraremos alguns exemplos práticos de testes automatizados utilizando PHP. Escolhi PHP por ser a linguagem que tenho maior domínio, mas ressalto que os conceitos aqui apresentados podem ser aplicados a qualquer linguagem de programação e ferramenta (com algumas adaptações, é claro).

Planejar testes

Antes de partirmos para o código, vale lembrar que em uma situação real nem sempre conseguiremos automatizar todos os testes, nesses casos, é necessário, fazer uma análise criteriosa de quais casos de teste devem ser automatizados. Alguns critérios de escolha são:

• Funcionalidades importantes do sistema;
• Funcionalidades utilizadas com frequência;
• Casos de teste que envolvem riscos para o Negócio.

Nessa etapa são planejados o ambiente de teste utilizado, cronograma de execução, entregáveis gerados com a execução, equipe envolvida, escopo de automação, entre outros.

Tá na hora do código

Um pouco de contexto: imagine uma aplicação bem simples que consiste em um catálogo de programas (filmes/séries etc.) onde o usuário deve ser capaz de marcar como assistido/não assistido.

O programa (filme/série) tem as seguintes propriedades: id, nome, resumo e assistido. Nossa classe Movie.php ficou assim:

OBS: já estou utilizando alguns recursos novos do PHP 8, como propriedades nomeadas, mas nada impediria de extrair as propriedades de um array ou em parâmetros separados no construtor.

<?php

declare(strict_types=1);

class Movie 
{
  private $watched = false;

  public function __construct(
    private string $id,
    private string $name,
    private string $summary
  ) {}

  public function toggleWatched() {
    $this->watched = !$this->watched;
  }

  public function isWatched() {
    return $this->watched;
  }
}

Vamos ao teste

Nosso primeiro teste será bem simples: o usuário deve poder marcar um filme como assistido/não assistido. Faremos esse teste de duas maneiras (com e sem o auxílio de uma ferramenta - no caso o PHPUnit), ou seja, queremos se o método toggleWatched funciona conforme o esperado.

Nosso objetivo com esse primeiro teste é demonstrar o conceito conhecido como AAA (Arrange, Act, Assert) que consiste em uma divisão lógica do código em 3 etapas:

1. Arrange: o setup inicial do teste, é aqui que definimos tudo que o teste utilizará;
2. Act: é nessa etapa que executamos de fato o que queremos testar;
3. Assert: por fim verificamos se o resultado da execução é o resultado esperado.

Nosso arquivo test.php ficou da seguinte maneira:

<?php

declare(strict_types=1);

require 'Movie.php';

// Arrange
// Instanciamos o objeto $movie
$movie = new Movie(
  id: '1',
  name: 'Brooklyn 99',
  summary: ''
);

// Act
$movie->toggleWatched();

// Assert
if ($movie->isWatched() === true) {
  echo "PASSED".PHP_EOL;
} else {
  echo "FAIL".PHP_EOL;
}

Vejamos os 3 A's em ação:

1. Arrange: nessa etapa instanciamos um novo objeto da classe Movie;
2. Act: nessa etapa chamamos o método toggleWatched que, conforme definimos, inverte o valor da propriedade $watched, que inicia como false;
3. Assert: por fim verificamos se o resultado é o esperado, em caso de sucesso imprime no terminal PASSED, em caso de falha mostra FAIL.

Para executar esse teste basta executar o comando php test.php.

Como vimos, é perfeitamente possível realizar testes automatizados sem o auxílio de nenhuma ferramenta, porém à medida que os testes crescem e ficam mais complexos sua programação também ficará mais complexa.

Além disso as ferramentas possuem uma interface mais amigável, facilitando a visualização de quais erros passaram e quais falharam.

Utilizando o PHPUnit

Primeiramente precisamos instalar o phpunit, utilizaremos o composer para isso com o comando sugerido pela documentação oficial composer require --dev phpunit/phpunit ^9.5.

Por convenção o PHPUnit procura algumas condições específicas para executar os testes, são elas:

1. O arquivo da classe de teste deve terminar em Test - é recomendado utilizar [nomeDaClasseTestada]Test;
2. Os métodos da classe de teste devem iniciar com test - exemplo : testMetodoIsTrueDeveRetornarTrue
3. Os métodos de teste devem ter pelo menos um assert.
4. A classe de teste deve extender de PHPUnit\Framework\TestCase.

NOTA: Lembrando que todas essas convenções podem ser configuradas no arquivo phpunit.xml, mas não entraremos nesse nível detalhe nesse momento.

A seguir vamos alterar nosso arquivo test.php seguindo as convenções do PHPUnit, sendo assim renomeamos o arquivo para MovieTest.php e seu conteúdo ficou assim:

<?php declare(strict_types=1);

require 'Movie.php';

use PHPUnit\Framework\TestCase;

class MovieTest extends TestCase
{
  public function testToggleWatched()
  {
    // Arrange
    // Instanciamos o objeto $movie
    $movie = new Movie(
      id: '1',
      name: 'Brooklyn 99',
      summary: ''
    );

    // Act
    $movie->toggleWatched();

    // Assert
    $this->assertTrue($movie->isWatched());
  }
}

Perceba que mantivemos a estratégia dos 3 A's apenas ajustamos os métodos para que o PHPUnit encontrasse os testes para execução. Quando executamos o comando php vendor/bin/phpunit MovieTest.php temos o seguinte resultado:

O resultado do teste nos mostra que 1 teste foi executado e 1 assertion passou. Se utilizarmos o parâmetro --colors temos um resultado mais amigável:

Em caso de falha o PHPUnit também nos mostra qual classe / assertion a falha ocorreu:

Dessa forma fica muito mais fácil e rápido identificar qual teste falhou.

Conclusão

Nessa parte vimos mais alguns conceitos sobre testes automatizados, a importância de planejar os testes, como compor e escrever um teste, com e sem o auxílio de ferramentas. Também vimos as facilidades que a utilização de ferramentas especializadas em testes automatizados nos conferem, tanto na visualização, quanto na execução dos testes.

Apesar de utilizarmos PHP e o PHPUnit nos exemplos esses conceitos podem ser aplicados em qualquer framework ou linguagem.

Na próxima parte entraremos em conceitos um pouco mais avançados no mundos dos testes: dublês de teste. Falaremos sobre os tipos de dublês de testes e traremos exemplos de como utilizá-los no PHPUnit. Nos vemos lá!

Inspirado pela playlist sobre testes automatizados do Vinícius Dias (canal DiasdeDev), resolvi trazer para o blog alguns artigos sobre esse tema, começando com a teoria por trás dos testes automatizados, alguns exemplos práticos e também um pouco sobre TDD.

O que são testes automatizados?

Testes automatizados ou automação de testes é um método de testar softwares, que conta com o auxílio (ou não) de ferramentas especiais para controlar sua execução e compara o resultado obtido com um resultado esperado. Todo esse processo é realizado de maneira automática com pouca ou nenhuma intervenção humana.

Vantagens

As principais vantagens que podemos listar com relação a testes automatizados são:

1. Testes automatizados não dependem de recurso humano para ser executado. assim é possível executá-lo em horários alternativos, liberando desenvolvedores a executarem outras tarefas;
2. Reduz os erros humanos na execução dos testes. Quando todos os cenários são mapeados nos testes automatizados, conseguimos reduzir os erros humanos (ou vícios) dos testes manuais.
3. Teste automatizados são facilmente reproduzidos. Com testes automatizados não é necessário conhecimento completo do funcionamento do sistema, uma vez que qualquer desenvolvedor é capaz de reproduzir a execução dos testes.
4. Feedback mais rápido. Com testes automatizados conseguimos identificar mais rapidamente quando o software não está funcionando da maneira esperada.

Desvantagens

Apesar das inúmeras vantagens dos testes automatizados, também podemos listar algumas de suas desvantagens:

1. É necessário utilizar recursos para desenvolver os testes automatizados. Existe um trabalho adicional durante o desenvolvimento para que os testes sejam escritos.
2. Demanda conhecimento sobre automação de testes. Testes automatizados mal definidos podem causar falsa sensação de que o software está funcionando corretamente, por isso é necessário capacitação da equipe.
3. Podem exigir recursos adicionais. Pode ser necessário a construção de um ambiente dedicado aos testes, com banco de dados etc.
4. Pode desviar o objetivo principal dos testes. Pode causar o efeito de programar apenas para fazer o teste passar, desviando o foco do objetivo principal que é solucionar um problema.

Tipos de testes automatizados

Existem vários tipos de testes automatizados, todos têm um mesmo objetivo: reduzir o trabalho manual no teste de software, cada literatura divide os tipos de testes de uma maneira. Reuni alguns e separei da maneira que foi a mais fácil de entender durante meus estudos, são eles:

1. Teste de Unidade - Testes de unidade (ou unitários) são responsáveis por testar a menor unidade de código possível, por exemplo, para assegurar o funcionamento correto de um método, ou um cálculo etc.
2. Testes de Integração - Teste de integração asseguram que as unidades estão comunicando entre si da maneira esperada. Geralmente é nesse tipo de teste que verificamos se os dados estão sendo salvos corretamente no banco de dados, por exemplo.
3. Testes End to End (E2E) - Testes End-to-End (E2E) visam garantir o funcionamento de ponta a ponta da aplicação, normalmente simula o comportamento do usuário através da navegação pelas telas.
4. Teste de carga - Teste de carga servem para determinar o desempenho de um sistema em condições de carga da vida real. Através desse tipo de teste conseguimos validar o comportamento do sistema quando vários usuários acessam simultaneamente.

Pirâmide de testes

Mike Cohn propôs o conceito de pirâmide de testes em seu livro Succeeding with Agile, porém nem todos concordam com a nomenclatura utilizada por Mike Cohn, por isso, algumas versões da pirâmide foram derivadas da proposta original, uma delas, que gosto de utilizar como base, pode ser vista na figura da direita da imagem abaixo:

A proposta diz que devemos priorizar os testes debaixo para cima (bottom-up), ou seja, devemos ter em nosso sistema uma base sólida de testes de unidade (mais baratos e rápidos de serem executados) seguido de testes de integração e por fim testes E2E.

Porém o que vemos na maioria dos cenários é a ilustrado na figura da direita em que vemos a predominância de testes manuais e poucos testes de unidade.

Conclusão

O desenvolvimento de testes automatizados não é uma tarefa trivial e exige um certo conhecimento da equipe para que os testes automatizados não causem mais prejuízo do que benefícios.

É recomendado a implantação de testes automatizados em estágios iniciais do desenvolvimento (falaremos mais sobre isso quando abordarmos TDD). Em se tratando de sistemas já existentes, por exemplo, é importante que haja uma análise criteriosa de como os testes automatizados serão implementados para que não representem mais desvantagens do que vantagens.

Na próxima parte dessa série trarei exemplos práticos dos testes automatizados utilizando PHP, com e sem frameworks de teste. Também falaremos sobre dublês de teste e seus tipos. Até lá!

Nessa série utilizaremos Auto Machine Learning para realizar as análises e construir nossos modelos.

O que é Auto Machine Learning?

Auto Machine Learning (AutoML) são frameworks, ou conjunto de bibliotecas, que nos auxiliam no processo de análise dos dados e construção de modelos de machine learning, poupando tempo do cientista de dados no processo de exploração dos dados e seleção de algoritmos. As bibliotecas mais famosas de AutoML que podemos citar são PyCaret e FB Prophet.

Neste artigo iremos construir um modelo de Machine Learning para prever o custo do plano de saúde utilizando AutoML.

O problema

O papel do seguro é ser uma ferramenta para gerenciar o risco financeiro, é evidente que possuir um seguro de saúde melhora a segurança financeira conforme descrito neste artigo do The new england journal of medicine.

Ainda segundo os autores desse artigo, a expansão da cobertura por seguro aumentou, significativamente o acesso de pacientes a serviços de saúde, uso de saúde preventiva, tratamento de doenças crônicas, medicamentos e cirurgias, promovendo, portanto benefícios à saúde como detecção precoce de doenças, melhor aderência à medicamentos e gestão de condições crônicas.

Mas todos esses benefícios têm um custo: mais despesas para os órgãos estaduais, federais, locais ou privados.

Diante disso empresas que comercializam seguro de vida, com o objetivo de reduzir os potenciais prejuízos e ainda assim serem competitivas no mercado, costumam determinar o preço dos seus serviços através da avaliação de risco do cliente.

Objetivo Geral

O objetivo desse projeto é construir um modelo de Machine Learning de regressão para prever custos de seguro de vida utilizando AutoML.

Objetivos específicos

Para atingirmos o objetivo geral proposto iremos realizar as seguintes etapas de modo a conhecer nossos dados e escolher o melhor modelo para o problema proposto:

1. Aquisição dos dados
2. Análise exploratória
3. Tratamento dos dados
4. Escolha do modelo
5. Treinamento do modelo
6. Avaliação do modelo
7. Teste do modelo

Aquisição dos Dados

Os dados foram obtidos do Kaggle, plataforma amplamente utilizada para competições e ensino de Data Science e Machine Learning.

Análise Exploratória

Como primeira etapa de todo projeto de Data Science, precisamos conhecer o dataset que estamos trabalhando. Verificamos que nosso conjunto de dados contém 1338 registros e 7 variáveis.

Separação dos dados

Para evitarmos contaminar nosso modelo com dados que serão utilizados para teste, primeiramente devemos separar o conjunto de dados entre treino e teste, esse último será apresentado ao modelo apenas no final do processo, ou seja quando o modelo estiver testado e validado.

Tratamento dos dados

Antes de avançarmos para o treinamento do modelo, precisaremos realizar alguns tratamentos nos dados. Pela nossa análise exploratória podemos perceber que variáveis region, sex e smoker são do tipo texto, portanto precisaremos convertê-las antes de treinar nosso modelo.

Iremos converter a variável smoker para 0 e 1 de modo que no = 0 e yes = 1 Também iremos converter as variáveis region e sex utilizando a técnica de OneHotEncoding, para esse último deixaremos o PyCaret realizar a transformação.

A etapa de tratamento dos dados é uma das mais importantes no processo de construção de um modelo de Machine Learning, apesar o PyCaret ser capaz de realizar as transformações necessárias de maneira eficiente, optamos por realizar algumas transformações manuais.

Escolha do modelo

É nessa etapa que vemos todo o poder do AutoML em ação, com um simples comando, conseguimos criar vários modelos e comparar quais possuem o melhor desempenho.

Para isso utilizamos a função setup do PyCaret, como sabemos que se trata de um problema de regressão, utilizaremos o pacote pycaret.regression:

from pycaret.regression import *

reg = setup(data = train,
            target = 'charges',
            normalize = True,
            log_experiment = False)

Passamos para a função setup nosso dataset, o nome da variável alvo e algumas flags para que o PyCaret inclua alguns passos no seu pipeline. A flag normalize indica ao PyCaret que queremos normalizar nossos dados numéricos para que fiquem numa mesma escala.

Após a realização do setup podemos verificar qual o melhor modelo utilizando o comando compare_models().

Para nosso cenário selecionamos os 3 primeiros modelos para que, após o tuning, verificarmos qual possui o melhor desempenho. Os modelos selecionados foram: Gradient Boosting Regressor (GBR), Random Forest Regressor e Light GBM.

Tunando os modelos

Quando um modelo é criado usando o create_model() ele usa os hiperparâmetros padrão para cada modelo. Para fazer o tuning desses parâmetros, usamos a função tune_model().

Essa função faz o tuning dos parâmetros automaticamente, e mais uma vez o avalia com validação cruzada.

Por padrão o tune_model() utiliza o Random Grid Search para encontrar os parâmetros otimizados.

O tuning dos modelos nos revelou algumas características interessantes:

• o GBR com parâmetros default apresentou desempenho ligeiramente melhor do que sua versão tunada.
• o Random Forest tunado apresentou melhor desempenho superando até a versão default GBR
• o Light GBM tunado apresentou melhor desempenho que sua versão com parâmetros default. Mas ainda assim se mostrou inferior ao Random Forest.

Diante dos resultados e levando em consideração nossa análise, apesar do modelo de Random Forest ter apresentado desempenho ligeiramente superior ao GBR, seu tempo de execução é consideravelmente maior, não justificando, portanto o ganho de performance. Em nosso cenário escolheríamos o GBR.

Com o modelo tunado e treinado, basta finalizá-lo, utilizando o método finalize_model() e realizar um teste final com dados não vistos pelo modelo, que ele estará pronto para ser colocado em produção.

Conclusão

Construímos e comparamos alguns modelos de Machine Learning para realizar a previsão de custos de seguro de vida.

Todo esse processo de treinamento e avaliação dos modelos foi mais simples e rápido com a utilização de frameworks de Auto Machine Learning, no entanto vale ressaltar que tais técnicas não devem ser utilizadas sem que haja, primeiro, um entendimento claro do problema e dos dados que estamos lidando.

Percebemos também que, apesar de apresentar um desempenho ligeiramente superior, o algoritmo de Random Forest mostrou-se mais lento na execução do que o Gradient Boosting Regressor justificando nossa escolha por esse último.

Existem diversas melhorias que podemos fazer nesse projeto tais como:

1. avaliar outros modelos e/ou outras métricas de desempenho
2. realizar outros tratamentos nos dados como remoção/ajustes de outliers que podem influenciar negativamente nossas previsões - e que optamos por não fazê-lo nessa análise.

A análise completa você confere abaixo:

health-insurance-prediction/PROJETO_Prevendo_custo_de_Seguro_de_Vida_com_PyCaret.ipynb at main · virb30/health-insurance-prediction

Contribute to virb30/health-insurance-prediction development by creating an account on GitHub.

GitHubvirb30

Churn ou Churn rate, é uma métrica que representa a taxa de evasão de clientes em determinado período de tempo, ou seja, quanto menor o Churn Rate, melhor.

Outra métrica bastante relevante e derivada dessa taxa, é o Churn de Receita ou Monthly Recurring Revenue (MMR) Churn que representa o total de receita perdida em razão desses cancelamentos.

O que fazer com essa informação?

Através da taxa de churn (ou churn rate) e sua análise ao longo do tempo é possível identificar se há algum problema que deve ser atacado de modo a evitar a evasão de clientes, por exemplo se há algum aspecto do produto que têm desagradado os usuários a ponto de cancelar o serviço.

Como utilizar essa informação?

Churn também pode ser utilizado para identificar potenciais cancelamentos com antecedência, possibilitando a tomada de ações para reter tais clientes.

Para empresas que querem crescer, é necessário investir para adquirir novos clientes. Cada vez que um cliente cancela um serviço isso representa uma perda de investimento significativa, consequentemente mais tempo e esforço serão necessários para repor esse cliente.

Ser capaz de prever quando um cliente está propenso a cancelar e pró-ativamente oferecer incentivos para que ele fique pode oferecer grandes economias para um negócio.

O que vamos fazer?

Nesse projeto iremos construir um modelo de Machine Learning utilizando o algoritmo XGBoost e compararemos seu desempenho com um modelo baseado em Árvore de Decisão.

Aquisição dos dados

Os dados utilizados neste projeto foram originalmente disponibilizados na plataforma de ensino da IBM Developer, e tratam de um problema típico de uma companhia de telecomunicações. O dataset completo pode ser encontrado neste link.

Apesar de não haver informações explícitas disponíveis, os nomes das colunas permitem um entendimento a respeito do problema.

Análise Exploratória

Como todo projeto de Data Science começamos realizando a análise exploratória dos dados de modo a identificar com o que estamos lidando: quantas e quais são as variáveis e seus respectivos tipos, quantos registros o conjunto de dados possui, se temos dados ausentes e quais tratamentos precisaremos realizar.

Após a análise do nosso dataset chegamos ao seguinte cenário:

1. Nosso dataset possui 7043 registros;
2. Nossa variável alvo é representada pela coluna Churn e possui menos amostras de cancelamento do que não cancelamento (que era esperado);
3. As colunas tenure, MonthlyCharges e TotalCharges são numéricas, as demais são categóricas;
4. As variáveis categóricas possuem, no máximo 4 categorias possíveis;
5. A coluna TotalCharges possui 11 registros com o valor " " (texto vazio).

Tratamento dos dados

Aplicaremos os passos a seguir para a transformação dos dados de modo que fiquem preparados para utilização no modelo. Essas mesmas etapas deverão ser seguidas tanto nos conjuntos de treino quanto nos de teste:

1. Codificar as variáveis categóricas utilizando OneHotEncoding (se você não está familiarizado com esse termo, confira esse artigo);
2. Padronizar as variáveis numéricas de modo que elas fiquem numa mesma escala;

Como nossos dados estão desbalanceados, precisaremos balanceá-los antes de treinar o modelo, para isso utilizaremos a técnica de Under sampling - que elimina alguns registros da classe majoritária até que o conjunto esteja balanceado. Faremos isso apenas com o conjunto de treino.

Escolhendo um modelo

Como mencionamos anteriormente iremos utilizar o XGBoost para essa análise, nesse artigo o autor compara 4 algoritmos de Machine Learning: Árvores de Decisão, Random Forest, Gradient Boosted Machine Tree “GBM” e XGBoost, como resultado, o XGBoost foi o que apresentou melhor desempenho.

Treinando e avaliando o modelo

Com o modelo escolhido podemos continuar para as etapas de treinamento e avaliação do modelo.

O treinamento consiste em passar os dados de treino para o pipeline, o pipeline é responsável por realizar as transformações dos dados e treinar fit o modelo.

pipeline = Pipeline([
  ('feature_transformer', features_transformer),
  ('classifier', model)
])

pipeline.fit(X_train_balanced, y_train_balanced)

Com o modelo treinado passamos os dados de validação para realizar as previsões

y_pred = pipeline.predict(X_val)
y_proba = pipeline.predict_proba(X_val)

Com as previsões realizadas é possível avaliar o desempenho do modelo, em nosso caso estamos utilizando a métrica recall, ou seja, taxa de previsões de churn positivo (clientes que cancelaram o serviço) realizadas corretamente pelo algoritmo. Os resultados podem ser vistos na imagem abaixo:

Obtivemos uma taxa de 76% de acerto para churn = 1 (sim)

Melhorando o Modelo

Com uma primeira versão do modelo criada, vamos tentar melhorar seu desempenho com alguns ajustes nos parâmetros (ou fine tuning). Iremos contar com a ajuda do GridSearch para descobrirmos os melhores parâmetros.

# importar pacotes
from sklearn.model_selection import GridSearchCV

# definir parâmetros que serão avaliados
parameters = {
    'learning_rate': [0.01, 0.05, 0.1],
    'n_estimators': [100, 500],
    'max_depth': [4, 5, 6],
    'eta': [0.01, 0.05, 0.1],
    'subsample': [0.9],
    'colsample_bytree': [0.2]
}

clf = GridSearchCV(model, parameters)
X_train_transformed = features_transformer.fit_transform(X_train_balanced)
clf.fit(X_train_transformed, y_train_balanced)
print("Melhor: {} usando {}".format(clf.best_score_, clf.best_params_))

O GridSearch sugere que utilizemos:

1. colsample_bytree = 0.2
2. eta = 0.01
3. learning_rate = 0.05
4. max_depth = 4
5. n_estimators = 100
6. subsample = 0.9

Treinaremos novamente nosso modelo, dessa vez com esses parâmetros e realizaremos as previsões:

# novo modelo com tunning
model_tuned = XGBClassifier(
  learning_rate=0.05,
  n_estimators=100,
  max_depth=4,
  gamma=1,
  subsample=0.9,
  colsample_bytree=0.2,
  objective='binary:logistic',
  eta=0.01,
  random_state=42,
)

# replace pipeline model
pipeline.steps[1] = ('classifier', model_tuned)

# treinar modelo
pipeline.fit(X_train_balanced, y_train_balanced)

# realizar previsões
y_pred = pipeline.predict(X_val)
y_proba = pipeline.predict_proba(X_val)

Com o novo modelo treinado obtivemos um desempenho um pouco melhor: 79% de recall:

Conclusão

Nosso modelo apresentou melhor desempenho do que um modelo baseado em Árvore de decisão, conforme exposto nesse artigo.

Vimos ainda que é possível melhorar o desempenho dos modelos apenas realizando o tunning adequado nos seus parâmetros. No entanto, a melhora mais significativa foi obtida com o tratamento adequado nos dados e na escolha do modelo.

Vale ressaltar ainda que como nosso conjunto de dados contém dados do usuário somente - e não possui dados referentes à experiência do usuário, por exemplo número de reclamações ou solicitações de suporte - não foi possível realizar nenhuma engenharia que nos desse mais informações e possivelmente melhorar ainda mais o desempenho.

Por fim, podemos dizer que nosso modelo obteve um desempenho satisfatório ao conseguir prever corretamente aproximadamente 80% dos casos de churn.

O Projeto

churn-prediction/Projeto_Churn_Prediction_para_uma_empresa_de_Telecomunicações.ipynb at main · virb30/churn-prediction

Contribute to virb30/churn-prediction development by creating an account on GitHub.

GitHubvirb30

Referências

What is customer churn prediction and why is it important?

Customer churn is one of the most important metrics for a growing business to evaluate. Read on to learn what Customer Churn is and why it is important.

Avaus

Churn Rate: o que é e como reduzir para sua empresa crescer

Entenda o Churn!

Resultados DigitaisResultados Digitais

A maioria dos algoritmos de Machine Learning trabalham apenas com dados numéricos, porém os problemas do mundo real muitas vezes trarão variáveis categóricas (ex: sim/não, alto/médio/baixo, ruim/regular/bom entre outros exemplos). Como podemos, então, construir um modelo de Machine Learning que utiliza variáveis desse tipo?

As duas maneiras mais comuns de converter/codificar variáveis categóricas são: Label Encoder e One-hot Encoder. Ambos os métodos tem o mesmo objetivo: codificar categorias em números. Nesse artigo vamos falar um pouco sobre elas, suas vantagens e desvantagens e quando utilizar cada uma.

Label Encoder

Label Encoding consiste em converter as classes categóricas em números que as representam (ex: masculino/feminino são convertidos em 0/1, Brasil/EUA/Japão serão convertidos em 0/1/2, etc.). Vamos utilizar como exemplo os países, que não possuem relação de ordem, utilizar o Label Encoder teria o seguinte resultado:

A coluna "País" poderia ser removia, porém optamos por mantê-la na imagem para fins didáticos.

Porém o Label Encoder introduz um novo problema para o modelo. Se tomarmos como exemplo os países: Brasil/EUA/Japão (que foram convertidos em 0/1/2) o modelo poderá se confundir ao achar que as datas representam algum tipo de ordem: 0 < 1 < 2 e atribuir um peso maior ao Japão por exemplo.

Sendo assim fica claro que, se precisarmos converter variáveis sem que haja qualquer relação de ordem, devemos evitar utilizar o Label Encoder. Podemos implementar o LabelEncoder (presente no pacote Scikitlearn) em python:

# importar pacotes
from sklearn.preprocessing import LabelEncoder

# instanciar encoder
le = LabelEncoder()

# 'treinar' encoder
le.fit(y_train)

# realizar a transformação
y_train = le.transform(y_train)

# visualizar classes encontradas
le.classes_

# recuperar os labels originals
le.inverse_transform(y_train)

One-hot Encoder

Como dissemos, dependendo da situação, podemos confundir o modelo ao utilizar o Label Encoder, tornando-a uma solução inviável. Para evitar isso, podemos utilizar o One-hot Encoder.

De maneira simples, o One-hot Encoder pega as categorias de uma coluna e as divide em várias colunas, cada uma representando uma categoria, essas colunas são preenchidas com valor 0 ou 1 - dependendo da categoria original. Tomemos nosso exemplo anterior dos países, se utilizarmos o One-hot Encoder teremos um resultado semelhante ao ilustrado abaixo:

Também podemos implementar o OneHotEncoder (presente no pacote Scikitlearn) em python:

# importar pacotes
from sklearn.preprocessing import OneHotEncoder

# instanciar encoder
le = OneHotEncoder()

# 'treinar' encoder
le.fit(X_train)

# criar dataframe
X_train_enc = le.transform(X_train)

A desvantagem desse método comparado ao anterior é que, se tivermos muitas categorias para uma variável, iremos produzir muitas colunas adicionais e dependendo do modelo que estamos utilizando, podemos introduzir outros problemas de desempenho.

Conclusão

O intuito desse artigo foi trazer um pouco sobre as diferenças das duas principais formas de conversão de variáveis categóricas para modelos de Machine Learning - Label Encoder e One-hot Encoder.

Em resumo, vimos que o Label Encoder é uma excelente ferramenta para converter variáveis categóricas que possuem alguma relação de ordem, no entanto não é indicado para variáveis que não possuem tal relação devido a possibilidade de introduzir problemas no modelo.

Já o One-hot Encoder é ideal para os casos em que o Label Encoder não é indicado, no entanto, dependendo do número de categorias, o One-hot Encoder pode introduzir outro tipo de problema no modelo.

A escolha do método de codificação dependerá do problema que está sendo analisado.

Referências

Choosing the right Encoding method-Label vs OneHot Encoder

how can your choice of encoding play a major role in your prediction model

Towards Data ScienceRahil Shaikh

Label Encoder vs. One Hot Encoder in Machine Learning

Originally published here: http://blog.contactsunny.com/data-science/label-encoder-vs-one-hot-encoder-in-machine-learning

MediumSunny Srinidhi

Neste projeto, iremos abordar o problema das fraudes em cartões de crédito, uma das principais preocupações das instituições financeiras como bancos e fintechs. Em 2020, segundo o Mapa da Fraude, foram registradas 3,5 milhões de transações potencialmente fraudulentas, cerca de 403 tentativas de fraude por hora - nos segmentos de e-commerce, mercado financeiro, vendas diretas e telecomunicações - , isso representou R$ 3,6 bilhões em tentativas de fraude em 2020. (ClearSale, 2021).

Dentre essas fraudes, aquelas envolvendo cartões de crédito são de grande relevância uma vez que a sua não-detecção acarretará em prejuízos consideráveis, tanto para o consumidor quanto para a instituição financeira.

Um outro fator a ser considerado é a quantidade de falsos positivos, ou seja, aquelas vezes em que você tentou fazer uma compra e teve seu cartão bloqueado preventivamente - o que provavelmente gerou estresse e constrangimento.

Ainda que seja desejável reduzir a quantidade de falsos positivos, é preferível (tanto para instituição financeira quanto para o consumidor) que hajam mais falsos positivos do que falsos negativos.

Por todos esses motivos, o investimento na área de detecção de fraudes por meio de Inteligência Artificial vem crescendo a cada ano, representando uma grande oportunidade em Data Science.

Dispondo de grandes volumes de dados como base histórica, um algoritmo de machine learning apenas um pouco melhor que os anteriores já representa uma economia de milhões de Reais. E esse é o desafio, aprimorar cada vez mais o uso de algoritmos visando inibir ou evitar transações fraudulentas.

Sobre os dados

Os dados que usaremos neste projeto foram disponibilizados por algumas empresas europeias de cartão de crédito. O dataset representa as operações financeiras que aconteceram no período de dois dias, onde foram classificadas 492 fraudes em meio a quase 290 mil transações.

Como você pode notar, este é um conjunto de dados extremamente desbalanceado, onde as fraudes representam apenas 0,17% do total.

Outro detalhe interessante é que as features são todas numéricas, e foram descaracterizadas (por problemas ligados à privacidade e segurança). Assim, os nomes das colunas são representados por [V1,V2,V3…,V28]

Na página original dos dados, também é informado que as variáveis passaram por uma transformação conhecida como Análise de Componentes Principais (Principal Component Analysis - PCA).

PCA

A PCA permite a redução da dimensionalidade enquanto mantém o maior número possível de informações. Para conseguir isso, o algoritmo encontra um conjunto novo de recursos - os chamados componentes.

Esses componentes são em número menor ou igual às variáveis originais. No caso deste projeto, os componentes achados pela transformação da PCA são as próprias colunas [V1,V2,V3…,V28].

Objetivos

O objetivo desse projeto é comparar dois modelos de Machine Learning treinados em diferentes condições - com dados desbalanceados, balanceados  com over-sampling e balanceados com under-sampling.

Também iremos realizar o comparativo de desempenho de dois dos algoritmos de classificação mais comuns em Machine Learning: Regressão Logística e Árvores de Decisão. Ao todo treinaremos 6 modelos para, ao final do estudo identificarmos qual algoritmo apresentou os melhores resultados nesse cenário.

Não aprofundaremos em todos os conceitos e técnicas utilizadas, se quiser saber mais sobre todo o processo de análise, confira  a análise completa no link abaixo:

fraud-detection/Projeto_Detecção_de_Fraude_em_Cartões_de_Crédito.ipynb at main · virb30/fraud-detection

Contribute to virb30/fraud-detection development by creating an account on GitHub.

GitHubvirb30

Conhecendo os dados

A primeira etapa do projeto consiste em realizar uma análise exploratória para conhecer os dados que estamos trabalhando e podermos definir as estratégias que utilizaremos, dessa análise conseguimos extrair alguns insights que guiarão os processos seguintes:

• As variáveis Time e Amount possuem seus valores originais, isso nos indica que será necessário ajustar a escala desses atributos para que não impacte no nosso modelo;
• Por causa do processo de PCA, evidenciado pela presença das variáveis (V1-V28), não temos mais detalhes sobre o que cada variável significa e nem como elas influenciam na classificação (em fraude ou legítima);
• Também vemos que não há nenhum registro com dados ausentes, nos poupando uma etapa de tratamento.

Separando os conjuntos

Antes de fazermos qualquer tratamento nos dados, é interessante dividir o conjunto em dois subconjuntos: treino e teste. Uma recomendação geral é que o modelo só tenha conhecimento dos dados de teste após treinado e validado, com isso, além de conseguirmos simular uma situação real onde o modelo deverá ser capaz de classificar dados novos/desconhecidos, evitamos que o modelo seja "viciado" e funcione apenas para os dados nos quais foi treinado.

Analisando nossos dados

O gráfico, Figura 1, deixa claro o desbalanceamento do dataset, com apenas 0,17% do total de registros sendo classificados como fraude.

Portanto será necessário balancearmos os dados antes de treinar nosso modelo de classificação.

Preparação dos dados

De modo a conseguirmos comparar o desempenho dos modelos que utilizam o mesmo algoritmo, utilizaremos duas técnicas de balanceamento nos dados de treino:

• over-sampling: nessa técnica, os dados da classe minoritária (no caso, fraudes) são replicados até que atinjam a mesma quantidade  da classe majoritária, por exemplo se temos 50 registros da classe 1 e 10 da classe 2 ao final do balanceamento teremos 50 registros de cada classe;
• under-sampling: essa técnica é o processo oposto da técnica anterior, ou seja, exemplos da classe majoritária são removidos, aleatoriamente, até que ambas fiquem com a mesma quantidade, se utilizarmos as mesmas condições do exemplo anterior - 50 registros da classe 1 e 10 da classe 2 - ao final do balanceamento teremos 10 registros de cada classe.

Dividir entre treino e validação

Antes de realizarmos qualquer tratamento nos dados, é interessante dividirmos nosso subconjunto (lembram-se que já fizemos uma divisão no início da análise?) em dois novos: treino e validação. Os novos conjuntos ficaram com os seguintes tamanhos:

• Treino: 181564
• Validação: 60522
• Teste: 42721

Padronizar dados

Como vimos anteriormente, as variáveis Time e Amount estão em escala diferente das demais e isso pode prejudicar o treinamento do nosso modelo, portanto precisaremos padronizá-las. Como a variável Amount possui outliers utilizaremos a classe StandardScaler disponível no pacote scikitlearn.

Nesse momento a padronização deverá ser realizada somente no dataset de treino.

A classe StandardScaler além de transformar as variáveis, também armazenará os estados da transformação, dessa maneira, quando formos validar e testar o modelo, o novo conjunto de dados passará pela mesma transformação, utilizando os mesmos valores que foram "treinados" pelo conjunto de treino, evitando assim potenciais "vícios".

Balanceamento dos dados

Agora que nossos dados de treino estão padronizados, e conforme citado anteriormente, iremos balancear os dados de duas maneiras: under-sampling e over-sampling ao final do processo teremos dois conjuntos de dados da seguinte maneira:

• under-sampling: 313 registros de cada classe
• over-sampling: 181251 registros de cada classe

Podemos ver nos gráficos da Figura 2 que agora nossos dados estão balanceados e podemos prosseguir para o treinamento do modelo.

Modelo de Machine Learning

Com os dados balanceados podemos seguir com a construção dos nossos modelos. Como estamos lidando com um problema de classificação binária (ou seja o alvo pode assumir apenas 2 valores - 0 ou 1) e conforme citamos no início desse artigo, iremos realizar um comparativo entre dois modelos: regressão logística e árvores de decisão.

Ambos os modelos serão treinados da seguinte maneira: 1) utilizando os dados originais, 2) com dados balanceados com under-sampling e 3) com dados balanceados com over-sampling.

Em seguida iremos comparar o desempenho dos modelos treinados com mesmo algoritmo mas com balanceamentos diferentes e, por fim, realizaremos a comparação de qual dos 6 modelos apresentou melhores resultados.

Modelo de Regressão Logística

O modelo de regressão logística utiliza a função sigmoide e mapeia os valores de saída no intervalo [0, 1], sendo, portanto, o mais utilizado em problemas de classificação binária, como: detecção de spam, tumor maligno/benigno, fraudes etc.

Modelo de Árvore de Decisão

O algoritmo de Árvore de Decisão é mais intuitivo para humanos, uma vez que faz a avalia propriedades e, com base em critérios calculados durante o treino, toma sucessivas decisões sobre qual caminho seguir (direita ou esquerda) até que não haja mais decisões a tomar. Para ficar mais claro a Figura 3 mostra parte de uma árvore de decisão.

Avaliando o modelos

Para avaliar nossos modelos, utilizaremos, com métrica de avaliação, os indicadores: precision, recall e f1-score.

precision nos informa a quantidade proporcional de identificações positivas feitas corretamente, ou seja, dentre as previsões marcadas como positivo, qual foi o percentual de acerto do algoritmo, podemos resumir precision com a equação:

recall nos diz a proporção de positivos encontrados corretamente, ou seja, dos dados reais positivos, qual proporção deles foi realmente marcado como positivo, e é dado pela equação:

O F1-score é a média harmônica entre precision e recalle nos dá uma boa ideia do desempenho do nosso algoritmo. É obtido pela equação:

Onde:

• TP = true positive (previsões positivas corretas)
• FP = false positive (previsões positivas incorretas)
• FN = false negative (previsões negativas incorretas)
• TN = true negative (previsões negativas corretas)

Outra métrica interessante, e que utiliza-se dos conceitos acima abordados é a AUC ROC, que podem ser definidas como:

• ROC ou Receiver Operation Characteristic traça uma curva baseada nas taxas de verdadeiro positivo e falso positivo.
• AUC ou Area Under the Curve é uma métrica que traduz a curva ROC em um número através do cálculo, como o nome sugere, da área sob a curva ROC.

Utilizaremos como métrica para nossa comparação, principalmente os índices AUC ROC e recall.

Avaliando o modelo de regressão

Para os cenários de treino propostos obtivemos os seguintes resultados para o modelo de Regressão Logística, a Figura 4 mostra, de forma visual, esses resultados:

Dataset Original

• Acurácia global: 99,93%
• Recall: 69,52%
• AUC ROC: 84,75%

O recall nos diz que apenas 69,52% das previsões de fraude foram feitas corretamente, o que significa uma taxa de aproximadamente 31% de falsos positivos, aliado à acurácia global de 99,93% temos um forte indício de que esse modelo está com overfitting.

Under-sampling

• Acurácia global: 96,86%
• Recall: 91,43%
• AUC ROC: 94,15%

Quando utilizamos dados balanceados com under-sampling notamos uma melhora no recall, ou seja, 91,43% das previsões de fraude foram corretas - isso provoca uma redução no número de falsos positivos.

Over-sampling

• Acurácia global: 97,71%
• Recall: 89,52%
• AUC ROC: 93,62%

O modelo de regressão treinado com o dataset balanceado em over-sampling apresentou resultados semelhantes aos anteriores. porém ligeiramente piores.

Notamos, portanto, que, para esse dataset, o modelo de regressão tem melhor desempenho com menos dados e dados reais (não fabricados).

Avaliando o modelo de Árvore

Para facilitar a comparação apresentaremos os resultados da mesma maneira que fizemos para o modelo de regressão e a Figura 5 contém a representação gráfica dos resultados:

Dataset Original

• Acurácia global: 99,92%
• Recall: 80,95%
• AUC ROC: 90,45%

Esses resultados revelam que, para dados desbalanceados, o modelo de árvore de decisão é melhor que o modelo de regressão - recall de 80,95%, em contrapartida, a acurácia global de quase 100% é um forte indício de overfitting.

Under-sampling

• Acurácia global: 87,15%
• Recall: 90,48%
• AUC ROC: 88,81%

Apesar de ter apresentado menor índice AUC ROC, o modelo de árvore de decisão treinado com apresentou melhores resultados de recall.

Over-sampling

• Acurácia global: 99,91%
• Recall: 77,14%
• AUC ROC: 88,54%

Já o modelo de árvore de decisão treinado com dados balanceados em Over-sampling apresentou resultados piores até que quando treinado com dados desbalanceados.

Esses resultados nos mostram que o modelo de árvore de decisão é menos eficiente quando o volume de dados é maior, também nos mostra que esse modelo é menos suscetível a dados desbalanceados se comparado com o modelo de regressão.

Conclusão

Nessa análise comparamos o desempenho de dois modelos de classificação baseados em algoritmos diferentes - Regressão Logística e Árvore de Decisão - aplicados ao problema de detecção de fraudes em transações de cartão de crédito utilizando um mesmo conjunto de dados.

Consideramos principalmente as métricas recall e AUC ROC para nosso comparativo, uma vez que são esses indicadores que melhor representam a taxa de acerto (fraudes detectadas corretamente), os resultados foram resumidos e podem ser vistos na Tabela 1.

A tabela acima nos revela características importantes com relação ao nosso cenário (problema e dados):

1. O algoritmo de regressão logística apresentou melhor desempenho com o dataset balanceado através da técnica de under-sampling (com um menor volume de amostras).
2. O algoritmo de árvore de decisão apresentou melhor desempenho em relação a taxa de acertos de transações fraudulentas (recall), quando treinado utilizando um dataset balanceados com under-sampling (menor volume de amostras).
3. O modelo de árvore de decisão apresentou melhor desempenho - comparado ao de regressão - quando os dados estavam desbalanceados, mostrando mais robustez desse algoritmo em situações semelhantes.

No cenário de detecção de fraudes em cartão de crédito esperamos obter: menor número de falsos positivos (melhor experiência do cliente) e menor número de falsos negativos (mais segurança tanto para a instituição quanto para o cliente), logo, o modelo recomendado para esse cenário é o de Regressão Logística treinado com o dataset balanceado com under-sampling.

Essa análise também nos mostrou que, apenas com a realização do tratamento adequado nos dados é possível melhorar o desempenho de modelos de Machine Learning, dispensando a necessidade de desenvolver um novo algoritmo ou realizar ajustes finos para atingir resultados satisfatórios. No entanto com um bom tunning nos parâmetros, aliado a um bom conjunto de dados é possível obtermos modelos cada vez melhores e mais precisos.

COVID-19 é uma doença infecciosa causada por uma variante recém-descoberta do coronavírus, denominado Sars-Cov-2.

Transmitido principalmente por meio de gotículas provenientes de tosses ou espirros de pessoas infectadas, a gravidade dos sintomas varia muito de pessoa para pessoa.

Fato é, não se sabe muita coisa a respeito do COVID-19. Estudos estão sendo realizados no mundo todo, porém os resultados ainda não são conclusivos e definitivos.

Até o presente momento, observa-se que cerca de 80% dos casos confirmados são assintomáticos e rápidos. A maioria das pessoas que se encaixam nesse grupo, se recupera sem nenhuma sequela.

No entanto, 15% das pessoas terão infecções graves e precisarão de oxigênio. O restante das pessoas, que representam 5%, serão classificadas como infecções muito graves e precisarão de ventilação assistida, por meio de respiradores mecânicos em ambiente hospitalar.

Esse risco é ainda maior em se tratando da população idosa. Idosos, naturalmente, são mais suscetíveis a doenças infectocontagiosas, uma vez que o sistema imunológico enfraquece com a idade, favorecendo a manifestação de casos mais graves nessa população.

Pandemia

Após mais de 1 ano de decretada pandemia de COVID-19, em março de 2020, além das medidas recomendadas pela OMS - distanciamento social, higienização das mãos e uso de máscara - a esperança se concentra na vacinação em massa da população para que a vida volte ao normal.

Objetivos

O objetivo dessa análise é obter um panorama da pandemia de COVID-19, no Brasil e no mundo, utilizando os dados públicos da doença disponibilizados pelo Our World In Data (OWID) - um projeto da Global Change Data Lab, uma organização sem fins lucrativos baseada no Reino Unido.

Objetivos específicos

Esperamos obter respostas aos seguintes questionamentos:

• Como se deu a evolução da pandemia no Brasil e no mundo?
• Houve redução no número de novas mortes com o avanço da vacinação?
• Quando foi registrada a primeira morte no Brasil?
• Quantos dias demorou para registrarmos a primeira morte, considerando o primeiro caso de COVID-19 registrado no país?
• Como se deu a evolução de casos da doença no país?

Evolução do COVID-19

Toda nossa análise considerará como data limite: 16 de agosto de 2021, podemos perceber um crescimento exponencial na quantidade de casos de COVID-19 no mundo conforme mostra a figura 1:

Se detalharmos melhor como fica a distribuição de casos e mortes por continente vemos que o continente Asiático é o que possui maior número de casos, Figura 2, no entanto, o continente Europeu é o que possui maior número de mortes, Figura 3.

Como o COVID-19 é uma doença infectocontagiosa e que se manifesta de maneira mais grave na população idosa, nossa hipótese inicial é que o continente Europeu possui mais habitantes nessa condição, Figura 4, justificando a presença do continente nessa posição.

Apesar de impreciso (pois utilizamos a média da população idosa dos países que compõem o continente) podemos ver que há uma disparidade entre o percentual da população Idosa no continente Europeu em relação aos demais continentes, essa característica é um forte indício que confirma nossa hipótese que justifica o maior número de mortes nesse continente.

Países com maior número de casos e mortes no mundo

Agora que temos uma ideia geral da pandemia no mundo, montamos um ranking com os 5 países que mais registraram casos e mortes, nossa lista é composta de: nome do país, total de casos/mortes e percentual de casos/mortes em relação a população total

Em total de casos

1. Estados Unidos - 36.888.952 - 11,15% da população total
2. Índia - 32.250.679 - 2,34%
3. Brasil - 20.378.570 - 9,59%
4. França - 6.556.496 - 9,70%
5. Rússia - 6.531.585 - 4,48%

Em total de mortes

1. Estados Unidos - 622.321 - 0,19% da população total
2. Brasil - 569.492 - 0,27%
3. Índia - 432.079 - 0,03%
4. México - 248.652 - 0,19%
5. Peru - 197.393 - 0,60%

Notamos que o Brasil figura entre os 3 países com maior número absoluto de casos confirmados(20.378.570 - 9,59% da população), atrás apenas de Estados Unidos(36.888.952 - 11,15% da população) e Índia(32.250.679 - 2,34% da população).

Em se tratando do número absoluto de mortes, o Brasil encontra-se em segundo lugar (569.492 - 0,27% da população total), atrás apenas dos Estados Unidos (622.321 - 0,19% da população total) e seguido da Índia (432.079 - 0,03% da população total).

Os impactos da vacinação

As vacinas para COVID-19 são efetivas e uma ferramenta importante para controle da pandemia. No entanto, nenhuma vacina é 100% eficaz para prevenir pessoas de contrairem a doença, existe uma pequena porcentagem de pessoas totalmente vacinadas que ainda ficam doentes (OPAS, 2021).

Portanto o objetivo central da vacinação em massa é a redução no número de casos graves e óbitos e, consequentemente, o controle da pandemia.

Na Figura 5,  podemos perceber como o avanço da vacinação impactou no número de novos casos e novas mortes no mundo. Consideraremos o número absoluto de pessoas vacinadas (com 1 ou todas as doses previstas).

Vale lembrar que cada país tem seu ritmo de vacinação e disponibilidade de vacinas, ou seja, o cenário mundial pode não se repetir quando analisamos os países isoladamente.

Vemos acima que o avanço da vacinação pode ter contribuído para a redução do número de novas mortes ao longo tempo, no entanto, quando comparamos com o número de novos casos, Figura 6,  não temos o mesmo resultado:

Notamos pelo gráfico acima uma oscilação na quantidade de novos casos com picos e vales cada 2 meses aproximadamente. Esse comportamento se repete, independente do avanço da vacinação. No entanto, a partir de Janeiro de 2021 a tendência de novos casos está praticamente constante.

Diversos fatores podem contribuir para esse cenário, por exemplo, adoção de medidas mais restritivas, ou o aumento da confiança da população já vacinada podem ter consequências no aparecimento de novos casos.

O Cenário na América do Sul

A Figura 7, mostra como o total de novos casos e novas mortes estão distribuídos entre os países da América do Sul.

Esses dados nos revelam que o Brasil possui mais casos e mortes por COVID-19 do que todos os países da América do Sul juntos. Num primeiro momento esses números assustam quando vistos isoladamente. No entanto vale destacar que a população total do país representa quase 50% da população total do continente.

Portanto, quando utilizamos a população do país em relação a população do continente como referência, vemos que os números de casos/mortes por COVID-19, ainda que elevados, são proporcionais à representatividade populacional do Brasil na América do Sul.

A COVID-19 no Brasil

O primeiro caso de COVID-19 registrado no Brasil foi em 26/02/2020, já a primeira morte em 17/03/2020, 20 dias após o primeiro caso, nesta data o país contabilizava 321 casos confirmados.

Podemos ver pela Figura 8, como a evolução de casos e mortes ocorreu no país, notamos uma grande diferença entre o número absoluto de casos e mortes. Isso evidencia a proporção entre casos leves e fatais da doença.

Ajustando a escala do gráfico, Figura 9, é possível visualizar melhor a evolução dos números de casos e mortes ao longo do tempo. Ainda que haja uma diferença significativa entre total de casos e mortes, percebemos que a evolução desses dois indicadores deu-se de maneira similar.

Esse comportamento é esperado uma vez que o número total de mortes está diretamente relacionado com o número total de casos.

Os impactos da Vacinação

Percebemos que o Brasil possui números expressivos no total de casos e mortes por COVID-19. Mas será que o avanço da vacinação no país tem contribuído para a melhora desse cenário? A Figura 10 mostra como foi a evolução de novos casos no país com relação à vacinação. Lembrando que o início da vacinação no Brasil se deu em 17/01/2021.

Podemos perceber algumas características interessantes sobre a vacinação no país e que merecem destaque:

Notamos momentos sem dados, provavelmente causados pelas pausas por falta de vacina ou períodos em que não houve registro.

Também percebemos uma redução expressiva no número de novas mortes à medida que a vacinação avança, demonstrando a eficácia da vacinação em massa contra a pandemia.

Diferente do que ocorre em âmbito mundial, notamos uma tendência de queda no número de novos casos no cenário nacional, Figura 11, porém vale destacar que a proporção dos testes pode não refletir o cenário real.

Temos visto também que alguns dias não há divulgação de novos casos ainda que eles existam, essa situação pode ser vista no gráfico através dos períodos em que não há registro de novos casos.

Mas, no geral, podemos ver que a vacinação tem impactado diretamente o número de novos casos, contribuindo para sua diminuição ao longo do tempo.

Conclusão

Fizemos uma análise superficial dos dados relativos à Pandemia de COVID-19 e disponibilizados pela Our World In Data de modo a obter um panorama da doença no Brasil e no Mundo e, principalmente, quais os impactos da vacinação no controle da pandemia.

No cenário mundial, notamos uma melhora na quantidade de novas mortes, principalmente à medida que a vacinação avança, no entanto, o mesmo não se repete quando o assunto são novos casos, para esses notamos que há uma certa estabilidade, ou seja, nem melhor, nem pior.

Esses dados nos revelam ainda que o Brasil é um dos países que mais apresenta casos e mortes por COVID-19 no mundo, no entanto, diferente do cenário mundial, notamos sinais de redução no número de casos e mortes com o avanço da vacinação, mostrando que essa têm sido uma medida eficaz no controle da pandemia no país.

Existem muitos fatores envolvidos que podem influenciar a coleta e distribuição de dados referentes à pandemia, portanto as análises aqui realizadas não refletem a realidade em sua totalidade.

A análise completa você confere aqui:

analise-covid/Projeto_Panorama_do_COVID_19_no_Brasil.ipynb at main · virb30/analise-covid

Contribute to virb30/analise-covid development by creating an account on GitHub.

GitHubvirb30

O Airbnb já é considerado como sendo a maior empresa hoteleira da atualidade. Ah, o detalhe é que ele não possui nenhum hotel!

Conectando pessoas que querem viajar (e se hospedar) com anfitriões que querem alugar seus imóveis de maneira prática, o Airbnb fornece uma plataforma inovadora para tornar essa hospedagem alternativa.

No final de 2018, a Startup fundada em 2008, já havia hospedado mais de 300 milhões de pessoas ao redor de todo o mundo, desafiando as redes hoteleiras tradicionais.

Uma das iniciativas do Airbnb é disponibilizar dados do site, para algumas das principais cidades do mundo. Por meio do portal Inside Airbnb, é possível baixar uma grande quantidade de dados para desenvolver projetos e soluções de Data Science.

Destino: Lisboa

O turismo em Portugal está na moda, e nada melhor do que começar um passeio pelo país pela sua capital, Lisboa.

O clima em Lisboa é agradável o ano todo, mas as melhores épocas para visitá-la são na primavera e no outono, quando as temperaturas são amenas e não costuma chover. Os meses de verão podem ser bem quentes, principalmente em agosto, período de férias escolares na Europa, quando alguns estabelecimentos podem permanecer fechados. O inverno costuma ser chuvoso e raramente atinge temperaturas abaixo de 0^oC.

Esse cenário climático faz com que as Praias tornem-se a atração preferida dos turistas. Além disso os pontos históricos, a gastronomia e os jardins são passeios que valem a pena.

Com tantas opções de passeio o deslocamento também é um aspecto a ser considerado. Felizmente circular por Lisboa é muito fácil e agradável, partindo do centro da cidade, boa parte das atrações pode ser alcançada a pé, os passeios mais distantes podem ser alcançados utilizando os Metros, eléctricos (bondes) e autocarros (ônibus), que são opções acessíveis, além dos tradicionais: Táxi, Uber e afins.

Com todas essas facilidades, onde se hospedar passa a ser uma questão de escolher como curtir a cidade e não uma busca estratégica visando o itinerário.

A Grande Lisboa - semelhante ao que ocorre com a Grande São Paulo no Brasil - é composta de vários municípios: Alenquer, Amadora, Arruda dos Vinhos, Azambuja, Cadaval, Cascais, Lisboa, Loures, Lourinhã, Mafra, Odivelas, Oeiras, Sintra, Sobral de Monte Agraço, Torres Vedras e Vila Franca de Xira.

Airbnb em Portugal

Em Portugal, para um anfitrião anunciar um imóvel do tipo Alojamento Local (casas, apartamentos ou alojamentos) para aluguéis de curta duração é necessário que seja feito um registro no Portal Cidadão. Esse registro deve ser feito para todos os anúncios do Airbnb em Portugal. Essa regulamentação não determina os números mínimo e máximo de noites para aluguel.

Obtenção dos Dados

Os dados estão disponíveis no site Inside Airbnb.

Para essa análise utilizamos o arquivo listings.csv que contém informações resumidas e métricas para a cidade de Lisboa.

Esse conjunto é composto (no momento da análise) de 19458 registros com 16 atributos (variáveis). A versão completa desse dataset também está disponível no portal e conta com 106 variáveis para análise.

Objetivos

O objetivo da nossa análise é identificar alguns padrões sobre o aluguel de imóveis do Airbnb em Lisboa. Analisaremos, principalmente os locais  com maior oferta, a média de preço e qual a média do mínimo de noites para aluguel na cidade.

Análise dos Dados

Nessa etapa iremos entender como os dados estão estruturados e quais características nos chamam mais atenção.

Segundo sua documentação as variáveis estão divididas da seguinte maneira:

Dicionário das variáveis

• id - identificador único do airbnb
• name - descrição do imóvel
• host_id - código do proprietário (anfitrião) do imóvel
• host_name - nome do anfitrião
• neighbourhood_group - grupo do bairro
• neighbourhood - nome do bairro
• latitude - latitude do imóvel
• longitude - longitude do imóvel
• room_type - tipo de quarto
• price - preço da diária em moeda local (no caso, euros)
• minimum_nights - número mínimo de noites
• number_of_reviews - quantidade de reviews
• last_review - data da última review
• reviews_per_month - média de reviews por mês
• calculated_host_listings_count - quantidade de imóveis do host na mesma região
• availability_365 - quantidade de dias disponíveis nos próximos 365 dias.

Verificando os valores únicos da variável neighbourhood_group (grupo do bairro) percebemos que eles representam os 16 munícipios da Grande Lisboa.

Análise exploratória

Antes de iniciar a análise é importante sabermos como está a qualidade dos nossos dados, para isso, verificamos algumas informações sobre o dataset, tais como tipos das variáveis, quantidade de valores ausentes e como as variáveis estão distribuídas.

Utilizando esses critérios, alguns pontos nos chamam a atenção:

• 18% do dataset não possui informação nos campos de review (reviews_per_month e last_review);
• A variável host_name possui pouco mais de 0,1% de valores ausentes e
• A variável name possui 0,05% de valores ausentes.

Nesse aspecto temos um conjunto de dados bom uma vez que as variáveis de review não são relevantes para nossa análise. No entanto ao verificar a distribuição das variáveis, notamos a presença de outliers - valores que destoam - que podem prejudicar nossa análise.

Pelo resumo acima vemos que:

• a variável price possui 75% dos valores abaixo de €110,00, porém seu valor máximo é € 20628,00.
• notamos também a presença de valores zerados, em se tratando de aluguéis, não faz sentido que existam aluguéis gratuitos, portanto, também consideramos esses valores como outliers.
• a variável minimum_nights (mínimo de noites) possui valores acima de 365 dias.

Portanto, antes de continuarmos, faz-se necessário realizar uma limpeza nos dados, visando, principalmente eliminar (ou reduzir) esses outliers.

Limpeza dos Dados

Para remover outliers de um dataset, podemos excluir os registros ou alterar os valores seguindo algum critério. A escolha da estratégia depende de diversos fatores, tais como natureza da variável escolhida, objetivo do projeto, conjunto de dados analisado, etc.

Primeiro delimitamos os valores de corte dos outliers: 200 para price e 6 para minimum_nights, ou seja, iremos excluir todos os registros que possuam preço acima de € 200,00 e mínimo de noites acima de 6. Também iremos remover os registros com price = 0. O cálculo realizado para determinar os valores de corte pode ser visto na análise.

Esses registros representam, respectivamente 8% e 6,5% do conjunto de dados. Nosso dataset limpo ficou com 16751 registros, uma redução de pouco mais de 13%. Devido à quantidade de dados disponíveis, acreditamos que esse é um número aceitável e não causará grandes prejuízos à análise.

Verificamos alguns pontos que merecem destaque:

• A mediana de price quase não foi afetada pela limpeza, isso significa que nossa limpeza não provocou grandes distorções nos preços;
• A média e o desvio padrão de price foram reduzidos consideravelmente enfatizando a sensibilidade dessa variável a outliers e;
• Agora não temos dados que não fazem sentido (por exemplo price = 0 e minimum_nights > 365).

Continuando a análise

Com os dados limpos podemos prosseguir com nossa análise respondendo à questão mais importante para quem deseja visitar Lisboa.

Qual a média de preços do aluguel?

Segundo a documentação do dataset todos os dados referentes a preço são dados em moeda local, portanto, a média de preço dos aluguéis em Lisboa é de

€ 77,00

Qual o tipo de imóvel mais alugado no Airbnb?

Em nosso dataset a variável room_type indica qual o tipo do imóvel que está anunciado no Airbnb. As opções disponíveis são:  Entire home/apt (apartamentos/casas inteiras), Hotel room (quarto de hotel), Shared Room (quarto compartilhado) ou Private room (aluguel de um quarto).

Vemos que em Lisboa a preferência de aluguel é para apartamentos/casas inteiras, e representa 63% do conjunto de dados.

Qual é a média do mínimo de noites para aluguel?

2 noites

A média do mínimo de noites em um imóvel é de aproximadamente 2 noites, o que indica que as pessoas costumam ficar em um imóvel em Lisboa o período equivalente ao final de semana.

Qual a localidade mais cara do dataset?

Vamos dividir essa pergunta em 2 partes. Primeiro vamos ver qual a cidade mais cara da Grande Lisboa, em seguida vamos analisar quais os bairros mais caros da capital Lisboa (cidade mais populosa de Portugal).

Pelo gráfico acima vemos que Arruda Dos Vinhos é a cidade com maior média de preço, no entanto, se analisarmos a quantidade de imóveis por cidade, vemos que nosso dataset possui apenas 5 imóveis nesse município, o que, consequentemente, eleva sua média. Portanto consideramos Mafra como o munícipio como localidade mais cara.

Ainda dentro dessa análise, vemos que Lisboa é a cidade que possui maior número de imóveis cadastrados. Vamos ver também qual é o bairro mais caro da cidade de Lisboa.

Pelo gráfico acima vemos que o Parque das Nações é o bairro com maior média de preço, segundo a Imobiliária Engel & Völkers “[O Parque das Nações] é atualmente um dos mais procurados para arrendamento, apresentando um preço por metro quadrado em torno dos 4.300 euros", isso, aliado à uma oferta relativamente baixa (193 imóveis no nosso dataset) pode ter contribuído com a média dos preços mais elevada nessa localidade.

Mapa de calor

Vamos visualizar melhor a distribuição dos preços dos imóveis na Grande Lisboa através do mapa de calor:

Para efeitos comparativos, vamos confrontar o mapa de calor acima, com o mapa da Vimeca, empresa responsável pelo transporte em Lisboa.

Comparando os dois mapas, vemos que a grande predominância de imóveis se dá nas regiões litorânea (incluindo as banhadas pelo reio Tejo) e na região central de Lisboa.

Conclusão

Foi realizada uma análise genérica dos dados do Airbnb para a Grande Lisboa. O objetivo principal era ter uma visão geral sobre o conjunto de dados e gerar insights para análises mais aprofundadas. Vimos que esse dataset possui alguns outliers fazendo-se necessária uma limpeza antes de prosseguirmos com a análise.

Algumas localidades possuem poucos imóveis disponíveis, o que pode provocar distorções na média dos preços.

Os locais com maior oferta estão localizados nas regiões litorâneas (e banhadas pelo rio Tejo) e no centro de Lisboa. O tempo médio despendido pelos visitantes na cidade é de pouco mais de 2 dias.

Por fim vale ressaltar que esse dataset contém uma parcela dos dados disponíveis pelo Airbnb, sendo ideal para uma análise inicial. No entanto recomenda-se a utilização da versão completa desse dataset que possui 106 atributos para análise.

Confira a análise completa aqui.

‌‌

‌‌

Neste último post da série de visão computacional iremos construir um detector de objetos, em tempo real, utilizando nossos queridinhos: Python, OpenCV e, dessa vez, a YOLO pré-treinada no COCO Dataset.

You Only Look Once (YOLO) + Common Objects in Context (COCO) Dataset

A YOLO é o estado da arte dos sistemas de detecção de objetos em tempo real, extremamente rápida e precisa,

O COCO dataset é um conjunto de dados de ampla escala que contém a classificação de 80 tipos de objetos diferentes com mais de 330K imagens para realização da segmentação de objetos.

Combinados, formam uma poderosa ferramenta para detecção e classificação de objetos em tempo real. Deixo alguns links a seguir se desejar conhecer mais sobre a YOLO e o COCO Dataset.

O Projeto

Nesse projeto iremos utilizar algumas técnicas apresentadas nos artigos anteriores dessa série, por isso não entraremos em detalhes sobre elas e vamos nos concentrar na parte da detecção e identificação dos objetos.

Dessa vez iremos implementar CLI (Command Line Interface), em que o usuário pode informar, através do terminal, a câmera que será utilizada ou um arquivo de vídeo para ser analisado. As funcionalidades que iremos implementar são:

• Inicializar o streaming de vídeo - ou enviar um arquivo de vídeo para ser analisado - à escolha do usuário;
• Realizar pré-processamento da imagem para reduzir os ruídos e;
• Detectar os objetos que desejamos - no nosso caso optamos por detectar somente: pessoa(0), monitor(62), mouse(64), controle remoto(65) e teclado(66).

Preparando nossa aplicação

Primeiramente importaremos as bibliotecas necessárias e configuraremos as constantes necessárias para o correto funcionamento.

import numpy as np
import argparse
import os
from os.path import join, dirname
import cv2
import time
from imutils.video import VideoStream, FileVideoStream
from imutils.video import FPS

Além das bibliotecas que utilizaremos para a captura e processamento das imagens cv2, imutils e numpy, importamos também a biblioteca os para ler o sistema arquivos.

Como iremos construir um CLI, importamos também a biblioteca argparse permitindo que o usuário informe os parâmetros necessários via terminal.

Em seguida configuramos algumas constantes:

• Nível de confiança mínimo
• Non-maximum Suppression threshold - um limite para filtrar as "caixas" que destacarão os objetos detectados, evitando múltiplas detecções para um mesmo objeto.
• O diretório que contem nosso modelo treinado e os nomes das classes.

CONFIDENCE_MIN = 0.4
NMS_THRESHOLD = 0.2
MODEL_BASE_PATH = join(dirname(__file__), "yolo-coco")

Em seguida iremos definir algumas funções:

1. build_parser: essa função irá construir nosso parser, que possibilitará que nossa aplicação receba argumentos através do terminal:

def build_parser():
    parser = argparse.ArgumentParser()
    parser.add_argument("-i", "--input", required=True, help="Endereço do streaming, camera index ou caminho do arquivo")
    return parser

2. load_classes: essa função irá extrair os nomes das classes a partir do arquivo coco.names - retornará os labels e uma cor aleatória para cada label existente no arquivo:

    def load_classes():
    	with open(os.path.sep.join([MODEL_BASE_PATH, 'coco.names'])) as f:
            labels = f.read().strip().split('\n')

            # gerar cores para cada label
            np.random.seed(42)
            colors = np.random.randint(0, 255, size=(len(labels), 3), dtype='uint8')
            return labels, colors

3. load_model: irá carregar o modelo treinado no cv2:

def load_model():
    net = cv2.dnn.readNetFromDarknet(
        os.path.sep.join([MODEL_BASE_PATH, 'yolov3.cfg']),
        os.path.sep.join([MODEL_BASE_PATH, 'yolov3.weights']))

    return net

4. extract_layers: essa função irá extrair as camadas não conectadas da arquitetura YOLO

def extract_layers():
    ln = net.getLayerNames()
    ln = [ln[i[0] - 1] for i in net.getUnconnectedOutLayers()]
    return ln

5. start_streaming: responsável por instanciar e inicializar o streaming (ou carregar o arquivo) de vídeo:

def start_streaming(streaming_path):
    if os.path.isfile(streaming_path):
        vs = FileVideoStream(streaming_path)
    elif streaming_path.isnumeric:
        vs = VideoStream(int(streaming_path))
    else:
        vs = VideoStream(streaming_path)

    vs.start()
    return vs

Agora que nossas funções estão definidas vamos para o código principal, irei separar os blocos que dizem respeito à mesma funcionalidade e comentarei brevemente sobre cada parte no decorrer do artigo:

if __name__ == '__main__':
    parser = build_parser()
    streaming_path = vars(parser.parse_args())['input']

    print("[+] Carregando labels das classes treinadas...")
    labels, colors = load_classes()

    print("[+] Carregando o modelo YOLO treinado")
    net = load_model()

    ln = extract_layers()

    print("[+] Iniciando a recepção do streaming...")
    vs = start_streaming(streaming_path)
    time.sleep(1)
    fps = FPS().start()

Nessa primeira parte estamos fazendo o setup do nosso CLI:

• construir o parser,
• capturar a entrada do usuário,
• carregar as classes e cores,
• carregar o modelo,
• extrair as camadas desconectadas da arquitetura YOLO e;
• inicializar o streaming de vídeo.

    while True:
        frame = vs.read()

        # redimensionar os frames
        # frame = cv2.resize(frame, None, fx=0.2, fy=0.2)

        # capturar a largura e altura do frame
        (H, W) = frame.shape[:2]

        # construir um container blob e fazer uma passagem na YOLO
        blob = cv2.dnn.blobFromImage(frame, 1 / 255.0, (W, H), swapRB=True, crop=False)
        net.setInput(blob)
        layer_outputs = net.forward(ln)

        # criar listas com boxes, nível de confiança e ids das classes
        boxes = []
        confidences = []
        class_ids = []

Nosso loop infinito que irá capturar o frame do stream, construir o blob a partir do frame e passar pela YOLO. Iremos também criar as listas de boxes, níveis de confiança e ids das classes, mais adiante utilizaremos essas listas para exibir a localização, nível de confiança e classe dos objetos detectados.

        for output in layer_outputs:
            for detection in output:
                scores = detection[5:]
                class_id = np.argmax(scores)
                confidence = scores[class_id]

                # filtar pelo threshold da confiança
                # selecionar somente se for pessoa, monitor, teclado, mouse ou controle remoto
                # verificar  arquivo coco.name caso precise utilizar outras classes
                if confidence > CONFIDENCE_MIN and class_id in [0, 62, 64, 65, 66]:
                    box = detection[0:4] * np.array([W, H, W, H])
                    (center_x, center_y, width, height) = box.astype("int")

                    x = int(center_x - (width / 2))
                    y = int(center_y - (height / 2))

                    boxes.append([x, y, int(width), int(height)])
                    confidences.append(float(confidence))
                    class_ids.append(class_id)

Nesse trecho estamos percorrendo as saídas e detecções realizadas pela YOLO e filtrando-as tanto pelo nível de confiança mínimo (que definimos na etapa de preparação) quanto pelas classe que desejamos detectar.

Para as detecções que se enquadram nesses critérios, iremos adicionar as respectivas informações nas listas que criamos anteriormente:

• boxes - coordenadas da caixa que destaca cada objeto detectado;
• confidence - os níveis de confiança de cada objeto
• class_ids - as classes de cada um dos objetos detectados

# eliminar ruido e redundâncias aplicando non-maxima suppression
        new_ids = cv2.dnn.NMSBoxes(boxes, confidences, CONFIDENCE_MIN, NMS_THRESHOLD)
        if len(new_ids) > 0:
            for i in new_ids.flatten():
                (x, y) = (boxes[i][0], boxes[i][1])
                (w, h) = (boxes[i][2], boxes[i][3])

                # plotar retângulo e texto das classes detectadas no frame atual
                color_picked = [int(c) for c in colors[class_ids[i]]]
                cv2.rectangle(frame, (x, y), (x + w, y + h), color_picked, 2)
                text = "{}: {:.4f}".format(labels[class_ids[i]], confidences[i])
                cv2.putText(frame, text, (x, y - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.5, color_picked, 2)

Como a YOLO não aplica o Non-maximum Supression (NMS) para nós, iremos aplicá-lo para remover a sobreposição das "caixas" que detectam os objetos, mantendo apenas a detecção mais confiável.

Para cada uma dessas detecções (já com o filtro NMS aplicado) iremos extrair os pontos das caixas e plotar o retângulo - ao redor do objeto com o texto e o nível de confiança - no frame atual.

Em seguida vamos exibir o frame atualizado e aguardar o usuário pressionar a tecla de saída (esc):

        # exibir o frame atual
        cv2.imshow('Frame', frame)

        # sair caso seja pressionada a tecla ESC
        c = cv2.waitKey(1)
        if c == 27:
            break

        # atualiza o fps
        fps.update()

Por fim, eliminamos os processos e janelas:

  # eliminar processos e janelas
    fps.stop()
    cv2.destroyAllWindows()
    vs.stop()

Demonstração

Conclusão

Apesar de ser um projeto simples, como conseguimos extrair diversos objetos diferentes podemos imaginar diversas aplicações, tais como: em carros autônomos, detecção de invasão em espaços restritos, identificar utilização de objetos proibido em determinado local, entre outras.

Repositório do Projeto

virb30/realtime_object_detection

Realtime Object Detection with Python & OpenCV. Contribute to virb30/realtime_object_detection development by creating an account on GitHub.

GitHubvirb30

Referências

YOLO object detection with OpenCV - PyImageSearch

In this guide you will learn how to use the YOLO object detector to detect objects in images and video using OpenCV, Python, and Deep Learning.

PyImageSearchAdrian Rosebrock

Non-maximum Suppression (NMS)

A Technique to remove duplicates and false positives in object detection

Towards Data ScienceSambasivarao. K

YOLO: Real-Time Object Detection

You only look once (YOLO) is a state-of-the-art, real-time object detection system.

Joseph Redmon

COCO - Common Objects in Context

Common Objects in Context

Neste artigo iremos construir um detector de fadiga utilizando Python, OpenCV e a biblioteca de detecção de landmarks dlib. Esse projeto foi baseado neste artigo do mestre da visão computacional Adrian Rosebrock.

O que iremos utilizar?

Para esse projeto iremos utilizar Python e algumas bibliotecas, dentre elas: OpenCV, dlib e imutils. Utilizaremos alguns recursos adicionais, porém essas três bibliotecas são as principais para atingirmos nosso objetivo central: Detectar Fadiga.

OpenCV

Em nosso projeto o OpenCV será utilizado, principalmente, para realizar o pré-processamento das imagens que serão utilizadas para a detecção. Além disso, iremos utilizá-la para exibir as imagem (frames), aplicar o contorno aos pontos de interesse (em nosso caso, os olhos), adicionar texto sobre a imagem, etc.

Imutils

A biblioteca imutils irá nos auxiliar na captura do vídeo na forma de streaming, para que possamos realizar a detecção em tempo real.

Dlib

Será com a biblioteca dlib, em conjunto com um modelo pré-treinado de deep learning (presente na mesma) - e capaz de detectar 68 landmarks -, que iremos detectar as landmarks faciais.

Mas o que são landmarks faciais?

Em nosso contexto, as landmarks faciais são pontos de interesse ao longo de uma área, ou seja, o objetivo de um detector de landmarks faciais é identificar estruturas importantes de um rosto utilizando métodos previsão de formas (shape prediction). Detectar essas marcações, em geral utiliza dois processos:

1. Localizar a face na imagem
2. Detectar as estruturas faciais chave do objeto de interesse

A localização da face pode ser realizada de diversas maneiras com diversos algoritmos, mas, para que nossa detecção funcione, precisamos extrair dessa imagem a bounding box (uma espécie de caixa) que representa a face.

Com a área do rosto, podemos aplicar a segunda etapa: detectar as estruturas faciais chave. Existem diversos algoritmos para tais tarefas, mas em essência, a maioria tenta detectar e rotular as regiões:

• boca;
• nariz;
• sobrancelhas (direita e esquerda)
• olhos (direito e esquero);
• mandíbula;

Detectar Fadiga

Até agora conseguimos carregar o vídeo e detectar os pontos de interesse dos rostos nas imagens, mas como detectamos a fadiga?

Nesse projeto iremos considerar a proporção de abertura dos olhos, assim, se a proporção for menor que nosso limiar, temos a fadiga.

Como estamos utilizando a biblioteca dlib com o detector de 68 landmarks, temos, para cada olho, 6 pontos, conforme imagem abaixo:

Podemos calcular a proporção do aspecto do olho com a seguinte equação:

Com esse valor, conseguiremos identificar se há ou não sinais de fadiga na imagem/vídeo.

Juntando tudo

Combinaremos essas e outras bibliotecas para criar nosso detector de fadiga. Começaremos instalando e importando todas elas.

pip install opencv-python imutils playsound numpy

NOTA: para a instalação correta da dlib recomendo seguir esse tutorial.

# importar pacotes necessários
from os.path import join, dirname
from scipy.spatial import distance as dist
from imutils.video import VideoStream
from imutils import face_utils
from threading import Thread
import numpy as np
import playsound
import imutils
import time
import dlib
import cv2
import matplotlib.pyplot as plt
import os

1. Definiremos algumas constantes que serão utilizadas ao longo do algoritmo

# definir constantes
ALARM_SOUND = join(dirname(__file__), "buzina.wav") # local do arquivo do alarme
WEBCAM = os.environ.get('WEBCAM', 1) # indice da câmera que capturará o stream
EYE_THRESHOLD = 0.25 # limiar de "abertura" dos olhos
FRAMES_SEQ = 40 # quantidade de frames seguidos que o EAR médio deve permanecer abaixo do limiar antes de soar o alarme
COUNTER = 0 # contador
ALARM_TRIGGERED = False # indica se o alarme está tocando ou não
SHAPE_PREDICTOR = join(dirname(__file__), 'shape_predictor_68_face_landmarks.dat') # caminho do modelo pré-treinado

2. Carregar o modelo para a dlib e capturar os índices dos olhos do previsor

# carregar o dlib para detectar rostos
detector = dlib.get_frontal_face_detector()
predictor = dlib.shape_predictor(SHAPE_PREDICTOR)

# pegar os indices do previsor, para olhos esquero e direito
(lStart, lEnd) = face_utils.FACIAL_LANDMARKS_IDXS['left_eye']
(rStart, rEnd) = face_utils.FACIAL_LANDMARKS_IDXS['right_eye']

3. Capturar o vídeo como stream (imutils)

print("[INFO] inicializando streaming de video")
vs = VideoStream(src=WEBCAM).start()
time.sleep(2.0)

Como nosso objetivo é capturar os frames em stream, os passos a seguir serão colocados dentro de um loop infinito while True

4. Converter a imagem para escala de cinza (opencv)

# ler o frame do stream
frame = vs.read()
# redimensionar imagem para 800px de largura
frame = imutils.resize(frame, width=800)
# converter para escala de cinza
gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)

5. Detectar faces (dlib)

# detecar faces da imagem em escala de cinza utilizando o detector configurado anteriormente
rects = detector(gray, 0)

6. Extrair olhos (direito e esquerdo) - para cada face detectada

7. Calcular o EAR de cada olho e o EAR médio dos dois olhos - Separamos o calculo do EAR na função:

def calculate_eye_aspect_ratio(eye):
    # calcular a distância euclidiana entre os conjuntos das
    # landmarks verticais do olho coordenadas-(x, y)
    A = dist.euclidean(eye[1], eye[5])
    B = dist.euclidean(eye[2], eye[4])

    # calcular a distância euclidiana entre as
    # landmarks horizontais do olho coordenadas-(x, y)
    C = dist.euclidean(eye[0], eye[3])

    # calcular o EAR
    ear = (A + B) / (2.0 * C)
    return ear

Utilizamos a distancia euclidiana entre as landmarks verticais e a landmark horizontal e aplicamos a fórmula citada anteriormente.

8. Disparar alarme e exibir mensagem na tela caso: EAR ficar abaixo do limiar 40 quadros consecutivos (frames).

    # loop nas faces detectadas
    for rect in rects:
        shape = predictor(gray, rect)
        shape = face_utils.shape_to_np(shape)

        # extrair coordenadas dos olhos e calcular a proporção de abertura
        leftEye = shape[lStart:lEnd]
        rightEye = shape[rStart:rEnd]
        leftEAR = calculate_eye_aspect_ratio(leftEye)
        rightEAR = calculate_eye_aspect_ratio(rightEye)

        # ratio medio para os dois olhos
        ear = (leftEAR + rightEAR) / 2.0

        # convex hull para os olhos
        leftEyeHull = cv2.convexHull(leftEye)
        rightEyeHull = cv2.convexHull(rightEye)
        cv2.drawContours(frame, [leftEyeHull], -1, (0, 255, 0), 1)
        cv2.drawContours(frame, [rightEyeHull], -1, (0, 255, 0), 1)

        # exibe gráfico
        draw_graph(ear)

        # checar ratio do olho x threshold
        if ear < EYE_THRESHOLD:
            COUNTER += 1

            # verificar critério para soar o alarme
            if COUNTER >= FRAMES_SEQ:
                # ligar alarme
                if not ALARM_TRIGGERED:
                    ALARM_TRIGGERED = True
                    t = Thread(target=trigger_alarm)
                    t.daemon = True
                    t.start()

                cv2.putText(frame, "[ALERTA] FADIGA!", (10, 30),
                            cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 0, 255), 2)

            # se acima do threshold, desliga alarme e reseta contador
        else:
            ALARM_TRIGGERED = False
            COUNTER = 0

        # desenhar a proporção de abertura dos olhos
        cv2.putText(frame, "EAR {:.2f}".format(ear), (300, 30),
                    cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 0, 255), 2)

9. Mostrar frame e aguardar tecla de saída

# ainda dentro do loop while True
# mostrar frame
cv2.imshow("Frame", frame)
key = cv2.waitKey(1) & 0xFF

# tecla para sair do script "q"
if key == ord("q"):
	break

10. Finalizar tudo

# fora do loop while
# clean
cv2.destroyAllWindows()
vs.stop()

Demonstração:

Conclusão

Os recursos de detecção de landmarks da dlib são bastante poderosos, e as aplicaçõs são inúmeras, com eles podemos, por exemplo:

• aplicar filtros semelhantes aos do Instagram (bigode, óculos, modificar a boca, etc.);
• construir um detector de fadiga semelhante aos encontrados em veículos mais modernos (como nosso exemplo);
• ou até mesmo  extrair emoções de expressões faciais.

Referências

Facial landmarks with dlib, OpenCV, and Python - PyImageSearch

Learn how to detect and extract facial landmarks from images using dlib, OpenCV, and Python.

PyImageSearchAdrian Rosebrock

Drowsiness Detection System in Real-Time using OpenCV and Flask in Python

This article provides an overview of a system that detects whether a person is drowsy while driving and if so, alerts him by using voice…

Towards Data ScienceSouvik Ghosh

http://vision.fe.uni-lj.si/cvww2016/proceedings/papers/05.pdf

Drowsiness detection with OpenCV - PyImageSearch

In this tutorial, I’ll demonstrate how to build a driver drowsiness detector using OpenCV, Python, and computer vision techniques.

PyImageSearchAdrian Rosebrock

Nesse artigo, simularemos o funcionamento dos filtros do Instagram demonstrando como é possível aplicar filtros em tempo real utilizando  apenas Python, OpenCV e uma webcam. Para não estendermos demais esse post, não detalharemos o algoritmo por trás de cada filtro. Utilizaremos a classe filters.py que discutimos neste artigo.

Nosso algoritmo será composto de 3 etapas principais:

1. Inicialização: nessa etapa configuramos as dependências e inicializamos o streaming
2. Execução: etapa principal do nosso projeto, que será responsável por aplicar o filtro selecionado nos frames do streaming iniciado na etapa 1.
3. Finalização: nessa etapa encerramos o streaming e liberamos os processos que foram inicializados na etapa 1.

Após conhecer o fluxo da nossa aplicação.... hora do código.

Hora do Código

Como de costume, começamos importando os pacotes que iremos utilizar, e definimos algumas constantes importantes (para evitar números mágicos no meio do código):

# importar pacotes
import os

from imutils.video import VideoStream
import imutils
import numpy as np
import cv2
import time
from os.path import dirname, join
import os

# importamos nossos filtros
from filters import grayscale, original, sketch, sepia, blur, canny

# constantes
WEBCAM = os.environ.get('WEBCAM', 1)

Lembrando que também precisamos instalar as dependências:

pip install imutils numpy opencv-python

Note que nossa constante WEBCAM é um dado do tipo inteiro e foi obtida a partir das variáveis de ambiente do sistema operacional. Veremos mais adiante que essa constante será responsável por indicar à nossa aplicação qual webcam deve ser utilizada.

"Quero te ver" - Inicializando o streaming

Nossa proposta é manipular imagens em tempo real, por isso não podemos simplesmente enviar uma imagem como fizemos em artigos anteriores, precisamos iniciar um streaming de vídeo .

Um Streaming de Vídeo nada mais é do que a transmissão de um vídeo (ou uma sequência de imagens - frames) em tempo real, nesse caso, de uma webcam para o computador que está executando nossa aplicação.

Para nos ajudar nessa tarefa utilizaremos a classe VideoStream da biblioteca imutils que torna esse processo tão simples quanto executar um comando:

def main():
    print('[INFO] starting video stream')
    vs = VideoStream(src=WEBCAM).start()
    time.sleep(2.0)

    filters = {
        '0': original,
        '1': grayscale,
        '2': sketch,
        '3': sepia,
        '4': blur,
        '5': canny,
        '6': None,
        '7': None
    }

    print("""Press any of the following keys to:
        0: Original Image
        1: Grayscale
        2: Sketch
        3: Sepia
        4: Blur
        5: Canny
        6: Face detection
        7: Blur face
        q: Quit""")

    # initial_filter
    selected_filter = '0'

No código acima estamos definindo uma função main que abrigará todo nosso código.

Em seguida instanciamos e inicializamos o streaming de vídeo utilizando como fonte da transmissão a webcam , que foi definida anteriormente, para evitar possíveis erros, indicamos ao nosso algoritmo para aguardar 2 segundos antes de prosseguirmos a execução time.sleep(2.0).

Como é desejável que o usuário seja capaz de alterar o filtro em tempo de execução, criamos um dicionário filters que traduzirá o filtro selecionado para a função correspondente.

Para finalizar esse etapa mostramos um texto com os filtros disponíveis e inicializamos o filtro inicial para "0" - imagem original.

"Vamos mudar" - Aplicando filtros no streaming

Com o streaming iniciado podemos agora ler os frames e aplicar as transformações que o usuário selecionar. Para termos o efeito de vídeo, iremos colocar todo o processamento em um loop:

 while True:
        # ler frames
        frame = vs.read()
        frame = imutils.resize(frame, width=400)

        # pegar filtro selecionado
        filter = filters.get(selected_filter)
        if filter is not None:
            # aplicar filtro no frame
            frame = filter(frame)

        # exibir frame na tela
        cv2.imshow("Frame", frame)
        key = cv2.waitKey(1) & 0xFF
        if key == ord('q'):
            break

        if key in [ord(k) for k in filters.keys()]:
            selected_filter = chr(key)

Dentro do loop fazemos a leitura do frame capturado vs.read() redimensionamos a imagem mutils.resize(frame, width=400), em seguida pegamos o filtro a partir do dicionário que configuramos na etapa anterior filter = filter.get(selected_filter) e o aplicamos à imagem frame = filter(frame) , nesse momento nossa variável frame está com o filtro aplicado.

Por fim utilizamos o OpenCV para exibir a imagem cv2.imshow("Frame", frame).

Como todo nosso código está sendo executado em um loop infinito é importante configurarmos uma condição de parada, nesse caso utilizamos o waitKey do OpenCV.

O waitKey ficará "escutando" e, quando alguma tecla for pressionada, ela será armazenada na variável key. Em nosso exemplo realizamos 2 testes:

• O primeiro verifica se a tecla é a letra "q", em caso positivo, interrompe a execução do loop.
• O segundo verifica se a tecla existe no dicionário de filtros, em caso positivo, aplica o filtro selecionado.

"Ao sair, apague a luz" - Finalizando a aplicação

Quando interrompemos o loop, precisamos destruir as janelas abertas pelo imshow do OpenCV e encerrar o stream:

 # destruir as janelas e interromper o stream
 cv2.destroyAllWindows()
 vs.stop()

Da maneira que construímos, para aplicarmos qualquer outro filtro, basta que ele seja programado - no nosso caso os filtros localizados em filters.py - e incluído no dicionário filters.

Bônus - Deep Learning para Detecção de Rostos

Para irmos um pouco além, como etapa bônus, utilizaremos um modelo de Deep Learning pré-treinado e discutido neste artigo.

Iremos implementar a funcionalidade de detecção e censura de rostos da mesma maneira dos filtros, ou seja, o usuário poderá selecioná-los através das teclas.

Como utilizaremos Deep Learning e um modelo já treinado, precisamos, primeiro carregar os arquivos, informamos o nível de confiança desejado (nesse caso, 70% ou 0.7) e carregamos o modelo:

PROTOTXT = join(dirname(__file__), "deploy.prototxt.txt")
MODEL = join(dirname(__file__), "res10_300x300_ssd_iter_140000.caffemodel")
CONFIDENCE_THRESHOLD = 0.7

# carregar o modelo
net = cv2.dnn.readNetFromCaffe(PROTOTXT, MODEL)

Nota: utilizamos as funções join e dirname(__file__) , ao invés de simplesmente informar o nome do arquivo, para melhor compatibilidade entre sistemas operacionais.

Com nosso modelo carregado, iremos incluir as funções de detecção e censura de rostos no dicionário (opções 6 e 7) e dentro do nosso loop:

    h, w = frame.shape[:2]
    
    blob = cv2.dnn.blobFromImage(frame, 1, (300, 300), (104.0, 177.0, 123.0))
    net.setInput(blob)
    detections = net.forward()
     
    # iterar ao longo das deteccoes
    for i in range(0, detections.shape[2]):
        # exemplo de intervalo de confianca
        confidence = detections[0, 0, i, 2]
        
        # selecionar apenas intervalos acima do threshold
        if confidence > CONFIDENCE_THRESHOLD:
            # label da confiança
            text = "{:.2f}%".format(confidence * 100)
            
            # calcular o bounding box
            box = detections[0, 0, i, 3:7] * np.array([w, h, w, h])
            (startX, startY, endX, endY) = box.astype('int')
            
            if selected_filter == '6':
                frame = cv2.rectangle(frame, (startX, startY), (endX, endY), (0, 255, 0), 1)
                
            if selected_filter == '7':
                face = frame[startY:endY, startX:endX]
                blured = cv2.GaussianBlur(face, (33, 33), 0)
                frame[startY:endY, startX:endX] = blured

Primeiramente extraímos o tamanho (altura e largura) do frame que estamos analisando.

Como estamos trabalhando com deep learning, precisamos realizar alguns pré-processamentos na imagen antes de passá-la através da rede. Para nos auxiliar nesse processo, o OpenCV possui a função cv2.dnn.blobFromImage, que executa os seguintes passos:

1. Subtração da média
2. Escala
3. Opcionalmente troca de canais (alterar R[ed] com B[lue])

Mais detalhes sobre esse recurso podem ser encontrados aqui.

Para a subtração da média utilizamos os valores descritos no benchmark do próprio OpenCV.

Definimos, então, o blob gerado como input da rede neural net.setInput(blob) e a executamos net.forward() esse processo resultará nas detecções realizadas. Como a rede irá retornar mais de uma detecção e seus respectivos graus de confiança, iremos iterar sobre elas procurando pelo primeiro resultado que esteja acima do limiar de 70% que definimos anteriormente.

Quando encontrado, iremos extrair os pontos que delimitam o rosto detectado formando uma "caixa" (bounding box):

box = detections[0, 0, i, 3:7] * np.array([w, h, w, h])
(startX, startY, endX, endY) = box.astype('int')

Com os pontos da bounding box - que delimitam a área de rosto detectado -, podemos aplicar os filtros desejados.

Em nosso exemplo nosso filtro 6 (detecção de rosto) irá exibir um retângulo verde ao redor do rosto frame = cv2.rectangle(frame, (startX, startY), (endX, endY), (0, 255, 0), 1). Enquanto que nosso filtro 7 (censura) irá aplicar o GaussianBlur para embaçar e censurar o rosto.

face = frame[startY:endY, startX:endX]
blured = cv2.GaussianBlur(face, (33, 33), 0)
frame[startY:endY, startX:endX] = blured

Demo

A versão final do projeto pode ser conferida no link abaixo

Projeto

virb30/realtime_face_filters

Contribute to virb30/realtime_face_filters development by creating an account on GitHub.

GitHubvirb30

Referências

Face detection with OpenCV and deep learning - PyImageSearch

Learn how to perform face detection in images and face detection in video streams using OpenCV, Python, and deep learning.

PyImageSearchAdrian Rosebrock

opencv/opencv

Open Source Computer Vision Library. Contribute to opencv/opencv development by creating an account on GitHub.

GitHubopencv

Deep learning: How OpenCV’s blobFromImage works - PyImageSearch

Today’s blog post is inspired by a number of PyImageSearch readers who have commented on previous deep learning tutorials wanting to understand what exactly OpenCV’s blobFromImage function is doing under the hood. You see, to obtain (correct) predictions from deep…

PyImageSearchAdrian Rosebrock