Simulador de Elevadores

UNIVERSIDADE LUTERANA DO BRASIL
CURSO DE SISTEMAS DE INFORMAÇÃO
CÂMPUS CANOAS

PROTÓTIPO DE SIMULADOR
DE ELEVADORES

Mauricio Volkweis Astiazara

Monografia desenvolvida durante a disciplina Trabalho de
Conclusão de Curso em Sistemas de Informação II e
apresentada ao Curso de Sistemas de Informação da
Universidade Luterana do Brasil, câmpus Canoas, como
pré-requisito para a obtenção do título de Bacharel em
Sistemas de Informação.
Orientador: Prof. Roland Teodorowitsch

2

Canoas, novembro de 2005.

Universidade Luterana do Brasil – ULBRA
Curso de Sistemas de Informação – Câmpus Canoas

Reitor:
Pastor Ruben Eugen Becker
Vice-Reitor:
Eng. Leandro Eugênio Becker
Diretor da Faculdade de Informática:
Prof. Gilberto Fernandes Marchioro
Coordenador de Curso (Câmpus Canoas):
Prof. Gilberto Fernandes Marchioro
Coordenador das Disciplinas de Trabalho de Conclusão de Curso (Câmpus Canoas):
Profª. Denise Salvadori Virti

Banca Avaliadora composta por: Data da defesa: 06/12/2005.
Prof. Roland Teodorowitsch (Orientador)
Prof. Adriano Petry
Prof. Alexandre Berg

CIP – Catalogação na Publicação
Astiazara, Mauricio

Protótipo de Simulador de Elevadores / Mauricio Volkweis
Astiazara; orientado por Roland Teodorowitsch. – Canoas: 2005.
64 p.: il.

Trabalho de Conclusão de Curso (Graduação em Sistemas de
Informação). Universidade Luterana do Brasil, 2005.

1. Simulação. 2. Elevador. 3. Orientação a Objetos. I.
Teodorowitsch, Roland. II. Título.

Endereço:
Universidade Luterana do Brasil – Câmpus Canoas
Av. Farroupilha, n° 8.001 - Bairro São Luís
CEP 92420-280 Canoas-RS – Brasil

AGRADECIMENTOS
Agradeço à empresa Wise Engenharia Eletrônica e Informática pela contribuição e
pelos recursos cedidos, sem os quais este trabalho não seria realizado.

SUMÁRIO
1 INTRODUÇÃO....................................................................................................................11
2 ELEVADORES....................................................................................................................12
3 SIMULAÇÃO.......................................................................................................................17
4 PROJETO DA FERRAMENTA........................................................................................21
5 DESENVOLVIMENTO DA FERRAMENTA..................................................................26
6 UTILIZAÇÃO DO PROTÓTIPO......................................................................................52
7 CONCLUSÃO......................................................................................................................62

LISTA DE ABREVIATURAS E SIGLAS
ABNT Associação Brasileira de Normas Técnicas
CAD Computer Aided Design
CASE Computer Aided Software Engineering
NBR Norma Brasileira
OMG Object Management Group
UML Unified Modeling Language
VB Visual Basic

RESUMO
Este artigo descreve o projeto e o desenvolvimento de uma ferramenta para a
simulação de sistemas de elevadores. O objetivo desta ferramenta é auxiliar o profissional da
área de pesquisa e desenvolvimento de tecnologia para elevação. O simulador permitirá a
avaliação de diferentes projetos de elevadores.

Palavras-chaves: Simulação; Elevador; Orientação a Objetos.

ABSTRACT
Title: “Prototype of Elevators Simulator”

This paper describes the design and the development of a tool for simulation of
elevator systems. The objective of that tool is to provide assistance to the elevation
technology researcher. The simulator will allow the evaluation of different elevator projects.

Key-words: Simulation; Elevator; Object Technology.

1 INTRODUÇÃO
Na indústria de elevadores, a área de venda e dimensionamento tem meios para avaliar
o desempenho de uma solução de elevadores para um prédio que será construído ou que está
sendo modernizado. Esses meios normalmente são cálculos com o uso de fórmulas e tabelas
que descrevem o desempenho dos atuais produtos de elevação. A área de pesquisa e
desenvolvimento também tem necessidade de realizar avaliações e experimentos, porém não
pode utilizar os mesmos cálculos da área de venda e dimensionamento porque estes são
totalmente baseados em tecnologias existentes, e não dão margem a variações para teste de
novas propostas e alternativas de projeto.
Para auxiliar a área de pesquisa e desenvolvimento, é proposta uma ferramenta não de
cálculo, mas sim de simulação de elevadores. Esta ferramenta incorpora nos seus objetos
simulados o mesmo comportamento dos objetos reais e ainda permite um maior grau de
configuração e flexibilidade. O produto desenvolvido é um protótipo funcional que deve
provar que a simulação é uma alternativa viável na área de elevação.
O próximo capítulo aprofunda a apresentação sobre elevadores e sobre o problema que
está sendo abordado. Em seguida, uma conceituação sobre simulação é feita, bem como
metodologias para simulação e ferramentas existentes no mercado. É definida uma proposta
de ferramenta no capítulo seguinte. Toda a modelagem e desenvolvimento da ferramenta são
descritos no Capítulo 5. O capítulo seguinte já explora o protótipo produzido em ação. Ao
final são relatadas as conclusões obtidas com o trabalho e as referências utilizadas.

2 ELEVADORES
Para um melhor entendimento sobre elevadores, é feito um breve histórico de como
surgiu este meio de transporte, como se deu o seu desenvolvimento tecnológico e tendências
de tecnologia para o futuro. Passa-se então a uma introdução à disciplina de engenharia de
elevação e às necessidades que a área de pesquisa e desenvolvimento possui.

2.1 SURGIMENTO DO ELEVADOR
O Homem é um animal que prefere viver em colônia a viver isoladamente. A vida em
grupo sempre favoreceu a humanidade desde os tempos mais remotos, por exemplo, caçando
em conjunto. Desde o nascimento das primeiras cidades, o que se viu foi uma urbanização
crescente; as pessoas deixando o campo e indo morar e trabalhar na cidade.
Esse fenômeno de agrupamento acarreta uma maior quantidade de pessoas em um
mesmo espaço, o que requer melhor aproveitamento da área disponível. Edificações de mais
de um piso existem desde a antiguidade, mas vieram atender especialmente bem à
necessidade sempre crescente de mais pessoas no mesmo lugar, manifestadas atualmente
como centros comerciais, torres, prédios de escritórios, etc.
O uso de edificações de mais de um piso fez o Homem ter alguma preocupação com
transporte vertical de pessoas e materiais. No começo, eram usados meios rudimentares, como
escadas, rampas, cestas e plataformas erguidas por tração animal ou até mesmo humana. Com
o aprimoramento, surgiram os dispositivos baseados em trilhos verticais ou guias. Estes
dispositivos evoluíram para a forma de elevador no início de 1800. Neste período, a principal
utilização destes elevadores era o transporte de materiais e, ocasionalmente, de pessoas. Ainda
não havia mecanismos de segurança e os resultados eram desastrosos quando o cabo de
sustentação se rompia (STRAKOSCH, 1998).
Em 1853, Elisha Graves Otis inventou o mecanismo de segurança de elevadores. Este
mecanismo foi projetado para prevenir a queda livre da plataforma de elevação caso o cabo se
rompa. Devido a essa invenção, o uso de elevadores para transporte de pessoas começou a ter
aceitação do público. Em 1857, foi instalado o primeiro elevador de passageiros na loja de E.
V. Haughwout & Company em Nova Iorque. Atualmente, um elevador é definido como um
transporte projetado para mover pessoas ou materiais verticalmente. Este transporte deve
incluir um mecanismo de segurança para evitar a queda em caso de falha.

13

2.2 DESENVOLVIMENTO TECNOLÓGICO E TENDÊNCIAS
Nos primórdios da indústria de elevadores, a maior evolução ocorreu na área da
engenharia mecânica. A mecânica era usada para realizar o trabalho de erguer a carga
transportada. Controladores mecânicos eram usados para selecionar a direção da viagem
(subida ou descida) e para outras funções necessárias. Elevadores hidráulicos tornaram-se
muito populares e foram o mais alto patamar tecnológico durante alguns anos.
Mais tarde, muitas partes mecânicas foram substituídas por partes elétricas. Isto
permitiu o aparecimento do primeiro elevador de botão. A aplicação de controladores
elétricos estabilizou o tempo de viagem do elevador, uma vez que a velocidade não mais
dependia de fatores como a pressão da água (para elevadores hidráulicos) e características
mecânicas (para elevadores a tração). Outra melhoria que a eletricidade trouxe posteriormente
foi uma suavização da aceleração e desaceleração, muito comum nos elevadores atuais,
proporcionando certo conforto ao passageiro (STRAKOSCH, 1998).
A evolução da eletrônica deu origem à microeletrônica e esta passou a ser mais uma
tecnologia empregada no transporte vertical. Inicialmente, microcontroladores permitiram um
melhor gerenciamento dos motores, aumentando a velocidade e, conseqüentemente,
diminuindo o tempo de viagem. Uma melhor suavização da aceleração e desaceleração
também pode ser obtida. O uso da microeletrônica foi a maior inovação da década passada
(STRAKOSCH, 1998) e com o aumento da velocidade dos microprocessadores, mais
operações do elevador tornaram-se eletrônicas, possibilitando a aumento no conforto e
agregação de diversos serviços extras, como, por exemplo, restrição de acesso.
A tendência da evolução tecnológica para os elevadores é a uso da informática. O que
já se observa há algum tempo, e que tende a ser o caminho, não é uma substituição da
microeletrônica pela informática, mas sim uma integração e complementação. Essa integração
dá-se, por exemplo, através de sistemas de elevadores se comunicando com sistemas de
informação, disponibilizando informações sobre o seu estado atual, possibilitando análises,
como diagnóstico de problemas. Sistemas de informação também se comunicam com os
sistemas de elevadores enviando configurações e comandos, servindo de interface de mais
alto nível entre o Homem e o sistema de elevador. Essas aplicações já podem ser vistas nos
chamados prédios inteligentes, onde o que ocorre é uma integração de diversos dispositivos
(como o sistema de elevadores) gerenciados por um sistema de automação predial (sistema de
informação). Uma aplicação da informática como complemento ao sistema de elevadores é
servindo de periférico rico, como, por exemplo, usar um computador com tela sensível ao
toque para terminal de chamadas, ou então, como quiosque interativo dentro da cabine,
distraindo o passageiro durante a viagem.
No futuro, o computador será usado como núcleo do sistema de elevadores, realizando
operações críticas como lógicas de atendimento de chamadas. Isso facilitará ainda mais a
integração com os sistemas de informação, podendo talvez o sistema de elevadores ser
conectado diretamente à rede de computadores local, e até mesmo à rede mundial de
computadores, para fornecer e consultar dados estatísticos sobre o tráfego de pessoas no
prédio, visando proporcionar um melhor serviço de transporte.

