Escolar Documentos
Profissional Documentos
Cultura Documentos
PROTÓTIPO DE SIMULADOR
DE ELEVADORES
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
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....................................................................................................................12
2 ELEVADORES....................................................................................................................13
2.1 SURGIMENTO DO ELEVADOR..................................................................................................13
2.2 DESENVOLVIMENTO TECNOLÓGICO E TENDÊNCIAS.....................................................................14
2.3 ENGENHARIA DE ELEVAÇÃO..................................................................................................14
2.3.1 Estudo de Tráfego...................................................................................................15
2.3.2 Cálculo de Tráfego.................................................................................................16
2.4 NECESSIDADES DA ÁREA DE PESQUISA E DESENVOLVIMENTO.......................................................17
3 SIMULAÇÃO.......................................................................................................................18
3.1 CONCEITO..........................................................................................................................18
3.2 METODOLOGIAS..................................................................................................................19
3.3 FERRAMENTAS EXISTENTES...................................................................................................19
4 PROJETO DA FERRAMENTA........................................................................................22
4.1 MOTIVAÇÃO.......................................................................................................................22
4.2 OBJETIVOS.........................................................................................................................23
4.3 METODOLOGIA ADOTADA.....................................................................................................24
4.3.1 Orientação a Objetos..............................................................................................24
4.3.2 Processo Unificado.................................................................................................24
4.3.3 UML.......................................................................................................................25
4.4 RECURSOS EMPREGADOS.......................................................................................................25
4.4.1 Modelagem.............................................................................................................25
4.4.2 Implementação........................................................................................................26
5 DESENVOLVIMENTO DA FERRAMENTA..................................................................27
5.1 LEVANTAMENTO DOS CASOS DE USO.......................................................................................27
5.2 PACOTES BÁSICOS...............................................................................................................30
5.3 PACOTES ESPECÍFICOS DO SISTEMA.........................................................................................32
5.3.1 Pacote Prédio..........................................................................................................33
5.3.2 Pacote Pessoa..........................................................................................................34
5.3.2.1 População Programada....................................................................................34
5.3.2.2 Geradores de População..................................................................................35
5.3.2.3 Usos de um Prédio..........................................................................................37
5.3.3 Pacote Elevador......................................................................................................39
5.3.3.1 Visão Geral das Classes do Pacote.................................................................39
5
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.
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.
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;
19
• 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.
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.
23
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.
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.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
26
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.
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:
29
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.
30
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
34
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.
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.
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.
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.
39
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.
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.
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.
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.
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.
A porta da cabine também possui estados durante a simulação. Estes estados são
mostrados no diagrama da Figura 21.
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.
50
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
52
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.
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.
58
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.
60
6.2.2 Cálculo 2
A segunda amostra de cálculo descreve um prédio de 15 pavimentos, sendo os dois
primeiros com altura de 609 centímetros e os demais, 365 centímetros. O elevador tem
capacidade para 17 pessoas e velocidade de 2,5 metros por segundo. O cálculo indica que o
total de pessoas transportadas em 5 minutos durante um pico de tráfego de subida é 28
pessoas.
Novamente, os itens descritos foram construídos no simulador e a simulação
executada diversas vezes para amenizar fatores aleatórios da geração da população. Os
resultados obtidos ficaram no intervalo entre 27 e 29 pessoas, o que pode ser considerado
adequado. Nas Figuras 32 e 33 é mostrado o fim da simulação e o seu resultado.
62