O que é o Jupiter

O Jupiter é uma ferramenta para responder perguntas sobre sistemas antes de construí-los — ou antes de mudá-los.

As perguntas que ele responde

• Quanto tempo um pedido vai demorar do início ao fim?
• Quantos servidores preciso para atender o dobro da demanda?
• Onde está o gargalo?
• Se eu dobrar a capacidade daquela etapa, quanto melhora?
• Com que frequência o sistema fica cheio e recusa trabalho?

São perguntas que aparecem em fila de atendimento, linha de produção, arquitetura de software, rede de sensores, logística — qualquer coisa em que trabalho chega, passa por etapas e sai.

Por que não basta uma conta de média

Parece que dá para responder na planilha. Se o atendimento leva 5 minutos e chega um cliente a cada 10, o atendente trabalha metade do tempo e ninguém espera. Certo?

Errado. Na prática, forma-se fila: às vezes dois clientes chegam quase juntos, e o segundo espera mesmo com o atendente folgado na média.

E o efeito não é pequeno. Nesse mesmo sistema, se o atendimento subir de 5 para 9 minutos:

Tempo de atendimento	Atendente ocupado	Espera do cliente
5 min	50%	10 min
9 min	90%	89 min

O atendimento quase dobrou. A espera multiplicou por nove. Nenhuma média simples prevê isso.

O que a ferramenta acrescenta

Ela leva em conta que as coisas variam. Chegadas não são regulares, atendimentos não duram sempre o mesmo. É dessa variação que nascem as filas — e é ela que uma conta de média ignora.

Como um modelo funciona

Você desenha o sistema com duas peças:

• Lugares (círculos) representam onde as coisas ficam: uma fila, uma etapa de processamento, um recurso disponível.
• Transições (retângulos) representam o que acontece: um cliente chega, um atendimento termina, uma peça avança.

Dentro dos lugares ficam fichas, que representam as coisas em si — clientes, pedidos, peças, mensagens. As transições movem fichas de um lugar para outro, e algumas levam tempo para isso.

Esse desenho é uma Rede de Petri Estocástica. "Estocástica" quer dizer que os tempos variam segundo uma distribuição, em vez de serem fixos — que é o que faz o modelo se parecer com a realidade.

Como se usa

1. Desenhe o sistema com lugares e transições.
2. Diga quanto tempo cada etapa leva.
3. Declare o que quer medir — tempo de resposta, vazão, utilização.
4. Execute e leia os resultados.
5. Compare cenários variando um parâmetro para ver o que muda.

O passo 5 costuma ser o que mais entrega. Um modelo rodado uma vez responde "como está"; variando parâmetros ele responde "o que fazer".

O que ele não é

Não é um simulador de eventos programável. Você descreve o sistema com o formalismo de redes de Petri, não escrevendo código.

Não descobre o modelo sozinho. Ele calcula as consequências do que você descreveu. Se o desenho não corresponde ao sistema real, os números não vão corresponder também — por isso vale confrontar o modelo com alguma medição real sempre que possível.

Não substitui medir. Ele serve para responder perguntas sobre situações que você ainda não pode medir: o dobro da carga, uma etapa a mais, um servidor a menos.

Por onde começar

Vá para Seu primeiro modelo. Em poucos minutos você monta uma fila com um atendente, e vai conseguir conferir se o resultado está certo — porque esse caso tem resposta conhecida.