2.3 ENGENHARIA DE ELEVAÇÃO
Com a grande atividade da construção civil no começo da década de 90 e o aumento
do tamanho e altura dos prédios naquela época, questões como quantidade, tamanho e
localização dos elevadores começaram a ser levantadas (STRAKOSCH, 1998). Um

14

pensamento típico e errado da época era que “se um prédio possui um sistema de elevadores
que atende às suas necessidades de tráfego, para um prédio com o dobro do tamanho basta
dobrar a quantidade de elevadores”. Evidenciou-se que esta lógica não é verdadeira e a
necessidade fez surgir a engenharia de elevação como uma disciplina especial de projeto.
Engenharia de elevação é a técnica de aplicar a tecnologia de elevadores disponível
para satisfazer a demanda de tráfego em prédios de múltiplos andares. Ela envolve um
cuidadoso estudo da população total esperada para ocupar os pisos superiores, um estudo
sobre os padrões de tráfego dessa população, o apropriado cálculo do desempenho do sistema
de elevadores e o julgamento dos resultados obtidos para então recomendar a melhor solução.
A qualidade de uma solução em questão é avaliada, no estudo da elevação, em termos
de qualidade de transporte e qualidade de serviço. Qualidade de transporte é a capacidade do
sistema de elevadores transportar uma quantidade de passageiros em 5 minutos. Quanto maior
a quantidade de passageiros transportados em 5 minutos, maior é a qualidade de transporte. Já
a qualidade de serviço está relacionada com tempo que o passageiro aguarda pelo elevador.
Quanto menor o tempo de espera, melhor é a qualidade do serviço. Normalmente, cada país
regulamenta exigências mínimas de qualidade de transporte e qualidade de serviço para cada
tipo de prédio (comercial, residencial, etc.). No Brasil, essas exigências estão na norma
brasileira (NBR) 5665 da Associação Brasileira de Normas Técnicas (ABNT).
Um estudo de elevação consiste basicamente de:
1. Avaliação dos requisitos de transporte, através do Estudo de Tráfego;
2. Determinação de uma solução que atenda ao mesmo tempo à qualidade de
transporte e à qualidade de serviço da maneira mais econômica, através do Cálculo
de Tráfego.

2.3.1 Estudo de Tráfego
A avaliação dos requisitos de transporte inicia pelo estudo minucioso e detalhado a
respeito da população do prédio. Isto inclui levantamento de informações sobre como as
pessoas irão chegar, ocupar e se mover no prédio. Os fatores básicos de estudo incluem o
número de ocupantes e visitantes, sua distribuição pelos pavimentos, os tempos e as taxas de
chegada e partida. Tais informações podem ser determinadas, dependendo se o prédio em
questão é existente ou ainda está em construção, por observações, discussões com
administradores e proprietários e por pesquisa das necessidades de uso dos ocupantes (ou
futuros ocupantes) e da população.
Este estudo sobre a população visa o descobrimento do período crítico de tráfego. O
período crítico de tráfego é o período de 5 minutos em que o sistema de elevadores é mais
requisitado. O tipo, direção e intensidade do tráfego durante este período determinam a
quantidade de serviço de elevação necessária para o prédio. Se os elevadores servem bem ao
tráfego durante o período crítico, eles são capazes de satisfazer ao tráfego durante todos os
outros períodos. Por exemplo, para um prédio de escritórios, o período crítico de tráfego pode
ser de manhã, pouco antes do horário de início da jornada de trabalho, com tráfego
predominantemente para cima, pois as pessoas estão tentando chegar em suas mesas para
começar a trabalhar. Em suma, um dos objetivos do estudo de tráfego é a obtenção da
quantidade de passageiros que o sistema de elevadores precisa transportar em 5 minutos, ou
seja, a qualidade de transporte necessária, bem como a direção predominante do tráfego: para
cima, para baixo ou misto.

15

Outro objetivo do estudo de tráfego é determinar a qualidade de serviço necessária
para o prédio. Estudos e observações realizados ao longo dos anos têm mostrado que os
passageiros se tornam impacientes depois de aguardar 30 segundos pelo elevador em prédios
comerciais e 60 segundos em prédios residenciais (STRAKOSCH, 1998). Logo esses são
bons parâmetros de qualidade de serviço. Porém, outros valores menores podem ser exigidos
devido a características funcionais do prédio, normas, ou por exigência dos clientes
(construtora ou administradora do prédio).

2.3.2 Cálculo de Tráfego
A qualidade de transporte e a qualidade de serviço requeridas, que foram obtidas no
estudo de tráfego, servem de entrada para o cálculo de tráfego. O cálculo de tráfego consiste
no uso de um modelo matemático (fórmulas e tabelas) para auxiliar na obtenção da apropriada
quantidade, velocidade e tamanho dos elevadores.
As fórmulas e tabelas utilizadas no cálculo de tráfego são o resumo do desempenho da
tecnologia da elevação existente (fatores de tempo e carga, principalmente) e do
comportamento da população de passageiros diante desta tecnologia. Essas tabelas e fórmulas
permitem o cálculo do desempenho de um sistema de elevadores proposto. Este modelo é
resultado de anos de observação do comportamento real da população de passageiros de
diversos edifícios e da sumarização de dados estatísticos.
Os passos para a determinação de uma solução de através do cálculo de tráfego são os
seguintes:
1. Propor uma configuração de elevador (velocidade, largura de porta, capacidade);
2. Calcular o tempo de viagem (tempo para que o elevador leva para ir do saguão até o
mais alto piso e retornar). Diversos fatores de tempo são considerados como as
características dos pavimentos do edifício, paradas prováveis, tempo de
transferência de passageiros entre a cabine e os pavimentos, fatores de ineficiência
e outros, além da configuração do elevador indicada no passo 1.
3. Cálculo da quantidade de elevadores necessária para atender à qualidade de
transporte exigida no estudo de tráfego.
4. Cálculo da qualidade de serviço obtida.
5. Se a solução não atende à qualidade de serviço exigida, deve-se voltar ao passo 1
redefinindo a configuração do elevador. Se a solução e além do esperado, pode-se
voltar ao passo 1 utilizando-se uma configuração de elevador mais modesta visando
obter a solução com a melhor relação custo/benefício.
Claro que para fins didáticos, foi feita uma simplificação dos passos mencionados
acima. A aplicação correta do modelo para cálculo depende não só de conhecimento
matemático, mas de conhecimento teórico sobre elevação. Por exemplo, para aumentar a
qualidade de serviço, não se deve aumentar a capacidade do elevador, e sim diminuí-la,
aumentando por conseqüência o número de elevadores, o que produz um menor tempo de
espera do passageiro.
O resultado do cálculo de tráfego para um prédio em construção é um argumento
sólido para justificar a adoção de uma determinada solução, pois é baseado num modelo
matemático, racional, fruto de anos de estudo da elevação, sendo a principal ferramenta para
encontrar o equilíbrio entre economia e qualidade.

16

2.4 NECESSIDADES DA ÁREA DE PESQUISA E DESENVOLVIMENTO
O modelo matemático citado na engenharia de elevação na seção anterior é
perfeitamente adequado para cálculo de tráfego, que por sua vez é empregado principalmente
pela área de vendas de elevadores novos e modernizações de elevadores existentes. A área de
pesquisa e desenvolvimento de tecnologias para elevação também precisa de um modelo que
reflita o comportamento de uma solução de elevadores frente a uma população de passageiros.
Uma idéia seria aproveitar o modelo matemático do cálculo de tráfego. Porém, os objetivos e
necessidades do estudo da elevação são diferentes dos da área de pesquisa e desenvolvimento,
embora sejam relacionados. Quando o modelo do cálculo de tráfego é aplicado com o enfoque
de pesquisa e desenvolvimento de novas tecnologias de elevação, muitas necessidades não são
atendidas.
O modelo usado no estudo da elevação está apoiado nas características e limitações
das tecnologias existentes e altamente consolidadas, o que diverge do objetivo de estudo da
utilização de uma nova tecnologia para melhorar a vazão do tráfego. Uma nova tecnologia
pode ter características bem diferentes das atualmente utilizadas, não sendo facilmente
acomodada no cálculo, como é a diminuição de um fator de tempo, por exemplo. Em certos
casos, a aplicação de novas tecnologias muda até mesmo o comportamento da população de
passageiros. Seria necessária uma certa flexibilidade do modelo para permitir tal estudo.
Outra limitação ao se usar este modelo é a sua linearidade: muitos comportamentos da
população de passageiros foram sumarizados em um comportamento médio estatístico. Tal
linearidade é útil para o cálculo através de fórmulas e tabelas, mas não deixa margem para a
observação de como o comportamento individual dos passageiros afeta de modo geral o
desempenho do sistema de elevadores. O que se tem é um “aplainamento” de algo que na
verdade é “irregular”.
Com o atual modelo, é difícil avaliar como o comportamento da população de
passageiros é afetado frente a uma nova situação, como um dispositivo de chamada com
comportamento diferenciado, ou presença ou ausência de indicadores no pavimento. Este
modelo não pode responder a muitas perguntas do tipo “se isso fosse assim, o que
aconteceria?”. Certas mudanças tecnológicas nem sequer são físicas, como, por exemplo,
otimizações e mudanças nos algoritmos de atendimento de chamadas.
Essas limitações acontecem porque os objetos do mundo real (populações de
passageiros e sistema de elevadores) foram transformados em abstrações matemáticas
contendo somente os pontos de interesse do cálculo de tráfego. Para a área de pesquisa e
desenvolvimento seria necessário um trabalho semelhante: criar um modelo específico, que
atenda às necessidades da área de pesquisa e desenvolvimento, a partir dos objetos do mundo
real. Uma alternativa é colocar o comportamento desses objetos dentro de um simulador ao
invés de dentro de tabelas e fórmulas.

3 SIMULAÇÃO
Segundo Perin Filho (1995, p. 17), existem, de modo geral, três estratégias de
resolução de problemas: experimentação direta, resolução analítica e simulação. A
experimentação direta consiste em fazer experimentos diretamente no sistema real para tentar
encontrar a melhor solução por tentativa e erro. Por sua vez, a resolução analítica consiste em
construir um modelo analítico e aplicar um método matemático para obter a melhor solução
para o problema. Já na simulação de sistemas, experimentos são feitos para tentar encontrar a
melhor solução por tentativa e erro, como na experimentação direta, porém não no sistema
real, e sim, em um modelo.

