Alexandre Hideki Deguchi Martani

Dalton Vinicius Teixiera Pinto

Este laboratório tem como objetivo o estudo e compreensão de modelos de simulação. Foram escolhidos os modelos de abordagem por eventos e por atividades.

Os detalhes de cada implementação e os resultados obtidos estão devidamente comentados nos itens a seguir.

A descrição do problema apresentada no roteiro pode ser expressa segundo os diagramas de ciclos apresentados a seguir:

Diagrama de Ciclos de Cliente

Diagrama de Ciclos de Ligação

Diagrama de Ciclos de Caixa Eletrônico

Diagrama de Ciclos de Gerente

Diagrama de Ciclos de Operador de Caixa

Diagrama de Ciclos Integrado

Usando a modelagem por eventos, foram implementadas as classes CClient e CCall.

Cada objeto da classe CClient representa um cliente presencial que entrou no banco. Cada objeto da classe CCall representa uma ligação para o gerente.

As classes básicas não foram alteradas a partir do exemplo dado em classe. As classes CCall e CClient implementam a abordagem por eventos, sendo cada método representando um evento, ou uma subrotina de um evento. Os eventos são agendados e executados pela classe básica CEventExecutive.

Classe CCall:

• ArriveCall: Trata a chegada de uma ligação; Se o gerente está livre, inicia o serviço e agenda o fim do serviço, caso contrário, coloca a ligação na fila de ligações. Também agenda a chegada da próxima ligação.

• ScheduleEndCall: Verifica que o tempo que o cliente esperou é maior que o limite. Se for, termina a ligação imediatamente e registra um não atendimento; caso contrário, agenda o final do serviço.

• EndCallService: Trata o final do serviço da ligação, coletando estatísticas.

• EndCall: Encerra a ligação. Verifica se há outra ligação ou outro cliente na fila para o gerente, se houver, inicia o serviço do mesmo; caso contrário, coloca o gerente em estado livre.

• ExecuteEvent: Classe de ajuda para roteamento dos eventos.

Classe CClient:

• ScheduleEndATMService: Agenda o final do serviço no ATM.

• ScheduleEndManagerService: Agenda o final do serviço no gerente.

• ScheduleEndTellerService: Agenda o final do serviço no caixa.

• ArriveClient: Trata a chegada de um cliente. Basicamente, decide para onde o cliente deseja ir e chama uma das funções GoTo*. Também agenda a chegada do próximo cliente.

• GoToATM: Trata a ida do cliente ao ATM. Se o ATM estiver livre e sem fila, ele vai no ATM, caso contrário, ele entra no fim da fila.

• GoToManager: Trata a ida do cliente ao gerente. Se o gerente estiver livre e sem fila e não tiver nenhuma ligação na fila, ele vai no gerente, caso contrário, ele entra no fim da fila.

• GoToTeller: Trata a ida do cliente ao caixa. Se o caixa estiver livre e sem fila, ele vai no caixa, caso contrário, ele entra no fim da fila.

• GoOut: Trata a saída do cliente, gerando estatística de tempo de permanência do cliente no sistema.

• EndATMService: Trata o fim do serviço de ATM, onde o cliente pode decidir sair ou ir para o caixa ou ir para o gerente. Verifica a fila do ATM para a presença de outros clientes e processa o próximo, ou marca o ATM como livre.

• EndManagerService: Trata o fim do serviço de gerente, depois do qual o cliente sai da agência. Verifica a fila de ligações e a de clientes no gerente e processa o próximo, ou marca o gerente como livre.

• EndTellerService: Trata o fim do serviço de caixa, depois do qual o cliente sai da agência. Verifica a fila do caixa para a presença de outros clientes e processa o próximo, ou marca o caixa como livre.

• ExecuteEvent: Classe de ajuda para roteamento dos eventos.

Os arquivos da modelagem por atividades estão em anexo, no arquivo .zip no qual este relatório foi entregue, a descrição de cada arquivo segue a seguir:

• EventApproach.cpp: Programa principal, no qual estão descritas as rotinas e classes especificas para a solução do problema na abordagem de eventos.
• Event.h: Biblioteca oferecida pelo professor para a realização do laboratório, tal biblioteca possui as classes básicas para a modelagem por eventos.
• Statistics.h: Biblioteca oferecida pelo professor que contém rotinas para o tratamento estatístico dos dados. Tal biblioteca foi ligeiramente modificada para facilitar a realização do laboratório.
• CLista: Biblioteca oferecida pelo professor, que contém a representação de listas usadas nos outros arquivos.