3.1 CONCEITO
Na língua portuguesa, simular significa representar com semelhança, fingir, aparentar.
Na engenharia, o termo tem sido usado para se referir a situações nas quais se tenta
compreender as características de um sistema pelo estudo de outro que lhe é similar.
Como processo, a simulação consiste na observação ao longo do tempo do
desempenho de um modelo que representa um sistema definido a partir de um problema a ser
resolvido. O modelo é usado como uma ferramenta de experimentação que, através de
tentativa e erro, permite comparar diversos cenários, cada um representando uma política de
operação do sistema, uma configuração do sistema ou uma solução do problema original.
Prado (2004, p. 95) possui um conceito de simulação mais próximo ao tema deste
trabalho uma vez que se refere à simulação informatizada: “Simulação é a técnica de solução
de um problema pela análise de um modelo que descreve o comportamento do sistema usando
um computador digital”.
Diferentes fatores podem levar ao uso da simulação ao invés da experimentação direta:
• Tempo: o computador pode realizar rapidamente experimentos que no sistema
real consomem anos;
• Custo: cada experimentação no sistema real é muito dispendiosa;
• Impossibilidade de experimentação direta: experimentações no sistema real não
podem ser realizadas por questões de segurança (como oferecer perigo para seres
humanos ou para o meio ambiente), de acesso ou ainda inexistência (o sistema
está em construção ou sendo estudada a construção);
• Visualização: computadores permitem uma fácil visualização dos resultados, o
que é importante no processo de tomada de decisões;

18

• Repetição: dificilmente experiências no sistema real podem ser repetidas para uma
observação mais detalhada do seu comportamento, porém, isso é realizado de
modo fácil na simulação realizada por computador.

3.2 METODOLOGIAS
Para implementar um sistema de simulação, basicamente três orientações são
possíveis:
• Orientado para atividades;
• Orientado para eventos;
• Orientado para objetos.
Na programação orientada para atividades, a forma de controle do tempo de simulação
se dá através da divisão do tempo total de simulação em intervalos menores e de mesmo
tamanho. A simulação é realizada em cada intervalo. Assim, o “relógio” sofre incrementos
regulares e, a cada passagem de tempo, é feita uma varredura em todas as atividades da
simulação para atualização das variáveis de estado.
Já a orientação para eventos normalmente utiliza-se de um relógio que é incrementado
com o valor necessário para a chegada do tempo do próximo evento de interesse da
simulação. Dessa forma, o tempo não passa de forma linear, mas sim aos saltos, passando
somente pelos momentos de valor para a simulação (eventos). Esta técnica de controle do
relógio economiza recursos computacionais.
A programação de simulação orientada para objetos, de certa forma, constitui uma
combinação e generalização das duas orientações anteriores. Nesta orientação, as entidades de
interesse da simulação são transformadas em objetos, incorporando além dos dados
correspondentes aos seus atributos os procedimentos computacionais relacionados às suas
atividades. Pode ser aplicada tanto uma técnica de controle do relógio quanto outra ou, até
mesmo, uma mista.

3.3 FERRAMENTAS EXISTENTES
Existem no mercado programas de simulação com enfoque de aplicação a
determinadas áreas. O programa Arena da empresa Rockwell Automation, por exemplo,
permite a simulação de processos de negócio, como serviços de atendimento ao consumidor,
logística de distribuição de materiais e produtos, processos de manufatura e armazenagem,
etc. (ROCKWELL AUTOMATION, 2005). As simulações deste programa variam desde a
animação de um fluxograma até a geração de imagens de três dimensões, dependendo da
distribuição. A Figura 1 exibe a execução da simulação de um processo de manufatura no
aplicativo.

19

Figura 1 – Simulação de um processo de manufatura com o programa Arena

Outro programa de simulação disponível no mercado é o Vensim da empresa Ventana
Systems. Este programa é mais genérico porque trabalha com fórmulas matemáticas, podendo
simular qualquer coisa que possa ser representada por fórmulas. Ele permite criar e interligar
diferentes fórmulas, variáveis de entrada e variáveis de saída, e durante a simulação,
representa graficamente as saídas que foram calculadas com base em valores fornecidos pelo
usuário (VENTANA SYSTEMS, 2005). Na Figura 2 apresenta-se um exemplo de uso desta
ferramenta para a modelagem de um sistema condicionador de ar com apresentação de custos
(SGRILLO, 2003). Este modelo foi criado por Ricardo Sgrillo, professor da Universidade
Estadual de Santa Cruz.

20

Figura 2 – Modelo de condicionador de ar com o programa Vensim

Todos estes programas têm um certo grau de generalidade para poderem ser aplicados
a diferentes domínios de problema. Com uma maior gama de aplicação, a quantidade de
possíveis clientes aumenta. Porém essa generalidade sacrifica em certo grau a fidelidade, a
riqueza e o detalhamento da simulação para um domínio específico, e, por conseqüência, o
valor da simulação em si para o usuário. Uma analogia pode ser feita com uma planilha
eletrônica: ela é útil para uma grande variedade de aplicações, como planejamentos,
orçamentos, relatórios; mas seria genérica demais para controlar o estoque de um
supermercado, embora seja possível. De acordo com a singularidade do domínio do problema,
o ideal é se utilizar um programa especialmente elaborado para resolver este problema, na
analogia, um programa de controle de estoque.
Acredita-se ser este o caso do estudo da elevação com o enfoque de pesquisa e
desenvolvimento de novas tecnologias: o mais valoroso para o usuário seria uma ferramenta
especializada na simulação de elevadores, que atenda aos seus objetivos específicos deste
domínio.

4 PROJETO DA FERRAMENTA
Considerando-se a necessidade levantada nos capítulos anteriores, foi proposto o
desenvolvimento de uma ferramenta de simulação para atendê-la. Nesta ferramenta, o usuário
entra com a população de passageiros (suas características, quantidade, posição, direção de
tráfego dominante, etc.) e com o sistema de elevadores (quantidade, velocidade, capacidade,
largura de porta, lógica de atendimento, etc.), e então executa a simulação. A população de
passageiros passa a interagir com o sistema de elevadores visando chegar no seu andar de
destino. No decorrer da simulação, dados sobre o desempenho da solução são coletados. A
simulação é apresentada como uma animação para o usuário, ajudando na observação do
comportamento da solução.
O projeto da ferramenta foi baseado nas fórmulas e tabelas do cálculo de tráfego,
visando extrair dali o comportamento dos objetos do mundo real; comportamento esse que foi
resumido para fins de cálculo. Com um objeto simulado que apresenta o comportamento
definido no cálculo de tráfego, que por sua vez foi baseado no mundo real, tem-se a
possibilidade de experimentar esse objeto contra novas situações e verificar qual o resultado,
servindo de base para o estudo do emprego de novas tecnologias aplicadas à elevação e
experimentação de diferentes alternativas de projeto.

4.1 MOTIVAÇÃO
Os profissionais da área de pesquisa e desenvolvimento de tecnologias para a elevação
(normalmente engenheiros eletricistas e engenheiros mecânicos) possuem muitas ferramentas
específicas para a sua área técnica, como programas de CAD (Computer Aided Design) para
desenho de circuitos e peças, simuladores de circuito, compiladores e editores de código-
fonte. Porém para trabalho de mais alto nível e multidisciplinar, a quantidade é bem menor.
Diferente da área de informática, que possui, por exemplo, diversas ferramentas CASE
(Computer Aided Software Engineering). Acredita-se que a ferramenta proposta seja uma
ferramenta de alto nível que venha a auxiliar estes profissionais no seu trabalho.
Uma ferramenta de simulação libera o usuário para a experimentação de novas idéias,
incitando a criatividade. Das idéias criativas é que nascem as novas tecnologias que mais cedo
ou mais tarde passam a fazer parte do cotidiano das pessoas. Espera-se que com essa
ferramenta haja um aumento na produtividade dos estudos de pesquisa e desenvolvimento de
tecnologia para a elevação, o que indiretamente contribui para a vida da população em geral.

22

Esta ferramenta pode não só ajudar no desenvolvimento de novas tecnologias, como
também ajudar a justificar a aplicação de soluções já em campo, elucidando por que
determinadas alternativas de projeto foram descartadas e a atual foi utilizada. Pode até mesmo
vir a ser usada como uma ferramenta didática, exemplificando conceitos e auxiliando na
introdução de profissionais leigos na área de elevação.

4.2 OBJETIVOS
Os seguintes objetivos integram o projeto de desenvolvimento da ferramenta:
• Simular fielmente a população de passageiros:
1. O passageiro simulado deve ter um comportamento humano, agindo com
características inteligentes (por exemplo, trocando informações com o sistema
de elevadores, verificando se a cabine não está lotada antes de entrar, etc.);
2. Deve ser possível configurar a população para gerar uma situação de tráfego
específica em termos de quantidade e direção, como, por exemplo, tráfego
predominantemente para baixo;
3. O programa deve auxiliar o usuário, se este desejar, a configurar uma
população de passageiros com base em informações de mais alto nível, como,
por exemplo, “o prédio é um hospital de 200 leitos”;
• Simular o sistema de elevadores da forma mais independente possível da
implementação de hardware e software:
- O sistema de elevadores deve ter tal nível de abstração que permita simular
soluções com qualquer um dos dispositivos existentes e até com os que não
existem (não implementados ou nem mesmo pesquisados);
- Não deve haver apego às limitações da tecnologia atual como, por exemplo,
velocidade máxima alcançada, deixando a cargo do usuário configurar o
sistema como desejar;
• Definir um conjunto de classes coerente e consistente para que a lógica de
atendimento possa atuar:
- Devem ser suficientes para que a lógica realize a sua função;
- Deve haver um baixo nível de acoplamento entre sistema de elevadores e a
lógica de atendimento. Isso permite implementar uma variedade de lógicas de
atendimento diferentes e intercambiáveis;
- Essa base servirá para que futuramente um editor de lógicas de atendimento
seja acrescentado ao simulador;
• Primar por um baixo acoplamento entre os objetos da simulação e a camada de
apresentação visando futuramente melhorá-la, talvez utilizando um motor de
imagens tridimensionais como DirectX ou OpenGL.
• Validação através da comparação do comportamento da simulação com o cálculo
de tráfego: os dois devem produzir resultados convergentes já que são modelos
diferentes do mesmo objeto.
Esse trabalho é considerado um protótipo porque algumas das funcionalidades
desejadas para um produto final não serão implementadas por questão de tempo, como, por
exemplo, um editor de lógicas de atendimento (mencionado anteriormente), para que o
próprio usuário possa testar uma nova forma de atender as chamadas dos passageiros. Porém,
todo o trabalho será realizado visando uma base sólida para a futura completude e
amadurecimento dessa ferramenta.

23

4.3 METODOLOGIA ADOTADA
Foi escolhida a abordagem de análise e projeto orientados a objetos devido às suas
inúmeras vantagens. Para apoiar esse paradigma de desenvolvimento de sistemas, foi tomada
como base a metodologia Processo Unificado. Esta metodologia se vale da UML (Unified
Modeling Language) como notação diagramática.

4.3.1 Orientação a Objetos
Há muito tempo a análise e projeto de software orientado a objetos deixou de ser uma
novidade ou tendência. Atualmente, a sua aplicação está muito bem difundida e consolidada
no mercado de desenvolvimento de sistemas de informação.
A visão tradicional no desenvolvimento de software adotava a perspectiva de um
algoritmo. Nessa visão, o principal bloco de construção do software é o procedimento ou
função. Essa perspectiva conduz os desenvolvedores a voltarem o seu foco de atenção para
questões referentes ao controle e à decomposição de algoritmos maiores em outros menores.
Não existe nenhuma grande desvantagem nessa solução, com exceção da tendência a permitir
sistemas instáveis. À medida que os requisitos se modificam (e isso certamente ocorrerá) e o
sistema cresce (o que também acontecerá), será difícil fazer a manutenção de sistemas
construídos a partir do foco em algoritmos.
A visão contemporânea do desenvolvimento de sistemas de informação adota uma
perspectiva orientada a objetos. Nessa visão, o principal bloco de construção do sistema é o
objeto ou a classe. De forma simplificada, pode-se dizer que uma classe é especificação de
como se constituem e de como se comportam todos os objetos criados como sendo
pertencentes a esta classe. Um objeto contém dados (variáveis) e operações (funções). Uma
das principais características de um sistema orientado a objetos é que a sua estrutura tende a
refletir a estrutura de objetos de negócio do mundo real, facilitando a comunicação entre
analistas e usuários. Além disso, o desenvolvimento orientado a objetos favorece a
reutilização, facilita a extensão e manutenção dos sistemas. Com a orientação a objetos,
mesmo os problemas mais complexos não se tornam intratáveis.

4.3.2 Processo Unificado
O desenvolvimento desse projeto será baseado parcialmente na metodologia chamada
Processo Unificado, que fornece uma abordagem para a construção de sistemas orientados a
objetos. O Processo Unificado pode ser considerado o antecessor do RUP (Rational Unified
Process), o processo de desenvolvimento de software da empresa Rational; o RUP é um
refinamento do Processo Unificado (LARMAN, 2004). O termo “parcialmente” foi utilizado
porque não é pretendida uma execução exata do Processo Unificado, ele será a principal base
mas também serão aplicados conceitos de outras metodologias que forem consideradas
convenientes, como, por exemplo, da metodologia Objectory.
Dentre as características do Processo Unificado, está o esforço inicial em construir
uma arquitetura central e coesa. Logo no começo é definida uma “espinha dorsal” da
arquitetura, focalizando uma implementação ampla e rasa, estabelecendo os temas principais
do projeto e os subsistemas com suas interfaces e responsabilidades.
Outra prática do Processo Unificado é a modelar visualmente o sistema. Uma
porcentagem extraordinária do cérebro humano está envolvida com o processamento visual.

24

Portanto, as pessoas não têm somente habilidade em empregar linguagens textuais (como
prosa ou código), mas também linguagens visuais espaço-orientadas, icônicas, diagramáticas
como UML, porque isto explora as forças naturais do cérebro. Além disso, a abstração é uma
prática útil ao refletir sobre projetos de software e ao comunicá-los, porque permite focalizar
aspectos importantes, enquanto esconde ou ignora detalhes ruidosos. Uma linguagem visual
como a UML permite visualizar e raciocinar a respeito de modelos abstratos de software,
movendo-se rapidamente dos esboços diagramáticos das grandes idéias para o projeto
(LARMAN, 2004).

4.3.3 UML
A UML tem sido amplamente difundida no meio do desenvolvimento de software e é
apoiada por muitas ferramentas CASE, além de ser a linguagem-padrão de modelagem do
OMG (Object Management Group) desde 1997, e desde então tem sido aprimorada por esta
organização (BOOCH, RUMBAUGH e JACOBSON, 2000). UML pode ser empregada para
visualização, especificação, construção e documentação de artefatos de sistemas orientados a
objetos.
Linguagens fornecem um vocabulário e as regras para a combinação das palavras
desse vocabulário com a finalidade de comunicar algo. Da mesma forma, a UML contém um
conjunto de símbolos gráficos, cada um com uma semântica bem definida. Isso visa
minimizar a possibilidade de ambigüidades na interpretação de um modelo. Dessa forma, o
modelo elaborado por um desenvolvedor pode ser lido por qualquer outro (ou por uma
ferramenta CASE) com facilidade de comunicação de idéias sobre o sistema que está sendo
modelado.
UML é apenas uma linguagem, ou notação, sendo, portando somente uma parte do
processo de desenvolvimento de sistemas de software. A UML é independente de
metodologia. Qualquer metodologia de desenvolvimento de sistemas que seja orientada a
objetos pode aplicar a UML perfeitamente para modelagem e documentação.

4.4 RECURSOS EMPREGADOS
Para a modelagem do sistema será empregada a ferramenta CASE Jude, e para a
implementação a linguagem Visual Basic.Net. Ambos serão detalhados a seguir.

4.4.1 Modelagem
Existem diversas ferramentas CASE que suportam UML. Entre elas está o aplicativo
Jude, desenvolvido pela empresa Eiwa System Management. Esta empresa distribui o
aplicativo em duas versões: a Community, que á gratuita; e a Professional, que é paga. A
versão paga possui suporte a outros tipos de digramas que não fazem parte da UML, como
mapas mentais, além de outros recursos adicionais, como a possibilidade de criação de
hiperligação entre diagramas (EIWA SYSTEM MANAGEMENT 2005).
Esta não é uma das ferramentas mais maduras e completas do mercado, mas tem a seu
favor uma interface com o usuário simples e familiar, além de relativa rapidez se comparada
com outras ferramentas deste estilo construídas em Java. Como qualquer aplicativo construído
em Java, Jude requer que a Máquina Virtual Java esteja instalada no computador. Esta

25

ferramenta CASE faz engenharia reversa e engenharia de produção para a linguagem Java,
recurso este que não será utilizado, pois a linguagem selecionada para o projeto é outra.

4.4.2 Implementação
A linguagem de programação escolhida para implementar o software é Visual
Basic.Net da empresa Microsoft. Diferente da versão anterior, Visual Basic 6.0, esta
contempla uma quantidade bem mais abrangente de conceitos da programação orientada a
objetos, como, por exemplo, herança simples, interfaces, classes abstratas, polimorfismo, etc.,
sendo adequada às necessidades do software.
Esta linguagem faz parte de um conjunto de linguagens de programação da Microsoft
que, a partir desta versão, compilam para uma linguagem intermediária (ROMAN,
PETRUSHA e LOMAX, 2002), que por sua vez é executada por uma máquina virtual
chamada Framework.Net, de forma semelhante a linguagem Java. Porém, a máquina virtual
da Microsoft não é multiplataforma, funcionando apenas para o sistema operacional Windows
98 em diante. Uma iniciativa da comunidade de software livre começou a implementar uma
máquina virtual chamada Mono capaz de executar no sistema operacional GNU/Linux os
programas compilados para o Framework.Net.
O ambiente integrado de desenvolvimento utilizado será o Microsoft Visual Studio.Net
2002. Este ambiente, como outros do tipo, permite a edição do código-fonte auxiliada por
verificadores de sintaxe em tempo de digitação, compilação, depuração e distribuição do
programa.

5 DESENVOLVIMENTO DA FERRAMENTA
Nas seções seguintes, serão descritas as atividades realizadas e os produtos obtidos
durante o desenvolvimento do sistema de acordo com a definição apresentada no capítulo
anterior. É importante salientar que a ordem de apresentação dos produtos do
desenvolvimento não necessariamente reflete a ordem em que estes foram realizados, pois, na
metodologia adotada, muitas atividades ocorrem em paralelo, como, por exemplo, a
confecção simultânea e incremental dos diagramas de casos de uso, diagrama de pacotes e
diagrama de classes.

5.1 LEVANTAMENTO DOS CASOS DE USO
O diagrama de casos de uso da UML permite mostrar atores (entidades de fora do
sistema) utilizando o sistema de forma a produzir algum resultado observável e relevante do
ponto de vista do ator. No simulador de elevadores, o diagrama de casos de uso foi utilizado
para elucidar as tarefas que o usuário deseja executar no sistema, resultando na Figura 3.

27

Figura 3 – Casos de uso do sistema

O caso de uso “Simular” foi um dos primeiros a ser levantado por estar diretamente
ligado ao objetivo do sistema. Da mesma forma, o caso de uso “Comparar Simulações”.
Porém, para realizar estes casos, é necessário que o usuário realize outras tarefas, o que por
sua vez acarretou o descobrimento dos demais casos de uso. Cada caso é detalhado a seguir:

28

Quadro 1 – Detalhamento dos casos de uso do sistema
Caso de Uso Descrição
Construir Prédio O usuário define as características físicas de um prédio
ainda sem considerações sobre elevadores.
Construir População O usuário seleciona um prédio previamente construído e
cria para este uma faixa de tempo e uma população que
atua neste prédio durante esta faixa de tempo. O usuário
pode construir mais de uma população para o mesmo
prédio.
Construir Sistema de Elevadores O usuário seleciona um prédio previamente construído e
elabora para este uma solução de elevação, configurando
todas as características necessárias. O usuário pode
construir mais de um sistema de elevadores para o mesmo
prédio.
Construir Cenário O usuário seleciona um prédio previamente construído,
uma de suas populações, um dos seus sistemas de
elevadores e uma das lógicas de atendimento disponíveis
tornando esta seleção um cenário passível de simulação.
Simular O usuário seleciona um cenário previamente construído e
solicita o início da simulação. Ao final da simulação tem-se
um resultado.
Comparar Simulações O usuário seleciona dois ou mais cenários, que tenham sido
simulados ao menos uma vez, para confrontar seus
resultados.

Pela análise dos casos de uso, verificou-se uma dependência entre eles, de forma que
um não pode ser realizado sem que o outro tenha sido realizado anteriormente. A dependência
entre os casos de uso foi explicitada no diagrama da Figura 4. Na UML, a dependência entre
dois itens é representada por uma seta de ponta vazada e corpo tracejado. Esta dependência
foi utilizada para definir a ordem de realização dos casos de uso, sendo o “Construir Prédio” o
primeiro deles.

29

Figura 4 – Dependência entre os casos de uso

Na seção seguinte, encontram-se as classes que foram projetadas para, trabalhando em
conjunto, realizar os casos de uso.

5.2 PACOTES BÁSICOS
Na UML, um pacote serve para grupar itens afins. A metodologia Objectory prega a
divisão das classes em três tipos: entidades, limites (ou apresentação) e controladoras. A
organização de pacotes de classes adotada aqui foi inspirada nesta metodologia e é uma
solução que pode ser adotada em qualquer projeto, independente do domínio de problema.
Esta organização consiste em quatro pacotes básicos:
• Entidades – contém as classes relativas ao domínio do problema em questão. Por
exemplo, na modelagem de um sistema de vendas, este pacote é que deve conter
classes como Cliente, Produto, Cupom, etc. A principal responsabilidade destas
classes é representar as entidades pertencentes ao domínio do problema e a sua
lógica. De forma alguma as classes deste pacote podem conter lógica e serviços
relacionados à apresentação de informações, interface com o usuário ou
comunicação com o meio exterior ao sistema; estas responsabilidades devem ser

30