Observação: Para compilar e executar o laboratório, é necessário que exista a pasta output para que as saídas de debug sejam devidamente geradas sem que o programa pare de funcionar.

Usando a modelagem por atividades, foi implementada a classe CBank em C++.

Tal classe trata de todas as atividades realizadas para a simulação do funcionamento de um banco.

Tal classe CBank possui uma entidade CEntity, que pode ser um cliente ou uma chamada, a ser tratada adequadamente por cada atividade.

Assim, foi criado o executor CBankExecutor para gerenciar as atividades CBank.

Basicamente, o executor CBankExecutor possui as rotinas básicas para gerenciar a execução da atividades que ele possui. Assim sendo, ele executa o time scan e para cada periodo de tempo dado, as atividades são obtidas e executadas.

A execução de cada atividade ocorre através da rotina ExecuteActivity, que executa todas as atividades após, onde cada uma checa se deve realizar algo, ou não. Estas atividades são: ArriveClient, ArriveCall, StartManager, EndManager, StartCall, EndCall, StartTeller, EndTeller, StartATM e EndATM.

• ArriveClient: Trata de enfileirar a chegada de um cliente, e agendar a chegada do próximo.

• ArriveCall: Trata de enfileirar a chegada de uma chamada telefônica, e agendar a chegada da próxima.

• StartManager: Trata de iniciar a execução do atendimento de um cliente pelo Gerente, agendando o termino do atendimento, se este estiver livre e não houver nenhuma chamada telefônica pendente.

• EndManager: Trata de terminar execução do atendimento de clientes pelo Gerente, deixando o Gerente livre para realizar outras tarefas.

• StartCall: Trata de iniciar a execução do atendimento de chamada telefônica pelo Gerente, agendando o termino do atendimento, se este estiver livre.

• EndCall: Trata de terminar execução do atendimento de chamadas telefônicas pelo Gerente, deixando-o livre para realizar outras tarefas.

• StartTeller: Trata de iniciar a execução do atendimento de um cliente pelo Operador de Caixa, agendando o termino do atendimento, se este estiver livre.

• EndTeller: Trata de terminar execução do atendimento de cliente pelo Operador de Caixa, deixando-o livre para atender um novo cliente.

• StartATM: Trata de iniciar a execução do atendimento de um cliente pelo Caixa Eletrônico, agendando o termino do atendimento, se este estiver livre.

• EndATM: Trata de terminar execução do atendimento de cliente pelo Caixa Eletrônico, deixando-o livre para atender um novo cliente. Tal atividade também reencaminha o cliente para próximo atendimento, se necessário (Gerente ou Operador d Caixa).

Os arquivos da modelagem por atividades estão em anexo, no arquivo .zip no qual este relatório foi entregue, a descrição de cada arquivo segue a seguir:

• ActivityApproach.cpp: Programa principal, no qual estão descritas as rotinas e classes especificas para a solução do problema na abordagem de atividades.
• Activity.h: Biblioteca oferecida pelo professor para a realização do laboratório, tal biblioteca possui as classes necessárias para a implementação das classes específicas do executor, atividade além de conter a classe CEntity, usda para modelar os clientes e chamadas.
• Statistics.h: Biblioteca oferecida pelo professor que contém rotinas para o tratamento estatístico dos dados. Tal biblioteca foi ligeiramente modificada para facilitar a realização do laboratório.
• CLista: Biblioteca oferecida pelo professor, que contém a representação de listas usadas pela biblioteca Activity.h.

Observação: Para compilar e executar o laboratório, é necessário que exista a pasta output para que as saídas de debug sejam devidamente geradas sem que o programa pare de funcionar.

A execução desta modelagem para foi feita para os períodos de 6 meses, 1 ano, 2 anos, 5 anos e 10 anos.

Os resultados resumidos de cada período são dados pelas tabelas a seguir:

Abordagem de eventos

Abordagem de atividades

Abordagem de eventos

Abordagem de atividades

Abordagem de eventos

Abordagem de atividades

Abordagem de eventos

Abordagem de atividades

Abordagem de eventos

Abordagem de atividades