atribuídas às classes do pacote Apresentação. Estas classes normalmente se
relacionam entre si e com as classes do pacote Serviços somente.
• Controladores – estas classes coordenam atividades que normalmente possuem
algum estado envolvendo alguns objetos Entidade. Segundo o exemplo de um
sistema para vendas, uma classe controladora poderia ser CoordenadorVenda que
seria responsável pela realização de vendas no sistema. Ela conteria o estado da
venda corrente (esperando por produtos, esperando por pagamento, esperando por
autorização de crédito, etc.) e coordenaria a ação entre os diferentes objetos
entidades (cliente, produto, etc.). As classes controladoras dependem das classes
entidades e das classes de serviço. As classes controladoras também são
responsáveis por notificar os objetos que estejam interessados sobre alterações nos
objetos entidades.
• Apresentação – as classes deste pacote têm a responsabilidade de ser a interface
entre o sistema e os usuários que interagem com ele (normalmente pessoas, mas
podem ser também outros sistemas). Elas exibem as informações de objetos
entidade e controladores para os usuários, e também transmitem ao sistema
eventos que os usuários disparam. As classes de apresentação normalmente são
extensões de classes genéricas de interface gráfica com usuário e contêm
componentes como botões, listas e caixas de texto. Dependendo do sistema
modelado, não existe uma interface com o usuário tipo teclado e monitor, mas
mesmo assim são consideradas classes de apresentação as classes que fazem a
comunicação com o meio externo, como as classes que controlam dispositivos de
hardware (mostradores, luzes indicadoras, sensores, portas de comunicação, etc.).
As classes de apresentação dependem de todas as outras, pois exibem informações
sobre essas classes ou se utilizam dela de alguma maneira.
• Serviços – neste pacote, estão classes altamente genéricas que resolvem
problemas comuns que não são específicos de nenhum domínio. Por isso, essas
classes são altamente reutilizáveis entre diferentes sistemas. As classes mais
específicas (entidades, controladoras e de apresentação é que se valem delas para
sua própria implementação). O desenvolvedor, na maioria dos casos, não cria
muitas classes de serviço porque as plataformas de desenvolvimento já fornecem
uma grande quantidade delas prontas para serem utilizadas. Classes que servem de
interface entre o usuário e o sistema mas que ainda não foram personalizadas
(através de herança ou composição) para um domínio específico de problema são
consideradas como classes de serviço, como é o caso dos componentes de
interface gráfica como botão, caixa de texto, janela, etc.
O diagrama da Figura 5 mostra uma visão da organização dos pacotes básicos. Nos
diagramas UML, a representação gráfica do pacote é como uma pasta. Pacotes podem mostrar
dependências entre si, o que indica, na verdade, que alguns itens dentro de um pacote é que
têm alguma dependência com os itens dentro de outro pacote.

31

Figura 5 – Divisão básica das classes em pacotes

5.3 PACOTES ESPECÍFICOS DO SISTEMA
Seguindo a divisão de pacotes básica mencionada na seção anterior, durante o
levantamento dos casos de uso, foram encontrados conceitos relativos ao domínio que foram
modelados como entidades. Desta forma, o pacote Entidades foi o primeiro a ser “povoado”
com classes. No decorrer deste povoamento, observou-se que certas classes tinham grandes
afinidades e se dividiam em grupos bem distintos. Para representar essa característica do
domínio, foram criados subpacotes dentro do pacote Entidades. Esses pacotes são: Prédio,
Pessoa e Elevador.
O diagrama da Figura 6 exibe as relações de dependência entre esses pacotes. Nas
subseções seguintes, serão explorados cada um dos pacotes com suas devidas classes.

32

Figura 6 – Pacotes para agrupar três grupos bem distintos de entidades

5.3.1 Pacote Prédio
Este pacote contém todo o conjunto de classes necessárias para configurar um prédio
da simulação em termos das suas características físicas somente. Estas classes são totalmente
independentes da existência (ou não) de um sistema de elevadores para este prédio e da
configuração deste sistema. As classes deste pacote também não “tomam conhecimento” da
população que venha a habitar este prédio e suas características. O diagrama da Figura 7
mostra uma visão geral das classes do pacote.

Figura 7 – Visão geral das classes do pacote Prédio

A classe Predio foi criada mais por objetivos conceituais do que práticos, pois o seu
aspecto mais relevante é possuir um objeto da classe Pavimentos, que é uma coleção de
objetos Pavimento. O estereótipo “coleção” atribuído à classe Pavimentos foi utilizado ao
longo da modelagem em outras classes também, e significa que a classe coleciona objetos de
outra classe, geralmente a com cardinalidade zero ou muitos (0..*) no relacionamento. Em
termos de implementação, este estereótipo significa que a classe terá diversas operações
comuns a coleções, como obter um item, contar a quantidade de itens colecionados, remover
um item, criar um enumerador para que se possa iterar sobre os itens da coleção em um laço
(loop).
Pavimento é uma classe que possui como atributos nome e altura. Geralmente, o valor
de nome corresponde ao seu índice em relação aos outros pavimentos, mas em certos prédios,
alguns pavimentos têm nomes diferentes, como, por exemplo, o primeiro pavimento ser

33

chamado de “T” de térreo ou “P” de piso. As alturas dos pavimentos de um prédio muitas
vezes não são iguais, existem alguns pavimentos mais altos, principalmente o térreo. Isto,
mais tarde, irá influenciar na simulação do sistema de elevadores.

5.3.2 Pacote Pessoa
Todas a classes referentes à população de passageiros que passará pelo prédio durante
a simulação estão neste pacote. Como mostrado no diagrama de pacotes dos três grupos de
entidades encontrados na modelagem, as classes de Pessoa têm uma dependência com as
classes do pacote prédio. E isto é natural se for analisado que as pessoas caminham pelo
prédio; as pessoas estão assentadas sobre o prédio; as pessoas usam o prédio. E como isto
acontece depende das características físicas do prédio.

5.3.2.1 População Programada
No mundo real, em dados instantes de tempo, pessoas chegam ao sistema de
elevadores com a necessidade de serviço de transporte. Esta necessidade surge pelo fato da
pessoa estar em um pavimento, mas o pavimento que ela deseja ou precisa estar é outro acima
ou abaixo. Na simulação, o usuário define uma faixa de tempo que será simulada e deve
programar a chegada de pessoas dentro dessa faixa de tempo, sendo que cada pessoa está em
um pavimento e tem como destino outro pavimento. Para realizar essas atribuições, foram
projetadas as classes ilustradas no diagrama abaixo.

Figura 8 – Programação da população de passageiros

O objeto PopulacaoProgramada possui a definição de uma faixa de tempo e também
coleciona objetos Chegadas, sendo que cada objeto Chegadas está associado a um instante de
tempo dentro desta faixa. Um objeto Chegadas, por sua vez, coleciona objetos Chegada,

34

sendo cada objeto Chegada associado a um pavimento do Prédio ao qual a
PopulacaoProgramada pertence. Um objeto Chegada coleciona objetos Pessoa, ou seja,
Chegada contém as pessoas que chegarão no sistema de elevadores a partir do pavimento ao
qual Chegada está associado. Verificando a conexão dos objetos até agora, têm-se a
possibilidade de programar nesta estrutura pessoas que chegam para solicitar serviço de
transporte vertical em um dado instante de tempo a partir de um dado pavimento. Falta a
programação de para onde essas pessoas desejam ir.
Para implementar o pavimento destino das pessoas, a classe Pessoa está associada a
uma classe Destinos, que é uma coleção de objetos Destino. Um objeto Destino nada mais é
que um Pavimento e um tempo de permanência deste pavimento. Isto possibilita que uma
pessoa tenha mais de um pavimento destino dentro prédio, o que a faria usar o sistema de
elevadores mais de uma vez, de acordo com o programado.

5.3.2.2 Geradores de População
O modelo de população programada mostrado anteriormente representa
adequadamente a realidade e permite criar qualquer tipo de população real no ambiente
simulado. Porém, este modelo tem uma granularidade muito fina, pois tem um objeto Pessoa
para cada pessoa que compõem a população de passageiros. O usuário do simulador perderia
muito tempo se tivesse que configurar no software cada uma desses objetos Pessoa para criar
a população desejada. Além disso, cada pessoa pode ter múltiplos destinos. A solução para
esse problema foi a criação de um gerador de população programada. Esse gerador é um
objeto da classe GeradorPopulacao que recebe uma parametrização de valores inteiros sobre a
população de passageiros desejada e, quando invocada determinada operação, cria uma
população programada com base nesses valores. Na implementação dessa classe
GeradorPopulacao, devido a problemas no andamento do projeto, foi assumido com o
objetivo de simplificação que uma pessoa tem apenas um destino. Isto não foi feito pela
remoção do suporte da pessoa a múltiplos destinos. As pessoas somente não serão
configuradas com múltiplos destinos. A implementação da simulação da pessoa foi realizada
com suporte a múltiplos destinos.
As Tabelas 1 e 2 ilustram como a classe GeradorPopulacao, que internamente tem uma
estrutura semelhante, é parametrizada com valores numéricos e a partir destes gera a
população de passageiros programada. As colunas representam os pavimentos de um prédio e
as linhas, os instantes de chegadas de pessoas. As células contêm a quantidade de pessoas que
chegam no instante indicado na linha e no pavimento indicado na coluna.

Tabela 1 – Programação de Origens
Pav. 1 Pav. 2 Pav. 3 Pav. 4 Pav. 5 Pav. 6
15/10/2005 08:00:00 6 5 5 4 5 6
15/10/2005 08:01:00 0 4 4 5 2 4
15/10/2005 08:02:00 2 4 0 5 4 4
15/10/2005 08:03:00 3 3 2 6 2 1

35

Tabela 2 – Programação de Destinos
Pav. 1 Pav. 2 Pav. 3 Pav. 4 Pav. 5 Pav. 6
15/10/2005 08:00:00 25 2 0 2 1 0
15/10/2005 08:01:00 4 7 8 1 2 4
15/10/2005 08:02:00 15 1 0 0 2 4
15/10/2005 08:03:00 5 4 6 4 4 5

O gerador de população facilita a criação de uma população programada de maior
volume, porém, mesmo assim, ela se torna pouco prática quando o usuário já possui uma
quantidade de pessoas definida (vinda de alguma estimativa ou é um dado real de um prédio).
Nesse caso o usuário é que teria que calcular a divisão apropriada da quantidade entre os
tempos e pavimentos. Para tornar facilitada a geração de uma população a partir de uma
quantidade de pessoas já definida, foi criada a classe GeradorPopulacaoRelativo. Esta classe
recebe como parâmetros uma quantidade absoluta de pessoas e a distribuição dessas pessoas
no tempo (instante de chegada) e espaço (pavimento). Essa distribuição é passada para a
classe através de porcentagens. Uma vez parametrizada, a classe pode criar, através da
chamada de uma operação, um objeto GeradorPopulacao visto no parágrafo anterior e este por
sua vez é que irá gerar a população programada, como indicado no diagrama da Figura 9.

Figura 9 – Relação entre geradores de população e população programada

Os passos para configurar um gerador de população relativo são os seguintes:
1. Informar a quantidade absoluta de pessoas;
2. Definir a distribuição dessas pessoas no tempo através de porcentagens;
3. Para cada chegada, definir a distribuição das pessoas daquele instante de chegada
nos pavimentos através de porcentagens.
Como já foi mencionado, o gerador de população relativo trabalha com porcentagens,
e a sua estrutura interna é semelhante às Tabelas 3 e 4:

36

Tabela 3 – Distribuição de pessoas no tempo
Tempo Pessoas (%)
15/10/2005 08:00:00 55
15/10/2005 08:01:00 30
15/10/2005 08:02:00 15
15/10/2005 08:03:00 0

Tabela 4 – Distribuição de pessoas nos pavimentos num dado instante
Pavimento Origem (%) Destino (%)
1 100 0
2 0 20
3 0 20
4 0 20
5 0 20
6 0 20

Essas camadas afastam o usuário de necessidade de ter que lidar com uma quantidade
muito grande de pequenos objetos, facilitando a sua tarefa, mas, em contrapartida, tiram do
usuário a possibilidade de detalhamento. O ideal seria que o aplicativo permitisse a edição nos
diferentes níveis de detalhe, como o usuário desejar. Por exemplo, o usuário poderia
programar usar o gerador de população relativo para rapidamente configurar grande parte da
população, em seguida, criar o gerador de população e então ajustar nele alguns detalhes,
depois criar a população programada e, se necessário configurar alguma pessoa específica.

5.3.2.3 Usos de um Prédio
A função que é desempenhada em um espaço físico influencia na quantidade de
pessoas que freqüentarão este espaço. Com base nisso, é possível estimar populações para
futuras edificações se é sabido de antemão o uso das áreas em questão. O simulador fornece
ao usuário um assistente para estimar a população de um prédio a partir do uso das áreas.
Transpostas para o projeto, estas relações se tornaram classes como indicado no diagrama da
Figura 10.

37

Figura 10 – Classes que representam relação entre uso e população estimada

A interface IUsoPredio define as operações que são desejadas para um objeto que
pode calcular uma população estimada. Outras classes realizam essa interface, porém cada
classe com a sua própria lógica de cálculo. A principal operação é getTotal, que é justamente
a quantidade de pessoas resultante do cálculo. Para efetuar o cálculo, cada classe tem
parâmetros específicos que o usuário irá informar. Por exemplo, UsoEscritorio precisa apenas
da área para calcular a população, já UsoApartamento precisa da quantidade de apartamentos,
a quantidade de dormitórios por apartamento e se existe ou não dormitório de empregada. A
interface IUsoPredio é bem simples e é mostrada no código-fonte que segue.

Public Interface clsIUsoPredio
Function getTipo() As String
Function getDescricao() As String
Function getTotal() As Integer
Function clona() As clsIUsoPredio
End Interface
Figura 11 – Definição da interface IUso

A classe UsosPredio coleciona qualquer objeto que realize a interface IUsoPredio. Ela
representa os diferentes usos de um prédio específico e tem operações que normalmente são
implementadas pela iteração pelos seus itens IUsoPredio, como, por exemplo, a obtenção do
total de pessoas estimadas com base nos usos do prédio. Esta operação tem o código-fonte
exibido a seguir.

38

Public Function getTotal() As Integer
Dim Valor As Integer
Dim i As clsIUsoPredio

For Each i In Me
Valor = Valor + i.getTotal
Next

Return Valor
End Function
Figura 12 – Operação da classe UsosPredio que obtem o total de pessoas

Existem duas classes de uso do prédio que não são realmente cálculos de estimativa, e
sim serviços auxiliares para o usuário. Uma dessas classes é ValorDireto. Ela permite que o
usuário entre com uma quantidade de população diretamente, sem nenhum cálculo, e é usada
quando o usuário sabe qual é a quantidade de pessoas ou estimou a quantidade de outro modo
que não pelo programa. Além da quantidade o usuário pode opcionalmente entrar também
com uma descrição para identificar a origem da quantidade por exemplo.
A outra classe é RelacaoValor. Ela faz um cálculo simples de multiplicação de uma
quantidade de unidades por uma quantidade de pessoas, sendo que essas duas informações são
dadas pelo usuário. Como foi dito, esse cálculo é muito simples e o próprio usuário poderia
fazê-lo até mentalmente, mas a presteza dessa classe não é realizar o cálculo para o usuário e
sim, servir para documentar como o cálculo foi feito, para que, por exemplo, outro usuário
abra o arquivo realizado por outro e entenda qual a relação adotada no cálculo e até mesmo
possa alterar a quantidade de unidades. O usuário pode definir um nome para a unidade.
Assim, é possível o usuário criar uma relação tipo: são 4 equipes de desenvolvimento de
software, 10 pessoas por equipe, total de 40 pessoas.

5.3.3 Pacote Elevador
Este pacote contém as classes responsáveis pela solução de elevação para um prédio.
Primeiramente, será apresentada uma visão geral das classes do pacote e, posteriormente, um
aprofundamento sobre lógica de atendimento de chamadas de passageiros.

5.3.3.1 Visão Geral das Classes do Pacote
Algumas dessas classes se relacionam com outras do pacote Prédio, isso ocorre já que
um sistema de elevadores está instalado em um prédio, e precisa de informações sobre esse
prédio para funcionar. No diagrama da Figura 13, está uma visão geral das classes e suas
relações.

39

Figura 13 – Visão geral das classes do pacote Elevador

As classes Predio, Pavimentos e Pavimento que aparecem no diagrama pertencem ao
pacote Prédio. O papel de cada classe do pacote Elevador é demonstrado a seguir:
• SistemaElevadores – é a classe que representa toda uma solução de elevação,
servindo de “raiz” para as demais. Ela se relaciona com uma lógica de
atendimento que controla a forma como o sistema despacha as chamadas dos
passageiros. Possui uma coleção de elevadores. Contém configurações gerais do
sistema como, por exemplo, capacidade de cabine, sendo que normalmente
repassa essas configurações aos objetos interessados (objetos cabine, no caso
citado).
• Elevadores – agrega os elevadores de um sistema de elevadores.
• Elevador – é um par poço e cabine, geralmente possui um nome identificador
embora quase nunca o passageiro tenha essa informação.
• Poco – representa o poço por onde a cabine corre. Estende-se ao longo dos
pavimentos e possui configurações individuais por pavimento que são
representadas pela classe PavimentoElevador, classe essa que o poço coleciona.
• PavimentoElevador – contém qualquer configuração individual por pavimento
que o poço precisa manter. Atualmente, esta classe só contém a informação sobre
a existência ou não de uma porta de pavimento, mesmo assim, foi decido projetar
poço como uma coleção de PavimentoElevador ao invés de uma coleção de
valores booleanos (tem porta de pavimento ou não) visando acomodar melhor
alterações e expansões que venham a surgir. Caso apareça uma nova configuração
de pavimento, basta acrescentá-la na classe PavimentoElevador.

40

• Cabine – transporta as pessoas. Contém toda a lógica de controle de movimento
para subir e descer e de transferência de pessoas (entrada e saída). Possui também
subcomponentes como a sua porta, que é um objeto do tipo PortaCabine.
• PortaCabine – basicamente controla a abertura e fechamento. Todas as demais
características da porta de cabine que são comuns a todas as portas de cabine estão
em uma classe separada chamada TipoPortaCabine, e porta de cabine mantém
uma referência para um objeto deste tipo.
• TipoPortaCabine – contém as características de um tipo de porta de cabine.
Estas características dizem respeito às dimensões da porta, velocidade de abertura,
velocidade de fechamento, etc.
• ILogicaAtendimento – é uma interface que define o que é esperado de um
algoritmo de atendimento de chamadas de passageiros, também conhecido como
algoritmo de despacho de chamadas. Outras classes é que irão realizar essa
interface, sendo que cada classe pode implementar sua própria estratégia de
atendimento.

5.3.3.2 Lógica de Atendimento
Assim como na computação existem diversos algoritmos diferentes para resolver o
mesmo problema, na engenharia de elevação existem diversas lógicas de atendimento
diferentes para coordenar o sistema de elevadores no atendimento de chamadas de
passageiros. Diferentes lógicas de atendimento necessitam de diferentes periféricos para
trocar informações com o ambiente. Esses periféricos são botões, sensores, indicadores, etc.
Os dados que a lógica de atendimento não tem como obter por inexistência de um tipo de
periférico para coletá-los, ela trata com suposições. Essas suposições são baseadas no tipo de
tráfego de pessoas que a lógica espera atender, por isso, existem lógicas otimizadas para
diferentes tipos de tráfego. O uso de uma lógica de atendimento num ambiente onde o tráfego
não é o esperado provoca a redução do desempenho do sistema de elevadores.
Existem livros e revistas especializados em elevadores que falam e discutem a respeito
de lógicas de atendimento. Porém o que há é a explicação da idéia básica para a
implementação de uma determinada lógica de atendimento. Normalmente, cada empresa,
parte desta idéia básica para implementar a sua própria versão desta lógica de atendimento,
com suas próprias personalizações e melhorias. Estas implementações que realmente são
colocadas nos produtos são mantidas em grande sigilo por cada indústria, já que é um recurso
chave para o desempenho do sistema de elevadores.
O objetivo deste protótipo não é realizar a implementação fiel de alguma lógica de
atendimento de alguma empresa específica, e sim desenvolver a arquitetura de um ambiente
adequado de simulação de elevadores, onde é possível acomodar diferentes lógicas de
atendimento. Este ambiente deve ser como uma “arena” onde se pode experimentar diferentes
tipos de soluções e verificar o seu desempenho. É objetivo deste trabalho também
implementar um protótipo deste ambiente para provar que é um projeto viável e que a
arquitetura funciona adequadamente. Por isso, foi implementada apenas uma lógica de
atendimento que foi baseada na lógica de atendimento chamada atendimento seletivo de
descida, descrita na bibliografia pesquisada (STRAKOSCH, 1998). Era prevista a
implementação de mais alguma lógica, mas devido a problemas de tempo no andamento do
projeto, elas não foram implementadas. Mesmo a assim, acredita-se que isto não compromete
o trabalho proposto uma vez que a lógica de atendimento, neste protótipo, tem apenas caráter
ilustrativo, já que ela foi implementada para ter o comportamento básico descrito na

41