• call wait: Tempo de espera de chamadas
• call in system: Tempo que as chamadas ficam no sistema
• call duration: Duração do atendimento de cada chamada
• call attended: Atendimentos de chamada (valor 1 para chamada atendida, valor 0 para chamada não atendida, sendo que o total é o numero de chamadas)
• client wait: Tempo de espera do cliente, para cada atendimento, independente de qual
• client in system: Tempo que cada cliente fica no sistema
• manager wait: Tempo de espera do cliente aguardando o gerente
• manager duration: Duração do atendimento do cliente pelo gerente
• teller wait: Tempo de espera do cliente aguardando o operador de caixa
• teller duration: Duração do atendimento do cliente pelo operador de caixa
• atm wait: Tempo de espera do cliente aguardando o caixa eletrônico
• atm duration: Duração do atendimento do cliente pelo caixa eletrônico

Pode-se perceber que em todos os dados, tem-se uma convergência rápida, sendo que eles diferem pouco. Isso pode denotar que a aproximação obtida é boa.

Ainda assim, alguns dos dados apresentam comportamento estranho, como os valores de manager wait (Espera do cliente para atendimento com gerente). Porém este tipo de resultado é facilmente entendido ao olharmos os valores máximos, que são extremamente altos. Isso significa que apesar da grande maioria dos valores estarem concentrados perto de valores relativamente baixos, existem valores extremos muito grandes, que fazem com que o desvio padrão seja bem elevado.

A dificuldade da abordagem de eventos é a grande quantidade de casos que precisam ser tratados em cada evento. Adicionar mais uma condição, por exemplo, mais um tipo de cliente que visita o gerente, requer alterações em diversos pontos do código.

Já na abordagem por atividades tem-se grande facilidade em adicionar novas atividades, basta adicionar uma rotina simples a mais para que cada uma seja tratada adequadamente, com o devido cuidado de fazer as checagens de tipo de atividade e tempo. A desvantagem é a grande quantidade de verificações de tipo de atividade e de tempo, presente em praticamente todos os métodos. Nesta abordagem, há uma quantidade muito maior de chamadas de métodos, que são descartados nessa verificação. Porém, tais chamadas consomem tempo de programação e de processamento.

Em ambos os métodos, nota-se a existência do acoplamento entre as classes, pois por exemplo, ao fazer com que o gerente atenda prioritariamente chamadas telefônicas, é preciso que a rotina de atendimento ao cliente esteja programada adequadamente, fazendo com que o atendimento não seja realizado se houver chamada telefônica em espera. Este tipo de raciocínio é sutil, mas causa grandes problemas e é difícil de ser notado.

Assim como o esperado, ambas implementações trouxeram valores muito próximos, como exemplo temos a espera por atendimento no caixa eletrônico para o período de 10 anos: por atividade obteve-se 3.49 mins com desvio padrão de 5.04 mins, já na abordagem por eventos obteve-se 3.46 mins com desvio padrão de 5.04 mins.

Alguns poucos valores apresentaram uma diferença um pouco maior, como a espera por atendimento do gerente no período de 10 anos: por atividade obteve-se 40.45 mins com desvio padrão de 46.04 mins, já para eventos, obteve-se 35.65 mins com desvio padrão de 42.20 mins. A primeira vista, estes dados parecem ruins pela distância da ordem de 10%, porém nota-se que o desvio padrão é muito grande, tornando-os compatíveis ainda assim. Esse grande desvio padrão é devido a presença de alguns poucos valores muito altos no conjunto de amostras, no caso de atividades, obteve-se um valor máximo de 406.26 mins e no de eventos um valor máximo de 361.87, assim variações nesses campos são totalmente compreensíveis e esperadas.

Com a realização deste laboratório, pode-se compreender melhor as possíveis implementações de modelos de simulações.

Os resultados obtidos foram coerentes com o esperado, uma vez que, para abordagens diferentes, foi possível obter valores bem próximos para cada grandeza estudada. Em algumas grandezas, o valores não foram tão próximos quanto o esperado, porém tal resultado é facilmente compreendido quando se observa que estes estão dentro da faixa determinada pelo desvio padrão.

Além disso, foi possível comparar as vantagens e desvantagens de cada um dos modelos de simulações utilizado, tornando possível uma escolha mais consciente do modelo que será adotado em trabalhos futuros.