bibliografia pesquisada, mas o restante, sobre o qual não se tem descrição, foi implementado
para o correto funcionamento, porém sem necessariamente representar a realidade de algum
produto específico de alguma empresa.
Em um sistema com atendimento seletivo de descida, existe apenas um tipo de botão
de chamada nos pavimentos, o do tipo que faz chamada de descida (embora o passageiro no
pavimento possa querer subir). O elevador atende as chamadas sempre de cima para baixo, ou
seja, ele sobe até a chamada de pavimento (ou de cabine) mais alta e desce atendendo as
demais chamadas até a chamada mais baixa. Então, o ciclo é reiniciado e o elevador sobe
novamente para atender a chamada mais alta realizada neste meio tempo e desce atendendo as
demais. Esta lógica é apropriada para o tráfego de prédios residências, onde normalmente as
pessoas querem ir do térreo para o seu andar e do seu andar para o térreo.
A realização dessa lógica de atendimento no sistema é feita pela classe
SeletivoDescida juntamente com a classe AtendenteSeletivoDescida. Um objeto
SeletivoDescida cria para cada um dos elevadores do sistema um objeto AtendenteSeletivo
Descida. Cada objeto AtendenteSeletivoDescida controla o seu próprio elevador e o objeto
SeletivoDescida coordena todos os atendentes.
Na simulação, não existem restrições nem detalhamentos relativos a aspectos de
hardware, como é caso de um único botão de descida para o atendimento seletivo de descida.
O que há é uma comunicação direta entre os passageiros e a lógica de atendimento, sem
intermédio de periféricos. Para uma simulação correta, cada classe de lógica de atendimento
simulada deve não se valer de informações que no ambiente real não estão disponíveis,
simulando assim limitações de hardware. Por exemplo, para a lógica seletivo descida não são
coletadas mais de uma chamada para o mesmo pavimento, logo, a lógica de atendimento não
sabe quantas pessoas estão esperando em cada pavimento, o que realmente acontece no
sistema real. Outras limitações específicas desta lógica implementada são que o destino da
chamada é informado somente na cabine (chamada de cabine) e a ausência de dispositivo
pesador para que se possa estimar quantidade de pessoas na cabine e se ela está lotada. Todas
essas informações estão disponíveis no sistema, mas a lógica não as utiliza justamente para
simular a realidade. Em outras lógicas, talvez não haja alguma dessas limitações, então ela
pode se valer da informação correspondente livremente e muito provavelmente seja um
algoritmo que leva em consideração essa informação a mais para prover um melhor
atendimento.

5.3.4 Pacote Simulação
Classes que não representam objetos da realidade simulada, mas que controlam,
organizam ou analisam esses objetos, estão presentes neste pacote. Inicialmente, será visto um
diagrama que mostra a estrutura geral de um estudo (Figura 14). Um estudo é como é
denominado o “documento” do simulador. O usuário ao utilizar o simulador irá iniciar um
novo estudo ou abrir um estudo existente.

42

Figura 14 – Estrutura do estudo no simulador

Algumas classes de outros pacotes aparecem neste diagrama. Um detalhamento das
classes é feito a seguir:
• Sistema – classe relativa ao controle da aplicação em si. Pode-se dizer que é a
“raiz” do aplicativo.
• Estudo – como foi dito anteriormente, é o documento que o usuário irá criar e
poderá salvar em arquivo. Possui três coleções que podem ser associadas a
momentos distintos para o usuário: Predios, quando o usuário está construindo os
objetos que poderão participar de simulações; Cenarios, quando o usuário
seleciona objetos para participarem de uma simulação e executa a simulação; e
Comparativos, depois de executadas diferentes simulações, elas são comparadas.
• Prédios, Cenário e Comparativos – classes de coleção que armazenam e
organizam objetos ItemPredio, Cenário e Comparativo respectivamente. Não
possuem mais responsabilidades além destas.
• ItemPredio – contém um predio (do pacote Predio), uma coleção de sistemas de
elevadores e uma coleção de populações.
• SistemasElevadores – coleciona os sistemas de elevadores que foram criados
para o prédio do ItemPredio ao qual pertence.
• Populações – coleciona as populações que foram criadas para o prédio do
ItemPredio ao qual pertence.

43

• ItemPopulacao – contém uma população programada e outros objetos
relacionados a edição dessa população programada, como, por exemplo, um
objeto GeradorPopulacaoRelativo.
As classes Cenario e Comparativo serão explicadas a seguir de forma mais detalhada,
com o auxílio do diagrama da Figura 15.

Figura 15 – Classes Cenário e Comparativo

Um objeto Cenário não passa de uma seleção de objetos que o usuário faz, visando
posteriormente executar a simulação com estes objetos. Como observado no diagrama da
Figura 15, Cenário contém, de forma direta ou indireta, os objetos necessários para criar uma
simulação, que são Predio, SistemaElevadores, PopulacaoProgramada e ILogicaAtendimento.
Além disso, possui um objeto Relatório que armazena dados sobre a simulação executada.
Um objeto Comparativo não passa de uma coleção de Cenário, configurado para posterior
comparação de seus resultados (armazenados no objeto Relatório). O objeto cenário tem uma
operação chamada criaSimulacao que gera um objeto simulação configurado adequadamente
com os mesmos objetos do cenario. A classe simulação está no diagrama da Figura 16.

Figura 16 – Classe simulação e seus relacionamentos

44

O objeto simulação é que realmente é realiza a simulação. O objeto Cenário só
mantém as configurações para posteriores simulações. A simulação possui um objeto Relógio
que controla a passagem do tempo simulado. Relógio não se relaciona diretamente com o
objeto que deseja ouvir a passagem do tempo (simulação, nesse caso), mas sim, por
intermédio de uma interface (IOuvinteRelogio) para evitar o acoplamento da classe relógio
com qualquer classe que deseje este serviço. Assim a classe relógio pode ser reaproveitada em
outros tipos de simulações e até em outros domínios de problema. A classe população contém
as pessoas que estão atualmente (de acordo com o relógio) ativas na simulação. À medida que
o tempo passa, a classe população remove pessoas que já chegaram aos seus destinos e
adiciona as próximas pessoas programadas para chegar neste tempo, vindas da classe
PopulacaoProgramada. O objeto relatório é usado para armazenar os dados sobre a simulação
executada.

5.4 EXECUÇÃO DA SIMULAÇÃO
Os diagramas mostrados na seção anterior (diagramas de classe) mostram apenas
aspectos estruturais do sistema, aspectos esses que são estáticos (BOOCH, RUMBAUGH e
JACOBSON, 2000). Fazendo uma correlação com a implementação em alguma linguagem de
programação, se pode dizer que aqueles diagramas estavam mais para tempo de compilação
do que para tempo de execução. Nesta seção, serão vistos aspectos dinâmicos do sistema,
mais relacionados ao tempo de execução. É possível tal visualização através de diagramas de
seqüência (BOOCH, RUMBAUGH e JACOBSON, 2000) e diagramas de estado. Será focada
apenas a execução da simulação no sistema, visto que é um dos aspectos mais relevantes do
projeto. Serão vistos quais os objetos envolvidos na simulação e como ela se dá.
O diagrama da Figura 17 mostra a troca de mensagens (ou invocação de operações)
entre os objetos toda vez que o relógio “bate”, fazendo com que o tempo simulado passe e a
simulação ocorra. O objeto Controlador mostrado, na implementação realizada, é um
temporizador que a cada estouro de tempo chama a operação passaTempo do relógio. Uma
outra alternativa de implementação poderia ser chamar a operação passaTempo do relógio
dentro de um laço, o que tornaria a execução bem rápida, mas sem a possibilidade de o
usuário observar o andamento da simulação; ou ainda, permitir que o usuário controle a
chamada da operação passaTempo do relógio através de uma tecla por exemplo. O ideal seria
ter as três opções para o usuário escolher de acordo com a sua necessidade.

45

Figura 17 – Execução da simulação no objeto Simulação

Quando o relógio tem a sua operação passaTempo invocada, ele incrementa o seu
tempo e notifica o seu atual ouvinte de que o tempo passou. Este ouvinte, no caso do
simulador de elevadores, é um objeto simulação. O objeto simulação por sua vez, quando
ouve a notificação de passagem de tempo chama a sua rotina de simulação, que consiste
basicamente de chamar a operação simula dos seus objetos SistemaElevadores e População. O
diagrama da Figura 18 é, de certa forma, uma continuação do diagrama anterior, expandindo o
que acontece durante na operação simula do objeto SistemaElevadores.

46

Figura 18 – Execução da simulação no objeto SistemaElevadores

Os diagramas das Figuras 18 e 19 devem ser considerados como contínuos. Na sua
operação simula, o objeto SistemaElevador chama a operação simula da sua atual lógica de
atendimento e dos seus elevadores. O objeto Elevadores, por sua vez, irá chamar simula para
cada um dos seus elevadores. Cada Elevador solicita a simula para sua Cabine e esta solicita
para a sua porta.

Figura 19 – Execução da simulação no objeto Elevadores

47

Ao longo da simulação, certos objetos precisam manter alguma variável sobre o seu
estado corrente. Este estado determina a ação que o objeto realiza na simulação, alterando o
seu comportamento à medida que o tempo passa. Os objetos do sistema de elevadores que
possuem estado são Cabine e PortaCabine. Estes objetos e seus estados serão examinados a
seguir, iniciando com Cabine.
A Figura 20 é um diagrama de estados da UML. Cada retângulo com cantos
arredondados representa um estado e as setas, a transição entre estes estados. O círculo aponta
para o estado inicial. Como pode ser observado, o objeto Cabine inicia no estado ocioso. Este
estado indica que a cabine não recebeu nenhuma ordem para atender nenhum pavimento
ainda, ou que a cabine terminou de atender o pavimento ordenado. Normalmente, é neste
estado que a cabine receberá ordens da lógica de atendimento para atender determinado
pavimento. Quando a cabine recebe uma ordem de atendimento, ela verifica se ela já não está
no pavimento ordenado, se estiver ele passa para o estado TransferindoPessoas. Caso
contrário, será iniciado o fechamento da porta de cabine através da mudança para o estado
FechandoPorta. Uma vez que a porta esteja fechada, a cabine parte para o pavimento destino,
estando durante este tempo no estado Movendo. Ao chegar no pavimento destino, existe ainda
um tempo necessário para que a cabine nivele o seu piso com o do pavimento. Durante esta
ação, ela está no estado Nivelando. Uma vez nivelada, a cabine abre a porta (mudança para o
estado AbrindoPorta). Com a porta aberta, as pessoas começam e entrar e sair da cabine, que
fica então no estado TransferindoPessoas. O tempo em que a cabine permanece no estado
TransferindoPessoas depende da quantidade de pessoas entrando e saindo dela, sendo
diretamente proporcional. Terminada a transferência, a cabine volta para o estado Ocioso.

Figura 20 – Estados do objeto Cabine

48

A porta da cabine também possui estados durante a simulação. Estes estados são
mostrados no diagrama da Figura 21.

Figura 21 – Estados do objeto PortaCabine

A porta de cabine inicia no estado Aberta. Quando ela recebe uma ordem de
fechamento, entra então no estado Fechando, e permanecerá neste estado o tempo necessário
para completar o seu fechamento. Quando está completamente fechada, passa para o estado
Fechada e permanecerá neste estado até que receba uma ordem para abrir. Se a ordem para
abrir for dada, ocorre a mudança para o estado Abrindo, cuja permanência durará o tempo
necessário para abrir a porta. Uma vez que a abertura esteja completa, a porta volta para o
estado Aberta.
Como foi visto anteriormente, o objeto simulacao chama na sua rotina de simulação a
operação simula de Elevadores e, em seguida, chama a operação simula de População. Agora,
será expandido o processo de simulação dentro do objeto População. Tal processo é ilustrado
no diagrama da Figura 22.

49

Figura 22 – Execução da simulação no objeto Populacao

A operação simula de População consiste em três tarefas. A primeira é remover as
pessoas que já não têm mais pavimentos para ir, logo, não têm mais importância na
simulação. Isto é feito pela rotina removePessoasProntas, que pergunta para cada pessoa se
ela está finalizada e, em caso afirmativo, a remove. Outra tarefa é verificar a chegada de mais
pessoas à simulação. As chegadas dependem do tempo atual e do que foi programado na
PopulacaoProgramada. Por isso, a populacao pede para PopulacaoProgramada as pessoas que
devem entrar no tempo atual através da operação obtemPessoas. As pessoas retornadas por
esta operação são adicionadas na população. Por fim, a população itera sobre as pessoas que
ela mantém, chamando para cada uma a operação simula.
A classe Pessoa passa por estados ao longo da simulação para controlar o seu
comportamento. Estes estados são mostrados no diagrama da Figura 23.

50

Figura 23 – Estados do objeto Pessoa

O estado inicial da pessoa é Indefinido. Este estado indica que pessoa não sabe o que
fazer e precisa avaliar a situação para tomar uma decisão (ir para outro estado). Quando está
neste estado, a pessoa verifica se possui algum pavimento destino, se ela já não está neste
pavimento destino e se esse destino é alcançável pelo sistema de elevadores. Se ela constatar
que precisa utilizar o sistema de elevadores, ela passa para o estado ChamandoElevador; do
contrário, muda para o estado Pronto. Uma vez no estado ChamandoElevador, a pessoa
realiza a chamada no sistema de elevadores, passando em seguida para o estado
EsperandoElevador. Neste meio tempo, a pessoa aguarda pelo elevador apropriado. Quando
ela consegue entrar na cabine, muda então para o estado ViajandoElevador. Quando no estado
ViajandoElevador, a pessoa não faz nada, apenas aguarda a notificação de parada da cabine,
verificando se esta parada é no seu pavimento destino. Se for, a pessoa sai da cabine
completando a viagem, o que a faz mudar para o estado Pronto. O destino alcançado é
removido da coleção de destinos da pessoa. Se houver mais destinos, a pessoa volta para o
estado Indefinido, reiniciando o ciclo. Caso contrário, muda para o estado Finalizado, que é o
estado final, indicado na UML por apontar para uma circunferência com um círculo
concêntrico. Quando um objeto entra no seu estado final não muda mais para nenhum outro
estado, logo, no caso da pessoa, ela não executará mais nenhuma ação e será removida da
população como foi descrito anteriormente.
Durante essas ações, a pessoa reporta dados sobre o desempenho do sistema durante o
atendimento da sua chamada. Esses dados entram no objeto relatório da simulação e do
cenário para depois serem sumarizados e analisados. Os principais dados coletados são o
tempo de espera, que é o tempo desde de a chamada realizada no pavimento até a chegada da

51

cabine; e o tempo de viagem, que é o tempo que a pessoa passou dentro da cabine. O tempo
de espera e o tempo de viagem são os dados essenciais para a avaliação do desempenho de um
sistema de elevadores. A soma desses dois dados resulta no tempo total que a pessoa usou o
sistema. Outros dados adicionais poderiam ser coletados por outros objetos, pela cabine, por
exemplo. Mas isso já seria a adaptação para necessidades específicas de algum usuário ou
empresa. Essa e outras personalizações poderão ser feitas se este protótipo vir a ser adotado
por alguma empresa como um projeto.

6 UTILIZAÇÃO DO PROTÓTIPO
Para as classes descritas no capítulo anterior, foram construídos objetos controladores
(para coordenar a edição e interação do usuário) e interfaces gráficas, tornando o sistema um
protótipo utilizável. Certas qualidades desejáveis num produto final não foram
implementadas, como, por exemplo, vários conceitos relacionados à engenharia da
usabilidade, bem como manual do usuário e documentação de ajuda. Justamente por não ter
as características de um produto final é que o projeto foi caracterizado como protótipo. O
projeto foi planejado para produzir apenas um protótipo porque o objetivo deste trabalho é
provar que é a simulação de elevadores é um projeto viável e que a arquitetura projetada é
adequada, robusta, abrangente e extensível. Além disso, a produção de um aplicativo como
este com qualidade de produto final levaria mais tempo do que o permitido para este trabalho,
e só teria sentido se fosse já adotado como projeto para uma empresa em particular.
A próxima seção irá introduzir a aparência e funcionamento da ferramenta através de
um exemplo de simulação. Já a seção seguinte faz uma correlação entre o simulador e o
cálculo de tráfego.

6.1 EXEMPLO DE SIMULAÇÃO
A ferramenta será usada para avaliar o desempenho de duas soluções de elevação
frente ao mesmo prédio e população. Na janela principal do programa, no lado esquerdo,
existe um conjunto de três “páginas”, com os títulos Prédio, Cenários e Comparativos. Na
página Prédios é que o usuário adiciona os objetos que posteriormente poderão participar de
uma simulação. Estes objetos são prédio, população e sistema de elevadores. A adição é feita
através dos respectivos menus. A página prédios mostra uma estrutura de árvore, onde cada
prédio é uma raiz contendo a estrutura física, um conjunto de populações e um conjunto de
sistemas de elevadores pertencentes a este prédio. Isto reflete o que foi modelado e descrito
anteriormente sobre um prédio poder ter mais uma população e mais de sistema de
elevadores. A edição das características físicas de um prédio é mostrada na Figura 24. Todos
os itens aparecendo na figura estão com os nomes sugeridos pelo programa, mas podem ser
renomeados como o usuário desejar.

53

Figura 24 – Edição da estrutura física de um prédio

Na edição da população, deve ser informada a quantidade de pessoas no prédio. Isso é
feito adicionando-se usos ao prédio. Caso a quantidade de pessoas seja conhecida, utiliza-se o
tipo de uso valor direto, que na verdade não é um tipo de uso. Ele permite que o usuário digite
o valor desejado diretamente. Se não se sabe a quantidade de pessoas, ela pode ser estimada
com a ajuda do sistema se a forma que o prédio será utilizado for conhecida. Na Figura 25,
observa-se a utilização do tipo de uso do prédio para auxiliar a estimar a quantidade de
pessoas.

54

Figura 25 – Estimativa da população baseada nos usos do prédio

Uma vez definida a quantidade de pessoas da população, o usuário distribui essas
pessoas em momentos de chegada. Isso é feito clicando num gráfico que tem no eixo X a
linha de tempo da simulação. Essa linha de tempo pode ser editada quanto ao início, fim e a
sua escala.
A Figura 26 mostra a distribuição das chegadas para a população do exemplo. De
forma, semelhante é feita a distribuição de cada chegada pelos pavimentos, sendo uma
distribuição para a origem e outra para o destino.

55

Figura 26 – Distribuição das pessoas em momentos de chegada

A edição do sistema de elevadores é mostrada na Figura 27. Foram criados dois
sistemas para o exemplo. O Sistema 1 possui dois elevadores com cabines de capacidade de
15 pessoas. Já o Sistema 2, possui três elevadores com cabines de capacidade de 10 pessoas.
As configurações restantes são iguais entre os dois sistemas.

56

Figura 27 – Edição do sistema de elevadores

Na página Cenários, o usuário pode selecionar itens que ele criou e editou na página
prédios para serem simulados juntos, o que no sistema é chamado de cenário. Os cenários são
exibidos em uma lista, como mostrado na Figura 28. Criar um cenário não faz com que a
simulação seja iniciada, apenas permite manter a configuração necessária para iniciar a
simulação a partir do cenário. Pode-se dizer que, no programa, a simulação é o cenário em
execução. Só é possível criar um cenário se existe pelo menos um prédio com uma população
e com um sistema de elevadores. Para o exemplo, foram criados dois cenários. Ambos
possuem o mesmo prédio e população. A diferença está no sistema de elevadores: o Cenário 1
utiliza o Sistema 1 e o Cenário 2, o Sistema 1. A Figura 28 mostra o Cenário 1 com a
simulação sendo executada.

57

Figura 28 – Cenário com simulação em execução

Os números na coluna pessoas indicam a quantidade de pessoas aguardando pelo
elevador no respectivo pavimento. As cabines são representadas pelos colchetes, sendo que o
número entre eles é a quantidade de pessoas dentro da cabine. As setas laterais aparecem
quando a porta da cabine está abrindo ou fechando.
Os comparativos são criados selecionando-se cenários existentes para que os
resultados de suas simulações sejam confrontados. Os comparativos são criados e exibidos
numa lista na página Comparativos do programa. A janela de comparativo exibe o resultado
de cada um dos cenários do comparativo, que normalmente é exibido em um gráfico separado
na janela de cenário, num único gráfico, facilitando a avaliação do usuário. No gráfico é
possível para o usuário selecionar qual valor deseja visualizar: tempo de espera, tempo de
viagem ou tempo total (tempo de espera + tempo de viagem). Também é possível selecionar a
forma de agregação entre média, máxima e mínima. A Figura 29 mostra o comparativo
realizado para o exemplo, mostrando o desempenho de Cenário 1 e Cenário 2.

58

Figura 29 – Comparativo exemplo

6.2 COMPARAÇÃO COM CÁLCULO DE TRÁFEGO
O comportamento dos objetos da simulação foi baseado principalmente nas
descrições, fórmulas e tabelas encontradas em (STRAKOSCH, 1998), que também são
utilizadas no cálculo de tráfego. Por isso é de se esperar que a simulação apresente resultados
semelhantes aos do cálculo de tráfego. Durante todo o desenvolvimento, o comportamento
dos objetos simulados foi comparado com o que é descrito no cálculo de tráfego como, por
exemplo, a porta simulada. Serão demonstradas a seguir comparações mais gerais, utilizando
amostras de cálculo de tráfego que foram recriadas no simulador.

6.2.1 Cálculo 1
A amostra de cálculo descreve um elevador com capacidade de 16 pessoas, com
velocidade de 2,5 metros por segundo e porta de tipo central de 120 centímetros. Ele está
instalado em um prédio de 11 pavimentos, sendo cada um deles de 365 centímetros de altura.
É questionado pelo cálculo quantas pessoas são transportadas em 5 minutos durante um pico
de tráfego de subida, sendo que em médio a cabine lotada fará 8.6 paradas. De acordo com o
cálculo, o resultado é 30 pessoas.

Simulador de Elevadores

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (12)

Semelhante a Simulador de Elevadores

Semelhante a Simulador de Elevadores (18)

Mais de Mauricio Volkweis Astiazara

Mais de Mauricio Volkweis Astiazara (20)

Simulador de Elevadores